\start
Date: Mon, 09 May 2011 10:53:10 -0600
From: Dan Mahoney
To: list
Subject: Attempting to make axiom on MacOsx 10.6 with Case-Insensitve FIleSystem
Cc: Marian Anghel

Morning,
  I am attempting to make axiom on a MacOs HFS that I believe was
formated as case-insensitive.
The make always fails with the following error.
cp: ...../axiom/mnt/macosxppc/doc/spadhelp/ASP12.help and 
...../axiom/mnt/macosxppc/doc/spadhelp/Asp12.help are identical

\start
Date: Wed, 11 May 2011 14:37:40 -0400
From: Tim Daly
To: Dan Mahoney
Subject: Re: Attempting to make axiom on MacOsx 10.6 with Case-Insensitve FIleSystem
Cc: Marian Anghel

I do not see ASP12.help, only Asp12.help.
The only reference to that name is in books/bookvol10.3.pamphlet

Axiom, in general, has had all of the files except the
help files moved to lowercase only names. The help files
mirror the actual names of the domains so they need 
mixed cases.

Can you give me a traceback of where this might happen?

Tim Daly


On Mon, 2011-05-09 at 10:53 -0600, Dan Mahoney wrote:
> Morning,
>   I am attempting to make axiom on a MacOs HFS that I believe was
> formated as case-insensitive.
> The make always fails with the following error.
> cp: ...../axiom/mnt/macosxppc/doc/spadhelp/ASP12.help and 
> ...../axiom/mnt/macosxppc/doc/spadhelp/Asp12.help are identical

\start
Date: Wed, 11 May 2011 14:39:55 -0400
From: Tim Daly
To: Dan Mahoney
Subject: Re: Attempting to make axiom on MacOsx 10.6 with Case-Insensitve FIleSystem
Cc: Marian Anghel

When Axiom starts it lists a version number which is a
(month year) form. What version are you using?

Axiom has been case-insensitive since around 2008.

On Mon, 2011-05-09 at 10:53 -0600, Dan Mahoney wrote:
> Morning,
>   I am attempting to make axiom on a MacOs HFS that I believe was
> formated as case-insensitive.
> The make always fails with the following error.
> cp: ...../axiom/mnt/macosxppc/doc/spadhelp/ASP12.help and 
> ...../axiom/mnt/macosxppc/doc/spadhelp/Asp12.help are identical

\start
Date: Sat, 14 May 2011 12:23:41 -0400
From: Tim Daly
To: list
Subject: Re: [sage-devel] Re: LaTeX code to Sage expression?

Since TeX is turing complete and allows macros,
would it be possible to create a set of macros
that are not ambiguous? For instance, an integral
macro that specifies the limits and differential
variable?

\integrate{0}{\infty}{r}{sin(\theta)}

In this case it seems to me that the latex macros
would closely approximate the actual linear input
to the CAS.

On Sat, 2011-05-14 at 08:25 -0700, rjf wrote:
> Look at
> http://moralfiber.org/eylon/berkeley/cs282/
> to see a paper,
> Parsing Mathematics Typeset in TeX
> that  successfully parsed many many formulas
> from Gradshteyn and Rhyzik, a table of integrals.
> 
> The result was Lisp, which presumably could be Maxima.
> If you have a result in Maxima, presumably Sage can make sense of it.
> 
> Or the same design can directly produce whatever Sage-speak you had in
> mind.

\start
Date: Sat, 14 May 2011 13:49:39 -0400
From: Eugene Surowitz
To: Tim Daly
Subject: Index entries for "eq?"

The file "book-index.xhtml" contains 3 entries for "eq?",
all for "Section 9.18 EqTable".
There are in fact three text statements in in that section
containing the string "eg?".

I generally believe that an index would contain only one entry
per page for any given word.  Does the index generation mechanism
for Axiom inteneded to function that way?
Or does it tolerate duplicates per page/section?

\start
Date: Sat, 14 May 2011 15:05:56 -0400
From: Eugene Surowitz
To: list
Subject: Re: Index entries for "eq?"

Oops: intended

On 5/14/2011 1:49 PM, Eugene Surowitz wrote:
> Tim:
>
> The file "book-index.xhtml" contains 3 entries for "eq?",
> all for "Section 9.18 EqTable".
> There are in fact three text statements in in that section
> containing the string "eg?".
>
> I generally believe that an index would contain only one entry
> per page for any given word. Does the index generation mechanism
> for Axiom inteneded to function that way?
> Or does it tolerate duplicates per page/section?

\start
Date: Sun, 15 May 2011 17:43:52 -0400
From: Tim Daly
To: Eugene Surowitz
Subject: Re: Index entries for "eq?"

The file book-index.xhtml was a contributed document.
Axiom does nothing but copy it at build time.

On Sat, 2011-05-14 at 13:49 -0400, Eugene Surowitz wrote:
> Tim:
> 
> The file "book-index.xhtml" contains 3 entries for "eq?",
> all for "Section 9.18 EqTable".
> There are in fact three text statements in in that section
> containing the string "eg?".
> 
> I generally believe that an index would contain only one entry
> per page for any given word.  Does the index generation mechanism
> for Axiom inteneded to function that way?
> Or does it tolerate duplicates per page/section?

\start
Date: Mon, 16 May 2011 14:11:27 -0400
From: Tim Daly
To: David Lichteblau
Subject: Re: [Sbcl-devel] Windows port future ... Git?

On Mon, 2011-05-16 at 18:28 +0200, David Lichteblau wrote:
> Quoting Daniel Herring (Daniel Herring):
> > David Lichteblau wrote:
> > > Regarding git use I would like to point out that git is really cool (and
> > > I'm obviously using it), but being able to easily merge stuff between
> > > branches does not make it easy to merge the result into an upstream
> > > project.
> > >
> > > A straight "let's merge this branch" commit is not an option for the
> > > branches in question -- and would not do justice to their complexity and
> > > the amazing work Dmitry and Anton have put into them.
> >
> > I may be missing the point (and you're certainly doing a lot more than I
> > ever have) but I disagree with your statement.
> 
> It seems clear to me from Nikodemus' announcement that SBCL is being
> moved to git.  I was not actively involved with SBCL development at the
> time when git was being discussed, but I personally appreciate git's
> features and welcome this development.
> 
> Consequently, further discussion and exposition of git's virtues would
> be redundant, and I'd like to keep my response to these points as brief
> as possible.
> 
> However, every project using git has its own set of rules governing the
> appropriate steps for submitting and checking in patches, and some main
> guidelines are common to most projects.  The point I was making is
> primarily about those procedures in general, and the goals for my
> current work in particular.
> 
> > With Git, Dmitry and Anton could easily have their own "windows branch" of
> > SBCL in the official SBCL source tree.  That could happen today.  Then
> > this branch can be merged/retired as you and others refactor the important
> > pieces into the master branch (currently the only thing in CVS).
> 
> Git's advantage is that collaborative work with multiple distinct
> repositories works very well, without having highly experimental work in
> the main repository.  The existing Windows repositories are well-known
> and very visible.
> 
> > With the current setup, we have a handful of semi-official repositories,
> > people didn't even know about your work, ...  Tracking these forks and
> > merges is important.
> 
> The term "merge" has a double meaning here.  I want to _merge_ the
> windows changes, but we cannot do that through a _merge commit_ in git:
> 
> The work Dmitry and Anton have done is outstanding and highly
> appreciated, yet it comes with a long history.  I need to re-linearize
> it, split it, remove superseded experiments, extract proposed
> enhancements that are not meant to be merged yet, and extensively test
> each part.
> 
> None of that is in any way special; it is typical patch integration
> work.  What is perhaps special is that the changes are more extensive
> than many other contributions being submitted to SBCL.
> 
> They were not built^W written in one day, and I think it is appropriate for
> SBCL as a project to take a little time to review and digest them, too.
> 
> d.

The same issues arose when the Axiom project moved from SVN
to git. Under SVN we created user-related branches so various
ideas could be explored. Unfortunately these branches were
not kept to the single idea but became essentially alternative
implementations with many "features". That was clearly a project
management failure on my part.

At one point in the project we attempted to merge the branches
back into the main line. Unfortunately the development on these
branches had gotten much too complex as many ideas were 
being explored in each branch. 

A many-month effort was made to cherry pick changes that could be
merged. But cherry picking changes, while technically possible,
led to social problems as the branch maintainers wanted every
change accepted. This was not possible among the several branches,
of course. This was especially hard as there was no documentation
about the changes, making conflicts impossible to resolve.

What the "great merge" exposed was that the branch maintainers
had goals that conflicted with the stated project goals. Working
in their own branch allowed them to pursue these conflicting
goals quietly. Ultimately this led to two forks.

The lesson to learn is that branches should be based on single ideas
(e.g. swap NIL and T semantics), not on people (e.g. Bob's branch).

Another lesson: code should be merged or rejected very quickly (e.g
less than 2 weeks) otherwise the branch owner gets too attached
to their code rather than the idea so rejecting the idea is taken,
unintentionally, as a rejection of the person. Even great developers
(which Axiom had) generate ideas that get rejected.

The third lesson is that it should be up to the branch owner
to provide "diff -Naur" patches that can be smoothly applied
(actually "git diff" patches). After all, the branch owner knows the
branch code. These patches should all relate to a single feature. 

The trunk maintainer should not try to understand-and-cherry-pick.
That way lies madness, anger, and forks.

A fourth lesson is that there should be no "public" branches anymore.
These should all be local. git allows branches to be pushed and pulled
among subsets of developers without public branches.

Move the trunk now. Let the branches provide focused diff-Naur patches.

Moving from SVN to git is a great idea. I highly recommend it.

\start
Date: Mon, 16 May 2011 17:07:20 -0400
From: Tim Daly
To: Eugene Surowitz, Arthur Ralfs
Subject: Re: Index entries for "eq?"

Since the xhtml is all static text it should be a simple
task to just read it once and eliminate any duplicates.
Just make the changes you want, send me a diff-Naur file,
and I'll apply them.
 
The author is Arthur Ralfs.

Tim Daly

On Mon, 2011-05-16 at 16:38 -0400, Eugene Surowitz wrote:
> OK: so we have an unmaintained, probably machine generated,
> and apparently incomplete but otherwise useful piece of the documentation.
> 
> Any memory of who or how it was generated generated?
> 
> I had to create something similar for another project and
> had a degassing step in there which appears to have omitted here.
> If memory serves correctly degassing can actually be done with
> simple unix commands only.
> 
> But that would bypass the incompleteness issue.
> 
> The C++ thing that I have in specialized form might be
> generalized to create a component for Axiom that would
> work from the entire documentation source since the pamphlets
> are really now TeX/Latex which was its targeted input.
> 
> Eugene J. Surowitz
> 
> On 5/15/2011 5:43 PM, daly wrote:
> > The file book-index.xhtml was a contributed document.
> > Axiom does nothing but copy it at build time.
> >
> > Tim
> >
> > On Sat, 2011-05-14 at 13:49 -0400, Eugene Surowitz wrote:
> >> Tim:
> >>
> >> The file "book-index.xhtml" contains 3 entries for "eq?",
> >> all for "Section 9.18 EqTable".
> >> There are in fact three text statements in in that section
> >> containing the string "eg?".
> >>
> >> I generally believe that an index would contain only one entry
> >> per page for any given word.  Does the index generation mechanism
> >> for Axiom inteneded to function that way?
> >> Or does it tolerate duplicates per page/section?

\start
Date: Mon, 16 May 2011 17:13:46 -0400
From: Eugene Surowitz
To: Tim Daly
Subject: Re: Index entries for "eq?"

Will do very shortly.

Eugene J. Surowitz

On 5/16/2011 5:07 PM, daly wrote:
> Since the xhtml is all static text it should be a simple
> task to just read it once and eliminate any duplicates.
> Just make the changes you want, send me a diff-Naur file,
> and I'll apply them.
>
> The author is Arthur Ralfs.
>
> Tim Daly
>
> On Mon, 2011-05-16 at 16:38 -0400, Eugene Surowitz wrote:
>> OK: so we have an unmaintained, probably machine generated,
>> and apparently incomplete but otherwise useful piece of the documentation.
>>
>> Any memory of who or how it was generated generated?
>>
>> I had to create something similar for another project and
>> had a degassing step in there which appears to have omitted here.
>> If memory serves correctly degassing can actually be done with
>> simple unix commands only.
>>
>> But that would bypass the incompleteness issue.
>>
>> The C++ thing that I have in specialized form might be
>> generalized to create a component for Axiom that would
>> work from the entire documentation source since the pamphlets
>> are really now TeX/Latex which was its targeted input.
>>
>> Eugene J. Surowitz
>>
>> On 5/15/2011 5:43 PM, daly wrote:
>>> The file book-index.xhtml was a contributed document.
>>> Axiom does nothing but copy it at build time.
>>>
>>> Tim
>>>
>>> On Sat, 2011-05-14 at 13:49 -0400, Eugene Surowitz wrote:
>>>> Tim:
>>>>
>>>> The file "book-index.xhtml" contains 3 entries for "eq?",
>>>> all for "Section 9.18 EqTable".
>>>> There are in fact three text statements in in that section
>>>> containing the string "eg?".
>>>>
>>>> I generally believe that an index would contain only one entry
>>>> per page for any given word.  Does the index generation mechanism
>>>> for Axiom inteneded to function that way?
>>>> Or does it tolerate duplicates per page/section?

\start
Date: Mon, 16 May 2011 16:38:31 -0400
From: Eugene Surowitz
To: Tim Daly
Subject: Re: Index entries for "eq?"

OK: so we have an unmaintained, probably machine generated,
and apparently incomplete but otherwise useful piece of the documentation.

Any memory of who or how it was generated generated?

I had to create something similar for another project and
had a degassing step in there which appears to have omitted here.
If memory serves correctly degassing can actually be done with
simple unix commands only.

But that would bypass the incompleteness issue.

The C++ thing that I have in specialized form might be
generalized to create a component for Axiom that would
work from the entire documentation source since the pamphlets
are really now TeX/Latex which was its targeted input.

Eugene J. Surowitz

On 5/15/2011 5:43 PM, daly wrote:
> The file book-index.xhtml was a contributed document.
> Axiom does nothing but copy it at build time.
>
> Tim
>
> On Sat, 2011-05-14 at 13:49 -0400, Eugene Surowitz wrote:
>> Tim:
>>
>> The file "book-index.xhtml" contains 3 entries for "eq?",
>> all for "Section 9.18 EqTable".
>> There are in fact three text statements in in that section
>> containing the string "eg?".
>>
>> I generally believe that an index would contain only one entry
>> per page for any given word.  Does the index generation mechanism
>> for Axiom inteneded to function that way?
>> Or does it tolerate duplicates per page/section?

\start
Date: Mon, 16 May 2011 15:35:21 -0700
From: Arthur Ralfs
To: list
Subject: Re: Index entries for "eq?"

I did the xhtml-mthml version of the book several years ago from the
latex/tex using regular expressions in emacs.  It was quite laborious.
Because a lot of the latex is hand written and the tex output from axiom
has been hand modified a lot of the conversion had to be done by hand.
I always thought it would be nice if it could be generated automatically
when building axiom but I think to do so would require regularizing the
latex in the book pamphlets.  Maybe then requiring any future additions
to the book to be run through a validator.

On 05/16/2011 01:38 PM, Eugene Surowitz wrote:
> OK: so we have an unmaintained, probably machine generated,
> and apparently incomplete but otherwise useful piece of the documentation.
>
> Any memory of who or how it was generated generated?
>
> I had to create something similar for another project and
> had a degassing step in there which appears to have omitted here.
> If memory serves correctly degassing can actually be done with
> simple unix commands only.
>
> But that would bypass the incompleteness issue.
>
> The C++ thing that I have in specialized form might be
> generalized to create a component for Axiom that would
> work from the entire documentation source since the pamphlets
> are really now TeX/Latex which was its targeted input.
>
> Eugene J. Surowitz
>
> On 5/15/2011 5:43 PM, daly wrote:
>> The file book-index.xhtml was a contributed document.
>> Axiom does nothing but copy it at build time.
>>
>> Tim
>>
>> On Sat, 2011-05-14 at 13:49 -0400, Eugene Surowitz wrote:
>>> Tim:
>>>
>>> The file "book-index.xhtml" contains 3 entries for "eq?",
>>> all for "Section 9.18 EqTable".
>>> There are in fact three text statements in in that section
>>> containing the string "eg?".
>>>
>>> I generally believe that an index would contain only one entry
>>> per page for any given word. Does the index generation mechanism
>>> for Axiom inteneded to function that way?
>>> Or does it tolerate duplicates per page/section?

\start
Date: Mon, 16 May 2011 19:46:23 -0400
From: Tim Daly
To: Arthur Ralfs
Subject: Re: Index entries for "eq?"

I have been contemplating writing special case latex macros
that supply unambiguous parsings of the input expressions, such as
\integrate{0}{\infty}{\sin{x}}{x}
which are essentially just the Axiom input parameters
written in custom latex. This would allow direct generation
of both the Axiom input and the .dvi output.

On Mon, 2011-05-16 at 15:35 -0700, Arthur Ralfs wrote:
> Eugene,
> 
> I did the xhtml-mthml version of the book several years ago from the
> latex/tex using regular expressions in emacs.  It was quite laborious.
> Because a lot of the latex is hand written and the tex output from axiom
> has been hand modified a lot of the conversion had to be done by hand.
> I always thought it would be nice if it could be generated automatically
> when building axiom but I think to do so would require regularizing the
> latex in the book pamphlets.  Maybe then requiring any future additions
> to the book to be run through a validator.
> 
> Arthur
> 
> On 05/16/2011 01:38 PM, Eugene Surowitz wrote:
> > OK: so we have an unmaintained, probably machine generated,
> > and apparently incomplete but otherwise useful piece of the documentation.
> >
> > Any memory of who or how it was generated generated?
> >
> > I had to create something similar for another project and
> > had a degassing step in there which appears to have omitted here.
> > If memory serves correctly degassing can actually be done with
> > simple unix commands only.
> >
> > But that would bypass the incompleteness issue.
> >
> > The C++ thing that I have in specialized form might be
> > generalized to create a component for Axiom that would
> > work from the entire documentation source since the pamphlets
> > are really now TeX/Latex which was its targeted input.
> >
> > Eugene J. Surowitz
> >
> > On 5/15/2011 5:43 PM, daly wrote:
> >> The file book-index.xhtml was a contributed document.
> >> Axiom does nothing but copy it at build time.
> >>
> >> Tim
> >>
> >> On Sat, 2011-05-14 at 13:49 -0400, Eugene Surowitz wrote:
> >>> Tim:
> >>>
> >>> The file "book-index.xhtml" contains 3 entries for "eq?",
> >>> all for "Section 9.18 EqTable".
> >>> There are in fact three text statements in in that section
> >>> containing the string "eg?".
> >>>
> >>> I generally believe that an index would contain only one entry
> >>> per page for any given word. Does the index generation mechanism
> >>> for Axiom inteneded to function that way?
> >>> Or does it tolerate duplicates per page/section?

\start
Date: Tue, 17 May 2011 13:53:05 -0400
From: Eugene Surowitz
To: Tim Daly
Subject: Re: Index entries for "eq?"

The thing I did with a tex manuscript got off the ground
by turning something like
\integrate{0}{\infty}{\sin{x}}{x}
into
\integrate 0  \infty  \sin x   x
which consists of primitive exhaustive vocabulary elements.
The specalized tex/latex control sequences that you
are considering would just join everything else in the processing.

On 5/16/2011 7:46 PM, daly wrote:
> I have been contemplating writing special case latex macros
> that supply unambiguous parsings of the input expressions,
> such as
> \integrate{0}{\infty}{\sin{x}}{x}
> which are essentially just the Axiom input parameters
> written in custom latex. This would allow direct generation
> of both the Axiom input and the .dvi output.
>
> Tim
>
> On Mon, 2011-05-16 at 15:35 -0700, Arthur Ralfs wrote:
>> Eugene,
>>
>> I did the xhtml-mthml version of the book several years ago from the
>> latex/tex using regular expressions in emacs.  It was quite laborious.
>> Because a lot of the latex is hand written and the tex output from axiom
>> has been hand modified a lot of the conversion had to be done by hand.
>> I always thought it would be nice if it could be generated automatically
>> when building axiom but I think to do so would require regularizing the
>> latex in the book pamphlets.  Maybe then requiring any future additions
>> to the book to be run through a validator.
>>
>> Arthur
>>
>> On 05/16/2011 01:38 PM, Eugene Surowitz wrote:
>>> OK: so we have an unmaintained, probably machine generated,
>>> and apparently incomplete but otherwise useful piece of the documentation.
>>>
>>> Any memory of who or how it was generated generated?
>>>
>>> I had to create something similar for another project and
>>> had a degassing step in there which appears to have omitted here.
>>> If memory serves correctly degassing can actually be done with
>>> simple unix commands only.
>>>
>>> But that would bypass the incompleteness issue.
>>>
>>> The C++ thing that I have in specialized form might be
>>> generalized to create a component for Axiom that would
>>> work from the entire documentation source since the pamphlets
>>> are really now TeX/Latex which was its targeted input.
>>>
>>> Eugene J. Surowitz
>>>
>>> On 5/15/2011 5:43 PM, daly wrote:
>>>> The file book-index.xhtml was a contributed document.
>>>> Axiom does nothing but copy it at build time.
>>>>
>>>> Tim
>>>>
>>>> On Sat, 2011-05-14 at 13:49 -0400, Eugene Surowitz wrote:
>>>>> Tim:
>>>>>
>>>>> The file "book-index.xhtml" contains 3 entries for "eq?",
>>>>> all for "Section 9.18 EqTable".
>>>>> There are in fact three text statements in in that section
>>>>> containing the string "eg?".
>>>>>
>>>>> I generally believe that an index would contain only one entry
>>>>> per page for any given word. Does the index generation mechanism
>>>>> for Axiom inteneded to function that way?
>>>>> Or does it tolerate duplicates per page/section?

\start
Date: Sun, 22 May 2011 19:39:36 -0400
From: Tim Daly
To: Johannes Grabmeier
Subject: )d op foo

Axiom now displays examples of use as well as type information:

)d op pop!

There are 4 exposed functions called pop!:
  [1] ArrayStack D1 -> D1 from ArrayStack D1 if D1 has SETCAT
  [2] Dequeue D1 -> D1 from Dequeue D1 if D1 has SETCAT
  [3] D -> D1 from D if D has SKAGG D1 and D1 has TYPE
  [4] Stack D1 -> D1 from Stack D1 if D1 has SETCAT

Examples of pop! from ArrayStack

a:ArrayStack INT:= arrayStack [1,2,3,4,5]
pop! a
a

Examples of pop! from Dequeue

a:Dequeue INT: dequeue [1,2,3,4,5]
pop! a
a

Examples of pop! from StackAggregate

a:Stack INT:= stack [1,2,3,4,5]
pop! a
a

Examples of pop! from Stack

a:Stack INT:= stack [1,2,3,4,5]
pop! a
a

These are part of the ++ comments for the operations with a
special ++X prefix. For instance, in ArrayStack, the pop! operation
comments are:

  pop_! : % -> S
    ++
    ++X a:ArrayStack INT:= arrayStack [1,2,3,4,5]
    ++X pop! a
    ++X a

The )d op parsing routine looks for these special ++X examples
and includes them in the output.

This is a simple change to the display routine since the ++
comments are stored in the database. All the author has to
do is prefix example lines in the comment with ++X

I think this is a useful documentation feature. I would hope
that the other systems would pick up this change. We can all
benefit from the additional documentation.

\start
Date: Sat, 21 May 2011 06:15:30 -0700 (PDT)
From: Doug Telford
To: list
Subject: Axiom Fedora Mar 2011 bin - Problem report

--0-1069508861-1305983730=:65013

At your website, clicking on "Filing a bug report" did not work.

Problem:
Tutorial section 1.1.5 Legendre polynomial appears to have errors:

(9) -> p(0)==1
=
=
 Type: Void
(10) -> p(1)==x
=
=
 Type: Void
(11) -> p(n) == ((2*n-1)*x*p(n-1) - (n-1) * p(n-2))/n
=
=
 Type: Void
(12) -> p(10)
 Compiling function p with type Integer -> Polynomial Fraction=20
 Integer=20
 Compiling function p as a recurrence relation.
(12) -> p(10)

 >> System error:
 The function |*1;p;1;frame0| is undefined.

(12) -> coeff(p(90),x,90)

 >> System error:
 The function |*1;p;1;frame0| is undefined.

Regards,
Doug

\start
Date: Tue, 24 May 2011 14:49:49 -0400
From: Tim Daly
To: Doug Telford
Subject: Axiom Fedora Mar 2011 bin - Problem report

Sorry for the delay and thanks for the bug report.

It took a while to reproduce as I had to create the Fedora machine.
I am rebuilding the binary at the moment to see if it still exists.

The code works on the latest version of Axiom which will be 
released by the end of this month. 

In any case, I will let you know what I find.

\start
Date: Tue, 24 May 2011 17:38:06 -0400
From: Tim Daly
To: Doug Telford
Subject: Re: Axiom Fedora Mar 2011 bin - Problem report

I have fixed this problem and built a new fedora image at
http://axiom-developer.org/axiom-website/downloads/axiom-fedora-mar2011-bin.tgz

I've also added this example as a regression test to the
latest test suite.

Thanks for the bug report.

On Sat, 2011-05-21 at 06:15 -0700, T.D. Telford wrote:
> At your website, clicking on "Filing a bug report" did not work.
> 
> Problem:
> Tutorial section 1.1.5 Legendre polynomial appears to have errors:
> 
> (9) -> p(0)==1
> 
> Type: Void
> (10) -> p(1)==x
> 
> Type: Void
> (11) -> p(n) == ((2*n-1)*x*p(n-1) - (n-1) * p(n-2))/n
> 
> Type: Void
> (12) -> p(10)
>    Compiling function p with type Integer -> Polynomial Fraction 
>       Integer 
>    Compiling function p as a recurrence relation.
> (12) -> p(10)
>  
>    >> System error:
>    The function |*1;p;1;frame0| is undefined.
> 
> (12) -> coeff(p(90),x,90)
>  
>    >> System error:
>    The function |*1;p;1;frame0| is undefined.

\start
Date: Wed, 25 May 2011 12:13:09 -0400
From: Tim Daly
To: Eugene Surowitz
Subject: eq? in book-index

Eugene,

Since I haven't heard from you I set out to address your
concern about eq? appearing multiple times on the same page.

I have looked at the book-index file and I think that Arthur's
original version is reasonable. The notion of a "page" in html
based documentation isn't clearly defined. The fact that some
of the references point to adjacent items is a non-issue since
the user would not notice that fact.

\start
Date: Wed, 25 May 2011 13:28:05 -0400
From: Tim Daly
To: Eugene Surowitz
Subject: bookvol5 index

> Rather I'm starting to look at something that has
> no index at all, that is, bookvol5.pamphlet.

Actually bookvol5 has a 175 page index.
But something I did broke the index generation function.
I'll look into it.

\start
Date: Wed, 25 May 2011 12:57:03 -0400
From: Eugene Surowitz
To: Arthur Ralfs
Subject: Fwd: Re: eq? in book-index

-------- Original Message --------

I've been busy writing a paper due tomorrow.

I agree with you that a "page"
is an ill defined notion in xml/html.
That the target page of the index page (not the index page itself)
has multiple nearby entries is no issue to me.

With the multiple references to the target page,
it is nice to be pointing near the particular reference.
But, since there no way, from the index entries,
to tell which is the most appropriate reference,
I don't much see need for more than one entry.

But that just my view and given that the current
index was essentially hand generated I don't
intend to go further in that direction for the moment.

Rather I'm starting to look at something that has
no index at all, that is, bookvol5.pamphlet.

On 5/25/2011 12:13 PM, daly wrote:
> Eugene,
>
> Since I haven't heard from you I set out to address your
> concern about eq? appearing multiple times on the same page.
>
> I have looked at the book-index file and I think that Arthur's
> original version is reasonable. The notion of a "page" in html
> based documentation isn't clearly defined. The fact that some
> of the references point to adjacent items is a non-issue since
> the user would not notice that fact.

\start
Date: Wed, 25 May 2011 14:00:24 -0400
From: Eugene Surowitz
To: Tim Daly
Subject: Re: bookvol5 index

OK; the version I had was blank.

Eugene J. Surowitz

On 5/25/2011 1:28 PM, daly wrote:
>> Rather I'm starting to look at something that has
>> no index at all, that is, bookvol5.pamphlet.
>
>
> Actually bookvol5 has a 175 page index.
> But something I did broke the index generation function.
> I'll look into it.

\start
Date: Wed, 25 May 2011 17:53:18 -0400
From: Tim Daly
To: Eugene Surowitz
Subject: Re: bookvol5 index

This problem is fixed. It will be part of the new release
scheduled for this week. Thanks.

On Wed, 2011-05-25 at 14:00 -0400, Eugene Surowitz wrote:
> OK; the version I had was blank.
> 
> Eugene J. Surowitz
> 
> On 5/25/2011 1:28 PM, daly wrote:
> >> Rather I'm starting to look at something that has
> >> no index at all, that is, bookvol5.pamphlet.
> >
> >
> > Actually bookvol5 has a 175 page index.
> > But something I did broke the index generation function.
> > I'll look into it.

\start
Date: Thu, 26 May 2011 05:47:11 -0400
From: Tim Daly
To: list
Subject: Axiom May 2011 release

The May 2011 release is complete.
The sourceforge, savannah, and github websites are up to date.
The axiom-developer.org website will be up to date shortly
with sources and binaries.

May 2011 Release

This release involved more work treeshaking of the compiler and
interpreter. Argument naming conventions were normalized to improve
the documentation and clarity.

Time was spent proofreading the books and reducing or eliminating
latex warnings. Missing index files were fixed and errors in the Jenks
book were fixed.

The website has been updated to make Arthur Ralf's book available
from every page. The website is being rewritten to be IPv6 enabled.

Doug Telford was added to the credits.

Book Volume 0 (Jenks book)
  proofread to chapter 1 (pdf page 86)
  replace "operator over" by "operate over"
  set textlength 400
  port changes to Arthur Ralfs HTML version

Book Volume 1 (Tutorial)
  proofread and copyedit
  set textlength 400
  update HTML image

Book Volume 2 
  set textlength 400

Book Volume 3
  set textlength 400

Book Volume 4
  set textlength 400

Book Volume 5 (Interpreter)
  add Doug Telford to credits
  set textlength 400
  treeshake interpreter

Book Volume 6
  set textlength 400

Book Volume 7 (Hyperdoc)
  set textlength 400

Book Volume 7.1 (Hyperdoc pages)
  set textlength 400
  update What's New Page
  ps/v71mar2011.eps
  ps/v71releasenotes.eps add release notes

Book Volume 8
  set textlength 400

Book Volume 9 (Compiler)
  normalize argument names to top level functions
  treeshake compiler

Book Volume 10
  set textlength 400

Book Volume 10.1
  set textlength 400

Book Volume 10.2 (Categories)
  set textlength 400

Book Volume 10.3 (Domains)
  set textlength 400

Book Volume 10.4 (Packages)
  set textlength 400

Book Volume 10.5 (Numerics)
  set textlength 400

Book Volume 11
  set textlength 400

Book Volume 12
  set textlength 400

Biblography
  add several references
  set textlength 400

readme
  add Doug Telford to credits

website
  set up IPv6 address range
  download.html add binaries
  bugreport.html add bug reporting instructions
 
  The website now has an online version of the Jenks book which is a 
  link to Arthur Ralf's HTML version. This has been updated with the
  proofreading changes for the latex version.

     *.html add online book link to Arthur Ralfs HTML version
     hyperdoc/axbook/ps/h-root.png port changes
     hyperdoc/axbook/section-0.1.xhtml, section-0.6.xhtml,
section-0.7.xhtml

Makefiles
  books/Makefile fix missing index
  books/Makefile set textlength 400

Testing
  Makefile add davis.input
  Makefile add erf.input
  Makefile bug report regression test
  davis.input
  erf.input add examples of erf integration
  telford.input bug report regression test


src/interp/
  define.lisp treeshake compiler
  parsing.lisp treeshake compiler
  vmlisp.lisp treeshake compiler

\start
Date: Thu, 26 May 2011 07:41:02 -0700
From: Arthur Ralfs
To: Eugene Surowitz
Subject: Re: Fwd: Re: eq? in book-index

On 05/25/2011 09:57 AM, Eugene Surowitz wrote:

> But that just my view and given that the current
> index was essentially hand generated I don't
> intend to go further in that direction for the moment.
>

IIRC the index was not generated by hand, rather there's markup, 
something like \index{eq} in the original TeX, from which the index was 
generated programmatically.

\start
Date: Thu, 26 May 2011 12:04:29 -0400
From: Eugene Surowitz
To: list
Subject: Re: eq? in book-index

Arthur:

I think these were the comments that gave me the
impression that much of the index effort was by hand.
The use of latex \index was what I expected.
Things are now clearer.

Thanx and cheers,
Eugene J. Surowitz

On 5/16/2011 6:35 PM, Arthur Ralfs wrote:
>
> Eugene,
>
> I did the xhtml-mthml version of the book several years ago from the
> latex/tex using regular expressions in emacs. It was quite laborious.
> Because a lot of the latex is hand written and the tex output from axiom
> has been hand modified a lot of the conversion had to be done by hand.
> I always thought it would be nice if it could be generated automatically
> when building axiom but I think to do so would require regularizing the
> latex in the book pamphlets. Maybe then requiring any future additions
> to the book to be run through a validator.
>
> Arthur
>
> On 05/16/2011 01:38 PM, Eugene Surowitz wrote:
>> OK: so we have an unmaintained, probably machine generated,
>> and apparently incomplete but otherwise useful piece of the documentation.
>>
>> Any memory of who or how it was generated generated?
>>
>> I had to create something similar for another project and
>> had a degassing step in there which appears to have omitted here.
>> If memory serves correctly degassing can actually be done with
>> simple unix commands only.
>>
>> But that would bypass the incompleteness issue.
>>
>> The C++ thing that I have in specialized form might be
>> generalized to create a component for Axiom that would
>> work from the entire documentation source since the pamphlets
>> are really now TeX/Latex which was its targeted input.
>>
>> Eugene J. Surowitz
>>
>> On 5/15/2011 5:43 PM, daly wrote:
>>> The file book-index.xhtml was a contributed document.
>>> Axiom does nothing but copy it at build time.
>>>
>>> Tim
>>>
>>> On Sat, 2011-05-14 at 13:49 -0400, Eugene Surowitz wrote:
>>>> Tim:
>>>>
>>>> The file "book-index.xhtml" contains 3 entries for "eq?",
>>>> all for "Section 9.18 EqTable".
>>>> There are in fact three text statements in in that section
>>>> containing the string "eg?".
>>>>
>>>> I generally believe that an index would contain only one entry
>>>> per page for any given word. Does the index generation mechanism
>>>> for Axiom inteneded to function that way?
>>>> Or does it tolerate duplicates per page/section?
