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

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Thu, 1 Feb 2007 06:15:50 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Asq rewritten

There were many plans to rewrite various parts of Axiom.  I decided
to actually rewrite one part: the asq program :).

Actually my reasons for rewrite were:

1) Old asq was broken by trivial changes to database format (like
   turning off compression, or pretty printing databases), the
   new one should be more resistant.
2) Old asq was longish, verbose and used very unusal coding style.
3) Some people (Bill Page ???) hoped to use asq as a base for
   browser access to Axiom databases, the new one hopefully is
   easier to adapt/change than the old one.

Since the output of old asq was rather irregular, I have taken
liberty to change output formatting and command line options.
I hope that such change will cause no troubles.

Since the old asq documentation mostly duplicated daase.lisp.pamphlet,
I have written also completly new (short) documentation.

P.S.  I just commited the new asq to wh-sandbox.

\start
Date: 01 Feb 2007 09:23:22 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Asq rewritten

Dear Waldek,

Waldek Hebisch writes:

> There were many plans to rewrite various parts of Axiom.  I decided
> to actually rewrite one part: the asq program :).

Did you see the mail where I set a price? Well, I repeat the relevant bit here
anyway, slightly modified to make the intention clearer:

(Modifications in [...])


**OLD MAIL*********************************************************************
I think it's time to set a price again. I'll pay 100$ anyone who writes a new,
or modifies an existing program, that displays [in a standard webbrowser] the
documentation of a +++ environment (and only this bit of documentation) as
generated by ALLPROSE, on demand, i.e., using a web interface similar to that
Tim provided.

To get started, do the following

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

svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk

cd combinat/trunk/combinat

notangle -t8 Makefile.nw > Makefile

make VARIANTSTOBUILD=axiom

cd lib

for f in $(ar t libcombinatax.al); do ar x libcombinatax.al $f; done
for f in $(ar t libcombinatax.al); do echo ")lib $f" >> combinat.input; done

cd ../src

axiom

-- now everything of combinat is available. To generate a libdb.text say

)se co args "-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra -i ../include"

)co csseries
----------------------------------------------------------------------
(very likely, there is an easier way to generate the libdb file.)

To explain the process a bit: (Ralf, please correct me if I'm wrong)

  make VARIANTSTOBUILD=axiom

extracts using noweb documentation and code from the source files, for example
series.as.nw. All of the code and the api description (i.e., everything between
\begin{+++} ... \end{+++} ) is put into a file csseries.as.

")co csseries" is one way to extract the +++ strings and write them into
libdb.text.

The best thing would be, of course, if one could simply call tex4ht on the
individual +++ strings. One would have to write a suitable LaTeX preamble, of
course, that \usepackages the appropriate style files. However, I do not know
how hyperlinking will work then. (In fact, I don't even understand hyperlinking
within ALLPROSE, and Ralf begs me to read the documentation since a few
months...)

Maybe it also makes sense to run a preprocessor over the literate
program. I.e., to modify ALLPROSE so that preprocecessed LaTeX (for example
html) is put into a database. But I would like the other solution better.

It would already be a great thing if doc could be displayed without
hyperlinks. That shouldn't be too hard, I believe.

**END OLD MAIL*****************************************************************

Here is a bit of the generated libdb.text:


dDataStream`1`x`(CoercibleTo(OutputForm))->etc`(T)`DATASTR`\begin{adusage}      T == Integer      s: \adthistype{} T := \adname{stream: T -> %} 0;      s := \adname{stream: Generator T -> %}(generator [1, 3]);      g: \adtype{Generator} T == generate for i in 2.. repeat yield i;      s := \adname{stream: Generator T -> %} g;    \end{adusage}    \begin{addescription}{Implements an infinite array.}      The domain \adthistype{} can be abstractly seen as an infinite      array. However, to make thi----s data structure finite, it is more      appropriate to view it as a pair $(a, g)$ of an      \adcode$\adtype{Array}(T)$ and a \adcode$\adtype{Generator}(T)$.        Like \adtype{Array}, \adthistype{} is 0-based.    \end{addescription}



Non-standard environments and commands:

adusage and addescription are environments, adname, adthisname, adtype,
adthistype commands defined in combinat/trunc/allprose/aldordoc.sty.nw.

Below is a very short description, to see the full thing say

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

cd combinat/trunk/combinat

make include-allprose-documentation colored html

konqueror doc/combinat.html

-------------------------------------------------------------------------------
and go to Section 33.


The short description:

adusage: explains how to use the constructor/operation by example

addescription: the argument of the environment is a one-line description, the
         body a more detailed one

\adname: markup for a constant or operation. Should be hyperlinked to the
         appropriate constant, operation.

\adtype: markup for a type constructor. Should be hyperlinked to the
         appropriate type constructor.

\adthisname: expands to the constant or operation we are currently looking
         at. (should not occur if we are just defining a type...)

\adthisname: expands to the constructor we are currently looking at, or, if we
         we are just defining a constant or an operation, the constructor it
         belongs to. In the example above, it expands to DataStream.


You can find the DataStream example properly typeset in Section 22.1.

To see an operation, look at stream: Generator T -> % (roughly five pages below
the definition of DataStream, which, in libdb.text reads as follows:

ostream`1`x`(Generator(T))->_$`dDataStream(T)``\begin{adusage}      T == Integer;      g: \adtype{Generator} T := generator [2,4,6,7];      s: \adthistype{} T := \adthisname{} g;    \end{adusage}    \begin{adparameters}      \adparameter{g: Generator Integer} A (finite or infinite)      generator that computes the next values of the stream.    \end{adparameters}    \begin{addescription}{Construct a stream.}      The function constructs the stream      \begin{gather}        (g_1, g_2, g_3, \ldots----)      \end{gather}      or (informally) the infinite array      \begin{adsnippet}        [x for x in g]      \end{adsnippet}      where $g_i$ is the $i$-th element generated by the generator $g$.        In case the stream $g$ is finite and generates $n$ elements then      the result is      \begin{gather}        (g_1,...,g_{n-1}, g_n, g_n, g_n, \ldots).      \end{gather}    \end{addescription}    \begin{adremarks}      It is allowed to call \adthisname{} with a generator that does not      --ge--nerate any element, but the resulting stream may not be ask to      reveal any of its entries, since there are none. It is basically      the same to say \adcode$\adthisname(generate)$ and      \adcode$\adname{new}()$.    \end{adremarks}



It is a mystery to me how Ralf did the linking magic. Maybe he or the
combinat.aux file can help...

\start
Date: Thu, 01 Feb 2007 10:10:37 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: Asq rewritten

I think I have to reply to Martin's mail.

I don't have experience with the database, but slightly different from 
what Martin wants, my intensions would go into another direction (which 
are as a first approximation completely independent of ALLPROSE).

The Aldor compiler puts the ++ comments into the .ao files. Using

aldor -fasy file.ao

one basically gets all the information that is relevant, ie, code and ++ 
comments at the right place. Furthermore if one includes

   -lalgebra -laldor

on the above command line, the compiler extracts exports from the 
libraries and puts them into some place of domains in file.ao. That 
would give a list of *all* the exports of a domain/category in file.ao.

Anyway, an .asy file basically is a LISP file, if I am not completely 
wrong. So for a LISP expert that should be not too difficult to make 
sense of it.

My current plans (no time for actually writing some code) would be to 
take that .asy file and produce a .tex file which could be compiled into 
.html via tex4ht. Actually, I go only via .tex because ALLPROSE uses the 
convention to write a LaTeX-like syntax into the ++ comments.

Actually, ALLPROSE already contains the API, but not in an API-only 
form. And I would very much like that one could fold and unfold the 
*complete* list of exports of a domain and to have references from 
categories to domains that use that category.

Ralf

On 02/01/2007 09:23 AM, Martin Rubey wrote:
> Dear Waldek,
> 
> Waldek Hebisch writes:
> 
>> There were many plans to rewrite various parts of Axiom.  I decided
>> to actually rewrite one part: the asq program :).
> 
> Did you see the mail where I set a price? Well, I repeat the relevant bit here
> anyway, slightly modified to make the intention clearer:
> 
> (Modifications in [...])
> 
> 
> **OLD MAIL*********************************************************************
> I think it's time to set a price again. I'll pay 100$ anyone who writes a new,
> or modifies an existing program, that displays [in a standard webbrowser] the
> documentation of a +++ environment (and only this bit of documentation) as
> generated by ALLPROSE, on demand, i.e., using a web interface similar to that
> Tim provided.

[snip]

> It is a mystery to me how Ralf did the linking magic. Maybe he or the
> combinat.aux file can help...

Come on, Martin, there is no mystery. Since ALLPROSE introduced some 
conventions of how to write domain and category definitions, it is quite 
easy to extract their names from the code and put them into 
\addefinetype{...}. When you use \adtype{...} it links to the place 
where \addefinetype is. The definition of \addefinetype and \adtype 
basically use commands from the hyperref LaTeX package and add some 
indexing and color information. That is not too much magic.

\start
Date: Thu, 1 Feb 2007 04:39:39 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox

On Wed, 31 Jan 2007 Waldek Hebisch wrote:

[...]

| Modified: branches/wh-sandbox/src/etc/asq.c.pamphlet
| ===================================================================
| --- branches/wh-sandbox/src/etc/asq.c.pamphlet	2007-01-27 16:50:57 UTC (rev 425)
| +++ branches/wh-sandbox/src/etc/asq.c.pamphlet	2007-02-01 05:09:31 UTC (rev 426)
| @@ -2,1559 +2,929 @@
|  \usepackage{axiom}
|  \begin{document}
|  \title{\$SPAD/etc asq.c}
| -\author{Timothy Daly}
| +\author{Waldek Hebisch}

I believe the conventional wisdom would suggest that you add your name
as co-author as opposed to replacing the existing author, even if you
have rewritten it. If this were a separate new program not building on
previous ideas, I would that it is OK.

\start
Date: 01 Feb 2007 04:55:07 -0600
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Asq rewritten

Ralf Hemmecke writes:

| I think I have to reply to Martin's mail.
| 
| I don't have experience with the database, but slightly different from
| what Martin wants, my intensions would go into another direction
| (which are as a first approximation completely independent of
| ALLPROSE).
| 
| The Aldor compiler puts the ++ comments into the .ao files. Using

The old parser (used by the compiler) almost ignores comment -- you
don't see them directly in the parse tree; they are recorded
elsewhere.  The new parser (used by the interpreter) has documentation
as part of the parse tree.

We have made some progress, here in the Parasol Lab, in terms of
understanding the Axiom compiler infrastructure.  We plan to have
Axiom store algebras in formats that are close to the source trees.
Something betwen the "parse forms" and the internal AST that is fed to
compTopLevel for example, but that retained just about anything.  The
new format is of course in addition to the existing ones.

\start
Date: Thu, 1 Feb 2007 14:34:53 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox

Gabriel Dos Reis wrote:
> On Wed, 31 Jan 2007 Waldek Hebisch wrote:
> 
> [...]
> 
> | Modified: branches/wh-sandbox/src/etc/asq.c.pamphlet
> | ===================================================================
> | --- branches/wh-sandbox/src/etc/asq.c.pamphlet	2007-01-27 16:50:57 UTC (rev 425)
> | +++ branches/wh-sandbox/src/etc/asq.c.pamphlet	2007-02-01 05:09:31 UTC (rev 426)
> | @@ -2,1559 +2,929 @@
> |  \usepackage{axiom}
> |  \begin{document}
> |  \title{\$SPAD/etc asq.c}
> | -\author{Timothy Daly}
> | +\author{Waldek Hebisch}
> 
> I believe the conventional wisdom would suggest that you add your name
> as co-author as opposed to replacing the existing author, even if you
> have rewritten it. If this were a separate new program not building on
> previous ideas, I would that it is OK.
> 

Hmm, I undersand that conventional wisdom is to err on side of giving
more credit for work than too little credit, but I find this suggestion
a little extreme.

Gaby, did you look at both programs: the new asq is a _new_ program.
Re-used from the old program is starting Latex boilerplate, Latex
footer and AXIOM variable (assignment and a test).  On the level of
ideas of course I re-used the very idea of having such a program
and tried to make it compatible (in particular I re-used most of
the option names).  Also the general approach (using linear search)
is common.  But that is basically all.

About 70% of the new program is a start of generic S-expression handling
library which has no couterpart in the old program.  The rest is also
very different (in particular much simpler) due to use of S-expressions
and table driven option handling.

I think it is proper to have acknowledgement line like:

  This program replaces an older one written by Tim Daly.

(the exact wording may be different).
 
\start
Date: Thu, 01 Feb 2007 16:11:14 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox
Cc: Gabriel Dos Reis

>> I believe the conventional wisdom would suggest that you add your name
>> as co-author as opposed to replacing the existing author, even if you
>> have rewritten it. If this were a separate new program not building on
>> previous ideas, I would that it is OK.
>>
> 
> Hmm, I undersand that conventional wisdom is to err on side of giving
> more credit for work than too little credit, but I find this suggestion
> a little extreme.
> 
> Gaby, did you look at both programs: the new asq is a _new_ program.
> Re-used from the old program is starting Latex boilerplate, Latex
> footer and AXIOM variable (assignment and a test).  On the level of
> ideas of course I re-used the very idea of having such a program
> and tried to make it compatible (in particular I re-used most of
> the option names).  Also the general approach (using linear search)
> is common.  But that is basically all.
> 
> About 70% of the new program is a start of generic S-expression handling
> library which has no couterpart in the old program.  The rest is also
> very different (in particular much simpler) due to use of S-expressions
> and table driven option handling.
> 
> I think it is proper to have acknowledgement line like:

>   This program replaces an older one written by Tim Daly.  (*)

> (the exact wording may be different).

If the program is more or less completely new then it is OK if Waldek 
just puts himself as an author. But removing Tim completely is, of 
course, no option.

Waldek, what about including the above information of what you took over 
and what you simplified in addition to the line (*)? You probably also 
took over the interface since otherwise your program cannot simply 
replace Tim's asq.

I think that Tim has already stated it before: respect.

\start
Date: Thu, 1 Feb 2007 09:54:15 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox

On Thu, 1 Feb 2007, Waldek Hebisch wrote:

| Gabriel Dos Reis wrote:
| > On Wed, 31 Jan 2007 Waldek Hebisch wrote:
| >
| > [...]
| >
| > | Modified: branches/wh-sandbox/src/etc/asq.c.pamphlet
| > | ===================================================================
| > | --- branches/wh-sandbox/src/etc/asq.c.pamphlet	2007-01-27 16:50:57 UTC (rev 425)
| > | +++ branches/wh-sandbox/src/etc/asq.c.pamphlet	2007-02-01 05:09:31 UTC (rev 426)
| > | @@ -2,1559 +2,929 @@
| > |  \usepackage{axiom}
| > |  \begin{document}
| > |  \title{\$SPAD/etc asq.c}
| > | -\author{Timothy Daly}
| > | +\author{Waldek Hebisch}
| >
| > I believe the conventional wisdom would suggest that you add your name
| > as co-author as opposed to replacing the existing author, even if you
| > have rewritten it. If this were a separate new program not building on
| > previous ideas, I would that it is OK.
| >
|
| Hmm, I undersand that conventional wisdom is to err on side of giving
| more credit for work than too little credit, but I find this suggestion
| a little extreme.

I'm not so sure.

| Gaby, did you look at both programs: the new asq is a _new_ program.

I read over your new "asq" and the old asq and followed your
explanation, *before* I sent my mail.

My opinion is that your name should be added co-author, not replace
the original author.  Or, call the program something else and
acknowledge that this new program greatly benefited from the existing
one, in particular from its documentation and its errors. But having
two proram doing almost the same thing will be very confusing.  So, I
believe the conventional wisdom is good here.

A ways to kepp a project attractice and collegial is to be cautious
with credit.

Look at GCC for example.  Most parts of it have nothing common with
the GCC from 1996 or 1997.  In particular, look at the C preprocessor;
it has been *completely* rewritten from scratch, with readically
different ideas.  Nonetheless, the authorship displays the people who
did not "directly" contribute to the new program in any form.

\start
Date: Thu, 1 Feb 2007 20:04:50 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox

> On Thu, 1 Feb 2007, Waldek Hebisch wrote:
> 
> | Gabriel Dos Reis wrote:
> | > On Wed, 31 Jan 2007 Waldek Hebisch wrote:
> | >
> | > [...]
> | >
> | > | Modified: branches/wh-sandbox/src/etc/asq.c.pamphlet
> | > | ===================================================================
> | > | --- branches/wh-sandbox/src/etc/asq.c.pamphlet	2007-01-27 16:50:57 UTC (rev 425)
> | > | +++ branches/wh-sandbox/src/etc/asq.c.pamphlet	2007-02-01 05:09:31 UTC (rev 426)
> | > | @@ -2,1559 +2,929 @@
> | > |  \usepackage{axiom}
> | > |  \begin{document}
> | > |  \title{\$SPAD/etc asq.c}
> | > | -\author{Timothy Daly}
> | > | +\author{Waldek Hebisch}
> | >
> | > I believe the conventional wisdom would suggest that you add your name
> | > as co-author as opposed to replacing the existing author, even if you
> | > have rewritten it. If this were a separate new program not building on
> | > previous ideas, I would that it is OK.
> | >
> |
> | Hmm, I undersand that conventional wisdom is to err on side of giving
> | more credit for work than too little credit, but I find this suggestion
> | a little extreme.
> 
> I'm not so sure.
> 
> | Gaby, did you look at both programs: the new asq is a _new_ program.
> 
> I read over your new "asq" and the old asq and followed your
> explanation, *before* I sent my mail.
> 
> My opinion is that your name should be added co-author, not replace
> the original author.  Or, call the program something else and
> acknowledge that this new program greatly benefited from the existing
> one, in particular from its documentation and its errors. But having
> two proram doing almost the same thing will be very confusing.  So, I
> believe the conventional wisdom is good here.
>

I fail to see how filename affects authorship status of a file.  FYI
I developed under different name outside of Axiom tree.  I started
copying a few lines from old asq but quickly realized that old code
do not fit into my design.  So I wrote the program essentially from 
scratch.  <heresy> After the program was finished I have put literate
wrapper around it and dropped it into the source tree </heresy>.
IMHO the few copied lines are not more significant than a few declarations
that I copied form man pages.

Note that I do not claim any credit for the old asq program.  And
I think that we should prominently state that previous version was
due to Tim Daly.  But the \authors{} construct seem too limited
to correctly express such information.

AFAICS changing file name limits possibilty for
misunderstanding authorship, but is an inconvenience for users
(still, if you guys think that renaming is a way to go I will do
it).  I do not consider keeping the old program as an option:
main reason to write the new one was that the old one does not
work with other changes that I am making.
 
> A ways to kepp a project attractice and collegial is to be cautious
> with credit.
> 
> Look at GCC for example.  Most parts of it have nothing common with
> the GCC from 1996 or 1997.  In particular, look at the C preprocessor;
> it has been *completely* rewritten from scratch, with readically
> different ideas.  Nonetheless, the authorship displays the people who
> did not "directly" contribute to the new program in any form.
> 

I do not see information about authors in preprocessor program files,
only note like:

   Copyright (C) 1986, 1987, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
   1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006
   Free Software Foundation, Inc.
   Contributed by Per Bothner, 1994-95.
   Based on CCCP program by Paul Rubin, June 1986
   Adapted to ANSI C, Richard Stallman, Jan 1987

IMHO such note is misleading by ommision, but at least dates allow
to infer that this information is highly incomplete.  I see
Richard Stallman mentioned as a coauthor of cpp.texi, but comparing
cpp.texinfo from gcc-1.35 with cpp.texi from gcc-4.1.1 I can find
a few passages are taken almost verbatim from the old version.
I would guess that careful examination would show more connections.
So I consider it reasonable to state that Stallman is a coauthor
(assuming he did wrote version contained in gcc-1.35). 

Concering programs: I did not look at preprocessor files.  But I did
found surprising similarities between some parts of gcc-1.35 and 
parts of gcc-4.1.1 -- after many edits code looks very different,
but clearly is still the same code.

\start
Date: Thu, 1 Feb 2007 13:24:16 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox

On Thu, 1 Feb 2007, Waldek Hebisch wrote:

| > On Thu, 1 Feb 2007, Waldek Hebisch wrote:
| >
| > | Gabriel Dos Reis wrote:
| > | > On Wed, 31 Jan 2007 Waldek Hebisch wrote:
| > | >
| > | > [...]
| > | >
| > | > | Modified: branches/wh-sandbox/src/etc/asq.c.pamphlet
| > | > | ===================================================================
| > | > | --- branches/wh-sandbox/src/etc/asq.c.pamphlet	2007-01-27 16:50:57 UTC (rev 425)
| > | > | +++ branches/wh-sandbox/src/etc/asq.c.pamphlet	2007-02-01 05:09:31 UTC (rev 426)
| > | > | @@ -2,1559 +2,929 @@
| > | > |  \usepackage{axiom}
| > | > |  \begin{document}
| > | > |  \title{\$SPAD/etc asq.c}
| > | > | -\author{Timothy Daly}
| > | > | +\author{Waldek Hebisch}
| > | >
| > | > I believe the conventional wisdom would suggest that you add your name
| > | > as co-author as opposed to replacing the existing author, even if you
| > | > have rewritten it. If this were a separate new program not building on
| > | > previous ideas, I would that it is OK.
| > | >
| > |
| > | Hmm, I undersand that conventional wisdom is to err on side of giving
| > | more credit for work than too little credit, but I find this suggestion
| > | a little extreme.
| >
| > I'm not so sure.
| >
| > | Gaby, did you look at both programs: the new asq is a _new_ program.
| >
| > I read over your new "asq" and the old asq and followed your
| > explanation, *before* I sent my mail.
| >
| > My opinion is that your name should be added co-author, not replace
| > the original author.  Or, call the program something else and
| > acknowledge that this new program greatly benefited from the existing
| > one, in particular from its documentation and its errors. But having
| > two proram doing almost the same thing will be very confusing.  So, I
| > believe the conventional wisdom is good here.
| >
|
| I fail to see how filename affects authorship status of a file.

Me enither.  Why do you think it has anything to do with this?

[...]

| Note that I do not claim any credit for the old asq program.

Yes, and listing only your name as author implies claiming credits.

| > A ways to kepp a project attractice and collegial is to be cautious
| > with credit.
| >
| > Look at GCC for example.  Most parts of it have nothing common with
| > the GCC from 1996 or 1997.  In particular, look at the C preprocessor;
| > it has been *completely* rewritten from scratch, with readically
| > different ideas.  Nonetheless, the authorship displays the people who
| > did not "directly" contribute to the new program in any form.
| >
|
| I do not see information about authors in preprocessor program files,
| only note like:
|
|    Copyright (C) 1986, 1987, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|    1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006
|    Free Software Foundation, Inc.
|    Contributed by Per Bothner, 1994-95.
|    Based on CCCP program by Paul Rubin, June 1986
|    Adapted to ANSI C, Richard Stallman, Jan 1987
|
| IMHO such note is misleading by ommision, but at least dates allow
| to infer that this information is highly incomplete.

The prominent omission is the name of the second author you found in
cpp.texi to which we should add that of Neil Booth.  You can cross
check those assertions either by looking the ChangeLog or digging the
archives (don't look at the ChangeLog in libcpp/, look at those in gcc/).

The original CPP worked on strings (contrary to ISO C specification),
and was an external program.  The new CPP works on tokens and is
integrated to the C-family front-ends.  There are very signficant
differences.  The authors took the pain to preserve the old behaviour
through within the new, correct, implementation.

Put blunt, I think you did a grave act of violence by replacing
the existing asq.c with the new one witout explicit acknowlegement as
co-author (which I believe is the correct thing), and  acknowledgment
section that traces the history of asq.c.

| I see
| Richard Stallman mentioned as a coauthor of cpp.texi, but comparing
| cpp.texinfo from gcc-1.35 with cpp.texi from gcc-4.1.1 I can find
| a few passages are taken almost verbatim from the old version.
| I would guess that careful examination would show more connections.
| So I consider it reasonable to state that Stallman is a coauthor
| (assuming he did wrote version contained in gcc-1.35).
|
| Concering programs: I did not look at preprocessor files.  But I did
| found surprising similarities between some parts of gcc-1.35 and
| parts of gcc-4.1.1 -- after many edits code looks very different,
| but clearly is still the same code.

It would be very interesting to see which portions of which files you
look at.

\start
Date: Thu, 1 Feb 2007 22:20:40 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox

> On Thu, 1 Feb 2007, Waldek Hebisch wrote:
> 
> | > On Thu, 1 Feb 2007, Waldek Hebisch wrote:
> | >
> | > | Gabriel Dos Reis wrote:
> | > | > On Wed, 31 Jan 2007 Waldek Hebisch wrote:
> | > | >
> | > | > [...]
> | > | >
> | > | > | Modified: branches/wh-sandbox/src/etc/asq.c.pamphlet
> | > | > | ===================================================================
> | > | > | --- branches/wh-sandbox/src/etc/asq.c.pamphlet	2007-01-27 16:50:57 UTC (rev 425)
> | > | > | +++ branches/wh-sandbox/src/etc/asq.c.pamphlet	2007-02-01 05:09:31 UTC (rev 426)
> | > | > | @@ -2,1559 +2,929 @@
> | > | > |  \usepackage{axiom}
> | > | > |  \begin{document}
> | > | > |  \title{\$SPAD/etc asq.c}
> | > | > | -\author{Timothy Daly}
> | > | > | +\author{Waldek Hebisch}
> | > | >
> | > | > I believe the conventional wisdom would suggest that you add your name
> | > | > as co-author as opposed to replacing the existing author, even if you
> | > | > have rewritten it. If this were a separate new program not building on
> | > | > previous ideas, I would that it is OK.
> | > | >
> | > |
> | > | Hmm, I undersand that conventional wisdom is to err on side of giving
> | > | more credit for work than too little credit, but I find this suggestion
> | > | a little extreme.
> | >
> | > I'm not so sure.
> | >
> | > | Gaby, did you look at both programs: the new asq is a _new_ program.
> | >
> | > I read over your new "asq" and the old asq and followed your
> | > explanation, *before* I sent my mail.
> | >
> | > My opinion is that your name should be added co-author, not replace
> | > the original author.  Or, call the program something else and

                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> | > acknowledge that this new program greatly benefited from the existing
> | > one, in particular from its documentation and its errors. But having
> | > two proram doing almost the same thing will be very confusing.  So, I
> | > believe the conventional wisdom is good here.
> | >
> |
> | I fail to see how filename affects authorship status of a file.
> 
> Me enither.  Why do you think it has anything to do with this?
> 

How should I read what you wrote above? (I the place marked by ^ signs).

> [...]
> 
> | Note that I do not claim any credit for the old asq program.
> 
> Yes, and listing only your name as author implies claiming credits.
> 

I do claim credit for the new file.

> Put blunt, I think you did a grave act of violence by replacing
> the existing asq.c with the new one witout explicit acknowlegement as
> co-author (which I believe is the correct thing), and  acknowledgment
> section that traces the history of asq.c.
>

I am shocked by your words.  For me "author" has clear meaning: 
somebody who wrote the work or nontrivial part of it or at least had
significant influence on the shape of the work.  I somebody replaced
something that I wrote by new thing but kept my name as an author
I would probably ask to romove my name -- taking credit for something
taht I did not would only devaluate credits due for things that I
really did.  However, if Tim Daly feels as a coauthor of new asq
I will add his name.  But I will not do this without his explicit
permission.

Concerning acknowledgment: I did a mistake here -- I was concetrating
on technical details and forgot about it.  I would like to correct
this problem but opinions I hear from you (Gaby) and Ralph are
widely different.
 
> | I see
> | Richard Stallman mentioned as a coauthor of cpp.texi, but comparing
> | cpp.texinfo from gcc-1.35 with cpp.texi from gcc-4.1.1 I can find
> | a few passages are taken almost verbatim from the old version.
> | I would guess that careful examination would show more connections.
> | So I consider it reasonable to state that Stallman is a coauthor
> | (assuming he did wrote version contained in gcc-1.35).
> |
> | Concering programs: I did not look at preprocessor files.  But I did
> | found surprising similarities between some parts of gcc-1.35 and
> | parts of gcc-4.1.1 -- after many edits code looks very different,
> | but clearly is still the same code.
> 
> It would be very interesting to see which portions of which files you
> look at.
> 

IIRC this was in the C front end.  But I am not sure if disscusing
gcc authorship is relevant here (what you wrote above only strengthened
my impression that gcc is not a good model to follow).

The point I wanted to make is: even if evolved text/code looks quite
different from the original its form is usually significantly
influenced by original author (and in many cases this influence
can be seen).  I feel that "start from scratch" rewrite is quite
different.

\start
Date: Thu, 1 Feb 2007 16:03:47 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [426] branches/wh-sandbox

On Thu, 1 Feb 2007, Waldek Hebisch wrote:

| > | > | Gaby, did you look at both programs: the new asq is a _new_ program.
| > | >
| > | > I read over your new "asq" and the old asq and followed your
| > | > explanation, *before* I sent my mail.
| > | >
| > | > My opinion is that your name should be added co-author, not replace
| > | > the original author.  Or, call the program something else and
|
|                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| > | > acknowledge that this new program greatly benefited from the existing
| > | > one, in particular from its documentation and its errors. But having
| > | > two proram doing almost the same thing will be very confusing.  So, I
| > | > believe the conventional wisdom is good here.
| > | >
| > |
| > | I fail to see how filename affects authorship status of a file.
| >
| > Me enither.  Why do you think it has anything to do with this?
| >
|
| How should I read what you wrote above? (I the place marked by ^ signs).

Well, calling a program something else is not a matter of file-name.
You could very well put your codes in the *same* file asq.c, while
retaining the previous.   But, that is not what is not.  You have
*replaced* the existing one.

[...]

| I am shocked by your words.  For me "author" has clear meaning:
| somebody who wrote the work or nontrivial part of it or at least had
| significant influence on the shape of the work.  I somebody replaced
| something that I wrote by new thing but kept my name as an author
| I would probably ask to romove my name

yes, but I had not seen you putting Tim's name as co-author and he
asking for taking his name out.  And in this case, I do believe that
Tim's initial effort and continued documentation (even not perfet,
e.g. duplication) does contribute  substantially to the new code.

I just think we should not refrain for giving enough credits if we
ever want the place to be collegial and attracts more people.
This is my last word on this; I've said where I stand.

[...]

| > | I see
| > | Richard Stallman mentioned as a coauthor of cpp.texi, but comparing
| > | cpp.texinfo from gcc-1.35 with cpp.texi from gcc-4.1.1 I can find
| > | a few passages are taken almost verbatim from the old version.
| > | I would guess that careful examination would show more connections.
| > | So I consider it reasonable to state that Stallman is a coauthor
| > | (assuming he did wrote version contained in gcc-1.35).
| > |
| > | Concering programs: I did not look at preprocessor files.  But I did
| > | found surprising similarities between some parts of gcc-1.35 and
| > | parts of gcc-4.1.1 -- after many edits code looks very different,
| > | but clearly is still the same code.
| >
| > It would be very interesting to see which portions of which files you
| > look at.
| >
|
| IIRC this was in the C front end.

As I said, the C preproprocessor is a different component now,
separate from the C-family front-ends, with the integration done with
the parser -- instead of through temporary files as in the past.
Look at libcpp/.

| But I am not sure if disscusing
| gcc authorship is relevant here (what you wrote above only strengthened
| my impression that gcc is not a good model to follow).

I'm not sure.  People contributing new components get their names in.
Others, such as Richard Henderson, are so universally recognized that
they don't think they need to put down their names :-)

\start
Date: Thu, 1 Feb 2007 14:12:26 -0800 (PST)
From: Cliff Yapp
To: Gabriel Dos Reis, Waldek Hebisch
Subject: Re: axiom: [426] branches/wh-sandbox

--- Gabriel Dos Reis wrote:

> Put blunt, I think you did a grave act of violence by replacing
> the existing asq.c with the new one witout explicit acknowlegement as
> co-author (which I believe is the correct thing), and  acknowledgment
> section that traces the history of asq.c.

In the interests of keeping this discussion productive, can anyone
point to an established (and insofar as is possible objective) standard
for evaluating when co-authorship credit should be awarded and when an
effort is sufficiently new to warrant sole authorship with a history? 
I don't suppose simply diffing the files and looking for some minimum %
changed would be enough, but is there some relatively objective
criteria that can be established here to avoid friction?
 
I understand credit is something people feel strongly about,
particularly in an academic and open source enviornment, so I think it
would be beneficial to have some policy in this regard.  I suspect this
situation is a bit unique - normally academic papers are not
sufficently direct in lineage to provoke a discussion on whether
authors of previous work should have co-authorship credit in the new. 
If we treat Axiom in this fasion (literate programming and whatnot), I
would say the old pamphlet should be cited in appropriate places in the
new one in academic style (after all, if you want to re-use a graph
from an old paper, say in a thesis, you get and include permission and
then cite the source).  An Axiom journal would be a major asset in this
respect, as new versions of pamphlets could be published in one section
of it and become true citable papers.

It's actually a bit of an interesting problem, because we don't want to
dilute authorship credits to the point of not being useful (which
author do you contact if a work lists twenty, and it turns out sixteen
of them worked only on previous versions and don't know anything about
the new one?)  Even in regular computer science channels, there tends
to be a paper published that doesn't directly involve the source code -
really using the literate programming paradigm (where a paper building
on previous work to produce a better result will not just reference
other work but actually include it as part of the foundation on which
they are building subsequent work, as in this case) seems to introduce
some rather unique problems and deserves some careful consideration
about what practices should be used.

One thought might be to include certain "metadata" in the chunck
structure which could be used to automatically add citations and
credits - if we make an emacs mode (say) that when it reads an Axiom
pamphlet parses the metadata and tracks what is changed - then each
chunck knows who changed it and who didn't, and can automatically
produce citation links on that basis (for example, a code block that
survives unchanged through 4 major pamphlet revisions need only refer
to the original, since that is where it came from.)  Maybe one of the
many source code management systems we have available could even
automate this feature based on commit diffs and who is commiting?  Then
the question of "who wrote what" can be quickly and definitively
answered.  If desirable there could be some "primary authorship"
decided based on how much of the current code is new compared to
previous versions.  Peer review could be used to override abuses of the
system (for example, making unnecessary and trivial changes in enough
parts of the code to claim primary authorship.)

Imperfect ideas I'm sure, but maybe someone else has something better
to suggest?

\start
Date: Thu, 1 Feb 2007 18:18:43 -0500
From: Alfredo Portes
To: Cliff Yapp
Subject: Re: axiom: [426] branches/wh-sandbox
Cc: Gabriel Dos Reis

> One thought might be to include certain "metadata" in the chunck
> structure which could be used to automatically add citations and
> credits - if we make an emacs mode (say) that when it reads an Axiom
> pamphlet parses the metadata and tracks what is changed - then each
> chunck knows who changed it and who didn't, and can automatically
> produce citation links on that basis (for example, a code block that
> survives unchanged through 4 major pamphlet revisions need only refer
> to the original, since that is where it came from.)  Maybe one of the
> many source code management systems we have available could even
> automate this feature based on commit diffs and who is commiting?  Then
> the question of "who wrote what" can be quickly and definitively
> answered.  If desirable there could be some "primary authorship"
> decided based on how much of the current code is new compared to
> previous versions.  Peer review could be used to override abuses of the
> system (for example, making unnecessary and trivial changes in enough
> parts of the code to claim primary authorship.)

I know that this is not the current development process, but I think
Tim has explained before that in the pamphlet, when you correct
errors, modify or add, you should leave the old code as not used chunk
and add the new code explaining how it improves the old code, and it
serves like Gaby said to keep a history of the changes.

\start
Date: Thu, 1 Feb 2007 19:31:29 -0600
From: Tim Daly
To: list
Subject: authorship

I really hate to enter this debate because, apparently I'm at the
center of it. But there has been a policy of authorship and credit
in Axiom, although I probably never stated it clearly in one place.

I've held forth on the subject of authorship and/or credit in
Axiom before, for instance,

<http://lists.gnu.org/archive/html/axiom-developer/2003-08/msg00058.html>

Being a second-string academic all my life I've had a great deal
of experience with the topic, not all good.

I spent 19 years at IBM Research where "credit" is the coin of the
realm, so to speak. I remember spending years on a project, having
written a reasonable portion of the software, most of the tools, and a
large portion of a user's guide with 3 other people. The copy of the
guide I still have has 4 names on the cover. The DAY after I left the
project the guide was changed to exclude my name. I have a copy of the
"new" guide which is character-by-character the same except for my
name on the cover. 

I also worked on a patent, which my notes (prior to joining IBM) show
as my idea only to have my name excluded from the patent application.

I also generated an idea, did the background research and wrote the
code to demonstrate the idea but when the paper was written and
submitted my name was nowhere to be found. (Names and identifying
details withheld, despite my policy of "liberal credit sharing" :-) ). 

I spent years on another project which I rewrote in common lisp despite
protest (worse, a reprimand). The final project was shipped as common
lisp. The project generated a couple awards of $20,000 each. My name
was not mentioned in the announcement and I did not see a single
dollar of the cash.

Such events, no matter how well rationalized, always feel wrong.

I joined the scratchpad project and a few years later it was to
be sold. I spent time over several months trying to dig up the name
of everyone associated with the project. I put their name on the
documentation and I added a )credit function to the top level command
line of Axiom. I'm certain you don't know most of these people and
you do not know the roles they played in Axiom's history. 

When Axiom was released as free software and I rewrote it into the
current literate form I originally claimed that the author of every
work was Nicolas Bourbaki, thinking that was a clever reference to
a mythical mathematician. I was later informed that this is an official
society in France and changed every author to "The Axiom Team".

<html://lists.gnu.org/archive/html/axiom-developer/2003-08/msg00062.html>

Later the "Axiom Team" idea bothered me as there were files for which
I clearly knew the author(s). Their names should be on the work.
I spent time trying to discover or guess the probable author
of each of the nearly 400 files.

Volume 1, the Tutorial book, includes a page that has the name of
everyone who contributed to Axiom up to that time, as far as I know.

The role is not important, it's the effort that counts. There are
people who are listed as contributors and/or authors where the current
work no longer contains a single line of code or documentation. But
they were the original authors. 

I've just gotten permission to use portions of Joel Moses' work 
as part of the documentation effort I'm doing for integration.
It may be that after reformating/editing/rewriting/rethinking
the whole effort there may not be a single line of text that
comes from his original contribution. Yet clearly Joel will be
listed as an author. Authorship is ideas as well as text. And
it is important. So important, in fact, that credit was the ONLY
request made in exchange for his generous contribution.

When considering the issue of authorship and credit ask yourself what
happens when, in 30 years, Axiom contains not a single line of code or
text that you wrote. Are you still an author? Should you still be in
the credit list? Is it meaningful for co-authorship to exist between
people who are 30 years apart in time? Does it hurt to share
authorship or credit? Is ``diff'' the golden standard?

As a matter of (my) policy it has been the case that the most liberal
guidelines were used for authorship and credit. I believe this tradition
should continue.

\start
Date: Thu, 1 Feb 2007 22:25:18 -0500
From: Bill Page
To: Francois Maltey
Subject: RE: Tests of sage.

Francois,

Thank you for testing this.

I have been able to reproduce this problem. The same thing
happens to me. I am looking into the problem and I will let
you know a solution soon.

Regards,
Bill Page.

On January 31, 2007 9:31 AM Francois Maltey wrote:
> 
> Many thanks for your pretty mail, Bill :
> 
> > Please see the examples at:
> > 
> > http://sage-notebook.axiom-developer.org/axiom
> > 
> > I would be happy to answer any questions you have.
> 
> So I download sage (a 130 MB file), untar and make the system.
>

What version of Sage did you download? As far as I can see the
most recent version of Sage (version 2.0) is "only" about 88 Mb.

http://modular.math.washington.edu/sage/dist/src/index.html

or

http://sage.scipy.org/sage/dist/src/index.html

I just finished downloading, untar and make of Sage-2.0 on a
OpenSuSE 10.2 linux system.
 
> As root I add axiom binary in the $PATH, 
> and add also the main sage directory in the $PATH.
> 
> I can run axiom -nox -nocle in a root-xterm.
>

On my system I have Axiom built from a recent version of the
build-improvements branch.
 
> As root I can run sage everywhere 
> run install_scripts('/usr/local/bin') in sage, 
> and lauch notebook()
> 
> In x11 I open http://localhost:8000 with firefox.
> I get the screen of the sage system.
> I can type commands in bluebox.
> 
> But I almost never obtain any results. 

Make sure to press Shift+Enter to execute the contents of
the bluebox.

> Neither without system when I test 2*3
> neither for axiom when I type in two lines %axiom \\ 2+3.
>

I have very similar problems. But if I only enter Sage
commands, everything seems to work. If I try Axiom commands
then it fails. I see an error traceback in the Sage session
log. These same commands work properly on the Sage server
which is apparently running the same version of Sage but a
different version of Axiom.
 
> Return adds a break-line.

Use Shift+Enter to execute a cell.

> Evaluate rerun the session but result remains green box.
> 
> What I forget ?
> 

I think you are doing everything correct. There seems to be
some problem with Sage and/or Axiom. I recall that I had some
problem with readline when I first tested this and I am quite
sure that the 'axiom4sage-0.1.spkg' that is used on the Sage
server was built using gcl with readline disabled. I will
check this and get back to you.

\start
Date: Fri, 2 Feb 2007 15:03:29 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: authorship

Tim Daly wrote: 
> When considering the issue of authorship and credit ask yourself what
> happens when, in 30 years, Axiom contains not a single line of code or
> text that you wrote. Are you still an author? Should you still be in
> the credit list? Is it meaningful for co-authorship to exist between
> people who are 30 years apart in time? Does it hurt to share
> authorship or credit? Is ``diff'' the golden standard?
> 

I distinguish authorship and credit: calculus texbooks develop build
on ideas of Newton and Leibnitz (and many have structure similar to
19-century French texts) -- they acknowledge the intelectual acnestors,
but the authors of previous works are not authors of new ones.

Diff is not "the golden standard": it can be easily fooled by reformatting
or trivial changes, IMHO it is importat if structure of original work
remains (translation into another language may change every word, but
preserves structure).

I think that authors should be comfortable with the idea that work
that at one time was useful/important gets replaced by newer works.
If part that I wrote  is replaced by something new I am no longer
author of the new part, when the whole work changes enough I am no
longer author of the new work.  That does not diminsh credit for past
work.  In the mailing list archive (close to the links you gave)
I found the following passage written by Matt Kaufmann:

----
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).
----

So now authors of ACL2 are Kaufmann and Moore, while Boyer contribution
is acknowledged, but he is no longer considered as an author -- that
looks right for me.

> As a matter of (my) policy it has been the case that the most liberal
> guidelines were used for authorship and credit. I believe this tradition
> should continue.
> 


I wrote (in response to Gaby, cc-ed to you):
| For me "author" has clear meaning:
|  somebody who wrote the work or nontrivial part of it or at least had
| significant influence on the shape of the work.  I somebody replaced
| something that I wrote by new thing but kept my name as an author
| I would probably ask to romove my name -- taking credit for something
| that I did not would only devaluate credits due for things that I
| really did.  However, if Tim Daly feels as a coauthor of new asq
| I will add his name.  But I will not do this without his explicit
| permission.

Tim, you have indirectly answered my question.  But I have to 
ask you explicitly:  Do you agree to have your name in \author
field (as opposed to being mentioned in credits/acknowledments
section) of the asq.c.pamplet file commited to wh-sandbox
branch.  If you want to know more about this file I described
how this file took current shape in:

http://lists.gnu.org/archive/html/axiom-developer/2007-02/msg00005.html

and

http://lists.gnu.org/archive/html/axiom-developer/2007-02/msg00008.html

\start
Date: Fri, 2 Feb 2007 15:23:09 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [427] branches/wh-sandbox

> On Thu, 1 Feb 2007 Waldek Hebisch wrote:
> 
> | +	* src/interp/setq.lisp.pamphlet: Turn on pretty printing.
> 
> I think this should go on build-improvements too.
> There is no single day, here, where I haven't set *print-pretty* when
> dumping.
> 

Do you want just setq part (this is one-liner) below, or do you
also want nicely printed databases?  Database part needs my older
change '*do-not-compress-databases*' variable and would brake asq
(asq in wh-sandbox tolerates uncompressed/prettyprinted databases).


diff -ru --exclude=.svn wh-sandbox2/src/interp/setq.lisp.pamphlet ../wh-sandbox2/src/interp/setq.lisp.pamphlet
--- wh-sandbox2/src/interp/setq.lisp.pamphlet	2006-12-03 04:23:54.000000000 +0100
+++ ../wh-sandbox2/src/interp/setq.lisp.pamphlet	2007-01-30 23:11:50.000000000 +0100
@@ -185,7 +185,7 @@
 ;; Common lisp control variables
 ;;(setq *load-verbose* nil)
 (setq *print-array* nil)
-(setq *print-pretty* nil)
+(setq *print-pretty* t)
 (setq *print-circle* nil)
 
 ;; $SYSCOMMANDS is now defined at the top of i-syscmd.boot

\start
Date: 02 Feb 2007 10:13:28 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: authorship

Waldek Hebisch writes:

[...]

| Tim, you have indirectly answered my question.  But I have to 
| ask you explicitly:  Do you agree to have your name in \author
| field (as opposed to being mentioned in credits/acknowledments
| section) of the asq.c.pamplet file commited to wh-sandbox
| branch.

I'm sorry to say it this way: this is getting insane.

\start
Date: Fri, 2 Feb 2007 12:57:04 -0600
From: Tim Daly
To: Waldek Hebisch
Subject: authorship

Well, I've been reasonably clear about what I believe the Axiom
policy should be and my opinion of what is a reasonable course.

Since I do all merges by hand, when I got to the line that does
the \author merge I would jointly list the authorship of all of
the prior people with all of the new people, quite independent
of the fact that my name is involved.

You chose to "modify" the file rather than replace the file
so in the main line merge I'd have over-ridden your choice
of \author line and changed it to read (in alphabetical order):

\author{Timothy Daly and Waldek Hebisch}

If you, or anyone feels, that they should have sole authorship
the simple solution is to create a new source filename and then 
modify the build script to drop the old file and use the new one.
The build script could compile "newasq.pamphlet" into the bin/asq
function and all would still work. When merging the new file the
issue would not arise and the new file would retain sole authorship.

I have no feelings either way about asq. Indeed, I hadn't noticed
anything until it was mentioned. I do my best not to "own" programs or
keep emotional attachments to them, both of which tend to cause friction
in the open source model.

\start
Date: Fri, 2 Feb 2007 20:40:24 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: authorship

> Well, I've been reasonably clear about what I believe the Axiom
> policy should be and my opinion of what is a reasonable course.
> 
> Since I do all merges by hand, when I got to the line that does
> the \author merge I would jointly list the authorship of all of
> the prior people with all of the new people, quite independent
> of the fact that my name is involved.
> 
> You chose to "modify" the file rather than replace the file
> so in the main line merge I'd have over-ridden your choice
> of \author line and changed it to read (in alphabetical order):
> 
> \author{Timothy Daly and Waldek Hebisch}
> 

OK, so I am now putting the above in wh-sandbox version.

\start
Date: Sat, 03 Feb 2007 15:13:58 +0100
From: Gregory Vanuxem
To: list
Subject: series2.output

Hello,

Can someone send me the generated output of the input file
series2.input, which is in src/input ? I have a problem with GCL, so I
tested under Windows where this problem doesn't seem present but I need
to be sure of these results. 

\start
Date: Sat, 03 Feb 2007 16:22:24 +0100
From: Gregory Vanuxem
To: list
Subject: Re: series2.output

Forget my request... There is MathAction :-)

\start
Date: Sat, 03 Feb 2007 16:37:40 +0100
From: Gregory Vanuxem
To: list
Subject: Re: series2.output

There is a apparently a problem in the Build-improvements branch or may
be in GCL, I have no idea (I can reproduce the following on MathAction
(build-improvements)):

=======================================================================
Gold:

(2) -> f:=taylor(1-x^2)

             2
   (2)  1 - x
                   Type: UnivariateTaylorSeries(Expression Integer,x,0)
(3) -> sin asin f

             2      11
   (3)  1 - x  + O(x  )
========================================================================
Build-improvements:
========================================================================
(11) -> f:=taylor(1-x^2)

              2
   (11)  1 - x
                  Type: UnivariateTaylorSeries(Expression Integer,x,0)

(12) -> sin asin f

             1  4    1  6    7   8     5   10      11
   (12)  1 - - x  - -- x  - --- x  - ---- x   + O(x  )
             4      16      768      3072
                  Type: UnivariateTaylorSeries(Expression Integer,x,0)
========================================================================

etc... (see series2.input)

\start
Date: Sat, 3 Feb 2007 18:05:52 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: series2.output

> There is a apparently a problem in the Build-improvements branch or may
> be in GCL, I have no idea (I can reproduce the following on MathAction
> (build-improvements)):
> 
> =======================================================================
> Gold:
> 
> (2) -> f:=taylor(1-x^2)
> 
>              2
>    (2)  1 - x
>                    Type: UnivariateTaylorSeries(Expression Integer,x,0)
> (3) -> sin asin f
> 
>              2      11
>    (3)  1 - x  + O(x  )
> ========================================================================
> Build-improvements:
> ========================================================================
> (11) -> f:=taylor(1-x^2)
> 
>               2
>    (11)  1 - x
>                   Type: UnivariateTaylorSeries(Expression Integer,x,0)
> 
> (12) -> sin asin f
> 
>              1  4    1  6    7   8     5   10      11
>    (12)  1 - - x  - -- x  - --- x  - ---- x   + O(x  )
>              4      16      768      3072
>                   Type: UnivariateTaylorSeries(Expression Integer,x,0)
> ========================================================================
> 

AFAICS this is bug 312 in action.  This bug appeared as a byproduct
of fix for bug 63.  Igor Khavkine found the wrong place and proposed
a fix, wh-sandbox contains slightly different fix.

\start
Date: Sat, 03 Feb 2007 18:31:53 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: series2.output

Le samedi 03 f=E9vrier 2007 =E0 18:05 +0100, Waldek Hebisch a =E9crit :
> > There is a apparently a problem in the Build-improvements branch or m=
ay
> > be in GCL, I have no idea (I can reproduce the following on MathActio=
n
> > (build-improvements)):
> >
> > ========================
==========================
=======================
> > Gold:
> >
> > (2) -> f:=taylor(1-x^2)
> >
> >              2
> >    (2)  1 - x
> >                    Type: UnivariateTaylorSeries(Expression Integer,x,=
0)
> > (3) -> sin asin f
> >
> >              2      11
> >    (3)  1 - x  + O(x  )
> > ========================
==========================
========================
> > Build-improvements:
> > ========================
==========================
========================
> > (11) -> f:=taylor(1-x^2)
> >
> >               2
> >    (11)  1 - x
> >                   Type: UnivariateTaylorSeries(Expression Integer,x,0=
)
> >
> > (12) -> sin asin f
> >
> >              1  4    1  6    7   8     5   10      11
> >    (12)  1 - - x  - -- x  - --- x  - ---- x   + O(x  )
> >              4      16      768      3072
> >                   Type: UnivariateTaylorSeries(Expression Integer,x,0=
)
> > ========================
==========================
========================
> >
>
> AFAICS this is bug 312 in action.  This bug appeared as a byproduct
> of fix for bug 63.  Igor Khavkine found the wrong place and proposed
> a fix, wh-sandbox contains slightly different fix.

Yes you're right, my version of Gold contains the Igor Kahvkine's patch.
Will look in your patches (on my BIG TODO list).

\start
Date: Sat, 03 Feb 2007 15:41:57 -0500
From: William Sit
To: list
Subject: How to allocate more space for Axiom on Windows

I was trying to solve a homogeneous parametric linear system
(9 by 9) with 18 parameters that Dhagash Mehta
<dhagash.mehta@adelaide.edu.au> recently sent me. The
coefficient matrix is:

(1) -> )library PLEQN
   ParametricLinearEquations is now explicitly exposed in
frame initial
   ParametricLinearEquations will be automatically loaded
when needed
(2) -> amat := [[-a[1, 2, 1, 1] - a[2, 1, 1, 1] - b[1, 1, 1,
3] - b[1, 1, 3, 1],
 a[1, 2, 1, 1], -b[1, 1, 1, 3], a[2, 1, 1, 1], 0, 0, -b[1,
1, 3, 1], 0, 0],_
  [a[1, 2, 1, 1], -a[1, 2, 1, 1] - a[1, 3, 1, 2] - a[2, 2,
1, 2] - b[1, 2, 3,2],
 a[1, 3, 1, 2], 0, a[2, 2, 1, 2], 0, 0, -b[1, 2, 3, 2], 0],_

  [-b[1, 1, 1, 3], a[1, 3, 1, 2], -a[1, 3, 1, 2] - a[2, 3,
1, 3] - b[1, 1, 1, 3]
- b[1, 3, 3, 3], 0, 0, a[2, 3, 1, 3], 0, 0, -b[1, 3, 3,
3]],_
  [a[2, 1, 1, 1], 0, 0, -a[2, 1, 1, 1] - a[2, 2, 2, 1] -
a[3, 1, 2, 1] - b[2, 1,
2, 3], a[2, 2, 2, 1], -b[2, 1, 2, 3], a[3, 1, 2, 1], 0, 0],_

  [0, a[2, 2, 1, 2], 0, a[2, 2, 2, 1], -a[2, 2, 1, 2] - a[2,
2, 2, 1] - a[2, 3,2
, 2] - a[3, 2, 2, 2], a[2, 3, 2, 2], 0, a[3, 2, 2, 2], 0],_
  [0, 0, a[2, 3, 1, 3], -b[2, 1, 2, 3], a[2, 3, 2, 2], -a[2,
3, 1, 3] - a[2, 3,2
, 2] - a[3, 3, 2, 3] - b[2, 1, 2, 3], 0, 0, a[3, 3, 2, 3]],_

  [-b[1, 1, 3, 1], 0, 0, a[3, 1, 2, 1], 0, 0, -a[3, 1, 2, 1]
- a[3, 2, 3, 1] -b[
1, 1, 3, 1] - b[3, 1, 3, 3], a[3, 2, 3, 1], -b[3, 1, 3,
3]],_
  [0, -b[1, 2, 3, 2], 0, 0, a[3, 2, 2, 2], 0, a[3, 2, 3, 1],
-a[3, 2, 2, 2] -a[3
, 2, 3, 1] - a[3, 3, 3, 2] - b[1, 2, 3, 2], a[3, 3, 3, 2]],_

  [0, 0, -b[1, 3, 3, 3], 0, 0, a[3, 3, 2, 3], -b[3, 1, 3,
3], a[3, 3, 3, 2],-a[3
, 3, 2, 3] - a[3, 3, 3, 2] - b[1, 3, 3, 3] - b[3, 1, 3,
3]]];

(2) -> psolve(amat)

   >> System error:
   The storage for CONS is exhausted.
Currently, 82689 pages are allocated.
Use ALLOCATE to expand the space.

Can any one tell me how to increase the space? Exactly how
big is one page? I have 2GB RAM. Is it possible to allocate
the max to Axiom (under Windows XP)?

\start
Date: Sat, 03 Feb 2007 16:02:13 -0500
From: William Sit
To: list
Subject: Re: How to allocate more space for Axiom on Windows

On Sat, 03 Feb 2007 15:41:57 -0500
  William Sit wrote:
>    >> System error:
>    The storage for CONS is exhausted.
>Currently, 82689 pages are allocated.
>Use ALLOCATE to expand the space.
>
>Can any one tell me how to increase the space? Exactly 
>how
>big is one page? I have 2GB RAM. Is it possible to 
>allocate
>the max to Axiom (under Windows XP)?
>
Let me add that on my system, the XP OS normally used 
about under 800 MB with multiple programs open. When Axiom 
started the CPU monitor shows 770MB and when the command 
psolve(amat) started, the memory usage rose all the way to 
about 1.20 GB and then quit. So there is plenty of 
physical RAM left (not to mention virtual RAM). I repeated 
this and Axiom aborted with:

    >> System error:
    The storage for CONS is exhausted.
Currently, 97956 pages are allocated.
Use ALLOCATE to expand the space.

protected-symbol-warn called with (NIL)

\start
Date: Sat, 3 Feb 2007 22:25:47 +0100 (CET)
From: Waldek Hebisch
To: William Sit
Subject: Re: How to allocate more space for Axiom on Windows

William Sit wrote:
>    >> System error:
>    The storage for CONS is exhausted.
> Currently, 82689 pages are allocated.
> Use ALLOCATE to expand the space.
> 
> Can any one tell me how to increase the space? Exactly how
> big is one page? I have 2GB RAM. Is it possible to allocate
> the max to Axiom (under Windows XP)?
> 

Have you tried to follow the advice:

)lisp (allocate 'cons 200000 t)

(Or some bigger number instead of 200000).  Using gcl 2.6.7 I can
maximally give 110000 (120000 is refused, few numbers between crashed
gcl).  Using gcl 2.6.8 I can give bigger values.  Typically page 
means 4 kilobytes, that would agree with process size (empty Axiom
about 80 Mb, around 900 Mb after allocating 200000 pages).

\start
Date: Sat, 03 Feb 2007 22:39:05 +0100
From: Gregory Vanuxem
To: William Sit
Subject: Re: How to allocate more space for Axiom on Windows

Le samedi 03 f=E9vrier 2007 =E0 16:02 -0500, William Sit a =E9crit :
> On Sat, 03 Feb 2007 15:41:57 -0500
>   William Sit wrote:
> >    >> System error:
> >    The storage for CONS is exhausted.
> >Currently, 82689 pages are allocated.
> >Use ALLOCATE to expand the space.
> >
> >Can any one tell me how to increase the space? Exactly
> >how
> >big is one page?

4096 bytes (1 << 12)

)lis (room) will tell you the number of page availables. This is fixed
at compile time so if you have compiled with the default options you'll
be limited to 512Mo (and I don't know exactly the memory organisation,
Camm could tell you, but you'll not be able I think to allocate all the
space for cons since there are contiguous pages, relocatable pages ...).

You can use the function allocate:

-- Function: ALLOCATE (type number &optional (really-allocate nil))
     Package:LISP

     GCL specific: Sets the maximum number of pages for the type class
     of the GCL implementation type TYPE to NUMBER.  If REALLY-ALLOCATE
     is given a non-NIL value, then the specified number of pages will
     be allocated immediately.

>(room)

   434/434    47.5%         CONS BIGNUM RATIO COMPLEX STRUCTURE
     7/45     76.9%         FIXNUM SHORT-FLOAT LONG-FLOAT CHARACTER
RANDOM-STATE READTABLE SPICE
   154/736    85.6%         SYMBOL STREAM PATHNAME CCLOSURE CLOSURE
     1/2      23.9%         PACKAGE
     2/59     21.2%         ARRAY HASH-TABLE VECTOR BIT-VECTOR
    21/33     97.9%         CFUN CFDATA
    45/59     99.1%         SFUN STRING GFUN VFUN AFUN

   805/2215                 contiguous (125 blocks)
       26214                hole
       10485   0.0%         relocatable

       664 pages for cells
     38168 total pages
    202532 pages available
     21444 pages in heap but not gc'd + pages needed for gc marking
    262144 maximum pages

>(allocate 'cons 512)

T

>(room)

   434/512    48.8%         CONS BIGNUM RATIO COMPLEX STRUCTURE
     7/45     81.7%         FIXNUM SHORT-FLOAT LONG-FLOAT CHARACTER
RANDOM-STATE READTABLE SPICE
   154/736    85.6%         SYMBOL STREAM PATHNAME CCLOSURE CLOSURE
     1/2      23.9%         PACKAGE
     2/59     21.2%         ARRAY HASH-TABLE VECTOR BIT-VECTOR
    21/33     97.9%         CFUN CFDATA
    45/59     99.4%         SFUN STRING GFUN VFUN AFUN

   805/2215                 contiguous (120 blocks)
       26214                hole
       10485   0.0%         relocatable

       664 pages for cells
     38168 total pages
    202532 pages available
     21444 pages in heap but not gc'd + pages needed for gc marking
    262144 maximum pages


Greg

----------------------------------------------------------------------
Random documentation (under LGPL I think):


-- Variable: *IGNORE-MAXIMUM-PAGES*
     Package:SI GCL specific: Tells the GCL memory manager whether
     (non-NIL) or not (NIL) it should expand memory whenever the
     maximum allocatable pages have been used up.


-- Variable: *OPTIMIZE-MAXIMUM-PAGES*
     Package:SI

     GCL specific: Tells the GCL memory manager whether to attempt to
     adjust the maximum allowable pages for each type to approximately
     optimize the garbage collection load in the current process.
     Defaults to T.  Set to NIL if you care more about memory usage
     than runtime.

-- Function: GBC (x)
     Package:LISP

     GCL specific: Invokes the garbage collector (GC) with the
     collection level specified by X.  NIL as the argument causes GC to
     collect cells only.  T as the argument causes GC to collect
     everything.

-- Function: MAXIMUM-CONTIGUOUS-PAGES ()
     Package:SI

     GCL specific: Returns the current maximum number of pages for
     contiguous blocks.


-- Function: GET-HOLE-SIZE ()
     Package:SI

     GCL specific: Returns as a fixnum the size of the memory hole (in
     pages).

-- Function: ALLOCATE-CONTIGUOUS-PAGES (number &optional
          (really-allocate nil))
     Package:SI

     GCL specific: Sets the maximum number of pages for contiguous
     blocks to NUMBER.  If REALLY-ALLOCATE is non-NIL, then the
     specified number of pages will be allocated immediately.

-- Function: MAXIMUM-ALLOCATABLE-PAGES (type)
     Package:SI

     GCL specific: Returns the current maximum number of pages for the
     type class of the GCL implementation type TYPE.

-- Function: ALLOCATED-RELOCATABLE-PAGES ()
     Package:SI

     GCL specific: Returns the number of pages currently allocated for
     relocatable blocks.

-- Function: MAXIMUM-CONTIGUOUS-PAGES ()
     Package:SI

     GCL specific: Returns the current maximum number of pages for
     contiguous blocks.


-- Function: GET-HOLE-SIZE ()
     Package:SI

     GCL specific: Returns as a fixnum the size of the memory hole (in
     pages).

-- Function: SET-HOLE-SIZE (fixnum)
     Package:SI

     GCL specific: Sets the size of the memory hole (in pages).

-- Funcition: ALLOCATED (type)
     Package:SI

     Returns 6 values:
    nfree
          number free

    npages
          number of pages

    maxpage
          number of pages to grow to

    nppage
          number per page

    gbccount
          number of gc's due to running out of items of this size

    nused
          number of items used

     Note that all items of the same size are stored on similar pages.
     Thus for example on a 486 under linux the following basic types are
     all the same size and so will share the same allocated information:
     CONS BIGNUM RATIO COMPLEX STRUCTURE.

-- Variable: *LISP-MAXPAGES*
     Package:SI GCL specific: Holds the maximum number of pages (1 page
     = 2048 bytes) for the GCL process.  The result of changing the
     value of SI:*LISP-MAXPAGES* is unpredictable.

-- Variable: *MULTIPLY-STACKS*
     Package:SI

     If this variable is set to a positive fixnum, then the next time
     through the TOP-LEVEL loop, the loop will be exited.  The size of
     the stacks will be multiplied by the value of *multiply-stacks*,
     and the TOP-LEVEL will be called again.  Thus to double the size
     of the stacks:

     >(setq si::*multiply-stacks* 2) [exits top level and reinvokes it,
     with the new stacks in place] >

     We must exit TOP-LEVEL, because it and any other lisp functions
     maintain many pointers into the stacks, which would be incorrect
     when the stacks have been moved.    Interrupting the process of
     growing the stacks, can leave you in an inconsistent state.


-- Function: ALLOCATE-GROWTH (type min max percent percent-free)
     Package:SI

     The next time after a garbage collection for TYPE, if PERCENT-FREE
     of the objects of this TYPE are not actually free, and if the
     maximum number of pages for this type has already been allocated,
     then the maximum number will be increased by PERCENT of the old
     maximum, subject to the condition that this increment be at least
     MIN pages and at most MAX pages.  A list of the previous values
     for min, max, percent, and percent-free for the type TYPE is
     returned.   A value of 0 means use the system default,  and if an
     argument is out of range then the current values are returned with
     no change made.

     Examples: (si::allocate-growth 'cons 1 10 50 10) would insist that
     after a garbage collection for cons, there be at least 10% cons's
     free.   If not the number of cons pages would be grown by 50% or
     10 pages which ever was smaller.   This might be reasonable if you
     were trying to build an image which was `full', ie had few free
     objects of this type.

     (si::allocate-growth 'fixnum 0 10000 30 40) would grow space till
     there were normally 40% free fixnums, usually growing by 30% per
     time.

     (si::allocate-growth 'cons 0 0 0 40) would require 40% free conses
     after garbage collection for conses, and would use system defaults
     for the the rate to grow towards this goal.

     (si::allocate-growth 'cons -1 0 0 0) would return the current
     values, but not make any changes.


> I have 2GB RAM. Is it possible to
> >allocate
> >the max to Axiom (under Windows XP)?
> >
> Let me add that on my system, the XP OS normally used
> about under 800 MB with multiple programs open. When Axiom
> started the CPU monitor shows 770MB and when the command
> psolve(amat) started, the memory usage rose all the way to
> about 1.20 GB and then quit. So there is plenty of
> physical RAM left (not to mention virtual RAM). I repeated
> this and Axiom aborted with:
>
>     >> System error:
>     The storage for CONS is exhausted.
> Currently, 97956 pages are allocated.
> Use ALLOCATE to expand the space.
>
> protected-symbol-warn called with (NIL)

\start
Date: Sun, 04 Feb 2007 04:08:03 -0500
From: William Sit
To: Waldek Hebisch
Subject: Re: How to allocate more space for Axiom on Windows

Thanks, Waldek. I tried as you suggested; the allocate produces a system
error unless I use a very small number. Nonetheless, the CONS type space
seems to have 200000 even though there is an error message.

However, when I run the computation, it stops again. So I am not sure if
I got any extra space that way (the max page is still the same) or it is
some other type of memory that needs to be increased.  I am limited to
131072 pages (using (room), as suggested by Gregory Vanuxem -- Greg,
thanks for the docs). So it looks like 512MB. I am using a precompiled
version on Windows. I have no idea what gcl I am using.

I also tried the commands from SI but the run always quit after using up
the pages (but there is still plenty of physical memory).



William

----- transcript from trials
(2) -> )lisp (ALLOCATE 'cons 200000 t))

   >> System error:
   Can't allocate 200000 pages for CONS.

protected-symbol-warn called with (NIL)
(2) -> )lisp (room)

 52815/200000   1.3%     115CONS RATIO COMPLEX STRUCTURE
    73/200    42.9%         FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE
READTABLE
NIL
   224/500    97.4%         SYMBOL STREAM
     1/8      23.1%         PACKAGE
  3651/5114    0.4%      12 ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME
CCLOSURE
 FAT-STRING
   125/500    69.7%         STRING
   100/100    12.6%       1 CFUN BIGNUM LONG-FLOAT
    34/89     99.4%         SFUN GFUN CFDATA SPICE NIL

  4293/5347               2 contiguous (234 blocks)
       2000                 hole
       9161    0.6%      38 relocatable

     57023 pages for cells
     72477 total pages
     45060 pages available
     13535 pages in heap but not gc'd + pages needed for gc marking
    131072 maximum pages
Value = NIL
(2) -> psolve(amat,9)

   >> System error:
   The storage for CONS is exhausted.
Currently, 82872 pages are allocated.
Use ALLOCATE to expand the space.

protected-symbol-warn called with (NIL)
(2) -> )lisp (room)

 82872/200000  71.5%     143CONS RATIO COMPLEX STRUCTURE
    73/200    41.8%         FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE
READTABLE
NIL
   224/500    97.3%         SYMBOL STREAM
     1/8      23.1%         PACKAGE
  5114/5114    0.3%      27 ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME
CCLOSURE
 FAT-STRING
   125/500    68.9%         STRING
   100/100    12.2%       2 CFUN BIGNUM LONG-FLOAT
    34/89     99.4%         SFUN GFUN CFDATA SPICE NIL

  4293/5347               2 contiguous (234 blocks)
       2000                 hole
       15931  30.3%      59 relocatable

     88543 pages for cells
    110767 total pages
         0 pages available
     20305 pages in heap but not gc'd + pages needed for gc marking
    131072 maximum pages
Value = NIL
(2) -> )lisp (si::allocate-growth 'cons 1 10 50 10)

Value = (0 0 0 0)
(2) -> )lisp (room)

 82872/200000  71.6%     143CONS RATIO COMPLEX STRUCTURE
    73/200    42.1%         FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE
READTABLE
NIL
   224/500    97.3%         SYMBOL STREAM
     1/8      23.1%         PACKAGE
  5114/5114    0.3%      27 ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME
CCLOSURE
 FAT-STRING
   125/500    69.3%         STRING
   100/100    12.3%       2 CFUN BIGNUM LONG-FLOAT
    34/89     99.4%         SFUN GFUN CFDATA SPICE NIL

  4293/5347               2 contiguous (234 blocks)
       2000                 hole
       15931  30.3%      59 relocatable

     88543 pages for cells
    110767 total pages
         0 pages available
     20305 pages in heap but not gc'd + pages needed for gc marking
    131072 maximum pages
Value = NIL
(2) -> psolve(amat,9)

   >> System error:
   The storage for CONS is exhausted.
Currently, 82872 pages are allocated.
Use ALLOCATE to expand the space.

protected-symbol-warn called with (NIL)

(2) -> )lisp (setq *ignore-maximum-pages* t)

Value = T
(2) -> )lisp (si::allocate-contiguous-pages 10000 t)

   >> System error:
   Can't allocate 10000 pages for contiguous blocks.

protected-symbol-warn called with (NIL)
(2) -> )lisp (room)

 82872/200000   0.8%     185CONS RATIO COMPLEX STRUCTURE
    73/200    42.1%         FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE
READTABL
NIL
   224/500    97.3%         SYMBOL STREAM
     1/8      23.1%         PACKAGE
  5114/5114    0.3%      50 ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME
CCLOSU
 FAT-STRING
   125/500    69.3%         STRING
   100/100    12.3%       2 CFUN BIGNUM LONG-FLOAT
    34/89     99.4%         SFUN GFUN CFDATA SPICE NIL

  4293/10000              3 contiguous (234 blocks)
       2000                 hole
       15931   0.3%      66 relocatable

     88543 pages for cells
    110767 total pages
         0 pages available
     20305 pages in heap but not gc'd + pages needed for gc marking
    131072 maximum pages
Value = NIL
(2) -> psolve(amat,9)

   >> System error:
   The storage for CONS is exhausted.
Currently, 82872 pages are allocated.
Use ALLOCATE to expand the space.

protected-symbol-warn called with (NIL)

-------


Waldek Hebisch wrote:

> William Sit wrote:
> >    >> System error:
> >    The storage for CONS is exhausted.
> > Currently, 82689 pages are allocated.
> > Use ALLOCATE to expand the space.
> >
> > Can any one tell me how to increase the space? Exactly how
> > big is one page? I have 2GB RAM. Is it possible to allocate
> > the max to Axiom (under Windows XP)?
> >
>
> Have you tried to follow the advice:
>
> )lisp (allocate 'cons 200000 t)
>
> (Or some bigger number instead of 200000).  Using gcl 2.6.7 I can
> maximally give 110000 (120000 is refused, few numbers between crashed
> gcl).  Using gcl 2.6.8 I can give bigger values.  Typically page
> means 4 kilobytes, that would agree with process size (empty Axiom
> about 80 Mb, around 900 Mb after allocating 200000 pages).

\start
Date: Sun, 4 Feb 2007 07:04:40 -0600
From: Tim Daly
To: list
Subject: Can you depend on it?

It's 5 a.m.  on a sunday morning and I can't sleep because I'm
suffering from flaming asshole syndrome. The person suffering from
this disease feels they know what they are talking about and needs to
enlighten the rest of the world. Today I've got it bad.

I've been programming for nearly 36 years. I'm obsessive about it. I'm
writing a program for work that translates bit streams into mathematics
(in lisp). And for a hobby, I write Axiom programs that translate
mathematics into bit streams (in lisp). When I leave work (whatever
that means, since I work from home and have no fixed hours) I swap
machines and work on Axiom. When I'm not programming, I'm reading
about programming. Of course, I don't read programs, which in some
sense makes me illiterate in my own field. But I do write them. And I
do think about how and why I write them. And how to do it right.
Especially when it concerns Axiom.




In the last 6 years I've given a lot of thought to Axiom. Where can it
go? What can it do? Will it survive? Is it worth keeping? Can people
depend on it?

Ah, that's the question for today...."Can people depend on it?".

And if they can't know the results are correct, what's the point?



I'm re-reading the Mythical Man-Month, which I do every couple years.
And I've recently read "Dreaming in Code", a book about constructing
Chandler, an open-source Personal Information Manager. I watched a
video of destructive testing of the new Boeing aircraft wing. And I'm
remembering Bill Perzley, a guy I used to work for who knew what it
meant to write quality software.

I'll take each of these unrelated components and try to tie them
together.

If you haven't read the Mythical Man-Month I cannot recommend it
enough. It brings up so many good points, like the tarpit problem,
that you need to be able to recognize. Among the many points he makes,
one key "take-away" lesson stands out for me. "Nobody knows how to
schedule software". NOBODY. Even Knuth admits it. So next time your
boss asks you for a schedule don't give him one. Because you don't
know. You can't even guess. Another take-away lesson is that
programming is a lot more than writing code. And that's what concerns
us here. More about this later.




The "Dreaming in Code" book is about a paid project pretending to be
an open source project. It is never going to complete. And it will
fail to do anything worth doing. And no-one can learn from or build
upon the results, good or bad.  It's another long, drawn out software
disaster. I've been there and I've done that. I've written whole
shelves worth of software. Some of it died because the robots that it
drove no longer exist. Some of it died because the company no longer
exists. Some of it died because .... well, because it was crap code,
which nobody but me understood and nobody could maintain. More about
this later.





Which brings me to my third reference point, the destructive testing
of Boeing's new aircraft wing. The video is on youtube and it's really
impressive to watch. The engineering team, dozens of people, is
standing around watching the bending of the wings of a brand new
Boeing aircraft until they snap. The design spec calls for surviving
150 percent of the design load. Both wings finally broke, exactly in
the wing location expected with exactly the kind of failure they
expected.... at 154% of design load. The engineering team went wild
with joy. Except for one guy. He was clearly annoyed and when asked
why he said that they were wrong by about 2.7 percent. (That's the
kind of engineer I want designing airplanes I fly.) Think about that
test. They busted up a perfectly good, multimillion dollar airplane to
test it. And they knew the answer to the test before they ran it.  You
could look up the analysis, read the documentation and rely on the
answer before they ran the test.




Which brings me to my last reference point, Bill Perzley. When I first
started working in robotics I worked on a 3 man research team. Bill
was an old man, in his mid 50s (:-) ) and was the research lead. We
had a robot that could move 200kg at several hundred inches per second
and stop within 1 encoder bit of the target location repeatably. This
was a very big, very fast, and when you made a programming mistake, a
very dangerous machine. The robot had 6 different joints and 16
kilobytes of plated-wire memory. That's 131072 bits. 

We had to teach the robot how to weld the fender of a car using a 30kg
spot welding gun while the fender was stationary. Then we had to
convert the stationary points into moving points so the robot would
weld the fender as it slid by on the assembly line. During our initial
testing a single bit value caused the robot to reach upward while the
weld gun was inside the fender. The robot lifted the weld gun, the
fender, the iron trolley, and 6 meters of steel I-beam up to the
ceiling before we could even think to hit the emergency stop button.
Fast, obedient, and dangerous.

So, Bill spends 4 MONTHS in his office smoking cigars like they were
free, banging away on a 4 function hand calculator. After 4 months he
comes out with a huge pile of A4 paper covered in zeros and ones,
131072 of them to be exact. He hands them to me, along with a pile of
mathematics. He asked me to check it over. And when I'm done to use our
memory store interface (a set of switches to choose a memory location,
set its value, and toggle a "write") to "program" the robot. He had
worked out the final location of every weld as it would appear while
the fender moved past the robot. If his calculations were correct the
robot should spot weld the fender in 24 places in real time
coordinated with the varying speed of the cart along the I-beam.

He had me "program" all 131072 bits into the robot so we could run
this test case. He wanted to see the exact results of his test and the
only way to do that was to stick his head into the wheel well of the
fender, inches from the robot and WELL within the robot's
reach. Needless to say, I was a bit nervous as a single bit mistake in
keying in the "program" could kill Bill before anybody could react.
Being the engineer that he was he stuck his head in the wheel well and
told me to start the robot. I argued with him.... 

ME:   Bill, if this is wrong it could kill you.
BILL: It's right
ME:   Bill, how do you know you didn't make a mistake?"
BILL: I checked it.
ME:   Suppose the math is wrong?
BILL: Did you check it?
ME:   Yes.

ME:   Suppose I made a mistake keying in the program.
BILL: Did you check it?
ME:   Several times.
BILL: Good. Then it works. Start the robot.

I watched the robot swing a weld gun within inches of his cigar all
along the 6 meters. And it worked, just exactly as Bill said it would.
And he KNEW it would work. Why? Because everything he did was
absolutely the best he could make it. This test, like the Boeing wing
test, was a foregone conclusion. He knew the answer before he ever
gave me the program. And I understood everything he did because he
wrote it all down in detail. You could bet your life on the result.



Now, what's this all got to do with Axiom?

Ah, that's the question for today...."Can people depend on it?".

And if they can't know the results are correct, what's the point?


I believe that Axiom could be the foundation for the next few hundred
years of computational mathematics. Oh, not the program we have
now. But the one it could evolve into if we do it right. Axiom is the
only program I've ever worked on that has that potential. The
mathematics doesn't change and, if correctly implemented, Axiom should
always give you an answer you can depend on. In fact, you should be
able to look at the final result of an Axiom computation and KNOW it
is right. And after that time, you and everyone else can depend on it.
Like an aircraft wing, only better because this is mathematics.

But I also find it frustrating because I don't see any Bill Perzley's
in the game. Bill not only learned the mathematics (we both took the
same course from Lou Paul), he understood it. He "programmed" it (we
didn't have anything but calculators and switches for programming but
it was still programming). He wrote it up so *I* could understand it.
And when he wrote programs they worked and *I* could check them. You
could bet your life on his work. And Bill often did.

Is this the level of quality we see in Axiom? Nope. Is this the level
of quality we can achieve? Yes. So, why don't we achieve it? Why don't
we write Axiom software as if our life depended on it? Why are we
still writing software like the Chandler project? Why can't we say
that this WILL work and it WILL give you the correct answer? What does
it take to get Perzley kind of quality?



After much thought I believe that we need to deeply improve the way
Axiom is written. Consider the latest dust-up that just flew by on the
mailing list (this isn't intended to cast blame, just to illustrate).

The issue is an apparent bug that was in the original Axiom
code. Apparently the computation of:

  f:=taylor(1-x^2)
  sin asin f

gave a wrong answer. A "fix" was applied that gives the answer:

  1 - x^2 + O(x^11)

This was considered wrong and a new "fix" was applied giving the
answer:

 1 - 1/4 x^4 - 1/16 x^6 - 7/768 x^8 - 5/3072 x^10 + O(x^11)


Lets apply Bill Perzley's eyes to this bug. I don't know if the
original Axiom answer was correct, the first "fix" was correct, or the
latest "fix" was correct. That's a problem. And it's a very deep
problem. Much deeper than this one bug. Bill's approach to this would
be to start at the bottom, namely subtraction in (1-x^2) and work his
way up, understanding all he could about each piece. At the end of
several months he's announce the fix. And I'd be willing to bet my
life he was right. Because he understood the problem, he understood
the answer, and he documented it so *I* could understand it.

How hard is this? Really, really hard. Because almost nobody knows
about subtraction in Axiom. Nonsense? Well subtraction is a very
widely implemented operator in many domains such as quaternions.  It
occurs everywhere. Is the definition right? Does it work everywhere?
Does axiom implement subtraction properly for all domains?  Once we
feel confident of that we can look at the "1" portion of the initial
expression. What does "1" mean in Axiom? Does it properly implement
the concept of "1" in mathematics?  Can we depend on it?




So that's one of the key questions. "Can we depend on it?". We may be
a domain experts in robotics and implement DHMatrices in Axiom. But did
we write it up in depth so the next person can understand it? 

By the time we've reached the level of documentation of things like
 
  UnivariateTaylorSeries(Expression Integer,x,0)

we, and everyone who reads our documentation, should be able to say
with life-depending certainty that our answer is correct. Someone 30
years from now should be able to read what we wrote and be as certain
as we are that our answer is correct.



Because we're doing mathematics.
Because we're doing it for people to understand.
Because Axiom's life depends on it.

\start
Date: 04 Feb 2007 14:43:26 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: Can you depend on it?

I agree with many things you write, save two:

1) I think that it is not worth dying for some robot or mathematics or
   anything.  And it is certainly not the case that you can rely ("depend") on
   anything.  I'd say, that both Bill and Boing team were just lucky.

   Important note: I do believe that various efforts and tools can improve on
   the likelihood of success, literate programming, unit testing are certainly
   two of them (the latter still missing in Axiom, because nobody finds the
   time to make AldorUnit work with libaxiom. Should be quite trivial, though).

   But it won't help you if you "died", even if the probability of dying was
   very very very low.

2) The history

>   f:=taylor(1-x^2)
>   sin asin f
> 
> gave a wrong answer. A "fix" was applied that gives the answer:
> 
>   1 - x^2 + O(x^11)
> 
> This was considered wrong and a new "fix" was applied giving the
> answer:
> 
>  1 - 1/4 x^4 - 1/16 x^6 - 7/768 x^8 - 5/3072 x^10 + O(x^11)

does not seem entirely correct to me. Since I believe that you have some
versions of axiom around, could you please double check?

In any case, Ralf Hemmecke has (in the framework of our species project) a well
documented and unit-tested powerseries implementation, albeit only a partial
implementation, currently. Looking at the code of Axiom, I'm quite convinced
that *all* of it should go away. It can be done much better, if you look at
Joris van der Hoeven's and Dominik Gruntz papers.

(On Computing Limits in a Symbolic Manipulation System; Dominik Gruntz. ETH
 Diss 11432, 1996. http://www.gruntz.ch/publications2.html)

By the way, I think that most code in axiom is crap. It is a mere coincidence
that it works roughly. If you want to see a well engineered system, look at the
MuPAD sources. (I'm not saying that it couldn't be done better. But it's quite
incredible how well it works. It's a pity that MuPAD is non-free now.)


Martin

PS: does anybody happen to know how many initial values one needs to single out
a specific Taylor series solution of an algebraic equation? To get a feel for
the problem:

There need not be a Taylor solution at all:

f(x)^2-x=0

There can be several branches with equal constant term:

 map(e+->series(e, x=0), zerosOf((x^2-1)*z^2-2*(x^4-1)*z+(x^2-1),z))

                             +-+                              +-+
                +-+     2   \|2   3      4       +-+     2   \|2   3      4
   (160)  [1 - \|2 x + x  - ---- x  + O(x ),1 + \|2 x + x  + ---- x  + O(x )]
                              4                                4


I'd guess that the first d terms are enough, when the equation has degree d in
z, but I don't know and in general less should be sufficient.

Some problem for ADE's, i.e., equations of the form

p(1, z(x), z'(x), z''(x), ...) = 0, p polynomial with coefficients in K[x]?

\start
Date: Sun, 4 Feb 2007 06:28:49 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Re: Can you depend on it?

> Ah, that's the question for today...."Can people depend on it?".
> 
> And if they can't know the results are correct, what's the point?

That combination of questions might be the most common objection I have
heard to using CAS software in science and mathematical research.  One
I happen to agree with. Oh, there are others, such as the tendency of
lazy humans to substitute computer software for understanding, and that
has its valid points, but the most serious one I think is being able to
know the results are correct. 

> I believe that Axiom could be the foundation for the next few hundred
> years of computational mathematics. Oh, not the program we have
> now. But the one it could evolve into if we do it right. Axiom is the
> only program I've ever worked on that has that potential. The
> mathematics doesn't change and, if correctly implemented, Axiom
> should always give you an answer you can depend on. In fact, you
> should be able to look at the final result of an Axiom computation
> and KNOW it is right. And after that time, you and everyone else can
> depend on it. Like an aircraft wing, only better because this is
> mathematics.

This is why I think it is important to pursue proof checkers (things
like Isabelle, HOL, COQ, ACL2, etc.) as a starting point, not as
something to tack on later.  KNOWING a result is correct when a
computer produces it is very very complex.  It is unambiguous when a
wing breaks, and fairly easy to measure (given the right equipment). 
Predicting it is fairly hard, but doable.  Ditto for the robot - if
something goes wrong, lots of equipment starts flying that shouldn't be
moving.  Or, in the less spectacular case, the wrong thing gets welded.
 A computer has many subtle points of possible failure.  Is it a weird
CPU bug, a mishandling of information in some subtle, unexpected way, a
1/1,000,000,000 failure condition of the operating system (think the
blackout that hit most of the northeastern US a while back - they
traced that back to a software error condition with a very small
window: http://www.securityfocus.com/news/8412)  If the systems running
such a major portion of the national energy grid can't be completely
trusted, why should anyone trust CAS software?
 
> But I also find it frustrating because I don't see any Bill Perzley's
> in the game. Bill not only learned the mathematics (we both took the
> same course from Lou Paul), he understood it. He "programmed" it (we
> didn't have anything but calculators and switches for programming but
> it was still programming). He wrote it up so *I* could understand it.
> And when he wrote programs they worked and *I* could check them. You
> could bet your life on his work. And Bill often did.

In this instance, it sounds like both the hardware and software were
special purpose, very well engineered, and he had a fair amount of
time/money to commit to the project.  While authors of CAS systems
might be able to make sure the software they write is solid (although
that goal still seems a ways off) they must rely on both the operating
environment and the hardware underneath it to work correctly.  Neither
of those components is under the control of the author, since the
software will be installed in as many environments as it can be made to
run.  It will work most of the time, but who knows when some subtle
difference will trigger a northeast blackout in the results?  How can
it be prevented?

> Is this the level of quality we see in Axiom? Nope. Is this the level
> of quality we can achieve? Yes. So, why don't we achieve it? Why
> don't we write Axiom software as if our life depended on it? Why are
> we still writing software like the Chandler project? Why can't we say
> that this WILL work and it WILL give you the correct answer?

Because, among other reasons, we don't have the tools that will let us
make that assertion and back it up.  I doubt Perzley would have been
willing to do what he did if the robot was being operated by Windows XP
and was just taking instructions he had fed it - I know I sure wouldn't
- because every element of the system which MIGHT cause failure isn't
guaranteed.

> What does it take to get Perzley kind of quality?

This is the type of problem I would like to do research in, someday.  I
have a ways to go first (as you mentioned earlier, you must know both
the mathematics and how to program, and I am working on increasing my
basic knowledge before making another run at Axiom level problems) but
the question is a worthy one.

Science magazine had a rather interesting article (I suppose it's not
the full story since it's a specialty topic in a general magazine, but
I found it good food for thought) about the difficulties that have
begun to appear in the form of proofs that cannot be checked by human
reviewers: 
http://www.sciencemag.org/cgi/content/summary/307/5714/1402a   In that
article, the point was made that there are two aspects to proof
checking:

1.  Knowing it is correct
2.  Understanding why it is correct (human understanding)

If you only use human beings to check proofs, these two components are
not separable.  A human being must understand the proof in order to
know if it is correct.  An automated proof checker, correctly done,
should be able to mechanically verify that the proof is sound.  In
theory, a human being dogged enough to follow the computer through the
steps should arrive at the exact same conclusion, although the
experience is unlikely to build much insight into how to make "good"
proofs.  What needs to be human understandable is a) the proof checking
system and b) the logic converting human CAS style inputs into proof
statements.  Once the correct proof statements are generated, the proof
checker will take it from there.

I think the distinction is important for what we are trying to do here,
because for a CAS it is less important to produce elegant/beautiful
proofs and more important to know the result is correct.  Proof
software may never generate the "optimal" proof for a given result, but
so long as it generates a CORRECT proof that can be evaluated in
reasonable time it has done what is needed for us to rely on it.  In
our case the proofs are a means to an end - if people can rely on
Axiom's results as having come from components that have proof backing,
and can at need (say for a particularly critical result for a paper)
have Axiom generate the full proof validation for a result to be
verified by any of several systems, I think we will have achieved a
level of confidence that will permit more general use of the systems. 
We will be able to say "yes it is correct, and here's the proof, to be
checked however you care to check it."

Now the details of that system, and whether it is even possible, are
the subject of many years of fascinating research and may even require
defining as unambiguously as possible what it means to prove something.
 But I think this is going to be essential for the long term viability
of any such system - it must be "so good" that using anything else
becomes a liability.

CAS systems are currently used in science - Mathematica + Feyncalc was
a common tool at my undergrad physics department - and those systems
have become usable through a sort of prolonged process of evaluation by
many scientists.  However, if asked to show proof that a feyncalc
derived result was correct, pencil and paper work would be needed to
verify the system was correct.  Making a system that WOULDN'T need such
work is going to be a hard sell, and some good answers to the question
of why any new system is any better than Mathematica + Feyncalc would
be needed.

But to make that system, one must know not just programming and
mathematics but proof logic as well (plus high energy physics, for this
problem domain), and how to make all of them interact.    Which reminds
me, I have some reading to do...

\start
Date: 04 Feb 2007 19:13:49 +0100
From: Martin Rubey
To: Bill Page,
Subject: MathAction down - mirror not up to date?

Dear Bill,

unfortunately, it seems that mathaction is currently down.

furthermore, it seems that the mirror at risc is not really up to date. By the
way, if I make changes at the mirror at risc, I guess they are not applied to
the main site, are they? I.e., after one update, they get lost?

\start
Date: Sun, 4 Feb 2007 14:17:15 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: MathAction down - mirror not up to date?

Martin,

On February 4, 2007 1:14 PM you wrote:

> 
> unfortunately, it seems that mathaction is currently down.

I am looking at the problem. Something has gone with the configuration
of Apache on the axiom-developer.org server however I have not made
any recent changes. The backend Zope web server however is still working.
So in the mean time you can bypass Apache by accessing the Axiom wiki
site from the following url:

http://axiom-developer.org:8080/mathaction/FrontPage

I will let you know when the problem with Apache is fixed.

> 
> furthermore, it seems that the mirror at risc is not really 
> up to date. By the way, if I make changes at the mirror at risc,
> I guess they are not applied to the main site, are they? I.e.,
> after one update, they get lost?
> 

It is true that the risc mirror site is not up to date. I have
not gotten around to update for over a month. Changes you make
at the risc site are not automatically applied at the main site
but there is a simple process to transfer pages from one site
to another.

\start
Date: Sun, 4 Feb 2007 14:32:27 -0500
From: Bill Page
To: Martin Rubey
Subject: re: MathAction down - mirror not up to date?

Ok, problem solved.

http://wiki.axiom-developer.org

and

http://portal.axiom-developer.org

are working again. The problem was that one of the user directories
on axiom-developer.org was deleted without removing the entries
for that user's web site from the apache configuration files. Apache
refused to restart.

Tim has been making an effort to clean up the file space on
axiom-developer.org in order to reduce the monthly cost of operating
this server (Over $250/month which Tim is contributing from his own
pocket! I think we need to discuss how to share the cost of this
server.) On his request I recently cleaned up the mathaction development
directories but I am quite sure that I did not delete any /home user
directories.

Anyway, the Apache configuration file has now been updated and
everything appears to be fine again.

I will now put some priority on updating the risc mirror site in
case this or something more serious happens again.

Regards,
Bill Page.


On February 4, 2007 2:17 PM I wrote:
> 
> On February 4, 2007 1:14 PM Martin wrote:
> 
> > 
> > unfortunately, it seems that mathaction is currently down.
> 
> I am looking at the problem. Something has gone with the configuration
> of Apache on the axiom-developer.org server however I have not made
> any recent changes. The backend Zope web server however is still
> working.
>
> So in the mean time you can bypass Apache by accessing the Axiom wiki
> site from the following url:
> 
> http://axiom-developer.org:8080/mathaction/FrontPage
> 
> I will let you know when the problem with Apache is fixed.

\start
Date: 04 Feb 2007 20:54:16 +0100
From: Martin Rubey
To: Bill Page
Subject: re: MathAction down - mirror not up to date? /	money

Bill Page writes:

> Ok, problem solved.
> 
> http://wiki.axiom-developer.org
> 
> and
> 
> http://portal.axiom-developer.org
> 
> are working again. 

Great! Thank you!

> Tim has been making an effort to clean up the file space on
> axiom-developer.org in order to reduce the monthly cost of operating this
> server (Over $250/month which Tim is contributing from his own pocket! I
> think we need to discuss how to share the cost of this server.)

Definitively. I'll keep it in mind.

\start
Date: 04 Feb 2007 21:28:08 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: messages in wh-sandbox

Dear Waldek,

is there a way to turn of messages like

BasicLookup coerce: ((OutputForm) $)
Lookup coerce ((OutputForm) $)
Lookup coerce ((OutputForm) $)
BasicLookup coerce: ((OutputForm) $)
Lookup coerce ((OutputForm) $)

in wh-sandbox?

\start
Date: Sun, 04 Feb 2007 16:03:17 -0500
From: Bill Page
To: list
Subject: building wh-sandbox on SuSE 10.2
Cc: Bill Page

Waldek, et al.

I just tried to build wh-sandbox on a SuSE 10.2 linux system. Everything se=
ems
to compile normally up to the point of building hyperdoc and ends with the =
error
message:

  No rule to make target `all-ax'.

Does anyone have an idea about what might cause this error?  Suggestions?

What reports do we have of successful builds of wh-sandbox? What
platforms?

Regards,
Bill Page.

wspage@suse-linux:~/axiom-sandbox> tail -100 build.log
process3d.c:857: warning: =E2=80=98linearMouseXY.x=E2=80=99 may be used uni=
nitialized in
this function
process3d.c:857: warning: =E2=80=98linearMouseXY.y=E2=80=99 may be used uni=
nitialized in
this function
process3d.c:857: warning: =E2=80=98mouseXY.x=E2=80=99 may be used uninitial=
ized in this
function
process3d.c:857: warning: =E2=80=98mouseXY.y=E2=80=99 may be used uninitial=
ized in this
function
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=project3d.c
./../../../wh-sandbox/src/graph/view3D/project3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o project3=
d.o
project3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=quitbut3d.c
./../../../wh-sandbox/src/graph/view3D/quitbut3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o quitbut3=
d.o
quitbut3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=quit3d.c
./../../../wh-sandbox/src/graph/view3D/quit3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o quit3d.o
quit3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=save3d.c
./../../../wh-sandbox/src/graph/view3D/save3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o save3d.o
save3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=savebut3d.c
./../../../wh-sandbox/src/graph/view3D/savebut3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o savebut3=
d.o
savebut3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=smoothShade3d.c
./../../../wh-sandbox/src/graph/view3D/smoothShade3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o
smoothShade3d.o smoothShade3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=spadAction3d.c
./../../../wh-sandbox/src/graph/view3D/spadAction3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o
spadAction3d.o spadAction3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=stuff3d.c
./../../../wh-sandbox/src/graph/view3D/stuff3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o stuff3d.=
o
stuff3d.c
stuff3d.c: In function =E2=80=98norm_dist=E2=80=99:
stuff3d.c:128: warning: =E2=80=98pert.z=E2=80=99 is used uninitialized in t=
his function
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=surface3d.c
./../../../wh-sandbox/src/graph/view3D/surface3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o surface3=
d.o
surface3d.c
surface3d.c: In function =E2=80=98drawRenderedPolygon=E2=80=99:
surface3d.c:394: warning: =E2=80=98col_rgb.r=E2=80=99 may be used uninitial=
ized in this
function
surface3d.c:394: warning: =E2=80=98col_rgb.g=E2=80=99 may be used uninitial=
ized in this
function
surface3d.c:394: warning: =E2=80=98col_rgb.b=E2=80=99 may be used uninitial=
ized in this
function
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=transform3d.c
./../../../wh-sandbox/src/graph/view3D/transform3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o
transform3d.o transform3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=viewport3d.c
./../../../wh-sandbox/src/graph/view3D/viewport3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o viewport=
3d.o
viewport3d.c
/home/wspage/wh-sandbox/src/graph/view3D/static.h:42: warning: =E2=80=98lab=
els=E2=80=99
defined but not used
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=volume3d.c
./../../../wh-sandbox/src/graph/view3D/volume3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o volume3d=
.o
volume3d.c
/home/wspage/axiom-sandbox/src/graph/view3D/../../.././build/scripts/docume=
nt
--tangle --output=write3d.c
./../../../wh-sandbox/src/graph/view3D/write3d.c.pamphlet
gcc -c -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/wh-sandbox/src/graph/view3D
-I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/view3D/../../.././config -o write3d.=
o
write3d.c
gcc ./buttons3d.o ./closeView3d.o ./component3d.o ./control3d.o ./illuminat=
e3d.o
./lightbut3d.o ./lighting3d.o ./main3d.o ./mesh3d.o ./msort3d.o ./pot3d.o
./process3d.o ./project3d.o ./quitbut3d.o ./quit3d.o ./save3d.o ./savebut3d=
.o
./smoothShade3d.o ./spadAction3d.o ./stuff3d.o ./surface3d.o ./transform3d.=
o
./viewport3d.o ./volume3d.o ./write3d.o ../Gdraws/Gfun.o -o
/home/wspage/axiom-sandbox/target/i686-suse-linux/lib/view3D \
                -L/home/wspage/axiom-sandbox/src/graph/view3D/../../.././sr=
c/lib
-lspad -lXpm  -lSM -lICE -lX11  -lm
./Gdraws/Gfun.o: In function `PSInit':
/home/wspage/axiom-sandbox/src/graph/Gdraws/Gfun.c:811: warning: the use of
`tmpnam' is dangerous, better use `mkstemp'
./Gdraws/Gfun.o: In function `PSGlobalInit':
/home/wspage/axiom-sandbox/src/graph/Gdraws/Gfun.c:686: warning: the use of
`tempnam' is dangerous, better use `mkstemp'
rm -f stamp
echo timestamp > stamp
finished ../../../../wh-sandbox/src/graph/view3D
make[3]: Leaving directory `/home/wspage/axiom-sandbox/src/graph/view3D'
cd viewAlone && SPAD=/home/wspage/axiom-sandbox/target/i686-suse-linux SR=
C=/src
INT=/home/wspage/axiom-sandbox/int OBJ=/home/wspage/axiom-sandbox/obj
INC=/home/wspage/axiom-sandbox/../wh-sandbox/src/include NOISE="-o
/home/wspage/axiom-sandbox/build/i686-suse-linux/trace" VERSION="Axiom
build-improvements branch 2006-11-26"
DOCUMENT=/home/wspage/axiom-sandbox/build/scripts/document PLF="" CCF=
="-O2
-fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" LISP=lsp make
make[3]: Entering directory `/home/wspage/axiom-sandbox/src/graph/viewAlone=
'
/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././build/scripts/doc=
ument
--tangle --output=viewAlone.c
./../../../wh-sandbox/src/graph/viewAlone/viewAlone.c.pamphlet
gcc -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I../../../../wh-sandbox/src/graph/viewAlone
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include -I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././config -c -o
viewAlone.o viewAlone.c
/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././build/scripts/doc=
ument
--tangle --output=spoonComp.c
./../../../wh-sandbox/src/graph/viewAlone/spoonComp.c.pamphlet
gcc -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I../../../../wh-sandbox/src/graph/viewAlone
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include -I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././config -c -o
spoonComp.o spoonComp.c
/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././build/scripts/doc=
ument
--tangle --output=spoon2D.c
./../../../wh-sandbox/src/graph/viewAlone/spoon2D.c.pamphlet
gcc -g -O2 -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE 
-I../../../../wh-sandbox/src/graph/viewAlone
-I/home/wspage/wh-sandbox/src/graph/include
-I/home/wspage/wh-sandbox/src/include -I/home/wspage/wh-sandbox/src/include
-I/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././config -c -o
spoon2D.o spoon2D.c
gcc viewAlone.o spoonComp.o spoon2D.o -o
/home/wspage/axiom-sandbox/target/i686-suse-linux/bin/viewAlone
-L/home/wspage/axiom-sandbox/src/graph/viewAlone/../../.././src/lib -lspad =
\
                -lXpm  -lSM -lICE -lX11
rm -f stamp
echo timestamp > stamp
finished .
make[3]: Leaving directory `/home/wspage/axiom-sandbox/src/graph/viewAlone'
/home/wspage/axiom-sandbox/src/graph/../.././build/scripts/document
--tangle=`basename parabola/data` --output=parabola/data
./../../wh-sandbox/src/graph/fileformats.pamphlet
/home/wspage/axiom-sandbox/src/graph/../.././build/scripts/document
--tangle=`basename parabola/graph0` --output=parabola/graph0
./../../wh-sandbox/src/graph/fileformats.pamphlet
echo timestamp > stamp
24 finished
make[2]: Leaving directory `/home/wspage/axiom-sandbox/src/graph'
./../wh-sandbox/config/mkinstalldirs
/home/wspage/axiom-sandbox/target/i686-suse-linux/bin
./../wh-sandbox/config/mkinstalldirs
/home/wspage/axiom-sandbox/target/i686-suse-linux/share
cd hyper && SPAD=/home/wspage/axiom-sandbox/target/i686-suse-linux SRC==
/src
INT=/home/wspage/axiom-sandbox/int OBJ=/home/wspage/axiom-sandbox/obj
INC=/home/wspage/axiom-sandbox/../wh-sandbox/src/include NOISE="-o
/home/wspage/axiom-sandbox/build/i686-suse-linux/trace" VERSION="Axiom
build-improvements branch 2006-11-26"
DOCUMENT=/home/wspage/axiom-sandbox/build/scripts/document PLF="" CCF=
="-O2
-fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" LISP=lsp make
make[2]: Entering directory `/home/wspage/axiom-sandbox/src/hyper'
failcmd='exit 1'; \
        for f in $MAKEFLAGS; do \
           case $f in \
              *=* | --[!k]*) ;; \
              *k*) failcmd='fail=yes';; \
           esac; \
        done; \
        dot_seen=no; \
        target=`echo all-recursive | sed s/-recursive//`; list=''; \
        for subdir in $list; do \
           echo "Making $target in $subdir"; \
           if test "$subdir" = "."; then \
              dot_seen=yes; \
              local_target="$target-ax"; \
           else \
              local_target="$target"; \
           fi; \
           (cd $subdir && SPAD=/home/wspage/axiom-sandbox/target/i686-sus=
e-linux
SRC=/src INT=/home/wspage/axiom-sandbox/int OBJ=/home/wspage/axiom-sa=
ndbox/obj
INC=/home/wspage/axiom-sandbox/../wh-sandbox/src/include NOISE="-o
/home/wspage/axiom-sandbox/build/i686-suse-linux/trace" VERSION="Axiom
build-improvements branch 2006-11-26"
DOCUMENT=/home/wspage/axiom-sandbox/build/scripts/document PLF="" CCF=
="-O2
-fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" LISP=lsp make $local=
_target)
|| eval $failcmd; \
        done; \
        if test "$dot_seen" = "no"; then \
           SPAD=/home/wspage/axiom-sandbox/target/i686-suse-linux SRC=/=
src
INT=/home/wspage/axiom-sandbox/int OBJ=/home/wspage/axiom-sandbox/obj
INC=/home/wspage/axiom-sandbox/../wh-sandbox/src/include NOISE="-o
/home/wspage/axiom-sandbox/build/i686-suse-linux/trace" VERSION="Axiom
build-improvements branch 2006-11-26"
DOCUMENT=/home/wspage/axiom-sandbox/build/scripts/document PLF="" CCF=
="-O2
-fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" LISP=lsp make "$targ=
et-ax"
|| exit 1; \
        fi; test -z "$fail"
make[3]: Entering directory `/home/wspage/axiom-sandbox/src/hyper'
make[3]: *** No rule to make target `all-ax'.  Stop.
make[3]: Leaving directory `/home/wspage/axiom-sandbox/src/hyper'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/wspage/axiom-sandbox/src/hyper'
make[1]: *** [all-hyper] Error 2
make[1]: Leaving directory `/home/wspage/axiom-sandbox/src'
make: *** [all-src] Error 2
wspage@suse-linux:~/axiom-sandbox>

\start
Date: 04 Feb 2007 22:18:23 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: building wh-sandbox on SuSE 10.2

Bill Page writes:

> What reports do we have of successful builds of wh-sandbox? What
> platforms?

I just re-built wh-sandbox, although not from scratch but only after a svn up,
on kubuntu dapper without a problem.

\start
Date: Sun, 4 Feb 2007 22:29:48 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: Re: building wh-sandbox on SuSE 10.2

> Waldek, et al.
> 
> I just tried to build wh-sandbox on a SuSE 10.2 linux system. Everything seems
> to compile normally up to the point of building hyperdoc and ends with the error
> message:
> 
>   No rule to make target `all-ax'.
> 
> Does anyone have an idea about what might cause this error?  Suggestions?
> 
> What reports do we have of successful builds of wh-sandbox? What
> platforms?
> 
> Regards,
> Bill Page.
> 
> wspage@suse-linux:~/axiom-sandbox> tail -100 build.log
<snip>
> make[3]: Entering directory `/home/wspage/axiom-sandbox/src/hyper'
> make[3]: *** No rule to make target `all-ax'.  Stop.
> make[3]: Leaving directory `/home/wspage/axiom-sandbox/src/hyper'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/wspage/axiom-sandbox/src/hyper'
> make[1]: *** [all-hyper] Error 2
> make[1]: Leaving directory `/home/wspage/axiom-sandbox/src'
> make: *** [all-src] Error 2
> wspage@suse-linux:~/axiom-sandbox>
> 

Thanks for the report.  I build regularly on prerelase Debian and on
Mandrake 9.2.  Your log looks different than my build log -- I will
investigate what is the reason for the difference.

\start
Date: Sun, 4 Feb 2007 22:39:28 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: messages in wh-sandbox

Martin Rubey wrote:
> is there a way to turn of messages like
> 
> BasicLookup coerce: ((OutputForm) $)
> Lookup coerce ((OutputForm) $)
> Lookup coerce ((OutputForm) $)
> BasicLookup coerce: ((OutputForm) $)
> Lookup coerce ((OutputForm) $)
> 
> in wh-sandbox?
>

When do you see them?  They look like debugging messages I use, but
they should not get into public version.  ATM I do not not them,
and quick search did not found them in current svn.

Later you wrote:
> I just re-built wh-sandbox, although not from scratch but only after a svn up,
> on kubuntu dapper without a problem. 

Do the messages appear in the freshly re-built version?

\start
Date: 04 Feb 2007 22:44:41 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: messages in wh-sandbox

Waldek Hebisch writes:

> Martin Rubey wrote:
> > is there a way to turn of messages like
> > 
> > BasicLookup coerce: ((OutputForm) $)
> > Lookup coerce ((OutputForm) $)
> > Lookup coerce ((OutputForm) $)
> > BasicLookup coerce: ((OutputForm) $)
> > Lookup coerce ((OutputForm) $)
> > 
> > in wh-sandbox?
> >
> 
> When do you see them?  They look like debugging messages I use, but
> they should not get into public version.  ATM I do not not them,
> and quick search did not found them in current svn.
> 
> Later you wrote:
> > I just re-built wh-sandbox, although not from scratch but only after a svn up,
> > on kubuntu dapper without a problem. 
> 
> Do the messages appear in the freshly re-built version?

yes. Unfortunately, I have thrown the log away. Ah, I see, I just ran a svn
diff and some files are modified. Very likely, this is because of an
experimental patch of Peter Broadbery to enable aldor extend. Sorry about
taking away your time...

\start
Date: Sun, 4 Feb 2007 20:35:29 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: [Axiom-math] [ANN] New version of Guessing	Package on MathAction

Martin,

On February 4, 2007 6:59 PM you wrote:
> 
> It has now become obvious that the code in
> 
> > http://wiki.axiom-developer.org/MantepseSpad2
> 
> did not compile properly: guessExpRat(q) does not work, look for 
> 
> 
>   For Sequence (5), we enter
> 
> Would be great if you could fix that...
> 

I am not sure if I can fix anything, but you are right that
MantepseSpad2 did not compile in the 1 minute CPU time limit
on MathAction. I increased the limit to 60 minutes - in fact
the compile took almost 12 minutes of CPU time! That is one
long hard program to compile!!!

Maybe it is alright now? It seems to have compiled. You have
to wait for about 15 minutes. The browser times out and does
not display the result but when you refresh the page after 15
minutes the compile is complete and the page looks ok.

Let me know if this works now. I will leave the limit at 60
minutes for now.

\start
Date: 05 Feb 2007 04:12:37 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: [Axiom-math] [ANN] New version of Guessing	Package on MathAction

Dear Bill,

Bill Page writes:

> I am not sure if I can fix anything, but you are right that
> MantepseSpad2 did not compile in the 1 minute CPU time limit
> on MathAction. I increased the limit to 60 minutes - in fact
> the compile took almost 12 minutes of CPU time! That is one
> long hard program to compile!!!

Yes, it is quite big. Even though I factored out many many things already...

> Maybe it is alright now? It seems to have compiled. 

Unfortunately, no. In fact, if you unfold the spad button, it says

  >> System error:
  Unexpected end of #<input stream "/var/zope/var/LatexWiki/GUESS.NRLIB/index.KAF">.

I have never seen such a message before... Well, I'm trying again and see
whether it's a one time only. However, I have to go to bed then, it's alreade
10 past 4...


Thanks for all your help!

Martin

PS: Neil Sloane will be looking at the program next week, and possibly include
it in SuperSeeker. That'd be nice!

\start
Date: 05 Feb 2007 04:55:06 +0100
From: Martin Rubey
To: Martin Rubey
Subject: Re: [Axiom-math] [ANN] New version of Guessing	Package on MathAction

Martin Rubey writes:

> Dear Bill,

It's working now! Super! Good night!

\start
Date: Mon, 05 Feb 2007 23:38:19 -0500
From: Bill Page
To: list
Subject: wh-sandbox: error in hyperdoc - uncompress is obsolete

While testing Hyperdoc in the current version wh-sandbox on OpenSuSE 10.2 I
encountered the following problem while run some example graphics:

Hyperdoc processed crashed (window disappeared) and the following message
appeared in the Axiom console session:

(2) -> XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0.0"
      after 40603 requests (40235 known processed) with 0 events remaining.
read_pixmap_file: unable to open
/home/wspage/axiom-sandbox/target/i686-suse-linux/share/viewports/AssortedGraphicsExamplePage6.VIEW/image.xpm
uncompress: No such file or directory

-------

My understanding is that 'uncompress' is an obselete name for 'gzip -d'. Is that
correct?

\start
Date: Mon, 05 Feb 2007 23:45:49 -0500
From: Bill Page
To: list
Subject: Re: building wh-sandbox on SuSE 10.2

Quoting Bill Page:

> ...
> I just tried to build wh-sandbox on a SuSE 10.2 linux system. 
> Everything seems to compile normally up to the point of building
> hyperdoc and ends with the error message:
>
>   No rule to make target `all-ax'.
> ...

After investigating this a little more I found that the file

   src/hyper/Makefile

in my out-of-source build directory was incomplete. It seemed
to contain only the standard header stanzas but none of the
contents of

   src/hyper/Makefile.in

from the source directory.

I do not know the exact cause, however after re-running configure
in the build directory the problem was corrected and I was able to
complete the build by simply re-starting 'make'.

The only difference that I am aware of between the first time I
ran 'configure' and the second time was that previously I had
not yet installed 'latex'. I am not sure if this might have triggered
the problem.

In any case, I can now report a successful build on OpenSuSE 10.2.

\start
Date: 06 Feb 2007 04:59:03 -0600
From: Gabriel Dos Reis
To: Bill Page
Subject: re: building wh-sandbox on SuSE 10.2

Bill Page writes:

| Quoting Bill Page:
| 
| > ...
| > I just tried to build wh-sandbox on a SuSE 10.2 linux
| > system. Everything seems to compile normally up to the point of
| > building
| > hyperdoc and ends with the error message:
| >
| >   No rule to make target `all-ax'.
| > ...
| 
| After investigating this a little more I found that the file
| 
|    src/hyper/Makefile
| 
| in my out-of-source build directory was incomplete. It seemed
| to contain only the standard header stanzas but none of the
| contents of
| 
|    src/hyper/Makefile.in
| 
| from the source directory.
| 
| I do not know the exact cause, however after re-running configure
| in the build directory the problem was corrected and I was able to
| complete the build by simply re-starting 'make'.
| 
| The only difference that I am aware of between the first time I
| ran 'configure' and the second time was that previously I had
| not yet installed 'latex'. I am not sure if this might have triggered
| the problem.


I don't know.  But, it is curious.  I've seen a similar behaviour in
build-improvement once, but it happened at the toplevel.  At the time,
I found that it was because noweave/notangle was missing so the
build-setup.sh script overwrote complete information with partial
information.  

\start
Date: Tue, 6 Feb 2007 14:20:37 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Algebra bootstrap

I would like to share with you recent progress I made.  Namely, I was
able to bootstrap Axiom algebra using no cached Lisp (that means no
Lisp for algebra files, boot and interpreter are different story).

How doeas it work?  I looked once again at 'Loading' messages appearing
in Axiom trace.  I have noticed that only 263 different thing get
leaded.  Of them there is 199 categories, 44 domains associated
with categories (those domains give default implementations for
some functions) and 20 core domains:

AssociationList Boolean Character DoubleFloat Fraction
IndexedList IndexedOneDimensionalArray IndexedString
IndexedVector Integer List NonNegativeInteger OutputForm
PositiveInteger PrimitiveArray Reference SingleInteger
String Symbol Vector

Main bootstrap problems are due to core domains: if we forget about
Reference the other are all mutually dependent.  Also, they depend
on many categories and it turn many categories depend on core
domains.

AFAICS bootstrap layer used by Tim includes almast all core domains
and categories with associated domains.  Once we have compiled
all categories and domains loaded by Axiom we can proceed essentially
in any order.

I spent some time trying to find pattern deciding wether a file
gets loaded during given compilation or not.  There are obvious
reasons to load categories:  Axiom implements Join as runtime
operation, so in order to compute Join it must first load all
categories involved in Join.  Also, it seems that Axiom loads
categories of arguments of constructors.  However, loading of
domains looked almost random.  After some effort I have tracked
this to the optDeltaEntry in nruncomp.boot.pamphlet: appearently
this functions tries to avoid lookups in domain vectors and redirect
calls to final destination.  To do this optDeltaEntry must have
domain vectors available, so it load corresponding domains.
After disabling optimisation done by optDeltaEntry _no_ domains
are loaded during compilarion.

So, it remains to bootstrap categories.  There is still a little
cyclic dependencies between categories, due to constructor
arguments.  But $bootStrapMode switch resolves this dependency,
and it is enough to topologically sort categories based on
ancestor fields.


The final process looks as follows.  The compiler is modified to
have extra switch $bootstrapDomains, which if set to true disables
optimisation in optDeltaEntry.  In the first pass I use topologically
sorted list of categories and compile in $bootStrapMode.  In the
second pass I use $bootstrapDomains switch and compile categories
plus core domains.  In the thired pass I recompile categories
and core domains in normal mode.  Finally, I compile the rest
of algebra in alphabetical order (in fact, I let make choose the
oreder, but the list I give is sorted alphabetically, and make
processes it in order).

There is still problem of databases: the process I outlined above
uses pre-built databases.  Most of the typechecking uses information
form databases, so in order to modify algebra one has to generate
databases first and only later can use bootstrap procedure.  I made
some progress trying to bootstrap with empty databases.  I am able
to compile categories and about 50 domains in $bootStrapMode starting
from empty databases, but the resulting databases still contain too
little (or possibly incorrect) information, so normal bootstrap using
such databases fails relatively early.

\start
Date: 06 Feb 2007 08:04:51 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Algebra bootstrap

I think we need to have a basic interpreter, and a basic compiler
in the sense that they are almost like the interpreter and compiler,
but they "know" only 

   * simple types: Boolean, Integer, Float
   * constructed types: List(T), Vector(T)
   * fundamental structure: Category

Form that, we must separate and rationalize the database construction.

We must also be able to process a file without first having to split
it into several chunks.  We have been able to process SPAD files that
way; making )abbrev a no-op.

\start
Date: Tue, 6 Feb 2007 17:00:47 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: Re: wh-sandbox: error in hyperdoc - uncompress is obsolete

> While testing Hyperdoc in the current version wh-sandbox on OpenSuSE 10.2 I
> encountered the following problem while run some example graphics:
> 
> Hyperdoc processed crashed (window disappeared) and the following message
> appeared in the Axiom console session:
> 
> (2) -> XIO:  fatal IO error 104 (Connection reset by peer) on X server ":0.0"
>       after 40603 requests (40235 known processed) with 0 events remaining.
> read_pixmap_file: unable to open
> /home/wspage/axiom-sandbox/target/i686-suse-linux/share/viewports/AssortedGraphicsExamplePage6.VIEW/image.xpm
> uncompress: No such file or directory
> 
> -------
> 
> My understanding is that 'uncompress' is an obselete name for 'gzip -d'. Is that
> correct?
> 

Not exactly, 'uncompress' the program to decompress .Z (LZW compressed)
files.  Later 'gzip' was created and to large degree reduced need to
use 'compress' and 'uncompress'.  And yes, 'gzip -d' can do the job
of 'uncompress' (and more).

I have met similar (or maybe exactly this) problem.  'uncompress'
program is uses by Xpm library -- to see any images at all you
must have 'uncompress' program (shell script passing work to 'gzip -d'
may serve as a replacement).  But on some machines there are problems
even if 'uncompress' is present.  In fact on dual core Pentums running
Debian prerelease most of the time I get error trying to see images
(but sometimes images work).  I have traced my problem to Xpm library
-- it looked that 'uncompress' was nicely decompressing images,
but for unknown reasons Xpm library decided that 'uncompress' was
not working and returned error indication.  I am not sure where the
real error is: it may be bug in this version of Xpm library, it may
be that Hyperdoc is messing with process control in ways which
confilct with Xpm.  All machines where I was able to reproduce the
problem run the same version of Debian on the same hardware, so it
looked likely that this is a bug in Debian provided Xpm library.

There is a workaroud: in wh-sandbox Hyperdoc will uncompressed files
if they are present (or 'gzip' compressed ones, but AFAIK 'gzip -d'
has the same problem as 'uncompress').  At least in my case reading
uncompressed images never failed.  So you can try uncomressing
all .xpm.Z files (wastefull on space, but should work ...).

In the future we want to replace Xpm library by a different (portable)
image library, so the problem should automatically go away.  If the
problem affects more poeple I will probably look again at it to
find quicker solutuion.

\start
Date: 06 Feb 2007 21:50:14 +0100
From: Francois Maltey
To: list
Subject: axiom in windows xp for an user who isn't root.

Hello,

I have installed axiom and msys as root in windows xp for some students.
It's all right ! 

But I don't want theses students are root in windows xp.
So I create an other login.

I change rights of the axiom directory and the msys directory.
Now they are read/write/and others for all users.

When I run axiom in this login I get a boot error.
Axiom is looking for a file in a very long path in msys
inside 8 or 10 sub-sub-directory. This file isn't in the msys directory.

This computer is at work and my mail at home... So I can't be more precise.

May you help me ?

\start
Date: Tue, 6 Feb 2007 17:35:53 -0500
From: Bill Page
To: Francois Maltey
Subject: RE: axiom in windows xp for an user who isn't root.

On February 6, 2007 3:50 PM Francois Maltey wrote:
> 
> I have installed axiom and msys as root in windows xp for 
> some students. It's all right !

msys is not necessary to use Axiom on windows - only if you
need to build Axiom from source.

> 
> But I don't want theses students are root in windows xp.
> So I create an other login.
>

How did you install Axiom in Windows? From the binary install
program or from source?
 
> I change rights of the axiom directory and the msys directory.
> Now they are read/write/and others for all users.
> 
> When I run axiom in this login I get a boot error.
> Axiom is looking for a file in a very long path in msys
> inside 8 or 10 sub-sub-directory. This file isn't in the msys 
> directory.
>

It sounds like the AXIOM environment variable is not set.
 
> This computer is at work and my mail at home... So I can't be 
> more precise.
> 
> May you help me ?
> 

To check the AXIOM variable go to:

 Start/ControlPanel/System/Advanced/EnvironmentVariables

and check that the 'System variables' table includes

  Variable Name: AXIOM
  Variable Value: c:/Program Files/axiom/mnt/windows

It is possible that Axiom was originally installed for a single
user only, in which case the AXIOM variable may only be defined
for that specific user in the 'Users varaibles for ...'.

\start
Date: Wed, 7 Feb 2007 00:32:55 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Algebra bootstrap

I have commited new algebra bootstrap to wh-sandbox.  This code is
subject to change.  I belive that the code I commited should work
well for the intended purpose (that is bootstraping Axiom),
however:
- I am still investigating bootstrap problems (especially database
  bootstrap) and the whole process is likely to change
- I find the code ugly, partially due to tools used (make nad shell)
  and consider moving it to Lisp
- the code uses hardcoded lists of files, we should generate them
  automatically.

I have commited it so that:
- others can see details of bootstrap process
- I can kill Lisp embedded in algebra pamphlets

\start
Date: Wed, 7 Feb 2007 01:17:02 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Algebra bootstrap

> 
> I think we need to have a basic interpreter, and a basic compiler
> in the sense that they are almost like the interpreter and compiler,
> but they "know" only 
> 
>    * simple types: Boolean, Integer, Float
>    * constructed types: List(T), Vector(T)
>    * fundamental structure: Category
> 
> Form that, we must separate and rationalize the database construction.
>

Current compiler (before algebra bootstrap) does not know about Integer.
And Integer depends on large part of algebra.  So I would say that such
basic compiler while a noble goal would require substantial algebra
rewrite.  Such rewrite in turn need something like Aldor post facto
extension.

As an excercise I tried to make a minimal algebra.  I compiled
about 20 very simple domains and categories and generated corresponding
databses, but resulting interpreter was non-functional.  More effort
would probably give functional system, but ATM I am not sure if such
system is useful for bootstrap.
 
> We must also be able to process a file without first having to split
> it into several chunks.  We have been able to process SPAD files that
> way; making )abbrev a no-op.
> 

In longer run sure.  ATM I am using quite different method: I dumped
parse trees of the whole Axiom algebra into a file.  So now I can load
the whole algebra just as a single S-expression.  I am loading this
S-expression into sbcl running various analyses on it.  The idea is to
write (in Lisp) a simple compiler capable of extracting type declarations
and generating from them Axiom databases.  ATM I have a semi-reasonable
macro expander (there is one macro that the expander misess, but I
hope that it correctly expands all declarations that I need).  I have
also a simple transformer that eliminates 'where' construct.  Together
macro expander + 'where' transformer allow me to separate implementation
form interface (the assumption beeing that in databases we need only
information from interface).

Concerning abbrev declaration: I am not sure how to find out wether
something is a package or a domain without using information from
abbrevs.

\start
Date: 06 Feb 2007 19:19:57 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Algebra bootstrap

Waldek Hebisch writes:

| > 
| > I think we need to have a basic interpreter, and a basic compiler
| > in the sense that they are almost like the interpreter and compiler,
| > but they "know" only 
| > 
| >    * simple types: Boolean, Integer, Float
| >    * constructed types: List(T), Vector(T)
| >    * fundamental structure: Category
| > 
| > Form that, we must separate and rationalize the database construction.
| >
| 
| Current compiler (before algebra bootstrap) does not know about Integer.

I don't think so.  

The internal AST that eventually reaches the type analyzer and the
semantic analyzer, starting from compTopLelve, already contain mention
of Integer (and the other basic types).

| And Integer depends on large part of algebra.  So I would say that such
| basic compiler while a noble goal would require substantial algebra
| rewrite.  Such rewrite in turn need something like Aldor post facto
| extension.

By "simple type", I don't expect the basic type to understand beyond
simple operations defined on their domains.  

The glorious version of Integer is not needed wholesale when starting
the boostrap process.  The glorification is a set that needs to come
after.  Yes, post facto extensions are ways to achieve late
glorification -- and if you look at the practice, this is not fancy;
just think "type classes" (Haskell), which Axiom would have invented
two decades ago if it had post facto extensions.

| As an excercise I tried to make a minimal algebra.  I compiled
| about 20 very simple domains and categories and generated corresponding
| databses, but resulting interpreter was non-functional.  More effort
| would probably give functional system, but ATM I am not sure if such
| system is useful for bootstrap.

I don't think the interpreter is a good way tp arrive to the
bootstrap.  We must be in "type checking" mode, not "type inferencing"
mode where we will be trying to infer and load things.  No, that way
lies madness.

| > We must also be able to process a file without first having to split
| > it into several chunks.  We have been able to process SPAD files that
| > way; making )abbrev a no-op.
| > 
| 
| In longer run sure.

Well, Axiom has 25-year horizon; so not sure what you mean by 
"longer run" :-)

| ATM I am using quite different method: I dumped
| parse trees of the whole Axiom algebra into a file.  So now I can load
| the whole algebra just as a single S-expression. 

Well, (almost) everything is an S-expression; so I must ask which
"form" do you save an load?  The parse tree?  the parse form?  The
internal AST? or the generated Lisp code?

What other thing we have been doing, we have found both the parse form
(not the parse tree) and the internal AST useful to save and load later.
A third form, not conveniently present in Axiom at the moment, is one
where either the parse form or the internal AST is completely typed
(just before code generation).

| I am loading this
| S-expression into sbcl running various analyses on it.  The idea is to
| write (in Lisp) a simple compiler capable of extracting type declarations
| and generating from them Axiom databases.

Oh, that is simply done in Boot and I do hope you don't go to Lisp for
that.  Just catch the parse form from postTranform or parseTransform.

I do sincerely hope, we don't end up multiplying parsers, analyzers,
type checkers, macro expanders, each with its own share of bugs, and
mix all those in form or Axiom!

[...]

| Concerning abbrev declaration: I am not sure how to find out wether
| something is a package or a domain without using information from
| abbrevs.

We should get to a poing where we don't need to distinsguish that!

Now, if you look at a capsule, it tells your whether something "is"
for a domain or not by the presence or absence of 'domain in the
category declaration.  Again look at the the internal AST produced by 
parseTransform.

I'm sorry the whole documentation is not online yet, but many things
are happening and I need to petition for 48h in a day.

Th algebra interface to the parser is very simple minded.  There is
work going on to define different levels of fully typed ASTs.


-- Gaby


--=-=-=

-- Written by Gabriel Dos Reis (gdr AT cs DOT tamu DOT edu)
-- Last modified on Jan 15, 2007.
--
-- This file contains a low-level code for parsing
-- a Spad source file into an internal AST.  The
-- AST, for the entire file, is presented as a list of
-- toplevel statements (mostly definitions).
-- Since this is low-level code, I don't expect people
-- to get here, and you cannot directly use it.  If you think, 
-- you need to get to here, then something is already wrong.
-- There is a higher-level interface, written in SPAD, to this
-- code.  See gdr-spad-parser.spad.
--
-- To use this file:
--    (1) translate it to Common Lisp, with bootsys:
--         bootsys -batch -eval '(boottran::boottoclc "gdr-reader.boot")'
--
--    (2) compile gdr-spad-parser.spad
--
--


gdrParseSpadFile sourceFile ==
  $SPAD : local := true                        -- we are parsing Spad, 
  $BOOT : local := false                       --   not Boot.

  OUT_-STREAM := _*STANDARD_-OUTPUT_*          -- spit any noise to
                                               -- the standard output
  -- we need to tell the post-parsing transformers that we're compiling;
  -- few parse forms have slightly different representations
  -- depending on whether we are in interpreter mode or compiler mode.
  savedInteractiveMode := $InteractiveMode
  $InteractiveMode := false
  oldParserAutoloadOnceTrigger()               -- load parsing functions
  oldCompilerAutoloadOnceTrigger()
  INIT_-BOOT_/SPAD_-READER()
  savedInStream := IN_-STREAM                  -- we need to restore the
                                               -- global input stream state
                                               -- after we finished messing
                                               -- with it
  IN_-STREAM := MAKE_-INSTREAM sourceFile
  INITIALIZE_-PREPARSE IN_-STREAM
  asts := []                                   -- accumulates parse trees
                                               -- for all definitions in 
                                               -- sourceFile.
  while ^(_*EOF_* or FILE_-CLOSED) repeat
     BOOT_-LINE_-STACK := PREPARSE IN_-STREAM
     LINE := CDAR BOOT_-LINE_-STACK
     PARSE_-NewExpr()
     pt := POP_-STACK_-1()                     -- get the parse tree
     pf := postTransform pt                    -- turn it into a parse form
     ast := parseTransform pf                  -- finally into an AST
     asts := cons([pf, ast], asts)
  IOCLEAR(IN_-STREAM, OUT_-STREAM)
  SHUT IN_-STREAM
  IN_-STREAM := savedInStream
  $InteractiveMode := savedInteractiveMode
  -- we accumulated the parse trees in reverse order
  -- of declarations.
  reverse asts


--=-=-=

Pair(T) ==> Record(first: T, second: T)
AST ==> SExpression

)abbrev package SPADPRSR SpadParser
++ This package provides a simple minded interface to the SPAD parser.
++ Over time, we will add belts and whistles.

SpadParser(): Public == Private where
  Public == with
    parse: String -> List AST ++ parse(f) parses the source file f
                              ++ and returns the result as a list of
                              ++ pair of ASTs.  The first component
                              ++ of a pair is a parse form, and
                              ++ the second compoenent is the internal AST.
                              ++ Each pair on the list represents a
                              ++ toplevel definition.
  Private == add
    spadReaderInitialized : Boolean := false
                              -- guards against multiple parser 
                              -- definitions.

    parse(source: String) : List AST ==
      if not spadReaderInitialized then
         LOAD("gdr-reader.clisp")$Lisp
         spadReaderInitialized := true
      ast : List SExpression := gdrParseSpadFile(source)$Lisp
      ast


\start
Date: Wed, 7 Feb 2007 04:40:00 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Algebra bootstrap

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | Current compiler (before algebra bootstrap) does not know about Integer.
> 
> I don't think so.  
> 
> The internal AST that eventually reaches the type analyzer and the
> semantic analyzer, starting from compTopLelve, already contain mention
> of Integer (and the other basic types).
>

Try starting with minimal databases.  You will get messages as:

Integer is not a known type

or

Boolean is not a known type

Compiler do have _some_ knowledge: Record, Union, Mapping and
Enumeration are built-in.  There are some more or less random
pieces of information hardcoded in various parts of the compiler.
But Integer, Boolean and List are recognized only if present in
databeses.

Note that already postTransform uses semantic information:

postAtom x ==
  $BOOT => x
  x=0 => '(Zero)
  x=1 => '(One)
  EQ(x,'T) => 'T_$ -- rename T in spad code to T$
  IDENTP x and GETDATABASE(x,'NILADIC) => LIST x
  x
               ^^^^^^^^^^^^^^^^^^^^^^^

and parseTransform (more precisely parseHas) again preforms database
lookup. 
 
> | And Integer depends on large part of algebra.  So I would say that such
> | basic compiler while a noble goal would require substantial algebra
> | rewrite.  Such rewrite in turn need something like Aldor post facto
> | extension.
> 
> By "simple type", I don't expect the basic type to understand beyond
> simple operations defined on their domains.  
> 
> The glorious version of Integer is not needed wholesale when starting
> the boostrap process.  The glorification is a set that needs to come
> after.  Yes, post facto extensions are ways to achieve late
> glorification -- and if you look at the practice, this is not fancy;
> just think "type classes" (Haskell), which Axiom would have invented
> two decades ago if it had post facto extensions.
> 

I use the following Integer for bootstrap:

)abbrev category INS IntegerNumberSystem
IntegerNumberSystem(): Category == with nil
)abbrev domain INT Integer
Integer: IntegerNumberSystem with
    FakeIdentityToAppeaseSpad: % -> %
  == add
    FakeIdentityToAppeaseSpad(x) == x

This is enough to convince compiler that Integer is a valid type.  I do
not see how better Integer will help in bootstrap.  More precisely to
bootstrap you need to resolve forward references.  And the problem is
that in _last_ bootstrap pass there is a lot of forward references.
I do not think that will help resolve those references.

I guess that you think about something like classic compiler bootstrap,
where you need to get translator for small language running and than
you can use it to translate rest of the compiler.  In particular such
set of basic domains would allow to write large part of compiler in
Spad.  But current bootstrap problem is really all about databases,
we do not care if during database bootstrap we get correct code (or
any code at all), we just want to collect type declaration.  And
we need a lot of declarations in databases to start compiling
current Axiom algebra.

> | As an excercise I tried to make a minimal algebra.  I compiled
> | about 20 very simple domains and categories and generated corresponding
> | databses, but resulting interpreter was non-functional.  More effort
> | would probably give functional system, but ATM I am not sure if such
> | system is useful for bootstrap.
> 
> I don't think the interpreter is a good way tp arrive to the
> bootstrap.  We must be in "type checking" mode, not "type inferencing"
> mode where we will be trying to infer and load things.  No, that way
> lies madness.
> 

That was just a sanity check of what I did.  All I am saying here is
that my attempt to create small system failed (it does not mean that
other will fail -- I certainly did not try hard and gave up early).

> | > We must also be able to process a file without first having to split
> | > it into several chunks.  We have been able to process SPAD files that
> | > way; making )abbrev a no-op.
> | > 
> | 
> | In longer run sure.
> 
> Well, Axiom has 25-year horizon; so not sure what you mean by 
> "longer run" :-)
> 

Few months and longer.

> | ATM I am using quite different method: I dumped
> | parse trees of the whole Axiom algebra into a file.  So now I can load
> | the whole algebra just as a single S-expression. 
> 
> Well, (almost) everything is an S-expression; so I must ask which
> "form" do you save an load?  The parse tree?  the parse form?  The
> internal AST? or the generated Lisp code?
> 

I wrote: parse tree.  More precisely I took output of Meta parser, just
before call to postTransform.  I replaced call to postTransform by
call to a simple flattener (to replace nested trees having semicolon
as operator by lists) and pretty-printed the result of flattener 
(without flattening the expression had too much nesting and
pretty-printer could not print it correctly). 

> What other thing we have been doing, we have found both the parse form
> (not the parse tree) and the internal AST useful to save and load later.
> A third form, not conveniently present in Axiom at the moment, is one
> where either the parse form or the internal AST is completely typed
> (just before code generation).
> 
> | I am loading this
> | S-expression into sbcl running various analyses on it.  The idea is to
> | write (in Lisp) a simple compiler capable of extracting type declarations
> | and generating from them Axiom databases.
> 
> Oh, that is simply done in Boot and I do hope you don't go to Lisp for
> that.  Just catch the parse form from postTranform or parseTransform.
> 
> I do sincerely hope, we don't end up multiplying parsers, analyzers,
> type checkers, macro expanders, each with its own share of bugs, and
> mix all those in form or Axiom!
> 

My Lisp code is throw-away code (or research if you prefer such name).
The basic thing is that I am getting better turnaroud with sbcl.  
I can load the algebra tree into sbcl in about half of second (I am
loading it from a fasl).  Tree walk trough this tree takes small part
of second.  If I have large output most of the time is spent pretty-printing
the results, which may take few seconds.  If results are small the
whole run may finish in a second.  I do not see how I could get
such turnaroud working inside Axiom tree.  FYI, Axiom needed about
70 seconds to parse algebra -- I certainly do not want to loose
70 seconds each time I try something.

> [...]
> 
> | Concerning abbrev declaration: I am not sure how to find out wether
> | something is a package or a domain without using information from
> | abbrevs.
> 
> We should get to a poing where we don't need to distinsguish that!
> 
> Now, if you look at a capsule, it tells your whether something "is"
> for a domain or not by the presence or absence of 'domain in the
> category declaration.  Again look at the the internal AST produced by 
> parseTransform.
> 

I do not want to use output of parseTransform because it depends on
databases.  If databases miss some information the resulting tree
is incorrect (sometimes the compiler will later fix such a tree, but
many cases lead to errors).  

I think that currect Axiom apprach to compilation has serious flaw.
Namely postTransform and parseTransform are dane _before_ macro
expansion.  This means that they have only limited syntactic
information and some transformations just work blindly.  Both
parseTransform and postTransform compensate this lack of syntactic
data by use of semantic informations from databases.

I think that macro expansion should be done just after initial parse
(before any semantic transformations), that is why I have written
my macro expander.  BTW: current Axiom way allow pretty weird 
macro tricks, but it seems that algebra uses only small, well
behaved subset.

P.S. Thanks for the attached code.

\start
Date: Tue, 6 Feb 2007 23:11:24 -0500
From: Bill Page
To: Waldek Hebisch
Subject: RE: Algebra bootstrap

On February 6, 2007 6:33 PM Waldek Hebisch wrote:
>
> I have commited new algebra bootstrap to wh-sandbox.
> ...

Fantastic.

>
> I have commited it so that:
> - others can see details of bootstrap process

Thank you very much for providing this work so quickly.

> - I can kill Lisp embedded in algebra pamphlets
>

Waldek,

  Wy jeste=B6cie moimi bohaterem!

(You are my hero!)

\start
Date: 06 Feb 2007 23:00:27 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Algebra bootstrap

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Waldek Hebisch writes:
| > 
| > | Current compiler (before algebra bootstrap) does not know about Integer.
| > 
| > I don't think so.  
| > 
| > The internal AST that eventually reaches the type analyzer and the
| > semantic analyzer, starting from compTopLelve, already contain mention
| > of Integer (and the other basic types).
| >
| 
| Try starting with minimal databases.  You will get messages as:
| 
| Integer is not a known type
| 
| or
| 
| Boolean is not a known type

Yes, that adds evidence to my claim that the compiler knows about
Integer and other basic types: they are gotten through the databases,
and the compiler (in its current state) cannot do anything meaningful
without that knowledge.  That is what I meant.

| Compiler do have _some_ knowledge: Record, Union, Mapping and
| Enumeration are built-in.

Yes. Record, Union, and MApping are necessary.  

For Enumerations, I have not make my mind yet.  Som built-in support
is needed, but it is not clear to me that level of built-in is needed.

|  There are some more or less random
| pieces of information hardcoded in various parts of the compiler.

Yes, a systematic approach for restructuring the compiler (as well as
the interpreter) is needed.  No doubt.  My primary concern is about
laying down precisely the rules.  That needs some kind of basic "first
principles".  That is what I'm aiming at.  I largely regard the
current setting as a defective departure that needs correction.  The
question is what to correct?  And in which directions?  

| But Integer, Boolean and List are recognized only if present in
| databeses.

and if they are not, the compilation is screwed!  You cannot really
define them as "secondary", because they come as annotation for
constants,a nd they parser knows they must mean something.  They
really are "primary" from the compiler point of view.  The compiler
needs to query the database because, it believes that Integer has more
properties (e.g. Euclidean domain) than it assumes.  That is not the
case for a Record for example, neither for Mapping.  The case of List
is a bit curious.  However, my *guessing* from reading the code for
List is that it was realized that List can be assumed a basic domain,
but later enriched in an algebra file -- embryonic ideas for "post
facto extensions". 

| Note that already postTransform uses semantic information:
| 
| postAtom x ==
|   $BOOT => x
|   x=0 => '(Zero)
|   x=1 => '(One)
|   EQ(x,'T) => 'T_$ -- rename T in spad code to T$
|   IDENTP x and GETDATABASE(x,'NILADIC) => LIST x
|   x
|                ^^^^^^^^^^^^^^^^^^^^^^^

But that really is not semantic information -- you don't need to
evaluate "x" to know what it means.  That information is
purely syntactic, because you can infer it from purely syntactic
considerations looking at the parse form of a definition.

Now, if your point is that the post-parser transformer should be fixed
to clearly delimit the phase, the answer is yes.  As the key is
approach this from the angle of "what it ideally should do?"; then you
look at the current approximation and see where the defect is.

| and parseTransform (more precisely parseHas) again preforms database
| lookup. 

Much less than the interpreter.  Still before and during the type
checking phase, we don't need to consult the databas, except, except,
when we have an "import" statement.  But, even there I'm not sure
looking at the database is the right answer.

|  
| > | And Integer depends on large part of algebra.  So I would say that such
| > | basic compiler while a noble goal would require substantial algebra
| > | rewrite.  Such rewrite in turn need something like Aldor post facto
| > | extension.
| > 
| > By "simple type", I don't expect the basic type to understand beyond
| > simple operations defined on their domains.  
| > 
| > The glorious version of Integer is not needed wholesale when starting
| > the boostrap process.  The glorification is a set that needs to come
| > after.  Yes, post facto extensions are ways to achieve late
| > glorification -- and if you look at the practice, this is not fancy;
| > just think "type classes" (Haskell), which Axiom would have invented
| > two decades ago if it had post facto extensions.
| > 
| 
| I use the following Integer for bootstrap:
| 
| )abbrev category INS IntegerNumberSystem
| IntegerNumberSystem(): Category == with nil
| )abbrev domain INT Integer
| Integer: IntegerNumberSystem with
|     FakeIdentityToAppeaseSpad: % -> %
|   == add
|     FakeIdentityToAppeaseSpad(x) == x
| 
| This is enough to convince compiler that Integer is a valid type.  I do
| not see how better Integer will help in bootstrap.  More precisely to
| bootstrap you need to resolve forward references.  And the problem is
| that in _last_ bootstrap pass there is a lot of forward references.
| I do not think that will help resolve those references.

No, but you're looking at a much higher level and you don't see the
trees. 

The question, for each individual uses of Integer is what is needed?
If you use "+", then the above fake is insufficient.
Where the "post factor" extensions helps is that you can add those
required operations as you go.  This process is very diffrent from
asserting that Integer belongs to a given caterogy.

| I guess that you think about something like classic compiler bootstrap,
| where you need to get translator for small language running and than
| you can use it to translate rest of the compiler.

Yes, but there is nothing un-classic here, except that the runtime
support is a Lisp system.  And precisely, we should take advantage of
that. You extend the small think and load it, and have an improved
version.  That is much simpler that the "classic" compiler bootstrap.
Remember, they bootstrapped Lisp before they bootstrapped C, so if
sometrhing is classic, it certainly is Lsip bootstrapping :-)

|  In particular such
| set of basic domains would allow to write large part of compiler in
| Spad. 

YES!

I believe, I already stated that many times in the past.
I evene recalled Bill saying that from his point of view Boot was
conceived as a mini-SPAD, but I would have to disagree with him on
several technical points :-)


| But current bootstrap problem is really all about databases,

Get rid of the databases, or said differently look at the database as
the final thing with the belts and whistles.  Don't design the
bootstrap process around it.  It is what you build as wrap up.  Think
of it as the .so or .a you ship to user.  You don't build your
compiler to depend on it for its own bootstrap.  You design your
compiler so that it can produce the library and use it.  Shift
perspective. 

| we do not care if during database bootstrap we get correct code (or
| any code at all),

We should care that we get correct code.  Compiler miscompilation is a
nightmarre to debug.

| we just want to collect type declaration.  

And most of this can be done at the abstract syntax level -- given the
relatively simple syntax.

| And
| we need a lot of declarations in databases to start compiling
| current Axiom algebra.

If we get to the point that the compiler can handle a unit
(e.g. source file) at a time, then you can rely on mutually recursive
definition to sort out the initial problem.

[...]

| > | > We must also be able to process a file without first having to split
| > | > it into several chunks.  We have been able to process SPAD files that
| > | > way; making )abbrev a no-op.
| > | > 
| > | 
| > | In longer run sure.
| > 
| > Well, Axiom has 25-year horizon; so not sure what you mean by 
| > "longer run" :-)
| > 
| 
| Few months and longer.

OK, that is nothing then :-)

| > | ATM I am using quite different method: I dumped
| > | parse trees of the whole Axiom algebra into a file.  So now I can load
| > | the whole algebra just as a single S-expression. 
| > 
| > Well, (almost) everything is an S-expression; so I must ask which
| > "form" do you save an load?  The parse tree?  the parse form?  The
| > internal AST? or the generated Lisp code?
| > 
| 
| I wrote: parse tree.  More precisely I took output of Meta parser, just
| before call to postTransform.  I replaced call to postTransform by
| call to a simple flattener (to replace nested trees having semicolon
| as operator by lists) and pretty-printed the result of flattener 
| (without flattening the expression had too much nesting and
| pretty-printer could not print it correctly). 

OK.  I'm nervous about having to duplicate the work of the post-parser
transformer.  It should be fixed so that you don't have to outsource
its job.

[...]

| My Lisp code is throw-away code (or research if you prefer such name).
| The basic thing is that I am getting better turnaroud with sbcl.  
| I can load the algebra tree into sbcl in about half of second (I am
| loading it from a fasl).  Tree walk trough this tree takes small part
| of second.  If I have large output most of the time is spent pretty-printing
| the results, which may take few seconds.  If results are small the
| whole run may finish in a second.  I do not see how I could get
| such turnaroud working inside Axiom tree.  FYI, Axiom needed about
| 70 seconds to parse algebra -- I certainly do not want to loose
| 70 seconds each time I try something.

Now, the question is whether it is an inherent inefficient in Axiom,
or its runtime system (GCL).  I know that some long time GCL users
have complained about GCL spending too much time doing unnecessary
work (mostly done on its behalf by GCC).

If it is an inherent deficiency in Axiom, we must know.

For example, there are many places in where an a-list is used, and
that a-list may induce in some places linear search -- when a
hash-table or just a good tree would have been better.  The 
the Environment (third slot of the triplet) is a horrible mess of
a-lists. 

| > [...]
| > 
| > | Concerning abbrev declaration: I am not sure how to find out wether
| > | something is a package or a domain without using information from
| > | abbrevs.
| > 
| > We should get to a poing where we don't need to distinsguish that!
| > 
| > Now, if you look at a capsule, it tells your whether something "is"
| > for a domain or not by the presence or absence of 'domain in the
| > category declaration.  Again look at the the internal AST produced by 
| > parseTransform.
| > 
| 
| I do not want to use output of parseTransform because it depends on
| databases. 

yes but the uses of the databases at that particular point are not
necessary. If you fix that, do you still need to duplicate the job?

| If databases miss some information the resulting tree
| is incorrect (sometimes the compiler will later fix such a tree, but
| many cases lead to errors).  

IF you can process a file in a whole -- which you can with the
skeleton I posted earlier -- you don't need to consult the databases.

| 
| I think that currect Axiom apprach to compilation has serious flaw.
| Namely postTransform and parseTransform are dane _before_ macro
| expansion.  This means that they have only limited syntactic
| information and some transformations just work blindly.  Both
| parseTransform and postTransform compensate this lack of syntactic
| data by use of semantic informations from databases.
| 
| I think that macro expansion should be done just after initial parse
| (before any semantic transformations), that is why I have written
| my macro expander.  BTW: current Axiom way allow pretty weird 
| macro tricks, but it seems that algebra uses only small, well
| behaved subset.

I believe I don't understand why the macro expansion *needs* to be
done before postTransform and parseTransform.  I'm not saying you're
wrong; I'm saying "can you elaborate?".

\start
Date: Thu, 8 Feb 2007 00:53:55 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: Re: Algebra bootstrap

Bill Page wrote:
> Waldek,
>
>   Wy jeste=B6cie moimi bohaterem!
>
> (You are my hero!)
>

You are welcome.  I hope my work will be useful.

\start
Date: 08 Feb 2007 22:48:38 +0100
From: Francois Maltey
To: Bill Page
Subject: Re: axiom in windows xp for an user who isn't root.

Dear Bill,

> msys is not necessary to use Axiom on windows - only if you
> need to build Axiom from source.
>
I install Axiom in Windows from the binary install.

> > I change rights of the axiom directory and the msys directory.
> > Now they are read/write/and others for all users.
> >
> It sounds like the AXIOM environment variable is not set.
> 
> To check the AXIOM variable go to:
>
>  Start/ControlPanel/System/Advanced/EnvironmentVariables

Many thanks ! This variable was set for root, not for the other user.

> and check that the 'System variables' table includes
>
>   Variable Name: AXIOM
>   Variable Value: c:/Program Files/axiom/mnt/windows

\start
Date: Fri, 09 Feb 2007 19:30:44 +0000
From: Vladimir Bondarenko
To: list
Subject: Most recent AXIOM release(s)?

Hello *,

I am wondering what is the latest AXIOM release for Linux?

When the next release for Windows is planned (at least approximately)?

Thanks in advance.

\start
Date: Fri, 9 Feb 2007 23:28:15 -0800
From: Brent Fulgham
To: list
Subject: Building Axiom

Trying to get Axiom to build on the Mac is pretty frustrating, mainly  
because the build fails on GCL.  Since I already have access to at  
least two (and possibly more) excellent Lisp implementations I  
regularly use, it would be great to use one of them instead.  (Or at  
least, use a precompiled GCL, if I have one on my system).

Has anyone made any progress working with Axiom in a non-GCL  
environment?

\start
Date: 10 Feb 2007 02:32:25 -0600
From: Gabriel Dos Reis
To: Brent Fulgham
Subject: Re: Building Axiom

Brent Fulgham writes:

| Trying to get Axiom to build on the Mac is pretty frustrating, mainly
| because the build fails on GCL.

There have been documented successful build reports on Mac OS/PowerPC.  So,
could you be more specific?  

\start
Date: 10 Feb 2007 09:50:07 +0100
From: Martin Rubey
To: Vladimir Bondarenko
Subject: Re: Most recent AXIOM release(s)?

Dear Vladimir,

Vladimir Bondarenko writes:

> I am wondering what is the latest AXIOM release for Linux?

there haven't been any "official" releases for quite a while. I recommend
checking out wh-sandbox, which seems to be quite good currently.

> When the next release for Windows is planned (at least approximately)?

Sorry, no windows. Bill?

Vladimir, did you consider taking the price for porting AldorUnit to Axiom?
Would be really nice!

\start
Date: 10 Feb 2007 12:17:26 +0100
From: Martin Rubey
To: Tim Daly
Subject: new AXIOM release(s)
Cc: Igor Khavkine

Dear Tim, *,

Tim Daly writes:

> So I'm resuming my role as "Lead Developer" and will generate a new release
> in the near future.

This is great news, Tim!

I believe, in fact, that this is one of your major strenghts!

> I'll try to pick up and merge some of the changes but not the whole new build
> system as it is still experimental.

Good luck!

I'll try to document the Taylor series patch provided by Igor Khakvine, so that
it is not only included in wh-sandbox, but also in trunk. (Although I accept
help, of course)

There are quite a few "fix proposed" issues on IssueTracker. If you find time
could you walk through them and send me mail like "please send documentation
for #xxx", I'll try to make an effort.

I have also documented parts of ystream.spad, find it attached below.

Martin

\documentclass{article}

\begin{document}
\title{ssolve.spad}
\author{Martin Rubey}
\maketitle
\begin{abstract}
\end{abstract}
\tableofcontents

<<pkg: YSTREAM ParadoxicalCombinatorsForStreams>>= 
)abbrev package YSTREAM ParadoxicalCombinatorsForStreams
++ Computation of fixed points of mappings on streams
++ Author: Burge, Watt (revised by Williamson)
++ Date Created: 1986
++ Date Last Updated: 21 October 1989
++ Keywords: stream, fixed point
++ Examples:
++ References:
ParadoxicalCombinatorsForStreams(A):Exports == Implementation where
  ++ This package implements fixed-point computations on streams.
  A  :   Type
  ST ==> Stream
  L  ==> List
  I  ==> Integer
 
  Exports ==> with
    Y: (ST A -> ST A) -> ST A
      ++ Y(f) computes a fixed point of the function f.
    Y: (L ST A -> L ST A,I) -> L ST A
      ++ Y(g,n) computes a fixed point of the function g, where g takes
      ++ a list of n streams and returns a list of n streams.
 
  Implementation ==> add
 
This package uses the internal representation of [[Stream]]. There we read:

\begin{verbatim}
    -- This description of the rep is not quite true.
    -- The Rep is a pair of one of three forms:
    --    [value: S,             rest: %]
    --    [nullstream:    Magic, NIL    ]
    --    [nonnullstream: Magic, fun: () -> %]
    -- Could use a record of unions if we could guarantee no tags.

    NullStream:    S := _$NullStream$Lisp    pretend S
    NonNullStream: S := _$NonNullStream$Lisp pretend S

    Rep := Record(firstElt: S, restOfStream: %)
\end{verbatim}

<<pkg: YSTREAM ParadoxicalCombinatorsForStreams>>=  
    Y f ==
      y : ST A := CONS(0$I,0$I)$Lisp
      j := f y
      RPLACA(y,frst j)$Lisp
      RPLACD(y,rst j)$Lisp
      y
@ 

Let [[f: ST -> ST]]. We create a new stream [[y]], which we leave
uninitialized. For the moment, I cannot explain why the compiler accepts
[[CONS(0$I,0$I)$Lisp]] as a stream. However, since [[Stream]]s are lazy, %
[[f y]] doesn't compute any elements of the stream. However, if [[f]] really
depends on its input, this dependence is then captured in the [[restOfStream]]
part of the record representing the stream. The next two lines replace
[[frstElt]] and [[restOfStream]] of [[y]] by those of [[j]], thus, now
[[restofStream]] of [[y]] depends on itself.

It seems that the $n$\textsuperscript{th} element of [[f y]] should only depend
on the first $n-1$ elements of [[y]]. For example, let us simulate the
computation of the first two elements of [[Y f]]: calling [[fun()]] returns the
first element $c_1$ of [[f y]]. Thus, [[Y f]] now equals $[c_1,\dots]$. Calling
[[fun()]] again, we have to get the second element of $f [c_1,\dots]$. Suppose
this equals $c_2$, and [[Y f]] now equals $[c_1,c_2,\dots]$.

<<pkg: YSTREAM ParadoxicalCombinatorsForStreams>>=  
    Y(g,n) ==
      x : L ST A := [CONS(0$I,0$I)$Lisp for i in 1..n]
      j := g x
      for xi in x for ji in j repeat
        RPLACA(xi,frst ji)$Lisp
        RPLACD(xi,rst ji)$Lisp
      x

\section{License}
<<license>>=
--Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
--All rights reserved.
--
--Redistribution and use in source and binary forms, with or without
--modification, are permitted provided that the following conditions are
--met:
--
--    - Redistributions of source code must retain the above copyright
--      notice, this list of conditions and the following disclaimer.
--
--    - Redistributions in binary form must reproduce the above copyright
--      notice, this list of conditions and the following disclaimer in
--      the documentation and/or other materials provided with the
--      distribution.
--
--    - Neither the name of The Numerical ALgorithms Group Ltd. nor the
--      names of its contributors may be used to endorse or promote products
--      derived from this software without specific prior written permission.
--
--THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
--IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
--TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
--PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
--OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
--EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
--PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
--PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
--LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
--NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
--SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
@
<<*>>=
<<license>>

<<pkg: YSTREAM ParadoxicalCombinatorsForStreams>>
@
\end{document}

\start
Date: Sat, 10 Feb 2007 18:56:49 +0600 (NOVT)
From: Andrey G. Grozin
To: list
Subject: build-improvements without external noweb: is it supposed to work?

Hello *,

I've just checked out build-improvements, ./configured it and started make:

grozin@gandalf ~/build-improvements $ make
Making in noweb
make[1]: Entering directory `/home/grozin/build-improvements/noweb/src'
cd c; make "CC=gcc -ansi -pedantic" "CFLAGS=" all
make[2]: Entering directory `/home/grozin/build-improvements/noweb/src/c'
notangle -Rheader errors.nw > errors.h
/bin/sh: notangle: command not found
make[2]: *** [errors.h] Error 127
make[2]: Leaving directory `/home/grozin/build-improvements/noweb/src/c'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/grozin/build-improvements/noweb/src'
make: *** [build/i686-pc-linux/bin/notangle] Error 2

I'll install noweb and try again. I just wonder: there is directory noweb, 
and, if external noweb is not found, it should be build? Or am I wrong?

While I'm at it, one more question. I have gcl 2.6.7 installed. It is in 
ansi mode (I need it for maxima). Will build-improvements build gcl in 
traditional mode from the sources in the gcl directory? Or it will simply 
fail? I'll see shortly, I just want to ask what it is supposed to do.

By the way, I use Gentoo current (very current, updated today :-). 
Build-improvements seems the best bet for constructing a reasonable 
ebuild, because it is distro-packager friendly. What do you think, is this 
branch ready for packaging? (I mean not the main portage tree, but an 
experimental overlay.) If not, when will it be ready for such wider 
testing by the Gentoo community?

\start
Date: 10 Feb 2007 11:28:53 -0600
From: Gabriel Dos Reis
To: Andrey G. Grozin
Subject: Re: build-improvements without external noweb: is it supposed to work?

Andrey G. Grozin writes:

| Hello *,
| 
| I've just checked out build-improvements, ./configured it and started make:
| 
| grozin@gandalf ~/build-improvements $ make
| Making in noweb
| make[1]: Entering directory `/home/grozin/build-improvements/noweb/src'
| cd c; make "CC=gcc -ansi -pedantic" "CFLAGS=" all
| make[2]: Entering directory `/home/grozin/build-improvements/noweb/src/c'
| notangle -Rheader errors.nw > errors.h
| /bin/sh: notangle: command not found
| make[2]: *** [errors.h] Error 127
| make[2]: Leaving directory `/home/grozin/build-improvements/noweb/src/c'
| make[1]: *** [all] Error 2
| make[1]: Leaving directory `/home/grozin/build-improvements/noweb/src'
| make: *** [build/i686-pc-linux/bin/notangle] Error 2
| 
| I'll install noweb and try again. I just wonder: there is directory
| noweb, and, if external noweb is not found, it should be build? Or am
| I wrong?

You're not doing anything wrong.  

This is a timestampe issue introduced recently when noweb was
unpackage in the source tree.  I should really fix that.
Here is how you can work around that:

    # from the top directory of the Axiom build-improvements branch
    # bring the timestamp up to date
    % (cd noweb/src/c/ && touch *.h *.c)
    # now issue make as usual
    % make
    
| While I'm at it, one more question. I have gcl 2.6.7 installed. It is
| in ansi mode (I need it for maxima). Will build-improvements build gcl
| in traditional mode from the sources in the gcl directory? Or it will
| simply fail? I'll see shortly, I just want to ask what it is supposed
| to do.

If gcl is visible from your PATH, then configure will pick it by
default and use it.  I have not tried gcl in ansi mode yet.
But, you can also convince Axiom's configure NOT to use the gcl from
your path (even if it found it):  add --without-gcl to your configure
command line.

| By the way, I use Gentoo current (very current, updated today
| :-). Build-improvements seems the best bet for constructing a
| reasonable ebuild, because it is distro-packager friendly. What do you
| think, is this branch ready for packaging?

one of the reasons why this branch was created was to make it
"distro-package friendly".  At the moment, I believe it supports the
traditional "./configure && make && make install", so it should be
ready for packaging.  However, it does not support cross-compilation
for deeper reasons.

| (I mean not the main
| portage tree, but an experimental overlay.) If not, when will it be
| ready for such wider testing by the Gentoo community?

It would be great if you could help in that regard!

\start
Date: Sat, 10 Feb 2007 12:49:20 -0800
From: Brent Fulgham
To: Gabriel Dos Reis
Subject: Re: Building Axiom

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Feb 10, 2007, at 12:32 AM, Gabriel Dos Reis wrote:

> Brent Fulgham writes:
>
> | Trying to get Axiom to build on the Mac is pretty frustrating,  
> mainly
> | because the build fails on GCL.
>
> There have been documented successful build reports on Mac OS/ 
> PowerPC.  So,
> could you be more specific?

I have not tried the Gold branch, but working from the "build  
improvements" branch (following the instructions shown on http:// 
wiki.axiom-developer.org/BuildAxiom):

Chaz:~/Projects/Lisp/Axiom/build-improvements brent$ ./configure
checking build system type... powerpc-apple-darwin8.8.0
checking host system type... powerpc-apple-darwin8.8.0
checking target system type... powerpc-apple-darwin8.8.0
checking for gmake... no
[...]
config.status: creating src/doc/Makefile
config.status: creating build/scripts/document
config.status: creating config/axiom-c-macros.h
config.status: config/axiom-c-macros.h is unchanged
building list of Algebra bootstrap files...done
extracting list of SPAD type definitions...done
Chaz:~/Projects/Lisp/Axiom/build-improvements brent$ make
if test "." != "." -a ! -d gcl; then \
    cp -r ./gcl .; \
fi; cd gcl; \
./configure --prefix=/Users/brent/Projects/Lisp/Axiom/build- 
improvements/build/powerpc-apple-darwin8.8.0 --disable-statsysbfd
                                  --enable-machine=powerpc-macosx -- 
enable-vssize=65536*2 --disable-tkconfig --disable-x --disable-xgcl && \
         make && make install
loading cache ./config.cache
checking host system type... powerpc-apple-darwin8.8.0
host=powerpc-apple-darwin8.8.0
enable_machine=powerpc-macosx
use=powerpc-macosx
checking for gcc... (cached) gcc
[...]

So far, so good.  But then terror strikes!

checking emacs info/dir... /Users/brent/Projects/Lisp/Axiom/build- 
improvements/build/powerpc-apple-darwin8.8.0/share/info/
checking for tcl/tk... checking for tclsh... (cached) tclsh
checking for main in -llieee... (cached) no
not found
checking alloca... yes
checking Checking for buggy gcc version from redhat... no
creating ./config.status
creating makedefc
sed: 62: conftest.s1: unescaped newline inside substitute pattern
creating windows/gcl.iss
sed: 62: conftest.s1: unescaped newline inside substitute pattern
creating windows/sysdir.bat
sed: 62: conftest.s1: unescaped newline inside substitute pattern
creating windows/install.lsp
sed: 62: conftest.s1: unescaped newline inside substitute pattern
creating h/gclincl.h
makedefc
add-defs1 powerpc-macosx
using powerpc-macosx.defs

The sed stuff is failing due to some kind of line-ending problem.   
Perhaps a UNIX/WINDOWS/MAC EOL issue?  Looking in a text editor  
doesn't show anything helpful.  Of course, once the autogeneration  
phase fails, everything else is broken after that point:

echo "ECHO start %1\lib\gcl-`cat majvers`.`cat minvers`\unixport\.exe  
- -dir %1\lib\gcl-`cat majvers`.`cat minvers`\unixport -libdir %1\lib 
\gcl-`cat majvers`.`cat minvers` -eval \"(setq si::*allow-gzipped- 
file* t)\" %1 %2 %3 %4 %5 %6 %7 %8 %9 >> gcli.bat" ) > /Users/brent/ 
Projects/Lisp/Axiom/build-improvements/gcl/bin/gclfinal.bat ; fi
(cd xbin ; cp ../bin/gcl .)
cd cmpnew && make gcl_collectfn.o
../unixport/saved_pre_gcl ../unixport/ -compile gcl_collectfn.lsp
make[2]: ../unixport/saved_pre_gcl: Command not found
make[2]: *** [gcl_collectfn.o] Error 127
make[1]: *** [cmpnew/gcl_collectfn.o] Error 2
make: *** [build/powerpc-apple-darwin8.8.0/bin/gcl] Error 2
Chaz:~/Projects/Lisp/Axiom/build-improvements brent$


Grr!

Waldek's version is no better for this error.

I could diff the 'official' GCL and Axiom GCL directories to see  
what's wrong, if that might be helpful.

If anyone has successfully built on Mac, please let me know if you  
had to do anything fancy.  I already tried adjusting my pathing to  
exclude my MacPorts stuff, but that didn't seem to help (using or not  
using it resulted in the same problem).

\start
Date: Sat, 10 Feb 2007 16:34:58 -0500
From: Bill Page
To: Martin Rubey, Vladimir Bondarenko
Subject: RE: Most recent AXIOM release(s)?

On February 10, 2007 3:50 AM Martin Rubey wrote:
> ...
> 
> Vladimir Bondarenko writes:
> 
> > When the next release for Windows is planned (at least 
> > approximately)?
> 
> Sorry, no windows. Bill?
> 

The build-improvements branch of Axiom builds on Windows.

\start
Date: Sat, 10 Feb 2007 18:50:45 -0800
From: Arthur Ralfs
To: list
Subject: )set output mathml on

This posting is in response to Andrey Grozin's questions here
http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00076.html
which were recently referenced by CY.

I wanted to get my mathml package delivering output.  Here's what I did.

1.  created output mathml section in src/interp/setvars.boot.pamphlet by
copying
    and modifying the tex section. Remember to add "<<outputmathmlCode>>" at
    end.
    Copied setvars.boot.pamphlet and ran notangle on it.
    From inside axiom ran )lisp (boottran::boottocl "tmp/setvars.boot")
    which put setvars.clisp into int/interp/setvars.clisp and then replaced
    the lisp in setvars.boot.pamphlet with that in setvars.clisp.
    code chunks:
     <<outputmathmlCode>>
     <<setOutputMathml>>
     <<describeSetOutputMathml>>
    variables:
        setOutputMathml
    $mathmlOutputStream
    $mathmlOutputFile
    $mathmlFormat
    describeSetOutputMathml

2.  create output mathml section in setvart.boot.pamphlet.
     Added line
    mathml        create output in MathML style         Off:CONSOLE
    to \section{output} table

    Added <<outputmathml>> to code chunk <<output>> in \section{output}
    code chunks:
     <<outputmathml>>
    variables:
    setOutputMathml
    $mathmlFormat
    $mathmlOutputFile

3.  Added
    ${OUT}/MMLFORM.o to Layer 17 of Makefile.pamphlet
    So far I've eliminated the analog of TEX1, doesn't seem to be needed.
      I added the line
    "mathml.spad.pamphlet (MMLFORM)" to layer 17 completed spad files.
    I added a dependency in my package so it needs to be in layer 17 rather
    than layer 14 where TEX appears.
    Incidentally why does TEX1 appear in layer 4 when it seems to depend
    on TEX which appears in layer 14?
    Added lines to SPADFILES  and DOCFILES.

4.  Added
    (|MathMLFormat| . MMLFORM)
    to exposed.lsp.pamphlet

5.  Added
    DONE mathml.spad.pamphlet
    DONE )abbrev package MMLFORM MathMLFormat
    to Lattice.pamphlet.
    Stepped through Lattice.pamphlet by searching for "TEX" and
    mimiced everthing for MMLFORM however I can't see that
    Lattice.pamphlet is actually used anymore.

6.  Added mathml.spad subsection to src/doc/axiom.bib.pamphlet.

7.  Added
mathmlFormat expr ==
  mml := '(MathMLFormat)
  mmlrep := '(String)
  formatFn := getFunctionFromDomain("coerce",mml,[$OutputForm])
  displayFn := getFunctionFromDomain("display",mml,[mmlrep])
  SPADCALL(SPADCALL(expr,formatFn),displayFn)
  TERPRI $mathmlOutputStream
  FORCE_-OUTPUT $mathmlOutputStream
  NIL

  to interp/i-output.boot.pamphlet

  To function "output(expr,domain)" add lines for mathml,e.g.
     "if $mathmlFormat then mathmlFormat expr".

After all this I successfully compile axiom (using gold branch) so
now I can do this:

(1) -> )set messages autoload off
(1) -> )set output tex on
(1) -> )set output mathml on
(1) -> (x+y)**2

         2           2
   (1)  y  + 2x y + x
$$
{y \sp 2}+{2 \  x \  y}+{x \sp 2}
\leqno(1)
$$

<math xmlns="http://www.w3.org/1998/Math/MathML" mathsize="big"
display="block">
<mrow><msup><mrow><mi>y</mi></mrow><mrow><mn>2</mn></mrow></msup></mrow><mo>+</mo><mrow><mn>2</mn><mo>&InvisibleTimes;</mo><mi>x</mi><mo>&InvisibleTimes;</mo><mi>y</mi></mrow><mo>+</mo><mrow><msup><mrow><mi>x</mi></mrow><mrow><mn>2</mn></mrow></msup></mrow>
</math>

                                                     Type: Polynomial
Integer

\start
Date: Sat, 10 Feb 2007 21:37:43 -0600
From: Tim Daly
To: Arthur Ralfs
Subject: )set output mathml on

> I wanted to get my mathml package delivering output....

Excellent. This seems to be a simple enough change that we could
pick it up quite quickly. There is a browser plugin by Sam Dooley,
a previous Axiom author, that handles MathML. I can't remember the
name though.

In order to pick up this work into the mainstream axiom it still
lacks a few pieces:

1) DOCUMENTATION. besides modifying the pamphlet files it would
   be useful if you could write down any understanding you gained
   about how the current code works and why you needed to change
   what you did. It's the 'WHY' that is most important to future
   people trying to follow your changes. Assume some other person
   is trying to understand and change your code 30 years later.
   Plus, if you made the effort to understand how Axiom works in
   some small piece, it is worth capturing that understanding so
   others can build on it. For instance, why does TEX1 appear 
   useless? What did you depend on that moved your code up the
   layer chain? Is there a 1-to-1 correspondence between MathML
   constructs and Axiom-Tex constructs? Does your code cover all
   the cases?



2) MORE DOCUMENTATION. I, and many others, do not know the details
   of MathML. Perhaps finding/referencing/writing some overview as
   well as adding bibliographic references would be useful. Look at
   dhmatrix.spad.pamphlet for an example of possible documentation.
   A discussion of the possible forms of equation output in Axiom
   and their generation by your code would make the whole change
   much easier to maintain and modify once they come out the MATHML 2.0



3) TESTS. MathML works for your example. But a reasonable test suite
   is needed to check the range of coverage and to make sure it doesn't
   get broken in the future. One of two approaches seem reasonable to
   me, although any reasonable test strategy is fine. You could either
   collect a large number of axiom input syntax expressions into a
   single file and run your code against this set, thus testing the
   robustness on "random" input you didn't create. You could also give
   some thought to a "coverage" test suite to show that you handle
   things like summation symbols, equation numbering, various bracing
   styles, tables, as well as the usual things like exponentiation, etc.

   This kind of testing really won't cover the "format" issues for 
   output and I'm not sure how we could do that. But it will test for
   code-breakage on random and constructed input. Axiom users can
   create their own output formats for their domains which is not
   constrained to follow "standard math".

   Please add your test files to the src/input/Makefile.



4) PATCH FILES. Run

     diff -Naur axiomfile.pamphlet yourfile.pamphlet >axiomfile.pamphlet.patch

   so we can see exactly what changed in each file. The "-Naur" option is
   the standard way to create axiom patch files.

This is really the only way to "get it off your desk" and into the
distribution. I try to pick up changes I understand "in the small"
which I can test but more glorious changes really require your effort.
Packaging changes to "get it off your desk" is three times more work.
I'd like to be able to pick things up that seem "simple" but since I'm
not the author I have no real ability to debug it when the merge breaks.
  
\start
Date: Sun, 11 Feb 2007 19:07:38 +0300
From: Vadim V. Zhytnikov
To: list
Subject: Re: new AXIOM release(s)

> Tim Daly writes:
> 
>> So I'm resuming my role as "Lead Developer" and will generate a new release
>> in the near future.
> 

This is really good news!

But maybe you find it possible to change the way
how Axiom releases are actually released.

1) IMHO publish release as CVS tree on SorceForge
is bad practice.  To make sure whether something
have changed or I still have some old release
I have to check all hundreds of files in CVS tree.
Publishing release as a single file (tarball)
is common practice and is much better IMHO.

2) I'd like to see some consistent version
numbering scheme for Axiom releases which
will last more than one year.  It will be
of great help for maintainers of .rpm and
.deb packages who package Axiom for
various Linux distributions and users
who use these packages.
Try to find axiom on www.rpmfind.com and
you'll see that now each packager invents
his own package numbering scheme - all
different.

I understand that both issues are purely
technical but I think they are important
enough from practical point of view.
After all this is question of identity.

\start
Date: 11 Feb 2007 10:21:50 -0600
From: Gabriel Dos Reis
To: Vadim V. Zhytnikov
Subject: Re: new AXIOM release(s)

Vadim V. Zhytnikov writes:

[...]

| 1) IMHO publish release as CVS tree on SorceForge
| is bad practice.  To make sure whether something
| have changed or I still have some old release
| I have to check all hundreds of files in CVS tree.
| Publishing release as a single file (tarball)
| is common practice and is much better IMHO.

Fully agreed.

| 
| 2) I'd like to see some consistent version
| numbering scheme for Axiom releases which
| will last more than one year.  It will be
| of great help for maintainers of .rpm and
| .deb packages who package Axiom for
| various Linux distributions and users
| who use these packages.

I propose the numbering X.Y.Z, with

  * X == major release number
  * Y == minor release number
  * Z == patch level release number

I propose that the next version be 3.5.0, with subsequent bug fix
releases, be 3.5.x.
When we merge build-improvements to trunk, I would suggest we bump it
to 4.0.0.

I also propose that on a regular bases (e.e.g 3 months), we make
either a patch release or a minor release; we make a major release
every year.  The latter assumes we have enough momentum.

[...]

| After all this is question of identity.

\start
Date: Sun, 11 Feb 2007 11:59:58 -0600
From: Tim Daly
To: Vadim V. Zhytnikov
Subject: new AXIOM release(s)

> 1) IMHO publish release as CVS tree on SorceForge is bad practice...

That's unlikely to change, at least by me. I'm only trying to maintain
the source tree, not the release of binaries. The sources also live at
savannah.nongnu.org (CVS), axiom-developer.org (arch), and 
sourceforge.net (SVN), as well as on google.

I could create a tarball and store it on these sites except for one
problem, ... time. I simply don't have the time. I'm not a company.
I'm one guy sitting in a room working on this at night and on weekends
as a hobby.  However, if you have the interest you could maintain
tarballs on these sites.  Advocacy is volunteering.

I put together a web page showing a grid of binaries and their
platforms (<http://daly.axiom-developer.org/axiombinary>) which was
mentioned on this list a while ago and, I believe, was picked up by
<http://wiki.axiom-developer.org> (I don't see it there now). However,
no one has contributed any binaries.



> 2) I'd like to see some consistent version numbering scheme....

Check the mailing list archives. We've had this discussion and
several schemes were proposed, such as the usual Major.Minor.Patch
schemes. We settled on a version scheme, which is consistent, 
which is machine checkable, and which has been used for years.

There is a VERSION variable in the top level Makefile.
This variable is changed with every new release of the source code.

This version is printed in the banner when Axiom starts:

                AXIOM Computer Algebra System
                Version: Axiom (September 2006)
      Timestamp: Thursday December 14, 2006 at 20:11:24

The Version: says what source release was used for the build.
The Timestamp: says what date and time the binary build occurred.

The VERSION variable is: boot::*build-version* which you can access:


 -> _*BUILD_-VERSION_*$Lisp
 (1) Axiom (September 2006)
                                              Type: SExpression

 -> )lisp *build-version*
 Value = "Axiom (September 2006)"

Since source releases occur (on a best-effort) basis every two months
there is no ambiguity to the Month-Year format. 


The TIMESTAMP variable is: boot::*yearweek* which you can access:

 -> _*YEARWEEK_*$Lisp
 (2) Thursday December 14, 2006 at 20:11:24 
                                              Type: SExpression

 -> )lisp *yearweek*
 Value = "Thursday December 14, 2006 at 20:11:24 "

The variable name "yearweek" comes from the fact that I used to release
Axiom on a weekly basis when I was at IBM and it was my primary job.

Tim

\start
Date: Sun, 11 Feb 2007 19:21:52 +0100
From: Gregory Vanuxem
To: list
Subject: Request for testing (Win32 users)

Hello,

I have uploaded a version of Axiom built on top of SBCL for Windows (32
bits).
So if you are a Windows user, you already know Axiom and you can spent some
time
for testing and reporting bugs I would really be happy.

Things that you have to know:

* You must know Axiom,
* You have an official version of Axiom (built on top of GCL) for Windows,
* You must know that this version comes with absolutely no warranty of any
kind,
* "How to use it" is not supported,
* Bug (that is, bug in this version not present in the official one) MUST be
  reported to vanuxemg at yahoo dot fr and not to the official Axiom bug
tracking systems,
* This is not the same version than the official one (the code differs),
* This is not a fork (code in this version is destined to be included in the
official version),
* The source code is NOT available (sorry, not yet),
* Do not discuss issues related to this version on the official Axiom
mailing lists unless
  this is explicitely permitted,
* This version contains a LOT of bugs,
* This version is based on an "experimental" version of SBCL so you'll
contribute to SBCL
  too if you find SBCL bugs, but do know that all of this is experimental,
* Do not trust its results.


It can be downloaded from:
http://perso.orange.fr/parabola/axiom-sbcl-win.tar.bz2

To use it, untar/unbzip2 it in a directory without space in its name (full
path without space).
Export the environment variable AXIOM, it must point to the directory that
contains
the algebra, bin etc... directories.

So for example:

set AXIOM=c:\somewhere\axiom-sbcl-win

and you can start it with

c:\somewhere\axiom-sbcl-win\bin\interpsys


One of the the most important thing to know is that this work is based on
the
work of Juergen Weiss (among others of course), he "ported" parts of Axiom
to the CMU Common Lisp system.

Many, many thanks to you, Juergen Weiss.

\start
Date: Sun, 11 Feb 2007 12:36:12 -0600
From: Tim Daly
To: Gregory Vanuxem
Subject: request for testing (Win32 users)

"Do not discuss issues related to this version on the official Axiom
mailing lists unless explicitly permitted"

Well, it's axiom. it's in development. this is the most likely place
to discuss it. you don't need permission to discuss anything on this
list (although some topics, like legal topics which have their own
list, can generate some pushback).

But if you want permission, you have mine for what that's worth.

It seems perfectly reasonable to discuss the SBCL effort here.

Tim

\start
Date: 11 Feb 2007 13:32:00 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: new AXIOM release(s)

Tim Daly writes:

[...]

| > 2) I'd like to see some consistent version numbering scheme....
| 
| Check the mailing list archives. We've had this discussion and
| several schemes were proposed, such as the usual Major.Minor.Patch
| schemes. We settled on a version scheme, which is consistent, 
| which is machine checkable, and which has been used for years.

The "machine checkable" thing is a non-argument.

There are other meaningful machine checkable alternative as well.

    % gcc -v 
    [...]
    gcc version 4.3.0 20070210 (experimental)

    % /usr/bin/gcc -v                                               ~
    [...]
    gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)

    % ld --version
    GNU ld version 2.15.94.0.2.2 20041220 (SuSE Linux)

\start
Date: Sun, 11 Feb 2007 14:40:44 -0500
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: Re: new AXIOM release(s)

Hi Gaby,

> I propose the numbering X.Y.Z, with
>
>   * X == major release number
>   * Y == minor release number
>   * Z == patch level release number
>
> I propose that the next version be 3.5.0, with subsequent bug fix
> releases, be 3.5.x.
> When we merge build-improvements to trunk, I would suggest we bump it
> to 4.0.0.
>
> I also propose that on a regular bases (e.e.g 3 months), we make
> either a patch release or a minor release; we make a major release
> every year.  The latter assumes we have enough momentum.

With a 3 months cycles, I think a schema like the ones used by Gentoo or Ubuntu
makes sense: 2007.3, 2007.6.....or 7.03, 7.06....where is clearly
visible when it was
released.

I say this because maybe there is no that many changes for the X.Y.Z
schema, even when I am aware that this is usually the standard.

Just my 0.005 cents.

\start
Date: Sun, 11 Feb 2007 22:46:11 +0300
From: Vadim V. Zhytnikov
To: Tim Daly
Subject: Re: new AXIOM release(s)

Tim Daly writes:
>> 1) IMHO publish release as CVS tree on SorceForge is bad practice...
> 
> That's unlikely to change, at least by me. I'm only trying to maintain
> the source tree, not the release of binaries. 

I mean only source release tarball not any binaries.

\start
Date: Sun, 11 Feb 2007 13:50:58 -0600 (CST)
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: new AXIOM release(s)

On Sun, 11 Feb 2007, Alfredo Portes wrote:

| Hi Gaby,
|
| > I propose the numbering X.Y.Z, with
| >
| >   * X == major release number
| >   * Y == minor release number
| >   * Z == patch level release number
| >
| > I propose that the next version be 3.5.0, with subsequent bug fix
| > releases, be 3.5.x.
| > When we merge build-improvements to trunk, I would suggest we bump it
| > to 4.0.0.
| >
| > I also propose that on a regular bases (e.e.g 3 months), we make
| > either a patch release or a minor release; we make a major release
| > every year.  The latter assumes we have enough momentum.
|
| With a 3 months cycles, I think a schema like the ones used by Gentoo or Ubuntu
| makes sense: 2007.3, 2007.6.....or 7.03, 7.06....where is clearly
| visible when it was
| released.

That also makes sense.

\start
Date: Sun, 11 Feb 2007 15:38:54 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Request for testing (Win32 users)

On February 11, 2007 1:22 PM Vanuxem Gr=E9gory wrote:
>
> I have uploaded a version of Axiom built on top of SBCL for
> Windows (32 bits). So if you are a Windows user, you already
> know Axiom and you can spent some time for testing and reporting
> bugs I would really be happy.

Great! I am very glad you are working on this.

>
> Things that you have to know:
>
> * You must know Axiom,
> * You have an official version of Axiom (built on top of GCL)
>   for Windows,

I do, I do. :-)

> * You must know that this version comes with absolutely no
>   warranty of any kind,
> * "How to use it" is not supported,

Isn't that already obvious and clear? I think this applies to
all open source projects including the open source version(s)
of Axiom.

> * Bug (that is, bug in this version not present in the
> official one) MUST be reported to vanuxemg at yahoo dot fr
> and not to the official Axiom bug tracking systems,

Do you prefer this for your own personal reasons? I do not see
why your work should not be included along with the other current
and experimental version of Axiom. It is possible to make special
provision (i.e. new categories) in the Axiom wiki IssueTracker
system to refer to your new version so that we can easily
distinguish to which version the issue applies.

> * This is not the same version than the official one (the
>   code differs),

I do not know what is really "official" any more. Juergen Weiss'
experimental version of Axiom on CMUCL has been discussed before
on this list and his original source code has been distributed.
Some of his changes have been incorporated into the "official"
sources in available via CVS and at SourceForge.

> * This is not a fork (code in this version is destined to be
> included in the official version),
> * The source code is NOT available (sorry, not yet),

I think it would be perfect if you would make this source available
as a branch in SVN at SourceForge.

> * Do not discuss issues related to this version on the official
>   Axiom mailing lists unless this is explicitly permitted,

As Tim Daly has already pointed out: no permission is required
to discuss any Axiom related issue on the "official" Axiom mailing
lists. In fact, discussing Axiom any other way seems rather
pointless to me.

> * This version contains a LOT of bugs,

I think that this is not a surprise and does not differ from other
current experimental versions of Axiom.

> * This version is based on an "experimental" version of SBCL so
>   you'll contribute to SBCL too if you find SBCL bugs, but do
>   know that all of this is experimental,

Great. I am very glad that someone has finally begun to work
publicly with Axiom on another version of Lisp.

> * Do not trust its results.
>

That applies to ALL computer algebra systems - even the expensive
commercial ones.

>
> It can be downloaded from:
> http://perso.orange.fr/parabola/axiom-sbcl-win.tar.bz2
>
> To use it, untar/unbzip2 it in a directory without space in its
> name (full path without space). Export the environment variable
> AXIOM, it must point to the directory that contains the algebra,
> bin etc... directories.
>
> So for example:
>
> set AXIOM=c:\somewhere\axiom-sbcl-win
>
> and you can start it with
>
> c:\somewhere\axiom-sbcl-win\bin\interpsys
>

Thank very much for making this available.

>
> One of the most important thing to know is that this work
> is based on the work of Juergen Weiss (among others of course),
> he "ported" parts of Axiom to the CMU Common Lisp system.
>
> Many, many thanks to you, Juergen Weiss.
>

Yes, as I have said before: Juergen's work on the CMU version
was (and still is) critically important to the current open
source version of Axiom. I think it would be great if someone
would take on the job of making the source for the CMU version
available in the SourceForge SVN repository. I think there may
be some people who would be willing to test it further and to
contribute changes and improvements.

I don't think we should be afraid to work on several different
versions of Axiom in parallel, especially when one of the stated
goals is to of the Axiom project is to support Axiom on a number
of different Common Lisp environments.

Thanks again, Greg, for making your work available!

\start
Date: Sun, 11 Feb 2007 16:24:54 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Request for testing (Win32 users)

You wrote:

> ...
> To use it, untar/unbzip2 it in a directory without space in its
> name (full path without space).
> Export the environment variable AXIOM, it must point to the
> directory that contains the algebra, bin etc... directories.
>
> So for example:
>
> set AXIOM=c:\somewhere\axiom-sbcl-win
>
> and you can start it with
>
> c:\somewhere\axiom-sbcl-win\bin\interpsys
> ...

I get the following result on by Windows XP SP2 system while
running under Cygwin, using 'wget ...' and 'tar xjvf' to
extract the binary and setting the AXIOM variable:

$ echo $AXIOM
/home/Administrator/axiom-sbcl-win

Administrator@asus ~/axiom-sbcl-win
$ /home/Administrator/axiom-sbcl-win/bin/interpsys
This is SBCL 1.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.

This is experimental prerelease support for the Windows platform: use
at your own risk.  "Your Kitten of Death awaits!"

   >> System error:
   The file ".\\" does not exist.


debugger invoked on a SB-INT:SIMPLE-CONTROL-ERROR:
  attempt to THROW to a tag that does not exist: |top_level|

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

(no restarts: If you didn't do this on purpose, please report it as a bug.)

("no debug information for frame")
0]

---------

Any idea what might be wrong?

\start
Date: Sun, 11 Feb 2007 22:53:03 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Request for testing (Win32 users)

> -----Message d'origine-----
> Greg,
>
> You wrote:
>
> > ...
> > To use it, untar/unbzip2 it in a directory without space in its
> > name (full path without space).
> > Export the environment variable AXIOM, it must point to the
> > directory that contains the algebra, bin etc... directories.
> >
> > So for example:
> >
> > set AXIOM=c:\somewhere\axiom-sbcl-win
> >
> > and you can start it with
> >
> > c:\somewhere\axiom-sbcl-win\bin\interpsys
> > ...
>
> I get the following result on by Windows XP SP2 system while
> running under Cygwin, using 'wget ...' and 'tar xjvf' to
> extract the binary and setting the AXIOM variable:
>
> $ echo $AXIOM
> /home/Administrator/axiom-sbcl-win

This is a native Windows application so SBCL does not
understand the path used (Cygwin specific).

\start
Date: Sun, 11 Feb 2007 19:31:57 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Request for testing (Win32 users)

Greg,

On February 11, 2007 4:53 PM you wrote:
> ...
> I wrote:
> > I get the following result on by Windows XP SP2 system while
> > running under Cygwin, using 'wget ...' and 'tar xjvf' to
> > extract the binary and setting the AXIOM variable:
> >
> > $ echo $AXIOM
> > /home/Administrator/axiom-sbcl-win
>
> This is a native Windows application so SBCL does not
> understand the path used (Cygwin specific).
>

Duh! I should have realized ... thanks.

You it works. Great job. I think this is a great step forward
for a fully ANSI-compliant common lisp implementation of Axiom.
I can't resist to ask: Have you tried building this version of
Axiom with GCL in ANSI mode?

Regards,
Bill Page.

PS. Could you explain the phrase: "Kitten of Death" :-)

Example output of axiom-sbcl-win on my Windows system:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Administrator.ASUS>set
AXIOM=C:\cygwin\home\Administrator\axiom-sbcl-win

C:\Documents and
Settings\Administrator.ASUS>C:\cygwin\home\Administrator\axiom-sbcl-win/b=
in/
interpsys

This is SBCL 1.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.

This is experimental prerelease support for the Windows platform: use
at your own risk.  "Your Kitten of Death awaits!"
-------------------------------------------------------------------------=
---
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-------------------------------------------------------------------------=
---
-

(1) -> integrate(1/sqrt(1-x^2),x)
   Loading
   ...
                 +--------+
                 |   2
                \|- x  + 1  - 1
   (1)  - 2atan(---------------)
                       x
                                          Type: Union(Expression
Integer,...)
(2) ->

\start
Date: Sun, 11 Feb 2007 22:29:12 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Request for testing (Win32 users)

Greg,

So far I have two problems with axiom-sbcl-win to report:

1) The )cd command does not work as expected. Here is an
   example with my comments marked --->

-------

C:\Documents and Settings\Administrator.ASUS\Desktop>set
AXIOM=C:\cygwin\home\Administrator\axiom-sbcl-win

C:\Documents and Settings\Administrator.ASUS\Desktop>cd "c:\Documents =
and
Settings\Administrator.ASUS\My Documents"

C:\Documents and Settings\Administrator.ASUS\My
Documents>C:\cygwin\home\Administrator\axiom-sbcl-win\bin\interpsys

This is SBCL 1.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.

This is experimental prerelease support for the Windows platform: use
at your own risk.  "Your Kitten of Death awaits!"
-------------------------------------------------------------------------=
---
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-------------------------------------------------------------------------=
---
-

(1) -> )sys cd
C:\Documents and Settings\Administrator.ASUS\My Documents

---> The current system path is correct.

(1) -> )cd
   The current AXIOM default directory is
      C:\Documents and Settings\Administrator.ASUS\

---> This current directory is wrong. So this file is not found.

(1) -> )co FOO.spad

   The file FOO.spad is needed but does not exist.

---> But we can set it explicitly

(1) -> )cd "C:\Documents and Settings\Administrator.ASUS\My Documents"
   The current AXIOM default directory is
      C:\Documents and Settings\Administrator.ASUS\My Documents\

---> Now it works.

(1) -> )co FOO.spad
   Compiling AXIOM source code from file
      C:\Documents and Settings\Administrator.ASUS\My Documents\FOO.spad
using old system compiler.
   ...

---> The package is compiled (FASL) and loaded and executes as
     expected. Great!

---------

Note: This problem occurs even if the path does not contain any
spaces.

But here is the second problem.

2) If I compile the same file twice, the existing compiler output is
not replaced:

(1) -> )co FOO.spad
   ...
   finalizing NRLIB FOO
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the path specified.
The system cannot find the path specified.

   >> System error:

Win32 Error [MoveFileW@8] - 183
Cannot create a file when that file already exists.

-----------

Note: This re-compile problem does *not* occur if the current
directory is set to a path that contains no spaces.

\start
Date: Mon, 12 Feb 2007 02:14:06 -0500
From: Cliff Yapp
To: list
Subject: SBCL and Axiom

Vanuxem Grgory wrote:
> Hello,
> 
> I have uploaded a version of Axiom built on top of SBCL for Windows (32
> bits).

Interesting!  Not being a Windows user I can't check this out directly, 
but it is good news.

I have a couple of questions concerning how this has been accomplished, 
although they may be premature:

1.  You mentioned Juergen Weiss's CMUCL port - did you alter that code 
to run on SBCL or use the techniques there as a guide and convert one of 
the other trees?

2.  Did you change the boot/SPAD compilers to output SBCL compliant lisp 
code, or hand tweak the lisp code produced by the "regular" compile?

Back when I took a run at SBCL + Axiom, one of the points that became 
quickly clear was that short of carrying through with a complete 
conversion of all boot code to lisp (a long term goal at the moment) or 
simply living with hand tweaked translator output for a large number of 
files at least the boot compiler and possibly the spad compiler would 
need to be adjusted to output ANSI lisp.  I was able to just about load 
the stand-alone bootstrap boot->lisp system after some tweaking, but I 
didn't carry much further than that.

Gaby has proceeded much deeper into the BOOT world than I was ever able 
to and the presence of old and new BOOT (shoe?) adds a rather unexpected 
twist.  The prospect of fixing BOTH variations to output correct code is 
not a particularly enjoyable one.  My hope was that the new BOOT (shoe) 
was the stand alone code in the boot directory, which I suspect would be 
somewhat simpler to get working as the first step in getting sbcl to 
support the complete build chain as it exists today in GCL.

Gaby, did SHOE ever reach a point where it could convert all of the 
Axiom BOOT code to lisp?  I recall there being a couple of different 
conventions between BOOT and SHOE but I don't remember the conclusion - 
  can the conversion be made?

\start
Date: 12 Feb 2007 08:14:41 -0600
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: SBCL and Axiom

Cliff Yapp writes:

[...]

| Gaby has proceeded much deeper into the BOOT world than I was ever
| able to and the presence of old and new BOOT (shoe?) adds a rather
| unexpected twist.  The prospect of fixing BOTH variations to output
| correct code is not a particularly enjoyable one.

It is wrong to have both variations around.  Old Boot should go away.
That is non negotiable.

|  My hope was that
| the new BOOT (shoe) was the stand alone code in the boot directory,
| which I suspect would be somewhat simpler to get working as the first
| step in getting sbcl to support the complete build chain as it exists
| today in GCL.

That is my understanding too.

| Gaby, did SHOE ever reach a point where it could convert all of the
| Axiom BOOT code to lisp?

We are almost there.  I've found that the new Boot is much simpler,
and more comfortable to work with.  

\start
Date: Mon, 12 Feb 2007 06:45:35 -0800 (PST)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: SBCL and Axiom


--- Gabriel Dos Reis wrote:

> Cliff Yapp writes:
> 
> [...]
> 
> | Gaby has proceeded much deeper into the BOOT world than I was ever
> | able to and the presence of old and new BOOT (shoe?) adds a rather
> | unexpected twist.  The prospect of fixing BOTH variations to output
> | correct code is not a particularly enjoyable one.
> 
> It is wrong to have both variations around.  Old Boot should go away.
> That is non negotiable.

Agreed.
 
> | Gaby, did SHOE ever reach a point where it could convert all of the
> | Axiom BOOT code to lisp?
> 
> We are almost there.  I've found that the new Boot is much simpler,
> and more comfortable to work with.  

Excellent news.  Is there anything I/we can do to help that process
along?  When we have that, I would like to take another run at getting
the complete bootstrap process working on sbcl.  Roughly, I think it
will work something like:

1.  Get boottocl working and compare the generated output to the
current output, and identify any differences.  Once we can generate the
same output, in theory Boot/Shoe should be functional.  I don't
anticipate any tremendous difficulty here based on my earlier
experiences.

2.  Once it is working, start tracking down gotchas that prevent the
generated lisp code from working in SBCL, and start tweaking BOOT to
generate correct results.  In one sense I would prefer to work directly
with the lisp code but I think that is too large a project to start
with - fixing BOOT to generate legal ANSI code should (hopefully) be a
relatively straightforward change.

3.  Once we can load the generated files from BOOT successfully, see if
the SPAD compiler also needs fixing.  If the translation is
SPAD->Boot->Lisp we should be OK, but I'm guessing it's SPAD->Lisp and
so more tweaking will be needed.  Hopefully the changes to BOOT will
map fairly readily to SPAD as well.

The completion of that process should leave us with a functional Axiom
on sbcl using the existing process and no hand tweaked lisp files other
than the ones that are lisp now, which I think is where we want to
start when merging portability changes back into the main tree given
the current build situation.  Hand tweaked lisp files that are supposed
to be autogenerated will work in specific cases but will be hard to
maintain, so I think we need to bite the bullet and go back to the
source.  Once we are running in sbcl using the existing bootstrap
process we can try many things (like asdf) without being forced to step
carefully around the build issues, which I think will help speed things
up.

\start
Date: Mon, 12 Feb 2007 08:58:11 -0600 (CST)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: SBCL and Axiom

On Mon, 12 Feb 2007, C Y wrote:

|
| --- Gabriel Dos Reis wrote:
|
| > Cliff Yapp writes:
| >
| > [...]
| >
| > | Gaby has proceeded much deeper into the BOOT world than I was ever
| > | able to and the presence of old and new BOOT (shoe?) adds a rather
| > | unexpected twist.  The prospect of fixing BOTH variations to output
| > | correct code is not a particularly enjoyable one.
| >
| > It is wrong to have both variations around.  Old Boot should go away.
| > That is non negotiable.
|
| Agreed.
|
| > | Gaby, did SHOE ever reach a point where it could convert all of the
| > | Axiom BOOT code to lisp?
| >
| > We are almost there.  I've found that the new Boot is much simpler,
| > and more comfortable to work with.
|
| Excellent news.  Is there anything I/we can do to help that process
| along?  When we have that, I would like to take another run at getting
| the complete bootstrap process working on sbcl.  Roughly, I think it
| will work something like:
|
| 1.  Get boottocl working and compare the generated output to the
| current output, and identify any differences.  Once we can generate the
| same output, in theory Boot/Shoe should be functional.  I don't
| anticipate any tremendous difficulty here based on my earlier
| experiences.

The New Boot translator has the command  boottran::boottoclc (no the
ending 'c') that includes the definitions being translated as comments
in the CL output.

I have to make a list of reserved words or "library" functions that
both Old Boot and New Boot use.  That should help you quickly focuse
on the "interesting" bits.

| 2.  Once it is working, start tracking down gotchas that prevent the
| generated lisp code from working in SBCL, and start tweaking BOOT to
| generate correct results.  In one sense I would prefer to work directly
| with the lisp code but I think that is too large a project to start
| with - fixing BOOT to generate legal ANSI code should (hopefully) be a
| relatively straightforward change.

Agreed.  I believe the Boot "language" shields us from many low-level
details and quickly move to the real issue.  I acknowledge that the
state we are now where it has been neglected is unfortunate.  I'll try
to do as much as I can.

| 3.  Once we can load the generated files from BOOT successfully, see if
| the SPAD compiler also needs fixing.  If the translation is
| SPAD->Boot->Lisp we should be OK, but I'm guessing it's SPAD->Lisp and
| so more tweaking will be needed.  Hopefully the changes to BOOT will
| map fairly readily to SPAD as well.

Yes.  Note also that the New Boot translator has the framework to
generate machine code (when told where the CL compiler is) from Boot
and load it in the running image at a go.

| The completion of that process should leave us with a functional Axiom
| on sbcl using the existing process and no hand tweaked lisp files other
| than the ones that are lisp now, which I think is where we want to
| start when merging portability changes back into the main tree given
| the current build situation.  Hand tweaked lisp files that are supposed
| to be autogenerated will work in specific cases but will be hard to
| maintain, so I think we need to bite the bullet and go back to the
| source.  Once we are running in sbcl using the existing bootstrap
| process we can try many things (like asdf) without being forced to step
| carefully around the build issues, which I think will help speed things
| up.

There are still some GCL-isms deeply embedded in Axiom.

\start
Date: Mon, 12 Feb 2007 17:24:43 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Request for testing (Win32 users)

Le dimanche 11 f=E9vrier 2007 =E0 19:31 -0500, Bill Page a =E9crit :
> Greg,
>
> On February 11, 2007 4:53 PM you wrote:
> > ...
> > I wrote:
> > > I get the following result on by Windows XP SP2 system while
> > > running under Cygwin, using 'wget ...' and 'tar xjvf' to
> > > extract the binary and setting the AXIOM variable:
> > >
> > > $ echo $AXIOM
> > > /home/Administrator/axiom-sbcl-win
> >
> > This is a native Windows application so SBCL does not
> > understand the path used (Cygwin specific).
> >
>
> Duh! I should have realized ... thanks.
>
> You it works. Great job. I think this is a great step forward
> for a fully ANSI-compliant common lisp implementation of Axiom.
> I can't resist to ask: Have you tried building this version of
> Axiom with GCL in ANSI mode?

No, I dropped support of GCL because of spurious bugs: (cond ...)
handled strangely (a runtime problem apparently). But I added some
modifications to allow it to run on the "ANSI" version of GCL. They are
not tested of course.

> Regards,
> Bill Page.
>
> PS. Could you explain the phrase: "Kitten of Death" :-)

No :-) It comes from the SBCL banner (on Windows only).

\start
Date: Mon, 12 Feb 2007 11:40:11 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Request for testing (Win32 users)
Cc: Camm Maguire

Earlier Gregory Vanuxem wrote:

> I have uploaded a version of Axiom built on top of SBCL for
> Windows (32 bits).
>
> It can be downloaded from:
> http://perso.orange.fr/parabola/axiom-sbcl-win.tar.bz2
> ...

On February 12, 2007 11:25 AM Gregory Vanuxem wrote:
> ...
> Le dimanche 11 f=E9vrier 2007 =E0 19:31 -0500, Bill Page a =E9crit :
> >
> > It works. Great job. I think this is a great step forward
> > for a fully ANSI-compliant common lisp implementation of Axiom.
> > I can't resist to ask: Have you tried building this version of
> > Axiom with GCL in ANSI mode?
>
> No, I dropped support of GCL because of spurious bugs: (cond ...)
> handled strangely (a runtime problem apparently). But I added
> some modifications to allow it to run on the "ANSI" version of
> GCL. They are not tested of course.
>

Thanks. I think the GCL main developer Camm Maquire would be
strongly motivated to help with ensuring that an ANSI version
of Axiom works with GCL, especially as a means to test and
improve GCL's support for ANSI. As I recall he is away for a
few more weeks but we should expect some comment from him on
this when he returns.

\start
Date: Mon, 12 Feb 2007 17:30:31 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Request for testing (Win32 users)

Le dimanche 11 f=E9vrier 2007 =E0 22:29 -0500, Bill Page a =E9crit :
> Greg,
>
> So far I have two problems with axiom-sbcl-win to report:
>
> 1) The )cd command does not work as expected. Here is an
>    example with my comments marked --->

Thanks for reporting these problems, they are added on my TODO list and
in fact the problem is more complex, we need some functions that
generate correct (portable) pathname. I have modified some functions in
this regards but I do not always use them. I (or we) will use them later
but these type of things (and a lot of other from my point of view) need
to be "uniformized" and well defined (the API and it's _REAL_
conformance to ANSI CL).

\start
Date: 12 Feb 2007 11:26:06 -0600
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: Request for testing (Win32 users)

Gregory Vanuxem writes:

| Le dimanche 11 f=E9vrier 2007 =E0 22:29 -0500, Bill Page a =E9crit :
| > Greg,
| >
| > So far I have two problems with axiom-sbcl-win to report:
| >
| > 1) The )cd command does not work as expected. Here is an
| >    example with my comments marked --->
|
| Thanks for reporting these problems, they are added on my TODO list and
| in fact the problem is more complex, we need some functions that
| generate correct (portable) pathname.

Aim for POSIX -- they already have done the work -- and have tools
that convert non-POSIX to POSIX.  In essence, that is what MinGW does
with the path names.

\start
Date: 12 Feb 2007 11:26:50 -0600
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: Request for testing (Win32 users)

Gregory Vanuxem writes:

| Le dimanche 11 f=E9vrier 2007 =E0 19:31 -0500, Bill Page a =E9crit :
| > Greg,
| >
| > On February 11, 2007 4:53 PM you wrote:
| > > ...
| > > I wrote:
| > > > I get the following result on by Windows XP SP2 system while
| > > > running under Cygwin, using 'wget ...' and 'tar xjvf' to
| > > > extract the binary and setting the AXIOM variable:
| > > >
| > > > $ echo $AXIOM
| > > > /home/Administrator/axiom-sbcl-win
| > >
| > > This is a native Windows application so SBCL does not
| > > understand the path used (Cygwin specific).
| > >
| >
| > Duh! I should have realized ... thanks.
| >
| > You it works. Great job. I think this is a great step forward
| > for a fully ANSI-compliant common lisp implementation of Axiom.
| > I can't resist to ask: Have you tried building this version of
| > Axiom with GCL in ANSI mode?
|
| No, I dropped support of GCL because of spurious bugs: (cond ...)
| handled strangely (a runtime problem apparently).

Are those known to GCL developers?

\start
Date: Mon, 12 Feb 2007 18:27:48 +0100
From: Gregory Vanuxem
To: Cliff Yapp
Subject: Re: SBCL and Axiom

Le lundi 12 f=E9vrier 2007 =E0 02:14 -0500, C Y a =E9crit :
> Vanuxem Gr=E9gory wrote:
> > Hello,
> >
> > I have uploaded a version of Axiom built on top of SBCL for Windows (32
> > bits).
>
> Interesting!  Not being a Windows user I can't check this out directly,
> but it is good news.
>
> I have a couple of questions concerning how this has been accomplished,
> although they may be premature:
>
> 1.  You mentioned Juergen Weiss's CMUCL port - did you alter that code
> to run on SBCL or use the techniques there as a guide and convert one of
> the other trees?

I completely based this work on the version of Juergen Weiss. My work
was essentially the one of an ant. I grepped the code for "cmu" added
support of SBCL and Clisp. After that I added some files and modified
bootsys so that it can be compiled on GCL, SBCL, Clisp and (for the fun)
Allegro CL. Finally I tried to fix as much as can bugs.

Juergen Weiss did an amazing work...

Of course there are some GLC'ish things in the boot code, as Gaby said
previously, that needed to be fixed. I must point out that what I have
done will need to be checked by Lisp specialists. The version that I'll
share will not be the one I'm working on. I added to this "shareable"
version a tons of things from the official Axiom such that it'll be easy
to diff it. But I intimately think that we have to reorganise, simplify,
factorise, develop and document the code when we will merge changes. I
already began to reorganise the code, this is a pain to work on, say
stream for example, when the code is disseminated everywhere...

>
> 2.  Did you change the boot/SPAD compilers to output SBCL compliant lisp
> code, or hand tweak the lisp code produced by the "regular" compile?

No the code (from spad, bootsys boot and old boot) produced by the version
on which I'm working (presumably the same than the official Axiom))
is compilable and "runnable" by SBCL, CMU [1] and Clisp.

>
> Back when I took a run at SBCL + Axiom, one of the points that became
> quickly clear was that short of carrying through with a complete
> conversion of all boot code to lisp (a long term goal at the moment) or
> simply living with hand tweaked translator output for a large number of
> files at least the boot compiler and possibly the spad compiler would
> need to be adjusted to output ANSI lisp.  I was able to just about load
> the stand-alone bootstrap boot->lisp system after some tweaking, but I
> didn't carry much further than that.
>
> Gaby has proceeded much deeper into the BOOT world than I was ever able
> to and the presence of old and new BOOT (shoe?) adds a rather unexpected
> twist.  The prospect of fixing BOTH variations to output correct code is
> not a particularly enjoyable one.  My hope was that the new BOOT (shoe)
> was the stand alone code in the boot directory, which I suspect would be
> somewhat simpler to get working as the first step in getting sbcl to
> support the complete build chain as it exists today in GCL.

Spad, bootsys boot and old boot can be compiled without problem
:-). It's really simple to add support of SBCL, Clisp, CMU and Allegro
(though I'm pretty sure some bugs remain) to bootsys.

I forgot to say one thing, I have not "ported" the socket code. I need
first to better understand some parts of Axiom relative to this.

Greg

PS : I have a couple of problems with CMU CL, it can not compile some
functions and I don't know why as of now.

\start
Date: Mon, 12 Feb 2007 18:29:45 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: Re: TR: Request for testing (Win32 users)

>From Bill Page:

> >
> > > * Bug (that is, bug in this version not present in the
> > > official one) MUST be reported to vanuxemg at yahoo dot fr
> > > and not to the official Axiom bug tracking systems,
> >
> > Do you prefer this for your own personal reasons? I do not see
> > why your work should not be included along with the other current
> > and experimental version of Axiom. It is possible to make special
> > provision (i.e. new categories) in the Axiom wiki IssueTracker
> > system to refer to your new version so that we can easily
> > distinguish to which version the issue applies.

Nothing personal. But for now the code is not public so this is
problematic. I prefer to not pollute official Axiom bugs tracker.

> > > * This is not the same version than the official one (the
> > >   code differs),
> >
> > I do not know what is really "official" any more. Juergen Weiss'
> > experimental version of Axiom on CMUCL has been discussed before
> > on this list and his original source code has been distributed.
> > Some of his changes have been incorporated into the "official"
> > sources in available via CVS and at SourceForge.
> >
> > > * This is not a fork (code in this version is destined to be
> > > included in the official version),
> > > * The source code is NOT available (sorry, not yet),
> >
> > I think it would be perfect if you would make this source available
> > as a branch in SVN at SourceForge.
> >
> > > * Do not discuss issues related to this version on the official
> > >   Axiom mailing lists unless this is explicitly permitted,
> >
> > As Tim Daly has already pointed out: no permission is required
> > to discuss any Axiom related issue on the "official" Axiom mailing
> > lists. In fact, discussing Axiom any other way seems rather
> > pointless to me.
> >
> > > * This version contains a LOT of bugs,
> >
> > I think that this is not a surprise and does not differ from other
> > current experimental versions of Axiom.
> >
> > > * This version is based on an "experimental" version of SBCL so
> > >   you'll contribute to SBCL too if you find SBCL bugs, but do
> > >   know that all of this is experimental,
> >
> > Great. I am very glad that someone has finally begun to work
> > publicly with Axiom on another version of Lisp.
> >
> > > * Do not trust its results.
> > >
> >
> > That applies to ALL computer algebra systems - even the expensive
> > commercial ones.
> >
> > >
> > > It can be downloaded from:
> > > http://perso.orange.fr/parabola/axiom-sbcl-win.tar.bz2
> > >
> > > To use it, untar/unbzip2 it in a directory without space in its
> > > name (full path without space). Export the environment variable
> > > AXIOM, it must point to the directory that contains the algebra,
> > > bin etc... directories.
> > >
> > > So for example:
> > >
> > > set AXIOM=c:\somewhere\axiom-sbcl-win
> > >
> > > and you can start it with
> > >
> > > c:\somewhere\axiom-sbcl-win\bin\interpsys
> > >
> >
> > Thank very much for making this available.
> >
> > >
> > > One of the most important thing to know is that this work
> > > is based on the work of Juergen Weiss (among others of course),
> > > he "ported" parts of Axiom to the CMU Common Lisp system.
> > >
> > > Many, many thanks to you, Juergen Weiss.
> > >
> >
> > Yes, as I have said before: Juergen's work on the CMU version
> > was (and still is) critically important to the current open
> > source version of Axiom. I think it would be great if someone
> > would take on the job of making the source for the CMU version
> > available in the SourceForge SVN repository. I think there may
> > be some people who would be willing to test it further and to
> > contribute changes and improvements.

There are, already, a lot of versions of Axiom (gold, silver,
build-improvements, wh-sandbox...), I do not want to add yet another
one. Don't know how this has to be handled.

\start
Date: 12 Feb 2007 11:45:40 -0600
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: SBCL and Axiom

Gregory Vanuxem writes:

[...]

| Juergen Weiss did an amazing work...

Yup.

| Of course there are some GLC'ish things in the boot code, as Gaby said
| previously, that needed to be fixed. I must point out that what I have
| done will need to be checked by Lisp specialists. The version that I'll
| share will not be the one I'm working on. I added to this "shareable"
| version a tons of things from the official Axiom such that it'll be easy
| to diff it. But I intimately think that we have to reorganise, simplify,
| factorise, develop and document the code when we will merge changes. I
| already began to reorganise the code, this is a pain to work on, say
| stream for example, when the code is disseminated everywhere...

It would be nice it your work (or the shareable version of it) could
be put on a branch...

[...]

| I forgot to say one thing, I have not "ported" the socket code. 

Ah, that one! :-)  don't worry about it -- as long as you don't fire
up sman and friends.

\start
Date: Mon, 12 Feb 2007 18:58:03 +0100
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: Request for testing (Win32 users)

Le lundi 12 f=E9vrier 2007 =E0 11:26 -0600, Gabriel Dos Reis a =E9crit :
> Gregory Vanuxem writes:
>
> | Le dimanche 11 f=E9vrier 2007 =E0 19:31 -0500, Bill Page a =E9crit :
> | > Greg,
> | >
> | > On February 11, 2007 4:53 PM you wrote:
> | > > ...
> | > > I wrote:
> | > > > I get the following result on by Windows XP SP2 system while
> | > > > running under Cygwin, using 'wget ...' and 'tar xjvf' to
> | > > > extract the binary and setting the AXIOM variable:
> | > > >
> | > > > $ echo $AXIOM
> | > > > /home/Administrator/axiom-sbcl-win
> | > >
> | > > This is a native Windows application so SBCL does not
> | > > understand the path used (Cygwin specific).
> | > >
> | >
> | > Duh! I should have realized ... thanks.
> | >
> | > You it works. Great job. I think this is a great step forward
> | > for a fully ANSI-compliant common lisp implementation of Axiom.
> | > I can't resist to ask: Have you tried building this version of
> | > Axiom with GCL in ANSI mode?
> |
> | No, I dropped support of GCL because of spurious bugs: (cond ...)
> | handled strangely (a runtime problem apparently).
>
> Are those known to GCL developers?

The big problem is to find a simple way to reproduce it, I haven't one.
I have sent a bug report (for GCL-2.7) to Camm ("Disparition of a
condition ?") and it may be similar to the one in gcl-2.6.8pre so... The
big problem is that I'm alone with this bug, Bill and Waldek does not
have this bug. The bug is (on 2.6.8):

(1) -> )set br query
(1) -> 1/0

   >> Error detected within library code:
   division by zero


   You have two options. Enter:
     top        to return to top level, or
     break      to enter a LISP break loop.

   Please enter your choice now:

Normally we have three choices... (and the code looks correct, I don't
understand).

I dropped support of GCL, but that does not mean I don't want to support
GCL. The code on which I'm working is destined to be included on a
version that supports GCL.

\start
Date: Mon, 12 Feb 2007 20:18:47 +0100 (CET)
From: Waldek Hebisch
To: Brent Fulgham
Subject: Re: Building Axiom

Brent Fulgham wrote:
> Trying to get Axiom to build on the Mac is pretty frustrating, mainly  
> because the build fails on GCL.  Since I already have access to at  
> least two (and possibly more) excellent Lisp implementations I  
> regularly use, it would be great to use one of them instead.  (Or at  
> least, use a precompiled GCL, if I have one on my system).
> 

Have you tried to use precompiled GCL?  On Linux I regulary use
such method:

GCL=/path/to/gcl ../wh-sandbox/configure

There is a little catch:  last time I chcecked build did not work
with ANSI version of GCL.  But gcl-2.6.7 and 2.6.8 worked fine.

\start
Date: Mon, 12 Feb 2007 21:43:39 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Bug 312

I would like here to make some remarks concering bug 312.  First,
this bug is really in 'powern' function defined in 
'sttaylor.spad.pamphlet'.  Below is (corrected) version contained
in wh-sandbox:

      powern(rn,x) ==
        order : I := 0
        for n in 0.. repeat
          empty? x => return zro()
          not zero? frst x => (order := n; leave x)
          x := rst x
          n = 1000 =>
            error "**: series with many leading zero coefficients"
        (ord := (order exquo denom(rn))) case "failed" =>
          error "**: rational power does not exist"
        co := frst x
        if ord > 0 and rn < 0 then
           error "**: negative power does not exist"
        (invCo := recip co) case "failed" =>
           error "** rational power of coefficient undefined"
-- This error message is misleading, isn't it? see sups.spad/cRationalPower
        power :=
--          one? co => YS(powerrn(rn,x,#1))
          (co = 1) => YS(powerrn(rn,x,#1))
          (denom rn) = 1 =>
            not negative?(num := numer rn) =>
-- It seems that this cannot happen, but I don't know why
              (co**num::NNI) * YS(powerrn(rn,(invCo :: A) * x,#1))
            (invCo :: A)**((-num)::NNI) * YS(powerrn(rn,(invCo :: A) * x,#1))
          RATPOWERS => co**rn * YS(powerrn(rn,(invCo :: A) * x,#1))
          error "** rational power of coefficient undefined"
        monom(1,(ord :: I) * numer(rn)) * power

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

At first glance this function looks cryptic.  But look at documentation:

      powern : (RN,ST A) -> ST A
        ++ powern(r,f) raises power series f to the power r.

So 'powern' is supposed to raises Taylor series to a rational power.
How one can to such thing?  If Taylor series has form f=1+c_1*x+...
(the lowest order term is zero) one can recursively compute coefficients
using the fact that:

  (f+a*x^n)^r = f^r+r*a*x^n mod x^(n+1)

Axiom code uses YS operator to solve this reccurence: this is done
in assignment to 'power' variable.

If the series has non-zero, non one lowest order term, that is

f = c_0*(1+c_1*x+...),

we just have to divide f by c_0 and multiply the result by
c_0^r (this is also handled in the assignment to power).

So the remaining case is when the lowest order term is 0.  In this
case 

f = x^a*f_1 

where f_1 has non-zero lowest order term.  We handle f_1 by earlier
method while (x^a)^r = x^(a*r).  However, we want a Taylor series
as a result, so we must require that a*r is a natural number.

Now, the first part of 'powern' handles splitting this power of x:

        order : I := 0
        for n in 0.. repeat
          empty? x => return zro()
          not zero? frst x => (order := n; leave x)
          x := rst x
          n = 1000 =>
            error "**: series with many leading zero coefficients"

(note that 'x' in the code is what I call 'f' above, while my 'a' is
called 'order' in the code).  Next, we check that order*r is an 
integer:

        (ord := (order exquo denom(rn))) case "failed" =>
          error "**: rational power does not exist"

Remember first nonzero coefficient:

        co := frst x

Check that we get nonnegative order*r:

        if ord > 0 and rn < 0 then
           error "**: negative power does not exist"

I skip assignment to power (explained eariler).  Finally we have
to multiply the result by correct power of 'x':

        monom(1,(ord :: I) * numer(rn)) * power

(note that ord = order/denom(rn), so ord * numer(rn) = order*rn).

Checking in SVN archive shows that the last line was omitted in
revision 19.  The change in revision 19 added support for negative
integer powers, it is clear that omission of last line was
unintentional.

\start
Date: 12 Feb 2007 15:59:31 -0600
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: TR: Request for testing (Win32 users)

[...]

| > > Yes, as I have said before: Juergen's work on the CMU version
| > > was (and still is) critically important to the current open
| > > source version of Axiom. I think it would be great if someone
| > > would take on the job of making the source for the CMU version
| > > available in the SourceForge SVN repository. I think there may
| > > be some people who would be willing to test it further and to
| > > contribute changes and improvements.
|
| There are, already, a lot of versions of Axiom (gold, silver,
| build-improvements, wh-sandbox...), I do not want to add yet another
| one. Don't know how this has to be handled.

The more the merrier.

\start
Date: Mon, 12 Feb 2007 14:20:27 -0800 (PST)
From: Cliff Yapp
To: Gabriel Dos Reis, regory Vanuxem
Subject: Re: TR: Request for testing (Win32 users)

--- Gabriel Dos Reis wrote:

> | There are, already, a lot of versions of Axiom (gold, silver,
> | build-improvements, wh-sandbox...), I do not want to add yet
> | another one. Don't know how this has to be handled.
> 
> The more the merrier.

At this point, I'd say with everyone exploring and testing at a very
basic level the only thing to do is to keep a list as best we can. 
Eventually things will probably come together as the best solutions
appear, but for a while it's going to be a bit crazy.

The requirement to document code in a literate fashion means the hurdle
to get code in the main tree is high, and that means a lot of
experimental branches will spring up as people do "not ready for prime
time" work.  In some ways this might actually keep people from assuming
Axiom is ready for uses it isn't really ready for, so it's not all bad.

Cheers,
CY

P.S. - is http://weitz.de/cl-fad/ of interest for the path issues?  For
sockets http://common-lisp.net/project/usocket/ might be of interest.

\start
Date: Tue, 13 Feb 2007 12:48:17 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: SBCL and Axiom

Gabriel Dos Reis wrote:
> Cliff Yapp writes:
> | Gaby, did SHOE ever reach a point where it could convert all of the
> | Axiom BOOT code to lisp?
> 
> We are almost there.  I've found that the new Boot is much simpler,
> and more comfortable to work with.  
> 

Gaby, how do you plan to avoid latent bugs due to semantic differences
between Boot and Shoe?  AFAICS Shoe accepts almast all (or maybe all)
Boot, but trying to use it results in build failure due to mistranslation.
Do you have a tool that can flag places where semantics of Boot and Shoe
differ?

\start
Date: Tue, 13 Feb 2007 06:58:14 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: SBCL and Axiom

On Tue, 13 Feb 2007, Waldek Hebisch wrote:

| Gabriel Dos Reis wrote:
| > Cliff Yapp writes:
| > | Gaby, did SHOE ever reach a point where it could convert all of the
| > | Axiom BOOT code to lisp?
| >
| > We are almost there.  I've found that the new Boot is much simpler,
| > and more comfortable to work with.
| >
|
| Gaby, how do you plan to avoid latent bugs due to semantic differences
| between Boot and Shoe?  AFAICS Shoe accepts almast all (or maybe all)
| Boot,

Almost -- not all.  If you run the New Boot translator on some files
in src/interp, you'll get syntax errors.

| but trying to use it results in build failure due to mistranslation.

What mistranslation?

| Do you have a tool that can flag places where semantics of Boot and Shoe
| differ?

No, but the only places I'm aware of where both languages differ
is in a tiny part of "built-in" or "library" functions.

To have a tool that does what you say, we must have the difference in
semantics documented.

The differences are apparent once we have the table in
front of our eyes, and there we can have a warning is we want.
For any other construct, I'm not aware of semantics difference.

\start
Date: Tue, 13 Feb 2007 15:02:43 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: SBCL and Axiom

Gabriel Dos Reis wrote:
> On Tue, 13 Feb 2007, Waldek Hebisch wrote:
> 
> | Gabriel Dos Reis wrote:
> | > Cliff Yapp writes:
> | > | Gaby, did SHOE ever reach a point where it could convert all of the
> | > | Axiom BOOT code to lisp?
> | >
> | > We are almost there.  I've found that the new Boot is much simpler,
> | > and more comfortable to work with.
> | >
> |
> | Gaby, how do you plan to avoid latent bugs due to semantic differences
> | between Boot and Shoe?  AFAICS Shoe accepts almast all (or maybe all)
> | Boot,
> 
> Almost -- not all.  If you run the New Boot translator on some files
> in src/interp, you'll get syntax errors.
> 
> | but trying to use it results in build failure due to mistranslation.
> 
> What mistranslation?
> 

Well, I tried once to compile all .boot files using Shoe.  IIRC I was
able to quckly handle syntax errors.  But the process quickly died
during algebra build: clearly SPAD compiler was mistranslated.

I now tried to just convert 'postpar.boot.pamphlet'.  First, quoted
symbols such as 'if 'in 'where where upcased (AFAIUI you call this
"library" differences).  I am not aware of any more problem with
'postpar.boot.pamphlet', but ATM build is in progress and it will
take some time to verify results.  However, I also noticed another
problem: Shoe mistranslates some where constructs.  In particular,
in as.boot.pamphlet we have function asCategoryParts which has
where clause defining three functions: main, build, and exportsOf.
main references exportsOf.  Shoe renames the three nested functions,
but fails to rename reference in main to exportsOf.

\start
Date: Tue, 13 Feb 2007 08:49:41 -0500
From: Cliff Yapp
To: Gregory Vanuxem
Subject: Re: SBCL and Axiom

Gregory Vanuxem wrote:

>> 1.  You mentioned Juergen Weiss's CMUCL port - did you alter that code 
>> to run on SBCL or use the techniques there as a guide and convert one of 
>> the other trees?
> 
> I completely based this work on the version of Juergen Weiss. My work
> was essentially the one of an ant. I grepped the code for "cmu" added
> support of SBCL and Clisp. After that I added some files and modified
> bootsys so that it can be compiled on GCL, SBCL, Clisp and (for the fun)
> Allegro CL. Finally I tried to fix as much as can bugs.

OK

> Juergen Weiss did an amazing work...

No question.  It's a shame that work didn't get more press way back when.

> Of course there are some GLC'ish things in the boot code, as Gaby said
> previously, that needed to be fixed. I must point out that what I have
> done will need to be checked by Lisp specialists. The version that I'll
> share will not be the one I'm working on. I added to this "shareable"
> version a tons of things from the official Axiom such that it'll be easy
> to diff it.

OK, sounds good.  I'm fooling around with asdf at the moment trying to 
figure out how to work with it, which may be a bit premature but will 
hopefully be useful later on.  (Don't know how well GCL/asdf play 
together, I've never successfully run asdf on GCL personally.)

> But I intimately think that we have to reorganise, simplify,
> factorise, develop and document the code when we will merge changes. I
> already began to reorganise the code, this is a pain to work on, say
> stream for example, when the code is disseminated everywhere...
> 
>> 2.  Did you change the boot/SPAD compilers to output SBCL compliant lisp 
>> code, or hand tweak the lisp code produced by the "regular" compile?
> 
> No the code (from spad, bootsys boot and old boot) produced by the version
> on which I'm working (presumably the same than the official Axiom))
> is compilable and "runnable" by SBCL, CMU [1] and Clisp.

Really??  That's excellent news, but rather surprising.

  > Spad, bootsys boot and old boot can be compiled without problem 
:-). It's really
> simple to add support of SBCL, Clisp, CMU and Allegro (though I'm pretty sure
> some bugs remain) to bootsys. 

Nice!  I have the code in the boot/ directory loading on sbcl as well, 
so it will be interesting to check what the various diffs look like.  I 
have tried running it on interp but I get what are probably the 
collisions between old boot and new boot Gaby mentioned before.

> I forgot to say one thing, I have not "ported" the socket code. I need
> first to better understand some parts of Axiom relative to this.

I'd say usockets and cl-fad might be of interest here (the links I 
provided in another email) but I don't have enough experience with 
either to know for sure.

\start
Date: 13 Feb 2007 16:22:43 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: document missing in installation

Dear Waldek,

it seems that version 434 of wh-sandbox seems to install "document" to
axiom/target/.../bin

Is this only on my machine?

Furthermore, it seems that my packages get recompiled in any case, even if I
only did a configure to change the prefix.

\start
Date: Wed, 14 Feb 2007 16:18:52 +0600 (NOVT)
From: Andrey G. Grozin
To: Gabriel Dos Reis
Subject: Re: build-improvements without external noweb: is it supposed to work?

I've installed noweb and did

./configure --prefix=/usr --infodir=/usr/share/info \
--mandir=/usr/share/man --without-gcl

(because my external gcl is ansi), then make. After some time, I've got

./../..//build/i686-pc-linux/bin/lisp -batch -eval \
                 '(progn (mapcar (function (lambda (x) (load x))) \
                         (quote ( "boothdr.o"  "exports.o"  "npextras.o" 
"stage0/ptyout.o"  "stage0/btincl2.o"  "stage0/btscan2.o" 
"stage0/typrops.o"  "stage0/btpile2.o"  "stage0/typars.o" 
"stage0/tytree1.o"))) \
                         (system::save-system "bootsys"))'

Error: The variable |
| is unbound.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by PROGN.
Broken at MAPCAR.  Type :H for Help.
>>

What should I do next?

\start
Date: Wed, 14 Feb 2007 08:36:25 -0600 (CST)
From: Gabriel Dos Reis
To: Andrey G. Grozin
Subject: Re: build-improvements without external noweb: is it supposed to work?

On Wed, 14 Feb 2007, Andrey G. Grozin wrote:

| Hello,
|
| I've installed noweb and did
|
| ./configure --prefix=/usr --infodir=/usr/share/info \
| --mandir=/usr/share/man --without-gcl
|
| (because my external gcl is ansi), then make. After some time, I've got
|
| ./../..//build/i686-pc-linux/bin/lisp -batch -eval \
|                  '(progn (mapcar (function (lambda (x) (load x))) \
|                          (quote ( "boothdr.o"  "exports.o"  "npextras.o"
| "stage0/ptyout.o"  "stage0/btincl2.o"  "stage0/btscan2.o"
| "stage0/typrops.o"  "stage0/btpile2.o"  "stage0/typars.o"
| "stage0/tytree1.o"))) \
|                          (system::save-system "bootsys"))'
|
| Error: The variable |
| | is unbound.
| Fast links are on: do (si::use-fast-links nil) for debugging
| Error signalled by PROGN.
| Broken at MAPCAR.  Type :H for Help.
| >>
|
| What should I do next?

This is a bug in GCL, also reported by Bill.  I'll check in a work
around for Axiom.

\start
Date: Wed, 14 Feb 2007 10:52:32 -0500
From: Bill Page
To: list
Subject: gcl and noweb in the build-improvements source	tree
Cc: Gabriel Dos Reis

Every time I download build-improvments on a new machine, I've been
thinking about the decision to include gcl and noweb source in the
Axiom source tree (in source format) in the SVN repository at
SourceForge. It seems to me that rather than having gcl inside the
tree

  /trunk
     ....
     /branches/wh-sandbox
    ...
     /branches/build-improvements
      /branches/build-improvements/gcl
      /branches/build-improvements/noweb
      ...

what we should have done is create a new root directory

  /trunk
     ....
     /branches/wh-sandbox
    ...
     /branches/build-improvements
    ...

  /extras
    /gcl
    /noweb
    ...

That way, it would be possible to avoid having to pull all the
source for gcl and noweb if these are already pre-installed.

\start
Date: Wed, 14 Feb 2007 10:59:50 -0500
From: Bill Page
To: Andrey G. Grozin
Subject: Re: build-improvements without external noweb:	is it supposed to work?
Cc: Gabriel Dos Reis

Quoting Andrey G. Grozin:

>
> I've installed noweb and did
>
> ./configure --prefix=/usr --infodir=/usr/share/info \
> --mandir=/usr/share/man --without-gcl
>
> (because my external gcl is ansi), then make. After some time, I've got
>
> ./../..//build/i686-pc-linux/bin/lisp -batch -eval \
>                  '(progn (mapcar (function (lambda (x) (load x))) \
>                          (quote ( "boothdr.o"  "exports.o"  "npextras.o"
> "stage0/ptyout.o"  "stage0/btincl2.o"  "stage0/btscan2.o"
> "stage0/typrops.o"  "stage0/btpile2.o"  "stage0/typars.o"
> "stage0/tytree1.o"))) \
>                          (system::save-system "bootsys"))'
>
> Error: The variable |
> | is unbound.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by PROGN.
> Broken at MAPCAR.  Type :H for Help.
>>>
>
> What should I do next?
>

Here is a patch that I use to solve this problem. It seems that at least
on some platforms, i.e. combinations of shell and/or make, gcl cannot
process the '-batch -eval' arguments in the the way one would expect.

---------

[page@axiom-developer axiom.build-improvements]$ diff -u 
src/boot/Makefile.pamp
hlet.orig src/boot/Makefile.pamphlet.new
--- src/boot/Makefile.pamphlet.orig     2007-02-14 09:53:36.000000000 -0600
+++ src/boot/Makefile.pamphlet.new      2007-02-14 09:55:32.000000000 -0600
@@ -1341,10 +1341,10 @@
  and saving the resulting image back on disk.
  <<build bootsys>>=
  bootsys$(EXEEXT): $(OBJECTS)
-       $(LOADSYS) -batch -eval \
+       echo \
                 '(progn (mapcar (function (lambda (x) (load x))) \
                         (quote ($(patsubst %, "%", $(OBJECTS))))) \
-                       (system::save-system "$@"))'
+                       (system::save-system "$@"))' | $(LOADSYS
  @

  The make rule [[bootsys]] is executed through a recursive call to [[$(MAKE)]]

\start
Date: Wed, 14 Feb 2007 10:06:27 -0600 (CST)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements without external noweb: is it supposed to work?

| Quoting Andrey G. Grozin:
|
| >
| > I've installed noweb and did
| >
| > ./configure --prefix=/usr --infodir=/usr/share/info \
| > --mandir=/usr/share/man --without-gcl
| >
| > (because my external gcl is ansi), then make. After some time, I've got
| >
| > ./../..//build/i686-pc-linux/bin/lisp -batch -eval \
| >                  '(progn (mapcar (function (lambda (x) (load x))) \
| >                          (quote ( "boothdr.o"  "exports.o"  "npextras.o"
| > "stage0/ptyout.o"  "stage0/btincl2.o"  "stage0/btscan2.o"
| > "stage0/typrops.o"  "stage0/btpile2.o"  "stage0/typars.o"
| > "stage0/tytree1.o"))) \
| >                          (system::save-system "bootsys"))'
| >
| > Error: The variable |
| > | is unbound.
| > Fast links are on: do (si::use-fast-links nil) for debugging
| > Error signalled by PROGN.
| > Broken at MAPCAR.  Type :H for Help.
| >>>
| >
| > What should I do next?
| >
|
| Here is a patch that I use to solve this problem. It seems that at least
| on some platforms, i.e. combinations of shell and/or make, gcl cannot
| process the '-batch -eval' arguments in the the way one would expect.

Yes.  More curious is that Jacob Smith ran into similar problem on a
Debina based system only for some of the "-batch -eval" things.

:-(

Bill, please could you check in your patch?

\start
Date: Wed, 14 Feb 2007 10:16:51 -0600 (CST)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: gcl and noweb in the build-improvements source tree

On Wed, 14 Feb 2007, Bill Page wrote:

| Gaby, et al.
|
| Every time I download build-improvments on a new machine, I've been
| thinking about the decision to include gcl and noweb source in the
| Axiom source tree (in source format) in the SVN repository at
| SourceForge. It seems to me that rather than having gcl inside the
| tree
|
|   /trunk
|      ....
|      /branches/wh-sandbox
|     ...
|      /branches/build-improvements
|       /branches/build-improvements/gcl
|       /branches/build-improvements/noweb
|       ...
|
| what we should have done is create a new root directory
|
|   /trunk
|      ....
|      /branches/wh-sandbox
|     ...
|      /branches/build-improvements
|     ...
|
|   /extras
|     /gcl
|     /noweb
|     ...
|
| That way, it would be possible to avoid having to pull all the
| source for gcl and noweb if these are already pre-installed.

That is a good alternative.
I would rename /extras to /tools though :-)


The implication though is that when we make a release, we must make
sure gcl and noweb are included.  That slightly complicates the logic
of the Makefiles, but it is doable.  Also we must watch out that
people don't forget building and testing --without-gcl and
--without-noweb (which will be the common cases).

\start
Date: Wed, 14 Feb 2007 10:47:16 -0600 (CST)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: gcl and noweb in the build-improvements source tree

On Wed, 14 Feb 2007, Bill Page wrote:

| Gaby, et al.
|
| Every time I download build-improvments on a new machine, I've been
| thinking about the decision to include gcl and noweb source in the
| Axiom source tree (in source format) in the SVN repository at
| SourceForge. It seems to me that rather than having gcl inside the
| tree
|
|   /trunk
|      ....
|      /branches/wh-sandbox
|     ...
|      /branches/build-improvements
|       /branches/build-improvements/gcl
|       /branches/build-improvements/noweb
|       ...

I should probably add that with SVN, it is possible to branch "only"
directories people are interested, not the whole stuff.

\start
Date: Wed, 14 Feb 2007 12:51:57 -0800 (PST)
From: Brent Fulgham
To: Gabriel Dos Reis, Bill Page
Subject: re: gcl and noweb in the build-improvements source tree

> The implication though is that when we make a release, we must make
> sure gcl and noweb are included.  That slightly complicates the logic
> of the Makefiles, but it is doable.  Also we must watch out that
> people don't forget building and testing --without-gcl and
> --without-noweb (which will be the common cases).

I don't understand why GCL and Noweb are included in the first place.
You don't include AWK/SED, GCC, or a variety of other tools necessary
for building the software.

I suppose for GCL is was necessary, since Axiom might depend on
specifics of the Lisp language supported.

But it seems like making 'noweb' a build requirement might be an
easier approach.  And as Axiom migrates to a more ANSI code base you
could remove GCL as well.

\start
Date: Wed, 14 Feb 2007 15:27:37 -0600 (CST)
From: Gabriel Dos Reis
To: Brent Fulgham
Subject: re: gcl and noweb in the build-improvements source tree

On Wed, 14 Feb 2007, Brent Fulgham wrote:

| > The implication though is that when we make a release, we must make
| > sure gcl and noweb are included.  That slightly complicates the logic
| > of the Makefiles, but it is doable.  Also we must watch out that
| > people don't forget building and testing --without-gcl and
| > --without-noweb (which will be the common cases).
|
| I don't understand why GCL and Noweb are included in the first place.

since this is a recuring discussion, we should probably have an FAQ
entry for it.  The archive has some record of the discussion.

| You don't include AWK/SED, GCC, or a variety of other tools
| necessary for building the software.

indeed.  Because they are standard tools.

Which distros include noweb and GCL as standard tools?

| I suppose for GCL is was necessary, since Axiom might depend on specifics of the Lisp language supported.

You suppose right.

| But it seems like making 'noweb' a build requirement might be an easier approach.  And as Axiom migrates to a more ANSI code base you could remove GCL as well.

I don't think the inclusionof GCL was supposed to be forever.  It will
be however necessary, as long as it isn't standard tool.

\start
Date: Thu, 15 Feb 2007 22:55:42 +0100
From: Gregory Vanuxem
To: list
Subject: Lisp format in sf.spad.pamphlet

Hello,

I have introduced two bugs in DFLOAT when I sent a patch against
sf.spad.pamphlet (outputting routine). Try, for example,
complex(1.7,-2.3@SF) or 3.0*x^3+-2.7@SF*x^2. Furthermore, the directive
used ("~G") is not "the" good one (it's not portable, the directive
works this way only on GCL). Patch in attachment (I have used the Float
method (via 'message')).

A suggestion, what about using )spool to produce *.output file?
(to simplify the comparison via diff of two versions of Axiom (different
banners)).

Greg

PS : Tested on Gold and Build-improvements (should work on Wh-sandbox, I
think). My tests were : building from scratch, tracing outputTran and
testing all outputting formats (algebra, fortran, tex etc...).

--- /home/greg/TDevel/cvs/axiom/src/algebra/sf.spad.pamphlet	2006-04-17 08:=
28:41.000000000 +0200
+++ src/algebra/sf.spad.pamphlet	2007-02-14 12:17:59.000000000 +0100
@@ -846,7 +846,7 @@
          ++ (that is, \spad{|(r-f)/f| < b**(-n)}).

  == add
-   format: String := "~G"
+   format: String := "~A"
    MER ==> Record(MANTISSA:Integer,EXPONENT:Integer)

    manexp: % -> MER
@@ -914,7 +914,8 @@
    exp1()           == FLOAT(534625820200,MOST_-POSITIVE_-LONG_-FLOAT$=
Lisp)$Lisp / FLOAT(196677847971,MOST_-POSITIVE_-LONG_-FLOAT$Lisp)$Lisp
    pi()             == PI$Lisp
    coerce(x:%):OutputForm ==
-     outputForm(FORMAT(NIL$Lisp,format,x)$Lisp pretend DoubleFloat)
+     x >= 0 => message(FORMAT(NIL$Lisp,format,x)$Lisp pretend String)
+     - (message(FORMAT(NIL$Lisp,format,-x)$Lisp pretend String))
    convert(x:%):InputForm == convert(x pretend DoubleFloat)$InputForm
    x < y            == (x<y)$Lisp
    - x              == (-x)$Lisp
@@ -1085,273 +1086,277 @@

 <<DFLOAT.lsp BOOTSTRAP>>=

-(|/VERSIONCHECK| 2)

-(DEFUN |DFLOAT;OMwrite;$S;1| (|x| |$|) (PROG (|sp| |dev| |s|) (RETURN (SEQ=
 (LETT |s| "" |DFLOAT;OMwrite;$S;1|) (LETT |sp| (|OM-STRINGTOSTRINGPTR| |s|=
) |DFLOAT;OMwrite;$S;1|) (LETT |dev| (SPADCALL |sp| (SPADCALL (QREFELT |$| =
7)) (QREFELT |$| 10)) |DFLOAT;OMwrite;$S;1|) (SPADCALL |dev| (QREFELT |$| 1=
2)) (SPADCALL |dev| |x| (QREFELT |$| 14)) (SPADCALL |dev| (QREFELT |$| 15))=
 (SPADCALL |dev| (QREFELT |$| 16)) (LETT |s| (|OM-STRINGPTRTOSTRING| |sp|) =
|DFLOAT;OMwrite;$S;1|) (EXIT |s|)))))
+(/VERSIONCHECK 2)

-(DEFUN |DFLOAT;OMwrite;$BS;2| (|x| |wholeObj| |$|) (PROG (|sp| |dev| |s|) =
(RETURN (SEQ (LETT |s| "" |DFLOAT;OMwrite;$BS;2|) (LETT |sp| (|OM-STRINGTOS=
TRINGPTR| |s|) |DFLOAT;OMwrite;$BS;2|) (LETT |dev| (SPADCALL |sp| (SPADCALL=
 (QREFELT |$| 7)) (QREFELT |$| 10)) |DFLOAT;OMwrite;$BS;2|) (COND (|wholeOb=
j| (SPADCALL |dev| (QREFELT |$| 12)))) (SPADCALL |dev| |x| (QREFELT |$| 14)=
) (COND (|wholeObj| (SPADCALL |dev| (QREFELT |$| 15)))) (SPADCALL |dev| (QR=
EFELT |$| 16)) (LETT |s| (|OM-STRINGPTRTOSTRING| |sp|) |DFLOAT;OMwrite;$BS;=
2|) (EXIT |s|)))))
+(DEFUN |DFLOAT;doubleFloatFormat;2S;1| (|s| $) (PROG (|ss|) (RETURN (SEQ (=
LETT |ss| (QREFELT $ 6) |DFLOAT;doubleFloatFormat;2S;1|) (SETELT $ 6 |s|) (=
EXIT |ss|)))))

-(DEFUN |DFLOAT;OMwrite;Omd$V;3| (|dev| |x| |$|) (SEQ (SPADCALL |dev| (QREF=
ELT |$| 12)) (SPADCALL |dev| |x| (QREFELT |$| 14)) (EXIT (SPADCALL |dev| (Q=
REFELT |$| 15)))))
+(DEFUN |DFLOAT;OMwrite;$S;2| (|x| $) (PROG (|sp| |dev| |s|) (RETURN (SEQ (=
LETT |s| "" |DFLOAT;OMwrite;$S;2|) (LETT |sp| (OM-STRINGTOSTRINGPTR |s|) |D=
FLOAT;OMwrite;$S;2|) (LETT |dev| (SPADCALL |sp| (SPADCALL (QREFELT $ 10)) (=
QREFELT $ 12)) |DFLOAT;OMwrite;$S;2|) (SPADCALL |dev| (QREFELT $ 14)) (SPAD=
CALL |dev| |x| (QREFELT $ 16)) (SPADCALL |dev| (QREFELT $ 17)) (SPADCALL |d=
ev| (QREFELT $ 18)) (LETT |s| (OM-STRINGPTRTOSTRING |sp|) |DFLOAT;OMwrite;$=
S;2|) (EXIT |s|)))))

-(DEFUN |DFLOAT;OMwrite;Omd$BV;4| (|dev| |x| |wholeObj| |$|) (SEQ (COND (|w=
holeObj| (SPADCALL |dev| (QREFELT |$| 12)))) (SPADCALL |dev| |x| (QREFELT |=
$| 14)) (EXIT (COND (|wholeObj| (SPADCALL |dev| (QREFELT |$| 15)))))))
+(DEFUN |DFLOAT;OMwrite;$BS;3| (|x| |wholeObj| $) (PROG (|sp| |dev| |s|) (R=
ETURN (SEQ (LETT |s| "" |DFLOAT;OMwrite;$BS;3|) (LETT |sp| (OM-STRINGTOSTRI=
NGPTR |s|) |DFLOAT;OMwrite;$BS;3|) (LETT |dev| (SPADCALL |sp| (SPADCALL (QR=
EFELT $ 10)) (QREFELT $ 12)) |DFLOAT;OMwrite;$BS;3|) (COND (|wholeObj| (SPA=
DCALL |dev| (QREFELT $ 14)))) (SPADCALL |dev| |x| (QREFELT $ 16)) (COND (|w=
holeObj| (SPADCALL |dev| (QREFELT $ 17)))) (SPADCALL |dev| (QREFELT $ 18)) =
(LETT |s| (OM-STRINGPTRTOSTRING |sp|) |DFLOAT;OMwrite;$BS;3|) (EXIT |s|))))=
)

-(PUT (QUOTE |DFLOAT;checkComplex|) (QUOTE |SPADreplace|) (QUOTE |C-TO-R|))=

+(DEFUN |DFLOAT;OMwrite;Omd$V;4| (|dev| |x| $) (SEQ (SPADCALL |dev| (QREFEL=
T $ 14)) (SPADCALL |dev| |x| (QREFELT $ 16)) (EXIT (SPADCALL |dev| (QREFELT=
 $ 17)))))

-(DEFUN |DFLOAT;checkComplex| (|x| |$|) (|C-TO-R| |x|))
+(DEFUN |DFLOAT;OMwrite;Omd$BV;5| (|dev| |x| |wholeObj| $) (SEQ (COND (|who=
leObj| (SPADCALL |dev| (QREFELT $ 14)))) (SPADCALL |dev| |x| (QREFELT $ 16)=
) (EXIT (COND (|wholeObj| (SPADCALL |dev| (QREFELT $ 17)))))))

-(PUT (QUOTE |DFLOAT;base;Pi;6|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (|F=
LOAT-RADIX| 0.0))))
+(PUT (QUOTE |DFLOAT;checkComplex|) (QUOTE |SPADreplace|) (QUOTE C-TO-R))

-(DEFUN |DFLOAT;base;Pi;6| (|$|) (|FLOAT-RADIX| 0.0))
+(DEFUN |DFLOAT;checkComplex| (|x| $) (C-TO-R |x|))

-(DEFUN |DFLOAT;mantissa;$I;7| (|x| |$|) (QCAR (|DFLOAT;manexp| |x| |$|)))
+(PUT (QUOTE |DFLOAT;base;Pi;7|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (FL=
OAT-RADIX 0.0))))

-(DEFUN |DFLOAT;exponent;$I;8| (|x| |$|) (QCDR (|DFLOAT;manexp| |x| |$|)))
+(DEFUN |DFLOAT;base;Pi;7| ($) (FLOAT-RADIX 0.0))

-(PUT (QUOTE |DFLOAT;precision;Pi;9|) (QUOTE |SPADreplace|) (QUOTE (XLAM NI=
L (|FLOAT-DIGITS| 0.0))))
+(DEFUN |DFLOAT;mantissa;$I;8| (|x| $) (QCAR (|DFLOAT;manexp| |x| $)))

-(DEFUN |DFLOAT;precision;Pi;9| (|$|) (|FLOAT-DIGITS| 0.0))
+(DEFUN |DFLOAT;exponent;$I;9| (|x| $) (QCDR (|DFLOAT;manexp| |x| $)))

-(DEFUN |DFLOAT;bits;Pi;10| (|$|) (PROG (#1=#:G105705) (RETURN (COND ((EQ=
L (|FLOAT-RADIX| 0.0) 2) (|FLOAT-DIGITS| 0.0)) ((EQL (|FLOAT-RADIX| 0.0) 16=
) (|*| 4 (|FLOAT-DIGITS| 0.0))) ((QUOTE T) (PROG1 (LETT #1# (FIX (SPADCALL =
(|FLOAT-DIGITS| 0.0) (SPADCALL (FLOAT (|FLOAT-RADIX| 0.0) |MOST-POSITIVE-LO=
NG-FLOAT|) (QREFELT |$| 28)) (QREFELT |$| 29))) |DFLOAT;bits;Pi;10|) (|chec=
k-subtype| (|>| #1# 0) (QUOTE (|PositiveInteger|)) #1#)))))))
+(PUT (QUOTE |DFLOAT;precision;Pi;10|) (QUOTE |SPADreplace|) (QUOTE (XLAM N=
IL (FLOAT-DIGITS 0.0))))

-(PUT (QUOTE |DFLOAT;max;$;11|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL |MOS=
T-POSITIVE-LONG-FLOAT|)))
+(DEFUN |DFLOAT;precision;Pi;10| ($) (FLOAT-DIGITS 0.0))

-(DEFUN |DFLOAT;max;$;11| (|$|) |MOST-POSITIVE-LONG-FLOAT|)
+(DEFUN |DFLOAT;bits;Pi;11| ($) (PROG (#0=#:G1444) (RETURN (COND ((EQL (F=
LOAT-RADIX 0.0) 2) (FLOAT-DIGITS 0.0)) ((EQL (FLOAT-RADIX 0.0) 16) (* 4 (FL=
OAT-DIGITS 0.0))) ((QUOTE T) (PROG1 (LETT #0# (FIX (SPADCALL (FLOAT-DIGITS =
0.0) (SPADCALL (FLOAT (FLOAT-RADIX 0.0) MOST-POSITIVE-LONG-FLOAT) (QREFELT =
$ 30)) (QREFELT $ 31))) |DFLOAT;bits;Pi;11|) (|check-subtype| (> #0# 0) (QU=
OTE (|PositiveInteger|)) #0#)))))))

-(PUT (QUOTE |DFLOAT;min;$;12|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL |MOS=
T-NEGATIVE-LONG-FLOAT|)))
+(PUT (QUOTE |DFLOAT;max;$;12|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL MOST=
-POSITIVE-LONG-FLOAT)))

-(DEFUN |DFLOAT;min;$;12| (|$|) |MOST-NEGATIVE-LONG-FLOAT|)
+(DEFUN |DFLOAT;max;$;12| ($) MOST-POSITIVE-LONG-FLOAT)

-(DEFUN |DFLOAT;order;$I;13| (|a| |$|) (|-| (|+| (|FLOAT-DIGITS| 0.0) (SPAD=
CALL |a| (QREFELT |$| 26))) 1))
+(PUT (QUOTE |DFLOAT;min;$;13|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL MOST=
-NEGATIVE-LONG-FLOAT)))

-(PUT (QUOTE |DFLOAT;Zero;$;14|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (FL=
OAT 0 |MOST-POSITIVE-LONG-FLOAT|))))
+(DEFUN |DFLOAT;min;$;13| ($) MOST-NEGATIVE-LONG-FLOAT)

-(DEFUN |DFLOAT;Zero;$;14| (|$|) (FLOAT 0 |MOST-POSITIVE-LONG-FLOAT|))
+(DEFUN |DFLOAT;order;$I;14| (|a| $) (- (+ (FLOAT-DIGITS 0.0) (SPADCALL |a|=
 (QREFELT $ 28))) 1))

-(PUT (QUOTE |DFLOAT;One;$;15|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (FLO=
AT 1 |MOST-POSITIVE-LONG-FLOAT|))))
+(PUT (QUOTE |DFLOAT;Zero;$;15|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (FL=
OAT 0 MOST-POSITIVE-LONG-FLOAT))))

-(DEFUN |DFLOAT;One;$;15| (|$|) (FLOAT 1 |MOST-POSITIVE-LONG-FLOAT|))
+(DEFUN |DFLOAT;Zero;$;15| ($) (FLOAT 0 MOST-POSITIVE-LONG-FLOAT))

-(DEFUN |DFLOAT;exp1;$;16| (|$|) (|/| (FLOAT 534625820200 |MOST-POSITIVE-LO=
NG-FLOAT|) (FLOAT 196677847971 |MOST-POSITIVE-LONG-FLOAT|)))
+(PUT (QUOTE |DFLOAT;One;$;16|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (FLO=
AT 1 MOST-POSITIVE-LONG-FLOAT))))

-(PUT (QUOTE |DFLOAT;pi;$;17|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL PI)))=

+(DEFUN |DFLOAT;One;$;16| ($) (FLOAT 1 MOST-POSITIVE-LONG-FLOAT))

-(DEFUN |DFLOAT;pi;$;17| (|$|) PI)
+(DEFUN |DFLOAT;exp1;$;17| ($) (/ (FLOAT 534625820200 MOST-POSITIVE-LONG-FL=
OAT) (FLOAT 196677847971 MOST-POSITIVE-LONG-FLOAT)))

-(DEFUN |DFLOAT;coerce;$Of;18| (|x| |$|) (SPADCALL |x| (QREFELT |$| 39)))
+(PUT (QUOTE |DFLOAT;pi;$;18|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL PI)))=


-(DEFUN |DFLOAT;convert;$If;19| (|x| |$|) (SPADCALL |x| (QREFELT |$| 42)))
+(DEFUN |DFLOAT;pi;$;18| ($) PI)

-(PUT (QUOTE |DFLOAT;<;2$B;20|) (QUOTE |SPADreplace|) (QUOTE |<|))
+(DEFUN |DFLOAT;coerce;$Of;19| (|x| $) (COND ((< |x| 0.0) (SPADCALL (SPADCA=
LL (FORMAT NIL (QREFELT $ 6) (- |x|)) (QREFELT $ 41)) (QREFELT $ 42))) ((QU=
OTE T) (SPADCALL (FORMAT NIL (QREFELT $ 6) |x|) (QREFELT $ 41)))))

-(DEFUN |DFLOAT;<;2$B;20| (|x| |y| |$|) (|<| |x| |y|))
+(DEFUN |DFLOAT;convert;$If;20| (|x| $) (SPADCALL |x| (QREFELT $ 45)))

-(PUT (QUOTE |DFLOAT;-;2$;21|) (QUOTE |SPADreplace|) (QUOTE |-|))
+(PUT (QUOTE |DFLOAT;<;2$B;21|) (QUOTE |SPADreplace|) (QUOTE <))

-(DEFUN |DFLOAT;-;2$;21| (|x| |$|) (|-| |x|))
+(DEFUN |DFLOAT;<;2$B;21| (|x| |y| $) (< |x| |y|))

-(PUT (QUOTE |DFLOAT;+;3$;22|) (QUOTE |SPADreplace|) (QUOTE |+|))
+(PUT (QUOTE |DFLOAT;-;2$;22|) (QUOTE |SPADreplace|) (QUOTE -))

-(DEFUN |DFLOAT;+;3$;22| (|x| |y| |$|) (|+| |x| |y|))
+(DEFUN |DFLOAT;-;2$;22| (|x| $) (- |x|))

-(PUT (QUOTE |DFLOAT;-;3$;23|) (QUOTE |SPADreplace|) (QUOTE |-|))
+(PUT (QUOTE |DFLOAT;+;3$;23|) (QUOTE |SPADreplace|) (QUOTE +))

-(DEFUN |DFLOAT;-;3$;23| (|x| |y| |$|) (|-| |x| |y|))
+(DEFUN |DFLOAT;+;3$;23| (|x| |y| $) (+ |x| |y|))

-(PUT (QUOTE |DFLOAT;*;3$;24|) (QUOTE |SPADreplace|) (QUOTE |*|))
+(PUT (QUOTE |DFLOAT;-;3$;24|) (QUOTE |SPADreplace|) (QUOTE -))

-(DEFUN |DFLOAT;*;3$;24| (|x| |y| |$|) (|*| |x| |y|))
+(DEFUN |DFLOAT;-;3$;24| (|x| |y| $) (- |x| |y|))

-(PUT (QUOTE |DFLOAT;*;I2$;25|) (QUOTE |SPADreplace|) (QUOTE |*|))
+(PUT (QUOTE |DFLOAT;*;3$;25|) (QUOTE |SPADreplace|) (QUOTE *))

-(DEFUN |DFLOAT;*;I2$;25| (|i| |x| |$|) (|*| |i| |x|))
+(DEFUN |DFLOAT;*;3$;25| (|x| |y| $) (* |x| |y|))

-(PUT (QUOTE |DFLOAT;max;3$;26|) (QUOTE |SPADreplace|) (QUOTE MAX))
+(PUT (QUOTE |DFLOAT;*;I2$;26|) (QUOTE |SPADreplace|) (QUOTE *))

-(DEFUN |DFLOAT;max;3$;26| (|x| |y| |$|) (MAX |x| |y|))
+(DEFUN |DFLOAT;*;I2$;26| (|i| |x| $) (* |i| |x|))

-(PUT (QUOTE |DFLOAT;min;3$;27|) (QUOTE |SPADreplace|) (QUOTE MIN))
+(PUT (QUOTE |DFLOAT;max;3$;27|) (QUOTE |SPADreplace|) (QUOTE MAX))

-(DEFUN |DFLOAT;min;3$;27| (|x| |y| |$|) (MIN |x| |y|))
+(DEFUN |DFLOAT;max;3$;27| (|x| |y| $) (MAX |x| |y|))

-(PUT (QUOTE |DFLOAT;=;2$B;28|) (QUOTE |SPADreplace|) (QUOTE |=|))
+(PUT (QUOTE |DFLOAT;min;3$;28|) (QUOTE |SPADreplace|) (QUOTE MIN))

-(DEFUN |DFLOAT;=;2$B;28| (|x| |y| |$|) (|=| |x| |y|))
+(DEFUN |DFLOAT;min;3$;28| (|x| |y| $) (MIN |x| |y|))

-(PUT (QUOTE |DFLOAT;/;$I$;29|) (QUOTE |SPADreplace|) (QUOTE |/|))
+(PUT (QUOTE |DFLOAT;=;2$B;29|) (QUOTE |SPADreplace|) (QUOTE =))

-(DEFUN |DFLOAT;/;$I$;29| (|x| |i| |$|) (|/| |x| |i|))
+(DEFUN |DFLOAT;=;2$B;29| (|x| |y| $) (= |x| |y|))

-(DEFUN |DFLOAT;sqrt;2$;30| (|x| |$|) (|DFLOAT;checkComplex| (SQRT |x|) |$|=
))
+(PUT (QUOTE |DFLOAT;/;$I$;30|) (QUOTE |SPADreplace|) (QUOTE /))

-(DEFUN |DFLOAT;log10;2$;31| (|x| |$|) (|DFLOAT;checkComplex| (|log| |x|) |=
$|))
+(DEFUN |DFLOAT;/;$I$;30| (|x| |i| $) (/ |x| |i|))

-(PUT (QUOTE |DFLOAT;**;$I$;32|) (QUOTE |SPADreplace|) (QUOTE EXPT))
+(DEFUN |DFLOAT;sqrt;2$;31| (|x| $) (|DFLOAT;checkComplex| (SQRT |x|) $))

-(DEFUN |DFLOAT;**;$I$;32| (|x| |i| |$|) (EXPT |x| |i|))
+(DEFUN |DFLOAT;log10;2$;32| (|x| $) (|DFLOAT;checkComplex| (|log| |x|) $))=


-(DEFUN |DFLOAT;**;3$;33| (|x| |y| |$|) (|DFLOAT;checkComplex| (EXPT |x| |y=
|) |$|))
+(PUT (QUOTE |DFLOAT;**;$I$;33|) (QUOTE |SPADreplace|) (QUOTE EXPT))

-(PUT (QUOTE |DFLOAT;coerce;I$;34|) (QUOTE |SPADreplace|) (QUOTE (XLAM (|i|=
) (FLOAT |i| |MOST-POSITIVE-LONG-FLOAT|))))
+(DEFUN |DFLOAT;**;$I$;33| (|x| |i| $) (EXPT |x| |i|))

-(DEFUN |DFLOAT;coerce;I$;34| (|i| |$|) (FLOAT |i| |MOST-POSITIVE-LONG-FLOA=
T|))
+(DEFUN |DFLOAT;**;3$;34| (|x| |y| $) (|DFLOAT;checkComplex| (EXPT |x| |y|)=
 $))

-(PUT (QUOTE |DFLOAT;exp;2$;35|) (QUOTE |SPADreplace|) (QUOTE EXP))
+(PUT (QUOTE |DFLOAT;coerce;I$;35|) (QUOTE |SPADreplace|) (QUOTE (XLAM (|i|=
) (FLOAT |i| MOST-POSITIVE-LONG-FLOAT))))

-(DEFUN |DFLOAT;exp;2$;35| (|x| |$|) (EXP |x|))
+(DEFUN |DFLOAT;coerce;I$;35| (|i| $) (FLOAT |i| MOST-POSITIVE-LONG-FLOAT))=


-(DEFUN |DFLOAT;log;2$;36| (|x| |$|) (|DFLOAT;checkComplex| (LN |x|) |$|))
+(PUT (QUOTE |DFLOAT;exp;2$;36|) (QUOTE |SPADreplace|) (QUOTE EXP))

-(DEFUN |DFLOAT;log2;2$;37| (|x| |$|) (|DFLOAT;checkComplex| (LOG2 |x|) |$|=
))
+(DEFUN |DFLOAT;exp;2$;36| (|x| $) (EXP |x|))

-(PUT (QUOTE |DFLOAT;sin;2$;38|) (QUOTE |SPADreplace|) (QUOTE SIN))
+(DEFUN |DFLOAT;log;2$;37| (|x| $) (|DFLOAT;checkComplex| (LN |x|) $))

-(DEFUN |DFLOAT;sin;2$;38| (|x| |$|) (SIN |x|))
+(DEFUN |DFLOAT;log2;2$;38| (|x| $) (|DFLOAT;checkComplex| (LOG2 |x|) $))

-(PUT (QUOTE |DFLOAT;cos;2$;39|) (QUOTE |SPADreplace|) (QUOTE COS))
+(PUT (QUOTE |DFLOAT;sin;2$;39|) (QUOTE |SPADreplace|) (QUOTE SIN))

-(DEFUN |DFLOAT;cos;2$;39| (|x| |$|) (COS |x|))
+(DEFUN |DFLOAT;sin;2$;39| (|x| $) (SIN |x|))

-(PUT (QUOTE |DFLOAT;tan;2$;40|) (QUOTE |SPADreplace|) (QUOTE TAN))
+(PUT (QUOTE |DFLOAT;cos;2$;40|) (QUOTE |SPADreplace|) (QUOTE COS))

-(DEFUN |DFLOAT;tan;2$;40| (|x| |$|) (TAN |x|))
+(DEFUN |DFLOAT;cos;2$;40| (|x| $) (COS |x|))

-(PUT (QUOTE |DFLOAT;cot;2$;41|) (QUOTE |SPADreplace|) (QUOTE COT))
+(PUT (QUOTE |DFLOAT;tan;2$;41|) (QUOTE |SPADreplace|) (QUOTE TAN))

-(DEFUN |DFLOAT;cot;2$;41| (|x| |$|) (COT |x|))
+(DEFUN |DFLOAT;tan;2$;41| (|x| $) (TAN |x|))

-(PUT (QUOTE |DFLOAT;sec;2$;42|) (QUOTE |SPADreplace|) (QUOTE SEC))
+(PUT (QUOTE |DFLOAT;cot;2$;42|) (QUOTE |SPADreplace|) (QUOTE COT))

-(DEFUN |DFLOAT;sec;2$;42| (|x| |$|) (SEC |x|))
+(DEFUN |DFLOAT;cot;2$;42| (|x| $) (COT |x|))

-(PUT (QUOTE |DFLOAT;csc;2$;43|) (QUOTE |SPADreplace|) (QUOTE CSC))
+(PUT (QUOTE |DFLOAT;sec;2$;43|) (QUOTE |SPADreplace|) (QUOTE SEC))

-(DEFUN |DFLOAT;csc;2$;43| (|x| |$|) (CSC |x|))
+(DEFUN |DFLOAT;sec;2$;43| (|x| $) (SEC |x|))

-(DEFUN |DFLOAT;asin;2$;44| (|x| |$|) (|DFLOAT;checkComplex| (ASIN |x|) |$|=
))
+(PUT (QUOTE |DFLOAT;csc;2$;44|) (QUOTE |SPADreplace|) (QUOTE CSC))

-(DEFUN |DFLOAT;acos;2$;45| (|x| |$|) (|DFLOAT;checkComplex| (ACOS |x|) |$|=
))
+(DEFUN |DFLOAT;csc;2$;44| (|x| $) (CSC |x|))

-(PUT (QUOTE |DFLOAT;atan;2$;46|) (QUOTE |SPADreplace|) (QUOTE ATAN))
+(DEFUN |DFLOAT;asin;2$;45| (|x| $) (|DFLOAT;checkComplex| (ASIN |x|) $))

-(DEFUN |DFLOAT;atan;2$;46| (|x| |$|) (ATAN |x|))
+(DEFUN |DFLOAT;acos;2$;46| (|x| $) (|DFLOAT;checkComplex| (ACOS |x|) $))

-(DEFUN |DFLOAT;acsc;2$;47| (|x| |$|) (|DFLOAT;checkComplex| (ACSC |x|) |$|=
))
+(PUT (QUOTE |DFLOAT;atan;2$;47|) (QUOTE |SPADreplace|) (QUOTE ATAN))

-(PUT (QUOTE |DFLOAT;acot;2$;48|) (QUOTE |SPADreplace|) (QUOTE ACOT))
+(DEFUN |DFLOAT;atan;2$;47| (|x| $) (ATAN |x|))

-(DEFUN |DFLOAT;acot;2$;48| (|x| |$|) (ACOT |x|))
+(DEFUN |DFLOAT;acsc;2$;48| (|x| $) (|DFLOAT;checkComplex| (ACSC |x|) $))

-(DEFUN |DFLOAT;asec;2$;49| (|x| |$|) (|DFLOAT;checkComplex| (ASEC |x|) |$|=
))
+(PUT (QUOTE |DFLOAT;acot;2$;49|) (QUOTE |SPADreplace|) (QUOTE ACOT))

-(PUT (QUOTE |DFLOAT;sinh;2$;50|) (QUOTE |SPADreplace|) (QUOTE SINH))
+(DEFUN |DFLOAT;acot;2$;49| (|x| $) (ACOT |x|))

-(DEFUN |DFLOAT;sinh;2$;50| (|x| |$|) (SINH |x|))
+(DEFUN |DFLOAT;asec;2$;50| (|x| $) (|DFLOAT;checkComplex| (ASEC |x|) $))

-(PUT (QUOTE |DFLOAT;cosh;2$;51|) (QUOTE |SPADreplace|) (QUOTE COSH))
+(PUT (QUOTE |DFLOAT;sinh;2$;51|) (QUOTE |SPADreplace|) (QUOTE SINH))

-(DEFUN |DFLOAT;cosh;2$;51| (|x| |$|) (COSH |x|))
+(DEFUN |DFLOAT;sinh;2$;51| (|x| $) (SINH |x|))

-(PUT (QUOTE |DFLOAT;tanh;2$;52|) (QUOTE |SPADreplace|) (QUOTE TANH))
+(PUT (QUOTE |DFLOAT;cosh;2$;52|) (QUOTE |SPADreplace|) (QUOTE COSH))

-(DEFUN |DFLOAT;tanh;2$;52| (|x| |$|) (TANH |x|))
+(DEFUN |DFLOAT;cosh;2$;52| (|x| $) (COSH |x|))

-(PUT (QUOTE |DFLOAT;csch;2$;53|) (QUOTE |SPADreplace|) (QUOTE CSCH))
+(PUT (QUOTE |DFLOAT;tanh;2$;53|) (QUOTE |SPADreplace|) (QUOTE TANH))

-(DEFUN |DFLOAT;csch;2$;53| (|x| |$|) (CSCH |x|))
+(DEFUN |DFLOAT;tanh;2$;53| (|x| $) (TANH |x|))

-(PUT (QUOTE |DFLOAT;coth;2$;54|) (QUOTE |SPADreplace|) (QUOTE COTH))
+(PUT (QUOTE |DFLOAT;csch;2$;54|) (QUOTE |SPADreplace|) (QUOTE CSCH))

-(DEFUN |DFLOAT;coth;2$;54| (|x| |$|) (COTH |x|))
+(DEFUN |DFLOAT;csch;2$;54| (|x| $) (CSCH |x|))

-(PUT (QUOTE |DFLOAT;sech;2$;55|) (QUOTE |SPADreplace|) (QUOTE SECH))
+(PUT (QUOTE |DFLOAT;coth;2$;55|) (QUOTE |SPADreplace|) (QUOTE COTH))

-(DEFUN |DFLOAT;sech;2$;55| (|x| |$|) (SECH |x|))
+(DEFUN |DFLOAT;coth;2$;55| (|x| $) (COTH |x|))

-(PUT (QUOTE |DFLOAT;asinh;2$;56|) (QUOTE |SPADreplace|) (QUOTE ASINH))
+(PUT (QUOTE |DFLOAT;sech;2$;56|) (QUOTE |SPADreplace|) (QUOTE SECH))

-(DEFUN |DFLOAT;asinh;2$;56| (|x| |$|) (ASINH |x|))
+(DEFUN |DFLOAT;sech;2$;56| (|x| $) (SECH |x|))

-(DEFUN |DFLOAT;acosh;2$;57| (|x| |$|) (|DFLOAT;checkComplex| (ACOSH |x|) |=
$|))
+(PUT (QUOTE |DFLOAT;asinh;2$;57|) (QUOTE |SPADreplace|) (QUOTE ASINH))

-(DEFUN |DFLOAT;atanh;2$;58| (|x| |$|) (|DFLOAT;checkComplex| (ATANH |x|) |=
$|))
+(DEFUN |DFLOAT;asinh;2$;57| (|x| $) (ASINH |x|))

-(PUT (QUOTE |DFLOAT;acsch;2$;59|) (QUOTE |SPADreplace|) (QUOTE ACSCH))
+(DEFUN |DFLOAT;acosh;2$;58| (|x| $) (|DFLOAT;checkComplex| (ACOSH |x|) $))=


-(DEFUN |DFLOAT;acsch;2$;59| (|x| |$|) (ACSCH |x|))
+(DEFUN |DFLOAT;atanh;2$;59| (|x| $) (|DFLOAT;checkComplex| (ATANH |x|) $))=


-(DEFUN |DFLOAT;acoth;2$;60| (|x| |$|) (|DFLOAT;checkComplex| (ACOTH |x|) |=
$|))
+(PUT (QUOTE |DFLOAT;acsch;2$;60|) (QUOTE |SPADreplace|) (QUOTE ACSCH))

-(DEFUN |DFLOAT;asech;2$;61| (|x| |$|) (|DFLOAT;checkComplex| (ASECH |x|) |=
$|))
+(DEFUN |DFLOAT;acsch;2$;60| (|x| $) (ACSCH |x|))

-(PUT (QUOTE |DFLOAT;/;3$;62|) (QUOTE |SPADreplace|) (QUOTE |/|))
+(DEFUN |DFLOAT;acoth;2$;61| (|x| $) (|DFLOAT;checkComplex| (ACOTH |x|) $))=


-(DEFUN |DFLOAT;/;3$;62| (|x| |y| |$|) (|/| |x| |y|))
+(DEFUN |DFLOAT;asech;2$;62| (|x| $) (|DFLOAT;checkComplex| (ASECH |x|) $))=


-(PUT (QUOTE |DFLOAT;negative?;$B;63|) (QUOTE |SPADreplace|) (QUOTE MINUSP)=
)
+(PUT (QUOTE |DFLOAT;/;3$;63|) (QUOTE |SPADreplace|) (QUOTE /))

-(DEFUN |DFLOAT;negative?;$B;63| (|x| |$|) (MINUSP |x|))
+(DEFUN |DFLOAT;/;3$;63| (|x| |y| $) (/ |x| |y|))

-(PUT (QUOTE |DFLOAT;zero?;$B;64|) (QUOTE |SPADreplace|) (QUOTE ZEROP))
+(PUT (QUOTE |DFLOAT;negative?;$B;64|) (QUOTE |SPADreplace|) (QUOTE MINUSP)=
)

-(DEFUN |DFLOAT;zero?;$B;64| (|x| |$|) (ZEROP |x|))
+(DEFUN |DFLOAT;negative?;$B;64| (|x| $) (MINUSP |x|))

-(PUT (QUOTE |DFLOAT;hash;$I;65|) (QUOTE |SPADreplace|) (QUOTE HASHEQ))
+(PUT (QUOTE |DFLOAT;zero?;$B;65|) (QUOTE |SPADreplace|) (QUOTE ZEROP))

-(DEFUN |DFLOAT;hash;$I;65| (|x| |$|) (HASHEQ |x|))
+(DEFUN |DFLOAT;zero?;$B;65| (|x| $) (ZEROP |x|))

-(DEFUN |DFLOAT;recip;$U;66| (|x| |$|) (COND ((ZEROP |x|) (CONS 1 "failed")=
) ((QUOTE T) (CONS 0 (|/| 1.0 |x|)))))
+(PUT (QUOTE |DFLOAT;hash;$I;66|) (QUOTE |SPADreplace|) (QUOTE HASHEQ))

-(PUT (QUOTE |DFLOAT;differentiate;2$;67|) (QUOTE |SPADreplace|) (QUOTE (XL=
AM (|x|) 0.0)))
+(DEFUN |DFLOAT;hash;$I;66| (|x| $) (HASHEQ |x|))

-(DEFUN |DFLOAT;differentiate;2$;67| (|x| |$|) 0.0)
+(DEFUN |DFLOAT;recip;$U;67| (|x| $) (COND ((ZEROP |x|) (CONS 1 "failed")) =
((QUOTE T) (CONS 0 (/ 1.0 |x|)))))

-(DEFUN |DFLOAT;Gamma;2$;68| (|x| |$|) (SPADCALL |x| (QREFELT |$| 93)))
+(PUT (QUOTE |DFLOAT;differentiate;2$;68|) (QUOTE |SPADreplace|) (QUOTE (XL=
AM (|x|) 0.0)))

-(DEFUN |DFLOAT;Beta;3$;69| (|x| |y| |$|) (SPADCALL |x| |y| (QREFELT |$| 95=
)))
+(DEFUN |DFLOAT;differentiate;2$;68| (|x| $) 0.0)

-(PUT (QUOTE |DFLOAT;wholePart;$I;70|) (QUOTE |SPADreplace|) (QUOTE FIX))
+(DEFUN |DFLOAT;Gamma;2$;69| (|x| $) (SPADCALL |x| (QREFELT $ 96)))

-(DEFUN |DFLOAT;wholePart;$I;70| (|x| |$|) (FIX |x|))
+(DEFUN |DFLOAT;Beta;3$;70| (|x| |y| $) (SPADCALL |x| |y| (QREFELT $ 98)))

-(DEFUN |DFLOAT;float;2IPi$;71| (|ma| |ex| |b| |$|) (|*| |ma| (EXPT (FLOAT =
|b| |MOST-POSITIVE-LONG-FLOAT|) |ex|)))
+(PUT (QUOTE |DFLOAT;wholePart;$I;71|) (QUOTE |SPADreplace|) (QUOTE FIX))

-(PUT (QUOTE |DFLOAT;convert;2$;72|) (QUOTE |SPADreplace|) (QUOTE (XLAM (|x=
|) |x|)))
+(DEFUN |DFLOAT;wholePart;$I;71| (|x| $) (FIX |x|))

-(DEFUN |DFLOAT;convert;2$;72| (|x| |$|) |x|)
+(DEFUN |DFLOAT;float;2IPi$;72| (|ma| |ex| |b| $) (* |ma| (EXPT (FLOAT |b| =
MOST-POSITIVE-LONG-FLOAT) |ex|)))

-(DEFUN |DFLOAT;convert;$F;73| (|x| |$|) (SPADCALL |x| (QREFELT |$| 101)))
+(PUT (QUOTE |DFLOAT;convert;2$;73|) (QUOTE |SPADreplace|) (QUOTE (XLAM (|x=
|) |x|)))

-(DEFUN |DFLOAT;rationalApproximation;$NniF;74| (|x| |d| |$|) (SPADCALL |x|=
 |d| 10 (QREFELT |$| 105)))
+(DEFUN |DFLOAT;convert;2$;73| (|x| $) |x|)

-(DEFUN |DFLOAT;atan;3$;75| (|x| |y| |$|) (PROG (|theta|) (RETURN (SEQ (CON=
D ((|=| |x| 0.0) (COND ((|<| 0.0 |y|) (|/| PI 2)) ((|<| |y| 0.0) (|-| (|/=
| PI 2))) ((QUOTE T) 0.0))) ((QUOTE T) (SEQ (LETT |theta| (ATAN (|FLOAT-SIG=
N| 1.0 (|/| |y| |x|))) |DFLOAT;atan;3$;75|) (COND ((|<| |x| 0.0) (LETT |the=
ta| (|-| PI |theta|) |DFLOAT;atan;3$;75|))) (COND ((|<| |y| 0.0) (LETT |the=
ta| (|-| |theta|) |DFLOAT;atan;3$;75|))) (EXIT |theta|))))))))
+(DEFUN |DFLOAT;convert;$F;74| (|x| $) (SPADCALL |x| (QREFELT $ 104)))

-(DEFUN |DFLOAT;retract;$F;76| (|x| |$|) (PROG (#1=#:G105780) (RETURN (SP=
ADCALL |x| (PROG1 (LETT #1# (|-| (|FLOAT-DIGITS| 0.0) 1) |DFLOAT;retract;$F=
;76|) (|check-subtype| (|>=| #1# 0) (QUOTE (|NonNegativeInteger|)) #1#)) =
(|FLOAT-RADIX| 0.0) (QREFELT |$| 105)))))
+(DEFUN |DFLOAT;rationalApproximation;$NniF;75| (|x| |d| $) (SPADCALL |x| |=
d| 10 (QREFELT $ 108)))

-(DEFUN |DFLOAT;retractIfCan;$U;77| (|x| |$|) (PROG (#1=#:G105785) (RETUR=
N (CONS 0 (SPADCALL |x| (PROG1 (LETT #1# (|-| (|FLOAT-DIGITS| 0.0) 1) |DFLO=
AT;retractIfCan;$U;77|) (|check-subtype| (|>=| #1# 0) (QUOTE (|NonNegativ=
eInteger|)) #1#)) (|FLOAT-RADIX| 0.0) (QREFELT |$| 105))))))
+(DEFUN |DFLOAT;atan;3$;76| (|x| |y| $) (PROG (|theta|) (RETURN (SEQ (COND =
((= |x| 0.0) (COND ((< 0.0 |y|) (/ PI 2)) ((< |y| 0.0) (- (/ PI 2))) ((QU=
OTE T) 0.0))) ((QUOTE T) (SEQ (LETT |theta| (ATAN (FLOAT-SIGN 1.0 (/ |y| |x=
|))) |DFLOAT;atan;3$;76|) (COND ((< |x| 0.0) (LETT |theta| (- PI |theta|) |=
DFLOAT;atan;3$;76|))) (COND ((< |y| 0.0) (LETT |theta| (- |theta|) |DFLOAT;=
atan;3$;76|))) (EXIT |theta|))))))))

-(DEFUN |DFLOAT;retract;$I;78| (|x| |$|) (PROG (|n|) (RETURN (SEQ (LETT |n|=
 (FIX |x|) |DFLOAT;retract;$I;78|) (EXIT (COND ((|=| |x| (FLOAT |n| |MOST=
-POSITIVE-LONG-FLOAT|)) |n|) ((QUOTE T) (|error| "Not an integer"))))))))
+(DEFUN |DFLOAT;retract;$F;77| (|x| $) (PROG (#0=#:G1519) (RETURN (SPADCA=
LL |x| (PROG1 (LETT #0# (- (FLOAT-DIGITS 0.0) 1) |DFLOAT;retract;$F;77|) (|=
check-subtype| (>= #0# 0) (QUOTE (|NonNegativeInteger|)) #0#)) (FLOAT-RAD=
IX 0.0) (QREFELT $ 108)))))

-(DEFUN |DFLOAT;retractIfCan;$U;79| (|x| |$|) (PROG (|n|) (RETURN (SEQ (LET=
T |n| (FIX |x|) |DFLOAT;retractIfCan;$U;79|) (EXIT (COND ((|=| |x| (FLOAT=
 |n| |MOST-POSITIVE-LONG-FLOAT|)) (CONS 0 |n|)) ((QUOTE T) (CONS 1 "failed"=
))))))))
+(DEFUN |DFLOAT;retractIfCan;$U;78| (|x| $) (PROG (#0=#:G1524) (RETURN (C=
ONS 0 (SPADCALL |x| (PROG1 (LETT #0# (- (FLOAT-DIGITS 0.0) 1) |DFLOAT;retra=
ctIfCan;$U;78|) (|check-subtype| (>= #0# 0) (QUOTE (|NonNegativeInteger|)=
) #0#)) (FLOAT-RADIX 0.0) (QREFELT $ 108))))))

-(DEFUN |DFLOAT;sign;$I;80| (|x| |$|) (SPADCALL (|FLOAT-SIGN| |x| 1.0) (QRE=
FELT |$| 111)))
+(DEFUN |DFLOAT;retract;$I;79| (|x| $) (PROG (|n|) (RETURN (SEQ (LETT |n| (=
FIX |x|) |DFLOAT;retract;$I;79|) (EXIT (COND ((= |x| (FLOAT |n| MOST-POSI=
TIVE-LONG-FLOAT)) |n|) ((QUOTE T) (|error| "Not an integer"))))))))

-(PUT (QUOTE |DFLOAT;abs;2$;81|) (QUOTE |SPADreplace|) (QUOTE (XLAM (|x|) (=
|FLOAT-SIGN| 1.0 |x|))))
+(DEFUN |DFLOAT;retractIfCan;$U;80| (|x| $) (PROG (|n|) (RETURN (SEQ (LETT =
|n| (FIX |x|) |DFLOAT;retractIfCan;$U;80|) (EXIT (COND ((= |x| (FLOAT |n|=
 MOST-POSITIVE-LONG-FLOAT)) (CONS 0 |n|)) ((QUOTE T) (CONS 1 "failed"))))))=
))

-(DEFUN |DFLOAT;abs;2$;81| (|x| |$|) (|FLOAT-SIGN| 1.0 |x|))
+(DEFUN |DFLOAT;sign;$I;81| (|x| $) (SPADCALL (FLOAT-SIGN |x| 1.0) (QREFELT=
 $ 114)))

-(DEFUN |DFLOAT;manexp| (|x| |$|) (PROG (|s| #1=#:G105806 |me| |two53|) (=
RETURN (SEQ (EXIT (COND ((ZEROP |x|) (CONS 0 0)) ((QUOTE T) (SEQ (LETT |s| =
(SPADCALL |x| (QREFELT |$| 114)) |DFLOAT;manexp|) (LETT |x| (|FLOAT-SIGN| 1=
.0 |x|) |DFLOAT;manexp|) (COND ((|<| |MOST-POSITIVE-LONG-FLOAT| |x|) (PROGN=
 (LETT #1# (CONS (|+| (|*| |s| (SPADCALL |MOST-POSITIVE-LONG-FLOAT| (QREFEL=
T |$| 25))) 1) (SPADCALL |MOST-POSITIVE-LONG-FLOAT| (QREFELT |$| 26))) |DFL=
OAT;manexp|) (GO #1#)))) (LETT |me| (MANEXP |x|) |DFLOAT;manexp|) (LETT |tw=
o53| (EXPT (|FLOAT-RADIX| 0.0) (|FLOAT-DIGITS| 0.0)) |DFLOAT;manexp|) (EXIT=
 (CONS (|*| |s| (FIX (|*| |two53| (QCAR |me|)))) (|-| (QCDR |me|) (|FLOAT-D=
IGITS| 0.0)))))))) #1# (EXIT #1#)))))
+(PUT (QUOTE |DFLOAT;abs;2$;82|) (QUOTE |SPADreplace|) (QUOTE (XLAM (|x|) (=
FLOAT-SIGN 1.0 |x|))))

-(DEFUN |DFLOAT;rationalApproximation;$2NniF;83| (|f| |d| |b| |$|) (PROG (|=
#G102| |nu| |ex| BASE #1=#:G105809 |de| |tol| |#G103| |q| |r| |p2| |q2| #=
2=#:G105827 |#G104| |#G105| |p0| |p1| |#G106| |#G107| |q0| |q1| |#G108| |=
#G109| |s| |t| #3=#:G105825) (RETURN (SEQ (EXIT (SEQ (PROGN (LETT |#G102|=
 (|DFLOAT;manexp| |f| |$|) |DFLOAT;rationalApproximation;$2NniF;83|) (LETT =
|nu| (QCAR |#G102|) |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |ex| (Q=
CDR |#G102|) |DFLOAT;rationalApproximation;$2NniF;83|) |#G102|) (LETT BASE =
(|FLOAT-RADIX| 0.0) |DFLOAT;rationalApproximation;$2NniF;83|) (EXIT (COND (=
(|<| |ex| 0) (SEQ (LETT |de| (EXPT BASE (PROG1 (LETT #1# (|-| |ex|) |DFLOAT=
;rationalApproximation;$2NniF;83|) (|check-subtype| (|>=| #1# 0) (QUOTE (=
|NonNegativeInteger|)) #1#))) |DFLOAT;rationalApproximation;$2NniF;83|) (EX=
IT (COND ((|<| |b| 2) (|error| "base must be > 1")) ((QUOTE T) (SEQ (LETT |=
tol| (EXPT |b| |d|) |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |s| |nu=
| |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |t| |de| |DFLOAT;rational=
Approximation;$2NniF;83|) (LETT |p0| 0 |DFLOAT;rationalApproximation;$2NniF=
;83|) (LETT |p1| 1 |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |q0| 1 |=
DFLOAT;rationalApproximation;$2NniF;83|) (LETT |q1| 0 |DFLOAT;rationalAppro=
ximation;$2NniF;83|) (EXIT (SEQ G190 NIL (SEQ (PROGN (LETT |#G103| (DIVIDE2=
 |s| |t|) |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |q| (QCAR |#G103|=
) |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |r| (QCDR |#G103|) |DFLOA=
T;rationalApproximation;$2NniF;83|) |#G103|) (LETT |p2| (|+| (|*| |q| |p1|)=
 |p0|) |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |q2| (|+| (|*| |q| |=
q1|) |q0|) |DFLOAT;rationalApproximation;$2NniF;83|) (COND ((OR (EQL |r| 0)=
 (|<| (SPADCALL |tol| (ABS (|-| (|*| |nu| |q2|) (|*| |de| |p2|))) (QREFELT =
|$| 118)) (|*| |de| (ABS |p2|)))) (EXIT (PROGN (LETT #2# (SPADCALL |p2| |q2=
| (QREFELT |$| 117)) |DFLOAT;rationalApproximation;$2NniF;83|) (GO #2#)))))=
 (PROGN (LETT |#G104| |p1| |DFLOAT;rationalApproximation;$2NniF;83|) (LETT =
|#G105| |p2| |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |p0| |#G104| |=
DFLOAT;rationalApproximation;$2NniF;83|) (LETT |p1| |#G105| |DFLOAT;rationa=
lApproximation;$2NniF;83|)) (PROGN (LETT |#G106| |q1| |DFLOAT;rationalAppro=
ximation;$2NniF;83|) (LETT |#G107| |q2| |DFLOAT;rationalApproximation;$2Nni=
F;83|) (LETT |q0| |#G106| |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |=
q1| |#G107| |DFLOAT;rationalApproximation;$2NniF;83|)) (EXIT (PROGN (LETT |=
#G108| |t| |DFLOAT;rationalApproximation;$2NniF;83|) (LETT |#G109| |r| |DFL=
OAT;rationalApproximation;$2NniF;83|) (LETT |s| |#G108| |DFLOAT;rationalApp=
roximation;$2NniF;83|) (LETT |t| |#G109| |DFLOAT;rationalApproximation;$2Nn=
iF;83|)))) NIL (GO G190) G191 (EXIT NIL))))))))) ((QUOTE T) (SPADCALL (|*| =
|nu| (EXPT BASE (PROG1 (LETT #3# |ex| |DFLOAT;rationalApproximation;$2NniF;=
83|) (|check-subtype| (|>=| #3# 0) (QUOTE (|NonNegativeInteger|)) #3#))))=
 (QREFELT |$| 119))))))) #2# (EXIT #2#)))))
+(DEFUN |DFLOAT;abs;2$;82| (|x| $) (FLOAT-SIGN 1.0 |x|))

-(DEFUN |DFLOAT;**;$F$;84| (|x| |r| |$|) (PROG (|n| |d| #1=#:G105837) (RE=
TURN (SEQ (EXIT (COND ((ZEROP |x|) (COND ((SPADCALL |r| (QREFELT |$| 120)) =
(|error| "0**0 is undefined")) ((SPADCALL |r| (QREFELT |$| 121)) (|error| "=
division by 0")) ((QUOTE T) 0.0))) ((OR (SPADCALL |r| (QREFELT |$| 120)) (S=
PADCALL |x| (QREFELT |$| 122))) 1.0) ((QUOTE T) (COND ((SPADCALL |r| (QREFE=
LT |$| 123)) |x|) ((QUOTE T) (SEQ (LETT |n| (SPADCALL |r| (QREFELT |$| 124)=
) |DFLOAT;**;$F$;84|) (LETT |d| (SPADCALL |r| (QREFELT |$| 125)) |DFLOAT;**=
;$F$;84|) (EXIT (COND ((MINUSP |x|) (COND ((ODDP |d|) (COND ((ODDP |n|) (PR=
OGN (LETT #1# (|-| (SPADCALL (|-| |x|) |r| (QREFELT |$| 126))) |DFLOAT;**;$=
F$;84|) (GO #1#))) ((QUOTE T) (PROGN (LETT #1# (SPADCALL (|-| |x|) |r| (QRE=
FELT |$| 126)) |DFLOAT;**;$F$;84|) (GO #1#))))) ((QUOTE T) (|error| "negati=
ve root")))) ((EQL |d| 2) (EXPT (SPADCALL |x| (QREFELT |$| 54)) |n|)) ((QUO=
TE T) (SPADCALL |x| (|/| (FLOAT |n| |MOST-POSITIVE-LONG-FLOAT|) (FLOAT |d| =
|MOST-POSITIVE-LONG-FLOAT|)) (QREFELT |$| 57))))))))))) #1# (EXIT #1#)))))
+(DEFUN |DFLOAT;manexp| (|x| $) (PROG (|s| #0=#:G1545 |me| |two53|) (RETU=
RN (SEQ (EXIT (COND ((ZEROP |x|) (CONS 0 0)) ((QUOTE T) (SEQ (LETT |s| (SPA=
DCALL |x| (QREFELT $ 117)) |DFLOAT;manexp|) (LETT |x| (FLOAT-SIGN 1.0 |x|) =
|DFLOAT;manexp|) (COND ((< MOST-POSITIVE-LONG-FLOAT |x|) (PROGN (LETT #0# (=
CONS (+ (* |s| (SPADCALL MOST-POSITIVE-LONG-FLOAT (QREFELT $ 27))) 1) (SPAD=
CALL MOST-POSITIVE-LONG-FLOAT (QREFELT $ 28))) |DFLOAT;manexp|) (GO #0#))))=
 (LETT |me| (MANEXP |x|) |DFLOAT;manexp|) (LETT |two53| (EXPT (FLOAT-RADIX =
0.0) (FLOAT-DIGITS 0.0)) |DFLOAT;manexp|) (EXIT (CONS (* |s| (FIX (* |two53=
| (QCAR |me|)))) (- (QCDR |me|) (FLOAT-DIGITS 0.0)))))))) #0# (EXIT #0#))))=
)

-(DEFUN |DoubleFloat| NIL (PROG NIL (RETURN (PROG (#1=#:G105850) (RETURN =
(COND ((LETT #1# (HGET |$ConstructorCache| (QUOTE |DoubleFloat|)) |DoubleFl=
oat|) (|CDRwithIncrement| (CDAR #1#))) ((QUOTE T) (|UNWIND-PROTECT| (PROG1 =
(CDDAR (HPUT |$ConstructorCache| (QUOTE |DoubleFloat|) (LIST (CONS NIL (CON=
S 1 (|DoubleFloat;|)))))) (LETT #1# T |DoubleFloat|)) (COND ((NOT #1#) (HRE=
M |$ConstructorCache| (QUOTE |DoubleFloat|))))))))))))
+(DEFUN |DFLOAT;rationalApproximation;$2NniF;84| (|f| |d| |b| $) (PROG (|#G=
103| |nu| |ex| BASE #0=#:G1548 |de| |tol| |#G104| |q| |r| |p2| |q2| #1==
#:G1566 |#G105| |#G106| |p0| |p1| |#G107| |#G108| |q0| |q1| |#G109| |#G110|=
 |s| |t| #2=#:G1564) (RETURN (SEQ (EXIT (SEQ (PROGN (LETT |#G103| (|DFLOA=
T;manexp| |f| $) |DFLOAT;rationalApproximation;$2NniF;84|) (LETT |nu| (QCAR=
 |#G103|) |DFLOAT;rationalApproximation;$2NniF;84|) (LETT |ex| (QCDR |#G103=
|) |DFLOAT;rationalApproximation;$2NniF;84|) |#G103|) (LETT BASE (FLOAT-RAD=
IX 0.0) |DFLOAT;rationalApproximation;$2NniF;84|) (EXIT (COND ((< |ex| 0) (=
SEQ (LETT |de| (EXPT BASE (PROG1 (LETT #0# (- |ex|) |DFLOAT;rationalApproxi=
mation;$2NniF;84|) (|check-subtype| (>= #0# 0) (QUOTE (|NonNegativeIntege=
r|)) #0#))) |DFLOAT;rationalApproximation;$2NniF;84|) (EXIT (COND ((< |b| 2=
) (|error| "base must be > 1")) ((QUOTE T) (SEQ (LETT |tol| (EXPT |b| |d|) =
|DFLOAT;rationalApproximation;$2NniF;84|) (LETT |s| |nu| |DFLOAT;rationalAp=
proximation;$2NniF;84|) (LETT |t| |de| |DFLOAT;rationalApproximation;$2NniF=
;84|) (LETT |p0| 0 |DFLOAT;rationalApproximation;$2NniF;84|) (LETT |p1| 1 |=
DFLOAT;rationalApproximation;$2NniF;84|) (LETT |q0| 1 |DFLOAT;rationalAppro=
ximation;$2NniF;84|) (LETT |q1| 0 |DFLOAT;rationalApproximation;$2NniF;84|)=
 (EXIT (SEQ G190 NIL (SEQ (PROGN (LETT |#G104| (DIVIDE2 |s| |t|) |DFLOAT;ra=
tionalApproximation;$2NniF;84|) (LETT |q| (QCAR |#G104|) |DFLOAT;rationalAp=
proximation;$2NniF;84|) (LETT |r| (QCDR |#G104|) |DFLOAT;rationalApproximat=
ion;$2NniF;84|) |#G104|) (LETT |p2| (+ (* |q| |p1|) |p0|) |DFLOAT;rationalA=
pproximation;$2NniF;84|) (LETT |q2| (+ (* |q| |q1|) |q0|) |DFLOAT;rationalA=
pproximation;$2NniF;84|) (COND ((OR (EQL |r| 0) (< (SPADCALL |tol| (ABS (- =
(* |nu| |q2|) (* |de| |p2|))) (QREFELT $ 121)) (* |de| (ABS |p2|)))) (EXIT =
(PROGN (LETT #1# (SPADCALL |p2| |q2| (QREFELT $ 120)) |DFLOAT;rationalAppro=
ximation;$2NniF;84|) (GO #1#))))) (PROGN (LETT |#G105| |p1| |DFLOAT;rationa=
lApproximation;$2NniF;84|) (LETT |#G106| |p2| |DFLOAT;rationalApproximation=
;$2NniF;84|) (LETT |p0| |#G105| |DFLOAT;rationalApproximation;$2NniF;84|) (=
LETT |p1| |#G106| |DFLOAT;rationalApproximation;$2NniF;84|)) (PROGN (LETT |=
#G107| |q1| |DFLOAT;rationalApproximation;$2NniF;84|) (LETT |#G108| |q2| |D=
FLOAT;rationalApproximation;$2NniF;84|) (LETT |q0| |#G107| |DFLOAT;rational=
Approximation;$2NniF;84|) (LETT |q1| |#G108| |DFLOAT;rationalApproximation;=
$2NniF;84|)) (EXIT (PROGN (LETT |#G109| |t| |DFLOAT;rationalApproximation;$=
2NniF;84|) (LETT |#G110| |r| |DFLOAT;rationalApproximation;$2NniF;84|) (LET=
T |s| |#G109| |DFLOAT;rationalApproximation;$2NniF;84|) (LETT |t| |#G110| |=
DFLOAT;rationalApproximation;$2NniF;84|)))) NIL (GO G190) G191 (EXIT NIL)))=
)))))) ((QUOTE T) (SPADCALL (* |nu| (EXPT BASE (PROG1 (LETT #2# |ex| |DFLOA=
T;rationalApproximation;$2NniF;84|) (|check-subtype| (>= #2# 0) (QUOTE (|=
NonNegativeInteger|)) #2#)))) (QREFELT $ 122))))))) #1# (EXIT #1#)))))

-(DEFUN |DoubleFloat;| NIL (PROG (|dv$| |$| |pv$|) (RETURN (PROGN (LETT |dv=
$| (QUOTE (|DoubleFloat|)) . #1=(|DoubleFloat|)) (LETT |$| (GETREFV 140) =
. #1#) (QSETREFV |$| 0 |dv$|) (QSETREFV |$| 3 (LETT |pv$| (|buildPredVector=
| 0 0 NIL) . #1#)) (|haddProp| |$ConstructorCache| (QUOTE |DoubleFloat|) NI=
L (CONS 1 |$|)) (|stuffDomainSlots| |$|) |$|))))
+(DEFUN |DFLOAT;**;$F$;85| (|x| |r| $) (PROG (|n| |d| #0=#:G1575) (RETURN=
 (SEQ (EXIT (COND ((ZEROP |x|) (COND ((SPADCALL |r| (QREFELT $ 123)) (|erro=
r| "0**0 is undefined")) ((SPADCALL |r| (QREFELT $ 124)) (|error| "division=
 by 0")) ((QUOTE T) 0.0))) ((OR (SPADCALL |r| (QREFELT $ 123)) (= |x| 1.0=
)) 1.0) ((QUOTE T) (COND ((SPADCALL |r| (|spadConstant| $ 125) (QREFELT $ 1=
26)) |x|) ((QUOTE T) (SEQ (LETT |n| (SPADCALL |r| (QREFELT $ 127)) |DFLOAT;=
**;$F$;85|) (LETT |d| (SPADCALL |r| (QREFELT $ 128)) |DFLOAT;**;$F$;85|) (E=
XIT (COND ((MINUSP |x|) (COND ((ODDP |d|) (COND ((ODDP |n|) (PROGN (LETT #0=
# (- (SPADCALL (- |x|) |r| (QREFELT $ 129))) |DFLOAT;**;$F$;85|) (GO #0#)))=
 ((QUOTE T) (PROGN (LETT #0# (SPADCALL (- |x|) |r| (QREFELT $ 129)) |DFLOAT=
;**;$F$;85|) (GO #0#))))) ((QUOTE T) (|error| "negative root")))) ((EQL |d|=
 2) (EXPT (SPADCALL |x| (QREFELT $ 57)) |n|)) ((QUOTE T) (SPADCALL |x| (/ (=
FLOAT |n| MOST-POSITIVE-LONG-FLOAT) (FLOAT |d| MOST-POSITIVE-LONG-FLOAT)) (=
QREFELT $ 60))))))))))) #0# (EXIT #0#)))))

-(MAKEPROP (QUOTE |DoubleFloat|) (QUOTE |infovec|) (LIST (QUOTE #(NIL NIL N=
IL NIL NIL NIL (|OpenMathEncoding|) (0 . |OMencodingXML|) (|String|) (|Open=
MathDevice|) (4 . |OMopenString|) (|Void|) (10 . |OMputObject|) (|DoubleFlo=
at|) (15 . |OMputFloat|) (21 . |OMputEndObject|) (26 . |OMclose|) |DFLOAT;O=
Mwrite;$S;1| (|Boolean|) |DFLOAT;OMwrite;$BS;2| |DFLOAT;OMwrite;Omd$V;3| |D=
FLOAT;OMwrite;Omd$BV;4| (|PositiveInteger|) |DFLOAT;base;Pi;6| (|Integer|) =
|DFLOAT;mantissa;$I;7| |DFLOAT;exponent;$I;8| |DFLOAT;precision;Pi;9| |DFLO=
AT;log2;2$;37| (31 . |*|) |DFLOAT;bits;Pi;10| |DFLOAT;max;$;11| |DFLOAT;min=
;$;12| |DFLOAT;order;$I;13| (CONS IDENTITY (FUNCALL (|dispatchFunction| |DF=
LOAT;Zero;$;14|) |$|)) (CONS IDENTITY (FUNCALL (|dispatchFunction| |DFLOAT;=
One;$;15|) |$|)) |DFLOAT;exp1;$;16| |DFLOAT;pi;$;17| (|OutputForm|) (37 . |=
outputForm|) |DFLOAT;coerce;$Of;18| (|InputForm|) (42 . |convert|) |DFLOAT;=
convert;$If;19| |DFLOAT;<;2$B;20| |DFLOAT;-;2$;21| |DFLOAT;+;3$;22| |DFLOAT=
;-;3$;23| |DFLOAT;*;3$;24| |DFLOAT;*;I2$;25| |DFLOAT;max;3$;26| |DFLOAT;min=
;3$;27| |DFLOAT;=;2$B;28| |DFLOAT;/;$I$;29| |DFLOAT;sqrt;2$;30| |DFLOAT;l=
og10;2$;31| |DFLOAT;**;$I$;32| |DFLOAT;**;3$;33| |DFLOAT;coerce;I$;34| |DFL=
OAT;exp;2$;35| |DFLOAT;log;2$;36| |DFLOAT;sin;2$;38| |DFLOAT;cos;2$;39| |DF=
LOAT;tan;2$;40| |DFLOAT;cot;2$;41| |DFLOAT;sec;2$;42| |DFLOAT;csc;2$;43| |D=
FLOAT;asin;2$;44| |DFLOAT;acos;2$;45| |DFLOAT;atan;2$;46| |DFLOAT;acsc;2$;4=
7| |DFLOAT;acot;2$;48| |DFLOAT;asec;2$;49| |DFLOAT;sinh;2$;50| |DFLOAT;cosh=
;2$;51| |DFLOAT;tanh;2$;52| |DFLOAT;csch;2$;53| |DFLOAT;coth;2$;54| |DFLOAT=
;sech;2$;55| |DFLOAT;asinh;2$;56| |DFLOAT;acosh;2$;57| |DFLOAT;atanh;2$;58|=
 |DFLOAT;acsch;2$;59| |DFLOAT;acoth;2$;60| |DFLOAT;asech;2$;61| |DFLOAT;/;3=
$;62| |DFLOAT;negative?;$B;63| |DFLOAT;zero?;$B;64| |DFLOAT;hash;$I;65| (|U=
nion| |$| (QUOTE "failed")) |DFLOAT;recip;$U;66| |DFLOAT;differentiate;2$;6=
7| (|DoubleFloatSpecialFunctions|) (47 . |Gamma|) |DFLOAT;Gamma;2$;68| (52 =
. |Beta|) |DFLOAT;Beta;3$;69| |DFLOAT;wholePart;$I;70| |DFLOAT;float;2IPi$;=
71| |DFLOAT;convert;2$;72| (|Float|) (58 . |convert|) |DFLOAT;convert;$F;73=
| (|Fraction| 24) (|NonNegativeInteger|) |DFLOAT;rationalApproximation;$2Nn=
iF;83| |DFLOAT;rationalApproximation;$NniF;74| |DFLOAT;atan;3$;75| |DFLOAT;=
retract;$F;76| (|Union| 103 (QUOTE "failed")) |DFLOAT;retractIfCan;$U;77| |=
DFLOAT;retract;$I;78| (|Union| 24 (QUOTE "failed")) |DFLOAT;retractIfCan;$U=
;79| |DFLOAT;sign;$I;80| |DFLOAT;abs;2$;81| (63 . |Zero|) (67 . |/|) (73 . =
|*|) (79 . |coerce|) (84 . |zero?|) (89 . |negative?|) (94 . |one?|) (99 . =
|one?|) (104 . |numer|) (109 . |denom|) |DFLOAT;**;$F$;84| (|Pattern| 100) =
(|PatternMatchResult| 100 |$|) (|Factored| |$|) (|Union| 131 (QUOTE "failed=
")) (|List| |$|) (|Record| (|:| |coef1| |$|) (|:| |coef2| |$|) (|:| |genera=
tor| |$|)) (|Record| (|:| |coef1| |$|) (|:| |coef2| |$|)) (|Union| 133 (QUO=
TE "failed")) (|Record| (|:| |quotient| |$|) (|:| |remainder| |$|)) (|Recor=
d| (|:| |coef| 131) (|:| |generator| |$|)) (|SparseUnivariatePolynomial| |$=
|) (|Record| (|:| |unit| |$|) (|:| |canonical| |$|) (|:| |associate| |$|)) =
(|SingleInteger|))) (QUOTE #(|~=| 114 |zero?| 120 |wholePart| 125 |unitNo=
rmal| 130 |unitCanonical| 135 |unit?| 140 |truncate| 145 |tanh| 150 |tan| 1=
55 |subtractIfCan| 160 |squareFreePart| 166 |squareFree| 171 |sqrt| 176 |si=
zeLess?| 181 |sinh| 187 |sin| 192 |sign| 197 |sech| 202 |sec| 207 |sample| =
212 |round| 216 |retractIfCan| 221 |retract| 231 |rem| 241 |recip| 247 |rat=
ionalApproximation| 252 |quo| 265 |principalIdeal| 271 |prime?| 276 |precis=
ion| 281 |positive?| 285 |pi| 290 |patternMatch| 294 |order| 301 |one?| 306=
 |nthRoot| 311 |norm| 317 |negative?| 322 |multiEuclidean| 327 |min| 333 |m=
ax| 343 |mantissa| 353 |log2| 358 |log10| 363 |log| 368 |lcm| 373 |latex| 3=
84 |inv| 389 |hash| 394 |gcdPolynomial| 404 |gcd| 410 |fractionPart| 421 |f=
loor| 426 |float| 431 |factor| 444 |extendedEuclidean| 449 |exquo| 462 |exp=
ressIdealMember| 468 |exponent| 474 |exp1| 479 |exp| 483 |euclideanSize| 48=
8 |divide| 493 |digits| 499 |differentiate| 503 |csch| 514 |csc| 519 |coth|=
 524 |cot| 529 |cosh| 534 |cos| 539 |convert| 544 |coerce| 564 |characteris=
tic| 594 |ceiling| 598 |bits| 603 |base| 607 |atanh| 611 |atan| 616 |associ=
ates?| 627 |asinh| 633 |asin| 638 |asech| 643 |asec| 648 |acsch| 653 |acsc|=
 658 |acoth| 663 |acot| 668 |acosh| 673 |acos| 678 |abs| 683 |^| 688 |Zero|=
 706 |One| 710 |OMwrite| 714 |Gamma| 738 D 743 |Beta| 754 |>=| 760 |>| 76=
6 |=| 772 |<=| 778 |<| 784 |/| 790 |-| 802 |+| 813 |**| 819 |*| 849)) (=
QUOTE ((|approximate| . 0) (|canonicalsClosed| . 0) (|canonicalUnitNormal| =
. 0) (|noZeroDivisors| . 0) ((|commutative| "*") . 0) (|rightUnitary| . 0) =
(|leftUnitary| . 0) (|unitsKnown| . 0))) (CONS (|makeByteWordVec2| 1 (QUOTE=
 (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0=
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0))) (CONS (QUOTE #(|FloatingPointSyst=
em&| |RealNumberSystem&| |Field&| |EuclideanDomain&| NIL |UniqueFactorizati=
onDomain&| |GcdDomain&| |DivisionRing&| |IntegralDomain&| |Algebra&| |Algeb=
ra&| |DifferentialRing&| NIL |OrderedRing&| |Module&| NIL NIL |Module&| NIL=
 NIL NIL |Ring&| NIL NIL NIL NIL NIL NIL NIL |AbelianGroup&| NIL NIL |Abeli=
anMonoid&| |Monoid&| NIL |OrderedSet&| |AbelianSemiGroup&| |SemiGroup&| |Tr=
anscendentalFunctionCategory&| NIL |SetCategory&| NIL |ElementaryFunctionCa=
tegory&| NIL |HyperbolicFunctionCategory&| |ArcTrigonometricFunctionCategor=
y&| |TrigonometricFunctionCategory&| NIL NIL |RadicalCategory&| |Retractabl=
eTo&| |RetractableTo&| NIL NIL |BasicType&| NIL)) (CONS (QUOTE #((|Floating=
PointSystem|) (|RealNumberSystem|) (|Field|) (|EuclideanDomain|) (|Principa=
lIdealDomain|) (|UniqueFactorizationDomain|) (|GcdDomain|) (|DivisionRing|)=
 (|IntegralDomain|) (|Algebra| 103) (|Algebra| |$$|) (|DifferentialRing|) (=
|CharacteristicZero|) (|OrderedRing|) (|Module| 103) (|EntireRing|) (|Commu=
tativeRing|) (|Module| |$$|) (|OrderedAbelianGroup|) (|BiModule| 103 103) (=
|BiModule| |$$| |$$|) (|Ring|) (|OrderedCancellationAbelianMonoid|) (|Right=
Module| 103) (|LeftModule| 103) (|LeftModule| |$$|) (|Rng|) (|RightModule| =
|$$|) (|OrderedAbelianMonoid|) (|AbelianGroup|) (|OrderedAbelianSemiGroup|)=
 (|CancellationAbelianMonoid|) (|AbelianMonoid|) (|Monoid|) (|PatternMatcha=
ble| 100) (|OrderedSet|) (|AbelianSemiGroup|) (|SemiGroup|) (|Transcendenta=
lFunctionCategory|) (|RealConstant|) (|SetCategory|) (|ConvertibleTo| 41) (=
|ElementaryFunctionCategory|) (|ArcHyperbolicFunctionCategory|) (|Hyperboli=
cFunctionCategory|) (|ArcTrigonometricFunctionCategory|) (|TrigonometricFun=
ctionCategory|) (|OpenMath|) (|ConvertibleTo| 127) (|RadicalCategory|) (|Re=
tractableTo| 103) (|RetractableTo| 24) (|ConvertibleTo| 100) (|ConvertibleT=
o| 13) (|BasicType|) (|CoercibleTo| 38))) (|makeByteWordVec2| 139 (QUOTE (0=
 6 0 7 2 9 0 8 6 10 1 9 11 0 12 2 9 11 0 13 14 1 9 11 0 15 1 9 11 0 16 2 0 =
0 22 0 29 1 38 0 13 39 1 41 0 13 42 1 92 13 13 93 2 92 13 13 13 95 1 100 0 =
13 101 0 103 0 116 2 103 0 24 24 117 2 24 0 104 0 118 1 103 0 24 119 1 103 =
18 0 120 1 103 18 0 121 1 0 18 0 122 1 103 18 0 123 1 103 24 0 124 1 103 24=
 0 125 2 0 18 0 0 1 1 0 18 0 87 1 0 24 0 97 1 0 138 0 1 1 0 0 0 1 1 0 18 0 =
1 1 0 0 0 1 1 0 0 0 75 1 0 0 0 63 2 0 89 0 0 1 1 0 0 0 1 1 0 129 0 1 1 0 0 =
0 54 2 0 18 0 0 1 1 0 0 0 73 1 0 0 0 61 1 0 24 0 114 1 0 0 0 78 1 0 0 0 65 =
0 0 0 1 1 0 0 0 1 1 0 109 0 110 1 0 112 0 113 1 0 103 0 108 1 0 24 0 111 2 =
0 0 0 0 1 1 0 89 0 90 2 0 103 0 104 106 3 0 103 0 104 104 105 2 0 0 0 0 1 1=
 0 136 131 1 1 0 18 0 1 0 0 22 27 1 0 18 0 1 0 0 0 37 3 0 128 0 127 128 1 1=
 0 24 0 33 1 0 18 0 122 2 0 0 0 24 1 1 0 0 0 1 1 0 18 0 86 2 0 130 131 0 1 =
0 0 0 32 2 0 0 0 0 51 0 0 0 31 2 0 0 0 0 50 1 0 24 0 25 1 0 0 0 28 1 0 0 0 =
55 1 0 0 0 60 1 0 0 131 1 2 0 0 0 0 1 1 0 8 0 1 1 0 0 0 1 1 0 24 0 88 1 0 1=
39 0 1 2 0 137 137 137 1 1 0 0 131 1 2 0 0 0 0 1 1 0 0 0 1 1 0 0 0 1 3 0 0 =
24 24 22 98 2 0 0 24 24 1 1 0 129 0 1 2 0 132 0 0 1 3 0 134 0 0 0 1 2 0 89 =
0 0 1 2 0 130 131 0 1 1 0 24 0 26 0 0 0 36 1 0 0 0 59 1 0 104 0 1 2 0 135 0=
 0 1 0 0 22 1 1 0 0 0 91 2 0 0 0 104 1 1 0 0 0 76 1 0 0 0 66 1 0 0 0 77 1 0=
 0 0 64 1 0 0 0 74 1 0 0 0 62 1 0 41 0 43 1 0 127 0 1 1 0 13 0 99 1 0 100 0=
 102 1 0 0 103 1 1 0 0 24 58 1 0 0 103 1 1 0 0 24 58 1 0 0 0 1 1 0 38 0 40 =
0 0 104 1 1 0 0 0 1 0 0 22 30 0 0 22 23 1 0 0 0 81 2 0 0 0 0 107 1 0 0 0 69=
 2 0 18 0 0 1 1 0 0 0 79 1 0 0 0 67 1 0 0 0 84 1 0 0 0 72 1 0 0 0 82 1 0 0 =
0 70 1 0 0 0 83 1 0 0 0 71 1 0 0 0 80 1 0 0 0 68 1 0 0 0 115 2 0 0 0 24 1 2=
 0 0 0 104 1 2 0 0 0 22 1 0 0 0 34 0 0 0 35 2 0 11 9 0 20 3 0 11 9 0 18 21 =
1 0 8 0 17 2 0 8 0 18 19 1 0 0 0 94 1 0 0 0 1 2 0 0 0 104 1 2 0 0 0 0 96 2 =
0 18 0 0 1 2 0 18 0 0 1 2 0 18 0 0 52 2 0 18 0 0 1 2 0 18 0 0 44 2 0 0 0 24=
 53 2 0 0 0 0 85 2 0 0 0 0 47 1 0 0 0 45 2 0 0 0 0 46 2 0 0 0 0 57 2 0 0 0 =
103 126 2 0 0 0 24 56 2 0 0 0 104 1 2 0 0 0 22 1 2 0 0 0 103 1 2 0 0 103 0 =
1 2 0 0 0 0 48 2 0 0 24 0 49 2 0 0 104 0 1 2 0 0 22 0 29)))))) (QUOTE |look=
upComplete|)))
+(DEFUN |DoubleFloat| NIL (PROG NIL (RETURN (PROG (#0=#:G1588) (RETURN (C=
OND ((LETT #0# (HGET |$ConstructorCache| (QUOTE |DoubleFloat|)) |DoubleFloa=
t|) (|CDRwithIncrement| (CDAR #0#))) ((QUOTE T) (UNWIND-PROTECT (PROG1 (CDD=
AR (HPUT |$ConstructorCache| (QUOTE |DoubleFloat|) (LIST (CONS NIL (CONS 1 =
(|DoubleFloat;|)))))) (LETT #0# T |DoubleFloat|)) (COND ((NOT #0#) (HREM |$=
ConstructorCache| (QUOTE |DoubleFloat|))))))))))))
+
+(DEFUN |DoubleFloat;| NIL (PROG (|dv$| $ |pv$|) (RETURN (PROGN (LETT |dv$|=
 (QUOTE (|DoubleFloat|)) . #0=(|DoubleFloat|)) (LETT $ (GETREFV 143) . #0=
#) (QSETREFV $ 0 |dv$|) (QSETREFV $ 3 (LETT |pv$| (|buildPredVector| 0 0 NI=
L) . #0#)) (|haddProp| |$ConstructorCache| (QUOTE |DoubleFloat|) NIL (CONS =
1 $)) (|stuffDomainSlots| $) (QSETREFV $ 6 "~A") $))))
+
+(MAKEPROP (QUOTE |DoubleFloat|) (QUOTE |infovec|) (LIST (QUOTE #(NIL NIL N=
IL NIL NIL NIL (QUOTE |format|) (|String|) |DFLOAT;doubleFloatFormat;2S;1| =
(|OpenMathEncoding|) (0 . |OMencodingXML|) (|OpenMathDevice|) (4 . |OMopenS=
tring|) (|Void|) (10 . |OMputObject|) (|DoubleFloat|) (15 . |OMputFloat|) (=
21 . |OMputEndObject|) (26 . |OMclose|) |DFLOAT;OMwrite;$S;2| (|Boolean|) |=
DFLOAT;OMwrite;$BS;3| |DFLOAT;OMwrite;Omd$V;4| |DFLOAT;OMwrite;Omd$BV;5| (|=
PositiveInteger|) |DFLOAT;base;Pi;7| (|Integer|) |DFLOAT;mantissa;$I;8| |DF=
LOAT;exponent;$I;9| |DFLOAT;precision;Pi;10| |DFLOAT;log2;2$;38| (31 . *) |=
DFLOAT;bits;Pi;11| |DFLOAT;max;$;12| |DFLOAT;min;$;13| |DFLOAT;order;$I;14|=
 (CONS IDENTITY (FUNCALL (|dispatchFunction| |DFLOAT;Zero;$;15|) $)) (CONS =
IDENTITY (FUNCALL (|dispatchFunction| |DFLOAT;One;$;16|) $)) |DFLOAT;exp1;$=
;17| |DFLOAT;pi;$;18| (|OutputForm|) (37 . |message|) (42 . -) |DFLOAT;coer=
ce;$Of;19| (|InputForm|) (47 . |convert|) |DFLOAT;convert;$If;20| |DFLOAT;<=
;2$B;21| |DFLOAT;-;2$;22| |DFLOAT;+;3$;23| |DFLOAT;-;3$;24| |DFLOAT;*;3$;25=
| |DFLOAT;*;I2$;26| |DFLOAT;max;3$;27| |DFLOAT;min;3$;28| |DFLOAT;=;2$B;2=
9| |DFLOAT;/;$I$;30| |DFLOAT;sqrt;2$;31| |DFLOAT;log10;2$;32| |DFLOAT;**;$I=
$;33| |DFLOAT;**;3$;34| |DFLOAT;coerce;I$;35| |DFLOAT;exp;2$;36| |DFLOAT;lo=
g;2$;37| |DFLOAT;sin;2$;39| |DFLOAT;cos;2$;40| |DFLOAT;tan;2$;41| |DFLOAT;c=
ot;2$;42| |DFLOAT;sec;2$;43| |DFLOAT;csc;2$;44| |DFLOAT;asin;2$;45| |DFLOAT=
;acos;2$;46| |DFLOAT;atan;2$;47| |DFLOAT;acsc;2$;48| |DFLOAT;acot;2$;49| |D=
FLOAT;asec;2$;50| |DFLOAT;sinh;2$;51| |DFLOAT;cosh;2$;52| |DFLOAT;tanh;2$;5=
3| |DFLOAT;csch;2$;54| |DFLOAT;coth;2$;55| |DFLOAT;sech;2$;56| |DFLOAT;asin=
h;2$;57| |DFLOAT;acosh;2$;58| |DFLOAT;atanh;2$;59| |DFLOAT;acsch;2$;60| |DF=
LOAT;acoth;2$;61| |DFLOAT;asech;2$;62| |DFLOAT;/;3$;63| |DFLOAT;negative?;$=
B;64| |DFLOAT;zero?;$B;65| |DFLOAT;hash;$I;66| (|Union| $ (QUOTE "failed"))=
 |DFLOAT;recip;$U;67| |DFLOAT;differentiate;2$;68| (|DoubleFloatSpecialFunc=
tions|) (52 . |Gamma|) |DFLOAT;Gamma;2$;69| (57 . |Beta|) |DFLOAT;Beta;3$;7=
0| |DFLOAT;wholePart;$I;71| |DFLOAT;float;2IPi$;72| |DFLOAT;convert;2$;73| =
(|Float|) (63 . |convert|) |DFLOAT;convert;$F;74| (|Fraction| 26) (|NonNega=
tiveInteger|) |DFLOAT;rationalApproximation;$2NniF;84| |DFLOAT;rationalAppr=
oximation;$NniF;75| |DFLOAT;atan;3$;76| |DFLOAT;retract;$F;77| (|Union| 106=
 (QUOTE "failed")) |DFLOAT;retractIfCan;$U;78| |DFLOAT;retract;$I;79| (|Uni=
on| 26 (QUOTE "failed")) |DFLOAT;retractIfCan;$U;80| |DFLOAT;sign;$I;81| |D=
FLOAT;abs;2$;82| (68 . |Zero|) (72 . /) (78 . *) (84 . |coerce|) (89 . |zer=
o?|) (94 . |negative?|) (99 . |One|) (103 . =) (109 . |numer|) (114 . |de=
nom|) |DFLOAT;**;$F$;85| (|PatternMatchResult| 103 $) (|Pattern| 103) (|Fac=
tored| $) (|Union| 134 (QUOTE "failed")) (|List| $) (|Record| (|:| |coef1| =
$) (|:| |coef2| $) (|:| |generator| $)) (|Record| (|:| |coef1| $) (|:| |coe=
f2| $)) (|Union| 136 (QUOTE "failed")) (|Record| (|:| |quotient| $) (|:| |r=
emainder| $)) (|Record| (|:| |coef| 134) (|:| |generator| $)) (|SparseUniva=
riatePolynomial| $) (|Record| (|:| |unit| $) (|:| |canonical| $) (|:| |asso=
ciate| $)) (|SingleInteger|))) (QUOTE #(~= 119 |zero?| 125 |wholePart| 13=
0 |unitNormal| 135 |unitCanonical| 140 |unit?| 145 |truncate| 150 |tanh| 15=
5 |tan| 160 |subtractIfCan| 165 |squareFreePart| 171 |squareFree| 176 |sqrt=
| 181 |sizeLess?| 186 |sinh| 192 |sin| 197 |sign| 202 |sech| 207 |sec| 212 =
|sample| 217 |round| 221 |retractIfCan| 226 |retract| 236 |rem| 246 |recip|=
 252 |rationalApproximation| 257 |quo| 270 |principalIdeal| 276 |prime?| 28=
1 |precision| 286 |positive?| 290 |pi| 295 |patternMatch| 299 |order| 306 |=
one?| 311 |nthRoot| 316 |norm| 322 |negative?| 327 |multiEuclidean| 332 |mi=
n| 338 |max| 348 |mantissa| 358 |log2| 363 |log10| 368 |log| 373 |lcm| 378 =
|latex| 389 |inv| 394 |hash| 399 |gcdPolynomial| 409 |gcd| 415 |fractionPar=
t| 426 |floor| 431 |float| 436 |factor| 449 |extendedEuclidean| 454 |exquo|=
 467 |expressIdealMember| 473 |exponent| 479 |exp1| 484 |exp| 488 |euclidea=
nSize| 493 |doubleFloatFormat| 498 |divide| 503 |digits| 509 |differentiate=
| 513 |csch| 524 |csc| 529 |coth| 534 |cot| 539 |cosh| 544 |cos| 549 |conve=
rt| 554 |coerce| 574 |characteristic| 604 |ceiling| 608 |bits| 613 |base| 6=
17 |atanh| 621 |atan| 626 |associates?| 637 |asinh| 643 |asin| 648 |asech| =
653 |asec| 658 |acsch| 663 |acsc| 668 |acoth| 673 |acot| 678 |acosh| 683 |a=
cos| 688 |abs| 693 ^ 698 |Zero| 716 |One| 720 |OMwrite| 724 |Gamma| 748 D 7=
53 |Beta| 764 >= 770 > 776 = 782 <= 788 < 794 / 800 - 812 + 823 ** 82=
9 * 859)) (QUOTE ((|approximate| . 0) (|canonicalsClosed| . 0) (|canonicalU=
nitNormal| . 0) (|noZeroDivisors| . 0) ((|commutative| "*") . 0) (|rightUni=
tary| . 0) (|leftUnitary| . 0) (|unitsKnown| . 0))) (CONS (|makeByteWordVec=
2| 1 (QUOTE (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0))) (CONS (QUOTE #(|Floati=
ngPointSystem&| |RealNumberSystem&| |Field&| |EuclideanDomain&| NIL |Unique=
FactorizationDomain&| |GcdDomain&| |DivisionRing&| |IntegralDomain&| |Algeb=
ra&| |Algebra&| |DifferentialRing&| NIL |OrderedRing&| |Module&| NIL NIL |M=
odule&| NIL NIL NIL |Ring&| NIL NIL NIL NIL NIL NIL NIL |AbelianGroup&| NIL=
 NIL |AbelianMonoid&| |Monoid&| NIL |OrderedSet&| |AbelianSemiGroup&| |Semi=
Group&| |TranscendentalFunctionCategory&| NIL |SetCategory&| NIL |Elementar=
yFunctionCategory&| NIL |HyperbolicFunctionCategory&| |ArcTrigonometricFunc=
tionCategory&| |TrigonometricFunctionCategory&| NIL NIL |RadicalCategory&| =
|RetractableTo&| |RetractableTo&| NIL NIL |BasicType&| NIL)) (CONS (QUOTE #=
((|FloatingPointSystem|) (|RealNumberSystem|) (|Field|) (|EuclideanDomain|)=
 (|PrincipalIdealDomain|) (|UniqueFactorizationDomain|) (|GcdDomain|) (|Div=
isionRing|) (|IntegralDomain|) (|Algebra| 106) (|Algebra| $$) (|Differentia=
lRing|) (|CharacteristicZero|) (|OrderedRing|) (|Module| 106) (|EntireRing|=
) (|CommutativeRing|) (|Module| $$) (|OrderedAbelianGroup|) (|BiModule| 106=
 106) (|BiModule| $$ $$) (|Ring|) (|OrderedCancellationAbelianMonoid|) (|Ri=
ghtModule| 106) (|LeftModule| 106) (|LeftModule| $$) (|Rng|) (|RightModule|=
 $$) (|OrderedAbelianMonoid|) (|AbelianGroup|) (|OrderedAbelianSemiGroup|) =
(|CancellationAbelianMonoid|) (|AbelianMonoid|) (|Monoid|) (|PatternMatchab=
le| 103) (|OrderedSet|) (|AbelianSemiGroup|) (|SemiGroup|) (|Transcendental=
FunctionCategory|) (|RealConstant|) (|SetCategory|) (|ConvertibleTo| 44) (|=
ElementaryFunctionCategory|) (|ArcHyperbolicFunctionCategory|) (|Hyperbolic=
FunctionCategory|) (|ArcTrigonometricFunctionCategory|) (|TrigonometricFunc=
tionCategory|) (|OpenMath|) (|ConvertibleTo| 131) (|RadicalCategory|) (|Ret=
ractableTo| 106) (|RetractableTo| 26) (|ConvertibleTo| 103) (|ConvertibleTo=
| 15) (|BasicType|) (|CoercibleTo| 40))) (|makeByteWordVec2| 142 (QUOTE (0 =
9 0 10 2 11 0 7 9 12 1 11 13 0 14 2 11 13 0 15 16 1 11 13 0 17 1 11 13 0 18=
 2 0 0 24 0 31 1 40 0 7 41 1 40 0 0 42 1 44 0 15 45 1 95 15 15 96 2 95 15 1=
5 15 98 1 103 0 15 104 0 106 0 119 2 106 0 26 26 120 2 26 0 107 0 121 1 106=
 0 26 122 1 106 20 0 123 1 106 20 0 124 0 106 0 125 2 106 20 0 0 126 1 106 =
26 0 127 1 106 26 0 128 2 0 20 0 0 1 1 0 20 0 90 1 0 26 0 100 1 0 141 0 1 1=
 0 0 0 1 1 0 20 0 1 1 0 0 0 1 1 0 0 0 78 1 0 0 0 66 2 0 92 0 0 1 1 0 0 0 1 =
1 0 132 0 1 1 0 0 0 57 2 0 20 0 0 1 1 0 0 0 76 1 0 0 0 64 1 0 26 0 117 1 0 =
0 0 81 1 0 0 0 68 0 0 0 1 1 0 0 0 1 1 0 112 0 113 1 0 115 0 116 1 0 106 0 1=
11 1 0 26 0 114 2 0 0 0 0 1 1 0 92 0 93 2 0 106 0 107 109 3 0 106 0 107 107=
 108 2 0 0 0 0 1 1 0 139 134 1 1 0 20 0 1 0 0 24 29 1 0 20 0 1 0 0 0 39 3 0=
 130 0 131 130 1 1 0 26 0 35 1 0 20 0 1 2 0 0 0 26 1 1 0 0 0 1 1 0 20 0 89 =
2 0 133 134 0 1 0 0 0 34 2 0 0 0 0 54 0 0 0 33 2 0 0 0 0 53 1 0 26 0 27 1 0=
 0 0 30 1 0 0 0 58 1 0 0 0 63 1 0 0 134 1 2 0 0 0 0 1 1 0 7 0 1 1 0 0 0 1 1=
 0 26 0 91 1 0 142 0 1 2 0 140 140 140 1 1 0 0 134 1 2 0 0 0 0 1 1 0 0 0 1 =
1 0 0 0 1 3 0 0 26 26 24 101 2 0 0 26 26 1 1 0 132 0 1 2 0 135 0 0 1 3 0 13=
7 0 0 0 1 2 0 92 0 0 1 2 0 133 134 0 1 1 0 26 0 28 0 0 0 38 1 0 0 0 62 1 0 =
107 0 1 1 0 7 7 8 2 0 138 0 0 1 0 0 24 1 1 0 0 0 94 2 0 0 0 107 1 1 0 0 0 7=
9 1 0 0 0 69 1 0 0 0 80 1 0 0 0 67 1 0 0 0 77 1 0 0 0 65 1 0 44 0 46 1 0 13=
1 0 1 1 0 103 0 105 1 0 15 0 102 1 0 0 106 1 1 0 0 26 61 1 0 0 106 1 1 0 0 =
26 61 1 0 0 0 1 1 0 40 0 43 0 0 107 1 1 0 0 0 1 0 0 24 32 0 0 24 25 1 0 0 0=
 84 2 0 0 0 0 110 1 0 0 0 72 2 0 20 0 0 1 1 0 0 0 82 1 0 0 0 70 1 0 0 0 87 =
1 0 0 0 75 1 0 0 0 85 1 0 0 0 73 1 0 0 0 86 1 0 0 0 74 1 0 0 0 83 1 0 0 0 7=
1 1 0 0 0 118 2 0 0 0 26 1 2 0 0 0 107 1 2 0 0 0 24 1 0 0 0 36 0 0 0 37 3 0=
 13 11 0 20 23 2 0 7 0 20 21 2 0 13 11 0 22 1 0 7 0 19 1 0 0 0 97 1 0 0 0 1=
 2 0 0 0 107 1 2 0 0 0 0 99 2 0 20 0 0 1 2 0 20 0 0 1 2 0 20 0 0 55 2 0 20 =
0 0 1 2 0 20 0 0 47 2 0 0 0 26 56 2 0 0 0 0 88 2 0 0 0 0 50 1 0 0 0 48 2 0 =
0 0 0 49 2 0 0 0 0 60 2 0 0 0 106 129 2 0 0 0 26 59 2 0 0 0 107 1 2 0 0 0 2=
4 1 2 0 0 0 106 1 2 0 0 106 0 1 2 0 0 0 0 51 2 0 0 26 0 52 2 0 0 107 0 1 2 =
0 0 24 0 31)))))) (QUOTE |lookupComplete|)))

 (MAKEPROP (QUOTE |DoubleFloat|) (QUOTE NILADIC) T)
+
 @
 \section{License}
 <<license>>=

\start
Date: Thu, 15 Feb 2007 23:17:10 +0100
From: Gregory Vanuxem
To: list
Subject: Re: Lisp format in sf.spad.pamphlet

Le jeudi 15 f=E9vrier 2007 =E0 22:55 +0100, Gregory Vanuxem a =E9crit :

> A suggestion, what about using )spool to produce *.output file?
> (to simplify the comparison via diff of two versions of Axiom (differen=
t
> banners)).

I forgot one thing, GCL adds something like "Starts dribbling to
test.axiom (2007/2/15, 23:13:40)" in the output file so this suggestion
does not help.

\start
Date: Fri, 16 Feb 2007 00:56:20 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: Lisp format in sf.spad.pamphlet

Gregory Vanuxem wrote:
> Hello,
> 
> I have introduced two bugs in DFLOAT when I sent a patch against
> sf.spad.pamphlet (outputting routine). Try, for example,
> complex(1.7,-2.3@SF) or 3.0*x^3+-2.7@SF*x^2. Furthermore, the directive
> used ("~G") is not "the" good one (it's not portable, the directive
> works this way only on GCL). Patch in attachment (I have used the Float
> method (via 'message')).
>

I wonder how portable "~A" is.  The standard promises nice output,
but nothing more.  OTOH all Lisp implementations that I tried get
"~G" wrong (GCL does not add trailing spaces, the other lose
some significant digits).
 
> A suggestion, what about using )spool to produce *.output file?
> (to simplify the comparison via diff of two versions of Axiom (different
> banners)).
> 

FYI: I use the script below.  The crucial thing is at the end:
I use sed to delete banner and timing messages.  I also normalize
paths that appear for various reasons (most from 'Loading' messages).


---------------------------<cut here>-------------------------
#!/bin/sh

DIR1=$1
DIR2=$2


echo DIR1=$DIR1
echo DIR2=$DIR2

ADIR1=$(cd $DIR1; pwd)
ADIR2=$(cd $DIR2; pwd)

verify_dir () {
if ! [ -d $1 ] ; then
  echo $1: does not exist
  exit
fi
}

verify_dir $ADIR1
verify_dir $ADIR2

IDIR1=$ADIR1/int/input
IDIR2=$ADIR2/int/input

verify_dir $IDIR1
verify_dir $IDIR2

TDIR1=$ADIR1/mnt
TDIR2=$ADIR2/mnt
if ! [ -d $TDIR1 ] ; then
    TDIR1=$ADIR1/target
fi
if ! [ -d $TDIR2 ] ; then
    TDIR2=$ADIR2/target
fi

verify_dir $TDIR1
verify_dir $TDIR2

PLF=""
for A in $(ls $TDIR1); do
  if [ -d $TDIR1/$A ] ; then
     if [ "$PLF"x != x ] ; then
        echo $TDIR1: contains more then one subdirectory
     else
        PLF=$A
     fi
  fi
done

AX1=$TDIR1/$PLF

PLF=""
for A in $(ls $TDIR2); do
  if [ -d $TDIR2/$A ] ; then
     if [ "$PLF"x != x ] ; then
        echo $TDIR2: contains more then one subdirectory
     else
        PLF=$A
     fi
  fi
done

AX2=$TDIR2/$PLF

echo AX1=$AX1
echo AX2=$AX2

trap "rm -f /tmp/tcmp1.$$ /tmp/tcmp2.$$" 0 2 3 15

cd $IDIR1
for A in *.output; do
  echo Diffing $A
  if ! [ -f $IDIR2/$A ] ; then
     echo $A: only in $IDIR1
  else
     sed "1,/^(/d;/^ *Time: /d;s,$AX1,AXIOM,g" $A > /tmp/tcmp1.$$
     sed "1,/^(/d;/^ *Time: /d;s,$AX2,AXIOM,g" $IDIR2/$A > /tmp/tcmp2.$$
     diff -u /tmp/tcmp1.$$ /tmp/tcmp2.$$
  fi
done

-----------------------<cut here>------------------------

\start
Date: Thu, 15 Feb 2007 23:47:18 -0800 (PST)
From: Cliff Yapp
To: list
Subject: A first attempt at a notangle in Lisp

I hesitate to say it's useful, but I have what appears to be a (more or
less) working notangle command in lisp.  It successfully handles a
couple test files, and although I haven't inspected the results it
handled most of the contents of boot and interp without crashing. 
Unfortunately it's performance is worse than abysmal.  The first result
is with noweb's notangle on the boot and interp directories, the second
with the lisp one:

CL-USER> (load "./setup/cleardirs.lisp")
T
CL-USER> (time (load "./setup/runnotangle.lisp"))
Evaluation took:
  7.172 seconds of real time
  0.892056 seconds of user run time
  1.44809 seconds of system run time
  [Run times include 0.016 seconds GC run time.]
  0 calls to %EVAL
  0 page faults and
  12,691,344 bytes consed.
T
CL-USER> (load "./setup/cleardirs.lisp")
T
CL-USER> (time (load "./setup/runlispnotangle.lisp"))
Evaluation took:
  610.982 seconds of real time
  591.209 seconds of user run time
  10.440652 seconds of system run time
  [Run times include 15.088 seconds GC run time.]
  0 calls to %EVAL
  0 page faults and
  12,712,508,936 bytes consed.
T

What I'm hoping is all of the things I've undoubtedly done very very
wrong can be fixed, but I'm not sure at this point.  In the hopes that
this will prod someone into doing it right, I'll upload the files (and
yes the cl-notangle.lisp file was notangled by cl-notangle ;-).  I
haven't got a noweb command in lisp yet though, which I guess we would
need unless we switch to the latex-as-chunks style.

Cheers,
CY



 
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love 
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265 
--0-279212549-1171612038=:61325

XGRvY3VtZW50Y2xhc3N7YXJ0aWNsZX0gClx1c2VwYWNrYWdle2F4aW9tfQpc
YmVnaW57ZG9jdW1lbnR9Clx0aXRsZXtjbC1ub3RhbmdsZSB2MC4xIC0gYSBM
aXRlcmF0ZSBQcm9ncmFtIENvZGUgRXh0cmFjdG9yIGZvciBBTlNJIENvbW1v
biBMaXNwfSAKXGF1dGhvcntDbGlmZm9yZCBZYXBwfQpcbWFrZXRpdGxlClxi
ZWdpbnthYnN0cmFjdH0KICBOT1dFQiBpcyB0aGUgY2xhc3NpYyBsYW5ndWFn
ZSBhZ25vc3RpYyB0b29sIHVzZWQgZm9yIGxpdGVyYXRlIHByb2dyYW1taW5n
CiAgaW4gdGhlIHN0eWxlIG9mIEtudXRoJ3Mgb3JpZ2luYWwgV0VCLiAgVGhp
cyB0b29sIGltcGxlbWVudHMgYSBtZXRob2QgaW4KICBsaXNwIGZvciBleHRy
YWN0aW5nIHRoZSBzb3VyY2UgY29kZSBmcm9tIGxpdGVyYXRlIGRvY3VtZW50
cy4KXGVuZHthYnN0cmFjdH0KXGVqZWN0Clx0YWJsZW9mY29udGVudHMKXGVq
ZWN0Cgpcc2VjdGlvbntDb3B5cmlnaHQgYW5kIExpY2Vuc2V9CgogVGhpcyBw
cm9ncmFtIGlzIGF2YWlsYWJsZSB1bmRlciB0aGUgTW9kaWZpZWQgQlNEIGxp
Y2Vuc2UuICBUaGUgd29yZGluZwogb2YgdGhlIGZpbGUgd2FzIGNoYW5nZWQg
c2xpZ2h0bHksIGFzIHRoZXJlIGlzIG5vIG9yZ2FuaXphdGlvbiBhc3NvY2lh
dGVkCiB3aXRoIHRoZSBjcmVhdGlvbiBvZiB0aGlzIGZpbGUsIGJ1dCBpZiB0
aGVyZSBpcyBhbnkgcXVlc3Rpb24gdGhlIGxpY2Vuc2UKIGlzIGludGVuZGVk
IHRvIGJlIE1vZGlmaWVkIEJTRC4KCjw8Y29weXJpZ2h0Pj49Cjs7IENvcHly
aWdodCAoYykgMjAwNywgQ2xpZmZvcmQgWWFwcAo7OyBBbGwgcmlnaHRzIHJl
c2VydmVkLgoKQAoKPDxsaWNlbnNlPj49Cjs7IFJlZGlzdHJpYnV0aW9uIGFu
ZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0
aG91dAo7OyBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQg
dGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlCjs7IG1ldDoKOzsK
OzsgICAgLSBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCBy
ZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAo7OyAgICAgIG5vdGljZSwgdGhp
cyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xh
aW1lci4KOzsKOzsgICAgLSBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZv
cm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAo7OyAgICAg
IG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xs
b3dpbmcgZGlzY2xhaW1lciBpbgo7OyAgICAgIHRoZSBkb2N1bWVudGF0aW9u
IGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUKOzsg
ICAgICBkaXN0cmlidXRpb24uCjs7Cjs7ICAgIC0gVGhlIG5hbWVzIG9mIHRo
ZSBjb250cmlidXRvcnMgbWF5IG5vdCBiZSB1c2VkIHRvIGVuZG9yc2Ugb3Ig
cHJvbW90ZQo7OyAgICAgIHByb2R1Y3RzIGRlcml2ZWQgZnJvbSB0aGlzIHNv
ZnR3YXJlIHdpdGhvdXQgc3BlY2lmaWMgcHJpb3Igd3JpdHRlbgo7OyAgICAg
IHBlcm1pc3Npb24uCjs7Cjs7VEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBC
WSBUSEUgQ09QWVJJR0hUIEhPTERFUlMgQU5EIENPTlRSSUJVVE9SUyAiQVMK
OztJUyIgQU5EIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywg
SU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQKOztUTywgVEhFIElNUExJRUQg
V0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9S
IEEKOztQQVJUSUNVTEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuIElOIE5P
IEVWRU5UIFNIQUxMIFRIRSBDT1BZUklHSFQgT1dORVIKOztPUiBDT05UUklC
VVRPUlMgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5D
SURFTlRBTCwgU1BFQ0lBTCwKOztFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJ
QUwgREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sCjs7
UFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUyBPUiBTRVJWSUNFUzsg
TE9TUyBPRiBVU0UsIERBVEEsIE9SCjs7UFJPRklUUzsgT1IgQlVTSU5FU1Mg
SU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9S
WSBPRgo7O0xJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNU
IExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HCjs7TkVHTElHRU5DRSBP
UiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWSBPVVQgT0YgVEhFIFVT
RSBPRiBUSElTCjs7U09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUg
UE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCgpAIAoKXGVqZWN0ClxzZWN0
aW9ue0ludHJvZHVjdGlvbiAtIE5PV0VCIGFuZCBMaXRlcmF0ZSBQcm9ncmFt
bWluZ30KClRoZSBjb25jZXB0IG9mIExpdGVyYXRlIFByb2dyYW1taW5nIHRy
YWNlcyBiYWNrIHRvIERvbmFsZCBLbnV0aCwgdGhlIGF1dGhvcgpvZiB0aGUg
VGVYIHR5cGVzZXR0aW5nIHN5c3RlbSBhbmQgQ1dFQi4gIFRoZSBmdW5kYW1l
bnRhbCBpZGVhIG9mIGxpdGVyYXRlIApwcm9ncmFtbWluZyBpcyB0byBkZXZl
bG9wIHRoZSBjb2RlIGFuZCBkb2N1bWVudGF0aW9uIGFzIG9uZSBpbnRlZ3Jh
dGVkIHdob2xlIAotIHJhdGhlciB0aGFuIGhhdmluZyBzb3VyY2UgY29kZSBp
biBvbmUgZmlsZSBhbmQgZG9jdW1lbnRhdGlvbiBpbiBhbm90aGVyIHRoZSAK
dHdvIGFyZSB3b3ZlbiB0b2dldGhlci4gIFRoaXMgcGxhY2VzIHRoZSBlbXBo
YXNpcyBvbiBpZGVhcyBtb3JlIHRoYW4gY29kZSwgYW5kIAppcyBpbnRlbmRl
ZCB0byBlbmNvdXJhZ2UgdGhlIGNyZWF0aW9uIG9mIHByb2dyYW1zIHRoYXQg
d2lsbCBiZSB1bmRlcnN0YW5kYWJsZSAKYW5kIHVzYWJsZSBhcyBsb25nIGFz
IHRoZSBpZGVhcyBiZWhpbmQgdGhlIGRlc2lnbiBpdHNlbGYgYXJlIHZhbGlk
LgoKT25lIG9mIHRoZSBwcmFjdGljYWwgY29uc2VxdWVuY2VzIG9mIHRoaXMg
aWRlYSBpcyB0aGF0IGluIG9yZGVyIGZvciB0aGUgY29kZSAKaW4gYSBsaXRl
cmF0ZSBkb2N1bWVudCB0byBiZSBsb2FkZWQgaW50byBhIG1hY2hpbmUsIGl0
IG11c3QgYmUgZXh0cmFjdGVkIGZyb20gCnRoZSBkb2N1bWVudC4gVGhpcyBp
cyBmdXJ0aGVyIGNvbXBsaWNhdGVkIGJ5IHRoZSBlbXBoYXNpcyBvZiBsaXRl
cmF0ZSAKcHJvZ3JhbW1pbmcgb24gaWRlYXMgcmF0aGVyIHRoYW4gY29kZSBk
aWN0YXRpbmcgdGhlIG9yZGVyIG9mIGEgcHJvZ3JhbW1lcidzIAp3b3JrLiAg
V0VCIGRvY3VtZW50cyB0aHVzIGFyZSBub3Qgb25seSBpbnRlcndvdmVuIHRl
eHQgYW5kIHNvdXJjZSBjb2RlLCBidXQgCmhhdmUgY2h1bmtzIG9mIGNvZGUg
ZGVmaW5lZCBhdCBhcmJpdHJhcnkgcG9pbnRzIGluIHRoZSBkb2N1bWVudC4g
IFRoZXJlIGlzIAp1c3VhbGx5IGEgcm9vdCBjaHVuayB3aGljaCBwbGFjZXMg
dGhlIGluZGl2aWR1YWwgcGllY2VzIGluIHRoZSBjb3JyZWN0IG9yZGVyLCAK
YnV0IGVhY2ggcGllY2UgbWF5IGluIHR1cm4gcmVmZXJlbmNlIG90aGVyIHBp
ZWNlcyBhbmQgYWxsIG9mIHRoZW0gbXVzdCBiZSAKZXZlbnR1YWxseSBwdXQg
aW4gdGhlIGNvcnJlY3Qgc2VxdWVuY2UgdG8gYWxsb3cgdGhlIG1hY2hpbmUg
dG8gcmVhZCB0aGVtLgoKSW4gTk9XRUIsIHRoZSBzcGVjaWZpYyBjb21tYW5k
IHRoYXQgZG9lcyB0aGlzIGpvYiBpcyBjYWxsZWQgbm90YW5nbGUuICBUaGVy
ZSAKYXJlIG90aGVyIGNvbW1hbmRzIHRoYXQgcHJvY2VzcyB0aGUgZG9jdW1l
bnQgaW50byB2YXJpb3VzIG91dHB1dCBmb3JtcywgYnV0IApmcm9tIHRoZSBz
dGFuZHBvaW50IG9mIHRoZSBtYWNoaW5lIHVuZGVyc3RhbmRpbmcgdGhlIGNv
ZGUgbm90YW5nbGUgaXMgdGhlIAptb3N0IGNyaXRpY2FsLgoKSGVyZSwgd2Ug
d2lsbCBpbXBsZW1lbnQgYSB3YXkgaW4gbGlzcCB0byBsb2FkIGEgcGFtcGhs
ZXQgZmlsZSwgQXhpb20ncyBmb3JtIApvZiBsaXRlcmF0ZSBwcm9ncmFtbWlu
ZyBkb2N1bWVudCwgYW5kIGV4dHJhY3QgdGhlIGNvZGUgZnJvbSBpdC4KCgpc
c2VjdGlvbntUaGUgVG9wIExldmVsIEZpbGUgU3RydWN0dXJlfQoKPDwqPj49
Cjw8Y29weXJpZ2h0Pj4KPDxsaWNlbnNlPj4KPDxkZWxpbWl0ZXJzPj4KPDxo
YXNodGFibGU+Pgo8PGNodW5rY2xhc3M+Pgo8PGJhc2ljLWNodW5rLW9wZXJh
dGlvbnM+Pgo8PHJlYWRpbi1jaHVuaz4+Cjw8dG9wbGV2ZWwtY2h1bmstc2Nh
bm5pbmc+Pgo8PHJlZmVyZW5jZS1jaHVuay1zY2FubmluZz4+Cjw8bG9hZC1m
aWxlPj4KPDx3cml0ZS1maWxlPj4KPDxub3RhbmdsZT4+CkAgCgpcc2VjdGlv
bntJbml0aWFsIERlZmluaXRpb25zfQoKVGhlIG1vc3QgaW1wb3J0YW50IHBp
ZWNlcyBvZiBpbmZvcm1hdGlvbiBuZWVkZWQgd2hlbiB1bnRhbmdsaW5nIGEg
ZmlsZSBhcmUgCnRoZSBkZWxpbWl0aW5nIHN0cmluZ3MgdXNlZCB0byBpZGVu
dGlmeSBwYXJ0cyBvZiBhIGNodW5rLiAgQXMgYSBydWxlLCBjaHVua3MgCmNv
bnNpc3Qgb2YgYSBuYW1lLCBhIGJvZHksIGFuZCBhbiBlbmQgb2YgY2h1bmsg
Y2hhcmFjdGVyIHdoaWNoIHNpZ25pZmllcyB0aGUgCmVuZCBvZiB0aGUgY29k
ZS4gIEhvd2V2ZXIsIGJlY2F1c2UgY2h1bmtzIG1heSBhbHNvIHJlZmVyZW5j
ZSBvdGhlciBjaHVua3MsIAp0aGVyZSBhbHNvIG5lZWQgdG8gYmUgY2h1bmsg
cmVmZXJlbmNlIGZsYWdzIHRoYXQgY2FuIGJlIHNlZW4gaW5zaWRlIHRoZSBi
b2R5IAppdHNlbGYuICBBeGlvbSBjb252ZW50aW9ucyBhcmUgdXNlZCBoZXJl
IGZvciB0aGUgZGVmYXVsdHMsIGJ1dCBvdGhlcnMgYXJlIApjZXJ0YWlubHkg
cG9zc2libGUgYW5kIGNhbiBiZSBhY2hpZXZlZCBieSBzaW1wbHkgcmUtZGVm
aW5pbmcgdGhlc2UgdmFyaWFibGVzLiAgCk5vdGUsIGhvd2V2ZXIsIHRoYXQg
Y29sbGlzaW9ucyBiZXR3ZWVuIGRlbGltaXRlcnMgYXQgdGhlIHNhbWUgbGV2
ZWxzIChzYXksIAp0aGUgZW5kaW5nIGNoYXJhY3RlcnMgZm9yIHRoZSBuYW1l
IG9mIHRoZSBjaHVuayBhbmQgdGhlIGVuZCBvZiBjaHVuayBib2R5IApjaGFy
YWN0ZXIsIG9yIHRoZSB0d28gZGVsaW1pdGVycyB1c2VkIGluc2lkZSB0aGUg
Ym9keSBmb3IgcmVmZXJlbmNlcykgd2lsbCAKYWxtb3N0IGNlcnRhaW5seSBw
cmV2ZW50IGNvcnJlY3QgcGFyc2luZyBvZiB0aGUgZmlsZS4KCjw8ZGVsaW1p
dGVycz4+PQooZGVmdmFyIHN0YXJ0Y2hhcnMgIjw8IikKKGRlZnZhciBlbmRj
aGFycyAiPj49IikKKGRlZnZhciBlbmRjaHVua2NoYXJzICJAIikKKGRlZnZh
ciByZWZzdGFydGNoYXJzICI8PCIpCihkZWZ2YXIgcmVmZW5kY2hhcnMgIj4+
IikgCgpACgpXaGVuIHJlYWRpbmcgaW4gY2h1bmtzIGFuZCBzdG9yaW5nIHRo
ZW0sIGEgaGFzaCB0YWJsZSBpcyB1c2VkLiAgV2UgaW5pdGlhbGl6ZSAKdGhh
dCB0YWJsZSBhdCB0aGUgYmVnaW5uaW5nLCBzaW5jZSBpdCBpcyB1c2VkIHRo
cm91Z2hvdXQgdGhlIHByb2dyYW0uICBBbiAKaW1wb3J0YW50IGZlYXR1cmUg
dG8gbm90ZSBoZXJlIGlzIHRoYXQgdGhpcyBoYXNoIHRhYmxlIHVzZXMgdGhl
IGBgZXF1YWwnJyAKZnVuY3Rpb24gZm9yIGVxdWFsaXR5IHRlc3RpbmcsIHdo
aWNoIGlzIG5lY2Vzc2FyeSBmb3IgdGhlIGhhc2ggdGFibGUgdG8gd29yayAK
d2l0aCBzdHJpbmcga2V5cy4gIENodW5rIG5hbWVzIGFyZSBzdHJpbmdzLCBh
bmQgYSBkZWZhdWx0IGhhc2ggdGFibGUgCmNvbmZpZ3VyYXRpb24gaW4gTGlz
cCB3aWxsIG5vdCBhY2NlcHQgdGhlbS4KCjw8aGFzaHRhYmxlPj49CihkZWZw
YXJhbWV0ZXIgKmNodW5rLWhhc2gtdGFibGUqIChtYWtlLWhhc2gtdGFibGUg
OnRlc3QgJ2VxdWFsKSkKCkAKClxzZWN0aW9ue0NodW5rIHN0cnVjdHVyZSBp
biBDTE9TfQoKQ0xPUyAodGhlIENvbW1vbiBMaXNwIE9iamVjdCBTeXN0ZW0p
IHByb3ZpZGVzIGV4Y2VsbGVudCB0b29scyBmb3IgZGF0YSAKc3RydWN0dXJl
IGNyZWF0aW9uIGFuZCBtYW5pcHVsYXRpb24uICBXZSB3aWxsIG1ha2Ugb25s
eSBtaW5vciB1c2Ugb2YgaXQgaGVyZSwgCnRvIGRlZmluZSBhIGRhdGEgc3Ry
dWN0dXJlIHRoYXQgd2lsbCBob2xkIGNodW5rcyBhcyB0aGV5IGFyZSByZWFk
IGluIGFuZCAKcGFyc2VkLiAgKEl0IGlzIHBlcmhhcHMgbm90IHN0cmljdGx5
IG5lY2Vzc2FyeSB0byBpbmNsdWRlIHRoZSBjaHVuayBuYW1lIGluIAp0aGUg
ZGF0YSBzdHJ1Y3R1cmUsIHNpbmNlIHRoZSBoYXNoIGNvZGUgaXMgYWxzbyB0
aGUgY2h1bmsgbmFtZS4pIFRoaXMgCmRlZmluaXRpb24gd2lsbCBhbHNvIGF1
dG9tYXRpY2FsbHkgcHJvZHVjZSBmdW5jdGlvbnMgdG8gbWFuaXB1bGF0ZSB0
aGUgCnN0cnVjdHVyZXMgd2l0aGluIHRoZSBjbGFzcywgYWx0aG91Z2ggd2Ug
d2lsbCBkZWZpbmUgY29udmVuaWVuY2UgZnVuY3Rpb25zIApmb3IgdGhvc2Ug
b3BlcmF0aW9ucyBsYXRlci4gVGhlIGNvbnRlbnRzIG9mIHRoZSBjaHVuayBh
cmUgaW5pdGlhbGl6ZWQgdG8gdGhlIAplbXB0eSBzdHJpbmcuCgo8PGNodW5r
Y2xhc3M+Pj0KKGRlZmNsYXNzIGNodW5rICgpCiAgKChjaHVuay1uYW1lCiAg
ICA6aW5pdGFyZyA6Y2h1bmstbmFtZQogICAgOmluaXRmb3JtIChlcnJvciAi
TXVzdCBzdXBwbHkgYSBjaHVuayBuYW1lLiIpCiAgICA6cmVhZGVyIGNodW5r
LW5hbWUKICAgIDpkb2N1bWVudGF0aW9uICJOYW1lIG9mIGNodW5rLiIpCiAg
IChjaHVuay1jb250ZW50cwogICAgOmluaXRhcmcgOmNodW5rLWNvbnRlbnRz
CiAgICA6aW5pdGZvcm0gIiIKICAgIDphY2Nlc3NvciBjaHVuay1jb250ZW50
cwogICAgOmRvY3VtZW50YXRpb24gIlRleHQgb2YgY2h1bmsgLSBtYXkgaW5j
bHVkZSByZWZlcmVuY2VzIHRvIG90aGVyIGNodW5rcyIpKSkKCkAKClxzZWN0
aW9ue0Jhc2ljIENodW5rIE9wZXJhdGlvbnN9CgpUaGVyZSBhcmUgdGhyZWUg
dGhpbmdzIHdlIHdpbGwgbm9ybWFsbHkgbmVlZCB0byBkbyB3aXRoIGNodW5r
czogIG1ha2UgbmV3IApvbmVzLCByZWFkIHRoZSBjb250ZW50IG9mIGFscmVh
ZHkgZXhpc3RpbmcgY2h1bmtzLCBhbmQgYWRkIGRhdGEgdG8gYWxyZWFkeSAK
ZXhpc3RpbmcgY2h1bmtzLiAgQ2h1bmsgYnVpbGRpbmcgZG9lcyBub3Qgbm9y
bWFsbHkgbmVlZCB0byByZW1vdmUgY29udGVudCAtIAptb3JlIHN1YnRsZSBt
YW5pcHVsYXRpb24gb2YgY29udGVudCBpcyBuZWVkZWQgZm9yIGhhbmRsaW5n
IHJlZmVyZW5jZXMsIGJ1dCAKdGhhdCBpcyBkZWFsdCB3aXRoIGVsc2V3aGVy
ZS4KClxzdWJzZWN0aW9ue05ldyBDaHVua3N9CgpBIG5ldyBjaHVuayBpcyBh
bHdheXMgYXNzdW1lZCB0byBiZSBlbXB0eSwgc28gd2Ugc2ltcGx5IHRha2Ug
YSBuYW1lIGFyZ3VtZW50IAphbmQgaW5pdGlhbGl6ZSB0aGUgY2h1bmssIG1l
cmdpbmcgaXQgaW50byB0aGUgY2VudHJhbCBoYXNoIHRhYmxlIGFzIHdlIApj
cmVhdGUgaXQuICBUaGlzIG1lYW5zIHRoZSBjaHVuayBgYGxpdmVzJycgaW4g
dGhlIGhhc2ggdGFibGUgYW5kIGRvZXMgbm90IApleGlzdCBhcyBhIHZhcmlh
YmxlIGluIHRoZSBMaXNwIGVudmlyb25tZW50LCBzbyB5b3Ugd2lsbCBuZXZl
ciB0eXBlIApgYGNodW5rMScnIGFuZCBzZWUgdGhlIGNvbnRlbnRzIG9mIHRo
ZSBjaHVuay4KCjw8bmV3LWNodW5rPj49CihkZWZ1biBtYWtlLW5ldy1jaHVu
ayAoY3Vyci1jaHVuay1uYW1lKQogIChzZXRmIChnZXRoYXNoIGN1cnItY2h1
bmstbmFtZSAqY2h1bmstaGFzaC10YWJsZSopIAoJKG1ha2UtaW5zdGFuY2Ug
J2NodW5rIDpjaHVuay1uYW1lIGN1cnItY2h1bmstbmFtZSkpKQoKQAoKXHN1
YnNlY3Rpb257UmVhZGluZyBDaHVuayBDb250ZW50c30KCkJlY2F1c2UgdGhl
IGNodW5rcyBhcmUgY29udGFpbmVkIGluIHRoZSBoYXNoIHRhYmxlLCB3ZSBu
ZWVkIGEgd2F5IHRvIHN1cHBseSAKdGhlIG5hbWUgb2YgYSBjaHVuayBhbmQg
cmV0cmlldmUgdGhlIGNvbnRlbnRzLiAgTm90ZSB0aGF0IHRoaXMgcmV0dXJu
cyAKdGhlIGxpdGVyYWwgc3RyaW5nIG9mIHRoZSBjaHVuayBhbmQgZG9lcyBu
b3Qgc3dhcCBpbiBkZWZpbml0aW9ucyBmb3IgCnJlZmVyZW5jZXMuCgo8PGdl
dC1jaHVuay1jb250ZW50cz4+PQooZGVmdW4gZ2V0LWNodW5rLWNvbnRlbnRz
IChjdXJyLWNodW5rLW5hbWUpCiAgKGNodW5rLWNvbnRlbnRzIChnZXRoYXNo
IGN1cnItY2h1bmstbmFtZSAqY2h1bmstaGFzaC10YWJsZSopKSkKCkAKClxz
dWJzZWN0aW9ue0FkZGluZyBOZXcgQ29udGVudCB0byBDaHVua3N9CgpBcyB0
aGUgZmlsZSBpcyByZWFkIGluIGxpbmUgYnkgbGluZSwgd2UgZG9uJ3QgZGVm
aW5lIGNodW5rIGNvbnRlbnRzIGluIGEgCnNpbmdsZSBgYGd1bHAnJyBidXQg
b25lIGxpbmUgYXQgYSB0aW1lLiAgU28gd2UgbmVlZCBhIGNvbnZlbmllbnQg
d2F5IHRvIGFkZCAKbmV3IGxpbmVzIHRvIHRoZSBjb250ZW50cyBvZiBhIGNo
dW5rIGtub3dpbmcgb25seSB0aGUgbmFtZSBvZiB0aGUgY2h1bmsgYW5kIAp0
aGUgY29udGVudHMgdG8gYWRkLiAgVGhlIG9ubHkgbWlub3IgZGlmZmljdWx0
eSBoZXJlIGlzIHRoYXQgcmVhZC1saW5lIGluIApMaXNwIGRvZXNuJ3QgcHJl
c2VydmUgbmV3bGluZXMgYXMgcGFydCBvZiB0aGUgc3RyaW5nLCB3aGljaCBp
cyBub3JtYWxseSB0aGUgCmRlc2lyZWQgYmVoYXZpb3IgYnV0IG5vdCB3aGF0
IGlzIG5lZWRlZCBoZXJlLiAgU28gdGhlcmUgYXJlIHR3byBjYXNlcyAtIGlu
IAp0aGUgaW5pdGlhbCBjYXNlIHdoZW4gdGhlIGNvbnRlbnRzIGFyZSBlbXB0
eSB3ZSBzaW1wbHkgYXNzaWduIHRoZSBzdHJpbmcgYXMKdGhlIG5ldyBjb250
ZW50cy4gIElmIHRoZSBjb250ZW50cyBhcmUgbm90IGVtcHR5IHdlIG5lZWQg
dG8gY3JlYXRlIGEgbmV3IApzdHJpbmcgY29udGFpbmluZyB0aGUgb3JpZ2lu
YWwgY29udGVudHMsIGEgbmV3bGluZSBjaGFyYWN0ZXIsIGFuZCB0aGUgbmV3
IApsaW5lLgoKPDxhZGQtY2h1bmstY29udGVudHM+Pj0KKGRlZnVuIGFkZC10
by1jaHVuay1jb250ZW50cyAoY3Vyci1jaHVuay1uYW1lIG5ldy1jb250ZW50
cykKICAobGV0ICgoc3RhcnRpbmctY2h1bmstY29udGVudHMgKGdldC1jaHVu
ay1jb250ZW50cyBjdXJyLWNodW5rLW5hbWUpKSkKICAgIChpZiAoc3RyaW5n
LWVxdWFsIHN0YXJ0aW5nLWNodW5rLWNvbnRlbnRzICIiKQoJKHNldGYgKGNo
dW5rLWNvbnRlbnRzIChnZXRoYXNoIGN1cnItY2h1bmstbmFtZSAqY2h1bmst
aGFzaC10YWJsZSopKQoJICAgICAgbmV3LWNvbnRlbnRzKQoJKHNldGYgKGNo
dW5rLWNvbnRlbnRzIChnZXRoYXNoIGN1cnItY2h1bmstbmFtZSAqY2h1bmst
aGFzaC10YWJsZSopKQoJICAgICAgKGNvbmNhdGVuYXRlICdzdHJpbmcgc3Rh
cnRpbmctY2h1bmstY29udGVudHMgKHN0cmluZyAjXE5ld2xpbmUpCgkJCSAg
IG5ldy1jb250ZW50cykpKSkpCgpACgpcc3Vic2VjdGlvbntBbGwgQmFzaWMg
RnVuY3Rpb25zfQoKVGhlc2UgdGhyZWUgb3BlcmF0aW9ucyBhcmUgdGhlIGNv
cmUgb2Ygd2hhdCBpcyBuZWVkZWQuICBXZSB3aWxsIGFkZCBvbmUgbW9yZSAK
ZnVuY3Rpb24gZm9yIGNvbnZlbmllbmNlIGR1cmluZyBkZWJ1Z2dpbmcsIHdo
aWNoIHByaW50cyBvdXQgYWxsIGNodW5rcyBpbiAKdGhlIGhhc2ggdGFibGUu
Cgo8PHZpZXctYWxsPj49CihkZWZ1biB2aWV3LWFsbC1jaHVua3MgKCkKICAo
bWFwaGFzaCAjJyhsYW1iZGEgKGsgdikgKGZvcm1hdCB0ICJ+YSA9PiB+YX4l
IiBrIHYpKSAqY2h1bmstaGFzaC10YWJsZSopKQoKQAoKPDxiYXNpYy1jaHVu
ay1vcGVyYXRpb25zPj49Cjw8bmV3LWNodW5rPj4KPDxnZXQtY2h1bmstY29u
dGVudHM+Pgo8PGFkZC1jaHVuay1jb250ZW50cz4+Cjw8dmlldy1hbGw+PgpA
Cgpcc2VjdGlvbntMb2NhdGluZyBDaHVua3MgYW5kIENodW5rIFJlZmVyZW5j
ZXN9CgpUaGUgbW9zdCBkaWZmaWN1bHQgcGFydCBvZiBkZWFsaW5nIHdpdGgg
bGl0ZXJhdGUgcHJvZ3JhbW1pbmcgZmlsZXMgaXMgdGhlIAppbnRlcndvdmVu
IHN0cnVjdHVyZSB0aGF0IGNvZGUgY2h1bmsgcmVmZXJlbmNlcyBjYW4gcHJv
ZHVjZS4gIFR3byBsZXZlbHMgYXJlIApuZWVkZWQgLSBpZGVudGlmeSBhbmQg
c3RvcmUgZGVmaW5lZCBjaHVua3MsIGFuZCBzcG90IHJlZmVyZW5jZXMgdG8g
Y2h1bmtzIAppbnNpZGUgb2YgY2h1bmsgYm9kaWVzLgoKXHN1YnNlY3Rpb257
SWRlbnRpZnlpbmcgYW5kIFN0b3JpbmcgQ2h1bmtzIC0gVG9wIExldmVsfQoK
QW4gYXNzdW1wdGlvbiBtYWRlIGlzIHRoYXQgYWxsIGNodW5rIGRlZmluaXRp
b25zIGFyZSBgYHRvcCBsZXZlbCcnIC0gdGhhdCBpcywgCm5vIGNodW5rIGlz
IGRlZmluZWQgaW4gdGhlIGJvZHkgb2YgYW5vdGhlciBjaHVuay4gIEdyYW50
aW5nIHRoYXQgYXNzdW1wdGlvbiwgCml0IGlzIHBvc3NpYmxlIHRvIGNoZWNr
IGVhY2ggc3RyaW5nIGFzIGl0IGlzIHJlYWQgdG8gc2VlIGlmIGl0IGlzIHRo
ZSBzdGFydCAKb2YgYSBuZXcgY2h1bmsuICBUaGlzIGlzIGRvbmUgdXNpbmcg
TGlzcCBzdHJpbmcgc2VhcmNoaW5nIGFuZCBzcGFjZSB0cmltbWluZy4KQW5v
dGhlciBhc3N1bXB0aW9uIGlzIHRoYXQgdGhlIGJlZ2lubmluZyBpZGVudGlm
aWVyIGZvciBhIGNodW5rIGlzIG9uIGl0cyAKb3duIGxpbmUgLSB0aGlzIGlz
IHByb2JhYmx5IG5vdCBzdHJpY3RseSBuZWNlc3NhcnkgYnV0IHNob3VsZCBi
ZSBzdGFuZGFyZCAKY29udmVudGlvbi4KCjw8dG9wbGV2ZWwtY2h1bmstc2Nh
bm5pbmc+Pj0KKGRlZnVuIGNoZWNrLWZvci10b3BsZXZlbC1jaHVuayAoaW5w
dXRzdHJpbmcgZmlsZW5hbWUpCiAgIChsZXQgKCh0ZXN0c3RyaW5nIChzdHJp
bmctdHJpbSAiICIgaW5wdXRzdHJpbmcpKSkKICAgICAoaWYgKD4gKGxlbmd0
aCB0ZXN0c3RyaW5nKSAzKQogICAgIChpZiAoYW5kIChzdHJpbmctZXF1YWwg
c3RhcnRjaGFycyB0ZXN0c3RyaW5nIDplbmQyIChsZW5ndGggc3RhcnRjaGFy
cykpCgkgICAgICAoc3RyaW5nLWVxdWFsIGVuZGNoYXJzIHRlc3RzdHJpbmcg
CgkJCSAgICAgOnN0YXJ0MiAoLSAobGVuZ3RoIHRlc3RzdHJpbmcpIChsZW5n
dGggZW5kY2hhcnMpKQoJCQkgICAgIDplbmQyIChsZW5ndGggdGVzdHN0cmlu
ZykpKQogICAgICAgICAobGV0ICgobmV3LWNodW5rLW5hbWUgKHN1YnNlcSB0
ZXN0c3RyaW5nIChsZW5ndGggc3RhcnRjaGFycykKCQkJCSAgICgtIChsZW5n
dGggdGVzdHN0cmluZykgKGxlbmd0aCBlbmRjaGFycykpKSkpCgkgICAobWFr
ZS1uZXctY2h1bmsgbmV3LWNodW5rLW5hbWUpCgkgICAocmVhZC1pbi1jaHVu
ayBuZXctY2h1bmstbmFtZSBmaWxlbmFtZSkKCSAgIHQpCgkgKSkpKQoKQAoK
XHN1YnNlY3Rpb257SWRlbnRpZnlpbmcgYW5kIEV4cGFuZGluZyBDaHVuayBS
ZWZlcmVuY2VzfQoKVGhlIGFib3ZlIHdpbGwgc2VydmUgZm9yIHRvcGxldmVs
IGNodW5rIGlkZW50aWZpY2F0aW9uLCBidXQgdGhlIHRhc2sgb2YgCmlkZW50
aWZ5aW5nIHJlZmVyZW5jZXMgdG8gY2h1bmtzIGluIHRoZSBib2R5IG9mIGEg
Y2h1bmsgaXMgYSBzbGlnaHRseSAKZGlmZmVyZW50IHRhc2suICBBIGxpbmUg
d2lsbCBjb250YWluIG9ubHkgb25lIGNodW5rIGRlZmluaXRpb24sIGJ1dCB0
aGUgCmNvbnRlbnRzIG9mIGEgY2h1bmsgYm9keSBtYXkgY29udGFpbiBtYW55
IGNodW5rIHJlZmVyZW5jZXMuICBBIGZ1cnRoZXIgCmNvbXBsaWNhdGlvbiBp
cyB0aGF0IGV2ZW4gd2hlbiB0aG9zZSByZWZlcmVuY2VzIGFyZSBleHBhbmRl
ZCwgdGhleSBtYXkgCmluIHR1cm4gY29udGFpbiBvdGhlciByZWZlcmVuY2Vz
LiAgVG8gaGFuZGxlIHRoaXMgYSByZWN1cnNpdmUgZnVuY3Rpb24KaWRlbnRp
ZmllcyAgdGhlIGZpcnN0IGNodW5rLCBleHBhbmRzIGl0LCBidWlsZHMgYSBu
ZXcgc3RyaW5nIGJhc2VkIG9uIAp0aGUgY29tYmluYXRpb24gIG9mIG9sZCBh
bmQgbmV3LCBpbnNlcnRzIGluIHBsYWNlIG9mIHRoZSByZWZlcmVuY2UsIAph
bmQgY2FsbHMgaXRzZWxmIG9uIHRoZSBuZXcgcmVzdWx0LiBJbiB0aGUgZW5k
LCB0aGUgcmV0dXJuZWQgCnN0cmluZyB3aWxsIGhhdmUgYWxsIHJlZmVyZW5j
ZXMgZXhwYW5kZWQgYW5kIGNvbnN0aXR1dGUgdGhlIGZpbmFsIGZvcm0gb2Yg
CnRoZSBjaHVuayBhcyBpdCBpcyB0byBiZSBzZW50IHRvIHRoZSBvdXRwdXQg
ZmlsZS4KCkhvd2V2ZXIsIHRoZXJlIGFyZSBzZXZlcmFsIHRoaW5ncyB0byBi
ZSB3YXJ5IG9mIHdoZW4gZG9pbmcgdGhpcyBzY2FuLiAgVGhlCmZpcnN0IGlz
IGEgYmFkIGNodW5rLCBvciBhIHJlZmVyZW5jZSBjaHVuayB3aGljaCBoYXMg
bm8gZGVmaW5pdGlvbi4gIFRoaXMKaXMgaGFuZGxlZCBieSB0aHJvd2luZyBh
biBlcnJvciBpZiBzdWNoIGEgY2h1bmsgaXMgZW5jb3VudGVyZWQuICBXZSB3
aWxsCmFsc28gZGVmaW5lIGhlcmUgdGhlIGNvcmUgcm91dGluZSBmb3IgbWVy
Z2luZyB0aGUgc3RyaW5nczoKCjw8Y29yZS1yZWY+Pj0KKHByb2duCiAgKGxl
dCAoKG1pZGRsZXN0cmluZyAoc3Vic2VxIGlucHV0c3RyaW5nIAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAoKyBwb3MxIChsZW5ndGggcmVmc3Rh
cnRjaGFycykpIAoJCQkgICAgICBwb3MyKSkpCiAgICAoaWYgKGdldGhhc2gg
bWlkZGxlc3RyaW5nICpjaHVuay1oYXNoLXRhYmxlKikKCShwcm9nbgoJICAo
c2V0ZiBpbnB1dHN0cmluZyAKCQkoY29uY2F0ZW5hdGUgJ3N0cmluZwoJCQkg
ICAgIChzdWJzZXEgaW5wdXRzdHJpbmcgMCBwb3MxKQoJCQkgICAgIChnZXQt
Y2h1bmstY29udGVudHMgbWlkZGxlc3RyaW5nKQoJCQkgICAgIChzdWJzZXEg
aW5wdXRzdHJpbmcgCgkJCSAgICAgICAgICAgICAoKyBwb3MyIChsZW5ndGgg
cmVmZW5kY2hhcnMpKSkpKQoJICAoY2hlY2stZm9yLXJlZmVyZW5jZWQtY2h1
bmsgaW5wdXRzdHJpbmcgcG9zMSkpCgkoZXJyb3IgICJ+UyB3YXMgbm90IGZv
dW5kIGluIGhhc2ggdGFibGUuIiBtaWRkbGVzdHJpbmcpKSkpKSkKQAoKVGhl
IG5leHQgY2hlY2sgaXMgZm9yIGEgY2FzZSB3aGVyZSB0aGUgZGVsaW1pdGlu
ZyBjaGFyYWN0ZXJzIGFyZSBicm9rZW4KdXAgb3ZlciB0d28gbGluZXMuICBX
ZSB3aWxsIG5vdCByZWdhcmQgdGhpcyBhcyBhIGxlZ2FsIGNodW5rIG5hbWUs
IGFzCml0IGlzIGEgcmF0aGVyIHVubGlrZWx5IGNoYXJhY3RlciBjb21iaW5h
dGlvbiBmb3IgYSBsYWJlbCwgYW5kIGl0IGFsc28KYWxsb3dzIHRoZSBhdm9p
ZGFuY2Ugb2YgYWNjaWRlbnRhbCBjaHVuayBuYW1lIG1hdGNoaW5nIHdoZW4g
aXQgaXMgbm90CmludGVuZGVkIChvbmUgb2YgdGhlIGNodW5rcyBpbiB0aGlz
IHBhbXBobGV0LCBmb3IgZXhhbXBsZSwgd291bGQgdHJpZ2dlcgpzdWNoIGFu
IGVycm9yLikgIElmIHN1Y2ggYSBjb25kaXRpb24gaXMgZm91bmQsIHRoZSBz
Y2FuIHNob3VsZCBiZSByZXN1bWVkCmJleW9uZCB0aGUgbmV3bGluZSBjaGFy
YWN0ZXIuCgo8PGNoZWNrLWZvci1uZXdsaW5lPj49CihpZiAoc2VhcmNoIChz
dHJpbmcgI1xOZXdsaW5lKSBpbnB1dHN0cmluZyA6c3RhcnQyIHBvczEgCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6ZW5k
MiBwb3MyKQogIChjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVuayBpbnB1dHN0
cmluZyAKICAJKCsoc2VhcmNoIChzdHJpbmcgI1xOZXdsaW5lKSBpbnB1dHN0
cmluZyA6c3RhcnQyIHBvczEKCQkJCQkJIDplbmQyIHBvczIpIDEpICkKICA8
PGNvcmUtcmVmPj4KQAoKV2l0aCB0aG9zZSB0d28gY2hlY2tzIGluIHBsYWNl
LCB3ZSBub3cgZGVmaW5lIHRoZSB0b3AgbGV2ZWwgY29udHJvbApmb3IgcG9z
aXRpb25pbmcgdGhlIHNlYXJjaCBjb21tYW5kLiAgVG8gYXZvaWQgY29uZnVz
aW9uIGFuZCB1bm5lZWRlZApzY2FubmluZywgdGhlIGNvbW1hbmQgdGFrZXMg
YSBzdGFydGluZyBwb3NpdGlvbiBhcyBhbiBhcmd1bWVudC4gIFRoaXMKYWxs
b3dzIHN1YnNlcXVlbnQgcmVjdXJzaXZlIGNhbGxzIHRvIGRpY3RhdGUgdGhl
aXIgc3RhcnRpbmcgcG9zaXRpb24sCmFuZCB0aGUgaW5pdGlhbCBjYWxsIHNp
bXBseSBzcGVjaWZpZXMgemVybyBhcyB0aGUgYmVnaW5uaW5nLiAgQXQgdGhp
cyBsZXZlbAp3ZSBhbHNvIGhhdmUgdGhlIGV4aXQgY29uZGl0aW9uIC0gaWYg
b25lIG9yIG1vcmUgb2YgcG9zMSBhbmQgcG9zMiBhcmUKbmlsLCB0aGF0IG1l
YW5zIHRoaXMgcGFydGljdWxhciBzdHJpbmcgaXMgY29tcGxldGUgYW5kIGNh
biBiZSByZXR1cm5lZC4KCjw8cmVmZXJlbmNlLWNodW5rLXNjYW5uaW5nPj49
CihkZWZ1biBjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVuayAoaW5wdXRzdHJp
bmcgc3RhcnRwb3MpCiAgIChsZXQgKChwb3MxIChzZWFyY2ggcmVmc3RhcnRj
aGFycyBpbnB1dHN0cmluZyA6c3RhcnQyIHN0YXJ0cG9zKSkpCiAgICAgKGxl
dCAoKHBvczIgKGlmIHBvczEgKHNlYXJjaCByZWZlbmRjaGFycyBpbnB1dHN0
cmluZyA6c3RhcnQyIHBvczEpKSkpCiAgICAgICAoaWYgKGFuZCBwb3MxIHBv
czIpCgkgICAocHJvZ24KCSAgIDw8Y2hlY2stZm9yLW5ld2xpbmU+PgoJICAg
aW5wdXRzdHJpbmcpKSkpCgpACgpcc2VjdGlvbntSZWFkaW5nIGluIENodW5r
c30KCk9uY2Ugd2UgaGF2ZSBpZGVudGlmaWVkIGEgY2h1bmsgYXQgdGhlIHRv
cCBsZXZlbCwgd2UgbXVzdCByZWFkIGl0IGluLiBJbiB0aGUgCnRvcGxldmVs
IGZ1bmN0aW9uIHRoYXQgam9iIGlzIHBhc3NlZCBvZmYgdGhhdCBqb2IgdG8g
YSBmdW5jdGlvbiBjYWxsZWQgCnJlYWQtaW4tY2h1bmsuICByZWFkLWluLWNo
dW5rIGlzIHRoZSBmdW5jdGlvbiB0aGF0IHB1dHMgYWRkaXRpb25hbCBsaW5l
cyBpbnRvIAp0aGUgY2h1bmsgY29udGVudHMgc2xvdCB1bnRpbCB0aGUgZW5k
LW9mLWNodW5rLWJvZHkgY2hhcmFjdGVyIGlzIHNwb3R0ZWQuICAKSXQgYWxz
byB1c2VzIHJlY3Vyc2lvbiAtIGlmIHRoZSBsaW5lIGl0IHJlYWRzIGlzbid0
IHRoZSBlbmQtb2YtYm9keSBtYXJrZXIsIAppdCBhcHBlbmRzIHRoYXQgbGlu
ZSB0byB0aGUgY29udGVudHMgYW5kIGNhbGxzIGl0c2VsZiB0byBjaGVjayB0
aGUgbmV4dCAKbGluZS4gIEl0IGFsc28gd2lsbCBhdm9pZCBhbiBlbmQtb2Yt
Ym9keSBtYXJrZXIgd2l0aCBhIGRvdWJsZS1xdW90ZSBpbiBmcm9udApvZiBp
dCwgdG8gYWxsb3cgdGhlIHByZXNlbmNlIG9mIHRoYXQgY2hhcmFjdGVyIGlu
IGNlcnRhaW4gdXNlcy4KCjw8cmVhZGluLWNodW5rPj49CihkZWZ1biByZWFk
LWluLWNodW5rIChjdXJyLWNodW5rLW5hbWUgZmlsZW5hbWUpCiAgKGxldCAo
KG5leHRsaW5lIChyZWFkLWxpbmUgZmlsZW5hbWUgbmlsKSkpCiAgICAoaWYg
KG9yIChub3QgKHNlYXJjaCBlbmRjaHVua2NoYXJzIG5leHRsaW5lKSkgCiAg
ICAgICAgICAgIChzZWFyY2ggKGNvbmNhdGVuYXRlICdzdHJpbmcgKHN0cmlu
ZyAjXCIpIGVuZGNodW5rY2hhcnMpCgkgICAgICAgICAgICAgbmV4dGxpbmUp
KSAKCShwcm9nbgoJICAoYWRkLXRvLWNodW5rLWNvbnRlbnRzIGN1cnItY2h1
bmstbmFtZSBuZXh0bGluZSkKCSAgKHJlYWQtaW4tY2h1bmsgY3Vyci1jaHVu
ay1uYW1lIGZpbGVuYW1lKSkpKSkKCkAKClxzZWN0aW9ue0ZpbGUgT3BlcmF0
aW9uc30KCk5vdyB0aGF0IHdlIGtub3cgaG93IHRvIGhhbmRsZSBjaHVua3Ms
IHdlIG9ubHkgbmVlZCB0byBhcHBseSB0aGF0IGtub3dsZWRnZSAKdG8gc29t
ZSBwYXJ0aWN1bGFyIGZpbGUuICBGb3IgdGhpcywgd2UgdXNlIGEgbG9vcCBt
YWNybyByYXRoZXIgdGhhbiByZWN1cnNpb24uCgo8PGxvYWQtZmlsZT4+PQoo
ZGVmdW4gbG9hZC1wYW1waGxldC1maWxlIChmaWxlbmFtZSkKICAobGV0ICgo
aW4gKG9wZW4gZmlsZW5hbWUgOmlmLWRvZXMtbm90LWV4aXN0IG5pbCkpKQog
ICAgKHdoZW4gaW4KICAgICAgKGxvb3AgZm9yIGxpbmUgPSAocmVhZC1saW5l
IGluIG5pbCkKCSAgICB3aGlsZSBsaW5lIGRvIChjaGVjay1mb3ItdG9wbGV2
ZWwtY2h1bmsgbGluZSBpbikpCiAgICAgIChjbG9zZSBpbikpKSkKCkAKCldl
IGFsc28gbmVlZCB0byBiZSBhYm91dCB0byBvdXRwdXQgdG8gYSBmaWxlLiBU
aGUgemVybyBpbiB0aGUgd3JpdGUtc3RyaW5nIApjb21tYW5kIHNpbXBseSB0
ZWxscyB0aGUgc2Nhbm5lciB0byBzdGFydCBhdCB0aGUgYmVnaW5uaW5nIG9m
IHRoZSBmaWxlLiAgQXMKaXQgaXMgY3VycmVudGx5IGNvbmZpZ3VyZWQsIHRo
ZSBvdXRwdXQgZmlsZSBpcyBhbHdheXMgb3ZlcndyaXR0ZW4uCgo8PHdyaXRl
LWZpbGU+Pj0KKGRlZnVuIHdyaXRlLW91dHB1dC1maWxlIChmaWxlbmFtZSBj
aHVua25hbWUpCiAgKGxldCAoKG91dHB1dHN0cmVhbSAob3BlbiBmaWxlbmFt
ZSA6ZGlyZWN0aW9uIDpvdXRwdXQgOmlmLWV4aXN0cyA6c3VwZXJzZWRlKSkp
CiAgICAod3JpdGUtc3RyaW5nIChjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVu
ayAKCQkgICAoZ2V0LWNodW5rLWNvbnRlbnRzIGNodW5rbmFtZSkgMCkgb3V0
cHV0c3RyZWFtKQogICAgKGNsb3NlIG91dHB1dHN0cmVhbSkpKQoKQAoKXHNl
Y3Rpb257UHVsbGluZyBJdCBUb2dldGhlciAtIFRoZSBub3RhbmdsZSBDb21t
YW5kfQoKVGhlIGZpbmFsLCB0b3AgbGV2ZWwgY29udHJvbCBjb21tYW5kIGlz
IG5hbWVkIG5vdGFuZ2xlIHRvIGNvbmZvcm0gdG8gdGhlIApOT1dFQiBjb252
ZW50aW9uLiAgVGhpcyBjb21tYW5kIGFjY2VwdHMgYW4gaW5wdXQgZmlsZSwg
b3V0cHV0IGZpbGUsIGFuZCAKb3B0aW9uYWxseSB0aGUgbmFtZSBvZiB0aGUg
Y2h1bmsgYXQgd2hpY2ggdG8gc3RhcnQgZXh0cmFjdGluZyBjb250ZW50cy4g
IApUaGUgZGVmYXVsdCBjb252ZW50aW9uIG9mIEF4aW9tIGlzIHRvIHVzZSBh
biBhc3RlcmlzayBhcyB0aGUgcm9vdCBub2RlLCBidXQgCnRoaXMgaXMgbm90
IHVuaXZlcnNhbGx5IHRydWUgYW5kIGl0IGlzIHNvbWV0aW1lcyBkZXNpcmFi
bGUgdG8gb3V0cHV0IGNvZGUgCmZyb20gb25lIHBhbXBobGV0IGludG8gbXVs
dGlwbGUgdGFyZ2V0IGZpbGVzLCBzdGFydGluZyBhdCBtdWx0aXBsZSByb290
cy4gIApJbiB0aGF0IGNhc2UsIHRoZSBjaHVuayBuYW1lIGlzIHBhc3NlZCB0
byBub3RhcmdldCBhcyB3ZWxsLiAgRm9yIGV4YW1wbGU6CgpcYmVnaW57cXVv
dGV9Cihub3RhbmdsZSBgYGJvb3QucGFtcGhsZXQnJyBgYGJvb3QubGlzcCcn
IGBgUkxpc3AnJykKXGVuZHtxdW90ZX0KClxub2luZGVudCB3b3VsZCBleHRy
YWN0IGFsbCBjb2RlIHJlZmVyZW5jZWQgYnkgdGhlIFJMaXNwIGNodW5rLCB3
aGVyZWFzCgpcYmVnaW57cXVvdGV9Cihub3RhbmdsZSBgYGJvb3QucGFtcGhs
ZXQnJyBgYGJvb3QuYm9vdCcnKQpcZW5ke3F1b3RlfQoKXG5vaW5kZW50IHdv
dWxkIGV4dHJhY3QgYWxsIGNvZGUgcmVmZXJlbmNlZCBieSB0aGUgXHZlcmJA
JycqJydAIG5vZGUuCgpUaGUgbm90YW5nbGUgY29tbWFuZCB3aWxsIGFsd2F5
cyBjbGVhciB0aGUgaGFzaCB0YWJsZSBiZWZvcmUgYW5kIGFmdGVyCnVzZSwg
dG8gZW5zdXJlIG5vIGFjY2lkZW50YWwgY29sbGlzaW9ucyBhbmQgYXZvaWQg
dW5uZWNlc3NhcnkgbWVtb3J5CnVzYWdlLgoKPDxub3RhbmdsZT4+PQooZGVm
dW4gbm90YW5nbGUgKGZpbGVpbm5hbWUgZmlsZW91dG5hbWUgJm9wdGlvbmFs
IChjaHVua25hbWUgIioiKSkKICAoY2xyaGFzaCAqY2h1bmstaGFzaC10YWJs
ZSopCiAgKGxvYWQtcGFtcGhsZXQtZmlsZSBmaWxlaW5uYW1lKQogICh3cml0
ZS1vdXRwdXQtZmlsZSBmaWxlb3V0bmFtZSBjaHVua25hbWUpCiAgKGNscmhh
c2ggKmNodW5rLWhhc2gtdGFibGUqKSkKQAoKXGVuZHtkb2N1bWVudH0K

--0-279212549-1171612038=:61325

OzsgQ29weXJpZ2h0IChjKSAyMDA3LCBDbGlmZm9yZCBZYXBwCjs7IEFsbCBy
aWdodHMgcmVzZXJ2ZWQuCgo7OyBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGlu
IHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKOzsg
bW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhl
IGZvbGxvd2luZyBjb25kaXRpb25zIGFyZQo7OyBtZXQ6Cjs7Cjs7ICAgIC0g
UmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRo
ZSBhYm92ZSBjb3B5cmlnaHQKOzsgICAgICBub3RpY2UsIHRoaXMgbGlzdCBv
ZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCjs7
Cjs7ICAgIC0gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg
cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKOzsgICAgICBub3RpY2Us
IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRp
c2NsYWltZXIgaW4KOzsgICAgICB0aGUgZG9jdW1lbnRhdGlvbiBhbmQvb3Ig
b3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlCjs7ICAgICAgZGlz
dHJpYnV0aW9uLgo7Owo7OyAgICAtIFRoZSBuYW1lcyBvZiB0aGUgY29udHJp
YnV0b3JzIG1heSBub3QgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUK
OzsgICAgICBwcm9kdWN0cyBkZXJpdmVkIGZyb20gdGhpcyBzb2Z0d2FyZSB3
aXRob3V0IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4KOzsgICAgICBwZXJtaXNz
aW9uLgo7Owo7O1RISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENP
UFlSSUdIVCBIT0xERVJTIEFORCBDT05UUklCVVRPUlMgIkFTCjs7SVMiIEFO
RCBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElO
RywgQlVUIE5PVCBMSU1JVEVECjs7VE8sIFRIRSBJTVBMSUVEIFdBUlJBTlRJ
RVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBCjs7UEFS
VElDVUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiBJTiBOTyBFVkVOVCBT
SEFMTCBUSEUgQ09QWVJJR0hUIE9XTkVSCjs7T1IgQ09OVFJJQlVUT1JTIEJF
IExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUws
IFNQRUNJQUwsCjs7RVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMIERBTUFH
RVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLAo7O1BST0NVUkVN
RU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0Yg
VVNFLCBEQVRBLCBPUgo7O1BST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQ
VElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YKOztM
SUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJ
VFksIE9SIFRPUlQgKElOQ0xVRElORwo7O05FR0xJR0VOQ0UgT1IgT1RIRVJX
SVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YgVEhJ
Uwo7O1NPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklM
SVRZIE9GIFNVQ0ggREFNQUdFLgoKKGRlZnZhciBzdGFydGNoYXJzICI8PCIp
CihkZWZ2YXIgZW5kY2hhcnMgIj4+PSIpCihkZWZ2YXIgZW5kY2h1bmtjaGFy
cyAiQCIpCihkZWZ2YXIgcmVmc3RhcnRjaGFycyAiPDwiKQooZGVmdmFyIHJl
ZmVuZGNoYXJzICI+PiIpIAoKKGRlZnBhcmFtZXRlciAqY2h1bmstaGFzaC10
YWJsZSogKG1ha2UtaGFzaC10YWJsZSA6dGVzdCAnZXF1YWwpKQoKKGRlZmNs
YXNzIGNodW5rICgpCiAgKChjaHVuay1uYW1lCiAgICA6aW5pdGFyZyA6Y2h1
bmstbmFtZQogICAgOmluaXRmb3JtIChlcnJvciAiTXVzdCBzdXBwbHkgYSBj
aHVuayBuYW1lLiIpCiAgICA6cmVhZGVyIGNodW5rLW5hbWUKICAgIDpkb2N1
bWVudGF0aW9uICJOYW1lIG9mIGNodW5rLiIpCiAgIChjaHVuay1jb250ZW50
cwogICAgOmluaXRhcmcgOmNodW5rLWNvbnRlbnRzCiAgICA6aW5pdGZvcm0g
IiIKICAgIDphY2Nlc3NvciBjaHVuay1jb250ZW50cwogICAgOmRvY3VtZW50
YXRpb24gIlRleHQgb2YgY2h1bmsgLSBtYXkgaW5jbHVkZSByZWZlcmVuY2Vz
IHRvIG90aGVyIGNodW5rcyIpKSkKCihkZWZ1biBtYWtlLW5ldy1jaHVuayAo
Y3Vyci1jaHVuay1uYW1lKQogIChzZXRmIChnZXRoYXNoIGN1cnItY2h1bmst
bmFtZSAqY2h1bmstaGFzaC10YWJsZSopIAoJKG1ha2UtaW5zdGFuY2UgJ2No
dW5rIDpjaHVuay1uYW1lIGN1cnItY2h1bmstbmFtZSkpKQoKKGRlZnVuIGdl
dC1jaHVuay1jb250ZW50cyAoY3Vyci1jaHVuay1uYW1lKQogIChjaHVuay1j
b250ZW50cyAoZ2V0aGFzaCBjdXJyLWNodW5rLW5hbWUgKmNodW5rLWhhc2gt
dGFibGUqKSkpCgooZGVmdW4gYWRkLXRvLWNodW5rLWNvbnRlbnRzIChjdXJy
LWNodW5rLW5hbWUgbmV3LWNvbnRlbnRzKQogIChsZXQgKChzdGFydGluZy1j
aHVuay1jb250ZW50cyAoZ2V0LWNodW5rLWNvbnRlbnRzIGN1cnItY2h1bmst
bmFtZSkpKQogICAgKGlmIChzdHJpbmctZXF1YWwgc3RhcnRpbmctY2h1bmst
Y29udGVudHMgIiIpCgkoc2V0ZiAoY2h1bmstY29udGVudHMgKGdldGhhc2gg
Y3Vyci1jaHVuay1uYW1lICpjaHVuay1oYXNoLXRhYmxlKikpCgkgICAgICBu
ZXctY29udGVudHMpCgkoc2V0ZiAoY2h1bmstY29udGVudHMgKGdldGhhc2gg
Y3Vyci1jaHVuay1uYW1lICpjaHVuay1oYXNoLXRhYmxlKikpCgkgICAgICAo
Y29uY2F0ZW5hdGUgJ3N0cmluZyBzdGFydGluZy1jaHVuay1jb250ZW50cyAo
c3RyaW5nICNcTmV3bGluZSkKCQkJICAgbmV3LWNvbnRlbnRzKSkpKSkKCihk
ZWZ1biB2aWV3LWFsbC1jaHVua3MgKCkKICAobWFwaGFzaCAjJyhsYW1iZGEg
KGsgdikgKGZvcm1hdCB0ICJ+YSA9PiB+YX4lIiBrIHYpKSAqY2h1bmstaGFz
aC10YWJsZSopKQoKKGRlZnVuIHJlYWQtaW4tY2h1bmsgKGN1cnItY2h1bmst
bmFtZSBmaWxlbmFtZSkKICAobGV0ICgobmV4dGxpbmUgKHJlYWQtbGluZSBm
aWxlbmFtZSBuaWwpKSkKICAgIChpZiAob3IgKG5vdCAoc2VhcmNoIGVuZGNo
dW5rY2hhcnMgbmV4dGxpbmUpKSAKICAgICAgICAgICAgKHNlYXJjaCAoY29u
Y2F0ZW5hdGUgJ3N0cmluZyAoc3RyaW5nICNcIikgZW5kY2h1bmtjaGFycykK
CSAgICAgICAgICAgICBuZXh0bGluZSkpIAoJKHByb2duCgkgIChhZGQtdG8t
Y2h1bmstY29udGVudHMgY3Vyci1jaHVuay1uYW1lIG5leHRsaW5lKQoJICAo
cmVhZC1pbi1jaHVuayBjdXJyLWNodW5rLW5hbWUgZmlsZW5hbWUpKSkpKQoK
KGRlZnVuIGNoZWNrLWZvci10b3BsZXZlbC1jaHVuayAoaW5wdXRzdHJpbmcg
ZmlsZW5hbWUpCiAgIChsZXQgKCh0ZXN0c3RyaW5nIChzdHJpbmctdHJpbSAi
ICIgaW5wdXRzdHJpbmcpKSkKICAgICAoaWYgKD4gKGxlbmd0aCB0ZXN0c3Ry
aW5nKSAzKQogICAgIChpZiAoYW5kIChzdHJpbmctZXF1YWwgc3RhcnRjaGFy
cyB0ZXN0c3RyaW5nIDplbmQyIChsZW5ndGggc3RhcnRjaGFycykpCgkgICAg
ICAoc3RyaW5nLWVxdWFsIGVuZGNoYXJzIHRlc3RzdHJpbmcgCgkJCSAgICAg
OnN0YXJ0MiAoLSAobGVuZ3RoIHRlc3RzdHJpbmcpIChsZW5ndGggZW5kY2hh
cnMpKQoJCQkgICAgIDplbmQyIChsZW5ndGggdGVzdHN0cmluZykpKQogICAg
ICAgICAobGV0ICgobmV3LWNodW5rLW5hbWUgKHN1YnNlcSB0ZXN0c3RyaW5n
IChsZW5ndGggc3RhcnRjaGFycykKCQkJCSAgICgtIChsZW5ndGggdGVzdHN0
cmluZykgKGxlbmd0aCBlbmRjaGFycykpKSkpCgkgICAobWFrZS1uZXctY2h1
bmsgbmV3LWNodW5rLW5hbWUpCgkgICAocmVhZC1pbi1jaHVuayBuZXctY2h1
bmstbmFtZSBmaWxlbmFtZSkKCSAgIHQpCgkgKSkpKQoKKGRlZnVuIGNoZWNr
LWZvci1yZWZlcmVuY2VkLWNodW5rIChpbnB1dHN0cmluZyBzdGFydHBvcykK
ICAgKGxldCAoKHBvczEgKHNlYXJjaCByZWZzdGFydGNoYXJzIGlucHV0c3Ry
aW5nIDpzdGFydDIgc3RhcnRwb3MpKSkKICAgICAobGV0ICgocG9zMiAoaWYg
cG9zMSAoc2VhcmNoIHJlZmVuZGNoYXJzIGlucHV0c3RyaW5nIDpzdGFydDIg
cG9zMSkpKSkKICAgICAgIChpZiAoYW5kIHBvczEgcG9zMikKCSAgIChwcm9n
bgoJICAgKGlmIChzZWFyY2ggKHN0cmluZyAjXE5ld2xpbmUpIGlucHV0c3Ry
aW5nIDpzdGFydDIgcG9zMSAKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIDplbmQyIHBvczIpCiAgKGNoZWNrLWZvci1yZWZl
cmVuY2VkLWNodW5rIGlucHV0c3RyaW5nIAogIAkoKyhzZWFyY2ggKHN0cmlu
ZyAjXE5ld2xpbmUpIGlucHV0c3RyaW5nIDpzdGFydDIgcG9zMQoJCQkJCQkg
OmVuZDIgcG9zMikgMSkgKQogIChwcm9nbgogIChsZXQgKChtaWRkbGVzdHJp
bmcgKHN1YnNlcSBpbnB1dHN0cmluZyAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKCsgcG9zMSAobGVuZ3RoIHJlZnN0YXJ0Y2hhcnMpKSAKCQkJ
ICAgICAgcG9zMikpKQogICAgKGlmIChnZXRoYXNoIG1pZGRsZXN0cmluZyAq
Y2h1bmstaGFzaC10YWJsZSopCgkocHJvZ24KCSAgKHNldGYgaW5wdXRzdHJp
bmcgCgkJKGNvbmNhdGVuYXRlICdzdHJpbmcKCQkJICAgICAoc3Vic2VxIGlu
cHV0c3RyaW5nIDAgcG9zMSkKCQkJICAgICAoZ2V0LWNodW5rLWNvbnRlbnRz
IG1pZGRsZXN0cmluZykKCQkJICAgICAoc3Vic2VxIGlucHV0c3RyaW5nIAoJ
CQkgICAgICAgICAgICAgKCsgcG9zMiAobGVuZ3RoIHJlZmVuZGNoYXJzKSkp
KSkKCSAgKGNoZWNrLWZvci1yZWZlcmVuY2VkLWNodW5rIGlucHV0c3RyaW5n
IHBvczEpKQoJKGVycm9yICAiflMgd2FzIG5vdCBmb3VuZCBpbiBoYXNoIHRh
YmxlLiIgbWlkZGxlc3RyaW5nKSkpKSkpCgkgICBpbnB1dHN0cmluZykpKSkK
CihkZWZ1biBsb2FkLXBhbXBobGV0LWZpbGUgKGZpbGVuYW1lKQogIChsZXQg
KChpbiAob3BlbiBmaWxlbmFtZSA6aWYtZG9lcy1ub3QtZXhpc3QgbmlsKSkp
CiAgICAod2hlbiBpbgogICAgICAobG9vcCBmb3IgbGluZSA9IChyZWFkLWxp
bmUgaW4gbmlsKQoJICAgIHdoaWxlIGxpbmUgZG8gKGNoZWNrLWZvci10b3Bs
ZXZlbC1jaHVuayBsaW5lIGluKSkKICAgICAgKGNsb3NlIGluKSkpKQoKKGRl
ZnVuIHdyaXRlLW91dHB1dC1maWxlIChmaWxlbmFtZSBjaHVua25hbWUpCiAg
KGxldCAoKG91dHB1dHN0cmVhbSAob3BlbiBmaWxlbmFtZSA6ZGlyZWN0aW9u
IDpvdXRwdXQgOmlmLWV4aXN0cyA6c3VwZXJzZWRlKSkpCiAgICAod3JpdGUt
c3RyaW5nIChjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVuayAKCQkgICAoZ2V0
LWNodW5rLWNvbnRlbnRzIGNodW5rbmFtZSkgMCkgb3V0cHV0c3RyZWFtKQog
ICAgKGNsb3NlIG91dHB1dHN0cmVhbSkpKQoKKGRlZnVuIG5vdGFuZ2xlIChm
aWxlaW5uYW1lIGZpbGVvdXRuYW1lICZvcHRpb25hbCAoY2h1bmtuYW1lICIq
IikpCiAgKGNscmhhc2ggKmNodW5rLWhhc2gtdGFibGUqKQogIChsb2FkLXBh
bXBobGV0LWZpbGUgZmlsZWlubmFtZSkKICAod3JpdGUtb3V0cHV0LWZpbGUg
ZmlsZW91dG5hbWUgY2h1bmtuYW1lKQogIChjbHJoYXNoICpjaHVuay1oYXNo
LXRhYmxlKikp

\start
Date: Fri, 16 Feb 2007 16:04:28 +0600 (NOVT)
From: Andrey G. Grozin
To: Bill Page
Subject: Re: build-improvements without external noweb: is it supposed to work?
Cc: Gabriel Dos Reis

On Wed, 14 Feb 2007, Bill Page wrote:
> Quoting Andrey G. Grozin:
>>  ./../..//build/i686-pc-linux/bin/lisp -batch -eval \
>>                   '(progn (mapcar (function (lambda (x) (load x))) \
>>                           (quote ( "boothdr.o"  "exports.o"  "npextras.o"
>>  "stage0/ptyout.o"  "stage0/btincl2.o"  "stage0/btscan2.o"
>>  "stage0/typrops.o"  "stage0/btpile2.o"  "stage0/typars.o"
>>  "stage0/tytree1.o"))) \
>>                           (system::save-system "bootsys"))'
>>
>>  Error: The variable |
>> |  is unbound.
>>  Fast links are on: do (si::use-fast-links nil) for debugging
>>  Error signalled by PROGN.
>>  Broken at MAPCAR.  Type :H for Help.
Doing ./configure and make in a freshly checked-out tree with the latest 
Bill's patch, I get exactly the same error:

./../..//build/i686-pc-linux/bin/lisp -batch -eval \
                 '(progn (mapcar (function (lambda (x) (load x))) \
                         (quote ( "boothdr.o"  "exports.o"  "npextras.o" 
"stage0/ptyout.o"  "stage0/btincl2.o"  "stage0/btscan2.o" 
"stage0/typrops.o"  "stage0/btpile2.o"  "stage0/typars.o" 
"stage0/tytree1.o"))) \
                         (system::save-system "bootsys"))'

Error: The variable |
| is unbound.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by PROGN.
Broken at MAPCAR.  Type :H for Help.

Maybe, changes of this kind are needed in several places?

\start
Date: Fri, 16 Feb 2007 13:44:50 +0100 (CET)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: A first attempt at a notangle in Lisp

> I hesitate to say it's useful, but I have what appears to be a (more or
> less) working notangle command in lisp.  It successfully handles a
> couple test files, and although I haven't inspected the results it
> handled most of the contents of boot and interp without crashing. 
> Unfortunately it's performance is worse than abysmal.  

Your method of appending content to a chunk was quadratic.  Below
is a diff changing this to linear method, gives much better speed (at
least on "nag-e02.boot.pamphlet") but still much slower than Debian
notangle (0.48s sbcl, 0.028s system version).  AFAICS reading
pamphlets is still slow (takes 0.4s on "nag-e02.boot.pamphlet").


--- cl-notangle.lisp.pamphlet	2007-02-16 11:57:23.000000000 +0100
+++ cl-notangle.lisp.pamphlet	2007-02-16 13:03:47.000000000 +0100
@@ -365,13 +365,21 @@
 
 <<readin-chunk>>=
 (defun read-in-chunk (curr-chunk-name filename)
-  (let ((nextline (read-line filename nil)))
-    (if (or (not (search endchunkchars nextline)) 
-            (search (concatenate 'string (string #\") endchunkchars)
-	             nextline)) 
-	(progn
-	  (add-to-chunk-contents curr-chunk-name nextline)
-	  (read-in-chunk curr-chunk-name filename)))))
+  (let ((lines nil))
+     (loop for nextline = (read-line filename nil)
+            while (or (not (search endchunkchars nextline))
+                       (search (concatenate 'string (string #\") endchunkchars)
+                                nextline))
+            do
+                  (progn
+                     (push nextline lines)
+                     (push (string #\Newline) lines)))
+      (if lines
+         (progn
+            (pop lines)
+            (add-to-chunk-contents curr-chunk-name
+                            (apply #'concatenate 'string 
+                                 (reverse lines)))))))
 
 @
 


\start
Date: Fri, 16 Feb 2007 06:03:06 -0800 (PST)
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: A first attempt at a notangle in Lisp

--- Waldek Hebisch wrote:

> Your method of appending content to a chunk was quadratic.  Below
> is a diff changing this to linear method, gives much better speed (at
> least on "nag-e02.boot.pamphlet") but still much slower than Debian
> notangle (0.48s sbcl, 0.028s system version).  AFAICS reading
> pamphlets is still slow (takes 0.4s on "nag-e02.boot.pamphlet").

Thanks!  Wow, did that ever make a difference.  Where you running the
above after compiling cl-notangle.lisp or just loading it?  Running the
same comparison (I'm in SBCL 1.01, by the way) I've now got:

CL-USER> (time (load "./setup/runnotangle.lisp"))
Evaluation took:
  4.93 seconds of real time
  0.848053 seconds of user run time
  0.728046 seconds of system run time
  [Run times include 0.1 seconds GC run time.]
  0 calls to %EVAL
  0 page faults and
  12,686,456 bytes consed.
T
CL-USER> (load "./setup/cleardirs.lisp")
T
CL-USER> (time (load "./setup/runlispnotangle.lisp"))
Evaluation took:
  9.45 seconds of real time
  9.208575 seconds of user run time
  0.240015 seconds of system run time
  [Run times include 0.248 seconds GC run time.]
  0 calls to %EVAL
  0 page faults and
  175,565,168 bytes consed.

Which doesn't achieve Tim's goal of a faster notangle than notangle but
is usably quick.  Thanks Waldek!

I attached v0.2 with this patch applied.

CY

P.S. - I know the descriptive text in the file needs quite a lot of
improvement (for example I don't cite any sources at the moment) but
them's the breaks when it's 2am and you have to work tomorrow.  If
there is real interest in this as a tool for Axiom I'll try to spruce
it up some more.


 
____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
--0-631001030-1171634586=:41236

XGRvY3VtZW50Y2xhc3N7YXJ0aWNsZX0gClx1c2VwYWNrYWdle2F4aW9tfQpc
YmVnaW57ZG9jdW1lbnR9Clx0aXRsZXtjbC1ub3RhbmdsZSB2MC4yIC0gYSBM
aXRlcmF0ZSBQcm9ncmFtIENvZGUgRXh0cmFjdG9yIGZvciBBTlNJIENvbW1v
biBMaXNwfSAKXGF1dGhvcntDbGlmZm9yZCBZYXBwLCBXYWxkZWsgSGViaXNj
aH0KXG1ha2V0aXRsZQpcYmVnaW57YWJzdHJhY3R9CiAgTk9XRUIgaXMgdGhl
IGNsYXNzaWMgbGFuZ3VhZ2UgYWdub3N0aWMgdG9vbCB1c2VkIGZvciBsaXRl
cmF0ZSBwcm9ncmFtbWluZwogIGluIHRoZSBzdHlsZSBvZiBLbnV0aCdzIG9y
aWdpbmFsIFdFQi4gIFRoaXMgdG9vbCBpbXBsZW1lbnRzIGEgbWV0aG9kIGlu
CiAgbGlzcCBmb3IgZXh0cmFjdGluZyB0aGUgc291cmNlIGNvZGUgZnJvbSBs
aXRlcmF0ZSBkb2N1bWVudHMuClxlbmR7YWJzdHJhY3R9ClxlamVjdApcdGFi
bGVvZmNvbnRlbnRzClxlamVjdAoKXHNlY3Rpb257VXBkYXRlc30KClxub2lu
ZGVudCBcdmVyYkAoMi8xNS8wNylAIC0gSW5pdGlhbCB2MC4xIHJlbGVhc2Vk
Clxub2luZGVudCBcdmVyYkAoMi8xNi8wNylAIC0gV2FsdGVyIEhlYmlzY2gg
cHJvdmlkZXMgbGluZWFyIHRpbWUgcmVhZC1pbi1jaHVuawoKXHNlY3Rpb257
Q29weXJpZ2h0IGFuZCBMaWNlbnNlfQoKIFRoaXMgcHJvZ3JhbSBpcyBhdmFp
bGFibGUgdW5kZXIgdGhlIE1vZGlmaWVkIEJTRCBsaWNlbnNlLiAgVGhlIHdv
cmRpbmcKIG9mIHRoZSBmaWxlIHdhcyBjaGFuZ2VkIHNsaWdodGx5LCBhcyB0
aGVyZSBpcyBubyBvcmdhbml6YXRpb24gYXNzb2NpYXRlZAogd2l0aCB0aGUg
Y3JlYXRpb24gb2YgdGhpcyBmaWxlLCBidXQgaWYgdGhlcmUgaXMgYW55IHF1
ZXN0aW9uIHRoZSBsaWNlbnNlCiBpcyBpbnRlbmRlZCB0byBiZSBNb2RpZmll
ZCBCU0QuCgo8PGNvcHlyaWdodD4+PQo7OyBDb3B5cmlnaHQgKGMpIDIwMDcs
IENsaWZmb3JkIFlhcHAKOzsgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCkAKCjw8
bGljZW5zZT4+PQo7OyBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJj
ZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKOzsgbW9kaWZp
Y2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxv
d2luZyBjb25kaXRpb25zIGFyZQo7OyBtZXQ6Cjs7Cjs7ICAgIC0gUmVkaXN0
cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92
ZSBjb3B5cmlnaHQKOzsgICAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25k
aXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCjs7Cjs7ICAg
IC0gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9k
dWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKOzsgICAgICBub3RpY2UsIHRoaXMg
bGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt
ZXIgaW4KOzsgICAgICB0aGUgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIg
bWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlCjs7ICAgICAgZGlzdHJpYnV0
aW9uLgo7Owo7OyAgICAtIFRoZSBuYW1lcyBvZiB0aGUgY29udHJpYnV0b3Jz
IG1heSBub3QgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUKOzsgICAg
ICBwcm9kdWN0cyBkZXJpdmVkIGZyb20gdGhpcyBzb2Z0d2FyZSB3aXRob3V0
IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4KOzsgICAgICBwZXJtaXNzaW9uLgo7
Owo7O1RISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENPUFlSSUdI
VCBIT0xERVJTIEFORCBDT05UUklCVVRPUlMgIkFTCjs7SVMiIEFORCBBTlkg
RVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVU
IE5PVCBMSU1JVEVECjs7VE8sIFRIRSBJTVBMSUVEIFdBUlJBTlRJRVMgT0Yg
TUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBCjs7UEFSVElDVUxB
UiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiBJTiBOTyBFVkVOVCBTSEFMTCBU
SEUgQ09QWVJJR0hUIE9XTkVSCjs7T1IgQ09OVFJJQlVUT1JTIEJFIExJQUJM
RSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJ
QUwsCjs7RVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMgKElO
Q0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLAo7O1BST0NVUkVNRU5UIE9G
IFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBE
QVRBLCBPUgo7O1BST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikg
SE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YKOztMSUFCSUxJ
VFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJVFksIE9S
IFRPUlQgKElOQ0xVRElORwo7O05FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBB
UklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YgVEhJUwo7O1NP
RlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9G
IFNVQ0ggREFNQUdFLgoKQCAKClxlamVjdApcc2VjdGlvbntJbnRyb2R1Y3Rp
b24gLSBOT1dFQiBhbmQgTGl0ZXJhdGUgUHJvZ3JhbW1pbmd9CgpUaGUgY29u
Y2VwdCBvZiBMaXRlcmF0ZSBQcm9ncmFtbWluZyB0cmFjZXMgYmFjayB0byBE
b25hbGQgS251dGgsIHRoZSBhdXRob3IKb2YgdGhlIFRlWCB0eXBlc2V0dGlu
ZyBzeXN0ZW0gYW5kIENXRUIuICBUaGUgZnVuZGFtZW50YWwgaWRlYSBvZiBs
aXRlcmF0ZSAKcHJvZ3JhbW1pbmcgaXMgdG8gZGV2ZWxvcCB0aGUgY29kZSBh
bmQgZG9jdW1lbnRhdGlvbiBhcyBvbmUgaW50ZWdyYXRlZCB3aG9sZSAKLSBy
YXRoZXIgdGhhbiBoYXZpbmcgc291cmNlIGNvZGUgaW4gb25lIGZpbGUgYW5k
IGRvY3VtZW50YXRpb24gaW4gYW5vdGhlciB0aGUgCnR3byBhcmUgd292ZW4g
dG9nZXRoZXIuICBUaGlzIHBsYWNlcyB0aGUgZW1waGFzaXMgb24gaWRlYXMg
bW9yZSB0aGFuIGNvZGUsIGFuZCAKaXMgaW50ZW5kZWQgdG8gZW5jb3VyYWdl
IHRoZSBjcmVhdGlvbiBvZiBwcm9ncmFtcyB0aGF0IHdpbGwgYmUgdW5kZXJz
dGFuZGFibGUgCmFuZCB1c2FibGUgYXMgbG9uZyBhcyB0aGUgaWRlYXMgYmVo
aW5kIHRoZSBkZXNpZ24gaXRzZWxmIGFyZSB2YWxpZC4KCk9uZSBvZiB0aGUg
cHJhY3RpY2FsIGNvbnNlcXVlbmNlcyBvZiB0aGlzIGlkZWEgaXMgdGhhdCBp
biBvcmRlciBmb3IgdGhlIGNvZGUgCmluIGEgbGl0ZXJhdGUgZG9jdW1lbnQg
dG8gYmUgbG9hZGVkIGludG8gYSBtYWNoaW5lLCBpdCBtdXN0IGJlIGV4dHJh
Y3RlZCBmcm9tIAp0aGUgZG9jdW1lbnQuIFRoaXMgaXMgZnVydGhlciBjb21w
bGljYXRlZCBieSB0aGUgZW1waGFzaXMgb2YgbGl0ZXJhdGUgCnByb2dyYW1t
aW5nIG9uIGlkZWFzIHJhdGhlciB0aGFuIGNvZGUgZGljdGF0aW5nIHRoZSBv
cmRlciBvZiBhIHByb2dyYW1tZXIncyAKd29yay4gIFdFQiBkb2N1bWVudHMg
dGh1cyBhcmUgbm90IG9ubHkgaW50ZXJ3b3ZlbiB0ZXh0IGFuZCBzb3VyY2Ug
Y29kZSwgYnV0IApoYXZlIGNodW5rcyBvZiBjb2RlIGRlZmluZWQgYXQgYXJi
aXRyYXJ5IHBvaW50cyBpbiB0aGUgZG9jdW1lbnQuICBUaGVyZSBpcyAKdXN1
YWxseSBhIHJvb3QgY2h1bmsgd2hpY2ggcGxhY2VzIHRoZSBpbmRpdmlkdWFs
IHBpZWNlcyBpbiB0aGUgY29ycmVjdCBvcmRlciwgCmJ1dCBlYWNoIHBpZWNl
IG1heSBpbiB0dXJuIHJlZmVyZW5jZSBvdGhlciBwaWVjZXMgYW5kIGFsbCBv
ZiB0aGVtIG11c3QgYmUgCmV2ZW50dWFsbHkgcHV0IGluIHRoZSBjb3JyZWN0
IHNlcXVlbmNlIHRvIGFsbG93IHRoZSBtYWNoaW5lIHRvIHJlYWQgdGhlbS4K
CkluIE5PV0VCLCB0aGUgc3BlY2lmaWMgY29tbWFuZCB0aGF0IGRvZXMgdGhp
cyBqb2IgaXMgY2FsbGVkIG5vdGFuZ2xlLiAgVGhlcmUgCmFyZSBvdGhlciBj
b21tYW5kcyB0aGF0IHByb2Nlc3MgdGhlIGRvY3VtZW50IGludG8gdmFyaW91
cyBvdXRwdXQgZm9ybXMsIGJ1dCAKZnJvbSB0aGUgc3RhbmRwb2ludCBvZiB0
aGUgbWFjaGluZSB1bmRlcnN0YW5kaW5nIHRoZSBjb2RlIG5vdGFuZ2xlIGlz
IHRoZSAKbW9zdCBjcml0aWNhbC4KCkhlcmUsIHdlIHdpbGwgaW1wbGVtZW50
IGEgd2F5IGluIGxpc3AgdG8gbG9hZCBhIHBhbXBobGV0IGZpbGUsIEF4aW9t
J3MgZm9ybSAKb2YgbGl0ZXJhdGUgcHJvZ3JhbW1pbmcgZG9jdW1lbnQsIGFu
ZCBleHRyYWN0IHRoZSBjb2RlIGZyb20gaXQuCgoKXHNlY3Rpb257VGhlIFRv
cCBMZXZlbCBGaWxlIFN0cnVjdHVyZX0KCjw8Kj4+PQo8PGNvcHlyaWdodD4+
Cjw8bGljZW5zZT4+Cjw8ZGVsaW1pdGVycz4+Cjw8aGFzaHRhYmxlPj4KPDxj
aHVua2NsYXNzPj4KPDxiYXNpYy1jaHVuay1vcGVyYXRpb25zPj4KPDxyZWFk
aW4tY2h1bms+Pgo8PHRvcGxldmVsLWNodW5rLXNjYW5uaW5nPj4KPDxyZWZl
cmVuY2UtY2h1bmstc2Nhbm5pbmc+Pgo8PGxvYWQtZmlsZT4+Cjw8d3JpdGUt
ZmlsZT4+Cjw8bm90YW5nbGU+PgpAIAoKXHNlY3Rpb257SW5pdGlhbCBEZWZp
bml0aW9uc30KClRoZSBtb3N0IGltcG9ydGFudCBwaWVjZXMgb2YgaW5mb3Jt
YXRpb24gbmVlZGVkIHdoZW4gdW50YW5nbGluZyBhIGZpbGUgYXJlIAp0aGUg
ZGVsaW1pdGluZyBzdHJpbmdzIHVzZWQgdG8gaWRlbnRpZnkgcGFydHMgb2Yg
YSBjaHVuay4gIEFzIGEgcnVsZSwgY2h1bmtzIApjb25zaXN0IG9mIGEgbmFt
ZSwgYSBib2R5LCBhbmQgYW4gZW5kIG9mIGNodW5rIGNoYXJhY3RlciB3aGlj
aCBzaWduaWZpZXMgdGhlIAplbmQgb2YgdGhlIGNvZGUuICBIb3dldmVyLCBi
ZWNhdXNlIGNodW5rcyBtYXkgYWxzbyByZWZlcmVuY2Ugb3RoZXIgY2h1bmtz
LCAKdGhlcmUgYWxzbyBuZWVkIHRvIGJlIGNodW5rIHJlZmVyZW5jZSBmbGFn
cyB0aGF0IGNhbiBiZSBzZWVuIGluc2lkZSB0aGUgYm9keSAKaXRzZWxmLiAg
QXhpb20gY29udmVudGlvbnMgYXJlIHVzZWQgaGVyZSBmb3IgdGhlIGRlZmF1
bHRzLCBidXQgb3RoZXJzIGFyZSAKY2VydGFpbmx5IHBvc3NpYmxlIGFuZCBj
YW4gYmUgYWNoaWV2ZWQgYnkgc2ltcGx5IHJlLWRlZmluaW5nIHRoZXNlIHZh
cmlhYmxlcy4gIApOb3RlLCBob3dldmVyLCB0aGF0IGNvbGxpc2lvbnMgYmV0
d2VlbiBkZWxpbWl0ZXJzIGF0IHRoZSBzYW1lIGxldmVscyAoc2F5LCAKdGhl
IGVuZGluZyBjaGFyYWN0ZXJzIGZvciB0aGUgbmFtZSBvZiB0aGUgY2h1bmsg
YW5kIHRoZSBlbmQgb2YgY2h1bmsgYm9keSAKY2hhcmFjdGVyLCBvciB0aGUg
dHdvIGRlbGltaXRlcnMgdXNlZCBpbnNpZGUgdGhlIGJvZHkgZm9yIHJlZmVy
ZW5jZXMpIHdpbGwgCmFsbW9zdCBjZXJ0YWlubHkgcHJldmVudCBjb3JyZWN0
IHBhcnNpbmcgb2YgdGhlIGZpbGUuCgo8PGRlbGltaXRlcnM+Pj0KKGRlZnZh
ciBzdGFydGNoYXJzICI8PCIpCihkZWZ2YXIgZW5kY2hhcnMgIj4+PSIpCihk
ZWZ2YXIgZW5kY2h1bmtjaGFycyAiQCIpCihkZWZ2YXIgcmVmc3RhcnRjaGFy
cyAiPDwiKQooZGVmdmFyIHJlZmVuZGNoYXJzICI+PiIpIAoKQAoKV2hlbiBy
ZWFkaW5nIGluIGNodW5rcyBhbmQgc3RvcmluZyB0aGVtLCBhIGhhc2ggdGFi
bGUgaXMgdXNlZC4gIFdlIGluaXRpYWxpemUgCnRoYXQgdGFibGUgYXQgdGhl
IGJlZ2lubmluZywgc2luY2UgaXQgaXMgdXNlZCB0aHJvdWdob3V0IHRoZSBw
cm9ncmFtLiAgQW4gCmltcG9ydGFudCBmZWF0dXJlIHRvIG5vdGUgaGVyZSBp
cyB0aGF0IHRoaXMgaGFzaCB0YWJsZSB1c2VzIHRoZSBgYGVxdWFsJycgCmZ1
bmN0aW9uIGZvciBlcXVhbGl0eSB0ZXN0aW5nLCB3aGljaCBpcyBuZWNlc3Nh
cnkgZm9yIHRoZSBoYXNoIHRhYmxlIHRvIHdvcmsgCndpdGggc3RyaW5nIGtl
eXMuICBDaHVuayBuYW1lcyBhcmUgc3RyaW5ncywgYW5kIGEgZGVmYXVsdCBo
YXNoIHRhYmxlIApjb25maWd1cmF0aW9uIGluIExpc3Agd2lsbCBub3QgYWNj
ZXB0IHRoZW0uCgo8PGhhc2h0YWJsZT4+PQooZGVmcGFyYW1ldGVyICpjaHVu
ay1oYXNoLXRhYmxlKiAobWFrZS1oYXNoLXRhYmxlIDp0ZXN0ICdlcXVhbCkp
CgpACgpcc2VjdGlvbntDaHVuayBzdHJ1Y3R1cmUgaW4gQ0xPU30KCkNMT1Mg
KHRoZSBDb21tb24gTGlzcCBPYmplY3QgU3lzdGVtKSBwcm92aWRlcyBleGNl
bGxlbnQgdG9vbHMgZm9yIGRhdGEgCnN0cnVjdHVyZSBjcmVhdGlvbiBhbmQg
bWFuaXB1bGF0aW9uLiAgV2Ugd2lsbCBtYWtlIG9ubHkgbWlub3IgdXNlIG9m
IGl0IGhlcmUsIAp0byBkZWZpbmUgYSBkYXRhIHN0cnVjdHVyZSB0aGF0IHdp
bGwgaG9sZCBjaHVua3MgYXMgdGhleSBhcmUgcmVhZCBpbiBhbmQgCnBhcnNl
ZC4gIChJdCBpcyBwZXJoYXBzIG5vdCBzdHJpY3RseSBuZWNlc3NhcnkgdG8g
aW5jbHVkZSB0aGUgY2h1bmsgbmFtZSBpbiAKdGhlIGRhdGEgc3RydWN0dXJl
LCBzaW5jZSB0aGUgaGFzaCBjb2RlIGlzIGFsc28gdGhlIGNodW5rIG5hbWUu
KSBUaGlzIApkZWZpbml0aW9uIHdpbGwgYWxzbyBhdXRvbWF0aWNhbGx5IHBy
b2R1Y2UgZnVuY3Rpb25zIHRvIG1hbmlwdWxhdGUgdGhlIApzdHJ1Y3R1cmVz
IHdpdGhpbiB0aGUgY2xhc3MsIGFsdGhvdWdoIHdlIHdpbGwgZGVmaW5lIGNv
bnZlbmllbmNlIGZ1bmN0aW9ucyAKZm9yIHRob3NlIG9wZXJhdGlvbnMgbGF0
ZXIuIFRoZSBjb250ZW50cyBvZiB0aGUgY2h1bmsgYXJlIGluaXRpYWxpemVk
IHRvIHRoZSAKZW1wdHkgc3RyaW5nLgoKPDxjaHVua2NsYXNzPj49CihkZWZj
bGFzcyBjaHVuayAoKQogICgoY2h1bmstbmFtZQogICAgOmluaXRhcmcgOmNo
dW5rLW5hbWUKICAgIDppbml0Zm9ybSAoZXJyb3IgIk11c3Qgc3VwcGx5IGEg
Y2h1bmsgbmFtZS4iKQogICAgOnJlYWRlciBjaHVuay1uYW1lCiAgICA6ZG9j
dW1lbnRhdGlvbiAiTmFtZSBvZiBjaHVuay4iKQogICAoY2h1bmstY29udGVu
dHMKICAgIDppbml0YXJnIDpjaHVuay1jb250ZW50cwogICAgOmluaXRmb3Jt
ICIiCiAgICA6YWNjZXNzb3IgY2h1bmstY29udGVudHMKICAgIDpkb2N1bWVu
dGF0aW9uICJUZXh0IG9mIGNodW5rIC0gbWF5IGluY2x1ZGUgcmVmZXJlbmNl
cyB0byBvdGhlciBjaHVua3MiKSkpCgpACgpcc2VjdGlvbntCYXNpYyBDaHVu
ayBPcGVyYXRpb25zfQoKVGhlcmUgYXJlIHRocmVlIHRoaW5ncyB3ZSB3aWxs
IG5vcm1hbGx5IG5lZWQgdG8gZG8gd2l0aCBjaHVua3M6ICBtYWtlIG5ldyAK
b25lcywgcmVhZCB0aGUgY29udGVudCBvZiBhbHJlYWR5IGV4aXN0aW5nIGNo
dW5rcywgYW5kIGFkZCBkYXRhIHRvIGFscmVhZHkgCmV4aXN0aW5nIGNodW5r
cy4gIENodW5rIGJ1aWxkaW5nIGRvZXMgbm90IG5vcm1hbGx5IG5lZWQgdG8g
cmVtb3ZlIGNvbnRlbnQgLSAKbW9yZSBzdWJ0bGUgbWFuaXB1bGF0aW9uIG9m
IGNvbnRlbnQgaXMgbmVlZGVkIGZvciBoYW5kbGluZyByZWZlcmVuY2VzLCBi
dXQgCnRoYXQgaXMgZGVhbHQgd2l0aCBlbHNld2hlcmUuCgpcc3Vic2VjdGlv
bntOZXcgQ2h1bmtzfQoKQSBuZXcgY2h1bmsgaXMgYWx3YXlzIGFzc3VtZWQg
dG8gYmUgZW1wdHksIHNvIHdlIHNpbXBseSB0YWtlIGEgbmFtZSBhcmd1bWVu
dCAKYW5kIGluaXRpYWxpemUgdGhlIGNodW5rLCBtZXJnaW5nIGl0IGludG8g
dGhlIGNlbnRyYWwgaGFzaCB0YWJsZSBhcyB3ZSAKY3JlYXRlIGl0LiAgVGhp
cyBtZWFucyB0aGUgY2h1bmsgYGBsaXZlcycnIGluIHRoZSBoYXNoIHRhYmxl
IGFuZCBkb2VzIG5vdCAKZXhpc3QgYXMgYSB2YXJpYWJsZSBpbiB0aGUgTGlz
cCBlbnZpcm9ubWVudCwgc28geW91IHdpbGwgbmV2ZXIgdHlwZSAKYGBjaHVu
azEnJyBhbmQgc2VlIHRoZSBjb250ZW50cyBvZiB0aGUgY2h1bmsuCgo8PG5l
dy1jaHVuaz4+PQooZGVmdW4gbWFrZS1uZXctY2h1bmsgKGN1cnItY2h1bmst
bmFtZSkKICAoc2V0ZiAoZ2V0aGFzaCBjdXJyLWNodW5rLW5hbWUgKmNodW5r
LWhhc2gtdGFibGUqKSAKCShtYWtlLWluc3RhbmNlICdjaHVuayA6Y2h1bmst
bmFtZSBjdXJyLWNodW5rLW5hbWUpKSkKCkAKClxzdWJzZWN0aW9ue1JlYWRp
bmcgQ2h1bmsgQ29udGVudHN9CgpCZWNhdXNlIHRoZSBjaHVua3MgYXJlIGNv
bnRhaW5lZCBpbiB0aGUgaGFzaCB0YWJsZSwgd2UgbmVlZCBhIHdheSB0byBz
dXBwbHkgCnRoZSBuYW1lIG9mIGEgY2h1bmsgYW5kIHJldHJpZXZlIHRoZSBj
b250ZW50cy4gIE5vdGUgdGhhdCB0aGlzIHJldHVybnMgCnRoZSBsaXRlcmFs
IHN0cmluZyBvZiB0aGUgY2h1bmsgYW5kIGRvZXMgbm90IHN3YXAgaW4gZGVm
aW5pdGlvbnMgZm9yIApyZWZlcmVuY2VzLgoKPDxnZXQtY2h1bmstY29udGVu
dHM+Pj0KKGRlZnVuIGdldC1jaHVuay1jb250ZW50cyAoY3Vyci1jaHVuay1u
YW1lKQogIChjaHVuay1jb250ZW50cyAoZ2V0aGFzaCBjdXJyLWNodW5rLW5h
bWUgKmNodW5rLWhhc2gtdGFibGUqKSkpCgpACgpcc3Vic2VjdGlvbntBZGRp
bmcgTmV3IENvbnRlbnQgdG8gQ2h1bmtzfQoKQXMgdGhlIGZpbGUgaXMgcmVh
ZCBpbiBsaW5lIGJ5IGxpbmUsIHdlIGRvbid0IGRlZmluZSBjaHVuayBjb250
ZW50cyBpbiBhIApzaW5nbGUgYGBndWxwJycgYnV0IG9uZSBsaW5lIGF0IGEg
dGltZS4gIFNvIHdlIG5lZWQgYSBjb252ZW5pZW50IHdheSB0byBhZGQgCm5l
dyBsaW5lcyB0byB0aGUgY29udGVudHMgb2YgYSBjaHVuayBrbm93aW5nIG9u
bHkgdGhlIG5hbWUgb2YgdGhlIGNodW5rIGFuZCAKdGhlIGNvbnRlbnRzIHRv
IGFkZC4gIFRoZSBvbmx5IG1pbm9yIGRpZmZpY3VsdHkgaGVyZSBpcyB0aGF0
IHJlYWQtbGluZSBpbiAKTGlzcCBkb2Vzbid0IHByZXNlcnZlIG5ld2xpbmVz
IGFzIHBhcnQgb2YgdGhlIHN0cmluZywgd2hpY2ggaXMgbm9ybWFsbHkgdGhl
IApkZXNpcmVkIGJlaGF2aW9yIGJ1dCBub3Qgd2hhdCBpcyBuZWVkZWQgaGVy
ZS4gIFNvIHRoZXJlIGFyZSB0d28gY2FzZXMgLSBpbiAKdGhlIGluaXRpYWwg
Y2FzZSB3aGVuIHRoZSBjb250ZW50cyBhcmUgZW1wdHkgd2Ugc2ltcGx5IGFz
c2lnbiB0aGUgc3RyaW5nIGFzCnRoZSBuZXcgY29udGVudHMuICBJZiB0aGUg
Y29udGVudHMgYXJlIG5vdCBlbXB0eSB3ZSBuZWVkIHRvIGNyZWF0ZSBhIG5l
dyAKc3RyaW5nIGNvbnRhaW5pbmcgdGhlIG9yaWdpbmFsIGNvbnRlbnRzLCBh
IG5ld2xpbmUgY2hhcmFjdGVyLCBhbmQgdGhlIG5ldyAKbGluZS4KCjw8YWRk
LWNodW5rLWNvbnRlbnRzPj49CihkZWZ1biBhZGQtdG8tY2h1bmstY29udGVu
dHMgKGN1cnItY2h1bmstbmFtZSBuZXctY29udGVudHMpCiAgKGxldCAoKHN0
YXJ0aW5nLWNodW5rLWNvbnRlbnRzIChnZXQtY2h1bmstY29udGVudHMgY3Vy
ci1jaHVuay1uYW1lKSkpCiAgICAoaWYgKHN0cmluZy1lcXVhbCBzdGFydGlu
Zy1jaHVuay1jb250ZW50cyAiIikKCShzZXRmIChjaHVuay1jb250ZW50cyAo
Z2V0aGFzaCBjdXJyLWNodW5rLW5hbWUgKmNodW5rLWhhc2gtdGFibGUqKSkK
CSAgICAgIG5ldy1jb250ZW50cykKCShzZXRmIChjaHVuay1jb250ZW50cyAo
Z2V0aGFzaCBjdXJyLWNodW5rLW5hbWUgKmNodW5rLWhhc2gtdGFibGUqKSkK
CSAgICAgIChjb25jYXRlbmF0ZSAnc3RyaW5nIHN0YXJ0aW5nLWNodW5rLWNv
bnRlbnRzIChzdHJpbmcgI1xOZXdsaW5lKQoJCQkgICBuZXctY29udGVudHMp
KSkpKQoKQAoKXHN1YnNlY3Rpb257QWxsIEJhc2ljIEZ1bmN0aW9uc30KClRo
ZXNlIHRocmVlIG9wZXJhdGlvbnMgYXJlIHRoZSBjb3JlIG9mIHdoYXQgaXMg
bmVlZGVkLiAgV2Ugd2lsbCBhZGQgb25lIG1vcmUgCmZ1bmN0aW9uIGZvciBj
b252ZW5pZW5jZSBkdXJpbmcgZGVidWdnaW5nLCB3aGljaCBwcmludHMgb3V0
IGFsbCBjaHVua3MgaW4gCnRoZSBoYXNoIHRhYmxlLgoKPDx2aWV3LWFsbD4+
PQooZGVmdW4gdmlldy1hbGwtY2h1bmtzICgpCiAgKG1hcGhhc2ggIycobGFt
YmRhIChrIHYpIChmb3JtYXQgdCAifmEgPT4gfmF+JSIgayB2KSkgKmNodW5r
LWhhc2gtdGFibGUqKSkKCkAKCjw8YmFzaWMtY2h1bmstb3BlcmF0aW9ucz4+
PQo8PG5ldy1jaHVuaz4+Cjw8Z2V0LWNodW5rLWNvbnRlbnRzPj4KPDxhZGQt
Y2h1bmstY29udGVudHM+Pgo8PHZpZXctYWxsPj4KQAoKXHNlY3Rpb257TG9j
YXRpbmcgQ2h1bmtzIGFuZCBDaHVuayBSZWZlcmVuY2VzfQoKVGhlIG1vc3Qg
ZGlmZmljdWx0IHBhcnQgb2YgZGVhbGluZyB3aXRoIGxpdGVyYXRlIHByb2dy
YW1taW5nIGZpbGVzIGlzIHRoZSAKaW50ZXJ3b3ZlbiBzdHJ1Y3R1cmUgdGhh
dCBjb2RlIGNodW5rIHJlZmVyZW5jZXMgY2FuIHByb2R1Y2UuICBUd28gbGV2
ZWxzIGFyZSAKbmVlZGVkIC0gaWRlbnRpZnkgYW5kIHN0b3JlIGRlZmluZWQg
Y2h1bmtzLCBhbmQgc3BvdCByZWZlcmVuY2VzIHRvIGNodW5rcyAKaW5zaWRl
IG9mIGNodW5rIGJvZGllcy4KClxzdWJzZWN0aW9ue0lkZW50aWZ5aW5nIGFu
ZCBTdG9yaW5nIENodW5rcyAtIFRvcCBMZXZlbH0KCkFuIGFzc3VtcHRpb24g
bWFkZSBpcyB0aGF0IGFsbCBjaHVuayBkZWZpbml0aW9ucyBhcmUgYGB0b3Ag
bGV2ZWwnJyAtIHRoYXQgaXMsIApubyBjaHVuayBpcyBkZWZpbmVkIGluIHRo
ZSBib2R5IG9mIGFub3RoZXIgY2h1bmsuICBHcmFudGluZyB0aGF0IGFzc3Vt
cHRpb24sIAppdCBpcyBwb3NzaWJsZSB0byBjaGVjayBlYWNoIHN0cmluZyBh
cyBpdCBpcyByZWFkIHRvIHNlZSBpZiBpdCBpcyB0aGUgc3RhcnQgCm9mIGEg
bmV3IGNodW5rLiAgVGhpcyBpcyBkb25lIHVzaW5nIExpc3Agc3RyaW5nIHNl
YXJjaGluZyBhbmQgc3BhY2UgdHJpbW1pbmcuCkFub3RoZXIgYXNzdW1wdGlv
biBpcyB0aGF0IHRoZSBiZWdpbm5pbmcgaWRlbnRpZmllciBmb3IgYSBjaHVu
ayBpcyBvbiBpdHMgCm93biBsaW5lIC0gdGhpcyBpcyBwcm9iYWJseSBub3Qg
c3RyaWN0bHkgbmVjZXNzYXJ5IGJ1dCBzaG91bGQgYmUgc3RhbmRhcmQgCmNv
bnZlbnRpb24uCgo8PHRvcGxldmVsLWNodW5rLXNjYW5uaW5nPj49CihkZWZ1
biBjaGVjay1mb3ItdG9wbGV2ZWwtY2h1bmsgKGlucHV0c3RyaW5nIGZpbGVu
YW1lKQogICAobGV0ICgodGVzdHN0cmluZyAoc3RyaW5nLXRyaW0gIiAiIGlu
cHV0c3RyaW5nKSkpCiAgICAgKGlmICg+IChsZW5ndGggdGVzdHN0cmluZykg
MykKICAgICAoaWYgKGFuZCAoc3RyaW5nLWVxdWFsIHN0YXJ0Y2hhcnMgdGVz
dHN0cmluZyA6ZW5kMiAobGVuZ3RoIHN0YXJ0Y2hhcnMpKQoJICAgICAgKHN0
cmluZy1lcXVhbCBlbmRjaGFycyB0ZXN0c3RyaW5nIAoJCQkgICAgIDpzdGFy
dDIgKC0gKGxlbmd0aCB0ZXN0c3RyaW5nKSAobGVuZ3RoIGVuZGNoYXJzKSkK
CQkJICAgICA6ZW5kMiAobGVuZ3RoIHRlc3RzdHJpbmcpKSkKICAgICAgICAg
KGxldCAoKG5ldy1jaHVuay1uYW1lIChzdWJzZXEgdGVzdHN0cmluZyAobGVu
Z3RoIHN0YXJ0Y2hhcnMpCgkJCQkgICAoLSAobGVuZ3RoIHRlc3RzdHJpbmcp
IChsZW5ndGggZW5kY2hhcnMpKSkpKQoJICAgKG1ha2UtbmV3LWNodW5rIG5l
dy1jaHVuay1uYW1lKQoJICAgKHJlYWQtaW4tY2h1bmsgbmV3LWNodW5rLW5h
bWUgZmlsZW5hbWUpCgkgICB0KQoJICkpKSkKCkAKClxzdWJzZWN0aW9ue0lk
ZW50aWZ5aW5nIGFuZCBFeHBhbmRpbmcgQ2h1bmsgUmVmZXJlbmNlc30KClRo
ZSBhYm92ZSB3aWxsIHNlcnZlIGZvciB0b3BsZXZlbCBjaHVuayBpZGVudGlm
aWNhdGlvbiwgYnV0IHRoZSB0YXNrIG9mIAppZGVudGlmeWluZyByZWZlcmVu
Y2VzIHRvIGNodW5rcyBpbiB0aGUgYm9keSBvZiBhIGNodW5rIGlzIGEgc2xp
Z2h0bHkgCmRpZmZlcmVudCB0YXNrLiAgQSBsaW5lIHdpbGwgY29udGFpbiBv
bmx5IG9uZSBjaHVuayBkZWZpbml0aW9uLCBidXQgdGhlIApjb250ZW50cyBv
ZiBhIGNodW5rIGJvZHkgbWF5IGNvbnRhaW4gbWFueSBjaHVuayByZWZlcmVu
Y2VzLiAgQSBmdXJ0aGVyIApjb21wbGljYXRpb24gaXMgdGhhdCBldmVuIHdo
ZW4gdGhvc2UgcmVmZXJlbmNlcyBhcmUgZXhwYW5kZWQsIHRoZXkgbWF5IApp
biB0dXJuIGNvbnRhaW4gb3RoZXIgcmVmZXJlbmNlcy4gIFRvIGhhbmRsZSB0
aGlzIGEgcmVjdXJzaXZlIGZ1bmN0aW9uCmlkZW50aWZpZXMgIHRoZSBmaXJz
dCBjaHVuaywgZXhwYW5kcyBpdCwgYnVpbGRzIGEgbmV3IHN0cmluZyBiYXNl
ZCBvbiAKdGhlIGNvbWJpbmF0aW9uICBvZiBvbGQgYW5kIG5ldywgaW5zZXJ0
cyBpbiBwbGFjZSBvZiB0aGUgcmVmZXJlbmNlLCAKYW5kIGNhbGxzIGl0c2Vs
ZiBvbiB0aGUgbmV3IHJlc3VsdC4gSW4gdGhlIGVuZCwgdGhlIHJldHVybmVk
IApzdHJpbmcgd2lsbCBoYXZlIGFsbCByZWZlcmVuY2VzIGV4cGFuZGVkIGFu
ZCBjb25zdGl0dXRlIHRoZSBmaW5hbCBmb3JtIG9mIAp0aGUgY2h1bmsgYXMg
aXQgaXMgdG8gYmUgc2VudCB0byB0aGUgb3V0cHV0IGZpbGUuCgpIb3dldmVy
LCB0aGVyZSBhcmUgc2V2ZXJhbCB0aGluZ3MgdG8gYmUgd2FyeSBvZiB3aGVu
IGRvaW5nIHRoaXMgc2Nhbi4gIFRoZQpmaXJzdCBpcyBhIGJhZCBjaHVuaywg
b3IgYSByZWZlcmVuY2UgY2h1bmsgd2hpY2ggaGFzIG5vIGRlZmluaXRpb24u
ICBUaGlzCmlzIGhhbmRsZWQgYnkgdGhyb3dpbmcgYW4gZXJyb3IgaWYgc3Vj
aCBhIGNodW5rIGlzIGVuY291bnRlcmVkLiAgV2Ugd2lsbAphbHNvIGRlZmlu
ZSBoZXJlIHRoZSBjb3JlIHJvdXRpbmUgZm9yIG1lcmdpbmcgdGhlIHN0cmlu
Z3M6Cgo8PGNvcmUtcmVmPj49Cihwcm9nbgogIChsZXQgKChtaWRkbGVzdHJp
bmcgKHN1YnNlcSBpbnB1dHN0cmluZyAKICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKCsgcG9zMSAobGVuZ3RoIHJlZnN0YXJ0Y2hhcnMpKSAKCQkJ
ICAgICAgcG9zMikpKQogICAgKGlmIChnZXRoYXNoIG1pZGRsZXN0cmluZyAq
Y2h1bmstaGFzaC10YWJsZSopCgkocHJvZ24KCSAgKHNldGYgaW5wdXRzdHJp
bmcgCgkJKGNvbmNhdGVuYXRlICdzdHJpbmcKCQkJICAgICAoc3Vic2VxIGlu
cHV0c3RyaW5nIDAgcG9zMSkKCQkJICAgICAoZ2V0LWNodW5rLWNvbnRlbnRz
IG1pZGRsZXN0cmluZykKCQkJICAgICAoc3Vic2VxIGlucHV0c3RyaW5nIAoJ
CQkgICAgICAgICAgICAgKCsgcG9zMiAobGVuZ3RoIHJlZmVuZGNoYXJzKSkp
KSkKCSAgKGNoZWNrLWZvci1yZWZlcmVuY2VkLWNodW5rIGlucHV0c3RyaW5n
IHBvczEpKQoJKGVycm9yICAiflMgd2FzIG5vdCBmb3VuZCBpbiBoYXNoIHRh
YmxlLiIgbWlkZGxlc3RyaW5nKSkpKSkpCkAKClRoZSBuZXh0IGNoZWNrIGlz
IGZvciBhIGNhc2Ugd2hlcmUgdGhlIGRlbGltaXRpbmcgY2hhcmFjdGVycyBh
cmUgYnJva2VuCnVwIG92ZXIgdHdvIGxpbmVzLiAgV2Ugd2lsbCBub3QgcmVn
YXJkIHRoaXMgYXMgYSBsZWdhbCBjaHVuayBuYW1lLCBhcwppdCBpcyBhIHJh
dGhlciB1bmxpa2VseSBjaGFyYWN0ZXIgY29tYmluYXRpb24gZm9yIGEgbGFi
ZWwsIGFuZCBpdCBhbHNvCmFsbG93cyB0aGUgYXZvaWRhbmNlIG9mIGFjY2lk
ZW50YWwgY2h1bmsgbmFtZSBtYXRjaGluZyB3aGVuIGl0IGlzIG5vdAppbnRl
bmRlZCAob25lIG9mIHRoZSBjaHVua3MgaW4gdGhpcyBwYW1waGxldCwgZm9y
IGV4YW1wbGUsIHdvdWxkIHRyaWdnZXIKc3VjaCBhbiBlcnJvci4pICBJZiBz
dWNoIGEgY29uZGl0aW9uIGlzIGZvdW5kLCB0aGUgc2NhbiBzaG91bGQgYmUg
cmVzdW1lZApiZXlvbmQgdGhlIG5ld2xpbmUgY2hhcmFjdGVyLgoKPDxjaGVj
ay1mb3ItbmV3bGluZT4+PQooaWYgKHNlYXJjaCAoc3RyaW5nICNcTmV3bGlu
ZSkgaW5wdXRzdHJpbmcgOnN0YXJ0MiBwb3MxIAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgOmVuZDIgcG9zMikKICAoY2hl
Y2stZm9yLXJlZmVyZW5jZWQtY2h1bmsgaW5wdXRzdHJpbmcgCiAgCSgrKHNl
YXJjaCAoc3RyaW5nICNcTmV3bGluZSkgaW5wdXRzdHJpbmcgOnN0YXJ0MiBw
b3MxCgkJCQkJCSA6ZW5kMiBwb3MyKSAxKSApCiAgPDxjb3JlLXJlZj4+CkAK
CldpdGggdGhvc2UgdHdvIGNoZWNrcyBpbiBwbGFjZSwgd2Ugbm93IGRlZmlu
ZSB0aGUgdG9wIGxldmVsIGNvbnRyb2wKZm9yIHBvc2l0aW9uaW5nIHRoZSBz
ZWFyY2ggY29tbWFuZC4gIFRvIGF2b2lkIGNvbmZ1c2lvbiBhbmQgdW5uZWVk
ZWQKc2Nhbm5pbmcsIHRoZSBjb21tYW5kIHRha2VzIGEgc3RhcnRpbmcgcG9z
aXRpb24gYXMgYW4gYXJndW1lbnQuICBUaGlzCmFsbG93cyBzdWJzZXF1ZW50
IHJlY3Vyc2l2ZSBjYWxscyB0byBkaWN0YXRlIHRoZWlyIHN0YXJ0aW5nIHBv
c2l0aW9uLAphbmQgdGhlIGluaXRpYWwgY2FsbCBzaW1wbHkgc3BlY2lmaWVz
IHplcm8gYXMgdGhlIGJlZ2lubmluZy4gIEF0IHRoaXMgbGV2ZWwKd2UgYWxz
byBoYXZlIHRoZSBleGl0IGNvbmRpdGlvbiAtIGlmIG9uZSBvciBtb3JlIG9m
IHBvczEgYW5kIHBvczIgYXJlCm5pbCwgdGhhdCBtZWFucyB0aGlzIHBhcnRp
Y3VsYXIgc3RyaW5nIGlzIGNvbXBsZXRlIGFuZCBjYW4gYmUgcmV0dXJuZWQu
Cgo8PHJlZmVyZW5jZS1jaHVuay1zY2FubmluZz4+PQooZGVmdW4gY2hlY2st
Zm9yLXJlZmVyZW5jZWQtY2h1bmsgKGlucHV0c3RyaW5nIHN0YXJ0cG9zKQog
ICAobGV0ICgocG9zMSAoc2VhcmNoIHJlZnN0YXJ0Y2hhcnMgaW5wdXRzdHJp
bmcgOnN0YXJ0MiBzdGFydHBvcykpKQogICAgIChsZXQgKChwb3MyIChpZiBw
b3MxIChzZWFyY2ggcmVmZW5kY2hhcnMgaW5wdXRzdHJpbmcgOnN0YXJ0MiBw
b3MxKSkpKQogICAgICAgKGlmIChhbmQgcG9zMSBwb3MyKQoJICAgKHByb2du
CgkgICA8PGNoZWNrLWZvci1uZXdsaW5lPj4KCSAgIGlucHV0c3RyaW5nKSkp
KQoKQAoKXHNlY3Rpb257UmVhZGluZyBpbiBDaHVua3N9CgpPbmNlIHdlIGhh
dmUgaWRlbnRpZmllZCBhIGNodW5rIGF0IHRoZSB0b3AgbGV2ZWwsIHdlIG11
c3QgcmVhZCBpdCBpbi4gSW4gdGhlIAp0b3BsZXZlbCBmdW5jdGlvbiB0aGF0
IGpvYiBpcyBwYXNzZWQgb2ZmIHRoYXQgam9iIHRvIGEgZnVuY3Rpb24gY2Fs
bGVkIApyZWFkLWluLWNodW5rLiAgcmVhZC1pbi1jaHVuayBpcyB0aGUgZnVu
Y3Rpb24gdGhhdCBwdXRzIGFkZGl0aW9uYWwgbGluZXMgaW50byAKdGhlIGNo
dW5rIGNvbnRlbnRzIHNsb3QgdW50aWwgdGhlIGVuZC1vZi1jaHVuay1ib2R5
IGNoYXJhY3RlciBpcyBzcG90dGVkLiAgCkl0IGFsc28gdXNlcyByZWN1cnNp
b24gLSBpZiB0aGUgbGluZSBpdCByZWFkcyBpc24ndCB0aGUgZW5kLW9mLWJv
ZHkgbWFya2VyLCAKaXQgYXBwZW5kcyB0aGF0IGxpbmUgdG8gdGhlIGNvbnRl
bnRzIGFuZCBjYWxscyBpdHNlbGYgdG8gY2hlY2sgdGhlIG5leHQgCmxpbmUu
ICBJdCBhbHNvIHdpbGwgYXZvaWQgYW4gZW5kLW9mLWJvZHkgbWFya2VyIHdp
dGggYSBkb3VibGUtcXVvdGUgaW4gZnJvbnQKb2YgaXQsIHRvIGFsbG93IHRo
ZSBwcmVzZW5jZSBvZiB0aGF0IGNoYXJhY3RlciBpbiBjZXJ0YWluIHVzZXMu
Cgo8PHJlYWRpbi1jaHVuaz4+PQooZGVmdW4gcmVhZC1pbi1jaHVuayAoY3Vy
ci1jaHVuay1uYW1lIGZpbGVuYW1lKQogIChsZXQgKChsaW5lcyBuaWwpKQog
ICAgIChsb29wIGZvciBuZXh0bGluZSA9IChyZWFkLWxpbmUgZmlsZW5hbWUg
bmlsKQogICAgICAgICAgICB3aGlsZSAob3IgKG5vdCAoc2VhcmNoIGVuZGNo
dW5rY2hhcnMgbmV4dGxpbmUpKQogICAgICAgICAgICAgICAgICAgICAgIChz
ZWFyY2ggKGNvbmNhdGVuYXRlICdzdHJpbmcgKHN0cmluZyAjXCIpIAoJCQkJ
CWVuZGNodW5rY2hhcnMpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgbmV4dGxpbmUpKQogICAgICAgICAgICBkbwogICAgICAgICAgICAgICAg
ICAocHJvZ24KICAgICAgICAgICAgICAgICAgICAgKHB1c2ggbmV4dGxpbmUg
bGluZXMpCiAgICAgICAgICAgICAgICAgICAgIChwdXNoIChzdHJpbmcgI1xO
ZXdsaW5lKSBsaW5lcykpKQogICAgICAoaWYgbGluZXMKICAgICAgICAgKHBy
b2duCiAgICAgICAgICAgIChwb3AgbGluZXMpCiAgICAgICAgICAgIChhZGQt
dG8tY2h1bmstY29udGVudHMgY3Vyci1jaHVuay1uYW1lCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAoYXBwbHkgIydjb25jYXRlbmF0ZSAnc3RyaW5n
IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAocmV2ZXJzZSBs
aW5lcykpKSkpKSkKCkAKClxzZWN0aW9ue0ZpbGUgT3BlcmF0aW9uc30KCk5v
dyB0aGF0IHdlIGtub3cgaG93IHRvIGhhbmRsZSBjaHVua3MsIHdlIG9ubHkg
bmVlZCB0byBhcHBseSB0aGF0IGtub3dsZWRnZSAKdG8gc29tZSBwYXJ0aWN1
bGFyIGZpbGUuICBGb3IgdGhpcywgd2UgdXNlIGEgbG9vcCBtYWNybyByYXRo
ZXIgdGhhbiByZWN1cnNpb24uCgo8PGxvYWQtZmlsZT4+PQooZGVmdW4gbG9h
ZC1wYW1waGxldC1maWxlIChmaWxlbmFtZSkKICAobGV0ICgoaW4gKG9wZW4g
ZmlsZW5hbWUgOmlmLWRvZXMtbm90LWV4aXN0IG5pbCkpKQogICAgKHdoZW4g
aW4KICAgICAgKGxvb3AgZm9yIGxpbmUgPSAocmVhZC1saW5lIGluIG5pbCkK
CSAgICB3aGlsZSBsaW5lIGRvIChjaGVjay1mb3ItdG9wbGV2ZWwtY2h1bmsg
bGluZSBpbikpCiAgICAgIChjbG9zZSBpbikpKSkKCkAKCldlIGFsc28gbmVl
ZCB0byBiZSBhYm91dCB0byBvdXRwdXQgdG8gYSBmaWxlLiBUaGUgemVybyBp
biB0aGUgd3JpdGUtc3RyaW5nIApjb21tYW5kIHNpbXBseSB0ZWxscyB0aGUg
c2Nhbm5lciB0byBzdGFydCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBmaWxl
LiAgQXMKaXQgaXMgY3VycmVudGx5IGNvbmZpZ3VyZWQsIHRoZSBvdXRwdXQg
ZmlsZSBpcyBhbHdheXMgb3ZlcndyaXR0ZW4uCgo8PHdyaXRlLWZpbGU+Pj0K
KGRlZnVuIHdyaXRlLW91dHB1dC1maWxlIChmaWxlbmFtZSBjaHVua25hbWUp
CiAgKGxldCAoKG91dHB1dHN0cmVhbSAob3BlbiBmaWxlbmFtZSA6ZGlyZWN0
aW9uIDpvdXRwdXQgOmlmLWV4aXN0cyA6c3VwZXJzZWRlKSkpCiAgICAod3Jp
dGUtc3RyaW5nIChjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVuayAKCQkgICAo
Z2V0LWNodW5rLWNvbnRlbnRzIGNodW5rbmFtZSkgMCkgb3V0cHV0c3RyZWFt
KQogICAgKGNsb3NlIG91dHB1dHN0cmVhbSkpKQoKQAoKXHNlY3Rpb257UHVs
bGluZyBJdCBUb2dldGhlciAtIFRoZSBub3RhbmdsZSBDb21tYW5kfQoKVGhl
IGZpbmFsLCB0b3AgbGV2ZWwgY29udHJvbCBjb21tYW5kIGlzIG5hbWVkIG5v
dGFuZ2xlIHRvIGNvbmZvcm0gdG8gdGhlIApOT1dFQiBjb252ZW50aW9uLiAg
VGhpcyBjb21tYW5kIGFjY2VwdHMgYW4gaW5wdXQgZmlsZSwgb3V0cHV0IGZp
bGUsIGFuZCAKb3B0aW9uYWxseSB0aGUgbmFtZSBvZiB0aGUgY2h1bmsgYXQg
d2hpY2ggdG8gc3RhcnQgZXh0cmFjdGluZyBjb250ZW50cy4gIApUaGUgZGVm
YXVsdCBjb252ZW50aW9uIG9mIEF4aW9tIGlzIHRvIHVzZSBhbiBhc3Rlcmlz
ayBhcyB0aGUgcm9vdCBub2RlLCBidXQgCnRoaXMgaXMgbm90IHVuaXZlcnNh
bGx5IHRydWUgYW5kIGl0IGlzIHNvbWV0aW1lcyBkZXNpcmFibGUgdG8gb3V0
cHV0IGNvZGUgCmZyb20gb25lIHBhbXBobGV0IGludG8gbXVsdGlwbGUgdGFy
Z2V0IGZpbGVzLCBzdGFydGluZyBhdCBtdWx0aXBsZSByb290cy4gIApJbiB0
aGF0IGNhc2UsIHRoZSBjaHVuayBuYW1lIGlzIHBhc3NlZCB0byBub3Rhcmdl
dCBhcyB3ZWxsLiAgRm9yIGV4YW1wbGU6CgpcYmVnaW57cXVvdGV9Cihub3Rh
bmdsZSBgYGJvb3QucGFtcGhsZXQnJyBgYGJvb3QubGlzcCcnIGBgUkxpc3An
JykKXGVuZHtxdW90ZX0KClxub2luZGVudCB3b3VsZCBleHRyYWN0IGFsbCBj
b2RlIHJlZmVyZW5jZWQgYnkgdGhlIFJMaXNwIGNodW5rLCB3aGVyZWFzCgpc
YmVnaW57cXVvdGV9Cihub3RhbmdsZSBgYGJvb3QucGFtcGhsZXQnJyBgYGJv
b3QuYm9vdCcnKQpcZW5ke3F1b3RlfQoKXG5vaW5kZW50IHdvdWxkIGV4dHJh
Y3QgYWxsIGNvZGUgcmVmZXJlbmNlZCBieSB0aGUgXHZlcmJAJycqJydAIG5v
ZGUuCgpUaGUgbm90YW5nbGUgY29tbWFuZCB3aWxsIGFsd2F5cyBjbGVhciB0
aGUgaGFzaCB0YWJsZSBiZWZvcmUgYW5kIGFmdGVyCnVzZSwgdG8gZW5zdXJl
IG5vIGFjY2lkZW50YWwgY29sbGlzaW9ucyBhbmQgYXZvaWQgdW5uZWNlc3Nh
cnkgbWVtb3J5CnVzYWdlLgoKPDxub3RhbmdsZT4+PQooZGVmdW4gbm90YW5n
bGUgKGZpbGVpbm5hbWUgZmlsZW91dG5hbWUgJm9wdGlvbmFsIChjaHVua25h
bWUgIioiKSkKICAoY2xyaGFzaCAqY2h1bmstaGFzaC10YWJsZSopCiAgKGxv
YWQtcGFtcGhsZXQtZmlsZSBmaWxlaW5uYW1lKQogICh3cml0ZS1vdXRwdXQt
ZmlsZSBmaWxlb3V0bmFtZSBjaHVua25hbWUpCiAgKGNscmhhc2ggKmNodW5r
LWhhc2gtdGFibGUqKSkKQAoKXGVuZHtkb2N1bWVudH0K

--0-631001030-1171634586=:41236

OzsgQ29weXJpZ2h0IChjKSAyMDA3LCBDbGlmZm9yZCBZYXBwCjs7IEFsbCBy
aWdodHMgcmVzZXJ2ZWQuCgo7OyBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGlu
IHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKOzsg
bW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhl
IGZvbGxvd2luZyBjb25kaXRpb25zIGFyZQo7OyBtZXQ6Cjs7Cjs7ICAgIC0g
UmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRo
ZSBhYm92ZSBjb3B5cmlnaHQKOzsgICAgICBub3RpY2UsIHRoaXMgbGlzdCBv
ZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCjs7
Cjs7ICAgIC0gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg
cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKOzsgICAgICBub3RpY2Us
IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRp
c2NsYWltZXIgaW4KOzsgICAgICB0aGUgZG9jdW1lbnRhdGlvbiBhbmQvb3Ig
b3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlCjs7ICAgICAgZGlz
dHJpYnV0aW9uLgo7Owo7OyAgICAtIFRoZSBuYW1lcyBvZiB0aGUgY29udHJp
YnV0b3JzIG1heSBub3QgYmUgdXNlZCB0byBlbmRvcnNlIG9yIHByb21vdGUK
OzsgICAgICBwcm9kdWN0cyBkZXJpdmVkIGZyb20gdGhpcyBzb2Z0d2FyZSB3
aXRob3V0IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4KOzsgICAgICBwZXJtaXNz
aW9uLgo7Owo7O1RISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIENP
UFlSSUdIVCBIT0xERVJTIEFORCBDT05UUklCVVRPUlMgIkFTCjs7SVMiIEFO
RCBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElO
RywgQlVUIE5PVCBMSU1JVEVECjs7VE8sIFRIRSBJTVBMSUVEIFdBUlJBTlRJ
RVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBCjs7UEFS
VElDVUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELiBJTiBOTyBFVkVOVCBT
SEFMTCBUSEUgQ09QWVJJR0hUIE9XTkVSCjs7T1IgQ09OVFJJQlVUT1JTIEJF
IExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUws
IFNQRUNJQUwsCjs7RVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMIERBTUFH
RVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLAo7O1BST0NVUkVN
RU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1MgT0Yg
VVNFLCBEQVRBLCBPUgo7O1BST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQ
VElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YKOztM
SUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJ
VFksIE9SIFRPUlQgKElOQ0xVRElORwo7O05FR0xJR0VOQ0UgT1IgT1RIRVJX
SVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRIRSBVU0UgT0YgVEhJ
Uwo7O1NPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklM
SVRZIE9GIFNVQ0ggREFNQUdFLgoKKGRlZnZhciBzdGFydGNoYXJzICI8PCIp
CihkZWZ2YXIgZW5kY2hhcnMgIj4+PSIpCihkZWZ2YXIgZW5kY2h1bmtjaGFy
cyAiQCIpCihkZWZ2YXIgcmVmc3RhcnRjaGFycyAiPDwiKQooZGVmdmFyIHJl
ZmVuZGNoYXJzICI+PiIpIAoKKGRlZnBhcmFtZXRlciAqY2h1bmstaGFzaC10
YWJsZSogKG1ha2UtaGFzaC10YWJsZSA6dGVzdCAnZXF1YWwpKQoKKGRlZmNs
YXNzIGNodW5rICgpCiAgKChjaHVuay1uYW1lCiAgICA6aW5pdGFyZyA6Y2h1
bmstbmFtZQogICAgOmluaXRmb3JtIChlcnJvciAiTXVzdCBzdXBwbHkgYSBj
aHVuayBuYW1lLiIpCiAgICA6cmVhZGVyIGNodW5rLW5hbWUKICAgIDpkb2N1
bWVudGF0aW9uICJOYW1lIG9mIGNodW5rLiIpCiAgIChjaHVuay1jb250ZW50
cwogICAgOmluaXRhcmcgOmNodW5rLWNvbnRlbnRzCiAgICA6aW5pdGZvcm0g
IiIKICAgIDphY2Nlc3NvciBjaHVuay1jb250ZW50cwogICAgOmRvY3VtZW50
YXRpb24gIlRleHQgb2YgY2h1bmsgLSBtYXkgaW5jbHVkZSByZWZlcmVuY2Vz
IHRvIG90aGVyIGNodW5rcyIpKSkKCihkZWZ1biBtYWtlLW5ldy1jaHVuayAo
Y3Vyci1jaHVuay1uYW1lKQogIChzZXRmIChnZXRoYXNoIGN1cnItY2h1bmst
bmFtZSAqY2h1bmstaGFzaC10YWJsZSopIAoJKG1ha2UtaW5zdGFuY2UgJ2No
dW5rIDpjaHVuay1uYW1lIGN1cnItY2h1bmstbmFtZSkpKQoKKGRlZnVuIGdl
dC1jaHVuay1jb250ZW50cyAoY3Vyci1jaHVuay1uYW1lKQogIChjaHVuay1j
b250ZW50cyAoZ2V0aGFzaCBjdXJyLWNodW5rLW5hbWUgKmNodW5rLWhhc2gt
dGFibGUqKSkpCgooZGVmdW4gYWRkLXRvLWNodW5rLWNvbnRlbnRzIChjdXJy
LWNodW5rLW5hbWUgbmV3LWNvbnRlbnRzKQogIChsZXQgKChzdGFydGluZy1j
aHVuay1jb250ZW50cyAoZ2V0LWNodW5rLWNvbnRlbnRzIGN1cnItY2h1bmst
bmFtZSkpKQogICAgKGlmIChzdHJpbmctZXF1YWwgc3RhcnRpbmctY2h1bmst
Y29udGVudHMgIiIpCgkoc2V0ZiAoY2h1bmstY29udGVudHMgKGdldGhhc2gg
Y3Vyci1jaHVuay1uYW1lICpjaHVuay1oYXNoLXRhYmxlKikpCgkgICAgICBu
ZXctY29udGVudHMpCgkoc2V0ZiAoY2h1bmstY29udGVudHMgKGdldGhhc2gg
Y3Vyci1jaHVuay1uYW1lICpjaHVuay1oYXNoLXRhYmxlKikpCgkgICAgICAo
Y29uY2F0ZW5hdGUgJ3N0cmluZyBzdGFydGluZy1jaHVuay1jb250ZW50cyAo
c3RyaW5nICNcTmV3bGluZSkKCQkJICAgbmV3LWNvbnRlbnRzKSkpKSkKCihk
ZWZ1biB2aWV3LWFsbC1jaHVua3MgKCkKICAobWFwaGFzaCAjJyhsYW1iZGEg
KGsgdikgKGZvcm1hdCB0ICJ+YSA9PiB+YX4lIiBrIHYpKSAqY2h1bmstaGFz
aC10YWJsZSopKQoKKGRlZnVuIHJlYWQtaW4tY2h1bmsgKGN1cnItY2h1bmst
bmFtZSBmaWxlbmFtZSkKICAobGV0ICgobGluZXMgbmlsKSkKICAgICAobG9v
cCBmb3IgbmV4dGxpbmUgPSAocmVhZC1saW5lIGZpbGVuYW1lIG5pbCkKICAg
ICAgICAgICAgd2hpbGUgKG9yIChub3QgKHNlYXJjaCBlbmRjaHVua2NoYXJz
IG5leHRsaW5lKSkKICAgICAgICAgICAgICAgICAgICAgICAoc2VhcmNoIChj
b25jYXRlbmF0ZSAnc3RyaW5nIChzdHJpbmcgI1wiKSAKCQkJCQllbmRjaHVu
a2NoYXJzKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5leHRs
aW5lKSkKICAgICAgICAgICAgZG8KICAgICAgICAgICAgICAgICAgKHByb2du
CiAgICAgICAgICAgICAgICAgICAgIChwdXNoIG5leHRsaW5lIGxpbmVzKQog
ICAgICAgICAgICAgICAgICAgICAocHVzaCAoc3RyaW5nICNcTmV3bGluZSkg
bGluZXMpKSkKICAgICAgKGlmIGxpbmVzCiAgICAgICAgIChwcm9nbgogICAg
ICAgICAgICAocG9wIGxpbmVzKQogICAgICAgICAgICAoYWRkLXRvLWNodW5r
LWNvbnRlbnRzIGN1cnItY2h1bmstbmFtZQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgKGFwcGx5ICMnY29uY2F0ZW5hdGUgJ3N0cmluZyAKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKHJldmVyc2UgbGluZXMpKSkp
KSkpCgooZGVmdW4gY2hlY2stZm9yLXRvcGxldmVsLWNodW5rIChpbnB1dHN0
cmluZyBmaWxlbmFtZSkKICAgKGxldCAoKHRlc3RzdHJpbmcgKHN0cmluZy10
cmltICIgIiBpbnB1dHN0cmluZykpKQogICAgIChpZiAoPiAobGVuZ3RoIHRl
c3RzdHJpbmcpIDMpCiAgICAgKGlmIChhbmQgKHN0cmluZy1lcXVhbCBzdGFy
dGNoYXJzIHRlc3RzdHJpbmcgOmVuZDIgKGxlbmd0aCBzdGFydGNoYXJzKSkK
CSAgICAgIChzdHJpbmctZXF1YWwgZW5kY2hhcnMgdGVzdHN0cmluZyAKCQkJ
ICAgICA6c3RhcnQyICgtIChsZW5ndGggdGVzdHN0cmluZykgKGxlbmd0aCBl
bmRjaGFycykpCgkJCSAgICAgOmVuZDIgKGxlbmd0aCB0ZXN0c3RyaW5nKSkp
CiAgICAgICAgIChsZXQgKChuZXctY2h1bmstbmFtZSAoc3Vic2VxIHRlc3Rz
dHJpbmcgKGxlbmd0aCBzdGFydGNoYXJzKQoJCQkJICAgKC0gKGxlbmd0aCB0
ZXN0c3RyaW5nKSAobGVuZ3RoIGVuZGNoYXJzKSkpKSkKCSAgIChtYWtlLW5l
dy1jaHVuayBuZXctY2h1bmstbmFtZSkKCSAgIChyZWFkLWluLWNodW5rIG5l
dy1jaHVuay1uYW1lIGZpbGVuYW1lKQoJICAgdCkKCSApKSkpCgooZGVmdW4g
Y2hlY2stZm9yLXJlZmVyZW5jZWQtY2h1bmsgKGlucHV0c3RyaW5nIHN0YXJ0
cG9zKQogICAobGV0ICgocG9zMSAoc2VhcmNoIHJlZnN0YXJ0Y2hhcnMgaW5w
dXRzdHJpbmcgOnN0YXJ0MiBzdGFydHBvcykpKQogICAgIChsZXQgKChwb3My
IChpZiBwb3MxIChzZWFyY2ggcmVmZW5kY2hhcnMgaW5wdXRzdHJpbmcgOnN0
YXJ0MiBwb3MxKSkpKQogICAgICAgKGlmIChhbmQgcG9zMSBwb3MyKQoJICAg
KHByb2duCgkgICAoaWYgKHNlYXJjaCAoc3RyaW5nICNcTmV3bGluZSkgaW5w
dXRzdHJpbmcgOnN0YXJ0MiBwb3MxIAogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgOmVuZDIgcG9zMikKICAoY2hlY2stZm9y
LXJlZmVyZW5jZWQtY2h1bmsgaW5wdXRzdHJpbmcgCiAgCSgrKHNlYXJjaCAo
c3RyaW5nICNcTmV3bGluZSkgaW5wdXRzdHJpbmcgOnN0YXJ0MiBwb3MxCgkJ
CQkJCSA6ZW5kMiBwb3MyKSAxKSApCiAgKHByb2duCiAgKGxldCAoKG1pZGRs
ZXN0cmluZyAoc3Vic2VxIGlucHV0c3RyaW5nIAogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAoKyBwb3MxIChsZW5ndGggcmVmc3RhcnRjaGFycykp
IAoJCQkgICAgICBwb3MyKSkpCiAgICAoaWYgKGdldGhhc2ggbWlkZGxlc3Ry
aW5nICpjaHVuay1oYXNoLXRhYmxlKikKCShwcm9nbgoJICAoc2V0ZiBpbnB1
dHN0cmluZyAKCQkoY29uY2F0ZW5hdGUgJ3N0cmluZwoJCQkgICAgIChzdWJz
ZXEgaW5wdXRzdHJpbmcgMCBwb3MxKQoJCQkgICAgIChnZXQtY2h1bmstY29u
dGVudHMgbWlkZGxlc3RyaW5nKQoJCQkgICAgIChzdWJzZXEgaW5wdXRzdHJp
bmcgCgkJCSAgICAgICAgICAgICAoKyBwb3MyIChsZW5ndGggcmVmZW5kY2hh
cnMpKSkpKQoJICAoY2hlY2stZm9yLXJlZmVyZW5jZWQtY2h1bmsgaW5wdXRz
dHJpbmcgcG9zMSkpCgkoZXJyb3IgICJ+UyB3YXMgbm90IGZvdW5kIGluIGhh
c2ggdGFibGUuIiBtaWRkbGVzdHJpbmcpKSkpKSkKCSAgIGlucHV0c3RyaW5n
KSkpKQoKKGRlZnVuIGxvYWQtcGFtcGhsZXQtZmlsZSAoZmlsZW5hbWUpCiAg
KGxldCAoKGluIChvcGVuIGZpbGVuYW1lIDppZi1kb2VzLW5vdC1leGlzdCBu
aWwpKSkKICAgICh3aGVuIGluCiAgICAgIChsb29wIGZvciBsaW5lID0gKHJl
YWQtbGluZSBpbiBuaWwpCgkgICAgd2hpbGUgbGluZSBkbyAoY2hlY2stZm9y
LXRvcGxldmVsLWNodW5rIGxpbmUgaW4pKQogICAgICAoY2xvc2UgaW4pKSkp
CgooZGVmdW4gd3JpdGUtb3V0cHV0LWZpbGUgKGZpbGVuYW1lIGNodW5rbmFt
ZSkKICAobGV0ICgob3V0cHV0c3RyZWFtIChvcGVuIGZpbGVuYW1lIDpkaXJl
Y3Rpb24gOm91dHB1dCA6aWYtZXhpc3RzIDpzdXBlcnNlZGUpKSkKICAgICh3
cml0ZS1zdHJpbmcgKGNoZWNrLWZvci1yZWZlcmVuY2VkLWNodW5rIAoJCSAg
IChnZXQtY2h1bmstY29udGVudHMgY2h1bmtuYW1lKSAwKSBvdXRwdXRzdHJl
YW0pCiAgICAoY2xvc2Ugb3V0cHV0c3RyZWFtKSkpCgooZGVmdW4gbm90YW5n
bGUgKGZpbGVpbm5hbWUgZmlsZW91dG5hbWUgJm9wdGlvbmFsIChjaHVua25h
bWUgIioiKSkKICAoY2xyaGFzaCAqY2h1bmstaGFzaC10YWJsZSopCiAgKGxv
YWQtcGFtcGhsZXQtZmlsZSBmaWxlaW5uYW1lKQogICh3cml0ZS1vdXRwdXQt
ZmlsZSBmaWxlb3V0bmFtZSBjaHVua25hbWUpCiAgKGNscmhhc2ggKmNodW5r
LWhhc2gtdGFibGUqKSk=

\start
Date: Fri, 16 Feb 2007 15:10:25 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: A first attempt at a notangle in Lisp

Hi Cliff,

Wouldn't it make sense to contact the Texmacs people whether they would 
want some literate programming support. Or has Texmacs LP support already?

\start
Date: Fri, 16 Feb 2007 06:59:38 -0800 (PST)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: A first attempt at a notangle in Lisp

That's a good question.  I don't know if they support it - I'll have to
check tonight.  At the moment I can't compile TeXmacs for some reason
on my machine, so I'll have to figure that out first.  I don't know if
there would be interest on the product side.

The Emacs mode is nice but that syntax highlighting problem is annoying
and is apparently a limitation of mmm-mode - that plus the mathematical
WYSIWYG of TeXmacs could be Very Nice indeed.  Don't know how much work
is involved with making TeXmacs nice for our purposes, but it's
probably worth a look.

Cheers,
CY

--- Ralf Hemmecke wrote:

> Hi Cliff,
> 
> Wouldn't it make sense to contact the Texmacs people whether they
> would want some literate programming support. Or has Texmacs LP
> support already?

\start
Date: Fri, 16 Feb 2007 17:59:15 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: A first attempt at a notangle in Lisp

Le vendredi 16 f=E9vrier 2007 =E0 13:44 +0100, Waldek Hebisch a =E9crit :=

> > I hesitate to say it's useful, but I have what appears to be a (more =
or
> > less) working notangle command in lisp.  It successfully handles a
> > couple test files, and although I haven't inspected the results it
> > handled most of the contents of boot and interp without crashing.
> > Unfortunately it's performance is worse than abysmal. 
>
> Your method of appending content to a chunk was quadratic.  Below
> is a diff changing this to linear method, gives much better speed (at
> least on "nag-e02.boot.pamphlet") but still much slower than Debian
> notangle (0.48s sbcl, 0.028s system version).  AFAICS reading
> pamphlets is still slow (takes 0.4s on "nag-e02.boot.pamphlet").
>
>
> --- cl-notangle.lisp.pamphlet	2007-02-16 11:57:23.000000000 +0100
> +++ cl-notangle.lisp.pamphlet	2007-02-16 13:03:47.000000000 +0100
> @@ -365,13 +365,21 @@
> 
>  <<readin-chunk>>=
>  (defun read-in-chunk (curr-chunk-name filename)
> -  (let ((nextline (read-line filename nil)))
> -    (if (or (not (search endchunkchars nextline))
> -            (search (concatenate 'string (string #\") endchunkchars)
> -	             nextline))
> -	(progn
> -	  (add-to-chunk-contents curr-chunk-name nextline)
> -	  (read-in-chunk curr-chunk-name filename)))))
> +  (let ((lines nil))
> +     (loop for nextline = (read-line filename nil)
> +            while (or (not (search endchunkchars nextline))
> +                       (search (concatenate 'string (string #\") endch=
unkchars)
> +                                nextline))
> +            do
> +                  (progn
> +                     (push nextline lines)
> +                     (push (string #\Newline) lines)))
> +      (if lines
> +         (progn
> +            (pop lines)
> +            (add-to-chunk-contents curr-chunk-name
> +                            (apply #'concatenate 'string
> +                                 (reverse lines)))))))

And another one (it does not remove the last #\Newline):

(defun read-in-chunk (curr-chunk-name filename)
  (let* ((nl (string #\Newline))
        (lines (loop for nextline = (read-line filename nil)
                 while (or (not (search endchunkchars nextline))
                       (search (concatenate 'string (string #\")
                                        endchunkchars)
                                nextline))
                 collect (concatenate 'string nextline nl))))
      (if lines
            (add-to-chunk-contents curr-chunk-name
                            (apply #'concatenate 'string
                                 lines)))))

Only tested on nag-e02.boot.pamphlet with SBCL.

\start
Date: Fri, 16 Feb 2007 11:24:57 -0600
From: Tim Daly
To: list
Subject: lisp noweb speed issue

Generally doing read or readline calls is a very slow way to read a file.
Use read-sequence instead. The improvement is noticeable.

See <http://www.emmett.ca/~sabetts/slurp.html>

\start
Date: Fri, 16 Feb 2007 19:10:15 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: A first attempt at a notangle in Lisp

On 02/16/2007 03:59 PM, C Y wrote:
> That's a good question.  I don't know if they support it - I'll have to
> check tonight.  At the moment I can't compile TeXmacs for some reason
> on my machine, so I'll have to figure that out first.  I don't know if
> there would be interest on the product side.

Well, every time I try texmacs I get frustrated after a few minutes.
Recently I downloaded TeXmacs-1.0.6.8-static-gnu-linux.tar.gz extracted
and started it. Then I started a Maple session typed just

2 + 3

and ENTER and texmacs stopped to respond.

After setting MATHLINK_PLATFORM I get a few warnings but Mma seems to work.

Anyway, always seem to run into trouble with TeXmacs although I find the 
idea very good and I think texmacs is very appropriate as an Axiom GUI 
and also (and in particular) for the literate programming way of writing 
  the Axiom program itself.

> The Emacs mode is nice but that syntax highlighting problem is annoying
> and is apparently a limitation of mmm-mode

Well, I thought you in particular could trace that bug somehow. 
Unfortunately, I cannot do serious things in LISP.

\start
Date: Fri, 16 Feb 2007 10:27:05 -0800 (PST)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: A first attempt at a notangle in Lisp

--- Ralf Hemmecke wrote:
> > The Emacs mode is nice but that syntax highlighting problem is
> > annoying and is apparently a limitation of mmm-mode
> 
> Well, I thought you in particular could trace that bug somehow. 

I probably can, but my current (imperfect) understanding of the issue
is that it is buried deeply in the controlling of the Emacs syntax
highlighting routines and how they work.  It would probably involve
some serious greasemonkey work on mmm-mode's guts (I don't think
mmm-mode is being actively developed any more), and if I'm going to do
that I would rather turn the whole thing into a literate program and
actually understand what it is doing.  (I'd probably have to do that
much work anyway to figure out how to handle this.)

> Unfortunately, I cannot do serious things in LISP.

Well, I can't either ;-).  No point in letting that stop me though -
given enough head banging you can punch a hole in a brick wall :-).

\start
Date: Fri, 16 Feb 2007 10:36:06 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: lisp noweb speed issue

I'll take a look at read-sequence this weekend and see if I can figure
it out.

Tim, performance tuning and fixing a couple of hacks aside (I need to
look over Ralf's perl solution to make sure I've got my bases covered)
is this something that you think could be used in Axiom?  I wrote it
because I want to teach asdf how to handle Axiom's source files by
itself, and for experimental purposes it will probably serve in its
current form, but if there's a real chance of it being used in Axiom
proper I'll put some more time into it.  It will probably never be as
flexible as noweb itself but I doubt we need all of that flexibility.

Of course, that begs the noweb side of the question, but that's more
complex than notangle and will probably have to wait a bit.

Cheers,
CY

--- Tim Daly wrote:

> Generally doing read or readline calls is a very slow way to read a
> file.
> Use read-sequence instead. The improvement is noticeable.
> 
> See <http://www.emmett.ca/~sabetts/slurp.html>

\start
Date: 16 Feb 2007 04:31:05 -0600
From: Gabriel Dos Reis
To: Andrey G. Grozin
Subject: Re: build-improvements without external noweb: is it supposed to work?

Andrey G. Grozin writes:

| On Wed, 14 Feb 2007, Bill Page wrote:
| > Quoting Andrey G. Grozin:
| >>  ./../..//build/i686-pc-linux/bin/lisp -batch -eval \
| >>                   '(progn (mapcar (function (lambda (x) (load x))) \
| >>                           (quote ( "boothdr.o"  "exports.o"  "npextras.o"
| >>  "stage0/ptyout.o"  "stage0/btincl2.o"  "stage0/btscan2.o"
| >>  "stage0/typrops.o"  "stage0/btpile2.o"  "stage0/typars.o"
| >>  "stage0/tytree1.o"))) \
| >>                           (system::save-system "bootsys"))'
| >>
| >>  Error: The variable |
| >> |  is unbound.
| >>  Fast links are on: do (si::use-fast-links nil) for debugging
| >>  Error signalled by PROGN.
| >>  Broken at MAPCAR.  Type :H for Help.
| Doing ./configure and make in a freshly checked-out tree with the
| latest Bill's patch, I get exactly the same error:
| 
| ./../..//build/i686-pc-linux/bin/lisp -batch -eval \
|                  '(progn (mapcar (function (lambda (x) (load x))) \
|                          (quote ( "boothdr.o"  "exports.o"
| "npextras.o" "stage0/ptyout.o"  "stage0/btincl2.o"  "stage0/btscan2.o"
| "stage0/typrops.o"  "stage0/btpile2.o"  "stage0/typars.o"
| "stage0/tytree1.o"))) \
|                          (system::save-system "bootsys"))'

I just finished a build with Bill's patch -- there was only one
glitch: there was a missing closing paren.

\start
Date: 16 Feb 2007 20:53:16 +0100
From: Martin Rubey
To: Cliff Yapp
Subject: Re: A first attempt at a notangle in Lisp

Cliff Yapp writes:

> --- Ralf Hemmecke wrote:
> > > The Emacs mode is nice but that syntax highlighting problem is annoying
> > > and is apparently a limitation of mmm-mode
> > 
> > Well, I thought you in particular could trace that bug somehow. 
> 
> I probably can, 

PLEASE PLEASE DO. In fact, since you say that mmm is roughly dead, maybe you
could resurrect it? It is a wunderful thing, apart from those glitches...

\start
Date: Fri, 16 Feb 2007 21:55:52 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: A first attempt at a notangle in Lisp

Hello Cliff,

On 02/16/2007 08:53 PM, Martin Rubey wrote:
> Cliff Yapp writes:
> 
>> --- Ralf Hemmecke wrote:
>>>> The Emacs mode is nice but that syntax highlighting problem is annoying
>>>> and is apparently a limitation of mmm-mode
>>> Well, I thought you in particular could trace that bug somehow. 
>> I probably can, 
> 
> PLEASE PLEASE DO. In fact, since you say that mmm is roughly dead, maybe you
> could resurrect it? It is a wunderful thing, apart from those glitches...

I support Martin. It is really annoying that I have to add %$ after the 
end of a code chunk if the code chunk contained an odd number of $'s. 
That only happens in XEmacs. but Martin has similar problems with the 
double quotes although they seem to be paired correctly.

If you or some other on this mailing list could find the bug in mmm-mode 
that would really be wonderful. Martin and me could probably put 
together a demonstration file for this syntax-highlighting problem.

\start
Date: Fri, 16 Feb 2007 15:03:27 -0600
From: Tim Daly
To: Cliff Yapp
Subject: lisp lisp noweb speed issue

> is this something you think can be used in Axiom?

Yes, I do. This debate has raged before on this list but I
believe that we need a lisp version of noweb for several reasons.
Your opinions may vary.

1) the )compile command needs to understand pamphlets directly
2) we need tighter integration of the interpreter and documentation
3) the build process will eventually be lisp-only (controversy)
4) we need to be able to experiment with pamphlet formats for new ideas
5) noweb slows considerably as the files get larger, apparently due to
   the shell pipe of data from process to process.
   (my work pamphlet is now 6M lines, (4k pages of doc, 67k lines of lisp))

\start
Date: Fri, 16 Feb 2007 14:06:25 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: lisp lisp noweb speed issue

--- Tim Daly wrote:

> > is this something you think can be used in Axiom?
> 
> Yes, I do. This debate has raged before on this list but I
> believe that we need a lisp version of noweb for several reasons.

What would you consider as the minimal features required to include
cl-notangle (or cl-noweb as the case may be) in Axiom?  I would like to
know what the key minimal requirements are so I know what to shoot for
first.

> 1) the )compile command needs to understand pamphlets directly

Agreed.

> 2) we need tighter integration of the interpreter and documentation

Not sure quite how that works but it sounds good.

> 3) the build process will eventually be lisp-only (controversy)

This is my main reason for wanting notangle in lisp.  Is the eventual
goal of building in lisp controversial?  My understanding is
all-in-lisp is regarded as the best (most portable) way to handle this
process, but the tools were/are lacking - perhaps with notangle in lisp
(and eventually noweb) we can achieve this.  The only catch is that we
can't be lisp only if we need to build GCL first, but at least once we
have a running lisp everything else can be lisp.  The news that we are
close to replacing old boot with new boot (which is simpler to get
working in ANSI lisp) and an sbcl port are two major pieces of the
puzzle, so I'm trying to add notangle and an asdf based loading system
as the other missing pieces.  

> 4) we need to be able to experiment with pamphlet formats for new
> ideas

Yes - I would like to see the default Axiom pamphlet output a little
different (fancier) than it is now (now there's controversy ;-)

> 5) noweb slows considerably as the files get larger, apparently due
> to
>    the shell pipe of data from process to process.
>    (my work pamphlet is now 6M lines, (4k pages of doc, 67k lines of
> lisp))

Tim, out of curosity how does this version (suboptimal I know) compare
with noweb on that really large file?  I'm sure the read commands will
be a killer but it shouldn't be piping data around, at least.  (Dunno
if it works in GCL, I've only tested it on sbcl).

\start
Date: Fri, 16 Feb 2007 14:11:15 -0800 (PST)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: A first attempt at a notangle in Lisp

--- Ralf Hemmecke wrote:

> I support Martin. It is really annoying that I have to add %$ after
> the end of a code chunk if the code chunk contained an odd number of
> $'s. That only happens in XEmacs. but Martin has similar problems
> with the double quotes although they seem to be paired correctly.

I think it's basically that the coloring function for Emacs's syntax
highlighting doesn't skip chunks in mmm-mode when deciding how to
highlight things.  That's what would need to be fixed, and it may be
rather non-trivial (but worthwhile) to fix it.  I have a feeling it may
wind up being the case that mmm-mode serves as a guide for a new
literate programming mode, rather than being a fix to mmm-mode - we
will see.  My major concern is that that behavior of Emacs's syntax
highlighting is not user configurable at all, but I don't know enough
to say.

> If you or some other on this mailing list could find the bug in
> mmm-mode that would really be wonderful. Martin and me could
> probably put together a demonstration file for this syntax-
> highlighting problem.

I've seen it before on the $ symbol, in Emacs.  I'll have a look and
see what can be done, but it may be a slow process.

\start
Date: 16 Feb 2007 23:21:46 +0100
From: Martin Rubey
To: Cliff Yapp
Subject: Re: pamphlets

Dear all,

I keep repeating it.

> > 4) we need to be able to experiment with pamphlet formats for new ideas

BEFORE you start developing new ideas, PLEASE look at ALLPROSE. for example by
checking out aldor-combinat

-------------------------------------------------------------------------------
svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk

cd combinat/trunk/combinat

notangle -t8 Makefile.nw > Makefile

make dvi

or

make colored dvi

or, if you have tex4ht installed,

make colored html
-------------------------------------------------------------------------------

It does not make sense to reinvent the wheel. A lot of though has gone into
ALLPROSE, and it proved *very* convenient. Note that aldor-combinat is *not* a
small project. I did use ALLPROSE also for very small projects, by the way. It
just works.

\start
Date: 16 Feb 2007 23:23:30 +0100
From: Martin Rubey
To: list
Subject: Summer of code

I just came across

http://code.google.com/support/bin/answer.py?answer=60302&topic=10727

So, who is going to prepare the application for google SOC?

If nobody volonteers, I'll do it. I'd propose a HyperDoc replacement using the
ALLPROSE format.

\start
Date: Fri, 16 Feb 2007 18:00:53 -0500
From: Cliff Yapp
To: Martin Rubey
Subject: Re: pamphlets

Martin Rubey wrote:
> Dear all,
> 
> I keep repeating it.
> 
>>> 4) we need to be able to experiment with pamphlet formats for new ideas
> 
> BEFORE you start developing new ideas, PLEASE look at ALLPROSE. for example by
> checking out aldor-combinat
> 
> -------------------------------------------------------------------------------
> svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk
> 
> cd combinat/trunk/combinat
> 
> notangle -t8 Makefile.nw > Makefile
> 
> make dvi
> 
> or
> 
> make colored dvi

Martin, I'm failing on the latter command with:

! TeX capacity exceeded, sorry [grouping levels=255].
\@textcolor #1#2#3->\protect \leavevmode {
                                           \color #1{#2}#3}
l.148 ...YVERSION}}\\{{projectname}{projectname}}}
 
\nwindexuse{LIBRARYVERSION...

Do I need to tweak a texmf.cnf setting or some such?

\start
Date: 16 Feb 2007 17:16:43 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [437] branches/wh-sandbox

Waldek Hebisch writes:

[...]

| Modified: branches/wh-sandbox/ChangeLog.wh
| ===================================================================
| --- branches/wh-sandbox/ChangeLog.wh	2007-02-16 10:31:28 UTC (rev 436)
| +++ branches/wh-sandbox/ChangeLog.wh	2007-02-16 21:41:44 UTC (rev 437)
| @@ -1,3 +1,22 @@
| +2007-02-16  Waldek Hebisch  Waldek Hebisch
| +
| +	Build depsys using Shoe.
| +	* src/interp/Makefile.pamphlet: Use bootsys to translate
| +	depsys boot files.  Do not include c-util in depsys.
| +	* src/interp/Makefile.in: Regenerate.
| +	* src/interp/c-util.boot.pamphlet: Remove bootstrap Lisp.
| +	* src/interp/clam.boot.pamphlet: Adjust for Shoe, remove
| +	bootstrap Lisp.
| +	* src/interp/g-boot.boot.pamphlet: Likewise.
| +	* src/interp/g-util.boot.pamphlet: Likewise.
| +	* src/interp/interp-proclaims.lisp: Likewise.
| +	* src/interp/parse.boot.pamphlet: Likewise.
| +	* src/interp/postpar.boot.pamphlet: Likewise.
| +	* src/interp/slam.boot.pamphlet: Likewise.
| +	* src/interp/vmlisp.lisp.pamphlet: AXIOM-MEMBER: new function
| +	* src/interp/interp-proclaims.lisp: Mention it.
| +	* src/interp/sys-pkg.lisp.pamphlet: Likewise.

Interesting.  I had similar (and more) patches like that in my local
tree as of 2006-12-26.  I never committed it because there was a small
catch -- which I can't explain right now because I don't have all the
elements handy :-(  Good to see someone is catching on :-)

\start
Date: Sat, 17 Feb 2007 00:36:30 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: pamphlets

>> make colored dvi

> Martin, I'm failing on the latter command with:

> ! TeX capacity exceeded, sorry [grouping levels=255].
> \@textcolor #1#2#3->\protect \leavevmode {
                                             \color #1{#2}#3}
> l.148 ...YVERSION}}\\{{projectname}{projectname}}}

> \nwindexuse{LIBRARYVERSION...

> Do I need to tweak a texmf.cnf setting or some such?

I don't know exactly what you have done, and although I have increase my 
pool sizes locally, it is very probably not the reason for the problem.

I guess, there might be something missing on your computer.
Maybe you first install "packaged-allprose" from

http://www.risc.uni-linz.ac.at/people/hemmecke/aldor/allprose/index.html

in particular you should install the newest version of srcltx.sty. 
ALLPROSE needs at least version 1.4. (I have the suspicion that this 
could be the reason for this strange error message.)

Try first srcltx and then packaged-allprose. Then let me know.

\start
Date: Sat, 17 Feb 2007 00:40:11 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [437] branches/wh-sandbox

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> [...]
> 
> | Modified: branches/wh-sandbox/ChangeLog.wh
> | ===================================================================
> | --- branches/wh-sandbox/ChangeLog.wh	2007-02-16 10:31:28 UTC (rev 436)
> | +++ branches/wh-sandbox/ChangeLog.wh	2007-02-16 21:41:44 UTC (rev 437)
> | @@ -1,3 +1,22 @@
> | +2007-02-16  Waldek Hebisch  Waldek Hebisch
> | +
> | +	Build depsys using Shoe.
> | +	* src/interp/Makefile.pamphlet: Use bootsys to translate
> | +	depsys boot files.  Do not include c-util in depsys.
> | +	* src/interp/Makefile.in: Regenerate.
> | +	* src/interp/c-util.boot.pamphlet: Remove bootstrap Lisp.
<snip>
> Interesting.  I had similar (and more) patches like that in my local
> tree as of 2006-12-26.  I never committed it because there was a small
> catch -- which I can't explain right now because I don't have all the
> elements handy :-(  Good to see someone is catching on :-)
> 

The patch is more tricky than it looks like: greping for suspected
keywords give tons of false positives and in first shot I missed few
places (and I dicovered that a few more bad keywords).  And I still
use depsys for to translate c-util (trying to use bootsys gives me
some misterious errors).

I have checked that resulting Lisp (output from depsys and interpsys)
is identical (modulo gensymed names) so the patch works reasonably,
but there is still risk of bugs in rarely used code.

\start
Date: Sat, 17 Feb 2007 09:04:01 -0500
From: Cliff Yapp
To: list
Subject: mmm-noweb and fontification

In case this triggers a flag for anybody, it looks like this might
be what we need (or mmm-mode needs anyway) to fontify in such a way
that chunks are avoided:

;;; Fontification functions.

;; Rather than the function, e.g., `font-lock-fontify-region' containing
;; the code to fontify a region, the function runs the function whose
;; name is the value of the variable, e.g.,
;; `font-lock-fontify-region-function'.  Normally, the value of this
;; variable is, e.g., `font-lock-default-fontify-region'
;; which does contain the code to fontify a region.  However, the value
;; of the variable could be anything and thus, e.g.,
;;`font-lock-fontify-region' could do anything.  The indirection of the
;; fontification functions gives major modes the capability of modifying
;; the way font-lock.el fontifies.  Major modes can modify the values
;; of, e.g., `font-lock-fontify-region-function',
;; via the variable `font-lock-defaults'.

;; Languages that contain text normally contained in different major
;; modes could define their own fontification functions that treat text
;; differently depending on its context.  For example, Perl mode could
;; arrange that here docs are fontified differently than Perl code.  Or
;; Yacc mode could fontify rules one way and C code another.  Neat!

That sounds like the ticket, now to figure out how to use it!

\start
Date: Sun, 18 Feb 2007 00:10:37 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: Lisp format in sf.spad.pamphlet

> Hello,
> 
> I have introduced two bugs in DFLOAT when I sent a patch against
> sf.spad.pamphlet (outputting routine). Try, for example,
> complex(1.7,-2.3@SF) or 3.0*x^3+-2.7@SF*x^2. Furthermore, the directive
> used ("~G") is not "the" good one (it's not portable, the directive
> works this way only on GCL). Patch in attachment (I have used the Float
> method (via 'message')).
> 
> A suggestion, what about using )spool to produce *.output file?
> (to simplify the comparison via diff of two versions of Axiom (different
> banners)).
> 
> Greg
> 
> PS : Tested on Gold and Build-improvements (should work on Wh-sandbox, I
> think). My tests were : building from scratch, tracing outputTran and
> testing all outputting formats (algebra, fortran, tex etc...).

Included now in wh-sandbox (the Lisp part was not needed, since wh-sandbox
now contains no algebra bootstrap Lisp).

\start
Date: Sat, 17 Feb 2007 15:58:03 -0800 (PST)
From: Cliff Yapp
To: list
Subject: No progress on notangle :-(

I have tried to use read-sequence to load a file quickly, which works
fine, but I'm afraid I haven't done too well with the problem of
working with the resulting string.  The code so far is actually slower
than the earlier version, and from what I can tell the primary issue
seems to be too many subseq operations on the big one-pamphlet string. 
I tried leaving the string intact and just identifying positions rather
than chopping it off as I scanned, but the searches got progressively
more expensive even though I was supplying new start positions. 
There's probably a better way to do it or an obvious mistake in the way
I have done it, but I'm afraid I've been staring at it a bit too long. 

(defvar startchars "<<")
(defvar endchars ">>=")
(defvar endchunkchars "@")
(defvar refstartchars "<<")
(defvar refendchars ">>") 

(defparameter *chunk-hash-table* (make-hash-table :test 'equal))

(defclass chunk ()
  ((chunk-name
    :initarg :chunk-name
    :initform (error "Must supply a chunk name.")
    :reader chunk-name
    :documentation "Name of chunk.")
   (chunk-contents
    :initarg :chunk-contents
    :initform ""
    :accessor chunk-contents
    :documentation "Text of chunk - may include references to other
chunks")))

(defun make-new-chunk (curr-chunk-name curr-chunk-contents)
  (setf (gethash curr-chunk-name *chunk-hash-table*) 
        (make-instance 'chunk :chunk-name curr-chunk-name
:chunk-contents curr-chunk-contents)))

(defun get-chunk-contents (curr-chunk-name)
  (chunk-contents (gethash curr-chunk-name *chunk-hash-table*)))

(defun view-all-chunks ()
  (maphash #'(lambda (k v) (format t "~a => ~a~%" k v))
*chunk-hash-table*))

(defun check-for-referenced-chunk (inputstring startpos)
   (let ((pos1 (search refstartchars inputstring :start2 startpos)))
     (let ((pos2 (if pos1 (search refendchars inputstring :start2
pos1))))
       (if (and pos1 pos2)
           (progn
           (if (search (string #\Newline) inputstring :start2 pos1 
                                                      :end2 pos2)
             (check-for-referenced-chunk inputstring 
                   (+(search (string #\Newline) inputstring :start2
pos1
                                                            :end2 pos2)
1) )
             (progn
               (let ((middlestring (subseq inputstring 
                                           (+ pos1 (length
refstartchars)) 
                                           pos2)))
                 (if (gethash middlestring *chunk-hash-table*)
                     (progn
                       (setf inputstring 
                             (concatenate 'string
                                          (subseq inputstring 0 pos1)
                                          (get-chunk-contents
middlestring)
                                          (subseq inputstring 
                                                  (+ pos2 (length
refendchars)))))
                       (check-for-referenced-chunk inputstring pos1))
                     (error  "~S was not found in hash table."
middlestring))))))
           inputstring))))

(defun check-for-newline-in-name (endofname pamphletfile)
   (let ((newlinepos (search (string #\Newline) pamphletfile :end2
endofname :from-end t))
	 (startcharspos (search startchars pamphletfile :end2 endofname
:from-end t)))
     (if newlinepos
	 (if (> newlinepos startcharspos) t))))

(defun find-next-chunk (startingpoint pamphletfile)
  (let ((endofname  (search endchars pamphletfile :start2
startingpoint))
	(startofname) (startofbody) (endofbody))
    (if endofname
	 (if (check-for-newline-in-name endofname pamphletfile)
	     (find-next-chunk (+ endofname (length endchars)) pamphletfile)
	   (progn
	     (setf startofname (+ (length startchars) (search startchars
pamphletfile :end2 endofname :from-end t)))
	     (setf startofbody (+ (length endchars) endofname 1))
	     (setf endofbody (+ 1 (search (concatenate 'string (string
#\Newline) endchunkchars) pamphletfile :start2 endofname)))
	     (if (and startofname endofname startofbody endofbody) 
		 (list startofname endofname startofbody endofbody)))))))

(defun file-to-string (filename)
  (let ((openfile (open filename :if-does-not-exist nil)))
  (let ((fileasstring (make-array (file-length openfile) :element-type
'character :fill-pointer t)))
    (setf (fill-pointer fileasstring) (read-sequence fileasstring
openfile))
    (close openfile)
    fileasstring)))

(defun load-pamphlet-file (filename)
  (let ((pamphletfile (file-to-string filename)))
    (let ((checkedlength 0)
	  (totallength (length pamphletfile))
	  (chunkpositions (find-next-chunk 0 pamphletfile)))
     (if chunkpositions
	 (progn
	   (do ()
	       ((> checkedlength totallength))
	     (progn 
	       (make-new-chunk (subseq pamphletfile (first chunkpositions)
(second chunkpositions))
			       (subseq pamphletfile (third chunkpositions) (fourth
chunkpositions)))
	       (setf pamphletfile (subseq pamphletfile (fourth
chunkpositions)))
	       (setf chunkpositions (find-next-chunk 0 pamphletfile))
	       (if (not chunkpositions) (setf checkedlength (+ 1
totallength)))))
	   )
	 (error "No code chunks found.  Perhaps delimiters are
incorrect?")))))

(defun write-output-file (filename chunkname)
  (let ((outputstream (open filename :direction :output :if-exists
:supersede)))
    (write-string (check-for-referenced-chunk 
                   (get-chunk-contents chunkname) 0) outputstream)
    (close outputstream)))

(defun notangle (fileinname fileoutname &optional (chunkname "*"))
  (clrhash *chunk-hash-table*)
  (load-pamphlet-file fileinname)
  (write-output-file fileoutname chunkname)
  (clrhash *chunk-hash-table*))

\start
Date: Sat, 17 Feb 2007 16:22:31 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Minor cleanup on working version

Forgot to add Waldek's name to the lisp level copyright notice.  Also
changed the exception for the end-of-chunk-body character to look for
it not in the first column, rather than for a double quite before it
(like the perl version.)

v0.3 attached.

--0-2090592225-1171758151=:52761

XGRvY3VtZW50Y2xhc3N7YXJ0aWNsZX0gClx1c2VwYWNrYWdle2F4aW9tfQpc
YmVnaW57ZG9jdW1lbnR9Clx0aXRsZXtjbC1ub3RhbmdsZSB2MC4zIC0gYSBM
aXRlcmF0ZSBQcm9ncmFtIENvZGUgRXh0cmFjdG9yIGZvciBBTlNJIENvbW1v
biBMaXNwfSAKXGF1dGhvcntDbGlmZm9yZCBZYXBwLCBXYWxkZWsgSGViaXNj
aH0KXG1ha2V0aXRsZQpcYmVnaW57YWJzdHJhY3R9CiAgTk9XRUIgaXMgdGhl
IGNsYXNzaWMgbGFuZ3VhZ2UgYWdub3N0aWMgdG9vbCB1c2VkIGZvciBsaXRl
cmF0ZSBwcm9ncmFtbWluZwogIGluIHRoZSBzdHlsZSBvZiBLbnV0aCdzIG9y
aWdpbmFsIFdFQi4gIFRoaXMgdG9vbCBpbXBsZW1lbnRzIGEgbWV0aG9kIGlu
CiAgbGlzcCBmb3IgZXh0cmFjdGluZyB0aGUgc291cmNlIGNvZGUgZnJvbSBs
aXRlcmF0ZSBkb2N1bWVudHMuClxlbmR7YWJzdHJhY3R9ClxlamVjdApcdGFi
bGVvZmNvbnRlbnRzClxlamVjdAoKXHNlY3Rpb257VXBkYXRlc30KClxub2lu
ZGVudCBcdmVyYkAoMi8xNS8wNylAIC0gSW5pdGlhbCB2MC4xIHJlbGVhc2Vk
Clxub2luZGVudCBcdmVyYkAoMi8xNi8wNylAIC0gV2FsdGVyIEhlYmlzY2gg
cHJvdmlkZXMgbGluZWFyIHRpbWUgcmVhZC1pbi1jaHVuawpcbm9pbmRlbnQg
XHZlcmJAKDIvMTcvMDcpQCAtIE1pbm9yIGNoYW5nZSB0byBjaGVjayBmb3Ig
QCBjaGFyYWN0ZXIsIGNvcHlyaWdodCBmaXgKClxzZWN0aW9ue0NvcHlyaWdo
dCBhbmQgTGljZW5zZX0KCiBUaGlzIHByb2dyYW0gaXMgYXZhaWxhYmxlIHVu
ZGVyIHRoZSBNb2RpZmllZCBCU0QgbGljZW5zZS4gIFRoZSB3b3JkaW5nCiBv
ZiB0aGUgZmlsZSB3YXMgY2hhbmdlZCBzbGlnaHRseSwgYXMgdGhlcmUgaXMg
bm8gb3JnYW5pemF0aW9uIGFzc29jaWF0ZWQKIHdpdGggdGhlIGNyZWF0aW9u
IG9mIHRoaXMgZmlsZSwgYnV0IGlmIHRoZXJlIGlzIGFueSBxdWVzdGlvbiB0
aGUgbGljZW5zZQogaXMgaW50ZW5kZWQgdG8gYmUgTW9kaWZpZWQgQlNELgoK
PDxjb3B5cmlnaHQ+Pj0KOzsgQ29weXJpZ2h0IChjKSAyMDA3LCBDbGlmZm9y
ZCBZYXBwLCBXYWxkZWsgSGViaXNjaAo7OyBBbGwgcmlnaHRzIHJlc2VydmVk
LgoKQAoKPDxsaWNlbnNlPj49Cjs7IFJlZGlzdHJpYnV0aW9uIGFuZCB1c2Ug
aW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAo7
OyBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0
aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlCjs7IG1ldDoKOzsKOzsgICAg
LSBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4g
dGhlIGFib3ZlIGNvcHlyaWdodAo7OyAgICAgIG5vdGljZSwgdGhpcyBsaXN0
IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4K
OzsKOzsgICAgLSBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVz
dCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAo7OyAgICAgIG5vdGlj
ZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcg
ZGlzY2xhaW1lciBpbgo7OyAgICAgIHRoZSBkb2N1bWVudGF0aW9uIGFuZC9v
ciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUKOzsgICAgICBk
aXN0cmlidXRpb24uCjs7Cjs7ICAgIC0gVGhlIG5hbWVzIG9mIHRoZSBjb250
cmlidXRvcnMgbWF5IG5vdCBiZSB1c2VkIHRvIGVuZG9yc2Ugb3IgcHJvbW90
ZQo7OyAgICAgIHByb2R1Y3RzIGRlcml2ZWQgZnJvbSB0aGlzIHNvZnR3YXJl
IHdpdGhvdXQgc3BlY2lmaWMgcHJpb3Igd3JpdHRlbgo7OyAgICAgIHBlcm1p
c3Npb24uCjs7Cjs7VEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUg
Q09QWVJJR0hUIEhPTERFUlMgQU5EIENPTlRSSUJVVE9SUyAiQVMKOztJUyIg
QU5EIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVE
SU5HLCBCVVQgTk9UIExJTUlURUQKOztUTywgVEhFIElNUExJRUQgV0FSUkFO
VElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEKOztQ
QVJUSUNVTEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuIElOIE5PIEVWRU5U
IFNIQUxMIFRIRSBDT1BZUklHSFQgT1dORVIKOztPUiBDT05UUklCVVRPUlMg
QkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRB
TCwgU1BFQ0lBTCwKOztFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFN
QUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sCjs7UFJPQ1VS
RU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUyBPUiBTRVJWSUNFUzsgTE9TUyBP
RiBVU0UsIERBVEEsIE9SCjs7UFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJS
VVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRgo7
O0xJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJ
TElUWSwgT1IgVE9SVCAoSU5DTFVESU5HCjs7TkVHTElHRU5DRSBPUiBPVEhF
UldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWSBPVVQgT0YgVEhFIFVTRSBPRiBU
SElTCjs7U09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lC
SUxJVFkgT0YgU1VDSCBEQU1BR0UuCgpAIAoKXGVqZWN0ClxzZWN0aW9ue0lu
dHJvZHVjdGlvbiAtIE5PV0VCIGFuZCBMaXRlcmF0ZSBQcm9ncmFtbWluZ30K
ClRoZSBjb25jZXB0IG9mIExpdGVyYXRlIFByb2dyYW1taW5nIHRyYWNlcyBi
YWNrIHRvIERvbmFsZCBLbnV0aCwgdGhlIGF1dGhvcgpvZiB0aGUgVGVYIHR5
cGVzZXR0aW5nIHN5c3RlbSBhbmQgQ1dFQi4gIFRoZSBmdW5kYW1lbnRhbCBp
ZGVhIG9mIGxpdGVyYXRlIApwcm9ncmFtbWluZyBpcyB0byBkZXZlbG9wIHRo
ZSBjb2RlIGFuZCBkb2N1bWVudGF0aW9uIGFzIG9uZSBpbnRlZ3JhdGVkIHdo
b2xlIAotIHJhdGhlciB0aGFuIGhhdmluZyBzb3VyY2UgY29kZSBpbiBvbmUg
ZmlsZSBhbmQgZG9jdW1lbnRhdGlvbiBpbiBhbm90aGVyIHRoZSAKdHdvIGFy
ZSB3b3ZlbiB0b2dldGhlci4gIFRoaXMgcGxhY2VzIHRoZSBlbXBoYXNpcyBv
biBpZGVhcyBtb3JlIHRoYW4gY29kZSwgYW5kIAppcyBpbnRlbmRlZCB0byBl
bmNvdXJhZ2UgdGhlIGNyZWF0aW9uIG9mIHByb2dyYW1zIHRoYXQgd2lsbCBi
ZSB1bmRlcnN0YW5kYWJsZSAKYW5kIHVzYWJsZSBhcyBsb25nIGFzIHRoZSBp
ZGVhcyBiZWhpbmQgdGhlIGRlc2lnbiBpdHNlbGYgYXJlIHZhbGlkLgoKT25l
IG9mIHRoZSBwcmFjdGljYWwgY29uc2VxdWVuY2VzIG9mIHRoaXMgaWRlYSBp
cyB0aGF0IGluIG9yZGVyIGZvciB0aGUgY29kZSAKaW4gYSBsaXRlcmF0ZSBk
b2N1bWVudCB0byBiZSBsb2FkZWQgaW50byBhIG1hY2hpbmUsIGl0IG11c3Qg
YmUgZXh0cmFjdGVkIGZyb20gCnRoZSBkb2N1bWVudC4gVGhpcyBpcyBmdXJ0
aGVyIGNvbXBsaWNhdGVkIGJ5IHRoZSBlbXBoYXNpcyBvZiBsaXRlcmF0ZSAK
cHJvZ3JhbW1pbmcgb24gaWRlYXMgcmF0aGVyIHRoYW4gY29kZSBkaWN0YXRp
bmcgdGhlIG9yZGVyIG9mIGEgcHJvZ3JhbW1lcidzIAp3b3JrLiAgV0VCIGRv
Y3VtZW50cyB0aHVzIGFyZSBub3Qgb25seSBpbnRlcndvdmVuIHRleHQgYW5k
IHNvdXJjZSBjb2RlLCBidXQgCmhhdmUgY2h1bmtzIG9mIGNvZGUgZGVmaW5l
ZCBhdCBhcmJpdHJhcnkgcG9pbnRzIGluIHRoZSBkb2N1bWVudC4gIFRoZXJl
IGlzIAp1c3VhbGx5IGEgcm9vdCBjaHVuayB3aGljaCBwbGFjZXMgdGhlIGlu
ZGl2aWR1YWwgcGllY2VzIGluIHRoZSBjb3JyZWN0IG9yZGVyLCAKYnV0IGVh
Y2ggcGllY2UgbWF5IGluIHR1cm4gcmVmZXJlbmNlIG90aGVyIHBpZWNlcyBh
bmQgYWxsIG9mIHRoZW0gbXVzdCBiZSAKZXZlbnR1YWxseSBwdXQgaW4gdGhl
IGNvcnJlY3Qgc2VxdWVuY2UgdG8gYWxsb3cgdGhlIG1hY2hpbmUgdG8gcmVh
ZCB0aGVtLgoKSW4gTk9XRUIsIHRoZSBzcGVjaWZpYyBjb21tYW5kIHRoYXQg
ZG9lcyB0aGlzIGpvYiBpcyBjYWxsZWQgbm90YW5nbGUuICBUaGVyZSAKYXJl
IG90aGVyIGNvbW1hbmRzIHRoYXQgcHJvY2VzcyB0aGUgZG9jdW1lbnQgaW50
byB2YXJpb3VzIG91dHB1dCBmb3JtcywgYnV0IApmcm9tIHRoZSBzdGFuZHBv
aW50IG9mIHRoZSBtYWNoaW5lIHVuZGVyc3RhbmRpbmcgdGhlIGNvZGUgbm90
YW5nbGUgaXMgdGhlIAptb3N0IGNyaXRpY2FsLgoKSGVyZSwgd2Ugd2lsbCBp
bXBsZW1lbnQgYSB3YXkgaW4gbGlzcCB0byBsb2FkIGEgcGFtcGhsZXQgZmls
ZSwgQXhpb20ncyBmb3JtIApvZiBsaXRlcmF0ZSBwcm9ncmFtbWluZyBkb2N1
bWVudCwgYW5kIGV4dHJhY3QgdGhlIGNvZGUgZnJvbSBpdC4KCgpcc2VjdGlv
bntUaGUgVG9wIExldmVsIEZpbGUgU3RydWN0dXJlfQoKPDwqPj49Cjw8Y29w
eXJpZ2h0Pj4KPDxsaWNlbnNlPj4KPDxkZWxpbWl0ZXJzPj4KPDxoYXNodGFi
bGU+Pgo8PGNodW5rY2xhc3M+Pgo8PGJhc2ljLWNodW5rLW9wZXJhdGlvbnM+
Pgo8PHJlYWRpbi1jaHVuaz4+Cjw8dG9wbGV2ZWwtY2h1bmstc2Nhbm5pbmc+
Pgo8PHJlZmVyZW5jZS1jaHVuay1zY2FubmluZz4+Cjw8bG9hZC1maWxlPj4K
PDx3cml0ZS1maWxlPj4KPDxub3RhbmdsZT4+CkAgCgpcc2VjdGlvbntJbml0
aWFsIERlZmluaXRpb25zfQoKVGhlIG1vc3QgaW1wb3J0YW50IHBpZWNlcyBv
ZiBpbmZvcm1hdGlvbiBuZWVkZWQgd2hlbiB1bnRhbmdsaW5nIGEgZmlsZSBh
cmUgCnRoZSBkZWxpbWl0aW5nIHN0cmluZ3MgdXNlZCB0byBpZGVudGlmeSBw
YXJ0cyBvZiBhIGNodW5rLiAgQXMgYSBydWxlLCBjaHVua3MgCmNvbnNpc3Qg
b2YgYSBuYW1lLCBhIGJvZHksIGFuZCBhbiBlbmQgb2YgY2h1bmsgY2hhcmFj
dGVyIHdoaWNoIHNpZ25pZmllcyB0aGUgCmVuZCBvZiB0aGUgY29kZS4gIEhv
d2V2ZXIsIGJlY2F1c2UgY2h1bmtzIG1heSBhbHNvIHJlZmVyZW5jZSBvdGhl
ciBjaHVua3MsIAp0aGVyZSBhbHNvIG5lZWQgdG8gYmUgY2h1bmsgcmVmZXJl
bmNlIGZsYWdzIHRoYXQgY2FuIGJlIHNlZW4gaW5zaWRlIHRoZSBib2R5IApp
dHNlbGYuICBBeGlvbSBjb252ZW50aW9ucyBhcmUgdXNlZCBoZXJlIGZvciB0
aGUgZGVmYXVsdHMsIGJ1dCBvdGhlcnMgYXJlIApjZXJ0YWlubHkgcG9zc2li
bGUgYW5kIGNhbiBiZSBhY2hpZXZlZCBieSBzaW1wbHkgcmUtZGVmaW5pbmcg
dGhlc2UgdmFyaWFibGVzLiAgCk5vdGUsIGhvd2V2ZXIsIHRoYXQgY29sbGlz
aW9ucyBiZXR3ZWVuIGRlbGltaXRlcnMgYXQgdGhlIHNhbWUgbGV2ZWxzIChz
YXksIAp0aGUgZW5kaW5nIGNoYXJhY3RlcnMgZm9yIHRoZSBuYW1lIG9mIHRo
ZSBjaHVuayBhbmQgdGhlIGVuZCBvZiBjaHVuayBib2R5IApjaGFyYWN0ZXIs
IG9yIHRoZSB0d28gZGVsaW1pdGVycyB1c2VkIGluc2lkZSB0aGUgYm9keSBm
b3IgcmVmZXJlbmNlcykgd2lsbCAKYWxtb3N0IGNlcnRhaW5seSBwcmV2ZW50
IGNvcnJlY3QgcGFyc2luZyBvZiB0aGUgZmlsZS4KCjw8ZGVsaW1pdGVycz4+
PQooZGVmdmFyIHN0YXJ0Y2hhcnMgIjw8IikKKGRlZnZhciBlbmRjaGFycyAi
Pj49IikKKGRlZnZhciBlbmRjaHVua2NoYXJzICJAIikKKGRlZnZhciByZWZz
dGFydGNoYXJzICI8PCIpCihkZWZ2YXIgcmVmZW5kY2hhcnMgIj4+IikgCgpA
CgpXaGVuIHJlYWRpbmcgaW4gY2h1bmtzIGFuZCBzdG9yaW5nIHRoZW0sIGEg
aGFzaCB0YWJsZSBpcyB1c2VkLiAgV2UgaW5pdGlhbGl6ZSAKdGhhdCB0YWJs
ZSBhdCB0aGUgYmVnaW5uaW5nLCBzaW5jZSBpdCBpcyB1c2VkIHRocm91Z2hv
dXQgdGhlIHByb2dyYW0uICBBbiAKaW1wb3J0YW50IGZlYXR1cmUgdG8gbm90
ZSBoZXJlIGlzIHRoYXQgdGhpcyBoYXNoIHRhYmxlIHVzZXMgdGhlIGBgZXF1
YWwnJyAKZnVuY3Rpb24gZm9yIGVxdWFsaXR5IHRlc3RpbmcsIHdoaWNoIGlz
IG5lY2Vzc2FyeSBmb3IgdGhlIGhhc2ggdGFibGUgdG8gd29yayAKd2l0aCBz
dHJpbmcga2V5cy4gIENodW5rIG5hbWVzIGFyZSBzdHJpbmdzLCBhbmQgYSBk
ZWZhdWx0IGhhc2ggdGFibGUgCmNvbmZpZ3VyYXRpb24gaW4gTGlzcCB3aWxs
IG5vdCBhY2NlcHQgdGhlbS4KCjw8aGFzaHRhYmxlPj49CihkZWZwYXJhbWV0
ZXIgKmNodW5rLWhhc2gtdGFibGUqIChtYWtlLWhhc2gtdGFibGUgOnRlc3Qg
J2VxdWFsKSkKCkAKClxzZWN0aW9ue0NodW5rIHN0cnVjdHVyZSBpbiBDTE9T
fQoKQ0xPUyAodGhlIENvbW1vbiBMaXNwIE9iamVjdCBTeXN0ZW0pIHByb3Zp
ZGVzIGV4Y2VsbGVudCB0b29scyBmb3IgZGF0YSAKc3RydWN0dXJlIGNyZWF0
aW9uIGFuZCBtYW5pcHVsYXRpb24uICBXZSB3aWxsIG1ha2Ugb25seSBtaW5v
ciB1c2Ugb2YgaXQgaGVyZSwgCnRvIGRlZmluZSBhIGRhdGEgc3RydWN0dXJl
IHRoYXQgd2lsbCBob2xkIGNodW5rcyBhcyB0aGV5IGFyZSByZWFkIGluIGFu
ZCAKcGFyc2VkLiAgKEl0IGlzIHBlcmhhcHMgbm90IHN0cmljdGx5IG5lY2Vz
c2FyeSB0byBpbmNsdWRlIHRoZSBjaHVuayBuYW1lIGluIAp0aGUgZGF0YSBz
dHJ1Y3R1cmUsIHNpbmNlIHRoZSBoYXNoIGNvZGUgaXMgYWxzbyB0aGUgY2h1
bmsgbmFtZS4pIFRoaXMgCmRlZmluaXRpb24gd2lsbCBhbHNvIGF1dG9tYXRp
Y2FsbHkgcHJvZHVjZSBmdW5jdGlvbnMgdG8gbWFuaXB1bGF0ZSB0aGUgCnN0
cnVjdHVyZXMgd2l0aGluIHRoZSBjbGFzcywgYWx0aG91Z2ggd2Ugd2lsbCBk
ZWZpbmUgY29udmVuaWVuY2UgZnVuY3Rpb25zIApmb3IgdGhvc2Ugb3BlcmF0
aW9ucyBsYXRlci4gVGhlIGNvbnRlbnRzIG9mIHRoZSBjaHVuayBhcmUgaW5p
dGlhbGl6ZWQgdG8gdGhlIAplbXB0eSBzdHJpbmcuCgo8PGNodW5rY2xhc3M+
Pj0KKGRlZmNsYXNzIGNodW5rICgpCiAgKChjaHVuay1uYW1lCiAgICA6aW5p
dGFyZyA6Y2h1bmstbmFtZQogICAgOmluaXRmb3JtIChlcnJvciAiTXVzdCBz
dXBwbHkgYSBjaHVuayBuYW1lLiIpCiAgICA6cmVhZGVyIGNodW5rLW5hbWUK
ICAgIDpkb2N1bWVudGF0aW9uICJOYW1lIG9mIGNodW5rLiIpCiAgIChjaHVu
ay1jb250ZW50cwogICAgOmluaXRhcmcgOmNodW5rLWNvbnRlbnRzCiAgICA6
aW5pdGZvcm0gIiIKICAgIDphY2Nlc3NvciBjaHVuay1jb250ZW50cwogICAg
OmRvY3VtZW50YXRpb24gIlRleHQgb2YgY2h1bmsgLSBtYXkgaW5jbHVkZSBy
ZWZlcmVuY2VzIHRvIG90aGVyIGNodW5rcyIpKSkKCkAKClxzZWN0aW9ue0Jh
c2ljIENodW5rIE9wZXJhdGlvbnN9CgpUaGVyZSBhcmUgdGhyZWUgdGhpbmdz
IHdlIHdpbGwgbm9ybWFsbHkgbmVlZCB0byBkbyB3aXRoIGNodW5rczogIG1h
a2UgbmV3IApvbmVzLCByZWFkIHRoZSBjb250ZW50IG9mIGFscmVhZHkgZXhp
c3RpbmcgY2h1bmtzLCBhbmQgYWRkIGRhdGEgdG8gYWxyZWFkeSAKZXhpc3Rp
bmcgY2h1bmtzLiAgQ2h1bmsgYnVpbGRpbmcgZG9lcyBub3Qgbm9ybWFsbHkg
bmVlZCB0byByZW1vdmUgY29udGVudCAtIAptb3JlIHN1YnRsZSBtYW5pcHVs
YXRpb24gb2YgY29udGVudCBpcyBuZWVkZWQgZm9yIGhhbmRsaW5nIHJlZmVy
ZW5jZXMsIGJ1dCAKdGhhdCBpcyBkZWFsdCB3aXRoIGVsc2V3aGVyZS4KClxz
dWJzZWN0aW9ue05ldyBDaHVua3N9CgpBIG5ldyBjaHVuayBpcyBhbHdheXMg
YXNzdW1lZCB0byBiZSBlbXB0eSwgc28gd2Ugc2ltcGx5IHRha2UgYSBuYW1l
IGFyZ3VtZW50IAphbmQgaW5pdGlhbGl6ZSB0aGUgY2h1bmssIG1lcmdpbmcg
aXQgaW50byB0aGUgY2VudHJhbCBoYXNoIHRhYmxlIGFzIHdlIApjcmVhdGUg
aXQuICBUaGlzIG1lYW5zIHRoZSBjaHVuayBgYGxpdmVzJycgaW4gdGhlIGhh
c2ggdGFibGUgYW5kIGRvZXMgbm90IApleGlzdCBhcyBhIHZhcmlhYmxlIGlu
IHRoZSBMaXNwIGVudmlyb25tZW50LCBzbyB5b3Ugd2lsbCBuZXZlciB0eXBl
IApgYGNodW5rMScnIGFuZCBzZWUgdGhlIGNvbnRlbnRzIG9mIHRoZSBjaHVu
ay4KCjw8bmV3LWNodW5rPj49CihkZWZ1biBtYWtlLW5ldy1jaHVuayAoY3Vy
ci1jaHVuay1uYW1lKQogIChzZXRmIChnZXRoYXNoIGN1cnItY2h1bmstbmFt
ZSAqY2h1bmstaGFzaC10YWJsZSopIAoJKG1ha2UtaW5zdGFuY2UgJ2NodW5r
IDpjaHVuay1uYW1lIGN1cnItY2h1bmstbmFtZSkpKQoKQAoKXHN1YnNlY3Rp
b257UmVhZGluZyBDaHVuayBDb250ZW50c30KCkJlY2F1c2UgdGhlIGNodW5r
cyBhcmUgY29udGFpbmVkIGluIHRoZSBoYXNoIHRhYmxlLCB3ZSBuZWVkIGEg
d2F5IHRvIHN1cHBseSAKdGhlIG5hbWUgb2YgYSBjaHVuayBhbmQgcmV0cmll
dmUgdGhlIGNvbnRlbnRzLiAgTm90ZSB0aGF0IHRoaXMgcmV0dXJucyAKdGhl
IGxpdGVyYWwgc3RyaW5nIG9mIHRoZSBjaHVuayBhbmQgZG9lcyBub3Qgc3dh
cCBpbiBkZWZpbml0aW9ucyBmb3IgCnJlZmVyZW5jZXMuCgo8PGdldC1jaHVu
ay1jb250ZW50cz4+PQooZGVmdW4gZ2V0LWNodW5rLWNvbnRlbnRzIChjdXJy
LWNodW5rLW5hbWUpCiAgKGNodW5rLWNvbnRlbnRzIChnZXRoYXNoIGN1cnIt
Y2h1bmstbmFtZSAqY2h1bmstaGFzaC10YWJsZSopKSkKCkAKClxzdWJzZWN0
aW9ue0FkZGluZyBOZXcgQ29udGVudCB0byBDaHVua3N9CgpBcyB0aGUgZmls
ZSBpcyByZWFkIGluIGxpbmUgYnkgbGluZSwgd2UgZG9uJ3QgZGVmaW5lIGNo
dW5rIGNvbnRlbnRzIGluIGEgCnNpbmdsZSBgYGd1bHAnJyBidXQgb25lIGxp
bmUgYXQgYSB0aW1lLiAgU28gd2UgbmVlZCBhIGNvbnZlbmllbnQgd2F5IHRv
IGFkZCAKbmV3IGxpbmVzIHRvIHRoZSBjb250ZW50cyBvZiBhIGNodW5rIGtu
b3dpbmcgb25seSB0aGUgbmFtZSBvZiB0aGUgY2h1bmsgYW5kIAp0aGUgY29u
dGVudHMgdG8gYWRkLiAgVGhlIG9ubHkgbWlub3IgZGlmZmljdWx0eSBoZXJl
IGlzIHRoYXQgcmVhZC1saW5lIGluIApMaXNwIGRvZXNuJ3QgcHJlc2VydmUg
bmV3bGluZXMgYXMgcGFydCBvZiB0aGUgc3RyaW5nLCB3aGljaCBpcyBub3Jt
YWxseSB0aGUgCmRlc2lyZWQgYmVoYXZpb3IgYnV0IG5vdCB3aGF0IGlzIG5l
ZWRlZCBoZXJlLiAgU28gdGhlcmUgYXJlIHR3byBjYXNlcyAtIGluIAp0aGUg
aW5pdGlhbCBjYXNlIHdoZW4gdGhlIGNvbnRlbnRzIGFyZSBlbXB0eSB3ZSBz
aW1wbHkgYXNzaWduIHRoZSBzdHJpbmcgYXMKdGhlIG5ldyBjb250ZW50cy4g
IElmIHRoZSBjb250ZW50cyBhcmUgbm90IGVtcHR5IHdlIG5lZWQgdG8gY3Jl
YXRlIGEgbmV3IApzdHJpbmcgY29udGFpbmluZyB0aGUgb3JpZ2luYWwgY29u
dGVudHMsIGEgbmV3bGluZSBjaGFyYWN0ZXIsIGFuZCB0aGUgbmV3IApsaW5l
LgoKPDxhZGQtY2h1bmstY29udGVudHM+Pj0KKGRlZnVuIGFkZC10by1jaHVu
ay1jb250ZW50cyAoY3Vyci1jaHVuay1uYW1lIG5ldy1jb250ZW50cykKICAo
bGV0ICgoc3RhcnRpbmctY2h1bmstY29udGVudHMgKGdldC1jaHVuay1jb250
ZW50cyBjdXJyLWNodW5rLW5hbWUpKSkKICAgIChpZiAoc3RyaW5nLWVxdWFs
IHN0YXJ0aW5nLWNodW5rLWNvbnRlbnRzICIiKQoJKHNldGYgKGNodW5rLWNv
bnRlbnRzIChnZXRoYXNoIGN1cnItY2h1bmstbmFtZSAqY2h1bmstaGFzaC10
YWJsZSopKQoJICAgICAgbmV3LWNvbnRlbnRzKQoJKHNldGYgKGNodW5rLWNv
bnRlbnRzIChnZXRoYXNoIGN1cnItY2h1bmstbmFtZSAqY2h1bmstaGFzaC10
YWJsZSopKQoJICAgICAgKGNvbmNhdGVuYXRlICdzdHJpbmcgc3RhcnRpbmct
Y2h1bmstY29udGVudHMgKHN0cmluZyAjXE5ld2xpbmUpCgkJCSAgIG5ldy1j
b250ZW50cykpKSkpCgpACgpcc3Vic2VjdGlvbntBbGwgQmFzaWMgRnVuY3Rp
b25zfQoKVGhlc2UgdGhyZWUgb3BlcmF0aW9ucyBhcmUgdGhlIGNvcmUgb2Yg
d2hhdCBpcyBuZWVkZWQuICBXZSB3aWxsIGFkZCBvbmUgbW9yZSAKZnVuY3Rp
b24gZm9yIGNvbnZlbmllbmNlIGR1cmluZyBkZWJ1Z2dpbmcsIHdoaWNoIHBy
aW50cyBvdXQgYWxsIGNodW5rcyBpbiAKdGhlIGhhc2ggdGFibGUuCgo8PHZp
ZXctYWxsPj49CihkZWZ1biB2aWV3LWFsbC1jaHVua3MgKCkKICAobWFwaGFz
aCAjJyhsYW1iZGEgKGsgdikgKGZvcm1hdCB0ICJ+YSA9PiB+YX4lIiBrIHYp
KSAqY2h1bmstaGFzaC10YWJsZSopKQoKQAoKPDxiYXNpYy1jaHVuay1vcGVy
YXRpb25zPj49Cjw8bmV3LWNodW5rPj4KPDxnZXQtY2h1bmstY29udGVudHM+
Pgo8PGFkZC1jaHVuay1jb250ZW50cz4+Cjw8dmlldy1hbGw+PgpACgpcc2Vj
dGlvbntMb2NhdGluZyBDaHVua3MgYW5kIENodW5rIFJlZmVyZW5jZXN9CgpU
aGUgbW9zdCBkaWZmaWN1bHQgcGFydCBvZiBkZWFsaW5nIHdpdGggbGl0ZXJh
dGUgcHJvZ3JhbW1pbmcgZmlsZXMgaXMgdGhlIAppbnRlcndvdmVuIHN0cnVj
dHVyZSB0aGF0IGNvZGUgY2h1bmsgcmVmZXJlbmNlcyBjYW4gcHJvZHVjZS4g
IFR3byBsZXZlbHMgYXJlIApuZWVkZWQgLSBpZGVudGlmeSBhbmQgc3RvcmUg
ZGVmaW5lZCBjaHVua3MsIGFuZCBzcG90IHJlZmVyZW5jZXMgdG8gY2h1bmtz
IAppbnNpZGUgb2YgY2h1bmsgYm9kaWVzLgoKXHN1YnNlY3Rpb257SWRlbnRp
ZnlpbmcgYW5kIFN0b3JpbmcgQ2h1bmtzIC0gVG9wIExldmVsfQoKQW4gYXNz
dW1wdGlvbiBtYWRlIGlzIHRoYXQgYWxsIGNodW5rIGRlZmluaXRpb25zIGFy
ZSBgYHRvcCBsZXZlbCcnIC0gdGhhdCBpcywgCm5vIGNodW5rIGlzIGRlZmlu
ZWQgaW4gdGhlIGJvZHkgb2YgYW5vdGhlciBjaHVuay4gIEdyYW50aW5nIHRo
YXQgYXNzdW1wdGlvbiwgCml0IGlzIHBvc3NpYmxlIHRvIGNoZWNrIGVhY2gg
c3RyaW5nIGFzIGl0IGlzIHJlYWQgdG8gc2VlIGlmIGl0IGlzIHRoZSBzdGFy
dCAKb2YgYSBuZXcgY2h1bmsuICBUaGlzIGlzIGRvbmUgdXNpbmcgTGlzcCBz
dHJpbmcgc2VhcmNoaW5nIGFuZCBzcGFjZSB0cmltbWluZy4KQW5vdGhlciBh
c3N1bXB0aW9uIGlzIHRoYXQgdGhlIGJlZ2lubmluZyBpZGVudGlmaWVyIGZv
ciBhIGNodW5rIGlzIG9uIGl0cyAKb3duIGxpbmUgLSB0aGlzIGlzIHByb2Jh
Ymx5IG5vdCBzdHJpY3RseSBuZWNlc3NhcnkgYnV0IHNob3VsZCBiZSBzdGFu
ZGFyZCAKY29udmVudGlvbi4KCjw8dG9wbGV2ZWwtY2h1bmstc2Nhbm5pbmc+
Pj0KKGRlZnVuIGNoZWNrLWZvci10b3BsZXZlbC1jaHVuayAoaW5wdXRzdHJp
bmcgZmlsZW5hbWUpCiAgIChsZXQgKCh0ZXN0c3RyaW5nIChzdHJpbmctdHJp
bSAiICIgaW5wdXRzdHJpbmcpKSkKICAgICAoaWYgKD4gKGxlbmd0aCB0ZXN0
c3RyaW5nKSAzKQogICAgIChpZiAoYW5kIChzdHJpbmctZXF1YWwgc3RhcnRj
aGFycyB0ZXN0c3RyaW5nIDplbmQyIChsZW5ndGggc3RhcnRjaGFycykpCgkg
ICAgICAoc3RyaW5nLWVxdWFsIGVuZGNoYXJzIHRlc3RzdHJpbmcgCgkJCSAg
ICAgOnN0YXJ0MiAoLSAobGVuZ3RoIHRlc3RzdHJpbmcpIChsZW5ndGggZW5k
Y2hhcnMpKQoJCQkgICAgIDplbmQyIChsZW5ndGggdGVzdHN0cmluZykpKQog
ICAgICAgICAobGV0ICgobmV3LWNodW5rLW5hbWUgKHN1YnNlcSB0ZXN0c3Ry
aW5nIChsZW5ndGggc3RhcnRjaGFycykKCQkJCSAgICgtIChsZW5ndGggdGVz
dHN0cmluZykgKGxlbmd0aCBlbmRjaGFycykpKSkpCgkgICAobWFrZS1uZXct
Y2h1bmsgbmV3LWNodW5rLW5hbWUpCgkgICAocmVhZC1pbi1jaHVuayBuZXct
Y2h1bmstbmFtZSBmaWxlbmFtZSkKCSAgIHQpCgkgKSkpKQoKQAoKXHN1YnNl
Y3Rpb257SWRlbnRpZnlpbmcgYW5kIEV4cGFuZGluZyBDaHVuayBSZWZlcmVu
Y2VzfQoKVGhlIGFib3ZlIHdpbGwgc2VydmUgZm9yIHRvcGxldmVsIGNodW5r
IGlkZW50aWZpY2F0aW9uLCBidXQgdGhlIHRhc2sgb2YgCmlkZW50aWZ5aW5n
IHJlZmVyZW5jZXMgdG8gY2h1bmtzIGluIHRoZSBib2R5IG9mIGEgY2h1bmsg
aXMgYSBzbGlnaHRseSAKZGlmZmVyZW50IHRhc2suICBBIGxpbmUgd2lsbCBj
b250YWluIG9ubHkgb25lIGNodW5rIGRlZmluaXRpb24sIGJ1dCB0aGUgCmNv
bnRlbnRzIG9mIGEgY2h1bmsgYm9keSBtYXkgY29udGFpbiBtYW55IGNodW5r
IHJlZmVyZW5jZXMuICBBIGZ1cnRoZXIgCmNvbXBsaWNhdGlvbiBpcyB0aGF0
IGV2ZW4gd2hlbiB0aG9zZSByZWZlcmVuY2VzIGFyZSBleHBhbmRlZCwgdGhl
eSBtYXkgCmluIHR1cm4gY29udGFpbiBvdGhlciByZWZlcmVuY2VzLiAgVG8g
aGFuZGxlIHRoaXMgYSByZWN1cnNpdmUgZnVuY3Rpb24KaWRlbnRpZmllcyAg
dGhlIGZpcnN0IGNodW5rLCBleHBhbmRzIGl0LCBidWlsZHMgYSBuZXcgc3Ry
aW5nIGJhc2VkIG9uIAp0aGUgY29tYmluYXRpb24gIG9mIG9sZCBhbmQgbmV3
LCBpbnNlcnRzIGluIHBsYWNlIG9mIHRoZSByZWZlcmVuY2UsIAphbmQgY2Fs
bHMgaXRzZWxmIG9uIHRoZSBuZXcgcmVzdWx0LiBJbiB0aGUgZW5kLCB0aGUg
cmV0dXJuZWQgCnN0cmluZyB3aWxsIGhhdmUgYWxsIHJlZmVyZW5jZXMgZXhw
YW5kZWQgYW5kIGNvbnN0aXR1dGUgdGhlIGZpbmFsIGZvcm0gb2YgCnRoZSBj
aHVuayBhcyBpdCBpcyB0byBiZSBzZW50IHRvIHRoZSBvdXRwdXQgZmlsZS4K
Ckhvd2V2ZXIsIHRoZXJlIGFyZSBzZXZlcmFsIHRoaW5ncyB0byBiZSB3YXJ5
IG9mIHdoZW4gZG9pbmcgdGhpcyBzY2FuLiAgVGhlCmZpcnN0IGlzIGEgYmFk
IGNodW5rLCBvciBhIHJlZmVyZW5jZSBjaHVuayB3aGljaCBoYXMgbm8gZGVm
aW5pdGlvbi4gIFRoaXMKaXMgaGFuZGxlZCBieSB0aHJvd2luZyBhbiBlcnJv
ciBpZiBzdWNoIGEgY2h1bmsgaXMgZW5jb3VudGVyZWQuICBXZSB3aWxsCmFs
c28gZGVmaW5lIGhlcmUgdGhlIGNvcmUgcm91dGluZSBmb3IgbWVyZ2luZyB0
aGUgc3RyaW5nczoKCjw8Y29yZS1yZWY+Pj0KKHByb2duCiAgKGxldCAoKG1p
ZGRsZXN0cmluZyAoc3Vic2VxIGlucHV0c3RyaW5nIAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAoKyBwb3MxIChsZW5ndGggcmVmc3RhcnRjaGFy
cykpIAoJCQkgICAgICBwb3MyKSkpCiAgICAoaWYgKGdldGhhc2ggbWlkZGxl
c3RyaW5nICpjaHVuay1oYXNoLXRhYmxlKikKCShwcm9nbgoJICAoc2V0ZiBp
bnB1dHN0cmluZyAKCQkoY29uY2F0ZW5hdGUgJ3N0cmluZwoJCQkgICAgIChz
dWJzZXEgaW5wdXRzdHJpbmcgMCBwb3MxKQoJCQkgICAgIChnZXQtY2h1bmst
Y29udGVudHMgbWlkZGxlc3RyaW5nKQoJCQkgICAgIChzdWJzZXEgaW5wdXRz
dHJpbmcgCgkJCSAgICAgICAgICAgICAoKyBwb3MyIChsZW5ndGggcmVmZW5k
Y2hhcnMpKSkpKQoJICAoY2hlY2stZm9yLXJlZmVyZW5jZWQtY2h1bmsgaW5w
dXRzdHJpbmcgcG9zMSkpCgkoZXJyb3IgICJ+UyB3YXMgbm90IGZvdW5kIGlu
IGhhc2ggdGFibGUuIiBtaWRkbGVzdHJpbmcpKSkpKSkKQAoKVGhlIG5leHQg
Y2hlY2sgaXMgZm9yIGEgY2FzZSB3aGVyZSB0aGUgZGVsaW1pdGluZyBjaGFy
YWN0ZXJzIGFyZSBicm9rZW4KdXAgb3ZlciB0d28gbGluZXMuICBXZSB3aWxs
IG5vdCByZWdhcmQgdGhpcyBhcyBhIGxlZ2FsIGNodW5rIG5hbWUsIGFzCml0
IGlzIGEgcmF0aGVyIHVubGlrZWx5IGNoYXJhY3RlciBjb21iaW5hdGlvbiBm
b3IgYSBsYWJlbCwgYW5kIGl0IGFsc28KYWxsb3dzIHRoZSBhdm9pZGFuY2Ug
b2YgYWNjaWRlbnRhbCBjaHVuayBuYW1lIG1hdGNoaW5nIHdoZW4gaXQgaXMg
bm90CmludGVuZGVkIChvbmUgb2YgdGhlIGNodW5rcyBpbiB0aGlzIHBhbXBo
bGV0LCBmb3IgZXhhbXBsZSwgd291bGQgdHJpZ2dlcgpzdWNoIGFuIGVycm9y
LikgIElmIHN1Y2ggYSBjb25kaXRpb24gaXMgZm91bmQsIHRoZSBzY2FuIHNo
b3VsZCBiZSByZXN1bWVkCmJleW9uZCB0aGUgbmV3bGluZSBjaGFyYWN0ZXIu
Cgo8PGNoZWNrLWZvci1uZXdsaW5lPj49CihpZiAoc2VhcmNoIChzdHJpbmcg
I1xOZXdsaW5lKSBpbnB1dHN0cmluZyA6c3RhcnQyIHBvczEgCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6ZW5kMiBwb3My
KQogIChjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVuayBpbnB1dHN0cmluZyAK
ICAJKCsoc2VhcmNoIChzdHJpbmcgI1xOZXdsaW5lKSBpbnB1dHN0cmluZyA6
c3RhcnQyIHBvczEKCQkJCQkJIDplbmQyIHBvczIpIDEpICkKICA8PGNvcmUt
cmVmPj4KQAoKV2l0aCB0aG9zZSB0d28gY2hlY2tzIGluIHBsYWNlLCB3ZSBu
b3cgZGVmaW5lIHRoZSB0b3AgbGV2ZWwgY29udHJvbApmb3IgcG9zaXRpb25p
bmcgdGhlIHNlYXJjaCBjb21tYW5kLiAgVG8gYXZvaWQgY29uZnVzaW9uIGFu
ZCB1bm5lZWRlZApzY2FubmluZywgdGhlIGNvbW1hbmQgdGFrZXMgYSBzdGFy
dGluZyBwb3NpdGlvbiBhcyBhbiBhcmd1bWVudC4gIFRoaXMKYWxsb3dzIHN1
YnNlcXVlbnQgcmVjdXJzaXZlIGNhbGxzIHRvIGRpY3RhdGUgdGhlaXIgc3Rh
cnRpbmcgcG9zaXRpb24sCmFuZCB0aGUgaW5pdGlhbCBjYWxsIHNpbXBseSBz
cGVjaWZpZXMgemVybyBhcyB0aGUgYmVnaW5uaW5nLiAgQXQgdGhpcyBsZXZl
bAp3ZSBhbHNvIGhhdmUgdGhlIGV4aXQgY29uZGl0aW9uIC0gaWYgb25lIG9y
IG1vcmUgb2YgcG9zMSBhbmQgcG9zMiBhcmUKbmlsLCB0aGF0IG1lYW5zIHRo
aXMgcGFydGljdWxhciBzdHJpbmcgaXMgY29tcGxldGUgYW5kIGNhbiBiZSBy
ZXR1cm5lZC4KCjw8cmVmZXJlbmNlLWNodW5rLXNjYW5uaW5nPj49CihkZWZ1
biBjaGVjay1mb3ItcmVmZXJlbmNlZC1jaHVuayAoaW5wdXRzdHJpbmcgc3Rh
cnRwb3MpCiAgIChsZXQgKChwb3MxIChzZWFyY2ggcmVmc3RhcnRjaGFycyBp
bnB1dHN0cmluZyA6c3RhcnQyIHN0YXJ0cG9zKSkpCiAgICAgKGxldCAoKHBv
czIgKGlmIHBvczEgKHNlYXJjaCByZWZlbmRjaGFycyBpbnB1dHN0cmluZyA6
c3RhcnQyIHBvczEpKSkpCiAgICAgICAoaWYgKGFuZCBwb3MxIHBvczIpCgkg
ICAocHJvZ24KCSAgIDw8Y2hlY2stZm9yLW5ld2xpbmU+PgoJICAgaW5wdXRz
dHJpbmcpKSkpCgpACgpcc2VjdGlvbntSZWFkaW5nIGluIENodW5rc30KCk9u
Y2Ugd2UgaGF2ZSBpZGVudGlmaWVkIGEgY2h1bmsgYXQgdGhlIHRvcCBsZXZl
bCwgd2UgbXVzdCByZWFkIGl0IGluLiBJbiB0aGUgCnRvcGxldmVsIGZ1bmN0
aW9uIHRoYXQgam9iIGlzIHBhc3NlZCBvZmYgdGhhdCBqb2IgdG8gYSBmdW5j
dGlvbiBjYWxsZWQgCnJlYWQtaW4tY2h1bmsuICByZWFkLWluLWNodW5rIGlz
IHRoZSBmdW5jdGlvbiB0aGF0IHB1dHMgYWRkaXRpb25hbCBsaW5lcyBpbnRv
IAp0aGUgY2h1bmsgY29udGVudHMgc2xvdCB1bnRpbCB0aGUgZW5kLW9mLWNo
dW5rLWJvZHkgY2hhcmFjdGVyIGlzIHNwb3R0ZWQuICAKSXQgYWxzbyB1c2Vz
IHJlY3Vyc2lvbiAtIGlmIHRoZSBsaW5lIGl0IHJlYWRzIGlzbid0IHRoZSBl
bmQtb2YtYm9keSBtYXJrZXIsIAppdCBhcHBlbmRzIHRoYXQgbGluZSB0byB0
aGUgY29udGVudHMgYW5kIGNhbGxzIGl0c2VsZiB0byBjaGVjayB0aGUgbmV4
dCAKbGluZS4gIEl0IGFsc28gd2lsbCBhdm9pZCBhbiBlbmQtb2YtYm9keSBt
YXJrZXIgbm90IGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlCnN0cmluZywgdG8g
YXZvaWQgZW5kLW9mLWNodW5rLWJvZHkgY2hhcmFjdGVycyBpbiB0aGUgYm9k
eSBvZiBjb2RlIGFjY2lkZW50bHkKdHJpZ2dlcmluZyBhbiBlbmQgb2YgcmVh
ZC4KCjw8cmVhZGluLWNodW5rPj49CihkZWZ1biByZWFkLWluLWNodW5rIChj
dXJyLWNodW5rLW5hbWUgZmlsZW5hbWUpCiAgKGxldCAoKGxpbmVzIG5pbCkp
CiAgICAgKGxvb3AgZm9yIG5leHRsaW5lID0gKHJlYWQtbGluZSBmaWxlbmFt
ZSBuaWwpCiAgICAgICAgICAgIHdoaWxlIChvciAobm90IChzZWFyY2ggZW5k
Y2h1bmtjaGFycyBuZXh0bGluZSkpCiAgICAgICAgICAgICAgICAgICAgICAg
KHNlYXJjaCBlbmRjaHVua2NoYXJzIG5leHRsaW5lIDpzdGFydDIgMSkpCiAg
ICAgICAgICAgIGRvCiAgICAgICAgICAgICAgICAgIChwcm9nbgogICAgICAg
ICAgICAgICAgICAgICAocHVzaCBuZXh0bGluZSBsaW5lcykKICAgICAgICAg
ICAgICAgICAgICAgKHB1c2ggKHN0cmluZyAjXE5ld2xpbmUpIGxpbmVzKSkp
CiAgICAgIChpZiBsaW5lcwogICAgICAgICAocHJvZ24KICAgICAgICAgICAg
KHBvcCBsaW5lcykKICAgICAgICAgICAgKGFkZC10by1jaHVuay1jb250ZW50
cyBjdXJyLWNodW5rLW5hbWUKICAgICAgICAgICAgICAgICAgICAgICAgICAg
IChhcHBseSAjJ2NvbmNhdGVuYXRlICdzdHJpbmcgCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIChyZXZlcnNlIGxpbmVzKSkpKSkpKQoKQAoK
XHNlY3Rpb257RmlsZSBPcGVyYXRpb25zfQoKTm93IHRoYXQgd2Uga25vdyBo
b3cgdG8gaGFuZGxlIGNodW5rcywgd2Ugb25seSBuZWVkIHRvIGFwcGx5IHRo
YXQga25vd2xlZGdlIAp0byBzb21lIHBhcnRpY3VsYXIgZmlsZS4gIEZvciB0
aGlzLCB3ZSB1c2UgYSBsb29wIG1hY3JvIHJhdGhlciB0aGFuIHJlY3Vyc2lv
bi4KCjw8bG9hZC1maWxlPj49CihkZWZ1biBsb2FkLXBhbXBobGV0LWZpbGUg
KGZpbGVuYW1lKQogIChsZXQgKChpbiAob3BlbiBmaWxlbmFtZSA6aWYtZG9l
cy1ub3QtZXhpc3QgbmlsKSkpCiAgICAod2hlbiBpbgogICAgICAobG9vcCBm
b3IgbGluZSA9IChyZWFkLWxpbmUgaW4gbmlsKQoJICAgIHdoaWxlIGxpbmUg
ZG8gKGNoZWNrLWZvci10b3BsZXZlbC1jaHVuayBsaW5lIGluKSkKICAgICAg
KGNsb3NlIGluKSkpKQoKQAoKV2UgYWxzbyBuZWVkIHRvIGJlIGFib3V0IHRv
IG91dHB1dCB0byBhIGZpbGUuIFRoZSB6ZXJvIGluIHRoZSB3cml0ZS1zdHJp
bmcgCmNvbW1hbmQgc2ltcGx5IHRlbGxzIHRoZSBzY2FubmVyIHRvIHN0YXJ0
IGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIGZpbGUuICBBcwppdCBpcyBjdXJy
ZW50bHkgY29uZmlndXJlZCwgdGhlIG91dHB1dCBmaWxlIGlzIGFsd2F5cyBv
dmVyd3JpdHRlbi4KCjw8d3JpdGUtZmlsZT4+PQooZGVmdW4gd3JpdGUtb3V0
cHV0LWZpbGUgKGZpbGVuYW1lIGNodW5rbmFtZSkKICAobGV0ICgob3V0cHV0
c3RyZWFtIChvcGVuIGZpbGVuYW1lIDpkaXJlY3Rpb24gOm91dHB1dCA6aWYt
ZXhpc3RzIDpzdXBlcnNlZGUpKSkKICAgICh3cml0ZS1zdHJpbmcgKGNoZWNr
LWZvci1yZWZlcmVuY2VkLWNodW5rIAoJCSAgIChnZXQtY2h1bmstY29udGVu
dHMgY2h1bmtuYW1lKSAwKSBvdXRwdXRzdHJlYW0pCiAgICAoY2xvc2Ugb3V0
cHV0c3RyZWFtKSkpCgpACgpcc2VjdGlvbntQdWxsaW5nIEl0IFRvZ2V0aGVy
IC0gVGhlIG5vdGFuZ2xlIENvbW1hbmR9CgpUaGUgZmluYWwsIHRvcCBsZXZl
bCBjb250cm9sIGNvbW1hbmQgaXMgbmFtZWQgbm90YW5nbGUgdG8gY29uZm9y
bSB0byB0aGUgCk5PV0VCIGNvbnZlbnRpb24uICBUaGlzIGNvbW1hbmQgYWNj
ZXB0cyBhbiBpbnB1dCBmaWxlLCBvdXRwdXQgZmlsZSwgYW5kIApvcHRpb25h
bGx5IHRoZSBuYW1lIG9mIHRoZSBjaHVuayBhdCB3aGljaCB0byBzdGFydCBl
eHRyYWN0aW5nIGNvbnRlbnRzLiAgClRoZSBkZWZhdWx0IGNvbnZlbnRpb24g
b2YgQXhpb20gaXMgdG8gdXNlIGFuIGFzdGVyaXNrIGFzIHRoZSByb290IG5v
ZGUsIGJ1dCAKdGhpcyBpcyBub3QgdW5pdmVyc2FsbHkgdHJ1ZSBhbmQgaXQg
aXMgc29tZXRpbWVzIGRlc2lyYWJsZSB0byBvdXRwdXQgY29kZSAKZnJvbSBv
bmUgcGFtcGhsZXQgaW50byBtdWx0aXBsZSB0YXJnZXQgZmlsZXMsIHN0YXJ0
aW5nIGF0IG11bHRpcGxlIHJvb3RzLiAgCkluIHRoYXQgY2FzZSwgdGhlIGNo
dW5rIG5hbWUgaXMgcGFzc2VkIHRvIG5vdGFyZ2V0IGFzIHdlbGwuICBGb3Ig
ZXhhbXBsZToKClxiZWdpbntxdW90ZX0KKG5vdGFuZ2xlIGBgYm9vdC5wYW1w
aGxldCcnIGBgYm9vdC5saXNwJycgYGBSTGlzcCcnKQpcZW5ke3F1b3RlfQoK
XG5vaW5kZW50IHdvdWxkIGV4dHJhY3QgYWxsIGNvZGUgcmVmZXJlbmNlZCBi
eSB0aGUgUkxpc3AgY2h1bmssIHdoZXJlYXMKClxiZWdpbntxdW90ZX0KKG5v
dGFuZ2xlIGBgYm9vdC5wYW1waGxldCcnIGBgYm9vdC5ib290JycpClxlbmR7
cXVvdGV9Cgpcbm9pbmRlbnQgd291bGQgZXh0cmFjdCBhbGwgY29kZSByZWZl
cmVuY2VkIGJ5IHRoZSBcdmVyYkAnJyonJ0Agbm9kZS4KClRoZSBub3Rhbmds
ZSBjb21tYW5kIHdpbGwgYWx3YXlzIGNsZWFyIHRoZSBoYXNoIHRhYmxlIGJl
Zm9yZSBhbmQgYWZ0ZXIKdXNlLCB0byBlbnN1cmUgbm8gYWNjaWRlbnRhbCBj
b2xsaXNpb25zIGFuZCBhdm9pZCB1bm5lY2Vzc2FyeSBtZW1vcnkKdXNhZ2Uu
Cgo8PG5vdGFuZ2xlPj49CihkZWZ1biBub3RhbmdsZSAoZmlsZWlubmFtZSBm
aWxlb3V0bmFtZSAmb3B0aW9uYWwgKGNodW5rbmFtZSAiKiIpKQogIChjbHJo
YXNoICpjaHVuay1oYXNoLXRhYmxlKikKICAobG9hZC1wYW1waGxldC1maWxl
IGZpbGVpbm5hbWUpCiAgKHdyaXRlLW91dHB1dC1maWxlIGZpbGVvdXRuYW1l
IGNodW5rbmFtZSkKICAoY2xyaGFzaCAqY2h1bmstaGFzaC10YWJsZSopKQpA
CgpcZW5ke2RvY3VtZW50fQo=

\start
Date: Sat, 17 Feb 2007 19:04:32 -0800
From: Arthur Ralfs
To: list
Subject: MathML package

I've posted my MathML package on SandBoxMathML.
I'm still working on both the code and the documentation but
it does work now.  I've also included the diff files needed to
patch Axiom so it can be built with mathml as a new output
form.  There are also a few files to help with viewing the
output in Firefox.

\start
Date: Sun, 18 Feb 2007 05:43:22 +0100 (CET)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: No progress on notangle

> I have tried to use read-sequence to load a file quickly, which works
> fine, but I'm afraid I haven't done too well with the problem of
> working with the resulting string.  The code so far is actually slower
> than the earlier version, and from what I can tell the primary issue
> seems to be too many subseq operations on the big one-pamphlet string. 
> I tried leaving the string intact and just identifying positions rather
> than chopping it off as I scanned, but the searches got progressively
> more expensive even though I was supplying new start positions. 
> There's probably a better way to do it or an obvious mistake in the way
> I have done it, but I'm afraid I've been staring at it a bit too long. 

Fast way to scan strings is to use finite automaton.  The code below
shows how this can be done in Lisp. 

Notes:
- This is a proof of concept (probably buggy) code, in particular I
  only extract the  main chunk (do not handle rescannig for other
  chunks).  Rescannig can be done by similar code, which simulatneously
  could handle @-escapes ("@<<" etc).  If escapes are not supported one
  could do with a single scan, extending automaton to remember positions
  of embedded tags.  Alternative way to have single scan is to
  copy content to new array during scan handling escapes during
  copy.
- AFAICS this code is faster then Debian (pretty fast) notangle.
  I belive that after adding needed features it can still be
  fast.
- I use (unsigned-byte  8) as a type because Lisp implementation
  may choose to have Unicode character and perfrom complicated
  recoding during input and output.  Also, Unicode characters
  are likely to require more storage (so more time for memory
  access and for garbage collection).
- The main function 'scan-for-chunks' is a rat nest of gotos.
  But that is correct because finite automaton _is_ a rat nest
  of transition and one of the simplest ways to implement
  transitions is to use gotos.  One can make it shorter by
  using apropritate macros.  Ideally the automaton code should
  be mechanically generated -- writing in C I would use flex
  (the task is trivial for flex, but no so trivial by hand).
- For ultimate speed pamplets should be read directly by Spad
  scanner.  This would avoid duplicate work.  Namely, Spad have
  to scan the file anyway.  Recoginzing noweb markers adds
  only little complexity to scanner and (if implemented via
  finite automaton) almost no execution time.  Spad performs
  macro expansion and the same mechanizm can substitute chunks
  if they respect pile rules.  If one really wants unstructured
  chunks one can handle them redirection parser input (like
  include files).
- Re-doing Spad scanning/parsing is on my todo list.  But ATM
  parsing works no worse than the rest of compiler and while
  quite slow it is still one of the fastest parts in the compiler.
  So this task has very low priority.

Code follows:

;;; Usage:
;;;         (untangle "input.file.name" "output.file.name")
;;;

(defconstant start-tag-code1 (char-code #\<))
(defconstant start-tag-code2 (char-code #\<))
(defconstant end-tag-code-1 (char-code #\>))
(defconstant end-tag-code-2 (char-code #\>))
(defconstant end-tag-code-3 (char-code #\=))
(defconstant chunk-end-code (char-code #\@))
(defconstant newline-code 10)
(defconstant space-code (char-code #\ ))

(defun read-file (f)
    (let* ((b-len (file-length f))
           (buff (make-array (list (+ b-len 1))
                             :element-type '(unsigned-byte  8))))
        (read-sequence buff f)
        (setf (aref buff b-len) newline-code)
        buff))

(defun read-named-file (name)
    (with-open-file (f name :element-type '(unsigned-byte  8))
         (read-file f)))

(defclass chunk ()
  ((chunk-name
    :initarg :chunk-name
    :initform (error "Must supply a chunk name.")
    :reader chunk-name
    :documentation "Name of chunk.")
   (chunk-contents
    :initarg :chunk-contents
    :initform '()
    :accessor chunk-contents
    :documentation "Text of chunk - may include references to other chunks")))

(defparameter *chunk-hash-table* (make-hash-table :test 'equalp))

(defun add-to-chunk-contents (name content)
    (let ((chunk (gethash name *chunk-hash-table*)))
         (if (not chunk)
             (setf chunk (setf (gethash name *chunk-hash-table*)
                               (make-instance 'chunk :chunk-name name))))
             (push (chunk-contents chunk) content)))

(defun view-all-chunks ()
  (maphash #'(lambda (k v) (format t "~a => ~S~&" k v)) *chunk-hash-table*))

(defun print-chunk-name (name line-number)
    (format t "Chunk start in line ~A: <<" line-number)
    (dotimes (i (array-dimension name 0))
        (format t "~A" (code-char (aref name i))))
    (format t ">>~&")) 

(defun scan-for-chunks (buff)
    (prog ((pos -1)
           (end-buff (- (array-dimension buff 0) 1))
           (start-pos)
           (code)
           (chunk-name)
           (line-number 0))
       normal-start
         (incf pos)
         (incf line-number)
         (if (>= pos end-buff)
             (return-from scan-for-chunks))
         (setf code (aref buff pos))
         (if (equal code start-tag-code1)
             (go chunk-start-tag-1))
         (if (equal code newline-code)
             (go normal-start))
         (go normal)
       normal
         (incf pos)
         (setf code (aref buff pos))
         (if (equal code newline-code)
             (go normal-start))
         (go normal)
       chunk-start-tag-1
         (incf pos)
         (setf code (aref buff pos))
         (if (equal code start-tag-code2)
             (progn
                  (setf start-pos (+ pos 1))
                  (format t "start-pos: ~A, char: ~A~&" start-pos
                                                      (aref buff start-pos))
                  (go in-chunk-start-tag)))
         (if (equal code newline-code)
             (go normal-start))
         (go normal)
       in-chunk-start-tag
         (incf pos)
         (setf code (aref buff pos))
         (if (equal code end-tag-code-1)
             (go in-chunk-start-tag-3))
         (if (equal code newline-code)
             (go normal-start))
         (go in-chunk-start-tag)
       in-chunk-start-tag-3
         (incf pos)
         (setf code (aref buff pos))
         (if (equal code end-tag-code-2)
             (go in-chunk-start-tag-4))
         (if (equal code newline-code)
             (go normal-start))
         (go normal)
       in-chunk-start-tag-4
         (incf pos)
         (setf code (aref buff pos))
         (if (equal code end-tag-code-3)
             (progn 
                  (setf chunk-name (subseq buff start-pos (- pos 2)))
                  (go in-chunk-start-tag-trailing)))
         (if (equal code newline-code)
             (go normal-start))
         (go normal)
       in-chunk-start-tag-trailing
         (incf pos)
         (setf code (aref buff pos))
         (if (equal code newline-code)
             (progn
                 (print-chunk-name chunk-name line-number)
                 (setf chunk-start-pos (+ pos 1))
                 (go in-chunk)))
         (if (equal code space-code)
             (go in-chunk-start-tag-trailing))
         (go normal)
       chunk-start
         (setf chunk-end-pos pos)
         (incf pos)
         (if (>= pos end-buff)
             (break "unexpected end of file"))
         (setf code (aref buff pos))
         (incf line-number)
         (if (equal code newline-code)
             (go chunk-start))
         (if (equal code chunk-end-code)
             (progn 
                 (add-to-chunk-contents 
                     chunk-name 
                     (list chunk-start-pos chunk-end-pos))
                 (go chunk-end-trailing)))
         (go in-chunk)
       chunk-end-trailing
         (incf pos)
         (setf code (aref buff pos))
         (if (equal code newline-code)
            (go normal-start))
         (if (equal code space-code)
            (go chunk-end-trailing))
         (format t "pos: ~A, code: ~A~&" pos code)
         (break "garbage after end of chunk marker")
       in-chunk
         (incf pos)
         (setf code (aref buff pos))
         (if (equal code newline-code)
             (go chunk-start))
         (go in-chunk)))

(defun untangle (in-file out-file)
    (let ((buff (read-named-file in-file)) (chunk))
          (scan-for-chunks buff)
          (setf chunk (gethash (make-array (list 1)
                                         :element-type '(unsigned-byte  8)
                                         :initial-element (char-code #\*))
                                *chunk-hash-table*))
          (if (not chunk)
              (break "No main chunk"))
          (with-open-file (of out-file :direction :output
                                       :element-type '(unsigned-byte  8))
              (dolist (seg (reverse (chunk-contents chunk)))
                    (write-sequence buff of :start (nth 0 seg) 
                                            :end (nth 1 seg))))))
         

\start
Date: Sat, 17 Feb 2007 21:50:03 -0800 (PST)
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: No progress on notangle

> Fast way to scan strings is to use finite automaton.  The code below
> shows how this can be done in Lisp. 

Eeeep.  I'm impressed!

> - The main function 'scan-for-chunks' is a rat nest of gotos.
>   But that is correct because finite automaton _is_ a rat nest
>   of transition and one of the simplest ways to implement
>   transitions is to use gotos.  One can make it shorter by
>   using apropritate macros.  Ideally the automaton code should
>   be mechanically generated -- writing in C I would use flex
>   (the task is trivial for flex, but no so trivial by hand).

Perhaps they could be prototyped in flex and then mapped to the Lisp
macro system?

This raises a question for me - I know Tim has need of a very fast
notangle for his work, but does Axiom actually need this kind of speed?
 The complexity of this code makes me wonder of the extra 30 seconds in
Axiom build time are worth the added obfuscation.  I suppose if we get
the macros written it won't be so formidible though...

I did a little bit of analysis, which Waldek's work makes more or less
moot but I'll add on anyway in case it winds up being of use to someone
else who is interested in basic profiling.  One point - unless I'm
misunderstanding what the finite automaton solution is, this analysis
actually does point in the correct optimization direction - which is to
say, not read-line or reading speed but rather string manipulation
speed.  Perhaps similar (but more advanced) study will wind up being
useful for other parts of Axiom.

Among the interesting features of sbcl, it turns out there is a neat
little utility called sb-profile that lets one watch how much time
functions take over time.  I tried it using v0.3 of the cl-notangle,
and it is suggesting that it's not only (or even primarily) read-line
that is taking the time.

Here's what I did:

SETUP> (load "/home/cyapp/cl-notangle-v0.3.lisp")
T
SETUP> (sb-profile:profile MAKE-NEW-CHUNK GET-CHUNK-CONTENTS
ADD-TO-CHUNK-CONTENTS READ-IN-CHUNK CHECK-FOR-TOPLEVEL-CHUNK
CHECK-FOR-REFERENCED-CHUNK LOAD-PAMPHLET-FILE WRITE-OUTPUT-FILE)
; No value

That sets up the profiling on the defined functions.  I then run my
benchmark test, which is essentially all of boot and interp:

SETUP> (load "./setup/runlispnotangle.lisp")
T

This takes anywhere from 10 to 13 seconds, bases on earlier testing. 
Looking at the report:

SETUP> (sb-profile:report)
  seconds  |    consed   |  calls |  sec/call  |  name  
----------------------------------------------------------
     5.369 | 101,785,848 |    761 |   0.007055 |
CHECK-FOR-REFERENCED-CHUNK
     4.869 |  72,160,120 |    802 |   0.006072 | READ-IN-CHUNK
     0.378 |   2,271,408 |    207 |   0.001826 | WRITE-OUTPUT-FILE
     0.204 |   4,750,544 |    207 |   0.000985 | LOAD-PAMPHLET-FILE
     0.066 |   1,925,024 | 10,731 |   0.000006 |
CHECK-FOR-TOPLEVEL-CHUNK
     0.031 |     296,264 |    802 |   0.000039 | MAKE-NEW-CHUNK
     0.019 |           0 |  1,557 |   0.000012 | GET-CHUNK-CONTENTS
     0.010 |      20,480 |    800 |   0.000013 | ADD-TO-CHUNK-CONTENTS
----------------------------------------------------------
    10.946 | 183,209,688 | 15,867 |            | Total

estimated total profiling overhead: 0.03 seconds
overhead estimation parameters:
  2.4e-8s/call, 2.088e-6s total profiling, 9.44e-7s internal profiling
; No value

interesting things immediately jump out - the majority of the read-line
calls are in read-in-chunk and load-pamphlet-file, but they account for
only about half the time.  Admittedly that's already as long as noweb
takes to finish the job, but the real killer is
CHECK-FOR-REFERENCED-CHUNK.  So, since read-line was the initial
suspect, we take the instrumenting one step further and add some more
basic functions:

SETUP> (sb-profile:reset)
NIL
SETUP> (sb-profile:profile read-line string-equal concatenate search)
; No value

We run the identical test:

SETUP> (load "./setup/runlispnotangle.lisp")
T

and get a new report:

SETUP> (sb-profile:report)
  seconds  |    consed   |  calls  |  sec/call  |  name  
-----------------------------------------------------------
     5.533 |  89,786,440 |  11,880 |   0.000466 | CONCATENATE
     2.402 |           0 | 160,425 |   0.000015 | SEARCH
     1.971 |  49,896,872 |     761 |   0.002590 |
CHECK-FOR-REFERENCED-CHUNK
     0.445 |  31,027,600 | 168,558 |   0.000003 | READ-LINE
     0.308 |   1,564,872 |     207 |   0.001487 | WRITE-OUTPUT-FILE
     0.154 |  15,594,040 |     802 |   0.000192 | READ-IN-CHUNK
     0.021 |      90,736 |  11,315 |   0.000002 | STRING-EQUAL
     0.019 |           0 |   1,557 |   0.000012 | GET-CHUNK-CONTENTS
     0.003 |      20,160 |     802 |   0.000004 | MAKE-NEW-CHUNK
     0.001 |      14,880 |     800 |   0.000002 | ADD-TO-CHUNK-CONTENTS
     0.000 |   2,523,816 |     207 |   0.000000 | LOAD-PAMPHLET-FILE
     0.000 |   2,074,864 |  10,731 |   0.000000 |
CHECK-FOR-TOPLEVEL-CHUNK
-----------------------------------------------------------
    10.856 | 192,594,280 | 368,045 |            | Total

estimated total profiling overhead: 0.77 seconds
overhead estimation parameters:
  2.4e-8s/call, 2.088e-6s total profiling, 9.44e-7s internal profiling
; No value

Ah - concatenate by itself takes about as long as noweb does to do the
complete job.  search and read-line together take less than 3s,  and
are called a combined total of over 300k times to concatenate's less
than 12k.  This seems to suggest read-line, while slower than
read-sequence, is not yet the limiting factor.

Unfortunately, unless someone knows of a library that implements the
type of system Waldek is talking about, it looks like there is some
work ahead to implement the best of all possible notangles.  I may go
ahead and use the less efficient one for the moment to try other things
like teaching asdf to read pamphlet files, and when we are ready to go
"live" we can try for high end optimization targets.  Waldek (if you
made it this far), how much work do you think is involved with setting
up the full polished system?  Also, can you recommend some background
reading on the technique you're describing?

\start
Date: Sun, 18 Feb 2007 01:08:36 -0500
From: Bill Page
To: Arthur Ralfs
Subject: RE: MathML package

On February 17, 2007 10:05 PM Arthur Ralfs wrote:

> 
> I've posted my MathML package on SandBoxMathML.
> I'm still working on both the code and the documentation but
> it does work now.  I've also included the diff files needed to
> patch Axiom so it can be built with mathml as a new output
> form.  There are also a few files to help with viewing the
> output in Firefox.
> 

Arthur,

Thank you very much for this contribution! I think this will
be very important for the development of new users interfaces
for Axiom. At the moment I am bogged down with other activities
but I plan to install your patches in my version of Axiom soon
and give this a test run.

Perhaps we can also install this on the Axiom Wiki web server
so that MathML output can be viewed directly in the Wiki. Last
time I tried this (with the Reduce MathML interface) I ran into
problems with forcing the Wiki to generate the correct headers
for web pages that contain MathML. Do you know of any way to
embed MathML into HTML that does not (quite) conform to the
XHTML standard?

Regards,
Bill Page.

PS. You might notice that I added your mathml.spad pamphlet as
a page on the Wiki (see link on left sidebar of SandBoxMathML)
so now you can see the documentation and code online.

\start
Date: Sun, 18 Feb 2007 00:17:18 -0800
From: Arthur Ralfs
To: Bill Page
Subject: Re: MathML package

Bill Page wrote:
> Arthur,
>
> Perhaps we can also install this on the Axiom Wiki web server
> so that MathML output can be viewed directly in the Wiki. Last
> time I tried this (with the Reduce MathML interface) I ran into
> problems with forcing the Wiki to generate the correct headers
> for web pages that contain MathML. Do you know of any way to
> embed MathML into HTML that does not (quite) conform to the
> XHTML standard?
>
> Regards,
> Bill Page.
>
>   
Bill,

As far as I know the following is the "correct" way to embed mathml into
xhtml.  The file needs to have the extension xml or xhtml.  html doesn't
work (in Firefox), I guess however that if delivering the page with a
web server the content type could be set so that the file extension
wouldn't matter.

<?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"
                     
"http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd" >
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>MathML Test </title>
  </head>
  <body>
    <math xmlns="http://www.w3.org/1998/Math/MathML" mathsize="big"
display="block">
      <msup><mi>x</mi><mn>2</mn></msup>
    </math>
  </body>
</html>

This also works, again with file extension  xml or xhtml.

<html>
  <body>
    <math xmlns="http://www.w3.org/1998/Math/MathML" mathsize="big"
display="block">
      <msup><mi>x</mi><mn>2</mn></msup>
    </math>
  </body>
</html>

\start
Date: 18 Feb 2007 03:19:11 -0600
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: No progress on notangle

Cliff Yapp writes:

[...]

| This raises a question for me - I know Tim has need of a very fast
| notangle for his work, but does Axiom actually need this kind of speed?

Yes!

>From my perspective, anything that is slower (by any margin) than
current noweb isn't worth replacing it.  Axiom builds tens of hundreds
of algebras and noweb is invoked on all files.  I don't want to slow
down more the build.  Yes, this is religious issue, but it takes too
long to build Axiom, which slows down the patch-build-test cycle.

\start
Date: Sun, 18 Feb 2007 05:10:19 -0800 (PST)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: No progress on notangle

--- Gabriel Dos Reis wrote:

> Cliff Yapp writes:
> 
> [...]
> 
> | This raises a question for me - I know Tim has need of a very fast
> | notangle for his work, but does Axiom actually need this kind of
> | speed?
> 
> Yes!

<grin>  ask a silly question...  OK, I'll keep trying to follow what
Waldek is doing.

> From my perspective, anything that is slower (by any margin) than
> current noweb isn't worth replacing it.  Axiom builds tens of
> hundreds of algebras and noweb is invoked on all files.
> I don't want to slow down more the build.  Yes, this is religious
> issue, but it takes too long to build Axiom, which slows down the
> patch-build-test cycle.

OK...  Hmm.  What about this - I already have taught sbcl how to run
the  external notangle command for some previous work.  What if we set
it up that the lisp notangle command first looks for the external
notangle and tries to run it, but failing that falls back to the
internal one?  That way, we can make use of a pre-installed noweb if
it's available, and if that fails fall back on the lisp version. 
If/when we get a faster one we simply reverse the order in which the
options are tried.  For that matter, we can add the perl one to the
list as well - I've never benchmarked that one so I can't say how fast
it is.

For the case where noweb isn't already installed, I guess it's a
question of whether the increased time of cl-notangle is greater than
the time it takes to build the regular noweb.  I haven't timed the
noweb build so I'm not sure - I don't think the 7 second difference for
boot+interp would do it but of course the real volume is in the algebra
source files which I've not yet tried.

I guess another question is whether Axiom is set up so that ./configure
can build only noweb and nothing else on request.

\start
Date: Sun, 18 Feb 2007 09:28:33 -0600 (CST)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: No progress on notangle

On Sun, 18 Feb 2007, C Y wrote:

[...]

| I guess another question is whether Axiom is set up so that ./configure
| can build only noweb and nothing else on request.

  make all-noweb

\start
Date: Sun, 18 Feb 2007 12:50:10 -0600
From: Tim Daly
To: Camm Maguire
Subject: GCC/GCL warning messages

Camm,

I'm building the next Axiom release. During the GCL build I see a large
number of messages that read:

gcl_defmacro.c:In function `L12':
gcl_defmacro.c:79: warning: dereferencing type-punned pointer will
 break strict-aliasing rules

C99 language semantics now assume that pointers to different types
point to different memory locations, which is obvious nonsense, but
part of the new standard.

You might want to add -fno-strict-aliasing option to the GCC command line.
The alternative fix is to embed a (void *) between your cast and your
thing thus:

  x = (yourcast)(void *)thing

\start
Date: Sun, 18 Feb 2007 21:19:49 +0100 (CET)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: No progress on notangle

Below is a newer version of CL notangle, this time handling recursive
references.  There are still significant differences compared to
real notangle (lack of @ escapes, different end of line handling, ...).
I also fixed performace problem in scan-for-chunks (previous version
was using 'equal' and sbcl emited actual call to 'equal', current
version uses 'eql' which generates inline code).  Another performance
problem was using arrays of bytes as hash keys (completly killed
performance for pamphlets with many small chunks, or chunks
split into many small pieces).  I solved this problem converting
arrays to strings before hashing.

This version seem to be significantly faster than notangle: it is able
to process simple 8 Mb file (containing few big chunks) in 0.14s while
notangle needs 2s.  On 8Mb file containing 1000 chunks, each consisting
of 100 pieces 10 lines each, my version needs 0.24s, while notangle
uses 2.85s. 

BTW. Timing was done on 2GHz Athlon 64.  Notangle came from Axiom build,
Lisp is sbcl 1.0.  I tried also clisp, but it is quite slow (need 8.73
senconds on my second test file) -- no wonder since I use a low level
code.  This version (like the previous one) does not work with gcl
(ANSI 2.6.5 interpreter claims that 'read-sequence' is undefined,
non-ANSI interpreter chokes on 'defclass').

(defconstant start-tag-code-1 (char-code #\<))
(defconstant start-tag-code-2 (char-code #\<))
(defconstant end-tag-code-1 (char-code #\>))
(defconstant end-tag-code-2 (char-code #\>))
(defconstant end-tag-code-3 (char-code #\=))
(defconstant start-marker-code-1 (char-code #\<))
(defconstant start-marker-code-2 (char-code #\<))
(defconstant end-marker-code-1 (char-code #\>))
(defconstant end-marker-code-2 (char-code #\>))
(defconstant chunk-end-code (char-code #\@))
(defconstant newline-code 10)
(defconstant space-code (char-code #\ ))

(defun read-file (f)
    (let* ((b-len (file-length f))
           (buff (make-array (list (+ b-len 1))
                             :element-type '(unsigned-byte  8))))
        (read-sequence buff f)
        (setf (aref buff b-len) newline-code)
        buff))

(defun read-named-file (name)
    (with-open-file (f name :element-type '(unsigned-byte  8))
         (read-file f)))

(defclass chunk ()
  ((chunk-name
    :initarg :chunk-name
    :initform (error "Must supply a chunk name.")
    :reader chunk-name
    :documentation "Name of chunk.")
   (chunk-contents
    :initarg :chunk-contents
    :initform '()
    :accessor chunk-contents
    :documentation "Text of chunk - may include references to other chunks")))

(defparameter *chunk-hash-table* (make-hash-table :test 'equal))

(defun add-to-chunk-contents (name content)
    (declare (optimize (speed 3)))
    (let ((chunk (gethash name *chunk-hash-table*)))
         (if (not chunk)
             (setf chunk (setf (gethash name *chunk-hash-table*)
                               (make-instance 'chunk :chunk-name name))))
             (push content (chunk-contents chunk))))

(defun view-all-chunks ()
  (maphash #'(lambda (k v) (format t "~a => ~S~&" k (chunk-contents v))) *chunk-hash-table*))

(defun print-chunk-name (name line-number)
    (format t "Chunk start in line ~A: <<" line-number)
    (dotimes (i (array-dimension name 0))
        (format t "~A" (code-char (aref name i))))
    (format t ">>~&")) 

(defun array-to-string (ar)
    (declare (optimize (speed 3))
             (type (simple-array (unsigned-byte 8) (*)) ar))
    (let* ((len (array-dimension ar 0))
           (str (make-string len)))
          (dotimes (i len)
               (setf (aref str i) (code-char (aref ar i))))
          str))

(defun scan-for-chunks (buff)
    (declare (optimize (speed 3)))
    (prog ((pos -1)
           (end-buff (- (array-dimension buff 0) 1))
           (start-pos)
           (code)
           (chunk-name)
           (content nil)
           (chunk-start-pos)
           (chunk-end-pos)
           (line-number 0))
         (declare (type (signed-byte 32) pos end-buff line-number)
                  (type (simple-array (unsigned-byte  8) (*)) buff))
                  
       normal-start
         (incf pos)
         (incf line-number)
         (if (>= pos end-buff)
             (return-from scan-for-chunks))
         (setf code (aref buff pos))
         (if (eql code start-tag-code-1)
             (go chunk-start-tag-1))
         (if (eql code newline-code)
             (go normal-start))
         (go normal)
       normal
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code newline-code)
             (go normal-start))
         (go normal)
       chunk-start-tag-1
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code start-tag-code-2)
             (progn
                  (setf start-pos (+ pos 1))
                  ;;; (format t "start-pos: ~A, char: ~A~&" start-pos
                  ;;;                                  (aref buff start-pos))
                  (go in-chunk-start-tag)))
         (if (eql code newline-code)
             (go normal-start))
         (go normal)
       in-chunk-start-tag
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code end-tag-code-1)
             (go in-chunk-start-tag-3))
         (if (eql code newline-code)
             (go normal-start))
         (go in-chunk-start-tag)
       in-chunk-start-tag-3
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code end-tag-code-2)
             (go in-chunk-start-tag-4))
         (if (eql code newline-code)
             (go normal-start))
         (go normal)
       in-chunk-start-tag-4
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code end-tag-code-3)
             (progn 
                  (setf chunk-name (subseq buff start-pos (- pos 2)))
                  (go in-chunk-start-tag-trailing)))
         (if (eql code newline-code)
             (go normal-start))
         (go normal)
       in-chunk-start-tag-trailing
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code newline-code)
             (progn
                 ;;; (print-chunk-name chunk-name line-number)
                 (setf chunk-start-pos (+ pos 1))
                 (go in-chunk)))
         (if (eql code space-code)
             (go in-chunk-start-tag-trailing))
         (go normal)
       chunk-start
         (setf chunk-end-pos pos)
         (incf pos)
         (if (>= pos end-buff)
             (break "unexpected end of file"))
         (setf code (aref buff pos))
         (incf line-number)
         (if (eql code newline-code)
             (go chunk-start))
         (if (eql code start-marker-code-1)
             (go start-marker-1))
         (if (eql code chunk-end-code)
             (progn
                 (push (list chunk-start-pos chunk-end-pos) content)
                 (setf content (reverse content))
                 ;;; (format t "Adding ~S to ~S~&" content chunk-name) 
                 (add-to-chunk-contents 
                     (array-to-string chunk-name)
                     content)
                 ;;; (view-all-chunks)
                 (setf content nil)
                 (go chunk-end-trailing)))
         (go in-chunk)
       chunk-end-trailing
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code newline-code)
            (go normal-start))
         (if (eql code space-code)
            (go chunk-end-trailing))
         (format t "pos: ~A, code: ~A~&" pos code)
         (break "garbage after end of chunk marker")
       in-chunk
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code newline-code)
             (go chunk-start))
         (if (eql code start-marker-code-1)
             (go start-marker-1))
         (go in-chunk)
       start-marker-1
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code start-marker-code-2)
             (progn
                 (setf start-pos (+ pos 1))
                 (go start-marker-2)))
         (if (eql code newline-code)
             (go chunk-start))
         (go in-chunk)
       start-marker-2
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code end-marker-code-1)
             (go start-marker-3))
         (if (eql code newline-code)
             (go chunk-start))
         (go start-marker-2)
       start-marker-3
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code end-marker-code-2)
              (progn
                   (push (list chunk-start-pos (- start-pos 2)) content)
                   (push (array-to-string
                             (subseq buff start-pos (- pos 1)))
                          content)
                   (setf chunk-start-pos (+ pos 1))
                   (go in-chunk)))
         (if (eql code newline-code)
             (go chunk-start))
         (go start-marker-2)))

(defun write-chunk (buff name out-file)
    (let ((chunk (gethash name *chunk-hash-table*)))
        (dolist (segs (reverse (chunk-contents chunk)))
            (dolist (seg segs)
                (if (consp seg)
                    (write-sequence buff out-file :start (nth 0 seg)
                                                :end (nth 1 seg))
                    (write-chunk buff seg out-file))))))

(defun untangle (in-file out-name)
    (clrhash *chunk-hash-table*)
    (let ((buff (read-named-file in-file))
          (chunk)
          (name (make-array (list 1)
                                         :element-type '(unsigned-byte  8)
                                         :initial-element (char-code #\*))))
          (scan-for-chunks buff)
          ;;; (setf name (array-to-string name))
          (setf name "*")
          (setf chunk (gethash name *chunk-hash-table*))
          (if (not chunk)
              (break "No main chunk"))
          (with-open-file (out-file out-name :direction :output
                                       :if-exists :supersede
                                       :element-type '(unsigned-byte  8))
              (write-chunk buff name out-file))))
         
\start
Date: Sun, 18 Feb 2007 22:01:48 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: Re: No progress on notangle

Unforunately, I am a lisp illiterate. :-( So I don't even know how to 
start your program on test files. So I would like to give a little 
(meaningless) testfile.

The output of notangle on the program below is

----------------------
foo(x: Integer): Integer == z := 1
                             for i in 1.. x repeat
                                 h := 1
                                 for j in 1..i repeat
                                     h := h + j
                                     h := 2*h
                                 h := if h > 100
                                        then
                                          h-2
                                        else
                                          h+2
                                 h := 3*h
                                 z := h
                             z
----------------------

Does your program give the same result?

Furthermore what about the option "-L" that can be given to notangle?
That is particularly useful if your compiler emits a column number for 
error messages. #pile mode is bad in that case anyway, but there are 
also files that are indentation-independent.

Ralf

---BEGIN aaa.spad.pamphlet
<<*>>=
foo(x: Integer): Integer == <<foo body>>
@

<<foo body>>=
z := 1
for i in 1.. x repeat
     <<auxiliary computation>>
     h := <<post computation>>
     <<binding z>>
z
@

<<auxiliary computation>>=
h := 1
for j in 1..i repeat
     h := h + j
     h := 2*h
@

<<post computation>>=
if h > 100
   then
     h-2
   else
     h+2
@

<<binding z>>=
h := 3*h
z := h
@
---END aaa.spad.pamphlet

\start
Date: Sun, 18 Feb 2007 14:01:53 -0800 (PST)
From: Cliff Yapp
To: Waldek Hebisch
Subject: notangle

(changing the subject since it's no longer true ;-)

--- Waldek Hebisch wrote:

> Below is a newer version of CL notangle, this time handling recursive
> references.  There are still significant differences compared to
> real notangle (lack of @ escapes, different end of line handling,
> ...).

Well, we probably don't actually need the full power of noweb notangle
- I think it makes more sense to enforce sane pamphlet writing style
instead (improves human readability, for that matter - stays
consistent).

By lack of @ escapes, do you mean that any @ in the file is treated as
the end of a code chunk, e.g. no awareness of position?  (e.g. it won't
be able to process itself as a pamphlet?)  From what I saw earlier the
only two things that are really needed are recognizing an illegal chunk
name due to newline inclusion (you may not even need that one the way
you've defined your start and end chars) and making sure @ is right
after a newline (at least for parsing Axiom files, which is the main
goal.)  I'll have a go at it later and see how it behaves.

> I also fixed performace problem in scan-for-chunks (previous version
> was using 'equal' and sbcl emited actual call to 'equal', current
> version uses 'eql' which generates inline code).  Another performance
> problem was using arrays of bytes as hash keys (completly killed
> performance for pamphlets with many small chunks, or chunks
> split into many small pieces).  I solved this problem converting
> arrays to strings before hashing.

Wow.  VERY impressive work.  One question Waldek - I'm willing to try
to convert this code into a literate document for purposes of Axiom
inclusion, but I fear I'm not competent to describe these issues and
reasons for specific choices.  I'll take a stab at it using your emails
as a starting point (indeed, that might be a good way to ensure the
documentation covers enough for other clueless beginners) but are you
up for a few painfully ignorant questions? ;-)

Also, are you OK with the modified BSD license for this?  It's
essentially all your code at this point so I don't want to presume.

> This version seem to be significantly faster than notangle: it is
> able to process simple 8 Mb file (containing few big chunks) in 0.14s
> while notangle needs 2s.  On 8Mb file containing 1000 chunks, each
> consisting of 100 pieces 10 lines each, my version needs 0.24s, while
> notangle uses 2.85s. 

You may have just become the poster child for those trying to debunk
the "lisp is slow" myth ;-).

> BTW. Timing was done on 2GHz Athlon 64.  Notangle came from Axiom
> build, Lisp is sbcl 1.0.  I tried also clisp, but it is quite slow
> (need 8.73 senconds on my second test file) -- no wonder since I use
> a low level code.  This version (like the previous one) does not
> work with gcl (ANSI 2.6.5 interpreter claims that 'read-sequence'
> is undefined, non-ANSI interpreter chokes on 'defclass').

Um.  Clisp doesn't surprise me, and normally if speed is a concern
people don't run on Clisp anyway.  I also ran into the defclass thing
on GCL - perhaps we could use defstruct instead?  I don't know that
there's any particular reason to use CLOS other than convenience and
trying to be "modern".

Cheers, and thanks again for some really excellent work!

\start
Date: Sun, 18 Feb 2007 23:13:52 +0100 (CET)
From: Waldek Hebisch
To: Ralf Hemmecke
Subject: Re: No progress on notangle

Ralf Hemmecke wrote:
> Unforunately, I am a lisp illiterate. :-( So I don't even know how to 
> start your program on test files. So I would like to give a little 
> (meaningless) testfile.

If you have sbcl you can do (assuming that you have saved the program
int the file "nono2.lisp"):

(load "nono2.lisp")
(untangle "input.file" "output.file")

For timing:
(time (untangle "input.file" "output.file"))

Other Lisps require extra commands to compile the code but at least
up to version 1.0 sbcl automatically compiles the code.

> 
> The output of notangle on the program below is
> 
> ----------------------
> foo(x: Integer): Integer == z := 1
>                              for i in 1.. x repeat
>                                  h := 1
>                                  for j in 1..i repeat
>                                      h := h + j
>                                      h := 2*h
>                                  h := if h > 100
>                                         then
>                                           h-2
>                                         else
>                                           h+2
>                                  h := 3*h
>                                  z := h
>                              z
> ----------------------
> 
> Does your program give the same result?
>

No.  First I have noticed that notangle behaves in rather inconsitent
way.  I do not want to waste time trying to find out exact rules used
by notangle.  With pile semantics it seems better to integrate
notangle like processing with Spad scanning and treat each hunk as
a pile (IMHO having piles spanning hunk boundary is just confusing
and error prone).

To supporting such feature would require storing information about
all line endings.  This is not very hard, but I do not want to
invest much more time in this program unless other find it useful.
Also note that the reason to use Lisp is so that the program can
run inside Axiom process.  For external program I would use C
which probably would be faster to write and would give faster
program.  Note that this is not intended to be a general remark
about languages: I simply know C better (most of the time for
writing program was actually spent in CL manuals), I know C tools
for scanning, I have a collection of C utility routines which
make the task easier.

> Furthermore what about the option "-L" that can be given to notangle?
> That is particularly useful if your compiler emits a column number for 
> error messages. #pile mode is bad in that case anyway, but there are 
> also files that are indentation-independent.
>

That could be easily addedd: the program traces line numbers anyway
(for debugging purposes) so it would be easy to store them together
with chunks and emit when needed.

> ---BEGIN aaa.spad.pamphlet
> <<*>>=
> foo(x: Integer): Integer == <<foo body>>
> @
> 
> <<foo body>>=
> z := 1
> for i in 1.. x repeat
>      <<auxiliary computation>>
>      h := <<post computation>>
>      <<binding z>>
> z
> @
> 
> <<auxiliary computation>>=
> h := 1
> for j in 1..i repeat
>      h := h + j
>      h := 2*h
> @
> 
> <<post computation>>=
> if h > 100
>    then
>      h-2
>    else
>      h+2
> @
> 
> <<binding z>>=
> h := 3*h
> z := h
> @
> ---END aaa.spad.pamphlet
> 

BTW:  is the the test program supposed to be in good literate style?
both <<auxiliary computation>> and <<binding z>> change h without
any hint about such possibility in <<foo body>>.  I find such
practice _very_ bad for readability.

\start
Date: Sun, 18 Feb 2007 23:37:19 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: Re: No progress on notangle

> First I have noticed that notangle behaves in rather inconsitent
> way.

Really? I've met some cases where notangle does not as I would like, but 
these cases are rare.

> I do not want to waste time trying to find out exact rules used
> by notangle.  With pile semantics it seems better to integrate
> notangle like processing with Spad scanning and treat each hunk as
> a pile (IMHO having piles spanning hunk boundary is just confusing
> and error prone).

Of course, I would also forbid the equivalent way of saying

<<*>>=
foo(): () == {
    some code
@
some doc
<<*>>=
    some more code
}
@

But the code I gave was not of that style.

>> Furthermore what about the option "-L" that can be given to notangle?
>> That is particularly useful if your compiler emits a column number for 
>> error messages. #pile mode is bad in that case anyway, but there are 
>> also files that are indentation-independent.

> That could be easily addedd: the program traces line numbers anyway
> (for debugging purposes) so it would be easy to store them together
> with chunks and emit when needed.

But you know that then notangle doesn't indentate? If you remove the 
#line lines from the output of "notangle -L ..." you don't get the same 
output as "notangle ...". And this is actually a good thing. I once 
complaint about the missing indentation, but Norman refused to change 
the behaviour and he is right.

>> ---BEGIN aaa.spad.pamphlet
>> <<*>>=
>> foo(x: Integer): Integer == <<foo body>>
>> @
>>
>> <<foo body>>=
>> z := 1
>> for i in 1.. x repeat
>>      <<auxiliary computation>>
>>      h := <<post computation>>
>>      <<binding z>>
>> z
>> @
>>
>> <<auxiliary computation>>=
>> h := 1
>> for j in 1..i repeat
>>      h := h + j
>>      h := 2*h
>> @
>>
>> <<post computation>>=
>> if h > 100
>>    then
>>      h-2
>>    else
>>      h+2
>> @
>>
>> <<binding z>>=
>> h := 3*h
>> z := h
>> @
>> ---END aaa.spad.pamphlet

> BTW:  is the the test program supposed to be in good literate style?
> both <<auxiliary computation>> and <<binding z>> change h without
> any hint about such possibility in <<foo body>>.  I find such
> practice _very_ bad for readability.

Of course that was just a cooked up example for the indentation problem. 
What I like is code like...

<<implementation: gosperForm>>=
gosperForm(f: P, g: P): (P, P, P) == {
     import from FractionalRoot Integer;
     import from Integer;
     nonNegativeIntegerRoots: Generator Integer := {
         <<nonnegative integers $h$ with $\gcd(f(n),g(n+h))\ne1$>>
     }
     <<build up the Gosper triple $(p, q, c)$>>
     (p, q, c)
}
@

<<non-negative integers $h$ with $\gcd(f(n),g(n+h))\ne1$>>=
r: UPh := resultant(lift(f), lift(g)(n+h::UPhn));
v for i in integerRoots r | (v:=integralValue i) > 0;
@

<<build up the Gosper triple $(p, q, c)$>>=
c:P := 1;
p := f;
q := g;
for root in nonNegativeIntegerRoots repeat {
	u:P := gcd(p, q(x + root::P));
	p := quotient(p, u);
	q := quotient(q, u(x - root::P));
	for j in 1..root repeat c := c*u(x - j::P);
}
@

... and even that could be improved. (I omitted the latex part.)

Anyway, I don't claim that I know the best way to write literate programs.

\start
Date: 18 Feb 2007 17:26:37 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: GCC/GCL warning messages
Cc: Camm Maguire

Tim Daly writes:

| Camm,
| 
| I'm building the next Axiom release. During the GCL build I see a large
| number of messages that read:
| 
| gcl_defmacro.c:In function `L12':
| gcl_defmacro.c:79: warning: dereferencing type-punned pointer will
|  break strict-aliasing rules
| 
| C99 language semantics now assume that pointers to different types
| point to different memory locations, which is obvious nonsense, but
| part of the new standard.

That statement is obviously untrue. 

The non-aliasing rule, which has always been there since I don't know
when -- certainly, it is part of C89, and it is not a C99 invention --
says that the following is undefined behaviour

      double z;
      *(long*)&z = 1;
      printf ("%g", z);

That makes perfect sense.  Why would you think it is nonsense?

| You might want to add -fno-strict-aliasing option to the GCC command line.

Instead of papering over the incorrectness, I would suggest to fix it.

\start
Date: Sun, 18 Feb 2007 18:45:49 -0500
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: No progress on notangle

Ralf, I take it what you expect, based on your example, is
that notangle will "fill in" the pile spacing used by each
chunk in the output?  Is this default behavior or does it
need an option?

I must say I'm a bit confused - my original thought was that
all notangle had to do was get the code out of the chunks
"as is" line by line and stuff it into the output file in
the right order.  Can you point me to a couple examples of using
-L and what its effects/utility are?  (Sorry if they're in the
archives - I can try digging later.)

I've been reading over Waldek's code and I think I understand
what he is up to now, so I'll see what I can do with it - I can
see where automatic generation of some of this code via macro
would be a Good Thing.

Waldek, I'm not sure if others will find it useful but I do intend
to use it to try and make asdf load pamphlet files transparently.
(or more correctly, load code from pamphlet files.)  I really appreciate
the time you've put into this and I for one have learned something
from it :)

\start
Date: Mon, 19 Feb 2007 00:52:48 +0100 (CET)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: notangle

C Y wrote:
> --- Waldek Hebisch wrote:
> 
> > Below is a newer version of CL notangle, this time handling recursive
> > references.  There are still significant differences compared to
> > real notangle (lack of @ escapes, different end of line handling,
> > ...).
> 
> Well, we probably don't actually need the full power of noweb notangle
> - I think it makes more sense to enforce sane pamphlet writing style
> instead (improves human readability, for that matter - stays
> consistent).
> 
> By lack of @ escapes, do you mean that any @ in the file is treated as
> the end of a code chunk, e.g. no awareness of position?  (e.g. it won't
> be able to process itself as a pamphlet?)  From what I saw earlier the
> only two things that are really needed are recognizing an illegal chunk
> name due to newline inclusion (you may not even need that one the way
> you've defined your start and end chars) and making sure @ is right
> after a newline (at least for parsing Axiom files, which is the main
> goal.)  I'll have a go at it later and see how it behaves.
> 

Look at the following C program:
<<*>>=
int
fun(int x)
{
   return (x@<<8) | (x>>8);
}
@
<<8) | (x>>=
+
@

Normal notangle gives:

int
fun(int x)
{
   return (x<<8) | (x>>8);
}

while CL version gives:

int
fun(int x)
{
   return (x@+8);
}

Without the "8) | (x" chunk CL notangle would just halt on error.

> > I also fixed performace problem in scan-for-chunks (previous version
> > was using 'equal' and sbcl emited actual call to 'equal', current
> > version uses 'eql' which generates inline code).  Another performance
> > problem was using arrays of bytes as hash keys (completly killed
> > performance for pamphlets with many small chunks, or chunks
> > split into many small pieces).  I solved this problem converting
> > arrays to strings before hashing.
> 
> Wow.  VERY impressive work.  One question Waldek - I'm willing to try
> to convert this code into a literate document for purposes of Axiom
> inclusion, but I fear I'm not competent to describe these issues and
> reasons for specific choices.  I'll take a stab at it using your emails
> as a starting point (indeed, that might be a good way to ensure the
> documentation covers enough for other clueless beginners) but are you
> up for a few painfully ignorant questions? ;-)
>

Ask, I will try too answer.
 
> Also, are you OK with the modified BSD license for this?  It's
> essentially all your code at this point so I don't want to presume.
>

Sure, I prefer to omit license from files to avoid clutter, but use
the code any way you wish.  For Axiom distribution probably putting
a single line like "For legal info see Axiom.Licence" could be a good
compromise between beetween legal pedantry and practicality.
 
> > This version seem to be significantly faster than notangle: it is
> > able to process simple 8 Mb file (containing few big chunks) in 0.14s
> > while notangle needs 2s.  On 8Mb file containing 1000 chunks, each
> > consisting of 100 pieces 10 lines each, my version needs 0.24s, while
> > notangle uses 2.85s. 
> 
> You may have just become the poster child for those trying to debunk
> the "lisp is slow" myth ;-).
>
 
Do not be too eager with this.  It is clear that even for strings
hashtables take a lot of time.  We are forced to do an otherwise
useless copy to string to avoid huge slowdon.  And in the main
loop the code is clearly worse then the code from a C compiler.
So the program is probably faster than similar Perl or Python
programs, but slower than good C version.

> > BTW. Timing was done on 2GHz Athlon 64.  Notangle came from Axiom
> > build, Lisp is sbcl 1.0.  I tried also clisp, but it is quite slow
> > (need 8.73 senconds on my second test file) -- no wonder since I use
> > a low level code.  This version (like the previous one) does not
> > work with gcl (ANSI 2.6.5 interpreter claims that 'read-sequence'
> > is undefined, non-ANSI interpreter chokes on 'defclass').
> 
> Um.  Clisp doesn't surprise me, and normally if speed is a concern
> people don't run on Clisp anyway.  I also ran into the defclass thing
> on GCL - perhaps we could use defstruct instead?  I don't know that
> there's any particular reason to use CLOS other than convenience and
> trying to be "modern".
> 

Yes, defstruct should be enough.  'read-sequence' (and I guess also
'write-sequence') causes more problems, because performance depends on
it.  For gcl we probably must provide our own (calling C) versions.

\start
Date: Mon, 19 Feb 2007 01:26:10 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: No progress on notangle

On 02/19/2007 12:45 AM, C Y wrote:
> Ralf, I take it what you expect, based on your example, is
> that notangle will "fill in" the pile spacing used by each
> chunk in the output?  Is this default behavior or does it
> need an option?

Getting the indentation right is the default behaviour. But it can get 
rather complicated.

---BEGIN aaa.spad.pamphlet
<<*>>=
<<blah>><<foo>>
         bar
@
<<blah>>=
x
  XX
@
<<foo>>=
y
  YY
@
---END aaa.spad.pamphlet

What would you expect? Perhaps
=================
x
  XXy
          YY
         bar
=================
??? That is what I get with

notangle aaa.spad.pamphlet

Contrary to that with

notangle -L'#line %L "aaa.spad.pamphlet"%N' aaa.spad.pamphlet

I get

=============================
#line 7 "aaa.spad.pamphlet"
x
  XX
#line 11 "aaa.spad.pamphlet"
y
  YY
#line 4 "aaa.spad.pamphlet"
         bar
=============================

> I must say I'm a bit confused - my original thought was that
> all notangle had to do was get the code out of the chunks
> "as is" line by line and stuff it into the output file in
> the right order.  Can you point me to a couple examples of using
> -L and what its effects/utility are?  (Sorry if they're in the
> archives - I can try digging later.)

I know you have downloaded Aldor-Combinat. After saying "make dvi"
you find two types of .as files under the src directory.

series.as   -- generated without -L option
csseries.as -- generated with -L option.

Ignore the +++ comments since they are missing in the files that are not 
prefixed by cs.

But generally the indentation with -L is *exactly* as in the original 
source i.e. the .pamphlet/.nw file.

\start
Date: Mon, 19 Feb 2007 01:41:44 +0100 (CET)
From: Waldek Hebisch
To: Ralf Hemmecke
Subject: Re: No progress on notangle

> > First I have noticed that notangle behaves in rather inconsitent
> > way.
> 
> Really? I've met some cases where notangle does not as I would like, but 
> these cases are rare.
>

Suppose that your program contains an arbitrary sequence of '@', '<<'
and '>>'.  Do you know how to write the source file to get required
output?  I did not want to waste time on this problem, but a few
trials gave rather bizzare results.

Your example suggest that notangle is consistent in its indentation
rules, but if you take "random" input the results look strange.

Also, I thought that notagle is inconsistent in it treatment of
tabs (sometimes mangles then, but preserves leading tabs in Makefiles),
but it seems that normaly notagle consistently mangles tabs and
just needs extra option to preserve tabs.

> >> Furthermore what about the option "-L" that can be given to notangle?
> >> That is particularly useful if your compiler emits a column number for 
> >> error messages. #pile mode is bad in that case anyway, but there are 
> >> also files that are indentation-independent.
> 
> > That could be easily addedd: the program traces line numbers anyway
> > (for debugging purposes) so it would be easy to store them together
> > with chunks and emit when needed.
> 
> But you know that then notangle doesn't indentate? If you remove the 
> #line lines from the output of "notangle -L ..." you don't get the same 
> output as "notangle ...". And this is actually a good thing. I once 
> complaint about the missing indentation, but Norman refused to change 
> the behaviour and he is right.

ATM CL version also do not indentate.  It puts first char of the chunk
in the same line as <<xxx>> marker, but of course printing '#line' we
can also emit a newline before it.

> Of course that was just a cooked up example for the indentation problem. 
> What I like is code like...
> 
> <<implementation: gosperForm>>=
> gosperForm(f: P, g: P): (P, P, P) == {
>      import from FractionalRoot Integer;
>      import from Integer;
>      nonNegativeIntegerRoots: Generator Integer := {
>          <<nonnegative integers $h$ with $\gcd(f(n),g(n+h))\ne1$>>
>      }
>      <<build up the Gosper triple $(p, q, c)$>>
>      (p, q, c)
> }
> @
> 
> <<non-negative integers $h$ with $\gcd(f(n),g(n+h))\ne1$>>=
> r: UPh := resultant(lift(f), lift(g)(n+h::UPhn));
> v for i in integerRoots r | (v:=integralValue i) > 0;
> @
> 
> <<build up the Gosper triple $(p, q, c)$>>=
> c:P := 1;
> p := f;
> q := g;
> for root in nonNegativeIntegerRoots repeat {
> 	u:P := gcd(p, q(x + root::P));
> 	p := quotient(p, u);
> 	q := quotient(q, u(x - root::P));
> 	for j in 1..root repeat c := c*u(x - j::P);
> }
> @
> 
> ... and even that could be improved. (I omitted the latex part.)
> 
> Anyway, I don't claim that I know the best way to write literate programs.

I am asking to understand which features of notangle are useful.  Would
you need notangle for a programming language where by default input is
a comment, all code must be in procedures/functions, you can write
procedures in arbitrary order and you can have arbitrary procedure names
(but with special begin/end name markers).
In such language your example could look like:

<<implementation: gosperForm>>(f: P, g: P): (P, P, P)=
      import from FractionalRoot Integer;
      import from Integer;
      nonNegativeIntegerRoots: Generator Integer := {
          <<nonnegative integers $h$ with $\gcd(f(n),g(n+h))\ne1$>>(f, g, h)
      }
      <<build up the Gosper triple $(p, q, c)$>>
      (p, q, c)
@

<<non-negative integers $h$ with $\gcd(f(n),g(n+h))\ne1$>>(f, g, h)=
r: UPh := resultant(lift(f), lift(g)(n+h::UPhn));
v for i in integerRoots r | (v:=integralValue i) > 0;
@
....

That would be less flexible that notangle because of need for explicit
parameter passing, but at least for me having explicit parameters 
(and explicit scopes) makes text more readable.

\start
Date: Sun, 18 Feb 2007 21:25:41 -0500
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: notangle

Waldek Hebisch wrote:

>> You may have just become the poster child for those trying to debunk
>> the "lisp is slow" myth ;-).
>  
> Do not be too eager with this.  It is clear that even for strings
> hashtables take a lot of time.  We are forced to do an otherwise
> useless copy to string to avoid huge slowdon.  And in the main
> loop the code is clearly worse then the code from a C compiler.
> So the program is probably faster than similar Perl or Python
> programs, but slower than good C version.

Don't worry - I'm not usually one to get involved with language
wars anyway.  But I think by any measure we would want to worry
about this result is excellent - after all, notangle as a percentage
of the total build time looks to be pretty small, so at some point
the time put in to optimize further reaches diminishing returns.
This solution should integrate well with Axiom, perform very well,
and can be expanded upon for other uses (like the SPAD compiler).

Thanks for all the effort to fix my original code - I'll see if
I can make defstruct work and get something that will do for
GCL as well.

(One question - I thought read-sequence was part of the ANSI
Common Lisp spec?  Is it just that GCL hasn't implemented it yet?
Of course it's not so critical since we aren't running on the
ANSI image yet anyway.)

\start
Date: 19 Feb 2007 12:15:07 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: status of windows version

Dear all,

sorry about asking a FAQ...

Tomorrow I will have to install Axiom on a MS Windows machine for a very
renowned professor who wants to use my guessing package.

Is there anything I should be aware of? Is Windows version 0.1.4 the current
version? Is there any way to make hyperdoc, i.e., the "browse" functionality,
available under windows?

I guess wh-sandbox does not run under windows? (Bill said, build-improvements
does...)

\start
Date: Mon, 19 Feb 2007 09:31:30 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: status of windows version
Cc: Gabriel Dos Reis, Waldek Hebisch

On February 19, 2007 6:15 AM Martin Rubey wrote:
> 
> sorry about asking a FAQ...
>

:-) No so frequent, I think.

> Tomorrow I will have to install Axiom on a MS Windows machine 
> for a very renowned professor who wants to use my guessing
> package.
> 
> Is there anything I should be aware of? Is Windows version 
> 0.1.4 the current version?

Yes - current as of 2 years ago. :-(

> Is there any way to make hyperdoc, i.e., the "browse"
> functionality, available under windows?
> 

No, not at present. I think the best way of supporting hyperdoc
on Windows is to use Microsoft Virtual PC (or VMware, both are
free) and install a linux system on the virtual machine, then
install Axiom, e.g. wh-sandbox. I use Virtual PC extensively.
It works very well - especially if you have at least a dual-core
machine and enough ram (at least 1 Gb.). If you need help with

> I guess wh-sandbox does not run under windows? (Bill said, 
> build-improvements does...)
> 

Yes, I have successfully built build-improvments on Windows.
Of course since there is no X-windows environment of Windows,
hyperdoc and graphics are not built.

wh-sandbox was branched from build-improvements before the
ability to build on Windows was added so, no, I don't think
wh-sandbox will build on Windows at this time. It would be nice
if Waldek or Gaby could merge the build-improvements branch
with the wh-sandbox branch. If they could do that, I think
it would form a very good basis for a new Axiom Silver
distribution.

\start
Date: 19 Feb 2007 09:24:39 -0600
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: status of windows version
Cc: Waldek Hebisch

Bill Page writes:

[...]

| wh-sandbox was branched from build-improvements before the
| ability to build on Windows was added so, no, I don't think
| wh-sandbox will build on Windows at this time. It would be nice
| if Waldek or Gaby could merge the build-improvements branch
| with the wh-sandbox branch. If they could do that, I think
| it would form a very good basis for a new Axiom Silver
| distribution.

Waldek is more familiar with wh-sandbox than me, so I would pass the
ball to him :-)

However, there are other experiments in wh-sandbox that we should
discuss before we consider it basis for Axiom Silver.  That discussion
surely would be long and intense; so I would prefer Waldek works more
on it before we get to that point.

\start
Date: Mon, 19 Feb 2007 08:32:56 -0800 (PST)
From: Cliff Yapp
To: Bill Page, Martin Rubey
Subject: RE: status of windows version
Cc: Waldek Hebisch, Gabriel Dos Reis

--- Bill Page wrote:

> > I guess wh-sandbox does not run under windows? (Bill said, 
> > build-improvements does...)
> 
> Yes, I have successfully built build-improvments on Windows.

Bill, is that result something we could wrap up in the NSIS installer
and push out as a release?

> Of course since there is no X-windows environment of Windows,
> hyperdoc and graphics are not built.

Maybe as an alternative to command-line-only we could bundle ntemacs
and the Emacs mode, and rig it to start that up when the icon is
clicked?  Axiom is big enough that a few more megs probably won't break
anybody's back, and we could always provide a "no-emacs" binary if
someone wanted it.

When I tested emacs mode + Axiom on Windows it did succeed, give or
take a bug in turning input red when it is changed.  (the latest cvs
emacs build fixed it but I doubt we would want to distribute that.)
 
Unfortunately, I don't have access to a Windows box so I'm not much
help on this issue :-(.

\start
Date: Tue, 20 Feb 2007 01:19:46 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: status of windows version

Gabriel Dos Reis wrote:
> Bill Page writes:
> 
> [...]
> 
> | wh-sandbox was branched from build-improvements before the
> | ability to build on Windows was added so, no, I don't think
> | wh-sandbox will build on Windows at this time. It would be nice
> | if Waldek or Gaby could merge the build-improvements branch
> | with the wh-sandbox branch. If they could do that, I think
> | it would form a very good basis for a new Axiom Silver
> | distribution.
> 
> Waldek is more familiar with wh-sandbox than me, so I would pass the
> ball to him :-)

Well, I actually intended to bulk-merge changes to build-improvements
but some changes (like removal of DESTDIR) look backwards, some other
changes (src/algebra/Makefile.pamphlet and src/interp/Makefile.pamphlet)
are from my point of view mostly irrelevant (due to new algebra
bootstrap).  In general many changes looks like incomplete transitions
(was there any reason not to ansify graph subdirectory?).  I could
probably just pick changes needed for Windows build.  But I decided
to not do so for two reasons:
- it would make full merge harder
- it is rather incovenint for me to test on Windows

> However, there are other experiments in wh-sandbox that we should
> discuss before we consider it basis for Axiom Silver.  That discussion
> surely would be long and intense; so I would prefer Waldek works more
> on it before we get to that point.

Let me summarize main changes in wh-sandbox:

1) removal of unused code from compiler/interpreter
2) translating depsys using Shoe and removal of depsys bootstrap Lisp
3) new algebra bootstrap and removal of algebra bootstrap Lisp
4) mechanical generation of (most of) .pht pages
5) hyperdoc and algebra fixes
6) removal of useless files
7) pretty-printing of intermediate files and asq rewrite
8) adding guessing package written by Martin Rubey

Given change may be split into multiple commits, but looking at change
log should be clear how to categorize commits.  Somebody making a
release may prefer to pick only bug fixes (position 5) or maybe
also guessing package.  To large degree this should be possible since
(IIRC) only some documentation fixes depend on generation of .pht pages
(and one can just pick the newly generated pages), otherwise fixes do not
depend on structural changes.  OTOH I consider structural changes
essential for future Axiom maintenance.  I plan much deeper structural
changes, but IMHO they already give significant benefits.  There
are some costs, for example new algebra bootstrap takes more time than
the old one.  I feel reasonably confident that changes I made work
correctly so if I was making a release I would include them.  

\start
Date: Mon, 19 Feb 2007 18:32:35 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: status of windows version

On Tue, 20 Feb 2007, Waldek Hebisch wrote:

| Well, I actually intended to bulk-merge changes to build-improvements
| but some changes (like removal of DESTDIR) look backwards, some other

It is a mistake to defined DESTDIR in a Makefile.  The solution
I implemented in the build-improvements was a mild fix.  The real
fix is to remove the definition.  Which is what happened.

[...]

| 1) removal of unused code from compiler/interpreter

I'm nervous about code removal when I have not understood beyond "it
is dead code".  It does not mean I'm opposed to it.  I'm saying I'd
like to understand why the code is removed.

\start
Date: Tue, 20 Feb 2007 03:05:19 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Lisp comparator

Below is a little utility that I use to compare Lisp files produced
by Axiom.  Axiom uses uninterned (gensymed) symbols in its output.
Such sumbols are printed like '#:G706711' where the numbers depend
on computation history.  When Lisp is reading the file the numbers
does not matter at all -- what matter is if two such symbols are
equal (which is marked in special way) or different.  When comparing
files as texts different numbering of gensymed symbols give a lot
of spuriouos differences.  The program below can discard most such
differences (it does not recurse into arrays, so it may sometimes
show difference for textually identical files).

Note that this _not_ a polished code, just something that other may
find useful (comments show how the code may be called).  BTW, I use
the Lisp code via a shell wrapper:

-------------<start wrapper>------------------
#!/bin/sh
exec /usr/bin/sbcl --noinform --noprint \
       --load /var/tmp/hebisch/axp4/pp/ldiff.fasl \
       --disable-debugger \
       --eval '(make-package "VMLISP")' \
       --eval '(make-package "BOOT")' \
       --eval '(compare-files "'"$1"'" "'"$2"'")' \
       --eval '(sb-ext:quit)'
#      --disable-debugger
-------------<end wrapper>--------------------



(defun read-forms (file)
    (let ((result nil) (pp))
         (do () (nil)
             (setf pp (read file nil nil))
             (if (null pp)
                 (return-from read-forms (reverse result))
                 (setf result (cons pp result))))))

;;; (compare-forms '(ala ola "as" (1 2 3)) '(ala ola "as" (1 2 3)))
(defun compare-forms (f1 f2)
(let ((sym-hash1 (make-hash-table))
      (sym-hash2 (make-hash-table))
      (sym-count 0))

(labels
((compare-forms-0 (f1 f2)
    (cond
         ((consp f1)
             (if (not (consp f2))
                 (return-from compare-forms nil))
             (do () (nil)
                 (let ((el1 (car f1)) (el2 (car f2)))
                      (setf f1 (cdr f1))
                      (setf f2 (cdr f2))
                      (if (not (compare-forms-0 el1 el2))
                          (return-from compare-forms nil)))
                 (if (not (and (consp f1) (consp f2)))
                     (return-from compare-forms-0
                         (compare-forms-0 f1 f2))))
             t)
         ((and (symbolp f1) (not (symbol-package f1)))
             (if (or (not (symbolp f2)) (symbol-package f2))
                 (return-from compare-forms nil))
             (let ((pp1 (gethash f1 sym-hash1))
                   (pp2 (gethash f2 sym-hash2)))
                  (if (not (equal pp1 pp2))
                       (return-from compare-forms nil))
                  (cond
                       ((not pp1)
                            (incf sym-count)
                            (setf (gethash f1 sym-hash1) sym-count)
                            (setf (gethash f2 sym-hash2) sym-count)))
                  t))
         (t (equalp f1 f2)))))
(compare-forms-0 f1 f2))))

(defun print-heading (el)
    (let ((*print-level* 2) (*print-length* 3))
        (pprint el)))
;;; (compare-files "/mn/a6/pom/axiom/nn5/ax-build1/int/algebra/INT.NRLIB/code.lsp" "/mn/a6/pom/axiom/nn6/ax-build1/int/algebra/INT.NRLIB/code.lsp")
(defun compare-files (name1 name2)
    (let* ((fil1 (open name1 :direction :input :if-does-not-exist :error))
           (fil2 (open name2 :direction :input :if-does-not-exist :error))
           (l1 (read-forms fil1)) (l2 (read-forms fil2)) (el2 nil))
         (dolist (el1 l1)
             (if (not (consp l2))
                 (return-from compare-files (and (format t "short l2~&") nil)))
             (setf el2 (car l2))
             (setf l2 (cdr l2))
             (if (not (compare-forms el1 el2))
                 (progn ()
                      (format t "Difference in:")
                      (print-heading el1)
                      (format t "~&and:")
                      (print-heading el2)
                      (format t "~&")
                      (return-from compare-files nil))))
         (not l2)))

\start
Date: Mon, 19 Feb 2007 20:47:06 -0600
From: Tim Daly
To: Cliff Yapp, Waldek Hebisch
Subject: lisp speedups

Another technique that significantly improves the speed of lisp
code is the use of declarations. In general, a function call in 
lisp has to have a case statement of the possible types of each
argument and needs to handle the possible types. However, if you
tell the compiler what the argument types are and the return types
are you can get significantly faster code. The best way to illustrate
this is to use the DISASSEMBLE function which will show you the code
that gets laid down by the lisp compiler. CMUCL and SBCL are very
good at optimizing code. GCL also does an excellent job. That's what
the .fn files are for in Axiom.

So, if you have a function + and you say:
   (+ a b)
the compiler cannot assume that a or b are anything so it has to
check for arguments such as lists. 

You can improve the calling code by using THE... as in
  (+ (the integer a) (the integer b))

Lisp can optimize a bit further if you know that the arguments will
always be less than a machine-sized integer, called a FIXNUM. Then
you can say:

  (+ (the fixnum a) (the fixnum b))

However you haven't told the compiler that the result will not
exceed a machine fixnum. You can do this with:

  (the fixnum (+ (the fixnum a) (the fixnum b)))

And now the compiler can improve the function call, potentially 
even inlining the + operation and reducing it to a single machine
add instruction. It can assume that the add will get two machine
sized integers and return a machine-sized result without overflow.

Type declarations can cause a huge speed improvement. CMUCL and
SBCL have amazing optimizing compilers that use type information well.

GCL can automatically generate the type information for all of
the functions in a file. If you first load the GCL file, gcl_collectfn.lsp
and then tell the compiler to emit the type definitions you'll get a .fn
file. So the sequence for optimizing is:

(load "gcl_collectfn.lsp")
(compiler::emit-fn t)
(compile-file "yourfile.lisp")
(load "yourfile.fn")
(compile-file "yourfile.lisp")

The first compile-file will generate the .fn, which contains the type
info (and you can hand-augment this if you like), and the second compile-file
will generate much faster code. Once you know this type information you can
hand code it in your original source file and eliminate the collectfn step.

You can do global declarations using PROCLAIM and DECLARE.

See http://www.lrdr.epita.fr/dload/papers/verna.06.imecs.pdf
"How to make Lisp go faster than C"

\start
Date: Tue, 20 Feb 2007 04:51:21 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: lisp speedups

> Another technique that significantly improves the speed of lisp
> code is the use of declarations. In general, a function call in 
> lisp has to have a case statement of the possible types of each
> argument and needs to handle the possible types. However, if you
> tell the compiler what the argument types are and the return types
> are you can get significantly faster code. The best way to illustrate
> this is to use the DISASSEMBLE function which will show you the code
> that gets laid down by the lisp compiler. CMUCL and SBCL are very
> good at optimizing code. GCL also does an excellent job. That's what
> the .fn files are for in Axiom.
>

The program I posted uses declarations.  AFAICS sbcl has enough 
information about types, from the declarations I gave it can infer
the rest (in my experiance gcl needs much more declarations).
When I wrote that the code could be faster I examined also output
of dissasemble.  The following snippet:

       normal-start
         (incf pos)
         (incf line-number)
         (if (>= pos end-buff)
             (return-from scan-for-chunks))
         (setf code (aref buff pos))
         (if (eql code start-tag-code-1)
             (go chunk-start-tag-1))
         (if (eql code newline-code)
             (go normal-start))
         (go normal)

corresponds to the following assembly code:

;     2AF4: L1:   488B4DD0         MOV RCX, [RBP-48]
;     2AF8:       4883C108         ADD RCX, 8
;     2AFC:       48894DD0         MOV [RBP-48], RCX
;     2B00:       488B55D0         MOV RDX, [RBP-48]
;     2B04:       488B45C8         MOV RAX, [RBP-56]
;     2B08:       488B48F9         MOV RCX, [RAX-7]
;     2B0C:       488B45C8         MOV RAX, [RBP-56]
;     2B10:       4839D1           CMP RCX, RDX
;     2B13:       0F86ED0B0000     JBE L48
;     2B19:       48C1FA03         SAR RDX, 3
;     2B1D:       488B45C8         MOV RAX, [RBP-56]
;     2B21:       480FB64C1001     MOVZX RCX, BYTE PTR [RAX+RDX+1]
;     2B27:       48C1E103         SHL RCX, 3
;     2B2B:       4883F950         CMP RCX, 80
;     2B2F:       0F840F090000     JEQ L34
;     2B35:       EBBD             JMP L1

Why this code is far from optimal?  First, sbcl failed to allocate
variables to registers.  FYI I use AMD64 machine and sbcl in principle
can use 14 general purpose registers (there is 16 registers, but two,
stack pointer RSP and base pointer RBP are used bu sbcl).  The
'scan-for-chunks' function has 11 variables, so it does not look very
hard to allocate _all_ variables into registers.  But apparently sbcl
not only failed to keep variables in registers, it also reloads value
which is still available in register.  Second, there are useless shifts
-- variable code is always used in comparison with (constant) integers
and pos is mostly used in integer operations (it is also stored in
lists).

As a compiler writer I can understand why sbcl is unable to produce
better code.  But I would not call it excellent.
 
\start
Date: Tue, 20 Feb 2007 05:40:43 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: status of windows version

> On Tue, 20 Feb 2007, Waldek Hebisch wrote:
> 
> | Well, I actually intended to bulk-merge changes to build-improvements
> | but some changes (like removal of DESTDIR) look backwards, some other
> 
> It is a mistake to defined DESTDIR in a Makefile.  The solution
> I implemented in the build-improvements was a mild fix.  The real
> fix is to remove the definition.  Which is what happened.
>

OK, my mistake -- after quick scanning I thought that you removed
DESTDIR support.  Now I see that you implemented correct handling.
 
\start
Date: Tue, 20 Feb 2007 17:48:27 +0100
From: Gregory Vanuxem
To: list
Subject: Current directory at startup

Hello,

I have just built wh-sandbox and found a _serious_ bug. It's present in
Build-improvement too (and probably Gold). Last time, I uploaded a
binary version of Axiom I made an error, I added the function 'reroot'
just before the uploading and this function is wrong, at least in the
version on which I'm working. The problem is that at startup the
"current directory" is incorrectly set and if you compile a file it will
compile the one in your home directory instead of the one in the current
directory (if the "basenames" are identical). This issue can mess up the
build process (it happened with build-improvement (version 395)).

There is another problem with file (fixed in wh-sandbox): probe-file no
longer works on directory. Tim I think you should take care of these
issues if you plan to release a new version of Gold, several persons
already reported problems related to this one (with fixes too I
believe).

Greg

PS: See reroot (bookvol5), make-input-filename (nlib.lisp) etc...

\start
Date: Tue, 20 Feb 2007 18:04:29 +0100
From: Gregory Vanuxem
To: list
Subject: Re: Current directory at startup

Some (?) other issues:

(1) -> )cd temp
   The current AXIOM default directory
is /home/greg/wh-axiom/axiom/target/x86_64-unknown-linux/
(1) -> )cd
   The current AXIOM default directory is /home/greg/
(1) -> )cd temp

   >> System error:
   #p"/home/greg/" is not of type SEQUENCE.

the /home/greg/temp directory exists.

Greg

PS : Bill, in the bug report that you sent me, you mention two bugs but
I think there was only one bug, )cd without parameter changes the
working directory to $HOME ($HOMEPATH on Windows I think) :


(1) -> )sys cd
C:\Documents and Settings\Administrator.ASUS\My Documents

---> The current system path is correct.

(1) -> )cd
   The current AXIOM default directory is
      C:\Documents and Settings\Administrator.ASUS\
     
---> This current directory is wrong. So this file is not found.



Le mardi 20 f=E9vrier 2007 =E0 17:48 +0100, Gregory Vanuxem a =E9crit :
> Hello,
>
> I have just built wh-sandbox and found a _serious_ bug. It's present in
> Build-improvement too (and probably Gold). Last time, I uploaded a
> binary version of Axiom I made an error, I added the function 'reroot'
> just before the uploading and this function is wrong, at least in the
> version on which I'm working. The problem is that at startup the
> "current directory" is incorrectly set and if you compile a file it wil=
l
> compile the one in your home directory instead of the one in the curren=
t
> directory (if the "basenames" are identical). This issue can mess up th=
e
> build process (it happened with build-improvement (version 395)).
>
> There is another problem with file (fixed in wh-sandbox): probe-file no
> longer works on directory. Tim I think you should take care of these
> issues if you plan to release a new version of Gold, several persons
> already reported problems related to this one (with fixes too I
> believe).
>
> Greg
>
> PS: See reroot (bookvol5), make-input-filename (nlib.lisp) etc...

\start
Date: Wed, 21 Feb 2007 10:31:43 -0500
From: Bill Page
To: list
Subject: First about Sage published

Althought this is not directly about Axiom, it might be of interest
to note that Sage does include an interface to Axiom as well as
several other computer algebra systems. I think it is remarkable
that a system that is less than two years old is already the basis
of a new book - even if the author of the book is also the (primary)
author of the system.

http://www.ams.org/bookstore-getitem/item=gsm-79

Modular Forms, a Computational Approach
William Stein

The leading expert in computations with modular forms demystifies
this process with practical algorithms . free software is available
to assist with exercises .

--

Review

This marvellous and highly original book fills a significant gap in
the extensive literature on classical modular forms. This is not
just yet another introductory text to this theory, though it could
certainly be used as such in conjunction with more traditional
treatments. Its novelty lies in its computational emphasis
throughout: Stein not only defines what modular forms are, but shows
in illuminating detail how one can compute everything about them in
practice. This is illustrated throughout the book with examples from
his own (entirely free) software package SAGE, which really bring the
subject to life while not detracting in any way from its theoretical
beauty. The author is the leading expert in computations with modular
forms, and what he says on this subject is all tried and tested and
based on his extensive experience. As well as being an invaluable
companion to those learning the theory in a more traditional way,
this book will be a great help to those who wish to use modular forms
in applications, such as in the explicit solution of Diophantine
equations. There is also a useful Appendix by Gunnells on extensions
to more general modular forms, which has enough in it to inspire many
PhD theses for years to come. While the book's main readership will
be graduate students in number theory, it will also be accessible to
advanced undergraduates and useful to both specialists and non-
specialists in number theory.

--John E. Cremona, University of Nottingham

William Stein is an associate professor of mathematics at the
University of Washington at Seattle. He earned a PhD in mathematics
from UC Berkeley and has held positions at Harvard University and
UC San Diego. His current research interests lie in modular forms,
elliptic curves, and computational mathematics.

--

Oh, for the "glory days" of Axiom when Axiom might have been the
tool of choice for this type of work!

\start
Date: Wed, 21 Feb 2007 13:47:26 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: status of windows version
Cc: Waldek Hebisch, Gabriel Dos Reis

On February 19, 2007 11:33 AM C Y wrote:
> 
> --- Bill Page wrote:
> 
> > > I guess wh-sandbox does not run under windows? (Bill said, 
> > > build-improvements does...)
> > 
> > Yes, I have successfully built build-improvments on Windows.
> 
> Bill, is that result something we could wrap up in the NSIS installer
> and push out as a release?
> 

I think that's a great idea - especially if we also merge the bug
fixes from wh-sandbox.

If you would like to do this, please let me know. I would be glad
to help. Compiling the windows version is described on the Axiom
Wiki. Using NSIS to package the result is very easy.

\start
Date: 21 Feb 2007 20:08:27 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: status of windows version
Cc: Waldek Hebisch, Gabriel Dos Reis

Bill Page writes:

> On February 19, 2007 11:33 AM C Y wrote:

> > Bill, is that result something we could wrap up in the NSIS installer and
> > push out as a release?
> > 
> 
> I think that's a great idea - especially if we also merge the bug fixes from
> wh-sandbox.

It would be great if you could package my guessing package, too. It is quite
annoying needing access to somebody's computer just to have it installed. (I
succeeded, though)

Another thing: is Aldor working with wh-sandbox / build improvements?

It is quite possible that I will have a chance to present Ralf's and my work at
the "Seminaire Lotharingien" end of march. Would be nice to have cd's as
giveaways...

\start
Date: Wed, 21 Feb 2007 15:00:27 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: status of windows version
Cc: Waldek Hebisch, Gabriel Dos Reis

On February 21, 2007 2:08 PM Martin Rubey wrote:
> 
> Bill Page writes:
> 
> > On February 19, 2007 11:33 AM C Y wrote:
> 
> > > Bill, is that result something we could wrap up in the 
> > > NSIS installer and push out as a release?
> > > 
> > 
> > I think that's a great idea - especially if we also merge 
> > the bug fixes from wh-sandbox.
> 
> It would be great if you could package my guessing package, 
> too.

As you know, Waldek has added your integer sequence guessing
package to wh-sandbox, however wh-sandbox has not yet been
shown to build on Windows. I doubt that wh-sandbox will build
on Windows at this time since it was branched from an earlier
version of build-improvements before the Windows build was
possible. There are changes needed specifically to avoid trying
to build the components dependent on X-windows.

On the other hand wh-sandbox now uses a much better algebra
bootstrap method which makes it simpler to add new algebra which
build-improvements doesn't have yet. This might complicate things
until/when Gaby and Waldek manage to merge these two developments.
I recall the problems you had trying to add GUESS to the Axiom
Gold distribution.

> It is quite annoying needing access to somebody's computer
> just to have it installed. (I succeeded, though)

Were you able to install GUESS on the Windows version of Axiom?

> 
> Another thing: is Aldor working with wh-sandbox / build-
> improvements?

Aldor, oh Aldor, will you ever be free?

Aldor does work with build-improvemnts. (That is what we are
currently using on the Axiom Wiki server.) I am not sure about
wh-sandbox (because of the change in bootstrap method) but I
believe that it should be quite easy to install Aldor on that
version too since basically, Aldor support is just added on
top.

> 
> It is quite possible that I will have a chance to present 
> Ralf's and my work at the "Seminaire Lotharingien" end of
> march. Would be nice to have cd's as giveaways...
> 

Do you mean something like the Doyen LiveCD? Perhaps we need
to encourage Alfredo to produce a new version...

\start
Date: 21 Feb 2007 22:42:08 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: status of windows version
Cc: Gabriel Dos Reis, Waldek Hebisch

Bill Page writes:

> > It would be great if you could package my guessing package, too.
> 
> As you know, Waldek has added your integer sequence guessing package to
> wh-sandbox, however wh-sandbox has not yet been shown to build on Windows. I
> doubt that wh-sandbox will build on Windows at this time since it was
> branched from an earlier version of build-improvements before the Windows
> build was possible. There are changes needed specifically to avoid trying to
> build the components dependent on X-windows.

Yes. In fact, that's the greatest pain of all: no HyperDoc on Windows.

> > It is quite annoying needing access to somebody's computer just to have it
> > installed. (I succeeded, though)
> 
> Were you able to install GUESS on the Windows version of Axiom?

Yes, it's trivial - apart from the fact that it takes roughly half an hour to
compile. But I cannot expect anybody to start with axiom by learning how to
compile a package. Well, I could really provide an input file "compile.input"
and another one "load.input". Still, I'd like it better if it was included.

> > Another thing: is Aldor working with wh-sandbox / build- improvements?

> Aldor does work with build-improvemnts. (That is what we are currently using
> on the Axiom Wiki server.) I am not sure about wh-sandbox (because of the
> change in bootstrap method) but I believe that it should be quite easy to
> install Aldor on that version too since basically, Aldor support is just
> added on top.

Great!

> > It is quite possible that I will have a chance to present Ralf's and my
> > work at the "Seminaire Lotharingien" end of march. Would be nice to have
> > cd's as giveaways...
> 
> Do you mean something like the Doyen LiveCD? Perhaps we need to encourage
> Alfredo to produce a new version...

Yes. But, as you remarked above, no Guessing package with Gold. And no
Aldor. I'd need both, plus ALLPROSE, plus aldor-combinat.

\start
Date: 21 Feb 2007 22:48:42 +0100
From: Martin Rubey
To: list
Subject: Bug with paths in wh-sandbox
Cc: Waldek Hebisch

I made wh-sandbox available on my linux box for other members of the
departement by setting the file permissions of

~/axiom

(the install directory) appropriately. However, it seems that axiom wants the
build directory to be availble. I received the following notice:

Ein weiteres Problem, das bei putty aufgetreten ist, war die folgende Fehlermeldung:
(1) ->
(1) -> f(0)==0
                                                                   Type: Void
(2) -> f(1)==1
                                                                   Type: Void
(3) -> f(n)==f(n-1)+f(n-2)
                                                                   Type: Void
(4) -> f(7)
   Compiling function f with type Integer -> NonNegativeInteger
   Compiling function f as a recurrence relation.
cc1: Fehler: /local/scratch/wh-sandbox/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h: Permission denied


Apart from these minor glitches, wh-sandbox is working very well, it seems!
Thank you,

\start
Date: Wed, 21 Feb 2007 20:25:17 -0500
From: Alfredo Portes
To: Bill Page
Subject: Re: status of windows version
Cc: Waldek Hebisch, Gabriel Dos Reis

> Do you mean something like the Doyen LiveCD? Perhaps we need
> to encourage Alfredo to produce a new version...

No encouragement needed just more time :-).

Please let me know what Axiom "version" should I use or if I should
wait for a possible new Silver (build-improvements + wh-sandbox).

One possibility for those that need hyperdoc on Windows is using
vmware + Doyen.

Sorry Martin about not having the CD ready for your presentation last
time. By the way, I don't know if it was ever addressed the problem with Gold
patch 50 that would break HyperDoc when adding Martin's package.

\start
Date: 21 Feb 2007 23:15:02 -0600
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Bug with paths in wh-sandbox
Cc: Waldek Hebisch

Martin Rubey writes:

| I made wh-sandbox available on my linux box for other members of the
| departement by setting the file permissions of
| 
| ~/axiom
| 
| (the install directory) appropriately. However, it seems that axiom wants the
| build directory to be availble. I received the following notice:

The current handling of paths in Axiom (Gold) and its branches 
are just dead plain wrong.  some of the issues were corrected in
build-improvements (therefore wh-sandbox), but most of them remain.
I consider that your report and that of Gregory are related and fall
in the same basket.

\start
Date: 22 Feb 2007 11:09:02 +0100
From: Martin Rubey
To: list
Subject: unit testing

Dear all,

I'm discussing with Christian Aistleitner unit testing in Axiom, and I
wondered, how the regression tests are currently run. I only found the .input
files, but cannot find any files containing the corresponding "should be"
output.

Furthermore, how is "should be" and "is" currently compared?

\start
Date: Thu, 22 Feb 2007 05:11:27 -0500
From: Bill Page
To: Alfredo Portes
Subject: RE: status of windows version
Cc: Waldek Hebisch, Gabriel Dos Reis

Hi Alfredo,

On February 21, 2007 8:25 PM you wrote:
> Bill Page wrote: 
> > Do you mean something like the Doyen LiveCD? Perhaps we need
> > to encourage Alfredo to produce a new version...
> 
> No encouragement needed just more time :-).
> 

Oh, I know that problem!

> Please let me know what Axiom "version" should I use or if
> I should wait for a possible new Silver (build-improvements +
> wh-sandbox).
>

Well, my personal opinion is that it is no good to wait. We
should use the best of what we have right now. What that might
be 6 months from now, it is hard to tell. Open source projects
like Axiom really do not have schedules and resources like in
the commercial world; it all depends on personal initiative and
how much people are willing and able to give to others.

For a new Linux distribution of Axiom I favour wh-sandbox. It has
the greatest and most significant number of fixes and improvements
as far as the end user is concerned. Waldek has done a great job
of repairing and even completing parts of Hyperdoc that never were
resolved in the "commerical" version. I have never liked hyperdoc
much because I found it so unstable and the gui rather dry and ugly,
but the new wh-sandbox version is changing my mind a little - because
it actally works. Waldek has also corrected a number of significant
bugs in the algebra and added Martin's GUESS package.

For a new Windows distribution of Axiom hyperdoc is not an issue
since there is no available hyperdoc version for Windows, but the
build procedure that does not assume X-windows is important, so our
best choice right now is build-improvements.

Merging the downstream algebra bug fixes from wh-sandbox back into
build-improvements is only a matter of using svn to pick and apply
the appropriate revisions from the repository. If I some how find
a few minutes of the next week, perhaps I can do that. Merging the
GUESS build changes might be a bit more challenging.

Even if no one gets a chance to do any merging, building a new
Windows version from build-improvements is still worth it because
build-improvements is based on Axiom Gold (patch-50) while the
current windows build is two years old and based on about patch-30
or something like that and an older version of GCL.

> ...

\start
Date: Thu, 22 Feb 2007 12:21:40 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: unit testing

> Dear all,
> 
> I'm discussing with Christian Aistleitner unit testing in Axiom, and I
> wondered, how the regression tests are currently run. I only found the .input
> files, but cannot find any files containing the corresponding "should be"
> output.
> 
> Furthermore, how is "should be" and "is" currently compared?
> 

The procedure I use for wh-sandbox is as follows.  First, when a change
is developed I use ad hoc methods to verify that the change is having
intended effect typically going trough many iterations.  When I am
satisfied with change I do a full build and compare test output and
generated .pht pages.  For recent changes to algebra bootstrap and to
interpreter (switch from boot to Shoe) I also compared generated Lisp.

I do not consider any version as "should be" -- I simply monitor changes.
I compare with previous versions, typically with the preceeding one,
but sometimes also with older versions.

I compare .pht pages just using diff.  For .output files I use a script
that I recently posted.  For lisp files I have a special Lisp comparator
program (also recently posted).

I tried to use random expressions for testing but there are few problems
- my first attempt generated a lot of invalid expressions (like divisions
  by zero or type errors)
- the expressions have bad distribution, many are quite trivial but
  the other quickly get too complicated for Axiom to handle
- test runs tend to get trapped in infinite or semi-infinite computations
  or run out of memory (timeouts could help, but some examples _do_ get
  correct answer only after hours of computations)
- big problem is how to find correct answer to compare with test result.
  For indefinite integrals we can just integrate derivatives.  For
  definite integrals (and possibly some other expressions) we may
  compare numerical evaluation of symbolic result with result of 
  numerical integration.  Another possibility is are multi-CAS
  competitions:  compare outputs of different systems.

-- 
                              Waldek Hebisch
Waldek Hebisch 



\start
Date: 22 Feb 2007 13:09:00 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: unit testing

Waldek Hebisch writes:

> > Dear all,
> > 
> > I'm discussing with Christian Aistleitner unit testing in Axiom, and I
> > wondered, how the regression tests are currently run. I only found the .input
> > files, but cannot find any files containing the corresponding "should be"
> > output.
> > 
> > Furthermore, how is "should be" and "is" currently compared?
> > 
> 
> The procedure I use for wh-sandbox is as follows.  First, when a change
> is developed I use ad hoc methods to verify that the change is having
> intended effect typically going trough many iterations.  When I am
> satisfied with change I do a full build and compare test output and
> generated .pht pages.  For recent changes to algebra bootstrap and to
> interpreter (switch from boot to Shoe) I also compared generated Lisp.

Oh, I meant, results of computations using axiom...

> - big problem is how to find correct answer to compare with test result.  For
> indefinite integrals we can just integrate derivatives.  For definite
> integrals (and possibly some other expressions) we may compare numerical
> evaluation of symbolic result with result of numerical integration.  Another
> possibility is are multi-CAS competitions: compare outputs of different
> systems.

Yes, that's what I have in mind - although, for the moment, static only. I.e.,
a rather large database of results, which are checked after a change in the
algebra is made

\start
Date: Thu, 22 Feb 2007 17:40:49 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: SBCL and compiler speed

Encouraged by progress made by Greg Vanuxem I decided to retry
my attempt to compile Axiom using sbcl.  One of my main motivators
is problem of long compile times.  It is hard to resolve such
problems without a profiler.  I was unable to profile gcl compiled
programs, while profiling seem to work quite well in sbcl.
FYI I use the following patch to Juergen Weiss version:

http://www.math.uni.wroc.pl/~hebisch/prog/sbcl-cmu2.diff

Currently Debian sbcl 0.9.16 gives up compiling ALGSC (1.0 after
1 hour is still working), however I collected some timing data.
Namely I used sbcl compiled interpsys to do bootstrap part of
algebra build (like new bootstrap in wh-sandbox).  The profile
shows interesting things. First, compilation is much faster than
using gcl (about 15 minutes on the same machine) .  Most of the
time is spent in Lisp compilation, but we also have a few hot
spots in spad compilation.

Some remarks: This is profile from the third bootstrap stage,
consisting of normal compilation of all categories and about
20 core domains.  Profiles form earlier stages are somwhat
different -- the first stage is much faster, and Lisp compilation
takes smaller part.  The second stage is similar to the third.
I think that third stage is closer to normal compilation
(however, bootstrap compiles only few domains, while rest of
build handles bulk of domains and packages).


  seconds  |     consed    |   calls   |  sec/call  |  name
---------------------------------------------------------------
    56.724 | 3,295,119,728 |       342 |   0.165859 | RECOMPILE-LIB-FILE-IF-NECESSARY
    26.956 |    39,137,360 |   437,427 |   0.000062 | |coerce|
    18.446 | 1,135,112,672 |       342 |   0.053935 | LOCALDATABASE
    15.316 |       382,448 |   398,448 |   0.000038 | |isDomainForm|
    14.991 |   546,596,384 |   386,423 |   0.000039 | |comp3|
    14.179 |   848,948,032 |    10,826 |   0.001310 | EVAL
     6.340 |    82,164,176 | 1,301,192 |   0.000005 | |macroExpand|
     5.923 |   355,568,272 |     2,482 |   0.002386 | |spadCompileOrSetq|
     5.512 |   188,600,624 |     2,140 |   0.002576 | |compDefineCapsuleFunction|
     3.792 |    40,395,328 |   265,305 |   0.000014 | |compAtom|
     3.732 |   253,396,128 |       342 |   0.010912 | |compDefineLisplib|
     2.740 |   105,498,352 |     2,795 |   0.000980 | COMP370
     2.332 |   151,835,232 |       118 |   0.019762 | |mkCategoryPackage|
     1.968 |    97,820,208 |       204 |   0.009645 | |compDefineCategory2|
     1.814 |   129,140,032 |    19,498 |   0.000093 | |knownInfo|
     1.751 |    12,989,472 |     4,432 |   0.000395 | |compColon|
     0.992 |     6,727,248 |   204,213 |   0.000005 | |compSymbol|
     0.951 |    30,750,720 |   142,563 |   0.000007 | |getFormModemaps|
     0.749 |   225,793,568 |       138 |   0.005431 | |compDefineFunctor1|
     0.740 |    42,394,672 |     2,482 |   0.000298 | |compile|
     0.557 |    58,616,512 |         7 |   0.079579 | |compAdd|
     0.484 |    19,390,784 |       138 |   0.003507 | |makeFunctorArgumentParameters|
     0.203 |     8,872,672 |     2,502 |   0.000081 | COMP
     0.099 |     2,912,032 |     9,164 |   0.000011 | |updateCategoryFrameForCategory|
     0.094 |     6,528,944 |       250 |   0.000375 | |updateCategoryFrameForConstructor|
     0.067 |       111,328 |     2,140 |   0.000031 | |hasSigInTargetCategory|
     0.010 |     1,569,968 |    18,160 |   0.000001 | |compCategoryItem|
     0.010 |       130,496 |       342 |   0.000029 | |compileConstructor1|
     0.008 |       226,064 |     3,438 |   0.000002 | |compDefineAddSignature|
     0.007 |         4,144 |       342 |   0.000020 | |unloadOneConstructor|
     0.006 |             0 |     4,137 |   0.000002 | |getAbbreviation|
     0.002 |             0 |     2,140 |   0.000001 | |addArgumentConditions|
     0.002 |         8,192 |     2,341 |   0.000001 | |getSignatureFromMode|
     0.002 |       144,448 |       956 |   0.000002 | |orderByDependency|
     0.001 |             0 |     2,281 |   0.000001 | |primitiveType|
     0.001 |             0 |       138 |   0.000007 | |addEmptyCapsuleIfNecessary|
     0.000 |         8,192 |       138 |   0.000000 | |compDefineFunctor|
     0.000 |       138,848 |     3,328 |   0.000000 | |compDefine|
     0.000 |        16,384 |       204 |   0.000000 | |compDefineCategory|
     0.000 |    18,943,744 |   250,466 |   0.000000 | |comp|
     0.000 |   206,764,272 |   386,423 |   0.000000 | |comp2|
     0.000 |       446,928 |       346 |   0.000000 | |compWithMappingMode|
     0.000 |    75,078,768 |   107,669 |   0.000000 | |compExpression|
     0.000 |    11,108,624 |    84,858 |   0.000000 | |compForm|
     0.000 |   190,556,032 |   143,419 |   0.000000 | |compForm1|
     0.000 |     4,939,808 |    58,857 |   0.000000 | |compArgumentsAndTryAgain|
     0.000 |    12,663,168 |    73,948 |   0.000000 | |compForm2|
     0.000 |    55,031,440 |    91,510 |   0.000000 | |compForm3|
     0.000 |     1,759,856 |     1,796 |   0.000000 | |compIf|
     0.000 |        45,840 |     2,046 |   0.000000 | |getSuccessEnvironment|
     0.000 |       823,344 |     3,545 |   0.000000 | |compDefine1|
     0.000 |        53,600 |       204 |   0.000000 | |compDefineCategory1|
     0.000 |       634,384 |       956 |   0.000000 | |compDefWhereClause|
     0.000 |       903,936 |     2,887 |   0.000000 | |doIt|
     0.000 |     3,801,216 |    31,201 |   0.000000 | |compApplication|
     0.000 |     2,805,328 |     4,855 |   0.000000 | |applyMapping|
     0.000 |    65,133,568 |    51,649 |   0.000000 | |compApplyModemap|
---------------------------------------------------------------
   187.502 | 8,338,543,520 | 4,530,493 |            | Total


\start
Date: Thu, 22 Feb 2007 18:39:17 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: SBCL and compiler speed

Waldek,

Le jeudi 22 f=E9vrier 2007 =E0 17:40 +0100, Waldek Hebisch a =E9crit :
> Encouraged by progress made by Greg Vanuxem I decided to retry
> my attempt to compile Axiom using sbcl.  One of my main motivators
> is problem of long compile times.  It is hard to resolve such
> problems without a profiler.  I was unable to profile gcl compiled
> programs, while profiling seem to work quite well in sbcl.
> FYI I use the following patch to Juergen Weiss version:
>
> http://www.math.uni.wroc.pl/~hebisch/prog/sbcl-cmu2.diff

I you want I can upload what I have done (more precisely what is
"distributable"), I planned to upload it Sunday but I'm not against this
idea (I'm busy). The bad news is that the interpreter is not
pamphletised [1], I do not think that the documentation must be done
now, it has to be done when merging and when, I think, we have _fixed_
the API (a lot of functions rely on CltL1 (GCL ?) (symbol used to
extensively for example)). WHat I'm saying does not prevent to document,
"conceptually", some part of the "interpreter" such that the database,
the compiler(s) etc...

Greg

[1] The build process is buggy too, somes versions of Make (the one in
Cygwin for example) does not accept the algebra Makefile and its
inclusions.

\start
Date: Fri, 23 Feb 2007 00:41:08 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: SBCL and compiler speed

> Waldek,
>
> Le jeudi 22 f=E9vrier 2007 ? 17:40 +0100, Waldek Hebisch a =E9crit :
> > Encouraged by progress made by Greg Vanuxem I decided to retry
> > my attempt to compile Axiom using sbcl.  One of my main motivators
> > is problem of long compile times.  It is hard to resolve such
> > problems without a profiler.  I was unable to profile gcl compiled
> > programs, while profiling seem to work quite well in sbcl.
> > FYI I use the following patch to Juergen Weiss version:
> >
> > http://www.math.uni.wroc.pl/~hebisch/prog/sbcl-cmu2.diff
>
> I you want I can upload what I have done (more precisely what is
> "distributable"), I planned to upload it Sunday but I'm not against this
> idea (I'm busy). The bad news is that the interpreter is not
> pamphletised [1], I do not think that the documentation must be done
> now, it has to be done when merging and when, I think, we have _fixed_
> the API (a lot of functions rely on CltL1 (GCL ?) (symbol used to
> extensively for example)). WHat I'm saying does not prevent to document,
> "conceptually", some part of the "interpreter" such that the database,
> the compiler(s) etc...
>
> Greg
>
> [1] The build process is buggy too, somes versions of Make (the one in
> Cygwin for example) does not accept the algebra Makefile and its
> inclusions.
>

It would be nice to see your version.  I certainly would like to
know how you solved some specific problems (non-ANSI type declarations,
BPINAME function etc).  I would like also to time build process.

\start
Date: Fri, 23 Feb 2007 06:02:35 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Bug with paths in wh-sandbox

> I made wh-sandbox available on my linux box for other members of the
> departement by setting the file permissions of
> 
> ~/axiom
> 
> (the install directory) appropriately. However, it seems that axiom wants the
> build directory to be availble. I received the following notice:
> 
<snip>
> cc1: Fehler: /local/scratch/wh-sandbox/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h: Permission denied
> 
> 

Currently wh-sandbox (and I belive also build-improvements) does not install
gcl files (in this case cmpinclude.h) in target directory.  The simplest
solution is to use system installed gcl (and make sure that gcl _is_
installed on target machine).

Gaby is right that we have mess with paths, but even with correct paths
we still would have problem: we simply do not install the needed include
file.

\start
Date: Fri, 23 Feb 2007 10:14:55 -0500
From: Bill Page
To: Waldek Hebisch
Subject: RE: Bug with paths in wh-sandbox

On February 23, 2007 12:03 AM Waldek Hebisch wrote:
> ... 
> Currently wh-sandbox (and I belive also build-improvements) 
> does not install gcl files (in this case cmpinclude.h) in
> target directory.  
> The simplest solution is to use system installed gcl (and
> make sure that gcl _is_ installed on target machine).
> 
> Gaby is right that we have mess with paths, but even with 
> correct paths we still would have problem: we simply do not
> install the needed include file.
> 

I think that this file is installed in the target directory
(mnt) in the Axiom Gold release. Right?

\start
Date: Sat, 24 Feb 2007 04:16:09 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Bug with paths in wh-sandbox

Gabriel Dos Reis wrote:
> Martin Rubey writes:
> 
> | I made wh-sandbox available on my linux box for other members of the
> | departement by setting the file permissions of
> | 
> | ~/axiom
> | 
> | (the install directory) appropriately. However, it seems that axiom wants the
> | build directory to be availble. I received the following notice:
> 
> The current handling of paths in Axiom (Gold) and its branches 
> are just dead plain wrong.  some of the issues were corrected in
> build-improvements (therefore wh-sandbox), but most of them remain.
> I consider that your report and that of Gregory are related and fall
> in the same basket.
> 

After some investigation it turend out that eariler versions do not
need "cmpinclude.h" -- gcl simply puts inline content of this file.
gcl behaviour is controlled by the Lisp compiler::*default-system-p*
variable, which is set to t.  As a workaround one can use the following
in the start script:

)lisp (setf compiler::*default-system-p* nil)

AFAICS the problem was interoduced in version 25 (patch 45): this
variable is set to t when using system installed gcl.  Typically
this is not a problem, but I belive that if somebody builds gold
using system installed gcl (assuming that this would work ...)
and then puts the content of Axiom directory on a machine whithout
installed gcl, then the same problem would appear.

Now, the question is how to solve the problem.  One way is to patch
src/lsp/Makefile.pamphlet so that it does not set 
compiler::*default-system-p* to t.  Another possibility is to
set compiler::*default-system-p* to nil when dumping final AXIOMsys.
For me the second possibility looks slightly better, as it avoids
putting extra crud into intermediate C files.

>From my point of view nicest solution would be to teach gcl check
if cmpinclude.h is in expected place, if yes use it, otherwise
use cached version.

\start
Date: Sat, 24 Feb 2007 15:46:28 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Sources of the port of Axiom to SBCL/CMUCL/Clisp (was: SBCL and compiler speed)

Le vendredi 23 f=E9vrier 2007 =E0 00:41 +0100, Waldek Hebisch a =E9crit :=

> >
> > I you want I can upload what I have done (more precisely what is
> > "distributable"), I planned to upload it Sunday but I'm not against t=
his
> > idea (I'm busy). The bad news is that the interpreter is not
> > pamphletised [1], I do not think that the documentation must be done
> > now, it has to be done when merging and when, I think, we have _fixed=
_
> > the API (a lot of functions rely on CltL1 (GCL ?) (symbol used to
> > extensively for example)). WHat I'm saying does not prevent to docume=
nt,
> > "conceptually", some part of the "interpreter" such that the database=
,
> > the compiler(s) etc...
> >
> > Greg
> >
> > [1] The build process is buggy too, somes versions of Make (the one i=
n
> > Cygwin for example) does not accept the algebra Makefile and its
> > inclusions.
> >
>
> It would be nice to see your version.  I certainly would like to
> know how you solved some specific problems (non-ANSI type declarations,
> BPINAME function etc).  I would like also to time build process.
>

Here are the sources:

http://perso.orange.fr/parabola/axiom-cl.tar.gz

It is based on the work of Juergen Weiss available here:

http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz

(So you can easily diff these to know who did what)

For the question of BPINAME, I have the same problem than you.
When I read your code I was particularly interested in your
implementation of this function. This function is
implemented but further investigations are needed.

For example the

((and (consp func) (eq (car func) 'lambda)) (second (third func)))

is probably never used. Furthermore in boot code we can see several
reference to compiled-function-p before using BPINAME, compiled-function-=
p
is really implementation dependant so... I will work on this when time wi=
ll permit.

Anyway there are numerous "TODO" in the code, if some of you want to work=
 on
this port feel free to improve it :-) (when there are "QUESTION" in the c=
ode
this is because further investigation are needed and eventually I'll have=
 to
ask Juergen Weiss why it's implemented this way).

To compile it 'cd' to src/boot, edit the Makefile.(sbcl|clisp|cmu) and th=
e Makefile.inc
to change the variables defined if necessary (you'll have, for sure, to m=
odify AXIOMROOT).
Export the AXIOM environment variable so for example with SBCL :

export AXIOM=/usr/local/axiom-cl/mnt/sbcl

and use 'make -f Makdefile.sbcl' to build bootsys with SBCL.

Do the same thing for src/interp and src/algebra.

To use Axiom do not forget to export the environment variable AXIOM
(this is necessary for the moment).

The build process has been done in such a way that you can easily build
Axiom for each CL implementation (and test the three at the same time).

And, a last remark (for fun)

<Hans Reiser argument>

Original Axiom:
-------------------------------------------------------------------------=
---
time echo ')r zdsolve' | /usr/local/axiom/mnt/linux/bin/AXIOMsys &>/dev/n=
ull

real    1m24.392s
user    1m21.025s
sys     0m1.010s
-------------------------------------------------------------------------=
---
Axiom on SBCL:
-------------------------------------------------------------------------=
---
time echo ')r zdsolve' | /usr/local/axiom-cl/mnt/sbcl/bin/interpsys &>/de=
v/null

real    0m29.127s
user    0m25.860s
sys     0m0.506s
-------------------------------------------------------------------------=
---

</Hans Reiser argument>

And there are a lot of other types of remark...

Greg

PS: If you have fix, amelioration etc... please let me know.

PS2: For the "warriors" who want to use Aldor edit foam_l.lisp since
it's specialised for me (the |SInt| type). A better way is to use an inte=
ger
range as type instead of a predefined type such that fixnum. The
other problem is that we don't have the sources so we can not know
what exactly a |Sint| is.)

==========================
==========================
==========================
=====
KNOWN PROBLEMS (not related to Axiom):

If you encounter a "NIL is not of type continuation" with CMUCL try to ch=
ange
the safety optimise setting, this is apparently a bug in CMUCL.

Some versions of SBCL (mine for example (x86-64)), apparently, loop indef=
initely
when computing the gcd with MOST-NEGATIVE-FIXNUM as one of its arguments.=
 Solution
fix SBCL :-)

(this one is related to the build process of Axiom)
It will be not possible to build the algebra with some version of Make.
This need to be  fixed. The typical error message is something like
"can not load BASTYPE", this type is not available since the correspondin=
g
.spad file is not compiled). On MinGW-MSYS I have to create the included =
makefiles
with the "standard" version of make and use the "packaged make" to
build the algebra :-(

\start
Date: Sat, 24 Feb 2007 11:47:57 -0600
From: Tim Daly
To: list
Subject: next release

I'm working on the next release of Axiom Gold.

Work is being done on Axiom in several different locations
and I've made an effort to harvest those changes that I understand
and to merge, test, and document these changes back into the release.

In open source projects it is important that changes get collected
and packaged so they can be merged with the main release. This
is done by releasing diffs and changesets (the whole point of SVN).
Often the original author is the only one who can diff, document,
test and package these changesets.

The mailing list has almost no patches posted.
Why is that?

\start
Date: 24 Feb 2007 19:23:07 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: next release

Tim Daly writes:

> I'm working on the next release of Axiom Gold.

Great! Could you please try to include my guessing package?

> The mailing list has almost no patches posted.
> Why is that?

I sent all patches to issue tracker. Look at "fix proposed", please.

\start
Date: Sun, 25 Feb 2007 03:30:09 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: Sources of the port of Axiom to SBCL/CMUCL/Clisp

Gregory Vanuxem wrote:
> Here are the sources:
> 
> http://perso.orange.fr/parabola/axiom-cl.tar.gz
>

Thanks, nice job.
 
> It is based on the work of Juergen Weiss available here:
> 
> http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz
> 
> (So you can easily diff these to know who did what)
> 
> For the question of BPINAME, I have the same problem than you.
> When I read your code I was particularly interested in your
> implementation of this function. This function is
> implemented but further investigations are needed.
> 
> For example the 
> 
> ((and (consp func) (eq (car func) 'lambda)) (second (third func)))
> 
> is probably never used. Furthermore in boot code we can see several
> reference to compiled-function-p before using BPINAME, compiled-function-p
> is really implementation dependant so... I will work on this when time will permit.
>

I suspect that the use of compiled-function-p is bogus: Axiom probably
assumes that the function is either given by a lambda list or is
a compiled function.  But it looks that such assumption was true in
the past, but now both compiled and interpreted functions are (represented
by) function objects.  I think that the case you quote above just
tests for archaic representation of interpreted functions.

I hope that Lisp implementation that is capable of finding name of a function
object will return this name as a third value of function-lambda-expression.
However, I noticed that sbcl returns funny things for functions obtained
from lambda expresions so I added a little samity check.  I wonder
how well such implementation works with other Lisps -- in principle
it may be quite portable.

> To compile it 'cd' to src/boot, edit the Makefile.(sbcl|clisp|cmu) and the Makefile.inc
> to change the variables defined if necessary (you'll have, for sure, to modify AXIOMROOT).
> Export the AXIOM environment variable so for example with SBCL :
> 
> export AXIOM=/usr/local/axiom-cl/mnt/sbcl
> 
> and use 'make -f Makdefile.sbcl' to build bootsys with SBCL.
> 
> Do the same thing for src/interp and src/algebra.
> 
> To use Axiom do not forget to export the environment variable AXIOM
> (this is necessary for the moment).
> 

I had apply the following diff to build with  sbcl 0.9.16.  The first
hunks just corrects a typo, the second chunk is a quick hack around the
problem that sb-unix::unix-mkdir accepts only base-string, while we have
a string as an argument.  I did not try building using sbcl 1.0, but
I did check that in sbcl 1.0 sb-unix::unix-mkdir works just with
strings, so probably 1.0 needs no workaround.

diff -u pp/axiom-cl/src/interp/Makefile.sbcl axiom-cl/src/interp/Makefile.sbcl
--- pp/axiom-cl/src/interp/Makefile.sbcl	2007-02-24 14:01:24.000000000 +0100
+++ axiom-cl/src/interp/Makefile.sbcl	2007-02-25 00:05:33.000000000 +0100
@@ -15,7 +15,7 @@
 	@ echo copy $@ from $<
 	@ cp -p $< $@
 
-${OUT_DEP}/proclaims.${lisp}: ${IN}/sbcl_proclaims.lisp
+${OUT_DEP}/proclaims.${LISP}: ${IN}/sbcl_proclaims.lisp
 	@ echo making $@ from $<
 	@ ln -s $< $@
 
diff -u pp/axiom-cl/src/interp/nlib.lisp axiom-cl/src/interp/nlib.lisp
--- pp/axiom-cl/src/interp/nlib.lisp	2007-02-24 13:52:50.000000000 +0100
+++ axiom-cl/src/interp/nlib.lisp	2007-02-25 00:27:08.000000000 +0100
@@ -248,7 +248,7 @@
 
 #+(and :sbcl :unix)
 (defun makedir (fname)
-  (sb-unix::unix-mkdir (boot::interp-make-directory fname) #o755))
+  (sb-ext::run-program "/bin/mkdir" (list fname)))
 
 #+:clisp
 (defun makedir (fname)

\start
Date: 24 Feb 2007 20:52:14 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: next release

Tim Daly writes:

| I'm working on the next release of Axiom Gold.
| 
| Work is being done on Axiom in several different locations
| and I've made an effort to harvest those changes that I understand
| and to merge, test, and document these changes back into the release.
| 
| In open source projects it is important that changes get collected
| and packaged so they can be merged with the main release. This
| is done by releasing diffs and changesets (the whole point of SVN).
| Often the original author is the only one who can diff, document,
| test and package these changesets.
| 
| The mailing list has almost no patches posted.
| Why is that?

Well, patches are supposed to be posted when they are ready for
"prime time" use.  For "personal" experimentation we don't require
that (should we?).

The axiom-commit mailing list has the history of all commits
to SVN -- when they are not truncated due to SF policy.

\start
Date: Sat, 24 Feb 2007 20:54:45 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Bug with paths in wh-sandbox

On Sat, 24 Feb 2007, Waldek Hebisch wrote:

| Gabriel Dos Reis wrote:
| > Martin Rubey writes:
| >
| > | I made wh-sandbox available on my linux box for other members of the
| > | departement by setting the file permissions of
| > |
| > | ~/axiom
| > |
| > | (the install directory) appropriately. However, it seems that axiom wants the
| > | build directory to be availble. I received the following notice:
| >
| > The current handling of paths in Axiom (Gold) and its branches
| > are just dead plain wrong.  some of the issues were corrected in
| > build-improvements (therefore wh-sandbox), but most of them remain.
| > I consider that your report and that of Gregory are related and fall
| > in the same basket.
| >
|
| After some investigation it turend out that eariler versions do not
| need "cmpinclude.h" -- gcl simply puts inline content of this file.
| gcl behaviour is controlled by the Lisp compiler::*default-system-p*
| variable, which is set to t.  As a workaround one can use the following
| in the start script:
|
| )lisp (setf compiler::*default-system-p* nil)
|
| AFAICS the problem was interoduced in version 25 (patch 45): this
| variable is set to t when using system installed gcl.  Typically
| this is not a problem, but I belive that if somebody builds gold
| using system installed gcl (assuming that this would work ...)
| and then puts the content of Axiom directory on a machine whithout
| installed gcl, then the same problem would appear.
|
| Now, the question is how to solve the problem.  One way is to patch
| src/lsp/Makefile.pamphlet so that it does not set
| compiler::*default-system-p* to t.  Another possibility is to
| set compiler::*default-system-p* to nil when dumping final AXIOMsys.
| For me the second possibility looks slightly better, as it avoids
| putting extra crud into intermediate C files.
|
| From my point of view nicest solution would be to teach gcl check
| if cmpinclude.h is in expected place, if yes use it, otherwise
| use cached version.

You have spent some time investigating this; but, unfortunately I do
not see the direct link to GCL stuff being system-wide or not.
Please could you walk me (slowly) through your invesgitation?

[ I just saw your patch, but I would first like to see why the
  patch is correct at the "algorithmic" level. ]

\start
Date: Sun, 25 Feb 2007 04:41:54 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Bug with paths in wh-sandbox

Gabriel Dos Reis wrote:
> On Sat, 24 Feb 2007, Waldek Hebisch wrote:
> | After some investigation it turend out that eariler versions do not
> | need "cmpinclude.h" -- gcl simply puts inline content of this file.
> | gcl behaviour is controlled by the Lisp compiler::*default-system-p*
> | variable, which is set to t.  As a workaround one can use the following
> | in the start script:
> |
> | )lisp (setf compiler::*default-system-p* nil)
> |
> | AFAICS the problem was interoduced in version 25 (patch 45): this
> | variable is set to t when using system installed gcl.  Typically
> | this is not a problem, but I belive that if somebody builds gold
> | using system installed gcl (assuming that this would work ...)
> | and then puts the content of Axiom directory on a machine whithout
> | installed gcl, then the same problem would appear.
> |
> | Now, the question is how to solve the problem.  One way is to patch
> | src/lsp/Makefile.pamphlet so that it does not set
> | compiler::*default-system-p* to t.  Another possibility is to
> | set compiler::*default-system-p* to nil when dumping final AXIOMsys.
> | For me the second possibility looks slightly better, as it avoids
> | putting extra crud into intermediate C files.
> |
> | From my point of view nicest solution would be to teach gcl check
> | if cmpinclude.h is in expected place, if yes use it, otherwise
> | use cached version.
> 
> You have spent some time investigating this; but, unfortunately I do
> not see the direct link to GCL stuff being system-wide or not.
> Please could you walk me (slowly) through your invesgitation?
> 
> [ I just saw your patch, but I would first like to see why the
>   patch is correct at the "algorithmic" level. ]
> 

in the file gcl_cmpmain.lsp we have:

(defun compiler-pass2 (c-pathname h-pathname system-p )
  (declare (special *init-name*))
  (with-open-file (st c-pathname :direction :output)
    (let ((*compiler-output1* (if (eq system-p 'disassemble) *standard-output*
                                st)))
      (declare (special *compiler-output1*))
    (with-open-file (*compiler-output2* h-pathname :direction :output)
      (cond ((and
              (stringp *cmpinclude-string*)
              (not system-p)
              (si::fwrite *cmpinclude-string* 0
                          (length *cmpinclude-string*) *compiler-output1*)))
            (t (wt-nl1 "#include " *cmpinclude*)))

So, if system-p argument to compiler-pass2 is true, it will try to
use system include file.

now in the same file in compile-file1 we have

        (compiler-pass2 c-pathname h-pathname system-p ))

and the beginning of compile-file1 is:

(defun compile-file1 (input-pathname
                      &key (output-file input-pathname)
                           (o-file t)
                           (c-file *default-c-file*)
                           (h-file *default-h-file*)
                           (data-file *default-data-file*)
                           (c-debug nil)
                           #+aosvs (ob-file nil)
                           (system-p *default-system-p*)

so during compile system-p is taken from *default-system-p*, unless
a specific values is given as a keyword argument.

\start
Date: Sun, 25 Feb 2007 05:30:15 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: next release

> I'm working on the next release of Axiom Gold.
> 
> Work is being done on Axiom in several different locations
> and I've made an effort to harvest those changes that I understand
> and to merge, test, and document these changes back into the release.
> 
> In open source projects it is important that changes get collected
> and packaged so they can be merged with the main release. This
> is done by releasing diffs and changesets (the whole point of SVN).
> Often the original author is the only one who can diff, document,
> test and package these changesets.
> 
> The mailing list has almost no patches posted.
> Why is that?
> 

Each version to wh-sandbox is typically a single changeset (some
large changes which are concepually a single unit are split into
multiple commits).  AFAIK you are receiveg the patches via axiom-commit
mailing list.  In my experience also web interface at:

http://axiom.svn.sourceforge.net/viewvc/axiom/

works reasonably.

Most patches to wh-sandbox are a very dull reading: they remove
hundreds of lines of machine generated files.  The following
patches to wh-sandbox fix user visible problems (many of them
were posted to the axiom-developr mailing list).  The number
allow to identify SVN version and get more details.

+++ ChangeLog.wh        (wersja 423)
@@ -1,3 +1,10 @@
+2007-01-17  Waldek Hebisch  Waldek Hebisch
+
+       Fix bug 101
+       * src/algebra/laplace.spad.pamphlet:
+       LaplaceTransform.lapkernel: handle derivatives
+       LaplaceTransform.locallaplace: supress last rule
+
+++ ChangeLog.wh        (wersja 421)
@@ -1,3 +1,12 @@
+2007-01-15  Waldek Hebisch  Waldek Hebisch
+           Martin Rubey
+
+       Fix bug 103
+       * src/algebra/polycat.spad.pamphlet:
+       FiniteAbelianMonoidRing.exquo: test for zero divisor
+       PolynomialCategory.primitivePart: special handling for zero
+       argument
+++ ChangeLog.wh        (wersja 419)
@@ -1,3 +1,15 @@
+2007-01-06  Waldek Hebisch  Waldek Hebisch
+
+       * src/interp/br-data.boot.pamphlet: dbHasExamplePage: Correct
+       path to example pages.
+       * src/hyper/pages/MSET.ht: Replace MultiSet by Multiset.
+       * src/hyper/pages/ug01.ht: Likewise.
+       * src/hyper/pages/xmpexp.ht: Likewise.
+       * src/hyper/pages/man0.ht: Use full path to htsearch
+       * src/hyper/htinp.pamphlet: Use full path to viewAlone.
+       * src/hyper/pages/util.ht: Likewise.  Use $AXIOM insead of $SPAD
+       * src/hyper/pages/ht.db: Remove.
+
+++ ChangeLog.wh        (wersja 418)
@@ -1,3 +1,9 @@
+2007-01-05  Waldek Hebisch  Waldek Hebisch
+
+       * src/algebra/gaussian.spad.pamphlet: Fix complex
+       argument (fixes or works around bugs 15, 47, 184,
+       293, 314)
+
+++ ChangeLog.wh        (wersja 410)
@@ -1,3 +1,7 @@
+2006-12-21  Waldek Hebisch  Waldek Hebisch
+
+       * src/algebra/intfact.spad.pamphlet: Fix bug 329.
+
+++ ChangeLog.wh        (wersja 397)
@@ -1,3 +1,7 @@
+2006-12-12  Waldek Hebisch  Waldek Hebisch
+
+       * src/algebra/manip.spad.pamphlet: Fix bug 278.
+
+++ ChangeLog.wh        (wersja 388)
@@ -1,5 +1,9 @@
 2006-12-09  Waldek Hebisch  Waldek Hebisch

+       * src/algebra/intef.spad.pamphlet: Fix bugs 100 and 308.
+
+++ ChangeLog.wh        (wersja 387)
@@ -1,5 +1,9 @@
 2006-12-09  Waldek Hebisch  Waldek Hebisch

+       * src/algebra/intrf.spad.pamphlet: Partial fix for bug 199.
+
+++ ChangeLog.wh        (wersja 386)
@@ -1,3 +1,7 @@
+2006-12-09  Waldek Hebisch  Waldek Hebisch
+
+       * src/algebra/sttaylor.spad.pamphlet: Fix bug 312
+
+++ ChangeLog.wh        (wersja 343)
@@ -1,5 +1,9 @@
 2006-11-30  Waldek Hebisch  Waldek Hebisch

+       * src/sman/sman.c.pamphlet: Do not mess with terminal on exit.
+
+++ ChangeLog.wh        (wersja 342)
@@ -1,5 +1,13 @@
 2006-11-30  Waldek Hebisch  Waldek Hebisch

+       * src/include/com.h: Add new command code.
+       * src/interp/sockio.lisp.pamphlet: Likewise.
+       * src/interp/server.boot.pamphlet: serverReadLine: send it.
+       * src/sman/session.c.pamphlet: accept_session_connection:
+       Use new code to detect lost race.
+
+++ ChangeLog.wh        (wersja 341)
@@ -1,5 +1,11 @@
 2006-11-30  Waldek Hebisch  Waldek Hebisch

+       * src/hyper/parse-types.pamphlet: Do not add ".Z" extension.
+       * src/lib/pixmap.c.pamphlet: Atomatically switch between
+       compressed and uncompressed pixmaps.
+
+++ ChangeLog.wh        (wersja 339)
@@ -1,3 +1,8 @@
+2006-11-30  Waldek Hebisch  Waldek Hebisch
+
+       * src/algebra/newdata.spad.pamphlet:
+       iprint$InternalPrintPackage: remove useless call to FLUSH
+
+++ ChangeLog.wh        (wersja 327)
@@ -1,3 +1,8 @@
+2006-11-28  Waldek Hebisch  Waldek Hebisch
+
+       * src/graph/view3D/component3d.c.pamphlet: draw3DComponents():
+       reference starting point.
+
+++ ChangeLog.wh        (wersja 325)
@@ -1,3 +1,7 @@
+2006-11-26  Waldek Hebisch  Waldek Hebisch
+
+       * src/hyper/htinp.pamphlet: strCopy(): call strcpy.
+
+++ ChangeLog.wh        (wersja 312)
@@ -1,5 +1,11 @@
 2006-11-23  Waldek Hebisch  Waldek Hebisch

+       Fix for bug #280.
+       * src/interp/br-search.boot.pamphlet: grepConstruct:
+       Exit early on errors
+
+++ ChangeLog.wh        (wersja 310)
@@ -1,5 +1,10 @@
 2006-11-23  Waldek Hebisch  Waldek Hebisch

+       * src/interp/daase.lisp.pamphlet: getdatabase: when
+       reporting misses print arguments in consistent order
+
+++ ChangeLog.wh        (wersja 306)
@@ -1,5 +1,11 @@
 2006-11-23  Waldek Hebisch  Waldek Hebisch

+       * src/hyper/pages/util.ht: Undo change from 2003:
+       uncomment \spadcmd and \spadsys, remove leadinig
+       parenthesis from \spadsyscom
+
+++ ChangeLog.wh        (wersja 284)
@@ -1,5 +1,11 @@
-2006-11-17
+2006-11-17  Waldek Hebisch  Waldek Hebisch

+       * src/etc/axiom: Add Axiom binary directory to the PATH
+       * src/hyper/search.pamphlet: use -k sort option, fix
+       presea script
+
+++ ChangeLog.build-improvements        (wersja 281)
@@ -1,3 +1,13 @@
+2006-11-15  Waldek Hebisch
+           Bill Page
+
+       * rename mixed case files to avoid svn checkout problems
+         on Windows and Mac, e.g. src/hyper/bitmaps/Alpha.bitmap
+         to alpha-cap.bitmap, etc.
+       * delete duplicate file src/share/doc/hypertex/pages/util.ht
+         and junk from src/doc/ps
+       * Correct noweb syntax in Rosetta.pamphlt
+
+++ ChangeLog.wh        (wersja 280)
@@ -1,3 +1,12 @@
+2006-11-17  Waldek Hebisch  Waldek Hebisch
+
+       Fixes for Spad filehandling.
+       * src/algebra/files.spad.pamphlet: Remove checks, add close! to
+       Libray exports
+       * src/interp/fname.lisp.pamphlet: Use axiom-probe-file
+       * src/interp/nlib.lisp.pamphlet (probe-name): Likewise.
+       (make-input-filename): Add slash to separate names.
+
+++ ChangeLog.wh        (wersja 271)
@@ -1,5 +1,14 @@
 2006-11-15  Waldek Hebisch  Waldek Hebisch

+       * src/interp/lisplib.boot.pamphlet: readLibPathFast:
+       activate error checking
+       * src/interp/nlib.lisp.pamphlet: fix search for
+       directories
+       * src/etc/Makefile.pamphlet: Install USERS.DAASE and
+       DEPENDENTS.DAASE
+

\start
Date: Sat, 24 Feb 2007 23:22:44 -0600
From: Tim Daly
To: Waldek Hebisch
Subject: next release

I've seen the changes on axiom-commit and some of them have been
merged with in the next release. For instance, I've removed all 
of the C prototype code. However, there are changes that are 
deeper (e.g. math) which do not have documentation or test cases,
such as changes to the series package. I'm not able to decide if
these changes are correct. I had a conversation with Clifton 
Williamson about it but so far the details are still unresolved. 
I'm still not clear if the original code, the previous patch, or
the current patch is correct. 

I'm also having difficulty deciding what changes should be added
and what changes are part of a larger change (e.g. the asq rewrite).
Is it possible to isolate a closed set of changes that are diff -Naur
changes from Gold? 

In general, publishing a changeset to a branch is not the same as
publishing a diff -Naur from Gold. I've been trying to sift thru
the changesets but it takes a great deal of time to decide what 
to do in the absence of documentation.

Working without published diff -Naur from Gold I expect that
people will complain that their favorite change will not be
included. I'd prefer to get it right the first time.

\start
Date: 25 Feb 2007 11:25:44 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: next release

Tim Daly writes:

> such as changes to the series package. I'm not able to decide if
> these changes are correct. I had a conversation with Clifton 
> Williamson about it but so far the details are still unresolved. 
> I'm still not clear if the original code, the previous patch, or
> the current patch is correct. 

I'll try to document that patch today or tomorrow.  Did you already look at the
others?

http://wiki.axiom-developer.org/IssueTracker?status:list=fix%20proposed

I also posted a documentation patch to ystream.spad.pamphlet some time ago.

Concerning "favorite fix":

* Waldek's patches to hyperdoc

* my patches to hyperdoc (i.e. spadedit.pamphlet) (#5, #144)

* the patch correcting the typo for multiset documentation (#319)

* the patch for the series package (#312)

* the patch to COMBF correcting the binomial inconsitency (a necessity for my
  guessingPackage, meanwhile) (#336)

* waldek's patch correcting the problem in normalize.

* #199, but is is hopeless to get documentation there, I think. Waldek is the
   only one we could ask...

\start
Date: 25 Feb 2007 13:25:57 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: [Axiom-mail] %S in some contr. pkg fails to compile

Dear Ralf

(I'm the author of mantepse & co)

Ralf Hemmecke writes:

> Hello, why is it that I can compile the Simpson's method's spad file but not
> mantepse.spad? The latter contains %S strings which let the compile command
> choke.

Hm, I don't see any %S strings in any of my source packages?

If you just want to use the package, I'd advise you to check out Waldek
Hebisch's branch, it contains my package and many other improvements.

Otherwise, here are some instructions:

you need to get *all* of

ssolve.spad.pamphlet
rec.spad.pamphlet
fffg.spad.pamphlet
mantepse.spad.pamphlet

Put them into a directory, say "guess" and cd to that directory:

cd guess

  you then have to issue

document ssolve.spad.pamphlet
document rec.spad.pamphlet
document fffg.spad.pamphlet
document mantepse.spad.pamphlet

  which should produce ssolve.spad, rec.spad, fffg.spad, mantepse.spad and also
  documentation in .dvi format.

  If any of these files contains "%S", something is wrong...

  Now you should start Axiom

axiom

  and start compiling *in this order*:

)co fffg.spad
)co ssolve.spad

  the following will most likely signal an error like "UFPS not found"...

)co mantepse.spad )co UFPS

  thus you have to do it once more:

)co mantepse.spad )co UFPS

)co rec.spad

  the following is the easiest way to work around a stupid bug...

)sys rm -rf UFPS.*

  this final compilation will take a *very* long time (half an hour or so)

)co mantepse.spad

  if any of the above compile commands (except the one indicated) fails, please
  send mail again.

  I'm very sorry that building is so complicated. I'd be very interested
  whether you succeed...



Good Luck, 

Martin

PS: this week there will be a yet improved version of my package available.

\start
Date: Sun, 25 Feb 2007 15:46:55 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: Sources of the port of Axiom to SBCL/CMUCL/Clisp

Le dimanche 25 f=E9vrier 2007 =E0 03:30 +0100, Waldek Hebisch a =E9crit :=


[...]

> I suspect that the use of compiled-function-p is bogus: Axiom probably
> assumes that the function is either given by a lambda list or is
> a compiled function.  But it looks that such assumption was true in
> the past, but now both compiled and interpreted functions are (represen=
ted
> by) function objects.  I think that the case you quote above just
> tests for archaic representation of interpreted functions.

This is what I think too.

>
> I hope that Lisp implementation that is capable of finding name of a fu=
nction
> object will return this name as a third value of function-lambda-expres=
sion.
> However, I noticed that sbcl returns funny things for functions obtaine=
d
> from lambda expresions so I added a little samity check.  I wonder
> how well such implementation works with other Lisps -- in principle
> it may be quite portable.

It is definitely a better implementation.

[...]

> I had apply the following diff to build with  sbcl 0.9.16.  The first
> hunks just corrects a typo, the second chunk is a quick hack around the
> problem that sb-unix::unix-mkdir accepts only base-string, while we hav=
e
> a string as an argument.  I did not try building using sbcl 1.0, but
> I did check that in sbcl 1.0 sb-unix::unix-mkdir works just with
> strings, so probably 1.0 needs no workaround.

I'm working with 1.0.2 (in fact pre 1.0.3 since I use a file from CVS (be=
cause of some changes
in the FOP compiler in 1.0.2, in some circumstances, undeclared variables=
 are not "accepted",
the "real" compiler treats them as specials)).
I'll keep my implementation since the unix feature and the function unix-=
mkdir is available on
Windows, though I'm hesitant.

\start
Date: Sun, 25 Feb 2007 09:28:12 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Bug with paths in wh-sandbox

On Sun, 25 Feb 2007, Waldek Hebisch wrote:

| Gabriel Dos Reis wrote:
| > On Sat, 24 Feb 2007, Waldek Hebisch wrote:
| > | After some investigation it turend out that eariler versions do not
| > | need "cmpinclude.h" -- gcl simply puts inline content of this file.
| > | gcl behaviour is controlled by the Lisp compiler::*default-system-p*
| > | variable, which is set to t.  As a workaround one can use the following
| > | in the start script:
| > |
| > | )lisp (setf compiler::*default-system-p* nil)
| > |
| > | AFAICS the problem was interoduced in version 25 (patch 45): this
| > | variable is set to t when using system installed gcl.  Typically
| > | this is not a problem, but I belive that if somebody builds gold
| > | using system installed gcl (assuming that this would work ...)
| > | and then puts the content of Axiom directory on a machine whithout
| > | installed gcl, then the same problem would appear.
| > |
| > | Now, the question is how to solve the problem.  One way is to patch
| > | src/lsp/Makefile.pamphlet so that it does not set
| > | compiler::*default-system-p* to t.  Another possibility is to
| > | set compiler::*default-system-p* to nil when dumping final AXIOMsys.
| > | For me the second possibility looks slightly better, as it avoids
| > | putting extra crud into intermediate C files.
| > |
| > | From my point of view nicest solution would be to teach gcl check
| > | if cmpinclude.h is in expected place, if yes use it, otherwise
| > | use cached version.
| >
| > You have spent some time investigating this; but, unfortunately I do
| > not see the direct link to GCL stuff being system-wide or not.
| > Please could you walk me (slowly) through your invesgitation?
| >
| > [ I just saw your patch, but I would first like to see why the
| >   patch is correct at the "algorithmic" level. ]
| >
|
| in the file gcl_cmpmain.lsp we have:
|
| (defun compiler-pass2 (c-pathname h-pathname system-p )
|   (declare (special *init-name*))
|   (with-open-file (st c-pathname :direction :output)
|     (let ((*compiler-output1* (if (eq system-p 'disassemble) *standard-output*
|                                 st)))
|       (declare (special *compiler-output1*))
|     (with-open-file (*compiler-output2* h-pathname :direction :output)
|       (cond ((and
|               (stringp *cmpinclude-string*)
|               (not system-p)
|               (si::fwrite *cmpinclude-string* 0
|                           (length *cmpinclude-string*) *compiler-output1*)))
|             (t (wt-nl1 "#include " *cmpinclude*)))
|
| So, if system-p argument to compiler-pass2 is true, it will try to
| use system include file.

Yes, I understood that part.

The link I'm missing is why Axiom's misbehaviour (reported by both
Gregory and Martin) is traced back to that.  Or am I lured by the
title of the thread? (I have been travelling the whole week, so I have
no access to all the discussion, only this one and some other bits).

| now in the same file in compile-file1 we have
|
|         (compiler-pass2 c-pathname h-pathname system-p ))
|
| and the beginning of compile-file1 is:
|
| (defun compile-file1 (input-pathname
|                       &key (output-file input-pathname)
|                            (o-file t)
|                            (c-file *default-c-file*)
|                            (h-file *default-h-file*)
|                            (data-file *default-data-file*)
|                            (c-debug nil)
|                            #+aosvs (ob-file nil)
|                            (system-p *default-system-p*)
|
| so during compile system-p is taken from *default-system-p*, unless
| a specific values is given as a keyword argument.

\start
Date: Sun, 25 Feb 2007 17:45:21 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Bug with paths in wh-sandbox

Gabriel Dos Reis wrote:
> On Sun, 25 Feb 2007, Waldek Hebisch wrote:
> 
> | Gabriel Dos Reis wrote:
> | > On Sat, 24 Feb 2007, Waldek Hebisch wrote:
> | > | After some investigation it turend out that eariler versions do not
> | > | need "cmpinclude.h" -- gcl simply puts inline content of this file.
> | > | gcl behaviour is controlled by the Lisp compiler::*default-system-p*
> | > | variable, which is set to t.  As a workaround one can use the following
> | > | in the start script:
> | > |
> | > | )lisp (setf compiler::*default-system-p* nil)
> | > |
> | > | AFAICS the problem was interoduced in version 25 (patch 45): this
> | > | variable is set to t when using system installed gcl.  Typically
> | > | this is not a problem, but I belive that if somebody builds gold
> | > | using system installed gcl (assuming that this would work ...)
> | > | and then puts the content of Axiom directory on a machine whithout
> | > | installed gcl, then the same problem would appear.
> | > |
> | > | Now, the question is how to solve the problem.  One way is to patch
> | > | src/lsp/Makefile.pamphlet so that it does not set
> | > | compiler::*default-system-p* to t.  Another possibility is to
> | > | set compiler::*default-system-p* to nil when dumping final AXIOMsys.
> | > | For me the second possibility looks slightly better, as it avoids
> | > | putting extra crud into intermediate C files.
> | > |
> | > | From my point of view nicest solution would be to teach gcl check
> | > | if cmpinclude.h is in expected place, if yes use it, otherwise
> | > | use cached version.
> | >
> | > You have spent some time investigating this; but, unfortunately I do
> | > not see the direct link to GCL stuff being system-wide or not.
> | > Please could you walk me (slowly) through your invesgitation?
> | >
> | > [ I just saw your patch, but I would first like to see why the
> | >   patch is correct at the "algorithmic" level. ]
> | >
> |
> | in the file gcl_cmpmain.lsp we have:
> |
> | (defun compiler-pass2 (c-pathname h-pathname system-p )
> |   (declare (special *init-name*))
> |   (with-open-file (st c-pathname :direction :output)
> |     (let ((*compiler-output1* (if (eq system-p 'disassemble) *standard-output*
> |                                 st)))
> |       (declare (special *compiler-output1*))
> |     (with-open-file (*compiler-output2* h-pathname :direction :output)
> |       (cond ((and
> |               (stringp *cmpinclude-string*)
> |               (not system-p)
> |               (si::fwrite *cmpinclude-string* 0
> |                           (length *cmpinclude-string*) *compiler-output1*)))
> |             (t (wt-nl1 "#include " *cmpinclude*)))
> |
> | So, if system-p argument to compiler-pass2 is true, it will try to
> | use system include file.
> 
> Yes, I understood that part.
> 
> The link I'm missing is why Axiom's misbehaviour (reported by both
> Gregory and Martin) is traced back to that.  Or am I lured by the
> title of the thread? (I have been travelling the whole week, so I have
> no access to all the discussion, only this one and some other bits).
>

First, this fixes _part_ of the problem that Martin reported (problem
reported by Gregory are fixed by another patch).  

: Ein weiteres Problem, das bei putty aufgetreten ist, war die folgende Fehlermeldung:
: (1) ->
: (1) -> f(0)==0
:                                                                    Type: Void
: (2) -> f(1)==1
:                                                                    Type: Void
: (3) -> f(n)==f(n-1)+f(n-2)
:                                                                    Type: Void
: (4) -> f(7)
:    Compiling function f with type Integer -> NonNegativeInteger
:    Compiling function f as a recurrence relation.
: cc1: Fehler: /local/scratch/wh-sandbox/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h: Permission denied
 
This errors came for gcc search for include files.  The patch I applied
allows Axiom to work when build tree is not present.  In other words,
when you make a tarball of installed Axiom and put it on another
machine it will work, unless there is unreadable directory on path
leading to original build tree.

That is, one still gets the error when build tree is unreadable.  It is
hard to say who is a guilty party.  At least part of blame goes to the
following:

- gcc: it skips nonexistent directories, but raises errors for unreadable
  ones
- gcl: it unconditionally adds include directive of form
    -I/gcl/system/directory/../h
  (where /gcl/system/directory/ is stored in si::*system-directory*
  variable)
- Axiom, because it lets si::*system-directory* stay at its default
  setting.

One possibility to solve this problem is to point si::*system-directory*
(more precisely the pathname with "../h" appended) to known empty (or non
existent) directory (for example somwhere inside Axiom tree).  If we
decide to do that we may even create real h directory and put
cmpinclude.h there.  I initially rejected such idea (changing 
si::*system-directory*) because I prefer limit our intervention into
gcl internals (note that compiler::*default-system-p* is nil by
default, so my patch merely restored default setting).  I was
also not aware that evan after applying the patch the permission
problem is still present:  my assumption was that gcl should be
capable of generating working standalone executables which can
compile code on the fly.  It is obvious that such executable
needs C compiler in the system, but I consider it a bug that
mere presence of unreadable directory with a magic name can
break such a program.
 
> | now in the same file in compile-file1 we have
> |
> |         (compiler-pass2 c-pathname h-pathname system-p ))
> |
> | and the beginning of compile-file1 is:
> |
> | (defun compile-file1 (input-pathname
> |                       &key (output-file input-pathname)
> |                            (o-file t)
> |                            (c-file *default-c-file*)
> |                            (h-file *default-h-file*)
> |                            (data-file *default-data-file*)
> |                            (c-debug nil)
> |                            #+aosvs (ob-file nil)
> |                            (system-p *default-system-p*)
> |
> | so during compile system-p is taken from *default-system-p*, unless
> | a specific values is given as a keyword argument.
> 
> -- Gaby
> 

\start
Date: Sun, 25 Feb 2007 17:53:12 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: document missing in installation

> Dear Waldek,
> 
> it seems that version 434 of wh-sandbox seems to install "document" to
> axiom/target/.../bin
> 
> Is this only on my machine?
>

On my machine wh-sandbox does not istall "document".  Do you want to
have "document" installed?
 
> Furthermore, it seems that my packages get recompiled in any case, even if I
> only did a configure to change the prefix.
> 

I belive that this is fixed in version 439.

\start
Date: Sun, 25 Feb 2007 18:09:44 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: Current directory at startup

Gregory Vanuxem wrote:
> Some (?) other issues:
> 
> (1) -> )cd temp
>    The current AXIOM default directory
> is /home/greg/wh-axiom/axiom/target/x86_64-unknown-linux/ 
> (1) -> )cd
>    The current AXIOM default directory is /home/greg/ 
> (1) -> )cd temp
>  
>    >> System error:
>    #p"/home/greg/" is not of type SEQUENCE.
> 
> the /home/greg/temp directory exists.
> 
> Greg
> 

I belive that following patch (applied to wh-sandbox) fixes this problem.
The patch may be somewhat controversial -- I removed code for ancient
systems (because this code is clearly broken by later changes) and
decided to consistently apply convention that directory names have
no extra directory separator at the end.  The changes may works or
not on Windows depending how Windows Lisps handle namestrings,
since I can not test what happens on Windows I did not try to add
special code.  AFAIK Windows kernel happily works with pathnames
containing slashes and many portable programs internally exclusively
use slashes in pathnames (converting from backslashes on input),
so the code _may_ work.  

Anyway, patch follows (note that this patch will probably do
no good without other pathname changes from wh-sandbox):

Index: src/interp/vmlisp.lisp.pamphlet
===================================================================
--- src/interp/vmlisp.lisp.pamphlet	(wersja 440)
+++ src/interp/vmlisp.lisp.pamphlet	(wersja 441)
@@ -97,13 +97,18 @@
 \section{The get-current-directory function}
 Contributed by Juergen Weiss.
 <<getCD>>=
+(defun trim-directory-name (name)
+    #+:unix
+    (if (char= (char name (1- (length name))) #\/)
+        (setf name (subseq name 0 (1- (length name)))))
+    name)
 #+:cmu
 (defun get-current-directory ()
   (namestring (extensions::default-directory)))
 
 #+(or :akcl :gcl)
 (defun get-current-directory ()
-  (namestring (truename "")))
+    (trim-directory-name (namestring (truename ""))))
 
 @
 \section{License}
@@ -2015,13 +2020,14 @@
 (defun MAKE-BVEC (n)
  (make-array (list n) :element-type 'bit :initial-element 0))
 
+<<getCD>>
+
 (in-package 'boot)
 
 <<manexp>>
 <<acot>>
 <<cot>>
 <<asec>>
-<<getCD>>
 <<Missing DFLOAT Transcendental functions>>
 
 
Index: src/interp/bootlex.lisp.pamphlet
===================================================================
--- src/interp/bootlex.lisp.pamphlet	(wersja 440)
+++ src/interp/bootlex.lisp.pamphlet	(wersja 441)
@@ -184,7 +184,6 @@
 	   (OPTIONLIST nil)
 	   (*EOF* NIL)
 	   (File-Closed NIL)
-	 ;;  ($current-directory "/spad/libraries/")
 	   (/editfile *spad-input-file*)
 	   (|$noSubsumption| |$noSubsumption|)
 	   in-stream out-stream)
Index: src/interp/util.lisp.pamphlet
===================================================================
--- src/interp/util.lisp.pamphlet	(wersja 440)
+++ src/interp/util.lisp.pamphlet	(wersja 441)
@@ -760,36 +760,6 @@
       (mapcar #'load files)))
 
 @
-\subsubsection{interp-make-directory}
-This is used by the ")cd" system command.
-<<interp-make-directory>>=
-(defun interp-make-directory (direc)
-  (setq direc (namestring direc))
-  (if (string= direc "")  $current-directory
-   (if (or (memq :unix *features*)
-	   (memq 'unix *features*))
-    (progn
-      (if (char/= (char $current-directory (1-(length $current-directory))) #\/)
-	  (setq $current-directory (concat $current-directory "/")))
-      (if (char/= (char direc 0) #\/)
-	  (setq direc (concat $current-directory direc)))
-      (if (char/= (char direc (1- (length direc))) #\/)
-	  (setq direc (concat direc "/")))
-      direc)
-    (progn ;; Assume Windows conventions
-      (if (not (or (char= (char $current-directory (1- (length $current-directory))) #\/)
-                   (char= (char $current-directory (1- (length $current-directory))) #\\ )))
-	  (setq $current-directory (concat $current-directory "\\")))
-      (if (not (or (char= (char direc 0) #\/)
-                   (char= (char direc 0) #\\)
-                   (find #\: direc)))
-          (setq direc (concat $current-directory direc)))
-      (if (not (or (char= (char direc (1- (length direc))) #\/)
-                   (char= (char direc (1- (length direc))) #\\ )))
-	  (setq direc (concat direc "\\")))
-      direc))))
-
-@
 \subsubsection{make-directory}
 Make a directory relative to the {\bf \$spadroot} variable.
 <<make-directory>>=
@@ -1448,12 +1418,11 @@
 <<license>>
 
 (in-package "BOOT")
-(export '($spadroot $directory-list $current-directory reroot
+(export '($spadroot $directory-list reroot
 	  make-absolute-filename |$msgDatabaseName| |$defaultMsgDatabaseName|))
 
 <<our-write-date>>
 <<make-directory>>
-<<interp-make-directory>>
 <<bin-path>>
 <<load-directory>>
 <<compspadfiles>>
Index: src/interp/patches.lisp.pamphlet
===================================================================
--- src/interp/patches.lisp.pamphlet	(wersja 440)
+++ src/interp/patches.lisp.pamphlet	(wersja 441)
@@ -114,15 +114,11 @@
     ))
 
 (defun |cd| (args)
-  (cond ((null args)
-#+(and :lucid :ibm/370)
-         (setq $current-directory "")
-#-(and :lucid :ibm/370)
-         (setq $current-directory (truename (user-homedir-pathname))) )
-        ((eql (|directoryp| (interp-make-directory (car args))) 1)
-         (setq $current-directory (namestring (truename (interp-make-directory (car args)))))))
-#+(or :kcl :ibcl :CCL) (system:CHDIR $current-directory)
-  (|sayKeyedMsg| 'S2IZ0070 (list (namestring $current-directory))))
+    (let ((dname (if (null args)
+                     (trim-directory-name (namestring (user-homedir-pathname)))
+                     (car args))))
+         #+(or :kcl :ibcl :CCL) (system:CHDIR dname))
+  (|sayKeyedMsg| 'S2IZ0070 (list (get-current-directory))))
 
 <<toplevel>>
 (define-function 'top-level #'toplevel)
@@ -285,10 +281,6 @@
 (setq |$consistencyCheck| ()) ;; prevents wasting time checking consistency
 
 
-#+(or :CCL (and :lucid :ibm/370))
-(setq vmlisp::$current-directory (truename "."))
-#-(or :CCL (and :lucid :ibm/370))
-(setq vmlisp::$current-directory (make-directory *default-pathname-defaults*))
 
 (defvar *msghash* nil "hash table keyed by msg number")
 
@@ -328,8 +320,6 @@
 (|initializeTimedNames| |$interpreterTimedNames| |$interpreterTimedClasses|)
 
 #+:dos
-(setq vmlisp::$current-directory (truename "."))
-#+:dos
 (setq vmlisp::$spadroot "/spad/mnt/dos")
 #+:dos
 (defun user-homedir-pathname ()
Index: src/interp/nlib.lisp.pamphlet
===================================================================
--- src/interp/nlib.lisp.pamphlet	(wersja 440)
+++ src/interp/nlib.lisp.pamphlet	(wersja 441)
@@ -435,7 +435,7 @@
 (defun make-full-namestring (filearg &optional (filetype nil))
   (namestring (merge-pathnames (make-filename filearg filetype))))
 
-(defun get-directory-list (ft &aux (cd (namestring $current-directory)))
+(defun get-directory-list (ft &aux (cd (get-current-directory)))
   (cond ((member ft '("NRLIB" "DAASE" "EXPOSED") :test #'string=)
 	   (if (eq BOOT::|$UserLevel| 'BOOT::|development|)
 	       (cons cd $library-directory-list)
Index: src/interp/bookvol5.pamphlet
===================================================================
--- src/interp/bookvol5.pamphlet	(wersja 440)
+++ src/interp/bookvol5.pamphlet	(wersja 441)
@@ -177,8 +177,6 @@
 coerceFailure                &                     & runspad \\
 curinstream                  & ncIntLoop           & \\
 curoutstream                 & ncIntLoop           & \\
-vmlisp::\$current-directory  & restart             & \\
-                             & reroot              & \\
 \$currentLine                & restart             & removeUndoLines \\
 \$dalymode                   &                     & intloopReadConsole \\
 \$defaultMsgDatabaseName     & reroot              & \\
@@ -275,28 +273,6 @@
 [[*standard-output*]] common lisp variable in [[ncIntLoop]].
 While not using the ``dollar'' convention this variable is still ``global''.
 
-\subsection{vmlisp::\$current-directory}
-When running in Lucid Common Lisp ([[:lucid]]) on an IBM/370 mainframe
-([[:ibm/370]]) this variable is used in place of the 
-[[*default-pathname-defaults*]] common lisp variable. 
-Otherwise this variable is
-set to the empty string in [[restart]]. 
-
-Notice that the variable [[*default-pathname-defaults*]] is a Common
-Lisp standard variable with implementation defined meaning.
-Typically, its value is an object that represents the directory from
-where the Lisp image has been started.
-
-The [[reroot]] function sets this variable to the value of
-[[$spadroot]] which itself has the value of the argument to the
-[[reroot]] function. Since the argument to the [[reroot]] function is
-an string which represents an absolute pathname pointing to AXIOM the
-net result is that the [[$current-directory]] is set to point to the
-shell [[AXIOM]] variable.
-
-So during execute both [[$current-directory]] and [[$spadroot]] reflect
-the value of the [[AXIOM]] shell variable.
-
 \subsection{\$currentLine}
 The [[$currentLine]] line is set to [[NIL]] in [[restart]].
 It is used in [[removeUndoLines]] in the undo mechanism.
@@ -708,11 +684,6 @@
   (setq |$IOindex| 1)
   (setq |$InteractiveFrame| (|makeInitialModemapFrame|))
   (setq |$printLoadMsgs| t)
-#+(and :lucid :ibm/370)
-  (setq vmlisp::$current-directory "")
-#-(and :lucid :ibm/370)
-  (setq vmlisp::$current-directory
-     (make-directory *default-pathname-defaults*))
   (|loadExposureGroupData|)
   (|statisticsInitialization|)
   (|initHist|)
@@ -1144,8 +1115,7 @@
    (mapcar #'make-absolute-filename $relative-library-directory-list))
   (setq |$defaultMsgDatabaseName|
 	(pathname (make-absolute-filename "/share/msgs/s2-us.msgs")))
-  (setq |$msgDatabaseName| ())
-  (setq $current-directory $spadroot))
+  (setq |$msgDatabaseName| ()))
 
 @
 \subsection{defun statisticsInitialization}
Index: src/interp/sys-pkg.lisp.pamphlet
===================================================================
--- src/interp/sys-pkg.lisp.pamphlet	(wersja 440)
+++ src/interp/sys-pkg.lisp.pamphlet	(wersja 441)
@@ -427,7 +427,7 @@
 	 VMLISP::APPLX VMLISP::LASTNODE VMLISP::SUBSTQ VMLISP::TRUEFN
 	 VMLISP::|last| VMLISP::RPLACSTR VMLISP::SETQP VMLISP::QCADDR
 	 VMLISP::QCAADAR VMLISP::QCDDAAR VMLISP::|intersection|
-	 VMLISP::HASHTABLE-CLASS VMLISP::$CURRENT-DIRECTORY
+	 VMLISP::HASHTABLE-CLASS
 	 VMLISP::*COMP370-APPLY* VMLISP::QSETVELT VMLISP::MOVEVEC
 	 VMLISP::ID VMLISP::DEFINE-FUNCTION VMLISP::MSUBSTQ VMLISP::|nsubst|
 	 VMLISP::LISTOFFLUIDS VMLISP::SUB1 VMLISP::NUMBEROFARGS
@@ -449,7 +449,8 @@
 	 VMLISP::INTERSECTIONQ VMLISP::DSETQ VMLISP::FETCHCHAR
 	 VMLISP::STRCONC VMLISP::MACRO-MISSINGARGS VMLISP::RPACKFILE
 	 VMLISP::EXIT VMLISP::PLUS VMLISP::RKEYIDS
-	 VMLISP::COMPILE-LIB-FILE VMLISP::RECOMPILE-LIB-FILE-IF-NECESSARY))
+	 VMLISP::COMPILE-LIB-FILE VMLISP::RECOMPILE-LIB-FILE-IF-NECESSARY
+         VMLISP::GET-CURRENT-DIRECTORY VMLISP::TRIM-DIRECTORY-NAME))
 
 ;;; Definitions for package BOOT of type SHADOW
 (lisp:in-package "BOOT")
Index: ChangeLog.wh
===================================================================
--- ChangeLog.wh	(wersja 440)
+++ ChangeLog.wh	(wersja 441)
@@ -1,3 +1,22 @@
+2007-02-25  Waldek Hebisch  Waldek Hebisch
+
+	Fix current directory handling.  Remove $current-directory
+	variable and all referenctes to it.
+	* src/interp/vmlisp.lisp.pamphlet: trim-directory-name: new
+	function.
+	<getCD>: move to VMLISP package
+	* src/interp/sys-pkg.lisp.pamphlet: export get-current-directory
+	and trim-directory-name.
+	* src/interp/patches.lisp.pamphlet: |cd|: just change directory
+	(do not mess with $current-directory).
+	do not set $current-directory.
+	* src/interp/bookvol5.pamphlet: do not set $current-directory.
+	* src/interp/nlib.lisp.pamphlet: get-directory-list: use
+	get-current-directory.
+	* src/interp/util.lisp.pamphlet: interp-make-directory: remove.
+	* src/interp/bootlex.lisp.pamphlet: remove comment referencing
+	$current-directory.
+	
 2007-02-24  Waldek Hebisch  Waldek Hebisch
 
 	Make the final image independent of cmpinclude.h

\start
Date: 25 Feb 2007 18:37:40 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Bug with paths in wh-sandbox
Cc: Gabriel Dos Reis

Dear all,

Waldek Hebisch writes:

> my assumption was that gcl should be capable of generating working standalone
> executables which can compile code on the fly.  It is obvious that such
> executable needs C compiler in the system, but I consider it a bug that mere
> presence of unreadable directory with a magic name can break such a program.

I'm not sure if Camm reads axiom-devel, so, did you consider asking him?

\start
Date: 25 Feb 2007 18:39:25 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: document missing in installation

Waldek Hebisch writes:

> On my machine wh-sandbox does not istall "document".  Do you want to have
> "document" installed?

Yes, definitively. Otherwise, contributed packages cannot be compiled.

\start
Date: Sun, 25 Feb 2007 11:48:28 -0600
From: Tim Daly
To: Gregory Vanuxem, Waldek Hebisch
Subject: compiled-function-p

> I suspect that the use of compiled-function-p is bogus: Axiom probably
> assumes that the function is either a lambda list or is
> a compiled function. But it looks that such assumption was true in
> the past....

Actually, in other lisps that hosted Axiom, such as VMLisp, it was
perfectly possible for the so-called function position of an
expression to contain virtually any expression. VMLisp will do a
complete recursive evaluation of the car of an expression.  Common
lisp introduced restrictions on what could appear in the function
position. Since common lisp is our new, favorite lisp we can remove
the test. Portions of the code still contain these historical lisp-isms.

\start
Date: Sun, 25 Feb 2007 11:49:04 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Bug with paths in wh-sandbox

On Sun, 25 Feb 2007, Waldek Hebisch wrote:

| > The link I'm missing is why Axiom's misbehaviour (reported by both
| > Gregory and Martin) is traced back to that.  Or am I lured by the
| > title of the thread? (I have been travelling the whole week, so I have
| > no access to all the discussion, only this one and some other bits).
| >
|
| First, this fixes _part_ of the problem that Martin reported (problem
| reported by Gregory are fixed by another patch).

Aha, this is what I missed -- I thought the other parts were also solved.

\start
Date: Sun, 25 Feb 2007 12:15:26 -0600
From: Tim Daly
To: Waldek Hebisch
Subject: compiled-function-p

> Anyway, patch follows (note that this patch will probably do
> no good without other pathname changes from wh-sandbox

Here is where my problem arises. When trying to build a system that
many people will use, such as Gold, it is important that I don't
introduce more, or more subtle, errors than I fix. I'm very reluctant
to change what I don't understand since, in the long run I and others
may need to maintain it.

In order to apply your changes I will need to evaluate every other
change you've made to decide if it is related or a prerequisite change.
It can take a day or more to difference your source tree from Gold and
do this evaluation since there is no documentation in the source files
explaining why the change was made. And it is not clear if these changes
depend on other parts of your sandbox, such as Gaby's build system.

This change is a worthwhile idea and should be brought forward to Gold.
It would be most helpful, and Gold would happen a lot faster, if you 
could take the time to make a diff-Naur Gold patch containing the
complete changeset.

\start
Date: Sun, 25 Feb 2007 12:55:09 -0600 (CST)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Bug with paths in wh-sandbox

On Sun, 25 Feb 2007, Waldek Hebisch wrote:

[...]

| First, this fixes _part_ of the problem that Martin reported (problem
| reported by Gregory are fixed by another patch).
|
| : Ein weiteres Problem, das bei putty aufgetreten ist, war die folgende Fehlermeldung:
| : (1) ->
| : (1) -> f(0)==0
| :                                                                    Type: Void
| : (2) -> f(1)==1
| :                                                                    Type: Void
| : (3) -> f(n)==f(n-1)+f(n-2)
| :                                                                    Type: Void
| : (4) -> f(7)
| :    Compiling function f with type Integer -> NonNegativeInteger
| :    Compiling function f as a recurrence relation.
| : cc1: Fehler: /local/scratch/wh-sandbox/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h: Permission denied
|
| This errors came for gcc search for include files.  The patch I applied
| allows Axiom to work when build tree is not present.  In other words,
| when you make a tarball of installed Axiom and put it on another
| machine it will work, unless there is unreadable directory on path
| leading to original build tree.
|
| That is, one still gets the error when build tree is unreadable.  It is
| hard to say who is a guilty party.  At least part of blame goes to the
| following:
|
| - gcc: it skips nonexistent directories, but raises errors for unreadable
|   ones

In this case, it is not clear to me how the resulting C program would
compile if GCL's header is not included.  So, it is probably a good
thing that GCC complained.  But, I think the root cause is elsewhere.

| - gcl: it unconditionally adds include directive of form
|     -I/gcl/system/directory/../h
|   (where /gcl/system/directory/ is stored in si::*system-directory*
|   variable)
| - Axiom, because it lets si::*system-directory* stay at its default
|   setting.

My understanding (Camm, please correct me) is that GCL is not set up
yet to work without its internal header file.  However, if that is
true I can't explain why we did not run into that problem before...

\start
Date: Sun, 25 Feb 2007 12:57:51 -0600 (CST)
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Bug with paths in wh-sandbox

On Sun, 25 Feb 2007, Martin Rubey wrote:

| Dear all,
|
| Waldek Hebisch writes:
|
| > my assumption was that gcl should be capable of generating working standalone
| > executables which can compile code on the fly.  It is obvious that such
| > executable needs C compiler in the system, but I consider it a bug that mere
| > presence of unreadable directory with a magic name can break such a program.
|
| I'm not sure if Camm reads axiom-devel, so, did you consider asking him?

My understanding is that Camm is subscribed to the list.  However,
from time to time -- for our own protection against spams -- bona fide
subscribers may be unsubscribed.  I believe Camm had suggested to be
explicitly CC:'d in case his input is needed.  Furthermore, I think he
also explained that he will not be back before March or something like
that.

\start
Date: 25 Feb 2007 13:36:34 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Lazyness in lexing Boot and Spad

  Axiom's implementation of Boot's and Spad source includer
(src/boot/btincl2.boot, src/interp/cstream.boot) uses lazyness (faked
through function "Delay").  This is also variously known as zipper.
My quesion is how much of the complexity introduced by faking
lazyness actually outweight the benefits?  Is the lazyness actually
beneficial? 

\start
Date: Sun, 25 Feb 2007 21:14:52 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Bug with paths in wh-sandbox

Gabriel Dos Reis wrote:
> On Sun, 25 Feb 2007, Waldek Hebisch wrote:
> 
> [...]
> 
> | First, this fixes _part_ of the problem that Martin reported (problem
> | reported by Gregory are fixed by another patch).
> |
> | : Ein weiteres Problem, das bei putty aufgetreten ist, war die folgende Fehlermeldung:
> | : (1) ->
> | : (1) -> f(0)==0
> | :                                                                    Type: Void
> | : (2) -> f(1)==1
> | :                                                                    Type: Void
> | : (3) -> f(n)==f(n-1)+f(n-2)
> | :                                                                    Type: Void
> | : (4) -> f(7)
> | :    Compiling function f with type Integer -> NonNegativeInteger
> | :    Compiling function f as a recurrence relation.
> | : cc1: Fehler: /local/scratch/wh-sandbox/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h: Permission denied
> |
> | This errors came for gcc search for include files.  The patch I applied
> | allows Axiom to work when build tree is not present.  In other words,
> | when you make a tarball of installed Axiom and put it on another
> | machine it will work, unless there is unreadable directory on path
> | leading to original build tree.
> |
> | That is, one still gets the error when build tree is unreadable.  It is
> | hard to say who is a guilty party.  At least part of blame goes to the
> | following:
> |
> | - gcc: it skips nonexistent directories, but raises errors for unreadable
> |   ones
> 
> In this case, it is not clear to me how the resulting C program would
> compile if GCL's header is not included.  So, it is probably a good
> thing that GCC complained.  But, I think the root cause is elsewhere.
>

My point is that GCC is inconsistent here: both non-existent and unreadable
directory raise the some alternative: either directory is not needed
(and may be safely skipped) or is needed.  I can guess that GCC made
a pragmatic decision here: non existent directories are probably very
frequent and GCC does not dare to signal error. 
 
> | - gcl: it unconditionally adds include directive of form
> |     -I/gcl/system/directory/../h
> |   (where /gcl/system/directory/ is stored in si::*system-directory*
> |   variable)
> | - Axiom, because it lets si::*system-directory* stay at its default
> |   setting.
> 
> My understanding (Camm, please correct me) is that GCL is not set up
> yet to work without its internal header file.  However, if that is
> true I can't explain why we did not run into that problem before...
> 

Try the following (or belive me that you get indicated result). Create
a simple Spad file.  Take Axiom from build-improvements (or wh-sandbox),
with gcl intalation visible.  By default you should see 
compiler::*default-system-p* set to t.

1) Try just compiling your file.  It should compile fine.
2) Change access right on gcl instaltion so that it is unreadable by
you.  Again try compiling: you should see error about lack of
access to gcl directory
3) rename gcl directory. Again try compiling: you should see a
cascade of errors from gcc (due to missing declarations from
include file).
4) do
)lisp (setf compiler::*default-system-p* nil)
compile again: Your file should compile fine.
5) Move back gcl instalation into is original place (still
ureadable by you).  Compile again: you should see the same
error as in 2.

Point 4 shows that executable created by gcl _can_ compile Lisp
files if compiler::*default-system-p*  is set to nil and
include directory is either absent or readible.  With include
directory present, but unreadable (point 5 above) you get errors.

As I wrote, when compiler::*default-system-p* is nil C files generated
by gcl do not need the gcl include file.  But gcl still add corresponding
-I option to gcc comand line, and you get spurious errors.

\start
Date: Sun, 25 Feb 2007 22:08:02 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Lazyness in lexing Boot and Spad

> 
> Hello,
> 
>   Axiom's implementation of Boot's and Spad source includer
> (src/boot/btincl2.boot, src/interp/cstream.boot) uses lazyness (faked
> through function "Delay").  This is also variously known as zipper.
> My quesion is how much of the complexity introduced by faking
> lazyness actually outweight the benefits?  Is the lazyness actually
> beneficial? 
> 

AFAICS the main potential of benefit of lazyness is that it allows
writing algorithm as if it operated on the whole file, but still
have "interactive" parser -- that is parser which stops reading
its input when it sees end of a syntactic construct.

This potential benefit is completly lost in Axiom: the command
line parser requires that the whole construct is on single logical
line (that is single line after joining all continuated lines).
I can guess that command line parser is non-interactive due to
backtracking and also because whitespace syntax lacks explicit
end-of-construct markes (for example parser sees that a procedure
ended only when seeing next procedure or end of file).

I must say that this whole pipeline:

scan.boot.pamphlet pile.boot.pamphlet pf2sex.boot.pamphlet
pf2atree.boot.pamphlet parini.boot.pamphlet packtran.boot.pamphlet
macex.boot.pamphlet intfile.boot.pamphlet incl.boot.pamphlet
dq.boot.pamphlet cstream.boot.pamphlet cparse.boot.pamphlet
astr.boot.pamphlet

is on my list of candidates for removal.  I would like to reuse
parts of this code, but I belive that what we need can be done
simpler.  However, rewriting this part for me is of low priority,
and I probably will not get to this before summer.

My vision of future compiler is:  
- classical lexer which generates basic syntax tree nodes (including
  line number info)
- first stage parser (build surface syntax tree) accepting very
  loose grammar
- macroexpander
- second stage parser (flattening trees and checking syntactic
  constraints which cna be checked only after macro expansion)
- typechecker, probably multipass.  In first few passes I would only
  consider interface parts, the final pass would also check bodys
  (and resolve overloading)
- final code generation

Some remarks why such structure:  I want macro expansion rather
early, because before macro expansion is it impossible to check
for syntax correctness.  Also, full syntactic information helps
with typechecking (current parser has it backwards, it uses
type information for parsing, leading sometimes to weird errors).

Also, current compiler couples code generation with type checking,
which is potentialy wastefull.  Namely, in some cases the compiler
has to do backtracking search on possible type assignments, so
it generates code and then discard it during backtracking (I am
not sure how serious this problem is -- most of the time backtracking
is very limited).  

During compilation in some cases (IIRC in chaseInferences) the compiler
uses recursive traversal on a dag (ignoring identity of nodes)
which leads to about 3m spent on a single file (samewhat surprisingly
the particular procedure I found shows pathological behaviour only one
file, on other taking only little time).

I belive that having typechecking as a separate phase operationg
essentially on the whole program would allow beter search technique
and would avoid many time sinks (currently many global data structure
are invalidated after compilation of any constructors, which is
probably responsible for nonlinear compile times for multifile
compilations).

\start
Date: 25 Feb 2007 18:01:50 -0600
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Lazyness in lexing Boot and Spad

Waldek Hebisch writes:

| > 
| > Hello,
| > 
| >   Axiom's implementation of Boot's and Spad source includer
| > (src/boot/btincl2.boot, src/interp/cstream.boot) uses lazyness (faked
| > through function "Delay").  This is also variously known as zipper.
| > My quesion is how much of the complexity introduced by faking
| > lazyness actually outweight the benefits?  Is the lazyness actually
| > beneficial? 
| > 
| 
| AFAICS the main potential of benefit of lazyness is that it allows
| writing algorithm as if it operated on the whole file, but still
| have "interactive" parser -- that is parser which stops reading
| its input when it sees end of a syntactic construct.

I'm familiar with Haskell -- and have written slightly more than "toy"
programs in Haskell, so I appreciate the benefits of lazyness in
general.  I apologize I did not make make it clearer that I'm talking
of the specific case of Axiom's way of consuming the token stream.

I posit that if we had strictness analysis in Axiom, then the analysis
would find out that actually the parts that effectively consumes the
token stream are strict in the token stream argument.  So, lazyness
buys nothing.  I base that conjecture over "debugging" under GCL.
That is why I raised the question of the lazyness benefits in the
specific case of Axiom's current infrastructure.

| This potential benefit is completly lost in Axiom: the command
| line parser requires that the whole construct is on single logical
| line (that is single line after joining all continuated lines).

Yes.  Which a strictness analysis will find out.

| I can guess that command line parser is non-interactive due to
| backtracking and also because whitespace syntax lacks explicit
| end-of-construct markes (for example parser sees that a procedure
| ended only when seeing next procedure or end of file).

Yes.  But, I don't think that makes a huge difference.

| I must say that this whole pipeline:
| 
| scan.boot.pamphlet pile.boot.pamphlet pf2sex.boot.pamphlet
| pf2atree.boot.pamphlet parini.boot.pamphlet packtran.boot.pamphlet
| macex.boot.pamphlet intfile.boot.pamphlet incl.boot.pamphlet
| dq.boot.pamphlet cstream.boot.pamphlet cparse.boot.pamphlet
| astr.boot.pamphlet
| 
| is on my list of candidates for removal.

There are many files on that list that I would disagree on removing.
This statement is based on spending a non-negligible part of the last
10 months studying from different angles.  No doubt they need
improvement.  But, I'm deeply skeptical about their removal.

|  I would like to reuse
| parts of this code, but I belive that what we need can be done
| simpler.  However, rewriting this part for me is of low priority,
| and I probably will not get to this before summer.

I've done some work on it in several local tress, but their
combination is not a coherent structure at this time I'm afraid.

While working on those parts of the compiler (and interpreter), I've
considered a suggestion made by Bill Page some time ago: maybe rewrite
Axiom in Haskell?  On several occasions, I've resisted that idea.
But, if we get the improvements in both Boot and the compiler
structures, it will look a lot like something written in "simple
Haskell".  Funny.

| My vision of future compiler is:  
| - classical lexer which generates basic syntax tree nodes (including
|   line number info)
| - first stage parser (build surface syntax tree) accepting very
|   loose grammar
| - macroexpander
| - second stage parser (flattening trees and checking syntactic
|   constraints which cna be checked only after macro expansion)
| - typechecker, probably multipass.  In first few passes I would only
|   consider interface parts, the final pass would also check bodys
|   (and resolve overloading)
| - final code generation
| 
| Some remarks why such structure:  I want macro expansion rather
| early, because before macro expansion is it impossible to check
| for syntax correctness.  Also, full syntactic information helps
| with typechecking (current parser has it backwards, it uses
| type information for parsing, leading sometimes to weird errors).

I'm unclear about your issue with macro expansion.  From my
understanding, they happen very early in the compilation process --
albeit not like C macro expansion (a horror I would like to see
disappear the surface of the planet).

   --% WHERE
   compWhere([.,form,:exprList],m,eInit) ==
     $insideExpressionIfTrue: local:= false
     $insideWhereIfTrue: local:= true
     e:= eInit
     u:=
       for item in exprList repeat
         [.,.,e]:= comp(item,$EmptyMode,e) or return "failed"
     u="failed" => return nil
     $insideWhereIfTrue:= false
     [x,m,eAfter]:= comp(macroExpand(form,eBefore:= e),m,e) or return nil
     eFinal:=
       del:= deltaContour(eAfter,eBefore) => addContour(del,eInit)
       eInit
     [x,m,eFinal]


I would like Axiom to have the ability to store the following:
  (1) the "parse form"
  (2) the "fully typed ast" before code generation

I have an intermediate representation of Spad in Spad.  It lacks
a couple of feature, but I can handle almost all algebra files.

| Also, current compiler couples code generation with type checking,
| which is potentialy wastefull.  Namely, in some cases the compiler
| has to do backtracking search on possible type assignments, so
| it generates code and then discard it during backtracking (I am
| not sure how serious this problem is -- most of the time backtracking
| is very limited).  

Yes, my guestimate was that the waste generated by backtracking is
small enough.

| During compilation in some cases (IIRC in chaseInferences) the compiler
| uses recursive traversal on a dag (ignoring identity of nodes)
| which leads to about 3m spent on a single file (samewhat surprisingly
| the particular procedure I found shows pathological behaviour only one
| file, on other taking only little time).
| 
| I belive that having typechecking as a separate phase operationg
| essentially on the whole program would allow beter search technique
| and would avoid many time sinks (currently many global data structure
| are invalidated after compilation of any constructors, which is
| probably responsible for nonlinear compile times for multifile
| compilations).

That idea is already present in some form:

intloopSpadProcess(stepNo,lines,ptree,interactive?)==
    $stepNo:local := stepNo
    $currentCarrier := cc := ['carrier]
    ncPutQ(cc, 'stepNumber, stepNo)
    ncPutQ(cc, 'messages, $ncMsgList)
    ncPutQ(cc, 'lines, lines)
    $ncMsgList := nil
    result := CatchAsCan(flung, Catch("SpadCompileItem",
     CATCH($intCoerceFailure, CATCH($intSpadReader,
       interp(cc, ptree, interactive?))))) where
 
        interp(cc, ptree, interactive?) ==
            ncConversationPhase(function phParse,            [cc, ptree])
            ncConversationPhase(function phMacro,            [cc])
            ncConversationPhase(function phIntReportMsgs,[cc, interactive?])
            ncConversationPhase(function phInterpret,        [cc])
 
            #ncEltQ(cc, 'messages) ^= 0 => ncError()
 
    intSetNeedToSignalSessionManager()
    $prevCarrier := $currentCarrier
    result = 'ncEnd     => stepNo
    result = 'ncError   => stepNo
    result = 'ncEndItem => stepNo
    stepNo+1
 
\start
Date: Mon, 26 Feb 2007 10:08:13 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: Build problem (was [SOLVED] %S in some contr. pkg fails to compile)

Martin,
it all works now thanks to your detailed help. I compiled
the latest axiom-silver, that's why the reply took so long.

The problem was, on the web page I saw the button named 'src'
and I thought hey just )read that into axiom ...

Axiom Silver has a bug BTW which prevents it from building
from svn. svn creates subdirectories named .svn/ with some read-only
files, and at two places in the make process there are commands
'cp -r' (recursive) that will try to copy these directories, too.
Maybe they should be changed to 'cp -r [a-zA-Z]* ...'?

\start
Date: Mon, 26 Feb 2007 15:07:13 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Lazyness in lexing Boot and Spad

If SPAD provides "Generator" that would be sufficient. In Aldor-Combinat 
I have implemented streams and formal power series building on that concept.

I have not checked Axiom, but I guess defining a series like

s: FormalPowerSeries(Integer) := new();
set!(s, 1 + monom * s * s);

is not possible. Am I wrong? Maybe the delay keyword allows it??? (Could 
someone show me?)

Of course, I would rather like to write

s := 1 + monom * s * s;

or perhaps with == instead of :=, but that would really require lazyness.

Ralf

On 02/25/2007 08:36 PM, Gabriel Dos Reis wrote:
> Hello,
> 
>   Axiom's implementation of Boot's and Spad source includer
> (src/boot/btincl2.boot, src/interp/cstream.boot) uses lazyness (faked
> through function "Delay").  This is also variously known as zipper.
> My quesion is how much of the complexity introduced by faking
> lazyness actually outweight the benefits?  Is the lazyness actually
> beneficial? 
> 

\start
Date: Mon, 26 Feb 2007 09:34:19 -0600 (CST)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Lazyness in lexing Boot and Spad

On Mon, 26 Feb 2007, Ralf Hemmecke wrote:

| If SPAD provides "Generator" that would be sufficient. In Aldor-Combinat
| I have implemented streams and formal power series building on that concept.
|
| I have not checked Axiom, but I guess defining a series like
|
| s: FormalPowerSeries(Integer) := new();
| set!(s, 1 + monom * s * s);
|
| is not possible. Am I wrong? Maybe the delay keyword allows it??? (Could
| someone show me?)
|
| Of course, I would rather like to write
|
| s := 1 + monom * s * s;
|
| or perhaps with == instead of :=, but that would really require lazyness.

The lazyness I was talking about in my message is at the Boot source
code level.

Lazyness at Spad level is a different issue.  The computational rules
used by Spad does not seem to be documented anywhere. Experimental
evidence suggests "call by value" but that does not seem to be
sancitoned by an official documentation.

\start
Date: Mon, 26 Feb 2007 17:45:57 -0600
From: Tim Daly
To: Gabriel Dos Reis
Subject: Lazyness in lexing Boot and Spad

> Is the lazyness actually beneficial?

I do not have knowledge of the internals of boot, which was
designed and written entirely by Dick Jenks and Bill Burge.
There were many parsers for Axiom and this was a research
area for Bill. I suspect that the DELAY you see in the zipper
parser was just another research experiment, not related to
the delay in recent languages in any way.

Frankly I believe the whole thing should be rewritten using the
syntax and semantics of Aldor but implemented in lisp, following 
the original scratchpad project plan.

The C based version can never reach into the axiom algebra tree
where the real value of axiom lies. Most of the functionality of
Aldor already exists. A cleanly designed and implemented parser
would go a long way toward making the project a stronger research
platform, both for language and for algebra. We could remove all
of boot and its complications and have a clearly specified AST
layer that users could access. Indeed, done properly and carefully
documented a new parser would allow an algebra file to define its
own input syntax, similar to it's ability to define its own output
syntax. Thus a quantum physics user could implement the "bra" and
"ket" operators, handle greek letters, etc.

But I think a parser rewrite waits on the language definition.
I don't think it would benefit us to be overly religious about
the language points at this time. It would be more important to
be able to parse what exists cleanly and make the parser extensible
from algebra. Lisp gives us the unique ability to manipulate the
intermediate language forms in the same implementation language.
Thus the "overhead" of letting algebra introduce new syntax is
minimal since even the console readtables can be changed on the fly.

\start
Date: 26 Feb 2007 18:34:20 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Lazyness in lexing Boot and Spad

Tim Daly writes:

| > Is the lazyness actually beneficial?
| 
| I do not have knowledge of the internals of boot, which was
| designed and written entirely by Dick Jenks and Bill Burge.
| There were many parsers for Axiom and this was a research
| area for Bill. I suspect that the DELAY you see in the zipper
| parser was just another research experiment, not related to
| the delay in recent languages in any way.
| 
| Frankly I believe the whole thing should be rewritten using the
| syntax and semantics of Aldor but implemented in lisp, following 
| the original scratchpad project plan.

I agree with the goal, except on the mean: src/boot/ should be
improved instead of being replaced by a system directly written in
Lisp.  I've spent a fair amount trying to understand that part of the
system.  I conjecture that anything that would be reinvented in Lisp
would be inferior and the resource is best spent documenting and
improving it.  For example, pattern matching let us directly express
algorithms and ideas, instead of the current circumvolutions of
predicate testing and wild casting.  src/boot/ already has pattern
matching, along with algebraic data type definition.  Initial testing
shows that the translator translates just fine.  It is regretful that
it has not been used in the rest of src/interp.

[...]

| But I think a parser rewrite waits on the language definition.

Yes.

| I don't think it would benefit us to be overly religious about
| the language points at this time. It would be more important to
| be able to parse what exists cleanly and make the parser extensible
| from algebra. Lisp gives us the unique ability to manipulate the
| intermediate language forms in the same implementation language.

So does Boot.

| Thus the "overhead" of letting algebra introduce new syntax is
| minimal since even the console readtables can be changed on the fly.

yes, and many aspect of the current implementation reminds me of use
Template Haskell

        http://www.haskell.org/th/

in domain specific languages.

\start
Date: Mon, 26 Feb 2007 18:43:16 -0600
From: Tim Daly
To: Gabriel Dos Reis
Subject: next release

> Well, patches are supposed to be posted when they are ready for
> "prime time" use. For "personal" experimentation we don't require
> that (should we?)

Well, clearly "personal" experimentation is a non-issue.

I'm not claiming that anyone has an obligation to share their
local changes. Indeed, the license does not require this either.
However, working together on a common project tends to imply sharing.
But real sharing involves work to "get it off your desk" and into
the common distribution.

The published mechanism for making changes to Gold is to post
  diff -Naur goldcode yourcode >patch
files to the mailing list




I see changes in various files that can be picked up at this time and
would benefit everyone. However, there are several, shall we say,
"challenges":



Challenge 1: SIMPLE CHANGES, such as removing the C prototype
  code is clear, tedious, harmless, and requires no explanation.
  I've already picked up these changes and made sure they happen
  in every file.




Challenge 2: LESS OBVIOUS CHANGES, such as eliding "member" from
  the boot code. This change was made with no documentation added
  to the source code making it impossible to (a) guess why and
  (b) test. Furthermore, there are no test cases so even if I
  understood it I'd have to develop the test cases again (assuming
  you had them in the first place) from scratch.




Challenge 3: ALGEBRA CHANGES. these are clearly beneficial as
  they address known bugs. Unfortunately I'm not an expert in ALL
  of the algebra and I'm adverse to changing what I don't understand.
  (Consider me the first in a long line of people maintaining this 
   code over the next 30 years. If I can't understand it how will they?)
  There was a change to the series code which went into Gold. Now we
  find out that the "fix" was wrong and a new "fix" is proposed. 
  I spoke with Clifton Williamson, the original author of the code, to
  try to validate the original code vs the new fix, so far with no
  decision. Do we want algebra bug fixes to lay around unmerged?
  Do we want to change algebra we don't understand? If we understand
  it do we want to share that information with future maintainers?

  If algebra bug fixes are to be merged we'd need to have some
  explanation of the algorithm so the code could be understood by
  people other than the person who proposed the fix. You need to
  understand the algorithm to fix it anyway so write down what you
  understand so others can understand.

  If algebra bug fixes are to be merged we'd need to have some
  test cases of the algorithm so the code can be checked, especially
  for boundary cases. If you've understood the algorithm and can fix
  it I'd suppose that you had test cases. Publish these as part of
  the fix.




Challenge 4: DEEP STRUCTURAL CHANGES. these are harder to merge as
  they will completely restructure axiom. this will have an impact
  not only on the main line of code but also on every other "private"
  branch of axiom, so it is vital that they are complete, consistent,
  and correct. 

  In order to merge this code it would need a cleanly documented
  pile of code. One of the main project goals is to make sure that
  the system can be maintained. That implies that other people can
  gain an understanding of the code without having to reverse
  engineer it. We're stuck with the reverse engineering task because
  Daly, et.al. didn't document anything. Lets learn from history.

  It would also have to be a diff of Gold since it would be impossible
  to know all of the little dependent pieces that are tucked away
  (e.g. the new axiom-c-macro.h file) or the new handling of
  gcl-cmpinclude.h, etc. You've spent months making GNU configure
  work. Wouldn't it be frustrating to find it badly broken because
  of merging problems?

  Other deep changes, such as a new parser, are also likely to be a
  "challenge 4" task.





> The axiom-commit mailing list has the history of all commits
> to SVN -- when they are not truncated due to SF policy

The axiom-commit mailing list posts are essentially worthless as a
Gold-merge resource. I can reclaim the same information in more detail
by doing 
   diff -r --brief build-improvements gold

What's missing is the (a) changesets (b) documentation (c) tests

The "changeset" mentality is that all of the changes necessary to
produce a final single effect are packaged in a single set of patches.

Changesets are essential to contain all of a change and only a change.
In the current bi/wh branches even simple changes, such as eliding
the C protoype code are spread over multiple commits and not fully
implemented everywhere. The new asq requires new database formats
and changes to the database generation code, all of which have to
happen at the same time.

Documentation is essential because while the axiom-commit says something
cryptic like "fixed bug #NNN", that message is hardly considered a high
quality, "production" piece of code. If we're going to make progress
against the winds of time we've got to consider the future maintainers.

Tests are necessary so that (a) other people can see what the impact
of a change is, (b) we can see what breaks in other peoples' branches
or the gold branch, (c) we can (eventually) regression test and (d) we
can eventually build up a more organized, comprehensive test suite 
like CATS (Computer Algebra Test Suite) that other people can build upon.




Since I'm in the midst of reverse-engineering the build-improvements
and wh-sandbox branches it would be a good time to consider packaging
up changesets for functionality you consider complete and ready. I know
it takes you away from "interesting" axiom tasks. The whole build process
has already cost me several weeks so I understand.

\start
Date: Tue, 27 Feb 2007 02:05:07 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: fixes and patches

> > Anyway, patch follows (note that this patch will probably do
> > no good without other pathname changes from wh-sandbox
> 
> Here is where my problem arises. When trying to build a system that
> many people will use, such as Gold, it is important that I don't
> introduce more, or more subtle, errors than I fix. I'm very reluctant
> to change what I don't understand since, in the long run I and others
> may need to maintain it.
> 
> In order to apply your changes I will need to evaluate every other
> change you've made to decide if it is related or a prerequisite change.
> It can take a day or more to difference your source tree from Gold and
> do this evaluation since there is no documentation in the source files
> explaining why the change was made. And it is not clear if these changes
> depend on other parts of your sandbox, such as Gaby's build system.
> 
> This change is a worthwhile idea and should be brought forward to Gold.
> It would be most helpful, and Gold would happen a lot faster, if you 
> could take the time to make a diff-Naur Gold patch containing the
> complete changeset.
>

I am trying to help, but sorry ATM I am very busy.  The list I posted
contains all changes that I consider to be user visible changes.  I belive
they are mostly independent of other patches.  Patches to .spad files
should apply to Gold with no (or little) changes.  Most algebra patches
reference bug numbers in Issue tracker.  Having Issue tracker number
you can find a testcase and frequently disscusion. Some fixes are
taken from Issue tracker.  Many algebra fixes show in test result
(the script I posted helps to automate comparison).  In particular
bug 312 is prominently visible (IIRC in series2.output) -- just
compare test results.

IIRC one fix to .spad files depends on changes to file handling
in interpreter (this should be obvious since those changes form
a single changeset == form single patch).  I think that changes
to interpreter files are independent of build system. One change
affecting Hyperdoc, that is installation on libdb etc, changes
Makefiles -- IIRC I have posted a version of this patch which
applies to Gold.  One change to Hyperdoc (extra change in protocol)
must be done both to Hyperdoc and to interpreter (otherwise
things will break), I belive that other Hyperdoc changes can be
applied independently (but some fixes concern Hyperdoc crashes,
so if you take incomplete set of fixes crash may eliminate 
possibility to see improvement due to other fixes).

I do not have time to make (and test) diffs to Gold.  But even
if I had time I do not know if making such diffs would be a
good idea: IIUC your devlopement version is different from
published one and you apply diffs manually.  Most of the time
different between Gold and wh-sandbox is trivial and will
cause no trouble.  The only trouble points are likely to
be due to removal of duplicate code in wh-sandbox and improvements
to build machinery.  But those to changes are made precisely
to avoid doing extra work.  Gaby spent time cleaning build
system, I spent time identifying duplicate/unused code (I do
_not_ remove code lightly).  Now you want us to spent time
working with issues that our work eliminated?

Note, if you want changes to wh-sandbox as separate patches
I can provide this (but I think you already have them from
the commit mailing list).  Also, if you have specific questions
concering patches I will try to answer.

\start
Date: Tue, 27 Feb 2007 02:52:54 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: next release
Cc: Gabriel Dos Reis

> Challenge 2: LESS OBVIOUS CHANGES, such as eliding "member" from
>   the boot code. This change was made with no documentation added
>   to the source code making it impossible to (a) guess why and
>   (b) test. Furthermore, there are no test cases so even if I
>   understood it I'd have to develop the test cases again (assuming
>   you had them in the first place) from scratch.
>

That issue has been discussed on the mailing list: 

Shoe tranlates member to MEMBER and passes MEMBER unchanged
Boot tranlates MEMBER to |member| and passes member as |member|

(to check just look at generated Lisp).  MEMBER and |member| have
different semantics.  If you look at generated spad files you
may easily see that compiler which uses MEMBER (insted of |member|)
mistranslate many files.

> 
> 
> 
> Challenge 3: ALGEBRA CHANGES. these are clearly beneficial as
>   they address known bugs. Unfortunately I'm not an expert in ALL
>   of the algebra and I'm adverse to changing what I don't understand.
>   (Consider me the first in a long line of people maintaining this 
>    code over the next 30 years. If I can't understand it how will they?)
>   There was a change to the series code which went into Gold. Now we
>   find out that the "fix" was wrong and a new "fix" is proposed.

If somebody compared test results the problem would be recognized
immediately.  
 
>   I spoke with Clifton Williamson, the original author of the code, to
>   try to validate the original code vs the new fix, so far with no
>   decision. Do we want algebra bug fixes to lay around unmerged?
>   Do we want to change algebra we don't understand? If we understand
>   it do we want to share that information with future maintainers?
> 

I wrote an explanation.  And my conclusion is simple: original code
was correct, but did not handle some cases with negative powers.
After change those cases were handled correctly, but fix missed
the last line from original code.  I restored the this missing
line (which is needed _only_ when constant term is 0).


> > The axiom-commit mailing list has the history of all commits
> > to SVN -- when they are not truncated due to SF policy
> 
> The axiom-commit mailing list posts are essentially worthless as a
> Gold-merge resource. I can reclaim the same information in more detail
> by doing 
>    diff -r --brief build-improvements gold
> 
> What's missing is the (a) changesets (b) documentation (c) tests
>

Tim, at least in wh-sandbox I tried to have changeset == commit.  There
are some exceptions (merge from build improvements was split into
few commits, once or twice I made a mistake and next commit fixed this),
but essentially having commits you have changesets.
 
> The "changeset" mentality is that all of the changes necessary to
> produce a final single effect are packaged in a single set of patches.
> 
> Changesets are essential to contain all of a change and only a change.

If you want to make changes completly indepenent then I must say sorry.
I try to avoid unneded dependencies, but changes I do are all part
of larger effort to make Axiom better.  Each is self contained but
may depend on previous changes.  Note that identifying independent
sets is a nonlinear and essentially useless task -- we want _one_
good version, not a myriad of combiantions of various patches.


> In the current bi/wh branches even simple changes, such as eliding
> the C protoype code are spread over multiple commits and not fully
> implemented everywhere. The new asq requires new database formats
> and changes to the database generation code, all of which have to
> happen at the same time.
>

No.  New asq should work fine with old databases.  Old asq can not
work with compressed or pretty printed databases (note that 
database documentation claims that compression is optional and
says that hunks are just Lisp forms -- nothing forbiding
pretty printing).  So new asq just implements what is documented
(removes undocumented restrictions from old asq).  The new
asq is _required_ if you want to use asq with uncompressed
databases (or prett print them).
 
\start
Date: 26 Feb 2007 23:27:45 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: next release

Tim Daly writes:

| > Well, patches are supposed to be posted when they are ready for
| > "prime time" use. For "personal" experimentation we don't require
| > that (should we?)
| 
| Well, clearly "personal" experimentation is a non-issue.
| 
| I'm not claiming that anyone has an obligation to share their
| local changes. Indeed, the license does not require this either.
| However, working together on a common project tends to imply sharing.
| But real sharing involves work to "get it off your desk" and into
| the common distribution.

This is true in general, including your changes to Gold we don't see
until the Big Day.  I'm trying to single you out.  We all have local
experimental trees that would do more harms if published than kept local.

[...]

| Challenge 1: SIMPLE CHANGES, such as removing the C prototype
|   code is clear, tedious, harmless, and requires no explanation.
|   I've already picked up these changes and made sure they happen
|   in every file.

Those changes are clearly beneficial in isolation.  Please note also
that because Gold and Silver have gone, until very recently, into very
uncertain status, it was hard to do anything useful.  Changes should
first go into Silver before being picked up and lifted to Gold.  We,
at least me, don't know which branch is Silver and what is its
status.  I don't know which is going to be Gold and its day-to-day
status, i.e. preview of what is to be Gold.  Under those
circumstances, it is hard to do anything useful to Silver and Gold.


| Challenge 2: LESS OBVIOUS CHANGES, such as eliding "member" from
|   the boot code. This change was made with no documentation added
|   to the source code making it impossible to (a) guess why and
|   (b) test. Furthermore, there are no test cases so even if I
|   understood it I'd have to develop the test cases again (assuming
|   you had them in the first place) from scratch.

I don't remember any patch eliding "member" from the Boot code.

[...]

| > The axiom-commit mailing list has the history of all commits
| > to SVN -- when they are not truncated due to SF policy
| 
| The axiom-commit mailing list posts are essentially worthless as a
| Gold-merge resource. I can reclaim the same information in more detail
| by doing 
|    diff -r --brief build-improvements gold

Those changes that would go into Gold, are ideally, diffs between
Silver and Gold.  However, I no longer know what is Silver and what is
Gold. 

| What's missing is the (a) changesets (b) documentation (c) tests
| 
| The "changeset" mentality is that all of the changes necessary to
| produce a final single effect are packaged in a single set of patches.

The "changeset" mentality must make room for incremental improvements;
that is a necessity when you don't have the power (e.g. resources) to
make change in one shot in a timely manner and remain useful.  Users
are more tolerant of incremental improvements than may be assumed.

[...]

| Since I'm in the midst of reverse-engineering the build-improvements
| and wh-sandbox branches it would be a good time to consider packaging
| up changesets for functionality you consider complete and ready. I know
| it takes you away from "interesting" axiom tasks. The whole build process
| has already cost me several weeks so I understand.

It is not a matter of taking me away from "interesting" axiom tasks than
asking me to allocate time today or this week when I have none to
solve the fuzzily defined problem.  I was travelling last week
attending (important) ISO C++ meetings, which made me fall behind
class schedules which I need to catch on this week, plus the usual
deadlines that come hard when time is short.


I need the following:
  (a) a clear mark of what is Silver, what is Gold
  (b) I would like to be able to propose diff between Silver and Gold
      for inclusion in Gold
  (c) I would like to have patches applied directly to Silver,
      assumming the general community is interested.  I.e. I would like
      to see more testing of "gold preview".

Can we work that out?

\start
Date: 26 Feb 2007 23:46:36 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: next release

Gabriel Dos Reis writes:

| Tim Daly writes:
| 
| | > Well, patches are supposed to be posted when they are ready for
| | > "prime time" use. For "personal" experimentation we don't require
| | > that (should we?)
| | 
| | Well, clearly "personal" experimentation is a non-issue.
| | 
| | I'm not claiming that anyone has an obligation to share their
| | local changes. Indeed, the license does not require this either.
| | However, working together on a common project tends to imply sharing.
| | But real sharing involves work to "get it off your desk" and into
| | the common distribution.
| 
| This is true in general, including your changes to Gold we don't see
| until the Big Day.  I'm trying to single you out.  We all have local
                         ^

arrgh.  I did it again :-(.  Obviously my fingers again did not obey my
brain when it said "NOT".  Sorry for that.  I hope you deduced that
from the rest of the paragraph.

| experimental trees that would do more harms if published than kept local.

\start
Date: Tue, 27 Feb 2007 00:11:39 -0600
From: Tim Daly
To: Gabriel Dos Reis
Subject: next release

Gaby,

> This is true in general, including your changes to Gold we don't see
> until the Big Day. I'm trying to single you out. We all have local
> experimental trees that would do more harms if published than kept local.

I published my whole research tree (in git, since svn was broken)
in November when we had this same discussion but got no response.
All of my axiom-related work is now kept in that tree.




>...[snip]... Please note also 
> that because Gold and Silver have gone, until very recently, into very
> uncertain status ...[snip]...

The plan was to publish a new Gold at the end of November.  But in the
beginning of November we had the big discussion about me being "a
single point of failure" so I stepped out of the way and told everyone
that any changes they wanted in Gold they would have to do
themselves. Everyone had permission to do that. Since that time no-one
has changed anything. It became clear that nobody was going to make
the effort to create a new release.  I've decided to step back into
the role of releasing systems and am trying to catch up to the
outstanding changes.

I tried maintaining silver but I was the only one making changes.
Plus the additional copies of Axiom were causing rising server costs.
If it depends on my effort silver is dead. I only have enough time
available to do Gold and do my own axiom-related work. I certainly
don't have time to maintain silver. Since advocacy is volunteering
you're welcome to create and maintain a silver version that is a
test version for gold changes. 

Gold will again be released on a 2-month, best-effort schedule.

\start
Date: Tue, 27 Feb 2007 00:20:06 -0600
From: Tim Daly
To: Gabriel Dos Reis
Subject: next release

> arrgh. I did it again :-(

funny. :-)

\start
Date: Tue, 27 Feb 2007 00:58:49 -0600 (CST)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: next release

On Tue, 27 Feb 2007 Tim Daly wrote:

| Gaby,
|
| > This is true in general, including your changes to Gold we don't see
| > until the Big Day. I'm trying to single you out. We all have local
| > experimental trees that would do more harms if published than kept local.
|
| I published my whole research tree (in git, since svn was broken)
| in November when we had this same discussion but got no response.

It appeared to me to be an "experiment".  I did not exactly what I
should "answer".

| All of my axiom-related work is now kept in that tree.
|
|
|
|
| >...[snip]... Please note also
| > that because Gold and Silver have gone, until very recently, into very
| > uncertain status ...[snip]...
|
| The plan was to publish a new Gold at the end of November.  But in the
| beginning of November we had the big discussion about me being "a
| single point of failure" so I stepped out of the way and told everyone
| that any changes they wanted in Gold they would have to do
| themselves.  Everyone had permission to do that. Since that time no-one
| has changed anything. It became clear that nobody was going to make
| the effort to create a new release.

My understanding was that decision was the outcome of
miscommunication, therefore I was not going to do any release or do any
commit to Silver or Gold (I don't know exactly which trees are those)
_until that was resolved_.  Clearly, I'm not going to take anybody's
place if that someone thinks he is being "kicked out".  Sorry to put
it that way, but that is how your message sounded.


[ For example, I needed an "official" version for my last semester
  class project, but in the end I distributed an official version
  of build-improvements so that students can work.  I would have
  preferred it was official. ]

|  I've decided to step back into the role of releasing systems and am
| trying to catch up to the outstanding changes.

I very much welcome your stepping back into the role of releasing the
system.

| I tried maintaining silver but I was the only one making changes.

Going back to last semester discussion, you're the only one doing the
commit to Silver, because it appeared to me that:
  (1) the system was set up in a way that you're the only one to
      effectively commit to silver, e.g. any commit to SF SVN
      reposiotyr is effectively "lost" from your perspective.

  (2) you wanted to take over silver, which I was originally maintaining.

| Plus the additional copies of Axiom were causing rising server costs.
| If it depends on my effort silver is dead. I only have enough time
| available to do Gold and do my own axiom-related work. I certainly
| don't have time to maintain silver. Since advocacy is volunteering
| you're welcome to create and maintain a silver version that is a
| test version for gold changes.

So, we are again back to what things were in April-September 2006?
This is an important question I need a clear answer for.

As I already pointed out, we should encourage people to commit
themselves their patches to Silver.  That reduces the load on the
maintainer.

\start
Date: Tue, 27 Feb 2007 00:59:39 -0600 (CST)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: next release

On Tue, 27 Feb 2007 Tim Daly wrote:

| > arrgh. I did it again :-(
|
| funny. :-)

Well, being the perpetrator I feel differently :-( :-/

\start
Date: Tue, 27 Feb 2007 12:34:05 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: mapleok results

Here are results of my analysis of several integrals from mapleok
before and after applying arc tangent patch.  

I had examined a few other integral, but did not record my conclusion.
In general for integrals missing from (rather short) list below I 
make no statement.  To conclude that we get an integral wrong I
was typically satisfied with results of numerical integration. To
conclude that we got integral OK I looked if jump discontinuities are
present (absence of jump discontinuities means we got the integral
correct).  I did some sanity checking for other problems, but
besically I trusted that up to jump discontinuities we get them
correct.

integrate(z/(2-cos(z^2))^2, z=0..2, "noPole")
was wrong
is wrong

in1012a:=integrate(log(abs(z^3-1))/(1+z)^2, z= 0..%plusInfinity,"noPole")
wrong

in1084a:=integrate(atan(sin(z))+atan(1/sin(z)), z= 0..1,"noPole")
wrong

in1118:=integrate(acot(z), z= 0..1/2*I)
was wrong
is OK

in1149:=integrate(imag(z)*z^(1/6), z= -%i..%i)
wrong

in1167a:=integrate((z^2)^(1/6), z= -3..-1,"noPole")
wrong

in1183a:=integrate(csc(z), z= 1-I..1+I,"noPole")
too complicated

in1186a:=integrate((z^2+z)^(1/2)/(1+z^2)^2, z= 0..1,"noPole")
was OK
is wrong

in1190a:=integrate(sin(z)^2*tan(z)^(1/2), z=0..1, "noPole")
was wrong
is wrong
too complicated answer

in1191a:=integrate(sin(z)^2/tan(z)^(1/2), z= 0..1,"noPole")
was wrong
is wrong

in1207a:=integrate(sin(z)*cos(z)*tan(z)^(1/2), z= 0..1, "noPole")
was wrong
is OK

in1214a:=integrate(-sin(z)*tan(z)*csc(z-1), z= 0..1, "noPole")
wrong (is divergent)

in1217a:=integrate(sin(z)*sec(z)*tan(z)^(1/2), z= 0..1,"noPole")
was wrong
is OK

in1218a:=integrate(sin(z)*sec(z)/tan(z)^(1/2), z= 0..1,"noPole")
was wrong
is OK

in15ab:=integrate(log(sqrt(z)+z^5), z=0..a,"noPole")
was wrong
is OK

in1228a:=integrate(sin(z)*csc(z)*tan(z)^(1/2), z= 0..1,"noPole")
was wrong
is OK

in1248a:=integrate(sin(z)*csc(z)*tan(z)^(1/2), z= 0..1,"noPole")
duplicate

in1261a:=integrate(1/(sin(z)+cos(2*z)), z= -1..1,"noPole")
wrong (divergent)

in1376a:=integrate(z*acoth(z^(1/2)), z= 0..1,"noPole")
ignored imaginary part

in143a:=integrate(sqrt(1+z)/(1+z^2), z= 0..1,"noPole")
was wrong
is OK

in1933a:=integrate(atan(z)/z/(z*(1+z))^(1/2), z= 0..1,"noPole")
was wrong
is OK

in202a:=integrate(acsc(z), z= 0..1/2,"noPole")
ignored imaginary part
real part was wrong

in2053a:=integrate(atan(2*z-1), z= 0..infinity,"noPole")
was wrong
is OK

integrate(atan(2*z-1), z= 0..%plusInfinity,"noPole")
was wrong
is OK

in2201a:=integrate(acoth(z)+%pi-asec(z-1), z= 0..1,"noPole")
ignored imaginary part
????

in249a:=integrate((sin(z)/(cos(z)-1))^(1/3), z= 0..%pi,"noPole")
ignored imaginary part
????

\start
Date: 27 Feb 2007 16:44:57 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Problem compiling wh-sandbox

Dear Waldek,

It seems I've got a problem compiling version 441 of wh-sandbox.

* gcl is not insatlled on my machine

* configure doesn't seem to do anything unusual

* make seems to get into an infinite loop starting with

if test "." != "."; then \
   cp -r ./gcl .; \
fi; cd gcl; \
./configure --prefix=/local/scratch/wh-sandbox/build/i686-pc-linux --enable-statsysbfd --disable-dynsysbfd --enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-tkconfig --disable-x --disable-xgcl && \
        make && make install
/bin/sh: line 0: cd: gcl: No such file or directory

\start
Date: Tue, 27 Feb 2007 10:51:59 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: Problem compiling wh-sandbox
Cc: Waldek Hebisch

Marin,

On February 27, 2007 10:45 AM you wrote:
> 
> It seems I've got a problem compiling version 441 of wh-sandbox.
> 
> * gcl is not insatlled on my machine
> ... 

As far as I know wh-sandbox requires that both gcl and noweb be
pre-installed *before* building Axiom.

As far as I am concerned, that is a good thing. gcl and noweb
should not be part of the Axiom distribution.

\start
Date: Tue, 27 Feb 2007 15:25:29 -0500
From: Cliff Yapp
To: Martin Rubey
Subject: Re: Problem compiling wh-sandbox
Cc: Waldek Hebisch

Martin,

I hit the same thing and worked around it by copying the gcl tree over 
from build-improvements.

Cheers,
CY

Martin Rubey wrote:
> Dear Waldek,
> 
> It seems I've got a problem compiling version 441 of wh-sandbox.
> 
> * gcl is not insatlled on my machine
> 
> * configure doesn't seem to do anything unusual
> 
> * make seems to get into an infinite loop starting with
> 
> if test "." != "."; then \
>    cp -r ./gcl .; \
> fi; cd gcl; \
> ./configure --prefix=/local/scratch/wh-sandbox/build/i686-pc-linux --enable-statsysbfd --disable-dynsysbfd --enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-tkconfig --disable-x --disable-xgcl && \
>         make && make install
> /bin/sh: line 0: cd: gcl: No such file or directory

\start
Date: 27 Feb 2007 16:51:30 -0600
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Problem compiling wh-sandbox
Cc: Waldek Hebisch

Cliff Yapp writes:

| Martin,
| 
| I hit the same thing and worked around it by copying the gcl tree over
| from build-improvements.
| 
| Cheers,
| CY
| 
| Martin Rubey wrote:
| > Dear Waldek,
| > It seems I've got a problem compiling version 441 of wh-sandbox.
| > * gcl is not insatlled on my machine
| > * configure doesn't seem to do anything unusual
| > * make seems to get into an infinite loop starting with
| > if test "." != "."; then \
| >    cp -r ./gcl .; \
| > fi; cd gcl; \
| > ./configure --prefix=/local/scratch/wh-sandbox/build/i686-pc-linux --enable-statsysbfd --disable-dynsysbfd --enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-tkconfig --disable-x --disable-xgcl && \
| >         make && make install
| > /bin/sh: line 0: cd: gcl: No such file or directory

I believe Waldek said you must have GCL installed if you want to use
wh-sandbox.  If that recollection is accurate, then I think he might
want to enforce that at configuration time,

\start
Date: Tue, 27 Feb 2007 18:40:49 -0500
From: Bill Page
To: Cliff Yapp
Subject: Re: Problem compiling wh-sandbox
Cc: Waldek Hebisch

Quoting C Y:
>
> I hit the same thing and worked around it by copying the gcl tree over
> from build-improvements.
>
> Cheers,
> CY
>
> Martin Rubey wrote:
>>
>> It seems I've got a problem compiling version 441 of wh-sandbox.
>>
>> * gcl is not insatlled on my machine
>>

It may not be obvious but you do not need to checkout the complete
build-improvements branch in order to get gcl and noweb. The following
svn commands are sufficient:

   svn co
https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements/gcl

   svn co
https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements/noweb

To build gcl just the default build would be sufficient:

   $ cd ~/gcl
   $ ./configure
   $ make
   $ make install

( by default installs in /usr/local )

But if you want optimize GCL just for building Axiom you can use:

   $ ./configure --prefix=... --disable-tkconfig --disable-x --disable-xgcl

where ... is where you want to install gcl and '.../bin' must in the PATH

   $ export PATH=.../bin:$PATH

To install noweb you must edit the Makefile by hand:

   $ cd ~/noweb/src

or apply the following patch to install noweb in /usr/local:

-------- noweb.patch ----------
   $ diff -au Makefile.orig Makefile
--- Makefile.orig       2007-02-27 17:10:46.000000000 -0600
+++ Makefile    2007-02-27 17:17:12.000000000 -0600
@@ -6,9 +6,9 @@
  CFLAGS=
  # If you have Icon, you should use the Icon versions of the noweb pipeline.
  # Set LIBSRC=icon
-LIBSRC=awk
+LIBSRC=icon
  # If you have no Icon compiler, but do have icont, make ICONC=icont
-ICONC=iconc
+ICONC=icont
  ICONT=icont

  # BIN is where the commands (notangle, noweave, nountangle, noroots) land
@@ -18,9 +18,9 @@
  # MAN7EXT is the extension for the nowebstyle man page (usually 7)
  # TEXINPUTS is the directory for TeX macro files
  # ELISP is the directory for emacs lisp files, or /dev/null not to install
-BIN=/usr/local/noweb
-LIB=/usr/local/noweb/lib
-MAN=/usr/local/noweb/man
+BIN=/usr/local/bin
+LIB=/usr/local/lib
+MAN=/usr/local/man
  MANEXT=1
  MAN7EXT=7
  TEXINPUTS=/usr/local/tex/inputs

---------

   $ patch < noweb.patch
   $ make
   $ make install

Note:

This patch uses the 'icon' option instead of 'awk'. Using icon results in
a significantly faster version of noweb. You can download icon from

   http://www.cs.arizona.edu/icon

\start
Date: Wed, 28 Feb 2007 19:32:25 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Problem compiling wh-sandbox
Cc: Waldek Hebisch

> Dear Waldek,
> 
> It seems I've got a problem compiling version 441 of wh-sandbox.
> 
> * gcl is not insatlled on my machine
> 
> * configure doesn't seem to do anything unusual
> 
> * make seems to get into an infinite loop starting with
> 
> if test "." != "."; then \
>    cp -r ./gcl .; \
> fi; cd gcl; \
> ./configure --prefix=/local/scratch/wh-sandbox/build/i686-pc-linux --enable-statsysbfd --disable-dynsysbfd --enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-tkconfig --disable-x --disable-xgcl && \
>         make && make install
> /bin/sh: line 0: cd: gcl: No such file or directory
> 


In general to compile wh-sandbox you need to do one of the following:

-- have gcl pre-installed on your machine (note that if you have gcl in
   a private directory you can tell configure where to find it)
-- copy gcl tree from build-improvements.

I will put this information into README.wh.  Also, for out of source
build the build just stopped -- I will investigate how to detect missing
gcl tree and give sensible error message (intead of the loop you were
seeing).

-- 
                              Waldek Hebisch
Waldek Hebisch 



\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
