\start
Date: Fri, 01 Jan 2010 00:13:41 -0500
From: Tim Daly
To: list
Subject: Re: [sage-devel] Re: doctest failures due to rounding errors on Solaris.

Dr. David Kirkby wrote:
> rjf wrote:
>   
>> On Dec 31, 11:15 am, "Dr. David Kirkby" <david.kir...@onetel.net>
>> wrote:
>>
>>     
>>>> RJF
>>>>         
>>> The point you are missing is that we want to compare the output what Sage prints
>>> to a human.
>>>
>>>       
>> The point you are missing is that the following item, which presumably
>> could be printed by Sage,
>> is perfectly readable to a human:
>>
>> 6121026514868073 * 2^(-51).
>>
>> It exactly dictates the bits in an IEEE double-float, and does not
>> require any conversion from binary
>> to decimal. It does not need rounding.  This kind of representation
>> does not have any hidden unprinted digits.  It does not ever need to
>> be longer because of delicate edge conditions of certain numbers.
>>
>> It happens to evaluate to
>> APPROXIMATELY   2.718281828459045
>>     
>
> Sure, Sage could print that. It would also be worth printing the sign bit, so we 
> could verify the values of
>
> 1) Sign bit
> 2) Significand
> 3) Exponent.
>
> All of those could be correct. But there is still the software which does the 
> non-trivial task of converting that into the base 10 representation used by 
> humans. Then in additon to that, there is the software which takes a base 10 
> number, shows it with the Sage prompt, adding carriage returns etc where 
> necessary. All of these can go wrong.
>
> I would think in an almost ideal world, the test would be done at a higher 
> level, using hardware/software which checked what the monitor actually 
> displayed. That's not quite as easy to do though.
>
> Even better would be some way to scan the brain of the user to see what he/she 
> believes Sage is showing. Perhaps we use a font that is not very good, so 
> despite being displayed properly, it misunderstood.
>
> Given most of time people want to see a base 10 representation of a number, and 
> not a base 2, base 16 or IEE 754 representation, I believe most testing should 
> be done at the base 10 level.
>
> If there is a reason for testing the IEEE 754 representation as first choice, 
> then you have yet to convince me of it.

Dave,

Axiom has the same issues.

My take on this is that what you check depends on the reason you are
checking.  If you are generating the output for human use (e.g. a
table) then you want decimal.  If you are generating the output for
regression testing (e.g. checking the answers on multiple hardware)
then you probably want Fateman's solution.

\start
Date: Thu, 31 Dec 2009 21:16:43 -0800
From: William Stein
To: list
Subject: Re: doctest failures due to rounding errors on Solaris.

On Thu, Dec 31, 2009 at 9:13 PM, Tim Daly wrote:
> Dr. David Kirkby wrote:
>> rjf wrote:
>>
>>> On Dec 31, 11:15 am, "Dr. David Kirkby" <david.kir...@onetel.net>
>>> wrote:
>>>
>>>
>>>>> RJF
>>>>>
>>>> The point you are missing is that we want to compare the output what S=
age prints
>>>> to a human.
>>>>
>>>>
>>> The point you are missing is that the following item, which presumably
>>> could be printed by Sage,
>>> is perfectly readable to a human:
>>>
>>> 6121026514868073 * 2^(-51).
>>>
>>> It exactly dictates the bits in an IEEE double-float, and does not
>>> require any conversion from binary
>>> to decimal. It does not need rounding. This kind of representation
>>> does not have any hidden unprinted digits. It does not ever need to
>>> be longer because of delicate edge conditions of certain numbers.
>>>
>>> It happens to evaluate to
>>> APPROXIMATELY  2.718281828459045
>>>
>>
>> Sure, Sage could print that. It would also be worth printing the sign bi=
t, so we
>> could verify the values of
>>
>> 1) Sign bit
>> 2) Significand
>> 3) Exponent.
>>
>> All of those could be correct. But there is still the software which doe=
s the
>> non-trivial task of converting that into the base 10 representation used=
 by
>> humans. Then in additon to that, there is the software which takes a bas=
e 10
>> number, shows it with the Sage prompt, adding carriage returns etc where
>> necessary. All of these can go wrong.
>>
>> I would think in an almost ideal world, the test would be done at a high=
er
>> level, using hardware/software which checked what the monitor actually
>> displayed. That's not quite as easy to do though.
>>
>> Even better would be some way to scan the brain of the user to see what =
he/she
>> believes Sage is showing. Perhaps we use a font that is not very good, s=
o
>> despite being displayed properly, it misunderstood.
>>
>> Given most of time people want to see a base 10 representation of a numb=
er, and
>> not a base 2, base 16 or IEE 754 representation, I believe most testing =
should
>> be done at the base 10 level.
>>
>> If there is a reason for testing the IEEE 754 representation as first ch=
oice,
>> then you have yet to convince me of it.
>>
>>
>> Dave
>>
>>
>>
> Dave,
>
> Axiom has the same issues.
>
> My take on this is that what you check depends on the reason you are
> checking.
> If you are generating the output for human use (e.g. a table) then you
> want decimal.
> If you are generating the output for regression testing (e.g. checking
> the answers on
> multiple hardware) then you probably want Fateman's solution.
>
> Tim

The output is used both for human use and for regression testing.  Its
primary use is human -- it's an example in the Sage reference manual:

   sage: float(e)
   2.7182818284590451

This is something a user will look at when reading the documentation
for some function.  It illustrates what happens when they convert the
symbolic constant e to float.

\start
Date: Fri, 01 Jan 2010 01:09:06 -0500
From: Tim Daly
To: list
Subject: Re: doctest failures due to rounding errors on Solaris.

William Stein wrote:
> On Thu, Dec 31, 2009 at 9:13 PM, Tim Daly wrote:
>   
>> Dr. David Kirkby wrote:
>>     
>>> rjf wrote:
>>>
>>>       
>>>> On Dec 31, 11:15 am, "Dr. David Kirkby" <david.kir...@onetel.net>
>>>>>> RJF
>>>>>>             
>>>>> The point you are missing is that we want to compare the output what Sage prints to a human.
>>>>>           
>>>> The point you are missing is that the following item, which presumably
>>>> could be printed by Sage,
>>>> is perfectly readable to a human:
>>>>
>>>> 6121026514868073 * 2^(-51).
>>>>
>>>> It exactly dictates the bits in an IEEE double-float, and does not
>>>> require any conversion from binary
>>>> to decimal. It does not need rounding.  This kind of representation
>>>> does not have any hidden unprinted digits.  It does not ever need to
>>>> be longer because of delicate edge conditions of certain numbers.
>>>>
>>>> It happens to evaluate to
>>>> APPROXIMATELY   2.718281828459045
>>>>
>>>>         
>>> Sure, Sage could print that. It would also be worth printing the sign bit, so we
>>> could verify the values of
>>>
>>> 1) Sign bit
>>> 2) Significand
>>> 3) Exponent.
>>>
>>> All of those could be correct. But there is still the software which does the
>>> non-trivial task of converting that into the base 10 representation used by
>>> humans. Then in additon to that, there is the software which takes a base 10
>>> number, shows it with the Sage prompt, adding carriage returns etc where
>>> necessary. All of these can go wrong.
>>>
>>> I would think in an almost ideal world, the test would be done at a higher
>>> level, using hardware/software which checked what the monitor actually
>>> displayed. That's not quite as easy to do though.

>>> Even better would be some way to scan the brain of the user to see
>>> what he/she believes Sage is showing. Perhaps we use a font that
>>> is not very good, so despite being displayed properly, it
>>> misunderstood.  Given most of time people want to see a base 10
>>> representation of a number, and not a base 2, base 16 or IEE 754
>>> representation, I believe most testing should be done at the base
>>> 10 level.

>>> If there is a reason for testing the IEEE 754 representation as first choice,
>>> then you have yet to convince me of it.
>>
>> Axiom has the same issues.

>> My take on this is that what you check depends on the reason you
>> are checking.  If you are generating the output for human use
>> (e.g. a table) then you want decimal.  If you are generating the
>> output for regression testing (e.g. checking the answers on
>> multiple hardware) then you probably want Fateman's solution.

>> Tim
>>     
>
> The output is used both for human use and for regression testing.  Its
> primary use is human -- it's an example in the Sage reference manual:
>
>    sage: float(e)
>    2.7182818284590451
>
> This is something a user will look at when reading the documentation
> for some function.  It illustrates what happens when they convert the
> symbolic constant e to float.

And therein lies the problem. We use a regression that does a
comparison of the printed representation of the output of the run with
a stored copy of the output.

All of our regression tests were passing until I installed another,
unrelated program.  Suddenly about 30 regression tests started
failing. It turns out that the unrelated program upgraded one of the
system libraries. The net effect of that change was to cause the last
digit in the output to "wobble" so that some of the table values
differ in the nth place (20th, 30th, or thereabouts digit). This
caused the regression comparisons to fail.

Common lisp will give you the exact bit pattern of the float and this value
does not wobble so the text comparison succeeds with both the old and
the new libraries against the bit pattern.

So I can tell you from experience that what you would like to do is not
going to succeed.

Our solution to the human vs regression problem is to include the stable
bit values in the actual compare and keep the human values in a latex
table. This is easy to do with literate input.

\start
Date: Thu, 31 Dec 2009 23:00:11 -0800
From: William Stein
To: list
Subject: Re: doctest failures due to rounding errors on Solaris.

On Thu, Dec 31, 2009 at 10:09 PM, Tim Daly wrote=
:
> William Stein wrote:
>> On Thu, Dec 31, 2009 at 9:13 PM, Tim Daly wro=
te:
>> The output is used both for human use and for regression testing. Its
>> primary use is human -- it's an example in the Sage reference manual:
>>
>>  sage: float(e)
>>  2.7182818284590451
>>
>> This is something a user will look at when reading the documentation
>> for some function. It illustrates what happens when they convert the
>> symbolic constant e to float.
>>
>> William
>>
>>
> And therein lies the problem. We use a regression that does a comparison
> of the
> printed representation of the output of the run with a stored copy of
> the output.
>
> All of our regression tests were passing until I installed another,
> unrelated program.
> Suddenly about 30 regression tests started failing. It turns out that
> the unrelated
> program upgraded one of the system libraries. The net effect of that
> change was
> to cause the last digit in the output to "wobble" so that some of the
> table values
> differ in the nth place (20th, 30th, or thereabouts digit). This caused
> the regression
> comparisons to fail.
>
> Common lisp will give you the exact bit pattern of the float and this val=
ue
> does not wobble so the text comparison succeeds with both the old and
> the new libraries against the bit pattern.
>
> So I can tell you from experience that what you would like to do is not
> going to succeed.

What I would like to do does succeed.    The goal of the doctest suite
in Sage is:

  (1) to provide examples for users that illustrate every function in Sage,

  (2) assure that these examples run as claimed, in the sense that a
given input pasted into the Sage command line, results in the claimed
output (with certain well-defined assumptions about state).

You can view (1) as documentation for users, and view (2) as one form
of "regression testing".   There are many types of regression tests.

Regarding your example, I would consider it a bug if the specific
examples of Sage's floating point output -- as claimed in the examples
in the official documentation -- are wrong in the presence of certain
standard system-wide shared libraries.     That is to say, if the Sage
documentation says:

   sage: foo(bar)
   1.2345

but in fact in Sage one has

   sage: foo(bar)
   1.2351

then I would consider this misleading documentation, i.e., a bug.
Your statement above suggests that you *don't* consider this a bug at
all.   In Sage, one possible solution (and it depends on context
whether this it the right solution or not) would be to change the
documentation to

   sage: foo(bar)     # last few digits numerically unstable
   1.23...

The "..." in Python's doctest framework is a wildcard.     The Sage
code hasn't been changed, but the documentation has been.   The point
is that a read of the documentation for the function foo will see
explicitly -- right there in the documentation -- that there are
numerical noise issues on certain platforms.       We have followed
exactly this approach in all of the Sage example docstests, which now
total over 110,000 lines of input, testing over 19,000 functions (or
over 80% of the functions in Sage).

 -- William

>
> Our solution to the human vs regression problem is to include the stable
> bit values in the actual compare and keep the human values in a latex
> table. This is easy to do with literate input.
>
> Tim

\start
Date: Thu, 31 Dec 2009 23:00:27 -0800
From: William Stein
To: list
Subject: Re: doctest failures due to rounding errors on Solaris.

On Thu, Dec 31, 2009 at 10:09 PM, Tim Daly wrote:
> William Stein wrote:
>> On Thu, Dec 31, 2009 at 9:13 PM, Tim Daly wrote:
>> The output is used both for human use and for regression testing. Its
>> primary use is human -- it's an example in the Sage reference manual:
>>
>>  sage: float(e)
>>  2.7182818284590451
>>
>> This is something a user will look at when reading the documentation
>> for some function. It illustrates what happens when they convert the
>> symbolic constant e to float.
>>
>> William
>>

> And therein lies the problem. We use a regression that does a
> comparison of the printed representation of the output of the run
> with a stored copy of the output.

> All of our regression tests were passing until I installed another,
> unrelated program.  Suddenly about 30 regression tests started
> failing. It turns out that the unrelated program upgraded one of the
> system libraries. The net effect of that change was to cause the
> last digit in the output to "wobble" so that some of the table
> values differ in the nth place (20th, 30th, or thereabouts
> digit). This caused the regression comparisons to fail.

> Common lisp will give you the exact bit pattern of the float and this value
> does not wobble so the text comparison succeeds with both the old and
> the new libraries against the bit pattern.

> So I can tell you from experience that what you would like to do is not
> going to succeed.

What I would like to do does succeed.    The goal of the doctest suite
in Sage is:

  (1) to provide examples for users that illustrate every function in Sage,

  (2) assure that these examples run as claimed, in the sense that a
given input pasted into the Sage command line, results in the claimed
output (with certain well-defined assumptions about state).

You can view (1) as documentation for users, and view (2) as one form
of "regression testing".   There are many types of regression tests.

Regarding your example, I would consider it a bug if the specific
examples of Sage's floating point output -- as claimed in the examples
in the official documentation -- are wrong in the presence of certain
standard system-wide shared libraries.     That is to say, if the Sage
documentation says:

   sage: foo(bar)
   1.2345

but in fact in Sage one has

   sage: foo(bar)
   1.2351

then I would consider this misleading documentation, i.e., a bug.
Your statement above suggests that you *don't* consider this a bug at
all.   In Sage, one possible solution (and it depends on context
whether this it the right solution or not) would be to change the
documentation to

   sage: foo(bar)     # last few digits numerically unstable
   1.23...

The "..." in Python's doctest framework is a wildcard.     The Sage
code hasn't been changed, but the documentation has been.   The point
is that a read of the documentation for the function foo will see
explicitly -- right there in the documentation -- that there are
numerical noise issues on certain platforms.       We have followed
exactly this approach in all of the Sage example docstests, which now
total over 110,000 lines of input, testing over 19,000 functions (or
80.9% of the functions in Sage).

> Our solution to the human vs regression problem is to include the stable
> bit values in the actual compare and keep the human values in a latex
> table. This is easy to do with literate input.

\start
Date: Fri, 1 Jan 2010 13:19:32 -0700
From: Krivanek
To: list
Subject: error Message

While using Real Axiom 5.0025 version I got an error message at mile 10,
"Axis minimum value must be equal to or less then maximum"

\start
Date: Tue, 5 Jan 2010 00:27:09 +0800
From: Lee Duhem
To: list
Subject: [PATCH] More fixs about typos and formatting in books.

Hi,

I have found more typos and formatting problems in books,
here is the fixes, you may want take a look.

lee

--00504502cb1f6d2360047c5931cb

ZGlmZiAtLWdpdCBhL2Jvb2tzL2Jvb2t2b2wwLnBhbXBobGV0IGIvYm9va3MvYm9va3ZvbDAucGFt
cGhsZXQKaW5kZXggNDUwOTgwNi4uNDc3M2FkOSAxMDA2NDQKLS0tIGEvYm9va3MvYm9va3ZvbDAu
cGFtcGhsZXQKKysrIGIvYm9va3MvYm9va3ZvbDAucGFtcGhsZXQKQEAgLTE2NDIsNyArMTY0Miw3
IEBAIEdpdmVuIHRoYXQgd2UgY2FuIGRlZmluZSBleHByZXNzaW9ucyBpbnZvbHZpbmcgc3ltYm9s
cywgaG93IGRvIHdlIGFjdHVhbGx5CiBjb21wdXRlIHRoZSByZXN1bHQgd2hlbiB0aGUgc3ltYm9s
cyBhcmUgYXNzaWduZWQgdmFsdWVzPyBUaGUgYW5zd2VyIGlzIHRvCiB1c2UgdGhlIHtcYmYgZXZh
bH0gZnVuY3Rpb24gd2hpY2ggdGFrZXMgYW4gZXhwcmVzc2lvbiBhcyBpdHMgZmlyc3QgYXJndW1l
bnQKIGZvbGxvd2VkIGJ5IGEgbGlzdCBvZiBhc3NpZ25tZW50cy4gRm9yIGV4YW1wbGUsIHRvIGV2
YWx1YXRlIHRoZSBleHByZXNzaW9ucwote1xzbCB4RHVtbXl9IGFuZCB7XHNsIHh5RHVtbXl9IHJl
c3VsdGluZyBmcm9tIHRoZWlyIHJlc3BlY3RpdmUgYXNzaWdubWVudHMgCit7XGJmIHhEdW1teX0g
YW5kIHtcYmYgeHlEdW1teX0gcmVzdWx0aW5nIGZyb20gdGhlaXIgcmVzcGVjdGl2ZSBhc3NpZ25t
ZW50cyAKIGFib3ZlIHdlIHR5cGU6CiAKIFxzcGFkY29tbWFuZHtldmFsKHhEdW1teSx4PTMpfQpA
QCAtNjg5OSw3ICs2ODk5LDcgQEAgQW55IGRvbWFpbiBjYW4gYmUgcmVmaW5lZCB0byBhIHtcaXQg
c3ViZG9tYWlufSBieSBhIG1lbWJlcnNoaXAKIG9iamVjdCBvZiB0aGUgZG9tYWluLCByZXR1cm5z
IGVpdGhlciB7XHR0IHRydWV9IG9yIHtcdHQgZmFsc2V9LiAgRm9yCiBleGFtcGxlLCB0aGUgZG9t
YWluIHtcdHQgSW50ZWdlcn0gY2FuIGJlIHJlZmluZWQgdG8gdGhlIHN1YmRvbWFpbiAKIHtcdHQg
UG9zaXRpdmVJbnRlZ2VyfSwgdGhlIHNldCBvZiBpbnRlZ2VycyAkeCQgc3VjaCB0aGF0ICR4ID4g
MCQsIGJ5IGdpdmluZwotdGhlIEF4aW9tIHByZWRpY2F0ZSAkeCArLT4geCA+IDAkLiAgU2ltaWxh
cmx5LCBBeGlvbSBjYW4gZGVmaW5lCit0aGUgQXhpb20gcHJlZGljYXRlIHtcdHQgeCArLT4geCA+
IDB9LiAgU2ltaWxhcmx5LCBBeGlvbSBjYW4gZGVmaW5lCiBzdWJkb21haW5zIHN1Y2ggYXMgYGB0
aGUgc3ViZG9tYWluIG9mIGRpYWdvbmFsIG1hdHJpY2VzLCcnIGBgdGhlCiBzdWJkb21haW4gb2Yg
bGlzdHMgb2YgbGVuZ3RoIHR3bywnJyBgYHRoZSBzdWJkb21haW4gb2YgbW9uaWMKIGlycmVkdWNp
YmxlIHBvbHlub21pYWxzIGluICR4JCwnJyBhbmQgc28gb24uICBUcml2aWFsbHksIGFueSBkb21h
aW4gaXMKQEAgLTc4MDMsNyArNzgwMyw3IEBAIG9mIHR5cGUge1x0dCBJbnRlZ2VyfS4KIFRoZSBz
eW50YXggZm9yIHdyaXRpbmcgYSB7XHR0IFVuaW9ufSB0eXBlIHdpdGhvdXQgc2VsZWN0b3JzIGlz
CiBcYmVnaW57Y2VudGVyfQoge1x0dCBVbmlvbigkXGhib3h7XGl0IHR5cGV9X3sxfSQsICRcaGJv
eHtcaXQgdHlwZX1fezJ9JCwgCi1cbGRvdHMsICRcaGJveHtcaXQgdHlwZX0re059JCl9CitcbGRv
dHMsICRcaGJveHtcaXQgdHlwZX1fe059JCl9CiBcZW5ke2NlbnRlcn0KIFRoZSB0eXBlcyBpbiBh
IHVuaW9uIHdpdGhvdXQgc2VsZWN0b3JzIG11c3QgYmUgZGlzdGluY3QuXFwKIH0KQEAgLTg1MTcs
NyArODUxNyw3IEBAIFBlcmhhcHMgd2UgYWN0dWFsbHkgd2FudGVkIGEgZnJhY3Rpb24gb2YgY29t
cGxleCBpbnRlZ2Vycy4KICQkCiBcZnJhY3syfXszfQogJCQKLVxyZXR1cm5UeXBle1R5cGU6IEZs
b2F0fQorXHJldHVyblR5cGV7VHlwZTogRnJhY3Rpb24gQ29tcGxleCBJbnRlZ2VyfQogCiBJbiBl
YWNoIGNhc2UsIEFYSU9NIHVzZWQgdGhlIGluZGljYXRlZCBvcGVyYXRpb25zLCBzb21ldGltZXMg
Zmlyc3QKIG5lZWRpbmcgdG8gY29udmVydCB0aGUgdHdvIGludGVnZXJzIGludG8gb2JqZWN0cyBv
ZiB0aGUgYXBwcm9wcmlhdGUgdHlwZS4KQEAgLTEwMTQzLDcgKzEwMTQzLDcgQEAgdGhleSBhcHBl
YXIsIGV4Y2VwdCBhcyBtb2RpZmllZCBieSBjb250cm9sIGV4cHJlc3Npb25zIHN1Y2ggYXMKIFxp
bmRleHtpdGVyYXRlfSB7XHR0IGlmLXRoZW4tZWxzZX0gY29uc3RydWN0aW9ucy4gIFRoZSB2YWx1
ZSBvZiBhIGJsb2NrIGlzCiB0aGUgdmFsdWUgb2YgdGhlIGV4cHJlc3Npb24gbGFzdCBldmFsdWF0
ZWQgaW4gdGhlIGJsb2NrLgogCi1UbyBsZWF2ZSBhIGJsb2NrIGVhcmx5LCB1c2UgYGB7XHR0ID0+
fScnLiAgRm9yIGV4YW1wbGUsICRpIDwgMCA9PiB4JC4gIFRoZQorVG8gbGVhdmUgYSBibG9jayBl
YXJseSwgdXNlIGBge1x0dCA9Pn0nJy4gIEZvciBleGFtcGxlLCB7XHR0IGkgPCAwID0+IHh9LiAg
VGhlCiBleHByZXNzaW9uIGJlZm9yZSB0aGUgYGB7XHR0ID0+fScnIG11c3QgZXZhbHVhdGUgdG8g
e1x0dCB0cnVlfSBvciB7XHR0IGZhbHNlfS4KIFRoZSBleHByZXNzaW9uIGZvbGxvd2luZyB0aGUg
YGB7XHR0ID0+fScnIGlzIHRoZSByZXR1cm4gdmFsdWUgZm9yIHRoZSBibG9jay4KIApAQCAtMTA1
MDUsNyArMTA1MDUsNyBAQCB0aGlzIGlzIGltcG9zc2libGUuICBTbyBBeGlvbSBoYXMgdGhpcyBz
aW1wbGUgcnVsZTogdGhlIHR5cGUgb2YgdGhlCiBmdW5jdGlvbiBpcyBkZXRlcm1pbmVkIGJ5IHRo
ZSB0eXBlIG9mIGl0cyBib2R5LCBpbiB0aGlzIGNhc2UgYSBibG9jay4KIFRoZSBub3JtYWwgdmFs
dWUgb2YgYSBibG9jayBpcyB0aGUgdmFsdWUgb2YgaXRzIGxhc3QgZXhwcmVzc2lvbiwgaW4KIHRo
aXMgY2FzZSwgYSBsb29wLiAgQW5kIHRoZSB2YWx1ZSBvZiBldmVyeSBsb29wIGlzIHRoZSB1bmlx
dWUgdmFsdWUgb2YKLXtcdHQgVm9pZH0uISAgU28gdGhlIHJldHVybiB0eXBlIG9mIHtcYmYgZn0g
aXMge1x0dCBWb2lkfS4KK3tcdHQgVm9pZH0hICBTbyB0aGUgcmV0dXJuIHR5cGUgb2Yge1xiZiBm
fSBpcyB7XHR0IFZvaWR9LgogCiBUaGVyZSBhcmUgdHdvIHdheXMgdG8gZml4IHRoaXMuICBUaGUg
YmVzdCB3YXkgaXMgZm9yIHlvdSB0byB0ZWxsIEF4aW9tCiB3aGF0IHRoZSByZXR1cm4gdHlwZSBv
ZiAkZiQgaXMuICBZb3UgZG8gdGhpcyBieSBnaXZpbmcgJGYkIGEKQEAgLTEwNTQ0LDcgKzEwNTQ0
LDcgQEAgJCQKIFRoZSB7XHR0IGJyZWFrfSBrZXl3b3JkIGlzIG9mdGVuIG1vcmUgdXNlZnVsIFxp
bmRleHticmVha30gaW4gdGVybWluYXRpbmcKIFxpbmRleHtsb29wIWxlYXZpbmcgdmlhIGJyZWFr
fSBhIGxvb3AuICBBIHtcdHQgYnJlYWt9IGNhdXNlcyBjb250cm9sIHRvCiB0cmFuc2ZlciB0byB0
aGUgZXhwcmVzc2lvbiBpbW1lZGlhdGVseSBmb2xsb3dpbmcgdGhlIGxvb3AuICBBcyBsb29wcwot
YWx3YXlzIHJldHVybiB0aGUgdW5pcXVlIHZhbHVlIG9mIHtcdHQgVm9pZH0uLCB5b3UgY2Fubm90
IHJldHVybiBhCithbHdheXMgcmV0dXJuIHRoZSB1bmlxdWUgdmFsdWUgb2Yge1x0dCBWb2lkfSwg
eW91IGNhbm5vdCByZXR1cm4gYQogdmFsdWUgd2l0aCB7XHR0IGJyZWFrfS4gIFRoYXQgaXMsIHtc
dHQgYnJlYWt9IHRha2VzIG5vIGFyZ3VtZW50LgogCiBUaGlzIGV4YW1wbGUgaXMgYSBtb2RpZmlj
YXRpb24gb2YgdGhlIGxhc3QgZXhhbXBsZSBpbiB0aGUgcHJldmlvdXMKQEAgLTEwOTE3LDcgKzEw
OTE3LDcgQEAgd2hpbGUgciA8PSBsYXN0cm93IHJlcGVhdAogXHN1YnNlY3Rpb257Zm9yIExvb3Bz
fQogXGxhYmVse3VnTGFuZ0xvb3BzRm9ySW59CiAKLUF4aW9tIHByb3ZpZGVzIHRoZSB7XHR0IGZv
cn0gXGluZGV4e2Zvcn0gYW5kIHtcdHQgaW5cIH0gXGluZGV4e2lufSBrZXl3b3JkcyBpbgorQXhp
b20gcHJvdmlkZXMgdGhlIHtcdHQgZm9yfSBcaW5kZXh7Zm9yfSBhbmQge1x0dCBpbn0gXGluZGV4
e2lufSBrZXl3b3JkcyBpbgoge1x0dCByZXBlYXR9IGxvb3BzLCBhbGxvd2luZyB5b3UgdG8gaXRl
cmF0ZSBhY3Jvc3MgYWxsIFxpbmRleHtpdGVyYXRpb259CiBlbGVtZW50cyBvZiBhIGxpc3QsIG9y
IHRvIGhhdmUgYSB2YXJpYWJsZSB0YWtlIG9uIGludGVncmFsIHZhbHVlcyBmcm9tCiBhIGxvd2Vy
IGJvdW5kIHRvIGFuIHVwcGVyIGJvdW5kLiAgV2Ugc2hhbGwgcmVmZXIgdG8gdGhlc2UgbW9kaWZ5
aW5nCkBAIC0xMDk0Myw3ICsxMDk0Myw3IEBAIG9mIHtcdHQgVm9pZH0uXFwgfQogXHN1YnNlY3Rp
b257Zm9yIGkgaW4gbi4ubSByZXBlYXR9CiBcbGFiZWx7dWdMYW5nTG9vcHNGb3JJbk5NfQogCi1J
ZiB7XHR0IGZvcn0gXGluZGV4e2Zvcn0gaXMgZm9sbG93ZWQgYnkgYSB2YXJpYWJsZSBuYW1lLCB0
aGUge1x0dCBpblwgfQorSWYge1x0dCBmb3J9IFxpbmRleHtmb3J9IGlzIGZvbGxvd2VkIGJ5IGEg
dmFyaWFibGUgbmFtZSwgdGhlIHtcdHQgaW59CiBcaW5kZXh7aW59IGtleXdvcmQgYW5kIHRoZW4g
YW4gaW50ZWdlciBzZWdtZW50IG9mIHRoZSBmb3JtICRuLi5tJCwKIFxpbmRleHtzZWdtZW50fSB0
aGUgZW5kIHRlc3QgZm9yIHRoaXMgbG9vcCBpcyB0aGUgcHJlZGljYXRlICRpID4gbSQuCiBUaGUg
Ym9keSBvZiB0aGUgbG9vcCBpcyBldmFsdWF0ZWQgJG0tbisxJCB0aW1lcyBpZiB0aGlzIG51bWJl
ciBpcwpAQCAtMTEwMzIsNyArMTEwMzIsNyBAQCBTZWUgXGRvbWFpbnJlZntTZWdtZW50fS4KIEJ5
IGRlZmF1bHQsIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdmFsdWVzIHRha2VuIG9uIGJ5IGEgdmFy
aWFibGUgaW4KIGxvb3BzIHN1Y2ggYXMge1x0dCBmb3IgaSBpbiBuLi5tIHJlcGVhdCAuLi59IGlz
ICQxJC4gIEl0IGlzIHBvc3NpYmxlIHRvCiBzdXBwbHkgYW5vdGhlciwgcG9zc2libHkgbmVnYXRp
dmUsIHN0ZXAgdmFsdWUgYnkgdXNpbmcgdGhlIHtcdHQgYnl9Ci1caW5kZXh7Ynl9IGtleXdvcmQg
YWxvbmcgd2l0aCB7XHR0IGZvcn0gYW5kIHtcdHQgaW5cIH0uICBMaWtlIHRoZSB1cHBlciBhbmQK
K1xpbmRleHtieX0ga2V5d29yZCBhbG9uZyB3aXRoIHtcdHQgZm9yfSBhbmQge1x0dCBpbn0uICBM
aWtlIHRoZSB1cHBlciBhbmQKIGxvd2VyIGJvdW5kcywgdGhlIHN0ZXAgdmFsdWUgZm9sbG93aW5n
IHRoZSB7XHR0IGJ5fSBrZXl3b3JkIG11c3QgYmUgYW4KIGludGVnZXIuICBOb3RlIHRoYXQgdGhl
IGxvb3Age1x0dCBmb3IgaSBpbiAxLi4yIGJ5IDAgcmVwZWF0IG91dHB1dChpKX0KIHdpbGwgbm90
IHRlcm1pbmF0ZSBieSBpdHNlbGYsIGFzIHRoZSBzdGVwIHZhbHVlIGRvZXMgbm90IGNoYW5nZSB0
aGUKQEAgLTExMDgwLDcgKzExMDgwLDcgQEAgYW5kIGxlc3MgdGhhbiB0aGUgZmlyc3QgcHJpbWUg
Z3JlYXRlciB0aGFuICQxNSQuCiAKIEFub3RoZXIgdmFyaWFudCBvZiB0aGUge1x0dCBmb3J9IGxv
b3AgaGFzIHRoZSBmb3JtOgogXGJlZ2lue2NlbnRlcn0KLXtcaXQge1x0dCBmb3J9IHgge1x0dCBp
blwgfSBsaXN0IHtcdHQgcmVwZWF0fSBsb29wQm9keX0KK3tcaXQge1x0dCBmb3J9IHgge1x0dCBp
bn0gbGlzdCB7XHR0IHJlcGVhdH0gbG9vcEJvZHl9CiBcZW5ke2NlbnRlcn0KIAogVGhpcyBmb3Jt
IGlzIHVzZWQgd2hlbiB5b3Ugd2FudCB0byBpdGVyYXRlIGRpcmVjdGx5IG92ZXIgdGhlIGVsZW1l
bnRzCkBAIC0xMTI2OSw3ICsxMTI2OSw3IEBAICQkCiBccmV0dXJuVHlwZXtUeXBlOiBOb25OZWdh
dGl2ZUludGVnZXJ9CiAKIEhlcmUgbG9vcGluZyBzdG9wcyB3aGVuIHRoZSBsaXN0ICRsJCBpcyBl
eGhhdXN0ZWQsIGV2ZW4gdGhvdWdoCi10aGUgJGZvciBpIGluIDAuLiQgc3BlY2lmaWVzIG5vIHRl
cm1pbmF0aW5nIGNvbmRpdGlvbi4KK3RoZSB7XHR0IGZvciBpIGluIDAuLn0gc3BlY2lmaWVzIG5v
IHRlcm1pbmF0aW5nIGNvbmRpdGlvbi4KIAogXHNwYWRjb21tYW5ke2ZvciBpIGluIDAuLiBmb3Ig
eCBpbiBsIHJlcGVhdCBzdW0gOj0gaSAqIHh9CiBccmV0dXJuVHlwZXtUeXBlOiBWb2lkfQpAQCAt
MTE3MTMsNyArMTE3MTMsNyBAQCBpcyBhIHRyaXBsZSBwcmltZS4gIFdlIGNvdWxkIGRvIHRoaXMg
YnkgYSB0cmlwbGUge1x0dCBmb3J9IGl0ZXJhdGlvbi4gIEEKIG1vcmUgZWNvbm9taWNhbCB3YXkg
aXMgdG8gdXNlIHtcYmYgZmlyc3RPZlR3aW5zfS4gIFRoaXMgdGltZSBob3dldmVyLAogcHV0IGEg
c2VtaWNvbG9uIGF0IHRoZSBlbmQgb2YgdGhlIGxpbmUuCiAKLUNyZWF0ZSB0aGUgc3RyZWFtIG9m
IGZpcnN0VHJpcGxldHMuICBQdXQgYSBzZW1pY29sb24gYXQgdGhlIGVuZCBzbworQ3JlYXRlIHRo
ZSBzdHJlYW0gb2Yge1xiZiBmaXJzdFRyaXBsZXRzfS4gIFB1dCBhIHNlbWljb2xvbiBhdCB0aGUg
ZW5kIHNvCiB0aGF0IG5vIGVsZW1lbnRzIGFyZSBjb21wdXRlZC4KIFxzcGFkY29tbWFuZHtmaXJz
dFRyaXBsZXRzIDo9IFtwIGZvciBwIGluIGZpcnN0T2ZUd2lucyBmb3IgcSBpbiByZXN0IGZpcnN0
T2ZUd2lucyB8IHEgPSBwKzJdO30KIFxyZXR1cm5UeXBle1R5cGU6IFN0cmVhbSBJbnRlZ2VyfQpA
QCAtMTE5NTMsMTAgKzExOTUzLDEwIEBAIG1hY3JvIGZpYlN0cmVhbSA9PQogCiBVc2UgXHNwYWRm
dW5Gcm9te2NvbmNhdH17U3RyZWFtfSB0byBzdGFydCB3aXRoIHRoZSBmaXJzdCB0d28KIFxpbmRl
eHtGaWJvbmFjY2kgbnVtYmVyc30gRmlib25hY2NpIG51bWJlcnMuCi1cc3BhZGNvbW1hbmR7Y29u
Y2F0KFswLDFdLGZpYlN0cmVhbSl9Citcc3BhZGNvbW1hbmR7Y29uY2F0KFsxLDFdLGZpYlN0cmVh
bSl9CiAkJAogXGxlZnRbCi0wLCAxLCAyLCAzLCA1LCA4LCB7MTN9LCB7MjF9LCB7MzR9LCB7NTV9
LCAKKzEsIDEsIDIsIDMsIDUsIDgsIHsxM30sIHsyMX0sIHszNH0sIHs1NX0sIAogXGxkb3RzIAog
XHJpZ2h0XQogJCQKQEAgLTEyMDI3LDcgKzEyMDI3LDcgQEAgZXhhbXBsZSBvZiBhIHByZWZpeCBv
cGVyYXRvciBpcyBwcmVmaXggYGB7XHR0IC19JycuICBGb3IgZXhhbXBsZSwgJC0gMiArCiA1JCBj
b252ZXJ0cyB0byAkKC0gMikgKyA1JCBwcm9kdWNpbmcgdGhlIHZhbHVlICQzJC4gIEFueSBwcmVm
aXgKIGZ1bmN0aW9uIHRha2luZyB0d28gYXJndW1lbnRzIGNhbiBiZSB3cml0dGVuIGluIGFuIGlu
Zml4IG1hbm5lciBieQogcHV0dGluZyBhbiBhbXBlcnNhbmQgYGB7XHR0IFwmfScnIGJlZm9yZSB0
aGUgbmFtZS4gIFRodXMgJHtcdHQgRH0oMip4LHgpJCBjYW4KLWJlIHdyaXR0ZW4gYXMgJDIqeFwg
e1x0dCBcJkR9IHgkIHJldHVybmluZyAkMiQuCitiZSB3cml0dGVuIGFzICQyKnhcIHtcdHQgXCZE
fVwgeCQgcmV0dXJuaW5nICQyJC4KIAogRXZlcnkgZnVuY3Rpb24gaW4gQXhpb20gaXMgaWRlbnRp
ZmllZCBieSBhIHtcaXQgbmFtZX0gYW5kIAoge1xpdCB0eXBlfS4gKEFuIGV4Y2VwdGlvbiBpcyBh
biBgYGFub255bW91cyBmdW5jdGlvbicnIGRpc2N1c3NlZCBpbgpAQCAtMTI2NDgsMTIgKzEyNjQ4
LDEyIEBAIEhlcmUgaXMgdGhlIHZhbHVlIG90aGVyd2lzZS4KIFxyZXR1cm5UeXBle1R5cGU6IFZv
aWR9CiAKIFdoYXQgaXMgdGhlIHZhbHVlIGZvciAkbiA9IDckPwotXHNwYWRjb21tYW5ke2ZhY3Rv
KDMpfQorXHNwYWRjb21tYW5ke2ZhY3RvKDcpfQogXGJlZ2lue3ZlcmJhdGltfQogICAgQ29tcGls
aW5nIGZ1bmN0aW9uIGZhY3RvIHdpdGggdHlwZSBJbnRlZ2VyIC0+IEludGVnZXIgCiBcZW5ke3Zl
cmJhdGltfQogJCQKLTYgCis1MDQwCiAkJAogXHJldHVyblR5cGV7VHlwZTogUG9zaXRpdmVJbnRl
Z2VyfQogCkBAIC0xMzMyNSw3ICsxMzMyNSw3IEBAIGJhY2sgdG8gdGhlIG1haW4gQnJvd3NlIG1l
bnUsIGVyYXNlIHtcdHQgZnVuY3Rpb259LCBlbnRlcgoge1x0dCBDcm9zcyBSZWZlcmVuY2V9IGFu
ZCB0aGVuIG9uIHtcdHQgRG9tYWluc30uICAKIFRoZSBsaXN0IHlvdSBzZWUgY29udGFpbnMgb3Zl
ciBmb3J0eSBkb21haW5zIHRoYXQgYmVsb25nIHRvIHRoZSAKIGNhdGVnb3J5IHtcdHQgQ29udmVy
dGlibGVUbyBJbnB1dEZvcm19LiAgVGh1cyB5b3UgY2FuIHVzZSB7XGJmIGZ1bmN0aW9ufSAKLWZv
ciB7XHR0IEludGVnZXJ9LCB7XHR0IEZsb2F0fSwge1x0dCBTdHJpbmd9LCB7XHR0IENvbXBsZXh9
LCAKK2ZvciB7XHR0IEludGVnZXJ9LCB7XHR0IEZsb2F0fSwge1x0dCBTeW1ib2x9LCB7XHR0IENv
bXBsZXh9LCAKIHtcdHQgRXhwcmVzc2lvbn0sIGFuZCBzbyBvbi4KIAogXHNlY3Rpb257RnVuY3Rp
b25zIERlZmluZWQgd2l0aCBCbG9ja3N9CkBAIC0xNDIxNyw3ICsxNDIxNyw3IEBAIEhlcmUgd2Ug
aGF2ZSB1c2VkIHRocmVlIG91dHB1dCBvcGVyYXRpb25zLiAgT3BlcmF0aW9uCiBcc3BhZGZ1bkZy
b217b3V0cHV0fXtPdXRwdXRGb3JtfSBkaXNwbGF5cyB0aGUgcHJpbnRhYmxlIGZvcm0gb2YKIG9i
amVjdHMgb24gdGhlIHNjcmVlbiwgXHNwYWRmdW5Gcm9te2NlbnRlcn17T3V0cHV0Rm9ybX0gY2Vu
dGVycyBhCiBwcmludGFibGUgZm9ybSBpbiB0aGUgd2lkdGggb2YgdGhlIHNjcmVlbiwgYW5kCi1c
c3BhZGZ1bkZyb217YmxhbmtTZXBhcmF0ZX17T3V0cHV0Rm9ybX0gdGFrZXMgYSBsaXN0IG9mIG5w
cmludGFibGUKK1xzcGFkZnVuRnJvbXtibGFua1NlcGFyYXRlfXtPdXRwdXRGb3JtfSB0YWtlcyBh
IGxpc3Qgb2YgbiBwcmludGFibGUKIGZvcm1zIGFuZCBpbnNlcnRzIGEgYmxhbmsgYmV0d2VlbiBz
dWNjZXNzaXZlIGVsZW1lbnRzLgogCiBMb29rIGF0IHRoZSByZXN1bHQuCkBAIC0xNDQyOCw3ICsx
NDQyOCw3IEBAIGlzc3VlZC4gIFRoaW5rIG9mIHJld3JpdGUgcnVsZXMgYXMgZnVuY3Rpb25zIHRo
YXQgdGFrZSBvbmUgYXJndW1lbnQuCiBXaGVuIGEgcmV3cml0ZSBydWxlICRBID0gQiQgaXMgYXBw
bGllZCB0byBhbiBhcmd1bWVudCAkZiQsIGl0cyBtZWFuaW5nCiBpczogYGByZXdyaXRlIGV2ZXJ5
IHN1YmV4cHJlc3Npb24gb2YgJGYkIHRoYXQge1xpdCBtYXRjaGVzfSAkQSQgYnkKICRCLiQnJyBU
aGUgbGVmdC1oYW5kIHNpZGUgb2YgYSByZXdyaXRlIHJ1bGUgaXMgY2FsbGVkIGEge1xpdCBwYXR0
ZXJufTsKLWl0cyByaWdodC1zaWRlIHNpZGUgaXMgY2FsbGVkIGl0cyB7XGl0IHN1YnN0aXR1dGlv
bn0uCitpdHMgcmlnaHQtaGFuZCBzaWRlIGlzIGNhbGxlZCBpdHMge1xpdCBzdWJzdGl0dXRpb259
LgogCiBDcmVhdGUgYSByZXdyaXRlIHJ1bGUgbmFtZWQge1xiZiBsb2dydWxlfS4gIFRoZSBnZW5l
cmF0ZWQgc3ltYm9sCiBiZWdpbm5pbmcgd2l0aCBhIGBge1x0dCBcJX0nJyBpcyBhIHBsYWNlLWhv
bGRlciBmb3IgYW55IG90aGVyIHRlcm1zIHRoYXQKQEAgLTE0OTA3LDcgKzE0OTA3LDcgQEAgVGhl
IGdlbmVyYWwgZm9ybWF0IGZvciBkcmF3aW5nIGEgZnVuY3Rpb24gZGVmaW5lZCBieSBhIGZvcm11
bGEgJGYoeCkkIGlzOgogd2hlcmUgJGEuLmIkIGRlZmluZXMgdGhlIHJhbmdlIG9mICR4JCwgYW5k
IHdoZXJlIHtcaXQgb3B0aW9uc30KIHByZXNjcmliZXMgemVybyBvciBtb3JlIG9wdGlvbnMgYXMg
ZGVzY3JpYmVkIGluCiBcc2VjdGlvbnJlZnt1Z0dyYXBoVHdvRE9wdGlvbnN9LiAgQW4KLWV4YW1w
bGUgb2YgYW4gb3B0aW9uIGlzICRjdXJ2ZUNvbG9yID09IGJyaWdodCByZWQoKS4kIEFuIGFsdGVy
bmF0aXZlCitleGFtcGxlIG9mIGFuIG9wdGlvbiBpcyAkY3VydmVDb2xvciA9PSBicmlnaHRcIHJl
ZCgpLiQgQW4gYWx0ZXJuYXRpdmUKIGZvcm1hdCBpbnZvbHZpbmcgZnVuY3Rpb25zICRmJCBhbmQg
JGckIGlzIGFsc28gYXZhaWxhYmxlLlxcCiB9CiAKQEAgLTE0OTg0LDcgKzE0OTg0LDcgQEAgcGFy
YW1ldHJpYyBmb3JtdWxhcyAkeCA9IGYodCkkIGFuZCAkeSA9IGcodCkkIGlzOgogd2hlcmUgJGEu
LmIkIGRlZmluZXMgdGhlIHJhbmdlIG9mIHRoZSBpbmRlcGVuZGVudCB2YXJpYWJsZSAkdCQsIGFu
ZAogd2hlcmUge1xpdCBvcHRpb25zfSBwcmVzY3JpYmVzIHplcm8gb3IgbW9yZSBvcHRpb25zIGFz
IGRlc2NyaWJlZCBpbgogXHNlY3Rpb25yZWZ7dWdHcmFwaFRocmVlRE9wdGlvbnN9LiAgQW4KLWV4
YW1wbGUgb2YgYW4gb3B0aW9uIGlzICRjdXJ2ZUNvbG9yID09IGJyaWdodCByZWQoKS4kXFwgfQor
ZXhhbXBsZSBvZiBhbiBvcHRpb24gaXMgJGN1cnZlQ29sb3IgPT0gYnJpZ2h0XCByZWQoKS4kXFwg
fQogCiBIZXJlJ3MgYW4gZXhhbXBsZToKIApAQCAtMTYxOTgsNyArMTYxOTgsNyBAQCBvZiB0d28g
dmFyaWFibGVzICR4JCBhbmQgJHkkIGlzOgogd2hlcmUgJGEuLmIkIGFuZCAkYy4uZCQgZGVmaW5l
IHRoZSByYW5nZSBvZiAkeCQKIGFuZCAkeSQsIGFuZCB3aGVyZSB7XGl0IG9wdGlvbnN9IHByZXNj
cmliZXMgemVybyBvciBtb3JlCiBvcHRpb25zIGFzIGRlc2NyaWJlZCBpbiBcc2VjdGlvbnJlZnt1
Z0dyYXBoVGhyZWVET3B0aW9uc30uCi1BbiBleGFtcGxlIG9mIGFuIG9wdGlvbiBpcyAkdGl0bGUg
PT0gIlRpdGxlIG9mIEdyYXBoIi4kCitBbiBleGFtcGxlIG9mIGFuIG9wdGlvbiBpcyAkdGl0bGUg
PT0gIlRpdGxlXCBvZlwgR3JhcGgiLiQKIEFuIGFsdGVybmF0aXZlIGZvcm1hdCBpbnZvbHZpbmcg
YSBmdW5jdGlvbiAkZiQgaXMgYWxzbwogYXZhaWxhYmxlLlxcCiB9CkBAIC0xNjI1Myw3ICsxNjI1
Myw3IEBAICR6ID0gaCh0KSQgaXM6CiB3aGVyZSAkYS4uYiQgZGVmaW5lcyB0aGUgcmFuZ2Ugb2Yg
dGhlIGluZGVwZW5kZW50IHZhcmlhYmxlCiAkdCQsIGFuZCB3aGVyZSB7XGl0IG9wdGlvbnN9IHBy
ZXNjcmliZXMgemVybyBvciBtb3JlIG9wdGlvbnMKIGFzIGRlc2NyaWJlZCBpbiBcc2VjdGlvbnJl
Znt1Z0dyYXBoVGhyZWVET3B0aW9uc30uCi1BbiBleGFtcGxlIG9mIGFuIG9wdGlvbiBpcyAkdGl0
bGUgPT0gIlRpdGxlIG9mIEdyYXBoIi4kCitBbiBleGFtcGxlIG9mIGFuIG9wdGlvbiBpcyAkdGl0
bGUgPT0gIlRpdGxlXCBvZlwgR3JhcGgiLiQKIEFuIGFsdGVybmF0aXZlIGZvcm1hdCBpbnZvbHZp
bmcgZnVuY3Rpb25zICRmJCwgJGckIGFuZAogJGgkIGlzIGFsc28gYXZhaWxhYmxlLlxcCiB9CkBA
IC0xNjMyNiw3ICsxNjMyNiw3IEBAIHdoZXJlICRhLi5iJCBhbmQgJGMuLmQkIGRlZmluZSB0aGUg
cmFuZ2Ugb2YgdGhlCiBpbmRlcGVuZGVudCB2YXJpYWJsZXMgJHUkIGFuZCAkdiQsIGFuZCB3aGVy
ZQoge1xpdCBvcHRpb25zfSBwcmVzY3JpYmVzIHplcm8gb3IgbW9yZSBvcHRpb25zIGFzIGRlc2Ny
aWJlZCBpbgogXHNlY3Rpb25yZWZ7dWdHcmFwaFRocmVlRE9wdGlvbnN9LgotQW4gZXhhbXBsZSBv
ZiBhbiBvcHRpb24gaXMgJHRpdGxlID09ICJUaXRsZSBvZiBHcmFwaCIuJAorQW4gZXhhbXBsZSBv
ZiBhbiBvcHRpb24gaXMgJHRpdGxlID09ICJUaXRsZVwgb2ZcIEdyYXBoIi4kCiBBbiBhbHRlcm5h
dGl2ZSBmb3JtYXQgaW52b2x2aW5nIGZ1bmN0aW9ucyAkZiQsICRnJCBhbmQKICRoJCBpcyBhbHNv
IGF2YWlsYWJsZS5cXAogfQo=
--00504502cb1f6d2360047c5931cb

ZGlmZiAtLWdpdCBhL2Jvb2tzL2Jvb2t2b2wxLnBhbXBobGV0IGIvYm9va3MvYm9va3ZvbDEucGFt
cGhsZXQKaW5kZXggMjk2MmM0ZS4uNGQ1NzdlYSAxMDA2NDQKLS0tIGEvYm9va3MvYm9va3ZvbDEu
cGFtcGhsZXQKKysrIGIvYm9va3MvYm9va3ZvbDEucGFtcGhsZXQKQEAgLTk0NjMsNyArOTQ2Myw3
IEBAIEFueSBkb21haW4gY2FuIGJlIHJlZmluZWQgdG8gYSB7XGl0IHN1YmRvbWFpbn0gYnkgYSBt
ZW1iZXJzaGlwCiBvYmplY3Qgb2YgdGhlIGRvbWFpbiwgcmV0dXJucyBlaXRoZXIge1x0dCB0cnVl
fSBvciB7XHR0IGZhbHNlfS4gIEZvcgogZXhhbXBsZSwgdGhlIGRvbWFpbiB7XHR0IEludGVnZXJ9
IGNhbiBiZSByZWZpbmVkIHRvIHRoZSBzdWJkb21haW4gCiB7XHR0IFBvc2l0aXZlSW50ZWdlcn0s
IHRoZSBzZXQgb2YgaW50ZWdlcnMgJHgkIHN1Y2ggdGhhdCAkeCA+IDAkLCBieSBnaXZpbmcKLXRo
ZSBBeGlvbSBwcmVkaWNhdGUgJHggKy0+IHggPiAwJC4gIFNpbWlsYXJseSwgQXhpb20gY2FuIGRl
ZmluZQordGhlIEF4aW9tIHByZWRpY2F0ZSB7XHR0IHggKy0+IHggPiAwfS4gIFNpbWlsYXJseSwg
QXhpb20gY2FuIGRlZmluZQogc3ViZG9tYWlucyBzdWNoIGFzIGBgdGhlIHN1YmRvbWFpbiBvZiBk
aWFnb25hbCBtYXRyaWNlcywnJyBgYHRoZQogc3ViZG9tYWluIG9mIGxpc3RzIG9mIGxlbmd0aCB0
d28sJycgYGB0aGUgc3ViZG9tYWluIG9mIG1vbmljCiBpcnJlZHVjaWJsZSBwb2x5bm9taWFscyBp
biAkeCQsJycgYW5kIHNvIG9uLiAgVHJpdmlhbGx5LCBhbnkgZG9tYWluIGlzCkBAIC0xMDM5Nyw3
ICsxMDM5Nyw3IEBAIG9mIHR5cGUge1x0dCBJbnRlZ2VyfS4KIFRoZSBzeW50YXggZm9yIHdyaXRp
bmcgYSB7XHR0IFVuaW9ufSB0eXBlIHdpdGhvdXQgc2VsZWN0b3JzIGlzCiBcYmVnaW57Y2VudGVy
fQoge1x0dCBVbmlvbigkXGhib3h7XGl0IHR5cGV9X3sxfSQsICRcaGJveHtcaXQgdHlwZX1fezJ9
JCwgCi1cbGRvdHMsICRcaGJveHtcaXQgdHlwZX0re059JCl9CitcbGRvdHMsICRcaGJveHtcaXQg
dHlwZX1fe059JCl9CiBcZW5ke2NlbnRlcn0KIFRoZSB0eXBlcyBpbiBhIHVuaW9uIHdpdGhvdXQg
c2VsZWN0b3JzIG11c3QgYmUgZGlzdGluY3QuXFwKIH0KQEAgLTExMTA3LDcgKzExMTA3LDcgQEAg
UGVyaGFwcyB3ZSBhY3R1YWxseSB3YW50ZWQgYSBmcmFjdGlvbiBvZiBjb21wbGV4IGludGVnZXJz
LgogJCQKIDIgXG92ZXIgMyAKICQkCi1ccmV0dXJuVHlwZXtUeXBlOiBGbG9hdH0KK1xyZXR1cm5U
eXBle1R5cGU6IEZyYWN0aW9uIENvbXBsZXggSW50ZWdlcn0KIAogSW4gZWFjaCBjYXNlLCBBeGlv
bSB1c2VkIHRoZSBpbmRpY2F0ZWQgb3BlcmF0aW9ucywgc29tZXRpbWVzIGZpcnN0CiBuZWVkaW5n
IHRvIGNvbnZlcnQgdGhlIHR3byBpbnRlZ2VycyBpbnRvIG9iamVjdHMgb2YgdGhlIGFwcHJvcHJp
YXRlIHR5cGUuCg==
--00504502cb1f6d2360047c5931cb

ZGlmZiAtLWdpdCBhL2Jvb2tzL2Jvb2t2b2w3LjEucGFtcGhsZXQgYi9ib29rcy9ib29rdm9sNy4x
LnBhbXBobGV0CmluZGV4IDUwYzdkNzIuLjg4MmVhNTMgMTAwNjQ0Ci0tLSBhL2Jvb2tzL2Jvb2t2
b2w3LjEucGFtcGhsZXQKKysrIGIvYm9va3MvYm9va3ZvbDcuMS5wYW1waGxldApAQCAtODUzOTQs
NyArODUzOTQsNyBAQCBIZXJlIGlzIHRoZSB2YWx1ZSBvdGhlcndpc2UuCiBceHRjewogV2hhdCBp
cyB0aGUgdmFsdWUgZm9yIFxheGlvbXtuID0gN30/CiB9ewotXHNwYWRwYXN0ZXtmYWN0bygzKSBc
ZnJlZXtmYWN0b259fQorXHNwYWRwYXN0ZXtmYWN0byg3KSBcZnJlZXtmYWN0b259fQogfQogXHh0
Y3sKIFdoYXQgaXMgdGhlIHZhbHVlIGZvciBcYXhpb217biA9IC03fT8KQEAgLTg2Nzg2LDcgKzg2
Nzg2LDcgQEAgSW5wdXRGb3JtfSBpbiB0aGUgaW5wdXQgYXJlYSBmb2xsb3dpbmcge1xiZiBTID19
LiAgQ2xpY2sgb24ge1xiZiBDcm9zcwogUmVmZXJlbmNlfSBhbmQgdGhlbiBvbiB7XGJmIERvbWFp
bnN9LiAgVGhlIGxpc3QgeW91IHNlZSBjb250YWlucyBvdmVyCiBmb3J0eSBkb21haW5zIHRoYXQg
YmVsb25nIHRvIHRoZSBjYXRlZ29yeSBcYXhpb21UeXBle0NvbnZlcnRpYmxlVG8KIElucHV0Rm9y
bX0uICBUaHVzIHlvdSBjYW4gdXNlIFxheGlvbUZ1bntmdW5jdGlvbn0gZm9yCi1cYXhpb21UeXBl
e0ludGVnZXJ9LCBcYXhpb21UeXBle0Zsb2F0fSwgXGF4aW9tVHlwZXtTdHJpbmd9LAorXGF4aW9t
VHlwZXtJbnRlZ2VyfSwgXGF4aW9tVHlwZXtGbG9hdH0sIFxheGlvbVR5cGV7U3ltYm9sfSwKIFxh
eGlvbVR5cGV7Q29tcGxleH0sIFxheGlvbVR5cGV7RXhwcmVzc2lvbn0sIGFuZCBzbyBvbi4KIAog
XGVuZHNjcm9sbAo=
--00504502cb1f6d2360047c5931cb--

\start
Date: Thu, 7 Jan 2010 16:17:13 +0000
From: Martin Baker
To: Tim Daly
Subject: Re: GrassmannAlgebra domain

On Thursday 10 Dec 2009 20:03:34 Tim Daly wrote:
> Well Axiom is all about organizing the algebra into hierarchical
> categories where
> each category build on prior ones.
> 
> Is there a natural hierarchy of these algebras? If so, I think it is
> important to
> extract that hierarchy, define the operations at the category level even
> if they
> do not have an implementation there, and layer the categories naturally.
> 
> I would start by just writing the Cayley-Dickson, Spinor, Hopf, and Tensor
> domain definitions (without implementations), find the common operations,
> collect them into a category, and inherit from that category.
> 
> I know a little bit about Clifford algebra and I'm reading the Grassman
> algebra book now but I do not know enough to say anything about what
> would be common among the various algebras.
> 
> Tim
> 

Tim,

I've been thinking about this although I'm not sure I've had any great 
insights? I don't claim to have any great expertise in the the deeper level 
mathematics myself so I thought I would just write down all the issues that 
occurred to me in case you or anyone had any ideas.

By the way, I'm still working on Grassman/Clifford algebra code here:
file:///home/master/euclid/maths/standards/program/clifford/

Although these algebras have common operations like addition, multiplication 
(exterior, inner...) and their inverses, they would be coded differently so I 
can't see now they would make use of common code in categories, or inherit 
from categories, in such a way to simplify the relationships between these 
related algebras.

In many cases we might want the algebra to be a module over algebras with one 
of the multiplications which is:

    * associative.
    * possibly commutative or non-commutative.
    * distributive over addition.

Although not all the multiplications in a given algebra/structure would have 
these properties.  We may want to have a module over an algebra with multiple 
multiplications, such as Grassmann/Clifford algebra itself, so we need a way 
to choose the multiplication which forms the module.

In addition to these requirements we can't take this algebra family in 
isolation but they need to interwork with related algebra families, It would 
be good if these algebra families need to appear on the category and domain 
graph here:
http://www.axiom-developer.org/axiom-website/dotabb.html
(its not complicated enough yet!)

Relationship to Other Algebras
-----------------------------------------
Since there are many accidental and not so accidental isomorphisms between 
Clifford algebras and Cayley-Dickson (complex, quaternion and octonion), 
spinor, Hopf and tensor Algebras, for instance: see tables in [Pertti 
Lounesto, Clifford Algebras and Spinors, Second Edition].

Do we need lots of coerce functions? Or can we represent some of these by 
choosing a suitable category hierarchy?

Are there common functions between these algebras that could be separated out 
into categories?

How to Choose a Hierarchy
--------------------------------------
How do we go about designing a category hierarchy structure? How does this 
relate to the way that algebras are created in mathematics?

By applying constraints?
--------------------------------
We could start with tensor algebra and represent these as a subalgebra by 
applying some constraint (like Pauli matrices). Is there a way to get a 
subalgebra in SPAD by applying constraints?

There is already an issue with working with sparse Clifford algebras and this 
approach would seem to make the issue of efficient coding and storage of 
variables even worse.

Also this would seem to go away from point of having a separate Clifford 
algebra implementation and so I don't think this approach is really practical?

By using isomorphisms?
----------------------------------
There are lots of isomorphisms between the algebra families, is it practical 
to treat say complex numbers or quaternions as special cases of a Clifford 
algebra? Probably not as complex numbers are used widely and need to be 
efficient.

Generating using semidirect product and so on?
-----------------------------------------------------------------
Since it does not seem very efficient to use the category hierarchy to create 
subalgebras from more general algebras, can we do the reverse and build up 
more complex algebras from simpler ones?

For instance could we generate the quaternions from complex numbers whose 
elements were themselves complex numbers? Or could we generate quaternions 
from a semidirect product of two complex number algebras?

As SPAD stands at the moment I can't see how this is possible? We cant even 
create complex numbers whose elements are themselves complex numbers:

(1) -> a:= complex(complex(1,2),complex(3,4))
   There are 1 exposed and 0 unexposed library operations named complex
      having 2 argument(s) but none was determined to be applicable.
      Use HyperDoc Browse, or issue
                             )display op complex
      to learn more about the available operations. Perhaps
      package-calling the operation or using coercions on the arguments
      will allow you to apply the operation.

   Cannot find a definition or applicable library operation named
      complex with argument type(s)
                              Complex(Integer)
                              Complex(Integer)

      Perhaps you should use "@" to indicate the required return type,
      or "$" to specify which version of the function you need.
(1) -> 

What seems to be required is a way to allow the inner and outer complex 
numbers to define a different imaginary operator and to define how they 
interact:

a: Quaternion := complex(%i,complex(%j,1,2),complex(%j,3,4), %k=%i*%j)

Anyhow, at this stage I cannot see how to generate algebras in this way?

Common Functions on these Algebras
----------------------------------------------------
Although I can't see how to how to design a category hierarchy to usefully 
relate these algebra families I can think of some common functions that could 
be applied to these algebras.

This does not concern operations on instances of elements of these algebras 
but operations on the whole algebras, examples of the sort of things that I 
would like to be able to do is:

    * Create a Type consisting of a complex number whose elements are complex 
numbers whose elements are complex numbers, run a function to check if this 
algebra is associative.
    * run a function to check if the above algebra is isomorphic to octonions.
    * Start with a Clifford algebra based on 3 dimensional space, add another 
dimension that squares to +ve, add another dimension that squares to -ve, in 
the plane of these extra dimensions rotate by 45 degrees.
    * Orthogonalise a basis.
    * Take a semidirect product of two complex number algebras, check if this 
is isomorphic to quaternions.
    * Take an even subalgebra of a Clifford algebra based on 3D Euclidean 
space, check if this is isomorphic to quaternions.
    * Convert to reciprocal basis
    * Convert between Clifford and Grassmann basis.

So none of these operations involves creating an element (a representation) in 
these algebras, they are all functions which operate on the algebra (Type) as 
a whole. So what I was thinking of is an interface (category) that could be 
applied to many algebras (domains) to provide a common set of functions like:

    * addDimension(squaresTo)
    * isAssociative?()
    * isIsomorphic?(Type)
    * rotateDimensions(plane)
    * directProduct(Type,Type)
    * semidirectProduct(Type,Type,function)
    * evenSubalgebra()
    * constrainToOrthogonal()

In the case of Clifford algebras these functions would be implemented to 
operate purely on the bilinear form, in the case of other algebras they would 
be implemented to operate on what determines that algebra.

\start
Date: Thu, 7 Jan 2010 16:35:51 +0000
From: Martin Baker
To: list
Subject: Re: GrassmannAlgebra domain

correction - the link in my last message should have been:
http://www.euclideanspace.com/maths/standards/program/clifford/

\start
Date: Mon, 11 Jan 2010 11:26:14 -0500
From: Camm Maguire
To: Tim Daly
Subject: Debian ports

Hi Tim!  Is there a reason that makeint.lisp needs to load bookvol5
twice?

\start
Date: Mon, 11 Jan 2010 14:19:14 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: Debian ports

Camm Maguire wrote:
> Hi Tim!  Is there a reason that makeint.lisp needs to load bookvol5
> twice?

I have been away on a business trip for the last week.
I will look at this shortly.

\start
Date: Mon, 11 Jan 2010 15:10:45 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: Debian ports

Tim Daly writes:

> Camm Maguire wrote:
>> Hi Tim!  Is there a reason that makeint.lisp needs to load bookvol5
>> twice?
>>
>> Take care,
>>   
> Camm,
>
> I have been away on a business trip for the last week.
> I will look at this shortly.
>
> Tim

Great to be in contact again.

1) I've apparently fixed the issue with the non-native-reloc ports, at
least temporarily, by loading bookvol5 in makeint.lisp as a .lsp the
first time.  I provide more detail later if desired.

2) I've just committed to the 2.6.8pre branch socket code which I hope
will obviate the need for your recent read.d patch regarding
read-char-no-hang.  I really think the current behavior is correct,
though I could of course be overlooking something.  Newlines are read
and returned.  The old implementation, among other things, returned
'eof for (read-char-no-hang *standard-input* nil 'eof)<Return>. 

I think you are rolling your own socket code, but I've been testing
briefly with this:

=============================================================================
>(in-package 'si)

#<"SYSTEM" package>

SYSTEM>(defun foo (&rest r ) nil)

FOO

SYSTEM>(let* ((s (socket 8081 :server #'foo))(a (accept s))) (do nil ((eq 'eof (setq ch (read-char-no-hang a nil 'eof)))) (sleep 1) (when ch (print ch))))

#\a 
#\s 
#\d 
#\Return 
#\Newline 
NIL

SYSTEM>.
=============================================================================
(other xterm)
telnet localhost 8081 </tmp/foo
Trying 127.0.0.1...
Connected to localhost.m.enhanced.com.
Escape character is '^]'.
Connection closed by foreign host.
=============================================================================
file /tmp/foo
asd
=============================================================================

3) I don't really know how to test or use )browse at the moment.  And
I have forgotten how to escape to the lisp propmt, (as opposed to one
command at a time )lisp)

4) It would be great to integrate the compiler::link patches for now
at least.  At some point I hope to have native object relocation
everywhere, but this is likely a ways off.

Note I'm turning off sgc for now, but this should not be permanent.

=============================================================================
--- ./lsp/Makefile.pamphlet.orig	2010-01-04 16:45:15.000000000 +0000
+++ ./lsp/Makefile.pamphlet	2010-01-04 16:46:18.000000000 +0000
@@ -1161,12 +1161,8 @@
 
 gcldir: 
 	@echo 2 building ${GCLVERSION}
-	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
-<<gcl-2.6.8pre.socket.patch>>
-<<gcl-2.6.8pre.libspad.patch>>
-<<gcl-2.6.8pre.toploop.patch>>
-<<gcl-2.6.8pre.collectfn.fix>>
-<<gclConfigureMake>>
+#	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
+	echo '(compiler::link (list (compile-file "${BOOKS}/tangle.lisp")) "${OUT}/lisp" (format nil "(progn (let ((*load-path* (cons ~S *load-path*))(si::*load-types* ~S)) (compiler::emit-fn t))(fmakunbound (quote si::sgc-on))(when (fboundp (quote si::sgc-on)) (si::sgc-on t))#-native-reloc(setq compiler::*default-system-p* t))" si::*system-directory* (quote (list #+native-reloc".o" ".lsp"))) "${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o ${OBJ}/${SYS}/lib/libspad.a")' | gcl
 	@echo 13 finished system build on `date` | tee >gcldir
 
 ccldir: ${LSP}/ccl/Makefile
--- ./src/interp/Makefile.pamphlet.orig	2010-01-11 17:34:04.000000000 +0000
+++ ./src/interp/Makefile.pamphlet	2010-01-11 17:33:38.000000000 +0000
@@ -426,8 +426,28 @@
 \begin{verbatim}
 <<save depsys image>>=
 	@ (cd ${MNT}/${SYS}/bin ; \
-	   echo '(progn (load "${OUT}/makedep.lisp")' \
-                '(spad-save "${DEPSYS}"))' | ${LISPSYS})
+	   echo '#+native-reloc(progn (load "${OUT}/makedep.lisp") (spad-save "${DEPSYS}"))#-native-reloc(progn\
+			(setq si::*collect-binary-modules* t)\
+			(load "${OUT}/makedep.lisp")\
+			(compiler::link\
+				(remove-duplicates si::*binary-modules* :test (quote equal))\
+				"$(DEPSYS)"\
+				(format nil "\
+					(setq si::*collect-binary-modules* t)\
+					(let ((si::*load-path* (cons ~S si::*load-path*))\
+	                                     (si::*load-types* ~S))\
+						(compiler::emit-fn t))\
+					(load \"$(OUT)/makedep.lisp\")\
+					(gbc t)\
+					(when si::*binary-modules*\
+						(error (apply 'concatenate 'string \"Binary module load error: \" si::*binary-modules*)))\
+					(setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+					(gbc t)\
+					(fmakunbound (quote si::sgc-on))(when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+					(setq compiler::*default-system-p* t)\
+				" si::*system-directory* (quote (list ".lsp")))\
+				""\
+				nil))' | sed 's,\\$$,,g' | ${LISPSYS})
 @
 \end{verbatim}
 
@@ -697,7 +717,7 @@
 #	@ cp -p ${SRC}/doc/msgs/co-eng.msgs ${SPAD}/doc/msgs
 	@ echo '${PROCLAIMS}' > ${OUT}/makeint.lisp
 	@ echo '(load "${OUT}/nocompil")' >> ${OUT}/makeint.lisp
-	@ echo '(load "${OUT}/bookvol5")' >> ${OUT}/makeint.lisp
+	@ echo '(load "${OUT}/bookvol5.lsp")' >> ${OUT}/makeint.lisp
 	@ echo '(load "${OUT}/util")' >> ${OUT}/makeint.lisp
 	@ echo '(in-package "BOOT")' >> ${OUT}/makeint.lisp
 	@ touch ${TIMESTAMP}
@@ -728,8 +748,33 @@
 	@ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' \
                >> ${OUT}/makeint.lisp
 	@ (cd ${OBJ}/${SYS}/bin ; \
-	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp")' \
-                 '(gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+	  echo '#+native-reloc(progn (gbc t) (setq x si::*system-directory*)(load "${OUT}/makeint.lisp") (setq si::*system-directory* x) (unintern (quote x))(gbc t)(user::spad-save "${SAVESYS}"))#-native-reloc(progn\
+			(setq si::*collect-binary-modules* t)\
+			(setq x si::*system-directory*)\
+			(load "${OUT}/makeint.lisp")\
+			(setq si::*system-directory* x)\
+			(unintern (quote x))\
+			(compiler::link\
+				(remove-duplicates si::*binary-modules* :test (quote equal))\
+				"$(SAVESYS)"\
+				(format nil "\
+					(let ((si::*load-path* (cons ~S si::*load-path*))\
+                                             (si::*load-types* ~S))\
+						(compiler::emit-fn t))\
+					 (setq si::*collect-binary-modules* t)\
+					 (setq x si::*system-directory*)\
+					 (load \"$(OUT)/makeint.lisp\")\
+					 (setq si::*system-directory* x)\
+					 (unintern (quote x))\
+					 (when si::*binary-modules*\
+						(error (apply 'concatenate 'string \"Binary module load error: \" si::*binary-modules*)))\
+					(setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+					(gbc t)\
+					(fmakunbound (quote si::sgc-on))(when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+					(setq compiler::*default-system-p* t)\
+				" si::*system-directory* (quote (list ".lsp")))\
+			"$(OBJ)/$(SYS)/lib/sockio-c.o $(OBJ)/$(SYS)/lib/cfuns-c.o $(OBJ)/$(SYS)/lib/libspad.a" \
+			nil))' | sed 's,\\$$,,g' | $(LISPSYS))
 	@ echo 6 ${SAVESYS} created
 	@ cp ${SAVESYS} ${AXIOMSYS}
 	@ echo 6a ${AXIOMSYS} created
--- ./src/etc/Makefile.pamphlet.orig	2010-01-04 15:26:34.000000000 +0000
+++ ./src/etc/Makefile.pamphlet	2010-01-04 14:55:31.000000000 +0000
@@ -24,7 +24,7 @@
 	@ cp ${SRC}/doc/topics.data ${INT}/algebra
 	@ cp ${SRC}/doc/topics.data ${INT}/algebra
 	@ (cd ${INT}/algebra ; \
-           echo ')lisp (make-databases "" nil)' | ${INTERPSYS} )
+           echo ')lisp #+native-reloc(make-databases "" nil) #-native-reloc(system "cp ${SRC}/../debian/*.daase ${INT}/algebra/")' | ${INTERPSYS} )
 	@ cp -pr ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra
 
 @
=============================================================================

\start
Date: Tue, 12 Jan 2010 00:23:07 +0100
From: Michael Becker
To: list
Subject: sum(binomial(t+i,i),i=0..k)

    Hi,
     can someone explain  the following answer of axiom?

(12) -> sum(binomial(t+i,i),i=0..k)

                     t + k      t - 1
         (t + k + 1)(     ) - t(     )
                       k         - 1
   (12)  -----------------------------
                     t + 1
                                                    Type: Expression(Integer)
(13) ->                                                                         

\start
Date: Tue, 12 Jan 2010 06:51:21 +0100
From: Martin Rubey
To: Michael Becker
Subject: Re: sum(binomial(t+i,i),i=0..k)

Michael Becker writes:

>     Hi,
>      can someone explain  the following answer of axiom?
>
> (12) -> sum(binomial(t+i,i),i=0..k)
>
>                      t + k      t - 1
>          (t + k + 1)(     ) - t(     )
>                        k         - 1
>    (12)  -----------------------------
>                      t + 1
>                                                     Type: Expression(Integer)

What do want to know? It's entirely correct.  The second binomial should
be interpreted as always zero, that's all.

\start
Date: Tue, 12 Jan 2010 03:10:44 -0500
From: Bill Page
To: list
Subject: Fwd: sum(binomial(t+i,i),i=0..k)

---------- Forwarded message ----------

Am Dienstag, 12. Januar 2010 00:46 schrieb Bill Page:
> What in particular do you think requires explanation? It looks ok to me.
> E.g.
>
> (1) -> ex1:=sum(binomial(t+i,i),i=0..k)
>
>           t + k   t - 1
>     (t + k + 1)(   ) - t(   )
>            k     - 1
>  (1) -----------------------------
>           t + 1
>                   Type: Expression

a)  i do not understand the meaning of binomial(t-1,-1):

(2) -> kernels(ex1).2

    t - 1
 (2) (   )
    - 1

b) i did expect:  binomial(t+k+1, t+1)

 (3) -> eval(binomial(t+k+1, t+1),[t=10,k=31])

  (3) 4280561376

c) axiom does not like binomial(t-1,-1)

 (4) -> normalize (ex1 - binomial(t+k+1, t+1))

  >> Error detected within library code:
  factorial not defined for negative integers

d) t*binomial(t-1,-1) is really = 0 in ex1 :

 (4) -> normalize ( (t+k+1)*binomial(t+k,k)/ (t+1) - binomial(t+k+1, =
t+1))

  (4) 0

> Integer (2) -> eval(ex1,[t=10,k=31])
>
>  (2) 4280561376
>                   =
        Type: Expression
> Integer (3) -> [binomial(10+i,i) for i in 0..31]
>
>  (3)
>  [1, 11, 66, 286, 1001, 3003, 8008, 19448, 43758, 92378, 184756, 35=
2716,
>   646646, 1144066, 1961256, 3268760, 5311735, 8436285, 13123110,
> 20030010, 30045015, 44352165, 64512240, 92561040, 131128140, 183579396,
> 254186856, 348330136, 472733756, 635745396, 847660528, 1121099408]
>                   =
           Type: List
> Integer (4) -> reduce(+,%)
>
>  (4) 4280561376
>                   =
          Type:
> PositiveInteger
>
> 2010/1/11 Michael Becker:
> >   can someone explain the following answer of axiom?
> >
> > (12) -> sum(binomial(t+i,i),i=0..k)
> >
> >           t + k   t - 1
> >     (t + k + 1)(   ) - t(   )
> >            k     - 1
> >  (12) -----------------------------
> >           t + 1
> >                  =
        Type:
> > Expression(Integer)

\start
Date: Tue, 12 Jan 2010 09:34:25 -0500
From: Tim Daly
To: Lee Duhem
Subject: Re: [PATCH] More fixs about typos and formatting in books.

Lee Duhem wrote:
> Hi,
>
> I have found more typos and formatting problems in books,
> here is the fixes, you may want take a look.

Your patches have been applied.
Thank you.

\start
Date: Wed, 13 Jan 2010 05:14:32 +0100
From: Michael Becker
To: Martin Rubey
Subject: Re: sum(binomial(t+i,i),i=0..k)

Am Dienstag, 12. Januar 2010 06:51 schrieb Martin Rubey:

> ....
> What do want to know? It's entirely correct.  
> The second binomial should be interpreted as always zero, 

  Axion does not believe that  binomial(t-1,-1) is zero:

   (1) -> sum(binomial(t+i,i),i=0..k)

                    t + k      t - 1
        (t + k + 1)(     ) - t(     )
                      k         - 1
   (1)  -----------------------------
                    t + 1
                                     Type: Expression(Integer)
(2) -> normalize %

   >> Error detected within library code:
   factorial not defined for negative integers

\start
Date: Wed, 13 Jan 2010 02:08:45 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: Debian ports

Camm,

Good to hear from you. Sorry for the delay. I was off at a conference all
of last week.

1) I've apparently fixed the issue with the non-native-reloc ports, at
least temporarily, by loading bookvol5 in makeint.lisp as a .lsp the
first time.  I provide more detail later if desired.



1) The bookvol5 file is eventually going to be the full interpreter. I am
moving all of the code (slowly and carefully) into that file. At the moment
only some of the macros have been moved. These macros need to be
in the compile environment so bookvol5 has to be loaded to pick up the
moved macros. This file also needs to be compiled and loaded later
since there are some functions that are currently defined in other files.

This is a temporary situation. I am "tree-shaking" the whole interpreter
so that I only pick up functions that are actually used. I have thrown away
piles of code that can never be referenced. There are still well over 100
files to process so the tree-shaking will probably take the rest of the 
year.
However, once the interpreter is isolated there will only be one literate
file that contains everything.

2) I've just committed to the 2.6.8pre branch socket code which I hope
will obviate the need for your recent read.d patch regarding
read-char-no-hang.  I really think the current behavior is correct,
though I could of course be overlooking something.  Newlines are read
and returned.  The old implementation, among other things, returned
'eof for (read-char-no-hang *standard-input* nil 'eof)<Return>. 

I think you are rolling your own socket code, but I've been testing
briefly with this:


I don't want my own socket code but I was unable to get the behavior I 
needed to
implement using Axiom as a web server. I will pick up your latest 
release and do a
build and test using it. I'm more than happy to use an unpatched lisp.

>
>
> 3) I don't really know how to test or use )browse at the moment.  And
> I have forgotten how to escape to the lisp propmt, (as opposed to one
> command at a time )lisp)
>   

 From the top level you can drop into lisp using ")fin" and you can 
return to Axiom
from lisp using "(restart)" You can also do ")lisp (setq $dalymode t)" 
which will
cause Axiom to interpret any expression that starts with an open-paren 
as lisp thus:

  )lisp (setq $dalymode t)
  (+ 1 1) => 2



 From the top level you type ")browse" and Axiom will now function as a 
web server on
the port (8085). At the moment you need to give a full path to the root 
page thus:

http://127.0.0.1:8085/home/axiom/mnt/ubuntu/doc/hypertex/rootpage.xhtml

Try Topics -> Numbers -> Integers -> x:=factorial(200) as an example.
You should see the result of the computation pasted inline in the webpage.

This should be easier and automatic but I have to write that code and I 
have not.



> 4) It would be great to integrate the compiler::link patches for now
> at least.  At some point I hope to have native object relocation
> everywhere, but this is likely a ways off.
>
> Note I'm turning off sgc for now, but this should not be permanent.
>

I have not used the compiler::link patch because I didn't understand
it and could not get it to work.. I will rewrite the makefile to use
your changes and see if I can get it to work.

Do you know if GCL will build on a MAC? I used to have a MAC port
working but something broke and I cannot figure out what.

\start
Date: Wed, 13 Jan 2010 14:08:52 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: Debian ports

Tim Daly writes:

> Camm,
>
> Good to hear from you. Sorry for the delay. I was off at a conference all
> of last week.
>

No problem -- welcome back!

> 1) I've apparently fixed the issue with the non-native-reloc ports, at
> least temporarily, by loading bookvol5 in makeint.lisp as a .lsp the
> first time.  I provide more detail later if desired.
>
>
>
> 1) The bookvol5 file is eventually going to be the full interpreter. I am
> moving all of the code (slowly and carefully) into that file. At the moment
> only some of the macros have been moved. These macros need to be
> in the compile environment so bookvol5 has to be loaded to pick up the
> moved macros. This file also needs to be compiled and loaded later
> since there are some functions that are currently defined in other files.
>
> This is a temporary situation. I am "tree-shaking" the whole interpreter
> so that I only pick up functions that are actually used. I have thrown away
> piles of code that can never be referenced. There are still well over 100
> files to process so the tree-shaking will probably take the rest of
> the year.
> However, once the interpreter is isolated there will only be one literate
> file that contains everything.
>

OK, but for now, if we want ia64, mips, mipsel, alpha, and hppa ports
(which maybe we don't), I need to get the interpsys build to load all
binary modules just once.  As I said before, things apparently work by
changing the bookvol5 load at the top of makeint.lisp to a .lsp load
as far as this file goes.  But there is alas something else that is
loading (autoloading?) the following file three times:

Error: Binary module load error:
 /home/camm/axiom-20091101/mnt/linux/algebra/exposed.o

Can you help here?  Can I use the same trick to load the first two
instances in .lsp form?

The issue is that on these platforms, native object relocation is
currently absent.  In gcl cvs, mips, mipsel, and alpha relocation become
available, but this still leaves ia64 and hppa, so we need
compiler::link for full portability.  

The idea here is to run the init sequence keeping a list of all loaded
.o files (which use dlopen on these systems and do not persist across
save-system), link in these binaries with the system linker, ld, and
then rerun the init sequence in the produced executable redirecting
all load calls to the previously linked in .o files to a simple
initialization of their program data.  This is reported as
"Initializing" instead of "Loading".  

The problem is that these files can exist in only one instance at the
ld stage, and at the init stage.  (I suppose I could try something
really fancy to copy and rename the files on the fly to file1, file2,
etc. if I had to.  This is tough as the compiled in init function in
each object is named according to the file name at compile time --
these function names have to be unique too.)

> 2) I've just committed to the 2.6.8pre branch socket code which I hope
> will obviate the need for your recent read.d patch regarding
> read-char-no-hang.  I really think the current behavior is correct,
> though I could of course be overlooking something.  Newlines are read
> and returned.  The old implementation, among other things, returned
> 'eof for (read-char-no-hang *standard-input* nil 'eof)<Return>. 
>
> I think you are rolling your own socket code, but I've been testing
> briefly with this:
>
>
> I don't want my own socket code but I was unable to get the behavior I
> needed to
> implement using Axiom as a web server. I will pick up your latest
> release and do a
> build and test using it. I'm more than happy to use an unpatched lisp.
>

Great!

>>
>>
>> 3) I don't really know how to test or use )browse at the moment.  And
>> I have forgotten how to escape to the lisp propmt, (as opposed to one
>> command at a time )lisp)
>>   
>
> From the top level you can drop into lisp using ")fin" and you can
> return to Axiom
> from lisp using "(restart)" You can also do ")lisp (setq $dalymode t)"
> which will
> cause Axiom to interpret any expression that starts with an open-paren
> as lisp thus:
>
>  )lisp (setq $dalymode t)
>  (+ 1 1) => 2
>
>
>
> From the top level you type ")browse" and Axiom will now function as a
> web server on
> the port (8085). At the moment you need to give a full path to the
> root page thus:
>
> http://127.0.0.1:8085/home/axiom/mnt/ubuntu/doc/hypertex/rootpage.xhtml
>
> Try Topics -> Numbers -> Integers -> x:=factorial(200) as an example.
> You should see the result of the computation pasted inline in the webpage.
>
> This should be easier and automatic but I have to write that code and
> I have not.
>
>

Thanks!

Alas my browser is hanging on the above url, so something needs
fixing.  I don't even get to read-char-no-hang:

(1) -> )lisp (trace read-char-no-hang)

Warning: READ-CHAR-NO-HANG is being redefined.
Value = (READ-CHAR-NO-HANG)
(1) -> )browse
listening on port 8085
 .....

Debugging suggestions?

>
>> 4) It would be great to integrate the compiler::link patches for now
>> at least.  At some point I hope to have native object relocation
>> everywhere, but this is likely a ways off.
>>
>> Note I'm turning off sgc for now, but this should not be permanent.
>>
>>   
> I have not used the compiler::link patch because I didn't understand
> it and could not get
> it to work.. I will rewrite the makefile to use your changes and see
> if I can get it to work.
>

Thanks!  Here are my patches, most of which are cosmetic:

=============================================================================
--- Makefile.orig	2009-11-30 16:45:00.000000000 +0000
+++ Makefile	2010-01-05 03:34:57.000000000 +0000
@@ -14,9 +14,9 @@
 #GCLVERSION=gcl-2.6.6
 #GCLVERSION=gcl-2.6.7pre
 #GCLVERSION=gcl-2.6.7
-#GCLVERSION=gcl-2.6.8pre
+GCLVERSION=gcl-2.6.8pre
 #GCLVERSION=gcl-2.6.8pre2
-GCLVERSION=gcl-2.6.8pre3 
+#GCLVERSION=gcl-2.6.8pre3 
 AWK:=gawk
 GCLDIR:=${LSP}/${GCLVERSION}
 SRC:=${SPD}/src
@@ -34,7 +34,7 @@
 DOCUMENT:=${SPADBIN}/document
 TANGLE:=${SPADBIN}/lib/notangle
 WEAVE:=${SPADBIN}/lib/noweave
-NOISE:="-o ${TMP}/trace"
+NOISE:=-o ${TMP}/trace
 PATCH:=patch
 UNCOMPRESS:=gunzip
 
@@ -45,7 +45,7 @@
 ENV:= SPAD=${SPAD} SYS=${SYS} SPD=${SPD} LSP=${LSP} GCLDIR=${GCLDIR} \
      SRC=${SRC} INT=${INT} OBJ=${OBJ} MNT=${MNT} ZIPS=${ZIPS} TMP=${TMP} \
      SPADBIN=${SPADBIN} INC=${INC} CCLBASE=${CCLBASE} PART=${PART} \
-     SUBPART=${SUBPART} NOISE=${NOISE} GCLVERSION=${GCLVERSION} \
+     SUBPART=${SUBPART} NOISE="${NOISE}" GCLVERSION=${GCLVERSION} \
      TANGLE=${TANGLE} VERSION=${VERSION} PATCH=${PATCH} DOCUMENT=${DOCUMENT} \
      WEAVE=${WEAVE} UNCOMPRESS=${UNCOMPRESS} BOOKS=${BOOKS}
 
@@ -59,16 +59,16 @@
 	@ cp Makefile.dvi ${MNT}/${SYS}/doc/src/root.Makefile.dvi
 	@ echo p2 starting parallel make of books
 	@ echo p3 ${SPD}/books/Makefile from ${SPD}/books/Makefile.pamphlet
-	@ ( cd ${SPD}/books ; \
-           ${DOCUMENT} ${NOISE} Makefile ; \
-           cp Makefile.dvi ${MNT}/${SYS}/doc/src/books.Makefile.dvi ; \
-	   ${ENV} ${MAKE} & )
+	@( cd ${SPD}/books && \
+           ${DOCUMENT} ${NOISE} Makefile && \
+           cp Makefile.dvi ${MNT}/${SYS}/doc/src/books.Makefile.dvi && \
+	   ${ENV} ${MAKE} )
 	@ echo p4 starting parallel make of input documents
-	@ ${ENV} ${MAKE} parallelinput ${NOISE} &
+	@ ${ENV} ${MAKE} parallelinput ${NOISE} 
 	@ echo p5 starting parallel make of xhtml documents
-	@ ${ENV} ${MAKE} parallelxhtml ${NOISE} &
+	@ ${ENV} ${MAKE} parallelxhtml ${NOISE} 
 	@ echo p6 starting parallel make of help
-	@ ${ENV} $(MAKE) parallelhelp ${NOISE} &
+	@ ${ENV} $(MAKE) parallelhelp ${NOISE} 
 	@ echo p7 starting parallel make of src
 	@ ${ENV} $(MAKE) -f Makefile.${SYS} 
 	@ echo 3 finished system build on `date` | tee >lastBuildDate
--- Makefile.pamphlet.orig	2010-01-04 21:51:21.000000000 +0000
+++ Makefile.pamphlet	2010-01-04 21:52:11.000000000 +0000
@@ -45,16 +45,16 @@
 	@ cp Makefile.dvi ${MNT}/${SYS}/doc/src/root.Makefile.dvi
 	@ echo p2 starting parallel make of books
 	@ echo p3 ${SPD}/books/Makefile from ${SPD}/books/Makefile.pamphlet
-	@ ( cd ${SPD}/books ; \
-           ${DOCUMENT} ${NOISE} Makefile ; \
-           cp Makefile.dvi ${MNT}/${SYS}/doc/src/books.Makefile.dvi ; \
-	   ${ENV} ${MAKE} & )
+	@( cd ${SPD}/books && \
+           ${DOCUMENT} ${NOISE} Makefile && \
+           cp Makefile.dvi ${MNT}/${SYS}/doc/src/books.Makefile.dvi && \
+	   ${ENV} ${MAKE} )
 	@ echo p4 starting parallel make of input documents
-	@ ${ENV} ${MAKE} parallelinput ${NOISE} &
+	@ ${ENV} ${MAKE} parallelinput ${NOISE} 
 	@ echo p5 starting parallel make of xhtml documents
-	@ ${ENV} ${MAKE} parallelxhtml ${NOISE} &
+	@ ${ENV} ${MAKE} parallelxhtml ${NOISE} 
 	@ echo p6 starting parallel make of help
-	@ ${ENV} $(MAKE) parallelhelp ${NOISE} &
+	@ ${ENV} $(MAKE) parallelhelp ${NOISE} 
 	@ echo p7 starting parallel make of src
 	@ ${ENV} $(MAKE) -f Makefile.${SYS} 
 	@ echo 3 finished system build on `date` | tee >lastBuildDate
@@ -287,7 +287,7 @@
 \end{verbatim}
 with the default value of NOISE being:
 \begin{verbatim}
-   NOISE="-o ${TMP}/trace"
+   NOISE=-o ${TMP}/trace
 \end{verbatim}
 
 The reason NOISE exists is that the latex command will
@@ -371,7 +371,7 @@
 DOCUMENT:=${SPADBIN}/document
 TANGLE:=${SPADBIN}/lib/notangle
 WEAVE:=${SPADBIN}/lib/noweave
-NOISE:="-o ${TMP}/trace"
+NOISE:=-o ${TMP}/trace
 PATCH:=patch
 UNCOMPRESS:=gunzip

@@ -380,7 +380,7 @@
 ENV:= SPAD=${SPAD} SYS=${SYS} SPD=${SPD} LSP=${LSP} GCLDIR=${GCLDIR} \
      SRC=${SRC} INT=${INT} OBJ=${OBJ} MNT=${MNT} ZIPS=${ZIPS} TMP=${TMP} \
      SPADBIN=${SPADBIN} INC=${INC} CCLBASE=${CCLBASE} PART=${PART} \
-     SUBPART=${SUBPART} NOISE=${NOISE} GCLVERSION=${GCLVERSION} \
+     SUBPART=${SUBPART} NOISE="${NOISE}" GCLVERSION=${GCLVERSION} \
      TANGLE=${TANGLE} VERSION=${VERSION} PATCH=${PATCH} DOCUMENT=${DOCUMENT} \
      WEAVE=${WEAVE} UNCOMPRESS=${UNCOMPRESS} BOOKS=${BOOKS}

@@ -806,9 +806,9 @@
 #GCLVERSION=gcl-2.6.6
 #GCLVERSION=gcl-2.6.7pre
 #GCLVERSION=gcl-2.6.7
-#GCLVERSION=gcl-2.6.8pre
+GCLVERSION=gcl-2.6.8pre
 #GCLVERSION=gcl-2.6.8pre2
-GCLVERSION=gcl-2.6.8pre3 
+#GCLVERSION=gcl-2.6.8pre3 
 @
 
 \subsubsection{The [[GCLOPTS]] configure variable}
@@ -867,7 +867,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -914,7 +914,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -961,7 +961,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -1008,7 +1008,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -1055,7 +1055,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -1102,7 +1102,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -1148,7 +1148,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -1201,7 +1201,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -1255,7 +1255,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 SRCDIRS=bootdir interpdir sharedir algebradir etcdir docdir inputdir
 PATCH=patch
@@ -1363,7 +1363,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
 PATCH=patch
@@ -1425,7 +1425,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
 PATCH=patch
@@ -1472,7 +1472,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
 PATCH=patch
@@ -1757,7 +1757,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-CUSTRELOC>>
 <<SRCDIRS>>
 PATCH=patch
@@ -1815,7 +1815,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
 PATCH=patch
@@ -1891,7 +1891,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
 PATCH=patch
@@ -1967,7 +1967,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2043,7 +2043,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2093,7 +2093,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2169,7 +2169,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2245,7 +2245,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2354,7 +2354,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2402,7 +2402,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2450,7 +2450,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2497,7 +2497,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2549,7 +2549,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
 PATCH=gpatch
@@ -2596,7 +2596,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2643,7 +2643,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2690,7 +2690,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2737,7 +2737,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2785,7 +2785,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2832,7 +2832,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2880,7 +2880,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2927,7 +2927,7 @@
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
 PATCH=patch
@@ -2991,7 +2991,7 @@
 LISP=lsp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
+XLIB=/usr/lib
 <<GCLOPTS-CUSTRELOC>>
 <<SRCDIRS>>
 PATCH=patch
--- ./src/algebra/Makefile.pamphlet.orig	2010-01-04 15:26:34.000000000 +0000
+++ ./src/algebra/Makefile.pamphlet	2010-01-04 14:55:31.000000000 +0000
@@ -15975,7 +15975,7 @@
 	  else \
 	   echo '(progn (in-package (quote boot)) (compile-file "$*.lsp" :output-file "$*.o"))' | ${DEPSYS} >${TMP}/trace ; \
 	  fi )
-	@ cp ${MID}/$*.o ${OUT}/$*.o
+	@ mkdir -p $$(dirname $(OUT)/$*.o) && cp ${MID}/$*.o ${OUT}/$*.o
 
 @
 <<genericSPADfiles>>=
=============================================================================
--- ./lsp/Makefile.pamphlet.orig	2010-01-04 16:45:15.000000000 +0000
+++ ./lsp/Makefile.pamphlet	2010-01-04 16:46:18.000000000 +0000
@@ -1161,12 +1161,8 @@
 
 gcldir: 
 	@echo 2 building ${GCLVERSION}
-	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
-<<gcl-2.6.8pre.socket.patch>>
-<<gcl-2.6.8pre.libspad.patch>>
-<<gcl-2.6.8pre.toploop.patch>>
-<<gcl-2.6.8pre.collectfn.fix>>
-<<gclConfigureMake>>
+#	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
+	echo '(compiler::link (list (compile-file "${BOOKS}/tangle.lisp")) "${OUT}/lisp" (format nil "(progn (let ((*load-path* (cons ~S *load-path*))(si::*load-types* ~S)) (compiler::emit-fn t))(fmakunbound (quote si::sgc-on))(when (fboundp (quote si::sgc-on)) (si::sgc-on t))#-native-reloc(setq compiler::*default-system-p* t))" si::*system-directory* (quote (list #+native-reloc".o" ".lsp"))) "${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o ${OBJ}/${SYS}/lib/libspad.a")' | gcl
 	@echo 13 finished system build on `date` | tee >gcldir
 
 ccldir: ${LSP}/ccl/Makefile
--- ./src/interp/Makefile.pamphlet.orig	2010-01-11 17:34:04.000000000 +0000
+++ ./src/interp/Makefile.pamphlet	2010-01-11 17:33:38.000000000 +0000
@@ -426,8 +426,28 @@
 \begin{verbatim}
 <<save depsys image>>=
 	@ (cd ${MNT}/${SYS}/bin ; \
-	   echo '(progn (load "${OUT}/makedep.lisp")' \
-                '(spad-save "${DEPSYS}"))' | ${LISPSYS})
+	   echo '#+native-reloc(progn (load "${OUT}/makedep.lisp") (spad-save "${DEPSYS}"))#-native-reloc(progn\
+			(setq si::*collect-binary-modules* t)\
+			(load "${OUT}/makedep.lisp")\
+			(compiler::link\
+				(remove-duplicates si::*binary-modules* :test (quote equal))\
+				"$(DEPSYS)"\
+				(format nil "\
+					(setq si::*collect-binary-modules* t)\
+					(let ((si::*load-path* (cons ~S si::*load-path*))\
+	                                     (si::*load-types* ~S))\
+						(compiler::emit-fn t))\
+					(load \"$(OUT)/makedep.lisp\")\
+					(gbc t)\
+					(when si::*binary-modules*\
+						(error (apply (quote concatenate) (quote string) \"Binary module load error: \" si::*binary-modules*)))\
+					(setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+					(gbc t)\
+					(fmakunbound (quote si::sgc-on))(when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+					(setq compiler::*default-system-p* t)\
+				" si::*system-directory* (quote (list ".lsp")))\
+				""\
+				nil))' | sed 's,\\$$,,g' | ${LISPSYS})
 @
 \end{verbatim}
 
@@ -697,7 +717,7 @@
 #	@ cp -p ${SRC}/doc/msgs/co-eng.msgs ${SPAD}/doc/msgs
 	@ echo '${PROCLAIMS}' > ${OUT}/makeint.lisp
 	@ echo '(load "${OUT}/nocompil")' >> ${OUT}/makeint.lisp
-	@ echo '(load "${OUT}/bookvol5")' >> ${OUT}/makeint.lisp
+	@ echo '(load "${OUT}/bookvol5.lsp")' >> ${OUT}/makeint.lisp
 	@ echo '(load "${OUT}/util")' >> ${OUT}/makeint.lisp
 	@ echo '(in-package "BOOT")' >> ${OUT}/makeint.lisp
 	@ touch ${TIMESTAMP}
@@ -728,8 +748,33 @@
 	@ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' \
                >> ${OUT}/makeint.lisp
 	@ (cd ${OBJ}/${SYS}/bin ; \
-	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp")' \
-                 '(gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+	  echo '#+native-reloc(progn (gbc t) (setq x si::*system-directory*)(load "${OUT}/makeint.lisp") (setq si::*system-directory* x) (unintern (quote x))(gbc t)(user::spad-save "${SAVESYS}"))#-native-reloc(progn\
+			(setq si::*collect-binary-modules* t)\
+			(setq x si::*system-directory*)\
+			(load "${OUT}/makeint.lisp")\
+			(setq si::*system-directory* x)\
+			(unintern (quote x))\
+			(compiler::link\
+				(remove-duplicates si::*binary-modules* :test (quote equal))\
+				"$(SAVESYS)"\
+				(format nil "\
+					(let ((si::*load-path* (cons ~S si::*load-path*))\
+                                             (si::*load-types* ~S))\
+						(compiler::emit-fn t))\
+					 (setq si::*collect-binary-modules* t)\
+					 (setq x si::*system-directory*)\
+					 (load \"$(OUT)/makeint.lisp\")\
+					 (setq si::*system-directory* x)\
+					 (unintern (quote x))\
+					 (when si::*binary-modules*\
+						(error (apply (quote concatenate) (quote string) \"Binary module load error: \" si::*binary-modules*)))\
+					(setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+					(gbc t)\
+					(fmakunbound (quote si::sgc-on))(when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+					(setq compiler::*default-system-p* t)\
+				" si::*system-directory* (quote (list ".lsp")))\
+			"$(OBJ)/$(SYS)/lib/sockio-c.o $(OBJ)/$(SYS)/lib/cfuns-c.o $(OBJ)/$(SYS)/lib/libspad.a" \
+			nil))' | sed 's,\\$$,,g' | $(LISPSYS))
 	@ echo 6 ${SAVESYS} created
 	@ cp ${SAVESYS} ${AXIOMSYS}
 	@ echo 6a ${AXIOMSYS} created
--- ./src/etc/Makefile.pamphlet.orig	2010-01-04 15:26:34.000000000 +0000
+++ ./src/etc/Makefile.pamphlet	2010-01-04 14:55:31.000000000 +0000
@@ -24,7 +24,7 @@
 	@ cp ${SRC}/doc/topics.data ${INT}/algebra
 	@ cp ${SRC}/doc/topics.data ${INT}/algebra
 	@ (cd ${INT}/algebra ; \
-           echo ')lisp (make-databases "" nil)' | ${INTERPSYS} )
+           echo ')lisp #+native-reloc(make-databases "" nil) #-native-reloc(system "cp ${SRC}/../debian/*.daase ${INT}/algebra/")' | ${INTERPSYS} )
 	@ cp -pr ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra
 
 @
=============================================================================

> Do you know if GCL will build on a MAC? I used to have a MAC port
> working but
> something broke and I cannot figure out what.
>

It should, but our chief developer on this platform has disappeared,
and I have not tested here in quite a while.  It would be very good to
refresh this.

\start
Date: Wed, 13 Jan 2010 14:23:54 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: Debian ports

Camm, the URL shown below is partially specific to your system
If you build axiom with the shell variable 

    $AXIOM=/home/axiom/mnt/ubuntu

then the URL will work as shown (assuming you build on ubuntu).
If you build on, say, a fedora10 system with the shell variable

    $AXIOM=/home/camm/mnt/fedora10

the URL would be:

http://127.0.0.1:8085/home/camm/mnt/fedora10/doc/hypertex/rootpage.xhtml

That is, you have to specify the complete path to the file rootpage.xhtml
(which will naturally have the $AXIOM prefix you used).

>From the top level you type ")browse" and Axiom will now function as a
web server on
the port (8085). At the moment you need to give a full path to the
root page thus:

http://127.0.0.1:8085/home/axiom/mnt/ubuntu/doc/hypertex/rootpage.xhtml

Try Topics -> Numbers -> Integers -> x:=factorial(200) as an example.
You should see the result of the computation pasted inline in the webpage.

This should be easier and automatic but I have to write that code and
I have not.

Alas my browser is hanging on the above url, so something needs
fixing.  I don't even get to read-char-no-hang:

(1) -> )lisp (trace read-char-no-hang)

Warning: READ-CHAR-NO-HANG is being redefined.
Value = (READ-CHAR-NO-HANG)
(1) -> )browse
listening on port 8085
 .....

Debugging suggestions?

\start
Date: Wed, 13 Jan 2010 14:30:55 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: Debian ports

Camm,

The file "exposed" sets 3 global variables
 |$globalExposureGroupAlist|
 |$localExposureDataDefault|
 |$localExposureData|

These are static, hand-maintained alists.

I have no idea why they are loaded multiple times.
They do not need to be. I will look into it.



OK, but for now, if we want ia64, mips, mipsel, alpha, and hppa ports
(which maybe we don't), I need to get the interpsys build to load all
binary modules just once.  As I said before, things apparently work by
changing the bookvol5 load at the top of makeint.lisp to a .lsp load
as far as this file goes.  But there is alas something else that is
loading (autoloading?) the following file three times:

Error: Binary module load error:
 /home/camm/axiom-20091101/mnt/linux/algebra/exposed.o

Can you help here?  Can I use the same trick to load the first two
instances in .lsp form?

\start
Date: Wed, 13 Jan 2010 14:48:46 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: Debian ports

Odd thing is, if I go into int/interp, fireup
../../obj/linux/bin/lisp, and execute

(progn
			(setq si::*collect-binary-modules* t)
			(setq x si::*system-directory*)
			(load "../../obj/linux/interp/makeint.lisp")
			(setq si::*system-directory* x)
			(unintern (quote x))
			(compiler::link
				(remove-duplicates si::*binary-modules* :test (quote equal) :from-end t)
				"interpsys"
				(format nil "
					(let ((si::*load-path* (cons ~S si::*load-path*))
                                             (si::*load-types* ~S))
						(compiler::emit-fn t))
					 (setq si::*collect-binary-modules* t)
					 (setq x si::*system-directory*)
					 (load \"../../obj/linux/interp/makeint.lisp\")
					 (setq si::*system-directory* x)
					 (unintern (quote x))
					 (when si::*binary-modules*
						(error (apply (quote concatenate) (quote string) \"Binary module load error: \" si::*binary-modules*)))
					(setq si::collect-binary-modules* nil si::*binary-modules* nil)
					(gbc t)
					(fmakunbound (quote si::sgc-on))(when (fboundp (quote si::sgc-on)) (si::sgc-on t))
					(setq compiler::*default-system-p* t)
				" si::*system-directory* (quote (list ".lsp")))
			"../../obj/linux/lib/sockio-c.o ../../obj/linux/lib/cfuns-c.o ../../obj/linux/lib/libspad.a" 
			nil))

I get a perfectly fine interpsys which will finish the build, with no
exposed.o loaded at all.  Yes this same command in the
src/interp/Makefile.pamphlet autoloads exposed.o 3 times.
Puzzled.....

Take care,


Tim Daly writes:

> Camm,
>
> Good to hear from you. Sorry for the delay. I was off at a conference all
> of last week.
>
> 1) I've apparently fixed the issue with the non-native-reloc ports, at
> least temporarily, by loading bookvol5 in makeint.lisp as a .lsp the
> first time.  I provide more detail later if desired.
>
>
>
> 1) The bookvol5 file is eventually going to be the full interpreter. I am
> moving all of the code (slowly and carefully) into that file. At the moment
> only some of the macros have been moved. These macros need to be
> in the compile environment so bookvol5 has to be loaded to pick up the
> moved macros. This file also needs to be compiled and loaded later
> since there are some functions that are currently defined in other files.
>
> This is a temporary situation. I am "tree-shaking" the whole interpreter
> so that I only pick up functions that are actually used. I have thrown away
> piles of code that can never be referenced. There are still well over 100
> files to process so the tree-shaking will probably take the rest of
> the year.
> However, once the interpreter is isolated there will only be one literate
> file that contains everything.
>
> 2) I've just committed to the 2.6.8pre branch socket code which I hope
> will obviate the need for your recent read.d patch regarding
> read-char-no-hang.  I really think the current behavior is correct,
> though I could of course be overlooking something.  Newlines are read
> and returned.  The old implementation, among other things, returned
> 'eof for (read-char-no-hang *standard-input* nil 'eof)<Return>. 
>
> I think you are rolling your own socket code, but I've been testing
> briefly with this:
>
>
> I don't want my own socket code but I was unable to get the behavior I
> needed to
> implement using Axiom as a web server. I will pick up your latest
> release and do a
> build and test using it. I'm more than happy to use an unpatched lisp.
>
>>
>>
>> 3) I don't really know how to test or use )browse at the moment.  And
>> I have forgotten how to escape to the lisp propmt, (as opposed to one
>> command at a time )lisp)
>>   
>
> From the top level you can drop into lisp using ")fin" and you can
> return to Axiom
> from lisp using "(restart)" You can also do ")lisp (setq $dalymode t)"
> which will
> cause Axiom to interpret any expression that starts with an open-paren
> as lisp thus:
>
>  )lisp (setq $dalymode t)
>  (+ 1 1) => 2
>
>
>
> From the top level you type ")browse" and Axiom will now function as a
> web server on
> the port (8085). At the moment you need to give a full path to the
> root page thus:
>
> http://127.0.0.1:8085/home/axiom/mnt/ubuntu/doc/hypertex/rootpage.xhtml
>
> Try Topics -> Numbers -> Integers -> x:=factorial(200) as an example.
> You should see the result of the computation pasted inline in the webpage.
>
> This should be easier and automatic but I have to write that code and
> I have not.
>
>
>
>> 4) It would be great to integrate the compiler::link patches for now
>> at least.  At some point I hope to have native object relocation
>> everywhere, but this is likely a ways off.
>>
>> Note I'm turning off sgc for now, but this should not be permanent.
>>
>>   
> I have not used the compiler::link patch because I didn't understand
> it and could not get
> it to work.. I will rewrite the makefile to use your changes and see
> if I can get it to work.
>
> Do you know if GCL will build on a MAC? I used to have a MAC port
> working but
> something broke and I cannot figure out what.

\start
Date: Wed, 13 Jan 2010 14:58:42 -0500
From: Camm Maguire
To: Tim Daly
Subject: re: Debian ports

Thanks Tim!  But it still hangs just as before.  What else can I
trace to see where I'm stuck?

Take care,

Tim Daly writes:

> Camm, the URL shown below is partially specific to your system
> If you build axiom with the shell variable 
>
>    $AXIOM=/home/axiom/mnt/ubuntu
>
> then the URL will work as shown (assuming you build on ubuntu).
> If you build on, say, a fedora10 system with the shell variable
>
>    $AXIOM=/home/camm/mnt/fedora10
>
> the URL would be:
>
> http://127.0.0.1:8085/home/camm/mnt/fedora10/doc/hypertex/rootpage.xhtml
>
> That is, you have to specify the complete path to the file rootpage.xhtml
> (which will naturally have the $AXIOM prefix you used).

>
>>From the top level you type ")browse" and Axiom will now function as a
> web server on
> the port (8085). At the moment you need to give a full path to the
> root page thus:
>
> http://127.0.0.1:8085/home/axiom/mnt/ubuntu/doc/hypertex/rootpage.xhtml
>
> Try Topics -> Numbers -> Integers -> x:=factorial(200) as an example.
> You should see the result of the computation pasted inline in the webpage.
>
> This should be easier and automatic but I have to write that code and
> I have not.
>
>
>
>
> Thanks!
>
> Alas my browser is hanging on the above url, so something needs
> fixing.  I don't even get to read-char-no-hang:
>
> (1) -> )lisp (trace read-char-no-hang)
>
> Warning: READ-CHAR-NO-HANG is being redefined.
> Value = (READ-CHAR-NO-HANG)
> (1) -> )browse
> listening on port 8085
> .....
>
> Debugging suggestions?

\start
Date: Wed, 13 Jan 2010 15:17:12 -0500
From: Tim Daly
To: Camm Maguire
Subject: re: Debian ports

Does the URL
file:///home/camm/mnt/fedora10/doc/hypertex/rootpage.xhtml
work?

Camm Maguire wrote:
> Thanks Tim!  But it still hangs just as before.  What else can I
> trace to see where I'm stuck?
>
> Take care,
>
> Tim Daly writes:
>
>   
>> Camm, the URL shown below is partially specific to your system
>> If you build axiom with the shell variable 
>>
>>    $AXIOM=/home/axiom/mnt/ubuntu
>>
>> then the URL will work as shown (assuming you build on ubuntu).
>> If you build on, say, a fedora10 system with the shell variable
>>
>>    $AXIOM=/home/camm/mnt/fedora10
>>
>> the URL would be:
>>
>> http://127.0.0.1:8085/home/camm/mnt/fedora10/doc/hypertex/rootpage.xhtml
>>
>> That is, you have to specify the complete path to the file rootpage.xhtml
>> (which will naturally have the $AXIOM prefix you used).
>>
>> >From the top level you type ")browse" and Axiom will now function as a
>> web server on
>> the port (8085). At the moment you need to give a full path to the
>> root page thus:
>>
>> http://127.0.0.1:8085/home/axiom/mnt/ubuntu/doc/hypertex/rootpage.xhtml
>>
>> Try Topics -> Numbers -> Integers -> x:=factorial(200) as an example.
>> You should see the result of the computation pasted inline in the webpage.
>>
>> This should be easier and automatic but I have to write that code and
>> I have not.
>>
>>
>>
>>
>> Thanks!
>>
>> Alas my browser is hanging on the above url, so something needs
>> fixing.  I don't even get to read-char-no-hang:
>>
>> (1) -> )lisp (trace read-char-no-hang)
>>
>> Warning: READ-CHAR-NO-HANG is being redefined.
>> Value = (READ-CHAR-NO-HANG)
>> (1) -> )browse
>> listening on port 8085
>> .....
>>
>> Debugging suggestions?

\start
Date: Wed, 13 Jan 2010 23:27:34 +0300
From: Aleksej Saushev
To: list
Subject: Re: Debian ports

Camm Maguire writes:

> @@ -867,7 +867,7 @@
>  LISP=lisp
>  DAASE=${SRC}/share
>  # where the libXpm.a library lives
> -XLIB=/usr/X11R6/lib
> +XLIB=/usr/lib
>  <<GCLOPTS>>
>  <<SRCDIRS>>
>  PATCH=patch

You'd better stop doing such senseless things and do what the rest of
the world does: respect LDFLAGS and link dynamically.

This simplifies code much because you remove all these multiple
customizations.

It is hard to tell for sure, most likely you've broken FreeBSD support,
and Tim boasted that he supports FreeBSD.

\start
Date: Wed, 13 Jan 2010 15:29:48 -0500
From: Camm Maguire
To: Tim Daly
Subject: re: Debian ports

Tim Daly writes:

> Does the URL
> file:///home/camm/mnt/fedora10/doc/hypertex/rootpage.xhtml
> work?
>

Yes, but of course without the axiom respondign to requests.

The same url with http://127.0.0.1:8085/ put at the front looks like
it is connecting, but waits forever.  So the tcp port is open at
least. 

Take care,

>
> Camm Maguire wrote:
>> Thanks Tim!  But it still hangs just as before.  What else can I
>> trace to see where I'm stuck?
>>
>> Take care,
>>
>> Tim Daly writes:
>>
>>   
>>> Camm, the URL shown below is partially specific to your system
>>> If you build axiom with the shell variable 
>>>
>>>    $AXIOM=/home/axiom/mnt/ubuntu
>>>
>>> then the URL will work as shown (assuming you build on ubuntu).
>>> If you build on, say, a fedora10 system with the shell variable
>>>
>>>    $AXIOM=/home/camm/mnt/fedora10
>>>
>>> the URL would be:
>>>
>>> http://127.0.0.1:8085/home/camm/mnt/fedora10/doc/hypertex/rootpage.xhtml
>>>
>>> That is, you have to specify the complete path to the file rootpage.xhtml
>>> (which will naturally have the $AXIOM prefix you used).
>>>
>>> >From the top level you type ")browse" and Axiom will now function as a
>>> web server on
>>> the port (8085). At the moment you need to give a full path to the
>>> root page thus:
>>>
>>> http://127.0.0.1:8085/home/axiom/mnt/ubuntu/doc/hypertex/rootpage.xhtml
>>>
>>> Try Topics -> Numbers -> Integers -> x:=factorial(200) as an example.
>>> You should see the result of the computation pasted inline in the webpage.
>>>
>>> This should be easier and automatic but I have to write that code and
>>> I have not.
>>>
>>> Alas my browser is hanging on the above url, so something needs
>>> fixing.  I don't even get to read-char-no-hang:
>>>
>>> (1) -> )lisp (trace read-char-no-hang)
>>>
>>> Warning: READ-CHAR-NO-HANG is being redefined.
>>> Value = (READ-CHAR-NO-HANG)
>>> (1) -> )browse
>>> listening on port 8085
>>> .....
>>>
>>> Debugging suggestions?

\start
Date: Wed, 13 Jan 2010 15:33:00 -0500
From: Camm Maguire
To: Aleksej Saushev
Subject: re: Debian ports

Aleksej Saushev writes:

> Camm Maguire writes:
>
>> @@ -867,7 +867,7 @@
>>  LISP=lisp
>>  DAASE=${SRC}/share
>>  # where the libXpm.a library lives
>> -XLIB=/usr/X11R6/lib
>> +XLIB=/usr/lib
>>  <<GCLOPTS>>
>>  <<SRCDIRS>>
>>  PATCH=patch
>
> You'd better stop doing such senseless things and do what the rest of
> the world does: respect LDFLAGS and link dynamically.
>

Agreed.  I don't know what this variable is used for, only that it
broke the Debian build a long time ago.

> This simplifies code much because you remove all these multiple
> customizations.
>

Agreed.

> It is hard to tell for sure, most likely you've broken FreeBSD support,
> and Tim boasted that he supports FreeBSD.
>

This is a Debian only patch, so no worries.

\start
Date: Wed, 13 Jan 2010 16:06:59 -0500
From: Camm Maguire
To: Tim Daly
Subject: re: Debian ports

Greetings!  Regarding the compiler link issue, this seems to be
working so far.  I don't know how to stop the autoloader, so I move
the file out of the way and link it in by hand:

=============================================================================
--- ./lsp/Makefile.pamphlet.orig	2010-01-04 16:45:15.000000000 +0000
+++ ./lsp/Makefile.pamphlet	2010-01-04 16:46:18.000000000 +0000
@@ -1161,12 +1161,8 @@
 
 gcldir: 
 	@echo 2 building ${GCLVERSION}
-	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
-<<gcl-2.6.8pre.socket.patch>>
-<<gcl-2.6.8pre.libspad.patch>>
-<<gcl-2.6.8pre.toploop.patch>>
-<<gcl-2.6.8pre.collectfn.fix>>
-<<gclConfigureMake>>
+#	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
+	echo '(compiler::link (list (compile-file "${BOOKS}/tangle.lisp")) "${OUT}/lisp" (format nil "(progn (let ((*load-path* (cons ~S *load-path*))(si::*load-types* ~S)) (compiler::emit-fn t))(fmakunbound (quote si::sgc-on))(when (fboundp (quote si::sgc-on)) (si::sgc-on t))#-native-reloc(setq compiler::*default-system-p* t))" si::*system-directory* (quote (list #+native-reloc".o" ".lsp"))) "${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o ${OBJ}/${SYS}/lib/libspad.a")' | gcl
 	@echo 13 finished system build on `date` | tee >gcldir
 
 ccldir: ${LSP}/ccl/Makefile
--- ./src/interp/Makefile.pamphlet.orig	2009-11-30 09:45:01.000000000 -0700
+++ ./src/interp/Makefile.pamphlet	2010-01-13 13:58:50.000000000 -0700
@@ -419,15 +419,40 @@
 
 \subsection{save depsys image}
 Once the appropriate commands are in the [[${OUT}/makedep.lisp]] file
-we can load the file into a fresh image and save it. At least that's
+we can load the file into a fresh image and save it. At least that is
 how it used to work. In freebsd we cannot do this so we have to use
 a much more complicated procedure.
 This code used to read:
 \begin{verbatim}
 <<save depsys image>>=
 	@ (cd ${MNT}/${SYS}/bin ; \
-	   echo '(progn (load "${OUT}/makedep.lisp")' \
-                '(spad-save "${DEPSYS}"))' | ${LISPSYS})
+	   echo '#+native-reloc(progn\
+		    (load "${OUT}/makedep.lisp")\
+		    (spad-save "${DEPSYS}"))\
+		 #-native-reloc(progn\
+		    (setq si::*collect-binary-modules* t)\
+		    (load "${OUT}/makedep.lisp")\
+		    (compiler::link\
+			(remove-duplicates si::*binary-modules* :test (quote equal))\
+			"$(DEPSYS)"\
+			(format nil "\
+				(setq si::*collect-binary-modules* t)\
+				(let ((si::*load-path* (cons ~S si::*load-path*))\
+	                              (si::*load-types* ~S))\
+				  (compiler::emit-fn t))\
+				  (load \"$(OUT)/makedep.lisp\")\
+				  (gbc t)\
+				  (when si::*binary-modules*\
+					(error (apply (quote concatenate) (quote string)\
+					 \"Binary module load error: \" si::*binary-modules*)))\
+				  (setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+				  (gbc t)\
+				  (fmakunbound (quote si::sgc-on))\
+				  (when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+				  (setq compiler::*default-system-p* t)"\
+				si::*system-directory* (quote (list ".lsp")))\
+				""\
+				nil))' | sed 's,\\$$,,g' | ${LISPSYS})
 @
 \end{verbatim}
 
@@ -697,7 +722,7 @@
 #	@ cp -p ${SRC}/doc/msgs/co-eng.msgs ${SPAD}/doc/msgs
 	@ echo '${PROCLAIMS}' > ${OUT}/makeint.lisp
 	@ echo '(load "${OUT}/nocompil")' >> ${OUT}/makeint.lisp
-	@ echo '(load "${OUT}/bookvol5")' >> ${OUT}/makeint.lisp
+	@ echo '(load "${OUT}/bookvol5.lsp")' >> ${OUT}/makeint.lisp
 	@ echo '(load "${OUT}/util")' >> ${OUT}/makeint.lisp
 	@ echo '(in-package "BOOT")' >> ${OUT}/makeint.lisp
 	@ touch ${TIMESTAMP}
@@ -727,9 +752,47 @@
 	@ echo '#+:akcl (si::gbc-time 0)' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' \
                >> ${OUT}/makeint.lisp
-	@ (cd ${OBJ}/${SYS}/bin ; \
-	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp")' \
-                 '(gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+	@ (cd ${OBJ}/${SYS}/bin ;\
+	   mv ${OUT}/../../../mnt/linux/algebra/exposed.o ${OUT}/../../../mnt/linux/algebra/exposed1.o;\
+	   echo '#+native-reloc(progn \
+	       	      (gbc t)\
+		      (setq x si::*system-directory*)\
+		      (load "${OUT}/makeint.lisp")\
+		      (setq si::*system-directory* x)\
+		      (unintern (quote x))\
+		      (gbc t)\
+		      (user::spad-save "${SAVESYS}"))\
+	        #-native-reloc(progn\
+		      (setq si::*collect-binary-modules* t)\
+		      (setq x si::*system-directory*)\
+		      (load "${OUT}/makeint.lisp")\
+		      (setq si::*system-directory* x)\
+		      (unintern (quote x))\
+                      (push "${OUT}/../../../mnt/linux/algebra/exposed1.o" si::*binary-modules*)\
+		      (compiler::link\
+			(remove-duplicates si::*binary-modules* :test (quote equal))\
+			"$(SAVESYS)"\
+			(format nil "\
+				(let ((si::*load-path* (cons ~S si::*load-path*))\
+                                      (si::*load-types* ~S))\
+				 (compiler::emit-fn t))\
+				 (setq si::*collect-binary-modules* t)\
+				 (setq x si::*system-directory*)\
+				 (load \"$(OUT)/makeint.lisp\")\
+				 (setq si::*system-directory* x)\
+				 (unintern (quote x))\
+				 (when si::*binary-modules*\
+					(error (apply (quote concatenate) (quote string)\
+					 \"Binary module load error: \" si::*binary-modules*)))\
+				 (setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+				 (gbc t)\
+				 (fmakunbound (quote si::sgc-on))\
+				 (when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+				 (setq compiler::*default-system-p* t)"\
+			        si::*system-directory* (quote (list ".lsp")))\
+		        "$(OBJ)/$(SYS)/lib/sockio-c.o $(OBJ)/$(SYS)/lib/cfuns-c.o $(OBJ)/$(SYS)/lib/libspad.a"\
+		        nil))' | sed 's,\\$$,,g' | $(LISPSYS);\
+	   mv ${OUT}/../../../mnt/linux/algebra/exposed1.o ${OUT}/../../../mnt/linux/algebra/exposed.o)
 	@ echo 6 ${SAVESYS} created
 	@ cp ${SAVESYS} ${AXIOMSYS}
 	@ echo 6a ${AXIOMSYS} created
--- ./src/etc/Makefile.pamphlet.orig	2010-01-04 15:26:34.000000000 +0000
+++ ./src/etc/Makefile.pamphlet	2010-01-04 14:55:31.000000000 +0000
@@ -24,7 +24,7 @@
 	@ cp ${SRC}/doc/topics.data ${INT}/algebra
 	@ cp ${SRC}/doc/topics.data ${INT}/algebra
 	@ (cd ${INT}/algebra ; \
-           echo ')lisp (make-databases "" nil)' | ${INTERPSYS} )
+           echo ')lisp #+native-reloc(make-databases "" nil) #-native-reloc(system "cp ${SRC}/../debian/*.daase ${INT}/algebra/")' | ${INTERPSYS} )
 	@ cp -pr ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra
 
 @

\start
Date: Wed, 13 Jan 2010 17:21:55 -0500
From: Tim Daly
To: Camm Maguire
Subject: re: Debian ports

hmm...

In the zips directory there is a copy of GCL that builds cleanly.
Does this connect? Is there any change in the socket code
between the gcl tgz in the zips directory and your latest version?

Camm Maguire wrote:
> Greetings!
>
> Tim Daly writes:
>
>   
>> Does the URL
>> file:///home/camm/mnt/fedora10/doc/hypertex/rootpage.xhtml
>> work?
>>
>>     
>
> Yes, but of course without the axiom respondign to requests.
>
> The same url with http://127.0.0.1:8085/ put at the front looks like
> it is connecting, but waits forever.  So the tcp port is open at
> least. 
>
> Take care,
>
>   
>> Camm Maguire wrote:
>>     
>>> Thanks Tim!  But it still hangs just as before.  What else can I
>>> trace to see where I'm stuck?
>>>
>>> Take care,
>>>
>>> Tim Daly writes:
>>>
>>>   
>>>       
>>>> Camm, the URL shown below is partially specific to your system
>>>> If you build axiom with the shell variable 
>>>>
>>>>    $AXIOM=/home/axiom/mnt/ubuntu
>>>>
>>>> then the URL will work as shown (assuming you build on ubuntu).
>>>> If you build on, say, a fedora10 system with the shell variable
>>>>
>>>>    $AXIOM=/home/camm/mnt/fedora10
>>>>
>>>> the URL would be:
>>>>
>>>> http://127.0.0.1:8085/home/camm/mnt/fedora10/doc/hypertex/rootpage.xhtml
>>>>
>>>> That is, you have to specify the complete path to the file rootpage.xhtml
>>>> (which will naturally have the $AXIOM prefix you used).
>>>>
>>>> Tim
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> >From the top level you type ")browse" and Axiom will now function as a
>>>> web server on
>>>> the port (8085). At the moment you need to give a full path to the
>>>> root page thus:
>>>>
>>>> http://127.0.0.1:8085/home/axiom/mnt/ubuntu/doc/hypertex/rootpage.xhtml
>>>>
>>>> Try Topics -> Numbers -> Integers -> x:=factorial(200) as an example.
>>>> You should see the result of the computation pasted inline in the webpage.
>>>>
>>>> This should be easier and automatic but I have to write that code and
>>>> I have not.
>>>>
>>>> Alas my browser is hanging on the above url, so something needs
>>>> fixing.  I don't even get to read-char-no-hang:
>>>>
>>>> (1) -> )lisp (trace read-char-no-hang)
>>>>
>>>> Warning: READ-CHAR-NO-HANG is being redefined.
>>>> Value = (READ-CHAR-NO-HANG)
>>>> (1) -> )browse
>>>> listening on port 8085
>>>> .....
>>>>
>>>> Debugging suggestions?

\start
Date: Wed, 13 Jan 2010 17:26:42 -0500
From: Tim Daly
To: Aleksej Saushev
Subject: re: Debian ports

Please post a patch file that does what you suggest.
I was unable to build successfully using dynamic loading.

Aleksej Saushev wrote:
> Camm Maguire writes:
>
>   
>> @@ -867,7 +867,7 @@
>>  LISP=lisp
>>  DAASE=${SRC}/share
>>  # where the libXpm.a library lives
>> -XLIB=/usr/X11R6/lib
>> +XLIB=/usr/lib
>>  <<GCLOPTS>>
>>  <<SRCDIRS>>
>>  PATCH=patch
>>     
>
> You'd better stop doing such senseless things and do what the rest of
> the world does: respect LDFLAGS and link dynamically.
>
> This simplifies code much because you remove all these multiple
> customizations.
>
> It is hard to tell for sure, most likely you've broken FreeBSD support,
> and Tim boasted that he supports FreeBSD.

\start
Date: Wed, 13 Jan 2010 18:56:31 -0200 (BRST)
From: Paulo Andrade
To: Camm Maguire
Subject: Re: [Gcl-devel] re: Debian ports

Camm Maguire wrote:

  Hi,

  Sorry if it is off topic (currently I am not subscribed to
axiom-developer).

  I updated the mandriva gcl and axiom packages some time ago. You can
see the files at:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/axiom/current/

  What would be the proper way to setup a single script to start, or
open a tab in, firefox from axiom? That is run something like:
firefox -remote
'openURL(localhost:8085/usr/lib64/axiom-3.4/doc/hypertex/topicspage.xhtml=
)'
once the ')browse' command was run.

  Something like running 'notebook()' in sagemath, or the command line
option 'sage -notebook'

> Thanks Tim!  But it still hangs just as before.  What else can I
> trace to see where I'm stuck?
>
> Take care,
>
> Tim Daly writes:
>
>> Camm, the URL shown below is partially specific to your system
>> If you build axiom with the shell variable
>>
>>    $AXIOM=/home/axiom/mnt/ubuntu
>>
>> then the URL will work as shown (assuming you build on ubuntu).
>> If you build on, say, a fedora10 system with the shell variable
>>
>>    $AXIOM=/home/camm/mnt/fedora10
>>
>> the URL would be:
>>
>> http://127.0.0.1:8085/home/camm/mnt/fedora10/doc/hypertex/rootpage.xht=
ml
>>
>> That is, you have to specify the complete path to the file
>> rootpage.xhtml
>> (which will naturally have the $AXIOM prefix you used).
>>
>> Tim
>>
>>
>>
>>
>>
>>
>>>From the top level you type ")browse" and Axiom will now function as a
>> web server on
>> the port (8085). At the moment you need to give a full path to the
>> root page thus:
>>
>> http://127.0.0.1:8085/home/axiom/mnt/ubuntu/doc/hypertex/rootpage.xhtm=
l
>>
>> Try Topics -> Numbers -> Integers -> x:=factorial(200) as an example=
.
>> You should see the result of the computation pasted inline in the
>> webpage.
>>
>> This should be easier and automatic but I have to write that code and
>> I have not.
>>
>>
>>
>>
>> Thanks!
>>
>> Alas my browser is hanging on the above url, so something needs
>> fixing.  I don't even get to read-char-no-hang:
>>
>> (1) -> )lisp (trace read-char-no-hang)
>>
>> Warning: READ-CHAR-NO-HANG is being redefined.
>> Value = (READ-CHAR-NO-HANG)
>> (1) -> )browse
>> listening on port 8085
>> .....
>>
>> Debugging suggestions?

\start
Date: Fri, 15 Jan 2010 21:34:27 -0500
From: Camm Maguire
To: Tim Daly
Subject: re: Debian ports
Cc: Aleksej Saushev

One other issue is coming up.  You are resetting
si::*system-directory* in your restart function.  This is used in gcl
as distributed to find auxiliary files.  On most platforms, you don't
need any, so you don't notice this, but, again as currently
distributed, GCL can't find the cmpinclude.h file when you redirect
this variable.  I've got a work around for now, and this part of GCL
can certainly be made more foolproof, but my question is -- do you
need to set this variable?  Can't we let variables in the 'si package
be set by gcl?

Take care,

Tim Daly writes:

> Please post a patch file that does what you suggest.
> I was unable to build successfully using dynamic loading.
>
> Tim
>
>
> Aleksej Saushev wrote:
>> Camm Maguire writes:
>>
>>   
>>> @@ -867,7 +867,7 @@
>>>  LISP=lisp
>>>  DAASE=${SRC}/share
>>>  # where the libXpm.a library lives
>>> -XLIB=/usr/X11R6/lib
>>> +XLIB=/usr/lib
>>>  <<GCLOPTS>>
>>>  <<SRCDIRS>>
>>>  PATCH=patch
>>>     
>>
>> You'd better stop doing such senseless things and do what the rest of
>> the world does: respect LDFLAGS and link dynamically.
>>
>> This simplifies code much because you remove all these multiple
>> customizations.
>>
>> It is hard to tell for sure, most likely you've broken FreeBSD support,
>> and Tim boasted that he supports FreeBSD.

\start
Date: Fri, 15 Jan 2010 23:46:05 -0500
From: Tim Daly
To: Camm Maguire
Subject: re: Debian ports
Cc: Aleksej Saushev

I removed the line from restart and rebuilt/retested the system.
I can find no difference in behavior so Axiom will no longer set 
si::*system-directory*
This is available in the lastest patch. 20100115.03.tpd.patch
(git commit 509e5b024a)

Camm Maguire wrote:
> Hi Tim!
>
> One other issue is coming up.  You are resetting
> si::*system-directory* in your restart function.  This is used in gcl
> as distributed to find auxiliary files.  On most platforms, you don't
> need any, so you don't notice this, but, again as currently
> distributed, GCL can't find the cmpinclude.h file when you redirect
> this variable.  I've got a work around for now, and this part of GCL
> can certainly be made more foolproof, but my question is -- do you
> need to set this variable?  Can't we let variables in the 'si package
> be set by gcl?
>
> Take care,
>
> Tim Daly writes:
>
>   
>> Please post a patch file that does what you suggest.
>> I was unable to build successfully using dynamic loading.
>>
>> Tim
>>
>>
>> Aleksej Saushev wrote:
>>     
>>> Camm Maguire writes:
>>>
>>>   
>>>       
>>>> @@ -867,7 +867,7 @@
>>>>  LISP=lisp
>>>>  DAASE=${SRC}/share
>>>>  # where the libXpm.a library lives
>>>> -XLIB=/usr/X11R6/lib
>>>> +XLIB=/usr/lib
>>>>  <<GCLOPTS>>
>>>>  <<SRCDIRS>>
>>>>  PATCH=patch
>>>>     
>>>>         
>>> You'd better stop doing such senseless things and do what the rest of
>>> the world does: respect LDFLAGS and link dynamically.
>>>
>>> This simplifies code much because you remove all these multiple
>>> customizations.
>>>
>>> It is hard to tell for sure, most likely you've broken FreeBSD support,
>>> and Tim boasted that he supports FreeBSD.

\start
Date: Sat, 16 Jan 2010 15:06:35 -0500
From: Tim Daly
To: Camm Maguire
Subject: re: Debian ports
Cc: Aleksej Saushev

The latest patch removes the file exposed.lsp
so it no longer needs to be loaded at all.

\start
Date: Tue, 19 Jan 2010 16:26:47 -0500
From: Camm Maguire
To: Tim Daly
Subject: re: Debian ports
Cc: Aleksej Saushev

Greetings!  Tim, is there a machine at your site onto which you would
mind giving me access?  Perhaps I could set this up for you there.

Take care,

Tim Daly writes:

> Please post a patch file that does what you suggest.
> I was unable to build successfully using dynamic loading.
>
> Tim
>
>
> Aleksej Saushev wrote:
>> Camm Maguire writes:
>>
>>   
>>> @@ -867,7 +867,7 @@
>>>  LISP=lisp
>>>  DAASE=${SRC}/share
>>>  # where the libXpm.a library lives
>>> -XLIB=/usr/X11R6/lib
>>> +XLIB=/usr/lib
>>>  <<GCLOPTS>>
>>>  <<SRCDIRS>>
>>>  PATCH=patch
>>>     
>>
>> You'd better stop doing such senseless things and do what the rest of
>> the world does: respect LDFLAGS and link dynamically.
>>
>> This simplifies code much because you remove all these multiple
>> customizations.
>>
>> It is hard to tell for sure, most likely you've broken FreeBSD support,
>> and Tim boasted that he supports FreeBSD.

\start
Date: Sat, 23 Jan 2010 12:52:57 -0500
From: Tim Daly
To: list
Subject: Axiom January 2010 released

The Axiom Version January 2010 has been released to
the source code servers:

  from github:      git clone git://github.com/daly/axiom.git
  from savannah:    git clone axiom@git.sv.nongnu.org:/srv/git/axiom.git
  from sourceforge: |git clone 
git://axiom.git.sourceforge.net/gitroot/axiom/axiom|

(commit: 7aa4ca083d79f63bc46b0c21af41e9d79191f390)

Binaries will become available as time permits at:
http://axiom-developer.org/axiom-website/download.html

\start
Date: Fri, 29 Jan 2010 20:49:50 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: Axiom January 2010 released

Separate question -- I notice there are many regression failures in
the build log.  Do you have any mechanism to identify "expected"
failures?  Or is there any other automated way to ensure the
correctness of the build?  For example, with maxima, the autobuilder
is instructed to abort if there are any "unexpected" test suite
failures. 

Take care,

Tim Daly writes:

> The Axiom Version January 2010 has been released to
> the source code servers:
>
>  from github:      git clone git://github.com/daly/axiom.git
>  from savannah:    git clone axiom@git.sv.nongnu.org:/srv/git/axiom.git
>  from sourceforge: |git clone
> git://axiom.git.sourceforge.net/gitroot/axiom/axiom|
>
> (commit: 7aa4ca083d79f63bc46b0c21af41e9d79191f390)
>
> Binaries will become available as time permits at:
> http://axiom-developer.org/axiom-website/download.html

\start
Date: Sat, 30 Jan 2010 10:12:21 +0000
From: Martin Baker
To: list
Subject: html formatter

I have created a html formatter: html.spad.pamphlet
and made it available here:

http://github.com/martinbaker/multivector/

I have put more information and test results here:
http://www.euclideanspace.com/maths/standards/program/output/

If you think it is useful to others you are most welcome to add it to the 
codebase.

\start
Date: Sat, 30 Jan 2010 08:36:16 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: Axiom January 2010 released

There are failures in the build log but they are mostly expected failures.
They are designed to test deliberately failing cases.

The design of the regression test system is that you create an input file,
capture the output, and append it after the command with a prefix.

So

1+1

in an input file generates

  (1) 2
                  Type: PositiveInteger

Now you construct an input file that has some special comments
around this test case (see any file in src/input/*.input.pamphlet):

--S 1 of 32
1+1
--R  (1) 2
--R                Type: PositiveInteger
--E 1

Since anything with "--" is an axiom comment almost all of the lines
are ignored when the file is read. If you read the file and spool the
output you will see:

--S 1 of 32                                     <-- the testcase number
1+1                                             <-- the axiom input
                                                <-- the actual output
  (1) 2                                         <--
                  Type: PositiveInteger         <--
--R                                             <-- the expected output
--R  (1) 2                                      <--
--R                Type: PositiveInteger        <--
--E 1                                           <-- end of this testcase

We see the input (1+1) and the Axiom output. We also have comments that show
the expected Axiom output. There is a function called "regress" which 
will take this spool
output file (say, foo.output") and compare the actual Axiom output from 
the expected Axiom
output.

 )lisp (regress "foo.output")

It lists the successful and the failing test cases (look in 
int/input/*.regress)

At the very end of the build Axiom scans the regress files looking for 
any that fail.
Some can fail due to the fact that the algorithm is random. Others fail 
for various
reasons. I check these failure cases after every Axiom build.

Any failures either get fixed in the next update or get added to the 
known bugs list.

So, to answer your question, there are cases where the Axiom input fails 
intentionally
and the failing output is captured. This way it is possible to test 
known bad inputs.
The regression test system only cares that the answers are the same, it 
does not care
that the Axiom input is a known, intentional failure.

Thus, the regression test system can test both successful and failing 
input but will
only complain if some output did not match the previous results.

Tim


Camm Maguire wrote:
> Congratulations, Tim!
>
> Separate question -- I notice there are many regression failures in
> the build log.  Do you have any mechanism to identify "expected"
> failures?  Or is there any other automated way to ensure the
> correctness of the build?  For example, with maxima, the autobuilder
> is instructed to abort if there are any "unexpected" test suite
> failures. 
>
> Take care,
>
> Tim Daly writes:
>
>   
>> The Axiom Version January 2010 has been released to
>> the source code servers:
>>
>>  from github:      git clone git://github.com/daly/axiom.git
>>  from savannah:    git clone axiom@git.sv.nongnu.org:/srv/git/axiom.git
>>  from sourceforge: |git clone
>> git://axiom.git.sourceforge.net/gitroot/axiom/axiom|
>>
>> (commit: 7aa4ca083d79f63bc46b0c21af41e9d79191f390)
>>
>> Binaries will become available as time permits at:
>> http://axiom-developer.org/axiom-website/download.html

\start
Date: Sat, 30 Jan 2010 08:37:16 -0500
From: Tim Daly
To: list
Subject: Axiom January 2010 binaries are available

The binaries are available at:
http://axiom-developer.org/axiom-website/download.html

\start
Date: Sat, 30 Jan 2010 08:41:09 -0500
From: Tim Daly
To: Martin Baker
Subject: Re: html formatter

Very nice. I'll look into this further.

Are you aware of the work in Axiom Volume 11: The Axiom Browser?
It uses mathml for mathematics display.

Tim

Martin Baker wrote:
> I have created a html formatter: html.spad.pamphlet
> and made it available here:
>
> http://github.com/martinbaker/multivector/
>
> I have put more information and test results here:
> http://www.euclideanspace.com/maths/standards/program/output/
>
> If you think it is useful to others you are most welcome to add it to the 
> codebase.
>
> Martin Baker

\start
Date: Sat, 30 Jan 2010 09:47:39 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: Axiom January 2010 released

Tim Daly writes:

...

> At the very end of the build Axiom scans the regress files looking for
> any that fail.
> Some can fail due to the fact that the algorithm is random. Others
> fail for various
> reasons. I check these failure cases after every Axiom build.
>
> Any failures either get fixed in the next update or get added to the
> known bugs list.
>
> So, to answer your question, there are cases where the Axiom input
> fails intentionally
> and the failing output is captured. This way it is possible to test
> known bad inputs.
> The regression test system only cares that the answers are the same,
> it does not care
> that the Axiom input is a known, intentional failure.
>
> Thus, the regression test system can test both successful and failing
> input but will
> only complain if some output did not match the previous results.
>

Do I understand correctly, then, that as some failures are random, and
will therefore are expected to produce differences with previous
output, there is no way to really catch a case, say, where gcl is
blowing the algorithm on a new platform?  If so, a wishlist item would
be to add some flag that would indicate an expected stochastic
failure.  Then an autobuilder could be instructed to demand strict
compliance with some known output, or fail.

Take care,

> Tim
>
>
> Camm Maguire wrote:
>> Congratulations, Tim!
>>
>> Separate question -- I notice there are many regression failures in
>> the build log.  Do you have any mechanism to identify "expected"
>> failures?  Or is there any other automated way to ensure the
>> correctness of the build?  For example, with maxima, the autobuilder
>> is instructed to abort if there are any "unexpected" test suite
>> failures. 
>>
>> Take care,
>>
>> Tim Daly writes:
>>
>>   
>>> The Axiom Version January 2010 has been released to
>>> the source code servers:
>>>
>>>  from github:      git clone git://github.com/daly/axiom.git
>>>  from savannah:    git clone axiom@git.sv.nongnu.org:/srv/git/axiom.git
>>>  from sourceforge: |git clone
>>> git://axiom.git.sourceforge.net/gitroot/axiom/axiom|
>>>
>>> (commit: 7aa4ca083d79f63bc46b0c21af41e9d79191f390)
>>>
>>> Binaries will become available as time permits at:
>>> http://axiom-developer.org/axiom-website/download.html
>>>
>>> Tim
>>>
>>>
>>> _______________________________________________
>>> Axiom-developer mailing list
>>> list
>>> http://lists.nongnu.org/mailman/listinfo/axiom-developer

\start
Date: Sat, 30 Jan 2010 16:18:50 +0000
From: Martin Baker
To: Tim Daly
Subject: Re: html formatter

On Saturday 30 Jan 2010 13:41:09 Tim Daly wrote:
> Are you aware of the work in Axiom Volume 11: The Axiom Browser?
> It uses mathml for mathematics display.
 
Tim,

I did come across it although I did not fully take it in at the time, so much 
to learn when first looking at the Axiom documentation. The documentation 
probably needs a bit more overview at the start of volume 11 before jumping 
into build instructions so that newcomers can see what its all about.

It does seem a very nice idea, using the browser for what it is good at and 
use Axiom for doing the maths. Is this is what provides calculations for the 
Axiom wiki? It would be a good way to show new users the advantages of Axiom 
if there were a page where they could type in a formula ,or sequence of axiom 
commands, and see the result immediately on the web page.

Looking at the dates it looks like development on this stopped around 2007, so 
I guess interest must have declined, which seems a pity. 

Using the command line interpreter has pros and cons, I wonder if this could 
be a way to overcome the cons, for instance: allowing the user to enter 
mathematical symbols such as the Greek alphabet directly into the formula 
using buttons on the web page?

\start
Date: Sat, 30 Jan 2010 19:16:41 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: Axiom January 2010 released

Some of the algorithms are purely random so the result
has nothing to do with GCL.

Actually, there is behavior in floating point that differs
from platform to platform. Run
  grep machineFraction src/input/*

The floating point behavior differs from platform to platform.
I wrote 'machineFraction' to get at the actual bits in the
register (it uses common lisp's integer-decode-float, see
the code in books/bookvol5.pamphlet, e.g. integer-decode-float-numerator)

In src/input/dfloat.input.pamphlet you can see that

machineFraction(2.71828)

is not equal to

machineFraction(2.71828@DoubleFloat)

on Ubuntu, but they are equal on some other linux platforms.
They should be equal.

Why these differ is on the list to debug.

Camm Maguire wrote:
> Greetings, and thanks!
>
> Tim Daly writes:
>
> ...
>
>   
>> At the very end of the build Axiom scans the regress files looking for
>> any that fail.
>> Some can fail due to the fact that the algorithm is random. Others
>> fail for various
>> reasons. I check these failure cases after every Axiom build.
>>
>> Any failures either get fixed in the next update or get added to the
>> known bugs list.
>>
>> So, to answer your question, there are cases where the Axiom input
>> fails intentionally
>> and the failing output is captured. This way it is possible to test
>> known bad inputs.
>> The regression test system only cares that the answers are the same,
>> it does not care
>> that the Axiom input is a known, intentional failure.
>>
>> Thus, the regression test system can test both successful and failing
>> input but will
>> only complain if some output did not match the previous results.
>>
>>     
>
> Do I understand correctly, then, that as some failures are random, and
> will therefore are expected to produce differences with previous
> output, there is no way to really catch a case, say, where gcl is
> blowing the algorithm on a new platform?  If so, a wishlist item would
> be to add some flag that would indicate an expected stochastic
> failure.  Then an autobuilder could be instructed to demand strict
> compliance with some known output, or fail.
>
> Take care,
>
>   
>> Tim
>>
>>
>> Camm Maguire wrote:
>>     
>>> Congratulations, Tim!
>>>
>>> Separate question -- I notice there are many regression failures in
>>> the build log.  Do you have any mechanism to identify "expected"
>>> failures?  Or is there any other automated way to ensure the
>>> correctness of the build?  For example, with maxima, the autobuilder
>>> is instructed to abort if there are any "unexpected" test suite
>>> failures. 
>>>
>>> Take care,
>>>
>>> Tim Daly writes:
>>>
>>>   
>>>       
>>>> The Axiom Version January 2010 has been released to
>>>> the source code servers:
>>>>
>>>>  from github:      git clone git://github.com/daly/axiom.git
>>>>  from savannah:    git clone axiom@git.sv.nongnu.org:/srv/git/axiom.git
>>>>  from sourceforge: |git clone
>>>> git://axiom.git.sourceforge.net/gitroot/axiom/axiom|
>>>>
>>>> (commit: 7aa4ca083d79f63bc46b0c21af41e9d79191f390)
>>>>
>>>> Binaries will become available as time permits at:
>>>> http://axiom-developer.org/axiom-website/download.html

\start
Date: Sat, 30 Jan 2010 19:36:23 -0500
From: Tim Daly
To: Martin Baker
Subject: Re: html formatter

Martin Baker wrote:
> On Saturday 30 Jan 2010 13:41:09 Tim Daly wrote:
>   
>> Are you aware of the work in Axiom Volume 11: The Axiom Browser?
>> It uses mathml for mathematics display.
>>     
>  
> Tim,
>
> I did come across it although I did not fully take it in at the time, so much 
> to learn when first looking at the Axiom documentation. The documentation 
> probably needs a bit more overview at the start of volume 11 before jumping 
> into build instructions so that newcomers can see what its all about.
>   

At the moment all of the energy is going into moving the source code 
from the
tree-of-tiny-files format into books. It takes a while to move a 
million-things-of-code,
along with rewrites and refactoring. I'm into the final stretch though 
as I only have to
consolidate the interpreter and compiler. I hope to have it finished by 
the end of the year.

Once that happens I will revisit each book with an eye to writing decent 
documentation
See the book Lisp In Small Pieces for the ultimate goal I hope to 
achieve. The books
only contain the source code for the most part. There will be much more 
once I get rid
of the 1960s-PDP-11-64K-sea-of-tiny-little-files organization.
> It does seem a very nice idea, using the browser for what it is good at and 
> use Axiom for doing the maths. Is this is what provides calculations for the 
> Axiom wiki? It would be a good way to show new users the advantages of Axiom 
> if there were a page where they could type in a formula ,or sequence of axiom 
> commands, and see the result immediately on the web page.
>   
Actually when you run the browser from the Axiom command line you can 
input expressions
into the browser and the computed result will open up a <DIV> in your 
browser with the results.
This works now. All of the Javascript/AJAX/mathml/axiom-interpreter code 
works so it is
easy to add new pages. Once I got a proof of concept working I went back 
to building up
the other books.

Arthur Ralfs is the person to credit for the mathml connection.

More of the hyperdoc pages have to be converted and there are plans for 
deeper documentation
in the browser format. The browser form already contains pages which are 
not in hyperdoc.
There are newly written pages and code examples from the NIST Digital 
Library of Mathematical Functions.
There are other pieces of work stacked up  to put into the Axiom 
browser. We really want
to support the bra and ket notation from quantum theory. (I've been 
playing with that for a
while and it would be nice if Axiom supported it better.)

> Looking at the dates it looks like development on this stopped around 2007, so 
> I guess interest must have declined, which seems a pity. 
>
> Using the command line interpreter has pros and cons, I wonder if this could 
> be a way to overcome the cons, for instance: allowing the user to enter 
> mathematical symbols such as the Greek alphabet directly into the formula 
> using buttons on the web page?
>   

The browser will certainly support unicode I/O. The question would be 
whether the lisp
system will support unicode, which would be nice because then you could 
input/output
symbols like sigma as though it were any other character. Since Axiom is 
listening on
the host end it can interpret unicode any way it likes.
> Martin Baker
>
>   
Tim



