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

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Fri, 01 Sep 2006 02:26:45 -0400
From: William Sit
To: Bill Page
Subject: Re: obsolete pages and portal download

Bill Page wrote:
> 
> On August 31, 2006 6:11 PM William Sit wrote:
> >
> > Is there any info that is still useful on
> > http://page.axiom-developer.org?
> 
> No, I don't think so. This was my original "personal home page"
> on the axiom-developer site. In addition to the wiki and the
> portal, anyone who has an account directly on the axiom-developer
> server also has such a web page. These are only editable when
> you are directly logged in to the server.

I see. I had always thought that was the main axiom-developer page.
 
> > Can some of these pages be deleted (or made unreadable by
> > the public)?
> 
> Yes. Should I delete it, have it automatically re-direct to
> http://wiki.axiom-developer.org or maybe take the time to
> actually make it more "personal"? What do yo think?

Since this is your personal page, it would be up to you to decide
whether to delete it or redirect it. But as far as the Axiom public is
concerned, it would be less confusing if the headers of those pages say
clearly it is your personal home page and that you provide links to the
"official" Wiki site. Then if someone stumbles onto your page through
searches, they would be directed to the right info place.

Non-historic and obsolete stuff should be deleted, even on your personal
page (IMHO).
 
> See also for example Tim's personal page at:
> 
> http://daly.axiom-developer.org

At least he shows his picture with his big name prominent. So everyone
knows it is a personal web site.

> Of course anyone who wishes to could also construct such a
> "personal page" on the Axiom wiki or Axiom portal sites without
> any special access to the server.

Yes, but it should be clear it is a personal page.
 
[...]
> > Just a random comment from random browsing.
> 
> Thanks for reviewing this.
> 
> > Your work on the site is always appreciated.
> >
> 
> I am glad it is useful. I would be very pleased if you or anyone
> else who has some time would go ahead with any changes that you
> think would improve the site. The portal site in some cases changes
> might require an upgrade of your registration "site manager" status
> to allow edit access but I would be very pleased to delegate this
> to who ever is motivated. :-)

There are two aspects: the portal main page is public and I don't mind
editing it. But the personal pages of its members are personal, and
better be left to the individual member who owns it. However, on the
main page, it should be clear what the purpose of the portal is, and why
each member owns a personal page. If I recall correctly, you mentioned
that very few members actually use the portal (that includes me, sorry).
I don't know why I would want to maintain my own portal page!

> If you don't have time, I will try to get to updating the portal
> pages asap.

I will do what I can, once I learn what the purpose of the portal is.
But if editing involves more, like programming in zope or plone, then
I'm afraid I am not the right person.

\start
Date: Fri, 1 Sep 2006 02:53:57 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: --patch-50

I've built a debian box.
The default setup does not include latex or x11 support.
I eventually figured out that you need to do

  apt-get install latex
  apt-get install xlib-dev

and the command line reads:

  make AWK=nawk

The build is in process.

\start
Date: 01 Sep 2006 06:14:37 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: --patch-50

Tim Daly writes:

| I've built a debian box.
| The default setup does not include latex or x11 support.

Most of the compile farm (non-linus) hosts offered by SF display
similar setting: either they don't have latex or they don't have svn.
I eventually gave up using them as testing platforms.

\start
Date: Fri, 1 Sep 2006 09:11:44 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: --patch-50

> | I've built a debian box.
> | The default setup does not include latex or x11 support.
> 
> Most of the compile farm (non-linus) hosts offered by SF display
> similar setting: either they don't have latex or they don't have svn.
> I eventually gave up using them as testing platforms.

isn't that the point of configure?

\start
Date: Fri, 1 Sep 2006 08:35:59 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: --patch-50

On Fri, 1 Sep 2006, root wrote:

| > | I've built a debian box.
| > | The default setup does not include latex or x11 support.
| >
| > Most of the compile farm (non-linus) hosts offered by SF display
| > similar setting: either they don't have latex or they don't have svn.
| > I eventually gave up using them as testing platforms.
|
| isn't that the point of configure?

Axiom requires latex for build. If the environment does not have
latex, I cannot build Axiom, therefore I cannot test it on that
platform.

\start
Date: Fri, 1 Sep 2006 09:59:01 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: --patch-50

> | > | I've built a debian box.
> | > | The default setup does not include latex or x11 support.
> | >
> | > Most of the compile farm (non-linus) hosts offered by SF display
> | > similar setting: either they don't have latex or they don't have svn.
> | > I eventually gave up using them as testing platforms.
> |
> | isn't that the point of configure?
> 
> Axiom requires latex for build. If the environment does not have
> latex, I cannot build Axiom, therefore I cannot test it on that
> platform.

true. but i'd hope that configure would give a clue about what failed
and how to correct the problem.

i spent only 1 minute fixing the latex problem
but it took a good half-hour to figure out how to fix the X problems.
(of course, learning dselect took an hour but...)

can't configure on debian output messages like:

   Error: no latex.... try apt-get install latex
   Error: no X.h.... try apt-get install xlib-dev

there are a limited number of missing packages.

\start
Date: Fri, 01 Sep 2006 16:13:25 +0200
From: Ralf Hemmecke
To: list
Subject: Silver build-improvements: stamp-gcldir

I realised that

make clean

does not remove

build-improvements/lsp/stamp-gcldir

Interestingly, looking at lsp/Makefile.pamphlet, it even seems that the 
target "clean" in the lsp directory is never called. It would fail since 
there is no ccl directory.

clean:
	@echo 17 cleaning ${LSP}/ccl
	@( cd ccl ; ${ENV} ${MAKE} clean )

\start
Date: Fri, 1 Sep 2006 10:13:08 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: --patch-50

On September 1, 2006 9:36 AM Gabriel Dos Reis wrote:
> 
> On Fri, 1 Sep 2006, Tim Daly wrote:
> 
> | > | I've built a debian box.
> | > | The default setup does not include latex or x11 support.
> | >

On Debian of course the usual method of building Axom would be
from the Debian sources... :)

  apt-get source axiom

and the build-deps are also easy to satisfy.

> | > Most of the compile farm (non-linus) hosts offered by SF
> | > display similar setting: either they don't have latex or
> | > they don't have svn. I eventually gave up using them as
> | > testing platforms.
> |
> | isn't that the point of configure?
> 
> Axiom requires latex for build. If the environment does not have
> latex, I cannot build Axiom, therefore I cannot test it on that
> platform.
> 

I would be surprise to learn that latex was not available for
any computer system in use today. If latex is not installed,
then (usually) installing it is straight-forward. For example,
there are several different latex versions available for Windows
systems (miktex being perhap the most common free version).

Anyway, I do not see why the Axiom build should be designed to
require latex. The only really essential tool here is noweb.

\start
Date: Fri, 1 Sep 2006 09:18:54 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: --patch-50

On Fri, 1 Sep 2006, root wrote:

| > | > | I've built a debian box.
| > | > | The default setup does not include latex or x11 support.
| > | >
| > | > Most of the compile farm (non-linus) hosts offered by SF display
| > | > similar setting: either they don't have latex or they don't have svn.
| > | > I eventually gave up using them as testing platforms.
| > |
| > | isn't that the point of configure?
| >
| > Axiom requires latex for build. If the environment does not have
| > latex, I cannot build Axiom, therefore I cannot test it on that
| > platform.
|
| true. but i'd hope that configure would give a clue about what failed
| and how to correct the problem.

It does; configure.ac.pamphlet from build-improvements says:

   AC_CHECK_PROG([LATEX], [latex],
		 [latex], [AC_MSG_ERROR([Axiom needs a latex program.])])


However, my point was different: I cannot use the SF compile farm
hosts at the moment because basic Axiom requirements are nto met.

|
| i spent only 1 minute fixing the latex problem
| but it took a good half-hour to figure out how to fix the X problems.
| (of course, learning dselect took an hour but...)

I don't think I want to fix the problems on the SF machines...

\start
Date: Fri, 1 Sep 2006 09:23:01 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: --patch-50

On Fri, 1 Sep 2006, Bill Page wrote:

| > Axiom requires latex for build. If the environment does not have
| > latex, I cannot build Axiom, therefore I cannot test it on that
| > platform.
| >
|
| I would be surprise to learn that latex was not available for
| any computer system in use today.

just check it our on the non-linux compile farm hosts offered by SF.

| If latex is not installed,
| then (usually) installing it is straight-forward.

Well, I don't have the time to "fix" all those varieties of systems.

| Anyway, I do not see why the Axiom build should be designed to
| require latex. The only really essential tool here is noweb.

We also latex the document; that is part of the basic requirements --
we had a discussion on that issue last week or so with Tim.  If you
want to convince him, good luck.  Otherwise, I'll continue my work on
the sane machines I have access to.  If there are problems somewhere,
I'm very willing to fix them, but I decline to fix the build
environments.

\start
Date: Fri, 01 Sep 2006 16:29:47 +0200
From: Ralf Hemmecke
To: list
Subject: patch-50 successfully compiled on debian sarge

Hello,

I just want to tell you that getting a fresh copy of patch-50 compiled 
fine on my Debian Sarge box.

BTW, this time I got a new copy of the tla archive, but would

make clean
tla update
./configure
make

be enough?

I am somehow missing a "distclean" target.
Or is the current "clean" target producing a directory content as it 
would be after a fresh checkout?

\start
Date: 01 Sep 2006 09:30:57 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Silver build-improvements: stamp-gcldir

Ralf Hemmecke writes:

| I realised that
| 
| make clean
| 
| does not remove
| 
| build-improvements/lsp/stamp-gcldir

I'll fix it.  Bill reported it to me earlier this week.  I had lot of
things to do so I had little times for Axiom.  Sorry for that.

| Interestingly, looking at lsp/Makefile.pamphlet, it even seems that
| the target "clean" in the lsp directory is never called. It would fail
| since there is no ccl directory.
| 
| clean:
| 	@echo 17 cleaning ${LSP}/ccl
| 	@( cd ccl ; ${ENV} ${MAKE} clean )

that is from mainline/golden Axiom, and the rules are very tricky.

\start
Date: 01 Sep 2006 09:38:38 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: patch-50 successfully compiled on debian sarge

Ralf Hemmecke writes:

| I am somehow missing a "distclean" target.

And I'm missing a mostlyclean target -- so that I don't have to
rebuild some parts (e.g. gcl, bootstrap algebra, etc.)  over and over
again. 

| Or is the current "clean" target producing a directory content as it
| would be after a fresh checkout?

the current least surprising method I've found the hard way is just to
rm -rf the entire build directory.  Notice that by using the lndir
trick you can make the build directory different from the source
directory so that you can still keep the source in separate
directories.  Axiom golden and sylver don't support non-in-source
build (which is is a realy bummer), but I have a local experimental
copy of build-improvements where you use the standard practice of
building in a directory different from the source directory, without
the lndir trick. 

\start
Date: Fri, 01 Sep 2006 16:47:35 +0200
From: Ralf Hemmecke
To: list
Subject: Silver build-improvements branch does not compile

woodpecker:~/OTHER/Axiom/Silver/build-improvements>svn update
At revision 112.

./configure
make

Aborts on my Debian Sarge box with the following message.
Should it actually compile?

Ralf

[snip]
====================================
=== algebra bootstrap complete ======
=====================================
compiling AHYP.spad to AHYP.NRLIB
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:2:24: 

cmpinclude.h: No such file or directory
In file included from
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:3:
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:4: 

error: syntax error before "LI2"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:19: 

error: syntax error before "LnkTLI5"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:19: 

error: syntax error before '...' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:20: 

error: syntax error before '*' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:20: 

error: `object' declared as function returning a function
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:20: 

error: function `object' is initialized like a variable
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:20: 

error: syntax error before ')' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:20: 

error: syntax error before ')' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:21: 

error: syntax error before "LnkTLI4"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:22: 

error: syntax error before '*' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:22: 

error: `object' declared as function returning a function
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:22: 

error: function `object' is initialized like a variable
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c: 

In function `init_AHYP':
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:4: 

error: syntax error before ')' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c: 

In function `L1':
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:8: 

error: syntax error before '*' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:9: 

error: syntax error before '*' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:10: 

error: `vs_check' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:10: 

error: (Each undeclared identifier is reported only once
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:10: 

error: for each function it appears in.)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:11: 

error: `vs_top' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:11: 

error: `sup' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:14: 

error: syntax error before "V2"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:15: 

error: `V2' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:15: 

error: syntax error before ')' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:16: 

error: `Cnil' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:18: 

error: `base' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:19: 

error: `vs_base' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:23: 

error: syntax error before ')' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:23: 

error: `LnkLI4' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:24: 

error: syntax error before ')' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c: 

At top level:
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:30: 

error: syntax error before "LI2"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c: 

In function `LI2':
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:32: 

error: syntax error before '*' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:32: 

error: syntax error before '*' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:32: 

error: `vs_top' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:32: 

error: `sup' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:32: 

error: `vs_check' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:35: 

error: syntax error before "V3"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:36: 

error: `V3' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:36: 

error: `Cnil' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:37: 

error: syntax error before "V4"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:38: 

error: `base' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:38: 

error: `LnkLI5' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:38: 

error: syntax error before ')' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:38: 

error: syntax error before ')' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:39: 

error: `vs_base' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:43: 

error: `V4' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:44: 

error: syntax error before ')' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:45: 

error: syntax error before "V5"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:46: 

error: `V5' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:47: 

error: syntax error before "V6"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:48: 

error: `V6' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c: 

In function `LnkT6':
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:52: 

error: syntax error before ')' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c: 

At top level:
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:53: 

error: syntax error before "LnkTLI5"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:53: 

error: syntax error before "first"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c: 

In function `LnkTLI5':
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:53: 

error: syntax error before "V1"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:53: 

error: `va_list' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:53: 

error: `ap' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:53: 

error: `first' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:53: 

error: `V1' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:53: 

error: syntax error before ')' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:53: 

error: `LnkLI5' undeclared (first use in this function)
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c: 

At top level:
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:54: 

error: syntax error before "LnkTLI4"
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c: 

In function `LnkTLI4':
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:54: 

error: syntax error before ')' token
/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:54: 

error: `LnkLI4' undeclared (first use in this function)
copying AHYP.NRLIB to AHYP.o
cp: cannot stat
`/home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/code.o': 

No such file or directory
make[4]: ***
[/home/hemmecke/OTHER/Axiom/Silver/build-improvements/mnt/linux/algebra/AHYP.o] 

Error 1
make[4]: Leaving directory
`/home/hemmecke/OTHER/Axiom/Silver/build-improvements/src/algebra'
make[3]: *** [algebradir] Error 2
make[3]: Leaving directory
`/home/hemmecke/OTHER/Axiom/Silver/build-improvements/src'
make[2]: *** [srcdir] Error 2
make[2]: Leaving directory
`/home/hemmecke/OTHER/Axiom/Silver/build-improvements'
make[1]: *** [do-all] Error 2
make[1]: Leaving directory
`/home/hemmecke/OTHER/Axiom/Silver/build-improvements'
make: *** [all] Error 2

\start
Date: Fri, 1 Sep 2006 10:38:36 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: patch-50 successfully compiled on debian sarge

> Axiom golden and sylver don't support non-in-source
> build (which is is a realy bummer)

they don't? the source tree is read-only (or is intended to be).

src is all of the original (human-generated) source.
int is a cache of (machine-independent, machine-generated) source
obj is a cache of (machine-dependent, machine-generated) binary
mnt is the ship system and should be the only thing needed to run

if you want the other directories to show up elsewhere just use
a symbolic link.

\start
Date: Fri, 1 Sep 2006 10:49:42 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: --patch-50

Gaby,

On September 1, 2006 10:23 AM you wrote:
> ...
> Bill Page wrote: 
> | Anyway, I do not see why the Axiom build should be designed to
> | require latex. The only really essential tool here is noweb.
> 
> We also latex the document; that is part of the basic requirements --
> we had a discussion on that issue last week or so with Tim.

I do not recall that discussion. I do not agree that latex should be
part of the basic requirements. LaTeX plays no essential role in
compiling Axiom from source. Of course LaTeX (or an equivalent like
Lyx or TeXmacs etc.) would be a requirement if one intended to actually
modify the source since Axiom is coded in a literate style, but that
is another issue.

> If you want to convince him, good luck.

I thought the point of Silver was that we didn't have to try to
convince Tim of anything anymore ... ;)  (... meant to be funny).

> Otherwise, I'll continue my work on the sane machines I have access
> to.

Goood plan.

> If there are problems somewhere, I'm very willing to fix them, but
> I decline to fix the build environments.
> 

I think "fix" is too strong a word for the SF compile farm since
these machines serve many different purposes.

\start
Date: Fri, 1 Sep 2006 10:44:21 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: patch-50 successfully compiled on debian sarge

> I just want to tell you that getting a fresh copy of patch-50 compiled 
> fine on my Debian Sarge box.
> 
> BTW, this time I got a new copy of the tla archive, but would
> 
> make clean
> tla update
> ./configure
> make
> 
> be enough?
> 
> I am somehow missing a "distclean" target.
> Or is the current "clean" target producing a directory content as it 
> would be after a fresh checkout?

It turns out that the recursive 'make clean' cannot recover from
certain badly formed partial builds. The actual clean stanza that
is now executed is in the top level Makefile and reads:

	@ echo 7 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
	@ echo 8 Environment ${ENV}
	@ rm -f lsp/Makefile.dvi
	@ rm -f lsp/Makefile
	@ rm -rf lsp/gcl*
	@ rm -f noweb 
	@ rm -f trace
	@ rm -f Makefile.${SYS}
	@ rm -f Makefile.dvi
	@ rm -rf int
	@ rm -rf obj
	@ rm -rf mnt
	@ for i in `find . -name "*~"` ; do rm -f $$i ; done
	@ for i in `find src -name "Makefile"` ; do rm -f $$i ; done
	@ for i in `find src -name "Makefile.dvi"` ; do rm -f $$i ; done

This should reset the system back to its initial state.

I'll clean up the Makefile.pamphlets to reflect this.

\start
Date: Fri, 1 Sep 2006 10:46:43 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Silver build-improvements branch does not compile

> cmpinclude.h: No such file or directory
> In file included from
> /home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:3:
> /home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:4: 


cmpinclude.h is from GCL.
apparently the compile-file lisp call cannot find this include file.

did you build GCL or are you trying to use a pre-installed copy?

\start
Date: Fri, 1 Sep 2006 11:01:07 -0400
From: Bill Page
To: William Sit
Subject: RE: obsolete pages and portal download

William,

On September 1, 2006 2:27 AM you wrote:
> 
> Bill Page wrote:
> > 
> > On August 31, 2006 6:11 PM William Sit wrote:
> > >
> > > Is there any info that is still useful on
> > > http://page.axiom-developer.org?
> > 
> > No, I don't think so. This was my original "personal home page"
> > on the axiom-developer site. In addition to the wiki and the
> > portal, anyone who has an account directly on the axiom-developer
> > server also has such a web page. These are only editable when
> > you are directly logged in to the server.
> 
> I see. I had always thought that was the main axiom-developer
> page.
>

No. That is just were the development of MathAction as an
experiment started.
  
> > > Can some of these pages be deleted (or made unreadable by
> > > the public)?
> > 
> > Yes. Should I delete it, have it automatically re-direct to
> > http://wiki.axiom-developer.org or maybe take the time to
> > actually make it more "personal"? What do yo think?
> 
> Since this is your personal page, it would be up to you to decide
> whether to delete it or redirect it. But as far as the Axiom public
> is concerned, it would be less confusing if the headers of those 
> pages say clearly it is your personal home page and that you
> provide links to the "official" Wiki site. Then if someone stumbles
> onto your page through searches, they would be directed to the right
> info place.
>

Is this better?

http://page.axiom-developer.org
 
Thanks for your suggestions.

\start
Date: Fri, 1 Sep 2006 10:54:21 -0400
From: Tim Daly
To: Bill Page
Subject: Re: --patch-50
Cc: Gabriel Dos Reis

> > | Anyway, I do not see why the Axiom build should be designed to
> > | require latex. The only really essential tool here is noweb.
> > 
> > We also latex the document; that is part of the basic requirements --
> > we had a discussion on that issue last week or so with Tim.
> 
> I do not recall that discussion. I do not agree that latex should be
> part of the basic requirements. LaTeX plays no essential role in
> compiling Axiom from source. Of course LaTeX (or an equivalent like
> Lyx or TeXmacs etc.) would be a requirement if one intended to actually
> modify the source since Axiom is coded in a literate style, but that
> is another issue.

hmmpf.  you'll never convince tim of THIS one :-)

> > If you want to convince him, good luck.
> 
> I thought the point of Silver was that we didn't have to try to
> convince Tim of anything anymore ... ;)  (... meant to be funny).

in some sense, yes. the SVN branch is a place where such "wild"
ideas (such as axiom without latex) can be explored. it's the
'Linux Torvolds' vs 'Andrew Morton' organization used in Linux
(not that i'm claiming to be linus...)

Andrew maintains a -mm version of Linux that includes many 
patches/changes/extensions/breakage that is not accepted into
the mainline distribution if/until Linus is convinced. some
ideas (such as the kernel debugger) never get included in the
main distribution (see http://kwn.net/2000/0914/a/lt-debugger.php3)

i can see from his post that Linus is a 'primitivist' like myself :-)

> > If there are problems somewhere, I'm very willing to fix them, but
> > I decline to fix the build environments.
> > 
> 
> I think "fix" is too strong a word for the SF compile farm since
> these machines serve many different purposes.

latex does not need to be globally installed.

\start
Date: 01 Sep 2006 10:04:21 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: patch-50 successfully compiled on debian sarge

Tim Daly writes:

| > Axiom golden and sylver don't support non-in-source
| > build (which is is a realy bummer)
| 
| they don't?

No, they don't.  I just repeated this for illustration.  Try it on
your machine.

  % cd src/axiom.trunk-tla
  % tla update
  [...]
  % cd ~/build/
  % mkdir trunk-tla
  % ~/src/axiom.trunk-tla/configure --prefix=$HOME
  Linux


  ===================================================
  You must set your AXIOM and PATH variables. Type:

  To build the rest of the system type:

  export AXIOM=/home/gdr/build/mnt/linux
  export PATH=$AXIOM/bin:$PATH
  make

  configure finished.

  % export AXIOM=/home/gdr/build/mnt/linux
  % export PATH=$AXIOM/bin:$PATH
  % make
  make: *** No targets specified and no makefile found.  Stop.


| the source tree is read-only (or is intended to be).

That is the _intent_, but NOT the actual reality.
Compare with this

% cd build
% mkdir b-i && cd b-i
% /media/usbdisk_2/cas/axiom/2006-08-30.b-i/configure --prefix=$HOME
[...]
% make
AXIOM=/home/gdr/build/b-i/mnt/linux; export AXIOM; PATH=/home/gdr/build/b-i/mnt/linux/bin:${PATH}; make do-all
make[1]: Entering directory `/home/gdr/build/b-i'
0 SPAD=/home/gdr/build/b-i/mnt/linux SYS=linux SPD=/home/gdr/build/b-i LSP=/home/gdr/build/b-i/lsp GCLDIR=/home/gdr/build/b-i/lsp/gcl-system SRC=/home/gdr/build/b-i/src INT=/home/gdr/build/b-i/int OBJ=/home/gdr/build/b-i/obj MNT=/home/gdr/build/b-i/mnt ZIPS=/home/gdr/build/b-i/zips TMP=/home/gdr/build/b-i/obj/tmp SPADBIN=/home/gdr/build/b-i/mnt/linux/bin INC=/home/gdr/build/b-i/src/include CCLBASE=/home/gdr/build/b-i/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /home/gdr/build/b-i/obj/tmp/trace GCLVERSION=gcl-system VERSION=Axiom (build improvements branch) -- 2006-08-28 DOCUMENT=/home/gdr/build/b-i/build/scripts/document
[... so on...]

The sources live in a different place and the build happens
elsewhere.  The objects for the build, host and target are separated.

| src is all of the original (human-generated) source.
| int is a cache of (machine-independent, machine-generated) source
| obj is a cache of (machine-dependent, machine-generated) binary
| mnt is the ship system and should be the only thing needed to run

I understand that division but it is setting up a very non-standard build
process that does not even match the intents.

| if you want the other directories to show up elsewhere just use
| a symbolic link.

A simple symbolic link does NOT work.  You have to do something
equivalent to the lndir trick I documented. 

Axiom would gain lot by not building a ghetto around itself.

\start
Date: 01 Sep 2006 10:13:19 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Silver build-improvements branch does not compile

Ralf Hemmecke writes:

| woodpecker:~/OTHER/Axiom/Silver/build-improvements>svn update
| At revision 112.
| 
| ./configure
| make
| 
| Aborts on my Debian Sarge box with the following message.
| Should it actually compile?

See

  http://lists.nongnu.org/archive/html/axiom-developer/2006-08/msg00571.html


The executive summary is a bug (I believe) in the option GCL uses to
compile the generated C codes.  GCL should include the patch to cmpinclude.h

A fix for Axiom would be to have GCL include that path evertime, for
example by modifying *CC* -- by I have not tested that yet.

So, for the moment I have successful builds with

   ./configure --without-gcl

I should probably make that default -- but it kinds of negates the
whole purpose of the patch.  If I don't have time to fix the GCL issue
today, I'll make --without-gcl the default.

\start
Date: Fri, 01 Sep 2006 17:19:19 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Silver build-improvements branch does not compile

On 09/01/2006 04:46 PM, root wrote:
>> cmpinclude.h: No such file or directory
>> In file included from
>> /home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:3:
>> /home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:4: 
> 
> 
> cmpinclude.h is from GCL.
> apparently the compile-file lisp call cannot find this include file.
> 
> did you build GCL or are you trying to use a pre-installed copy?
> 
> t

I did not build GCL by hand, of course. Just said

./configure
make

But I have an seemingly old gcl installed.

 >gcl --version
GCL (GNU Common Lisp)  2.6.6 CLtL1    Jan 18 2005 00:13:38
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

How do I find out whether Axiom has built gcl or not?
At least the config.log says

configure:3030: checking for gcl
configure:3046: found /usr/bin/gcl

And this is 2.6.6. Hmmmm....

\start
Date: 01 Sep 2006 10:22:35 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: --patch-50

Bill Page writes:

| Gaby,
| 
| On September 1, 2006 10:23 AM you wrote:
| > ...
| > Bill Page wrote: 
| > | Anyway, I do not see why the Axiom build should be designed to
| > | require latex. The only really essential tool here is noweb.
| > 
| > We also latex the document; that is part of the basic requirements --
| > we had a discussion on that issue last week or so with Tim.
| 
| I do not recall that discussion.

I do not have enough patience to wait the long time needed to lookup
mails from the axiom-developer archive, it was mostly a ping-pong
between Tim and me on the list.

I do believe that there out to be a mode of compiling Axiom without
having to latex the pamphlet files, because there are situations where
those latexing are pure plain waste of valuable time.

[...]

| > If there are problems somewhere, I'm very willing to fix them, but
| > I decline to fix the build environments.
| > 
| 
| I think "fix" is too strong a word for the SF compile farm since
| these machines serve many different purposes.

well, when I asked for machines where I could test Axiom on, you kindly
reminded me that SF offers compile farm machines.  I find the idea great!
Then I proceeded to registered myself and test Axiom.  Only to find
that Axiom build requirements are met only on linux-based platforms. 
If we restrict ourselves sufficiently enough we should not have any
problem.  We could even build a wonderful black-hole ghetto for Axiom.  

Now, if I must spend valuable time to install tools on each of those
systems and watchout for my user configuration files to pick the right
binaries and whatnot, then I rather spend it on my research and teaching.
Axiom requirements are excellent in the abstract.  Its approach to the
real software world makes it a good candidate for the contest of most
frustrating open source software to contribute to. 

\start
Date: 01 Sep 2006 10:26:24 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: --patch-50

Tim Daly writes:

[...]

| > > If you want to convince him, good luck.
| > 
| > I thought the point of Silver was that we didn't have to try to
| > convince Tim of anything anymore ... ;)  (... meant to be funny).
| 
| in some sense, yes. the SVN branch is a place where such "wild"
| ideas (such as axiom without latex) can be explored. 

You have also to realize that it is good to provide people way to test
wild ideas and provide incentive to people.  Can you give me any
reason why people would spend their valuable time Axiom-without-latex
when it is for from the outset that it is wasted time?

| it's the
| 'Linux Torvolds' vs 'Andrew Morton' organization used in Linux
| (not that i'm claiming to be linus...)

No, at the moment it is not.  Rather, I'm beginning to view it as way
of trapping people :-)


[...]

| > > If there are problems somewhere, I'm very willing to fix them, but
| > > I decline to fix the build environments.
| > > 
| > 
| > I think "fix" is too strong a word for the SF compile farm since
| > these machines serve many different purposes.
| 
| latex does not need to be globally installed.

that is beside the point.

\start
Date: Fri, 1 Sep 2006 11:18:06 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Silver build-improvements branch does not compile

> How do I find out whether Axiom has built gcl or not?
> At least the config.log says
> 
> configure:3030: checking for gcl
> configure:3046: found /usr/bin/gcl
> 
> GCL (GNU Common Lisp)  2.6.6 CLtL1    Jan 18 2005 00:13:38

To build axiom on 2.6.6 you need to set the GCLVERSION variable.
The required patches are in the zips subdirectory and will 
automatically be picked up.

Unfortunately you'll have to reach into the tla archives to pick up
gcl-2.6.6.tgz

Axiom will certainly not build on a pre-installed GCL version 2.6.6

\start
Date: 01 Sep 2006 10:28:47 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Silver build-improvements branch does not compile

Tim Daly writes:

| > cmpinclude.h: No such file or directory
| > In file included from
| > /home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:3:
| > /home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:4: 
| 
| 
| cmpinclude.h is from GCL.
| apparently the compile-file lisp call cannot find this include file.

Yes, the include file is however installed in *system-directory*/h.

| 
| did you build GCL or are you trying to use a pre-installed copy?

this error happens only if you use pre-installed copy of GCL.  We must
support that.

\start
Date: 01 Sep 2006 10:36:09 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Silver build-improvements branch does not compile

Ralf Hemmecke writes:

| On 09/01/2006 04:46 PM, root wrote:
| >> cmpinclude.h: No such file or directory
| >> In file included from
| >> /home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.c:3:
| >> /home/hemmecke/OTHER/Axiom/Silver/build-improvements/int/algebra/AHYP.NRLIB/AHYP.h:4:
| > cmpinclude.h is from GCL.
| > apparently the compile-file lisp call cannot find this include file.
| > did you build GCL or are you trying to use a pre-installed copy?
| > t
| 
| I did not build GCL by hand, of course. Just said
| 
| ./configure

As of today, when you say that, Axiom will look the build environment
to see whether GCL is present and try to use it.

I should probably put a version cut of on it -- say GCL 2.6.7.

But, even with that, there is a bug in GCL that needs to be fixed:
currently it does not seemt to the set the -I include directory switch
so that GCC can find its internal include file.

I'll try to work around that by modifying *CC*.

[...]

| How do I find out whether Axiom has built gcl or not?

Normaly, the message output by configure on the standard output should
tell you that Axiom will use the installed GCL.  You should have seen
something like

    checking for gcl... gcl

Say 

  ./configure --without-gcl

to force Axiom to build its own copy of GCL.

\start
Date: Fri, 1 Sep 2006 08:43:20 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis, Tim Daly
Subject: Requiring LaTeX

--- Gabriel Dos Reis wrote:

> | in some sense, yes. the SVN branch is a place where such "wild"
> | ideas (such as axiom without latex) can be explored. 
> 
> You have also to realize that it is good to provide people way to
> test wild ideas and provide incentive to people.  Can you give me any
> reason why people would spend their valuable time Axiom-without-latex
> when it is for from the outset that it is wasted time?

Correct me if I'm wrong, but wouldn't this be simply addressed by
having a ./configure --nobuild-latex option in the build improvements
branch, with the reasonable expectation that this option becomes
"mainstream" when the build-improvements branch does?  The default can
be to build the LaTeX files, but a quick check for functionality
outside of the latex system can also be done for those who aren't
testing the latex build ability at that time.

I understand the desire to make literate programming part of the
process and I agree with that goal, but in cases like the sourceforge
compile farm I can certainly see checking the non-latex parts of the
build on those platforms.  We aren't in the business (so far as I know)
of testing latex functionality on different platforms - we assume if
people want latex built they have latex available, just like gcl
assumes a working gcc available.  If people don't have latex available
and can't install it, then I can see a minimalist build option. 
Editing the files in pamphlet style doesn't mean you need to check that
the latex part works then and there - if the code part and the notangle
part work there then latex can be debugged later on a machine/platform
where it does exist.

In the very long term, something like an improved cl-typesetting might
enable us to actually remove the need for a working TeX installation as
a requirement for creating the literate files, but since we can't
currently provide our own solution and a serious LaTeX installation is
sometimes a lot to assume I would favor making the LaTeX build a
configure time option.  The default should still be to build it, but I
would support giving the user the choice to disable it because there
are circumstances (the SF compile farm being a good example) where
there is a valid reason not to use it.

\start
Date: Fri, 1 Sep 2006 11:54:30 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: --patch-50

On September 1, 2006 11:23 AM you wrote:
> ... 
> I do believe that there out to be a mode of compiling Axiom without
> having to latex the pamphlet files, because there are situations
> where those latexing are pure plain waste of valuable time.
> 

Good.

> [...]
> 
> | > If there are problems somewhere, I'm very willing to fix them,
> | > but I decline to fix the build environments.
> | > 
> | I think "fix" is too strong a word for the SF compile farm since
> | these machines serve many different purposes.
> 
> well, when I asked for machines where I could test Axiom on, you
> kindly reminded me that SF offers compile farm machines.  I find
> the idea great!
> Then I proceeded to registered myself and test Axiom.  Only to find
> that Axiom build requirements are met only on linux-based platforms. 
> If we restrict ourselves sufficiently enough we should not have any
> problem.  We could even build a wonderful black-hole ghetto for
> Axiom.  
> 

I don't think there is a desire to restrict where Axiom builds -
this is only due to allocation of the scarce resource of people
motivated to solve problems on other platforms.

> Now, if I must spend valuable time to install tools on each of those
> systems and watchout for my user configuration files to pick the
> right binaries and whatnot, then I rather spend it on my research 
> and teaching.

Understood. I would prefer to reduce the requirements (e.g. remove
the requirement for latex).

> Axiom requirements are excellent in the abstract.  Its approach to
> the real software world makes it a good candidate for the contest
> of most frustrating open source software to contribute to. 
> 

I agree. How can we fix that?

\start
Date: Fri, 01 Sep 2006 19:44:47 +0200
From: Ralf Hemmecke
To: list
Subject: Silver build-improvements: Hyperdoc

The compilation of the build-improvements succeeded with

./configure --without-gcl
make

After that I said

export AXIOM=/my/path/to/mnt/linux
export PATH=$AXIOM/bin:$PATH
axiom

After the welcome message I read

(1) ->
ReadBitmapFile: File 
 >/home/hemmecke/OTHER/Axiom/Silver/build-improvements/mnt/linux/../../share/doc/hypertex/bitmaps/axiom1.bitmap< 
not found

and hyperdoc flashes up and dies.

Interestingly, I don't see that share directory under 
build-improvements. The file could be found here.

./mnt/linux/doc/hypertex/bitmaps/axiom1.bitmap

\start
Date: 01 Sep 2006 12:48:41 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Silver build-improvements: Hyperdoc

Ralf Hemmecke writes:

| The compilation of the build-improvements succeeded with
| 
| ./configure --without-gcl
| make
| 
| After that I said
| 
| export AXIOM=/my/path/to/mnt/linux
| export PATH=$AXIOM/bin:$PATH
| axiom
| 
| After the welcome message I read
| 
| (1) ->
| ReadBitmapFile: File
| >/home/hemmecke/OTHER/Axiom/Silver/build-improvements/mnt/linux/../../share/doc/hypertex/bitmaps/axiom1.bitmap<
| not found
| 
| and hyperdoc flashes up and dies.
| 
| Interestingly, I don't see that share directory under
| build-improvements. The file could be found here.
| 
| ./mnt/linux/doc/hypertex/bitmaps/axiom1.bitmap

Interesting, I did not make any work in that directory.  
I suspect there must be an issue related to this reported in the axiom
tracker, but for a different Axiom flavour (not build-improvements).

Thanks,

\start
Date: Fri, 1 Sep 2006 14:13:14 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Requiring LaTeX
Cc: Gabriel Dos Reis

> I understand the desire to make literate programming part of the
> process and I agree with that goal, but in cases like the sourceforge
> compile farm I can certainly see checking the non-latex parts of the
> build on those platforms.  We aren't in the business (so far as I know)

\begin{rant}

We part company on this one.
I guess I'm alone in understanding that the Latex IS THE SOURCE.

Latex is not optional, it is not overhead, it is not waste.
If latex is not installed then axiom SHOULD NOT BUILD.

If you just want a system without source code that's fine.
But that has nothing much to do with the design and testing of
the axiom configure/make process.

I get the distinct impression that no-one has really made the
transition to literate programming. 

Do you write the documentation before and during program development 
or are you coding and then "adding the documentation"? 

Do you always notangle or do you write code and embed it later?

Are you writing for the end user and future developers
or are you programming and then explaining?

Do you create the .dvi file and xdvi it on every change
or do you call gcc/lisp directly and only look at the .dvi later?

Do you rewrite paragraphs so they flow easier, have index entries,
and are placed where they logically belong in the explanation or
do you write paragraphs around where the compiler wants the code?
(hint: if your code is in compiler order in the file you are most
likely NOT doing literate programming. Humans don't understand
design issues in compiler order)



Literate programming has almost nothing to do with latex.
It is a change in MINDSET and a change in development methodology.



Few people have had the opportunity to get their own code returned
to them after 15 years. Believe me, your "deep understanding" of
the makefiles, algebra code, etc. will be lost on you when you are
asked to explain or maintain it 15 years from now.

Code that you need to explain (and which you are no longer around
to explain) is DEAD CODE. Code written for the machine rather than
people is DEAD CODE. Don't believe me? Show me code you wrote 15
years ago that is still used and maintained by others.

Since we are only in the first 50 years of computer science and
most code dies when the company kills it or the company dies we
have not had the issue of creating live code. LIVE CODE is code
that will survive many GENERATIONS of programmers. Few examples
exist because most code dies.

Axiom cannot afford to add more dead code. It will not survive.
Open source will NOT do it. I've already had one of my open
source projects die (pinger, an SNMP client/server in Java), 
even sourceforge removed it.



After much pondering on the subject I believe that literate
programming is the only technology that promises to make code live.
It can do that because it changes the MINDSET so that programmers
write for PEOPLE, not machines.



The new makefiles should be 3/4 documentation. They should discuss
the design decisions (like separate build trees) based on today's
understanding so that when the trends change (and they will) the
next generation knows the why and how of the design. Why is it ok
to require the user to install GCL but not Latex? Why is it important
to have automatically generated makefiles? Why is it important to
use automake? How is non-linux portability addressed? What linux
assumptions are made so I know what to change for BSD? What about
getting it to run on a MAC? Windows?

We SHOULD be reading the literate makefiles like you would
peer-review a paper. That way we could correct design mistakes
and debate wording of explanations that affect code.

Unreasonable? Hardly. I've gotten a fair amount of grief over the
design of the current Makefile tree. I've been told that it is
unclear (even though the first paragraph of the top level Makefile
starts explaining the design points). I've been told it is not
'standard' even though it preceeds automake by 10 years. I've been
told that it doesn't support 'standard stanzas' (like distclean,
whatever that does). I've been told that it should use special
GNU-make features (whereas it used to use standard make and used
to build on Suns which it won't do now). I've been told that it
is a complete mess even though it follows a very small number of
design principles everywhere (stanza per file, makefile per 
subdirectory, unique echo per stanza, Bill Page/$INT/$OBJ/$MNT variables,
etc.

Believe me, you're going to catch grief from the next person to
touch the makefile process. At least explain why the new process
does what it does so that you can point out where changes go against
design principles (such as the src/int/obj/mnt principles).



Above all, please try to make the transition to a literate mindset,
at least while working on Axiom code. The future demands it.

\end{rant}

\start
Date: Fri, 1 Sep 2006 14:14:03 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Silver build-improvements: Hyperdoc

>  >/home/hemmecke/OTHER/Axiom/Silver/build-improvements/mnt/linux/../../share/doc/hypertex/bitmaps/axiom1.bitmap< 
> not found

This is fixed in --patch-50

\start
Date: Fri, 1 Sep 2006 13:33:52 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Requiring LaTeX

On Fri, 1 Sep 2006, root wrote:

| Latex is not optional, it is not overhead, it is not waste.
| If latex is not installed then axiom SHOULD NOT BUILD.

The logical consequence is that Axiom would probably stay in its black
hole ghetto and you continue ranting alone here wondering why nobody
recognizes the value of Axiom, and why you have so few people
contributing to Axiom.  The 30-years horizons might just be 30-years
night.

| I get the distinct impression that no-one has really made the
| transition to literate programming.

I strongly suspect you get a VERY WRONG impression.

The question is not whether we understand the value of literate
programming.  The issue is more about how we leverage on existing
tools to bring literate programming mainstream.  Until you appreciate
that that you can NOT take over the world overnight, you will
unknowingly be harming Axiom.

[...]

| Literate programming has almost nothing to do with latex.

How true!  Now get down, and concrete.  Axiom requires latex to
build.  That requirement should be losened until you take over the
world.  Latex isn't needed for running and testing Axiom.  Refusing to
build Axiom on a system where latex does not exist is not just
non-sensical.  It does active harm to the project itself.

Nobody has proposed that Axiom be non-literate -- if that is what
you're arguing.

\start
Date: Fri, 01 Sep 2006 22:02:04 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Silver build-improvements: Hyperdoc

On 09/01/2006 08:14 PM, root wrote:
>>  >/home/hemmecke/OTHER/Axiom/Silver/build-improvements/mnt/linux/../../share/doc/hypertex/bitmaps/axiom1.bitmap< 
>> not found
> 
> This is fixed in --patch-50

No, that cannot be. ;-)

Since fixes in Gold should appear *BEFORE* in Silver, that fix cannot be 
in Gold, since it is not in Silver.

If it is in Gold, then someone is hiding the good stuff from people 
working on the Silver branch.

Tim, you should not just add improvements without telling others. That 
makes frustrated developers who will soon get away from Axiom or fork a 
new project. Do you want that?

\start
Date: Fri, 01 Sep 2006 22:29:18 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: Requiring LaTeX

> | Latex is not optional, it is not overhead, it is not waste.
> | If latex is not installed then axiom SHOULD NOT BUILD.

I must say, I don't understand that. If you type "make" that will build 
the whole system. Why cannot there be some targets like "make binaries", 
"make doc" to split that process?

Suppose you are an axiom-developer (and you can build everything of 
Axiom on your local machine). Now person A is posting a message that 
Axiom does not build on machine X for this or that reason. Let's say the 
reason is that the binaries don't compile. You have access to a similar 
machine X' and you have the feeling that you could solve the problem.
You checkout Axiom on X' start compilation and... the compilation stops 
just after trying to latex the first Makefile.pamphlet, because 
unfortunately, LaTeX is not installed on that machine and you don't have 
root access to install it.

In any case it simply would cost you too much time to look for a bugfix 
and so you just say

rm -rf $AXIOMTREE

and don't even post on axiom-developer that you had tried to solve the 
issue.

A build system that builds parts of Axiom with fewer requirements (like 
building binaries and no .dvi files) is just a PLUS for Axiom. That has 
NOTHING to do with Tim's wish that Axiom should not (fully) build if 
LaTeX is not available. It's just support for Axiom developers.

> | I get the distinct impression that no-one has really made the
> | transition to literate programming.
> 
> I strongly suspect you get a VERY WRONG impression.

I also think so. Tim, it was basically you and all that Axiom stuff that 
made me try LP. And although I think I've understood the change in 
mindset, I must admit that it is not completely trivial to change my 
previous way of programming to an LP style. You can see that from all my 
code in ALLPROSE and aldor-combinat 
svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk/combinat
But I will never go back to non-LP.

\start
Date: Fri, 1 Sep 2006 14:01:04 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Requiring LaTeX
Cc: Gabriel Dos Reis

--- Tim Daly wrote:

> \begin{rant}
> 
> We part company on this one.
> I guess I'm alone in understanding that the Latex IS THE SOURCE.
> 
> Latex is not optional, it is not overhead, it is not waste.
> If latex is not installed then axiom SHOULD NOT BUILD.

If we take that approach, then it is just as important to bundle TeX in
some form along with Axiom as it is to bundle GCL.  Particularly on
Windows, where an installation of TeX probably does not already exist.
 
> I get the distinct impression that no-one has really made the
> transition to literate programming. 

That may be true, in some sense - if you mean going from "making a
document that describes a design and then integrating the code into
that design" to writing a document which happens to have some passages
in source code.  I liken it to writing a document containing both
English and Ancient Egyptian - if you don't speak Ancient Egyptian
fluently, you're going to wind up either writing out the Egyptian and
then going back and writing the English paper (because they require
different types of concentration) or writing the English paper and then
creating the Ancient Egyptian to support what you need  (the latter
approach is the one I am planning for the units package).  Obviously it
is iterative for both languages but eventually you arrive at something
reasonable.

I think, Tim, you are capable of writing fluently in both English and
programming languages - in both cases they are merely ways in which you
"speak" your ideas.  To me at least it is not (yet) this natural - if
I'm translating an idea into code I have to stop and figure out how to
do it, with a lot of trial and error.  I can't do that and write at the
same time, as yet - for me it is two different kinds of concentration.
 
> Do you write the documentation before and during program development 
> or are you coding and then "adding the documentation"? 

The former, more or less, although I will likely change both code and
document significantly before this process is done.  If I hit a sticky
point of coding that requires an hour of banging my head into new
shapes I don't bother writing latex until I can say something
intelligent.  This may be because I am not a skilled coder - when it
comes more "naturally" to me perhaps I will become better at the "write
a document some of which happens to be in the Aldor language" style of
working.

> Do you always notangle or do you write code and embed it later?

The latter, or as I build a document I will notangle it to get the
support structure, and then fool around with the next piece until it
makes sense, then go back and embed it to have it become part of the
"support" structure and main document.

> Are you writing for the end user and future developers
> or are you programming and then explaining?

Hopefully the two are not mutually exclusive.  I am in the somewhat
precarious position of trying to write a high quality literate program
without having at the beginning of the process either the academic
knowledge or the programming knowledge to achieve the goal at the
outset.  Ralf and William have both been an immeasurable help in
improving that situation, but many of the issues I have to figure out
are due to my not yet being "fluent" in the subjects of Aldor, Axiom,
and units/dimensions/types.  It would be like including someone
learning English for the first time in a document attempting to do a
literary review of a book - you want the review to be about the book,
not about the author of the review learning how to write the review.

> Do you create the .dvi file and xdvi it on every change
> or do you call gcc/lisp directly and only look at the .dvi later?

Heh - I guess since my pamphlet file is so far all latex code it's a
bit of a moot point.  On the Emacs mode pamphlet, it was sort of a mix.

> Do you rewrite paragraphs so they flow easier, have index entries,
> and are placed where they logically belong in the explanation or
> do you write paragraphs around where the compiler wants the code?
> (hint: if your code is in compiler order in the file you are most
> likely NOT doing literate programming. Humans don't understand
> design issues in compiler order)

That part I do understand.  I order the ideas for humans and then put
things in the correct order at the end.

> Literate programming has almost nothing to do with latex.
> It is a change in MINDSET and a change in development methodology.

I agree.  That methodology, however, requires a fluency level in
programming which will require some time for me to achieve.

> Few people have had the opportunity to get their own code returned
> to them after 15 years. Believe me, your "deep understanding" of
> the makefiles, algebra code, etc. will be lost on you when you are
> asked to explain or maintain it 15 years from now.

:-).  Oh, no question there.  But before I consider myself qualified to
write a document about a program, I want to have something that works. 
If I don't have running code for an idea I will usually describe the
idea, and then grab the programming tools and beat my head against it
until something works.  THEN I (might) be qualified to start talking
about the how and why of making the idea into a coded algorithm.  

I may change some of this once I am comfortable enough to do "real
work" in Aldor.

> Code that you need to explain (and which you are no longer around
> to explain) is DEAD CODE. Code written for the machine rather than
> people is DEAD CODE. Don't believe me? Show me code you wrote 15
> years ago that is still used and maintained by others.

I wasn't programming 15 years ago, but I agree this is true.

> Since we are only in the first 50 years of computer science and
> most code dies when the company kills it or the company dies we
> have not had the issue of creating live code. LIVE CODE is code
> that will survive many GENERATIONS of programmers. Few examples
> exist because most code dies.

Definitely agree.  We have reinvented so many wheels so many times it
borders on crazy.

> Axiom cannot afford to add more dead code. It will not survive.
> Open source will NOT do it. I've already had one of my open
> source projects die (pinger, an SNMP client/server in Java), 
> even sourceforge removed it.

OK.  I don't want to hammer too hard on this point Tim, but for things
like the lisp and boot code in the interperter I think there is already
so little understanding of that code that the changes required to make
it run on ANSI, documented or not, are going to do very little to
change the "live" status of that code in a literate sense.  Your work
on bookvol5 is what WILL change it, and eventually a re-write which
cleans up and makes known the issues involved with the interperter
design, but the practical benefits of ANSI compatible changes are
mostly orthogonal to the goal of a comprehensible literate interperter.
 Obviously the BEST idea is to make the interperter into a literate
program, but my one run at that pretty much convinced me that we should
just start at an ideas level, design what the interperter SHOULD be,
and then use the existing code where applicable as either a guide or
copied over to create the new interperter.  Since that task is down the
road on the current plan, I would like to see a minimal ANSI compatible
subset change made (with or without comments, since the codebase is
already too dense for many of us to understand at the moment anyway and
thus we don't DECREASE comprehensibility any) to allow us to make use
of tools being created for Lisp today.  

I understand this doesn't advance the goal of making Axiom truly
literate and so may be counter to the goals of the project, I'm just
presenting (as well as I can) the argument for a few short term, quick,
and immediate steps to improve immediate problems like being able to
run only on GCL, which doesn't support things like McCLIM, cffi, Slime
(maybe?), and other tools used by most modern lisp programmers today. 
If they are not convincing then that's OK too.

> After much pondering on the subject I believe that literate
> programming is the only technology that promises to make code live.
> It can do that because it changes the MINDSET so that programmers
> write for PEOPLE, not machines.

Agreed.

> The new makefiles should be 3/4 documentation. They should discuss
> the design decisions (like separate build trees) based on today's
> understanding so that when the trends change (and they will) the
> next generation knows the why and how of the design. Why is it ok
> to require the user to install GCL but not Latex?

But we don't require the user to install GCL - Axiom deliberately
includes it in the tree as of now.  We DO require an external install
of LaTeX - is the plan to bundle some subset of TeX and LaTeX as well? 
(I can see this if we have a cl-typesetting type solution since that
typesetting logic can also be used in GUI situations as well as
literate coding, but I don't think TeX was designed for this type of
situation.)

> Why is it important
> to have automatically generated makefiles? Why is it important to
> use automake? How is non-linux portability addressed? What linux
> assumptions are made so I know what to change for BSD? What about
> getting it to run on a MAC? Windows?
> 
> We SHOULD be reading the literate makefiles like you would
> peer-review a paper. That way we could correct design mistakes
> and debate wording of explanations that affect code.

OK.  But for those of us who are not qualified to comment on issues
related to those particular questions (which are quite non-trivial as I
understand it, but that's about all I know about it) how much
background should be documented in Axiom?  The idea of building
software itself from human readable languages into binaries?  The
reasons for platform differences?  The issues of compiling expressions
to Ultrasparc vs AMD64 binary code, and the consequences of the design
differences?

Personally, I think those types of questions (indeed most related to
building code) should be documented at a system-wide level as literate
programs (literate autoconf and automake) rather than be the
responsibility of Axiom.  I find this an attractive idea (which is why
things like the literate lisp implementation and things like
Movitz/CADR lisp machine code interest me) but personally I think there
has to be a point beyond which Axiom shouldn't have to go because Axiom
is a CAS, not an operating system.  I don't know for sure what the line
is, but (for example) I would rather leave the extremely messy issues
of building on different platforms to the autoconf/automake experts. 
Would it be nice of autoconf and automake were literate programs,
describing all the issues and how to deal with them?  Yes.  Is this
Axiom's responsibility?  I don't know.

> Unreasonable? Hardly. I've gotten a fair amount of grief over the
> design of the current Makefile tree. I've been told that it is
> unclear (even though the first paragraph of the top level Makefile
> starts explaining the design points). I've been told it is not
> 'standard' even though it preceeds automake by 10 years.

Standards are themselves a moving target, (hopefully) improved by
increasing knowledge and skill on the part of the people creating them.

> I've been
> told that it doesn't support 'standard stanzas' (like distclean,
> whatever that does). I've been told that it should use special
> GNU-make features (whereas it used to use standard make and used
> to build on Suns which it won't do now). I've been told that it
> is a complete mess even though it follows a very small number of
> design principles everywhere (stanza per file, makefile per 
> subdirectory, unique echo per stanza, Bill Page/$INT/$OBJ/$MNT variables,
> etc.

It is extremely unfortunate that these platform specific issues are
there to cause us trouble.  I think the idea of autoconf and automake
is to isolate programs from the lower level cross-platform issues, and
instead allow the program to focus on writing their own code, but I
confess I don't know enough about it to know for sure.  Gaby?

> Believe me, you're going to catch grief from the next person to
> touch the makefile process. At least explain why the new process
> does what it does so that you can point out where changes go against
> design principles (such as the src/int/obj/mnt principles).

That's reasonable.

> Above all, please try to make the transition to a literate mindset,
> at least while working on Axiom code. The future demands it.

I have been and am, but I make one final observation:

"To write literature with a language one must first be fluent in it."

Fluency in programming languages, like human languages, takes time and
practice.  Perhaps I should not be attempting any serious Axiom work
until I first achieve fluency.

\start
Date: Fri, 1 Sep 2006 17:29:46 -0400
From: Alfredo Portes
To: list
Subject: re: Requiring LaTeX

Hi everyone,

I know that probably I am the person of least programming experience
in the list, but I felt like commenting on this issue.

Axiom should only provide the packages that are "must have" and that the
user cannot install in their system by themselves. I do not think you
should convert your make process into a package manager.

If a special version of GCL is required for Axiom, then it should be
provided.
But if it falls under the criteria of Noweb, Latex, X, etc, ... that the
user can
install by themselves, then GCL and every other package should be also a
dependency. If their are not present then AXIOM is not compiled and the
error is shown to the user telling them what is needed.

Then you move to another level of providing packages for the different
distros
(at least the mayor ones) and use their respective package managers to
handle
the dependencies (yum, apt-get, emerge, pacman, (insert your favorite here).

> The new makefiles should be 3/4 documentation. They should discuss
> the design decisions (like separate build trees) based on today's
> understanding so that when the trends change (and they will) the
> next generation knows the why and how of the design. Why is it ok
> to require the user to install GCL but not Latex?

>>But we don't require the user to install GCL - Axiom deliberately
>>includes it in the tree as of now.  We DO require an external install
>>of LaTeX - is the plan to bundle some subset of TeX and LaTeX as well?
>>(I can see this if we have a cl-typesetting type solution since that
>>typesetting logic can also be used in GUI situations as well as
>>literate coding, but I don't think TeX was designed for this type of
>>situation.)

\start
Date: Fri, 1 Sep 2006 17:30:17 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Silver build-improvements: Hyperdoc

> >>  >/home/hemmecke/OTHER/Axiom/Silver/build-improvements/mnt/linux/../../share/doc/hypertex/bitmaps/axiom1.bitmap< 
> >> not found
> > 
> > This is fixed in --patch-50
> 
> No, that cannot be. ;-)
> 
> Since fixes in Gold should appear *BEFORE* in Silver, that fix cannot be 
> in Gold, since it is not in Silver.
> 
> If it is in Gold, then someone is hiding the good stuff from people 
> working on the Silver branch.
> 
> Tim, you should not just add improvements without telling others. That 
> makes frustrated developers who will soon get away from Axiom or fork a 
> new project. Do you want that?

ummm, the patch was posted to the list and i applied it.
it is hardly a secret fix.
see CHANGELOG item 20060814


i was working on the todo-list posted in the --patch-50 announce which read:

      update CVS on sourceforge
      update CVS on savannah
      diff -Naur Gold Silver and post patches
      ....

of which i've completed the first two and was working on the third
when the news arrived that --patch-50 fails on debian. so i balr'd
off ot build a debian box to debug the problem. debian had some
default setup issues (latex, xdev) which i had to solve. now debian
build stops in the algebra compile and i'm trying to debug the problem
as we speak. 

the plan is to diff Gold and Silver.... soon.

it's a holiday weekend here in the states which means i get an
extra day of axiom hacking.

\start
Date: Sat, 02 Sep 2006 00:03:10 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Silver build-improvements: Hyperdoc

> i was working on the todo-list posted in the --patch-50 announce which read:
> 
>       update CVS on sourceforge
>       update CVS on savannah
>       diff -Naur Gold Silver and post patches

> the plan is to diff Gold and Silver.... soon.

But that is the wrong order. Silver should have the patches before.
As I said I strongly believe that Silver trunk SHOULD be ALWAYS in sync 
with what you have in your tla archive.

Otherwise you are developing silver and the svn/trunk is gold.

BTW, when will there be the next official release of Gold. I haven't 
heard of any Axiom release recently. Or are you saying that --patch-50 
was a Gold-release? To be honest, I am still completely confused about 
all that. Am I alone?

Anyway, when Gold is released there should not be need to move patches 
from Gold to Silver/trunk. If that must happen then I think something is 
wrong.

\start
Date: Fri, 01 Sep 2006 18:10:28 -0400
From: William Sit
To: Bill Page
Subject: Re: obsolete pages and portal download

On Fri, 1 Sep 2006 11:01:07 -0400
  Bill Page wrote:
>Is this better?
>
>http://page.axiom-developer.org

Honestly? No. I did not check very carefully, but it seems 
all you did was adding a front page as your personal web 
page (which is good). But anyone reaching, say the page 
for Axiom portal (link given on the new page) would still 
be led to obsolete info like the Download link there. This 
is because as far as other users are concerned, these link 
are external to your personal page, and can be accessed 
either via your provided link or through say Google 
search.

I would suggest that we (you?) do a Google search on 
Axiom, and remove or update those pages (especially those 
on the top in the search results) if they are under our 
(your) control. The fewer past/obsolete pages appearing in 
the Google search results, the better (or if they do 
appear, users will have to use a cached copy, indicating 
possibly out-of-date material, and the direct link 
provided by Google should fail).

If you set me up to be able to edit or delete pages no 
longer needed, I'll spend some time to clean things up.

\start
Date: Fri, 1 Sep 2006 18:14:40 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: re: Requiring LaTeX
Cc: Gabriel Dos Reis

> Suppose you are an axiom-developer (and you can build everything of 
> Axiom on your local machine). Now person A is posting a message that 
> Axiom does not build on machine X for this or that reason. Let's say the 
> reason is that the binaries don't compile. You have access to a similar 
> machine X' and you have the feeling that you could solve the problem.

Here is where the change in MINDSET kicks in. 

The source code is [latex vs gcc] and someone posts a bug in a
program. You try to build the program and it fails in the [noweb-latex
vs gcc compile] step so you give up. Or you argue that you could take
the intermediate code [spad/lisp vs AST-RTL] and debug with that. (GCC
can generate intermediate files of abstract syntax trees (AST) or
register transfer language (RTL) which are system-independent.)
You can certainly build/debug with that.


> You checkout Axiom on X' start compilation and... the compilation stops 
> just after trying to latex the first Makefile.pamphlet, because 
> unfortunately, LaTeX is not installed on that machine and you don't have 
> root access to install it.

So if [noweb-latex vs gcc] is not installed you give up?
You don't need root access to install latex. It's just a program.
Latex can be installed locally with no problems. (perhaps we should
consider including it in zips :-) (joke, joke, ok?))

The point I'm trying to make is that not have latex is like not
having GCC. Axiom compiles code on the fly so you must have GCC.
If your development platform did not include GCC you can't build 
Axiom.

The second point is that just because something is technically
possible it is not a requirement that we support it. You CAN run
the final RTL-machine stage of GCC without running anything else
but nobody expects you to build from RTL.



It is perfectly reasonable to have a -nosource option. Many people
don't care about the source.

But not having source is just using a binary. It's not a build
environment.




It is not reasonable to build on a non-latex machine because in the
near future (assuming I have a creative burst that gets me over the
hump) we should be able to just drag-and-drop sources onto our 
browser-based hyperdoc. The whole process will fail without latex.
Future plans require it. Systems without latex will be like systems
without X11. Many useful features of Axiom won't be supported.



> In any case it simply would cost you too much time to look for a bugfix 
> and so you just say
> 
> rm -rf $AXIOMTREE
> 
> and don't even post on axiom-developer that you had tried to solve the 
> issue.

If a developer in a source forest gives up does the CVS tree hear it?



> A build system that builds parts of Axiom with fewer requirements (like 
> building binaries and no .dvi files) is just a PLUS for Axiom. That has 
> NOTHING to do with Tim's wish that Axiom should not (fully) build if 
> LaTeX is not available. It's just support for Axiom developers.

Ummm, I can take your argument further. Bill really wants us to work
on APT-GET installed programs like noweb (and latex). Suppose a
developer does not have root access. Can they APT-GET noweb? If not,
they could build a system version directly from the INT subdirectory
since this does not require the SRC subdirectory, latex, or noweb.

However we don't ship INT (which, if we did, would seriously speed
up the build process since it caches a lot of work). This elides
both the noweb and latex requirements. Is this a plus?




> But I will never go back to non-LP.

It would be hard for me to make the case that you are not
doing literate programming :-). 

I was trying to make the point that for any programmer it is as
hard to change to literate programming in a proper way as it is
to change to functional programming, parallel programming,
object-oriented programming or any other major sub-genre. 

True object-oriented programming uses strict message passing
(ala Smalltalk) and it is hard to learn. Using C++ to write
C programs is not object-oriented programming. From my point
of view using non-latex builds is extracting the post-C++
C code in order to compile. You still dress the king but
only in underwear. :-)




If build speed is the ONLY issue then just don't 'rm' anything.
There is NO reason to rebuild the system from scratch or make clean.
In theory you can change anything in the source tree, type
'make' and it SHOULD do the right thing. Otherwise make is broken.
One of the current design principles is that this should 'just work'.

\start
Date: Fri, 1 Sep 2006 17:32:54 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: Requiring LaTeX

On Fri, 1 Sep 2006, Ralf Hemmecke wrote:

| > | Latex is not optional, it is not overhead, it is not waste.
| > | If latex is not installed then axiom SHOULD NOT BUILD.
|
| I must say, I don't understand that. If you type "make" that will build
| the whole system. Why cannot there be some targets like "make binaries",
| "make doc" to split that process?

My original plan -- as I tried to communicate to Tim last week -- was
pricesely that we should make the process modula so that we have the
kind you subdivision you are proposing even if "make" just ends up
doing the whole.  I have seen *successful lagre projects* (much larger
and complex than Axiom) work that way.  Axiom is painting itself in a
coerner that can only harm it.

\start
Date: Fri, 1 Sep 2006 17:40:13 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Requiring LaTeX

On Fri, 1 Sep 2006, C Y wrote:

| --- Tim Daly wrote:
|
| > \begin{rant}
| >
| > We part company on this one.
| > I guess I'm alone in understanding that the Latex IS THE SOURCE.
| >
| > Latex is not optional, it is not overhead, it is not waste.
| > If latex is not installed then axiom SHOULD NOT BUILD.
|
| If we take that approach, then it is just as important to bundle TeX in
| some form along with Axiom as it is to bundle GCL.  Particularly on
| Windows, where an installation of TeX probably does not already exist.

we might probably want to bundle a working C compiler, a working
operating system, as well.

sorry, I could not resist.

\start
Date: Fri, 1 Sep 2006 17:56:19 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Requiring LaTeX

On Fri, 1 Sep 2006, C Y wrote:

| > I've been
| > told that it doesn't support 'standard stanzas' (like distclean,
| > whatever that does). I've been told that it should use special
| > GNU-make features (whereas it used to use standard make and used
| > to build on Suns which it won't do now). I've been told that it
| > is a complete mess even though it follows a very small number of
| > design principles everywhere (stanza per file, makefile per
| > subdirectory, unique echo per stanza, Bill Page/$INT/$OBJ/$MNT variables,
| > etc.
|
| It is extremely unfortunate that these platform specific issues are
| there to cause us trouble.  I think the idea of autoconf and automake
| is to isolate programs from the lower level cross-platform issues, and
| instead allow the program to focus on writing their own code, but I
| confess I don't know enough about it to know for sure.  Gaby?

Autoconf and Automake are now "standard" tools that insulate software
developers from lots of platform variabilities.  Tim claims he has
been told many things; as far as I'm concerned, those "things" were
most of the time backed with facts.

In April, I approched two friends of mine involved in linu
distributions (RH and SUSE) hoping to have them make Axiom part of
their distribution.  They said they won't touch this stuff if it does
not support cross-compilation.  We have two choices: ignore them, and
improve Axiom so that it becomes easy to build, therefore easier to
dsitrbute.  I suspect the later choice can only be beneficial to the
project.  That is why I set up to improve the build process.
Using Autoconf for example, it is a very simple matter to resolve the
X11 issue -- because people have hitted that problem many times and
Autoconf solved it once for all.  However, I've gotten the distinct
feeling that Axiom likes to build its own ghetto and solve problems
with known solution its own way.

Yesterday, I've gotten a student who is very exceited about what I
said about Axiom and he would like to work on provisos for example.
But, I'm very hesitant to launch him on the Axiom sources, because it
would take him inordinate amount of wasted time -- on distracting
build issue -- just to get to a point where he could be productive.

\start
Date: Fri, 1 Sep 2006 18:48:42 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Silver build-improvements: Hyperdoc

> > the plan is to diff Gold and Silver.... soon.
> 
> But that is the wrong order. Silver should have the patches before.
> As I said I strongly believe that Silver trunk SHOULD be ALWAYS in sync 
> with what you have in your tla archive.
> 
> Otherwise you are developing silver and the svn/trunk is gold.
> 
....[snip]....
> 
> Anyway, when Gold is released there should not be need to move patches 
> from Gold to Silver/trunk. If that must happen then I think something is 
> wrong.

i refer you to prior emails... 

point 1 is that until recently i did not have a working svn client and
could not patch silver. thus, i didn't.

point 2 is that silver was intended as a testing ground for ideas
whereas gold is a place where official system builds reside.

point 3 is that i don't have the time to maintain silver with the
very latest patches in any reliable way. unseen behind the gold
curtain is that a lot of testing occurs for each patch on many
systems so it 'just works'. this testing occurs in batches every
two months or so. i can't apply silver patches and not test them
and i don't have the time to test them as they are posted.

point 4 is that bug fixes don't necessarily change anything interesting
in the 'mission' of silver which is to allow developers a place to make
major system changes in public.

point 5 is that i promised to bring silver up-to-date as of this
gold release and then apply patches there at the same time as i
apply patches to my local copy of gold, regardless of breakage.
thus silver will appear to lead the official gold releases in 
the future.




> BTW, when will there be the next official release of Gold. I haven't 
> heard of any Axiom release recently. Or are you saying that --patch-50 
> was a Gold-release? To be honest, I am still completely confused about 
> all that. Am I alone?

gold (--patch-50) went out on 8/29. look in the email archives for a
subject of '--patch-50' or look at the CHANGELOG in the root of the
axiom--main--1--patch-50 for a list of changes.

each --patch-NN level is a 'gold release' and they are supposed to
occur at 2 month intervals (see the email archives) since 2 months
is short enough to wait for an official fix but long enough that
i don't spend all my time testing.

\start
Date: Fri, 1 Sep 2006 18:02:39 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Requiring LaTeX

On Fri, 1 Sep 2006, root wrote:

| You don't need root access to install latex.

True.  But is latex *really* required to install and run axiom.  The
answer is no.  Are all people' times best spent in installing latex on
all machines when the real issue is to test for *axiom*
functionnalities?  You have to ask yourself how you can best benefit
from people's limited time.

If you believe that latex is required for Axiom, I must delcare that
you have not understood literate programming.  And I'm not joking;
sadly. :-(

[...]

| It is not reasonable to build on a non-latex machine because in the
| near future (assuming I have a creative burst that gets me over the
| hump) we should be able to just drag-and-drop sources onto our
| browser-based hyperdoc. The whole process will fail without latex.

when that wonderful time comes, we will advise.

| Future plans require it.

But we have to live with the present too.

| Systems without latex will be like systems without X11.

Not really.  Really check.

\start
Date: Fri, 1 Sep 2006 19:01:37 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Requiring LaTeX

> In April, I approched two friends of mine involved in linu
> distributions (RH and SUSE) hoping to have them make Axiom part of
> their distribution.  They said they won't touch this stuff if it does
> not support cross-compilation.  We have two choices: ignore them, and

Please explain what you mean by cross-compilation.

You can NFS mount SRC, set the AXIOM variable for the current system,
type 'make' and it will cross-compile. We've been able to do this 
since 1985 or so. I used it to build on Suns, Symbolics, AIX, and
several other systems on a daily basis. If you also NFS mount INT
you can used the cached work on a cross-platform build.

\start
Date: Sat, 02 Sep 2006 01:21:32 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: re: Requiring LaTeX
Cc: Gabriel Dos Reis

On 09/02/2006 12:14 AM, root wrote:
>> Suppose you are an axiom-developer (and you can build everything of
>>  Axiom on your local machine). Now person A is posting a message 
>> that Axiom does not build on machine X for this or that reason. 
>> Let's say the reason is that the binaries don't compile. You have 
>> access to a similar machine X' and you have the feeling that you 
>> could solve the problem.
> 
> Here is where the change in MINDSET kicks in.
> 
> The source code is [latex vs gcc]
                      ^^^^^^^^^^^^^^
What does that mean?

> and someone posts a bug in a program. You try to build the program 
> and it fails in the [noweb-latex vs gcc compile] step so you give up.
> 
> 
> 
Yes. Because from the description of the build failure posted I had some
feeling what is going wrong. But I cannot reproduce it. Since my build
doesn't come to that point.

> Or you argue that you could take the intermediate code [spad/lisp vs 
> AST-RTL] and debug with that. (GCC can generate intermediate files of
> abstract syntax trees (AST) or register transfer language (RTL) which
> are system-independent.) You can certainly build/debug with that.

I don't even have "intermediate code".

I really don't understand why you insist on preventing people from
contributing to Axiom. It is all community work. If someone understands
what is going on and posts a fix. That is much quicker than having to
wait for someone how has the right environment, understands the problem,
is able to fix it. Note that I could even post a patch that fixes a
problem without having latex on machine X'. Note that I have
(deliberately) included a phrase in parentheses in my first sentence
above. I either do it on my local machine and testing the latex build
there and the binary build on X'. Then I could send a fully documented
patch and everyone would be happy. No?

And even if I submit a patch that does contain a latex error. The guy
who posted the problem could check the binary build and fix the latex
stuff and post a correction patch. That is distributed development! You
need not have just one person knowledgable in everything.

I fully understand that for the enduser you want latex, noweb and
everything, but what does that have to do with developers doing
distributed development to produce proper pamphlets?

>> You checkout Axiom on X' start compilation and... the compilation 
>> stops just after trying to latex the first Makefile.pamphlet, 
>> because unfortunately, LaTeX is not installed on that machine and 
>> you don't have root access to install it.

> So if [noweb-latex vs gcc] is not installed you give up? You don't 
> need root access to install latex. It's just a program. Latex can be 
> installed locally with no problems.

Of course, I could install it. But why should I invest my precious time
with installng LaTeX (or anything else) if it is actually not needed for
what I am trying to achieve.

> The point I'm trying to make is that not have latex is like not 
> having GCC.

Really? If I write a paper, I don't care whether gcc is installed. LaTeX
is what counts. It all depends on what I want to achieve.

> It is perfectly reasonable to have a -nosource option. Many people 
> don't care about the source.
> 
> But not having source is just using a binary. It's not a build 
> environment.

There are simply different use cases for Axiom. Some people USE
mathematical theorems but are unable to prove them or even to invent new
ones. What you are saying is: I consider those people not as my target
audience for application of mathematics.

> If build speed is the ONLY issue then just don't 'rm' anything. There
>  is NO reason to rebuild the system from scratch or make clean.

Right. But if I don't have latex and change a pamphlet, I am lost.

> One of the current design principles is that this should 'just work'.

Wasn't there someone who said that --patch-50 does not build on debian?

\start
Date: Fri, 1 Sep 2006 19:27:13 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: re: Requiring LaTeX
Cc: Gabriel Dos Reis

> One of the current design principles is that this should 'just work'.
>
> Wasn't there someone who said that --patch-50 does not build on debian?

There was. I'm debugging it now.

I have RH7.2, RH9, FC4, FC5, Ubuntu, FreeBSD (not working yet), MAC OSX
(not working yet), XP2 (partial), Red Flag Linux, Knoppix and Doyen running 
on various machines.  I've tried to build a SUSE machine and a Solaris x86
machine without success so far. I've tested Axiom on the working machines.

I just built a new Debian machine to extend testing to that platform
which has not been a problem in the past. Future releases will be tested.

It should 'just work' but I keep finding new 'features' in new versions
of operating systems that require me to extend my local compile farm
(thus extending the effort to create gold). For instance, FC5 broke the
X portion of the system. Renaud pointed this out to me in July at ISSAC
so I built an FC5 system to test it. (A motherboard failure (since fixed)
delayed the release of gold).

I can't claim that it does 'just work' but I do try hard to make it so.

\start
Date: Fri, 1 Sep 2006 18:39:58 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Requiring LaTeX

On Fri, 1 Sep 2006, root wrote:

| > In April, I approched two friends of mine involved in linu
| > distributions (RH and SUSE) hoping to have them make Axiom part of
| > their distribution.  They said they won't touch this stuff if it does
| > not support cross-compilation.  We have two choices: ignore them, and
|
| Please explain what you mean by cross-compilation.

Benjamin Kosnik tried to explain that in April on this list.
Imagine I'm running on x86-based machine, and I must build binaries
for a PowerPC-based systems.

http://en.wikipedia.org/wiki/Cross-compiling
http://www.airs.com/ian/configure/configure_5.html

and if you want an example of what I'm talking about

http://www.mozilla.org/build/cross-compiling.html

| You can NFS mount SRC, set the AXIOM variable for the current system,

Sorry to say, but that is way, far way insufficient to provide
cross-compilation. Furthermore, as I demonstrated earlier, the current
scheme just does NOT work.  I've tried it!

\start
Date: Fri, 1 Sep 2006 18:43:50 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: Requiring LaTeX

On Sat, 2 Sep 2006, Ralf Hemmecke wrote:

| I really don't understand why you insist on preventing people from
| contributing to Axiom.

if we allow build of Axiom without requiring latex, Axiom might be in
the danger of being tested and used in more environments, and we might
have more users; that should not be allowed.

\start
Date: Fri, 1 Sep 2006 18:45:41 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Requiring LaTeX

On Fri, 1 Sep 2006, root wrote:

| I can't claim that it does 'just work' but I do try hard to make it so.

everybody is trying hard.  You have to admit that if you open the door
for more testing, you might have more hands to help you.  Maybe you
don't want that, I don't really know.

\start
Date: Sat, 02 Sep 2006 01:56:17 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: re: Requiring LaTeX
Cc: Gabriel Dos Reis

On 09/02/2006 01:27 AM, root wrote:
>> One of the current design principles is that this should 'just work'.
>>
>> Wasn't there someone who said that --patch-50 does not build on debian?
> 
> There was. I'm debugging it now.
> 
> I have RH7.2, RH9, FC4, FC5, Ubuntu, FreeBSD (not working yet), MAC OSX
> (not working yet), XP2 (partial), Red Flag Linux, Knoppix and Doyen running 
> on various machines.  I've tried to build a SUSE machine and a Solaris x86
> machine without success so far. I've tested Axiom on the working machines.

Next time before you release gold, just make an announcement. Then 
people (like me for example) could download silver/trunk (which should 
be the upcoming release) and test it. That way some burden of testing is 
released from you and nobody on the axiom-developer mailing list could 
say after the gold release that it doesn't build on his system.

What about that suggestion? Or do you really want to test everything 
alone and wait for complaints after the release?

\start
Date: 01 Sep 2006 18:59:39 -0500
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: re: Requiring LaTeX

Alfredo Portes writes:

[...]

| If a special version of GCL is required for Axiom, then it should be
| provided.
| But if it falls under the criteria of Noweb, Latex, X, etc, ... that the
| user can
| install by themselves, then GCL and every other package should be also a
| dependency. If their are not present then AXIOM is not compiled and the
| error is shown to the user telling them what is needed.

If we restrict ourselves sufficiently enough, we would find that 
Earth is flat -- we just have to check our office or bedroom.

It is a fundamental mistake to believe that people can or have the
right install things; and even if they technically can, they would do
so.  Axiom should minimize that dependency.

LaTeX is not fundamental to build Axiom.  
Similarly, Axiom needs not run under X11.
Axiom needs GCL and a working C compiler. Those are different stories.
You can expect a C compiler from the build environment.
GCL you can't expect, so it makes sense to put a copy of it in Axiom
-- though ideally, we would like not to.

Someone, peopel seems to interpret allowing Axiom to be built if latex
is not present as making Axiom non-literate.  I highly suspect that is
a religiously mis-representation of what literate programming is.
Furthermore, we have to face the reality and ask ourselves what we can
do to gradually make Axiom a computing platform of choice.  I don't
believe we will get there by being rigid about the build environment.
The minimum requirements should not include latex nor X.

Three days ago, I had my copy of Mathematica and sadly look over the
bill.  Yet, I'm happy with the product (and very unhappy about what it
costs).  The reason being that I can have students' limited time best
spent there.  I certainly don't want them get swamped in rigid
approach to literate programming, when they have valuable contribution
to make.  I must confess that, however enthusiastic I'm about Axiom.

\start
Date: 01 Sep 2006 19:01:24 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Silver build-improvements: Hyperdoc

Ralf Hemmecke writes:

| On 09/01/2006 08:14 PM, root wrote:
| >>
| >> >/home/hemmecke/OTHER/Axiom/Silver/build-improvements/mnt/linux/../../share/doc/hypertex/bitmaps/axiom1.bitmap<
| >> not found
| > This is fixed in --patch-50
| 
| No, that cannot be. ;-)
| 
| Since fixes in Gold should appear *BEFORE* in Silver, that fix cannot
| be in Gold, since it is not in Silver.
| 
| If it is in Gold, then someone is hiding the good stuff from people
| working on the Silver branch.

You have to realize that the branch silver is actually a trap. :-(

| Tim, you should not just add improvements without telling others. That
| makes frustrated developers who will soon get away from Axiom or fork
| a new project.

How true.

\start
Date: 01 Sep 2006 19:03:34 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Silver build-improvements: Hyperdoc

Tim Daly writes:

| > >>  >/home/hemmecke/OTHER/Axiom/Silver/build-improvements/mnt/linux/../../share/doc/hypertex/bitmaps/axiom1.bitmap< 
| > >> not found
| > > 
| > > This is fixed in --patch-50
| > 
| > No, that cannot be. ;-)
| > 
| > Since fixes in Gold should appear *BEFORE* in Silver, that fix cannot be 
| > in Gold, since it is not in Silver.
| > 
| > If it is in Gold, then someone is hiding the good stuff from people 
| > working on the Silver branch.
| > 
| > Tim, you should not just add improvements without telling others. That 
| > makes frustrated developers who will soon get away from Axiom or fork a 
| > new project. Do you want that?
| 
| ummm, the patch was posted to the list and i applied it.

I missed it.  Please could you give me a pointer to it?

\start
Date: 01 Sep 2006 19:08:04 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Silver build-improvements: Hyperdoc

Tim Daly writes:

[...]

| point 1 is that until recently i did not have a working svn client and
| could not patch silver. thus, i didn't.

see?  Now imagine, I don't have latex on a machine I would like to
check Axiom on.  That *is* reality.

| point 2 is that silver was intended as a testing ground for ideas
| whereas gold is a place where official system builds reside.

My understanding and recollection are that silver is a testbed and
only good ans well-tested ideas move to gold, *and* fixes to gold must
be present in silver.  Otherwise, the wholse excercise becomes
pointless. 

| point 3 is that i don't have the time to maintain silver with the
| very latest patches in any reliable way.

I don't think people ask you to maintain silver -- that is why I
volunteered for it.  However, people are asking that if you have a fix
for a problem in both golden and silver, make sure it gets applied to
silver first.

\start
Date: Fri, 1 Sep 2006 20:24:41 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: Requiring LaTeX

> | I can't claim that it does 'just work' but I do try hard to make it so.
> 
> everybody is trying hard.  You have to admit that if you open the door
> for more testing, you might have more hands to help you.  Maybe you
> don't want that, I don't really know.

I believe this discussion started because I suggested using the 
sourceforge compile farm for testing. You eventually replied that
since the sourceforge farm didn't supply latex on certain platforms
you were not going to test them. But you can install latex.

I want testing, especially for the build mechanism.

\start
Date: Fri, 1 Sep 2006 20:55:10 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: Requiring LaTeX

> | I really don't understand why you insist on preventing people from
> | contributing to Axiom.
> 
> if we allow build of Axiom without requiring latex, Axiom might be in
> the danger of being tested and used in more environments, and we might
> have more users; that should not be allowed.

Ralf, Gaby,

Are these reasonable statements?

Axiom source code is available on 3 platforms. All posted patches have
been applied. On my private server many users have personal userids;
22 people have read/write access to the Arch repository. There are
over half-a-dozen 'private' arch branches created for users, Camm has
a private userid for assisting Axiom/GCL testing, I set up the initial
SVN repository and gave Gaby Administrator access to do anything he
wants on the sourceforge site.  I've done many off-list handholding
efforts for people who are starting with the system. I've encouraged
major changes like using ALLPROSE everywhere. I've helped with private
development of Aldor. Six people have admin access on savannah (Me,
David, Camm, Juergen, Bill, and Dylan) and three people have admin access
on sourceforge (Me, Bill, Gaby). All have the right and ability to
change Axiom any way they want. In all nearly 30 people can completely
rewrite the system, including the golden sources.

In what way are people being prevented from contributing?

Axiom used to build directly from non-latex sources. These sources
still exist in Arch and CVS. There are more Axiom users now than
there were prior to the latex builds. There is nothing to prevent
you from creating a non-latex SVN branch that uses these sources.

So far only the Debian default system does not include Latex.
Latex can be built for a single user. In what way does using
latex cause the world to turn away?



I admit to having strongly religious views of the way I believe Axiom
should be built but that doesn't mean you have to agree.  It doesn't
mean you can't change things. In fact I encourage you to try.  If you
really believe latex is a blocking condition then build the system
without it.  This is, after all, open source and there is nothing
stopping you from proving your point. Certainly not me.

\start
Date: Fri, 1 Sep 2006 20:04:30 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Requiring LaTeX

On Fri, 1 Sep 2006, root wrote:

| > | I can't claim that it does 'just work' but I do try hard to make it so.
| >
| > everybody is trying hard.  You have to admit that if you open the door
| > for more testing, you might have more hands to help you.  Maybe you
| > don't want that, I don't really know.
|
| I believe this discussion started because I suggested using the
| sourceforge compile farm for testing. You eventually replied that
| since the sourceforge farm didn't supply latex on certain platforms
| you were not going to test them. But you can install latex.
|
| I want testing, especially for the build mechanism.

As I said earlier, I do want to do the testing -- I don't think I've
proposed anything amounting to do merge on silver without testing on
enough platforms.  I've called for help for testing earlier.

I just don't want to go and install "random" tools on all the SF
compile farm machines and spend time making sure that when I switch to
a different platform my PATH pick the right binaries.

\start
Date: Fri, 1 Sep 2006 20:56:47 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: re: Requiring LaTeX
Cc: Gabriel Dos Reis

> Next time before you release gold, just make an announcement. Then 
> people (like me for example) could download silver/trunk (which should 
> be the upcoming release) and test it. That way some burden of testing is 
> released from you and nobody on the axiom-developer mailing list could 
> say after the gold release that it doesn't build on his system.
> 
> What about that suggestion? Or do you really want to test everything 
> alone and wait for complaints after the release?

Ralf,

I just got SVN access 2 weeks ago. 
Until that time I was unable to change silver.

\start
Date: Fri, 1 Sep 2006 20:19:37 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Requiring LaTeX

On Fri, 1 Sep 2006, root wrote:

| > | I really don't understand why you insist on preventing people from
| > | contributing to Axiom.
| >
| > if we allow build of Axiom without requiring latex, Axiom might be in
| > the danger of being tested and used in more environments, and we might
| > have more users; that should not be allowed.
|
| Ralf, Gaby,
|
| Are these reasonable statements?

To some extent, they reflect the frustration grown out of what I see
as unreasonable rigid requirements.  I apologize if you feel bad about
it, but they reflect some reality and I would encourage you to take
them into account.

[...]

| In what way are people being prevented from contributing?
|
| Axiom used to build directly from non-latex sources. These sources
| still exist in Arch and CVS.

I suspect that what we are saying is that, instead of telling users grab
yet that another branch somewhere else, make the mainstream ones
sufficiently "accessible" in the sense that they don't require too
much dependencies.  Those are not unreasonable statements.

I may not have looked sufficiently, but I was not under the impression
that we have so much reousrce that we can afford unfocused branches
multiplied ad infinitum, and wasted efforts.

| There are more Axiom users now than
| there were prior to the latex builds. There is nothing to prevent
| you from creating a non-latex SVN branch that uses these sources.

I suspect that is the part you don't want to aapreciate.  I'm not
interested in working on any branch on something that is not
mainline.  And I certainly don't have the desire to spend time on
a branch of Axiom when I do know from the outset that it is wasted
time.  So the question: is there sufficient value in allwoing Axiom to
build in an environment lacking latex.  The answer is yes.  You say no
with the emphasis that if latex is missing then the build must fail.
When, you hold that view so strongly, how do you really believe you
encourage people to make contributions to Axiom?  Apparently, I have
machines I can help testing Axiom functionalities if Axiom is allowed
to build if latex is missing.

| So far only the Debian default system does not include Latex.

the SF compile farm hosts where latex is missing are not just debian
systems.  Please check.

| Latex can be built for a single user. In what way does using
| latex cause the world to turn away?

It does prevent people from effectively testing Axiom, when in
fact latex is not necessary to test Axiom's functionnalities.

| I admit to having strongly religious views of the way I believe Axiom
| should be built but that doesn't mean you have to agree.  It doesn't
| mean you can't change things. In fact I encourage you to try.  If you
| really believe latex is a blocking condition then build the system
| without it.

Good!  The question is whether you guarantee NOT to give the work
consideration.

\start
Date: Fri, 1 Sep 2006 19:51:00 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis, Tim Daly
Subject: re: Requiring LaTeX

If I may, I have a couple questions/observations:

1)  If there is functionality developed in a branch, what are the
mechanisms for deciding if this functionality will become part of the
"main" branch?  This is not clear currently.

2)  One view of having large numbers of divergent branches is that it
splits project resources across many uncoordinated efforts, diluting
the effect each branch can achieve - the "many-branches" development
model is a lot like forking, which open source has an adversion too
except under extreme circumstances (like XFree86 vs. X.org).  The
reason for this is simple - development in isolation increases the risk
that a significant development effort will result in work that is not
accepted by the large community as part of the "official" distribution,
and dilutes effort which could have made the original project better. 
Marketing dictates that users, with understandably limited attention
spans, will not wish to expend the effort to understand many similar
forks of software.  When competiting for that attention, focus is
critical.  How do many individual divergent branches impact the user
perception of Axiom as a focused product likely to deliver results?

3)  If we are going to require TeX/LaTeX as a core component, what is
the minimal subset of (say) TeTeX and MikTeX that will provide us with
the functionality we need to create pamphlet file builds?  We include
GCL because it prevents issues with GCL as a separate program, and now
the evidence suggests that this procedure might also be needed if LaTeX
is never to be an issue on any platform.

I understand the desire to have full functionality with minimal
requirements from the system - on Windows it is almost essential.  But
with automake/autoconf we should be able to have our cake and eat it
too.  If the only way to resolve this is to have either an
external-latex or internal-latex build option and build whatever subset
of TeX is actually required for Axiom, how difficult would that be to
achieve?

A good open source project always requires some compromise, so if I may
let me suggest we see if there is some solution that can be found which
lets us move forward.  As I understand it:

a)  One side of this argument is that any build options which encourage
the use of non-literate programming styles of development should be
discouraged in order to promote the usage of literate programming as a
style.

b)  Another side is that minimal testing of machine-program
functionality on systems without LaTeX is a valid check on the
portability of Axiom to the new platform.

What about this?  If we accept that LaTeX is an indespensible part of
the build process, we treat it like GCL and provide enough of TeX and
LaTeX internally to produce what we need.  However, we also create a
config option which will check only the machine level code, including
the building of TeX itself.  (If TeX doesn't build on a platform this
will be held a bug Axiom must deal with, the same as a GCL bug.)  This
will accomidate work styles different from that of the fully literate
program writer (which is a rare breed both in terms of training and the
skill level needed), and ultimately any patches submitted back to Axiom
(from whatever source) must be quality vetted by the core team anyway
in order to ensure the standards have been met.  The default settings
will not neglect the LaTeX build - a developer would have to
specifically seak out a way to not build the LaTeX based components of
the system.  Similar to the "--without-X" option in some software - you
don't go looking for it unless there is a reason you want it.  We can
argue about whether there SHOULD be a reason to want it, but the tool
is there for those who want to use it.  Coversion to literate
programming is a gradual process, I think, and making it smoother/more
gradual for those new to it is most likely a good idea - in the end,
those who might have given up early can be eased onto the hook ;-)

The drawback, of course, is that this would be one more bundled package
in Axiom.  However, the autoconf work should make this ultimately an
optional choice - download only Axiom and try to build using only
externals (GCL, LaTeX) or download a much larger system that requires
only the most rudimentary bootstrapping binaries conceivable.  There
are two philosophies at work here, and I would rather see both
accomidated to some degree and allow us to keep our coherence as a
project.  But that's just me.

\start
Date: Fri, 1 Sep 2006 23:59:23 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: Requiring LaTeX

On September 1, 2006 6:33 PM Gabriel Dos Reis wrote:

> Tim Daly wrote:
> | > | Latex is not optional, it is not overhead, it is not waste.
> | > | If latex is not installed then axiom SHOULD NOT BUILD.
> |

I seems to me that Tim is like "the man who mistook his hammer
for a house". ;)

> On Fri, 1 Sep 2006, Ralf Hemmecke wrote:
> | I must say, I don't understand that. If you type "make" 
> | that will build the whole system. Why cannot there be some
> | targets like "make binaries", "make doc" to split that
> | process?
> 
> My original plan -- as I tried to communicate to Tim last week --
> was precisely that we should make the process modular so that
> we have the kind of subdivision you are proposing even if "make"
> just ends up doing the whole.  I have seen *successful lagre
> projects* (much larger and complex than Axiom) work that way.
> Axiom is painting itself in a corner that can only harm it.
> 

Silver is the logical "escape route" for me. :) I will be glad to
do everything I can to support it's continued development along
the lines proposed above.

\start
Date: Sat, 2 Sep 2006 00:42:07 -0400
From: Tim Daly
To: Bill Page
Subject: re: Requiring LaTeX
Cc: Gabriel Dos Reis

Well, after much discussion with a friend....

Are you all concerned that the new makefile won't get into gold?
Because I have philosophical problems with the idea of non-latex builds?
Have I ever said that I wouldn't accept it? 
Have I even said it's up to me?

\start
Date: Sat, 2 Sep 2006 01:47:42 -0400
From: Tim Daly
To: list
Subject: Debian build failure

It appears that the src/algebra/Makefile fails.
This Makefile is dynamically created by the findAlgebraFiles script.

The awk script attached to the BOOTSTRAP routine in findAlgebraFiles
does not created the required .lsp files.

The script reads:

egrep '<<.*BOOTSTRAP>>=' *.spad.pamphlet | sort | uniq | \
awk -F: '{
  chunk=substr($2,3,length($2)-5);
  split(chunk,part," ");
  lspfile="\${MID}/"part[1];
  print lspfile": \${IN}/"$1;
  print "\t@\${TANGLE} -R\""chunk"\" \${IN}/"$1">"lspfile;
  print "";
}'


Does anyone see anything in this script that might fail on debian
systems but work on other linux systems?

\start
Date: Sat, 02 Sep 2006 10:22:09 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Debian build failure

I don''t really understand, what you mean here. In Makefile.pamphlet I 
read in section

\subsection{Write the Makefile stanzas for the bootstrap files}

the following text:

Finally we output two lines:
\begin{verbatim}
${MID}/vector.spad.pamphlet: ${IN}/vector.spad.pamphlet
	${TANGLE} -R"VECTOR.lsp BOOTSTRAP" ${IN}/vector.spad.pamphlet 
 >${MID}/VECTOR.lsp
\end{verbatim}

So findAlgebraFiles does NOT write any .lsp file. It writes Makefile 
stanzas to stdout. If you want .lsp files you must say

make ${MID}/vector.lsp

BTW. If you carefully compare the generated lines in the Makefile and 
the above verbatim text then you realize that the target is something like

${MID}/vector.lsp

and not

${MID}/vector.spad.pamphlet

so the script does better than the documentation.

Ralf


On 09/02/2006 07:47 AM, root wrote:
> It appears that the src/algebra/Makefile fails.
> This Makefile is dynamically created by the findAlgebraFiles script.
> 
> The awk script attached to the BOOTSTRAP routine in findAlgebraFiles
> does not created the required .lsp files.
> 
> The script reads:
> 
> egrep '<<.*BOOTSTRAP>>=' *.spad.pamphlet | sort | uniq | \
> awk -F: '{
>   chunk=substr($2,3,length($2)-5);
>   split(chunk,part," ");
>   lspfile="\${MID}/"part[1];
>   print lspfile": \${IN}/"$1;
>   print "\t@\${TANGLE} -R\""chunk"\" \${IN}/"$1">"lspfile;
>   print "";
> }'
> 
> 
> Does anyone see anything in this script that might fail on debian
> systems but work on other linux systems?

\start
Date: Sat, 2 Sep 2006 04:23:07 -0400
From: Tim Daly
To: list
Subject: Debian build failure

I found it.

On most lisp systems the egrep/awk script creates stanzas that look like:

${MID}/ABELGRP.lsp: ${IN}/catdef.spad.pamphlet
	@${TANGLE} -R"ABELGRP.lsp BOOTSTRAP" ${IN}/catdef.spad.pamphlet>${MID}/ABELGRP.lsp


but on Debian the lines look like:

\${MID}/ABELGRP.lsp: \${IN}/catdef.spad.pamphlet
	@\${TANGLE} -R"ABELGRP.lsp BOOTSTRAP" \${IN}/catdef.spad.pamphlet>\${MID}/ABELGRP.lsp


It looks like debian's awk uses a different convention of escape characters.
I'll have to write a special case version for debian in the morning.

\start
Date: Sat, 02 Sep 2006 10:48:13 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Debian build failure

Hi Tim,

Interesting. The two lines from my src/algebra/Makefile look like

${MID}/VECTOR.lsp: ${IN}/vector.spad.pamphlet
	@${TANGLE} -R"VECTOR.lsp BOOTSTRAP" 
${IN}/vector.spad.pamphlet>${MID}/VECTOR.lsp

No \ there.

I am using debian.

awk --version
GNU Awk 3.1.4

But I also heard that there is some issue with \ in awk.

Ralf

On 09/02/2006 10:23 AM, root wrote:
> I found it.
> 
> On most lisp systems the egrep/awk script creates stanzas that look like:
> 
> ${MID}/ABELGRP.lsp: ${IN}/catdef.spad.pamphlet
> 	@${TANGLE} -R"ABELGRP.lsp BOOTSTRAP" ${IN}/catdef.spad.pamphlet>${MID}/ABELGRP.lsp
> 
> 
> but on Debian the lines look like:
> 
> \${MID}/ABELGRP.lsp: \${IN}/catdef.spad.pamphlet
> 	@\${TANGLE} -R"ABELGRP.lsp BOOTSTRAP" \${IN}/catdef.spad.pamphlet>\${MID}/ABELGRP.lsp
> 
> 
> It looks like debian's awk uses a different convention of escape characters.
> I'll have to write a special case version for debian in the morning.

\start
Date: Sat, 2 Sep 2006 07:23:23 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Requiring LaTeX

On Sat, 2 Sep 2006, root wrote:

| Well, after much discussion with a friend....
|
| Are you all concerned that the new makefile won't get into gold?
| Because I have philosophical problems with the idea of non-latex builds?
| Have I ever said that I wouldn't accept it?
| Have I even said it's up to me?


You are the one who decides what goes into gold.  When you say
something about what should happen to Axiom, it carries lot of weight.

\start
Date: 02 Sep 2006 06:55:33 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: Requiring LaTeX

Cliff Yapp writes:

| If I may, I have a couple questions/observations:
| 
| 1)  If there is functionality developed in a branch, what are the
| mechanisms for deciding if this functionality will become part of the
| "main" branch?  This is not clear currently.

In April 2006, I think Ralf asked similar question and I tried to
answer as best as I could.  From my perspective, a functionnality
developed on a branch needs to 

   1) be well-tested,
   2) have a well-documented patch (e.g. following the accepted
      programming methodogy),
   3) be reviewed by the "core" developers, (e.g. Tim), for acceptance
      or rejection.

\start
Date: Sat, 02 Sep 2006 10:10:52 -0400
From: Raymond Rogers
To: Tim Daly
Subject: Re: --patch-50

root wrote:
>>> does it compile in debian stable?
>>> i'll try to build a debian machine here.
>> I don't know. I have modified the XLIB variable (Debian testing) in
>> Makefile.pamphlet. Debian stable uses X11R6/lib directory I believe.
> 
> This is what the 'fedora5' stanza does automatically.
> You get this stanza with
> 
> export AXIOM=`pwd`/mnt/fedora5
> 

I would like to comment; it's more correct to change this option to
something like X Window System Version 7.0.0 I believe that this x11
version moved the lib, thus a compile test like Xorg -version is more
in line with reality than selecting fedora5.  All of the other
distributions (and perhaps individuals upgrading) will (or should)
track this.  IMHO things like this have to be folded in, in a
systematic manner; this type of change is not going away.

I keep hoping for stability but it's not happening.
Ray

\start
Date: Sat, 02 Sep 2006 11:08:10 -0400
From: Raymond Rogers
To: list
Subject: re: Requiring LaTeX

Alfredo,

Oh, please please; what good is "literate programing" if nobody
understands what is said.  Known error outs should automatically tell
the user (typically inexperienced) what to do.

Ray

Alfredo Portes wrote:
 and the
> error is shown to the user telling them what is needed.
> 

\start
Date: Sat, 2 Sep 2006 12:02:12 -0400
From: Alfredo Portes
To: Raymond Rogers
Subject: re: Requiring LaTeX

Ray,

On 9/2/06, Raymond E. Rogers Raymond Rogers wrote:Alfredo,
        Oh, please please; what good is "literate programing" if nobody
understands what is said.  Known
error outs should automatically tell the user (typically inexperienced) what
to do.

Ray

Alfredo Portes wrote:
and the
> error is shown to the user telling them what is needed.
>

I would argue the contrary, that this doesn't always happen. Windows systems
are the best example. What in the world do I do if I get a window saying:

"unknown error".
"error: c456cpetht..."
"the system has recovered from a serious error"

That doesn't have to do anything with LP. And type of error messages like
this are written by world top programmers.

My point was that I see now two camps in the mailing list. I could be a
regular user of Axiom, so my hope will be always to just say "apt-get
install axiom" or any other package manager. If I am trying to compile it
and I am missing something, then this should be clear. Who has not spent
time trying to figure out some dependency because it was not clear what
broke at compilation time. (maybe only me, nooby :-) ).

In a perfect world Axiom would not have any dependency, but if it must
have it then let the user install it in the system. How hard is to
have latex on a system nowdays. I am with Tim in this, regarding that
future projects will require latex (browser hyperdoc...). Axiom is in
LP style, Latex/Noweb is the current tool in Axiom to achieve this,
how can Latex not be a requirement?

I understand that it makes it harder for the testing purposes on other
systems, but I think is not that much of a problem as it sounds in this
thread. Of course I could be totally wrong, with everybody more experienced
than me actually doing the work (easy to talk in the bench) .

I hope that was the problem you were talking about, and not my English.
Sorry if I am not clear in my writting (I have only 4 years living in US.
Funny enough 4 years ago I was not able to ask for coffee in a restaurant,
much less think that I would be able to write suggestions for such a  great
project like Axiom).

\start
Date: Sat, 02 Sep 2006 12:41:39 -0400
From: Raymond Rogers
To: Alfredo Portes
Subject: re: Requiring LaTeX

Alfredo Portes wrote:
> Ray,
> 
> On 9/2/06, *Raymond E. Rogers* <Raymond Rogers
> Alfredo,
>         Oh, please please; what good is "literate programing" if nobody
> understands what is said.  Known
> error outs should automatically tell the user (typically inexperienced)
> what to do.
> 
> Ray
> 
> Alfredo Portes wrote:
> and the
>> error is shown to the user telling them what is needed.
>>
> 
> I would argue the contrary, that this doesn't always happen. Windows
> systems are the best example. What in the world do I do if I get a
> window saying:
> 
> "unknown error".
> "error: c456cpetht..."
> "the system has recovered from a serious error"
> 
I have no idea, and that was the point I was trying to make.

> That doesn't have to do anything with LP. And type of error messages
> like this are written by world top programmers.
There are some people that would argue that, but I won't go there:)

> 
> My point was that I see now two camps in the mailing list. I could be a
> regular user of Axiom, so my hope will be always to just say "apt-get
> install axiom" or any other package manager. If I am trying to compile
> it and I am missing something, then this should be clear. Who has not
> spent time trying to figure out some dependency because it was not clear
> what broke at compilation time. (maybe only me, nooby :-) ).
yes

> 
> In a perfect world Axiom would not have any dependency, but if it must
It must unless we are going to reinvent the universe; the point is to make it clear and explicit.


> I understand that it makes it harder for the testing purposes on other
> systems, but I think is not that much of a problem as it sounds in this
> thread. Of course I could be totally wrong, with everybody more
> experienced than me actually doing the work (easy to talk in the bench) .
It's a challenge, but one that must be met for wide usage; at least until "The Operating System"is
finally developed.
> 
> I hope that was the problem you were talking about, and not my English.
> Sorry if I am not clear in my writting (I have only 4 years living in
> US. Funny enough 4 years ago I was not able to ask for coffee in a
> restaurant, much less think that I would be able to write suggestions
> for such a  great project like Axiom).
Absolutely nothing to do with you or your writing; I was just making a plea for know errors to give
guidance about how to fix things.

\start
Date: 02 Sep 2006 12:02:06 -0500
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: re: Requiring LaTeX

Alfredo Portes writes:


[...]

| In a perfect world Axiom would not have any dependency, but if it must have
| it then let the
| user install it in the system. How hard is to have latex on a system
| nowdays. I am with Tim in this, regarding that future projects will require
| latex (browser hyperdoc...). Axiom is  in LP style, Latex/Noweb is the
| current tool in Axiom to achieve this, how can Latex not be a requirement?
| 
| I understand that it makes it harder for the testing purposes on other
| systems, but I think is not that much of a problem as it sounds in this
| thread.

Here is a concrete proposal for you:  get subscribed at SF (if you're
not already) and install latex on all the non-linux systems they have
and do the testings on all of those hosts, send the build log back to me.

\start
Date: Sat, 02 Sep 2006 19:07:00 +0200
From: Gregory Vanuxem
To: list
Subject: Some typos in src/algebra

See attachment...

Greg

--- src/algebra/attreg.spad.pamphlet.old	2006-09-02 19:00:53.000000000 +0200
+++ src/algebra/attreg.spad.pamphlet	2006-09-02 19:01:09.000000000 +0200
@@ -65,7 +65,7 @@
     ++ \spad{additiveValuation} implies
     ++ \spad{euclideanSize(a*b)=euclideanSize(a)+euclideanSize(b)}.
   multiplicativeValuation
-    ++ \spad{multiplicativeValuation} imples
+    ++ \spad{multiplicativeValuation} implies
     ++ \spad{euclideanSize(a*b)=euclideanSize(a)*euclideanSize(b)}.
   NullSquare
     ++ \axiom{NullSquare} means that \axiom{[x,x] = 0} holds.
--- src/algebra/clifford.spad.pamphlet.old	2006-09-02 18:26:06.000000000 +0200
+++ src/algebra/clifford.spad.pamphlet	2006-09-02 18:45:02.000000000 +0200
@@ -499,8 +499,8 @@
 {\bf http://web.maths.unsw.edu.au/~leopardi/clifford-2003-06-05.pdf}
 \bibitem{8} Cartan, Elie and Study, Eduard
 "Nombres Complexes",
-Encyclopaedia Sciences Math\'ematique, \'edition fran\,caise, 15, (1908),
-d'apr\'s l'article allemand de Eduard Study, pp329-468. Reproduced as
+Encyclopaedia Sciences Math\'ematique, \'edition fran\c caise, 15, (1908),
+d'apr\`es l'article allemand de Eduard Study, pp329-468. Reproduced as
 pp107-246 of \cite{17} 
 \bibitem{9} Hestenes, David and Sobczyck, Garret
 "Clifford algebra to geometric calculus: a unified language for 
@@ -528,6 +528,6 @@
 "Clifford algebras with numeric and symbolic computations",
 Birkh\"auser (1996)
 \bibitem{17} Cartan, Elie and Montel, P. (eds), 
-"Oeveres Compl\`etes" Gauthier-Villars, (1953)
+"\OE uvres Compl\`etes" Gauthier-Villars, (1953)
 \end{thebibliography}
 \end{document}

\start
Date: Sat, 2 Sep 2006 13:32:26 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: re: Requiring LaTeX

Gaby,

 I knew this part was going to be taken in another context, and by no means
 I tried to underestimate the work you are doing. Plus, I do recall your
email
 explaining that you did not want waste time testing on systems, when you
 could focus on your research or teaching.

Here is a concrete proposal for you:  get subscribed at SF (if you're
> not already) and install latex on all the non-linux systems they have
> and do the testings on all of those hosts, send the build log back to me.


  I guess your point with this assignment is to show me how difficult it is.
By no
  means I wanted to say this was trivial. But if that helps with the great
work you are
  doing, I would be more than glad. But I am curious, couldn't be latex be
avoided for
  testing purposes, and then have it as a requirement later on??? (do latex
to build the
  documentation).

   But again what do I know. But if you read the thread again it looked like
developers
   clashing over ideas, which is normal until it gets to point similar to
Matthew Garrett
   resignation from Debian.

   I apologize if my comment was wrongly interpreted.

\start
Date: Sat, 02 Sep 2006 13:43:06 -0500
From: Jay Belanger
To: list
Subject: re: Requiring LaTeX

Gabriel Dos Reis writes:
...
> Someone, peopel seems to interpret allowing Axiom to be built if latex
> is not present as making Axiom non-literate.  

(Some "if"s, I know.)
If being built refers to being built by people who might make changes
(others will eventually use pre-built binaries, I would guess) and if
part of literate programming is being able to produce nice typeset
documentation, wouldn't building without typesetting encourage
literate bit-rot?

> I highly suspect that is a religiously mis-representation of what
> literate programming is.

What is it, then?

\start
Date: Sat, 2 Sep 2006 14:39:28 -0500 (CDT)
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: re: Requiring LaTeX

On Sat, 2 Sep 2006, Alfredo Portes wrote:

| Gaby,
|
|  I knew this part was going to be taken in another context, and by no means
|  I tried to underestimate the work you are doing. Plus, I do recall your
| email
|  explaining that you did not want waste time testing on systems, when you
|  could focus on your research or teaching.

I think you misread what I said. I do not want to waste my time
"fixing" build environments -- I for sure know how to find my way
through, I just don't believe it is a good use of my time.  Fixing
Axiom is already a full-time job.  I *do want to do the testing* -- or
accept help from others to do the testing.  Testing is important.

[...]

|   I guess your point with this assignment is to show me how difficult it is.

Not really.  I just do not buy the stance "it is not difficult to
install X Y tool on systems, _therefore_ people should do it and by the
way we are not going to make it easy for people to contribute the
little they can."

| By no
|   means I wanted to say this was trivial. But if that helps with the great
| work you are
|   doing, I would be more than glad. But I am curious, couldn't be latex be
| avoided for
|   testing purposes, and then have it as a requirement later on??? (do latex
| to build the
|   documentation).

That is essentially what I have been saying since the begining.  We
are not in the business of testing latex on all pltaforms.  We are
primarily interested in testing Axiom.  Consequently, I believe we
should make it possible to allow people to test Axiom on system
lacking latex.  I don't see how that harms Axiom.

\start
Date: 02 Sep 2006 14:44:55 -0500
From: Gabriel Dos Reis
To: Jay Belanger
Subject: re: Requiring LaTeX

Jay Belanger writes:

| Gabriel Dos Reis writes:
| ...
| > Someone, peopel seems to interpret allowing Axiom to be built if latex
| > is not present as making Axiom non-literate.  
| 
| (Some "if"s, I know.)
| If being built refers to being built by people who might make changes
| (others will eventually use pre-built binaries, I would guess) and if
| part of literate programming is being able to produce nice typeset
| documentation, wouldn't building without typesetting encourage
| literate bit-rot?

Jay,

  Why don't you register at SF and fix the build environment so that
you can report on testings if you believe that Axiom should not be
allowed in build environement without latex?  That way we can
meaningfully reject any help amounting to test Axiom in an environment
without latex.

\start
Date: 02 Sep 2006 14:52:51 -0500
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: Some typos in src/algebra

Gregory Vanuxem writes:

| See attachment...

applied to build-improvements.

\start
Date: Sat, 2 Sep 2006 15:51:12 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: Requiring LaTeX

This is an sourceforge project admin detail. I'll handle it.
I've sent a request to the sourceforge response team.

\start
Date: Sat, 2 Sep 2006 15:03:59 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Requiring LaTeX

On Sat, 2 Sep 2006, root wrote:

| Gaby,
|
| This is an sourceforge project admin detail. I'll handle it.
| I've sent a request to the sourceforge response team.

Great!
latex and svn are missing.

\start
Date: Sat, 02 Sep 2006 15:04:31 -0500
From: Jay Belanger
To: list
Subject: re: Requiring LaTeX

Gabriel Dos Reis writes:

> Jay Belanger writes:
>
> | Gabriel Dos Reis writes:
> | ...
> | > Someone, peopel seems to interpret allowing Axiom to be built if latex
> | > is not present as making Axiom non-literate.
> |
> | (Some "if"s, I know.)
> | If being built refers to being built by people who might make changes
> | (others will eventually use pre-built binaries, I would guess) and if
> | part of literate programming is being able to produce nice typeset
> | documentation, wouldn't building without typesetting encourage
> | literate bit-rot?
>
> Jay,
>
>   Why don't you register at SF

I am registered at SF; I'm belanger there.

> and fix the build environment so that you can report on testings

I don't know what that would involve, but I'd be happy to look into
it. 

> if you believe that Axiom should not be allowed in build
> environement without latex?

I don't have any beliefs in the matter.  I was asking what I thought
was an important question which I didn't see addressed in this thread.

\start
Date: Sat, 2 Sep 2006 16:08:54 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: re: Requiring LaTeX

  Why don't you register at SF and fix the build environment so that
> you can report on testings if you believe that Axiom should not be
> allowed in build environement without latex?  That way we can
> meaningfully reject any help amounting to test Axiom in an environment
> without latex.


  I think what Jay is trying to say is that regular users will use binaries
or
  PM to install axiom. However the case you are referring is to people who
  would like to contribute, but shouldnt any code to be contributed to
  Axiom be in LP form also? I know this is not the standard, but I think
  that would be the final goal? How can this be accomplished without Latex?

   However, I think a compromise could be to have something like
--without-latex
   (extreme case), but knowing that documentation, and other possible future
features
   will not be available. I am sure you have already said this on this
thread.

\start
Date: Sat, 02 Sep 2006 22:29:09 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: Requiring LaTeX

> We are primarily interested in testing Axiom.  Consequently, I
> believe we should make it possible to allow people to test Axiom on
> system lacking latex.  I don't see how that harms Axiom.

Gaby, in order to stop the whole debate... You've heard Tim. He is not 
preventing people to do anything good or bad. What I understood this 
morning was that when Tim speaks of Axiom he refers to the gold release.
If you (and I) think that it is good for Axiom to modify the Makefiles 
that (a part of) Axiom builds even if latex is not present, then we are 
allowed to do that. Tim might not want it moved into gold, but even if 
these modified Makefiles stay in silver, it would speed up the build 
process and allow other people testing at least a part of Axiom.

I think the simplest way would be to ask configure to generate a 
variable LATEX that expands to 'latex' if LaTeX is installed on the 
system and no "--without-latex" switch is given or it expands to 'echo'.

Then in each place where latex is used it should read ${LATEX}.
These are the only files that refer to latex as a command.

src/interp/bookvol5.pamphlet
src/doc/Makefile.pamphlet
src/doc/bookvol1.pamphlet
src/script/document

\start
Date: Sat, 02 Sep 2006 22:35:33 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Debian build failure

Do these lines help you?

 >echo Hello | awk '{print "\${MID}"}'
awk: warning: escape sequence `\$' treated as plain `$'
${MID}

 >echo Hello | awk '{print "${MID}"}'
${MID}

Unfortunately I have no idea whether $ should be escaped or not. I was 
unable to find an appropriate line in the gawk info pages.

\start
Date: Sat, 2 Sep 2006 15:41:56 -0500 (CDT)
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: re: Requiring LaTeX

On Sat, 2 Sep 2006, Alfredo Portes wrote:

|   Gaby,
|
|   Why don't you register at SF and fix the build environment so that
| > you can report on testings if you believe that Axiom should not be
| > allowed in build environement without latex?  That way we can
| > meaningfully reject any help amounting to test Axiom in an environment
| > without latex.
|
|
|   I think what Jay is trying to say is that regular users will use binaries
| or
|   PM to install axiom.

I suspect people are simplifying too much here.  I don't believe the
world divides so nicely into mutually exclusive  "regular users" and
"contributors"; and regular users will have binaries or PM to install
axiom.  I know of reasonable people who hate PM (with the automatic
dependency hell that comes with it).  So positing the above would make
a lot of sense only if we restrict our world sufficiently enough.

|    However the case you are referring is to people who
|   would like to contribute, but shouldnt any code to be contributed to

testing, testing, testing, I said.
Not contributing unbuilt or untested patches.

|   Axiom be in LP form also? I know this is not the standard, but I think
|   that would be the final goal? How can this be accomplished without Latex?

Building Axiom can be done without latex.

Latex is required only to "type check" the pamphlet files.  If you see
someone contruting something without having latexed it, please arrest him.
And if you look carefully you would arrest many of the key contributors.

Again, I'M NOT PROPOSING TO ACCEPT CHANGES TO PAMPHLET FILES THAT
HAVE NOT BEEN PROPERLY LATEXED.

Now, do you believe that we have enough resources and testers on
all platforms we want to support, so that we should refuse building
Axiom without latex?  That is NOT a rhetorical question.

\start
Date: Sat, 2 Sep 2006 15:45:31 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: Requiring LaTeX

On Sat, 2 Sep 2006, Ralf Hemmecke wrote:

| > We are primarily interested in testing Axiom.  Consequently, I
| > believe we should make it possible to allow people to test Axiom on
| > system lacking latex.  I don't see how that harms Axiom.
|
| Gaby, in order to stop the whole debate... You've heard Tim. He is not
| preventing people to do anything good or bad. What I understood this
| morning was that when Tim speaks of Axiom he refers to the gold release.
| If you (and I) think that it is good for Axiom to modify the Makefiles
| that (a part of) Axiom builds even if latex is not present, then we are
| allowed to do that. Tim might not want it moved into gold, but even if
| these modified Makefiles stay in silver, it would speed up the build
| process and allow other people testing at least a part of Axiom.
|
| I think the simplest way would be to ask configure to generate a
| variable LATEX that expands to 'latex' if LaTeX is installed on the
| system and no "--without-latex" switch is given or it expands to 'echo'.

that is indeed one way to do it.

| Then in each place where latex is used it should read ${LATEX}.
| These are the only files that refer to latex as a command.
|
| src/interp/bookvol5.pamphlet
| src/doc/Makefile.pamphlet
| src/doc/bookvol1.pamphlet
| src/script/document

document does many things, including latexing input files.  And it is
used at many places.

I would like to divide the make rules so that we have "make dvi" that
does the latexing, separated from the rest.  Of course, for releases
"make all" will compile codes and "make dvi".

\start
Date: 02 Sep 2006 15:49:01 -0500
From: Gabriel Dos Reis
To: Jay Belanger
Subject: re: Requiring LaTeX

Jay Belanger writes:

[...]

| >   Why don't you register at SF
| 
| I am registered at SF; I'm belanger there.

Great!

| > and fix the build environment so that you can report on testings
| 
| I don't know what that would involve, but I'd be happy to look into
| it. 


Basically, here is what I would like to see:
  On all non-linux platforms (and fedora platforms), check out a copy
  of the build-improvements.  configure and make it and send me (gdr
  at acm.org) the build log.  I'm particularly interested in issues
  related to X11.

\start
Date: 02 Sep 2006 16:20:00 -0500
From: Gabriel Dos Reis
To: Jay Belanger
Subject: re: Requiring LaTeX

Jay Belanger writes:

| Gabriel Dos Reis writes:
| ...
| > Basically, here is what I would like to see:
| >   On all non-linux platforms (and fedora platforms), check out a copy
| >   of the build-improvements.  configure and make it and send me (gdr
| >   at acm.org) the build log.  I'm particularly interested in issues
| >   related to X11.
| 
| Okay.  I'll read up on the compile farm tonight and get the logs to
| you when I get the chance.

\start
Date: Sun, 03 Sep 2006 05:05:47 +0200
From: Gregory Vanuxem
To: list
Subject: Gold source tarball

In the page http://wiki.axiom-developer.org/AxiomSources, it is
written : "the stable release is avaiblable either via a direct source
tarball or via access to CVS or TLA archives. You find more details at
AxiomGoldBranch" but where is/are the source tarball(s)? It could be a
good idea to allow user to download a source tarball either from
SourceForge or savannah, they offer this type of service (from
wiki.axiom-developer is a good idea too).

\start
Date: Sun, 3 Sep 2006 10:05:22 -0400
From: Tim Daly
To: list
Subject: silver checkout

Every attempt I make to check out the silver branch fails with
svn: Can't open file '...random file name...'

There appears to be no way to recover and continue.
Each failure complains that axiom/trunk/axiom is locked.
svn cleanup axiom fails

Is anyone able to check out the silver branch?

\start
Date: 03 Sep 2006 10:50:03 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: silver checkout

Tim Daly writes:

| Every attempt I make to check out the silver branch fails with
| svn: Can't open file '...random file name...'
| 
| There appears to be no way to recover and continue.
| Each failure complains that axiom/trunk/axiom is locked.
| svn cleanup axiom fails
| 
| Is anyone able to check out the silver branch?

Upon receiving your mail, I tested

  % svn co https://svn.sourceforge.net/svnroot/axiom/trunk/axiom axiom.silver

It just finished with

   [...]
   A    axiom.silver/lsp/ChangeLog
   Checked out revision 113.


Do you have connection troubles?

\start
Date: 03 Sep 2006 12:03:22 -0500
From: Gabriel Dos Reis
To: list
Subject: awk and espace

I believe there was a discussion yesterday about awk and escapes
involving $, \ and debian.  While working on the makefiles for
something unrelated, I happen to notice that on a non-debian system I
have the following warnings 

  awk: cmd. line:3: warning: escape sequence `\$' treated as plain `$'

and so on.  So, if you fix this; make sure you don't fix it "just" for
debian. 

\start
Date: Sun, 3 Sep 2006 13:10:09 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: cross-compiling Axiom

On September 1, 2006 7:40 PM Gabriel Dos Reis
> 
> On Fri, 1 Sep 2006, Tim Daly wrote:
> 
> | Please explain what you mean by cross-compilation.
> 
> Benjamin Kosnik tried to explain that in April on this list.
> Imagine I'm running on x86-based machine, and I must build
> binaries for a PowerPC-based systems.
> 
> http://en.wikipedia.org/wiki/Cross-compiling
> ... 

I think anyone who suggests that Axiom should/could be built
this way does not understand how lisp works. What sense does
it make to try to do a lisp save-system to some other hardware
platform?

Or do I misunderstand what you mean?

\start
Date: Sun, 3 Sep 2006 12:41:20 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: cross-compiling Axiom

On Sun, 3 Sep 2006, Bill Page wrote:

| On September 1, 2006 7:40 PM Gabriel Dos Reis
| >
| > On Fri, 1 Sep 2006, Tim Daly wrote:
| >
| > | Please explain what you mean by cross-compilation.
| >
| > Benjamin Kosnik tried to explain that in April on this list.
| > Imagine I'm running on x86-based machine, and I must build
| > binaries for a PowerPC-based systems.
| >
| > http://en.wikipedia.org/wiki/Cross-compiling
| > ...
|
| I think anyone who suggests that Axiom should/could be built
| this way does not understand how lisp works.

For data points, Emacs is lisp-based and can be cross-compiled.  Maybe
Stallman and friends don't understand how lisp works, however they made
Emacs cross-compilable.  But, since that is from the real world, it
probably does not count.

| What sense does
| it make to try to do a lisp save-system to some other hardware
| platform?

Properly distinguish build, host and target specific tools and files.
Make sure that, for example, when GCL tries to compile a function,
it invokes the adequate C compiler; that GCL is itself compiled with
the adequate C compiler etc.

| Or do I misunderstand what you mean?

I don't know; however, you're most certainly welcome to explain why you
believe people suggesting cross-compilation of Axiom don't know how
lisp works.

\start
Date: Sun, 3 Sep 2006 13:53:28 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: cross-compiling Axiom

On September 3, 2006 1:41 PM Gabriel Dos Reis wrote:
> ...
> Bill Page wroteL 
> | What sense does it make to try to do a lisp save-system to some
> | other hardware platform?
> 
> Properly distinguish build, host and target specific tools and files.
> Make sure that, for example, when GCL tries to compile a function,
> it invokes the adequate C compiler; that GCL is itself compiled with
> the adequate C compiler etc.
> 

But... when GCL compiles a function it becomes *part* of GCL.
How can we separate that?

\start
Date: Sun, 3 Sep 2006 12:56:54 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: cross-compiling Axiom

On Sun, 3 Sep 2006, Bill Page wrote:

| On September 3, 2006 1:41 PM Gabriel Dos Reis wrote:
| > ...
| > Bill Page wroteL
| > | What sense does it make to try to do a lisp save-system to some
| > | other hardware platform?
| >
| > Properly distinguish build, host and target specific tools and files.
| > Make sure that, for example, when GCL tries to compile a function,
| > it invokes the adequate C compiler; that GCL is itself compiled with
| > the adequate C compiler etc.
| >
|
| But... when GCL compiles a function it becomes *part* of GCL.
| How can we separate that?

Please, explain carefully why you believe that people suggesting
cross-compilation of Axiom don't know what how lisp works.  Once
you've given your justifications, we should be able to work out where
the confusions are.

\start
Date: Sun, 3 Sep 2006 14:08:42 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: cross-compiling Axiom

I don't know who doesn't know what doesn't work. I just
asked how can this be done with gcl?

> -----Original Message-----
> 
> 
> On Sun, 3 Sep 2006, Bill Page wrote:
> 
> | On September 3, 2006 1:41 PM Gabriel Dos Reis wrote:
> | > ...
> | > Bill Page wroteL
> | > | What sense does it make to try to do a lisp save-system to some
> | > | other hardware platform?
> | >
> | > Properly distinguish build, host and target specific 
> tools and files.
> | > Make sure that, for example, when GCL tries to compile a function,
> | > it invokes the adequate C compiler; that GCL is itself 
> compiled with
> | > the adequate C compiler etc.
> | >
> |
> | But... when GCL compiles a function it becomes *part* of GCL.
> | How can we separate that?
> 
> Please, explain carefully why you believe that people suggesting
> cross-compilation of Axiom don't know what how lisp works.  Once
> you've given your justifications, we should be able to work out where
> the confusions are.

\start
Date: 03 Sep 2006 13:44:04 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: cross-compiling Axiom

Bill Page writes:

| I don't know who doesn't know what doesn't work. 

The issue is not who doesn't know, but why you believe that anyone
suggesting cross-compilation of Axiom does not know how lisp works, as
you suggested in earlier message.  That would help clarify confusions.

| I just asked how can this be done with gcl?

There are numerous poins to work out; and I've listed the most obvious
that immediately came to my mind.

The idea is to be able to use platform A to build Axiom, or minimal part
of it, so that the built Axiom can run on platform B.

Most distributors work that way, because they usually have faster
build machines.  Again, refer to Benjamin Kosnik's message from April
2006. 

\start
Date: Sun, 3 Sep 2006 17:18:24 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: cross-compiling Axiom

> -----Original Message-----
> 
> Bill Page writes:
> 
> | I don't know who doesn't know what doesn't work. 
> 
> The issue is not who doesn't know, but why you believe that anyone
> suggesting cross-compilation of Axiom does not know how lisp works,
> as you suggested in earlier message.  That would help clarify
> confusions.

Sorry, I did not intend to offend anyone. All I meant was I do not
believe that cross-pile is possible using a lisp like GCL. And it
is unclear to me how this can be done with any lisp - but you say
emacs lisp is cross-compiled and I believe you. But I don't see
how that can help the cross-compile issue with Axiom.

In fact, so far your replies have been distinctly unhelpful... :(

> 
> | I just asked how can this be done with gcl?
> 
> There are numerous poins to work out; and I've listed the most
> obvious that immediately came to my mind.
> ...
> Properly distinguish build, host and target specific tools and
> files. Make sure that, for example, when GCL tries to compile a
> function, it invokes the adequate C compiler; that GCL is itself
> compiled with the adequate C compiler etc.
>

I don't see how any of these points apply to gcl. gcl is based
on gcc. That is a "adequate C compiler" isn't it?

> 
> The idea is to be able to use platform A to build Axiom, or 
> minimal part of it, so that the built Axiom can run on platform
> B.

I have no idea how that would be possible except perhaps through
some virtual machine technology - but then that is not really
cross-compilation is it?

> 
> Most distributors work that way, because they usually have
> faster build machines.  Again, refer to Benjamin Kosnik's message
> from April 2006. 
> 

I can not find any reference by Benjamin Kosnik to lisp in the
axiom-developer archive. I did find however David Mentre's
explanation of why cross-compilation might be difficult/impossible
for Axiom.

http://lists.nongnu.org/archive/html/axiom-developer/2006-04/msg00318.html

\start
Date: Sun, 3 Sep 2006 16:43:28 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: re: cross-compiling Axiom

On Sun, 3 Sep 2006, Bill Page wrote:

|
|
| > -----Original Message-----
| > From: Gabriel Dos Reis
| > [mailto:Gabriel Dos Reis] On Behalf Of Gabriel Dos Reis
| > Sent: September 3, 2006 2:44 PM
| > To: Bill Page
| > Cc: list
| > Subject: re: cross-compiling Axiom
| >
| >
| > Bill Page writes:
| >
| > | I don't know who doesn't know what doesn't work.
| >
| > The issue is not who doesn't know, but why you believe that anyone
| > suggesting cross-compilation of Axiom does not know how lisp works,
| > as you suggested in earlier message.  That would help clarify
| > confusions.
|
| Sorry, I did not intend to offend anyone. All I meant was I do not
| believe that cross-pile is possible using a lisp like GCL.

That is a very *distinctly different* statement.

| And it
| is unclear to me how this can be done with any lisp - but you say
| emacs lisp is cross-compiled and I believe you.

You don't have to believe me.  The source code is out there and you
can walk yourself through it and see how it is done.

| But I don't see how that can help the cross-compile issue with Axiom.

Emacs was offered a data point of a lisp-base system that can be
cross-compiled, in response to your original statement.

| In fact, so far your replies have been distinctly unhelpful... :(
|
| >
| > | I just asked how can this be done with gcl?
| >
| > There are numerous poins to work out; and I've listed the most
| > obvious that immediately came to my mind.
| > ...
| > Properly distinguish build, host and target specific tools and
| > files. Make sure that, for example, when GCL tries to compile a
| > function, it invokes the adequate C compiler; that GCL is itself
| > compiled with the adequate C compiler etc.
| >
|
| I don't see how any of these points apply to gcl. gcl is based
| on gcc. That is a "adequate C compiler" isn't it?

First you have to make sure that core GCL is compiled with a C
compiler targetting the host.  Next, you have to make sure that GCL
uses the host C compiler for its internal purposes.  Furthermore, you
have to make sure that the rest of GCL (that really needs to run on
the host) is compiled in a host-like enrivonment.  Notice here that
you have a "seed" that is cross-compiled so that further compilation
can be done.   This is basically the way Emacs is compiled.

[...]

| > Most distributors work that way, because they usually have
| > faster build machines.  Again, refer to Benjamin Kosnik's message
| > from April 2006.
| >
|
| I can not find any reference by Benjamin Kosnik to lisp in the
| axiom-developer archive.

Again, read carefuuly what I wrote.  What I wrote is an explanation of
the way most distributors work.  Not to a mention to a specific lisp.

Now, if you hold it is impossible to cross-compile Axiom; then, that
is fine.  Let's move to another topic, and come back when I've
finished my work on cross-compilation.  Let's not just tell people
that they don't understand how lisp work.

\start
Date: Sun, 3 Sep 2006 16:37:46 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis, Bill Page
Subject: re: cross-compiling Axiom

Gaby, just for my own information:

Is this issue similar to (say) compiling CMUCL or SBCL for a new
platform, working from a current one?

I always understood cross-compiliation to be the production of a binary
for a platform that does not currently have any existing binary, using
a running binary on a second system.  This means, in general, that the
software on the second system must understand how to write a valid
binary for the first, and also that the software itself not depend
explicitly on behavior not exhibited by the second system.  

More specificly, does distribution cross-compilation imply that for
some machine types/targets, the target machine type is never actually
used to build any software - instead, an existing machine of a
different type is used to create the binaries for the targeted arch? 
And unless a distribution can compile binaries for machines completely
different from the one the software is actually being built on, then
they can't distribute a particular package (the logic being it is too
much work to have N machines for N archs, some of which might be
substantually less powerful than the build machines?)

I would have thought if GCL was able to do this then Axiom probably
would be able to too, give or take the non-lisp parts of the system -
am I missing something?  Or is GCL in fact not able to be distributed
for similar reasons?  I would be interested to know how Maxima fairs in
this situation.

Cheers, and thanks again for all your hard work.

\start
Date: Sun, 3 Sep 2006 20:01:45 -0400
From: Tim Daly
To: Cliff Yapp
Subject: re: cross-compiling Axiom
Cc: Gabriel Dos Reis

Axiom was ported to the Zaurus handheld using cross-compilation.
Camm does it in the Debian setup.

There are two methods generally used, CROSS-COMPILATION and
CROSS-MOUNTING. 

CROSS-COMPILATION involves two systems, B -- the build system and
T -- the target system. You compile on B but tell GCC that the
target is T. 

GCC is designed in layers. The source code eventually gets compiled to
RTL (Register Transfer Language) which is a target independent
lisp-like assembler language. Since this is system-independent you
can use the RTL anywhere.

The final stage of GCC compiles RTL to the target platform. GCC
currently targets about 20 platforms.  This is useful for targets like
the Zaurus (an ARM (i386-ish) processor) that do not have the
horsepower to be a compile platform. It is also useful for embedded
systems.




CROSS-MOUNTING is easier if the target system has the tools and horsepower
to host GCC. For instance, to build on a Sun system it is easier to use
NFS (Network File System). Here we talk about S -- the source system
and T -- the target system.

On S, which contains the source tree, you 'export' the filesystem using
NFS. This allows anyone to mount the filesystem remotely. On T you 
NFS-mount the sources. They now appear to be on the target system
and you can just type 'make'

Axiom can use this system. First you build on S so that you have a 
full build tree (SRC, INT, OBJ, MNT). Notice that these are defined as

  SRC -- Human created, read-only
  INT -- Machine-generated, Machine-independent
  OBJ -- Machine-generated, Machine-dependent
  MNT -- Final distribution tree


SRC contains the source tree. NFS export on B it so it can be mounted on T.
INT contains a 'cache' of extracted code that is system-independent so it
also can be NFS exported on B and NFS-mounted on T. This saves having to
redo a lot of work.

On B you export SRC & INT.
On T you NFS-mount SRC & INT.
On T you set the AXIOM variable to the local machine 
  (e.g. export AXIOM=`pwd`/mnt/sun)
On T you type 'make' and it builds a Sun version.

In parallel, other systems can also do NFS-mount and make.
The only change is the AXIOM variable (e.g. `pwd`/mnt/macox)





The advantage of CROSS-COMPILATION is that you can build for systems
that don't support a build environment. The disadvantage is that you
need a cross-compiled environment (e.g. libraries need to be cross
compiled, .h files need to reflect the target, etc.). Since Axiom
needs the X11 libraries for a full build you need to have X11
libraries that are cross-compiled for the target (e.g. Zaurus)


The advantage of CROSS-MOUNTING is that you are building on the 
final target and can use all of the libraries, includes, and tools.
The disadvantage is that you can't do this if the target does not
have the horsepower.


Which method you use is determined by the resources of the target.

\start
Date: Sun, 3 Sep 2006 21:46:12 -0400
From: Bill Page
To: Tim Daly, Cliff Yapp
Subject: re: cross-compiling Axiom
Cc: Camm Maguire, Gabriel Dos Reis

On September 3, 2006 8:02 PM Tim Daly wrote:
>
> Axiom was ported to the Zaurus handheld using cross-compilation.
> Camm does it in the Debian setup.

No, I don't think that is true. At least I know it isn't true
for the version of Axiom that I run on my Zaurus. Axiom is built
on Debian like all other packages that I know of on Debian - on
a machine that is hardware-compatible with the target.

http://db.debian.org/machines.cgi

I think the binary that I use on my Zaurus was compiled on Debian
running on such an Arm host. (Camm can confirm.)

http://www.debian.org/ports/arm

These machines have the same type of processor as the Zaurus
(although of course these are probably not handheld devices :)
having faster processors, more memory and faster mass storage.

In order to run Axiom, I must also configure my Zaurus to run
a similar Debian distribution. On my Zaurus the arm Debian
distribution runs in a chroot.

>
> There are two methods generally used, CROSS-COMPILATION and
> CROSS-MOUNTING.
>

I have never heard of "cross-mounting" used in this context.

>
> CROSS-COMPILATION involves two systems, B -- the build system
> and T -- the target system. You compile on B but tell GCC that
> the target is T.
>
> GCC is designed in layers. The source code eventually gets
> compiled to RTL (Register Transfer Language) which is a target
> independent lisp-like assembler language. Since this is system-
> independent you can use the RTL anywhere.
>
> The final stage of GCC compiles RTL to the target platform. GCC
> currently targets about 20 platforms.  This is useful for targets
> like the Zaurus (an ARM (i386-ish) processor) that do not have
> the horsepower to be a compile platform. It is also useful for
> embedded systems.
>

In fact I have built Axiom from source on my Zaurus, but I do not
recommend it. Since there is not enough main memory you must
configure a swap disk and swapping to SD ram is *slow*. It took
about two days to complete.

Perhaps it is possible to cross-compile programs written in C to
arm using gcc. For example, here is an ambitious project of that
type:

http://scratchbox.org/wiki/Crocodile

But I am quite sure that this is *not* how Camm compiles Axiom for
Arm and the other Debian architectures.

>
> CROSS-MOUNTING is easier if the target system has the tools and
> horsepower to host GCC. For instance, to build on a Sun system
> it is easier to use NFS (Network File System). Here we talk about
> S -- the source system and T -- the target system.
>
> On S, which contains the source tree, you 'export' the filesystem
> using NFS. This allows anyone to mount the filesystem remotely. On
> T you NFS-mount the sources. They now appear to be on the target
> system and you can just type 'make'

Tim, that sounds like nonsense. Anyone can mount source directories
located on another machine running another operating system. You can
use NFS, or Samba or whatever. This has nothing to do with cross-
compilation.

>
> Axiom can use this system. First you build on S so that you have a
> full build tree (SRC, INT, OBJ, MNT). Notice that these are defined
> as
>
>   SRC -- Human created, read-only
>   INT -- Machine-generated, Machine-independent
>   OBJ -- Machine-generated, Machine-dependent
>   MNT -- Final distribution tree
>
>
> SRC contains the source tree. NFS export on B it so it can be
> mounted on T. INT contains a 'cache' of extracted code that is
> system-independent so it also can be NFS exported on B and
> NFS-mounted on T. This saves having to redo a lot of work.
>
> On B you export SRC & INT.
> On T you NFS-mount SRC & INT.
> On T you set the AXIOM variable to the local machine
>   (e.g. export AXIOM=`pwd`/mnt/sun)
> On T you type 'make' and it builds a Sun version.
>
> In parallel, other systems can also do NFS-mount and make.
> The only change is the AXIOM variable (e.g. `pwd`/mnt/macox)
>

Maybe this strategy was interesting once-upon-a-time but with
the machines that we have available today I doubt that there is
much advantage to this. It seems to me that all you might save
is the BOOT-to-Lisp and SPAD-to-Lisp compile times. The only code
in Axiom that is (approximately) machine independent is the lisp
source code and the generated lisp code. To get anywhere else
with that you still need a lisp interpreter/compiler on the target
environment. And it seems to me that that is the hard part.

>
> The advantage of CROSS-COMPILATION is that you can build for
> systems that don't support a build environment. The disadvantage
> is that you need a cross-compiled environment (e.g. libraries
> need to be cross compiled, .h files need to reflect the target,
> etc.). Since Axiom needs the X11 libraries for a full build you
> need to have X11 libraries that are cross-compiled for the target
> (e.g. Zaurus)

The version of Zaurus that I have (which still runs the Sharp
supplied embedded Linux) does not support X11 natively. That is
one reason why you need the Debian arm port. There may be a
version of OpenZaurus Linux that does have X11.

But I still do not understand how you can talk about cross-
compilation and GCL. When GCL compiles some lisp source code
it produces intermediate C code which, yes could in principle
be compiled for another architecture, but then it immediately
attempts to link the generated object code into the running
GCL image. If you are attempting cross-compilation this is
not possible because the running GCL image is not compatible
with the object code produced by gcc.

What am I missing?

>
> The advantage of CROSS-MOUNTING is that you are building on
> the final target and can use all of the libraries, includes,
> and tools. The disadvantage is that you can't do this if the
> target does not have the horsepower.

As far as I can see, this is irrelevant to the issue of cross-
compilation.

>
> Which method you use is determined by the resources of the
> target.
>

If you build the binaries on the target this is not cross-
compilation.

With regards to cross-compilation and Maxima see for example:

http://www.math.utexas.edu/pipermail/maxima/2003/003434.html

Camm writes:

> I believe you will run into some problems when cross-compiling.
> You can compile all the objects just fine by pointing gcl at
> your gcc cross compiler.  But part of gcl's build, and maxima's,
> entails loading and executing these objects (i.e. initializing
> the lisp core), so you would at least need a mips emulator, which
> I doubt exists. Your best bet I'd think would be to setup your
> pda to mount a larger filesystem via nfs from another box, with
> a true mips development environment installed.  Compile there,
> and your pda should be able to run the produced executable.

http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2005-04/msg01510.=
htm
l
http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2005-04/msg01463.html

\start
Date: Sun, 3 Sep 2006 21:06:49 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: re: cross-compiling Axiom
Cc: Camm Maguire

On Sun, 3 Sep 2006, Bill Page wrote:

| What am I missing?

the cross-compiled GCL will on the target (which is also the host).

[...]

| > so you would at least need a mips emulator, which  I doubt exists.

  http://www.linux-mips.org/wiki/Emulators

\start
Date: Sun, 3 Sep 2006 21:22:26 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: re: cross-compiling Axiom
Cc: Camm Maguire

On Sun, 3 Sep 2006, Bill Page wrote:

| But I still do not understand how you can talk about cross-
| compilation and GCL. When GCL compiles some lisp source code
| it produces intermediate C code which, yes could in principle
| be compiled for another architecture, but then it immediately
| attempts to link the generated object code into the running
| GCL image. If you are attempting cross-compilation this is
| not possible because the running GCL image is not compatible
| with the object code produced by gcc.
|
| What am I missing?

I believe you're confusing "cross-compiling GCL" and "building a
GCL cross-compiler".  In my Axiom work, I'm interested in the former.

\start
Date: Sun, 3 Sep 2006 22:18:47 -0400
From: Tim Daly
To: Bill Page
Subject: re: cross-compiling Axiom
Cc: Camm Maguire, Gabriel Dos Reis

I was giving a tutorial on the difference between two different
obscure techniques that could be used to get Axiom running on a new
system. I'm not advocating either technique.




> > Axiom was ported to the Zaurus handheld using cross-compilation.
> > Camm does it in the Debian setup.
> 
> No, I don't think that is true.

You're right. I'm wrong.





> There are two methods generally used, CROSS-COMPILATION and
> CROSS-MOUNTING. 
>
> I have never heard of "cross-mounting" used in this context.

Cross-mounting was the primary way to build axiom. A Zaurus
handheld contains more processor speed and memory than the 
systems we used to use. Storing the SRC and INT directories
on the target machine would cause them to run out of disk space.




> > CROSS-MOUNTING is easier if the target system has the tools and
> 
> Tim, that sounds like nonsense. Anyone can mount source directories
> located on another machine running another operating system. You can
> use NFS, or Samba or whatever. This has nothing to do with cross-
> compilation.

ummm, that's why I put it in a separate paragraph named CROSS-MOUNTING.
yes, it has nothing to do with CROSS-COMPILATION.




> Maybe this strategy was interesting once-upon-a-time but with
> the machines that we have available today I doubt that there is
> much advantage to this. 

Quite true. Which is why I now copy the sources to the target machine.

I'm pointing out that historically Axiom built on many target
systems which had the speed of your toaster and the disk space of
your credit card using this technique. It explains why Axiom is
structured the way it is. A full, from-scratch Axiom build used
to take 3 weeks. Two days on a Zaurus would have been a miracle.



 
> But I still do not understand how you can talk about cross-
> compilation and GCL. When GCL compiles some lisp source code
> it produces intermediate C code which, yes could in principle
> be compiled for another architecture, but then it immediately
> attempts to link the generated object code into the running
> GCL image. If you are attempting cross-compilation this is
> not possible because the running GCL image is not compatible
> with the object code produced by gcc.
> 
> What am I missing?

Not much that I can see. Yes, you could build a cross-compiled
image of Axiom and you could set the system so it does not try
to compile things but you couldn't use it for algebra development
without a lot of hand-manipulation (e.g. running the debugsys
image in which everything is interpreted, hand-loading the
interpreted form of the compiled algebra, etc).

I'm at a loss about why the cross-compilation issue was raised.




> > The advantage of CROSS-MOUNTING is that you are building on
> > the final target and can use all of the libraries, includes,
> > and tools. The disadvantage is that you can't do this if the
> > target does not have the horsepower.
> 
> As far as I can see, this is irrelevant to the issue of cross-
> compilation.

Historically it wasn't. On systems with 10 gig hard drives
and 4 Meg of memory (a VERY big system then) you didn't need
to do this. But on systems with 10 meg hard drives and 640k
of memory it was a challenge.

The compilers did not include a cross-compile target so it
was not possible to build on anything but the target systems.

Now it's completely worthless, as you point out.





> > 
> > Which method you use is determined by the resources of the
> > target.
> > 
> 
> If you build the binaries on the target this is not cross-
> compilation.

ummm, again, I don't believe I said it was....
I was just giving a tutorial about the two techniques.
I don't recommend either one.

\start
Date: Sun, 3 Sep 2006 21:40:40 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: cross-compiling Axiom
Cc: Camm Maguire

On Sun, 3 Sep 2006, root wrote:


| Not much that I can see. Yes, you could build a cross-compiled
| image of Axiom and you could set the system so it does not try
| to compile things but you couldn't use it for algebra development
| without a lot of hand-manipulation (e.g. running the debugsys
| image in which everything is interpreted, hand-loading the
| interpreted form of the compiled algebra, etc).
|
| I'm at a loss about why the cross-compilation issue was raised.

Distributors have environments set up so that they can cross-compile
programs to targets.  You can wonder why they do this, but that is the
way they do it.

Cross-compiling Axiom here, does not mean that the Axiom compilers or
interpreter is itself a cross-compiler (to get there, you would have
compiled Axiom as a Canadian cross which is pointless in this specific
case).  The cross-compiled tools or programs just act natively when
run on the host.  I suspect that is the part Bill is confused about.

\start
Date: Mon, 4 Sep 2006 00:25:24 -0400
From: Tim Daly
To: list
Subject: --patch-50

Sourceforge SVN trunk/axiom is up to date with the Gold version

There are 390 changes. 

Apparently the automatic conversion from CVS to SVN is broken
with respect to binary files. They have been fixed.

In the trunk/axiom directory there is a directory called PATCH49-50
that contains a file called PATCHES which lists all of the commands
used to make the changes. It also contains *.patch files which are
the diff -Naur changes to each file.

\start
Date: 04 Sep 2006 00:13:00 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: --patch-50

| Sourceforge SVN trunk/axiom is up to date with the Gold version

\start
Date: Mon, 4 Sep 2006 04:13:19 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: cross-compiling Axiom

On Sun, 3 Sep 2006, C Y wrote:

| Gaby, just for my own information:
|
| Is this issue similar to (say) compiling CMUCL or SBCL for a new
| platform, working from a current one?

In essence, it is similar.

I never looked at SBCL before you mentioned it in this thread.
I briefly browsed their website and the description of their build
process.  They claim cross-compilation of SBCL is straghtforward

      http://www.sbcl.org/porting.html

I rest my case.  (Or maybe they don't know how Lisp works :-)

[...]

| I would have thought if GCL was able to do this then Axiom probably
| would be able to too, give or take the non-lisp parts of the system -
| am I missing something?

I don't think you are missing anything.  I don't believe the current
build of GCL can be subjbect to cross-compilation -- from reading its
makefile.

For the type of work I'm doing, we don't need the Axiom compiler as a
cross-compiler -- it would remain native.  We want it to be
cross-compiled.


| Or is GCL in fact not able to be distributed for similar reasons?

I don't know; Camm may have more answers here.
It certainly does not come with the linux version I use.

| I would be interested to know how Maxima fairs in this situation.

maxima does not come with the distro I used -- I don't know for RH.
But, isn't Maxima capable of using a lisp implementation other than GCL?

| Cheers, and thanks again for all your hard work.

You're welcoome.  Thanks!

\start
Date: Mon, 4 Sep 2006 13:10:17 -0400
From: Tim Daly
To: list
Subject: SVN problems

Perhaps it is just me but SVN is very frustrating to use.
It gets itself into this 'locked' state and cannot escape.
The only method I've found so far is to completely rm the whole tree
and fetch it fresh. 
  svn cleanup . 
is a worthless command.

Am I the only one with this problem?

\start
Date: Mon, 4 Sep 2006 13:30:24 -0400
From: Tim Daly
To: list
Subject: SVN problems

OK, I give up with SVN.

Apparently all of the effort I put into the system yesterday and last
night is broken.

I copied correct versions of the jpg files (which were broken).
I marked several hundred files as 'binary', including these jpg files.
I committed all of the changes.
The commit succeeded.

Due to a lock problem here I removed all of the svn directory.
Then I did an svn checkout to re-fetch the tree.
It appears that the work I did was lost even though the commit succeeded.
For example, try 
  firefox axiom30yr.jpg
which should be a picture of a bayou. The picture is broken. Still.
Even though I explicitly copied a correct version, marked the new
version with svn tags, and had a confirmed commit.

SVN is clearly not ready for prime time.

\start
Date: Mon, 04 Sep 2006 19:54:17 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: SVN problems

I don't know on which system you work, but I had no problem with the svn 
on debian that I installed via

apt-get -i subversion

Just use

svn checkout https://svn.sourceforge.net/svnroot/axiom/trunk
svn update
-- change something
svn commit

I have no idea why you needed "svn tags". That is basically like copying 
a directory. Completely irrelevant to commit the Gold patches to 
silver/trunk. "svn tags" is definitely not the same as "cvs tag".

Ralf

On 09/04/2006 07:30 PM, root wrote:
> OK, I give up with SVN.
> 
> Apparently all of the effort I put into the system yesterday and last
> night is broken.
> 
> I copied correct versions of the jpg files (which were broken).
> I marked several hundred files as 'binary', including these jpg files.
> I committed all of the changes.
> The commit succeeded.
> 
> Due to a lock problem here I removed all of the svn directory.
> Then I did an svn checkout to re-fetch the tree.
> It appears that the work I did was lost even though the commit succeeded.
> For example, try 
>   firefox axiom30yr.jpg
> which should be a picture of a bayou. The picture is broken. Still.
> Even though I explicitly copied a correct version, marked the new
> version with svn tags, and had a confirmed commit.
> 
> SVN is clearly not ready for prime time.

\start
Date: Mon, 4 Sep 2006 13:57:09 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN problems

I have svn installed.

to see the problem do an svn checkout and then do:
  firefox axiom30yr.jpg

svn tries to guess which files are binary.
sometimes it fails.
you can mark the files with svn keyword tags (yes, not CVS tags)
that tell svn that the file is binary. or so they claim. but it failed.

my major problem is that svn appears to have lost my work.
the WHOLE point of version control is NEVER to lose work.
thus SVN appears to miss the main reason it exists.

clearly this must be something i'm doing wrong
but after twice reading the docs and much frustration
i give up.

\start
Date: 04 Sep 2006 13:38:56 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: SVN problems

| my major problem is that svn appears to have lost my work.
| the WHOLE point of version control is NEVER to lose work.
| thus SVN appears to miss the main reason it exists.

I've never lost anything with SVN for over a year of heavy usewith
other major projects. 

I'll try to look into your issues later tonight.

\start
Date: Mon, 04 Sep 2006 21:46:18 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: SVN problems

> my major problem is that svn appears to have lost my work.
> the WHOLE point of version control is NEVER to lose work.
> thus SVN appears to miss the main reason it exists.
> 
> clearly this must be something i'm doing wrong
> but after twice reading the docs and much frustration
> i give up.

Why don't you ask for help at the axiom-developer mailing list?
If you tell what you want to achieve, maybe someone is giving you the 
right commands and you could save your time instead of reading the 
svn-book several times. You probably only need 3 or 4 commands with any 
SCM. But it's always better if someone tells you what and how to use it.

And I believe you are wrong. It's not svn that gets the binary wrong.
I did the following, and the picture was ok. I would have been very much 
surprised if the Subversion people made such a big mistake for a .jpg 
file that very much looks binary.
svnadmin create --fs-type fsfs /home/hemmecke/scratch/SVNMYTEST 

cd ~/scratch
mkdir axiom
cd axiom
cp ~/OTHER/Axiom/axiom--main--1--patch-50/axiom* .
svn import . file:///home/hemmecke/scratch/SVNMYTEST/AXIOM
Adding  (bin)  axiomicon.png
Adding  (bin)  axiom30yr.jpg
Adding  (bin)  axiomsml.png
Adding  (bin)  axiomlogo.jpg

Committed revision 1.
cd ~/scratch
svn co file:///home/hemmecke/scratch/SVNMYTEST/AXIOM ax
A    ax/axiomicon.png
A    ax/axiom30yr.jpg
A    ax/axiomsml.png
A    ax/axiomlogo.jpg
Checked out revision 1.
display ax/axiom30yr.jpg

Anyway the difference of the pictures from Gold and Silver/trunk is a 
translation of 0x0d to 0x0a in several places.

Maybe the picture is already broken in CVS and was wrongly moved from 
CVS to SVN?

\start
Date: Mon, 4 Sep 2006 16:48:04 -0400
From: Bill Page
To: Tim Daly
Subject: RE: SVN problems

On September 4, 2006 1:10 PM Tim Daly wrote:
> 
> Perhaps it is just me but SVN is very frustrating to use.
> It gets itself into this 'locked' state and cannot escape.
> The only method I've found so far is to completely rm the
> whole tree and fetch it fresh. 
>   svn cleanup . 
> is a worthless command.
> 
> Am I the only one with this problem?
> 

I have had no problems at all with svn on linux, but on Windows
using TortoiseSVN I have not yet succeeded in getting a complete
checkout. The symptoms are identical to what you describe: the
download fails, the tree gets locked and although instructed to
use the 'svn cleanup' command to correct the problem, this has
no effect.

When I get serious about using svn on windows I will probably
be forced to use the cygwin version.

I had similar problems with arch (tla) on Windows. The only
source code system that has worked reliably for me on both Linux
and Windows has been darcs.

\start
Date: 04 Sep 2006 15:50:02 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: SVN problems

Ralf Hemmecke writes:

| Committed revision 1.
| cd ~/scratch
| svn co file:///home/hemmecke/scratch/SVNMYTEST/AXIOM ax
| A    ax/axiomicon.png
| A    ax/axiom30yr.jpg
| A    ax/axiomsml.png
| A    ax/axiomlogo.jpg
| Checked out revision 1.
| display ax/axiom30yr.jpg
| 
| Anyway the difference of the pictures from Gold and Silver/trunk is a
| translation of 0x0d to 0x0a in several places.

Ralf, please could you check in the corrected versions?

\start
Date: Mon, 4 Sep 2006 17:56:55 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: SVN problems

On September 4, 2006 3:46 PM Ralf Hemmecke
> ... 
> Anyway the difference of the pictures from Gold and Silver/trunk
> is a translation of 0x0d to 0x0a in several places.
> 
> Maybe the picture is already broken in CVS and was wrongly moved
> from CVS to SVN?
> 

Yes, there are still some files in the Axiom CVS that are not
properly marked as binary. When using just CVS this doesn't
matter because CVS does not mangle text file contents. At least
on SourceForge when moving a file from CVS to SVN the binary or
text attribute from CVS is retained. SVN does mangle text files,
recreating what it thinks are proper line endings. I recall that
we discussed this a few months ago when we first set up the SVN
repository.

However Tim did write:

> I marked several hundred files as 'binary', including these
> jpg files.

I am not sure if he was referring to CVS or SVN but obviously
these files should be marked correctly in both places. And your
test shows that this is done automatically by 'svn import' without
having to "mark" them. But I presume that Tim was trying to change
the binary attribute of files that were already in SVN with the
wrong attribute (having been copied from CVS). Perhaps to correct
this problem it is necessary to remove these files first and then
re-import them? Or to mark them properly in CVS and move them
again?

\start
Date: Tue, 05 Sep 2006 00:07:35 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: SVN problems

> However Tim did write:
> 
>> I marked several hundred files as 'binary', including these
>> jpg files.
> 
> I am not sure if he was referring to CVS or SVN but obviously
> these files should be marked correctly in both places. And your
> test shows that this is done automatically by 'svn import' without
> having to "mark" them. But I presume that Tim was trying to change
> the binary attribute of files that were already in SVN with the
> wrong attribute (having been copied from CVS). Perhaps to correct
> this problem it is necessary to remove these files first and then
> re-import them? Or to mark them properly in CVS and move them
> again?

The CVS manual says

    The `-kb' option available with some CVS commands insures that
neither line ending conversion nor keyword expansion will be done.

    Here is an example of how you can create a new file using the `-kb'
flag:

      $ echo '$Id$' > kotest
      $ cvs add -kb -m"A test file" kotest
      $ cvs ci -m"First checkin; contains a keyword" kotest

    If a file accidentally gets added without `-kb', one can use the
`cvs admin' command to recover.  For example:

      $ echo '$Id$' > kotest
      $ cvs add -m"A test file" kotest
      $ cvs ci -m"First checkin; contains a keyword" kotest
      $ cvs admin -kb kotest
      $ cvs update -A kotest
      # For non-unix systems:
      # Copy in a good copy of the file from outside CVS
      $ cvs commit -m "make it binary" kotest

Let's hope that one can trust that.

\start
Date: Mon, 4 Sep 2006 18:06:47 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN problems

> Maybe the picture is already broken in CVS and was wrongly moved from 
> CVS to SVN?

The picture is fine in CVS. I found a site online that said that the
automatic conversion function fails to properly classify binaries.
The SVN site was created automatically from CVS by Sourceforge.
I suspect the binary problem started there.

If you look in PATCH49-50/PATCHES you can see the commands I used
to mark the files. (PATCHES contains all the commands I executed
that modified the repository).

I did an Arch checkout (to axiom) and an SVN checkout (to silver).
Then I did:
   diff -r --brief axiom silver
and found that the axiom30yr.jpg was different because of newlines.
(Why a source code control system changes a file is beyond me.)

So I copied a corrected version, check that it was correct with
   firefox axiom30yr.jpg
and used the recommended command (see the PATCHES file).

Eventually I did
  svn commit
which said it worked. Then it sent email to the list saying
that a commit happened. Thus, my files are now safe (since
commit is supposed to be a transaction, either fully succeeding
or fully failing).

A clean, new checkout shows that the file is still mangled.

And the problem is not only .jpg files. 

If you look at the zips directory some of the patch files 
do not compare. Patch files are straight ascii text. They
are designed to survive being sent by email which traditionally
mangles data.





If you want a silver branch that contains the latest patches
I'm willing to maintain that. But SVN is not a good place to
do that it seems. Since people don't like Arch or CVS perhaps
we could consider darcs which Bill seems to love (and which is
the only system we haven't yet tried).

Failing that I'd be happy to set up a silver Arch branch.

\start
Date: Mon, 4 Sep 2006 18:37:24 -0400
From: Bill Page
To: Tim Daly
Subject: RE: SVN problems

On September 4, 2006 6:07 PM Tim Daly wrote:

> ... 
> If you want a silver branch that contains the latest patches
> I'm willing to maintain that. But SVN is not a good place to
> do that it seems.

Tim, I think your conclusion is still to "hasty". Yes, SVN has
problems, but like the other systems I am confident that it can
be made to work.

> Since people don't like Arch or CVS perhaps we could consider
> darcs which Bill seems to love (and which is the only system
> we haven't yet tried).

I am sure that we could find ways to screw-up darcs also. :) There
are quite a few projects do use darcs, including Sage and it seems
to be popular with lisp projects:

  http://www.cliki.net/admin/search?words=darcs

But I would *not* recommend that we switch to darcs now - even
though I do think it is a better source code control system.

> 
> Failing that I'd be happy to set up a silver Arch branch.
> 

I think we need to resolve the problems Tim is having with SVN
and then get on with what we have been planning for the last
few months with Axiom Silver on SVN.

\start
Date: 04 Sep 2006 18:40:13 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: SVN problems

Bill Page writes:

| On September 4, 2006 6:07 PM Tim Daly wrote:
| 
| > ... 
| > If you want a silver branch that contains the latest patches
| > I'm willing to maintain that. But SVN is not a good place to
| > do that it seems.
| 
| Tim, I think your conclusion is still to "hasty". Yes, SVN has
| problems, but like the other systems I am confident that it can
| be made to work.

Indeed.

[...]

| I think we need to resolve the problems Tim is having with SVN
| and then get on with what we have been planning for the last
| few months with Axiom Silver on SVN.

Fully agreed.

The trouble is I don't what his settings are.  All colleagues I work
with here and outside have not reported the same kind of troubles he
is having.  You seem to know the symptoms...  Tim are you indeed using
a windows-based system?  Bill, how did you "solve" the problems?

\start
Date: Mon, 4 Sep 2006 19:58:58 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: SVN problems

> The trouble is I don't what his settings are.  All colleagues I work
> with here and outside have not reported the same kind of troubles he
> is having.  You seem to know the symptoms...  Tim are you indeed using
> a windows-based system?  Bill, how did you "solve" the problems?

I'm using Fedora Core 5. There aren't any 'settings' that I'm aware of.
I just did

   svn checkout
   modify files
   svn commit

Under what conditions would you expect to check in a file,
check it out again, and have it not compare? 

Try checking out the Arch golden source and do a 
  diff -r --brief golden silver

At the time I did the silver commit these two source trees were identical.
Following the commit I did an svn checkout and the trees differ radically.

\start
Date: Mon, 4 Sep 2006 20:58:18 -0400
From: Bill Page
To: Tim Daly
Subject: RE: SVN problems
Cc: Gabriel Dos Reis

On September 4, 2006 7:59 PM Tim Daly wrote:

> ...
> > Tim are you indeed using a windows-based system?
> 
> I'm using Fedora Core 5. There aren't any 'settings' that I'm 
> aware of.

> > Bill, how did you "solve" the problems?

Although the answer is irrelevant to Tim's situation, I do not
have a solution to the problems on Windows yet. Most recently
I upgraded my version of TortioseSVN but the problem did not
go away. My next attempt will be to install the cygwin version
of SVN and try it that way. Of course since we don't build
Axiom under cygwin on Windows, that is less than desirable.
Perhaps there is another native Windows version of SVN besides
Tortoise?

> I just did
> 
>    svn checkout
>    modify files
>    svn commit
> 
> Under what conditions would you expect to check in a file,
> check it out again, and have it not compare? 
>

I believe that this would happen if the files you are modifying
are incorrectly labelled as 'text' files.
 
> Try checking out the Arch golden source and do a 
>   diff -r --brief golden silver
> 
> At the time I did the silver commit these two source trees 
> were identical. Following the commit I did an svn checkout
> and the trees differ radically.
> 

I expect this would happen for example to .jpg and .zip files
already in the repository that are not properly labelled as
'binary'. You need to change this attribute in SVN for these
files before doing the commit.

\start
Date: Mon, 4 Sep 2006 21:08:41 -0400
From: Tim Daly
To: Bill Page
Subject: Re: SVN problems
Cc: Gabriel Dos Reis

> Although the answer is irrelevant to Tim's situation, I do not
> have a solution to the problems on Windows yet. Most recently
> I upgraded my version of TortioseSVN but the problem did not
> go away. My next attempt will be to install the cygwin version
> of SVN and try it that way. Of course since we don't build
> Axiom under cygwin on Windows, that is less than desirable.
> Perhaps there is another native Windows version of SVN besides
> Tortoise?

I tried to use windows but the disk is formatted for FAT32.
For some reason the filenames fail to match under windows.
For instance, in the license subdirectory there is (on linux)
an uppercase filename 'LICENSE.AXIOM' which stays uppercase
on the FAT32 disk. But there is an uppercase 'LICENSE.CC'
in the same directory on the same disk which gets stored as
'license.cc' (lowercase). I can't figure out the pattern.
And the system considers 'license.cc' and 'LICENSE.CC' equivalent
names but diff doesn't agree which seriously complicates the compare.

> I believe that this would happen if the files you are modifying
> are incorrectly labelled as 'text' files.

True. Apparently SVN likes to rewrite end-of-line characters.
I don't know why.
 
> I expect this would happen for example to .jpg and .zip files
> already in the repository that are not properly labelled as
> 'binary'. You need to change this attribute in SVN for these
> files before doing the commit.

Well, it's not quite that simple as there is no 'binary' attribute
in SVN. But I did find the equivalent command, at least I think I
did, and changed it for the files. See PATCH49-50/PATCHES.

And it is not simply 'binary' vs 'text' apparently. SOME of the
.patch files (not all, which puzzles) in zips have been changed
by SVN. The .patch files are clearly text.

\start
Date: Mon, 4 Sep 2006 22:22:35 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: cross-compiling Axiom

On September 4, 2006 5:13 AM Gabriel Dos Reis wrote:
> 
> On Sun, 3 Sep 2006, C Y wrote:
> 
> | Gaby, just for my own information:
> |
> | Is this issue similar to (say) compiling CMUCL or SBCL for a
> | new platform, working from a current one?
> 
> In essence, it is similar.
> 
> I never looked at SBCL before you mentioned it in this thread.
> I briefly browsed their website and the description of their build
> process.  They claim cross-compilation of SBCL is straightforward
> 
>       http://www.sbcl.org/porting.html
> 
> I rest my case.  (Or maybe they don't know how Lisp works :-)
>

Or maybe they don't even know what cross-compilation is? ;) Did you
read the description of the SBCL "cross-compilation" process?

http://sbcl-internals.cliki.net/Build

Even the first line on the page Gaby quoted above says:

"Unlike most free software, SBCL can't bootstrap itself directly
from the gcc suite."

So all the rest that follows is related to this feature of SBCL. In
contrast, GCL *can* be built directly given gcc and continues to
depend on gcc even after it is built. In that sense GCL is just an
extension of gcc. So if the SBCL definition of cross-compile is
allowed, then of course both GCL and Axiom can be "cross-compiled".
All we have to do is first cross-compile gcc for the target system.
Then we just proceed to build GCL on the target system as we would
any other system (as is done on Debian for example).

Notice the steps under "Cross-Compiling" on the SBCL page look more
like Tim's description of "Cross-Mounting" than cross-compiling.
The final SBCL binary is built on the target system through a
standard lisp 'save-system' command - *not* on the host.

http://sbcl-internals.cliki.net/make-target-2

So it is clear that SBCL can not be cross-compiled in the sense
of simply specifying a target different from the host system on
the ./configure command.
 
> [...]
> 
> | I would have thought if GCL was able to do this then Axiom
> | probably would be able to too, give or take the non-lisp parts
> | of the system - am I missing something?
> 
> I don't think you are missing anything.  I don't believe the current
> build of GCL can be subject to cross-compilation -- from reading
> its makefile.

Most of GCL is written in C. It does not require an existing ANSI
Common Lisp executable as a host for initial bootstrapping the way
SBCL does. So "cross-compiling" GCL is actually easier than in the
case of SBCL.

If what SBCL does is cross-compiling than it seems that we have
simply been arguing over semantics (the same words used differently)
and not a real problem. :(

On the other hand I would prefer to use the term 'cross-compile"
in a more standard manner, to refer to the case where the final
target code is created on the host system.

> 
> For the type of work I'm doing, we don't need the Axiom compiler
> as a cross-compiler -- it would remain native.  We want it to be
> cross-compiled.
> 

Since the Axiom compiler is written in Lisp and BOOT, and BOOT
compiles to Lisp, and GCL compiles Lisp to C, and GCL is
written in C and is compiled with gcc, and gcc can be cross-
compiled ... what is the problem?

> 
> | Or is GCL in fact not able to be distributed for similar
> | reasons?
> 
> I don't know; Camm may have more answers here.
> It certainly does not come with the Linux version I use.
> 
> | I would be interested to know how Maxima fairs in this
> | situation.
> 
> maxima does not come with the distro I used -- I don't know for
> RH. But, isn't Maxima capable of using a lisp implementation 
> other than GCL?
>

These days Maxima is usually built using Clisp, but GCL is still
an option of the configure. Clisp is at included in the Fedora
Linux distribution (extras). Debian includes both Clisp and GCL.

Clisp uses a byte-code interpreter. It does not compile to object
code on the target machine, so cross-compilation should not be
much of an issue, but I was not able to find anything in the Clisp
documentation that suggests that ./configure actually supports
cross-compilation, i.e. creating a binary for target system
different than the host.

It is also not clear to me from the maxima ./configure options
if the Maxima build can compile Clisp byte-code intended for
use on a target system different from the host. Has anyone tried
this? E.g. Successfully building a version of Maxima for Sparc
hardware on an i386 Linux system?

\start
Date: Mon, 4 Sep 2006 23:30:03 -0400
From: Bill Page
To: Tim Daly
Subject: RE: SVN problems
Cc: Gabriel Dos Reis

Tim,

On September 4, 2006 9:09 PM you wrote:
> ...
> Bill Page wrote: 
> > I believe that this would happen if the files you are modifying
> > are incorrectly labelled as 'text' files.
> 
> True. Apparently SVN likes to rewrite end-of-line characters.
> I don't know why.
>  
> > I expect this would happen for example to .jpg and .zip files
> > already in the repository that are not properly labelled as
> > 'binary'. You need to change this attribute in SVN for these
> > files before doing the commit.
> 
> Well, it's not quite that simple as there is no 'binary' attribute
> in SVN. But I did find the equivalent command, at least I think I
> did, and changed it for the files. See PATCH49-50/PATCHES.
> 

What you did looks ok to me except that I notice you did not remove
the eol-style property on the jpg files. I think you need:

   svn propdel svn:eol-style *.jpg

Could this be the problem?

> And it is not simply 'binary' vs 'text' apparently. SOME of the
> .patch files (not all, which puzzles) in zips have been changed
> by SVN. The .patch files are clearly text.
> 

Yes, see:

http://subversion.tigris.org/faq.html#binary-files

I think you might need to check/set the properties

  svn proplist *.jpg

  svn propset svn:mime-type image/jpeg filename.jpg

  svn propdel svn:eol-style filename.jpg

  cd zips

  svn proplist *.tgz

  svn propget svn:mime-type *.tgz

  svn propget svn:eol-style *.patch

  svn propset svn:mime-type application/octet-stream filename.tgz

  svn propset svn:eol-style native filename.patch

etc.

\start
Date: Tue, 5 Sep 2006 03:44:32 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: re: cross-compiling Axiom

On Mon, 4 Sep 2006, Bill Page wrote:

| On September 4, 2006 5:13 AM Gabriel Dos Reis wrote:
| >
| > On Sun, 3 Sep 2006, C Y wrote:
| >
| > | Gaby, just for my own information:
| > |
| > | Is this issue similar to (say) compiling CMUCL or SBCL for a
| > | new platform, working from a current one?
| >
| > In essence, it is similar.
| >
| > I never looked at SBCL before you mentioned it in this thread.
| > I briefly browsed their website and the description of their build
| > process.  They claim cross-compilation of SBCL is straightforward
| >
| >       http://www.sbcl.org/porting.html
| >
| > I rest my case.  (Or maybe they don't know how Lisp works :-)
| >
|
| Or maybe they don't even know what cross-compilation is? ;)

Huh?!?

| Did you
| read the description of the SBCL "cross-compilation" process?

*Yes*.

| http://sbcl-internals.cliki.net/Build
|
| Even the first line on the page Gaby quoted above says:
|
| "Unlike most free software, SBCL can't bootstrap itself directly
| from the gcc suite."

Yes, that does not preclude cross-compilation.

You see, GCC for example, can no longuer be bootstrapped with a K&R C
compiler.  You need an ANSI C compiler to bootstrap GCC, just like you
need a LISP compiler to bootstrap SBCL.

The (in)ability of bootstrapping from GCC does not constitute a
criteria of cross-compilation.  However, it may be an issue in the
context of GNU toolchain.

| So all the rest that follows is related to this feature of SBCL. In
| contrast, GCL *can* be built directly given gcc and continues to
| depend on gcc even after it is built.

The question is not whether GCL can be built directly given gcc, but
whether GCL can be cross-compiled in the context of GNU toolchain.  If
GCL claims to be the official GNU implementation of Common Lisp, then
we better find a way to get there.

Exactly what are you disputing now?  That Lisp cannot be
cross-compiled?  Or that SBCL cannot be cross-compiled or that that
cross-compilation must consist of ./configure --target=...?

That is important to know, because it is no longer clear to me what
you're driving at.

Take GCC for example, you CANNOT cross-compile it if you do not have
the binutils binaries for the target system.   That is a pretty much a
basic requirement -- similar to SBSL requiring a sufficiently
ANSI-compliant Lisp to start up.

Furthermore, if you want to bootstrap GCC on a platform (say HPUX)
lacking an ANSI C compiler, you need at least a binary of GCC
for that platform.   I don't see that situation different from SBCL
requiring a LISP compiler to start up bootstrap.


| In that sense GCL is just an extension of gcc.

LOL.  In that sense, the whole world is an extension of GCC.
But, again, being an extension of GCC is not the issue at hand.
Many software are extension of GCC (in your sense), still fare better
with cross-compilation.  I suspect being an extension of GCC is not a
sufficient condition.

| So if the SBCL definition of cross-compile is
| allowed, then of course both GCL and Axiom can be "cross-compiled".
| All we have to do is first cross-compile gcc for the target system.

Yes, but that is still insufficient.  We need to do more work to get
to cross-compilation with the GNU toolchain -- that is all that counts
if we ever want Axiom (based on GCL) shipped with linux distros.

| Then we just proceed to build GCL on the target system as we would
| any other system (as is done on Debian for example).

Yes, we *just*.  Except that at the moment, we don't make sure that
will work in a cross-compilation context with the GNU toolchain.  I
tried yesterday afternoon with no luck :-(

| Notice the steps under "Cross-Compiling" on the SBCL page look more
| like Tim's description of "Cross-Mounting" than cross-compiling.
| The final SBCL binary is built on the target system through a
| standard lisp 'save-system' command - *not* on the host.

yes; who asked you to save GCL image on the host?

This is situation is no different from what we (speaking of GCC) are
used to when we have to regression-test GCC on different architecture
(which include *bootstrapping* a cross-compiled compiler and *use* it)
when we don't have access to the target.

      http://gcc.gnu.org/simtest-howto.html

My question is very simple: Can I set up an environment like that that
let cross-compile GCL?  The asnwer at the moment is NO.  Can it be
done. The answer is YES.  Do I need cross-mounting?  I think NO.
No matter how much you deny cross-compilation of Lisp.

[...]

| > | I would have thought if GCL was able to do this then Axiom
| > | probably would be able to too, give or take the non-lisp parts
| > | of the system - am I missing something?
| >
| > I don't think you are missing anything.  I don't believe the current
| > build of GCL can be subject to cross-compilation -- from reading
| > its makefile.
|
| Most of GCL is written in C. It does not require an existing ANSI
| Common Lisp executable as a host for initial bootstrapping the way
| SBCL does. So "cross-compiling" GCL is actually easier than in the
| case of SBCL.

Huh?!?

| If what SBCL does is cross-compiling than it seems that we have
| simply been arguing over semantics (the same words used differently)
| and not a real problem. :(

what SBCL does is cross-compilation.  I don't believe I have been
arguing over semantics.  I do have a fundamental issue.  How do I get
Axiom (and therefore GCL) to support cross-compilation in the context
of GNU toolchain.  First, you have suggested that anyone thinking of
cross-compiling GCL does not understand Lsip.  When offered compeling
Lisp-based system supporting cross-compilation, you are that


| On the other hand I would prefer to use the term 'cross-compile"
| in a more standard manner, to refer to the case where the final
| target code is created on the host system.

*which* final code?

| > For the type of work I'm doing, we don't need the Axiom compiler
| > as a cross-compiler -- it would remain native.  We want it to be
| > cross-compiled.
| >
|
| Since the Axiom compiler is written in Lisp and BOOT, and BOOT
| compiles to Lisp, and GCL compiles Lisp to C, and GCL is
| written in C and is compiled with gcc, and gcc can be cross-
| compiled ... what is the problem?

is that supposed to be an existential proof?

Sorry, I've little time for quibbling.  If you believe Axiom in its
current form supports cross-compilation in the GNU toolchain context,
please work out precisely th details for me.  That would sve me lot of
work.  Otherwise, help me with more constructive proofs.

Here is an idea of what it takes to cross-compile GCC, for example

     http://linux.bytesex.org/cross-compiler.html

(or course, I could have given you the link to Dan Kegel's more
elaborated and complete crosstool suite, but I prefer the above link
for its simplicity at exposing the core issues.

Please, again have a look at the description of how SBCL achieves
cross-compilation.

\start
Date: Tue, 05 Sep 2006 11:27:41 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: SVN problems

> | Committed revision 1.
> | cd ~/scratch
> | svn co file:///home/hemmecke/scratch/SVNMYTEST/AXIOM ax
> | A    ax/axiomicon.png
> | A    ax/axiom30yr.jpg
> | A    ax/axiomsml.png
> | A    ax/axiomlogo.jpg
> | Checked out revision 1.
> | display ax/axiom30yr.jpg
> | 
> | Anyway the difference of the pictures from Gold and Silver/trunk is a
> | translation of 0x0d to 0x0a in several places.
> 
> Ralf, please could you check in the corrected versions?

Done. Because, I saw terribly wrong properties set, I simply removed the 
files from SVN/trunk and added the correct versions. Now we have.

Properties on 'axiom/axiom30yr.jpg':
   svn:mime-type : application/octet-stream
Properties on 'axiom/axiomicon.png':
   svn:executable : *
   svn:mime-type : application/octet-stream
Properties on 'axiom/axiomlogo.jpg':
   svn:executable : *
   svn:mime-type : application/octet-stream
Properties on 'axiom/axiomsml.png':
   svn:executable : *
   svn:mime-type : application/octet-stream

The executable property probably comes from the fact that my fresh 
checkout of Gold has the executable bit set.

But I have the impression that those files are not the only once that 
cause trouble.

For example,

Properties on 'axiom/src/hyper/viewports/ugGraphTwoDOptionsPage7.VIEW/data':
   svn:keywords : Author Date Id Revision
   svn:eol-style : native
Properties on 
'axiom/src/hyper/viewports/ugGraphTwoDOptionsPage7.VIEW/graph0':
   svn:keywords : Author Date Id Revision
   svn:eol-style : native
Properties on 
'axiom/src/hyper/viewports/ugGraphTwoDOptionsPage7.VIEW/image.bm.Z':
   svn:mime-type : application/octet-stream
   svn:keywords : Author Date Id Revision
   svn:eol-style : native
Properties on 
'axiom/src/hyper/viewports/ugGraphTwoDOptionsPage7.VIEW/image.xpm.Z':
   svn:mime-type : application/octet-stream
   svn:keywords : Author Date Id Revision
   svn:eol-style : native

There are also other .Z files that have svn:keywords and svn:eol-style set.

The whole axiom/src/hyper/bitmaps directory contains files with

   svn:keywords : Author Date Id Revision
   svn:eol-style : native

I don't think that the conversion CVS-->SVN was the best idea. It should 
have been "svn import" from the tla archive. Tim, is there something 
like a "tla export" which gives the files without the tla status files 
(like that .arch-ids directory)?

Gaby, since we want Silver/trunk to be in sync with Tim's Gold-to-be 
branch, would it make sense to remove the archive and just import from 
--patch-50 anew? I have no idea however, how to merge then with the 
build-improvements branch. Or do you have more experience with SVN to 
cure the problem?

\start
Date: Tue, 5 Sep 2006 04:57:16 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: SVN problems

On Tue, 5 Sep 2006, Ralf Hemmecke wrote:

| > | Committed revision 1.
| > | cd ~/scratch
| > | svn co file:///home/hemmecke/scratch/SVNMYTEST/AXIOM ax
| > | A    ax/axiomicon.png
| > | A    ax/axiom30yr.jpg
| > | A    ax/axiomsml.png
| > | A    ax/axiomlogo.jpg
| > | Checked out revision 1.
| > | display ax/axiom30yr.jpg
| > |
| > | Anyway the difference of the pictures from Gold and Silver/trunk is a
| > | translation of 0x0d to 0x0a in several places.
| >
| > Ralf, please could you check in the corrected versions?
|
| Done. Because, I saw terribly wrong properties set, I simply removed the
| files from SVN/trunk and added the correct versions. Now we have.

thanks for your time!

I do agree that "import" would have been a better setup.  Oh well,
with hindsight... :-)

[...]

| Gaby, since we want Silver/trunk to be in sync with Tim's Gold-to-be
| branch, would it make sense to remove the archive and just import from
| --patch-50 anew? I have no idea however, how to merge then with the
| build-improvements branch. Or do you have more experience with SVN to
| cure the problem?

Interesting.  We do definetly want silver to be in sync with gold
wherever possible.  The only issue with respect to restarting again is
indeed what happens to  work done on branches made on silver.  I
suspect that at the moment, we have two branches where people have
"actively" put work: the one by Antoine and the build-improvements.

I'm not familiar with Antoine's branch to comment.

As of the build-improvements, we have some work there that might not
cleanly apply to a fresh tree from gold -- I really don't know, that
is just a first approximation thought.  I have more work in the
pipeline waiting for testing and fixes; this is done against current
silver.

Do you believe we cannot fix the other "binary" type files without
restarting afresh (would have been much simpler if we did not have other
branches)?

\start
Date: 05 Sep 2006 05:27:49 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: New Axiom release

Tim, would you release --patch-50 as a new version of Axiom?

I would like to tell people, go and pick that tarball -- it is
official release -- and build and install it.  

I would rather avoid "get CVS, tla, svn", and then figure out whether
you make something out of it.

\start
Date: Tue, 05 Sep 2006 12:34:23 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: SVN problems

> I'm not familiar with Antoine's branch to comment.

I am sure Antoine comments on it.

> As of the build-improvements, we have some work there that might not
> cleanly apply to a fresh tree from gold -- I really don't know, that
> is just a first approximation thought.

Well, my problem is that I don't know what happens if I simply remove 
the svn:eol-style and svn:keywords properties. We should certainly 
remove the svn:keywords property from ALL files. The svn:eol-style would 
probably not do any harm since internally svn stores the files with a 
Unix line end marker. The problem is that all binaries that are in SVN 
might be corrupt inside the archive, since if the svn:eol-style property 
is set, then svn translates 0x0D to 0x0A (Mac -> Unix) while putting the 
file into the svn repository. So no matter whether I delete the property 
now, the file is corrupt. (My guess, I haven't actually checked it.)

So basically, the procedure would be.

1) Remove the svn:keywords property from ALL files.
2) Remove the svn:eol-style property from binary files (maybe even ALL
    would be OK???)
3) Checkout a fresh copy of silver/trunk.
4) Copy all source files from --patch-50 to silver/trunk.
5) Commit the change.
    My wild guess is that svn only commits the files that actually differ
    from the repository. I hope that svn does not take the copy date into
    account.

I don't know whether the property change can be merged with the 
build-improvements. Any experience?

> Do you believe we cannot fix the other "binary" type files without
> restarting afresh (would have been much simpler if we did not have other
> branches)?

See question above. Does anybody have experience with merging properties 
from one branch to another?

Before any change to the trunk is done. We should make clear that it 
would be the right procedure.

\start
Date: Tue, 5 Sep 2006 14:23:45 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: RE: cross-compiling Axiom

There have been doubts here wether Lisp systems can be croos- 
compiled. Let me mention here a simple method which is used
by some Lisp-like system -- this method shows that cross-
compiling Lisp has no fundamental problems (only usual
problems).

First, why croos-compiling Lisp looks difficult? The reason
is dynamic nature of Lisp: freshly compiled code is loaded
into hast system and used in subsequent compilations. Moreover,
compiling Lisp means building apropriate data structures
which mix ordinary data with machine code. There seem to
be difficulty here: we want data stuctures containg target
machine code as a final result, but during compilation we
need host machine code.

One method which can solve this difficulty is: compile
everything twice, one version for host machine to be
used in further compilation, the second one for target.
In particular, for GCL one can probably just run the
C compiler twice to get object files for target machine.

If done naively this process still requires loading
object files into target Lisp to build the final image.
With such a method to do full build on host one has to
provide cross-Lisp capable just of loading object files
and saving image. While non-trivial (since some code is
executed at load time) such limited cross-Lisp should be
much simpler than full compiler. Alternatively, since
final loading of object files and dumping image is
unlikely to be time critical one can build the final
image at install time.

Of course there are usual cross-compilation problems, for
example (in GCL case) one must make sure that generated
C code works both on host and target machine.

\start
Date: 05 Sep 2006 08:11:42 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: cross-compiling Axiom

Waldek Hebisch writes:

[...]

| With such a method to do full build on host one has to
| provide cross-Lisp capable just of loading object files
| and saving image.

Amen.

now, we just need manpower to get there :-)

[...]

| Of course there are usual cross-compilation problems, for
| example (in GCL case) one must make sure that generated
| C code works both on host and target machine.

Yes.  That is tricky too since GCL uses some "non-standard" aspects of C.

\start
Date: Tue, 5 Sep 2006 09:58:55 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: cross-compiling Axiom

On September 5, 2006 4:45 AM Gabriel Dos Reis wrote:
> ...
> Bill Page wrote:
> | Since the Axiom compiler is written in Lisp and BOOT, and BOOT
> | compiles to Lisp, and GCL compiles Lisp to C, and GCL is
> | written in C and is compiled with gcc, and gcc can be cross-
> | compiled ... what is the problem?
> 
> is that supposed to be an existential proof?
>

No, that is just what SBCL does and of course it can be done
with GCL as well without the bootstrapping issue. GCL already
runs on all of the Debian architectures. That is better than
an existential proof, it is proof by construction.
 
> Sorry, I've little time for quibbling.

You originally raised the issue, claiming that this prevents
the inclusion of Axiom in major Linux distributions. If this
is just a "quibble", then that is quite unfortunate for Axiom.

I find your non-analytic, confrontational manner about this
issue to be rather surprising, given that you obviously
understand and are contributing to the solution of a lot of
other more important issues. I suppose this prompts me to
reply in a like manner. I am sorry for that. :(

But really I am not so sure this is such an important issue.
After all, we do have Axiom available on Debian and Ubantu via

  apt-get install axiom*

Installing Axiom on other major platforms is quite straight
forward. Maybe that is enough. None of Mathematica, Maple,
Maxima nor Sage are include any of the "major" Linux
distributions.

> If you believe Axiom in its current form supports
> cross-compilation in the GNU toolchain context,
> please work out precisely the details for me.

No, GCL (and therefore Axiom) does *not* support cross-
compilation.

> That would save me lot of work.

Could you remind me why you want to do this, again?

> Otherwise, help me with more constructive proofs.

I repeat: What is the problem?

> 
> Here is an idea of what it takes to cross-compile GCC, for
> example
> 
>      http://linux.bytesex.org/cross-compiler.html
> 
> (or course, I could have given you the link to Dan Kegel's more
> elaborated and complete crosstool suite, but I prefer the above
> link for its simplicity at exposing the core issues.

I thought you said you did not want the Axiom compiler to be a
cross-compiler, but only that you wish to cross-compile Axiom.
If by cross-compile, what you really mean is to port Axiom then
(in principle) all that you need to do to do this is to cross-
compile gcc. Of course there are some "sticky issues" concerning
memory management and interface to native operating systems.
This is what prevents for example an easy port of GCL (and Axiom)
from Linux to Windows.

> 
> Please, again have a look at the description of how SBCL
> achieves cross-compilation.
> 

I read it in detail. SBCL does *not* achieve cross-compilation.
You (and they) are confusing porting an application with cross-
compilation. There is nothing in the SBCL build process that
cannot already be done using GCL - already is done on Debian.

\start
Date: Tue, 5 Sep 2006 09:25:57 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: re: cross-compiling Axiom

On Tue, 5 Sep 2006, Bill Page wrote:

| > Sorry, I've little time for quibbling.
|
| You originally raised the issue, claiming that this prevents
| the inclusion of Axiom in major Linux distributions. If this
| is just a "quibble", then that is quite unfortunate for Axiom.
|
| I find your non-analytic, confrontational manner about this
| issue to be rather surprising, given that you obviously
| understand and are contributing to the solution of a lot of
| other more important issues. I suppose this prompts me to
| reply in a like manner. I am sorry for that. :(

I'm quite disappointed by the very manner you approach this issue.

I've bee made aware the Axiom build issue and started work on it.
With the goal of eventually having a system that can be cross-compiled.

You started out a few days ago claiming that anybody who speaks of
cross-compilation of Axiom does not understand who Lisp works.
If your assertion were true, it would effectively stop fruitless work
in early stage and save reousrces.

Therefore, I very politely requested that you elaborate in a
comprehensive manner why you believe that.  You very have consistently
refused to explain yourself.  I've offered examples.  You either
dismiss them, or turn around.  And now, you complain I'm
non-analytical and confrontational.  That IS disppointing.

Please either explain yourself or let's stop this nonsense.

\start
Date: Tue, 5 Sep 2006 08:45:11 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis, Bill Page
Subject: re: cross-compiling Axiom

Just so I can see if I'm successfully following this or not, can I try
and list a few points and see if I am understanding them correctly?

We want to use gcc and the GNU tools to create a binary targeted for HP
Unix Debian Linux on a Sparc, or Windows on an x86 Linux host, that can
be copied from Linux to the target system with ftp or a USB stick and
run with no further compiling.  The target system is in no way required
for anything except running the final binary. Is this what Linux
distributors want to be able to do?  And is the issue that GCL cannot
currently build using the non-host-system binutils and include files
that are required for this to work?  Or will Axiom also have trouble
even if we get GCL itself to do this?

Things We Can Do:

1.  Camm and the Debian team can build GCL and Axiom on a wide variety
of target platforms, but it is not clear if they are doing this using
the "normal" way Linux distributions want to or have some special
provisions like having at least one machine of every target type
available.  Based on Gaby's comments I take it the Debian solution is
not general enough to meet everyone's needs, however they are doing it.

2.  We can build on Linux and sometimes Windows using existing tools on
those platforms, but we cannot build a Linux binary on Windows or a
Windows binary on Linux.  (Correct?)

Moving to other platforms, our options are:

1.  Produce a working GCL for a platform, then build Axiom on that
platform using the GCL made for it

2.  Produce a working GCL and a working Axiom binary for a platform,
with no compiling work done on the target system.

Is that the distinction here Gaby?  Doing 1 is NOT cross-compiling,
while #2 is?  And #2 is the one we currently cannot do?

\start
Date: Tue, 5 Sep 2006 11:55:01 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: cross-compiling Axiom

On September 5, 2006 10:26 AM Gabriel Dos Reis wrote:
> 
> I'm quite disappointed by the very manner you approach this issue.
>

Likewise. :(
 
> I've bee made aware the Axiom build issue and started work on
> it.

I greatly appreciate all the work you have done on the Axiom
Silver build.improvements branch. I think it is great!

> With the goal of eventually having a system that can be 
> cross-compiled.
>

1) Why should we want Axiom to be cross-compiled?

I think there are many more important issues to address.
 
> You started out a few days ago claiming that anybody who speaks
> of cross-compilation of Axiom does not understand who Lisp works.
> If your assertion were true, it would effectively stop fruitless
> work in early stage and save resources.

I still think there is a fundamental misunderstanding.

> 
> Therefore, I very politely requested that you elaborate in a
> comprehensive manner why you believe that. You very have
> consistently refused to explain yourself.

That is not true.

I have explained and so had David Mentre and a few other people
on this list.

> I've offered examples.  You either dismiss them, or turn around.

I have explained in detail why I dismiss them. In each case they
do not satisfy even your own definition of cross-compilation
when earlier you quoted:

http://en.wikipedia.org/wiki/Cross-compiling

in a response to Tim.

"Compiling a program takes place by running a compiler on the
build platform. The compiled program will run on the host platform.
Usually these two are the same; if they are different, the process
is called cross-compilation."

In the SBCL example, the program compilation is not complete until
after extensive initialization and the final 'save-system' which must
be done on the target system. The target is integrally involved in
the process. This is not cross-compilation. At best it attempts to
save a little time by doing *some* of the intermediate compilation
on the host. This is the same thing that Tim described as "cross-
mounting". In that case, the time required to compile SPAD and BOOT
to Lisp is saved by doing this only once on the host.

> And now, you complain I'm non-analytical and confrontational.
> That IS disappointing.

I said that because you have never answered any of my questions
in this thread. You have only been issuing "challenges". I've
numbered the questions 1) and 2) in this email just so you don't
miss them again. :)

> 
> Please either explain yourself or let's stop this nonsense.
> 

When Axiom is built using GCL, gcc becomes an integral part of
Axiom. Axiom cannot run without it. gcc is called every time you
define a function. So to run Axiom you must provide the gcc
environment. If you have the gcc environment, then GCL and Axiom
can be built on the target environment. 2) What is the point of
"jumping-through-hoops" to try to arrange that some part of the
build can take place on a host environment separate from the
target when in the end the target must have the same environment,
must be sufficiently powerful to run Axiom and must in any case
be involved in the creation of the resulting program?

\start
Date: Tue, 5 Sep 2006 11:04:14 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: cross-compiling Axiom

On Tue, 5 Sep 2006, C Y wrote:

| Just so I can see if I'm successfully following this or not, can I try
| and list a few points and see if I am understanding them correctly?
|
| We want to use gcc and the GNU tools to create a binary targeted for HP
| Unix Debian Linux on a Sparc, or Windows on an x86 Linux host, that can
| be copied from Linux to the target system with ftp or a USB stick and
| run with no further compiling.  The target system is in no way required
| for anything except running the final binary. Is this what Linux
| distributors want to be able to do?

Yes.

| And is the issue that GCL cannot
| currently build using the non-host-system binutils and include files
| that are required for this to work?  Or will Axiom also have trouble
| even if we get GCL itself to do this?

If we can get GCL do it, we most certainly can have Axiom move there.

| Things We Can Do:
|
| 1.  Camm and the Debian team can build GCL and Axiom on a wide variety
| of target platforms, but it is not clear if they are doing this using
| the "normal" way Linux distributions want to or have some special
| provisions like having at least one machine of every target type
| available.  Based on Gaby's comments I take it the Debian solution is
| not general enough to meet everyone's needs, however they are doing it.

I'm not familiar enough with the way the Debian people do it.  My
discussion with Benjamin was quite extensive and from what I
understood, we need to do a bit more and then we can take on.
But, I suspect that the linux distros are familiar with the way debian
people do it. Apart from that and other reasons I alluded to I don't
know more about why they do it the way they prefer to do it.

| 2.  We can build on Linux and sometimes Windows using existing tools on
| those platforms, but we cannot build a Linux binary on Windows or a
| Windows binary on Linux.  (Correct?)

yes.

| Moving to other platforms, our options are:
|
| 1.  Produce a working GCL for a platform, then build Axiom on that
| platform using the GCL made for it
|
| 2.  Produce a working GCL and a working Axiom binary for a platform,
| with no compiling work done on the target system.
|
| Is that the distinction here Gaby?

yes.  More precisely, for #2 we would need a simulator for the target
to accomodate GCL (for saving image).

| Doing 1 is NOT cross-compiling,
| while #2 is?  And #2 is the one we currently cannot do?

#2 is the one we cannot currently do.

Elaborating on your #1, if we can produce #1 plus a "cheap" simulator
to build Axiom, then we would be in a very good shape.  Simulators
already exist in the GNU tools chain (see the link I gave earlier
about the way we test GCC on targets we don't have access to).  We
need to convince Axiom to work with GNU toolchains -- that is what
I've been spending time on so far.

\start
Date: Tue, 5 Sep 2006 11:30:54 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: re: cross-compiling Axiom

On Tue, 5 Sep 2006, Bill Page wrote:

| 1) Why should we want Axiom to be cross-compiled?

Because I believe that making Axiom more accessible is a very
important issue for Axiom.  You believe that people can just go
apt-get and voil=E0.  I highly suspect your view is right for a
very restricted class of people.

One way of making Axiom accessible is by "convincing" popular
linux distros to bundle it with their packages.

| I think there are many more important issues to address.

that is your belief.

I however agree there are other important issues to address. At the
moment, I don't believe they are more important that "getting Axiom to
the masses".

[...]

| I have explained and so had David Mentre and a few other people
| on this list.

David's message (from April) got an answer from Benjamin.
How many other people on this list?  Please be specific.

| > I've offered examples.  You either dismiss them, or turn around.
|
| I have explained in detail why I dismiss them. In each case they
| do not satisfy even your own definition of cross-compilation
| when earlier you quoted:
|
| http://en.wikipedia.org/wiki/Cross-compiling
|
| in a response to Tim.
|
| "Compiling a program takes place by running a compiler on the
| build platform. The compiled program will run on the host platform.
| Usually these two are the same; if they are different, the process
| is called cross-compilation."
|
| In the SBCL example, the program compilation is not complete until
| after extensive initialization and the final 'save-system' which must
| be done on the target system. The target is integrally involved in
| the process.

but that does not disqualify it from being a cross-compilation.  If
you follow a cross-compilation of GCC step by step, you'll notice
that, in effect we do similar things except that it is less
noticeable.  The "save image" step in the SBCL case, corresponds to
the "linking step" of GCC and its dependence on libgcc (except that
the linker does not run the executable but in needs to be a cross).
The save image step can be made by a simple "loader-n-saver" that
indeed need to run on the target but that loader-n-saver does not need
to be a full-implementation (therefore small) and get to run in a
simulator.  That is cheap.  You would have done all the work on the
host and the tiny tricky on the simulated target.  You would have
produced the whole suite without having access to the target.  That is
cross-compilation.

| > And now, you complain I'm non-analytical and confrontational.
| > That IS disappointing.
|
| I said that because you have never answered any of my questions
| in this thread.

That simply is untrue.

| You have only been issuing "challenges".

No; I've just been amazed how negative you want this stuff to be:
"it is impossible to do, and you speak of doing it, then you must not
understand it, and if you do understand it, then it is not important".

Now, if that is constructrive, then I hereby apply for the rank of
"arm-chair contributor" :-)

[...]

| When Axiom is built using GCL, gcc becomes an integral part of
| Axiom. Axiom cannot run without it. gcc is called every time you
| define a function. So to run Axiom you must provide the gcc
| environment.

No, I do not need to provide GCC environment.  I just need to make
sure that the right GCC is called.  GCL does not provide GCC.  It just
assumes GCC exists.

| If you have the gcc environment, then GCL and Axiom
| can be built on the target environment. 2) What is the point of
| "jumping-through-hoops" to try to arrange that some part of the
| build can take place on a host environment separate from the
| target when in the end the target must have the same environment,
| must be sufficiently powerful to run Axiom and must in any case
| be involved in the creation of the resulting program?

but, you know that is not the case.  So, you want me to answer a
question that is at best a mischaracterization to begin with?

sigh.

\start
Date: Tue, 05 Sep 2006 13:35:58 -0500
From: Jay Belanger
To: list
Subject: re: Requiring LaTeX

Jay Belanger writes:

> Gabriel Dos Reis writes:
> ...
> > Basically, here is what I would like to see:
> >   On all non-linux platforms (and fedora platforms), check out a copy
> >   of the build-improvements.  configure and make it and send me (gdr
> >   at acm.org) the build log.  I'm particularly interested in issues
> >   related to X11.
>
> Okay.  I'll read up on the compile farm tonight and get the logs to
> you when I get the chance.

The compile farm is a really nice thing for sourceforge to offer, but
nonetheless seems to have problems.  I was unable to compile Axiom on
any of the compile farm machines.  The problem was either:
  * misconfigured subversion
  * no subversion installed
  * no latex installed
I'll try to install the missing software in the user directories and
try again to build Axiom on some of the machines, but alas that won't
happen before next week.

\start
Date: 05 Sep 2006 14:26:21 -0500
From: Gabriel Dos Reis
To: Jay Belanger
Subject: re: Requiring LaTeX

Jay Belanger writes:

| Jay Belanger writes:
| 
| > Gabriel Dos Reis writes:
| > ...
| > > Basically, here is what I would like to see:
| > >   On all non-linux platforms (and fedora platforms), check out a copy
| > >   of the build-improvements.  configure and make it and send me (gdr
| > >   at acm.org) the build log.  I'm particularly interested in issues
| > >   related to X11.
| >
| > Okay.  I'll read up on the compile farm tonight and get the logs to
| > you when I get the chance.
| 
| The compile farm is a really nice thing for sourceforge to offer, but
| nonetheless seems to have problems.  I was unable to compile Axiom on
| any of the compile farm machines.  The problem was either:
|   * misconfigured subversion
|   * no subversion installed
|   * no latex installed

Many thanks for the report.  It is helpful for the community here, if
anything, as data point of aspects of the world outside.

| I'll try to install the missing software in the user directories and
| try again to build Axiom on some of the machines, but alas that won't
| happen before next week.

Again, thanks for the time you invested in this.

\start
Date: Tue, 5 Sep 2006 19:44:14 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: cross-compiling Axiom

On Tuesday, September 05, 2006 12:31 PM Gabriel Dos Reis
>
> | 1) Why should we want Axiom to be cross-compiled?
>
> Because I believe that making Axiom more accessible is a very
> important issue for Axiom.  You believe that people can just go
> apt-get and voil=E0.

Apparently apt-get works on at least 2 of the 10 major distributions.
And the rpms created via alien from the Debian binaries seem work
on at least Fedora and SuSe but of course you have to satisfy any
dependencies manually.

> I highly suspect your view is right for a very restricted
> class of people.
>

Debian and Ubuntu seem to be pretty widely used to me. They are both
listed here with the "top 10":

http://distrowatch.com/dwres.php?resource=major

There does not seem to be any easy way to get statistics on the
actual number of installed Linux systems. But I think we have
received reports of successful installation of Axiom on all of
these "major" systems.

During August (which was a pretty typical month) the Linux binaries
for Axiom were downloaded 120 times while the Windows binaries for
Axom where downloaded 521 times (not counting BitTorrent downloads).

> One way of making Axiom accessible is by "convincing" popular
> Linux distros to bundle it with their packages.

1) For how many people would that make Axiom significantly more
   accessible than it is already? Ok, having it on your "extras"
   CD might be convenient but does that really make such a
   difference?

2) Since Maxima is not currently included any "popular Linux
   distros" and it has been in line much longer than Axiom, what
   chance does Axiom have of being included? As far as I know no
   computer algebra package is included in any "major" Linux
   distribution except Debian.

I really doubt that "accessibility" of Axiom is a problem. We
have Axiom on Knoppix and other Knoppix-based LiveCD's, we have
Axiom on the DoyenCD (Fedora 3), and even have Axiom directly
accessible over the web.

I think simply including the DoyenCD with the Axiom Tutorial
book (which is already available to university book stores
through standard channels like Amazon) would have a bigger
impact than anything we do through the Linux distributions.

>
> | I think there are many more important issues to address.
>
> that is your belief.
>
> I however agree there are other important issues to address.
> At the moment, I don't believe they are more important than
> "getting Axiom to the masses".

I am all for exposing Axiom to a larger number of people, but
adding Axiom to the 10,000 other packages that are included in
the typical Linux distribution doesn't seem like such a great
strategy to me.

3) Do you think Mathematica and Maple have been successful at
   getting their products "to the masses"?

4) Is that the kind of goal that you would like to set for Axiom?

>From my point of view, even though both companies spend quite a
lot on advertising in the academic and scientific communities, they
still seem to have serious problems achieving wider acceptance of
computer algebra as "tool for the masses". It seems to me the
reasons are much deeper than just accessibility.

Yes, that is just my belief but I will try to cite some statistics
to make it seem more plausible. On http://popcon.debian.org Axiom
is currently ranked 9964 out of 23688 while Maxima is at 3694.
The popularity graphs show that the number of Axiom installations
appears to be still rising (although not quickly) while Maxima
installations have (more or less) leveled off. Both Axiom and
Maxima are equally accessible to Debian users. So accessibility
does not seem to be a factor in the observed difference.

Of course since participation on Debian popcon is optional,
it is easy to dispute the actual meaning of these numbers.

>
> [...]
>
> | I have explained and so had David Mentre and a few other people
> | on this list.
>
> David's message (from April) got an answer from Benjamin.

About cross-compilation David Mentre wrote:

> ...
> That might be an issue, as Lisp images are generated by executing
> the lisp machine, and machine specific C and object files are
> generated at that time. Maybe Camm could comment on this point,
> as GCL guru. ;-)
>
> However, Axiom can be compiled on various architecture (tested
> archs are alpha amd64 arm hppa i386 ia64 mips mipsel powerpc
> s390 sparc).
> ...

5) Is this the "answer form Benjamin" to which you refer?

http://lists.nongnu.org/archive/html/axiom-developer/2006-04/msg00323.htm=
l

> From: 	Benjamin Kosnik
> Subject: 	Re: [Axiom-mail] Axiom and linux distros
> Date: 	Thu, 20 Apr 2006 11:54:10 -0500
>
> > Could you detail this point? By "cross-compilation", do you really
> > mean like compiling on architecture i386 for arch ppc64? Why?
>
> often times ppc64 hardware is unavailable, or slow.
>
> This is a pretty common requirement.

-----

I don't count that as any sort of credible "answer".

6) In what sense could this be called a "common requirement"? Which
   Linux distributions requre that all packages be cross-compilable?
   What other packages like Axiom are cross-compilable?

> How many other people on this list?  Please be specific.
>

I think I should let them speak for themselves, if they wish.

> ...
> No; I've just been amazed how negative you want this stuff to be:
> "it is impossible to do, and you speak of doing it, then you must
> not understand it, and if you do understand it, then it is not
> important".

That is certainly not a direct quote from me. But I do think that
anyone who suggests that cross-compilation of Axiom is desirable
must have some basic misunderstanding of how Axiom is built on
Lisp or (maybe) are using the term "cross-compilation" in some
non-standard way. And I do believe there are better ways of spending
time on Axiom then trying to satisfy artificial requirements that
have such dubious benefits.

>
> Now, if that is constructive, then I hereby apply for the rank
> of "arm-chair contributor" :-)

I am afraid you no longer qualify. But I still have some hope that
continuing this discussion might help to convince you not to spend
much time on what seems to me is obviously a "fool's errand".

Of course this is just my "arm chair" opinion. I am sorry if the
expression of my opinion annoys you or seems to waste your time.
But this is an open source project, so I am sure that you will
continue with your contributions to Axiom or not, as you see fit.

>
> [...]
>
> | When Axiom is built using GCL, GCC becomes an integral part of
> | Axiom. Axiom cannot run without it. GCC is called every time you
> | define a function. So to run Axiom you must provide the GCC
> | environment.
>
> No, I do not need to provide GCC environment.  I just need to make
> sure that the right GCC is called. GCL does not provide GCC.  It
> just assumes GCC exists.

What you wrote above sounds self-contradictory.

Axiom uses GCL to compile functions and SPAD code. Or more precisely:
since Axiom is a Lisp application, Axiom *includes* GCL as an integral
part of the program. Axiom/GCL compiles function definitions and SPAD
code to C. GCL does require a GCC environment to compile the generated
C code to object code and to link the object code into the Axiom image.

For example on Windows, the necessary parts of the GCC environment
(including the GCC compiler) must be copied from MSYS/MinGW and these
are included in the self-install binary distribution file for Windows.

>
> | If you have the GCC environment, then GCL and Axiom
> | can be built on the target environment. 2) What is the point of
> | "jumping-through-hoops" to try to arrange that some part of the
> | build can take place on a host environment separate from the
> | target when in the end the target must have the same environment,
> | must be sufficiently powerful to run Axiom and must in any case
> | be involved in the creation of the resulting program?
>
> but, you know that is not the case.  So, you want me to answer a
> question that is at best a mischaracterization to begin with?
>

No.

I did not intend to ask a question containing a mischaracterization.
I believe that the presumptions of the question are accurate.

7) Why do you say: "you know that is not the case"? What part of
   what I wrote above do you think is not true?

\start
Date: Tue, 5 Sep 2006 19:59:20 -0400
From: Bill Page
To: Tom Boothby
Subject: RE: NotebookWiki

On Tuesday, September 05, 2006 5:18 PM you wrote:
>
> Recently, we've been discussing adapting the notebook to be
> used by Axiom and other languages.  I commented that I've
> been contemplating a fusion of the SAGE notebook, and the
> wiki idiom.  I thought I'd have gotten around to this sooner,
> but I've finally posted my ideas to the SAGE wiki.  This is
> by no means complete, but I want to get other people into the
> discussion early on.
>
> http://sage.math.washington.edu:9001/NotebookWiki
>

I am very interested in this subject. As you might know, we
do already have some support for SAGE on the Axiom wiki
website:

http://wiki.axiom-developer.org/SandBoxSage

This not based on the SAGE notebook concept, but rather on sage
/examples/latex_embed methods created by Gonzalo Tornaria and
Joe Wetherell et al.

Adapting the Sage notebook to be used by Axiom sounds very
interesting. Of course I am also interested in providing a more
general interface to Axiom from Sage in the same manner as the
existing Maxima interface.

Because of firewall restrictions I have problems accessing non-
standard HTTP ports like 9001 from my usual place of work. Is
there anyway you can make the NotebookWiki page accessible
through port 80 or 443? Or would you mind if I proxied your
site via the Apache web server at axiom-developer.org?

\start
Date: Tue, 5 Sep 2006 14:18:00 -0700 (PDT)
From: Tom Boothby
To: Bill Page
Subject: NotebookWiki

Recently, we've been discussing adapting the notebook to be used by Axiom and other languages.  I commented that I've been contemplating a fusion of the SAGE notebook, and the wiki idiom.  I thought I'd have gotten around to this sooner, but I've finally posted my ideas to the SAGE wiki.  This is by no means complete, but I want to get other people into the discussion early on.

http://sage.math.washington.edu:9001/NotebookWiki

\start
Date: Tue, 5 Sep 2006 19:13:47 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: re: cross-compiling Axiom

On Tue, 5 Sep 2006, Page, Bill wrote:

| I really doubt that "accessibility" of Axiom is a problem.

Fine.

I'll stopt it there; thanks for your time.

\start
Date: Tue, 05 Sep 2006 17:16:35 -0700
From: William Stein
To: Bill Page, Tom Boothby
Subject: Re: [SAGEdev] NotebookWiki

On Tue, 05 Sep 2006 16:59:20 -0700, Page, Bill Bill Page  
wrote:
> Adapting the Sage notebook to be used by Axiom sounds very
> interesting. Of course I am also interested in providing a more
> general interface to Axiom from Sage in the same manner as the
> existing Maxima interface.

I've started working on this some.  I got distracted by a bunch of travel  
though,
which just came to an end.  Probably what will happen is that I'll make a  
first
version that works, but for which some standard things in Axiom are hard  
to do,
or some things are too slow, and we'll work to make the interface more  
usable.

> Because of firewall restrictions I have problems accessing non-
> standard HTTP ports like 9001 from my usual place of work. Is
> there anyway you can make the NotebookWiki page accessible
> through port 80 or 443?

I haven't only because of laziness.   If you could give me instructions
how to do this (sage.math is an ubuntu linux box running apache2), I
could do it.

> Or would you mind if I proxied your
> site via the Apache web server at axiom-developer.org?

Please do and let me know the address.

\start
Date: Tue, 5 Sep 2006 17:18:51 -0700
From: Bob McElrath
To: Tom Boothby
Subject: Re: NotebookWiki

Tom Boothby [Tom Boothby] wrote:
> Recently, we've been discussing adapting the notebook to be used by Axiom 
> and other languages.  I commented that I've been contemplating a fusion of 
> the SAGE notebook, and the wiki idiom.  I thought I'd have gotten around to 
> this sooner, but I've finally posted my ideas to the SAGE wiki.  This is by 
> no means complete, but I want to get other people into the discussion early 
> on.
> 
> http://sage.math.washington.edu:9001/NotebookWiki

Have you seen my axiom/tiddlywiki demo?
    http://bob.mcelrath.org/moz-axiom.tar.gz

I have gotten more heavily involved in the TiddlyWiki project, which is
a CLIENT-side wiki, and as such I think it is much more appropriate as a
basis of personal mathematical computation.  In the above example each
wiki node is a logical unit of computation that can be mixed & matched.
I think this idiom may be quite powerful and we should continue to try
ideas along these lines.

Whether or not you like tiddlywiki, I think the web browser as an
interface is extremely powerful, due to firefox's knowledge of MathML,
and straightforward UI interaction that can be done with css,
javascript, and AJAX.  This nicely abstracts the interface from the
axiom server.

What ever happened with embedding a web server in axiom a la axiomui?
If someone can point me to a build of axiom which contains a web server,
I can whip up the equivalent to the above using a newer axiom and
TiddlyWiki version, where the interface would use AJAX to communicate
with the axiom server.  This would all be local, no web hosting needed.
(I'd very much like to do this...but have been unable to find the
axiomui code, and just building it would cost me a week of pain...)

I've tried various ideas using netcat, and similar tools to pipe command
line interfaces over HTTP, but to no success (so far).  But, perhaps it
can still be done...

\start
Date: Tue, 5 Sep 2006 21:19:03 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: NotebookWiki
Cc: Tom Boothby

On Tuesday, September 05, 2006 8:19 PM Bob McElrath wrote:
>
> Have you seen my axiom/tiddlywiki demo?
>     http://bob.mcelrath.org/moz-axiom.tar.gz
> ...

Yes. I agree that the client-side wiki concept has a great deal of
merit.

>
> Whether or not you like tiddlywiki, I think the web browser as
> an interface is extremely powerful, due to firefox's knowledge
> of MathML, and straightforward UI interaction that can be done
> with css, javascript, and AJAX.  This nicely abstracts the
> interface from the axiom server.

The Sage NoteBook of course uses these methods and communicates
with Sage running a web server embedded in Python. I expect that
what Tom is suggesting would require a similar interface to Axiom.

>
> What ever happened with embedding a web server in axiom a la
> axiomui?

AxiomUI

http://wiki.axiom-developer.org/AxiomUI

uses a separate webserver called 'araneida' written in common lisp
that runs in as a process separate from Axiom and communicates
with Axiom via two-way-stream: See:

http://wiki.axiom-developer.org/axiom--GUI--1/src/web-gui/AxiomHubLisp

With a little help from those-more-knowledgeable-in-Lisp-than-I,
It should be possible to resurrect at least this part of AxiomUI.

> If someone can point me to a build of axiom which contains a
> web server, I can whip up the equivalent to the above using a
> newer axiom and TiddlyWiki version, where the interface would
> use AJAX to communicate with the axiom server.  This would all
> be local, no web hosting needed. (I'd very much like to do this...
> but have been unable to find the axiomui code, and just building
> it would cost me a week of pain...)

I am very encouraged that you are motivated to continue this
work. For the AxiomUI source code see the links above, but if
you haven't used Lisp before, you might be right about the
"week of pain". :-) I hope we can attract some Lisp helpers...

Camm Maguire also provided some very simple web server code in
Lisp that can be run from inside Axiom:

http://lists.gnu.org/archive/html/axiom-developer/2005-04/msg00141.html

Kai Kaminski did not use this approach for AxiomUI because it
required a version 2.6.7 of GCL that was not yet in common use
in Axiom.

http://lists.nongnu.org/archive/html/axiom-developer/2005-06/msg00201.ht
ml

Plus he may have had some concerns about the desire to make sure
that calls to Axiom could be made "non-blocking", e.g. in the case
that Axiom goes into a loop or extremely long calculation. But if
you would like to attempt something this way, I would be glad to
help you get started. I did go so far as to verify that this
mini-webserver in Lisp does work. To complete the interface to
Axiom, we also need to be able to issue Axiom commands from Lisp
and to return Axiom output as a string to be parsed in a manner
similar to what is done in AxiomHubLisp above. Tim Daly provided
some key code in Axiom/Lisp for doing this about the same time as
the start of the AxiomUI project. I think this is in the axiom-
developer email list archives. If you want, I can take a look for
it.

>
> I've tried various ideas using netcat, and similar tools to
> pipe command line interfaces over HTTP, but to no success
> (so far).  But, perhaps it can still be done...
>

I definitely would not want to go that route.

\start
Date: Tue, 05 Sep 2006 19:11:55 -0700
From: William Stein
To: Bill Page
Subject: Hopefully stupid question


This may be a very stupid question.  Does Axiom support OS X (Intel)
in any way, either building from source or from pre-compiled binaries?
Or is Axiom Windows and Linux only?  For at least the next few weeks,
I'm using OS X full time for working on SAGE, and the first step
toward writing an Axiom interface is to install Axiom.  However, when
I search the Axiom web site and the download links, I can't find
anything about using it with OS X.  Morever, the tarball (the "gold"
version from Sept 05) says it doesn't know anything about Darwin:

   "Finished extraction
   Darwin
   Your system name is Darwin
   We do not know how to build for this kind of system
   Send a note to list about it"

Should I get a certain recent cvs snapshot?

Note -- if Axiom is Linux only this isn't a show stopper, since I can just
write the interface under Linux.  I just want to know.

\start
Date: Tue, 5 Sep 2006 22:12:43 -0400
From: Bill Page
To: William Stein
Subject: RE: [SAGEdev] NotebookWiki
Cc: Tom Boothby

On Tuesday, September 05, 2006 8:17 PM William Stein wrote:
> On Tue, 05 Sep 2006 16:59:20 -0700, Bill Page wrote:
> > Adapting the Sage notebook to be used by Axiom sounds very
> > interesting. Of course I am also interested in providing a more
> > general interface to Axiom from Sage in the same manner as the
> > existing Maxima interface.
>
> I've started working on this some.  I got distracted by a
> bunch of travel though, which just came to an end.  Probably
> what will happen is that I'll make a first version that works,
> but for which some standard things in Axiom are hard to do,
> or some things are too slow, and we'll work to make the
> interface more usable.

Great. I took a look at the Maxima interface, but it was a bit
overwelming as a place start for me as a novice Sage developer
(although I must admit I learnt somethings about using Pexpect
that I am already planning to duplicate on Axiom Wiki :). If you
can give me even a basic shell that calls Axiom with some command
and returns a result to Sage, plus some hints as to how to install
and test it in my Sage installation, then I would be glad to try
to help.

>
> > Because of firewall restrictions I have problems accessing non-
> > standard HTTP ports like 9001 from my usual place of work. Is
> > there anyway you can make the NotebookWiki page accessible
> > through port 80 or 443?
>
> I haven't only because of laziness. If you could give me
> instructions how to do this (sage.math is an ubuntu linux
> box running apache2), I could do it.

You will need to add something like the following to your Apache
configuration file:

LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
...
<VirtualHost 209.135.140.38>
  ServerName   sage-notebook.axiom-developer.org
  ErrorLog     /home/page/sage-logs/error_log
  CustomLog    /home/page/sage-logs/access_log common
  ProxyPass    / http://sage.math.washington.edu:8100/
  ProxyPassReverse / http://sage.math.washington.edu:8100/
</VirtualHost>

<VirtualHost 209.135.140.38>
  ServerName   sage-wiki.axiom-developer.org
  ErrorLog     /home/page/sage-logs/error_log
  CustomLog    /home/page/sage-logs/access_log common
  ProxyPass    / http://sage.math.washington.edu:9001/
  ProxyPassReverse / http://sage.math.washington.edu:9001/
</VirtualHost>

These are the actual configuration options used on the
axiom-developer server. Of course you must change the ip
address and directories as appropriate for your system.

If you get stuck or if this is very unclear, let me know and
I can give you more explicit instructions.

>
> > Or would you mind if I proxied your
> > site via the Apache web server at axiom-developer.org?
>
> Please do and let me know the address.
>

Here is the axiom-developer proxy address for your wiki:

http://sage-wiki.axiom-developer.org

Here also is an axiom-developer proxy for the prototype
NotebookWiki at http://sage.math.washington.edu:8100

http://sage-notebook.axiom-developer.org

Both of these work fine through my firewall.

\start
Date: Tue, 5 Sep 2006 22:13:59 -0400
From: Tim Daly
To: William Stein
Subject: Re: Hopefully stupid question

The problem is that I've been unable to get the port to work.
I've narrowed it down to the fact that I probably installed Fink wrong.
I'm not a MAC user by trade so it's hard for me. There is no fundamental
reason why it won't work it's just that the MAC environment is so foreign
to me that I keep getting tripped up.

\start
Date: Tue, 05 Sep 2006 19:44:32 -0700
From: William Stein
To: Tim Daly
Subject: Re: Hopefully stupid question

On Tue, 05 Sep 2006 19:13:59 -0700, Tim Daly wrote:

> The problem is that I've been unable to get the port to work.
> I've narrowed it down to the fact that I probably installed Fink wrong.
> I'm not a MAC user by trade so it's hard for me. There is no fundamental
> reason why it won't work it's just that the MAC environment is so foreign
> to me that I keep getting tripped up.

I am the same.  Getting SAGE to build on OS X was much harder for me than
even getting it to build on Cygwin.   I'm forcing myself to learn OS X
right now (by using it), partly since so many potential end users are
using it these days.   By the way, Justin Walker (Justin Walker) is often
extremely helpful and sorting out compilation issues on OS X.

Why do you need fink for building axiom?  Probably you just need the latest
Xcode install (it's a very good idea to get the latest version, since there
were very annoying bugs in earlier versions).

\start
Date: Tue, 5 Sep 2006 22:42:09 -0400
From: Tim Daly
To: William Stein
Subject: Re: Hopefully stupid question

first i've heard of Xcode, got a URL? --t

\start
Date: 05 Sep 2006 23:50:39 -0400
From: Camm Maguire
To: Bill Page
Subject: re: cross-compiling Axiom
Cc: Gabriel Dos Reis

Greetings!

Bill Page writes:

> On September 3, 2006 8:02 PM Tim Daly wrote:
> > 
> > Axiom was ported to the Zaurus handheld using cross-compilation.
> > Camm does it in the Debian setup.
> 
> No, I don't think that is true. At least I know it isn't true
> for the version of Axiom that I run on my Zaurus. Axiom is built
> on Debian like all other packages that I know of on Debian - on
> a machine that is hardware-compatible with the target.
> 
> http://db.debian.org/machines.cgi
> 
> I think the binary that I use on my Zaurus was compiled on Debian
> running on such an Arm host. (Camm can confirm.)
> 

This is correct.

> http://www.debian.org/ports/arm
> 
> These machines have the same type of processor as the Zaurus
> (although of course these are probably not handheld devices :)
> having faster processors, more memory and faster mass storage.
> 
> In order to run Axiom, I must also configure my Zaurus to run
> a similar Debian distribution. On my Zaurus the arm Debian
> distribution runs in a chroot.
> 
> > 
> > There are two methods generally used, CROSS-COMPILATION and
> > CROSS-MOUNTING. 
> >
> 
> I have never heard of "cross-mounting" used in this context.
>  
> > 
> > CROSS-COMPILATION involves two systems, B -- the build system
> > and T -- the target system. You compile on B but tell GCC that
> > the target is T. 
> > 
> > GCC is designed in layers. The source code eventually gets
> > compiled to RTL (Register Transfer Language) which is a target
> > independent lisp-like assembler language. Since this is system-
> > independent you can use the RTL anywhere.
> > 
> > The final stage of GCC compiles RTL to the target platform. GCC
> > currently targets about 20 platforms.  This is useful for targets
> > like the Zaurus (an ARM (i386-ish) processor) that do not have
> > the horsepower to be a compile platform. It is also useful for
> > embedded systems.
> >
> 
> In fact I have built Axiom from source on my Zaurus, but I do not
> recommend it. Since there is not enough main memory you must
> configure a swap disk and swapping to SD ram is *slow*. It took
> about two days to complete.
> 
> Perhaps it is possible to cross-compile programs written in C to
> arm using gcc. For example, here is an ambitious project of that
> type:
> 
> http://scratchbox.org/wiki/Crocodile
> 
> But I am quite sure that this is *not* how Camm compiles Axiom for
> Arm and the other Debian architectures.
> 

While I am certainly not the expert here, I do know that Debian in
particular has given considerable thought to portability.
Traditionally, it has supported synchronous releases on 11 different
architectures -- a truly massive feat, especially when considering the
size of the archive.

As time has progressed, the spread between the fastest and slowest
machines has widened, and this has sparked some dicussion on the
development mailing lists regarding a possible  two-tier
classification system for supported arches into 'main' and 'scc'
("second-class citizen").  Some such moves are inevitable I suppose at
some point, but I just want to emphasize how many bugs have been shaken
out of gcl supporting all these different machines, how much bloat had
to be remmoved to make it feasible, and how much remarkable support
has been offered from the respective supporters of the particular
architectures.  The m68k crowd (aka former amiga users) is
particularly amazing.

In this discussion, some consideration was given to constructing
cross-compiling auto-builders.  While I did not follow it to the end,
the consensus appeared to be that the technology was not yet
sufficiently fool-proof.  You can dig this up on the debian-devel
archives if interested.

> > 
> > CROSS-MOUNTING is easier if the target system has the tools and
> > horsepower to host GCC. For instance, to build on a Sun system
> > it is easier to use NFS (Network File System). Here we talk about
> > S -- the source system and T -- the target system.
> > 
> > On S, which contains the source tree, you 'export' the filesystem
> > using NFS. This allows anyone to mount the filesystem remotely. On
> > T you NFS-mount the sources. They now appear to be on the target
> > system and you can just type 'make'
> 
> Tim, that sounds like nonsense. Anyone can mount source directories
> located on another machine running another operating system. You can
> use NFS, or Samba or whatever. This has nothing to do with cross-
> compilation.
> 
> > 
> > Axiom can use this system. First you build on S so that you have a 
> > full build tree (SRC, INT, OBJ, MNT). Notice that these are defined
> > as
> > 
> >   SRC -- Human created, read-only
> >   INT -- Machine-generated, Machine-independent
> >   OBJ -- Machine-generated, Machine-dependent
> >   MNT -- Final distribution tree
> > 
> > 
> > SRC contains the source tree. NFS export on B it so it can be 
> > mounted on T. INT contains a 'cache' of extracted code that is 
> > system-independent so it also can be NFS exported on B and
> > NFS-mounted on T. This saves having to redo a lot of work.
> > 
> > On B you export SRC & INT.
> > On T you NFS-mount SRC & INT.
> > On T you set the AXIOM variable to the local machine 
> >   (e.g. export AXIOM=`pwd`/mnt/sun)
> > On T you type 'make' and it builds a Sun version.
> > 
> > In parallel, other systems can also do NFS-mount and make.
> > The only change is the AXIOM variable (e.g. `pwd`/mnt/macox)
> >
> 
> Maybe this strategy was interesting once-upon-a-time but with
> the machines that we have available today I doubt that there is
> much advantage to this. It seems to me that all you might save
> is the BOOT-to-Lisp and SPAD-to-Lisp compile times. The only code
> in Axiom that is (approximately) machine independent is the lisp
> source code and the generated lisp code. To get anywhere else
> with that you still need a lisp interpreter/compiler on the target
> environment. And it seems to me that that is the hard part.
>  
> > 
> > The advantage of CROSS-COMPILATION is that you can build for
> > systems that don't support a build environment. The disadvantage
> > is that you need a cross-compiled environment (e.g. libraries
> > need to be cross compiled, .h files need to reflect the target,
> > etc.). Since Axiom needs the X11 libraries for a full build you
> > need to have X11 libraries that are cross-compiled for the target
> > (e.g. Zaurus)
> 
> The version of Zaurus that I have (which still runs the Sharp
> supplied embedded Linux) does not support X11 natively. That is
> one reason why you need the Debian arm port. There may be a
> version of OpenZaurus Linux that does have X11.
> 
> But I still do not understand how you can talk about cross-
> compilation and GCL. When GCL compiles some lisp source code
> it produces intermediate C code which, yes could in principle
> be compiled for another architecture, but then it immediately
> attempts to link the generated object code into the running
> GCL image. If you are attempting cross-compilation this is
> not possible because the running GCL image is not compatible
> with the object code produced by gcc.
> 
> What am I missing?
> 

Nothing AFAICT in the existing build framework.  I just want to
mention that GCL unlike some other lisp systems supports both an
interpreter and a compiler.  This is primarily to aid in developing
and debugging the compiler, but also provides some means for platform
independent work.  The whole Axiom system should load and run
interpreted if desired, and if one has a massive amount of time on
one's hands :-).  The same holds for the GCL lisp files -- check out
the saved_pre_gcl image.

One item of medium term interest in GCL development is a just-in-time
byte-code compiler/interpreter for faster platform-independent
(i.e. non-native code) execution.  Few have expressed an interest in
this thus far.

> > 
> > The advantage of CROSS-MOUNTING is that you are building on
> > the final target and can use all of the libraries, includes,
> > and tools. The disadvantage is that you can't do this if the
> > target does not have the horsepower.
> 
> As far as I can see, this is irrelevant to the issue of cross-
> compilation.
> 
> > 
> > Which method you use is determined by the resources of the
> > target.
> > 
> 
> If you build the binaries on the target this is not cross-
> compilation.
> 
> With regards to cross-compilation and Maxima see for example:
> 
> http://www.math.utexas.edu/pipermail/maxima/2003/003434.html
> 
> Camm writes:
> 
> > I believe you will run into some problems when cross-compiling.
> > You can compile all the objects just fine by pointing gcl at
> > your gcc cross compiler.  But part of gcl's build, and maxima's,
> > entails loading and executing these objects (i.e. initializing
> > the lisp core), so you would at least need a mips emulator, which
> > I doubt exists. Your best bet I'd think would be to setup your
> > pda to mount a larger filesystem via nfs from another box, with
> > a true mips development environment installed.  Compile there,
> > and your pda should be able to run the produced executable. 
> 
> http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2005-04/msg01510.htm
> l
> http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2005-04/msg01463.htm
> l
> 

I think one can reduce the problem down to cross-compiling C code
produced by gcl/axiom running interpreted.

\start
Date: Tue, 05 Sep 2006 21:47:47 -0700
From: William Stein
To: Justin Walker
Subject: Re: [SAGEdev] Hopefully stupid question

On Tue, 05 Sep 2006 20:41:57 -0700, Justin C. Walker Justin Walker  
wrote:
> If you have a Mac, it "comes with".  It is not installed by default,
> but you can install it from the CD/DVD that came with your system.

Yes, but that version will be out of date.  For example, the XCode
that came with my Macbook Pro DVD compiles PARI incorrectly (the unit
tests fail).  But the tests are fine with the latest version of XCode.

> Failing that, go to <http://developer.apple.com>, and sign up as an
> "on-line" developer (gratis).  Then you should be able to download
> Xcode corresponding to the version of the system you have (assuming
> it's a 10.4 system, get Xcode 2.4): it's in the Developer Tools area
> of the Downloads page.

Yes, I've done this and it worked well for me.  Note that the download
is nearly 1GB.

I just checked and the current version is indeed "XCode 2.4", and the
website says "The Xcode 2.4 release provides overall stability improvement
and adds support for 64-bit Intel based Mac computers. It is recommended
that all Xcode users install this update."

Note that I think you have to have OS X 10.4.x to install the new version
of XCode.

> One issue with Fink (or DarwinPorts, for that matter) is that the
> setup includes all dependencies, so the potential for duplication is
> significant.  The problem both projects are solving by doing this is
> to keep dependencies out of the mix, so it's hard to fault them; it's
> just that the disk space used can get large.

You might consider "turning off" fink when doing the Axiom port to
avoid confusion, e.g., move /sw to /sw.orig, at least assuming that
Axiom doesn't depend on packages you only get via fink.

\start
Date: Tue, 5 Sep 2006 20:41:57 -0700
From: Justin Walker
To: list
Subject: Re: [SAGEdev] Hopefully stupid question

On Sep 5, 2006, at 19:42 , root wrote:

> first i've heard of Xcode, got a URL? --t

If you have a Mac, it "comes with".  It is not installed by default,  
but you can install it from the CD/DVD that came with your system.

Failing that, go to <http://developer.apple.com>, and sign up as an  
"on-line" developer (gratis).  Then you should be able to download  
Xcode corresponding to the version of the system you have (assuming  
it's a 10.4 system, get Xcode 2.4): it's in the Developer Tools area  
of the Downloads page.

Of course, since you are already building, you must have it installed  
(the Xcode package has the compiler tool chain in it) :-}

One issue with Fink (or DarwinPorts, for that matter) is that the  
setup includes all dependencies, so the potential for duplication is  
significant.  The problem both projects are solving by doing this is  
to keep dependencies out of the mix, so it's hard to fault them; it's  
just that the disk space used can get large.

\start
Date: Tue, 5 Sep 2006 22:05:05 -0700
From: Justin Walker
To: list
Subject: Re: [SAGEdev] Hopefully stupid question

On Sep 5, 2006, at 21:47 , William Stein wrote:

> On Tue, 05 Sep 2006 20:41:57 -0700, Justin C. Walker  
> Justin Walker wrote:
>> If you have a Mac, it "comes with".  It is not installed by default,
>> but you can install it from the CD/DVD that came with your system.
>
> Yes, but that version will be out of date.

Thanks for bringing that up; I neglected to go into that detail :-}

Depending on what version of things you have (Mac OS X, Xcode),  
William is correct: you should upgrade to the latest compatible  
version of the developer tools (earlier versions are available for  
download on Apple's developer site).  It's a fact of life that for  
SAGE to work well, being up to date with the latest available  
compiler revs is generally required.

>> Failing that, go to <http://developer.apple.com>, and sign up as an
>> "on-line" developer (gratis).  Then you should be able to download
>> Xcode corresponding to the version of the system you have (assuming
>> it's a 10.4 system, get Xcode 2.4): it's in the Developer Tools area
>> of the Downloads page.
>
> Yes, I've done this and it worked well for me.  Note that the download
> is nearly 1GB.
>
> I just checked and the current version is indeed "XCode 2.4", and the
> website says "The Xcode 2.4 release provides overall stability  
> improvement
> and adds support for 64-bit Intel based Mac computers. It is  
> recommended
> that all Xcode users install this update."
>
> Note that I think you have to have OS X 10.4.x to install the new  
> version
> of XCode.

Yup; the developer site should provide guidance on compatibility  
issues; if there are questions, ask here.

> You might consider "turning off" fink when doing the Axiom port to
> avoid confusion, e.g., move /sw to /sw.orig, at least assuming that
> Axiom doesn't depend on packages you only get via fink.

Absolutely.  If you are developing something to put into SAGE, you  
*must* turn off both Fink ("/sw") and DarwinPorts (usually in "/opt/ 
local").  Since most users of SAGE will be missing at least one of  
these, the dependencies will cause SAGE to break on Mac OS X.

\start
Date: Wed, 6 Sep 2006 05:18:21 -0400
From: Tim Daly
To: Camm Maguire
Subject: re: cross-compiling Axiom
Cc: Gabriel Dos Reis

> Nothing AFAICT in the existing build framework.  I just want to
> mention that GCL unlike some other lisp systems supports both an
> interpreter and a compiler.  This is primarily to aid in developing
> and debugging the compiler, but also provides some means for platform
> independent work.  The whole Axiom system should load and run
> interpreted if desired, and if one has a massive amount of time on
> one's hands :-).  The same holds for the GCL lisp files -- check out
> the saved_pre_gcl image.

Axiom already does this. I use it for deep debugging.
The debugsys image is automatically created in the OBJ/SYS directory.

> One item of medium term interest in GCL development is a just-in-time
> byte-code compiler/interpreter for faster platform-independent
> (i.e. non-native code) execution.  Few have expressed an interest in
> this thus far.

CCL (part of the axiom pile) and CLISP both provide this ability.
Both are portable but slow relative to GCL which was chosen for speed.
There is also a byte-coded lisp that uses the Java VM. This is a solved
problem so I wouldn't spend too much time on it.

CLISP provides a portable ANSI platform and is the one I'm using to test
the ANSI port for Axiom. I'm unlikely to release Axiom on that platform
but will wait use a compiled lisp (hopefully GCL when it is ready).

Instead of a byte-code effort I'd much rather see the ability to 
portably construct a window in which I can draw colored lines from lisp.
Such an effort will make it possible for the graphics to be ported.
There is a lot of work going on in this area and I think it is important.

In general I'd take direction from the Java crowd about new functionality.
Java is interesting only because you can portably do networking, graphics,
database, etc. Lisp is missing the fundamental support hooks to build
these libraries.

\start
Date: Wed, 6 Sep 2006 05:24:26 -0400
From: Tim Daly
To: William Stein
Subject: Re: [SAGEdev] Hopefully stupid question
Cc: Justin Walker

So SAGE is using Xcode and not Fink? Thus it would help future
compatibility if I used Xcode?

\start
Date: 06 Sep 2006 06:22:18 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: cross-compiling Axiom
Cc: Camm Maguire

Tim Daly writes:

| > Nothing AFAICT in the existing build framework.  I just want to
| > mention that GCL unlike some other lisp systems supports both an
| > interpreter and a compiler.  This is primarily to aid in developing
| > and debugging the compiler, but also provides some means for platform
| > independent work.  The whole Axiom system should load and run
| > interpreted if desired, and if one has a massive amount of time on
| > one's hands :-).  The same holds for the GCL lisp files -- check out
| > the saved_pre_gcl image.
| 
| Axiom already does this. I use it for deep debugging.
| The debugsys image is automatically created in the OBJ/SYS directory.

Indeed.  While I was messing myself with src/interp, I stumbled over it
two days ago and I find it useful.

\start
Date: Wed, 6 Sep 2006 08:44:13 -0700
From: Justin Walker
To: Tim Daly
Subject: Re: [SAGEdev] Hopefully stupid question

On Sep 6, 2006, at 02:24 , root wrote:

> William,
>
> So SAGE is using Xcode and not Fink? Thus it would help future
> compatibility if I used Xcode?

There is a terminological speed-bump here: Fink (as is DarwinPorts)  
is a "community" project whose aim, roughly, is to make a lot of open- 
source software easily available on Mac OS X, in a way that minimizes  
the hassle for the user.  There have been long, heated, discussions  
on the pros and cons, but the essential point is that these are "add- 
ins" that many users may be unaware of, unwilling to install, or  
actively hostile to, Fink.

Xcode is two things: it's a package of tools for development on Mac  
OS X; and it's an IDE for working on programming/debugging/editing  
tasks.

What you really want are the tools: the compiler(s) and link/loader.   
These are packaged with Xcode, but aren't Xcode.

So: you need to have Xcode (the package) installed, but you don't  
need to "use Xcode".

I hope that is both clearer, and not too pedantic.

\start
Date: Wed, 06 Sep 2006 09:30:28 -0700
From: William Stein
To: Tim Daly
Subject: Re: [SAGEdev] Hopefully stupid question
Cc: Justin Walker

On Wed, 06 Sep 2006 02:24:26 -0700, Tim Daly wrote:

> William,
>
> So SAGE is using Xcode and not Fink? Thus it would help future
> compatibility if I used Xcode?

Correct.  Building all of SAGE from source has 0 dependency on Fink or  
Darwin Ports.
All it requires is a few of the compiler tools in XCode.

\start
Date: 06 Sep 2006 12:37:34 -0400
From: Camm Maguire
To: Tim Daly
Subject: re: cross-compiling Axiom
Cc: Gabriel Dos Reis

Greetings!

Tim Daly writes:

> > Nothing AFAICT in the existing build framework.  I just want to
> > mention that GCL unlike some other lisp systems supports both an
> > interpreter and a compiler.  This is primarily to aid in developing
> > and debugging the compiler, but also provides some means for platform
> > independent work.  The whole Axiom system should load and run
> > interpreted if desired, and if one has a massive amount of time on
> > one's hands :-).  The same holds for the GCL lisp files -- check out
> > the saved_pre_gcl image.
> 
> Axiom already does this. I use it for deep debugging.
> The debugsys image is automatically created in the OBJ/SYS directory.
> 
> > One item of medium term interest in GCL development is a just-in-time
> > byte-code compiler/interpreter for faster platform-independent
> > (i.e. non-native code) execution.  Few have expressed an interest in
> > this thus far.
> 
> CCL (part of the axiom pile) and CLISP both provide this ability.
> Both are portable but slow relative to GCL which was chosen for speed.
> There is also a byte-coded lisp that uses the Java VM. This is a solved
> problem so I wouldn't spend too much time on it.
> 

OK, but would be nice to have all in one place.

> CLISP provides a portable ANSI platform and is the one I'm using to test
> the ANSI port for Axiom. I'm unlikely to release Axiom on that platform
> but will wait use a compiled lisp (hopefully GCL when it is ready).
> 

2.7.0 is getting close.

> Instead of a byte-code effort I'd much rather see the ability to 
> portably construct a window in which I can draw colored lines from lisp.
> Such an effort will make it possible for the graphics to be ported.
> There is a lot of work going on in this area and I think it is important.
> 

Weren't we looking at gcltk last time?  I cleaned this up specifically
for this purpose.

If you can live with X emulation on Windows, etc., you should be able
to try xgcl now.  I.e. you should be able to remove --disable-xgcl
from the compile flags with current 2.6.8pre.  Just do (xgcl-demo) at
the prompt.

Likewise there was the browser/gcl http server idea.

Otherwise, I am at a loss as to what would constitute a good solution
here.  We could get an interface to wxwindows pretty easily, but what
will be definitive and stand the test of time?

> In general I'd take direction from the Java crowd about new functionality.
> Java is interesting only because you can portably do networking, graphics,
> database, etc. Lisp is missing the fundamental support hooks to build
> these libraries.
> 

Alas, that boat has already sailed.  I don't think it will ever be
possible to revise the ansi lisp standard to include graphics and
networking.  My own opinion is to bring lisp as close to C as possible
in regard to these missing items -- then we will be assured of some
longevity.  And I don't think we need to fret about the lack of
standardization here -- as long as we have one good open-source
compiler that will never go away and can be bent to our needs, that's
all we should ever want.  If I had to design all the C code I write to
work on gcc, icc, portland, .... my productivity would be destroyed --
gcc is good enough, and is not going away in my lifetime.  As far as
axiom goes, I'm far more interested in fixing math bugs and adding
math functionality, though clearly I haven't been contributing in this
area (yet).  I don't particularly care about SPAD vs. Aldor either --
as long as we have one language under our control that is open and
forever, I'm grateful.

Speaking of networking -- a Debian user just found a bug in our socket
code which has now been fixed in cvs, in case you want to update.

\start
Date: Wed, 6 Sep 2006 12:44:20 -0400
From: Bill Page
To: Justin Walker
Subject: Xcode and Fink (was:  Hopefully stupid question)

On Wednesday, September 06, 2006 11:44 AM Justin C. Walker wrote:
>
> On Sep 6, 2006, at 02:24 , Tim Daly wrote:
> >
> > So SAGE is using Xcode and not Fink? Thus it would help future
> > compatibility if I used Xcode?
>
> ...
> Xcode is two things: it's a package of tools for development on
> Mac OS X; and it's an IDE for working on programming/debugging/editing

> tasks.
> ...
> So: you need to have Xcode (the package) installed, but you don't 
> need to "use Xcode".
>
> I hope that is both clearer, and not too pedantic.
>

I think it's very clear, thank you.

So, how can I tell of Xcode is installed? In particular, how
can I tell of Xcode is installed on the OS X system in the
SourceForge compile farm? The server is accessed via ssh command
line. The compile farm docs

http://sourceforge.net/docs/compile_farm

seem to be a little out of date since the

* ppc-osx1: Apple Mac OS X 10.1 Server with Fink running on an Mac G4
* ppc-osx2: Apple Mac OS X 10.2 Server with Fink running on an Mac G4

are no longer available but there is a system named ppc-osx3 running
OS X 10.3.

If both Xcope and Fink are installed, since this is a shared server
with no root access can you recommend a procedure that will ensure
that I do not inherit any Fink dependencies?

\start
Date: Wed, 6 Sep 2006 10:11:49 -0700
From: Justin Walker
To: Bill Page
Subject: Re: [SAGEdev] Xcode and Fink (was: Hopefully stupid question)


On Sep 6, 2006, at 09:44 , Page, Bill wrote:

> On Wednesday, September 06, 2006 11:44 AM Justin C. Walker wrote:
>>
>> On Sep 6, 2006, at 02:24 , Tim Daly wrote:
>>>
>>> So SAGE is using Xcode and not Fink? Thus it would help future
>>> compatibility if I used Xcode?
>>
>> ...
>> Xcode is two things: it's a package of tools for development on
>> Mac OS X; and it's an IDE for working on programming/debugging/ 
>> editing
>
>> tasks.
>> ...
>> So: you need to have Xcode (the package) installed, but you don't
>> need to "use Xcode".
>>
>> I hope that is both clearer, and not too pedantic.
>>
>
> I think it's very clear, thank you.
>
> So, how can I tell of Xcode is installed? In particular, how
> can I tell of Xcode is installed on the OS X system in the
> SourceForge compile farm? The server is accessed via ssh command
> line. The compile farm docs

Xcode (the IDE and friends) is installed in "/Developer", so check  
for that directory.  However, as I said, Xcode is also the tool chain  
(gcc, dyld, ...), and those are what you want.  Especially when  
viewed from an ssh perspective, it should look, more or less, like  
any Unix system:
    gcc -v
will tell you what version of the compiler you have.

>
> http://sourceforge.net/docs/compile_farm
>
> seem to be a little out of date since the
>
> * ppc-osx1: Apple Mac OS X 10.1 Server with Fink running on an Mac G4
> * ppc-osx2: Apple Mac OS X 10.2 Server with Fink running on an Mac G4
>
> are no longer available but there is a system named ppc-osx3 running
> OS X 10.3.

You can the version of the OS with "sw_version" (command-line).

> If both Xcope and Fink are installed, since this is a shared server
> with no root access can you recommend a procedure that will ensure
> that I do not inherit any Fink dependencies?

The most straight-forward is to check your environment variables  
('env').  You don't want anything like "/sw/..." in any of them  
(e.g., PATH).

If the 10.3 system is not 10.3.9, then you may have some build  
problems with SAGE; ask here for help if things go sour.  I can try  
building things for you on my 10.4 systems if you want to verify that  
they work on a more recent system.

\start
Date: 06 Sep 2006 13:49:35 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Cannot Rename The File Erlib To NRLIB

Greetings!

Bill Page writes:

> Camm,
> 
> On Wednesday, August 30, 2006 1:03 PM I wrote:
> > ... 
> > Anyway it seems the following patch replacing (probe-file filearg)
> > with (directory (truename filearg)) should work (for Axiom's
> > purposes at least):
> > 
> > In src/interp/nlib.lisp.pamphlet:
> >
> > ----------
> > 
> >  ;; ($ERASE filearg) -> 0 if succeeds else 1
> >  (defun $erase (&rest filearg)
> >    (setq filearg (make-full-namestring filearg))
> > -  (if (probe-file filearg)
> > +  (if (directory (truename filearg))
> >  #+:CCL (delete-file filearg)
> >  #+:AKCL
> >        (if (library-file filearg)
> >            (delete-directory filearg)
> >            (delete-file filearg))
> >        1))
> > 
> > ----------
> > 
> > Any comments? Does anyone see how to do this a better way?
> 
> I have compiled and tested Axiom Silver build.improvements branch
> with the new version of gcl-2.6.8pre, the above change as well as
> the patch suggested by Camm:
> 
> > On Wednesday, August 23, 2006 2:27 PM
> > > ... 
> > > You need this in patches.lisp.pamphlet:
> > > 
> > > -        (setq $current-directory (truename 
> > > -          (user-homedir-pathname))) )
> > >
> > > goes to
> > > 
> > > +        (setq $current-directory (namestring (truename 
> > > +          (user-homedir-pathname)))))
> > >
> 
> As expected the problem with rename is solved by these changes.
> Also Axiom has been built with 50% more memory (196*256) then was
> possible with the previous version of gcl. This should eliminate
> the memory related errors we have been seeing on some pages on
> the Axiom Wiki. I have made this new version of Axiom the current
> version on MathAction so that we can test it more thoroughly.
> 
> However I remain a little uncertain if 'directory' is really the
> proper way to check for the existence of a file or directory in
> common lisp?
> 

I think you want (null (pathname-name (truename filearg)))
or
(and (directory filearg) (not (probe-file filearg)))

\start
Date: Wed, 6 Sep 2006 14:04:50 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Cannot Rename The File Erlib To NRLIB

On Wednesday, September 06, 2006 1:50 PM you wrote:
>
> Bill Page writes:
> ...
> > >
> > > In src/interp/nlib.lisp.pamphlet:
> > >
> > > ----------
> > >
> > >  ;; ($ERASE filearg) -> 0 if succeeds else 1
> > >  (defun $erase (&rest filearg)
> > >    (setq filearg (make-full-namestring filearg))
> > > -  (if (probe-file filearg)
> > > +  (if (directory (truename filearg))
> > >  #+:CCL (delete-file filearg)
> > >  #+:AKCL
> > >        (if (library-file filearg)
> > >            (delete-directory filearg)
> > >            (delete-file filearg))
> > >        1))
> > >
> > > ----------
> > >
> > ...
> > However I remain a little uncertain if 'directory' is really
> > the proper way to check for the existence of a file or
> > directory in common lisp?
> >
>
> 1) I think you want (null (pathname-name (truename filearg)))
>
> 2) or (and (directory filearg) (not (probe-file filearg)))
>

Sorry, I still feel a little "dense" about this. Could you take
a minute to translate these two expressions for me? I want

 (if (... filearg)
   )

to be true if filearg is either a file *or* a directory.

I suspect that 2) requires that it be a directory and not a file
since 'probe-file' is now interpreted as specifically as testing
for a *file*. So maybe that one is not right?

I am also worried about the "wild-card" properties of 'directory'
which is not something I really want.

But I don't know the semantics of 1) at all, and having
consulted the lisp docs as deeply as possible, I am still
not sure. What exactly does expression 1) do on GCL?

\start
Date: 06 Sep 2006 14:10:17 -0400
From: Camm Maguire
To: Vadim V. Zhytnikov
Subject: Re: [Maxima] Maxima 5.10.0 release candidate 3
Cc: Robert Dodier

Greetings!  Just checked out wxmaxima, and was wondering if an
interface to wxwindows from lisp would be useful/desirable.

Is there yet a consensus on the 'best' cross-platform graphics,
esp. wrt. gcltk/ltk?

Take care,

Vadim V. Zhytnikov writes:

> Robert Dodier writes:
> > I have tagged version-59399rc3 (Maxima 5.10.0 release candidate 3) in CVS.
> 
> > There are a few minor changes but the one of most interest
> > is that there is a new wxMaxima version which will be bundled
> > with the Windows installer. Vadim, can you create a
> > Windows installer for the new release candidate?
> > 
> 
> Done. maxima-5.9.3.99rc3.exe uploaded to SF.
> It includes wxMaxima 0.7.0 release.  As for gcl,
> first I tried to build with gcl 2.6.8pre (today CVS).
> Console Maxima is OK but to my surprise both xmaxima
> and wxMaxima just show blank skreen.  So I reverted
> to gcl 2.6.7.
> 
> One small question - not all files in share/lbfgs
> are packaged to rc3 tarball.  Intentionally?

\start
Date: Wed, 6 Sep 2006 14:19:35 -0700 (PDT)
From: Cliff Yapp
To: Camm Maguire, Tim Daly
Subject: Graphics and GCL
Cc: Gabriel Dos Reis

> Otherwise, I am at a loss as to what would constitute a good solution
> here.  We could get an interface to wxwindows pretty easily, but what
> will be definitive and stand the test of time?

Camm, just so we know, what would be involved with getting McCLIM
working on GCL?  Has this been tried in recent history?  I guess on a
related note, does asdf work in the ANSI image now?

\start
Date: 06 Sep 2006 18:14:19 -0400
From: Camm Maguire
To: Cliff Yapp
Subject: Re: Graphics and GCL
Cc: Gabriel Dos Reis

Cliff Yapp writes:

> --- Camm Maguire wrote:
> 
> > Otherwise, I am at a loss as to what would constitute a good solution
> > here.  We could get an interface to wxwindows pretty easily, but what
> > will be definitive and stand the test of time?
> 
> Camm, just so we know, what would be involved with getting McCLIM
> working on GCL?  Has this been tried in recent history?  I guess on a
> related note, does asdf work in the ANSI image now?
> 

asdf works at least basically in gclcvs (aka 2.7.0) right now, and
possibly can be made to work with 2.6.8 ansi, I just haven't tried.  I
also have no experience with McCLIM, but if everyone signs off on this
being the 'one true way', I'll make sure it works.

Take care,

> Cheers,
> CY
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 

\start
Date: Wed, 6 Sep 2006 18:26:58 -0400
From: Bill Page
To: David Harvey, Tom Boothby
Subject: RE: [SAGEdev] NotebookWiki

On September 06, 2006 8:54 AM David Harvey wrote:
> ...
> It would be utterly insane to have the SAGE code available
> to edit wiki-style.
> ...

I would like to comment on Tom Boothby's vision of how a wiki
with an interface to Sage might be beneficial to the develop
of Sage as a software project. The intention, as I understand
it, would be to maintain a version the actual source code and
documentation for Sage as "pages" on the wiki. Changes to the
contents of source code pages modified by open access over the
web would become part of a live collaborative online test
environment. Plus a channel would be provided whereby these
changes could be selectively incorporated into the official
Sage distribution.

The wiki pages would also contain live Sage calculations -
such as is possible in the current NoteBook interface - that
could be used to incorporate illustrations of features and
issues in the documentation in a dynamic manner.

In fact the Axiom project has made the entire source code of
Axiom available over the web in precisely this way for the last
year. And has operated a wiki able to display the results of
Axiom calculations for more than two years. See for example:

http://wiki.axiom-developer.org/axiom--test--1

Axiom source code is written in a "literate programming" style
based on noweb and LaTeX called "pamphlets" which enables
"chunks" of source code to be named, referenced in discussion
in the text, and assembled into executable programs. The Axiom
wiki is able to store the source of each pamphlet as an object
embedded in an editable wiki page and to render it in various
document formats (dvi, pdf, ps) as well as extract code chunks
on demand.

Discussion and illustrative calculations can be freely attached
to wiki pages containing pamphlet objects.

As the chief designer of the web site that is currently used to
support Axiom, Tom's suggestions seem very welcome to me. But the
fact is that these features of the Axiom wiki web site have not
been extensively used to Axiom developers and users and remain
essentially only an experimental aspect of the web site.

>
> On Sep 6, 2006, at 1:46 PM, Tom Boothby wrote:
>
> > I see wikipedia as a great success in open authoring.  Most 
> > mischievous edits are caught pretty quickly.  I don't think
> > that SAGE would be much different -- just to a smaller scale.
>

In my opinion, scale is an essential and critical difference
between the Axiom and Sage wiki web sites and wikipedia. Our
experience on the Axiom wiki suggests that the ratio of the
number of active contributors to the number of people to the
total number of visitors our site is as high as 1 in 10,000 -
even including "mischievous edits". We do have 2 or 3 people
who regularly contribute. The number of visits per month is
nearly 10,000 the number of edits.

I think the whole reason for wikipedia's success is still
quite uncertain. But if wikipedia hosts say 1 million visits
per month, then this same ratio is approximately preserved.



On Wednesday, September 06, 2006 4:07 PM David Harvey wrote:

> Yes, wikipedia is wonderful. But there's a big difference
> between prose and code.....  a large piece of code can be
> completely broken by the tiniest change. Code is much more
> unstable than plain text in this sense.

I strongly disagree with this view. I don't think one can
usefully define "broken" and "stable" in this way. I would
claim instead that the "stability" and/or robustness of both
code and documentation is largely determined by two factors:

1) how accessible and visible they are, and

2) the extent to which authors and editors (and programmers)
   take responsibility for and identify with the content

> I don't know how much time you guys have spent around wikipedia.
> I hung around there a lot last year, and I saw a lot of crazy
> people make a lot of crazy edits. On wikipedia, it makes not
> a shred of difference if someone changes all the Catalan numbers
> to Dogalan numbers (yes, that actually happened). But I would
> be really pissed off if someone decided that it would be cool
> to see how SAGE would work if i^2 was +1 instead of -1.
> ...

Certainly one thing that is remarkable about wikipedia is the
response of wikipedia and it's contributors to instances of
"mischievous edits" (or worse). The integrity of the encyclopedia
is apparently being aggressively and effectively defended by
people who do not expect anything other than a small amount of
recognition for their contributions. The sense of "ownership"
is evident in how most people describe wikipedia. One might
even be inclined to suspect that "mischievous edits", when not
allowed to overrun the really interesting and reliable content
actually contributes to this sense of ownership.

Wouldn't it be great if we were able to harness some of this
human energy for the improvement of computer algebra systems!

>
> >> If there's a level of protection as William described, i.e.
> >> changes need human review before getting sent to the master
> >> repository, then I have absolutely no objection, and I think
> >> it's a very interesting idea.
> >
> > There should definitely be a couple of layers of protection.  
> > Ultimately, my plan was to let the wiki essentially manage a
> > darcs  repository -- that was how I was planning to let a user
> > pull patches down from the wiki.  William could still manage
> > the official releases.
>

This would be easy to accomplish and has been discussed on the
axiom-developer list, but not yet implemented. The simple reason
is that it does not seem urgent since almost no one has come
forward wishing to contribute to Axiom in this way. (The sole
exception being online editing of the Axiom Tutorial book.)

> I've heard of something like this before, but in the other
> direction. I heard about someone trying to use svn as a backend
> to manage the data for a wiki. Can't remember where I saw this
> though... probably on one of the wikipedia tech mailing lists.

Yes, this has been done for example as an extension of the
Zope application layer on which the ZWiki engine using on the
Axiom website is based.

>
> I'm a bit puzzled by this though... "let the wiki essentially
> manage a darcs repository". Does this mean you would need a
> nice programmer's text editor in a web page? I haven't seen such
> a thing before.
>

Yes, this is provided on the Axiom wiki via an "external editor"
function. After appropriately configuring their browsers, users
can click on an edit icon to cause the browser to launch an
editor on the user's workstation (such as emacs or some other)
with the contents of the wiki page. When the user issues a
editor command to save, the page is automatically uploaded to
the wiki. See:

http://wiki.axiom-developer.org/ExternalEdit

In spite of the doubts that are raised in my mind by what I
consider to be only the limited success of the Axiom wiki
website when it comes to this approach over the last year, I
am still optimistic that with a sufficient number of motivated
people and with increasing experience of users with this type
of system, we might still be able to take advantage this
technology. I am glad that it is being considered and developed
for Sage.

\start
Date: Wed, 6 Sep 2006 19:20:23 -0400
From: Bill Page
To: David Harvey, Tom Boothby
Subject: RE: [SAGEdev] NotebookWiki

On Wednesday, September 06, 2006 6:27 PM I wrote:
> ...
> Certainly one thing that is remarkable about wikipedia is the
> response of wikipedia and it's contributors to instances of
> "mischievous edits" (or worse). The integrity of the encyclopedia
> is apparently being aggressively and effectively defended by
> people who do not expect anything other than a small amount of
> recognition for their contributions. The sense of "ownership"
> is evident in how most people describe wikipedia. One might
> even be inclined to suspect that "mischievous edits", when not
> allowed to overrun the really interesting and reliable content
> actually contributes to this sense of ownership.
>
> Wouldn't it be great if we were able to harness some of this
> human energy for the improvement of computer algebra systems!
> ...

This leads me to a perhaps radical but quite serious suggestion:

Here we are working on Moinmoin and ZWiki-based wiki web sites
for Sage and Axiom, but maybe we should really be spending some
time developing a MediaWiki interface for these systems ...
(MediaWiki is the software that is used to implement wikipedia.)
What I mean is, this sort of computer algebra system should be
available directly on wikipedia. I think for certain Sage (once
the Axiom interface for Sage is complete :) is a logical candidate
for such an extension of wikipedia given it's commitment to open
source software and the approach to integrating diverse packages
into a coherent user interface.

Wikipedia has a huge potential audience and a large contributor
base - even if we restrict our view to only the current mathematical
content. Although this might sound like a "bandwagon" kind of
strategy, I seriously think that we should consider approach
the wikipedia developers soon (that is assuming that no one has
already suggested this idea) rather than waiting for it to happen
is a less optimal way.

Of course there might be some reluctance given the computer
resource that might have to be dedicated to providing this
sort of user interface. Maybe at least initially we would need
to consider what "class" of wikipedia user/contributor would be
permitted access to the computational part of the system, i.e.
permitted to edit wiki pages contain such "live math".

I believe there are already systems such as this being
developed specifically to assist with mathematical education.
For example:

http://www.mathweb.org
http://www.mathsnet.net/mathview/index.html

I know there are more, both commercial and open source projects.
I'll have to look back through my notes.

\start
Date: Wed, 6 Sep 2006 16:44:37 -0700
From: Bob McElrath
To: Bill Page
Subject: re: [SAGEdev] NotebookWiki
Cc: Tom Boothby, David Harvey,

AAAAAHHHHH!!!!! NNNOOOOOOOO!!!!

Page, Bill [Bill Page] wrote:
> This leads me to a perhaps radical but quite serious suggestion:
> 
> Here we are working on Moinmoin and ZWiki-based wiki web sites
> for Sage and Axiom, but maybe we should really be spending some
> time developing a MediaWiki interface for these systems ...
> (MediaWiki is the software that is used to implement wikipedia.)
> What I mean is, this sort of computer algebra system should be
> available directly on wikipedia. I think for certain Sage (once
> the Axiom interface for Sage is complete :) is a logical candidate
> for such an extension of wikipedia given it's commitment to open
> source software and the approach to integrating diverse packages
> into a coherent user interface.

The reason I chose ZWiki initially is because MediaWiki (and many other
latex-in-wiki sytems) is very un-latex-like and very un-wiki like, and I
expected users who did not and would not learn STX or Wiki, but I wanted
to render their math in a reasonable way.  (i.e. as we often send each
other in email)

    http://meta.wikimedia.org/wiki/Help:Formula

The current LatexWiki meshes nicely with the pamphlet ideas and the
knowledge that scientists and mathemeticians have.  We all know we can
type $x^2$ and know what it means.  Learning to type <math>x^2</math> is
unexpected behavior, and throws one into learning HTML too.

This project already has too many languages.  We should be seeking to
reduce the set of languages.  Thereby we reduce the knowledge set needed
to contribute to Axiom.  Latex and pamphlets are two that are not going
away.  I think we should head for a pamphlet-based wiki instead.

\start
Date: Wed, 6 Sep 2006 21:09:35 -0400
From: Bill Page
To: Justin Walker
Subject: RE: [SAGEdev] Xcode and Fink (was: Hopefully stupid question)
Cc: waqar@opendarwin.org, Camm Maguire,	William Stein

On Wednesday, September 06, 2006 1:12 PM Justin C. Walker wrote:
> >> ...
> >> So: you need to have Xcode (the package) installed, but you
> >> don't need to "use Xcode" [the IDE].

What about DarwinPorts?

http://darwinports.opendarwin.org

Their advertisement sez:

"The DarwinPorts Project's main goal is to provide an easy
way to install various open-source software products on the
Darwin OS family (OpenDarwin, Mac OS X and Darwin)."

"Please note that in order to install and run DarwinPorts on
Mac OS X you must have Apple's Xcode installed, found at the
Apple Developer site or on your Mac OS X installation CDs/DVD."

"It's sort of like the FreeBSD ports collection ..."

Apparently GCL has already been ported:

http://darwinports.opendarwin.org/ports/?by=name&substr=gcl

"gcl 2.6.6
    GNU Common Lisp
    Maintained by: waqar@opendarwin.org
    Categories: lang
    Platforms: darwin
    Dependencies: gettext"

Since we already apparently have the ability to build Axiom on BSD
systems which (like Debian) starts with a pre-installed version of
GCL, perhaps this would be the straightest path to Axiom on OS X?

I wonder if the DarwinPorts GCL maintainer: 'waqar' would be willig
to give us some insight into the ease or difficulty of porting GCL
what might also apply to Axiom?

\start
Date: Wed, 6 Sep 2006 20:02:06 -0700 (PDT)
From: Cliff Yapp
To: Camm Maguire
Subject: Re: Graphics and GCL
Cc: Gabriel Dos Reis

> > Camm, just so we know, what would be involved with getting McCLIM
> > working on GCL?  Has this been tried in recent history?  I guess on
> > a related note, does asdf work in the ANSI image now?
> > 
> 
> asdf works at least basically in gclcvs (aka 2.7.0) right now, and
> possibly can be made to work with 2.6.8 ansi, I just haven't tried. 

Ah, great!  I'll take a stab at compiling cvs gcl.

> I also have no experience with McCLIM, but if everyone signs off on
> this being the 'one true way', I'll make sure it works.

I'm afraid that no such event is likely :-(.  

Ah, well - I'll have a go and see if it compiles, at least.

\start
Date: Thu, 7 Sep 2006 09:42:15 -0500
From: Waqar Malik
To: Bill Page
Subject: Re: [SAGEdev] Xcode and Fink (was: Hopefully stupid question)
Cc: Justin Walker, William Stein, Camm Maguire, Waqar Malik

I be glad to help with Axiom, but I have not used Axiom, so I have not
tried to compile it.

Couple of things to remember about gcl port, I have not updated to  
the latest release (2.6.7) and I have not compiled it on Intel  
machines yet, I will have to spend some time to verify that it works.

--Waqar
On Sep 6, 2006, at 8:09 PM, Page, Bill wrote:

>
> I wonder if the DarwinPorts GCL maintainer: 'waqar' would be willig
> to give us some insight into the ease or difficulty of porting GCL
> what might also apply to Axiom?

\start
Date: Thu, 7 Sep 2006 11:24:28 -0400
From: Bill Page
To: Waqar Malik
Subject: RE: [SAGEdev] Xcode and Fink (was: Hopefully stupid question)
Cc: Justin Walker, William Stein, Camm Maguire

On Thursday, September 07, 2006 10:42 AM Waqar Malik wrote:

> 	I be glad to help with Axiom, but I have not used
> Axiom, so I have not tried to compile it.

Thank you, thank you!

The main part of Axiom (the AXIOMsys computational "engine") is
built as a very large Lisp application on top of GCL plus a few
external subroutines written in C linked into the image.

The two other main parts of Axiom: Hyperdoc and Graphics, run
as separate processes, are written entirely in C and communicate
with AXIOMsys via sockets.

>
> Couple of things to remember about gcl port, I have not updated
> to the latest release (2.6.7) and I have not compiled it on
> Intel machines yet, I will have to spend some time to verify
> that it works.
>

It should be possible to build Axiom using the older version
of GCL.

Anything you can do to help us with this would be greatly
appreciated! If you haven't already, you might want to visit
the Axiom developer website at

http://wiki.axiom-developer.org

to find out more about Axiom. If you have any questions and/or
suggestions, please let me know.

Thanks again, and "Welcome aboard!" :-)

\start
Date: Thu, 07 Sep 2006 17:26:02 +0200
From: Kai Kaminski
To: list
Subject: Lisp GUI libraries and a UI for Axiom

Hi,

despite being busy and not reading the list regularly, I couldn't help
but notice the discussions about Lisp GUIs, especially the suggestions
to create Lisp FFI bindings to WxWidgets (formerly WxWindows, see
http://wxwidgets.org). I first present a short, non-exhaustive list of
Lisp GUI libraries that are free, portable and actively maintained. At
the end of this message there are a few thoughts on GUIs for Axiom.

- wxCL (http://www.wxcl-project.org/language/en/)

  Bindings for the WxWidgets library. Yes, they already
  exist. According to the developers they are in alpha state and
  should work on Mac OS X, Windows XP and Linux. They have only been
  tested on the former two, though.

  CFFI (http://cffi.common-lisp.net/project/cffi/) is used to abstract
  away the differences between different Lisp FFIs. CFFI is fully
  supported on almost all significant Lisps and OSs. See
  http://cffi.common-lisp.net/project/cffi/ for details.

- cells-gtk (http://cffi.common-lisp.net/project/cells-gtk/)

  Bindings for GTK using Kenny Tilton's Cells library
  (http://cffi.common-lisp.net/project/cells/), a portable CLOS
  dataflow extension, to ease GUI programming. Uses CFFI (see above).

- Celtk (http://www.tilton-technology.com/Celtk.html)

  Bindings for Tk using cells (see cells-gtk). OpenGL support.


- McClim (http://www.cliki.net/McCLIM)

  This library is still somewhat experimental and depends on X11 (even
  though there is an experimental Mac backend). Active developer
  community and interesting concepts, as well as a standard.

- lisp-cffi-qt4 (http://lisp-cffi-qt4.sourceforge.net/)

  Experimental CFFI bindings to QT4, the library that is used for KDE.


All the libraries mentioned above are in an early state. There are
rough edges and lots of missing functionality, but all of them look
promising. So far I've tried Cells-GTK (on OS X, doesn't run out of
the box) and McClim.

Now that I've presented a list of Lisp GUI libraries, let me argue
that it is irrelevant. 

I do not see any reason why a GUI for Axiom has to be written in
Lisp. Why not write a GUI for Axiom in Python or Java or C++? Why does
every GUI have to be portable? Why should there be only one GUI or
even a canonical GUI anyway?

Different people will want different GUIs. Tim Daly prefers a 'bare'
Emacs with all buffers in Fundamental Mode, whereas I love my Slime
and all the other bells and whistles. Martin Rubey wants to edit his
pamphlets using Emacs, other people can't stand Emacs. Some of the
latter sold their souls to the VI gods, others really want fancy
graphics and icons and toolbars. Finally some people prefer a portable
GUI, whereas others want really tight integration with their OS of
choice.

Trying to provide a single GUI making all these people happy is futile
at best, probably insane and certainly an awful lot of work.

The solution is to separate the GUI from the Axiom core and make GUI
programming easier. The former is pretty easy, just get rid of the GUI
code in $AXIOM/src. That would also get rid of most of the C code and
thereby improve portability of the core. Making GUI programming easier
is a lot more work.

For a GUI to be more useful than an Axiom terminal session, it needs
to be able to understand Axiom's output to some extent. It also needs the ability to
query Axiom for all kinds of information, eg

- list all existing variables/functions/types/commands/loaded libraries/etc
- list all functions/commands that are either of a given type or applicable to a given object
- where is the documentation for this library/function/command/etc?
- where is the source code for a given function?
- show me all functions/libraries that call/are called by function/library X
- in debugging mode: supply a stack trace

Create an API that supports this kind of functionality and future
versions of itself, and make it available over a socket using a simple
(in every programming language) clear-text protocol. Done. Sooner or
later someone will write a GUI then.

\start
Date: Thu, 7 Sep 2006 10:43:48 -0500
From: Waqar Malik
To: Bill Page
Subject: Re: [SAGEdev] Xcode and Fink (was: Hopefully stupid question)
Cc: Justin Walker, William Stein, Camm Maguire

Ok, I looked at the page, and to build it seems pretty simple, since  
it uses configure script., If you want to you can install MacPorts  
and install gcl and try to build axiom on the mac and see if it builds.
I will give it a try later today, as I have class that I need to  
attend this morning.

--Waqar
On Sep 7, 2006, at 10:24 AM, Page, Bill wrote:

> On Thursday, September 07, 2006 10:42 AM Waqar Malik wrote:
>
>> 	I be glad to help with Axiom, but I have not used
>> Axiom, so I have not tried to compile it.
>
> Thank you, thank you!
>
> The main part of Axiom (the AXIOMsys computational "engine") is
> built as a very large Lisp application on top of GCL plus a few
> external subroutines written in C linked into the image.
>
> The two other main parts of Axiom: Hyperdoc and Graphics, run
> as separate processes, are written entirely in C and communicate
> with AXIOMsys via sockets.
>
>>
>> Couple of things to remember about gcl port, I have not updated
>> to the latest release (2.6.7) and I have not compiled it on
>> Intel machines yet, I will have to spend some time to verify
>> that it works.
>>
>
> It should be possible to build Axiom using the older version
> of GCL.
>
> Anything you can do to help us with this would be greatly
> appreciated! If you haven't already, you might want to visit
> the Axiom developer website at
>
> http://wiki.axiom-developer.org
>
> to find out more about Axiom. If you have any questions and/or
> suggestions, please let me know.
>
> Thanks again, and "Welcome aboard!" :-)

\start
Date: Thu, 7 Sep 2006 11:45:48 -0400
From: Tim Daly
To: Kai Kaminski
Subject: Re: Lisp GUI libraries and a UI for Axiom

> I do not see any reason why a GUI for Axiom has to be written in
> Lisp. Why not write a GUI for Axiom in Python or Java or C++? Why does
> every GUI have to be portable? Why should there be only one GUI or
> even a canonical GUI anyway?

Perhaps I wasn't clear. I am not trying to create any kind of GUI.
I'm trying to make a portable front end for the graphics code.

My experience with many years of porting, which makes up probably
half of my career, is that C programs are probably the least portable.
This is especially true of C programs that draw lines.

Lisp programs are amazingly portable. It took all of 5 minutes to move
my work project (a 20k+ line lisp porgram) from Linux to Windows. 

I'm looking for a way to draw a colored line in a window on all of
the existing platforms from Lisp. Given this I can re-implement the
graphics portion of Axiom and make it run everywhere.

I need a lisp program that can open a window on Linux and Windows
and draw a colored line using common code. Surely this must be possible.

\start
Date: Thu, 7 Sep 2006 11:47:36 -0400
From: Tim Daly
To: Bill Page
Subject: Re: [SAGEdev] Xcode and Fink (was: Hopefully stupid question)
Cc: Justin Walker, Waqar Malik Camm Maguire, William Stein, Waqar Malik

> It should be possible to build Axiom using the older version
> of GCL.

All of the required patches are in zips.
Just set the GCLVERSION variable to match the GCL version,
put the gcl-version.tgz file in zips, set the AXIOM shell
variable, and type make.

\start
Date: Thu, 7 Sep 2006 11:58:31 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: Lisp GUI libraries and a UI for Axiom

Kai,

On Thursday, September 07, 2006 11:26 AM you wrote:
> ...
> Now that I've presented a list of Lisp GUI libraries, let me argue
> that it is irrelevant.
>
> I do not see any reason why a GUI for Axiom has to be written in
> Lisp. Why not write a GUI for Axiom in Python or Java or C++? Why
> does every GUI have to be portable? Why should there be only one
> GUI or even a canonical GUI anyway?

+1 Right on!

> ...
> The solution is to separate the GUI from the Axiom core and make
> GUI programming easier. The former is pretty easy, just get rid
> of the GUI code in $AXIOM/src. That would also get rid of most of
> the C code and thereby improve portability of the core. Making GUI
> programming easier is a lot more work.

Yes.

>
> For a GUI to be more useful than an Axiom terminal session, it needs
> to be able to understand Axiom's output to some extent. It also needs
> the ability to query Axiom for all kinds of information, ...
>
> Create an API that supports this kind of functionality and future
> versions of itself, and make it available over a socket using a
> simple (in every programming language) clear-text protocol. Done.
> Sooner or later someone will write a GUI then.
>

I believe that is an excellent suggestion.

This approach is already partially used in Maxima to abstract the
user interface from TeXmacs. I recently used an only slightly
modified version of the interface code written by James Amundson

http://wiki.axiom-developer.org/SandBoxMaxima#msg20060810023214-0500@wik
i.axiom-developer.org

in the new MathAction Wiki interface for Maxima. The TeXmacs
interface uses embedded control codes but I changed this to an
XML-style bracketing that was very easy to parse in Python.

For more Maxima examples see:

http://wiki.axiom-developer.org/SandBoxMaxima2

---------

Interfacing to Axiom actually presents a little more of a
challenge than Maxima because we also need to deal separately
with the type information. And as you suggested above, error
messages, state-of-the-computation information and graphical
data should also be handled through a consistent and well
documented clear text protocol.

The protocol and API also needs to be designed to work well with
asynchronous AJAX-style techniques for browser interaction.

The Sage developers have been discussing
Twisted http://twistedmatrix.com/trac/ and
Nevow http://divmod.org/trac/wiki/DivmodNevow as appropriate
related interface technologies.

I think that if we can graft these methods into the Lisp side
of AXIOMsys, then we would be in a very good position when
"Sooner or later someone writes the next GUI application".

\start
Date: Thu, 7 Sep 2006 09:17:25 -0700
From: Bob McElrath
To: Kai Kaminski
Subject: Re: Lisp GUI libraries and a UI for Axiom

As far as drawing graphs, why not just dump out a graph in any kind of
portable format (e.g. postscript, pdf, svg, etc).  A front-end can parse
it and display it.  There are many relevant lisp libraries:
    http://www.cliki.net/graphics%20library
    http://www.cliki.net/plotting

Kai Kaminski [Kai Kaminski] wrote:
> Now that I've presented a list of Lisp GUI libraries, let me argue
> that it is irrelevant. 
> 
> I do not see any reason why a GUI for Axiom has to be written in
> Lisp. Why not write a GUI for Axiom in Python or Java or C++? Why does
> every GUI have to be portable? Why should there be only one GUI or
> even a canonical GUI anyway?
> 
> Different people will want different GUIs. Tim Daly prefers a 'bare'
> Emacs with all buffers in Fundamental Mode, whereas I love my Slime
> and all the other bells and whistles. Martin Rubey wants to edit his
> pamphlets using Emacs, other people can't stand Emacs. Some of the
> latter sold their souls to the VI gods, others really want fancy
> graphics and icons and toolbars. Finally some people prefer a portable
> GUI, whereas others want really tight integration with their OS of
> choice.
> 
> Trying to provide a single GUI making all these people happy is futile
> at best, probably insane and certainly an awful lot of work.
> 
> The solution is to separate the GUI from the Axiom core and make GUI
> programming easier. The former is pretty easy, just get rid of the GUI
> code in $AXIOM/src. That would also get rid of most of the C code and
> thereby improve portability of the core. Making GUI programming easier
> is a lot more work.
> 
> For a GUI to be more useful than an Axiom terminal session, it needs
> to be able to understand Axiom's output to some extent. It also needs the ability to
> query Axiom for all kinds of information, eg
> 
> - list all existing variables/functions/types/commands/loaded libraries/etc
> - list all functions/commands that are either of a given type or applicable to a given object
> - where is the documentation for this library/function/command/etc?
> - where is the source code for a given function?
> - show me all functions/libraries that call/are called by function/library X
> - in debugging mode: supply a stack trace
> 
> Create an API that supports this kind of functionality and future
> versions of itself, and make it available over a socket using a simple
> (in every programming language) clear-text protocol. Done. Sooner or
> later someone will write a GUI then.

\start
Date: 07 Sep 2006 11:44:01 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Lisp GUI libraries and a UI for Axiom
Cc: Kai Kaminski

Tim Daly writes:

[...]

| half of my career, is that C programs are probably the least portable.

some C programmers say the same for Lisp...

[...]

| Lisp programs are amazingly portable. It took all of 5 minutes to move
| my work project (a 20k+ line lisp porgram) from Linux to Windows. 


There are viable, well-supported GUI out there.  QT is a good
option... (supported on windows, mac, unix/linux boxes).

\start
Date: Thu, 7 Sep 2006 12:53:02 -0400
From: Bill Page
To: Tim Daly
Subject: RE: Lisp GUI libraries and a UI for Axiom
Cc: Kai Kaminski

On Thursday, September 07, 2006 11:46 AM Tim Daly wrote:
> ...
> Lisp programs are amazingly portable. It took all of 5 minutes
> to move my work project (a 20k+ line lisp porgram) from Linux
> to Windows.
> ....

Hmmm. If you ever get a chance, maybe you could try this trick
with Kai Kaminski's AxiomUI code? :) It's written entirely in
Lisp (except for the Javascript part on the web browser), uses
some standard common lisp packages and runs on Clisp in Linux.
But on our first (and only) attempt neither Kai nor I were able
to get it to run on Windows.

\start
Date: Thu, 7 Sep 2006 13:25:34 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Lisp GUI libraries and a UI for Axiom

On Thursday, September 07, 2006 1:00 PM you asked:

> Can you tell me where I can checkout the source of Kai's
> AxiomUI (svn, darcs..).

See

darcs get http://page.axiom-developer.org/repository/axiom--GUI--1

and in the tla archive as 'axiom-GUI--1'. Everything except the
standard common lisp components are also available here as online
pamphlets:

http://wiki.axiom-developer.org/axiom--GUI--1

Here are a couple of related references from the axiom-developer
list at the time Kai completed this work:

http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00141.ht
ml
http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00064.ht
ml

\start
Date: Thu, 07 Sep 2006 20:42:46 +0200
From: Kai Kaminski
To: Tim Daly
Subject: Re: Lisp GUI libraries and a UI for Axiom

Tim Daly writes:

>> I do not see any reason why a GUI for Axiom has to be written in
>> Lisp. Why not write a GUI for Axiom in Python or Java or C++? Why does
>> every GUI have to be portable? Why should there be only one GUI or
>> even a canonical GUI anyway?
>
> Perhaps I wasn't clear. I am not trying to create any kind of GUI.
> I'm trying to make a portable front end for the graphics code.

...

> I'm looking for a way to draw a colored line in a window on all of
> the existing platforms from Lisp. Given this I can re-implement the
> graphics portion of Axiom and make it run everywhere.

You were clear, and what really triggered my post was the assumption
that there were no Lisp bindings for WxWidgets.

This comment begs the question though, why displaying graphics
shouldn't be the responsibility of the GUI. I believe that Axiom
should just tell the GUI 'look, your last command prompted me to
create a plot. Here is the list of points and here are the additional
options the user supplied (eg. line style, point style, colors
etc)'. Then the GUI should make sure that the plot somehow gets
displayed. A simple one might just pipe the whole load to gnuplot,
another one might have a fancy plot window.

If what you write above is really what you want, Tk should do the
trick. There are several Tk interfaces for Lisp, the most portable is
probably Ltk (http://www.peter-herth.de/ltk/). It also consists of
pretty much one file, so it's easy to LOAD and to handle.

I just tried to run it under GCL, but it didn't work. I'm not yet sure
why. The only non-portable part of it seems to be the function that
calls the WISH interpreter, which is part of Tk. Changing that should
be easy enough, but GCL chokes on some conditions-related stuff. I'll
take a closer look.

\start
Date: Thu, 07 Sep 2006 20:43:05 +0200
From: Kai Kaminski
To: list
Subject: Re: Lisp GUI libraries and a UI for Axiom

Kai Kaminski writes:

> The solution is to separate the GUI from the Axiom core and make GUI
> programming easier. The former is pretty easy, just get rid of the GUI
> code in $AXIOM/src. That would also get rid of most of the C code and
> thereby improve portability of the core. Making GUI programming easier
> is a lot more work.
>
> For a GUI to be more useful than an Axiom terminal session, it needs
> to be able to understand Axiom's output to some extent. It also needs the ability to
> query Axiom for all kinds of information, eg
>
> - list all existing variables/functions/types/commands/loaded libraries/etc
> - list all functions/commands that are either of a given type or applicable to a given object
> - where is the documentation for this library/function/command/etc?
> - where is the source code for a given function?
> - show me all functions/libraries that call/are called by function/library X
> - in debugging mode: supply a stack trace
>
> Create an API that supports this kind of functionality and future
> versions of itself, and make it available over a socket using a simple
> (in every programming language) clear-text protocol. Done. Sooner or
> later someone will write a GUI then.
Just a minute ago I revisited the Maxima mailing list archives and
found the following two messages supporting my point of view to some
extent:

http://www.math.utexas.edu/pipermail/maxima/2004/008349.html

  Argues that the output of Maxima shouldn't just be 'textual chatter'
  that the other end (a GUI or another tool) has to sort through. He
  calls this the 'stone age approach', and that's what it is.

  Unlike him I believe TCP sockets are nicer for communication than
  CORBA, but that's a detail. Just like the choice of XML, SEXPs, JSON
  or some other scheme for encoding the information that Axiom exchanges
  with the GUI.

http://www.math.utexas.edu/pipermail/maxima/2004/008303.html

  Argues for a clear separation of the GUI from the computational
  engine.

\start
Date: Thu, 7 Sep 2006 11:55:25 -0700
From: Justin Walker
To: Bill Page
Subject: Re: [SAGEdev] Xcode and Fink (was: Hopefully stupid question)
Cc: Camm Maguire, William Stein, Wagar Malik

Sorry for the delay in replying.

On Sep 6, 2006, at 18:09 , Page, Bill wrote:

> On Wednesday, September 06, 2006 1:12 PM Justin C. Walker wrote:
>>>> ...
>>>> So: you need to have Xcode (the package) installed, but you
>>>> don't need to "use Xcode" [the IDE].
>
> What about DarwinPorts?

DarwinPorts is in the same class as Fink: it is something that you  
should not rely on.  It may well be worth using what the DarwinPorts  
maintainers have discovered about building GCL on Mac OS X (as we  
have done in the past with Singular and Macaulay2, from Fink), but  
you can't rely on, and I think, force upon the SAGE user, the use of  
anything from DarwinPorts itself.

Since Waqar is now involved, this may be a moot point :-}

\start
Date: Thu, 7 Sep 2006 14:47:03 -0400
From: Tim Daly
To: Kai Kaminski
Subject: Re: Lisp GUI libraries and a UI for Axiom

> This comment begs the question though, why displaying graphics
> shouldn't be the responsibility of the GUI.

In Axiom, displaying graphics IS the clear responsibility of the GUI.
Axiom has a completely standalone graphics package (you can run it
directly, it's called viewAlone). 

I need to port viewAlone to many platforms. *MY* preference is to 
do it in lisp. 

\start
Date: Thu, 07 Sep 2006 20:59:15 +0200
From: Kai Kaminski
To: list
Subject: Re: Lisp GUI libraries and a UI for Axiom

Bob McElrath writes:

> As far as drawing graphs, why not just dump out a graph in any kind of
> portable format (e.g. postscript, pdf, svg, etc).  A front-end can parse
> it and display it.  There are many relevant lisp libraries:
>     http://www.cliki.net/graphics%20library
>     http://www.cliki.net/plotting
Because there is a difference between the plot data and the resulting
plot and producing the latter from the former isn't easy. The plot
contains all kinds of objects like grid lines, axis, a title etc. This
implies that we need tons of plotting code inside the core of
Axiom. The plot data that Axiom produces should be an easily parseable
description of the points/lines/surfaces that are to be displayed, as
well as all additional options that the user supplied, like colours,
axis etc.

As for the GUI, different people will prefer different plotters
(layout, output formats, ...).

\start
Date: Thu, 7 Sep 2006 13:28:51 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: A Canonical Axiom GUI 

While I agree that it is desirable to have Axiom be as easy as possible
to interface with from a GUI standpoint, I disagree that there
shouldn't be a canonical Axiom GUI.  This does not, please note, mean
that I think there should be ONLY one GUI for Axiom - people should be
free to make as many GUIs as they want.  The observation that different
people will want (and be more productive in) different environments is
quite correct.  However, there should be one GUI that is designed to be
the "default" GUI for Axiom.

For both Maple and Mathematica, there is one GUI which is designed to
offer an intelligent, organized way to deal with mathematical problems,
objects, and documents.  In each case this GUI is the "public face" of
the program and serves as both a convenient tool for document
formatting and as visual evidence of the effort put into making the
product a "finished, polished tool."  It is a re-assurance (however
potentially false) that work has gone into making sure that the user
won't have to deal with problems that programmers would normally deal
with.

I won't argue with those who will point out that this doesn't mean
anything about how good the mathematical abilities of the software are
- indeed, I agree with them.  But for those who will evaluate Axiom as
a tool to use, the metrics they will be using in some form are:

1.  Does this project look like a serious, able, and high quality
production?
2.  How friendly is it to use to do what I need to do?
3.  How much time will it take me to learn enough with this tool to
become productive?

It takes enough time and energy to evaluate a tool such as Axiom in a
non-trivial way that the motivation to do so must be extreme.  (How
many people here have seen a sub-optimal tool used simply because
people already knew it and thought it would be faster to use that tool
instead of learn one they knew might be better?)

For serious research, this may not be a problem.  Axiom has a very
strong foundation, and there are very probably lots of projects where
the time spent learning Axiom will pay off well enough to motivate
people to learn it, GUI or not.  Many more, however, will not be that
motivated.

I would personally prefer that there exist a GUI for Axiom that is
designed by the same people who are intimately familiar with the system
itself, and (for example) might be able to teach a graphical
environment to associate type information with graphical behavior in
the GUI.  (Imagine, for example, a GUI that would let someone drag a
polynomial into an integration template but would refuse a matrix as an
incompatible type.  Or a formula template for ballistic motion that
would reject anything with the wrong type in its slots.  The visual
display may or may not contain all of the important information for the
user, but a GUI working with the type system itself could be far more
intelligent.)  My guess is 3rd party graphical systems are not likely
to be interested in this type of work, preferring instead to simply use
Axiom as a mathematical engine to get answers to common problems.  

I think it would be desirable for people who download and install
Axiom, when they type "axiom" or click their Axiom icon, to have a GUI
environment available that is similar in concept to the Maple and
Mathematica environments, but perhaps with more or different
functionality.  Our "first impression" with potential users is what
they see when they start the program, and I would personally like there
to be a smooth, polished, and professional GUI as our first foot
forward.

Of course, someone would need to create such an environment, and code
always speaks louder than emails.  I have looked at these issues a
little bit and will attempt to pursue them further, but I know the
problem is significant.  I guess it boils down to this:

1.  I think a default GUI for Axiom would be a Very Good Thing
2.  The project is not yet a a point where this should be a major focus
for the project as a whole.
3.  The work to make Axiom more friendly to ALL GUIs should be more
important, because it will be useful to a very broad spectrum of
applications.  (Indeed, even the command prompt probably should work
off of the same API some day.)
4.  Code counts more than opinions, so I'll be quiet until I have more
of the former ;-).

\start
Date: 07 Sep 2006 16:58:46 -0400
From: Camm Maguire
To: Waqar Malik
Subject: Re: [SAGEdev] Xcode and Fink (was: Hopefully stupid question)
Cc: Aurelien Chanudet

Greetings!  I take it this discussion is regarding OSX support.
Great!

If memory serves, one of the gcl developers got this working with a
more recent release.  Am cc'ing him in hope he might have some
comment/be able to offer help.

Supposedly, 2.6.8pre compiles on OSX 'out of the box' -- at least the
ACL2 people have told me it worked for them.

Never understood the relationship between fink, darwinports, and
macports ...

There are OSX specific bfd patches in the gcl source tree.  It would
be wonderful to get these accepted into binutils upstream someday -- I
haven't gotten around to asking about it.

Take care,

Waqar Malik writes:

> Ok, I looked at the page, and to build it seems pretty simple, since
> it uses configure script., If you want to you can install MacPorts
> and install gcl and try to build axiom on the mac and see if it builds.
> I will give it a try later today, as I have class that I need to
> attend this morning.
> 
> --Waqar
> On Sep 7, 2006, at 10:24 AM, Page, Bill wrote:
> 
> > On Thursday, September 07, 2006 10:42 AM Waqar Malik wrote:
> >
> >> 	I be glad to help with Axiom, but I have not used
> >> Axiom, so I have not tried to compile it.
> >
> > Thank you, thank you!
> >
> > The main part of Axiom (the AXIOMsys computational "engine") is
> > built as a very large Lisp application on top of GCL plus a few
> > external subroutines written in C linked into the image.
> >
> > The two other main parts of Axiom: Hyperdoc and Graphics, run
> > as separate processes, are written entirely in C and communicate
> > with AXIOMsys via sockets.
> >
> >>
> >> Couple of things to remember about gcl port, I have not updated
> >> to the latest release (2.6.7) and I have not compiled it on
> >> Intel machines yet, I will have to spend some time to verify
> >> that it works.
> >>
> >
> > It should be possible to build Axiom using the older version
> > of GCL.
> >
> > Anything you can do to help us with this would be greatly
> > appreciated! If you haven't already, you might want to visit
> > the Axiom developer website at
> >
> > http://wiki.axiom-developer.org
> >
> > to find out more about Axiom. If you have any questions and/or
> > suggestions, please let me know.
> >
> > Thanks again, and "Welcome aboard!" :-)

\start
Date: Thu, 7 Sep 2006 17:05:55 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: Lisp GUI libraries and a UI for Axiom

> Bob McElrath writes:
>
> > As far as drawing graphs, why not just dump out a graph in
> > any kind of portable format (e.g. postscript, pdf, svg, etc).
> > A front-end can parse it and display it.  There are many
> > relevant lisp libraries:
> >     http://www.cliki.net/graphics%20library
> >     http://www.cliki.net/plotting
>

Bob, have you changed your mind on this issue since we discussed
it last year? :)

http://lists.nongnu.org/archive/html/axiom-developer/2005-06/msg00491.ht
ml

BTW, when I was looking in the archives, I noticed some more
"lost comments" about the use of HTTP as an Axiom user interface
protocol as mentioned in a different but related thread:

http://lists.nongnu.org/archive/html/axiom-developer/2005-05/msg00209.ht
ml

On Thursday, September 07, 2006 2:59 PM Kai Kaminski wrote:
>
> Because there is a difference between the plot data and the
> resulting plot and producing the latter from the former isn't
> easy. The plot contains all kinds of objects like grid lines,
> axis, a title etc. This implies that we need tons of plotting
> code inside the core of Axiom. The plot data that Axiom
> produces should be an easily parseable description of the
> points/lines/surfaces that are to be displayed, as well as
> all additional options that the user supplied, like colours,
> axis etc.
>

I am inclined to agree with Kai, but for reasons different than
the ones I would have sited last year. Specifically, in the
development of Sage I see a "real life" example of the benefits
the modular approach. This does not just apply between the
computational "engine" and the graphical user interface, but
actually extends deeper into methods of computation and outward
into various modes of presentation of the same data for different
purposes. From my point of view Sage gets a lot of mileage out of
being able to mix and match the features of many different open
source computer algebra systems. The more modular they are, the
more flexible the integration between them can be.

But Sage takes a somewhat different large-scale "object-oriented"
view. When maxima returns an object to a variable at the Sage
command level, that complex strongly-typed object inherits a
number of properties and methods from it's parent. In the case of
a Maxima expression, at least one of these methods plots a graph.
But this is just an external interface to some graphics function
internal to Maxima. For example another method might involve
Maxima's symbolic integration or differentiation operations.

And just like in Axiom, objects can often be coerced or converted
from one class (domain) into another where they might inherit
quite a different set of methods and properties, for example
as a polynomial in Singular or a graph in gnuplot. So this is
not modularity for it's own sake but rather because we really
need to be able to perform these conversions as efficiently
and flexibly as possible. If the graphic data from Axiom was
represented only as a postscript file, it might be very
difficult to convert that to a form that could be scaled by a
graphic method in gnuplot.

> As for the GUI, different people will prefer different plotters
> (layout, output formats, ...).
>

Long ago at the end of the previous century when Axiom was
younger and the developers more optimistic ... ;) ... Axiom
had a virtual reality graphics interface called OpenInventor.
In fact this was part of the Texplorer browser integration
which was lost to us by corporate decision making. But you
can still see the vestiges of that marriage in the existing
instrumentation in the Axiom library graphics code. (Ref.
Mike Dewar discussed this briefly on this list almost 4 years
ago!)

http://lists.nongnu.org/archive/html/axiom-developer/2005-04/msg00132.ht
ml

http://lists.gnu.org/archive/html/axiom-developer/2002-11/msg00142.html

OpenInventor is still there and it's still open source:

http://oss.sgi.com/projects/inventor
http://oss.sgi.com/projects/inventor/license.html

and has a lot of excellent documentation.

But it's real status as open source seems a bit in doubt since
it seems that an enhanced version is being sold as closed source
by a company called Mercury http://www.tgs.com ?

Wikipedia to the rescue ;)

 http://en.wikipedia.org/wiki/Open_Inventor

So now OpenInventor exists as "Coin3d"

  http://www.coin3d.org/
  http://www.coin3d.org/licensing

with dual GPL and commercial licensing!

Still confused? I am. It's hard to think of a better example
of the peculiar dynamics between proprietary and open source
software development!

Anyway, I wonder if having taken him apart, we could somehow
manage to put humpty-dumpty back together again? :)

\start
Date: 07 Sep 2006 17:16:10 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Cannot Rename The File Erlib To NRLIB

Bill Page writes:

> Camm, 
> 
> On Wednesday, September 06, 2006 1:50 PM you wrote:
> > 
> > Bill Page writes:
> > ... 
> > > > 
> > > > In src/interp/nlib.lisp.pamphlet:
> > > >
> > > > ----------
> > > > 
> > > >  ;; ($ERASE filearg) -> 0 if succeeds else 1
> > > >  (defun $erase (&rest filearg)
> > > >    (setq filearg (make-full-namestring filearg))
> > > > -  (if (probe-file filearg)
> > > > +  (if (directory (truename filearg))
> > > >  #+:CCL (delete-file filearg)
> > > >  #+:AKCL
> > > >        (if (library-file filearg)
> > > >            (delete-directory filearg)
> > > >            (delete-file filearg))
> > > >        1))
> > > > 
> > > > ----------
> > > > 
> > > ... 
> > > However I remain a little uncertain if 'directory' is really
> > > the proper way to check for the existence of a file or
> > > directory in common lisp?
> > > 
> > 
> > 1) I think you want (null (pathname-name (truename filearg)))
> >
> > 2) or (and (directory filearg) (not (probe-file filearg)))
> > 
> 
> Sorry, I still feel a little "dense" about this. Could you take
> a minute to translate these two expressions for me? I want
> 
>  (if (... filearg)
>    )
> 
> to be true if filearg is either a file *or* a directory.

My apologies -- I thought you just wanted a directory.  So both of the
above are wrong.

truename is required to return an error if the path does not exist.
So you might not want this.  

I think we might still be deviating from the spec on directory a bit.
Even though we pass all the ansi tests.  At the moment, the best I can
think of is

(or (probe-file filearg) (= 1 (length (directory filearg))))

We can change this if it is deemed insufficient, and/or add a si::stat
function. 

The pathnames returned by truename or directory, etc., are structures
with components:

device
directory
name
type

The second is a list of components, which can include keywords
:current, :absolute, etc.  It can also be nil, which gives the
default, i.e. current working dir.  Pathnames corresponding to
directories have nil in the last two slots, and have corresponding
namestrings ending in "/".  Unfortunately, as you state, directory at
present has a certain globbin/pattern matching behavior which is not
so useful in this context.  Again, we can likely change this if
needed.

Take care,


> 
> I suspect that 2) requires that it be a directory and not a file
> since 'probe-file' is now interpreted as specifically as testing
> for a *file*. So maybe that one is not right?
> 
> I am also worried about the "wild-card" properties of 'directory'
> which is not something I really want.
> 
> But I don't know the semantics of 1) at all, and having
> consulted the lisp docs as deeply as possible, I am still
> not sure. What exactly does expression 1) do on GCL?

\start
Date: 07 Sep 2006 16:18:17 -0500
From: Gabriel Dos Reis
To: Camm Maguire
Subject: re: [SAGEdev] Xcode and Fink (was: Hopefully stupid question)
Cc: Waqar Malik, Aurelien Chanudet

Camm Maguire writes:

[...]

| There are OSX specific bfd patches in the gcl source tree.  It would
| be wonderful to get these accepted into binutils upstream someday -- I
| haven't gotten around to asking about it.

Yes, I'm wondering why they are kept in GCL and not put in upstream.
I would suspect that binutils maintainers would be glad to have them.
Could you say more about the issues around its non-presence in upstream?

\start
Date: 07 Sep 2006 16:24:48 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: A Canonical Axiom GUI

Cliff Yapp writes:

[...]

| It takes enough time and energy to evaluate a tool such as Axiom in a
| non-trivial way that the motivation to do so must be extreme.  (How
| many people here have seen a sub-optimal tool used simply because
| people already knew it and thought it would be faster to use that tool
| instead of learn one they knew might be better?)

does Windows count as a tool? :-)

| 
| For serious research, this may not be a problem.  Axiom has a very
| strong foundation, and there are very probably lots of projects where
| the time spent learning Axiom will pay off well enough to motivate
| people to learn it, GUI or not.  Many more, however, will not be that
| motivated.
| 
| I would personally prefer that there exist a GUI for Axiom that is
| designed by the same people who are intimately familiar with the system
| itself, and (for example) might be able to teach a graphical
| environment to associate type information with graphical behavior in
| the GUI.  (Imagine, for example, a GUI that would let someone drag a
| polynomial into an integration template but would refuse a matrix as an
| incompatible type.  Or a formula template for ballistic motion that
| would reject anything with the wrong type in its slots.  The visual
| display may or may not contain all of the important information for the
| user, but a GUI working with the type system itself could be far more
| intelligent.)  My guess is 3rd party graphical systems are not likely
| to be interested in this type of work, preferring instead to simply use
| Axiom as a mathematical engine to get answers to common problems.  
| 
| I think it would be desirable for people who download and install
| Axiom, when they type "axiom" or click their Axiom icon, to have a GUI
| environment available that is similar in concept to the Maple and
| Mathematica environments, but perhaps with more or different
| functionality.  Our "first impression" with potential users is what
| they see when they start the program, and I would personally like there
| to be a smooth, polished, and professional GUI as our first foot
| forward.
| 
| Of course, someone would need to create such an environment, and code
| always speaks louder than emails.  I have looked at these issues a
| little bit and will attempt to pursue them further, but I know the
| problem is significant.  I guess it boils down to this:
| 
| 1.  I think a default GUI for Axiom would be a Very Good Thing
| 2.  The project is not yet a a point where this should be a major focus
| for the project as a whole.
| 3.  The work to make Axiom more friendly to ALL GUIs should be more
| important, because it will be useful to a very broad spectrum of
| applications.  (Indeed, even the command prompt probably should work
| off of the same API some day.)
| 4.  Code counts more than opinions, so I'll be quiet until I have more
| of the former ;-).

\start
Date: 07 Sep 2006 16:26:20 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: A Canonical Axiom GUI

Cliff Yapp writes:

[...]

| It takes enough time and energy to evaluate a tool such as Axiom in a
| non-trivial way that the motivation to do so must be extreme.  (How
| many people here have seen a sub-optimal tool used simply because
| people already knew it and thought it would be faster to use that tool
| instead of learn one they knew might be better?)

Does Windows count as a tool? :-)

[...]

| I think it would be desirable for people who download and install
| Axiom, when they type "axiom" or click their Axiom icon, to have a GUI
| environment available that is similar in concept to the Maple and
| Mathematica environments, but perhaps with more or different
| functionality. 

\start
Date: Thu, 07 Sep 2006 23:48:12 +0200
From: Kai Kaminski
To: Cliff Yapp
Subject: Re: A Canonical Axiom GUI

Cliff Yapp writes:

> I won't argue with those who will point out that this doesn't mean
> anything about how good the mathematical abilities of the software are
> - indeed, I agree with them.  But for those who will evaluate Axiom as
> a tool to use, the metrics they will be using in some form are:
>
> 1.  Does this project look like a serious, able, and high quality
> production?
> 2.  How friendly is it to use to do what I need to do?
> 3.  How much time will it take me to learn enough with this tool to
> become productive?
I'm not sure how these objectives depend on the existence of a
canonical user interface. Besides what looks great to the beginning
student might look like a toy to a researcher. What looks great to the
latter might look like a pile of unintellegible crap to the former.

> It takes enough time and energy to evaluate a tool such as Axiom in a
> non-trivial way that the motivation to do so must be extreme.  (How
> many people here have seen a sub-optimal tool used simply because
> people already knew it and thought it would be faster to use that tool
> instead of learn one they knew might be better?
The tool doesn't change, only the GUI. Do you know any other
successful language that has a canonical GUI? Certainly not C/C++,
Java, Smalltalk, Lisp, Python, Ruby, Fortran.

> I would personally prefer that there exist a GUI for Axiom that is
> designed by the same people who are intimately familiar with the system
> itself, and (for example) might be able to teach a graphical
> environment to associate type information with graphical behavior in
> the GUI.  (Imagine, for example, a GUI that would let someone drag a
> polynomial into an integration template but would refuse a matrix as an
> incompatible type.  Or a formula template for ballistic motion that
> would reject anything with the wrong type in its slots.  The visual
> display may or may not contain all of the important information for the
> user, but a GUI working with the type system itself could be far more
> intelligent.)  My guess is 3rd party graphical systems are not likely
> to be interested in this type of work, preferring instead to simply use
> Axiom as a mathematical engine to get answers to common problems.  
I certainly hope that implementing the two examples you give doesn't
require one to be an Axiom expert. Why do you assume that 3rd parties
are not interested in developing powerful GUIs? Non of the free Lisp
implementations has an IDE and most people are using Slime, which is
just great (even though not nearly perfect).

> I think it would be desirable for people who download and install
> Axiom, when they type "axiom" or click their Axiom icon, to have a GUI
> environment available that is similar in concept to the Maple and
> Mathematica environments, but perhaps with more or different
> functionality.  Our "first impression" with potential users is what
> they see when they start the program, and I would personally like there
> to be a smooth, polished, and professional GUI as our first foot
> forward.
Why can't you provide this experience without a canonical GUI? Linux
doesn't have a canonical GUI, it doesn't even have any standard
software. That's why mere mortals don't just download the kernel, but
instead install Ubuntu, or whatever the latest hip Linux distribution
is (I don't mean to disparage Ubuntu, as far as I know it's a fine
system).

> Of course, someone would need to create such an environment, and code
> always speaks louder than emails.  I have looked at these issues a
> little bit and will attempt to pursue them further, but I know the
> problem is significant.  I guess it boils down to this:
>
> 1.  I think a default GUI for Axiom would be a Very Good Thing
As I said, I'm not convinced.

> 2.  The project is not yet a a point where this should be a major focus
> for the project as a whole.
That depends on what you mean. I believe the most important thing is
to make it developer friendly. In particular we must be able to use
all the open source Lisp libraries that are available. Also, writing
tools (especially GUIs) for Axiom should be easy.

> 3.  The work to make Axiom more friendly to ALL GUIs should be more
> important, because it will be useful to a very broad spectrum of
> applications.  (Indeed, even the command prompt probably should work
> off of the same API some day.)
It most certainly should.

> 4.  Code counts more than opinions, so I'll be quiet until I have more
> of the former ;-).
I'm not so sure about that. How can anyone start coding if there is no
consent of what the core of Axiom is and what features it should offer
to GUIs?

Finally I'd be interested in how we could get such a canonical GUI. I
see two ways, each of which has its fair share of problems.

1) We discuss what features the GUI should have and what modifications
   to Axiom's core are necessary. Then some poor soul starts coding
   and after some time (probably measured in years) we end up with the
   canonical GUI as the Axiom gods ordered it (that's us).

   What if it fails for whatever reason? What if some third party
   builds a GUI that is much more attractive to users than the
   canonical one? Look at GNU Hurd and Linux. I seem to remember that
   Hurd is the 'canonical' GNU OS. Does anyone care?

2) We modify the Axiom core to allow easy development of GUIs. People
   start building them, first simple, then more involved ones. We pick
   the 'best'.

   What if two years later a different GUI is much better? Do we
   change the canonical GUI? For how long does it have to be the
   better one?


Finally let me point out that there really is no best GUI. On Mac OS X
the perfect GUI must support AppleScript and satisfy the expectations
of Mac users, who are very picky about UI design. Recently I witnessed
a discussion about the subtle differences between a window's
maximize/close button on OS X and Windows.

Since a single GUI might support several system at once (see Bill's
work), why not turn the whole thing upside-down? People download
bundles consisting of a single GUI and several cores (Axiom, GAP,
whatever).

Kai

PS: I don't mean to say that there shouldn't be a nice, downloadable
package on Axiom's website featuring a specific GUI. What I'm after is
independence. Axiom's main branch should contain no GUI-related code
other than the implementation of the Axiom<->GUI protocol.

\start
Date: 07 Sep 2006 17:08:50 -0500
From: Gabriel Dos Reis
To: Kai Kaminski
Subject: Re: A Canonical Axiom GUI

Kai Kaminski writes:

[...]

| PS: I don't mean to say that there shouldn't be a nice, downloadable
| package on Axiom's website featuring a specific GUI. What I'm after is
| independence. Axiom's main branch should contain no GUI-related code
| other than the implementation of the Axiom<->GUI protocol.

I agree with that.  If you can sell it to the powers, I would be happy
to lend a helping hand.

\start
Date: Thu, 7 Sep 2006 18:08:34 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Cannot Rename The File Erlib To NRLIB

On Thursday, September 07, 2006 5:16 PM you wrote:
> ...
> I think we might still be deviating from the spec on directory a
> bit. Even though we pass all the ansi tests.  At the moment, the
> best I can think of is
>
> (or (probe-file filearg) (= 1 (length (directory filearg))))
>
> We can change this if it is deemed insufficient, and/or add a
> si::stat function.
> ...

Yes. I prefer the (si:stat filearg) function:

  nil if no file or directory exists,  otherwise some
  list of useful info and keywords (like Unix?)

The non-nil return might not be so standard between systems
but who really cares?

The following long boring chain of messages between the experts:

http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2005-07/msg01699
.html

convinces me that your suggestion is the best idea so far! :-)

\start
Date: Thu, 7 Sep 2006 17:09:06 -0500
From: Waqar Malik
To: Camm Maguire
Subject: Re: [SAGEdev] Xcode and Fink (was: Hopefully stupid question)
Cc: Aurelien Chanudet

On Sep 7, 2006, at 3:58 PM, Camm Maguire wrote:

> Greetings!  I take it this discussion is regarding OSX support.
> Great!
>
> If memory serves, one of the gcl developers got this working with a
> more recent release.  Am cc'ing him in hope he might have some
> comment/be able to offer help.
>
> Supposedly, 2.6.8pre compiles on OSX 'out of the box' -- at least the
> ACL2 people have told me it worked for them.
>
	So that means we need to bump the port to the latest source and take  
it from there. I just tried to compile GCL 2.6.6 and 2.6.7 on 10.4.7  
and it failed, I will see what is going on and at least update the  
port to build correctly.

> Never understood the relationship between fink, darwinports, and
> macports ...
>
	DarwinPorts was renamed to MacPorts after recent shutdown of the  
OpenDarwin. Fink is a separate porting environment. You only need one  
or the other, they pretty much do the same thing. There might be  
differences in number and kind of ports.


> There are OSX specific bfd patches in the gcl source tree.  It would
> be wonderful to get these accepted into binutils upstream someday -- I
> haven't gotten around to asking about it.
>
> Take care,
>
> Waqar Malik writes:
>
>> Ok, I looked at the page, and to build it seems pretty simple, since
>> it uses configure script., If you want to you can install MacPorts
>> and install gcl and try to build axiom on the mac and see if it  
>> builds.
>> I will give it a try later today, as I have class that I need to
>> attend this morning.
>>
>> --Waqar
>> On Sep 7, 2006, at 10:24 AM, Page, Bill wrote:
>>
>>> On Thursday, September 07, 2006 10:42 AM Waqar Malik wrote:
>>>
>>>> 	I be glad to help with Axiom, but I have not used
>>>> Axiom, so I have not tried to compile it.
>>>
>>> Thank you, thank you!
>>>
>>> The main part of Axiom (the AXIOMsys computational "engine") is
>>> built as a very large Lisp application on top of GCL plus a few
>>> external subroutines written in C linked into the image.
>>>
>>> The two other main parts of Axiom: Hyperdoc and Graphics, run
>>> as separate processes, are written entirely in C and communicate
>>> with AXIOMsys via sockets.
>>>
>>>>
>>>> Couple of things to remember about gcl port, I have not updated
>>>> to the latest release (2.6.7) and I have not compiled it on
>>>> Intel machines yet, I will have to spend some time to verify
>>>> that it works.
>>>>
>>>
>>> It should be possible to build Axiom using the older version
>>> of GCL.
>>>
>>> Anything you can do to help us with this would be greatly
>>> appreciated! If you haven't already, you might want to visit
>>> the Axiom developer website at
>>>
>>> http://wiki.axiom-developer.org
>>>
>>> to find out more about Axiom. If you have any questions and/or
>>> suggestions, please let me know.
>>>
>>> Thanks again, and "Welcome aboard!" :-)

\start
Date: Thu, 7 Sep 2006 16:30:07 -0700 (PDT)
From: Cliff Yapp
To: Kai Kaminski
Subject: Re: A Canonical Axiom GUI

Hey Kai!  We never seem to overlap on IRC, do we? ;-)  Sorry about that
- I need xchat to make a noise when someone sends a message to me. 
Hmm...

--- Kai Kaminski wrote:

> The tool doesn't change, only the GUI. Do you know any other
> successful language that has a canonical GUI? Certainly not C/C++,
> Java, Smalltalk, Lisp, Python, Ruby, Fortran.

Are you saying you regard Axiom as a language?
 
> I certainly hope that implementing the two examples you give doesn't
> require one to be an Axiom expert. Why do you assume that 3rd parties
> are not interested in developing powerful GUIs? Non of the free Lisp
> implementations has an IDE and most people are using Slime, which is
> just great (even though not nearly perfect).

SLIME is quite good, but I'm not sure the cases are comparable.  If you
look around, I think you will find that there are few to no open source
mathematical environments that approach Mathematica's notebook
interface.  Texmacs probably comes the closest of any I am familiar
with, but it is not tightly integrated with the mathematical
environment.  Some, like wxMaxima, are nice and quite functional but I
think we should strive to have a GUI the way Axiom strives to be a CAS
- to be a solution so good that using it is a no-brainer.  Study all
existing solutions, find the best features of them all, research it
(there is existing work on the topic that is quite academic in nature),
and then design the interface using literate programming techniques. 
To me Lisp makes sense as the language of the GUI because that is also
the foundational language Axiom is written in.

> Why can't you provide this experience without a canonical GUI? Linux
> doesn't have a canonical GUI, it doesn't even have any standard
> software.

There are arguments that it suffers because of this, particularly from
the standpoint of those looking to offer commercial software on Linux. 
I admit I don't know, since the only way to find out is to try, but I
suspect that developing a top notch CAS GUI will require those familiar
with Axiom itself to be deeply involved in the process.

> That's why mere mortals don't just download the kernel, but
> instead install Ubuntu, or whatever the latest hip Linux distribution
> is (I don't mean to disparage Ubuntu, as far as I know it's a fine
> system).

Agreed.  But it does result in effort being diffused over many
distributions and many parallel efforts.  This is the nature of open
source and definitely allows for new features to be tried, so I don't
decry it - but I hope that new and advanced features of mathematical
GUIs could be incorporated into a unified, powerful environment for
Axiom instead of having the user forced to sacrifice one feature or
another depending on their choice of GUI.  (Minimalistic interfaces
aside, of course - there the whole point is to have fewer features.)  

> > 1.  I think a default GUI for Axiom would be a Very Good Thing
>
> As I said, I'm not convinced.

No worries.  There is plenty of room here for differing opinions :-).
 
> > 2.  The project is not yet a a point where this should be a major
> > focus for the project as a whole.
>
> That depends on what you mean. I believe the most important thing is
> to make it developer friendly. In particular we must be able to use
> all the open source Lisp libraries that are available. Also, writing
> tools (especially GUIs) for Axiom should be easy.

Right.  What I ment was we shouldn't be (as a project) worrying about
GUI design when we can't run on ANSI lisp yet.
 
> > 4.  Code counts more than opinions, so I'll be quiet until I have
> > more of the former ;-).

> I'm not so sure about that. How can anyone start coding if there is
> no consent of what the core of Axiom is and what features it should
> offer to GUIs?

Well, that's a bit different.  What we should expose to GUIs and how is
probably somewhat separate from how the GUIs use that information.  The
latter is usually where most of the trouble comes in :-).

> Finally I'd be interested in how we could get such a canonical GUI. I
> see two ways, each of which has its fair share of problems.
> 
> 1) We discuss what features the GUI should have and what
> modifications to Axiom's core are necessary. Then some poor soul
> starts coding and after some time (probably measured in years) we
> end up with the canonical GUI as the Axiom gods ordered it (that's
> us).

:-).  I'm beginning to think that most really high quality software
does take years.  TeX, Axiom, BrlCAD...
 
> What if it fails for whatever reason? What if some third party
> builds a GUI that is much more attractive to users than the
> canonical one? Look at GNU Hurd and Linux. I seem to remember that
> Hurd is the 'canonical' GNU OS. Does anyone care?

Well, if what I have heard about Lisp holds true in GUI programming it
should be fairly hard for anybody to create a feature we can't
incorporate one way or another ;-).  The idea of a literate GUI program
should be that it is first about ideas, and second about the
implementation of those ideas.  If we do it right and cover most of the
key elements of such programs from the beginning (and there are many
similar elements) then further extensions of the core functionality
should be managable.  From my standpoint, the key problems are:

1.  2-D interactive mathematical display and formatting, particularly
line breaking and font interactions.  Probably the hardest single part.

2.  2 and 3-D plotting, interactive manipulation, etc.  IZIC has done
some work that I like, and VTK is also very nice - adapting those ideas
and some work that has been done on how to do high quality mathematical
plotting is probably the second hardest part, or even hardest if we
also cover the core algorithms for graphical display and manipulation
ourselves.

3.  IO in various formats.  TeX, LaTeX, openmath, MathML, a file
storage format for Axiom notebooks, Word's equation editor and doc
format, pdf (particularly the interesting new trick of embedding movies
and objects you can interact with).  Communications protocals between
GUI and Axiom core also fall in here.  Here's an interesting one - if
we need to run the Axiom core without a multi-threaded lisp, how do we
stop a job that is running too long?  Killing it is a bit drastic,
since that also loses us any other computations done before, but what
alternatives are there?

4.  Global document structure - in some ways, a Mathematical GUI must
also be a document processor.  Mathematica certainly is.  How do we
handle that issue?  What typesetting engines are available, and which
are suited for interactive work? 
 
> 2) We modify the Axiom core to allow easy development of GUIs. People
>    start building them, first simple, then more involved ones. We
>    pick the 'best'.
> 
>    What if two years later a different GUI is much better? Do we
>    change the canonical GUI? For how long does it have to be the
>    better one?

That's why I prefer we have our own, that takes good ideas wherever
they are found and incorporates them.
 
> Finally let me point out that there really is no best GUI. On Mac OS
> X the perfect GUI must support AppleScript and satisfy the
> expectations of Mac users, who are very picky about UI design.
> Recently I witnessed a discussion about the subtle differences
> between a window's maximize/close button on OS X and Windows.

Yes, it's quite tricky.  My understanding was CLIM was developed in
part to abstract as much of that as possible, although lack of back
ends to GUI libraries sort of limits that potential at the moment.  In
some respects I think the CLIM design was even more ambitious than that
of Java's GUI libraries - the designers wanted the possiblity of native
looks on all supported platforms using native widgets, when available. 
Of course, that's a bit hard in practice and would require a fairly
universal FFI (hence my interest in the CFFI project.)

> Since a single GUI might support several system at once (see Bill's
> work), why not turn the whole thing upside-down? People download
> bundles consisting of a single GUI and several cores (Axiom, GAP,
> whatever).

Because those systems, fundamentally, are not designed to work
together.  I admire the SAGE effort and I think it will be very useful,
but GAP (for example) doesn't share Axiom's type system and so there is
an impediance mismatch between the two systems.  What assumptions is
GAP making that Axiom doesn't know about when it solves a problem, and
are those assumptions ones that are compatible with the ones we would
make?  Does a function name or even a property name mean the same thing
between the two systems?  If we evolve towards proving algorithms, how
do we prove an algorithm used in GAP without doing enough work to go
ahead and implement it in Axiom anyway?  

> PS: I don't mean to say that there shouldn't be a nice, downloadable
> package on Axiom's website featuring a specific GUI. What I'm after
> is independence. Axiom's main branch should contain no GUI-related
> code other than the implementation of the Axiom<->GUI protocol.
 
Well, maybe.  But I think there should be an axiom-gui tree as well
that has the "official" Axiom GUI, which the Axiom project keeps in
sync with any changes to the Axiom core.  And when we build the
complete "system" we should build axiom-gui as well.  We already build
the Hyperdoc program, after all, and that is part of the default
system.  I'd rather have axiom-gui as a directory in the toplevel axiom
branch, and have a ./configure --without-gui option if one doesn't want
it.  When I type .configure  make  make install and then run "axiom" I
would kind of expect the GUI to be the default.

\start
Date: 07 Sep 2006 22:01:19 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: re: [SAGEdev] Xcode and Fink (was: Hopefully stupid question)
Cc: Waqar Malik, Aurelien Chanudet

Gabriel Dos Reis writes:

> Camm Maguire writes:
> 
> [...]
> 
> | There are OSX specific bfd patches in the gcl source tree.  It would
> | be wonderful to get these accepted into binutils upstream someday -- I
> | haven't gotten around to asking about it.
> 
> Yes, I'm wondering why they are kept in GCL and not put in upstream.
> I would suspect that binutils maintainers would be glad to have them.
> Could you say more about the issues around its non-presence in upstream?
> 

I think it is simple lack of followup on my part with the binutils
developers.  If you would like to isolate the patch and craft an
email, that would be most helpful!

\start
Date: Fri, 8 Sep 2006 04:41:00 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Build-improvements - noweb required?

Building build-improvements branch fails without alredy installed
noweb.  Namely, confugure detects that noweb is absent and then
proceeds further. But the Makefile variable TANGLE is unset, which
causes build failure before building noweb (in fact, it looks that
noweb is not built at all).

\start
Date: 08 Sep 2006 02:57:17 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Build-improvements - noweb required?

Waldek Hebisch writes:

| Building build-improvements branch fails without alredy installed
| noweb.  Namely, confugure detects that noweb is absent and then
| proceeds further. But the Makefile variable TANGLE is unset, which
| causes build failure before building noweb (in fact, it looks that
| noweb is not built at all).

which platform is this on?  Please, could you send the build log to
axiom-testresults@lists.sf.net so that I can have a look at it?

\start
Date: Fri, 8 Sep 2006 13:01:07 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Build-improvements - noweb required?

> Waldek Hebisch writes:
> 
> | Building build-improvements branch fails without alredy installed
> | noweb.  Namely, confugure detects that noweb is absent and then
> | proceeds further. But the Makefile variable TANGLE is unset, which
> | causes build failure before building noweb (in fact, it looks that
> | noweb is not built at all).
> 
> which platform is this on?  Please, could you send the build log to
> axiom-testresults@lists.sf.net so that I can have a look at it?
> 
> Thanks!
> 
> -- Gaby
> 

Done that and got:

> Your mail to 'Axiom-testresults' with the subject
>
>     Build failure without noweb

> Is being held until the list moderator can review it for approval.
>
> The reason it is being held:
>
>     Post by non-member to a members-only list

Hope you can see it.

\start
Date: Fri, 08 Sep 2006 13:13:44 +0200
From: Kai Kaminski
To: Gabriel Dos Reis
Subject: Re: A Canonical Axiom GUI

Gabriel Dos Reis writes:

> Kai Kaminski writes:
>
> [...]
>
> | PS: I don't mean to say that there shouldn't be a nice, downloadable
> | package on Axiom's website featuring a specific GUI. What I'm after is
> | independence. Axiom's main branch should contain no GUI-related code
> | other than the implementation of the Axiom<->GUI protocol.
>
> I agree with that.  If you can sell it to the powers, I would be happy
> to lend a helping hand.
Thanks. Maybe we can just agree that having an API/protocol to the
Axiom core is useful anyway and then implement that. That way we avoid
the discussion about wether we need a canonical GUI or not. The
existence of a well-designed API seems to be a good idea anyway.

I'll try to put up a wiki page for collecting design proposals, use
cases, etc. Furthermore I'll try to document those parts of Axiom that
are directly related to this effort (plotting code, database access,
documentation access, access to the interpreter/compiler etc).

\start
Date: 08 Sep 2006 06:20:00 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Build-improvements - noweb required?

Waldek Hebisch writes:

| > Waldek Hebisch writes:
| > 
| > | Building build-improvements branch fails without alredy installed
| > | noweb.  Namely, confugure detects that noweb is absent and then
| > | proceeds further. But the Makefile variable TANGLE is unset, which
| > | causes build failure before building noweb (in fact, it looks that
| > | noweb is not built at all).
| > 
| > which platform is this on?  Please, could you send the build log to
| > axiom-testresults@lists.sf.net so that I can have a look at it?
| > 
| > Thanks!
| > 
| > -- Gaby
| > 
| 
| Done that and got:

Thanks!

| > Your mail to 'Axiom-testresults' with the subject
| >
| >     Build failure without noweb
| 
| > Is being held until the list moderator can review it for approval.
| >
| > The reason it is being held:
| >
| >     Post by non-member to a members-only list
| 
| Hope you can see it.

Tim, I don't have admin privilege for mailing lists; can you look into
this, please?

Waldek, please send me (gdr at acm.org) the config.log from the build
directory.  Thanks!

\start
Date: Fri, 08 Sep 2006 15:55:58 +0200
From: Kai Kaminski
To: Cliff Yapp
Subject: Re: A Canonical Axiom GUI

Cliff Yapp writes:

> Hey Kai!  We never seem to overlap on IRC, do we? ;-)  Sorry about that
> - I need xchat to make a noise when someone sends a message to me. 
> Hmm...
:-)

> --- Kai Kaminski wrote:
>
>> The tool doesn't change, only the GUI. Do you know any other
>> successful language that has a canonical GUI? Certainly not C/C++,
>> Java, Smalltalk, Lisp, Python, Ruby, Fortran.
>
> Are you saying you regard Axiom as a language?
Axiom isn't a language perse, but it incorporates Spad/Aldor, which is
one (two actually) and offers an interpreter. How is that different
from Lisp, Haskell, ML or any other programming language that offers
an interactive environment?

Wouldn't you expect the average user of Axiom to write at least little
programs/libraries?

>> I certainly hope that implementing the two examples you give doesn't
>> require one to be an Axiom expert. Why do you assume that 3rd parties
>> are not interested in developing powerful GUIs? Non of the free Lisp
>> implementations has an IDE and most people are using Slime, which is
>> just great (even though not nearly perfect).
>
> SLIME is quite good, but I'm not sure the cases are comparable.  If you
> look around, I think you will find that there are few to no open source
> mathematical environments that approach Mathematica's notebook
> interface.  Texmacs probably comes the closest of any I am familiar
> with, but it is not tightly integrated with the mathematical
> environment.  Some, like wxMaxima, are nice and quite functional but I
> think we should strive to have a GUI the way Axiom strives to be a CAS
> - to be a solution so good that using it is a no-brainer.
You seem to suggest that we are better suited to built a powerful,
complex GUI than the community at large. I don't believe that.

I don't know why TeXmacs isn't as tightly integrated with any
mathematical environment as you'd wish. I *do* know, though, that it
would be fairly hard to integrate it closely with Axiom, because Axiom
is somewhat 'unfriendly' to programs. If anyone feels that this claim
should be substantiated I'll happily give a few examples.

>  Study all
> existing solutions, find the best features of them all, research it
> (there is existing work on the topic that is quite academic in nature),
> and then design the interface using literate programming techniques. 
> To me Lisp makes sense as the language of the GUI because that is also
> the foundational language Axiom is written in.
I disagree with this on several counts. First of all this looks like
the waterfall model to me. Figure out what we want, implement it, be
happy. The problem is that we don't even know what we want, and we'll
never figure that out without writing some GUI code.

Why does a GUI need literate programming? Correctness in the GUI isn't
nearly as important as in the mathematical core. Besides, literate
programming is an investment in the future. GUI code often doesn't
have much of a future, since things change rapidly. Especially the
first few GUI attempts will be so bad that people will throw them
away, anyway. That shouldn't stop anyone from using LP if so inclined.

I don't understand the connection between the implementation languages
of Axiom and (one of) its GUIs at all. The only good thing that would
come out of writing the GUI in Lisp in that regard is that the GUI
could run in the same Lisp image as Axiom (that would require
multi-threading, by the way, unless you're prepared to let your GUI
stall for hours at a time). That would spare us the burden of defining
a network protocol and we might even do without a proper API to the
core by just letting the GUI code dig around in the bowels of Axiom.
While that is tempting I strongly believe that it is important to
make building GUIs in any language as easy as possible.

>> Why can't you provide this experience without a canonical GUI? Linux
>> doesn't have a canonical GUI, it doesn't even have any standard
>> software.
>
> There are arguments that it suffers because of this, particularly from
> the standpoint of those looking to offer commercial software on Linux. 
> I admit I don't know, since the only way to find out is to try, but I
> suspect that developing a top notch CAS GUI will require those familiar
> with Axiom itself to be deeply involved in the process.
Someone who isn't at least somewhat familiar with Axiom or CAS in
general probably wouldn't attempt to write a GUI for it (oh, the
irony). The only things that require deep Axiom knowledge are the
specification and implementation of the Axiom/GUI protocol. Writing a
top notch GUI requires GUI design skills and an end user perspective.

Besides I never argued that Axiom's core developers shouldn't be
involved with the development of one or more GUIs. I'm not convinced
though, that they'll produce the best GUI possible. Furthermore I'm
confident that they have more important things to do. To rephrase that
argument: Many people can do GUI development, but only very few can
work on Axiom's internals. It sure isn't a good idea then, to have the
Axiom experts hacking on the GUI.

>> That's why mere mortals don't just download the kernel, but
>> instead install Ubuntu, or whatever the latest hip Linux distribution
>> is (I don't mean to disparage Ubuntu, as far as I know it's a fine
>> system).
>
> Agreed.  But it does result in effort being diffused over many
> distributions and many parallel efforts.  This is the nature of open
> source and definitely allows for new features to be tried, so I don't
> decry it - but I hope that new and advanced features of mathematical
> GUIs could be incorporated into a unified, powerful environment for
> Axiom instead of having the user forced to sacrifice one feature or
> another depending on their choice of GUI.  (Minimalistic interfaces
> aside, of course - there the whole point is to have fewer features.)  
Parallel efforts are great! Suppose there was one true Linux. Do you
believe that all the people who work on specific distributions now
would then instead work on the one true version? Also what if there
are two really cool features which you can't support at the same time?

>> > 1.  I think a default GUI for Axiom would be a Very Good Thing
>>
>> As I said, I'm not convinced.
>
> No worries.  There is plenty of room here for differing opinions :-).
Don't kid yourself. There's barely enough room for mine. ;-)

>> > 2.  The project is not yet a a point where this should be a major
>> > focus for the project as a whole.
>>
>> That depends on what you mean. I believe the most important thing is
>> to make it developer friendly. In particular we must be able to use
>> all the open source Lisp libraries that are available. Also, writing
>> tools (especially GUIs) for Axiom should be easy.
>
> Right.  What I ment was we shouldn't be (as a project) worrying about
> GUI design when we can't run on ANSI lisp yet.
Exactly. By making GUI development easy other people who can't or
don't want to work on the more pressing problems (ANSIfication,
Spad/Aldor, elimination of BOOT [that one's for you, Bill ;-)] etc)
can start working on GUIs. Later, when the more imminent problems have
been solved, we can look at the existing GUIs and figure out where to
go from there. Why should GUI development have to wait until
everything else has been taken care of?

>> > 4.  Code counts more than opinions, so I'll be quiet until I have
>> > more of the former ;-).
>
>> I'm not so sure about that. How can anyone start coding if there is
>> no consent of what the core of Axiom is and what features it should
>> offer to GUIs?
>
> Well, that's a bit different.  What we should expose to GUIs and how is
> probably somewhat separate from how the GUIs use that information.  The
> latter is usually where most of the trouble comes in :-).
It is indeed very different. Of course, the former should be guided by
the latter. Since we don't really know what a great GUI should look
like, we'll have to take some educated guesses and then wait for
feedback.

>> Finally I'd be interested in how we could get such a canonical GUI. I
>> see two ways, each of which has its fair share of problems.
>> 
>> 1) We discuss what features the GUI should have and what
>> modifications to Axiom's core are necessary. Then some poor soul
>> starts coding and after some time (probably measured in years) we
>> end up with the canonical GUI as the Axiom gods ordered it (that's
>> us).
>
> :-).  I'm beginning to think that most really high quality software
> does take years.  TeX, Axiom, BrlCAD...
Sure. Most great software is the result of evolution, though. Another
argument why we shouldn't be too picky about the quality of early GUI
code. This in turn means that the GUI code shouldn't live in Axiom's
main branch, or in any Axiom branch at all.

>> What if it fails for whatever reason? What if some third party
>> builds a GUI that is much more attractive to users than the
>> canonical one? Look at GNU Hurd and Linux. I seem to remember that
>> Hurd is the 'canonical' GNU OS. Does anyone care?
>
> Well, if what I have heard about Lisp holds true in GUI programming it
> should be fairly hard for anybody to create a feature we can't
> incorporate one way or another ;-).  The idea of a literate GUI
> program
That doesn't imply that it's a good idea. Besides you have to consider
library issues. Despite Lisp's greatness as a language, there isn't
good support for native Cocoa (Mac) user interfaces. In fact it's not
even clear that there ever will be. On Windows there is an effort for
a native GUI library, but it's still in alpha as far as I know (google
for 'graphics-forms'). Even if that succeeds you might be better off
with Visual Basic (as sad as that is).

> should be that it is first about ideas, and second about the
> implementation of those ideas.  If we do it right and cover most of the
> key elements of such programs from the beginning (and there are many
> similar elements) then further extensions of the core functionality
> should be managable.  From my standpoint, the key problems are:
I claim that you won't have the right idea without actually writing
code. Some features look great in theory, but don't work out in
practice. It is notoriously hard to predict these things. Hence the
'design first - code later' method will break down.

> 1.  2-D interactive mathematical display and formatting, particularly
> line breaking and font interactions.  Probably the hardest single part.
This is of interest to other people as well
(eg. cl-typesetting). Thus it should be done in a separate general
purpose library (eg. cl-typesetting).

> 2.  2 and 3-D plotting, interactive manipulation, etc.  IZIC has done
> some work that I like, and VTK is also very nice - adapting those ideas
> and some work that has been done on how to do high quality mathematical
> plotting is probably the second hardest part, or even hardest if we
> also cover the core algorithms for graphical display and manipulation
> ourselves.
That's been done for other languages already. It would be cool to have
a flexible plotting library in Lisp. But it's a waste of time write
now. There are good offerings in other languages, so just use
them. The Python Matplotlib source is about 30,000 lines, if I recall
correctly. Do you really want to recreate that effort for the sake of
purity? I don't.

> 3.  IO in various formats.  TeX, LaTeX, openmath, MathML, a file
> storage format for Axiom notebooks, Word's equation editor and doc
> format, pdf (particularly the interesting new trick of embedding movies
> and objects you can interact with).  Communications protocals
> between
I reckon that most of this should be the responsibility of external
tools, not the Axiom core itself.

> GUI and Axiom core also fall in here.  Here's an interesting one - if
> we need to run the Axiom core without a multi-threaded lisp, how do we
> stop a job that is running too long?  Killing it is a bit drastic,
> since that also loses us any other computations done before, but what
> alternatives are there?
For starters we could just use a multi-threaded Lisp. If that fails we
might be able to use Unix signals (or an equivalent mechanism) and
several processes. In the beginning we might have to live with an
Axiom that doesn't behave very well.

> 4.  Global document structure - in some ways, a Mathematical GUI must
> also be a document processor.  Mathematica certainly is.  How do we
> handle that issue?  What typesetting engines are available, and which
> are suited for interactive work? 
Depends on the GUI. Not everyone wants to write articles using his
CAS. Some people just want to calculate a few integrals every now and
then. Those GUIs that want to do document processing will figure out a
way to do it. That problem isn't really specific to Axiom.

>> 2) We modify the Axiom core to allow easy development of GUIs. People
>>    start building them, first simple, then more involved ones. We
>>    pick the 'best'.
>> 
>>    What if two years later a different GUI is much better? Do we
>>    change the canonical GUI? For how long does it have to be the
>>    better one?
>
> That's why I prefer we have our own, that takes good ideas wherever
> they are found and incorporates them.
And is always last on new developments, and looks like a random
collection of CAS GUI features.

>> Since a single GUI might support several system at once (see Bill's
>> work), why not turn the whole thing upside-down? People download
>> bundles consisting of a single GUI and several cores (Axiom, GAP,
>> whatever).
>
> Because those systems, fundamentally, are not designed to work
> together.  I admire the SAGE effort and I think it will be very useful,
> but GAP (for example) doesn't share Axiom's type system and so there is
> an impediance mismatch between the two systems.  What assumptions is
> GAP making that Axiom doesn't know about when it solves a problem, and
> are those assumptions ones that are compatible with the ones we would
> make?  Does a function name or even a property name mean the same thing
> between the two systems?  If we evolve towards proving algorithms, how
> do we prove an algorithm used in GAP without doing enough work to go
> ahead and implement it in Axiom anyway?  
Just because you use two CASs from the same GUI doesn't imply that
they'll have to work together. In my Emacs I use Common Lisp and
Haskell, which don't understand each other either. On the other hand
this whole point isn't that important, so let's ignore it for now.

>> PS: I don't mean to say that there shouldn't be a nice, downloadable
>> package on Axiom's website featuring a specific GUI. What I'm after
>> is independence. Axiom's main branch should contain no GUI-related
>> code other than the implementation of the Axiom<->GUI protocol.
>  
> Well, maybe.  But I think there should be an axiom-gui tree as well
> that has the "official" Axiom GUI, which the Axiom project keeps in
> sync with any changes to the Axiom core.  And when we build the
That would mean that not all GUIs are created equal. There will always
be tricks the official GUI can do, that other GUIs aren't capable
of. If the Axiom core has a new feature that requires it to break
compatibility with older GUI versions, will the release of that feature
have to wait for the official GUI to catch up? Even if alternative
GUIs already support it?

> complete "system" we should build axiom-gui as well.  We already build
> the Hyperdoc program, after all, and that is part of the default
> system.  I'd rather have axiom-gui as a directory in the toplevel axiom
> branch, and have a ./configure --without-gui option if one doesn't want
> it.  When I type .configure  make  make install and then run "axiom" I
> would kind of expect the GUI to be the default.
In my view the GUI should take care of presenting the documentation as
well. No separate HyperDoc program. Of course, nothing stops you from
building a terminal-like UI and supply a separate HyperDoc with that.


I have the impression that there are quite a few things that we just
won't agree on. Since my arguments are often based on speculation I'm
not really willing to push them much harder. Maybe we could instead
try to find a common ground. How about the following:

1) In the Axiom core we create one or more additional Lisp packages
   (in the DEFPACKAGE sense) that provide an API for all the services
   that a GUI needs/wants/whatever.

   The most important feature would probably be to get the output from
   textual chatter to something with more structure.

2) We add a *small* and *simple* piece of code that exports that API
   over a socket interface. We also add a commandline option to enable
   this feature/configure the port/etc.


\start
Date: 08 Sep 2006 16:25:48 +0200
From: Martin Rubey
To: Kai Kaminski
Subject: Re: A Canonical Axiom GUI

Kai Kaminski writes:

Good to see you here!

> 1) In the Axiom core we create one or more additional Lisp packages
>    (in the DEFPACKAGE sense) that provide an API for all the services
>    that a GUI needs/wants/whatever.
> 
>    The most important feature would probably be to get the output from
>    textual chatter to something with more structure.

For display only I think there are three possibilities:

* use OutputForm directly

* use TEX

* create a domain like TEX that takes something in OutputFrom and converts it
  to whatever you want

For input and reusing output you should probably extend INFORM. If the type of
a result of a computation doesn't have INFORM, you should complain to the
author of the domain, or realize that it would be very very hard to come up
with an INFORM.

To obtain the domain of computation 101 you can use domainOf(%%(101))

And I still strongly believe that it would be wise to extend Ralf's ALLPROSE to
become a full-featured GUI. You really should look at the stuff tex4ht
produces, i.e., try

make html

in any ALLPROSE project (for example MyAlps, that comes with the ALLPROSE
distribution)

(you have to have tex4ht installed, of course)

\start
Date: Fri, 8 Sep 2006 10:55:43 -0400
From: Bill Page
To: Gabriel Dos Reis, Tim Daly
Subject: RE: Build-improvements - noweb required?
Cc: Waldek Hebisch

Tim, did you change the password on the 'Axiom-testresults'
email list?

Gaby, I have seen this same problem recently while trying
build.improvements on various machines on the SourceForge compile
farm and on my own hardware. I recall that you said that the
branch would be "broken" for a while since you were in the
process of making even more radical improvements, so I did
not mention it yet.

As a work-a-round it seems to be possible to specify

  make noweb

to force noweb to be built first.

On September 8, 2006 7:20 AM Gabriel Dos Reis wrote:
> 
> Waldek Hebisch writes:
> 
> | Done that and got:
> 
> Thanks!
> 
> | > Your mail to 'Axiom-testresults' with the subject
> | >
> | >     Build failure without noweb
> | 
> | > Is being held until the list moderator can review it for
> | > approval.
> | >
> | > The reason it is being held:
> | >
> | >     Post by non-member to a members-only list
> | 
> | Hope you can see it.

The reason why Waldek Hebisch's message was held is simply because he
is not subscribed to the 'Axiom-testresults' email list. Because spam
is such a terrible problem on these lists, requiring user registration
is the only way to prevent abuse. The list manager software has an option
to bounce email from non-subscribers to the list administrator. I look
after the axiom-developer, axiom-mail, axiom-legal, and axiom-math lists.
We get several hundred spam messages a day to these lists!

> Tim, I don't have admin privilege for mailing lists; can you look into
> this, please?

You are listed as a full project administrator for Axiom on Sourceforge:

Project Administrators:

Bill Page 		billpage
Tim Daly 		daly
Gabriel Dos Reis 	dos-reis

with the same rights as both Tim and I:

Id 		CVS	SVN	Shell	Rel	Snap	Track	For 	Doc.
News 	Screen
billpage	Yes 	Yes 	Yes 	Yes 	Yes 	A 	Mod 	Ed
Ed 	Ed
daly		Yes 	Yes 	Yes 	Yes 	Yes 	A 	Mod 	Ed
Ed 	Ed
dos-reis	Yes 	Yes 	Yes 	Yes 	Yes 	A 	Mod 	Ed
Ed 	Ed

At http://sourceforge.net/project/admin/?group_id=48359

after logging in you should see:

Your Permissions:

  You are listed as a project administrator for this project.
  You can perform ALL project operations.

If not, let me know.

axiom-testresults@lists.sf.net is an email list. So go here:

http://sourceforge.net/project/admin/lists_forums.php?group_id=48359

or more specifically:

http://sourceforge.net/mail/admin/index.php?group_id=48359&change_status=1

and then on to

https://lists.sourceforge.net/lists/admin/axiom-testresults

to change list options. Here you get stopped unless you know

'List Administrator Password'

I thought this password was the same as the other lists, but I just
tried it and it doesn't work, so I guess not. :( The password can be
easily changed by any one of us, but it wasn't me. Tim?

Anyway, once you get there, on the above page you can set the
options so that you will receive bounce messages from postings by
non-subscribers to this list. That will allow you to intercept
and approve messages such as the one from Waldek.

Let me know if you have any problems with this.

\start
Date: Fri, 8 Sep 2006 10:16:46 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: Build-improvements - noweb required?
Cc: Waldek Hebisch

On Fri, 8 Sep 2006, Bill Page wrote:

| Tim, did you change the password on the 'Axiom-testresults'
| email list?

I don't know what it is.

| Gaby, I have seen this same problem recently while trying
| build.improvements on various machines on the SourceForge compile
| farm and on my own hardware. I recall that you said that the
| branch would be "broken" for a while since you were in the
| process of making even more radical improvements, so I did
| not mention it yet.

yes, on my TODO list it is not supposed to last -- but, hey smester
starts and things get longer to be done than planed.  But, on my local
tree, all of the breakage I know of are fixed.  I hope to do a "fix"
commit today (late).

| As a work-a-round it seems to be possible to specify
|
|   make noweb
|
| to force noweb to be built first.

that is then a real breakage I have not seen.  Thanks for pointing out.

[...]

| > | Hope you can see it.
|
| The reason why Waldek Hebisch's message was held is simply because he
| is not subscribed to the 'Axiom-testresults' email list.

I would like to see the Axiom-testresults list require less stringent
subscription rules.  It is there for encouraging people to send build
logs, test results for Axiom -- they are not required  to read or
receive message from that list.  It is mainly useful for us
developers.  I understand the spam issue; I feel there ought to be a
way to handle it without requiring people to subscribe.  At GCC, we
manage to have all lists (except gcc-announces) freely open to people,
yet the spam rate is very very low.

 Because spam
| is such a terrible problem on these lists, requiring user registration
| is the only way to prevent abuse. The list manager software has an option
| to bounce email from non-subscribers to the list administrator. I look
| after the axiom-developer, axiom-mail, axiom-legal, and axiom-math lists.
| We get several hundred spam messages a day to these lists!
|
| > Tim, I don't have admin privilege for mailing lists; can you look into
| > this, please?
|
| You are listed as a full project administrator for Axiom on Sourceforge:

yes, but last time I wanted to approve my own message (from my TAMU
account), I was told (by the list manager) that only tim has an admin
privilege and knows what the passowrd is.  I should have made that
point earlier.

[...]

| to change list options. Here you get stopped unless you know
|
| 'List Administrator Password'
|
| I thought this password was the same as the other lists, but I just
| tried it and it doesn't work, so I guess not. :( The password can be
| easily changed by any one of us, but it wasn't me. Tim?

and I don't know what others are.

\start
Date: 08 Sep 2006 12:15:13 -0400
From: Camm Maguire
To: Waqar Malik
Subject: Re: [SAGEdev] Xcode and Fink (was: Hopefully stupid question)
Cc: Aurelien Chanudet

Waqar Malik writes:

> On Sep 7, 2006, at 3:58 PM, Camm Maguire wrote:
> 
> > Greetings!  I take it this discussion is regarding OSX support.
> > Great!
> >
> > If memory serves, one of the gcl developers got this working with a
> > more recent release.  Am cc'ing him in hope he might have some
> > comment/be able to offer help.
> >
> > Supposedly, 2.6.8pre compiles on OSX 'out of the box' -- at least the
> > ACL2 people have told me it worked for them.
> >
> 	So that means we need to bump the port to the latest source
> and take  it from there. I just tried to compile GCL 2.6.6 and 2.6.7
> on 10.4.7  and it failed, I will see what is going on and at least
> update the  port to build correctly.
> 

One thing I would suggest is a simple ./configure && make using cvs
branch 2.6.8pre.  Same should work for 2.6.7 if memory serves.  2.6.8
is (hopefully) days away, and just awaits a few more Debian
autobuilders.  

Also wanted to mention that there is still one important GCL feature
missing on this port, stratified garbage collection, or SGC, which
relies on trapping addresses from segfaults caused by write attempts
to read only pages as a GC accelerator.  Aurelien had this working at
one point, then something changed with some macosx release, so it is
currently disabled.  Would be great to resolve this.  I can offer
email help if desired.

Take care,

> > Never understood the relationship between fink, darwinports, and
> > macports ...
> >
> 	DarwinPorts was renamed to MacPorts after recent shutdown of
> the  OpenDarwin. Fink is a separate porting environment. You only need
> one  or the other, they pretty much do the same thing. There might be
> differences in number and kind of ports.
> 
> 
> > There are OSX specific bfd patches in the gcl source tree.  It would
> > be wonderful to get these accepted into binutils upstream someday -- I
> > haven't gotten around to asking about it.
> >
> > Take care,
> >
> > Waqar Malik writes:
> >
> >> Ok, I looked at the page, and to build it seems pretty simple, since
> >> it uses configure script., If you want to you can install MacPorts
> >> and install gcl and try to build axiom on the mac and see if it
> >> builds.
> >> I will give it a try later today, as I have class that I need to
> >> attend this morning.
> >>
> >> --Waqar
> >> On Sep 7, 2006, at 10:24 AM, Page, Bill wrote:
> >>
> >>> On Thursday, September 07, 2006 10:42 AM Waqar Malik wrote:
> >>>
> >>>> 	I be glad to help with Axiom, but I have not used
> >>>> Axiom, so I have not tried to compile it.
> >>>
> >>> Thank you, thank you!
> >>>
> >>> The main part of Axiom (the AXIOMsys computational "engine") is
> >>> built as a very large Lisp application on top of GCL plus a few
> >>> external subroutines written in C linked into the image.
> >>>
> >>> The two other main parts of Axiom: Hyperdoc and Graphics, run
> >>> as separate processes, are written entirely in C and communicate
> >>> with AXIOMsys via sockets.
> >>>
> >>>>
> >>>> Couple of things to remember about gcl port, I have not updated
> >>>> to the latest release (2.6.7) and I have not compiled it on
> >>>> Intel machines yet, I will have to spend some time to verify
> >>>> that it works.
> >>>>
> >>>
> >>> It should be possible to build Axiom using the older version
> >>> of GCL.
> >>>
> >>> Anything you can do to help us with this would be greatly
> >>> appreciated! If you haven't already, you might want to visit
> >>> the Axiom developer website at
> >>>
> >>> http://wiki.axiom-developer.org
> >>>
> >>> to find out more about Axiom. If you have any questions and/or
> >>> suggestions, please let me know.

\start
Date: Fri, 8 Sep 2006 09:23:38 -0700 (PDT)
From: Cliff Yapp
To: Kai Kaminski
Subject: Re: A Canonical Axiom GUI

--- Kai Kaminski wrote:
> > What we should expose to GUIs and how is probably somewhat
> > separate from how the GUIs use that information. The
> > latter is usually where most of the trouble comes in :-).
>
> It is indeed very different. Of course, the former should be guided
> by the latter. Since we don't really know what a great GUI should
> look like, we'll have to take some educated guesses and then wait for
> feedback.

Right.  I think we probably can make a reasonable guess though.

> > 1.  2-D interactive mathematical display and formatting, 
> > particularly line breaking and font interactions.  Probably the 
> > hardest single part.
>
> This is of interest to other people as well
> (eg. cl-typesetting). Thus it should be done in a separate general
> purpose library (eg. cl-typesetting).

I think we will probably need to be involved with that, but we will
see.

> > 2.  2 and 3-D plotting, interactive manipulation, etc.  IZIC has 
> > done some work that I like, and VTK is also very nice - adapting
> > those ideas and some work that has been done on how to do high
> > quality mathematical plotting is probably the second hardest part,
> > or even hardest if we also cover the core algorithms for graphical
> > display and manipulation ourselves.
>
> That's been done for other languages already. It would be cool to
> have a flexible plotting library in Lisp. But it's a waste of time
> write now. There are good offerings in other languages, so just use
> them. The Python Matplotlib source is about 30,000 lines, if I
> recall correctly. Do you really want to recreate that effort for the
> sake of purity? I don't.

Eventually, yes I do.  Existing work should be used as a guide, but I
think the eventual goal should be a plotting library so
good/robust/capable that it makes no sense to use anything else.  I
agree right now it is not a priority.

> > That's why I prefer we have our own, that takes good ideas wherever
> > they are found and incorporates them.
>
> And is always last on new developments, and looks like a random 
> collection of CAS GUI features.

I didn't say ONLY incorporated other ideas, or to incorporate all ideas
willy nilly.  Plus, how many really new features have appeared in CAS
work over the last 20 years?

> If the Axiom core has a new feature that requires it to break
> compatibility with older GUI versions, will the release of that 
> feature have to wait for the official GUI to catch up? Even if
> alternative GUIs already support it?

I would argue yes.  I think once we become a mature project the GUI
should be as much a part of providing a good environment as good
documentation.  I can see your point, but how often would such a change
happen in a major way that would break the official GUI and still allow
alternative GUIs to support it faster than the official one? 
Particularly if both the API and the GUI itself are well designed.

> I have the impression that there are quite a few things that we just
> won't agree on. 

Seems like it. :-)

> Since my arguments are often based on speculation I'm
> not really willing to push them much harder. Maybe we could
> instead try to find a common ground.

Logical and reasonable.

> How about the following:
>
> 1) In the Axiom core we create one or more additional Lisp packages
> (in the DEFPACKAGE sense) that provide an API for all the services
> that a GUI needs/wants/whatever.

Makes sense to me.  I would prefer to see Axiom make much better use of
the package system in Lisp, but apparently that will require some
design consideration since the original development pre-dates the
advent of common lisp packages.

> The most important feature would probably be to get the output from
> textual chatter to something with more structure.

Yes.

> 2) We add a *small* and *simple* piece of code that exports that API
>  over a socket interface. We also add a commandline option to enable
>  this feature/configure the port/etc.

Definitely.

\start
Date: Fri, 8 Sep 2006 14:12:45 -0400
From: Tim Daly
To: list
Subject: Tectonic shift
Cc: Kai Kaminski

GUI issues are fine but unrelated to my original goal.

I see a tectonic shift in the computational math area (at least
from my limited view of the world).

There is a rising tide of discrete and computational geometry,
indeed a rise of geometric rather than algebraic approaches
that I see.

Axiom does not have any of the computational algebra support
and I've been pondering ways to address this.

Along the way the issue arises about how to handle the graphics.
Currently the graphics does not really support concepts like
infinite tilings. You could do this in a pointwise manner but
shouldn't have to do that.




Additionally I have another area which I see nowhere else
which is visual support for algorithms and data structures.

I want to be able to define an isomorphism between a data structure
and a graph and have that automatically displayed and updated.

For example, a list object and a tree structured graph so that
changges to the list modify the tree picture BUT ALSO changes
to the tree picture modify the list structure in memory. Thus you
would be able to manipulate your program from the graphics.

These abilities would be so much easier to construct if they
were implemented in common lisp and running as axiom programs.




So I'm looking for a lisp package that can draw colored lines
(of which colored points are a subset) in a window. IF I can
get both input and output thru the window I can build the
ideas envisioned above.

\start
Date: Sat, 9 Sep 2006 11:13:12 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: Build-improvements - noweb required?
Cc: Waldek Hebisch, Gabriel Dos Reis

Bill Page wrote:
> Gaby, I have seen this same problem recently while trying
> build.improvements on various machines on the SourceForge compile
> farm and on my own hardware. I recall that you said that the
> branch would be "broken" for a while since you were in the
> process of making even more radical improvements, so I did
> not mention it yet.
> 
> As a work-a-round it seems to be possible to specify
> 
>   make noweb
> 
> to force noweb to be built first.
>
 
I tried that, however still a lot of breakage remains:

1) `TANGLE' and `WEAVE' in the main makefile remain unset (I changed
    them by hand to `notangle' and `noweave')

2) in `document' script the `tangle' and `weave' variables are unset
   changing their value to `$TANGLE' and `$WEAVE' does not help (I set
   them to `notangle' and `noweave')

3) in interp directory build fails at first step -- again looks like
   unset `$TANGLE' is unset (missing export somewhere ???)

\start
Date: 09 Sep 2006 17:06:32 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Build-improvements - config.log

[...]

| configure:2934: checking for notangle
| configure:2963: result: no
| configure:2969: checking for noweave
| configure:2998: result: no

configure detects that noweb is missing.  That is fine.

[...]

| NOTANGLE=''
| NOWEAVE=''

However, this is not right.  It is the consequence of a bogus logic I
knew of but failed to fix before commit. 
It is now fixed.  Sorry for that.

\start
Date: Sun, 10 Sep 2006 04:19:57 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Build-improvements - config.log
Cc: Waldek Hebisch

> It is now fixed.  Sorry for that.

Thanks. Now build go further, but stops when building algebra:

....
=====================================
=== algebra bootstrap complete ======
=====================================
compiling AHYP.spad to AHYP.NRLIB
AHYP.NRLIB/AHYP.c:2:24: error: cmpinclude.h: Nie ma takiego pliku ani katalogu
In file included from AHYP.NRLIB/AHYP.c:3:
AHYP.NRLIB/AHYP.h:4: error: syntax error before 'LI2'
AHYP.NRLIB/AHYP.h:19: error: syntax error before 'LnkTLI5'
....

Debian gcl is installed on the machine:

hebisch@studentka:/home/s/test/tt/axiom3/build-improvements$ gcl
GCL (GNU Common Lisp)  2.6.7 CLtL1    Dec 19 2005 02:59:03
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

>

cmpinclude.h is present in /usr/lib/gcl-2.6.7/h	

\start
Date: Sat, 9 Sep 2006 21:25:42 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Build-improvements - config.log

On Sun, 10 Sep 2006, Waldek Hebisch wrote:

| > It is now fixed.  Sorry for that.
|
| Thanks. Now build go further, but stops when building algebra:
|
| ....
| =====================================
| === algebra bootstrap complete ======
| =====================================
| compiling AHYP.spad to AHYP.NRLIB
| AHYP.NRLIB/AHYP.c:2:24: error: cmpinclude.h: Nie ma takiego pliku ani katalogu
| In file included from AHYP.NRLIB/AHYP.c:3:
| AHYP.NRLIB/AHYP.h:4: error: syntax error before 'LI2'
| AHYP.NRLIB/AHYP.h:19: error: syntax error before 'LnkTLI5'
| ....
|
| Debian gcl is installed on the machine:
|
| hebisch@studentka:/home/s/test/tt/axiom3/build-improvements$ gcl
| GCL (GNU Common Lisp)  2.6.7 CLtL1    Dec 19 2005 02:59:03
| Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
| Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
| Modifications of this banner must retain notice of a compatible license
| Dedicated to the memory of W. Schelter
|
| Use (help) to get some basic information on how to use GCL.
|
| >
|
| cmpinclude.h is present in /usr/lib/gcl-2.6.7/h

Indeed.  That is a known bug with GCL :-(
I had a fix for Axiom in one of my many local trees and I can't find
right now. To prevent Axiom from using the system-installed GCL, you
might want to add --without-gcl when configuring Axiom.

The above GCL bug is quite intriguing and curious.  I hope to have a
fix for it before 2.6.8 is shipped.

\start
Date: 09 Sep 2006 22:51:41 -0500
From: Gabriel Dos Reis
To: list
Subject: DeveloperNotes.pamphlet

Has anyone run that file successfully through latex?

\start
Date: Sun, 10 Sep 2006 05:53:07 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Build-improvements --witout-gcl
Cc: Waldek Hebisch

> On Sun, 10 Sep 2006, Waldek Hebisch wrote:
> 
> | > It is now fixed.  Sorry for that.
> |
> | Thanks. Now build go further, but stops when building algebra:
> |
> | ....
> | =====================================
> | === algebra bootstrap complete ======
> | =====================================
> | compiling AHYP.spad to AHYP.NRLIB
> | AHYP.NRLIB/AHYP.c:2:24: error: cmpinclude.h: Nie ma takiego pliku ani katalogu
> | In file included from AHYP.NRLIB/AHYP.c:3:
> | AHYP.NRLIB/AHYP.h:4: error: syntax error before 'LI2'
> | AHYP.NRLIB/AHYP.h:19: error: syntax error before 'LnkTLI5'
> | ....
> |
> | Debian gcl is installed on the machine:
> |
> | hebisch@studentka:/home/s/test/tt/axiom3/build-improvements$ gcl
> | GCL (GNU Common Lisp)  2.6.7 CLtL1    Dec 19 2005 02:59:03
> | Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> | Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
> | Modifications of this banner must retain notice of a compatible license
> | Dedicated to the memory of W. Schelter
> |
> | Use (help) to get some basic information on how to use GCL.
> |
> | >
> |
> | cmpinclude.h is present in /usr/lib/gcl-2.6.7/h
> 
> Indeed.  That is a known bug with GCL :-(
> I had a fix for Axiom in one of my many local trees and I can't find
> right now. To prevent Axiom from using the system-installed GCL, you
> might want to add --without-gcl when configuring Axiom.
> 

Tried build using --without-gcl. Now build fails much earlier:

gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/home/s/test/tt/axiom4/build-improvements/lsp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c
fat_string.c:17:17: error: bfd.h: Nie ma takiego pliku ani katalogu
fat_string.c:18:21: error: bfdlink.h: Nie ma takiego pliku ani katalogu
fat_string.c:231: error: syntax error before 'bfd_combined_table_update'
fat_string.c:231: error: syntax error before 'PTR'


BFD library is not installed on the build machine. From gcl configure log:

...
checking for bfd.h... no
checking for useable bfd_boolean... no
Guessing path to libbfd.a due to gcc bug
...

\start
Date: Sat, 9 Sep 2006 23:05:46 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Build-improvements --witout-gcl

On Sun, 10 Sep 2006, Waldek Hebisch wrote:

[...]

| Tried build using --without-gcl. Now build fails much earlier:
|
| gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/home/s/test/tt/axiom4/build-improvements/lsp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c
| fat_string.c:17:17: error: bfd.h: Nie ma takiego pliku ani katalogu
| fat_string.c:18:21: error: bfdlink.h: Nie ma takiego pliku ani katalogu
| fat_string.c:231: error: syntax error before 'bfd_combined_table_update'
| fat_string.c:231: error: syntax error before 'PTR'
|
|
| BFD library is not installed on the build machine. From gcl configure log:
|
| ...
| checking for bfd.h... no
| checking for useable bfd_boolean... no
| Guessing path to libbfd.a due to gcc bug
| ...


I saw similar failure earlier today:

  http://sourceforge.net/mailarchive/forum.php?thread_id=30503449&forum_id=49144

on a debian system.

It seems I have no choice but to locate the fix that allowed
the system-installed GCL to find its own include header.

Many thanks for your patience and help.  I'll keep you updated.

\start
Date: Sun, 10 Sep 2006 11:13:52 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: DeveloperNotes.pamphlet

On 09/10/2006 05:51 AM, Gabriel Dos Reis wrote:
> Has anyone run that file successfully through latex?
> 
> -- Gaby

I would very much prefer, if everyone includes the FULL path to a file 
and in which branch and what revision it actually is. How should I know 
that all these files are identical???

Anyway, you don't describe the problem you have, so I cannot help you. 
The only thing I can do is, how I can translate it.

cd Silver/branches/build-improvements/src/doc
svn update
#At revision 125.
cp axiom.sty.pamphlet DeveloperNotes.pamphlet ~/scratch
cd ~/scratch
notangle -Raxiom.sty axiom.sty.pamphlet > axiom.sty
noweave -n -delay DeveloperNotes.pamphlet > DN.tex
latex DN.tex

So what exactly is your problem???

\start
Date: Sun, 10 Sep 2006 12:16:32 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: DeveloperNotes.pamphlet

Hello,

I have just realised that the file src/doc/axiom.sty.pamphlet 
(build-improvements) contains noweb.sty in full. A quick look at it lets 
me guess that only a few lines at the end of the pamphlet is actually 
making the difference to noweb.sty. The other things are probably taken 
to be some (fixed) version (not documented which one) of noweb.sty.nw.

Since we are going to make noweb a dependence also axiom.sty.pamphlet 
should remove the noweb related code and has it replaced by

\usepackage{noweb}

Otherwise, we might run into trouble with newer versions of noweb and 
incompatible changes to noweb.sty.

Ralf

On 09/10/2006 05:51 AM, Gabriel Dos Reis wrote:
> Has anyone run that file successfully through latex?

\start
Date: Sun, 10 Sep 2006 07:08:53 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: DeveloperNotes.pamphlet
Cc: Gabriel Dos Reis

> I have just realised that the file src/doc/axiom.sty.pamphlet 
> (build-improvements) contains noweb.sty in full. A quick look at it lets 
> me guess that only a few lines at the end of the pamphlet is actually 
> making the difference to noweb.sty. The other things are probably taken 
> to be some (fixed) version (not documented which one) of noweb.sty.nw.

The exact version of axiom--main--1--patch-50 is noweb-2.10a.tgz
This is the version in the zips directory. 




> Since we are going to make noweb a dependence also axiom.sty.pamphlet 
> should remove the noweb related code and has it replaced by
> 
> \usepackage{noweb}
> 
> Otherwise, we might run into trouble with newer versions of noweb and 
> incompatible changes to noweb.sty.

There are axiom-specific latex tags. This is likely to increase
rather than decrease. This should be expected as we depend more
on latex as our tool. For instance, I have an as-yet-unpublished 
tag set that removes the use of

  <<randomchunck>>=

and replaces it with latex syntax

  \begin{chunk}{randomchunk}




The axiom.sty is intended to ensure that we can correctly and
consistently translate axiom pamphlet files. This is similar
to the policy of places like the AMS or Universities creating
their own style files.

\start
Date: Sun, 10 Sep 2006 06:35:02 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Ralf Hemmecke
Subject: \begin{chunk}
Cc: Gabriel Dos Reis

--- Tim Daly wrote:

> There are axiom-specific latex tags. This is likely to increase
> rather than decrease. This should be expected as we depend more
> on latex as our tool. For instance, I have an as-yet-unpublished 
> tag set that removes the use of
> 
>   <<randomchunck>>=
> 
> and replaces it with latex syntax
> 
>   \begin{chunk}{randomchunk}

Tim, when do you plan to make this change?  I realize it can be
(almost) automated but it would be nice to have that style going
forward, if that's our final target.  I've been working with auctex and
mmm-mode trying to convince auctex to quit using code chunks when it
does its fontifying of the latex part of the document.  Also, if we use
\begin{chunk} mmm-mode (which handles the dual-mode part of things)
will need to be taught how to recognize the new environment.  (I know
you don't need or use these, but for us mortals they are kind of nice
;-).  If that change is coming soon I should probably focus on the
\begin{chunk} syntax (which is probably somewhat simpler to deal with
anyway).

Also, one idea I want to mention now while there is still time to
consider it - would it be difficult to have an optional tag for a chunk
name identifying what language the code chunk is written in?  I ask
because for a number of applications (emacs mode mapping, syntax
highlighting in LaTeX using a package whose name escapes me at the
moment) it would be nice to know what language the chunk is.  Normally
a file is foo.lisp.pamphlet which works if all of the code chunks in
that file are lisp, but I know some pamphlets aren't like this.   Would
it be possible to specify a language (something like
\begin{chunk}{randomchunk}{boot} in a file.lisp.pamphlet file, for
example) so it is unambiguous and simple to determine how to deal with
it?

> The axiom.sty is intended to ensure that we can correctly and
> consistently translate axiom pamphlet files. This is similar
> to the policy of places like the AMS or Universities creating
> their own style files.

I have to say I tend to agree with this one.  We can examine new
features as they are introduced and see what the impact would be in
including them with Axiom, but I think a layer if insulation between
Axiom and those changes is probably a good thing.

\start
Date: Sun, 10 Sep 2006 09:32:00 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: \begin{chunk}
Cc: Gabriel Dos Reis

> > There are axiom-specific latex tags. This is likely to increase
> > rather than decrease. This should be expected as we depend more
> > on latex as our tool. For instance, I have an as-yet-unpublished 
> > tag set that removes the use of
> > 
> >   <<randomchunck>>=
> > 
> > and replaces it with latex syntax
> > 
> >   \begin{chunk}{randomchunk}
> 
> Tim, when do you plan to make this change?  I realize it can be
> (almost) automated but it would be nice to have that style going
> forward, if that's our final target.  I've been working with auctex and
> mmm-mode trying to convince auctex to quit using code chunks when it
> does its fontifying of the latex part of the document.  Also, if we use
> \begin{chunk} mmm-mode (which handles the dual-mode part of things)
> will need to be taught how to recognize the new environment.  (I know
> you don't need or use these, but for us mortals they are kind of nice
> ;-).  If that change is coming soon I should probably focus on the
> \begin{chunk} syntax (which is probably somewhat simpler to deal with
> anyway).

The change will probably come about once I figure out all the
details of 'environments', which is fairly hairy. TeX is not the
easiest language to learn. I wouldn't worry about the change.



> Also, one idea I want to mention now while there is still time to
> consider it - would it be difficult to have an optional tag for a chunk
> name identifying what language the code chunk is written in?  I ask
> because for a number of applications (emacs mode mapping, syntax
> highlighting in LaTeX using a package whose name escapes me at the
> moment) it would be nice to know what language the chunk is.  Normally
> a file is foo.lisp.pamphlet which works if all of the code chunks in
> that file are lisp, but I know some pamphlets aren't like this.   Would
> it be possible to specify a language (something like
> \begin{chunk}{randomchunk}{boot} in a file.lisp.pamphlet file, for
> example) so it is unambiguous and simple to determine how to deal with
> it?

ummm, I'm unsure of how to handle optional tags in environments
but I'll keep it on the design list.

\start
Date: Sun, 10 Sep 2006 16:09:04 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: \begin{chunk}
Cc: Gabriel Dos Reis

On 09/10/2006 03:32 PM, root wrote:
>>> There are axiom-specific latex tags. This is likely to increase 
>>> rather than decrease. This should be expected as we depend more 
>>> on latex as our tool. For instance, I have an as-yet-unpublished
>>>  tag set that removes the use of
>>> 
>>> <<randomchunck>>=
>>> 
>>> and replaces it with latex syntax
>>> 
>>> \begin{chunk}{randomchunk}

Before you don't show a .sty file, I hope that syntax change will not
happen. ;-)

>> Tim, when do you plan to make this change?  I realize it can be 
>> (almost) automated but it would be nice to have that style going 
>> forward, if that's our final target.  I've been working with auctex
>> and mmm-mode trying to convince auctex to quit using code chunks
>> when it does its fontifying of the latex part of the document.
>> Also, if we use \begin{chunk} mmm-mode (which handles the dual-mode
>> part of things) will need to be taught how to recognize the new
>> environment.

Exactly. If Tim changes the syntax without giving us the nice tools we
have NOW, that would be a step back.

> The change will probably come about once I figure out all the details
> of 'environments', which is fairly hairy. TeX is not the easiest
> language to learn. I wouldn't worry about the change.

Well, if you considered LaTeX that is probably totally easy. Build on
the fancyvrb package and you have what you want in a couple of minutes.
There is also the "listings" LaTeX package which should be considered.

>> Also, one idea I want to mention now while there is still time to 
>> consider it - would it be difficult to have an optional tag for a
>> chunk name identifying what language the code chunk is written in?
>> I ask because for a number of applications (emacs mode mapping,
>> syntax highlighting in LaTeX using a package whose name escapes me
>> at the moment) it would be nice to know what language the chunk is.
>> 
Well, if Cliff wants several languages in one file, then an optional
argument is a good idea. Again, an optional argument to an environment
is easy in LaTeX. However, I am not so sure why I would want several
languages in one file. Cliff, do you intend to mix your Aldor files with
LISP code? Brrrrhhh.

Maybe you have also realised that noweb offers a way to make clickable 
code out of the code chunks. See the ALLPROSE documentation. I am 
heavily using it. It seems that nobody has considered that feature of 
noweb for use in Axiom pamphlets.

So BEFORE you make the change to a new syntax, think twice about what 
you will be missing afterwards. If it is then impossible to link produce 
a link from one identifier in a code chunk to its definition, then I am 
strongly AGAINST that change. And note you would have to program all 
that in LaTeX (or depend on the listings package or something the like 
and add a few LaTeX lines). I don't think that this can happen in just a 
few days if you want all the features that noweb has NOW.

The other thing is that there seems to be too much manpower for Axiom 
that people think about that syntax change. I guess writing in noweb and 
having a little script later that translates the <<...>> syntax into a 
LaTeX-like syntax automatically, is probably an easy thing. But we 
should focus on more urgent matters. Noweb syntax isn't too hard to learn.

Do whatever you like. It is open source after all. But I am really not 
convinced that a syntax change should happen now.

\start
Date: Sun, 10 Sep 2006 09:14:59 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: DeveloperNotes.pamphlet

On Sun, 10 Sep 2006, Ralf Hemmecke wrote:

| On 09/10/2006 05:51 AM, Gabriel Dos Reis wrote:
| > Has anyone run that file successfully through latex?
| >
| > -- Gaby
|
| I would very much prefer, if everyone includes the FULL path to a file
| and in which branch and what revision it actually is. How should I know
| that all these files are identical???

I'm talking of the file src/doc/DeveloperNotes.pamphlet.

To date Tim uses ${DOCUMENT} to latex the files; but he does ignore
any errors that might come out of the latexing process -- which gives
everybpdy the sensation that every is fine.

I've modified that file (on build-improvements) to take into account
the exit status of latex and the makefiles do now take it into
account.  The consequences is that it exposes few cases where the
typesetting process is not OK.  The above mentioned file is one of
them.  In particular is contains in various places characters '$', '#'
un-escaped, enclosed in [[ ]].  It also contains things like

   [[./lib/htrefs]]\\
   [[./lib/htsearch]]\\
   [[./lib/hthits]]


which confuses latex in many places.  etc.

My question was whether anybody actually tried to typeset that file
successfully.

\start
Date: Sun, 10 Sep 2006 09:16:58 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: DeveloperNotes.pamphlet

On Sun, 10 Sep 2006, root wrote:

| > I have just realised that the file src/doc/axiom.sty.pamphlet
| > (build-improvements) contains noweb.sty in full. A quick look at it lets
| > me guess that only a few lines at the end of the pamphlet is actually
| > making the difference to noweb.sty. The other things are probably taken
| > to be some (fixed) version (not documented which one) of noweb.sty.nw.
|
| The exact version of axiom--main--1--patch-50 is noweb-2.10a.tgz
| This is the version in the zips directory.

The issue is what do you do when people already have noweb installed.

\start
Date: Sun, 10 Sep 2006 10:22:06 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: DeveloperNotes.pamphlet

> | > I have just realised that the file src/doc/axiom.sty.pamphlet
> | > (build-improvements) contains noweb.sty in full. A quick look at it lets
> | > me guess that only a few lines at the end of the pamphlet is actually
> | > making the difference to noweb.sty. The other things are probably taken
> | > to be some (fixed) version (not documented which one) of noweb.sty.nw.
> |
> | The exact version of axiom--main--1--patch-50 is noweb-2.10a.tgz
> | This is the version in the zips directory.
> 
> The issue is what do you do when people already have noweb installed.

Since we don't use noweb.sty anywhere why is this an issue?

\start
Date: Sun, 10 Sep 2006 16:34:01 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: DeveloperNotes.pamphlet

[snip]

> I've modified that file (on build-improvements) to take into account
> the exit status of latex and the makefiles do now take it into
> account.  The consequences is that it exposes few cases where the
> typesetting process is not OK.  The above mentioned file is one of
> them.  In particular is contains in various places characters '$', '#'
> un-escaped, enclosed in [[ ]].  It also contains things like
> 
>    [[./lib/htrefs]]\\
>    [[./lib/htsearch]]\\
>    [[./lib/hthits]]

> which confuses latex in many places.  etc.

> My question was whether anybody actually tried to typeset that file
> successfully.

I haven't sent you the commands for nothing. Run them and you'll see 
that everything IS fine. DeveloperNotes.pamphlet is a noweb file, so you 
have to noweave it before running latex on it.

The [[...]] syntax is from noweb. A # there should be no problem. Take 
the follwoing file

%%%BEGIN aaa.pamphlet
This is a hash [[#]] and a dollar [[$]] sign.
%%%END aaa.pamphlet

Then say
noweave aaa.pamphlet > aaa.tex
latex aaa.tex

You should not get an error.

By the way, I rather think that latexing files should not be done by 
"document" but rather by some well designed Makefile logic. There is 
already something like that in ALLPROSE. Note that you don't know the 
number of times how often you need to run latex, but running latex 3 
times is often too much and sometimes you even have to run latex more 
than that. (There can even be cases where the output doesn't stabilise.)

\start
Date: Sun, 10 Sep 2006 16:37:11 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: DeveloperNotes.pamphlet
Cc: Gabriel Dos Reis

On 09/10/2006 04:22 PM, root wrote:
>> | > I have just realised that the file src/doc/axiom.sty.pamphlet
>> | > (build-improvements) contains noweb.sty in full. A quick look at it lets
>> | > me guess that only a few lines at the end of the pamphlet is actually
>> | > making the difference to noweb.sty. The other things are probably taken
>> | > to be some (fixed) version (not documented which one) of noweb.sty.nw.
>> |
>> | The exact version of axiom--main--1--patch-50 is noweb-2.10a.tgz
>> | This is the version in the zips directory.
>>
>> The issue is what do you do when people already have noweb installed.
> 
> Since we don't use noweb.sty anywhere why is this an issue?

Because, if Norman Ramsey decides to make a change in his program, he 
will probably adjust noweb.sty accordingly. If we still run an old copy 
(which is stored inside axiom.sty (so we are using noweb.sty)) then we 
are in trouble.

\start
Date: Sun, 10 Sep 2006 09:37:50 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: DeveloperNotes.pamphlet

On Sun, 10 Sep 2006, root wrote:

| > | > I have just realised that the file src/doc/axiom.sty.pamphlet
| > | > (build-improvements) contains noweb.sty in full. A quick look at it lets
| > | > me guess that only a few lines at the end of the pamphlet is actually
| > | > making the difference to noweb.sty. The other things are probably taken
| > | > to be some (fixed) version (not documented which one) of noweb.sty.nw.
| > |
| > | The exact version of axiom--main--1--patch-50 is noweb-2.10a.tgz
| > | This is the version in the zips directory.
| >
| > The issue is what do you do when people already have noweb installed.
|
| Since we don't use noweb.sty anywhere why is this an issue?

The claim was that:

 #  The other things are probably taken to be some (fixed) version (not
 #  documented which one) of noweb.sty.nw.


Now, if you base axiom.sty on some "fixed" version -- noweb-2.10a.tgz --
and the build does not use the noweb version from Axiom and the
suggestion was to say (see Ralf's message)

   \usepackage{noweb}

my question is then why is it excepted that all of that works at all?

\start
Date: Sun, 10 Sep 2006 09:42:40 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: DeveloperNotes.pamphlet

On Sun, 10 Sep 2006, Ralf Hemmecke wrote:

| [snip]
|
| > I've modified that file (on build-improvements) to take into account
| > the exit status of latex and the makefiles do now take it into
| > account.  The consequences is that it exposes few cases where the
| > typesetting process is not OK.  The above mentioned file is one of
| > them.  In particular is contains in various places characters '$', '#'
| > un-escaped, enclosed in [[ ]].  It also contains things like
| >
| >    [[./lib/htrefs]]\\
| >    [[./lib/htsearch]]\\
| >    [[./lib/hthits]]
|
| > which confuses latex in many places.  etc.
|
| > My question was whether anybody actually tried to typeset that file
| > successfully.
|
| I haven't sent you the commands for nothing.

You probably think I'm kidding and made this all out of the air?

| Run them and you'll see
| that everything IS fine. DeveloperNotes.pamphlet is a noweb file, so you
| have to noweave it before running latex on it.

I was NOT doing anything by hand till the build failed precisely on
that point.  Everything is done by the Makefiles which does
${DOCUMENT} them.

| The [[...]] syntax is from noweb.

yes, I know.  Thanks.

[...]

| By the way, I rather think that latexing files should not be done by
| "document" but rather by some well designed Makefile logic.

that is what they are if you have a look at the Makefiles.

\start
Date: Sun, 10 Sep 2006 16:59:05 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: DeveloperNotes.pamphlet

> | > My question was whether anybody actually tried to typeset that file
> | > successfully.
> |
> | I haven't sent you the commands for nothing.
> 
> You probably think I'm kidding and made this all out of the air?

I am sure you had an error, but you don't let people know exactly what 
the error message is. So I stop thinking about it.

And by the way. Recently, I was reporting a successful build of Axiom. 
 From that time there was still a DeveloperNotes.dvi existing. Are you 
saying that is wrong in some places?

If you want I'll sent it to you so that you could check.

\start
Date: Sun, 10 Sep 2006 10:56:50 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: DeveloperNotes.pamphlet

> | By the way, I rather think that latexing files should not be done by
> | "document" but rather by some well designed Makefile logic.
> 
> that is what they are if you have a look at the Makefiles.

The document command is similar in spirit to tar.
Tar handles additional features like gzip compression.

The document command is intended to collect the various ways
you might want to handle a pamphlet file (weave, tangle, 
drag-and-drop, pdf, etc). 

Document is to pamphlets as tar is to tar files.

In general the user will not have a makefile for any given
document file and will need a command to extract the file
in the necessary form.

\start
Date: Sun, 10 Sep 2006 10:41:20 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: DeveloperNotes.pamphlet

On Sun, 10 Sep 2006, Ralf Hemmecke wrote:

| And by the way. Recently, I was reporting a successful build of Axiom.

OK, that is good to know.

|  From that time there was still a DeveloperNotes.dvi existing. Are you
| saying that is wrong in some places?

I'll pose a bit and go back to dig where the real error started.
Obviously, I've been into this for too long to see what is hapening :-/

\start
Date: Sun, 10 Sep 2006 10:47:07 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: DeveloperNotes.pamphlet

On Sun, 10 Sep 2006, root wrote:

| > | By the way, I rather think that latexing files should not be done by
| > | "document" but rather by some well designed Makefile logic.
| >
| > that is what they are if you have a look at the Makefiles.
|
| The document command is similar in spirit to tar.

that is only remotely related to the problem I'm having, I think.

If you look at document on build-improvements, you'll see that it has
been augmented to allow finer grains. So your comparison is even more
accurate on build-improvements than on trunk :-).
[ I suspect that implements earlier discussions we have had and the
  improvements reflect what I needed. ]

Based on input from Ralf, I start suspecting mic-macs with the
axiom.sty and friends.

\start
Date: Sun, 10 Sep 2006 08:58:43 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke, Tim Daly
Subject: Re: \begin{chunk}
Cc: Gabriel Dos Reis

> There is also the "listings" LaTeX package which should be
> considered.

That was the one I was thinking of.  If we can have a "default"
language for a file based on the *.langtype.pamphlet motif and then
toggle the language of the chunk for special cases (hence the optional
parameter to specify the language) we could use listings to give us
some really excellent pamphlet typesetting.
 
> Well, if Cliff wants several languages in one file, then an optional
> argument is a good idea. Again, an optional argument to an
> environment is easy in LaTeX. However, I am not so sure why I would
> want several languages in one file. Cliff, do you intend to mix your
> Aldor files with LISP code? Brrrrhhh.

I would prefer not to.  But the early indications are that all of
interp is headed for bookvol5, which is currently a single file. 
Perhaps that will change, or the interp code will be all lisp?  If it
is unavoidable to have mixed code languages in one file, I do want to
make sure we can tell the listings package and mmm-mode what's going
on!

Also, if different files are eventually used in volumes, there will
probably be multiple languages in that situation.  We were looking at a
package a while back that might be able to actually do that - I didn't
get around to experimenting with it.

> Maybe you have also realised that noweb offers a way to make
> clickable code out of the code chunks. See the ALLPROSE
> documentation. I am heavily using it. It seems that nobody has
> considered that feature of noweb for use in Axiom pamphlets.

I took a stab at setting up allprose and didn't quite make it - I will
try again. 

> So BEFORE you make the change to a new syntax, think twice about what
> you will be missing afterwards. If it is then impossible to link
> produce a link from one identifier in a code chunk to its definition,
> then I am strongly AGAINST that change. And note you would have to
> program all  that in LaTeX (or depend on the listings package or
> something the like and add a few LaTeX lines). I don't think that
> this can happen in just a few days if you want all the features that
> noweb has NOW.

Correct me if I'm wrong, but I think the \begin{chunk}{chunkname}
syntax was intended to have the chunkname be mandatory.  Couldn't the
logic then remain the same and just go for {chunkname} as the target
instead of <<chunkname>>?  Perhaps even the chunk-within-chunk
insertion syntax of using the <<chunkname>> could be the same? e.g.

\begin{chunk}{Chunk1}
some code
\end{chunk}

\begin{chunk}{Chunk2}
some more code
\end{chunk}

\begin{chunk}{MasterChunk}
<<Chunk1>>
<<Chunk2>>
\end{chunk}
 
> The other thing is that there seems to be too much manpower for
> Axiom that people think about that syntax change. I guess writing in
> noweb and having a little script later that translates the <<...>>
> syntax into a LaTeX-like syntax automatically, is probably an easy
> thing. But we should focus on more urgent matters. Noweb syntax
> isn't too hard to learn.

No, it isn't.  But getting AucTeX to quit using $ inside code chunks
during it's fontification is not so easy, or maybe I'm just not doing
it right.  Does allprose fix this?

> Do whatever you like. It is open source after all. But I am really
> not convinced that a syntax change should happen now.

Tim said not to worry, so I won't ;-).  I just wanted to make sure we
didn't need to start working on mmm-mode now.

\start
Date: Sun, 10 Sep 2006 11:10:20 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: \begin{chunk}

On Sun, 10 Sep 2006, C Y wrote:

| --- Ralf Hemmecke wrote:
|
| > There is also the "listings" LaTeX package which should be
| > considered.
|
| That was the one I was thinking of.


yes, some of my colleagues use it.  Over the year, I've come to prefer
the package fancyvrb because it is very flexible and it gives me all I
want.

I really find the idea of singling out keywords very curious and
anti-abstraction.  All the examples in

  http://www.research.att.com/~bs/popl06.pdf

are typset with fancyvrb.

\start
Date: Sun, 10 Sep 2006 20:28:56 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: \begin{chunk}
Cc: Gabriel Dos Reis

>> Maybe you have also realised that noweb offers a way to make
>> clickable code out of the code chunks. See the ALLPROSE
>> documentation. I am heavily using it. It seems that nobody has
>> considered that feature of noweb for use in Axiom pamphlets.
> 
> I took a stab at setting up allprose and didn't quite make it - I will
> try again. 

I was referring to the "documentation". That exists as html.

You should definitely read chapter 9 "How to setup all features of 
ALLPROSE". And if you run into trouble just drop me a mail. I don't 
claim that the setup is fool proof. I'd like to have autoconf for 
ALLPROSE, too, but I'll wait until Gaby has setup and documented the 
stuff for Axiom, maybe then it is easier for me to add the autoconf stuff.

>> So BEFORE you make the change to a new syntax, think twice about what
>> you will be missing afterwards. If it is then impossible to link
>> produce a link from one identifier in a code chunk to its definition,
>> then I am strongly AGAINST that change. And note you would have to
>> program all  that in LaTeX (or depend on the listings package or
>> something the like and add a few LaTeX lines). I don't think that
>> this can happen in just a few days if you want all the features that
>> noweb has NOW.
> 
> Correct me if I'm wrong, but I think the \begin{chunk}{chunkname}
> syntax was intended to have the chunkname be mandatory.  Couldn't the
> logic then remain the same and just go for {chunkname} as the target
> instead of <<chunkname>>?  Perhaps even the chunk-within-chunk
> insertion syntax of using the <<chunkname>> could be the same? e.g.
> 
> \begin{chunk}{Chunk1}
> some code
> \end{chunk}
> 
> \begin{chunk}{Chunk2}
> some more code
> \end{chunk}
> 
> \begin{chunk}{MasterChunk}
> <<Chunk1>>
> <<Chunk2>>
> \end{chunk}

Oh, you should probably have written

\begin{chunk}{MasterChunk}
\use{Chunk1}
\use{Chunk2}
\end{chunk}

;-)

But you know that noweb can do stuff like

<<cat: CatA>>=
CatA: Category == ...
...
@ %def CatA

<<cat: DomainA>>=
DomainA: CatA == ...
...
@ %def DomainA

and noweave can make the CatA in the second chunk al link to the chunk 
that has the "%def CatA" attached. I think that the "listings" package 
can probably do similar things, but I am not sure whether it works over 
several chunks.

>> The other thing is that there seems to be too much manpower for
>> Axiom that people think about that syntax change. I guess writing in
>> noweb and having a little script later that translates the <<...>>
>> syntax into a LaTeX-like syntax automatically, is probably an easy
>> thing. But we should focus on more urgent matters. Noweb syntax
>> isn't too hard to learn.
> 
> No, it isn't.  But getting AucTeX to quit using $ inside code chunks
> during it's fontification is not so easy, or maybe I'm just not doing
> it right.  Does allprose fix this?

No, ALLPROSE does not add emacs support. That's something else. I also 
have this strange problem and add the moment for the places where the 
colours get wrong I add "%$" on a new line right after the closing @ of 
a chunk.

\start
Date: 10 Sep 2006 14:18:03 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: DeveloperNotes.pamphlet

Putting the developer notes aside, the new document script uncovers
a latex problem in src/algebra/transsolve.spad.pamphlet.  The error
below is what I see from the corresponding log file (note that the
pamphlet has been properly (no)weaved).  It is not a big deal

    [1

   ] (./transsolve.spad.toc)
   \tf@toc=\write3
   \openout3 = `transsolve.spad.toc'.

    [2] [3] [4] [5] [6]
   [7] [8] [9] [10] [11] [12]
   ! You can't use `macro parameter character #' in horizontal mode.
   l.513 generates the error (reported as bug #
                                                102):
   Sorry, but I'm not programmed to handle this case;
   I'll just pretend that you didn't ask for it.
   If you're in the wrong mode, you might be able to
   return to the right one by typing `I}' or `I$' or `I\par'.

The pmaphlet line was

  generates the error (reported as bug # 102):

I don't know whether that has been corrected on trunk or not (I've
checked yet).  

\start
Date: Sun, 10 Sep 2006 16:15:37 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: DeveloperNotes.pamphlet

> The pmaphlet line was
> 
>   generates the error (reported as bug # 102):
> 
> I don't know whether that has been corrected on trunk or not (I've
> checked yet).  

fixed in --patch-50 which is current 'gold'.

\start
Date: Sun, 10 Sep 2006 23:51:42 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: A Canonical Axiom GUI

Cliff Yapp writes:
> ... 
>>>> 1.  I think a default GUI for Axiom would be a Very Good Thing
>>
>>Kai Kaminski wrote:
>>> As I said, I'm not convinced.

I am convinced that trying to build a graphical user interface that
works only with Axiom would *not* be a good thing.

> >
> > No worries.  There is plenty of room here for differing 
> > opinions :-).
>
On September 8, 2006 9:56 AM Kai Kaminski wrote:
> Don't kid yourself. There's barely enough room for mine. ;-)
>

I do appreciate the sentiment in Kai's remark, which he indicates
we should take as humour. But I am worried that some people who are
potential contributors to this discussion might well perceive it
as fact. If so, I think that is very unfortunate. Axiom is a very
small project in terms of the number of active and vocal developers
so it is easy to give the wrong impression. My opinions about Axiom
development differ from other people on this list on a number of
points and I don't feel shy about saying so. Is that setting an
example or reinforcing the feeling that there is no more room for
other opinions? :(

Perhaps we need to do more to make sure that people feel like there
is room here for differing opinions and that we would really like to
hear them.

>>>> 2.  The project is not yet at a point where this should be a
>>>>     major focus for the project as a whole.
>>>
>>> That depends on what you mean. I believe the most important thing
>>> is to make it developer friendly.

Yes!

>>> In particular we must be able to use all the open source Lisp
>>> libraries that are available. Also, writing tools (especially
>>> GUIs) for Axiom should be easy.

While I would welcome anyone interesting in working on Axiom at the
level of the Lisp code, I seriously doubt whether compatibility of
Axiom with other open source Lisp libraries would make Axiom more
"friendly" to such developers. Or did you have some specific
libraries in mind that would have immediate application and mass
appeal?

>>
>> Right.  What I meant was we shouldn't be (as a project)  worrying
>> about GUI design when we can't run on ANSI lisp yet.
>
> Exactly. By making GUI development easy other people who can't or
> don't want to work on the more pressing problems (ANSIfication,
> Spad/Aldor, elimination of BOOT [that one's for you, Bill ;-)] etc)
> can start working on GUIs...

Thanks Kai :-). Yes, I am glad that only one Axiom developer seems
to be actively wasting his time on the idea of eliminating higher
level languages from Axiom... ;)

About ANSI lisp and licensing Aldor as open source, I agree that
indeed these are pressing problems - even "mission critical"
problems! If we don't solve these soon, I have little hope for the
immediate future of Axiom let alone the next 30 years.

> Later, when the more imminent problems have been solved, we can
> look at the existing GUIs and figure out where to go from there.
> Why should GUI development have to wait until everything else has
> been taken care of?

It should not and it isn't.

> 
>>>> 4.  Code counts more than opinions, so I'll be quiet until I
>>>>     have more of the former ;-).
>>
>>> I'm not so sure about that. How can anyone start coding if there is
>>> no consent of what the core of Axiom is and what features it should
>>> offer to GUIs?
>>
>> Well, that's a bit different.  What we should expose to GUIs and how
>> is probably somewhat separate from how the GUIs use that information.
>> The latter is usually where most of the trouble comes in :-).
>
> It is indeed very different. Of course, the former should be guided
> by the latter. Since we don't really know what a great GUI should
> look like, we'll have to take some educated guesses and then wait for
> feedback.

Having already implemented several user interfaces for Axiom, e.g.
TeXmacs, MathAction, AxiomUI and (soon) Sage, we do know very well the
kind of information and communications protocols that would make these
systems easier to program and more robust.

> ... 
>>
>> Well, if what I have heard about Lisp holds true in GUI programming
>> it should be fairly hard for anybody to create a feature we can't
>> incorporate one way or another ;-).  The idea of a literate GUI
>> program ...
>
> That doesn't imply that it's a good idea. Besides you have to consider
> library issues. Despite Lisp's greatness as a language, there isn't
> good support for native Cocoa (Mac) user interfaces. In fact it's not
> even clear that there ever will be. On Windows there is an effort for
> a native GUI library, but it's still in alpha as far as I know (google
> for 'graphics-forms'). Even if that succeeds you might be better off
> with Visual Basic (as sad as that is). 
> ...

I am afraid that I have to agree with Kai. We should not be tempted
to try to use Axiom as a fulcrum on which to lever renewed interest
in Lisp. To do so would almost certainly crush Axiom. In contrast to
the situation when most of Axiom was designed and implemented, there
are many other programming languages available today that are capable
of supporting Axiom and this is especially true when it comes to GUI
development.

>> 2.  2 and 3-D plotting, interactive manipulation, etc. IZIC has
>> done some work that I like, and VTK is also very nice - adapting 
>> those ideas and some work that has been done on how to do high
>> quality mathematical plotting is probably the second hardest part,
>> or even hardest if we also cover the core algorithms for graphical
>> display and manipulation ourselves.
>
> That's been done for other languages already. It would be cool to
> have a flexible plotting library in Lisp. But it's a waste of time
> write now. There are good offerings in other languages, so just use
> them. The Python Matplotlib source is about 30,000 lines, if I recall
> correctly. Do you really want to recreate that effort for the sake
> of purity? I don't.

On September 8, 2006 12:24 PM C Y wrote:
> 
> Eventually, yes I do.  Existing work should be used as a guide,
> but I think the eventual goal should be a plotting library so
> good/robust/capable that it makes no sense to use anything else.

No! This is open source and it's the 21st century. We should *never*
be thinking about re-writing other people's code. We need to be able
to collaborate with other projects and make direct use of other
people's work whenever we can. This is a philosophy that is deeply
embedded in the Sage project and I think it is largely responsible
for why it has become a major new computer algebra project is less
than two years - about the same amount of time we have been discussing
this GUI issue... The sooner we understand this philosophy the more
likely it is that we can save Axiom from the ghetto.
 
> ...
> Earlier C Y wrote:
>> GUI and Axiom core also fall in here.  Here's an interesting one -
>> if we need to run the Axiom core without a multi-threaded lisp,
>> how do we stop a job that is running too long?  Killing it is a bit
>> drastic, since that also loses us any other computations done before,
>> but what alternatives are there?
> For starters we could just use a multi-threaded Lisp. If that fails
> we might be able to use Unix signals (or an equivalent mechanism)
> and several processes. In the beginning we might have to live with an
> Axiom that doesn't behave very well.
>

The critical thing here is to design an asynchronous communications
protocol that allows the GUI process and the calculation engine to
work independently but in a co-operative manner.

I think we should pay close attention to the Twisted library currently
implemented in Python

http://twistedmatrix.com/trac

Twisted will very likely be used in the next version of Sage to improve
the Sage NoteBook GUI interface. It is especially suitable for use with
AJAX methods for web browser interface design.

If there is any similar kind of "event-driven networking framework"
that has already been implemented in multi-threaded lisp then that
might be of immediate interest. But even without such a library, as
Kai says it would possible to implement this as, say a Python process
running Twisted that communicates with the Axiom core is a more
primitive way.

> ... 
>>> Since a single GUI might support several system at once (see
>>> Bill's work), why not turn the whole thing upside-down? People
>>> download bundles consisting of a single GUI and several cores
>>> (Axiom, GAP, whatever).

Yes indeed. There has already been some interest expressed on the
part of the Sage Notebook developers to extend the Notebook interface
to work with Axiom. This is quite different than providing a direct
Sage interface to Axiom itself, for example the way Sage interfaces
with Maxima now.

>>
>> Because those systems, fundamentally, are not designed to work
>> together.  I admire the SAGE effort and I think it will be very
>> useful, but GAP (for example) doesn't share Axiom's type system
>> and so there is an impedance mismatch between the two systems.

This mismatch exists and is (largely) solved right now in Sage
between GAP, Singular and Maxima.

>> What assumptions is GAP making that Axiom doesn't know about when
>> it solves a problem, and are those assumptions ones that are
>> compatible with the ones we would make?  Does a function name or
>> even a property name mean the same thing between the two systems?

In principle this sounds like a really hard problem and it has even
given rise to a really big attempt at a general solution in the form
of OpenMath, but Sage ignores almost all of this and is a successful
demonstration that in practice this is not such a big problem. Sage
provides it's own dynamic strongly-typed object-oriented language
(actually just Python!) that serves as an interlingua between otherwise
quite different systems. It is interesting to note that this is the
same method that Martin Rubey used in Axiom to encapsulate Polymake.

> If we evolve towards proving algorithms, how do we prove an algorithm
> used in GAP without doing enough work to go ahead and implement it
> in Axiom anyway?

??? GAP already provides some tools for proving algorithms written
in GAP. Obviously the thing to do is to make use of these tools
where they exist.

> Just because you use two CASs from the same GUI doesn't imply that
> they'll have to work together. In my Emacs I use Common Lisp and
> Haskell, which don't understand each other either. On the other hand
> this whole point isn't that important, so let's ignore it for now.
> ...

I disagree that it is not important. To me, helping to provide a high
quality Axiom interface for Sage should be one of our highest priority
tasks at this time. The sooner we do this, the less we risk being
further marginalized by the success of this new open source project.
And because in contrast to those systems which already have an interface
with Sage, Axiom was built with an object-oriented philosophy very
similar to (in fact I would say, much more advanced than) Sage, I think
Axiom has a lot to offer the Sage project.

> 
> I have the impression that there are quite a few things that we just
> won't agree on. Since my arguments are often based on speculation I'm
> not really willing to push them much harder. Maybe we could instead
> try to find a common ground. How about the following:
> 
> 1) In the Axiom core we create one or more additional Lisp packages
>    (in the DEFPACKAGE sense) that provide an API for all the services
>    that a GUI needs/wants/whatever.
> 
>    The most important feature would probably be to get the output from
>    textual chatter to something with more structure.
>

Yes!
 
> 2) We add a *small* and *simple* piece of code that exports that API
>    over a socket interface. We also add a commandline option to enable
>    this feature/configure the port/etc.
> 

Yes, yes!

> > Kai Kaminski writes:
> >
> > | PS: I don't mean to say that there shouldn't be a nice, 
> > | downloadable package on Axiom's website featuring a specific
> > | GUI. What I'm after is independence. Axiom's main branch
> > | should contain no GUI-related code other than the
> > | implementation of the Axiom<->GUI protocol.
> >
> Gabriel Dos Reis writes:
> > I agree with that.  If you can sell it to the powers, I would be
> > happy to lend a helping hand.
>
> On September 8, 2006 7:14 AM Kai Kaminski wrote:
> Thanks. Maybe we can just agree that having an API/protocol to the
> Axiom core is useful anyway and then implement that. That way we
> avoid the discussion about whether we need a canonical GUI or not. The
> existence of a well-designed API seems to be a good idea anyway.
> 
> I'll try to put up a wiki page for collecting design proposals, use
> cases, etc. Furthermore I'll try to document those parts of Axiom that
> are directly related to this effort (plotting code, database access,
> documentation access, access to the interpreter/compiler etc).
> 

Kai, it you need any help or further incentive to start such a wiki
page please let me know. :)

On September 8, 2006 10:26 AM Martin Rubey wrote:
> ... 
> For display only I think there are three possibilities:
> 
> * use OutputForm directly
> * use TEX
> * create a domain like TEX that takes something in OutputFrom 
>   and converts it to whatever you want
> 
> For input and reusing output you should probably extend INFORM.
> If the type of a result of a computation doesn't have INFORM, you
> should complain to the author of the domain, or realize that it
> would be very very hard to come up with an INFORM.
> 

I think Martin's point is very important: that input and output
in Axiom are "designed in" to Axiom domains at a very fundamental
level. Therefore it is probably not practical nor desirable to try
to achieve a situation where the "Axiom main branch contain no
GUI-related code other than the implementation of the Axiom<->GUI
protocol".

But if by GUI-related you mean hyperdoc and Axiom graphics as opposed
to AXIOMsys itself, then I agree that these should not be considered
part of the core. Only AXIOMsys needs to be instrumented for an
external API.

As a bare minimum we need the kind of interface designed by James
Amundson for Maxima and used by A. G. Grozin in the TeXmacs interface
for Maxima. See http://wiki.axiom-developer.org/SandBoxMaxima
But I think that for Axiom we can do even better than that and
accommodate many other kinds of information such as Axiom types,
graphics data, and Axiom database (daase) queries.

\start
Date: Sun, 10 Sep 2006 22:36:06 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Kai Kaminski
Subject: RE: A Canonical Axiom GUI

 
> I do appreciate the sentiment in Kai's remark, which he indicates
> we should take as humour. But I am worried that some people who are
> potential contributors to this discussion might well perceive it
> as fact. If so, I think that is very unfortunate. Axiom is a very
> small project in terms of the number of active and vocal developers
> so it is easy to give the wrong impression. My opinions about Axiom
> development differ from other people on this list on a number of
> points and I don't feel shy about saying so. Is that setting an
> example or reinforcing the feeling that there is no more room for
> other opinions? :(

I doubt that is a problem.  If there is reluctance, it is probably
because many of the contributors here are skilled and senior
professionals at this game, and the newer arrivals don't feel qualified
to contradict them.  I myself should probably be less vocal in these
discussions until I have code to back up my ideas, as I am by no means
an expert.
 
> Perhaps we need to do more to make sure that people feel like there
> is room here for differing opinions and that we would really like to
> hear them.

It never hurts to assert that.

> While I would welcome anyone interesting in working on Axiom at the
> level of the Lisp code, I seriously doubt whether compatibility of
> Axiom with other open source Lisp libraries would make Axiom more
> "friendly" to such developers. Or did you have some specific
> libraries in mind that would have immediate application and mass
> appeal?

I doubt there are any that would have "mass appeal".  The most
immediately useful might be CFFI (for interfacing with numerical
libraries, for example.) There are a variety of somewhat longer term
possibilities - Femlisp, for example.  http://www.femlisp.org/
 
> About ANSI lisp and licensing Aldor as open source, I agree that
> indeed these are pressing problems - even "mission critical"
> problems! If we don't solve these soon, I have little hope for the
> immediate future of Axiom let alone the next 30 years.

I agree about the immediate future.  The long term is another matter,
but the amount of work required to get there will be higher without a
free Aldor.
 
> I am afraid that I have to agree with Kai. We should not be tempted
> to try to use Axiom as a fulcrum on which to lever renewed interest
> in Lisp. To do so would almost certainly crush Axiom. In contrast to
> the situation when most of Axiom was designed and implemented, there
> are many other programming languages available today that are capable
> of supporting Axiom and this is especially true when it comes to GUI
> development.

I expect it is a bit of a moot point if we are not going to have a
default GUI in the main Axiom tree.  Probably in the end there will be
many interfaces in many toolkits.  I take it there would be no
objection to the development of a Lisp based GUI as long as no move was
made to make it "the default"?
 
> > > Do you really want to recreate that effort for the sake
> > > of purity? I don't.
> > 
> > On September 8, 2006 12:24 PM C Y wrote:
> > 
> > Eventually, yes I do.  Existing work should be used as a guide,
> > but I think the eventual goal should be a plotting library so
> > good/robust/capable that it makes no sense to use anything else.
> 
> No! This is open source and it's the 21st century. We should *never*
> be thinking about re-writing other people's code. We need to be able
> to collaborate with other projects and make direct use of other
> people's work whenever we can. This is a philosophy that is deeply
> embedded in the Sage project and I think it is largely responsible
> for why it has become a major new computer algebra project is less
> than two years - about the same amount of time we have been
> discussing this GUI issue... The sooner we understand this philosophy
> the more likely it is that we can save Axiom from the ghetto.

I agree we should make use of available resources in the short term,
which does mean reusing work.  The really long term (maybe even beyond
the 30 year horizon) is I suppose not especially useful to think about
at this time.

>>> What assumptions is GAP making that Axiom doesn't know about when
>>> it solves a problem, and are those assumptions ones that are
>>> compatible with the ones we would make?  Does a function name or
>>> even a property name mean the same thing between the two systems?
>
> In principle this sounds like a really hard problem and it has even
> given rise to a really big attempt at a general solution in the form
> of OpenMath, but Sage ignores almost all of this and is a successful
> demonstration that in practice this is not such a big problem.

I think it depends on what one wants to do.  In full formality of
proving a result, as I understand it, every last step has to hold up -
I just don't see how potential differences in environment assumptions
can be avoided as a major problem in such a case.  For most uses I
agree that it is not likely to come up, but I am still extremely
dubious that such an approach can scale cleanly to all of mathematics. 
One of Axiom's strengths and main attractions is that it may actually
have the potential to scale enormously and cleanly.  

> ??? GAP already provides some tools for proving algorithms written
> in GAP. Obviously the thing to do is to make use of these tools
> where they exist.

That's just it - I would eventually like to see Axiom reach the point
that any mathematics included in it is backed by proving the algorithms
formally, and be able to generate proofs for its results.  While some
projects might have some of this done, many (to my understanding) don't
go to that extreme.  That then means incorporating the ideas behind the
existing code into Axiom, and providing whatever is needed in the way
of proofs, research paper citations, theory discussions, what have you.

Anyway, I'm not yet qualified to be arguing for such a position,
really.  Kai and I are trying to put our heads together and come up
with something a little more useful to do than argue about GUI issues,
so I at least will turn this discussion back to the real experts :-).

\start
Date: 11 Sep 2006 12:04:25 +0200
From: Martin Rubey
To: list
Subject: evaluator for functional equations / CHALLENGE!

Dear all!

next week I'm going to present my guessing package at MathInfo 06. It works
quite well meanwhile :-)

Hower, there is one thing I don't really want to program - in fact, I won't -
although it would be really really useful. Maybe somebody else can do it. I
offer a price, ok?

The challenge is as follows:

I need an operation evalADE that takes a functional equation of the form

f(x) = g(f(x), D(f(x),x), D(f(x),x,2),...),

where g is any "nice" expression, some initial values, and an integer n.

The result of the operation should be the n-th coefficient of the taylor
expansion of f, if it exists.

Even more important, suppose that the functional equation is of the form

p(f(x), D(f(x),x), D(f(x),x,2), ...)

where p is a polynomial. These f are called differentially algebraic.

The algorithm does not need to be especially fast, but it would be nice to be a
able to compute the first fifty to hundred coefficients in a reasonable time.

Note that Axiom provides an operation seriesSolve, which provides a partial
solution. However, it is very buggy and gives up even for certain algebraic
equations.

Price is negotiable.

\start
Date: Mon, 11 Sep 2006 12:06:00 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: \begin{chunk}

Hello

On 09/10/2006 06:10 PM, Gabriel Dos Reis wrote:
> On Sun, 10 Sep 2006, C Y wrote:
> 
> | --- Ralf Hemmecke wrote:
> |
> | > There is also the "listings" LaTeX package which should be
> | > considered.
> |
> | That was the one I was thinking of.
> 
> 
> yes, some of my colleagues use it.  Over the year, I've come to prefer
> the package fancyvrb because it is very flexible and it gives me all I
> want.
> 
> I really find the idea of singling out keywords very curious and
> anti-abstraction.

What exactly do you mean? That you have to write something
On page 17 of
http://www.ctan.org/tex-archive/macros/latex/contrib/listings/listings-1.3.pdf#search=%22listings%20latex%22

\lstset{emph={square},      emphstyle=\color{red},
         emph={[2]root,base},emphstyle={[2]\color{blue}}}
\begin{lstlisting}
for i:=maxint to 0 do
begin
     j:=square(root(i));
end;
\end{lstlisting}

??? In particular the \lstset{..} command?

If yes, then I agree.

But assume you could tangle Aldor code and retain some information of 
the .pamphlet file inside the .as file. The Aldor compiler should have 
an option to spit out a file (something like an .aux file) that would 
magically add such statements (in fact hyperlinks) to the appropriate 
chunks. We then would write \begin{chunk}{NAME of the chunk} ... 
\end{chunk} instead of \begin{lstlisting} ... \end{lstlisting}.
If you don't run the Aldor compiler you still could latex, but you just 
don't get the hyperlinks.

That is what I would consider ideal. Now, I think, whether the input 
syntax is <<...>> or \begin{chunk}{...} does not really matter that 
much. The aldor compiler would be needed to figure out where the 
definition of a particular keyword is and that is where the trouble begins.

I am not completely against a syntax change, but it should not be just a 
simple change. It should add some real value. Otherwise it is just 
wasted time.

>  All the examples in
> 
>   http://www.research.att.com/~bs/popl06.pdf
> 
> are typset with fancyvrb.

I guess that could have been done with ordinary latex features like 
\begin{verbatim} ... \end{verbatim}. The only places that I see that are 
impossible is the slanted text referring to "ConceptName".
But note that you are writing for a paper journal and you only give 
program snippets. I would like links from a usage of an identifier to 
its definition. Just suppose you have all the pamphlets online as html.

\start
Date: Mon, 11 Sep 2006 10:26:12 -0500
From: Jaroslov Rosenberger
To: list
Subject: axiom.silver
Cc: Jaroslov Rosenberger, Gabriel Dos Reis

I've just attempted to svn checkout the axiom.silver branch. I had two
errors: (1) the checkout appeared to fail, (2) the configure file
emits an error. My machine is:

Mac mini (macmini1,1)
Intel Core Duo
1.66 GHz
ROM: MM11.004B.B00

Mac OS X 10.4.7

The svn error is this:
***********************************************
subversion/libsvn_wc/log.c:338: (apr_err=155009)
svn: In directory 'axiom.silver/axiom/src/hyper/pages'
subversion/libsvn_subr/io.c:2175: (apr_err=2)
svn: Can't open file
'axiom.silver/axiom/src/hyper/pages/.svn/tmp/text-base/poly.pht.svn-base':
No such file or directory
*************************************************

The svn --version dump is this:
***********************************************
svn, version 1.3.1 (r19032)
   compiled Apr  4 2006, 00:30:54

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
************************************************

The error from the configure is this:
*******************************************
Darwin
Your system name is Darwin
We do not know how to build for this kind of system
Send a note to list about it
*******************************************

\start
Date: Mon, 11 Sep 2006 12:00:19 -0400
From: Tim Daly
To: Jaroslov Rosenberger
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger, Gabriel Dos Reis

> The error from the configure is this:
> *******************************************
> Darwin
> Your system name is Darwin
> We do not know how to build for this kind of system
> Send a note to list about it
> *******************************************


Actually, this is correct. I do not yet know how to build
Axiom on a MAC. There has been a recent suggestion that we
use Xcode and I'm pursuing that path.

\start
Date: Mon, 11 Sep 2006 11:25:30 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

On Mon, 11 Sep 2006, root wrote:

| > The error from the configure is this:
| > *******************************************
| > Darwin
| > Your system name is Darwin
| > We do not know how to build for this kind of system
| > Send a note to list about it
| > *******************************************
|
|
| Actually, this is correct. I do not yet know how to build
| Axiom on a MAC. There has been a recent suggestion that we
| use Xcode and I'm pursuing that path.

Tim --

  Jacob is a student at TAMU taking my class on symbolic computations.
He is interested in provisos -- I suspect at some point he may get
into touch with you.
He is trying to build Axiom for his class work.

>From what I understand, Bill has been able to build the
build-improvements branch with some patches from Camm (which I believe
I already put in build-improvements).  I have a fix for the debian
failure.  Once that is in, I would like to make a tarball of
build-improvements available from axiom-developer.org or from SF
(whichever is OK with you).  This is to remove the "random" checkout
errors.

\start
Date: Mon, 11 Sep 2006 12:22:01 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

> From what I understand, Bill has been able to build the
> build-improvements branch with some patches from Camm (which I believe
> I already put in build-improvements).  I have a fix for the debian
> failure.  Once that is in, I would like to make a tarball of
> build-improvements available from axiom-developer.org or from SF
> (whichever is OK with you).  This is to remove the "random" checkout
> errors.

you are a project admin so you have permission to upload files --t

\start
Date: Mon, 11 Sep 2006 11:36:32 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: axiom.silver

On Mon, 11 Sep 2006, root wrote:

| > From what I understand, Bill has been able to build the
| > build-improvements branch with some patches from Camm (which I believe
| > I already put in build-improvements).  I have a fix for the debian
| > failure.  Once that is in, I would like to make a tarball of
| > build-improvements available from axiom-developer.org or from SF
| > (whichever is OK with you).  This is to remove the "random" checkout
| > errors.
|
| you are a project admin so you have permission to upload files --t

sure :-) But, I prefered to know upfront whether that might cause any
"philosophical" problem to you.

\start
Date: Mon, 11 Sep 2006 12:37:36 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: axiom.silver

> sure :-) But, I prefered to know upfront whether that might cause any
> "philosophical" problem to you.

oh, probably. :-)
but my advice would be to ignore me. i'll get over it.
my opinion matters about as much as anyone elses.
try not to give it such 'voice of god' authority.
you have the ability and permission to do anything you want
which is why you're a project admin.

\start
Date: Mon, 11 Sep 2006 18:15:47 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: axiom.silver
Cc: Jaroslov Rosenberger

Gaby,

On Monday, September 11, 2006 12:26 PM you wrote:
>
> On Mon, 11 Sep 2006, root wrote:
>
> | > The error from the configure is this:
> | > *******************************************
> | > Darwin
> | > Your system name is Darwin
> | > We do not know how to build for this kind of system
> | > Send a note to list about it
> | > *******************************************
> |
> |
> | Actually, this is correct. I do not yet know how to build
> | Axiom on a MAC. There has been a recent suggestion that we
> | use Xcode and I'm pursuing that path.
>
> Tim --
>
>   Jacob is a student at TAMU taking my class on symbolic
> computations. He is interested in provisos -- I suspect at
> some point he may get into touch with you. He is trying to
> build Axiom for his class work.
>
> From what I understand, Bill has been able to build the
> build-improvements branch with some patches from Camm (which
> I believe I already put in build-improvements).

I have built the build-improvements branch on the axiom-developer
server (in fact that is what is running on MathAction right now).
But I think the build process still has some problems. For example,
I am not able to build (even if I specific '--without-noweb') if
noweb is not previously installed and in the PATH. Also, the
option to build from a previously installed gcl does not work
so the option '--without-gcl' is still necessary. Since building
from pre-installed gcl is possible on Debian using the Debian
source distribution for Axiom, there must still be something
missing from the 'gcl-system' option in the build-improvements
branch.

There is also an additional patch which I am still discussing
with Camm to solve the "Can't rename' problem. The patch that
I am using now might not be the ultimate solution of gcl-2.6.8.

Until a few days ago, I was also working on the SourceForge
compile farm - specifically on the OS X build. But SourceForge
currently has a network configuration problem which prevents me
from accessing their servers:

https://sourceforge.net/tracker/?func=detail&atid=200001&aid=155345=
6&gro
up_id=1

> I have a fix for the debian failure.  Once that is in, I would
> like to make a tarball of build-improvements available from
> axiom-developer.org or from SF (whichever is OK with you).
> This is to remove the "random" checkout errors.
>

I also continue to see some svn checkout errors. In some cases
on some platforms this seems to be a recoverable error by just
repeating the 'svn co' command until the checkout completes. On
others, the local svn archive gets unrecoverably locked. :(

I wonder if this might be another network configuration problem
at SourceForge?

Maybe we should setup a mirror of the SourceForge SVN repository
on the axiom-developer.org server? Then at least we would have an
alternate site in case there is a network problem.

\start
Date: Mon, 11 Sep 2006 18:40:36 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger, Gabriel Dos Reis

Maybe we should setup a mirror of the SourceForge SVN repository
> on the axiom-developer.org server? Then at least we would have an
> alternate site in case there is a network problem.


  I wonder if anybody have thought of putting Axiom in the Google
repositories.

  http://code.google.com/hosting/

  I already have Doyen in there http://code.google.com/p/doyenlivecd/

  They did start with SVN since day one, and probably do not have the
problems
   that SourceForge had moving from CVS.

\start
Date: Mon, 11 Sep 2006 19:00:38 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: axiom.silver
Cc: Jaroslov Rosenberger, Gabriel Dos Reis

On Monday, September 11, 2006 6:41 PM Jose Alfredo Perez wrote:

> Bill Page wrote:
>> Maybe we should setup a mirror of the SourceForge SVN repository
>> on the axiom-developer.org server? Then at least we would have an
>> alternate site in case there is a network problem.
>
> I wonder if anybody have thought of putting Axiom in the Google
> repositories.
>
> http://code.google.com/hosting/
>
> I already have Doyen in there http://code.google.com/p/doyenlivecd/
>
> They did start with SVN since day one, and probably do not have the
> problems that SourceForge had moving from CVS.

This sounds good to me.	I don't see any problem having the code
spread around except for keeping the various locations in synch.
Do you know if we can configure the Google repository to automatically
mirror the SourceForge repository?

And you are volunteering to set this up at Google?  Yes? Oh Good!
:-)

\start
Date: Mon, 11 Sep 2006 18:26:40 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: axiom.silver
Cc: Jaroslov Rosenberger

On Mon, 11 Sep 2006, Page, Bill wrote:

| Gaby,
|
| On Monday, September 11, 2006 12:26 PM you wrote:
| >
| > On Mon, 11 Sep 2006, root wrote:
| >
| > | > The error from the configure is this:
| > | > *******************************************
| > | > Darwin
| > | > Your system name is Darwin
| > | > We do not know how to build for this kind of system
| > | > Send a note to list about it
| > | > *******************************************
| > |
| > |
| > | Actually, this is correct. I do not yet know how to build
| > | Axiom on a MAC. There has been a recent suggestion that we
| > | use Xcode and I'm pursuing that path.
| >
| > Tim --
| >
| >   Jacob is a student at TAMU taking my class on symbolic
| > computations. He is interested in provisos -- I suspect at
| > some point he may get into touch with you. He is trying to
| > build Axiom for his class work.
| >
| > From what I understand, Bill has been able to build the
| > build-improvements branch with some patches from Camm (which
| > I believe I already put in build-improvements).
|
| I have built the build-improvements branch on the axiom-developer
| server (in fact that is what is running on MathAction right now).
| But I think the build process still has some problems. For example,
| I am not able to build (even if I specific '--without-noweb') if
| noweb is not previously installed and in the PATH.

I think I fixed that, as per my conversation with Waldek

  http://lists.gnu.org/archive/html/axiom-developer/2006-09/msg00225.html
  http://lists.gnu.org/archive/html/axiom-developer/2006-09/msg00226.html

| Also, the
| option to build from a previously installed gcl does not work
| so the option '--without-gcl' is still necessary. Since building
| from pre-installed gcl is possible on Debian using the Debian
| source distribution for Axiom, there must still be something
| missing from the 'gcl-system' option in the build-improvements
| branch.

As per discussion with Waldek, I'm able to reproduce the failure on
the SF compile farm host debian system.  For long time I've blamed GCL
for not finding its own internal files.  I had had several "fixes" -- none
of which I liked, because I felt they were ugly.  I finally nailed
down the real source (I think): It is caused by this line in
src/interp/Makefile.pamphlet for building interpsys

 @ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' >>  ${OUT}/makeint.lisp

That setting of *system-directory* fools GCL's logic for invoking GCC
to compile the intermediate C code.  I don't see any reason why Axiom
would want to set that variable if it is not going to copy whole
/usr/local/lib/gcl-x.y.z (or wherever that directory is) -- and I
don't see any reason why it should do so.  As I'm writing this mail, I
have a build going on.  Hopefully that would settle the issue.

Notice that fixing that bug also opens the door for reducing the
number of Axiom-specific patches we have to apply to our copy of GCL
sources.

| There is also an additional patch which I am still discussing
| with Camm to solve the "Can't rename' problem. The patch that
| I am using now might not be the ultimate solution of gcl-2.6.8.

Thanks for the update.  Let me know once you guys have decided on what
is the good way to fix that problem.

| Until a few days ago, I was also working on the SourceForge
| compile farm - specifically on the OS X build. But SourceForge
| currently has a network configuration problem which prevents me
| from accessing their servers:
|
| https://sourceforge.net/tracker/?func=detail&atid0001&aid=1553456&gro
| up_id=1

Yes.  I intended (last week-end) to post the list of hosts that I
can't connect to (the vast majority of them), and the list of hosts
lacking latex. The work on out-of-source build finally got me to a
point where I just needed to svn checkout from a "good host" and
seamlessly build on other machines (as user directories are
automounted everywhere).

| > I have a fix for the debian failure.  Once that is in, I would
| > like to make a tarball of build-improvements available from
| > axiom-developer.org or from SF (whichever is OK with you).
| > This is to remove the "random" checkout errors.
| >
|
| I also continue to see some svn checkout errors. In some cases
| on some platforms this seems to be a recoverable error by just
| repeating the 'svn co' command until the checkout completes. On
| others, the local svn archive gets unrecoverably locked. :(
|
| I wonder if this might be another network configuration problem
| at SourceForge?

Very likely.

| Maybe we should setup a mirror of the SourceForge SVN repository
| on the axiom-developer.org server? Then at least we would have an
| alternate site in case there is a network problem.

I'm not a big fan of project sources scattered all over the place with
sync snafus, but I'm definitely for a good solution that removes the
network problem out of the way.  Hopefully, now that we have
out-of-source  build, people would no longer need to "rm -rf" the
wholse source.

\start
Date: Mon, 11 Sep 2006 18:27:57 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: axiom.silver
Cc: Jaroslov Rosenberger

On Mon, 11 Sep 2006, Page, Bill wrote:

| This sounds good to me.	I don't see any problem having the code
| spread around except for keeping the various locations in synch.

That is a concern to me, but if we have a solution for that, let's go
for it.

| Do you know if we can configure the Google repository to automatically
| mirror the SourceForge repository?
|
| And you are volunteering to set this up at Google?  Yes? Oh Good!
| :-)

:-) :-)

\start
Date: Mon, 11 Sep 2006 19:47:25 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

> On Mon, 11 Sep 2006, Page, Bill wrote:
>
> | Do you know if we can configure the Google repository to automatically
> | mirror the SourceForge repository?


  I know that Google will not let you register a project that is already in
SourceForge
  (same name). Hopefully it can do more than this. I will look into this,
especially
  because it has been a concern to  have different source out of sync.

  I think Google will email the registered administrator to allow have Axiom
listed
  in their repositories.


> | And you are volunteering to set this up at Google?  Yes? Oh Good!
> | :-)


  I was afraid of that. :-)  (always afraid of the higher powers).

\start
Date: 12 Sep 2006 02:37:00 +0200
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

Alfredo Portes writes:

[...]

|   I think Google will email the registered administrator to allow have Axiom
| listed
|   in their repositories.

I OKed the request.

\start
Date: Mon, 11 Sep 2006 22:52:57 -0400
From: Tim Daly
To: list
Subject: branches/build-improvements/src/interp

> Revision: 127
>           http://svn.sourceforge.net/axiom/?rev=127&view=rev
> Author:   dos-reis
> Date:     2006-09-11 19:54:02 -0700 (Mon, 11 Sep 2006)
> 
> Log Message:
> -----------
> Don't set si::*system-directory*


methinks this breaks something (BSD?) if i remember correctly

See src/algebra/Makefile.pamphlet around line 611

\start
Date: 12 Sep 2006 05:16:14 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: branches/build-improvements/src/interp

Tim Daly writes:

| > Revision: 127
| >           http://svn.sourceforge.net/axiom/?rev=127&view=rev
| > Author:   dos-reis
| > Date:     2006-09-11 19:54:02 -0700 (Mon, 11 Sep 2006)
| > 
| > Log Message:
| > -----------
| > Don't set si::*system-directory*
| 
| 
| methinks this breaks something (BSD?) if i remember correctly
| 
| See src/algebra/Makefile.pamphlet around line 611

setting that breaks build of Axiom with system-installed GCL.
I've looked into how GCL uses si::*system-directory*.
I don't see how setting that variable as Axiom did can be ever correct.
Maybe the problem is somewhere else?
I don't have access to a sane *BSD to test, and I welcome any
help there.


src/algebra/Makefile.pamphlet around line 611 reads:

tree.spad.pamphlet (TREE BTCAT BTREE BSTREE BTOURN BBTREE PENDTREE)
twofact.spad.pamphlet (NORMRETR TWOFACT)                ;; <== HERE
unifact.spad.pamphlet (UNIFACT)

I looked into that file, but nothing "obvious".


The patch was tested on an 

* i686-pc-linux with GCL and noweb installed
* x86_64-suse-linux with noweb installed and WITHOUT GCL installed.

\start
Date: 11 Sep 2006 22:22:34 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] support system-install GCL

I've long errouneously blamed GCL.  Detailed investigation turned out
top be an Axiom doing.  Fixed thusly.

Tested on:

  * i686-pc-linux with GCL and noweb installed
  * x86_64-suse-linux without GCL and with noweb installed

Bill, if you can give it a try on mac, that would be very appreciated.

-- Gaby

src/interp/

2006-09-11  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet (${SAVESYS}): Don't set
	si::*system-directory*. 
	* Makefile.in: Regenerate.
	
*** src/interp/Makefile.pamphlet	(revision 15833)
--- src/interp/Makefile.pamphlet	(local)
*************** GCL likes to tell you when it has replac
*** 840,845 ****
--- 840,852 ----
  tail-recursive call. This happens when the last form in a function
  is a call to the same function. In general, we don't care so we set
  compiler::*suppress-compiler-notes* to true in order to reduce the noise.
+ 
+ Notice that when Axiom uses GCL as the Lisp platform, it is usually not 
+ a good idea to mess with GCL's internal variables.  In particular, GCL
+ has its own idea about what to do with [[si::*system-directory*]], which 
+ should not be set here just because we happen to save an GCL-based image.
+ Doing otherwise causes havoc.
+ 
  <<savesys>>=
  ${SAVESYS}:	${DEPSYS} ${OBJS} ${OUT}/bookvol5.${O} ${OUT}/util.${O} \
                  ${OUT}/nocompil.${LISP} ${OUT}/sys-pkg.${LISP} \
*************** ${SAVESYS}:	${DEPSYS} ${OBJS} ${OUT}/boo
*** 883,889 ****
  #	@ echo '#+:akcl (si::multiply-bignum-stack 10)' >> ${OUT}/makeint.lisp
  	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> ${OUT}/makeint.lisp
  	@ 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} )
  	@ echo 6 ${SAVESYS} created
--- 890,896 ----
  #	@ echo '#+:akcl (si::multiply-bignum-stack 10)' >> ${OUT}/makeint.lisp
  	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> ${OUT}/makeint.lisp
  	@ 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} )
  	@ echo 6 ${SAVESYS} created


\start
Date: Mon, 11 Sep 2006 23:32:03 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

On 12 Sep 2006 02:37:00 +0200, Gabriel Dos Reis <
Gabriel Dos Reis> wrote:

> |   I think Google will email the registered administrator to allow have
> Axiom
> | listed
> |   in their repositories.
>
> I OKed the request.


  Thanks Gaby

  Well the page repository is up now: http://code.google.com/p/axiom/

   Looking at http://code.google.com/hosting/faq.html and the web I do not
see a way yet
   implemented to import or keep in sync with SourceForge.

   I would like to know if I should proceed to put the source in there...if
yes then: should it
   be an exact copy of sourceforge?

   If anybody has gmail accounts please let me know to add them as
administrators ( I
   can send invitations to who ever needs one.)

\start
Date: 11 Sep 2006 22:39:27 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] Remove non-supported Makefiles

  This patchlet removes platform-specific makefiles that "obviously"
are not supported by Axiom in its current form.  Long term goal is to
stop generating Makefile.${SYS}

-- Gaby
2006-09-11  Gabriel Dos Reis  Gabriel Dos Reis
  
	* Makefile.pamphlet (<<Makefile.axposf1v3>>): Remove.
	(<<Makefile.axposf1v4>>): Likewise.
	(<<Makefile.hp10>>): Likewise.
	(<<Makefile.hp11>>): Likewise.
	(<<Makefile.hp9>>): Likewise.
	(<<Makefile.irixmips1>>): Likewise.
	(<<Makefile.irixmips3>>): Likewise.
	(<<Makefile.rs6000aix3>>): Likewise.
	(<<Makefile.rs6000aix4>>): Likewise.
	(<<Makefile.rs6000aix4.1>>): Likewise.
	(<<Makefile.rs6000aix4.3>>): Likewise.
	(<<Makefile.sun4os55c>>): Likewise.
	(<<Makefile.sun4os58c>>): Likewise.
	* Makefile.in: Regenerate.

*** Makefile.pamphlet	(revision 15074)
--- Makefile.pamphlet	(local)
*************** changed on the command line.
*** 353,359 ****
  ## -- Old-style Axiom makefile variables --
  ## ----------------------------------------
  
! VERSION="Axiom (build improvements branch) -- 2006-08-26"
  SPD=$(shell pwd)
  SYS=$(notdir $(AXIOM))
  SPAD=${SPD}/mnt/${SYS}
--- 353,359 ----
  ## -- Old-style Axiom makefile variables --
  ## ----------------------------------------
  
! VERSION="Axiom (build improvements branch) -- 2006-09-12"
  SPD=$(shell pwd)
  SYS=$(notdir $(AXIOM))
  SPAD=${SPD}/mnt/${SYS}
*************** GCLOPTS="--enable-vssize=65536*2 --enabl
*** 797,1064 ****
           --disable-statsysbfd  --enable-custreloc --disable-tkconfig \
           --enable-machine=pwerpc-macosx"
  @
- \subsection{Makefile.axposf1v3}
- <<Makefile.axposf1v3>>=
- # System dependent Makefile for the AXP/OSF platform
- # Platform variable
- PLF= ALPHAplatform
- # C compiler flags
- CCF=" -O2 -Olimit 3000 -std1 -warnprotos -float -ieee_with_no_inexact -D${PLF}"
- # Loader flags
- LDF=
- # C compiler to use
- CC= cc
- AWK="/systems/pub/bin.alpha/gawk -W version -W compat"
- RANLIB=ranlib
- TOUCH=/bin/touch
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- # where the libXpm.a library lives
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 24 Makefile.axposf1v3 called
- 	@echo 25 Environment : ${ENV} 
- 	@echo 26 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.axposf1v4}
- <<Makefile.axposf1v4>>=
- # System dependent Makefile for the AXP/OSF platform
- # Platform variable
- PLF= ALPHAplatform
- # C compiler flags
- CCF=" -O2 -Olimit 3000 -std1 -warnprotos -float -ieee_with_no_inexact -D${PLF}"
- # Loader flags
- LDF=
- # C compiler to use
- CC= cc
- AWK=/systems/pub/bin.alpha/gawk -W compat
- RANLIB=ranlib
- TOUCH=/bin/touch
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP}  DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 27 Makefile.axposf1v4 called
- 	@echo 28 Environment : ${ENV} 
- 	@echo 29 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.hp10}
- <<Makefile.hp10>>=
- # System dependent Makefile for the HP 9000/730 (700 series) platform
- # Platform variable
- PLF= HP10platform
- # C compiler flags
- CCF=" +O2 +Onolimit -D${PLF} -D_HPUX_SOURCE"
- # Loader flags
- LDF= -Wl,+vnocompatwarnings
- # C compiler to use
- CC= c89
- AWK="/usr/local/bin/gawk -W version -W compat"
- RANLIB=ranlib
- TOUCH=touch
- TAR=/usr/local/bin/gnutar
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP}  DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 30 Makefile.hp10 called
- 	@echo 31 Environment : ${ENV} 
- 	@echo 32 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.hp11}
- <<Makefile.hp11>>=
- # System dependent Makefile for the HP 9000/730 (700 series) platform
- # Platform variable
- PLF= HP10platform
- # C compiler flags
- CCF=" +O2 +Onolimit -D${PLF} -D_HPUX_SOURCE"
- # Loader flags
- LDF="-Wl,+vnocompatwarnings -lnsl"
- # C compiler to use
- CC= c89
- AWK="/usr/local/bin/gawk -W version -W compat"
- RANLIB=ranlib
- TOUCH=touch
- TAR=/usr/local/bin/gnutar
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 33 Makefile.hp11 called
- 	@echo 34 Environment : ${ENV} 
- 	@echo 35 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.hp9}
- <<Makefile.hp9>>=
- # System dependent Makefile for the HP 9000/730 (700 series) platform
- # Platform variable
- PLF= HP9platform
- # C compiler flags
- CCF=" -D${PLF} -Ae"
- # Loader flags
- LDF=
- # C compiler to use
- CC= cc -O
- AWK="/usr/local/bin/gawk -W version -W compat"
- RANLIB=ranlib
- TOUCH=touch
- TAR=/usr/local/bin/gnutar
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 36 Makefile.hp9 called
- 	@echo 37 Environment : ${ENV} 
- 	@echo 38 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.irixmips1}
- <<Makefile.irixmips1>>=
- # System dependent Makefile for the IP12 IRIX 5.3
- # Platform variable
- PLF= SGIplatform
- # C compiler flags
- CCF=" -O2 -D_SGI_SOURCE -fullwarn  -D${PLF}"
- # Loader flags
- LDF=
- # C compiler to use
- CC= cc
- RANLIB=echo
- TOUCH=touch
- TAR=gnutar
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 39 Makefile.irixmips1 called
- 	@echo 40 Environment : ${ENV} 
- 	@echo 41 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.irixmips3}
- <<Makefile.irixmips3>>=
- # System dependent Makefile for the IP26 IRIX 6.2
- # Platform variable
- PLF= SGIplatform
- CCF=" -mips3 -n32 -O -D_SGI_SOURCE -fullwarn -woff all -D${PLF}"
- # Loader flags
- LDF=
- # C compiler to use
- CC= cc -mips3 -n32
- RANLIB=echo
- TOUCH=touch
- TAR=gnutar
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 42 Makefile.irixmips3 called
- 	@echo 43 Environment : ${ENV} 
- 	@echo 44 finished system build on `date` | tee >lastBuildDate
  
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
  \subsection{Makefile.freebsd}
  Annoyingly enough it seems that GCL uses a default extension of .lsp
  rather than .lisp so we add the [[LISP]] variable here. We need to
--- 797,803 ----
*************** all: stamp-rootdirs srcsetup lspdir srcd
*** 1419,1613 ****
  <<document>>
  
  @
- \subsection{Makefile.rs6000aix3}
- <<Makefile.rs6000aix3>>=
- # System dependent Makefile for the IBM Risc System/6000 platform
- # Platform variable
- PLF= RIOSplatform
- # C compiler flags
- CCF=" -O3 -qstrict -qlanglvl=ansi -qextchk -D_ALL_SOURCE -D${PLF}"
- # Loader flags
- LDF=
- # C compiler to use
- CC=c89
- AWK="/systems/pub/rios/gawk -W version -W compat"
- TOUCH=/bin/touch
- TAR=/usr/local/bin/gtar
- RANLIB=ranlib
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 54 Makefile.rs6000aix3 called
- 	@echo 55 Environment : ${ENV} 
- 	@echo 56 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.rs6000aix4}
- <<Makefile.rs6000aix4>>=
- # System dependent Makefile for the IBM Risc System/6000 platform
- # Platform variable
- PLF= RIOSplatform
- # C compiler flags
- CCF=" -O3 -qstrict -qlanglvl=ansi -qextchk -D_ALL_SOURCE -D${PLF}"
- # Loader flags
- LDF=
- # C compiler to use
- CC=c89
- AWK="/systems/pub/rios/gawk -W version -W compat"
- TOUCH=/bin/touch
- TAR=/usr/local/bin/gtar
- RANLIB=ranlib
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 57 Makefile.rs6000aix4 called
- 	@echo 58 Environment : ${ENV} 
- 	@echo 59 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.rs6000aix4.1}
- <<Makefile.rs6000aix4.1>>=
- # System dependent Makefile for the IBM Risc System/6000 platform
- # Platform variable
- PLF= RIOSplatform
- # C compiler flags
- CCF=" -O3 -qstrict -qlanglvl=ansi -qextchk -D_ALL_SOURCE -D${PLF}"
- # Loader flags
- LDF=
- # C compiler to use
- CC=c89
- AWK="/systems/pub/rios/gawk -W version -W compat"
- TOUCH=/bin/touch
- TAR=/usr/local/bin/gtar
- RANLIB=ranlib
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 60 Makefile.rs6000aix4.1 called
- 	@echo 61 Environment : ${ENV} 
- 	@echo 62 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.rs6000aix4.3}
- <<Makefile.rs6000aix4.3>>=
- # System dependent Makefile for the IBM Risc System/6000 platform
- # Platform variable
- PLF= RIOSplatform
- # C compiler flags
- CCF=" -O3 -qstrict -qlanglvl=ansi -qextchk -D_ALL_SOURCE -D${PLF}"
- # Loader flags
- LDF=
- # C compiler to use
- CC=c89
- AWK="/systems/pub/rios/gawk -W version -W compat"
- TOUCH=/bin/touch
- TAR=/usr/local/bin/gtar
- RANLIB=ranlib
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
  
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 63 Makefile.rs6000aix4.3 called
- 	@echo 64 Environment : ${ENV} 
- 	@echo 65 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.sun4os55c}
- <<Makefile.sun4os55c>>=
- # System dependent Makefile for the SPARC SUNOS 5.5 platform with SPARCworks compiler
- # Platform variable
- PLF= SUN4OS5platform
- # C compiler flags
- CCF=" -xO4 -Xa  -D${PLF} -I /usr/openwin/include"
- # Loader flags
- LDF=-L /usr/openwin/lib -lnsl -lsocket 
- # C compiler to use
- CC= cc
- AWK=/systems/pub/sun4/gawk
- TOUCH=/bin/touch
- RANLIB= ar tvs 
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 66 Makefile.sun4os55c called
- 	@echo 67 Environment : ${ENV} 
- 	@echo 68 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
  \subsection{Makefile.sun4os55g}
  <<Makefile.sun4os55g>>=
  # System dependent Makefile for the SPARC SUNOS 5.5 platform with GNU compiler
--- 1158,1164 ----
*************** all: stamp-rootdirs srcsetup lspdir srcd
*** 1645,1687 ****
  <<document>>
  
  @
- \subsection{Makefile.sun4os58c}
- <<Makefile.sun4os58c>>=
- # System dependent Makefile for the SPARC SUNOS 5.5 platform with SPARCworks compiler
- # Platform variable
- PLF= SUN4OS5platform
- # C compiler flags
- CCF=" -xO4 -Xa  -D${PLF} -I /usr/openwin/include"
- # Loader flags
- LDF=-L /usr/openwin/lib -lnsl -lsocket 
- # C compiler to use
- CC= cc
- AWK=/systems/pub/sun4/gawk
- TOUCH=/bin/touch
- RANLIB= ar tvs 
- AXIOMXLROOT=${AXIOM}/compiler
- O=o
- BYE=bye
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
  
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
-     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 72 Makefile.sun4os58c called
- 	@echo 73 Environment : ${ENV} 
- 	@echo 74 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
  \subsection{Makefile.sung}
  <<Makefile.sung>>=
  # System dependent Makefile for the SPARC SUNOS 4.1.2 platform
--- 1196,1202 ----

\start
Date: 12 Sep 2006 05:44:20 +0200
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

Alfredo Portes writes:

| On 12 Sep 2006 02:37:00 +0200, Gabriel Dos Reis <
| Gabriel Dos Reis> wrote:
| 
| > |   I think Google will email the registered administrator to allow have
| > Axiom
| > | listed
| > |   in their repositories.
| >
| > I OKed the request.
| 
| 
|   Thanks Gaby
| 
|   Well the page repository is up now: http://code.google.com/p/axiom/

Great!

|    Looking at http://code.google.com/hosting/faq.html and the web I do not
| see a way yet
|    implemented to import or keep in sync with SourceForge.
| 
|    I would like to know if I should proceed to put the source in there...if
| yes then: should it
|    be an exact copy of sourceforge?

Hmm, I really would like to avoid versions of Axiom differering and
all being their own master sources.  If at all
possible, we should have exactly the same copy there.  The fact that,
it will not be mirrored converns me a bit. 

|    If anybody has gmail accounts please let me know to add them as
| administrators ( I
|    can send invitations to who ever needs one.)

I have a gmail account -- dosreis.

\start
Date: Mon, 11 Sep 2006 23:58:18 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

On 12 Sep 2006 05:44:20 +0200, Gabriel Dos Reis <
Gabriel Dos Reis> wrote:

Hmm, I really would like to avoid versions of Axiom differering and
> all being their own master sources.  If at all
> possible, we should have exactly the same copy there.  The fact that,
> it will not be mirrored converns me a bit.


  I am concerned with this too. It has happened to the source of Axiom in
  MathAction. I could try to keep it updated to the best of my abilities
(maybe
  a script???). Any suggestions are welcome.

|    If anybody has gmail accounts please let me know to add them as
> | administrators ( I
> |    can send invitations to who ever needs one.)
>
> I have a gmail account -- dosreis.


  Gaby, you are listed as owner now. You can modify it as needed. Anybody
else
   please let me know.. Bill???

\start
Date: Tue, 12 Sep 2006 00:34:01 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: axiom.silver
Cc: Jaroslov Rosenberger

On Monday, September 11, 2006 11:32 PM Alfredo Portes wrote:

> Well the page repository is up now: http://code.google.com/p/axiom/
>

Thanks Alfredo!

>  Looking at http://code.google.com/hosting/faq.html and the web
>  I do not see a way yet implemented to import or keep in sync with
>  SourceForge.

Hmmm... doesn't svn have some way to pull patches from another
repository? :-( Maybe 'svk pull' and 'push' can help?

Hosting FAQ says:

How do I get a copy of my data?
    At this time, there aren't any import or export features. But
    look for them as the service matures.

I guess we have to wait. In the meantime perhaps we can work out
a semi-automatic way to apply the patches automatically sent to

  'axiom-commit@lists.sourceforge.net'

Are you subscribed to that list?

>
>  I would like to know if I should proceed to put the source in
>  there...
>  if yes then: should it be an exact copy of sourceforge?
>

Yes and yes. At least this will allow us to test the checkout
problems and see if they are cured by the use of a different
host. Of course we may have to change things in the future.

>  If anybody has gmail accounts please let me know to add them as
>  administrators ( I can send invitations to who ever needs one.)

This "gmail" stuff confuses me since I do have a "Google Account" but
apparently not a Gmail account. Anyway Google says:

 "If you don't have a gmail account you can ask someone you know who
  already has a Gmail account to email you an invitation"

So Alfredo, could you send me an invitation please? :) To:

  Bill Page

\start
Date: Tue, 12 Sep 2006 00:49:46 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

 Bill,

I guess we have to wait. In the meantime perhaps we can work out
> a semi-automatic way to apply the patches automatically sent to
>
>   'axiom-commit@lists.sourceforge.net'
>
> Are you subscribed to that list?


  No, but I will :-) .


> Yes and yes. At least this will allow us to test the checkout
> problems and see if they are cured by the use of a different
> host. Of course we may have to change things in the future.


   I will commit the Silver source as an initial test.

So Alfredo, could you send me an invitation please? :) To:
>
>   Bill Page


  I just got your new email address. You are now listed as an owner:

  http://code.google.com/p/axiom/

\start
Date: Tue, 12 Sep 2006 01:02:32 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: axiom.silver
Cc: Jaroslov Rosenberger

Alfredo,

On Tuesday, September 12, 2006 12:50 AM you wrote:

> ...
>  I will commit the Silver source as an initial test.

Ok.

> ...
> I just got your new email address. You are now listed as an owner:
=09
	  http://code.google.com/p/axiom/
=09
Cool. Now I really feel sucked into the Google vortex... ;)

I added a few extra links to the project page.

Looks nice.

\start
Date: Tue, 12 Sep 2006 01:29:49 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

Tim,

You are listed as owner on:

http://code.google.com/p/axiom/

\start
Date: Tue, 12 Sep 2006 01:46:22 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: [build-improvements] support system-install GCL

On Monday, September 11, 2006 11:23 PM Gabriel Dos Reis wrote:
>
> I've long errouneously blamed GCL.  Detailed investigation turned
> out top be an Axiom doing.  Fixed thusly.
>
> Tested on:
>
>   * i686-pc-linux with GCL and noweb installed
>   * x86_64-suse-linux without GCL and with noweb installed
>
> Bill, if you can give it a try on mac, that would be very
> appreciated.
>

Good work!

I don't have access to a mac right now, but I can confirm that the
following commands build Axiom just fine on axiom-developer.org
with both noweb and gcl pre-installed:

$ svn co
https://svn.sourceforge.net/svnroot/axiom/branches/build-improvements \
         axiom.build-improvements

$ mkdir axiom-build

$ cd axiom-build

$ ../axiom.build-improvements/configure

$ more config.log

...skipping
configure:1381: checking target system type
configure:1395: result: i686-pc-linux
configure:1476: checking for gcc
configure:1492: found /usr/local/bin/gcc
configure:1502: result: gcc
configure:1746: checking for C compiler version
configure:1749: gcc --version </dev/null >&5
gcc (GCC) 4.0.1
...skipping
configure:2975: checking for notangle
configure:2991: found /usr/local/bin/notangle
configure:3001: result: notangle
configure:3010: checking for noweave
configure:3026: found /usr/local/bin/noweave
configure:3036: result: noweave
configure:3088: checking for gcl
configure:3104: found /usr/local/bin/gcl
...

$ nohup make&

$ tail -f nohup.out

...
46 Environment : PLF=LINUXplatform CCF=-O2 -fno-strength-reduce =
-Wall
-D_GNU_SOURCE -DLINUXplatform LDF= CC=gcc AWK= RANLIB=ranlib =
TOUCH=touch
TAR= AXIOMXLROOT=/home/page/axiom-build/mnt/linux/compiler O=o =
BYE=bye
LISP=lsp DAASE=/home/page/axiom.build-improvements/src/share
GCLOPTS=--enable-vssize=65536*2 --enable-statsysbfd
--enable-maxpage=256*1024 SRCDIRS=bootdir interpdir sharedir =
algebradir
etcdir clefdir docdir graphdir smandir hyperdir inputdir  PATCH=patch
make[2]: Leaving directory `/home/page/axiom-build'
make[1]: Leaving directory `/home/page/axiom-build'

$ export AXIOM=/home/page/axiom-build/mnt/linux
$ export PATH=$AXIOM/bin:$PATH
$ AXIOMsys
GCL (GNU Common Lisp)  2.6.8 CLtL1    Sep 11 2006 21:48:34
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD
UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
                        AXIOM Computer Algebra System
          Version: Axiom (build improvements branch) -- 2006-08-26
              Timestamp: Monday September 11, 2006 at 22:25:11
------------------------------------------------------------------------
-----
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
------------------------------------------------------------------------
-----

   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase
(1) ->

---------

Maybe we should set the option to eliminate the GCL banner?

I note that the GCLOPTS shown above do not correctly reflect the
fact that gcl was pre-built with different options.

Thanks for your work on this!

\start
Date: 12 Sep 2006 08:46:32 +0200
From: Martin Rubey
To: Bill Page, Alfredo Portes
Subject: Live CD for Conference (urgent)

Dear Alfredo, Bill,

as you probably know, I'm going to present my guessing package next week - only
as a poster, unfortunately, but still.


I would like to be able to give away Live-CD's (Knoppix style) that contain
Axiom and my guessing package, so that anybody can put it into his laptop and
try it out easily.

How am I to proceed?

IMPORTANT NOTE: the guessing package on MathAction is completely out of date. I
need the most recent version on the CD. Should I send you my package with
compilation instructions so that you can put it on the CD, or should I do this
myself somehow?

I'm sorry I'm so late, I didn't manage before...

\start
Date: Tue, 12 Sep 2006 03:05:50 -0400
From: Alfredo Portes
To: Martin Rubey
Subject: Re: Live CD for Conference (urgent)

Hi Martin,

On 12 Sep 2006 08:46:32 +0200, Martin Rubey
wrote:
>
> Dear Alfredo, Bill,
>
> as you probably know, I'm going to present my guessing package next week -
> only
> as a poster, unfortunately, but still.
>
> I would like to be able to give away Live-CD's (Knoppix style) that
> contain
> Axiom and my guessing package, so that anybody can put it into his laptop
> and
> try it out easily.


  Sorry Martin, the latest version of the LiveCD uses Fedora, because
it was the final goal to use Redhat software.  I have not had time to
try to put MathAction on a Knoppix CD. I guess I should look into
this. :(

  Have you used the latest LiveCD ??? Do you have any particular
reason to need the Knoppix one??? Let me know if there is any
particular issue that you would like me to address.


> IMPORTANT NOTE: the guessing package on MathAction is completely out
> of date. I need the most recent version on the CD. Should I send you
> my package with compilation instructions so that you can put it on
> the CD, or should I do this myself somehow?


  The process of creating the LiveCD is very straight forward (using
the Fedora LiveCD).  Following the instructions, it should not take
more than 45 minutes to have a complete CD from scratch by using
virtualization or a clean system.

  If you send me the package, I would be more than glad to include it
in the CD. I could also customize it so it appears on the menus and
add the paper or poster that you are going to present. I can have this
done by Wednesday night / Thursday morning.

\start
Date: 12 Sep 2006 09:14:21 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: evaluator for functional equations / CHALLENGE!

A followup on my own post, containing some material for fast algorithms.

Martin Rubey writes:


> I need an operation evalADE that takes a functional equation of the form
>
> f(x) = g(f(x), D(f(x),x), D(f(x),x,2),...),
>
> where g is any "nice" expression, some initial values, and an integer n.
>
> The result of the operation should be the n-th coefficient of the taylor
> expansion of f, if it exists.
>
> Even more important, suppose that the functional equation is of the form
>
> p(f(x), D(f(x),x), D(f(x),x,2), ...)
>
> where p is a polynomial. These f are called differentially algebraic.
>
> The algorithm does not need to be especially fast, but it would be nice t=
o be a
> able to compute the first fifty to hundred coefficients in a reasonable t=
ime.
>
> Note that Axiom provides an operation seriesSolve, which provides a parti=
al
> solution. However, it is very buggy and gives up even for certain algebra=
ic
> equations.

In the case of expansion around an ordinary point of f(x) satisfying a *lin=
ear*
differential equation, i.e.,

a0(x) f(x) + a1(x) D(f(x),x) + a2(x) D(f(x),x,2) + ... + a_k(x) D(f(x),x,k)=
 = 0

with a_k(x0)<>0,

a fast algorithm has been proposed by

Alin Bostan, Fr=E9d=E9ric Chyzak, Fran=E7ois Ollivier, Bruno Salvy, =C9ric =
Schost,
Alexandre Sedoglavic

available at http://arxiv.org/ps/cs/0604101

There is a paper by Nedialkov and Pryce

http://www.cas.mcmaster.ca/~nedialk/PAPERS/DAEs/taylcoeff_I/

that proposes an algorithm for the general problem. Maybe that's the one we
want...

\start
Date: 12 Sep 2006 09:23:50 +0200
From: Martin Rubey
To: Alfredo Portes
Subject: Re: Live CD for Conference (urgent)

Dear Alfredo,

Alfredo Portes writes:

>   Sorry Martin, the latest version of the LiveCD uses Fedora, because it was
> the final goal to use Redhat software.  I have not had time to try to put
> MathAction on a Knoppix CD. I guess I should look into this. :(
> 
>   Have you used the latest LiveCD ??? Do you have any particular reason to
> need the Knoppix one??? Let me know if there is any particular issue that you
> would like me to address.

No, I don't mind what system it is based on, I didn't know anything else but
Knoppix so far. I did not see the latest LiveCD, my computing powers here are
rather limited - I have to ask the computer group for everything. In fact, I
cannot even burn CD's... (But they will do it for me, of course)

> > IMPORTANT NOTE: the guessing package on MathAction is completely out of
> > date. I need the most recent version on the CD. Should I send you my
> > package with compilation instructions so that you can put it on the CD, or
> > should I do this myself somehow?
> 
> 
>   The process of creating the LiveCD is very straight forward (using the
> Fedora LiveCD).  Following the instructions, it should not take more than 45
> minutes to have a complete CD from scratch by using virtualization or a clean
> system.
> 
>   If you send me the package, I would be more than glad to include it in the
> CD. I could also customize it so it appears on the menus and add the paper or
> poster that you are going to present. I can have this done by Wednesday night
> / Thursday morning.

Well, I need the image downloadable on friday. Is it sufficient if I send you
the package with instructions tomorrow evening? (i.e., european time evening, I
have no idea what time zone you live in :-)

\start
Date: Tue, 12 Sep 2006 10:53:46 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

First of all, there was not proper response to my suggestion

http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00138.html

of how to deal with the "binary" file problem that we have in the 
sourceforge repository. I think we should solve that BEFORE the data is 
moved to google code.

Where are the SVN experts???

>>  Looking at http://code.google.com/hosting/faq.html and the web
>>  I do not see a way yet implemented to import or keep in sync with
>>  SourceForge.

> Hmmm... doesn't svn have some way to pull patches from another
> repository? :-( Maybe 'svk pull' and 'push' can help?
> 
> Hosting FAQ says:
> 
> How do I get a copy of my data?
>     At this time, there aren't any import or export features. But
>     look for them as the service matures.
> 
> I guess we have to wait. In the meantime perhaps we can work out
> a semi-automatic way to apply the patches automatically sent to
> 
>   'axiom-commit@lists.sourceforge.net'
> 
> Are you subscribed to that list?

Hmmm, but SVN has a way to run a script if someone says "svn commit". 
Couldn't that be used to send the patches from one server to the other?
I have however no idea whether google or sf allows to run such scripts 
at commit time. Anybody more familiar with that?

On the other hand it seems that SVK could be tricked to do the 
syncronization job. Gaby what are your experiences with that?
Isn't SVK creating a copy of the SVN repository locally (also as an SVN 
repository)?

And don't forget to update http://wiki.axiom-developer.org/AxiomSources
appropriately, once the "mirror" is working.

\start
Date: Tue, 12 Sep 2006 06:28:30 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: [build-improvements] support system-install GCL

On Tue, 12 Sep 2006, Page, Bill wrote:

| On Monday, September 11, 2006 11:23 PM Gabriel Dos Reis wrote:
| >
| > I've long errouneously blamed GCL.  Detailed investigation turned
| > out top be an Axiom doing.  Fixed thusly.
| >
| > Tested on:
| >
| >   * i686-pc-linux with GCL and noweb installed
| >   * x86_64-suse-linux without GCL and with noweb installed
| >
| > Bill, if you can give it a try on mac, that would be very
| > appreciated.
| >
|
| Good work!
|
| I don't have access to a mac right now, but I can confirm that the
| following commands build Axiom just fine on axiom-developer.org
| with both noweb and gcl pre-installed:

Many thanks for testing.

[...]

| Maybe we should set the option to eliminate the GCL banner?

Yes, definitely.

| I note that the GCLOPTS shown above do not correctly reflect the
| fact that gcl was pre-built with different options.

I'll look into that.

| Thanks for your work on this!

It was my pleasure.

\start
Date: 12 Sep 2006 13:34:27 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

Ralf Hemmecke writes:

| First of all, there was not proper response to my suggestion
| 
| http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00138.html
| 
| of how to deal with the "binary" file problem that we have in the
| sourceforge repository. I think we should solve that BEFORE the data
| is moved to google code.

I think I have to proceed as you suggested: remove the keywords and eol
properties.

[...]

| Hmmm, but SVN has a way to run a script if someone says "svn
| commit". Couldn't that be used to send the patches from one server to
| the other?
| I have however no idea whether google or sf allows to run such scripts
| at commit time. Anybody more familiar with that?

I'm no, but I'll look into that.

| On the other hand it seems that SVK could be tricked to do the
| syncronization job. Gaby what are your experiences with that?
| Isn't SVK creating a copy of the SVN repository locally (also as an
| SVN repository)?

yes, it does.  At the moment I'm not familiar with the google setting
but I'll have a look into it -- which makes me look into many things :-/

\start
Date: Tue, 12 Sep 2006 07:37:48 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger


SVN checkin...

in a clean Axiom (no CVS, .arch-ids, .svn directories, etc) do:

cd ~/axiom/..
ls -lR axiom >foo
 (edit foo to change each line to read  svn add filename)
 (edit foo to set the binary information for binary files)
sh ./foo
cd axiom
svn commit -m"first commit"

this should work. it's the method i used to create the CVS
systems because if you've been on this this list long enough
you can remember the
   axiomgnu/new/axiom.... 
import debacle. one slip of the command and you'll live with the
mistake for a long time since these hosts don't like deleting
information.

it has the added benefit that you can set up the binary file info
before svn guesses wrong.

\start
Date: Tue, 12 Sep 2006 14:37:14 +0200
From: Kai Kaminski
To: Bill Page
Subject: Re: A Canonical Axiom GUI

Bill Page writes:

> Cliff Yapp writes:
>> ... 
>>>>> 1.  I think a default GUI for Axiom would be a Very Good Thing
>>>
>>>Kai Kaminski wrote:
>>>> As I said, I'm not convinced.
>
> I am convinced that trying to build a graphical user interface that
> works only with Axiom would *not* be a good thing.
>
>> >
>> > No worries.  There is plenty of room here for differing 
>> > opinions :-).
>>
> On September 8, 2006 9:56 AM Kai Kaminski wrote:
>> Don't kid yourself. There's barely enough room for mine. ;-)
>>
>
> I do appreciate the sentiment in Kai's remark, which he indicates
> we should take as humour. But I am worried that some people who are
> potential contributors to this discussion might well perceive it
> as fact. If so, I think that is very unfortunate. Axiom is a very
> small project in terms of the number of active and vocal developers
> so it is easy to give the wrong impression. My opinions about Axiom
> development differ from other people on this list on a number of
> points and I don't feel shy about saying so. Is that setting an
> example or reinforcing the feeling that there is no more room for
> other opinions? :(

> Perhaps we need to do more to make sure that people feel like there
> is room here for differing opinions and that we would really like to
> hear them.
>
>>>>> 2.  The project is not yet at a point where this should be a
>>>>>     major focus for the project as a whole.
>>>>
>>>> That depends on what you mean. I believe the most important thing
>>>> is to make it developer friendly.
>
> Yes!
>
>>>> In particular we must be able to use all the open source Lisp
>>>> libraries that are available. Also, writing tools (especially
>>>> GUIs) for Axiom should be easy.
>
> While I would welcome anyone interesting in working on Axiom at the
> level of the Lisp code, I seriously doubt whether compatibility of
> Axiom with other open source Lisp libraries would make Axiom more
> "friendly" to such developers. Or did you have some specific
> libraries in mind that would have immediate application and mass
> appeal?
This is not about making Axiom attractive to random Lisp
developers. It's about making Axiom development easier by allowing the
use of existing libraries and tools. Also, by packaging certain
functionality into a library that is indepent of Axiom, we might get
people to work on that, if they have similar needs.

On common-lisp.net you can find lots of useful libraries for GUIs,
threads, file and directory operations, databases, XML parsing,
parsing in general, data compression, logging, text processing, type
setting, scientific computing and other things.

\start
Date: Tue, 12 Sep 2006 11:35:31 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: SVN on sourceforge

i set out to fix the silver version.
so far i tried 8 checkouts without success
and now i'm up to 20 updates, slowly grabbing pieces.
SVN on sourceforge seems broken somehow.

\start
Date: Tue, 12 Sep 2006 18:05:22 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

Why cannot we first agree on how to fix it. Just removing the SVN 
properties (svn:eol-style and svn:keywords) is probably NOT enough.

I have given a short procedure that should do the work without much trouble.

 >>So basically, the procedure would be.

 >>1) Remove the svn:keywords property from ALL files.
 >>2) Remove the svn:eol-style property from binary files (maybe even ALL
 >>   would be OK???)
 >>3) Checkout a fresh copy of silver/trunk.
 >>4) Copy all source files from --patch-50 to silver/trunk.
 >>5) Commit the change.
 >>   My wild guess is that svn only commits the files that actually
 >>   differ from the repository. I hope that svn does not take the
 >>   copy date into account.

I just have no confirmation from anybody on the list that this would be 
the right way to go.

 From what I have seen the binary property is set correctly already.

I would even do the update of the Silver TRUNK, but if nobody is 
convinced that the procedure is correct I rather hesitate to make a mess 
out of the trunk.

Ralf

On 09/12/2006 05:35 PM, root wrote:
> i set out to fix the silver version.
> so far i tried 8 checkouts without success
> and now i'm up to 20 updates, slowly grabbing pieces.
> SVN on sourceforge seems broken somehow.

\start
Date: 12 Sep 2006 12:41:27 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger, Gabriel Dos Reis

Bill Page writes:

> Gaby, 
> 
> On Monday, September 11, 2006 12:26 PM you wrote:
> > 
> > On Mon, 11 Sep 2006, root wrote:
> > 
> > | > The error from the configure is this:
> > | > *******************************************
> > | > Darwin
> > | > Your system name is Darwin
> > | > We do not know how to build for this kind of system
> > | > Send a note to list about it
> > | > *******************************************
> > |
> > |
> > | Actually, this is correct. I do not yet know how to build
> > | Axiom on a MAC. There has been a recent suggestion that we
> > | use Xcode and I'm pursuing that path.
> > 
> > Tim --
> > 
> >   Jacob is a student at TAMU taking my class on symbolic
> > computations. He is interested in provisos -- I suspect at
> > some point he may get into touch with you. He is trying to
> > build Axiom for his class work.
> > 
> > From what I understand, Bill has been able to build the
> > build-improvements branch with some patches from Camm (which
> > I believe I already put in build-improvements).
> 
> I have built the build-improvements branch on the axiom-developer
> server (in fact that is what is running on MathAction right now).
> But I think the build process still has some problems. For example,
> I am not able to build (even if I specific '--without-noweb') if
> noweb is not previously installed and in the PATH. Also, the
> option to build from a previously installed gcl does not work
> so the option '--without-gcl' is still necessary. Since building
> from pre-installed gcl is possible on Debian using the Debian
> source distribution for Axiom, there must still be something
> missing from the 'gcl-system' option in the build-improvements
> branch.

Please let me know if you need any help or clarification here.  All my
patches are under the debian subdirectory, patch.all and patch.merge.

> 
> There is also an additional patch which I am still discussing
> with Camm to solve the "Can't rename' problem. The patch that
> I am using now might not be the ultimate solution of gcl-2.6.8.
> 

I looked at this discussion, and there does not appear to be a
consensus on probe-file and directory.  As far as GCL goes, we can do
anything that passes Paul's ansi tests, as we do at the moment.  So if
you have such a suggestion, we can implement same.

The easy way, which avoids the requirement of PDP-10 lisp
comaptability :-), is si::stat.  How about this:

Index: unixfsys.c
===================================================================
RCS file: /cvsroot/gcl/gcl/o/unixfsys.c,v
retrieving revision 1.28
diff -u -r1.28 unixfsys.c
--- unixfsys.c	24 Aug 2006 16:53:28 -0000	1.28
+++ unixfsys.c	12 Sep 2006 16:35:56 -0000
@@ -23,6 +23,7 @@
 #include <stdlib.h>
 #include <unistd.h>
 #include <errno.h>
+#include <time.h>
 
 #define IN_UNIXFSYS
 #include "include.h"
@@ -490,6 +491,34 @@
 }
 
 
+DEF_ORDINARY("DIRECTORY",sKdirectory,KEYWORD,"");
+DEF_ORDINARY("LINK",sKlink,KEYWORD,"");
+DEF_ORDINARY("FILE",sKfile,KEYWORD,"");
+
+DEFUN_NEW("STAT",object,fSstat,SI,1,1,NONE,OO,OO,OO,OO,(object path),"") {
+
+  char filename[4096];
+  struct stat ss;
+  
+
+  bzero(filename,sizeof(filename));
+  coerce_to_filename(path,filename);
+  if (lstat(filename,&ss))
+    RETURN1(Cnil);
+  else {
+    int j;
+    ctime_r(&ss.st_ctime,filename);
+    j=strlen(filename);
+    if (isspace(filename[j-1]))
+      filename[j-1]=0;
+    RETURN1(list(3,S_ISDIR(ss.st_mode) ? sKdirectory : 
+		 (S_ISLNK(ss.st_mode) ? sKlink : sKfile),
+		 make_fixnum(ss.st_size),make_simple_string(filename)));
+  }
+}
+
+
+
 DEFUN_NEW("SETENV",object,fSsetenv,SI,2,2,NONE,OO,OO,OO,OO,(object variable,object value),"Set environment VARIABLE to VALUE")
 
 {


>(si::stat "/tmp/ff1.h")

(:LINK 9 "Tue Sep 12 12:32:58 2006")

>(si::stat "/tmp/ff.h")

(:FILE 0 "Mon Dec  5 13:52:23 2005")

>(si::stat "/tmp/")

(:DIRECTORY 81920 "Tue Sep 12 12:34:53 2006")

>(si::stat "/tmp")

(:DIRECTORY 81920 "Tue Sep 12 12:34:53 2006")

>(si::stat "/tmp1")

NIL

>


If we can agree on the interface, and on the Windows and Mac
equivalents, I can get this into 2.6.8 before release.

If there are any problems with the Debian package setup, please let me
know.   Will do a new axiom release once I can get 2.6.8pre to build
on mips and m68k.

Take care,


> Until a few days ago, I was also working on the SourceForge
> compile farm - specifically on the OS X build. But SourceForge
> currently has a network configuration problem which prevents me
> from accessing their servers:
> 
> https://sourceforge.net/tracker/?func=detail&atid0001&aid=1553456&gro
> up_id=1
> 
> > I have a fix for the debian failure.  Once that is in, I would
> > like to make a tarball of build-improvements available from
> > axiom-developer.org or from SF (whichever is OK with you).
> > This is to remove the "random" checkout errors.
> > 
> 
> I also continue to see some svn checkout errors. In some cases
> on some platforms this seems to be a recoverable error by just
> repeating the 'svn co' command until the checkout completes. On
> others, the local svn archive gets unrecoverably locked. :(
> 
> I wonder if this might be another network configuration problem
> at SourceForge?
> 
> Maybe we should setup a mirror of the SourceForge SVN repository
> on the axiom-developer.org server? Then at least we would have an
> alternate site in case there is a network problem.

\start
Date: Tue, 12 Sep 2006 14:25:37 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: SVN on sourceforge
Cc: Gabriel Dos Reis

Ralf,

On Tuesday, September 12, 2006 12:05 PM you wrote:
>
> Why cannot we first agree on how to fix it. Just removing the
> SVN properties (svn:eol-style and svn:keywords) is probably
> NOT enough.
>

Agreed.

> I have given a short procedure that should do the work
> without much trouble.
>
>  >>So basically, the procedure would be.
>
>  >>1) Remove the svn:keywords property from ALL files.
>  >>2) Remove the svn:eol-style property from binary files
>       (maybe even ALL would be OK???)

I think it would be better to be selective and leave the
svn:eol-style property as set on the text files.

>  >>3) Checkout a fresh copy of silver/trunk.
>  >>4) Copy all source files from --patch-50 to silver/trunk.
>  >>5) Commit the change.
>  >>   My wild guess is that svn only commits the files that actually
>  >>   differ from the repository. I hope that svn does not take the
>  >>   copy date into account.
>

This looks like the right approach.

> I just have no confirmation from anybody on the list that
> this would be the right way to go.
>

I think you should do it.

>  From what I have seen the binary property is set correctly
>  already.
>
> I would even do the update of the Silver TRUNK, but if nobody
> is convinced that the procedure is correct I rather hesitate
> to make a mess out of the trunk.
>

I don't think you can make it any worse. :-) This is a repository
anyway, so if it turns out not so good, then we just revert it.
Rember to check Tim's "patches-49-50" file to compare his original
lisk of changes. It looks to me like the only thing Tim missed
was to delete the svn:eol-style property from the binary files.

As far as I know there have been no patches directly to trunk
that are not also in arch axiom--main-1 branch. The only real
new work in Axiom Silver is going on in build.improvements.

The sooner we get trunk fixed up, the sooner we can plan on
merging build.improvements back into trunk and then into Gold.

Thanks for you offer to help with this.

\start
Date: Tue, 12 Sep 2006 14:40:45 -0400
From: Bill Page
To: Tim Daly
Subject: RE: SVN on sourceforge
Cc: Gabriel Dos Reis

Tim,

On Tuesday, September 12, 2006 11:36 AM you wrote:
>
> i set out to fix the silver version.
> so far i tried 8 checkouts without success
> and now i'm up to 20 updates, slowly grabbing pieces.
> SVN on sourceforge seems broken somehow.
>

It is possible that you are using a proxy that does not
understand the full WebDAV protocol as suggested in this email:
http://lists.ofbiz.org/pipermail/dev/2004-August/006333.html

------

We are behind a squid 2.3 http proxy which doesn't know about
WebDAV protocoll. It uses special requests which are been blocked
by squid. Solution1:
like you noted using https (squid simply forwards the ssl packets)

Solution 2:
extend the squid.conf file to support the webdav requests:
# add WebDAV methods
extension_methods SEARCH PROPFIND PROPPATCH MKCOL MOVE BMOVE DELETE
BDELETE REPORT

--------

It used to be the case that most proxies ignored encrypted packets
such as generated by https, but that may no longer be the case.

I think it would be worth checking if you are using a proxy
(sometimes this is hard to tell because the proxy can be
embedded in your corporate or ISP firewall) and if it can be
configured for the above WebDAV methods.

For me this problem is highly dependent on where I am located.
At home the problem is severe. At work the problem is intermittant.
On the axiom-developer.org server the problem does not occur at
all.

\start
Date: Tue, 12 Sep 2006 15:48:49 -0400
From: Tim Daly
To: Bill Page
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

i'm not behind a proxy.
i'm hardwired to the net.

\start
Date: Tue, 12 Sep 2006 16:27:45 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: [build-improvements] support system-install GCL

Gaby,

On Tue, 12 Sep 2006 I wrote:
> |
> | I don't have access to a mac right now, but I can confirm
> | that the following commands build Axiom just fine on
> | axiom-developer.org with both noweb and gcl pre-installed.
>

Here is another report:

I have successfully built the Axiom Silver build.improvements
branch on a Sun 280R (sparc, 64bit) Solaris 10 06/06 system with
a full GNU toolchain installed.

bash-2.05$ gcc --version
gcc (GCC) 4.1.1

bash-2.05$ ld --version
GNU ld version 2.17

bash-2.05$ make --version
GNU Make 3.80

bash-2.05$ awk --version
GNU Awk 3.1.5

etc.

I built and installed GCL separately from the Axiom build.
I really like this option. :-) I think it makes the whole
build easier.

bash-2.05$ svn co https://svn.sourceforge.net/svnroot/axiom/ \
             branches/build-improvements axiom.build-improvements

bash-2.05$ svn co https://svn.sourceforge.net/svnroot/axiom/ \
         branches/build-improvements axiom.build-improvements

bash-2.05$ tar xzvf axiom.build-improvements/zips/gcl-2.6.8pre.tgz

But it wasn't quite so easy... A patch is necessary to build GCL.

bash-2.05$ cp gcl-2.6.8pre gcl-2.6.8pre_orig

----------
bash-2.05$ diff -Naur gcl-2.6.8pre_orig gcl-2.6.8pre
diff -Naur gcl-2.6.8pre_orig/h/solaris.defs gcl-2.6.8pre/h/solaris.defs
--- gcl-2.6.8pre_orig/h/solaris.defs    2004-07-15 12:28:44.000000000
-0400
+++ gcl-2.6.8pre/h/solaris.defs 2006-09-12 13:15:58.280649000 -0400
@@ -1,15 +1,18 @@

-# notes for redhat 6.0
-#  the configure should select the compiler
GCC=/usr/bin/i386-glibc20-linux-gcc
-#  However for the gcl-tk directory, you must use plain 'gcc' since
-#  that must link with the tcl tk libs which have been compiled with
it.
-#  so after configure change to GCC=gcc in the gcl-tk/makefile
+# notes for Solaris

+# Machine dependent makefile definitions for Solaris 9, 10
+# running a full GNU toolchain. This might not work on a
+# pure Sun configuration.

-# Machine dependent makefile definitions for intel 386,486 running
linux
+# Modified: Sept 12, 2006 Bill Page

 LBINDIR=/usr/local/bin

+# We need these flags to get the right options for sockio.h
+# and memalign
+CFLAGS := ${CFLAGS} -DBSD_COMP=bsd_comp -DGNUMALLOC=gnumalloc
+
 #OFLAG =  -g -Wall
 #OFLAG =  -g -Wall -fomit-frame-pointer -Werror
 #LIBS  = -lm

---------

Probably the GCL build should to be updated to properly detect at
least the two major toolchain configurations on Sun Solaris systems:
Sun native and GNU. Over time, these seem to be converging but there
are still significant differences.

Apparently GCL must be built in its own source directory. When I
tried to build GCL using lndir to ghost the source tree, GCL built
and ran but it would not properly perform a compiler::link function.
It returned an error message contain ~A format character where a
file name should have been.

bash-2.05$ cd gcl-2.6.8pre
bash-2.05$ ./configure --disable-emacsdir --disable-tkconfig \
                       --disable-tclconfig --disable-xgcl

bash-2.05$ nohup make&

bash-2.05$ tail -f nohup.out

bash-2.05$ su

bash-2.05# make install

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

Some patches were also necessary to the Axiom sources.

bash-2.05$ cp axiom.build-improvements \
              axiom.build-improvements_orig

To work around problems with X11 include file paths in the first
part of the build, I set the following environment variable:

bash-2.05$ export CPATH=/usr/openwin/share/include

"CPATH specifies a list of directories to be searched as if
specified with -I, but after any paths given with -I options
on the command line."

A better solution might be to include the 'AXIOM_X11_CFFLAGS'
variable in the CFLAGS option in those builds that reference
the X11 libraries and include files. Something like this:

----------
bash-2.05$ diff -Nau
axiom.build-improvements_orig/src/lib/Makefile.pamphlet \
    axiom.build-improvements/src/lib/Makefile.pamphlet
--- axiom.build-improvements_orig/src/lib/Makefile.pamphlet
2006-09-12 14:48:19.390563000 -0400
+++ axiom.build-improvements/src/lib/Makefile.pamphlet  2006-09-12
16:13:52.104054000 -0400
@@ -17,7 +17,7 @@
 OUT=${OBJ}/${SYS}/lib
 DOCINT=${INT}/doc/src/lib
 DOCMNT=${MNT}/${SYS}/doc/src/lib
-INC= $(axiom_src_srcdir)/include
+INC= $(axiom_src_srcdir)/include ${AXIOM_X11_CFLAGS}

 AR=    ${OUT}/bsdsignal.o  ${OUT}/cursor.o ${OUT}/edin.o     \
         ${OUT}/fnct_key.o   ${OUT}/halloc.o ${OUT}/openpty.o  \

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

Warning: I have not tested the above patch yet.

This patch corrects and error in building debugsys

-----------
diff -Naur -x .svn -x Makefile -x '*.in' -x '*.dvi' -x '*.log' -x
'*.tex' -x '*.
toc' -x '*.aux' -x '*.mk' -x '*.lisp' -x '*.c' -x nohup.out
axiom.build-improvem
ents_orig/src/interp/debugsys.lisp.pamphlet
axiom.build-improvements/src/interp/
debugsys.lisp.pamphlet
--- axiom.build-improvements_orig/src/interp/debugsys.lisp.pamphlet
2006-09-
12 14:33:52.828375000 -0400
+++ axiom.build-improvements/src/interp/debugsys.lisp.pamphlet
2006-09-12 15:00
:03.637137000 -0400
@@ -79,6 +79,18 @@
 The [[*build-version*]] variable is only introduced into the system
 from the Makefile. Since this isn't going thru the Makefile when
 loaded by hand we need to establish a value.
+
+These names must be adjusted if necessary to reflect the
+platform name. So:
+
+      (thesymb "/obj/linux/interp/sockio.o")
+
+is wrong but
+
+       (thesymb (concatenate 'string "/obj/" *sys* "/interp/sockio.o"))
+
+is ok.  (Sept 12, 2006  Bill Page)
+
 <<*>>=
 (setq *build-version* "debug")
 (build-interpsys
@@ -169,7 +181,6 @@
       (thesymb "/int/interp/simpbool.clisp")
       (thesymb "/int/interp/slam.clisp")
       (thesymb (concatenate 'string "/obj/" *sys* "/interp/sockio.o"))
-      (thesymb "/obj/linux/interp/sockio.o")
       (thesymb "/int/interp/spad.lisp")
       (thesymb "/int/interp/spaderror.lisp")
       (thesymb "/int/interp/template.clisp")

This patch adds the X11 libraries to sman and friends.

--------

diff -Naur -x .svn -x Makefile -x '*.in' -x '*.dvi' -x '*.log' -x
'*.tex' -x '*.
toc' -x '*.aux' -x '*.mk' -x '*.lisp' -x '*.c' -x nohup.out
axiom.build-improvem
ents_orig/src/sman/Makefile.pamphlet
axiom.build-improvements/src/sman/Makefile.
pamphlet
--- axiom.build-improvements_orig/src/sman/Makefile.pamphlet
2006-09-12 14:15
:44.112706000 -0400
+++ axiom.build-improvements/src/sman/Makefile.pamphlet 2006-09-12
13:51:33.2870
37000 -0400
@@ -10,6 +10,9 @@
 \tableofcontents
 \eject
 \section{Environment variables}
+The LDFLAGS must include the AXIOM_X11_LDFLAGS so that
+the loader can find the X11 libraries on non-standard
+configurations.  (Sept 12, 2006 Bill Page)
 <<environment>>=
 # this is where we are compiling from
 IN=     $(axiom_src_srcdir)/sman
@@ -33,7 +36,8 @@
 # this is where the documentation ends up
 DOC=    ${MNT}/${SYS}/doc/src/sman
 CFLAGS=        ${CCF}
-LDFLAGS= -L${LIB} -lspad ${LDF}
+# LDFLAGS= -L${LIB} -lspad ${LDF}
+LDFLAGS= -L${LIB} -lspad ${LDF} -lspad ${AXIOM_X11_LDFLAGS}

 DOCFILES=${DOC}/session.c.dvi ${DOC}/nagman.c.dvi ${DOC}/sman.c.dvi \
          ${DOC}/spadclient.c.dvi
@@ -45,7 +49,7 @@
 <<session>>=
 ${OUTLIB}/session: ${SMANOBJS} ${MIDOBJ}/session.o
        @ echo 1 linking session
-       @ ${CC} -o ${OUTLIB}/session ${MIDOBJ}/session.o ${SMANOBJS}
+       @ ${CC} -o ${OUTLIB}/session ${MIDOBJ}/session.o ${SMANOBJS}
${LDFLAGS}

 ${MID}/session.c: ${IN}/session.c.pamphlet
        @ echo 2 making ${MID}/session.c from ${IN}/session.c.pamphlet
@@ -71,7 +75,7 @@
 <<nagman>>=
 ${OUT}/nagman: ${SMANOBJS} ${MIDOBJ}/nagman.o
        @ echo 5 linking nagman
-       @ ${CC} -o ${OUT}/nagman ${MIDOBJ}/nagman.o ${SMANOBJS}
+       @ ${CC} -o ${OUT}/nagman ${MIDOBJ}/nagman.o ${SMANOBJS}
${LDFLAGS}

 ${MID}/nagman.c: ${IN}/nagman.c.pamphlet
        @ echo 6 making ${MID}/nagman.c from ${IN}/nagman.c.pamphlet
@@ -95,7 +99,7 @@
 <<spadclient>>=
 ${OUTLIB}/spadclient: ${SMANOBJS} ${MIDOBJ}/spadclient.o
        @ echo 9 linking spadclient
-       @ ${CC} -o ${OUTLIB}/spadclient ${MIDOBJ}/spadclient.o
${SMANOBJS}
+       @ ${CC} -o ${OUTLIB}/spadclient ${MIDOBJ}/spadclient.o
${SMANOBJS} ${LD
FLAGS}

 ${MID}/spadclient.c: ${IN}/spadclient.c.pamphlet
        @ echo 10 making ${MID}/spadclient.c from
${IN}/spadclient.c.pamphlet
@@ -119,7 +123,7 @@
 <<sman>>=
 ${OUT}/sman: ${SMANOBJS} ${MIDOBJ}/sman.o
        @ echo 13 linking sman
-       @ ${CC} -o ${OUT}/sman ${MIDOBJ}/sman.o ${SMANOBJS}
+       @ ${CC} -o ${OUT}/sman ${MIDOBJ}/sman.o ${SMANOBJS} ${LDFLAGS}

 ${MID}/sman.h: ${IN}/sman.c.pamphlet
        @ echo 00 making ${MID}/sman.h from ${IN}/sman.c.pamphlet

---------

With the new build.improvements branch we can now do an out-of-source
build for Axiom. :)

bash-2.05$ mkdir axiom.build
bash-2.05$ cd axiom.build
bash-2.05$ ../axiom.build-improvements/configure
bash-2.05$ nohup make&
bash-2.05$ tail -f nohup.out

To perform the install we need another simple patch:

---------
bash-2.05$ diff -Nau axiom.build-improvements_orig/Makefile.pamphlet \
  axiom.build-improvements/Makefile.pamphlet
--- axiom.build-improvements_orig/Makefile.pamphlet     2006-09-12
14:11:30.204909000 -0400
+++ axiom.build-improvements/Makefile.pamphlet  2006-09-12
15:31:00.802527000 -0400
@@ -625,7 +625,11 @@
 @
 \subsection{install}
 <<install>>=
+.PHONY:        install
 install:
+       $(PATH_EXPORTS) $(MAKE) do-install
+
+do-install:
        @echo 78 installing Axiom in ${DESTDIR}
        @mkdir -p ${DESTDIR}
        @cp -pr ${MNT} ${DESTDIR}

----------
bash-2.05$ su
bash-2.05# make install

78 installing Axiom in /usr/local/axiom
79 Axiom installation finished.

Please add /usr/local/axiom/mnt/solaris9/bin to your PATH variable
Start Axiom with the command axiom

make[1]: Leaving directory `/export/home/dmprod/axiom.build'

bash-2.05$ export PATH=/usr/local/axiom/mnt/solaris9/bin:$PATH
bash-2.05$ AXIOMsys
GCL (GNU Common Lisp)  2.6.8 CLtL1    Sep 12 2006 05:57:14
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
                        AXIOM Computer Algebra System
          Version: Axiom (build improvements branch) -- 2006-09-12
            Timestamp: Wednesday September 13, 2006 at 00:52:01
------------------------------------------------------------------------
-----
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
------------------------------------------------------------------------
-----

   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase
(1) ->

\start
Date: Tue, 12 Sep 2006 16:46:53 -0400
From: Bill Page
To: Tim Daly, Bill Page
Subject: RE: SVN on sourceforge
Cc: Gabriel Dos Reis

On Tuesday, September 12, 2006 3:49 PM Tim Daly wrote:
>
> i'm not behind a proxy.
> i'm hardwired to the net.
>

Me too, baby. :)) And proxies are hardwired too. ((:

Whether you connect via a proxy or not can be quite transparent
to you - they hide everywhere these days: inside NAT routers,
in ISP firewalls, and NSA computers... A proxy is just a stateful
process that sits between you and the rest of the world, limiting
the type of transactions that can pass on a given port (and doing
whatever else they want to do with your transactions).

But you might be right that you are not behind such a proxy.

Anyway, the idea that proxies can cause problems with the WebDAV
protocol used by SVN seems to be quite common on the Web. But
(usually) this does not apply to encrypted transactions sent via
https. And we are already use https.

\start
Date: Tue, 12 Sep 2006 18:48:04 -0400
From: Alfredo Portes
To: axiom-developer <list>
Subject: Disk Quota Google

Higuer powers :-) (Bill, Tim, Gaby, Ralf...),

Trying to commit the Silver source to the Google repository, I had the
problem
of going over the disk quota limit. (100 MB).

I email google and they asking me what size we need.

If you can advise me on what size would be good?

\start
Date: 13 Sep 2006 01:19:40 +0200
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: Disk Quota Google

Alfredo Portes writes:

| Higuer powers :-) (Bill, Tim, Gaby, Ralf...),
| 
| Trying to commit the Silver source to the Google repository, I had the
| problem
| of going over the disk quota limit. (100 MB).

Hey, they must be kidding... :-)
full source of Axiom silver is about 114M

| I email google and they asking me what size we need.
| 
| If you can advise me on what size would be good?

20G should be probably be OK for the next few years -- if we don't
have a surge of interest :-).

\start
Date: 13 Sep 2006 01:21:45 +0200
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: Disk Quota Google

Alfredo Portes writes:

| Higuer powers :-) (Bill, Tim, Gaby, Ralf...),
| 
| Trying to commit the Silver source to the Google repository, I had the
| problem
| of going over the disk quota limit. (100 MB).
| 
| I email google and they asking me what size we need.
| 
| If you can advise me on what size would be good?

Alfredo --

when you get a chance to commit, make sure that the source files don't
(except configure and friends) get the executable file bit set -- that
is unfortunately the same with Axiom gold and silver.

\start
Date: Tue, 12 Sep 2006 19:26:18 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Disk Quota Google

Alfredo,

On Tuesday, September 12, 2006 6:48 PM you asked:
=09
> Trying to commit the Silver source to the Google repository,
> I had the problem of going over the disk quota limit. (100 MB).
>
> I email google and they asking me what size we need.
>=09
>If you can advise me on what size would be good?
>=09

Currently the arch repository axiom--main--1 is 169,896 Kbytes
computed using 'du -K B'. I expect that svn trunk is about the
same size. (It is actually inflated because of old zip files and
other junk.)

There will be several Axiom Silver branchs, would guess many
100 Mbytes each... Gaby has been removing the cruft but svn is
more of a pig for storage than arch. The build.improvements
branch seems to occupy 267,772 Kbytes on axiom-developer.org.

Maybe we should run some kind of packing job?

So I would suggest that you ask for at least 1000 Mbytes -
more if they don't think you are crazy. :-)

\start
Date: Tue, 12 Sep 2006 18:28:49 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: [build-improvements] support system-install GCL

On Tue, 12 Sep 2006, Page, Bill wrote:

| Gaby,
|
| On Tue, 12 Sep 2006 I wrote:
| > |
| > | I don't have access to a mac right now, but I can confirm
| > | that the following commands build Axiom just fine on
| > | axiom-developer.org with both noweb and gcl pre-installed.
| >
|
| Here is another report:

I like it!
:-)

Hmm, now this means I can no longer mess the build-improvements branch
without having Bill after me :-) :-)

I'll set priority to integrate your suggestion and merge a good part
of build-improvements to silver (after extensive testing and all
that).  Which means I have tp get back to Ralf soon.

I have more work on the makefile simplification in the pipeline, and I
would like to have them in.  I would like to support parallel build of
Axiom, because it takes just too long to compile sequentially.  I
don't have that implemented yet.  But good part of the work is in
testing.

I'll work with Camm for the GCL bits.

\start
Date: Tue, 12 Sep 2006 18:32:39 -0500 (CDT)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

On Tue, 12 Sep 2006, Camm Maguire wrote:

[...]

| > I have built the build-improvements branch on the axiom-developer
| > server (in fact that is what is running on MathAction right now).
| > But I think the build process still has some problems. For example,
| > I am not able to build (even if I specific '--without-noweb') if
| > noweb is not previously installed and in the PATH. Also, the
| > option to build from a previously installed gcl does not work
| > so the option '--without-gcl' is still necessary. Since building
| > from pre-installed gcl is possible on Debian using the Debian
| > source distribution for Axiom, there must still be something
| > missing from the 'gcl-system' option in the build-improvements
| > branch.
|
| Please let me know if you need any help or clarification here.  All my
| patches are under the debian subdirectory, patch.all and patch.merge.

Hi Camm,

  I fixed that part in Axiom.  It turns out to be a problem in Axiom's
build setup instead of GCL -- as I erroneously suspected earlier.

I would like to support parallel build but that will not happen for
gcl-2.6.8.

The file stat stuff is more urgent.

\start
Date: 13 Sep 2006 01:35:05 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Disk Quota Google

Bill Page writes:

[...]

| svn is more of a pig for storage than arch. 

ys, SVN is space hungry.  That is one of the main reason why I use SVK
-- it has a better file-sharing algorithms (plus other goodies).  But
SVK works over SVN.

[...]

| So I would suggest that you ask for at least 1000 Mbytes -
| more if they don't think you are crazy. :-)


there is a chance that they will give the lower he ask -- so I will go
for higher.  SVN becomes very hungry as the number of branches grows.

\start
Date: 12 Sep 2006 18:45:54 -0500
From: Gabriel Dos Reis
To: list
Subject: Remove some Makefile variables

this is a low hanging fruit toward simplification of the makefiles.
None of the following variables are needed in Makefile.${SYS}.

Tested on an x86_64-suse-linux

-- Gaby

2006-09-12  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet (CC): Remove explicit setting throughout.
	This is now present in each makefile -- except toplevel
	Makefile.${SYS} but, it is not used there anyway.
	Don't pass explicitly in ENV.
	(AWK): Likewise.
	(TOUCH): Likewise.
	(TAR): Likewise.
	(RANLIB): Likewise.
	(PATCH): Likewise.

*** Makefile.in	(revision 15075)
--- Makefile.in	(local)
*************** ENV= SPAD=${SPAD} SYS=${SYS} SPD=${SPD} 
*** 32,38 ****
       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} \
!      TANGLE=${TANGLE} VERSION=${VERSION} PATCH=${PATCH} \
       DOCUMENT=${axiom_build_document} DAASE=$(DAASE) \
       WEAVE=${WEAVE} AXIOM_X11_CFLAGS="${AXIOM_X11_CFLAGS}" \
       AXIOM_X11_LDFLAGS="${AXIOM_X11_LDFLAGS}"
--- 32,38 ----
       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} \
!      TANGLE=${TANGLE} VERSION=${VERSION} \
       DOCUMENT=${axiom_build_document} DAASE=$(DAASE) \
       WEAVE=${WEAVE} AXIOM_X11_CFLAGS="${AXIOM_X11_CFLAGS}" \
       AXIOM_X11_LDFLAGS="${AXIOM_X11_LDFLAGS}"
*** Makefile.pamphlet	(revision 15075)
--- Makefile.pamphlet	(local)
*************** ENV= SPAD=${SPAD} SYS=${SYS} SPD=${SPD} 
*** 380,386 ****
       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} \
!      TANGLE=${TANGLE} VERSION=${VERSION} PATCH=${PATCH} \
       DOCUMENT=${axiom_build_document} DAASE=$(DAASE) \
       WEAVE=${WEAVE} AXIOM_X11_CFLAGS="${AXIOM_X11_CFLAGS}" \
       AXIOM_X11_LDFLAGS="${AXIOM_X11_LDFLAGS}"
--- 380,386 ----
       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} \
!      TANGLE=${TANGLE} VERSION=${VERSION} \
       DOCUMENT=${axiom_build_document} DAASE=$(DAASE) \
       WEAVE=${WEAVE} AXIOM_X11_CFLAGS="${AXIOM_X11_CFLAGS}" \
       AXIOM_X11_LDFLAGS="${AXIOM_X11_LDFLAGS}"
*************** PLF=BSDplatform
*** 812,821 ****
  CCF="-O2 -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/local/include"
  # Loader flags
  LDF="-L/usr/local/lib"
- # C compiler to use
- CC=gcc 
- RANLIB=ranlib
- TOUCH=touch
  AXIOMXLROOT=${AXIOM}/compiler
  O=o
  BYE=bye
--- 812,817 ----
*************** LISP=lsp
*** 823,832 ****
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
!     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} PATCH=${PATCH} TANGLE=${TANGLE}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.FreeBSD called
--- 819,828 ----
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
!     AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} TANGLE=${TANGLE}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.FreeBSD called
*************** PLF=MSYSplatform
*** 855,864 ****
  CCF="-O2 -Wall -D_GNU_SOURCE -D${PLF}"
  # Loader flags
  LDF=
- # C compiler to use
- CC=gcc 
- RANLIB=ranlib
- TOUCH=touch
  AXIOMXLROOT=${AXIOM}/compiler
  O=o
  BYE=bye
--- 851,856 ----
*************** LISP=lsp
*** 866,875 ****
  <<GCLOPTS>>
  SRCDIRS=bootdir interpdir sharedir algebradir etcdir docdir inputdir
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
!     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.windows called
--- 858,867 ----
  <<GCLOPTS>>
  SRCDIRS=bootdir interpdir sharedir algebradir etcdir docdir inputdir
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
!     AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.windows called
*************** PLF=LINUXplatform
*** 896,905 ****
  CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
  # Loader flags
  LDF=
- # C compiler to use
- CC=gcc 
- RANLIB=ranlib
- TOUCH=touch
  AXIOMXLROOT=${AXIOM}/compiler
  O=o
  BYE=bye
--- 888,893 ----
*************** LISP=lsp
*** 907,916 ****
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
!     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.linux called
--- 895,904 ----
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
!     AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.linux called
*************** PLF=LINUXplatform
*** 940,949 ****
  CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
  # Loader flags
  LDF=
- # C compiler to use
- CC=gcc 
- RANLIB=ranlib
- TOUCH=touch
  AXIOMXLROOT=${AXIOM}/compiler
  O=o
  BYE=bye
--- 928,933 ----
*************** LISP=lsp
*** 951,960 ****
  <<GCLOPTS-LOCBFD>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
!     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.linux called
--- 935,944 ----
  <<GCLOPTS-LOCBFD>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
!     AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.linux called
*************** PLF=LINUXplatform
*** 981,990 ****
  CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
  # Loader flags
  <<fedora64 loader flags>>
- # C compiler to use
- CC=gcc 
- RANLIB=ranlib
- TOUCH=touch
  AXIOMXLROOT=${AXIOM}/compiler
  O=o
  BYE=bye
--- 965,970 ----
*************** LISP=lsp
*** 992,1001 ****
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
!     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.linux called
--- 972,981 ----
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
!     AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.linux called
*************** PLF=LINUXplatform
*** 1018,1027 ****
  CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
  # Loader flags
  LDF=
- # C compiler to use
- CC=gcc 
- RANLIB=ranlib
- TOUCH=touch
  AXIOMXLROOT=${AXIOM}/compiler
  O=o
  BYE=bye
--- 998,1003 ----
*************** LISP=lsp
*** 1029,1038 ****
  <<GCLOPTS-LOCBFD>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
!     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.linux called
--- 1005,1014 ----
  <<GCLOPTS-LOCBFD>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
!     AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.linux called
*************** PLF= LINUXplatform
*** 1054,1063 ****
  CCF=" -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE  -D${PLF}"
  # Loader flags
  LDF=
- # C compiler to use
- CC= gcc 
- RANLIB=ranlib
- TOUCH=/usr/5bin/touch
  AXIOMXLROOT=${AXIOM}/compiler
  O=o
  BYE=bye
--- 1030,1035 ----
*************** LISP=lisp
*** 1065,1074 ****
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
!     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 48 Makefile.linuxglibc called
--- 1037,1046 ----
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
!     AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 48 Makefile.linuxglibc called
*************** PLF= LINUXplatform
*** 1090,1099 ****
  CCF=" -g  -Wall -D_GNU_SOURCE  -D${PLF}"
  # Loader flags
  LDF=
- # C compiler to use
- CC= gcc 
- RANLIB=ranlib
- TOUCH=/usr/5bin/touch
  AXIOMXLROOT=${AXIOM}/compiler
  O=o
  BYE=bye
--- 1062,1067 ----
*************** LISP=lisp
*** 1101,1110 ****
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
!     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 51 Makefile.linuxglibc2.1 called
--- 1069,1078 ----
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
!     AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 51 Makefile.linuxglibc2.1 called
*************** PLF=LINUXplatform
*** 1131,1140 ****
  CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
  # Loader flags
  LDF=
- # C compiler to use
- CC=gcc 
- RANLIB=ranlib
- TOUCH=touch
  AXIOMXLROOT=${AXIOM}/compiler
  O=o
  BYE=bye
--- 1099,1104 ----
*************** LISP=lsp
*** 1142,1151 ****
  <<GCLOPTS-LOCBFD>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
!     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.linux called
--- 1106,1115 ----
  <<GCLOPTS-LOCBFD>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
!     AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.linux called
*************** PLF= SUN4OS5platform
*** 1168,1178 ****
  CCF=" -O3 -D__EXTENSIONS__ -Wall -ansi -D${PLF} -I /usr/openwin/include"
  # Loader flags
  LDF=-L /usr/openwin/lib -lnsl -lsocket 
- # C compiler to use
- CC= gcc
- AWK=/systems/pub/sun4/gawk
- TOUCH=/bin/touch
- RANLIB= ar tvs 
  AXIOMXLROOT=${AXIOM}/compiler
  O=o
  BYE=bye
--- 1132,1137 ----
*************** LISP=lisp
*** 1180,1189 ****
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
!     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 69 Makefile.sun4os55g called
--- 1139,1148 ----
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
!     AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 69 Makefile.sun4os55g called
*************** PLF= SUNplatform
*** 1206,1217 ****
  CCF=" -O -D${PLF} -I/usr/openwin/include"
  # Loader flags
  LDF= -L/usr/openwin/lib
- # C compiler to use
- CC= gcc
- AWK="/systems/pub/sun4/gawk -W version -W compat"
- RANLIB=ranlib
- TOUCH=/usr/5bin/touch
- TAR=/usr/local/bin/gnutar
  AXIOMXLROOT=${AXIOM}/compiler
  O=o
  BYE=bye
--- 1165,1170 ----
*************** LISP=lisp
*** 1219,1228 ****
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
!     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 75 Makefile.sung called
--- 1172,1181 ----
  <<GCLOPTS>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
!     AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 75 Makefile.sung called
*************** low level C socket code (in particular, 
*** 1242,1250 ****
  we change the platform variable to be [[MACOSXplatform]] and create
  this new stanza.
  
- Also it appears that the MAC OSX does not include gawk or nawk by 
- default so we change the [[AWK]] variable to use [[awk]].
- 
  We need to add [[-I/usr/include/sys]] because [[malloc.h]] has been
  moved on this platform. 
  
--- 1195,1200 ----
*************** CCF="-O2 -fno-strength-reduce -Wall -D_G
*** 1261,1271 ****
       -I/usr/include -I/usr/include/sys"
  # Loader flags
  LDF=
- # C compiler to use
- CC=gcc 
- AWK=awk
- RANLIB=ranlib
- TOUCH=touch
  AXIOMXLROOT=${AXIOM}/compiler
  O=o
  BYE=bye
--- 1211,1216 ----
*************** LISP=lsp
*** 1273,1282 ****
  <<GCLOPTS-CUSTRELOC>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
!     TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.linux called
--- 1218,1227 ----
  <<GCLOPTS-CUSTRELOC>>
  <<SRCDIRS>>
  
! ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
!     AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
      LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
!     SRCDIRS=${SRCDIRS}
  
  all: stamp-rootdirs srcsetup lspdir srcdir
  	@echo 45 Makefile.linux called


\start
Date: Tue, 12 Sep 2006 20:46:12 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: [build-improvements] support system-install GCL

Be sure you test your build on Fedora Core 5.
I had to special case that platform.

\start
Date: Tue, 12 Sep 2006 19:59:48 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [build-improvements] support system-install GCL

On Tue, 12 Sep 2006, root wrote:

| Gaby,
|
| Be sure you test your build on Fedora Core 5.
| I had to special case that platform.

yes, testing on as many as supported platforms is a prerequisite for
merge to silver.  At this point, I'm still working on an experimental
branch.   I would like to move as quickly as possible to the big
picture and fix the missing bits as I get access to more platforms.

I have no access to a Fedora Core 5, nor a *BSD platform.  IT is
essential for me to get Axiom build on MACs though.
Any help is much appreciated.

\start
Date: Tue, 12 Sep 2006 22:39:43 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: [build-improvements] support system-install GCL

[arch@tower bi]$ ./configure
checking build system type... i686-pc-linux
checking host system type... i686-pc-linux
checking target system type... i686-pc-linux
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for gawk... gawk
checking for gtar... gtar
checking for gpatch... no
checking for patch... patch
checking for make... make
checking for ranlib... ranlib
checking for touch... touch
checking for latex... latex
checking for makeindex... makeindex
checking for notangle... no
checking for noweave... no
checking for gcl... no
checking how to run the C preprocessor... gcc -E
checking for X... libraries , headers 
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
configure: SYSNAME=Fedora Core release 5 (Bordeaux)
configure: Linux
configure: creating ./config.status
config.status: creating Makefile
config.status: creating lsp/Makefile
config.status: creating src/Makefile
config.status: creating src/lib/Makefile
config.status: creating src/boot/Makefile
config.status: creating src/interp/Makefile
config.status: creating src/share/Makefile
config.status: creating src/algebra/Makefile
config.status: creating src/etc/Makefile
config.status: creating src/clef/Makefile
config.status: creating src/doc/Makefile
config.status: creating src/graph/Makefile
config.status: creating src/graph/Gdraws/Makefile
config.status: creating src/graph/view2D/Makefile
config.status: creating src/graph/view3D/Makefile
config.status: creating src/graph/viewAlone/Makefile
config.status: creating src/graph/viewman/Makefile
config.status: creating src/sman/Makefile
config.status: creating src/hyper/Makefile
config.status: creating src/input/Makefile
config.status: creating src/booklets/Makefile
config.status: creating build/scripts/document
[arch@tower bi]$ echo $AXIOM

[arch@tower bi]$ export AXIOM=`pwd`/mnt/linux
[arch@tower bi]$ make
cd . && autoconf
cd /home/arch/bi && /bin/sh ./config.status `echo /home/arch/bi/ | sed -e 's|/home/arch/bi/||'`Makefile
config.status: creating Makefile
AXIOM=/home/arch/bi/mnt/linux; export AXIOM; PATH=/home/arch/bi/mnt/linux/bin:${PATH}; make do-all
make[1]: Entering directory `/home/arch/bi'
13 making noweb
patching file modules.c
mnt.o: In function `emitfile':mnt.c:(.text+0x3c0): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
make[2]: [install-code] Error 1 (ignored)
make[2]: [install-tex] Error 1 (ignored)
texhash: /usr/share/texmf: directory not writable. Skipping...
texhash: /usr/share/texmf-config: directory not writable. Skipping...
texhash: /usr/share/texmf-var: directory not writable. Skipping...
texhash: /var/lib/texmf/ls-R: no write permission. Skipping...
texhash: Done.
make[2]: [install-elisp] Error 1 (ignored)
./config/mkinstalldirs /home/arch/bi/build/i686-pc-linux/share/texmf/tex && \
/home/arch/bi/build/i686-pc-linux/bin/notangle -Raxiom.sty /home/arch/bi/src/doc/axiom.sty.pamphlet > /home/arch/bi/build/i686-pc-linux/share/texmf/tex/axiom.sty
10 copying /home/arch/bi/src/scripts to /home/arch/bi/build/scripts
echo timestamp > stamp-build-scripts
1 making a linux system, PART=cprogs SUBPART=everything
2 Environment SPAD=/home/arch/bi/mnt/linux SYS=linux SPD=/home/arch/bi LSP=/home/arch/bi/lsp GCLDIR=/home/arch/bi/lsp/gcl-2.6.8pre SRC=/home/arch/bi/src INT=/home/arch/bi/int OBJ=/home/arch/bi/obj MNT=/home/arch/bi/mnt ZIPS=/home/arch/bi/zips TMP=/home/arch/bi/obj/tmp SPADBIN=/home/arch/bi/mnt/linux/bin INC=/home/arch/bi/src/include CCLBASE=/home/arch/bi/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /home/arch/bi/obj/tmp/trace GCLVERSION=gcl-2.6.8pre TANGLE=/home/arch/bi/build/i686-pc-linux/bin/notangle VERSION=Axiom (build improvements branch) -- 2006-09-12 DOCUMENT=/home/arch/bi/build/scripts/document DAASE=/home/arch/bi/src/share WEAVE=/home/arch/bi/build/i686-pc-linux/bin/noweave AXIOM_X11_CFLAGS= AXIOM_X11_LDFLAGS=-lXpm  -lSM -lICE -lX11 
make[2]: Entering directory `/home/arch/bi'
11 checking directory structure
12 Environment: SPAD=/home/arch/bi/mnt/linux SYS=linux SPD=/home/arch/bi LSP=/home/arch/bi/lsp GCLDIR=/home/arch/bi/lsp/gcl-2.6.8pre SRC=/home/arch/bi/src INT=/home/arch/bi/int OBJ=/home/arch/bi/obj MNT=/home/arch/bi/mnt ZIPS=/home/arch/bi/zips TMP=/home/arch/bi/obj/tmp SPADBIN=/home/arch/bi/mnt/linux/bin INC=/home/arch/bi/src/include CCLBASE=/home/arch/bi/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /home/arch/bi/obj/tmp/trace GCLVERSION=gcl-2.6.8pre TANGLE=/home/arch/bi/build/i686-pc-linux/bin/notangle VERSION=Axiom (build improvements branch) -- 2006-09-12 DOCUMENT=/home/arch/bi/build/scripts/document DAASE=/home/arch/bi/src/share WEAVE=/home/arch/bi/build/i686-pc-linux/bin/noweave AXIOM_X11_CFLAGS= AXIOM_X11_LDFLAGS=-lXpm  -lSM -lICE -lX11 
make[2]: Leaving directory `/home/arch/bi'
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./Makefile.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo))
(/home/arch/bi/build/i686-pc-linux/share/texmf/tex/axiom.sty)
No file Makefile.aux.
[1]
No file Makefile.toc.
[2] [3] [4]
Overfull \hbox (41.71167pt too wide) in paragraph at lines 111--115
\OT1/cmr/m/n/10 for de-bug-ging pur-poses. We use the spe-cific file \OT1/cmtt/
m/n/10 $(top_builddir)/build/stamp-scripts
[5] [6] [7] [8] [9]
Overfull \hbox (34.22025pt too wide) in paragraph at lines 347--350
[]\OT1/cmr/m/n/10 The \OT1/cmtt/m/n/10 DOCUMENT \OT1/cmr/m/n/10 vari-able is no
w set to re-place the di-rect call to the \OT1/cmtt/m/n/10 $SPADBIN/document
[10] [11] [12] [13]
Overfull \hbox (48.74657pt too wide) in paragraph at lines 516--516
[]\OT1/cmtt/m/n/10 the {\tt{}noweb.src.shell.roff.mm.patch} file remove the ins
ecure temp file[] 

Overfull \hbox (17.24684pt too wide) in paragraph at lines 516--516
[]\OT1/cmtt/m/n/10 {\tt{}noweb.src.lib.toascii.patch} because this is not a sou
rce file.[] 
[14]
Overfull \hbox (53.99652pt too wide) in paragraph at lines 516--516
[]        \OT1/cmtt/m/n/10 ${ENV} ${MAKE} BIN=${MNT}/${SYS}/bin/lib LIB=${MNT}/
${SYS}/bin/lib \[] 

Overfull \hbox (48.74657pt too wide) in paragraph at lines 516--516
[]                \OT1/cmtt/m/n/10 TEXINPUTS=${MNT}/${SYS}/bin/tex all install 
>${TMP}/trace )[] 

Overfull \hbox (22.4968pt too wide) in paragraph at lines 516--516
[]        \OT1/cmtt/m/n/10 @echo The file marks the fact that noweb has been ma
de > noweb[] 
[15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]
[30] [31] [32] [33] [34] (./Makefile.aux)

LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.

 )
(see the transcript file for additional information)
Output written on Makefile.dvi (34 pages, 55336 bytes).
Transcript written on Makefile.log.
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./Makefile.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo))
(/home/arch/bi/build/i686-pc-linux/share/texmf/tex/axiom.sty) (./Makefile.aux)
[1] (./Makefile.toc [2]) [3] [4] [5]
Overfull \hbox (41.71167pt too wide) in paragraph at lines 111--115
\OT1/cmr/m/n/10 for de-bug-ging pur-poses. We use the spe-cific file \OT1/cmtt/
m/n/10 $(top_builddir)/build/stamp-scripts
[6] [7] [8] [9] [10]
Overfull \hbox (34.22025pt too wide) in paragraph at lines 347--350
[]\OT1/cmr/m/n/10 The \OT1/cmtt/m/n/10 DOCUMENT \OT1/cmr/m/n/10 vari-able is no
w set to re-place the di-rect call to the \OT1/cmtt/m/n/10 $SPADBIN/document
[11] [12] [13] [14]
Overfull \hbox (48.74657pt too wide) in paragraph at lines 516--516
[]\OT1/cmtt/m/n/10 the {\tt{}noweb.src.shell.roff.mm.patch} file remove the ins
ecure temp file[] 

Overfull \hbox (17.24684pt too wide) in paragraph at lines 516--516
[]\OT1/cmtt/m/n/10 {\tt{}noweb.src.lib.toascii.patch} because this is not a sou
rce file.[] 
[15]
Overfull \hbox (53.99652pt too wide) in paragraph at lines 516--516
[]        \OT1/cmtt/m/n/10 ${ENV} ${MAKE} BIN=${MNT}/${SYS}/bin/lib LIB=${MNT}/
${SYS}/bin/lib \[] 

Overfull \hbox (48.74657pt too wide) in paragraph at lines 516--516
[]                \OT1/cmtt/m/n/10 TEXINPUTS=${MNT}/${SYS}/bin/tex all install 
>${TMP}/trace )[] 

Overfull \hbox (22.4968pt too wide) in paragraph at lines 516--516
[]        \OT1/cmtt/m/n/10 @echo The file marks the fact that noweb has been ma
de > noweb[] 
[16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]
[31] [32] [33] [34] [35] (./Makefile.aux) )
(see the transcript file for additional information)
Output written on Makefile.dvi (35 pages, 74776 bytes).
Transcript written on Makefile.log.
make[2]: Entering directory `/home/arch/bi'
18 making /home/arch/bi/src
make[3]: Entering directory `/home/arch/bi/src'
cd . && notangle -t8 Makefile.pamphlet > ./Makefile.in
/bin/sh: notangle: command not found
make[3]: *** [Makefile.in] Error 127
make[3]: Leaving directory `/home/arch/bi/src'
make[2]: *** [srcsetup] Error 2
make[2]: Leaving directory `/home/arch/bi'
make[1]: *** [do-all] Error 2
make[1]: Leaving directory `/home/arch/bi'
make: *** [all] Error 2
[arch@tower bi]$ exit
exit

Process shell exited abnormally with code 2

\start
Date: Tue, 12 Sep 2006 22:03:17 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [build-improvements] support system-install GCL

On Tue, 12 Sep 2006, root wrote:

| checking for notangle... no
| checking for noweave... no

[...]

| make[3]: Entering directory `/home/arch/bi/src'
| cd . && notangle -t8 Makefile.pamphlet > ./Makefile.in
| /bin/sh: notangle: command not found
| make[3]: *** [Makefile.in] Error 127
| make[3]: Leaving directory `/home/arch/bi/src'
| make[2]: *** [srcsetup] Error 2
| make[2]: Leaving directory `/home/arch/bi'
| make[1]: *** [do-all] Error 2
| make[1]: Leaving directory `/home/arch/bi'
| make: *** [all] Error 2
| [arch@tower bi]$ exit
| exit
|
| Process shell exited abnormally with code 2

To build the build-improvements branch at the moment, you need to have
noweb installed in the build environment.  I took that as a working
assumption based on past discussions.  When it is time to merge to
trunk, I'll work on reducing that requirement. (It is not hard to
remove though).

\start
Date: Tue, 12 Sep 2006 23:16:50 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: [build-improvements] support system-install GCL

yum install noweb failed.
where should i get the recommended noweb?

\start
Date: Tue, 12 Sep 2006 22:33:45 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [build-improvements] support system-install GCL

On Tue, 12 Sep 2006, root wrote:

| yum install noweb failed.

I'm puzzled.

| where should i get the recommended noweb?

I took that of Norman Ramsey.

\start
Date: Tue, 12 Sep 2006 23:36:12 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: [build-improvements] support system-install GCL

do you require a specific version or can i use the one in zips? 
i'm trying not to make assumptions so i can do a valid test of 
your makefiles.

\start
Date: Tue, 12 Sep 2006 23:55:32 -0400
From: Bill Page
To: Tim Daly
Subject: RE: [build-improvements] support system-install GCL
Cc: Gabriel Dos Reis

Tim,

>
> do you require a specific version or can i use the one in
> zips? i'm trying not to make assumptions so i can do a valid
> test of your makefiles.
>

Noweb's master distribution is here:

http://www.eecs.harvard.edu/nr/noweb/dist

You can use that if you want. The executables have to be in
the PATH. Or you can use the one in the zips directory.

If the default build '--without-noweb' had worked, the one
in the zips directory is the one that would have been built.
That is was not automatically built is a bug.

\start
Date: Tue, 12 Sep 2006 23:58:07 -0400
From: Bill Page
To: Tim Daly
Subject: RE: [build-improvements] support system-install GCL
Cc: Gabriel Dos Reis

On Tuesday, September 12, 2006 11:17 PM Tim Daly wrote:
>
> yum install noweb failed.
> where should i get the recommended noweb?
>

What's wrong with your installation of yum?

Or do you mean that noweb is not in the yum archive?

'apt-get install noweb' works fine on Debian.

\start
Date: Tue, 12 Sep 2006 23:02:32 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [build-improvements] support system-install GCL

On Tue, 12 Sep 2006, root wrote:

| do you require a specific version or can i use the one in zips?

You can use the one in the zips (just way --without-gcl) -- though I
also build with GCL-2.6.7

If you have GCL installed, configure will detect it and use it.

| i'm trying not to make assumptions so i can do a valid test of
| your makefiles.

Many thanks for your help.

\start
Date: Tue, 12 Sep 2006 23:03:51 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: [build-improvements] support system-install GCL

On Tue, 12 Sep 2006, Page, Bill wrote:

| That is was not automatically built is a bug.

it is a dependency working assumption I made.  It will be lifted -- it
is on the TODO list.

\start
Date: Wed, 13 Sep 2006 09:25:51 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Disk Quota Google
Cc: Bill Page,

On 09/13/2006 01:35 AM, Gabriel Dos Reis wrote:
> Bill Page writes:
> 
> [...]
> 
> | svn is more of a pig for storage than arch. 
> 
> ys, SVN is space hungry.

What? I previously had my private HOME directory versioned by CVS, at 
the beginning of the year I have moved to SVN for that. (I don't use the 
Berkeley DB format, but created via "svnadmin create --fs-type fsfs ...".

The CVS repository was about twice the size of my HOME, for SVN it is 
LESS THAN HOME!!! SVN zips the patches that are send to the repository.

> That is one of the main reason why I use SVK
> -- it has a better file-sharing algorithms (plus other goodies).  But
> SVK works over SVN.

I can understand the other goodies, but not the space considerations. 
SVK actually has the WHOLE original remote SVN repository stored locally 
as a "depot" under ~/.svk so that you can do things off-line. SVN just 
extracts a working copy (actually two since the files that you have 
checked out are in their original version additionally stored under the 
.svn directories.

I don't really know whether SVN or SVK needs more space.

> SVN becomes very hungry as the number of branches grows.

I don't really understand. Creating a branch is done via "svn copy". If 
you look at the size of the REPOSITORY, you'll see that it has grown 
less then 1000 Bytes. SVN is just storing that the new branch is copied 
from the some origin. The actual copying takes place at checkout time.

But anyway... 100MB at google seems a bit to less for Axiom. ;-)

\start
Date: Wed, 13 Sep 2006 09:51:44 +0200
From: Ralf Hemmecke
To: Bill Page, list
Subject: Re: SVN on sourceforge

I have just tried

date
Wed Sep 13 09:50:46 CEST 2006
svn co https://svn.sourceforge.net/svnroot/axiom/trunk trunk

for the second time. The checkout always stopped here...

A    trunk/axiom/src/include/prt.H1
A    trunk/axiom/src/include/XDither.H1
svn: REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
svn: REPORT of '/svnroot/axiom/!svn/vcc/default': Could not read 
response body:Secure connection truncated (https://svn.sourceforge.net)

Any idea what is going wrong?

\start
Date: 13 Sep 2006 09:59:45 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge

Ralf Hemmecke writes:

> I have just tried
> 
> date
> Wed Sep 13 09:50:46 CEST 2006
> svn co https://svn.sourceforge.net/svnroot/axiom/trunk trunk
> 
> for the second time. The checkout always stopped here...
> 
> A    trunk/axiom/src/include/prt.H1
> A    trunk/axiom/src/include/XDither.H1
> svn: REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
> svn: REPORT of '/svnroot/axiom/!svn/vcc/default': Could not read response
> body:Secure connection truncated (https://svn.sourceforge.net)
> 
> Any idea what is going wrong?
> 

maybe this helps: (from http://gallery.menalto.com/node/53820)


Error: Secure connection truncated

 Some users encounter this error communicating with svn.sourceforge.net,
 particularly on long running commands like checkout. Here is a response from
 Sourceforge:

While we are not sure what the cause of the problem is, the following seems to
 resolve the 'Secure connection truncated' error message that some SVN users
 have encountered. In the [global] section of the ~/.subversion/servers file,
 add the following line: http-compression = no

\start
Date: Wed, 13 Sep 2006 10:10:35 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: SVN on sourceforge

Hmmm. Maybe your suggestion is good, but after I've sent my mail, I just 
tried

cd trunk
svn update

and succeeded.

So I tried again.

svn co -r1 https://svn.sourceforge.net/svnroot/axiom/trunk trunk
cd trunk
svn update

No problem with that.

Maybe the "svn checkout" causes the problem. "svn update", however, 
works fine.

Tim, could you try to check with the -r1 option and then an update?
If that works for you (actually, I don't remember that you have given an 
explicit failure message) then we should update

http://wiki.axiom-developer.org/AxiomSources

Ralf

On 09/13/2006 09:59 AM, Martin Rubey wrote:
> Ralf Hemmecke writes:
> 
>> I have just tried
>>
>> date
>> Wed Sep 13 09:50:46 CEST 2006
>> svn co https://svn.sourceforge.net/svnroot/axiom/trunk trunk
>>
>> for the second time. The checkout always stopped here...
>>
>> A    trunk/axiom/src/include/prt.H1
>> A    trunk/axiom/src/include/XDither.H1
>> svn: REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
>> svn: REPORT of '/svnroot/axiom/!svn/vcc/default': Could not read response
>> body:Secure connection truncated (https://svn.sourceforge.net)
>>
>> Any idea what is going wrong?
>>
> 
> maybe this helps: (from http://gallery.menalto.com/node/53820)
> 
> 
> Error: Secure connection truncated
> 
>  Some users encounter this error communicating with svn.sourceforge.net,
>  particularly on long running commands like checkout. Here is a response from
>  Sourceforge:
> 
> While we are not sure what the cause of the problem is, the following seems to
>  resolve the 'Secure connection truncated' error message that some SVN users
>  have encountered. In the [global] section of the ~/.subversion/servers file,
>  add the following line: http-compression = no
> 

\start
Date: Wed, 13 Sep 2006 04:17:22 -0400
From: Tim Daly
To: Bill Page
Subject: Re: [build-improvements] support system-install GCL
Cc: Gabriel Dos Reis

> > yum install noweb failed.
> > where should i get the recommended noweb?
> > 
> 
> What's wrong with your installation of yum?
> 
> Or do you mean that noweb is not in the yum archive?
> 
> 'apt-get install noweb' works fine on Debian.

my guess is that yum is not in the fedora archives.
yum doesn't use debian so the only option is a hand install.

\start
Date: Wed, 13 Sep 2006 05:03:28 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge

well, i'd hoped that i could make a definitive test.
i modifed .subversion/servers and set http-compression=no, 
did a complete checkout, and it worked.

i unset http-compression (back to yes, i guess) in .subersion/servers,
did a complete checkout, and it worked.

so at 5a.m. EST it appears to work and nothing was proven.

it could be that http-compression causes the cpu usage to spike
when running the checkout requests and they have a ulimit or other
clamp on the host process which kills it. 

i'll rerun the same test around noon and see what results i get.

\start
Date: Wed, 13 Sep 2006 11:17:40 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

as you know, I have freshly checked out Gold (--patch-50) and Silver 
(trunk r133).

You know Silver is a mess with respect to the properties. I've just run

cd Axiom/Gold/axiom--main--1
find . -type f ! -regex '.*\.arch-ids.*' ! -regex '.*{arch}.*' -exec cmp 
{} ../../Silver/trunk/axiom/{} ';'

Of course, many of the .Z files differ.

But if you shorten the output a bit via

find . -type f ! -regex '.*\.arch-ids.*' ! -regex '.*{arch}.*' -exec cmp 
{} ../../Silver/trunk/axiom/{} ';'| perl -ne 'if (/.*\/(.*) differ:/) 
{print "$1\n"}' |sort|uniq

you'll find

ac20.pdf
bookvol1.pdf
gcl-2.6.1.cmpnew.gcl_cmpflet.lsp.patch
gcl-2.6.2.cmpnew.gcl_cmpflet.lsp.patch
gcl-2.6.2a.cmpnew.gcl_cmpflet.lsp.patch
gcl-2.6.3.cmpnew.gcl_cmpflet.lsp.patch
gcl-2.6.5.cmpnew.gcl_cmpflet.lsp.patch
gcl-2.6.5w.cmpnew.gcl_cmpflet.lsp.patch
gcl-2.6.6.cmpnew.gcl_cmpflet.lsp.patch
image.bm.Z
image.xpm.Z
libaxiom.al
manuel1.pdf
manuel2.pdf
tla-1.1.tar.gz

In particular the .patch files are interesting. In Gold they appear with 
a line ending of CR LF, in Silver it's just LF. I have the suspicion 
that tla does not take care of different system. SVN stores always the 
UNIX line endings inside the repository.

Maybe the 2.6.6 and below patches are not so important, because we are 
removing them anyway soon, but we should somehow agree on storing Unix 
line endings for source files inside the tla and svn repositories. 
Otherwise it is more difficult than just running cmp to check whether 
Gold and Silver trunk are in sync.

I'll try to get the binaries correct and leave the .patch files as they are.

BTW, Tim, why is there now also "tla-1.1.tar.gz" inside the axiom archive?

And libaxiom.al is there to avoid running the scripts from Peter 
Broadbery? But note that this thing gets out of date if ever somebody 
modifies some algebra files.

\start
Date: Wed, 13 Sep 2006 05:20:52 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

> gcl-2.6.1.cmpnew.gcl_cmpflet.lsp.patch
> gcl-2.6.2.cmpnew.gcl_cmpflet.lsp.patch
> gcl-2.6.2a.cmpnew.gcl_cmpflet.lsp.patch
> gcl-2.6.3.cmpnew.gcl_cmpflet.lsp.patch
> gcl-2.6.5.cmpnew.gcl_cmpflet.lsp.patch
> gcl-2.6.5w.cmpnew.gcl_cmpflet.lsp.patch
> gcl-2.6.6.cmpnew.gcl_cmpflet.lsp.patch

it's very curious why these have CRLF.
i'll fix that in gold in the next release.
we can fix it in silver now.

\start
Date: Wed, 13 Sep 2006 11:36:52 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

So, now I have run to check from Silver r133 to Gold (--patch-50).

Hmmm, it seems that Silver/trunk already contains a few more files than 
Gold.

Gaby, would you like to keep it that way? Or should we rather have

(tla) Gold to be = (svn) silver/trunk

??? Any patch would have to be applied to both repositories.

Ralf

cd Axiom/Silver/trunk/axiom
find . -type f ! -regex '.*\.svn/.*' -exec cmp {} 
../../../Gold/axiom--main--1/{} ';'| perl -ne 'if (/.*\/(.*) differ:/) 
{print "$1\n"}' |sort|uniq

cmp: ../../../Gold/axiom--main--1/./zips/ChangeLog: No such file or 
directory
cmp: ../../../Gold/axiom--main--1/./src/hyper/ChangeLog: No such file or 
directory
cmp: ../../../Gold/axiom--main--1/./src/algebra/ChangeLog: No such file 
or directory
cmp: ../../../Gold/axiom--main--1/./src/input/ChangeLog: No such file or 
directory
cmp: ../../../Gold/axiom--main--1/./src/boot/ChangeLog: No such file or 
directory
cmp: ../../../Gold/axiom--main--1/./src/doc/ChangeLog: No such file or 
directory
cmp: ../../../Gold/axiom--main--1/./src/lib/ChangeLog: No such file or 
directory
cmp: ../../../Gold/axiom--main--1/./lsp/ChangeLog: No such file or directory
cmp: ../../../Gold/axiom--main--1/./PATCH49-50/configure.patch: No such 
file or directory
cmp: ../../../Gold/axiom--main--1/./PATCH49-50/CHANGELOG.patch: No such 
file or directory
cmp: ../../../Gold/axiom--main--1/./PATCH49-50/Makefile.patch: No such 
file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.interp.cfuns.lisp.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/lsp.Makefile.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.share.doc.hypertex.pages.util.ht.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.interp.debugsys.lisp.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.interp.sockio.lisp.pamphlet.patch: 
No such file or directory
cmp: ../../../Gold/axiom--main--1/./PATCH49-50/PATCHES: No such file or 
directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/zips.gcl-2.6.1.cmpnew.gcl_cmpflet.lsp.patch.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.input.zimmer.input.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/zips.gcl-2.6.3.cmpnew.gcl_cmpflet.lsp.patch.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/zips.gcl-2.6.2a.cmpnew.gcl_cmpflet.lsp.patch.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.doc.DeveloperNotes.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/zips.gcl-2.6.5.cmpnew.gcl_cmpflet.lsp.patch.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.scripts.Makefile.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.hyper.token.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.scripts.tex.axiom.sty.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.graph.view2D.Makefile.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.doc.Makefile.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.algebra.perm.spad.pamphlet.patch: 
No such file or directory
cmp: ../../../Gold/axiom--main--1/./PATCH49-50/Makefile.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/zips.gcl-2.6.5w.cmpnew.gcl_cmpflet.lsp.patch.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.interp.hash.lisp.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.lib.bsdsignal.c.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.interp.patches.lisp.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/zips.gcl-2.6.2.cmpnew.gcl_cmpflet.lsp.patch.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.doc.book.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.doc.bookvol1.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/zips.gcl-2.6.6.cmpnew.gcl_cmpflet.lsp.patch.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.hyper.Makefile.pamphlet.patch: 
No such file or directory
cmp: 
../../../Gold/axiom--main--1/./PATCH49-50/src.interp.Makefile.pamphlet.patch: 
No such file or directory
cmp: ../../../Gold/axiom--main--1/./ChangeLog: No such file or directory
ac20.pdf
bookvol1.pdf
gcl-2.6.1.cmpnew.gcl_cmpflet.lsp.patch
gcl-2.6.2.cmpnew.gcl_cmpflet.lsp.patch
gcl-2.6.2a.cmpnew.gcl_cmpflet.lsp.patch
gcl-2.6.3.cmpnew.gcl_cmpflet.lsp.patch
gcl-2.6.5.cmpnew.gcl_cmpflet.lsp.patch
gcl-2.6.5w.cmpnew.gcl_cmpflet.lsp.patch
gcl-2.6.6.cmpnew.gcl_cmpflet.lsp.patch
image.bm.Z
image.xpm.Z
libaxiom.al
manuel1.pdf
manuel2.pdf
tla-1.1.tar.gz

\start
Date: Wed, 13 Sep 2006 11:38:34 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

OK, then fix it in Gold, Silver is already OK.

But anyway, these files go away soon... ;-)

Ralf

On 09/13/2006 11:20 AM, root wrote:
>> gcl-2.6.1.cmpnew.gcl_cmpflet.lsp.patch
>> gcl-2.6.2.cmpnew.gcl_cmpflet.lsp.patch
>> gcl-2.6.2a.cmpnew.gcl_cmpflet.lsp.patch
>> gcl-2.6.3.cmpnew.gcl_cmpflet.lsp.patch
>> gcl-2.6.5.cmpnew.gcl_cmpflet.lsp.patch
>> gcl-2.6.5w.cmpnew.gcl_cmpflet.lsp.patch
>> gcl-2.6.6.cmpnew.gcl_cmpflet.lsp.patch
> 
> it's very curious why these have CRLF.
> i'll fix that in gold in the next release.
> we can fix it in silver now.
> 

\start
Date: Wed, 13 Sep 2006 05:31:24 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

> BTW, Tim, why is there now also "tla-1.1.tar.gz" inside the axiom archive?

i'm trying to port axiom locally to 3 different systems,
Windows, MAC OSX, and FreeBSD.

none of them have tla and i need to build it.
it appears that i'm going to have to add patches (ala GCL)
in order to create versions that run everywhere.

eventually these patches will be pushed upstream and hopefully go away.

i know this is 'verboten' but these systems are not debian and
you can't just do an apt-get to install the code. but until the
patches go upstream the users of these 3 systems need the tools.

\start
Date: Wed, 13 Sep 2006 05:32:21 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

someone should patch noweb's build process.
it uses a non-standard build procedure.

\start
Date: Wed, 13 Sep 2006 05:33:34 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

> And libaxiom.al is there to avoid running the scripts from Peter 
> Broadbery? But note that this thing gets out of date if ever somebody 
> modifies some algebra files.

peter's script requires java, i believe.
it's on my list to think that one thru.
it won't be an issue until aldor is released
... which reminds me, time to ask again...

\start
Date: Wed, 13 Sep 2006 11:49:34 +0200
From: Ralf Hemmecke
To: Bill Page, list
Subject: Re: SVN on sourceforge

In Silver/trunk I see

ls -la
total 20
drwx------  5 hemmecke hemmecke 4096 2006-09-13 09:42 .
drwx------  4 hemmecke hemmecke 4096 2006-09-13 09:57 ..
drwx------  7 hemmecke hemmecke 4096 2006-09-13 09:58 .svn
drwx------  3 hemmecke hemmecke 4096 2006-09-13 09:42 CVSROOT
drwx------  8 hemmecke hemmecke 4096 2006-09-13 09:57 axiom

Is there any particular interest in keeping CVSROOT?

If that it gone, we also don't need the axiom directory, but could move 
the files and dirs inside it one level up.

\start
Date: Wed, 13 Sep 2006 05:45:29 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

in general, silver will be ahead of gold so there will be differences.

i used the PATCH49-50 directory so i could journal my changes.
it isn't really necessary but i thought i'd share them so others
could see where i made mistakes.

the CHANGELOGs below the top level directory are probably unnecessary
but don't hurt anything. my working method has been to catalog every
change in the top level CHANGELOG.

\start
Date: Wed, 13 Sep 2006 11:56:25 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

Wow! A very clear description of what goes wrong. ;-)

Ralf

On 09/13/2006 11:32 AM, root wrote:
> someone should patch noweb's build process.
> it uses a non-standard build procedure.

\start
Date: Wed, 13 Sep 2006 05:59:11 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge

CVSROOT is probably a legacy of the fact that the SVN archive
was created automatically from the CVS archive. 

\start
Date: Wed, 13 Sep 2006 12:10:46 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

> in general, silver will be ahead of gold so there will be differences.

This is where I don't agree.

There will be several branches in silver that have patches that don't go 
to gold, but Silver/trunk (and only that directory) should be in sync 
with the Gold version you are working on.

So at each point in time Silver/trunk should contain exactly the same 
code as is in your local Gold-to-be archive. If you don't want that then 
make the Gold-to-be archive public so we could get the patches you apply 
to that archive and put it into Silver/trunk.

\start
Date: Wed, 13 Sep 2006 06:06:08 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

> Wow! A very clear description of what goes wrong. ;-)
> 
> Ralf
> 
> On 09/13/2006 11:32 AM, root wrote:
> > someone should patch noweb's build process.
> > it uses a non-standard build procedure.
> > 
> > t

The standard is to do 
 ./configure
 make

but in noweb you need to change to a build directory and then do
 cd build
 ../configure
 make

trivial, but annoying, forcing you to read the docs and you know
how i hate documentation :-)

\start
Date: Wed, 13 Sep 2006 06:11:03 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

> > in general, silver will be ahead of gold so there will be differences.
> 
> This is where I don't agree.
> 
> There will be several branches in silver that have patches that don't go 
> to gold, but Silver/trunk (and only that directory) should be in sync 
> with the Gold version you are working on.
> 
> So at each point in time Silver/trunk should contain exactly the same 
> code as is in your local Gold-to-be archive. If you don't want that then 
> make the Gold-to-be archive public so we could get the patches you apply 
> to that archive and put it into Silver/trunk.

methinks you may be confused on this point.

when i say that silver will be 'ahead' of gold i'm saying exactly 
what you said. silver (assuming i'm ever able to maintain it) will be
gold-to-be, in sync with my latest set of mistakes. (all code changes
are mistakes until properly tested, then they become bugs :-) )

\start
Date: Wed, 13 Sep 2006 06:26:09 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

> OK, then fix it in Gold, Silver is already OK.
> 
> But anyway, these files go away soon... ;-)
> 
> Ralf
> 
> On 09/13/2006 11:20 AM, root wrote:
> >> gcl-2.6.1.cmpnew.gcl_cmpflet.lsp.patch
> >> gcl-2.6.2.cmpnew.gcl_cmpflet.lsp.patch
> >> gcl-2.6.2a.cmpnew.gcl_cmpflet.lsp.patch
> >> gcl-2.6.3.cmpnew.gcl_cmpflet.lsp.patch
> >> gcl-2.6.5.cmpnew.gcl_cmpflet.lsp.patch
> >> gcl-2.6.5w.cmpnew.gcl_cmpflet.lsp.patch
> >> gcl-2.6.6.cmpnew.gcl_cmpflet.lsp.patch
> > 
> > it's very curious why these have CRLF.
> > i'll fix that in gold in the next release.
> > we can fix it in silver now.
> > 
> > t

actually, i went back to gcl-2.6.6 and the original files were DOS
meaning they followed the DOS standard for line endings. this is
changed as of gcl-2.6.7.

\start
Date: Wed, 13 Sep 2006 12:57:40 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

are the .bitmap and .mask files in src/graph/include/bitmaps/ really 
text files? They look like that. How are they generated? And would it 
make sense to add a svn:eol-style=native property to them? (They 
actually already have it in the SVN repository.)

Same question for .xbm.

Gaby, what about all those text-files you have checked in? They don't 
seem to carry the svn:eol-style=native property. Should I change that, too?

\start
Date: Wed, 13 Sep 2006 06:09:15 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge

On Wed, 13 Sep 2006, Ralf Hemmecke wrote:

| > in general, silver will be ahead of gold so there will be differences.
|
| This is where I don't agree.

I think Tim is right.  My understanding of silver and gold is that
silver will have patches *before* gold considers them.

\start
Date: Wed, 13 Sep 2006 06:11:48 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge

On Wed, 13 Sep 2006, Ralf Hemmecke wrote:

| Hello
|
| are the .bitmap and .mask files in src/graph/include/bitmaps/ really
| text files? They look like that. How are they generated? And would it
| make sense to add a svn:eol-style=native property to them? (They
| actually already have it in the SVN repository.)
|
| Same question for .xbm.
|
| Gaby, what about all those text-files you have checked in? They don't
| seem to carry the svn:eol-style=native property. Should I change that, too?

I used the unix-style, but if you believe native is less troublesome,
yes please go ahead.

\start
Date: Wed, 13 Sep 2006 06:12:26 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge

On Wed, 13 Sep 2006, Ralf Hemmecke wrote:

| So, now I have run to check from Silver r133 to Gold (--patch-50).
|
| Hmmm, it seems that Silver/trunk already contains a few more files than
| Gold.
|
| Gaby, would you like to keep it that way? Or should we rather have

Yes, it is fine for silver to have more files than gold.

\start
Date: Wed, 13 Sep 2006 06:12:42 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: SVN on sourceforge

On Wed, 13 Sep 2006, root wrote:

| someone should patch noweb's build process.
| it uses a non-standard build procedure.

:-) :-)

\start
Date: Wed, 13 Sep 2006 13:25:27 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Gold-Silver-Bronze

No, no, I think we all agree now. The confusion appeared because it is 
not really clear, what is meant, if somebody speaks of gold or silver. 
So to make it clear now.

*Gold*: The latest release of axiom--main--1--patch-??
*Silver* = *Gold-to-be* =https://svn.sourceforge.net/svnroot/axiom/trunk

All the other branches like, for example, the build-improvements branch 
on sourceforge are experimental (a bronze thing, so to say).

I hope we all agree on that terminology.

Ralf

PS: Maybe it was just me who was confused. :-)




On 09/13/2006 01:09 PM, Gabriel Dos Reis wrote:
> On Wed, 13 Sep 2006, Ralf Hemmecke wrote:
> 
> | > in general, silver will be ahead of gold so there will be differences.
> |
> | This is where I don't agree.
> 
> I think Tim is right.  My understanding of silver and gold is that
> silver will have patches *before* gold considers them.

\start
Date: 13 Sep 2006 13:27:23 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge

Ralf Hemmecke writes:

| Hmmm. Maybe your suggestion is good, but after I've sent my mail, I
| just tried
| 
| cd trunk
| svn update
| 
| and succeeded.
| 
| So I tried again.
| 
| svn co -r1 https://svn.sourceforge.net/svnroot/axiom/trunk trunk
| cd trunk
| svn update
| 
| No problem with that.

I had had problems with checking out Axiom into a directory on *SF*
hosts.

| 
| Maybe the "svn checkout" causes the problem. "svn update", however,
| works fine.

yes, because it is a short-running process.

\start
Date: Wed, 13 Sep 2006 14:30:49 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: SVN on sourceforge

What about the files
src/share/algebra/DEPENDENTS.DAASE/index.KAF
src/share/algebra/USERS.DAASE/index.KAF

They look like text files, but I guess it matters if they are checked 
out under Windows and get CR LF line endings?

\start
Date: Wed, 13 Sep 2006 08:27:25 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge

they are the axiom initial database files.
an index.KAF file is a binary random access file.
the first integer in the file is the byte offset of the hash table.
the hash table has a set of (key . index) pairs
the index is the byte offset in the file of the value for the key.

\start
Date: Wed, 13 Sep 2006 15:00:55 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: SVN on sourceforge

OK, a few more file types that I am unsure of...
Not that I cannot recognise text files... what worries me is whether 
Axiom still treats them correctly if they are checked out under Windows 
and compiled there natively. I faintly remember that Tim said something 
about some files that have numbers in them counting the bytes to access 
the data. If a checkout changes the line-endings the count is wrong.
So please tell me what filetypes should keep/get the

svn:eol-style=native

property (ie change to native line endings at checkout).

For some files I prefer to remove the "eol-style" property, because they 
are not really source files (like .ps and .eps files, for example).


.daase
.data
.db
.eps, .epsi, .ps
     These are actually text files, but I don't think they must
     have eol-style=native. Or is somebody considering to edit them?
.ht
.pht
.list
.mask
.msgs
.out
.pht
.ps
xbm.tiny
.tm
.bitmap.wrong
.xbm

\start
Date: Wed, 13 Sep 2006 08:58:26 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge

none of those are 'text' file formats. --t

\start
Date: Wed, 13 Sep 2006 10:19:59 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: SVN on sourceforge

On September 13, 2006 9:01 AM Ralf Hemmecke wrote:
>
> OK, a few more file types that I am unsure of...
> Not that I cannot recognise text files... what worries me
> is whether Axiom still treats them correctly if they are
> checked out under Windows and compiled there natively.

I am moving between Windows and Linux/Unix all the time.
The difference between line endings is seldom a problem
for text files but the way some systems bend over backwards
try to "help" you with this non-problem is what actually
causes the problems.

Why did the designers of SVN allow this? !! Tim, said earlier
that source archive systems should NEVER modify the source
they are asked to store and I strongly agree.

> I faintly remember that Tim said something about some files
> that have numbers in them counting the bytes to access the
> data.

I think it is funny that these files have an ascii text string
(possibly varying in length) that represents the byte offset.
It is a strange mixture of paradigms but I guess it is ok.

> If a checkout changes the line-endings the count is wrong.
> So please tell me what filetypes should keep/get the
>
> svn:eol-style=native
>
> property (ie change to native line endings at checkout).
>

Actually my understanding is that if we remove the svn:eol-style
properties from all files and set that as the default, then
SVN will just leave all the files alone.

> For some files I prefer to remove the "eol-style" property,
> because they are not really source files (like .ps and .eps
> files, for example).

I think we should remove it from all files and make that the
default.

\start
Date: Wed, 13 Sep 2006 16:40:12 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: SVN on sourceforge

somehow you are contradicting yourself.

>> So please tell me what filetypes should keep/get the
>>
>> svn:eol-style=native
>>
>> property (ie change to native line endings at checkout).

> Actually my understanding is that if we remove the svn:eol-style
> properties from all files and set that as the default, then
> SVN will just leave all the files alone.

In a previous mail

http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00294.html

you suggested:

 >> I think it would be better to be selective and leave the
 >> svn:eol-style property as set on the text files.

I've already locally modified the eol-style and was just about to 
commit. The following files and extensions are left with the "native" 
eol-style set.

I believe it is OK if they are left as text files and change the 
line-endings.

In particular, I would like to see it for .pamphlet files. It gives a 
terrible mess if some windows user changes ONE line in a file, commits 
the thing and I run a diff to the previous version and see that ALL 
lines have changed.

The copyright files...
   .AXIOM
   .B
   .BULL
   .CC
   .CCL
   .EAY
   .FSF
   .NOWEB
   .RAND
   .SMC

Some other obvious text files.
I actually don't understand why in the repository is anything else than 
pamphlets. I can understand .fig, .jpg, .png or such files, but not 
.lisp, .tex, .sty, .text, .h. Maybe .booklet is special.

Any reason why there are such non-pamphlets?

   .H1 <-------- I am not sure about that one. Looks like a .h file.
   .booklet
   .h
   .lisp
   .pamphlet
   .patch
   .sty
   .tex
   .text

   CHANGELOG
   ChangeLog
   FAQ
   Makefile
   README

   axiom
   configure
   document
   showdvi

These files are probably not needed anymore...
   boxhead
   boxtail
   boxup

 From CVSROOT
   checkoutlist
   commitinfo
   config
   copyright
   cvswrappers
   editinfo
   loginfo
   modules
   notify
   rcsinfo
   summary
   taginfo
   verifymsg


\start
Date: 13 Sep 2006 16:45:27 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: SVN on sourceforge

Bill Page writes:

| Actually my understanding is that if we remove the svn:eol-style
| properties from all files and set that as the default, then
| SVN will just leave all the files alone.

Yes.

\start
Date: Wed, 13 Sep 2006 10:58:18 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SVN on sourceforge

> Any reason why there are such non-pamphlets?
> 
>    .H1 <-------- I am not sure about that one. Looks like a .h file.
>    .h

these are include files. part of the rewrite was to put them into
the pamphlets but i never finished the task.


>    .patch

this is standard text input to the patch tool. probably could be
a pamphlet since patch will recognize its own input. try one and 
see if you can get patch to swallow a pamphlet containing a patch
and still extract the patch.



>    .lisp
>    .text

odd. got full pathnames?




>    .sty
>    .tex

these look like noise someone left around. got full pathnames?




>    .booklet

this is experimental for the booklet command in src/doc




>    CHANGELOG
>    FAQ
>    README

trying to be standard here. human readable and all that.




>    ChangeLog

this isn't one of my original files. probably redundant with CHANGELOG




>    Makefile

ya gotta start somewhere :-)




>    axiom
>    configure
>    document
>    showdvi

these are executable shell scripts but should be in pamphlet form
in the source tree. i didn't get those done.





> These files are probably not needed anymore...
>    boxhead
>    boxtail
>    boxup

they are not needed. they were part of my conversion tools.









>  From CVSROOT
>    checkoutlist
>    commitinfo
>    config
>    copyright
>    cvswrappers
>    editinfo
>    loginfo
>    modules
>    notify
>    rcsinfo
>    summary
>    taginfo
>    verifymsg

CVSROOT should go away completely.

\start
Date: Wed, 13 Sep 2006 17:09:02 +0200
From: Gregory Vanuxem
To: Kai Kaminski, Cliff Yapp
Subject: RE: A Canonical Axiom GUI

> -----Message d'origine-----
> De : axiom-developer-bounces+g.vanuxem=wanadoo.fr@nongnu.org
> part de Kai Kaminski
> Envoye : vendredi 8 septembre 2006 15:56
> A : C Y
> Cc : list
> Objet : Re: A Canonical Axiom GUI

[...]

> I don't know why TeXmacs isn't as tightly integrated with any
> mathematical environment as you'd wish. I *do* know, though, that it
> would be fairly hard to integrate it closely with Axiom, because Axiom
> is somewhat 'unfriendly' to programs. If anyone feels that this claim
> should be substantiated I'll happily give a few examples.

Yes, please, when time permits.

\start
Date: Wed, 13 Sep 2006 11:11:20 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: SVN on sourceforge

On Wednesday, September 13, 2006 10:40 AM you wrote:
>
> somehow you are contradicting yourself.
>

You are right. I have been thinking about this for a while
and I realized that I had become suckered into this whole
'svn:eol-style' thing, too. Part of the problem is that
svn is trying to be "all things to all people". If they
had just learned to say "no" life would be so much easier...

> >> So please tell me what filetypes should keep/get the
> >>
> >> svn:eol-style=native
> >>
> >> property (ie change to native line endings at checkout).
>
> > Actually my understanding is that if we remove the
> > svn:eol-style properties from all files and set that as
> > the default, then SVN will just leave all the files alone.
>
> In a previous mail
>
>
http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00294.ht
ml
>
> you suggested:
>
> >> I think it would be better to be selective and leave
> >> the svn:eol-style property as set on the text files.
>

I have changed my mind. It is true that they probably "do no
harm" right now so they could be retained. But it is only
an accident of the conversion from CVS on SourceForge that
they are there at all. To save us having to re-visit this again,
and again, say when people do checkouts to MAC (\r line endings)
and Windows (\r\n endings), God forbid that anyone should ever
try to install Axiom under VMS on a VAX computer...

I think we should get rid of them now. All text files in the
Axiom source distribution should use unix-style line endings -
period. When porting to other platforms it is the responsibility
of the port as to how to deal with this. On Windows almost all
text processing software treat \n and \r\n identicall. There
is a patch to the BOOT and SPAD compilers on the Windows version
of Axiom to do exactly that.

> I've already locally modified the eol-style and was just about
> to commit. The following files and extensions are left with the
> "native" eol-style set.
>
> I believe it is OK if they are left as text files and change the
> line-endings.
>

Ok.

> In particular, I would like to see it for .pamphlet files. It
> gives a terrible mess if some windows user changes ONE line in
> a file, commits the thing and I run a diff to the previous version
> and see that ALL lines have changed.

That is an elementary Windows developer error. Don't expect the
archive software to save them - revoke their archive access
privileges!  ;)

>
> The copyright files...
>    .AXIOM
>    .B
>    .BULL
>    .CC
>    .CCL
>    .EAY
>    .FSF
>    .NOWEB
>    .RAND
>    .SMC
>
> Some other obvious text files.

Having to make the distinction between 'text' and 'non-text'
files is annoying and unnecessary.

> I actually don't understand why in the repository is anything
> else than pamphlets.

I agree.

> I can understand .fig, .jpg, .png or such files,

I don't.

With the very rare exception of essential graphic artwork (eg. book
cover) I think all such files should be generated from source - by
running Axiom, noweb, LaTeX, dvipng, graphviz, etc.

> I think we should only keep the source but not .lisp, .tex, .sty,
> .text, .h.

Right.

> Maybe .booklet is special.

'booklet' is an experimental type of source file like 'pamphlet'.

>
> Any reason why there are such non-pamphlets?
>
>    .H1 <-------- I am not sure about that one. Looks like a .h file.
>    .booklet
>    .h
>    .lisp
>    .pamphlet
>    .patch
>    .sty
>    .tex
>    .text
>
>    CHANGELOG
>    ChangeLog
>    FAQ
>    Makefile
>    README
>
>    axiom
>    configure
>    document
>    showdvi
>

There may need to be a small number of files to simplify the
'bootstrap form pamphlet' process. And some (e.g. README) are
present to conform to open source packaging common practices.

> These files are probably not needed anymore...
>    boxhead
>    boxtail
>    boxup
>

I agree.

>  From CVSROOT
>    checkoutlist
>    commitinfo
>    config
>    copyright
>    cvswrappers
>    editinfo
>    loginfo
>    modules
>    notify
>    rcsinfo
>    summary
>    taginfo
>    verifymsg
>

These are CVS control files that should not be in the
SVN archive.

\start
Date: Wed, 13 Sep 2006 17:16:50 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: SVN on sourceforge

>>    .lisp
>>    .text
> 
> odd. got full pathnames?
> 
> 
> 
>>    .sty
>>    .tex
> 
> these look like noise someone left around. got full pathnames?

cd axiom/Silver/trunk/axiom
find . -regex '.*\.\(lisp\|text\|tex\|sty\)'
./src/scripts/tex/axiom.sty
./src/algebra/libdb.text
./src/interp/interp-proclaims.lisp
./src/interp/libdb.text
./src/interp/temp.text
./src/share/algebra/glosskey.text
./src/share/algebra/libdb.text
./src/share/algebra/comdb.text
./src/share/algebra/glossdef.text
./src/share/algebra/gloss.text
./src/boot/boot-proclaims.lisp
./src/doc/diagrams.tex
./src/doc/fnotes.tex
./src/doc/gloss.text

\start
Date: 13 Sep 2006 17:29:07 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: SVN on sourceforge

Tim Daly writes:

[...]

| >    ChangeLog
| 
| this isn't one of my original files. probably redundant with CHANGELOG

I keep my change records there -- uses GNU standard style.

| >    Makefile
| 
| ya gotta start somewhere :-)

build-improvements has

    Makefile.in

and all makefiles will be instantiated at configure-time.

| >    axiom
| >    configure
| >    document
| >    showdvi
| 
| these are executable shell scripts but should be in pamphlet form
| in the source tree. i didn't get those done.

build-improvements has document.in

[...]

| CVSROOT should go away completely.

Amen.

\start
Date: Wed, 13 Sep 2006 12:00:05 -0400
From: Bill Page
To: Tim Daly
Subject: RE: SVN on sourceforge
Cc: Gabriel Dos Reis

On Wednesday, September 13, 2006 5:31 AM you wrote:
>
> > BTW, Tim, why is there now also "tla-1.1.tar.gz" inside
> > the axiom archive?
>
> i'm trying to port axiom locally to 3 different systems,
> Windows, MAC OSX, and FreeBSD.
>
> none of them have tla and i need to build it.

That is no reason to keep an old distribution of tla in the
Axiom archive.

On each new platform you should start with the newest tla
sources available and solve problems with that, if you feel
motivated. Otherwise work-a-round them via scp or whatever.

> it appears that i'm going to have to add patches (ala GCL)
> in order to create versions that run everywhere.

Contribute such patches to the arch developers. They do not
belong in the Axiom source distribution.

> eventually these patches will be pushed upstream and
> hopefully go away.
>

I think they should go away now. :-)

> i know this is 'verboten' but these systems are not debian
> and you can't just do an apt-get to install the code.

On most common systems in use today there alternatives at
least as good as apt-get.

> but until the patches go upstream the users of these 3
> systems need the tools.
>

They already have there own tools. You need to learn to use
them. Otherwise Axiom will continue to look like just another
weird foreign system to them.

\start
Date: Wed, 13 Sep 2006 11:02:42 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: SVN on sourceforge

On Wed, 13 Sep 2006, Page, Bill wrote:

[...]

| > i know this is 'verboten' but these systems are not debian
| > and you can't just do an apt-get to install the code.
|
| On most common systems in use today there alternatives at
| least as good as apt-get.

"most common systems" in a suitably chosen sample.

\start
Date: Wed, 13 Sep 2006 12:15:06 -0400
From: Bill Page
To: Tim Daly, Ralf Hemmecke
Subject: Aldor and Axiom (was: SVN on sourceforge)
Cc: Gabriel Dos Reis

On Wednesday, September 13, 2006 5:34 AM Tim Daly wrote:
> Ralf Hemmecke wrote:
> > And libaxiom.al is there to avoid running the scripts from
> > Peter Broadbery? But note that this thing gets out of date
> > if ever somebody modifies some algebra files.

I don't think this belongs in the Axiom source code distribution.

>
> peter's script requires java, i believe.
> it's on my list to think that one thru.
> it won't be an issue until aldor is released
> ... which reminds me, time to ask again...
>

I've given up. Aldor.org et al have passed every target date
that has ever been discussed and they barely seem to be able
to keep the Aldor website up to date. I no longer believe that
they really want to make Aldor open source. Rather than simply
"it takes time to get everyone to agree", it seems likely that
there are some non-vocal associates of aldor.org that do not
want Aldor to be released. Otherwise I cannot explain why we
are still in this situation. :(

Note: Both Mike Dewar and Steven Watt have stated publicly on
this list that they support making Aldor open source.

\start
Date: Wed, 13 Sep 2006 12:35:06 -0400
From: Bill Page
To: Tim Daly
Subject: RE: SVN on sourceforge
Cc: Gabriel Dos Reis

On Wednesday, September 13, 2006 6:06 AM Tim Daly wrote:
> >
> > > someone should patch noweb's build process.
> > > it uses a non-standard build procedure.
>

I agree, but it seems that you just can't teach an old dog
new tricks ... ;)

> The standard is to do
>  ./configure
>  make
>
> but in noweb you need to change to a build directory and then
> do
>
>  cd build
>  ../configure
>  make
>
> trivial, but annoying, forcing you to read the docs and you know
> how i hate documentation :-)
>

Actually noweb is more non-standard than that. 'noweb-2.11b'
from the master distribution does not contain any 'configure'
option at all. The entire source distribution is in the 'src'
subdirectory and you have to edit the 'Makefile' manually
before typing 'make all'. Or you can write a simple shell
script like the example 'nwmake'.

\start
Date: Wed, 13 Sep 2006 19:06:57 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: SVN on sourceforge

> | CVSROOT should go away completely.
> 
> Amen.

Removed from Silver/trunk.

\start
Date: Wed, 13 Sep 2006 19:08:11 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: build-improvements and latex

I have updated to version 133 of build-improvements branch and 
retried build on the same Debian testing machine. Now build goes
further, but fails running Latex on clifford.spad.tex
The reason for failure is missing amssymb.sty file.
I am affraid that if we want clean build, then configure should check
for all latex packages used.

\start
Date: Wed, 13 Sep 2006 19:27:39 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: SVN on sourceforge

>> I actually don't understand why in the repository is anything 
>> else than pamphlets.
> 
> I agree.
> 
>> I can understand .fig, .jpg, .png or such files,
> 
> I don't.

> With the very rare exception of essential graphic artwork (eg. book
> cover) I think all such files should be generated from source - by
> running Axiom, noweb, LaTeX, dvipng, graphviz, etc.

Ah, of course, pictures should be exceptions, but allowed if they ARE 
sources. If somebody gives me a an idea how to put .fig into a 
.pamphlet, I agree, that also that can go away, but I don't consider 
xfig such a bad program. Note that the .latex generated from .fig is NOT 
the source. Of course, you know that...

\start
Date: Wed, 13 Sep 2006 19:29:45 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: SVN on sourceforge

Hi Tim,

>> These files are probably not needed anymore...
>>    boxhead
>>    boxtail
>>    boxup
> 
> they are not needed. they were part of my conversion tools.

Then remove them.

\start
Date: Wed, 13 Sep 2006 19:35:19 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: SVN on sourceforge

> Actually my understanding is that if we remove the svn:eol-style
> properties from all files and set that as the default, then
> SVN will just leave all the files alone.

So what is the opinion of people on the list? Should we just say

svn propdel svn:eol-style -R

???

If svn:eol-style is removed, I would like at least a script that takes 
care of commits that contain \r\n line endings. Such commits should be 
rejected. Can that be done on sourceforge?

\start
Date: Wed, 13 Sep 2006 13:37:42 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: build-improvements and latex

On Wednesday, September 13, 2006 1:08 PM Waldek Hebisch wrote:
>
> I have updated to version 133 of build-improvements branch and
> retried build on the same Debian testing machine. Now build goes
> further, but fails running Latex on clifford.spad.tex
> The reason for failure is missing amssymb.sty file.
> I am affraid that if we want clean build, then configure should check
> for all latex packages used.
>

I still think it makes better sense to *not* run the LaTeX part
of the build by default. If somebody wants it, they should be
able to run something like:

  make documentation-all

later. Or even individually like this:

  make clifford.spad.dvi

\start
Date: Wed, 13 Sep 2006 19:50:52 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: build-improvements and latex
Cc: Waldek Hebisch

> I still think it makes better sense to *not* run the LaTeX part
> of the build by default. If somebody wants it, they should be
> able to run something like:
> 
>   make documentation-all
> 
> later. Or even individually like this:
> 
>   make clifford.spad.dvi

That's a good one. Assume clifford.spad makes a reference to Integer. At 
least when the whole documentation is build I want to see that reference 
turned into a link to the definition of Integer. For that we still need 
some good convention of how pamphlets should look like. Hmm, maybe we 
are not at that stage ...

\start
Date: Wed, 13 Sep 2006 14:03:21 -0400
From: Bill Page
To: Enrique Acosta
Subject: Doyen and Sage (was: [SAGEsupport] SAGE)

On Wednesday, September 13, 2006 12:58 PM William Stein wrote:

>
> On Wed, 13 Sep 2006 08:13:56 -0700, Enrique Acosta wrote:
> > ...
> > I am using sage on windows with coLinux. ...
>
> We've decided not to support SAGE-with-cygwin anymore.
>
> > tried the CoLinux one and made it work after some settings on
> > the network connections. Some explanation of that in the
> > documentation could be useful. Everything is working fine now
> > and I think the notebook interface is really useful.
> ...
> > Last week I also tried the Vmware version to see what were the
> > differences and had a terrible experience.
>
> I don't recommend or support using that.  Colinux is the way to
> go.

See: http://colinux.org

So, finally a linux solution that actually works with Windows?
I want to hear more.

>
> >  First of all, I copuld not load the notebook, and then found
> > a serious limitations with the fact that you cannot copy and
> > paste from windows to Vmware and vice-versa.
>
> Yes, vmware is really not a good solution.
> ...
>
> VMware is not worth using.  You should use colinux.
> ...
> > The last experience which I have had with sage, was when
> > trying to use it on a Knoppix live CD. Is this possible?
> > I have tried it for two days unsuccesfully, although I have
> > to accept I am a complete Linux Newbie...
>
> I've never done this, but the following might work:
> (1) Put the SAGE binary on a USB drive:
>       http://modular.math.washington.edu/SAGEbin/linux_32bit/
> You probably want the ubuntu binary -- hopefully it will work.
> You could use ubuntu's live CD -- then for sure that binary
> would work.
> (2) Boot into the live CD environment.
> (3) Plug in the USB drive.
> (4) Type "tar xvf sage-1.3.7-ubuntu-i686-Linux.tar.gz"
>      to extract the binary (the extracted version is 333MB).
> (5) type "cd sage-1.3.7-ubuntu-i686-Linux"
> (6) type "./sage"
> (7) type notebook() to get the SAGE notebook.
> (8) Anything in SAGE that requires compiling, e.g.,
> rebuilding / upgrading, developing compiled code, etc.,
> will fail since live CD's don't include GCC  by default.
>
> > Anyway, I'm trying this because I want to use SAGE on a pretty old
> > dell laptop which is running windows but has only a 2GB
> hard disk  and
> > on which I cannot install linux since its a shared computer. I don't
> > know if you know if this is possible to do, or have considered the
> > idea of building a linux live CD with an already installed SAGE to
> > have a portable version of the programm which could use a
> usb drive to
> > save sessions, notebooks and everything. It would be great!
>
> People have suggested before building such a live CD, and
> I've been very encouraging, but nobody has actually stepped
> up to do it yet. Maybe you are the person to do it.   The
> crucial thing is that you should install GCC into the live cd,
> but get rid of things you don't need, like openoffice
> which is often in live cd's.
>

On the Axiom developer web site we host the Doyen project

http://wiki.axiom-developer.org/Doyen

and such a live CD has been developed:

http://wiki.axiom-developer.org/DoyenCD

"Doyen is a Science Platform. It features a Live CD that contains
free and open source science software and a Wiki user interface
that runs on a laptop."

Right now the DoyenCD contains only Axiom, Magnus and Maxima. We
have been discussing add Sage and it's friends.

A complete description of how the DoyenCD was built is provided
here:

http://wiki.axiom-developer.org/DoyenDocs

\start
Date: Wed, 13 Sep 2006 14:15:19 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: New Axiom Browser (was: build-improvements and	latex)
Cc: Waldek Hebisch

On Wednesday, September 13, 2006 1:51 PM Ralf Hemmecke wrote:

>...
> Assume clifford.spad makes a reference to Integer. At least
> when the whole documentation is build I want to see that
> reference turned into a link to the definition of Integer.
> For that we still need some good convention of how pamphlets
> should look like. Hmm, maybe we are not at that stage ...
>

What *I* would like is some kind of updated version of the
Hyperdoc browser - probably using standard browser/local
webserver technology - that would allow external references
from the documentation. So we have such references embedded
in various places and/or generated automatically by something
that can parse SPAD/Aldor source code. Then while reading some
documentation or even a paper, a user can click on a link and
be immediately at the right place in Axiom.

The contents of this new Axiom Browser should be automatically
generated from alll the Axiom source distribution pamphlets.

If Axiom is not available locally, then such links should
automatically link to a standard remote website with similar
information. This should be possible with a little javascript
magic.

\start
Date: Wed, 13 Sep 2006 11:53:03 -0700
From: William Stein
To: Bill Page, Enrique Acosta
Subject: Re: [SAGEsupport] Doyen and Sage (was:  SAGE)

On Wed, 13 Sep 2006 11:03:21 -0700, Page, Bill Bill Page  
wrote:
>> I don't recommend or support using that.  Colinux is the way to
>> go.
>
> See: http://colinux.org
>
> So, finally a linux solution that actually works with Windows?
> I want to hear more.

In short, it's the linux kernel ported to run as a normal windows process.
Because of the SAGE notebook, which provides the UI and graphics for SAGE,
the colinux approach works well.  Without that, it would be painful to use
for anything involving graphics.
>
> On the Axiom developer web site we host the Doyen project
>
> http://wiki.axiom-developer.org/Doyen
>
> and such a live CD has been developed:
>
> http://wiki.axiom-developer.org/DoyenCD
>
> "Doyen is a Science Platform. It features a Live CD that contains
> free and open source science software and a Wiki user interface
> that runs on a laptop."
>
> Right now the DoyenCD contains only Axiom, Magnus and Maxima. We
> have been discussing add Sage and it's friends.

How much space is left.  For SAGE, we'd need about 300MB, probably,
since we would want to include GCC.

\start
Date: Wed, 13 Sep 2006 14:50:39 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: SVN on sourceforge

========================================================================
========================================================================
==== NOWEB =============================================================
========================================================================
========================================================================

It took me 5 tries to install noweb properly from sources.

I managed to tar -zxf the noweb tgz file and it does not create a directory
so I ended up with a lot of random files at the top level.

I didn't have gawk installed

I managed to mis-edit the makefile and added crud to my system directories

The make all install failed to terminate, looping infintely deeper.

The 5th try worked.

========================================================================
========================================================================




[root@dhcppc0 zips]# mkdir noweb
[root@dhcppc0 zips]# cd noweb
[root@dhcppc0 noweb]# tar -zxf ../noweb-2.10a.tgz 
[root@dhcppc0 noweb]# cd src
[root@dhcppc0 src]# ./awkname gawk
[root@dhcppc0 src]# make all
cd c; make "CC=gcc -ansi -pedantic" "CFLAGS=" all 
make[1]: Entering directory `/tmp/bi/zips/noweb/src/c'
gcc -ansi -pedantic    -c -o notangle.o notangle.c
gcc -ansi -pedantic    -c -o getline.o getline.c
gcc -ansi -pedantic    -c -o match.o match.c
gcc -ansi -pedantic    -c -o modules.o modules.c
gcc -ansi -pedantic    -c -o modtrees.o modtrees.c
gcc -ansi -pedantic    -c -o strsave.o strsave.c
gcc -ansi -pedantic    -c -o main.o main.c
gcc -ansi -pedantic    -c -o errors.o errors.c
gcc -ansi -pedantic    -c -o columns.o columns.c
gcc -ansi -pedantic  -o nt notangle.o getline.o match.o modules.o modtrees.o strsave.o main.o errors.o columns.o
gcc -ansi -pedantic    -c -o markmain.o markmain.c
gcc -ansi -pedantic    -c -o markup.o markup.c
gcc -ansi -pedantic  -o markup markmain.o strsave.o markup.o errors.o getline.o columns.o
gcc -ansi -pedantic    -c -o mnt.o mnt.c
gcc -ansi -pedantic  -o mnt mnt.o getline.o match.o modules.o modtrees.o notangle.o strsave.o errors.o columns.o
mnt.o: In function `emitfile':mnt.c:(.text+0x3c0): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
gcc -ansi -pedantic    -c -o finduses.o finduses.c
gcc -ansi -pedantic    -c -o recognize.o recognize.c
gcc -ansi -pedantic  -o finduses columns.o errors.o finduses.o match.o getline.o recognize.o
make[1]: Leaving directory `/tmp/bi/zips/noweb/src/c'
for i in shell lib xdoc tex; do (cd $i; make all); done
make[1]: Entering directory `/tmp/bi/zips/noweb/src/shell'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/tmp/bi/zips/noweb/src/shell'
make[1]: Entering directory `/tmp/bi/zips/noweb/src/lib'
chmod +x unmarkup emptydefn toascii nwmtime pipedocs h2a btdefn
make[1]: Leaving directory `/tmp/bi/zips/noweb/src/lib'
make[1]: Entering directory `/tmp/bi/zips/noweb/src/xdoc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/tmp/bi/zips/noweb/src/xdoc'
make[1]: Entering directory `/tmp/bi/zips/noweb/src/tex'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/tmp/bi/zips/noweb/src/tex'
cd awk; make "ICONT=icont" "ICONC=iconc" all
make[1]: Entering directory `/tmp/bi/zips/noweb/src/awk'
chmod +x noindex  totex noidx tohtml
make[1]: Leaving directory `/tmp/bi/zips/noweb/src/awk'
[root@dhcppc0 src]# make install
mkdir /usr/local/bin /usr/local/bin/lib 2>/dev/null
make: [install-shell] Error 1 (ignored)
sed "s@|LIBDIR|@/usr/local/bin/lib@" shell/noweb > /usr/local/bin/noweb
chmod +x /usr/local/bin/noweb
sed "s@|LIBDIR|@/usr/local/bin/lib@" shell/notangle > /usr/local/bin/notangle
chmod +x /usr/local/bin/notangle
sed "s@|LIBDIR|@/usr/local/bin/lib@" shell/noweave		 > /usr/local/bin/noweave		
chmod +x /usr/local/bin/noweave		
sed "s@|LIBDIR|@/usr/local/bin/lib@" shell/nountangle > /usr/local/bin/nountangle
chmod +x /usr/local/bin/nountangle
sed "s@|LIBDIR|@/usr/local/bin/lib@" shell/nodefs > /usr/local/bin/nodefs
chmod +x /usr/local/bin/nodefs
sed "s@|LIBDIR|@/usr/local/bin/lib@" shell/noroots > /usr/local/bin/noroots
chmod +x /usr/local/bin/noroots
sed "s@|LIBDIR|@/usr/local/bin/lib@" shell/nuweb2noweb > /usr/local/bin/nuweb2noweb
chmod +x /usr/local/bin/nuweb2noweb
sed "s@|LIBDIR|@/usr/local/bin/lib@" shell/cpif > /usr/local/bin/cpif
chmod +x /usr/local/bin/cpif
sed "s@|LIBDIR|@/usr/local/bin/lib@" shell/htmltoc > /usr/local/bin/htmltoc
chmod +x /usr/local/bin/htmltoc
sed "s@|LIBDIR|@/usr/local/bin/lib@" shell/noroff > /usr/local/bin/noroff
chmod +x /usr/local/bin/noroff
sed "s@|LIBDIR|@/usr/local/bin/lib@" shell/toroff > /usr/local/bin/lib/toroff
chmod +x /usr/local/bin/lib/toroff
cp shell/tmac.w /usr/local/bin/lib
mkdir /usr/local/bin /usr/local/bin/lib 2>/dev/null
make: [install-code] Error 1 (ignored)
strip c/nt c/markup c/mnt c/finduses
cp c/nt c/markup c/mnt c/finduses /usr/local/bin/lib
cd awk; make ICONT=icont ICONC=iconc LIB=/usr/local/bin/lib BIN=/usr/local/bin install
make[1]: Entering directory `/tmp/bi/zips/noweb/src/awk'
chmod +x noindex  totex noidx tohtml
cp totex noidx tohtml /usr/local/bin/lib
cp noindex  /usr/local/bin
make[1]: Leaving directory `/tmp/bi/zips/noweb/src/awk'
cd lib; make LIB=/usr/local/bin/lib install
make[1]: Entering directory `/tmp/bi/zips/noweb/src/lib'
chmod +x unmarkup emptydefn toascii nwmtime pipedocs h2a btdefn
cp unmarkup emptydefn toascii nwmtime h2a btdefn /usr/local/bin/lib
sed 's@|LIBDIR|@/usr/local/bin/lib@g' pipedocs > /usr/local/bin/lib/pipedocs
chmod +x /usr/local/bin/lib/pipedocs
make[1]: Leaving directory `/tmp/bi/zips/noweb/src/lib'
mkdir /usr/local/bin/man /usr/local/bin/man/man1 /usr/local/bin/man/man7 2>/dev/null
sed -e "s@|LIBDIR|@/usr/local/bin/lib@" -e "s@|TEXINPUTS|@/usr/local/tex/inputs@" xdoc/cpif.1 > /usr/local/bin/man/man1/cpif.1
sed -e "s@|LIBDIR|@/usr/local/bin/lib@" -e "s@|TEXINPUTS|@/usr/local/tex/inputs@" xdoc/nodefs.1 > /usr/local/bin/man/man1/nodefs.1
sed -e "s@|LIBDIR|@/usr/local/bin/lib@" -e "s@|TEXINPUTS|@/usr/local/tex/inputs@" xdoc/noroots.1 > /usr/local/bin/man/man1/noroots.1
sed -e "s@|LIBDIR|@/usr/local/bin/lib@" -e "s@|TEXINPUTS|@/usr/local/tex/inputs@" xdoc/noweb.1 > /usr/local/bin/man/man1/noweb.1
sed -e "s@|LIBDIR|@/usr/local/bin/lib@" -e "s@|TEXINPUTS|@/usr/local/tex/inputs@" xdoc/noindex.1 > /usr/local/bin/man/man1/noindex.1
sed -e "s@|LIBDIR|@/usr/local/bin/lib@" -e "s@|TEXINPUTS|@/usr/local/tex/inputs@" xdoc/nuweb2noweb.1 > /usr/local/bin/man/man1/nuweb2noweb.1
sed -e "s@|LIBDIR|@/usr/local/bin/lib@" -e "s@|TEXINPUTS|@/usr/local/tex/inputs@" xdoc/notangle.1 > /usr/local/bin/man/man1/notangle.1
sed -e "s@|LIBDIR|@/usr/local/bin/lib@" -e "s@|TEXINPUTS|@/usr/local/tex/inputs@" xdoc/noroff.1 > /usr/local/bin/man/man1/noroff.1
sed -e "s@|LIBDIR|@/usr/local/bin/lib@" -e "s@|TEXINPUTS|@/usr/local/tex/inputs@" xdoc/sl2h.1 > /usr/local/bin/man/man1/sl2h.1
sed -e "s@|LIBDIR|@/usr/local/bin/lib@" -e "s@|TEXINPUTS|@/usr/local/tex/inputs@" xdoc/htmltoc.1 > /usr/local/bin/man/man1/htmltoc.1
sed -e "s@|LIBDIR|@/usr/local/bin/lib@" -e "s@|TEXINPUTS|@/usr/local/tex/inputs@" xdoc/nowebstyle.7 > /usr/local/bin/man/man7/nowebstyle.7
sed -e "s@|LIBDIR|@/usr/local/bin/lib@" -e "s@|TEXINPUTS|@/usr/local/tex/inputs@" xdoc/nowebfilters.7 > /usr/local/bin/man/man7/nowebfilters.7
rm -f /usr/local/bin/man/man1/noweave.1
(cd /usr/local/bin/man/man1; ln notangle.1 noweave.1)
rm -f /usr/local/bin/man/man1/nountangle.1
(cd /usr/local/bin/man/man1; ln notangle.1 nountangle.1)
mkdir /usr/local/tex/inputs 2>/dev/null
make: [install-tex] Error 1 (ignored)
cp tex/nwmac.tex tex/noweb.sty /usr/local/tex/inputs
texhash || echo "Program texhash not found or failed"
texhash: Updating /usr/share/texmf/ls-R... 
texhash: Updating /usr/share/texmf-config/ls-R... 
texhash: Updating /usr/share/texmf-var/ls-R... 
texhash: Updating /var/lib/texmf/ls-R... 
texhash: Done.
mkdir /dev/null 2>/dev/null
make: [install-elisp] Error 1 (ignored)
cp elisp/noweb-mode.el /dev/null
[root@dhcppc0 src]# which notangle
/usr/local/bin/notangle

\start
Date: Wed, 13 Sep 2006 14:51:29 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: SVN on sourceforge

========================================================================
========================================================================
===== Building Axiom  first try ========================================
========================================================================
========================================================================

This went into an infinite loop in the make due to some kind of
timestamp problem.






[root@dhcppc0 src]# echo $AXIOM

[root@dhcppc0 src]# cd ..
[root@dhcppc0 noweb]# cd ..
[root@dhcppc0 zips]# cd ..
[root@dhcppc0 bi]# ls
axiom30yr.jpg	ChangeLog.build-improvements  lsp
axiomicon.png	config			      Makefile.in
axiomlogo.jpg	configure		      Makefile.pamphlet
axiomsml.png	configure.ac		      README
build-setup.sh	configure.ac.pamphlet	      README.build-improvements
ChangeLog	FAQ			      src
CHANGELOG	license			      zips
[root@dhcppc0 bi]# export AXIOM=`pwd`/mnt/linux
[root@dhcppc0 bi]# ./configure
checking build system type... i686-pc-linux
checking host system type... i686-pc-linux
checking target system type... i686-pc-linux
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for gawk... gawk
checking for gtar... gtar
checking for gpatch... no
checking for patch... patch
checking for make... make
checking for ranlib... ranlib
checking for touch... touch
checking for latex... latex
checking for makeindex... makeindex
checking for notangle... notangle
checking for noweave... noweave
checking for gcl... no
checking how to run the C preprocessor... gcc -E
checking for X... libraries , headers 
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
configure: SYSNAME=Fedora Core release 5 (Bordeaux)
configure: Linux
configure: configure complete.  Now type 
configure:                               
configure: make
configure: creating ./config.status
config.status: creating Makefile
config.status: creating lsp/Makefile
config.status: creating src/Makefile
config.status: creating src/lib/Makefile
config.status: creating src/boot/Makefile
config.status: creating src/interp/Makefile
config.status: creating src/share/Makefile
config.status: creating src/algebra/Makefile
config.status: creating src/etc/Makefile
config.status: creating src/clef/Makefile
config.status: creating src/doc/Makefile
config.status: creating src/graph/Makefile
config.status: creating src/graph/Gdraws/Makefile
config.status: creating src/graph/view2D/Makefile
config.status: creating src/graph/view3D/Makefile
config.status: creating src/graph/viewAlone/Makefile
config.status: creating src/graph/viewman/Makefile
config.status: creating src/sman/Makefile
config.status: creating src/hyper/Makefile
config.status: creating src/input/Makefile
config.status: creating src/booklets/Makefile
config.status: creating build/scripts/document
[root@dhcppc0 bi]# make
make: Warning: File `Makefile.in' has modification time 3.2e+06 s in the future
cd . && autoconf
cd /tmp/bi && /bin/sh ./config.status `echo /tmp/bi/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating Makefile
make: Warning: File `Makefile.in' has modification time 3.2e+06 s in the future
cd . && autoconf
cd /tmp/bi && /bin/sh ./config.status `echo /tmp/bi/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating Makefile
make: Warning: File `Makefile.in' has modification time 3.2e+06 s in the future
cd . && autoconf
cd /tmp/bi && /bin/sh ./config.status `echo /tmp/bi/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating Makefile
make: Warning: File `Makefile.in' has modification time 3.2e+06 s in the future
cd . && autoconf
cd /tmp/bi && /bin/sh ./config.status `echo /tmp/bi/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating Makefile
make: Warning: File `Makefile.in' has modification time 3.2e+06 s in the future
cd . && autoconf
cd /tmp/bi && /bin/sh ./config.status `echo /tmp/bi/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating Makefile
make: Warning: File `Makefile.in' has modification time 3.2e+06 s in the future
cd . && autoconf
cd /tmp/bi && /bin/sh ./config.status `echo /tmp/bi/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating Makefile
make: Warning: File `Makefile.in' has modification time 3.2e+06 s in the future
cd . && autoconf
cd /tmp/bi && /bin/sh ./config.status `echo /tmp/bi/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating Makefile
make: Warning: File `Makefile.in' has modification time 3.2e+06 s in the future
cd . && autoconf
cd /tmp/bi && /bin/sh ./config.status `echo /tmp/bi/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating Makefile
make: Warning: File `Makefile.in' has modification time 3.2e+06 s in the future
cd . && autoconf
cd /tmp/bi && /bin/sh ./config.status `echo /tmp/bi/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating Makefile
make: Warning: File `Makefile.in' has modification time 3.2e+06 s in the future
cd . && autoconf
cd /tmp/bi && /bin/sh ./config.status `echo /tmp/bi/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating Makefile
make: Warning: File `Makefile.in' has modification time 3.2e+06 s in the future
cd . && autoconf
make: *** [configure] Interrupt

\start
Date: Wed, 13 Sep 2006 14:52:13 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: SVN on sourceforge

========================================================================
========================================================================
==== Axiom build second try
========================================================================
========================================================================

So I touched every file, did a make clean, and tried again

Oddly this seems to be complaining about timestamps of 
programs that are not Axiom source code.






[root@dhcppc0 bi]# touch -R *
touch: invalid option -- R
Try `touch --help' for more information.
[root@dhcppc0 bi]# for i in `find .` ; do touch $i ; done
[root@dhcppc0 bi]# make clean
cd . && autoconf
cd /tmp/bi && /bin/sh ./config.status `echo /tmp/bi/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating Makefile
AXIOM=/tmp/bi/mnt/linux; export AXIOM; PATH=/tmp/bi/mnt/linux/bin:${PATH}; make do-clean
make[1]: Entering directory `/tmp/bi'
7 making a linux system, PART=cprogs SUBPART=everything
8 Environment SPAD=/tmp/bi/mnt/linux SYS=linux SPD=/tmp/bi LSP=/tmp/bi/lsp GCLDIR=/tmp/bi/lsp/gcl-2.6.8pre SRC=/tmp/bi/src INT=/tmp/bi/int OBJ=/tmp/bi/obj MNT=/tmp/bi/mnt ZIPS=/tmp/bi/zips TMP=/tmp/bi/obj/tmp SPADBIN=/tmp/bi/mnt/linux/bin INC=/tmp/bi/src/include CCLBASE=/tmp/bi/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /tmp/bi/obj/tmp/trace GCLVERSION=gcl-2.6.8pre TANGLE=notangle VERSION=Axiom (build improvements branch) -- 2006-09-12 DOCUMENT=/tmp/bi/build/scripts/document DAASE=/tmp/bi/src/share WEAVE=noweave AXIOM_X11_CFLAGS= AXIOM_X11_LDFLAGS=-lXpm  -lSM -lICE -lX11 
make[1]: Leaving directory `/tmp/bi'
[root@dhcppc0 bi]# make
AXIOM=/tmp/bi/mnt/linux; export AXIOM; PATH=/tmp/bi/mnt/linux/bin:${PATH}; make do-all
make[1]: Entering directory `/tmp/bi'
cd /tmp/bi && \
/bin/sh ./config.status build/scripts/document
config.status: creating build/scripts/document
./config/mkinstalldirs /tmp/bi/build/i686-pc-linux/share/texmf/tex && \
notangle -Raxiom.sty /tmp/bi/src/doc/axiom.sty.pamphlet > /tmp/bi/build/i686-pc-linux/share/texmf/tex/axiom.sty
mkdir -p -- /tmp/bi/build/i686-pc-linux/share/texmf/tex
10 copying /tmp/bi/src/scripts to /tmp/bi/build/scripts
echo timestamp > stamp-build-scripts
1 making a linux system, PART=cprogs SUBPART=everything
2 Environment SPAD=/tmp/bi/mnt/linux SYS=linux SPD=/tmp/bi LSP=/tmp/bi/lsp GCLDIR=/tmp/bi/lsp/gcl-2.6.8pre SRC=/tmp/bi/src INT=/tmp/bi/int OBJ=/tmp/bi/obj MNT=/tmp/bi/mnt ZIPS=/tmp/bi/zips TMP=/tmp/bi/obj/tmp SPADBIN=/tmp/bi/mnt/linux/bin INC=/tmp/bi/src/include CCLBASE=/tmp/bi/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /tmp/bi/obj/tmp/trace GCLVERSION=gcl-2.6.8pre TANGLE=notangle VERSION=Axiom (build improvements branch) -- 2006-09-12 DOCUMENT=/tmp/bi/build/scripts/document DAASE=/tmp/bi/src/share WEAVE=noweave AXIOM_X11_CFLAGS= AXIOM_X11_LDFLAGS=-lXpm  -lSM -lICE -lX11 
make[2]: Entering directory `/tmp/bi'
11 checking directory structure
12 Environment: SPAD=/tmp/bi/mnt/linux SYS=linux SPD=/tmp/bi LSP=/tmp/bi/lsp GCLDIR=/tmp/bi/lsp/gcl-2.6.8pre SRC=/tmp/bi/src INT=/tmp/bi/int OBJ=/tmp/bi/obj MNT=/tmp/bi/mnt ZIPS=/tmp/bi/zips TMP=/tmp/bi/obj/tmp SPADBIN=/tmp/bi/mnt/linux/bin INC=/tmp/bi/src/include CCLBASE=/tmp/bi/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /tmp/bi/obj/tmp/trace GCLVERSION=gcl-2.6.8pre TANGLE=notangle VERSION=Axiom (build improvements branch) -- 2006-09-12 DOCUMENT=/tmp/bi/build/scripts/document DAASE=/tmp/bi/src/share WEAVE=noweave AXIOM_X11_CFLAGS= AXIOM_X11_LDFLAGS=-lXpm  -lSM -lICE -lX11 
make[2]: Leaving directory `/tmp/bi'
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./Makefile.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo))
(/tmp/bi/build/i686-pc-linux/share/texmf/tex/axiom.sty)
No file Makefile.aux.
[1]
No file Makefile.toc.
[2] [3] [4]
Overfull \hbox (41.71167pt too wide) in paragraph at lines 111--115
\OT1/cmr/m/n/10 for de-bug-ging pur-poses. We use the spe-cific file \OT1/cmtt/
m/n/10 $(top_builddir)/build/stamp-scripts
[5] [6] [7] [8] [9]
Overfull \hbox (34.22025pt too wide) in paragraph at lines 347--350
[]\OT1/cmr/m/n/10 The \OT1/cmtt/m/n/10 DOCUMENT \OT1/cmr/m/n/10 vari-able is no
w set to re-place the di-rect call to the \OT1/cmtt/m/n/10 $SPADBIN/document
[10] [11] [12] [13]
Overfull \hbox (48.74657pt too wide) in paragraph at lines 516--516
[]\OT1/cmtt/m/n/10 the {\tt{}noweb.src.shell.roff.mm.patch} file remove the ins
ecure temp file[] 

Overfull \hbox (17.24684pt too wide) in paragraph at lines 516--516
[]\OT1/cmtt/m/n/10 {\tt{}noweb.src.lib.toascii.patch} because this is not a sou
rce file.[] 
[14]
Overfull \hbox (53.99652pt too wide) in paragraph at lines 516--516
[]        \OT1/cmtt/m/n/10 ${ENV} ${MAKE} BIN=${MNT}/${SYS}/bin/lib LIB=${MNT}/
${SYS}/bin/lib \[] 

Overfull \hbox (48.74657pt too wide) in paragraph at lines 516--516
[]                \OT1/cmtt/m/n/10 TEXINPUTS=${MNT}/${SYS}/bin/tex all install 
>${TMP}/trace )[] 

Overfull \hbox (22.4968pt too wide) in paragraph at lines 516--516
[]        \OT1/cmtt/m/n/10 @echo The file marks the fact that noweb has been ma
de > noweb[] 
[15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]
[30] [31] [32] [33] [34] (./Makefile.aux)

LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.

 )
(see the transcript file for additional information)
Output written on Makefile.dvi (34 pages, 55328 bytes).
Transcript written on Makefile.log.
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./Makefile.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo))
(/tmp/bi/build/i686-pc-linux/share/texmf/tex/axiom.sty) (./Makefile.aux)
[1] (./Makefile.toc [2]) [3] [4] [5]
Overfull \hbox (41.71167pt too wide) in paragraph at lines 111--115
\OT1/cmr/m/n/10 for de-bug-ging pur-poses. We use the spe-cific file \OT1/cmtt/
m/n/10 $(top_builddir)/build/stamp-scripts
[6] [7] [8] [9] [10]
Overfull \hbox (34.22025pt too wide) in paragraph at lines 347--350
[]\OT1/cmr/m/n/10 The \OT1/cmtt/m/n/10 DOCUMENT \OT1/cmr/m/n/10 vari-able is no
w set to re-place the di-rect call to the \OT1/cmtt/m/n/10 $SPADBIN/document
[11] [12] [13] [14]
Overfull \hbox (48.74657pt too wide) in paragraph at lines 516--516
[]\OT1/cmtt/m/n/10 the {\tt{}noweb.src.shell.roff.mm.patch} file remove the ins
ecure temp file[] 

Overfull \hbox (17.24684pt too wide) in paragraph at lines 516--516
[]\OT1/cmtt/m/n/10 {\tt{}noweb.src.lib.toascii.patch} because this is not a sou
rce file.[] 
[15]
Overfull \hbox (53.99652pt too wide) in paragraph at lines 516--516
[]        \OT1/cmtt/m/n/10 ${ENV} ${MAKE} BIN=${MNT}/${SYS}/bin/lib LIB=${MNT}/
${SYS}/bin/lib \[] 

Overfull \hbox (48.74657pt too wide) in paragraph at lines 516--516
[]                \OT1/cmtt/m/n/10 TEXINPUTS=${MNT}/${SYS}/bin/tex all install 
>${TMP}/trace )[] 

Overfull \hbox (22.4968pt too wide) in paragraph at lines 516--516
[]        \OT1/cmtt/m/n/10 @echo The file marks the fact that noweb has been ma
de > noweb[] 
[16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]
[31] [32] [33] [34] [35] (./Makefile.aux) )
(see the transcript file for additional information)
Output written on Makefile.dvi (35 pages, 74768 bytes).
Transcript written on Makefile.log.
make[2]: Entering directory `/tmp/bi'
18 making /tmp/bi/src
make[3]: Entering directory `/tmp/bi/src'
cd /tmp/bi/src/../. && /bin/sh ./config.status `echo /tmp/bi/src/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating src/Makefile
make[3]: Leaving directory `/tmp/bi/src'
make[3]: Entering directory `/tmp/bi/src'
17 making ./lib
make[4]: Entering directory `/tmp/bi/src/lib'
cd /tmp/bi/src/lib/../../. && /bin/sh ./config.status `echo /tmp/bi/src/lib/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating src/lib/Makefile
make[4]: Leaving directory `/tmp/bi/src/lib'
make[4]: Entering directory `/tmp/bi/src/lib'
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=bsdsignal.c bsdsignal.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include bsdsignal.c -o /tmp/bi/obj/linux/lib/bsdsignal.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=cursor.c cursor.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include cursor.c -o /tmp/bi/obj/linux/lib/cursor.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=edin.c edin.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include edin.c -o /tmp/bi/obj/linux/lib/edin.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=fnct_key.c fnct_key.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include fnct_key.c -o /tmp/bi/obj/linux/lib/fnct_key.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=halloc.c halloc.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include halloc.c -o /tmp/bi/obj/linux/lib/halloc.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=openpty.c openpty.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include openpty.c -o /tmp/bi/obj/linux/lib/openpty.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=pixmap.c pixmap.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include pixmap.c -o /tmp/bi/obj/linux/lib/pixmap.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=prt.c prt.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include prt.c -o /tmp/bi/obj/linux/lib/prt.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=sockio-c.c sockio-c.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include sockio-c.c -o /tmp/bi/obj/linux/lib/sockio-c.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=spadcolors.c spadcolors.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include spadcolors.c -o /tmp/bi/obj/linux/lib/spadcolors.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=util.c util.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include util.c -o /tmp/bi/obj/linux/lib/util.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=wct.c wct.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include wct.c -o /tmp/bi/obj/linux/lib/wct.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=XDither.c XDither.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include XDither.c -o /tmp/bi/obj/linux/lib/XDither.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=XShade.c XShade.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include XShade.c -o /tmp/bi/obj/linux/lib/XShade.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=XSpadFill.c XSpadFill.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include XSpadFill.c -o /tmp/bi/obj/linux/lib/XSpadFill.o
73 making /tmp/bi/obj/linux/lib/libspad.a
ar: creating /tmp/bi/obj/linux/lib/libspad.a
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=cfuns-c.c cfuns-c.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include cfuns-c.c -o /tmp/bi/obj/linux/lib/cfuns-c.o
/tmp/bi/src/lib/../.././build/scripts/document --tangle --output=hash.c hash.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -c -I/tmp/bi/src/include hash.c -o /tmp/bi/obj/linux/lib/hash.o
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=bsdsignal.c.tex bsdsignal.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex bsdsignal.c.tex > /dev/null
/usr/bin/install -c bsdsignal.c.dvi /tmp/bi/mnt/linux/doc/src/lib/bsdsignal.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=cfuns-c.c.tex cfuns-c.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex cfuns-c.c.tex > /dev/null
/usr/bin/install -c cfuns-c.c.dvi /tmp/bi/mnt/linux/doc/src/lib/cfuns-c.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=cursor.c.tex cursor.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex cursor.c.tex > /dev/null
/usr/bin/install -c cursor.c.dvi /tmp/bi/mnt/linux/doc/src/lib/cursor.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=edin.c.tex edin.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex edin.c.tex > /dev/null
/usr/bin/install -c edin.c.dvi /tmp/bi/mnt/linux/doc/src/lib/edin.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=fnct_key.c.tex fnct_key.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex fnct_key.c.tex > /dev/null
/usr/bin/install -c fnct_key.c.dvi /tmp/bi/mnt/linux/doc/src/lib/fnct_key.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=halloc.c.tex halloc.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex halloc.c.tex > /dev/null
/usr/bin/install -c halloc.c.dvi /tmp/bi/mnt/linux/doc/src/lib/halloc.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=hash.c.tex hash.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex hash.c.tex > /dev/null
/usr/bin/install -c hash.c.dvi /tmp/bi/mnt/linux/doc/src/lib/hash.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=openpty.c.tex openpty.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex openpty.c.tex > /dev/null
/usr/bin/install -c openpty.c.dvi /tmp/bi/mnt/linux/doc/src/lib/openpty.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=pixmap.c.tex pixmap.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex pixmap.c.tex > /dev/null
/usr/bin/install -c pixmap.c.dvi /tmp/bi/mnt/linux/doc/src/lib/pixmap.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=prt.c.tex prt.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex prt.c.tex > /dev/null
/usr/bin/install -c prt.c.dvi /tmp/bi/mnt/linux/doc/src/lib/prt.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=sockio-c.c.tex sockio-c.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex sockio-c.c.tex > /dev/null
/usr/bin/install -c sockio-c.c.dvi /tmp/bi/mnt/linux/doc/src/lib/sockio-c.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=Makefile.tex Makefile.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex Makefile.tex > /dev/null
/usr/bin/install -c Makefile.dvi /tmp/bi/mnt/linux/doc/src/lib/Makefile.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=spadcolors.c.tex spadcolors.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex spadcolors.c.tex > /dev/null
/usr/bin/install -c spadcolors.c.dvi /tmp/bi/mnt/linux/doc/src/lib/spadcolors.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=util.c.tex util.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex util.c.tex > /dev/null
/usr/bin/install -c util.c.dvi /tmp/bi/mnt/linux/doc/src/lib/util.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=wct.c.tex wct.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex wct.c.tex > /dev/null
/usr/bin/install -c wct.c.dvi /tmp/bi/mnt/linux/doc/src/lib/wct.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=XDither.c.tex XDither.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex XDither.c.tex > /dev/null
/usr/bin/install -c XDither.c.dvi /tmp/bi/mnt/linux/doc/src/lib/XDither.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=XShade.c.tex XShade.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex XShade.c.tex > /dev/null
/usr/bin/install -c XShade.c.dvi /tmp/bi/mnt/linux/doc/src/lib/XShade.c.dvi
/tmp/bi/src/lib/../.././build/scripts/document --weave --output=XSpadFill.c.tex XSpadFill.c.pamphlet
/tmp/bi/src/lib/../.././build/scripts/document --latex XSpadFill.c.tex > /dev/null
/usr/bin/install -c XSpadFill.c.dvi /tmp/bi/mnt/linux/doc/src/lib/XSpadFill.c.dvi
72 finished making .
make[4]: Leaving directory `/tmp/bi/src/lib'
make[3]: Leaving directory `/tmp/bi/src'
19 making /tmp/bi/lsp
make[3]: Entering directory `/tmp/bi/lsp'
cd /tmp/bi/lsp/../. && /bin/sh ./config.status `echo /tmp/bi/lsp/ | sed -e 's|/tmp/bi/||'`Makefile
config.status: creating lsp/Makefile
make[3]: Leaving directory `/tmp/bi/lsp'
make[3]: Entering directory `/tmp/bi/lsp'
1 building /tmp/bi/lsp gcl-2.6.8pre
make[4]: Entering directory `/tmp/bi/lsp'
gtar -zxf /tmp/bi/lsp/../zips/gcl-2.6.8pre.tgz
gtar: gcl-2.6.8pre/h/coff: time stamp 2006-08-26 02:33:38 is 1645894 s in the future
gtar: gcl-2.6.8pre/h/cmplrs: time stamp 2006-08-26 02:33:38 is 1645894 s in the future
gtar: gcl-2.6.8pre/h/page.h: time stamp 2006-08-10 13:50:35 is 304111 s in the future
gtar: gcl-2.6.8pre/h: time stamp 2006-08-26 02:33:38 is 1645894 s in the future
gtar: gcl-2.6.8pre/o/unixfsys.c: time stamp 2006-08-23 14:14:22 is 1428738 s in the future
gtar: gcl-2.6.8pre/o/gbc.c: time stamp 2006-08-11 22:15:52 is 420828 s in the future
gtar: gcl-2.6.8pre/o/cmpaux.c: time stamp 2006-08-25 15:08:41 is 1604797 s in the future
gtar: gcl-2.6.8pre/o/read.d: time stamp 2006-08-25 12:32:53 is 1595449 s in the future
gtar: gcl-2.6.8pre/o/alloc.c: time stamp 2006-08-10 13:50:35 is 304111 s in the future
gtar: gcl-2.6.8pre/o: time stamp 2006-08-26 02:33:41 is 1645897 s in the future
gtar: gcl-2.6.8pre/go: time stamp 2006-08-26 02:33:37 is 1645893 s in the future
gtar: gcl-2.6.8pre/mp: time stamp 2006-08-26 02:33:39 is 1645895 s in the future
gtar: gcl-2.6.8pre/bin: time stamp 2006-08-26 02:32:18 is 1645814 s in the future
gtar: gcl-2.6.8pre/doc: time stamp 2006-08-26 02:33:28 is 1645884 s in the future
gtar: gcl-2.6.8pre/dos: time stamp 2006-08-26 02:33:28 is 1645884 s in the future
gtar: gcl-2.6.8pre/man/man1: time stamp 2006-08-26 02:33:39 is 1645895 s in the future
gtar: gcl-2.6.8pre/man: time stamp 2006-08-26 02:33:39 is 1645895 s in the future
gtar: gcl-2.6.8pre/lsp: time stamp 2006-08-26 02:33:39 is 1645895 s in the future
gtar: gcl-2.6.8pre/pcl/old: time stamp 2006-08-26 02:33:42 is 1645898 s in the future
gtar: gcl-2.6.8pre/pcl/impl/hp: time stamp 2006-08-26 02:33:41 is 1645897 s in the future
gtar: gcl-2.6.8pre/pcl/impl/ti: time stamp 2006-08-26 02:33:42 is 1645898 s in the future
gtar: gcl-2.6.8pre/pcl/impl/cmu: time stamp 2006-08-26 02:33:41 is 1645897 s in the future
gtar: gcl-2.6.8pre/pcl/impl/gcl: time stamp 2006-08-26 02:33:41 is 1645896 s in the future
gtar: gcl-2.6.8pre/pcl/impl/kcl: time stamp 2006-08-26 02:33:41 is 1645896 s in the future
gtar: gcl-2.6.8pre/pcl/impl/ibcl: time stamp 2006-08-26 02:33:41 is 1645896 s in the future
gtar: gcl-2.6.8pre/pcl/impl/pyramid: time stamp 2006-08-26 02:33:41 is 1645896 s in the future
gtar: gcl-2.6.8pre/pcl/impl/gold-hill: time stamp 2006-08-26 02:33:41 is 1645896 s in the future
gtar: gcl-2.6.8pre/pcl/impl/coral: time stamp 2006-08-26 02:33:41 is 1645896 s in the future
gtar: gcl-2.6.8pre/pcl/impl/franz: time stamp 2006-08-26 02:33:41 is 1645896 s in the future
gtar: gcl-2.6.8pre/pcl/impl/lucid: time stamp 2006-08-26 02:33:41 is 1645896 s in the future
gtar: gcl-2.6.8pre/pcl/impl/xerox: time stamp 2006-08-26 02:33:42 is 1645897 s in the future
gtar: gcl-2.6.8pre/pcl/impl/symbolics: time stamp 2006-08-26 02:33:41 is 1645896 s in the future
gtar: gcl-2.6.8pre/pcl/impl/vaxlisp: time stamp 2006-08-26 02:33:42 is 1645897 s in the future
gtar: gcl-2.6.8pre/pcl/impl: time stamp 2006-08-26 02:33:42 is 1645897 s in the future
gtar: gcl-2.6.8pre/pcl/test: time stamp 2006-08-26 02:33:42 is 1645897 s in the future
gtar: gcl-2.6.8pre/pcl/notes: time stamp 2006-08-26 02:33:42 is 1645897 s in the future
gtar: gcl-2.6.8pre/pcl/unused: time stamp 2006-08-26 02:33:42 is 1645897 s in the future
gtar: gcl-2.6.8pre/pcl/extensions: time stamp 2006-08-26 02:33:41 is 1645896 s in the future
gtar: gcl-2.6.8pre/pcl: time stamp 2006-08-26 02:33:42 is 1645897 s in the future
gtar: gcl-2.6.8pre/clcs/unused: time stamp 2006-08-26 02:33:27 is 1645882 s in the future
gtar: gcl-2.6.8pre/clcs: time stamp 2006-08-26 02:33:27 is 1645882 s in the future
gtar: gcl-2.6.8pre/comp: time stamp 2006-08-26 02:33:27 is 1645882 s in the future
gtar: gcl-2.6.8pre/gmp3/cxx: time stamp 2006-08-26 02:33:31 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/doc: time stamp 2006-08-26 02:33:31 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpf: time stamp 2006-08-26 02:33:32 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/sh/sh2: time stamp 2006-08-26 02:33:33 is 1645888 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/sh: time stamp 2006-08-26 02:33:33 is 1645888 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/arm: time stamp 2006-08-26 02:33:32 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/pyr: time stamp 2006-08-26 02:33:33 is 1645888 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/k6/mmx: time stamp 2006-08-26 02:33:34 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/k6/k62mmx: time stamp 2006-08-26 02:33:34 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/k6: time stamp 2006-08-26 02:33:34 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/k7/mmx: time stamp 2006-08-26 02:33:34 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/k7: time stamp 2006-08-26 02:33:34 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/p6/mmx: time stamp 2006-08-26 02:33:34 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/p6/p3mmx: time stamp 2006-08-26 02:33:34 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/p6: time stamp 2006-08-26 02:33:34 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/i486: time stamp 2006-08-26 02:33:33 is 1645888 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/pentium/mmx: time stamp 2006-08-26 02:33:34 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/pentium: time stamp 2006-08-26 02:33:34 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/pentium4/mmx: time stamp 2006-08-26 02:33:34 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/pentium4/sse2: time stamp 2006-08-26 02:33:34 is 1645888 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86/pentium4: time stamp 2006-08-26 02:33:34 is 1645888 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/x86: time stamp 2006-08-26 02:33:34 is 1645888 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/vax: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/a29k: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/cray/cfp: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/cray/ieee: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/cray: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/i960: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/ia64: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/m68k/mc68020: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/m68k: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/m88k/mc88110: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/m88k: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/hppa/hppa1_1/pa7100: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/hppa/hppa1_1: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/hppa/hppa2_0: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/hppa: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/lisp: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/s390: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/pa64: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/powerpc32: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/powerpc64: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/alpha/ev5: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/alpha/ev6: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/alpha: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/mips2: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/mips3: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/ns32k: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/pa64w: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/power: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/thumb: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/z8000: time stamp 2006-08-26 02:33:34 is 1645888 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/sparc32/v8/supersparc: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/sparc32/v8: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/sparc32/v9: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/sparc32: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/sparc64: time stamp 2006-08-26 02:33:33 is 1645887 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/generic: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/z8000x: time stamp 2006-08-26 02:33:34 is 1645888 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn/clipper: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/mpn: time stamp 2006-08-26 02:33:34 is 1645888 s in the future
gtar: gcl-2.6.8pre/gmp3/mpq: time stamp 2006-08-26 02:33:35 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpz: time stamp 2006-08-26 02:33:35 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/mpfr: time stamp 2006-08-26 02:33:32 is 1645886 s in the future
gtar: gcl-2.6.8pre/gmp3/tune: time stamp 2006-08-26 02:33:37 is 1645891 s in the future
gtar: gcl-2.6.8pre/gmp3/demos/calc: time stamp 2006-08-26 02:33:31 is 1645885 s in the future
gtar: gcl-2.6.8pre/gmp3/demos/expr: time stamp 2006-08-26 02:33:31 is 1645885 s in the future
gtar: gcl-2.6.8pre/gmp3/demos/perl/GMP: time stamp 2006-08-26 02:33:31 is 1645885 s in the future
gtar: gcl-2.6.8pre/gmp3/demos/perl: time stamp 2006-08-26 02:33:31 is 1645884 s in the future
gtar: gcl-2.6.8pre/gmp3/demos: time stamp 2006-08-26 02:33:31 is 1645884 s in the future
gtar: gcl-2.6.8pre/gmp3/macos: time stamp 2006-08-26 02:33:31 is 1645884 s in the future
gtar: gcl-2.6.8pre/gmp3/mpbsd: time stamp 2006-08-26 02:33:31 is 1645884 s in the future
gtar: gcl-2.6.8pre/gmp3/scanf: time stamp 2006-08-26 02:33:36 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/tests/cxx: time stamp 2006-08-26 02:33:36 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/tests/mpf: time stamp 2006-08-26 02:33:36 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/tests/mpn: time stamp 2006-08-26 02:33:36 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/tests/mpq: time stamp 2006-08-26 02:33:36 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/tests/mpz: time stamp 2006-08-26 02:33:36 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/tests/misc: time stamp 2006-08-26 02:33:36 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/tests/rand: time stamp 2006-08-26 02:33:37 is 1645890 s in the future
gtar: gcl-2.6.8pre/gmp3/tests/devel: time stamp 2006-08-26 02:33:36 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/tests/mpbsd: time stamp 2006-08-26 02:33:36 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/tests: time stamp 2006-08-26 02:33:36 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3/debian: time stamp 2006-08-26 02:33:31 is 1645884 s in the future
gtar: gcl-2.6.8pre/gmp3/printf: time stamp 2006-08-26 02:33:36 is 1645889 s in the future
gtar: gcl-2.6.8pre/gmp3: time stamp 2006-08-26 02:33:37 is 1645890 s in the future
gtar: gcl-2.6.8pre/info: time stamp 2006-08-26 02:33:39 is 1645892 s in the future
gtar: gcl-2.6.8pre/misc: time stamp 2006-08-26 02:33:39 is 1645892 s in the future
gtar: gcl-2.6.8pre/xbin: time stamp 2006-08-26 02:33:42 is 1645895 s in the future
gtar: gcl-2.6.8pre/binutils/ld/po: time stamp 2006-08-26 02:33:13 is 1645866 s in the future
gtar: gcl-2.6.8pre/binutils/ld/emulparams: time stamp 2006-08-26 02:33:13 is 1645865 s in the future
gtar: gcl-2.6.8pre/binutils/ld/emultempl: time stamp 2006-08-26 02:33:13 is 1645865 s in the future
gtar: gcl-2.6.8pre/binutils/ld/scripttempl: time stamp 2006-08-26 02:33:13 is 1645865 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/lib: time stamp 2006-08-26 02:33:22 is 1645874 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-scripts: time stamp 2006-08-26 02:33:21 is 1645873 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-auto-import: time stamp 2006-08-26 02:33:14 is 1645866 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-elfcomm: time stamp 2006-08-26 02:33:15 is 1645867 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-elfvers: time stamp 2006-08-26 02:33:16 is 1645868 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-elfweak: time stamp 2006-08-26 02:33:16 is 1645868 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-d10v: time stamp 2006-08-26 02:33:15 is 1645867 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-i386: time stamp 2006-08-26 02:33:17 is 1645869 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-cris: time stamp 2006-08-26 02:33:14 is 1645866 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-ia64: time stamp 2006-08-26 02:33:17 is 1645869 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-maxq: time stamp 2006-08-26 02:33:17 is 1645869 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-mmix: time stamp 2006-08-26 02:33:20 is 1645872 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-s390: time stamp 2006-08-26 02:33:20 is 1645872 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-v850: time stamp 2006-08-26 02:33:22 is 1645874 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-srec: time stamp 2006-08-26 02:33:22 is 1645874 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-pe: time stamp 2006-08-26 02:33:20 is 1645872 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-sh/arch: time stamp 2006-08-26 02:33:21 is 1645873 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-sh/sh64: time stamp 2006-08-26 02:33:22 is 1645874 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-sh: time stamp 2006-08-26 02:33:21 is 1645872 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-bootstrap: time stamp 2006-08-26 02:33:14 is 1645865 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-fastcall: time stamp 2006-08-26 02:33:16 is 1645867 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-cdtest: time stamp 2006-08-26 02:33:14 is 1645865 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-checks: time stamp 2006-08-26 02:33:14 is 1645865 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-cygwin: time stamp 2006-08-26 02:33:14 is 1645865 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-elfvsb: time stamp 2006-08-26 02:33:16 is 1645867 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-selective: time stamp 2006-08-26 02:33:21 is 1645872 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-alpha: time stamp 2006-08-26 02:33:13 is 1645864 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-h8300: time stamp 2006-08-26 02:33:17 is 1645868 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-sparc: time stamp 2006-08-26 02:33:22 is 1645873 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/config: time stamp 2006-08-26 02:33:13 is 1645864 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-shared: time stamp 2006-08-26 02:33:22 is 1645873 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-versados: time stamp 2006-08-26 02:33:22 is 1645873 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-x86-64: time stamp 2006-08-26 02:33:22 is 1645873 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-m68hc11: time stamp 2006-08-26 02:33:17 is 1645868 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-mips-elf: time stamp 2006-08-26 02:33:18 is 1645869 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-xtensa: time stamp 2006-08-26 02:33:22 is 1645873 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-arm: time stamp 2006-08-26 02:33:14 is 1645865 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-crx: time stamp 2006-08-26 02:33:14 is 1645865 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-elf: time stamp 2006-08-26 02:33:15 is 1645866 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-frv: time stamp 2006-08-26 02:33:16 is 1645866 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-undefined: time stamp 2006-08-26 02:33:22 is 1645872 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-powerpc: time stamp 2006-08-26 02:33:20 is 1645870 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-linkonce: time stamp 2006-08-26 02:33:17 is 1645867 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-discard: time stamp 2006-08-26 02:33:15 is 1645865 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite/ld-xstormy16: time stamp 2006-08-26 02:33:22 is 1645872 s in the future
gtar: gcl-2.6.8pre/binutils/ld/testsuite: time stamp 2006-08-26 02:33:22 is 1645872 s in the future
gtar: gcl-2.6.8pre/binutils/ld: time stamp 2006-08-26 02:33:13 is 1645863 s in the future
gtar: gcl-2.6.8pre/binutils/bfd/po: time stamp 2006-08-26 02:32:30 is 1645820 s in the future
gtar: gcl-2.6.8pre/binutils/bfd/doc: time stamp 2006-08-26 02:32:29 is 1645819 s in the future
gtar: gcl-2.6.8pre/binutils/bfd/hosts: time stamp 2006-08-26 02:32:30 is 1645820 s in the future
gtar: gcl-2.6.8pre/binutils/bfd: time stamp 2006-08-26 02:32:30 is 1645819 s in the future
gtar: gcl-2.6.8pre/binutils/cpu: time stamp 2006-08-26 02:32:34 is 1645823 s in the future
gtar: gcl-2.6.8pre/binutils/etc: time stamp 2006-08-26 02:32:35 is 1645823 s in the future
gtar: gcl-2.6.8pre/binutils/gas/po: time stamp 2006-08-26 02:32:46 is 1645834 s in the future
gtar: gcl-2.6.8pre/binutils/gas/doc: time stamp 2006-08-26 02:32:45 is 1645833 s in the future
gtar: gcl-2.6.8pre/binutils/gas/config: time stamp 2006-08-26 02:32:44 is 1645831 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/pj: time stamp 2006-08-26 02:33:00 is 1645847 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/sh/arch: time stamp 2006-08-26 02:33:01 is 1645848 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/sh/sh64: time stamp 2006-08-26 02:33:01 is 1645848 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/sh: time stamp 2006-08-26 02:33:01 is 1645848 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/all: time stamp 2006-08-26 02:32:46 is 1645833 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/arc: time stamp 2006-08-26 02:32:47 is 1645834 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/arm: time stamp 2006-08-26 02:32:47 is 1645834 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/cfi: time stamp 2006-08-26 02:32:48 is 1645835 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/crx: time stamp 2006-08-26 02:32:49 is 1645836 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/dlx: time stamp 2006-08-26 02:32:50 is 1645837 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/elf: time stamp 2006-08-26 02:32:50 is 1645837 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/frv: time stamp 2006-08-26 02:32:50 is 1645837 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/mri: time stamp 2006-08-26 02:33:00 is 1645847 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/ppc: time stamp 2006-08-26 02:33:00 is 1645847 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/vax: time stamp 2006-08-26 02:33:07 is 1645854 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/z8k: time stamp 2006-08-26 02:33:07 is 1645854 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/d10v: time stamp 2006-08-26 02:32:50 is 1645837 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/d30v: time stamp 2006-08-26 02:32:50 is 1645836 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/i386: time stamp 2006-08-26 02:32:53 is 1645839 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/cris: time stamp 2006-08-26 02:32:49 is 1645835 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/i860: time stamp 2006-08-26 02:32:53 is 1645839 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/fr30: time stamp 2006-08-26 02:32:50 is 1645836 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/m32r: time stamp 2006-08-26 02:32:54 is 1645840 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/ia64: time stamp 2006-08-26 02:32:54 is 1645840 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/m68k: time stamp 2006-08-26 02:32:55 is 1645841 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/m88k: time stamp 2006-08-26 02:32:55 is 1645841 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/hppa/basic: time stamp 2006-08-26 02:32:52 is 1645838 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/hppa/parse: time stamp 2006-08-26 02:32:52 is 1645838 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/hppa/reloc: time stamp 2006-08-26 02:32:52 is 1645838 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/hppa/unsorted: time stamp 2006-08-26 02:32:52 is 1645838 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/hppa: time stamp 2006-08-26 02:32:52 is 1645838 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/mips: time stamp 2006-08-26 02:32:58 is 1645843 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/mmix: time stamp 2006-08-26 02:32:59 is 1645844 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/s390: time stamp 2006-08-26 02:33:00 is 1645845 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/v850: time stamp 2006-08-26 02:33:07 is 1645852 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/sun4: time stamp 2006-08-26 02:33:02 is 1645847 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/alpha: time stamp 2006-08-26 02:32:46 is 1645831 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/h8300: time stamp 2006-08-26 02:32:51 is 1645836 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/mcore: time stamp 2006-08-26 02:32:55 is 1645840 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/pdp11: time stamp 2006-08-26 02:33:00 is 1645845 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/sparc: time stamp 2006-08-26 02:33:02 is 1645846 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/tic80: time stamp 2006-08-26 02:33:06 is 1645850 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/tic4x: time stamp 2006-08-26 02:33:02 is 1645846 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/mn10200: time stamp 2006-08-26 02:32:59 is 1645843 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/mn10300: time stamp 2006-08-26 02:33:00 is 1645844 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/iq2000: time stamp 2006-08-26 02:32:54 is 1645838 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/macros: time stamp 2006-08-26 02:32:55 is 1645839 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/maxq10: time stamp 2006-08-26 02:32:55 is 1645839 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/maxq20: time stamp 2006-08-26 02:32:55 is 1645839 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/msp430: time stamp 2006-08-26 02:33:00 is 1645844 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/sparc-solaris: time stamp 2006-08-26 02:33:02 is 1645846 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/tic54x: time stamp 2006-08-26 02:33:06 is 1645849 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/m68hc11: time stamp 2006-08-26 02:32:54 is 1645837 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/symver: time stamp 2006-08-26 02:33:02 is 1645845 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/openrisc: time stamp 2006-08-26 02:33:00 is 1645843 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/m68k-coff: time stamp 2006-08-26 02:32:55 is 1645838 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/xtensa: time stamp 2006-08-26 02:33:07 is 1645850 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/xstormy16: time stamp 2006-08-26 02:33:07 is 1645850 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas/ieee-fp: time stamp 2006-08-26 02:32:54 is 1645837 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/gas: time stamp 2006-08-26 02:33:07 is 1645850 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/lib: time stamp 2006-08-26 02:33:07 is 1645850 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite/config: time stamp 2006-08-26 02:32:46 is 1645829 s in the future
gtar: gcl-2.6.8pre/binutils/gas/testsuite: time stamp 2006-08-26 02:33:07 is 1645850 s in the future
gtar: gcl-2.6.8pre/binutils/gas: time stamp 2006-08-26 02:32:46 is 1645829 s in the future
gtar: gcl-2.6.8pre/binutils/intl: time stamp 2006-08-26 02:33:10 is 1645853 s in the future
gtar: Skipping to next header
gtar: Archive contains obsolescent base-64 headers

gzip: stdin: invalid compressed data--crc error

gzip: stdin: invalid compressed data--length error
gtar: Child returned status 1
gtar: gcl-2.6.8pre/binutils/binutils/po: time stamp 2006-08-26 02:32:33 is 1645815 s in the future
gtar: gcl-2.6.8pre/binutils/binutils: time stamp 2006-08-26 02:32:33 is 1645815 s in the future
gtar: gcl-2.6.8pre/binutils: time stamp 2006-08-26 02:33:26 is 1645868 s in the future
gtar: gcl-2.6.8pre: time stamp 2006-08-26 02:33:42 is 1645884 s in the future
gtar: Error exit delayed from previous errors
make[4]: *** [gcl-2.6.8predir] Error 2
make[4]: Leaving directory `/tmp/bi/lsp'
make[3]: *** [stamp-gcldir] Error 2
make[3]: Leaving directory `/tmp/bi/lsp'
make[2]: *** [lspdir] Error 2
make[2]: Leaving directory `/tmp/bi'
make[1]: *** [do-all] Error 2
make[1]: Leaving directory `/tmp/bi'
make: *** [all] Error 2
[root@dhcppc0 bi]# cd ..
[root@dhcppc0 tmp]# rm -rf bi
[root@dhcppc0 tmp]# 

\start
Date: 13 Sep 2006 21:08:01 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements and latex
Cc: Waldek Hebisch

Bill Page writes:

| On Wednesday, September 13, 2006 1:08 PM Waldek Hebisch wrote:
| > 
| > I have updated to version 133 of build-improvements branch and 
| > retried build on the same Debian testing machine. Now build goes
| > further, but fails running Latex on clifford.spad.tex
| > The reason for failure is missing amssymb.sty file.
| > I am affraid that if we want clean build, then configure should check
| > for all latex packages used.
| > 
| 
| I still think it makes better sense to *not* run the LaTeX part
| of the build by default. If somebody wants it, they should be
| able to run something like:
| 
|   make documentation-all

Yes, that is way most GNU standard projects work, mke; make dvi; make
ps; make pdf or whatever.  But the idea is not unanimous here.

\start
Date: 13 Sep 2006 21:10:04 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex
Cc: Waldek Hebisch

Ralf Hemmecke writes:

| Hmm, maybe we are not at that stage ...

*Yes*

We need to get running on as many platform as "popular"; then we gain
critical mass; then we get the fanciest things. 

\start
Date: Wed, 13 Sep 2006 14:14:50 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: SVN on sourceforge

On Wed, 13 Sep 2006, root wrote:

| The make all install failed to terminate, looping infintely deeper.

Now that you mention it, I do remain that I ran into the same issue
and finally solved it.

There is something to be said for non-standard build systems :-)

\start
Date: Wed, 13 Sep 2006 15:15:59 -0400
From: Bill Page
To: Tim Daly
Subject: RE: SVN on sourceforge
Cc: Gabriel Dos Reis

On Wednesday, September 13, 2006 2:52 PM you wrote:
>
> =
==========================
==========================
============
> ==== Axiom build second try
> =
==========================
==========================
============
>
> So I touched every file, did a make clean, and tried again
>
> Oddly this seems to be complaining about timestamps of
> programs that are not Axiom source code.
> ...

Ya, that is odd. What is 'gtar'? The output looks suspicious.
What kind of system is this? Maybe you could send a copy of config.sys?

Curious: Why did you touch every file?

\start
Date: Wed, 13 Sep 2006 14:16:04 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: SVN on sourceforge

On Wed, 13 Sep 2006, root wrote:

|
| ========================================================================
| ========================================================================
| ===== Building Axiom  first try ========================================
| ========================================================================
| ========================================================================
|
| This went into an infinite loop in the make due to some kind of
| timestamp problem.

| make: Warning: File `Makefile.in' has modification time 3.2e+06 s in
| the future cd . && autoconf cd /tmp/bi && /bin/sh ./config.status
| `echo /tmp/bi/ | sed -e 's|/tmp/bi/||'`Makefile config.status:
| creating Makefile make: Warning: File `Makefile.in' has modification
| time 3.2e+06 s in the future cd . && autoconf

:-((

\start
Date: Wed, 13 Sep 2006 14:17:45 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: SVN on sourceforge

On Wed, 13 Sep 2006, root wrote:

| So I touched every file, did a make clean, and tried again
|
| Oddly this seems to be complaining about timestamps of
| programs that are not Axiom source code.

I think you have some problem with your "make".
this is complaining about gmp sub-build inside GCL.

\start
Date: Wed, 13 Sep 2006 14:19:34 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: SVN on sourceforge

On Wed, 13 Sep 2006, Page, Bill wrote:

| Tim,
|
| On Wednesday, September 13, 2006 2:52 PM you wrote:
| >
| > ==============================================================
| > ==== Axiom build second try
| > ==============================================================
| >
| > So I touched every file, did a make clean, and tried again
| >
| > Oddly this seems to be complaining about timestamps of
| > programs that are not Axiom source code.
| > ...
|
| Ya, that is odd. What is 'gtar'? The output looks suspicious.
| What kind of system is this? Maybe you could send a copy of config.sys?
|
| Curious: Why did you touch every file?

Because that was the way he could bypass a timestamp problem with hys
system make and the generation of Makefile files.
I'm curious of how he got that huge difference of timestamp.

\start
Date: 13 Sep 2006 21:19:08 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: New Axiom Browser (was: build-improvements and latex)
Cc: Waldek Hebisch

Bill Page writes:

[...]

| If Axiom is not available locally, then such links should
| automatically link to a standard remote website with similar
| information. This should be possible with a little javascript
| magic.

that should be an option -- I would hate to see Axiom suddenly starts
competing with other network hungry software for access to the net.

\start
Date: Wed, 13 Sep 2006 15:26:51 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: New Axiom Browser

On September 13, 2006 3:19 PM Gaby wrote:

>
> Bill Page writes:
>
> [... concerning links from documentation and papers to Axiom]
>
> | If Axiom is not available locally, then such links should
> | automatically link to a standard remote website with similar
> | information. This should be possible with a little javascript
> | magic.
>
> that should be an option -- I would hate to see Axiom suddenly
> starts competing with other network hungry software for access
> to the net.
>

??? Perhaps you did not understand what I meant by Axiom Browser?
In what since does this involve "Axiom competing with other network
software"?

\start
Date: Wed, 13 Sep 2006 15:24:13 -0400
From: Tim Daly
To: Bill Page
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

> On Wednesday, September 13, 2006 2:52 PM you wrote:
> > 
> > ==============================================================
> > ==== Axiom build second try
> > ==============================================================
> > 
> > So I touched every file, did a make clean, and tried again
> > 
> > Oddly this seems to be complaining about timestamps of 
> > programs that are not Axiom source code.
> > ...
> 
> Ya, that is odd. What is 'gtar'? The output looks suspicious.
> What kind of system is this? Maybe you could send a copy of config.sys?

unfortunately, no. i  rm -rf * the directory so i could rebuild
from scratch and try again. next time i'll save it.



> 
> Curious: Why did you touch every file?

touch brings the time stamp up to date.
thus all of the files are pre-make ready.

\start
Date: Wed, 13 Sep 2006 15:25:20 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: SVN on sourceforge

> | So I touched every file, did a make clean, and tried again
> |
> | Oddly this seems to be complaining about timestamps of
> | programs that are not Axiom source code.
> 
> I think you have some problem with your "make".
> this is complaining about gmp sub-build inside GCL.

except for installing noweb this is a vanilla, off the install CD,
Fedora core 5 system.

\start
Date: Wed, 13 Sep 2006 15:36:20 -0400
From: Bill Page
To: Tim Daly, Gabriel Dos Reis
Subject: RE: SVN on sourceforge

Sorry, I seems I received you emails in the wrong order.
Perhaps time is warped today? Dr. Who?

On Wednesday, September 13, 2006 2:51 PM  Tim Daly wrote:
> ==========
> ===== Building Axiom  first try
> ==========
>
> This went into an infinite loop in the make due to some kind of
> timestamp problem.
>
>
> [root@dhcppc0 src]# echo $AXIOM
> ...
> [root@dhcppc0 bi]# export AXIOM=`pwd`/mnt/linux
                     ^^^^^^^^^^^^^

This is not necessary.

> [root@dhcppc0 bi]# ./configure
> checking build system type... i686-pc-linux
> checking host system type... i686-pc-linux
> checking target system type... i686-pc-linux
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ANSI C... none needed
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether ln -s works... yes
> checking for gawk... gawk
> checking for gtar... gtar

How is the g... stuff suppoed to work? All of my systems
have just 'tar' and 'awk'.

> ...
> [root@dhcppc0 bi]# make
> make: Warning: File `Makefile.in' has modification time
> 3.2e+06 s in the future
> ...

Far out.

\start
Date: Wed, 13 Sep 2006 21:48:52 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: New Axiom Browser (was: build-improvements	and latex)

On 09/13/2006 09:19 PM, Gabriel Dos Reis wrote:
> Bill Page writes:
> 
> [...]
> 
> | If Axiom is not available locally, then such links should
> | automatically link to a standard remote website with similar
> | information. This should be possible with a little javascript
> | magic.
> 
> that should be an option -- I would hate to see Axiom suddenly starts
> competing with other network hungry software for access to the net.

Gaby, I don't understand. If you have a documentation of Axiom and click 
on a like then you should get somewhere or the link should not show at 
all. I would prefer a local documentation ie, the link goes to some 
local html, but if that cannot be found the link should either directly 
  link to some resources on the net or at least link to some footnote 
that tells you the appropriate URL.

\start
Date: Wed, 13 Sep 2006 15:50:35 -0400
From: Bill Page
To: Tim Daly, Gabriel Dos Reis
Subject: RE: SVN on sourceforge

On Wednesday, September 13, 2006 3:25 PM  Tim Daly wrote:

> ...
> except for installing noweb this is a vanilla, off the
> install CD, Fedora core 5 system.
>

Scary.

Does subversion come with the install?

The timestamps on the files in the Axiom distribution seem
to be corrupted. I have not seen this before. Could this
be related to your earlier SourceForge access problems?

Have you tried just to build GCL stand alone?

\start
Date: Wed, 13 Sep 2006 14:52:29 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: SVN on sourceforge

On Wed, 13 Sep 2006, Page, Bill wrote:

| > [root@dhcppc0 bi]# ./configure
| > checking build system type... i686-pc-linux
| > checking host system type... i686-pc-linux
| > checking target system type... i686-pc-linux
| > checking for gcc... gcc
| > checking for C compiler default output file name... a.out
| > checking whether the C compiler works... yes
| > checking whether we are cross compiling... no
| > checking for suffix of executables...
| > checking for suffix of object files... o
| > checking whether we are using the GNU C compiler... yes
| > checking whether gcc accepts -g... yes
| > checking for gcc option to accept ANSI C... none needed
| > checking for a BSD-compatible install... /usr/bin/install -c
| > checking whether ln -s works... yes
| > checking for gawk... gawk
| > checking for gtar... gtar
|
| How is the g... stuff suppoed to work? All of my systems
| have just 'tar' and 'awk'.

Some systems have gtar, some don't.  Just like some have gawk instead
of awk (or nawk, or...).  The differences should not matter for our
purpose -- and if they do, then we have a bug.

\start
Date: Wed, 13 Sep 2006 16:02:34 -0400
From: Bill Page
To: Gabriel Dos Reis,
Subject: RE: SVN on sourceforge

On Wednesday, September 13, 2006 3:15 PM Gabriel Dos Reis
>
> On Wed, 13 Sep 2006, Tim Daly wrote:
>
> | The make all install failed to terminate, looping
> | infintely deeper.

I have never had this problem building noweb.

Perhaps this is another symptom of some kind of
misconfiguration of the gnu toolchain on your system?

Have you built any other packages from source successfully?

>
> Now that you mention it, I do remain that I ran into the
> same issue and finally solved it.
>
> There is something to be said for non-standard build
> systems :-)
>

Er, it wouldn't be polite to repeat it here! ;)

\start
Date: 13 Sep 2006 22:00:47 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: New Axiom Browser

Bill Page writes:

| On September 13, 2006 3:19 PM Gaby wrote:
| 
| > 
| > Bill Page writes:
| > 
| > [... concerning links from documentation and papers to Axiom]
| > 
| > | If Axiom is not available locally, then such links should
| > | automatically link to a standard remote website with similar
| > | information. This should be possible with a little javascript
| > | magic.
| > 
| > that should be an option -- I would hate to see Axiom suddenly
| > starts competing with other network hungry software for access
| > to the net.
| > 
| 
| ??? Perhaps you did not understand what I meant by Axiom Browser?

in that case, you might to elaborate to communicate your suggestion.

| In what since does this involve "Axiom competing with other network
| software"?

I don't know.

What I meant is I would hate to have Axiom starts competing with other
software to gain access to the net.  I did not say competing with
network software -- most of them are not.

\start
Date: 13 Sep 2006 22:07:02 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: New Axiom Browser (was: build-improvements and latex)

Ralf Hemmecke writes:

| On 09/13/2006 09:19 PM, Gabriel Dos Reis wrote:
| > Bill Page writes:
| > [...]
| > | If Axiom is not available locally, then such links should
| > | automatically link to a standard remote website with similar
| > | information. This should be possible with a little javascript
| > | magic.
| > that should be an option -- I would hate to see Axiom suddenly starts
| > competing with other network hungry software for access to the net.
| 
| Gaby, I don't understand. If you have a documentation of Axiom and
| click on a like then you should get somewhere or the link should not
| show at all. I would prefer a local documentation ie, the link goes to
| some local html, but if that cannot be found the link should either
| directly link to some resources on the net or at least link to some
| footnote that tells you the appropriate URL.

What I was saying is that I would like to have that as an option --
i.e. if the documentation is not locally available, I would prefer to
be given the opportunity to chose whether Axiom should contact the
world or just say "sorry, documentation missing".

\start
Date: Wed, 13 Sep 2006 16:02:41 -0400
From: Tim Daly
To: Bill Page
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

> > | The make all install failed to terminate, looping
> > | infintely deeper.
> 
> I have never had this problem building noweb.
> 
> Perhaps this is another symptom of some kind of
> misconfiguration of the gnu toolchain on your system?
> 
> Have you built any other packages from source successfully?

this is a clean fedora core 5 install.
fedora core 5 changed a lot of things.
i had to make a special case in the axiom gold build.

\start
Date: Wed, 13 Sep 2006 15:15:43 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: SVN on sourceforge

On Wed, 13 Sep 2006, root wrote:

| > > | The make all install failed to terminate, looping
| > > | infintely deeper.
| >
| > I have never had this problem building noweb.
| >
| > Perhaps this is another symptom of some kind of
| > misconfiguration of the gnu toolchain on your system?
| >
| > Have you built any other packages from source successfully?
|
| this is a clean fedora core 5 install.
| fedora core 5 changed a lot of things.
| i had to make a special case in the axiom gold build.

It looks so.  I'd like to work on this further with you.

Unfortunately, I have a lecture in less than an hour and I have slides
to prepare for tomorrow.  It is almost unlikely that I have anything
done for Axiom tonight :-(

\start
Date: Wed, 13 Sep 2006 22:17:16 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: New Axiom Browser (was: build-improvements	and latex)

> | Gaby, I don't understand. If you have a documentation of Axiom and
> | click on a like then you should get somewhere or the link should not
> | show at all. I would prefer a local documentation ie, the link goes to
> | some local html, but if that cannot be found the link should either
> | directly link to some resources on the net or at least link to some
> | footnote that tells you the appropriate URL.
> 
> What I was saying is that I would like to have that as an option --
> i.e. if the documentation is not locally available, I would prefer to
> be given the opportunity to chose whether Axiom should contact the
> world or just say "sorry, documentation missing".

What I was saying, that I want a more or less thumb html page maybe with 
a few javascript items that are there to help showing what you want.
But there should be just links and the user has to CLICK to get some 
more documentation. Nothing tries to get other documentation 
automatically. I think you would favour that, right?

I guess, Bill meant nothing else with

| > | If Axiom is not available locally, then such links should
| > | automatically link to a standard remote website with similar
| > | information.

\start
Date: Wed, 13 Sep 2006 16:27:18 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: New Axiom Browser (was: build-improvements andlatex)

On Wednesday, September 13, 2006 4:17 PM you wrote:
> ...
> What I was saying, that I want a more or less dumb html page
> maybe with a few javascript items that are there to help showing
> what you want. But there should be just links and the user has
> to CLICK to get some more documentation. Nothing tries to get
> other documentation automatically. I think you would favour that,
> right?
>
> I guess, Bill meant nothing else with
>
> | > | If Axiom is not available locally, then such links should
> | > | automatically link to a standard remote website with similar
> | > | information.
>

Exactly. I did not realize that what I wrote was so ambiguous.
Thanks for the clarification.

\start
Date: Wed, 13 Sep 2006 18:10:25 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: build.improvements 'make clean'

Here is just a quick patch to make sure that all the
'stamp-*' directories are deleted in the case of
'make clean'.

--------

-sh-3.00$ diff -au Makefile.pamphlet_orig Makefile.pamphlet
--- Makefile.pamphlet_orig      2006-09-13 18:03:28.000000000 -0400
+++ Makefile.pamphlet   2006-09-13 18:06:58.000000000 -0400
@@ -94,7 +94,7 @@
        @ rm -rf int
        @ rm -rf obj
        @ rm -rf mnt
-       @ rm -f stamp-*
+       @ rm -f `find . -name 'stamp*'`
        @ for i in `find . -name "*~"` ; do rm -f $$i ; done
        @ for i in `find src -name "Makefile.dvi"` ; do rm -f $$i ; done

-sh-3.00$

\start
Date: Wed, 13 Sep 2006 18:18:44 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Doyen and Sage (was: [SAGEsupport] SAGE)
Cc: Enrique Acosta

I saw few emails regarding adding Sage to the Doyen CD.

Would you want me to add it now or wait until a possible
support for Axiom inside Sage.

I could have a CD only with Sage for now.

Also, should add your work on LatexWiki to support Sage
to the Doyen CD?

\start
Date: 14 Sep 2006 00:16:57 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: New Axiom Browser (was: build-improvements and latex)

| > | Gaby, I don't understand. If you have a documentation of Axiom and
| > | click on a like then you should get somewhere or the link should not
| > | show at all. I would prefer a local documentation ie, the link goes to
| > | some local html, but if that cannot be found the link should either
| > | directly link to some resources on the net or at least link to some
| > | footnote that tells you the appropriate URL.
| > What I was saying is that I would like to have that as an option --
| > i.e. if the documentation is not locally available, I would prefer to
| > be given the opportunity to chose whether Axiom should contact the
| > world or just say "sorry, documentation missing".
| 
| What I was saying, that I want a more or less thumb html page maybe
| with a few javascript items that are there to help showing what you
| want.
| But there should be just links and the user has to CLICK to get some
| more documentation. Nothing tries to get other documentation
| automatically. I think you would favour that, right?

Yes.  Thanks!

\start
Date: Wed, 13 Sep 2006 18:27:42 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Doyen and Sage
Cc: William Stein, Enrique Acosta

On Wednesday, September 13, 2006 6:19 PM Alfredo Portes writes:

> I saw few emails regarding adding Sage to the Doyen CD.
>
> Would you want me to add it now or wait until a possible
> support for Axiom inside Sage.

I don't think it is necessary to wait for that. I may be a
few more months away.

But both Axiom and Sage (about 300MB) are quite large. Do
you think they would both fit + DoyenWiki and Magnus on the
same CD?

> I could have a CD only with Sage for now.
>
> Also, should add your work on LatexWiki to support Sage
> to the Doyen CD?

Yes, I think having the LatexWiki support for Sage on the
CD would be very desirable. (That reminds me that I promised
to get those changes into the MathAction darcs repository...
I haven't done that yet.)

\start
Date: Wed, 13 Sep 2006 20:03:11 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Doyen and Sage
Cc: William Stein, Enrique Acosta

I don't think it is necessary to wait for that. I may be a
> few more months away.


  Ok.  If there is anything I can do to help please let me know.

But both Axiom and Sage (about 300MB) are quite large. Do
> you think they would both fit + DoyenWiki and Magnus on the
> same CD?


  Yeah it is okay, keep it comming :-) . I created an image of Doyen
   with Sage:

   http://alfredo.axiom-developer.org/DoyenSage.iso

   I exhort to try it and let me know if anything is missing. I put a
   Sage icon on the Doyen menu. The Sage notebook should be
   functional also.

   To take for a spin using vmware:

    http://alfredo.axiom-developer.org/DoyenVmware.tar.gz

Yes, I think having the LatexWiki support for Sage on the
> CD would be very desirable. (That reminds me that I promised
> to get those changes into the MathAction darcs repository...
> I haven't done that yet.)


    Just let me know to add it to the CD and make it an official
    release in MathAction.

\start
Date: Wed, 13 Sep 2006 21:29:28 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build.improvements 'make clean'

On Wed, 13 Sep 2006, Page, Bill wrote:

| Gaby,
|
| Here is just a quick patch to make sure that all the
| 'stamp-*' directories are deleted in the case of
| 'make clean'.

Thanks.  This is queued.

\start
Date: Wed, 13 Sep 2006 23:47:36 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Doyen and Sage
Cc: William Stein, Enrique Acosta

Alfredo,

On Wednesday, September 13, 2006 8:03 PM you wrote:

> ...
> I created an image of Doyen with Sage:
=09
   http://alfredo.axiom-developer.org/DoyenSage.iso
=09
> I exhort to try it and let me know if anything is missing.

Man. You're good! :-)

I downloaded it, burned the CD and popped it into my desktop,
rebooted and there it was. Very easy. I think it boots more
quickly than Knoppix.

> I put a Sage icon on the Doyen menu.

Did I miss it? I didn't see the Sage icon.

But I had no problem running Sage from a terminal window.

> The Sage notebook should be functional also.

Yes it is. Works great. Maybe there should be a specific
icon for that too that just starts NoteBook and runs the
browser in one click.
=09
> To take for a spin using vmware:
>
>  http://alfredo.axiom-developer.org/DoyenVmware.tar.gz
>

I have a lot of trouble running VMware on this old office
desktop. But it runs fine on a much larger machine at home
that I use for my real work... :) I'll let you know later.=09

>> Yes, I think having the LatexWiki support for Sage on the
>> CD would be very desirable. (That reminds me that I promised
>> to get those changes into the MathAction darcs repository...
>> I haven't done that yet.)
>
> Just let me know to add it to the CD and make it an official
> release in MathAction.

Expect the update to the repository in a couple of days.

BTW, I really like the new content in the DoyenWiki. We can
also add a few pages about Sage. There is an 'AboutSage' page
on MathAction that we can cut-up and paste.

Regards,
Bill Page.

PS. We should get a copy of the DoyenCD into BitTorrent soon.
And into the Axiom Tutorial book.

Tim, since you "own" the Axiom book on Lulu can you look into how
to do this? Of course I can arrange to publish it as a separate
item and I will also add it to the CafePress Axiom Gear - but
you know, I am disappointed by how little "gear" actually gets
ordered :(  I like my Axiom mug and my Axiom baseball cap! :)

\start
Date: Wed, 13 Sep 2006 23:56:27 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Aldor and Axiom (was: SVN on sourceforge)

On Wednesday, September 13, 2006 11:46 PM Cliff Yapp wrote:

> ...
> [no Aldor open source license]
> This of course does not mean that we cannot learn from and
> use the ideas in Aldor - merely that we must take our SPAD
> beginnings and build them up into something better.
>
> If we must do this, I would like to see some thought put into
> designing and defining SPAD+ or whatever with an eye towards
> formal proving systems and automatic proof generation.
> ...

I think that this is so far past our current skill level and
the available resources that there is virtually no chance that
this will ever be anything but a paper exercise.

If we have to live without Aldor then I think we would be much
better off looking at possibilities such as how to make Ocaml or
Haskell work with Axiom. Ocaml at least is heavily used in proof
systems and has a syntax and object model not too different
from SPAD and Aldor.

\start
Date: Wed, 13 Sep 2006 20:57:45 -0700
From: William Stein
To: Bill Page, Alfredo Portes
Subject: Re: Doyen and Sage
Cc: Enrique Acosta

On Wed, 13 Sep 2006 20:47:36 -0700, Page, Bill Bill Page  
wrote:
>> I created an image of Doyen with Sage:
> 	
>    http://alfredo.axiom-developer.org/DoyenSage.iso
> 	
>> I exhort to try it and let me know if anything is missing.
>
> Man. You're good! :-)

Indeed!

>> I put a Sage icon on the Doyen menu.
>
> Did I miss it? I didn't see the Sage icon.
>
> But I had no problem running Sage from a terminal window.
>
>> The Sage notebook should be functional also.
>
> Yes it is. Works great. Maybe there should be a specific
> icon for that too that just starts NoteBook and runs the
> browser in one click.

Fortunately you can do all that with the following command line.
So just make an icon that does the following:

     sage -notebook sage_notebook 8000 localhost True

It'll make a directory sage_notebook in whatever directory that
command is run in, start the SAGE server, and launch the default
web browser with the notebook loaded.

>>> Yes, I think having the LatexWiki support for Sage on the
>>> CD would be very desirable. (That reminds me that I promised
>>> to get those changes into the MathAction darcs repository...
>>> I haven't done that yet.)
>>
>> Just let me know to add it to the CD and make it an official
>> release in MathAction.
>
> Expect the update to the repository in a couple of days.
>
> BTW, I really like the new content in the DoyenWiki. We can
> also add a few pages about Sage. There is an 'AboutSage' page
> on MathAction that we can cut-up and paste.

You're doing so much for SAGE -- I really need to get the SAGE<-->Axiom
interface going soon.

\start
Date: Thu, 14 Sep 2006 01:05:05 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Doyen and Sage

  Bill,

Man. You're good! :-)


  I have learned more from you and Tim than in many of my CS classes.
  I wish I could contribute more regarding source code...some day.

Did I miss it? I didn't see the Sage icon.


  Applications -> Doyen -> Sage

Expect the update to the repository in a couple of days.


  Ok.

BTW, I really like the new content in the DoyenWiki.


  Ah, that was the easy part, just needed to copy your work :-).


> We can also add a few pages about Sage. There is an 'AboutSage' page
> on MathAction that we can cut-up and paste.


  Ok.

Tim, since you "own" the Axiom book on Lulu can you look into how
> to do this? Of course I can arrange to publish it as a separate
> item and I will also add it to the CafePress Axiom Gear - but
> you know, I am disappointed by how little "gear" actually gets
> ordered :(  I like my Axiom mug and my Axiom baseball cap! :)


  I think this is a very good idea.

\start
Date: Thu, 14 Sep 2006 09:39:20 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [SilverBinaries] (new) Help test Axiom Silver

Nice that you have opened up that site.

http://wiki.axiom-developer.org/SilverBinaries

However, I think we should stick to some naming convention otherwise 
people (not me anymore) get confused.

What we have is like Debian.

Gold = stable
Silver = unstable
Bronze = testing

You promote the build-improvements branch which is clearly in the 
testing phase, so it should NOT be called Silver.

It seems that we are all quite lazy and confuse the sourceforge 
repository with Silver. That should not be done.

Only

svn co https://svn.sourceforge.net/svnroot/axiom/trunk SilverAxiom

Should be called "Silver". It is actually correctly stated at

http://wiki.axiom-developer.org/AxiomSources

but maybe, I should add "Bronze" to the testing heading?

Anybody against that distiction? If no then SilverBinaries should be 
called BronzeBinaries and it should give the complete URL to download 
the sources, or there should be a link to the 
http://wiki.axiom-developer.org/AxiomSources
page.

\start
Date: Thu, 14 Sep 2006 09:46:21 +0200
From: Ralf Hemmecke
To: Alfredo Portes
Subject: re: Doyen and Sage

Hi Alfredo,

I strongly believe that you should put your name onto

http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers

Or send me some data and I'll do it.

Your work on Doyen and Sage is important for Axiom. Thanks.

\start
Date: Thu, 14 Sep 2006 10:55:00 +0200
From: Ralf Hemmecke
To: list
Subject: [Fwd: Your message to Axiom-commit awaits moderator approval]

Hello,

I give up.

I've removed the svn:keywords from all files and svn:eol-style from 
selected files. Of course that involved nearly ALL files of Silver, but 
after the commit went on for more than 45 min (!!! That looks like whole 
files have been transmitted, although I have only changed properties.), 
it tells me the following.

[snip]
Sending        axiom/zips/noweb.src.Makefile.patch
Sending        axiom/zips/tla-1.1.tar.gz
Sending        axiom/zips/vmlisp.lisp.pamphlet.patch
Transmitting file data .svn: Commit failed (details follow):
svn: MERGE request failed on '/svnroot/axiom/trunk/axiom'
svn: MERGE of '/svnroot/axiom/trunk/axiom': 500 Internal Server Error 
(https://svn.sourceforge.net)

 From what I see, all files were sent to sourceforge, but as you can 
read from the attached mail, the commit was not completed because the 
log is too big. Nothing tells me that, if the list moderator (whoever 
this is) accepts the post that then also the commit succeeds.

I am simply frustrated by this. Why should I split a commit only because 
of limitations of the tools?

\start
Date: Thu, 14 Sep 2006 01:40:31 -0700
From: axiom-commit-bounces@lists.sourceforge.net
To: Ralf Hemmecke
Subject: Your message to Axiom-commit awaits moderator approval

Your mail to 'Axiom-commit' with the subject

    SF.net SVN: axiom: [136] trunk/axiom

Is being held until the list moderator can review it for approval.

The reason it is being held:

    Message body is too big: 255284 bytes with a limit of 200 KB

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:

\start
Date: Thu, 14 Sep 2006 12:02:27 +0200
From: Ralf Hemmecke
To: Ralf Hemmecke
Subject: Re: [Fwd: Your message to Axiom-commit awaits moderator approval]

You remember ... I've just sent...

> [snip]
> Sending        axiom/zips/noweb.src.Makefile.patch
> Sending        axiom/zips/tla-1.1.tar.gz
> Sending        axiom/zips/vmlisp.lisp.pamphlet.patch
> Transmitting file data .svn: Commit failed (details follow):
> svn: MERGE request failed on '/svnroot/axiom/trunk/axiom'
> svn: MERGE of '/svnroot/axiom/trunk/axiom': 500 Internal Server Error 
> (https://svn.sourceforge.net)

It clearly says "commit failed". But hey, try "svn update" in the trunk 
and you'll see that the commit succeeded.

If that is not strange...

I'll continue to copy the --patch-50 files to silver and try to correct 
the corrupted binaries.

\start
Date: 14 Sep 2006 12:40:18 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: [SilverBinaries] (new) Help test Axiom Silver

Ralf Hemmecke writes:

| Hi Bill,
| 
| Nice that you have opened up that site.

same here!

| 
| http://wiki.axiom-developer.org/SilverBinaries
| 
| However, I think we should stick to some naming convention otherwise
| people (not me anymore) get confused.
| 
| What we have is like Debian.
| 
| Gold = stable
| Silver = unstable
| Bronze = testing

many of my students were scared by the name "unstable" and did not
want to touch it.  I don't think they are unique in that respect.

I know that for GCC, for example, we call mainline, "experimental" -- not
"unstable".  Personally, I would prefer to reserve the "negative"
sounding "unstable" to branches like "build-improvements" -- which
really can be very unstable :-)

| You promote the build-improvements branch which is clearly in the
| testing phase, so it should NOT be called Silver.

\start
Date: 14 Sep 2006 12:45:02 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [Fwd: Your message to Axiom-commit awaits	moderator approval]

Ralf Hemmecke writes:

| Hello,
| 
| I give up.
| 
| I've removed the svn:keywords from all files and svn:eol-style from
| selected files. Of course that involved nearly ALL files of Silver,
| but after the commit went on for more than 45 min (!!! That looks like
| whole files have been transmitted, although I have only changed
| properties.), it tells me the following.
| 
| [snip]
| Sending        axiom/zips/noweb.src.Makefile.patch
| Sending        axiom/zips/tla-1.1.tar.gz
| Sending        axiom/zips/vmlisp.lisp.pamphlet.patch
| Transmitting file data .svn: Commit failed (details follow):
| svn: MERGE request failed on '/svnroot/axiom/trunk/axiom'
| svn: MERGE of '/svnroot/axiom/trunk/axiom': 500 Internal Server Error
| (https://svn.sourceforge.net)

I've begun to be more and mroe convinced that SF SVN server is not
good for work.  Tim preferred to blame SVN -- but realy, it is a
problem with SF server.  I've seen and done much larger commit with
GCC with svn. 

[...]

| The reason it is being held:
| 
|     Message body is too big: 255284 bytes with a limit of 200 KB
| 

Give me a break.

I noticed that the server can also truncate commit diffs -- which makes
the whole idea very useful :-(

\start
Date: Thu, 14 Sep 2006 06:38:40 -0400
From: Tim Daly
To: Bill Page, Alfredo Portes
Subject: Re: Doyen and Sage
Cc: William Stein, Enrique Acosta

Alfredo,
> 
> On Wednesday, September 13, 2006 8:03 PM you wrote:
> 
> > ...
> > I created an image of Doyen with Sage:
> 	
>    http://alfredo.axiom-developer.org/DoyenSage.iso
> 	
> > I exhort to try it and let me know if anything is missing.
> 

Excellent work. You're really adding value to the project.
Your name is now on the credits list and will show
up as of patch-51, the next release.

To see it start axiom and type
  )credits


Btw, if anyone notices a name missing please send me a note.
I've made a great effort to collect the names of people who
have helped make Axiom what it is.

\start
Date: Thu, 14 Sep 2006 12:53:20 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: SVN on sourceforge
Cc: Gabriel Dos Reis

Hi,

>>  >>3) Checkout a fresh copy of silver/trunk.
>>  >>4) Copy all source files from --patch-50 to silver/trunk.
>>  >>5) Commit the change.
>>  >>   My wild guess is that svn only commits the files that actually
>>  >>   differ from the repository. I hope that svn does not take the
>>  >>   copy date into account.

I have just done...

cd $Gold
find . -type f ! -regex '.*\.arch-ids.*' ! -regex '.*{arch}.*' \
      ! -regex '.*\.patch' ! -exec cmp {} $Silver/trunk/axiom/{} ';' \
      -exec cp {} $Silver/trunk/axiom/{} ';'
cd $Silver/trunk
svn commit

Committed revision 137.

As you see, I have left out the .patch files, since they appeared to be 
without the strange \r\n endings in the SVN repository.

Could someone check whether a windows checkout of Gold and Silver 
agrees. (Maybe it does not, since I haven't deleted all the 
svn:eol-style properties.) The binaries should be correct, however, 
under Windows and Linux.

Still to do...

Remove the binary property from the .pamphlet files. I did not do it 
since the binary bit is set for those files in my Gold checkout and I 
wanted SF/trunk to be in sync with Gold (up to this patches-49-50 
directory).

Any suggestions what to do here? Binary bits should be removed in 
Gold-to-be and Silver at the same time.

Maybe ... remove the svn:eol-style property from ALL files? BTW, what is 
tla doing with respect to text files?
And can sourceforge prevent people from committing textfiles that 
contain \r\n?

\start
Date: Thu, 14 Sep 2006 06:46:26 -0400
From: Tim Daly
To: Bill Page, Alfredo Portes
Subject: Re: Doyen and Sage
Cc: William Stein, Enrique Acosta

On a different note, both to Bill and Jose,

It is important that we document everything we do in a way that
others can easily reproduce our work. Jose, I know you've heard
this song many times so I'll just sing the first verse.

Bill, I think it is important that we keep the doyen build
documentation up to date with all of the latest changes, specifically
how to add the wiki and the sage information. The pdf at
http://wiki.axiom-developer.org/images/DoyenDocs.pdf
is, in some sense, more valuable than the CD itself because it
makes it possible for people to reproduce the work.

Can the two of you work on bringing the docs up to speed
with the Doyen CD distribution?

Are the how-to build docs on the Doyen CD?

\start
Date: Thu, 14 Sep 2006 12:58:25 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [Fwd: Your message to Axiom-commit awaits	moderator approval]

> | The reason it is being held:
> | 
> |     Message body is too big: 255284 bytes with a limit of 200 KB
> | 
> 
> Give me a break.
> 
> I noticed that the server can also truncate commit diffs -- which makes
> the whole idea very useful :-(

Should I understand that?

Anyway, only the message is confusing. I sometimes tend not to believe 
what the error message is telling me. So I continued and succeeded.
Silver is now more or less in sync with patch-50. Corrupted binaries 
corrected.

\start
Date: Thu, 14 Sep 2006 13:06:05 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: [SilverBinaries] (new) Help test Axiom Silver

> | What we have is like Debian.
> | 
> | Gold = stable
> | Silver = unstable
> | Bronze = testing
> 
> many of my students were scared by the name "unstable" and did not
> want to touch it.  I don't think they are unique in that respect.
> 
> I know that for GCC, for example, we call mainline, "experimental" -- not
> "unstable".  Personally, I would prefer to reserve the "negative"
> sounding "unstable" to branches like "build-improvements" -- which
> really can be very unstable :-)

I just wanted to follow the naming conventions of a big project like 
Debian. I quite believe that people who use Debian unstable all well 
aware that things could break. Anyway "unstable" does not have such a 
bad conotation for Debian. Am I wrong?

If we call Silver = experimental that is not very different from 
"testing". If you can come up with anthing better, you're welcome.

A suggestion could even be... drop "stable", "unstable", "testing" and 
just call the branches Gold, Silver, Bronze with a definition of what 
they are and the understanding that there is just ONE Gold and ONE 
Silver but many Bronze branches.

\start
Date: Thu, 14 Sep 2006 06:59:06 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Doyen and Sage
Cc: William Stein, Enrique Acosta

> Tim, since you "own" the Axiom book on Lulu can you look into how
> to do this? Of course I can arrange to publish it as a separate
> item and I will also add it to the CafePress Axiom Gear - but
> you know, I am disappointed by how little "gear" actually gets
> ordered :(  I like my Axiom mug and my Axiom baseball cap! :)

Unfortunately the Tutorial book cannot be changed without releasing
a whole new version.

The choice was to release the book with or without an ISBN.
This choice has implications.

An ISBN book can only have minor typo-style edits.
An ISBN book can be ordered by universities, book stores, etc.
An ISBN book can be picked up by B&N, Amazon, etc.
An ISBN costs money to register ($140)

A non-ISBN book can be changed at any time
A non-ISBN book cannot be purchase-ordered (eliminates most univs)
A non-ISBN book cannot be picked up by B&N, Amazon, etc.
A non-ISBN book is free

So I decided that the cost, which allowed much wider distribution,
was worth the restriction that it could not be changed without
producing a whole new version. Perhaps we can consider doing that
over the christmas holidays (when I get a larger block of time to
work on axiom)

Of course, we have no restriction on the version in the Axiom
source tree. 

Since you're advocating the change, you're volunteering, right? :-) :-)
(Heck, if you want you can even put YOUR name on the cover instead
of mine)

\start
Date: Thu, 14 Sep 2006 07:58:19 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: Doyen and Sage

 Tim,

Can the two of you work on bringing the docs up to speed
> with the Doyen CD distribution?


  The latest work to add Sage is not in the docs yet. However,
  the current docs should allow anybody to reproduce the
  latest CD. Of course the docs can always be improved.
  I will revise the documentation.

Are the how-to build docs on the Doyen CD?


 Yes they are.  Not that visible now...quick fix.

\start
Date: 14 Sep 2006 14:19:30 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: [SilverBinaries] (new) Help test Axiom Silver

Ralf Hemmecke writes:

| > | What we have is like Debian.
| > | | Gold = stable
| > | Silver = unstable
| > | Bronze = testing
| > many of my students were scared by the name "unstable" and did not
| > want to touch it.  I don't think they are unique in that respect.
| > I know that for GCC, for example, we call mainline, "experimental"
| > -- not
| > "unstable".  Personally, I would prefer to reserve the "negative"
| > sounding "unstable" to branches like "build-improvements" -- which
| > really can be very unstable :-)
| 
| I just wanted to follow the naming conventions of a big project like
| Debian.

Yes, I know debian uses that word.  And it also has the reputation for
"being for the though guys" -- whether that is justified or not.

But, with people I've talked to (not just here, but before I even
consider going to the US) "unstable" does not come with good
prejudice.  We have to think about it.  Like I said, I much prefer
"experimental" to "unstable".  I would prefer to reserve "unstable"
for much more experimental work than silver.

| I quite believe that people who use Debian unstable all well
| aware that things could break.

I don't dispute that -- just like people using "experimental" knows
things might break.  They have very different "implied connotations".

| Anyway "unstable" does not have such a
| bad conotation for Debian. Am I wrong?

As I said, Debian is known -- rightly or wrongly -- to be for the
"though guys".  I don't want Axiom to be for the tough guys.

| If we call Silver = experimental that is not very different from
| "testing". If you can come up with anthing better, you're welcome.

It definitely is.  I really would like to not call the
build-improvements branch "testing".  
I do believe that "unstable" for silver is not doing it justice. 

| A suggestion could even be... drop "stable", "unstable", "testing" and
| just call the branches Gold, Silver, Bronze with a definition of what
| they are and the understanding that there is just ONE Gold and ONE
| Silver but many Bronze branches.

That is one way of doing it.  As long as we reserve "unstable" for far
worse situations.

\start
Date: 14 Sep 2006 14:22:17 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [Fwd: Your message to Axiom-commit awaits	moderator approval]

Ralf Hemmecke writes:

| > | The reason it is being held:
| > | |     Message body is too big: 255284 bytes with a limit of 200 KB
| > | Give me a break.
| > I noticed that the server can also truncate commit diffs -- which
| > makes
| > the whole idea very useful :-(
| 
| Should I understand that?

what I'm saying is that I see axiom-commits as telling me what are the
diffs between two successive revisions.  If the diffs sent to the
mailing list (not the real thing committed) are truncated, that is not
very helpful.   

[...]

| Silver is now more or less in sync with patch-50.

\start
Date: Thu, 14 Sep 2006 05:27:19 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Aldor and Axiom (was: SVN on sourceforge)

--- Bill Page wrote:

> On Wednesday, September 13, 2006 11:46 PM Cliff Yapp wrote:
> 
> > ...
> > [no Aldor open source license] 
> > This of course does not mean that we cannot learn from and
> > use the ideas in Aldor - merely that we must take our SPAD 
> > beginnings and build them up into something better.
> > 
> > If we must do this, I would like to see some thought put into 
> > designing and defining SPAD+ or whatever with an eye towards 
> > formal proving systems and automatic proof generation.
> > ...
> 
> I think that this is so far past our current skill level and
> the available resources that there is virtually no chance that
> this will ever be anything but a paper exercise.

I suppose so.  I was wondering if perhaps academic interest in such a
project might be generated - there are a number of teams around the
world working on related tasks.
 
> If we have to live without Aldor then I think we would be much
> better off looking at possibilities such as how to make Ocaml or
> Haskell work with Axiom. Ocaml at least is heavily used in proof
> systems and has a syntax and object model not too different
> from SPAD and Aldor.

Yes, Ocaml would make the possible heavy use of COQ a very interesting
possibility.  My biggest reservation is that the Ocaml compiler is
licensed under the Q public license with some exceptions, but I guess
that's a lot better than not having it available at all.

Haskell seems to have ghc, which looks to be licensed pretty much like
Axiom itself, but the juicy COQ incentive isn't there.  There's
something called Yarrow but it doesn't seem to be as "big time" as coq.

Anybody have experience with these languages?

\start
Date: 14 Sep 2006 14:40:00 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: Aldor and Axiom

I believe that we should *not* embark on designing yet another language. I
played enough with Aldor meanwhile to really appreciate the language - with
it's deficiencies.

Those of you inclined on working on the language:

PLEASE get started understanding the interpreter and possibly extend it to at
least understand dependent types, and/or make types first class objects.

Axiom would benefit a lot - no matter whether Aldor becomes free or not. This
is the one thing we need in any case!

If you prefer to rewrite the interpreter in a different language, go ahead. But
please don't design yet another one!

\start
Date: 14 Sep 2006 14:58:48 +0200
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Aldor and Axiom

Martin Rubey writes:

| Dear all,
| 
| I believe that we should *not* embark on designing yet another language. I
| played enough with Aldor meanwhile to really appreciate the language - with
| it's deficiencies.
| 
| Those of you inclined on working on the language:
| 
| PLEASE get started understanding the interpreter and possibly extend it to at
| least understand dependent types, and/or make types first class objects.

I tend to agree with Martin.  We should focus on either SPAD (make it
better) or Aldor (hopeless).

\start
Date: Thu, 14 Sep 2006 15:07:25 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Aldor and Axiom

> We should focus on either SPAD (make it better) or Aldor (hopeless).

Gaby, you should have replaced 'better' by 'Aldor' (language). ;-)

\start
Date: Thu, 14 Sep 2006 09:19:22 -0400
From: Tim Daly
To: list
Subject: conferene call

I work remotely. Once a week we have conference calls where we all
dial into a certain phone number and enter a pass code. 

It seems like this might be a reasonable thing to do with Axiom
because a lot can be resolved quickly over the phone.

Would this be a reasonable thing for Axiom?
Does anyone know of a place that provides this service?
Any idea of the costs involved?

\start
Date: Thu, 14 Sep 2006 15:46:00 +0200
From: Kai Kaminski
To: Tim Daly
Subject: Re: conferene call

> I work remotely. Once a week we have conference calls where we all
> dial into a certain phone number and enter a pass code. 
>
> It seems like this might be a reasonable thing to do with Axiom
> because a lot can be resolved quickly over the phone.
>
> Would this be a reasonable thing for Axiom?
> Does anyone know of a place that provides this service?
> Any idea of the costs involved?
As far as I understand Skype offers conference calls. That would be
free and Skype is available on Windows, Linux and Macs. Installation
(on a Mac at least) is trivial.

See www.skype.com.

\start
Date: Thu, 14 Sep 2006 16:02:46 +0200
From: Kai Kaminski
To: Tim Daly
Subject: Re: conferene call

Kai Kaminski writes:

> Tim Daly writes:
>
>> I work remotely. Once a week we have conference calls where we all
>> dial into a certain phone number and enter a pass code. 
>>
>> It seems like this might be a reasonable thing to do with Axiom
>> because a lot can be resolved quickly over the phone.
>>
>> Would this be a reasonable thing for Axiom?
>> Does anyone know of a place that provides this service?
>> Any idea of the costs involved?
> As far as I understand Skype offers conference calls. That would be
> free and Skype is available on Windows, Linux and Macs. Installation
> (on a Mac at least) is trivial.
>
> See www.skype.com.
If you'd like to try it out before committing to it, feel free to call me
(magicmuffinman).

I believe that in conference calls the host should be the one with the
biggest pipe, btw, since all communication goes over his machine.

\start
Date: Thu, 14 Sep 2006 16:06:37 +0200
From: Kai Kaminski
To: Tim Daly
Subject: Re: conferene call

[Skype for conference calls]

Another interesting feature is that people can participate with
regular phones as well (you need to on the order of 30 Euro/year,
though).

Skype also supports text messages. Tim, if you don't have a microphone
and still want to try, go ahead.

\start
Date: 14 Sep 2006 16:36:01 +0200
From: Martin Rubey
To: Timothy Daly Tim Daly
Subject: Help with adding algebra URGENT!

Dear Tim, *

I'm having problems adding algebra.

I have a package FiniteAbelianMonoidRingFunctions2, short FAMR2, and another
one, FractionFreeFastGaussianFractions, short FFFGF, which depends on the
former.

I modified the Makefile.pamphlet in src/algebra as follows:

USERLAYER=\
  ${OUT}/FAMR2.o   \
  ${OUT}/FFFGF.o   \
@ 


I also modified exposed.lisp.pamphlet appropriately. However, make NOISE= keeps
complaining:

  Semantic Errors:
      [1] generalInterpolation:  FiniteAbelianMonoidRingFunctions2 is not a known type

(generalInterpolation is an operation defined in FFFGF.)

I also tried to add FAMR2.o into the previous layer, i.e. layer 23, but that
didn't change things either.

If I remove FFFGF, the build completes and FAMR2 is visible... 

What did I do wrong?

\start
Date: 14 Sep 2006 17:56:36 +0200
From: Martin Rubey
To: Bill Page
Subject: putting pamphlets on MathAction

could you please put the three attached pamphlets on mathaction.

fffg.spad.pamphlet => FractionFreeFastGaussianElimination

rec.spad.pamphlet => RecurrenceRelationOperator

mantepse.spad.pamphlet => Guess

(mantepse depends on the other two)

I got an error message about noweave not found, and including it via spad
doesn't seem to like the dollar signs...

(sorry for not being particularly useful anymore, I didn't sleep last night...)

Thanks for everything,

--=-=-=

H4sIAE1sCUUAA7xb63PjuJHfz/NXsFKpysyVd9aWZ9a7t7nUUXxIjPkyQNnjrXyhJVhmliK1JDVj
Z+b+92u8AYpy7kMuU6m13f0D0Gg0+kWEPO/bnmze1/3+/b7c7Z9qMnz3L/53Dv+uzs/pz4sff7zg
P89/ZPTzi9nVxdWH7y7OP57PZh8vZ1dX351fXALtO+f8Xy3I1L9DP5Sd43zXHR7Iyyu4dbt7+HfI
82/+97dNuz7sSDOs67Lvv5bdUK1r8j9v/nboyb5c/1ZuydfyuWp3QHog26r5KgcAYaiGmnz92x9x
7vo/9N36h7LekoeudIi2KoCVh+Gp7b4W1a4dnl4cv6xfgLorfyNsAjlx+dAPXbmmE5NmY/35d7Ie
YLnyoSbt47ptBli/V/Qe/lu1zde4WpOmB+H//Oea//qXv/zXm19+8dr9S1dtnwbn7fqdc/Hzzxff
z87PZ2dO8UScFDbTVeuydtx423bV8LTrnUXXHvZOPGzew3C3rh02vHc60pPuM2Fk+B8imwqErB4O
dH2nbDYOqM2pGqdvD92aMMpD1ZTdi/PYdrv+zPkCCzhtx362hwEm2bWb6hEEoFOcOWVHnD3pdtUw
kI2z79rP1QZ+GZ7KAf5DYJq6br9UzdYBNWwqOqing+hEZPhPLpcD/753bOl6p32UYq3bDXF2YPmw
oaEEcenM5UP7mbKErsQ0jtO0YBLkDDBV79QwI53IXLzZjCSDZcGaKtDr+9fkgXUN3Uh5YMubA8j4
/yUSLKvmoRhpzqU8wh/gdMBOAbkrBzCNsu71ObDjA6aawtyStduUVGwSukZT7ggV8f9gb7C3zlqA
jmVnV4H9UdNnq7VdD+K9OA+EWhzstnXgzgCVUOMCceGqEYfrEm6KkhaWBvN1HgHAtde3j8MXanTC
IJ1+T9bUHmFwRe20o5bYcJvse73LYhlhB2dhceeiwIHfc5TdRn7gO/N7p1gGjpfl9yhaLAtnmcV+
gLDjpj5Q0wJF81WRAeEPLoaZIvwHxnLTeyf4lKMAYydDTpTkcQTTwfzITYsowGdOlHrxyo/SxZkD
UzhpVjhxlERF4FOJsjO28PFAJwudJEDeEv5051EcFfdsxTAqUrpaCMu5MEPuoiLyVrGLnHyF8gwH
Dt2cH2EvdqMk8N+DBLCqE9wGaeHgpRvHo71md2mAYCqY0drqPABJ3Xkc8MVgq36EAq+ge9K/eaBA
EDE+c3AeeBH8AlMFnwLYkYvuzxw+Kw5uVgADtuO7ibuADb49rRkH9EL3hjJvhYKECg7qwKs5LqJi
VQTOIst8pnEcoNvIC/AvTpxhprQVDs5gjcKlS/NJQGcAAPR8hSOmvSgtAoRWeRFl6Ts47DvQDsjp
wmCfqTlL2YZBURm6h2lhIqoLdg5nzt0yAA6immUac6kqMGjOKxwDBiuCIgtjpzBNGiziaBGkXkD5
GZ3nLsLBOzi2CKRb0Enp0ncurLtiG6fHBZLxXyNqf9KIz9ixOlHouP5tRIUXcDAEHAmzYarzlkLx
79/8NwSb/6Bhxog5b968rZrvRfR0/jTPsuLdm7c9GX53vv1xW7cPZR3QAHnoCLv4LnVh39786S0I
syGPVcO935byeufbQ9lX62/Ot6bc1lXzG/xWNk0JPyBmEOpCSA9/LKvNhjTwC8xQHuqh//bmrRz6
xnHefnN5bK7WSdlU+0PNHB6MfA+OaJG4aZS/s3HgqR5IxwCpYoUQkdtOjArhrEaDEliaYuS8R5Cc
q0Xw8+uFxV2Ae2rmL3jowG8durL2QMahhGgvBmBP4JsXLtm9+js8NCwP6C8E50Kwuq6EGWFdRseF
610LTt+36wq0uPlr223KRghBYX/NkK+2rWBxRQwMeBkBGGD2p7yDAEfPhMmaJ+DJfM6fl3XZrMlm
zsJd0RG2/fm8QEEgEXBQGTjZUmh3nuUTHHuLgBFb5BODUZUNddGMGaXgMkx2WNVEcMIoDkwWJmW3
flKCYUMwLjLkDTQQNexc50W2QqnFlyPNgfzM5uAvBKVta1Jy4bIsDqR6vbLbwCy1tjfPRb7igT6r
singarWSWQTpJFupZ6aBM4F8KmkyKeZfumhE9mj6y3jg6jEeceF+Vuu8rV+adgcJgWHDdKo8iwW+
rh4hl9kYNuLFUSiYbS02kMWZXL7d7drGJ3TaRh6956vtAfswKHqWJIq+r8mzIOZx8Mmi8zta/YPd
cAnSF1GibGXxeWYWBLXtYO4VIJ+QPUsBmVkL4hPIS449iwdufJGkuRzSDFVzIJuQalXJlhYhOH0J
aZkxDAS/9APZ8VkyuIz4Xh4KcveGTMjN1X32XqB2iRp2CyEXYvx7Lw7ESL+ECqLs2Th/7uJAk2Pq
gSk5jrDYoA950I55an2pfAjKiRtLQFN+roYltcEGLHeblKAEdir+MnFh658k8PcDOfBlaeheyYWr
dv9UUp0Q3NYshTS07UcZziWwgxIn59mcfW6QO0BQ9mcS2O/r8sWaBUPucK/YsNh68MkWLqw0E47z
tYH47QEKrbBuS66TMM7cYxamiWJZK3E4FIcrYbx+V34xDNVH7p33SbNEHrwUbpmyl+ogKSDbSxPx
UZaL9YNqS0wlBUJDQU1YEt+pKODTQFoNYA4QJDt1FfwgpPlKeGpYnPkBHMZn7ijoX6exFvRVJK62
bHUcLdJXUCLqEXODITjjlbgdwe8HtZHgxqbZZhHcCIsIus7wi4yFkHQ/wWFdQ1lTNpCGkIeGdDTY
9Mbqi3mwAg8mnHHwXDGDCD5F8jie91ASy9tBk/cxfSQWIGZjCIbrTEY4PI2yNE4nA8IYWLQQLRu4
i0/sWJIpqYp21VSfy44G9bz9QjpMeBolRFzlwmXwO0I2lBMim2aLHMqNyTCrYyylpBA9GTV1E0Wm
9ulXn6uj0BX60e3MRIUVqbkQ4RGZer1qzTJJjvAWR5ij2MWXCSF03R8vlEI9XtbMGDgsnR9hllBi
7tpuD0XkTqCWWWLCYvBrZeduwddsQc+jHcbuYjF7BY7bbhBAnMmgw5GYDKdmxcas4HgqcFYs/WNM
Wg/eS6ZwboZvY7Sq2SJiRXiGQLmNEY5tDPMkDPKlyrSqEGqrSMYhM/zp0CepZR3BlazH1gWVoRvP
bOgY43oKQEha1fuWNsogaeWWF7uCe6hhg91AvbeYyYpyIdTBhlxiEW5rvOR4Ga0cem4xs+HsvkLm
TDrlefIEMqsQT+FOJtCTcKH9kWsPsQeufQI+tpEpSY/mmp4q76pdNUCRIrw3x+YoCeIpOD7smNtf
JXIfi/LQ04TVytFMjwtlMw6l7hcEnHJZn3RWC9OsOHggp9FBqhzb4gCekF8nxlpBJR8aLKYP7mcZ
L0oNpg7NCxWZGUO7GTVQ3IhFV4KrWPe+rE4pH/kyGMoAZMUem3VSY3Mxx7Kstc9aitFLUjKvuAzc
XFKey81EbrcMPrmQ33EQJJHkmRYmlBPpeoRdTcgMwQDbvhpJAleUptFyBp5/iKzNLiV+JV3LRqQh
jWHnk0NGnj9KKVT6/xGW2uUYmo+gxWHPI1NUrHIZmyymfVGiAnK52WuwSwW7tGAvYm9RGhX3kqPs
Sd0sQYPb/MCrn2ptZSqgTFrF2mgeJnwCMX5DoKimwF/jKPWD3MLxarJ4Iqa3EsuzRpSFZvozM58c
RYm8WAKDyCC8pZwHBbZstF7iPMR6PorFHQsiPe2O2EpGsxM4FBatxHIkCmfhCfAYagK7z/w6UoFv
Y0n/DN6r7Wjtg1lTCfi3tNNn828r8iUXkTi6vY2CO5uP6CmYtza6RUHqa1DXk7iEmmRNig7uGu30
c1luYzeXASnqYKI9ftmlpVlvRggLr3NNuoaMQuJ1gNJARsRr8kI27nrNnBq38mtXZ2BTIrD1PQX4
B1z2BNK6pqUZJoR4Q5DY/TW5zEVtEldQ2nfMxONoLmkEQx7eEV0CxvgmkUxqsRmra7sXv3p8JLAM
jb5mwwdKjczE8/qXz2eKgqWDOQm7kLiLY+BkDyPGuZqTl8G6CqYUW++UN5tgXkrmpWYWbcLdLxuU
SBeclL/xGpIGcjiujWm8yXUYe2FqIG3mKvU0D4Er5k46uUbgfaWfhmX3+gyZRmD1/HpxMcWfaf5s
in+p+ZeSL8/ZLPQ5dTpHApxOkgRwqvuT6PYPR4m8mLeULE8GU8YyLiek25LiCWRmnGIZpaIKSCBA
1OAxp2t/vqZZ/TM8MU0zAdOUJ9c2bbVBsMxod+CbJKITvRu6vbLZcFHxPfYSeTjUCkFLoylymb1K
Pip5PqwyUFvoHMlgSJvOVU8GvpJ0yowqMiGr15Gs4sLYrwGz85eEVkcaJOKxNROEOD1T2jY6NjKb
S7M0uFDMlFYskDsasTBNI8mmJddxdpNmKJGeh2Kihh7BljTV2ugyUlQinKkR+IjVtbRsJy1gc/KW
iV4Mo68SSCk9iw6OasJ5ycZDL4apUlyNujmUGzCiQ0cE5Gbl+hZGJPLjrk7qyWAucLQkOwKhEWiy
vZh6Znsxg7NrBCeTxyaJ0/cWYJ68tlkD5Tqk/T0zS1VYsrry4iTEno+D9YR5WzUD14OUGYxG55HH
kJF8HCwnFK0P0EVDlBKyxMvS1Eb45HPFs6cs8YNbmxk063YjfEmWBNLjKjZtKgkeQhO866rZKP61
DTCOEOSW338kF9P3FZ2FoZ8lA70KT3v6mwPhQTjLb1aBTOfAUME+NyN9It/Q5xgxUifHzhT4yO6R
1IuPFAiTIRLfqDIcSfLw1G6pFZy4ghkqlurTQXYY9gcz+clWwjxzqFbc/b5rn6FkaUxIDvVKLk07
L2E7g6DHQVEEkm4V+owvO1l5CSO6kQZyF8YimfjD8JI39/O6bIh3gOPhKJR7K3Q7RvH63EDhSdSh
eyzXCrJC4enVxtIhFSemVj1C4wk0X/0YupoZOmMst9nkpGMfYVQXw0VFHqDEUiGY7vpJaI9G+uUx
d6IXcgyaKhFgSqQaojkk3GAF8oNbDsm2/uZGRQW18bYElVF+YjP2wPqEwXNJzZ9LsgimQXKShWx+
GQDJE4yKFdCud51HkuK1pFur3UZeFiCZbDN/NtojLSLVScF9kVU/lxBlwVzzdITWAVrT3XRmt6Vz
SlFNYA30dBHPYNpHaIxV6jOUWeNPXOyZFGs2hrDWQS/6BPIbkmbbLenxJmcrtWRfjXIIpXPd7Ylp
l8rM8OlTENn6sXsFskugOlsTMYsWwxC3ZgppuyGkKnoR8aGOF0XWTZhJIwFeXzGdUws1xt94if6E
Byh6GYS2IWEoxvTpME2RKk6z2GB+LLkJzJnEtzjjS9zNoR0qkOqVHueN0eNEJe1THmUkKiERfPap
wuDjLIZAJlMgCnq2OlDAkpUEY66GqoYj4dcUmKsiiiW72bQ7nulh9qaPQ1IfI09C7OSZAcJp3qvf
yk4N0i9BIA9XOfDrOTtHys9PY+xo+VfWnrTvU2Dz49tJjGrUjhGjrg9yddeHZqVezd7x8OP34gxr
lr7F6iDNW5PFxnkCnPYELWNy4/NJ7o1i30j+eiibLa3yXqtAUWJYMGFwyFtONTMR9j1VeQh4Ad6p
kQO5FAustXGMWaw31pRBsfCk+RPqo+XDS7NQh2t08QpmJjBqJz29ZjEE0Up+GVD2HuAY3IIE0reM
BB14ewitZHMI0belNP+UzTLaxtP9Wv2MAmUR3C7+mgq1EGlZ4cGdNMpUsKUriGKULqIUhNddtR+o
ZwTt0B/iCxR4yJXshE1gLgyQ0AsmW/nxAQcLizaHzFskqMCaR7IXZ7NtwxDAmYU8gii2WFfuqqIa
V++/gueBFz/WWzHsBtpFsBHV48vooRmULJD5m7caRxAYUjmo2dZm1NMfaDD4gideP8uwg8EdiBQM
UsOuJ1OxdbTDlbQo8bDhKCOnTzJVVs7bffQ72z+/ShgZV+lo4NGlwuateh1u3y8cInW99LiTcReH
N4ZY8n2c8TwODx0puT7B6bmJSbX7HJx/MQmYacBsEnCpAZcKIG24QKqRhYdDt1uWD9X6ydrGUkRd
/LJ7aNllxPfJXBZWQOVZP8tpT35rwAsvlANo8+oodt9jCN9yJTcYB5CxuUOkE36noP+vhfJA6QV9
AOyuJP2lbo2vc/KZXEGetXMo5NMuRb0Q5AtFH2THG6iF7nkXT3D4Ri+CtvL3opVPG/mXvoFjBRQ3
ctcLxDEU9L38N4fOHCWyAi/afUw+k5o+0bHf/iD37hUISK8uPKvU1CBdIJ4aOG4T66HqtdGpoazW
YHg2IC8cG2/vvshy+cGSfStYs49MQ1kfvWwrkPFklmEns70CuRLCCzZdrL3+co4/nJMLaPcVlwfa
h+BmY9+xVSyLxFOVxOpoOqMamswZVrT48F6ZdrKHvcp1E/ufe17leKegrDsL4WI9boyu8uR4N4eq
J4fnSeXkn461Y17BEbww0aTrIZvXQXeVRirujvmjeRhSTtWTjqXaZHNLBQC/wLpRwtet/FvxBeiW
SE9yG+h0mVPt+TlfzE9vuPy+bmiKXnb1of22rVjZd5vJV113hzvSFP2hOQpEd6AFGofevXmrHp+z
IW6/52+ssczUgPJBUD4oyo+C8qOiXAnKlaL8JCg/KcrPgvKzolycy8XONW0maTNNk0Mv9NiZHDvT
Y2dS1JmWdSZFm2nZZlK4mZZuJteY6TUu5RqXeo1LqaBLraHLS0m71DQpy6WW5fKjpH3U2pXzfTA0
LnXwQevgg5Tvg5bvo5Tvo5bvo1zjo17jSsp3peW7kvJdafmu1DFqXV1JXV1pXf0k1/1JrAv+GIqp
xms3/EWSd0Q264DQy93rCwtiN3ZC3dUR/KRcP8H1Kl72RPozBkwKb4QzyyQOmULIy2YjVdARWJ4p
sgzKfBCW5RbKYqkHbYLXtVD47qxlAOO5kzDJRq4tx6S0gAttGF6XNI8EHTEAttdQ9BGZQNJeDoIV
JBbT9kzW8rdjZXGsjVEfdNnpGY+GE/bk3OKql3uJ8XRP8IzyIFHlAYsg0t96Zb0+1IfeyiSgLtZf
nNNy61f9uiMDEa/41KsBVh/SzrH5Fcpd+BFWQ1lL6AQuiETIgN9j8KX4sKf5mA2S6QfMRV9Z7aq+
lK2RiSnV6yuA669tJ8A3K1eBeZ/ZeyLr33rBRoHexvht94kZoSJSQ3TIZq9g/re9d2ts6zYWhfu6
+StwHPeEtCVFpJykVZO0FC8yG1FkSMqXOmn3ErkorZoiaS7SspL6/NrzG87T9/DNDG6Dy6JkR8np
3idsY1LAYAAMBoPBYDBwARv7NVs1ZLflNtQH+tw2gNbk4ebqKjgQRcAvDCCzGXmjsl+1lNx2fOkX
sy1VRyd3KnXgtGi1XMwibWqxNrWz9TogQYvVzoffh3pioKScssdiLmSbVRicn2K2rU66Gej+hT4w
BG7rPUmWasNIGV8Wso7HMRIOE9PJU7rnDErHEC9IzPV5UOPblrERIZdiKjDn2YljcQhF4tCK1eF1
ps5jhs875jRGbhBpP6Z2ibAh09soKd4ckyuIubPRid4lpWFxvWPzdlrMOQQ2Wag90YU9uSzCL3NA
HmdekFzWHu7AS5YIfARACrgFtvE7L0fHh6zcFobnlkun2FpeSE6PNuu1vk84Gg2OtKGE7q854vYI
j3pU7mS/mvxzinXrdQfmbf2v7brNfh1kf8uzZ0H2Cc++CrK7PHseZJ/y7GWQ3efZb4Ls73h2HmQP
WfZ07Ge3Gyz74tzPPj5i2fULDIHAL/pA2vGpJatZtTTtGabR4HRoAJ+nFNvARfX8eGQgapG6aryu
2rnf1toRa2vt/DLIfsqyxz4D1BqMAWppkN1i2QeRxh3wxh2kqVf+oNVi5aeJn92u6+x0/0mAHoSv
RQ8AkwunPGQ3j1n56cTPbjdZ9sXYzz5usOx/Jn72X3njrs797O4Ry54HpU956U1Q95mpGxTtdLXW
flzkV5Ot+b2y1hAv7t0BuGqhqyH4aLGYOdQdjnq9k+F2wCqDvAVnjYHqtS4ifbk6enpmdceopF4t
YAWgFee00x/0jjxQlKoWBP+KwDBBzusGSW50/rjUZ5hB6oeY+07tfV47NAW7AYvU2lp5zHKGue3R
kfEPNv0NQYE8FnKrbiUvazk9bLZMD7fpV2HJPis5WGzw1qRt0qB3Nuqctmix5dfi5Rp1ns6yxDo1
1I9aJ8apQWVKx0ad2+2dRnK150+9O3Byh+lV5iAf6kvt+pYSZRy7V90p7eS4daRNhMY8msxmN3iu
mE7MKX1dW6djQPzGiQJWM6i+Gj+F6b0CvcUuwpyo9acv+wbUsUhGodEqqbf38k48Hcbma7enJ7av
Wj0YpBcYKeVG6wfafHaUXDhlj45NWdIctHQ6qg9HL/vmbrl0UqWMbq955t5mH6TjzSpHVwYH88Bi
NpfWee+O7Nw7ytweHY1M2QZsNZHrlI2sUW88NYc1DbzlP5Oaf8BXjfqRYSv3NsjpYq4vhOB18tO/
xYA4hAYgFxtoy4hyvmUuNo3FbGb9/xp2QNgBiFXSORUabUMFB7a3zB2wXveo1ze3tuU9dSC5niOQ
b09u1I7eK99nFdHRH+/K6bOWVubV9WlnQJrfmR41M3ltTuJtdiIZdnskQXraFcYRPfrkUsK0Wy9G
IVBoLyfofu/EdCbmKwjoLDU4gLVLMGzP6gOGjV39dqA6gz6Depth0219z1h9eGf7Bi0O6cQlomWL
8DIyr6t10rJGr9ZsraVu68RsoFSqgx+zTQXQ3ZXhDoxeM9AnSuYWcnNxlWTyJvFZo6kvk7beJjNT
4TOQLbpG92qwXOh1Fg0lFPIulcpW2UbpITdy9oW5Xqvv23ZaJ02W1puS+5Q7NwlQTwZ7qY7uP7E7
wI7Rq3NilzN9QdgBOGXZiDG6FLXNWqSAgnN425P6C+fusLp47NQJfOPV6nhEEQxRxOlrhMhtS2QJ
M0jmr0HOmWXjLQ+kAoSqw1Low7sQAw+C3wImkKGtUt3SpcM/qRTKIbIXcK9SHqWjPah3LXrKLW7s
gDe2GNa/nAul9B0JPJZ3htMhcB2WiYYFdGPOAGFt3Wkq18GG8iTp2sHbgHqgZ05PXZhv8+lDEHLk
Zhg5BhSEbI1sZaBPQKF60WfQ3FFVz8g2ObxynMphKjHCvD1ojQYN07DIbWLJV6zxnkJjLs+OJ1ZG
HDeaRkYcr5KJM6DHlltknlUYjgegMegspbQdg/6or4curvB6RbrY5A57Pe0Z9tquUoFG1bB3Fifp
O0/qdl4YRCq7UMZ3mn1zH3Werrgk7PCxdK48Wn7vnPILjCvQtA3xQIU3xNNuT07Np1YZort17ir7
bdP04ST58UY6dDi9PPnb0Ar/k3S65nGTzNhghh2ZE67KBaGWTHsi4ubk1Na1haU5R99+K4/TA2/n
sQYsNm+zGU7fGAOctBmkpxqfWCF1sriQK8dJ77hjTkD8cyl5bUzlGkpxQoEESeQNuN6p9i2ltOfZ
+vJsLkN2UN7zM5OrdFJINufAsXtFmH9srqNpAEU6fkPsRJ1c02GLyytdyyv6npZDEryw5UJETucd
koyGdpNcJKWZjHZh9Mp5Wh9aFckD0RADmy9vZ6UT55DcMRuwVvXOMTApbXeP/toqumdE+fpmTXht
yN1SVQ2J3OgmZhOOl1r8jS6ILCvYXBjLA7262ZbEQIYaFUANY2DO7rdXHx57F2227YlgTvmVW/Wp
N2i2O25mKMh6XJIpKIZ/0PTxR3mw17XzUsGZaz6DpuUTlaf2fhiVSm/9+vVJNtYX2rnVot7sNBrF
Bg9dTZ/VosBcDyTHhN7Hs199YqmWZb0ywIKs14XYgs3Xa3ahw2lza2A1if5ssabF3N7IcWDpFlDL
g7X3cRzYIYelS2081wq6+C6LXJFCECcuhJb6BN9uRcC9aduHEWRQ5gaF124DoW9JxAQ/XpPgkPNx
tlT3PizD9rW87WN81Wx9812wue0P7O42vPeAEHTbwbnQ4CCAbFs+crOBYOwqpa4r8NxBvWmzlZs7
M0cNGmxfRPkqTCNlmtstmOMrJeboATNjntZOMwYN471d4ONOYHyVjFt/YEetSWIA4mw24Jt55XQL
bZSjNzhuPK1roRTzyHUwcd4K1GLUiu21CTyDsev7gC/wWkRYAaEWKLM8KdczXvewdWyqVtnmrokH
94IBMlE+ZGuHv9fiS7bXad7nod2juyCsSve42AHrWxa17sx3WIqHfC3e7kDtFGszjxsezsEB4qxG
Lj8uYb61dFmny9ElUPNCHkSP9O2giLbMdGXp++zmDrxcp0EYKdc2KIibyj1SG+a67Sgw1oyOTCXW
J9YdjnpDh8eJL00cmhYo45xbRPIR55Zbzc9ofbbQ1wtfY3JM1YNBzcIqI7K1IJ8V24nPLLVBe36z
SZ0Fxgrys3bTQMWcc3lrzk4sQxaB44Dh6LkbDywZKRoXXdJbN4SNrmpn/VibHBdaF/zF7fAFfcCi
jbpfdPgaY8vE+tEbtPqRuoo2BGdsuofuZegi62Ubw8IzYmqZ9YLtHl6YzcMLstWwnLbNso3PlQXm
BRsANNgzDvXdw//WJAdxOrHSsZupnDHh8Zt7df/4x7GjEMTJcdsHkg42/rU+CoA00Gu0AdZQ+ojP
9DOAsHhMs+aL+c3VwvrVUYtOzSkaqLp4D0OmjjrDl0phry+Xsxu6L0VZ/b69lUVZRcyioE9eAqco
8DsEeXYiVtSHw15DB9H0TrMkPU0MnPpmbUIdUtbZqNfVXtk6trOSErkhzxE6ouj1XUPxbQIB0f4g
AqPvl1ggfRxylP642Kytj9FR62/mVtLRYjOf+MGojnpnp82/DdQO/WiVzWagcq1Haa7yB50THcD4
EuR02pvqYwnMbjx9FkRL9uIhs6AkIIpZ8ON+R0claaB/Zg5rMIpP2ETRIX17sdI7uqMkl0zQOao3
nnZMAOR0NU7lpA1CITWe6RsA0UMtAul1j0z4ZbyooI0WOr4YGjgsEtgMRW+KeQdX3TN28GUCEeJN
XLyISMYRW5ZfQ8b4hMOTfssprDZpCnf/pM+O31i+iTDQ6LMAAyxQc+hT2Ri0beRl0gYwni0JWLzF
fqr5WwYQlWoJjQsVHo6YKwaCLGAWFEXBftk46Y30NjxyndigxS39aKTRymBEgxQNn66TWbN1bMKn
N9PBZXLFYwm3Bk/1dTS+mZZ3/YoD+jRN8CzH5EpZMo5yJFfyndXNm/1uNwbGAXoaQDoSnywuEnrp
g3fwxDRFvSCibBPxlpuGUwBm6RjpRgNpHp0MWiZitAmgbOwG5IxPoZT3C2GqBkb71QTngghRHMI4
L9BuZKkz49mzraCjUqiCoEH4JcPVKGzWAAbgUrL8IBafWeWz3SlCmapm2XLNnBfjmgi18KR9ph3m
Wm+MV0rrO+MmYw45VTgucxKqz+/QuI97/UgMczT1N7RagS9HzPWJNQse0HrRh//rGwEMqjfdRtoX
fUbbgpDMyt+q6kONNucpmnwUosHo7MhEY0Z7vwnG2TIHRH7oZMzFVdJGdfNBHI/c9sDemVcL7vzC
hag3GMjxSbczbbh3LzCtoa+9otAkox47te0BE7iHqv7Jq3e0V+/a2M/sZJXymp1nPMsP2Ow4HWDk
5hd3gj66ccUDluwHJT3kIeot+EJs7phF4lCzqNFezadHYd0x6LAZp0dhQ6IrkAxlHcDeuiS323ZB
bss75Dw6c29gwv2r2yDmJjXl21gwXvhmya0s0ouJ2UzR9/K1DgSsqHm8HarNY1AgeNvAX/HDzbY9
3GSHzDY2OD8QCE6hFTOzMyEEsYW9sqzWrp8qL3DpG+Ey3VTh1KC4ChdvxxJEkHjlvu0CNpLZTMVj
Rzfyjt5jOBsiplXqEOawPhzVY8GkSftQx8xG5XAgtkSLbw9ZrHi3TJGghiIgLO3BOisUvStrbpW3
h2fsFY/jZLbIchocx0DhSMNjuQc5KyyiIjzzrQqDikQwUeA42UKsPpSVxCqQ9VN8IIlP2+OnrdNh
ywW6k0J0bDQiVcpmu0ERjlunfRMVQcFKPdEs08dDs0wTAHnkxY8VjxvsYBGAW+/kwq5qarX+5lSE
ZsrCMJQAz55HUiXk9PH6CnPaBIoLuqsOo44BwpxGKaDgRu/xiIOc+c05c5qzydGEEapZx0p/PF7k
sJsyd7S66fpyIQnRg3mrVlCK+9250oOBgaR0vLFjNNmpq6DHJjK/DvxFXglzR8ZjlBIMTecCkoiX
OHqto6GhE8Yjp2SMQs7S1OrAVzMZ/bzKgGK687FVnZ8m+aVhn6f14VPDQLF44xvgSJl2ZjiRuZnc
id+fGn4n75NU66a+wvG0dXJilY7OHPYfqOuC0tJNlipudQMWtb5xDSEXFP1aU8c+1xRzTvHXk06z
X9/iyxKsLgjfLYa35+YA2NsCV3CUjaW24i8+35ZF3a5rCa7I1mw5ucH7Eh3+wIQC0takjrUmqRxr
wOnwEMIqtyDSaIeHGlWgNlhKh0dLUbkRM7lFVHNAbdSBDg87QK5HTniTjvP0m873H43r6L0IAUTj
RHRsmAgC8iPe22D3mBlTVzpt60BAULd02+s3FLgtyHKHR1lmJZyD1aDEd7zlasunpEDnFMS5kQMS
gD2a1znlqwJlM1U5UtvpkUMmdRPEv+3ZObXx8S2UfMjJs0x3TttDDuvbLDvMZikBQFLpIGud0z7G
WfNzZXi1zvCs62B2Xy3o836EcZscxQtQWREG4PxySt3eYqEcd6/eGdVfnjjMvT0SS8d5w6wzX27W
bRPF3oY3NBnutlmCmBlLRDTCFlTSzsjJKnrkAq/cMKYg2K5cbf9mNP67miEdK6SjKvNwlMpg1znq
MzugA81g6gjjgGBl9v5uZxBk2tKnI68GWve9KJOd/uB0pLftGkhbyS2bREPGyRacDUzxFawC2Fd0
DPSFzgBfndGbZfnwAKbL5wZU6uJtMpbOe9/2ntUbejYok5e7cp/Uz4zydpImE3o9KJ020zWezszN
qJy06k2Qh9pzkJ7WU9obj3TYegH8aN8iSNk2I1cAxsPR0yFO7BY59ooGf0Tjdu9IdweB/pHtuxat
6hLVu5ao6RK1u5YADS7Xhcx1j6JJcXTj7K9hbtiQ4VAm8jjNCSibR4ZWgTsogRh65Gu5YOkmdVmD
IC90mTzpgoDVjLBwz1R0pEBKV6q79r48uZlPFvPn6kWEk+fsOYSLK+nQWT/WJzL4fIK8CBV/heGo
4T614F186n7LLj5h/lkxqjMHFX9ZQU9kfAYw1880YCDh6DsNDnSNQUdfbXCgDxi0fsMhzS8bq1RK
KnWhEAS4e5tfBghpDdV5C8hcGEs59UHuGt1DLfFGikAe85BSuSbewWBxbc48CPrpoPfc2B48CzGg
GriPOZAtxTxSQK3QRy9d4NRskzsPnXRhW9Q5G2oAfn2kyzGrOaGNcUY+I3or3vXjDPjlP8jQ0Ct4
8MLDgQLQpDfh85zXFAb1kXn6SgX+StUDIl37eAjbI51k07XuyklHh6zhENb9h4DOTkbD73T4c2cP
5p0HPW3qQCzp9W3HSqfmWMkAF0VgOx2e3QXUNTCf2tiUUGqtosHoECME0Xo+0qx4upiz+3haHuob
YgTd6JkdIr5ZQWm905ZJkXKyna1yuWVynl08hb+qHqivQp7CWmJ24qi+Ku8372ELdIFTMH1cEym9
3+jpgxq5mZBxD/UzE+3uyMmMmvtOHXOfUnb5cQUgsqcV6mI0s3Jgir4DDr/NVMDfVlXhHvD6FLm3
pACg6RZn+Z7xllf70YD5epr5tE+0Yz/tOQZUBaJP7PWGs2cO7XWIOe/tgSaIZO7PPbuJ33NU7emd
FMJyZ4Fek9dLq4uML5Eys71swXPdR4qepVXq3tnI6tTe0wcq/L7eh/v7ErYtCVwopAeF8c3l2cxp
yUJyPM8zu+WKs1v/ubQv61avkgk0eUzREZVjAq4s8oSdSrzkEVXtywRuEB6J+6T1nXH0dp5y4CFZ
2gP2EIR6vIAyBqOOtZEzVwP1yoOT7u5cFETVASEvhOB+Vt88b8jBCm4l9bvmXlIA7dgZ+5EnFqw+
3u9yjZzDBJdu+l127caHtHsU6PCJCYLFwQrc0bt96yfsgG/yy+biWpK52+w9Pw1hCt2y+13mmB2+
DKHaGW2mjX/b7xoPKw5gxFi/y6QY+fW7oVm1lKw3+if6HTud5qZ4LAN5VZtp64N0q0Fg1kFTp+sw
tHgfYAxL9VG2en25mE6fZ+u11GftNDt6fnJkoWVzekZQy1Cvvanc0JGgknOjV5jviIh277tCQNuV
do/TbuE9hcACMQHXjBb9hX7CYdQzMjTkJ6bH4B7NqjIhqOEc5z6IvBrxnV/IMSccaYdX/QrMUfAk
RhG81VF0yTO/qHvqYo9cuJeYp7X0yZwfvKXhwAFjLsh1Jmcl6n6Rwsce+85jjyxGnaZ2QALjNoc0
tc84Ouct0Xj+sBnqfxsAo2IE20sZ0F1Gmka3z3YvqNjVVPtWTe2vKK44ng8U+DL2YS1Bd0YNz1/y
kPn0foeXzZ6wpdcudXw1AwCzw7iLIUSYPcjGDMK8G8ZUGXSqOjP3n/J0M1kYH0An7NtgyGHkQugG
dQcKnzWNKba/WaVbPFP72jXVgWP+b33zBAuIa63CSGqeDa3LI0VPN+XV3ve7+omN0B5A1BiI+2BI
4LQ7qJsHXeWTHuYsSA/toGkODiQEmWxDsLYPp1bfELLDISO7MLkJ8yAiT3PUPRBG2yCP88lgZPjk
A8x3zHqHF4f8DQfeOcKJpSG8y0IEwo9ZSLKtkPm4Zo4vSOonXMgrYMJO1gZmzyTzeH9twEK1q+9N
zfoDmcyjaJCS3qwebNEbHeh2irOavPv0dZ9Wv3nkZpOIsNlD8/5Hnk025mYrKAfsqpDceIX0Gpn9
2YAiCGivCvTAbvROzLMR6960q3gp78x783S0OCUx1hp19dsMbljeoY5Zz9J7U5WjrYRy7vu3Id1t
x9BuO+LgfOcxtDuPoicpCKze0kD4oMQaD/rdW53Dun7EBZ+gxwus40t1fabeeNqyWU6s9wFIHP1s
wi3mAmMtCAH9s4phV5/Gei4L1mNhu73BmBt8sNCfvocxNgugA1/OoXHlDOr3XQyH1sHQhw26e2a7
CwvsNvvM0BhoCBS1p1PlSzDsn5yaxyhNrg7AD7k2Br//aO/wOy4k4m9iLFYw6K3pNBujGubHX0Vw
wDE0x6dy0+c91y2Ryme6ORgniItzOOLHVgq6+IIwgLfvAOrainRBbaqVJ8uM5waW6zbnMR/k4dmR
9UEGGPusxNkRu2qjc+yrJKsFxu8zkaGALgYJ7Fsu5e2a4ZmJ5LpZGk85xwaJLlKDun3K48q9TSZp
87JrzdEGxJs3L9njr3Lv6hjB8I+XOvyrJhA978HSks27o80VdCzXuUfm/BMA8JBRPkS5CZa70VED
qPCthp1f8PubCp2NZaEvU+hDWNqhmFNYd+y33QnS1ji3RAgah3OdrbfCOA7XI636Bc9o4GOg6pFS
0pqH5hESczQWm38jVHf11T9m9LMWP51qtnWYZXeo9Mq9TO6bEY17FHB/AhcE8TdmGZ1IEF+fmOdC
HDj/XZZa00A5etnoec/qZVaGOjBnp50oDOnR3gn6mQmHtAXQmThYouoXCZYGszLcftFRgTdMZInY
Mlb0qtKZ8xRjtKSyebuFOs+2FHE3YWe0C2u1Anh/jbNL3O03IzV8tNe8DMZvYae7qLAgx2drc6ly
aNS8Wxb28OGX+OVLdUJJ9y9HPb+Mv1yb1ToO4ghMgDVrMnsHRZk03WdQtOsXlIElfa3nqEShA3Jz
3Q80v46VvXpCeU+gyMznaQbyGHTiPId9NegjRq49b3W0eCkwWWuL9e0GYWUPVuR5wTz83KF50bSr
zAs21qzpL0DKm2vbL/pHzz0MmGJx+JmxHL1PMI9nvIhERCCAAZXHG6oT9axMJKLq/yQxKEOq7lZ4
tjyyMPnd3mksH5sjYboDN9+EIzAohscaQtt3ZdaxSZdKv0yVwVXdnCC6qgRttLeAcXO3Bh9q+FvC
pkp4dCFSBXjAU8qkiKcmU4U8lTky5qnOK4htKkEHDEkQ3VSC4C1oA7L2yo9seRs79H/KdYtnOYE8
/6fW1yxm68hAmRSOM8iyy7UC6vWHBigSkVNBYUjOCFgoxiS8jOMRKWA4ToXljID4cTkluAzMacAj
UdsU2oFDERubU2U/Y7UWR94kYBV60wC7UTYVCBs8L5imBKBomhpABZGTORRETue4178kwNBkFoTU
VE1gLXAiT1L2Cz27bBJ5R/DUaGBNCdpvGMDodSwJZcXH1lCYCpg1KRIMUwLJaJgOnHNeI6FkPEwH
KkaiNiNRGMBSggx9EBYFU1GNwmAGMNH7CrpEnZUIA2MqEutxdkJjyjwZG9PJ31LfwKnPD0MpYRy2
2xqIUpGO4vZxeCeajqqYokwaoEiYSTVebEwDyW7kugk1Scky1qTO4sEmZTYbFB5uUmV2e02TqVcz
ukulUmMhJwmIYk5qoMKgkxL0JRM5fthJgqC4kwaAhZOUuc6YRI5uJdTpkEOYSGwqc2SJ5AWNJACK
GqnyI2EjCUbFjdRQNnCkzLV0tvEhZQ4FiDR54fyjEJEmP/em3gmbehSYUaZiZEYH513iRaqiFDBS
FXbjCP1PZSRi+ZZdZOQnkz5PJir5tN7kqTq6o819fmbztd4lPUVYOo/waCCOW3qBKZ7YfFqHERUV
yJAtbEFMRQUzMBB+QEQC6GmCbwuJKLWqqh0zFrRPYpFR+9xcELg6c9jSpC+IyUeAfY6kQM1QR68B
UDQsnSzRbsUKsNBIEkzGRjJwQRAfBWVhwlhxBKKCxRmgiOeBhGOS0QsJR/kyJpwGcIPCSYAGX9X9
4G8SxAiQ28K/SfBBo2HgCwLASUBnOhUoyRQDzgcpGNaBoz1uCx0mwZ3BClcnFexN52sGY+zlbnaG
fH0IFAUZfs3mOk1xWhILYyahHILFJDGXw15QMpnPthyjUCuleGI6e2u4MAku44WZAkWEHjndu33r
pWKGafjioGFSpMioYbvarFG84TpjvS8MEyYh200Ld8fIX7KgDP0VFC7gWBn8KwIdFxxnXHLcPZ6X
KksBvYLCcaOSkrmtfqy+WEyv/6msPRbejepF+SqslwNg9TgZ2Gu3UqHXa/N0/Ub86+EMXebRypID
9ZvJOlGP5f5LlOWFN1Eq4z09UfrTn0aXaZ6KC5yQubjOZjNxnooUy6YTUfr0X+e4U/8X/nKem/nU
PJSLv+Wzb5UA7djS1UFOa8TsRteDTf+wgpcUSAzKVbb0+l9AsPFiebObp1upAjj+Uvo+xSuZpe/P
04ts/tP6Mj2HPWCGb+4tL2/e//THP76HvOwc9iFXP1Xfi/lifQmSAorNJwG0TJ0sxhvc8b4v/e63
z//1z3Q6vdjLl8lkb5lcLS9n6fr+69iHzxf7+/hd/eKLqvze/4LS9/effPnl/pPfVfc/36/VPv/y
yydf/m6/enBQ/eJ3Yv/+mxJ+Nvk6WQnxu9XmPL3ZAjdeXJ3/Gu35lT/f6+k4niV5/hMqw+NZClN1
k6dLaYX+KXmXLa7eaxlg5+/3axA66U+GhSAl2awvF6ufuohnLgZIU0i9Sl6nBKtxJOc5aUjvQXiD
ZBOqplxM5LGAgMIgSHIxzWaQu1q8zSapmCb5WkzVuS/8SFOxUh5EgCfjboMiMX6De1Ls2Cq/J8Vs
MQVhusbb3aXvc2nu/Ek1Q0b0EbcG/3lf+uqrDyzyzTdflyrJ+fkqfSs+sGjp8WNRJ/IeCk5fTG+m
+XiVUcyCQ/x7hLTT+BX5cpGIK3lBSkwVVjFdrMT3OHbrm2X6U0Eb3pdubVy5dShit+t38Lyg+DOo
HgpEtLMVqg5QBS0oD6o7olXZXn5Qu1MttS211LCWyrbyhwLX0NU6F19/LTpoJr/Sbmzi+hIIA4UZ
xDXwZonwwZgcCuiH2P1GYD31agV/1muY7SGCgslkUirt7orrVMCEhZkIEyVZi30BI47DC5MH+Hoh
9jXy8hR6b7Anh1gB/FMDZKo/2VT8mK4WfwYGgSV7LvYfQuUyK53lqen1lboiVp6Kmb3IqhxhRLID
sxfD+YmkAgjEY1n5jliRU9zmCtJLoFFEplu7fSyKIh85k2wbYHRqbSvw0RMq04OSI72KBA/OO6ku
AuKjdPw6XV2BQriD6I5gmw773olI5hNxkpwnl/MdcZwuVhfpjmnvLkm4sfUPEYsp0BS3clbuATJT
PzYIESqY40Yz3xHDTr0r/rrY4E1I4Awh94KiDn/e5BkVIEIsUYmUhzKiVtsrFVGt3NwRzyp34fbm
IdSbzcuuqRD6qU2rOJ+eASsG0w2qOF3MT3G3BRsvZYys4HwYnvUFVPmNKHZ7QzCzFyTYcogM+kA7
BkLYpAnXxILE0PVbikbRKRwwM8cWR/n1jpjtiGkFZyfyyphNGBjNd39/jdzx499nYlp+Rz2Myghc
YkFIoN1SAHFM93YEJUWIha1RQ01dVJMYRprEPS3a73WrLmS4IMa7SW7Z9/yGsS/xi8ElWXePBNIY
O9utKIaF5ebh+B+vy93KQ0QGndQe66Jcq+xBk9dKcskpNKVLfpCNqJLzxWYtHk4fYgPT+XgxkbPo
4fjhniSInXMpo4v+LqCHZmlFkSJEBkxj5Akx1MGyUFCXIrNzv4G1nvHe9mVTse6zjx/9WEvKwKiN
OjDrjkjXSeW9WKYrHJVcKJexXbyOZzEl+mIedXOTo15BzATtADaRvW/Ukc2X1o8CRRBCpUqCWnwA
N90jbXBFnoU49hebZAViLYXhhyXtHOfPCk9dxWaJCQvUOCyGf0G7/7Vb3RPH1ATiLkhCRIl4MCff
pgfQGBjzHWqEXK90myyiSZZcoHQVyUr3ByYBoJLtM8Wm0J7Z5mouMoLUSus4yRkybAH8u5eJXfGq
ulPd2dvb26n+sCPlJGsH4sN1GNsLvfileOZuEi3C1Zy9pcHw5/DYerFG3y7s+A6sWO/kT2C7BFei
NP8olkV1NpnNYIxzOqtWZSHzvcWHYhVrBNadgXRZr24UmGnFe1pGQbnCIUGISHtY+9+7Y8WUIhgp
Z4TsKBRT946LVZw8rO5yoioF6oBkXgJ5kJVj65BFphakZfnHCuwM17QqcU5V0xo59e+kTiRscmPJ
d8C9Fp2ZO7KcotPwMpuuJUkOP3yF9TrOkKnV9mJLT/mKe4F9Y2xBnZRIf3xUTh6fP3r3ePzo3d9r
jyfw78FjmLcV8bUoY3rtkcw5eGTz3u+Jztziw/AuJCNydc0JlLEfH23K88rXc/ri1GgcRvqM/ZUT
PdrpRkE3QQD946fXO6/fS4FEBkLpOCy+gu5/I35kAwQ0gD4Bq//jp+zr/fdAHSqcvUfY7BtJJEWb
H3EYSVpSsfMbiye/lDcYkQSwTx8rAWsl+at9kHw1lH0/yG7jgdt98YDFdR8ssHXwE0g/p/SxSd+z
PfrAcaQi/8WGEf9nh/GNO5mjGtIHjSVHWH5DouvuA+pSZOf2AbUFAOTNIwR683c9ud/8nU9voklk
UlsUana/+bszv9/oCV6wrSnmjjf/Bad5defNDlDQcEhgwPhGWzDu9YO7BqKW0N4Y916DqaJga8e3
jqQbL2ljSjoJ5hPtxEI1L1wKy69jsgMqiSdPD2kb3rRmnNePHs0eMQZB28tr2FOyVaZMWksMIaCS
TIgbT4XwVXZ42KT2Z8hj+3t7VHy3+sMvMn5vdn+FEVSV3OcYuhLrENXynzuUbx49Kr9+NKsUDqcS
Daq6DxtVQJ79eqPKHGuIrL/o6AaKwN2HduK2E7F548yR/8zx9Ya1/Hp3Vjk8jNq8rGrxgZN3345x
VY3xLzPC2nq0C+tLRmcrVLM+Y8jF9BcZ64t0HVMGfpTKAM3WcTJLVmjIQgM0GSJoYzfdYXsZRHWe
ovFCnz3BdoWZ8Iq2dmUGc+juw3G8b93oFbDQ8tDd7B06gwoLLSYcfq3M+8IZ40+mAIA3xeVcoFd4
oF8Jdfpc72mvMG0xn92IxdsUeX+Re3oFGU6u8AoMUAZRzRdzMkzgOR7aUi43F3bCjMnwkS/TdGL6
mmATp3uZSTjHhCVLwHbThhGak11truROWpzv7SljyLnuCydaNkUPA3VawSfROUw+93iGTjKAXlgx
fj0O4cWjiK02qVhal4ptMOXGoTE3FnNC8S7/Tjwi0KxxWGjlO3TsL4ZNtIw5ZGZwIMJ2FkYzwdbj
MedT/qS6W41KrB3xSU1TEG3M5QbQR5pngJrITKt0vVnNpVDGENpj6R4ib9yIefpuLd5KypChBnhv
d67qINuyDMmNmPIrjFqALJzMYWoTOM375Col602Si7fUFsQqyf0/ysv4xHtbTGefLofiDJ0syw+m
Cca6fLDFDmskPg3BJ2/VX8sF8aW+1QjkFF+JJTSigv3C3PxysZlNoOE4R89TYvkdkWc43byjP/jz
MgHiwM9ZikfkQCE1a3eVmWuH/qA5rAyve/bsD6v7WlRpxpiuAvpDofev0NS3e1Vn7pLMqe3tzdU0
ZYyn0L7dy7BTxpT2jdh3q8APAhH2DCZo1cnCMoe0Z4GVxc3CBvxTCb1stxqTFNQEWe0yrFZW/U8a
gyDDqdjPdg5EPVRIs8iUKKpg38mQ00K8ZYlYF2/NY6RTySugmVBT32ng2z0cXPwQkfEPIDP+zUDK
kAyzGUHK9i+geXSCcxHzVspHOV2lSfgephfML2VeLiiBkm6SzhK9MSWZAa13ZjmK5eUNzigJVCYo
NM0bksH0/EakV8v1TbnyUDX/lkaiAx5h2vF6vUO1VyohRWr3QZJ/Z5ogklpRXUQVXl0tUh+jqqo6
oHdtxyeqpHhNk/z/4iLNjgKiI11c0pw4RLX6wnKHsfMXu9b4spu1TwsJPPUwMDpxi67BmgIIX5WV
cP3K9kD8w28uaWBlecAiJdifjOirhOAk7Sy4QfwnVyDbo6I/RXBQv2IbKU9RVtZL4Em1NMX4nlO3
ogtAz0HP/lrU3FUFfV3iLOiwHp3GfFKteOxEbA7095ncdFZqUK4Hkmomc8IqGLxbFDu3m3YwftG+
/Rpd88bvvjehqMsqNxzXB+j+t7vEeNZTofzuMPRMuImkTaJyJRBlh567ghUlF+9o5mEQJfZ2S/ld
5WH8VRe0cfMGBDP0rh8ttn8eAtsUzV4XN9EO3fyX7RBJeM4bF+/25purHeip/J7YOb0uzzEUtgDl
w/jyAfgkne9UK5XPylAEfj9CwAmSoABQW6ViHMkYsZD/YuxGVphVOr6cp8IIGfgWV9la0J3auZiI
DewlTncnu1UrjMuntLN6VxH/C75uXKmcrlYg9h84Tj5zupMm3VIy7TKHj6+mubjaQLuvMFbuA1vD
qfgKdKs7IZb2Qu3PQdhg7+bsU231k2SdqDbo2vw9+80e7Awf0ch9UtsDHegdJKBurlKqKuUOKzit
25MdoNfuJKrY/6CQdMl2g1v3d2zrbqhBtpdyd69cQ1aQizz8Vd2pVT6j1Fqx3kJLPAFXFXC1opxZ
YX0RJ+nVVSI+3zsQr/8PTEbEW5VANPDqr1pFzLMx2abQKRz2x/n48hoDis53EBd8z7HR/8iziyt0
/lmL7Aq5nv7elW5AokzBYtMr8eVeTaKfJMhqyWZ8SXtwdDxSoM3pXDwBsEhTq4SfWvYIW5ZmwL8n
/yffkD0xF856mS9Xi3PYfuc7gGVOlkfbQ9aP9d4vsljhmP4illj0K/8nsD3QjKysaINZZ1cpmt7z
JdpllUcoblp13M1y1zVf7YhZcnU+SeJ7pas7KdYro69L2QP//nio0TdeU4I1sDZDA1qJYVydUHtw
NrzB6bbSLeT8jc4vUzIxKuhHovwjzE+o7NDVG/HDddCrmNWim8kq8Leut7sjsljVuPG6NgXImoRt
eWSQSHPbZjnBYw7pqJajkFQlUOyNk9mYwtDhmGUrVLEDQ8vMNPhf8NuWjxpdVjPhEMyXBdA2sjOU
edfQEKvpt2tpAImQlb57s1kIFFncy0x/3uTpGjD9D41qB4s7NKdRYq1aRlrlEZL/uYuFiaYhNYWm
87YWEcgO7n0tUq9PTnu7Jevy6+xfD7nb74fZhanpyhMSJ6eyr+IaJF0Z98Rz7WkOAlpaUrWXI5R7
nP4j24W1Jvua+EC1Vk8t2q1pLQGgzHIUnbS0WgNOvdp4jUXljI5tZGr5iuGbqLMPvfp/W4Sfbhyk
5X88VquXBIefr83kjxfExa18ZVQrKyrCzOW2zBMlymiE3C20ZIFu8s7ffheLP80eOBtfq9n4rZ5/
MLKv0bUDF7fHVctJ7tRVRtrVHk0/ctWWPIxsOqswDrRS7xU6vM52kWxQzBcFiAqEwT6dKaJioAqi
xzZuo3eUagCCmEQNooFmoN8/LLfjS4xpOdkTPYBaXWd5imuimC0Wr2mpUoey0j6FYQaAjrgk6+Wb
1KY92+oy1fln1QjazD/I1qiOpQ8slKE9YxLYh+7oYh4g5zUhri/xLhrRhHIVYSTkVww3tH2l04FA
mvZsjlv06hfavrHfDSOP1QUb52CuaHBvkcswNmoMoyb4peIJdi4EqtnMLDkgu2TxghMfLkxJwYth
35dcgs/RovWPHLeJLZLJP1FLVhqzvN+cZE5nu3K0rOJgpSpIB1hlQKv9Edb3PfJyteUmVE6NhNXc
2ahBPv+TRkHViTeVfv+w4LJSu/BOkXlHzr+2dIciRReY7lD0o68yzbJp9BYTO7xfLa5K2iVN3hIs
uqmFLvn6emZefIPItJquEsH/2/d6najoDl/BpSIo0y4udMvVD2SXNjm1WcAPuKZE19N46eCKGgLR
9VCCuvWKaOm/39WnD7kAoY317S0nslvML79dmvnt0ozzYfz082/N/NrXZu7AruF9GaQ7vx/DRoQO
ZuxxT3hDxjlnKhXeXUZ8V/Jxx5vB4jr/H+W3fNvubQgimxnZJNehgu+s574KxN0FgkyBBqls558V
5YfwSP3JNIEilrrH48X2h27phEMGfYPnwmIUQm1ly9CGfbOFSufuvoUB3IWUY09VzMvTvcxqgIBe
OnSMAzv6uPIwblzXlywtlguJA4+dVjKSVvmT6iPCXfkLFHGqtJ+HtFJGly2+jCOt6Q6zGWHmHbX9
fOtCTpuHuG7Le9BANVj2UL5NF7PZ4hrlOUiieTpO8zyBCSM9djqfXhmeR5A0GV+K1eJazrWEXOkX
K/TSoQ0dZUspuSf6cm7eiA4koU+QBBZ4RfZiPEGa74hz+AMrQe84jOODchJ3VoiNxCtuy/SgmX2T
Ow0JUffXOU5v/5c4Txel36ZZ8PngafaxDom3xOtwPrc4JPIZa6b9MD7sHyAMChbj/z7yAVgjIiPo
jL87LPKT+Espsm2WLxSLyPvFfKdcDBXbHBdD37rvTdVWQ5b1N7/6tscyHeO1VnJYMoon4rLK9uv5
4nqu9Gzldr5YZReZdgrAnaqY0P60FGmoaN9l6ysQzN33Uqq/YVKyiqrR3gCkdhbuQkVbjvUWXU0w
T++8fDPTiCumBquNCPHqprZ7UyUSwhdQ5EaaDm9q+McK7Xg3M+N98+NhcdPK7YpnWTaHhdr99d3X
r/BS6QHtDuY/OP2vb97hNQ2QQjgf6IfT9u0VGzVTms+kcVG13nZWejgBTfaq+qACKwM51D7c3jNr
jiKvp49B4S2gj0X5x93Xt5SJuF094vR6XH2oCPYItu9s3KHbVnLKAkiJr79mpaks/UPAnv3sJBun
8zzF2T6TP3FKo81zsbxZ0WWDcqMiavv7XzgmLPGV/GuP/vrLBjqWpXvJeC9Zf+P2BJD9h/5IqZtR
FBOYNFc4VSmcTr6Yrq9h3/kncbPYwMxGnpyY5zkEngDPJ58tVoThagEkuMHEDb5XKQ829Q1Q/OP4
9Ewcq+svfXy6byxUP4FFCcUSU/NLea0Ei6CJRwxVK0R7AZhpzv1JpBlKZDoIxjlYg0r+Q8rnVGPd
QeNyGXbo0HiQ8CTcKtDiG4FGY1N2T1JgKzVspydacF0ulsqlHHqsokvKwps8nW5mchl53hk97Z2N
RP30pXiOzx+djl7+ieQPrjipNCLIIElZOpHloa9okrhBunVbg8ZTKFQ/6px0Ri+xR+3O6LQ1HIp2
byDqol8fjDqNs5P6QBbunw36vWFrTwzT9Daqo6i5WqzQOrBOslm+9x+0Hn311SPkNsZ6pY+J3Xb3
UFQfY/294zpIQTnvLY5mN3mdYpC9XzD8I8V5/LIo/mPt84Mvn3yu4j9+8fkXX36B8R9r+7Xf4j/+
Gp+7xH/c2/sM/p+vxp9JjSr/bJ2+++yWqJDfPxz2600qlcgw8kLzmo0TOcquFuvLG9FMZrfEifRj
OKqwtEEoR5WuV536hE7RYJESqhXvSyOl7yZ04j1L36FYRH0cRXQG6hRI0RsBOyfQk/dAjXybzvAm
qHQU6+LhFPwHf5euLxdyYVhDu0kyaURzZXylXGAwKPhmA9IF6pwt1vLgHeUTmUZLqGFf4aFfvk6X
aEZD5Uu3l4ykIKSzxSYn+ZtT+DkeQQsv85U0OAbLkskX6RrvEWUUE9BejqJg7NTC3DTxYkG7gJJq
/57AJ7okKlwiz6VzADrsQ2VjZX9lC4iuPH0HiXkJ+ztZgNaA2w2ihVrbaKuh2UAsVEI2BxLNlEKs
m1AqnfZGLVB7p7RSI0XYKGLLbYBQBCBnu2SWL5SPRqn06hVjvs9UTOW9Wb40su4HUEQX+gBaHTjb
Kq4X80/Jf2+2wCc99AIu9wqwY4b+XKMCiB0ExKXSkPZydszVZg8LvQZFZk0XKOWhrjTIy1Pw3OlM
qfMpLLzXi9VrtLBjbOdEXuOUNm9a1ZCBri+xOZBhuY2ovydKJdpvZiv0fJukieQGpFGELVX78Coo
GYIl9UtQQSKnDuerPXGCPMUvnyFaeftMANRcDhIaskvYmR30MEKuefVqulhQkNgffsBT3nWi76ZK
dlZbJIA7qg9++EHOCzkdlHKip5ZtmR1/mCKHWmSkyg0TpQxGpcZ1fUKbYRbFiM+VGQXXULUAE4IA
TGEwX0LHJmpcYOQL0ePysZZdwa5L7oBJJnL5lpICG6tHtYiiM8lryVVqNEndJOxPLoAIoJeCyMBL
qBLBBBnuSlLt+jIbX0Jbb4AFyRagkKgiE4Vlhe9CBwgkCS5B48btjERSTvcu9kT1SUUOqhqgPIJU
CmJGBYUdoEEOSiZVS4Gcz9mcuFv5cjjVfV4JC7969f3Dn0C9fP8Z0GBvAdxCI2ywEIJP1biDZr2O
NEgL/0F6vslmEz15DIlXCxi28QrdfN+XGlKwKZcElEZXuKkGbXUPz/DotiWefED98oK42uNTrFvN
LzhfkLllsybpkt46GGfoWfV0cZ2+1bIvy3fkPjiZZegjkwi6/IoXCdAaQx7CieFCjLIi24UGBij0
WoxvxjPNrnjWR6WveRD40hgfrEajEbCjYgziyitYRHCVkdYtFNtAv6WcBKg3j3EhA8Q0znslGXEe
V5+rZPUaBcflarG5IC2/fA5ik7w6aVFUkwd3nLhKafFKIiCv2LUHpNpE/PT9+VQc9Xqj4WhQ72Ps
NBDxSGRcRBPZQZFvgKuTXALjKxnvEQSWnLG6tI6bFEucklqelNkGBoJ6da18sFGAqzNotYrRUGY6
lpmtZa/UYeeRBgFHT+TltDtPpwuHT8LWkIYt5bLsH9KbapXPWVAkztlifkGr7jzHx8/wlv700IWi
VbskkzqnOkHCnLWbzt/yzSonqdHrSloyPCxB0cH7Wz3t6CKqH3V7pw4e9cJjUHToYlM9wVEn+xnK
odkNuvcsrq5w1kzsuqLIeY55yBoTrYrhmNVR/SRNA+aFHN1kNb4EYY4BcLMZ0g/lQ67HBzFO0jH6
jANSufSKpKSGk0aIIjzh2rmZzeZqsSFHZhhb2g+v0utVJr1lQQgvZkaolOSzDJuVElUJhU+Flqqp
rO5Z0yHrnqjP8J0eslJD369TWPFLq9SEFeasSlMf2jqZpXKyg0Tp4Q2DdAlFk8liSeCl1LzPp5ZS
9OkEQpLowamzMO9FXOHcwqkEO1DoeVk6AoO+X9I5F8DzFSAnGicUz18tQaFACkl1jEZks9T26fMV
4Ibd7LoE6sqcqZ/UQFQ/sY/SOABNg13EeSptGLgIyjiCs8WF8giblLK1UPKeai2V1MBY5Vaa03Ps
2jQzrdQvcezYiPJSFyWKlNTiJienii7gSGvtFD2TMiBP1+I//1OuWfuffgo6N5C59CFVqhv6SHld
Lzl9lCgAB8Mtu+ZWr7OrWPVzaHEye01OHDDehq90oPwENH2ko9SNqGDONwmJXnwPHFVfrDbzXPKs
WlqwDdBF9NRTnK7bcSDOF4s1bsGWn35aQv3xx8RML9QZsvkGK98sr5MVKsRmJUbBpx4TEyeq5SfU
RFCj8s25MRJKcogjXY/KthDyBVJkKSNYc7MJBV4/h1kFu9I8cx+1EOXO6ZBkZkUqDBaUSHSdEtGB
SPPFPPWVMt1VFZQB1PzZhhgRVki5yFktFYQVaP7Sd87uLUyMBuR/WnrMDC/NFoslKbxovyJkuOjq
UwRgE0N13MiR9mIWnxLtQAA7aTp8g6cPMeQ+gKQY7h4h6QbxlyB/TMdGJHrlqqiiMaeoMEsKSLT5
QpZbpVNUYkvSFXMtebZMDpzQf1oxcxAMSEGztXEWZGhByWwMV+muVFXWl75SUtnj+761JU2JAlNz
GpfnPJI09Y00bDUgtOh0O7A0lib0YOsCFhWpbcn7WAYIlU5hYWYZqCMoPW/kizZoqFfXnSRZ8YTH
0E5O8Wz+FvQ6uiGATZA0LNGxgcdRsGkg+Sg1eSqM8YxWpLHCZL1IiKBSVsj+6yLyrAm1MHmHLDX+
X6YW5CjSKNLpuiS9vmgc1puJPN7DAoarzNYKN504n2kxUIxDhy2vDTdpVilZ9UdPjrJR35Hcjvqe
V3bE6GnrlGErWSI6u7EQW7AZyCt7ZM0ukQ2HjDUgINb4UAh6qUluzeav0YqtdFYg5Qot2LMbEonZ
WHJMSR99kkqPElkKOhTB9EwG9Nr0SNeOy/dMTm1RknJWymwDjS220IqRpfpOFSpVeDYp0cDDGmRU
P8lM0IMJGR+UlgIdySQWmcz37zicgfg7qb9sDfaNkv21ouKLPlBR+AIQzeLYjX3LEmgsD5B8XxJC
Da7SCQGZl7ILSSwFFEIPBh8BhyQP1/AYwdyUXV4SH88lEJ0CzTpp1Qk7wyX1Uo6r8RQ5R7CSjQCX
fOGakjguqSyzVjTbJ736iGNXD0hzGPWktNtH9eSzA/dMw6mU1umoM2gNGExrqFrutKs13NXJOoXe
d+btUi8+M1zqmWKPXvrxYtuKdn/oYce3gV0Kyp2FTy/1Ri6rk56vdSgtH7TlLe3gA2cShuGCxdpr
Bb4867YC1vIAZhRpl3qWlrULavRGwzbCpJyatjNc8hFZ3n56ONbpo3xKlsPIR1j9dqmnWVkruvTk
HS95etrx+tiznWS41HOnDJd+ANWOLEiAdm/QZTD9Toy/+oNOtz7gfKieOA1TGHb1WqnXLv2GqYWj
R0YdeslnR3mv6Z3OgPby9U4HrtX2qKOJ4KbshrgMmE3xOW4QcJx8dtMfR/UYJ6OOJYWb4sBY9uW4
Rj43DUd+r4cvu0e9E54yitJ+FND+rN30+ohvU7p9xEcnVdsZLvm2JK9TvTbJekQvYjptl29k+rjk
U4tKPsqFx6w7eFhrViOMH8QWokav/1KtQbSYOWsQT5E9NilmDeIpVj6bVLMGsZRdXpKvG1Ip8dcg
SnXWIJnC1yCZEuAK1iCZytcgSnHWIJnC1yCe4vXRWYN4CqOXswbJFH8NUqlsDZIpfA1iKZyCwRrE
U1krnDVIp+y6FAzWIJbK63TWIJuyy1sarEEy9dRvhbMGqZRRADOKtMtZg2QKX4MoxVmDZIq/BtlU
p/3OGmRTHJhgDWKpvF3OGkQpzhpEKcEaJFP5GsRT2Mg6axClBGuQTOVrkEzhaxBPYdiDNYinMjhn
DbIpDr2CNcimunB8DZIpfA0yKbshLr4GqRSf4wYBxwVrEEvl4+isQSzFgfHXIJk68rnJWYNkCl+D
KCVYg3gqo72zBukUr4/BGiRT+RrEUniPnDXIpgRyNbIG4WqDy0/EHPWxRqhkvV6l3uuqQpTro9Gg
dVwpTS7lQ22+par5tFsH4fCiUlpcjZO1X16Ue91KabnCC9BBFkwcNHEtYTGdT+c+5j69sn1aKUkb
UdCy7vDlsNFtBiYysyaz5dhZip++7DtUl11kA9Noe9zYOhnVj4I58W2vNWi0WLlve6fPWoOR5R/V
RCZSmq1Oe3R04i52SgQzmdVt9E65ItDrNlvPeIvgH13Gk0Sy6Tbh1OmJIqqFGPbbEfYdvey3HIab
YJjWKMNVP5bhsvUGXUMCruiM2menNUFfB/B11j9pVUpXr9F8tZr4XNL9dtBqgOwGNhpvVm8j+Pr9
xtngWUv0h/RdKY0X6WocAcROCzmoQg2lGLSAYI3QDquZrGqZrOow2enLqqdF9UAK9Rtcoxn0+qOq
w2ff1SKjCovQyF1NJIkcrYCo5aYg4YI19NujBkA2GI8qAvKUMw/mtHfaqgb836+bWaFTTnqqQyZF
Ep+vhEOTwteXVv3EW4daw5P6iNNLjUWY4umOw9bxUee0WWNM3jr21xeY8vVula8vlFLz2iVTD/hc
qBbPhdod54LmnprlnhrnnnbXWTraXRgOJwE4os3lQ/tZoKg+k2WsTgfEcpbc4xdsCZTNKe7ZwcfO
8ovVJJ36k/Z40Gy1C+fUgaXKgTOnjt1Nj6tDHNWHSmq5CR5zUNUWCPXYA876ivENTQ40TT52WZ3P
k3BdLJ92+oPekYD1gL776hsEAn2fnnVhxDAbxghz4avofhGUgVwUa7PFyq+n0TvpDUS/ftIajVCK
Jsvla3+RL3fr/af1xrdVoX7U9I8D/NH/9riqvmvq+wCkbbJKrqD7wapdH9CUF/Sjhl9D/fdQ/X02
aMvvWgldJ9C47aMZnjWeVkqw8OOdHT/zpZyVhQz0xDLQE1coq60uE8onvYEjsEBMd32Ybh8Gpe/y
EaoELj/KFM6SrSEs4yMuZFovOhEltl2HrY074zsnLVfktzunnVHLgTk1GwN3seiendSrbOo35arD
lobWs/qJFN1uijdXgAWPOo7YPOn2mmcnXJyf9I47DXc7hymBEqt5jM01xWxByoGTguznyTbFjHwj
KNmSp/RO602nXZQStEtORGcLCYudSy85Gx31q9mKaE1qNjt6W+vUpQ4gR4ZivZbzN8AlJQHHNWgO
W24rKIVznJro/qZSzUmmF9LkdBRDNU8dmKGCcXHh/HXqxJns4hp160deCqzn/uIKqaPW4JTxRN/S
1aZ4dBi0+sPvAr6H1KarjAzaTW2k0CmdIMXys6NAvPDVheNB76wfpjgb1H690Wr49Br2T06BLxxF
o9V3+QuFnZsyar3Q6iPfVDaf9Vw4JQn5gvWkeBH//GMX8VS9hlz1JbEUG0KJj0KB/LkVyJ87Ahl2
ju4OmFKc3ftRIHIa9cZTNRO49fFpfXD6N14SU/7mYG8+qw9csapSPMHXOmlplctN4dbH4ajXOxmy
iWylqoPLSFYjolEAOO1qBwK5HRXIbTuzjDqj+dJJcS2GzX69G0wYSPWYqXPaGIAgHbKl44VvoaCU
QIh+C7O4dcIF8kn9xLMrYcquu1B0Tlsv+sFC0Wuioa/LFgEU3M/PfOH+/IyNRnfQ1lsnLtzrxm7F
UxzqnA7P+jVXRNeHx/2AXj1kFReu/91Za/DSFdGwTnsiWtvXXcHXhb3NUyb4WoOuZzE0Bko3ZdcX
VkG7bIeMOIFJ5WJXKR5/nUl+ZiUlKiNcPi8ULl98rGyZXi2CTf3fgAkqpXyxWi+T14FqCJuffv3b
QmHzhRU2XzjC5mzU6/a4mfbo2FPhKMGVPoOYZfVo4MM16oNR65QJAxQ+fWl1ZHrkSetFbc876Gi3
XvhHJJDCeLsZnL+0TmKtap34rWoNPSNEy4yvFRdA6wAVpTqonr7suxwkExxr/LcxuQyIPEt7INBl
Akd1Wh/qQs50Hvom+rp3eqWYg6H6m+yfYeEvCln4y49l4QJG/NIy4pcOI54ct4CDbC9UAuvXkWfw
ORqFk7Xd9ZQUlOh151Sr01b0McOqxLIz1Fowa5o2fKL2B99JflN/f3em2I+LoW9Zmux+IaH/8LGE
HiehARBmHsiKKciKyDZbGkoEkEooK5poP4Pf3RH+Awu6IDtJoSz5gx3CP/AhPEK9q+UMUO9s4J6j
1gfu/qM5qD/H7Y03/7/zZFC73hi51jdsrasuDKJmwkHdVenbg7NRxzn36IzqL+WGV8+8k14E02ld
r948wREHvbrWPPhMHPoLXU9rumw99LY//Y4+Y9E6ef20ORz49qyz086wdczKvWCsLMeqkN/++LH8
RlHbAo5rto4HLeA5jH7+Lp0sA+dd2HALnIyCNC8h56VQ30NKPcZDEXrpMTCgDEAaosVZhbnx85XN
U7TxB3wPcGsF4HlgZUObKmQ3kesHp0PR7g+FPJEv5Pc/Wn7/oyOyugNvICHFOwiTZOG69Uk/wlwt
bTNmixJp0mwb2Pa5i+SYPBLmHI9n8e7MwBSHUdsn/vyK+i60rTLqpvCTfknxIMGXy8PWoCM9EXSK
OavhKrnTKsUbHtN3Tsns89JWeVL3UfXMHDZTbPRUaR7O0RCxFVcw681Ow03p9t0R7Hfrw2GgHPRJ
PnFtXzIZ749MYcSTbOqTHcC0jDIK54uhq46/aHvS6G8wMs2WtsdJvi2c+9WPPhCV962D+ackmNCS
TCiLjv6uCT1qldJ4lQTL1aDeh0WgArJlmmxm6zyctf3hd4LMGQJ4FRUaAF4l1xFVGJeUxgtY/VZp
YIg96fZgvrflvBFtmlBCWhqF1AuEnlVCzTdcRjerLA2syLRjFYqxAUpHmfDhjpAxoLlXaX4ZGJlb
w6eQs0jPs01QsNtrHXXOAPXVCh9s93NR6xO4xauUFstkFgL0mj0YgD6ZpdfLdBWYjDFMB+6xAOJi
tTifh33sAwlaR5A/W6zXi8UsyD/pjVBOgaRN13SVz4c4Q5GPNhoAWa+Tm4g5fjiSK3ClRLEAko0P
MKofnRydAbHxR6t+Vim9zdJrvKzjQz7rtJ4XH0uyw++qe/pd9TcTlOLIzPpgUHP1T5XiO6IN+wdP
HFxHR1ovMinEEk4KCR5fEtiCRoGSM4UvKC3YcJ9xtasZdYaS08LZU+1Xj4/adV5yv9b6q5dy0K7L
FA9X32l/2y6GLMU1baiJ6+GipcdV0QK7Ytv4AtgUvYlzTUHaqM9SvBW5bf2ozILS1LZtvszYEdEp
g17PdTrqDPyd44k23rgOXx3fgitT+A4DB82V8ZTSrXtnLCTCXLi/GYcfN4WbgurH3XrAEyh+XOoo
mePuQ7VKYVN6oSmoa72mdMroqWesOW2cjlAjt7hOG71m55nP96dn3dHZEedp2C/7SrMdSJ0i1xqP
v9SSxHHBOuLOZJXC99DPY2qaZQmbQtZ6rrrXRycDR9PRYtYdx/7R8xPPUaB12lQTXqcct7xeS4Hs
06vfOYVW8D5qwcxwtX0K9rvN3vPQDDcYdUYdvkHud40jpUkxDosmhdRVX78yXmBOiiNXv9PuhDZF
yzN3L40WbkeKDlu++53aDDkpL3rtENdIyVCW4u8C9aLjpsDq4/VxBNPRNTaTN5FjKFcpjL80e7vt
OgvMz3KHx3uNS5wL84wOWfxxlKlcwrwI3O/kbSLrxFHs0VT9aI8mjBt2E5yRKPdQob5rghxzUAcb
DOovhfrq0FdVyK+Cs36ZCVrQeXIR6FA00qIuv4ixhFowxdNWvY8OAlfnGGM19BHoHnVOcVc4nQb+
fZ0BbAnabVAyL5LZZp0FetFx/QRVePQtWOfrUOXp1kewvwONZ7EKdFQljES93z95CX8IZaMVlDHq
4TcG6oQv1E5RNTsItuM4/w/Q/2u1pluWIf3lLBfDl11kC9TOYl4FaiURjSGJk6GQZ2vqq6q+a+r7
AFS4VXYRsTmpoyKBfoaCzrOEtJUKNTeEMr4L5a5X5Nhxgp55gpwRhXTTq5TezTDSfkhjWPLEyXNY
AIRcbnHrcHIsXsAa3f/2WJxgxwXJYfECvvDPgmpxWYd6YtX0zG6iS1UAUV5QLW36l+YcfA3EiybV
92JQXM8LORRF+iv3q3Md6xSrWPkiJ4Wnv+I0cfXX+svgLLtuhaPRQoNrE4E7sZ4u7hqnuca2C3TO
dsPRMFv7T7quFionv9+utj09UylqkrGSOKVd2dixhOC6ne26TrGVGq3Qd7+GlKetHp1tcVxKFtg+
ngTO6SegMbkah0rx9g7ErK4OVfdbIVOcIwYpTAK9B6UEL6nkh6v3eAelUm6EOoGvf/dhug+HPabJ
aUluU4Au0J3WwO3jMHDwHgYHR+YA36ZIMeWvvUO/Xda/06ygff86xJlVQjyHcneMVApbteUUdlZQ
KUs8XC/afrtetP3rNlriMOwGuYNroJLtMl3sbFm9q7PlXY9rqswbs0rumFoEdEauTtjsDNCcxsa/
I53g+ZziXvua532Sngy73iTGFNeDVk6CmoOoH1yXgNqDA96u595ZLfbvrH60f+c4Wa3TYM2l80NB
R0tCHo2qL9BdYMmMuISq63A6Mo+KxiPU0ZhQzpxCeYOomD4FS5h0BaGvv+kwQkLdMxPyeFWo62RC
XSIrwCSvhQnaFQrpgieUYViFLBLSsCYvGQnlH1e0tMqCqgtqLVUnKYIOUOS/Q0EuCEKexBUgk74G
Ql1vEtLRQKhbTEK6hgnpMiD6belH2vFfpNQf5QdF8ZUwppKQ7k0qAJJAlyUM2SSkpg1jOMum04g3
Pu1wROOk0yaY4GgEckgRhaL5TaDBNnrY7JfDu9w2mezXVgvQR+eBUtncrx3BKivw+6n8bvxVfqPF
B7VcVG5qgZGzjdMTGDRb5QFDdwbD00ppvrnCwIK+L+8ZUK9FuW82SUATyP7urI4Karq6SiJTBbR/
3DPXoYJlnm4mi1kWKrHD1lkT+AePhZZB02G1q6FdMqCX9GQTtDXEf9GpYvYW43MGVOv0hv1ifYz5
ZFddp2xcGlvfMckjJ7qjMQE/uGIO+SDcE+rxZzoUzHt3jdMcwGCw5cFagjLac/WSKdyxQnIKh5E8
461xioMcve2F1yNM8WyAkp88XO1Tc4SjdTutAVrdzpyQWc1reBrSC7Twk4ZzD6D7dNB7Ls9wVIpk
Tj4aih99HarZkpTnKZ5GiyLn7NSx9xDfBjpUO/DibPs2wH7P3Ocz9hLJ4q4O1R/1PR0dmd23fIy6
p66e1XqhSehe5vCsdKBrqbN2rgn1Bo7TU/WgeN188tG2gtlsGjnd7Q7qo3a9Ibr9QbsN/zb6bXHc
Ou2iV4CApDq2Dh+vQNsiCFkyOQTyQJnrRUdp/0J/y69K6Tz9EYRncHzT+hvQAHIXi1kaSqpBqy3I
uVuou+Sig6qRwH+gEEZVCzAOOicnIPAnoYrQaTRRK8B/zvr01cV/cXWYr/FhxnB1kBZVoU2rAEpB
wALAl42T1lCgByX8lFCL9SLY8CNcb4T3EyeT2Fg0m226+qW9XwMyt74Tre9qoq29X9PVKrR/tAYD
tH5ABTHrCdSAGzvRPxs+fVZHuGnMjaUP++q2QBkjmid9oW6hw/fwpN/CQoE+1W63Mf0y7Ha7/RT7
LFfB+CIIuRjqLsg8pW3/ab3bIo+bq80sON9U9w+EvoeAh5MyaHxgb+kJgKPLzPJfoCQOL/SIvsmf
hcxOODjBSRlsiXF4zggCuxKDwM4gxHmQd4Sp6QaUlGDBPj4Cte+k00QIikUartlHZIUGZr2YZCt0
5IicEqOoFL1mXzyF/4bwD0Cn8zT9McDWOm21/ga5lxjtPzSwPW2dDlswiy6WF+Owsa3TPmiimBue
WZ7U8dYx5K0W6Xl4C+uorbLysCgZ34dYGEiwCsoOz45g090nJRZXCUEWg8FogD/kvwMUQPAFlWQT
Cj0WOsrQKUalhO8Hg4wI+B6ETBOEAszBGTrbBAikI4BQDgEEhae7ARh05oiy83WEhE9bZ0RBUDmn
m/BQG/dRUIFQGzFBjrogUuHv79pCZkLhaTaPCnRQ0qUYucLna4NsPPnCY/G4COpqGQQAV+EUkr7S
lBs9N5eul6LVHQh9tgXAoc/BsAtiHIU4vp+Uv5mGRtyzk9HwuzbIp3l6LZ+z9hVU2ijQqi70jSlY
p45owyDkKi6U5wipyuvLNBSW2u4k+uoHgC7xIatAqe43eniFcHE1Sd8Gkw9v3Qi6My3kVWr46n97
jOB5unobHt33usPW4FlrgA4EkyxYepSrjJAHpUL+e8T+GOhvoIFMR6+NZZzt++RN0dfMv5yeh84I
7aPBmcB/MT+SPYDMQR/XwJhQkBJhKcN7B5nyBK0u1A+0q6dvwh3HSes73JEsZutFRLR08XIf/HMA
Y34y6pGYiS4oXdEnhQX/q8FSL/CLNGP6jVzVwsvZ8A1/EkEATWQRrAMX40m7ULE06Bt2FiMhQyuo
rxqyXxdUCjwRCDi9PwAuX8EYB1ulAYzaC4GWXWA/GBuY3yfiaetFHX4L5aeERdexeSq1NnTam6Sh
sByACBvgzi2Z4euvMT+9fZm9/yaa+R3m5rEpDkIYpzjkB7UqMn0nUALTtm8acUjpnTxrtVFBIYjI
zhMtUoLMUvBvH4Ynv8rWgXfPsNsZPSW/l3CpGI1g7wn/nDYQYBM65wyfItpNkN4ZoifMMWzvWshC
XezIOtzkjnBfu464QOEJsyDXaXEkfw9VEjrrCumsIvRZNOC4XsQG9xRUGfT0E6PnPTnKm3kWAzw7
7aj8gpl/ZiY9QGRvY/mdZ33p89MMhR6eh9LF6bcU9jPIlkZcoUyPwvmqCbX/Fcp6qb9rsrpaM9QA
YAoctwTWWgNx8nYRqkrP0IKFl1orpes04jj2vNVBoXq9jkiQ533Re77F5MBu8Vbda7zDvnetAVP2
nQ0gpNSe+ClPwi00pH4elPwiwP7lgXsoJHVPbwstt0/OcRJJEy8F7/ayDedR7+y0+bdBz9326kXE
br5pK+W0ArdLnlnlqbkL5JhVSB5yE03Pd05pPPMt0Xp35B1z0d6K90hqKE6KFJ6O6cU48jgmmp6O
lOUa1p2Sw/6Jc1jV7MbcVZr9rudOgOcXngFIpjgGoGr9rxFzT7X+rWcWquKIeyndIKUfxfWdewgY
uFK3vvPNPbRnDOilNrQc1/6T5rF/xNhu+inHjaBdkPrXumfSanhHjO3gaKfdbmg/FG7SgtQXnunr
aa/rpZweueODKS+CPsr9J+cJed7olsRdrwNzfNLtNPre1Qo90Rhcx1xtcFO4l3fnNHJLRqVyuLYf
S4tc6x3XJNoqh30MbkWozTIvqbwHGYycrz6uUcsLVyB3k5w62n5k2642jV4f9Y6awakdNEsJTJN6
t+zSHvaWXh/1npnhkhtb1utj2KWErutSAXB6JJcmXlJtVy32p1ZQMFywDffapVQ8hkvuB3l9naO+
NoXy4/CAAzrBUWEnuAbUsWLbuY3b8lz3OvbkXqfIvSaHoT2ob37tnAIZZQ9Mis8BndP+sHPs4FIb
+D0/BMQgcA0YtN0enY70hLQpo1B+kTrnlJT2CY5d7/htS+Xm3e/jSQcUTicMgbkUYFPM3SaTIk1L
Hn+hWuvOIUtok2JHTafYhY+b5NV237a/G8TA7NpIdjoFtzEBvbpd38VD7vcdXMr+wupDm3GIS4d7
4CkHfoo5lDcpg3YEl9ztMNpr84BthdaZWQrt2P1xPNWOGzZlBM1wDjV6wZylQBudIKYjpg46TKuh
Xb/TI73RtzCgaLX6AU/o3bwDh/t81q5+cI+/34y55faDdRQ39m6vacPv4mr3IjJH7vo5B2hBzlLU
Bp+1HffywTjCZtvTkPpdE21Sp1hHIJ3SM65IHJcyAjhwtP10UxSjsxTlae7ieum6hytzAW/XwI8+
2VcM6PVR2tVZye9gGR86obCk8ZnTlGwBAS61yWclBw1zBc1N4Refmq2ILKRUR4+mjb7Ta7n192Fw
x+7SS9kAeCtao6ErVwcBD+rDJA+X9cJyU3iPBg0voBCmhDFDhw1/9g3t8mtS/LmNy9IgkBNkX3Bx
dYOSXeMkpVOUdcPtI+wovNu7wxGsh3LjYVLQXsEpqCzeHt+TVcJt11nQLnVaZ7GP6rHIF6DKnY3c
OKUtX/eFlJHSa3WKuTfj4JKmCtZHZZzgKX2fJ+RBnN+uMyvWbErnmbPWouXOpb2yxnn0wut9Ln9p
E6DFrswcDEaaIPx2Pev5V4fJ3OCMxnPnmmC1ODhO9aOD40yWi1nEXKkiywiKGyIoSodQO1DRRJsa
qbqQQabTqyR2fV1OPaGmoBjKb+kIHXODFhSAsdikwuLwVJ1APM2Od0uWEty9eeCrBiyMw+lOLuD0
rtw+uQn8gk7Td4s0Wr8juk+8K0jy4MWRar3OwL2kMoxhGhqh5iZ4lxRcPYo4tVF3e6cSdx2mKg6K
Uv3oqCjpdLN8F1ivW21sQKU0W0wWgfGwe9ITeBlYyItGwF/IcN0e/tOtlAA6CHpaljGrBH0dCLrf
Ucw9LLBK1YmsghV4rNFWnGG4oI3B5OpDzhew56n7eoRKrXE4HaBEJwQBxNvD2JXuzlFdjahJOR25
uvm3ASdSShi8zgayZnr3cYttZlUCY6lT22Vn8UFS614rwhYz0EfHJMF3it6FYRXrrUopuYhdW8Cr
DxRtXlB0f0GxcASF9RAU8ENQqAohg4EIMt4VeBOS8BA0zYWknKAhEoqOwKb0JxFbUHDlIv9Liqko
OgQOxIR/Kaq5oAg8giLjCIqaLeTlDYo3X4CMrl8Kuu4qKFaOoKtdgt5KEOSaLY5kffhvRShKhZ6C
dI9T9sl6KBQ4KNABeiwfdzCtoaCrlkKxpjp/nGXBGbY2QQhg68bTzqnoP5dzSvoVBshlPCmh7jwD
xMVqGZ6GQS463faPW3i0NZ+E3iIqGocYYOg8ISNCChlIT8gIeyBaLsbhqc8xuifho9vhoRU65ooG
sNkQuiOdsgT7oiUOzyQOgjMJVAQOikN+V1nInaoTc0fWxgXSUN/FVQnHxqavpQWsWirFlSpIfnen
2+WmO9iGulEUJLcHy1vLuwuoBoPtjohB+KZHDbmnsvtBDWGSe2pwveV2DRJA/ff3vDhkTotowjn6
6JEX4VSOhyvNiuP+VD868M9kv9qXD1ZGPAZkPAV07ggy0btCmH9q9O+B0LeNYeYT/y4D7u3026Lf
Vrf0A3+R+vDp6IhcXurwRXclRes7TAL2xa/jofzj6KSYVVlooeof3PBQ3ngSap5A6HmCatGeb7qr
H/nLn4SyCcq5UicYUwXD823dO7GSwTyd7dORezIlyeCxF9HJ5aZGt09Ge8Y9xVF8qh8dxicZxxRm
vZkW9QaqmrAuzt4Eh5QUYECQFVeQM7L4rgWr4UjIG99CxQCEwvPA9QEDyQoKnS7qpy/xP1DNx/vB
cgJLVmMfL0bsfx7N+hyzvohmfYGO8NVCR3g63RLqPEuoMyuhTqqEOpsS6nRLFN1DxBUdQE4V6FB+
H0sfe7rjRu74BRO0R+Y1DHiyfwDZ89D7qLl/UD/GhyAAogBJ3yBZJdeLZbjZwlD6QgbUl1/7lVKa
XYRup62+UKH5AGA/uKwLVG3tVzErNkwtHKZ0/0k06wllxbsIubKLAFFEp74SZNPpOFgx8YgN3T4b
xy/oX3LfjPhuQuYL0Wm3BXl/ZhHnWBVZWuC30NYEoY6lhZzrICBBrZjOFhFPVBk+ajoPPT97ww65
3oinRwK93GVQtkjUmnajX/+2KoBowz6FZYN/+kJaP4TyaZeF1zdhJ2E6tkd4lxfkCX5hPJplsop5
DLf79YF0FA5dqNoDIeOjwRcM6nT/y8igtve/RBfPmF/TcRO28PgfnjORh2MSCA/aypD+l2wiF6tB
9atR7ni2CMZJ3t8SahMj9P5JKBVgKPT2gjCkF6HvhTqWwWVKnJ52RL8jBj26ZfI6aKkKqStk5AGh
IjkKGddVfUFbZ1egnIZemt1mh3wUo1d21NU4ob4G6nv4nb7Jc5XlwcgN6z30RnyNkYbCftElI/lV
FTJkv9CPVgj9wgVmSE66WkwiPnL6lAzy89DzFHcq0h0yNvjyNjUapQUdmgi05+D5U6U0T2DnFbSZ
AtYKFbZWUBBaoaJZCjqAFuogGriRvsnRcpKsg1nW6Q9g1f5WqMVTqPjSQhk10cUx6obe67YGg28F
fWEUJT//CKYg/FelKQx7WeDpyA0BWLehplYDv5VrBsGhM3gwf8667e4IXyrGgcKdzRqtXJdhgATS
J4SKES5UVBEhYx0LFfNY9Lsw2eFfyYzFa5UM9SFUlA6h4ndQ9TFXbhXVROhY5PoHtQOd+pd5ZLNM
12rFmfoaya8TlUgWTiHfJquU3gA/RBhMHUMI9V1DD7+YHFDHLQJN7EKdLgiye4lBq3GC02SVLgOa
Dlp9WMWUYhDGGINB6YBygi8fHeGNjwAChTPeKAtWIvmUilDPh+A3/lcT6tEV3O/T4ytChvNQX7XY
eOl40xRRK/RJpqCGm3DT2hmeUZmbPF/MAj4evhyCUoc+dMkqi2nvPTTEwn8dUtsHZ7Ac9vByJ4ap
wigR+EhEsdbOAiRW3QiJDd8ZAFK8eExS0eQqcP101AG2dhV3UBR9VMN+1T0RQ/+2L4OUP/ibTIzQ
deCDPfmjn/L5537Kl8FpDib+wQf7g9fBYf+PXorkMLeDR4EDDEoet6AWQ3ZzgkcQjSDsgkzkPl2D
uhc0hsKBOa/hkIbo00qqjY7JW2q9bKej9F8nhZRXt1Wt4GRFKYDcAEFakGPYbL1Q0Qdc5yovwkI7
eP6PtEMP5jT0mQD90CO7dU0wKUpl4vZXXcgx0waOVIPAkSqIWNA27wNyVOYhSZOipqJFddz0zx4w
kK58jdF1oqm7G1GpJHBaKbWBb4vliuptnoMwECR2XFsxrUQcOejNYQeleuSA9Zo95RCprccmfIBJ
kdqL26qufgDEphz4LxTK3SRHJTeRHq3k9tEDA2b2UmAzFKT4Z3py9+OBgerspXhns6T++yx6OvDf
xpBaBEfVa/hD02tE+ErtOz3DnOuJQ9qQM6ZSTfI62LOXUHXK0H9mVKkNHCbmi6v1F2bl68oFgKEy
bjiOJfDEEzJac7CopGmCd1CqCG5KP3zJDeOnnDgFEZF7TqtSuB9AO+IANQgiYdCmw+mgUj84jHHW
5agCf129WnNLZs8/85eKiIvKzhuTIrVYbsX6zr9ZPnzekY80OKhedv0aaS/KqaeUEIb8zLxUy08T
RyY6i7anKr3EtkHv91wrmYp3GzOT1T7+BdDZReycQtvBhTIjq2vIQhmRhcquUPnIfg30IAH/DUUd
7yvngcaGyo0gD376t0b//hH/rVFK7Qn9+yX9+wf6l3IP9mNKJWYQuoMD+pcKH3yO/9LPJ5T5hGp5
Qng+p1o+/7wA2xf4D1X+JWH8ktB8KVOoOfIfwvJHur6cr5Pwglynjrol5MNYvFuFQdi6/ZMXeGls
vAotO41BG8NmRN63LJM2INBVULTlJdrG0zqquINmu01j08ZYw6vLSMAz3G+2YGultFAB8vEpPquG
RrbQwiaVKIE/6B961U2GRyUrZGQL0SRT2jRfrzbhFl9evRfSF0a0QA8YnDVEB4OjdU/7Qn53+qKh
UgDTLL2ar1fBdhyvxKSz6SZidztpn+G9xvTdEv4fXmlXLgy0aRvSVckXffg/jhPAryLBPlBHo2gf
6f6TArsreuW3j+tC+eIL5YEvlM+9UGHA8Pu0vt3uCiBnZF+dRunbRvpOo6bK9j5ZtWKmyjaaKtG8
dhWazOjZQemyKrrEkxJ0FQsHgIuGaMunFQbA3qCMiCEZ9KTkFOidLkitBSxRBwS8pz+sCtz3g4Ro
D7HReS2y64Ms2vahhFm+DqMfttHLisTQRbLJ82nYteP62RB094aCyMIeqc0E3V896eOPPj3TI9TT
LfqbrhhSbYVD11DWN3nnexVeKT1uSHsPXrwhoE30DLl1eqZ6BRAhVTC/TybAaewWuvZrQ2MZfu8L
+Xe/rX6gcEDzZHgAdjo6RmhQfNp00KUAw9jbzaMTugku/cfr8lgMDVholozhbUlUy/C6H9QG0uf1
4m0yDgn2LehTjU4DD/rCWOedlvhrb9AEHjyBZRxhFpvgWvBJW3rOhGfVGD9E6DhvQoW0Eaimt9Gs
OQ8DGelXOoR2YUVRC3oOyKthpwsCBOQX/SmNiNF1VTnlC/Seph+IQo42WRGDhRL0vYYgr0oExS/a
dWFYdLqWHRoq0b1a0AtXQmlT8Bcy3HyWzSO3/qXjqDg96ZzS3f/55ip6itJpD/sDqZKetqCGAf7T
wCv4WCLC7qDGtwadhtCPoBAgXTmNmHfxWEDepZHfDTRGhgSEoeoB1eC/BtrPFmiCD4gm49oIeShP
762iSX6xTOdXSXiNFdR/ElaQGnnZlHYUeNG7Za2ZgeylEMJCeVIL8rHGr7YyaI7wXdPlNLgE3Kb4
gehm8Uxo12/88R0IRWw5/KSb0RFTYl9F6TqGESar2XKVXaWzuMMJSmw1dpUSBjYJDJNSzxd0ykl/
kHFykkYns2wnNB1nNQBFonpJV2cJg9bKbDwGfTN2TIjO+zRS6AQCkJvQeoc7AAwXS9/4jzQTZhcB
i1LLOsenQl11EdKxWKibI+gQl46z8NCm2R6imqNe0RDqOgKaIiM2SlIu8LWAUPOQj5oI/biJ/lGj
uLGRURzpURxR4Db4pw+zZL05D681nx21hHZYRI1lQCkqknilBA2NKC7QVNJbCiybNfZiQG3fs2x6
Gx5McWNd1QP3cus84xgRUR91SyqxaXc8Wgo6KdqT3MU1dJ0/9TaTpUhOYTss2lzEjJu14BrwQZhS
DVI+j+F6EsA9Ccy3XwbXk7+MGl3/4LaiYW9bMROoSy+lpni011oNg5N7DkYdpfDwlIGxGnJcSidn
JtX96vPjEbdpNfdrnsmzuX8AMiC4IisVCA5H+xDHEkuT0klROxDP8CpVaoZLadA8JeBVtffw2iX3
DrxONYU5LrVdsHRQ+wMfl5qkLpzLE+3ArtWGxSC0GqhUbmmFFA9XcKVFLaQ+Lh21lqegLs8tu0Pl
zsZSzvqhZ5zSRZyS/ZY6FjEp/isSUq/357bW1W0flb7MsGvdmMGQNhzgGhnrj06RCyXD1bGiQ6ec
tiJ8r/XoPeZD1fZi4mvNmsNIpXsv8M8KLlJ6Tx2RuuzDHO8HckIr33uub1fbw9Xv+rhi11qDuS1V
a45LKeOMgid2VjnXNP1XHUipdlqBGru7vkgtzB9HuR3lrdCKs22ptDlwGEoJIn/LvbMH1w7M5m3P
rN2I8YRSlhktToOrEkr9ZTC9hrFIcksz6bK8TqmxeimkINleo0YatgvEUk3RUacEJnHQKr3xQZUz
gqvT6LUGDf5eBz4N1na8U7u+niDfE2v7VxhJteE9MlZr19g88p4Yi1xFJaXS4SapZnLsA/3qik2R
qpYnC1WqZ272SkqNk7VL7vZ8/hra+/s6Ba+iDfnF0+GZIZhJMRfYuN+kUmRtSW0a4ylaidIp6I0Q
sTjLVNZHbfliKaQocgrKlJHnXwqp3pXi52cj9v6rUivJUo1AUWP1R7+1gVEiQ50bA5sI+VW9Lazj
JJ1GTRTNVltZKSREGFkJAy+PRqDcS1DcTEyyt1keet2o6yxCX2sROkCroGstQq3l4mnr5AR/U0KR
UYmWeTK1ojkuj/ncgPAbDU7R4DndRPYkbRh/admMmTWFlhi0p6gJPX2FmusqQf4p5AlstK1aWsiq
YtY8qkDa8/IaAL2L+PlhU/Apios8XWWhD8uxfo2O3N9WEVfFIerKsNvtoONltiIDcOgGNqi1RWcw
aNfQOpQsZxEj5Um9f4JR7Dqnz+gnAm5WaciAanqRKxCG8YZvcTZEz7n5LBY4GmZVlQwXIY+pEENC
hwcS6s670JNRyONMocP04g/oaZx5eniD85R83Tew+Qy9EdXFNum9RE3XZvEaxUuLWoEGaPAhIw5A
BHtjFHgDjHudR1hxSJyYxy65DeUdt/gDeuoFW6QC/lcr3s+yF0Rqzgsien6zvYuazyxFTWxnf4Mz
y9frcUY5MlwKH2fX8MK8KcF1f6mpenq9Cyc52NWf/ajJep64uI6DN0i1hOEaouRmlgJzIaLz0uTg
rVDzgWt/aFRxPBpAz2tFwj0gxzvt15xpWyH52FnBrT8NX2MVg/EV9cQ/mtXXEPkKGMGlJixfP01B
nqKA7Aq4xy6C1oofq6h99GMV8QPT2h/lc06x81Z8n6ZNy0SRu30V9+VieKo8FKfTeXjd7PQIzwZm
2VW2DsU3qiMtZU0PhCUo+GQ6r9K/teKQoTo6KECs0piPpG5ggT3T2jHjxQct8rBEve640YTvJuwg
vgWpEwcftuUD4cMBwcE3lS8OaoiWPFiHo1ZsYk7YSFdKGPFxkoX36o4bT+udU/G3JoEGciyqKmnZ
xl4qqdW80Hg117uPuMFJUePv7tMHoX8JsYC7U4PxdOcEjXMAUwv09FPj/mDntI7CYVIkRbjOL0cu
0NNpfLgOLkfO0cqRQTn24WnMA0MPE5MhgwC7bapOgcEP5aRmZ4tLja0jI6JvsLSzeTKTAI40GF2m
eSr/EJfJ21TMF2txA+xznqZzASre7EYkUPTmRxAjoA+KSboENkrnY1CYxPlmXaJSyWQC+dlcJLPl
ZXKerrMxVEdv2GLq+jLLoRLThD0xgpQS5WfzCwG5yXKZoMKD9U0oHnq6V3Kal8xmqnaxmOu+7kWd
TCL+1I1+p1svlgO9AU3cecHMPan/rXuAAPHs72BA6cipeOKjfBi2v5PyoWDGnrRewMYLBENncDaA
L/q3WP9gL2bUnBczqK+uHYZQuSss9Yivp6p2d45Kyjh7adlZPosMcjZfdNAgZ8/6ncf5qAI9820P
LbYLVz2NsfQZaO2CBBcxJqwBxDvIiHg1/XyVvC8NkvUl5K8vk7kYz5I8z6Y3CnK8SpO1hQU2XS8A
MBXpuyxfI1eub5YpNGANzJyWronJRbYWgBBY86uvzkADIuLTMJi/+EBgMOHAMtRut48D8YWJoS7T
ej6SwbgcT7pGL/BqPGtHol9iYtWHPNZ+yX7ifgB51hqGpk5M9F/QoMR2NZboNZ4SofXeUPZQEJAw
UlJCSo7FlAaEeCBHITEBbWZ1lc1h2PQoECSNABmaFfVpJPaPer3REGRv/71aUWTye/Ozan/W7M+D
97rN9OeT97bs5xbqC/vzS/vzD/bnH100VV4vVKx/1uzPA/vzif0JdXI0rN7qlxbqD/bnH83P2r79
WXXQ1Fh/a1SvYWBTZB8Y7eV7Oe3UQB2tFq9hXWiHiwcIb1GfTWAi0t8RsfwOvkD0J7kY4Y9Shhfw
c/xbdOZvQfQvVgNcWlbq+qLoPBu0TpugPOLFOwQT7cXqKpm11XMP9AJE/SSG6Bmk9BerNeDAC+Qx
kGayTobZ/DWANOujeukSYxxQLQIbkE6eIquts2Q+hOUIFrxUoNhrNWGRmGZLCXqaXAzlIW9bv1jf
wZDoU9jj626QG3ILVh7VCSo1SGHPum5cpuPXOUIMWsPS/I1GixDfbZLJKllvVmkM43dn9dJ8sVyr
EgDfgz+ush/pHZFYCZjioCcvWctbuOOOgbY6x6X5ZMqQN7Mc5OU6bS82qyxdjbR1KFa62RkGS5bk
lMniKsnmkldW6RRmMFB1gloEZM0/XUvRG7JO7+ivrcYoQGq4EuVGa/42Wy3mVzC2rmqLmdeL1WuU
6JNsRXGtM+Te59AgNL+l4nOeQYsJKSznm2w2QVUl/en786nonL43cDdkHaTOoIQyS7icCxJDqpcW
QgHdx25LE1E6KenlhlB3O02GWwDR04wWLtIQQBoKHAh52xaRlfasDkdoMRQ4/AG0vKGa50AiUMsI
Sj4wAkJVAa32SNAajC6CTU5L36WezaYQ1isWm/USdD4lmGUecRwoj0CK64VYblbLRY7t7Ccw/xRk
NkdukZCg+G1yqAn6TxQWeI9qsQHpDjPyPDESpTxJzB8VVT0SpbRExDA+6bt0vKH4CdCSCYzyZTa+
xAwysU2k4pkKojCuPiVD4T3x/BLEWDZ/C+JsgvT+z/+8Sl4jh443yEKffiquEeucHEvXJcSzN3mb
qaZJzIS42WuwoZMqq3j1CuobDhpfP/ypewrL3sOfhi+H7z/LV+PPFE/88IMAHrVD7rBTSeskOUy3
saZH+m6Ngg/18NXiKsJ3ms9kqRzRzBbXUqeZ48iiJrQQY1CGYKYyBhXZFJSiFNhyD7XL1E4lWlg7
p9AP6M173fgS8CskdbBrOgk67PVW5wCFvBygMqdF6TZiQQv6hJ5qzObIgp4GgVSHzUF+kwt9LU/q
EzRIMue9yK5QRmU54950F5clwfpM0/d8AfsgmKliluVLdc89Rptmqw+thaaBjDJNP8/mn8kqY82U
b2YUtNRkfkhjNZmKmynjdcZbaqqMNRb2m028sD9EQoBkPV2skXWSNc4P2vql78azDSrd1H72BM0/
LyfvNatCLyh6Cgpd5DTkw2l2AYsbihQ1c21ZzH6dpstoX0yTvkaFhhRLyZw2BgdPZQGWgmSZ6mKx
u0c3Vce6clPN8U+AxRjOnGQbx8lJVmFBPCTzeRJri4oDwpPss/AeCvt4G09VFj+etF6v1FVcF4N5
B56n2bfdeCp7083DYR5uc9N1pBIn6fMw6YtY2US9Deqm6ZdinVTzGqyHYhIB5s+OuunLGAp21YIn
L9KVOuRxUvVxg4eEm1m9dNgNRbCTXTeKid0McdPtg3deehQNez2Vp6+SMGkapYu5SMIT7Vt6Xqp5
O8/F4hqY3Qwe4yQoxa9NuDmRJPeoM8B1nWYXl7Em1HjbvFI1p3lOTmHbalFMB0UUONhGgYPCWg6C
pEmBDINJk+BjXUEBfqodpK9iM22SXqzSYE6xO0M8lT/M66FhR+A8mYVH5ckskI+HB3J01BgvOQKd
hlyThoLLDczjY3hSwA/eFR83J4aJ3XRykvUBqJuozz49JOaklSfym09Ourn15GFRb1aGxHEes+QZ
JmqIh4lfnXLT7dF+UMRcnfKSI9DTcASn4QhOoxTXYXt4EntokydP4xqFibbkpAXTB5Ji6699YNNJ
VOdpTpp9c9pHYS5uuKlhUmzW2SBPPNGEbuKJV+qCkIfAvPTpJM6CxYQ/+OmhWKzWkSnOr5h5yWZ+
B3hWIafxSFBOMlk7Ynh4PCiezl8iddLTmKCeBrLMcVZx0+MzgV1646n8DpuXTlaqCCYeZDRM3kTS
7ZuoAabYBHGuzfnpWVRzdB5QddLZs6lOegwJf0HVSY/NC/aCqoeGXbNzkzdRutnrdB4e9ggrTzbP
LDqJi5jifLGahOsve4LVT83jWJjbk5tjY425iebFOZ48n6Tv0klMC+R3Bp1kfR3QS5zFBCCLbeam
mlhGbnJU1ecBzPzkVVRqE3+9TWJ049F23eRlTIcsUoocfzE/Kw9YO1tvlrOYEHkdjBS/3+jCcvcz
J9k6m/Fk/miuhygLkTBPDifZvKvro7BP6TrJ+mKlk2jf1fWx5GG7bRA5nmouZnoYTKhzLzECa29q
uonrdJkHBLlKliCDo1hiixl/HNhNjmvDkJGvQ234Ks0vgzT+dLCHRcfG42mvY9vRq9crEACr2CAw
yw1L5C8Ou+nxoZQvEIfaDnuZ2E01kZ99POl5tgkJacFZYh5l76tw2+NcsvXS7TriYuFvHbtZLIif
nxqDZpH63GTr9hSUiC1u/FKuk2yUaReLfRnZy2B+Dl4Od4Hg6fyer5e+isoqyImo+JAK+4tgTXHu
+gZ47EvQbtYiHE52x9dNjdLBOtbyxKvI7LbPSHsYWDBFJ5k9I83Tl3EOca4bO+lByipGJB5h0U2O
AC+TcFyWPKq8nx7FsYJdwTqCB3T3NGyJG9vRx8VvSrsZMS1xycxTLqK4ioPtCTcNTsh7D0+sA/oR
bicttsgsw23BMmCyZVyGLnFJnYd8w1/q5snmXW4PzWyxPggmWcy+jml4PTmGxN4ld1Ptc99u+k18
Ax0TZNxh002OikNUQzfhZNfPdztJ68zu4FwkeWRew7q/mSz0q9Y8Azea0yge5iDv5vBInjx5E6WL
4zTvpmeBwszeXvCxRJc1ex3fTYyqsuxaPk+1z417qeaNcg9NGqyILGSpk1qw+phApW5aIBj4W+c+
BjplDQqEtGBRBjwUPCaql7WJqvA6CqqTtCbXpkh6DHGeBiOeB002r2h4ZXVsAyctSDGPsnulcdmd
ZIsAnr8H76eb+RKiWoWLe87tOSzZWj5cNCzsAk+OKyZRaq6BSwMJzp4acVLZPRIfzTocA/M8PU/c
jC/xUDWGI2LZ1Q/ZO0nRhchef3ESQ+02v7k6jwpxHgTXTV6nMXFC/hhJYC2yz1w4iQWEW4fcbENg
8ETXO95DYmxuPC2LHe+yeBkeDh0cg6ddLwr2Upt5FhOlmwK1AtKzt7GdMQuv4WY4EYd5OnmRBKlZ
el1rxtDYl2+81GYo8zEZJlrMmvp2kcV0kOs0C+XW9Tpuyno3iy3v7wp2VDd8Zjo53KU65shQP2n2
BtyTIXQssCDKswDdsj5jfos20fgk2iTtP2hTjAnJS307x9GFRJuyIsfHABA9kHMXEg2ruQdonBtt
mnXfY2na+48lGRdCnfAmAJF+i/ov7fsYo3Gz19hOYQ2g6Iu+U9xtgzysdDJ/GCtIt8kM0czNscnm
mTI32V7dDRDZW09OkZlbxKTrV108PMx/w4HXD7nwNOvB4WOxLhxOAX1ri6dZJw4fiWFiL8O4d3A8
zL/DSWYOHj4a4+HhZZjHaBge8wqNk/ZFtLj28nBgrZuHm2z8PHwskxg49/TwMpZRLDysJoe3zh5u
srlc6uFxbtU5JZi/h5dhHD4CZDwWqFOGuXz4GXFMzOnDKaC8Pty0aZxGNoAoh7aOH36y8fzwEHl3
C1kp/6GuoJwTM9MtGEvzbroH6Lj/h1u05reQl6sFjbRZxS2sxZEdFNLiYCstDoprOgjTJkUC0fEE
cYo4AQ6CjFV0NjJnELeIjSDLk7k7iI+Jh0TgZfh7uTydP+3koWIuIX6RGHwaYaY0Iuu895p8JE+K
uMSP/epmRZHxILgc3MZpcFPNxXgPj72Hz+GdwLhOho2K6yFyHEScMo6HiJNjH5bxkDnhdXmJd+hu
PtmbwXroJrOwEAEuG3fXKxODn0bGehoZ62l8YMzDTxyUuZA46dMC5cY+2eVAhzPPuJEECC4X4eyy
F7OdROtJEmCxMUDdEpE0qSIHGN6FoFlseWCvg3kotJuJA22cTNzUWRJFwTxNHHjmZ+KnX/HF1EG1
jkkOJ6axl25eHfNRWX8Tp4jz+hjP4O4mPjK9/XULhElOeBQPR+7OIZNsAy3zZCdwsofJcTzhpZy3
bcP0TQyb43viFYrOKzdis4+Mx2rmhbjziZvBvE98bOF8cvxP3Ax3NjEs1gnFKcAjPbvpm6LFm4d1
5kWYF4qTbg4WfDx6/+5AryaR1Z95ovhIuDeKU4SH4HHLqI21l8qew2NouI+Kk86dVHxMPLK1U8ZE
rfZSZ1EJyx/hcwvYV7fc9PhuxXlszytgoxCFZZSpwS9inFjCItF5xwJnBwVWMXpoc4aXakwaARpj
1vBKaNOGk+wEVfIwaS8Zp4B1k3GStY3Ew/E65CEnOrgL7URvYkWcYE08nTvQ+LiyCB4eDMVJNz40
ARbrROOWMOHJnVTrRhMgyiPtZ68x8mQb4txDYlxpfPAYNAt7zqAdbxo3w7jTBIiiizZ3qPHSCzYU
3KXGKaF9apxE7lTjIzIvTvICr6PbfsevxsfjXKdyStkcnroo3sXxRyrdItbrJswowGQfXXdKWMcb
J92FZojyNNKHyEbTjXDvIXGe0PQKGfcbrxB/RJMVYVHxeao2pvpIlEHVgeWParrpLESRj+c62gEn
hL6T7mxfGCJtznWgrROPk/wm2qXV2C/OQ5rwdGUJ9hHkRfBOoH8vYxWXt8wFyCthfIC8dBYqKUBl
vYC8vEVExvFY/25yfNVmIfY4+FVMMFlfIB/JlbcBNunMG8jJWBYoI+7zA06JMGkVpZjz6CoH30SZ
eJlERmrJvYKCjDga5hfklmCOQW6G8+qrj855RMEt5urwOt2zYTJcBcolcw/yk41/kI8q2hHtIeQm
RtfOZWQntwz5r0iZd9yEnALMT8hJN45CPibrKeTCR850HF8hHw97eIIX4d5CXsZNga0kKkudCG9u
elwoc5cht0C4PDlOQz6ePCYCXLchJ4f5DfmoeGRNN8t5A5hhs+9vuPBuwE1WwDoPuanGeyhAFN9G
rFxBaVPjRmH+sAeHty5EfrLxIfIxpdHtlvYtctNcmnEky9DmZxyJ3MS8SLvhrkROkQhd+JMlHhbn
hWUvbzOLSqo8DVcux6HIy4gi1y5FDmzYdONU5Bc3L6Zw4CxMMn5FPgLuWOSU4J5FQYYzpzxsJois
Uyhuv8tdGxfDxF914QUKFJ84ca0fgwO7jirWjo9RgGkdGRTjZeSkcjcjH03slEA7Grlp8SUtdw8U
TGpEm2fORj4S/uS2U8K4G3kluL8RL2EdjtzUIjKuI9zOnt3hqV5ITg9PzOzK3Y689AIBZF/l4eDM
88iD565HvMimSGlhzkc+Kva4j5vjPnjOkDH/IyfZOiD5mKwHkl+gGVk2HB8kH9Uii6o41guJY7Ju
SB4480Pi8O+KLLQ3/gy2WU50R8hyIqiN0nwtGkmOEahCB5lRazgaUqCbvgqP+LTVG7zco5g3wqRj
TDMgrJeKhduDPRMf56uv1imeCc7SnJBHAQ+pvD0Z0CGFSv/xF5GOLxfiKqHQWabwdIVYVd0U3qUQ
QXk8MeXEn4BC/wF/juqnxyet92J38ADbIdqDBwUYxDe8oaLCeuASRvfB3ePd2hOPuqwvhYju1CON
98FWbMgw7PON1xreWz7cuq98bt3aU4dfWD8LkNyplxLngy2YxDdOvRV3Hlymopu8TvHsTwzXyfzH
BGZEXbx6hTh++MHGthpj7E4ZHgs6Nr8R9XcZ9ODVK5Co6QXFbPvhhx34W4WXwz9AXS29erWUh+uQ
sidKpbaKyqYilGFosvTdcpbMZVgyDPCZw4KnwhsF4bUwElMJDxknUNV04UWlxio6azeMlw539+rV
UX0gm3hUfwE/ShhYCv/4GxYbXW4IfpWK62w2E+fQEGE964RfJ5QplYYZBiT04s6V072LvXjrDAUT
G/635IFjEzOMKIVhw3JJhhSUphveGtPDxAxfKafhUwVklDIiAEctaSijy716NV9AkYtZWtwXDEqH
e9H5RAZo05HZ8rCJyfiytL2FItJCzAeeeZuptpVs267T5K1s2nOMvLWZTWSoq0QolrvZUYO7g7H5
FJtJ7BlGh6N4cf/5nxhEDARwsvz0Uxn+ShzpFBaE2QwNFMpWgs74MDJtCUOPych2kKm0TqF6KYO9
ievkRphalth+DHWYy6hhyRqj1vIBsRiRA1VMMSToisXJVQVUGMASNRTL7AmMmLhQsRHTcbKBSXSt
43kZfsfYXRTHEWBASUeQkpzCsjYLuSeGiys7TWxsZwC5ylNQsHIVWQ+W4NLtsOvL1QbGaLaAlo8v
sSkwxSlkoC63V+rMdWjFcSKbD237dB1pndjM19kMiUO9yUW+kF0ZX0owM1AuWXfENcYWvLaBzswA
ET0141ynTqWr5Fri4UOBGTSRMawgUJ3kw2I+uwF+XC6xFqyKoEhBFipqpRLy+XiFtq890YMJVmJg
GKyRAnxLYMyxjZQcl4v5gkgJbZGBFoEjkWvWMpalihwoOZjahS1KVjhX5xSm1YVBfgWGvEqTuZq3
C5z1xY2ibOqrjAGcYztBuaZHO1WVKJ1QXuoGykkxzVYIfL0QEtSjVWkrrUqwBn2u5cUFbL6XNiAo
scwyXaFZVIp4KYhwqhgHh0MdvzQlwzYwyPvS9xlWGMxEWhjQcwlFUBDTMSrHFSrNOXIaL2+8ISTs
Kpy1DKisx8IGMA3bZMtHG2YkliPXvQbJANo6UKVa+dSMMqCqvSbmqAa7rcUY/5VRlaImguBfQ710
tkJBocViPN6sdIxOxQxYsWQOl89LcoTLCvjVK4o1vW+haOWE+TC+3Mxfi+R88TatAIu/NkFeS6wX
ewu1lpjaX736XjrOIxFs9NFWnsNSBuKcuDvLS1SHbMsYUiV2MsXC2p9Bby2xzGxCGQ/7yguMjY0N
sT2T3Av6AHY7F1Vik5pq/Z6ooxCRcVmldJTPApSojzn2jqo3NeolyHSoB3oh75CJvFraMnyogrkD
sFwtxmmeqyVLryhywEgbe20i6eq2sDXRdNKh82fIuGYYKjsClOpThi3SwgJs2EkPm3q2AF8rEFov
ssyX09IIXJKRpFpsLi5hMFcpPaIgmU9yV8mZqGsd4pNkHc0vSiUZaZmBc5KK80njaAfQjhwfJMUu
qAlBc2F63Cw2pQ26ZmCXJ3o1p5Uasmx0WBBqUK4zpdRz2OuqjqUlGC/QiEgA2zVCjRCqcwsTGzQR
B6EoVasDNWwHQR7XRPnzigIsxQGhuvWlUI7INGSk5N+5OFHTLMiMC5dq1UB1M4cFThJUu+JnpGHg
YkVCZYeU8dmNv1qSrpXMgAOM8smbqubHRYZaCrUY/yfKf9StppVlr1TO01ToV5opsCtqYwk6/4Pq
qMYP2g+DITUuOb9haq5wJcQ9DVp4K7SI/fGXX8RuWTDusoAVo7FL20KFkGbS8AOWsd17atZupF13
bhOtnbJ3ejv0Uet9ZHnVCJXWWoZmXRA2Jbsq/rJrcu6mIXxk1bvFde/eqXJ/sa/nUj7BnMBpQrwM
///nJl/rJcJMWbW6UTzyRZ5nGCL88xKfa7iXoaIkp6AteNwvhYxtJ7TyHOSBnGAXm1myIg3YMoYN
u62WLfTgNWtJVFvnavgWbT2q1JPqXaI6pGZrxS9UQC/1aP1ctyGdTnHD+BaFFjLjLHstdwJGx5WY
SDcAudH59EqKmUQrCVA70PuKtqlTuUfGgP0ZrVtyFVzfzLIflaKwVzpKcnz9ByrE8SqM9vw6ww3c
1JVSusROiViG5J96jYXDSdkPe1FcvVfIMjBAIJoRTo09ugvkMtL9BHbOOUly2D4AwRavcTN3ldIa
RxQ5DN8c6LRFGVuj1jE1/nIiS36vlKRygUoLW+hQrgqS5C+Ho0Gr3q34uPTSwHChqmY2lGgx2jVK
R0XUT5toKkSQyYJGHbv7ZgNzxd388xZZ3fdzp2Vk8qIXVGjIZUtPOi16Bs1rqFpBeZ95Y1Qb8u2N
yFNgnMldWvGs1Rj1BvdJrru18I+3N00tyuFbTMaeeSxds6WiNdjo91EE+imThreg+pQHt5p1KANX
tJKM6Q2Ma7WZh9lkJt9UalWk7xt7llSZafZdJiuaYGSYKDkr0ooeGSEFQT6oA2AwR/CZEGV0SHfl
Ewx4O1TKMUIzKVkj3Ot0ubbaP+AHUpOOuTj/J9sEoPM2aouLuWo6iSrCMslyaRugB8OkrgsbFxL8
gYkVNBDSQCeoRKLwLGkJskpVW31lgCik3j5AuipzxBpkJzQdZfuiREqcEo+ot4/HiPVycU0mhLV5
nyNAnJuHos5vShmoYtkYGYuGjzR+QHdNJkI5W1A5RJFDDy9Cq2AFQuVsvlYEv1q8TWYkgU8HJ50j
/urHHJ+XkuZANHTuqDmsB+IqWanHKvb6g1aj0zsbqucm5KscwnmVA5eAdIkUzWEaybfZJJEVWA6a
LKmztKbByp7OSUjuoYhW4622HHwTN/Le/AGmhg0Oba3wMbe3+vUQ9504IDks3HOd+Z//ebJIJvjX
3t7ep5+KK9gGoqGe4v2rKdJcrHtUjTq7ov3Y7/cWeABCO73f7xEFP6NVZ2HOPnDhoMOPRzIfGQB+
E8B4qQvrXFVaKPwEWPqLsM0gKNsOQ/qiZkRTGTBKMdZWHCrVWpJvsrFUFqHkSQyNgTyHEfhWxyux
+6N48PCn015n2Hr/QPwAmWu0bkkIiftBZbzQaB+If9E5jXoE4r0gbOz0KZ3BoKrSdyj+zcOfRt0+
HYWDqqJbNs3kGY+hnXl/i4+jogOnCSjWcZLMpBlLD19IjduJQUg/LS9XiwtcNua72lpffrPBtyxw
ZYBFo6wf2KAp8kDW/UAcyqllUxcPKpVPiRzy5Q/TEkbBX7zKKPmJ+j6P+4xtxwZf0fCmF8XRkByq
Txl/X3DASKc3jG/tmd/acI05SFSog5NEWUWA4Rs9F1xmavYavL100v57PF63bTUoVHaCB4V7oJ7q
BBDrF6vkKt9bp+9MX2Yg3d+pvjjdkGUgFc/wDfthouwKUVp1wataAtDvs27rdISdlQwKtchMUDV2
p6wSgyGaC02MZnhEGpjD/pgcjUu14vka5ZbYiGAbnGgghvLo5GCHoQysIDc7ndMKH0gDgoNJfIhv
BJnUkAGfHOzv22Nub7TVCfd2PNHR3FLEG1l7HG7rjRT6xuaGwxeBB92UxnOWnU/OcdTXIdHUlLYg
egbYFIdOiV0TPTDJ5h42I0Q82BCQWsrnVPEAcyhnjKNTElt97g2vBgxG18fgDqTTvJgYEJJ3FeP2
HX1Uvv4F+9b3pSNlnpbaJ0YemGxAf91j57ioDtH2lNQtIO1ldnGZrnZnoP/NzJte7jm3VPKkOokm
Ovfw9Uq9zYYPxp2n+JgXaH85aqGoQyXXr0F3yserbLlWFk4CByUU1Wd9NGiO6bPcvmimnvqaQlfq
smHtzIoOTB5Cx9pmymOKObzWyX8h9XNFmjNsydeo6uLBxg7shnF7n6Ou6Z4USusraPiTGTahrY39
tNd79Wovyc0RijQTaJq/epXge3R0HsOesdNq+wVo3+pVUKQR04NX8ixTvmqs71BS94e0M91RvheI
xjX7OY+qyTbN8FU9tBLJM/5shXuspbSwBB4MaJ4GpA/GyRJ5CNQoc3rB2z5P8RQkUftA2mxQQ8zr
gcNUJpRevWKPon2mx5V7ecgXmtcJXqSkPePK6d+BeEB3Lx/wgZF0TpTNZ612OyWzR0jY6ThsE40N
HAEeyP34gx3spXSNeCC9bx4opeeB6UfJf5B6orcD/CTmfWmI+5aq2jPjtsHaoixo/MVFeYRFDdT8
w5wrhPSu5Y3WjUQ/jpLtgjpewxdncT8rrV4YtmQpypImuaC/dls7sh5+sC3NT3S7hF62nsvdFTqy
aDMShpqAQQdCVPTBV2kLED1+LR1eaMclh4+edUTOy0vXqwzqm2O7yrJ3/1Jd+5fuVMV6GuF4XuEg
BVYv1clP//LVV4V4xN4jEBOfCl9v820jtAun8eMDp+bRYkGyHcdNe7bQ2NHQ7ZXIxevTXPDxRA7V
/ZSOTNruSHYb2oxrdyDDUaa8oK6qcyRjpFiQdEGzoPRJzhWRSlBB/JFu7MtJ+m60ykAFxmHSL5+a
5sOYR+yJQFG9DTDPfMfwgFj16Jgrlxs5NERVbfpC3lKbf9DGYWoCw0yzd/YdUKQ27fGJNNL0WWDw
jHb38O7N/tpvt1wacPzPU+m4h22kNUG1eZmu3Im8QyODtgQcReNjpVtARy+KDVFYqOFVU9y++KlM
ZiRIamoKwvpx/VquHlfyXcd56omk58BcqbNkGjO696Kr5OL3kaUSls+fMYX+JfA2Anxt5tkb+Pq+
BI0Wu+1D8elPsF2n7n6NLV6vyg9rOwc7MLoX60v4Xdn9vPInAMmXs2xdJsAdNIHvPICdvMxIJtjq
rx/ok/IHmP+q9sMDucdHILoMZUAfHKIBCLXABw+rNvvB9+u/fM8V4O8fPKAKH3z/gBV48M0DjYiV
hWref4qKIw2HdgHA101xwHFQtKR/9YoIidZG4hbtP4AUkToPSkIy/rYPAcq8/gqjM0supDDIkxut
GQEgghknhXQ2EXmK1w3RdV3Uc7Lyo8FUmb6k28T3D2uarWzNJXq9WB9h0VGDbrYcfcXg8gx/QdKH
TthJJ5iupcmxJFtkNYiZfj9WO9qjkytSltqN7qmg5yhnOwyNooWmFHBX2XwjOwesRzUBj6ElEoMK
pCs0z87VKR4dKdN59FxZudfGvewc7wukoXy4kxiIyADSR5FU6NkLzIkv3+K3Womo/aQtSzKqIUGF
90bQHRwlkyOLFRV5Vf3ha9U2nVL74WvdSp10AEl3bC8jvmZgpL/iAaKWpiCdjeEuKmycmmS6HdIi
4tXWRhP47GZHI1eHG7HxARVZziA80yQ5Ks+25BEPzRvlRuL7vF6mCZr+5fSQVtlcOU6WjBn+1auo
+Fe6uOJKdZLDKztfTG405195FSv9izxYStrhV3qH2oNxI1D1cXh4MkDaV8kyCzE7sjcqAyn5A8dc
BPjzysj6EgM6P3COJ8s9zEC8ziOZ9PvYyJEzsHYgJwLwwYEWyAnv+VNEVtkYcr19jw6Ba2t4cKdZ
+GAbQvGNuAtvBsq6M1yu/4vS2Q/UsRQqGPL0oWrmyxhPkfS7wajJMQ3Q0doJRh7K4/7CmKQeKO2d
v0MuBRZiKlJq+MUkrtPIo0ayL5saoioM8Iisa8fwM3mY5+iiBYzP9BrUZtQNC3WWtcyW+qV3pX58
uMbhbUffExfSYql3RERhpgXmSOLVZi61Hr2IKr3nsFSwmXcUl71HnCq/qp4CQxJTU6o/WCVCgfxs
9UThiWknJO+0f6KSdbTxQ4d7vI2QoiJwbg6JGYOX7HZbei9f66VNSSnG7dvWNMuibFkzwxJbuF69
Uj2C4TaLGNMbCqURqyq+QtFZrFJp9PpTLNyik07fE4rkeSIuNjcfbCmOxyG3dKNgqWQrpNxbkO0j
J58DdXqJmtv6OlV+O8HpsFq6tVsdnY8bA41tj3QbUyiMhHDNObGu/fBDuPLKBZVfofHXVOX1oLZH
JevAvdisxmZ3ZEyewzUuKHS6vAL58twOtTRRKd08JzAVihjVj6++oiQpO6RnqxFWh8aU+/VdPhw6
usbISkUIfQfcqm1oA/+QZjltkh7SYl96spn2fHiDdGvQrvTzWwNLQO3gZ5BHtaZ6H62p3ldravfR
mtp9tebgPlpzcF+teXIfrXlyX635/D5a8/l9teaL+2jNF/fVmi/vozVf3ldr/nAfrfnDfbXmj/fQ
mj/em/C7D1lcvT9ZfB/CuHpvwrh6H9K4em/SuHof4rh6b+K4eh/yuHpv8rh6HwK5em8CuXofErl6
bxK5eh8iuXpvIrl6HzK5em8yuXofQrl6b1K5dh9SuXZvUrl2H1K5dn8q8n1I5dq9SeXafUjl2n1I
5YIAI3RS90g5tzgxdzDBv/NLDi8qEfd77O9vvhH6d9Um1+zPA/vzif35uf35hf35pf35B/vzj/Zn
dZ/9ZvVVWYVVVmOVVVlldVZZpVVWa5VVW2X11li9Nd5PVm9N1ns2bA1O6i9bA/qLbhkgUZPZ7FDk
q3HoNCZ9sOgVMHSKpIBH77njVw2vhGX5ZSpj0MDQfYLY/uPhT8Ozo359MIIUikpC13cOxfgyHaP9
91xMzsX4aiIuZos85xgPRDZ/K63NeEaBJpv/XF5P/lP6AiyT1VVueXf4cvg1+o+hn+3JsI+/4eu9
wJrxD2qBUE0hSN0qg6Ffb1IGfAPkoPG18kfDwEBfS0dqC907+iumwdd70ZX5XfQX7X0NidCEDrQB
mtDBNhy9bMFv+BeJAtRFotSBeuonVmgI2xs0WwOHsE/EEd6fQDKQ++dQXTtDBzZpGsoBbehm/Uno
04xWt3L5kTqMeCTKaFE2bs5ktH9QQRdnnFOHh0h1quaBRPvA+UF9e4DQsm++t3OlVKIxPuSd+Vw0
ME16ECVrIZ3T91ov+r1hq0nWPOpkrjzoyGAPM57j+AK5RrIP3jExd3TYkzI75DnmIo/SiPvS/xxS
mRY9IOZ3KYVTSabUOye3kKykA+Yc8hnH/IKVq3DJDRO2zV13q1vqLZ6gzFoIw4nPyOFwEqmYEVRQ
TjpBOZ7+EwS5tjGvL9Pz7HyWLaCC5eXN+5/++Mf3kJed4/XSn6rvcZhQHEjDrw8tUzVB3pd+V/xx
o89rO+yWAh/x2YfPF/v7+F394ouq/N7/gtL3a9Xak8+f/K66//l+DX7Vvvz8d/vVJ7X9L38n9u+3
GfHPBoYJ9vq/W23O05stcHjd9tdoz6/8+V5zyXiW5PlPyWqdjVF/+H6Djgk0aaVzOyTN02t1qvbT
9+Sw9v6nn75fr2V8svcewABvMct8+ullH7fPTlU2/XyvOd9y7ffrbD1Lf3I4FFKTzfpysfqpi02d
iwEOG6SiyCV4jSfBw7hkvMYjJjrcUrHRBD3Vpn2n1H1Dkc7p8Ej3CyXjxQbPwtTDSfQDj/HSNxs8
JUH3lx3lwEzOCzsYxwjUsGQm5purc4xOAZkmzQQa2FEH6eiNIPQl6vRa4DlLvicwppr0i8xNyKpZ
KuOANS5XeDU4mYtvV+htOYeFYJauPs3pPA/n/pUgsn+vL/6JVTpL3wL9rMvO0WozhyU7mb2VF/D6
yWYm/pZdXVFM7zkho8HZk0LEkvF7ijC6mOrrelbzVG4cZ+3+UJzNMzqKW6dtuh7YX1ynqyG9dYNX
I+4IipprJTk/X6VvxR2LlLbklRuLdHooBngXFtRqQTfBLPyIgqQy0B3x6bsdsf8Qf9N9k98/ZOdH
ei3DFlW3NamtBx17/uGlOBE+vPQ2ehggTphD0QI9ANkEKNTRbCfjCwDBrvGUtyQph0Px9dffbGuH
QMwSnKFFBbSk7uFdJpPkKllNDkUZEe4Q2orY/YZ+SCivGXhYNpn4CMowXjSuJa2RyLeVQPldlj+p
PvqktiPwRYhpNs5oIk29v/GCdPB5OKR4p4ZUB4oz7L8VEbCG4tXjXn8kjlF+9JaYzjjfz4pwug9S
evxY1EnoHQou9TC9mUoHPQA75GWkX6BCeE1uv6mWI6gg4rAtNiARCDpHNXCC+M5vxPcoZ9Fr/ifC
936vxPCWt7IJ8YjA8WEww3Td0D6sdvyvkndNvD5L/tyHoiPfgMLR/70aDGiNA1SeVKTr9DRLc+WA
9S672lyJiYEhP+m5PlHNxhbVJJtO05UMQiX0e4x7Xg27VbcK5duu6mHIbIXK3TdZgWa2SuSF4UzT
FUdBObUzZ12YKhYVUfsnpxlItAmQXdNpeJlN11tIRPnF1MkxWzqQr9LxZrXC9csicGghUW0ng0Io
O27xfCAFbMepTt1nIXSvSZZs6TXlb+OJC/Ry9/jBYYMYDdp8RZfXugkPrJzl6aefVv5+IKafYqee
7NlGAL0sri2Ew33WHG/G38Y0rGXbaUf1O/xyubha4IYHJvchRt/E/YVHPAbi0g+mL/rykMcaevSp
WC4W/M4TK/+4acCr8ibBCd4p28IOlF/MDlInw2GkOUAX/+maGrYxJZdoRnVS/fryPQzSkihhCHhM
wNrlcpZhvANbtzNrLC7pjI1ue7I6una1ymQUro+SFFSdT58m8elWQYoAt04YE1PBrI8WC4YGny+u
cKC3zSvDBagBJ4zgJP1j2PhqvMe68wECmRp/j8KY8HEawxDK1MJ5ZSHi0wqZQEZnymbZOkuNC71q
vXSIsvh2xVpeCCWHymQ8XmxAdtjW7YIkJnfec5ejMtR8MowkYlCRH1cq4wpN+b5Evn6zmCnxt4Vc
nKMdMWS77dArT6YpXm8+XcxP0wta2OK8KQFDxrRT9m0yg/mHXsv4KNREuoqq3iRz1s18ga+hoj4z
BVrdcYapbshmWC0SuUr3BY39BYMOWcVCdJVSJKwbewlLt9BpGhun7W1EDJzGk/R8c1HUMsosbNs1
7gpBmc4UI+iQKnpnqicp7iuhOR9ESqrZaaje/p4mV0DJIV0985rLQSLMgL6oarpoSLWTlje/+DS8
VShZPejjVl7eVqef2gt1Sz85SNhP48a6UTWre21312g/RuLxNjn9oWdkt3TG5Ic9oSyvP9rHWxtV
VHxRO5nuxF6mUncuZPlyltzU8+N24YywIPF5IU0mdCWK9k/q2iGPFMkau3I0apfySjKjMf08pTsz
aiCBDqsdCgsl415bfArgaX9XNWwsR1SJIIkXNssn6In/+x01IHLDPMetWX1+syMeTBOMG/ug4lO1
XNH3wuWVdBoQtZ6uF0upnvxJBIMxSdE0RW728hFo6R8tb9esEgqjqXeRMqDUBFsuR47NSgLWXvlO
p/4c75QaQ79Bf75bR4JivPWrdL1Z4e3l1SaVV8i9jtgr4g6v24653aGo+NMEI+JIFsf9tsUBbVUd
pqMOuZMGNUJ2Gvv6bJFNbE0cSv7BlIg5myXKlHid0YauFLGXfEMGE5rKV7gjF8AkxqRRLSsaV4oh
1IAUA6hFfQtEqAFUJDUG6VIcfg1f+Bps+XV6c71Ac5Csckcu+4eIrML2hVL7nUhigQB49UAnPjg8
1EXpMzk8hLI/hOYGKK0L2kRW2isoN6i2Rg+Xq4ErOIsfE72WcfxMe5qYgjbRLek1TO7+PFJQ4jZS
KEVHFVMFZaJfzC3Id2cTXZAlOqV5QakPmAplQUoMK3QKor5ji6mCkBgp5hZ0FuiJKsgTOQZe0FkJ
dUGeWFTQLkqMAUziFgZgi5KlKkuMUlUKk0W6Gqfld4e/rxz2SH1DKywieLenJ5OTAelyTrFUwgQo
IPcG/nU+HBPmm9+4JVa4KJ1+OSK9DM3NmU0WxeI7FJwzEL7LNNG7SuHUADuIb5RwJtmsC6Nk5eh/
Nvayar1eJfWqGUppMbPVZFNadjDK4s2fIWON4W11TZCJJ93lsrp2U2E1f1LVf+ygfoG58v6MqVdj
QZRu/RLeAFDYNXo0VzxgdtlDoey+WqmZyGXhQcmJ9qOPEdDEvM/txUZc7/Ozii1gscOJLeBFNmyx
zYhti+M+5G02SbW1hijjP79TIu2atooYcmGpd4Kr7SZtW8tdjdsnZKHHxZVWcG6qv6PpW1mzJCJY
/9W6GFq0rKqC95nM2Jps6NxuVV7Qo6Cx1iCk7Kdbq5ALSGEVMru4Cm7A31oPWy4LK2MwxTUqU/jW
yuRyXViPzA6rsBqGNqXd0iVa7bd0R5rT4l3hxiRTTaDwMt1A1/OxtiTPUqRt2zLQ8HlKOxyUsp7x
xrQt1OF8A04BKVQm0CFCBrKrFPcfl3+/4/qZITJNc4vKjtcdXD9iNvHi6rh+E6n255rE/QayVc01
j5gWynU/biJxyH2rdeTOrQwaGbNrFDbQ0Z6KGlhg4rizAcdv4rvAVFHYPqukFTVui9WCjYMyX/gt
mUcsEcXsxhW//xqmCBVZDQO76CBr8tksd1Yrq+SWntN+IDLFtholjS1yh2OKzqgtbgNm5XT1ujIQ
C/eiVr+020pxqPekFU9tczXA3ar6STqaSVavYssa5Hb2YcEWOrJVvUsz2Sb212+rXE9n4cZ4Fiyp
d+wM7Zh/5Y6wpfbWRrLd+V1bKTnz4xrKbDTuxv8u1JTWgF+PmKqNatW/tYXK7HDX9lUfFuohqSXw
hzT48DCC0dgebm0/2iLu2ni2of1oFmDmlFvbJg0svyqHBmaiWxvJzUe/flMdfeXWtjpmoLs29sE7
BvqRjdY22NC09Qu1eXrPbbZ6160NtiazO7d2fs+t5YrZ7bOMWeru2uKY+YZXiqoa6GkPfjaPR00/
Z63hUNosHFOPTY6admz2nd0RSQnVCDLrx0zONOrlIuNPvSf62kFb69u40V7kFE/wCp85xjfk6TxF
GYPoaRDPtKNE+Pudkj7ctHl943Dyfkek67GyApXbO2K4I1ov+oPBjhjsaArvKAPr7UYhGhvQ9dsU
Y/G2z+6u+PFoD6AH9Ybo905ein5bfF6CZKBkW1xnq4lxy8jS1Vps0AEJqhlfzjHqLNU2PBTH40lT
PjOqyhJdoamDZC2u/s/4cg1Ux0O6LBXPN6sf09lcvIUmKzLA3vD/Q/+KNijP+RodwOf4SNgc2oD4
QKEW320Wa/TJSeev/8+Kon3lQJVJAjCv8R8ZYG8uTqEU6iOLHJQNSNhDBNCT/w1jRdD0UuB3bXzl
Tzn2Dg7FXxfZvNzDC3TpZJgC4o6MVT1rqpeXCqjVOR1Rj7FfrRVsFedZTi8bY9UiOaeoZHI4oXYA
yNfpbLbGIvChdFV5y8QbHmLcRb8Fcp/BC+hJRuDaLBQvxj8DyVAoh0cL5DA3QZv3bylnqmuoh98W
INpnvWWuTYxhxX2cntAuto1GV29zysocsvTnH4/wjPn3O7+v8MNzk/vZ1txH20urx+1geh/KY08f
AAYQ5ud8GwjGm59P/qyz9d4y6PrWj2YqHFviJ0ig3w6XIbuLf9LLp+eLNU4PEG+Xyezccv8c/lnj
XJlixChCMUBkUOSa4mlpzAP1rhvM5x1UYGa5yIA155NrRAUI8N0xKo/CAJ/ixvdK/7/1j2sSCLCz
JpaneygzLJfyKZ5mkLSe4U82CZUursTZoRggwdq3UyV7vPtNRkWlAITJhyVlN+5SFP6qQ9s2wGmy
0P/6WtOG0G6xn2O2PEbA7PhRAgGdnnYIpGBD0Je5/UWe+VnYEplr579j4qW1btAanp2wRqpDaq19
Her1gm4AH2JzKvZyRPvW2xFtA1u9Ddbe6DBlbr99ocTs8KxPoCCwVnlqC9ilkCE969/ebkTYlmXa
7fYxwbfpAQcYItgSt5N8fZxsgKjK4INQ7a1gOj0nFseLFdO6tW81O+32sN9q1AlHGei8I+gfbIm8
LqL6aiDbPqjunYS2PTAlXrASWhrT+FYM41PjyGieJRfSOCUtho3dq2S9yt45GBuSN4FHdxX/QCMJ
4mkf8ylbsZT0LabLJoeafbCdlCL/DiW7/Ehjvy6rSmAvCuDRadLUZAfdrQ2TIouR/KBflsVQVpOA
ee0oRDKjAEn9kNG+EAgUKjukhVAvGNSLIqgGq7BRoaGcL9apOkGk41w+DHuLirhMcvkGHx1GJ7Pr
5EYGlJbvJeNZbr6DewLUVAFfLvtN9wnn2RqUCXVMrMyvoL4tLub4DmGm7aS6RadSGJGkjMpZVMcu
lHR98/esZKVUayA5l1gMRo0kK40DE2JqusK4Dp2JKKeQyWyHmWqePKMcpao9UztKrLL86tOkuiM+
rf8gD9Jx5WwzgdPdzNahyEGF+5ks0LYlTMWUZFsVgaCmWTD8Nby91qFb6zCsdejWGqGWTCcGOl8l
mzHM/0tY0+WasgM6aDajRVrrpag+oJ4KC/4F7BownCW5YuDdzf8NOqlckOL344ghlZNY2x9SzRrG
hVPeVp29VzcTcu12Tw/hEggsXRIK5M57Cs/pIzEQ9WbrvY7eSk9H5jm5Oik9cqwee3mj9gd4+MiR
yZjR+RoVJmmfNw6CPJJsNg9aYDdrgVuCfnxR+w4aAt3C/HFK4d5dNaryb0YzvKwsz+64W+X2npMa
JQWC+ouJ5LtRg36k+OT7YllEk7VuGsejC97S+QxdMnL7XjyBcpuNRYYXbVxaFRd27+qsF/8OfFg0
Gh/Oov8eg8IaBUPz/s5jU4BDDZaZLR/G9tLA8WFyURlFQDquSYul57nxZQp7Wq5Pz1E6z2GdLSeP
zzm2eeXvc7Eqzys7yhEIf8uj2eCS/45ULKb45sMs3vqPElqysCu67tIhpx+qb/fdIavM6K60BttH
o/neHAEnml/VFa+CPnF8sfESTeiC7Bb9Ku4Zx3SHTj7t44jp82ypwldu7+jTvpi+t0/Q5dJ5W/mv
qYuBakI/RR/7dbrbTyYpxwb5q8W77EoVUZNZ7sX0o0jm8SM5fQwHTN1OwAL1YbMGCkSmzK23/hza
kmdCxHdB3UmXvpIy/oJ7J5/eFvSlGvQTmF++TsYdmLTE+FiZHiHUR01QKLl1dt5yE9m5i/zxtHP4
R5MxoJ0jaz0CzC4+kFNmF7dwitsrZ6X6Ocwhe8XR/QLMgTFZ8ErSmw3sKmb0svkiQODogcgEwZX+
/UqEyh/HZrOLO7MZJ7zDGD+b8BzbFs76OOrpvsmbkwVBEvyJ+3QxW3wY42KJKOfC9j6b4xOV+ARB
svq/Plv/LzKzJJdiaRNwoFqJEv+j+BmL3sLQ3nhwRPFbnh8yHhzbNjlzC497fGHpu5WottPOaQy/
jW6J7tEctYWPpDkW3a5JBlqgpJyzvN9VQvuUczS5LYJiG+U4jlA0eNy6I9xr6uiM43OwpOaHiI//
a0T0xIEzHZhk+GXFgcu5hULaH6jtg+KNySAdf9iQQIHtAt1uf6MaK5cO6jLJrzAMYZ8/alJDybvK
UUuG6HL2QWTYokr2P74z/dt6o9dm6/gciNCCGCMf1D1HWb1VtYnYDaMSq2jyFMv6D54K/fhcKCAb
o1XhevgxkyPS6Y+SUXddXR2Kb1dZPt4Sc6sZ5s5y/wMn18+khYm15a6PHN+dlsoPtsAVmN8KyCRp
w1F9qCj+tRTku1LYJSvHF1IYRTNanDyDU0hZCai7zM1pzrUN0oXvZmAiQSBPuZlSrSNk6QZSALg7
tVBB/iJNlGHo/LZlU2BJPLyN+ViR5XpYnO14ab4Z6m7a0CeBEZAdOJtOv/n5vd7W74dvHu7G+64m
5xtaKWyjfSOlPzcRXrwptMbiVM257uAierMb0ag+boGNLLElIbzO9T+0d/3t3XNEkjcAeql8s1u8
WBaukC6uj5LzTAq52AJJ/4YJojfblYqAoiTMP4RdgGp3pCcz9Slm2Srxfxar3EEbIyr5Xo+mdx8i
wSNiG6ZH1Ym/51wnofwaqBuu12i6qkRAJ+lF9e6gd8FK0AXX4nbv94POEeQVR9JW3UfWkZ/klcaE
zg0dj+V7bwU249Q4+VCk79T6+5nXaseLOcbd3+DzoeRFPSXXb8lxWnXZI2zPU/VO80Ko10KvdNwh
Cjk+hyI7+Jx8go8qkJ/QdZbTc8c3FDiSXMjwQQ58zUPMFsjTCwrxLV8otXxUnhtOqlieggErHzya
P3r0ZPcJfh08xr/mu7VH8woeyIpqjTMbQ7IjsgKEZiLAwpl9vW//pkgU2BYxF49FuYwVqWpqdtmj
uwkSyk4pzsYf1ohytYY9epQ9yh7/wyKk1EcHkPiFzH58sE9fDEZIyjyWoI9rVYR8XN3ntEE/eXVu
SOJGhUTWh4l4EE0eXOUqnh2CDErX6pRRPXDOWOhQOZRTs1Xd0M5MVS+/KCGjQfpCfj+ufo5frLD/
2a09kYUeU5HdP2AhwrOLX/CP7RATAh9GaDk0AFihwa0RNbF588dPzCD/YvRStcvKgVC1x0S4x8jK
2WPVv9r9SybVfYqvMiBJVF5hCAblxji3sadmjJjYTb3biTpGLkxAL9pCHirnZAOJwi+j8DR7e1Vc
0narfpwa8n3Hq0UprF1l7gcPDcSWHao2loEBKuovrn3COCEGWLXkzFWOi9nhITSGwc03V6Ya649/
90rIWSNDj259EUl/A7bPoAmVvzhFtjRm/yH+9UssP5fpbInOL0j4X3SNkR1p16RfYHl5KNow/MZ7
kAvXNs6UoaQHo8/y8JA8GQ8PlacjzBd8/kG7Gmo4ErQajfVJdLcs6opFeVl5qEHKw4qsYfgZcVU8
z61G3U8bwS4ZH45IrjAEINRsg4ikGXnBoro/wzVsiCEI5F//iEwQ5IMFa/UDeZ1BOz/Mya+V3Bsy
Vbp5WmuegF5j3EpczabNwcrNUxJkX4c82TwtZ5qPiTFVOeD3WXkJOhb1fkcsa+bngs38Cfv9tn4o
nlWUHBg6wvRV2ag15Y1xni/THFtWseiOeH14OKxU4g7KQZkaL1N5ODzrw1CBLEWxyOhbLhPEo0fl
Bc0sgIW/ietfo7ip7u1NfmCLBFlImsxXx8spo7RW0rCivrGjmGzQLMugW0eXGozYByR9pmgFqlCS
Zzmrjk8NoZeDZB8WgaT6SA4lFcHRJJ/qdE1Hd/Wvk/3HlIN1Pz6oPEKv40vajSX7X9d3bTI9eJbT
9uwA928LuveVX4HmntpzPmif5Hs164biMbXdS/xHkRc8fR6Zae81fdf5WzatYulXCwmoV52k+vYQ
15i6/IrQz4zJr0U+EaOfijxXf4sLuPoD2l55JBtg59w2+snPriyhmmDmqqZWt99Qt2m66MrdSNbG
VlcrP0OhMEnfpZOWiqyfI9vdXil9YkVh/hdeNfA/Sl6Q1DbtRd/xGvWh/O6dHVhYGMh9nI2gqeXH
dLX4s1hicLp9qwgrqs7SBB+wa1gbg1hWNJnEI4G1KJo9eqT2Wkvegcduk/B2KzpfghawNI1uF7ea
smKtLntoaeHBtonPgjxaeDCvxMg0rCFUWVEGViJJoTuummaZRNnYrnzoMokvwygKf1J1FsQdpAsf
5ofFd6cYKyLjVH7xVdRbREVJ04R4sUasiBSlPyuH5j7GB1HUXqy4N4I+pGn8a5PH8pokD+c3NXkd
gRtjwejknI01aUGTZqQX4WwtM266WqibKFo7ocV+Nt4RryjqAeyiHoIMkr9r8PuHw0PSNu4m015B
Z7AnP0TVDC0bKhzVY484VjYQaRCbM2fleldr61Kamm3NcM5lGbmIcmqO1SYnB71v3bSbnPIyWCke
xiZcgyIB8IJqHGUDdlhbDD7zYwkiig2+R9LDr4mH9dB8UgXhis3dwy3Nw7bWE6Mr2t1ERJstGKx9
ywlqA7ZZ0JCyqRjUOZ1RcjryGRYzQ0PcpwSumv5RoS1n6fxtusIeVv4iBb3Z9tkJ/BeV4vb3IRsJ
def8JJuijlGOLaZ3X4rbahnVty5Lv8iu8BfdCaqeqruux+R3Nst+TCf8Nlo7waiMkFoeAtFm6Xox
r+csBMIdyaU/MaK3P0CD0R+pmkTc+uubd45C4FpCfPW0aLjfPSOrvipo9N7AakLZhmcxhETnRbd1
iIalyWL+6VraTlVoKedNlBsMH3FONtlkLa71AkJm1k2eTjez/2GnD+1RcJpZoWvy6k4WymBbjrR2
tOxA/idICb6qQqb4SjxxzB2vfojRgxa/mZSDqPXuotZLhhBDL7KrQfYrvcMQjnav6LkHW15jWYKt
HuCyFb6rIoLt5UnnrlbsFH9Xu2OhGi90cMdCB1arF+LmUN+Obhuxx6hltlZkbgKBBNKYr/m0Cd0B
7VdV8Amaqwxn4famrvgTd8e7UTjeGs7Ypj2vgMtCCttCROIbRUWbXLPJzFB+c2CTD1jVK9huYV16
rZeXzXWuqX2fao/ZDcnwhy+9aGeUhzJ+gqegCRVMsXwJC8A4WZcfKI1A3cZ5wIOC46aU/VmJrXoP
Zb6K2sMAVtkhu0MbrLL2xaG0TJy+I8m/I2dDdTeT86FSZElS1WNgAbOm8oWfswmsV9VDM6DSOJai
1TcD5qxKy4oqJ3ZhRCte4Vph4VpQuOYXPigsfBAUPnDaPdc8imVRVuwaw5ga8rn4RkTG+M7MYNjh
AXsBan7hcEGlcIihdJU3UR5ZuVwycSDseYOLpuahqUWAJjUPkwYiG+JcXshXp2grQbFH5fFdhvc8
s7WycdNVMGnfoMOLxWIpzldp8toNHgMTsnrIrsY7HxzK9BqW7bK0ICJ/7cjBhgUNfk6qu4vqY5Q/
0UmjPw9PCUuHv75VdnmXWlL7kJbUbEvg56S2u6jdS0uc0Ir4+Qgus+e+d2YxNhDYW2YktdZWdwCS
qtdVRsGtKGouCuQrHY0WtIx8McOg5G9pe8o+JaeiA717hIqYeWOVXVEEGgzFVL4YT7DmKr0CAIuo
rAoLy+uJ7gN7ZLeztjkZteIaW6aPocnFgo7VFwv5vDPiKrkNe4ItmpLmiZWD7DluMwhcYqb64Hux
ymWRYJlRoy4P8/ckrPhaVOWgS4KZQ3X93Jx9vkk50qg6PCah3Te2cpf50pR1LTtiv/JZxA6m8z1k
0Mz6WzyfivIjUeRzRhHf9s6384on6rQPrnh0s9S78Kj3eYx6Pg0vAhqG0ELZJwLSXDDS3KLrxyin
i8ejZq2r+nzQpwXw7SvSrT7MMOF9jJ1CIWnHu4AHz1V7nllU0bpW1NravbT2zu2VLa6ZFheHJFtl
1ailZGvjpFQJDDDS7LrKbmGDz6KFpV0WCxeWBvwrV7Axc5GuvMqsRUWIoK5iRLohHFEhJnnSvdoy
xe0HZuOX2g6i+cS1dpPleoVno6uC07niz+t0NU9ngKTywZwlTz2s8f4OJyXq80geIIEW+c5Qy+51
DMbtREFi4L10XBC+pNWouAHaAox0EneguV7yrXeB9AOzLg1vk3mWX/6PB7d3OlAPPC14sYZmzdCi
mleoGnyOM6KV6C05wDlbr7jNY798m6HDs13E+3HoRZIzNiiM/6btgtqXhsIClZPqo/njZL/y9/kj
IB1Xqd+9M3YJem/R7aTSI65ASSGTdS6mK5hRZKVwbNk5mw1VkwOaJO+xrTRmubEI7dEvrVAWn32P
CcuFW1bqyuOqO5jvrLCXXQAg+eORKPvzBXZE3lEjkxjZ/TQnLmAUrcwMeveZ73RAUoZajpPUWFc/
Zu0xhGY+DNullGqey5JqHE2bM2OaYVRjHVuloOzmqU7y+YGDqCRuJSNyOtPMse05LUPTh6UXjPTU
oRkb8NAaYDTXwGK5o1uu5q7prr2yY01ljnX81SewBnH/MPwbEZLIlSgNilBwPsR+Mpu/Dip8e/DI
mPm1LMdDzcpKIE90rTHpZd4maYIa9EMhdivkAnPsR1amqROrsek6M9gQdoXYkfyA9BPpjXi/Nvv7
xkeeEourVJmcBd4ykj5oPdwY6WfmtZF69RofNpGxXFh0SXPvRkbx0Vc8JHk09VTASif84k4kFiqL
XxlIiu0fHXNwWn5Xebz7zbT85tG7uyspFgl9FJJmGWd3xeuLDLNXloEui/pAuffVB78BbdsCGfxy
SyMQ4N7aoQadIgSRsSEFJUC7ymdz/pICRj8Pm66Cxyri+Jltk6ta7QNINrJXP0yk0/udGNDNqdF3
iPtVBHcVNTPnF6HoHtR9t0CqR/K+yvdQ+URM/16e7ZltExK+nhMdy9NDFXQVnYDdI6vIwDeHVqYN
QVZV7Z/VyqGJBszPipz3I6GEyfMMbTNdP28ErphLvJKSl2eVhxTgm66wE5HJSRsUyhSjUTNn7dkM
7UvymqS+m78DogcYb6JzCCnfdU119bIPuFI3hziD1QuXS6hbkJ9wbLpsNd7DLuaRqr6MaKTFn7iA
sKKqNvvBtWNNNuO0/I9HO9AueT581wGtfeCI/r8zpMHZzCtUgT6pxgYH6FAw+Ki8xIb79tG8TCbJ
VbKaPKQ42OV2RQ9u4ejKU96EriPyZU0Ot9zTT4165Rxd32Uus2DCL3Dg2d/VFzGHisjQv0B7wP2M
f2TgzObtVfMFrabvnCEpmo73MBmD0bNzkY+BXm30pJML6p3mHc48FvQZ52uzyhKq7cohj1S+bRTa
/xVmYKhLSCHbvquUDan468lVsqJ9xCj/PzjGhYI2OlwoaQs44N5ErfT4UWN+78qWrLmdzfAUaGJI
LYOrl4ONpgoZ7wyW47T2rknmqsdObCHfAsbA+9KbT17dDSxljKMINR6ko+mQCn6Dd7M8mw/ZO5a6
F3kZS8mrwYyP8vp80ofJsZGXa/Mi3qQzTdlhxpg6lGc5m493BDomSFpFJjqdaEoEMcIFrIacxhqP
3rmFjQbWrkbXCtUeZtkwczzSCKe5B/EBDtqp3FLyWsWvrFr2kfuDQ0atVz/ELWM5zOfxulymcUMb
YwX9iMufCJh/X8lHK+OzSn6QNahsX6BRURaWM9Mg6GOs2dxxcNLt+ucGRHaal/O78AqwJNvzFRiy
oeJcGuWN+brebLHnC5i+awc+OgoRCX2L8stfpfA9S51N1I4g0w2hqPCGuPaygK/c5hGySrybtX+D
ftZ+sY7ypz3Kt3TPtte7eJqPk3lZhjEol+0K+okUcSD3iI0sN+8KvcyQyc2bT6xrt3XHPodDnbHv
jrgKw4cPmxy6WzUI7zmT4hGUqqoeQ4nr540iXZiJ9r3279j52i/be9qv2KGPbMw+jgy379X4QzRx
EqjtotxEEQkkoo+ngPZev2+NqsA4rC74/SLWMqeu+QVuuO1dfkUThHHGwUmn26RA3B0xp7u5TZ4Q
r0NbwxkaLqad9HJuEee3opQBcRKxXiXzfExPs60xXKxU9R3Ezvxyc2ydWFfH+GHhfXNlyVVeiORs
iPGD1usZgYwvFwsZC0SssotLWMOzi3mCcUf29va4AiBdJDBE1T8eHYpyuOtT3q7sMStdWu6LGDVk
k6zjD+xo3v2drgb/+PcZmaN3aO8QkL3OXlXiyeXXh/JJrZn6nrLre3yW4ZOD8hWv8usdDOEzrUiP
3aF+uesjGnjnQXTfjnIyYj0wgityAay4IwjpCL0P6I+dSg7VncesnIyybi6TnNPwqrZpdpldC53h
sWqsebkY/+On1zuv32svPWgWUBZFC0J/BU3/RvxIzQbdN99c/eOn7Ov999AhKpe9R5DsGwJgrW3Y
XjR4cnm9gOGSx538Hn3TZm5hEv+IxD0eueVNAk5ld6VwMsqGuhUM+PRQnYdYEBvUzY+dw97vvcUt
1q4tdHEivksOQsoK8crT8nHFsrh2lIyC3eNDqUzuFO5pPPXSwbKlDNPi4nW3deU0Ibbi4noBIvuk
FkH4YkeNyxZcND121ORW36pc44eHXlxCby/O32E+NG8/AKMv5YNc5MvKH3j+xVZ2Gc/vl1rPYzOf
JJOMgwXkn9I7MPDv46r8rvy9Jr91Gq5S5iYotnb4AjidBYxwRNNcz3Ibr4DNFXmpdi7XKwouUTBA
M+sfwrSHrPKZ9F/Fu7RZxTqLmF/7cuZWQqZ5xAVj5tyvme9WuZWb6tvV9tHHIPsrlc9M6UeP5hWP
HB9DDOqa6ljQj8dzE0bBqQlUn0O1750fSsx6n8oiaZXfbBZHN8+SFai2FWzuw26yXAJ7KWe6qjxx
r4hy7uFvK/xym6Jbz7YTH1yLfHzTr+hWbcLWI+Fv0Sc46F3X+TtVEaz0vAROg7stzkppnKfppFhp
3BGbOXDlegPKYTq7CaeNMn9Pi+aMvE6Wr7PVDIahhkENs8pDpTuyp6PHZhdjrIw6rERk2jgKRfZI
enJQ1B3nglzsmAimjj/wVp2Z30IxjWxu5p3SZhi6QsXCHdtCFUPRzQ3a6pT/uCX7g7QCaY2OWazj
NwRu0waUqNgR5equCTxQ3alW6EIkfO14o/wBSsF2XUAJkS01R/Ddpg+YJQdUjM8A8SdV4xIZoJM8
tqMlwY6dqOpnqBhELjm5ysF8odUC458zdGLwyr0JG29slT5WwFH9uvqgaMq+8g2bHz6YLg3uPJae
fernDuXdB7JIsysau2DkfjFV7M3ufxFlzMiNnxnv2p5ZvFHL8hsrlO+63zeF5QL65vAQuPWWldqU
ad9S47b9eVhxm4JmkDfJ3dZxg+IFb8eHrlCgDL2xS2R59shob3zB0nU1eFW3LV+8ENJ16zpmA5fb
Kiqx5wvdGu62xH3iOcnz9Q1PFgvugd4qS9/cIkwfbJPUdxeftzilfciC9VFr5RYJu71pv8BSWry3
NmJAWsWx/CcHAGZnq5cRL/+iAEFDpld+QVGOQnaTq4veMkp4Yl5F/RHdrtlDqaCKX2GMliVs9p0r
uMSEWs/Gi+PywKDpvTkvInHedkQ8lGKozi/VUdxD10vbY/Jt0eBsMDhoWVnHeSL1HBvhHm0/djtC
UDzqE5X45aLvPO3/EmN97wilhZnelrVxjingjLZEZ/N8DYOB/MR5Bp8xznIZZQDx4NZuQwcR0vVI
XYXTPiwAuRlf4n2TZImG/TyjBwYw3o282ya3ihaTpzcA5DiZIyRGHE/mN9fJjdEMsNU1eRrPb3pw
a4HsjMw+VLKsXZH2QxldYXNBrlCGCtst8H7NdLoaqTywIyhDj165pY3c3NjiVpofTEPdsw/dlYox
QCKva5npCM+HWj2gKD62wC/mCSVdBbhXJFoq0wu95IfGCGQgTN1EQorh1hsKq/DcFLdhla6l6xo/
e0AvWYYgfN+Jjn8xVAGLi6d1rEDPkg5rMh5Zm2L63S3omT6totZifHC8N3azvqT4HPPxbDPRD2B4
5yZKkMGXagMURiai1tqzYkXNhdLWGFWlIhXrBxsPXJ+QmCD55vLlCpxos3StQp7jYdqisvWOl2qB
G0RrqC4YY0ML5H9BIEYl6nMbCFpFY3PWhjuEZNSIQCO20RijuH6NeM9qDHERsLFG0jIlnFgJoVfP
daISpEPkYeS9Hf45FN0Ehu+divVxJ0K/ZXU/SykWg4kU8pb+tq0zg4F/lGU8ZocrpAPfzA2jUm7u
NSplZgeDbqHO1tyr334d1DZPlvPV/Q/kBouu7XS3Hevur9WzNuta2/TNn0u/dsBQn0lrRVxa2FHa
oMmXYpRcItdV9ndhUcvqRsT9+7I26+fHsDUrzih02y3Df8OJ8LPo0P5ZhPh3mDaoMMMe11AGFnC6
Qo3PYaWEe4ljAsw8oz1Wvpht1taNyCuLwRwyNtGGhcTEgmxW2jOrAnjc3DB4edxWAJvNM/QgyO8C
S0PJp3cBnJnbhS2cbK6ubux2cgFa2VGSZ+OeMoz417SLanJ07jgMKKJz5OAH0ySbpZMHd7uljvKH
QnOSy+i1DKgm8s0Kph69BYObETvCCKEYjXylposNPgo2A1aY3OzR+0zSIJqs2WaGmEc+2aSc9KUu
CH/nGOkzw0fDMlR3E/SCxivXarjkFWxZN27DbmS15ym+ZQSK52yxeJ1O5HNOKrqorCYHkr1OKXQV
EGEFYoCdcZoWhCcz6BCOezrazJdnCcWXyDMuQL/+RmgaU70jFNbYWeolTInQHkz0sBP0bTLLJnvC
TmysgrY4yr+fa/I2+BgZX6g1RYLEV2WZHPFliQyjl/4Zq8SHz/5kcnB3NjFhGCShHlf39sJAG2MW
AEhJUx4qG+QmzF0pgs3c/pC4GRNTWhPo7jfWbzMRm3gz0mwzDtZcl0QXK+R0gHMgvHCDpoDPIh08
fkivcjMx+OQxDI7z51pNm3Eq2QiIj9cN1riNgU2vdIl8m+VAExVoRrtE7fmvo+FsoQi7bzbQMDmt
1tkVrEiZag5N1QVyJICMX+OLfwvFxuzyNrdOmUcrF6vsIsNn/3Bk9iwJLlh4vovxhLIdNuc8rqJF
4cUp+RbKhQyQjRrLNk7fwubtCjv/2BbXkA+1H0l1vbqRJp48z85nqZV+D2Sr2rcEU/WiHLkGKNrX
k9ebtEA5frh2qX8XXBBlhr49conCtWWHjHy3XM+m62Q4o+UAGGOMXj9/KLKR4Q0669m4tcH23a0P
OC/3Qi7qkF71ZgugTQ/JHgHjEImTdIdgPEUhlnTR4pL8OS27MdoeHEyH0dHqRrHAejgwT5BqbaDs
O55baFizTbDqKlvtWGgbMVmkOYbVVnoZRSS5SaW5TV1IQ7Y2oRtcvTI+FPhmOxuK24j5/9Q4eM/O
FVPn1oMq+nwiI++4MYmYNHtFdUADfnh4B83uFzpQl5IRlZyxcj3KVNCziXoK+75r5Zv4p32o2Ytz
xJTwu4Y8wgi7hIPnU9BuFh0eAJSaquPDswhk6uE8BfCVCmJ/S6Q6Gb0N1YG5XKFR3d1BqBU+pHqV
gEieL7Txnb12ByTfE6Knllyc2mhHvQI9NZ2oNZwUCnyTPUWVdX1diObp4hqnxg4PiAsKAMpXdTIB
XAyTTAacezXeGf+gdYrUnrHRbhI6oM5H8P9XeACMCIE2GDt2uZzd0F1sco9P0Ahr3l8V9Pxynr0F
DZ0pDwnFcVV1xKLimVm4pPDS+nTZPkpMQfW2rBcGkOSZCrr8UG7PmN4Q2SvebVUzUDT0Gg/xljLf
pspi+8i6vL7eEhPNfsIjlNf6CMUzmWyp1cUi1/0xqZiohyq3t6k83DKhrDR2eSZPl3tBBWEn9JWy
PZsSbrQ6dayOZZp7/IzdUgpP04XGas/WGVLa/Lh4UQWxpegvVWqxLMtdtyKqWZooteJ1h+3y3X2w
vgo0QfPKVTbnV31IzO7h+8H5Gm/py0M0PflqpN3lQj6czF8NZm9k01ZQxs0UGZ66ZWOc2fzuEA7V
AoeqZvde1ETkeJxdKImZnr6jDhqTXE3B18Db0uc92JBulmqy417XHtuoMxor2nalYNsT9cmE/A2w
kbSBuCJKXEJD0jkJCBUzeiavRREFrnESLFeLcZpO5PmQdI6nkdrjezE2FvIdDduCclS2slcfiqeM
/eyqc/Th3oI9GKHe6WAYyupGLd7KllbDIZ0X4Y4uiC1fXohveMtjUFFLs9wv29MvU9GOg04/Uo2c
wQd6T3QEzFPcvJKhRhvlpMHmPF2v5U4OT+dWGZ5p07bRBmzN5XU25CMp1+lhFfPmNeAn/hnPMMQ3
exYb0bCXsa2Bh7aZyQT4eQ0bHpQgOnw2LR24E0VGAWzEjskUWhi73Yf7FBQ92AhLQ2mucWKTFllw
uJSWMGTTkeJYJSDxuWXDVtQdxm30ukT8DOFjI4E6jfhYJIo2Ks4Ik24FtlTS6+MnoyR6kdsdIevb
VzG9GAcJYsLxsZvwB6OizWf+oPh1AVXYNPhOTxL42/4R2TXwoXuYRg/wDNrZ5vt4mDrp2cW0FOkO
mUiw2V1Sc2ih6Q49i9SdSGWa3t3WUVaA+/QvYtHs1Y7Pt9zbUZ5trublLl4QuBunfpi5T4/bnQJ2
a/3mTsBskt2tKU2z18VtrxqIHU/7wA9u+aTBWpv6aLAfKCMgejj6JJbhX22k7h2d6EVHBz64Pe41
IePlukMZx9djK7bxuN+Nmd0OGh0Ddhbqih3wzfkG34tQKoW04/7Cm0Os/rfd4W+7w992h7/tDn/u
7jC2+5I7nK17vjtt+GgeuZu+2/Yg5QWLGAfLTERuTP977wuN2fU+N4db94Vq96UcdbGF883VeUon
b8bzIhfJW1j+SULSyamyFygvSOnqy9y7jVNlTgYEbWagHdSYHlySx3ooAHakbHUDKSPhUATn7GCc
mDHfXDE7LIhtuTSn4mqxonNBRWUCQ0RmDcCjoHXiEB5vuWEXSU7gieNE+fbZDctCblDlXlE5OFN3
YKO5ubhkJCIORLd94C/qNXDL4loyLHDMApX9OfUND2Npb3GjmcLRH3agV+NkIyfXXK2NWU69lDqq
YTmqIrczNPFCTmCfKTgkVrbnaeGm93tvNos1DdzXLKqgzJJrMm4XvhIwO7m2V7i0x7wfUKS8zuTV
YbkrmML8tDc8Ir4NSGp1ypPDzjmXq0UgSIodHf6X8XTgM6QY/rGoQi9DsriHn476q6aP1QVlcE02
b3KtL8Ivfda6Jy9V4zN/zJJBbHUJkiVdGf5WSgd6ullDhrFO/BnRdJOb85S5rCSTCR5fyr7RrAM+
Q+PKrkIhWYVOyndNkxCTdIlGijgUdtxaPVmD6yvGaMt0TEGfa7RNwuc0oPVdjoucDy3tkeEhSRbD
5uwI+S3v32xO6hO33Im72u4sovuwxNyTLeYjTAxF9pjDLdaYj7THxC0yygOIrWzSOoNz7wPftOWb
5cNbTXzcwgeVkXmNk+g3o8p/e6OKWbu9Q+jNu59vZoD2gIyVVAxCw7o7Re/sm17QMQ4CGpKWAN8Q
4oK6vcDXe/xLxPwNH95biqYoL37+Mi/3xB1UeIPRKcgl+i2UtkQEQA1lOIXv0tH/ESiPtfQIZ4S8
3tDvsPBh8hUqj75+c8PmOWDho0712cX2/jpd9JCNdVxrG157v6CH22starYCC5v9dDFb/JyXqMI+
yBgq1Ts1P6i9oP0GLuwAajsf2QHkAmQw2vxOyq+2D0Ch4Czsc2EJJkgCXv6hiJktpUPuDYhQQEcD
p+j4CwgGbp9w2oiuab+QQJjCSvjhEoFFHIqKBL/BBTTVYBHW/OAuu421mD9mbgW1F/FEcQc+/pW6
yNSi4AP/drPKdj7CAF73ixhAgf1yc+rNbmxW3UPoGYcUb5AWPGZJ5H3Aj5uLqIRYDJ6eUtbxUsQb
tPfCIOixEN56+ab/MS3ULHhbI29XjAtY8oeP7qBPf2CkO/Xunrr14ZPyY6blrRPzY4n3i0XJ+EWP
PW+RKC5LaLmiFYCHv98xYuvh74F2rz6VMpxszAAp/xxurn4IpfnHrr63tCRZ39oSjzeiGxyvdZSW
rvSpnZoK2GqdpKYJx323PmjUhOxWMt21IV4v77pQwnw6ge3fTHlJ0e+iY8hb3qDWYNtsRlyQeMYb
faosZtSeBzumPR92feYONTyQtoTt/jrqQxdVwqN9na3eO/5EmhUORX+RZyxYu3PGD6Df6FiOrJnK
7vOKm1XNMTvaTOeGCbaYjZQ8VpBWp6ARUC8V+waOuwxTjJBYpbzbtJWEd7CnoJaA1ll7humbWBwb
GiApG46lp3xugb5K8QTuz2VPOMDkqZi6Ncz+w7ayMYU0wEM0Zk6Vz2ESkffK2eMqhgamP7yAqGUY
891q5YeAFNRnNGn/uQxU+fOOqSBSt8DjBL0sY8X55jwfr7LluvzpEuQH1MGH4Qd/hiBqWvGwbGSZ
fKXP9WV3iFJ75NiGHYsvrI/UsaI6cd7TNpjbr67o+4dl6NTdLrrQhzdLn8Lv7Zn3waPB0NSHlfwh
DmJmm5lrZT0egbi+q+Ol1o+suIQOuzrLB57aGPGsf+zGH+u6w8fVgD4MidntwbJb8op+gEwJpYrl
0wecn2/XjE3BWw381PctQspjBduiCK5/ybvuc5jC7hwAwfRJlc0IFL0xwY0fJbxpF0NYQkkdSDHQ
aZQEC8iab662Sqnd7VLKY25XTn1S/Vqh3wO9WP38QHGV30FcAeafIa3iIuAxYr2ScudDBdZHi6xf
X2ipQfFl1m8Sq1hiOVQ0rPdrT3c28VCJKf2l9PuHpdL3eUo4f1pKWSXV0M6pONZHj6Bhvi999dW2
/G+++VqaRefjdDWXtzH1Wynm5ES6YiU3KpxHOs/JywjDZeC5en3vr3tvkzlGLkRc/cVitU6hq7QT
F0MZEnGQ4mEvHpRDHXVTR9vWMZTdEV/slSrJ+fkqfSu2tbz0+LFoplJ04K1V/JscRHWh9J18p8Po
9YsptP3NBu/m0h3TVSJ9zZQjVl7i6Mt0IkIpZRPOxtzktVd6zRn2bU+SBUjiYNkkeCPBL1l4vitF
30PbJhO7v4JMU8Ax7arsZhtPbVMzIAHnFMAhB0XHqwD+54+bGi6ckomYEnb4SmeTUqy+cvvwr4ts
XlbJCNdIgCqL1c2OaCzmsHytM2l8NNQ6BPq2VDOACzroCYHObfJhtWv0PVFbCR2675sIJ2gQiwg9
68wDuDIG4CGsw7vfaL9fyvOqg3LJZGK2LqochmRs81DTY9mV8rLyF1W/Wke2DT0foXDAeW7xMHOo
X2lwP2ZMpVlDTegdtJ3E5q75oeZS205TRfiHcSbbOsX6sl4bAzOgdQBRSO8A8h4FoT0r9+qISkOb
bckWS9u2HN9dfnpSNFLRtnLbxGqI6hYPmjvL2ZNsjIsljvZM/lTrbWOxvJG3f8uNiqjt738huuii
OReDzXl6I76Sf+3RX3/BMK1ZupeM95L1N25TANl/6I8MH4UDv1pcrJIrdG2aom9ovpiur5NV+idx
s9igxxuGvrCelBkqLpPPFivCcLWYZNMbTNxox0LlaK18iY9Pz8SxjM8k+ptz6JhQ/RRJTiiWmJpf
phNxLr3C29iKoWqFaGOkImK5P+nochheA4eiBpX8h34EQWHdoTeVQc+Axq+UtobmmRuBflWm7J6k
wFZq8KtEyiP4crFUYY4ydMOfzcR5Kgtv8nS6me0IABfPO6OnvbORqJ++FM/rg0H9dPTyTyTOYZtK
jqeELAPJnaUTWR76ukrm6xukW7c1aDyFQvWjzkln9BJ71O6MTmE6i3ZvIOqiXx+MOo2zk/pAFu6f
Dfq9YWsPtKL0Nqqjkkpe2ZN0nWSzfO8/iAu/+uoRchtjPUybLOjuD/oNChudF7dayYwUNqmvAbCV
UPQq/DZopgzYKuiEi+nlDkq58We5BsW+C4ciT8KF6YEue2eV5Zal7g7SGSj8PeyHfposxhtcq9+X
fvff8LNKx3v5MpnsLZOr5eUsXf8CdezD54v9ffyufvFFVX7vf0Hp+/sH1YMvq7+r7n++X6s9+bz2
BcBVIe3gd2L/F2hL8Nng/RwhfrdCQbwFDuPX/Brt+ZU/32v2Hs+SPP8JF6XxDNaz70E4qhnyU/Iu
W1xBEvlVs/nw/Tpbz9KfNAtBQrIBebn6ia90kIqbSgLVKJLznFwC3sMaPCIvfzkVJynog1py49qW
zVKU7nidRHriqzt66t0QKD7/fp2+W+cbyJEK0k/ry/fyygbF5l+ZaE1k748j8UKPP3z39/lDpZ/q
TX6+TMcZqKm04tl09sbonhQXtm/fk8vDYgp6+5r8JgLVcdBq9PoiDCjFlccimJj6WASLCmOdhubQ
0UJuVSwV7fMY3cR8d325jdKILSgUvI47vyuhEZ2ldSQK12BH7pdu29YJ2JLR5qKH1rV0MsRbNbTC
wNLbpKUt3GNoqzIUb6vierUZArWA9juifp7OsmTeXcwX2WTH83sxyi835sVcY0DFxiGCprCXbAeo
1esT593dSO/v0nVQO0zrrW5L7b9j6wnFz2o9uUtHd8wqftyhKHsxbzXmtv6/cl7AbbV+AQKY43sU
Qj/pKHQb40MOoznf3wHewdCAM1jmK+/VNdXcjU4oL4MZfHj7ayJvPG/K833YMhAV8Y8K6pryYRml
AGvOhB/sWjSUtfjW6fhyjlc48S5Wjvfw6F6Lul8s5uQsJS9Qr9LlDAZFzQHqh8VjSshrx5msE+Vo
srog0az6aeaSrEn57KtMi09p/Wz+bsrY2025WtmxEYYAsq0m8dWCaqF7fBhBUN7PU9ewZccSDEEK
3Aet2+BrKSjBF1OLKpnTzVcjIPYsD9SbrXvgAXRXnRoeeEds8HNYoFh4yWe9JW/QW9keb1h0kVUj
4Jfb2OSdRbeVX+7AJpylPH6ZEgdMP1Vf9E3XBTHAsglMPFuM1Wsi0qjTmz4jRKdpOkknMIhG6BWN
Jo2ftqYVIc+mYiA9CdUtWX3gdJGuyTsrKjW+TVfzdIasoiUPVCVjXptmmVsjziugnfl0sV0QEa64
AUHFWrxK3h0W1nbLkSYFjSwsu7Xoa4znqHtOvYrbGgnJYklTlkc/KD9YLRbr3hR68eDwUBHuoUMG
XRafyo6UhOTtJfN03V9hKbqHTS2A7v2euPRZsnqwI2rmTYLTxVzdjXNLQSW3lJEmBhlKYiYloLpI
CErYgvSTCQKsJmY6kP1D0wTNGFLu6uucMJXk+00JLGxjjNKN2+OHreGhecVbYdZSmIwNdGokLxai
WqvK7CBTZzIGqwsib9PfWCxonbB3fbEBsp49Xa3bi4+rFas08ecMrj1R/j3o5HgFPMPXhC4Wi4kO
v1HRwcxd+kH5PDVMkRMdE5SgdL/6kApV90gSZ3vpnpJtGOYA57YfKTh9U8/b5jTbiHpKFjNk5tke
xlFBrLU9NWAEoiLp25IqLIfJk8VXUoUpz/Zqlb/wyB0EE61c5+j6a9Sngz3DJbJnUpgr71h3kqoa
ZNYzVSpSkQug6zug+p7sGSLP8ahWD0JFT0+Zh8e4HLM7H31IWYWZ0a9JjuRAnCeVvWoEc5Q+HoBu
9hO3eF21t7i8hpAIdP/8RsHwIzmM7MHnJXVY82SG1ruLSxOfEZDQs1gas9J8FkbAO+qtULeV8Y0t
DI6Da202n8DSrC6nM3Vgh6bTmutgHi5VlxsMBUA+39vVyy9F3KY4xBMZWMz2DJcjst3SFfUHssAD
tlqi2MJFV+ujdIhvgkOQ6CCdRIozKL0nGqTurTEQB0XwxrvslKU7TQ+LAcpE6gMeoQ0mOcndcAT+
87Z+13GmJ3PSuKDXsrNyrZdKqtQjOHPIXyGMnsf5Gp86f6K49C4qQznyvMb0kOkN5unXiNNC8QLt
ustTFCLDE1OWA01UnjVowu9N/0z+5vPDQ3yaLnE9G/c9h6BPEgzJoOIUqhdeaPN/aHfc/N0NutKO
US90Sx5whBT/yL4UV0726OEIKRmpQX+RRKFDMKch7MY+oLFtUu02rxow4Wd/gtJIQZMwXrdYBtfO
KeoFwiBWXPcYU5Xn6ARVrWCeOzgIWExXhy8Bh3Px3nElpd53po1kXg7q3XfIQDdp/Q7HFMoYw8GA
5DdX9smX9I089Y1peT9btfxoxdJVK/UjMIuVVKNep1JfondKJK/J28qy91I+qAopPMlrGTMRhYIU
51pEQNeyq0SVs6Ft9UWRQ3vwrnOyeUHOPH23li22LbcxemhDutJRjTDUkFpX5MohJ80SJZ/ZoGLE
CRNBZo6ePtdkUVklGT2+Kefh3kdukhdLGS1NbZSL9sfEb1iPeYjFDUE1RXGqu5K+Cf2QUAHM/4w7
48Uy5kBI7zDLmBVMToJg1KzqykIUYrI5ET9A21C6GOTl2gEiiNCTVLaFbvfrUK5RP1LNHeRriD9C
CMUlRRB8Br+yDyLZX7atP5T8gndueDgzZegg2bSvVLFoF+/SydsoKqvTlPjmluruk2KmrMsteuEy
dj9jEzH7Ezs75Cxgy5a50rljabNr2u01QMaeRAUOK4Na0kOFiD9aIRmcvlH3ph+O0ci50oN3Ecpz
GUOTLRZQpvKXIhlb8YJVcKriGfgc2GDfpnqDY9YSMyp2YbGtT9/47sNlA4sOpX68DKzXhbChzYBN
9p0bAAG7SFljN/KxRUQ7liIl1Xp32GZkXiyJaj8YOvurq4PU11YQq23+az+Km6dk8KxQy4gJMWhT
eTeiAnwWUUf8/qHSEQgMn0Z3IeHPIqJfKXpg8+jYnzgWYUUZZMWZQw2asxJUuozPt47T3bk1dDu3
4wlz+9Yl4A4c4a89PlOEQpw0W0Ctlc84pwRjhWIHUd+VY6IIgMj6QZ0y/u2M+Fb7H35wbB5Xd8sO
EZ1whZF30ebptV8rfMsAPLfVuFWGovLNRGhY890kMLlMy0YW4oqsxnedXR85v25TBn6xqa0Qxczu
ZTfx8G5udx+wNdEzkYdboDDot8xzXFr46ikL8cntLHy4lnt9sbtSeaVC+8F6os4tpLZibHQ+fs2/
bTz/64+kTzsaK+qta6nTvnfw/39uKF7m9Qp7v9KmNwqnuaEDqutVRiGB2QnjKpUP6JI5joxSdqNj
qyTbTjBo3F7pb1qVaXcnNJ76kKGZcUfblXd8C1PFHk6i7mjHXzbTO+YwXmjVsn5BEnZT5Gxwi8kJ
huR0MT9NLxJ2hdiSgK4iRwBg3unb1xdc87++RP8Z3O4BS/8eA1AFF1MIXptUjY31QllWNZS6tgJf
9vkLtZG8sBtJAqMJuF+scfP3+j5k7qm7aNqkg0BaFqji2n5v9NWIccw5JFcGMkR7nqIzqHEZNRsR
aZb4R0ngqRbr+X0p/tREI1ToVCsytT9a9XNWJKXTeVHF9x3RySp/nb5hvAEkYXlG3DO+3sESe45C
Y8KK0yMDr405wpYHxUSK8h0PVcVR2fAmhHlwepms8tS6qjLf7rZLvFAp1IzeLEuSSUpWLCfKZQW5
/2G70B5J71l/49gdi7dFRWN6z5uiMar0dN9z32056OG0LpPVfbiYvZWUsNMPav16jJe5ZBTQt2qh
VZTYqvo99HyIes0W1aBcsZyyKzZfytueV6zPb5gAteM8Sm5mC+WNXG7bIYO2O830VLJ1eUXGX3Nj
JpSf+tHEjI6Pfs1FDo/QvSVOysZ/hyWOOBebePvyNpms0H5jSWev99p83lP3yQXZT5WljpSIW+Sb
nDpHCiTVgbjepDZ1oSaltri7TyTrGxoyY8lb+0aD13z10Rc3aYOEk8ieBEcGo8IvOcOWMXqHd9+5
6B6DeIUsDFqDcyH+VTmj8P78FnVRFUJN6b3MKRAF5ZfCXTLaGDXnMINfp/ba/qtycOBbubVX+Hlw
KB4UZuLz1ckwxfDfazpYgBbgPCX4Ag8S8l5Cx8N8+SAic4kJ/1KOMWnFdx5RXOsJhICrvfn7gVz9
kXynGe5XYT6ssmlewZCjy6ZPVnh/XZLcFPp632+SZksZmODurLm/t4cbwyc7ekp/XtnCnDqhfAuJ
Hj26/V5/OZSnDpItZ29EwaAF7jz5qAmBWVHXqFsnA8DdbTLIu+i/XXn77crbv+2Vt9vvSvy/cZnr
t89vn98+v31++/z2+e3z2+e3z2+f3z6/fX77/Pb57fPb57fPb5/fPr992Of/B9ObcVwAwAMA
--=-=-=--

\start
Date: Thu, 14 Sep 2006 11:57:32 -0400
From: Alfredo Portes
To: Bill Page
Subject: Doyen Docs

While editing: http://wiki.axiom-developer.org/DoyenDocs , I got this error:

Some or all of this page may not have rendered properly, because of the
following error:
noweb: cd '/var/zope/var/LatexWiki/';
/usr/local/axiom/mnt/linux/bin/lib/noweave -delay 'DoyenDocs.pamphlet' > '
DoyenDocs.tex'
/bin/sh: line 1: /usr/local/axiom/mnt/linux/bin/lib/noweave: No such file or
directory

\start
Date: Thu, 14 Sep 2006 13:13:48 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: [Fwd: Your message to Axiom-commit	awaitsmoderator approval]

On September 14, 2006 6:45 AM Gabriel Dos Reis wrote:
> ... 
> I've begun to be more and more convinced that SF SVN server is
> not good for work.  Tim preferred to blame SVN -- but realy,
> it is a problem with SF server.  I've seen and done much larger
> commit with GCC with svn. 

I think you are right. SourceForge seems to be having ongoing
network problems. I still can not access the compile farm.

I don't know how using Savannah on Google is going to work out.

Maybe we should just put up our own subversion server on
axiom-developer.org. How hard can it be? At least then we will
know who to blame. :)

> [...]
> | The reason it is being held:
> | 
> |     Message body is too big: 255284 bytes with a limit of 200 KB
> 
> Give me a break.

This is configurable. I have changed the limit to 500 KB. If
necessary we can make it larger.

> 
> I noticed that the server can also truncate commit diffs -- 
> which makes the whole idea very useful :-(
> 

Maybe we can configure this too?

\start
Date: Thu, 14 Sep 2006 19:18:25 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: putting pamphlets on MathAction

Sorry to say, Martin, but even though you tried to document the API of 
the package constructors, your code is much in the spirit of the old 
Axiom files. :-(

Your code may be excellent, but it is clearly written for a machine and 
not for humans. So I cannot read it. You probably know that.

Take for example mantepse.spad.pamphlet:

\begin{abstract}
   The packages defined in this file enable {\Axiom} to guess formulas
   for sequences of, for example, rational numbers or rational functions,
   given the first few terms.  It extends and complements Christian
   Krattenthaler's
   program \Rate\ and the relevant parts of Bruno Salvy and Paul
   Zimmermann's \GFUN.
\end{abstract}

That is actually ALL there is to describe the algorithms you use inside 
your code. :-( Even worse. The macros \Rate and \GFUN are not references 
to the literature or URLs.

If Axiom were a Journal and your code were a contribution to that 
journal. I am sure you yourself would reject that.

Sorry for such harsh criticism, but I simply think if new things are to 
be accepted to Axiom they should come with a certain standard. We 
already have enough legacy code to deal with.

I would change my mind if your contributions makes (at least) two more 
contributors to Axiom Algebra and and you promise to document your code 
in an LP style till the end of the year.

Maybe you should have a nap... ;-)

Good luck with the presentation of your Guess package.

Ralf



On 09/14/2006 05:56 PM, Martin Rubey wrote:
> Dear Bill,
> 
> could you please put the three attached pamphlets on mathaction.
> 
> fffg.spad.pamphlet => FractionFreeFastGaussianElimination
> 
> rec.spad.pamphlet => RecurrenceRelationOperator
> 
> mantepse.spad.pamphlet => Guess
> 
> (mantepse depends on the other two)
> 
> I got an error message about noweave not found, and including it via spad
> doesn't seem to like the dollar signs...
> 
> (sorry for not being particularly useful anymore, I didn't sleep last night...)
> 
> Thanks for everything,
> 

\start
Date: Thu, 14 Sep 2006 13:48:09 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Doyen Docs

On September 14, 2006 11:58 AM Alfredo Portes wrote:

> While editing: http://wiki.axiom-developer.org/DoyenDocs ,
> I got this error:

Some or all of this page may not have rendered properly,
> because of the following error: 
> noweb: cd '/var/zope/var/LatexWiki/';
> /usr/local/axiom/mnt/linux/bin/lib/noweave -delay 'DoyenDocs.pamphlet' >
'DoyenDocs.tex'
> /bin/sh: line 1: /usr/local/axiom/mnt/linux/bin/lib/noweave: No such file
or directory 
>
> Any idea?

Yes, sorry. I broke this while updating MathAction to a newer
version of Axiom recently. MathAction still expects to find
noweave in the Axiom binary distribution but that is no longer
true for the version of Axiom that we are using on MathAction.
I need to adjust these paths to use the installed version of
noweave et al.

I've just done a temporary fix and it should be working again
now.

\start
Date: Thu, 14 Sep 2006 14:18:49 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: conferene call

On September 14, 2006 9:46 AM Kai Kaminski wrote:
> 
> Tim Daly writes:
> 
> > I work remotely. Once a week we have conference calls where
> > we all dial into a certain phone number and enter a pass code. 
> >
> > It seems like this might be a reasonable thing to do with Axiom
> > because a lot can be resolved quickly over the phone.
> >
> > Would this be a reasonable thing for Axiom?

Yes!

> > Does anyone know of a place that provides this service?
> > Any idea of the costs involved?
>

Free.

> As far as I understand Skype offers conference calls. That would
> be free and Skype is available on Windows, Linux and Macs.
> Installation (on a Mac at least) is trivial.
> 
> See www.skype.com.
> 

I think using Skype for this is a great idea.

I very highly recommend Skype. Of course you need high speed
Internet access for it to work properly.

On September 14, 2006 10:07 AM Kai Kaminski wrote:
> 
> [Skype for conference calls]
> 
> Another interesting feature is that people can participate with
> regular phones as well (you need to on the order of 30 Euro/year,
> though).
> 
> Skype also supports text messages. Tim, if you don't have a
> microphone and still want to try, go ahead.
> 

Tim Daly and I have used Skype ... but we never seemm to be in
online at the same time. :(

The right time for a conference call is a big issue - especially
sense we are quite distributed around the globe.

On September 14, 2006 10:03 AM Kai Kaminski wrote:

> ...
> If you'd like to try it out before committing to it, feel 
> free to call me (magicmuffinman).
> 
> I believe that in conference calls the host should be the one
> with the biggest pipe, btw, since all communication goes over
> his machine.
> 

My SkypeName is: billpageathome

Let's get together sometime soon - the more people the better. :)

\start
Date: Thu, 14 Sep 2006 14:24:50 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: putting pamphlets on MathAction

Martin,

On September 14, 2006 11:57 AM you wrote:
> 
> could you please put the three attached pamphlets on mathaction.
> 
> fffg.spad.pamphlet => FractionFreeFastGaussianElimination
> 
> rec.spad.pamphlet => RecurrenceRelationOperator
> 
> mantepse.spad.pamphlet => Guess
> 
> (mantepse depends on the other two)
> 

Done. See new links at

http://wiki.axiom-developer.org/AxiomContributions#bottom

> I got an error message about noweave not found, and including 
> it via spad doesn't seem to like the dollar signs...
> 

Sorry. My error. It is fixed now.

> (sorry for not being particularly useful anymore, I didn't 
> sleep last night...)
>

They say that's not good for your health... but I'm still ok. :)

I believe in Gingko and Ginseng ...
 
> Thanks for everything,
> 

You are welcome (but it's going to cost you later! ;)

\start
Date: Thu, 14 Sep 2006 14:21:11 -0400
From: Tim Daly
To: Bill Page
Subject: Re: conferene call
Cc: Kai Kaminski

Bill, Kai,

can we choose a time and try a 3-way conference call
just to test things out?

\start
Date: Thu, 14 Sep 2006 14:51:19 -0400
From: Bill Page
To: Tim Daly
Subject: RE: conferene call
Cc: Kai Kaminski

On September 14, 2006 2:21 PM Tim Daly wrote:
> 
> Bill, Kai,
> 
> can we choose a time and try a 3-way conference call
> just to test things out?
> 

How's today, Thu 4:00 PM EDT (Kingston: UTC/GMT -5 hours + 1 Daylight)?

http://www.timeanddate.com/worldclock/city.html?n=1183

Timing is complicated!

Or any hour after that except dinner time (7:00 PM :)

\start
Date: Thu, 14 Sep 2006 14:50:11 -0400
From: Tim Daly
To: Bill Page
Subject: Re: conferene call
Cc: Kai Kaminski

I have a work conference call at 3:30 (it is currently 3pm here).
It should last about 1 hour. I'll try to initiate a call to both
of you once the work call ends. 

\start
Date: Thu, 14 Sep 2006 16:04:56 -0400
From: Alfredo Portes
To: list
Subject: Fwd: [M#73697383] Re: Disk-quota Request

Tim, Bill, Gaby, Ralf:

I need some advice:

This is the response from Google to my request for more space:

You've certainly given us pause for discussion!  500MB or 1GB is a
*lot* of space, especially for what's supposed to be just source code.
We've been scratching our heads, wondering why your project needs so
much space.

Your project certainly looks mature and has a healthy community around
it, and we'd like to see it hosted at Google Code.  However, it also
looks like there's a lot of extra 'junk' in the repository... for
example, the zips/ directory contains dozens of releases(?) of the
same package?  (And even random odd Arch packages, like 'tla'?)

We'd like people to *not* use Subversion as a package-distribution
system, but as a source distribution system.  (We're working on
creating a dedicated 'downloads' feature right now, though!)  At the
moment, we'd be more comfortable giving you another 100MB of disk
quota... perhaps you could clean up your repository's history?  Trim
it down to just necessary source code, and move the release .zips
somewhere else for a while?

\start
Date: 14 Sep 2006 22:50:40 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: conferene call
Cc: Kai Kaminski

| Tim Daly and I have used Skype ... but we never seemm to be in
| online at the same time. :(

I have a skype account too, but I very unfrequentlyput myself online. 
I find the Axiom conference call idea an excellent one.

| The right time for a conference call is a big issue - especially
| sense we are quite distributed around the globe.

indeed :-(

| On September 14, 2006 10:03 AM Kai Kaminski wrote:
| 
| > ...
| > If you'd like to try it out before committing to it, feel 
| > free to call me (magicmuffinman).
| > 
| > I believe that in conference calls the host should be the one
| > with the biggest pipe, btw, since all communication goes over
| > his machine.
| > 
| 
| My SkypeName is: billpageathome

Mine is: gdr.at.skype

\start
Date: 14 Sep 2006 23:02:08 +0200
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

Alfredo Portes writes:

| Tim, Bill, Gaby, Ralf:
| 
| I need some advice:
| 
| This is the response from Google to my request for more space:

How much of the zips directory actually take?  build-improvements says
28M.  The whole thing is 114M.  But we will grow and create more
branches. 

| ***********************************************************************************
| 
| You've certainly given us pause for discussion!  500MB or 1GB is a
| *lot* of space, especially for what's supposed to be just source code.

They are kidding.  The mainline of GCC currently is at 331M; the SVK
mirror repo on my disk is at *12G*.  

| We've been scratching our heads, wondering why your project needs so
| much space.
| 
| Your project certainly looks mature and has a healthy community around
| it, and we'd like to see it hosted at Google Code.  However, it also
| looks like there's a lot of extra 'junk' in the repository... for
| example, the zips/ directory contains dozens of releases(?) of the
| same package?  (And even random odd Arch packages, like 'tla'?)
| 
| We'd like people to *not* use Subversion as a package-distribution
| system, but as a source distribution system.  (We're working on
| creating a dedicated 'downloads' feature right now, though!)  At the
| moment, we'd be more comfortable giving you another 100MB of disk
| quota... perhaps you could clean up your repository's history?  Trim
| it down to just necessary source code, and move the release .zips
| somewhere else for a while?

Tell them, we're actively working on reducing zips (the can have a
look at the build-improvements branch).  Furthermore, what
it contains is really necessary for building Axiom for many, common,
target configuration.  And, we cannot move the zips somewhere else.

1G is good for the moment.

Perhaps they think we are not serious?

They certainly will not object to the current 12G of GCC -- Google
invests lot of resources into GCC.

\start
Date: Thu, 14 Sep 2006 17:09:17 -0400
From: Tim Daly
To: list
Subject: Axiom Conference Call Sept 14, 2006

Participants: Bill Page, Kai Kaminski, Tim Daly
Start time: 4pm EST
End time: 5pm EST
Purpose: discuss how feasible conference calling is and whether skype can work

1) Skype conferencing works. 

   One of the key issues that arises is that you need to have 
   headphones because the microphone picks up the speaker output
   of your computer which causes echos.

   Another key issue (unresolved) is how to pass control of a
   conversation from one person to another. Perhaps we need to
   use Robert's Rules of Order or some such. Suggestions are welcome.

2) Kai dialed in from a MAC. He volunteered to look at the MAC port.
   Tim volunteered to 'partner' with this effort (see later discussion)

3) SVN is an ongoing problem. Bill volunteered to try to set up an
   SVN server on axiom-developer. Tim is partnering with that effort.
   Bill can do the setup and I can struggle with the checkin process.

4) One way of getting around the sourceforge SVN problem would be to
   create nightly tarballs. Savannah has that ability but it is unclear
   whether sourceforge does. Tim volunteered to look into it.

5) There was some discussion of setting up Xcode on the MAC.
   Apparently some people use a mouse, which Tim doesn't.
   Things were learned.

6) Bill make reference to the HP TestDrive machine set. This allows
   us to try building Axiom on a range of servers. See

   http://wiki.axiom-developer.org/HPTestDrive

7) Bill pointed Tim to the patches made for the SVN improvements
   branch to enable building Axiom on solaris. Tim will look into
   possibly merging this into the Gold/Silver branch.

8) There was a discussion of the possibility of losing work due
   to abandoned or partially completed branches. For instance if
   someone does a partial port of Axiom to a MAC How do we make
   sure that the work is not lost?

   Bill suggested two possible improvements. One is that each 
   branch is 'owned' by someone who is the person responsible for
   making changes and applying patches. 

   The second idea is a 'buddy system' where a second person 
   volunteers to 'partner' on an effort. That way you have to 
   report your progress to someone other than yourself. 

9) An important point is that skype will allow us to contact each
   other thru voice in a less formal way. However it is important,
   especially with conference calls, that the information about the
   discussion and the decisions gets recorded and reported to the
   mailing list where it can be journaled. 

   The current suggestion is that the 'host' (there can only be one
   host on skype) which is the person who creates the conference
   is responsible for taking notes and reporting results.

10) There was a discussion of which version (Gold, Silver, or
    Build-improvements) to choose when trying to port to a system.

    Tim's take on it was that the question revolves around the
    issue of whether the system is known to build on the target.
    If it is known to build then the only issue is whether the
    new Makefiles in Build-improvement works. If it is not known
    to build then Gold should be used so we can isolate the 
    Makefile bugs from the source code bugs.

11) There was a discussion of the next skype conference. The 
    proposal was that it should occur near 1pm EST so that most
    people can attend. It was also proposed that there be 
    regularly scheduled conferences. Tim suggested 1pm on 
    Wednesday and/or 1pm on Saturday.

12) The next conference is scheduled for 1pm on 
       Monday Sept 18 at 1pm

    Send your skype ID to Tim Daly so he can conference you in.

\start
Date: Thu, 14 Sep 2006 17:19:21 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Fwd: [M#73697383] Re: Disk-quota Request

On September 14, 2006 5:02 PM Gabriel Dos Reis wrote:
> 
> Alfredo Portes writes:
> 
> | This is the response from Google to my request for more space:
> ... 
> | Your project certainly looks mature and has a healthy community
> | around it, and we'd like to see it hosted at Google Code.

That's the good news. :-)

> | However, it also looks like there's a lot of extra 'junk' in the
> | repository... for example, the zips/ directory contains dozens of
> | releases(?) of the same package?  (And even random odd Arch packages,
> | like 'tla'?)

They've been reading my posts to axiom-developer, haven't they? ;)
I think they have a point.

> | 
> | We'd like people to *not* use Subversion as a package-distribution
> | system, but as a source distribution system.  (We're working on
> | creating a dedicated 'downloads' feature right now, though!)  At the
> | moment, we'd be more comfortable giving you another 100MB of disk
> | quota... perhaps you could clean up your repository's history? Trim
> | it down to just necessary source code, and move the release .zips
> | somewhere else for a while?
> 
> Tell them, we're actively working on reducing zips (the can have
> a look at the build-improvements branch).  Furthermore, what it
> contains is really necessary for building Axiom for many, common,
> target configuration.  And, we cannot move the zips somewhere else.

Throw away the tla tarball, and I agree that the build-improvements
branch is probably the minimum source code distribution.

> 
> 1G is good for the moment.
>

They said +100MB that makes 200MB total, right?

If our primary motivation right now is to diagnose/solve the svn
checkout problem, then maybe just uploading the build-improvements
branch to Google Code would be sufficient for now.
 
> Perhaps they think we are not serious?
> 
> They certainly will not object to the current 12G of GCC -- Google
> invests lot of resources into GCC.
> 

I doubt that Google would host GCC using this mechanism so the
comparisonn is rather moot. The problem is, I suppose that Axiom
is not big enough to warrant direct Google investment but (almost?)
too big for the Google Code project.

\start
Date: Thu, 14 Sep 2006 23:21:34 +0200
From: Ralf Hemmecke
To: Alfredo Portes
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

Hmmm, I must admit that they are right. We have lots of junk inside our 
repository. However, we cannot change the situation just by deleting the 
zips. And zips is only half of the story.

I have removed the .svn files from my Silver and run

cd Silver
du -k .|sort -n
[snip]
6248    ./src/interp
7496    ./src/hyper/viewports
8104    ./src/hyper/pages
9660    ./src/algebra
15844   ./src/share/algebra
15940   ./src/share
17664   ./src/doc/ps
18792   ./src/hyper
24532   ./src/doc
56544   ./zips
81052   ./src
138296  .

Since svn zips the files, the actual repository should fit into 100MB.

But look at that file: src/input/mapleok.input.pamphlet
-rw-------   1 hemmecke hemmecke 234633 2006-09-13 10:03 
mapleok.input.pamphlet

Who is going to read that???

Has someone looked at the pictures in src/doc/ps ?
To me more than half of them look generated by Axiom, the rest is 
screenshots of HyperDoc. Both have terribly low resolution.

\start
Date: Thu, 14 Sep 2006 17:23:13 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

Gaby,

> Tell them, we're actively working on reducing zips (the can have a
> look at the build-improvements branch).  Furthermore, what
> it contains is really necessary for building Axiom for many, common,
> target configuration.  And, we cannot move the zips somewhere else.

Is it possible that you or Tim or Bill can write to Ben Collins-Sussman :
Ben Collins-Sussman ? He is the person who wrote the last email to
me. You probably can explain in more detail than me why such a size
is necessary.

> 1G is good for the moment.

I think 200MB is the current size.

> Perhaps they think we are not serious?

In my first email I sent them links to  MathAction and the
SourceForge page, so the could see the community around
Axiom. The source is not in their repositories, so I assume
they did checkout it from SourceForge.

\start
Date: 14 Sep 2006 23:31:35 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom Conference Call Sept 14, 2006

Tim Daly writes:

[...]

| 10) There was a discussion of which version (Gold, Silver, or
|     Build-improvements) to choose when trying to port to a system.
| 
|     Tim's take on it was that the question revolves around the
|     issue of whether the system is known to build on the target.
|     If it is known to build then the only issue is whether the
|     new Makefiles in Build-improvement works. If it is not known
|     to build then Gold should be used so we can isolate the 
|     Makefile bugs from the source code bugs.

I always thought it is "silver". 

I thought build-improvements should die (or be closed) once I'm finished.

\start
Date: 14 Sep 2006 23:35:01 +0200
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

Alfredo Portes writes:

| Gaby,
| 
| > Tell them, we're actively working on reducing zips (the can have a
| > look at the build-improvements branch).  Furthermore, what
| > it contains is really necessary for building Axiom for many, common,
| > target configuration.  And, we cannot move the zips somewhere else.
| 
| Is it possible that you or Tim or Bill can write to Ben Collins-Sussman :
| Ben Collins-Sussman ? He is the person who wrote the last email to
| me. You probably can explain in more detail than me why such a size
| is necessary.

OK, I did not know that.  Before reading your mail, I contacted a
fellow GCC developer (a very long time GNU toolchain contributor) now
at Google to know a bit about this issue.

\start
Date: 14 Sep 2006 23:44:08 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

Ralf Hemmecke writes:

| Hmmm, I must admit that they are right. We have lots of junk inside
| our repository. However, we cannot change the situation just by
| deleting the zips. And zips is only half of the story.

Yes, we have junk in many places.  This won't change overnight --
unless we have someone doing cleanup as fulltime job.  In many vision,
even if move zips out (which I can't at the moment), we will accreate
more than zips, in term of functionality.  The solution to this issue
must be somewhere else.


Bill, if you transform axiom-developer.org into the SVN server I fear
that it becomes heavily loaded -- let alone situations where several
peple hammer on the SVN server to get source out.  I have no other good
solution at the moment.

How much does a 100G drive cost these days?

\start
Date: 15 Sep 2006 01:06:34 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Makefile.solaris9 stanza

... reads:
    <<Makefile.solaris9>>=
    # System dependent Makefile for the Intel/Linux platform
    # Platform variable
    PLF=LINUXplatform
    # C compiler flags
    ...


why is it described as an Intel/Linux platform?  Just a copy-n-paste
thinko?

\start
Date: Thu, 14 Sep 2006 21:02:15 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Makefile.solaris9 stanza

On September 14, 2006 7:07 PM Gabriel Dos Reis wrote:
> 
> ... reads:
>     <<Makefile.solaris9>>=
>     # System dependent Makefile for the Intel/Linux platform
>     # Platform variable
>     PLF=LINUXplatform
>     # C compiler flags
>     ...
> why is it described as an Intel/Linux platform?  Just a copy-n-paste
> thinko?
> 

More cruft.

As far as I can see PLF is defined in Makefile.pamphlet but never
used anywhere in the source.

I suggest we delete it before somebody tries to use it. We don't
need more flags and special cases in the source if we can avoid
it.

\start
Date: Thu, 14 Sep 2006 21:14:32 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Makefile.solaris9 stanza

> More cruft.
> 
> As far as I can see PLF is defined in Makefile.pamphlet but never
> used anywhere in the source.
> 
> I suggest we delete it before somebody tries to use it. We don't
> need more flags and special cases in the source if we can avoid
> it.

The C code uses this variable. look at src/lib/openpty.c.pamphlet.
It is used as a -D variable on the C command line.

\start
Date: Thu, 14 Sep 2006 21:40:37 -0400
From: Bill Page
To: Tim Daly
Subject: RE: Makefile.solaris9 stanza

On September 14, 2006 9:15 PM Tim Daly wrote:
>...
> Bill Page wrote:
> > 
> > As far as I can see PLF is defined in Makefile.pamphlet but never
> > used anywhere in the source.
> > 
> > I suggest we delete it before somebody tries to use it. We don't
> > need more flags and special cases in the source if we can avoid
> > it.
> 
> The C code uses this variable. look at src/lib/openpty.c.pamphlet.
> It is used as a -D variable on the C command line.
> 

What version of the source? I can't find it in either Axiom Gold
(axiom--main--1--patch-49) nor in the build-improvements branch
anywhere. Maybe I am blind.

Can you give me a line number?

\start
Date: Thu, 14 Sep 2006 21:41:59 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Makefile.solaris9 stanza

> > > As far as I can see PLF is defined in Makefile.pamphlet but never
> > > used anywhere in the source.
> > > 
> > > I suggest we delete it before somebody tries to use it. We don't
> > > need more flags and special cases in the source if we can avoid
> > > it.
> > 
> > The C code uses this variable. look at src/lib/openpty.c.pamphlet.
> > It is used as a -D variable on the C command line.
> > 
> 
> What version of the source? I can't find it in either Axiom Gold
> (axiom--main--1--patch-49) nor in the build-improvements branch
> anywhere. Maybe I am blind.
> 
> Can you give me a line number?

src/lib/openpty.c line 22.

the compiler line reads:

   gcc -D${PLF} 

which expands to mark the platform like 

   gcc -DLINUXplatform.

\start
Date: Thu, 14 Sep 2006 21:59:03 -0400
From: Bill Page
To: Gabriel Dos Reis, Ralf Hemmecke
Subject: RE: Fwd: [M#73697383] Re: Disk-quota Request

On September 14, 2006 5:44 PM Gabriel Dos Reis wrote:
> 
> Ralf Hemmecke writes:
> 
> | Hmmm, I must admit that they are right. We have lots of junk inside
> | our repository. However, we cannot change the situation just by
> | deleting the zips. And zips is only half of the story.
> 
> Yes, we have junk in many places.  This won't change overnight --
> unless we have someone doing cleanup as fulltime job.

Let's agree that it should be at least a part-time job. :)

But I fear that this situation is due to a difference in philosophy.
Tim Daly (and perhaps other earlier Axiom developers) seem to have
used the "everything and the kitchen sink" approach to the *archive*.
Whereas for other people the emphasis is on "source code control".
In that case everything else belongs elsewhere.

> In many vision, even if move zips out (which I can't at the moment),
> we will accrete more than zips, in term of functionality. The
> solution to this issue must be somewhere else.
>

Could you describe this "vision" a little? What else do you
envisage adding to the Axiom source distribution?

On September 14, 2006 5:22 PM Ralf Hemmecke wrote:
> ... 
> But look at that file: src/input/mapleok.input.pamphlet
> -rw-------   1 hemmecke hemmecke 234633 2006-09-13 10:03 
> mapleok.input.pamphlet
> 
> Who is going to read that???
>

I think this is a good example of something that belongs elsewhere
if we agree that the purpose of this archive is source code control.
I think keeping these sorts of documents on the Axiom Wiki (or the
Axiom Portal if it is personal research), makes better sense than
mixing it into the source. I understand Tim's purpose in associating
it with the "input" files since these are the closest thing that
Axiom has to actual test files.
 
> Has someone looked at the pictures in src/doc/ps ?
> To me more than half of them look generated by Axiom, the rest
> is screenshots of HyperDoc. Both have terribly low resolution.
> 

Yes, some are quite terrible and contribute to the rather rough
appearance, for example of the Axiom Tutorial book. We should
be able to do better.

As I said earlier, I don't think things that can be generated
from Axiom belong in the archive. The instructions for generating
them - yes, but not the output.

Gaby wrote:
>  [About installing an SVN server on axiom-developer.org]
> Bill, if you transform axiom-developer.org into the SVN server
> I fear that it becomes heavily loaded -- let alone situations
> where several people hammer on the SVN server to get source out.
> I have no other good solution at the moment.
>

We already have both tla and darcs archives on axiom-developer.org
These do not seem to lead to any significant load on the server.
Do you really expect that SVN is that much worse??
 
> How much does a 100G drive cost these days?
> 

Peanuts at the supermarket, or on your desktop. But if you ask
Google how much does it cost, they would have to add the
proportional amortized cost of the data center and the system
operations and maintenance staff, etc... I think it becomes
non-trivial. :)

\start
Date: Thu, 14 Sep 2006 22:15:29 -0400
From: Bill Page
To: Tim Daly
Subject: RE: Makefile.solaris9 stanza

Thanks. Now I see how it works.

On September 14, 2006 9:42 PM you wrote:
> 
> > > > As far as I can see PLF is defined in Makefile.pamphlet 
> but never
> > > > used anywhere in the source.
> > > > 
> > > > I suggest we delete it before somebody tries to use it. We don't
> > > > need more flags and special cases in the source if we can avoid
> > > > it.

Damn. So I guess it's too late. This stuff is everywhere. ;)

> > > 
> > > The C code uses this variable. look at src/lib/openpty.c.pamphlet.
> > > It is used as a -D variable on the C command line.
> > > 
> > 
> > What version of the source? I can't find it in either Axiom Gold
> > (axiom--main--1--patch-49) nor in the build-improvements branch
> > anywhere. Maybe I am blind.
> > 
> > Can you give me a line number?
> 
> src/lib/openpty.c line 22.
> 
> the compiler line reads:
> 
>    gcc -D${PLF} 
> 
> which expands to mark the platform like 
> 
>    gcc -DLINUXplatform.
> 

So the answer to Gaby's original question then is that for Solaris
one would expect this variable should be something like:

  PLF=SUNplatform

or SUN4OS5platform or ... something like that.

But at least in the case of the build that I was doing on Solaris 10
with the GNU toolchain installed, it looks more like a LINUXplatform.
I did not patch this variable in my build. (I have no idea whether my
compile would have worked if it had been set to SUNplatform.)

Anyway, I think all these flags are an unfortunate mess which should
really (eventually) be handled by the more general and more standard
autoconfig mechanisms. Right?

\start
Date: Thu, 14 Sep 2006 22:23:42 -0400
From: Cliff Yapp Cliff Yapp
To: Bill Page
Subject: Re: Aldor and Axiom - alternatives?

On Wednesday 13 September 2006 11:56 pm, Page, Bill wrote:

> I think that this is so far past our current skill level and
> the available resources that there is virtually no chance that
> this will ever be anything but a paper exercise.

I think it MIGHT be possible for us to make SPAD support the key
feature or two we want from Aldor (type behavior, etc.) but even
if we do that, we are still faced with the problem that SPAD as
a language in Axiom does not have any really good foundation as
a documented language.   I guess my question to those of us
looking to improve SPAD is this - even if we can change it to
support the feature or two we need, how do we document the
language?  Do we have the resources to make a really formal
definition?  How do we tie those definitions to something that a
theorem prover could use?

> If we have to live without Aldor then I think we would be much
> better off looking at possibilities such as how to make Ocaml
> or Haskell work with Axiom. Ocaml at least is heavily used in
> proof systems and has a syntax and object model not too
> different from SPAD and Aldor.

Bill, do you have experience with Ocaml?  Apparently Ocaml and
Axiom are not completely unaware of each other as projects:

http://caml.inria.fr/pub/ml-archives/caml-list/2005/07/cf19927bddbdfdbb6a06=
2bb9f56262e9.en.html

and apparently there has been some earlier discussion of
languages + mathematical "fitting":

http://listserv.acm.org/scripts/wa.exe?A2=ind0206c&L=oscas&P=481

Since my guess is some of the people on the list now were
involved in these earlier discussions, perhaps they can give us
an idea of what might be the pros and cons of using Ocaml or
Haskell to re-implement our spad code.

There are some earlier discussions of Ocaml on the list:
http://lists.nongnu.org/archive/html/axiom-developer/2005-10/msg00204.html

Possibly relevant to this discussion:  there has been somewhere
some work with COQ and Axiom:

 http://www.emis.de/proceedings/MKM2001/hardin.ps

This is probably one of the documents we should look at first,
but I don't know how to obtain a copy:

1. G. Alexandre. D=E2=80=99Axioma Zermelo. Ph. D. Thesis, University of
Paris 6, LIP6, February 1998.

To the best of my searching abilities, it's not currently online. 
I suppose a copy might be ordered from the University?

Personally, I am not so afraid of the idea of translating our
code, since I believe the effort required to understand and
document properly what is there is going to be almost the same
amount of effort as a re-write.  Hopefully the interp framework
is reasonably language independent  (after all we can plug in
Aldor - which is a separate implementation of a language, even
if similar to SPAD - already).  Since to make files fully
literate we need to not only understand the code but the origins
and definitions of the algorithms being implemented, we are
looking at a massive effort to spruce up the algebra code no
matter which way we go on the programming language side.  I
suspect (although I could be wrong) that understanding and
documenting properly the design considerations and mathematical
theory behind the SPAD code will be such a large effort that the
language considerations become secondary, except for the
question of what language has the most potential for benefiting
us at the 30 year horizon.

\start
Date: Thu, 14 Sep 2006 22:31:40 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Axiom Conference Call Sept 14, 2006

On September 14, 2006 5:32 PM you wrote:
> 
> Tim Daly writes:
> 
> [...]
> 
> | 10) There was a discussion of which version (Gold, Silver, or
> |     Build-improvements) to choose when trying to port to a system.
> | 
> |     Tim's take on it was that the question revolves around the
> |     issue of whether the system is known to build on the target.
> |     If it is known to build then the only issue is whether the
> |     new Makefiles in Build-improvement works. If it is not known
> |     to build then Gold should be used so we can isolate the 
> |     Makefile bugs from the source code bugs.
> 
> I always thought it is "silver". 
> 
> I thought build-improvements should die (or be closed) once 
> I'm finished.
> 

This issue was related to the fact that I recently sent you some
patches for building Axiom on Solaris 10/GNU from the build-
improvement sources. Tim wants to apply these changes to Axiom Gold
sooner rather than waiting for them to tricle through Silver to
Gold.

Tim is also very motivated to produce a successful build of Axiom
on MAC OS/X. I suggested that using the build-improvements branch
to do this port might be easier because of the build from system
GCL option (I also forgot to emphasise the build out-of-source).
But Tim prefers to work with the Gold distribution.

Tim is probably right that my building Solaris with the
build-improvements sources was probably a little pre-mature,
but I just like working with build-improvements so much more
than Gold, that I could not resist... :) And at least in this
little exercise I did not find anything that I would classify
as a Makefile bug.

\start
Date: Thu, 14 Sep 2006 22:35:02 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

> > But look at that file: src/input/mapleok.input.pamphlet
> > -rw-------   1 hemmecke hemmecke 234633 2006-09-13 10:03 
> > mapleok.input.pamphlet
> > 
> > Who is going to read that???
> >
> 
> I think this is a good example of something that belongs elsewhere
> if we agree that the purpose of this archive is source code control.
> I think keeping these sorts of documents on the Axiom Wiki (or the
> Axiom Portal if it is personal research), makes better sense than
> mixing it into the source. I understand Tim's purpose in associating
> it with the "input" files since these are the closest thing that
> Axiom has to actual test files.

mapleok IS an input file. I just took the time to document the
expected results so you could tell if you got the right answer.
It is partially on the way to automating regression testing.

Testing files are clearly part of the source control pile.
Especially since they are run as part of the source code build.

\start
Date: Thu, 14 Sep 2006 22:39:04 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

> > Has someone looked at the pictures in src/doc/ps ?
> > To me more than half of them look generated by Axiom, the rest
> > is screenshots of HyperDoc. Both have terribly low resolution.
> > 
> 
> Yes, some are quite terrible and contribute to the rather rough
> appearance, for example of the Axiom Tutorial book. We should
> be able to do better.
> 
> As I said earlier, I don't think things that can be generated
> from Axiom belong in the archive. The instructions for generating
> them - yes, but not the output.

Those files are part of the original Axiom book (the Jenks book)
and clearly represent source for the book. One of the outstanding
problems I have to solve is how to place more than one image on
a page. That's the one blocking condition to reproducing the Jenks
book accurately. 

\start
Date: Thu, 14 Sep 2006 22:40:35 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Makefile.solaris9 stanza

On September 14, 2006 9:42 PM you wrote:
> > 
> > > > > As far as I can see PLF is defined in Makefile.pamphlet 
> > but never
> > > > > used anywhere in the source.
> > > > > 
> > > > > I suggest we delete it before somebody tries to use it. We don't
> > > > > need more flags and special cases in the source if we can avoid
> > > > > it.
> 
> Damn. So I guess it's too late. This stuff is everywhere. ;)

Yeah, most of those conditionals are what make the C code hard to port.
C is the least portable language there is (I know because I had to 
figure out most of those conditionals). That's one major motivation
toward rewriting it in lisp.

\start
Date: Thu, 14 Sep 2006 22:43:22 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Makefile.solaris9 stanza

> So the answer to Gaby's original question then is that for Solaris
> one would expect this variable should be something like:
> 
>   PLF=SUNplatform
> 
> or SUN4OS5platform or ... something like that.
> 
> But at least in the case of the build that I was doing on Solaris 10
> with the GNU toolchain installed, it looks more like a LINUXplatform.
> I did not patch this variable in my build. (I have no idea whether my
> compile would have worked if it had been set to SUNplatform.)

It depends. The issue usually arises because the include file chain
changes with every platform. However, a linux-compatible include file
chain could use LINUXplatform. Try not to read too much into the name.




> Anyway, I think all these flags are an unfortunate mess which should
> really (eventually) be handled by the more general and more standard
> autoconfig mechanisms. Right?

In theory, yes. In practice, no. I doubt anyone is going to figure
out the possible combinations automatically and then re-port the
code to the various platforms to ensure that it works. 

\start
Date: Fri, 15 Sep 2006 05:12:02 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

On 09/15/2006 04:39 AM, root wrote:
>>> Has someone looked at the pictures in src/doc/ps ? To me more
>>> than half of them look generated by Axiom, the rest is
>>> screenshots of HyperDoc. Both have terribly low resolution.
>>> 
>> Yes, some are quite terrible and contribute to the rather rough 
>> appearance, for example of the Axiom Tutorial book. We should be
>> able to do better.
>> 
>> As I said earlier, I don't think things that can be generated from
>> Axiom belong in the archive. The instructions for generating them -
>> yes, but not the output.
> 
> Those files are part of the original Axiom book (the Jenks book) and
> clearly represent source for the book.

No. The source is a Makefile that reproduces the graphs in exactly the
same way as they are now. BUT, for future versions of the Axiom Book,
the Makefile should set the option to produce higher resolution graphs.
So the actual source is MISSING or HIDDEN inside the Axiom book.

> One of the outstanding problems I have to solve is how to place more
> than one image on a page. That's the one blocking condition to
> reproducing the Jenks book accurately.
> 
> t

Without a clear problem description, nobody is able to help.

\start
Date: Fri, 15 Sep 2006 05:21:49 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

On 09/15/2006 04:35 AM, root wrote:
>>> But look at that file: src/input/mapleok.input.pamphlet
>>> -rw-------   1 hemmecke hemmecke 234633 2006-09-13 10:03 
>>> mapleok.input.pamphlet
>>>
>>> Who is going to read that???
>>>
>> I think this is a good example of something that belongs elsewhere
>> if we agree that the purpose of this archive is source code control.
>> I think keeping these sorts of documents on the Axiom Wiki (or the
>> Axiom Portal if it is personal research), makes better sense than
>> mixing it into the source. I understand Tim's purpose in associating
>> it with the "input" files since these are the closest thing that
>> Axiom has to actual test files.
> 
> mapleok IS an input file. I just took the time to document the
> expected results so you could tell if you got the right answer.
> It is partially on the way to automating regression testing.

Do you really believe that somebody is going to read that file? Even if 
you documented it? I won't I am not a computed that checks whether the 
output that appears on my axiom session agrees byte by byte with what is 
in the .input file. I would have to count at least 100.000 bytes by 
inspection. I guess even if a computer can make errors. In such a stupid 
procedure I am far worse.

> Testing files are clearly part of the source control pile.

Right, but output should be checked automatically. And isn't it better 
to compare the actual Axiom data structures than the OutputForm result?

> Especially since they are run as part of the source code build.

Maybe you should look at Christian's AldorUnit. I think it's much better 
than just inventing a new test environment.

http://www.risc.uni-linz.ac.at/software/aldor/aldorunit

\start
Date: Thu, 14 Sep 2006 23:27:34 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

> No. The source is a Makefile that reproduces the graphs in exactly the
> same way as they are now. BUT, for future versions of the Axiom Book,
> the Makefile should set the option to produce higher resolution graphs.
> So the actual source is MISSING or HIDDEN inside the Axiom book.

Those files have been carefully screenscraped and gimped to fit
the aspect ratio, size, etc. of the book. There is no obvious
way to auto-screenscrape hyperdoc pages.

Those images were made sometime in the early 90s.

\start
Date: Thu, 14 Sep 2006 23:28:58 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

> > One of the outstanding problems I have to solve is how to place more
> > than one image on a page. That's the one blocking condition to
> > reproducing the Jenks book accurately.
> 
> Without a clear problem description, nobody is able to help.

Check the email archives where I was asking for help.

I recently bought a book (The Latex Graphics Companion)
that appears to contain the solution. Now all I have to
do is get educated.

\start
Date: Thu, 14 Sep 2006 23:36:57 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

> > mapleok IS an input file. I just took the time to document the
> > expected results so you could tell if you got the right answer.
> > It is partially on the way to automating regression testing.
> 
> Do you really believe that somebody is going to read that file? Even if 
> you documented it? I won't I am not a computed that checks whether the 
> output that appears on my axiom session agrees byte by byte with what is 
> in the .input file. I would have to count at least 100.000 bytes by 
> inspection. I guess even if a computer can make errors. In such a stupid 
> procedure I am far worse.

Automated testing is a long leap to do in one step. Documenting 
the results of the tests is on part of the solution. 

As to the size of the file, why is everyone afraid of large files?
Rregression test files which will certainly get large.

(For my job I needed to regression test the Intel 01 opcode which
requires 23008 lines of assembler to test various combinations.
Regression test files get large.)

> > Testing files are clearly part of the source control pile.
> 
> Right, but output should be checked automatically. And isn't it better 
> to compare the actual Axiom data structures than the OutputForm result?
>
> > Especially since they are run as part of the source code build.
> 
> Maybe you should look at Christian's AldorUnit. I think it's much better 
> than just inventing a new test environment.
> 
> http://www.risc.uni-linz.ac.at/software/aldor/aldorunit

Advocacy is volunteering. 

I have a solution in mind but you're welcome to implement something.
We clearly need automated regression testing.

\start
Date: Thu, 14 Sep 2006 21:24:28 -0700
From: William Stein
To: list
Subject: Fwd: Re: SAGE

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

...sorry for the delay.

Well, I downloaded the CD and tried it on my laptop and it didn't
work, but then I tried it on my desktop computer and it did! I think
its a great thing to have and to distribute, although I had serious
problems mounting my USB drive and my HDD (I wasn't able to do it at
all) by some issues with user priviliges. I don't know if its because
I'm a complete Lunix morron, or just because there is really and
issue. Well.

Anyway, its too bad that it doesn't work with my laptop! I guess it
has to do with the compatibility of the Linux live CD with my
laptop...its a relatively old Dell (Latitude CPi), which even has some
issues running the Knoppix live CD. I put the CD in and it doesn't
even start loading, it only shows the fist line of booting where it
says the author of the program who wrote the Live CD thing.

Anyway,

thanks for everything again!

Enrique



On 9/13/06, Enrique Acosta <enriqueacostajaramillo@gmail.com> wrote:
> I'm downloading it now,
> but that may take a while since my internet connection is not very
> fast....it is possible that by tomorrow night I could try it out.
>
> I'll be telling you what happens.
>
> Thank you
>
> On 9/13/06, William Stein wrote:
> > On Wed, 13 Sep 2006 18:08:39 -0700, Enrique Acosta
> > <enriqueacostajaramillo@gmail.com> wrote:
> > > By what you told me, I think you should change the documentation in
> > > the sage installation guide, since in the section Pre-built Binary
> > > Install there is not even a mention of coLinux!
> >
> > I rewrote it all this morning.  See attached.
> >
> > > Thank you again...and about your suggestion of me doing the Sage live
> > > CD...well, I would very much like to do it, but as I told you I'm a
> > > Linux Newbie and I don't think there is any possibility that I could
> > > find the time to learn all the stuff I would have to just to try to  
> do
> > > something which I will not even probably manage to do well. But
> > > anyway, do count with my help in whatever comes to your mind, I would
> > > be glad to help out as long as I have the time.
> >
> > I don't know if you noticed, but the Axiom people appear to have
> > made a Live CD that includes SAGE today.  I think they cc'd you
> > the emails about it.  In particular, here's what they wrote to me:
> >
> >     I created an image of Doyen with Sage:
> >
> >     http://alfredo.axiom-developer.org/DoyenSage.iso
> >
> >     I exhort you to try it and let me know if anything is missing. I  
> put a
> >     Sage icon on the Doyen menu. The Sage notebook should be
> >     functional also.
> >
> >     To take for a spin using vmware:
> >
> >      http://alfredo.axiom-developer.org/DoyenVmware.tar.gz

\start
Date: 15 Sep 2006 06:25:33 +0200
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Aldor and Axiom - alternatives?

Cliff Yapp writes:

| On Wednesday 13 September 2006 11:56 pm, Page, Bill wrote:
| 
| > I think that this is so far past our current skill level and
| > the available resources that there is virtually no chance that
| > this will ever be anything but a paper exercise.
| 
| I think it MIGHT be possible for us to make SPAD support the key 
| feature or two we want from Aldor (type behavior, etc.) but even 
| if we do that, we are still faced with the problem that SPAD as 
| a language in Axiom does not have any really good foundation as 
| a documented language.   I guess my question to those of us 
| looking to improve SPAD is this - even if we can change it to 
| support the feature or two we need, how do we document the 
| language?

we just do it. :-)
Whether we convert to Aldor or some other language, we still need to
know the semantics of the SPAD language.  After all, the algebra files
have meanings (with bugs or not).

| Do we have the resources to make a really formal 
| definition?

if we don't then we don't have the resource to move to another
language -- whether imporved SPAD, Aldor, or...

|  How do we tie those definitions to something that a 
| theorem prover could use?

that is called research :-) 

[...]

|                                 Since to make files fully 
| literate we need to not only understand the code but the origins 
| and definitions of the algorithms being implemented, we are 
| looking at a massive effort to spruce up the algebra code no 
| matter which way we go on the programming language side.  I 
| suspect (although I could be wrong) that understanding and 
| documenting properly the design considerations and mathematical 
| theory behind the SPAD code will be such a large effort that the 
| language considerations become secondary, except for the 
| question of what language has the most potential for benefiting 
| us at the 30 year horizon.

In five  years, we might yet another (new) language is better
suited... 

\start
Date: 15 Sep 2006 06:33:39 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

Bill Page writes:

[...]

| > In many vision, even if move zips out (which I can't at the moment),
| > we will accrete more than zips, in term of functionality. The
| > solution to this issue must be somewhere else.
| >
| 
| Could you describe this "vision" a little? What else do you
| envisage adding to the Axiom source distribution?

First, I would like to see the wiki stored as part of the SVN source
-- but I don't expect that to exceed the Axiom source code base.

Second, suppose we succeed in attracting people; I suspect that we
would have more and more branchs and more and more commits.  Frequent
commits make large depot.

[...]

| >  [About installing an SVN server on axiom-developer.org]
| > Bill, if you transform axiom-developer.org into the SVN server
| > I fear that it becomes heavily loaded -- let alone situations
| > where several people hammer on the SVN server to get source out.
| > I have no other good solution at the moment.
| >
| 
| We already have both tla and darcs archives on axiom-developer.org
| These do not seem to lead to any significant load on the server.
| Do you really expect that SVN is that much worse??

no; the question I suspect is how many users do you currently estimate
for tla and darcs?  
My suspicion was that since silver is going to the the mainline, we
would have more and more people looking at it -- otherwise we don't
succeed :-)

\start
Date: 15 Sep 2006 06:35:32 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Fwd: [M#73697383] Re: Disk-quota Request

Tim Daly writes:

[...]

| We clearly need automated regression testing.

*Yes*.

The question is whether you're going to require it be in lisp :-)

\start
Date: 15 Sep 2006 06:40:00 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Axiom Conference Call Sept 14, 2006

| Gaby,
| 
| On September 14, 2006 5:32 PM you wrote:
| > 
| > Tim Daly writes:
| > 
| > [...]
| > 
| > | 10) There was a discussion of which version (Gold, Silver, or
| > |     Build-improvements) to choose when trying to port to a system.
| > | 
| > |     Tim's take on it was that the question revolves around the
| > |     issue of whether the system is known to build on the target.
| > |     If it is known to build then the only issue is whether the
| > |     new Makefiles in Build-improvement works. If it is not known
| > |     to build then Gold should be used so we can isolate the 
| > |     Makefile bugs from the source code bugs.
| > 
| > I always thought it is "silver". 
| > 
| > I thought build-improvements should die (or be closed) once 
| > I'm finished.
| > 
| 
| This issue was related to the fact that I recently sent you some
| patches for building Axiom on Solaris 10/GNU from the build-
| improvement sources. Tim wants to apply these changes to Axiom Gold
| sooner rather than waiting for them to tricle through Silver to
| Gold.

[...]

Thanks for explaining, and thanks for your enthousiasm for the
build-improvemnts branch.  I, too, was (pleasantly) surprised by your
attempt and of course would like results available to people as soon
as possible.  But I fear that "pre-mature" testing with negative
results might make people turn away.  Or the contrary.

\start
Date: Fri, 15 Sep 2006 00:44:18 -0400
From: Alfredo Portes
To: Enrique Acosta
Subject: Re: Fwd: Re: SAGE

Hi,
>
> ...sorry for the delay.
>
> Well, I downloaded the CD and tried it on my laptop and it didn't
> work, but then I tried it on my desktop computer and it did!


  Sorry to hear that you had problems.

I think its a great thing to have and to distribute, although I had serious
> problems mounting my USB drive and my HDD (I wasn't able to do it at
> all) by some issues with user priviliges.


  I assume that your HDD has windows and a NTFS partition. I will look into
  these problems.

  You can always also do "sudo su" to become root and mount devices, but
   this should be working automatically...my bad :-( .


> I don't know if its because
> I'm a complete Lunix morron, or just because there is really and
> issue. Well.


  Not you are not :-). Your feedback right now is one of the most important
  things to improve Doyen.

Anyway, its too bad that it doesn't work with my laptop! I guess it
> has to do with the compatibility of the Linux live CD with my
> laptop...its a relatively old Dell (Latitude CPi), which even has some
> issues running the Knoppix live CD. I put the CD in and it doesn't
> even start loading,


  That puzzles me. Never seem it breaking at that point...one of the things
is
  that Fedora version works better with certain machines...Knoppix on
others.

   I would really appreciate if you can do something for me. Download this
iso:

   http://daly.axiom-developer.org/doyen/doyen04262005.iso

   Let me know if it boots up properly on your laptop. That is a version
based
   Knoppix. We could add Sage to it.

\start
Date: 15 Sep 2006 06:42:32 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Makefile.solaris9 stanza

Bill Page writes:

| On September 14, 2006 7:07 PM Gabriel Dos Reis wrote:
| > 
| > ... reads:
| >     <<Makefile.solaris9>>=
| >     # System dependent Makefile for the Intel/Linux platform
| >     # Platform variable
| >     PLF=LINUXplatform
| >     # C compiler flags
| >     ...
| > why is it described as an Intel/Linux platform?  Just a copy-n-paste
| > thinko?
| > 
| 
| More cruft.
| 
| As far as I can see PLF is defined in Makefile.pamphlet but never
| used anywhere in the source.

It is used deep in the graph source code.  But, the way it is used is
waaaay pure disgusting hack (the author(s) should not feel offensed).
I think I most certainly had sent an email about it in the past -- if
not, then I'm sure I did compose the mail.

It is on my TODO list to remove it along with a better structuring.

\start
Date: 15 Sep 2006 06:44:25 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Makefile.solaris9 stanza

Bill Page writes:

[...]

| So the answer to Gaby's original question then is that for Solaris
| one would expect this variable should be something like:
| 
|   PLF=SUNplatform
| 
| or SUN4OS5platform or ... something like that.

Yes, that is what I expected but found something else.  So I thought
there was a reason for it.

[...]

| Anyway, I think all these flags are an unfortunate mess which should
| really (eventually) be handled by the more general and more standard
| autoconfig mechanisms. Right?

Yes.  I have a plan for that.

\start
Date: 15 Sep 2006 06:47:15 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Makefile.solaris9 stanza

Tim Daly writes:

| On September 14, 2006 9:42 PM you wrote:
| > > 
| > > > > > As far as I can see PLF is defined in Makefile.pamphlet 
| > > but never
| > > > > > used anywhere in the source.
| > > > > > 
| > > > > > I suggest we delete it before somebody tries to use it. We don't
| > > > > > need more flags and special cases in the source if we can avoid
| > > > > > it.
| > 
| > Damn. So I guess it's too late. This stuff is everywhere. ;)
| 
| Yeah, most of those conditionals are what make the C code hard to port.

no harder than the lisp non-portable sutff all over the place in the
Axiom source code.  I don't think we have a perfect language match
here in terms of portability.  I've coded for longtime in C and C++; I
don't think this particular is stuff is handled the proper way.

[...]

| C is the least portable language there is (I know because I had to 
| figure out most of those conditionals). That's one major motivation
| toward rewriting it in lisp.

Please, no.  Lisp does not look more portable than C to me.

\start
Date: 15 Sep 2006 06:48:24 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Makefile.solaris9 stanza

Tim Daly writes:

| > So the answer to Gaby's original question then is that for Solaris
| > one would expect this variable should be something like:
| > 
| >   PLF=SUNplatform
| > 
| > or SUN4OS5platform or ... something like that.
| > 
| > But at least in the case of the build that I was doing on Solaris 10
| > with the GNU toolchain installed, it looks more like a LINUXplatform.
| > I did not patch this variable in my build. (I have no idea whether my
| > compile would have worked if it had been set to SUNplatform.)
| 
| It depends. The issue usually arises because the include file chain
| changes with every platform. However, a linux-compatible include file
| chain could use LINUXplatform. Try not to read too much into the name.

yes, but the name is what people see.  It must be meaningful, are at
least not induce the wrong expectation.  (my original question).

\start
Date: Fri, 15 Sep 2006 00:55:30 -0400
From: Alfredo Portes
To: Enrique Acosta
Subject: Re: Fwd: Re: SAGE

Well, I downloaded the CD and tried it on my laptop and it didn't
> work, but then I tried it on my desktop computer and it did! I think
> its a great thing to have and to distribute, although I had serious
> problems mounting my USB drive and my HDD (I wasn't able to do it at
> all) by some issues with user priviliges. I don't know if its because
> I'm a complete Lunix morron, or just because there is really and
> issue. Well.


  I am the morron :-). In that image, I forgot to add the doyen user to the
  proper groups. If you log out, and login as root, password: doyen@org ,
you
  can see that it should detect your NTFS partition and the mounting should
  work fine. Again sorry for this.

   Also another favor, if you can give me the exact model of your laptop.
Probably
   I can look for one similar to try to reproduce the error.

\start
Date: 15 Sep 2006 00:15:30 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] first step toward a uniform toplevel makefile

  to make it possible to test on more platforms, especially, those NOT
explicilty listed as being know to work, we need a uniform Makefile
file.  This patchlet moves the logic to decide platform specific
variables from the toplevel makefile to the configure file.
Next steps would consist in reducing the differences and actually
allow more platforms.

Tested on:
  * i686-pc-linux (GCL and noweb system-installed)
  * x86_64-suse-linux (noweb system-installed, GCL missing)

-- Gaby

2006-09-14  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet (do-all): Don't generate and call
	Makefile.${SYS} on the fly.  Remove special-cased Makefile
	stanzas. 
	(PLF, CCF, LDF, LISP, GCLOPTS, SRCDIRS): Define as
	Autoconf-substituted. 
	(ENV): Pass them on sub-makes.
	* Makefile.in: Regenerate.
	* configure.ac.pamphlet: Special-case PLF, CCF, LDF, LISP,
	GCLOPTS and SRCDIRS.
	* configure.ac: Regenerate.
	* configure: Likewise.

*** Makefile.pamphlet	(revision 15845)
--- Makefile.pamphlet	(local)
*************** do-all: @axiom_required_build_utils@ sta
*** 41,53 ****
  	@ echo 1 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
  	@ echo 2 Environment ${ENV}
  	@ $(MAKE) stamp-rootdirs
- 	@ ${TANGLE} -t8 -RMakefile.${SYS} $(srcdir)/Makefile.pamphlet \
-                     > Makefile.${SYS}
  	@ ($(axiom_build_document) --weave --latex \
                                     $(srcdir)/Makefile.pamphlet && \
  	   $(mkinstalldirs) ${MNT}/${SYS}/doc/src && \
  	   cp Makefile.dvi ${MNT}/${SYS}/doc/root.Makefile.dvi)
! 	@ ${ENV} $(MAKE) -f Makefile.${SYS} 
  	@echo 3 finished system build on `date` | tee >lastBuildDate
  
  .PHONY: start
--- 41,51 ----
  	@ echo 1 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
  	@ echo 2 Environment ${ENV}
  	@ $(MAKE) stamp-rootdirs
  	@ ($(axiom_build_document) --weave --latex \
                                     $(srcdir)/Makefile.pamphlet && \
  	   $(mkinstalldirs) ${MNT}/${SYS}/doc/src && \
  	   cp Makefile.dvi ${MNT}/${SYS}/doc/root.Makefile.dvi)
! 	@ ${ENV} $(MAKE) srcsetup lspdir srcdir
  	@echo 3 finished system build on `date` | tee >lastBuildDate
  
  .PHONY: start
*************** do-start: @axiom_required_build_utils@ s
*** 61,66 ****
--- 59,67 ----
  <<noweb>>
  <<literate commands>>
  <<install>>
+ <<srcsetup>>
+ <<src>>
+ <<lsp>>
  
  .PHONY: document
  document:
*************** document:
*** 70,77 ****
  do-document: @axiom_build_utils@ stamp-build-scripts
  	@ echo 4 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
  	@ echo 5 Environment ${ENV}
! 	@ ${TANGLE} -t8 -RMakefile.${SYS} Makefile.pamphlet >Makefile.${SYS}
! 	@ ${ENV} $(MAKE) -f Makefile.${SYS} document
  	@echo 6 finished system build on `date` | tee >lastBuildDate
  
  <<rootdirs>>
--- 71,80 ----
  do-document: @axiom_build_utils@ stamp-build-scripts
  	@ echo 4 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
  	@ echo 5 Environment ${ENV}
! 	@mkdir -p ${INT}/doc/lsp
! 	@mkdir -p ${INT}/doc/src
! 	@(cd lsp ; ${ENV} ${MAKE} document )
! 	@(cd src ; ${ENV} ${MAKE} document )
  	@echo 6 finished system build on `date` | tee >lastBuildDate
  
  <<rootdirs>>
*************** COMMAND=${DESTDIR}/mnt/${SYS}/bin/axiom
*** 374,379 ****
--- 377,389 ----
  DAASE = $(axiom_src_datadir)
  NOISE="-o ${TMP}/trace"
  
+ PLF=@PLF@
+ CCF=@CCF@
+ LDF=@LDF@
+ LISP=@LISP@
+ GCLOPTS=@GCLOPTS@
+ SRCDIRS=@SRCDIRS@
+ 
  <<part>>
  
  ENV= SPAD=${SPAD} SYS=${SYS} SPD=${SPD} LSP=${LSP} GCLDIR=${GCLDIR} \
*************** ENV= SPAD=${SPAD} SYS=${SYS} SPD=${SPD} 
*** 383,389 ****
       TANGLE=${TANGLE} VERSION=${VERSION} \
       DOCUMENT=${axiom_build_document} DAASE=$(DAASE) \
       WEAVE=${WEAVE} AXIOM_X11_CFLAGS="${AXIOM_X11_CFLAGS}" \
!      AXIOM_X11_LDFLAGS="${AXIOM_X11_LDFLAGS}"
  
  @
  \subsection{rootdirs}
--- 393,401 ----
       TANGLE=${TANGLE} VERSION=${VERSION} \
       DOCUMENT=${axiom_build_document} DAASE=$(DAASE) \
       WEAVE=${WEAVE} AXIOM_X11_CFLAGS="${AXIOM_X11_CFLAGS}" \
!      AXIOM_X11_LDFLAGS="${AXIOM_X11_LDFLAGS}" \
!      PLF="$(PLF)" CCF="$(CCF)" LDF="$(LDF)" LISP=$(LISP) \
! 	GCLOPTS="$(GCLOPTS)" SRCDIRS="$(SRCDIRS)"
  
  @
  \subsection{rootdirs}
*************** GCLOPTS="--enable-vssize=65536*2 --enabl
*** 798,1149 ****
           --enable-machine=pwerpc-macosx"
  @
  
- \subsection{Makefile.freebsd}
- Annoyingly enough it seems that GCL uses a default extension of .lsp
- rather than .lisp so we add the [[LISP]] variable here. We need to
- depend on the default extension behavior because the system build
- will load either the interpreted or compiled form of a file depending
- on which is available. This varies at different stages of the build.
- <<Makefile.freebsd>>=
- # System dependent Makefile for the FreeBSD platform
- # Platform variable
- PLF=BSDplatform
- # C compiler flags
- CCF="-O2 -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/local/include"
- # Loader flags
- LDF="-L/usr/local/lib"
- LISP=lsp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS} TANGLE=${TANGLE}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 45 Makefile.FreeBSD called
- 	@echo 46 Environment : ${ENV} 
- 	@echo 47 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.windows}
- This is for the Windows port. We assume that the build will be done
- using GCC under MSYS.
- 
- We've modified the [[GCLOPTS]] variable from the standard config in
- two ways. First we add [[--enable-debug]] so more information is
- available for testing and second we removed [[--enable-statsysbfd]].
- 
- <<Makefile.windows>>=
- # System dependent Makefile for the Intel/Windows/MSYS platform
- # Platform variable
- PLF=MSYSplatform
- # C compiler flags
- CCF="-O2 -Wall -D_GNU_SOURCE -D${PLF}"
- # Loader flags
- LDF=
- LISP=lsp
- <<GCLOPTS>>
- SRCDIRS=bootdir interpdir sharedir algebradir etcdir docdir inputdir
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
-       LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 45 Makefile.windows called
- 	@echo 46 Environment : ${ENV} 
- 	@echo 47 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.linux}
- Annoyingly enough it seems that GCL uses a default extension of .lsp
- rather than .lisp so we add the [[LISP]] variable here. We need to
- depend on the default extension behavior because the system build
- will load either the interpreted or compiled form of a file depending
- on which is available. This varies at different stages of the build.
- <<Makefile.linux>>=
- # System dependent Makefile for the Intel/Linux platform
- # Platform variable
- PLF=LINUXplatform
- # C compiler flags
- CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
- # Loader flags
- LDF=
- LISP=lsp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 45 Makefile.linux called
- 	@echo 46 Environment : ${ENV} 
- 	@echo 47 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.gentoo}
- Annoyingly enough it seems that GCL uses a default extension of .lsp
- rather than .lisp so we add the [[LISP]] variable here. We need to
- depend on the default extension behavior because the system build
- will load either the interpreted or compiled form of a file depending
- on which is available. This varies at different stages of the build.
- 
- We've modified the [[GCLOPTS]] variable because [[bfd]] does not seem
- to work on Solaris 9. So we use a local version shipped with GCL.
- <<Makefile.gentoo>>=
- # System dependent Makefile for the Intel/Linux/Gentoo platform
- # Platform variable
- PLF=LINUXplatform
- # C compiler flags
- CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
- # Loader flags
- LDF=
- LISP=lsp
- <<GCLOPTS-LOCBFD>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 45 Makefile.linux called
- 	@echo 46 Environment : ${ENV} 
- 	@echo 47 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.fedora64}
- Fedora Core 2 on the AMD 64 uses 64 bit libraries. We need to change the
- loader flags so these libraries are used otherwise the graphics won't build.
- <<fedora64 loader flags>>=
- LDF="-L/usr/local/lib64 -L/usr/openwin/lib64 -L/usr/lib64 "
- @
- <<Makefile.fedora64>>=
- # System dependent Makefile for the Intel/Linux platform
- # Platform variable
- PLF=LINUXplatform
- # C compiler flags
- CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
- # Loader flags
- <<fedora64 loader flags>>
- LISP=lsp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 45 Makefile.linux called
- 	@echo 46 Environment : ${ENV} 
- 	@echo 47 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.fedora3}
- Fedora Core 3 needs special GCL options for local bfd.
- <<Makefile.fedora3>>=
- # System dependent Makefile for the Intel/Linux platform (Fedora Core 3)
- # Platform variable
- PLF=LINUXplatform
- # C compiler flags
- CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
- # Loader flags
- LDF=
- LISP=lsp
- <<GCLOPTS-LOCBFD>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 45 Makefile.linux called
- 	@echo 46 Environment : ${ENV} 
- 	@echo 47 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.linuxglibc}
- <<Makefile.linuxglibc>>=
- # System dependent Makefile for the SPARC SUNOS 4.1.2 platform
- # Platform variable
- PLF= LINUXplatform
- # C compiler flags
- CCF=" -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE  -D${PLF}"
- # Loader flags
- LDF=
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 48 Makefile.linuxglibc called
- 	@echo 49 Environment : ${ENV} 
- 	@echo 50 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.linuxglibc2.1}
- <<Makefile.linuxglibc2.1>>=
- # System dependent Makefile for the SPARC SUNOS 4.1.2 platform
- # Platform variable
- PLF= LINUXplatform
- # C compiler flags
- CCF=" -g  -Wall -D_GNU_SOURCE  -D${PLF}"
- # Loader flags
- LDF=
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 51 Makefile.linuxglibc2.1 called
- 	@echo 52 Environment : ${ENV} 
- 	@echo 53 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- \subsection{Makefile.solaris9}
- Annoyingly enough it seems that GCL uses a default extension of .lsp
- rather than .lisp so we add the [[LISP]] variable here. We need to
- depend on the default extension behavior because the system build
- will load either the interpreted or compiled form of a file depending
- on which is available. This varies at different stages of the build.
- <<Makefile.solaris9>>=
- # System dependent Makefile for the Intel/Linux platform
- # Platform variable
- PLF=LINUXplatform
- # C compiler flags
- CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
- # Loader flags
- LDF=
- LISP=lsp
- <<GCLOPTS-LOCBFD>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 45 Makefile.linux called
- 	@echo 46 Environment : ${ENV} 
- 	@echo 47 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- 
- \subsection{Makefile.sun4os55g}
- <<Makefile.sun4os55g>>=
- # System dependent Makefile for the SPARC SUNOS 5.5 platform with GNU compiler
- # Platform variable
- PLF= SUN4OS5platform
- # C compiler flags
- CCF=" -O3 -D__EXTENSIONS__ -Wall -ansi -D${PLF} -I /usr/openwin/include"
- # Loader flags
- LDF=-L /usr/openwin/lib -lnsl -lsocket 
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 69 Makefile.sun4os55g called
- 	@echo 70 Environment : ${ENV} 
- 	@echo 71 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
- 
- \subsection{Makefile.sung}
- <<Makefile.sung>>=
- # System dependent Makefile for the SPARC SUNOS 4.1.2 platform
- # Platform variable
- PLF= SUNplatform
- # C compiler flags
- CCF=" -O -D${PLF} -I/usr/openwin/include"
- # Loader flags
- LDF= -L/usr/openwin/lib
- LISP=lisp
- <<GCLOPTS>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 75 Makefile.sung called
- 	@echo 76 Environment : ${ENV} 
- 	@echo 77 finished system build on `date` | tee >lastBuildDate
- 
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
  \subsection{Makefile.MACOSX}
  On the MAC OSX someone decided (probably a BSDism) to rename the
  [[SIGCLD]] signal to [[SIGCHLD]]. In order to handle this in the 
--- 810,815 ----
*************** We need to explicitly put [[-I/usr/inclu
*** 1158,1191 ****
  [[-I/usr/include/sys]] because the MAC seems to search in a
  different order than linux systems. The [[sys]] versions of 
  the include files are broken, at least for Axiom use.
- <<Makefile.MACOSX>>=
- # System dependent Makefile for the MAC OSX platform
- # Platform variable
- PLF=MACOSXplatform
- # C compiler flags
- CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} \
-      -I/usr/include -I/usr/include/sys"
- # Loader flags
- LDF=
- LISP=lsp
- <<GCLOPTS-CUSTRELOC>>
- <<SRCDIRS>>
- 
- ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} \
-     LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
-     SRCDIRS=${SRCDIRS}
- 
- all: stamp-rootdirs srcsetup lspdir srcdir
- 	@echo 45 Makefile.linux called
- 	@echo 46 Environment : ${ENV} 
- 	@echo 47 finished system build on `date` | tee >lastBuildDate
  
- <<srcsetup>>
- <<src>>
- <<lsp>>
- <<document>>
- 
- @
  \eject
  \begin{thebibliography}{99}
  \bibitem{1} CMUCL {\bf http://www.cons.org/cmucl}
--- 824,830 ----
*** README.build-improvements	(revision 15845)
--- README.build-improvements	(local)
*************** Gabriel Dos Reis
*** 56,61 ****
--- 56,63 ----
  
  * Fix Makefile generation dependencies.
  
+ * Find a better structuring for PLF, CCF, LDF, LISP.
+ 
  * Have Axiom configure pass down tp GCL options specified on the
    invokation line.
  
*** configure.ac.pamphlet	(revision 15845)
--- configure.ac.pamphlet	(local)
*************** AXIOM=`pwd`/mnt/$SYSNAME
*** 399,404 ****
--- 399,518 ----
  AC_SUBST(AXIOM)
  @
  
+ 
+ The old build machinery has hard-coded special-cased Makefile for 
+ some known platforms.   We would like to have a uniform, Makefiles with 
+ varying bits computed at configuration time.  As a transitional path 
+ from the current system to the new build framework, we have moved the
+ old logic from toplevel Makefile to here.  It is understood that in the
+ near future the logic will be improved to support more platforms.
+ <<platform specific bits>>=
+ SRCDIRS="bootdir interpdir sharedir algebradir etcdir clefdir docdir \
+         graphdir smandir hyperdir inputdir "
+ 
+ case $SYSNAME in
+     freebsd)
+         PLF=BSDplatform
+ 	CCF="-O2 -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/local/include"
+ 	LDF="-L/usr/local/lib"
+ 	LISP=lsp
+ 	GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=256*1024"
+ 	;;
+ 
+     windows)
+         PLF=MSYSplatform
+ 	CCF="-O2 -Wall -D_GNU_SOURCE -D${PLF}"
+ 	LDF=
+ 	LISP=lsp
+ 	GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=256*1024"
+ 	SRCDIRS=bootdir interpdir sharedir algebradir etcdir docdir inputdir
+ 	;;
+     linux)
+         PLF=LINUXplatform
+         CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
+ 	LDF=
+ 	LISP=lsp
+ 	GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=256*1024"
+ 	;;
+     gentoo)
+         PLF=LINUXplatform
+ 	CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
+ 	LDF=
+ 	LISP=lsp
+ 	GCLOPTS="--enable-vssize=65536*2 --enable-locbfd --disable-dynsysbfd \
+              --disable-statsysbfd --enable-maxpage=256*1024"
+ 	;;
+     fedora64)
+         PLF=LINUXplatform
+ 	CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
+ 	LDF="-L/usr/local/lib64 -L/usr/openwin/lib64 -L/usr/lib64 "
+ 	LISP=lsp
+ 	GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=256*1024"
+ 	;;
+     fedora3)
+         PLF=LINUXplatform
+ 	CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
+ 	LDF=
+ 	LISP=lsp
+ 	GCLOPTS="--enable-vssize=65536*2 --enable-locbfd --disable-dynsysbfd \
+              --disable-statsysbfd --enable-maxpage=256*1024"
+ 	;;
+     linuxglibc)
+         PLF= LINUXplatform
+ 	CCF=" -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE  -D${PLF}"
+ 	LDF=
+ 	LISP=lisp
+ 	GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=256*1024"
+ 	;;
+     linuxglibc2.1)
+         PLF= LINUXplatform
+ 	CCF=" -g  -Wall -D_GNU_SOURCE  -D${PLF}"
+ 	LDF=
+ 	LISP=lisp
+ 	GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=256*1024"
+ 	;;
+     solaris9)
+         PLF=LINUXplatform
+ 	CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
+ 	LDF=
+ 	LISP=lsp
+ 	GCLOPTS="--enable-vssize=65536*2 --enable-locbfd --disable-dynsysbfd \
+              --disable-statsysbfd --enable-maxpage=256*1024"
+ 	;;
+     sun4os55g)
+         PLF= SUN4OS5platform
+ 	CCF=" -O3 -D__EXTENSIONS__ -Wall -ansi -D${PLF} -I /usr/openwin/include"
+ 	LDF=-L /usr/openwin/lib -lnsl -lsocket 
+ 	LISP=lisp
+ 	GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=256*1024"
+ 	;;
+     sung)
+         PLF= SUNplatform
+ 	CCF=" -O -D${PLF} -I/usr/openwin/include"
+ 	LDF= -L/usr/openwin/lib
+ 	LISP=lisp
+ 	GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=256*1024"
+ 	;;
+     MACOSX)
+         PLF=MACOSXplatform
+ 	CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} \
+ 	    -I/usr/include -I/usr/include/sys"
+ 	LDF=
+ 	LISP=lsp
+ 	GCLOPTS="--enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-locbfd \
+ 	    --disable-statsysbfd  --enable-custreloc --disable-tkconfig \
+ 	    --enable-machine=pwerpc-macosx"
+ 	;;
+ esac
+ AC_SUBST(PLF)
+ AC_SUBST(CCF)
+ AC_SUBST(LDF)
+ AC_SUBST(LISP)
+ AC_SUBST(GCLOPTS)
+ AC_SUBST(SRCDIRS)
+ @
+ 
+ 
  \subsubsection{Instantiating configuration files}
  
  <<instantiate config files>>=
*************** AC_SUBST(X_PRE_LIBS)
*** 507,512 ****
--- 621,627 ----
  <<locate X11>>
  
  <<replicate old behaviour>>
+ <<platform specific bits>>
  <<instantiate config files>>
  @
  
\start
Date: Fri, 15 Sep 2006 10:17:04 +0200
From: Kai Kaminski
To: Gabriel Dos Reis
Subject: Re: Makefile.solaris9 stanza

Gabriel Dos Reis writes:

> Tim Daly writes:
>
> | On September 14, 2006 9:42 PM you wrote:
> | > > 
> | > > > > > As far as I can see PLF is defined in Makefile.pamphlet 
> | > > but never
> | > > > > > used anywhere in the source.
> | > > > > > 
> | > > > > > I suggest we delete it before somebody tries to use it. We don't
> | > > > > > need more flags and special cases in the source if we can avoid
> | > > > > > it.
> | > 
> | > Damn. So I guess it's too late. This stuff is everywhere. ;)
> | 
> | Yeah, most of those conditionals are what make the C code hard to port.
>
> no harder than the lisp non-portable sutff all over the place in the
> Axiom source code.  I don't think we have a perfect language match
> here in terms of portability.  I've coded for longtime in C and C++; I
> don't think this particular is stuff is handled the proper way.
I'm not going to start another pro-Lisp discussion. But I'd like to
point out that Axiom's Lisp code is not representative of (modern)
Lisp code. Furthermore the conditionals aren't organized very well and
most of them are superfluos anyway, because they are for Lisps that
are long dead and forgotten.

> [...]
>
> | C is the least portable language there is (I know because I had to 
> | figure out most of those conditionals). That's one major motivation
> | toward rewriting it in lisp.
>
> Please, no.  Lisp does not look more portable than C to me.
That could be argued, I guess. Besides Lisp has quite a few other
advantages over C. :-)

\start
Date: 15 Sep 2006 10:26:41 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: putting pamphlets on MathAction

unfortunately, it doesn't seem to work yet. How can I make MathAction compile a
pamphlet?

It seems that RECOP and the constructors in fffg.spad were compiled, but those
from mantepse weren't. Furthermore, I had to fix a typo in RECOP, but I didn't
manage to recompile it. Could you please try?

I put the things into the places were I feel they belong.

rec.spad is now linked from RecurrenceRelationOperator, fffg.spad from
FractionFreeFastGaussianElimination and mantepse.spad from
GuessingFormulasForSequences.

The pages Guess and SandBoxFFFG should be deleted.

\start
Date: 15 Sep 2006 11:10:22 +0200
From: Gabriel Dos Reis
To: Kai Kaminski
Subject: Re: Makefile.solaris9 stanza

Kai Kaminski writes:

| Gabriel Dos Reis writes:
| 
| > Tim Daly writes:
| >
| > | On September 14, 2006 9:42 PM you wrote:
| > | > > 
| > | > > > > > As far as I can see PLF is defined in Makefile.pamphlet 
| > | > > but never
| > | > > > > > used anywhere in the source.
| > | > > > > > 
| > | > > > > > I suggest we delete it before somebody tries to use it. We don't
| > | > > > > > need more flags and special cases in the source if we can avoid
| > | > > > > > it.
| > | > 
| > | > Damn. So I guess it's too late. This stuff is everywhere. ;)
| > | 
| > | Yeah, most of those conditionals are what make the C code hard to port.
| >
| > no harder than the lisp non-portable sutff all over the place in the
| > Axiom source code.  I don't think we have a perfect language match
| > here in terms of portability.  I've coded for longtime in C and C++; I
| > don't think this particular is stuff is handled the proper way.
| I'm not going to start another pro-Lisp discussion. But I'd like to
| point out that Axiom's Lisp code is not representative of (modern)
| Lisp code. Furthermore the conditionals aren't organized very well and
| most of them are superfluos anyway, because they are for Lisps that
| are long dead and forgotten.

Probably.


I followed this discussion

  http://www.math.utexas.edu/pipermail/maxima/2006/014309.html

with some interest.

\start
Date: 15 Sep 2006 11:54:05 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: Help with adding algebra URGENT!

Martin Rubey writes:

> Dear Tim, *

do I have to modify the daase files if I add two algebra files, one depending
on the other?

Martin

> 
> I'm having problems adding algebra.
> 
> I have a package FiniteAbelianMonoidRingFunctions2, short FAMR2, and another
> one, FractionFreeFastGaussianFractions, short FFFGF, which depends on the
> former.
> 
> I modified the Makefile.pamphlet in src/algebra as follows:
> 
> USERLAYER=\
>   ${OUT}/FAMR2.o   \
>   ${OUT}/FFFGF.o   \
> @ 
> 
> 
> I also modified exposed.lisp.pamphlet appropriately. However, make NOISE= keeps
> complaining:
> 
>   Semantic Errors:
>       [1] generalInterpolation:  FiniteAbelianMonoidRingFunctions2 is not a known type
> 
> (generalInterpolation is an operation defined in FFFGF.)
> 
> I also tried to add FAMR2.o into the previous layer, i.e. layer 23, but that
> didn't change things either.
> 
> If I remove FFFGF, the build completes and FAMR2 is visible... 
> 
> What did I do wrong?

\start
Date: Fri, 15 Sep 2006 11:54:36 +0200
From: Kai Kaminski
To: Gabriel Dos Reis
Subject: Re: Makefile.solaris9 stanza

Gabriel Dos Reis writes:

> | > | Yeah, most of those conditionals are what make the C code hard to port.
> | >
> | > no harder than the lisp non-portable sutff all over the place in the
> | > Axiom source code.  I don't think we have a perfect language match
> | > here in terms of portability.  I've coded for longtime in C and C++; I
> | > don't think this particular is stuff is handled the proper way.
> | I'm not going to start another pro-Lisp discussion. But I'd like to
> | point out that Axiom's Lisp code is not representative of (modern)
> | Lisp code. Furthermore the conditionals aren't organized very well and
> | most of them are superfluos anyway, because they are for Lisps that
> | are long dead and forgotten.
>
> Probably.
>
>
> I followed this discussion
>
>   http://www.math.utexas.edu/pipermail/maxima/2006/014309.html
>
> with some interest.
Ok, I read the first dozen messages or so, but I'm not sure what
you're aiming at (IEEE 754 or FFI?). Could you give me a hint?

\start
Date: 15 Sep 2006 12:20:42 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: Help with adding algebra URGENT!

Yet another question:

I just noticed that the constructor RINTERP is not found by HyperDoc, only the
operation it exports. 

After using one of the operations, RationalInterpolation is found, but RINTERP
still isn't.

Tim, you added RINTERP some months ago into the user layer. I suspect that one
somehow needs to rebuild the databases to make it available.

How?

PLEASE HELP, I need it for the conference, for the CD's.

Martin


Martin Rubey writes:

> Martin Rubey writes:
> 
> > Dear Tim, *
> 
> do I have to modify the daase files if I add two algebra files, one depending
> on the other?
> 
> Martin
> 
> > 
> > I'm having problems adding algebra.
> > 
> > I have a package FiniteAbelianMonoidRingFunctions2, short FAMR2, and another
> > one, FractionFreeFastGaussianFractions, short FFFGF, which depends on the
> > former.
> > 
> > I modified the Makefile.pamphlet in src/algebra as follows:
> > 
> > USERLAYER=\
> >   ${OUT}/FAMR2.o   \
> >   ${OUT}/FFFGF.o   \
> > @ 
> > 
> > 
> > I also modified exposed.lisp.pamphlet appropriately. However, make NOISE= keeps
> > complaining:
> > 
> >   Semantic Errors:
> >       [1] generalInterpolation:  FiniteAbelianMonoidRingFunctions2 is not a known type
> > 
> > (generalInterpolation is an operation defined in FFFGF.)
> > 
> > I also tried to add FAMR2.o into the previous layer, i.e. layer 23, but that
> > didn't change things either.
> > 
> > If I remove FFFGF, the build completes and FAMR2 is visible... 
> > 
> > What did I do wrong?

\start
Date: Fri, 15 Sep 2006 07:36:34 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: Help with adding algebra URGENT!

pls tar up your copy of the spad code and i'll wrestle with it.
i don't know the answer off the top of my head so it will take
some work. --t

\start
Date: 15 Sep 2006 13:57:42 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: Help with adding algebra URGENT!

Tim Daly writes:

> pls tar up your copy of the spad code and i'll wrestle with it.
> i don't know the answer off the top of my head so it will take
> some work. --t
Would be really great!


--=-=-=

H4sIABldCkUAA+19a3fbRpLofF39ih5bOQElihFpJ7mHEzvRSGbi3djWlZxM9jpODkSCEkYgQAGg
HvZ6f+39Dfvpfrj16CfQAClZ8mZmxeRYJNBdXV1dXV1dXVU9C9MymhdRr5iHk948nM1Pkqj8061+
tuHz1fY2/u1/9VWf/25/Rc+3B/3B4y8f/6m//eU2fPny6+1Hf9ruPx7Aa7F9u2j4P4uiDHMh/pQv
jqKrlnLjbHb0KfD5xJ9fJ9l4MYvScpyERfE+zMt4nEQf1n5dFNE8HJ+Gx9H78DLOZvAojS6ACrMw
nbz/dYeevX//a1kK/l4pcBCWkXxPXyuvvx/99FK+pq/w+ig6jtP3Ch94UMZlEr2f2RwKT8NFeZLl
718gqqk4wGGDp7PwNKLyCk54VJR5OAY4Qrw+iYTsTCEm0TROo4mAyuVJXIhpnEQiSsMj+KP6JcpM
HC+iAt5m+WwBpMEvAKmIzhZROgYw2bSLz0R0CXMmiboiD8s4S8NEpIvZUZRDidw8my7SMX4tuuI4
Po+w6QjATeO8KMU0uhBllM+KnhDPS4BYRumkEEAnAfQC4EiPQuye5HFRxmEq/g3gQpnyJEyi/PMC
AM3z7DgPZ4LI/itVhRZEHiXROdAPep+XiLP4a75IM3EYJudXVGo/XCTi/8SzGbQfpikBo8Hprf0K
WFhk/LVEEmXTcZZi28Xar0VEfYIhm4VAzZ9G+4fipzQ+D/MYsBgB5cJkP7uI8sMoj6Piw9o336xY
9OnTJ2ud8Ogoj87FilXWWt4Fu1k0HYqDOD3uiCdPBPRRWLBeh1dJZhftis8vu2J7Hb931ta+W/ts
fc10V3ISYdRvQ2mkBh17fv1aNhGuX7uNHrqQTZiheHY5z5BNgELPFdsRAyPBLk6iPFpjyuFQPHny
tA0PgZC5uAX2Ii5P+KEQJ+EknIX5ZCgCBNglsB2x9ZS+cKkKGgAhnEyqAAIYLxpX+RxnKaEwC+fB
w/7Gw0EX5lE0ncbjmCbStPL7uKNrms/6YZlH4UyT6pHkDPNvR9RYQ/Lq96/2X4vvUX68muNzi/Or
rzycXi2ytrkpdkjoDYUt9fD5XlSM85iKDe06AgRbqABenGQFiDglR8I8Ejhs2QIkApUuBEj7CcI7
uhK/opwtr+bRe4L3obdmwQ1a2YR4ROD4WGUOo3IXOOQ4y6+s8Z+Fl3swSudQ8TwaiucgU46jHEf/
MzkYgI1TKJh0RDGPxvEUxxalG7yOZ4sZSHRVBoU6yMcwOY6O8jAeG1CTeDoF5FKQn4kAIU4I9yot
bPXdJsLSbscCZhocQ3NHEdD0KAY5mV/1YLGJFV1xFKLLeQ7kUwtORCuKAUXUfu+ggUSbANkVnQ5P
4mnZQiJ630ydAl8TYWA5GC/yHNcvA8ChBYNqJ4MEyB03cK5JAdNxalP1WQjVa5IlLb2m9208cZxH
NX5w2MBHg5G9oiM8CQdWzmD6+eed3x6J6efYqcc9gwTQy8BqIRwQIkuh7aVMY2HWTjtq3+GXk2yW
HUdpBJN7KP6aZUkEbbnEs4q49IPpC03k4gJQS5LsQmRpcmUXX3liFTebBnZTlUnwY3QeJS3sQO+b
2YF1MhxGmgMFYpVgFcQxAnUqyy2qk+q3n2eTxbgkLYkeHAKcizhJaOjm8ySOJj2DmztrDCziAiCn
ag6lb5lT3RtKCmquSp894tNWQYoFlk4YoBA+tdZHA2WeJVdpNsOBbptXmgtQAw4tgpP090GzV+Oe
1Z1rCGRC/haFMcGzaQxDyE8b55Up4Z9WyATzrCjioziJy5j2ELaMOQclgjYZEt6WKMNT0MwAV9iO
hONxtgDZYbDbAkmcLZIJdtnmqBg1nximrgEFEGB0YPMA0Kb2voRewEhI8ddCLpujHTFkuu3Qqwin
UXk1FC+z9GV0TAubnze5YJ0xzZQ9DxOYf8BIoNedAzLYg1L2JkytbhZZsmB9Zgq0WnGGyW4wGkaL
RK5SfQGp3TTo8KpZiMJUPwFJwXoPFtUYOqhZ49SOI0KwaTyJjhbHTZjRy0bcLnBXCMp0LBkhW5Tz
RQk4yp2pmqS4rwR0rkVKatlBVG1/X4YzoOTh1ewoSyro2kU8zABP1XRRJeVOGlRWB+UVhJLRg262
8tq4Ov2k3RDsklv6aRep91O9JYUcW+beXUOjvYnEs3Fy+hOnk+iypTP6fb0n9KrSH5q4Egc0qjC2
1mRaib10o+5ciIt5El7tFN+PGmeEKeKfF2wyKRZJyfsn1EVQVKLUlENuIZs7GrVLeSmZ06xE6VxE
pRpIoEPeFUcw1QAwtGngyQI/7G9JxMY8olIEMVzYLP8YF6X4rCsHhDfMKW7NdtKrrngwDeMkmjzo
VKkadLBPiBAsJkdyQOR6WmZzVk/+ImqDMYnQNBWnQCZaLEBYgFJ4cRKPT8QkDy+QOGoXiQIPRgcx
55GzZiUVFtL+53TqW3+n5BhWEfp2tY7UqtnY51G5yAHfMl8QZ9U6wt3D7ji8bjrmdqeLzDANkyKS
LI77bQMDcJUdHp9E41PeSYMawZ3Gvv6cxRPTkl2Kf1hKRGrNEmlKvIhpQ7fmsZc8JYMJTeUZ7sgF
MIk2afQDSeNOcwk5IM0F5KLeUqKuAXSYGgfRXAyfwJ9xlk+C0+jqIkNzEDfZ5WV/iMA61r6Qtd8J
EwsEwJsH6uGD4VBVpc9kOIS6b+vmBqitKpqHVu1KRd6gmhYrsFwNXJYz8PFhBTMbvqU9TXRF89Ct
WUGMd38VUtDDNlJIRUdWkxX5YbWaW9HenU1UReuhU9uuyPqAbpAr0sN6g05F1HdMNVkRHnqquRWd
BXoiK9oPbQh2RWclVBXth00VzaJkMYB+2MIA1qJkqGo99FKVhUkW5eMouBx+1hm+IvUNrbAI4LKn
JpPzAp7znLKeEiQAAW+v4F/nY0PC9/o7boklLHpO3xyRHgC6hWWTRbF4iYIzAeE7j0K1qxROC7CD
eCqFM8lmVRklqw3+o6EHEnu1SqpVsy6lRWKaiae07ESzeXn1LbwAgZzqluDlFMY7CPhMJ+lYLT/s
qx9d1C/wLexVYY3Q7SooCNJtn8vrAhEuMlGeQ48fWHbZoZB2X6XUTHhZeIAm6vrRBZqYt217sRbX
2/ZZRUsx3+FES/EmG7ZoM2Kb6rgPOY8nkbLWEGXIHBBd0vEUbQFIu6atIuwU1FKOvNFq0jatrGrc
/pEs9Li40gpum+pXNH1LaxYDgvVfrot1i5ZRVUC7MWOrX0PntvoipFPNEPRWYxCS9tPWJngBaWyC
Xzc3YRvwW9uxlsvGxqwyzS1KU3hrY7xcN7bDr+tNGA1DmdKWdIlW+5busDnN3xXbmKSbqSm8lm6g
2rmpLaliKVK2bcIJntIOB6VsxXijcavrcFUDTgMp5Eugg4cMZFdp7j8u/9WOX4A6HQFcMk3bFpVu
pTu4fvhs4s3N2fqNp9mPNYlXEbRWNdc8ojHkdd9vInHIvdQ6sjKWNSR9do1GBB3tqQnBBhPHygac
KoqXNVNFI35GSWtCrsVqYY2DNF9UMUk9lohmdrMVv38MUwRJjTyC7kfyK+/EK7NaWiVbek77Ac8U
azVKaltk14bknVEtbgN65XT1ugCIhXtRo1+abaUYqj1pp6K2uRrgVl9+JR1NP4Z+oobCLfB2dr1h
C+3Zqq6CprWJ/fS48nqa1DfGSW1JXbEztGP+xB2xltqlSFq781WxZM68GaKWjcbd+K9CTbYGfDpi
Shzlqr8UQ2l2WBW//nqjHhIZAl8H4eHQA1HbHpbij7aIVZG3NrQ3ZgHLnLIUNzawfFIOrZmJliJp
m48+PaqOvrIUV8cMtCqyDy6tojdEWtlg66atO8J5ess4G71rKcLGZLYytuktY2srZstnmWWpWxVj
n/nGbhRVNdDTHnw0j3tNPz89Ozxkm4Vj6jGPvaYd83pld0RSQhWA2PgxkzMNnbZMjT91T+wrB22l
b+NGOytKOmQBLQ4JykdM0hg0wQ1lxbQjRfiH7po63DTv9rXDyYeuiMqxtAIFo6447Ipnv+wfHHTF
QVdRuCsNrMuNQjQ2oOuP4iixzdX+z9aWePfXHpQ+2NkV+69+/HexPxJfrsFjoORIXMT5RLtlxFFe
igU6IEEz45MUlHfm0cOh+H482SP/zjVZl+gKqB6EpZj91/ikBKrjIV0cib8t8ndRkopzQFmSAfaG
/w/9K0agPBclOoCnPfG3KAUcEB4o1OJ/L7ISfXKi9PS/8jmUjQugyiSEMqf4D0EHOC+hFuojWQHK
BjzoIQDoyf+FsaLSILAz8b9HuzuvhXTsPRiKf83iNHgF5fNochgBYBq7PEy4V50maj1/+Zp6jP16
lsNWMY0LPG6jpkWIfQLcaTihdShQlFGSlFgFPvRcNv6MD5lhHA+BTaMqBrzPsCuoSUbFlVnIX83+
HDBDoRx+nSGHuQ+UeX9JPd3cbjY7ilN0WQNWfjUvlImx3vA+Tk/Ay9pGo6u3PmW1HLLU5/cNPGP+
rPtZxz4812+/aH270V47XczY1Q4KfeYrAAMI8zNtK3Kco2fPt+q12lvWut76UUyFY0v8BA/ou8Nl
yO7i76E4j/KjrMTpAeLtJEyODPen8E+Jc2Uawi8CcYDAoMpFBCtZqiAfiOgSgzdgPndRgUkKEQNr
ppMLBAUAZrDdpfooDGDKw/wvyv9XvitJIMDOmlie4lASrBfZUzyK4VGZ4FdrEkpdXIqzoThAgo2W
UyXe3HoaU1UWgDD5sCZ3Y5Wq8GsHcFsAp3Gl/3yiaENgW+zn+JqPEfC1/yiBCr18+ZyKNGwI9vnt
flbE1VeICb81898x8dJad/Ds8KcfLSTlIbXSvoZqvchQgA0RnY4JjhgtjY4Y6bL9ZWVNRIeuszz6
QorZw5/2qSgIrLyITAWzFFpAf9pfjjcCHHGd0Wj0PZUfIXvhEMGWeBQW5ffhAogqDT5YatRaTD0v
iMUxsGK6Y+xbe89Ho8P9Z7s7BCMAOncF/YOYcLiI7KsuOaoWVb3j0qYHusYvVg0ljWl8O5rxCTky
msfhMRun2GK4uzULyzy+dCDuMm8Cj25J/gEkqcQP+/ieXkuWYt9iCjYZKvZBPOkJ/65Ldv6wsV/V
lTWwFw3l0WlSt2QG3W0NH3kWI/6gX5aBEMhJYHntSED8ogHIztCifWMhUKjMkDaW+sUq9UtTqV2r
wd0ODSXo2JE8QaTjXHsYellHnICoLTN1GB0mF+EV6KjPU5GxsRJGrujingA1VYBXcL8pnjCNS1Am
5DGxNL+C+pYdp/E7ENjKTqowesnCiCSlV86iOnYspevZb/GakVLPDphzicVg1Eiy0jhYQkxOVxjX
Q2ci8hTSL0f1l3Ke/ExvpKr2s9xRYpPBm8/Dfld8vvOWD9Jx5RxZAufFIinrIgcV7p+5wsjU0A3T
I4OVpwShZorht8PlrR66rR7WWz10W/VQi58TAx3l4WIM8/8E1nReU7qgg8YJLdJKL0X1AfVUWPCP
YdcQp5EgVwyM3fy/oJPyguSPjyOGlE5io+qQKtbQLpwcrZp8kJEJhXK7P48SGdIFSxeXArnzAV04
akB0iZ29ZxQCS0d5i/EYF0l0dZJ6JIa/ogvImdwf4OGjDQyrJYA2Kkxsn9cOgngCiFvEI9un3GBg
Nms1twTa+eF5TK9CoCXM76cU7t0lUp0/GM0wWJnP7my3yvaekxrFAkH+skTyatSgL6B0Il2aaFIq
1Gw4quKSzsfoklEIjB6GTZI8JrZtNgYYBtq4tGqu7MbqlNkfgQ+bRuP6LPrHGBQLKRiaDyuPTQMM
OVh6tlyP7dnAcT25KI0iIB1L0mKhYfTVEqE5LVen5yidU1hng3DzyIaWdn5LRR6kna50BMLvfDRb
C/LvsmIxjYE6iR/7GwktruyKrlU65PRD9u22O2SUGdWVZwfto7H3QR8Bh4pfZYhXQ59seL7xEnvQ
Be4WfWvumQ1phU7+sI8jps6zWYXvLO/oD/ti+gEnBiiHwPAFO29L/zUZGCgn9A/oY19GW/vhJLKh
wfs8u4xnsoqczLwXky4BIMGOLClgOGDqdgIWqOvNGqjgmTJLo/4c2pJngsd3Qcaks68k519wY/Jx
8tekGvQTmH9BxmPbgUlJjJvKdA+hbjRBoWbr7FwSiezEIt+cdg7/KDLWaOfI2goBkuNrckpyvIRT
3F45K9XHMAf3ygZ3B8yBOVkwJOlsAbuKBOO3XTWjrgciE9RC+rc7HirfjM2S45XZzCa8wxgfTXgb
Wgtn3Yx6qm8cOdmQJKE6cX/Ikux6jIs1vJwL2/s4DXPgLtizhfl/+2z9b2RmJpdkaZ1woN/xEv9G
/IxVlzB0ZTxsQP4oz+uMhw2tTc4s4fEKXxj6thLVdNo5jbGj0Q3RKzRHbeGGNMeq7ZpkTQtkyjnL
+6oSuko5R5NrERRtlLNh1EVDhVu7wg1TR2ecKgczNa8jPv7biFgRB850sCTD3YoDl3MbhXR1oNoH
pTImB9H4ekMCFdoFutn+ejVWWzrIYJJPMAz1Pt9oUkPNVeWoIYN3ObsWGVpUyf2bd2Z/WW/U2mwc
n2sitCHHyLW65yirS1Ubj93QK7GaJk+zrL/2VNj3z4UGslm0alwPbzI5PJ2+kYxadXV1KN6ustzc
ErPUDLOy3L/m5PpIWuhcW+76aMNbaam8tgWuwfzWQCamjQ3quqL4UynIq1LYJasNr05hFM1ocaoY
nOqU5YKqy7Y5zQnbIF14NQMTCQI+5baUapUhSyFICeBWwlCWvBMUOQ1dFbd4CiyJh7c+HyuyXB82
v3a8NM8OVTdN6pOaEdA6cNadPvv4Xrf1e/1sfcvfdzk5z2ilMEhXjZTVuYnlxVmjNRanamHrDi6g
sy2PRnWzBdazxK4JUenc/nV7t9/ePUckVQZALZVnW82LZeMK6cK6kZy3pJALrSbpzyxBdNauVNQo
SsL8OuwCVFuRnpapTzJLq8T/KFZZQRsjKlW9HnXvriPBPWIbpkffyb/nhJPQ+wGoG67XaJR3PEUn
0XF/9aKrQKXSDWFxW7f7QecI8oojaSvjkVXmJw5pDOnc0PFYvnUsEI2X2smHMn1Hxt8POYxCecdZ
+vdoDJwMmgJ5UU/J9Zs5TqkuPYL2N8zmdo5JhgRGJUJ3ZirvEKUcT6FKF76OwwUwNPkJXcQFIhBd
UeJIciELTzE6Gy1ZGfJ0Rim+4yRy+ChINSd1DE/BgAWPNtKNjcdbj/HPo038lW4NNtIOHsiK/sBm
NgtIV8QNAPVEgIUzfrJtflMmCsRFpGJTBAE2JJsZmGWPYhO4lJlSNhtfD4mgP8AebcQb8ebvBiA9
3XgED7/i15uPtumPVUYwZTa56OagjyU3+9s2bdBPXp4bkriRKZHVYSIeRJMHV9DHs0OQQVEpTxkx
9hs5wrDQUDqUE9qybcAzls3zH3oQ0yB9xX83+1/iH6ty9bM1eMyVNqnK1v/CSgRnC//AP6ZDlhC4
HqF5aKBghwZ3QNRE9NLNx3qQ74xesnVuHAg12CTCbSIrx5uyf4Pbl0yy+5Rf5YAkUZBjCgbpxpia
3FOJRUzsptrteB0jM53Qi7aQQ+mcrEui8IspPU2v18clbatfzVNDvu8YWhTB2hXYfvCAIGI2lDgG
wAAd+cvWPmGcEAKsWjxzpeNiPBwCMla5dDHTzRh//NUbIWeNGD26VSCS+gvQvgAUOt85VVqQ2V7H
X3ex/JxEyRydX5Dwd7rGcEdGA/YLDOZDMYLh196DtnAd4Uw5ZHpY9JkPh+TJOBxKT0eYL3j9g3I1
VOVI0CowxifR3bLIEItg3llXRYLDDrdw+AVxlf+d24yMT3sNu2S8OCKcYQpAaNkkEYli8oJFdT/B
NewQUxDwr989EwT5ILOwfsDhDMr5ISW/VnJviGXtvZeDvR9Br9FuJa5mM7KLBXsvSZA9qfPk3ssg
VnxMjCnrAb8nwRx0LOp9V8wH+mtmzfyJ9f18Zyh+7kg5cOgI0zeBVmuChXaeD2iOzftYtStOh8PD
TsfvoFyrM7DrdNYPf9qHoQJZimLRom8QUImNjSCjmQVl4Tdx/SmKm36vN3lrLRJkIdmzfHUqbwKU
1lIaduRf7Cg+1mDmAejW3qUGM/YBSX+WtAJVKCziwmrOnhpCLQfhNiwCYX+Dh5Kq4GiST3VU0tHd
zpNwe5PeYNubjzob6HV8QruxcPvJzpZ5LPAemIK2Z49w/5ZR3FcxA809Mud8gB/zvZx1h2KTcK88
/L3JC54+G3raV1Dfcn4zah1Dv0GdgGrVCfvnQ1xjdviPh356TD4V+YSPfjLz3M45LuDyB+De2WAE
zJxrox9/triGREHPVUWtF/u7MprmBbpy74alttUNgp9RKEyiy2jyTGbWL5DtljdKH19VmP+NoQbV
j5QXJLU1vug7PqA+BJeXZmBhYSD3cWsEdSvvojz7VswxOd22UYQlVZMonMAY7hobg5h3FJnEhsBW
JM02NuRea253YNNFCaNb0fkStIC5RnrUjDW98mEdVMDSwoO4iS9q72jhwXdrFpkOB1gqkJSBlYgp
tOKqqZdJlI2jznWXSbwZRlL4Yd9ZELtIF3uY15tjpyxWRMbp3PkqWllExZqiCfHigFgRKUo/O0Md
j3EtiprAilsj6DpN409NHsNrTB6b3+TkdQSujwW9kzMZK9KCJm2RXtRna2Bx0yyTkShKO6HFPhl3
xRvKegC7qHWQQfx9AN/fDoekbawm095AZ7Anb71qhpINHRvUZoU4RjYQaRCaM2d5vRuMVC1FzZFi
OCdYhhdRm5pjuckpQO8r98wmJ5jXVop134TbpUwAdkU5joxA18JFw9Nf5iCirMGvkHT4hHhYDc3D
PghXRLeHW5r1kdITvSvaaiJiZC0YFn7zCWoDBi1AJNANgzqnXqw5HfkCq+mhIe6TAldOf6/Q5lma
nkc59rDzHQt6ve0zE/g7+cTt77o1EjLm/Md4ijpG4FtMV1+KR3IZVVGXa3eyK7zTnaDsqYx1/Z78
zpL4XTSxo9FGIWZlhKfBIRAticos3SmsFAgrkkt9fEQfXUODUR9WTTxu/TuLS0chcC0hVfW0abgv
fyarvqyo9d6a1YRea57FFBLPf3nxbIiGpUmWfl6y7VSmlnLuRLnC9BFHZJMNS3GhFhAysy6KaLpI
/mymD+1RcJoZoavf7TivUAabeqS1o2UH3j9EStirKrwU34jHjrnjzVsfPWjxS1gOota7hVovGUI0
vciuBq/fqB2GcLR7Sc8ebHm1ZQm2egDLNHjZRwDt9Unn7nfMFL8crFhpYFd6tGKlR0arF+JqqKKj
R1rsWdTSWysyN4FAAmlsr/m0Ce2C9isbeIjmKs1ZuL3ZkfyJu+MtbzkbG5uxNT5vgMvqFDaViMRX
korm8cA8tgzlV4/M40dW0zlst7AttdZzsLl6q1vfptZ9dkMy/OFNL8oZZZ3zJ1QUNCGTKQYnsACM
wzJ4IDUCGY3zwE4KjptS62fHt+qt83uZtccqkMdDK4a2tsqaG4eigDi9y+Tv8mzob8U8HzpNliTZ
PCYW0GuqvfDbbALrVX+oB5SNYxFafWNgzj5bVmQ9sQUj2qlUHjRWHtQqD6qVHzVWflSr/MjBO1U8
inVRVmxpw5gc8lQ8FZ4xXpkZNDs8sG6ASo8dLug0DjHU7tso8pGVyyUTp4Q5b3DBDCpgBp5Ck0EF
kipENsSUA/LlKVouKPcoH9/FGOcZl9LGTaFgbN+gw4ssm4ujPApP3eQxMCH7Qys03vngUEYXsGwH
bEFE/uryYMOCBl8n/a2sv4nyxztp1Gf9JUF5bt++Fbi8S5gMroPJwGACXyeDrWxwK5g4qRXxcwMu
M+e+K7OYNRDYW8tIaqyt7gCE/UpXLQq2ghi4IJCvVDZa0DKKLMGk5Oe0PbU+a05Dj9TuERqyzBt5
PKMMNJiKKTgeT7DlPt0CAIsoN4WVOTzRvWCP7HbGNsdZKy4QM3UMTS4WdKyeZXy9M8JacxF7jBhN
SfPExkH2fD+ySuASM1UH31lecJXaMiNHnQ/ze1xWPBF9HnQmmD5UV9fNmeubpCONbKPCJLT7Riy3
LF+aQLXSFdudLzx2MPW+AgzQ3DnH8ykvPxJFvrQoUrW929t5yRM7tA/uVOhmqHdcod6XPupVaXhc
o2G9tJD2iRppji3SLNH1fZRT1f1Zs8q+Oh+s0gL49g3pVtczTFQ+2k4hgYz8XcCD5745z2xqqBw0
YTu4FWxXxpcxHmiMm1OS5XHfaylpRY6lSs0Aw2bXPF7CBl94K7NdFis31gb4uSvYLHORarxvWYua
AEFbzYAUIjagRkh80p23THHzgdn4tbKDKD5xrd1kuc7xbDRvOJ1r/pxGeRolAKRzbc7iUw9jvF/h
pER+NvgACbTIS00ts9fRENuJgsTAuHRcEL6m1agZAWUBRjqJFWiulnzjXcB+YMal4TxM4+Lkzw+W
d7qmHlS04KwEtBK0qBYdagav4/RoJWpLDuWcrZff5rEdLDN0VGwX/n4MK5nktA0K878pu6DypaG0
QEHY30g3w+3Ob+kGkM5WqS8vtV2C7lt0Oyn1iBkoKWSyLsQ0hxlFVgrHll1Ys6Gv34AmaffYNOqz
3BiA5uiXVigDz9zHhPXqW1bqymbfHcxLI+y5C1CIv2yIoDpfYEdUOWq0JEZ8O+j4BYyklZ5Bl19U
nQ5IyhDmOEm1dfUma48mtOXD0C6lJHouS8px1DjH2jRjUc3qWB6BsltE6lGVH+wi8pFtJSNyOtPM
se05mKHpw9ALRnrq0Mwa8Lo1QGuuNYtlV2Eu567urgnZMaYyxzr+5iGsQbZ/GP5GgCRyGaQGURec
69hPy+avkgovTx7pM78GPB5yVnZq8kS16pNe+m6SPVCD3jZCN0KuZo69YWOKOr4W91xnBpPCrhE6
kh+APmRvxNu12d82PPKUyGaRNDkLjDJiH7RXuDFS18wrI3V+ihebcC4XK7ukjrvhLD4qxIPJo6gn
E1Y66Re7nlyoVv7KmqRo/6icg9PgsrO59XQanG1crq6kGCD0kUD2ApzdnUpfOM1ewIkum/pAb2+r
D1UERgYDTn7ZggQWuDU85KBThiAyNkSgBChX+Ti1b1LA7Od11GXyWEmc6suRfiuxrhZgNjKhHzrT
6e1ODOjmVOs7xP0yg7vMmlnYgVAUB3XbGLB6xPEqv0LjEzH9LUh6etuEhN8piI7BdCiTrqITsHtk
5Rn4vUMj0w5BVvXNz35nqLMB22dFzv2RUEO/qxjaEtW+jQSumHMMSSmCpLNOCb4phJ2ITE7aoFBG
mI3actZOErQvcZikis3vgugBxpuoNwTU3nVNVfPcB1yp9w5xBssbLufQtiA/Yd90aTXewy5mQzYf
IBi2+BMXEFRU1ZK3rh1rshhHwe8bXcCLz4dXHdDBNUf0f86Q1s5m3qAK9LDvGxygQ8Pgo/LiG+7l
o3kSTsJZmE/WKQ92MOqowW0cXT7lDSkc0V7WeLh5Tz/V6pVzdL3KXLaSCf+CA2/97v/ic6jwDP0v
aA+4nfH3DJzevL3Z+4VW00tnSJqm4y1Mxtrombloj4FabdSk4wV1pXmHM89K+ozzda9vPeiPOkM7
U3nbKIz+EWZgXZdgITtaVcrWqfjp5CpZ0W4wyv8Dx7hR0HqHCyVtAwfcmqhljx855reubHHLozjB
U6CJJjUnVw9qG02ZMt4ZLMdp7XKPzFWbTm6hqgXMKr7P3nwculuzlFkcRaDxIB1Nh1TxKcZmVWw+
ZO+Yq14UAdbi0GCLj4qddLIPk2PBwbVFE2/SmSZ32GJMlcoziNNxV6BjAtPKM9HpRJMB+AhXYzXk
NAt59M5tRBpYu+9dKyQ+lmVDz3EPEg66j/wDXMNTuqUUg061sX5QBV4dHDJqvXnrt4wVMJ/HZRDQ
uKGNsYN+xMFDAfPvG7600j+r+IOsQXX3BRoVuTLPTA1gH3PNFo6Dk8Lr7wsQ2VERFKvwCrCktedr
MGRDwwUb5bX5emfvmXV9gaXvmoH3joJHQi9Rfu1bKaqepc4mqivIdEMgOjYirr2sxlcuegSs4+/m
4A/Qz8GdddS+2iNY0j2DbyXwtBiHacBpDILArKAPWcSB3CM2Mty8JdQyQya3ynyyurasO+Y6HOqM
uXfEVRiuP2w8dEs1iMp1Js0jyKqqGkOG9XGjSAEz3r4P/oidH9xt72m/YobeszG7GRmW79Xsi2j8
JJDbRd5EEQkY0M0poLzXb1ujajAOywC/O7GWOW2lx7jhNrH8kiZYxhkH5zlFkwJxuyKl2Nw9+4G/
DWUNt8DYYtp5HhQGcLEUJCfECUWZh2kxpqvZSkwXy6q+A9iZX+4b0ya29Vz7YWG8ubTkSi9EcjbE
/EFlmVCR8UmWcS4QkcfHJ7CGx8dpiHlHer2erQCwiwSmqPp9YyiC+q5Pertal1mp2rwvsqjBKBnH
H9jRXP5GocHvfkvIHN2lvUON7DvWrUr24+B0yFdqJfLv1Arfs2cZXjnIt3gFp11M4TPtsMfuobq5
6wYIrjyI7t1RzgtfD7Tg8gSANXcESzpC7xr9MVPJobpzmZXzIlDoWpJzWg/V1mgHVlhogseqPvQK
Mf79/Wn39IPy0gO0gLIoWrD0N4D6U/GO0Abdt1jMfn8fP9n+AB2ievEHLBI/pQIWtrumF7v246DM
YLj4uNOOo98zL1uYpHpE4h6PLLmTwKayu1I4LwJN3Q4mfFqX5yGmiEnqVs2dY93fu8Qt1qwtFDjh
3yXXUsoK8aai5eOKZWB1pYyC3eM6K5Pdxj1NRb10oLTUsbQ4f9sj1ThNiFZYtl6AwB4OPAB/6cpx
aYFF06MrJ7f8K+vtvl2v5CWs7MXte5iH+u4HYPQ5X8hFvqz2Bc93trJzPr+7Ws99M58kE+fBAvJP
6R4Y+Hezz387vw34r3qGq5SOBEVsD38BTrcSRjiiKVWz3OQrsOYKB9WmvF5RcomGAUqMf4ilPcSd
L9h/FWNp445xFtHftnnmdupMs2ELxtiJr0m3+raVm9rbUvbRTZD9nc4XuvbGRtqpkOMmxKCuyY7V
+rGZ6jQKTkug+gzlvjcdMmS1T7UyaQVni+yvVz+HOai2HUR3/UU4nwN7SWe6Pp+4d0RQVOCPJHze
pijsre3EtVvhyzerDS3VJkw7XH6JPmEXXXWdX6mJ2kpv18BpsNriLJXGNIomzUpjVyxS4MpyAcph
lFzVp400f0+b5gyHkxVlnCcwDANMahh31qXuaF0dPda7GG1lVGklPNPGUSjiDfbkoKw7ToCc75gI
pk514I06ky6hmAKW6nkntRkLXKNi4Y5to4oh6eYmbXXq32zJvpZWwNZon8XaHyGwTBuQoqIrgv6W
TjzQ7/Y7FBAJf7qVUb6GUtCuC0gh0tKyB94yfUAvOaBifAGAH/a1S2QNHPNYV0mCrpmo8mtdMfAE
ObnKQZoptUD75xw6OXh5b2KNN2KljhVwVJ/0HzRN2TdVw+b1B9OlwcpjWbFPfexQrj6QTZpd09jV
Ru7OVLGzrX8QZUzLjY/Md23OLM7ksnxmhPKq+31dmRfQs+EQuHXJSq3rjJa02LY/rzc8oqQZ5E2y
2jquQfxi43HdFQqUoTOzRAbJhtbe7AVLtbVrN7Vs+bIrIV1b1zGTuNw00fFdX+i2sNoS97DiJG+v
b3iy2BAHulSWni0Rpg/aJPXq4nOJU9p1FqwbrZUtErYdtTtYSpv31loMsFUc6z98BMXMbK288Nf/
pQHALj/v3KEoRyG7KGSgN2cJD/WtqO/Q7dq6KBVU8RnmaJnDZt8JwSUmVHo2Bo7zgcFe5c554cnz
1hX+VIp1dX4uj+LWXS/tCpO3ZYMzyeAAs0DleSL1HJFwj7Y33Y5QKTvrE9W4u+w7P+zfxVjfOkC2
MNPdsibPMSWcUZboOC1KGAzkJ5tn8BrjuOAsAwgHt3YLOohg1yMZCqd8WKDkYnyC8SbhHA37RUwX
DGC+G45t462igVTRG6DkOEyxJGYcD9Ori/BKawaI9YBP4+1ID9tawJ3h10Mpy0Ydth9ydoXFMblC
aSq0W+CrLdPpqqfxmh1BGnrUys02ch2xZVtp3mpE3bMP1ZWONkAiryuZ6QjPdaUeUBYfU+HOPKHY
VcD2ikRLZXSslvy6MQIZCJ8uPCnFcOsNlWV6bsrbkEclu67ZZw/oJWsBqN/vRMe/mKrAyoundKya
nsUOa5yPbEQ5/VZLeqZOqwhbzA+OcWNX5Qnl50jHyWKiLsConJtIQQZ/JA5QGZmIsDVnxZKamdTW
LKqyIuXrhzUeuD4hMUHypXxzBU60JCplynM8TMs6rTFeEgM3idahDDBGRBvkf0MiRinqC5MIWmZj
c9aGFVIyKkCgEZtsjF5YnyLfsxxDXARMrpEooAc/GgmhVs8ylA/YIXLouW/H/gzFixCG71Lm+liJ
0OdW2z9HlItBZwo5p98GOz0Y+CPgfMwOV7ADX+KmUQn2erudwLKDQbdQZ9vr7SwPBzXocb2qun9N
bjDgRk53R77ufqqejayujXTfqnPpUycMrTLpoIlLGztKGzS+KUbKJXJdtX43VjWsrkXcH5e1rX7e
hK2t6haFlkUZ/gEnwkfRYfRRhPgjTBtUmGGPqykDCziFUON1WBHBnuOYADMntMcqsmRRGjeiSl1M
5hBbE+2wkZhY0ZqV5syqoTxubqzyfNzWUDZOY/QgKFYpS0NpT++GcnpuN2I4WcxmV2Y7mYFW9tew
iMevpGGkGqbd1JKjc/vLgCKaIgc/mIZxEk0erBaljvKHUnOSy+gFJ1QTxSKHqUd3weBmxIwwlpCM
Rr5S02yBl4IlwAqTqx7dz8QG0bC0NjPEPHxlk3TSZ10QfheY6TPGS8NiVHdD9ILGkGs5XByCzW3j
NuyKmz2K8C4jUDyTLDuNJnydk8wuys0UQLLTiFJXARFyEAPWGafGoH4ygw7huKejzXyQhJRfooht
AfrkqVA0pnZfo7DGzlIvYUrU7cFEDzNBz8MknvSEmdjYBG1xpH+/rcmb5GNkfCFsmgRJVZW15EhV
lnAavehbbBIvPvuLfoO7s4lOw8CE2uz3evVEG2MrAZCUpnaqbJCbMHdZBOu5fZ28GRNdWxFo9Yj1
ZSZinW+GzTbj2prrkug4R06Hck6JSrpBXaHKIs/x+CGaFXpi2JNHMzjOnws5bcYRsxEQH8MNStzG
wKaXXSLP4wJoIhPNKJeoXvV2NJwtlGH3bAGI8bQq4xmsSLFEh6ZqhhwJRcaneONfJtnYCt62rVP6
0sosj49jvPYPR6ZnSHBspec7Hk/otcPmNo/LbFEYOMV3oRxzgmzUWNo4vYXNRx3r/KMtr6E91NVM
qmV+xSaeooiPkshIvweM1WhJMtVKliPXAEX7evJ6YwuU44drlvrLWoCoZejrkUsUri1dMvItCc+m
cDKc0TwA2hij1s+3TTYyjKAzno2tCJt7t65xXl5JuahSeu3sPYPSuodkj4Bx8ORJWiEZT1OKJVW1
uaZ9nZbZGLUnB1NpdJS60Syw1g/0FaRKGwiqjuemNKzZOln1trXaWaltxCSLCkyrLfUyykhyFbG5
TQakIVvr1A2uXukfCryz3RqKZcT8HzUOlWvnmqmz9KCKPg85846bk8iSZm+oDUDg7foKmt0dHaiz
ZEQlZyxdj2KZ9Gwir8K+7VbtTfwP+9ByJc+RpYSvmvIIM+wSDPs9Je22ssNDAammqvzwVgYyeXGe
LPCNTGK/JFMdZ29DdSDlFRrV3S6WyvEi1VkIIjnNlPHduu0OSN4T4pVccnFqox11BnpqNJFrOCkU
eCd7hCpredEI5ofsAqdG106ICwoAyld5MgFcDJOME869GXfHb5VOEZkzNtpNQgfk+Qj+P8MDYAQI
tMHcsfN5ckWx2OQeH6IRVt+/Kuj65SI+Bw3dUh5CyuMq2/BlxdOzcE7ppdXpsrmUmJLqtawXuiDJ
M5l0eZ23Z5be4Nkrrraq6VI09AoO8ZY030bSYrthXF5PW3KimU/9COVUHaFUTCYtrbpQeN0fk4qJ
eqh0e5vy4ZZOZaWg85k8BfeCCmKd0HcCczYl3Gx18lgd6+z17DN2Qyk8TRcKqjlbt4DS5seFiyqI
qUW/ZK1sHvCuWxJVL030tFPpjrXLd/fBKhRoguaVWZzaoT4kZnt4f3BRYpQ+H6KpyTcg7a4QfHGy
fWuwdUc2bQU5b6aI8dQtHuPMtmOHcKgyHKqB2XsRisjxOLtQElt6elceNIaFnIKnwNvs817bkC7m
crLjXtcc28gzGiPatliw9cTOZEL+BogkbSBmRIkTQCRKSUDInNEJh0URBS5wEszzbBxFEz4fYud4
GqmevRezxoLv0TAYBF7Zat360DxlzGdLnqMf9jLrwgh5T4cFIZARtRiVzVbDQzovwh1dLbd8kImn
Nua+Ul5LM++XzemXbqjrgFOXVCNn2APdE88FzFPcvJKhRhnl2GBzFJUl7+TwdC6P8Uybto0mYWvB
4WzIRyzX6WIVfec1wCf+GSeY4tu6FhvBWDdjGwMPbTPDCfBzCRselCAqfTYtHbgTRUYBaMSO4RQw
9EX34T4FRQ8iYWjI5honN2mTBceW0lyGbDosjuUDJL5t2TANvTj02+hVDf8Zwk0zgTpI3BSIpI3M
M2JJtwZbKun1/pNREr3I7Y6QrdpX8XkzDBLEBOOmm/AHr5s2n8WD5tsFZGWN8EpXElS3/a/JroEX
3cM0eoBn0M42vwrHUicrdjElRV4cWiLBvH5Bag4tNC8OKxaplUilUX/R1lGrgu3Tn/my2csdX9Vy
b0Y5WczS4AUGCKzGqdcz96lxWylht9JvVipsTbLVUNnTe13c9sqB6Fa0D/zglo8N1srUR4P9QBoB
0cOxSmJO/2oydXfVw0p2dOCD5XmvCZhd78Uh5/GtsJW18bjdjZnZDmodA3YWMsQO+OZogfdFSJWC
7bh3vDnE5u93h/e7w/vd4f3u8GN3h77dF+9wWvd8K234aB65m75le5AgszLGwTLjkRvTf+59oTa7
3ubmsHVfKHdf0lEXMUwXs6OITt6050UhwnNY/klC0smptBdIL0h29bXcu7VTZUEGBGVmoB3UmC5c
4mM9FABdlq1uImUkHIrgwjoYJ2YsFjPLDgtim5fmSMyynM4FJZWpGALSawAeBZWhQ3iMcsMukpzA
E8eJ9O0zG5aMN6i8V5QOztQd2Ggujk8sEhEHots+8Bf1Grglu2CGBY7JUNlPqW94GEt7iyvFFI7+
0IVejcMFT65Uro1xQb1kHVWzHDVRmBkaVlJOYJ8pOSQ21qto4br3vbNFVtLAPbGyCvIrXpNxu/CN
gNlpa3uNS7vP+wFFymnMocO8K5jC/DQRHh7fBiS1POUpYOdc8GpREyTNjg7/qT0d7BnSXH5T9KGX
dbK4h5+O+iunj9EFObmmNW8KpS/CN3XW2uOgarzmz7JkEFudgGSJcs3fUulATzdjyNDWiW8RzIvw
6iiyXFbCyQSPL7lvNOuAz9C4siVBMKvQSfmWRgkhsUs0UsShsOPWWpE1uL5ijrZY5RSsco2ySVQ5
DWi9ynGR86Gl3TM8JMl80JwdoR3lfW9zkh+/5U6sarszgG7DEnNLtpgbmBia7DHDFmvMDe0xfouM
9ACyVja2zuDcu+adtvZmebjUxGdb+KAxMq/ZJLo3qvzTG1X02l05hF5cfryZAfABGctUrKWGdXeK
lbNvukFHOwiokrQEVA0hblG3F3h7TzWI2L7Dx+4tZVPkwM+7ubnH76BiI4xOQS7Rl1DaEBEKqlKa
U+xdOvo/AuWxlVcE00PeytB3rfRhfAtVhb5VdOvoOcXqlzrtJMft/XW6WAE2VnmtTXrt7YYetrfa
hLYsVkf7hyzJPuYmqnofOIdKfyX0a6034K/L1TuA2s4NO4BcgAxGm99J8KZ9ABoFZ2OfG2tYgqTG
y2+bmNlQus69NSI00FGXk3S8A8Fg2yccHNE17Y4EwhRWwutLBCvjkFckVBFuoKkq5mHNa3fZRdZA
vsncqrXexBPNHbj5LXWeqUXJB/5ws8p03sMAle43MYAsdndz6mzLN6tuIfWMQ4ozpIWds8RzP+DN
5iIqIQZCRU8JVL4UcYb2XhgENRaisl6e7d8EQ8WCy5Bcrhg3sOTbG3ewSn9gpJV6d0vduv6kvMm0
XDoxb0q8O8uScafHnkskissSSq4oBWD9s64WW+ufAe3efM4ynGzMUJJ/Hi5mb+vS/Kar7xJMwnIp
JhXe8G5wKtjRsyhXp3ZyKiDW6pGcJjbs1fqgQBOwpWRaFZFKL1ddKGE+/Qjbv0R6SdH3pmPIJXdQ
q2JtNiNbkFSMN+pUWSSEz4Ouxud64TMrtPCAbQnt/jryQ4Eq9aN99Vred/yQzQpDsZ8VsZWs3Tnj
h6JPVS5HC01p93ljm1X1MTvaTFPNBC1mIymPZUmjU9AIyJuKqwaOVYbJR0hskmObWkm4gj0FtQS0
zpozzKqJxbGhAZBAcyxd5bOk9CzCE7hvg4pwgMnT0W2rMtvrI2ljqtMAD9Escypfh0lE7gXxZh9T
A9OPSkLUAMZ8q995WyMF9RlN2t8GQJVvu7oBT9sCjxPUsowNF4ujYpzH8zL4fA7yA9qwh+FtdYYg
aFrxsK5nmXyjzvW5O0SpHjm2Ycf8C+uGPFaUJ849ZYNZHrqi4g8D6NRqgS70sdFSp/C9nr4f3JsM
TX6smm/9RfRs03MtUONRE9erOl4q/ciIS+iwq7Nc89RGi2f1Zct/WdcKH1cDuh4QvduDZXetUvUa
MqUuVQyfPrD5eblmrCsuNfBT31uEVIUVDEYeWP/Bse4pTGF3DoBgeti3ZgSKXp/gxo8U3rSLISh1
SV2TYqDTSAlWI2uxmLVKqa12KVVhbldOPew/keB7oBfLr9cUV8UK4gogf4S08ouATYQ6Y7lzXYF1
Y5H16YWWHJSqzLqXWM0Sy6GiZr1PPd2tiYdKzNp3a5+tr639WkQE8/2cZRWroc9fiu/V0SNomB/W
vvmm7f3Tp0/YLJqOozzlaEx1V4o+OWFXrPBKpvOI0oK8jDBdBp6r7/T+tXceppi5EGHtZ1leRtBV
2omLQ06JeBDhYS8elEMbO7qNkWnjkLsjvuqtdcKjozw6F22Yr21uir2IRQdGreJvchBVlaJLvqdD
6/XZFHA/W2BsLsWY5iH7mklHrGLNBh/QiQg9CXQ6Gx3Ja0J69Rn2sivJakD8xeJJ7Y6Eas3G810W
fesGJ527v4NM08Axoz53c4SntpEekBrnNJRDDvKOV0P5jx83OVw4JUMxJejwJ0oma772gtHwX7M4
DeRjLLcbAlWy/KordrMUlq8yZuOjptYQ6PtMogFc8Bw9IdC5jS9Wu0DfE7mVUKn7nno4QRUxgNCz
Tl+AyzkAh7AObz1Vfr/0rtIc1AsnE711kfUwJePITjU95q4E8853sn25jrQNvT1C9QG33zYPs13q
Ew3uTcaUzRpyQnfRduKbu/qLnEsjM00l4df9TNY6xfa5XZMDs0brWolGetdK3qIgNGfllTa80tC8
NmTzPWtbjleXnxUp6mmorV6bWK2DWuJBs7Kc/TEe42KJo53wV7ne7mbzK47+DXY7YrC9/ZV4gS6a
qThYHEVX4hv+1aNf32Ga1jjqheNeWD51UQFg/6I+nD4KBz7PjvNwhq5NU/QNLbJpeRHm0V/EVbZA
jzdMfWE8KWNUXCZfZDlBmGWTeHqFDxfKsVA6Wktf4u9f/iS+5/xMYn9xBB0Tsp8iLAjEHJ8WJ9FE
HLFX+AixOJRYiBFmKiKW+4vKLofpNXAoBtDIv6hLECTULt2pDHoGIJ9LbQ3NM1cC/ap03R5ToJUa
diiR9Ag+yeYyzVGMbvhJIo4irrwoouki6QooLv72/PUPr356LXZe/rv4287Bwc7L1//+FxLnsE0l
x1MCFoPkjqMJ14e+5mFaXiHdXjw72P0BKu389fmPz1//O/Zo9Pz1S5jOYvTqQOyI/Z2D1893f/px
54Ar7/90sP/q8FkPtKJoGdVRSSWv7ElUhnFS9P6FuPCbbzaQ2yzWw2eTjGJ/0G9QmOy8uNUKE1LY
WF+DwkZC0a3wbaUtZcA0QSdcll7ugOSNv/VWg9h2y6HI43L15zVddmWVZclSt4J0Bgr/Cvuh95Ns
vMC1+sPan/4JP3k07hXzcNKbh7P5SRKVd9DGNny+2t7Gv/2vvurz3+2v6Pn29qP+o6++/lN/+8vt
weMvv/zqy0d/2u4/6n/Z/5PYvgNcap8FxucI8accBXFLOcxf8ynw+cSfXxV7j5OwKN7jojROYD37
FYSjnCHvw8s4m8Ej8qu25sOvZVwm0XvFQvAgXIC8zN/bKx08xU0lFVUgwqOCXAI+wBr8mrz8eSpO
ItAHleTGtS1OIpTuGE7CnvgyRk/eGwLV01/L6LIsFvCGFaT35ckHDtmg3Py5ztZE9n4/kErq8fXL
39J1qZ+qTX4xj8YxqKm04pnn1h2jPRYXpm+/kstDNgW9vSS/iZrqePBs99W+qCeUspXHpjI+9bGp
LCqMOzQ0Q0cLWapYStoXPrqJdKs8aaM0QqtVqt2Om65KaARnaO3JwnXQ5f3Ssm2dgC0ZbS5eoXUt
mhxiVA2tMLD07tHSVt9jKKsyVB/J6mq1OQRqAe27YucoSuIwfZGlWTzpVvxetPJrG/N8rjGgYuMQ
ASrWTbYHqNWrE+etLU/vV+k6qB0ae6PbEv4rYk8gPgp7cpf27phl/rihCCo5bxXkkfpfOi/gtlrd
AAHM8SsKofcqC91C+5DDaKbbXeAdTA2YwDLf+SDDVAs3OyEHg2l4GP014YjnRZBuw5aBqIg/Oqhr
8sUyUgFWnAlfrLBoqGvgldH4JMUQTozFKjAOj+JaZHyxSMlZigOo82iewKDIOUD9MHB0DQ47jrlN
lKNhfkyiWfZTzyVuSfrsy5cGntT6rfm7CLC3i6Df6ZoMQ1ByJCfxLKNWKI4PMwhyfJ4Mw+aOhZiC
FLgPsFvgbSkowbOpARWmFPmqBUTP8MDO3rNb4AF0V51qHrgkNvgYFmgWXnytN/MG3ZVd4Q0DzrNq
1PhlGZtcGnCt/LICm9gsVeGXKXHA9HP5h/5SuCAmWNaJiZNsLG8TYaPOq+nPBOhlFE2iCQyiFnpN
o0njp6xpTcDjqThgT0IZJasOnI6jkryzvFLj36I8jRJkFSV5oCnOea3R0lEjzi2gz9Np1i6ICJbf
gCBzLc7Cy2Fja0uONClpZGPd1qqnmM9R9Zx65bc1EpBsTlPWzn4QPMizrHw1hV48GA4l4dYdMqi6
eFW2pyY8bq9ZROV+jrUoDpswgO59Rlz6c5g/6IqBvpPgZZbK2Di3FjSypA6bGDiVRMISUAYSghKW
kX4ywQL5RE8Hsn8omqAZg+WuCueEqcT3N4WwsI0xSzduj9efHQ71Ld4SspLCZGygUyMOLES1Vtbp
IlPHnIPVLcLR9FcGClonTKwvIsDt9FSzbi9u1io2qfPPaVg9EXwGOjmGgMd4m9Bxlk1U+o2OSmbu
0g/qF5FmioLoGKIEpfjqIVXq90gSx72oJ2UbpjnAuV3NFByd7RQjfZqtRT09Fgkyc9LDPCoIddCT
A0ZFZCZ9U1Om5dDvuHrOKkyQ9Aad7+zMHVTG27h6o9ofUJ8e9TSXcM9YmEvvWHeSyhb41c+ylqch
t4Bq7xG197iniZziUa0ahI6anvwOj3FtyO58rJbkJvSMPiU5UgBxHnd6fQ9kL30qBRTaj93qOxLf
5vqqBANQ/asiBcOP5NCyB6+XVGnNwwStd8cnOj8jAKFrsRRkqflkWsA76q2Q0cp4xxYmx8G1Nk4n
sDTL4HRLHejSdCptHawCS7blJkOBIl/2ttTySxm3KQ/xhBOLmZ7hckS2WwpRf8AVHlirJYotXHSV
PkqH+Do5BIkO0klYnEHtntglda/ERByUwRtj2emV6jRdLAYgQ9YHKoTWkHiSu+kIqtfbVruOMz1M
SeOCXnNnea1nJZX1CJs5+Fu9jJrHRYlXnT+WXLqKyhB4rteYDi29QV/96nFaaF6gXXd5ykKkeWJq
vQEUpWcNmvBfTb8lf/N0OMSr6ULXs3G74hD0MMSUDDJPobzhhTb/Q7Pjtu/doJB2zHqhMHlgA6T8
R+amuCDs0cURLBkJoe+YKHQI5iBiRewDGIOTxFvfamAJP/MVlEZKmoT5usW8FnZOWS+wDELFdc9i
qiBFJ6h+B9+5g4MFm+nq8CXAcALvHVdS6v3z6W6YBrV2tx0yUCRttcM+hdLHcDAgxdXMXPkSnfGp
r0/L+2jV8saKpatWqktgspzVqNOI9SW6p4R5jaOVufcsH2SDlJ7klHMmolBgca5EBHQtnoWynklt
qwJFhubgXb2J04Y3aXRZMsYGc5OjhzakucpqhKmG5LrCKwdPmjlKPr1BxYwTOoNMip4+F2RRycOY
Lt/kedi74SY5m3O2NLlRbtofE79hO/oiFjcF1RTFqepKdFb3Q0IFsPgWd8bZ3OdASPcwc84KS06C
YFSs6spCFGKMjscP0CBKgUGVt2aAqETdk5Rxoeh+lcrV60equIN8DfFLvYTkkqYS9gx+Yy5EMt8M
rm/XqhVXRrw+Mzl1EKP2jazm7eIqnVxGUW5OUeLpkuZuk2K6rsstauHSdj9tE9H7EzM7eBZYy5YO
6ewa2mxpvCsIcO5JVOCwMWglGkpA9qUVzOD0F3Vv+uIYjZyQHoxFCFLOoWktFlCn812TjO1UklXY
VMUz8BTYYNs8rQyOXkv0qJiFxWAfnVXdhwNdFh1Kq/kysF23hEltBmyy7UQA1NiFZY3ZyPsWEeVY
ipSU691wZJE5mxPV3mo6V1dXB2hVW0GoBv3Taha3ipJhv6prGT4hBjgFWx4V4AuPOlLtHyodNYFR
pdEqJPwoIlYbRQ9sOzv2Q8ciLCmDrJg41KA5y0XZZTxtHafVubXudm7GE+b20iVgBY6orj1VpqgL
cdJsAbRSPv2cUhsrFDsIelWO8QIAIqsLdQL87Yx4q/0PPzQ2gUNCJ1mh51a0NLqotgl/Of3OsvZa
JSiq3pYArbe8mvwlh2lGshGWZy1edW7dcHYtUwXubGJLQD6je+A+HK7mdHeNjYmah3ayBUqCvmSW
48Jir51cyZ7azrKHK3mlL2ZPygEVygu2IujcSnIjZo3OzVf8ZeP5jz+SVdrRWFFvXTud8ryD//++
oGyZFzn2PleGN0qmuaDjqYs8poTA1vliHvH1uWSMI5OU2eaYJsmyUxs021pZ3bJKw263bjqtlqwb
GbvKqtyt2pc65mgSNUcz/oxm5ZBD+6D1A3V/JOylyNVgicEJhuRllr6MjkMrgNiQgAKRPQXohjcu
cmzr/Rcn6D2Dmz1g6c8w/VQtLIXKK4OqtrAeS7uqKiWDVuCPufxCbiOPzTaSitEE3G7Wt+3b+q4z
92QkmjLoYCElC2R1Zb3X2qrHNOYckUvzGII9itAVVDuM6m0IGyV+XxN4pmX1/LbUfkJRCxU60/JM
7Rsrfs6KJDW6Sk7xbUd0Wo2fRmcWbwBJrHda3Ft83cUaPUed0UnF6YqBU22MMPVBMWFR3q2A6jgK
G8ZB6Oum52FeRMZR1fLsHrnEq6uEitH3AiYZU7JjOJGXFeT+9VGjNZJus37qWB2bN0VNY3rLW6Ix
KvQU7bntYg5aOK3LZHM/zJJzpoSZftDqkzGGcnEO0HO50EpKtKp+6xUPold7z6gF6Yjl1M2t+RK0
Xa64k15ZAtSM8+vwKsmkL3IwMkMGuDtoVlSyMsjJ9KvjZeryU12ZGNPh0adc5PAAvbLEsWz8Iyxx
xLmI4vLlbTLJ0XpjSGeCe817u6fuhQvcT/lKHigRt/CNnOoNCyTZAb/eJLd0dU1KbnC3HjPraxpa
ppJzc0NDBX35UWGbtEHCSWTOgT2D0bFDnGHD6I3g3XbC3H0l3iALg9bghMO/CWJK7m/HUDc1IeSU
7sVOBW9ROyTcJaPJUHMEM/g0MkH7b4LacW9naa/w82AoHjS+xMurw8MIk3+XdKwAGOA8pfIN/iPk
u4Ruh8X8gUfmEhN+F/iYtFN1HZFcWxEINa6uzN9rcvUN+U4x3CdhPmxyT9+BwaNrTZ+4MXqdSa4r
PdmuoqTYktMSrM6a270ebgwfd9WU/rLTwpzqQbCERBsby6P6g7o8dYC0nLwRBWsYuPPkRhMCX3kd
o5ZOBii32mTgSPT7gLf7gLc/bMDb8kiJ/xmhXDf6TKfT47sOAGuP/3r89dfbjzn+a/Dl118//hrj
vx71v7qP//oUn1uI/9Is9NEBYEV7BNgUPdSmyhRA64AKbF8T0mMtU5uu5DiDPdnJrLhBXNZo58XB
QHCsqBMWg95kegc0sMO0Vqzii9paseotBHGJGUfIm2grFLQUM1FezaP3DTh8WFuKXACqsgynqsQR
tepVB/0heei1O7XvQKkGDIKDflc8W+IUfzBYqZVBSysDbKXVHrJK4Jk37AnGZCigH6iHYTs7fYou
2Bm0eO/zHWkwYWEm8lK/jcoADi/6jqZlJk178CSYQu819HCIDcA/A7Nziad0kda3wCBsFVyHxvmV
Y2qaZTJXBOayDPEqtl0rICbsKitZ2AEAYpMbR0stJgpczOC5P4PGaDT6Xpv4ULEawUT/PlwUBYyC
M8naCnqnVluFG0+oWA2KiqvyCh6cd/NM2pX/GsFGJJ+FadpFcH+N8vQklO5zP4ZH4UnaBV0oy49B
N1T4bpGE4/vktEF6xrfQaLkHwHT7iBDfOUZlvt/dw6RLz3deiH8FPROjjgCGvMZmB35eFTFVIELM
Qc8b851VYjDorTVRLdjrip9XCrPck5GG1dDK78cT/orz6eehqE83aMJrqBN0+w4l42k2BGOx8Ugn
54KyQR0Y9IHvCUKAezTh9rAiMfTOkqpecBKGuoGAYQSnXdwoTzvK3bEWQUYW8ne/JRQ51hgaiUss
CAnasAFxdPdkGJyHWIiNdWPRnpzEOkQOIX5QWB1LLdzwblgY9oUdj2Ff6w44gMWsy2FhY+zsi466
ALEQ6+PfT4MXnXW6STIVz9SxSjDo9ABl5aXPU2iKGSfwNcW/HOEeZH26jgiCKp9NeBatj9d7yk1c
37tk0UX9baCHOUUgijQB0sUURPuBD3RtWWhoS5L5uS0vLOwt3mtfNiXr/nzz0fdhgu7zuzvk6Qmb
rs4HAdsnHJVC3eu2RTdKakiw1uQZuutSNxeFdLSXoY+y97s7fAOsvsVSZPKQTUpQAw9vZOP4xDwq
FgmFXhwvQtxwRhx8cYTzB/Z245IvHpVxAxrCfwDe/7HV74nv43N5myh2hWOXHqSU0+QBIBOnZde6
LFLhZABN4vCYojRxb69DOfHOS8JPV5uqWyRjKhlbNzEbYIgB/NuLxZZ40+/2MY6y23+rIkatSysz
XocRX+jFXfHMahKtIe+vYm++H/djeKzMyjBRl4LpiySB7fBO2tiOT74Gy9IVoUmi72JU8cBl+MHA
o9tPlac5Xx7KxTQWHzjMji9IlfevVfGx8P/gjpWlFMFIOSNkRqGZuisuVn7yWG0HoWwUqAOSeQ7k
QVb2rUMGmFyQ5sG7DuwMSye2maKbxkoRwTUL1R1rcmPNS+BeA07PHa4n6UQeukyS4fVX2ErHLWBy
tT1u6am94h5j3yy2oE4y0HcbQbh5tHG5Od64/G2wOYF/H23CvMVzlgCfDzb4zaMN8+5DTzxPDTxt
YdSZ2Lri3QYmD3iS0h+bGrte1w4V9uTv9G5DN0EA/f7+tHv6QTs06Firb6D7T8U7a4AwXh1T9M5+
fx8/2f4A1KHK8QcsGz9lIknavMNhJGlJ1Y6snATk+cX3cqb6LmJbkr/ZBsk3QNkn/cExP8Rt8YCB
dRss0Dr4ITw/oudj/bxnenTNcaQq/2DDiP+ZYTxzJ7NXQ7rWWNoAgzMSXasPqEuR7vIBNRWgyNkG
Fjr7TU3us9/s6U008UxqA0LO7rPfnPl9piZ4w7ammTvO/gGneb971gUKag6pGTCeKgvG7V5xA7sG
jgHRwc233YJuomFrZ28dSTee08ZUJw/heJtKPJcD0Cc7oBH/4+mQtuF7xoxzurGRbNgu5rjwq+Ns
ZqWAtBYfwI48hN6zvO7exMPhnnP2StW3+m/v6JaxTzCCspHbHENXYg1RLf/YoTzb2AhON5JO43BK
0SCbu96oAvD4043qnn1/NpD1Tke3pgisPrQTF0/XX6uisXz0VK0Ma3C6hc4Ezc5ppCdcc/JuOw49
VPduRlhZj7ZgfYnpbIVDUdXhgJjeyVjj1fEeZeAdKwM0W8dhEubqphoyRNDGbtq19jJ8YTwaL9TZ
E2xXLBNe09YusMoM3X04jvfSjV4DC82H7mZv6Awq+YDv2S7f9hg/nCoHb5oL2B3K90+dPlJ72hkl
iKaEAOfkDIHRz45eQYaTGflyHFGIc5qlZJjAczy0pZwsjs2EGZPho5hHkYnvoKwH016sHxzhg7n1
APGmDSOgE88WM95Ji6NeTxpDjnx3KEg/cD6tsCfRUVdUsjRon3R2XReb9fJiw2OrDTuG1mvNNphg
d6jNjc2c0LzLX4lHBN1a32jlc+6kN2yiZMzQMoOTt3YbC6OZYJkLlPkED/vkgujjYHOdItqYg12g
D5tn1tY4gwhFDbNQTqLLeIy+LPMTzHgGPEnxc+dMGTLUAO9tpbINsi1nKdkNMVfYDKqwO24KU5uK
07xH3zu03oSFOCdcECqT+8+YVt+H9nkznat0UTkUTLRzox1WS3y+Je5c/ppnxJdzuiwOID3si2/E
HJDokLMRvFXhCegviIZPZPmuKGKcbpWjP53dpsRjOUAEKCRn7ZY0c3XpB81haXhVyRXiKTVXC34F
8E6M6LkVEKJlzqDXS5VXv3CcrwHseS/GTmlT2lPhuQcKCxH0GCaom8mj4BhN/LNVeYUI/F0KvXir
779tBcNIqdm5P8j9vPd3GoPaC6fh6mtvlKEEhTTzTImmBradFzKY/tx6SNE0FjabSKe1SgXFhIr6
DoLnPRxc/BCR8QeQGX9bRQJ4DLMZiwTmF9DcO8FtEXPO8pGnK5uEb2F6wfyS5uWGGijpJlESqo2p
irl1ZjmK5fkVziguREGt1dh32I3SzYNBZ12ivwRJGYiKIblurznhgHLKtN8NboMkf2SaIJBBU1tE
Fbu5gac9i6qy6Rq9B90qUZnig07nv32Rto4CvCPdXFOfOHi1+sZ6Q9/5i1lrqrLbwk8JCTz1qObM
adM1LFToTjkpXL8xPah7UJMGFvABC0uwv2jR57mojaSdKa4B/8UVyOao6C8eGNQv30aqoijrpCSB
XJp8fG9TVzuZY/atKayXA3dVQV8XPws6rEenMQ/7VWdx9vAvwyqT686yBuV6IEk0LSeshsFboti5
3TSDcad9+xRdq4zfbW9CKfeTTOfr+ADdzf3dlqdCcDmseyZceZ5NvHKlJsqGFXcFI0qO6crnYp7E
5Z5J9RZcdtafp8AQu9lslqX2m72ug8A1Lkt0P0psfxwAg4pir+Mrb4eu/mE7lPOd3IY3ji97lFvk
+Ir/TsycpqwjsCaA8qF9+aD4JEq7dIUxVIHvG1iQ05/4C+qQSQ9HWozYyH8+diMrTI6przkfhHRo
i8QsLsX3eQhNiwnGb4iXW5OtvhHGwUvaWV12MPvgwytXKsv4b8fJh0Pb2C0lVi5zMkJrhnGes7Ac
nzwwLbwU34ButRJgmXpRmjAIGuzdnH2qaX4SlqHEQbVW3bNf9WBnuEEj93DQAx3oEh6gbi6f9OWT
FVZwWrcnXaDX1sSr2KvMZi/IdoNb90tr666pQbaX4EUvGCAr8CIPv/rdQecLejpo1ltoiafCfVm4
35HOrLC+iB+j2SwUX/YeidP/gsmIcPtciAZe/hp0RBqPyTaFTuEYKzM+ucB8pyldTwB/U0T69yI+
nqHzTyniGXI9/d5iNyARvD6Jsjyaia97AwY/CZHVwsX4hPbg6Hgki+5NU/EYinlQ7RN8wmwDMYti
4N8f/6tYkD2xEM56Wczz7Ai23wWmDkzJ8mh6aPWj7N3JYoVjeieWWPQr/zsmAA1znVO3jGeUKLGY
o11WeoQKKz46eOGar7oiCWdHk9C/V5qtpFjnWl9n2QP/vhsq8Lun9MAYWPfqBjQ7dj7/kfDB2XAm
I8kZQ5u/0fllSiZGWXpDBO9gfkJjQ1dvxI+tg858VosXMTeB31W7L7oi9jVNWZt0BbImIS4bGgib
2xbzCR5zsKNagUJS1qCMqmEyXiQyn3Gco4pdM7QkGuH/gO+mvtfokifCIVhVFgBuZGcI7K6hIVbR
b8vQAB7Cq+jybJEJFFm2l5n6nBVRCZD+rEB1sXot3dfcwmruwapCSPvnFlYmmtapKRSd2zCiIl3c
+xqglT45+L5YMy6/zv51aLv9Xs8uTKhLT0hKuM4TIFN5LYoeZ0Ulx11YAMiSqrwcod5m9Hu8BWtN
/IT4QGKrphbt1pSW0LeSmnknLa3WAFOtNhVkUTmjYxt+GthJ0iby7EOt/v/WBJ8iDqLg9025enFx
+HqqJ7+/Ii5ugU5xaomT+st528sfpSijEXK30MwCLzCHr++Fr0uKPXRGFRiFf1PzD9PpomsHLm4m
P0916kojbd6j6Ueu2szDyKaJnW/FSL036PCabCHZoFpVFCAoEAbbnF0TFANZET22cRvdlaoBCGLO
yQxgAA26OBDYGFSh42jSE68wWPYixpjYi4gunKalSl0xRfapJCswhQwuyWr5JrXJyokbUJvfSiRo
M/8gLlEdi6ycoZr2FpPAPrSrqlUK2rym8ikRTeitJAyX/MaCDbjn6jkQSNHemuMGvPyGtm8Kotby
WAbYOAdzTYO7RC5j1lUeQ68Jfi55wjoXAtUs0UsOyC6u3nDiU0uF7YPOOaHiFC/dwfshKAUQXaYx
odwqUmNGW0GZh7HT2Rc8WkZxMFIVpAOsMqDVvoP1vUderqbehOrJkTCauzVqmFDE+kmjINtsvIMd
Q4pGjTFF6nlRDVtaoUpTANMKVW8cypRQfu56FJN1eJ9nszXlksZRgk2RWuiSr8Izi+YIIo01hRLB
/6vd2rZqOFFTDF9DUBHUGTVXWhL6gewyIqc2U/AaYUoUnmbXroWoYSEKD6VSS0NE1/75Qp+uEwCh
jPWjlhPZFvPLfdDMfdCM87H46eOjZj512MwK7FqPl0G62/Ex1ojQwYw57qlHyDjnTGutN4/NgFXj
eXJ1kF0Ufw7O7W17ZUPg2cwwSq5DhZO7qqoC2e4CtZcCDVJx9+8d6YewIX9amkATS93i8eLouls6
4ZBBRfAcG4hCyK1skHZNTvkJZgq09y1WgVVIOa6oikUw7cVGAwTw7NAxrtnRx511v3FdX+WooRwz
DDx2UjkDH/Y3CHbnO6jiNGk+67RSepctexlHWlMMsx5hyzuq/XzrmKfNOq7bHAe9JtQtaHzDGcpz
vB4kGkdFEcKEYY+d55/PNM/TPWfh+ETk2QXPtZBc6TEbbJrRho5es5TsiX2em1fiOTxCnyAuLDBE
9niMiclTzuiDjaB3XLEACQlyEndW5ho82JapQdP7JncaEqAXn+Y4vTWP+R/mPF2s3U+z2ufa0+ym
DolL8nU4nyUOifaM1dP+0D/s1xAGDYvxP498ANbwyAg6439x2OQn8d2aZ9v88tnfXr96KV5GF2WW
OoS1d8rNpXyb4+bSS/e9kdxqcN3q5ldFe3AWPXZY0oonwjLK9mmaXaRSz5Zu51keH8fKKQB3qmJC
+9M1D6J4HffyrS/d2u3ue+lpdcMkZRU149x92ZI1mce6RVcTlqd3EVwlCnBHt2DnyH9zNdi66hMJ
4Q9Q5IpNh1cDnQr6ylwJ9G7YjFow6lQsy/qwULm/Xj55g0Glj2h3kL51+r+zuMQwDZBCOB/oi4N7
e8NWTnw0n7FxUWJvOsseTkCTXl8dVGBjeMfGsL1nxhxFXk83AVFZQDdF8G7rdEkdj9vVhk2vzf66
JNjGadced+i2kZxcASnx5IlVm+rSP1S4Yj+7Txx5nzjyD5o4cuXcbaunorqJ9XfFdfA+meX95/5z
/7n/3H/uP/ef+8/95/5z/7n/3H/uP/ef+8/95/5z/7n/3H/uP/ef9s//B8CSKQoAuAEA
--=-=-=


mantepse depends on fffg and rec

the constructors should be compiled in this order:

  ${OUT}/FAMR2.o    \
  ${OUT}/FFFG.o     \
  ${OUT}/FFFGF.o    \
  ${OUT}/NEWTON.o   \
  ${OUT}/RECOP.o    \
  ${OUT}/UFPS.o     \
  ${OUT}/UFPS1.o    \
  ${OUT}/GOPT.o     \
  ${OUT}/GOPT0.o    \
  ${OUT}/GUESS.o    \
  ${OUT}/GUESSINT.o \
  ${OUT}/GUESSF1.o  \
  ${OUT}/GUESSF.o   \
  ${OUT}/GUESSP.o

only 

  GUESSINT GUESSF GUESSP

should be exposed.

The dependencies are as follows:

no dependencies

  FAMR2  FFFG  NEWTON  RECOP  UFPS GOPT

  FFFGF depends on FAMR2 and FFFG

  UFPS1 depends on UFPS

  GOPT0 depends on GOPT

  GUESS depends on all of the above

  GUESSINT GUESSF1 GUESSF GUESSP depend on GUESS

Thanks in advance,

Martin


\start
Date: Fri, 15 Sep 2006 07:59:51 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: Help with adding algebra URGENT!

got it. working on it. --t

\start
Date: 15 Sep 2006 14:15:59 +0200
From: Gabriel Dos Reis
To: Kai Kaminski
Subject: Re: Makefile.solaris9 stanza

Kai Kaminski writes:

| Gabriel Dos Reis writes:
| 
| > | > | Yeah, most of those conditionals are what make the C code hard to port.
| > | >
| > | > no harder than the lisp non-portable sutff all over the place in the
| > | > Axiom source code.  I don't think we have a perfect language match
| > | > here in terms of portability.  I've coded for longtime in C and C++; I
| > | > don't think this particular is stuff is handled the proper way.
| > | I'm not going to start another pro-Lisp discussion. But I'd like to
| > | point out that Axiom's Lisp code is not representative of (modern)
| > | Lisp code. Furthermore the conditionals aren't organized very well and
| > | most of them are superfluos anyway, because they are for Lisps that
| > | are long dead and forgotten.
| >
| > Probably.
| >
| >
| > I followed this discussion
| >
| >   http://www.math.utexas.edu/pipermail/maxima/2006/014309.html
| >
| > with some interest.
| Ok, I read the first dozen messages or so, but I'm not sure what
| you're aiming at (IEEE 754 or FFI?). Could you give me a hint?

no, sorry reference to the wrong discussion

   http://www.math.utexas.edu/pipermail/maxima/2006/014315.html

\start
Date: 15 Sep 2006 14:28:16 +0200
From: Martin Rubey
To: Tim Daly, Alfredo Portes
Subject: Re: Help with adding algebra URGENT!

Dear Tim, Dear Alfredo!

Tim Daly writes:

> got it. working on it. --t

great. A hint: I meanwhile found a (terrible) workaround. But this way I
probably won't get Alfredo to build Axiom :-(

Alfredo: it turned out that I can burn my CD's on Sunday afternoon European
time. So there is a little time left.

Tim:

I deleted all the algebra I want to add except FAMR2 and built axiom. That
worked fine.

Then I added FFFGF (which depends on FAMR2) and tried make. That
failed. However

make NOISE= DAASE=$AXIOM/../../int

succeeded!

However, this doesn't suffice to make all layers work. I have to complete the
build, then add the next layer, and so on.

I guess that

* the daase files in int should be updated after every layer.

* after the first update, i.e., after LAYER0BOOTSTRAP or so, DAASE should point
  to int.

I have no idea yet, why the constructors don't show up in HyperDoc.

\start
Date: Fri, 15 Sep 2006 14:47:43 +0200
From: Kai Kaminski
To: Gabriel Dos Reis
Subject: Re: Makefile.solaris9 stanza

Gabriel Dos Reis writes:

> Kai Kaminski writes:
>
> | Gabriel Dos Reis writes:
> | 
> | > | > | Yeah, most of those conditionals are what make the C code hard to port.
> | > | >
> | > | > no harder than the lisp non-portable sutff all over the place in the
> | > | > Axiom source code.  I don't think we have a perfect language match
> | > | > here in terms of portability.  I've coded for longtime in C and C++; I
> | > | > don't think this particular is stuff is handled the proper way.
> | > | I'm not going to start another pro-Lisp discussion. But I'd like to
> | > | point out that Axiom's Lisp code is not representative of (modern)
> | > | Lisp code. Furthermore the conditionals aren't organized very well and
> | > | most of them are superfluos anyway, because they are for Lisps that
> | > | are long dead and forgotten.
> | >
> | > Probably.
> | >
> | >
> | > I followed this discussion
> | >
> | >   http://www.math.utexas.edu/pipermail/maxima/2006/014309.html
> | >
> | > with some interest.
> | Ok, I read the first dozen messages or so, but I'm not sure what
> | you're aiming at (IEEE 754 or FFI?). Could you give me a hint?
>
> no, sorry reference to the wrong discussion
>
>    http://www.math.utexas.edu/pipermail/maxima/2006/014315.html
Ok, I guess it is about the fact that ANSI CL doesn't require
IEEE-754 floating point? Maybe I'm dense, but I don't get what you're
trying to say (seriously).

\start
Date: 15 Sep 2006 14:57:08 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: Help with adding algebra URGENT!

Dear Tim, Alfredo,

I just succeeded building as outlined below. Concerning the HyperDoc issue, all
constructors except those in the last layer are known now abbreviated and
spelled out. The ones in the last layer are known only spelled
out. Unfortunately, HyperDoc crashes on GUESSINT and GUESSP with bind stack
overflow, no idea why. 

Still, this Makefile problem really should be fixed.

Alfredo, is it possible that I just add the binary of axiom locally on my
computer somehow to the live CD?

Martin

Martin Rubey writes:


> Dear Tim, Dear Alfredo!
> 
> Tim Daly writes:
> 
> > got it. working on it. --t
> 
> great. A hint: I meanwhile found a (terrible) workaround. But this way I
> probably won't get Alfredo to build Axiom :-(
> 
> Alfredo: it turned out that I can burn my CD's on Sunday afternoon European
> time. So there is a little time left.
> 
> Tim:
> 
> I deleted all the algebra I want to add except FAMR2 and built axiom. That
> worked fine.
> 
> Then I added FFFGF (which depends on FAMR2) and tried make. That
> failed. However
> 
> make NOISE= DAASE=$AXIOM/../../int
> 
> succeeded!
> 
> However, this doesn't suffice to make all layers work. I have to complete the
> build, then add the next layer, and so on.
> 
> I guess that
> 
> * the daase files in int should be updated after every layer.
> 
> * after the first update, i.e., after LAYER0BOOTSTRAP or so, DAASE should point
>   to int.
> 
> I have no idea yet, why the constructors don't show up in HyperDoc.

\start
Date: Fri, 15 Sep 2006 09:21:19 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: Help with adding algebra URGENT!

hmmm, something bogus going on with the databases...
clearly this needs to be fixed.

\start
Date: Fri, 15 Sep 2006 10:05:15 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: putting pamphlets on MathAction

On September 15, 2006 4:27 AM Martin Rubey wrote:
> 
> unfortunately, it doesn't seem to work yet. How can I make 
> MathAction compile a pamphlet?

??? What do you mean by "compile"?

Perhaps you expected that the SPAD code embedded in the pamphlet
file would be "compiled" the same way that

  \begin{spad}
  ...
  \end{spad}

is compiled on a wiki page? Unfortunately that is not yet supported
inside pamphlet files. To do that we need some extension to the
LaTeX style files that run Axiom automatically and embed the result
into the LaTeX code. The main reason is that we need pamphlet files
to work both inside and outside of the Axiom Wiki environment.

This does work now with the \begin{sageblock} and \sage commands.
It uses some LaTeX code that was contributed by a Sage developer.
See

  http://wiki.axiom-developer.org/SandBoxSagePamphlet

What we have to do is extend this for Axiom.

> 
> It seems that RECOP and the constructors in fffg.spad were 
> compiled, but those from mantepse weren't. Furthermore, I had
> to fix a typo in RECOP, but I didn't manage to recompile it.
> Could you please try?

To compile the code has to be in \begin{spad} ... \end{spad} in the
page source outside the pamphlet or on a non-pamphlet page.

> 
> I put the things into the places were I feel they belong.
> 
> rec.spad is now linked from RecurrenceRelationOperator, fffg.spad
> from FractionFreeFastGaussianElimination and mantepse.spad from
> GuessingFormulasForSequences.
>

Good.
 
> The pages Guess and SandBoxFFFG should be deleted.
> 

To do that you can log in as a Zope user. If you like, I can do
it for you.

\start
Date: Fri, 15 Sep 2006 10:11:21 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: Building Axiom on axiom-developer.org

Kai,

On September 15, 2006 4:56 AM you wrote:
>
> the build of Gold (--patch-50) fails for me. The first problem is that
> the X11 headers aren't found, which can be overcome by adding
> -I/usr/X11R6/include to CCF in the Makefile.linux chunk in the
> toplevel Makefile.pamphlet.
>
> Now it fails with
>
>   Unrecoverable error: NULL_OR_ON_C_STACK macro invalid.
>
> ...
>
> Any idea?
>

See extensive discussion on axiom-developer email list:

http://lists.nongnu.org/archive/cgi-bin/namazu.cgi?query=NULL_OR_ON_C_S=
TACK&
submit=Search%21&idxname=axiom-developer&max=20&result=normal&sor=
t=date%3Ala
te

The short story is that on the axiom-develop.org server you have to
reduce the MAXPAGE size to 128*256 or else upgrade to a newer version
of gcl-2.6.8pre.

\start
Date: 15 Sep 2006 16:16:39 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: putting pamphlets on MathAction

Bill Page writes:

> On September 15, 2006 4:27 AM Martin Rubey wrote:
> > 
> > unfortunately, it doesn't seem to work yet. How can I make MathAction
> > compile a pamphlet?
> 
> ??? What do you mean by "compile"?
> 
> Perhaps you expected that the SPAD code embedded in the pamphlet file would
> be "compiled" the same way that
> 
>   \begin{spad}
>   ...
>   \end{spad}
> 
> is compiled on a wiki page? 

Yes...

> Unfortunately that is not yet supported
> inside pamphlet files. 

Oh!

> > It seems that RECOP and the constructors in fffg.spad were compiled, but
> > those from mantepse weren't. Furthermore, I had to fix a typo in RECOP, but
> > I didn't manage to recompile it.  Could you please try?
> 
> To compile the code has to be in \begin{spad} ... \end{spad} in the
> page source outside the pamphlet or on a non-pamphlet page.

Ah, I'll try this then...

> > The pages Guess and SandBoxFFFG should be deleted.
> 
> To do that you can log in as a Zope user. If you like, I can do it for you.

I really would like to do this, but I cannot log in. I clicked on admin and
entered user kratt6 and my password, but it said "authentication failed"... Do
I misremember my username or my password?

\start
Date: 15 Sep 2006 16:50:36 +0200
From: Gabriel Dos Reis
To: Kai Kaminski
Subject: Re: Makefile.solaris9 stanza

Kai Kaminski writes:


[...]

| >    http://www.math.utexas.edu/pipermail/maxima/2006/014315.html
| Ok, I guess it is about the fact that ANSI CL doesn't require
| IEEE-754 floating point? Maybe I'm dense, but I don't get what you're
| trying to say (seriously).

the claimed portability of CL over C when basic things like that throw
practitionners "out of the roof" :-)

\start
Date: Fri, 15 Sep 2006 11:13:16 -0400
From: Bill Page
To: Gabriel Dos Reis, Kai Kaminski
Subject: RE: Makefile.solaris9 stanza

On September 15, 2006 10:51 AM Gabriel Dos Reis wrote:
> 
> Kai Kaminski writes:
> ... 
> | >  http://www.math.utexas.edu/pipermail/maxima/2006/014315.html
> | Ok, I guess it is about the fact that ANSI CL doesn't require
> | IEEE-754 floating point? Maybe I'm dense, but I don't get 
> | what you're trying to say (seriously).
> 
> the claimed portability of CL over C when basic things like that
> throw practitionners "out of the roof" :-)
> 

I suppose that should read "off the roof" (as in suicide :).

I also do not see any evidence for the claimed portability of
Common Lisp. On the other hand I see applications written in "C"
on all platforms out numbering Lisp applications by many orders
of magnitude.

There of course even portability problems with Java - which was
intended specifically to solve portability problems.

What can we say?

"Life is complicated."

"Programming is a complex problem."

...

\start
Date: Fri, 15 Sep 2006 11:24:55 -0400
From: Alfredo Portes
To: William Stein
Subject: Re: colinux

William,

> Just out of curiosity, what were the issues with colinux that forced
> you into using live Linux CD's, vmware, etc.?

I never used colinux.  The Doyen CD is based on Tim Daly's idea of a
collaborative science platform: http://daly.axiom-developer.org/doyen/ .

The goal of the project is to provide a common collaborative environment,
that
can be distributed in conferences, etc.

An example of this could be at Sage Days. It would be unlikely that
everybody in
the audience will have Sage on their machines, the same development tools,
experimental code, or  mathematical algorithms that you are demonstrating.
You could provide them with a Doyen disk created for that conference
(particular code, docs, etc.) and they will be able to reproduce exactly
what you are showing without having to modify anything on their machines.
Furthermore, with the help of a Local Wiki and a Online Wiki, the
participants can make suggestions and improvements and these will be stored
for future use.

So the two key points here are providing a science collaborative environment
and making code contributions more permanent. I should put emphasis on the
fact that Literal Programming is vital for these goals.

Probably Tim and Bill extend on the idea.

\start
Date: Fri, 15 Sep 2006 11:30:20 -0400
From: Alfredo Portes
To: William Stein
Subject: Re: colinux

> Probably Tim and Bill extend on the idea.
>

  That should be: Probably Tim and Bill can explain the Doyen idea better.
:-)

\start
Date: 15 Sep 2006 11:30:39 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger, Gabriel Dos Reis

Greetings!

Can we finalize this stat bit please?  I'm trying to get 2.6.8 out
....

In addition to knowing whether enough information is provided, I need
to know if it works on windows, macosx, and any other proprietary
system of interest.

Take care,

Camm Maguire writes:

> Greetings!
> 
> Bill Page writes:
> 
> > Gaby, 
> > 
> > On Monday, September 11, 2006 12:26 PM you wrote:
> > > 
> > > On Mon, 11 Sep 2006, root wrote:
> > > 
> > > | > The error from the configure is this:
> > > | > *******************************************
> > > | > Darwin
> > > | > Your system name is Darwin
> > > | > We do not know how to build for this kind of system
> > > | > Send a note to list about it
> > > | > *******************************************
> > > |
> > > |
> > > | Actually, this is correct. I do not yet know how to build
> > > | Axiom on a MAC. There has been a recent suggestion that we
> > > | use Xcode and I'm pursuing that path.
> > > 
> > > Tim --
> > > 
> > >   Jacob is a student at TAMU taking my class on symbolic
> > > computations. He is interested in provisos -- I suspect at
> > > some point he may get into touch with you. He is trying to
> > > build Axiom for his class work.
> > > 
> > > From what I understand, Bill has been able to build the
> > > build-improvements branch with some patches from Camm (which
> > > I believe I already put in build-improvements).
> > 
> > I have built the build-improvements branch on the axiom-developer
> > server (in fact that is what is running on MathAction right now).
> > But I think the build process still has some problems. For example,
> > I am not able to build (even if I specific '--without-noweb') if
> > noweb is not previously installed and in the PATH. Also, the
> > option to build from a previously installed gcl does not work
> > so the option '--without-gcl' is still necessary. Since building
> > from pre-installed gcl is possible on Debian using the Debian
> > source distribution for Axiom, there must still be something
> > missing from the 'gcl-system' option in the build-improvements
> > branch.
> 
> Please let me know if you need any help or clarification here.  All my
> patches are under the debian subdirectory, patch.all and patch.merge.
> 
> > 
> > There is also an additional patch which I am still discussing
> > with Camm to solve the "Can't rename' problem. The patch that
> > I am using now might not be the ultimate solution of gcl-2.6.8.
> > 
> 
> I looked at this discussion, and there does not appear to be a
> consensus on probe-file and directory.  As far as GCL goes, we can do
> anything that passes Paul's ansi tests, as we do at the moment.  So if
> you have such a suggestion, we can implement same.
> 
> The easy way, which avoids the requirement of PDP-10 lisp
> comaptability :-), is si::stat.  How about this:
> 
> Index: unixfsys.c
> ===================================================================
> RCS file: /cvsroot/gcl/gcl/o/unixfsys.c,v
> retrieving revision 1.28
> diff -u -r1.28 unixfsys.c
> --- unixfsys.c	24 Aug 2006 16:53:28 -0000	1.28
> +++ unixfsys.c	12 Sep 2006 16:35:56 -0000
> @@ -23,6 +23,7 @@
>  #include <stdlib.h>
>  #include <unistd.h>
>  #include <errno.h>
> +#include <time.h>
>  
>  #define IN_UNIXFSYS
>  #include "include.h"
> @@ -490,6 +491,34 @@
>  }
>  
>  
> +DEF_ORDINARY("DIRECTORY",sKdirectory,KEYWORD,"");
> +DEF_ORDINARY("LINK",sKlink,KEYWORD,"");
> +DEF_ORDINARY("FILE",sKfile,KEYWORD,"");
> +
> +DEFUN_NEW("STAT",object,fSstat,SI,1,1,NONE,OO,OO,OO,OO,(object path),"") {
> +
> +  char filename[4096];
> +  struct stat ss;
> +  
> +
> +  bzero(filename,sizeof(filename));
> +  coerce_to_filename(path,filename);
> +  if (lstat(filename,&ss))
> +    RETURN1(Cnil);
> +  else {
> +    int j;
> +    ctime_r(&ss.st_ctime,filename);
> +    j=strlen(filename);
> +    if (isspace(filename[j-1]))
> +      filename[j-1]=0;
> +    RETURN1(list(3,S_ISDIR(ss.st_mode) ? sKdirectory : 
> +		 (S_ISLNK(ss.st_mode) ? sKlink : sKfile),
> +		 make_fixnum(ss.st_size),make_simple_string(filename)));
> +  }
> +}
> +
> +
> +
>  DEFUN_NEW("SETENV",object,fSsetenv,SI,2,2,NONE,OO,OO,OO,OO,(object variable,object value),"Set environment VARIABLE to VALUE")
>  
>  {
> 
> 
> >(si::stat "/tmp/ff1.h")
> 
> (:LINK 9 "Tue Sep 12 12:32:58 2006")
> 
> >(si::stat "/tmp/ff.h")
> 
> (:FILE 0 "Mon Dec  5 13:52:23 2005")
> 
> >(si::stat "/tmp/")
> 
> (:DIRECTORY 81920 "Tue Sep 12 12:34:53 2006")
> 
> >(si::stat "/tmp")
> 
> (:DIRECTORY 81920 "Tue Sep 12 12:34:53 2006")
> 
> >(si::stat "/tmp1")
> 
> NIL
> 
> >
> 
> 
> If we can agree on the interface, and on the Windows and Mac
> equivalents, I can get this into 2.6.8 before release.
> 
> If there are any problems with the Debian package setup, please let me
> know.   Will do a new axiom release once I can get 2.6.8pre to build
> on mips and m68k.
> 
> Take care,
> 
> 
> > Until a few days ago, I was also working on the SourceForge
> > compile farm - specifically on the OS X build. But SourceForge
> > currently has a network configuration problem which prevents me
> > from accessing their servers:
> > 
> > https://sourceforge.net/tracker/?func=detail&atid0001&aid=1553456&gro
> > up_id=1
> > 
> > > I have a fix for the debian failure.  Once that is in, I would
> > > like to make a tarball of build-improvements available from
> > > axiom-developer.org or from SF (whichever is OK with you).
> > > This is to remove the "random" checkout errors.
> > > 
> > 
> > I also continue to see some svn checkout errors. In some cases
> > on some platforms this seems to be a recoverable error by just
> > repeating the 'svn co' command until the checkout completes. On
> > others, the local svn archive gets unrecoverably locked. :(
> > 
> > I wonder if this might be another network configuration problem
> > at SourceForge?
> > 
> > Maybe we should setup a mirror of the SourceForge SVN repository
> > on the axiom-developer.org server? Then at least we would have an
> > alternate site in case there is a network problem.

\start
Date: Fri, 15 Sep 2006 11:45:47 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: axiom.silver
Cc: Jaroslov Rosenberger, Gabriel Dos Reis

Camm,

On September 15, 2006 11:31 AM you wrote:
>
> Can we finalize this stat bit please?  I'm trying to get 2.6.8
> out ...
>

Great!

> In addition to knowing whether enough information is provided,
> I need to know if it works on windows, macosx, and any other
> proprietary system of interest.
>

I think your proposal for the si::stat function is perfect.
I hope that it meets approval with other GCL users.

I will try your patch on Windows tonight and report results
tomorrow morning.

Regards,
Bill Page.

>
> Camm Maguire writes:
> ...
> > How about this:
> >
> > Index: unixfsys.c
> > =
==========================
==========================
====
> > RCS file: /cvsroot/gcl/gcl/o/unixfsys.c,v
> > retrieving revision 1.28
> > diff -u -r1.28 unixfsys.c
> > --- unixfsys.c	24 Aug 2006 16:53:28 -0000	1.28
> > +++ unixfsys.c	12 Sep 2006 16:35:56 -0000
> > @@ -23,6 +23,7 @@
> >  #include <stdlib.h>
> >  #include <unistd.h>
> >  #include <errno.h>
> > +#include <time.h>
> > 
> >  #define IN_UNIXFSYS
> >  #include "include.h"
> > @@ -490,6 +491,34 @@
> >  }
> > 
> > 
> > +DEF_ORDINARY("DIRECTORY",sKdirectory,KEYWORD,"");
> > +DEF_ORDINARY("LINK",sKlink,KEYWORD,"");
> > +DEF_ORDINARY("FILE",sKfile,KEYWORD,"");
> > +
> >
> +DEFUN_NEW("STAT",object,fSstat,SI,1,1,NONE,OO,OO,OO,OO,
> (object path),"") {
> > +
> > +  char filename[4096];
> > +  struct stat ss;
> > + 
> > +
> > +  bzero(filename,sizeof(filename));
> > +  coerce_to_filename(path,filename);
> > +  if (lstat(filename,&ss))
> > +    RETURN1(Cnil);
> > +  else {
> > +    int j;
> > +    ctime_r(&ss.st_ctime,filename);
> > +    j=strlen(filename);
> > +    if (isspace(filename[j-1]))
> > +      filename[j-1]=0;
> > +    RETURN1(list(3,S_ISDIR(ss.st_mode) ? sKdirectory :
> > +		 (S_ISLNK(ss.st_mode) ? sKlink : sKfile),
> > +		 make_fixnum(ss.st_size),make_simple_string(filename)));
> > +  }
> > +}
> > +
> > +
> > +
> >  DEFUN_NEW("SETENV",object,fSsetenv,SI,2,2,NONE,OO,OO,
> OO,OO,(object variable,object value),"Set environment VARIABLE
> to VALUE")
> > 
> >  {
> >
> >
> > >(si::stat "/tmp/ff1.h")
> >
> > (:LINK 9 "Tue Sep 12 12:32:58 2006")
> >
> > >(si::stat "/tmp/ff.h")
> >
> > (:FILE 0 "Mon Dec  5 13:52:23 2005")
> >
> > >(si::stat "/tmp/")
> >
> > (:DIRECTORY 81920 "Tue Sep 12 12:34:53 2006")
> >
> > >(si::stat "/tmp")
> >
> > (:DIRECTORY 81920 "Tue Sep 12 12:34:53 2006")
> >
> > >(si::stat "/tmp1")
> >
> > NIL
> >
> > >=04
> >
> >
> > If we can agree on the interface, and on the Windows and Mac
> > equivalents, I can get this into 2.6.8 before release.

\start
Date: Fri, 15 Sep 2006 12:44:16 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: timeout?

Martin,

Yes, there is a time-limit of 1 minute for Axiom on MathAction
to prevent any problems where a run-away process hangs the whole
system.

Can you think of why it might take more than a minute to compile
that page? If absolutely necessary I can temporarily relax this
restriction.

Regards,
Bill Page.

On September 15, 2006 12:08 PM Martin Rubey wrote:
> 
> I don't manage to compile the code on
> 
> http://wiki.axiom-developer.org/MantepseSpad2
> 
> I guess that there is a timeout...
> 
> Could you please check?
> 

\start
Date: Fri, 15 Sep 2006 18:48:35 +0200
From: Gregory Vanuxem
To: Kai Kaminski
Subject: [Fwd: Re: A Canonical Axiom GUI]

Thanks for your quick reply. I can not send a mail to you, gmx.de does
not accept mails from my ISP, so I send it here. In fact I wanted to
know why you think that  _Axiom is somewhat 'unfriendly' to program_,
but in general and not only about interfacing with textual chatters. I
misunderstood what you mean, sorry.

I agree with all you said in your mail about the mess of using the
AXIOMsys input/output in a UI. I think this is the method used by Sage
(with the pexpect python module), when the user works directly with GAP
or GP objects for example, and I have to say that I'm not a big fan of
this method. They will encounter the problems/annoyances you mentioned
when they will create the interface to Axiom.  A last thing, I think
that, yes, the creation of a well defined communication protocol, as you
argued in previous mails, is the way to begin/go. About communicating, I
have seen that some socket related routines have been added to Axiom but
it seems that they are not used. It's probably an anticipatory work of
Tim.

Again thanks,

Greg

P.S: I finally forwarded your mail to this list with some hesitations.

-------- Message transf=E9r=E9 --------

Gregory Vanuxem writes:

>> -----Message d'origine-----
>> De : axiom-developer-bounces+g.vanuxem=wanadoo.fr@nongnu.org
a
>> part de Kai Kaminski
>> Envoye : vendredi 8 septembre 2006 15:56
>> A : C Y
>> Cc : list
>> Objet : Re: A Canonical Axiom GUI
>
> [...]
>
>> I don't know why TeXmacs isn't as tightly integrated with any
>> mathematical environment as you'd wish. I *do* know, though, that it
>> would be fairly hard to integrate it closely with Axiom, because Axiom
>> is somewhat 'unfriendly' to programs. If anyone feels that this claim
>> should be substantiated I'll happily give a few examples.
>
> Yes, please, when time permits.


Suppose you want to write a UI for Axiom (terminal app, Emacs mode,
GUI) that does more than just sending all user input to Axiom and
spitting out whatever Axiom prints. You encounter at least the
following problems/annoyances.

0) Right after startup Axiom displays a banner, which you have to
   ignore (in fact, you might even want to extract the version number,
   eg. for bug reports). Your UI starts AXIOMsys instead of axiom, so
   that error messages don't mess up the banner if X11 isn't running.

   Right after the banner there is either the prompt or random junk,
   depending on the content of ~/.axiom.input. What do you do with
   that junk?

1) How do you recognize the end of output?

   a) Wait until the next prompt/type signature/etc pops up.

      What if some user code prints something that resembles a
      prompt/type signature/etc? Also there are at least five
      different settings for the prompt. Other output options may or
      may not influence the display of the type signature.

   b) Wait until no more output comes.

      How do you know that nothing else will come down the pipe?


2) How do you extract meaningful data from the output?

   You'd probably be interested in things like

   - What is the IOindex of the last command? (The IOindex is the
     position in Axiom's history in that particular frame)

   - Did any errors occur? Which ones? Where?

   - Which type did the last result have?

   - What is the value of the last result?

   - What libraries were autoloaded because of the last command?

   - What other output did the last command produce?

   - What error/status messages did Axiom itself produce?

   There is no reliable way to do this, because whatever you think is
   a type signature, for example, could just be some output of the
   user that only looks like one.


3) How do you query Axiom for information?

   Suppose you want to get a list of the available domains. Sending
   ')wd' to Axiom does the trick. But again you have to parse some
   random, human-readable format that might not even contain all the
   information you're after.


4) How about integrating the HyperDoc and graphics subsystems in your
   GUI?

   First of all you'll have to open a number of AF_UNIX (why not
   AF_INET?)  sockets (good luck figuring out their names). Then you
   have to implement a number of binary protocols (yay!) that aren't
   documented anywhere.


5) How about Chinese?

   One would hope that eventually Axiom prints system messages in the
   language of its user. Now try to extract the information you need
   when all the messages are in Chinese.


There are ways around some of the problems described above. For
example, instead of sending user input directly to Axiom, you could
always send

  )lisp (foo ...)

where foo is a Lisp program that does what you want. Since you can
access everything from Lisp that would (probably) work. Needless to
say that it is messy, error-prone and relies on Axiom internals. Hence
you won't be able to change certain aspects of Axiom's implementation
without breaking foo, which breaks your UI.


The solution is quite simple. Instead of throwing textual chatter at
the UI, send structured data

(:result
  (:value some-structural-representation)
  (:type ("Fraction" "Integer"))
  (:presentation
    (:tex "\frac{5}{4}")
    (:ascii "5\\n-\\n4")
    (:mathml "???"))
  (:input-form "5/4")
  (:io-index 204)
  (:errors nil)
  (:warnings ((:low-memory "Running low on memory")))
  (:output nil)
  (:plot-data nil)

or, for the XML-inclined

<result>
  <value>5</value>
  ...
</result>

Axiom has all that information, emitting something like the above is
almost trivial. You now know when the output is complete (when a
well-formed answer has been received) and you can easily distinguish
all kinds of information.

\start
Date: 15 Sep 2006 18:59:58 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: timeout?

Bill Page writes:

> Martin,
> 
> Yes, there is a time-limit of 1 minute for Axiom on MathAction
> to prevent any problems where a run-away process hangs the whole
> system.
> 
> Can you think of why it might take more than a minute to compile
> that page? If absolutely necessary I can temporarily relax this
> restriction.

Well, it takes several minutes on my computer. I don't really know why, but I
know that the compiler is a very sensitive creature. For example, moving the
operations ord1, ord2, deg1, deg2 towards the end of the constructor GUESS, on
my machine, the code will take nearly an hour to compile.

Similar findings are actually documented in some algebra files that are
currently shipped with axiom...

Thus, please either temporarily relax the time restriction (set it to 10 min,
for example) or compile the file by hand...

\start
Date: Fri, 15 Sep 2006 15:26:52 -0500
From: Jay Belanger
To: list
Subject: Re: [Fwd: Your message to Axiom-commit	awaitsmoderator approval]

Bill Page writes:
...
> I think you are right. SourceForge seems to be having ongoing
> network problems. I still can not access the compile farm.

Good; sorta.  At least it's not just me, I've been trying to access it
all week.  I seem to recall recently reading that there are other
compile farms, but I can't track down where I read it.  Maybe I
dreamed it.  Does anyone know if there's another compile farm similar
to sourceforge's?

\start
Date: Fri, 15 Sep 2006 17:39:19 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: timeout?

Martin,

On September 15, 2006 1:00 PM you wrote:
>
> Bill Page writes:
> 
> > Yes, there is a time-limit of 1 minute for Axiom on MathAction
> > to prevent any problems where a run-away process hangs the whole
> > system.
> > 
> > Can you think of why it might take more than a minute to compile
> > that page? If absolutely necessary I can temporarily relax this
> > restriction.
> 
> Well, it takes several minutes on my computer. I don't really know
> why, but I know that the compiler is a very sensitive creature. For 
> example, moving the operations ord1, ord2, deg1, deg2 towards the
> end of the constructor GUESS, on my machine, the code will take
> nearly an hour to compile.

That is ridiculously long! There has got to be a pretty serious
but in SPAD to take so long. :-(

> 
> Similar findings are actually documented in some algebra 
> files that are currently shipped with axiom...
>

This does not seem to happen during the usual build of Axiom.

> Thus, please either temporarily relax the time restriction 
> (set it to 10 min, for example) or compile the file by hand...
> 

It was easy for me to change it to 60 minutes. So you should
have plenty of time to compile now.

\start
Date: Fri, 15 Sep 2006 19:18:55 -0400
From: Tim Daly
To: Troy Dawson
Subject: Re: Interest in Scientific Linux

> Hello,
> As we get started with Scientific Linux we are just checking as people 
> sign up for the development mailing list what is bringing them to 
> Scientific Linux.
> Would you mind sharing what your interest is in Scientific Linux?


I'm the lead developer on Axiom. Axiom was originally developed over
a 23 year period at IBM Research (I was one of the original authors).
It was eventually sold to NAG. Axiom used to be sold commercially
as a competitor to Mathematica and Maple. In 2000 it was withdrawn
from the market and released as open source. See
http://wiki.axiom-developer.org

I'm also the lead developer on Doyen. Doyen is a scientific
computing platform based on LiveCDs (similar to Knoppix). See
http://daly.axiom-developer.org/doyen
Doyen is intended as a vehicle to make scientific software
available at computational science conferences.


We attempt to work cooperatively to bring together the best
available talent and tools. I signed up for the developer
mailing list so I can understand what the current concerns
are for Scientific Linux and to connect with developers who
have an interest in working together.

\start
Date: Sat, 16 Sep 2006 02:14:21 -0400
From: Bill Page
To: list
Subject: mercurial source code control system

http://www.selenic.com/mercurial/wiki

We are already using 4 different source code control systems in
the Axiom project (CVS, ARCH, SVN, DARCS) and no one is entirely
happy with any one of them, so what's the harm in considering
yet another? :-)

Mercurial (Hg) has been getting some very good reviews. The Sage
developers are considering switching from darcs to Hg for reasons
of performance. They recommend the following introduction:

http://indico.cern.ch/contributionDisplay.py?contribId=29&sessionId=4=
9&confI
d=44

\start
Date: Sat, 16 Sep 2006 08:47:13 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: mercurial source code control system

> We are already using 4 different source code control systems in
> the Axiom project (CVS, ARCH, SVN, DARCS) and no one is entirely
> happy with any one of them, so what's the harm in considering
> yet another? :-)

Gaby uses SVK to access our SVN archive. ;-)

Seriously, who is using CVS? Should we consider to drop keeping the CVS 
archive(s) in sync with GOLD? Should we drop CVS support? This synching 
process is needless work in my eyes... and we don't have so much resources.

\start
Date: 16 Sep 2006 09:00:10 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: mercurial source code control system

Ralf Hemmecke writes:

| > We are already using 4 different source code control systems in
| > the Axiom project (CVS, ARCH, SVN, DARCS) and no one is entirely
| > happy with any one of them, so what's the harm in considering
| > yet another? :-)
| 
| Gaby uses SVK to access our SVN archive. ;-)

Indeed.

How many active developers do we have?  How many VCS do we use?

I'm quite happy with SVN+SVK.  It is a pity SF's server is such a pain
in the ass to work with. :-(

| Seriously, who is using CVS? Should we consider to drop keeping the
| CVS archive(s) in sync with GOLD? Should we drop CVS support? This
| synching process is needless work in my eyes... and we don't have so
| much resources.

it looks like we are more effective at replicating the base source
code in many VCS than actually moving it forward :-/
(that includes me)

\start
Date: 16 Sep 2006 13:11:41 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: timeout?

Bill Page writes:

> It was easy for me to change it to 60 minutes. So you should
> have plenty of time to compile now.

Thank you, but it still fails. Could you please compile it by hand? It is
probably wiser to extract the code from the pamphlet stored at mathaction, I
don't really know what code is on mantepse2 now...

The trouble is, MathAction doesn't tell me what happened...

\start
Date: 16 Sep 2006 13:57:32 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: timeout?

Martin Rubey writes:

> The trouble is, MathAction doesn't tell me what happened...

I just realized that only the display doesn't work. The code was compiled
alright.

\start
Date: 16 Sep 2006 16:13:12 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: libspad, hash.o

  Is there a reason why src/lib/hash.o is not put in the object
archive src/lib/libspad.a?

\start
Date: Sat, 16 Sep 2006 10:25:08 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: libspad, hash.o

>  Is there a reason why src/lib/hash.o is not put in the object
>archive src/lib/libspad.a?

nope

\start
Date: 16 Sep 2006 17:21:19 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: libspad, hash.o

Tim Daly writes:

| >  Is there a reason why src/lib/hash.o is not put in the object
| >archive src/lib/libspad.a?
| 
| nope

OK, thanks!

\start
Date: Sat, 16 Sep 2006 09:40:38 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Question concerning types...

Question came up on IRC, and I'm curious.  Given the following:

                        AXIOM Computer Algebra System 
                       Version: Axiom (September 2006)
             Timestamp: Saturday September 9, 2006 at 11:29:25 
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------
 
   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase
(1) -> 
(1) -> a1 : Quaternion Fraction Integer
                                                                  
Type: Void
(2) -> a2 : Quaternion Fraction Integer
                                                                  
Type: Void
(3) -> a3 : Quaternion Fraction Integer
                                                                  
Type: Void
(4) -> a4 : Quaternion Fraction Integer
                                                                  
Type: Void
(5) -> a1
 5) -> 
   a1 is declared as being in Quaternion Fraction Integer but has not 
      been given a value.
(5) -> m := matrix[[a1,a2],[a3,a4]]
 5) -> 
   a1 is declared as being in Quaternion Fraction Integer but has not 
      been given a value.
(5) -> 

Why isn't this allowed?  I want a1->a4 to be variables without assigned
value, and I want to create a symbolic matric where all I know about
the entries is their type, in order to do general solving operations. 
How would I set this up correctly in Axiom?

\start
Date: 16 Sep 2006 18:51:09 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: Question concerning types...

Cliff Yapp writes:

> Question came up on IRC, and I'm curious.  Given the following:
> 
>                         AXIOM Computer Algebra System 
>                        Version: Axiom (September 2006)
>              Timestamp: Saturday September 9, 2006 at 11:29:25 
> -----------------------------------------------------------------------------
>    Issue )copyright to view copyright notices.
>    Issue )summary for a summary of useful system commands.
>    Issue )quit to leave AXIOM and return to shell.
> -----------------------------------------------------------------------------
>  
>    Re-reading compress.daase   Re-reading interp.daase
>    Re-reading operation.daase
>    Re-reading category.daase
>    Re-reading browse.daase
> (1) -> 
> (1) -> a1 : Quaternion Fraction Integer
>                                                                   
> Type: Void
> (2) -> a2 : Quaternion Fraction Integer
>                                                                   
> Type: Void
> (3) -> a3 : Quaternion Fraction Integer
>                                                                   
> Type: Void
> (4) -> a4 : Quaternion Fraction Integer
>                                                                   
> Type: Void
> (5) -> a1
>  5) -> 
>    a1 is declared as being in Quaternion Fraction Integer but has not 
>       been given a value.
> (5) -> m := matrix[[a1,a2],[a3,a4]]
>  5) -> 
>    a1 is declared as being in Quaternion Fraction Integer but has not 
>       been given a value.
> (5) -> 
> 
> Why isn't this allowed?  I want a1->a4 to be variables without assigned
> value, and I want to create a symbolic matric where all I know about
> the entries is their type, in order to do general solving operations. 
> How would I set this up correctly in Axiom?

Currently, you can't. Note that you promise axiom that a1 is a Quaternion
Fraction Integer. However, you don't hold your promise...

What you want is to make a1 a variable. Currently, there is no domain of
"Variables, which can take values only in Quaternion Fraction Integer".

In fact, it is (or should be) a FAQ. See MathAction.

The point of Axioms type system is that any identifier has a typed value. There
is no such thing as a identifier that does not have a value.

If you type 

5*a+a^2

into the interpreter, it responds with

Polynomial Integer.

When you say p:=5*a+3*a^2, the identifier p refers to this polynomial. The
internal representation is something like

[[5,a,1],[3,a,2]]

How would you represent a generic polynomial? You need a different domain for
that.

\start
Date: Sat, 16 Sep 2006 10:18:38 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey
Subject: Re: Question concerning types...

> Currently, you can't. Note that you promise axiom that a1 is a
> Quaternion Fraction Integer. However, you don't hold your promise...

How do I not hold it?  I never told it anything about a1 except what
type it is - were did I contradict this?

> What you want is to make a1 a variable. Currently, there is no domain
> of "Variables, which can take values only in Quaternion Fraction
> Integer".

Um.  That's surprising, at least to me.  (I suppose it wouldn't be if I
understood...)  Intuitively I would expect Variable to mean simply "an
unspecified specific instance of a Domain/Type/what have you" with ALL
domains being possible - just so long as you specify the type of the
variable, e.g.:

a1 : Variable(Matrix Quaternion Fraction Integer)

A specific example might be with working in dimensional types:  If I
define F as type Force, m as type Mass, and a as type Length/Time^2 I
want to be able to define m1 as type Mass and enter the expression
m*a/m1 into the interperter to return a of type Length/Time^2 without
having to ever specify any particular mass or acceleration.  But I want
that type information to be carried and used in the calculations - in
fact, it is essential.

> In fact, it is (or should be) a FAQ. See MathAction.

I took a look at the FAQ link, but I might have missed it.  I'll check
again.

> The point of Axioms type system is that any identifier has a typed
> value. There is no such thing as a identifier that does not have a
> value.
> 
> If you type 
> 
> 5*a+a^2
> 
> into the interpreter, it responds with
> 
> Polynomial Integer.

But what if I want a to have a specific type, for example limit it to
Quaternions only?
 
> When you say p:=5*a+3*a^2, the identifier p refers to this
> polynomial. The internal representation is something like
> 
> [[5,a,1],[3,a,2]]
> 
> How would you represent a generic polynomial? You need a different
> domain for that.

I guess I'm not following why things can't be further restricted by
saying in this particulary case a is of type FOO, and therefore doing
two things:

1)  restricting the evaluation of the polynomial substitutions for a
which are of type FOO

2)  allowing algorithms to use the knowledge that for this polynomial a
is restricted to some subset to make further deductions,
simplifications, and otherwise provide more precise answers

Sorry if this is an obviously trivial question.

\start
Date: Sat, 16 Sep 2006 14:36:58 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: [Fwd: AXIOM 138]
Cc: Larry Lambe

Gaby,

Larry Lambe has been trying to build Axiom on a 64-bit SUSE box.
One of the issues he ran into a couple problems and I pointed
him at the build-improvements branch. I'm not sure how you 
handle the X11/lib64 issue.

===============================================================

.....[snip].....

I am running SUSE 10.1, x86_64 and the make fails next by 
looking in X11/lib and not X11/lib64.  Could this be fixed in 
"configure"?  I changes to lib64 manually and the make concluded.  

.....[snip].....

However, it seems that hyperdoc is not working, specifically Browse.  I 
typed "LIST" in the input field, clicked on "Domains" and it asked if I 
wanted to see all domains.  I clicked "yes" and it brought up only 
*PlaneAlgebraicCurvePlot and SingleInteger.  Finally, neither 2D or 3D 
plotting work.  The latter is working in the Sept 2005 version that I 
recompiled on my current system.  Should I try another branch?  Thanks,

\start
Date: Sat, 16 Sep 2006 14:57:08 -0400
From: Tim Daly
To: Larry Lambe
Subject: (no subject)

The build-improvements branch uses automake.
I believe the process is just:

./configure
make

but Gabriel (Gaby) is the author of the new makefiles
and can answer questions about it better than I can.
He's copied here as Gabriel Dos Reis

\start
Date: Sat, 16 Sep 2006 22:03:23 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Question concerning types...

On 09/16/2006 07:18 PM, C Y wrote:
> --- Martin Rubey wrote:
> 
>> Currently, you can't. Note that you promise axiom that a1 is a
>> Quaternion Fraction Integer. However, you don't hold your promise...

> How do I not hold it?  I never told it anything about a1 except what
> type it is - were did I contradict this?

I don't know exactly what Martin meant with the promise, but think of
the following.

MachineInteger is in libaldor what SingleInteger is in Axiom. For a
particular element of that type you have exactly 32 bits.
Let's appreviate "macro I == MachineInteger;". Now, if you say

m: I;

in the interpreter, the interpreter has to take care of the fact that
this m does not have a value, since any of the 32 bits is reserved for
holding a true MachineInteger. Now assume you do simply

n: I := m + m;

then n does not have a value. However, there is a relation between m and
n. Where do you store that information? Certainly not in MachineInteger.
And hopefully also NOT in the interpreter. There should be a general
domain that handles such things. Something like a typed expression tree
which then could be used by the interpreter to figure out what you mean.
But to write such a domain, is another story.

BTW, why would you want typed variables in the first place?

What you wrote that looked to me like you want to replace the a_i later
with concrete values.

But looking at

m := matrix[[a1,a2],[a3,a4]]

maybe you want

Q == Quaternion Fraction Integer;

m(a1: Q, a2: Q, a3: Q, a4: Q): Matrix Q := matrix[[a1,a2],[a3,a4]];

???

If you want general solving facilities then you actually want m as a
variable and you need to tell the solver what your solution space is.

>> What you want is to make a1 a variable. Currently, there is no domain
>> of "Variables, which can take values only in Quaternion Fraction
>> Integer".
> 
> Um.  That's surprising, at least to me.  (I suppose it wouldn't be if I
> understood...)  Intuitively I would expect Variable to mean simply "an
> unspecified specific instance of a Domain/Type/what have you" with ALL
> domains being possible - just so long as you specify the type of the
> variable, e.g.:
> 
> a1 : Variable(Matrix Quaternion Fraction Integer)

Ask yourself who should take care about the type knowledge that you give
here. Where would you store that information?

> A specific example might be with working in dimensional types:  If I
> define F as type Force, m as type Mass, and a as type Length/Time^2 I
> want to be able to define m1 as type Mass and enter the expression
> m*a/m1 into the interperter to return a of type Length/Time^2 without
> having to ever specify any particular mass or acceleration.  But I want
> that type information to be carried and used in the calculations - in
> fact, it is essential.

Yes, that is possible. You know, we have discussed that already. We just
do not yet have proper code. The "dimension.as" file that I sent to the
list on 29-Aug-2006 is a first attempt but not as fully functional as
you would like. But don't worry, we come to that. However, I think that
it is not going to work in SPAD.

\start
Date: 16 Sep 2006 22:09:32 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [Fwd: AXIOM 138]
Cc: Larry Lambe

Tim Daly writes:

| Gaby,
| 
| Larry Lambe has been trying to build Axiom on a 64-bit SUSE box.
| One of the issues he ran into a couple problems and I pointed
| him at the build-improvements branch.


I build dayly axiom.build-improvements on x86_64-suse-linux.

| I'm not sure how you 
| handle the X11/lib64 issue.

This is the same issue as why you special-cased the Makefile for fedora4.

Autoconf has facilities to detect where X11 includes and libraries
are.  In particular it computes all the flags necessary to link
against X11.  The relevant portion of configure.ac.pamphlet on
build-improvements is:

   \section{Where is X11?}

   One of the thorniest issues with programs that use the X Window System
   is portability.  There exist many implementations of the X11
   specification, each with its own variations, extensions, and what
   not.  Designing hand-written, makefiles for such programs can be a
   daunting task, fraut with all kinds of traps.  Fortunately, Autoconf
   provides us with some help, namely the macro [[AC_PATH_X]] and
   [[AC_PATH_XTRA]].  The former searches the directories where the
   include files and the libraries file for X11 reside.  The later is an
   enhanced version that:
   \begin{itemize}
   \item computes the C compiler flags required by X;
   \item computes the linker flags required by X;
   \item checks for special libraries that some systems need in order to
      compile X programs;
   \item checks for special X11R6 libraries that need to be linked before
     the flag [[-lX11]].
   \end{itemize}

   <<locate X11>>=
   AC_PATH_XTRA
   ## Output directives for the C compiler
   AC_SUBST(X_CLFAGS)
   ## Output directives for the linker
   AC_SUBST(X_LIBS)
   ## Output any extra libraries required by X11
   AC_SUBST(X_EXTRA_LIBS)

   ## Finally, output the list of libraries that need to appear before -lX11
   ## Some part of Axiom depends on Xpm.  That library has kind uncertain
   ## future.  At some point in the past, it was deprecated, to be
   ## replaced by xpm-nox; then came back again.  So, its support may
   ## vary from system to system.  For the moment, we assume that if X11
   ## is found then, Xpm is already present.  Though, clearly that is a
   ## very optimistic assumption.  Long term, Axiom should get rid of
   ## dependence on Xpm.  A nearly fool-proof test would be probably
   ## inspired by AC_PATH_XTRA.  I don't have time to get to that
   ## complication right now.  Will fix later.
   X_PRE_LIBS="-lXpm $X_PRE_LIBS"
   AC_SUBST(X_PRE_LIBS)
   @

| ===============================================================
| 
| .....[snip].....
| 
| I am running SUSE 10.1, x86_64 and the make fails next by 
| looking in X11/lib and not X11/lib64.  Could this be fixed in 
| "configure"?  I changes to lib64 manually and the make concluded.  
| 
| .....[snip].....
| 
| However, it seems that hyperdoc is not working, specifically Browse.  I 
| typed "LIST" in the input field, clicked on "Domains" and it asked if I 
| wanted to see all domains.  I clicked "yes" and it brought up only 
| *PlaneAlgebraicCurvePlot and SingleInteger.  Finally, neither 2D or 3D 
| plotting work.  The latter is working in the Sept 2005 version that I 
| recompiled on my current system.  Should I try another branch?  Thanks,

on build-improvements, hyperdoc is not working because of a path issue
(fixed in --patch-50).  It was low priority for me, but I can fix it
quickly if Larry was to test the build-improvements branch and he
needs it.

\start
Date: 16 Sep 2006 22:10:48 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: none
Cc: Larry Lambe

Tim Daly writes:

| The build-improvements branch uses automake.

s/automake/Autoconf/

| I believe the process is just:
| 
| ./configure
| make

indeed.

Let me know if you encounter problems.

\start
Date: 16 Sep 2006 22:20:39 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Question concerning types...

Ralf Hemmecke writes:

[...]

| then n does not have a value. However, there is a relation between m and
| n. Where do you store that information? Certainly not in MachineInteger.
| And hopefully also NOT in the interpreter. There should be a general
| domain that handles such things. Something like a typed expression tree
| which then could be used by the interpreter to figure out what you mean.
| But to write such a domain, is another story.

Why Expression(I) could not be made to work with that?

More generally, I would like to see support for symbolic expressions
in Axiom.

Yesterday, it took me very time lines to code some simple symbolic
expression  manipulation in Mathematica.  The thing in Axiom would
have eaten my evening :-(

\start
Date: Sat, 16 Sep 2006 13:54:24 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Question concerning types...

> HI Cliff,

Hey Ralf.
 
> MachineInteger is in libaldor what SingleInteger is in Axiom. For a
> particular element of that type you have exactly 32 bits.
> Let's appreviate "macro I == MachineInteger;". Now, if you say
> 
> m: I;
> 
> in the interpreter, the interpreter has to take care of the fact that
> this m does not have a value, since any of the 32 bits is reserved
> for holding a true MachineInteger. Now assume you do simply
> 
> n: I := m + m;
> 
> then n does not have a value. However, there is a relation between m
> and n. Where do you store that information? Certainly not in
> MachineInteger.

Wouldn't that information be associated with the variable n?

> And hopefully also NOT in the interpreter. There should be a general
> domain that handles such things. Something like a typed expression
> tree which then could be used by the interpreter to figure out what
> you mean. But to write such a domain, is another story.

I must be thinking about this incorrectly.  I was thinking along these
lines:

m : I;  -- Creates a Variable with type MachineInteger.  m doesn't
        -- reserve space for a value in this form because there is
        -- no value - not until an actual value is assigned is the
        -- space needed.

m := 3;  -- Assigns a specific value to m.  m internally is coerced
         -- to a structure which holds not only the type information
         -- as above but also a specific value

n: I := m + m;  -- If m is defined only as m : I, this creates a
             -- variable with type MachineInteger and a value that
             -- is a function of m

> BTW, why would you want typed variables in the first place?

The use that came up on IRC was working with Quaternion matrix elements
and solving a matrix system to find equations, IIRC.  More generally,
mightn't one expect that things like solve algorithms and integration
would be able to use specific type information on variables to arrive
at more specific solutions than more general algorithms could find? 

> What you wrote that looked to me like you want to replace the a_i
> later with concrete values.

Possible, but also the intent might be to solve for a general symbolic
equation.

> But looking at
> 
> m := matrix[[a1,a2],[a3,a4]]
> 
> maybe you want
> 
> Q == Quaternion Fraction Integer;
> 
> m(a1: Q, a2: Q, a3: Q, a4: Q): Matrix Q := matrix[[a1,a2],[a3,a4]];
> 
> ???

Depending on the application, that is another potential use - when I
tried those two lines though, here's what happened:

                        AXIOM Computer Algebra System 
                       Version: Axiom (September 2006)
             Timestamp: Saturday September 9, 2006 at 11:29:25 
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------
 
   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase
(1) -> 
(1) -> Q == Quaternion Fraction Integer;
                                                                  
Type: Void
(2) -> m(a1: Q, a2: Q, a3: Q, a4: Q): Matrix Q :=
matrix[[a1,a2],[a3,a4]];
 2) -> 
   Q is not a valid type.
(2) -> Q    
   Compiling body of rule Q to compute value of type Domain 
   Loading /usr/local/axiom/mnt/linux/algebra/INT.o for domain Integer 
   Loading /usr/local/axiom/mnt/linux/algebra/FRAC.o for domain 
      Fraction 
   Loading /usr/local/axiom/mnt/linux/algebra/QUAT.o for domain 
      Quaternion 

 
   >> System error:
   Caught fatal error [memory may be damaged]

(2) -> m(a1: Q, a2: Q, a3: Q, a4: Q): Matrix Q :=
matrix[[a1,a2],[a3,a4]];
 2) -> 
   Q is not a valid type.

> If you want general solving facilities then you actually want m as a
> variable and you need to tell the solver what your solution space is.

The problem, as described to me, was having three matrices A, B and C. 
C is known.  The goal was to choose the elements of one of A or B then
look for equations coming from AB-BA = C.  The elements of A and B are
quaternion.

The person who asked the original question subscribed to the list, so
perhaps they can supply more details.

> > a1 : Variable(Matrix Quaternion Fraction Integer)
> 
> Ask yourself who should take care about the type knowledge that you
> give here. Where would you store that information?

As part of the structure associated with the variable name a1.  Perhaps
I am thinking about Variable incorrectly?

> Yes, that is possible. You know, we have discussed that already. We
> just do not yet have proper code.

Yes.  I was just using it as an illustration because that is the
problem domain where I am most familiar with the issue ;-).  There are
probably other cases besides that one where such logic would be useful.

> The "dimension.as" file that I sent to the list on 29-Aug-2006 is a
> first attempt but not as fully functional as you would like. But
> don't worry, we come to that. However, I think
> that it is not going to work in SPAD.

I'm inclined to agree.  Anyway, that was just an illustration of a more
general question.  Maybe another case would be integration - if you
know you are only dealing with positive integers as opposed to all
integers couldn't you deal with some integrals that you couldn't
otherwise deal with, in cases where the function isn't well behaved in
the negative numbers but is in the positive?

\start
Date: 16 Sep 2006 23:19:46 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: Question concerning types...

Cliff Yapp writes:

> (1) -> Q == Quaternion Fraction Integer;

in Axiom:

Q ==> Quaternion Fraction Integer;

> (2) -> m(a1: Q, a2: Q, a3: Q, a4: Q): Matrix Q := matrix[[a1,a2],[a3,a4]];

in Axiom and in Aldor:

m(a1: Q, a2: Q, a3: Q, a4: Q): Matrix Q == matrix[[a1,a2],[a3,a4]];

\start
Date: 16 Sep 2006 23:29:04 +0200
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Question concerning types...

Cliff Yapp writes:

| --- Ralf Hemmecke wrote:
| 
| > HI Cliff,
| 
| Hey Ralf.
|  
| > MachineInteger is in libaldor what SingleInteger is in Axiom. For a
| > particular element of that type you have exactly 32 bits.
| > Let's appreviate "macro I == MachineInteger;". Now, if you say
| > 
| > m: I;
| > 
| > in the interpreter, the interpreter has to take care of the fact that
| > this m does not have a value, since any of the 32 bits is reserved
| > for holding a true MachineInteger. Now assume you do simply
| > 
| > n: I := m + m;
| > 
| > then n does not have a value. However, there is a relation between m
| > and n. Where do you store that information? Certainly not in
| > MachineInteger.
| 
| Wouldn't that information be associated with the variable n?

but "n"'s type isn't Variable(some type), it is "some type", meaning,
it holds *values* of that type.  But you want it to hold a token of
some type.  That is a different story.  With systems that do
"symbolic" manipulations, you don't get that trouble; with with
systems like Axiom that do actually computations, you have to go
through an additional indirection.

\start
Date: Sat, 16 Sep 2006 14:56:29 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Question concerning types...

> | Wouldn't that information be associated with the variable n?
> 
> but "n"'s type isn't Variable(some type), it is "some type", meaning,
> it holds *values* of that type.

OK.

> But you want it to hold a token of some type.  That is a different
> story.

Surely that isn't a surprising way to want to use a CAS?

I'm actually surprised something like a1 : Integer would be handled any
other way then as a token with type, but again that may just be me not
knowing enough.

> With systems that do "symbolic" manipulations, you don't get that
> trouble; with with systems like Axiom that do actually computations,
> you have to go through an additional indirection.

I'm not sure I'm totally clear on the distinction.  After all, Axiom
can do things like integrate(1/(1+x^4),x) and provide a result - how is
that not a symbolic manipulation?

\start
Date: Sat, 16 Sep 2006 23:59:22 +0200
From: Gregory Vanuxem
To: Cliff Yapp
Subject: Re: Question concerning types...

Le samedi 16 septembre 2006 =E0 13:54 -0700, C Y a =E9crit :

[...]

> (1) -> Q == Quaternion Fraction Integer;
>                                                                  
> Type: Void
> (2) -> m(a1: Q, a2: Q, a3: Q, a4: Q): Matrix Q :=
> matrix[[a1,a2],[a3,a4]];
>  2) ->
>    Q is not a valid type.
> (2) -> Q   
>    Compiling body of rule Q to compute value of type Domain
>    Loading /usr/local/axiom/mnt/linux/algebra/INT.o for domain Integer
>    Loading /usr/local/axiom/mnt/linux/algebra/FRAC.o for domain
>       Fraction
>    Loading /usr/local/axiom/mnt/linux/algebra/QUAT.o for domain
>       Quaternion
>
> 
>    >> System error:
>    Caught fatal error [memory may be damaged]

Humm... And you continue to work with this Axiom session, you're
completely crazy :-) I don't know what can I think about the expression
"Q == Quaternion Fraction Integer". Nevertheless I think you can repo=
rt
this to IssueTracker, I consider this as critical.

\start
Date: Sun, 17 Sep 2006 00:09:11 +0200
From: Gregory Vanuxem
To: list
Subject: [Fwd: Undelivered Mail Returned to Sender] to gmx.de

Sorry for polluting the axiom-developer mailing list, this is the last
time. May be you know why some mails were accepted (1/3). My ISP was
recently bought by orange.fr so I must, may be, use directly their
address.

Don't know, Kai, why it's sometimes accepted.

Greg
-------- Message transf=E9r=E9 --------
De: Mail Delivery System <MAILER-DAEMON@orange.fr>
=C0: Gregory Vanuxem
Sujet: Undelivered Mail Returned to Sender
Date: Sat, 16 Sep 2006 23:38:18 +0200 (CEST)

This is the SMTP Server program at host orange.fr.

I'm sorry to have to inform you that your message could not be
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

			The SMTP Server program

<Kai Kaminski>: host mx0.gmx.net[213.165.64.100] said: 550-5.7.1 {=
mx038}
    The recipient does not accept mails from 'wanadoo.fr' over foreign
    mailservers 550 5.7.1 ( http://www.gmx.net/serverrules ) (in reply to=
 RCPT
    TO command)
pi=E8ce jointe message de courriel, "Undelivered Message"
-------- Message transf=E9r=E9 --------

Hello,

I just wanted to say that my mail sent to axiom-developer was sent to
you too. I do not know why my first mail was rejected by gmx.de. In fact
they even did not speak about blacklisted thing in response to my first
mail. I'm asking if my ISP has some problems actually, for example I
receive mail from axiom-developer in an incorrect order, may be this is
related.

\start
Date: Sun, 17 Sep 2006 01:43:20 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: Question concerning types...

On 09/16/2006 11:19 PM, Martin Rubey wrote:
> Cliff Yapp writes:
> 
>> (1) -> Q == Quaternion Fraction Integer;

Oh, I feared that this would cause trouble...

> in Axiom:
> 
> Q ==> Quaternion Fraction Integer;

Well that should work, but actually I used Aldor syntax. In Axiom you 
would have to write

Q := Quaternion Fraction Integer;

But note then Q is a variable and could change so if you then say

P := Polynomial Q
p1: P := 1
Q := Integer
p2: P := 1

can you assure that p1=p2? Note, the have the same type P which is 
Polynomial Q. Or will p1 become invalid by assigning Integer to Q?

Well, typing that into Axiom will surely reveal the answer, but could 
you say without doing it?

Oh, I just realised some weakness of Axiom...

P := Polynomial

    Although Polynomial is the name of a constructor, a full type must
       be specified in the context you have used it. Issue )show
       Polynomial for more information.

Seems that not everything is first class... :-(

>> (2) -> m(a1: Q, a2: Q, a3: Q, a4: Q): Matrix Q := matrix[[a1,a2],[a3,a4]];

> in Axiom and in Aldor:

> m(a1: Q, a2: Q, a3: Q, a4: Q): Matrix Q == matrix[[a1,a2],[a3,a4]];

Oh yes, thank you Martin, that was a stupid mistake of mine.

\start
Date: 17 Sep 2006 02:03:19 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Question concerning types...

Ralf Hemmecke writes:

[...]

| Seems that not everything is first class... :-(

and airline companies would agree :-)

\start
Date: 17 Sep 2006 02:14:26 +0200
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Question concerning types...

Cliff Yapp writes:

| --- Gabriel Dos Reis wrote:
| 
| > | Wouldn't that information be associated with the variable n?
| > 
| > but "n"'s type isn't Variable(some type), it is "some type", meaning,
| > it holds *values* of that type.
| 
| OK.
| 
| > But you want it to hold a token of some type.  That is a different
| > story.
| 
| Surely that isn't a surprising way to want to use a CAS?

Not really.  You did not say you wanted "n" to be a symbol; you want
it to designate some *value*.

| I'm actually surprised something like a1 : Integer would be handled any
| other way then as a token with type, but again that may just be me not
| knowing enough.

There is a difference between a symbol and an Integer.

What you want, if I understand your manipulation correctly, is to use
symbols, and only later subsitute some values for those symbols.  And
you want to make sure that the symbols are interpreted in some ways.
But, you can't say that directly in the Axiom type system.  Because
Axiom does not attach advanced types to symbols.

| 
| > With systems that do "symbolic" manipulations, you don't get that
| > trouble; with with systems like Axiom that do actually computations,
| > you have to go through an additional indirection.
| 
| I'm not sure I'm totally clear on the distinction.  After all, Axiom
| can do things like integrate(1/(1+x^4),x) and provide a result - how is
| that not a symbolic manipulation?

Yes.  Notice that in that context "x" is interpreted as *symbol*, not
as a value.  Your declaration of "n" said it should be interpreted as
standing for a value, but you did not say which.

\start
Date: Sun, 17 Sep 2006 02:33:19 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Question concerning types...

> The problem, as described to me, was having three matrices A, B and C. 
> C is known.  The goal was to choose the elements of one of A or B then
> look for equations coming from AB-BA = C.  The elements of A and B are
> quaternion.

Maybe you want that... Add the C yourself.
The trick is that you add variables if form of polynomials.

)clear all
R := Fraction Integer
P := Polynomial R
Q := Quaternion P
M := Matrix Q

A1 := quatern(A11, A1i, A1j, A1k)
A2 := quatern(A21, A2i, A2j, A2k)
A3 := quatern(A31, A3i, A3j, A3k)
A4 := quatern(A41, A4i, A4j, A4k)

A: M := matrix [[A1, A2], [A3, A4]]

B1: Q := quatern( 1,  2,  3,  5)
B2: Q := quatern( 7, 11, 13, 17)
B3: Q := quatern(19, 23, 29, 31)
B4: Q := quatern(37, 41, 43, 47)

B: M := matrix [[B1, B2], [B3, B4]]

Z := A*B - B*A

\start
Date: Sat, 16 Sep 2006 20:57:06 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Question concerning types...

> | > But you want it to hold a token of some type.  That is a
> | > different story.
> | 
> | Surely that isn't a surprising way to want to use a CAS?
> 
> Not really.  You did not say you wanted "n" to be a symbol; you want
> it to designate some *value*.

Yes and no.  I want it to be a variable, but a variable of a specific
type.  So rather than just saying x is "something" I say it is "some
integer" or "some float".  I thought I was saying that, but apparently
not - do I understand correctly that what I thought I was saying in
fact cannot be said in Axiom at this time?

> There is a difference between a symbol and an Integer.
> 
> What you want, if I understand your manipulation correctly, is to use
> symbols, and only later subsitute some values for those symbols.

Right.

> And you want to make sure that the symbols are interpreted in some
> ways. But, you can't say that directly in the Axiom type system. 
> Because Axiom does not attach advanced types to symbols.

Is there a reason it does not, or is just something that hasn't been
implemented?
 
> Yes.  Notice that in that context "x" is interpreted as *symbol*, not
> as a value.  Your declaration of "n" said it should be interpreted as
> standing for a value, but you did not say which.

So what I want then, using your terminology, would be a way to declare
a symbol to have a Type.  The reason a1 : MachineInteger produces the
expectation of a value is that Axiom simply doesn't support a symbol
with a Type, and so that assignment carries with it the assumption that
a1 now has some specific value?

Ouch.  There are many cases where one tries to solve a problem to
arrive at a symbolic equation, not a value.  If Axiom makes this
difficult that's going to be a real problem.

As long as I'm asking basic questions, just how would I go about
defining a function f(x) that took the expression produced by
integrating(1/(1+x^4),x) and numerically evaluated it for the given
value of x?  

\start
Date: Sun, 17 Sep 2006 00:30:31 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Question concerning types...

On September 16, 2006 5:59 PM Vanuxem Gr=E9gory wrote:
>
> Le samedi 16 septembre 2006 =E0 13:54 -0700, C Y a =E9crit :
> > ...
> >    >> System error:
> >    Caught fatal error [memory may be damaged]
>
> Humm... And you continue to work with this Axiom session, you're
> completely crazy :-) I don't know what can I think about the
> expression "Q == Quaternion Fraction Integer". Nevertheless I =
think
> you can report this to IssueTracker, I consider this as critical.
>

I agree with Greg, this should be reported as a bug in IssueTracker.

\start
Date: Sun, 17 Sep 2006 01:00:06 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Question concerning types...

On September 16, 2006 12:41 PM C Y wrote:

> ...
>    a1 is declared as being in Quaternion Fraction Integer
>    but has not been given a value.
> (5) -> 
> 
> Why isn't this allowed?  I want a1->a4 to be variables without
> assigned value, and I want to create a symbolic matrix where all
> I know about the entries is their type, in order to do general
> solving operations. How would I set this up correctly in Axiom?
> 

This subject has come up before.

Tim Daly has referred to this sort of thing as "indefinites". See
for example the email messages in this thread deal specifically
with the issue you raise above:

http://lists.nongnu.org/archive/html/axiom-developer/2004-06/msg00212.html

It is also mentioned here:

http://lists.nongnu.org/archive/html/axiom-developer/2004-12/msg00520.html

And here:

http://wiki.axiom-developer.org/84

and

http://lists.nongnu.org/archive/html/axiom-mail/2005-05/msg00037.html

On September 16, 2006 12:51 PM Martin Rubey wrote:
> ...
> Note that you promise axiom that a1 is a Quaternion Fraction Integer.
> However, you don't hold your promise...
> 
> What you want is to make a1 a variable. Currently, there is no
> domain of "Variables, which can take values only in Quaternion
> Fraction Integer".
> 
> In fact, it is (or should be) a FAQ. See MathAction.
> 
> The point of Axioms type system is that any identifier has a 
> typed value. There is no such thing as a identifier that does
> not have a value.
> 

Martin's point is important. This *is* a Frequently Asked Question
about Axiom - particularly by anyone who has used any of the more
"symbolic" and less "computer algebra-oriented" systems such as
Maxima, Maple or Mathematica. There really should be a discussion
of it here:

http://wiki.axiom-developer.org/FAQ

But sense there is not, now would be a good time to at least as
the question. Just click on the link above, read or skip to the
end and "Be Bold" - add a comment that asks the question. Later
someone can add the answer. That is how this wiki FAQ is supposed
to work.

On September 16, 2006 1:19 PM C Y  wrote:

> ...
> Intuitively I would expect Variable to mean simply "an
> unspecified specific instance of a Domain/Type/what have you"
> with ALL domains being possible - just so long as you specify
> the type of the variable, e.g.:
> 
> a1 : Variable(Matrix Quaternion Fraction Integer)
> 

Suppose there was such a domain constructor named Variable(D: domain)
which had the properties you suggest. What operations would you expect
this  domain to export? Would it have the same operations as D? For
example '+'. Given two objects from the domain Variable(Integer),
say 'x' and 'y', what is the type of the result of 'x+y'? Is it
still in Variable(Integer)?

As Tim Daly said in his original replies to me in the email thread
mentioned above, this gets pretty complicated rather quickly.

On September 16, 2006 4:21 PM Gabriel Dos Reis wrote:
> 
> Ralf Hemmecke writes:
> 
> [...]
> | There should be a general domain that handles such things.
> | Something like a typed expression tree which then could be
> | used by the interpreter to figure out what you mean. But to
> | write such a domain, is another story.
> 
> Why Expression(I) could not be made to work with that?
> 

Expression(R: OrderedSet) is a domain constructor that is intended
to implement many of these sort of expression manipulations
where the *coefficients* of the expressions come from domain R.
For example

(1) -> (a1,a2,a3,a4):Expression Quaternion Fraction Integer
       Type: Void
(2) -> m := matrix[[a1,a2],[a3,a4]]

         +a1  a2+
    (2)  |      |
         +a3  a4+
       Type: Matrix Expression Quaternion Fraction Integer

We did not specify any values for a1, a2, a3, a4, but in the
domain 'Expression Quaternion Fraction Integer' we can use
them to form new expressions of the type and use them in other
types.

Unfortunately something very important that should work here:

(3) -> quatern(1/2,1/4,1/8,1/16)::Expression Quaternion Fraction Integer
   Internal Error
   The function coerce with signature hashcode is missing from domain
      Expression(Quaternion (Fraction (Integer)))

doesn't work due to a bug in the current algebra code. :-(
I guess I had better submit this as a bug to IssueTracker...

> More generally, I would like to see support for symbolic
> expressions in Axiom.
>

Do you mean domains such as InputForm? Many purely symbolic
manipulations (in the sense of Lisp S-expressions) can be
performed in this domain (and related Sexpression). Most Axiom
domains have a coercion to InputForm. I think it is unfortunate,
though that the coercion to OutputForm from InputForm actually
displays these expressions as S-expressions, rather than in
Axiom's usual input notation.

> Yesterday, it took me very time lines to code some simple
> symbolic expression  manipulation in Mathematica.  The thing
> in Axiom would have eaten my evening :-(
> 

I think very likely this is mostly a result of very poor or
missing documentation about what is possible in Axiom rather
than a fundamental limitation.

On September 16, 2006 11:57 PM C Y wrote:
> 
> --- Gabriel Dos Reis wrote:
> ... 
> > And you want to make sure that the symbols are interpreted in some
> > ways. But, you can't say that directly in the Axiom type system. 
> > Because Axiom does not attach advanced types to symbols.
> 
> Is there a reason it does not, or is just something that hasn't been
> implemented?
>

I do not think that is correct. If Axiom does not attach types to
symbols, what would you say the following expression means?

(4) -> a1+a2

   (4)  a2 + a1
   Type: Expression Quaternion Fraction Integer

where a1, a2 are defined in (1) above.

> > Yes.  Notice that in that context "x" is interpreted as *symbol*,
> > not as a value.  Your declaration of "n" said it should be
> > interpreted as standing for a value, but you did not say which.
>

No, the situation is more complicated than that as the example (4)
above shows. Note in particular that in (4) a1 and a2 *do not*
have any values (other than the symbol which they implicitly
represent).

When I write:

  a1:Expression Quaternion Fraction Integer

I am saying that a1 is a symbolic expression which includes the
possibility that it be a specific 'Quaternion Fraction Integer' or
some symbol or even some symbolic expression.

This is different than if I wrote:

  a1:Quaternion Fraction Integer

when does not admit that possibility that a1 could be a symbolic
expression.
 
> So what I want then, using your terminology, would be a way to
> declare a symbol to have a Type.  The reason a1 : MachineInteger
> produces the expectation of a value is that Axiom simply doesn't
> support a symbol with a Type, and so that assignment carries with
> it the assumption that a1 now has some specific value?
> 
> Ouch.  There are many cases where one tries to solve a problem to
> arrive at a symbolic equation, not a value.  If Axiom makes this
> difficult that's going to be a real problem.

I do not think that Axiom makes this particularly difficult but it
certainly does things in a way quite different than Mathematica,
Maxima or Maple.

But don't get me wrong. There are some serious limitations on the
ways things of type Expression ... in Axiom can be manipulated when
compared to the 3M's. We have had discussions about this in this
list from time to time over the last few years.

> 
> As long as I'm asking basic questions, just how would I go about
> defining a function f(x) that took the expression produced by
> integrating(1/(1+x^4),x) and numerically evaluated it for the
> given value of x?  
> 

Cliff, why not give Axiom a try sometime instead of just talking
about it? ;)

(1) -> integrate(1/(1+x^4),x)

   (1)
        +-+      +-+    2         +-+        +-+    2
       \|2 log(x\|2  + x  + 1) - \|2 log(- x\|2  + x  + 1)
     +
           +-+         1          +-+         1
       - 2\|2 atan(---------) - 2\|2 atan(---------)
                     +-+                    +-+
                   x\|2  - 1              x\|2  + 1
  /
     8
       Type: Union(Expression Integer,...)
(2) -> subst(%,x=1.1)

   (2)
     0.1767766952 966368811 log(3.7656349186 104045537)
   +
     - 0.1767766952 966368811 log(0.6543650813 895954463)
   +
     - 0.3535533905 932737622 atan(1.7997429004 298623617)
   +
     - 0.3535533905 932737622 atan(0.3912921962 0451024907)
    Type: Expression Float

(3) -> numeric(%)
   Loading c:/Program Files/axiom/mnt/windows/algebra/NUMERIC.o for
      package Numeric

   (3)  - 0.1985595415 9339336209
   Type: Float

\start
Date: 17 Sep 2006 07:12:54 +0200
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Question concerning types...


| --- Gabriel Dos Reis wrote:
| 
| > | > But you want it to hold a token of some type.  That is a
| > | > different story.
| > | 
| > | Surely that isn't a surprising way to want to use a CAS?
| > 
| > Not really.  You did not say you wanted "n" to be a symbol; you want
| > it to designate some *value*.
| 
| Yes and no.  I want it to be a variable, but a variable of a specific
| type. 

You have to distinguish between "variable of specific type" from
"symbol substituable with values of specifc type".  The former
designates values -- i.e. computations are really done -- whereas the
later has to indicate to the compiler or interpreter to "remember" --
i.e. construct suspession -- for the computation.

| So rather than just saying x is "something" I say it is "some
| integer" or "some float".  I thought I was saying that, but apparently
| not - do I understand correctly that what I thought I was saying in
| fact cannot be said in Axiom at this time?

That is my understanding.

| > There is a difference between a symbol and an Integer.
| > 
| > What you want, if I understand your manipulation correctly, is to use
| > symbols, and only later subsitute some values for those symbols.
| 
| Right.
| 
| > And you want to make sure that the symbols are interpreted in some
| > ways. But, you can't say that directly in the Axiom type system. 
| > Because Axiom does not attach advanced types to symbols.
| 
| Is there a reason it does not, or is just something that hasn't been
| implemented?

I don't know whether there is a good reason why it has been
implemented -- I can explain why it does not work the way you want,
but I have not investigated the feasability of the "solution."

| > Yes.  Notice that in that context "x" is interpreted as *symbol*, not
| > as a value.  Your declaration of "n" said it should be interpreted as
| > standing for a value, but you did not say which.
| 
| So what I want then, using your terminology, would be a way to declare
| a symbol to have a Type.  The reason a1 : MachineInteger produces the
| expectation of a value is that Axiom simply doesn't support a symbol
| with a Type, and so that assignment carries with it the assumption that
| a1 now has some specific value?

a1 : MachineInteger tells Axiom that somewhere down a1 will designate
an object allocated to hold value of type MachineInteger.  There is 
the domain constructor Expression which you could try to use.
However, I seem to remember Ralf telling people that they should never
ever enter EXPR T in Axiom; so without knowing what you do futher with
your matrix I can't say the EXPR domain constructor is a good way to go;
you have to try.

Going back to your original example, here is what I have:


(3) -> a1 : EXPR Quaternion Fraction Integer
                                                                   Type: Void
(4) -> a2 : EXPR Quaternion Fraction Integer
                                                                   Type: Void
(5) -> a3 : EXPR Quaternion Fraction Integer
                                                                   Type: Void
(6) -> a4 : EXPR Quaternion Fraction Integer
                                                                   Type: Void
(7) -> m := matrix[[a1,a2], [a3, a4]]       
   Loading /usr/local/axiom/mnt/linux/algebra/MATRIX.o for domain 
      Matrix 
   Loading /usr/local/axiom/mnt/linux/algebra/VECTOR.o for domain 
      Vector 
   Loading /usr/local/axiom/mnt/linux/algebra/IIARRAY2.o for domain 
      InnerIndexedTwoDimensionalArray 
   Loading /usr/local/axiom/mnt/linux/algebra/MATCAT-.o for domain 
      MatrixCategory& 

   Loading /usr/local/axiom/mnt/linux/algebra/ARR2CAT-.o for domain 
      TwoDimensionalArrayCategory& 
   Loading /usr/local/axiom/mnt/linux/algebra/UDPO.o for package 
      UserDefinedPartialOrdering 
   Loading /usr/local/axiom/mnt/linux/algebra/SUP2.o for package 
      SparseUnivariatePolynomialFunctions2 
   Loading /usr/local/axiom/mnt/linux/algebra/UPOLYC2.o for package 
      UnivariatePolynomialCategoryFunctions2 
        +a1  a2+
   (7)  |      |
        +a3  a4+
                          Type: Matrix Expression Quaternion Fraction Integer



HTH.

| Ouch.  There are many cases where one tries to solve a problem to
| arrive at a symbolic equation, not a value.

Yes.

| If Axiom makes this difficult that's going to be a real problem.

I thought that was supposed to be the _strenght_ of Axiom :-/
(see related recent discussion with Bill on this list)

| As long as I'm asking basic questions, just how would I go about
| defining a function f(x) that took the expression produced by
| integrating(1/(1+x^4),x) and numerically evaluated it for the given
| value of x?  

eval()

\start
Date: 17 Sep 2006 07:17:57 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Question concerning types...

Bill Page writes:


[...]

| > Intuitively I would expect Variable to mean simply "an
| > unspecified specific instance of a Domain/Type/what have you"
| > with ALL domains being possible - just so long as you specify
| > the type of the variable, e.g.:
| > 
| > a1 : Variable(Matrix Quaternion Fraction Integer)
| > 
| 
| Suppose there was such a domain constructor named Variable(D: domain)
| which had the properties you suggest. What operations would you expect
| this  domain to export? Would it have the same operations as D? For
| example '+'. Given two objects from the domain Variable(Integer),
| say 'x' and 'y', what is the type of the result of 'x+y'? Is it
| still in Variable(Integer)?

FreeMonoid Variable Integer

\start
Date: Sat, 16 Sep 2006 23:51:52 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Question concerning types...

Thanks Bill and Gaby for very informative replys.  Since I started this
I'll add it to the FAQ ;-).

Thanks for the subst pointer Bill :-).  Sometimes the obvious just
won't come :-/.  

\start
Date: Sun, 17 Sep 2006 09:28:34 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Question concerning types...

> | > Intuitively I would expect Variable to mean simply "an
> | > unspecified specific instance of a Domain/Type/what have you"
> | > with ALL domains being possible - just so long as you specify
> | > the type of the variable, e.g.:
> | > 
> | > a1 : Variable(Matrix Quaternion Fraction Integer)
> | > 
> | 
> | Suppose there was such a domain constructor named Variable(D: domain)
> | which had the properties you suggest. What operations would you expect
> | this  domain to export? Would it have the same operations as D? For
> | example '+'. Given two objects from the domain Variable(Integer),
> | say 'x' and 'y', what is the type of the result of 'x+y'? Is it
> | still in Variable(Integer)?
> 
> FreeMonoid Variable Integer

Gaby, do you really believe that? But in order to say x+y you have to
have the type of Variable(D: domain) in the first place. So let's
suppose you simply say (Aldor-speak: PrimitiveType exports just equality)

Variable(D: PrimitiveType): PrimitiveType == add {
   Rep == ...
   (x: %) = (y: %): Boolean == ...
}

So you actually say that Variable is rather thumb. But first you have to
create x and y. So you would say

x: Variable(Integer) := "x"  -- give the name of the symbol
y: Variable(Integer) := "y"

There are already two issues here.

1)
When you just say
x: Variable(Integer)
without the assignment, you just declare an (Aldor/Axiom) identifier, no
value yet. If ever you are going to compute with x it has to have a
value. Now actually the domain Symbol does exactly that. However the lines

(1) -> (a1,a2,a3,a4):Expression Quaternion Fraction Integer
        Type: Void
(2) -> m := matrix[[a1,a2],[a3,a4]]

          +a1  a2+
     (2)  |      |
          +a3  a4+
        Type: Matrix Expression Quaternion Fraction Integer

given by Bill suggest that the Axiom interpreter is a bit more relaxed.
It actually interprets a1 as both, an Axiom identifier and as a variable 
of the domain Expression Quaternion Fraction Integer.

Try

b: Expression Quaternion Fraction Integer := B
B

in Axiom.


2)
Now Gaby said that x+y should have type FreeMonoid Variable Integer. Why 
not FreeGroup? I guess the interpreter has to do a lot of work to find 
the right interpretation for such a + and it must decide for one of 
possibly many choices. But assume I say x+z for
z: Variable(Float) := "z"
what is the type of that? Should the interpreter forbid such an 
addition? In the compiler I clearly don't want any guessing and not 
automatic conversion. Note that I prefer that (most of) the things that 
are possible in the interpreter could be compiled into stand alone programs.
Anyway, if the type tower is always expanded like that  you end up
with the fact that
(x+y)*x and x*x + x*y
have types
FreeMultiplicativeSemigroup FreeAdditiveSemigroup Variable Integer
and
FreeAdditiveSemigroup FreeMultiplicativeSemigroup Variable Integer
and thus are not equal.

And what would be the type of foo?(x,y)? Maybe I have extended Integer 
to contain a function foo: (%, %) -> Boolean. Variable(Integer) does 
however not export anything about its argument. So who is going to find 
out that such a foo exists?

\start
Date: 17 Sep 2006 09:44:05 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: Question concerning types...

Gabriel Dos Reis writes:

> However, I seem to remember Ralf telling people that they should never
> ever enter EXPR T in Axiom; so without knowing what you do futher with
> your matrix I can't say the EXPR domain constructor is a good way to go;
> you have to try.

I think that one has to be more careful before judging EXPR that way. I'd
rather say: try to avoid EXPR as much as you can, but there are things which
cannot be handled without.

EXPR QUAT FRAC INT would be the domain of expressions, with coefficients (i.e.,
all "numbers" that appear) being from QUAT FRAC INT.

Internally (and that might be good for understanding), the elements are stored
as fractions of multivariate polynomials with coefficients being QUAT FRAC INT
and symbols being "kernels", i.e., things that cannot be evaluated further.

Cliff, maybe you would be happy with the domain

POLY QUAT FRAC INT?

this one is "safer" - doesn't provide as much functionality though.

by the way, maybe it wasn't explained that way yet:

a: INT,; b: INT; a+b

+ is an operation in INT. it takes its arguments and applies the '+' function
from Lisp. The point is: +$INT was promised that the arguments it gets are
INTs. It's the design of axiom that every operation knows what types its
arguments have. They don't have to check anymore. That's why axiom is fast.

Go to a common lisp and say

(+ a b)

\start
Date: Sun, 17 Sep 2006 09:42:15 -0400
From: Tim Daly
To: list
Subject: skype conference

Reminder: axiom skype phone conference
When: Monday Sept 18, 1pm EST

If you want to participate in the conference
send you skype id to Tim Daly.

The way skype is organized only one person can
host a conference and he has to 'invite' people.

\start
Date: 17 Sep 2006 16:25:26 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Question concerning types...

Ralf Hemmecke writes:

| > | > Intuitively I would expect Variable to mean simply "an
| > | > unspecified specific instance of a Domain/Type/what have you"
| > | > with ALL domains being possible - just so long as you specify
| > | > the type of the variable, e.g.:
| > | > | > a1 : Variable(Matrix Quaternion Fraction Integer)
| > | > | | Suppose there was such a domain constructor named
| > Variable(D: domain)
| > | which had the properties you suggest. What operations would you expect
| > | this  domain to export? Would it have the same operations as D? For
| > | example '+'. Given two objects from the domain Variable(Integer),
| > | say 'x' and 'y', what is the type of the result of 'x+y'? Is it
| > | still in Variable(Integer)?
| > FreeMonoid Variable Integer
| 
| Gaby, do you really believe that? But in order to say x+y you have to
| have the type of Variable(D: domain) in the first place.

yes.  My working assumption is that if we had Variable(D: domain) to
mean anything, it would be such that operations of D would be *lifted*
to Variable(D: domain) and would work as if we had an algebra (in the
Universal Algebra sense).  In this case "+" would be lifted to
Variable Integer, so that x + y can be interpreted as an element a a
free monoid generated symbols.  That is not rocket science.

[...]

| (1) -> (a1,a2,a3,a4):Expression Quaternion Fraction Integer
|         Type: Void
| (2) -> m := matrix[[a1,a2],[a3,a4]]
| 
|           +a1  a2+
|      (2)  |      |
|           +a3  a4+
|         Type: Matrix Expression Quaternion Fraction Integer
| 
| given by Bill suggest that the Axiom interpreter is a bit more relaxed.

Funny enough, I tried similar thing and sent a message before seeing
Bill's.  That is a natural thing to do if you have a Universal Algebra
backgroud -- e.g. you're used to the 3M's.

[...]

| 2)
| Now Gaby said that x+y should have type FreeMonoid Variable
| Integer. Why not FreeGroup?

I picked FreeMonoid because that is the least assumption with "+" from
Integer.  But I'm OK to have the interpereter go directly to FreeGroup
-- that would be even more consistent with my earlier suggestion of
lifting operations to Variable D.

| I guess the interpreter has to do a lot of
| work to find the right interpretation for such a + and it must decide
| for one of possibly many choices.

If "+" is defined as beeing an associative operation , there would not
be much work to do.  In fact I don't want the interpret to become
super smart.  Just lift operations.

| But assume I say x+z for
| z: Variable(Float) := "z"
| what is the type of that? 

It is the type of its declaration: Variable(Float).

| Should the interpreter forbid such an
| addition?

there is no addition as far as I can see.

| In the compiler I clearly don't want any guessing and not
| automatic conversion. Note that I prefer that (most of) the things
| that are possible in the interpreter could be compiled into stand
| alone programs.
| Anyway, if the type tower is always expanded like that  you end up
| with the fact that
| (x+y)*x and x*x + x*y
| have types
| FreeMultiplicativeSemigroup FreeAdditiveSemigroup Variable Integer
| and
| FreeAdditiveSemigroup FreeMultiplicativeSemigroup Variable Integer
| and thus are not equal.

I don't see why.

| And what would be the type of foo?(x,y)? Maybe I have extended Integer
| to contain a function foo: (%, %) -> Boolean. 

Yes, what is the resulting Algrbraci structrure?

| Variable(Integer) does
| however not export anything about its argument.

it does not have to.

| So who is going to find out that such a foo exists?

The process would be that of lifting operations from D to Variable(D).
Notice, this isn't a problem for programming languages.  Think about
it from Universal Algebra perspective.

\start
Date: Sun, 17 Sep 2006 12:41:14 -0500 (CDT)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

On Fri, 15 Sep 2006, Camm Maguire wrote:

| Greetings!
|
| Can we finalize this stat bit please?  I'm trying to get 2.6.8 out

Hi Camm,

  currently 'make install' fails for GCL-2.6.8 if the utility
makeinfo is missing.  I think the installation should be allowed to
complete -- the documentation will just be missing, but that is OK
for many uses.

\start
Date: Sun, 17 Sep 2006 19:58:52 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Question concerning types...
Cc: William Sit

On 09/17/2006 04:25 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> | > | > Intuitively I would expect Variable to mean simply "an
> | > | > unspecified specific instance of a Domain/Type/what have you"
> | > | > with ALL domains being possible - just so long as you specify
> | > | > the type of the variable, e.g.:
> | > | > | > a1 : Variable(Matrix Quaternion Fraction Integer)
> | > | > | | Suppose there was such a domain constructor named
> | > Variable(D: domain)
> | > | which had the properties you suggest. What operations would you expect
> | > | this  domain to export? Would it have the same operations as D? For
> | > | example '+'. Given two objects from the domain Variable(Integer),
> | > | say 'x' and 'y', what is the type of the result of 'x+y'? Is it
> | > | still in Variable(Integer)?
> | > FreeMonoid Variable Integer
> | 
> | Gaby, do you really believe that? But in order to say x+y you have to
> | have the type of Variable(D: domain) in the first place.
> 
> yes.  My working assumption is that if we had Variable(D: domain) to
> mean anything, it would be such that operations of D would be *lifted*
> to Variable(D: domain) and would work as if we had an algebra (in the
> Universal Algebra sense).  In this case "+" would be lifted to
> Variable Integer, so that x + y can be interpreted as an element a a
> free monoid generated symbols.  That is not rocket science.

I agree with you that if D had type T then Variable(D) should have type 
T (plus maybe some exports that allow to create "indeterminates").

Looking at it mathematically (and simplified) then all we do is that we 
take a universal algebra D = (A, F) where A is the carrier set and F are 
the functions on it. Variable(D) is maybe a bad name, but all we do is 
that Variable(D) = (A', F') is a universal algebra where A' is the union 
of the set A, a set X of indeterminates, and all things that can be 
generated from A and X by applying functions from F'. F and F' behave 
identically on A.

Mathematically, that's not a big deal. But Aldor domains are actually 
multi-sorted algebras. That makes the situation a little more complicated.

So I still disagree with you that x+y should be of type 
FreeMonoid(Variable(Integer)). From what I said above, it seems more 
natural to me that its type is Variable(Integer) (well, it's a bad name, 
maybe Indefinite(Integer) would be better).

Anyway, what we want is a nice way of adding elements and more or less 
keeping the type of the domain. And that is not possible if you just 
define "Indefinite" having one argument D. One must know the type of D 
(a category) so that the return type would be clear.

Indefinite(C: Catagory)(D: C): C == add {
     Rep == Union(d: D, ???)
     ...
}

The ??? should be something that allows arbitrary expressions formed 
from D, the functions in C and some indeterminates X. (I have no idea 
how that would look like. Maybe just delayed evaluation of function 
composition.)

> [...]
> 
> | (1) -> (a1,a2,a3,a4):Expression Quaternion Fraction Integer
> |         Type: Void
> | (2) -> m := matrix[[a1,a2],[a3,a4]]
> | 
> |           +a1  a2+
> |      (2)  |      |
> |           +a3  a4+
> |         Type: Matrix Expression Quaternion Fraction Integer
> | 
> | given by Bill suggest that the Axiom interpreter is a bit more relaxed.
> 
> Funny enough, I tried similar thing and sent a message before seeing
> Bill's.  That is a natural thing to do if you have a Universal Algebra
> backgroud -- e.g. you're used to the 3M's.

Maybe. I don't say that shouldn't be allowed in the interpreter, but the 
compiler would generate a matrix of 4 uninitialized entries. Now what 
happens if you print m(1,1)? If that prints something reasonable then it 
tells me that the compiler knows about a special domain constructor, 
namely Expression. Drop "Expression" from above, what would be on screen 
for "stdout << m(1,1)"? The interpreter can add smart things. I am 
asking for the compiler.

[...]

> | I guess the interpreter has to do a lot of
> | work to find the right interpretation for such a + and it must decide
> | for one of possibly many choices.
> 
> If "+" is defined as beeing an associative operation , there would not
> be much work to do. 

Oh, who said that + is associative? The documentation, right? But that 
is not a nice thing to take into account for the compiler. It would be 
much better if Aldor allowed to state associativity in a formal manner.

> In fact I don't want the interpret to become
> super smart.  Just lift operations.

I am completely with you. The interpreter should not have any 
mathematical knowledge, just look into a database (basically the Axiom 
libraries) and figure out what could be done. It should be possible to 
change the libraries and work with the same interpreter.

> | But assume I say x+z for
> | z: Variable(Float) := "z"
> | what is the type of that? 
> 
> It is the type of its declaration: Variable(Float).

Oh, I meant the type of "x+z".

> | Should the interpreter forbid such an
> | addition?

> there is no addition as far as I can see.

But there was also no addition until you transformed Variable(Integer) 
into FreeMonoid Variable Integer.

> | In the compiler I clearly don't want any guessing and not
> | automatic conversion. Note that I prefer that (most of) the things
> | that are possible in the interpreter could be compiled into stand
> | alone programs.
> | Anyway, if the type tower is always expanded like that  you end up
> | with the fact that
> | (x+y)*x and x*x + x*y
> | have types
> | FreeMultiplicativeSemigroup FreeAdditiveSemigroup Variable Integer
> | and
> | FreeAdditiveSemigroup FreeMultiplicativeSemigroup Variable Integer
> | and thus are not equal.
> 
> I don't see why.

OK, let's turn this into a mathematical example.

A := Fraction Complex Integer; a: A := 1
B := Complex Fraction Integer; b: B := 1

Clearly A and be are isomorphic as fields, but they are NOT identical.
Not identical in Axiom and not identical in mathematics.

Note, we had a discussion whether "Fraction Fraction Integer" should be 
implemented to be the same as "Fraction Integer". Although I had even 
given code to do that, I believe it should not be implemented that way. 
Because an element that looks like (2/1)/(3/1) is NOT identical to 2/3. 
(Just consider fractions as equivalence classes of pairs of some type.

\start
Date: Sun, 17 Sep 2006 11:44:59 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Papers on Indefinites

Clearly I have some homework to do on this topic, and it's important
enough that I want to be sure I have the correct sources.  Looking over
the archive links Bill provided (thanks Bill!) it looks like papers by
Davenport and Fateman are recommended reading.  Are these the specific
papers in question?

James H. Davenport and Christ`ele Faure. The "unknown" in computer
algebra. Programmirovanie, 1(1), 1994.
http://lists.nongnu.org/archive/html/axiom-developer/2004-06/dviwYbMdboRdU.dvi

R. Fateman. Manipulation of matrices symbolically.
http://http.cs.berkeley.edu/~fateman/papers/symmat2.pdf

Not sure about this one:
Abstract matrices in symbolic computation
http://portal.acm.org/ft_gateway.cfm?id=1145820&type=pdf&coll=GUIDE&dl=&CFID=15151515&CFTOKEN=6184618#search=%22Fateman%20matrices%22

I didn't initially appreciate how important (even vital) this topic was
to Axiom.  It looks like this issue will be essential for eventual
support of some very common uses of computer algebra.

Tim, I'm not spotting it in the archives yet - did you ever find the
box with the provisos work in it?


Other links in the archives (I'm sure not comprehensive):

http://lists.nongnu.org/archive/html/axiom-math/2005-05/msg00000.html

I take it this is the NSF grant?  Papers from this effort will be
interesting:
Formal and Mathematical Foundations Grant , Parametric Computation in
Axiom: Towards Indefinite Symbolic Computing, co-PI (NSF 2004 - 2006)
http://www-cs.ccny.cuny.edu/~dtroeger/personal/troeger.html

http://lists.nongnu.org/archive/html/axiom-developer/2006-07/msg00144.html

http://lists.nongnu.org/archive/html/axiom-developer/2006-07/msg00201.html

\start
Date: 17 Sep 2006 21:18:59 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Question concerning types...
Cc: William Sit

Ralf Hemmecke writes:

[...]

| Looking at it mathematically (and simplified) then all we do is that
| we take a universal algebra D = (A, F) where A is the carrier set and
| F are the functions on it. Variable(D) is maybe a bad name, but all we
| do is that Variable(D) = (A', F') is a universal algebra where A' is
| the union of the set A, a set X of indeterminates, and all things that
| can be generated from A and X by applying functions from F'. F and F'
| behave identically on A.

yes.

| Mathematically, that's not a big deal. But Aldor domains are actually
| multi-sorted algebras. That makes the situation a little more
| complicated.

but not impossible.

In this discussion, I'm going to ignore Aldor for a moment and
concentrate on SPAD because I don't have access to Aldor source code
and anything that might transpire out of this discoussion should 
probably be recorded as a feature-request for SPAD with all the
"insights" we might have gained.

| So I still disagree with you that x+y should be of type
| FreeMonoid(Variable(Integer)). From what I said above, it seems more
| natural to me that its type is Variable(Integer) (well, it's a bad
| name, maybe Indefinite(Integer) would be better).

I don't think it should be Variable(Integer).  For me,
Variable(Integer) means a symbol who interpretation is of type
Integer.  I don't like Indefinite(Integer) neither.  So, it might very
well be that we're back to our old beloved friend Expression(Integer).

| Anyway, what we want is a nice way of adding elements and more or less
| keeping the type of the domain.

yes.

| And that is not possible if you just define "Indefinite" having one
| argument D. 

I'm clear why not.  Could you explain this a bit further?

| One must know the type of D 
| (a category) so that the return type would be clear.
| 
| Indefinite(C: Catagory)(D: C): C == add {
|      Rep == Union(d: D, ???)
|      ...
| }
| 
| The ??? should be something that allows arbitrary expressions formed
| from D, the functions in C and some indeterminates X. (I have no idea
| how that would look like. Maybe just delayed evaluation of function
| composition.)

I suspect I'm being dense here.  What would be wrong with Expression D?

| > [...]
| > | (1) -> (a1,a2,a3,a4):Expression Quaternion Fraction Integer
| > |         Type: Void
| > | (2) -> m := matrix[[a1,a2],[a3,a4]]
| > | |           +a1  a2+
| > |      (2)  |      |
| > |           +a3  a4+
| > |         Type: Matrix Expression Quaternion Fraction Integer
| > | | given by Bill suggest that the Axiom interpreter is a bit more
| > relaxed.
| > Funny enough, I tried similar thing and sent a message before seeing
| > Bill's.  That is a natural thing to do if you have a Universal Algebra
| > backgroud -- e.g. you're used to the 3M's.
| 
| Maybe. I don't say that shouldn't be allowed in the interpreter, but
| the compiler would generate a matrix of 4 uninitialized entries. Now
| what happens if you print m(1,1)?

If that entry is a Variable? I would expect the output to indicate
either the name or just m(1,1).  Look at what Axiom prints when you
say

    m * m

That matches my expectation.

| If that prints something reasonable
| then it tells me that the compiler knows about a special domain
| constructor, namely Expression.

yes.

|  Drop "Expression" from above, what
| would be on screen for "stdout << m(1,1)"? 

well, it Expression is dropped then we're back to the interpretation
we all agree on: A value of type Quaternion Fraction Integer.
Consequently m(1,1) must hold value of that type.

| The interpreter can add
| smart things. I am asking for the compiler.
| 
| [...]
| 
| > | I guess the interpreter has to do a lot of
| > | work to find the right interpretation for such a + and it must decide
| > | for one of possibly many choices.
| > If "+" is defined as beeing an associative operation , there would
| > not
| > be much work to do.
| 
| Oh, who said that + is associative? The documentation, right? 

And

yes, but in my model much of the documentation is moved to code.  In
this case, I would like to see properties() used to attach
mathematical properties.  

| But that
| is not a nice thing to take into account for the compiler.

Why?  

>From my point of view, the type of an operation is just as important
as its algebraic properties.

| It would be
| much better if Aldor allowed to state associativity in a formal manner.

SPAD does.  See properties()

| > In fact I don't want the interpret to become
| > super smart.  Just lift operations.
| 
| I am completely with you. The interpreter should not have any
| mathematical knowledge, just look into a database (basically the Axiom
| libraries) and figure out what could be done. It should be possible to
| change the libraries and work with the same interpreter.

yes.

| > | But assume I say x+z for
| > | z: Variable(Float) := "z"
| > | what is the type of that? It is the type of its declaration:
| > Variable(Float).
| 
| Oh, I meant the type of "x+z".
| 
| > | Should the interpreter forbid such an
| > | addition?
| 
| > there is no addition as far as I can see.
| 
| But there was also no addition until you transformed Variable(Integer)
| into FreeMonoid Variable Integer.

I did not transform a variable to FreeMonoid Variable Integer.
However, I did suggest that type  for th _compound expression_ "x+y"
when the question was asked.

| > | In the compiler I clearly don't want any guessing and not
| > | automatic conversion. Note that I prefer that (most of) the things
| > | that are possible in the interpreter could be compiled into stand
| > | alone programs.
| > | Anyway, if the type tower is always expanded like that  you end up
| > | with the fact that
| > | (x+y)*x and x*x + x*y
| > | have types
| > | FreeMultiplicativeSemigroup FreeAdditiveSemigroup Variable Integer
| > | and
| > | FreeAdditiveSemigroup FreeMultiplicativeSemigroup Variable Integer
| > | and thus are not equal.
| > I don't see why.
| 
| OK, let's turn this into a mathematical example.
| 
| A := Fraction Complex Integer; a: A := 1
| B := Complex Fraction Integer; b: B := 1
| 
| Clearly A and be are isomorphic as fields, but they are NOT identical.

As syntactic obejcts, no, they are not.  The issue can be rephrased as
whether they should remain non-equal in other non-syntactical
intepretation.   I think no.

| Not identical in Axiom and not identical in mathematics.

You have lost me on the last part.  My book says that both A and B are
the same mathematical object.  Why do you believe they are not?

| Note, we had a discussion whether "Fraction Fraction Integer" should
| be implemented to be the same as "Fraction Integer".

Under the mathematical interpretation they are the same.  I believe
they should also be the same in Axiom -- at least if you take
dependent types seriously.

| Although I had
| even given code to do that, I believe it should not be implemented
| that way. Because an element that looks like (2/1)/(3/1) is NOT
| identical to 2/3.

By the same token we should prevent Axiom from simplifying 3+2 to 5.

| (Just consider fractions as equivalence classes of
| pairs of some type.

I don't follow.

\start
Date: Sun, 17 Sep 2006 15:28:42 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Papers on Indefinites

Cliff,

On September 17, 2006 2:45 PM you wrote:
> 
> Clearly I have some homework to do on this topic, and it's
> important enough that I want to be sure I have the correct
> sources. Looking over the archive links Bill provided (thanks Bill!)
> it looks like papers by Davenport and Fateman are recommended reading.
> Are these the specific papers in question?
> ...

Yes, they are relevant but not central to the issue that you raised.
In fact the concept of "indefinities" was coined by Tim Daly. After
reading about the idea, I do not think that this formulation of the
issue (which is essentially based on proof theory and logic) is the
right approach for Axiom. Really I would prefer a more "algebraic"
approach. I think the paper by Steven Watt referred to in the
following thread:

http://lists.nongnu.org/archive/html/axiom-developer/2006-08/msg00525.html

Making Computer Algebra More Symbolic (Invited), Stephen M. Watt,
pp. 43-49, Proc. Transgressive Computing 2006: A conference
in honor or Jean Della Dora , (TC 2006), April 24-26 2006,
Granada Spain.

http://www.csd.uwo.ca/~watt/pub/reprints/2006-tc-sympoly.pdf

is a very important contribution. What he is describing here is
directly related to the implementation of the Expression domain
constructor in Axiom.
 
\start
Date: Sun, 17 Sep 2006 15:44:44 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Question concerning types...
Cc: William Sit

On September 17, 2006 1:59 PM Ralf Hemmecke wrote:
> ...
> Gaby wrote:
> > 
> > yes.  My working assumption is that if we had Variable(D: domain)
> > to mean anything, it would be such that operations of D would 
> > be *lifted* to Variable(D: domain) and would work as if we had an 
> > algebra (in the Universal Algebra sense).  In this case "+" would
> > be lifted to Variable Integer, so that x + y can be interpreted as
> > an element of a free monoid generated symbols.  That is not rocket
> > science.

No. The question is: Is it computer science? ;) I am glad that you
appear to think so.

> 
> I agree with you that if D had type T then Variable(D) should 
> have type T (plus maybe some exports that allow to create
> "indeterminates").

The meaning of this statement is unclear to me. Do you mean:
If D has category T then Variable(D) should have category T?
If so, I would disagree. Variable(D), as a universal algebra
over some symbols must have a different (but related) type,
perhaps Variable(D) has Universal(T)?

> 
> Looking at it mathematically (and simplified) then all we do 
> is that we take a universal algebra D = (A, F) where A is the
> carrier set and F are the functions on it. Variable(D) is maybe
> a bad name, but all we do is that Variable(D) = (A', F') is a
> universal algebra where A' is the union of the set A, a set X 
> of indeterminates, and all things that can be generated from A
> and X by applying functions from F'. F and F' behave identically
> on A.
> 
> Mathematically, that's not a big deal. But Aldor domains are
> actually multi-sorted algebras. That makes the situation a little
> more complicated.
>

I think sometimes you think too much about Aldor and not enough
about Axiom... ;)
 
> So I still disagree with you that x+y should be of type 
> FreeMonoid(Variable(Integer)). From what I said above, it seems
> more natural to me that its type is Variable(Integer) (well,
> it's a bad name, maybe Indefinite(Integer) would be better).
> 

The interesting thing to me is that all you appear to be doing here
is "re-inventing" the Expression domain constructor.

It seems to me that 'Expression(Integer)' is a good enough name. :-)


> Anyway, what we want is a nice way of adding elements and more or
> less keeping the type of the domain. And that is not possible if
> you just define "Indefinite" having one argument D. One must know
> the type of D (a category) so that the return type would be clear.
> 
> Indefinite(C: Catagory)(D: C): C == add {
>      Rep == Union(d: D, ???)
>      ...
> }
> 
> The ??? should be something that allows arbitrary expressions formed 
> from D, the functions in C and some indeterminates X. (I have no idea 
> how that would look like. Maybe just delayed evaluation of function 
> composition.)

I strongly recommend that you take a close look at how Expression is
implemented in the Axiom library.

> 
> > [...]
> > 
> > | (1) -> (a1,a2,a3,a4):Expression Quaternion Fraction Integer
> > |         Type: Void
> > | (2) -> m := matrix[[a1,a2],[a3,a4]]
> > | 
> > |           +a1  a2+
> > |      (2)  |      |
> > |           +a3  a4+
> > |         Type: Matrix Expression Quaternion Fraction Integer
> > | 
> > | given by Bill suggest that the Axiom interpreter is a bit
> > | more relaxed.
> >

The key thing to recall is something Martin wrote earlier.

On September 17, 2006 3:44 AM Martin Rubey wrote:
> 
> Gabriel Dos Reis writes:
> 
> > However, I seem to remember Ralf telling people that they 
> > should never ever enter EXPR T in Axiom; so without knowing
> > what you do futher with your matrix I can't say the EXPR domain
> > constructor is a good way to go; you have to try.
> 
> I think that one has to be more careful before judging EXPR 
> that way. I'd rather say: try to avoid EXPR as much as you can,
> but there are things which cannot be handled without.

I think the only reason to "avoid" Expression is because in some
sense it represents a less powerful and less generalizable approach
to computer algebra.

> 
> EXPR QUAT FRAC INT would be the domain of expressions, with 
> coefficients (i.e., all "numbers" that appear) being from
> QUAT FRAC INT.
> 
> Internally (and that might be good for understanding), the 
> elements are stored as fractions of multivariate polynomials
> with coefficients being QUAT FRAC INT and symbols being "kernels",
> i.e., things that cannot be evaluated further.
> 
> Cliff, maybe you would be happy with the domain
> 
> POLY QUAT FRAC INT?
> 
> this one is "safer" - doesn't provide as much functionality though.
> ... 

As Martin says, Expression is really implemented internally in
Axiom as 'Fraction MultivariatePolynomial' where the polynomial
symbols include first of all, all symbols (such as the symbols
a1, a2, a3, a4) plus a large number of other expressions, e.g.
'sin(a1)' which are not evaluated any further in the Expression
domain.
 
> > Funny enough, I tried similar thing and sent a message before
> > seeing Bill's.  That is a natural thing to do if you have a
> > Universal Algebra background -- e.g. you're used to the 3M's.

Actually the suggestion that the 3M's have anything to do with
Universal Algebra kind of made me "gag" ;) Seriously, I doubt the
implied connection. But it is true that Axiom's Expression domain
constructed was designed specifically to address the type of
"symbolic" calculations often done in these other packages.

> 
> Maybe. I don't say that shouldn't be allowed in the interpreter,
> but the compiler would generate a matrix of 4 uninitialized entries.

No that is not true. In the domain Expression the symbol 'a1'
simply stands for itself. It is not "uninitialized'.

> Now what happens if you print m(1,1)? If that prints something 
> reasonable then it tells me that the compiler knows about a special
> domain constructor, namely Expression.

Yes.

> Drop "Expression" from above, what would be on screen for "stdout
> << m(1,1)"? The interpreter can add smart things. I am asking for
> the compiler.
> 

I don't understand. Obviously Expression is a domain that the SPAD
compiler understands. Implementing Expression in Aldor should be
quite straight forward.

\start
Date: 17 Sep 2006 22:38:25 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Papers on Indefinites

Bill Page writes:

[...]

|           I think the paper by Steven Watt referred to in the
| following thread:
| 
| http://lists.nongnu.org/archive/html/axiom-developer/2006-08/msg00525.html
| 
| Making Computer Algebra More Symbolic (Invited), Stephen M. Watt,
| pp. 43-49, Proc. Transgressive Computing 2006: A conference
| in honor or Jean Della Dora , (TC 2006), April 24-26 2006,
| Granada Spain.
| 
| http://www.csd.uwo.ca/~watt/pub/reprints/2006-tc-sympoly.pdf
| 
| is a very important contribution. What he is describing here is
| directly related to the implementation of the Expression domain
| constructor in Axiom.

As I said earlier, think of it as use of types programming languages. 

\start
Date: 17 Sep 2006 22:46:00 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Question concerning types...
Cc: William Sit

Bill Page writes:

[...]

| > > Funny enough, I tried similar thing and sent a message before
| > > seeing Bill's.  That is a natural thing to do if you have a
| > > Universal Algebra background -- e.g. you're used to the 3M's.
| 
| Actually the suggestion that the 3M's have anything to do with
| Universal Algebra kind of made me "gag" ;) 

Why?

| Seriously, I doubt the implied connection.

I don't follow.  Could you elavorate?

\start
Date: Sun, 17 Sep 2006 16:09:37 -0500 (CDT)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger

  Following up on my earlier message, is it OK to apply this to
gcl-2.6.8pre CVS?  I'm using it in the GCL version present in Axiom
build-improvement branch.

Thanks!

-- Gaby

Index: ChangeLog
===================================================================
RCS file: /sources/gcl/gcl/ChangeLog,v
retrieving revision 1.14
diff -p -r1.14 ChangeLog
*** ChangeLog	3 Feb 2002 18:44:06 -0000	1.14
--- ChangeLog	17 Sep 2006 21:06:01 -0000
***************
*** 1,3 ****
--- 1,8 ----
+ 2006-09-17  Gabriel Dos Reis  Gabriel Dos Reis
+
+ 	* makefile (install1): Gracefully handle build of info files.
+ 	* info/makefile: Likewise.
+
  2002-01-25  Camm Maguire  <camm@intech19.enhanced.com>

  	* /cvsroot/gcl/gcl/ChangeLog, /cvsroot/gcl/gcl/ChangeLog.orig:
Index: makefile
===================================================================
RCS file: /sources/gcl/gcl/makefile,v
retrieving revision 1.73.4.2.2.21.6.1.8.9
diff -p -r1.73.4.2.2.21.6.1.8.9 makefile
*** makefile	15 Sep 2006 17:45:18 -0000	1.73.4.2.2.21.6.1.8.9
--- makefile	17 Sep 2006 21:06:01 -0000
*************** install1:
*** 196,203 ****
  #	(cd $(DESTDIR)$(INSTALL_LIB_DIR)/gcl-tk/demos ; \
  #	echo '(load "../tkl.o")(TK::GET-AUTOLOADS (directory "*.lisp"))' | ../../$(PORTDIR)/$(FLISP)$(EXE)) ; fi
  	if test "$(EMACS_SITE_LISP)" != "" ; then (cd elisp ; $(MAKE) install DESTDIR=$(DESTDIR)) ; fi
! 	if test "$(INFO_DIR)" != "unknown"; then (cd info ; $(MAKE) ; $(MAKE) install DESTDIR=$(DESTDIR)) ; fi
! 	if test "$(INFO_DIR)" != "unknown"; then (cd xgcl-2 ; $(MAKE) install DESTDIR=$(DESTDIR)) ; fi
  	if gcc --version | grep -i mingw >/dev/null 2>&1 ; then cp COPYING.LIB-2.0 readme-bin.mingw $(prefix) ; fi
  	if gcc --version | grep -i mingw >/dev/null 2>&1 ; then cp gcl.ico $(prefix)/bin ; fi
  	if gcc --version | grep -i mingw >/dev/null 2>&1 ; then rm -rf $(prefix)/install; mkdir $(prefix)/install ; cp windows/install.lsp $(prefix)/install ; windows/instdos.sh windows/sysdir.bat $(prefix)/bin/sysdir.bat ; fi
--- 196,203 ----
  #	(cd $(DESTDIR)$(INSTALL_LIB_DIR)/gcl-tk/demos ; \
  #	echo '(load "../tkl.o")(TK::GET-AUTOLOADS (directory "*.lisp"))' | ../../$(PORTDIR)/$(FLISP)$(EXE)) ; fi
  	if test "$(EMACS_SITE_LISP)" != "" ; then (cd elisp ; $(MAKE) install DESTDIR=$(DESTDIR)) ; fi
! 	-if test "$(INFO_DIR)" != "unknown"; then (cd info ; $(MAKE) ; $(MAKE) install DESTDIR=$(DESTDIR)) ; fi
! 	-if test "$(INFO_DIR)" != "unknown"; then (cd xgcl-2 ; $(MAKE) install DESTDIR=$(DESTDIR)) ; fi
  	if gcc --version | grep -i mingw >/dev/null 2>&1 ; then cp COPYING.LIB-2.0 readme-bin.mingw $(prefix) ; fi
  	if gcc --version | grep -i mingw >/dev/null 2>&1 ; then cp gcl.ico $(prefix)/bin ; fi
  	if gcc --version | grep -i mingw >/dev/null 2>&1 ; then rm -rf $(prefix)/install; mkdir $(prefix)/install ; cp windows/install.lsp $(prefix)/install ; windows/instdos.sh windows/sysdir.bat $(prefix)/bin/sysdir.bat ; fi
Index: info/makefile
===================================================================
RCS file: /sources/gcl/gcl/info/makefile,v
retrieving revision 1.23.6.4.2.1
diff -p -r1.23.6.4.2.1 makefile
*** info/makefile	25 Jun 2004 22:40:25 -0000	1.23.6.4.2.1
--- info/makefile	17 Sep 2006 21:06:11 -0000
*************** gcl.info: ${GCL_MAN} gcl.texi
*** 58,73 ****
  #	$(HTML_CMD) gcl.texi

  gcl-si/index.html: ${GCL_SI} gcl-si.texi
! 	$(HTML_CMD) gcl-si.texi

  gcl-tk/index.html: ${GCL_TK} gcl-tk.texi
! 	$(HTML_CMD) gcl-tk.texi

  gcl/index.html: gcl.texi
! 	$(HTML_CMD) gcl.texi

  install-html: gcl-tk_toc.html gcl-si_toc.html gcl_toc.html
! 	cp *.html /d/www/gcl

  install: $(GCL_DVI) $(GCL_HTML)
  	mkdir -p $(DESTDIR)${INFO_DIR}
--- 58,73 ----
  #	$(HTML_CMD) gcl.texi

  gcl-si/index.html: ${GCL_SI} gcl-si.texi
! 	-$(HTML_CMD) gcl-si.texi

  gcl-tk/index.html: ${GCL_TK} gcl-tk.texi
! 	-$(HTML_CMD) gcl-tk.texi

  gcl/index.html: gcl.texi
! 	-$(HTML_CMD) gcl.texi

  install-html: gcl-tk_toc.html gcl-si_toc.html gcl_toc.html
! 	-cp *.html /d/www/gcl

  install: $(GCL_DVI) $(GCL_HTML)
  	mkdir -p $(DESTDIR)${INFO_DIR}

\start
Date: Sun, 17 Sep 2006 20:23:20 -0400
From: Tim Daly
To: Camm Maguire
Subject: GCL on MAC OSX (powerpc)

I spent the day trying to build axiom on the MAC.
GCL builds and generates a lisp image that works.
(I'm using the Xcode development environment).
Unfortunately if you do a save-system the stored
image will NOT work. 

I'm rewriting the Makefiles to handle a pure-lisp
image build.

\start
Date: 18 Sep 2006 03:11:44 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: GCL on MAC OSX (powerpc)
Cc: Camm Maguire

Tim Daly writes:

| Camm,
| 
| I spent the day trying to build axiom on the MAC.
| GCL builds and generates a lisp image that works.
| (I'm using the Xcode development environment).
| Unfortunately if you do a save-system the stored
| image will NOT work. 

What are the symptoms?

\start
Date: 18 Sep 2006 03:24:20 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: libspad.a, cfuns-c.o sockio-c.c and friends

  My understanding, from reading src/lib/Makefile.pamphlet, is that
sockio-c.o is contained in libspad.a.  So why is it specified again
in lsp/Makefile.pamphlet when building a fresh lisp image from GCL?

Also, is there a reason why cfuns-c.o is not archived in libspad.a?

\start
Date: Sun, 17 Sep 2006 22:02:41 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: GCL on MAC OSX (powerpc)
Cc: Camm Maguire

> | I spent the day trying to build axiom on the MAC.
> | GCL builds and generates a lisp image that works.
> | (I'm using the Xcode development environment).
> | Unfortunately if you do a save-system the stored
> | image will NOT work. 
> 
> What are the symptoms?

frustration, fatigue, lack of....

oh, you mean the failure? 
the lisp runs fine but the image after the save-system
fails with an illegal instruction. looks like the link
edit failed to fill in a branch somewhere. i played with
GDB for a while but got nowhere.

Can't get Martin's stuff to work, can't get MAC stuff to work.
Made no perceptible progress at all this weekend. sigh.

\start
Date: Sun, 17 Sep 2006 22:11:27 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: libspad.a, cfuns-c.o sockio-c.c and friends
Cc: list

>   My understanding, from reading src/lib/Makefile.pamphlet, is that
> sockio-c.o is contained in libspad.a.  So why is it specified again
> in lsp/Makefile.pamphlet when building a fresh lisp image from GCL?
> 
> Also, is there a reason why cfuns-c.o is not archived in libspad.a?

cfuns-c.o and sockio-c.o get linked directly into the lisp image.
they are required to be part of the image so axiom can talk to sman,
the superman process that managed communication with hyperdoc and
graphics.

\start
Date: Sun, 17 Sep 2006 19:25:58 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: LaTeX source of the Rosetta document?

We've got the Rosetta document up in html form at
http://wiki.axiom-developer.org/RosettaStone

Is the LaTeX source code of this also available somewhere?  If so, can
we add a link to it to the wiki page?  I suppose in theory it would be
less current but it would be nice to have available.  If the copyright
on it permits, mightn't this also make a good appendix in the Axiom
Tutorial?

\start
Date: Sun, 17 Sep 2006 22:45:13 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: LaTeX source of the Rosetta document?

> Is the LaTeX source code of this also available somewhere?  

src/doc/Rosetta.pamphlet

\start
Date: 18 Sep 2006 04:55:08 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: libspad.a, cfuns-c.o sockio-c.c and friends

Tim Daly writes:

| >   My understanding, from reading src/lib/Makefile.pamphlet, is that
| > sockio-c.o is contained in libspad.a.  So why is it specified again
| > in lsp/Makefile.pamphlet when building a fresh lisp image from GCL?
| > 
| > Also, is there a reason why cfuns-c.o is not archived in libspad.a?
| 
| cfuns-c.o and sockio-c.o get linked directly into the lisp image.
| they are required to be part of the image so axiom can talk to sman,
| the superman process that managed communication with hyperdoc and
| graphics.

Yes, but then what about the copy of cfuns-c.o in libspad.a (which is
also specified along with cfuns-c.o)?

I guess another way to phrase my question is what is the difference
between specifying an object file directly, from as included via
libspad.a? 

\start
Date: Sun, 17 Sep 2006 20:16:59 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: LaTeX source of the Rosetta document?

Thanks Tim.  I added a comment to the RosettaStone page - I can't seem
to edit the page itself, perhaps because of the large number of <a
href= type entries?

Is anyone else seeing a problem with the formatting of the comments on
the RosettaStone wiki page or is it just my browser?

By the way, what is the best/preferred way to handle this page - edit
the pamphlet file and then update the wiki page, or edit the wiki page
and occasionally go back and edit the pamphlet file?

Cheers,
CY

--- Tim Daly wrote:

> > Is the LaTeX source code of this also available somewhere?  
> 
> src/doc/Rosetta.pamphlet

\start
Date: Mon, 18 Sep 2006 00:21:21 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: LaTeX source of the Rosetta document?

On September 17, 2006 11:17 PM C Y wrote:
> 
> Thanks Tim.  I added a comment to the RosettaStone page - I can't
> seem to edit the page itself, perhaps because of the large number
> of <a href= type entries?

Yes, probably. We still have the pain caused by spam to deal with. :(
Right now to edit these pages with many links you must have a Zope
user id and password.

> 
> Is anyone else seeing a problem with the formatting of the comments
> on the RosettaStone wiki page or is it just my browser?
> 

No it is not your browser. The formatting was a little strange because
this page used the old HTML page type. To be formatted properly comments
would have to be written in HTML. This is a limitation of the Zwiki
software. But I have just change the page type to allow StructuredText
so the comments should be ok now.

> By the way, what is the best/preferred way to handle this page -
> edit the pamphlet file and then update the wiki page, or edit the
> wiki page and occasionally go back and edit the pamphlet file?
> 

This page

http://wiki.axiom-developer.org/RosettaStone

was the result of an early experiment to convert LaTeX to HTML before
we had support for pamphlets on the wiki. The result of the conversion
is one really large page which is very slow to load. Perhaps we should
either do a better job of conversion to HTML (multiple pages) or maybe
just replace it with the pamphlet version?

http://wiki.axiom-developer.org/axiom--test--1/src/doc/Rosetta

At least that would simplify the online edit issue. I could also probably
eliminate the ban on links inside pamphlet files since spammers are
unlikely to go to the trouble of editing LaTeX/noweb pages. (There would
still be a restriction in the comments section of the pamplet page.)

\start
Date: Mon, 18 Sep 2006 00:40:23 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: libspad.a, cfuns-c.o sockio-c.c and friends

> I guess another way to phrase my question is what is the difference
> between specifying an object file directly, from as included via
> libspad.a? 

the lisp has to have some sort of extern linkage reference 
in order to choose the .o file from the archive. clearly there
is nothing in GCL that references those symbols as externs
so if you add libspad.a in the standard GCL linkage no .o
file will be selected from the archive.

but when the cfuns and sockio are included in the image
then the symbols they contain can be referenced by lisp
code which is written at run time.

axiom contains lisp code that uses the symbols externed by
cfuns and sockio. 

\start
Date: 18 Sep 2006 08:45:38 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: libspad.a, cfuns-c.o sockio-c.c and friends

Tim Daly writes:

| > I guess another way to phrase my question is what is the difference
| > between specifying an object file directly, from as included via
| > libspad.a? 
| 
| the lisp has to have some sort of extern linkage reference 
| in order to choose the .o file from the archive. clearly there
| is nothing in GCL that references those symbols as externs
| so if you add libspad.a in the standard GCL linkage no .o
| file will be selected from the archive.

Aha!  So, in fact we can just remove libspad.a from that list since
nothing in GCL references symbols from libspad.a.  Is that correct?

\start
Date: Mon, 18 Sep 2006 10:31:36 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: several images on one page

Sorry, Tim, I am unable to find it.

Ralf

On 09/15/2006 05:28 AM, root wrote:
>>> One of the outstanding problems I have to solve is how to place more
>>> than one image on a page. That's the one blocking condition to
>>> reproducing the Jenks book accurately.
>> Without a clear problem description, nobody is able to help.
> 
> Check the email archives where I was asking for help.
> 
> I recently bought a book (The Latex Graphics Companion)
> that appears to contain the solution. Now all I have to
> do is get educated.

\start
Date: Mon, 18 Sep 2006 12:14:41 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Question concerning types...

On 09/17/2006 09:18 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> [...]
> 
> | Looking at it mathematically (and simplified) then all we do is that
> | we take a universal algebra D = (A, F) where A is the carrier set and
> | F are the functions on it. Variable(D) is maybe a bad name, but all we
> | do is that Variable(D) = (A', F') is a universal algebra where A' is
> | the union of the set A, a set X of indeterminates, and all things that
> | can be generated from A and X by applying functions from F'. F and F'
> | behave identically on A.
> 
> yes.
> 
> | Mathematically, that's not a big deal. But Aldor domains are actually
> | multi-sorted algebras. That makes the situation a little more
> | complicated.
> 
> but not impossible.
> 
> In this discussion, I'm going to ignore Aldor for a moment and
> concentrate on SPAD because I don't have access to Aldor source code
> and anything that might transpire out of this discoussion should 
> probably be recorded as a feature-request for SPAD with all the
> "insights" we might have gained.

That's OK for me. But it is easier for me to speak Aldor, because it has 
a reasonable language description. I am not at all fluent in SPAD, so 
maybe we need a translator sometimes.

> | So I still disagree with you that x+y should be of type
> | FreeMonoid(Variable(Integer)). From what I said above, it seems more
> | natural to me that its type is Variable(Integer) (well, it's a bad
> | name, maybe Indefinite(Integer) would be better).
> 
> I don't think it should be Variable(Integer).  For me,
> Variable(Integer) means a symbol who interpretation is of type
> Integer.

OK, I can live with that. But that is saying that you don't just *lift* 
the operations from Integer to Variable(Integer). In Integer you would have

+: (%, %) -> %;

in Variable(Integer) you'd have

+: (%, %) -> FreeMonoid %;

So that is saying, for each operation you have to figure out the right 
return type. And since the signatures belong to the argument of the 
function "Variable", you'd have to build a universal constructor 
("Variable") that does this for arbitrary arguments.

Good luck to figure out the return type foo for Variable(MyInteger) and

MyInteger: IntegerType with {foo: %->%} == Integer add {foo(x:%):%==x}

 > I don't like Indefinite(Integer) neither.  So, it might very
> well be that we're back to our old beloved friend Expression(Integer).

No, definitely not. The difference to Expression Integer is that the 
"Integer" in the argument says something about the coefficients in the 
internal representation (Remember Axiom stores Expression(D) as a 
quotient of multivariate polynomials over D in "kernels" as variables.)
So Expression(D) does NOT say anything about the variables. In fact, I 
believe that the argument of Expression is more or less only there for 
technical reasons. The domains Expression(Integer) and Expression(Float) 
or Expression(AlgebraicNumber) are all different. But an element of

Expression SUP Integer

could as well live in Expression Integer. Expression in Axiom is a way 
to remove type information. Good for interactive stuff, but I still 
believe that people should be more specific (ie add appropriate types) 
when they write libraries.

So what I want (and I think also you want that) is such a lifting 
procedure where the *types of the variables* would be known. So the 
whole expression whould type-check. It's a kind of TypedExpression 
domain. Expression and TypedExpression looks similar to lamda calulus 
and typed lambda calculus to me.

> | Anyway, what we want is a nice way of adding elements and more or less
> | keeping the type of the domain.
> 
> yes.
> 
> | And that is not possible if you just define "Indefinite" having one
> | argument D. 
> 
> I'm clear why not.  Could you explain this a bit further?

Because that would require that each domain exports its category. 
Remember, Aldor does not have reflection. You get D and currently the 
only way to ask something about the type of D is

    D has CATX

Of course that is not useful since you'd have to know the exports of D 
at the time you write the program. That's much too early.

> | One must know the type of D 
> | (a category) so that the return type would be clear.
> | 
> | Indefinite(C: Catagory)(D: C): C == add {
> |      Rep == Union(d: D, ???)
> |      ...
> | }
> | 
> | The ??? should be something that allows arbitrary expressions formed
> | from D, the functions in C and some indeterminates X. (I have no idea
> | how that would look like. Maybe just delayed evaluation of function
> | composition.)

> I suspect I'm being dense here.  What would be wrong with Expression D?

As explained above, Expression D is NOT what you want.

> | > | (1) -> (a1,a2,a3,a4):Expression Quaternion Fraction Integer
> | > |         Type: Void
> | > | (2) -> m := matrix[[a1,a2],[a3,a4]]
> | > | |           +a1  a2+
> | > |      (2)  |      |
> | > |           +a3  a4+
> | > |         Type: Matrix Expression Quaternion Fraction Integer
> | > | | given by Bill suggest that the Axiom interpreter is a bit more
> | > relaxed.
> | > Funny enough, I tried similar thing and sent a message before seeing
> | > Bill's.  That is a natural thing to do if you have a Universal Algebra
> | > backgroud -- e.g. you're used to the 3M's.
> | 
> | Maybe. I don't say that shouldn't be allowed in the interpreter, but
> | the compiler would generate a matrix of 4 uninitialized entries. Now
> | what happens if you print m(1,1)?
> 
> If that entry is a Variable? I would expect the output to indicate
> either the name or just m(1,1).  Look at what Axiom prints when you
> say
> 
>     m * m
> 
> That matches my expectation.

Oh, please don't quote Axiom or any other system, I know they are 
relaxed and do what you expect. But look carefully at what you have 
written above, translate that into C, then you see that you have never 
given a1 a value, so the memory location is probably the nil pointer.

I quite like the distinction in the abstract of

http://portal.axiom-developer.org/refs/articles/TheUnknownInComputerAlgebra.dvi

Above a1,a2,a3,a4, and m are "programming variables" and interestingly 
there is actually no "mathematical symbol" specified above. The axiom 
interpreter now is smart and treats (1) as a definition of symbols that 
are called by the same name.

You see the difference if you type

)clear all
a1: Expression Integer := B

> | If that prints something reasonable
> | then it tells me that the compiler knows about a special domain
> | constructor, namely Expression.

> yes.

Maybe I was not clear enough. I meant, that then the compiler has the 
Expression domain built-in. That would be something that I would not 
really like. The compiler and the interpreter should not know about 
mathematics. You can easily implement Expression as a library package 
and that is where it belongs.

> |  Drop "Expression" from above, what
> | would be on screen for "stdout << m(1,1)"? 
> 
> well, it Expression is dropped then we're back to the interpretation
> we all agree on: A value of type Quaternion Fraction Integer.
> Consequently m(1,1) must hold value of that type.

OK.

> | The interpreter can add
> | smart things. I am asking for the compiler.
> | 
> | [...]
> | 
> | > | I guess the interpreter has to do a lot of
> | > | work to find the right interpretation for such a + and it must decide
> | > | for one of possibly many choices.
> | > If "+" is defined as beeing an associative operation , there would
> | > not
> | > be much work to do.
> | 
> | Oh, who said that + is associative? The documentation, right? 
> 
> And
> 
> yes, but in my model much of the documentation is moved to code.  In
> this case, I would like to see properties() used to attach
> mathematical properties.  

I am really curious, what model you have. What should

properties()$Integer

return?

> | But that
> | is not a nice thing to take into account for the compiler.
> 
> Why?  

I meant that the documentation is not formal enough for a compiler.

>>From my point of view, the type of an operation is just as important
> as its algebraic properties.

Oh, yes, I completely agree. Axiom should have axioms. ;-)

> | It would be
> | much better if Aldor allowed to state associativity in a formal manner.
> 
> SPAD does.  See properties()

Sorry, if you mean that, that is not formal enough for me. You just 
declare commutative("*") and you are done. If you start with the Peano 
Axioms then commutativity is not a declaration it requires a proof. So 
it's a theorem. What I would like to have is to state the theorem and 
hand it to a prover (who then spits out that * is commutative).

> | > In fact I don't want the interpret to become
> | > super smart.  Just lift operations.
> | 
> | I am completely with you. The interpreter should not have any
> | mathematical knowledge, just look into a database (basically the Axiom
> | libraries) and figure out what could be done. It should be possible to
> | change the libraries and work with the same interpreter.
> 
> yes.

Good to hear that we are on the same side.

\start
Date: Mon, 18 Sep 2006 12:57:20 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: equal or unequal (was: Question concerning types...)

Hi Gaby,

> | OK, let's turn this into a mathematical example. | | A := Fraction
> Complex Integer; a: A := 1 | B := Complex Fraction Integer; b: B := 1
>  | | Clearly A and be are isomorphic as fields, but they are NOT
> identical.
> 
> As syntactic obejcts, no, they are not.  The issue can be rephrased
> as whether they should remain non-equal in other non-syntactical 
> intepretation.   I think no.

Ah, you said it. You have a map inbetween to make things equal, namely
the "interpretation".

Maybe the above is not the best example, but I very much believe that
there are situations where one person wants to consider two things as
equal and another doesn't. They might have different focus. So if you
"design" the two things (like A and B) to be ALWAYS equal, you basically
prevent the second person from finding your CAS appropriate for his work.

> | Not identical in Axiom and not identical in mathematics.

> You have lost me on the last part.  My book says that both A and B
> are the same mathematical object.  Why do you believe they are not?

Let Z denote integer.

Let R denote a ring then C(R), the complex numbers over R is defined as
R[x]/(x^2+1). Let E and I denote the equivalence classes of 1 and x in
C(R) then an element of C(R) can be written as x*E+y*I.

Let R denote a ring without zero divisors. Then Q(R) is defined as
R^2/~ where (x,x') ~ (y,y') :<==> xy'=x'y. The equivalence class of
(x,x') in Q(R) is written as x/x'.

An element in A=Q(C(Z)) looks like (x*E+y*I) / (u*E+v*I).
An element in B=C(Q(Z)) looks like (x/y)*E + (u/v)*I.

(x,y,u,v all elements of Z)

If you now say that you can find two elements of A and B that are
mathematically equal (what does that mean, by the way?), then you
basically try to find a way to make them equal.

If you say that A=B that requires a proof.

A simpler example is Z itself. N is constructed by the peano axioms.
Z = N^2/~ where (m,n) ~ (m',n') :<==> m+n' = m'+n.

By construction, if n\in N then n \not\in Z.

Very often we say something like

   By abuse of notation we identify n and the class  [(n,0)] in Z and
   simply write n\in Z.

I haven't seen any computer algebra system that has addressed such
"abuse of notation". Actually all just abuse the notation and one cannot
do things that where not designed into the system. (It's a different
type of problem, but note how difficult it is to teach Maple or
Mathematica that your * is not commutative.)

> | Note, we had a discussion whether "Fraction Fraction Integer"
> should | be implemented to be the same as "Fraction Integer".

> Under the mathematical interpretation they are the same.

What is THE mathematical interpretation?

I am sure William Sit can elaborate on this.

> I believe they should also be the same in Axiom -- at least if you
> take dependent types seriously.

Could you tell in which sense this has to do with dependent types? You 
also don't want

SparseUnivariatePolynomial SparseUnivariatePolynomial Integer

to be just

SparseUnivariatePolynomial Integer


> | Although I had even given code to do that, I believe it should
> | not be implemented that way. Because an element that looks like
> | (2/1)/(3/1) is NOT identical to 2/3.

> By the same token we should prevent Axiom from simplifying 3+2 to 5.

You are mixing things. Let's suppose 3, 2, 5 are from Integer. Then 
there is +: (Integer, Integer) -> Integer. So we can simply apply that 
function to 3 and 2. Why would you forbid that?

The above is different.

First let's make it equal. If you type (2/1) and (3/1) they are of type 
Fraction Integer. Fraction Integer is a field and allows the operation 
/: (%, %) -> %. So that operation can be applied and yields 2/3.

Now make it different. If I interpret the second / in (2/1)/(3/1) as 
/$Fraction(Fraction Integer) (note that Fraction(S) has an operation 
/:(S,S)->%), then (2/1)/(3/1) is simply an element of 
Fraction(Fraction(Integer)) and is not equal to 2/3 because it has a 
different type.

For some reason the Axiom designers decided to put some knowledge into 
the interpreter which forbids to build "Fraction(Fraction(Integer))".
(But you agreed to put no such knowledge into interpreter or compiler. 
Or do you change your mind now?)

\start
Date: 18 Sep 2006 13:00:43 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Question concerning types...

Ralf Hemmecke writes:

[...]

| > | So I still disagree with you that x+y should be of type
| > | FreeMonoid(Variable(Integer)). From what I said above, it seems more
| > | natural to me that its type is Variable(Integer) (well, it's a bad
| > | name, maybe Indefinite(Integer) would be better).
| > I don't think it should be Variable(Integer).  For me,
| > Variable(Integer) means a symbol who interpretation is of type
| > Integer.
|
| OK, I can live with that. But that is saying that you don't just
| *lift* the operations from Integer to Variable(Integer).

I really meant *lift*, in the following sense:

     Integer =D7 Integer  ---> Variable Integer =D7 Variable Integer
             |                                |
      binOp  |                                | lift(binOp)
             v                                v
          Integer    ------------>    Variable Integer
=


(the horizontal arrows are to be elaborated).

| In Integer
| you would have
|
| +: (%, %) -> %;
|
| in Variable(Integer) you'd have
|
| +: (%, %) -> FreeMonoid %;

I certainly want to say (x+y) + (s+t), so I think I really want to have

     + : ($, $) -> $

in Variable Integer -- or FreeMonoid $, whatever it is called.

| So that is saying, for each operation you have to figure out the right
| return type.

Maybe I'm dense here, but I still don't get what you're saying.

[...]

| So what I want (and I think also you want that) is such a lifting
| procedure where the *types of the variables* would be known.

Yes.

| So the whole expression whould type-check. It's a kind of TypedExpression
| domain. Expression and TypedExpression looks similar to lamda calulus
| and typed lambda calculus to me.

Kind of.

| > | Anyway, what we want is a nice way of adding elements and more or less
| > | keeping the type of the domain.
| > yes.
| > | And that is not possible if you just define "Indefinite" having one
| > | argument D. I'm clear why not.  Could you explain this a bit
| > further?
|
| Because that would require that each domain exports its
| category.

So?

| Remember, Aldor does not have reflection.

If you don't want me to quote Axiom or other systems to you, why are
you quoting Aldor to me?

| You get D and
| currently the only way to ask something about the type of D is
|
|     D has CATX

yes, and that is quite limited, I know.  But, we are discussing a
system where we would like to express directly abstractions.  I don't
consider the currently crippled way of expressing things a sufficient
reason that answer my request above.

[...]

| > | > | (1) -> (a1,a2,a3,a4):Expression Quaternion Fraction Integer
| > | > |         Type: Void
| > | > | (2) -> m := matrix[[a1,a2],[a3,a4]]
| > | > | |           +a1  a2+
| > | > |      (2)  |      |
| > | > |           +a3  a4+
| > | > |         Type: Matrix Expression Quaternion Fraction Integer
| > | > | | given by Bill suggest that the Axiom interpreter is a bit more
| > | > relaxed.
| > | > Funny enough, I tried similar thing and sent a message before seeing
| > | > Bill's.  That is a natural thing to do if you have a Universal Alge=
bra
| > | > backgroud -- e.g. you're used to the 3M's.
| > | | Maybe. I don't say that shouldn't be allowed in the interpreter,
| > but
| > | the compiler would generate a matrix of 4 uninitialized entries. Now
| > | what happens if you print m(1,1)?
| > If that entry is a Variable? I would expect the output to indicate
| > either the name or just m(1,1).  Look at what Axiom prints when you
| > say
| >     m * m
| > That matches my expectation.
|
| Oh, please don't quote Axiom or any other system, I know they are
| relaxed and do what you expect.

So?  If they do what I expect, then what is the problem?

| But look carefully at what you have
| written above, translate that into C, then you see that you have never
| given a1 a value, so the memory location is probably the nil pointer.

That does not make any sense to me.  How do you declare a symbolic
variable in C?

[...]

| > | If that prints something reasonable
| > | then it tells me that the compiler knows about a special domain
| > | constructor, namely Expression.
|
| > yes.
|
| Maybe I was not clear enough. I meant, that then the compiler has the
| Expression domain built-in. That would be something that I would not
| really like. The compiler and the interpreter should not know about
| mathematics.

They have to know about *something*.  That something would hardly be
sport games.

I suspect you instead wanted them to know as minimum as possible of
mathematics.

[...]

| > | The interpreter can add
| > | smart things. I am asking for the compiler.
| > | | [...]
| > | | > | I guess the interpreter has to do a lot of
| > | > | work to find the right interpretation for such a + and it must de=
cide
| > | > | for one of possibly many choices.
| > | > If "+" is defined as beeing an associative operation , there would
| > | > not
| > | > be much work to do.
| > | | Oh, who said that + is associative? The documentation, right? And
| > yes, but in my model much of the documentation is moved to code.  In
| > this case, I would like to see properties() used to attach
| > mathematical properties.
|
| I am really curious, what model you have. What should
|
| properties()$Integer
|
| return?

Currently properties() take basic operators -- see the doc.

In in the system I see I would like properties('+ $ Integer) to report
all  registered properties of + from Integer.  A sort of typeful
version of Mathematica's Attributes[].

| > | But that
| > | is not a nice thing to take into account for the compiler.
| > Why?
|
| I meant that the documentation is not formal enough for a compiler.

yes, but you can't completly remove documentation.  All you can wish
is to move as much as possible from documentation to something the
compiler understand.

| >>From my point of view, the type of an operation is just as important
| > as its algebraic properties.
|
| Oh, yes, I completely agree. Axiom should have axioms. ;-)
|
| > | It would be
| > | much better if Aldor allowed to state associativity in a formal manne=
r.
| > SPAD does.  See properties()
|
| Sorry, if you mean that, that is not formal enough for me. You just
| declare commutative("*") and you are done.

yes, just as you declare axioms for your mathematical structures.  You
certainly don't want people to prove their axioms?

| If you start with the Peano
| Axioms then commutativity is not a declaration it requires a proof.

If I start there, then probably.  But what if I do not?

If you want to take it that way, do you really want Axiom not to use
the hardware for interger arithmetic but, instead go backt o Church
numerals?

I don't.

| So it's a theorem.

A theorem in one system, is just an axiom in another one.
Where you start greatly depends on needs and contexts.

| What I would like to have is to state the theorem and
| hand it to a prover (who then spits out that * is commutative).

That is good for one use of the system.  For another use, I don't
really want to go through that even I can have the system just look up
and does the job.

This is not an alien story to mathematician.  Start by assuming
something, and progress.  Latter you can prove that something from
more "primitive" blocks.  But, the real practice rarely is starts from
"primitives" and head directly to the final bits.

\start
Date: Mon, 18 Sep 2006 13:23:50 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Question concerning types...

>> I agree with you that if D had type T then Variable(D) should 
>> have type T (plus maybe some exports that allow to create
>> "indeterminates").
> 
> The meaning of this statement is unclear to me. Do you mean:
> If D has category T then Variable(D) should have category T?
> If so, I would disagree. Variable(D), as a universal algebra
> over some symbols must have a different (but related) type,
> perhaps Variable(D) has Universal(T)?

Let's make it simple. Integer is a Ring. Don't you want that Integer 
together with "indefinite integers" also form a ring? I don't think that 
I would want Universal(Ring). What is Universal, by the way?

I understand that "indefinite" thing just as a way to encode a delayed 
evaluation. In the "computation" that is done just with the type 
information, you can do any tricks that you can do with that 
information, but if that computation needs a value, it has to wait until 
I provide one. The point is, that you cannot apply an arbitrary 
operation on these indefinite objects. For example if I have a very 
restricted scope and not / operation can be seen then the compiler 
should reject to compile a/b for indefinite integers a and b.

>> Looking at it mathematically (and simplified) then all we do 
>> is that we take a universal algebra D = (A, F) where A is the
>> carrier set and F are the functions on it. Variable(D) is maybe
>> a bad name, but all we do is that Variable(D) = (A', F') is a
>> universal algebra where A' is the union of the set A, a set X 
>> of indeterminates, and all things that can be generated from A
>> and X by applying functions from F'. F and F' behave identically
>> on A.
>>
>> Mathematically, that's not a big deal. But Aldor domains are
>> actually multi-sorted algebras. That makes the situation a little
>> more complicated.

> I think sometimes you think too much about Aldor and not enough
> about Axiom... ;)

I don't think that my statement is much related to Aldor. You could 
replace Aldor by Axiom or SPAD, if you like. So what did you actually mean?

>> So I still disagree with you that x+y should be of type 
>> FreeMonoid(Variable(Integer)). From what I said above, it seems
>> more natural to me that its type is Variable(Integer) (well,
>> it's a bad name, maybe Indefinite(Integer) would be better).

> The interesting thing to me is that all you appear to be doing here
> is "re-inventing" the Expression domain constructor.
> 
> It seems to me that 'Expression(Integer)' is a good enough name. :-)

But inside Expression(Integer) the variables have NO type information 
attached.

> I strongly recommend that you take a close look at how Expression is
> implemented in the Axiom library.

Thank you. But Expression is not what solves the "indefinite" problem.

> 'sin(a1)' which are not evaluated any further in the Expression
> domain.

OK, let's take

n: Expression Integer := n
z := sin(2* %Pi * n)

Axiom knows, in fact, nothing about the n. But if it really knew that n 
is an Integer, it could simplify z to 0.

That should be a test case for indefinite computation.

>> Now what happens if you print m(1,1)? If that prints something 
>> reasonable then it tells me that the compiler knows about a special
>> domain constructor, namely Expression.
> 
> Yes.
> 
>> Drop "Expression" from above, what would be on screen for "stdout
>> << m(1,1)"? The interpreter can add smart things. I am asking for
>> the compiler.
>>
> 
> I don't understand. Obviously Expression is a domain that the SPAD
> compiler understands. Implementing Expression in Aldor should be
> quite straight forward.

Of course the Expression type is known. But is should not be built-in 
into the compiler. It should live in a library.

\start
Date: 18 Sep 2006 13:21:21 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: equal or unequal (was: Question concerning	types...)

Ralf Hemmecke writes:

| Hi Gaby,
| 
| > | OK, let's turn this into a mathematical example. | | A := Fraction
| > Complex Integer; a: A := 1 | B := Complex Fraction Integer; b: B := 1
| >  | | Clearly A and be are isomorphic as fields, but they are NOT
| > identical.
| > As syntactic obejcts, no, they are not.  The issue can be rephrased
| > as whether they should remain non-equal in other non-syntactical
| > intepretation.   I think no.
| 
| Ah, you said it. You have a map inbetween to make things equal, namely
| the "interpretation".
| 
| Maybe the above is not the best example,

it certainly isn't, sorry.

| but I very much believe that
| there are situations where one person wants to consider two things as
| equal and another doesn't.

if we are discussing abstract unknown "things" in general, then the
discussion is contentless, as that is symbolic computation issue 101.

However, here you put forward a very specific example.  Which, as far
as I can determine, does not support your claim. 

[...]

| > | Not identical in Axiom and not identical in mathematics.
| 
| > You have lost me on the last part.  My book says that both A and B
| > are the same mathematical object.  Why do you believe they are not?
| 
| Let Z denote integer.

Ralf, for an integral domain D, Quotient(Quotient(D)) = Quotient(D),
where Quotient is the "quotient field functor".

[...]

| Very often we say something like
| 
|    By abuse of notation we identify n and the class  [(n,0)] in Z and
|    simply write n\in Z.
| 
| I haven't seen any computer algebra system that has addressed such
| "abuse of notation".

think "coerce".  Now, a practical issue is whether I would want that
corce to be built-in or library.  For efficient reasons, I would
prefer it built-in -- until systems have progress to the point where
they attain zero abstraction penalty.

Another issue is whether the disction is practically useful.  Here,
opinions vary.


 Actually all just abuse the notation and one cannot
| do things that where not designed into the system. (It's a different
| type of problem, but note how difficult it is to teach Maple or
| Mathematica that your * is not commutative.)
| 
| > | Note, we had a discussion whether "Fraction Fraction Integer"
| > should | be implemented to be the same as "Fraction Integer".
| 
| > Under the mathematical interpretation they are the same.
| 
| What is THE mathematical interpretation?

anyone in any algebra book I've read so far.

| I am sure William Sit can elaborate on this.
| 
| > I believe they should also be the same in Axiom -- at least if you
| > take dependent types seriously.
| 
| Could you tell in which sense this has to do with dependent types? 

dependent types will depend on *values*, not just syntactic objects.
Consequently, when you compare types, you don't just compare them on
syntax, but on their canonical values.
Fraction is idempotent for integral domains.

| You also don't want
| 
| SparseUnivariatePolynomial SparseUnivariatePolynomial Integer
| 
| to be just
| 
| SparseUnivariatePolynomial Integer

what is the connection?

| > | Although I had even given code to do that, I believe it should
| > | not be implemented that way. Because an element that looks like
| > | (2/1)/(3/1) is NOT identical to 2/3.
| 
| > By the same token we should prevent Axiom from simplifying 3+2 to 5.
| 
| You are mixing things. Let's suppose 3, 2, 5 are from Integer. Then
| there is +: (Integer, Integer) -> Integer. So we can simply apply that
| function to 3 and 2. Why would you forbid that?

I would not.  I'm just using the same logic you used to say that
(2/1)/(3/1) is NOT identical to 2/3.

| The above is different.
| 
| First let's make it equal. If you type (2/1) and (3/1) they are of
| type Fraction Integer. Fraction Integer is a field and allows the
| operation /: (%, %) -> %. So that operation can be applied and yields
| 2/3.
| 
| Now make it different. If I interpret the second / in (2/1)/(3/1) as
| /$Fraction(Fraction Integer) (note that Fraction(S) has an operation
| /:(S,S)->%), then (2/1)/(3/1) is simply an element of
| Fraction(Fraction(Integer)) and is not equal to 2/3 because it has a
| different type.

that is a weakness, non-sense in the "type system", not anything
fundamentally, and mathematically, meaningful.

Assume you have thaught the system to understand that Fraction is
idempotent on integral domains.  Why would you still have that problem?

| For some reason the Axiom designers decided to put some knowledge into
| the interpreter which forbids to build "Fraction(Fraction(Integer))".
| (But you agreed to put no such knowledge into interpreter or
| compiler. Or do you change your mind now?)

Why do you think I would have changed my mind when you scrupulously base
your deduction of partial fragments of what I want?

As I said, I want the system powerfull enough to understand algebraic
properties, in particular idempotency.  Also, think of commuting
constructors, that is another area where you have lot of troubles.

\start
Date: Mon, 18 Sep 2006 04:44:10 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: LaTeX source of the Rosetta document?

> On September 17, 2006 11:17 PM C Y wrote:
> > 
> > Thanks Tim.  I added a comment to the RosettaStone page - I can't
> > seem to edit the page itself, perhaps because of the large number
> > of <a href= type entries?
> 
> Yes, probably. We still have the pain caused by spam to deal with. :(
> Right now to edit these pages with many links you must have a Zope
> user id and password.

Ah.  OK. 

> > Is anyone else seeing a problem with the formatting of the comments
> > on the RosettaStone wiki page or is it just my browser?
> 
> No it is not your browser. The formatting was a little strange
> because this page used the old HTML page type. To be formatted
> properly comments would have to be written in HTML. This is a
> limitation of the Zwiki software. But I have just change the page
> type to allow StructuredText so the comments should be ok now.

Thanks!

> This page
> 
> http://wiki.axiom-developer.org/RosettaStone
> 
> was the result of an early experiment to convert LaTeX to HTML before
> we had support for pamphlets on the wiki. The result of the
> conversion is one really large page which is very slow to load.
> Perhaps we should either do a better job of conversion to HTML
> (multiple pages) or maybe just replace it with the pamphlet version?
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/doc/Rosetta

My preference would be the pamphlet version, for the simple reason that
it is better to have one version that everyone keeps up to date. 
Multiple versions in different places is likely to result in one
becoming "current" and the other one getting progressively older,
unless there is an automatic sync between the two.

> At least that would simplify the online edit issue. I could also
> probably eliminate the ban on links inside pamphlet files since
> spammers are unlikely to go to the trouble of editing LaTeX/noweb
> pages. (There would still be a restriction in the comments section of
> the pamplet page.)
> 
> What do you think?

That sounds good to me.  Thanks Bill!

\start
Date: Mon, 18 Sep 2006 14:03:49 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Question concerning types...

On 09/18/2006 01:00 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
>
> [...]
>
> | > | So I still disagree with you that x+y should be of type
> | > | FreeMonoid(Variable(Integer)). From what I said above, it seems m=
ore
> | > | natural to me that its type is Variable(Integer) (well, it's a ba=
d
> | > | name, maybe Indefinite(Integer) would be better).
> | > I don't think it should be Variable(Integer).  For me,
> | > Variable(Integer) means a symbol who interpretation is of type
> | > Integer.
> |
> | OK, I can live with that. But that is saying that you don't just
> | *lift* the operations from Integer to Variable(Integer).
>
> I really meant *lift*, in the following sense:
>
>      Integer =D7 Integer  ---> Variable Integer =D7 Variable Integer
>              |                                |
>       binOp  |                                | lift(binOp)
>              v                                v
>           Integer    ------------>    Variable Integer 
>                          
>
> (the horizontal arrows are to be elaborated).

OK, I want it exactly so. But now you are saying yourself that the type
of x+y from above should be Variable(Integer) and not the FreeMonoid
thing. ;-)

> | In Integer
> | you would have
> |
> | +: (%, %) -> %;
> |
> | in Variable(Integer) you'd have
> |
> | +: (%, %) -> FreeMonoid %;
>
> I certainly want to say (x+y) + (s+t), so I think I really want to have=

>
>      + : ($, $) -> $
>
> in Variable Integer -- or FreeMonoid $, whatever it is called.

Yep, exactly what I said. In Variable(D), Category of D in and Category
of D out. So the type of Variable (or Indefinite) would be... hmm I need =

an extra argument... (aaaahhh, I had that yesterday...)

Indefinite(C: Catagory)(D: C): C == add {
     Rep == Union(d: D, ???)
     ...
}

> | > | Anyway, what we want is a nice way of adding elements and more or=
 less
> | > | keeping the type of the domain.
> | > yes.
> | > | And that is not possible if you just define "Indefinite" having o=
ne
> | > | argument D. I'm clear why not.  Could you explain this a bit
> | > further?
> |
> | Because that would require that each domain exports its
> | category.

> So?

> | Remember, Aldor does not have reflection.

> If you don't want me to quote Axiom or other systems to you, why are
> you quoting Aldor to me?

I cannot program with reflections in Axiom either. ;-)

> | > | > | (1) -> (a1,a2,a3,a4):Expression Quaternion Fraction Integer
> | > | > |         Type: Void
> | > | > | (2) -> m := matrix[[a1,a2],[a3,a4]]
> | > | > | |           +a1  a2+
> | > | > |      (2)  |      |
> | > | > |           +a3  a4+
> | > | > |         Type: Matrix Expression Quaternion Fraction Integer
> | > | > | | given by Bill suggest that the Axiom interpreter is a bit m=
ore
> | > | > relaxed.

> | But look carefully at what you have
> | written above, translate that into C, then you see that you have neve=
r
> | given a1 a value, so the memory location is probably the nil pointer.=

>
> That does not make any sense to me.  How do you declare a symbolic
> variable in C?

How do you declare a symbolic variable in SPAD? As a demonstration, a
short program

---BEGIN aaa.spad
)abbrev package RHXPKG RHxPkg

RHxPkg(): with
   foo: Integer -> Expression Integer
  == add
   foo(n: Integer): Expression Integer ==
     k: Expression(Integer) -- := "x"::Symbol :: Expression(Integer)
     n*k
---END aaa.spad

The two minus signs inside the code are delibarate!
Start Axiom, say
)compile aaa.spad
foo(3)
and be surprised.

> | Maybe I was not clear enough. I meant, that then the compiler has the=

> | Expression domain built-in. That would be something that I would not
> | really like. The compiler and the interpreter should not know about
> | mathematics.
>
> They have to know about *something*.  That something would hardly be
> sport games. 
>
> I suspect you instead wanted them to know as minimum as possible of
> mathematics.

Yes.

> | I meant that the documentation is not formal enough for a compiler.
>
> yes, but you can't completly remove documentation.  All you can wish
> is to move as much as possible from documentation to something the
> compiler understand.

Of course. I stick to the LP paradigm. I am not a computer and computers =

are my slaves. If I just tell them to prove some stupid theorem for me
they should do it. ;-)

> | If you start with the Peano
> | Axioms then commutativity is not a declaration it requires a proof.

> If I start there, then probably.  But what if I do not?

Well, I know we don't start always from zero, but we should always have
a knowledge base in the background and your definitions and theorems are =

based on that knowledge base. If the commutativity proof is inside the
base then fine, otherwise you are not doing mathematics.

> If you want to take it that way, do you really want Axiom not to use
> the hardware for interger arithmetic but, instead go backt o Church
> numerals? 
>
> I don't.

Neither do I, but state the basic Axioms (which would be hardware
integers or GMP) and then go from there. So commutativity in that case
would be an axiom.

> | So it's a theorem.

> A theorem in one system, is just an axiom in another one.
> Where you start greatly depends on needs and contexts.

\start
Date: 18 Sep 2006 14:03:51 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Question concerning types...

Ralf Hemmecke writes:

[...]

|                      The point is, that you cannot apply an arbitrary
| operation on these indefinite objects.

Why not? Why can't I just construct a suspesion for that operation?

| For example if I have a very
| restricted scope and not / operation can be seen then the compiler
| should reject to compile a/b for indefinite integers a and b.

yes, but that does not negate the lifting semantics.  Does it?

\start
Date: Mon, 18 Sep 2006 14:18:15 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Question concerning types...

On 09/18/2006 02:03 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> [...]
> 
> |                      The point is, that you cannot apply an arbitrary
> | operation on these indefinite objects.
> 
> Why not? Why can't I just construct a suspesion for that operation?
> 
> | For example if I have a very
> | restricted scope and not / operation can be seen then the compiler
> | should reject to compile a/b for indefinite integers a and b.
> 
> yes, but that does not negate the lifting semantics.  Does it?

I don't understand. What I said *is* the lifting semantics. If there is 
no / on Integer there is not / on Indefinite(Integer). That's what I said.

\start
Date: Mon, 18 Sep 2006 14:31:15 +0200 (CEST)
From: Bertfried Fauser
To: Ralf Hemmecke
Subject: Re: Question concerning types...

On Mon, 18 Sep 2006, Ralf Hemmecke wrote:

Hi,

a very interesting discussion! Perhaps you might enjoy reading 'The
Skeleton Key' by Dudley E. Littlewood, where the nature of indeterminates
is nicely contemplated.

>From my point of view, could you please explain, why an indeterminate
should behave like the original ring it was abstracted from. This is
uncategorical. Furthermore, there are many ionstances of problems where
inderterminates need to be specified or extendedly specified to make sense
at all or to solve a problem oin a meaningful way, eg Galois theory.

Would you agree that one should try to have say a Ring (integers) and
another algebraic structure (indeterminates) which might have several
attirbutes (associative, power associative, alternative, commutative,
ring, group,....) and that one builds up a new algebra from the
(semi/direct) product of the two algebraic structures at hand.

The diagram in a previous mail wants to define a sort of functor, but then
one has to specify the target category cxarefully! I do not beliefe that
there is such a generalization, usually one has to put severe restrictions
of tyhe nature and number of indeterminates to be able to construct
meaningfull algebraic objects.

Please go ahead with your refreshing discussion...

\start
Date: Mon, 18 Sep 2006 08:39:03 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: libspad.a, cfuns-c.o sockio-c.c and friends

> Aha!  So, in fact we can just remove libspad.a from that list since
> nothing in GCL references symbols from libspad.a.  Is that correct?

correct? i don't know. the C connections and dependencies can be quite
subtle (e.g. PLF usage). i can't say without checking but at some time
we, the original axiom developers, or i, when recovering axiom, thought
that it was needed. i could be wrong.

the only way to be sure is to eliminate it and then test.

\start
Date: Mon, 18 Sep 2006 15:07:29 +0200
From: Ralf Hemmecke
To: Bertfried Fauser
Subject: Re: Question concerning types...

Good that you join,

> a very interesting discussion! Perhaps you might enjoy reading 'The
> Skeleton Key' by Dudley E. Littlewood, where the nature of indeterminates
> is nicely contemplated.

Well, this "indefinite" (not indeterminate) is not my invention. I was 
just elaborating on what I believe I could be.

If you use "indeterminate" as the x in a univariate polynomial ring R[x] 
then (as I understand it) this is not the "indefinite" thing we are 
talking about. This x lives in R[x] but not in R.

Whoever wanted "indefinite things" should speak for himself, I only try 
to explain what I think they could be.

Of course it is possible to model indefinites by indeterminates, but you 
see that your domain now gets bigger. Indefinite integers are integers 
in every respect but the don't have a value (yet). In that sense the 
diagram is OK in my eyes.

But maybe the whole thing needs more elaboration.

>>From my point of view, could you please explain, why an indeterminate
> should behave like the original ring it was abstracted from. This is
> uncategorical.

If I understand the whole business correctly, then it is NOT an 
indeterminate.

> Would you agree that one should try to have say a Ring (integers) and
> another algebraic structure (indeterminates) which might have several
> attirbutes (associative, power associative, alternative, commutative,
> ring, group,....) and that one builds up a new algebra from the
> (semi/direct) product of the two algebraic structures at hand.

I think, I said something like that here.

http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00548.html

\start
Date: Mon, 18 Sep 2006 09:13:31 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: several images on one page

> Sorry, Tim, I am unable to find it.
> 
> Ralf
> 
> On 09/15/2006 05:28 AM, root wrote:
> >>> One of the outstanding problems I have to solve is how to place more
> >>> than one image on a page. That's the one blocking condition to
> >>> reproducing the Jenks book accurately.
> >> Without a clear problem description, nobody is able to help.
> > 
> > Check the email archives where I was asking for help.
> > 
> > I recently bought a book (The Latex Graphics Companion)
> > that appears to contain the solution. Now all I have to
> > do is get educated.

At various places in the Axiom (Jenks) book there are supposed to
be multiple images on the page. Nothing I tried would place an 
image where I wanted it. Images "float" and tend to move to the
previous or next page and I'm unable to stop this behavior.

If you're interested take a look at the Jenks book for a page
that contains multiple images and then look at the latex code
in src/doc. See if you can reproduce the multiple image page.

\start
Date: Mon, 18 Sep 2006 16:07:39 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: several images on one page

Hi Tim,

I see book.pamphlet and bookvol1.pamphlet in src/doc. What is what?

Actually, I finde it quite confusing that there are two files that look 
nearly identical on the first pages and then differ completely.

 From what I read in the Makefile, book.pamphlet is the file you want me 
to look at.

I have the original Axiom book on my desk and see (section 7.1.2) two 
graphics on page 183, but no graphic at all in section 7.1.2 in book.dvi.

Another point is that the original Axiom book is printed with a big 
margin that sometimes holds explanatory text. Seems that book.pamphlet 
is not the original source since that text on the top-left of page 183 
is not tagged as such. Do you still have the original source somewhere?

\start
Date: Mon, 18 Sep 2006 10:21:44 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: several images on one page

> I see book.pamphlet and bookvol1.pamphlet in src/doc. What is what?

book.pamphlet is the Jenks book.
boovol1.pamphlet is Axiom Volume 1, the Tutorial

> Actually, I finde it quite confusing that there are two files that look 
> nearly identical on the first pages and then differ completely.

All 10 planned volumes of the Axiom series will start out with the
same "look and feel". It's what book series like the 'for dummies'
or the O'Rielly series do.

>  From what I read in the Makefile, book.pamphlet is the file you want me 
> to look at.

Yes


> I have the original Axiom book on my desk and see (section 7.1.2) two 
> graphics on page 183, but no graphic at all in section 7.1.2 in book.dvi.

Because I couldn't put both graphics on the same page.
That's the problem I mentioned.
No matter what I do the graphics "float" to other pages.
I'm sure it is possible to do (since we did it) but I can make it work.


> Another point is that the original Axiom book is printed with a big 
> margin that sometimes holds explanatory text. Seems that book.pamphlet 
> is not the original source since that text on the top-left of page 183 
> is not tagged as such. Do you still have the original source somewhere?

No. I never got the original latex sources. The book was recreated by me 
by hand from multiple file sources. It took approximately 4 months.

Are you planning to be one the skype conference call?

\start
Date: Mon, 18 Sep 2006 09:38:57 -0500
From: Jay Belanger
To: list
Subject: re: several images on one page

Tim Daly writes:
...
> At various places in the Axiom (Jenks) book there are supposed to
> be multiple images on the page. Nothing I tried would place an
> image where I wanted it. Images "float" and tend to move to the
> previous or next page and I'm unable to stop this behavior.

In bookvol1.pamphlet, the figures all look like
 \begin{figure}[htbp]
 ...
 \end{figure}
If you start the placement specifier with an exclamation point,
 \begin{figure}[!htbp]
 ...
LaTeX will try extra hard to put the float where you ask.
Or, I suppose, there's no reason why the image has to be in a float;
you could just insert it where you want.

\start
Date: Mon, 18 Sep 2006 16:50:41 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: several images on one page

> At various places in the Axiom (Jenks) book there are supposed to
> be multiple images on the page. Nothing I tried would place an 
> image where I wanted it. Images "float" and tend to move to the
> previous or next page and I'm unable to stop this behavior.

> If you're interested take a look at the Jenks book for a page
> that contains multiple images and then look at the latex code
> in src/doc. See if you can reproduce the multiple image page.

I actually don't see a problem with having multiple pictures on one page.

The biggest problem is that AXIOM does not produce bounding boxes in the 
.ps file, so one must handcode that in the .tex file. (Which I have 
tried in the attached file.)

Hope that helps.

--------------060208020507040601010209
 name="rhxbook.pamphlet"
 filename="rhxbook.pamphlet"

\documentclass{book}
%\usepackage{axiom}
\usepackage{graphicx}
% struggle with latex figure-floating behavior
\renewcommand\floatpagefraction{.9}
\renewcommand\topfraction{.9}
\renewcommand\bottomfraction{.9}
\renewcommand\textfraction{.1}
\setcounter{totalnumber}{50}
\setcounter{topnumber}{50}
\setcounter{bottomnumber}{50}

% spadcommands are the actual text that you type at the axiom prompt
\newcommand{\spadcommand}[1]%
{\begin{flushleft}{\tt #1}\end{flushleft}\vskip .1cm }

% spadgraph are the actual text that you type at the axiom prompt for draw
\newcommand{\spadgraph}[1]%
{\begin{flushleft}{\tt #1}\end{flushleft}\vskip .1cm }

% returnType is the type signature returned by the axiom interpreter
\newcommand{\returnType}[1]%
{\begin{flushright}{\tt #1}\end{flushright}\vskip .1cm}

% spadsig gives the standard -> notation for signatures
\newcommand{\spadsig}[2]{{\sf #1 $\rightarrow$ #2}}

% The book begins with some introductory material that is not really
% listed as a chapter. This creates a header similar to \chapter.
\newcommand{\pseudoChapter}[1]%
{\vskip .5in \noindent {\Large{\bf #1}}\vskip .5in}

% The book begins with some introductory material that is not really
% listed as a section. This creates a header similar to \section.
\newcommand{\pseudoSection}[1]%
{\vskip .25in \noindent {\large{\bf #1}}\vskip .25in}

% spadofFrom records the operation in the index and the domain in the index
\newcommand{\spadopFrom}[2]{\index{library!operations!#1 @\begingroup \string\tt{} #1 \endgroup}\index{#2}``{\tt #1}''}

% spadfunFrom records the function name and domain in the index
\newcommand{\spadfunFrom}[2]{{\bf #1}\index{#1 @\begingroup \string\bf{} #1 \endgroup}\index{#2}}

% special meanings for math characters
\newcommand{\N}{\mbox{\bbold N}}
\newcommand{\Natural}{\mbox{\bbold N}}
\newcommand{\Z}{\mbox{\bbold Z}}
\newcommand{\Integer}{\mbox{\bbold Z}}
\newcommand{\Rational}{\mbox{\bbold Q}}
\newcommand{\Q}{\mbox{\bbold Q}}
\newcommand{\Complex}{\mbox{\bbold C}}
\newcommand{\C}{{\mathcal C}}
\newcommand{\Real}{\mbox{\bbold R}}
\newcommand{\F}{{\mathcal F}}
\newcommand{\R}{{\mathcal R}}

% draw a box around a text block
\newcommand\boxed[2]{%
\begin{center}
\begin{tabular}{|c|}
\hline
\begin{minipage}{#1}
\normalsize
{#2}
\end{minipage}\\
\hline
\end{tabular}
\end{center}}

\newcommand{\optArg}[1]{{{\tt [}{#1}{\tt ]}}}
\newcommand{\argDef}[1]{{\tt ({#1})}}
\newcommand{\funSyntax}[2]{{\bf #1}{\tt ({\small\it{#2}})}}
\newcommand{\funArgs}[1]{{\tt ({\small\it {#1}})}\newline}

\newcommand{\condata}[4]{{\bf #1} {\bf #2} {\bf #3} {\bf #4}}

\def\glossaryTerm#1{{\bf #1}\index{#1}}
\def\glossaryTermNoIndex#1{{\bf #1}}
\def\glossarySyntaxTerm#1{{\tt #1}\index{#1}}
\long\def\ourGloss#1#2{\par\pagebreak[3]{#1}\newline{#2}}
\def\csch{\mathop{\rm csch}\nolimits}

\def\erf{\mathop{\rm erf}\nolimits}

\def\zag#1#2{
  {{\hfill \left. {#1} \right|}
   \over
   {\left| {#2} \right. \hfill}
  }
}


% these bitmaps are used by HyperDoc
\newdimen\commentWidth 
\commentWidth=11pc
\newdimen\colGutterWidth 
\colGutterWidth=1pc
\newdimen\baseLeftSkip
\baseLeftSkip=\commentWidth \advance\baseLeftSkip by \colGutterWidth
\newcommand\ExitBitmap{{\setlength{\unitlength}{0.01in}\begin{picture}(50,16)(0,0)\special{psfile=ps/exit.ps}\end{picture}}}
\newcommand\ReturnBitmap{{\setlength{\unitlength}{0.01in}\begin{picture}(50,16)(0,0)\special{psfile=ps/home.ps}\end{picture}}}
\newcommand\HelpBitmap{{\setlength{\unitlength}{0.01in}\begin{picture}(50,16)(0,0)\special{psfile=ps/help.ps}\end{picture}}}
\newcommand\UpBitmap{{\setlength{\unitlength}{0.01in}\begin{picture}(50,16)(0,0)\special{psfile=ps/up.ps}\end{picture}}}
\newcommand{\tpd}[5]{{\setlength{\unitlength}{0.01in}\begin{picture}(#1,#2)(#3,#4)\special{psfile=#5}\end{picture}}}

\begin{document}




\section{Two-Dimensional Graphics}
\label{ugGraphTwoD}

The Axiom two-di\-men\-sion\-al graphics package provides the ability
to \index{graphics!two-dimensional} display
\begin{itemize}
\item curves defined by functions of a single real variable
\item curves defined by parametric equations
\item implicit non-singular curves defined by polynomial equations
\item planar graphs generated from lists of point components.
\end{itemize}

These graphs can be modified by specifying various options, such as
calculating points in the polar coordinate system or changing the size
of the graph viewport window.

\subsection{Plotting Two-Dimensional Functions of One Variable}
\label{ugGraphTwoDPlot}

\index{curve!one variable function} The first kind of
two-di\-men\-sion\-al graph is that of a curve defined by a function
$y = f(x)$ over a finite interval of the $x$ axis.

\boxed{4.6in}{
\vskip 0.1cm
The general format for drawing a function defined by a formula $f(x)$ is:
\begin{center}
{\tt draw(f(x), x = a..b, {\it options})}
\end{center}

where $a..b$ defines the range of $x$, and where {\it options}
prescribes zero or more options as described in
\ref{ugGraphTwoDOptions} on page~\pageref{ugGraphTwoDOptions}.  An
example of an option is $curveColor == bright red().$ An alternative
format involving functions $f$ and $g$ is also available.\\
}

A simple way to plot a function is to use a formula.  The first
argument is the formula.  For the second argument, write the name of
the independent variable (here, $x$), followed by an ``{\tt =}'', and the
range of values.

Display this formula over the range $0 \leq x \leq 6$.
Axiom converts your formula to a compiled function so that the
results can be computed quickly and efficiently. 

\spadgraph{draw(sin(tan(x)) - tan(sin(x)),x = 0..6)}
\begin{figure}[htbp]
{\rm draw(sin(tan(x)) - tan(sin(x)),x = 0..6)\\}
\vskip 0.2cm
\includegraphics[scale=0.5,bb=0 0 300 300]{ps/2D1VarA.ps}
\caption{$sin(tan(x)) - tan(sin(x))\ \ \ x = 0 \ldots6$}
\end{figure}
{\rm
\par
Notice that Axiom compiled the function before the graph was put
on the screen.

Here is the same graph on a different interval.\\

draw(sin(tan(x)) - tan(sin(x)),x = 10..16)\\
}
\vskip 0.2cm
\spadgraph{draw(sin(tan(x)) - tan(sin(x)),x = 10..16)}
\begin{figure}[htbp]
\includegraphics[scale=0.5,bb=0 0 400 400]{ps/2D1VarB.ps}
\caption{$sin(tan(x)) - tan(sin(x))\ \ \ x = 10 \ldots16$}
\end{figure}

Once again the formula is converted to a compiled function before any
points were computed.  If you want to graph the same function on
several intervals, it is a good idea to define the function first so
that the function has to be compiled only once.

This time we first define the function.
\spadcommand{f(x) == (x-1)*(x-2)*(x-3) }
%\begin{figure}
\includegraphics[scale=0.3,bb=0 0 300 300]{ps/2D1VarD.ps}
%\end{figure}
\returnType{Type: Void}
\includegraphics[scale=0.4,bb=14 14 188 199]{ps/2D1VarD.ps}
%\hspace*{\baseLeftSkip}\special{psfile=ps/2Dctrl.ps}

To draw the function, the first argument is its name and the second is
just the range with no independent variable.
\spadgraph{draw(f, 0..4) }
% window was 300 x 300
\includegraphics[scale=0.3,bb=0 0 295 295]{ps/2D1VarD.ps}

\end{document}

\start
Date: Mon, 18 Sep 2006 12:01:42 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Question concerning types...

On September 18, 2006 7:24 AM Ralf Hemmecke wrote:
>
> > Ralf Hemmecke wrote:
> >> I agree with you [Gaby] that if D had type T then Variable(D)
> >> should have type T (plus maybe some exports that allow to
> >> create "indeterminates").
> > 
> Bill Page wrote: 
> > The meaning of this statement is unclear to me. Do you mean:
> > If D has category T then Variable(D) should have category T?
> > If so, I would disagree. Variable(D), as a universal algebra
> > over some symbols must have a different (but related) type,
> > perhaps Variable(D) has Universal(T)?
> 
> Let's make it simple. Integer is a Ring. Don't you want that
> Integer together with "indefinite integers" also form a ring?

Yes. At least a Ring but it will also be something else as you
said parenthetically above "plus maybe some exports that allow to
create indeterminates".

> I don't think that I would want Universal(Ring). What is
> Universal, by the way?

It is some category constructor that I was imagining might be
definable. This constructor adds the required additional exports.

> 
> I understand that "indefinite" thing just as a way to encode 
> a delayed evaluation. In the "computation" that is done just
> with the type information, you can do any tricks that you can
> do with that information, but if that computation needs a value,
> it has to wait until I provide one.

I am not sure how to distinquish "tricks" from "computation".
Perhaps you mean purely symbolic manipulation of expressions
versus the appliction of algebraic operators defined by some
underlying domain?

What you call "delayed evaluation" (in a computer science sense)
has something to do with universal algebra in a a mathematical
sense. We need a mathematics (algebra) "large enough" to express
this notion.

> The point is, that you cannot apply an arbitrary operation on
> these indefinite objects. For example if I have a very restricted
> scope and not / operation can be seen then the compiler should
> reject to compile a/b for indefinite integers a and b.
> 

Yes, but that is generally true of Axiom's algebra.

> ...
> >>
> >> Mathematically, that's not a big deal. But Aldor domains are
> >> actually multi-sorted algebras. That makes the situation a little
> >> more complicated.
> 
> > I think sometimes you think too much about Aldor and not enough
> > about Axiom... ;)
> 
> I don't think that my statement is much related to Aldor. You could 
> replace Aldor by Axiom or SPAD, if you like. So what did you 
> actually mean?
>

What I meant was that you should look at how the algebra (such as
Expression) is implemented in Axiom now. I would prefer to replace
Aldor by SPAD for the purposes of this dicussion since Axiom's
algebra is currently implemented in SPAD even though we are
generally confident that it can be re-written in Aldor.
 
> ... 
> > The interesting thing to me is that all you appear to be doing here
> > is "re-inventing" the Expression domain constructor.
> > 
> > It seems to me that 'Expression(Integer)' is a good enough name. :-)
> 
> But inside Expression(Integer) the variables have NO type information 
> attached.

You understand that instead of talking about Expression(Integer), as
long as we do not introduce any functions, we can use instead just
Polynomial, right? (Substituting EXPR for POLY below gives the same
result.) But if we talk about POLY, it's implementation is already
clear in Aldor.

In Axiom I can write:

(1) -> a1:POLY INT
       Type: Void

(2) -> a1:=1

   (2)  1
        Type: Polynomial Integer

(3) -> a1:=1.1

   Cannot convert right-hand side of assignment 1.1
   to an object of the type Polynomial Integer of the left-hand
   side.

I want to think of 'a1' as the "typed variable". We can write:

(3) -> a2:POLY INT
       Type: Void

(4) -> (a1+a2)@POLY(INT)

   (4)  a2 + 1
   Type: Polynomial Integer

But

(5) -> (a1/a2)@POLY(INT)

   An expression involving @ Polynomial Integer actually evaluated to
   one of type Fraction Polynomial Integer . Perhaps you should use
   :: Polynomial Integer .

-----------

I used '@POLY(INT)' because I wanted to tell the Axiom interpreter not
to look of other coercions which would have made the interpretation
of '/' possible but no longer in 'POLY INT'.

Should we say that 'a1' represents an indefinite integer? Tentatively,
I think so.

> 
> > I strongly recommend that you take a close look at how Expression
> > is implemented in the Axiom library.
> 
> Thank you. But Expression is not what solves the "indefinite"
> problem.

You are right. Expression is too general. Not all objects in
'Expression Integer' evaluate to Integer. How about 'Polynomial
Integer'? Maybe it is to restrictive and we could admit at least
some other expressions not in 'Polynomial Integer' which do
evaluate to Integer?

> 
> > 'sin(a1)' which are not evaluated any further in the Expression
> > domain.
> 
> OK, let's take
> 
> n: Expression Integer := n
> z := sin(2* %Pi * n)
> 
> Axiom knows, in fact, nothing about the n. But if it really 
> knew that n is an Integer, it could simplify z to 0.
> 
> That should be a test case for indefinite computation.

I do not agree that Axiom knows nothing about n. It knows for
example that a1 has been assigned a value but that a2 has not.

(6) -> )di prop a1
Properties of a1 :
   Declared type or mode:   Polynomial Integer
   Value (has type Polynomial Integer):  1
(6) -> )di prop a2
Properties of a2 :
   Declared type or mode:   Polynomial Integer

---------

I agree that Axiom should be able to simplify

   z := sin(2* %Pi * a2)

to 0 (where a2 is any polynomial with integer coefficients). But
Axiom does not even simplify

   z := sin(2* %Pi)

to 0. When should such a simplification take place? In general
Axiom's 'simplify' operations are quite weak.

> ...
> > 
> > I don't understand. Obviously Expression is a domain that the
> > SPAD compiler understands. Implementing Expression in Aldor
> > should be quite straight forward.
> 
> Of course the Expression type is known. But is should not be
> built-in into the compiler. It should live in a library.
> 

??? Expression is not "built-in" to the SPAD compiler.

\start
Date: Mon, 18 Sep 2006 10:49:42 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Question concerning types...

Sorry in advance if this question is a bit daft...

--- Bill Page wrote:

> I used '@POLY(INT)' because I wanted to tell the Axiom interpreter
> not to look of other coercions which would have made the
> interpretation of '/' possible but no longer in 'POLY INT'.
> 
> Should we say that 'a1' represents an indefinite integer?
> Tentatively, I think so.

Does this mean that an indefinite integer couldn't be substituted in
anywhere a "definite" integer could be used?

\start
Date: Mon, 18 Sep 2006 14:15:49 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Question concerning types...

On September 18, 2006 1:50 PM C Y wrote:
> 
> Sorry in advance if this question is a bit daft...
>

Not at all. There is not such thing as a daft question -
however always keep in mind that the same is not true of
answers. :-)
 
> --- Bill Page wrote:
> 
> > I used '@POLY(INT)' because I wanted to tell the Axiom interpreter
> > not to look of other coercions which would have made the
> > interpretation of '/' possible but no longer in 'POLY INT'.
> > 
> > Should we say that 'a1' represents an indefinite integer?
> > Tentatively, I think so.
> 
> Does this mean that an indefinite integer couldn't be substituted in
> anywhere a "definite" integer could be used?
> 

No. The issue here is that what we want to call "indefinite integer"
has to come from some domain in Axiom. My proposal is that to define
this in algebraic terms what we need is a domain like Polynomial which
consists of some symbols and expressions (of a specific kind) over
these symobls. So it is clear, right? that the type

  Polynomial Integer

consists of a large clase of expressiions of that type. And saying

  a1:Polynomial Integer

is just a way of saying that the variable a1 will take values from
this domain.

But because the coefficients of the polynomial must come from the
domain Integer we know that these Integers are embedded in this class
of expressions as polynomials of degree 0, so we have no problem
specifying that a certain variable suchs as 'a1' is exact such an
integer (polynomial of degree 0).

In general both Integer and Polynomial Integer has Ring so, yes
it is true that Polynomial Integer can be used in (most) places
where would like to use Integer (but were no specific value is
required).

The only concern I have is whether or not Polynomial Integer is
"big enough" to model everything that we would want to mean by
"indefinite integer".

\start
Date: Mon, 18 Sep 2006 14:58:34 -0400
From: Tim Daly
To: list
Subject: Axiom Conference Call Sept 18, 2006

Participants: Kai Kaminski, Gabriel Dos Reis, Bill Page, Tim Daly
Start: 1pm
End: 2pm

1) Bill looked into the details of SVN/SVK on axiom-developer.org
   but has not yet succeeded in building an installation. 

2) Tim looked at porting Axiom to the MAC. 

   There is an outstanding GCL issue. GCL save-system cannot save
   images that will execute successfully. 

   Bill suggested trying to use compiler-link instead.
   This will be investigated.

3) Tim spent time this weekend looking into Martin's build issues
   without success.

   Suggestion that Jose send a diff of his changes to --patch-50
   so Tim can see what approach he was taking

4) The multiple-image-per-page issue with the original book was discussed.
   Kai suggested fixing the postscript files so they all contain the
   bounding box. Tim didn't think that was going to affect the floating
   issue in Latex but Tim was going to review it anyway.

5) Indefinites. 

   Tim mentioned that indefinites could be done using provisos.

   Bill objected that provisos was a proof-theoretic approach
   and that an algebraic approach might be more axiom-like.
   Thus, express Indefinite(Integer) as a Poly(Int) domain if there
   was sufficient coverage.

   Kai thought that both approaches were needed.

6) Kai has a student who wants to work on provisos.
   Tim agreed to share work with the student.

7) Tim did not yet recover the solaris changes.

   Bill pointed out that the solaris port could happen in two
   different environments, a standard solaris and a solaris with
   the GNU tool chain. He feels that the Build-improvements path
   would be more fine-grained rather than the global decision
   approach used by Gold. Thus the solaris port work is better
   left to Build-improvments.

8) Bill tried to build GCL-2.6.8pre on Windows without success.
   He points out that the older versions of GCL will no longer
   build and the fault is likely somewhere in his build setup.

9) Google objects to having binaries in the zips directory.
   It was agreed that since Google was only a method of getting
   around the breakage of Sourcforge SVN and that we plan to put
   SVN on axiom-developer therefore we should ignore Google going
   forward.

10) Gaby pointed out that SVK was more efficient than SVN
    Bill will look at SVK in more detail. There appears to be a
    Perl dependency that is at issue.

    Bill and Gaby will pursue this offline.

Tim will be generally unavailable until next monday evening.
The next scheduled conference call will be announced later.

\start
Date: Mon, 18 Sep 2006 15:54:45 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Question concerning types...

> 
> On September 18, 2006 1:50 PM C Y wrote:
> > 
> > Sorry in advance if this question is a bit daft...
> >
> 
On September 18, 2006 2:16 PM I wrote:
> Not at all. There is not such thing as a daft question -
> however always keep in mind that the same is not true of
> answers. :-)
>

I am afraid that what I wrote below might be a good example of
a "daft answer" - even if it is in the right spirit... :(

This idea needs more work. On 2nd thought what I wrote below
does not make good sense as it stands. Maybe this is better:


(2) -> a1:MPOLY([a1,a2],INT)
       Type: Void

(3) -> a2:MPOLY([a1,a2],INT)
       Type: Void

(4) -> a1+a2

   (4)  a1 + a2
        Type: MultivariatePolynomial([a1,a2],Integer)

This way it is clear that there are no indeterminants that are
not integers.

Regards,
Bill Page.

> > --- Earlier I wrote:
> ...
> My proposal is that to define this in algebraic terms what we
> need is a domain like Polynomial which consists of some symbols
> and expressions (of a specific kind) over these symobls. So it
> is clear, right? that the type
> 
>   Polynomial Integer
> 
> consists of a large clase of expressiions of that type. And saying
> 
>   a1:Polynomial Integer
> 
> is just a way of saying that the variable a1 will take values from
> this domain.
> 
> But because the coefficients of the polynomial must come from the
> domain Integer we know that these Integers are embedded in this class
> of expressions as polynomials of degree 0, so we have no problem
> specifying that a certain variable suchs as 'a1' is exact such an
> integer (polynomial of degree 0).
> 
> In general both Integer and Polynomial Integer has Ring so, yes
> it is true that Polynomial Integer can be used in (most) places
> where would like to use Integer (but were no specific value is
> required).
> 
> The only concern I have is whether or not Polynomial Integer is
> "big enough" to model everything that we would want to mean by
> "indefinite integer".

\start
Date: Mon, 18 Sep 2006 16:14:36 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: Axiom Conference Call Sept 18, 2006

> 9) Google objects to having binaries in the zips directory.
>    It was agreed that since Google was only a method of getting
>    around the breakage of Sourcforge SVN and that we plan to put
>    SVN on axiom-developer therefore we should ignore Google going
>    forward.

Should the project be deleted from: http://code.google.com/p/axiom/ ?

\start
Date: 18 Sep 2006 22:13:47 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom Conference Call Sept 18, 2006

Many thanks for posting the summary of the conference.

Below I add a small precision.

Tim Daly writes:

[...]

| 5) Indefinites. 
| 
|    Tim mentioned that indefinites could be done using provisos.
| 
|    Bill objected that provisos was a proof-theoretic approach
|    and that an algebraic approach might be more axiom-like.
|    Thus, express Indefinite(Integer) as a Poly(Int) domain if there
|    was sufficient coverage.
| 
|    Kai thought that both approaches were needed.
| 
| 6) Kai has a student who wants to work on provisos.
|    Tim agreed to share work with the student.

in both case, I think it was Gaby, not Kai :-)

[...]

| Tim will be generally unavailable until next monday evening.

\start
Date: Mon, 18 Sep 2006 22:55:44 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Question concerning types...

>> I understand that "indefinite" thing just as a way to encode 
>> a delayed evaluation. In the "computation" that is done just
>> with the type information, you can do any tricks that you can
>> do with that information, but if that computation needs a value,
>> it has to wait until I provide one.
> 
> I am not sure how to distinquish "tricks" from "computation".

Of course, no distiction.

> What you call "delayed evaluation" (in a computer science sense)
> has something to do with universal algebra in a a mathematical
> sense. We need a mathematics (algebra) "large enough" to express
> this notion.

Right. Let's make it clearer. Suppose we just take one operation. For 
simplicity let's take +. Let's take the Integers Z as a carrier set and 
define the universal algebra U = (Z, +) where + works on Z as usual. Let 
us introduce just one indefinite integer x. That means we form
(Z', +') where Z' is a superset of Z and +' restricted to Z is +.
Z' is the term algebra constructed from
Z union {x}  and the function symbol +'
where it is understood that u+'v is always replace by the actual integer 
sum u and v if they are both elements of Z.

If you want more indefinite integers, then iterate that process.

Who would be satisfied with such a way of modelling indefinite integers 
and who would not?

But note that Integer also has a operation zero?: Integer -> Boolean. So 
Z' should also deal with that. But we all know that Aldor/Axiom/SPAD 
domains are not just universal algebras but multisorted.

> What I meant was that you should look at how the algebra (such as
> Expression) is implemented in Axiom now.

I think the Expression constructor is a clever thing. In particular, 
here at RISC are several people who deal with symbolic summation. There 
one analyzes the (Mathematica) expression and basically forms a rational 
function domain which is basically something like Expression(Integer) is 
in Axiom.

>>> The interesting thing to me is that all you appear to be doing here
>>> is "re-inventing" the Expression domain constructor.
>>>
>>> It seems to me that 'Expression(Integer)' is a good enough name. :-)
>> But inside Expression(Integer) the variables have NO type information 
>> attached.
> 
> You understand that instead of talking about Expression(Integer), as
> long as we do not introduce any functions, we can use instead just
> Polynomial, right?

Yes, of course.

 > (Substituting EXPR for POLY below gives the same
> result.) But if we talk about POLY, it's implementation is already
> clear in Aldor.

Don't worry, I can read SPAD, but it's terribly more complicated than 
Aldor for me.

> In Axiom I can write:
> 
> (1) -> a1:POLY INT
>        Type: Void
> 
> (2) -> a1:=1
> 
>    (2)  1
>         Type: Polynomial Integer
> 
> (3) -> a1:=1.1 m
> 
>    Cannot convert right-hand side of assignment 1.1
>    to an object of the type Polynomial Integer of the left-hand
>    side.
> 
> I want to think of 'a1' as the "typed variable". We can write:
> 
> (3) -> a2:POLY INT
>        Type: Void
> 
> (4) -> (a1+a2)@POLY(INT)
> 
>    (4)  a2 + 1
>    Type: Polynomial Integer
> 
> But
> 
> (5) -> (a1/a2)@POLY(INT)
> 
>    An expression involving @ Polynomial Integer actually evaluated to
>    one of type Fraction Polynomial Integer . Perhaps you should use
>    :: Polynomial Integer .
> 
> -----------
> 
> I used '@POLY(INT)' because I wanted to tell the Axiom interpreter not
> to look of other coercions which would have made the interpretation
> of '/' possible but no longer in 'POLY INT'.
> 
> Should we say that 'a1' represents an indefinite integer? Tentatively,
> I think so.

Well, I would agree, if the interpreter knows how to deal with such 
"programming variables" that have no values, but neither SPAD nor Aldor 
understand that.

Have you ever typed

foo(n: Integer): Expression Integer == (k: Expression(Integer); n*k)
foo 1

into Axiom? (Save your session before doing it.)

>> But Expression is not what solves the "indefinite" problem.
> 
> You are right. Expression is too general. Not all objects in
> 'Expression Integer' evaluate to Integer.

No, that is not the problem. Assume that a1 is an indefinite integer.
zero?(a1) shouldn't evaluate to Integer. The point is that although you 
don't know the value of a1, the interpreter/compiler should only allow 
you to write foo(a1) if there is a function

foo: Integer -> SomeResultType

and otherwise tell you that you are doing nonsense. Note that in 
Expression(Integer) you can apply any function to a "kernel" since no 
type information is available. And another difference is: If a1 is an 
indefinite integer and e1 is an indefinite expression involving a1 then 
although you have no value, it is completely clear what type the result 
will have if you plug in a certain integer for a1 into e1. For an 
arbitrary expression from Expression(Integer) you cannot do that.

 > How about 'Polynomial
> Integer'? Maybe it is to restrictive and we could admit at least
> some other expressions not in 'Polynomial Integer' which do
> evaluate to Integer?

Why do you think an expression/polynomial that involves indefinite 
integers must evaluate to an integer? zero?(a1) would evaluate to 
Boolean, and that would be perfectly fine for me.

>> OK, let's take
>>
>> n: Expression Integer := n
>> z := sin(2* %Pi * n)

>> Axiom knows, in fact, nothing about the n. But if it really 
>> knew that n is an Integer, it could simplify z to 0.

>> That should be a test case for indefinite computation.

> I do not agree that Axiom knows nothing about n. It knows for
> example that a1 has been assigned a value but that a2 has not.

> (6) -> )di prop a1
> Properties of a1 :
>    Declared type or mode:   Polynomial Integer
>    Value (has type Polynomial Integer):  1
> (6) -> )di prop a2
> Properties of a2 :
>    Declared type or mode:   Polynomial Integer

But that is the interpreter and not SPAD itself.

> ---------
> 
> I agree that Axiom should be able to simplify
> 
>    z := sin(2* %Pi * a2)
> 
> to 0 (where a2 is any polynomial with integer coefficients).

No! That would be WRONG.
Assume that the polynomial domain is Z[x] 
SparseUnivariatePolynomial(Integer). And let f: Z[x] -> Q be the 
homomorphism of rings that maps Z[x] to the rational numbers 
(Fraction(Integer)). f should map x to 1/4. Now assume that a2=x.

sin(%Pi * a2) does not simplify to 0 in general. But if the interpreter 
"knows" that a2 is an integer, the simplification is safe.

\start
Date: Mon, 18 Sep 2006 23:22:43 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Question concerning types...

Ah... I forgot to say... if ever indefinite integers come to life then a 
syntax like

i: Integer

would be quite acceptable/preferrable.

Maybe I am wrong, but is there use for indefinite integers in library 
code or is that rather a use case for an interactive session?

If it's only for an interactive session, then I believe the interpreter 
should be made so smart to deal with "programming variables" (like the i 
above) that have no values as indefinite objects.

Note that even if SingleInteger just has 32 bits to store a value, the 
interpreter adds some knowledge anyway (name of the variable that holds 
the SingleInteger, the type of the value, etc.). So it would be simple 
for the interpreter to add another bit saying that this particular 
variable does not have a value.

If I look at

(1) -> n: Integer
 
Type: Void
(2) -> sin(2*%Pi*n)

    n is declared as being in Integer but has not been given a value.

then I believe the interpreter already does that. It just is not smart 
enough to apply the information it has.

\start
Date: Mon, 18 Sep 2006 18:52:21 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: Axiom Conference Call Sept 18, 2006

> 3) Tim spent time this weekend looking into Martin's build issues
>    without success.
>
>    Suggestion that Jose send a diff of his changes to --patch-50
>    so Tim can see what approach he was taking
>

Well, I just finished building using patch-49 as Bill suggested me.
Hyperdoc worked fine after doing just one step, which using patch-50
it was breaking for me (I am really sorry Martin :-( ). I would like to
know if Martin was using patch-49, that can also confirm the but if
there is any.

So my steps were as indicated by Martin:

1) Copy the files I sent you (i.e., mantepse.spad.pamphlet, fffg.spad.pamphlet,
  rec.spad.pamphlet, Makefile.pamphlet, exposed.lsp.pamphlet) into

  GoldenAxiom/src/algebra

(files are attached to this email).

2) edit Makefile.pamphlet as follows: replace

<<USERLAYER>>=

USERLAYER=\
 ${OUT}/FAMR2.o   \
 ${OUT}/FFFG.o    \
 ${OUT}/FFFGF.o   \
 ${OUT}/NEWTON.o  \
 ${OUT}/RECOP.o   \
 ${OUT}/UFPS.o    \
 ${OUT}/GOPT.o    \
 ${OUT}/UFPS1.o   \
 ${OUT}/GOPT0.o   \
 ${OUT}/GUESS.o   \
 ${OUT}/GUESSINT.o \
 ${OUT}/GUESSF1.o \
 ${OUT}/GUESSF.o  \
 ${OUT}/GUESSP.o
@

by

USERLAYER=\
 ${OUT}/FAMR2.o   \
 ${OUT}/FFFG.o    \
 ${OUT}/NEWTON.o  \
 ${OUT}/RECOP.o   \
 ${OUT}/UFPS.o    \
 ${OUT}/GOPT.o    \
 ${OUT}/GUESSF1.o
@

3) build axiom (i.e., go to Goldenaxiom, say ./configure, do what configure
  tells you to, say make)

Using patch 50 at this point Hyperdoc doesnt work anymore.

\start
Date: Mon, 18 Sep 2006 16:06:16 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke,
Subject: Re: Question concerning types...

> Ah... I forgot to say... if ever indefinite integers come to life
> then a  syntax like
> 
> i: Integer
> 
> would be quite acceptable/preferrable.
> 
> Maybe I am wrong, but is there use for indefinite integers in library
> code or is that rather a use case for an interactive session?

One possibility that occurs to me is the definition of physics
equations, which might be able to make good use of indefinites. 
Looking at what Feyncalc would need to be workable in Axiom is probably
a good starting point to determine if indefinites would be useful in a
library.  Checking user defined Maple and Mathematica packages might
also be of interest.

\start
Date: Tue, 19 Sep 2006 01:24:53 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: equal or unequal

On 09/18/2006 01:21 PM, Gabriel Dos Reis wrote:
> Ralf, for an integral domain D, Quotient(Quotient(D)) = Quotient(D),
> where Quotient is the "quotient field functor".

If = means "are isomophic as fields" then I agree. If = means 
"identical" then I don't agree. I don't even agree that it exists *THE* 
"quotient field functor". A lot of things in mathematics are "equal" up 
to isomorphism. Whether a person wants to see something as equal or not 
very much depends on his/her focus.

> | Very often we say something like
> | 
> |    By abuse of notation we identify n and the class  [(n,0)] in Z and
> |    simply write n\in Z.
> | 
> | I haven't seen any computer algebra system that has addressed such
> | "abuse of notation".

> think "coerce".

In Axiom I can say

z: Integer := 1
q: Fraction Integer := 1
b: Boolean := z = q

in SPAD I would have to say

b: Boolean := (z :: Fraction(Integer)) = q

for the last line.

So in some sense Axiom addresses this "abuse of notation" issue.
And it "supports" it by forbidding me to define two functions

---BEGIN aaa.input
foo(x: Integer): Boolean == true
foo(y: Fraction Integer): Boolean == false
---END aaa.input

)clear all
)read aaa.input
(3) -> foo(1$Integer)
    Compiling function foo with type Fraction Integer -> Boolean

    (3)  false

(4) -> foo(1$Fraction(Integer))

    (4)  false


Whereas SPAD allows it.

---BEGIN bbb.spad
)abbrev package RHXPKG RHxPkg

RHxPkg(): with
   foo: Integer -> Boolean
   foo: Fraction Integer -> Boolean
  == add
   foo(x: Integer): Boolean == true
   foo(y: Fraction Integer): Boolean == false
---END bbb.spad

)clear all
)co bbb.spad
(1) -> foo(1$Integer)
    Loading /home/hemmecke/scratch/RHXPKG.NRLIB/code for package RHxPkg

    (1)  true

(2) -> foo(1$Fraction(Integer))

    (2)  false

So, that is an instance of where the interpreter give different results 
than the code that SPAD compiles.
(BTW, is it possible to do without wrapping the functions by a package 
in the SPAD code?)

> Now, a practical issue is whether I would want that
> corce to be built-in or library.

I never want it built-in. Only the interpreter could be allowed (as it 
is now) to apply certain coercions.

> | What is THE mathematical interpretation?
> 
> anyone in any algebra book I've read so far.

Interesting that some mathematicians think that 0 is a natural number 
and some don't. But maybe you apply an indeterministic interpretation 
function. ;-)

> dependent types will depend on *values*, not just syntactic objects.
> Consequently, when you compare types, you don't just compare them on
> syntax, but on their canonical values.

> Fraction is idempotent for integral domains.

Hopefully, the programmer who implemented Fraction knew that.

---BEGIN aaa.spad
)abbrev package RHXPKG2 RHxPkg2
F ==> Fraction
Z ==> Integer
RHxPkg2(): with
   tst: (Z, Z) -> OutputForm
  == add
   tst(a: Z, b: Z): OutputForm ==
     p: F Z := a/3
     q: F Z := b/7
     ffz: F F Z := p / q
     ((numer ffz) :: OutputForm) / ((denom ffz)::OutputForm)
---END aaa.spad

)co aaa.spad
(1) -> tst(1,2)

          7
          -
          6
    (1)  ---
          1

> | > | Although I had even given code to do that, I believe it should
> | > | not be implemented that way. Because an element that looks like
> | > | (2/1)/(3/1) is NOT identical to 2/3.
> | 
> | > By the same token we should prevent Axiom from simplifying 3+2 to 5.
> | 
> | You are mixing things. Let's suppose 3, 2, 5 are from Integer. Then
> | there is +: (Integer, Integer) -> Integer. So we can simply apply that
> | function to 3 and 2. Why would you forbid that?
> 
> I would not.  I'm just using the same logic you used to say that
> (2/1)/(3/1) is NOT identical to 2/3.

It is not the same logic. The / in the middle of (2/1)/(3/1) is a 
different function from the other two /. I am sure you have heard of 
operator overloading.

> | The above is different.
> | 
> | First let's make it equal. If you type (2/1) and (3/1) they are of
> | type Fraction Integer. Fraction Integer is a field and allows the
> | operation /: (%, %) -> %. So that operation can be applied and yields
> | 2/3.
> | 
> | Now make it different. If I interpret the second / in (2/1)/(3/1) as
> | /$Fraction(Fraction Integer) (note that Fraction(S) has an operation
> | /:(S,S)->%), then (2/1)/(3/1) is simply an element of
> | Fraction(Fraction(Integer)) and is not equal to 2/3 because it has a
> | different type.
> 
> that is a weakness, non-sense in the "type system", not anything
> fundamentally, and mathematically, meaningful.

OK. We disagree.

> Assume you have thaught the system to understand that Fraction is
> idempotent on integral domains.  Why would you still have that problem?

If the system knew that Fraction were idempotent, then no problem. But 
see the code in RHXPKG2. Fraction in the Axiom library code is not 
idempotent.

> As I said, I want the system powerfull enough to understand algebraic
> properties, in particular idempotency.  Also, think of commuting
> constructors, that is another area where you have lot of troubles.
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Are we discussing system matters or personal issues?

\start
Date: Mon, 18 Sep 2006 20:03:54 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Axiom Conference Call Sept 18, 2006

On September 18, 2006 6:52 PM you wrote:
> 
> Well, I just finished building using patch-49 as Bill suggested me.
> Hyperdoc worked fine after doing just one step, which using patch-50
> it was breaking for me (I am really sorry Martin :-( ). I would like
> to know if Martin was using patch-49, that can also confirm the but
> if there is any.
>
> So my steps were as indicated by Martin:
> ... 
> Using patch 50 at this point Hyperdoc doesnt work anymore.
> 

So, just to confirm: if you follow all 10 of Martin's steps starting
with patch-49 do you obtain a working version of Axiom including
Hyperdoc and graphics?

If so, I guess we had better worry about what else might be wrong in
patch-50. Since AXIOMsys works in patch-50 (so far as we know) but
hyperdoc and graphics both fail, that should be a clue but the
interaction with Martin's modified build procedure is still entirely
unclear to me.

\start
Date: Mon, 18 Sep 2006 22:19:00 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Question concerning types...

> On September 18, 2006 12:02 PM Bill Page wrote:
> ...
> > What you call "delayed evaluation" (in a computer science sense)
> > has something to do with universal algebra in a a mathematical
> > sense. We need a mathematics (algebra) "large enough" to express
> > this notion.
> 

On September 18, 2006 4:56 PM Ralf Hemmecke wrote:
> Right. Let's make it clearer. Suppose we just take one operation.
> For simplicity let's take +. Let's take the Integers Z as a 
> carrier set and define the universal algebra U = (Z, +) where
> + works on Z as usual. Let us introduce just one indefinite integer
> x. That means we form (Z', +') where Z' is a superset of Z and +'
> restricted to Z is +. Z' is the term algebra constructed from
> Z union {x}  and the function symbol +' where it is understood
> that u+'v is always replace by the actual integer sum u and v if
> they are both elements of Z.
> 
> If you want more indefinite integers, then iterate that process.
> 
> Who would be satisfied with such a way of modelling indefinite
> integers and who would not?

I am very well satisfied with what you wrote above. :-)

> ... 
> > In Axiom I can write:
> > 
> > (1) -> a1:POLY INT
> >        Type: Void
> > ... 
> > Should we say that 'a1' represents an indefinite integer? 
> > Tentatively, I think so.
> 
> Well, I would agree, if the interpreter knows how to deal with
> such "programming variables" that have no values, but neither
> SPAD nor Aldor understand that.

I disagree with the term "programming variable" and also that
SPAD and Aldor do not understand this. And I now also disagree
with my tentative conclusion above: 'a1' is *not* a very good
model for an indefinite integer.

> 
> Have you ever typed
> 
> foo(n: Integer): Expression Integer ==
>   (k: Expression(Integer); n*k)
> foo 1
> 
> into Axiom? (Save your session before doing it.)
>

What I get is "memory may be damaged". This is quite understandable
since k is local to the function and you are trying to use it
as part of an Expression that is returned to the main line. Try this
instead:

(1) -> k: POLY(Integer)
       Type: Void
(2) -> foo(n: Integer): POLY Integer == (n*k)
   Function declaration foo : Integer -> Polynomial Integer has been
      added to workspace.
       Type: Void
(3) -> foo 1
   Compiling function foo with type Integer -> Polynomial Integer

   (3)  k
        Type: Polynomial Integer
 
> >> But Expression is not what solves the "indefinite" problem.
> > 
> > You are right. Expression is too general. Not all objects in
> > 'Expression Integer' evaluate to Integer.
> 
> No, that is not the problem.
> ...

You are right, most of the rest of what I wrote in that email
is wrong. :(

I think the only thing I can salvage from my thoughts so far in
this thread is that in Axiom "indefinite integers" need to be
members of some domain and that domain is not so different from
'Polynomial Integer' but there needs to be some more specific
structure.

Right now I am thinking:

(1) -> a:MPOLY([a],INT)

looks like the kind of universal algebra that you describe above.
Clear MPOLY([a],INT) is a superset of INT and +$MPOLY([a],INT)
extends +$INT in an appropriate way.

Consider:

(2) -> a1:MPOLY([a1,a2],INT)
       Type: Void

(3) -> a2:MPOLY([a1,a2],INT)
       Type: Void

for example as a possible representation of such a domain involving
two indefinite integers.

\start
Date: Tue, 19 Sep 2006 02:39:43 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Axiom Conference Call Sept 18, 2006

> So, just to confirm: if you follow all 10 of Martin's steps starting
> with patch-49 do you obtain a working version of Axiom including
> Hyperdoc and graphics?

Yes. I just finished a new trial again with 49 and 50 at the same time.
50 breaks, 49 doesn't. I hope somebody can reproduce this.

\start
Date: Tue, 19 Sep 2006 12:06:38 +0200
From: Kai Kaminski
To: Tim Daly
Subject: Re: Axiom Conference Call Sept 18, 2006

Sorry for disappearing suddenly, my internet connection went down. I'm
not sure what the problem was but it works again.

Tim Daly writes:

> 2) Tim looked at porting Axiom to the MAC. 
>
>    There is an outstanding GCL issue. GCL save-system cannot save
>    images that will execute successfully. 
Which version did you build and how? Which version of XCode/OS X did
you use?

> 4) The multiple-image-per-page issue with the original book was discussed.
>    Kai suggested fixing the postscript files so they all contain the
>    bounding box. Tim didn't think that was going to affect the floating
>    issue in Latex but Tim was going to review it anyway.
I'm pretty sure I didn't. It was Gaby.

> 5) Indefinites. 
>
>    Tim mentioned that indefinites could be done using provisos.
>
>    Bill objected that provisos was a proof-theoretic approach
>    and that an algebraic approach might be more axiom-like.
>    Thus, express Indefinite(Integer) as a Poly(Int) domain if there
>    was sufficient coverage.
>
>    Kai thought that both approaches were needed.
Again that's Gaby.

> 6) Kai has a student who wants to work on provisos.
>    Tim agreed to share work with the student.
I AM a student, I don't have them. So that was Gaby, too.

\start
Date: Tue, 19 Sep 2006 17:20:59 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Question concerning types...

http://wiki.axiom-developer.org/public/TheUnknownInComputerAlgebra.pdf

Ah, by the way, I've read the paper and did not find it particularly 
useful. What they do is a bit too complicated in my eyes.

 > \begin{spad}
 > )abbrev domain PUNINT PureUnknownInteger
 > PureUnknownInteger (D,BasicUnknown):Ring == Implementation where
 >     D:IntegerNumberSystem
 >     BasicUnknown:List Symbol
 >   Implementation ==> LocalAlgebra (Polynomial D,D,D) with
 >     "/" : ($,D) -> $
 >     ++ a/n computes the expression whose value is a/n if it
 >     ++ is actually an unknown integer
 > \end{spad}

It is certainly a wrong design to implement indefinite integers as 
polynomials.

Why?

Suppose you have a nice algebra library and you want the system to 
understand indefinite objects, then you are certainly not going to add 
any function to existing domains or wrap one (and actually ALL) domains 
with a domain constructor "Indefinite". No. It should be completely 
transparent. The goal is to type

n: Integer;

and not

n: Indefinite(Integer);

Either the interpreter or some layer between interpreter and library 
code should take care about indefinite objects.

I very much believe that this requires reflection from SPAD/Aldor.

\start
Date: Tue, 19 Sep 2006 12:25:07 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Question concerning types...

On September 19, 2006 11:21 AM Ralf Hemmecke wrote:
> 
> http://wiki.axiom-developer.org/public/TheUnknownInComputerAlgebra.pdf
> 
> Ah, by the way, I've read the paper and did not find it particularly 
> useful. What they do is a bit too complicated in my eyes.
> 
>  > \begin{spad}
>  > )abbrev domain PUNINT PureUnknownInteger
>  > PureUnknownInteger (D,BasicUnknown):Ring == Implementation where
>  >     D:IntegerNumberSystem
>  >     BasicUnknown:List Symbol
>  >   Implementation ==> LocalAlgebra (Polynomial D,D,D) with
>  >     "/" : ($,D) -> $
>  >     ++ a/n computes the expression whose value is a/n if it
>  >     ++ is actually an unknown integer
>  > \end{spad}
>

Complicated? As far as I can see this is about a simple as it could
be.

Although there does appear to be some code missing from the paper.
This code does not compile as it is.
 
> It is certainly a wrong design to implement indefinite integers as 
> polynomials.
> 
> Why?
> 
> Suppose you have a nice algebra library and you want the system
> to understand indefinite objects, then you are certainly not
> going to add any function to existing domains or wrap one (and
> actually ALL) domains with a domain constructor "Indefinite". No.
> It should be completely transparent.

I am not really sure I understand what you mean by "transparent" -
particularly in to the context of SPAD/Aldor. For the most part the
type system of SPAD/ALDOR is not "transparent" by design. One must
specify (almost) all types for these compilers. Unlike Haskell, for
example, type inference in Aldor is very limited.

Polynomials are necessarily involved in the definition of the
LocalAlgebra. Your argument is not an argument against using a
LocalAlgebra as an implementation of indefinite integers.

> The goal is to type
> 
> n: Integer;
> 
> and not
> 
> n: Indefinite(Integer);
> 
> Either the interpreter or some layer between interpreter and library 
> code should take care about indefinite objects.
>

This could be easily achieved in the Axiom interpreter but I don't
think it makes any sense in the compiler. In the compiler you must
write:

  n: Indefinite(Integer)

(or the equivalent) because of the semantics associated with

  n: Integer

in a static strongly typed language.
 
> I very much believe that this requires reflection from SPAD/Aldor.
> 

Why? I do not see reflection as essential in a statically typed
language.

\start
Date: Tue, 19 Sep 2006 18:31:48 +0200
From: Gregory Vanuxem
To: list
Subject: Verbatim LaTeX in src/doc/book.pamphlet

At line 15282 of src/doc/book.pamphlet (page 299 in the produced DVI
file) the polynomial wrote in LaTeX mathematical mode (display) is
enclosed in a verbatim environment. The verbatim environment can be
removed.

\start
Date: Tue, 19 Sep 2006 13:17:53 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Axiom Conference Call Sept 18, 2006

> In spite of planning the mirror the SourceForge SVN archive on
> axiom-developer.org, I think maintaining a smaller archive on Google -
> containing only the most experimental branch, i.e. build-improvements,
> is still a good idea.
>
> Of course this needs someone to manage it and keep it up to date
> with the main build-improvements branch on SourceForge (or axiom-
> developer). So we can only go with option if someone like you, Alfredo,
> is willing to take on this task.

For what I have read, build-improvements will be gone after Gaby's work
is completed and added to Silver -> Gold.

Should I put Silver on the repository?

\start
Date: Tue, 19 Sep 2006 20:08:56 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Question concerning types...

On 09/19/2006 06:25 PM, Bill Page wrote:
>>> It is certainly a wrong design to implement indefinite integers
>>> as
>> polynomials.
>> 
>> Why?
>> 
>> Suppose you have a nice algebra library and you want the system to
>> understand indefinite objects, then you are certainly not going to
>> add any function to existing domains or wrap one (and actually ALL)
>> domains with a domain constructor "Indefinite". No. It should be
>> completely transparent.
> 
> I am not really sure I understand what you mean by "transparent" -

OK, maybe transparent is a bad word. What I mean was that if I would
like to work with indefinite integers I would not like to write anything
more complicated than "n: Integer". I believe that the type of an
indefinite integer is Integer and NOT Indefinite(Integer). But, of
course that can only work in the interpreter and not in library code (ie
for the compiler).

> particularly in to the context of SPAD/Aldor. For the most part the 
> type system of SPAD/ALDOR is not "transparent" by design.

Here *I* don't understand what you mean by transparent. But it's not
important here.

> One must specify (almost) all types for these compilers. Unlike
> Haskell, for example, type inference in Aldor is very limited.

In terms of readability of the code, I rather like that Aldor forces the 
programmer to add type declarations in function definitions. I agree 
that it is sometimes quite cumbersome, but a bit of redundancy is never 
bad if you read your (own) code in 5 years. We still have no good tool 
that shows the type of identifiers if you hover over it with your mouse.

> Polynomials are necessarily involved in the definition of the 
> LocalAlgebra. Your argument is not an argument against using a 
> LocalAlgebra as an implementation of indefinite integers.

I'll be quite until I have put my ideas into code. Currently I don't 
think that I would use polynomials. I would rather encode an indefinite 
object by a function similar to typed lambda calculus. An indefinite 
integer is then just an identity function Z->Z (macro Z==Integer) and 
addition would be something like

(a: Z->Z) + (b: Z->Z): (Z,Z)->Z == (x: Z, y: Z): Z +-> a(x) + b(y)

the zero? function would be lifted like

zero?(a: Z->Z): Z->Boolean == (x: Z):Boolean +-> zero?(a(x))

But that is all not very well thought of, since how would I then write 
the equivalent of "zero?(2+3)" if 2 and 3 are replaced by indefinite 
integers? Ah, actually one needs

zero?(a: T->Z): T->Boolean == (t:T): Boolean +-> zero?(a(t))

But how to deal with the type T? I stop here.

>> The goal is to type
>> 
>> n: Integer;
>> 
>> and not
>> 
>> n: Indefinite(Integer);
>> 
>> Either the interpreter or some layer between interpreter and
>> library code should take care about indefinite objects.

> This could be easily achieved in the Axiom interpreter but I don't 
> think it makes any sense in the compiler. In the compiler you must 
> write:
> 
> n: Indefinite(Integer)
> 
> (or the equivalent) because of the semantics associated with
> 
> n: Integer
> 
> in a static strongly typed language.

Right. But I need a use case that would justify that it is reasonable 
that indefinite integers should appear in library code.

>> I very much believe that this requires reflection from SPAD/Aldor.

> Why? I do not see reflection as essential in a statically typed 
> language.

Oh, of course, reflection is not generally necessary. I meant that for 
what I have in mind I probably would need reflection. But maybe not.
Don't take me too serious. All that discussion is just to make the 
concept clearer. Code is still far away, especially a good design for 
indefinite objects.

\start
Date: Tue, 19 Sep 2006 15:58:42 -0400
From: Bill Page
To: Alfredo Portes
Subject: Google Code repository (was: Axiom Conference Call Sept 18, 2006)

On Tuesday, September 19, 2006 1:18 PM Alfredo Portes wrote:
>
>
> For what I have read, build-improvements will be gone after
> Gaby's work is completed and added to Silver -> Gold.
>

It wont be gone, it will be merged back into Silver Trunk and
someday merged into Gold (if/when Tim Daly is convinced that this
is the right way to build Axiom).

> Should I put Silver on the repository?

The terminology is still rather confusing, but from my point
of view the axiom.build-improvements branch is a branch of
Silver. So I guess you are asking whether you should put the
Silver *trunk* branch into the Google Code archive?

I would still prefer that we duplicate the most experiment branch
i.e. build-improvements, at Google. Among other things, it is
currently the branch that best meets Google's requirement that
we not attempt to re-distribute other packages as part of our
source tree. But Silver trunk still has a lot of that dead wood.

\start
Date: Tue, 19 Sep 2006 16:09:18 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Google Code repository (was: Axiom Conference Call Sept 18, 2006)

> The terminology is still rather confusing, but from my point
> of view the axiom.build-improvements branch is a branch of
> Silver. So I guess you are asking whether you should put the
> Silver *trunk* branch into the Google Code archive?

Sorry, I should be more explicit :) . Yes I meant having the Silver
trunk in the Google repository.

> I would still prefer that we duplicate the most experiment branch
> i.e. build-improvements, at Google. Among other things, it is
> currently the branch that best meets Google's requirement that
> we not attempt to re-distribute other packages as part of our
> source tree. But Silver trunk still has a lot of that dead wood.

After sending the email, I realized that your suggestion for build-improvements
was a better option, and also a smaller one :). I was about to test
something to keep both repositories in sync, but I got a quota error
again. Apparently Google did not increase the size to 200 MB.

\start
Date: Tue, 19 Sep 2006 22:19:11 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Google Code repository

Hi Bill,

>> Should I put Silver on the repository?
> 
> The terminology is still rather confusing, but from my point
> of view the axiom.build-improvements branch is a branch of
> Silver.

http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00344.html

The terminology is actually not confusing. The point is that we should 
*not* call the whole SourceForge SVN repository Silver, but only the 
trunk. Otherwise Silver = Sourceforge/Axiom (with now 3 or 4 (different) 
branches of the axiom Sources).

> I would still prefer that we duplicate the most experiment branch
> i.e. build-improvements, at Google.

Whatever we put there, we are probably only doing this to be present at 
Google. I guess nobody will seriously use the Google repository until 
build-improvements is merged with Silver.

\start
Date: Tue, 19 Sep 2006 16:49:08 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Google Code repository

On Tuesday, September 19, 2006 4:19 PM Ralf Hemmecke
>
> >> Should I put Silver on the repository?
> >
> Bill Page wrote:
> > The terminology is still rather confusing, but from my point
> > of view the axiom.build-improvements branch is a branch of
> > Silver.
>
>
http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00344.ht
ml
>
> The terminology is actually not confusing.

What I meant was that in spite of the email referenced above, it
is still confusing to *me*. I find it awkward not to be able to
use Silver to refer to other branches in the SourceForge SVN archive.
I know someone suggested that we start to use Bronze etc. but I am
not sure that that would help.

> The point is that we should *not* call the whole SourceForge SVN
> repository Silver, but only the trunk. Otherwise Silver =
> Sourceforge/Axiom (with now 3 or 4 (different) branches of the
> axiom Sources).

Are you referring to the CVS on SourceForge (presumably identical
to the CVS on Savannah)? I thought these only had a single branch.

If you are talking about the arch (tla) archive on axiom-developer
then, you are right. I was just about to ask whether we should refer
to these a "Gold" or not. There are actually more like 10 of these
branchs and one of them is the axiom--windows--1 branch. That is
the only branch that builds on Windows now. Do we call it Gold?

>
> > I would still prefer that we duplicate the most experiment
> > branch i.e. build-improvements, at Google.
>
> Whatever we put there, we are probably only doing this to be
> present at Google. I guess nobody will seriously use the Google
> repository until build-improvements is merged with Silver.
>

I hope that is not the case.

Well, this is open source development which mean "release early
and releas often". The more accessible our experimental branchs
are, the more they will be tested and the better our software
will become. Of course people have to be warned about exactly what
they are downloading so that they have the proper expectations
about how it might/might not work. But I think we want to encourage
people to at least try the latest experimental versions. As an
Axiom developer that is the only version I am really interested
in.

\start
Date: Tue, 19 Sep 2006 23:13:35 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Google Code repository

>> The point is that we should *not* call the whole SourceForge SVN
>> repository Silver, but only the trunk. Otherwise Silver =
>> Sourceforge/Axiom (with now 3 or 4 (different) branches of the
>> axiom Sources).
> 
> Are you referring to the CVS on SourceForge (presumably identical
> to the CVS on Savannah)? I thought these only had a single branch.

Who is using CVS? Cannot we just remove support for CVS? We are 
needlessly investing time in keeping all the different repositories in 
sync (who is actually doing it?) As far as I understand Tim releases 
axiom--main--1-patch-??, calls that Gold and then transfers the code to 
the two CVS repositories on Savannah and SF. So there are 3 ways to get 
GOLD.

> If you are talking about the arch (tla) archive on axiom-developer
> then, you are right. I was just about to ask whether we should refer
> to these a "Gold" or not.

No, I would only call axiom--main--1 as Gold. Click on Sources on the 
frontpage. Until now nobody has complained about the page that I have 
created so I think we should stick to it (until somebody is bold). ;-)

 > There are actually more like 10 of these
> branchs and one of them is the axiom--windows--1 branch. That is
> the only branch that builds on Windows now. Do we call it Gold?

No. BTW, why cannot axiom--windows--1 be merged with axiom--main--1? Is 
it so different?

\start
Date: 19 Sep 2006 23:10:44 +0200
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: Google Code repository (was: Axiom Conference Call Sept 18, 2006)

Alfredo Portes writes:

| Apparently Google did not increase the size to 200 MB.

I got an email that the hosting team would get into contact with me.
I'll ping them.

\start
Date: 19 Sep 2006 23:12:05 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Google Code repository

[...]

| Well, this is open source development which mean "release early
| and releas often". The more accessible our experimental branchs
| are, the more they will be tested and the better our software
| will become.

I agree with this sentiment.

\start
Date: Tue, 19 Sep 2006 17:31:52 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: Re: Google Code repository (was: Axiom Conference Call Sept 18, 2006)

On 19 Sep 2006 23:10:44 +0200, Gabriel Dos Reis
Gabriel Dos Reis wrote:
> Alfredo Portes writes:
>
> | Apparently Google did not increase the size to 200 MB.
>
> I got an email that the hosting team would get into contact with me.
> I'll ping them.
>
> -- Gaby

Thanks Gaby.

\start
Date: Tue, 19 Sep 2006 17:35:47 -0400
From: Bill Page
To: Ralf Hemmecke, Bill Page
Subject: RE: Google Code repository

On Tuesday, September 19, 2006 5:14 PM Ralf Hemmecke wrote:
> ...
> BTW, why cannot axiom--windows--1 be merged with axiom--main--1?
> Is it so different?
>

It is different but not too different. There are changes in
some of the Boot and Lisp code because Axiom uses some non-
portable unixism like calling system functions that only
exist on unix. There is also the fact that currently neither
Hyperdoc nor Axiom graphics can be built on Windows because
of the X-windows library dependencies.

But in any case, yes it could and should be merged back into
axiom--main--1. This has been waiting almost two years to
happen. Are you volunteering? :-)

The path that I had in mind to do this is starting with the
build-improvements branch on SVN since the new build environment
is based on tecnhiques that should be portable to the Windows
MSYS/MinGW environment and also can start with a previously
installed version of GCL which simplifies things significantly
on Windows.

\start
Date: Wed, 20 Sep 2006 04:15:40 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: axiom.silver
Cc: Jaroslov Rosenberger, Gabriel Dos Reis

On Friday, September 15, 2006 11:31 AM you wrote:
>
> Can we finalize this stat bit please?  I'm trying to get 2.6.8 out
> ....

I had a bit of trouble with my Windows MSYS/MinGW configuration
over the weekend, but now I have got it straight. See the Windows
configuration here:

http://wiki.axiom-developer.org/BuildAxiom

for how I setup the build environment.

I needed the following patch to build on Windows because of a
difference with lstat (explained in the patch).

$ diff -Naur gcl-2.6.8pre_orig/o gcl-2.6.8pre/o
diff -Naur gcl-2.6.8pre_orig/o/unixfsys.c gcl-2.6.8pre/o/unixfsys.c
--- gcl-2.6.8pre_orig/o/unixfsys.c      Sun Sep 17 17:54:43 2006
+++ gcl-2.6.8pre/o/unixfsys.c   Wed Sep 20 01:03:44 2006
@@ -34,6 +34,10 @@

 #ifdef __MINGW32__
 #  include <windows.h>
+/* Windows has no symlink, therefore no lstat.  Without symlinks lstat
+   is equivalent to stat anyway.  */
+#  define S_ISLNK(a) 0
+#  define lstat stat
 #endif

 #ifdef BSD

----------

With this patch applied I was able to build both the CLtL1 and ANSI
images.

Here are the results of some tests of the new si:stat function:

$ saved_gcl
GCL (GNU Common Lisp)  2.6.8 CLtL1    Sep 20 2006 02:26:46
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to
C:/DOCUME~1/bpage/LOCALS~1/Temp/

>(si:stat "tryserv.tcl")

(:FILE 481 1158724649)

>(si:stat "tryserv.xxx")

NIL

>(si:stat "bfd")       

(:DIRECTORY 0 1158734019)

>(quit)

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

The difference between this and your output below seems to be due
to a change in the coding for this section in the current CVS
which now looks like this:

  if (lstat(filename,&ss))
    RETURN1(Cnil);
  else {/* ctime_r insufficiently portable */
    /* int j;
       ctime_r(&ss.st_ctime,filename);
       j=strlen(filename);
       if (isspace(filename[j-1]))
       filename[j-1]=0;*/
    RETURN1(list(3,S_ISDIR(ss.st_mode) ? sKdirectory :
                 (S_ISLNK(ss.st_mode) ? sKlink : sKfile),
                 make_fixnum(ss.st_size),make_fixnum(ss.st_ctime)));

-------

So is this the result you expected from Windows?

Regards,
Bill Page.

>
> In addition to knowing whether enough information is provided, I need
> to know if it works on windows, macosx, and any other proprietary
> system of interest.
> ...
> >
> > The easy way, which avoids the requirement of PDP-10 lisp
> > comaptability :-), is si::stat.  How about this:
> >
> > Index: unixfsys.c
> > =
==========================
==========================
=================
> > RCS file: /cvsroot/gcl/gcl/o/unixfsys.c,v
> > retrieving revision 1.28
> > diff -u -r1.28 unixfsys.c
> > --- unixfsys.c	24 Aug 2006 16:53:28 -0000	1.28
> > +++ unixfsys.c	12 Sep 2006 16:35:56 -0000
> > @@ -23,6 +23,7 @@
> >  #include <stdlib.h>
> >  #include <unistd.h>
> >  #include <errno.h>
> > +#include <time.h>
> > 
> >  #define IN_UNIXFSYS
> >  #include "include.h"
> > @@ -490,6 +491,34 @@
> >  }
> > 
> > 
> > +DEF_ORDINARY("DIRECTORY",sKdirectory,KEYWORD,"");
> > +DEF_ORDINARY("LINK",sKlink,KEYWORD,"");
> > +DEF_ORDINARY("FILE",sKfile,KEYWORD,"");
> > +
> >
> +DEFUN_NEW("STAT",object,fSstat,SI,1,1,NONE,OO,OO,OO,OO,(objec
> t path),"") {
> > +
> > +  char filename[4096];
> > +  struct stat ss;
> > + 
> > +
> > +  bzero(filename,sizeof(filename));
> > +  coerce_to_filename(path,filename);
> > +  if (lstat(filename,&ss))
> > +    RETURN1(Cnil);
> > +  else {
> > +    int j;
> > +    ctime_r(&ss.st_ctime,filename);
> > +    j=strlen(filename);
> > +    if (isspace(filename[j-1]))
> > +      filename[j-1]=0;
> > +    RETURN1(list(3,S_ISDIR(ss.st_mode) ? sKdirectory :
> > +		 (S_ISLNK(ss.st_mode) ? sKlink : sKfile),
> > +		 make_fixnum(ss.st_size),make_simple_string(filename)));
> > +  }
> > +}
> > +
> > +
> > +
> > 
> DEFUN_NEW("SETENV",object,fSsetenv,SI,2,2,NONE,OO,OO,OO,OO,(ob
> ject variable,object value),"Set environment VARIABLE to VALUE")
> > 
> >  {
> >
> >
> > >(si::stat "/tmp/ff1.h")
> >
> > (:LINK 9 "Tue Sep 12 12:32:58 2006")
> >
> > >(si::stat "/tmp/ff.h")
> >
> > (:FILE 0 "Mon Dec  5 13:52:23 2005")
> >
> > >(si::stat "/tmp/")
> >
> > (:DIRECTORY 81920 "Tue Sep 12 12:34:53 2006")
> >
> > >(si::stat "/tmp")
> >
> > (:DIRECTORY 81920 "Tue Sep 12 12:34:53 2006")
> >
> > >(si::stat "/tmp1")
> >
> > NIL
> > ...

\start
Date: Wed, 20 Sep 2006 10:53:25 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Google Code repository

On 09/19/2006 11:35 PM, Page, Bill wrote:
> On Tuesday, September 19, 2006 5:14 PM Ralf Hemmecke wrote:
>> ... 
>> BTW, why cannot axiom--windows--1 be merged with axiom--main--1?
>> Is it so different?
>>
> 
> It is different but not too different. There are changes in
> some of the Boot and Lisp code because Axiom uses some non-
> portable unixism like calling system functions that only
> exist on unix. There is also the fact that currently neither
> Hyperdoc nor Axiom graphics can be built on Windows because
> of the X-windows library dependencies.
> 
> But in any case, yes it could and should be merged back into
> axiom--main--1. This has been waiting almost two years to
> happen. Are you volunteering? :-)

Oh, sorry, me doing the merge connected with Windows is probably not the 
best idea. There should proably be one who is more familiar with Windows.

> The path that I had in mind to do this is starting with the
> build-improvements branch on SVN since the new build environment
> is based on tecnhiques that should be portable to the Windows
> MSYS/MinGW environment and also can start with a previously
> installed version of GCL which simplifies things significantly
> on Windows.

The last edit on axiom--windows--1 was 2005-03-17. Wouldn't it make 
sense to merge it first with Gold (tla), then test it and only 
afterwards merge with the build-improvements? I guess that Gold is 
closer than build-improvements.

I've just tried

tla get arch@axiom-developer.org--axiom/axiom--windows--1 axiom--windows--1

(one line)

cd axiom--windows--1
tla star-merge arch@axiom-developer.org--axiom/axiom--main--1

Runs nicely, but gives a number of conflicts in the Makefiles which I 
feel unable to resolve. :-(

\start
Date: Wed, 20 Sep 2006 11:04:37 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [build Axiom] updated Windows build instructions

http://wiki.axiom-developer.org/BuildAxiom

Is there some particular reason why one needs darcs for the Windows 
build? Doesn't one have to get axiom--windows--1 from the tla archive?

I am confused.

There is a tla archive axiom--windows--1 AND a darcs archive 
axiom--windows--1? Unfortunately it is nowhere written that they are in 
sync. The darcs archive doesn't even appear on

http://wiki.axiom-developer.org/AxiomSources

so it is non-existing... ;-) ... only for people who want to run MathAction

http://wiki.axiom-developer.org/MathActionRepository

We simply have two many source archives and potential contributors have 
to ask at the axiom-developer mailing list which one contains the 
blessed sources.

\start
Date: Wed, 20 Sep 2006 05:31:44 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [build Axiom] updated Windows build instructions

On Wednesday, September 20, 2006 5:05 AM Ralf Hemmecke wrote:
>
> http://wiki.axiom-developer.org/BuildAxiom
>
> Is there some particular reason why one needs darcs for the
> Windows build? Doesn't one have to get axiom--windows--1
> from the tla archive?
>
> I am confused.
>

We have discussed this before. The problem is that there is
no reliable version of tla for Windows. Both Mike Thomas and
I have tried several different versions and they all have
problems. As far as I have been able to determine, tla is not
being actively maintained anymore, so the prospects of a good
Windows version seems small.

We started using darcs for axiom--windows--1 because it works
reliably on both Linux and Windows. Of course we probably
also could have used CVS but at the time we were already
moving away from it.

Now we are also using SVN but (possibly because of the
SourceForge problem) I have not been able to do a complete
checkout of anything from the SVN repository to Windows.

> There is a tla archive axiom--windows--1 AND a darcs archive
> axiom--windows--1? Unfortunately it is nowhere written that
> they are in sync.

As noted on the BuildAxiom page they were in sync as of
March 15, 2005 but the tla archive has not been updated
since March 17, 2005, so I think it is safe to say that they
are not in sync. But they are probably not very different.
I had planned to keep it up to date by manually transferring
the contents from one archive to the other on the axiom-
developer server, but in the end I really did very little
work with Windows after we got the first working executable.

> The darcs archive doesn't even appear on
>
> http://wiki.axiom-developer.org/AxiomSources
>
> so it is non-existing... ;-) ... only for people who want
> to run MathAction
>
> http://wiki.axiom-developer.org/MathActionRepository
>

I would be happy if you would correct this. I am not sure of
the best solution. Should we ignore the merging problem and
just call the darcs version the official sources for Windows?

> We simply have two many source archives and potential
> contributors have to ask at the axiom-developer mailing
> list which one contains the blessed sources.
>

Yes that is a problem. What is your suggested solution?

If someone can prove that SVN actually does work reliably on
Windows, then maybe that would be the best option?

\start
Date: Wed, 20 Sep 2006 12:13:26 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [build Axiom] updated Windows build instructions

> We have discussed this before. The problem is that there is
> no reliable version of tla for Windows.

I feared that.

> Both Mike Thomas and
> I have tried several different versions and they all have
> problems. As far as I have been able to determine, tla is not
> being actively maintained anymore, so the prospects of a good
> Windows version seems small.

Maybe one day we will be using bazaar-ng since that seems to be actively 
maintained by the ubuntu people.

> We started using darcs for axiom--windows--1 because it works
> reliably on both Linux and Windows. Of course we probably
> also could have used CVS but at the time we were already
> moving away from it.

Clear. We should only use CVS as a way of distributing (if at all), but 
not really working with it. Its days are numbered. ;-)

> Now we are also using SVN but (possibly because of the
> SourceForge problem) I have not been able to do a complete
> checkout of anything from the SVN repository to Windows.

Have you ever tried

http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00321.html

svn co -r1 https://svn.sourceforge.net/svnroot/axiom/trunk trunk
cd trunk
svn update

on Windows?

>> The darcs archive doesn't even appear on
>>
>> http://wiki.axiom-developer.org/AxiomSources
>>
>> so it is non-existing... ;-) ... only for people who want
>> to run MathAction
>>
>> http://wiki.axiom-developer.org/MathActionRepository

> I would be happy if you would correct this. I am not sure of
> the best solution. Should we ignore the merging problem and
> just call the darcs version the official sources for Windows?

I wouldn't. Better would be to sync them then I can declare on 
AxiomSource that they are the same. And sooner or later they should 
disappear anyway, because they should be merged to Gold or Silver. 
(First, of course, to Silver, but a merge with Gold was easy since we 
have "tla star-merge". The hard part is to sort out the conflicts.

>> We simply have two many source archives and potential
>> contributors have to ask at the axiom-developer mailing
>> list which one contains the blessed sources.

> Yes that is a problem. What is your suggested solution?

Document on AxiomSources. That should be the place to read about our 
source mess. ;-) If you bring axiom--windows--1 in sync with the tla 
archive, then I add the stuff to AxiomSources. I guess, you volunteer to 
be the maintainer of that branch. I haven't heard from Mike Thomas or 
Tim (who are currently the maintainers of the tla axiom--windows--1). 
Can I make you the maintainer of the darcs and tla versions?

> If someone can prove that SVN actually does work reliably on
> Windows, then maybe that would be the best option?

Probably, then axiom--windows--1 would exist as a branch on sourceforge.
But to be honest, I would rather try to avoid that and better ask for 
help from developers knowledgeable in Windows to actually do the merge now.

\start
Date: Wed, 20 Sep 2006 06:15:17 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Google Code repository

On Wednesday, September 20, 2006 4:53 AM you wrote:
> ...
> Bill Page wrote:
> > The path that I had in mind to do this is starting with the
> > build-improvements branch on SVN since the new build environment
> > is based on tecnhiques that should be portable to the Windows
> > MSYS/MinGW environment and also can start with a previously
> > installed version of GCL which simplifies things significantly
> > on Windows.
>
> The last edit on axiom--windows--1 was 2005-03-17. Wouldn't it
> make sense to merge it first with Gold (tla), then test it and
> only afterwards merge with the build-improvements? I guess that
> Gold is closer than build-improvements.

I don't think the additional differences in build-improvements
would make the merging more or less difficult. I would like to
take advantage of the new configure scripts to help detect
the differences between Linux and Windows.

>
> I've just tried
>
> tla get arch@axiom-developer.org--axiom/axiom--windows--1
> axiom--windows--1
>
> (one line)
>
> cd axiom--windows--1
> tla star-merge arch@axiom-developer.org--axiom/axiom--main--1
>
> Runs nicely, but gives a number of conflicts in the Makefiles
> which I feel unable to resolve. :-(
>

I seriously doubt that star-merge would be of much help in
merging these two sources because they work on two different
systems. The changes on the Linux side might be incompativle
with Windows and vice versa even though there is no conflict
to resolve. So even if star-merge succeeded, it is likely to
cause breakages in both environments.

I think our original process for developing the Windows port
was flawed. We should not really have created a separate
branch just for Windows.

I think we really need to start again with the up to date
Linux sources: (1) Test the build of that source code on
Windows. (2) If the build fails, we can consult the diffs
with the old Windows sources to see if it contains a solution.
(3) after we update the sources then we must first check that
it still builds on Linux. (4) If it does then we can continue
to test on Windows at step (1). And iterate until we have
sources that work on both systems.

There are really not that many changes to the Axiom source
code on Windows. Most of the work done by Mike Thomas involved
patches to GCL to allow it to compile Axiom. And Most of these
have since been incorporated in gcl-2.6.8pre.

gcl-2.6.8pre does compile on Windows with one minor change. But
my first attempt to use it to compile the Axiom windows sources
fails with a data type conflict on MYCOMBINE in src/interp/
cfuns.lisp.pamphlet which is partly coded in C embedded in
Lisp and partly in Lisp.

This seems similar to a problem that Camm solved with using
2.6.8pre on linux.

\start
Date: Wed, 20 Sep 2006 12:19:34 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [build Axiom] updated Windows build instructions

 > We have discussed this before. The problem is that there is
 > no reliable version of tla for Windows.

I feared that.

 > Both Mike Thomas and
 > I have tried several different versions and they all have
 > problems. As far as I have been able to determine, tla is not
 > being actively maintained anymore, so the prospects of a good
 > Windows version seems small.

Maybe one day we will be using bazaar-ng since that seems to be actively 
maintained by the ubuntu people.

 > We started using darcs for axiom--windows--1 because it works
 > reliably on both Linux and Windows. Of course we probably
 > also could have used CVS but at the time we were already
 > moving away from it.

Clear. We should only use CVS as a way of distributing (if at all), but 
not really working with it. Its days are numbered. ;-)

 > Now we are also using SVN but (possibly because of the
 > SourceForge problem) I have not been able to do a complete
 > checkout of anything from the SVN repository to Windows.

Have you ever tried

http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00321.html

svn co -r1 https://svn.sourceforge.net/svnroot/axiom/trunk trunk
cd trunk
svn update

on Windows?

 >> The darcs archive doesn't even appear on
 >>
 >> http://wiki.axiom-developer.org/AxiomSources
 >>
 >> so it is non-existing... ;-) ... only for people who want
 >> to run MathAction
 >>
 >> http://wiki.axiom-developer.org/MathActionRepository

 > I would be happy if you would correct this. I am not sure of
 > the best solution. Should we ignore the merging problem and
 > just call the darcs version the official sources for Windows?

I wouldn't. Better would be to sync them then I can declare on 
AxiomSource that they are the same. And sooner or later they should 
disappear anyway, because they should be merged to Gold or Silver. 
(First, of course, to Silver, but a merge with Gold was easy since we 
have "tla star-merge". The hard part is to sort out the conflicts.

 >> We simply have two many source archives and potential
 >> contributors have to ask at the axiom-developer mailing
 >> list which one contains the blessed sources.

 > Yes that is a problem. What is your suggested solution?

Document on AxiomSources. That should be the place to read about our 
source mess. ;-) If you bring axiom--windows--1 in sync with the tla 
archive, then I add the stuff to AxiomSources. I guess, you volunteer to 
be the maintainer of that branch. I haven't heard from Mike Thomas or 
Tim (who are currently the maintainers of the tla axiom--windows--1). 
Can I make you the maintainer of the darcs and tla versions?

 > If someone can prove that SVN actually does work reliably on
 > Windows, then maybe that would be the best option?

Probably, then axiom--windows--1 would exist as a branch on sourceforge.
But to be honest, I would rather try to avoid that and better ask for 
help from developers knowledgeable in Windows to actually do the merge now.

\start
Date: Wed, 20 Sep 2006 06:45:24 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [build Axiom] updated Windows build instructions

On Wednesday, September 20, 2006 6:13 AM you wrote:
> ...
> Maybe one day we will be using bazaar-ng since that seems to
> be actively maintained by the ubuntu people.

Ok on Linux... but Windows?

> ...
> Have you ever tried
>
>
http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00321.ht
ml
>
> svn co -r1 https://svn.sourceforge.net/svnroot/axiom/trunk trunk
> cd trunk
> svn update
>
> on Windows?

Yes. Unfortunately it fails with the same error message as on
Linux:

svn: REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
svn: REPORT of '/svnroot/axiom/!svn/vcc/default': Could not read
response body:
Secure connection truncated (https://svn.sourceforge.net)

-----

> ...
> Document on AxiomSources. That should be the place to read about
> our source mess. ;-) If you bring axiom--windows--1 in sync with
> the tla archive, then I add the stuff to AxiomSources. I guess,
> you volunteer to be the maintainer of that branch. I haven't
> heard from Mike Thomas or Tim (who are currently the maintainers
> of the tla axiom--windows--1). Can I make you the maintainer of
> the darcs and tla versions?

Ok. :-(

>
> > If someone can prove that SVN actually does work reliably on
> > Windows, then maybe that would be the best option?
>
> Probably, then axiom--windows--1 would exist as a branch on
> sourceforge. But to be honest, I would rather try to avoid that
> and better ask for help from developers knowledgeable in Windows
> to actually do the merge now.
>

Merging is awkward so long as we use too different archive systems.
It means the merge has to be done on a combination of different
machines.

Maybe moving the SVN archive to axiom-developer.org will help.

I am still tempted to look for solutions outside of all of the
archive systems we have tries so far. The more I read about
Mercurial the more I like it...

\start
Date: Wed, 20 Sep 2006 06:58:56 -0400
From: Bill Page
To: Bill Page
Subject: Axiom for Windows on GCL-2.6.8pre (was: Google Code repository)

On Wednesday, September 20, 2006 6:15 AM I wrote:
> ...
> gcl-2.6.8pre does compile on Windows with one minor change. But
> my first attempt to use it to compile the Axiom windows sources
> fails with a data type conflict on MYCOMBINE in src/interp/
> cfuns.lisp.pamphlet which is partly coded in C embedded in
> Lisp and partly in Lisp.
>
> This seems similar to a problem that Camm solved with using
> 2.6.8pre on linux.
>

Some good news. With the patches supplied by Camm in:

http://lists.nongnu.org/archive/html/axiom-developer/2006-08/msg00344.ht
ml

and removing the out-of-date patches which have since been
incorporated into gcl, the darcs axiom--windows--1 source code
seems to be compiling using the new gcl-2.6.8pre. I now expect it
to complete successfully (I will confirm in a couple of hours).

This means that at least we will be able to work with the same
version of gcl in both Linux and Windows once Camm officially
releases 2.6.8. The Windows version of Axiom was last successfully
compiled only with a patched version of gcl-2.6.5.

\start
Date: Wed, 20 Sep 2006 13:01:47 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [build Axiom] updated Windows build instructions

>> svn co -r1 https://svn.sourceforge.net/svnroot/axiom/trunk trunk
>> cd trunk
>> svn update
>>
>> on Windows?
> 
> Yes. Unfortunately it fails with the same error message as on
> Linux:
> 
> svn: REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
> svn: REPORT of '/svnroot/axiom/!svn/vcc/default': Could not read
> response body:
> Secure connection truncated (https://svn.sourceforge.net)

Does that happen already at "svn co -r1"?

And http://gallery.menalto.com/node/53820 also did not help?
:-(

\start
Date: Wed, 20 Sep 2006 07:08:57 -0400
From: Alfredo Portes
To: Ralf Hemmecke
Subject: re: [build Axiom] updated Windows build instructions

On 9/20/06, Ralf Hemmecke wrote:
> >> svn co -r1 https://svn.sourceforge.net/svnroot/axiom/trunk trunk
> >> cd trunk
> >> svn update
> >>
> >> on Windows?
> >
> > Yes. Unfortunately it fails with the same error message as on
> > Linux:
> >
> > svn: REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
> > svn: REPORT of '/svnroot/axiom/!svn/vcc/default': Could not read
> > response body:
> > Secure connection truncated (https://svn.sourceforge.net)
>
> Does that happen already at "svn co -r1"?

Same error here. It happens when you do the update.

\start
Date: Wed, 20 Sep 2006 07:12:28 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [build Axiom] updated Windows build instructions

Ralf,

On Wednesday, September 20, 2006 7:02 AM you asked:
>
> >> svn co -r1 https://svn.sourceforge.net/svnroot/axiom/trunk trunk
> >> cd trunk
> >> svn update
> >>
> >> on Windows?
> >
> > Yes. Unfortunately it fails with the same error message as on
> > Linux:
> >
> > svn: REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
> > svn: REPORT of '/svnroot/axiom/!svn/vcc/default': Could not read
> > response body:
> > Secure connection truncated (https://svn.sourceforge.net)
>
> Does that happen already at "svn co -r1"?
>

No. The failure occurs during the the 'svn update' step. Or
during the 'svn co' step if I omit the -r1.

> And http://gallery.menalto.com/node/53820 also did not help?
> :-(

I tried this on Linux and it did not help. On Windows I do not
know how to find the .subversion directory.

On Windows I am using the following subversion version:

$ svn --version
svn, version 1.4.0 (r21228)
   compiled Sep 11 2006, 17:46:59

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet
(http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV)
protocol.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network
protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

\start
Date: Wed, 20 Sep 2006 13:25:02 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [build Axiom] updated Windows build instructions

>>> svn: REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
>>> svn: REPORT of '/svnroot/axiom/!svn/vcc/default': Could not read
>>> response body:
>>> Secure connection truncated (https://svn.sourceforge.net)
>> Does that happen already at "svn co -r1"?

Have you read http://subversion.tigris.org/faq.html?

Especially,

Why do I get occasional, seemingly inconsistent errors checking out over 
http:// from a repository running on MacOS X 10.4 (Tiger)?

The answer claims that it is a bug in Apache.

So maybe the sourceforge people should do something...
And Bill maybe you should be careful when setting up apache for SVN on 
axiom-developer.org.

\start
Date: Wed, 20 Sep 2006 08:43:24 -0400
From: Alfredo Portes
To: Bill Page
Subject: re: [build Axiom] updated Windows build instructions

> > And http://gallery.menalto.com/node/53820 also did not help?
> > :-(
>
> I tried this on Linux and it did not help. On Windows I do not
> know how to find the .subversion directory.
>
> On Windows I am using the following subversion version:
>

I found it under \Documents and Settings\"local user"\Application
Data\Subversion
directory, however this didn't fix the problem.

\start
Date: 20 Sep 2006 15:28:23 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: [build Axiom] updated Windows build instructions

| >>> svn: REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
| >>> svn: REPORT of '/svnroot/axiom/!svn/vcc/default': Could not read
| >>> response body:
| >>> Secure connection truncated (https://svn.sourceforge.net)
| >> Does that happen already at "svn co -r1"?
| 
| Have you read http://subversion.tigris.org/faq.html?
| 
| Especially,
| 
| Why do I get occasional, seemingly inconsistent errors checking out
| over http:// from a repository running on MacOS X 10.4 (Tiger)?
| 
| The answer claims that it is a bug in Apache.

So do I not see hose failure when using SVK? (SVK is just an SVN client).

\start
Date: Wed, 20 Sep 2006 19:54:21 +0200
From: Gregory Vanuxem
To: Ralf Hemmecke
Subject: re: [build Axiom] updated Windows build instructions

Le mercredi 20 septembre 2006 =E0 12:13 +0200, Ralf Hemmecke a =E9crit :
[...]
> > I would be happy if you would correct this. I am not sure of
> > the best solution. Should we ignore the merging problem and
> > just call the darcs version the official sources for Windows?
>
> I wouldn't. Better would be to sync them then I can declare on
> AxiomSource that they are the same. And sooner or later they should
> disappear anyway, because they should be merged to Gold or Silver.

There is not a lot of differences between the two repositories as Bill
said. The file src/doc/ps/segbind.ps is only available in the tla
repository and in the file src/scripts/document the latex variable is
defined differently: `which latex` in the tla repository and latex in
the darcs one. It's on my TODO list to update my Windows version (the
tla one) up to Gold patch-50 but I first need to know why the bug #312
is specific to Axiom on Linux (see
http://lists.gnu.org/archive/html/axiom-math/2006-08/msg00035.html)

\start
Date: Wed, 20 Sep 2006 16:57:34 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: re: [build Axiom] updated Windows buildinstructions
Cc: Ralf Hemmecke

On Wednesday, September 20, 2006 1:54 PM Vanuxem Gr=E9gory wrote:
>
> There is not a lot of differences between the two repositories
> as Bill said. The file src/doc/ps/segbind.ps is only available
> in the tla repository

As far as I can tell this file is garbage that happened to get
caught in the archive. It is probably manually saved from the
graphic produced by the draw command in the file
'src/input/segbind.input'. It is not referenced anywhere in
the source.

> and in the file src/scripts/document the latex variable is
> defined differently: `which latex` in the tla repository and
> latex in the darcs one.

This is a change I made just last night while testing the windows
build... I guess I might as well explain it here. :) It turns out
that this is just a silly way to refer an executable file. It
breaks if the path to the executable contains directory names
with spaces - something that is quite frequent on Windows. The
new version of MikTeX puts the 'latex.exe' file in the
"c:/Program Files/MikTeX" directory and this causes a failure
in the 'document' script. By just writing 'latex' instead of
`which latex` we let the system lookup the executable in the
normal manner.

> It's on my TODO list to update my Windows version (the
> tla one) up to Gold patch-50

What version of tla do you use on Windows? Does it work
reliably for you? Have you tried to delete a tla archive from
Windows yet? With the version of tla what I was using this
is extremely awkward because very long file names prevent
the usual method of deleteing directories from working.

> but I first need to know why the bug #312 is specific to
> Axiom on Linux (see
> http://lists.gnu.org/archive/html/axiom-math/2006-08/msg00035.html)
>

If you have patience, perhaps you could try a binary search
through the older linux versions to find where the failure
was introduced. The axiom--windows--1 branch was cloned from
the linux version at about patch-30, I think. You can retrieve
the older patch versions from the tla archive by appending the
patch suffix to the archive name, like this:

  $ tla get axiom--main--1-patch-50 axiom-50
  $ tla get axiom--main--1-patch-49 axiom-49
  ...

\start
Date: Thu, 21 Sep 2006 00:14:48 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: re: [build Axiom] updated Windows buildinstructions
Cc: Ralf Hemmecke

Le mercredi 20 septembre 2006 =E0 16:57 -0400, Page, Bill a =E9crit :
[...]
>
> > and in the file src/scripts/document the latex variable is
> > defined differently: `which latex` in the tla repository and
> > latex in the darcs one.
>
> This is a change I made just last night while testing the windows
> build... I guess I might as well explain it here. :) It turns out
> that this is just a silly way to refer an executable file. It
> breaks if the path to the executable contains directory names
> with spaces - something that is quite frequent on Windows. The
> new version of MikTeX puts the 'latex.exe' file in the
> "c:/Program Files/MikTeX" directory and this causes a failure
> in the 'document' script. By just writing 'latex' instead of
> `which latex` we let the system lookup the executable in the
> normal manner.

OK, I understand now, I checked out axiom--windows--1 with darcs today
since it can be considered as the official branch for you. Personally, I
never install "Unix world" softwares (Axiom, Cygwin, MinGW, MikTeX,
Perl, Python etc...) in a path with spaces.

> > It's on my TODO list to update my Windows version (the
> > tla one) up to Gold patch-50
>
> What version of tla do you use on Windows? Does it work
> reliably for you? Have you tried to delete a tla archive from
> Windows yet? With the version of tla what I was using this
> is extremely awkward because very long file names prevent
> the usual method of deleteing directories from working.

No, I tried in the past without success. I've never tested darcs on
Windows. I thought that the official branch was on the tla repository
so I downloaded it from Linux.


> > but I first need to know why the bug #312 is specific to
> > Axiom on Linux (see
> > http://lists.gnu.org/archive/html/axiom-math/2006-08/msg00035.html)
> >
>
> If you have patience, perhaps you could try a binary search
> through the older linux versions to find where the failure
> was introduced. The axiom--windows--1 branch was cloned from
> the linux version at about patch-30, I think. You can retrieve
> the older patch versions from the tla archive by appending the
> patch suffix to the archive name, like this:
>
>   $ tla get axiom--main--1-patch-50 axiom-50
>   $ tla get axiom--main--1-patch-49 axiom-49
>   ...

OK, thanks. I don't know how I will do. I diff-ed some weeks ago the
int/algebra/*.spad (between patch-(49 or 50) and the windows branch) and
tested individually each modified file without success. So it seems to
me that the bug was introduced in the interpreter or somewhere else but
not in the algebra files. I could be wrong though.

\start
Date: Wed, 20 Sep 2006 21:21:53 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: An idea - Axiom Survey Team

This idea came out of some IRC discussions between myself and Kai a
little while back, and I thought we might as well bring it to the list.
 One of the drawbacks to the current Axiom codebase is that while the
existing pamphlets can indeed be processed by noweave and notangle,
they are not literate in the sense of having code chunks and
documentation woven together and being reorganized for human
consumption.  (At least, most of them - there are a few exceptions.)

While many of us lack the technical skills to be able to decode the
actual source code and document what it does, an alternative which can
still be useful is to take the mostly monolithic code chunks in the
existing pamphlet files and break them down into something more
managable.  Even if for the most part the people doing this can't add
useful comments, they can introduce a more literate program like
structure to the file and clear the way for more skilled programmers
who will deal with these files in the future.

The approach is simple - select one pamphlet file, and re-configure the
<*> chunk (usually the only chunk in a file aside from the license)
into more discrete components as per dhmatrix and other such files.  Of
course the breakdown made might be something other than the final,
optimal structure used during documentation but it should at least help
start the process.  If the person surveying the file has some idea as
to the functionality of some parts they can go ahead and introduce
documentation, but that is not essential - the idea is to make use of
anyone who might be less skilled at reading old lisp and boot code but
would still like to further the progress of Axiom.  Hence the name
Axiom Survey - it is not intended to be an in-depth exploration and
comprehension of the source code, just a first pass that helps those
who will follow.

As a more or less arbitrary starting point, we picked the
i-*.boot.pamphlet files in the interp directory.  I've broken down a
few of them into smaller chunks, although I haven't really added much
in the way of documentation as yet.  I created diff -Naur patches, but
it's almost needless since the only change is the literate structure
and there is no logic change to be explained.  They seem to build OK so
I'm hoping that means I didn't let any code slip through the cracks.

Does this sound like a useful project to put in motion?  With luck it
will be an aid to those who are skilled enough to understand the code,
and at the same time it will help introduce people to the Axiom
codebase.

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-858945582-1158812513=:99537

H4sICFUOEkUAA2F4aW9tc3VydmV5cGF0Y2hlcy0wOTIwMDYudGFyAOw8a3Pb
OJLz9fwrUC6nJJ0ojUg9/KhJNoqsZHwbWx5LmdSWV7dFSZDMMV/hw4+byn+/
7gZAghIleTZzubqrVVK2CTSA7kajX2gqjuZNx094FDadhu3b7nPsxM1ZECTN
0PbCO5fjH8n87od//tOCT6/Twd/mcdeiZ1M8w8fqWr3eD2ar2+p0Wj2r1/4B
oI6t9g+s9Q1rvviTxokdMQa/ebQbjkfx90Do+34ajQZrNn+E//aTE3jNWeq4
i4bjhVHwwD3uJ/GPcTT/UYjIj1JEivLxbxZsb6N10mi3mHl81u2dtXrNlvqw
RqvTah3U63W2a/Rpw+wysw1Dz9rtjdFv37JG1+ixetc4Zm/fHrC/22lyF0S/
T+446yPibMJt7yt0ePY9T5zE5fD3jK8c/3d7FieRPU++HtQnd07Mlo7L2Tzw
E9vxY3ZBlEUcfrK+lH/2PvXniRP4scGQcn/BFywJGPftmasWhOcE1mKpnzyH
0O/4YZqwZQRdNkNpYba/YHYcOyufeXZyx+GHM7ddhvBxE/CDiTXs4Pk3Pk/g
d4LLBEvEEXeAyO+0DeBQvdMxzA6xADZuPHo/+dy/GRps+Ovwil28Z/3zXy/G
w3M2es8mPw/Z9Wg8vnh38fFi8jdsGn8a/MzO+5f9D0NY/oC9PWj89NO/v3nz
Gn+7zpz7MX/z5qBxAFLxag9nYDxBvbNjZ85GM0SdTYAydrEApJ0lkIqAB/W/
x5yG/L4PFFhwUP/ppxVPCPIyWHDEjekN7Im9fs0KTa3qk3EEDEd8Vzwap7NF
4MHe1g7qbzdnbG1MiePLhsNCB4whn5mzhHWB+sDnLFgy2Es2I2JoK1lVjmXj
JHL8FXvvBnbC3gWBy22YB8B9NVNCEiiZyIC5aQRC6CQxTWWQzPiOywIYFD06
MafN7/VA7uvw85S2nrH3H0f9yTUy4w07Og9SkBdaFPuqT68rfvAusv35XY0F
kWz41XZTXqMBV+IBiccBsN4Gq8QuFXglN+5J8uXiajL8MLy5hj8JD2wD+tjZ
a0L5+ARRPmllKI8nNxdXHyTOwey3K/74ObJD3DzBtppGWBmURiaBXl181NG+
dHzHs91f7cjB4zMJHnmk8C/rqz7YkZFouwxwMW2tJ6BZGLjPfuA58GeczhIc
RLsPQLC9mQaBIWoG54H77EGu0mQ3cnsBUxQhH8SnScwxWyZyB4xexh62G88K
keynrsuqSQWYDHpnwaNzEtURIEU7iyx5wUylXNOPW7G16iwMTz8Ok4IQLx1/
oTEu9UoZh+Itz46aRgMTR44JUI893jnzO+aQ0hV/z22fzVBt82jOF4KJ5jEx
0WprTBx/ejee/FKtqCNZM46GXpg8Ix1ABJ0PwHCDfx7xr5T0VAxb8KWdugkd
GsVApAAgXScWR0V7Bipyhl3AAqg/bJ1m4ki5PrAZTQHsAs2QqY4gZC5/4G4m
YfE2fWG2j4EndbPTNUwz4w2MBx4feUCFQ1MkXNAfZ8dXfOyCViA1f53Gd6ja
zoNHn03sCDgFBmIZRN66lt8DKZV8CFAIIQCwXzBwo7kahEZCTwb8RLZokogW
V3QCZcsA9DODJ2AoaL05j/B8AtU8sqXJYgr6NTsapQkMfw94qZNDnDuxSKhO
LU2o8EPnN0EJEbhVn4RiRxxUizGuiQHyHOoaSlE28vuRk9x54KTM1emMC7SX
QuxkA6hPsEJwVnAKZofgvIW0vTpzJP+BRwCoJEhOEMznaUSmy0EOqtUZfwL7
Dx4MMo+4c3qK3LFMs8Cd2yCsGGcSr8oUT9eT6ttNFSD3yfdtD1QDTFEkUKg8
+VDg4wLnC/9S5Fr4F+SRbrYX6LqATuK4eSgScAAeAQdGUpKSdwvqhePRoX4b
tKsH59uzQ3XqUK1JJtJ5hdPKv6R4egPhDYC6CiKeT9jEwx4HhjzDxDbLMg3T
Ar61tfOICzrI71azWfUbZg1Of8iFCRfilnqXHhxNFgN/+jEKWdMRMhfcI4/B
AsVVxwjuiVERqIYoBozutWP7LkgScEg/hew6Cua4lf5K+Hes78YBizk4YY3x
9XDA3o1GE0IqDvkc9dMd6BYXpiQdc9G47F9nMDQB+biZ6gqz+Zu6y1eyvtQA
M+r6FNIuqgcwrtn25W3gZiMWzE5A0mdpgt54xKW3pHQmGSDYvDFsFfE2acqJ
+qhQY2fBG3y5RBfGSWCrgXr+AG4QHBMxGKcU5tk67RlWi9XbrVPD6sn9ujgf
XoFnAhYBeZ8LLlneAynrZB4Ag2piKPSVjwv2NzGcRY02654/88X4OU64N4yi
IKoejq0PQwiLe4fGbeVQjT00Koepf++jKg2E+4UH+XCa2/B54MGyHN3pzyDb
2dESOomYuxukGhrsizo1TDdh1ZDcR73lS61gKtDbgw2IA/eBTyZiprxXHyj8
kyTvlCqyqCQV3QPAGKK0gmjItkxCjlbcJzf2zA0wqgJMlrCrpNLg2MBjLkDY
NhhdXv+jMbnpX/2jYSI3YTBuI80hQLx4A5NPMc8iggI6ekeOU0kcwc5YhmAS
peX4odS1rZZhgnZtt0Hq2lLqBOQtoEvRTzA9WJczL65twf064gsMrYp8zFqr
oNsXBkMhVtuf2zLqO1IhTAnOCEAkSxj2n8B/J0LHJ6atvouCx7+imF/Gq2oF
5PviHeZ9QL5xxek2pOU2l+O+3llCwi6x2MICGr6BSH5uCyisH2e5LLmUTkxR
bYL0K3hsAUgmnMjhL+hRQjR2aYeAZW0Hp6xDA45GTYhGr0UGpH0CBqRX8Et2
aRLdp9O0Sk4C6hfwrNGxUboQvO6sV2ySGnYuHGAi25DeMFJnZD4R6MINNspR
BR6WzUQOurC0iqdgA7PdlNElGr+1WYaA+LaZDHBipULiIAPrQ6U47R69hSBc
toyoneg4MaiFguP2jI4Esu6B1NDcjjmmZijjI+KbTqenOVu32qxKFxCDYE2Y
QvhMt2K56Tbcy9TrC1lSoCBBeyutIakn0qIJ4MFkq1KuRA9EIxYIcee4Z7Rb
BSHOEC4SBFpP0FMgWhElcpI3/BH8Sn6TSno2WgUp6MkqtCmKRiWHR9GJtTwX
whtHXI+lq14MpMTcBeP7ETUK+GRiSpAOkpAauSEEh4cII4ocALRzbjK9eD3d
oriPgwrbIWcBjzYIr0A/kVOMP6Ti/6hFAHB8q0eOf8MpkZgvp8/V3jvZwdoI
a/+IMiraG2TsX1qp7iByVv1Cl1TiKE2D0fXfWHHgn4SytYHy/oly1oNXitlg
EgJQ73LM4atXhzXdDlxj4sJPxBEJUPkXjkgQijNySuFnt60HWFVvjLCZcGWY
FR1RaCZMPW9c0900zVsAEG+8sdOtf45tkzRc0yFZKxo8mJHJKSkoN1g5C4GA
PrreiFxlEbiuHennT6S8MG4Aj1XTNRijvY8C79xO7BloTcV4ZtZqekDfNSnV
1u2qgJ4m5Y8gZ+RZefe0+hWqr0NC/pBC2XiqswlDXEMOyzVQxL3ggX/yMT7u
J2NQYsLOlbRXxdYI8uOCJspsHKKtIFSECMNETL5y6RmcK3hUUCpkJEItShJ3
e6ea6Gh7D1MYt15lKu3hzfXH/qAPWsvwhNHIVs4i7Qh0KQYKxSMpou7yvqoi
zPZikm/UdYoSRFwFqSVHvUBLu0u0aOnjfM7byivXOJvBLkHDVDoK1EnugQKD
sCShB4VPqRC3NgR4/2mQNAZhC9eBk0sPCC4b8E+RtzfpOPe6+Z6gxtB3/CD3
4sD9Q/P73nbcNOLja9icFfiFxq2Y0TSIjCkeqxZtWcFz3AevqI/tZ7R4rusA
FsklxOT2ivdnQZqMwv4DrG3PHNdJnokxLwXOTp8PmxprHg4mGGB7HjllcDFB
zuIAlNWCkzb0xIwQoOOcFIbb2rQwVM7jOrPIBm9JDRDs7bSJvRvJOkA7c6iV
P30CB5vdFvDEXy4adAyLsb3vL7CdNahj+BQGMUyy0a/OUOkyyy3LbJ3t27Ao
8ybQKy/ItQpCMIWVRSzCd8vSTU58DXrKAQeHPDmRnIbzVKlig4hDel1i+HGr
kzG86H/W5Hbd2bDR4NkunSfa1CXo9eARk0/r4est4jHdtDDSXhZDV9FWRYWN
mThUypR2nGoSJ9JWmPKZYz7v1atqt2bIWwQPAlWR7Ako+4sZdoicQtaVgwG6
hjMjCKbdmB1jW8OU9PfoVuvYKuY/ixZWBetV5IcSlfWjmoV5PQrzjKT0QK9D
BWG5KZau34Yuk+0lGg0UQ1kCGe9yKK+p8plG8f4lBIPFF2xmz+9F9g15rHKl
+srMXtmO32Sf4agHpPQigYsQB0oUqDVwYVtcGpod4q9mwyhuAwYLHwHwqdCd
6882xP2UAAULxlQTJtfIbBNu231pQb9mxwk1WkIa8LwB/Lsoy46JJBxZF0FN
5sABlABBH5CgjMoSNBlfkC9G1FmCuhOzaKHF+YEJDDGwtmm7oS8TKwmUSRbm
lMqEou8/kwuyTTjW+vcKSa7K6XTbjEbLYPW4I+97j9dUcUbfU5E6O8tgPxl2
7QWb5ivfYX339BGfwCtZrfhiJ+FlQP8k9fI+AUtBUJE7mPrPZAPVT5zC4Vml
z7Hi0zG5oyftdZP1/fg0XMvGwDOrYlr57HWpQqUrSqDIj5d4G6DdCYmLcDcI
7sE+3/P8MoC0AobigZwDp48Fszgsh+5gGLrPIt1+0iIv6aTXXeOJ+pCvWh30
b2ge8sNHYW0TLi1kKBFWwKR5ziAGatFvFbkC9VRVsZOfemsOTHaJFOPukukQ
iXjPWd0lDGxz7GBRkJAKn8hTfJBTgMzwp7mbglm9BLLxmg13UOXhZREJ8NV1
5k7iPgumWG3jBJhycmKcdiRXbBGzZNqTXFvtDg2aapiHraC8gF6YUyZS+uBK
T9SRD1T0U9eLfqD5ZeU8myU6m22t9UZVTpK1lldrlHTrSxSu2xXGe2+mt103
F3u23MvmQNmlY8aqsrs16vu2u7X67ru14t2ZeN53CVQclaX/is3Fq45in5aO
L51ra7+eRS/2ZInh0maRXi3tWkO/JA1YHCZya5tt7bJGq6xRZjpER2nQL8Vk
W8S8OWV2Ql4ejhUnET7+2i4pn3lzvcwWKiJ0j2cTfMN32AQpN7VFuGG+v5rm
FaWHda3gURRqgnKdgS51glVkh3fPX38/PcWqSGiDnfV+N7+iH4ln/eB/u2r2
/88n1uu/5yCzf3LtN35213+bZs/K67+73RbWf7danX/Vf3+Pzx+t/94UkT9Q
/r11sKj+PjlrmWetk9Lq707bsDqsjlXQre9f/jzAlMgH7stKMnYD6hldQgEL
qh4tHPjkz+w/fj5npz/Cv7ZKf9hovkHvecL9FRWM6BxjRQoOd7SFlMmPIdhG
pwakDmvImSf8xrjJJnf8GTzKiAsInEA4EwsxP5YgDGiNUTSIAvtezoTpA/I2
sNqJL7FmiRb2bRfnILRoYZobA/Z5EEWgnt1n6a0smuy983Qms9vgGIdYGO/P
iQhgysbKcj3Mw+bOLblByg1WlfCC44PR8GYw1KqHXrIFWE2ELMR+6BZzVJPI
AZNtJBZ58g1yw69Gk+GZVmIpYLAzMSlvK2ssCu2vWV4/qq4VVE9i0fW9ABee
SAGLBvgwJgUaDK935Rp48yPHMBkgQGAR8S8pMsqJZbJcyAm9ZWCptwpkGz7J
hILIkq+HTTDlb6DX2EqwC8tmF1wURcptNtgi8CuJmpHiBdsX1w75JCLEmSEW
AZs5K613g+OiVhtzXi1DisgvaYAliK2aATTU9HvbDTZZGpswsVeZ/Hwz+myA
88NdA7GfZqlyYBY1C7hfPsGuGsydimSl6AFGuwIYL1iqR3PyGEHgQO5ERbyA
g1AJDtYATRyGztUjeMI/alnK5qRldEDt9E6MXqdYDrqF/jndlZs1FL0p/jhQ
zMwzB0IEGXA8IRXbFLsVw3HC0jRMruGZd+Is5yQ5a+xjY3udjdc3ow9Xxhlh
5doxjchZKWcugj2C8xXyhSV2TwjswR6q1dRFyndh2lnHdDC6OkcM/EVcgiD1
KizObm/DUjS3S2WGWL6DeBxgnocp3kuJdfegjcGbzC5TnCRJwOSQCOsyVcli
FUhR2D6LAxfCM/d5YPtCQ757HtxxUGT+qpqYQk29efFG53iI47sDj1yLgEdP
WQDQWaxShSd9SWLw2Lj86y+g2TCPv4cTQZiImWGefHVodTznv3hm40htyYWr
pDLFyrJiQu09ey2WT8wK1bBM89vrHWqmYhS0jFmp7caZf/GTAJwPdz+7CO/h
l1RYGmCerHFTdJDAqn7jrDmVBBFzs6K5jIi53HL17pRmnbaj6yxRoWH2O8fX
509kIe5QQ1CN67KBUA0EizUu62/4rDFbHCWse5vqGGp3QUwH0mrIbkk8opQb
t5XCRQXJDd5UXIqyM3xUqnQ6nRaOstCPuwgX3EqC4VO4Q7RgU4ZZIjIT7GJR
/7dwH8uczvOqT5DEvAWPLDtSL5i8RFY18D22UJnsuXobR76apBly2WY22Vjk
pDEpqQw7OIFY3BTQVVK6umPVXPuoyzn4XKLBwfdpbPAFU1dev2bvlaCNpIsX
Crdjyu7KF0vaWIBYNzum0bWkRYQpLUQmYWkI5m0p7q9ZGAB12osp5O1oBNO+
mELdmWo76mVcoWTlHh+vvsvHq2/x8epbfbx6qY+3w8vb6dtsH9ne1dnZ2rlp
ivYCKluxBbCo0rcAaTp0C4SutraAFA74tmn087cFpnhUyoRHSJgqC9wqd3my
/0JGRHnqFV+qifiDE6T09md2KYBv9aqXgmOUdroKeeTSr4ZQSCoeFYUFfhbE
YfCKtoLUsQyFhBUBUSPHt1opDOaRwSpz+mtBhzgz2wUww7sfzX5DMqEH/SNp
ycH1ybU4KXHLYAUlnStDCsQAJ3ppAAjGmCAPyLBjkHXIFzlwJeh4FyyeMflM
7jTxvKyDzeBJe4HLted0Vz/oTyA4t0FniRAVmUWwyvSRkZc8Jh2HZSQL+7lQ
agD6h5QhrZQXMgvV1T3GN8itlmlYxXipcjizFxIDsqq+9nKjfN2CAEklgnFE
SLJyevSQcdNAtKcixbnrquVFCQaC/ZYEQ/1bEwz1PyHBUP/GBEP9GxMMkuMq
wVBuY7aqDzV8/VhsF37se/t/Ir+9lv9Fiv/0DPDu/G+vbVlmlv89NnuY/223
/5X//S6fP57/3RSRkgxwd2sGeOtwygFbrbPWyVm7U5oDPu1g8rcufv0P54Dx
vLO+u+KzyHbmLNdeaSxekwV+2KBJH5RPrlnJlw/7KpSI7a6EsrnI+8mClnVU
QyMOUmhbe1uGjOQjlV7Qt5GIOstVFPAZmJUschBK1H/gEYZJgwzB9bfUxNcU
9MTXFORvoKSiHGUdJ+2bGhR6NYWfGCaSDRCVfvJRZ1ZTauf4yhK+mzS3RTqS
EDs0QqNyGCypRvFQkVs5BIMnWtbfb4lDe2FB3J0M8oTIWlv1aSvbnoB40Uf2
hByM+A7Nq5aEpUFyABlN5DAskedWMdEhvpegSy/fm8f5y75Plb18e1rnm54F
y/n2VNmsFBzQK1yCTnH/j4VECM7Wqda8vPy7XAh9JQoY+w3R0fnMK+BmfYCw
7gYjSU3Aywd+VS+kCguNZczy9dO8IQvaDJVq1SqsUF6Jm8qzX9D8VH/kxCJN
JxnYIh5g5KZlOrRIjfbB6orvh8iLCZPKhhzK18zXS3kHoHo6h8at8umKgaOR
CJewcihK/A6113E1/6RAPrUo+hm+EbjBAaJ0Ecj3kbOQfv0tZ/GqGHBm4Yis
zz5G4GvnHRG0myeZ6/sCESpcV6zzgCVbOdfNOTd9qbjuXWudxROcUxbLFzit
d1SJWQamNVke6lUjiJvdJD+To0jVAWonMhsqkjZ4c6CllGBn1BoqJsulSsxf
OG1yAQoqsi9Rys+U1p0dr6+F8lS9MlUVocn38LBOS8tuiE7sUV+6QxAgFbIk
VQZE4qsuenkpIoKRpuJfUkcUjf93e+/a3rhxJIzmq+dX4NXMPiRDiCZAUrdd
2UeWNLZ2dRuRmiRHUfxAJCQxw5sJUkMm8X8/desbAF40kr15zzPajYdodDe6
q6urq6rrghbjBDK0nDaGr4GtrXZr4+2J+hB+M+LIG1JflhkKoRkZmKlRQ1HG
JDewJx24s1YbRstqYrc9iD97aAFJtExM9nodbwNtl/FuZUPduk3Ekk5bP6Om
5IHM3r1ONIlUyJpIO9/jQYAy6PDeDRZizOHzLEWV0Rc6d3ooHBE8ucuCBdOw
yRW7/yAhUBn6KkU91iaiI2uYAtW1iWdjA80qVnbJFGnKCn/jeCMVp51sdBy3
skEj1Aq3xV0KW3VibXnYImSSqCFk8xpa0Y4I0QrKtJUbFNv+zbTD9MKGjib6
9vgLhXXhkoKqDZvUqwx6KVcCOpkSt+7Y7Fdc18RnE9h+BNjUZrLs3vnKpuT4
EnVkDcq1oIpB3RRBdj0w+pYTnHMJ2M9Ev9JHDLNPmpi550/qZbFlgjqtyxRq
dbrbS2Yged/P+WxxsoAtwjrsG1/g8w1qtdgTvkoRaGqh7eU2cQmO3K8K3fE8
oVzZz0wElljTnUJ2Atb5QDgY5rlPqGskRAg2/Y4S79I78Ta/805oxg5OyGFh
9rm38Q7vnvhoRE38uw3bl7FWo41Ua9ScG/82/8gJOiRIai4/bOy3rkRkUtO8
OakT524uQoymtxvy6uQeTnRNVZniEu28i3tDvD4gshkrfQ+q5+KH4Visv2vb
NT+owax2LX55WsieZwURJPClu/P1lNmMRPFN0wlaTnaVmQ5qtvgKTc8AHnAC
4u9DZGg6xnBk8X130J3ICWKsI7AXscXgWG98yVvx3uOFyQwEWuRVgM8+lCbk
ocrEt1C8GABz3yxRLzY/N47xIgtk7Uh9MUBml44hDiHStGPqZOenOW/+6MmA
P/m9oG+qlGz9fe4Zb8pM7Jfh6IDijrGX7YUKnEWFOJPTbjLqde/k2DQ9cOtP
8ZzdHy/u2faeVndnxw93vHIdSF2tppEW6wK2A0QIwbNjvNkINm596xslp+H/
G4+HC1tWc1tyFBBGE7Ixz64RGX8BILktDI4AqJ+KJjDk8jVOx5/kZxyz1SE+
rtMj1kt1uZn3B2Ti+E/e0fH7k/OT1snFOZyhQM/H3Q7qYb3ZeDpw1S4lHBnF
slITVQ+KHHiZQJhMFJgMKMh7FwOWmzf2N3hzGMsHvLnlMzV5HE6BCUO1713s
ifEGaQB+wd0oKKcIkgUA6FUm79/Iv/wPMwrNy4Ojw4PTUzXmddbF52/+NsDU
q6yfnglObPLvD08HK38rgEa9B7Sy6CldGD3IyECe4x9hDmCBBSd3nVDqJEoQ
IJ9OIarROJZYbvpoM8EpNfANFdZBWRpVjMpS9xs7Sgv5Uqib5myqFndOh8NP
09HhY9z+RI1vlFmJ7zb3MSoEf0SBIWcZA1/DKr1UIJkyNHpwJKMDjERPVJZK
7+m4Q0/PNPvk3AtCDwfP7uFXHkL2hbiWOh2MWTCbfB4azYgRpDfZyYztLKQX
5B3kPovc13poQXF17ntX7+kDV1fImXx47534+N9L6oReHFM1OJRHMfXUmxtv
VzNaz56lOMpSH3fDyaP3eTj+pI5xQrvP0dwrxpWHijV+wrCArTxLe8KnBBVs
NFfRgZQSUqp5na7cmhU5XKrqrURjRCdE6kXFGga2GD1k0/3AqNBqzzjh4g4J
aZZx/w5oidWHWxHd+qAqQRYEWqrdsRnDhBYLldHDQW8uHRFLxWpT8vJnHTnp
+ype8arZ9MLNcHtzZ7skUAgrvN7OHMnZ0ARtpKtGCqw6mJNHYbdNHnUktciH
jcmr5QPuk5OzNSYkPh7f/TpDk05O7u1v2Z8yN8XKRlfk2eFYfbGbSC98JWv4
YxNSOPDVopgor1ZPvDi+XpN4wAtjV4HHu+ndHcpA05H+VFDhaL08a+lAKyQy
+8grpmBSorXkSwUbxRGu/f50ojakHgfpaSOeGqEIrzfLkfqDGiRyXTGkWkns
9KTgR9sJh0H2GAo8gF8VQRXhvPfooYdxyNB058D7wTv0jrxjrwin5ZijQhYP
vOIPXvHQKx55xeMS/uFncGkPvEqlArXhSwrQuEj2iEpy44y2Zu+h6x+9n0C4
+2+qrvFjMFywwfXO9dFL+HPsbnD1Taqc4AR0//6i7UptMLbGOKZorwqxkpDm
f0QQODakK0qvw0F4IN+1RpqEAnkfT0YY8nScEBGkTphZYZLHCAcszMigpoOU
Rwo0Aw4BQmNQmGNbW8KI8cs1mvaBNe4ou5lj7yg8kmY1hhbT/+6AjDk/C1FC
KAqx0mEMhogok7SGXa2Q4BMLZaQhRvHPOYdggVtX18dIK8gXIFs9c5hR4Gfh
27iZV9yX2AB85gBYiADlbEg2b7FDaMi39tRZAXzOdD+tN/AZ6OmhhpWMwWAy
bbfjuJP4phhAx3cMRaIyfTi4gMmkaITYSS3biTpl6NhC9TvFdBBDHDYEBAaK
19DL2mS+Kb8CC1DG/f3XFzEA5Zee/uUvPvrLwE6xmQgag3T/gXfDfyW7kNbL
eIHyy9iA8itwAOX1D3+6EdfzfsnpX37hwV9+6ZlffvFxX37BSV9+4SFffun5
Xn7Z0Y7oj/lRzG54Uz5W5zz8fpVjvrz2CV9+8fFeft7JXn7psV5+6Ylezh7m
5dc4ycsLD/HyK5zgZczys/bxna39vNMb2h982eG9iNrTaf7X1HH+15zz3G7x
5Qf6wl7WOtEzB3lm13p5zrTyiQ/TGHbIe/syfHqX7/uZ30LpvSPH1Ns8FtP2
3WxY0mOTUdsfUt8na1zo6rQteE+MwJBwkuxzWU/HOdJfpY+WXPbF9j6hEeHb
QstcTyHJmpDWv1AsXg6TLqKe9jApng8H5/FDZBfq8DfOh4rKzwS/Yt3L2Xug
6kKJimxIIRw0Kc5ASu1DExAISYHLVHHgHxTMfpl2AfEoxhda4kpwxxqZozS2
q7Y5ig3CJPATdp1MYCitbh92jgRZ8Qq/IBIIUYUav1jBfZrTO4okc3Ev8X1M
QQYXoiQBepvoYZ/Dt6b397Bn0TY6xsuhUYSZvxRuACQs3oO8wPBimE8VdQqH
7CtEmsqLseMyJF5+6iJVbttzUvlwPQnbk57DNGdVW8PRGe5LgJK7ttYLHoE/
wX8cOOibKPTs4lwyY6QQd0oVem/fbSGZwBPs8mZ26x0F5rC8vJlDAXOOM3ie
c9orWvAGRybdNXsGu3g7DeRy01v2R3aNDCJLE05XUMVpUNJx54tThltBj93g
UwrAwH5lQJ6F6rGYlIdiTO6CNv2W4Ou6dEjI7ExArUxIKcwfoizwlUbkKRqz
vT3SJL5sRDMLhbwIdjZJJAjv0MXwVlh3qJIOfJ97OaynQhFc3NlRUWbLKLU6
stAYENCYRwKKCC/MYdGO7CsLtdNU9jSNNZxRjSMrVnc4Uqp9tQ3Vvr2xVrFD
w0F8nBLvOsVvwaeSgJwMVyTVcCeno+Pji572bggxS9cmR/dx0mwYUg7L6wKL
ijLAAnIQsUlSN9mTfQOPR961PX94DOVspzhq92xjhs730WjPK0Llze+oDjYs
4QM2qZBKsot+D10gS9IDUGRKtaXsd7dqHB/VCaN7YxB0GvrT4Jb+h7yAZXCC
WEqOTHfkv+e18SKCJDwAPpoU3ROTGz0Nu7gSdD/UjVTMM2vJgGDl7S2Tnc0t
Sp9DTlzKyHAnd/HkM9Jo66Bi0pOlyAH1RHbtCdmGKdmJE+7hhBRnqYUXtQkt
Tlnin25z/NOtTKQ6jBLPPR9aLPNNG+PK+e0A/wlu7QYwFO0Ofsh8NM4+SbEO
FHO+mJhQAp43y8KTarnw5IZprMyc547khZVGMJGDZvMDxduD5u9keZAPdaOg
BrsuFIpPe/vkG6Xc18Q+0n9/fU6XUcAY+4WfU7ztz+/EDa9kR/RDGDwhbX/n
dFXykNTkM1aBgtGStxnACeRd0FnLYSFj66eTpgf/f3Hd2jy7ODoG6eb8yPvT
yemp9+OFd/Cng794zYuLc89jfcbONqMw7XrATk3MUaDOFfsTJU+xfebW9jb5
O2zXqirnJ/7BshRxVED/ejY/kbNu1JksHNYgqJo6oX94dOWNKODtTcXfQ3dC
auJXbo1tfQ6eErQW4K/BNi1KqbeWaW3WzklFaMgu0SUclpklksIsfquMGuIw
HcGhBQzjoM1HDzKtI2KvdfhKciYUxwPViZY6eSF2d8hCabvR8AOD8ZKEy+X7
xZLvHt+y9ob8jjnq/yd3cvTJlG1W3otiP/D7oWOluchgz1DwnE0QcEd+QWab
e7plR5PaSXowKz6BL5Z+IVj0CdUJkAtrZTmmKCfiOFPBRIU47SMTqXwB+foZ
A+p0x7Fik/b7xJm/68TtXgTFqBrm5BKwOsq+DuM6U4Bel42CLXcEGyXpPuwz
72LoFG5GKMctBDLOTQENmo+V0NOO0av3lgcmu9Q2NVwaF4RtHtaKHOIGap2P
MMlwbw4o/IR5uRITjITDTZLqLhFtGFlHo45WDv3uPch0tF1I72HimBB8alsc
5NcEMJ70AqTSkx75yWuGE3n7vyGL7xZvwPc3vr1ZPq1Z4M+EzZuRSAx90UNI
D+FtPgAHjvdP/qsMyFDJD/tGiMM0lgjhG2IAyBqywUBpd+ING9SkFwfkgkoY
+PX+HuQBAN2c4nNIEtwG5W3aaYTG0Jdkn6fA2quIRU8sytDP0GbFFswkxVkh
M3OSHDT7sPSiAiA45JRzCuUiCmnvmpRXQ+kUpLeVahhHAbNYv2M0O5vGsjbt
4pYpTcV1YHjfIf9334seZG+3h2O8cPh2HI+G4wm71llMqBKTimiLz7VP7PfM
x+wEZEu8s2P4GCDcGN84ZNqdo3ygEJ9ksoMuUjkVbI0Sq5JSpsXoveTOvJo7
ZcMiuF6Da6thlByCJ1muImanUcX574Z2LGo4pJucYaU4M0znLN/k/GQwcadi
/Jv0VMTiWVcJ3DrfYQWiJHkBOniYtEy7NVs0BO7jY6pj3S+845QFVNO85zYc
gMVzMyeY0bnzCXKXRqkR8xYmV5MYkeDBXQkjiPr8fmg0yp5SKZOnK0d2C6p1
O7abmYnlDWACyzguSlZt7Y6qDPnsOZn6Vos/p4KyWCByw+KkyjjUzaQ5HWHE
iomb66zl3GCKtgAojcn9TM8jR82DyLPv5cgMSkNG0NqpEZUNqluBSY+3dGz0
HePQ4sC33487mDw31dRqwnPzkS+44vJFCJXpy0avBR+y4edTnkWdnhF+3w/E
ylC3MtkMc1piMyV+cXPfo69g5rJU0DFesfRMcj+lEoWvNwjlZRIPniyPEvum
/v0YU+Y4U/zpx+NW8R1B96coeQRoX5w3nd7ZRYRbiL9ytc77ZscI6KZHWC4Q
e1Kp3CivE+VqueG+b920lz9dXq8ahi/fKJnPZQnLn13CoreY52rY0NMITqB4
3MW7QLyqeOSQMRKPqFCkXEl4I2CFKQyqgbh4Vnd3U0r1FNFQno3+TQF78ifV
25Kh83lqwmF/BBwzcrbYINEpZe3CIvCBPjCBC/TKdK4+4d0NJ1EeEN/YxeTG
fJ9tcZroXGdoKPmMII/WUeE8uDVx8+QdHKju6CmU104yZRKZlirlxWVIpu+k
1FhMR90VzZLZPFchsdvG+ED7tnU33rxOdCwbUrehZkYSHyaect93T0nLpyyo
1uqUtDgI4DwPDQowCV1uxw2yt5UwzkKUFc1CjTo2xiR4vpAKtRU9ML64RTjn
RGByA6jR4YvZm429Db+Cls0FCeeJP5nTwiq4wFSVXiRWJsikZUKRy82PVYJO
Q/StKevnqdDfm/RENOvRP+IL2rNGUrFkN4scUnt0aEO+Uk8x74X+MqYHsfKh
4SWvPRaPBoN6bS7lHqSY7lFkaQjHGcUdDKc/1DHr0cMXcfysg5CvUxoRfEEl
JTWwFKrTkMIfgLGUOE7ZYuWyptaw4u9pXfxtvicyLTm+GXfiMfV1PBD/B9VS
xZwgpXUQ2EnTcAOzIN8ST+Y8ZT/6ngc1yZsrtJgOJYnY+AGkK1jW0a05+AjL
UQ1GESXNJ+wwW44Dp1PHBRzDJrSuUzLF2tMOH3IuI1WO+QgE0f4dWwsZ+CAK
qwc60GDcVCCQ2+ZwHcF23Tn9kEJXRi4MYN3TYVYJFDdOUE1AFVhYCiRBocR4
2BZo8CCRwgy9zABCly2CAldLmBXkrctK+ojNywYAo3G3zUjLTXjXtqeKCO7W
yLM2CPCHca2lgKG5zsQd5iIGQ+YurU1KTcjFLLOKhCwGGLmCEdLLHAjo4tzj
QUHAuUwT4zFiDogdIJLoqFiL2T3qmf6zg7NusZyiXHHnf+EmSyyfIgmogoEr
cFXDesOsqgiWuTcOE2CfOscqpXVbSYNFPgzTdwpG2ZLikRbD7mQwUBdY2XLO
tTkNYPOEt6wqpUqp0BRYS9Q4CCbVAE+SxBsBSeDQbMgGbQDr3B0PB8gUbhgb
Q/gx14EGcHmoo6SHcbtRddWb9pM5ctxTMlek4HG1oPLf097cD3Z3q3pyZB2E
mY+Mv5Vb9H0xw6umGTyTG2mT2na0SRt7AGtkUXa8ifD80Bdf72sZmld9S+K3
bNdy8kL9TfuDRaHv+FN7Ss4nNfV3bjPAgQ7eQ4tH+3+KXZTKEl8SxMrj/6w7
S6coX3uz6OaSrfLsa0vZ2ZlbSy91b2nS5T3/4jLAsIckINSCwBUQ8G8G8y+m
KMEsox9wxAm6VroY62uBGVsccXdZ4EmkBRd8UpgFYK4uyPM8FTSz2UVrFM1x
H88m8QDjffhX/rXm2lBcutIIwOY2s1yN0XXJpgE2WZ3l8beLYJDCjRSAcrHE
iV+iI/+ATDy1zTnFABIlBFRF4/GobStspBDTUV7wkNmoWs21VJPTbE7DoxtZ
revxCy2Kjq+q5EVMXtkHGRKs7mTZaxfO6hozTmyByyp1lfoi653GD104BID6
kyqTB+ZaOQicarsMp0bDDuJCodRICqNLwvZ4mCQ6FoC2hE48iWlAhwvq7t0I
KChWeZniacgR0IU1yTYL85sFpZzTyLnAzrlxzYsSp0KpmmBSXQp+ogxDs84k
jkMn9iPx0lxWXyC6VWWIbruJKayztW3HhlugdZCpOLe/qcIsC8Xyf6FYNLaT
JiS4s8sXC9Lh9jaPf9feOUw/xA44NyqNBKShW2HFTnwykSry9CqIwa2Wcymt
1Ss57zLXV4gffUwPrK+su3TYohXQKBpzPg/UjUhsHqqLoguMe0iHF540HCMs
EPVBvbblh0qJKneFmHUbODLgSPoqWR/1YLwaSDClX6TKxVa3IumSwQKV0A3X
RC5XTNcsloa+VCJAXR1/PL5qHkstE0khdxIcVWHB/ARaB62LM4/yId5MaGSd
bMAi+vL16SnnDu9YlcdUWw+KhF6VZ/MDimEgre8tGAFKXPDeThufC0mJzbIM
yvZUuOA7/uGOXL8jMw/1/mYP2A5/4rOErosXfZGrw3+hgRn7iHdea3iBcjzn
gneKiiN/4GNMVZvkjFimfYq1dwuGYpmihJt41UplIL4r+ig0Edwx9oj0gsma
P0cjosNR5+8RZRCPexymFM3RiKiN2KLjjokaDomyENMlt0TDo1v+oL5t2y+N
KjNtqIFmx7CO+EwXXweXl8fnR0WNlDjjxF8073IunU6dX1KS2dF5Hk4sGaHT
DXkfwWzHc88kCbJdDjRfMU2M24jkblZ2b3ccnHkRo2K4SAHXFt9F1Z0s63fm
jBc7lLN+kzTreJiLNKbiqxsmsrjIcMWxqljWL5Upi7G0AoY5Elv3oniUgT8T
BqWbtIaTqMdHmWNfYjwbkJoVVB4D5SSmgJ3IQeOmm0CW8294xYib53s++k3k
poCiHGFU0Ea1gZnMrOtW61Bk3sgZoZ2lhWYhSVo4jrtOMWQiwuM0Dh1hGKsu
amrsc9LNxDonXWyB0tFbUNiKRHmIGDDq3Es5QGwvEt+1waD5FnONGeFd8/fr
BkQVdZbqlnp10airAzsaROpawR6t41cx7OwgMxy47jNTjvTnRPRXM0ypIF47
ckqavXa2hOa5W5ZZGQrhKgYKiZsYaReD8Cdq99HFNaYJcdbQ3GlILBqRQO/m
rosJb4N6jYlJw8rw3g8l5GSL78SJl+6T/VA/KHC+rn5Ij2GhZGnknPhliP0z
Hxv4WC3NbT1GySGz6ionLsw6XVjs+0n3gUTMDrGokpXBNp51iLPopOlk6j4M
oglipHQRd6lWnyk1q2nVZhlMou4Agd2veCeYKBwOr043aUdjkPVbxx8o/deE
vQ0nZJNEUt+dxFOs1wPMDR00dtCDRunD+vsYyRw9IFqs2R/bVww6HT0pvyf7
/Zw6UsOfiAQNlTirxtI8Bs8Jk70k3LWkw01HctZfeW604mwsYrdMIvS6hW5M
Wf3t/NitTmxW5zFIPTuxOZ03meiUqUFmIjq673OL83P92sRAJ0RQUDSh8jiB
9ctD5WEvLw+VV978klB5ChiZcHg6v3hu7LdyKvabXcBhvRg6rx577bU7VYP9
DQJx6S3xxUGj8pKfxAscQtPenakS8WZUCaZt779UTcdDLvUu6+eVqiC3OKlS
uULJfMhKZJ92z0iVatUNl+ca2qeaaG2IVZ4xI88MdI1XGrgrjJJzKg1cYr3A
FnXpwqeXfNHpoF9UMyWZgsAtyeSTWmyhpalEnt1T6it/NiVpM5lUzRzzETny
UuYSCp0dmwY9phzjA/tD7uW9/ca9nU4NbkGxdYeZeuNif97VGL9KXyylGrjb
JXNZkK6d1rfb7x09caphejtllItmDXNVcnISLFA+qWN2gVaHX6cVJ+mpZYat
hVm1Z7MCmlXdFlpe9ZTKShL81SxDzelU6PD9vyL10de/P+Tkf7of/L75n0Ak
BHFG539q1ELK/1Tf/pr/6ff4w5Bcz83/lEaRnPxPW0vyPy1ovrsZbHlBsFet
L8r/hHmIggbnIwp/6wxQllpRCGsiWoPmcevg/Oj9yenxh6KrxvF/PD5v/uWs
aCkm1SHCfgX6qTjz5+l74G7CiYXYEACzEInYz8ZhIEgFm3cRpx7qxKSYDryy
7pO61B484r5zRCGJvMvxsAMCG7HkR11kOO7QzdQ7m/aAvZKsr97lsDcfDPtw
8iaSmOroMjy6pJEj6+Z25nvnaJQAPV70OghIqlycSsIhcSod+M1bueyTkr7f
Yp2KXL+yjceOa+tXnGattZSedOrfFD7STQL0XTIP0G3Klr+7JEWLNy3oRTrq
j0L4nzXRPBBNHAhlp8+duADo9Ef+U4Aw8BwgPIUOFOpstt4Icq7qoc9Ad6pi
Sjz5nwPnMh6/nq5lLtodQLg6c+ze0g46X1ODDTKLSOPHUeTYrqF5DXTDZgoU
PkCF3noKlEqL7L0T1pw9hdLBk8rgQtRGUBjaiiE4agxUgKwnNiZ6EmOHLYZf
ylAIrVp0IOSZb8dENskX/lHyI78Pi0xhkf1Rb5pwgGTo4B+oKputCcXQhWK4
LhS/AILdQbs37XD8NoYeTtUKK6/Wn5PU8HX8ro1ccj+9zgRxLphqm6anHnKw
PBonaTzHmtYMOXvDAmce40fdVH2UxEYjrNKFfBhWU3ZgQBY9e43h2TdPbegH
mG7fw9VFJw1Y2hJnoaamzgzPRnp+Z7iHvdT0vBn07M4OS+e+Z+bHTYhwUZs5
zP3N0lnz9DirR1g3PiuUhRZXN6hUim+BFm56Qckx+J5y9hw9WXj2H+LB2Yg0
Wv1RC2YOhZWu71VTWA1Vs9gLA7u/T1wU5jIARtNv2dcEfJlLUGl6lLFM/Daw
KbQAmFjFxueL33oYG8qDlvtQDRZ+ykCo00GAtiNmjfkQuLmJ/T1nz7YLpVt/
b1og6GLuXjcl0UDdzFskPhmOJweDzlVMN8IwOcBNzuPK/gkLX8P0n3ral7En
+Zq4/7PmxVULCumj+KK4CctU9t4+sWNa2CALxnDb9ifXa4v33rKmXlyoFOEg
r3RLdBVS6aYAUPD32mbKOfNjYIfn6hizng02pw4hF3v5FX+wYJ2A9gFozr81
kNuO52UfSwWmSyET7XCnkbYSspJEFgr2KZc+z5cTLQ0L9ZAlWrMUSR6obWub
5jNHcnR2CTOtag6FMlouILnhdkgBI8Ldhh9s68yZCwGVZh0MoPAqjJFgYR26
EYs6HXh52v0U48ZPDhK50JoW1uMFFrRnV/pFfadMy3icOSBBpF+eHaGsUnr6
N/KvZPgsKWpITi9TtV2maeIH7W59i8I5iKA4WGj9edwFNu57xonLHDr/1MvQ
+cpSfKAkNyGvd62+a9Zb0lblcx1xoeSnSZrhQuzNb09y4hLyxcupox2fjT7C
uRxe4n85HkDeGw8BYagcOyF5+wEUog8SrDpa4Rh/kRsPX/UqxadNK7f8HhHq
3A/AWQzd39JKYqX2Ld3aqI6ZkDhrdm227nXeeQzr5G7dKbEg1lKZXerKWMpc
faq2s7doG9d2ApI360Hoh4HNWJLfAfqB0n/i2chdzHmp5M9oiebkW6LoNR4X
P/ylWEAXnNmKJWQ/HBZtjnsq+aNTVnzy4cxwLPLxPfPQ8KYweVTmUXwVJ/ZX
T1j99KTZCj8eH3o3M46ugSsCzyG+AFYcy+ZyTHn/Iqa9ON/H792mxojqbneE
UlLs2eNDgyqAOJmlHV15dGjeoIEa7Lg9tx29x7aAXuZrSMLDjvGitp5dyj5I
kfbs5j1/DjWvV4mBrluG1MVpYYl8WpDBFHQq3wW5fNXxthgLzp2D7Dz/JEvP
V6hW/jn2vKkHaPNVrjcCk5rtmXMvWJNfdJJkgLLGoUVhR1DAiBO0/Ld0Hqbw
VwYiFoSHJD/OCI52QVpMW0L8l57hGDhT7Mgwbt4k7gFew/aRWBEiytRrjEvb
QY5LSy6Pk+WKvH8IS3Sv0YQmpLBEPbgzI1ksNTkipOHzJTTFTbaUhFbneBWN
oJFidEHM6qOgjsmy+WeS8VtNS3E3UvMWYy70tdwmVTNzDpxJB0X1HR/Jne+1
DfNLajMMfzAmz3evZaYN5wFtBnnn+NzyW6R/As59bKmjm9Z3yIGgUavnLCkM
oUKfJbbefacBAq+WDb8lIy8HPpv3WhN44/TkwubMQoezNbCh8kq4sLvNEZJt
eHSQP9jPoqaPYqTMgkDcX0haOlxXKweMJVh2yzjbJYUy1xZYrtcDS/QFWgwb
Lvj3KR4P4t775XwwV0o2DM7e8I9bpseNEDVc5QbKF4YhmQ4o+zJLbteDHGEN
UUb1ecuNiv9YCGlys/VVtymI51KiJST6f3hKHl41EtAtSp19yXRbBfaG1+H/
iJW5/H4GuV5X2cQrtAL7NAcK4Gguwj2Obl1HGaDcALlWLim0tsZFy4L57NIT
tYBDXAPtU70bGQhBpzV46mExIJ8LP+usTgMxY6K5PiwJahmYWSBbxoNAt88H
WPru5H2E3HLc8S44h+CvCqX1C0kuyOHNVGmofhC4M6Uw+2Gvg8a1/iD+jP9a
URTgDQyaXu5VbnH2XFVeQwP3tfSgo2yjh+dWYIVVv6evJqzVEQ/P9++PizP7
U6bbUsnIAtKUyMXZ8dkPx1dFZR+qel0M2huXpRt0gQ/091S725T+EUZkaR5x
fPf3QPsUnLwUoKCbxasPLSuBAnFJw1izu9TY1RcaUQgbV11ZDuuXfHyhAg9u
suUkcY9OWl4qEdIlT+E0lZU9pxwvtCpZaWU5r0lAHvt7XXLmYR1qg7mwrVo1
e42UPSPHheWihxrp+ytn4O+vUCEsROMqJXKsQ3z56020527ZUbwaO6QP3HL4
htyxMxotPkYLXMEfRe1P0UPs3zRTuU2ngsHZyWoyaRek1A85h463/sRbbHAt
/UPL4Dab6oqOpcD40WZOma3qLqZTLm+BIFFXBuCUPQWIlbs3YAdAmUOmdcX0
ea5erJK7xKrPwn4pEew/CY9PCIz4ozhIXUsqBc1KBBe+++Lo6LI4YJYbWlE8
oMV4exJeqG9fvOzbz/3upfru5Qvn7H3nVdf+6vm5+iz8eul399f7MCEByiAW
BuCjLP9p2JqOxA9LfksMvbUl7aWB/2z2Q/HXC/1zg2L/E6C0jumhWQ8JgOY5
dgMLyWWU0DzgmKm6e0a8e9WCnCqLCfxRXDnngaukGcQYsXjofUL/86T7j1g5
Syo3yDXCIW7xVdp2YOmrnhael/rw6y0zq1AefLnA+YgzdWDyhNCV9gBfQ3wU
lD4qKFHbp9eCEis46aZuDThhUF6QprbDHT9sLD9yOiM4Z7wlRw7n/tKmMXKL
gckWNBizCbYtgIFsT98oWYj0UfDo42o0MuB51rb5ArzQXPVSlHBYqCd73U9l
2U9Xr7qZ1JLVzJlUb+GkjH5bhT/8win17HU6k3U6Y07u6NYn1mh9Ru6IeQIa
0DGzA93kCmAeDR6mPdb2QN9v4f8l4NVUh37c4mgF2w03GYPcHOtVVFcQs4K+
RbYYX+tCeSlPeBqy3blMmB8AO/Ws96LeOpgo836LVd4ipZe57OzwjgRG1tqR
b3H5KZD4zROw53tPlSA9gaeV4+6rMffTku9Riokd+P3fYvWgW3PMMLLIUY0J
WSbj7gy/umoeTTWPZt48aPS/ydgHrzF2uVCmXyCCpnf/gs0/e87ml0QBcF7e
jaPx3PivefAMH+PkEGSAJrmTtoMqB7V3pSb3Ct6lKFObZKxjaqiBABMXCki/
fncgdGJ23bPgQJwFA4LDoQfu3YQhlK8LioOHhxD+R8CQ3y44ooeHrMncF0JE
WxtlRuipPwy+kIKXJIUgArsTBtb138ITZqb5S3P9tQgwrwvLUweap1l45ugY
7EBlGJIWcQF9j6MB22CKbxSFkcD6/W6HtcyCEjorBEaO2amFJnDMWiCC7n4X
8GRImsSITRO6mT/yf9H31ftV/M5o/+3MBBGDAb3lE3gmYgGmKBvsv52bC3O6
o5mRm7X08cv+wJKbmGBakhMXiOx0JvThjKhD3qLpRRCuzGLPbtfeGNCJfcm6
dLlwmb4Y9mfCHsG/PJ+rW57Vs/bxFToDe2Jl9xaAT4i3VfNDYBd2thp+bdtm
fgg+zoDmyPcI1/CUzxpNgbO4dfSB6s2TNRthJPBHenvxzACF1pudHMGEU4RN
ffpV4av5fc7W1N//Besy9NSZCy0VPV583p4pXgF/LBrqiwZarPKa7PdlqKMv
HupHGenH18f53x3peZPnuw3Yuz6/hiIDxiPhTBn+ueJSjkVyJ2OSDAT+8BFI
XJznPU9hdtEcRKcmo2T1yh9EB+XRlukVzsdRJavWXeuyf5m7Bgy/2e13gcby
LJr+2xnZsZG9mz8cxP4/KJr4G4fveh7sYQAWOtlfVCBMjWGQN4SU/VuVDNW0
RwmgGNbSOUsBLPRMYcn7I51SBi9hdmupKJuuLeDEd0fUXjQietR2IIssArXB
oA0Crco+yzPZ/+0s9qkZwGNdQ2KPxgGoLEcs3u511rqHRXOAZVYA2lnB2aVs
R5BVSQGY5KqDflm3HE89oZcvud7YYa3criOn/17XG2faweFslLEFUcZjrvJl
nqNyw7XpxCCvE8FoR5w3i7P9FtWNr0RREJLf7w/pzD45b2HotEP0Oy7O0fqR
gLIreW6C6iqoZEiMMW3+MhJxNjqYzqoGKPhEpEG5WCFa0pbEYNKJH89Gdqxy
jncBEPhM6vKhmqumnrmUhNLVsMAZVFP3dGYU7RWj4N/G+CfjBDMaDzuGMthW
U+ojgTPxIDXxXkD/DYUkDWGrLpy6YBIOlCI7o+CJxr2cnXghEMTxr1p3zf+N
hyQNo4L/oJGxR+Mp+bGMZvHc4f3yqYfO1NFPi27Dcf3wX2TffV5MH3/TCky1
VQ3AqZtQPB9biOKdk4YBg4b4l1HI9HABEVTfX1iBgVbfYaBt26H4XmEm2NFN
4DvAVz2UfDbsNp9p53xG7dw1PpY2A58WrPiSaR8mSa2Rdmwi44BeLBtSVoHj
DKHzHIquFCWS2Jts0KAI8MwcQGQZzhHnOQfFrqSgqO7YxFpyxAg3PIom8H28
MUNzqdmIcm/eVH0PZiXg9IIy1/JhthX5uZczGX5VDkoWIM6U38JZ1lEh309h
tJ7mzz62LWaYD7uChXIVEmHPRpf0fTS4969UejJJ0WElgmTyvMi9oADtC/l0
3LXcuRmlVfLPpuyXGnB65Jc4dNuD7TGSXBtnl0V6X6p4fxJ3ax4a/rr0rirY
5PKKN68FnKtbST3GOzIIjAPzKEWScLHIuwvpWN/a3qKrK44QIrkAGeHI/NSH
l0Blc9OBy8g98a41C5C2e1zgUDF7BsfD+UpAcCI/Ep2Wagc9JzCZS9UPtSfU
6NrlY8nC0tCKEi3S55jCUYvzO+1RvWrXl5crcWl07UO1Z8twBUuIo1Atceej
HOmpC29566nXnnUDfvExvGCZln6lVfXJUy/Nb02ezM0JvPZSLBMUYRWjhV+y
w1WuWfs0TRAHp4iB2Mt6lwOLBXaY1KWaXcblP2dyaxllqmGTeobHK9u7tBmo
I+rJh/8AJ6HDtBVbNtWE8SBlV2PD3yuHR7i/PqKP8H2elS3OofhWFi/gNO5F
rI1zqYozNmZ0DDFXYbCz5deqa8jPlGsm61Cy/l2lTR0BJs1jBZ3m8TLYPGPF
sotlf0+vRnPpWrz8e7Rnc3UtGfUKcicng0uFKuaxOF3fC+7J37MatkuL3NtI
SWZlVLxUguZlxpruhUImcIaczSAMG/8LYual1lld5qussoZz8+fYzmEuIUxt
g2FmieJi6hQ4I+axyh22K+FE6oYxIXlhyTTpPZ6sIv7I4ip/1ELOIeDPb/13
58PBefwQYXg6MX5j+NDUgU82d6RasmoPRzBYFK1tztiSsSxIavXN5evbIKbN
3zndjuTODBvGADOdu1fShFoG3+w001vPxhoz/Tq4AmAy6JIPM5T7EOQkTyyC
2wLFnciUGIDeUGkKXqBigzI8lpFfkMVX8RAMvpqAz0o9yn/I3Lhia1aPh1b+
Wmi19HiXSm9zmQ1L8Tvsp6DO+plw10zKrMCSTWUtk0jqch8g/75rzvt3w57a
MWfP2TAlBzoGhRZ1shCDfk+0USmtdshRPKiFdeMpjgdFoiNdqIm0nzGRW5Vt
zbPOH5A8tCRqB56SbkpyqFl5NOHNSXIx6M2B2LmnY6qY/MWj8dpH5ROeVE8c
nVqYS7k6zem77VPXSw5TJyHnpZJrLjNiTdagYj2JJuvG1Sot1GQFwS6etZxB
SHtlZWWc2b+HhGPYQfZlkbjWtt+LFAmr9OE+vHxPAKZfC62nngXWI1v1cDOY
9jF7ysDyZQjCquRlslxloUrWjwoL8aWOfFzEEour/M7NDUCJQg8w8qBJFKqX
CUZS8Ln9Ahe9bxeGqjB0CQClIZYFGPrupGB25Ek67AfK27KehCdpvjiZSc0K
o4J2eDiH24WulPHAP9J4s1yUED4btVyFkvdHL6hUvW91KX7GzPtqIPPGH8Ux
Lmsq8ox24ekNowllvsJapW8Pj+SX8iIlFo7SjlSVGTPsGKAZyd7++9OLgxZQ
42/5xx2/Snr7FFwgGiS67h/DP/4x6dnrYsUP0E8rUToT+p9j80cDHV5B7I/J
q6c3x9D3Jof9NIlJ8UkBgqZ0EWh5/1zca9A4biCK8kxVGC+VVqse7qQYjJub
d5ivtQsDed+Nex0MzWbHT/FsDCfkJjSnS4Q1gokAnI41Oh+/f7670gKNY/62
35ZZ1lfeCHW6TzD6Jd60i7eqs+cd6kho7nqAEY77/DUHKh/uFVQ+3BenVT/n
vLFOm+pKaS6lYvTSy6pJxC1ZagrAgDWroYqtDrxFvaZ3itfl7aCtlaQw8Cjd
uVWWmCTKXmED04Zd3G9YR4RlJZUxXbLeeY4Z01Vf7JjwBxt14P9d2WijbJyM
CalGD01R+mI+hD9yutHHvPRHddDmJL8vsYihX9wbGvs2xRjmai1jGMvaxd2w
pB730vYwckdjRoZf4xGu2Hcwyo9quB8Xg/DjMhDSAjbb4+7I1lxygawUPITw
PzZK5d+rhc1ne1m3jLi4xOmAEloj59xaFcqTIsfAMN3AcE8l20ezCbiMtDer
qht0UwqiVVUVrK41t8k/fzt+07PzKbgAnJqweZTekySKBjACQY4HALHQhVvL
6n/gWvvf3FTd8HrWhRyDERircZzZ+lzs7vqm2vVNa9c/d8831Z5v6j0/+LId
Dx3gQurketazu3BJnwPVOmrhYc9VDGMGOhBUMGFeD/55hD2ORlJ4E554ve6n
eE9qMTk/uwlvvUvvBBNdX97M/PmtKVOZ1Xb5dqTR2EVDRisnmMuuc7c9DJdK
7Ad/8i6WMVCyJZRLO9EYyE6EaS7i8Xw5dQFYiCkj/bLg/BwbxtH+L0TrRvuD
FDVUFpt2jRxqeHW7po1gU1HDpkUNv4AWkt7BRmMqUPg7V9c29CsdbE/bAz3D
w8JI3hRI0sxnrpWl/DP3YzrU2ZcQEV6AXkyGmxKSMqjthpwIurFbtU3U3Gh0
KeKMPJ8MRfMgRu5kMWGJyZay2GoukVFvblB2Szy6I3fJkXW/A6A600A7y4fZ
y0FWRIilFo5yl1aN8j+AzZK+imqW2Br15cBIkeTitOTA4NxCnfNFuDN4feSp
V/m6e8ux11qJOoP/LdxBuDmAu1RQu8wFGer71oOXuopCcyjisDEnp/jUoHQ4
oNjNLOiJKMgQDLY5ze4WnNfaW4Lcr+HAJtdrsTPJ4kChdCuf7N5zrlOJx6Ga
dNl5w1ZbKnM0UQRO83HWgtC1RqzrfLSasrngl+PUdH9GtjIwkt9k72T5GXeG
H6OxmiL8XEDjZ+tMUKJoy4SmSw4wOnsMe5l/S5n7Xk6ma2MPfp0TZz4/7BPe
PABX88az+Zo1THLTbA9qbvvThO8JxNKDorCDkArLME0pxxnROfZxsLVl30Sa
gOPPDul7bZk0X+eZNEsE0N8mBnlQl6vF7ao9nzhQMS3bgVVCQrYxAZr3fXgv
gcjfuPoYt1YMtdjE02pgQUAujq9TFsqzV43EEjSqWzzXcKUS5je4Rb7WxsrX
WWPlSp6t8rPsNySWkTJUSgtZDICaLHbdNgAUU+Z8xdGohOaTL7FPvVYWf9ej
rFGNYPbLhPD0xe2y0J8glLACdntrpcU6kT84dFZuYBCa1QzhZ+7KvmSGzxWe
G1vbPMWd7Tzn+ReJzjzha43IWV3B8rwg+qB/QoLyFDJvoIIYW4KfPirJ9F6p
q7EeSau2mCpJJJA9yCPZDTEe2anaHsCzda4405GEirPSFxH57iCJx5ODnvbR
NM/FyL/zdYxqWsse8xGRv3fHzEMEoOpVqhWiyMWry9ODw+LhEcUYviv9Z09h
9g6I26gz2QlqttzNrQNuzY1JUQpl0Jzr/Pz9xdURkA+q50eldFVfhuPv8bPS
wN8PaPxcmGIKnNs3elaH/iBkYy38YZzqXMW7St67d0cJ/uKE1OnG9Hyx9G5d
w5rNMjFXNTruuurZ+5f3N6/Zujo5//HS46tYxgxnfPbslNWMNUFVJHOERyVz
88/VQjeclBSA++DoyprnEgohJB9PWDF+dEuYfGlTSVNtMaLiWBVDJr/XE+Bf
OHiXshm+mtPgBHxu79RdG5S9h+Vpdl+L8V5Hgkdg/dixIIcP/wagYy//YCcV
R+XfDXRnBnBrqj9+U6jVmMnfcXgESzeyCnq/jboEoOYA7dzeqc/Ql/ymoKvL
Xt0J/50QztWYILwuNeTW0pk8G2bGlmGrIXtw1xaxfifNCK7Zujhrg+fDew2f
D+9zAfTL/QvUJQIZEKJJabsL0qdW2uaDennqvLWQI8XSrgaJA5H3TQ2R981c
iNwnz1OyLbkxNDNy7s6bK4PWpft8eqajyJMz52tDX9ZTmz17myBRgbezFVRF
JXsLjRHvbJ+aisbtd6LIS5VwCCYlCsrvXJih79TLQbbx/cYqoLFWe9cK4a+b
/tsB7nrUtHAtf4NNR8nvgW3bVVYR7FpqkhdD4PXC/pA8gRemlwZi8rxI67sS
ZjoQia1w/RyPmzHGUaIOBDZ0RQKw2apaVqHYNrNwGGpkJeheGI+Ew6XYYhgV
KCFMbtw/Pj+GIZNYiSMnQVn22HWUUqLAmdwZYkaUx+gp9jrRJBL4CMO9u21w
J2dKm5smOrf5tfTGiQFW6aKJ41WpxFZOdta9s4M/n5wfHf85xeuo+/CPHCPQ
iqj3JfEAK/4xwSETUo9hhEH1NgO/jwkDlSHxtnDTuzuuDPKsic8qf/ePZeL6
D2f/9/TsZ3v7ACVxx07Dxpve5q+IAVdTgauZAtdvBayBA6x6jR3pdnd3/Vr4
7w6unFllg5DJbJ0wZPoLqMcZuVqbX/bN20rXGdjIWPBYl0kEYJNnAy8srUun
JOZYcPNRnOQ6zy1vziTQQ+salcDjMryWBJv0q5jJRKlmCa8TKymMmGt6hUk0
77keZtc93WHvCzrsRbAug4nT42imu4Sfz+9zNO0m8XTm9Kl7tPpbaExH2v12
PMAXmHHltdx3tjkHSTmsNgITUDU/TLyd/yX+/BHtT+FfNwGMVrzaAeRXn0M6
qnwqwcaPnBrLO5QeMOh+fypRGtRdkkm7sV71N2VVr229VhEdOTwHBsfEROsY
xaaBXmnTONmTzfLwRa2pqUdrZv4kGDnahqNLhzARqqbgBP3Re6g31W+bVj+W
EQFWSvUjqORIOqqQ4jaqiq3FXbao0g9xO5pyTJ/2Y9z+1B08+Mj8eVHvczRP
lKNKk8hAiw90q6OkAmt7Fz90B//sTuJ+9x/xr1CAP/859TbzoaFrCDQ2LVjo
d00ozoWBriHT3cwFgK7VyvbTwpfxoGNGnM7vkQuU7sSGC24/Ak2HdQ/LAITo
j5nP83KGMMrFdqY6tyjHua21LrHIuQdMWey19P0gpw0PKNdUWN2pGwa2u/AC
1Ov67q7v9iOA1D3fEn9x7tf8b6EJpt/17+2rhg9TOITG6jbFwNiUu2A25Tak
TenvC+waJVoMg6rlQ6ZT8bRNcNE4lQU87Uhq5bufc/C4rF9pxvHLACvl+yVA
UaU2oFTZS8A0vD8EaD8Mx3O5evYLRXJ1KGVu5l1oUZZwgFbNglZxsFjvNVjt
xIuyneTfXYKsf/wCZO0UHH8Sb1CwMv0uNrM2i2K/cRfGfmMvjl3+++Lxzhbq
J2FpMDZr3eLK48JC0pHNhnzc/XsmHXIG22N0m06nttc8WD/6FEM3GQjllBeB
dP3d9zpdO8iZHHbTBJ25qt5dlAB5T+DsB84P+0BtMrTAG3j8p089MVMQSRcB
Oa4+At/n/13fL/oUNDKh9Cp0HY+V82TcYrG7P5YoIn/fb9OOCP7Tq6oLZcRi
YfaLMAJMlUuF41ThKgM0+gL7Pyy2UDPI+GV9uGibZ6xmo2/e+2VorLB+oRNH
bmMrCdmK5s7Wet5HfquNthuw70AYVkP0/9I2Stk8gyuPirbfl4iCC86KBaFq
ExczFtVy1z4fqs9a5zOsDSfHWquab+Jofzu/xmuPY6XVpT2klZVfe3RwUD5r
gOvUf/WVlMrO2i3r4IuN4zDgMfL62j6KrKdk421tE++B7rhBTYV840Poi7lc
OepeznjoH712we/1NadR8scdfVaW0oK4lqhbbJhT1oLcUzy+Axm4/ytqUV/n
j0TN98NxH29p4byKKOmAGBV3kz1PLBKNNEvJbXVOhnKquffM9uyhRYZwTgUU
6ECSw/CRIOsVJsMJ6kAK6A+LJxw6x2IaZgxEIX0U1XN3gDhCqb8xRC7m/sZD
OPKSLsptHkiJpQo2EhTaCSlFbBhu7yomCTpsPcZwfCaPw2mvw7LjXRwD80/x
uynf1Yf33gkdC/DjkpJBj3AFn+Le3AdG5A2nedfZPtAnzevEhMSY9KOFFxUV
z7tqNr2dzWBzp/GKq8pitIUvbzabx62D86P3J6fHH4rveJ8RggFUi97afz+b
PKETbB1s2gIyrII8ehWvCJWpTdFSUub/qaWDn3aqx5LuQSd5XfSX08P7K9Ne
RXNY+KcQy2pvhQUwHV2O4WgmqehlHZVKP+O+L2fAeWSnLlNAdQoJtM/+UxNw
u1o9iaPL8OiyZL3jjkql3IbPG9ECAKxz8tFMVlRcDSgDlFVdeQ6KYSxz+F9p
fQzP6UBhOFKhsAqM4xYQoVrVNhYsuiNYr99LM6zcwIgrml+PViOpma5aDAsA
AHX5vKIF6/5ZaEcJ4aV96XnrlD81lezeQDwAut9AkCPzbq6sbKDxVYJcpawB
fr6zyIN/i65OVvSU6mqSWCvB28XLLAUnbVfLwE8O8ZWitf+sMUiW92ei+eK+
HJq+ZE5Ozm6b+tvzWnkkpAaQyf29Gs0dTRt+Up6dcayFkxZm60A3Flg5bk00
1gnal0+FIr8YRK5xqvGwhmF9a89E5Jdi7xKUXQBVOIsVQOHn8xgF/CNekH8O
2ifh8TNO+ZzmJ9J84XB/iO7marz4+99+wNKpBWP6hj1smseqP+u7JyF82cLX
p3jwHI4K804bdG3ISbdt25UWLzqd1dBw+rywRnRJ+jwd+3ON1pcnqzFVJyeD
L+Dv1L5fg5Gydscp8VGqNes6l0w1NeDT8MxAcKsmJ9cO5R3XMKScyCv6dIdE
Lcyo2OThOR18XAlFBGB5mfCxWKJYxRx/Ce+4lJdZeLouOaKWnBr5pG8BhVm8
jxfgJRMBUQwuBPD54cX5oVtUKGbEuHDTUsob9LTxnTbAM5DrLDw1iJWJWpXX
2EJ3TOhmWtvXAws/7bRu9r8cqe2BK6ROA2upYLJEGvlSgePshfLGWVrc2AlI
b1YPG0Zv9gXyxtmLxI2zXGkjBeufhv0hmoEMp0mubLzovQPvhZUWjEykXiXr
rh7YmjLrc9o4E1hLlLImgH41GT7zuViX6oQxZ3eLju96ve6beDVFc1P/gvE9
F3/yOlmwWDlxw9Wa5Lx60V6VTAelfORb1Vd+RwR6NEcg0DcaNug5ZtJyzLCZ
OYr9/+VAT09vAcCzuP9KpPDyZZTw0iWEQbBFSc5DDNgYbv+7CU8poKqc3bjq
8eRFxzNlvP7yQ1JnNV415MzJryaQZQleMh0MbPlM7tptffZMdsNt/RJ+AwNK
rlz45bfhOOiFNRy4rrXbM0Pk8IorB5m27kjDUmsGKXgf7Aa8MkJiklBGw7hD
BTmh+lSRjxa1X6ILtJhDK+ygoQL1KlHWRrVqU9ZnAMsFl/uJZ6BFfmcWenii
NMvAng4BDXU+Ep5NZvM+P3fp7ZceZhIbzQL5LoM8CF4F5HMbQYs6C9RzgU1R
qFaDe9lOXLkHv3Qprr9ECMjvxz0DG7IUYc3hKxZTlFXdA714JoOR349NcxYt
hVpqBX699DbID3oP8d046raXKFj1n8UrsdusmcvhcDDpDqZxRwn5lrvZsrlY
zm4G7NvbDPZ67TV2ADuy5YN98RgX9dNcA/DGb8aQt5doyD46GrLncgAfmQFg
0O5s+Wj32GjU/dBG6Wee7B+dg705GcdRf/0RIY/kcEgakmlYLteRPVeFs7a6
4hmy9gul3/XksaVCRD4zvA6/+SxuagVXs/DgXfOIWEK+Fm6wN4I7GRusMVXE
h1juVFSwKbLCgX8nw6HXGw4eOHrQY+zRzMfoA4VuE5TgZIiGNsmopwJlIq/E
SRvQoKV7T15oj7Ey8jL+N284Fz2XUsRj4eiE2Uo34L0ZbjVob241an5QNRHy
16R8qlPzE84JbYzws+rsFewTVGeLdKz08S8wocGdm1nEZWY0Lxg//q3Hb2Th
+qMBqxGs1rl1X9UVo8E265G2thyDh7Uo9Hpj/UJ0yunqdZDJEH573VfqSb70
c/TPenrDLBBwnWEcJburL1x7tyte+x1Z++3dV1j7vLF+4drndPVbrv06AvMX
fpD++dKdDyJnKd3VFyJSsx9YXfHq71KspXBrN/Rr29vPFDhWfYK7+sL1z5n4
b7j+eVyfe6gsOSaWU5JVuGbuDss8sD/SYP7rv3rddjxIiBsx/Ij4ZSXMcGG5
js+nCujCRD/0JT6y3QkUBJmS0G7CAYXN81m2B+CB7+8TVZwMx5ODQecqHiI3
Ca+hh+EAeCFdgy8HJOSY6dl+jjodeDrtfoox/3tykLTIlNuurieWm1Ddrnmt
ux3H/eFTzCzccW/iFiO7axVa9xhOkRkm+n0YcZ+r2CZyqpmycks/B07Bmfv+
2voIX3gnHgxyTF/kemIJppopYy7TTltjsWNxwvUyNlcpvHp/bHrQPr74Psd0
VjU15r3pEndEcn3OVdACRVVHyxHz+9L6fX5+YtpzfnF8IWYSqt6phekfrd+n
mBJDFZ+a0jPzE4QTQFXruW9+N+3fBv9IT68eRKK0H0/tAid+hZKpeDrKlRGr
nZkez8zwzqzhnFnDOVPzWuJ8JDWdbQ9PzW6/CyNxC+1tfjay1vHM3vL0cDCd
VdMFQbpA0xAQR89G5KbRH+Fetipemt+X9oOD+7kJ5rGe5I/XD5fWb05wrh+b
x/bD3HSehtWTlfOaSy4tUFzagLx0QGZS9arns5H923r1lJNBVFW0J268j/Gd
pJjUD/o3JxTU5S7Bkrx0+gHTsan+c3KWUX99g4ecWkz/NtjHebdUTyp5Fu0M
lSpLv1yZYYqaXbuTdz19qYY1rqY1LieBkS4ym6bpDlVy29CbuYVAKteMfjqz
H87dd5fW72v7xcfImvkCT1Gseu3syWt3+13b2+/a3n7X1p5RocL1kxmIEyHa
Go3CJY6ZrF6Y+MNEJCXWsHmyBmoC05rnM+fpPFX70n748N5+whiI5unaaWbN
TMdzs8anApbpKUjkLqbyGjU+Wmjw0cLe3EBD3NcXBgKS3WtYHAnCY/b1zH5K
zNDXjdiScxynY2GoSnaUB6ueHcwhn8ZkQhks3o25zvX8KterfOmeWMO92vrm
IhWePaylqsSlZ2bidLTwC4tVqlaltVSwVv31PEzdcWiHT4MiyMSxm6Kqatt9
ZsrCVJcp/WXOOyj03nggIP41RrbyzR/+//2XjNuVLvCt41Gluxk/Rb3K3XA4
qYyi/uixF+OPSfvxhd+owt9WvY7/BtuNkJ4DfqZfjVrwh6DaqNbrUG278Qeo
VQ0bf/CqrzLDFX/TZBKNPQ/+jcfL68Xj5PcY0O/7h864lcq38P/RrDvsV+6m
3V5ns9sfjUEew02SfAso8i2jyLd5KPJNCKu7Wd3ZrFW9YHuvsbVX3apU1Z+3
Wa1Xq2/K5bK3pPHuZrDlBcFeWNurNzKNUYdTr1GaS/xHO8w2L963/nRwdex7
xx+Pz72T997B0ceT5vGRd/Hea/107F1eNJsnP5ycnrT+gkXN68OfvKODs4Mf
jyu8yTdFDbFpqyF0BChxmx2CWIpRvqJUnvT8ChLt4N1giGXIuZ0lD5uJmFG5
xejvjXEQ1SULwkeJnlDZPOIlR1/c2bv33jvrDQbGZr1REs3Pmj+iz3o7mhQL
G1iX3deBynYHDxv+xn/cbfhw5t93Z2ETSDHf0vShvLPBcSUaFAnXioEPDAKQ
ahwoftPrf8Lh02U3tsQayWQ4agG3O3i4HA/bwE+gn7T+7HBgejGxWXQvHJLF
7VSlCMefGCBvOPL3ovFD79bEDRrtb3y4vmgdU3ReGggOHgNV7XjlnW2TWO3k
6Pi8dcl9UTwNs2bfF7GUwqrc4C8K4Pj+h8sTqQ7l8HB+cHasp0r/ZidxFo1G
MP3UXKTUntINp4ojmO/dWNNmM6QOOo1ThhAaz23Op5Q473yJCxd/6GZjbwOj
mFrf41Ax8gKeVn74WgfKSpU5qJm0ooeHuGO/UPkSXziiF0Av5r0Z46ar6o2l
S+wJoBe+xPYhLqvje9NBdHc3jp+QU+lwcDpEJNVF4nUn6Ik/6kVtWG3phOtR
aMCODjSfcHQg2LDdsYQN9CXIS6+HmHI3nEyG/euRJOoMORF6zQqPa5DXhe5B
6+JMY609Owu1YVCP4+Fni/wUN5rhyTHQ2dqGT/V8qlzKhVwGcP+ucJOcTjt2
6rJXhs+yunWpuwCMQQaOgQtIAyC8AQe6N6VTGOCaJBwFIrIRgTaGppBApjU1
DHZrGBcXA/j59cCKxLVk8FsweBRxLsYdjNmJnx9gyjJr4vK58ys4c6+ax7Ri
qLe6XQqVbeh4OLJgkq5JYMk07ycPPg4iUbFcUucnrGYyijotbFc06/I/8RxE
DKe9ExdMpqfjganpduUrxUKRaU2CwTMwqmOX6Ot0DHh4372H/ybdGf43foLF
efRiDMP6CGc5PkywqFSqFLubQRYJmt2HQTSZjt0NpUuh4wezqRDDExdhhxxX
RKrTAQwt8Jz09gvNkx/PD1rXwBLdTwc+vLAOzZvUW4UON8UJB8ihjAv/6Xyt
iOHydBoo6u9WPmmFhzocduJFLJLzRqJrei00GGnjO462OsEdTRk+DPbT686U
mBTcCbzJvenIGz1iMB7sZ3jvMWM6jify6dfoupzpt8JrSCYrJ4PJ8IfesP0p
ubgH7pWWMe8FphOjdaSIuZEV8/pGTrLieG9/VjJhHidRt4ckVMdxDioV6OhW
lmov9yt04o1NlLfs33fe+fGfvKPj9yfnJ62Ti3OviFct4y4AAb4xG08HLk9e
UuiKUXY0luJDEXb+cHQe9WMfyY3f7zftiHkjGJ/QLZ4glbSZsdPhd/hKdpv5
+XB3G0PhMHHiiEaE5TrwfvdBeN7Di/PWwcn58VGx8PNb31QtSWI8p+35VQvp
0k9R+5P1BntSUzn79BFPEpwRUXarQ71lEwDR8f094HLcORg/fM9LnSosTnCf
CVgUNIYjYa8x5Npfzn64OP15kzhJrkY0hn9i8s0CSAdxTyK+FY9PW0XV3vfe
qp8Y+xzqth9BWi38/H9KFj51KGKlUCwGGG7pTlvPBKYGY6UZ0ySs52IE+0ON
O8J9ENE4MJDRx+PDS8JcOR+tAJsX46t4grq0IvT1Q5R02xcc3zfyJURduEup
SGrBjnUQ53cxKfgqLypUwK9j5LpR3Ak/TIeTWOLZwTvaTpbAZM0jSE8sKOJQ
LFo6jmn3R8xDcPAoX2JAISUYehRVlYcIHQl4dMj5WrVKTtC1WhVD773ilJJ5
Mon7x+PxcPwTxqUqbFjz2MibbZiebYiz9ZP4+xQmQgmjFXzwDOheUU3Miwif
KHWjxf7oo1NO7gB4HzzxadN7OZ0A9jBj4OKUFWHdenExpqM6PXgpLs7c+Od2
jzOf35BRYXqch8JhYJVb58MihKWRP1VMsGNhsyCv/L2+SThYBGZWkOJ6MMBd
C8AD2vkO6HDUwxt5DcR3cOwwaBTWhEDpgA2rgVAdKLF0OP72pt8nFIR/oCeg
pN6/xJKkzyO5qfgeDCK49Ye9DoFfZUjo9/ahvEQ5Ns7+5wMsD1egoxlzUudA
HhXpGaShwiJQPoY7boYBsO6IRd7aaDR+YETihXsJLkFPPJAMQuFA0+PMRTCs
mDdLakxtqamhClY9DqkKlTFzGEX8q3icTwz3pMqX2iErFK12QaHlSSfHxvQm
SEjgfO3ezzkauA5IHNPVwxOweNN2O447SYURpE6CXs3JAxf1ulEiKFd8148Y
ZgUq9t/FQlkoYCCVVYrAp3ubXkBvPgngceYqwrFagyrsk0FKOLEOROe8zxyS
OkAuVNjb50FM4QfNgxN+13btXLqjEQiCkowGH6cT3SN0wRmPJn0jq2PatkMM
vUjj0E+Y/II+R8lMNzi524bGtqwKahTHn6Akpn1R5AOptkVJnetVM0Ds7p1j
caT7lNzuMxUrMSce4n94zSHQgoPBpPsLoM8h3yok3sHdcDohNuhEcZHxGBWO
m5vHHw9OvR8uLlqIShOMCU/1YPxeD2SJHvOd91Gbkjngq2Z7jCr4RxBzNk9O
WBe6RcaMjSD0txqWOXPqj+THHl6L4S2QlfmO7vWQeeYL46SiOjD0bI/tuaEO
FVmyOMU1BIQErrkz1w2Bah6IqNoSgXDPe0T2CzdVwm4MvLeUjOCGCyzzVUyu
UdgybewiXSu/sRWqcoFnqR7TJVqPl37hGtFklGLmW5aaKVuYV6bvrLLysLlw
1OKq296SJA2UUpLYYqmFm7y6tCCfzHDOyl7G4kMzRUFOWZhTprkI/SZzzGfa
yPmXW24D1iGFXGzRJCiwrgY9IQqw0e66d73u8AEI3eP813/u7v76f8u9oXP/
B0JaEr/+DeDS+7+gGmzVqur+bxtq4P1fbav69f7v9/h77v1fHork3ABmL/H4
BnBJ893NYNcLq3u1cK+evUBkTgmzPZTxHw4go8Mz39y8O+6PJnNkKG9vvWIn
vu8OYroRwE/hVytwoI1KlhZoMnwD7f5lGv7r9raiVFPcb4JcHxsccWdw8kFF
PP1YffRG8Ysexk8XZlHXgcYoRc/jCVWDqcaYAcZDI51L9ljC70oeMKvEU+pg
o/Qww/T7Jb68hJ60ou2Uz8tfsXN9drJ31uFwNB9Tmqhiu+QFu7sBx/7EeMPe
ORzZ4y6e8AenD8Nxd/LYT7wfx8PpyDuddJhBRVUNgH27gXLMb331iodHPLEU
3GhgncAhp+OnOObrCyqiJfsPw2EvjgbKKtdjNUrJUu9EOvhhM+7FJu5i3gvk
WFGRrKJwd9o+ZZ1Qemlz2UH5z7w9YZyAQVdZbJHQTFI3pZ34bvpAUN6lVJq7
JgMpIFOn/Q1rt5yrXRBSN5jDQ8vTPfq1oXSEd7zU7iVvp3274KaWv78MIld0
dbsQLvxaQ8fSCL4CSEhiLgdVAxTMmpELDeBbBkOtZdzwFSBgYAwZkBqG0wFf
FepbFVPvniKKa5YK2IOELg7WABwwnAiMs36iwfCuE7d70RiEMNiwBJBNEhW5
ZmIrRoVYsB/jADc/yAIoapurH+xSOrDF0cFQACpd8KVYd6LoDt7FtT9FD5yx
jLXg0g0LB+2o/YgRMJSDup5HgF1wmjNskLdKatj4fuCoRoYjLHvihdbCPZcO
R0TeOEUF/YR6bzZ518vH8YwYReOoH4iDEsGNiOvnmOOimxjn8BWqyxKW5xWL
3aT5GI3RWeJPQM2AvhUHrFjlb5MGqfgkdnlSRhXUfYiM0VUGTaJbnXkS4/fg
DWNQV7FPv+H57n+Xr+TDOWKdAfz35uamQKtGffoenLSej8KmdWGdBUWofLVe
d3rKOta/52uib7wYT5kDENdoxaBgOKpUSbuMD6sQfckMajKDFePncSkqc0go
aEb30sH0u0lbYRUJwYHg6AVKr0SligOf7wtRvTLtEx2AOm9pD0LZ2fHZD8dX
xUKxOb0TC5yiBFov+dwnqeZRfcDX+JK5vbarErfLVYd8mn1/CNqkyZdiWgOc
WaEz7MGk8qaDF0syG7pjgtYISb36omBDRQvqOQ4Gw8G8P5wmOiKF0nXAeHDF
4cv9T7L4dgYZexNL/dFUBl7E6r7ZKTAxwGyCw61O3KQu6OkzqjBNIex31i6h
+y2LWsCeWbTJFu+j7r1adqAixQEqkYB4yYULX5wIPuTBSenxtaXVuvCSWzBE
HcKFxhal4wy26nbgr+WgMHh6Y0FB4CKAVnWvLk8PDg+KzKdAH3lI070PDSgU
hu97AcMCQbMxQKZwAykJPXbiwbC/YRGRbnL8yzTqXYz1HnBg6L8Tlovhq1DT
Bh/fWMFGF2ts31Ntbi0M03vAk03gQ0PlGp+eVc3M6t04Hg3Hkx8E6973ogfN
RmUZu4FsW0JdYOsAhxbRDg25jui5cBaaioqFmNzl8rJ9fkThAE9jhzg5Sfw8
en/84fDgqjjzdd9ERpxW8LGZJl0hQTDqUd2Le8r3l2I70oPRSQSZscmZY78p
M4RfSr8La4VmFlTpiJYBaS4AygCOxlOSq91gZ5dTwAHbVqsaZvZZqyJspf4E
8pULODHNifCwTdpjl53BNIq9qN+POyR9OhMnpeM6XFz5pVxc+XW4uPJzubjy
Ci6unMPFlXO5uPIiLm4RD7eQo1nIKOQe2nlHXw6RzyF2OZQid2vn7IU0gx8i
biCdwMUM6L+hL2FyLDYf8Aa2cQK7P8Z1RlX+fXfQsfIIYzIqTCAoiWjHapE1
fw5Fd3OdjFhpFGKj2t3kW8Rm6+rk/MdLxC4l2qgdHtwqRmST77GA54DjTSsS
tOEEWUxwtUFkMzwBFuHVpKnAT29I66/itWDglQjkMhyhivpC+pC7GHUkNlhD
gGuCldV5DHKiOHXw9eLIPZtDeBywAZjFw/JxQ+cccFspVnY6uOV7yG/o5ClO
Ozh8y6334p5tS6S5xayFAZkshDV1Q/QNjOSMUuodHh0cXHn0CJTmG7PJFEbc
2FfHWO3WN19BEx4QAG7gQ6Y0vNWok6XFGlDhKwMqzVu/BFxhyEY8jUAZ8fxv
AgyqSJ5lDTK+4HUsKWXPJQQ2wlTiY+XaVVnk05M+P2lIcmbjTprx1onY8GOQ
wOEblXLahOu1kb2prG5cVSC+SbUkApQLAmAKh72n2J4/bcj5CHV8vbn3aGJo
GWrk83W92E9jBxjFSY8NUA3eFIo/73s/l72f/+j9vOmVHHaOKIg0Vdd/XsQ4
AnIPbqlt+3Y7F7Cqs8uDk6vL4ozxmniiEn+fepWgbxIY7X130J3EGJj2YDyO
5oLIs1kGhbETwFwL+rMFIIxnk3jQ6ZlozQTFAYCH31jRrsQseQikj+i5a7A7
GerW0WDOLqoAauUWAJPga8VEmcRtkR1AqO/PAf+jghlw348KJQtNUQYadIqR
f3V8dnQNJ4Dz9mZmQdn7l4ZqDtsXbiaTeBTY08UCL6ik9S6YGw8njdfbym5K
vkkDjfiBmd5IrSvb+7ExWNU2DoBmRCiuVEMx1J7hUhW6EzLfVG/kGJJZw5NP
Z6oiZycDkUSAuswyRzSSEeTrc1ccJxtmZh9WZOadbmdQmBAdgfnDXhnPcf20
3ViRq0XjWHXwjQw5mY5GiByToeKNw50GqTRrIfDGda0N4NnhRbka1Y/xIIfV
KAmPy+I9xg4QdhULnQlPRGNQdufqMroruZnyS7mZ8rrcTPkZ3Ex5PW6mnOVm
yg43o5/w14u5mYWn95JTahH1XkKS8nduPkZrZO8mB4o/0q4cqTK0GJUdMElx
VJVbsrpDaEuUXzYIx0o5ASygvrDNnfg+AilOFEXD0TneXgHK0bL42qyfWV4i
q10WoOL7+267Gw/a84p3+DiEPZRwtL9o3JHzmisOR0gjyImce/mMSAAiFVcC
kg0DSipvNvG1lKkTHgHjjHCTxlVVGrWIFSNVy+sMWS5oa+nNjB5Mpmd9RU6s
4jmQjVJJbJACikRV2zZePVHA1s7M47xRRBCK0R5fMydRcI/1PlDFQC9tzgyC
1AyC1Aw+cXq29SZxU+D4PD78MvECLH3NrUwspPinNSRwVYvC29yV+o2LEYXa
xpsF48XzYaqVbaKn+N2+F4oOmfRV4+jzBgvfQS7Pm8z7bEgJPdL7ZvyAZzZi
+v53iiQrnGz3YjTwnI68BK294DC+n1LMBApYFB5RT7Ujj4w/uu1EjOHoOq8e
hM55pyFgPy2Zes1ZytQ8yTSIjK5fNFuZKxxhn4d40EXtyZR4xbuhIveAIEDe
BSlg5ubLLqjg//+OlpB0QjygNR1yCp/RCtJyCkCaLlDaqrNXb7itbGPFoI9o
2SnqRfCEgykQXsK//s27o+EUSM373jCa3LK2LgPNTYP9IU4yH7r1zUgf+wzS
uDdhq8JvcPvhJTJZthOVGYo+U4GR75nzSaBXuVV3Ft6ijQMvVyNAffMuPUQ4
NM0YaSRW93eBu9aoqGUF603BxFnw70JrfGa386Lskh1nfSswfKg6cbGaElOK
8kwa87m4YWRIic6qTb3Q9W2KDn+z3laob7ZTkPjjH0lHzQ9/27AIWoTSsAI0
zxP1/ubDSlbBzOFR4BeKlF8XiDSLNexwzq7QOjuqPU69dO6+Xjr8jjv8ws/f
WiPOUanDuDxXk55XKbQr0UyXUfN3VxHfmp5PMV12ScxJyWOyUdtWN1TZPkwX
/U+qD32NdFRaApDyIoAIVV93ny7bIMtQZtl64OAWL1lDFiyqybmTOXj2vZp7
tprdSYAlk+5yY6umrnu+yd0ABnTL8IjgtSZLVX4Vlqq8jKUq42t3JgsZqsWM
yuIjf/GJuBihli2kQsUs/opXexatAZLfOJdUDg31jqyrRuerGGMQukyVgaS+
NxwRZLW7VS6nHXmZjYrFZ8dnH4rM/olJyw09CVPuewXV5irqoLon8RkLdyWm
gxG9+bv7795rKwrrCCG2gCXyk/f4ARk0BUrIbwJzkEBNvheJs/6CmpGBmb67
ImiZmyxy08A7zuz9i4c5KOiijCoVeOpk9GAXK4Dalg9F5cFz1h10+2TlTrfj
uTe3dGee+r72A8P8IQDQLYu3I7d1WDVg9c/jh8jOC4qXeCowpKmpZINUFlH6
iH6pC7Fhyq/HWCwodxfLhmE4GpCLjaYH0F5d5JhqgVuPVu0esJRL+fowQvG7
d4tEYBzz7ENSU22FDXMuzlDppkj/LH+YQXacQe5A2V2WyOt3ygsjJZsnzEry
eOokUW01AofTRsTFxYaVa8aT6ySGM1P0EzLSfkKqgZt+4u/Bb8LawTgGph6F
/8SIJDCWw+G01/khxrj2raHuifF20VvSywzsmSmSPI4n0/GAPBFZmym+IKhN
qiIu/63KNDtqP2qFYkV6AEbmb1VfaPsANzrHCmAeG1huJtCWqaooMRhawHEj
tLZT0FJ2pt1EGIuJcpRiJvGp0kVgBV4Zf2KzJw2fTGOCS7bLhOmUccCC2fSG
w0987tx0E83W+FL1hiF5S9FAsN2ewA4h1UJIEX7gIYWqWFlf0tOQrnJ476XT
9CIfld2lDJttYny3duoObICyqKGT7Mnjx35Ypwpf3dtn7kC/QpgRvYaXwF2m
B5EdAO9x7x6odpzSUeo7d7bBzLmHxy3kXsUbhENNXWKr6vB+Gi94AVACr06b
DbPsWwe+9M968b1Hi/0Nlro4XhDj027DtltddtV/1vxRTi+KRqRMWWn26uRF
8YKtNWF46YhFMGOMVwT/6W1kPB5dwdGCmJYliVlSACM9qQGWSiMxjj+PuxOg
S4yeqPyn/TgDRsC9rde2Ekhs9DcyH/iOLBMQYFtVYra3QxWeBPWjcAalr9l1
ufK6RBsnfGa7xINLujQ7iu9vBeHYESuC43b+D/RkIt0uDYHr8UiwtyUjtUm3
A8Sls1PgM5uZIYUK7eldAuSr40KNfGdjpcwWdSxBp0ZH63Z9y9mCcgro6jf9
Pky/30zRbGX8gVxe/3AoNzj8k0eN7vFEgDKadZlFG6qSlEONqqtaYZNxnDjh
CngedOu13diyA2kt5hDos5teYFW0tBy6Rplr4O/UTKvWVFeOWvn0dtFhigd/
ZGItDEQPsLXFc9jZceaQiswARfukiv/OC9Bd4490KSg/ccD4gwnNUTyaPBah
QQnKH7sTZHIu7kWUwWI9J3W1QZPS9xw8q7ybDoOCXbyYmtL122OM5m3EPN97
gxgNXqLxXO5tkBQO792LYQ53qk9ZkZ5QJRYPhtOHR5977wOVkCgXIv5wQ4LZ
bpWcvXeARRSF1jdNueNq6puspn2Nc4Pv+JCmfYFYraUKAzeWKCw42k7MOKip
ChnUwdfkudlNRh57R6AqjvhgCvDQwdWq4uPZwZ+LdqfINXVK5cB3Co+w0KxO
auloZOnltAMvRAmGq0GORNbjLp58juE0YJvD3d0djmpErPFEbsq2KUlfeadm
dhCcwzi+iV+gu1Qiq7u7u+4rI2vQ+2CrShNtoAfSF0ZIId+n4SjH7RHlOjmz
KAi44X5y3yBJhtMrxRLyCU36UXX+DUfM0LioyUyxPrBl3Xt4leSTMefQ6gE4
nf5d92E6nDJmbjObvLMdKv28GCLnHvF1CtcEg72VW0S5RroYqXtWuUMyBRLP
BDHHT3O9iuFFtw9gzHpz161+ICYGCIMHIIyaM0EgaMZZvTObWoFHZsixC3d2
jJxr4isgDvf7JFYZk8yH4eRi4NpiKr3OW0SnPoULk1py7Hh7/ExHD/80zuuw
kugEPhw0uw8OoHLfLIMYGxnQeQr0PwKJSId8SoR1YxRhmEgsGVLNKhUVWi1k
QVXxTghT+ujVibGR1NrAGVvxKPj0524Sq2KG7DbxLLvVHedU1mGKqpWKMTYQ
wCmgouIVpBwQH8g0nX79bV9Zw/CzMADQ5cfjw/D0pNnCFw5YYcf/Mo1T6Jf3
wgpRBDDK4KDFY0bIljDiKUYYgArDnVKXvtcmNRkJErS7Jky2CYlgyAfN5ge1
hCTWit6MQpPjpoeKo173jiCCY+EYlVX286rZQgYMCn/Y0RGA1TuPPxfvuhhN
xAcJw7KWAlS4ZYEBWoiEi21u7KBzch0M/IBE4T7rW+ywU64mpWGlDFwdZ8aB
3kA2aUoIObEi3RYpku8SrnaEUplEwsAYdgyKMEQSv9uwbUIAS769gfpshYBg
LGKSBTRT9/v435Ls6gM2DTg8InyzcVLV16+pgLRa9Iv5O9q/+PjakbPyrFI0
uuaZq8CRsMAIw3/HInEuj+0K+OrI0GTiG+oP/eKgc2nsKSqrLDXuhXXgiOxw
rtC6bFOcDODcdp39bjvaASrCkUjhux1fO+Vl1x2gR+I3S90REeuNLrB3gZka
2o9QQXF+6cJiv58ImNhW32b81IESkQoExQ8hcR5Ha6F7R5ZaFC2A0r40H6YI
H2M0DJ7iAuKOZtDsbFEIqKAa1tVlCf6RwdnhxXkThujPSiIGC5EjfRMp/mH8
lk2Glc9SO7dmSr25zHFOkt+M0Fi5T86JqJInyFxfRPxDmRNI2uoNqLPx7Q2G
OvmHRabhQJy74vNvuwWChXsgQKDlWCI1T+0DMUalljJBUpjPoZIsZNQWOybe
nNgwsUP43Ryx1GbctellDrMljrk7SKaCasPeDrwchT+fHpxRXCZUjt8QBsB2
hk1Y8ue+lkzfXbUOb8WzJYnmGXYLw27OlbvUb74ehwCnh+F4nrMg6tW/I1na
bWwxWdrd+d3IEpGQM5CqBxJz2TwXU4GkGEE5a6kEifKR12w/4mRUENvIVhwR
B0/3ul6hxTc/PbIeuJtOvBPvEfEZowBJTGOsVDw4/eGEOYndbeIkgiBoWPBQ
Hd4UgGEh8Z8N55DftUZP9QJuQtGimiYEHaLljxgqamvDt4BstUa13XTwaTD8
LFGeacVk1hu3pTT8gOm1wQePuOUXqCUAKopy2/yHxiAvekCRZ+J5OajUtUR9
oPPTAVnutTF6S0JHA0cBZDfwRKnqZaPzRVkQ1BVv9s0sSN3QqRBsFIdKkt7L
vsVNrk6B8aTt43PJudAIjD8cx1i843BuGiogPJNxN1JvpCE5cGxF4xQoqRGc
iDYAJwHHK7PpnEqtS0Rwb09sMiNPXXLpGE+qDzIhsdQcKEZkl4N9vqoBR6sG
edvoNU9QjBl8YmEmecRbEmQD8fT6ZrN5eKaUluo4I/x1WL9J6E+sGLo62gPQ
Hzkw3aKUVkReISRQETnpTqZEUXhb6iLANEaId4p9FdcAw+TC3LnK28D33oZe
pSLzDqs87+2qI3XqM7bjRHN1ZM3mqUIX+s/Jeev46vy0WNh4u+GzIewJxsvw
uiVgKfA0fEONLLkIg3udiQsXwuuSzW4ToeyLXhMfRQJQgnH+7I3XTxhxVPQv
27kOBUps49YQmm0F4hBn12oj9EPkldAR0OKV2JEWZOdhRxu3o2CNBdpjmNil
u8ipAY98SYk18UnZmTI71cKc8+hU7t7P5b0oTrAI7yB9kHT0OYY0ku50PP3e
uoPskNTXifVMW6Yavg9Rrn3bmVhNkqwfgm7CTGLWoieRITnZCs7EwbYz8W/w
tSKxm6sMxo197WLja1zFJRqnQDpwA5ObSIg4UHP847ukB4Bk3YO01TeeQPrM
XRRvQ6TKxpNSGtDoXUTLBLAjEs4R7LDVO6IAVpAR8VgT+wiEefol2QmS11NT
GQdY2+UomkR3UULi+IfT4/MfWz+JE5T2gnK9kGENNm0/8zwfLbZEt+0S0Gwh
shy0lJhf8T1easehi6wYcnHaOE8xBpVkG+7UMFhgEIaKbZK9TAeDjjto7V/Z
5RwN0+xqRhAdbSPhm4jBOVU2iUzKGZBY/uYMERBYHqORWOxHcgVxcHl5fH5U
JGGGZ+Hp33zRQjQhVT19GSOOAU7PNxSTICKfZwbJLgu4Yd29Bb+PjIW1VUbO
R5Jjw2ie9Z2UCwWOFlW06fc9RRnmKjkOKAgiy3ld1XxjSOUNOt8kPv4XSFRy
y9GeF1L3pq/6AKlKKCrCTqKXVAPUAMPs0Wuvbk1f9U9BqxlNbG+JvHHXVzvd
a6kHQ/bcFP6jp/nywoYaPjuQHCTJsM3pItRcNnLclfC7DfNdgo31JQbWMWoA
CGLJyYDUAQQ1+vV9keGpaWVJzFvU2cOV8KJJVSE6yuALUFsF0APuO2goA5jh
J0os4agB4hlbvYLc6ZTjM765iWf0+zZ/12xpc9GVwLUV3bIvFgChlM+NfIPL
w2shUVmAdNNYc5yIcHDb9uDMt5wxCe4Io5rYQ8o7qGQJvtH1+4gZuVX1WtR2
mbTt7to2uhxNocjngV/gYLHaksUa2gAjSBXxXDvrq8MTL037/cOSRBz4RscU
yAJhRwOBwICd8vy/Wbpi3+jdQIIrC6bRwFZa/Z8NmWB9i0KvBbXqrsK2haCV
Jc6DmKaeq20zeFB4QSB7c0PRATFiyN2Puy+jA1dxX8yfVMZIRRmAAIhHvEFx
TadycNlbjsnZkQdVsUN+nW+YHUGt02Tp3NqS5wsIEza0aNNqGiBBqch4KajV
Qsz6shRTzn9jVMndLq7r4RJ2tfxSdrX8Ana1/Fx2tfxF7Gp5AbtaXsauksX1
i9jVHGY1j1vLY0/yjv68YznvHMs7PvKoaR5Zyd2wlt0+YbaxgzWPxVF/gXZp
1E+tVDTBINkmxrWvtDW6iotnvtZb8rqvuei8T3dYi1nbdrWYgg7AHfN59cYt
NWqCJ9SI+PzCEAexfg6MSTTpMELerzZOpfoKsS/91g0Lf2ayv2QPSANPs9OM
eshV+lKKIhFoZRtCF9bNvmQZdJalR2asN/g93KGky7xVNp8Ey7DKsKxXlfLl
GxUjA6UY3CkoDOA2j8b7E8UBkLken/3LruR87VJB7uOFFvAEHITIOgUZNu/H
cex4E2SLF4Dvhr7EwgmMSoyqVs2CZx/UefaBnenMWG2T+CMnFshmytSLQmrs
SYGKtnUDfxs//2wP+OefN/y9TvtWD88HQcr31G/VAZvgpXJYnvWbk0hi+FvP
RRdvJuNokPQ0iVao4+AIGt8MLaRIsB8J9XTI8vLB+RGM0IRnDMNdhkvoxhrA
mHLDe3XD4cOu928Khwet4x8vrv7iF0Sf7c9ub9VVTbbBTJwbbuDrqQyDMseT
AZxb6YlToT17PfiLK4Guvr5bqo3nCdY5DnJQxx8NZ4rrznDVBHF+qenpSxDz
iEhN+1Obe70D+Rdjv+sqJ/ctNPrJif1quqla/eR8tJr6ajX72cx5PxgOKJRl
WpFpsAvdn3IpUNylK0ahw3wt42iP9W0wCIF1P0RpsA7UvKZFEMuSvThBco3n
L8XmOyqOSKGNtfJJdtr0YWKIM13qjiStUNFrnlKDUaA9Mvk6QQ2cvGIEatHE
wIw0yUaHPLseYee4mUVtbJXgR3Q2Vq84IgLyBFRgEt5SVBZ4b6u0J+TLfnrQ
bF4cwuniOccUk7LAAQYngIwpJughJbubhFJd1xG7ETUmBBnU8uHbpbRKPNMd
TSnnI1rjawop8xJpb2kyneFVtpllmZl5KxaaOa3kY+TWbz4gERR+fut7lKXP
e9uzirXmzd+T15Q65KaA5lH+Xo+3KRs97t3kfndKizZVNxETi2Cl501jzwPG
vhoSBllv45WmJld6I5OjA74rFPWovZ/flmw1GZn1ZD5gjZDVc+aix15xuehZ
hARpIxC51gcpLKGfm0+cT1Tf5iiMIgMQlWdlEH92uTu6Sow7sURBD2oBaw0b
qXOF5wyDKrZDvw2UgiwX4BuJvs1QsUwCE/NISkITKor0rVSjLe/bIT+FSC+o
gMMYDpvdh9vb1K0YDMC6EMPhPAHfZBlRzJytmfRMsqa59WbGLb7z5ioLLd8y
N2r2rGdvMs3UXue2nu0ghOECDp1BOiWoxA2I54b1VOva1taQ3XsBnbVblH6X
yM1br2fqhbn1QlWP51STOdWNRcfw7u+hyeN2MpigzwWNxdzhUp20W8xhNADa
yzQb1QFswUfehDQvvpqVTxhPQ+wrddbBiWGddPBUzBxwLJJqj6onv1Nirojp
oOVJEdTqrBBobNnmAZrx6CY2s+c/USA4yyGdOoumFCkCFhYxZnqHqQSKmDsU
ETx7ISmW+nDaGPYvVebZZoaTMaWLHAKBpmrM3XnJkN3Z7jGwbkY4owhQ+r4/
SqwbCcsrMKjBtDG0RNDYsTJM0jKiDuSJc7YJ5NigU5vrsGxAupgJVvRVC57w
xVWriFYa2pS0j9NDB1jrwl4VKb8Mfiq2AaXaWhi9C7QhKbuWBc6ReRemXofu
a2NPULwLSzZJdv3INBNgM1I2SwBQd62tLJEO8V7ziIVEM+EI+mSIChVYgmGS
dMVy4N3jEKRM4vYcdORskMFWoOMpABHgWKQPaLGPom8L3SUQ8frx+AE9NvEy
Q/Csq76L0d/2FZNDG1w9kN7Kwkc908CdOBqcyTaw2N+OD8IOGoctgAS2mSao
pOwOOFsAJTlXgd96bO0rzdCqY678Oh3NgpgWZDhKWVkc1jQB+Z+gVmdn22Cr
UXUdooDvQlaMDc7I0llY+uGIMorKAYfOxAIcmQsB4DRKJoeP0aAdQ+O2gvC5
BTo4OxEw7NvBv8mXsR1NXEyJkk/GLA8NqPHUxbQMdO2NqyH1mJQk7sRhGrCc
St2mVB889XqVpZyt7aqRcpqnHAobmNA9lTKefzIz+i9ihFVutY+aaHRuBYew
A0IaHCNK3ELVcGL4kiDBM57bM05DJrBBE1BNT/rwEQ6XT8Yv6Z0872kZSArM
t2Knh8zXmuz8bH9TivAMyFuXJ1ampMmnz0buE9jId+g9DNjMC8XYlybMbUCS
B7LL8zVZ7k7UGtO+cRebl449x4Ltas3BWnfkaN7+5HvuvK1686Lym6fZncvr
NTrJBx5UVSlxYGZ3MW0z8kQE1o8FbvJNSUOYP5EF8j0HgI9J+0+XxjSAQvG4
R4mTorEOa61ojESBDzhD/XbDBo+l9xM3VI6B7WmVoLWbHSSVmTut0kCYW6iD
TTL4wpnGuYKyW2Q1+RQYGXzxOKFI12xxTBt2T9oGFa9FsfdZWC4ieswCbwZn
kmULiXfbkQ5rrU/t7j/Ujkd2LAwRMHBk10wQsYGxaYSefW8fZrwPXd2mAKJB
EhQHnMhUUEbV0YfzpyPefxL5Q55Q1MTsp7ARfG/uxE0gEQdev8P0cEBEo5Ed
7slw0oAlyNBCL2/zq3qbIOaZb5Cgabv7KQZZOuJsp93MoEZ6UPmfqUgTi8ev
FN9iCQ6AjQKw79SnQ+vbkhcWSCL+R7MsJn8HGdQjCyUUVFWnzukdJZVHfFEE
kCPaG9qXahpmsNamsrCstKou2gpqiNJGkC/y7kj7EQ28iysM+z5NKBhAMiVr
XKUBkj7g2EBayQdU3PHFCoP6RYbKt7wDXFWRc2A1dth8dMdx7SFfz9UWtjeF
DTVLNq6NZyPKnmipQ4nV0GSXdqNtawvtDyYTZWqrnwAZZy7MaGJsNOSDVGjd
ckyA8N+RPSSumvE4y9fUDwzM6NTDhFV0NIAwqLVnCnICIzGx3XEcvNc0QNZT
SkFIWSBPB+zTpUC0cZsWUKAHaH4gekz9VITZHvZgfzWrNvfXidn+UFQYzQPP
up6h6WxxJJhgx8RK43Fyv4tXEm+FFHQ3bs01DnzDkHtiU9QgFGffPEjN5mJs
TeZiXByOc6bCRgbL5xLyZcqOvpgyc7kYf9FU/paaix7FwslYUyGG6H44JBFl
iSuI5buHuKeFMmiacwslXTC/kmJFBQ51Zl52U8xLM3NMp48Vxk9r99EUYFOt
GD6NW+89/JVmnlEPlcCSwgz63V5EMRkZSl50N3yKve+/l8Fv8f7aDevPHzxQ
H+M9bRFeU5gmwOZgxnuMntEfYCzf4nxvP9MBkaKSjRnaWpq1nMIjbbHLabBb
M9oLlw2I/DtqoPhneFaCzLrkNktKXLzWa2KT2emgez9vkpKTYGQ9F5PAz/db
opgYaOnbnczpIGLRPQlzMDFRmn2XJU/dkmblx+E4taF3eUPvNmxam4QSjgC1
ih4OBDdwmGKlLJppze+jcExuEaqGUnO2Y33yvfkCYYT5TGEJjT1+Rzq6m+tt
uV1j7evubsPBbIf/c/VVPt/WpgstAcFI/6yr0o9K8rMVAYMJnLqjYXdA8U31
OWwZptABzUFTqR6FZeLsO9KJBGhJJP5psF2nWYVVKy76ydHxeeuSCIPRnwvn
fFP4b+jY34NH1sGTXj09brbya5OuGCvSfVFapsUQPtY+NEAZjWHoygVTPRSt
xI7kJ9DMOgmkGAZjJCTWbNuNXQqOEVbDhoqO4ZmKnM6xqAICdTGeHHMXe2yi
s+FDmWYIoB7BOx0eSPvOpIZgacuVbkBdLJgCJ26FS6gBc/ueUS3A9P/oeMxQ
ZA263cFISoToyCRPhHLpTwTFSSl3MEFmNIEznHHcno6TLlB71FJa7mWfh+NP
5OXKK0IXQ5PAxzs6PGsF+NsNEq7Cah1+bBmSan8tQK5ZthJNJ8zOJ+T3qZaK
dd/M5LZlG3nnIlNFyLCuNkk4YOEcf+aSCxJ8lEIUCh3DFRwoRVIh0Yaib5tY
jalQegvNYaDPScoeBnuzfHbT7hriYpLx4ugEfse2OepFsFVCktHZD42Mz6KH
Bzh0ppQZAndo+5Pkj/rse1dNJl/Q1T52hXaISeYDarmKuF5QKJ4GxU6Yclzb
7wS3nBxSXlFBSV1R4QvuItRdpH3fYBiqi0C6CKmLdBBMABxIpQ5pzX+ltG7p
wBeaiTOR8nRsN4yyh/ucabBikDARoNJOYdiePhouRkyqrZcDHcN7Es/QrWsg
gslOWEVT4rC6i75KoW1TUTiLgLKATNMRFauQZDGKJ0NHymRctjMZi/3j4kzG
UiM3B/Hidyobb8q+kgs2V+Y8c/MEqG4y6QFygvaqwrzwqTnVMQQqF1tRPrkg
FbwypzDQbRdHXuQKOaEH7UlaofPsYhPZTH88XaTih9lPVfVowlPJzO0wTVyU
iZHE6/Obhx5SC2pHSuGyBcFpzMtsiBUHX9xAIl82nWdFzFDokw4MoaaYCZ/w
m48p+E2/YeilIJ3te+4UkaCcLiHHYC5Mu8mqNV7sLqpgmudDmWfKbX3c2cbK
atR+co0j7TdyS5wpEhs6u9yGgmMZpubmmDFxYY4xkNqvOcY7/CprGKNA6hqk
2IAmna2CiGPpYI+Xbvcd+mHuyTWVUXfGzkSjSaZAU0h9T+c8pl/r66O8UroX
sV8YDDR6ck3orHlpnbHT2P620kfqAqV9swsuxu6z297t3dZPcLkjjmeKPpqx
27IelxhBR6+mJRlky/TM0hyuOkRsDlfVzDKM7mmZ5pU4Ltv/8+YPv9NfMm5X
6JQZVbqb9CNFqeAH7PIXfQODQW7V6/gvCIEhPQf8jLHmwnBr+w9BtVGt16vb
1UbwB6hV2679wau+0hyX/k0xL6rnwb/xeHk9kLp+jwH9vn9wdnmVyrfw/9Gs
O+xX7qbdXmcT+OcxHGB0Y/8toMi3jCLf5qPINyGs72Z1Z7NW9YLtvcbWXrVR
qao/b7Nax+iL5bK3tPku/L8XBHvVnb1aPdOcgg0ji45WTcid/zWaTh6H43+2
HmPvAIfuteKo/yu8QCI86U5QYPzrXQzCwj8jOAYxiP+vb8otki8wAiCHBEq8
O0zx4o2H0wk9kuoEg4SgkIGSEIrX+JuUyQdaTduCYy2pwCfiQcf6ADxzXpy/
0gXN8J5kDRWjUEz21RzeSDpDvAM1XXe4b5SmcXIM+jHeldom8yBKJiRGYsgG
NJJ/ikTRqFRMFZzt+u0x2Xa6Aw86SGJtxxJZEQVRJUMSBkUpp5TH5CtnbGO4
udeLyUMXhV4MpIwGRRz2nPJOYmBVtp/hatgHr4iEY6U7u4jGiBK8XE2Rroct
ZVDEo6xDd3w9N6TERGQG3geu5QlXiWKzbmPKvfLWjt+oqgglzYv3rT8dXB37
3vHH43Pv5L13cPTxpHl85F2891o/HXuXF83myQ8npyetv2BR8/rwJ+/oAN26
K0ynN0X427SFP48hfw/ix/Az4k6C2TVI9HzoDe8oW722CGKbosjrR+P2UAeq
6g7elJ/6aFRUof+AvDmcePN4wvmoOKkSZxPBX/2oPR7yvR70VuEzRn+EVUvN
49bB+dH7k1N0jgXIXSIGjJvj9uUwoev7UqoOYct9PM6pqJNse2dkxSUoW/5r
wnLqP6GYwrCnNsyvDBtMq4UYw9F42GTf3IAwJlrr53mKIaGU8Od07NLVvX7G
iDwmfNAniXpJXVJ/hKH4/omuzg/+5/jnzY/Hh16DyipVLCWrVstslXu3v7Ty
K6SSpK01pr2FdaVtoH4AEwM4fIYrlljZEuQtcd8EavvDprSI3fpocjfAq3+l
OvF0Cd8dpNYX1WOj+5D6Kuq23FAtM9c8gQ2sa/h64vdUPzXWIH+wwcrRrvPJ
IP+buNj5n3XfvODL50LMrI9nm9GX83q79wEjoBezMpQta3TPC5O3qTg3LTbS
S4n4OLqHdxfj8yE8Q3sV0GNbgldY4TwoEqjMm/rxvfsBTP6+OZyi3BLPJtgB
lpwCeYFqA5w2FRyCwKMLVApZGksK8jbe2nB38dlskEco7cVCmmKshIx7RVnp
97kBJZYlX7XPeMP1y7Q7ZpomvXyO2alT3HjHYyAwbmDbRFl1i3m+m72B7d4x
mjF6LvSUx5sU503BqZrZn4GD6fZ8+cpL5Snh2Y/Zp5xppEUosAkZI8/y8yxc
AufT2PBvChtAbjckx2LQaFDsie1VxhMnJ9A8hOYzvpCfkbpWz4tc+XkCYXGG
Nq9YzDcmpiPy0ChsqJluGJqv2nL0Mn6owUJZ4dXu4jYZ3Wg4PeAF39C76z7w
hYDqw4amPRjloIMPKoMrmfkXhyM0LNoUNTVX2PeU5hujaP14fHWpEmr2dNqe
kA0cwvr2OtCrEfDfbdBorEsn3Mt0kXs/ZwZREmYNx2L8oOBhAzaFQjV70rXs
pGGGhavjo+vDYxWYsicLGPjApSf+3bAzN5ftNzbZwq6wigY8NtIP1FASkdJ2
qdVsXKJLH4zR853n9smvrT7pkukf/t6NLpsTps/Fn6Xn+Kf0SBkb35Ou6GDQ
uRzHHXX5lvtO8v+oncVBriPuucsJJiPUtm32up+YVPv5NwfSgc60QzH/8TzD
yHQPyZ4k69yii8naTmDfS7IHt7jMCt0gvwEqi5T7LHARrYurIjkKsAMRMNud
zKKTX4jkunKLvJ4VebkdSZKWm8ITv/ZxVdjNFnBPa7yL+j2hOPvAuB0HXm/B
KIKcYQR6HESYKMsvIURP+yFTQKae/hpjpR7HlEMjyv31VO27GoXGK9d2d9Eh
w1BmjnD9p3E0Kk5965ppeqtOoac3FnbrUc5skxFrfqdxAocl6VtkdlZJsfeY
+ONHciqS2Jg3hZ//C4t8eGX78vZHk0fD+JEXKbNAcISN7evYPlre9CnDIoGA
jfv73aRdITFI0mK7RB+w5VJ6EvDs1DhTrL0Rof9PXQA4RjMVhB9+r2+ZpTln
D2TnMlIzU7l4fNvjtmw5tLwphhz6mUhDyjebhUOexYB5ApDN2p+UU7YzJ24v
c9rdoRhTdTiTa9t6VuRR9/mCYoDx1QzbhXEhbKqNd5iAVagalfp79hj1qZw9
pqxq6q7/HKRN4B5GFG9TgpSPuhgdFMD5wLf6EnhW8RWkma0o0aY5md7fKzXA
j/GEVALI5DHCkZgiF3+OZOIIDwtY+0Vc9BJOdxEfupBFc7kWuSF84eFddg9v
91RbSu3zaGEuZcrZzumNyQFAyvx/WuY8odhrasGuYnRjeFJr5jjs5Eml//Vf
wEObja8e4HjGXYgJCY0npWKn3BTKlNniM+xbuZ+OOh3awTCouUS/65qsb5yc
kY/h+rZt1QRbe1YZ4IaAj9IHK3UTW675OBxPKMlAUQ3Mhwoll1sF/DZzUQ8y
l+fOAyMFrpoHiCMh7vidHT9UsT4HGE3vlMw1aKSFYhHJpVdBbq1INBN+h/C7
z0kM4KmmbRIYCvjb7oNmqk2VplZuVCv38IwjfFtmBZ/FFgAzWWMGd/xg4sGM
HjH8HNoSkFZl2OvoFL865zFmYzpGckqZ0YhiUbHK3+rZuFLg5pQw10mnZQ1U
PxVndB5Zy1NQ+ZK1yUlqzdngZCEiGCQdRd0xhTM0sIssn1/lXQ+1CLWFAaTp
3NxQ9T0ovwWRwTpltfAK75PWUCticsphMtp6CbtTaTNgdpdyqkGVd/HgqWSt
ceE07viqOhmbqBfnU/uFnH6EeiAVbQVeGf2yd0w0DCs1Bpz1UV+ZJks5FEb9
jHnPaRzdi0kP/iTpjs/cmWwOdOu7iy1N6NhsBGu1zxRk5LeWE1N7Tr9nlppO
0hmjPkXn7gvIKA+56gi480VmriS7BCL5WdtEj0dNf+bPF5ABXQVK5sb52Qxt
5XeJYpGf3tyGCVF4BRROdKegYs871HzOTGPrxAYDZ54XyXmFGGcNSX+U5fSZ
DR4zNJ2DZTmAdJ6WF0AodCGkes2ORVLSxm37ENKDUOWkvLTS5sB8r8kj4uT+
MNJZqayiXOhXFyCp3Y5xVS8R603tGEBUH6q7H122B6QG96yfA/dAoz4Dt9Ng
8Sw40Loe5VqLYgmtlFKtozeOXaAjY5gMsxK3g9PMLNyeygr9prBh94dW6IPh
YBNvAnrxBF3K8XyKJxvZXdw0p52ib6v3siQIEmQFbu65uFpjXIXf8zSZuxi/
xw0lnzm5bz2qgCLLKqwiiPmNUlRSEhJLOmZbryM2esvIZyqhsg1ba1nNMHXG
V+7DqqMISnZoNc6OWjM6yRRS5veyAnVMI+XPwHopEtL0JSJyFDb+5GdDTs3X
TZS8eu5O/RQciLsRQJCDVHkL/tE6gIWQWNTnWm4d6W6oF95fqwBEAm54LA7/
nZbinnPKFWOAL/A5QG5nPI3TnbW0wtiti4Y8HBlLpzWHYY16sZMGdsY6zeHd
35ljoRpktG/xo+qIZAuli/HheBh9krr+u4vpBEgA3W6860eUrEwS927zioDg
YUnoGRoqoV5u7OHPneFrrd/sVmuI/8M7Hjx1x8MB+X5cT7q97qRLN9poSYZS
NcwLptmVexRH9nKllxSbn2Km8znkhZyqzeQ5jJrDJbnsissh5BzUeWetewim
jq/s8ZIm76upa5poLdvgC3E7g6ciVGuB2lrFqGfW8Vdt8UQgQFNCq6Zysl/w
GrAfDzedAdzz3qEHCvrnAWIXn+wdgE2bnLakne2ChQeSBZ5e3hV05HFXVl7r
bUsrR3FWnjIxgjA8AMiblgITdkLJpxO8ZOStnDueY/eQdcIDPWUY5wUTcPjp
RZPsdniWmtowLTfEYyqgwpqsz6W630nKak4EXHcdIvMnhLdO+DklbqkVeWP/
1kSy0/mBo1CgfwYa0HSfhObmvSEHDaUS9Sl36M1Nezo+HA4mw+kYOQj8n+0e
zvErtBp1eM/uJQMP7X/YSBY67hFnM/Vs5xLTrwEEsBgY7g8DN9QDDQqaG8nT
xcODgysv9m9usIc99VkYlemNAWPBYPqg5OEMEHJfFTUE0nopMwF6o+plhP6p
JfGrSlm5X4/eRkWMAa0T3GI86JkoMIobm5v3UJBsbm74KNc7jKtuJr+LWNUn
RNNBUujsQ/2M05VHNZWC3e7W0qYoHZ3pzIKXnJJYr2oqCvceWCVWx1XVczXT
dZZt4eAfTs9To/maUTYnqsJeSrY2a8ouPhPYF+KWqSrSZSZ2cx8lk2YcjduP
h9PxGHYzbGzkNqCJRV6ynabkMS02BZkZ4U6RZNdsQNWjHPHrTZb2RX2bfMu2
dxtoYqX2hYSG2xD3wA0/pfo5jEbJtBeLRfp7jAei/ZE8yuM5Cd0Fkx6pxO0M
SW22iTX/UM0/zMwfn/b1KN3EO8Px95Yaoqjo5KF5L8MHZpdW92YqN4WiGkwt
w4kaxomli7VR2MZcBom9j07UJjpJqaW9YqahbCerYk7nDoxOFED1IFWB3ub2
+i0eKd+NKQIuMTjtIi1aWGQz05/fiUEYjiktyJ8oxmB+vZLzYZys/iQ9pLTe
3c6eoL2twWALwQATVZV3aoEfGjweU+oXOOdZ39JlPaTPBnOmwkWv41agVZYH
hdiZwcMiyTh1u+WAxSr29DLoPOVDQO2TUS+jdLX5EhyAOWzh5dEx7LJDyTc1
heYl2Xxy0FnprnMoE4eQzSdZbf1gD9Uhk06V77wpVuJ83UXzinL0HLmV7SC0
q3vVd72DJ9ghak/ZO2XxSaKC7R5/KMZIw9hwn9dJQxV36AD9AVrRndstIxq7
5u9spW2VcmmiBXxnpQbxZ7WofopMqG9rcpE/mPwjzakv8rczBZxgjywmR2Sb
k9BaE2JxvnAOi7KzbSdMHRE5BKhBU8QqSpgjc9KfM5Mb9ew55dRRbGKm7f8y
k7gd7JKd8c4OcM2NV2ESf4roFlOZBnO0WklyqS1eKLaEry+8uxN9yb2nhHI2
BuSo0cOE41xY9tqyI1BqmIKop662F4p5a0knS9j8Zdyvw246TKRm/QyrZlgc
c9ib89YcndljLu+wcs8Rh+oupno2NcluwoUorO+xtchtrdGlWiPr+vpXsU04
YbsFbWHue8m4LZFBOA6C2OwrIzWVyro7QBa7B4jkU0f4SzF+9NuYVlKYSu4M
fR/EVCLhAaILBffA/FJPdQJTi2eqAQ5K9xSNJ+qBQjYBzR7HCUV4oI7u5t6s
wvrgyPt40Kq8Kb/KNMsvm2P5VSZYzs5OUWvLktlY8c58/jx+weeJ4CAsc29z
5+wVoBIaWqB5fkLtf0a1RG4HDsdnfVo/ZS+lrf6tLEpUWQVV1E/5H8UOMXB5
iCb3N3lVblMdv4c6Vs/4WExGZvoYDnYk2YhGlSq7QtjMNrfj7WR1xAVLugoW
dYWG01ZH+Likm3BRN4fD3rQ/sDrigiVd1RZ1dYQhZ6O51ZeUOJ3R6Z6MLIMx
SUzabF0dXpwfFgsbP29s+BagoTasOZTy+niSeGK7sePXt7zy7tauv1N3+BZY
0V48bo4iOJWKsJrYvLIhnEsSzX+gTF+9Oa29qfk28Sk4SwkjeE7o4W8bIj9R
jDCjUH6v0zANB45Lk7j7CFTwXHOUyrbxlIXwKQxO410WgdJ4kF3QnHUxJtMn
2RFr56W7mKJv0o0Eau0TbYAFGDD3HiM68qkbZkZQwXkjGhGOEBmbI/e24nnv
yeZ8MPfmccRuVrFdhbr6HHHUJRwFBXe9R8LZI1X+f0eDKSXQDnZ3q74ikvJl
TL8lMFf9MAelJkNRK70K62xKMBzy9+F6QyCHenrAo2BpdnLmE0RPsbuDwRx6
ag77MWb0ZkpMH2DPMlSajuQcKSYxe4JpY+Bu8id+jyPEt+Q9RTqPfowGt6PH
edLFRZiXKtSHqm99gi6QYHzkvUWlTjAS+GB3zDbDMNCDAXUzHXy2O/L64qem
okp3lHkV3kxZfWMPzpzc5qbbuxhOmhj+wVGMokRQCiMB3Y1t9pCn1ZqPeJpo
q5oZnZx+9u5CRQjlYYJ1AAJ+Sb20yeY1rjxUfIloQ6nBNbg51koio9K6FMyk
QHaVqb+rZtMLvg3q3+5WLUbIbPiDNtn0ESOEI4vHODK2AkkUQ8SOitE41skc
DDrpFG7EUbx4I5ZfaReWX2MLll9n/5VfY/OVX7rzyq+w7cqvsufKr7Dhyi/f
beUv32qyrzaD+ibsK+Aa1t4ibH8L+0vM6OEXGmvKlRaycpzKFodG6kfnD+1H
ex3OIS2tycZ/UQ983UX3EVT5EK+63co3Bazue2f/88FTX/UMw8iXcBzBj+/j
1h4txdb8LAmvIwJuUCVSVHtjOyisMXiu/azRl2X0yuyEf4I8jfeKWrMrlzaq
SFVjEz0o1B+iigemzAbQR3GK4J/4D03k6Ap/vsmkJsGXjK+6jjVebRMlv3V3
B5mqSiXIP1XFd+fH9uAOrf7wtz3CgyNrjPjS/aAZHKskpwPeT0PGXoPJNqLY
YLfh40zPnoAzTv6YZx1Vp7L1MXZLF33+mmpfJd45pRAiKwn79Hpva21+VUyu
6qitOkpMR5yLCIXkFNXAwQHxkTaJiUxKd+KtKR1kKMMejodArtAKA7n5nSCg
5MnVraq6zIwSqn2QsCtFkeNfEgagblW/RhNc9RIEuhAlu3RjauGqNt6TZI5A
9E6j+XA6ITsCpkril4E+1RhwnqZoB4sgYRhoGnl7fEaHjf4diiaWTwc6pYCw
zocoh3gw9K07aPemlO4APUGQqu4tjNzmOs6L20TKz50xSzxAVJUl/iK5hi/c
bpGxTDmrj1MNViry0tKQarhaisruItX2C5EzHz2ZRphgGRynAxrfde963eED
UJ7H+a//3N39FV9277qTuP/P4FfkBtBx73cLj/P17+vf17+vf1//vv59/fv6
9/Xv69/Xv69/X/++/n39+/r39e/r39e/r39f/77+ff37+vf17+vf17+vf1//
vv79X/H3/wEEBa5UAIACAA==

--0-858945582-1158812513=:99537--

\start
Date: Thu, 21 Sep 2006 08:14:07 -0500
From: Tim Daly
To: list
Subject: Exact Number Domain

Here's a proposal

Is is possible to create a domain which stores numbers so 
they always have an exact representation that terminates?

Clearly we can do this with FRAC(INT) so that 1/3 is
an exact representation of .333...

But the question is, can we create a domain that will
store the number in the lowest base which holds an exact
representation, such as 121 base 3? Something other than
base 2 or base 10?

It seems to me that some of the issues of floating-point
computation may be handled by dynamically changing the
base so the representation can handle intermediate
results exactly.

Comments?

(I'm on the road until monday evening so email access
is extremely questionable)

\start
Date: Thu, 21 Sep 2006 15:30:16 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Exact Number Domain

On 09/21/2006 03:14 PM, Tim Daly wrote:
> Here's a proposal
> 
> Is is possible to create a domain which stores numbers so 
> they always have an exact representation that terminates?

No it is not. At least not until you reveal what you understand by a 
"number" and what properties it should have.

BTW, how would you store \pi in a finite way? Is it 1 in base \pi?

\start
Date: Thu, 21 Sep 2006 09:43:36 -0400
From: Bill Page
To: Tim Daly
Subject: RE: Exact Number Domain

It is well known that in general real numbers do not have
any exact representation that "terminates" in this sense.
But not everything we do in a computer must be represented
in this way. For example in Axiom we can easily manipultate
series, continuing fractions, and other sorts of "stream-like"
object that are (potentially) infinite in size but which have
finite descriptions.

See http://wiki.axiom-developer.org/RealNumbers

Regards,
Bill Page.

On Thursday, September 21, 2006 9:14 AM Tim Daly wrote:
>
> Here's a proposal
>
> Is is possible to create a domain which stores numbers so
> they always have an exact representation that terminates?
> ...

\start
Date: Thu, 21 Sep 2006 15:54:28 +0200 (CEST)
From: Bertfried Fauser
To: Bill Page
Subject: RE: Exact Number Domain

a very cute question indeed. The approach proposed by Bill Page is quite
interesting in that way, that the completition of a number field can be
done in different ways using ideas from topos theory. I don't even see how
to manage the wealth of possibilities here. However what about truncating
computations in a sort of p-adic way along with a stream like
reprsentations?

To pick up Ralf Hemmeke's example, if you want to represent pi, you might
want it to expand in powers of some prime number, eg 3

pi= a1*3^1+a0*3^0+ .....

a stram like object could represent the n-th power truncated version of
such expansions. The inductive limit of these objects would actually (but
infinitely) represent the number.

Over all it seems to be very complicated and I would not expect such a
representation to be helpful for numeric calculations (speedwise) at all.

\start
Date: 21 Sep 2006 16:07:18 +0200
From: Martin Rubey
To: Alfredo Portes, Tim Daly, Antoine Hersen
Subject: Re: Axiom Conference Call Sept 18, 2006

Dear all, especially Alfredo and Bill!

First of all, I would like to say a big THANK YOU! for your encouragement and
your energy, although it has not quite worked out.

However: If you would save the image somewhere so I can download it, I could
burn a couple of CD's tonight.

I must confirm that I was also using patch 49. I didn't think of that
possibility. I'm truly sorry - please excuse.

On the other hand, I can report that my presentation (even though only a
poster) was quite a success. Although people are very sceptical about Axiom, I
was able to demonstrate that my algorithms are faster by an exponential
facter. (I.e., I need linear time, GFUN get's stack after something like a 100
terms.)

I'll report more when the conference is over, and I'll add some documentation,
too.

Antoine: could you make your univariate holonomic package available? That would
be splendid.

Alfredo Portes writes:

> > So, just to confirm: if you follow all 10 of Martin's steps starting
> > with patch-49 do you obtain a working version of Axiom including
> > Hyperdoc and graphics?
> 
> Yes. I just finished a new trial again with 49 and 50 at the same time.
> 50 breaks, 49 doesn't. I hope somebody can reproduce this.

\start
Date: Thu, 21 Sep 2006 16:18:36 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: [build Axiom] updated Windows buildinstructions

>> The file src/doc/ps/segbind.ps is only available
>> in the tla repository

> As far as I can tell this file is garbage that happened to get
> caught in the archive. It is probably manually saved from the
> graphic produced by the draw command in the file
> 'src/input/segbind.input'.

is it possible with axiom to say "draw(...)" and then save the generated 
picture as a .ps file or a .png without manual interaction? I basically 
want

   echo "draw(...)" | axiom > picture.ps

The reason is that in book.pamphlet there appear via

\spadcommand{draw(...)}

the commands that produce the pictures given in the book. With a little 
rewriting that could be automated and these .ps files in src/doc/ps 
could go away. Note that we should then also be able to produce higher 
resulution pictures (if Axiom allows it).

\start
Date: Thu, 21 Sep 2006 10:55:00 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: [build Axiom] updated Windows buildinstructions

On Thursday, September 21, 2006 10:19 AM you asked:
> ...
> is it possible with axiom to say "draw(...)" and then save
> the generated picture as a .ps file or a .png without manual
> interaction? I basically want
>
>    echo "draw(...)" | axiom > picture.ps
>
> The reason is that in book.pamphlet there appear via
>
> \spadcommand{draw(...)}
>
> the commands that produce the pictures given in the book.
> With a little rewriting that could be automated and these
> .ps files in src/doc/ps could go away. Note that we should
> then also be able to produce higher resulution pictures
> (if Axiom allows it).
>

Yes, all you need is to be using a machine that has X11
installed. his is possible even on a machine that doesn't
have a graphics adapter (such as the axiom-developer.org
server) by using a virtual frame buffer driver.

See "Extensions to MathAction" at

http://wiki.axiom-developer.org/SummerOfCode#msg20050602105831-0500@page.=
axiom-developer.org

And these related pages:

http://wiki.axiom-developer.org/SandBoxXvfbRun

http://wiki.axiom-developer.org/AxiomGraphics

I have tried this while connected via ssh to axiom-developer
server and I am able to create a postscript graphic which
I can then download. My intention is to use this technique
to add Axiom graphics to the wiki pages.

I have verified that I can run the 'axiom -gr -noht' script
inside a Xvfb shell and create postscript files in this way,
but there is a complication due to the interaction between
sman and AXIOMsys that prevent the usual method of communication
via unix pipes from working. The solution is to use the lower
level pty interface to send commands and receive output from
'axiom -gr -noht'. I learned how to do this properly in Python
using a package called 'Pexpect' from reading the code that
does this in Sage. But I haven't had enough extra time available
to contine work on this.

\start
Date: Thu, 21 Sep 2006 11:20:57 -0400
From: Bill Page
To: Bertfried Fauser
Subject: RE: Exact Number Domain

On Thursday, September 21, 2006 9:54 AM you wrote:
> ...
> To pick up Ralf Hemmeke's example, if you want to represent
> pi, you might want it to expand in powers of some prime number,
? eg 3
>
> pi= a1*3^1+a0*3^0+ .....
>
> a stram like object could represent the n-th power truncated
> version of such expansions. The inductive limit of these
> objects would actually (but infinitely) represent the number.
>
> Over all it seems to be very complicated and I would not expect
> such a representation to be helpful for numeric calculations
> (speedwise) at all.
>

For a practical implementation see the RealLib Project:

http://www.brics.dk/~barnie/RealLib

by Branimir Lambov

http://www.brics.dk/~barnie/

and especially his paper:

A two-layer approach to the computability and complexity of
real functions

http://www.brics.dk/~barnie/RealPaper.pdf

The Sage developers are working on an interface to RealLib

http://sage-wiki.axiom-developer.org/RealLib3
http://sage-wiki.axiom-developer.org/DidierDeshommes
http://modular.math.washington.edu/sage/packages/optional

I would like to be able to do this in Axiom.

\start
Date: Thu, 21 Sep 2006 17:26:36 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: [build Axiom] updated Windows buildinstructions

On 09/21/2006 04:55 PM, Page, Bill wrote:
>>    echo "draw(...)" | axiom > picture.ps

> Yes, all you need is to be using a machine that has X11
> installed.

Thank you, Bill. I really thought that it would have been easier.

Does somebody know why X11 is required? Axiom was also sold on Windows 
if I am not completely wrong. How did NAG produce graphics there?

I quickly looked at src/algebra/view2D.spad but I could not see anything 
related to X. Since I have no idea what

   VIEW    ==> VIEWPORTSERVER$Lisp

refers to, I am out of business. :-( But I really really wonder, why X 
is a must for draw and/or write. Does Axiom (through LISP) call some 
functions from X?

\start
Date: Thu, 21 Sep 2006 18:10:26 +0200
From: Kai Kaminski
To: Ralf Hemmecke
Subject: re: [build Axiom] updated Windows buildinstructions

Ralf Hemmecke writes:

> On 09/21/2006 04:55 PM, Page, Bill wrote:
>>>    echo "draw(...)" | axiom > picture.ps
>
>> Yes, all you need is to be using a machine that has X11
>> installed.
>
> Thank you, Bill. I really thought that it would have been easier.
>
> Does somebody know why X11 is required? Axiom was also sold on Windows
> if I am not completely wrong. How did NAG produce graphics there?
I don't know about that.

> I quickly looked at src/algebra/view2D.spad but I could not see
> anything related to X. Since I have no idea what
>
>   VIEW    ==> VIEWPORTSERVER$Lisp
>
> refers to, I am out of business. :-( But I really really wonder, why X
> is a must for draw and/or write. Does Axiom (through LISP) call some
> functions from X?
There is no X11 code in Axiom proper. Axiom only sends the plot data
to Viewman (see the src/graph subdirectory) or one of his friends (I
don't remember the details). They create the graphics and the ability
to dump PS files. Needless to say, they need X11.

Interesting places to look at are (all under $AXIOM/SRC):

GRAPH/*, INTERP/SOCKIO.LISP.PAMPHLET and ALGEBRA/VIEW*.SPAD.PAMPHLET.


To address your problem: I seem to remember that there is a simple way
to print the plot data (i.e. the list of points) to the console. If
not, simply change VIEW2D.SPAD. Then feed that list to GnuPlot.

I attached UIDRAW.SPAD.PAMPHLET, which is a modified VIEW2D.SPAD
(iirc). I used it to generate plot data for my SOC project. I'm sure
you could do a better job, but it worked for me. It prints the data as
Lisp sexps, though. You should probably change that. You also need
*PRINT-ARRAY* to be T.

Kai


--=-=-=

XGRvY3VtZW50Y2xhc3N7YXJ0aWNsZX0KXHVzZXBhY2thZ2V7bm93ZWJ9ClxiZWdpbntkb2N1bWVu
dH0KXHRpdGxle1wkU1BBRC9zcmMvYWxnZWJyYSBkcmF3LnNwYWR9ClxhdXRob3J7Q2xpZnRvbiBK
LiBXaWxsaWFtc29uLCBTY290dCBNb3JyaXNvbiwgSm9uIFN0ZWluYmFjaCwgTWlrZSBEZXdhciwg
S2FpIEthbWluc2tpfQpcbWFrZXRpdGxlClxiZWdpbnthYnN0cmFjdH0KVGhpcyBmaWxlIGlzIGEg
bW9kaWZpZWQgY29weSBvZiB7XHR0IERSQVcuU1BBRC5QQU1QSExFVH0uIEl0IGhhcyBjb2RlCmFk
ZGVkIHNvIHRoYXQgZm9yIHR3by1kaW1lbnNpb25hbCBwbG90cyBzb21lIHBsb3QgaW5mbyBpcyB3
cml0dGVuIHRvCnRoZSBzdGFuZGFyZCBvdXRwdXQuClxlbmR7YWJzdHJhY3R9ClxlamVjdApcdGFi
bGVvZmNvbnRlbnRzClxlamVjdApcc2VjdGlvbntwYWNrYWdlIERSQVdDRlVOIFRvcExldmVsRHJh
d0Z1bmN0aW9uc0ZvckNvbXBpbGVkRnVuY3Rpb25zfQo8PHBhY2thZ2UgRFJBV0NGVU4gVG9wTGV2
ZWxEcmF3RnVuY3Rpb25zRm9yQ29tcGlsZWRGdW5jdGlvbnM+Pj0KKWFiYnJldiBwYWNrYWdlIERS
QVdDRlVOIFRvcExldmVsRHJhd0Z1bmN0aW9uc0ZvckNvbXBpbGVkRnVuY3Rpb25zCisrIEF1dGhv
cjogQ2xpZnRvbiBKLiBXaWxsaWFtc29uCisrIERhdGUgQ3JlYXRlZDogMjIgSnVuZSAxOTkwCisr
IERhdGUgTGFzdCBVcGRhdGVkOiBBdWd1c3QgMjAwNSBieSBLYWkgS2FtaW5za2kKKysgQmFzaWMg
T3BlcmF0aW9uczogZHJhdywgcmVjb2xvcgorKyBSZWxhdGVkIENvbnN0cnVjdG9yczoKKysgQWxz
byBTZWU6CisrIEFNUyBDbGFzc2lmaWNhdGlvbnM6CisrIEtleXdvcmRzOgorKyBSZWZlcmVuY2Vz
OgorKyBEZXNjcmlwdGlvbjogVG9wTGV2ZWxEcmF3RnVuY3Rpb25zRm9yQ29tcGlsZWRGdW5jdGlv
bnMgcHJvdmlkZXMgdG9wIGxldmVsIAorKyBmdW5jdGlvbnMgZm9yIGRyYXdpbmcgZ3JhcGhpY3Mg
b2YgZXhwcmVzc2lvbnMuClRvcExldmVsRHJhd0Z1bmN0aW9uc0ZvckNvbXBpbGVkRnVuY3Rpb25z
KCk6CiBFeHBvcnRzID09IEltcGxlbWVudGF0aW9uIHdoZXJlCiAgQU5ZMSA9PT4gQW55RnVuY3Rp
b25zMQogIEIgICAgPT0+IEJvb2xlYW4KICBGICAgID09PiBGbG9hdAogIEwgICAgPT0+IExpc3QK
ICBTRUcgID09PiBTZWdtZW50IEZsb2F0CiAgU0YgICA9PT4gRG91YmxlRmxvYXQKICBEUk9QID09
PiBEcmF3T3B0aW9uCiAgUExPVCA9PT4gUGxvdAogIFBQQyAgPT0+IFBhcmFtZXRyaWNQbGFuZUN1
cnZlKFNGIC0+IFNGKQogIFBTQyAgPT0+IFBhcmFtZXRyaWNTcGFjZUN1cnZlKFNGIC0+IFNGKQog
IFBTRiAgPT0+IFBhcmFtZXRyaWNTdXJmYWNlKChTRixTRikgLT4gU0YpCiAgUHQgICA9PT4gUG9p
bnQgU0YKICBQU0ZVTiA9PT4gKFNGLCBTRikgLT4gUHQKICBQQ0ZVTiA9PT4gU0YgLT4gUHQKICBT
UEFDRTMgPT0+IFRocmVlU3BhY2UoU0YpCiAgVklFVzIgPT0+IFR3b0RpbWVuc2lvbmFsVmlld3Bv
cnQKICBWSUVXMyA9PT4gVGhyZWVEaW1lbnNpb25hbFZpZXdwb3J0CgogIEV4cG9ydHMgPT0+IHdp
dGgKCi0tJSBUd28gRGltZW5zaW9uYWwgRnVuY3Rpb24gUGxvdHMKCiAgICBkcmF3OiAoU0YgLT4g
U0YsU0VHLEwgRFJPUCkgLT4gVklFVzIKICAgICAgKysgZHJhdyhmLGEuLmIsbCkgZHJhd3MgdGhl
IGdyYXBoIG9mIFxzcGFke3kgPSBmKHgpfSBhcyB4CiAgICAgICsrIHJhbmdlcyBmcm9tIFxzcGFk
e21pbihhLGIpfSB0byBcc3BhZHttYXgoYSxiKX0uCiAgICAgICsrIFRoZSBvcHRpb25zIGNvbnRh
aW5lZCBpbiB0aGUgbGlzdCBsIG9mCiAgICAgICsrIHRoZSBkb21haW4gXHNwYWR7RHJhd09wdGlv
bn0gYXJlIGFwcGxpZWQuCiAgICBkcmF3OiAoU0YgLT4gU0YsU0VHKSAtPiBWSUVXMgogICAgICAr
KyBkcmF3KGYsYS4uYikgZHJhd3MgdGhlIGdyYXBoIG9mIFxzcGFke3kgPSBmKHgpfSBhcyB4CiAg
ICAgICsrIHJhbmdlcyBmcm9tIFxzcGFke21pbihhLGIpfSB0byBcc3BhZHttYXgoYSxiKX0uCgot
LSUgUGFyYW1ldHJpYyBQbGFuZSBDdXJ2ZXMKCiAgICBkcmF3OiAoUFBDLFNFRyxMIERST1ApIC0+
IFZJRVcyCiAgICAgICsrIGRyYXcoY3VydmUoZixnKSxhLi5iLGwpIGRyYXdzIHRoZSBncmFwaCBv
ZiB0aGUgcGFyYW1ldHJpYwogICAgICArKyBjdXJ2ZSBcc3BhZHt4ID0gZih0KSwgeSA9IGcodCl9
IGFzIHQgcmFuZ2VzIGZyb20gXHNwYWR7bWluKGEsYil9IHRvIAogICAgICArKyBcc3BhZHttYXgo
YSxiKX0uCiAgICAgICsrIFRoZSBvcHRpb25zIGNvbnRhaW5lZCBpbiB0aGUgbGlzdCBsIG9mIHRo
ZSBkb21haW4gXHNwYWR7RHJhd09wdGlvbn0KICAgICAgKysgYXJlIGFwcGxpZWQuCiAgICBkcmF3
OiAoUFBDLFNFRykgLT4gVklFVzIKICAgICAgKysgZHJhdyhjdXJ2ZShmLGcpLGEuLmIpIGRyYXdz
IHRoZSBncmFwaCBvZiB0aGUgcGFyYW1ldHJpYwogICAgICArKyBjdXJ2ZSBcc3BhZHt4ID0gZih0
KSwgeSA9IGcodCl9IGFzIHQgcmFuZ2VzIGZyb20gXHNwYWR7bWluKGEsYil9IHRvIAogICAgICAr
KyBcc3BhZHttYXgoYSxiKX0uCgotLSUgUGFyYW1ldHJpYyBTcGFjZSBDdXJ2ZXMKCiAgICBkcmF3
OiAoUFNDLFNFRyxMIERST1ApIC0+IFZJRVczCiAgICAgICsrIGRyYXcoY3VydmUoZixnLGgpLGEu
LmIsbCkgZHJhd3MgdGhlIGdyYXBoIG9mIHRoZSBwYXJhbWV0cmljCiAgICAgICsrIGN1cnZlIFxz
cGFke3ggPSBmKHQpLCB5ID0gZyh0KSwgeiA9IGgodCl9IGFzIHQgcmFuZ2VzIGZyb20gCiAgICAg
ICsrIFxzcGFke21pbihhLGIpfSB0byBcc3BhZHttYXgoYSxiKX0uCiAgICAgICsrIFRoZSBvcHRp
b25zIGNvbnRhaW5lZCBpbiB0aGUgbGlzdCBsIG9mIHRoZSBkb21haW4KICAgICAgKysgXHNwYWR7
RHJhd09wdGlvbn0gYXJlIGFwcGxpZWQuCiAgICBkcmF3OiAoUFNDLFNFRykgLT4gVklFVzMKICAg
ICAgKysgZHJhdyhjdXJ2ZShmLGcsaCksYS4uYixsKSBkcmF3cyB0aGUgZ3JhcGggb2YgdGhlIHBh
cmFtZXRyaWMKICAgICAgKysgY3VydmUgXHNwYWR7eCA9IGYodCksIHkgPSBnKHQpLCB6ID0gaCh0
KX0gYXMgdCByYW5nZXMgZnJvbSAKICAgICAgKysgXHNwYWR7bWluKGEsYil9IHRvIFxzcGFke21h
eChhLGIpfS4KICAgIGRyYXc6IChQQ0ZVTixTRUcsTCBEUk9QKSAtPiBWSUVXMwogICAgICArKyBk
cmF3KGYsYS4uYixsKSBkcmF3cyB0aGUgZ3JhcGggb2YgdGhlIHBhcmFtZXRyaWMKICAgICAgKysg
Y3VydmUgXHNwYWR7Zn0gYXMgdCByYW5nZXMgZnJvbSAKICAgICAgKysgXHNwYWR7bWluKGEsYil9
IHRvIFxzcGFke21heChhLGIpfS4KICAgICAgKysgVGhlIG9wdGlvbnMgY29udGFpbmVkIGluIHRo
ZSBsaXN0IGwgb2YgdGhlIGRvbWFpbgogICAgICArKyBcc3BhZHtEcmF3T3B0aW9ufSBhcmUgYXBw
bGllZC4KICAgIGRyYXc6IChQQ0ZVTixTRUcpIC0+IFZJRVczCiAgICAgICsrIGRyYXcoZixhLi5i
LGwpIGRyYXdzIHRoZSBncmFwaCBvZiB0aGUgcGFyYW1ldHJpYwogICAgICArKyBjdXJ2ZSBcc3Bh
ZHtmfSBhcyB0IHJhbmdlcyBmcm9tIAogICAgICArKyBcc3BhZHttaW4oYSxiKX0gdG8gXHNwYWR7
bWF4KGEsYil9LgoKICAgIG1ha2VPYmplY3Q6IChQU0MsU0VHLEwgRFJPUCkgLT4gU1BBQ0UzCiAg
ICAgICsrIG1ha2VPYmplY3QoY3VydmUoZixnLGgpLGEuLmIsbCkgcmV0dXJucyBhIHNwYWNlIG9m
IHRoZQogICAgICArKyBkb21haW4gXHNwYWR0eXBle1RocmVlU3BhY2V9IHdoaWNoIGNvbnRhaW5z
IHRoZSBncmFwaCBvZiB0aGUKICAgICAgKysgcGFyYW1ldHJpYyBjdXJ2ZSBcc3BhZHt4ID0gZih0
KSwgeSA9IGcodCksIHogPSBoKHQpfSBhcyB0IHJhbmdlcyBmcm9tIAogICAgICArKyBcc3BhZHtt
aW4oYSxiKX0gdG8gXHNwYWR7bWF4KGEsYil9OwogICAgICArKyBUaGUgb3B0aW9ucyBjb250YWlu
ZWQgaW4gdGhlIGxpc3QgbCBvZiB0aGUgZG9tYWluCiAgICAgICsrIFxzcGFke0RyYXdPcHRpb259
IGFyZSBhcHBsaWVkLgogICAgbWFrZU9iamVjdDogKFBTQyxTRUcpIC0+IFNQQUNFMwogICAgICAr
KyBtYWtlT2JqZWN0KHNwLGN1cnZlKGYsZyxoKSxhLi5iKSByZXR1cm5zIHRoZSBzcGFjZSBcc3Bh
ZHtzcH0KICAgICAgKysgb2YgdGhlIGRvbWFpbiBcc3BhZHR5cGV7VGhyZWVTcGFjZX0gd2l0aCB0
aGUgYWRkaXRpb24gb2YgdGhlIGdyYXBoCiAgICAgICsrIG9mIHRoZSBwYXJhbWV0cmljIGN1cnZl
IFxzcGFke3ggPSBmKHQpLCB5ID0gZyh0KSwgeiA9IGgodCl9IGFzIHQKICAgICAgKysgcmFuZ2Vz
IGZyb20gXHNwYWR7bWluKGEsYil9IHRvIFxzcGFke21heChhLGIpfS4KICAgIG1ha2VPYmplY3Q6
IChQQ0ZVTixTRUcsTCBEUk9QKSAtPiBTUEFDRTMKICAgICAgKysgbWFrZU9iamVjdChjdXJ2ZShm
LGcsaCksYS4uYixsKSByZXR1cm5zIGEgc3BhY2Ugb2YgdGhlCiAgICAgICsrIGRvbWFpbiBcc3Bh
ZHR5cGV7VGhyZWVTcGFjZX0gd2hpY2ggY29udGFpbnMgdGhlIGdyYXBoIG9mIHRoZQogICAgICAr
KyBwYXJhbWV0cmljIGN1cnZlIFxzcGFke3ggPSBmKHQpLCB5ID0gZyh0KSwgeiA9IGgodCl9IGFz
IHQgcmFuZ2VzIGZyb20gCiAgICAgICsrIFxzcGFke21pbihhLGIpfSB0byBcc3BhZHttYXgoYSxi
KX0uCiAgICAgICsrIFRoZSBvcHRpb25zIGNvbnRhaW5lZCBpbiB0aGUgbGlzdCBsIG9mIHRoZSBk
b21haW4KICAgICAgKysgXHNwYWR7RHJhd09wdGlvbn0gYXJlIGFwcGxpZWQuCiAgICBtYWtlT2Jq
ZWN0OiAoUENGVU4sU0VHKSAtPiBTUEFDRTMKICAgICAgKysgbWFrZU9iamVjdChzcCxjdXJ2ZShm
LGcsaCksYS4uYikgcmV0dXJucyB0aGUgc3BhY2UgXHNwYWR7c3B9CiAgICAgICsrIG9mIHRoZSBk
b21haW4gXHNwYWR0eXBle1RocmVlU3BhY2V9IHdpdGggdGhlIGFkZGl0aW9uIG9mIHRoZSBncmFw
aAogICAgICArKyBvZiB0aGUgcGFyYW1ldHJpYyBjdXJ2ZSBcc3BhZHt4ID0gZih0KSwgeSA9IGco
dCksIHogPSBoKHQpfSBhcyB0CiAgICAgICsrIHJhbmdlcyBmcm9tIFxzcGFke21pbihhLGIpfSB0
byBcc3BhZHttYXgoYSxiKX0uCgotLSUgVGhyZWUgRGltZW5zaW9uYWwgRnVuY3Rpb24gUGxvdHMK
CiAgICBkcmF3OiAoKFNGLFNGKSAtPiBTRixTRUcsU0VHLEwgRFJPUCkgLT4gVklFVzMKICAgICAg
KysgZHJhdyhmLGEuLmIsYy4uZCxsKSBkcmF3cyB0aGUgZ3JhcGggb2YgXHNwYWR7eiA9IGYoeCx5
KX0KICAgICAgKysgYXMgeCByYW5nZXMgZnJvbSBcc3BhZHttaW4oYSxiKX0gdG8gXHNwYWR7bWF4
KGEsYil9IGFuZCB5IHJhbmdlcyBmcm9tCiAgICAgICsrIFxzcGFke21pbihjLGQpfSB0byBcc3Bh
ZHttYXgoYyxkKX0uCiAgICAgICsrIGFuZCB0aGUgb3B0aW9ucyBjb250YWluZWQgaW4gdGhlIGxp
c3QgbCBvZiB0aGUgZG9tYWluCiAgICAgICsrIFxzcGFke0RyYXdPcHRpb259IGFyZSBhcHBsaWVk
LgogICAgZHJhdzogKChTRixTRikgLT4gU0YsU0VHLFNFRykgLT4gVklFVzMKICAgICAgKysgZHJh
dyhmLGEuLmIsYy4uZCkgZHJhd3MgdGhlIGdyYXBoIG9mIFxzcGFke3ogPSBmKHgseSl9CiAgICAg
ICsrIGFzIHggcmFuZ2VzIGZyb20gXHNwYWR7bWluKGEsYil9IHRvIFxzcGFke21heChhLGIpfSBh
bmQgeSByYW5nZXMgZnJvbQogICAgICArKyBcc3BhZHttaW4oYyxkKX0gdG8gXHNwYWR7bWF4KGMs
ZCl9LgogICAgbWFrZU9iamVjdDogKChTRixTRikgLT4gU0YsU0VHLFNFRyxMIERST1ApIC0+IFNQ
QUNFMwogICAgICArKyBtYWtlT2JqZWN0KGYsYS4uYixjLi5kLGwpIHJldHVybnMgYSBzcGFjZSBv
ZiB0aGUgZG9tYWluCiAgICAgICsrIFxzcGFkdHlwZXtUaHJlZVNwYWNlfSB3aGljaCBjb250YWlu
cyB0aGUgZ3JhcGggb2YgXHNwYWR7eiA9IGYoeCx5KX0KICAgICAgKysgYXMgeCByYW5nZXMgZnJv
bSBcc3BhZHttaW4oYSxiKX0gdG8gXHNwYWR7bWF4KGEsYil9IGFuZCB5IHJhbmdlcyBmcm9tCiAg
ICAgICsrIFxzcGFke21pbihjLGQpfSB0byBcc3BhZHttYXgoYyxkKX0sIGFuZCB0aGUgb3B0aW9u
cyBjb250YWluZWQgaW4gdGhlCiAgICAgICsrIGxpc3QgbCBvZiB0aGUgZG9tYWluIFxzcGFke0Ry
YXdPcHRpb259IGFyZSBhcHBsaWVkLgogICAgbWFrZU9iamVjdDogKChTRixTRikgLT4gU0YsU0VH
LFNFRykgLT4gU1BBQ0UzCiAgICAgICsrIG1ha2VPYmplY3QoZixhLi5iLGMuLmQpIHJldHVybnMg
YSBzcGFjZSBvZiB0aGUgZG9tYWluCiAgICAgICsrIFxzcGFkdHlwZXtUaHJlZVNwYWNlfSB3aGlj
aCBjb250YWlucyB0aGUgZ3JhcGggb2YgXHNwYWR7eiA9IGYoeCx5KX0KICAgICAgKysgYXMgeCBy
YW5nZXMgZnJvbSBcc3BhZHttaW4oYSxiKX0gdG8gXHNwYWR7bWF4KGEsYil9IGFuZCB5IHJhbmdl
cyBmcm9tCiAgICAgICsrIFxzcGFke21pbihjLGQpfSB0byBcc3BhZHttYXgoYyxkKX0uCgotLSUg
UGFyYW1ldHJpYyBTdXJmYWNlcwoKICAgIGRyYXc6IChQU0ZVTiwgU0VHLCBTRUcsIEwgRFJPUCkg
LT4gVklFVzMKICAgICAgKysgZHJhdyhmLGEuLmIsYy4uZCkgZHJhd3MgdGhlCiAgICAgICsrIGdy
YXBoIG9mIHRoZSBwYXJhbWV0cmljIHN1cmZhY2UgXHNwYWR7Zih1LHYpfQogICAgICArKyBhcyB1
IHJhbmdlcyBmcm9tIFxzcGFke21pbihhLGIpfSB0byBcc3BhZHttYXgoYSxiKX0KICAgICAgKysg
YW5kIHYgcmFuZ2VzIGZyb20gXHNwYWR7bWluKGMsZCl9IHRvIFxzcGFke21heChjLGQpfS4KICAg
ICAgKysgVGhlIG9wdGlvbnMgY29udGFpbmVkIGluIHRoZQogICAgICArKyBsaXN0IGwgb2YgdGhl
IGRvbWFpbiBcc3BhZHtEcmF3T3B0aW9ufSBhcmUgYXBwbGllZC4KICAgIGRyYXc6IChQU0ZVTiwg
U0VHLCBTRUcpIC0+IFZJRVczCiAgICAgICsrIGRyYXcoZixhLi5iLGMuLmQpIGRyYXdzIHRoZQog
ICAgICArKyBncmFwaCBvZiB0aGUgcGFyYW1ldHJpYyBzdXJmYWNlIFxzcGFke2YodSx2KX0KICAg
ICAgKysgYXMgdSByYW5nZXMgZnJvbSBcc3BhZHttaW4oYSxiKX0gdG8gXHNwYWR7bWF4KGEsYil9
CiAgICAgICsrIGFuZCB2IHJhbmdlcyBmcm9tIFxzcGFke21pbihjLGQpfSB0byBcc3BhZHttYXgo
YyxkKX0KICAgICAgKysgVGhlIG9wdGlvbnMgY29udGFpbmVkIGluIHRoZSBsaXN0CiAgICAgICsr
IGwgb2YgdGhlIGRvbWFpbiBcc3BhZHtEcmF3T3B0aW9ufSBhcmUgYXBwbGllZC4KICAgIG1ha2VP
YmplY3Q6IChQU0ZVTiwgU0VHLCBTRUcsIEwgRFJPUCkgLT4gU1BBQ0UzCiAgICAgICsrIG1ha2VP
YmplY3QoZixhLi5iLGMuLmQsbCkgcmV0dXJucyBhCiAgICAgICsrIHNwYWNlIG9mIHRoZSBkb21h
aW4gXHNwYWR0eXBle1RocmVlU3BhY2V9IHdoaWNoIGNvbnRhaW5zIHRoZQogICAgICArKyBncmFw
aCBvZiB0aGUgcGFyYW1ldHJpYyBzdXJmYWNlIFxzcGFke2YodSx2KX0KICAgICAgKysgYXMgdSBy
YW5nZXMgZnJvbSBcc3BhZHttaW4oYSxiKX0gdG8KICAgICAgKysgXHNwYWR7bWF4KGEsYil9IGFu
ZCB2IHJhbmdlcyBmcm9tIFxzcGFke21pbihjLGQpfSB0byBcc3BhZHttYXgoYyxkKX07CiAgICAg
ICsrIFRoZSBvcHRpb25zIGNvbnRhaW5lZCBpbiB0aGUKICAgICAgKysgbGlzdCBsIG9mIHRoZSBk
b21haW4gXHNwYWR7RHJhd09wdGlvbn0gYXJlIGFwcGxpZWQuCiAgICBtYWtlT2JqZWN0OiAoUFNG
VU4sIFNFRywgU0VHKSAtPiBTUEFDRTMKICAgICAgKysgbWFrZU9iamVjdChmLGEuLmIsYy4uZCxs
KSByZXR1cm5zIGEKICAgICAgKysgc3BhY2Ugb2YgdGhlIGRvbWFpbiBcc3BhZHR5cGV7VGhyZWVT
cGFjZX0gd2hpY2ggY29udGFpbnMgdGhlCiAgICAgICsrIGdyYXBoIG9mIHRoZSBwYXJhbWV0cmlj
IHN1cmZhY2UgXHNwYWR7Zih1LHYpfQogICAgICArKyBhcyB1IHJhbmdlcyBmcm9tIFxzcGFke21p
bihhLGIpfSB0bwogICAgICArKyBcc3BhZHttYXgoYSxiKX0gYW5kIHYgcmFuZ2VzIGZyb20gXHNw
YWR7bWluKGMsZCl9IHRvIFxzcGFke21heChjLGQpfS4KICAgIGRyYXc6IChQU0YsU0VHLFNFRyxM
IERST1ApIC0+IFZJRVczCiAgICAgICsrIGRyYXcoc3VyZmFjZShmLGcsaCksYS4uYixjLi5kKSBk
cmF3cyB0aGUKICAgICAgKysgZ3JhcGggb2YgdGhlIHBhcmFtZXRyaWMgc3VyZmFjZSBcc3BhZHt4
ID0gZih1LHYpfSwgXHNwYWR7eSA9IGcodSx2KX0sCiAgICAgICsrIFxzcGFke3ogPSBoKHUsdil9
IGFzIHUgcmFuZ2VzIGZyb20gXHNwYWR7bWluKGEsYil9IHRvIFxzcGFke21heChhLGIpfQogICAg
ICArKyBhbmQgdiByYW5nZXMgZnJvbSBcc3BhZHttaW4oYyxkKX0gdG8gXHNwYWR7bWF4KGMsZCl9
OwogICAgICArKyBUaGUgb3B0aW9ucyBjb250YWluZWQgaW4gdGhlCiAgICAgICsrIGxpc3QgbCBv
ZiB0aGUgZG9tYWluIFxzcGFke0RyYXdPcHRpb259IGFyZSBhcHBsaWVkLgogICAgZHJhdzogKFBT
RixTRUcsU0VHKSAtPiBWSUVXMwogICAgICArKyBkcmF3KHN1cmZhY2UoZixnLGgpLGEuLmIsYy4u
ZCkgZHJhd3MgdGhlCiAgICAgICsrIGdyYXBoIG9mIHRoZSBwYXJhbWV0cmljIHN1cmZhY2UgXHNw
YWR7eCA9IGYodSx2KX0sIFxzcGFke3kgPSBnKHUsdil9LAogICAgICArKyBcc3BhZHt6ID0gaCh1
LHYpfSBhcyB1IHJhbmdlcyBmcm9tIFxzcGFke21pbihhLGIpfSB0byBcc3BhZHttYXgoYSxiKX0K
ICAgICAgKysgYW5kIHYgcmFuZ2VzIGZyb20gXHNwYWR7bWluKGMsZCl9IHRvIFxzcGFke21heChj
LGQpfTsKICAgIG1ha2VPYmplY3Q6IChQU0YsU0VHLFNFRyxMIERST1ApIC0+IFNQQUNFMwogICAg
ICArKyBtYWtlT2JqZWN0KHN1cmZhY2UoZixnLGgpLGEuLmIsYy4uZCxsKSByZXR1cm5zIGEKICAg
ICAgKysgc3BhY2Ugb2YgdGhlIGRvbWFpbiBcc3BhZHR5cGV7VGhyZWVTcGFjZX0gd2hpY2ggY29u
dGFpbnMgdGhlCiAgICAgICsrIGdyYXBoIG9mIHRoZSBwYXJhbWV0cmljIHN1cmZhY2UgXHNwYWR7
eCA9IGYodSx2KX0sIFxzcGFke3kgPSBnKHUsdil9LAogICAgICArKyBcc3BhZHt6ID0gaCh1LHYp
fSBhcyB1IHJhbmdlcyBmcm9tIFxzcGFke21pbihhLGIpfSB0bwogICAgICArKyBcc3BhZHttYXgo
YSxiKX0gYW5kIHYgcmFuZ2VzIGZyb20gXHNwYWR7bWluKGMsZCl9IHRvIFxzcGFke21heChjLGQp
fS4KICAgICAgKysgVGhlIG9wdGlvbnMgY29udGFpbmVkIGluIHRoZQogICAgICArKyBsaXN0IGwg
b2YgdGhlIGRvbWFpbiBcc3BhZHtEcmF3T3B0aW9ufSBhcmUgYXBwbGllZC4KICAgIG1ha2VPYmpl
Y3Q6IChQU0YsU0VHLFNFRykgLT4gU1BBQ0UzCiAgICAgICsrIG1ha2VPYmplY3Qoc3VyZmFjZShm
LGcsaCksYS4uYixjLi5kLGwpIHJldHVybnMgYQogICAgICArKyBzcGFjZSBvZiB0aGUgZG9tYWlu
IFxzcGFkdHlwZXtUaHJlZVNwYWNlfSB3aGljaCBjb250YWlucyB0aGUKICAgICAgKysgZ3JhcGgg
b2YgdGhlIHBhcmFtZXRyaWMgc3VyZmFjZSBcc3BhZHt4ID0gZih1LHYpfSwgXHNwYWR7eSA9IGco
dSx2KX0sCiAgICAgICsrIFxzcGFke3ogPSBoKHUsdil9IGFzIHUgcmFuZ2VzIGZyb20gXHNwYWR7
bWluKGEsYil9IHRvCiAgICAgICsrIFxzcGFke21heChhLGIpfSBhbmQgdiByYW5nZXMgZnJvbSBc
c3BhZHttaW4oYyxkKX0gdG8gXHNwYWR7bWF4KGMsZCl9LgogICAgcmVjb2xvcjogKChTRixTRikg
LT4gUHQsKFNGLFNGLFNGKSAtPiBTRikgLT4gKChTRixTRikgLT4gUHQpCiAgICAgICsrIHJlY29s
b3IoKSwgdW5pbnRlcmVzdGluZyB0byB0b3AgbGV2ZWwgdXNlcjsgZXhwb3J0ZWQgaW4gb3JkZXIg
dG8gCiAgICAgICsrIGNvbXBpbGUgcGFja2FnZS4KCiAgSW1wbGVtZW50YXRpb24gPT0+IGFkZAog
ICAgLS0hISAgSSBoYXZlIGhhZCB0byB3b3JrIG15IHdheSBhcm91bmQgdGhlIGZvbGxvd2luZyBi
dWcgaW4gdGhlIGNvbXBpbGVyOgogICAgLS0hISAgV2hlbiBhIGxvY2FsIHZhcmlhYmxlIGlzIGdp
dmVuIGEgbWFwcGluZyBhcyBhIHZhbHVlLCBlLmcuCiAgICAtLSEhICBmb28gOiBTRiAtPiBTRiA6
PSBtYWtlRmxvYXRGdW5jdGlvbihmLHQpLAogICAgLS0hISAgdGhlIGNvbXBpbGVyIGNhbm5vdCBk
aXN0aW5ndWlzaCB0aGF0IGxvY2FsIHZhcmlhYmxlIGZyb20gYSBsb2NhbAogICAgLS0hISAgZnVu
Y3Rpb24gZGVmaW5lZCBlbHNld2hlcmUgaW4gdGhlIHBhY2thZ2UuICBUaHVzLCB3aGVuICdmb28n
IGlzCiAgICAtLSEhICBwYXNzZWQgdG8gYSBmdW5jdGlvbiwgZS5nLgogICAgLS0hISAgYmlyZCA6
PSBmY24oZm9vKSwKICAgIC0tISEgIGZvbyB3aWxsIG9mdGVuIGJlIGNvbXBpbGVkIGFzIHxEUkFX
O2Zvb3wgcmF0aGVyIHRoYW4gfGZvb3wuIFRoaXMsCiAgICAtLSEhICBvZiBjb3Vyc2UsIGNhdXNl
cyBhIHJ1bi10aW1lIGVycm9yLgogICAgLS0hISAgVG8gYXZvaWQgdGhpcyBwcm9ibGVtLCBsb2Nh
bCB2YXJpYWJsZXMgYXJlIG5vdCBnaXZlbiBtYXBwaW5ncyBhcwogICAgLS0hISAgdmFsdWVzLCBi
dXQgcmF0aGVyIChzaW5nbGV0b24pIGxpc3RzIG9mIG1hcHBpbmdzLiAgVGhlIGZpcnN0IGVsZW1l
bnQKICAgIC0tISEgIG9mIHRoZSBsaXN0IGNhbiBhbHdheXMgYmUgZXh0cmFjdGVkIGFuZCBldmVy
eXRoaW5nIGdvZXMgdGhyb3VnaAogICAgLS0hISAgYXMgYmVmb3JlLiAgVGhlcmUgaXMgbm8gbWFq
b3IgbG9zcyBpbiBlZmZpY2llbmN5LCBhcyB0aGUgY29tcHV0YXRpb24KICAgIC0tISEgIG9mIHBv
aW50cyB3aWxsIGFsd2F5cyBkb21pbmF0ZSB0aGUgY29tcHV0YXRpb24gdGltZS4KICAgIC0tISEg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLSBjancsICAyMiBKdW5lIE1DTVhD
CgogICAgaW1wb3J0IFBMT1QKICAgIGltcG9ydCBUd29EaW1lbnNpb25hbFBsb3RDbGlwcGluZwog
ICAgaW1wb3J0IEdyYXBoaWNzRGVmYXVsdHMKICAgIGltcG9ydCBWaWV3cG9ydFBhY2thZ2UKICAg
IGltcG9ydCBUaHJlZURpbWVuc2lvbmFsVmlld3BvcnQKICAgIGltcG9ydCBEcmF3T3B0aW9uRnVu
Y3Rpb25zMAogICAgaW1wb3J0IE1ha2VGbG9hdENvbXBpbGVkRnVuY3Rpb24oRXgpCiAgICBpbXBv
cnQgTWVzaENyZWF0aW9uUm91dGluZXNGb3JUaHJlZURpbWVuc2lvbnMKICAgIGltcG9ydCBTZWdt
ZW50RnVuY3Rpb25zMihTRixGbG9hdCkKICAgIGltcG9ydCBWaWV3RGVmYXVsdHNQYWNrYWdlCiAg
ICBpbXBvcnQgQW55RnVuY3Rpb25zMShQdCAtPiBQdCkKICAgIGltcG9ydCBBbnlGdW5jdGlvbnMx
KChTRixTRixTRikgLT4gU0YpCiAgICBpbXBvcnQgRHJhd09wdGlvbkZ1bmN0aW9uczAKICAgIGlt
cG9ydCBTUEFDRTMKCiAgICBFWFRPVkFSRVJST1IgOiBTdHJpbmcgOj0gXwogICAgICAiZHJhdzog
d2hlbiBzcGVjaWZ5aW5nIGZ1bmN0aW9uLCBsZWZ0IGhhbmQgc2lkZSBtdXN0IGJlIGEgdmFyaWFi
bGUiCiAgICBTTUFMTFJBTkdFRVJST1IgOiBTdHJpbmcgOj0gXwogICAgICAiZHJhdzogcmFuZ2Ug
aXMgaW4gaW50ZXJ2YWwgd2l0aCBvbmx5IG9uZSBwb2ludCIKICAgIERFUFZBUkVSUk9SIDogU3Ry
aW5nIDo9IF8KICAgICAgImRyYXc6IGluZGVwZW5kZW50IHZhcmlhYmxlIGFwcGVhcnMgb24gbGhz
IG9mIGZ1bmN0aW9uIGRlZmluaXRpb24iCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KLS0gICAgICAgICAgICAg
ICAgICAgICAyRCAtIGRyYXcncyAgCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKICAgIGRyYXdUb1NjYWxlUmFu
Z2VzOiAoU2VnbWVudCBTRixTZWdtZW50IFNGKSAtPiBMIFNFRwogICAgZHJhd1RvU2NhbGVSYW5n
ZXMoeFZhbHMseVZhbHMpID09CiAgICAgIC0tIHdhcm5pbmc6IGFzc3VtZXMgd2luZG93IGlzIHNx
dWFyZQogICAgICB4SGkgOj0gY29udmVydChoaSB4VmFscylARmxvYXQ7IHhMbyA6PSBjb252ZXJ0
KGxvIHhWYWxzKUBGbG9hdAogICAgICB5SGkgOj0gY29udmVydChoaSB5VmFscylARmxvYXQ7IHlM
byA6PSBjb252ZXJ0KGxvIHlWYWxzKUBGbG9hdAogICAgICB4RGlmZiA6PSB4SGkgLSB4TG87IHlE
aWZmIDo9IHlIaSAtIHlMbwogICAgICBwYWQgOj0gYWJzKHlEaWZmIC0geERpZmYpLzIKICAgICAg
eURpZmYgPiB4RGlmZiA9PgogICAgICAgIFtzZWdtZW50KHhMbyAtIHBhZCx4SGkgKyBwYWQpLG1h
cChjb252ZXJ0KCMxKUBGbG9hdCx5VmFscyldCiAgICAgIFttYXAoY29udmVydCgjMSlARmxvYXQs
eFZhbHMpLHNlZ21lbnQoeUxvIC0gcGFkLHlIaSArIHBhZCldCgogICAgcHJpbnRGbG9hdDogRmxv
YXQgLT4gJQogICAgcHJpbnRGbG9hdCAoZikgPT0KICAgICAgUFJJTkMkTGlzcCAiICIKICAgICAg
UFJJTkMkTGlzcCAoY29udmVydChmKUBTdHJpbmcpCiAgICAgIFBSSU5DJExpc3AgIiAiCgogICAg
ZHJhd1Bsb3Q6IChQTE9ULEwgRFJPUCkgLT4gVklFVzIKICAgIGRyYXdQbG90KHBsb3QsbCkgPT0K
ICAgICAgYnJhbmNoZXMgOj0gbGlzdEJyYW5jaGVzIHBsb3QKICAgICAgeFJhbmdlIDo9IHhSYW5n
ZSBwbG90OyB5UmFuZ2UgOj0geVJhbmdlIHBsb3QKICAgICAgLS0gcHJvY2VzcyBjbGlwcGluZyBp
bmZvcm1hdGlvbgogICAgICBpZiAoY2wgOj0gb3B0aW9uKGwsImNsaXBTZWdtZW50IiA6OiBTeW1i
b2wpKSBjYXNlICJmYWlsZWQiIHRoZW4KICAgICAgICBpZiBjbGlwQm9vbGVhbihsLGNsaXBQb2lu
dHNEZWZhdWx0KCkpIHRoZW4KICAgICAgICAgIGNsaXBJbmZvIDo9CiAgICAgICAgICAgIHBhcmFt
ZXRyaWM/IHBsb3QgPT4gY2xpcFBhcmFtZXRyaWMgcGxvdAogICAgICAgICAgICBjbGlwIHBsb3QK
ICAgICAgICAgIGJyYW5jaGVzIDo9IGNsaXBJbmZvLmJyYW5zCiAgICAgICAgICB4UmFuZ2UgOj0g
Y2xpcEluZm8ueFZhbHVlczsgeVJhbmdlIDo9IGNsaXBJbmZvLnlWYWx1ZXMKICAgICAgICBlbHNl
CiAgICAgICAgICAiTm8gZXhwbGljaXQgdXNlci1zcGVjaWZpZWQgY2xpcHBpbmciCiAgICAgIGVs
c2UKICAgICAgICBzZWdMaXN0IDo9IHJldHJhY3QoY2wgOjogQW55KSRBTlkxKEwgU0VHKQogICAg
ICAgIGVtcHR5PyBzZWdMaXN0ID0+CiAgICAgICAgICBlcnJvciAiZHJhdzogeW91IG1heSBzcGVj
aWZ5IGF0IGxlYXN0IDEgc2VnbWVudCBmb3IgMkQgY2xpcHBpbmciCiAgICAgICAgbW9yZT8oc2Vn
TGlzdCwyKSA9PgogICAgICAgICAgZXJyb3IgImRyYXc6IHlvdSBtYXkgc3BlY2lmeSBhdCBtb3N0
IDIgc2VnbWVudHMgZm9yIDJEIGNsaXBwaW5nIgogICAgICAgIHhMbyA6IFNGIDo9IDA7IHhIaSA6
IFNGIDo9IDA7IHlMbyA6IFNGIDo9IDA7IHlIaSA6IFNGIDo9IDAKICAgICAgICBpZiBlbXB0eT8g
cmVzdCBzZWdMaXN0IHRoZW4KICAgICAgICAgIHhMbyA6PSBsbyB4UmFuZ2U7IHhIaSA6PSBoaSB4
UmFuZ2UKICAgICAgICAgIHlSYW5nZUYgOj0gZmlyc3Qgc2VnTGlzdAogICAgICAgICAgeUxvIDo9
IGNvbnZlcnQobG8geVJhbmdlRilAU0Y7IHlIaSA6PSBjb252ZXJ0KGhpIHlSYW5nZUYpQFNGCiAg
ICAgICAgZWxzZQogICAgICAgICAgeFJhbmdlRiA6PSBmaXJzdCBzZWdMaXN0CiAgICAgICAgICB4
TG8gOj0gY29udmVydChsbyB4UmFuZ2VGKUBTRjsgeEhpIDo9IGNvbnZlcnQoaGkgeFJhbmdlRilA
U0YKICAgICAgICAgIHlSYW5nZUYgOj0gc2Vjb25kIHNlZ0xpc3QKICAgICAgICAgIHlMbyA6PSBj
b252ZXJ0KGxvIHlSYW5nZUYpQFNGOyB5SGkgOj0gY29udmVydChoaSB5UmFuZ2VGKUBTRgogICAg
ICAgIGNsaXBJbmZvIDo9IGNsaXBXaXRoUmFuZ2VzKGJyYW5jaGVzLHhMbyx4SGkseUxvLHlIaSkK
ICAgICAgICBicmFuY2hlcyA6PSBjbGlwSW5mby5icmFucwogICAgICAgIHhSYW5nZSA6PSBjbGlw
SW5mby54VmFsdWVzOyB5UmFuZ2UgOj0gY2xpcEluZm8ueVZhbHVlcwogICAgICAtLSBwcm9jZXNz
IHNjYWxpbmcgaW5mb3JtYXRpb24KICAgICAgaWYgdG9TY2FsZShsLGRyYXdUb1NjYWxlKCkpIHRo
ZW4KICAgICAgICBzY2FsZWRSYW5nZXMgOj0gZHJhd1RvU2NhbGVSYW5nZXMoeFJhbmdlLHlSYW5n
ZSkKICAgICAgICAtLSBhZGQgc2NhbGVkIHJhbmdlcyB0byBsaXN0IG9mIG9wdGlvbnMKICAgICAg
ICBsIDo9IGNvbmNhdChyYW5nZXMgc2NhbGVkUmFuZ2VzLGwpCiAgICAgIGVsc2UKICAgICAgICB4
UmFuZ2VGbG9hdCA6IFNFRyA6PSBtYXAoY29udmVydCgjMSlARmxvYXQseFJhbmdlKQogICAgICAg
IHlSYW5nZUZsb2F0IDogU0VHIDo9IG1hcChjb252ZXJ0KCMxKUBGbG9hdCx5UmFuZ2UpCiAgICAg
ICAgLS0gYWRkIHJhbmdlcyB0byBsaXN0IG9mIG9wdGlvbnMKICAgICAgICBsIDo9IGNvbmNhdChy
YW5nZXMobGwgOiBMIFNFRyA6PSBbeFJhbmdlRmxvYXQseVJhbmdlRmxvYXRdKSxsKQogICAgICAt
LSBwcm9jZXNzIGNvbG9yIGluZm9ybWF0aW9uCiAgICAgIHB0Q29sIDo9IHBvaW50Q29sb3JQYWxl
dHRlKGwscG9pbnRDb2xvckRlZmF1bHQoKSkKICAgICAgY3JDb2wgOj0gY3VydmVDb2xvclBhbGV0
dGUobCxsaW5lQ29sb3JEZWZhdWx0KCkpCgogICAgICAtLSBwcmludCB0aGUgYnJhbmNoZXMgKCpQ
UklOVC1BUlJBWSogbXVzdCBiZSBzZXQgdG8gVCwgb3RoZXJ3aXNlCiAgICAgIC0tIHRoZSBwcmlu
dG91dCB3aWxsIGJlIHVzZWxlc3MuCiAgICAgIFBSSU5DJExpc3AgIlBMT1REQVRBQkVHSU4gIgoK
ICAgICAgLS0gb3B0aW9ucwogICAgICBQUklOQyRMaXNwICIoIgogICAgICAtLSByYW5nZXMKICAg
ICAgUFJJTkMkTGlzcCAiOnJhbmdlICIKICAgICAgb3V0cHV0U3BhY2luZygwKQogICAgICBsb3gg
Oj0gbG93IHhSYW5nZUZsb2F0CiAgICAgIGhpeCA6PSBoaSB4UmFuZ2VGbG9hdAogICAgICBsb3kg
Oj0gbG93IHlSYW5nZUZsb2F0CiAgICAgIGhpeSA6PSBoaSB5UmFuZ2VGbG9hdAogICAgICBQUklO
QyRMaXNwICIoIgogICAgICBQUklOQyRMaXNwIChjb252ZXJ0KGxveClAU3RyaW5nKQogICAgICBQ
UklOQyRMaXNwICIgIgogICAgICBQUklOQyRMaXNwIChjb252ZXJ0KGxveSlAU3RyaW5nKQogICAg
ICBQUklOQyRMaXNwICIgIgogICAgICBQUklOQyRMaXNwIChjb252ZXJ0KGhpeClAU3RyaW5nKQog
ICAgICBQUklOQyRMaXNwICIgIgogICAgICBQUklOQyRMaXNwIChjb252ZXJ0KGhpeSlAU3RyaW5n
KQogICAgICBQUklOQyRMaXNwICIgIgogICAgICBQUklOQyRMaXNwICIpIgoKICAgICAgLS0gdW5p
dHMKICAgICAgUFJJTkMkTGlzcCAiIDp1bml0ICIKICAgICAgdSA6PSB1bml0cyhsLFtdQChMaXN0
IEZsb2F0KSlAKExpc3QgRmxvYXQpCiAgICAgIFBSSU5DJExpc3AgIigiCiAgICAgIGlmIG5vdCBu
dWxsIHUgIHRoZW4KICAgICAgICBmb3IgeCBpbiB1IHJlcGVhdAogICAgICAgICAgcHJpbnRGbG9h
dCh4KQogICAgICBQUklOQyRMaXNwICIpIgoKICAgICAgLS0gdGl0bGUKICAgICAgUFJJTkMkTGlz
cCAiIDp0aXRsZSAiCiAgICAgIHRpdGxlIDogU3RyaW5nIDo9IHRpdGxlKGwsICJBeGlvbSAyRCBQ
bG90IikKICAgICAgUFJJTlQkTGlzcCB0aXRsZQoKICAgICAgUFJJTkMkTGlzcCAiIDpicmFuY2hl
cyAiCiAgICAgIFBSSU5DJExpc3AgYnJhbmNoZXMKICAgICAgUFJJTkMkTGlzcCAiKSIKICAgICAg
UFJJTkMkTGlzcCAiUExPVERBVEFFTkQiCgogICAgICAtLSBkcmF3CiAgICAgIGRyYXdDdXJ2ZXMo
YnJhbmNoZXMscHRDb2wsY3JDb2wscG9pbnRTaXplRGVmYXVsdCgpLGwpCgogICAgbm9ybWFsaXpl
OiBTRUcgLT4gU2VnbWVudCBTRgogICAgbm9ybWFsaXplIHNlZyA9PQogICAgICAtLSBub3JtYWxp
emUgW2EsYl06CiAgICAgIC0tIGVycm9yIGlmIGEgPSBiLCByZXR1cm5zIFthLGJdIGlmIGEgPCBi
LCByZXR1cm5zIFtiLGFdIGlmIGIgPiBhCiAgICAgIGEgOj0gY29udmVydChsbyBzZWcpQFNGOyBi
IDo9IGNvbnZlcnQoaGkgc2VnKUBTRgogICAgICBhID0gYiA9PiBlcnJvciBTTUFMTFJBTkdFRVJS
T1IKICAgICAgYSA8IGIgPT4gc2VnbWVudChhLGIpCiAgICAgIHNlZ21lbnQoYixhKQoKLS0lIGZ1
bmN0aW9ucyBmb3IgY3JlYXRpb24gb2YgbWFwcyBTRiAtPiBQb2ludCBTRiAodHdvIGRpbWVuc2lv
bmFsKQoKICAgIG15VHJhcDE6IChTRi0+IFNGLCBTRikgLT4gU0YKICAgIG15VHJhcDEoZmY6U0Yt
PiBTRiwgZjpTRik6U0YgPT0KICAgICAgcyA6PSB0cmFwTnVtZXJpY0Vycm9ycyhmZihmKSkkTGlz
cCA6OiBVbmlvbihTRiwgImZhaWxlZCIpCiAgICAgIHMgY2FzZSAiZmFpbGVkIiA9PiBfJE5hTnZh
bHVlJExpc3AKICAgICAgcjo9czo6U0YKICAgICAgciA+bWF4KCkkU0Ygb3IgciA8IG1pbigpJFNG
ID0+IF8kTmFOdmFsdWUkTGlzcAogICAgICByCgogICAgbWFrZVB0MjogKFNGLFNGKSAtPiBQb2lu
dCBTRgogICAgbWFrZVB0Mih4LHkpID09IHBvaW50KGwgOiBMaXN0IFNGIDo9IFt4LHldKQoKLS0l
IFR3byBEaW1lbnNpb25hbCBGdW5jdGlvbiBQbG90cwogCiAgICBkcmF3KGY6U0YgLT4gU0Ysc2Vn
OlNFRyxsOkwgRFJPUCkgPT0KICAgICAgLS0gc2V0IGFkYXB0aXZlIHBsb3R0aW5nIG9mZiBvciBv
bgogICAgICBvbGRBZGFwdGl2ZSA6PSBhZGFwdGl2ZT8oKSRQTE9UCiAgICAgIHNldEFkYXB0aXZl
KGFkYXB0aXZlKGwsb2xkQWRhcHRpdmUpKSRQTE9UCiAgICAgIC0tIGNyZWF0ZSBmdW5jdGlvbiBT
RiAtPiBQb2ludCBTRgogICAgICBmZiA6IEwoU0YgLT4gUG9pbnQgU0YpIDo9IFttYWtlUHQyKG15
VHJhcDEoZiwjMSksIzEpXQogICAgICAtLSBwcm9jZXNzIGNoYW5nZSBvZiBjb29yZGluYXRlcwog
ICAgICBpZiAoYyA6PSBvcHRpb24obCwiY29vcmRpbmF0ZXMiIDo6IFN5bWJvbCkpIGNhc2UgImZh
aWxlZCIgdGhlbgogICAgICAgIC0tIGRlZmF1bHQgY29vcmRpbmF0ZSB0cmFuc2Zvcm1hdGlvbgog
ICAgICAgIGZmIDo9IFttYWtlUHQyKCMxLG15VHJhcDEoZiwjMSkpXQogICAgICBlbHNlCiAgICAg
ICAgY2MgOiBMKFB0IC0+IFB0KSA6PSBbcmV0cmFjdChjIDo6IEFueSkkQU5ZMShQdCAtPiBQdCld
CiAgICAgICAgZmYgOj0gWyhmaXJzdCBjYykoKGZpcnN0IGZmKSgjMSkpXQogICAgICAtLSBjcmVh
dGUgUExPVAogICAgICBwbCA6PSBwb2ludFBsb3QoZmlyc3QgZmYsbm9ybWFsaXplIHNlZykKICAg
ICAgLS0gcmVzZXQgYWRhcHRpdmUgcGxvdHRpbmcKICAgICAgc2V0QWRhcHRpdmUob2xkQWRhcHRp
dmUpJFBMT1QKICAgICAgLS0gZHJhdwogICAgICBkcmF3UGxvdChwbCxsKQogCiAgICBkcmF3KGY6
U0YgLT4gU0Ysc2VnOlNFRykgPT0gZHJhdyhmLHNlZyxuaWwoKSkKIAotLSUgUGFyYW1ldHJpYyBQ
bGFuZSBDdXJ2ZXMKCiAgICBkcmF3KHBwYzpQUEMsc2VnOlNFRyxsOkwgRFJPUCkgPT0KICAgICAg
LS0gc2V0IGFkYXB0aXZlIHBsb3R0aW5nIG9mZiBvciBvbgogICAgICBvbGRBZGFwdGl2ZSA6PSBh
ZGFwdGl2ZT8oKSRQTE9UCiAgICAgIHNldEFkYXB0aXZlKGFkYXB0aXZlKGwsb2xkQWRhcHRpdmUp
KSRQTE9UCiAgICAgIC0tIGNyZWF0ZSBmdW5jdGlvbiBTRiAtPiBQb2ludCBTRgogICAgICBmIDo9
IGNvb3JkaW5hdGUocHBjLDEpOyBnIDo9IGNvb3JkaW5hdGUocHBjLDIpCiAgICAgIGZjbiA6IEwo
U0YgLT4gUHQpIDo9IFttYWtlUHQyKG15VHJhcDEoZiwjMSksbXlUcmFwMShnLCMxKSldCiAgICAg
IC0tIHByb2Nlc3MgY2hhbmdlIG9mIGNvb3JkaW5hdGVzCiAgICAgIGlmIG5vdCAoYyA6PSBvcHRp
b24obCwiY29vcmRpbmF0ZXMiIDo6IFN5bWJvbCkpIGNhc2UgImZhaWxlZCIgdGhlbgogICAgICAg
IGNjIDogTChQdCAtPiBQdCkgOj0gW3JldHJhY3QoYyA6OiBBbnkpJEFOWTEoUHQgLT4gUHQpXQog
ICAgICAgIGZjbiA6PSBbKGZpcnN0IGNjKSgoZmlyc3QgZmNuKSgjMSkpXQogICAgICAtLSBjcmVh
dGUgUExPVAogICAgICBwbCA6PSBwb2ludFBsb3QoZmlyc3QgZmNuLG5vcm1hbGl6ZSBzZWcpCiAg
ICAgIC0tIHJlc2V0IGFkYXB0aXZlIHBsb3R0aW5nCiAgICAgIHNldEFkYXB0aXZlKG9sZEFkYXB0
aXZlKSRQTE9UCiAgICAgIC0tIGRyYXcKICAgICAgZHJhd1Bsb3QocGwsbCkKIAogICAgZHJhdyhw
cGM6UFBDLHNlZzpTRUcpID09IGRyYXcocHBjLHNlZyxuaWwoKSkKCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQot
LSAgICAgICAgICAgICAgICAgICAgIDNEIC0gQ3VydmVzICAKLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgotLSUg
ZnVuY3Rpb25zIGZvciBjcmVhdGlvbiBvZiBtYXBzIFNGIC0+IFBvaW50IFNGICh0aHJlZSBkaW1l
bnNpb25hbCkKCiAgICBtYWtlUHQ0OiAoU0YsU0YsU0YsU0YpIC0+IFBvaW50IFNGCiAgICBtYWtl
UHQ0KHgseSx6LGMpID09IHBvaW50KGwgOiBMaXN0IFNGIDo9IFt4LHkseixjXSkKCi0tJSBQYXJh
bWV0cmljIFNwYWNlIEN1cnZlcwoKICAgIGlkOiBTRiAtPiBTRgogICAgaWQgeCA9PSB4CgogICAg
ekNvb3JkOiAoU0YsU0YsU0YpIC0+IFNGCiAgICB6Q29vcmQoeCx5LHopID09IHoKCiAgICBjb2xv
clBvaW50czogKExpc3QgTGlzdCBQdCwoU0YsU0YsU0YpIC0+IFNGKSAtPiBMaXN0IExpc3QgUHQK
ICAgIGNvbG9yUG9pbnRzKGxscCxmdW5jKSA9PQogICAgICBmb3IgbHAgaW4gbGxwIHJlcGVhdCBm
b3IgcCBpbiBscCByZXBlYXQKICAgICAgICBwLjQgOj0gZnVuYyhwLjEscC4yLHAuMykKICAgICAg
bGxwCgogICAgbWFrZU9iamVjdChwc2M6UFNDLHNlZzpTRUcsbDpMIERST1ApID09CiAgICAgIHNw
IDo9IHNwYWNlIGwKICAgICAgLS0gb2J0YWluIGRlcGVuZGVudCB2YXJpYWJsZSBhbmQgY29vcmRp
bmF0ZSBmdW5jdGlvbnMKICAgICAgZiA6PSBjb29yZGluYXRlKHBzYywxKTsgZyA6PSBjb29yZGlu
YXRlKHBzYywyKTsgaCA6PSBjb29yZGluYXRlKHBzYywzKQogICAgICAtLSBjcmVhdGUgZnVuY3Rp
b24gU0YgLT4gUG9pbnQgU0Ygd2l0aCBkZWZhdWx0IG9yIHVzZXItc3BlY2lmaWVkCiAgICAgIC0t
IGNvbG9yIGZ1bmN0aW9uCiAgICAgIGZjbiA6IEwoU0YgLT4gUHQpIDo9IFttYWtlUHQ0KG15VHJh
cDEoZiwjMSksbXlUcmFwMShnLCMxKSxteVRyYXAxKGgsIzEpLF8KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIG15VHJhcDEoaWQsIzEpKV0KICAgICAgcG9pbnRzQ29sb3JlZD8gOiBCb29sZWFu
IDo9IGZhbHNlCiAgICAgIGlmIG5vdCAoYzEgOj0gb3B0aW9uKGwsImNvbG9yRnVuY3Rpb24xIiA6
OiBTeW1ib2wpKSBjYXNlICJmYWlsZWQiIHRoZW4KICAgICAgICBwb2ludHNDb2xvcmVkPyA6PSB0
cnVlCiAgICAgICAgZmNuIDo9IFttYWtlUHQ0KG15VHJhcDEoZiwjMSksbXlUcmFwMShnLCMxKSxt
eVRyYXAxKGgsIzEpLF8KICAgICAgICAgICAgICAgIHJldHJhY3QoYzEgOjogQW55KSRBTlkxKFNG
IC0+IFNGKSgjMSkpXQogICAgICAtLSBwcm9jZXNzIGNoYW5nZSBvZiBjb29yZGluYXRlcwogICAg
ICBpZiBub3QgKGMgOj0gb3B0aW9uKGwsImNvb3JkaW5hdGVzIiA6OiBTeW1ib2wpKSBjYXNlICJm
YWlsZWQiIHRoZW4KICAgICAgICBjYyA6IEwoUHQgLT4gUHQpIDo9IFtyZXRyYWN0KGMgOjogQW55
KSRBTlkxKFB0IC0+IFB0KV0KICAgICAgICBmY24gOj0gWyhmaXJzdCBjYykoKGZpcnN0IGZjbiko
IzEpKV0KICAgICAgLS0gY3JlYXRlIFBMT1QKICAgICAgcGwgOj0gcG9pbnRQbG90KGZpcnN0IGZj
bixub3JtYWxpemUgc2VnKSRQbG90M0QKICAgICAgLS0gY3JlYXRlIFRocmVlU3BhY2UKICAgICAg
cyA6PSBzcAogICAgICAtLSBkcmF3IFR1YmUKLS0gICAgICBwcmludChwbDo6T3V0cHV0Rm9ybSkK
ICAgICAgb3B0aW9uPyhsLCJ0dWJlUmFkaXVzIiA6OiBTeW1ib2wpID0+CiAgICAgICAgcHRzIDo9
IHR1YmVQb2ludHMobCw4KQogICAgICAgIHJhZCA6PSBjb252ZXJ0KHR1YmVSYWRpdXMobCwwLjI1
KSlARG91YmxlRmxvYXQKICAgICAgICB0dWIgOj0gdHViZShwbCxyYWQscHRzKSROdW1lcmljVHVi
ZVBsb3QoUGxvdDNEKQogICAgICAgIGxvb3BzIDo9IGxpc3RMb29wcyB0dWIKICAgICAgICAtLSBj
b2xvciBwb2ludHMgaWYgdGhpcyBoYXMgbm90IGJlZW4gZG9uZSBhbHJlYWR5CiAgICAgICAgaWYg
bm90IHBvaW50c0NvbG9yZWQ/IHRoZW4KICAgICAgICAgIGlmIChjMyA6PSBvcHRpb24obCwiY29s
b3JGdW5jdGlvbjMiIDo6IFN5bWJvbCkpIGNhc2UgImZhaWxlZCIKICAgICAgICAgICAgdGhlbiBj
b2xvclBvaW50cyhsb29wcyx6Q29vcmQpICAtLSBkZWZhdWx0IGNvbG9yIGZ1bmN0aW9uCiAgICAg
ICAgICAgIGVsc2UgY29sb3JQb2ludHMobG9vcHMscmV0cmFjdChjMyA6OiBBbnkpJEFOWTEoKFNG
LFNGLFNGKSAtPiBTRikpCiAgICAgICAgbWVzaChzLGxvb3BzLGZhbHNlLGZhbHNlKQogICAgICAg
IHMKICAgICAgLS0gZHJhdyBjdXJ2ZQogICAgICBiciA6PSBsaXN0QnJhbmNoZXMgcGwKICAgICAg
Zm9yIGIgaW4gYnIgcmVwZWF0IGN1cnZlKHMsYikKICAgICAgcwoKICAgIG1ha2VPYmplY3QocHNj
OlBDRlVOLHNlZzpTRUcsbDpMIERST1ApID09CiAgICAgIHNwIDo9IHNwYWNlIGwKICAgICAgLS0g
Y3JlYXRlIGZ1bmN0aW9uIFNGIC0+IFBvaW50IFNGIHdpdGggZGVmYXVsdCBvciB1c2VyLXNwZWNp
ZmllZAogICAgICAtLSBjb2xvciBmdW5jdGlvbgogICAgICBmY24gOiBMKFNGIC0+IFB0KSA6PSBb
cHNjXQogICAgICBwb2ludHNDb2xvcmVkPyA6IEJvb2xlYW4gOj0gZmFsc2UKICAgICAgaWYgbm90
IChjMSA6PSBvcHRpb24obCwiY29sb3JGdW5jdGlvbjEiIDo6IFN5bWJvbCkpIGNhc2UgImZhaWxl
ZCIgdGhlbgogICAgICAgIHBvaW50c0NvbG9yZWQ/IDo9IHRydWUKICAgICAgICBmY24gOj0gW2Nv
bmNhdChwc2MoIzEpLCByZXRyYWN0KGMxIDo6IEFueSkkQU5ZMShTRiAtPiBTRikoIzEpKV0KICAg
ICAgLS0gcHJvY2VzcyBjaGFuZ2Ugb2YgY29vcmRpbmF0ZXMKICAgICAgaWYgbm90IChjIDo9IG9w
dGlvbihsLCJjb29yZGluYXRlcyIgOjogU3ltYm9sKSkgY2FzZSAiZmFpbGVkIiB0aGVuCiAgICAg
ICAgY2MgOiBMKFB0IC0+IFB0KSA6PSBbcmV0cmFjdChjIDo6IEFueSkkQU5ZMShQdCAtPiBQdCld
CiAgICAgICAgZmNuIDo9IFsoZmlyc3QgY2MpKChmaXJzdCBmY24pKCMxKSldCiAgICAgIC0tIGNy
ZWF0ZSBQTE9UCiAgICAgIHBsIDo9IHBvaW50UGxvdChmaXJzdCBmY24sbm9ybWFsaXplIHNlZykk
UGxvdDNECiAgICAgIC0tIGNyZWF0ZSBUaHJlZVNwYWNlCiAgICAgIHMgOj0gc3AKICAgICAgLS0g
ZHJhdyBUdWJlCiAgICAgIG9wdGlvbj8obCwidHViZVJhZGl1cyIgOjogU3ltYm9sKSA9PgogICAg
ICAgIHB0cyA6PSB0dWJlUG9pbnRzKGwsOCkKICAgICAgICByYWQgOj0gY29udmVydCh0dWJlUmFk
aXVzKGwsMC4yNSkpQERvdWJsZUZsb2F0CiAgICAgICAgdHViIDo9IHR1YmUocGwscmFkLHB0cykk
TnVtZXJpY1R1YmVQbG90KFBsb3QzRCkKICAgICAgICBsb29wcyA6PSBsaXN0TG9vcHMgdHViCiAg
ICAgICAgLS0gY29sb3IgcG9pbnRzIGlmIHRoaXMgaGFzIG5vdCBiZWVuIGRvbmUgYWxyZWFkeQog
ICAgICAgIG1lc2gocyxsb29wcyxmYWxzZSxmYWxzZSkKICAgICAgICBzCiAgICAgIC0tIGRyYXcg
Y3VydmUKICAgICAgYnIgOj0gbGlzdEJyYW5jaGVzIHBsCiAgICAgIGZvciBiIGluIGJyIHJlcGVh
dCBjdXJ2ZShzLGIpCiAgICAgIHMKCiAgICBtYWtlT2JqZWN0KHBzYzpQU0Msc2VnOlNFRykgPT0K
ICAgICAgbWFrZU9iamVjdChwc2Msc2VnLG5pbCgpKQoKICAgIG1ha2VPYmplY3QocHNjOlBDRlVO
LHNlZzpTRUcpID09CiAgICAgIG1ha2VPYmplY3QocHNjLHNlZyxuaWwoKSkKCiAgICBkcmF3KHBz
YzpQU0Msc2VnOlNFRyxsOkwgRFJPUCkgPT0KICAgICAgc3AgOj0gbWFrZU9iamVjdChwc2Msc2Vn
LGwpCiAgICAgIG1ha2VWaWV3cG9ydDNEKHNwLCBsKQoKICAgIGRyYXcocHNjOlBTQyxzZWc6U0VH
KSA9PQogICAgICBkcmF3KHBzYyxzZWcsbmlsKCkpCgogICAgZHJhdyhwc2M6UENGVU4sc2VnOlNF
RyxsOkwgRFJPUCkgPT0KICAgICAgc3AgOj0gbWFrZU9iamVjdChwc2Msc2VnLGwpCiAgICAgIG1h
a2VWaWV3cG9ydDNEKHNwLCBsKQoKICAgIGRyYXcocHNjOlBDRlVOLHNlZzpTRUcpID09CiAgICAg
IGRyYXcocHNjLHNlZyxuaWwoKSkKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotLSAgICAgICAgICAgICAgICAg
ICAgIDNEIC0gU3VyZmFjZXMgIAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCiAgICBteVRyYXAyOiAoKFNGLCBT
RikgLT4gU0YsIFNGLCBTRikgLT4gU0YKICAgIG15VHJhcDIoZmY6KFNGLCBTRikgLT4gU0YsIHU6
U0YsIHY6U0YpOlNGID09CiAgICAgIHMgOj0gdHJhcE51bWVyaWNFcnJvcnMoZmYodSwgdikpJExp
c3AgOjogVW5pb24oU0YsICJmYWlsZWQiKQogICAgICBzIGNhc2UgImZhaWxlZCIgPT4gIF8kTmFO
dmFsdWUkTGlzcAogICAgICByOlNGIDo9IHM6OlNGCiAgICAgIHIgPm1heCgpJFNGIG9yIHIgPCBt
aW4oKSRTRiA9PiBfJE5hTnZhbHVlJExpc3AKICAgICAgcgoKICAgIHJlY29sb3IocHRGdW5jLGNv
bEZ1bmMpID09CiAgICAgIHB0IDo9IHB0RnVuYygjMSwjMikKICAgICAgcHQuNCA6PSBjb2xGdW5j
KHB0LjEscHQuMixwdC4zKQogICAgICBwdAoKICAgIHhDb29yZDogKFNGLFNGKSAtPiBTRgogICAg
eENvb3JkKHgseSkgPT0geAoKLS0lIFRocmVlIERpbWVuc2lvbmFsIEZ1bmN0aW9uIFBsb3RzCgog
ICAgbWFrZU9iamVjdChmOihTRixTRikgLT4gU0YseFNlZzpTRUcseVNlZzpTRUcsbDpMIERST1Ap
ID09CiAgICAgIHNwIDo9IHNwYWNlIGwKICAgICAgLS0gcHJvY2VzcyBjb2xvciBmdW5jdGlvbiBv
ZiB0d28gdmFyaWFibGVzCiAgICAgIGNvbDIgOiBMKChTRixTRikgLT4gU0YpIDo9IFt4Q29vcmRd
ICAgICAtLSBkdW1teSBjb2xvciBmdW5jdGlvbgogICAgICBwb2ludHNDb2xvcmVkPyA6IEJvb2xl
YW4gOj0gZmFsc2UKICAgICAgaWYgbm90IChjMiA6PSBvcHRpb24obCwiY29sb3JGdW5jdGlvbjIi
IDo6IFN5bWJvbCkpIGNhc2UgImZhaWxlZCIgdGhlbgogICAgICAgIHBvaW50c0NvbG9yZWQ/IDo9
IHRydWUKICAgICAgICBjb2wyIDo9IFtyZXRyYWN0KGMyIDo6IEFueSkkQU5ZMSgoU0YsU0YpIC0+
IFNGKV0KICAgICAgZmNuIDogTCgoU0YsU0YpIC0+IFB0KSA6PQogICAgICAgIFttYWtlUHQ0KG15
VHJhcDIoZiwjMSwjMiksIzEsIzIsKGZpcnN0IGNvbDIpKCMxLCMyKSldCiAgICAgIC0tIHByb2Nl
c3MgY2hhbmdlIG9mIGNvb3JkaW5hdGVzCiAgICAgIGlmIChjIDo9IG9wdGlvbihsLCJjb29yZGlu
YXRlcyIgOjogU3ltYm9sKSkgY2FzZSAiZmFpbGVkIiB0aGVuCiAgICAgICAgLS0gZGVmYXVsdCBj
b29yZGluYXRlIHRyYW5zZm9ybWF0aW9uCiAgICAgICAgZmNuIDo9IFttYWtlUHQ0KCMxLCMyLG15
VHJhcDIoZiwjMSwjMiksKGZpcnN0IGNvbDIpKCMxLCMyKSldCiAgICAgIGVsc2UKICAgICAgICBj
YyA6IEwoUHQgLT4gUHQpIDo9IFtyZXRyYWN0KGMgOjogQW55KSRBTlkxKFB0IC0+IFB0KV0KICAg
ICAgICBmY24gOj0gWyhmaXJzdCBjYykoKGZpcnN0IGZjbikoIzEsIzIpKV0KICAgICAgLS0gcHJv
Y2VzcyBjb2xvciBmdW5jdGlvbiBvZiB0aHJlZSB2YXJpYWJsZXMsIGlmIHRoZXJlIHdhcyBubwog
ICAgICAtLSBjb2xvciBmdW5jdGlvbiBvZiB0d28gdmFyaWFibGVzCiAgICAgIGlmIG5vdCBwb2lu
dHNDb2xvcmVkPyB0aGVuCiAgICAgICAgYyA6PSBvcHRpb24obCwiY29sb3JGdW5jdGlvbjMiIDo6
IFN5bWJvbCkKICAgICAgICBmY24gOj0gCiAgICAgICAgICBjIGNhc2UgImZhaWxlZCIgPT4gW3Jl
Y29sb3IoKGZpcnN0IGZjbiksekNvb3JkKV0KICAgICAgICAgIFtyZWNvbG9yKChmaXJzdCBmY24p
LHJldHJhY3QoYyA6OiBBbnkpJEFOWTEoKFNGLFNGLFNGKSAtPiBTRikpXQogICAgICAtLSBjcmVh
dGUgbWVzaAogICAgICBtZXNoIDo9IG1lc2hQYXIyVmFyKHNwLGZpcnN0IGZjbixub3JtYWxpemUg
eFNlZyxub3JtYWxpemUgeVNlZyxsKQogICAgICBtZXNoCgogICAgbWFrZU9iamVjdChmOihTRixT
RikgLT4gU0YseFNlZzpTRUcseVNlZzpTRUcpID09CiAgICAgIG1ha2VPYmplY3QoZix4U2VnLHlT
ZWcsbmlsKCkpCgogICAgZHJhdyhmOihTRixTRikgLT4gU0YseFNlZzpTRUcseVNlZzpTRUcsbDpM
IERST1ApID09CiAgICAgIHNwIDo9IG1ha2VPYmplY3QoZiwgeFNlZywgeVNlZywgbCkKICAgICAg
bWFrZVZpZXdwb3J0M0Qoc3AsIGwpCgogICAgZHJhdyhmOihTRixTRikgLT4gU0YseFNlZzpTRUcs
eVNlZzpTRUcpID09CiAgICAgIGRyYXcoZix4U2VnLHlTZWcsbmlsKCkpCgotLSUgcGFyYW1ldHJp
YyBzdXJmYWNlCgogICAgbWFrZU9iamVjdChzOlBTRix1U2VnOlNFRyx2U2VnOlNFRyxsOkwgRFJP
UCkgPT0KICAgICAgc3AgOj0gc3BhY2UgbAogICAgICAtLSBjcmVhdGUgZnVuY3Rpb25zIGZyb20g
ZXhwcmVzc2lvbnMKICAgICAgZiA6IEwoKFNGLFNGKSAtPiBTRikgOj0gW2Nvb3JkaW5hdGUocywx
KV0KICAgICAgZyA6IEwoKFNGLFNGKSAtPiBTRikgOj0gW2Nvb3JkaW5hdGUocywyKV0KICAgICAg
aCA6IEwoKFNGLFNGKSAtPiBTRikgOj0gW2Nvb3JkaW5hdGUocywzKV0KICAgICAgLS0gcHJvY2Vz
cyBjb2xvciBmdW5jdGlvbiBvZiB0d28gdmFyaWFibGVzCiAgICAgIGNvbDIgOiBMKChTRixTRikg
LT4gU0YpIDo9IFt4Q29vcmRdICAgICAtLSBkdW1teSBjb2xvciBmdW5jdGlvbgogICAgICBwb2lu
dHNDb2xvcmVkPyA6IEJvb2xlYW4gOj0gZmFsc2UKICAgICAgaWYgbm90IChjMiA6PSBvcHRpb24o
bCwiY29sb3JGdW5jdGlvbjIiIDo6IFN5bWJvbCkpIGNhc2UgImZhaWxlZCIgdGhlbgogICAgICAg
IHBvaW50c0NvbG9yZWQ/IDo9IHRydWUKICAgICAgICBjb2wyIDo9IFtyZXRyYWN0KGMyIDo6IEFu
eSkkQU5ZMSgoU0YsU0YpIC0+IFNGKV0KICAgICAgZmNuIDogTCgoU0YsU0YpIC0+IFB0KSA6PSAK
ICAgICAgICBbbWFrZVB0NChteVRyYXAyKChmaXJzdCBmKSwjMSwjMiksbXlUcmFwMigoZmlyc3Qg
ZyksIzEsIzIpLG15VHJhcDIoKGZpcnN0IGgpLCMxLCMyKSxfCiAgICAgICAgICAgICAgICAgbXlU
cmFwMigoZmlyc3QgY29sMiksIzEsIzIpKV0KICAgICAgLS0gcHJvY2VzcyBjaGFuZ2Ugb2YgY29v
cmRpbmF0ZXMKICAgICAgaWYgbm90IChjIDo9IG9wdGlvbihsLCJjb29yZGluYXRlcyIgOjogU3lt
Ym9sKSkgY2FzZSAiZmFpbGVkIiB0aGVuCiAgICAgICAgY2MgOiBMKFB0IC0+IFB0KSA6PSBbcmV0
cmFjdChjIDo6IEFueSkkQU5ZMShQdCAtPiBQdCldCiAgICAgICAgZmNuIDo9IFsoZmlyc3QgY2Mp
KChmaXJzdCBmY24pKCMxLCMyKSldCiAgICAgIC0tIHByb2Nlc3MgY29sb3IgZnVuY3Rpb24gb2Yg
dGhyZWUgdmFyaWFibGVzLCBpZiB0aGVyZSB3YXMgbm8KICAgICAgLS0gY29sb3IgZnVuY3Rpb24g
b2YgdHdvIHZhcmlhYmxlcwogICAgICBpZiBub3QgcG9pbnRzQ29sb3JlZD8gdGhlbgogICAgICAg
IGNvbDMgOiBMKChTRixTRixTRikgLT4gU0YpIDo9IFt6Q29vcmRdICAtLSBkZWZhdWx0IGNvbG9y
IGZ1bmN0aW9uCiAgICAgICAgaWYgbm90IChjIDo9IG9wdGlvbihsLCJjb2xvckZ1bmN0aW9uMyIg
OjogU3ltYm9sKSkgY2FzZSAiZmFpbGVkIiB0aGVuIAogICAgICAgICAgY29sMyA6PSBbcmV0cmFj
dChjIDo6IEFueSkkQU5ZMSgoU0YsU0YsU0YpIC0+IFNGKV0KICAgICAgICBmY24gOj0gW3JlY29s
b3IoKGZpcnN0IGZjbiksKGZpcnN0IGNvbDMpKV0KICAgICAgLS0gY3JlYXRlIG1lc2gKICAgICAg
bWVzaCA6PSBtZXNoUGFyMlZhcihzcCxmaXJzdCBmY24sbm9ybWFsaXplIHVTZWcsbm9ybWFsaXpl
IHZTZWcsbCkKICAgICAgbWVzaAoKICAgIG1ha2VPYmplY3QoczpQU0ZVTix1U2VnOlNFRyx2U2Vn
OlNFRyxsOkwgRFJPUCkgPT0KICAgICAgc3AgOj0gc3BhY2UgbAogICAgICAtLSBwcm9jZXNzIGNv
bG9yIGZ1bmN0aW9uIG9mIHR3byB2YXJpYWJsZXMKICAgICAgY29sMiA6IEwoKFNGLFNGKSAtPiBT
RikgOj0gW3hDb29yZF0gICAgIC0tIGR1bW15IGNvbG9yIGZ1bmN0aW9uCiAgICAgIHBvaW50c0Nv
bG9yZWQ/IDogQm9vbGVhbiA6PSBmYWxzZQogICAgICBpZiBub3QgKGMyIDo9IG9wdGlvbihsLCJj
b2xvckZ1bmN0aW9uMiIgOjogU3ltYm9sKSkgY2FzZSAiZmFpbGVkIiB0aGVuCiAgICAgICAgcG9p
bnRzQ29sb3JlZD8gOj0gdHJ1ZQogICAgICAgIGNvbDIgOj0gW3JldHJhY3QoYzIgOjogQW55KSRB
TlkxKChTRixTRikgLT4gU0YpXQogICAgICBmY24gOiBMKChTRixTRikgLT4gUHQpIDo9IAogICAg
ICAgIHBvaW50c0NvbG9yZWQ/ID0+IFtjb25jYXQocygjMSwgIzIpLCAoZmlyc3QgY29sMikoIzEs
ICMyKSldCiAgICAgICAgW3NdCiAgICAgIC0tIHByb2Nlc3MgY2hhbmdlIG9mIGNvb3JkaW5hdGVz
CiAgICAgIGlmIG5vdCAoYyA6PSBvcHRpb24obCwiY29vcmRpbmF0ZXMiIDo6IFN5bWJvbCkpIGNh
c2UgImZhaWxlZCIgdGhlbgogICAgICAgIGNjIDogTChQdCAtPiBQdCkgOj0gW3JldHJhY3QoYyA6
OiBBbnkpJEFOWTEoUHQgLT4gUHQpXQogICAgICAgIGZjbiA6PSBbKGZpcnN0IGNjKSgoZmlyc3Qg
ZmNuKSgjMSwjMikpXQogICAgICAtLSBjcmVhdGUgbWVzaAogICAgICBtZXNoIDo9IG1lc2hQYXIy
VmFyKHNwLGZpcnN0IGZjbixub3JtYWxpemUgdVNlZyxub3JtYWxpemUgdlNlZyxsKQogICAgICBt
ZXNoCgogICAgbWFrZU9iamVjdChzOlBTRix1U2VnOlNFRyx2U2VnOlNFRykgPT0KICAgICAgbWFr
ZU9iamVjdChzLHVTZWcsdlNlZyxuaWwoKSkKCiAgICBkcmF3KHM6UFNGLHVTZWc6U0VHLHZTZWc6
U0VHLGw6TCBEUk9QKSA9PQogICAgICAtLSBkcmF3CiAgICAgIG1lc2ggOj0gbWFrZU9iamVjdChz
LHVTZWcsdlNlZyxsKQogICAgICBtYWtlVmlld3BvcnQzRChtZXNoLGwpCgogICAgZHJhdyhzOlBT
Rix1U2VnOlNFRyx2U2VnOlNFRykgPT0KICAgICAgZHJhdyhzLHVTZWcsdlNlZyxuaWwoKSkKIAog
ICAgbWFrZU9iamVjdChzOlBTRlVOLHVTZWc6U0VHLHZTZWc6U0VHKSA9PQogICAgICBtYWtlT2Jq
ZWN0KHMsdVNlZyx2U2VnLG5pbCgpKQoKICAgIGRyYXcoczpQU0ZVTix1U2VnOlNFRyx2U2VnOlNF
RyxsOkwgRFJPUCkgPT0KICAgICAgLS0gZHJhdwogICAgICBtZXNoIDo9IG1ha2VPYmplY3Qocyx1
U2VnLHZTZWcsbCkKICAgICAgbWFrZVZpZXdwb3J0M0QobWVzaCxsKQoKICAgIGRyYXcoczpQU0ZV
Tix1U2VnOlNFRyx2U2VnOlNFRykgPT0KICAgICAgZHJhdyhzLHVTZWcsdlNlZyxuaWwoKSkKIApA
ClxzZWN0aW9ue3BhY2thZ2UgRFJBVyBUb3BMZXZlbERyYXdGdW5jdGlvbnN9Cjw8cGFja2FnZSBE
UkFXIFRvcExldmVsRHJhd0Z1bmN0aW9ucz4+PQopYWJicmV2IHBhY2thZ2UgRFJBVyBUb3BMZXZl
bERyYXdGdW5jdGlvbnMKKysgQXV0aG9yOiBDbGlmdG9uIEouIFdpbGxpYW1zb24KKysgRGF0ZSBD
cmVhdGVkOiAyMyBKYW51YXJ5IDE5OTAKKysgRGF0ZSBMYXN0IFVwZGF0ZWQ6IE9jdG9iZXIgMTk5
MSBieSBKb24gU3RlaW5iYWNoCisrIEJhc2ljIE9wZXJhdGlvbnM6IGRyYXcKKysgUmVsYXRlZCBD
b25zdHJ1Y3RvcnM6CisrIEFsc28gU2VlOgorKyBBTVMgQ2xhc3NpZmljYXRpb25zOgorKyBLZXl3
b3JkczoKKysgUmVmZXJlbmNlczoKKysgRGVzY3JpcHRpb246IFRvcExldmVsRHJhd0Z1bmN0aW9u
cyBwcm92aWRlcyB0b3AgbGV2ZWwgZnVuY3Rpb25zIGZvciAKKysgZHJhd2luZyBncmFwaGljcyBv
ZiBleHByZXNzaW9ucy4KVG9wTGV2ZWxEcmF3RnVuY3Rpb25zKEV4OkpvaW4oQ29udmVydGlibGVU
byBJbnB1dEZvcm0sU2V0Q2F0ZWdvcnkpKToKIEV4cG9ydHMgPT0gSW1wbGVtZW50YXRpb24gd2hl
cmUKICBCICAgID09PiBCb29sZWFuCiAgQklORCA9PT4gU2VnbWVudEJpbmRpbmcgRmxvYXQKICBM
ICAgID09PiBMaXN0CiAgU0YgICA9PT4gRG91YmxlRmxvYXQKICBEUk9QID09PiBEcmF3T3B0aW9u
CgogIFBQQyAgPT0+IFBhcmFtZXRyaWNQbGFuZUN1cnZlIEV4CiAgUFBDRiA9PT4gUGFyYW1ldHJp
Y1BsYW5lQ3VydmUoU0YgLT4gU0YpCiAgUFNDICA9PT4gUGFyYW1ldHJpY1NwYWNlQ3VydmUgRXgK
ICBQU0NGID09PiBQYXJhbWV0cmljU3BhY2VDdXJ2ZShTRiAtPiBTRikKICBQU0YgID09PiBQYXJh
bWV0cmljU3VyZmFjZSBFeAogIFBTRkYgPT0+IFBhcmFtZXRyaWNTdXJmYWNlKChTRixTRikgLT4g
U0YpCiAgU1BBQ0UzID09PiBUaHJlZVNwYWNlKFNGKQogIFZJRVcyID09PiBUd29EaW1lbnNpb25h
bFZpZXdwb3J0CiAgVklFVzMgPT0+IFRocmVlRGltZW5zaW9uYWxWaWV3cG9ydAoKICBFeHBvcnRz
ID09PiB3aXRoCgotLSUgVHdvIERpbWVuc2lvbmFsIEZ1bmN0aW9uIFBsb3RzCgogICAgZHJhdzog
KEV4LEJJTkQsTCBEUk9QKSAtPiBWSUVXMgogICAgICArKyBkcmF3KGYoeCkseCA9IGEuLmIsbCkg
ZHJhd3MgdGhlIGdyYXBoIG9mIFxzcGFke3kgPSBmKHgpfSBhcyB4CiAgICAgICsrIHJhbmdlcyBm
cm9tIFxzcGFke21pbihhLGIpfSB0byBcc3BhZHttYXgoYSxiKX07IFxzcGFke2YoeCl9IGlzIHRo
ZSAKICAgICAgKysgZGVmYXVsdCB0aXRsZSwgYW5kIHRoZSBvcHRpb25zIGNvbnRhaW5lZCBpbiB0
aGUgbGlzdCBsIG9mCiAgICAgICsrIHRoZSBkb21haW4gXHNwYWR7RHJhd09wdGlvbn0gYXJlIGFw
cGxpZWQuCiAgICBkcmF3OiAoRXgsQklORCkgLT4gVklFVzIKICAgICAgKysgZHJhdyhmKHgpLHgg
PSBhLi5iKSBkcmF3cyB0aGUgZ3JhcGggb2YgXHNwYWR7eSA9IGYoeCl9IGFzIHgKICAgICAgKysg
cmFuZ2VzIGZyb20gXHNwYWR7bWluKGEsYil9IHRvIFxzcGFke21heChhLGIpfTsgXHNwYWR7Zih4
KX0gYXBwZWFycyAKICAgICAgKysgaW4gdGhlIHRpdGxlIGJhci4KCi0tJSBQYXJhbWV0cmljIFBs
YW5lIEN1cnZlcwoKICAgIGRyYXc6IChQUEMsQklORCxMIERST1ApIC0+IFZJRVcyCiAgICAgICsr
IGRyYXcoY3VydmUoZih0KSxnKHQpKSx0ID0gYS4uYixsKSBkcmF3cyB0aGUgZ3JhcGggb2YgdGhl
IHBhcmFtZXRyaWMKICAgICAgKysgY3VydmUgXHNwYWR7eCA9IGYodCksIHkgPSBnKHQpfSBhcyB0
IHJhbmdlcyBmcm9tIFxzcGFke21pbihhLGIpfSB0byAKICAgICAgKysgXHNwYWR7bWF4KGEsYil9
OyBcc3BhZHsoZih0KSxnKHQpKX0gaXMgdGhlIGRlZmF1bHQgdGl0bGUsIGFuZCB0aGUKICAgICAg
Kysgb3B0aW9ucyBjb250YWluZWQgaW4gdGhlIGxpc3QgbCBvZiB0aGUgZG9tYWluIFxzcGFke0Ry
YXdPcHRpb259CiAgICAgICsrIGFyZSBhcHBsaWVkLgogICAgZHJhdzogKFBQQyxCSU5EKSAtPiBW
SUVXMgogICAgICArKyBkcmF3KGN1cnZlKGYodCksZyh0KSksdCA9IGEuLmIpIGRyYXdzIHRoZSBn
cmFwaCBvZiB0aGUgcGFyYW1ldHJpYwogICAgICArKyBjdXJ2ZSBcc3BhZHt4ID0gZih0KSwgeSA9
IGcodCl9IGFzIHQgcmFuZ2VzIGZyb20gXHNwYWR7bWluKGEsYil9IHRvIAogICAgICArKyBcc3Bh
ZHttYXgoYSxiKX07IFxzcGFkeyhmKHQpLGcodCkpfSBhcHBlYXJzIGluIHRoZSB0aXRsZSBiYXIu
CgotLSUgUGFyYW1ldHJpYyBTcGFjZSBDdXJ2ZXMKCiAgICBkcmF3OiAoUFNDLEJJTkQsTCBEUk9Q
KSAtPiBWSUVXMwogICAgICArKyBkcmF3KGN1cnZlKGYodCksZyh0KSxoKHQpKSx0ID0gYS4uYixs
KSBkcmF3cyB0aGUgZ3JhcGggb2YgdGhlCiAgICAgICsrIHBhcmFtZXRyaWMgY3VydmUgXHNwYWR7
eCA9IGYodCl9LCBcc3BhZHt5ID0gZyh0KX0sIFxzcGFke3ogPSBoKHQpfQogICAgICArKyBhcyB0
IHJhbmdlcyBmcm9tIFxzcGFke21pbihhLGIpfSB0byBcc3BhZHttYXgoYSxiKX07IFxzcGFke2go
dCl9CiAgICAgICsrIGlzIHRoZSBkZWZhdWx0IHRpdGxlLCBhbmQgdGhlIG9wdGlvbnMgY29udGFp
bmVkIGluIHRoZSBsaXN0IGwgb2YKICAgICAgKysgdGhlIGRvbWFpbiBcc3BhZHtEcmF3T3B0aW9u
fSBhcmUgYXBwbGllZC4KICAgIGRyYXc6IChQU0MsQklORCkgLT4gVklFVzMKICAgICAgKysgZHJh
dyhjdXJ2ZShmKHQpLGcodCksaCh0KSksdCA9IGEuLmIpIGRyYXdzIHRoZSBncmFwaCBvZiB0aGUg
cGFyYW1ldHJpYwogICAgICArKyBjdXJ2ZSBcc3BhZHt4ID0gZih0KX0sIFxzcGFke3kgPSBnKHQp
fSwgXHNwYWR7eiA9IGgodCl9IGFzIHQgcmFuZ2VzCiAgICAgICsrIGZyb20gXHNwYWR7bWluKGEs
Yil9IHRvIFxzcGFke21heChhLGIpfTsgXHNwYWR7aCh0KX0gaXMgdGhlIGRlZmF1bHQKICAgICAg
KysgdGl0bGUuCiAgICBtYWtlT2JqZWN0OiAoUFNDLEJJTkQsTCBEUk9QKSAtPiBTUEFDRTMKICAg
ICAgKysgbWFrZU9iamVjdChjdXJ2ZShmKHQpLGcodCksaCh0KSksdCA9IGEuLmIsbCkgcmV0dXJu
cyBhIHNwYWNlIG9mCiAgICAgICsrIHRoZSBkb21haW4gXHNwYWR0eXBle1RocmVlU3BhY2V9IHdo
aWNoIGNvbnRhaW5zIHRoZSBncmFwaCBvZiB0aGUKICAgICAgKysgcGFyYW1ldHJpYyBjdXJ2ZSBc
c3BhZHt4ID0gZih0KX0sIFxzcGFke3kgPSBnKHQpfSwgXHNwYWR7eiA9IGgodCl9CiAgICAgICsr
IGFzIHQgcmFuZ2VzIGZyb20gXHNwYWR7bWluKGEsYil9IHRvIFxzcGFke21heChhLGIpfTsgXHNw
YWR7aCh0KX0KICAgICAgKysgaXMgdGhlIGRlZmF1bHQgdGl0bGUsIGFuZCB0aGUgb3B0aW9ucyBj
b250YWluZWQgaW4gdGhlIGxpc3QgbCBvZgogICAgICArKyB0aGUgZG9tYWluIFxzcGFke0RyYXdP
cHRpb259IGFyZSBhcHBsaWVkLgogICAgbWFrZU9iamVjdDogKFBTQyxCSU5EKSAtPiBTUEFDRTMK
ICAgICAgKysgbWFrZU9iamVjdChjdXJ2ZShmKHQpLGcodCksaCh0KSksdCA9IGEuLmIpIHJldHVy
bnMgYSBzcGFjZSBvZiB0aGUKICAgICAgKysgZG9tYWluIFxzcGFkdHlwZXtUaHJlZVNwYWNlfSB3
aGljaCBjb250YWlucyB0aGUgZ3JhcGggb2YgdGhlCiAgICAgICsrIHBhcmFtZXRyaWMgY3VydmUg
XHNwYWR7eCA9IGYodCl9LCBcc3BhZHt5ID0gZyh0KX0sIFxzcGFke3ogPSBoKHQpfQogICAgICAr
KyBhcyB0IHJhbmdlcyBmcm9tIFxzcGFke21pbihhLGIpfSB0byBcc3BhZHttYXgoYSxiKX07IFxz
cGFke2godCl9IGlzCiAgICAgICsrIHRoZSBkZWZhdWx0IHRpdGxlLgoKLS0lIFRocmVlIERpbWVu
c2lvbmFsIEZ1bmN0aW9uIFBsb3RzCgogICAgZHJhdzogKEV4LEJJTkQsQklORCxMIERST1ApIC0+
IFZJRVczCiAgICAgICsrIGRyYXcoZih4LHkpLHggPSBhLi5iLHkgPSBjLi5kLGwpIGRyYXdzIHRo
ZSBncmFwaCBvZiBcc3BhZHt6ID0gZih4LHkpfQogICAgICArKyBhcyB4IHJhbmdlcyBmcm9tIFxz
cGFke21pbihhLGIpfSB0byBcc3BhZHttYXgoYSxiKX0gYW5kIHkgcmFuZ2VzIGZyb20KICAgICAg
KysgXHNwYWR7bWluKGMsZCl9IHRvIFxzcGFke21heChjLGQpfTsgXHNwYWR7Zih4LHkpfSBpcyB0
aGUgZGVmYXVsdAogICAgICArKyB0aXRsZSwgYW5kIHRoZSBvcHRpb25zIGNvbnRhaW5lZCBpbiB0
aGUgbGlzdCBsIG9mIHRoZSBkb21haW4KICAgICAgKysgXHNwYWR7RHJhd09wdGlvbn0gYXJlIGFw
cGxpZWQuCiAgICBkcmF3OiAoRXgsQklORCxCSU5EKSAtPiBWSUVXMwogICAgICArKyBkcmF3KGYo
eCx5KSx4ID0gYS4uYix5ID0gYy4uZCkgZHJhd3MgdGhlIGdyYXBoIG9mIFxzcGFke3ogPSBmKHgs
eSl9CiAgICAgICsrIGFzIHggcmFuZ2VzIGZyb20gXHNwYWR7bWluKGEsYil9IHRvIFxzcGFke21h
eChhLGIpfSBhbmQgeSByYW5nZXMgZnJvbQogICAgICArKyBcc3BhZHttaW4oYyxkKX0gdG8gXHNw
YWR7bWF4KGMsZCl9OyBcc3BhZHtmKHgseSl9IGFwcGVhcnMgaW4gdGhlIHRpdGxlIGJhci4KICAg
IG1ha2VPYmplY3Q6IChFeCxCSU5ELEJJTkQsTCBEUk9QKSAtPiBTUEFDRTMKICAgICAgKysgbWFr
ZU9iamVjdChmKHgseSkseCA9IGEuLmIseSA9IGMuLmQsbCkgcmV0dXJucyBhIHNwYWNlIG9mIHRo
ZQogICAgICArKyBkb21haW4gXHNwYWR0eXBle1RocmVlU3BhY2V9IHdoaWNoIGNvbnRhaW5zIHRo
ZSBncmFwaCBvZgogICAgICArKyBcc3BhZHt6ID0gZih4LHkpfSBhcyB4IHJhbmdlcyBmcm9tIFxz
cGFke21pbihhLGIpfSB0byBcc3BhZHttYXgoYSxiKX0KICAgICAgKysgYW5kIHkgcmFuZ2VzIGZy
b20gXHNwYWR7bWluKGMsZCl9IHRvIFxzcGFke21heChjLGQpfTsgXHNwYWR7Zih4LHkpfQogICAg
ICArKyBpcyB0aGUgZGVmYXVsdCB0aXRsZSwgYW5kIHRoZSBvcHRpb25zIGNvbnRhaW5lZCBpbiB0
aGUgbGlzdCBsIG9mIHRoZQogICAgICArKyBkb21haW4gXHNwYWR7RHJhd09wdGlvbn0gYXJlIGFw
cGxpZWQuCiAgICBtYWtlT2JqZWN0OiAoRXgsQklORCxCSU5EKSAtPiBTUEFDRTMKICAgICAgKysg
bWFrZU9iamVjdChmKHgseSkseCA9IGEuLmIseSA9IGMuLmQpIHJldHVybnMgYSBzcGFjZSBvZiB0
aGUgZG9tYWluCiAgICAgICsrIFxzcGFkdHlwZXtUaHJlZVNwYWNlfSB3aGljaCBjb250YWlucyB0
aGUgZ3JhcGggb2YgXHNwYWR7eiA9IGYoeCx5KX0KICAgICAgKysgYXMgeCByYW5nZXMgZnJvbSBc
c3BhZHttaW4oYSxiKX0gdG8gXHNwYWR7bWF4KGEsYil9IGFuZCB5IHJhbmdlcyBmcm9tCiAgICAg
ICsrIFxzcGFke21pbihjLGQpfSB0byBcc3BhZHttYXgoYyxkKX07IFxzcGFke2YoeCx5KX0gYXBw
ZWFycyBhcyB0aGUKICAgICAgKysgZGVmYXVsdCB0aXRsZS4KCi0tJSBQYXJhbWV0cmljIFN1cmZh
Y2VzCgogICAgZHJhdzogKFBTRixCSU5ELEJJTkQsTCBEUk9QKSAtPiBWSUVXMwogICAgICArKyBk
cmF3KHN1cmZhY2UoZih1LHYpLGcodSx2KSxoKHUsdikpLHUgPSBhLi5iLHYgPSBjLi5kLGwpIGRy
YXdzIHRoZQogICAgICArKyBncmFwaCBvZiB0aGUgcGFyYW1ldHJpYyBzdXJmYWNlIFxzcGFke3gg
PSBmKHUsdil9LCBcc3BhZHt5ID0gZyh1LHYpfSwKICAgICAgKysgXHNwYWR7eiA9IGgodSx2KX0g
YXMgdSByYW5nZXMgZnJvbSBcc3BhZHttaW4oYSxiKX0gdG8gXHNwYWR7bWF4KGEsYil9CiAgICAg
ICsrIGFuZCB2IHJhbmdlcyBmcm9tIFxzcGFke21pbihjLGQpfSB0byBcc3BhZHttYXgoYyxkKX07
IFxzcGFke2godCl9CiAgICAgICsrIGlzIHRoZSBkZWZhdWx0IHRpdGxlLCBhbmQgdGhlIG9wdGlv
bnMgY29udGFpbmVkIGluIHRoZSBsaXN0IGwgb2YKICAgICAgKysgdGhlIGRvbWFpbiBcc3BhZHtE
cmF3T3B0aW9ufSBhcmUgYXBwbGllZC4KICAgIGRyYXc6IChQU0YsQklORCxCSU5EKSAtPiBWSUVX
MwogICAgICArKyBkcmF3KHN1cmZhY2UoZih1LHYpLGcodSx2KSxoKHUsdikpLHUgPSBhLi5iLHYg
PSBjLi5kKSBkcmF3cyB0aGUKICAgICAgKysgZ3JhcGggb2YgdGhlIHBhcmFtZXRyaWMgc3VyZmFj
ZSBcc3BhZHt4ID0gZih1LHYpfSwgXHNwYWR7eSA9IGcodSx2KX0sCiAgICAgICsrIFxzcGFke3og
PSBoKHUsdil9IGFzIHUgcmFuZ2VzIGZyb20gXHNwYWR7bWluKGEsYil9IHRvIFxzcGFke21heChh
LGIpfQogICAgICArKyBhbmQgdiByYW5nZXMgZnJvbSBcc3BhZHttaW4oYyxkKX0gdG8gXHNwYWR7
bWF4KGMsZCl9OyBcc3BhZHtoKHQpfSBpcwogICAgICArKyB0aGUgZGVmYXVsdCB0aXRsZS4KICAg
IG1ha2VPYmplY3Q6IChQU0YsQklORCxCSU5ELEwgRFJPUCkgLT4gU1BBQ0UzCiAgICAgICsrIG1h
a2VPYmplY3Qoc3VyZmFjZShmKHUsdiksZyh1LHYpLGgodSx2KSksdSA9IGEuLmIsdiA9IGMuLmQs
bCkgcmV0dXJucwogICAgICArKyBhIHNwYWNlIG9mIHRoZSBkb21haW4gXHNwYWR0eXBle1RocmVl
U3BhY2V9IHdoaWNoIGNvbnRhaW5zIHRoZSBncmFwaAogICAgICArKyBvZiB0aGUgcGFyYW1ldHJp
YyBzdXJmYWNlIFxzcGFke3ggPSBmKHUsdil9LCBcc3BhZHt5ID0gZyh1LHYpfSwKICAgICAgKysg
XHNwYWR7eiA9IGgodSx2KX0gYXMgdSByYW5nZXMgZnJvbSBcc3BhZHttaW4oYSxiKX0gdG8gXHNw
YWR7bWF4KGEsYil9CiAgICAgICsrIGFuZCB2IHJhbmdlcyBmcm9tIFxzcGFke21pbihjLGQpfSB0
byBcc3BhZHttYXgoYyxkKX07IFxzcGFke2godCl9IGlzCiAgICAgICsrIHRoZSBkZWZhdWx0IHRp
dGxlLCBhbmQgdGhlIG9wdGlvbnMgY29udGFpbmVkIGluIHRoZSBsaXN0IGwgb2YKICAgICAgKysg
dGhlIGRvbWFpbiBcc3BhZHtEcmF3T3B0aW9ufSBhcmUgYXBwbGllZC4KICAgIG1ha2VPYmplY3Q6
IChQU0YsQklORCxCSU5EKSAtPiBTUEFDRTMKICAgICAgKysgbWFrZU9iamVjdChzdXJmYWNlKGYo
dSx2KSxnKHUsdiksaCh1LHYpKSx1ID0gYS4uYix2ID0gYy4uZCkgcmV0dXJucwogICAgICArKyBh
IHNwYWNlIG9mIHRoZSBkb21haW4gXHNwYWR0eXBle1RocmVlU3BhY2V9IHdoaWNoIGNvbnRhaW5z
IHRoZQogICAgICArKyBncmFwaCBvZiB0aGUgcGFyYW1ldHJpYyBzdXJmYWNlIFxzcGFke3ggPSBm
KHUsdil9LCBcc3BhZHt5ID0gZyh1LHYpfSwKICAgICAgKysgXHNwYWR7eiA9IGgodSx2KX0gYXMg
dSByYW5nZXMgZnJvbSBcc3BhZHttaW4oYSxiKX0gdG8gXHNwYWR7bWF4KGEsYil9CiAgICAgICsr
IGFuZCB2IHJhbmdlcyBmcm9tIFxzcGFke21pbihjLGQpfSB0byBcc3BhZHttYXgoYyxkKX07IFxz
cGFke2godCl9IGlzCiAgICAgICsrIHRoZSBkZWZhdWx0IHRpdGxlLgoKICBJbXBsZW1lbnRhdGlv
biA9PT4gYWRkCiAgICBpbXBvcnQgVG9wTGV2ZWxEcmF3RnVuY3Rpb25zRm9yQ29tcGlsZWRGdW5j
dGlvbnMKICAgIGltcG9ydCBNYWtlRmxvYXRDb21waWxlZEZ1bmN0aW9uKEV4KQogICAgaW1wb3J0
IFBhcmFtZXRyaWNQbGFuZUN1cnZlKFNGIC0+IFNGKQogICAgaW1wb3J0IFBhcmFtZXRyaWNTcGFj
ZUN1cnZlKFNGIC0+IFNGKQogICAgaW1wb3J0IFBhcmFtZXRyaWNTdXJmYWNlKChTRixTRikgLT4g
U0YpCiAgICBpbXBvcnQgVGhyZWVTcGFjZShTRikKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotLSAgICAgICAg
ICAgICAgICAgICAgIDJEIC0gZHJhdydzICAoZ2l2ZW4gYnkgZm9ybXVsYWUpCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQoKLS0lIFR3byBEaW1lbnNpb25hbCBGdW5jdGlvbiBQbG90cwogCiAgICBkcmF3KGY6RXgs
YmluZDpCSU5ELGw6TCBEUk9QKSA9PQogICAgICAtLSBjcmVhdGUgdGl0bGUgaWYgbmVjZXNzYXJ5
CiAgICAgIGlmIG5vdCBvcHRpb24/KGwsInRpdGxlIiA6OiBTeW1ib2wpIHRoZW4KICAgICAgICBz
OlN0cmluZyA6PSB1bnBhcnNlKGNvbnZlcnQoZilASW5wdXRGb3JtKQogICAgICAgIGlmIHNheUxl
bmd0aChzKSREaXNwbGF5UGFja2FnZSA+IDUwIHRoZW4KICAgICAgICAgIGwgOj0gY29uY2F0KHRp
dGxlICJBWElPTTJEIixsKQogICAgICAgIGVsc2UgbCA6PSBjb25jYXQodGl0bGUgcyxsKQogICAg
ICAtLSBjYWxsICdkcmF3JwogICAgICBkcmF3KG1ha2VGbG9hdEZ1bmN0aW9uKGYsdmFyaWFibGUg
YmluZCksc2VnbWVudCBiaW5kLGwpCiAKICAgIGRyYXcoZjpFeCxiaW5kOkJJTkQpID09IGRyYXco
ZixiaW5kLG5pbCgpKQogCi0tJSBQYXJhbWV0cmljIFBsYW5lIEN1cnZlcwoKICAgIGRyYXcocHBj
OlBQQyxiaW5kOkJJTkQsbDpMIERST1ApID09CiAgICAgIGYgOj0gY29vcmRpbmF0ZShwcGMsMSk7
IGcgOj0gY29vcmRpbmF0ZShwcGMsMikKICAgICAgLS0gY3JlYXRlIHRpdGxlIGlmIG5lY2Vzc2Fy
eQogICAgICBpZiBub3Qgb3B0aW9uPyhsLCJ0aXRsZSIgOjogU3ltYm9sKSB0aGVuCiAgICAgICAg
czpTdHJpbmcgOj0gdW5wYXJzZShjb252ZXJ0KGYpQElucHV0Rm9ybSkKICAgICAgICBpZiBzYXlM
ZW5ndGgocykkRGlzcGxheVBhY2thZ2UgPiA1MCB0aGVuCiAgICAgICAgICBsIDo9IGNvbmNhdCh0
aXRsZSAiQVhJT00yRCIsbCkKICAgICAgICBlbHNlIGwgOj0gY29uY2F0KHRpdGxlIHMsbCkKICAg
ICAgLS0gY3JlYXRlIGN1cnZlIHdpdGggZnVuY3Rpb25zIGFzIGNvb3JkaW5hdGVzCiAgICAgIGN1
cnZlIDogUFBDRiA6PSBjdXJ2ZShtYWtlRmxvYXRGdW5jdGlvbihmLHZhcmlhYmxlIGJpbmQpLF8K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1ha2VGbG9hdEZ1bmN0aW9uKGcsdmFyaWFibGUg
YmluZCkpJFBQQ0YKICAgICAgLS0gY2FsbCAnZHJhdycKICAgICAgZHJhdyhjdXJ2ZSxzZWdtZW50
IGJpbmQsbCkKIAogICAgZHJhdyhwcGM6UFBDLGJpbmQ6QklORCkgPT0gZHJhdyhwcGMsYmluZCxu
aWwoKSkKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQotLSAgICAgICAgICAgICAgICAgICAgIDNEIC0gQ3VydmVz
ICAoZ2l2ZW4gYnkgZm9ybXVsYXMpCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKICAgIG1ha2VPYmplY3QocHNj
OlBTQyx0QmluZDpCSU5ELGw6TCBEUk9QKSA9PQogICAgICAtLSBvYnRhaW4gZGVwZW5kZW50IHZh
cmlhYmxlIGFuZCBjb29yZGluYXRlIGZ1bmN0aW9ucwogICAgICB0IDo9IHZhcmlhYmxlIHRCaW5k
OyB0U2VnIDo9IHNlZ21lbnQgdEJpbmQKICAgICAgZiA6PSBjb29yZGluYXRlKHBzYywxKTsgZyA6
PSBjb29yZGluYXRlKHBzYywyKTsgaCA6PSBjb29yZGluYXRlKHBzYywzKQogICAgICAtLSBjcmVh
dGUgdGl0bGUgaWYgbmVjZXNzYXJ5CiAgICAgIGlmIG5vdCBvcHRpb24/KGwsInRpdGxlIiA6OiBT
eW1ib2wpIHRoZW4KICAgICAgICBzOlN0cmluZyA6PSB1bnBhcnNlKGNvbnZlcnQoZilASW5wdXRG
b3JtKQogICAgICAgIGlmIHNheUxlbmd0aChzKSREaXNwbGF5UGFja2FnZSA+IDUwIHRoZW4KICAg
ICAgICAgIGwgOj0gY29uY2F0KHRpdGxlICJBWElPTTNEIixsKQogICAgICAgIGVsc2UgbCA6PSBj
b25jYXQodGl0bGUgcyxsKQogICAgICAtLSBpbmRpY2F0ZSBkcmF3IHN0eWxlIGlmIG5lY2Vzc2Fy
eQogICAgICBpZiBub3Qgb3B0aW9uPyhsLCJzdHlsZSIgOjogU3ltYm9sKSB0aGVuCiAgICAgICAg
bCA6PSBjb25jYXQoc3R5bGUgdW5wYXJzZShjb252ZXJ0KGYpQElucHV0Rm9ybSksbCkKICAgICAg
LS0gY3JlYXRlIGN1cnZlIHdpdGggZnVuY3Rpb25zIGFzIGNvb3JkaW5hdGVzCiAgICAgIGN1cnZl
IDogUFNDRiA6PSBjdXJ2ZShtYWtlRmxvYXRGdW5jdGlvbihmLHQpLF8KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIG1ha2VGbG9hdEZ1bmN0aW9uKGcsdCksXwogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgbWFrZUZsb2F0RnVuY3Rpb24oaCx0KSkKICAgICAgLS0gY2FsbCAnZHJhdycKICAg
ICAgbWFrZU9iamVjdChjdXJ2ZSx0U2VnLGwpCgogICAgbWFrZU9iamVjdChwc2M6UFNDLHRCaW5k
OkJJTkQpID09CiAgICAgIG1ha2VPYmplY3QocHNjLHRCaW5kLG5pbCgpKQoKICAgIGRyYXcocHNj
OlBTQyx0QmluZDpCSU5ELGw6TCBEUk9QKSA9PQogICAgICAtLSBvYnRhaW4gZGVwZW5kZW50IHZh
cmlhYmxlIGFuZCBjb29yZGluYXRlIGZ1bmN0aW9ucwogICAgICB0IDo9IHZhcmlhYmxlIHRCaW5k
OyB0U2VnIDo9IHNlZ21lbnQgdEJpbmQKICAgICAgZiA6PSBjb29yZGluYXRlKHBzYywxKTsgZyA6
PSBjb29yZGluYXRlKHBzYywyKTsgaCA6PSBjb29yZGluYXRlKHBzYywzKQogICAgICAtLSBjcmVh
dGUgdGl0bGUgaWYgbmVjZXNzYXJ5CiAgICAgIGlmIG5vdCBvcHRpb24/KGwsInRpdGxlIiA6OiBT
eW1ib2wpIHRoZW4KICAgICAgICBzOlN0cmluZyA6PSB1bnBhcnNlKGNvbnZlcnQoZilASW5wdXRG
b3JtKQogICAgICAgIGlmIHNheUxlbmd0aChzKSREaXNwbGF5UGFja2FnZSA+IDUwIHRoZW4KICAg
ICAgICAgIGwgOj0gY29uY2F0KHRpdGxlICJBWElPTTNEIixsKQogICAgICAgIGVsc2UgbCA6PSBj
b25jYXQodGl0bGUgcyxsKQogICAgICAtLSBpbmRpY2F0ZSBkcmF3IHN0eWxlIGlmIG5lY2Vzc2Fy
eQogICAgICBpZiBub3Qgb3B0aW9uPyhsLCJzdHlsZSIgOjogU3ltYm9sKSB0aGVuCiAgICAgICAg
bCA6PSBjb25jYXQoc3R5bGUgdW5wYXJzZShjb252ZXJ0KGYpQElucHV0Rm9ybSksbCkKICAgICAg
LS0gY3JlYXRlIGN1cnZlIHdpdGggZnVuY3Rpb25zIGFzIGNvb3JkaW5hdGVzCiAgICAgIGN1cnZl
IDogUFNDRiA6PSBjdXJ2ZShtYWtlRmxvYXRGdW5jdGlvbihmLHQpLF8KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIG1ha2VGbG9hdEZ1bmN0aW9uKGcsdCksXwogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgbWFrZUZsb2F0RnVuY3Rpb24oaCx0KSkKICAgICAgLS0gY2FsbCAnZHJhdycKICAg
ICAgZHJhdyhjdXJ2ZSx0U2VnLGwpCgogICAgZHJhdyhwc2M6UFNDLHRCaW5kOkJJTkQpID09CiAg
ICAgIGRyYXcocHNjLHRCaW5kLG5pbCgpKQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0tICAgICAgICAgICAg
ICAgICAgICAgM0QgLSBTdXJmYWNlcyAgKGdpdmVuIGJ5IGZvcm11bGFzKQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0KCi0tJSBUaHJlZSBEaW1lbnNpb25hbCBGdW5jdGlvbiBQbG90cwoKICAgIG1ha2VPYmplY3Qo
ZjpFeCx4QmluZDpCSU5ELHlCaW5kOkJJTkQsbDpMIERST1ApID09CiAgICAgIC0tIGNyZWF0ZSB0
aXRsZSBpZiBuZWNlc3NhcnkKICAgICAgaWYgbm90IG9wdGlvbj8obCwidGl0bGUiIDo6IFN5bWJv
bCkgdGhlbgogICAgICAgIHM6U3RyaW5nIDo9IHVucGFyc2UoY29udmVydChmKUBJbnB1dEZvcm0p
CiAgICAgICAgaWYgc2F5TGVuZ3RoKHMpJERpc3BsYXlQYWNrYWdlID4gNTAgdGhlbgogICAgICAg
ICAgbCA6PSBjb25jYXQodGl0bGUgIkFYSU9NM0QiLGwpCiAgICAgICAgZWxzZSBsIDo9IGNvbmNh
dCh0aXRsZSBzLGwpCiAgICAgIC0tIGluZGljYXRlIGRyYXcgc3R5bGUgaWYgbmVjZXNzYXJ5CiAg
ICAgIGlmIG5vdCBvcHRpb24/KGwsInN0eWxlIiA6OiBTeW1ib2wpIHRoZW4KICAgICAgICBsIDo9
IGNvbmNhdChzdHlsZSB1bnBhcnNlKGNvbnZlcnQoZilASW5wdXRGb3JtKSxsKQogICAgICAtLSBv
YnRhaW4gZGVwZW5kZW50IHZhcmlhYmxlcyBhbmQgdGhlaXIgcmFuZ2VzCiAgICAgIHggOj0gdmFy
aWFibGUgeEJpbmQ7IHhTZWcgOj0gc2VnbWVudCB4QmluZAogICAgICB5IDo9IHZhcmlhYmxlIHlC
aW5kOyB5U2VnIDo9IHNlZ21lbnQgeUJpbmQKICAgICAgLS0gY2FsbCAnZHJhdycKICAgICAgbWFr
ZU9iamVjdChtYWtlRmxvYXRGdW5jdGlvbihmLHgseSkseFNlZyx5U2VnLGwpCgogICAgbWFrZU9i
amVjdChmOkV4LHhCaW5kOkJJTkQseUJpbmQ6QklORCkgPT0KICAgICAgbWFrZU9iamVjdChmLHhC
aW5kLHlCaW5kLG5pbCgpKQoKICAgIGRyYXcoZjpFeCx4QmluZDpCSU5ELHlCaW5kOkJJTkQsbDpM
IERST1ApID09CiAgICAgIC0tIGNyZWF0ZSB0aXRsZSBpZiBuZWNlc3NhcnkKICAgICAgaWYgbm90
IG9wdGlvbj8obCwidGl0bGUiIDo6IFN5bWJvbCkgdGhlbgogICAgICAgIHM6U3RyaW5nIDo9IHVu
cGFyc2UoY29udmVydChmKUBJbnB1dEZvcm0pCiAgICAgICAgaWYgc2F5TGVuZ3RoKHMpJERpc3Bs
YXlQYWNrYWdlID4gNTAgdGhlbgogICAgICAgICAgbCA6PSBjb25jYXQodGl0bGUgIkFYSU9NM0Qi
LGwpCiAgICAgICAgZWxzZSBsIDo9IGNvbmNhdCh0aXRsZSBzLGwpCiAgICAgIC0tIGluZGljYXRl
IGRyYXcgc3R5bGUgaWYgbmVjZXNzYXJ5CiAgICAgIGlmIG5vdCBvcHRpb24/KGwsInN0eWxlIiA6
OiBTeW1ib2wpIHRoZW4KICAgICAgICBsIDo9IGNvbmNhdChzdHlsZSB1bnBhcnNlKGNvbnZlcnQo
ZilASW5wdXRGb3JtKSxsKQogICAgICAtLSBvYnRhaW4gZGVwZW5kZW50IHZhcmlhYmxlcyBhbmQg
dGhlaXIgcmFuZ2VzCiAgICAgIHggOj0gdmFyaWFibGUgeEJpbmQ7IHhTZWcgOj0gc2VnbWVudCB4
QmluZAogICAgICB5IDo9IHZhcmlhYmxlIHlCaW5kOyB5U2VnIDo9IHNlZ21lbnQgeUJpbmQKICAg
ICAgLS0gY2FsbCAnZHJhdycKICAgICAgZHJhdyhtYWtlRmxvYXRGdW5jdGlvbihmLHgseSkseFNl
Zyx5U2VnLGwpCgogICAgZHJhdyhmOkV4LHhCaW5kOkJJTkQseUJpbmQ6QklORCkgPT0KICAgICAg
ZHJhdyhmLHhCaW5kLHlCaW5kLG5pbCgpKQoKLS0lIHBhcmFtZXRyaWMgc3VyZmFjZQoKICAgIG1h
a2VPYmplY3QoczpQU0YsdUJpbmQ6QklORCx2QmluZDpCSU5ELGw6TCBEUk9QKSA9PQogICAgICBm
IDo9IGNvb3JkaW5hdGUocywxKTsgZyA6PSBjb29yZGluYXRlKHMsMik7IGggOj0gY29vcmRpbmF0
ZShzLDMpCiAgICAgIGlmIG5vdCBvcHRpb24/KGwsInRpdGxlIiA6OiBTeW1ib2wpIHRoZW4KICAg
ICAgICBzOlN0cmluZyA6PSB1bnBhcnNlKGNvbnZlcnQoZilASW5wdXRGb3JtKQogICAgICAgIGlm
IHNheUxlbmd0aChzKSREaXNwbGF5UGFja2FnZSA+IDUwIHRoZW4KICAgICAgICAgIGwgOj0gY29u
Y2F0KHRpdGxlICJBWElPTTNEIixsKQogICAgICAgIGVsc2UgbCA6PSBjb25jYXQodGl0bGUgcyxs
KQogICAgICBpZiBub3Qgb3B0aW9uPyhsLCJzdHlsZSIgOjogU3ltYm9sKSB0aGVuCiAgICAgICAg
bCA6PSBjb25jYXQoc3R5bGUgdW5wYXJzZShjb252ZXJ0KGYpQElucHV0Rm9ybSksbCkKICAgICAg
dSA6PSB2YXJpYWJsZSB1QmluZDsgdVNlZyA6PSBzZWdtZW50IHVCaW5kCiAgICAgIHYgOj0gdmFy
aWFibGUgdkJpbmQ7IHZTZWcgOj0gc2VnbWVudCB2QmluZAogICAgICBzdXJmIDogUFNGRiA6PSBz
dXJmYWNlKG1ha2VGbG9hdEZ1bmN0aW9uKGYsdSx2KSxfCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgbWFrZUZsb2F0RnVuY3Rpb24oZyx1LHYpLF8KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBtYWtlRmxvYXRGdW5jdGlvbihoLHUsdikpCiAgICAgIG1ha2VPYmplY3Qoc3VyZix1U2Vn
LHZTZWcsbCkKCiAgICBtYWtlT2JqZWN0KHM6UFNGLHVCaW5kOkJJTkQsdkJpbmQ6QklORCkgPT0K
ICAgICAgbWFrZU9iamVjdChzLHVCaW5kLHZCaW5kLG5pbCgpKQoKICAgIGRyYXcoczpQU0YsdUJp
bmQ6QklORCx2QmluZDpCSU5ELGw6TCBEUk9QKSA9PQogICAgICBmIDo9IGNvb3JkaW5hdGUocywx
KTsgZyA6PSBjb29yZGluYXRlKHMsMik7IGggOj0gY29vcmRpbmF0ZShzLDMpCiAgICAgIC0tIGNy
ZWF0ZSB0aXRsZSBpZiBuZWNlc3NhcnkKICAgICAgaWYgbm90IG9wdGlvbj8obCwidGl0bGUiIDo6
IFN5bWJvbCkgdGhlbgogICAgICAgIHM6U3RyaW5nIDo9IHVucGFyc2UoY29udmVydChmKUBJbnB1
dEZvcm0pCiAgICAgICAgaWYgc2F5TGVuZ3RoKHMpJERpc3BsYXlQYWNrYWdlID4gNTAgdGhlbgog
ICAgICAgICAgbCA6PSBjb25jYXQodGl0bGUgIkFYSU9NM0QiLGwpCiAgICAgICAgZWxzZSBsIDo9
IGNvbmNhdCh0aXRsZSBzLGwpCiAgICAgIC0tIGluZGljYXRlIGRyYXcgc3R5bGUgaWYgbmVjZXNz
YXJ5CiAgICAgIGlmIG5vdCBvcHRpb24/KGwsInN0eWxlIiA6OiBTeW1ib2wpIHRoZW4KICAgICAg
ICBsIDo9IGNvbmNhdChzdHlsZSB1bnBhcnNlKGNvbnZlcnQoZilASW5wdXRGb3JtKSxsKQogICAg
ICAtLSBvYnRhaW4gZGVwZW5kZW50IHZhcmlhYmxlcyBhbmQgdGhlaXIgcmFuZ2VzCiAgICAgIHUg
Oj0gdmFyaWFibGUgdUJpbmQ7IHVTZWcgOj0gc2VnbWVudCB1QmluZAogICAgICB2IDo9IHZhcmlh
YmxlIHZCaW5kOyB2U2VnIDo9IHNlZ21lbnQgdkJpbmQKICAgICAgLS0gY3JlYXRlIHN1cmZhY2Ug
d2l0aCBmdW5jdGlvbnMgYXMgY29vcmRpbmF0ZXMKICAgICAgc3VyZiA6IFBTRkYgOj0gc3VyZmFj
ZShtYWtlRmxvYXRGdW5jdGlvbihmLHUsdiksXwogICAgICAgICAgICAgICAgICAgICAgICAgICAg
IG1ha2VGbG9hdEZ1bmN0aW9uKGcsdSx2KSxfCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
bWFrZUZsb2F0RnVuY3Rpb24oaCx1LHYpKQogICAgICAtLSBjYWxsICdkcmF3JwogICAgICBkcmF3
KHN1cmYsdVNlZyx2U2VnLGwpCgogICAgZHJhdyhzOlBTRix1QmluZDpCSU5ELHZCaW5kOkJJTkQp
ID09CiAgICAgIGRyYXcocyx1QmluZCx2QmluZCxuaWwoKSkKCkAKXHNlY3Rpb257cGFja2FnZSBE
UkFXQ1VSViBUb3BMZXZlbERyYXdGdW5jdGlvbnNGb3JBbGdlYnJhaWNDdXJ2ZXN9Cjw8cGFja2Fn
ZSBEUkFXQ1VSViBUb3BMZXZlbERyYXdGdW5jdGlvbnNGb3JBbGdlYnJhaWNDdXJ2ZXM+Pj0KKWFi
YnJldiBwYWNrYWdlIERSQVdDVVJWIFRvcExldmVsRHJhd0Z1bmN0aW9uc0ZvckFsZ2VicmFpY0N1
cnZlcworKyBBdXRob3I6IENsaWZ0b24gSi4gV2lsbGlhbXNvbgorKyBEYXRlIENyZWF0ZWQ6IDI2
IEp1bmUgMTk5MAorKyBEYXRlIExhc3QgVXBkYXRlZDogIEF1Z3VzdCAyMDA1IGJ5IEthaSBLYW1p
bnNraQorKyBCYXNpYyBPcGVyYXRpb25zOiBkcmF3CisrIFJlbGF0ZWQgQ29uc3RydWN0b3JzOgor
KyBBbHNvIFNlZToKKysgQU1TIENsYXNzaWZpY2F0aW9uczoKKysgS2V5d29yZHM6CisrIFJlZmVy
ZW5jZXM6CisrIERlc2NyaXB0aW9uOiBUb3BMZXZlbERyYXdGdW5jdGlvbnNGb3JBbGdlYnJhaWND
dXJ2ZXMgcHJvdmlkZXMgdG9wIGxldmVsIAorKyBmdW5jdGlvbnMgZm9yIGRyYXdpbmcgbm9uLXNp
bmd1bGFyIGFsZ2VicmFpYyBjdXJ2ZXMuCgpUb3BMZXZlbERyYXdGdW5jdGlvbnNGb3JBbGdlYnJh
aWNDdXJ2ZXMoUixFeCk6IEV4cG9ydHMgPT0gSW1wbGVtZW50YXRpb24gd2hlcmUKICBSICA6IEpv
aW4oSW50ZWdyYWxEb21haW4sIE9yZGVyZWRTZXQsIFJldHJhY3RhYmxlVG8gSW50ZWdlcikKICBF
eCA6IEZ1bmN0aW9uU3BhY2UoUikKCiAgQU5ZMSAgPT0+IEFueUZ1bmN0aW9uczEKICBEUk9QICA9
PT4gRHJhd09wdGlvbgogIEVRICAgID09PiBFcXVhdGlvbgogIEYgICAgID09PiBGbG9hdAogIEZS
QUMgID09PiBGcmFjdGlvbgogIEkgICAgID09PiBJbnRlZ2VyCiAgTCAgICAgPT0+IExpc3QKICBQ
ICAgICA9PT4gUG9seW5vbWlhbAogIFJOICAgID09PiBGcmFjdGlvbiBJbnRlZ2VyCiAgU0VHICAg
PT0+IFNlZ21lbnQKICBTWSAgICA9PT4gU3ltYm9sCiAgVklFVzIgPT0+IFR3b0RpbWVuc2lvbmFs
Vmlld3BvcnQKCiAgRXhwb3J0cyA9PT4gd2l0aAoKICAgIGRyYXc6IChFUSBFeCxTWSxTWSxMIERS
T1ApIC0+IFZJRVcyCiAgICAgICsrIGRyYXcoZih4LHkpID0gZyh4LHkpLHgseSxsKSBkcmF3cyB0
aGUgZ3JhcGggb2YgYSBwb2x5bm9taWFsCiAgICAgICsrIGVxdWF0aW9uLiAgVGhlIGxpc3QgbCBv
ZiBkcmF3IG9wdGlvbnMgbXVzdCBzcGVjaWZ5IGEgcmVnaW9uCiAgICAgICsrIGluIHRoZSBwbGFu
ZSBpbiB3aGljaCB0aGUgY3VydmUgaXMgdG8gc2tldGNoZWQuCgogIEltcGxlbWVudGF0aW9uID09
PiBhZGQKICAgIGltcG9ydCBWaWV3cG9ydFBhY2thZ2UKICAgIGltcG9ydCBQbGFuZUFsZ2VicmFp
Y0N1cnZlUGxvdAogICAgaW1wb3J0IFZpZXdEZWZhdWx0c1BhY2thZ2UKICAgIGltcG9ydCBHcmFw
aGljc0RlZmF1bHRzCiAgICBpbXBvcnQgRHJhd09wdGlvbkZ1bmN0aW9uczAKICAgIGltcG9ydCBT
ZWdtZW50RnVuY3Rpb25zMihSTixGKQogICAgaW1wb3J0IFNlZ21lbnRGdW5jdGlvbnMyKEYsUk4p
CiAgICBpbXBvcnQgQW55RnVuY3Rpb25zMShMIFNFRyBSTikKCiAgICBkcmF3VG9TY2FsZVJhbmdl
czogKFNFRyBGLFNFRyBGKSAtPiBMIFNFRyBGCiAgICBkcmF3VG9TY2FsZVJhbmdlcyh4VmFscyx5
VmFscykgPT0KICAgICAgLS0gd2FybmluZzogYXNzdW1lcyB3aW5kb3cgaXMgc3F1YXJlCiAgICAg
IHhIaSA6PSBoaSB4VmFsczsgeExvIDo9IGxvIHhWYWxzCiAgICAgIHlIaSA6PSBoaSB5VmFsczsg
eUxvIDo9IGxvIHlWYWxzCiAgICAgIHhEaWZmIDo9IHhIaSAtIHhMbzsgeURpZmYgOj0geUhpIC0g
eUxvCiAgICAgIHBhZCA6PSBhYnMoeURpZmYgLSB4RGlmZikvMgogICAgICB5RGlmZiA+IHhEaWZm
ID0+CiAgICAgICAgW3NlZ21lbnQoeExvIC0gcGFkLHhIaSArIHBhZCkseVZhbHNdCiAgICAgIFt4
VmFscyxzZWdtZW50KHlMbyAtIHBhZCx5SGkgKyBwYWQpXQoKICAgIGludENvbnZlcnQ6IFIgLT4g
SQogICAgaW50Q29udmVydCByID09CiAgICAgIChubiA6PSByZXRyYWN0SWZDYW4ocilAVW5pb24o
SSwiZmFpbGVkIikpIGNhc2UgImZhaWxlZCIgPT4KICAgICAgICBlcnJvciAiZHJhdzogcG9seW5v
bWlhbCBtdXN0IGhhdmUgcmF0aW9uYWwgY29lZmZpY2llbnRzIgogICAgICBubiA6OiBJCgogICAg
cG9seUVxdWF0aW9uOiBFUSBFeCAtPiBQIEkKICAgIHBvbHlFcXVhdGlvbiBlcSA9PQogICAgICBm
ZiA6PSBsaHMoZXEpIC0gcmhzKGVxKQogICAgICAociA6PSByZXRyYWN0SWZDYW4oZmYpQFVuaW9u
KEZSQUMgUCBSLCJmYWlsZWQiKSkgY2FzZSAiZmFpbGVkIiA9PgogICAgICAgIGVycm9yICJkcmF3
OiBub3QgYSBwb2x5bm9taWFsIGVxdWF0aW9uIgogICAgICByYXQgOj0gciA6OiBGUkFDIFAgUgog
ICAgICByZXRyYWN0SWZDYW4oZGVub20gcmF0KUBVbmlvbihSLCJmYWlsZWQiKSBjYXNlICJmYWls
ZWQiID0+CiAgICAgICAgZXJyb3IgImRyYXc6IG5vbi1jb25zdGFudCBkZW5vbWluYXRvciIKICAg
ICAgbWFwKGludENvbnZlcnQsbnVtZXIgcmF0KSRQb2x5bm9taWFsRnVuY3Rpb25zMihSLEkpCgog
ICAgcHJpbnRGbG9hdDogRmxvYXQgLT4gJQogICAgcHJpbnRGbG9hdCAoZikgPT0KICAgICAgUFJJ
TkMkTGlzcCAiICIKICAgICAgUFJJTkMkTGlzcCAoY29udmVydChmKUBTdHJpbmcpCiAgICAgIFBS
SU5DJExpc3AgIiAiCgoKCiAgICBkcmF3KGVxLHgseSxsKSA9PQogICAgICAtLSBvYnRhaW4gcG9s
eW5vbWlhbCBlcXVhdGlvbgogICAgICBwIDo9IHBvbHlFcXVhdGlvbiBlcQogICAgICAtLSBleHRy
YWN0IHJhbmdlcyBmcm9tIG9wdGlvbiBsaXN0CiAgICAgIGZsb2F0UmFuZ2UgOj0gb3B0aW9uKGws
InJhbmdlRmxvYXQiIDo6IFN5bWJvbCkKICAgICAgcmF0UmFuZ2UgOj0gb3B0aW9uKGwsInJhbmdl
UmF0IiA6OiBTeW1ib2wpCiAgICAgIChmbG9hdFJhbmdlIGNhc2UgImZhaWxlZCIpIGFuZCAocmF0
UmFuZ2UgY2FzZSAiZmFpbGVkIikgPT4KICAgICAgICBlcnJvciAiZHJhdzogeW91IG11c3Qgc3Bl
Y2lmeSByYW5nZXMgZm9yIGFuIGltcGxpY2l0IHBsb3QiCiAgICAgIHJhbmdlcyA6IEwgU0VHIFJO
IDo9IG5pbCgpICAgICAgICAgICAgIC0tIGR1bW15IHZhbHVlCiAgICAgIGZsb2F0UmFuZ2VzIDog
TCBTRUcgRiA6PSBuaWwoKSAgICAgICAgIC0tIGR1bW15IHZhbHVlCiAgICAgIHhSYW5nZSA6IFNF
RyBSTiA6PSBzZWdtZW50KDAsMCkgICAgICAgIC0tIGR1bW15IHZhbHVlCiAgICAgIHlSYW5nZSA6
IFNFRyBSTiA6PSBzZWdtZW50KDAsMCkgICAgICAgIC0tIGR1bW15IHZhbHVlCiAgICAgIHhSYW5n
ZUZsb2F0IDogU0VHIEYgOj0gc2VnbWVudCgwLDApICAgIC0tIGR1bW15IHZhbHVlCiAgICAgIHlS
YW5nZUZsb2F0IDogU0VHIEYgOj0gc2VnbWVudCgwLDApICAgIC0tIGR1bW15IHZhbHVlCiAgICAg
IGlmIG5vdCByYXRSYW5nZSBjYXNlICJmYWlsZWQiIHRoZW4KICAgICAgICByYW5nZXMgOj0gcmV0
cmFjdChyYXRSYW5nZSA6OiBBbnkpJEFOWTEoTCBTRUcgUk4pCiAgICAgICAgbm90IHNpemU/KHJh
bmdlcywyKSA9PiBlcnJvciAiZHJhdzogeW91IG11c3Qgc3BlY2lmeSB0d28gcmFuZ2VzIgogICAg
ICAgIHhSYW5nZSA6PSBmaXJzdCByYW5nZXM7IHlSYW5nZSA6PSBzZWNvbmQgcmFuZ2VzCiAgICAg
ICAgeFJhbmdlRmxvYXQgOj0gbWFwKGNvbnZlcnQoIzEpQEZsb2F0LHhSYW5nZSlAKFNFRyBGKQog
ICAgICAgIHlSYW5nZUZsb2F0IDo9IG1hcChjb252ZXJ0KCMxKUBGbG9hdCx5UmFuZ2UpQChTRUcg
RikKICAgICAgICBmbG9hdFJhbmdlcyA6PSBbeFJhbmdlRmxvYXQseVJhbmdlRmxvYXRdCiAgICAg
IGVsc2UKICAgICAgICBmbG9hdFJhbmdlcyA6PSByZXRyYWN0KGZsb2F0UmFuZ2UgOjogQW55KSRB
TlkxKEwgU0VHIEYpCiAgICAgICAgbm90IHNpemU/KGZsb2F0UmFuZ2VzLDIpID0+CiAgICAgICAg
ICBlcnJvciAiZHJhdzogeW91IG11c3Qgc3BlY2lmeSB0d28gcmFuZ2VzIgogICAgICAgIHhSYW5n
ZUZsb2F0IDo9IGZpcnN0IGZsb2F0UmFuZ2VzCiAgICAgICAgeVJhbmdlRmxvYXQgOj0gc2Vjb25k
IGZsb2F0UmFuZ2VzCiAgICAgICAgeFJhbmdlIDo9IG1hcChyZXRyYWN0KCMxKUBSTix4UmFuZ2VG
bG9hdClAKFNFRyBSTikKICAgICAgICB5UmFuZ2UgOj0gbWFwKHJldHJhY3QoIzEpQFJOLHlSYW5n
ZUZsb2F0KUAoU0VHIFJOKQogICAgICAgIHJhbmdlcyA6PSBbeFJhbmdlLHlSYW5nZV0KICAgICAg
LS0gY3JlYXRlIGN1cnZlIHBsb3QKICAgICAgYWNwbG90IDo9IG1ha2VTa2V0Y2gocCx4LHkseFJh
bmdlLHlSYW5nZSkKICAgICAgLS0gcHJvY2VzcyBzY2FsaW5nIGluZm9ybWF0aW9uCiAgICAgIGlm
IHRvU2NhbGUobCxkcmF3VG9TY2FsZSgpKSB0aGVuCiAgICAgICAgc2NhbGVkUmFuZ2VzIDo9IGRy
YXdUb1NjYWxlUmFuZ2VzKHhSYW5nZUZsb2F0LHlSYW5nZUZsb2F0KQogICAgICAgIC0tIGFkZCBz
Y2FsZWQgcmFuZ2VzIHRvIGxpc3Qgb2Ygb3B0aW9ucwogICAgICAgIGwgOj0gY29uY2F0KHJhbmdl
cyBzY2FsZWRSYW5nZXMsbCkKICAgICAgZWxzZQogICAgICAgIC0tIGFkZCByYW5nZXMgdG8gbGlz
dCBvZiBvcHRpb25zCiAgICAgICAgbCA6PSBjb25jYXQocmFuZ2VzIGZsb2F0UmFuZ2VzLGwpCiAg
ICAgIC0tIHByb2Nlc3MgY29sb3IgaW5mb3JtYXRpb24KICAgICAgcHRDb2wgOj0gcG9pbnRDb2xv
clBhbGV0dGUobCxwb2ludENvbG9yRGVmYXVsdCgpKQogICAgICBjckNvbCA6PSBjdXJ2ZUNvbG9y
UGFsZXR0ZShsLGxpbmVDb2xvckRlZmF1bHQoKSkKCiAgICAgIC0tIHByaW50IHRoZSBicmFuY2hl
cyAoKlBSSU5ULUFSUkFZKiBtdXN0IGJlIHNldCB0byBULCBvdGhlcndpc2UKICAgICAgLS0gdGhl
IHByaW50b3V0IHdpbGwgYmUgdXNlbGVzcy4KICAgICAgUFJJTkMkTGlzcCAiUExPVERBVEFCRUdJ
TiAiCgogICAgICAtLSBvcHRpb25zCiAgICAgIFBSSU5DJExpc3AgIigiCiAgICAgIC0tIHJhbmdl
cwogICAgICBQUklOQyRMaXNwICI6cmFuZ2UgIgogICAgICBvdXRwdXRTcGFjaW5nKDApCiAgICAg
IGxveCA6PSBsb3cgeFJhbmdlRmxvYXQKICAgICAgaGl4IDo9IGhpIHhSYW5nZUZsb2F0CiAgICAg
IGxveSA6PSBsb3cgeVJhbmdlRmxvYXQKICAgICAgaGl5IDo9IGhpIHlSYW5nZUZsb2F0CiAgICAg
IFBSSU5DJExpc3AgIigiCiAgICAgIFBSSU5DJExpc3AgKGNvbnZlcnQobG94KUBTdHJpbmcpCiAg
ICAgIFBSSU5DJExpc3AgIiAiCiAgICAgIFBSSU5DJExpc3AgKGNvbnZlcnQobG95KUBTdHJpbmcp
CiAgICAgIFBSSU5DJExpc3AgIiAiCiAgICAgIFBSSU5DJExpc3AgKGNvbnZlcnQoaGl4KUBTdHJp
bmcpCiAgICAgIFBSSU5DJExpc3AgIiAiCiAgICAgIFBSSU5DJExpc3AgKGNvbnZlcnQoaGl5KUBT
dHJpbmcpCiAgICAgIFBSSU5DJExpc3AgIiAiCiAgICAgIFBSSU5DJExpc3AgIikiCgogICAgICAt
LSB1bml0cwogICAgICBQUklOQyRMaXNwICIgOnVuaXQgIgogICAgICB1IDo9IHVuaXRzKGwsW11A
KExpc3QgRmxvYXQpKUAoTGlzdCBGbG9hdCkKICAgICAgUFJJTkMkTGlzcCAiKCIKICAgICAgaWYg
bm90IG51bGwgdSAgdGhlbgogICAgICAgIGZvciB4IGluIHUgcmVwZWF0CiAgICAgICAgICBwcmlu
dEZsb2F0KHgpCiAgICAgIFBSSU5DJExpc3AgIikiCgogICAgICAtLSB0aXRsZQogICAgICBQUklO
QyRMaXNwICIgOnRpdGxlICIKICAgICAgdGl0bGUgOiBTdHJpbmcgOj0gdGl0bGUobCwgIkF4aW9t
IDJEIFBsb3QiKQogICAgICBQUklOVCRMaXNwIHRpdGxlCgogICAgICBQUklOQyRMaXNwICIgOmJy
YW5jaGVzICIKICAgICAgUFJJTkMkTGlzcCAobGlzdEJyYW5jaGVzIGFjcGxvdCkKICAgICAgUFJJ
TkMkTGlzcCAiKSIKICAgICAgUFJJTkMkTGlzcCAiUExPVERBVEFFTkQiCgogICAgICAtLSBkcmF3
CiAgICAgIGRyYXdDdXJ2ZXMobGlzdEJyYW5jaGVzIGFjcGxvdCxwdENvbCxjckNvbCxwb2ludFNp
emVEZWZhdWx0KCksbCkKCkAKXHNlY3Rpb257cGFja2FnZSBEUkFXUFQgVG9wTGV2ZWxEcmF3RnVu
Y3Rpb25zRm9yUG9pbnRzfQo8PHBhY2thZ2UgRFJBV1BUIFRvcExldmVsRHJhd0Z1bmN0aW9uc0Zv
clBvaW50cz4+PQopYWJicmV2IHBhY2thZ2UgRFJBV1BUIFRvcExldmVsRHJhd0Z1bmN0aW9uc0Zv
clBvaW50cworKyBBdXRob3I6IE1pa2UgRGV3YXIKKysgRGF0ZSBDcmVhdGVkOiAyNCBNYXkgMTk5
NQorKyBEYXRlIExhc3QgVXBkYXRlZDogMjUgTm92ZW1iZXIgMTk5NgorKyBCYXNpYyBPcGVyYXRp
b25zOiBkcmF3CisrIFJlbGF0ZWQgQ29uc3RydWN0b3JzOgorKyBBbHNvIFNlZToKKysgQU1TIENs
YXNzaWZpY2F0aW9uczoKKysgS2V5d29yZHM6CisrIFJlZmVyZW5jZXM6CisrIERlc2NyaXB0aW9u
OiBUb3BMZXZlbERyYXdGdW5jdGlvbnNGb3JQb2ludHMgcHJvdmlkZXMgdG9wIGxldmVsIGZ1bmN0
aW9ucyBmb3IgCisrIGRyYXdpbmcgY3VydmVzIGFuZCBzdXJmYWNlcyBkZXNjcmliZWQgYnkgc2V0
cyBvZiBwb2ludHMuCiAKVG9wTGV2ZWxEcmF3RnVuY3Rpb25zRm9yUG9pbnRzKCk6IEV4cG9ydHMg
PT0gSW1wbGVtZW50YXRpb24gd2hlcmUKCiAgRFJPUCAgPT0+IERyYXdPcHRpb24KICBMICAgICA9
PT4gTGlzdAogIFNGICAgID09PiBEb3VibGVGbG9hdAogIFB0ICAgID09PiBQb2ludCBTRgogIFZJ
RVcyID09PiBUd29EaW1lbnNpb25hbFZpZXdwb3J0CiAgVklFVzMgPT0+IFRocmVlRGltZW5zaW9u
YWxWaWV3cG9ydAoKICBFeHBvcnRzID09PiB3aXRoCiAgICBkcmF3OiAoTCBTRixMIFNGKSAtPiBW
SUVXMgogICAgICArKyBkcmF3KGx4LGx5KSBwbG90cyB0aGUgY3VydmUgY29uc3RydWN0ZWQgb2Yg
cG9pbnRzICh4LHkpIGZvciB4CiAgICAgICsrIGluIFxzcGFke2x4fSBmb3IgeSBpbiBcc3BhZHts
eX0uCiAgICBkcmF3OiAoTCBTRixMIFNGLEwgRFJPUCkgLT4gVklFVzIKICAgICAgKysgZHJhdyhs
eCxseSxsKSBwbG90cyB0aGUgY3VydmUgY29uc3RydWN0ZWQgb2YgcG9pbnRzICh4LHkpIGZvciB4
CiAgICAgICsrIGluIFxzcGFke2x4fSBmb3IgeSBpbiBcc3BhZHtseX0uCiAgICAgICsrIFRoZSBv
cHRpb25zIGNvbnRhaW5lZCBpbiB0aGUgbGlzdCBsIG9mCiAgICAgICsrIHRoZSBkb21haW4gXHNw
YWR7RHJhd09wdGlvbn0gYXJlIGFwcGxpZWQuCiAgICBkcmF3OiAoTCBQdCkgLT4gVklFVzIKICAg
ICAgKysgZHJhdyhscCkgcGxvdHMgdGhlIGN1cnZlIGNvbnN0cnVjdGVkIGZyb20gdGhlIGxpc3Qg
b2YgcG9pbnRzIGxwLgogICAgZHJhdzogKEwgUHQsTCBEUk9QKSAtPiBWSUVXMgogICAgICArKyBk
cmF3KGxwLGwpIHBsb3RzIHRoZSBjdXJ2ZSBjb25zdHJ1Y3RlZCBmcm9tIHRoZSBsaXN0IG9mIHBv
aW50cyBscC4KICAgICAgKysgVGhlIG9wdGlvbnMgY29udGFpbmVkIGluIHRoZSBsaXN0IGwgb2Yg
dGhlIGRvbWFpbiBcc3BhZHtEcmF3T3B0aW9ufQogICAgICArKyBhcmUgYXBwbGllZC4KICAgIGRy
YXc6IChMIFNGLCBMIFNGLCBMIFNGKSAtPiBWSUVXMwogICAgICArKyBkcmF3KGx4LGx5LGx6KSBk
cmF3cyB0aGUgc3VyZmFjZSBjb25zdHJ1Y3RlZCBieSBwcm9qZWN0aW5nIHRoZSB2YWx1ZXMKICAg
ICAgKysgaW4gdGhlIFxheGlvbXtsen0gbGlzdCBvbnRvIHRoZSByZWN0YW5ndWxhciBncmlkIGZv
cm1lZCBieSB0aGUgCiAgICAgICsrIFxheGlvbXtseCBYIGx5fS4KICAgIGRyYXc6IChMIFNGLCBM
IFNGLCBMIFNGLCBMIERST1ApIC0+IFZJRVczCiAgICAgICsrIGRyYXcobHgsbHksbHosbCkgZHJh
d3MgdGhlIHN1cmZhY2UgY29uc3RydWN0ZWQgYnkgcHJvamVjdGluZyB0aGUgdmFsdWVzCiAgICAg
ICsrIGluIHRoZSBcYXhpb217bHp9IGxpc3Qgb250byB0aGUgcmVjdGFuZ3VsYXIgZ3JpZCBmb3Jt
ZWQgYnkgdGhlIAogICAgICArKyBUaGUgb3B0aW9ucyBjb250YWluZWQgaW4gdGhlIGxpc3QgbCBv
ZiB0aGUgZG9tYWluIFxzcGFke0RyYXdPcHRpb259CiAgICAgICsrIGFyZSBhcHBsaWVkLgoKICBJ
bXBsZW1lbnRhdGlvbiA9PT4gYWRkCgogICAgZHJhdyhscDpMIFB0LGw6TCBEUk9QKTpWSUVXMiA9
PQogICAgICBtYWtlVmlld3BvcnQyRChtYWtlR3JhcGhJbWFnZShbbHBdKSRHcmFwaEltYWdlLGwp
JFZJRVcyCgogICAgZHJhdyhscDpMIFB0KTpWSUVXMiA9PSBkcmF3KGxwLFtdKQoKICAgIGRyYXco
bHg6IEwgU0YsIGx5OiBMIFNGLCBsOkwgRFJPUCk6VklFVzIgPT0KICAgICAgZHJhdyhbcG9pbnQo
W3gseV0pJFB0IGZvciB4IGluIGx4IGZvciB5IGluIGx5XSxsKQoKICAgIGRyYXcobHg6IEwgU0Ys
IGx5OiBMIFNGKTpWSUVXMiA9PSBkcmF3KGx4LGx5LFtdKQoKICAgIGRyYXcoeDpMIFNGLHk6TCBT
Rix6OkwgU0YpOlZJRVczID09IGRyYXcoeCx5LHosW10pCgogICAgZHJhdyh4OkwgU0YseTpMIFNG
LHo6TCBTRixsOkwgRFJPUCk6VklFVzMgPT0KICAgICAgbSAgOiBJbnRlZ2VyIDo9ICN4CiAgICAg
IHplcm8/IG0gPT4gZXJyb3IgIk5vIFggdmFsdWVzIgogICAgICBuICA6IEludGVnZXIgOj0gI3kK
ICAgICAgemVybz8gbiA9PiBlcnJvciAiTm8gWSB2YWx1ZXMiCiAgICAgIHpMZW4gOiBJbnRlZ2Vy
IDo9ICN6CiAgICAgIHpMZW4gfj0gKG0qbikgPT4gCiAgICAgICAgekxlbiA+IChtKm4pID0+IGVy
cm9yICJUb28gbWFueSBaLXZhbHVlcyB0byBmaXQgZ3JpZCIKICAgICAgICBlcnJvciAiTm90IGVu
b3VnaCBaLXZhbHVlcyB0byBmaXQgZ3JpZCIKICAgICAgcG9pbnRzIDogTCBMIFB0IDo9IFtdCiAg
ICAgIGZvciBqIGluIG4uLjEgYnkgLTEgcmVwZWF0CiAgICAgICAgcm93IDogTCBQdCA6PSBbXQog
ICAgICAgIGZvciBpIGluIG0uLjEgYnkgLTEgcmVwZWF0CiAgICAgICAgICB6dmFsIDo9IChqLTEp
Km0raQogICAgICAgICAgcm93IDo9IGNvbnMocG9pbnQoW3guaSx5Lmosei56dmFsLHouenZhbF0p
LHJvdykKICAgICAgICBwb2ludHMgOj0gY29ucyhyb3cscG9pbnRzKQogICAgICBtYWtlVmlld3Bv
cnQzRChtZXNoIHBvaW50cyxsKQoKQApcc2VjdGlvbntMaWNlbnNlfQo8PGxpY2Vuc2U+Pj0KLS1D
b3B5cmlnaHQgKGMpIDE5OTEtMjAwMiwgVGhlIE51bWVyaWNhbCBBTGdvcml0aG1zIEdyb3VwIEx0
ZC4KLS1BbGwgcmlnaHRzIHJlc2VydmVkLgotLQotLVJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4g
c291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAotLW1vZGlmaWNhdGlvbiwg
YXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucyBhcmUK
LS1tZXQ6Ci0tCi0tICAgIC0gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0
YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKLS0gICAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25k
aXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCi0tCi0tICAgIC0gUmVkaXN0cmli
dXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQK
LS0gICAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5n
IGRpc2NsYWltZXIgaW4KLS0gICAgICB0aGUgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0
ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlCi0tICAgICAgZGlzdHJpYnV0aW9uLgotLQotLSAgICAt
IE5laXRoZXIgdGhlIG5hbWUgb2YgVGhlIE51bWVyaWNhbCBBTGdvcml0aG1zIEdyb3VwIEx0ZC4g
bm9yIHRoZQotLSAgICAgIG5hbWVzIG9mIGl0cyBjb250cmlidXRvcnMgbWF5IGJlIHVzZWQgdG8g
ZW5kb3JzZSBvciBwcm9tb3RlIHByb2R1Y3RzCi0tICAgICAgZGVyaXZlZCBmcm9tIHRoaXMgc29m
dHdhcmUgd2l0aG91dCBzcGVjaWZpYyBwcmlvciB3cml0dGVuIHBlcm1pc3Npb24uCi0tCi0tVEhJ
UyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQ09QWVJJR0hUIEhPTERFUlMgQU5EIENPTlRS
SUJVVE9SUyAiQVMKLS1JUyIgQU5EIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywg
SU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQKLS1UTywgVEhFIElNUExJRUQgV0FSUkFOVElFUyBP
RiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEKLS1QQVJUSUNVTEFSIFBVUlBPU0Ug
QVJFIERJU0NMQUlNRUQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBDT1BZUklHSFQgT1dORVIKLS1P
UiBDT05UUklCVVRPUlMgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURF
TlRBTCwgU1BFQ0lBTCwKLS1FWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUyAoSU5D
TFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sCi0tUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBH
T09EUyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SCi0tUFJPRklUUzsgT1IgQlVT
SU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRgot
LUxJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwgT1IgVE9S
VCAoSU5DTFVESU5HCi0tTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdB
WSBPVVQgT0YgVEhFIFVTRSBPRiBUSElTCi0tU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBU
SEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCkAKPDwqPj49Cjw8bGljZW5zZT4+Cgo8PHBh
Y2thZ2UgRFJBV0NGVU4gVG9wTGV2ZWxEcmF3RnVuY3Rpb25zRm9yQ29tcGlsZWRGdW5jdGlvbnM+
Pgo8PHBhY2thZ2UgRFJBVyBUb3BMZXZlbERyYXdGdW5jdGlvbnM+Pgo8PHBhY2thZ2UgRFJBV0NV
UlYgVG9wTGV2ZWxEcmF3RnVuY3Rpb25zRm9yQWxnZWJyYWljQ3VydmVzPj4KPDxwYWNrYWdlIERS
QVdQVCBUb3BMZXZlbERyYXdGdW5jdGlvbnNGb3JQb2ludHM+PgpAClxlamVjdApcYmVnaW57dGhl
YmlibGlvZ3JhcGh5fXs5OX0KXGJpYml0ZW17MX0gbm90aGluZwpcZW5ke3RoZWJpYmxpb2dyYXBo
eX0KXGVuZHtkb2N1bWVudH0K
--=-=-=--

\start
Date: Thu, 21 Sep 2006 12:26:43 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: [build Axiom] updated Windows buildinstructions

On Thursday, September 21, 2006 11:27 AM you wrote:
>
> On 09/21/2006 04:55 PM, Page, Bill wrote:
> >>    echo "draw(...)" | axiom > picture.ps
>
> > Yes, all you need is to be using a machine that has X11
> > installed.
>
> Thank you, Bill. I really thought that it would have been
> easier.
>
> Does somebody know why X11 is required?

Yes of course. There has been a long ongoing discussion about
how best to implement Hyperdoc and Axiom Graphics on Windows
because of this issue. X11 is required because both HyperDoc
and Axiom Graphics call X11 library functions directly when
creating windows and drawing to the screen.

> Axiom was also sold on Windows if I am not completely wrong.

You are correct.

> How did NAG produce graphics there?

NAG integrated two new packages for Axiom on Windows - one
called OpenInventor (for graphics) and the other Techexplorer
(a latex-cable browser to replace Hyperdoc). Both of these
packages were proprietary at the time Axiom was made open
source but now they are (more or less) open.

OpenInventor is now called 'Coin3d'. See:

http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00201.htm=
l

and the related threads:

http://lists.nongnu.org/archive/cgi-bin/namazu.cgi?query=openinventor&s=
ubmit=Search%21&idxname=axiom-developer&max=20&result=normal&sort=
=date%3Alate

http://lists.nongnu.org/archive/cgi-bin/namazu.cgi?query=Techexplorer&s=
ubmit=Search%21&idxname=axiom-developer&max=10&result=normal&sort=
=date%3Alate

For Techexplorer

http://lists.nongnu.org/archive/html/axiom-developer/2004-08/msg00069.htm=
l

http://www.integretechpub.com/products/techexplorer


>
> I quickly looked at src/algebra/view2D.spad but I could not
> see anything related to X. Since I have no idea what
>
>    VIEW    ==> VIEWPORTSERVER$Lisp
>
> refers to, I am out of business. :-(

This is part of the communications interface between Axiom and
Axiom Graphics. Axiom Graphics is a separate program written in
"C" that does all of the interaction with X11. AXIOMsys (which
is the program that runs the code at which you are looking) sends
commands to Axiom Graphics via a session socket.

> But I really really wonder, why X is a must for draw and/or
> write. Does Axiom (through LISP) call some functions from X?
>

No, not directly. Only by sending a command to another process
that does that work.

\start
Date: Thu, 21 Sep 2006 17:51:04 +0200
From: Kai Kaminski
To: list
Subject: Literated VMLISP.LISP.PAMPHLET

I've 'literated' VMLISP.LISP.PAMPHLET (the result is attached), which
contains compatibility/utility code. In particular, I did the
following:

1) I gave most functions their own chunk. Sometimes I put several
   functions in a single chunk, mostly because they didn't need
   individual documentation. For example there are a lot of aliases. I
   put most of them in a single chunk.

2) I added/removed blank lines and comments. The latter only if they
   appeared to be useless. Otherwise I just kept them.

3) I *did not* change the capitalization/formatting of code. At least
   not intentionally.

4) I *did* change the order of function definitions. This was
   necessary since I put several functions within a single chunk.

5) I *did not* delete any code that wasn't commented out.

6) I created sections roughly corresponding to the comments in
   VMLISP.LISP, which in turn corresponded to the VMLISP Manual. I
   added sections, when it seemed appropriate. I also moved code
   between sections, because sometimes functions were in the wrong
   sections.

   Almost every section contains at least one sentence describing
   what's supposed to go in there. Of course, that's not final.

   There are still functions in the wrong section, since the section
   scheme changed a few times.

7) I wrote documentation for some of the functions. There is still a
   lot of work to do, but it's a start.

8) I built Axiom using the new version. The build didn't finish, but
   it failed in the same spot as with the old one (algebra: compiling
   ahyp.spad). Cliff (CY) apparently succeeded building Axiom with the
   new file.


While literating VMLISP.LISP.PAMPHLET, I maintained a list with open questions,
suggestions, comments etc. Here it is:


1) Credits. There are a few places where credit is given to the
    contributor of a function (search for Juergen Weiss in
    VMLISP.LISP, for example). While I agree that giving proper credit
    to contributors is important, I don't think that the documentation
    chunks of individual functions are the right place. Currently
    that's not a problem since there is almost no documentation, but
    hopefully that will change. I'm not sure how to handle credits
    properly, though. Therefore I did not remove the credits given to
    Juergen in VMLISP.LISP so far.

2) Fixes and history. Some existing chunks are marked as fixes for
   specific compiler versions or contain a complete history for a tiny
   snippet of code. I believe that history belongs in the SVN/Arch/etc
   comments and fixes shouldn't be there at all. If there's a bug in
   the compiler, the compiler should be fixed. If a work-around is
   needed until the bug is removed, the fix should go as soon as the
   bug is fixed; or at least not stay indefinitely.

   For example, take a look at VMLISP.LISP:

     In GCL 2.5 there is a bug in the write-to-string function.
     It should respect *print-escape* but it does not. That is,

     ...

     <<stringimage fix>>=
     ;(define-function 'prin2cvec #'write-to-string)
     (define-function 'prin2cvec #'princ-to-string)
     ;(define-function 'stringimage #'write-to-string)
     (define-function 'stringimage #'princ-to-string)
     @

   Since we don't use GCL 2.5 anymore, why do we keep this? The
   work-around isn't bad since it doesn't really matter wether we call
   WRITE-TO-STRING with *PRINT-ESCAPE* bound to NIL or PRINC-TO-STRING
   (although the latter also binds *PRINT-READABLY* to NIL). But why
   do we keep the explanation of the problem around?

3) Obsolete code/documentation. There is a lot of code that is
   obsolete or almost obsolete. Either because it isn't used anywhere
   or because it is for the benefit of a long dead Lisp system (see
   point 4 below; also look at the 'No-ops and Constant Functions' and
   'Obsolete Functions' in VMLISP.LISP.PAMPHLET)

4) Obsolete and other *FEATURES*:
   
   - CCL (Codemist is dead/obsolete and CCL is also used by OpenMCL)
   - Lucid (dead/obsolete)
   - IBCL (dead/obsolete)
   - KCL (should be replaced with GCL)
   - CMULISP (obsolete; CMU CL does not have this in *FEATURES*)
   - ALLEGRO (is that code for Franz's Allegro CL? Does it run?)
   - ibm/370 (obsolete)
   - LispM (obsolete :-( )
   - AKCL (should be GCL)
   - RIOS (obsolete)
   - DOS (obsolete)
   - RT ?
   - oldboot ?
   - symbolics (obsolete)
   - ibmps2 (obsolete)
   - mcl (is that for Digitool's MCL or for OpenMCL?)
   - lispworks (Is that a recent addition? Does it work?)
   - cormanlisp (see lispworks)
   - clisp (see lispworks)
   - sbcl (see lispworks)
   - abcl (see lispworks)

   Conditionalized code shouldn't be sprinkled all over the place.

5) INT-CHAR isn't part of CL (see A.1.3 of the Hyperspec). Since it
   seems to work like CODE-CHAR, we should probably replace the former
   by the latter.  It is only used in two places, one of which is the
   awkwardly named EBCDIC, which isn't used very often either.

6) I'm not sure what to make of

     (defun copy (x) (copy-tree x)) ; not right since should descend vectors

   Since Axiom runs very nicely without COPY descending vectors, isn't
   that comment obsolete? How did it get there in the first place? And
   why not simply use copy-tree directly then?

7) What about the following:

     ; The following version has been provided to avoid reliance on the
     ; Common Lisp concatenate and replace functions. These built-in
     ; Lisp functions would probably end up doing the
     ; character-by-character copying shown here, but would also need to
     ; cope with generic sorts of sequences and unwarranted keyword
     ; generality

     (defun rplacstr (cvec1 start1 length1 cvec2
                            &optional start2 length2
                            &aux end1 end2)

   Is CONCATENATE really that slow? Is it still bad to depend on its
   existence?

8) What about functions/macros that have unused parameters or provide
   functionality that is somewhat esoteric and isn't used anywhere?
   For example:

     (defun MAKE-OUTSTREAM (filespec &optional (width nil) (recnum 0))
       (declare (ignore width) (ignore recnum))
         (cond ((numberp filespec) (make-synonym-stream '*terminal-io*))
           ((null filespec) (error "not handled yet"))
           (t (open (make-filename filespec) :direction :output))))

   This function is at least once called with optional arguments, but
   obviously that doesn't change anything. The method of creating a
   SYNONYM-STREAM of *TERMINAL-IO*, if passed a number, seems pretty
   insane (even though I can see where that's coming from). The same
   holds for that (NULL FILESPEC) clause.

9) There are many functions with suboptimal names. Examples:

   gensymp - checks wether its argument is an uninterned symbol

   fixp - checks for INTEGER instead of FIXNUM, unless you're running
          CCL

   LC2UC - also called UCASE and UPCASE. The latter is related to CL's
           STRING-UPCASE, but does fancy things for symbols and lists,
           and lets other atoms pass through. There should be only one
           name for this, and it shouldn't be LC2UC.

   |camlCaseName| - camel case is frowned upon in Lisp. Having to type
                    vertical bars twice for a name is awful. I
                    understand that this might be useful/necessary for
                    BOOT code, but eventually these should be changed.

   ALLCAPS - Nowadays the consensus seems to be that lowercase names
             are better. I think we should stick to that. Since the
             Lisp reader upcases everything anyway (unless it's
             surrounded by vertical bars, see above) it doesn't change
             anything.

   is-foo - ANSI CL uses a -p suffix for predicates, as in NUMBERP or
            DIGIT-CHAR-P. I believe we should stick to this. If not,
            we should at least establish a new convention. Currently
            several conventions are used (all from VMLISP.LISP):

              IS-CONSOLE
              PLACEP
              ZERO?

            I understand that even CL makes a few exceptions, but that
            doesn't imply that we have make a mess as well.

   com,mas - This is a matter of style but commas in identifiers are
             just ugly. They don't serve a purpose either.

   nohyphens - Example:

                 LISTOFFREES

               should be

                 LIST-OF-FREES

               In fact, it should be

                 list-of-frees

10) Functions as macros. There are quite a few macros that could be
   functions. They are usually made macros for performance reasons (to
   inline code). This is bad style, crippels the 'functions' and makes
   debugging hard. One could probably get the same or similar
   performance with appropriate inline declarations. Example:

     (defmacro identp (x)
       (if (atom x)
         `(and ,x (symbolp ,x))
         (let ((xx (gensym)))
           `(let ((,xx ,x))
              (and ,xx (symbolp ,xx))))))

     should be

     (declare (inline identp))
     (defun identp (x)
       (and x (symbolp x)))

   There are many similar cases (ifcar, ifcdr, eqcar, ...).

11) EVAL-WHEN. The arguments LOAD, COMPILE and EVAL are
    deprecated. They have been superseded by :LOAD-TOPLEVEL,
    :COMPILE-TOPLEVEL and :EXECUTE.

12) Packages. It is usually recommended that there is exactly one
    IN-PACKAGE form per file to avoid confusion. Since apparently the
    idea is to stuff the whole interpreter into a single pamphlet
    (exposing the hideousness of LP) I'm not sure how this
    translates.

    Usually it is also recommended to bundle functionality in
    packages. Currently that isn't done at all. There are only very
    few packages, and some of them don't serve any purpose. Again I'm
    not sure how packages work with LP.

13) (Quasi-)Aliases. There are many functions that are simply aliases
    for others. Some of them are simply created using

      (defun alias-for-foo (arg1 ... argN)
        (foo arg1 ... argN))

    Others are created using

      (define-function alias-for-foo #'foo)

    which simply sets the SYMBOL-FUNCTION of ALIAS-FOR-FOO to the
    function #'FOO.

    Sometimes these aliases don't accept all the parameters that the
    original accepted.

    Quasi-aliases are functions like

      (defun MSUBST (new old tree) (subst new old tree :test #'equal))

    that differ from their original by supplying one or more
    arguments.

    (Quasi-)Aliases should probably be replaced, unless they capture a
    concept. Suppose you store objects of type FOO as lists, and it so
    happens that two FOOs, say FOO-1 and FOO-2, are equal iff

      (equal foo-1 foo-2)

    returns T. In that case it's justified to have a function

      (equal-foo (&rest args)
        (apply #'equal args))

    Also if a (quasi-) alias captures a very common use of the underlying
    function and improves readability it can stay.

    I don't think saving key strokes is enough reason for introducing
    an alias. After all Emacs supports dynamic completion (even in
    Fundamental Mode). Other editors have similar features, I believe.

14) No-ops and constant functions. Believe it or not, but there are
    quite a few functions that literally do nothing, like

      (defun make-string (a) a)

    or

      (defmacro assemble (&rest ignore) 
        (declare (ignore ignore))
        nil)

    I reckon they should go.

16) Multiple definitions. There are multiple definitions for some
    functions, eg (in VMLISP.LISP)

    ;;--------------------> NEW DEFINITION (see unlisp.lisp.pamphlet)
    (defun |ListMember?| (ob l)
      (member ob l :test #'equal) )

    which corresponds to

    ;;--------------------> NEW DEFINITION (override in vmlisp.lisp.pamphlet)
    (defun |ListMemberQ?| (ob l)
      (member ob l :test #'eq) )

    (defun |ListMember?| (ob l)
      (member ob l :test #'equal) )

    in UNLISP.LISP. There is no ListMemberQ? in vmlisp.lisp by the
    way.

    To me it's not clear which of the two definitions is in
    effect. I'd have to look into the appropriate Makefile, I
    guess. Why not just get rid of the obsolete definition?

    This case is particularly interesting, as both definition are
    equivalent.

18) Gensyms. In macros you use GENSYM to generate unique symbols to
    avoid name clashes with user defined symbols. This shouldn't be
    done by hand, though. Instead a macro like WITH-UNIQUE-NAMES or
    WITH-GENSYMS ought to be used.


Kai


--=-=-=

XGRvY3VtZW50Y2xhc3N7YXJ0aWNsZX0KXHVzZXBhY2thZ2V7YXhpb219ClxiZWdpbntkb2N1bWVu
dH0KXHRpdGxle1wkU1BBRC9zcmMvaW50ZXJwIHZtbGlzcC5saXNwfQpcYXV0aG9ye0xhcnMgRXJp
Y3NvbiwgQmFycnkgVHJhZ2VyLCBNYXJ0aWFsIFNjaG9yLCBUaW1vdGh5IERhbHl9ClxtYWtldGl0
bGUKXGJlZ2lue2Fic3RyYWN0fQpcZW5ke2Fic3RyYWN0fQpcZWplY3QKXHRhYmxlb2Zjb250ZW50
cwoKXHNlY3Rpb257R2xvYmFsIFZhcmlhYmxlc30KXGxhYmVse3NlYzpHbG9iYWxWYXJpYWJsZXN9
CgpUaGlzIHNlY3Rpb24gbGlzdHMgYWxsIGdsb2JhbCB2YXJpYWJsZXMgZGVjbGFyZWQgaW4KW1tW
TUxJU1AuTElTUC5QQU1QSExFVF1dIHRvZ2V0aGVyIHdpdGggYSBzaG9ydCBleHBsYW5hdGlvbi4g
QSBkZXRhaWxlZApkZXNjcmlwdGlvbiBjYW4gYmUgZm91bmQgaW4gdGhlIGFwcHJvcHJpYXRlIHNl
Y3Rpb25zLgoKPDxjb21wMzcwLWFwcGx5Pj49CihkZWZ2YXIgKmNvbXAzNzAtYXBwbHkqIG5pbCAi
ZnVuY3Rpb24gKG5hbWUgZGVmKSBmb3IgY29tcDM3MCB0byBhcHBseSIpCkAKCjw8Y3VyaW5vdXRz
dHJlYW0+Pj0KKGRlZnZhciBjdXJpbnN0cmVhbSAobWFrZS1zeW5vbnltLXN0cmVhbSAnKnN0YW5k
YXJkLWlucHV0KikpCgooZGVmdmFyIGN1cm91dHN0cmVhbSAobWFrZS1zeW5vbnltLXN0cmVhbSAn
KnN0YW5kYXJkLW91dHB1dCopKQpACgo8PGVycm9yaW5vdXRzdHJlYW0+Pj0KKGRlZnZhciBlcnJv
cmluc3RyZWFtIChtYWtlLXN5bm9ueW0tc3RyZWFtICcqdGVybWluYWwtaW8qKSkKCihkZWZ2YXIg
ZXJyb3JvdXRzdHJlYW0gKG1ha2Utc3lub255bS1zdHJlYW0gJyp0ZXJtaW5hbC1pbyopKQpACgo8
PCplbWJlZGRlZC1mdW5jdGlvbnMqPj49CihkZWZ2YXIgKmVtYmVkZGVkLWZ1bmN0aW9ucyogbmls
KQpACgo8PCpsYW0tbmFtZSo+Pj0KKGRlZnZhciAqbGFtLW5hbWUqIG5pbCAibmFtZSB0byBiZSB1
c2VkIGJ5IGxhbSBtYWNybyBpZiBub24tbmlsIikKQAoKPDwqcmVhZC1wbGFjZS1ob2xkZXIqPj49
CihkZWZ2YXIgKnJlYWQtcGxhY2UtaG9sZGVyKiAobWFrZS1zeW1ib2wgIiUuRU9GIikKICAgImRl
ZmF1bHQgdmFsdWUgcmV0dXJuZWQgYnkgcmVhZCBhbmQgcmVhZC1saW5lIGF0IGVuZC1vZi1maWxl
IikKQAoKVGhpcyB2YXJpYWJsZSBzaG91bGQgbXVzdCBjb250YWluIGVpdGhlciBbW05JTF1dIG9y
IGEgZnVuY3Rpb24uIElmIGl0CmNvbnRhaW5zIGEgZnVuY3Rpb24sIGl0IGlzIGNhbGxlZCBieSBb
W0xBTVwsRklMRUFDVFFdXS4KPDxmaWxlYWN0cS1hcHBseT4+PQooZGVmdmFyICpmaWxlYWN0cS1h
cHBseSogbmlsICJmdW5jdGlvbiB0byBhcHBseSBpbiBmaWxlYWN0cSIpCkAKClRoZSB2YXJpYWJs
ZSBbW21hY2Vycm9yY291bnRdXSBjb250YWlucyB0aGUgbnVtYmVyIG9mIHRpbWVzIHRoYXQgb25l
Cm9mIHRoZSBmdW5jdGlvbnMgW1ttYWNyby1pbnZhbGlkYXJnc11dLCBbW21hY3JvLW1pc3Npbmdh
cmdzXV0gb3IKW1ttYWNlcnJdXSBoYXMgYmVlbiBjYWxsZWQuIFNpbmNlIGl0IGlzIG5ldmVyIHJl
YWQsIGl0J3MgcHJvYmFibHkKb2Jzb2xldGUuCjw8bWFjZXJyb3Jjb3VudD4+PQooZGVmdmFyIG1h
Y2Vycm9yY291bnQgMCAgIlB1dCBzb21lIGRvY3VtZW50YXRpb24gaW4gaGVyZSBzb21lZGF5IikK
QAoKXHNlY3Rpb257TWFjcm9sb2d5IGFuZCBEZWZpbmluZyBPcGVyYXRvcnN9ClxsYWJlbHtzZWM6
TWFjcm9sb2d5QW5kRGVmaW5pbmdPcGVyYXRvcnN9CgpUaGlzIHNlY3Rpb24gaW50cm9kdWNlcyBh
IG51bWJlciBvZiBmdW5jdGlvbnMgYW5kIG1hY3JvcyB0aGF0IGFyZSB1c2VkCnRvIGRlZmluZSBv
dGhlciBtYWNyb3MgYW5kIGZ1bmN0aW9ucyBpbiB0aGlzIGRvY3VtZW50LgoKCkRlZmluZXMgYSBn
bG9iYWwgYWxpYXMgZm9yIGFuIGV4aXN0aW5nIGZ1bmN0aW9ucy4KPDxkZWZpbmUtZnVuY3Rpb24+
Pj0KIy0ob3IgOkNDTCAoYW5kIDpMdWNpZCAobm90IDpyaW9zKSkpCihkZWZ1biBkZWZpbmUtZnVu
Y3Rpb24gKGYgdikKIChzZXRmIChzeW1ib2wtZnVuY3Rpb24gZikgdikpCiMrOkNDTAooZGVmdW4g
ZGVmaW5lLWZ1bmN0aW9uIChmIHYpCiAoc2V0ZiAoc3ltYm9sLWZ1bmN0aW9uIGYpIHYpCiAoc2V0
ZiAoZ2V0IGYgJ3M6bmV3bmFtZSkgdikpCkAKCjw8bWRlZj4+PQo7IEJlYXRzIG1lIGhvdyB0byBz
aW11bGF0ZSBtYWNybyBleHBhbnNpb24gImluIHRoZSBlbnZpcm9ubWVudCBvZiBzZCIuLi46Cgoo
ZGVmdW4gTURFRiAoYXJnIGl0ZW0gJm9wdGlvbmFsIHNkKQogKGRlY2xhcmUgKGlnbm9yZSBzZCkp
CiAgKG1hY3JvZXhwYW5kIGAoLGFyZyAsaXRlbSkpKQpACgo8PGRlZmluZS1tYWNybz4+PQojLUx1
Y2lkCihkZWZtYWNybyBkZWZpbmUtbWFjcm8gKGYgdikKIGAoc2V0ZiAobWFjcm8tZnVuY3Rpb24g
LGYpIChtYWNyby1mdW5jdGlvbiAsdikpKQpACgo8PG1hY3JvLWludmFsaWRhcmdzPj49CihkZWZ1
biBNQUNSTy1JTlZBTElEQVJHUyAoTkFNRSBGT1JNIE1FU1NBR0UpCiAgICAoc2V0cSBNQUNFUlJP
UkNPVU5UICAoKyAxIChldmFsICdNQUNFUlJPUkNPVU5UKSkpCiAgICAoZXJyb3IgKGZvcm1hdCBu
aWwgCiAgICAgICAgICAgICAgICAgICAiaW52YWxpZCBhcmd1bWVudHMgdG8gbWFjcm8gflMgd2l0
aCBpbnZhbGlkIGFyZ3VtZW50IH5TLCB+UyIKICAgICAgICAgICAgICAgICAgIG5hbWUgZm9ybSBt
ZXNzYWdlKSkpCkAKCjw8bWFjcm8tbWlzc2luZ2FyZ3M+Pj0KKGRlZnVuIE1BQ1JPLU1JU1NJTkdB
UkdTIChOQU1FIGlnbm9yZSBOKQogIChkZWNsYXJlIChpZ25vcmUgaWdub3JlKSkKICAoc2V0cSBN
QUNFUlJPUkNPVU5UICgrIDEgKGV2YWwgJ01BQ0VSUk9SQ09VTlQpKSkKICAoZXJyb3IgKGNvbmNh
dGVuYXRlICdzdHJpbmcgKHN5bWJvbC1uYW1lIE5BTUUpICIgcmVxdWlyZXMgIgogICAgICAgICAg
ICAgICAgICAgICAgIChpZiAobWludXNwIE4pICJhdCBsZWFzdCAiICJleGFjdGx5ICIpCiAgICAg
ICAgICAgICAgICAgICAgICAgKHNldHEgTiAoYWJzIE4pKQogICAgICAgICAgICAgICAgICAgICAg
IChjYXNlIE4gKDAgIm5vIikgKDEgIm9uZSIpICgyICJ0d28iKSAoMyAidGhyZWUiKQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICg0ICJmb3VyIikgKDUgImZpdmUiKSAoNiAic2l4IikKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAodCAocHJpbmMtdG8tc3RyaW5nIE4pKSkKICAgICAg
ICAgICAgICAgICAgICAgICAoaWYgKGVxIG4gMSkgIiBhcmd1bWVudCwiICIgYXJndW1lbnRzLCIp
KSkpCkAKCjw8bWFjZXJyPj49CihkZWZ1biBNQUNFUlIgKE1FU1NBR0UgJnJlc3QgaWdub3JlKQog
IChkZWNsYXJlIChpZ25vcmUgaWdub3JlKSkKICAgICAgKHNldHEgTUFDRVJST1JDT1VOVCAoKyAx
IChldmFsICdNQUNFUlJPUkNPVU5UKSkpCiAgICAgIChlcnJvcgogICAgICAgIChMSVNUICJpbiB0
aGUgZXhwcmVzc2lvbjoiIE1FU1NBR0UpKQogICAgICAoKSkKQAoKXHNlY3Rpb257R2FyYmFnZSBD
b2xsZWN0aW9ufQpcbGFiZWx7c2VjOkdhcmJhZ2VDb2xsZWN0aW9ufQoKPDx0b3RhbC1nYy10aW1l
Pj49CiMtKE9SIElCQ0wgS0NMIDpDTVVMSVNQIDpDQ0wpCihkZWZ1biAkVE9UQUwtR0MtVElNRSAo
KSAobGlzdCAwIDApKQoKIys6Q0NMCihkZWZ1biAkVE9UQUwtR0MtVElNRSAoKSAobGlzdCAoZ2N0
aW1lKSAoZ2N0aW1lKSkpCgojK0lCQ0wKKGRlZnVuICRUT1RBTC1HQy1USU1FICgmYXV4IChnY3J1
bnRpbWUgKHN5c3RlbTpnYmMtdGltZS1yZXBvcnQpKSkKICAobGlzdCBnY3J1bnRpbWUgZ2NydW50
aW1lKSkKCiMrS0NMCihkZWZ1biAkVE9UQUwtR0MtVElNRSAoJmF1eCAoZ2NydW50aW1lIChzeXN0
ZW06Z2JjLXRpbWUpKSkKICAoaWYgKG1pbnVzcCBnY3J1bnRpbWUpCiAgICAgIChzZXRxIGdjcnVu
dGltZSAoc3lzdGVtOmdiYy10aW1lIDApKSkKICAobGlzdCBnY3J1bnRpbWUgZ2NydW50aW1lKSkK
Cjs7OyBub3RlOiB0aGlzIHJlcXVpcmVzIHRoZSAxMS85Lzg5IGdjIHBhdGNoIGluIGNvZGUvbGlz
cC9kYWx5L21pc2MubGlzcAojKzpjbXVsaXNwCihkZWZ1biAkVE9UQUwtR0MtVElNRSAoKQogKGRl
Y2xhcmUgKHNwZWNpYWwgZXh0OjoqZ2MtcnVudGltZSogZXh0OjoqZ2Mtd2FsbHRpbWUqKSkKIChs
aXN0IGV4dDo6KmdjLXJ1bnRpbWUqIGV4dDo6KmdjLXdhbGx0aW1lKikpCkAKCjw8Z2MtdmVyYm9z
aXR5Pj49CiMrTHVjaWQKKGRlZnVuIGdjbXNnICh4KQogICAocHJvZzEgKG5vdCBzeXN0ZW06Oipn
Yy1zaWxlbmNlKikgKHNldHEgc3lzdGVtOjoqZ2Mtc2lsZW5jZSogKG5vdCB4KSkpKQojKyhPUiBJ
QkNMIEtDTCkKKGRlZnVuIGdjbXNnICh4KQogICAocHJvZzEgc3lzdGVtOipnYmMtbWVzc2FnZSog
KHNldHEgc3lzdGVtOipnYmMtbWVzc2FnZSogeCkpKQojKzpjbXVsaXNwCihkZWZ1biBnY21zZyAo
eCkKICAgKHByb2cxIGV4dDoqZ2MtdmVyYm9zZSogKHNldHEgZXh0OipnYy12ZXJib3NlKiB4KSkp
CiMrOmFsbGVncm8KKGRlZnVuIGdjbXNnICh4KSkKQAoKPDxyZWNsYWltPj49CiMrTHVjaWQKKGRl
ZnVuIHJlY2xhaW0gKCkgKHN5c3RlbTpnYykpCiMrOmNtdWxpc3AKKGRlZnVuIHJlY2xhaW0gKCkg
KGV4dDpnYykpCiMrKE9SIElCQ0wgS0NMKQooZGVmdW4gcmVjbGFpbSAoKSAoZ2JjIHQpKQojKzph
bGxlZ3JvCihkZWZ1biByZWNsYWltICgpIChleGNsOjpnYyB0KSkKIys6Q0NMCihkZWZ1biByZWNs
YWltICgpIChnYykpCkAKClxzZWN0aW9ue1N0cmVhbXN9ClxsYWJlbHtzZWM6U3RyZWFtc30KClRo
aXMgc2VjdGlvbiBjb250YWlucyBtb3N0IGZ1bmN0aW9ucyB0aGF0IGFyZSByZWxhdGVkIHRvIHN0
cmVhbQpJTy4gQW1vbmcgdGhlIGV4Y2VwdGlvbnMgYXJlIHRoZSBmdW5jdGlvbnMgaW4KXHJlZntz
ZWM6UmVhZGluZ0FuZFByaW50aW5nfS4KClxzdWJzZWN0aW9ue0NyZWF0aW9ufQpcbGFiZWx7c2Vj
OlN0cmVhbXNDcmVhdGlvbn0KClRoZSBuZXh0IHR3byBmdW5jdGlvbnMgYXJlIHVzZWQgdG8gb3Bl
biBpbnB1dC9vdXRwdXQgc3RyZWFtcyB0byBhIGZpbGUKb3IgYSBzeW5vbnltIHN0cmVhbSB0byBb
WypURVJNSU5BTC1JTypdXS4gVGhlIG9wdGlvbmFsIGFyZ3VtZW50cyBhcmUKaWdub3JlZC4KPDxt
YWtlLWlub3V0LXN0cmVhbT4+PQooZGVmdW4gTUFLRS1JTlNUUkVBTSAoZmlsZXNwZWMgJm9wdGlv
bmFsIChyZWNudW0gMCkpCiAoZGVjbGFyZSAoaWdub3JlIHJlY251bSkpCiAgIChjb25kICgobnVt
YmVycCBmaWxlc3BlYykgKG1ha2Utc3lub255bS1zdHJlYW0gJyp0ZXJtaW5hbC1pbyopKQogICAg
ICAgICAoKG51bGwgZmlsZXNwZWMpIChlcnJvciAibm90IGhhbmRsZWQgeWV0IikpCiAgICAgICAg
ICh0IChvcGVuIChtYWtlLWlucHV0LWZpbGVuYW1lIGZpbGVzcGVjKQogICAgICAgICAgICAgICAg
ICA6ZGlyZWN0aW9uIDppbnB1dCA6aWYtZG9lcy1ub3QtZXhpc3QgbmlsKSkpKQoKKGRlZnVuIE1B
S0UtT1VUU1RSRUFNIChmaWxlc3BlYyAmb3B0aW9uYWwgKHdpZHRoIG5pbCkgKHJlY251bSAwKSkK
IChkZWNsYXJlIChpZ25vcmUgd2lkdGgpIChpZ25vcmUgcmVjbnVtKSkKICAgKGNvbmQgKChudW1i
ZXJwIGZpbGVzcGVjKSAobWFrZS1zeW5vbnltLXN0cmVhbSAnKnRlcm1pbmFsLWlvKikpCiAgICAg
ICAgICgobnVsbCBmaWxlc3BlYykgKGVycm9yICJub3QgaGFuZGxlZCB5ZXQiKSkKICAgICAgICAg
KHQgKG9wZW4gKG1ha2UtZmlsZW5hbWUgZmlsZXNwZWMpIDpkaXJlY3Rpb24gOm91dHB1dCkpKSkK
QAoKCjw8bWFrZS1hcHBlbmRzdHJlYW0+Pj0KKGRlZnVuIE1BS0UtQVBQRU5EU1RSRUFNIChmaWxl
c3BlYyAmb3B0aW9uYWwgKHdpZHRoIG5pbCkgKHJlY251bSAwKSkKICJmb3J0cmFuIHN1cHBvcnQi
CiAoZGVjbGFyZSAoaWdub3JlIHdpZHRoKSAoaWdub3JlIHJlY251bSkpCiAoY29uZCAKICAoKG51
bWJlcnAgZmlsZXNwZWMpIChtYWtlLXN5bm9ueW0tc3RyZWFtICcqdGVybWluYWwtaW8qKSkKICAo
KG51bGwgZmlsZXNwZWMpIChlcnJvciAibWFrZS1hcHBlbmRzdHJlYW06IG5vdCBoYW5kbGVkIHll
dCIpKQogICgnZWxzZSAob3BlbiAobWFrZS1maWxlbmFtZSBmaWxlc3BlYykgOmRpcmVjdGlvbiA6
b3V0cHV0CiAgICAgICAgICA6aWYtZXhpc3RzIDphcHBlbmQgOmlmLWRvZXMtbm90LWV4aXN0IDpj
cmVhdGUpKSkpCkAKClRoZSBmdW5jdGlvbiBbW0RFRklPU1RSRUFNXV0gb3BlbnMgYSBzdHJlYW0g
YXMgc3BlY2lmaWVkIGJ5Cltbc3RyZWFtLWFsaXN0XV0sIGFuZCBpZiB0aGUgc3RyZWFtIGlzIGNv
bm5lY3RlZCB0byBhIGZpbGUsIHRoZQpbW0ZJTEUtUE9TSVRJT05dXSBpcyBzZXQgdG8gW1tDSEFS
LVBPU0lUSU9OXV0uCgpUaGUgZnVuY3Rpb24gbG9va3MgZm9yIHRoZSBrZXlzIFtbTU9ERV1dLCBb
W0ZJTEVdXSBhbmQgW1tERVZJQ0VdXSBvbgpbW1NUUkVBTS1BTElTVF1dLCB3aG9zZSB2YWx1ZXMg
YXJlIGludGVycHJldGVkIGFzIGZvbGxvd3M6CgpJZiBbW0RFVklDRV1dIGhhcyBhIHZhbHVlIG9m
IFtbJ0NPTlNPTEVdXSwgdGhlbiB0aGUgY3JlYXRlZCBzdHJlYW0gaXMKYSBzeW5vbnltIHN0cmVh
bSBvZiBbWypURVJNSU5BTC1JTypdXSBhbmQgdGhlIHJlc3Qgb2YgW1tTVFJFQU0tQUxJU1RdXQpp
cyBpZ25vcmVkLiBPdGhlcndpc2UgW1tERVZJQ0VdXSBpcyBpZ25vcmVkLgoKW1tNT0RFXV0gY2Fu
IGhhdmUgYXMgaXRzIHZhbHVlIG9uZSBvZiBbWydPVVRQVVRdXSxbWydPXV0sIFtbJ0lOUFVUXV0s
CltbJ0ldXSB3aXRoIHRoZSBvYnZpb3VzIG1lYW5pbmcuIElmIGl0J3MgbWlzc2luZyBmcm9tIFtb
U1RSRUFNLUFMSVNUXV0sCnRoZW4gYSBkZWZhdWx0IG9mIFtbJ0lOUFVUXV0gaXMgdXNlZC4KCltb
RklMRV1dIG11c3QgaGF2ZSBhIHZhbHVlIHVubGVzcyB0aGUgdmFsdWUgb2YgW1tERVZJQ0VdXSBp
cwpbWydDT05TT0xFXV0uIFRoZSB2YWx1ZSBpbmRpY2F0ZXMgdGhlIGZpbGVuYW1lIGlzIHVzZWQg
YXMgYW4gYXJndW1lbnQKdG8gW1tNQUtFLUZJTEVOQU1FXV0gKHNlZSBbW25saWIubGlzcF1dKS4K
Cjw8ZGVmaW9zdHJlYW0+Pj0KKGRlZnVuIERFRklPU1RSRUFNIChzdHJlYW0tYWxpc3QgYnVmZmVy
LXNpemUgY2hhci1wb3NpdGlvbikKIChkZWNsYXJlIChpZ25vcmUgYnVmZmVyLXNpemUpKQogICAo
bGV0ICgobW9kZSAob3IgKGNkciAoYXNzb2MgJ01PREUgc3RyZWFtLWFsaXN0KSkgJ0lOUFVUKSkK
ICAgICAgICAgKGZpbGVuYW1lIChjZHIgKGFzc29jICdGSUxFIHN0cmVhbS1hbGlzdCkpKQogICAg
ICAgICAoZGV2IChjZHIgKGFzc29jICdERVZJQ0Ugc3RyZWFtLWFsaXN0KSkpKQogICAgICAoaWYg
KEVRIGRldiAnQ09OU09MRSkgKG1ha2Utc3lub255bS1zdHJlYW0gJyp0ZXJtaW5hbC1pbyopCgko
bGV0ICgoc3RybSAoY2FzZSBtb2RlCgkJCSAgKChPVVRQVVQgTykgKG9wZW4gKG1ha2UtZmlsZW5h
bWUgZmlsZW5hbWUpCgkJCQkJICAgIDpkaXJlY3Rpb24gOm91dHB1dCkpCgkJCSAgKChJTlBVVCBJ
KSAob3BlbiAobWFrZS1pbnB1dC1maWxlbmFtZSBmaWxlbmFtZSkKCQkJCQkgICA6ZGlyZWN0aW9u
IDppbnB1dCkpKSkpCgkgIChpZiAoYW5kIChudW1iZXJwIGNoYXItcG9zaXRpb24pICg+IGNoYXIt
cG9zaXRpb24gMCkpCgkgICAgICAoZmlsZS1wb3NpdGlvbiBzdHJtIGNoYXItcG9zaXRpb24pKQoJ
ICBzdHJtKSkpKQpACgpcc3Vic2VjdGlvbntBY2Nlc3N9ClxsYWJlbHtzZWM6U3RyZWFtc0FjY2Vz
c30KCk9idmlvdXMuCjw8ZW9mcD4+PQooZGVmdW4gRU9GUCAoc3RyZWFtKQogIChudWxsIChwZWVr
LWNoYXIgbmlsIHN0cmVhbSBuaWwgbmlsKSkpCkAKClxzdWJzZWN0aW9ue1VwZGF0aW5nfQpcbGFi
ZWx7c2VjOlN0cmVhbXNVcGRhdGluZ30KCjw8c2h1dD4+PQooZGVmdW4gc2h1dCAoc3QpIChpZiAo
aXMtY29uc29sZSBzdCkgc3QKCQkgICAoaWYgKHN0cmVhbXAgc3QpIChjbG9zZSBzdCkgLTEpKSkK
QAoKClxzdWJzZWN0aW9ue01pc2NlbGxhbmVvdXN9ClxsYWJlbHtzZWM6U3RyZWFtc01pc2NlbGxh
bmVvdXN9Cgo8PGlzLWNvbnNvbGU+Pj0KIytMdWNpZAooZGVmdW4gSVMtQ09OU09MRSAoc3RyZWFt
KQogICAgKGFuZCAoc3RyZWFtcCBzdHJlYW0pCiAgICAgICAgIChvciAobm90IChjb25zcCAocGF0
aG5hbWUtZGlyZWN0b3J5IHN0cmVhbSkpKQogICAgICAgICAgICAgKGVxdWFsIChxY2FyIChwYXRo
bmFtZS1kaXJlY3Rvcnkgc3RyZWFtKSkgImRldiIpCgkgICAgIChudWxsIChwYXRobmFtZS1uYW1l
IHN0cmVhbSkgKSkpKQoKIytLQ0wKKGRlZnVuIElTLUNPTlNPTEUgKHN0cmVhbSkKICAoYW5kIChz
dHJlYW1wIHN0cmVhbSkgKG91dHB1dC1zdHJlYW0tcCBzdHJlYW0pCiAgICAgICAoZXEgKHN5c3Rl
bTpmcC1vdXRwdXQtc3RyZWFtIHN0cmVhbSkKICAgICAgICAgICAoc3lzdGVtOmZwLW91dHB1dC1z
dHJlYW0gKnRlcm1pbmFsLWlvKikpKSkKCiMtKE9SIEx1Y2lkIEtDTCA6Q0NMKQooZGVmdW4gSVMt
Q09OU09MRSAoc3RyZWFtKSAoRVEgc3RyZWFtICp0ZXJtaW5hbC1pbyopKQpACgpUaGUgZm9sbG93
aW5nIGNodW5rIHNob3VsZCBiZSBzcGxpdCB1cCBhbmQgZ28gaW50byBccmVme3NlYzpSZWFkaW5n
QW5kUHJpbnRpbmd9Lgo8PHNob2UtaW8+Pj0KKGRlZm1hY3JvIHxzaG9lQ29uc29sZXwgKGxpbmUp
CiBgKHdyaXRlLWxpbmUgLGxpbmUgKnRlcm1pbmFsLWlvKikpCgooZGVmbWFjcm8gfHNob2VJbnB1
dEZpbGV8IChmaWxlc3BlYykKIGAob3BlbiAsZmlsZXNwZWMgOmRpcmVjdGlvbiA6aW5wdXQgOmlm
LWRvZXMtbm90LWV4aXN0IG5pbCkpCgooZGVmbWFjcm8gfHNob2VyZWFkLWxpbmV8IChzdCkKIGAo
cmVhZC1saW5lICxzdCBuaWwgbmlsKSkKQAoKXHNlY3Rpb257UmVhZGluZyBhbmQgUHJpbnRpbmd9
ClxsYWJlbHtzZWM6UmVhZGluZ0FuZFByaW50aW5nfQoKVGhlIGZvbGxvd2luZyB0d28gZnVuY3Rp
b25zIGFyZSBub3Qgb25seSBhd2Z1bGx5IHNpbWlsYXIsIHRoZXkgYXJlCmFsc28gcHJldHR5IHVz
ZWxlc3MuIFRoZXkgYXJlbid0IGNhbGxlZCB2ZXJ5IG9mdGVuLiBJIGd1ZXNzIHRoZXkKc2hvdWxk
IGdvLgo8PHZtcmVhZD4+PQooZGVmdW4gVk1SRUFEICgmb3B0aW9uYWwgKHN0ICpzdGFuZGFyZC1p
bnB1dCopIChlb2Z2YWwgKnJlYWQtcGxhY2UtaG9sZGVyKikpCiAgKHJlYWQgc3QgbmlsIGVvZnZh
bCkpCkAKCjw8fHJlYWQtbGluZXw+Pj0KKGRlZnVuIHxyZWFkLWxpbmV8IChzdCAmb3B0aW9uYWwg
KGVvZnZhbCAqcmVhZC1wbGFjZS1ob2xkZXIqKSkKICAocmVhZC1saW5lIHN0IG5pbCBlb2Z2YWwp
KQpACgpUaGUgZnVuY3Rpb24gW1tQUkVUVFlQUklOMF1dIGlzIGFjdHVhbGx5IHVzZWQgb3V0c2lk
ZQpbW1BSRVRUWVBSSU5UXV0sIGJ1dCBvbmx5IG9uY2UuIE1heWJlIGl0IHNob3VsZCBnbywgb3Ig
YXQgbGVhc3QgZ2V0IGEKYmV0dGVyIG5hbWUuCjw8cHJldHR5cHJpbnQ+Pj0KKGRlZnVuIHByZXR0
eXByaW50ICh4ICZvcHRpb25hbCAoc3RyZWFtICpzdGFuZGFyZC1vdXRwdXQqKSkKICAocHJldHR5
cHJpbjAgeCBzdHJlYW0pICh0ZXJwcmkgc3RyZWFtKSkKCihkZWZ1biBwcmV0dHlwcmluMCAoeCAm
b3B0aW9uYWwgKHN0cmVhbSAqc3RhbmRhcmQtb3V0cHV0KikpCiAgKGxldCAoKCpwcmludC1wcmV0
dHkqIHQpICgqcHJpbnQtYXJyYXkqIHQpKQogICAgKHByaW4xIHggc3RyZWFtKSkpCkAKCjw8fGYs
cHJpbnQtb25lfD4+PQooZGVmdW4gfEYsUFJJTlQtT05FfCAoZm9ybSAmb3B0aW9uYWwgKHN0cmVh
bSAqc3RhbmRhcmQtb3V0cHV0KikpCiAoZGVjbGFyZSAoaWdub3JlIHN0cmVhbSkpCiAgICAobGV0
ICgoKnByaW50LWxldmVsKiA0KSAoKnByaW50LWxlbmd0aCogNCkpCiAgICAgICAocHJpbjEgZm9y
bSkgKHRlcnByaSkpKQpACgo8PHZtcHJpbnQ+Pj0KKGRlZnVuIHZtcHJpbnQgKHggJm9wdGlvbmFs
IChzdHJlYW0gKnN0YW5kYXJkLW91dHB1dCopKQogIChwcmluMSB4IHN0cmVhbSkgKHRlcnByaSBz
dHJlYW0pKQpACgo8PHRhYj4+PQooZGVmdW4gdGFiIChzaW50ICZvcHRpb25hbCAoc3RyZWFtIHQp
KQogIChmb3JtYXQgc3RyZWFtICJ+dlQiIHNpbnQpKQpACgpcc3Vic2VjdGlvbntUaGUgU3RyaW5n
SW1hZ2UgRml4fQpJbiBHQ0wgMi41IHRoZXJlIGlzIGEgYnVnIGluIHRoZSB3cml0ZS10by1zdHJp
bmcgZnVuY3Rpb24uCkl0IHNob3VsZCByZXNwZWN0ICpwcmludC1lc2NhcGUqIGJ1dCBpdCBkb2Vz
IG5vdC4gVGhhdCBpcywKXGJlZ2lue3ZlcmJhdGltfQpJbiBHQ0wgMi40LjE6CihzZXRxICpwcmlu
dC1lc2NhcGUqIG5pbCkKKHdyaXRlLXRvLXN0cmluZyAnfGF8KSA9PT4gImEiCgpJbiBHQ0wgMi41
Ogooc2V0cSAqcHJpbnQtZXNjYXBlKiBuaWwpCih3cml0ZS10by1zdHJpbmcgJ3xhfCkgPT0+ICJ8
YXwiClxlbmR7dmVyYmF0aW19CgpUaGUgZm9ybTJMaXNwU3RyaW5nIGZ1bmN0aW9uIHVzZXMgc3Ry
aW5naW1hZ2UgYW5kIGZhaWxzLgpUaGUgcHJpbmMtdG8tc3RyaW5nIGZ1bmN0aW9uIGFzc3VtZXMg
KnByaW50LWVzY2FwZSogaXMgbmlsCmFuZCB3b3JrcyBwcm9wZXJseS4KCjw8c3RyaW5naW1hZ2Ug
Zml4Pj49CjsoZGVmaW5lLWZ1bmN0aW9uICdwcmluMmN2ZWMgIyd3cml0ZS10by1zdHJpbmcpCihk
ZWZpbmUtZnVuY3Rpb24gJ3ByaW4yY3ZlYyAjJ3ByaW5jLXRvLXN0cmluZykKOyhkZWZpbmUtZnVu
Y3Rpb24gJ3N0cmluZ2ltYWdlICMnd3JpdGUtdG8tc3RyaW5nKQooZGVmaW5lLWZ1bmN0aW9uICdz
dHJpbmdpbWFnZSAjJ3ByaW5jLXRvLXN0cmluZykKQAoKXHNlY3Rpb257T1MgSW50ZXJmYWNlfQpc
bGFiZWx7c2VjOk9TSW50ZXJmYWNlfQoKPDxnZXRDRD4+PQo7IENvbnRyaWJ1dGVkIGJ5IEp1ZXJn
ZW4gV2Vpc3MuCiMrOmNtdQooZGVmdW4gZ2V0LWN1cnJlbnQtZGlyZWN0b3J5ICgpCiAgKG5hbWVz
dHJpbmcgKGV4dGVuc2lvbnM6OmRlZmF1bHQtZGlyZWN0b3J5KSkpCgojKyhvciA6YWtjbCA6Z2Ns
KQooZGVmdW4gZ2V0LWN1cnJlbnQtZGlyZWN0b3J5ICgpCiAgKG5hbWVzdHJpbmcgKHRydWVuYW1l
ICIiKSkpCkAKCjw8b2JleT4+PQojKyhhbmQgOkx1Y2lkIChub3QgOmlibS8zNzApKQooZGVmdW4g
T0JFWSAoUykKICAoc3lzdGVtOjpydW4tYWl4LXByb2dyYW0gKG1ha2UtYWJzb2x1dGUtZmlsZW5h
bWUgIi9saWIvb2JleSIpCgkJICAgICAgIDphcmd1bWVudHMJKGxpc3QgIi1jIiBTKSkpCiMrOmNt
dWxpc3AKKGRlZnVuIE9CRVkgKFMpCiAgIChleHQ6cnVuLXByb2dyYW0gKG1ha2UtYWJzb2x1dGUt
ZmlsZW5hbWUgIi9saWIvb2JleSIpCgkJICAgIChsaXN0ICItYyIgUykgOmlucHV0IHQgOm91dHB1
dCB0KSkKIysoT1IgSUJDTCBLQ0wgOkNDTCkKKGRlZnVuIE9CRVkgKFMpIChTWVNURU0gUykpCgoj
KzphbGxlZ3JvCihkZWZ1biBPQkVZIChTKSAoZXhjbDo6cnVuLXNoZWxsLWNvbW1hbmQgcykpCkAK
ClRoZSBbWyRTQ1JFRU5TSVpFXV0gZnVuY3Rpb24gaXMgcmVhbGx5IGEgY29uc3RhbnQgYW5kIGhh
cyBub3RoaW5nIHRvCmRvIHdpdGggdGhlIE9TLCBidXQgaXQgbWlnaHQgYmUgYSBnb29kIGlkZWEg
dG8gcmVwbGFjZSBpdCB3aXRoCnNvbWV0aGluZyB0aGF0IGFjdHVhbGx5IHRhbGtzIHRvIHRoZSBP
UyB0byBnZXQgdGhlIHNpemUgb2YgdGhlIHNjcmVlbi4KPDxzY3JlZW5zaXplPj49CihkZWZ1biAk
c2NyZWVuc2l6ZSAoKSAnKDI0IDgwKSkgICAgICAgICAgOyBZb3UgdGVsbCBtZSEhCkAKClxzZWN0
aW9ue09wZXJhdG9yIERlZmluaXRpb24gYW5kIFRyYW5zZm9ybWF0aW9ufQpcbGFiZWx7c2VjOk9w
ZXJhdG9yRGVmaW5pdGlvbkFuZFRyYW5zZm9ybWF0aW9ufQoKPDxjb21wMzcwPj49CihkZWZ1biBD
T01QMzcwIChmbmxpc3QpCiAgKGNvbmQgKChhdG9tIChjYXIgZm5saXN0KSkgKGxpc3QgKENPTVBJ
TEUxIGZubGlzdCkpKQogICAgICAgICh0IChNQVBDQVIgIycobGFtYmRhICh4KSAoQ09NUElMRTEg
eCkpIGZubGlzdCkpKSkKQAoKPDxjb21waWxlMT4+PQojKzpDQ0wgKHByb2NsYWltICcoc3BlY2lh
bCAqdmFycyogKmRlY2wqKSkgOzsgZGVjbGFyZSBub3QgaGFuZGxlZCByaWdodAoKKGRlZnVuIENP
TVBJTEUxIChmbikKICAobGV0KiAobmFyZ3MKICAgICAgICAgKGZuYW1lIChjYXIgZm4pKQogICAg
ICAgICAobGFtZGEgKGNhZHIgZm4pKQogICAgICAgICAobHR5cGUgKGNhciBsYW1kYSkpCiAgICAg
ICAgICp2YXJzKiAqZGVjbCogYXJncwogICAgICAgICAoYm9keSAoY2RkciBsYW1kYSkpKQogICAg
KGRlY2xhcmUgKHNwZWNpYWwgKnZhcnMqICpkZWNsKikpCiAgICAoaWYgKGVxIGx0eXBlICdMQU0p
CiAgICAgICAgKGxldCAoKCpsYW0tbmFtZSogKGludGVybiAoY29uY2F0IGZuYW1lICJcLExBTSIp
KSkpCiAgICAgICAgICAoc2V0cSBsYW1kYSAoZXZhbCBsYW1kYSkgbHR5cGUgKGNhciBsYW1kYSkg
Ym9keSAoY2RkciBsYW1kYSkpKSkKICAgIChsZXQgKChkZWN0ZXN0IChjYXIgYm9keSkpKQogICAg
ICAoaWYgKGFuZCAoZXFjYXIgZGVjdGVzdCAnZGVjbGFyZSkgKGVxY2FyIChjYWRyIGRlY3Rlc3Qp
ICdzcGVjaWFsKSkKCSAgKHNldHEgKmRlY2wqIChjZHIgKGNhZHIgZGVjdGVzdCkpIGJvZHkgKGNk
ciBib2R5KSkpKQogICAgKHNldHEgYXJncyAocmVtb3ZlLWZsdWlkcyAoY2FkciBsYW1kYSkpKQog
ICAgKGNvbmQgKChhbmQgKGVxIGx0eXBlICdsYW1iZGEpIChzaW1wbGUtYXJnbGlzdCBhcmdzKSkg
KHNldHEgbmFyZ3MgYXJncykpCiAgICAgICAgICAodCAoc2V0cSBuYXJncyAoZ2Vuc3ltKSkKICAg
ICAjK0xpc3BNIChzZXRxIGJvZHkgYCgoZHNldHEgLGFyZ3MgKGNvcHktbGlzdCAsbmFyZ3MpKSAs
QGJvZHkpKQogICAgICMtTGlzcE0gKHNldHEgYm9keSBgKChkc2V0cSAsYXJncyAgLG5hcmdzKSAs
QGJvZHkpKQogICAgICAgICAgICAgKGNvbmQgKChlcSBsdHlwZSAnbGFtYmRhKSAoc2V0cSBuYXJn
cyBgKCZyZXN0ICxuYXJncyAmYXV4ICxAKnZhcnMqKSkpCiAgICAgICAgICAgICAgICAgICAoKGVx
IGx0eXBlICdtbGFtYmRhKQogICAgICAgICAgICAgICAgICAgIChzZXRxIG5hcmdzIGAoJndob2xl
ICxuYXJncyAmcmVzdCAsKGdlbnN5bSkgJmF1eCAsQCp2YXJzKikpKQogICAgICAgICAgICAgICAg
ICAgKHQgKGVycm9yICJiYWQgZnVuY3Rpb24gdHlwZSIpKSkpKQogICAgKGNvbmQgKCpkZWNsKiAo
c2V0cSBib2R5IChjb25zIGAoZGVjbGFyZSAoc3BlY2lhbCAsQCAqZGVjbCopKSBib2R5KSkpKQog
ICAgKHNldHEgYm9keQogICAgICAgICAgKGNvbmQgKChlcSBsdHlwZSAnbGFtYmRhKSBgKGRlZnVu
ICxmbmFtZSAsbmFyZ3MgLiAsYm9keSkpCiAgICAgICAgICAgICAgICAoKGVxIGx0eXBlICdtbGFt
YmRhKSBgKGRlZm1hY3JvICxmbmFtZSAsbmFyZ3MgLiAsYm9keSkpKSkKICAgIChpZiAqQ09NUDM3
MC1BUFBMWSogKGZ1bmNhbGwgKkNPTVAzNzAtQVBQTFkqIGZuYW1lIGJvZHkpKQoKICAgIGJvZHkp
KQpACgo8PHNpbXBsZS1hcmdsaXN0Pj49CihkZWZ1biBzaW1wbGUtYXJnbGlzdCAoYXJnbGlzdCkK
ICAob3IgKG51bGwgYXJnbGlzdCkKICAgICAgKGFuZCAoY29uc3AgYXJnbGlzdCkgKG51bGwgKGNk
ciAobGFzdCBhcmdsaXN0KSkpCiAgICAgICAgICAgKGV2ZXJ5ICMnc3ltYm9scCBhcmdsaXN0KSkp
KQpACgo8PHJlbW92ZS1mbHVpZHM+Pj0KKGRlZnVuIHJlbW92ZS1mbHVpZHMgKGFyZ2xpc3QgJmF1
eCBmIHYpIDt1cGRhdGVzIHNwZWNpYWxzICpkZWNsKiBhbmQgKnZhcnMqCiAgKGRlY2xhcmUgKHNw
ZWNpYWwgKmRlY2wqICp2YXJzKikpCiAgIChjb25kICgobnVsbCBhcmdsaXN0KSBhcmdsaXN0KQog
ICAgICAgICAoKHN5bWJvbHAgYXJnbGlzdCkgKHB1c2ggYXJnbGlzdCAqdmFycyopIGFyZ2xpc3Qp
CiAgICAgICAgICAgICAgICA7aWYgYXRvbSBidXQgbm90IHN5bWJvbCwgaWdub3JlIHZhbHVlCiAg
ICAgICAgICgoYXRvbSBhcmdsaXN0KSAocHVzaCAoc2V0cSBhcmdsaXN0IChnZW50ZW1wKSkgKnZh
cnMqKSBhcmdsaXN0KQogICAgICAgICAoKGFuZCAoc2V0cSBmIChjYXIgYXJnbGlzdCkpCiAgICAg
ICAgICAgICAgIChlcSBmICdmbHVpZCkKICAgICAgICAgICAgICAgKGxpc3RwIChjZHIgYXJnbGlz
dCkpCiAgICAgICAgICAgICAgIChzZXRxIHYgKGNhZHIgYXJnbGlzdCkpCiAgICAgICAgICAgICAg
IChpZGVudHAgdikKICAgICAgICAgICAgICAgKG51bGwgKGNkZHIgYXJnbGlzdCkpKQogICAgICAg
ICAgKHB1c2ggdiAqZGVjbCopCiAgICAgICAgICAocHVzaCB2ICp2YXJzKikKICAgICAgICAgIHYp
CiAgICAgICAgICh0IChjb25zIChyZW1vdmUtZmx1aWRzIChjYXIgYXJnbGlzdCkpCiAgICAgICAg
ICAgICAgICAgIChyZW1vdmUtZmx1aWRzIChjZHIgYXJnbGlzdCkpKSkpKQpACgpcc2VjdGlvbntP
cGVyYXRpb25zIG9uIE51bWJlcnN9ClxsYWJlbHtzZWM6T3BlcmF0aW9uc09uTnVtYmVyc30KCjw8
cXVvdGllbnQ+Pj0KIy06Q0NMCihkZWZ1biBRVU9USUVOVCAoeCB5KQogIChjb25kICgob3IgKGZs
b2F0cCB4KSAoZmxvYXRwIHkpKSAobGlzcDovIHggeSkpCiAgICAgICAgKHQgKHRydW5jYXRlIHgg
eSkpKSkKIys6Q0NMCihkZWZ1biBRVU9USUVOVCAoeCB5KQogIChjb25kICgob3IgKGZsb2F0cCB4
KSAoZmxvYXRwIHkpKSAoLyB4IHkpKQogICAgICAgICh0ICh0cnVuY2F0ZSB4IHkpKSkpCkAKCjw8
cmVtYWluZGVyPj49CiMtOkNDTAooZGVmdW4gUkVNQUlOREVSICh4IHkpCiAgKGlmIChhbmQgKGlu
dGVnZXJwIHgpIChpbnRlZ2VycCB5KSkKICAgICAgKHJlbSB4IHkpCiAgICAgICgtIHggKCogeSAo
UVVPVElFTlQgeCB5KSkpKSkKQAoKPDxkaXZpZGU+Pj0KIy06Q0NMCihkZWZ1biBESVZJREUgKHgg
eSkKICAoaWYgKGFuZCAoaW50ZWdlcnAgeCkgKGludGVnZXJwIHkpKQogICAgICAobXVsdGlwbGUt
dmFsdWUtbGlzdCAodHJ1bmNhdGUgeCB5KSkKICAgICAgKGxpc3QgKFFVT1RJRU5UIHggeSkgKFJF
TUFJTkRFUiB4IHkpKSkpCkAKCjw8bG9nL2xuPj49CiMtOkNDTAooZGVmdW4gTE4gKHgpIChMT0cg
eCkpCiMtOkNDTAooZGVmdW4gTE9HMiAoeCkgKExPRyB4IDIuMCkpCihkZWZ1biB8bG9nfCAoeCkg
KExPRyB4IDEwLjApKQpACgpcc2VjdGlvbntPcGVyYXRpb25zIG9uIFNlcXVlbmNlc30KXGxhYmVs
e3NlYzpPcGVyYXRpb25zT25TZXF1ZW5jZXN9Cgpcc3Vic2VjdGlvbntVcGRhdGluZ30KXGxhYmVs
e3NlYzpPcGVyYXRpb25zT25TZXF1ZW5jZXNVcGRhdGluZ30KCjw8c2V0ZWx0Pj49CiMtOkNDTAoo
ZGVmbWFjcm8gc2V0ZWx0ICh2ZWMgaW5kIHZhbCkKIGAoc2V0ZiAoZWx0ICx2ZWMgLGluZCkgLHZh
bCkpCkAKCltbTlJFVkVSU0UwXV0gdGFrZXMgYSBsaXN0IGRlc2lnbmF0b3Igb3IgYSBzZXF1ZW5j
ZS4gQW4gYXRvbSBpcyBzaW1wbHkKcmV0dXJuZWQsIGEgc2VxdWVuY2UgaXMgcmV2ZXJzZWQgdXNp
bmcgW1tOUkVWRVJTRV1dIGFuZCB0aGVuIHJldHVybmVkLgo8PG5yZXZlcnNlMD4+PQojLTpDQ0wK
KGRlZm1hY3JvIG5yZXZlcnNlMCAoeCkKICAoaWYgKGF0b20geCkKICAgICAgYChpZiAoYXRvbSAs
eCkgLHggKG5yZXZlcnNlICx4KSkKICAgIChsZXQgKCh4eCAoZ2Vuc3ltKSkpCiAgICAgIGAobGV0
ICgoLHh4ICx4KSkKCSAoaWYgKGF0b20gLHh4KSAseHggKG5yZXZlcnNlICx4eCkpKSkpKQpACgpc
c2VjdGlvbntPcGVyYXRpb25zIG9uIFZlY3RvcnN9ClxsYWJlbHtzZWM6T3BlcmF0aW9uc09uVmVj
dG9yc30KClxzdWJzZWN0aW9ue0NyZWF0aW9ufQpcbGFiZWx7c2VjOk9wZXJhdGlvbnNPblZlY3Rv
cnNDcmVhdGlvbn0KCltbTUFLRS1WRUNdXSBpcyBhbiBhbGlhcyBmb3IgW1tNQUtFLUFSUkFZXV0g
YW5kIHNob3VsZCBnby4KPDxtYWtlLXZlYz4+PQooZGVmdW4gTUFLRS1WRUMgKG4pIChtYWtlLWFy
cmF5IG4pKQpACgo8PGxpc3QydmVjPj49CihkZWZ1biBMSVNUMlZFQyAobGlzdCkgKGNvZXJjZSBs
aXN0ICd2ZWN0b3IpKQpACgpbW01BS0UtQlZFQ11dIENyZWF0ZXMgYSBiaXR2ZWN0b3IsIGNvbnNp
bmcgdXAgYSBzdXBlcmZsdW9zIGxpc3QgaW4gdGhlCnByb2Nlc3MsIGFuZCBpbml0aWFsaXplcyB0
aGUgdmVjdG9yIHRvIDAuIFNob3VsZCBiZSBjYWxsZWQKW1tNQUtFLUJJVC1WRUNUT1JdXSwgaWYg
aXQgaXMgbmVlZGVkIGF0IGFsbC4KPDxtYWtlLWJ2ZWM+Pj0KKGRlZnVuIE1BS0UtQlZFQyAobikK
IChtYWtlLWFycmF5IChsaXN0IG4pIDplbGVtZW50LXR5cGUgJ2JpdCA6aW5pdGlhbC1lbGVtZW50
IDApKQpACgpcc3Vic2VjdGlvbntVcGRhdGluZ30KXGxhYmVse3NlYzpPcGVyYXRpb25zT25WZWN0
b3JzVXBkYXRpbmd9Cgo8PHZlYy1zZXRlbHQ+Pj0KKGRlZm1hY3JvIHZlYy1zZXRlbHQgKHZlYyBp
bmQgdmFsKQogYChzZXRmIChzdnJlZiAsdmVjICxpbmQpICx2YWwpKQpACgpcc3Vic2VjdGlvbntQ
cmVkaWNhdGVzfQoKPDxpdmVjcD4+PQooZGVmdW4gSVZFQ1AgKHgpIChhbmQgKHZlY3RvcnAgeCkg
KHN1YnR5cGVwIChhcnJheS1lbGVtZW50LXR5cGUgeCkgJ2ludGVnZXIpKSkKQAoKXHN1YnNlY3Rp
b257TWlzY2VsbGFuZW91c30KXGxhYmVse3NlYzpPcGVyYXRpb25zT25WZWN0b3JzTWlzY2VsbGFu
ZW91c30KCjw8c2l6ZT4+PQo7OyBPZGRseSwgTEVOR1RIIGlzIG1vcmUgZWZmaWNpZW50IHRoYW4g
TElTVC1MRU5HVEggaW4gQ0NMLCBzaW5jZSB0aGUgZm9ybWVyCjs7IGlzIGNvbXBpbGVkIGFuZCB0
aGUgbGF0dGVyIGlzIGJ5dGUtY29kZWQhCihkZWZ1biBzaXplIChsKSAKICAoY29uZCAoKHZlY3Rv
cnAgbCkgKGxlbmd0aCBsKSkKIys6Q0NMICAoKHN0cmluZ3AgbCkgKGxlbmd0aCBsKSkgOzsgVW50
aWwgQUNOIGZpeGVzIGhpcyBsaXNwIC0+IEMgdHJhbnNsYXRvci4KIy06Q0NMICAoKGNvbnNwIGwp
ICAgKGxpc3QtbGVuZ3RoIGwpKQojKzpDQ0wgICgoY29uc3AgbCkgICAobGVuZ3RoIGwpKQoJKHQg
ICAgICAgICAgIDApKSkKQAoKXHNlY3Rpb257T3BlcmF0aW9ucyBvbiBDaGFyYWN0ZXIgYW5kIEJp
dCBWZWN0b3JzfQpcbGFiZWx7c2VjOk9wZXJhdGlvbnNPbkNoYXJhY3RlckFuZEJpdFZlY3RvcnN9
Cgpcc3Vic2VjdGlvbntDcmVhdGlvbn0KXGxhYmVse3NlYzpPcGVyYXRpb25zT25DaGFyYWN0ZXJB
bmRCaXRWZWN0b3JzQ3JlYXRpb259Cgo8PGNvbmNhdD4+PQojLUFLQ0wKKGRlZnVuIGNvbmNhdCAo
YSBiICZyZXN0IGwpCiAgIChsZXQgKCh0eXBlIChjb25kICgoYml0LXZlY3Rvci1wIGEpICdiaXQt
dmVjdG9yKSAodCAnc3RyaW5nKSkpKQogICAgICAoY29uZCAoKGVxIHR5cGUgJ3N0cmluZykKCSAg
ICAgKHNldHEgYSAoc3RyaW5nIGEpIGIgKHN0cmluZyBiKSkKICAgICAgICAgICAgIChpZiBsIChz
ZXRxIGwgKG1hcGNhciAjJ3N0cmluZyBsKSkpKSkKICAgICAgKGlmIGwgKGFwcGx5ICMnY29uY2F0
ZW5hdGUgdHlwZSBhIGIgbCkKCShjb25jYXRlbmF0ZSB0eXBlIGEgYikpKSApCiMrQUtDTAooZGVm
dW4gY29uY2F0IChhIGIgJnJlc3QgbCkKICAoaWYgKGJpdC12ZWN0b3ItcCBhKQogICAgICAoaWYg
bCAoYXBwbHkgIydjb25jYXRlbmF0ZSAnYml0LXZlY3RvciBhIGIgbCkKCShjb25jYXRlbmF0ZSAn
Yml0LXZlY3RvciBhIGIpKQogICAgKGlmIGwgKGFwcGx5ICMnc3lzdGVtOnN0cmluZy1jb25jYXRl
bmF0ZSBhIGIgbCkKICAgICAgKHN5c3RlbTpzdHJpbmctY29uY2F0ZW5hdGUgYSBiKSkpKQpACjw8
bWFrZS1jdmVjPj49CihkZWZ1biBtYWtlLWN2ZWMgKHNpbnQpIChtYWtlLWFycmF5IHNpbnQgOmZp
bGwtcG9pbnRlciAwIDplbGVtZW50LXR5cGUgJ3N0cmluZy1jaGFyKSkKQAoKPDxtYWtlLWZ1bGwt
Y3ZlYz4+PQooZGVmdW4gbWFrZS1mdWxsLWN2ZWMgKHNpbnQgJm9wdGlvbmFsIChjaGFyICNcc3Bh
Y2UpKQogIChtYWtlLXN0cmluZyBzaW50IDppbml0aWFsLWVsZW1lbnQgKGNoYXJhY3RlciBjaGFy
KSkpCkAKCjw8bWFwZWx0Pj49CihkZWZtYWNybyBtYXBlbHQgKGYgdmVjKQogYChtYXAgJ3ZlY3Rv
ciAsZiAsdmVjKSkKQAoKXHN1YnNlY3Rpb257QWNjZXNzfQpcbGFiZWx7c2VjOk9wZXJhdGlvbnNP
bkNoYXJhY3RlckFuZEJpdFZlY3RvcnNBY2Nlc3N9Cgo8PHFlbnVtPj49CihkZWZ1biBRRU5VTSAo
Y3ZlYyBpbmQpIChjaGFyLWNvZGUgKGNoYXIgY3ZlYyBpbmQpKSkKQAoKPDxxZXNldD4+PQooZGVm
dW4gUUVTRVQgKGN2ZWMgaW5kIGNoYXJudW0pCiAgKHNldGYgKGNoYXIgY3ZlYyBpbmQpIChjb2Rl
LWNoYXIgY2hhcm51bSkpKQpACgo8PHN0cmluZzJpZC1uPj49CihkZWZ1biBzdHJpbmcyaWQtbiAo
Y3ZlYyBzaW50KQogIChpZiAoPCBzaW50IDEpCiAgICAgIG5pbAogICAgICAobGV0ICgoc3RhcnQg
KHBvc2l0aW9uLWlmLW5vdCAjJyhsYW1iZGEgKHgpIChjaGFyPSB4ICNcU3BhY2UpKSBjdmVjKSkp
CiAgICAgICAgKGlmIHN0YXJ0CiAgICAgICAgICAgIChsZXQgKChlbmQgKG9yIChwb3NpdGlvbiAj
XFNwYWNlIGN2ZWMgOnN0YXJ0IHN0YXJ0KSAobGVuZ3RoIGN2ZWMpKSkpCiAgICAgICAgICAgICAg
KGlmICg9IHNpbnQgMSkKICAgICAgICAgICAgICAgICAgKGludGVybiAoc3Vic2VxIGN2ZWMgc3Rh
cnQgZW5kKSkKICAgICAgICAgICAgICAgICAgKHN0cmluZzJpZC1uIChzdWJzZXEgY3ZlYyBlbmQp
ICgxLSBzaW50KSkpKQogICAgICAgICAgICAwKSkpKQpACgo8PHN1YnN0cmluZz4+PQooZGVmdW4g
c3Vic3RyaW5nIChjdmVjIHN0YXJ0IGxlbmd0aCkKICAoc2V0cSBjdmVjIChzdHJpbmcgY3ZlYykp
CiAgKGlmIGxlbmd0aCAoc3Vic2VxIGN2ZWMgc3RhcnQgKCsgc3RhcnQgbGVuZ3RoKSkgKHN1YnNl
cSBjdmVjIHN0YXJ0KSkpCkAKClxzdWJzZWN0aW9ue1NlYXJjaGluZ30KXGxhYmVse3NlYzpPcGVy
YXRpb25zT25DaGFyYWN0ZXJBbmRCaXRWZWN0b3JzU2VhcmNoaW5nfQoKPDxzdHJwb3M+Pj0KKGRl
ZnVuIHN0cnBvcyAod2hhdCBpbiBzdGFydCBkb250Y2FyZSkKICAgKHNldHEgd2hhdCAoc3RyaW5n
IHdoYXQpIGluIChzdHJpbmcgaW4pKQogICAoaWYgZG9udGNhcmUgKHByb2duIChzZXRxIGRvbnRj
YXJlIChjaGFyYWN0ZXIgZG9udGNhcmUpKQoJCSAgICAgICAoc2VhcmNoIHdoYXQgaW4gOnN0YXJ0
MiBzdGFydAoJCQkgICAgICAgOnRlc3QgIycobGFtYmRhICh4IHkpIChvciAoZXFsIHggZG9udGNh
cmUpCgkJCQkJCQkgKGVxbCB4IHkpKSkpKQogICAgICAgICAgICAgICAgKGlmICg9IHN0YXJ0IDAp
CiAgICAgICAgICAgICAgICAgICAoc2VhcmNoIHdoYXQgaW4pCiAgICAgICAgICAgICAgICAgICAo
c2VhcmNoIHdoYXQgaW4gOnN0YXJ0MiBzdGFydCkpCiAgICkpCkAKCjw8c3RycG9zbD4+PQo7IElu
IHRoZSBmb2xsb3dpbmcsIHRhYmxlIHNob3VsZCBiZSBhIHN0cmluZzoKCihkZWZ1biBzdHJwb3Ns
ICh0YWJsZSBjdmVjIHNpbnQgaXRlbSkKICAoc2V0cSBjdmVjIChzdHJpbmcgY3ZlYykpCiAgKGlm
IChub3QgaXRlbSkKICAgICAgKHBvc2l0aW9uIHRhYmxlIGN2ZWMgOnRlc3QgIycobGFtYmRhICh4
IHkpIChwb3NpdGlvbiB5IHgpKSA6c3RhcnQgc2ludCkKICAgICAgKHBvc2l0aW9uIHRhYmxlIGN2
ZWMgOnRlc3Qtbm90ICMnKGxhbWJkYSAoeCB5KSAocG9zaXRpb24geSB4KSkgOnN0YXJ0IHNpbnQp
KSkKQAoKXHN1YnNlY3Rpb257VXBkYXRpbmd9ClxsYWJlbHtzZWM6T3BlcmF0aW9uc09uQ2hhcmFj
dGVyQW5kQml0VmVjdG9yc1VwZGF0aW5nfQoKPDxzdWZmaXg+Pj0KKGRlZnVuIHN1ZmZpeCAoaWQg
Y3ZlYykKICAiU3VmZml4ZXMgdGhlIGZpcnN0IGNoYXIgb2YgdGhlIHN5bWJvbCBvciBjaGFyIElE
IHRvIHRoZSBzdHJpbmcgQ1ZFQywKICAgIGNoYW5naW5nIENWRUMuIgogICh1bmxlc3MgKGNoYXJh
Y3RlcnAgaWQpIChzZXRxIGlkIChlbHQgKHN0cmluZyBpZCkgMCkpKQogIChjb25kICgoYXJyYXkt
aGFzLWZpbGwtcG9pbnRlci1wIGN2ZWMpCgkgKHZlY3Rvci1wdXNoLWV4dGVuZCBpZCBjdmVjKQoJ
IGN2ZWMpCgkoKGFkanVzdGFibGUtYXJyYXktcCBjdmVjKQoJIChsZXQgKChsIChsZW5ndGggY3Zl
YykpKQoJICAgKGFkanVzdC1hcnJheSBjdmVjICgxKyBsKSkKCSAgIChzZXRmIChlbHQgY3ZlYyBs
KSBpZCkKCSAgIGN2ZWMpKQoJKHQgKGNvbmNhdCBjdmVjIGlkKSkpKQpACgo8PGNoYW5nZS1sZW5n
dGgvc2V0c2l6ZT4+PQooZGVmdW4gc2V0c2l6ZSAodmVjdG9yIHNpemUpIChhZGp1c3QtYXJyYXkg
dmVjdG9yIHNpemUpKQoKKGRlZmluZS1mdW5jdGlvbiAnY2hhbmdlbGVuZ3RoICMnc2V0c2l6ZSkK
QAoKPDxycGxhY3N0cj4+PQo7IFRoZSBmb2xsb3dpbmcgdmVyc2lvbiBoYXMgYmVlbiBwcm92aWRl
ZCB0byBhdm9pZCByZWxpYW5jZSBvbiB0aGUKOyBDb21tb24gTGlzcCBjb25jYXRlbmF0ZSBhbmQg
cmVwbGFjZSBmdW5jdGlvbnMuIFRoZXNlIGJ1aWx0LWluIExpc3AKOyBmdW5jdGlvbnMgd291bGQg
cHJvYmFibHkgZW5kIHVwIGRvaW5nIHRoZSBjaGFyYWN0ZXItYnktY2hhcmFjdGVyCjsgY29weWlu
ZyBzaG93biBoZXJlLCBidXQgd291bGQgYWxzbyBuZWVkIHRvIGNvcGUgd2l0aCBnZW5lcmljIHNv
cnRzCjsgb2Ygc2VxdWVuY2VzIGFuZCB1bndhcnJhbnRlZCBrZXl3b3JkIGdlbmVyYWxpdHkKCihk
ZWZ1biBycGxhY3N0ciAoY3ZlYzEgc3RhcnQxIGxlbmd0aDEgY3ZlYzIKICAgICAgICAgICAgICAg
ICAgICAgICAmb3B0aW9uYWwgc3RhcnQyIGxlbmd0aDIKICAgICAgICAgICAgICAgICAgICAgICAm
YXV4IGVuZDEgZW5kMikKICAoc2V0cSBjdmVjMiAoc3RyaW5nIGN2ZWMyKSkKICAoaWYgKG51bGwg
c3RhcnQxKSAoc2V0cSBzdGFydDEgMCkpCiAgKGlmIChudWxsIHN0YXJ0MikgKHNldHEgc3RhcnQy
IDApKQogIChpZiAobnVsbCBsZW5ndGgxKSAoc2V0cSBsZW5ndGgxICgtIChsZW5ndGggY3ZlYzEp
IHN0YXJ0MSkpKQogIChpZiAobnVsbCBsZW5ndGgyKSAoc2V0cSBsZW5ndGgyICgtIChsZW5ndGgg
Y3ZlYzIpIHN0YXJ0MikpKQogIChzZXRxIGVuZDEgKCsgc3RhcnQxIGxlbmd0aDEpKQogIChzZXRx
IGVuZDIgKCsgc3RhcnQyIGxlbmd0aDIpKQogIChpZiAoPSBsZW5ndGgxIGxlbmd0aDIpCiAgICAg
IChkbyAoKQogICAgICAgICAgKCg9IHN0YXJ0MSBlbmQxKSBjdmVjMSkKICAgICAgICAgIChzZXRm
IChhcmVmIGN2ZWMxIHN0YXJ0MSkgKGFyZWYgY3ZlYzIgc3RhcnQyKSkKICAgICAgICAgIChzZXRx
IHN0YXJ0MSAoMSsgc3RhcnQxKSkKICAgICAgICAgIChzZXRxIHN0YXJ0MiAoMSsgc3RhcnQyKSkp
CiAgICAgIChsZXQqICgobDEgKGxlbmd0aCBjdmVjMSkpCiMrOkNDTCAgICAgICAociAobGlzcDo6
bWFrZS1zaW1wbGUtc3RyaW5nICgtICgrIGwxIGxlbmd0aDIpIGxlbmd0aDEpKSkKIy06Q0NMICAg
ICAgIChyIChsaXNwOjptYWtlLXN0cmluZyAoLSAoKyBsMSBsZW5ndGgyKSBsZW5ndGgxKSkpCiAg
ICAgICAgICAgICAoaSAwKSkKICAgICAgICAgKGRvICgoaiAwICgxKyBqKSkpCiAgICAgICAgICAg
ICAoKD0gaiBzdGFydDEpKQogICAgICAgICAgICAgKHNldGYgKGFyZWYgciBpKSAoYXJlZiBjdmVj
MSBqKSkKICAgICAgICAgICAgIChzZXRxIGkgKDErIGkpKSkKICAgICAgICAgKGRvICgoaiBzdGFy
dDIgKDErIGopKSkKICAgICAgICAgICAgICgoPSBqIGVuZDIpKQogICAgICAgICAgICAgKHNldGYg
KGFyZWYgciBpKSAoYXJlZiBjdmVjMiBqKSkKICAgICAgICAgICAgIChzZXRxIGkgKDErIGkpKSkK
ICAgICAgICAgKGRvICgoaiBlbmQxICgxKyBqKSkpCiAgICAgICAgICAgICAoKD0gaiBsMSkpCiAg
ICAgICAgICAgICAoc2V0ZiAoYXJlZiByIGkpIChhcmVmIGN2ZWMxIGopKQogICAgICAgICAgICAg
KHNldHEgaSAoMSsgaSkpKQogICAgICAgICByKQogICkpCkAKClxzdWJzZWN0aW9ue1ByZWRpY2F0
ZXN9ClxsYWJlbHtzZWM6T3BlcmF0aW9uc09uQ2hhcmFjdGVyQW5kQml0VmVjdG9yc1ByZWRpY2F0
ZXN9Cgo8PGNncmVhdGVycD4+PQooZGVmdW4gQ0dSRUFURVJQIChzMSBzMikgKHN0cmluZz4gKHN0
cmluZyBzMSkgKHN0cmluZyBzMikpKQpACgpcc2VjdGlvbntPcGVyYXRpb25zIG9uIFBhaXJzfQpc
bGFiZWx7c2VjOk9wZXJhdGlvbnNPblBhaXJzfQoKXHN1YnNlY3Rpb257VXBkYXRpbmd9ClxsYWJl
bHtzZWM6T3BlcmF0aW9uc09uUGFpcnNVcGRhdGluZ30KClJlcGxhY2VzIHRoZSBjYXIgYW5kIGNk
ciBvZiBbW1BBSVIxXV0gd2l0aCB0aGUgY2FyIGFuZCBjZHIgb2YgW1tQQUlSMl1dIGFuZApyZXR1
cm5zIFtbUEFJUjFdXS4KPDxycGxwYWlyPj49CihkZWZ1biBSUExQQUlSIChwYWlyMSBwYWlyMikK
ICAoUlBMQUNBIHBhaXIxIChDQVIgcGFpcjIpKQogIChSUExBQ0QgcGFpcjEgKENEUiBwYWlyMikp
IHBhaXIxKQpACgpTZXRzIHRoZSBjYXIgYW5kIGNkciBvZiBbW1BBSVIxXV0gdG8gW1tDQTJdXSBh
bmQgW1tDRDJdXS4KPDxycGxub2RlPj49CihkZWZ1biBSUExOT0RFIChwYWlyMSBjYTIgY2QyKQog
KFJQTEFDQSBwYWlyMSBjYTIpIAogKFJQTEFDRCBwYWlyMSBjZDIpIHBhaXIxKQpACgpcc2VjdGlv
bntPcGVyYXRpb25zIG9uIExpc3RzfQpcbGFiZWx7c2VjOk9wZXJhdGlvbnNPbkxpc3RzfQoKXHN1
YnNlY3Rpb257Q3JlYXRpb259ClxsYWJlbHtzZWM6T3BlcmF0aW9uc09uTGlzdHNDcmVhdGlvbn0K
Cjw8dmVjMmxpc3Q+Pj0KKGRlZnVuIFZFQzJMSVNUICh2ZWMpIChjb2VyY2UgdmVjICdsaXN0KSkK
QAoKPDx8cmVtb3ZlfD4+PQooZGVmdW4gfHJlbW92ZXwgKGxpc3QgaXRlbSAmb3B0aW9uYWwgKGNv
dW50IDEpKQogIChpZiAoaW50ZWdlcnAgY291bnQpCiAgICAgIChyZW1vdmUgaXRlbSBsaXN0IDpj
b3VudCBjb3VudCA6dGVzdCAjJ2VxdWFscCkKICAgICAgKHJlbW92ZSBpdGVtIGxpc3QgOnRlc3Qg
IydlcXVhbHApKSkKQAoKPDxyZW1vdmVxPj49CihkZWZ1biBSRU1PVkVRIChsaXN0IGl0ZW0gJm9w
dGlvbmFsIChjb3VudCAxKSkKICAoaWYgKGludGVnZXJwIGNvdW50KQogICAgICAocmVtb3ZlIGl0
ZW0gbGlzdCA6Y291bnQgY291bnQgOnRlc3QgIydlcSkKICAgICAgKHJlbW92ZSBpdGVtIGxpc3Qg
OnRlc3QgIydlcSkpKQpACgpcc3Vic2VjdGlvbntBY2Nlc3N9ClxsYWJlbHtzZWM6T3BlcmF0aW9u
c09uTGlzdHNBY2Nlc3N9Cgo8PHxsYXN0fD4+PQooZGVmdW4gfGxhc3R8ICh4KSAoY2FyIChsYXN0
cGFpciB4KSkpCkAKClxzdWJzZWN0aW9ue1NlYXJjaGluZ30KXGxhYmVse3NlYzpPcGVyYXRpb25z
T25MaXN0c1NlYXJjaGluZ30KCjw8fGFzc29jfD4+PQojKzpDQ0wgKERFRk1BQ1JPIHxhc3NvY3wg
KFggWSkgYChBU1NPQyoqICxYICxZKSkKIy06Q0NMCihERUZVTiB8YXNzb2N8IChYIFkpCiAgIlJl
dHVybiB0aGUgcGFpciBhc3NvY2lhdGVkIHdpdGgga2V5IFggaW4gYXNzb2NpYXRpb24gbGlzdCBZ
LiIKICA7IGlnbm9yZXMgbm9uLW5pbCBsaXN0IHRlcm1pbmF0b3JzCiAgOyBpZ25vcmVzIG5vbi1w
YWlyIGEtbGlzdCBlbnRyaWVzCiAgKGNvbmQgKChzeW1ib2xwIFgpCgkgKFBST0cgTklMCgkgICAg
ICAgQSAgKENPTkQgKChBVE9NIFkpIChSRVRVUk4gTklMKSkKCQkJKChOT1QgKGNvbnNwIChDQVIg
WSkpKSApCgkJCSgoRVEgKENBQVIgWSkgWCkgKFJFVFVSTiAoQ0FSIFkpKSkgKQoJICAgICAgIChT
RVRRIFkgKENEUiBZKSkKCSAgICAgICAoR08gQSkpKQoJKChvciAobnVtYmVycCB4KSAoY2hhcmFj
dGVycCB4KSkKCSAoUFJPRyBOSUwKCSAgICAgICBBICAoQ09ORCAoKEFUT00gWSkgKFJFVFVSTiBO
SUwpKQoJCQkoKE5PVCAoY29uc3AgKENBUiBZKSkpICkKCQkJKChFUUwgKENBQVIgWSkgWCkgKFJF
VFVSTiAoQ0FSIFkpKSkgKQoJICAgICAgIChTRVRRIFkgKENEUiBZKSkKCSAgICAgICAoR08gQSkp
KQoJKHQKCSAoUFJPRyBOSUwKCSAgICAgICBBICAoQ09ORCAoKEFUT00gWSkgKFJFVFVSTiBOSUwp
KQoJCQkoKE5PVCAoY29uc3AgKENBUiBZKSkpICkKCQkJKChFUVVBTCAoQ0FBUiBZKSBYKSAoUkVU
VVJOIChDQVIgWSkpKSApCgkgICAgICAgKFNFVFEgWSAoQ0RSIFkpKQoJICAgICAgIChHTyBBKSkp
KSkKQAoKPDx8bWVtYmVyfD4+PQooZGVmdW4gfG1lbWJlcnwgKGl0ZW0gc2VxdWVuY2UpCiAgIChj
b25kICgoc3ltYm9scCBpdGVtKSAobWVtYmVyIGl0ZW0gc2VxdWVuY2UgOnRlc3QgIydlcSkpCgkg
KChzdHJpbmdwIGl0ZW0pIChtZW1iZXIgaXRlbSBzZXF1ZW5jZSA6dGVzdCAjJ2VxdWFsKSkKCSAo
KGFuZCAoYXRvbSBpdGVtKSAobm90IChhcnJheXAgaXRlbSkpKSAobWVtYmVyIGl0ZW0gc2VxdWVu
Y2UpKQoJIChUIChtZW1iZXIgaXRlbSBzZXF1ZW5jZSA6dGVzdCAjJ2VxdWFscCkpKSkKQAoKXHN1
YnNlY3Rpb257VXBkYXRpbmd9ClxsYWJlbHtzZWM6T3BlcmF0aW9uc09uTGlzdHNVcGRhdGluZ30K
Cjw8bnJlbW92ZT4+PQooZGVmdW4gTlJFTU9WRSAobGlzdCBpdGVtICZvcHRpb25hbCAoY291bnQg
MSkpCiAgKGlmIChpbnRlZ2VycCBjb3VudCkKICAgICAgKGRlbGV0ZSBpdGVtIGxpc3QgOmNvdW50
IGNvdW50IDp0ZXN0ICMnZXF1YWwpCiAgICAgIChkZWxldGUgaXRlbSBsaXN0IDp0ZXN0ICMnZXF1
YWwpKSkKQAoKPDxucmVtb3ZlcT4+PQooZGVmdW4gTlJFTU9WRVEgKGxpc3QgaXRlbSAmb3B0aW9u
YWwgKGNvdW50IDEpKQogIChpZiAoaW50ZWdlcnAgY291bnQpCiAgICAgIChkZWxldGUgaXRlbSBs
aXN0IDpjb3VudCBjb3VudCApCiAgICAgIChkZWxldGUgaXRlbSBsaXN0ICkpKQpACgo8PGVmZmFj
ZT4+PQooZGVmdW4gRUZGQUNFIChpdGVtIGxpc3QpIChkZWxldGUgaXRlbSBsaXN0IDpjb3VudCAx
IDp0ZXN0ICMnZXF1YWwpKQpACgo8PG5jb25jMj4+PQooZGVmdW4gTkNPTkMyICh4IHkpIChOQ09O
QyB4IHkpKSA7TkNPTkMgd2l0aCBleGFjdGx5IHR3byBhcmd1bWVudHMKQAoKXHN1YnNlY3Rpb257
TWlzY2VsbGFuZW91c30KXGxhYmVse3NlYzpPcGVyYXRpb25zT25MaXN0c01pc2NlbGxhbmVvdXN9
CgoKPDxxc29ydD4+PQooZGVmdW4gUVNPUlQgKGwpCiAoZGVjbGFyZSAoc3BlY2lhbCBzb3J0Z3Jl
YXRlcnApKQogIChOUkVWRVJTRSAoc29ydCAoY29weS1zZXEgbCkgU09SVEdSRUFURVJQKSkpCkAK
Cjw8c29ydGJ5Pj49CihkZWZ1biBTT1JUQlkgKGtleWZuIGwpCiAoZGVjbGFyZSAoc3BlY2lhbCBz
b3J0Z3JlYXRlcnApKQogIChucmV2ZXJzZSAoc29ydCAoY29weS1zZXEgbCkgU09SVEdSRUFURVJQ
IDprZXkga2V5Zm4pKSkKQAoKXHNlY3Rpb257RnVuY3Rpb25zfQpcbGFiZWx7c2VjOkZ1bmN0aW9u
c30KCjw8KmxhbT4+PQooZGVmdW4gKkxBTSAoYm9keSkKICAoY29uZCAgKChOT1QgKElTUVVPVEVE
UCAoZmlyc3QgQk9EWSkpKSAoY29ucyAnTEFNQkRBIEJPRFkpKQogICAgICAgICAoKExFVCogKChC
ViAoREVRVU9URSAoZmlyc3QgQk9EWSkpKQogICAgICAgICAgICAgICAgIChDT05UUk9MIChRVU9U
RVNPRiAoZmlyc3QgQk9EWSkpKQogICAgICAgICAgICAgICAgIChCT0RZIChjZHIgQk9EWSkpCiAg
ICAgICAgICAgICAgICAgKEFSR1MgKEdFTlNZTSkpCiAgICAgICAgICAgICAgICAgKElOTkVSLUZV
TkMgKG9yICpsYW0tbmFtZSogKGdlbnRlbXApKSkpCiAgICAgICAgICAgIChDT01QMzcwIChMSVNU
IElOTkVSLUZVTkMgYChMQU1CREEgLEJWIC4gLEJPRFkpKSkKICAgICAgICAgICAgYChNTEFNQkRB
ICxBUkdTCiAgICAgICAgICAgICAgICAgICAgICAoQ09OUyAoUVVPVEUgLElOTkVSLUZVTkMpCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAoV1JBUCAoY2RyICxBUkdTKSAnLENPTlRST0wpKSkp
KSkpCkAKCjw8d3JhcD4+PQooZGVmdW4gV1JBUCAoTElTVC1PRi1JVEVNUyBXUkFQUEVSKQogKHBy
b2cgbmlsCiAgKENPTkQgKChPUiAoTk9UIChQQUlSUCBMSVNULU9GLUlURU1TKSkgKG5vdCBXUkFQ
UEVSKSkKICAgICAgICAgKFJFVFVSTiBMSVNULU9GLUlURU1TKSkKICAgICAgICAoKE5PVCAoY29u
c3AgV1JBUFBFUikpCiAgICAgICAgIChTRVRRIFdSQVBQRVIgKExPVFNPRiBXUkFQUEVSKSkpKQog
IChSRVRVUk4KICAgIChDT05TIChpZiAoZmlyc3QgV1JBUFBFUikKICAgICAgICAgICAgICBgKCwo
Zmlyc3QgV1JBUFBFUikgLChmaXJzdCBMSVNULU9GLUlURU1TKSkKICAgICAgICAgICAgICAoZmly
c3QgTElTVC1PRi1JVEVNUykpCiAgICAgICAgICAoV1JBUCAoY2RyIExJU1QtT0YtSVRFTVMpIChj
ZHIgV1JBUFBFUikpKSkpKQpACgo8PGlzcXVvdGVkcD4+PQooZGVmdW4gSVNRVU9URURQIChidikK
ICAoQ09ORCAoKE5PVCAoY29uc3AgQlYpKSBOSUwpCiAgICAgICAgKChFUSAoZmlyc3QgQlYpICdR
VU9URSkpCiAgICAgICAgKChBTkQgKGNvbnNwIChmaXJzdCBCVikpIChFUSAoUUNBQVIgQlYpICdR
VU9URSkpKQogICAgICAgICgoSVNRVU9URURQIChjZHIgQlYpKSkpKQpACgo8PHF1b3Rlc29mPj49
CihkZWZ1biBRVU9URVNPRiAoQlYpCiAgKENPTkQgKChOT1QgKGNvbnNwIEJWKSkgTklMKQogICAg
ICAoKEVRIChmaXJzdCBCVikgJ1FVT1RFKSAnUVVPVEUpCiAgICAgICgoQ09OUyAoQ09ORCAoKE5P
VCAoY29uc3AgKGZpcnN0IEJWKSkpIG5pbCkKICAgICAgICAgICAgICAgICAgICgoRVEgKFFDQUFS
IEJWKSAnUVVPVEUpICdRVU9URSkKICAgICAgICAgICAgICAgICAgIChUIE5JTCkpCiAgICAgICAg
ICAgICAoUVVPVEVTT0YgKGNkciBCVikpKSkpKQpACgo8PGRlcXVvdGU+Pj0KKGRlZnVuIERFUVVP
VEUgKEJWKQogIChDT05EICgoTk9UIChjb25zcCBCVikpIEJWKQogICAgICAgICgoRVEgJ1FVT1RF
IChmaXJzdCBCVikpIChzZWNvbmQgQlYpKQogICAgICAgICgoQ09OUyAoaWYgKEVRICdRVU9URSAo
SUZDQVIgKENBUiBCVikpKSAoQ0FEQVIgQlYpIChmaXJzdCBCVikpCiAgICAgICAgICAgICAgIChE
RVFVT1RFIChjZHIgQlYpKSkpKSkKQAoKPDxsb3Rzb2Y+Pj0KKGRlZnVuIGxvdHNvZiAoJnJlc3Qg
aXRlbXMpCiAgKHNldHEgaXRlbXMgKGNvcHktbGlzdCBpdGVtcykpCiAgKG5jb25jIGl0ZW1zIGl0
ZW1zKSkKQAoKXHNlY3Rpb257T3BlcmF0aW9ucyBvbiBJZGVudGlmaWVyc30KXGxhYmVse3NlYzpP
cGVyYXRpb25zT25JZGVudGlmaWVyc30KClxzdWJzZWN0aW9ue0NyZWF0aW9ufQpcbGFiZWx7T3Bl
cmF0aW9uc09uSWRlbnRpZmllcnNDcmVhdGlvbn0KCjw8dXAvZG93bi1jYXNlPj49CihkZWZ1biB1
cGNhc2UgKGwpCiAgKGNvbmQgKChzdHJpbmdwIGwpIChzdHJpbmctdXBjYXNlIGwpKQogICAgICAg
ICgoaWRlbnRwIGwpIChpbnRlcm4gKHN0cmluZy11cGNhc2UgKHN5bWJvbC1uYW1lIGwpKSkpCiAg
ICAgICAgKChjaGFyYWN0ZXJwIGwpIChjaGFyLXVwY2FzZSBsKSkKICAgICAgICAoKGF0b20gbCkg
bCkKICAgICAgICAodCAobWFwY2FyICMndXBjYXNlIGwpKSkpCgoKKGRlZnVuIGRvd25jYXNlIChs
KQogIChjb25kICgoc3RyaW5ncCBsKSAoc3RyaW5nLWRvd25jYXNlIGwpKQogICAgICAgICgoaWRl
bnRwIGwpIChpbnRlcm4gKHN0cmluZy1kb3duY2FzZSAoc3ltYm9sLW5hbWUgbCkpKSkKICAgICAg
ICAoKGNoYXJhY3RlcnAgbCkgKGNoYXItZG93bmNhc2UgTCkpCiAgICAgICAgKChhdG9tIGwpIGwp
CiAgICAgICAgKHQgKG1hcGNhciAjJ2Rvd25jYXNlIGwpKSkpCkAKClxzdWJzZWN0aW9ue0FjY2Vz
c30KXGxhYmVse3NlYzpPcGVyYXRpb25zT25JZGVudGlmaWVyc0FjY2Vzc30KCgo8PHBuYW1lPj49
Cjs7IG5vdGUgaXQgaXMgaW1wb3J0YW50IHRoYXQgUE5BTUUgcmV0dXJucyBuaWwgbm90IGFuIGVy
cm9yIGZvciBub24tc3ltYm9scwooZGVmdW4gcG5hbWUgKHgpCiAgKGNvbmQgKChzeW1ib2xwIHgp
IChzeW1ib2wtbmFtZSB4KSkKCSgoY2hhcmFjdGVycCB4KSAoc3RyaW5nIHgpKQoJKHQgbmlsKSkp
CkAKCjw8cHJvcGxpc3Q+Pj0KOzsgcHJvcGVydHkgbGlzdHMgaW4gdm1saXNwIGFyZSBhbGlzdHMK
KGRlZnVuIFBST1BMSVNUICh4KQogIChpZiAoc3ltYm9scCB4KQojLTpDQ0wKICAgKHBsaXN0MmFs
aXN0IChzeW1ib2wtcGxpc3QgeCkpCiMrOkNDTAogICAocGxpc3QyYWxpc3QgKHBsaXN0IHgpKQog
ICAgbmlsKSkKCihkZWZ1biBwbGlzdDJhbGlzdCAoeCkKICAoaWYgKG51bGwgeCkgCiAgICAgIG5p
bAogICAgICAoY29ucyAoY29ucyAoZmlyc3QgeCkgKHNlY29uZCB4KSkgKHBsaXN0MmFsaXN0IChj
ZGRyIHgpKSkpKQoKIy06Q0NMCihkZWZ1biBwdXQgKHN5bSBpbmQgdmFsKSAoc2V0ZiAoZ2V0IHN5
bSBpbmQpIHZhbCkpCkAKClxzdWJzZWN0aW9ue01pc2NlbGxhbmVvdXN9ClxsYWJlbHtzZWM6T3Bl
cmF0aW9uc09uSWRlbnRpZmllcnNNaXNjZWxsYW5lb3VzfQoKPDx8aWRDaGFyP3w+Pj0KKGRlZm1h
Y3JvIHxpZENoYXI/fCAoeCkKIGAob3IgKGFscGhhbnVtZXJpY3AgLHgpIChtZW1iZXIgLHggJygj
XD8gI1wlICNcJyAjXCEpIDp0ZXN0ICMnY2hhcj0pKSkKQAoKPDx8c3RhcnRzSWQ/fD4+PQooZGVm
bWFjcm8gfHN0YXJ0c0lkP3wgKHgpCiBgKG9yIChhbHBoYS1jaGFyLXAgLHgpIChtZW1iZXIgLHgg
JygjXD8gI1wlICNcISkgOnRlc3QgIydjaGFyPSkpKQpACgo8PGRpZ2l0cD4+PQooZGVmdW4gZGln
aXRwICh4KQogIChvciAoYW5kIChzeW1ib2xwIHgpIChkaWdpdHAgKHN5bWJvbC1uYW1lIHgpKSkK
ICAgICAgKGFuZCAoY2hhcmFjdGVycCB4KSAoZGlnaXQtY2hhci1wIHgpKQogICAgICAoYW5kIChz
dHJpbmdwIHgpICg9IChsZW5ndGggeCkgMSkgKGRpZ2l0LWNoYXItcCAoY2hhciB4IDApKSkpKQpA
Cgo8PGRpZzJmaXg+Pj0KKGRlZnVuIGRpZzJmaXggKHgpCiAgKGlmIChzeW1ib2xwIHgpCiAgICAo
ZGlnaXQtY2hhci1wIChjaGFyIChzeW1ib2wtbmFtZSB4KSAwKSkKICAgIChkaWdpdC1jaGFyLXAg
eCkpKQpACgpUaGlzIG1hY3JvIGdlbmVyYXRlcyBjb2RlIG1vc3RseSBlcXVpdmFsZW50IHRvIHRo
ZSBjb21tZW50Lgo8PHxvcE9mfD4+PQooZGVmbWFjcm8gfG9wT2Z8ICh4KSA7KGlmIChhdG9tIHgp
IHggKHFjYXIgeCkpCiAgKGlmIChhdG9tIHgpCiAgICAgIGAoaWYgKGNvbnNwICx4KSAocWNhciAs
eCkgLHgpCiAgICAobGV0ICgoeHggKGdlbnN5bSkpKQogICAgICBgKGxldCAoKCx4eCAseCkpCgkg
KGlmIChjb25zcCAseHgpIChxY2FyICx4eCkgLHh4KSkpKSkKQAoKXHNlY3Rpb257QlBJc30KXGxh
YmVse3NlYzpCUElzfQoKPDxtYnBpcD4+PQooZGVmdW4gbWJwaXAgKGl0ZW0pIChhbmQgKHN5bWJv
bHAgaXRlbSkgO2Nhbm5vdCBrbm93IGEgY29tcGlsZWQgbWFjcm8gaW4gQ0xJU1AKICAgICAgICAg
ICAgICAgICAgICAgICAgIChjb21waWxlZC1mdW5jdGlvbi1wIChtYWNyby1mdW5jdGlvbiBpdGVt
KSkpKQpACgo8PGZicGlwPj49CihkZWZ1biBGQlBJUCAoaXRlbSkgKG9yIChjb21waWxlZC1mdW5j
dGlvbi1wIGl0ZW0pCgkJCShhbmQgKHN5bWJvbHAgaXRlbSkgKGZib3VuZHAgaXRlbSkKCQkJICAg
ICAobm90IChtYWNyby1mdW5jdGlvbiBpdGVtKSkKCQkJICAgICAoY29tcGlsZWQtZnVuY3Rpb24t
cCAoc3ltYm9sLWZ1bmN0aW9uIGl0ZW0pKSkpKQpACgo8PGJwaW5hbWU+Pj0KIytMdWNpZAooZGVm
dW4gQlBJTkFNRSAoZnVuYykKICAoaWYgKGZ1bmN0aW9ucCBmdW5jKQogICAgICAoaWYgKHN5bWJv
bHAgZnVuYykgZnVuYwoJKGxldCAoKG5hbWUgKHN2cmVmIGZ1bmMgMCkpKQoJICAoaWYgKGFuZCAo
Y29uc3AgbmFtZSkgKGVxIChjYXIgbmFtZSkgJ1NZU1RFTTo6TkFNRUQtTEFNQkRBKSkKCSAgICAg
IChjYWRyIG5hbWUpCgkgICAgbmFtZSkpICkpKQoKIysoT1IgSUJDTCBLQ0wpCihkZWZ1biBCUElO
QU1FIChmdW5jKQogIChpZiAoZnVuY3Rpb25wIGZ1bmMpCiAgICAgIChjb25kICgoc3ltYm9scCBm
dW5jKSBmdW5jKQoJICAgICgoYW5kIChjb25zcCBmdW5jKSAoZXEgKGNhciBmdW5jKSAnTEFNQkRB
LUJMT0NLKSkKCSAgICAgIChjYWRyIGZ1bmMpKQoJICAgICgoY29tcGlsZWQtZnVuY3Rpb24tcCBm
dW5jKQoJICAgICAoc3lzdGVtOmNvbXBpbGVkLWZ1bmN0aW9uLW5hbWUgZnVuYykpCgkgICAgKCd0
IGZ1bmMpKSkpCgojKzpjbXVsaXNwCihkZWZ1biBCUElOQU1FIChmdW5jKQogKHdoZW4gKGZ1bmN0
aW9ucCBmdW5jKQogIChjb25kCiAgICAoKHN5bWJvbHAgZnVuYykgZnVuYykKICAgICgoYW5kIChj
b25zcCBmdW5jKSAoZXEgKGNhciBmdW5jKSAnbGFtYmRhKSkgKHNlY29uZCAodGhpcmQgZnVuYykp
KQogICAgKChjb21waWxlZC1mdW5jdGlvbi1wIGZ1bmMpCiAgICAgIChzeXN0ZW06OiVwcmltaXRp
dmUgaGVhZGVyLXJlZiBmdW5jIHN5c3RlbTo6JWZ1bmN0aW9uLW5hbWUtc2xvdCkpCiAgICAoJ2Vs
c2UgZnVuYykpKSkKCiMrOmFsbGVncm8KKGRlZnVuIGJwaW5hbWUgKGZ1bmMpCiBmdW5jKQoKIys6
Q0NMCihkZWZ1biBicGluYW1lICh4KQogICAoaWYgKHN5bWJvbHAgeCkKICAgICAoaW50ZXJuIChz
eW1ib2wtbmFtZSAoc3ltYm9sLWZ1bmN0aW9uIHgpKSAiQk9PVCIpCiAgICBuaWwpKQpACgo8PGxp
c3RvZnF1b3Rlcz4+PQooZGVmdW4gTElTVE9GUVVPVEVTIChicGkpCiAoZGVjbGFyZSAoaWdub3Jl
IGJwaSkpCiAgKCkpCkAKPDxsaXN0b2ZmcmVlcz4+PQojK0x1Y2lkCihkZWZ1biBMSVNUT0ZGUkVF
UyAoYnBpKQogIChpZiAoY29tcGlsZWQtZnVuY3Rpb24tcCBicGkpCiAgICAgIChsZXQgKChlbmQg
KC0gKGx1Y2lkOjpwcm9jZWR1cmUtbGVuZ3RoIGJwaSkgMikpKQoJKGRvICgoaSAzICgxKyBpKSkK
CSAgICAgKGFucyBuaWwpKQoJICAgICgoPiBpIGVuZCkgYW5zKQoJICAgIChsZXQgKChsb2NleHAg
KHN2cmVmIGJwaSBpKSkpCgkgICAgICAoaWYgKHN5bWJvbHAgbG9jZXhwKSAocHVzaCBsb2NleHAg
YW5zKSkpKSkpKQoKIy1MdWNpZAooZGVmdW4gTElTVE9GRlJFRVMgKGJwaSkKIChkZWNsYXJlIChp
Z25vcmUgYnBpKSkKICgpKQpACgpcc2VjdGlvbntPcGVyYXRpb25zIG9uIEFyYml0cmFyeSBPYmpl
Y3RzfQpcbGFiZWx7c2VjOk9wZXJhdGlvbnNPbkFyYml0cmFyeU9iamVjdHN9Cgpcc3Vic2VjdGlv
bntDcmVhdGlvbn0KXGxhYmVse3NlYzpPcGVyYXRpb25zT25BcmJpdHJhcnlPYmplY3RzQ3JlYXRp
b259Cgo8PHN1YnN0Pj49CihkZWZ1biBNU1VCU1QgKG5ldyBvbGQgdHJlZSkgKHN1YnN0IG5ldyBv
bGQgdHJlZSA6dGVzdCAjJ2VxdWFsKSkKOyBub3RlIHN1YnN0IGlzbid0IGd1YXJhbnRlZWQgdG8g
Y29weQooZGVmdW4gfG5zdWJzdHwgKG5ldyBvbGQgdHJlZSkgKG5zdWJzdCBuZXcgb2xkIHRyZWUg
OnRlc3QgIydlcXVhbCkpCkAKCjw8Y29weT4+PQooZGVmdW4gY29weSAoeCkgKGNvcHktdHJlZSB4
KSkgOyBub3QgcmlnaHQgc2luY2Ugc2hvdWxkIGRlc2NlbmQgdmVjdG9ycwpACgo8PGVxc3Vic3Rs
aXN0Pj49CihkZWZ1biBlcXN1YnN0bGlzdCAobmV3IG9sZCBsaXN0KSAoc3VibGlzIChtYXBjYXIg
Iydjb25zIG9sZCBuZXcpIGxpc3QpKQpACgoKCjw8ZGNxZXhwPj49CjsgR2VuIGNvZGUgZm9yIFNF
VFFQIGV4cHIKCihldmFsLXdoZW4gKGNvbXBpbGUgbG9hZCBldmFsKQogKGRlZnVuIERDUUVYUCAo
Rk9STSBFUVRBRykKICAoUFJPRyAoU1YgcHZsIGF2bCBDT0RFKQogICAgICAgIChkZWNsYXJlIChz
cGVjaWFsIHB2bCBhdmwpKQogICAgICAgIChzZXRxIFNWIChHRU5TWU0pKQogICAgICAgIChzZXRx
IENPREUgKERDUUdFTkVYUCBTViBGT1JNIEVRVEFHIE5JTCkpCiAgICAgICAgKFJFVFVSTgogICAg
ICAgICAgYChMQU1CREEgKCxzdikKICAgICAgICAgICAgIChQUk9HICxwdmwKICAgICAgICAgICAg
ICAgICAgICxAY29kZQogICAgICAgICAgICAgICAgICAgKFJFVFVSTiAndHJ1ZSkKICAgICAgICAg
ICAgICAgIEJBRCAoUkVUVVJOIE5JTCkgKSApKSkpCikKQAo8PGRjcWdlbmV4cD4+PQo7IEdlbmVy
YXRlIEV4cHIgY29kZSBmb3IgRENRCihldmFsLXdoZW4gKGNvbXBpbGUgbG9hZCBldmFsKQogKGRl
ZnVuIERDUUdFTkVYUCAoU1YgRk9STSBFUVRBRyBRRkxBRykKICAoUFJPRyAoRCBBIEkgTCBDIFcp
CiAgICAgICAgKGRlY2xhcmUgKHNwZWNpYWwgcHZsIGF2bCkpCiAgICAoQ09ORCAoKEVRIEZPUk0g
U1YpIChSRVRVUk4gTklMKSkKICAgICAgICAgICgoSURFTlRQIEZPUk0pIChSRVRVUk4gYCgoc2V0
cSAsZm9ybSAsc3YpKSApKQogICAgICAgICAgKChzaW1wbGUtdmVjdG9yLXAgRk9STSkKICAgICAg
ICAgICAoUkVUVVJOIChTRVEKICAgICAgICAgICAgIChzZXRxIEwgKGxlbmd0aCBGT1JNKSkKICAg
ICAgICAgICAgIChJRiAoRVEgTCAwKQogICAgICAgICAgICAgICAgIChSRVRVUk4gKENPTkQgKChO
VUxMIFFGTEFHKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGAoKGNvbmQgKChub3Qg
KHNpbXBsZS12ZWN0b3ItcCAsc3YpKSAoZ28gYmFkKSkpKSkpKSkKICAgICAgICAgICAgIChzZXRx
IEkgKDEtIEwpKQogICAgICAgICBMUCAgKHNldHEgQSAoZWx0IEZPUk0gSSkpCiAgICAgICAgICAg
ICAoQ09ORCAoKEFORCAoTlVMTCBXKSAoT1IgKGNvbnNwIEEpIChzaW1wbGUtdmVjdG9yLXAgQSkp
KQogICAgICAgICAgICAgICAgICAgIChDT05EICgoY29uc3AgQVZMKSAoc2V0cSBXIChjYXIgKFJF
U0VUUSBBVkwgKGNkciBBVkwpKSkpKQogICAgICAgICAgICAgICAgICAgICAgICAgICgoc2V0cSBQ
VkwgKENPTlMgKHNldHEgVyAoR0VOU1lNKSkgUFZMKSkpKSkpCiAgICAgICAgICAgICAoc2V0cSBD
IChOQ09OQyAoQ09ORCAoKElERU5UUCBBKSBgKChzZXRxICxhIChFTFQgLHN2ICxpKSkpKQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKChPUiAoY29uc3AgQSkgKHNpbXBsZS12ZWN0
b3ItcCBBKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBgKChzZXRxICx3IChF
TFQgLHN2ICxpKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICxAKGRjcWdl
bmV4cCB3IGEgZXF0YWcgcWZsYWcpKSkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDKSkK
ICAgICAgICAgICAgIChpZiAoRVEgSSAwKSAoR08gUkVUKSkKICAgICAgICAgICAgIChzZXRxIEkg
KDEtIEkpKQogICAgICAgICAgICAgKEdPIExQKQogICAgICAgICBSRVQgKGlmIFcgKHNldHEgQVZM
IChDT05TIFcgQVZMKSkpCiAgICAgICAgICAgICAoQ09ORCAoKE5VTEwgUUZMQUcpCiAgICAgICAg
ICAgICAgICAgICAgYCgoQ09ORCAoKE9SIChOT1QgKHNpbXBsZS12ZWN0b3ItcCAsc3YpKSAoPCAo
bGVuZ3RoICxzdikgLGwpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIChHTyBCQUQpKSkK
ICAgICAgICAgICAgICAgICAgICAgICxAYykpCiAgICAgICAgICAgICAgICAgICAoJ1QgQykpKSkp
CiAgICAgICAgICAoKE5PVCAoY29uc3AgRk9STSkpIChSRVRVUk4gTklMKSkKICAgICAgICAgICgo
QU5EIEVRVEFHIChFUSAoY2FyIEZPUk0pIEVRVEFHKSkKICAgICAgICAgICAoUkVUVVJOCiAgICAg
ICAgICAgICAoQ09ORAogICAgICAgICAgICAgICAoKE9SIChOT1QgKEVRIDMgKExFTkdUSCBGT1JN
KSkpIChOT1QgKElERU5UUCAoY2FyIChzZXRxIEZPUk0gKGNkciBGT1JNKSkpKSkpCiAgICAgICAg
ICAgICAgICAoTUFDUk8tSU5WQUxJREFSR1MgJ0RDUVwvUURDUSBGT1JNIChNQUtFU1RSSU5HICJp
bnZhbGlkIHBhdHRlcm4uIikpKQogICAgICAgICAgICAgICAoYCgoc2V0cSAsKGNhciBmb3JtKSAs
c3YpICAsQChEQ1FHRU5FWFAgU1YgKENBRFIgRk9STSkgRVFUQUcgUUZMQUcpKSkpKSkpCiAgICAo
c2V0cSBBIChjYXIgRk9STSkpCiAgICAoc2V0cSBEIChjZHIgRk9STSkpCiAgICAoc2V0cSBDIChD
T05EICgoSURFTlRQIEEpIGAoKHNldHEgLGEgKENBUiAsc3YpKSkpCiAgICAgICAgICAgICAgICAg
ICgoT1IgKGNvbnNwIEEpIChzaW1wbGUtdmVjdG9yLXAgQSkpCiAgICAgICAgICAgICAgICAgICAo
Q09ORCAoKEFORCAoTlVMTCBEKSAoSURFTlRQIFNWKSkgKQogICAgICAgICAgICAgICAgICAgICAg
ICAgKChDT05EICgoY29uc3AgQVZMKSAoc2V0cSBXIChjYXIgKFJFU0VUUSBBVkwgKGNkciBBVkwp
KSkpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgoc2V0cSBQVkwgKENPTlMgKHNl
dHEgVyAoR0VOU1lNKSkgUFZMKSkgKSApICkgKQogICAgICAgICAgICAgICAgICAgKENPTkQgKChB
TkQgKGNvbnNwIEEpIEVRVEFHIChFUSAoY2FyIEEpIEVRVEFHKSkKICAgICAgICAgICAgICAgICAg
ICAgICAgICAoRENRR0VORVhQIChMSVNUICdDQVIgU1YpIEEgRVFUQUcgUUZMQUcpICkKICAgICAg
ICAgICAgICAgICAgICAgICAgIChgKChzZXRxICwob3IgdyBzdikgKENBUiAsc3YpKQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgLEAoRENRR0VORVhQIChPUiBXIFNWKSBBIEVRVEFHIFFGTEFH
KSkpKSkpKQogICAgKHNldHEgQyAoTkNPTkMgQyAoQ09ORCAoKElERU5UUCBEKSBgKChzZXRxICxk
IChDRFIgLHN2KSkpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAoKE9SIChjb25zcCBEKSAo
c2ltcGxlLXZlY3Rvci1wIEQpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgKENPTkQKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKChPUiBXIChJREVOVFAgU1YpKSApCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICgoQ09ORCAoKGNvbnNwIEFWTCkKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAoc2V0cSBXIChjYXIgKFJFU0VUUSBBVkwgKGNkciBBVkwp
KSkpICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgoc2V0cSBQVkwgKENP
TlMgKHNldHEgVyAoR0VOU1lNKSkgUFZMKSkgKSApICkgKQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgKENPTkQgKChBTkQgKGNvbnNwIEQpIEVRVEFHIChFUSAoY2FyIEQpIEVRVEFHKSkKICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoRENRR0VORVhQIChMSVNUICdDRFIgU1Yp
IEQgRVFUQUcgUUZMQUcpICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChgKChz
ZXRxICwob3IgdyBzdikgKENEUiAsc3YpKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgLEAoRENRR0VORVhQIChPUiBXIFNWKSBEIEVRVEFHIFFGTEFHKSkpKSkpKSkKICAgIChD
T05EIChXIChzZXRxIEFWTCAoQ09OUyBXIEFWTCkpKSkKICAgIChSRVRVUk4gKENPTkQgKChOVUxM
IFFGTEFHKSBgKChDT05EICgoQVRPTSAsc3YpIChHTyBCQUQpKSkgLEBjKSkgKEMpKSkpKQopCkAK
ClxzdWJzZWN0aW9ue1NlYXJjaGluZ30KXGxhYmVse3NlYzpPcGVyYXRpb25zT25BcmJpdHJhcnlP
YmplY3RzU2VhcmNoaW5nfQoKPDxlY3FleHA+Pj0KOyBHZW5lcmF0ZSBjb2RlIGZvciBFUVEKCihl
dmFsLXdoZW4gKGNvbXBpbGUgbG9hZCBldmFsKQogKGRlZnVuIEVDUUVYUCAoRk9STSBRRkxBRykK
ICAoUFJPRyAoU1YgUFZMIENPREUpCiAgICAgICAgKGRlY2xhcmUgKHNwZWNpYWwgcHZsKSkKICAg
ICAgICAoc2V0cSBTViAoR0VOU1lNKSkKICAgICAgICAoc2V0cSBDT0RFIChFQ1FHRU5FWFAgU1Yg
Rk9STSBRRkxBRykpCiAgICAgICAgKFJFVFVSTgogICAgICAgICAgICAgIGAoTEFNQkRBICgsc3Yp
CiAgICAgICAgICAgICAgICAgKFBST0cgLHB2bAogICAgICAgICAgICAgICAgICAgICAgICxAY29k
ZQogICAgICAgICAgICAgICAgICAgICAgIChSRVRVUk4gJ3RydWUpCiAgICAgICAgICAgICAgICAg
ICAgQkFEIChSRVRVUk4gTklMKSApICkpKSkKKQpACgo8PGVjcWdlbmV4cD4+PQo7IEdlbmVyYXRl
IGNvZGUgZm9yIEVRUSBpbm5hcmRzCgooZXZhbC13aGVuIChjb21waWxlIGxvYWQgZXZhbCkKIChk
ZWZ1biBFQ1FHRU5FWFAgKFNWIEZPUk0gUUZMQUcpCiAgKFBST0cgKEQgQSBJIEwgQyBXKQogICAg
ICAgIChkZWNsYXJlIChzcGVjaWFsIHB2bCkpCiAgICAgICAgKENPTkQKICAgICAgICAgICgoRVEg
Rk9STSBTVikgKFJFVFVSTiBOSUwpKQogICAgICAgICAgKChPUgogICAgICAgICAgICAgIChJREVO
VFAgRk9STSkKICAgICAgICAgICAgICAoTlVNUCBGT1JNKQogICAgICAgICAgICAgIChBTkQgKGNv
bnNwIEZPUk0pIChFUSAocWNhciBGT1JNKSAnUVVPVEUpKSkKICAgICAgICAgICAoUkVUVVJOCiAg
ICAgICAgICAgICBgKChDT05EICgoTk9UIChFUSAsZm9ybSAsc3YpKSAoR08gQkFEKSkpICkpKQog
ICAgICAgICAgKChzaW1wbGUtdmVjdG9yLXAgRk9STSkKICAgICAgICAgICAoUkVUVVJOIChTRVEK
ICAgICAgICAgICAgICAoc2V0cSBMIChsZW5ndGggRk9STSkpCiAgICAgICAgICAgICAgKGlmIChF
USBMIDApCiAgICAgICAgICAgICAgICAgIChSRVRVUk4KICAgICAgICAgICAgICAgICAgICAoQ09O
RCAoKE5VTEwgUUZMQUcpCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGAoKENPTkQgKChOT1Qg
KHNpbXBsZS12ZWN0b3ItcCAsc3YpKSAoR08gQkFEKSkpICkpKQogICAgICAgICAgICAgICAgICAg
ICkpCiAgICAgICAgICAgICAgKHNldHEgSSAoMS0gTCkpCiAgICAgICAgICAgTFAgKHNldHEgQSAo
ZWx0IEZPUk0gSSkpCiAgICAgICAgICAgICAgKGlmIChBTkQgKE5VTEwgVykgKE9SIChjb25zcCBB
KSAoc2ltcGxlLXZlY3Rvci1wIEEpKSkKICAgICAgICAgICAgICAgICAgKHB1c2ggKHNldHEgVyAo
R0VOU1lNKSkgUFZMKSkKICAgICAgICAgICAgICAoc2V0cSBDCiAgICAgICAgICAgICAgICAgICAg
KE5DT05DCiAgICAgICAgICAgICAgICAgICAgICAoQ09ORAogICAgICAgICAgICAgICAgICAgICAg
ICAoIChPUgogICAgICAgICAgICAgICAgICAgICAgICAgICAgKElERU5UUCBBKQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgKE5VTVAgQSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgIChB
TkQgKGNvbnNwIEEpIChFUSAocWNhciBBKSAnUVVPVEUpKSkKICAgICAgICAgICAgICAgICAgICAg
ICAgIGAoKENPTkQgKCAoTk9UIChFUSAsYSAoRUxUICxzdiAsaSkpKQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgKEdPIEJBRCkgKSApICkgKQogICAgICAgICAgICAgICAgICAgICAg
ICAoIChPUiAoY29uc3AgQSkgKHNpbXBsZS12ZWN0b3ItcCBBKSkKICAgICAgICAgICAgICAgICAg
ICAgICAgIGAoKHNldHEgLHcgKEVMVCAsc3YgLGkpKQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAsQChFQ1FHRU5FWFAgVyBBIFFGTEFHKSkpKQogICAgICAgICAgICAgICAgICAgICAgQykgKQog
ICAgICAgICAgICAgIChpZiAoRVEgSSAwKSAoR08gUkVUKSApCiAgICAgICAgICAgICAgKHNldHEg
SSAoMS0gSSkpCiAgICAgICAgICAgICAgKEdPIExQKQogICAgICAgICAgIFJFVAogICAgICAgICAg
ICAgIChDT05ECiAgICAgICAgICAgICAgICAoIChOVUxMIFFGTEFHKQogICAgICAgICAgICAgICAg
IGAoKENPTkQgKCAoT1IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoTk9UIChzaW1wbGUt
dmVjdG9yLXAgLHN2KSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoPCAobGVuZ3RoICxz
dikgLGwpKQogICAgICAgICAgICAgICAgICAgICAgICAgIChHTyBCQUQpICkgKQogICAgICAgICAg
ICAgICAgICAgLEBjKSkKICAgICAgICAgICAgICAgICggJ1QgQyApICkpICkpCiAgICAgICAgICAo
IChOT1QgKGNvbnNwIEZPUk0pKQogICAgICAgICAgIChSRVRVUk4gTklMKSApICkKICAgICAgICAo
c2V0cSBBIChjYXIgRk9STSkpCiAgICAgICAgKHNldHEgRCAoY2RyIEZPUk0pKQogICAgICAgIChp
ZiAoT1IgKGNvbnNwIEEpIChzaW1wbGUtdmVjdG9yLXAgQSkgKGNvbnNwIEQpIChzaW1wbGUtdmVj
dG9yLXAgRCkpCiAgICAgICAgICAgKHNldHEgUFZMIChDT05TIChzZXRxIFcgKEdFTlNZTSkpIFBW
TCkpKQogICAgICAgIChzZXRxIEMKICAgICAgICAgICAgICAoQ09ORAogICAgICAgICAgICAgICAg
KCAoT1IgKElERU5UUCBBKSAoTlVNUCBBKSAoQU5EIChjb25zcCBBKSAoRVEgKGNhciBBKSAnUVVP
VEUpKSkKICAgICAgICAgICAgICAgICBgKChDT05EICgoTk9UIChFUSAsYSAoQ0FSICxzdikpKSAo
R08gQkFEKSkpICkpCiAgICAgICAgICAgICAgICAoIChPUiAoY29uc3AgQSkgKHNpbXBsZS12ZWN0
b3ItcCBBKSkKICAgICAgICAgICAgICAgICBgKChzZXRxICx3IChDQVIgLHN2KSkKICAgICAgICAg
ICAgICAgICAgICxAKEVDUUdFTkVYUCBXIEEgUUZMQUcpKSkpKQogICAgICAgIChzZXRxIEMKICAg
ICAgICAgICAgICAoTkNPTkMKICAgICAgICAgICAgICAgIEMKICAgICAgICAgICAgICAgIChDT05E
CiAgICAgICAgICAgICAgICAgICggKE9SIChJREVOVFAgRCkgKE5VTVAgRCkgKEFORCAoY29uc3Ag
RCkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChFUSAo
Y2FyIEQpICdRVU9URSkpKQogICAgICAgICAgICAgICAgICAgYCgoQ09ORCAoKE5PVCAoRVEgLGQg
KENEUiAsc3YpKSkgKEdPIEJBRCkpKSApKQogICAgICAgICAgICAgICAgICAoIChPUiAoY29uc3Ag
RCkgKHNpbXBsZS12ZWN0b3ItcCBEKSkKICAgICAgICAgICAgICAgICAgIGAoKHNldHEgLHN2IChD
RFIgLHN2KSkKICAgICAgICAgICAgICAgICAgICAgLEAoRUNRR0VORVhQIFNWIEQgUUZMQUcpKSkp
KSkKICAgICAgICAoUkVUVVJOCiAgICAgICAgICAoQ09ORAogICAgICAgICAgICAoIChOVUxMIFFG
TEFHKQogICAgICAgICAgICAgYCgoQ09ORCAoIChBVE9NICxzdikKICAgICAgICAgICAgICAgICAg
ICAgIChHTyBCQUQpICkgKQogICAgICAgICAgICAgICAsQGMpKQogICAgICAgICAgICAoICdUCiAg
ICAgICAgICAgICBDICkgKSkgKSApCikKQAoKXHN1YnNlY3Rpb257VXBkYXRpbmd9ClxsYWJlbHtz
ZWM6T3BlcmF0aW9uc09uQXJiaXRyYXJ5T2JqZWN0c1VwZGF0aW5nfQoKPDxyY3FleHA+Pj0KOyBH
ZW5lcmF0ZSBjb2RlIGZvciBSUExRIGV4cHJzCgooZXZhbC13aGVuIChjb21waWxlIGxvYWQgZXZh
bCkKIChkZWZ1biBSQ1FFWFAgKEZPUk0pCiAgICAoUFJPRyAoU1YgUFZMIENPREUpCiAgICAgICAg
ICAoZGVjbGFyZSAoc3BlY2lhbCBwdmwpKQogICAgICAoc2V0cSBTViAoR0VOU1lNKSkKICAgICAg
KHNldHEgQ09ERSAoUkNRR0VORVhQIFNWIEZPUk0gTklMKSkKICAgICAgKFJFVFVSTgogICAgICAg
IGAoTEFNQkRBICgsc3YpCiAgICAgICAgICAgICAgKFBST0cgLHB2bAogICAgICAgICAgICAgICAg
LEBjb2RlCiAgICAgICAgICAgICAgICAoUkVUVVJOICd0cnVlKQogICAgICAgICAgICBCQUQgKFJF
VFVSTiBOSUwpICkgKSkpKQopCkAKCjw8cmNxZ2VuZXhwPj49CjsgR2VuZXJhdGUgY29kZSBmb3Ig
UlBMUSBleHByIGlubmFyZHMKCihldmFsLXdoZW4gKGNvbXBpbGUgbG9hZCBldmFsKQogKGRlZnVu
IFJDUUdFTkVYUCAoU1YgRk9STSBRRkxBRykKICAgIChQUk9HIChEIEEgSSBMIEMgVykKICAgICAg
ICAgIChkZWNsYXJlIChzcGVjaWFsIHB2bCkpCiAgICAgIChDT05ECiAgICAgICAgKCAoRVEgRk9S
TSBTVikKICAgICAgICAgIChSRVRVUk4gTklMKSApCiAgICAgICAgKCAoc2ltcGxlLXZlY3Rvci1w
IEZPUk0pCiAgICAgICAgIChSRVRVUk4gKFNFUQogICAgICAgICAgICAoc2V0cSBMIChsZW5ndGgg
Rk9STSkpCiAgICAgICAgICAgIChpZiAoRVEgTCAwKSAoUkVUVVJOIE5JTCkpCiAgICAgICAgICAg
IChzZXRxIEkgKDEtIEwpKQogICAgICAgIExQICAoc2V0cSBBIChlbHQgRk9STSBJKSkKICAgICAg
ICAgICAgKENPTkQKICAgICAgICAgICAgICAoIChBTkQKICAgICAgICAgICAgICAgICAgKE5VTEwg
VykKICAgICAgICAgICAgICAgICAgKE9SIChBTkQgKGNvbnNwIEEpIChOT1QgKEVRIChjYXIgQSkg
J1FVT1RFKSkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgIChzaW1wbGUtdmVjdG9yLXAgQSkp
KQogICAgICAgICAgICAgICAgKHNldHEgUFZMIChDT05TIChzZXRxIFcgKEdFTlNZTSkpIFBWTCkp
ICkgKQogICAgICAgICAgICAoc2V0cSBDCiAgICAgICAgICAgICAgKE5DT05DCiAgICAgICAgICAg
ICAgICAoQ09ORAogICAgICAgICAgICAgICAgICAoIChPUgogICAgICAgICAgICAgICAgICAgICAg
KElERU5UUCBBKQogICAgICAgICAgICAgICAgICAgICAgKE5VTVAgQSkKICAgICAgICAgICAgICAg
ICAgICAgIChBTkQgKGNvbnNwIEEpIChFUSAoY2FyIEEpICdRVU9URSkpKQogICAgICAgICAgICAg
ICAgICAgIGAoKFNFVEVMVCAsc3YgLGkgLGEpKSkKICAgICAgICAgICAgICAgICAgKCAoT1IgKGNv
bnNwIEEpIChzaW1wbGUtdmVjdG9yLXAgQSkpCiAgICAgICAgICAgICAgICAgICAgYCgoc2V0cSAs
dyAoRUxUICxzdiAsaSkpCiAgICAgICAgICAgICAgICAgICAgICAsQChSQ1FHRU5FWFAgVyBBIFFG
TEFHKSkpKQogICAgICAgICAgICAgICAgQykgKQogICAgICAgICAgICAoQ09ORAogICAgICAgICAg
ICAgICggKEVRIEkgMCkKICAgICAgICAgICAgICAgIChHTyBSRVQpICkgKQogICAgICAgICAgICAo
c2V0cSBJICgxLSBJKSkKICAgICAgICAgICAgKEdPIExQKQogICAgICAgIFJFVCAoUkVUVVJOCiAg
ICAgICAgICAgICAgKENPTkQKICAgICAgICAgICAgICAgICggKE5VTEwgUUZMQUcpCiAgICAgICAg
ICAgICAgICAgIGAoKENPTkQgKCAoT1IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKE5P
VCAoc2ltcGxlLXZlY3Rvci1wICxzdikpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICg8
IChsZW5ndGggLHN2KSAsbCkpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAoR08gQkFEKSAp
ICkKICAgICAgICAgICAgICAgICAgICAsQGMpKQogICAgICAgICAgICAgICAgKCAnVAogICAgICAg
ICAgICAgICAgICBDICkgKSkgKSkpCiAgICAgICAgKCAoTk9UIChjb25zcCBGT1JNKSkKICAgICAg
ICAgIChSRVRVUk4gTklMKSApICkKICAgICAgKHNldHEgQSAoY2FyIEZPUk0pKQogICAgICAoc2V0
cSBEIChjZHIgRk9STSkpCiAgICAgIChjb25kCiAgICAgICAgKCAob3IgKGFuZCAoY29uc3AgQSkg
KE5PVCAoRVEgKGNhciBBKSAnUVVPVEUpKSkgKHNpbXBsZS12ZWN0b3ItcCBBKSkKICAgICAgICAg
IChzZXRxIFBWTCAoQ09OUyAoc2V0cSBXIChHRU5TWU0pKSBQVkwpKSApICkKICAgICAgKHNldHEg
QwogICAgICAgIChDT05ECiAgICAgICAgICAoIChPUiAoSURFTlRQIEEpIChOVU1QIEEpIChBTkQg
KGNvbnNwIEEpIChFUSAoY2FyIEEpICdRVU9URSkpKQogICAgICAgICAgICBgKChycGxhY2EgLHN2
ICxhKSkpCiAgICAgICAgICAoIChPUiAoY29uc3AgQSkgKHNpbXBsZS12ZWN0b3ItcCBBKSkKICAg
ICAgICAgICAgYCgoc2V0cSAsdyAoQ0FSICxzdikpCiAgICAgICAgICAgICAgLEAoUkNRR0VORVhQ
IFcgQSBRRkxBRykpKSkpCiAgICAgIChzZXRxIEMKICAgICAgICAoTkNPTkMKICAgICAgICAgIEMK
ICAgICAgICAgIChDT05ECiAgICAgICAgICAgICggKE9SIChJREVOVFAgRCkgKE5VTVAgRCkgKEFO
RCAoY29uc3AgRCkgKEVRIChjYXIgRCkgJ1FVT1RFKSkpCiAgICAgICAgICAgICAgYCgoUlBMQUNE
ICxzdiAsZCkpKQogICAgICAgICAgICAoIChPUiAoY29uc3AgRCkgKHNpbXBsZS12ZWN0b3ItcCBE
KSkKICAgICAgICAgICAgICBgKChzZXRxICxzdiAoQ0RSICxzdikpCiAgICAgICAgICAgICAgICAs
QChSQ1FHRU5FWFAgU1YgRCBRRkxBRykpKSkpKQogICAgICAoUkVUVVJOCiAgICAgICAgKENPTkQK
ICAgICAgICAgICggKE5VTEwgUUZMQUcpCiAgICAgICAgICAgIGAoKENPTkQgKCAoQVRPTSAsc3Yp
CiAgICAgICAgICAgICAgICAgICAgICAoR08gQkFEKSApICkKICAgICAgICAgICAgICAsQGMpKQog
ICAgICAgICAgKCAnVAogICAgICAgICAgICBDICkgKSkgKSApCikKQAoKXHNlY3Rpb257Q2FsbCBU
cmFjaW5nfQpcbGFiZWx7c2VjOkNhbGxUcmFjaW5nfQoKPDxlbWJlZGRlZD4+PQooZGVmdW4gRU1C
RURERUQgKCkgKG1hcGNhciAjJ2NhciAqZW1iZWRkZWQtZnVuY3Rpb25zKikpCkAKCjw8ZW1iZWQ+
Pj0KKGRlZnVuIEVNQkVEIChDVVJSRU5ULUJJTkRJTkcgTkVXLURFRklOSVRJT04pCiAgKFBST0cK
Iys6Q0NMIChPUCBCViBCT0RZIE9MRC1ERUYgKkNPTVApCiMtOkNDTCAoT1AgQlYgQk9EWSBPTEQt
REVGKQogICAgICAoQ09ORAogICAgICAgICggKE5PVCAoSURFTlRQIENVUlJFTlQtQklORElORykp
CiAgICAgICAgICAoU0VUUSBDVVJSRU5ULUJJTkRJTkcKICAgICAgICAgICAgICAgIChlcnJvciAo
Zm9ybWF0IG5pbCAiaW52YWxpZCBhcmd1bWVudCB+cyB0byBFTUJFRCIgQ1VSUkVOVC1CSU5ESU5H
KSkpICkgKQogICAgICAoU0VUUSBPTEQtREVGIChzeW1ib2wtZnVuY3Rpb24gQ1VSUkVOVC1CSU5E
SU5HKSkKICAgICAgKFNFVFEgTkVXLURFRklOSVRJT04KICAgICAgICAoU0VURiAoc3ltYm9sLWZ1
bmN0aW9uIENVUlJFTlQtQklORElORykKICAgICAgICAgIChDT05ECiAgICAgICAgICAgICggKE5P
VCAoY29uc3AgTkVXLURFRklOSVRJT04pKQogICAgICAgICAgICAgIE5FVy1ERUZJTklUSU9OICkK
ICAgICAgICAgICAgKCAoQU5ECiAgICAgICAgICAgICAgICAoRENRIChPUCBCViAuIEJPRFkpIE5F
Vy1ERUZJTklUSU9OKQogICAgICAgICAgICAgICAgKE9SIChFUSBPUCAnTEFNQkRBKSAoRVEgT1Ag
J01MQU1CREEpKSkKICAgICAgICAgICAgICAoQ09ORAogICAgICAgICAgICAgICAgKCAoTk9UIChN
RU1RIENVUlJFTlQtQklORElORyAoRkxBVC1CVi1MSVNUIEJWKSkpCiAgICAgICAgICAgICAgICAg
YCgsT1AgLEJWICgoTEFNQkRBICgsQ1VSUkVOVC1CSU5ESU5HKSAuICxCT0RZKSAnLE9MRC1ERUYp
KQogICAgICAgICAgICAgICAgICAgKQogICAgICAgICAgICAgICAgKCAnVAogICAgICAgICAgICAg
ICAgICBORVctREVGSU5JVElPTiApICkgKQogICAgICAgICAgICAoICdUCiAgICAgICAgICAgICAg
YCgoTEFNQkRBICgsQ1VSUkVOVC1CSU5ESU5HKSAsTkVXLURFRklOSVRJT04pICcsT0xELURFRikp
KQogICAgICAgICAgICApICkKIys6Q0NMIChJRiAoQ09OU1AgTkVXLURFRklOSVRJT04pIChTRVRR
IE5FVy1ERUZJTklUSU9OIChDRFIgTkVXLURFRklOSVRJT04pKSkKICAgICAgKHB1c2ggKExJU1Qg
Q1VSUkVOVC1CSU5ESU5HIE5FVy1ERUZJTklUSU9OIE9MRC1ERUYpICplbWJlZGRlZC1mdW5jdGlv
bnMqKQogICAgICAoUkVUVVJOIENVUlJFTlQtQklORElORykgKSApCkAKCjw8dW5lbWJlZD4+PQoo
ZGVmdW4gVU5FTUJFRCAoQ1VSUkVOVC1CSU5ESU5HKQogICAgKFBST0cKIys6Q0NMICAoVE1QIEUt
TElTVCBDVVItREVGICpDT01QKQojLTpDQ0wgIChUTVAgRS1MSVNUIENVUi1ERUYpCiAgICAgIChT
RVRRIEUtTElTVCAqZW1iZWRkZWQtZnVuY3Rpb25zKikKICAgICAgKFNFVFEgQ1VSLURFRiAoc3lt
Ym9sLWZ1bmN0aW9uIENVUlJFTlQtQklORElORykpCiMrOkNDTCAoSUYgKENPTlNQIENVUi1ERUYp
IChTRVRRIENVUi1ERUYgKENEUiBDVVItREVGKSkpCiAgICAgIChDT05ECiAgICAgICAgKCAoTk9U
IChjb25zcCBFLUxJU1QpKQogICAgICAgICAgTklMICkKICAgICAgICAoIChFQ1EgKChDVVJSRU5U
LUJJTkRJTkcgQ1VSLURFRikpIEUtTElTVCkKICAgICAgICAgIChTRVRGIChzeW1ib2wtZnVuY3Rp
b24gQ1VSUkVOVC1CSU5ESU5HKSAoUUNBRERBUiBFLUxJU1QpKQogICAgICAgICAgKFNFVFEgKmVt
YmVkZGVkLWZ1bmN0aW9ucyogKFFDRFIgRS1MSVNUKSkKICAgICAgICAgIChSRVRVUk4gQ1VSUkVO
VC1CSU5ESU5HKSApCiAgICAgICAgKCAnVAogICAgICAgICAgKFNFUQogICAgICAgICAgICAoU0VU
USBUTVAgRS1MSVNUKQogICAgICAgIExQICAoQ09ORAogICAgICAgICAgICAgICggKE5PVCAoY29u
c3AgKFFDRFIgVE1QKSkpCiAgICAgICAgICAgICAgICAoRVhJVCBOSUwpICkKICAgICAgICAgICAg
ICAoIChOVUxMIChFQ1EgKChDVVJSRU5ULUJJTkRJTkcgQ1VSLURFRikpIChRQ0RSIFRNUCkpKQog
ICAgICAgICAgICAgICAgKFNFVFEgVE1QIChRQ0RSIFRNUCkpCiAgICAgICAgICAgICAgICAoR08g
TFApICkKICAgICAgICAgICAgICAoICdUCiAgICAgICAgICAgICAgICAoU0VURiAoc3ltYm9sLWZ1
bmN0aW9uICBDVVJSRU5ULUJJTkRJTkcpIChRQ0FSIChRQ0REQURSIFRNUCkpKQogICAgICAgICAg
ICAgICAgKFJQTEFDRCBUTVAgKFFDRERSIFRNUCkpCiAgICAgICAgICAgICAgICAoUkVUVVJOIENV
UlJFTlQtQklORElORykgKSApICkgKSApCiAgICAgIChSRVRVUk4gTklMKSApKQpACgo8PGZsYXQt
YnYtbGlzdD4+PQooZGVmdW4gRkxBVC1CVi1MSVNUIChCVi1MSVNUKQogIChQUk9HIChUTVAxKQog
ICAgICAoUkVUVVJOCiAgICAgICAgKENPTkQKICAgICAgICAgICggKFZBUlAgQlYtTElTVCkKICAg
ICAgICAgICAgKExJU1QgQlYtTElTVCkgKQogICAgICAgICAgKCAoUkVGVkVDUCBCVi1MSVNUKQog
ICAgICAgICAgICAoRkxBVC1CVi1MSVNUIChWRUMyTElTVCAoTUFQRUxUICMnRkxBVC1CVi1MSVNU
IEJWLUxJU1QpKSkgKQogICAgICAgICAgKCAoTk9UIChjb25zcCBCVi1MSVNUKSkKICAgICAgICAg
ICAgTklMICkKICAgICAgICAgICggKEVRICc9IChTRVRRIFRNUDEgKFFDQVIgQlYtTElTVCkpKQog
ICAgICAgICAgICAoRkxBVC1CVi1MSVNUIChRQ0RSIEJWLUxJU1QpKSApCiAgICAgICAgICAoIChW
QVJQIFRNUDEpCiAgICAgICAgICAgIChDT05TIFRNUDEgKEZMQVQtQlYtTElTVCAoUUNEUiBCVi1M
SVNUKSkpICkKICAgICAgICAgICggKEFORCAoTk9UIChjb25zcCBUTVAxKSkgKE5PVCAoUkVGVkVD
UCBUTVAxKSkpCiAgICAgICAgICAgIChGTEFULUJWLUxJU1QgKFFDRFIgQlYtTElTVCkpICkKICAg
ICAgICAgICggJ1QKICAgICAgICAgICAgKE5DT05DIChGTEFULUJWLUxJU1QgVE1QMSkgKEZMQVQt
QlYtTElTVCAoUUNEUiBCVi1MSVNUKSkpICkgKSkgKSkKQAoKPDx2YXJwPj49CihkZWZ1biBWQVJQ
IChURVNULUlURU0pCiAgICAoQ09ORAogICAgICAoIChJREVOVFAgVEVTVC1JVEVNKQogICAgICAg
IFRFU1QtSVRFTSApCiAgICAgICggKEFORAogICAgICAgICAgKGNvbnNwIFRFU1QtSVRFTSkKICAg
ICAgICAgIChPUiAoRVEgKFFDQVIgVEVTVC1JVEVNKSAnRkxVSUQpIChFUSAoUUNBUiBURVNULUlU
RU0pICdMRVgpKQogICAgICAgICAgKGNvbnNwIChRQ0RSIFRFU1QtSVRFTSkpCiAgICAgICAgICAo
SURFTlRQIChRQ0FEUiBURVNULUlURU0pKSkKICAgICAgICBURVNULUlURU0gKQogICAgICAoICdU
CiAgICAgICAgTklMICkgKSApCkAKClxzZWN0aW9ue01pc2NlbGxhbmVvdXMgRnVuY3Rpb25zfQpc
bGFiZWx7c2VjOk1pc2NlbGxhbmVvdXNGdW5jdGlvbnN9Cgo8PGNoYXJwPj49CihkZWZ1biBjaGFy
cCAoYSkgKG9yIChjaGFyYWN0ZXJwIGEpCiAgICAgICAgICAgICAgICAgICAgIChhbmQgKGlkZW50
cCBhKSAoPSAobGVuZ3RoIChzeW1ib2wtbmFtZSBhKSkgMSkpKSkKQAoKPDxjaGFyMm51bT4+PQoo
ZGVmdW4gTlVNMkNIQVIgKG4pIChjb2RlLWNoYXIgbikpCgooZGVmdW4gQ0hBUjJOVU0gKGMpIChj
aGFyLWNvZGUgKGNoYXJhY3RlciBjKSkpCkAKCjw8bGFtLGV2YWxhbmRmaWxlYWN0cT4+PQooZGVm
dW4gTEFNXCxFVkFMQU5ERklMRUFDVFEgKG5hbWUgJm9wdGlvbmFsIChmb3JtIG5hbWUpKQogICAg
KExBTVwsRklMRUFDVFEgbmFtZSBmb3JtKSAoZXZhbCBmb3JtKSkKCihkZWZ1biBMQU1cLEZJTEVB
Q1RRIChuYW1lIGZvcm0pCiAgICAgICAoaWYgKkZJTEVBQ1RRLUFQUExZKiAoRlVOQ0FMTCAqRklM
RUFDVFEtQVBQTFkqIG5hbWUgZm9ybSkpKQpACjw8b3JhZGR0ZW1wZGVmcz4+PQooZGVmbWFjcm8g
b3JhZGR0ZW1wZGVmcyAoZmlsZWFyZykKIGAoZXZhbC13aGVuIChjb21waWxlKSAobG9hZCAsZmls
ZWFyZykpKQpACgo8PHBsYWNlcD4+PQooZGVmdW4gUExBQ0VQIChpdGVtKSAoZXEgaXRlbSAqcmVh
ZC1wbGFjZS1ob2xkZXIqKSkKQAoKPDxsYW0+Pj0KKGRlZm1hY3JvIGxhbSAoJnJlc3QgYm9keSkK
IChsaXN0ICdxdW90ZSAoKmxhbSAoY29weS10cmVlIGJvZHkpKSkpCkAKCjw8cXJwbHE+Pj0KKGRl
Zm1hY3JvIHFycGxxICgmd2hvbGUgZm9ybSBwYXR0ZXJuIGV4cCkKIChpZiAob3IgKGNvbnNwIHBh
dHRlcm4pIChzaW1wbGUtdmVjdG9yLXAgcGF0dGVybikpCiAgYCgsKHJjcWV4cCBwYXR0ZXJuKSAs
ZXhwKQogICAobWFjcm8taW52YWxpZGFyZ3MgJ3FycGxxIGZvcm0gImZvcm0gbXVzdCBiZSB1cGRh
dGVhYmxlLiIpKSkKQAoKPDxcJHNob3dsaW5lPj49CjsgVGhlIGZvbGxvd2luZyBzaG91bGQgYWN0
dWFsbHkgcG9zaXRpb24gdGhlIGN1cnNvciBhdCB0aGUgc2ludCd0aCBsaW5lIG9mIHRoZSBzY3Jl
ZW46CgooZGVmdW4gJHNob3dsaW5lIChjdmVjIHNpbnQpICh0ZXJwcmkpIHNpbnQgKHByaW5jIGN2
ZWMpKQpACgo8PG51bWJlcm9mYXJncz4+PQojK0x1Y2lkCihkZWZ1biBudW1iZXJvZmFyZ3MgKHgp
CiAgKHNldHEgeCAoc3lzdGVtOjphcmdsaXN0IHgpKQogIChsZXQgKChueCAoLSAobGVuZ3RoIHgp
IChsZW5ndGggKG1lbXEgJyZhdXggeCkpKSkpCiAgICAoaWYgKG1lbXEgJyZyZXN0IHgpIChzZXRx
IG54ICgtICgxLSBueCkpKSkKICAgIChpZiAobWVtcSAnJm9wdGlvbmFsIHgpIChzZXRxIG54ICgt
ICgxLSAoYWJzIG54KSkpKSkKICAgIG54KSkKQAoKPDxcJHRvdGFsLWVsYXBzZWQtdGltZT4+PQoo
ZGVmdW4gJFRPVEFMLUVMQVBTRUQtVElNRSAoKQogICAobGlzdCAoZ2V0LWludGVybmFsLXJ1bi10
aW1lKSAoZ2V0LWludGVybmFsLXJlYWwtdGltZSkpKQpACgo8PHxjaGFyfD4+PQooZGVmbWFjcm8g
fGNoYXJ8ICh4KQogIChpZiAoYW5kIChjb25zcCB4KSAoZXEgKGNhciB4KSAncXVvdGUpKSAoY2hh
cmFjdGVyIChjYWRyIHgpKQogICAgYChjaGFyYWN0ZXIgLHgpKSkKQAoKPDxkY3E+Pj0KKGRlZm1h
Y3JvIGRjcSAoJnJlc3QgYXJncykKIChjb25zICdzZXRxcCBhcmdzKSkKQAoKPDxlY3E+Pj0KKGRl
Zm1hY3JvIGVjcSAoJnJlc3QgYXJncykKIChjb25zICdlcXEgYXJncykpCkAKPDxlcXE+Pj0KKGRl
Zm1hY3JvIGVxcSAocGF0dGVybiBleHApCiBgKCwoZWNxZXhwIHBhdHRlcm4gbmlsKSAsZXhwKSkK
QAo8PHFlcXE+Pj0KKGRlZm1hY3JvIHFlcXEgKHBhdHRlcm4gZXhwKQogYCgsKGVjcWV4cCBwYXR0
ZXJuIDEpICxleHApKQpACgpUaGUgW1tHRVRMXV0gZnVuY3Rpb24gaXMgCjw8Z2V0bD4+PQo7IEEg
dmVyc2lvbiBvZiBHRVQgdGhhdCB3b3JrcyB3aXRoIGxpc3RzCgo7IChkZWZ1biBnZXRsIChzeW0g
a2V5ICkKOyAgIChjb25kICgoY29uc3Agc3ltKSAoY2RyIChhc3NvYyBrZXkgc3ltIDp0ZXN0ICMn
ZXEpKSkKOyAgICAgICAgICgoc3ltYm9scCBzeW0pIChnZXQgc3ltIGtleSkpKSkKKGRlZnVuIGdl
dGwgKHN5bSBrZXkgKQogIChjb25kICgoY29uc3Agc3ltKSAoY2RyIChhc3NxIGtleSBzeW0pKSkK
ICAgICAgICAoKHN5bWJvbHAgc3ltKSAoZ2V0IHN5bSBrZXkpKSkpCkAKCjw8Y3VycmVudHRpbWU+
Pj0KKGRlZnVuIEN1cnJlbnRUaW1lICgpCiAgKG11bHRpcGxlLXZhbHVlLWJpbmQgKHNlYyBtaW4g
aG91ciBkYXkgbW9udGggeWVhcikgKGdldC1kZWNvZGVkLXRpbWUpCiAgICAoZm9ybWF0IG5pbCAi
fjIsJzBEL34yLCcwRC9+MiwnMER+MiwnMEQ6fjIsJzBEOn4yLCcwRCIKCSAgICBtb250aCBkYXkg
KHJlbSB5ZWFyIDEwMCkgaG91ciBtaW4gc2VjKSkpCkAKCgpUaGUgW1tkc2V0cV1dIGFsaWFzIGlz
IGluY2x1ZGVkIGhlcmUsIGJlY2F1c2Ugbm90aGluZyBlbHNlIGV2ZXIgY2FsbHMKW1tkb0RTRVRR
XV0uCgo8PGRvZHNldHE+Pj0KKGRlZm1hY3JvIGRzZXRxICgmd2hvbGUgZm9ybSBwYXR0ZXJuIGV4
cCkKIChkb2RzZXRxIGZvcm0gcGF0dGVybiBleHApKQoKCjs7IFRoaXMgaXNuJ3QgcmVhbGx5IGNv
bXBhdGlibGUgYnV0IGlzIGFzIGNsb3NlIGFzIHlvdSBjYW4gZ2V0IGluIGNvbW1vbiBsaXNwCjs7
IEluIHBsYWNlIG9mICgob25lLW9mIDEgMiAzKSBsKSAgeW91IHNob3VsZCB1c2UKOzsgICAoZnVu
Y2FsbCAob25lLW9mIDEgMiAzKSBsKQoKKGRlZnVuIGRvRFNFVFEgKGZvcm0gcGF0dGVybiBleHAp
CiAgKGxldCAoUFZMIEFWTCkKICAgIChkZWNsYXJlIChzcGVjaWFsIFBWTCBBVkwpKQogICAgKENP
TkQgKChJREVOVFAgUEFUVEVSTikKICAgICAgICAgICAoTElTVCAnU0VUUSBQQVRURVJOIEVYUCkp
CiAgICAgICAgICAoKEFORCAoTk9UIChjb25zcCBQQVRURVJOKSkgKE5PVCAoc2ltcGxlLXZlY3Rv
ci1wIFBBVFRFUk4pKSkKICAgICAgICAgICAoTUFDUk8tSU5WQUxJREFSR1MgJ0RTRVRRIEZPUk0g
ImNvbnN0YW50IHRhcmdldC4iKSkKICAgICAgICAgICgobGV0KiAoKFNWIChHRU5TWU0pKQogICAg
ICAgICAgICAgICAgICAoRS1QQVJUIChEQ1FHRU5FWFAgKExJU1QgJ0lERU5USVRZIFNWKSBQQVRU
RVJOICc9IE5JTCkpKQogICAgICAgICAgICAgKHNldHEgZS1wYXJ0CiAgICAgICAgICAgICAgICAg
ICBgKExBTUJEQSAoLHN2KQogICAgICAgICAgICAgICAgICAgICAgKFBST0cgLHB2bAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgLEBlLXBhcnQKICAgICAgICAgICAgICAgICAgICAgICAgICAg
IChSRVRVUk4gLHN2KQogICAgICAgICAgICAgICAgICAgICAgICAgQkFEIChSRVRVUk4gKFNFVFFF
UlJPUiAsc3YpKSkpKQogICAgICAgICAgICAgYCgsZS1wYXJ0ICxleHApKSkpKSkKCihkZWZ1biBT
RVRRRVJST1IgKCZyZXN0IEZPUk0pIChlcnJvciAoZm9ybWF0IG5pbCAiaW4gZGVzdHJ1Y3R1cmlu
ZyB+UyIgRk9STSkpKQpACgpcc3Vic2VjdGlvbntlcWNhcn0KXGxhYmVse3NlYzplcWNhcn0KCltb
ZXFjYXJdXSB0ZXN0cyB3ZXRoZXIgdGhlIFtbQ0FSXV0gb2YgW1t4XV0gZXF1YWxzIChpbiBhIGNl
cnRhaW4Kc2Vuc2UpIFtbeV1dLiBJdCB1c2VzIFtbRVFdXSBmb3IgW1tOSUxdXSBhbmQgc3ltYm9s
cywgW1tFUUxdXQpmb3IgaW50ZWdlcnMgYW5kIGFsbCBvdGhlciBMaXNwIG9iamVjdHMuIEl0IHRy
aWVzIHRvIG9wdGltaXplIHRoZQpjb21tb24gY2FzZSBvZiBmaXhudW1zIGZvciBzcGVlZC4KPDxl
cWNhcj4+PQojLTpDQ0wKKGRlZm1hY3JvIGVxY2FyICh4IHkpCiAobGV0ICgodGVzdAogICAgICAg
IChjb25kCiAgICAgICAgICgoZXF1YWJsZSB5KSAnZXEpCgkgKChpbnRlZ2VycCB5KSAnaT0pCgkg
KCdlcWwpKSkpCiAgKGlmIChhdG9tIHgpCiAgIGAoYW5kIChjb25zcCAseCkgKCx0ZXN0IChxY2Fy
ICx4KSAseSkpCiAgICAobGV0ICgoeHggKGdlbnN5bSkpKQogICAgIGAobGV0ICgoLHh4ICx4KSkK
ICAgICAgIChhbmQgKGNvbnNwICx4eCkgKCx0ZXN0IChxY2FyICx4eCkgLHkpKSkpKSkpCkAKW1tl
cWNhcl1dIGlzIG9ubHkgZGVmaW5lZCwgaWYgW1tDQ0xdXSBpcyBub3Qgb24gW1sqRkVBVFVSRVMq
XV0uIFRoaXMKaXMgcHJvYmFibHkgYmVjYXVzZSBpdCBpcyBwYXJ0IG9mIENvZGVtaXN0IENvbW1v
biBMaXNwICg/KS4gSWYgdGhhdCBpcwpzbyB0aGUgY29uZGl0aW9uYWwgY291bGQgYmUgcmVtb3Zl
ZCwgSSBndWVzcy4gSW4gZmFjdCwgdGhlIFtbQ0NMXV0KZmVhdHVyZSBpcyBub3QgdW5pcXVlIHRv
IENvZGVtaXN0IENvbW1vbiBMaXNwLiBGb3IgZXhhbXBsZSwgT3Blbk1DTApoYXMgW1tDQ0xdXSBv
biBpdHMgW1sqRkVBVFVSRVMqXV0uIFNpbmNlIENvZGVtaXN0IGlzIGlycmVsZXZhbnQgb3IKZGVh
ZCBhbmQgT3Blbk1DTCBpcyB2ZXJ5IG11Y2ggYWxpdmUsIG1heWJlIGFsbCB0aGUgQ0NMIGNvbmRp
dGlvbmFscwpzaG91bGQgYmUgYWRhcHRlZC9yZW1vdmVkLgoKClRoZSBbW2VxdWFibGVdXSBmdW5j
dGlvbiByZXR1cm5zIHRydWUsIGlmZiBbW3hdXSBpcyBlaXRoZXIgW1tOSUxdXSBvcgphIHF1b3Rl
ZCBzeW1ib2wuIEl0IGlzIHVzZWQgaW4gW1tlcWNhcl1dLgoKPDxlcXVhYmxlPj49CihkZWZ1biBl
cXVhYmxlICh4KSA7O2RlZiBuZWVkZWQgdG8gcHJldmVudCByZWN1cnNpb24gaW4gZGVmIG9mIGVx
Y2FyCiAgKG9yIChudWxsIHgpCiAgICAgIChhbmQgKGNvbnNwIHgpCiAgICAgICAgICAgKGVxIChj
YXIgeCkgJ3F1b3RlKQogICAgICAgICAgIChzeW1ib2xwIChjYWRyIHgpKSkpKQpACgpUaGUgW1tJ
PV1dIG1hY3JvIHRyaWVzIHRvIG9wdGltaXplIHRoZSBjb21wYXJpc29uIG9mIGludGVnZXJzIGZv
ciB0aGUKY29tbW9uIGNhc2Ugb2YgW1tGSVhOVU1dXXMuCjw8aT0+Pj0KKGRlZm1hY3JvIGk9ICh4
IHkpIDs7IGludGVnZXIgZXF1YWxpdHkKICAoaWYgKHR5cGVwIHkgJ2ZpeG51bSkKICAgICAgKGxl
dCAoKGd4IChnZW5zeW0pKSkKCWAobGV0ICgoLGd4ICx4KSkKCSAgIChhbmQgKHR5cGVwICxneCAn
Zml4bnVtKSAoZXFsICh0aGUgZml4bnVtICxneCkgLHkpKSkpCiAgICAobGV0ICgoZ3ggKGdlbnN5
bSkpIChneSAoZ2Vuc3ltKSkpCiAgICAgIGAobGV0ICgoLGd4ICx4KSAoLGd5ICx5KSkKCSAoY29u
ZCAoKGFuZCAodHlwZXAgLGd4ICdmaXhudW0pICh0eXBlcCAsZ3kgJ2ZpeG51bSkpCgkJKGVxbCAo
dGhlIGZpeG51bSAsZ3gpICh0aGUgZml4bnVtICxneSkpKQoJICAgICAgICgoZXFsICh0aGUgaW50
ZWdlciAsZ3gpICh0aGUgaW50ZWdlcixneSkpKSkpKSkpCkAKClxzdWJzZWN0aW9ue1ByZWRpY2F0
ZXN9ClxsYWJlbHtzZWM6UHJlZGljYXRlc30KClRoaXMgZnVuY3Rpb24gYWN0dWFsbHkgY2hlY2tz
IHdldGhlciBpdHMgYXJndW1lbnQgaXMgYW4gdW5pbnRlcm5lZApzeW1ib2wgb3Igbm90LiBJdCBk
b2VzIG5vdCBjaGVjaywgd2V0aGVyIGl0IHdhcyBjcmVhdGVkIGJ5IFtbR0VOU1lNXV0sCndoaWNo
IGlzIGFuIGltcG9ydGFudCBkaWZmZXJlbmNlLiBIZW5jZSB0aGUgbmFtZSBzaG91bGQgYmUgY2hh
bmdlZC4KPDxnZW5zeW1wPj49CiMtOkNDTAooZGVmdW4gZ2Vuc3ltcCAoeCkgKGFuZCAoc3ltYm9s
cCB4KSAobnVsbCAoc3ltYm9sLXBhY2thZ2UgeCkpKSkKQAoKVGhlIG5leHQgbWFjcm8gcmV0dXJu
cwo8PGlkZW50cD4+PQooZGVmbWFjcm8gaWRlbnRwICh4KSAKIChpZiAoYXRvbSB4KQogIGAoYW5k
ICx4IChzeW1ib2xwICx4KSkKICAgKGxldCAoKHh4IChnZW5zeW0pKSkKICAgIGAobGV0ICgoLHh4
ICx4KSkKICAgICAgKGFuZCAseHggKHN5bWJvbHAgLHh4KSkpKSkpCkAKClxzdWJzdWJzZWN0aW9u
e1R5cGUgcHJlZGljYXRlc30KXGxhYmVse3NlYzpUeXBlUHJlZGljYXRlc30KCkNoZWNrcyB3ZXRo
ZXIgaXRzIGFyZ3VtZW50IGlzIGEgW1tCSUdOVU1dXS4gSXNuJ3QgdXNlZCBhbnl3aGVyZSBhbmQK
c2hvdWxkIGdvLgo8PGJpbnRwPj49CiMtOkNDTAooZGVmbWFjcm8gYmludHAgKG4pCiBgKHR5cGVw
ICxuICdiaWdudW0pKQojKzpDQ0wKKGRlZnVuIGJpbnRwIChuKSAoYW5kIChpbnRlZ2VycCBuKSAo
bm90IChmaXhwIG4pKSkpCkAKCjw8c2ludHA+Pj0KIy06Q0NMCihkZWZtYWNybyBzaW50cCAobikK
IGAodHlwZXAgLG4gJ2ZpeG51bSkpCiMrOkNDTAooZGVmbWFjcm8gc2ludHAgKG4pCiAgYChmaXhw
ICxuKSkKQAoKPDxzbWludHA+Pj0KIy06Q0NMCihkZWZtYWNybyBzbWludHAgKG4pCiBgKHR5cGVw
ICxuICdmaXhudW0pKQojKzpDQ0wKKGRlZm1hY3JvIHNtaW50cCAobikKICBgKGZpeHAgLG4pKQpA
CgpbW0xJTlRQXV0gaXMgbmV2ZXIgdXNlZCBvdXRzaWRlIG9uZSBjb21tZW50ZWQgZnVuY3Rpb24g
aW4KW1tJLUNPRVJGTi5CT09ULlBBTVBITEVUXV0gYW5kIHNob3VsZCBnby4KPDxsaW50cD4+PQoo
ZGVmbWFjcm8gbGludHAgKG4pCiBgKHR5cGVwICxuICdiaWdudW0pKQpACgpcc3Vic2VjdGlvbntp
ZmNhci9pZmNkcn0KXGxhYmVse3NlYzppZmNhcklmY2RyfQoKVGhlc2UgbWFjcm9zIGdlbmVyYXRl
IGNvZGUgdGhhdCB3b3JrcyBsaWtlIFtbQ0FSXV0vW1tDRFJdXSBvbiBjb25zCmNlbGxzIGFuZCBl
dmFsdWF0ZXMgdG8gW1tOSUxdXSBmb3IgYWxsIG90aGVyIExpc3Agb2JqZWN0cy4KCjw8aWZjYXIv
aWZjZHI+Pj0KKGRlZm1hY3JvIGlmY2FyICh4KQogIChpZiAoYXRvbSB4KQogICAgICBgKGFuZCAo
Y29uc3AgLHgpIChxY2FyICx4KSkKICAgIChsZXQgKCh4eCAoZ2Vuc3ltKSkpCiAgICAgIGAobGV0
ICgoLHh4ICx4KSkKCSAoYW5kIChjb25zcCAseHgpIChxY2FyICx4eCkpKSkpKQoKKGRlZm1hY3Jv
IGlmY2RyICh4KQogIChpZiAoYXRvbSB4KQogICAgICBgKGFuZCAoY29uc3AgLHgpIChxY2RyICx4
KSkKICAgIChsZXQgKCh4eCAoZ2Vuc3ltKSkpCiAgICAgIGAobGV0ICgoLHh4ICx4KSkKCSAoYW5k
IChjb25zcCAseHgpIChxY2RyICx4eCkpKSkpKQpACgpcc2VjdGlvbntFZmZpY2llbmN5IEhhY2tz
fQpcbGFiZWx7c2VjOkVmZmljaWVuY3lIYWNrc30KClRoZXJlIGFyZSBzZXZlcmFsIGZ1bmN0aW9u
cyB0aGF0IG9ubHkgZXhpc3QgdG8gaW1wcm92ZQplZmZpY2llbmN5LiBUaGV5IHNpbXBseSBhc3N1
bWUgdGhhdCB0aGVpciBhcmd1bWVudHMgYXJlIG9mIHRoZSByaWdodAp0eXBlLCBlZy4gW1txY2Fy
XV0gYXNzdW1lcyB0aGF0IGl0IGlzIHBhc3NlZCBhIGNvbnMuIFRoZWlyIG5hbWVzCnVzdWFsbHkg
c3RhcnQgd2l0aCBhIFEsIHNpbmNlIHRoZXkgYXJlIChzdXBwb3NlZCB0byBiZSkgcXVpY2suIE9u
ZSBvZGQKZXhjZXB0aW9uIHRvIHRoZSBydWxlIGlzIFtbUUxFTkdUSF1dIChzZWUgXHJlZntzZWM6
YWxpYXNlc30pLCB3aGljaCBpcwpzaW1wbHkgYW4gYWxpYXMgZm9yIFtbTEVOR1RIXV0uCgoKXHN1
YnNlY3Rpb257U2VxdWVuY2UgRnVuY3Rpb25zfQpcbGFiZWx7c2VjOkVmZmljaWVuY3lIYWNrc1Nl
cXVlbmNlRnVuY3Rpb25zfQoKQWxsIChtb3N0Pykgb2YgdGhlIFtbQ0EqRCpSXV0gZnVuY3Rpb25z
IGluIENMIGhhdmUgYSBbW1FDQSpEKlJdXQplcXVpdmFsZW50LgoKPDxxY2FyLWZhbWlseT4+PQoj
LTpDQ0wKKGRlZm1hY3JvIHFjYXIgKHgpCiBgKGNhciAodGhlIGNvbnMgLHgpKSkKIy06Q0NMCihk
ZWZtYWNybyBxY2RyICh4KQogYChjZHIgKHRoZSBjb25zICx4KSkpCgojLTpDQ0wKKGRlZm1hY3Jv
IHFjYWFyICh4KQogYChjYXIgKHRoZSBjb25zIChjYXIgKHRoZSBjb25zICx4KSkpKSkKIy06Q0NM
CihkZWZtYWNybyBxY2FkciAoeCkKIGAoY2FyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAseCkp
KSkpCiMtOkNDTAooZGVmbWFjcm8gcWNkYXIgKHgpCiBgKGNkciAodGhlIGNvbnMgKGNhciAodGhl
IGNvbnMgLHgpKSkpKQojLTpDQ0wKKGRlZm1hY3JvIHFjZGRyICh4KQogYChjZHIgKHRoZSBjb25z
IChjZHIgKHRoZSBjb25zICx4KSkpKSkKCihkZWZtYWNybyBxY2FhYXIgKHgpCiBgKGNhciAodGhl
IGNvbnMgKGNhciAodGhlIGNvbnMgKGNhciAodGhlIGNvbnMgLHgpKSkpKSkpCihkZWZtYWNybyBx
Y2FhZHIgKHgpCiBgKGNhciAodGhlIGNvbnMgKGNhciAodGhlIGNvbnMgKGNkciAodGhlIGNvbnMg
LHgpKSkpKSkpCihkZWZtYWNybyBxY2FkYXIgKHgpCiBgKGNhciAodGhlIGNvbnMgKGNkciAodGhl
IGNvbnMgKGNhciAodGhlIGNvbnMgLHgpKSkpKSkpCihkZWZtYWNybyBxY2FkZHIgKHgpCiBgKGNh
ciAodGhlIGNvbnMgKGNkciAodGhlIGNvbnMgKGNkciAodGhlIGNvbnMgLHgpKSkpKSkpCihkZWZt
YWNybyBxY2RhYXIgKHgpCiBgKGNkciAodGhlIGNvbnMgKGNhciAodGhlIGNvbnMgKGNhciAodGhl
IGNvbnMgLHgpKSkpKSkpCihkZWZtYWNybyBxY2RhZHIgKHgpCiBgKGNkciAodGhlIGNvbnMgKGNh
ciAodGhlIGNvbnMgKGNkciAodGhlIGNvbnMgLHgpKSkpKSkpCihkZWZtYWNybyBxY2RkYXIgKHgp
CiBgKGNkciAodGhlIGNvbnMgKGNkciAodGhlIGNvbnMgKGNhciAodGhlIGNvbnMgLHgpKSkpKSkp
CihkZWZtYWNybyBxY2RkZHIgKHgpCiBgKGNkciAodGhlIGNvbnMgKGNkciAodGhlIGNvbnMgKGNk
ciAodGhlIGNvbnMgLHgpKSkpKSkpCgooZGVmbWFjcm8gcWNhYWFhciAoeCkKIGAoY2FyICh0aGUg
Y29ucyAoY2FyICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAseCkpKSkp
KSkpKQooZGVmbWFjcm8gcWNhYWFkciAoeCkKIGAoY2FyICh0aGUgY29ucyAoY2FyICh0aGUgY29u
cyAoY2FyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAseCkpKSkpKSkpKQooZGVmbWFjcm8gcWNh
YWRhciAoeCkKIGAoY2FyICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAo
Y2FyICh0aGUgY29ucyAseCkpKSkpKSkpKQooZGVmbWFjcm8gcWNhYWRkciAoeCkKIGAoY2FyICh0
aGUgY29ucyAoY2FyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAseCkp
KSkpKSkpKQooZGVmbWFjcm8gcWNhZGFhciAoeCkKIGAoY2FyICh0aGUgY29ucyAoY2RyICh0aGUg
Y29ucyAoY2FyICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAseCkpKSkpKSkpKQooZGVmbWFjcm8g
cWNhZGFkciAoeCkKIGAoY2FyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAoY2FyICh0aGUgY29u
cyAoY2RyICh0aGUgY29ucyAseCkpKSkpKSkpKQooZGVmbWFjcm8gcWNhZGRhciAoeCkKIGAoY2Fy
ICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAs
eCkpKSkpKSkpKQooZGVmbWFjcm8gcWNhZGRkciAoeCkKIGAoY2FyICh0aGUgY29ucyAoY2RyICh0
aGUgY29ucyAoY2RyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAseCkpKSkpKSkpKQooZGVmbWFj
cm8gcWNkYWFhciAoeCkKIGAoY2RyICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAoY2FyICh0aGUg
Y29ucyAoY2FyICh0aGUgY29ucyAseCkpKSkpKSkpKQooZGVmbWFjcm8gcWNkYWFkciAoeCkKIGAo
Y2RyICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAoY2RyICh0aGUgY29u
cyAseCkpKSkpKSkpKQooZGVmbWFjcm8gcWNkYWRhciAoeCkKIGAoY2RyICh0aGUgY29ucyAoY2Fy
ICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAseCkpKSkpKSkpKQooZGVm
bWFjcm8gcWNkYWRkciAoeCkKIGAoY2RyICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAoY2RyICh0
aGUgY29ucyAoY2RyICh0aGUgY29ucyAseCkpKSkpKSkpKQooZGVmbWFjcm8gcWNkZGFhciAoeCkK
IGAoY2RyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAoY2FyICh0aGUg
Y29ucyAseCkpKSkpKSkpKQooZGVmbWFjcm8gcWNkZGFkciAoeCkKIGAoY2RyICh0aGUgY29ucyAo
Y2RyICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAseCkpKSkpKSkpKQoo
ZGVmbWFjcm8gcWNkZGRhciAoeCkKIGAoY2RyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAoY2Ry
ICh0aGUgY29ucyAoY2FyICh0aGUgY29ucyAseCkpKSkpKSkpKQooZGVmbWFjcm8gcWNkZGRkciAo
eCkKIGAoY2RyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAoY2RyICh0aGUgY29ucyAoY2RyICh0
aGUgY29ucyAseCkpKSkpKSkpKQpACgpPZiBjb3Vyc2UsIHRoZXJlIGFyZSBhbHNvIHZhcmlhbnRz
IG9mIFtbUlBMQUNBXV0gYW5kIFtbUlBMQUNEXV0uCjw8cXJwbGFjPj49CihkZWZtYWNybyBxcnBs
YWNhIChhIGIpCiBgKHJwbGFjYSAodGhlIGNvbnMgLGEpICxiKSkKCihkZWZtYWNybyBxcnBsYWNk
IChhIGIpCiBgKHJwbGFjZCAodGhlIGNvbnMgLGEpICxiKSkKQAoKVGhlIFtbcWNzaXplXV0gbWFj
cm8gZXhwZWN0cyBhIFtbU0lNUExFLVNUUklOR11dIGFuZCByZXR1cm5zIGl0cwpsZW5ndGgsIHdo
aWNoIGl0IGRlY2xhcmVzIHRvIGJlIGEgW1tGSVhOVU1dXS4KPDxxY3NpemU+Pj0KKGRlZm1hY3Jv
IHFjc2l6ZSAoeCkKIGAodGhlIGZpeG51bSAobGVuZ3RoICh0aGUgc2ltcGxlLXN0cmluZyAseCkp
KSkKQAoKUmV0dXJucyB0aGUgbGFyZ2VzdCB2YWxpZCBpbmRleCBmb3IgYSBzZXF1ZW5jZSBhc3N1
bWluZyB0aGF0IGl0IGlzIGEKZml4bnVtLgo8PG1heGluZGV4Pj49CihkZWZtYWNybyBtYXhpbmRl
eCAoeCkKIGAodGhlIGZpeG51bSAoMS0gKHRoZSBmaXhudW0gKGxlbmd0aCAseCkpKSkpCkAKCjw8
c3RyaW5nbGVuZ3RoPj49CihkZWZtYWNybyBzdHJpbmdsZW5ndGggKHgpCiBgKGxlbmd0aCAodGhl
IHN0cmluZyAseCkpKQpACgo8PHFzZXF2ZWM+Pj0KKGRlZm1hY3JvIHFzZXRyZWZ2ICh2ZWMgaW5k
IHZhbCkKIGAoc2V0ZiAoc3ZyZWYgLHZlYyAodGhlIGZpeG51bSAsaW5kKSkgLHZhbCkpCgooZGVm
bWFjcm8gcXNldHZlbHQgKHZlYyBpbmQgdmFsKQogYChzZXRmIChzdnJlZiAsdmVjICh0aGUgZml4
bnVtICxpbmQpKSAsdmFsKSkKCihkZWZtYWNybyBxc2V0dmVsdC0xICh2ZWMgaW5kIHZhbCkKIGAo
c2V0ZiAoc3ZyZWYgLHZlYyAodGhlIGZpeG51bSAoMS0gKHRoZSBmaXhudW0gLGluZCkpKSkgLHZh
bCkpCgoKKGRlZm1hY3JvIHFzdHJpbmdsZW5ndGggKHgpCiBgKHRoZSBmaXhudW0gKGxlbmd0aCAo
dGhlIHNpbXBsZS1zdHJpbmcgLHgpKSkpCgooZGVmbWFjcm8gcXZlbHQgKHZlYyBpbmQpCiBgKHN2
cmVmICx2ZWMgKHRoZSBmaXhudW0gLGluZCkpKQoKKGRlZm1hY3JvIHF2ZWx0LTEgKHZlYyBpbmQp
CiBgKHN2cmVmICx2ZWMgKHRoZSBmaXhudW0gKDEtICh0aGUgZml4bnVtICxpbmQpKSkpKQoKKGRl
Zm1hY3JvIHF2bWF4aW5kZXggKHgpCiBgKHRoZSBmaXhudW0gKDEtICh0aGUgZml4bnVtIChsZW5n
dGggKHRoZSBzaW1wbGUtdmVjdG9yICx4KSkpKSkpCgooZGVmbWFjcm8gcXZzaXplICh4KQogYCh0
aGUgZml4bnVtIChsZW5ndGggKHRoZSBzaW1wbGUtdmVjdG9yICx4KSkpKQpACgpcc3Vic2VjdGlv
bntBcml0aG1ldGljfQpcbGFiZWx7RWZmaWNpZW5jeUhhY2tzQXJpdGhtZXRpY30KClRoZSBmb2xs
b3dpbmcgZnVuY3Rpb25zIHBlcmZvcm0gYXJpdGhtZXRpYyB3aXRoIGRlY2xhcmVkIHR5cGVzLAp1
c3VhbGx5IFtbRklYTlVNXV0uCjw8cWFyaXRobWV0aWM+Pj0KKGRlZm1hY3JvIHFzYWRkMSAoeCkK
IGAodGhlIGZpeG51bSAoMSsgKHRoZSBmaXhudW0gLHgpKSkpCgooZGVmbWFjcm8gcXNkZWMxICh4
KQogYCh0aGUgZml4bnVtICgxLSAodGhlIGZpeG51bSAseCkpKSkKCihkZWZtYWNybyBxc2RpZmZl
cmVuY2UgKHggeSkKIGAodGhlIGZpeG51bSAoLSAodGhlIGZpeG51bSAseCkgKHRoZSBmaXhudW0g
LHkpKSkpCgooZGVmbWFjcm8gcXNncmVhdGVycCAoYSBiKQogYCg+ICh0aGUgZml4bnVtICxhKSAo
dGhlIGZpeG51bSAsYikpKQoKKGRlZm1hY3JvIHFzaW5jMSAoeCkKIGAodGhlIGZpeG51bSAoMSsg
KHRoZSBmaXhudW0gLHgpKSkpCgooZGVmbWFjcm8gcXNsZWZ0c2hpZnQgKGEgYikKIGAodGhlIGZp
eG51bSAoYXNoICh0aGUgZml4bnVtICxhKSAodGhlIGZpeG51bSAsYikpKSkKCihkZWZtYWNybyBx
c2xlc3NwIChhIGIpCiBgKDwgKHRoZSBmaXhudW0gLGEpICh0aGUgZml4bnVtICxiKSkpCgooZGVm
bWFjcm8gcXNtYXggKHggeSkKIGAodGhlIGZpeG51bSAobWF4ICh0aGUgZml4bnVtICx4KSAodGhl
IGZpeG51bSAseSkpKSkKCihkZWZtYWNybyBxc21pbiAoeCB5KQogYCh0aGUgZml4bnVtIChtaW4g
KHRoZSBmaXhudW0gLHgpICh0aGUgZml4bnVtICx5KSkpKQoKKGRlZm1hY3JvIHFzbWludXMgKHgp
CiBgKHRoZSBmaXhudW0gKG1pbnVzICh0aGUgZml4bnVtICx4KSkpKQoKKGRlZm1hY3JvIHFzbWlu
dXNwICh4KQogYChtaW51c3AgKHRoZSBmaXhudW0gLHgpKSkKCihkZWZtYWNybyBxc29kZHAgKHgp
CiBgKG9kZHAgKHRoZSBmaXhudW0gLHgpKSkKCihkZWZtYWNybyBxc2Fic3ZhbCAoeCkKICBgKHRo
ZSBmaXhudW0gKGFicyAodGhlIGZpeG51bSAseCkpKSkKCihkZWZtYWNybyBxc3BsdXMgKHggeSkK
IGAodGhlIGZpeG51bSAoKyAodGhlIGZpeG51bSAseCkgKHRoZSBmaXhudW0gLHkpKSkpCgooZGVm
bWFjcm8gcXNzdWIxICh4KQogYCh0aGUgZml4bnVtICgxLSAodGhlIGZpeG51bSAseCkpKSkKCihk
ZWZtYWNybyBxc3RpbWVzICh4IHkpCiBgKHRoZSBmaXhudW0gKCogKHRoZSBmaXhudW0gLHgpICh0
aGUgZml4bnVtICx5KSkpKQoKKGRlZm1hY3JvIHFzemVyb3AgKHgpCiBgKHplcm9wICh0aGUgZml4
bnVtICx4KSkpCgooZGVmdW4gUVNRVU9USUVOVCAoYSBiKSAodGhlIGZpeG51bSAodHJ1bmNhdGUg
KHRoZSBmaXhudW0gYSkgKHRoZSBmaXhudW0gYikpKSkKCihkZWZ1biBRU1JFTUFJTkRFUiAoYSBi
KSAodGhlIGZpeG51bSAocmVtICh0aGUgZml4bnVtIGEpICh0aGUgZml4bnVtIGIpKSkpCkAKCltb
WkVSTz9dXSB3b3JrcyBzaW1pbGFyIHRvIFtbWkVST1BdXSwgYnV0IGRvZXNuJ3Qgc2lnbmFsIGEg
dHlwZSBlcnJvciwKaWYgW1t4XV0gaXMgbm90IGEgW1tOVU1CRVJdXS4KPDx6ZXJvPz4+PQojLTpD
Q0wKKGRlZm1hY3JvIHplcm8/ICh4KQogIGAoYW5kICh0eXBlcCAseCAnZml4bnVtKSAoemVyb3Ag
KHRoZSBmaXhudW0gLHgpKSkpCiMrOkNDTAooZGVmbWFjcm8gemVybz8gKHgpIGAoemVyb3AgLHgp
KQpACgpcc2VjdGlvbntBbGlhc2VzfQpcbGFiZWx7c2VjOmFsaWFzZXN9CgpUaGVzZSBhcmUgdGhl
IGZ1bmN0aW9ucy9tYWNyb3Mgd2hvc2Ugc29sZSBwdXJwb3NlIGlzIHRvIGFsbG93CmFsdGVybmF0
aXZlIG5hbWVzIGZvciBzdGFuZGFyZCBDTCBvcGVyYXRpb25zLiBUaGUgb25seSBzbGlnaHRseQpw
ZWN1bGlhciBmdW5jdGlvbiBpbiB0aGlzIGxpc3QgaXMgW1tGSVhQXV0gKHNlZSBiZWxvdykuIFNv
bWUgb2YgdGhlCm90aGVyIGZ1bmN0aW9ucy9tYWNyb3MgZG9uJ3QgdGFrZSBhbGwgdGhlIG9wdGlv
bmFsL2tleXdvcmQgYXJndW1lbnRzCnRoYXQgdGhlIG9yaWdpbmFsIGZ1bmN0aW9uIGFsbG93cy4K
Cjw8YWxpYXNlcz4+PQooZGVmbWFjcm8gYWJzdmFsICh4KQogYChhYnMgLHgpKQoKIy06Q0NMCihk
ZWZtYWNybyBhZGQxICh4KQogYCgxKyAseCkpCgooZGVmbWFjcm8gfGNvcHlMaXN0fCAoeCkgCiBg
KGNvcHktbGlzdCAseCkpCgojLTpDQ0wKKGRlZm1hY3JvIGRpZmZlcmVuY2UgKCZyZXN0IGFyZ3Mp
CiBgKC0gLEBhcmdzKSkKCihkZWZtYWNybyBpbnRwICh4KQogYChpbnRlZ2VycCAseCkpCgooZGVm
bWFjcm8gcm51bXAgKG4pCiBgKGZsb2F0cCAsbikpCgooZGVmbWFjcm8gdmVjcCAodikgYChzaW1w
bGUtdmVjdG9yLXAgLHYpKQoKKGRlZm1hY3JvIGN2ZWNwICh4KQogYChzdHJpbmdwICx4KSkKCihk
ZWZtYWNybyBsYXN0bm9kZSAobCkKIGAobGFzdCAsbCkpCgooZGVmbWFjcm8gbGFzdHBhaXIgKGwp
CiBgKGxhc3QgLGwpKQoKIy06Q0NMCihkZWZtYWNybyBtaW51cyAoeCkKIGAoLSAseCkpCgojLTpD
Q0wKKGRlZm1hY3JvIGxlc3NwICgmcmVzdCBhcmdzKQogYCg8ICxAYXJncykpCgooZGVmbWFjcm8g
bnVtcCAobikKIGAobnVtYmVycCAsbikpCgooZGVmbWFjcm8gcGFpcnAgKHgpCiBgKGNvbnNwICx4
KSkgCgojLTpDQ0wKKGRlZm1hY3JvIHBsdXMgKCZyZXN0IGFyZ3MpCiBgKCsgLEAgYXJncykpCgoj
LTpDQ0wKKGRlZm1hY3JvIHRpbWVzICgmcmVzdCBhcmdzKQogYCgqICxAYXJncykpCgojLTpDQ0wK
KGRlZm1hY3JvIHN1YjEgKHgpCiBgKDEtICx4KSkKCiMtOkNDTAooZGVmbWFjcm8gZ3JlYXRlcnAg
KCZyZXN0IGFyZ3MpCiBgKD4gLEBhcmdzKSkKCihkZWZtYWNybyBhcHBseCAoJnJlc3QgYXJncykK
IGAoYXBwbHkgLEBhcmdzKSkKCihkZWZtYWNybyBmZXRjaGNoYXIgKHggaSkKIGAoY2hhciAseCAs
aSkpCgooZGVmbWFjcm8gfGVxdWFsfCAoeCB5KQogYChlcXVhbHAgLHggLHkpKQoKKGRlZm1hY3Jv
IHJlZnZlY3AgKHYpIGAoc2ltcGxlLXZlY3Rvci1wICx2KSkKCjsgKGRlZm1hY3JvIHFtZW1xIChh
IGIpCjsgYChtZW1iZXIgLGEgLGIgOnRlc3QgIydlcSkpCihkZWZtYWNybyBxbWVtcSAoYSBiKSBg
KG1lbXEgLGEgLGIpKQoKKGRlZm1hY3JvIHFyZWZlbHQgKHZlYyBpbmQpCiBgKHN2cmVmICx2ZWMg
LGluZCkpCgooZGVmbWFjcm8gdGhyb3ctcHJvdGVjdCAoZXhwMSBleHAyKQogYCh1bndpbmQtcHJv
dGVjdCAsZXhwMSAsZXhwMikpCgooZGVmbWFjcm8gcWFzc3EgKGEgYikgYChhc3NxICxhICxiKSkK
CihkZWZtYWNybyBzdWJycCAoeCkKIGAoY29tcGlsZWQtZnVuY3Rpb24tcCAseCkpCgooZGVmaW5l
LWZ1bmN0aW9uICd0ZW1wdXMtZnVnaXQgIydnZXQtaW50ZXJuYWwtcnVuLXRpbWUpCihkZWZpbmUt
ZnVuY3Rpb24gJ01ERUZYICMnTURFRikKKGRlZmluZS1mdW5jdGlvbiAnS09NUElMRSAjJ0NPTVAz
NzApCihkZWZpbmUtZnVuY3Rpb24gJ1UtQ0FTRSAjJ3VwY2FzZSkKKGRlZmluZS1mdW5jdGlvbiAn
TEMyVUMgIyd1cGNhc2UpCihkZWZpbmUtZnVuY3Rpb24gJ0wtQ0FTRSAjJ2Rvd25jYXNlKQooZGVm
aW5lLWZ1bmN0aW9uICdNQUtFUFJPUCAjJ3B1dCkKKGRlZmluZS1mdW5jdGlvbiAnRklYICMndHJ1
bmNhdGUpCihkZWZpbmUtZnVuY3Rpb24gJ0lOVDJSTlVNICMnZmxvYXQpCihkZWZpbmUtZnVuY3Rp
b24gJ3ZtLyAjJ3F1b3RpZW50KQooZGVmaW5lLWZ1bmN0aW9uICdHRVRSRUZWICMnbWFrZS1hcnJh
eSkKKGRlZmluZS1mdW5jdGlvbiAnTElTVDJSRUZWRUMgIydMSVNUMlZFQykKKGRlZmluZS1mdW5j
dGlvbiAnTU9WRVZFQyAjJ3JlcGxhY2UpCihkZWZpbmUtZnVuY3Rpb24gJ1NUUkdSRUFURVJQICMn
Q0dSRUFURVJQKQooZGVmaW5lLWZ1bmN0aW9uICdzdHJjb25jICMnY29uY2F0KQooZGVmaW5lLWZ1
bmN0aW9uICdnZXRzdHIgIydtYWtlLWN2ZWMpCihkZWZpbmUtZnVuY3Rpb24gJ2dldGZ1bGxzdHIg
IydtYWtlLWZ1bGwtY3ZlYykKKGRlZmluZS1mdW5jdGlvbiAnTVNVQlNUUSAjJ3N1YnN0KSA7ZGVm
YXVsdCB0ZXN0IGlzIGVxbAooZGVmaW5lLWZ1bmN0aW9uICdTVUJTVFEgIydTVUJTVCkgO2RlZmF1
bHQgdGVzdCBpcyBlcWwgc3Vic3QgaXMgbm90IGd1YXJhbnRlZWQgdG8gY29weQoKKGRlZmluZS1m
dW5jdGlvbiAnbmV4dCAjJ3JlYWQtY2hhcikKKGRlZmluZS1mdW5jdGlvbiAncHJpbnRleHAgIydw
cmluYykKKGRlZmluZS1mdW5jdGlvbiAncHJpbjAgICMncHJpbjEpCgooZGVmaW5lLWZ1bmN0aW9u
ICdFVkExICMnZXZhbCkgO0VWQTEgYW5kIFZNTElTUCBFVkFMIG1ha2UgbGV4aWNhbHMgdmlzaWJs
ZQooZGVmaW5lLWZ1bmN0aW9uICdFVkFMRlVOICMnZXZhbCkgO0VWQUxGVU4gZHJvcHMgbGV4aWNh
bHMgYmVmb3JlIGV2YWx1YXRpbmcKKGRlZmluZS1mdW5jdGlvbiAnRVZBMUZVTiAjJ0VWQUxGVU4p
CkAKCgpUaGUgW1tGSVhQXV0gZnVuY3Rpb24ncyBtZWFuaW5nIGlzIGRpZmZlcmVudCBvbiBbW0ND
TF1dLiBUaGVyZSBpdAp0ZXN0cyB3ZXRoZXIgaXRzIGFyZ3VtZW50IGlzIGEgZml4bnVtLiBPbiBv
dGhlciBMaXNwcyBpdCBleHBhbmRzIHRvCltbSU5URUdFUlBdXSwgd2hpY2ggaXMgb2J2aW91c2x5
IHNvbWV0aGluZyBkaWZmZXJlbnQuIFNpbmNlIENDTCBpcwpkZWFkIGFueXdheSwgdGhpcyBkb2Vz
bid0IG1hdHRlciBhbnltb3JlLiBPbiB0aGUgb3RoZXIgaGFuZCBbW0ZJWFBdXQpzZWVtcyBxdWl0
ZSB1c2VsZXNzLCBzbyBtYXliZSBpdCBzaG91bGQgZ28uIEZvciBhIHNob3J0ZXIgdmVyc2lvbiBv
ZgpbW0lOVEVHRVJQXV0gbG9vayBhdCBbW0lOVFBdXSBhYm92ZS4KCjw8Zml4cD4+PQojLTpDQ0wg
IDs7IGZpeHAgaW4gY2NsIHRlc3RzIGZvciBmaXhudW0KKGRlZm1hY3JvIGZpeHAgKHgpCiBgKGlu
dGVnZXJwICx4KSkKQAoKVGhlIFtbUUxFTkdUSF1dIGZ1bmN0aW9uIGlzIGp1c3QgYW4gYWxpYXMg
Zm9yIHRoZSBbW0xFTkdUSF1dCmZ1bmN0aW9uLiBXaGF0IG1ha2VzIGl0IHNwZWNpYWwgaXMgdGhh
dCBpdHMgbmFtZSBoYXMgYSBRIHByZWZpeCwgd2hpY2gKdXN1YWxseSBpbmRpY2F0ZXMgdGhhdCBh
IGZ1bmN0aW9uIHRyYWRlcyBzYWZldHkgZm9yIHNwZWVkIChzZWUKXHJlZntzZWM6RWZmaWNpZW5j
eUhhY2tzfSkuIE9idmlvdXNseSB0aGF0IGlzbid0IHRoZSBjYXNlIGhlcmUuCgo8PHFsZW5ndGg+
Pj0KKGRlZm1hY3JvIHFsZW5ndGggKGEpCiBgKGxlbmd0aCAsYSkpCkAKCkJvdGggb2YgW1tTRVRT
SVpFXV0gYW5kIFtbQ0hBTkdFTEVOR1RIXV0gYXJlIGFsaWFzZXMgZm9yCltbQURKVVNULUFSUkFZ
XV0uCgoKVGhlIG5leHQgbWFjcm8gaXMgYW4gYWxpYXMgZm9yIFtbU1BFQ0lBTC1GT1JNLVBdXSwg
d2hpY2ggaXMgbm90IGluCkFOU0kgQ0wuIEl0IHNob3VsZCBwcm9iYWJseSBiZSByZXBsYWNlZCB3
aXRoIFtbU1BFQ0lBTC1PUEVSQVRPUi1QXV0uCgo8PG1ycHNmcD4+PQooZGVmbWFjcm8gbXJwICh4
KQogYChzcGVjaWFsLWZvcm0tcCAseCkpCgooZGVmbWFjcm8gc2ZwICh4KQogYChzcGVjaWFsLWZv
cm0tcCAseCkpCkAKCltbRUJDRElDXV0gdXNlcyBhIGRlcHJlY2F0ZWQgb3BlcmF0b3IgKFtbSU5U
LUNIQVJdXSksIGhhcyBhbiBhd2Z1bApuYW1lIGFuZCBpc24ndCB1c2VkIHZlcnkgb2Z0ZW4uCjw8
ZWJjZGljPj49CihkZWZ1biBFQkNESUMgKHgpIChpbnQtY2hhciB4KSkKQAoKW1tOQU1FREVSUlNF
VF1dIGlzIGFuIGFsaWFzIGZvciBjYXRjaCB0aGF0IG9ubHkgdGFrZXMgb25lIGZvcm0gYW5kCmln
bm9yZXMgdGhlIHJlc3QuCjw8bmFtZWRlcnJzZXQ+Pj0KKGRlZm1hY3JvIG5hbWVkZXJyc2V0IChp
ZCBpZXhwICZyZXN0IGl0ZW0pCiAoZGVjbGFyZSAoaWdub3JlIGl0ZW0pKQogIGAoY2F0Y2ggLGlk
ICxpZXhwKSkKQAoKXHNlY3Rpb257U2hvcnRjdXRzfQpcbGFiZWx7c2VjOlNob3J0Y3V0c30KClNo
b3J0Y3V0cyBhcmUgZnVuY3Rpb25zIHRoYXQgY2FsbCBkaWZmZXJlbnQgZnVuY3Rpb25zIHdpdGgg
dGhlCmFyZ3VtZW50cyBwcm92aWRlZCBieSB0aGUgdXNlciBwbHVzIGNvbnN0YW50IGFyZ3VtZW50
cy4gRm9yIGV4YW1wbGU6ClxiZWdpbnt2ZXJiYXRpbX0KKGRlZnVuIG1ha2UtYWRqdXN0YWJsZS1h
cnJheSAoZGltZW5zaW9ucykKICAobWFrZS1hcnJheSBkaW1lbnNpb25zIDphZGp1c3RhYmxlIHQp
KQpcZW5ke3ZlcmJhdGltfQpJbiB0aGlzIGNhc2UgW1tNQUtFLUFESlVTVEFCTEUtQVJSQVldXSB3
b3VsZCBiZSBhIHNob3J0Y3V0IGZvcgpbW01BS0UtQVJSQVldXS4KClRoZSBuYW1lIG9mIFtbQVNT
UV1dIGlzIHNvbWV3aGF0IG1pc2xlYWRpbmcsIGJlY2F1c2UgdXN1YWxseSB0aGUgUSBhdAp0aGUg
ZW5kIG9mIGEgbmFtZSBtZWFucyB0aGF0IG9uZSBvciBtb3JlIG9mIHRoZSBhcmd1bWVudHMgYXJl
CnF1b3RlZC4gSW4gdGhpcyBjYXNlIGl0IGluZGljYXRlcyB0aGF0IFtbRVFdXSBpcyB1c2VkIGFz
IHRoZSBlcXVhbGl0eQpwcmVkaWNhdGUgZm9yIFtbQVNTT0NdXS4gTWF5YmUgW1tBU1NPQy1FUV1d
IHdvdWxkIGJlIGJldHRlci4KCjw8YXNzcT4+PQojLShvciBMaXNwTSBMdWNpZCA6Q0NMKQooZGVm
bWFjcm8gYXNzcSAoYSBiKQogYChhc3NvYyAsYSAsYiA6dGVzdCAjJ2VxKSkKCiMrOkNDTAooZGVm
bWFjcm8gYXNzcSAoYSBiKSBgKGF0c29jICxhICxiKSkKQAoKPDxtZW1xPj49CiMtKG9yIExpc3BN
IEx1Y2lkIDpDQ0wpCihkZWZtYWNybyBtZW1xIChhIGIpCiBgKG1lbWJlciAsYSAsYiA6dGVzdCAj
J2VxKSkKQAoKPDxydmVjcD4+PQooZGVmbWFjcm8gcnZlY3AgKHYpCiBgKHR5cGVwICx2ICcodmVj
dG9yIGZsb2F0KSkpCkAKCjw8ZXZhbGFuZGZpbGVhY3RxPj49CihkZWZtYWNybyBldmFsYW5kZmls
ZWFjdHEgKG5hbWUgJm9wdGlvbmFsIChmb3JtIG5hbWUpKQogYChldmFsLXdoZW4gKGV2YWwgbG9h
ZCkgLGZvcm0pKSAgCkAKClRoZSBbW0VYSVRdXSBhbmQgW1tTRVFdXSBtYWNyb3MgYXJlIHByb2Jh
Ymx5IHJlbGF0ZWQuIFtbU0VRXV0KZXN0YWJsaXNoZXMgYSBibG9jayB3aXRoIHRoZSBuYW1lIFtb
U0VRXV0gYW5kIFtbRVhJVF1dIGV4aXRzIHN1Y2ggYQpibG9jayByZXR1cm5pbmcgdGhlIGdpdmVu
IHZhbHVlLgo8PGV4aXQ+Pj0KKGRlZm1hY3JvIGV4aXQgKCZyZXN0IHZhbHVlKQogYChyZXR1cm4t
ZnJvbSBzZXEgLEB2YWx1ZSkpCkAKCjw8c2VxPj49CihkZWZtYWNybyBzZXEgKCZyZXN0IGZvcm0p
CiAgKGxldCogKChib2R5IChyZXZlcnNlIGZvcm0pKQogICAgICAgICAodmFsIGAocmV0dXJuLWZy
b20gc2VxICwocG9wIGJvZHkpKSkpCiAgICAobnN1YnN0aXR1dGUgJyhwcm9nbikgbmlsIGJvZHkp
IDtkb24ndCB0cmVhdCBOSUwgYXMgYSBsYWJlbAogICAgYChibG9jayBzZXEgKHRhZ2JvZHkgLEAo
bnJldmVyc2UgYm9keSkgLHZhbCkpKSkKQAoKPDxuZT4+PQooZGVmbWFjcm8gbmUgKGEgYikgYChu
b3QgKGVxdWFsICxhICxiKSkpCkAKCjw8bmVxPj49Cjs7OyBUaGlzIG1heSBuZWVkIGFkanVzdG1l
bnQgaW4gQ0NMIHdoZXJlIE5FUSBtZWFucyAoTk9UIChFUVVBTCAuLikpKQojLTpDQ0wKKGRlZm1h
Y3JvIG5lcSAoYSBiKSBgKG5vdCAoZXEgLGEgLGIpKSkKQAoKW1tSRVNFVFFdXSBnZW5lcmF0ZXMg
Y29kZSB0aGF0IHdvcmtzIHNpbWlsYXIgdG8gW1tTRVRRXV0sIGJ1dCByZXR1cm5zCnRoZSBvbGQg
dmFsdWUgb2YgdGhlIHBsYWNlIHRoYXQgaXMgY2hhbmdlZCwgaW5zdGVhZCBvZiB0aGUgbmV3IG9u
ZS4KPDxyZXNldHE+Pj0KKGRlZm1hY3JvIHJlc2V0cSAoYSBiKQogYChwcm9nMSAsYSAoc2V0cSAs
YSAsYikpKQpACgpcc2VjdGlvbntOby1vcHMgYW5kIENvbnN0YW50IEZ1bmN0aW9uc30KXGxhYmVs
e3NlYzpOby1vcHNBbmRDb25zdGFudEZ1bmN0aW9uc30KClxzdWJzZWN0aW9ue05vLW9wc30KXGxh
YmVse3NlYzpOby1vcHNBbmRDb25zdGFudEZ1bmN0aW9uc05vLU9wc30KCk5vLW9wcyBhcmUgZnVu
Y3Rpb25zIHRoYXQgdGFrZSBvbmUgYXJndW1lbnQgYW5kIHNpbXBseSByZXR1cm4KaXQuIFNpbmNl
IHRoZXkgYXJlIHVzZWxlc3MsIHRoZXkgc2hvdWxkIGdvLgoKPDxuby1vcHM+Pj0KKGRlZm1hY3Jv
IGNyZWF0ZS1zYmMgKHgpIHgpICA7YSBuby1vcCBmb3IgY29tbW9uIGxpc3AKCihkZWZtYWNybyBt
YWtlc3RyaW5nIChhKSBhKQoKKGRlZnVuIHRyaW1zdHJpbmcgKHgpIHgpCgooZGVmdW4gUkUtRU5B
QkxFLUlOVCAobnVtYmVyLW9mLWhhbmRsZXIpIG51bWJlci1vZi1oYW5kbGVyKQpACgpcc3Vic2Vj
dGlvbntDb25zdGFudCBGdW5jdGlvbnN9ClxsYWJlbHtzZWM6Tm8tb3BzQW5kQ29uc3RhbnRGdW5j
dGlvbnNDb25zdGFudEZ1bmN0aW9uc30KClRoaXMgc2VjdGlvbiBjb250YWlucyBtb3N0IG9mIHRo
ZSBjb25zdGFudCBmdW5jdGlvbnMgKGZvciBhbiBleGNlcHRpb24Kc2VlIFtbJHNjcmVlbnNpemVd
XS4gU2luY2UgY29uc3RhbnQgZnVuY3Rpb25zIGFyZSBwcmV0dHkgdXNlbGVzcywgdGhleQpzaG91
bGQgZ28uCgo8PGFzc2VtYmxlPj49CihkZWZtYWNybyBhc3NlbWJsZSAoJnJlc3QgaWdub3JlKSAK
IChkZWNsYXJlIChpZ25vcmUgaWdub3JlKSkKICBuaWwpCkAKCltbU1RBVEVQXV0gaXMgdXNlZCBv
bmx5IG9uY2UgaW4gW1tNQUNST1MuTElTUC5QQU1QSExFVF1dLgo8PHN0YXRlcD4+PQooZGVmdW4g
U1RBVEVQIChpdGVtKQogKGRlY2xhcmUgKGlnbm9yZSBpdGVtKSkKICAgbmlsKSA7bm8gc3RhdGUg
b2JqZWN0cwpACgpbW1BBUFBQXV0gaXMgdXNlZCBvbmx5IG9uY2UgaW4gW1tDLVVUSUwuQk9PVC5Q
QU1QSExFVF1dLgo8PHBhcHBwPj49CihkZWZ1biBQQVBQUCAoaXRlbSkKIChkZWNsYXJlIChpZ25v
cmUgaXRlbSkpCiAgbmlsKSA7bm8gcGFydGlhbCBhcHBsaWNhdGlvbiBvYmplY3RzCkAKCjw8bmls
Zm4+Pj0KKGRlZnVuIG5pbGZuICgmcmVzdCBpZ25vcmUpCiAoZGVjbGFyZSAoaWdub3JlIGlnbm9y
ZSkpIAogKCkpCkAKClxzZWN0aW9ue09ycGhhbmFnZX0KXGxhYmVse3NlYzpPcnBoYW5hZ2V9CgpJ
ZiB3ZSBkb24ndCBrbm93IHdoYXQgYSBmdW5jdGlvbiBpcyBnb29kIGZvciBhbmQgd2hlcmUgaXQg
YmVsb25ncywgaXQKYmVsb25ncyBoZXJlLgoKPDxxc2V0cT4+PQooZGVmbWFjcm8gcXNldHEgKCZ3
aG9sZSBmb3JtIHBhdHRlcm4gZXhwKQogKGRlY2xhcmUgKGlnbm9yZSBmb3JtKSkKICBgKCwoZGNx
ZXhwIHBhdHRlcm4gJz0pICxleHApKQpACgo8PHJwbHE+Pj0KKGRlZm1hY3JvIHJwbHEgKCZ3aG9s
ZSBmb3JtIGV4cCBwYXR0ZXJuKQogKGlmIChvciAoY29uc3AgcGF0dGVybikgKHNpbXBsZS12ZWN0
b3ItcCBwYXR0ZXJuKSkKICBgKCwocmNxZXhwIHBhdHRlcm4pICxleHApCiAgIChtYWNyby1pbnZh
bGlkYXJncyAncnBscSBmb3JtICJmb3JtIG11c3QgYmUgdXBkYXRlYWJsZS4iKSkpCkAKCjw8c2V0
YW5kZmlsZXE+Pj0KKGRlZm1hY3JvIHNldGFuZGZpbGVxIChpZCBpdGVtKQogYChldmFsLXdoZW4g
KGV2YWwgbG9hZCkgCiAgIChzZXRxICxpZCAsaXRlbSkKICAgKGxhbVwsZmlsZWFjdHEgJyxpZCAo
bGlzdCAnc2V0cSAnLGlkIChsaXN0ICdxdW90ZSAsaWQpKSkpKQpACjw8c2V0cXA+Pj0KKGRlZm1h
Y3JvIHNldHFwICgmd2hvbGUgZm9ybSBwYXR0ZXJuIGV4cCkKIChkZWNsYXJlIChpZ25vcmUgZm9y
bSkpCiAgYCgsKGRjcWV4cCBwYXR0ZXJuICc9KSAsZXhwKSkKQAoKXHNlY3Rpb257T2Jzb2xldGUg
RnVuY3Rpb25zfQpcbGFiZWx7c2VjOk9ic29sZXRlRnVuY3Rpb25zfQoKVGhlIGZ1bmN0aW9ucyBp
biB0aGlzIHNlY3Rpb24gYXJlIG9ic29sZXRlIGluIHRoZSBzZW5zZSB0aGF0ClxiZWdpbntlbnVt
ZXJhdGV9ClxpdGVtIHRoZXkgYXJlbid0IGNhbGxlZCBhbnl3aGVyZSBpbiB0aGUgQXhpb20gc291
cmNlIHRyZWUsClxpdGVtIHRoZXkgYXJlbid0IHVzZWZ1bCBmb3IgaW50ZXJhY3RpdmUgdXNlL2Rl
YnVnZ2luZy4KXGVuZHtlbnVtZXJhdGV9CkhlbmNlIHRoZXkgYXJlIHRydWx5IG9ic29sZXRlLCBu
b3QganVzdCB1c2VsZXNzIG9yIGRlcHJlY2F0ZWQuCgo8PGNhbGxiZWxvdz4+PQooZGVmdW4gQ0FM
TEJFTE9XICgmcmVzdCBqdW5rKSBqdW5rKSA7IHRvIGludm9rZSBzeXN0ZW0gZGVwZW5kZW50IGNv
ZGU/CkAKClRoZSBjb21tZW50IGluIHRoZSBuZXh0IGZ1bmN0aW9uIGlzIHdyb25nLiBJdCBpc24n
dCBldmVuIHJlZmVycmVkIHRvCmluIFtbUEFSSU5JLkJPT1QuUEFNUEhMRVRdXS4KPDxxdW9yZW0+
Pj0KKGRlZnVuIFFVT1JFTSAoaSBqIHIpIDsgbmV2ZXIgdXNlZCwgcmVmZWQgaW4gcGFyaW5pLmJv
b3QKICAobXVsdGlwbGUtdmFsdWUtYmluZCAoeCB5KSAodHJ1bmNhdGUgaSBqKQogICAocnBsYWNh
ICh0aGUgY29ucyByKSB4KSAocnBsYWNkICh0aGUgY29ucyByKSB5KSkpCkAKCjw8ZnVuYXJncD4+
PQooZGVmdW4gRlVOQVJHUCAoaXRlbSkKIChkZWNsYXJlIChpZ25vcmUgaXRlbSkpCiAgbmlsKSA7
Y2FuJ3QgdGVsbCBjbG9zdXJlcyBmcm9tIG90aGVyIGZ1bmN0aW9ucwpACgoKXHNlY3Rpb257RnVu
Y3Rpb25zIGluIHRoZSBCT09UIFBhY2thZ2V9ClxsYWJlbHtzZWM6RnVuY3Rpb25zSW5UaGVCT09U
UGFja2FnZX0KClRoaXMgc2VjdGlvbiBjb250YWlucyB0aGUgY29kZSB0byBmdW5jdGlvbnMgdGhh
dCBsaXZlIGluIHRoZSBbW0JPT1RdXQpwYWNrYWdlLiBIYXZpbmcgbXVsdGlwbGUgW1tJTi1QQUNL
QUdFXV0gZm9ybXMgaW4gYSBzaW5nbGUgZmlsZSBpcwp1c3VhbGx5IGZyb3duZWQgdXBvbiwgYnV0
IHNpbmNlIGl0J3MgYWxsIGdvaW5nIGludG8gYm9va3ZvbDUgYW55d2F5LAp0aGVyZSdzIG5vIHBv
aW50IGluIHB1dHRpbmcgdGhlc2UgaW4gYSBkaWZmZXJlbnQgZmlsZS4KPDx8QWxpc3RBc3NvY1F8
Pj49Cjs7LS0tLS0tLS0tLS0tLS0tLS0tLS0+IE5FVyBERUZJTklUSU9OIChzZWUgdW5saXNwLmxp
c3AucGFtcGhsZXQpCihkZWZ1biB8QWxpc3RBc3NvY1F8IChrZXkgbCkKICAoYXNzb2Mga2V5IGwg
OnRlc3QgIydlcSkgKQpACgo8PHxMaXN0TWVtYmVyP3w+Pj0KOzstLS0tLS0tLS0tLS0tLS0tLS0t
LT4gTkVXIERFRklOSVRJT04gKHNlZSB1bmxpc3AubGlzcC5wYW1waGxldCkKKGRlZnVuIHxMaXN0
TWVtYmVyP3wgKG9iIGwpCiAgKG1lbWJlciBvYiBsIDp0ZXN0ICMnZXF1YWwpICkKQAoKPDwqbnBQ
UGFyZyo+Pj0KKGRlZnZhciAqbnBQUGFyZyogbmlsICJyZXdyaXRlIGZsZXRzLCB1c2luZyBnbG9i
YWwgc2NvcGluZyIpCkAKCjw8bnBQUGZmPj49CihkZWZ1biBucFBQZmYgKCkgKGFuZCAoZnVuY2Fs
bCAqbnBQUGFyZyopICh8bnBQdXNofCAobGlzdCAofG5wUG9wMXwpKSkpKQpACgo8PG5wUFBmPj49
CihkZWZ1biBucFBQZiAoKSAofG5wU2VtaUxpc3Rpbmd8IChmdW5jdGlvbiBucFBQZmYpKSkKQAoK
PDxucFBQZz4+PQooZGVmdW4gbnBQUGcgKCkgCiAoYW5kICh8bnBMaXN0QW5kUmVjb3ZlcnwgKGZ1
bmN0aW9uIG5wUFBmKSkpCiAofG5wUHVzaHwgKHxwZkFwcGVuZHwgKHxucFBvcDF8KSkpKQpACgo8
PHxucFBQfD4+PQooZGVmdW4gfG5wUFB8ICh8ZnwpCiAoZGVjbGFyZSAoc3BlY2lhbCAqbnBQUGFy
ZyopKQogIChzZXRxICpucFBQYXJnKiB8ZnwpCiAgKG9yICh8bnBQYXJlbmVkfCAoZnVuY3Rpb24g
bnBQUGYpKQogICAgKGFuZCAgKHxucFBpbGVCcmFja2V0ZWR8IChmdW5jdGlvbiBucFBQZykpCiAg
ICAgICAgICAofG5wUHVzaHwgKHxwZkVuU2VxdWVuY2V8ICh8bnBQb3AxfCkpKSkKICAgICAgIChm
dW5jYWxsIHxmfCkpKQpACgo8PCpucFBDZmYqPj49CihkZWZ2YXIgKm5wUENmZiogbmlsICJyZXdy
aXRlIGZsZXRzLCB1c2luZyBnbG9iYWwgc2NvcGluZyIpCkAKCjw8bnBQQ2ZmPj49CihkZWZ1biBu
cFBDZmYgKCkgKGFuZCAoZnVuY2FsbCAqbnBQQ2ZmKikgKHxucFB1c2h8IChsaXN0ICh8bnBQb3Ax
fCkpKSkpCkAKCjw8bnBQQ2c+Pj0KKGRlZnVuIG5wUENnICgpIAogKGFuZCAofG5wTGlzdEFuZFJl
Y292ZXJ8IChmdW5jdGlvbiBucFBDZmYpKSkKICh8bnBQdXNofCAofHBmQXBwZW5kfCAofG5wUG9w
MXwpKSkpCkAKCjw8fG5wUEN8Pj49CihkZWZ1biB8bnBQQ3wgKHxmfCkKICAob3IKICAgIChhbmQg
KHxucFBpbGVCcmFja2V0ZWR8IChmdW5jdGlvbiBucFBDZykpCiAgICAgICAgICh8bnBQdXNofCAo
fHBmRW5TZXF1ZW5jZXwgKHxucFBvcDF8KSkpKQogICAgKGZ1bmNhbGwgfGZ8KSkpCkAKCjw8fHN0
cmluZ0xFMXw+Pj0KKGRlZnVuIHxzdHJpbmdMRTF8ICh4IHkpCiAgKHN0cmluZzw9IHggeSA6c3Rh
cnQxIDEgOnN0YXJ0MiAyKSkKQAoKPDx8c29ydENhclN0cmluZ3w+Pj0KKGRlZnVuIHxzb3J0Q2Fy
U3RyaW5nfCAobGluZXMpCiAgKHNvcnQgbGluZXMgIydzdHJpbmc8PSA6a2V5ICMnY2FyKSkKQAoK
PDx8aW5zZXJ0U3RyaW5nfD4+PQooZGVmdW4gfGluc2VydFN0cmluZ3wgKHMxIHMyIGkxKQogICAo
cmVwbGFjZSBzMiBzMSA6c3RhcnQxIGkxIDplbmQxICgxKyBpMSkgOmVuZDIgKHNpemUgczEpKSkg
CkAKClxzdWJzZWN0aW9ue01pc3NpbmcgREZMT0FUIFRyYW5zY2VuZGVudGFsIGZ1bmN0aW9uc30K
VGhlc2UgZnVuY3Rpb25zIHNob3VsZCBiZSBkZWZpbmVkIGZvciBEb3VibGVGbG9hdCBpbnB1dHMg
YnV0IGFyZSBub3QuClRoZXNlIGFyZSBjaGVhcCBhbmQgZWFzeSBkZWZpbml0aW9ucyB0aGF0IHdv
cmsgYnV0IHNob3VsZCBiZSByZXdyaXR0ZW4uCjw8TWlzc2luZyBERkxPQVQgVHJhbnNjZW5kZW50
YWwgZnVuY3Rpb25zPj49CihkZWZ1biBzZWMgKHgpICgvIDEgKGNvcyB4KSkpCihkZWZ1biBjc2Mg
KHgpICgvIDEgKHNpbiB4KSkpCihkZWZ1biBhY3NjICh4KSAoYXNpbiAoLyAxIHgpKSkKKGRlZnVu
IGFzZWMgKHgpIChhY29zICgvIDEgeCkpKQooZGVmdW4gY3NjaCAoeCkgKC8gMSAoc2luaCB4KSkp
CihkZWZ1biBjb3RoICh4KSAoKiAoY29zaCB4KSAoY3NjaCB4KSkpCihkZWZ1biBzZWNoICh4KSAo
LyAxIChjb3NoIHgpKSkKKGRlZnVuIGFjc2NoICh4KSAoYXNpbmggKC8gMSB4KSkpCihkZWZ1biBh
Y290aCAoeCkgKGF0YW5oICgvIDEgeCkpKQooZGVmdW4gYXNlY2ggKHgpIChhY29zaCAoLyAxIHgp
KSkKQAoKXHN1YnNlY3Rpb257VGhlIG1hbmV4cCBmaXh9CkNvbnRyaWJ1dGVkIGJ5IEp1ZXJnZW4g
V2Vpc3MgZnJvbSBhIHN1Z2dlc3Rpb24gYnkgQXJ0aHVyIE5vcm1hbi4KVGhpcyBpcyBhIE1hbnRp
c3NhIGFuZCBFeHBvbmVudCBmdW5jdGlvbi4gCjw8bWFuZXhwPj49CiMrKG9yIDpjbXUgOmFrY2wg
OmdjbCkKKGRlZnVuIG1hbmV4cCAodSkKICAobXVsdGlwbGUtdmFsdWUtYmluZCAoZiBlIHMpIAog
ICAgKGRlY29kZS1mbG9hdCB1KQogICAgKGNvbnMgKCogcyBmKSBlKSkpCkAKClxzdWJzZWN0aW9u
e1RoZSBhcmMgY290YW5nZW50IGZ1bmN0aW9ufQpDb250cmlidXRlZCBieSBKdWVyZ2VuIFdlaXNz
IGZyb20gQXJ0aHVyIE5vcm1hbidzIENDTC4KPDxhY290Pj49CiMrOihvciA6Y211IDpha2NsIDpn
Y2wpCihkZWZ1biBhY290IChhKQogIChpZiAoPiBhIDAuMCkKICAgIChpZiAoPiBhIDEuMCkKICAg
ICAgIChhdGFuICgvIDEuMCBhKSkKICAgICAgICgtICgvIHBpIDIuMCkgKGF0YW4gYSkpKQogICAg
KGlmICg8IGEgLTEuMCkKICAgICAgICgtIHBpIChhdGFuICgvIC0xLjAgYSkpKQogICAgICAgKCsg
KC8gcGkgMi4wKSAoYXRhbiAoLSBhKSkpKSkpCkAKClxzdWJzZWN0aW9ue1RoZSBhcmMgY290YW5n
ZW50IGZ1bmN0aW9ufQpDb250cmlidXRlZCBieSBKdWVyZ2VuIFdlaXNzIGZyb20gQXJ0aHVyIE5v
cm1hbidzIENDTC4KPDxjb3Q+Pj0KIys6KG9yIDpjbXUgOmFrY2wgOmdjbCkKKGRlZnVuIGNvdCAo
YSkKICAoaWYgKG9yICg+IGEgMTAwMC4wKSAoPCBhIC0xMDAwLjApKQogICAgKC8gKGNvcyBhKSAo
c2luIGEpKQogICAgKC8gMS4wICh0YW4gYSkpKSkKQAoKXHN1YnNlY3Rpb257VGhlIGFyYyBjb3Rh
bmdlbnQgZnVuY3Rpb259CkNvbnRyaWJ1dGVkIGJ5IEp1ZXJnZW4gV2Vpc3MgZnJvbSBBcnRodXIg
Tm9ybWFuJ3MgQ0NMLgo8PGFzZWM+Pj0KIys6KG9yIDpjbXUgOmFrY2wgOmdjbCkKKGRlZnVuIGFz
ZWMgKGEpCiAgKGlmIChhbmQgKGEgPiAtMS4wKSAoYSA8IDEuMCkpCiAgICAwLjAKICAgIChhY29z
ICgvIDEuMCBhKSkpKQpACgpcc2VjdGlvbntMaWNlbnNlfQo8PGxpY2Vuc2U+Pj0KOzsgQ29weXJp
Z2h0IChjKSAxOTkxLTIwMDIsIFRoZSBOdW1lcmljYWwgQUxnb3JpdGhtcyBHcm91cCBMdGQuCjs7
IEFsbCByaWdodHMgcmVzZXJ2ZWQuCjs7Cjs7IFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291
cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAo7OyBtb2RpZmljYXRpb24sIGFy
ZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlCjs7
IG1ldDoKOzsKOzsgICAgIC0gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0
YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKOzsgICAgICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29u
ZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgo7Owo7OyAgICAgLSBSZWRpc3Ry
aWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdo
dAo7OyAgICAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93
aW5nIGRpc2NsYWltZXIgaW4KOzsgICAgICAgdGhlIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVy
IG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZQo7OyAgICAgICBkaXN0cmlidXRpb24uCjs7Cjs7
ICAgICAtIE5laXRoZXIgdGhlIG5hbWUgb2YgVGhlIE51bWVyaWNhbCBBTGdvcml0aG1zIEdyb3Vw
IEx0ZC4gbm9yIHRoZQo7OyAgICAgICBuYW1lcyBvZiBpdHMgY29udHJpYnV0b3JzIG1heSBiZSB1
c2VkIHRvIGVuZG9yc2Ugb3IgcHJvbW90ZSBwcm9kdWN0cwo7OyAgICAgICBkZXJpdmVkIGZyb20g
dGhpcyBzb2Z0d2FyZSB3aXRob3V0IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4gcGVybWlzc2lvbi4K
OzsKOzsgVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQ09QWVJJR0hUIEhPTERFUlMg
QU5EIENPTlRSSUJVVE9SUyAiQVMKOzsgSVMiIEFORCBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdB
UlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVECjs7IFRPLCBUSEUgSU1QTElFRCBX
QVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQQo7OyBQQVJUSUNV
TEFSIFBVUlBPU0UgQVJFIERJU0NMQUlNRUQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBDT1BZUklH
SFQgT1dORVIKOzsgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5E
SVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsCjs7IEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElB
TCBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywKOzsgUFJPQ1VSRU1FTlQg
T0YgU1VCU1RJVFVURSBHT09EUyBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SCjs7
IFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9O
IEFOWSBUSEVPUlkgT0YKOzsgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1Qg
TElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcKOzsgTkVHTElHRU5DRSBPUiBPVEhFUldJU0Up
IEFSSVNJTkcgSU4gQU5ZIFdBWSBPVVQgT0YgVEhFIFVTRSBPRiBUSElTCjs7IFNPRlRXQVJFLCBF
VkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgoKQAoKXHNl
Y3Rpb257U291cmNlfQpcbGFiZWx7c2VjOlNvdXJjZX0KClRoZSBvcmRlciBvZiB0aGUgY2h1bmtz
IHNob3VsZCBiZSBjbGVhbmVkIHVwIGV2ZW50dWFsbHkuIFRoaXMgc2hvdWxkCmhhcHBlbiBhZnRl
ciB0aGUgY29kZSBpdHNlbGYgaGFzIGJlZW4gY2xlYW5lZCB1cC4gQmUgY2FyZWZ1bCB3aGVuCmNo
YW5naW5nIHRoZSBvcmRlcjogaXQgbWlnaHQgYnJlYWsgdGhlIGJ1aWxkIQoKQWxzbyBwYXkgYXR0
ZW50aW9uIHRvIHRoZSBbWyhpbi1wYWNrYWdlICdib290KV1dIGZvcm0gdG93YXJkcyB0aGUgZW5k
Cm9mIHRoZSBmaWxlLgo8PCo+Pj0KPDxsaWNlbnNlPj4KCihpbi1wYWNrYWdlICJWTUxJU1AiKQoK
Iy06Y29tbW9uLWxpc3AgCiAoc2V0cSAqZmVhdHVyZXMqIChhZGpvaW4gOmNvbW1vbi1saXNwICpm
ZWF0dXJlcyopKQoKOzsgREVGVkFSUwoKPDxjb21wMzcwLWFwcGx5Pj4KPDxjdXJpbm91dHN0cmVh
bT4+Cjw8KmVtYmVkZGVkLWZ1bmN0aW9ucyo+Pgo8PGVycm9yaW5vdXRzdHJlYW0+Pgo8PGZpbGVh
Y3RxLWFwcGx5Pj4KPDwqbGFtLW5hbWUqPj4KPDxtYWNlcnJvcmNvdW50Pj4KPDwqcmVhZC1wbGFj
ZS1ob2xkZXIqPj4KCjw8ZGVmaW5lLWZ1bmN0aW9uPj4KPDxtZGVmPj4KPDxjb21wMzcwPj4KPDx1
cC9kb3duLWNhc2U+Pgo8PHByb3BsaXN0Pj4KPDxxdW90aWVudD4+Cjw8cmVtYWluZGVyPj4KPDxk
aXZpZGU+Pgo8PGxpc3QydmVjPj4KPDxjZ3JlYXRlcnA+Pgo8PGNvbmNhdD4+Cjw8bWFrZS1jdmVj
Pj4KPDxtYWtlLWZ1bGwtY3ZlYz4+Cgo7OyBERUZNQUNST1MKCjw8YWxpYXNlcz4+Cjw8YXNzZW1i
bGU+Pgo8PGFzc3E+Pgo8PGJpbnRwPj4KPDx8Y2hhcnw+Pgo8PG5vLW9wcz4+Cjw8ZGNxPj4KPDxk
ZWZpbmUtbWFjcm8+Pgo8PGVjcT4+Cjw8ZXFjYXI+Pgo8PGVxcT4+Cjw8ZXZhbGFuZGZpbGVhY3Rx
Pj4KPDxleGl0Pj4KPDxmaXhwPj4KPDxpPT4+Cjw8fGlkQ2hhcj98Pj4KPDxpZGVudHA+Pgo8PGlm
Y2FyL2lmY2RyPj4KPDxsYW0+Pgo8PGxpbnRwPj4KPDxtYXBlbHQ+Pgo8PG1heGluZGV4Pj4KPDxt
ZW1xPj4KPDxtcnBzZnA+Pgo8PG5hbWVkZXJyc2V0Pj4KPDxuZT4+Cjw8bmVxPj4KPDxucmV2ZXJz
ZTA+Pgo8PHxvcE9mfD4+Cjw8b3JhZGR0ZW1wZGVmcz4+Cjw8cWNhci1mYW1pbHk+Pgo8PHFjc2l6
ZT4+Cjw8cWVxcT4+Cjw8cWxlbmd0aD4+Cjw8cXJwbGFjPj4KPDxxcnBscT4+Cjw8cWFyaXRobWV0
aWM+Pgo8PHFzZXRxPj4KPDxxc2VxdmVjPj4KPDxyZXNldHE+Pgo8PHJwbHE+Pgo8PHJ2ZWNwPj4K
PDxzZXRhbmRmaWxlcT4+Cjw8c2V0ZWx0Pj4KPDxzZXRxcD4+Cjw8c2VxPj4KPDxzaG9lLWlvPj4K
PDxzaW50cD4+Cjw8c21pbnRwPj4KPDx8c3RhcnRzSWQ/fD4+Cjw8c3RyaW5nbGVuZ3RoPj4KPDx2
ZWMtc2V0ZWx0Pj4KPDx6ZXJvPz4+Cgo7OyBkZWZ1bnMKCjw8XCR0b3RhbC1lbGFwc2VkLXRpbWU+
Pgo8PHRvdGFsLWdjLXRpbWU+PgoKOyA3LjAgTWFjcm9zCgo7IDcuMiBDcmVhdGluZyBNYWNybyBF
eHByZXNzaW9ucwoKOyA1LjIgRnVuY3Rpb25zCgo7IDUuMi4yIExhbWJkYSBFeHByZXNzaW9ucwoK
PDwqbGFtPj4KPDx3cmFwPj4KPDxpc3F1b3RlZHA+Pgo8PHF1b3Rlc29mPj4KPDxkZXF1b3RlPj4K
PDxsb3Rzb2Y+PgoKOyA3LjQgVXNpbmcgTWFjcm9zCgo7IDguMCBPcGVyYXRvciBEZWZpbml0aW9u
IGFuZCBUcmFuc2Zvcm1hdGlvbgoKOyA4LjEgRGVmaW5pdGlvbiBhbmQgVHJhbnNmb3JtYXRpb24g
T3BlcmF0aW9ucwoKPDxjb21waWxlMT4+Cjw8c2ltcGxlLWFyZ2xpc3Q+Pgo8PHJlbW92ZS1mbHVp
ZHM+PgoKOyA5LjQgVmVjdG9ycyBhbmQgQnBpcwoKPDxpdmVjcD4+Cjw8bWJwaXA+Pgo8PGZicGlw
Pj4KCjsgOS41IElkZW50aWZpZXJzCgo8PGdlbnN5bXA+Pgo8PGRpZ2l0cD4+Cjw8ZGlnMmZpeD4+
Cjw8bG9nL2xuPj4KCjsgOS4xMyBTdHJlYW1zCgo8PGlzLWNvbnNvbGU+PgoKOyAxMC4wIENvbnRy
b2wgU3RydWN0dXJlcwoKOyAxMC44LjQgQXV4aWxpYXJ5IE9wZXJhdG9ycwoKPDxuaWxmbj4+Cgo7
IDExLjAgT3BlcmF0aW9ucyBvbiBJZGVudGlmaWVycwoKOyAxMS4xIENyZWF0aW9uCgo7IDExLjIg
QWNjZXNzaW5nCgo8PHBuYW1lPj4KCjsgMTIuMCBPcGVyYXRpb25zIG9uIE51bWJlcnMKCjsgMTIu
MSBDb252ZXJzaW9uCgo7IDEyLjIgUHJlZGljYXRlcwoKOyAxMi4zIENvbXB1dGF0aW9uCgo7IDEz
LjMgVXBkYXRpbmcKCjw8cnBscGFpcj4+Cjw8cnBsbm9kZT4+Cgo7IDE0LjAgT3BlcmF0aW9ucyBv
biBMaXN0cwoKOyAxNC4xIENyZWF0aW9uCgo8PHZlYzJsaXN0Pj4KPDx8bWVtYmVyfD4+Cjw8fHJl
bW92ZXw+Pgo8PHJlbW92ZXE+PgoKOyAxNC4yIEFjY2Vzc2luZwoKPDx8bGFzdHw+PgoKOyAxNC4z
IFNlYXJjaGluZwoKPDx8YXNzb2N8Pj4KCjsgMTQuNSBVcGRhdGluZwoKPDxucmVtb3ZlPj4KPDxu
cmVtb3ZlcT4+Cjw8ZWZmYWNlPj4KPDxuY29uYzI+PgoKOyAxNC42IE1pc2NlbGxhbmVvdXMKCjw8
cXNvcnQ+Pgo8PHNvcnRieT4+Cgo7IDE2LjAgT3BlcmF0aW9ucyBvbiBWZWN0b3JzCgo7IDE2LjEg
Q3JlYXRpb24KCjw8bWFrZS12ZWM+PgoKOyAxNi4yIEFjY2Vzc2luZwoKPDxzaXplPj4KCjsgMTcu
MCBPcGVyYXRpb25zIG9uIENoYXJhY3RlciBhbmQgQml0IFZlY3RvcnMKCjw8Y2hhcnA+Pgo8PGNo
YXIybnVtPj4KCjsgMTcuMSBDcmVhdGlvbgoKOyAxNy4yIEFjY2Vzc2luZwoKPDxxZW51bT4+Cjw8
cWVzZXQ+Pgo8PHN0cmluZzJpZC1uPj4KPDxzdWJzdHJpbmc+PgoKOyAxNy4zIFNlYXJjaGluZwoK
PDxzdHJwb3M+Pgo8PHN0cnBvc2w+PgoKOyAxNy40IFVwZGF0aW5nIG9wZXJhdG9ycwoKPDxzdWZm
aXg+Pgo8PGNoYW5nZS1sZW5ndGgvc2V0c2l6ZT4+Cjw8cnBsYWNzdHI+PgoKOyAxOS4wIE9wZXJh
dGlvbnMgb24gQXJiaXRyYXJ5IE9iamVjdHMKCjsgMTkuMSBDcmVhdGluZwoKPDxzdWJzdD4+Cjw8
Y29weT4+Cjw8ZXFzdWJzdGxpc3Q+Pgo8PGRjcWV4cD4+Cjw8ZGNxZ2VuZXhwPj4KCjsgMTkuMyBT
ZWFyY2hpbmcKCjw8ZWNxZXhwPj4KPDxlY3FnZW5leHA+PgoKOyAxOS40IFVwZGF0aW5nCgo8PHJj
cWV4cD4+Cjw8cmNxZ2VuZXhwPj4KCjsgMjIuMCBJbnRlcm5hbCBhbmQgRXh0ZXJuYWwgRm9ybXMK
CjsgMjMuMCBSZWFkaW5nCgo7IDI0LjAgUHJpbnRpbmcKCjw8c3RyaW5naW1hZ2UgZml4Pj4KPDx8
ZixwcmludC1vbmV8Pj4KPDxwcmV0dHlwcmludD4+Cjw8dm1wcmludD4+Cjw8dGFiPj4KCjsgMjcu
MCBTdHJlYW0gSS9PCgo7IDI3LjEgQ3JlYXRpb24KCjw8bWFrZS1pbm91dC1zdHJlYW0+Pgo8PG1h
a2UtYXBwZW5kc3RyZWFtPj4KPDxkZWZpb3N0cmVhbT4+Cjw8c2h1dD4+Cjw8ZW9mcD4+Cgo7IDI4
LjAgS2V5IGFkZHJlc3NlZCBJL08KCjsgNDYuMCBDYWxsIHRyYWNpbmcKCjw8ZW1iZWRkZWQ+Pgo8
PGVtYmVkPj4KPDx1bmVtYmVkPj4KPDxmbGF0LWJ2LWxpc3Q+Pgo8PHZhcnA+PgoKOyA0OC4wIE1p
c2NlbGxhbmVvdXMgQ01TIEludGVyYWN0aW9ucwoKPDxjdXJyZW50dGltZT4+Cjw8c2NyZWVuc2l6
ZT4+Cgo7IDk3LjAgU3R1ZmYgSW4gVGhlIE1hbnVhbCBCdXQgV2llcmRseSBEb2N1bWVudGVkCgo8
PGViY2RpYz4+Cjw8ZG9kc2V0cT4+Cjw8bWFjcm8taW52YWxpZGFyZ3M+Pgo8PG1hY3JvLW1pc3Np
bmdhcmdzPj4KPDxtYWNlcnI+Pgo8PG51bWJlcm9mYXJncz4+Cgo7IDk4LjAgU3R1ZmYgTm90IElu
IFRoZSBWTUxpc3AgTWFudWFsIFRoYXQgV2UgTGlrZQoKPDxnZXRsPj4KPDxcJHNob3dsaW5lPj4K
CjsgOTkuMCBBbmNpZW50IFN0dWZmIFdlIERlY2lkZWQgVG8gS2VlcAoKPDxsYW0sZXZhbGFuZGZp
bGVhY3RxPj4KPDxjYWxsYmVsb3c+Pgo8PHBsYWNlcD4+Cjw8dm1yZWFkPj4KPDx8cmVhZC1saW5l
fD4+Cjw8c3RhdGVwPj4KPDxmdW5hcmdwPj4KPDxwYXBwcD4+Cjw8Z2MtdmVyYm9zaXR5Pj4KPDxy
ZWNsYWltPj4KPDxicGluYW1lPj4KPDxsaXN0b2ZxdW90ZXM+Pgo8PGxpc3RvZmZyZWVzPj4KPDxv
YmV5Pj4KPDxlcXVhYmxlPj4KPDxxdW9yZW0+Pgo8PG1ha2UtYnZlYz4+CgoKOzs7Ozs7Ozs7Ozs7
Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7OzsKOzs7
OyAgICAgICAgICAgICAgSEVSRSBXRSBDSEFOR0UgVEhFIFBBQ0tBR0UhICAgICAgICAgICAgICAg
IDs7OzsKOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7
Ozs7Ozs7Ozs7Ozs7OzsKCihpbi1wYWNrYWdlICdib290KQoKPDxtYW5leHA+Pgo8PGFjb3Q+Pgo8
PGNvdD4+Cjw8YXNlYz4+Cjw8Z2V0Q0Q+Pgo8PE1pc3NpbmcgREZMT0FUIFRyYW5zY2VuZGVudGFs
IGZ1bmN0aW9ucz4+Cjw8fEFsaXN0QXNzb2NRfD4+Cjw8fExpc3RNZW1iZXI/fD4+Cgo7IHJld3Jp
dGUgbm5QUCBmb3IgY3NsLCB3aGljaCBkb2VzIG5vdCBzdXBwb3J0IGZsZXQKPDwqbnBQUGFyZyo+
Pgo8PG5wUFBmZj4+Cjw8bnBQUGY+Pgo8PG5wUFBnPj4KPDx8bnBQUHw+PgoKPDwqbnBQQ2ZmKj4+
Cjw8bnBQQ2ZmPj4KPDxucFBDZz4+Cjw8fG5wUEN8Pj4KCjw8fHN0cmluZ0xFMXw+Pgo8PHxzb3J0
Q2FyU3RyaW5nfD4+Cjw8fGluc2VydFN0cmluZ3w+PgoKQApcZWplY3QKXGJlZ2lue3RoZWJpYmxp
b2dyYXBoeX17OTl9ClxiaWJpdGVtezF9IG5vdGhpbmcKXGVuZHt0aGViaWJsaW9ncmFwaHl9Clxl
bmR7ZG9jdW1lbnR9Cg==
--=-=-=--

\start
Date: Thu, 21 Sep 2006 09:52:45 -0700
From: Alfredo Portes
To: list
Subject: Fwd: [M#73697383] Re: Disk-quota Request

---------- Forwarded message ----------
From: Ben Collins-Sussman

On 9/19/06, Alfredo Portes wrote:

> Ok. We can work with 100MB more. Please let me know as soon as you increase
> the quota size.
>

I've added another 150MB, bringing your total quota to 250MB.  Let us
know how it goes!

\start
Date: Thu, 21 Sep 2006 12:55:24 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: Literated VMLISP.LISP.PAMPHLET

On Thursday, September 21, 2006 11:51 AM Kai Kaminski wrote:
>
> I've 'literated' VMLISP.LISP.PAMPHLET (the result is attached), which
> contains compatibility/utility code.
> ...

Here is Kai's revision as a pamphlet file on the Axiom Wiki:

http://wiki.axiom-developer.org/axiom--test--1/src/interp/VmlispLisp

The think the result is quite beautiful.

I just clicked edit and cut-and-pasted Kai's draft into the source
for this page.

After review this and test that it still compiles, I think it should
become parge of the main Axiom distribution. Personally, I much prefer
this approach rather than the single-file monolithic "book volume"
approach that Tim Daly has proposed.

\start
Date: Thu, 21 Sep 2006 13:53:15 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: Google Code repository

I am having a terrible time trying to install both subversion as
a server and svk on the axiom-developer.org server.

Both the problem (and the advantage) of subversion as a server
is that it integrates closely with Apache. The version of
Apache that we are running on axiom-developer is too old and
in any case would need to be re-compiled with different options
to use the mod_dav_svn module. So before I can get that working
I have to first have to re-build Apache from source. Getting
this right and converting our httpd.conf configuration to the
new version of Apache is going to take me a few more days. :-(

In the mean time I have also been trying to install svk on this
server because in principle it can be used to help with mirroring
svn branches on other systems and provides additional features
such as star-merge etc.

But even this installation is turning out to be very difficult!
:-( As we discussed during the Skype meeting on Monday, in order
to get svk running I have been struggling with the prerequisite
svn secondary installation procedures that involves some serious
Perl dependencies, svn::core etc. I thought I (finally) had all
that figured out, but now I get the following error when trying
to start svk:

[page@axiom-developer page]$ svk
Can't locate Class/Autouse.pm in @INC (@INC contains:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 .) at
/usr/lib/perl5/site_perl/5.8.0/SVK.pm line 6.
BEGIN failed--compilation aborted at
/usr/lib/perl5/site_perl/5.8.0/SVK.pm line 6.
Compilation failed in require at /usr/bin/svk line 6.
BEGIN failed--compilation aborted at /usr/bin/svk line 6.
[page@axiom-developer page]$

-------

Perhaps you or someone else who is more familiar with the advanced
use of Perl than I am could suggest where to go from here?

<frustration>
  Man! You sure can tell that subversion was designed by people
  who liked cvs ... ;)
</frustration>

\start
Date: Thu, 21 Sep 2006 20:51:17 +0200
From: Gregory Vanuxem
To: Bill Page, Gabriel Dos Reis
Subject: re: Google Code repository

> -----Message d'origine-----
 
> [page@axiom-developer page]$ svk
> Can't locate Class/Autouse.pm in @INC (@INC contains:
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0
> /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl
> /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 .) at
> /usr/lib/perl5/site_perl/5.8.0/SVK.pm line 6.
> BEGIN failed--compilation aborted at
> /usr/lib/perl5/site_perl/5.8.0/SVK.pm line 6.
> Compilation failed in require at /usr/bin/svk line 6.
> BEGIN failed--compilation aborted at /usr/bin/svk line 6.
> [page@axiom-developer page]$ 
> 
> -------
> 
> Perhaps you or someone else who is more familiar with the advanced
> use of Perl than I am could suggest where to go from here?

The Class::Autouse module is missing. See 
http://search.cpan.org/~adamk/Class-Autouse-1.27/. If there is no package
for your distribution (it is named libclass-autouse-perl in Debian),
you can build, test and install the module with:
perl Makefile.pl
make
make test
make install 

\start
Date: Thu, 21 Sep 2006 21:12:26 +0200
From: Gregory Vanuxem
To: Bill Page, Ralf Hemmecke
Subject: re: [build Axiom] updated Windows buildinstructions

> -----Message d'origine-----

> This is part of the communications interface between Axiom and
> Axiom Graphics. Axiom Graphics is a separate program written in
> "C" that does all of the interaction with X11. AXIOMsys (which
> is the program that runs the code at which you are looking) sends
> commands to Axiom Graphics via a session socket.

Ho, I was totally wrong this week-end when I spoke about some socket
related code not used. I reread the sockio.lisp.pamphlet file and found
the functions used in the interpreter (I have never studied these parts
of the intergreter). Sorry for this.

PS: Humm... shame on me.

\start
Date: Thu, 21 Sep 2006 21:23:30 +0200
From: Gregory Vanuxem
To: Kai Kaminski
Subject: RE: Literated VMLISP.LISP.PAMPHLET

> -----Message d'origine-----
> 
> I've 'literated' VMLISP.LISP.PAMPHLET (the result is attached), which
> contains compatibility/utility code. 

Awesome! I quickly read your file and you have used
\subsection{The arc cotangent function} for cot and asec too :-)

Many thanks for Axiom.

\start
Date: Thu, 21 Sep 2006 15:37:36 -0400
From: Alfredo Portes
To: list
Subject: Re: Google Code repository

> Well, this is open source development which mean "release early
> and releas often". The more accessible our experimental branchs
> are, the more they will be tested and the better our software
> will become. Of course people have to be warned about exactly what
> they are downloading so that they have the proper expectations
> about how it might/might not work. But I think we want to encourage
> people to at least try the latest experimental versions. As an
> Axiom developer that is the only version I am really interested
> in.

I have committed the build-improvements branch to the trunk
of the Google Repository: http://axiom.googlecode.com/svn/trunk/

One can checkout the source by doing:
svn checkout http://axiom.googlecode.com/svn/trunk/ axiom

Can you please add something in the page: http://code.google.com/p/axiom/
explaining like you did in your comment above that this repository is
an experimental version.

\start
Date: Thu, 21 Sep 2006 22:10:50 +0200
From: Ralf Hemmecke
To: Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET

I don't much understand lisp, but what you did in literating the code is 
just super.

On 09/21/2006 05:51 PM, Kai Kaminski wrote:
> Hi,
> 
> I've 'literated' VMLISP.LISP.PAMPHLET (the result is attached), which
> contains compatibility/utility code. In particular, I did the
> following:
> 
> 1) I gave most functions their own chunk. Sometimes I put several
>    functions in a single chunk, mostly because they didn't need
>    individual documentation. For example there are a lot of aliases. I
>    put most of them in a single chunk.

For a first approximation that is OK, but I don't believe that the chunk 
names should agree with the names of the functions. If literate 
programming is done in that way, it doesn't add any value.

Not only the documentation around the function should describe the idea 
behind the code also the chunk names should should tell what the code is 
used for. So you would have

<<compute a Groebner basis>>=
<<initialize basis and critical pairs>>
while not empty criticalPairs repeat {
     <<take a critical pair>>
     <<compute the S-polynomial>>
     h := <<reduce the S-polynomial with respect to current basis>>
     if not zero? h then {
         <<update basis and critical pairs>>
     }
}
@

That's the essence of the GB-algorithm. And literate programs should 
convey this essence.

I admid that for LISP it's proably harder to put it into that style, but 
I guess, we are all learning what exactly LP is while we make 
experiences with real code.

> 2) I added/removed blank lines and comments. The latter only if they
>    appeared to be useless. Otherwise I just kept them.
> 
> 3) I *did not* change the capitalization/formatting of code. At least
>    not intentionally.
> 
> 4) I *did* change the order of function definitions. This was
>    necessary since I put several functions within a single chunk.
> 
> 5) I *did not* delete any code that wasn't commented out.

[snip]

> 8) I built Axiom using the new version. The build didn't finish, but
>    it failed in the same spot as with the old one (algebra: compiling
>    ahyp.spad). Cliff (CY) apparently succeeded building Axiom with the
>    new file.

[snip]

I think since you are not deleting or modifying code, you should just 
check, whether the notangled .lisp file is identical to the one from the 
monolithic chunk. It should be no problem to achive this. Then you are 
sure that the compilation will run through.

Good luck for all your work to come. Axiom will benefit from it.
Acually we need more people like Kai.

\start
Date: Thu, 21 Sep 2006 16:09:23 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: re: Google Code repository

On Thursday, September 21, 2006 2:51 PM you wrote:
> 
> > [page@axiom-developer page]$ svk
> > Can't locate Class/Autouse.pm in @INC (@INC contains:
> > ...
> > Perhaps you or someone else who is more familiar with the advanced
> > use of Perl than I am could suggest where to go from here?
>
> The Class::Autouse module is missing. See
> http://search.cpan.org/~adamk/Class-Autouse-1.27/
> If there is no package for your distribution (it is named
> libclass-autouse-perl in Debian), you can build, test and
> install the module with:
>   perl Makefile.pl
>   make
>   make test
>   make install
>

Thanks for your help.

This CPAN stuff is pretty scary! :-) I must have just downloaded
and installed several hundred new Perl packages in the list 5
minutes!

I logged in as root and did

  # cpan
  cpan> install Class::Autouse
  cpan> exit

I seemed to install ok. It told me I should upgrade my cpan
installation by 'install Bundle::CPAN' and then reload, which
I did apparently successfully

Then I went to svk and now it gaves me a different error:

[page@axiom-developer page]$ svk
Use of uninitialized value in pattern match (m//) at
/usr/lib/perl5/site_perl/5.8.0/Class/Autouse.pm line 531.
Can't locate File/Type.pm in @INC (@INC contains:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi, /usr/lib/perl5/5.8.0,
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi,
/usr/lib/perl5/site_perl/5.8.0, /usr/lib/perl5/site_perl,
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi,
/usr/lib/perl5/vendor_perl/5.8.0, /usr/lib/perl5/vendor_perl,
/usr/lib/perl5/5.8.0/i386-linux-thread-multi, /usr/lib/perl5/5.8.0, .)
at /usr/lib/perl5/site_perl/5.8.0/SVK/Util.pm line 36
BEGIN failed--compilation aborted at
/usr/lib/perl5/site_perl/5.8.0/SVK/Util.pm line 36.
Compilation failed in require at
/usr/lib/perl5/site_perl/5.8.0/SVK/Command.pm line 7.
BEGIN failed--compilation aborted at
/usr/lib/perl5/site_perl/5.8.0/SVK/Command.pm line 7.
Compilation failed in require at
/usr/lib/perl5/site_perl/5.8.0/Class/Autouse.pm line 406.
[page@axiom-developer page]$

--------

I tried

  cpan> install File::Type

but I get 3 errors during the install:

PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00setup....ok
t/01type.....Malformed UTF-8 character (unexpected non-continuation byte
0x0c, immediately after start byte 0xeb) in pattern match (m//) at
lib/File/Type.pm line 102.
Malformed UTF-8 character (unexpected non-continuation byte 0x0c,
immediately after start byte 0xeb) in pattern match (m//) at
lib/File/Type.pm line 108.
...
Malformed UTF-8 character (unexpected continuation byte 0x80, with no
preceding start byte) in pattern match (m//) at lib/File/Type.pm line
1344.
#     Failed test (t/01type.t at line 57)
#          got: 'application/octet-stream'
#     expected: 'audio/x-wav'
Malformed UTF-8 character (unexpected end of string) at lib/File/Type.pm
line 67.
...
Malformed UTF-8 character (byte 0xff) in pattern match (m//) at
lib/File/Type.pm line 1483.
#     Failed test (t/01type.t at line 57)
#          got: 'application/octet-stream'
#     expected: 'image/jpeg'
Malformed UTF-8 character (unexpected non-continuation byte 0xd0, 1 byte
after start byte 0xf3, expected 4 bytes) in pattern match (m//) at
lib/File/Type.pm line 120.
Malformed UTF-8 character (unexpected non-continuation byte 0xe5,
immediately after start byte 0xc4) in pattern match (m//) at
lib/File/Type.pm line 315.
...
Malformed UTF-8 character (unexpected continuation byte 0x8b, with no
preceding start byte) in pattern match (m//) at lib/File/Type.pm line
1479.
#     Failed test (t/02mime.t at line 61)
#          got: 'application/octet-stream'
#     expected: 'application/x-gzip'
# Looks like you failed 3 tests of 18.
dubious
        Test returned status 3 (wstat 768, 0x300)
DIED. FAILED tests 3, 14, 18
        Failed 3/18 tests, 83.33% okay
Failed 2/3 test scripts, 33.33% okay. 8/58 subtests failed, 86.21% okay.
Failed Test Stat Wstat Total Fail  Failed  List of Failed
------------------------------------------------------------------------
-------
t/01type.t     5  1280    36    5  13.89%  6 14 26 28 36
t/02mime.t     3   768    18    3  16.67%  3 14 18
make: *** [test_dynamic] Error 2
  /usr/bin/make test -- NOT OK
Running make install
  make test had returned bad status, won't install without force
[root@axiom-developer page]#
----------

So, any ideas how to fix this one?

\start
Date: Thu, 21 Sep 2006 22:31:08 +0200
From: Kai Kaminski
To: Gregory Vanuxem
Subject: Re: Literated VMLISP.LISP.PAMPHLET

>> -----Message d'origine-----
>> De : axiom-developer-bounces+g.vanuxem=wanadoo.fr@nongnu.org
>> part de Kai Kaminski
>> Envoye : jeudi 21 septembre 2006 17:51
>> A : list
>> Objet : Literated VMLISP.LISP.PAMPHLET
>> 
>> 
>> Hi,
>> 
>> I've 'literated' VMLISP.LISP.PAMPHLET (the result is attached), which
>> contains compatibility/utility code. 
>
> Awesome! I quickly read your file and you have used
> \subsection{The arc cotangent function} for cot and asec too :-)
Thanks for pointing that out, but it's not my fault. Those section
headings were there before. I only changed them from \section to
\subsection. It's fixed now.

\start
Date: Thu, 21 Sep 2006 22:41:19 +0200
From: Kai Kaminski
To: Ralf Hemmecke
Subject: Re: Literated VMLISP.LISP.PAMPHLET

Ralf Hemmecke writes:

> On 09/21/2006 05:51 PM, Kai Kaminski wrote:
>> Hi,
>>
>> I've 'literated' VMLISP.LISP.PAMPHLET (the result is attached), which
>> contains compatibility/utility code. In particular, I did the
>> following:
>>
>> 1) I gave most functions their own chunk. Sometimes I put several
>>    functions in a single chunk, mostly because they didn't need
>>    individual documentation. For example there are a lot of aliases. I
>>    put most of them in a single chunk.
>
> For a first approximation that is OK, but I don't believe that the
> chunk names should agree with the names of the functions. If literate
> programming is done in that way, it doesn't add any value.
Most of the functions in VMLISP.LISP.PAMPHLET are really short and
it's hard to see how they could benefit from splitting them up
further. Sometimes functions don't really need individual
documentation, eg. aliases, and it makes sense to stick them
together.

There are a few fairly long and complicated functions, and those
should probably be split up into multiple chunks. Unfortunately, I
have no idea what they do. They are not documented at all and they are
written in a peculiar style.

> Not only the documentation around the function should describe the
> idea behind the code also the chunk names should should tell what the
> code is used for. So you would have
>
> <<compute a Groebner basis>>=
> <<initialize basis and critical pairs>>
> while not empty criticalPairs repeat {
>     <<take a critical pair>>
>     <<compute the S-polynomial>>
>     h := <<reduce the S-polynomial with respect to current basis>>
>     if not zero? h then {
>         <<update basis and critical pairs>>
>     }
> }
> @
>
> That's the essence of the GB-algorithm. And literate programs should
> convey this essence.
Sure. If only I knew what the code does.

> I admid that for LISP it's proably harder to put it into that style,
> but I guess, we are all learning what exactly LP is while we make
> experiences with real code.
Actually there is a Lisp specific problem here. Often Lisp code
doesn't rely as much on side effects. Also every Lisp statement is an
expression with a value, which is used a lot. Finally people tend to
use lots of small functions. What is the difference between

(defun bar (...)
  (blah blub))

(defun foo (...)
  (let ((...))
    (bar ...)))

and

<<foo>>=
(defun foo (...)
  (let ((...))
    <<do-bar>>))
@

<<do-bar>>=
(blah blub)
@
  
>> 4) I *did* change the order of function definitions. This was
>>    necessary since I put several functions within a single chunk.
>>
>> 8) I built Axiom using the new version. The build didn't finish, but
>>    it failed in the same spot as with the old one (algebra: compiling
>>    ahyp.spad). Cliff (CY) apparently succeeded building Axiom with the
>>    new file.
>
> I think since you are not deleting or modifying code, you should just
> check, whether the notangled .lisp file is identical to the one from
> the monolithic chunk. It should be no problem to achive this. Then you
> are sure that the compilation will run through.
I couldn't, since I reordered code. There's not really a good way
around that, I believe.

\start
Date: Thu, 21 Sep 2006 16:45:14 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Google Code repository
Cc: Gabriel Dos Reis

On Thursday, September 21, 2006 3:36 PM you wrote:
>
> I have committed the build-improvements branch to the trunk
> of the Google Repository: http://axiom.googlecode.com/svn/trunk/
>

Great!

Thanks for doing this. I don't mean to be picky, but I wonder if there
is some way we could just populate /branches and leave /trunk empty?
By calling build-improvements /trunk I am afraid we might cause some
confusion. On the other hand, if Goggle gives us enough space it
would be good to have both /trunk and our current favorite /branch.

> One can checkout the source by doing:
> svn checkout http://axiom.googlecode.com/svn/trunk/ axiom
>
> Can you please add something in the page:
> explaining like you did in your comment above that this repository is
> an experimental version.
>

How's this? http://code.google.com/p/axiom

\start
Date: Thu, 21 Sep 2006 14:33:21 -0700
From: Alfredo Portes
To: Bill Page
Subject: Re: Google Code repository
Cc: Gabriel Dos Reis

Bill,

> Thanks for doing this. I don't mean to be picky, but I wonder if there
> is some way we could just populate /branches and leave /trunk empty?
> By calling build-improvements /trunk I am afraid we might cause some
> confusion. On the other hand, if Goggle gives us enough space it
> would be good to have both /trunk and our current favorite /branch.

One thing about this, is that we cannot edit the page:

http://code.google.com/p/axiom/source

which tells the users how to checkout the source, and it says to do it from the
trunk. I guess if we assume that people will be curious enough, they will look
into the branches, but I am not sure this will be always the case.

With the space we have now, one thing we can do is have Silver in the trunk and
build-improvements in a branch and go from there if Google increases the size.
Do you think that is ok?

>
> How's this? http://code.google.com/p/axiom
>

Thank you, it looks very good.

\start
Date: Thu, 21 Sep 2006 17:33:54 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Google Code repository
Cc: Gabriel Dos Reis

> Alfredo,

On Thursday, September 21, 2006 3:36 PM you wrote:
>
> I have committed the build-improvements branch to the trunk
> of the Google Repository: http://axiom.googlecode.com/svn/trunk/
>

When I try this anonymous checkout I get:

$ svn checkout http://axiom.googlecode.com/svn/trunk/ axiom

it fails immediately with:

  svn: PROPFIND request failed on '/svn/trunk'
  svn: PROPFIND of '/svn/trunk': Could not read status line:
  An existing connection was forcibly closed by the remote host.
    (http://axiom.googlecode.com)

----------

It seems like subversion just does like me. :-(

A self checkout (with password):

$ svn checkout https://axiom.googlecode.com/svn/trunk/ axiom
    --username synthesis.anikast.ca

but it justed failed a long way through the transfer with the
message:

...
A    axiom.build-improvements\src\hyper\pages\GBF.ht
A    axiom.build-improvements\src\hyper\pages\HTXFormatPage5.ht
svn: In directory 'axiom.build-improvements\src\hyper\pages'
svn: Can't copy
'axiom.build-improvements\src\hyper\pages\.svn\tmp\text-base\pol
y.pht.svn-base' to
'axiom.build-improvements\src\hyper\pages\.svn\tmp\poly.pht.t
mp.tmp': The system cannot find the file specified.

-------

So it's true. Subversion does like me...

BTW, what release of the SourceForge repository is this?
I notice that

 A    axiom.build-improvements\zips\tla-1.1.tar.gz

is still in this archive, but I am quite sure Gaby deleted it last
night. Which raises the question of how to keep this version up to
date with the SourceForge version.

I have been working with a program called 'tailor' on
axiom-developer.org

http://www.darcs.net/DarcsWiki/Tailor

http://fiatdev.com/articles/2006/09/10/mirroring-subversion-with-darcs-a
nd-tailor

This program can transfer as both source and as target systems
to and from: Darcs Subversion Monotone CVS Bazaar-NG Mercurial
and Git (Cogito) and also from Bazaar (Arch 1.x) and Tla (Arch)
source system only.

It seems to work nicely and automatically to create a new archives
and to keep to keep them up to date by automatically running
periodically.

So far I have mirrored the build-improvements branch successfully
with both Mercurial and Darcs. If you are interested ing trying
Mercurial here is the url:

http://mercurial.axiom-developer.org

For more information about Mercurial see

http://www.selenic.com/mercurial

It seems to be just as "fast and easy" as advertised and I can
use it successfully on both Linux and Windows. Installation
was a piece-of-cake (here that subversion developers! ;)

\start
Date: Thu, 21 Sep 2006 18:02:24 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Google Code repository
Cc: Gabriel Dos Reis

> When I try this anonymous checkout I get:
>
> $ svn checkout http://axiom.googlecode.com/svn/trunk/ axiom
>
> it fails immediately with:
>
>   svn: PROPFIND request failed on '/svn/trunk'
>   svn: PROPFIND of '/svn/trunk': Could not read status line:
>   An existing connection was forcibly closed by the remote host.
>     (http://axiom.googlecode.com)
>
> ----------
>
> It seems like subversion just does like me. :-(
>

I repeat it the checkout and it works here. :( . I do not know what is
going on. That was in your windows or linux box?

>
> So it's true. Subversion does like me...
>
> BTW, what release of the SourceForge repository is this?
> I notice that
>
>  A    axiom.build-improvements\zips\tla-1.1.tar.gz
>
> is still in this archive, but I am quite sure Gaby deleted it last
> night. Which raises the question of how to keep this version up to
> date with the SourceForge version.
>

I am at revision 151.

\start
Date: Thu, 21 Sep 2006 18:37:01 -0400
From: Bill Page
To: Alfredo Portes, Bill Page
Subject: RE: Google Code repository
Cc: Gabriel Dos Reis

On Thursday, September 21, 2006 6:02 PM you asked:
>
> > When I try this anonymous checkout:
> >
> > $ svn checkout http://axiom.googlecode.com/svn/trunk/ axiom
> >
> > it fails immediately with:
> >
> >   svn: PROPFIND request failed on '/svn/trunk'
> >   svn: PROPFIND of '/svn/trunk': Could not read status line:
> >   An existing connection was forcibly closed by the remote host.
> >     (http://axiom.googlecode.com)
> >
> > ----------
> >
> > It seems like subversion just does like me. :-(
> >
>
> I repeat it the checkout and it works here. :( . I do not know
> what is going on. That was in your windows or linux box?

This failure occured on subversion 1.4 on Windows - but I am
behind a strict firewall and proxy. It is possible that webdav
is not fully supported here. I will try later with a linux boxen.

While pulling my hair out about subversion last night, I did
management to find out something very useful, I think.

It is possible to use rsync to make a direct backup of our
subversion archive at SourceForge using the following commands:

  $ export RSYNC_PROXY=rsync-svn.sourceforge.net:80
  $ mkdir -p ~/repo/axiom/branches
  $ rsync -v -a rsync-svn-a::svn/axiom/* ~/repo/axiom/branches

See:

http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1#=
bac
kup

Then you can checkout a copy of the souces directly from this
local mirror!

  $ cd ~
  $ pwd
  /home/page
  $ svn info file:///home/page/repo/axiom/branches
  $ svn co file:///home/page/repo/axiom/branches build.improvements

It's fast! because rsync uses a very efficient network protocol
and file:// access is just local.

Please give it a try and let me know if it works for you.

\start
Date: Fri, 22 Sep 2006 01:05:18 +0200
From: Gregory Vanuxem
To: Bill Page, Gregory Vanuxem
Subject: re: Google Code repository

> -----Message d'origine-----

[...]

> This CPAN stuff is pretty scary! :-) I must have just downloaded
> and installed several hundred new Perl packages in the list 5
> minutes!

Yes, if there is a lot of prerequities my method is tedious.

[...]

> PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"
> "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
> t/00setup....ok
> t/01type.....Malformed UTF-8 character (unexpected non-continuation byte
> 0x0c, immediately after start byte 0xeb) in pattern match (m//) at
> lib/File/Type.pm line 102.
> Malformed UTF-8 character (unexpected non-continuation byte 0x0c,
> immediately after start byte 0xeb) in pattern match (m//) at
> lib/File/Type.pm line 108.
> ...
> Malformed UTF-8 character (unexpected continuation byte 0x80, with no
> preceding start byte) in pattern match (m//) at lib/File/Type.pm line
> 1344.
> #     Failed test (t/01type.t at line 57)
> #          got: 'application/octet-stream'
> #     expected: 'audio/x-wav'
> Malformed UTF-8 character (unexpected end of string) at lib/File/Type.pm
> line 67.
> ...
> Malformed UTF-8 character (byte 0xff) in pattern match (m//) at
> lib/File/Type.pm line 1483.
> #     Failed test (t/01type.t at line 57)
> #          got: 'application/octet-stream'
> #     expected: 'image/jpeg'
> Malformed UTF-8 character (unexpected non-continuation byte 0xd0, 1 byte
> after start byte 0xf3, expected 4 bytes) in pattern match (m//) at
> lib/File/Type.pm line 120.
> Malformed UTF-8 character (unexpected non-continuation byte 0xe5,
> immediately after start byte 0xc4) in pattern match (m//) at
> lib/File/Type.pm line 315.
> ...
> Malformed UTF-8 character (unexpected continuation byte 0x8b, with no
> preceding start byte) in pattern match (m//) at lib/File/Type.pm line
> 1479.
> #     Failed test (t/02mime.t at line 61)
> #          got: 'application/octet-stream'
> #     expected: 'application/x-gzip'
> # Looks like you failed 3 tests of 18.
> dubious

You are not alone with this problem, and it is not a bug, I believe, in this
module.
Search with Google "Malformed UTF-8 character (unexpected non-continuation
byte".
Some persons change the read/write mode of the filehandle to the binary one
(with binmode), some others prepend a LANG=C to the command line.
Or maybe modifying the open call with a "<:byte" or a "<:utf8" could help
(see perldoc PerlIO). But this requires to modify this module,
it's not a good solution. Is there some Perl gurus here?

\start
Date: Fri, 22 Sep 2006 01:31:51 +0200
From: Ralf Hemmecke
To: Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET

>> I think since you are not deleting or modifying code, you should just
>> check, whether the notangled .lisp file is identical to the one from
>> the monolithic chunk. It should be no problem to achive this. Then you
>> are sure that the compilation will run through.

> I couldn't, since I reordered code. There's not really a good way
> around that, I believe.

What do you mean you "reordered code"?

If it was

%FILE 1
<<*>>=
blih
blah
bluh
@
%END FILE1

and then you have

%FILE2
<<chunk bluh>>=
bluh
@

<<chunk blih>>=
blih
@

<<*>>=
<<chunk blih>>
<<chunk blah>>
<<chunk bluh>>
@

<<chunk blah>>
blah
@
%END FILE2

notangle FILE1 > file1
notangle FILE2 > file2
cmp file1 file2

should show that the two files are equal.

So what is "reorder"?

\start
Date: Thu, 21 Sep 2006 19:51:38 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: re: Google Code repository

Greg,

On Thursday, September 21, 2006 7:05 PM you wrote:
> ...
> > This CPAN stuff is pretty scary! :-) I must have just downloaded
> > and installed several hundred new Perl packages in the list 5
> > minutes!
>
> Yes, if there is a lot of prerequities my method is tedious.
>

Well

  $ cpan
  cpan> install ...

is great when everything works (almost as good as apt-get! :)

> ...
> You are not alone with this problem, and it is not a bug,
> I believe, in this module. Search with Google
> "Malformed UTF-8 character (unexpected non-continuation byte".
> Some persons change the read/write mode of the filehandle to
> the binary one (with binmode), some others prepend a LANG=C
> to the command line. Or maybe modifying the open call with a
> "<:byte" or a "<:utf8" could help (see perldoc PerlIO). But
> this requires to modify this module, it's not a good solution.

I just did:

  $ LANG=C perl -MCPAN -e 'install File::Type'

and the install worked fine.

Thank you, thank you, thank you!

Now I finally have a working

  $ svk version
  This is svk, version 1.08.

> Is there some Perl gurus here?

I think you are well qualified for that job. :-)

\start
Date: Fri, 22 Sep 2006 02:26:04 +0200
From: Gregory Vanuxem
To: Bill Page, Gregory Vanuxem
Subject: re: Google Code repository

> -----Message d'origine-----

[...] 
 
> I just did:
> 
>   $ LANG=C perl -MCPAN -e 'install File::Type'
> 
> and the install worked fine.

But the execution... 
A "LANG=C svk ..." will be necessary I think.

\start
Date: Thu, 21 Sep 2006 20:49:08 -0400
From: Bill Page
To: Bill Page
Subject: patches to daase.lisp.pamphlet and Axiom for Windows on GCL-2.6.8pre
Cc: Camm Maguire

On Wednesday, September 20, 2006 6:59 AM I wrote:

> ...
> Some good news. With the patches supplied by Camm in:
>
>
http://lists.nongnu.org/archive/html/axiom-developer/2006-08/msg00344.ht
ml
>
> and removing the out-of-date patches which have since been
> incorporated into gcl, the darcs axiom--windows--1 source code
> seems to be compiling using the new gcl-2.6.8pre. I now expect
> it to complete successfully (I will confirm in a couple of hours).
>
> This means that at least we will be able to work with the same
> version of gcl in both Linux and Windows once Camm officially
> releases 2.6.8. The Windows version of Axiom was last successfully
> compiled only with a patched version of gcl-2.6.5.
>

Well it wasn't quite that easy, but I did finally get a successful
Windows build of Axiom using gcl-2.6.8pre (as patched for the
previously mentioned lstat problem) but it turned out I needed
a few more patches.

The most serious and difficult problem occurred in Axiom's database
code. There is some incorrect usage of the lisp 'probe-file'
function that no longer corresponds the way 'probe-file' works
in gcl (since gcl-2.6.7). This is actually a bug in the current
Axiom linux source distribution as well! This might explain the
problems that we had recently with trying to compile Martin's
Rubey's new 'guess' package since it means that generating the
new databases might fail.


Patch procedure
---------------

The following is an annotated output from

  $ darcs --diff -u

------

Binary files old-axiom--windows--1-1/zips/gcl-2.6.5.tgz and
new-axiom--windows--1-1/zips/gcl-2.6.5.tgz differ

Because I was too lazy to take the time to properly modify the
Makefile.pamphlet for the new gcl-2.6.8pre build, the first
thing I did was prepare a tarball for gcl2.6.8pre using the
name gcl-2.6.5w

  $ tar xzvf gcl-2.6.8pre.tgz
  $ mv gcl-2.6.8pre gcl-2.6.5w
  $ tar czvf gcl-2.6.5w.tgz gcl-2.6.5w

so that I could just start with the existing Windows sources.

--------

The following patch removes those patches to gcl that no
longer apply

diff -rN -u old-axiom--windows--1-1/lsp/Makefile.pamphlet
new-axiom--windows--1-1/lsp/Makefile.pamphlet
--- old-axiom--windows--1-1/lsp/Makefile.pamphlet	Wed Sep 20
21:32:37 2006
+++ new-axiom--windows--1-1/lsp/Makefile.pamphlet	Wed Sep 20
21:32:54 2006
@@ -766,15 +766,9 @@
 	@mv gcl-2.6.5 ${GCLVERSION}
 <<gcl-2.6.5w.socket.patch>>
 <<gcl-2.6.5w.libspad.patch>>
-<<gcl-2.6.5w.toploop.patch>>
-<<gcl-2.6.5w.h.gmp_wrappers.h.patch>>
-<<gcl-2.6.5w.gcl_cmpmain.lsp.patch>>
 <<gcl-2.6.5w.tail-recursive.patch>>
 <<gcl-2.6.5w.collectfn.fix>>
 <<gcl-2.6.5w.h.mingw.defs.patch>>
-<<gcl-2.6.5w.o.alloc.c.patch>>
-<<gcl-2.6.5w.o.mingfile.c.patch>>
-<<gcl-2.6.5w.o.unixfsys.c.patch>>
 <<gclConfigureMake>>
 	@echo 112 finished system build on `date` | tee >gcldir

------

This is one of Camm's patches.

diff -rN -u old-axiom--windows--1-1/src/interp/cfuns.lisp.pamphlet
new-axiom--windows--1-1/src/interp/cfuns.lisp.pamphlet
--- old-axiom--windows--1-1/src/interp/cfuns.lisp.pamphlet	Wed Sep
20 21:32:48 2006
+++ new-axiom--windows--1-1/src/interp/cfuns.lisp.pamphlet	Wed Sep
20 21:33:06 2006
@@ -114,10 +114,10 @@

 #+(AND KCL (NOT ELF))
 (Clines
-"unsigned int MYCOMBINE(i,j)"
-"unsigned int i,j;"
+"int MYCOMBINE(i,j)"
+"int i,j;"
 "{"
-"return ( (((j & 16777215) << 6)+i) % 1073741789);"
+"return ( (((((unsigned int)j) & 16777215) << 6)+((unsigned int)i)) %
1073741789);"
 "}"
 )
 #+(AND KCL (NOT ELF))

------

This patch corrects some incorrect usage of 'probe-file' in the
Axiom database code. !! Very important !!

diff -rN -u old-axiom--windows--1-1/src/interp/daase.lisp.pamphlet
new-axiom--windows--1-1/src/interp/daase.lisp.pamphlet
--- old-axiom--windows--1-1/src/interp/daase.lisp.pamphlet	Wed Sep
20 21:32:48 2006
+++ new-axiom--windows--1-1/src/interp/daase.lisp.pamphlet	Wed Sep
20 21:33:06 2006
@@ -840,7 +840,7 @@
  (let (thisdir nrlibs asos asys libs object only dir key
       (|$forceDatabaseUpdate| t) noexpose)
   (declare (special |$forceDatabaseUpdate|))
-  (setq thisdir (namestring (probe-file ".")))
+  (setq thisdir (namestring (truename ".")))
   (setq noexpose nil)
   (multiple-value-setq (only dir noexpose) (processOptions options))
      ;don't force exposure during database build
@@ -1106,12 +1106,12 @@
   (setq *compressvector* nil)
   (withSpecialConstructors)
   (localdatabase nil
-     (list (list '|dir| (namestring (probe-file "./")) ))
+     (list (list '|dir| (namestring (truename "./")) ))
      'make-database)
   (dolist (dir dirlist)
 	  (localdatabase nil
 			 (list (list '|dir|
-				     (namestring (probe-file
+				     (namestring (truename
 						  (format nil "./~a"
 							  dir)))))
 			 'make-database))

-------

Here are 2 more of Camm's patches.

diff -rN -u old-axiom--windows--1-1/src/interp/hash.lisp.pamphlet
new-axiom--windows--1-1/src/interp/hash.lisp.pamphlet
--- old-axiom--windows--1-1/src/interp/hash.lisp.pamphlet	Wed Sep
20 21:32:48 2006
+++ new-axiom--windows--1-1/src/interp/hash.lisp.pamphlet	Wed Sep
20 21:33:07 2006
@@ -81,7 +81,7 @@
 (define-function 'HASHTABLE-CLASS #'system::hash-table-test)

 #+AKCL
-(clines "static int mem_value(x ,i)object x;int i; { return ((short
*)x)[i];}")
+(clines "int mem_value(x ,i)object x;int i; { return ((short
*)x)[i];}")
 #+AKCL
 (defentry memory-value-short(object int) (int "mem_value"))

diff -rN -u old-axiom--windows--1-1/src/interp/sockio.lisp.pamphlet
new-axiom--windows--1-1/src/interp/sockio.lisp.pamphlet
--- old-axiom--windows--1-1/src/interp/sockio.lisp.pamphlet	Wed Sep
20 21:32:49 2006
+++ new-axiom--windows--1-1/src/interp/sockio.lisp.pamphlet	Wed Sep
20 21:33:08 2006
@@ -78,7 +78,7 @@
   (defentry sock_send_int (int int) (int "sock_send_int"))
   (defentry sock_get_string_buf (int string int) (int
"sock_get_string_buf"))
   (defentry sock_send_string_len (int string int) (int
"sock_send_string_len"))
-  (defentry sock_get_float (int) (float "sock_get_float"))
+  (defentry sock_get_float (int) (double "sock_get_float"))
   (defentry sock_send_float (int float) (int "sock_send_float"))
   (defentry sock_send_wakeup (int int) (int "sock_send_wakeup"))
   (defentry server_switch () (int "server_switch"))

-------

This patch corrects an error in the 'document' script which
fails when the path to 'latex' contains a directory name with
a space.

diff -rN -u old-axiom--windows--1-1/src/scripts/document
new-axiom--windows--1-1/src/scripts/document
--- old-axiom--windows--1-1/src/scripts/document	Wed Sep 20
21:32:49 2006
+++ new-axiom--windows--1-1/src/scripts/document	Wed Sep 20
21:33:08 2006
@@ -1,5 +1,5 @@
 #!/bin/sh
-latex=`which latex`
+latex=latex
 if [ "$latex" = "" ] ; then
   echo document ERROR You must install latex first
   exit 0

-------

The following chunk of the unixport.makefile.patch no longer
applies to gcl-2.6.8pre

diff -rN -u
old-axiom--windows--1-1/zips/gcl-2.6.5w.unixport.makefile.patch
new-axiom--windows--1-1/zips/gcl-2.6.5w.unixport.makefile.patch
--- old-axiom--windows--1-1/zips/gcl-2.6.5w.unixport.makefile.patch
Wed Sep 20 21:32:52 2006
+++ new-axiom--windows--1-1/zips/gcl-2.6.5w.unixport.makefile.patch
Wed Sep 20 21:33:10 2006
@@ -10,12 +10,3 @@
 
  ifeq ($(ARRS),)
  ARRS:=ar rs
-@@ -28,7 +29,7 @@
- 	rm -rf gmp
- 	mkdir gmp
- 	a="$^" ; \
--	for i in $^ ; do \
-+	for i in $$a ; do \
- 		cp $$i gmp/$$(echo $$i | sed -e 's,\.\./,,1' -e
's,/,_,g') ; \
- 	done
- 	touch $@

--------

There, that's all there is too it. :-) Now you can build Axiom
on Windows with the newest prerelease version of GCL.

\start
Date: Fri, 22 Sep 2006 03:01:37 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: patches to daase.lisp.pamphlet and Axiom forWindows on GCL-2.6.8pre
Cc: Camm Maguire

> -----Message d'origine-----

[...]
 
> 
> There, that's all there is too it. :-) Now you can build Axiom
> on Windows with the newest prerelease version of GCL.

Just curious, can you reproduce the following issues:

http://wiki.axiom-developer.org/233TraceInFloatCausedFatalError

and

http://wiki.axiom-developer.org/194TracingComplexOnWindows

\start
Date: Thu, 21 Sep 2006 22:36:17 -0400
From: Bill Page
To: Gregory Vanuxem, Bill Page
Subject: re: Google Code repository

On Thursday, September 21, 2006 8:26 PM you wrote:
>...
> Bill Page wrote:
> > I just did:
> >
> >   $ LANG=C perl -MCPAN -e 'install File::Type'
> >
> > and the install worked fine.
>
> But the execution...
> A "LANG=C svk ..." will be necessary I think.
>

No, that is not necessary when running svk - only when doing
that particular install. SVK is working now, but before I
could complete all of the steps in Gaby's recipe at:

http://wiki.axiom-developer.org/AxiomSilverBranch

svk was interrupted by Perl exceptions and I had to satisfy
at least 6 more dependencies via cpan. I have just completed
the final checkout from the mirror and everything looks ok.

This svk thing is a real rats nest of Perl dependencies. I
don't understand why these dependencies were not automatically
satisfied during the svk installation procedure. But maybe
because I had so much trouble with installing svn in the
proper way so that svk could talk to it, I somehow managed
to munge that part of the svk install. But if this is the
normal install experience for svk, I certainly wouldn't
recommend it for the inexp=E9riment=E9e.

Anyway, all's well that ends well... Well almost. It turns out
that during the 'svk sync /mirror/axiom' the download from
SourceForge failed about at least 6 times and had to be
manually restarted. That did not happen to be before while
working on the axiom-developer.org server. But at least it
restarted properly without irrecoverably locking any files
or anything.

End result: I still have serious doubts about svn and svk.
:(

\start
Date: Fri, 22 Sep 2006 10:18:39 +0200
From: Kai Kaminski
To: Ralf Hemmecke
Subject: Re: Literated VMLISP.LISP.PAMPHLET

Ralf Hemmecke writes:

>>> I think since you are not deleting or modifying code, you should just
>>> check, whether the notangled .lisp file is identical to the one from
>>> the monolithic chunk. It should be no problem to achive this. Then you
>>> are sure that the compilation will run through.
>
>> I couldn't, since I reordered code. There's not really a good way
>> around that, I believe.
>
> What do you mean you "reordered code"?
I changed the order of function/macro definitions. I changed your
examble a bit to match what actually happened.

%FILE 1
<<*>>=
BLIH  (Should end up in a single chunk with BLUH)
BLOH
BLAH  (Should be in its own chunk)
BLUH  (depends on BLAH, ie has to come after blah in the file)
@
%END FILE1

Now try to chunk this up given those constraints without changing the
order of code.

Besides I deleted many blank lines and obsolete comments. I could've
kept them, but I reckon the cruft should go. Furthermore I'm planning
to be more invasive next time around. I'll eliminate aliases, obsolete
functions etc.

> cmp file1 file2
>
> should show that the two files are equal.
That's what I was planning to do, but it didn't work.

\start
Date: Fri, 22 Sep 2006 11:26:53 +0200
From: Ralf Hemmecke
To: Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET

> %FILE 1
> <<*>>=
> BLIH  (Should end up in a single chunk with BLUH)
> BLOH
> BLAH  (Should be in its own chunk)
> BLUH  (depends on BLAH, ie has to come after blah in the file)
> @
> %END FILE1
> 
> Now try to chunk this up given those constraints without changing the
> order of code.

So I don't know how reasonable that would be. Your are certainly better 
off doing it your way. But for your question....

%FILE 2
<<BLIUH>>=
BLIH
<<BLOH>>
<<BLAH>>
BLUH
@
I guess, you don't want the above chunk, because it contains too much, 
right?

<<BLOH>>=
BLOH
@

<<BLAH>>=
BLAH
@

<<*>>=
<<BLIUH>>
@
%END FILE 2

I guess, you are right. Do it your way and restructure so that the 
essence becomes clear. That is much more important then having identical 
  .lisp files. Identical up to permutation of functions is enough for 
lisp files.

\start
Date: Fri, 22 Sep 2006 09:02:28 -0400
From: Bill Page
To: Juan Rivas
Subject: re: Google Code repository

Welcome to the Axiom Developer list :-)

On September 22, 2006 7:25 AM Juan M. Bello Rivas wrote:
>
> Hi Bill,
>
> I was writing something about Tailor yesterday but then I realized
> you had just written an email to axiom-developer on that topic.
>
> I detailed the steps I took for replicating build-improvements into
> a local darcs repo at
>
>
http://blog.superadditive.com/2006/09/23/interoperability-between-source-=
cod
e-management-systems-with-tailor
>
> Perhaps it can be useful?

Yes, thank you very much. Your description is very useful.

I am quite impressed by how simple it is to use Tailor to move
complete repositories (including all history and revisions) from
one system to another. If we can't have just one common type of
source code respository, then at least we can interoperate.

E pluribus ...

\start
Date: Fri, 22 Sep 2006 16:34:57 +0200
From: Kai Kaminski
To: Ralf Hemmecke
Subject: Re: Literated VMLISP.LISP.PAMPHLET

Ralf Hemmecke writes:

>> %FILE 1
>> <<*>>=
>> BLIH  (Should end up in a single chunk with BLUH)
>> BLOH
>> BLAH  (Should be in its own chunk)
>> BLUH  (depends on BLAH, ie has to come after blah in the file)
>> @
>> %END FILE1
>>
>> Now try to chunk this up given those constraints without changing the
>> order of code.
>
> So I don't know how reasonable that would be. Your are certainly
> better off doing it your way. But for your question....
>
> %FILE 2
> <<BLIUH>>=
> BLIH
> <<BLOH>>
> <<BLAH>>
> BLUH
> @
> I guess, you don't want the above chunk, because it contains too much,
> right?
Not quite. This whole BL*H thing is thoroughly confusing. I'll just
give you the real code (kind of).

File1:

(defmacro alias-for-foo (...)
  [code generating code calling foo])

(defun bar (...)
  ...)

(defun define-function (alias function)
  (setf (symbol-function alias) function))

(define-function alias-for-bob #'bob)

End of File1

FOO and BOB are functions defined elsewhere. Now I wanted to put all
(most) aliases in a single chunk since they don't deserve individual
documentation. Hence the first and last forms above go into a single
chunk:

<<aliases>>=
(defmacro alias-for-foo (...)
  [code generating code calling foo])

(define-function alias-for-bob #'bob)
@

The (defun define-function ...) form has to go before that
chunk. Hence the order changes. I could have done what you suggest and
just referenced the (defun define-function ...) chunk in the aliases
chunk, but I didn't like that.

Of course, I also wanted to delete lots of whitespace and comments
anyway, so the whole point is moot.


Thanks for taking the time to discuss - admittedly boring - details.

\start
Date: Fri, 22 Sep 2006 17:14:36 +0200
From: Ralf Hemmecke
To: Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET

> Not quite. This whole BL*H thing is thoroughly confusing. I'll just
> give you the real code (kind of).
> 
> File1:
> 
> (defmacro alias-for-foo (...)
>   [code generating code calling foo])
> 
> (defun bar (...)
>   ...)
> 
> (defun define-function (alias function)
>   (setf (symbol-function alias) function))
> 
> (define-function alias-for-bob #'bob)
> 
> End of File1
> 
> FOO and BOB are functions defined elsewhere. Now I wanted to put all
> (most) aliases in a single chunk since they don't deserve individual
> documentation. Hence the first and last forms above go into a single
> chunk:
> 
> <<aliases>>=
> (defmacro alias-for-foo (...)
>   [code generating code calling foo])
> 
> (define-function alias-for-bob #'bob)
> @

Hmmm, I am not sure I can support that approach. For two reasons.

1) Most probably the aliases come in the documentation without links to 
the code they refer to. (Though that can be done.)

2) You separate code that belongs together. Don't you think?

Why would it make sense to list all the abbreviations on one section 
(even without documenation)?

> Thanks for taking the time to discuss - admittedly boring - details.

I don't think that it is "boring". I am sure that most of us have no 
real experience what the best LP style in Axiom would be. Otherwise I 
would have seen a "Conventions" page that explains how to write good 
literate programs. It's not totally clear, at least not for me.

But all our experiences must be collected some day on the wiki or 
another document to help newcomers with this LP style in Axiom. It's 
important.

\start
Date: Fri, 22 Sep 2006 18:18:49 +0200
From: Kai Kaminski
To: Ralf Hemmecke
Subject: Re: Literated VMLISP.LISP.PAMPHLET

>> Not quite. This whole BL*H thing is thoroughly confusing. I'll just
>> give you the real code (kind of).
>>
>> File1:
>>
>> (defmacro alias-for-foo (...)
>>   [code generating code calling foo])
>>
>> (defun bar (...)
>>   ...)
>>
>> (defun define-function (alias function)
>>   (setf (symbol-function alias) function))
>>
>> (define-function alias-for-bob #'bob)
>>
>> End of File1
>>
>> FOO and BOB are functions defined elsewhere. Now I wanted to put all
>> (most) aliases in a single chunk since they don't deserve individual
>> documentation. Hence the first and last forms above go into a single
>> chunk:
>>
>> <<aliases>>=
>> (defmacro alias-for-foo (...)
>>   [code generating code calling foo])
>>
>> (define-function alias-for-bob #'bob)
>> @
>
> Hmmm, I am not sure I can support that approach. For two reasons.
>
> 1) Most probably the aliases come in the documentation without links
> to the code they refer to. (Though that can be done.)
I'm not quite sure what exactly you're getting at.

> 2) You separate code that belongs together. Don't you think?
I suppose you mean that an alias definition should be next to the
definition of the function that it's an alias for? Like

<<foo>>=

(defun foo (...)
  ...)

(define-function alias-for-foo #'foo)
@

That's what I thought at first, but then it occured to me that

1) Aliases in general aren't terribly useful. The only exception I can
   think of is the following. Suppose you have an operation acting on
   objects of type FOO, say COMPARE-FOOS. Now it happens that the
   definition of that function is

     (defun compare-foos (&rest foos)
       (apply #'equal foos))

   In this case it is acceptable to create COMPARE-FOOS, because it
   captures a different concept. This is also useful if you later
   change the implementation of objects of type FOO, and you can't
   just compare them with EQUAL. In that case you simply change the
   implementation of COMPARE-FOOS. If you'd use EQUAL directly, you'd
   have to check each and every EQUAL in your source to figure out
   wether it has to be adapted to the new implementation of FOOs.

   Other than that I don't see any justification for aliases.

2) To be useful in the sense described above, an alias needs a good
   name. Almost all the aliases in VMLISP.LISP.PAMPHLET have terrible
   names. Here is a small sample:

     (defmacro absval (x)
       `(abs ,x))

     (defmacro intp (x)
       `(integerp ,x))

     (define-function 'U-CASE #'upcase)
     (define-function 'LC2UC #'upcase)
     (define-function 'L-CASE #'downcase)

     (define-function 'EVA1 #'eval) ;EVA1 and VMLISP EVAL make lexicals visible
     (define-function 'EVALFUN #'eval) ;EVALFUN drops lexicals before evaluating
     (define-function 'EVA1FUN #'EVALFUN)

     (define-function 'vm/ #'quotient)

   Note that apparently a single function can act differently
   depending on what it's called.

   I believe that all the aliases in the 'Aliases' section should be
   removed or at least renamed. I admit to being inconsistent, as
   there are many aliases that are not in that list, even though I
   often made a comment pointing out that they should be removed. One
   example is MAKE-VEC, which is defined as

     (defun make-vec (n)
       (make-array n))

   I'm not sure why this one got through. Another example is DSETQ,
   which is an alias for DODSETQ.

The 'Aliases' section contains only those aliases that I think should
be removed from Axiom. It so happens that almost all the aliases in
VMLISP.LISP.PAMPHLET qualify.

> Why would it make sense to list all the abbreviations on one section
> (even without documenation)?
Because they're all obsolete. That section is a list of things to
remove. Since that requires changing a lot of code (trivially), I
didn't do it (yet; I'm actually waiting for Tim's opinion on this,
before I go ahead and get rid of them). 

>> Thanks for taking the time to discuss - admittedly boring - details.
>
> I don't think that it is "boring". I am sure that most of us have no
> real experience what the best LP style in Axiom would be. Otherwise I
> would have seen a "Conventions" page that explains how to write good
> literate programs. It's not totally clear, at least not for me.
Not to me, either. When I read your first response to my VMLISP.LISP
conversion I actually thought about that. I was going to suggest that
you put up the example you gave (the Groebner basis fragment).

> But all our experiences must be collected some day on the wiki or
> another document to help newcomers with this LP style in Axiom. It's
> important.
It is. That doesn't really make discussing the intricate details of
chunking exciting, though. ;-)

\start
Date: Fri, 22 Sep 2006 18:41:53 +0200
From: Ralf Hemmecke
To: Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET

>> Hmmm, I am not sure I can support that approach. For two reasons.
>>
>> 1) Most probably the aliases come in the documentation without links
>> to the code they refer to. (Though that can be done.)
> I'm not quite sure what exactly you're getting at.

Have you, for example ever used

@ %def foo

at the end of a code chunk? noweave can generated hyperlinks inside the 
code pieces from that...

>> 2) You separate code that belongs together. Don't you think?
> I suppose you mean that an alias definition should be next to the
> definition of the function that it's an alias for? Like
> 
> <<foo>>=
> 
> (defun foo (...)
>   ...)
> 
> (define-function alias-for-foo #'foo)
> @
> 
> That's what I thought at first, but then it occured to me that
> 
> 1) Aliases in general aren't terribly useful. The only exception I can
>    think of is the following. Suppose you have an operation acting on
>    objects of type FOO, say COMPARE-FOOS. Now it happens that the
>    definition of that function is
> 
>      (defun compare-foos (&rest foos)
>        (apply #'equal foos))
> 
>    In this case it is acceptable to create COMPARE-FOOS, because it
>    captures a different concept. This is also useful if you later
>    change the implementation of objects of type FOO, and you can't
>    just compare them with EQUAL. In that case you simply change the
>    implementation of COMPARE-FOOS. If you'd use EQUAL directly, you'd
>    have to check each and every EQUAL in your source to figure out
>    wether it has to be adapted to the new implementation of FOOs.
> 
>    Other than that I don't see any justification for aliases.

I cannot say much about that. I am not a LISP programmer. :-(

[snip]

>> Why would it make sense to list all the abbreviations on one section
>> (even without documenation)?
> Because they're all obsolete. That section is a list of things to
> remove.

Hmmm, in that case, the section would not be forever. So I am with you.

>>> Thanks for taking the time to discuss - admittedly boring - details.
>> I don't think that it is "boring". I am sure that most of us have no
>> real experience what the best LP style in Axiom would be. Otherwise I
>> would have seen a "Conventions" page that explains how to write good
>> literate programs. It's not totally clear, at least not for me.
> Not to me, either. When I read your first response to my VMLISP.LISP
> conversion I actually thought about that. I was going to suggest that
> you put up the example you gave (the Groebner basis fragment).

All I can put onto the net is already there. My experience of 
programming in LP style is at the ALLPROSE website. I am sure that I am 
not perfect, but the whole thing is a bit bigger than just dhmatrix.

And I am currently doing something here...

svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk combinat
cd combinat/combinat
make colored dvi

in a similar style. But all that is not LISP, but you might get an idea 
how I think Axiom should look like.

\start
Date: Fri, 22 Sep 2006 18:48:46 +0200
From: Kai Kaminski
To: Ralf Hemmecke
Subject: Re: Literated VMLISP.LISP.PAMPHLET

Ralf Hemmecke writes:

>>> Hmmm, I am not sure I can support that approach. For two reasons.
>>>
>>> 1) Most probably the aliases come in the documentation without links
>>> to the code they refer to. (Though that can be done.)
>> I'm not quite sure what exactly you're getting at.
>
> Have you, for example ever used
>
> @ %def foo
>
> at the end of a code chunk? noweave can generated hyperlinks inside
> the code pieces from that...
No, I haven't. I didn't really know about that. I'll add it to noweb
(even though it's a shame that you have to do that by hand).

>>> 2) You separate code that belongs together. Don't you think?
>> I suppose you mean that an alias definition should be next to the
>> definition of the function that it's an alias for? Like
>>
>> <<foo>>=
>>
>> (defun foo (...)
>>   ...)
>>
>> (define-function alias-for-foo #'foo)
>> @
>>
>> That's what I thought at first, but then it occured to me that
>>
>> 1) Aliases in general aren't terribly useful. The only exception I can
>>    think of is the following. Suppose you have an operation acting on
>>    objects of type FOO, say COMPARE-FOOS. Now it happens that the
>>    definition of that function is
>>
>>      (defun compare-foos (&rest foos)
>>        (apply #'equal foos))
>>
>>    In this case it is acceptable to create COMPARE-FOOS, because it
>>    captures a different concept. This is also useful if you later
>>    change the implementation of objects of type FOO, and you can't
>>    just compare them with EQUAL. In that case you simply change the
>>    implementation of COMPARE-FOOS. If you'd use EQUAL directly, you'd
>>    have to check each and every EQUAL in your source to figure out
>>    wether it has to be adapted to the new implementation of FOOs.
>>
>>    Other than that I don't see any justification for aliases.
>
> I cannot say much about that. I am not a LISP programmer. :-(
Maybe I should have tried to explain this better, since I don't think
that this is specific to Lisp. In general, when does it make sense to
have several different names for a single function? Not very often,
I'd say.

>>> Why would it make sense to list all the abbreviations on one section
>>> (even without documenation)?
>> Because they're all obsolete. That section is a list of things to
>> remove.
>
> Hmmm, in that case, the section would not be forever. So I am with you.
Yes, it's supposed to disappear.

>>>> Thanks for taking the time to discuss - admittedly boring - details.
>>> I don't think that it is "boring". I am sure that most of us have no
>>> real experience what the best LP style in Axiom would be. Otherwise I
>>> would have seen a "Conventions" page that explains how to write good
>>> literate programs. It's not totally clear, at least not for me.
>> Not to me, either. When I read your first response to my VMLISP.LISP
>> conversion I actually thought about that. I was going to suggest that
>> you put up the example you gave (the Groebner basis fragment).
>
> All I can put onto the net is already there. My experience of
> programming in LP style is at the ALLPROSE website. I am sure that I
> am not perfect, but the whole thing is a bit bigger than just
> dhmatrix.
I looked at your ALLPROSE when Martin mentioned it to me. It's quite
impressive as far as I can see, but I didn't spend enough time with it
to say anything about it.

> And I am currently doing something here...
>
> svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk combinat
> cd combinat/combinat
> make colored dvi
I'll take a look.

\start
Date: Fri, 22 Sep 2006 20:11:27 +0200
From: Ralf Hemmecke
To: Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET

>> Have you, for example ever used
>>
>> @ %def foo
>>
>> at the end of a code chunk? noweave can generated hyperlinks inside
>> the code pieces from that...
> No, I haven't. I didn't really know about that. I'll add it to noweb
> (even though it's a shame that you have to do that by hand).

Noweb has a powerful concept of filters. If you somewhere find a filter 
that adds such things for lisp or write one yourself, you don't need to 
add that by hand.

For example, in the Aldor part of ALLPROSE, there is no need to add %def 
statements. Just a littl convention of how to write code... the rest is 
done by a script at "make dvi" time.

>>>    Other than that I don't see any justification for aliases.
>> I cannot say much about that. I am not a LISP programmer. :-(
> Maybe I should have tried to explain this better, since I don't think
> that this is specific to Lisp. In general, when does it make sense to
> have several different names for a single function? Not very often,
> I'd say.

I sometimes use macros in Aldor, but I try to keep that restricted to 
one file. The outside world should only see one thing.

> I looked at your ALLPROSE when Martin mentioned it to me. It's quite
> impressive as far as I can see, but I didn't spend enough time with it
> to say anything about it.

Well ALLPROSE is basically just for Aldor code, but as you see, it is a 
literate program by itself and that means it documents its Makefiles, 
latex-style files and PERL files. So, if you forget about the Aldor 
part, it could probably also support the documentation of LISP code.

I'll wait until I find time to understand Gaby's new build process to 
move some ideas from ALLPROSE to the Axiom code.

\start
Date: Sat, 23 Sep 2006 12:23:37 +0200
From: Frithjof Schulze
To: Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET 

Kai Kaminski wrote:

>
> I've 'literated' VMLISP.LISP.PAMPHLET (the result is attached), which
> contains compatibility/utility code.

I tried the same with eigen.spad.pamphlet. As a beginning I structured
the file, commented the functions I understand (although sometimes what
I wrote seems rather obvious) and began to write a little about the
theory.

I put the file in the wiki-source, so hopefully somebody comes up with
some kind of criticism. This is just a first try and I welcome
tips/ideas what to change. Hopefully I didn't made any content related
errors?

Tree additional questions concerning the literate source I have by now:

    How much theory belongs in a pamphlet? For example after a nice
    description what the gr=F6berner basis algorithm does, is it important
    why it terminates? Or is a reference here enough?

    If every file should be as elaborate as dhmatrix.spad, shouldn't one
    have a central point where the notation and foundations stuff gets
    clarified? Else, one would have to introduce the notation of
    vectors, matrics etc. again in every file that uses them. Maybe one
    should have a latex-style-convention in the wiki.

    How formal should a pamphlet be? Rather a heuristically description
    what happens (with reference) or better Definiton, Theorem ... ?

\start
Date: Sat, 23 Sep 2006 05:46:09 -0700 (PDT)
From: Cliff Yapp
To: Frithjof Schulze, Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET 

> I tried the same with eigen.spad.pamphlet. As a beginning I
> structured the file, commented the functions I understand (although
> sometimes what I wrote seems rather obvious) and began to write a
> little about the theory. 

Excellent!  Thank you!

> I put the file in the wiki-source, so hopefully somebody comes up
> with some kind of criticism. This is just a first try and I welcome
> tips/ideas what to change. Hopefully I didn't made any content
> related errors?

The first check is whether it builds correctly.  Or as Bill suggested,
check the notangle result against that of the previous file.

> Tree additional questions concerning the literate source I have by
> now:
> 
>     How much theory belongs in a pamphlet? For example after a nice
>     description what the grberner basis algorithm does, is it
>     important why it terminates? Or is a reference here enough? 

I don't know if there's a good answer to this.  My personal feeling is
that as much relevant information should be there as the author has
time to add, since many people may not be able to get to the referenced
articles without being at a university, but it's a judgement call -
obviously you don't want the entire life history of the major
researchers in the field as part of the pamphlet.  

I guess my response would be don't worry - just write what you think
best, and it can always be improved.  As long as the content is
accurate, it's going to be an improvement over what we have now!

>     If every file should be as elaborate as dhmatrix.spad,
>     shouldn't one have a central point where the notation and
>     foundations stuff gets clarified? Else, one would have to
>     introduce the notation of vectors, matrics etc. again in every
>     file that uses them. Maybe one should have a
>     latex-style-convention in the wiki.

Again, that's a judgement call.  I personally think it should go
something like this:

a)  In the files that implement vectors, matrix logic, and tensors a
full discussion should be present of the issues of syntax concerning
defining, displaying, and representing those objects according to major
mathematical conventions.

b)  In more specific files, a brief discussion of the points relevant
to the case in question along with a link to the main pamphlet(s) on
the issue would make sense.  If some specific conventions or syntax are
defined for the given topic, that should be discussed in the pamphlet. 
Also subject specific conventions which are not part of the wider
mathematical conventions should be covered.

Again, that's just me.  But a full treatment of a subject isn't
necessary when proposing a change - incremental improvements are also
welcome!
 
>     How formal should a pamphlet be? Rather a heuristically
>     description what happens (with reference) or better Definiton,
>     Theorem ... ? 

I don't think we're going to be universal on that right now - just
write as you prefer, and if at some point we decide on a general
convention we can go back and retool the pamphlets to all conform.  At
this point it is far more critical to get good, accurate literate
content - we don't want to drive away contributions due to style
nitpicks.  Those kinds of things can be fixed later.

\start
Date: Sat, 23 Sep 2006 14:54:09 +0200
From: Kai Kaminski
To: Frithjof Schulze
Subject: Re: Literated VMLISP.LISP.PAMPHLET

Frithjof Schulze writes:

> Kai Kaminski wrote:
>>
>> I've 'literated' VMLISP.LISP.PAMPHLET (the result is attached), which
>> contains compatibility/utility code.
>
> I tried the same with eigen.spad.pamphlet. As a beginning I structured
> the file, commented the functions I understand (although sometimes what
> I wrote seems rather obvious) and began to write a little about the
> theory.
Great! Cliff and I were actually hoping that others might join the
fun.

> I put the file in the wiki-source, so hopefully somebody comes up with
> some kind of criticism. This is just a first try and I welcome
> tips/ideas what to change. Hopefully I didn't made any content related
> errors?
I don't know Spad and I didn't check the content so far, but as far as
I can tell it looks really nice.

I have a few questions/comments:

1) Shouldn't mathematical symbols always be set in math mode, ie. 'the
   field $F$' instead of 'the field F'?

2) Isn't maybe 'Theory' a nicer heading than 'The underlying theory'?
   It's shorter and conveys the same information. Clearly a matter of
   style, though.

3) How about bibliography entries for introductory books or online
   articles on eigenvalues?

> Tree additional questions concerning the literate source I have by now:
>
>     How much theory belongs in a pamphlet? For example after a nice
>     description what the gr=F6berner basis algorithm does, is it important
>     why it terminates? Or is a reference here enough?
>
>     If every file should be as elaborate as dhmatrix.spad, shouldn't one
>     have a central point where the notation and foundations stuff gets
>     clarified? Else, one would have to introduce the notation of
>     vectors, matrics etc. again in every file that uses them. Maybe one
>     should have a latex-style-convention in the wiki.
I would think so, too. Maybe one could have include files for
different purposes, eg one for linear algebra, another one for group
theory etc.

It would be really nice to have a somewhat unified notation. Since
defining one is an awful lot of work, maybe we could borrow some ideas
from the different math sites on the web (MathWorld, for example).


Thanks a lot,
Kai

PS: I tried to edit the page to remove a typo or two, but it kept
nagging me to register, even though I already did that. I can also
edit other pages. Any idea?

\start
Date: Sat, 23 Sep 2006 15:03:44 +0200
From: Ralf Hemmecke
To: Frithjof Schulze
Subject: Pamphlet style (was: Literated	VMLISP.LISP.PAMPHLET)
Cc: Kai Kaminski

Hello!

It seems that slowly people are starting to bring legacy code into a
literate programming style. That is good and very important.

On 09/23/2006 12:23 PM, Frithjof Schulze wrote:

> I tried the same with eigen.spad.pamphlet. As a beginning I structured
> the file, commented the functions I understand (although sometimes what=

> I wrote seems rather obvious) and began to write a little about the
> theory.

Don't worry. Whatever you do is probably better than leaving the file as =

it is. The whole thing will be an iterative process. And why is that?
Because nobody at this mailing list has come forward to define a
definite style for pamphlets. I am probably right that there is no such
thing for Axiom pamphlets as a style guide.

Now, knowing that there is no help for you, the best thing you can do is =

to invent your own style and make it public.

The only stuff that I could see on the wiki is linked here...

http://wiki.axiom-developer.org/PamphletFiles

It is already something, especially
http://wiki.axiom-developer.org/PamphletExample
but currently it completely neglects the fact that there is relation
between the different pamphlet files and that nowadays we should not
just reference them via the bibliography, but via hyperlinks.

> I put the file in the wiki-source,

would it have been too hard to provide the URL directly? If you want to
have help, make it nearly zero-effort for potential contributors.

 > so hopefully somebody comes up with
> some kind of criticism. This is just a first try and I welcome
> tips/ideas what to change.

 > Hopefully I didn't made any content related errors?

Hmmm... the first thing YOU have to make sure is that your local copy of =

the Axiom sources still compiles without error (including the testcases).=


Whether you wrote good or bad content into the latex part of the
pamphlet is another question that needs review by other developers.
But the semantics should not change (at least not now or not too
drastically). In fact, I believe it must be made easier to add
testcases. Does somebody have a quick guide or reference of how to add
new testcases to Axiom?


> Tree additional questions concerning the literate source I have by now:=

>
>     How much theory belongs in a pamphlet? For example after a nice
>     description what the gr=F6berner basis algorithm does, is it import=
ant
>     why it terminates? Or is a reference here enough?

Good question. My current experience says: it depends.

If we now document every simple detail we will never reach a status
where Axiom becomes the leading research platform.

But think of Axiom as being (one of) THE leading research platform(s)
then the only place where the theory is (should be) is in the pamphlet
since there is no other reference in the world. You are inventing the
theory and deliver the code together with the theory. So that says: all
of the theory should be in the pamplet.

However, there is hundreds and hundreds of books about mathematics and
algorithms around that I believe should (currently) not being rewritten
in the form of pamphlets. I think, it is enough for certain well-known
algorithms to include one (or better several) easily accessible
references (including references to other existing implementations).

That is for now. In the long run I would even like to see standard
algorithms documented in a self-contained way in a pamphlet. It
basically means that Axiom should become not only a leading CAS, but a
source for learning about algorithms and the underlying theory.

To make that possible, sooner or later we have to start that
Axiom-Journal thing.

If you now think in terms of a journal, then a pamphlet is like an
article. Although one can consider a pamphlet as a container for several =

code files, I am not so convinced that it is the right way to do it. For =

me it is perfectly OK, if you deliver a .tar.gz archive with several
pamphlets to the journal for review. As in a true journal that archive
should describe one (new) idea.

All I want to say is that not the file is the basic unit but the
idea/topic that is described. So for example, the whole build process of =

Axiom should be described in one document (in dvi/ps/pdf/html/...
format), but not necessarily in just one .pamphlet. I don't care much
how the sources are mapped onto the hard disk. What matters is that I
get something readable, I understand the process/idea/topic and I am
able to click and my editor opens exactly at right position in the right =

file if I want to correct something.

That is basically what I provide with ALLPROSE. It is a framework to
produce a whole Aldor library. An I consider such a library as ONE unit
no matter on how many files it is distributed internally. It describes
or rather should describe one idea/topic.

>     If every file should be as elaborate as dhmatrix.spad, shouldn't on=
e
>     have a central point where the notation and foundations stuff gets
>     clarified? Else, one would have to introduce the notation of
>     vectors, matrics etc. again in every file that uses them. Maybe one=

>     should have a latex-style-convention in the wiki.

We had that before with the latex-style convention. It is not possible.
There are too many latex packages around and they are not all
compatible. We simply cannot fix the number of packages that we allow
since that is too much of a restriction to potential contributors. We
could have a journal style of how things should normally come out, but
it's impossible to think of every detail in advance.

>     How formal should a pamphlet be? Rather a heuristically description=

>     what happens (with reference) or better Definiton, Theorem ... ?

First approximation, guess and document what you've found out about the
legacy code. Next approximation, make that all more formal, add
definitions, theorems, PROOFS. A pamphlet should be a scientific
document, not just a code description. So finally, a pamphlet *is* as
formal as a journal article. (And is hopefully even formally reviewed.
And maybe later automatically verified by a proof checker -- that would
be cool!)

I hope that was not too long...

So first add your question to the FAQ page then open up
http://wiki.axiom-developer.org/PamphletStyle. And add your experience
and vision of how pamphlets should look like. Hopefully, we will soon
have some good guideline for new contributors.

\start
Date: Sat, 23 Sep 2006 15:32:09 +0200
From: Frithjof Schulze
To: Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET 

Kai Kaminski wrote:

> 1) Shouldn't mathematical symbols always be set in math mode, ie. 'the
>    field $F$' instead of 'the field F'?
>
> 2) Isn't maybe 'Theory' a nicer heading than 'The underlying theory'?
>    It's shorter and conveys the same information. Clearly a matter of
>    style, though.
> 
> 3) How about bibliography entries for introductory books or online
>    articles on eigenvalues?

Unfortunately all introductory textbooks I know are in german, but I
will look if I can find something appropriate. Also I don't really know
how to set mathematics in latex. Do you know about an introduction?
There is a lot about what fonts and symbols exists, but I would need
something about when to use what font or mode.

> I would think so, too. Maybe one could have include files for
> different purposes, eg one for linear algebra, another one for group
> theory etc.
>
> It would be really nice to have a somewhat unified notation. Since
> defining one is an awful lot of work, maybe we could borrow some ideas
> from the different math sites on the web (MathWorld, for example).

Yes. And there should be a reference some where in the wiki. Even if it
is just a reference which pamphlet defines a special notation.

> PS: I tried to edit the page to remove a typo or two, but it kept
> nagging me to register, even though I already did that. I can also
> edit other pages. Any idea?

Is it possible that I locked the page with zope-external-edit? It still
doesn't really works here.

\start
Date: Sat, 23 Sep 2006 15:57:30 +0200
From: Ralf Hemmecke
To: Frithjof Schulze
Subject: Re: Literated VMLISP.LISP.PAMPHLET
Cc: Kai Kaminski

Hi Frithjof,

On 09/23/2006 03:32 PM, Frithjof Schulze wrote:

> Unfortunately all introductory textbooks I know are in german, but I
>  will look if I can find something appropriate.

But even if you find some english reference, add the german references, too.

> Also I don't really know how to set mathematics in latex. Do you know
> about an introduction?

Under Linux I find ... (otherwise google...)

/usr/share/texmf/doc/latex/amsmath/*.dvi.gz

amsldoc.dvi and testmath.dvi should give you quite a lot of examples of 
how to do advanced stuff.

> There is a lot about what fonts and symbols exists, but I would need
> something about when to use what font or mode.

You don't usually have to care much about fonts in LaTeX, the symbols, 
however, you find, for example at the end of

/usr/share/texmf/doc/amstex/amsguide.dvi.gz

(But don't consider much the other stuff, since it describes AMS-TeX not 
AMS-LaTeX.)

If you then still have problems ask again.

\start
Date: Sat, 23 Sep 2006 16:08:24 +0200
From: Frithjof Schulze
To: Ralf Hemmecke
Subject: Re: Pamphlet style (was: Literated VMLISP.LISP.PAMPHLET) 

Ralf Hemmecke wrote:

> > I put the file in the wiki-source,
> 
> would it have been too hard to provide the URL directly? If you want
> to have help, make it nearly zero-effort for potential contributors.

Yes, I should, and could have done that easily.
 
> > so hopefully somebody comes up with
> > some kind of criticism. This is just a first try and I welcome
> > tips/ideas what to change.
> 
> > Hopefully I didn't made any content related errors?
> 
> Hmmm... the first thing YOU have to make sure is that your local copy
> of the Axiom sources still compiles without error (including the
> testcases).
> 
> Whether you wrote good or bad content into the latex part of the
> pamphlet is another question that needs review by other developers.
> But the semantics should not change (at least not now or not too
> drastically). 

Yes, axiom still compiles and testing a little by hand everything still
works fine.

> Hmmm... the first thing YOU have to make sure is that your local copy
> of the Axiom sources still compiles without error (including the
> testcases).

Are the testcases tried if I just recompile axiom or do I have compile
the whole program? There is no "test" clause or so in the Makefile. 

> That is for now. In the long run I would even like to see standard
> algorithms documented in a self-contained way in a pamphlet. It
> basically means that Axiom should become not only a leading CAS, but a
> source for learning about algorithms and the underlying theory.

That is in a way what I thought to do the other way round:
Learn about the algorithms and thereby documenting axiom. 

> I hope that was not too long...

No. What you wrote could actually be used in the wiki.
 
> So first add your question to the FAQ page then open up
> http://wiki.axiom-developer.org/PamphletStyle. And add your experience
> and vision of how pamphlets should look like. Hopefully, we will soon
> have some good guideline for new contributors.

I don't have that much 'visions' now. It will take some time until
there is a whole guideline, but I will start one.

\start
Date: Sat, 23 Sep 2006 16:26:04 +0200
From: Frithjof Schulze
To: Ralf Hemmecke
Subject: Re: Literated VMLISP.LISP.PAMPHLET 
Cc: Kai Kaminski

Ralf Hemmecke wrote:

> amsldoc.dvi and testmath.dvi should give you quite a lot of examples
> of how to do advanced stuff.

Thanks. testmath.tex is exactly what I was looking for: examples.

\start
Date: Sat, 23 Sep 2006 12:05:07 -0400
From: Bill Page
To: Frithjof Schulze
Subject: Literated eigen.spad.pamphlet

On Frithjof Schulze September 23, 2006 6:24 AM wrote:
> ...
> I tried the same with eigen.spad.pamphlet. As a beginning I
> structured the file, commented the functions I understand
> (although sometimes what I wrote seems rather obvious) and
> began to write a little about the theory.

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/EigenSpad

Great job! I am really glad that you invested time in doing this
work. I think it is excellent contributioin ot Axiom. I hope that
this work by you, Kai and Cliff is part of a trend ... :-)

>
> I put the file in the wiki-source, so hopefully somebody comes
> up with some kind of criticism. This is just a first try and I
> welcome tips/ideas what to change. Hopefully I didn't made any
> content related errors?
>

The first thing I would strongly suggest is that if you make
extensive changes like this to a pamphlet then you *should* add
your name as an author. We do want to recognize people for the
contributions they make. Ultimately perhaps, the authors/editors
of these pamphlets might wish to add them to their personal list
of papers and publications. In many cases these contributions
should count as research.

Of course getting the details right is important but just getting
started is sometimes the hardest part. But I didn't find any problems
in what you wrote and I learned several things about the Axiom eigen
package that I didn't know before. Thanks.

> Three additional questions concerning the literate source I
> have by now:
>
>  How much theory belongs in a pamphlet? For example after a nice
>  description what the gr=F6berner basis algorithm does, is it
>  important why it terminates? Or is a reference here enough?

I think references are important. Use web references if you can.
I suggest using hyperref to add clickable links directly in the
LaTeX source.

>
> If every file should be as elaborate as dhmatrix.spad, shouldn't
> one have a central point where the notation and foundations
> stuff gets clarified? Else, one would have to introduce the
> notation of vectors, matrics etc. again in every file that uses
> them. Maybe one should have a latex-style-convention in the wiki.

I think including a short section on notation in each pamphlet
would be good enough for now.

>
>  How formal should a pamphlet be? Rather a heuristically
>  description what happens (with reference) or better Definiton,
>  Theorem ... ?
>

Starting with just a heuristic description is fine. If you are
able to make some formal definitions and add a theorem or two
that might make the mathematician more comfortable :-) but it
is not necessary at this point - especially if you can find some
basic references.

\start
Date: Sat, 23 Sep 2006 12:07:33 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: Literated VMLISP.LISP.PAMPHLET

On September 23, 2006 8:54 AM you wrote:
> 
> PS: I tried to edit the page to remove a typo or two, but it kept
> nagging me to register, even though I already did that. I can also
> edit other pages. Any idea?
> 

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/EigenSpad

Editing this page works for me. It did not prompt me to register
or login.

Are you still having problems?

\start
Date: Sat, 23 Sep 2006 11:53:46 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: SPAD grammar and parsing

Poking around in the interp code, a couple of questions arise.

The first one is whether there is a grammar for the SPAD language.  If
memory serves, the answer to this is no there is not, but there is a
grammar for Aldor.

There has been some discussion in the past about programs like cl-yacc
that can generate a parser for a language based on its grammar.  I
don't know if a program like that could handle SPAD/Aldor->Lisp, but if
it could using it would solve two problems:

1)  It would force us to develop an actual grammar for the language
Axiom is using.

2)  It would help avoid the need to tangle with the maze of boot/spad
definitions we currently are using for this process by generating the
code we need in (hopefully) a cleaner, more modern style.

If such a generator really works, it has the additional benefit of
making it much simpler to put new ideas about language behavior into
practice.  Unfortunately parsers and language grammars seem to be
something of a non-trivial topic.  Is there anyone here for whom that
would be an interesting direction to work?

\start
Date: Sat, 23 Sep 2006 21:13:58 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: SPAD grammar and parsing
Cc: Christian Aistleitner

> The first one is whether there is a grammar for the SPAD language.  If
> memory serves, the answer to this is no there is not, but there is a
> grammar for Aldor.

I don't know for SPAD, but the Aldor User Guide (see aldor.org) gives a 
grammar for Aldor.

How else could Christian Aistleitner have written a parser for Aldor?

Bill, hasn't Christian sent you the code? Is that somewhere public? What 
license?

\start
Date: Sat, 23 Sep 2006 23:25:13 +0200
From: Ralf Hemmecke
To: Frithjof Schulze
Subject: Re: Pamphlet style

 >> I hope that was not too long...
 >
 > No. What you wrote could actually be used in the wiki.

I've just added

http://wiki.axiom-developer.org/SandboxPamphletStyle

I have no idea why it appears in a "verbatim" style. :-(

\start
Date: Sat, 23 Sep 2006 23:43:17 +0200
From: Frithjof Schulze
To: Ralf Hemmecke
Subject: Re: Pamphlet style 

Ralf Hemmecke wrote:

> I have no idea why it appears in a "verbatim" style. :-(

Latex couldn't understand the \begin{blah} ... \end{blah} stuff.

\start
Date: Sun, 24 Sep 2006 01:24:52 -0400
From: Bill Page
To: Alfredo Portes
Subject: Sage on Doyen

I have finally updated the MathAction darcs repository
http://wiki.axiom-developer.org/MathActionRepository to include
the changes I made to MathAction to support Sage \begin{sageblock}
and \sage{...} commands.

Do you have some time available to add this to the DoyenCD?

You should use:

  darcs pull http://page.axiom-developer.org/repository/latexwiki

to get these updates for Sage support. As usual, take care to
modify the paths in the code appropriately for Doyen.

I would like to be able to distribute the DoyenCD with Doyen Wiki
support for Sage at the upcoming Sage Days 2 in Seattle, October
6-10. I will be attending the meeting and especially the coding
sprint sessions where I plan to do my best to implement a first
version of a Sage interface for Axiom. This would mean that Sage
users would be able to use Axiom the same way they use Maxima now.

http://modular.math.washington.edu/sage/days2
http://sage-wiki.axiom-developer.org/days2

If you could put up a version of Doyen with Sage support on the web,
I would also like to add a few pages to the wiki that demonstrate
how to use Sage (derived from those on MathAction) so that they can
be included on the DoyenCD.

Regards,
Bill Page.


--------

On August 16, 2006 12:45 PM Bill Page wrote:

Subject: RE: sage.sty

Alfredo,

'sagetex.sty' is part of the Sage distribution. Look in your

   sage-root/examples/latex_embed

On axiom-developer look at:

  /home/page/sage-1.3.6.2/examples/latex_embed

I used everything from this directory just as it is with no
modifications. I added 'sagetex.sty' to the LaTeX style
directories in the same place as 'axiom.sty'. The only slightly
tricky thing was to locate 'sagetex.py' where it could be
found by sage (answer: var/LatexWiki).

You will see that 'sagetex.sty' and 'sagetex.py' must work
together.

Regards,
Bill Page.
________________________________

	From: Alfredo Portes [mailto:Alfredo Portes] 
	Sent: Wednesday, August 16, 2006 12:35 PM
	To: Bill Page
	Subject: sage.sty
	
	
	Bill,
	
	Do you think I can get a copy of sage.sty, if it is stable
      enough and you are not currently modifying it.
	
	Regards,
	
	JAP

\start
Date: Sun, 24 Sep 2006 21:49:18 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Sage on Doyen

Bill,

> I have finally updated the MathAction darcs repository
> http://wiki.axiom-developer.org/MathActionRepository to include
> the changes I made to MathAction to support Sage \begin{sageblock}
> and \sage{...} commands.

Thanks.

> Do you have some time available to add this to the DoyenCD?

Tomorrow, I can spend time working on this.

> You should use:
>
>   darcs pull http://page.axiom-developer.org/repository/latexwiki
>
> to get these updates for Sage support. As usual, take care to
> modify the paths in the code appropriately for Doyen.

10-4. :-)

> I would like to be able to distribute the DoyenCD with Doyen Wiki
> support for Sage at the upcoming Sage Days 2 in Seattle, October
> 6-10. I will be attending the meeting and especially the coding
> sprint sessions where I plan to do my best to implement a first
> version of a Sage interface for Axiom. This would mean that Sage
> users would be able to use Axiom the same way they use Maxima now.
>
> http://modular.math.washington.edu/sage/days2
> http://sage-wiki.axiom-developer.org/days2

Sounds great. I plan to talk to my advisor tomorrow and hopefully I
can go the Sage days. :-)

> If you could put up a version of Doyen with Sage support on the web,
> I would also like to add a few pages to the wiki that demonstrate
> how to use Sage (derived from those on MathAction) so that they can
> be included on the DoyenCD.

http://doyen.sytes.net . I will let you know when I update this with
your version
on MathAction.

\start
Date: Sun, 24 Sep 2006 23:44:29 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Sage on Doyen

On September 24, 2006 9:49 PM you wrote:
> 
> > I have finally updated the MathAction darcs repository
> > http://wiki.axiom-developer.org/MathActionRepository to include
> > the changes I made to MathAction to support Sage \begin{sageblock}
> > and \sage{...} commands.
> 
> Thanks.
> 
> > Do you have some time available to add this to the DoyenCD?
> 
> Tomorrow, I can spend time working on this.
>

Great.
 
> ... 
> > I would like to be able to distribute the DoyenCD with Doyen Wiki
> > support for Sage at the upcoming Sage Days 2 in Seattle, October
> > 6-10. I will be attending the meeting and especially the coding
> > sprint sessions where I plan to do my best to implement a first
> > version of a Sage interface for Axiom. This would mean that Sage
> > users would be able to use Axiom the same way they use Maxima now.
> >
> > http://modular.math.washington.edu/sage/days2
> > http://sage-wiki.axiom-developer.org/days2
> 
> Sounds great. I plan to talk to my advisor tomorrow and hopefully
> I can go the Sage days. :-)
>

Dr. William Stein was very interested to see your presentation on
Doyen. I think you might find some of the weekend talks interesting
(see attached email) and you help during the coding sprints would
be most welcome. :-)

Do not delay about making travel plans when you get approval to go
and contact the meeting organizers as soon as possible to confirm.
Apparently hotel accomodations in Seattle are getting a little tight
for that weekend.
 
> > If you could put up a version of Doyen with Sage support on the
> > web, I would also like to add a few pages to the wiki that
> > demonstrate how to use Sage (derived from those on MathAction)
> > so that they can be included on the DoyenCD.
> 
> http://doyen.sytes.net . I will let you know when I update this
> with your version on MathAction.
> 

Thanks.

http://24.44.150.177:8880/Doyen/SandBox

I see a problem with the Maxima output on this page. The $ should not
be present. I recall that you had to change the Maxima output parsing
regular expression because of a difference between Maxima built with
clisp (on Doyen) versus Maxima built with GCL (on MathAction). Do you
have a solution for this problem? If not, I can look into it.

Regards,
Bill Page.



-----Original Message-----
From: William Stein
Sent: September 24, 2006 3:21 AM
To: Iftikhar Burhanuddin
Cc: sage-days@sage.scipy.org; sage-devel@lists.sourceforge.net; Joseph L
Wetherell
Subject: Re: [SAGEdev] SD2 Talks


On Sat, 23 Sep 2006 12:47:40 -0700, Iftikhar Burhanuddin  
<burhanud@usc.edu> wrote:

> I'd like to see some talks at SD2 which will make us better sage
> developers, like the architecture of Sage, design choices, Pyrex, Coding
> practices, etc. Of course not at the cost of the math-comp talks!
>
> Have you drawn up a schedule or at least a list of tentative talks?

Here's a possible schedule.  Comments are welcome.   I'm all for
having tons of talks on the weekend, since there will be almost
no talks on Friday, Monday, and Tuesday.

=================================================================

FRIDAY (Coding sprint day):
         * 9am - 12pm: Organization session
         * 12 - 2pm: LUNCH (catered?)
         * 2pm ---> sprint!

=================================================================

SATURDAY (talks):

   Direction:
         * 9:00-10:00am -- W. Stein:  SAGE status report

   Use (30 minutes each):
         * 10:10 - 11:00 -- D. Joyner: Teaching undergrads using SAGE
         * 11:10 - 12:00 -- D. Harvey: the p-adic sigma functions and
                            p-adic heights

         * 12:00 - 2:00 -- LUNCH (catered??)

         * 2:00 - 2:25 -- J. Kantor & T. Boothby: Ray tracing in SAGE
         * 2:30 - 3:00 -- A. Clemesha: SAGE Graphics
         * 3:10 - 3:30 -- T. Boothby: The SAGE Notebook

         * 3:30 - 4:15 -- AFTERNOON BREAK

         * 4:15 - 4:45 -- Y. Qiang: Distributed Computation with Python
         * 5:00 - 5:30 -- M. Rubinstein: computing with L-functions

   Direction:
         * 5:40 - 6:30 -- W. Stein: Topic -- The SAGE Foundation?!

         * 7:00 - ? -- DINNER; hang out at cool Seattle coffee shops

=================================================================

SUNDAY:

  Direction:
         * 9:00 - 10:00 -- W. Stein: Development roadmap, funding sources,
                                     future conferences and workshop

  Development:
         * 10:15 - 11:00 -- W. Stein: Pyrex
         * 11:10 - 12:00 -- D. Harvey (and W. Stein): SAGE architecture,
                            design and coding

         * 12:00 - 2:00 -- LUNCH (on the ave)

         * 2:00 - 2:30 -- R. Bradshaw (& D. Harvey): Optimizing linear  
                          algebra in SAGE
         * 2:45 - 3:30 -- M. Albrecht: Groebner basis and crypto in SAGE  
                          (e.g., F4)
         * 3:45 - 4:15 -- J. Kantor: Numerical Computation in SAGE

         * 4:15 - 4:45 -- AFTERNOON BREAK

  Computational Number theory:
         * 4:45 - 5:15 -- J. Quer: Toward a database of Q-curves
         * 5:30 - 6:00 -- J. Voight: Computing quaternions with MAGMA
         * 6:10 - 6:40 -- S. Pauli: Remarks on computational algebraic  
                          number theory

  Direction:
         * 6:40 - 7:00 -- W. Stein: Wrap up.

         * 7:00 - ? -- DINNER; hang out at cool Seattle coffee shops

=================================================================

MONDAY:
   Coding sprints:
         * 10:00 - 11:30: Status reports; organization
         *  5:00 -  6:00: Lightening demos

=================================================================

TUESDAY:
   Coding sprints:
         * 2:00 - 4:00pm: Progress reports and plan for the future

\start
Date: 25 Sep 2006 13:03:00 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: axiom.silver
Cc: Jaroslov Rosenberger, Gabriel Dos Reis

Bill Page writes:

> Camm,
> 
> On Friday, September 15, 2006 11:31 AM you wrote:
> > 
> > Can we finalize this stat bit please?  I'm trying to get 2.6.8 out
> > ....
> 
> I had a bit of trouble with my Windows MSYS/MinGW configuration
> over the weekend, but now I have got it straight. See the Windows
> configuration here:
> 
> http://wiki.axiom-developer.org/BuildAxiom
> 
> for how I setup the build environment.
> 
> I needed the following patch to build on Windows because of a
> difference with lstat (explained in the patch).
> 
> $ diff -Naur gcl-2.6.8pre_orig/o gcl-2.6.8pre/o
> diff -Naur gcl-2.6.8pre_orig/o/unixfsys.c gcl-2.6.8pre/o/unixfsys.c
> --- gcl-2.6.8pre_orig/o/unixfsys.c      Sun Sep 17 17:54:43 2006
> +++ gcl-2.6.8pre/o/unixfsys.c   Wed Sep 20 01:03:44 2006
> @@ -34,6 +34,10 @@
>  
>  #ifdef __MINGW32__ 
>  #  include <windows.h> 
> +/* Windows has no symlink, therefore no lstat.  Without symlinks lstat
> +   is equivalent to stat anyway.  */
> +#  define S_ISLNK(a) 0
> +#  define lstat stat
>  #endif 

Thanks!  Will apply this.


>  
>  #ifdef BSD
> 
> ----------
> 
> With this patch applied I was able to build both the CLtL1 and ANSI
> images.
> 
> Here are the results of some tests of the new si:stat function:
> 
> $ saved_gcl
> GCL (GNU Common Lisp)  2.6.8 CLtL1    Sep 20 2006 02:26:46
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> Temporary directory for compiler files set to
> C:/DOCUME~1/bpage/LOCALS~1/Temp/
> 
> >(si:stat "tryserv.tcl")
> 
> (:FILE 481 1158724649)
> 
> >(si:stat "tryserv.xxx")
> 
> NIL
> 
> >(si:stat "bfd")        
> 
> (:DIRECTORY 0 1158734019)
> 
> >(quit)
> 
> ------------
> 
> The difference between this and your output below seems to be due
> to a change in the coding for this section in the current CVS
> which now looks like this:
> 
>   if (lstat(filename,&ss))
>     RETURN1(Cnil);
>   else {/* ctime_r insufficiently portable */
>     /* int j;
>        ctime_r(&ss.st_ctime,filename);
>        j=strlen(filename);
>        if (isspace(filename[j-1]))
>        filename[j-1]=0;*/
>     RETURN1(list(3,S_ISDIR(ss.st_mode) ? sKdirectory :
>                  (S_ISLNK(ss.st_mode) ? sKlink : sKfile),
>                  make_fixnum(ss.st_size),make_fixnum(ss.st_ctime)));

The issue I had found was that on Solaris, ctime_r was a no-op.  In
general, there are quite a few interesting fields in struct stat that
we might want to see, the question is in what form, in particular,
machine or human readable.  Here are other possibilities:

the protection mode (likely not very portable?)
uid/gid
access time/modification time
char device/block device/fifo/socket?

Now that I read the manpage, we could use ctime itself, as it returns
a pointer to statically allocated memory.  In general, we should avoid
any libc calls which call malloc due to the memory fragmentation
effects on ht e GCL heap.  I'm not sure if the ascii time string is
more useful, as one would have to write a parser to manipulate it.

Take care,


> 
> -------
> 
> So is this the result you expected from Windows?
> 
> Regards,
> Bill Page.
> 
> > 
> > In addition to knowing whether enough information is provided, I need
> > to know if it works on windows, macosx, and any other proprietary
> > system of interest.
> > ... 
> > > 
> > > The easy way, which avoids the requirement of PDP-10 lisp
> > > comaptability :-), is si::stat.  How about this:
> > > 
> > > Index: unixfsys.c
> > > ===================================================================
> > > RCS file: /cvsroot/gcl/gcl/o/unixfsys.c,v
> > > retrieving revision 1.28
> > > diff -u -r1.28 unixfsys.c
> > > --- unixfsys.c	24 Aug 2006 16:53:28 -0000	1.28
> > > +++ unixfsys.c	12 Sep 2006 16:35:56 -0000
> > > @@ -23,6 +23,7 @@
> > >  #include <stdlib.h>
> > >  #include <unistd.h>
> > >  #include <errno.h>
> > > +#include <time.h>
> > >  
> > >  #define IN_UNIXFSYS
> > >  #include "include.h"
> > > @@ -490,6 +491,34 @@
> > >  }
> > >  
> > >  
> > > +DEF_ORDINARY("DIRECTORY",sKdirectory,KEYWORD,"");
> > > +DEF_ORDINARY("LINK",sKlink,KEYWORD,"");
> > > +DEF_ORDINARY("FILE",sKfile,KEYWORD,"");
> > > +
> > > 
> > +DEFUN_NEW("STAT",object,fSstat,SI,1,1,NONE,OO,OO,OO,OO,(objec
> > t path),"") {
> > > +
> > > +  char filename[4096];
> > > +  struct stat ss;
> > > +  
> > > +
> > > +  bzero(filename,sizeof(filename));
> > > +  coerce_to_filename(path,filename);
> > > +  if (lstat(filename,&ss))
> > > +    RETURN1(Cnil);
> > > +  else {
> > > +    int j;
> > > +    ctime_r(&ss.st_ctime,filename);
> > > +    j=strlen(filename);
> > > +    if (isspace(filename[j-1]))
> > > +      filename[j-1]=0;
> > > +    RETURN1(list(3,S_ISDIR(ss.st_mode) ? sKdirectory : 
> > > +		 (S_ISLNK(ss.st_mode) ? sKlink : sKfile),
> > > +		 make_fixnum(ss.st_size),make_simple_string(filename)));
> > > +  }
> > > +}
> > > +
> > > +
> > > +
> > >  
> > DEFUN_NEW("SETENV",object,fSsetenv,SI,2,2,NONE,OO,OO,OO,OO,(ob
> > ject variable,object value),"Set environment VARIABLE to VALUE")
> > >  
> > >  {
> > > 
> > > 
> > > >(si::stat "/tmp/ff1.h")
> > > 
> > > (:LINK 9 "Tue Sep 12 12:32:58 2006")
> > > 
> > > >(si::stat "/tmp/ff.h")
> > > 
> > > (:FILE 0 "Mon Dec  5 13:52:23 2005")
> > > 
> > > >(si::stat "/tmp/")
> > > 
> > > (:DIRECTORY 81920 "Tue Sep 12 12:34:53 2006")
> > > 
> > > >(si::stat "/tmp")
> > > 
> > > (:DIRECTORY 81920 "Tue Sep 12 12:34:53 2006")
> > > 
> > > >(si::stat "/tmp1")
> > > 
> > > NIL
> > > ... 

\start
Date: Mon, 25 Sep 2006 20:39:04 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: re: [build Axiom] updated Windows buildinstructions

> Does somebody know why X11 is required? Axiom was also sold on Windows 
> if I am not completely wrong. How did NAG produce graphics there?
> 
> I quickly looked at src/algebra/view2D.spad but I could not see anything 
> related to X. Since I have no idea what
> 
>    VIEW    ==> VIEWPORTSERVER$Lisp
> 
> refers to, I am out of business. :-( But I really really wonder, why X 
> is a must for draw and/or write. Does Axiom (through LISP) call some 
> functions from X?

Axiom is actually a collection of processes. The top level process is
sman (superman) which starts and controls other processes, including
AXIOMsys (the interpreter), viewman (the graphics) and hyperdoc.

All of the processes communicate thru sockets.

Viewman does all of the drawing work using X11.

\start
Date: Mon, 25 Sep 2006 22:17:38 -0400
From: Bill Page
To: list
Subject: FW: RE: Google Code repository

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

On Fri, Sep 22, 2006 at 09:02:28AM -0400, Bill Page wrote:
> Welcome to the Axiom Developer list :-)

Thank you!

> > Perhaps it can be useful?
> 
> Yes, thank you very much. Your description is very useful.

I'm glad to hear that.

> I am quite impressed by how simple it is to use Tailor to move
> complete repositories (including all history and revisions) from
> one system to another. If we can't have just one common type of
> source code respository, then at least we can interoperate.

Yes, the problem for me is darcs is really slow on my computer.  I might
as well consider switching to mercurial.  The fact it is coded in
Python, a language in which I'm more fluent than in Haskell, is also a
strong point in its favor.

\start
Date: Tue, 26 Sep 2006 07:24:49 +0200
From: Christian Aistleitner
To: Ralf Hemmecke, Cliff Yapp
Subject: Re: SPAD grammar and parsing

On Sat, 23 Sep 2006 21:13:58 +0200, Ralf Hemmecke wrote:

>> The first one is whether there is a grammar for the SPAD language.  If
>> memory serves, the answer to this is no there is not, but there is a
>> grammar for Aldor.
>
> I don't know for SPAD, but the Aldor User Guide (see aldor.org) gives a  
> grammar for Aldor.

IIRC, there are lots of problems with the grammar. For example,  
parenthesis do not occur in the grammar.
Anyone ever written a considerable Aldor program not using parenthesis?

> Bill, hasn't Christian sent you the code? Is that somewhere public? What  
> license?

According to my mail client, I sent the code to Bill on 2005-10-20  
11:19:33 CEST.
I wrote to the mailing list the same day saying that anyone who wants to  
have the code, should drop me a line. I found no lines in my inbox.

\start
Date: Tue, 26 Sep 2006 10:37:47 -0400
From: Tim Daly
To: Kai Kaminski
Subject: re: [build Axiom] updated Windows buildinstructions

> To address your problem: I seem to remember that there is a simple way
> to print the plot data (i.e. the list of points) to the console. If
> not, simply change VIEW2D.SPAD. Then feed that list to GnuPlot.

You can save the Axiom graphics output to files and run the 
program called ViewAlone on them. There are many examples
of saved output in the source tree. See 
src/graph/viewAlone/parabola.VIEW

\start
Date: Tue, 26 Sep 2006 10:46:20 -0400
From: Tim Daly
To: Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET

The VMLISP file exists because the original sources were in MACLISP
and were ported to VMLISP. Eventually they were ported to an early
version of common lisp. 

The basic strategy was to leave the sources unchanged and write
common lisp equivalents for the maclisp and vmlisp functions were
possible. Many functions like EvalAndFileACTQ were possible to 
emulate closely enough that "it works for axiom". We were not
trying for generality. When we couldn't write the equivalent
function we rewrote the code.

This work was done in parallel with the development of AKCL.
Bill Schelter developed AKCL under contract to IBM and I helped
with some of that developement. Not all of the functions in 
common lisp existed or worked at the time.

Macros were used instead of 'Inline' because macro-expanded code
could be better optimized than 'inline' directive code. Many
tests were made by using the disassemble function and counting
actual machine instructions generated. In theory the two are
equivalent but in practice they are not.

\start
Date: Tue, 26 Sep 2006 10:48:47 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: re: [build Axiom] updated Windows buildinstructions

> Ho, I was totally wrong this week-end when I spoke about some socket
> related code not used. I reread the sockio.lisp.pamphlet file and found
> the functions used in the interpreter (I have never studied these parts
> of the intergreter). Sorry for this.

any chance you could capture some of this insight as
documentation for the code?

\start
Date: Tue, 26 Sep 2006 11:06:32 -0400
From: Tim Daly
To: Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET

> use lots of small functions. What is the difference between

This defines 2 functions.

> 
> (defun bar (...)
>   (blah blub))
> 
> (defun foo (...)
>   (let ((...))
>     (bar ...)))
> 

This defines a function and a "top level form".
The first expression is evaluated and returns a function.
The second expression is immediately evaluated for effect.

> and
> 
> <<foo>>=
> (defun foo (...)
>   (let ((...))
>     <<do-bar>>))
> @
> 
> <<do-bar>>=
> (blah blub)
> @

Depending on the situation the value of the top level form
could have other side effects.

\start
Date: Tue, 26 Sep 2006 11:12:40 -0400
From: Tim Daly
To: Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET

The 'alias' functions were defined following the philosophy of
writing VMLISP functions in common lisp rather than changing
the source code to be common lisp. This was the general porting
strategy we used in the past.

Keep in mind that we only need the alias function to perform the
specific task that axiom needs. In general the cover functions are
not even close to being equivalent but they cover the semantics
needed by axiom.

At the present time the code rewrite is removing many of these
functions completely. Bookvol5.pamphlet will not only be common 
lisp but will be ANSi common lisp. The net effect is that files
like vmlisp will go away.

\start
Date: Tue, 26 Sep 2006 11:18:29 -0400
From: Tim Daly
To: Kai Kaminski
Subject: Re: Literated VMLISP.LISP.PAMPHLET

> 1) Aliases in general aren't terribly useful.

In general they are not. But if you want to provide porting
functions that cover the semantics of two different functions
it is useful in lisp to just store a pointer in the function
cell of a symbol. It's a porting technique, not a useful
idea in general.




I should point out that you have to be VERY CAREFUL in axiom.
Not all function names that are used show up in the source.
This is NOT OBVIOUS. Axiom dynamically constructs some function
names so you cannot just grep to decide if something is being
used or not.

Plus Axiom plays some optimization games. Functions are initially
defined as 'autoload' which is just a trigger function. On first
use the trigger function loads the actual code which replaces the
function definition so it will have the correct definition on the
second and subsequent uses. There are other automatic 'inline'
operations that occur in order to speed up computation.

\start
Date: Tue, 26 Sep 2006 12:29:25 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Literated VMLISP.LISP.PAMPHLET
Cc: Kai Kaminski

> Indeed.  That os very annoying for debug sessions. :-(

debugging optimized code is always hard.
gcc does code-motion, loop unrolling, beta substitution, operator
promotion and many other things that make gdb sessions a pain.
ultimately it's the final disassemble instruction counts that matter.

\start
Date: Tue, 26 Sep 2006 19:35:00 +0200
From: Kai Kaminski
To: Tim Daly
Subject: Re: Literated VMLISP.LISP.PAMPHLET

Tim Daly writes:

>> use lots of small functions. What is the difference between
>
> This defines 2 functions.
True.
>> 
>> (defun bar (...)
>>   (blah blub))
>> 
>> (defun foo (...)
>>   (let ((...))
>>     (bar ...)))
>> 
>
> This defines a function and a "top level form".
> The first expression is evaluated and returns a function.
> The second expression is immediately evaluated for effect.
No. The DO-BAR chunk is included in the FOO chunk. Hence (BLAH BLUB)
ends up in the body of FOO and is not a toplevel form. Of course, the
two snippets differ in that one defines a function and the other does
not. But in a Lisp program I'd very much prefer the former, since it's
easier to understand and to work with. If performance is an issue, an
INLINE-declaration might help.

>> and
>> 
>> <<foo>>=
>> (defun foo (...)
>>   (let ((...))
>>     <<do-bar>>))
>> @
>> 
>> <<do-bar>>=
>> (blah blub)
>> @
>
> Depending on the situation the value of the top level form
> could have other side effects.
It is not a toplevel form.

\start
Date: Tue, 26 Sep 2006 21:43:40 +0200
From: Kai Kaminski
To: Tim Daly
Subject: Re: Literated VMLISP.LISP.PAMPHLET

I put your last two messages about the aliases in VMLISP.LISP
together, I hope you don't mind.

Tim Daly writes:

>> 1) Aliases in general aren't terribly useful.
>
> In general they are not. But if you want to provide porting
> functions that cover the semantics of two different functions
> it is useful in lisp to just store a pointer in the function
> cell of a symbol. It's a porting technique, not a useful
> idea in general.
Sure.

> I should point out that you have to be VERY CAREFUL in axiom.
> Not all function names that are used show up in the source.
> This is NOT OBVIOUS. Axiom dynamically constructs some function
> names so you cannot just grep to decide if something is being
> used or not.
I thought so, which is one of the reasons I didn't actually remove
anything. If we remove a function that's actually used, we'll notice
pretty soon, though.

> Plus Axiom plays some optimization games. Functions are initially
> defined as 'autoload' which is just a trigger function. On first
> use the trigger function loads the actual code which replaces the
> function definition so it will have the correct definition on the
> second and subsequent uses. There are other automatic 'inline'
> operations that occur in order to speed up computation.
What is this optimizing for? Memory? Is it still necessary?

> At the present time the code rewrite is removing many of these
> functions completely. Bookvol5.pamphlet will not only be common 
> lisp but will be ANSi common lisp. The net effect is that files
> like vmlisp will go away.
That's what I was trying to help with. The whole thing grew out of the
recent GUI discussion. Since there is no broad consensus on the GUI
and several other questions, Cliff and I tried to find a minimal
common ground. We finally agreed that chunking up and documenting
Axiom's internals is a useful project, that anyone can participate
in.

\start
Date: Tue, 26 Sep 2006 18:38:50 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Axiom memory usage and GCL

On Tuesday, September 26, 2006 11:33 AM you wrote:
>
> Bill Page writes:
> | ...
> | Starting with Camm's newest version of 2.6.8pre it is
> | possible to set maxpage a non-power of 2. I am not using
> | --enable-maxpage=196*1024 on MathAction and this seems to
> | be working so far.
>

What I meant to write was: I am *now* using

  --enable-maxpage=196*1024

> Many thanks.
>
> The reason I was asking is that I have a successful build of
> the axiom.build-improvements branch on the two machines I have,
> but when I tried on the SF Deian machine x86-linux1 I got a
> failure

How do you access the SF x86-linux1 machine? I used to have
access but the method I used (via cf.sourceforge.net) stopped
working a few weeks ago and I haven't been able to access any
of the compile farm machines since that time.

> -- which I can reproduce on another "old" x86 machine running
> redhat.  Both of them have "low" memory (256KB).  The failure
> in both build is:
>
> ====
>
> Loading
> /scratch/latexo/users/gdr/build/obj/i686-intel-linux/interp/util.o
> start address -T 0x86fb000 Finished loading
> /scratch/latexo/users/gdr/build/obj/i686-intel-linux/interp/util.o
>
> Error: The function BUILD is undefined.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by SETQ.
> Broken at SETQ.  Type :H for Help.
> BOOT>>make[4]: Leaving directory
> `/scratch/latexo/users/gdr/build/src/interp'
>
> ====
>

I think the effects of low memory can be unpredictable. You
should definitely try using the newest gcl-2.6.8pre and
changing CGLOPTS to specify a smaller default memory such as

  --enable-maxpage=196*1024

> ...

\start
Date: 27 Sep 2006 01:10:24 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Axiom memory usage and GCL

Bill Page writes:

| Gaby,
| 
| On Tuesday, September 26, 2006 11:33 AM you wrote:
| > 
| > Bill Page writes:
| > | ... 
| > | Starting with Camm's newest version of 2.6.8pre it is
| > | possible to set maxpage a non-power of 2. I am not using
| > | --enable-maxpage=196*1024 on MathAction and this seems to
| > | be working so far.
| > 
| 
| What I meant to write was: I am *now* using
| 
|   --enable-maxpage=196*1024

OK.

| > Many thanks.
| > 
| > The reason I was asking is that I have a successful build of
| > the axiom.build-improvements branch on the two machines I have,
| > but when I tried on the SF Deian machine x86-linux1 I got a
| > failure
| 
| How do you access the SF x86-linux1 machine? I used to have
| access but the method I used (via cf.sourceforge.net) stopped
| working a few weeks ago and I haven't been able to access any
| of the compile farm machines since that time.

I first log onto cf-shell.sf.net; then ssh x86-linux1 from there.

[...]

| I think the effects of low memory can be unpredictable. You
| should definitely try using the newest gcl-2.6.8pre and
| changing CGLOPTS to specify a smaller default memory such as
| 
|   --enable-maxpage=196*1024

the build-improvements branch uses the newest gcl-2.6.8pre.

I've been doing a binary search (which gives me a chance to appreciate
changetset commits); I may be near the commit that caused the problem,
but I really wish Axiom were faster to compile.  I hope to be at a
point where I can start parallel make, but I first need to get this
issue out of the way.

\start
Date: Tue, 26 Sep 2006 19:41:54 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Axiom memory usage and GCL

On Tuesday, September 26, 2006 7:10 PM you wrote:

> ...
> Bill Page wrote:
> |
> | How do you access the SF x86-linux1 machine? I used to
> | have access but the method I used (via cf.sourceforge.net)
> | stopped working a few weeks ago and I haven't been able
> | to access any of the compile farm machines since that time.
>
> I first log onto cf-shell.sf.net; then ssh x86-linux1 from
> there.

Cool. I wonder why no one at SourceForge ever mentioned that
this is possible?

https://sourceforge.net/tracker/?func=detail&atid=200001&aid=155345=
6&gro
up_id=1

Or why the compile farm docs don't mention it except for remote
commmand execution? 'course I shoulda thought of trying that...
;)

> ...
> I've been doing a binary search (which gives me a chance to
> appreciate changetset commits); I may be near the commit that
> caused the problem, but I really wish Axiom were faster to
> compile.

You mean there once was a version of build.improvements that did
compile in such small memory? You did not explain this earlier.

> I hope to be at a point where I can start parallel make, but
> I first need to get this issue out of the way.

Do you suspect some Axiom coding error??? Or are you talking
about a different issue. It is no longer clear to me.

\start
Date: 27 Sep 2006 02:36:33 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Axiom memory usage and GCL

Bill Page writes:

[...]

| > I've been doing a binary search (which gives me a chance to
| > appreciate changetset commits); I may be near the commit that
| > caused the problem, but I really wish Axiom were faster to
| > compile.
| 
| You mean there once was a version of build.improvements that did
| compile in such small memory? You did not explain this earlier.

I'm sorry for not being clear.  The newest gcl-2.6.8pre has been on
the build-improvements branch since
September 17; see zips/ChangeLog.build-improvements

    2006-09-17  Gabriel Dos Reis  Gabriel Dos Reis

            * gcl-2.6.8pre.tgz: Update.

and it contains patches that Camm and you worked on (I believe).

For the moment, the build seems to be broken except on my two
machines.  Once, it is back to normal I'll ping you for test.

| > I hope to be at a point where I can start parallel make, but
| > I first need to get this issue out of the way.
| 
| Do you suspect some Axiom coding error??? Or are you talking
| about a different issue. It is no longer clear to me.

Before blaming Axiom, I prefer to blame myself first -- the makefiles
are very tricky and what can appear as a small change in a Makefile
can have far reaching fallouts in Lisp codes (especially in src/interp
where I'm having this problem) because of very poor or lack of
abstractions. 

>From the description you gave, it looks to me like my failures may
have a different root from yours.  Since, it takes long to compiler
Axiom, it takes long to make progress.

\start
Date: Tue, 26 Sep 2006 21:56:01 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: Literated VMLISP.LISP.PAMPHLET

Too much context was removed by Tim in his reply and there was
no reference to the specific email to which this was a reply so
at first I thought: What is this all about? :-(

Then I tried to understand from

http://www.lisp.org/HyperSpec/Body/glo_t.html#top_level_form

"top level form n. a form which is processed specially by
compile-file for the purposes of enabling compile time
evaluation of that form. Top level forms include those forms
which are not subforms of any other form, and certain other
cases. See Section 3.2.3.1 (Processing of Top Level Forms)."

and

http://www.lisp.org/HyperSpec/Body/sec_3-2-3-1.html

what is meant by "top level form" in the discussion below but
failed.

Is this distinction relevant to the discussion?

>From my point of view 'bar' is something defined at one level,
i.e. at the "lisp" level. Whereas 'do-bar' is something
defined at a "higher" level, i.e. as a chunk name in the
pamphlet file or the "literate program" level.

Kai writes: "But in a Lisp program I'd very much prefer the
former [bar], since it's easier to understand and to work
with."

To me this raises an important question of the point-of-view
one should have when writing literate programs: Is it correct
to think of oneself as working "in a Lisp program" or should
we think of this first of all as a document?

The noweb <<do-bar>> chunk reference looks like and performs
like a macro expansion in the underlying programming language
even though it is actually done at the time of notangle,
prior to the compilation. From the point-of-view of the static
document perhaps <<do-bar>> is ease to understand. Presumably
one defines <<do-bar>>= because it has a special significance
and/or is a sub-expression that occurs frequently in the
source and deserves to be singled out and explained separately
in the documentation.

But Kai is apparently thinking in terms of working at the lisp
REPL and/or some debugging level where it might be more
convenient to have a name that lisp understands such as 'bar'.
Lisp does not understand the pamphlet format and cannot use
the name 'do-bar'... but maybe it should! When debugging
lisp programs derived from pamphlet source files maybe it
would make sense to have available some "noweb-aware" tools
that allowed simple reference to code chunks? E.g.

  (setq pamphlet-file "vmlisp.lisp.pamphlet")
  (pamphlet-chunk "do-bar")

etc.

Would this allow the lisp programmer/debugger to more easily
cross the gap between her lisp program and the pamphlet
source?

Or am I missing the point of this discussion?

Regards,
Bill Page.

On Thursday, September 21, 2006 4:41 PM Kai Kaminski wrote:

> >...
> >> use lots of small functions. What is the difference between

On Tuesday, September 26, 2006 11:07 AM Tim Daly wrote:

> > This defines 2 functions.

On Tuesday, September 26, 2006 1:35 PM Kai Kaminski wrote:
>
> True.
>
> >>
> >> (defun bar (...)
> >>   (blah blub))
> >>
> >> (defun foo (...)
> >>   (let ((...))
> >>     (bar ...)))
> >>
> >
> > This defines a function and a "top level form".
> > The first expression is evaluated and returns a function.
> > The second expression is immediately evaluated for effect.

> No. The DO-BAR chunk is included in the FOO chunk. Hence
> (BLAH BLUB) ends up in the body of FOO and is not a toplevel
> form. Of course, the two snippets differ in that one defines a
> function and the other does not. But in a Lisp program I'd very
> much prefer the former, since it's easier to understand and to
> work with. If performance is an issue, an INLINE-declaration
> might help.
>
> >> and
> >>
> >> <<foo>>=
> >> (defun foo (...)
> >>   (let ((...))
> >>     <<do-bar>>))
> >> @
> >>
> >> <<do-bar>>=
> >> (blah blub)
> >> @
> >
> > Depending on the situation the value of the top level form
> > could have other side effects.
>
> It is not a toplevel form.

\start
Date: 27 Sep 2006 05:47:03 +0200
From: Gabriel Dos Reis
To: list
Subject: Building Axiom

  The time it takes to build Axiom is prohibitive.  

If the build is done only once a day, that is probably alright.
However, when several iterations are done in a day, it becomes
unbearable.   

What can be done to improve the build time?

-- Gaby
PS: yes, I consider that I have relatively "fast" machines.

\start
Date: Wed, 27 Sep 2006 00:05:20 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Building Axiom

On Tuesday, September 26, 2006 11:47 PM Gabriel Dos Reis wrote:
>
>   The time it takes to build Axiom is prohibitive. 
>
> If the build is done only once a day, that is probably alright.
> However, when several iterations are done in a day, it becomes
> unbearable.  
>
> What can be done to improve the build time?
>
> -- Gaby
> PS: yes, I consider that I have relatively "fast" machines.
>

After eliminating the obvious like avoiding building the docs
and running the tests, the next thing you probably need to do
is find a way to compile SPAD faster. Right now, interpsys is
loaded and compiles a single SPAD file, then quits for each of
1,042 files. In principle it should be possible to compile many
SPAD files in a single call to interpsys - say one call per
layer in the algebra build.

Also, interpsys (really the embedded GCL) runs gcc for each
SPAD compile to compile the generated lisp to object code.
Is there some way to make starting gcc faster?

\start
Date: 27 Sep 2006 08:33:22 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Building Axiom

Bill Page writes:

| On Tuesday, September 26, 2006 11:47 PM Gabriel Dos Reis wrote:
| > 
| >   The time it takes to build Axiom is prohibitive.  
| > 
| > If the build is done only once a day, that is probably alright.
| > However, when several iterations are done in a day, it becomes
| > unbearable.   
| > 
| > What can be done to improve the build time?
| > 
| > -- Gaby
| > PS: yes, I consider that I have relatively "fast" machines.
| > 
| 
| After eliminating the obvious like avoiding building the docs
| and running the tests, the next thing you probably need to do
| is find a way to compile SPAD faster. Right now, interpsys is
| loaded and compiles a single SPAD file, then quits for each of
| 1,042 files. In principle it should be possible to compile many
| SPAD files in a single call to interpsys - say one call per
| layer in the algebra build.

agreed.

| Also, interpsys (really the embedded GCL) runs gcc for each
| SPAD compile to compile the generated lisp to object code.
| Is there some way to make starting gcc faster?

Not that I know of, given current Axiom architecture.

Offline, Camm, Bob Boyer and I have been exploring the idea of
integrating GCL to GCC (long term project).  Bob suggested that we
somehow find a way to have GCL not to start parsing over and over
again the same include file (cmpinclude.h).  
Maybe the precompiled header capability would be an option but I doubt
it gains us a significant speed up in the Axiom case, but who knows;
we have to try. 

\start
Date: 27 Sep 2006 09:28:13 +0200
From: Martin Rubey
To: Gabriel Dos Reis, Bill Page
Subject: Re: Building Axiom

Gabriel Dos Reis writes:

> Bill Page writes:
> 
> | On Tuesday, September 26, 2006 11:47 PM Gabriel Dos Reis wrote:
> | > 
> | >   The time it takes to build Axiom is prohibitive.  
> | > 
> | > If the build is done only once a day, that is probably alright.
> | > However, when several iterations are done in a day, it becomes
> | > unbearable.   
> | > 
> | > What can be done to improve the build time?
> | > 
> | > -- Gaby
> | > PS: yes, I consider that I have relatively "fast" machines.
> | > 
> | 
> | After eliminating the obvious like avoiding building the docs
> | and running the tests, the next thing you probably need to do
> | is find a way to compile SPAD faster. Right now, interpsys is
> | loaded and compiles a single SPAD file, then quits for each of
> | 1,042 files. In principle it should be possible to compile many
> | SPAD files in a single call to interpsys - say one call per
> | layer in the algebra build.

In fact, as I noted already there is a tiny flaw in the current bootstrap
process.

When adding several layers of spad files, as I did for my guessing package, one
has to add each layer one at the time, and has to call make as

make DAASE=$AXIOM/../../int 

Otherwise the newly built algebra files will not be in the database that
interpsys uses: it uses those in ${SRC}/share by default.

Thus, I think the Makefile should really work as follows:

 * for each layer
  
 *   start interpsys
  
 *   compile all files in the layer
  
 *   create the databases

from the second iteration on, of course, it should use the new databases.

HOWEVER: quite certainly, this will make the build process slower, instead of
faster, for two reasons:

* It takes quite some time to create the databases

* compiling slows down when several files are compiled. Certainly this is a
  bug, but I have no idea where to find it...

Of course, the latter can be circumvented by starting a fresh interpsys for
every file that gets compiled, just as it is done now.

I guess, the best way to speed up the build process is to document the
compiler.

\start
Date: 27 Sep 2006 10:52:18 +0200
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Building Axiom

Martin Rubey writes:

[...]

| In fact, as I noted already there is a tiny flaw in the current bootstrap
| process.
| 
| When adding several layers of spad files, as I did for my guessing package, one
| has to add each layer one at the time, and has to call make as
| 
| make DAASE=$AXIOM/../../int 
| 
| Otherwise the newly built algebra files will not be in the database that
| interpsys uses: it uses those in ${SRC}/share by default.

Yes, I noted that too (I did not know you "suffered" from that).  I
found it a bug and postpone it to latter when I have courage to attack
it.  The compiler should use database *built* from the current source.

| Thus, I think the Makefile should really work as follows:
| 
|  * for each layer
|   
|  *   start interpsys
|   
|  *   compile all files in the layer
|   
|  *   create the databases
| 
| from the second iteration on, of course, it should use the new databases.

We should find ways to speed up the database manipulation.

Also, Tim, I noticed that currently the database format is a mix of
two beast.  What is the "right" direction and what are your plans?

| HOWEVER: quite certainly, this will make the build process slower, instead of
| faster, for two reasons:

yes; but we have to speed up the compiler (and probably GCL too).

| * It takes quite some time to create the databases
| 
| * compiling slows down when several files are compiled. Certainly this is a
|   bug, but I have no idea where to find it...
| 
| Of course, the latter can be circumvented by starting a fresh interpsys for
| every file that gets compiled, just as it is done now.

but, that is very slow.  The compiler should be able to compiler
several files in row.

| 
| I guess, the best way to speed up the build process is to document the
| compiler.

Hear! Hear! Hear!

\start
Date: Wed, 27 Sep 2006 06:19:46 -0500 (CDT)
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: Google Code repository

On Thu, 21 Sep 2006, Alfredo Portes wrote:

| With the space we have now, one thing we can do is have Silver in the trunk and
| build-improvements in a branch and go from there if Google increases the size.
| Do you think that is ok?

Yes, definitely.

| > How's this? http://code.google.com/p/axiom
| >
|
| Thank you, it looks very good.

same here.

\start
Date: Wed, 27 Sep 2006 06:21:38 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: Google Code repository

On Thu, 21 Sep 2006, Page, Bill wrote:

| So it's true. Subversion does like me...

:-/

| BTW, what release of the SourceForge repository is this?
| I notice that
|
|  A    axiom.build-improvements\zips\tla-1.1.tar.gz
|
| is still in this archive, but I am quite sure Gaby deleted it last
| night.

That is correct.

\start
Date: 27 Sep 2006 13:24:53 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Axiom memory usage and GCL

Gabriel Dos Reis writes:

[...]

| I've been doing a binary search (which gives me a chance to appreciate
| changetset commits); I may be near the commit that caused the problem,
| but I really wish Axiom were faster to compile.  I hope to be at a
| point where I can start parallel make, but I first need to get this
| issue out of the way.

I traced the issue down to an obscure dependency in the toplevel
Makefile. Axiom build on SF x86-linux1 has been going on for a while
now.  It is at algebra layer 13, but I don't think it would be completed
before I take off to office.  This is the first time I'm having a
build of axiom.build-improvements going that far on a debian-based 
system.  I suspect that is encouraging.

\start
Date: Wed, 27 Sep 2006 09:00:18 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Building Axiom

>   The time it takes to build Axiom is prohibitive.  
> 
> If the build is done only once a day, that is probably alright.
> However, when several iterations are done in a day, it becomes
> unbearable.   
> 
> What can be done to improve the build time?
> 
> -- Gaby
> PS: yes, I consider that I have relatively "fast" machines.

three possibilities.... first, the whole point of using 'make'
is that you don't have to do a full build except the first time.
unfortunately you are working on the makefiles which is a very
rare situation. i know it is painful (from experience) but it
would be useless to optimize build times since almost no-one
else will have the problem.

second, do machine-parallel builds. fix a problem on one machine
and while it builds, move to the next machine.

third, have the build check for obj/sys/bin/lisp and if it exists
skip the lisp build step (unless you are hacking that makefile).

\start
Date: Wed, 27 Sep 2006 11:30:45 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: plone

Ralf,

On Wednesday, September 27, 2006 7:50 AM you wrote:
>
> I'll probably need some time to bring me up-to-date.
>

If you have questions about Plone, ZWiki or Zope, please feel
free to ask. I will try to help.

> As I have learned by now, there are several different programs
> that implement a wiki concept (Zwiki, Twiki, MediaWiki, ...
> http://en.wikipedia.org/wiki/Comparison_of_wiki_software
> ). Was there any good reason to choose Zwiki for Axiom?
>

In retrospect I think there was no especially good reason to
choose ZWiki/LatexWiki - only the timing and a matter of
convenience. Plus it turned out that the maintainer of the LaTeX
extension for ZWiki (Bob McElrath) happened also to be interested
in Axiom. :-)

It is amusing to me that ZWiki is not shown in this comparison.
At the time (almost three years ago) there were very few other
wiki's that included support for LaTeX. On another project I
had already had some experience with Plone and Zope. ZWiki is
written in Python using Zope as the web application server and
object-oriented database. I consider this a "higher-level"
application development environment compared to some other
scripting languages and choice of database or file system. But
this is large a subject matter of "taste".

> The reason, I am asking is that we currently run Twiki at RISC,
> but I am not so convinced whether it is better/worse than Zwiki
> or MediaWiki. (It's a pain to learn just another wiki syntax...)
>

I have looked at Twiki, and used both MediaWiki and Moinmoin. I
think all three of these now have optional LaTeX support.

https://twiki.cern.ch/twiki/bin/view/TWiki/MathModePlugin
http://meta.wikimedia.org/wiki/MediaWiki_math_markup
http://johannes.sipsolutions.net/Projects/new-moinmoin-latex

And they all could probably quite easily be adapted to interface
with Axiom and other computer algebra packages the way that
ZWiki/MathAction does now.

MediaWiki is famous because it is the software that runs Wikipedia.
The Sage project is using Moinmoin possibly because it is written
in Python which is also the implementation language for Sage. But
Moinmoin does not use Zope so it is simpler in that respect.

The "wiki syntax" in all of these systems was originally intended
to be very simple to use so as not to represent any barrier for
new users, but this goal has in most cases been abandoned because
it turns out that people do care about the format. Most of these
systems have some form of "WYSIWYG page editing" which is supposed
to be easy for new users to create nicely formatted pages. Moinmoin
in particular has a very nice editor.  ZWiki has this as an option
but I have turned it off because unfortunately it does not work
properly with the LatexWiki embedded LaTeX commands.

Actually I am rather surprised by the relatively slow rate of
adoption of the wiki concept but on the other hand, after three
years of watching closely it is clear to me that it is very
gradually growing in popularity - not declining.

\start
Date: 27 Sep 2006 19:37:11 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Building Axiom

Tim Daly writes:

| >   The time it takes to build Axiom is prohibitive.  
| > 
| > If the build is done only once a day, that is probably alright.
| > However, when several iterations are done in a day, it becomes
| > unbearable.   
| > 
| > What can be done to improve the build time?
| > 
| > -- Gaby
| > PS: yes, I consider that I have relatively "fast" machines.
| 
| three possibilities.... first, the whole point of using 'make'
| is that you don't have to do a full build except the first time.

Make isn't the problem.  As the system currently stands, when
something is modified it is recommended to delete the build tree and
start afresh -- doing otherwise only brings false positives (or
negatives depending on how you count).  I've been bitten enough to
know that for the moment, it is always the "first time".

| unfortunately you are working on the makefiles which is a very
| rare situation. i know it is painful (from experience) but it
| would be useless to optimize build times since almost no-one
| else will have the problem.

I doubt I'm alone; or if I'm alone, I doubt I'll stay alone for long
time.  Unless Axiom stays with only 2 "coders", I suspect this issue
needs to be addressed somehow. I have some students who will be poking at
various parts of the system.  I would hate they spend most of their
time waiting for the compiler. 

\start
Date: 28 Sep 2006 02:12:58 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Axiom memory usage and GCL

Gabriel Dos Reis writes:

[...]

| | > I hope to be at a point where I can start parallel make, but
| | > I first need to get this issue out of the way.
| | 
| | Do you suspect some Axiom coding error??? Or are you talking
| | about a different issue. It is no longer clear to me.
| 
| Before blaming Axiom, I prefer to blame myself first -- the makefiles
| are very tricky and what can appear as a small change in a Makefile
| can have far reaching fallouts in Lisp codes (especially in src/interp
| where I'm having this problem) because of very poor or lack of
| abstractions. 

I solved this issue:  It was me forgtetting to specify $(ENV) before
calling $(MAKE).  Which reminds why why I did not appreciate passing
those variables on command line in the first place.

Now, I can ressurect my work on the boot directory (which I partly
lost while digging this issue).

\start
Date: Wed, 27 Sep 2006 22:03:09 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Google Code repository
Cc: Gabriel Dos Reis

Alfredo and Gaby,

I think we should get the Google repository reloaded ASAP.

On Wednesday, September 27, 2006 7:20 AM Gaby wrote:
>
> On Thu, 21 Sep 2006, Alfredo Portes wrote:
>
> | With the space we have now, one thing we can do is have
> | Silver in the trunk and build-improvements in a branch
> | and go from there if Google increases the size.
> | Do you think that is ok?
>
> Yes, definitely.
>

I also agree. But to do that we *must* get the Google Code
masters to reset our svn repository on Google back to zero.
Since we do not have svnadmin access to the repository this
is apparently something that we can not do ourselves. Any
change that we make (including deletions!) do not result any
any decrease in the amount of space already used in the
repository files. We need to start again from an empty
repository state.

Alfredo, will you please contact Google and ask them to reset
it?

I have SVK running reliably now on the axiom-developer.org
server. With SVK it is possible to transfer an entire repository
from one location to another without having svnadmin export
import access. For example as described here:

http://svk.elixus.org/?RecoverSVNMasterFromSVKMirror

I would like to try this, but first we need to have an empty
repository on Google and not just one that "appears" to be
that way. :-)

Meanwhile I am still having fun using Tailor to convert from one
type of repository to another svn<->darcs<->hg and experimenting
with mercurial versus darcs...

If SVK doesn't work out, then I am sure that I can persuade Tailor
to also do svn <-> svn from one location to another. But since
SVK is native to svn, I think we should try that first. Both of
these can be run periodically via crontab so that no manual
intervention would be involved in keeping at least one-way
mirrors up to date. (Two-way involves the potential to that
one might have to manually resolve conflicts.)

I am still struggling with get svn installed in server mode
on axiom-developer.org but I hope to have more time to work
on that soon.

\start
Date: Wed, 27 Sep 2006 23:36:13 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Google Code repository
Cc: Gabriel Dos Reis

> Alfredo, will you please contact Google and ask them to reset
> it?

Sure, I will. I do not know if Gaby can also contact the person he
knows in google.

\start
Date: 28 Sep 2006 13:54:08 +0200
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: re: Google Code repository

Alfredo Portes writes:

| Bill,
| 
| > Alfredo, will you please contact Google and ask them to reset
| > it?
| 
| Sure, I will. I do not know if Gaby can also contact the person he
| knows in google.

I contacted him.  He is not directly related to the hosting team but
did ask them.  As you reported, the team was concerned about storing
some tarballs in the Axiom sources.  

For this particular issue of "emptying" the repo, do you want me to
contact them or do you prefer to handle it?

\start
Date: Thu, 28 Sep 2006 10:07:57 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: re: Google Code repository

On 28 Sep 2006 13:54:08 +0200, Gabriel Dos Reis
Gabriel Dos Reis wrote:
> Alfredo Portes writes:
>
> | Bill,
> |
> | > Alfredo, will you please contact Google and ask them to reset
> | > it?
> |
> | Sure, I will. I do not know if Gaby can also contact the person he
> | knows in google.
>
> I contacted him.  He is not directly related to the hosting team but
> did ask them.  As you reported, the team was concerned about storing
> some tarballs in the Axiom sourcest.
>
> For this particular issue of "emptying" the repo, do you want me to
> contact them or do you prefer to handle it?

Thanks Gaby. I already emailed them, but no response yet.

\start
Date: Thu, 28 Sep 2006 10:49:10 -0400
From: Alfredo Portes
To: Bill Page, Gabriel Dos Reis, 
Subject: Fwd: [M#73697383] Re: Disk-quota Request

Hi Bill,

This is an email sent by Ben Collins from Google. The repository
has been reseted.

Let me know please if it works fine.

Regards,

Alfredo

---------- Forwarded message ----------
From: Ben Collins-Sussman

Repository has been reset to revision 0.  Quota is still 250MB.

On 9/27/06, Alfredo Portes wrote:
> Hi Mr. Collins-Sussman,
>
> I would like to request you for a reset of the Axiom
> repository on your servers. We had certain problems
> when committing the initial data. I would like to know
> if this is possible keeping the current available space
> of 250 MB.
>
> Thank you very much, and we apologize for any
> inconvenience this may cause.

\start
Date: Thu, 28 Sep 2006 17:45:08 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: patch to daase  (probe-file)

Bill Page wrote:

[...]

> The most serious and difficult problem occurred in Axiom's database 
> code. There is some incorrect usage of the lisp 'probe-file'
> function that no longer corresponds the way 'probe-file' works
> in gcl (since gcl-2.6.7). This is actually a bug in the current
> Axiom linux source distribution as well! This might explain the
> problems that we had recently with trying to compile Martin's
> Rubey's new 'guess' package since it means that generating the
> new databases might fail.

[...]

> This patch corrects some incorrect usage of 'probe-file' in the 
> Axiom database code. !! Very important !!

> diff -rN -u old-axiom--windows--1-1/src/interp/daase.lisp.pamphlet
> new-axiom--windows--1-1/src/interp/daase.lisp.pamphlet
> --- old-axiom--windows--1-1/src/interp/daase.lisp.pamphlet      Wed Sep
> 20 21:32:48 2006
> +++ new-axiom--windows--1-1/src/interp/daase.lisp.pamphlet      Wed Sep
> 20 21:33:06 2006
> @@ -840,7 +840,7 @@
>   (let (thisdir nrlibs asos asys libs object only dir key 
>        (|$forceDatabaseUpdate| t) noexpose)
>    (declare (special |$forceDatabaseUpdate|))
> -  (setq thisdir (namestring (probe-file ".")))
> +  (setq thisdir (namestring (truename ".")))
>    (setq noexpose nil)
>    (multiple-value-setq (only dir noexpose) (processOptions options))
>       ;don't force exposure during database build

Already applied in Gold and build-improvements

> @@ -1106,12 +1106,12 @@
>    (setq *compressvector* nil)
>    (withSpecialConstructors)
>    (localdatabase nil
> -     (list (list '|dir| (namestring (probe-file "./")) ))
> +     (list (list '|dir| (namestring (truename "./")) ))
>       'make-database)

Already applied in Gold and build-improvements

>    (dolist (dir dirlist)
>           (localdatabase nil 
>                          (list (list '|dir| 
> -                                    (namestring (probe-file 
> +                                    (namestring (truename 
>                                                   (format nil "./~a" 
>                                                           dir)))))
>                          'make-database))

Not applied. Is it necessary (I do not have time to look at it) ?
It seems to me if 'dir' is a directory. Bill, or any other, do you
know how we can trigger this bug (in the interpreter for example)?

\start
Date: Thu, 28 Sep 2006 17:51:18 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: Re: patch to daase  (probe-file)

[...]
> Not applied. Is it necessary (I do not have time to look at it) ?

s/I do not have time to look at it/I do not have time to look at it
actually/

Greg

> It seems to me if 'dir' is a directory. Bill, or any other, do you
> know how we can trigger this bug (in the interpreter for example)?

\start
Date: Thu, 28 Sep 2006 12:29:40 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: RE: patch to daase  (probe-file)

Greg,

Thanks for looking at this patch.

On Thursday, September 28, 2006 11:45 AM you wrote:
>
> Bill Page wrote:
>
> [...]
>
> > This patch corrects some incorrect usage of 'probe-file' in the
> > Axiom database code. !! Very important !!
>
> diff -rN -u old-axiom--windows--1-1/src/interp/daase.lisp.pamphlet
> new-axiom--windows--1-1/src/interp/daase.lisp.pamphlet
> --- old-axiom--windows--1-1/src/interp/daase.lisp.pamphlet Wed Sep20 =
21:32:48 2006
> +++ new-axiom--windows--1-1/src/interp/daase.lisp.pamphlet Wed Sep20 =
21:33:06 2006
> ...
> >    (dolist (dir dirlist)
> >           (localdatabase nil
> >                          (list (list '|dir|
> > -                                    (namestring (probe-file
> > +                                    (namestring (truename
> >                                                   (format
> nil "./~a"
> >                                                           dir)))))
> >                          'make-database))
>
> Not applied. Is it necessary (I do not have time to look at it)?
> It seems to me if 'dir' is a directory. Bill, or any other, do
> you know how we can trigger this bug (in the interpreter for
> example)?
>

Since gcl-2.6.7 'probe-file' in gcl returns Nil if it's argument
is a directory so any place that it was used in the Axiom Lisp
code for it's side-effect of expanding a directory name to it's
truename would be in error.

These patches had not be previously applied to the Windows
version of the Axiom source because it was still bases on
gcl-2.6.5.

'make-databases' is not used in the Axiom interpreter. It is
only used during the build from source. It is a function with
two parameters:

interp/daase.lisp.pamphlet:

  (defun make-databases (ext dirlist) ...

and the affected code is:

  (localdatabase nil
     (list (list '|dir| (namestring (truename "./")) ))
     'make-database)
  (dolist (dir dirlist)
          (localdatabase nil
                         (list (list '|dir|
                                     (namestring (probe-file
                                                  (format nil "./~a"
                                                          dir)))))
                         'make-database))

...

But in etc/Makefile.pamphlet, which is the only place where
make=databases is called, we see:

  echo ')lisp (make-databases "" nil)' | ${INTERPSYS} )

so the net effect is that the above bug is not manifest in the
current build but this patch is desirable for possible future
application and consistency.

\start
Date: Thu, 28 Sep 2006 19:13:23 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: [M#73697383] Re: Disk-quota Request
Cc: Ben Collins-Sussman, Gabriel Dos Reis

Alfredo, Gaby, et al.

On Thursday, September 28, 2006 10:49 AM Alfredo Portes wrote:
>
> This is an email sent by Ben Collins from Google. The
> repository has been reseted.
>
> Let me know please if it works fine.
>

Unfortunately it does not work. :(

After several attempts using SVK, first trying the mirroring
method that I mentioned earlier, and then later using just a
simple 'commit' of the most recent revision of trunk from
the Axiom Silver, the result is the same error message:

  "Could not write svndiff to temp file: No space left on device"

My conclusion is that "if" we really do have 250Mbytes for the
repository on Google Code, then there must be something else
wrong with the system configuration because it certainly should
be possible to commit at least the most recent revision of trunk.

In those cases were I could get feedback from svn while it was
working, it seemed that this error occurred while trying to commit
a single large file from the zips directory - probably the gcl
tarball (about 20 Mbytes). That's large but not *that* large...
I wonder if the Google server is using some very limited
temporary space, e.g. a overly small /tmp volume or something
like that?

Another thought is perhaps svn is not properly recognizing the
tarball as binary? I am not sure if it makes sense for svn to
be writing an 'svndiff' for such a file.

I don't really know where to go from here on Google Code. It
is very awkward not having shell and svnadmin access to that
server.

On the axiom-developer.org server I am continuing to work towards
setting up our own svn server while subversion seems to keep
trying to "subvert" me at almost every step! ;) But setting up
complete mirrors of our SourceForge subversion archive with both
Darcs and Mercurial using Tailor to automatically keep them in
sync only took a couple of hours.

Regards,
Bill Page.


>
> ---------- Forwarded message ----------
> From: Ben Collins-Sussman
> Date: Sep 28, 2006 10:40 AM
> Subject: Re: [M#73697383] Re: Disk-quota Request
> To: Alfredo Portes
>
>
> Repository has been reset to revision 0.  Quota is still 250MB.
>
>
> On 9/27/06, Alfredo Portes wrote:
> > Hi Mr. Collins-Sussman,
> >
> > I would like to request you for a reset of the Axiom
> > repository on your servers. We had certain problems
> > when committing the initial data. I would like to know
> > if this is possible keeping the current available space
> > of 250 MB.
> >
> > Thank you very much, and we apologize for any
> > inconvenience this may cause.

\start
Date: Thu, 28 Sep 2006 23:10:10 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: [M#73697383] Re: Disk-quota Request
Cc: Ben Collins-Sussman, Gabriel Dos Reis

On Thursday, September 28, 2006 7:13 PM I wrote:
>
> After several attempts using SVK, first trying the mirroring
> method that I mentioned earlier, and then later using just a
> simple 'commit' of the most recent revision of trunk from
> the Axiom Silver, the result is the same error message:
>
>   "Could not write svndiff to temp file: No space left on
>    device"
> ...
> In those cases were I could get feedback from svn while it was
> working, it seemed that this error occurred while trying to
> commit a single large file from the zips directory - probably
> the gcl tarball (about 20 Mbytes). That's large but not *that*
> large... I wonder if the Google server is using some very
> limited temporary space, e.g. a overly small /tmp volume or
> something like that?
>

Actually I now suspect the problem occurs on our side of
the process - not Google's. Our axiom-developer.org server
is configured with a very small /tmp (tmpfs) space - only
16 Mbytes! If svn is trying to stuff all of the tarball into
this small space, it is bound to fail.

Many applications allow one to define an environment variable
to override the placement of files in /tmp, e.g.

  export TEMP=/anywhere/else

I was not able to determine if this is possible with svn/SVK
or not but I am running another batch job now with this
option to see if my commit will run to completion.

Stay tuned...

\start
Date: 28 Sep 2006 22:19:08 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] tidy build-depsys and build-interpsys

build-depsys is supposed to be an interface between the lisp world and
the "makefile" world.  However, it lacks abstraction.  Basically, it
takes (among other things) six parameters for directories, just to use
only one to build a path for some files to lookup>  It does so bt
concatening that directory path with "/interp/".  It could just take
that directory aas argument.  Fixed thusly.
build-interpsys has similr behaviour.

built and tested on an i868-pc-linux-gnu.

-- Gaby
*** ChangeLog.build-improvements	(revision 15870)
--- ChangeLog.build-improvements	(local)
***************
*** 1,3 ****
--- 1,8 ----
+ 2006-09-28  Gabriel Dos Reis  Gabriel Dos Reis
+ 
+ 	* config/setup-dep.mk (Makefile): Don't depend directly on
+ 	$(top_srcdir)/configure.
+ 
  2006-09-27  Gabriel Dos Reis  Gabriel Dos Reis
  
  	* config/var-def.mk (AXIOM): Move from toplevel Makefile.
*** config/setup-dep.mk	(revision 15870)
--- config/setup-dep.mk	(local)
*************** $(srcdir)/Makefile.in: $(srcdir)/Makefil
*** 43,50 ****
  	cd $(srcdir) && notangle -t8 Makefile.pamphlet > ./Makefile.in
  
  .PRECIOUS: Makefile
! Makefile: $(srcdir)/Makefile.in $(top_srcdir)/configure \
! 	  $(top_srcdir)/config/var-def.mk \
  	  $(top_srcdir)/config/setup-dep.mk \
  	  $(abs_top_builddir)/config.status
  	cd $(abs_top_builddir) && $(SHELL) ./config.status $(subdir)$@
--- 43,49 ----
  	cd $(srcdir) && notangle -t8 Makefile.pamphlet > ./Makefile.in
  
  .PRECIOUS: Makefile
! Makefile: $(srcdir)/Makefile.in $(top_srcdir)/config/var-def.mk \
  	  $(top_srcdir)/config/setup-dep.mk \
  	  $(abs_top_builddir)/config.status
  	cd $(abs_top_builddir) && $(SHELL) ./config.status $(subdir)$@
*** src/interp/ChangeLog.build-improvements	(revision 15870)
--- src/interp/ChangeLog.build-improvements	(local)
***************
*** 1,3 ****
--- 1,13 ----
+ 2006-09-28  Gabriel Dos Reis  Gabriel Dos Reis
+ 
+ 	* util.lisp.pamphlet (build-depsys): Replace last six parameters
+ 	with only indicating the build directory.
+ 	(make_depsys): Likewise.
+ 	(build-interpsys): Lose last six parameters.
+ 	* Makefile.pamphlet (${DEPSYS}): Adjust call to build-depsys.
+ 	($(SAVESYS)) Adjust call to build-interpsys.
+ 	* debugsys.lisp.pamphlet: Likewise.
+ 
  2006-09-26  Gabriel Dos Reis  Gabriel Dos Reis
  
  	* Makefile.pamphlet (all): Create stamp file.
*** src/interp/Makefile.in	(revision 15870)
--- src/interp/Makefile.in	(local)
*************** ${SAVESYS}:	${DEPSYS} ${OBJS} ${OUT}/boo
*** 289,295 ****
  	@ echo '(in-package "BOOT")' >> ${OUT}/makeint.lisp
  	@ touch ${TIMESTAMP}
  	@ echo '${YEARWEEK}' >> ${OUT}/makeint.lisp
! 	@ echo '(build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "%", ${OPOBJS}))) (quote ($(patsubst %, "%", ${OCOBJS}))) (quote ($(patsubst %, "%", ${BROBJS}))) (quote ($(patsubst %, "%", ${TRANOBJS}))) (quote ($(patsubst %, "%", ${NAGBROBJS}))) (quote ($(patsubst %, "%", ${ASAUTO})))  "${SPAD}"  "${LSP}" "$(axiom_src_srcdir)" "${INT}" "${OBJ}" "${MNT}" "${SYS}")' >> ${OUT}/makeint.lisp
  	@ echo '(in-package "SCRATCHPAD-COMPILER")' >> ${OUT}/makeint.lisp
  #	@ echo '(|shoeInternFile| "${MNT}/${SYS}/doc/msgs/co-eng.msgs")' >> ${OUT}/makeint.lisp
  	@ echo '(boot::set-restart-hook)' >> ${OUT}/makeint.lisp
--- 289,295 ----
  	@ echo '(in-package "BOOT")' >> ${OUT}/makeint.lisp
  	@ touch ${TIMESTAMP}
  	@ echo '${YEARWEEK}' >> ${OUT}/makeint.lisp
! 	@ echo '(build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "%", ${OPOBJS}))) (quote ($(patsubst %, "%", ${OCOBJS}))) (quote ($(patsubst %, "%", ${BROBJS}))) (quote ($(patsubst %, "%", ${TRANOBJS}))) (quote ($(patsubst %, "%", ${NAGBROBJS}))) (quote ($(patsubst %, "%", ${ASAUTO})))  "${SPAD}")' >> ${OUT}/makeint.lisp
  	@ echo '(in-package "SCRATCHPAD-COMPILER")' >> ${OUT}/makeint.lisp
  #	@ echo '(|shoeInternFile| "${MNT}/${SYS}/doc/msgs/co-eng.msgs")' >> ${OUT}/makeint.lisp
  	@ echo '(boot::set-restart-hook)' >> ${OUT}/makeint.lisp
*************** ${DEPSYS}:	${DEP} ${OUT}/sys-pkg.${LISP}
*** 326,332 ****
  	@ echo '(load "${OUT}/bookvol5")' >> ${OUT}/makedep.lisp
  	@ echo '(load "${OUT}/util")' >> ${OUT}/makedep.lisp
  	@ echo '(in-package "BOOT")' >> ${OUT}/makedep.lisp
! 	@ echo '(build-depsys (quote ($(patsubst %, "%", ${DEP}))) "${SPAD}" "${GCLDIR}" "$(axiom_src_srcdir)" "${INT}" "${OBJ}" "${MNT}" "${SYS}")' >> ${OUT}/makedep.lisp
  	@ echo '(unless (probe-file "${OUT}/postpar.$(OBJEXT)") (compile-file "${OUT}/postpar.${LISP}" :output-file "${OUT}/postpar.$(OBJEXT)"))' >> ${OUT}/makedep.lisp
  	@ echo '(load "${OUT}/postpar")' >> ${OUT}/makedep.lisp
  	@ echo '(unless (probe-file "${OUT}/parse.$(OBJEXT)") (compile-file "${OUT}/parse.${LISP}" :output-file "${OUT}/parse.$(OBJEXT)"))' >> ${OUT}/makedep.lisp
--- 326,332 ----
  	@ echo '(load "${OUT}/bookvol5")' >> ${OUT}/makedep.lisp
  	@ echo '(load "${OUT}/util")' >> ${OUT}/makedep.lisp
  	@ echo '(in-package "BOOT")' >> ${OUT}/makedep.lisp
! 	@ echo '(build-depsys (quote ($(patsubst %, "%", ${DEP}))) "${SPAD}" "$(builddir)")' >> ${OUT}/makedep.lisp
  	@ echo '(unless (probe-file "${OUT}/postpar.$(OBJEXT)") (compile-file "${OUT}/postpar.${LISP}" :output-file "${OUT}/postpar.$(OBJEXT)"))' >> ${OUT}/makedep.lisp
  	@ echo '(load "${OUT}/postpar")' >> ${OUT}/makedep.lisp
  	@ echo '(unless (probe-file "${OUT}/parse.$(OBJEXT)") (compile-file "${OUT}/parse.${LISP}" :output-file "${OUT}/parse.$(OBJEXT)"))' >> ${OUT}/makedep.lisp
*** src/interp/Makefile.pamphlet	(revision 15870)
--- src/interp/Makefile.pamphlet	(local)
*************** ${DEPSYS}:	${DEP} ${OUT}/sys-pkg.${LISP}
*** 798,804 ****
  	@ echo '(load "${OUT}/bookvol5")' >> ${OUT}/makedep.lisp
  	@ echo '(load "${OUT}/util")' >> ${OUT}/makedep.lisp
  	@ echo '(in-package "BOOT")' >> ${OUT}/makedep.lisp
! 	@ echo '(build-depsys (quote ($(patsubst %, "%", ${DEP}))) "${SPAD}" "${GCLDIR}" "$(axiom_src_srcdir)" "${INT}" "${OBJ}" "${MNT}" "${SYS}")' >> ${OUT}/makedep.lisp
  	@ echo '(unless (probe-file "${OUT}/postpar.$(OBJEXT)") (compile-file "${OUT}/postpar.${LISP}" :output-file "${OUT}/postpar.$(OBJEXT)"))' >> ${OUT}/makedep.lisp
  	@ echo '(load "${OUT}/postpar")' >> ${OUT}/makedep.lisp
  	@ echo '(unless (probe-file "${OUT}/parse.$(OBJEXT)") (compile-file "${OUT}/parse.${LISP}" :output-file "${OUT}/parse.$(OBJEXT)"))' >> ${OUT}/makedep.lisp
--- 798,804 ----
  	@ echo '(load "${OUT}/bookvol5")' >> ${OUT}/makedep.lisp
  	@ echo '(load "${OUT}/util")' >> ${OUT}/makedep.lisp
  	@ echo '(in-package "BOOT")' >> ${OUT}/makedep.lisp
! 	@ echo '(build-depsys (quote ($(patsubst %, "%", ${DEP}))) "${SPAD}" "$(builddir)")' >> ${OUT}/makedep.lisp
  	@ echo '(unless (probe-file "${OUT}/postpar.$(OBJEXT)") (compile-file "${OUT}/postpar.${LISP}" :output-file "${OUT}/postpar.$(OBJEXT)"))' >> ${OUT}/makedep.lisp
  	@ echo '(load "${OUT}/postpar")' >> ${OUT}/makedep.lisp
  	@ echo '(unless (probe-file "${OUT}/parse.$(OBJEXT)") (compile-file "${OUT}/parse.${LISP}" :output-file "${OUT}/parse.$(OBJEXT)"))' >> ${OUT}/makedep.lisp
*************** ${SAVESYS}:	${DEPSYS} ${OBJS} ${OUT}/boo
*** 879,885 ****
  	@ echo '(in-package "BOOT")' >> ${OUT}/makeint.lisp
  	@ touch ${TIMESTAMP}
  	@ echo '${YEARWEEK}' >> ${OUT}/makeint.lisp
! 	@ echo '(build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "%", ${OPOBJS}))) (quote ($(patsubst %, "%", ${OCOBJS}))) (quote ($(patsubst %, "%", ${BROBJS}))) (quote ($(patsubst %, "%", ${TRANOBJS}))) (quote ($(patsubst %, "%", ${NAGBROBJS}))) (quote ($(patsubst %, "%", ${ASAUTO})))  "${SPAD}"  "${LSP}" "$(axiom_src_srcdir)" "${INT}" "${OBJ}" "${MNT}" "${SYS}")' >> ${OUT}/makeint.lisp
  	@ echo '(in-package "SCRATCHPAD-COMPILER")' >> ${OUT}/makeint.lisp
  #	@ echo '(|shoeInternFile| "${MNT}/${SYS}/doc/msgs/co-eng.msgs")' >> ${OUT}/makeint.lisp
  	@ echo '(boot::set-restart-hook)' >> ${OUT}/makeint.lisp
--- 879,885 ----
  	@ echo '(in-package "BOOT")' >> ${OUT}/makeint.lisp
  	@ touch ${TIMESTAMP}
  	@ echo '${YEARWEEK}' >> ${OUT}/makeint.lisp
! 	@ echo '(build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "%", ${OPOBJS}))) (quote ($(patsubst %, "%", ${OCOBJS}))) (quote ($(patsubst %, "%", ${BROBJS}))) (quote ($(patsubst %, "%", ${TRANOBJS}))) (quote ($(patsubst %, "%", ${NAGBROBJS}))) (quote ($(patsubst %, "%", ${ASAUTO})))  "${SPAD}")' >> ${OUT}/makeint.lisp
  	@ echo '(in-package "SCRATCHPAD-COMPILER")' >> ${OUT}/makeint.lisp
  #	@ echo '(|shoeInternFile| "${MNT}/${SYS}/doc/msgs/co-eng.msgs")' >> ${OUT}/makeint.lisp
  	@ echo '(boot::set-restart-hook)' >> ${OUT}/makeint.lisp
*** src/interp/debugsys.lisp.pamphlet	(revision 15870)
--- src/interp/debugsys.lisp.pamphlet	(local)
*************** loaded by hand we need to establish a va
*** 247,259 ****
     ())
    (list 
     (thesymb "/int/interp/ax.clisp"))
!   (system:getenv "AXIOM")
!   "/lsp"
!   "/src"
!   "/int"
!   "/obj"
!   "/mnt"
!   *sys*)
  (in-package "SCRATCHPAD-COMPILER")
  (boot::set-restart-hook)
  (in-package "BOOT")
--- 247,253 ----
     ())
    (list 
     (thesymb "/int/interp/ax.clisp"))
!   (system:getenv "AXIOM"))
  (in-package "SCRATCHPAD-COMPILER")
  (boot::set-restart-hook)
  (in-package "BOOT")
*** src/interp/util.lisp.pamphlet	(revision 15870)
--- src/interp/util.lisp.pamphlet	(local)
*************** the necessary functions and macros to co
*** 38,51 ****
  image but it does not have any autoload triggers or databases
  loaded.
  <<build-depsys>>=
! (defun build-depsys (load-files spad lsp src int obj mnt sys)
  #+:CCL
    (setq *package* (find-package "BOOT"))
  #+:AKCL
    (in-package "BOOT")
    (push :oldboot *features*)
    (mapcar #'load load-files)
!   (make-depsys lsp src int obj mnt sys)
    (initroot spad)
    #+:AKCL
    (init-memory-config :cons 1000 :fixnum 400 :symbol 1000 :package 16
--- 38,51 ----
  image but it does not have any autoload triggers or databases
  loaded.
  <<build-depsys>>=
! (defun build-depsys (load-files spad build-interp-dir)
  #+:CCL
    (setq *package* (find-package "BOOT"))
  #+:AKCL
    (in-package "BOOT")
    (push :oldboot *features*)
    (mapcar #'load load-files)
!   (make-depsys build-interp-dir)
    (initroot spad)
    #+:AKCL
    (init-memory-config :cons 1000 :fixnum 400 :symbol 1000 :package 16
*************** into the image. It used to read:
*** 74,92 ****
     (compiler::emit-fn t)
  \end{verbatim}
  <<make-depsys>>=
! (defun make-depsys (lsp src int obj mnt sys)
    ;; perform system initializations for building a starter system
    (init-memory-config)
    #+:AKCL
    (let ()
     (mapcar
       #'load
!      (directory (concatenate 'string obj "/" sys "/interp/*.fn")))
     (with-open-file
!     (out (concatenate 'string obj "/" sys "/interp/proclaims.lisp" )
        :direction :output)
       (compiler::make-proclaims out))
!    (load (concatenate 'string obj "/" sys "/interp/proclaims.lisp")))
    )
  
  @
--- 74,92 ----
     (compiler::emit-fn t)
  \end{verbatim}
  <<make-depsys>>=
! (defun make-depsys (build-interp-dir)
    ;; perform system initializations for building a starter system
    (init-memory-config)
    #+:AKCL
    (let ()
     (mapcar
       #'load
!      (directory (concatenate 'string build-interp-dir "/*.fn")))
     (with-open-file
!     (out (concatenate 'string build-interp-dir "/proclaims.lisp" )
        :direction :output)
       (compiler::make-proclaims out))
!    (load (concatenate 'string build-interp-dir "/proclaims.lisp")))
    )
  
  @
*************** loads the databases, sets up autoload tr
*** 128,135 ****
  After this function is called the image is clean and can be saved.
  <<build-interpsys>>=
  (defun build-interpsys (load-files parse-files comp-files browse-files
! 	     translate-files nagbr-files asauto-files
!              spad lsp src int obj mnt sys)
    (push :oldboot *features*)
    (initroot spad)
    #+:AKCL
--- 128,134 ----
  After this function is called the image is clean and can be saved.
  <<build-interpsys>>=
  (defun build-interpsys (load-files parse-files comp-files browse-files
! 	     translate-files nagbr-files asauto-files spad)
    (push :oldboot *features*)
    (initroot spad)
    #+:AKCL

\start
Date: Fri, 29 Sep 2006 14:14:07 +0200
From: Ralf Hemmecke
To: list
Subject: Hyperdoc problem in patch-49

Type UnivariateTaylorSeries into the browse filed of HyperDoc then press
"Constructors". FINE.

Now try the same thing with

   UnivariateTaylor*

and you get the message "There is no constructor matching pattern 
"UnivariateTaylor*"

Anybody else experiences that problem?

\start
Date: 29 Sep 2006 14:41:43 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Hyperdoc problem in patch-49

Ralf Hemmecke writes:

> Type UnivariateTaylorSeries into the browse filed of HyperDoc then press
> "Constructors". FINE.
> 
> Now try the same thing with
> 
>    UnivariateTaylor*
> 
> and you get the message "There is no constructor matching pattern
> "UnivariateTaylor*"
> 
> Anybody else experiences that problem?

As far as I recall, that never worked. Hm, it does seem to work for operations
and categories...

\start
Date: Fri, 29 Sep 2006 07:19:19 -0500
From: Ben Collins-Sussman
To: Bill Page
Subject: Re: [M#73697383] Re: Disk-quota Request
Cc: Gabriel Dos Reis

Yes, this is definitely a client-side error.  When the svn client
sends a file to the server (during a commit), it uses xdelta to
diff-encode the data into a temporary file, then the neon library (an
http client library) pushes the tmpfile over the wire.

As an experiment, you might want to create a local repository, and
have svk push the full history from the original repository to another
local repository.

On 9/28/06, Page, Bill Bill Page wrote:
> On Thursday, September 28, 2006 7:13 PM I wrote:
> >
> > After several attempts using SVK, first trying the mirroring
> > method that I mentioned earlier, and then later using just a
> > simple 'commit' of the most recent revision of trunk from
> > the Axiom Silver, the result is the same error message:
> >
> >   "Could not write svndiff to temp file: No space left on
> >    device"
> > ...
> > In those cases were I could get feedback from svn while it was
> > working, it seemed that this error occurred while trying to
> > commit a single large file from the zips directory - probably
> > the gcl tarball (about 20 Mbytes). That's large but not *that*
> > large... I wonder if the Google server is using some very
> > limited temporary space, e.g. a overly small /tmp volume or
> > something like that?
> >
>
> Actually I now suspect the problem occurs on our side of
> the process - not Google's. Our axiom-developer.org server
> is configured with a very small /tmp (tmpfs) space - only
> 16 Mbytes! If svn is trying to stuff all of the tarball into
> this small space, it is bound to fail.
>
> Many applications allow one to define an environment variable
> to override the placement of files in /tmp, e.g.
>
>   export TEMP=/anywhere/else
>
> I was not able to determine if this is possible with svn/SVK
> or not but I am running another batch job now with this
> option to see if my commit will run to completion.
>
> Stay tuned...

\start
Date: Fri, 29 Sep 2006 19:13:06 +0200
From: Gregory Vanuxem
To: list
Subject: Working in the boot package

I want to work in the boot package. Is it possible from the interpreter
to open a gcl prompt with all the Axiom packages loaded and, it's _very
important_, all the internal variables set? If I work with depsys some
variables are not set so its behavior is different. Just an example
(MERGE-PATHNAMES "TEST") in depsys returns #p"/usr/local/axiom/mnt/TEST"
but in the interpreter it returns "#p"TEST" or #p"/home/greg/Axiom/TEST"
if I modified the AXIOM default directory with ')cd /home/greg/Axiom'.
Of course I know that it's possible to use ')lisp lisp-code' but this is
not practical.

\start
Date: Fri, 29 Sep 2006 14:01:00 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: Working in the boot package

> I want to work in the boot package. Is it possible from the interpreter
> to open a gcl prompt with all the Axiom packages loaded and, it's _very
> important_, all the internal variables set? If I work with depsys some
> variables are not set so its behavior is different. Just an example
> (MERGE-PATHNAMES "TEST") in depsys returns #p"/usr/local/axiom/mnt/TEST"
> but in the interpreter it returns "#p"TEST" or #p"/home/greg/Axiom/TEST"
> if I modified the AXIOM default directory with ')cd /home/greg/Axiom'.
> Of course I know that it's possible to use ')lisp lisp-code' but this is
> not practical.

There are at least several ways.

The one I usually use is to type:

  -> )lisp (setq |$DALYMODE| t)

This is a special mode of the interpreter.
ANY expression that starts with an open paren is 
interpreted as a lisp expression. Thus, after you
do this you can type lisp expressions at the prompt:

  -> (+ 2 3)
Value = 5

Another method is to type:

  -> )lisp (break)

which will put you into a lisp break loop (a recursive
version of the top level loop). To return back to axiom type
 
BOOT>> :q

at the lisp prompt.

A third method is to type:

  -> )lisp (throw |$intTopLevel| nil)

which will put you back into the lisp top level. To return
to axiom type:

BOOT> (restart)

\start
Date: Fri, 29 Sep 2006 15:49:19 -0400
From: Bill Page
To: Tim Daly, Gregory Vanuxem
Subject: RE: Working in the boot package

On September 29, 2006 1:13 PM Vanuxem Gr=E9gory wrote:
>
> > I want to work in the boot package. Is it possible from
> > the interpreter to open a gcl prompt with all the Axiom
> > packages loaded ...
>
On September 29, 2006 2:01 PM Tim Daly wrote:
>
> There are at least several ways.
>   -> )lisp (setq |$DALYMODE| t)
>   -> )lisp (break)
> BOOT>> :q
> at the lisp prompt.
>   -> )lisp (throw |$intTopLevel| nil)
> BOOT> (restart)

Hmmm.... what about the command?

  )fin

See Axiom Book.

\start
Date: Fri, 29 Sep 2006 15:56:13 -0400
From: Bill Page
To: Ben Collins-Sussman
Subject: RE: [M#73697383] Re: Disk-quota Request
Cc: Gabriel Dos Reis

On September 29, 2006 8:19 AM Ben Collins-Sussman wrote:
> 
> Yes, this is definitely a client-side error.  When the svn client
> sends a file to the server (during a commit), it uses xdelta to
> diff-encode the data into a temporary file, then the neon library
> (an http client library) pushes the tmpfile over the wire.
> ...

Thanks for the explanation. Our service providers has modified
the configuration of /tmp on our server to provide more space
and the 'svk smerge' command is now working happy apparently
re-creating the Axiom subversion repository on Google in the
expected manner. :-)

> ...
> >
> > Stay tuned...
> >

At the current rate of upload, I expect the process to take
a few more hours.

\start
Date: Fri, 29 Sep 2006 15:10:22 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: [M#73697383] Re: Disk-quota Request
Cc: Ben Collins-Sussman

On Fri, 29 Sep 2006, Bill Page wrote:

| On September 29, 2006 8:19 AM Ben Collins-Sussman wrote:
| >
| > Yes, this is definitely a client-side error.  When the svn client
| > sends a file to the server (during a commit), it uses xdelta to
| > diff-encode the data into a temporary file, then the neon library
| > (an http client library) pushes the tmpfile over the wire.
| > ...
|
| Thanks for the explanation. Our service providers has modified
| the configuration of /tmp on our server to provide more space
| and the 'svk smerge' command is now working happy apparently
| re-creating the Axiom subversion repository on Google in the
| expected manner. :-)

That is great!

It is comforting to see that technogoly works :-)

\start
Date: Fri, 29 Sep 2006 16:09:32 -0400
From: Tim Daly
To: list
Subject: Axiom conference call

Is anyone available for an axiom conference call?
Perhaps saturday at noot (EST)?

\start
Date: Fri, 29 Sep 2006 23:04:00 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Working in the boot package

> On September 29, 2006 1:13 PM Vanuxem Gr=E9gory wrote:
> >
> > > I want to work in the boot package. Is it possible from
> > > the interpreter to open a gcl prompt with all the Axiom
> > > packages loaded ...
> >
> On September 29, 2006 2:01 PM Tim Daly wrote:
> >
> > There are at least several ways.
> >   -> )lisp (setq |$DALYMODE| t)
> >   -> )lisp (break)
> > BOOT>> :q
> > at the lisp prompt.
> >   -> )lisp (throw |$intTopLevel| nil)
> > BOOT> (restart)
>
> Hmmm.... what about the command?
>
>   )fin
>
> See Axiom Book.

Impeccable!

Thanks for these quick responses.
Just a note, if I restart axiom via the lisp command (restart) ')fin' no
longer works

\start
Date: Fri, 29 Sep 2006 17:32:20 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: [M#73697383] Re: Disk-quota Request
Cc: Ben Collins-Sussman, Gabriel Dos Reis

> Thanks for the explanation. Our service providers has modified
> the configuration of /tmp on our server to provide more space
> and the 'svk smerge' command is now working happy apparently
> re-creating the Axiom subversion repository on Google in the
> expected manner. :-)

Good to hear Bill. :-) If everything goes as expected, later we can
discuss how to keep in sync sourceforge and google repositories.
I do not know if the steps you provided me before are still the ones
to use. This is just in case you want me to take care of the maintaining
them in sync.

\start
Date: 30 Sep 2006 10:50:53 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [Axiom-mail] Data structure for object definition

Tim Daly writes:

[...]

| so the term 'new' is without meaning and should be ignored.

Hmm, I don't know how to make sense of this (from interp/Makefile):

   NOTES: depsys proceeds all else. it is the compile-time environment
   for all interpreter code.
   :oldboot is pushed on the features list because there is a function
   in util.lisp that emulates the new boot parser command BOOTTOCL. since
                                                                    ^^^^^   
   we eventually plan to move to the new boot parser this function (and
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the push should disappear.


if I do s/new//g in that sentence.

\start
Date: Sat, 30 Sep 2006 15:58:35 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: build improvements results

I have uptdated to build-improvements form 29.09.2006 and tried it
on a few system. On debian sarge i386 and gentoo amd64  build works
both with system gcl and with bundled gcl (using `--without-gcl')
option. On amd64 mandrake 9.2 build works with bundled gcl (did not
try installed gcl). On debian unstable bundled gcl does not build
due to missing msgfmt:

make[6]: Wej=B6cie do katalogu `/home/s/test/tt/axiom7/ax-build2/lsp/gcl-2.=
6.8pre/binutils/bfd/po'
file=./`echo fr | sed 's,.*/,,'`.gmo \
          && rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
/bin/sh: line 1: msgfmt: command not found
make[6]: *** [fr.gmo] B=B3=B1d 127


Again on debian unstable using installed gcl fails:

make[2]: Wej=B6cie do katalogu `/home/s/test/tt/axiom7/ax-build/lsp'
echo '(compiler::link nil "/home/s/test/tt/axiom7/ax-build/build/x86_64-unk=
nown-linux/bin/lisp" \
                (format nil "(progn (let ((*load-path* (cons ~S *load-path*=
))\
                                          (si::*load-types* ~S)) \
                                         (compiler::emit-fn t)) \
                                    (when (fboundp (quote si::sgc-on)) \
                                          (si::sgc-on t)) \
                                    (setq compiler::*default-system-p* t))"=
 \
                        si::*system-directory* (quote (list ".lsp"))) \
                "/home/s/test/tt/axiom7/ax-build/lsp/.././src/lib/cfuns-c.o=
 \
                  /home/s/test/tt/axiom7/ax-build/lsp/.././src/lib/sockio-c=
.o \
                  /home/s/test/tt/axiom7/ax-build/lsp/.././src/lib/libspad.=
a")'
\
            | /usr/bin/gcl
GCL (GNU Common Lisp)  2.6.7 CLtL1    Dec 19 2005 02:59:03
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

>Error handler called recursively (:UNBOUND-VARIABLE NIL EVAL ""
                                      "The variable ~S is unbound."
                                      |
|)
Error handler called recursively (:UNBOUND-VARIABLE NIL EVAL ""
                                     "The variable ~S is unbound." |
|)
Error handler called recursively (:UNBOUND-VARIABLE NIL EVAL ""
                                     "The variable ~S is unbound." |
|)

Error: COMPILER::LINK [or a callee] requires less than six arguments.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by COMPILER::LINK.
Backtrace: funcall > system:top-level > eval > COMPILER::LINK

Broken at SYSTEM:IHS-FUN.
>make[2]: Opuszczenie katalogu `/home/s/test/tt/axiom7/ax-build/lsp'


When I modified the Makefile to put the 'compiler::link' form on a
single line I was able to restart the build. Build produced stopped latex
process later, but appearently I got working AXIOMsys.

\start
Date: 30 Sep 2006 19:16:59 +0200
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: build improvements results

Waldek Hebisch writes:

Hi Waldek, many thanks four your report!

| I have uptdated to build-improvements form 29.09.2006 and tried it
| on a few system. On debian sarge i386 and gentoo amd64  build works
| both with system gcl and with bundled gcl (using `--without-gcl')
| option. On amd64 mandrake 9.2 build works with bundled gcl (did not
| try installed gcl). On debian unstable bundled gcl does not build
| due to missing msgfmt:
|
| make[6]: Wej=B6cie do katalogu `/home/s/test/tt/axiom7/ax-build2/lsp/gcl-=
2.6.8pre/binutils/bfd/po'
| file=./`echo fr | sed 's,.*/,,'`.gmo \
|           && rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
| /bin/sh: line 1: msgfmt: command not found
| make[6]: *** [fr.gmo] B=B3=B1d 127

This is a binutils inside GCL issue.  I don't know what to do about
it.  Maybe modify GCL not to build with intl' support?

| Again on debian unstable using installed gcl fails:
|
| make[2]: Wej=B6cie do katalogu `/home/s/test/tt/axiom7/ax-build/lsp'
| echo '(compiler::link nil "/home/s/test/tt/axiom7/ax-build/build/x86_64-u=
nknown-linux/bin/lisp" \
|                 (format nil "(progn (let ((*load-path* (cons ~S *load-pat=
h*))\
|                                           (si::*load-types* ~S)) \
|                                          (compiler::emit-fn t)) \
|                                     (when (fboundp (quote si::sgc-on)) \
|                                           (si::sgc-on t)) \
|                                     (setq compiler::*default-system-p* t)=
)" \
|                         si::*system-directory* (quote (list ".lsp"))) \
|                 "/home/s/test/tt/axiom7/ax-build/lsp/.././src/lib/cfuns-c=
.o \
|                   /home/s/test/tt/axiom7/ax-build/lsp/.././src/lib/sockio=
-c.o \
|                   /home/s/test/tt/axiom7/ax-build/lsp/.././src/lib/libspa=
d.a")'
| \
|             | /usr/bin/gcl
| GCL (GNU Common Lisp)  2.6.7 CLtL1    Dec 19 2005 02:59:03
| Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
| Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
| Modifications of this banner must retain notice of a compatible license
| Dedicated to the memory of W. Schelter
|
| Use (help) to get some basic information on how to use GCL.
|
| >Error handler called recursively (:UNBOUND-VARIABLE NIL EVAL ""
|                                       "The variable ~S is unbound."


Is it possible this might be a shell issue?  It looks to me as if the
mutiline format string isn't being properly interpreted as a string
when passed to GCL.  What shell was that?

[...]

| When I modified the Makefile to put the 'compiler::link' form on a
| single line I was able to restart the build. Build produced stopped latex
| process later, but appearently I got working AXIOMsys.

I'll eventually get to the latex part.

For the moment, I've "mysteriously broken" my local tree.  I propose
to nominate Axiom for the most voodoo-esque software :-)

\start
Date: Sat, 30 Sep 2006 16:43:25 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: [M#73697383] Re: Disk-quota Request
Cc: Ben Collins-Sussman

Gaby,

On September 29, 2006 4:10 PM you wrote:
> 
> On Fri, 29 Sep 2006, Bill Page wrote:
> 
> | On September 29, 2006 8:19 AM Ben Collins-Sussman wrote:
> | >
> | > Yes, this is definitely a client-side error.  When the svn client
> | > sends a file to the server (during a commit), it uses xdelta to
> | > diff-encode the data into a temporary file, then the neon library
> | > (an http client library) pushes the tmpfile over the wire.
> | > ...
> |
> | Thanks for the explanation. Our service providers has modified
> | the configuration of /tmp on our server to provide more space
> | and the 'svk smerge' command is now working happy apparently
> | re-creating the Axiom subversion repository on Google in the
> | expected manner. :-)
> 
> That is great!
> 
> It is comforting to see that technology works :-)
> 

Well, um ... as usual I was too optimistic.

After 24 hours of running:

  svk smerge --baseless --incremental --verbatim --remoterev \
    /mirror/axiom /mirror/google --message="Initial commit" 

where /mirror/axiom is a mirror of the SourceForge repository
and /mirror/google is a mirror of the Google Code repository,

I got this message twice:

...skipping
A   branches/build-improvements/src/input/sregset.input.pamphlet
A   branches/build-improvements/src/input/lump.input.pamphlet
RA layer request failed: PUT of
  '/svn/!svn/wrk/b478bcbe-991e-0410-ae1c-cb0b31e56b2f/branches/build-
  improvements/src/input/lump.input.pamphlet': 502 Bad Gateway
  (https://axiom.googlecode.com)
  Please sync mirrored path /google first.
...

I had to restart from scratch because initially I did not (yet)
know about using --incremental.

Then the third time around this time using the incremental option
so that at least something got committed in case it failed again,
at revision 19 I got the error message:

New merge ticket: 54bea96e-1511-0410-8851-aaeae44645fa:/:18
A repository hook failed: MERGE request failed on '/svn':
Commit would put repository over quota limit.

Arrggggh! :-(

The complete svn repository on SourceForge is only 233,248 Kb.
It should have fit on Google!

On axiom-developer.org I can rsync the entire repository from
SourceForge and create a local mirror in about 10 minutes and
everything works fine.

Maybe 'svk smerge' is too brain-dead about the way it recreates
the branches and ends up duplicating more code than in the
original SourceForge repository?

Or maybe we do not actually have 250Mb. available on Google?

Again, not having shell access to Google Code is making this
unnecessarily excruciating. At least I could use svnadmin and
tidy things up. But doing things this way is ridiculous.

Where to go from here?

1) Start over from scratch again!? and this time do what I had
planned originally - just commit trunk, copy trunk to branches
build-improvements, and then commit an up to date version of
build-improvements? I.e. lose all the history?

2) Beg for another 100 Mb. from Google and continue the smerge?

3) Ask someone who does have shell access to Google Code to just
rsync this turkey from SourceForge for us?

What do you think?

Regards,
Bill Page.

PS. On a related issue. The more I think about the 'zips'
directory in the Axiom distribution the more I think it was a
ReallyStupid (tm) invention. Why take a source code tarball from
another project (gcl) and stick it into the Axiom repository?
If we really need a copy of gcl, why don't we just add it properly
into the repository as source code? Why do we work around the
capabilities of the source code control system by saving the
tarball and patches against it, having to apply these patches
during the build instead of just committing these patches to
Axiom's version of gcl in the repository? All of this stuff is
stored in the repository in a compressed manner anyway, right?

\start
Date: Sat, 30 Sep 2006 23:53:50 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: build improvements results
Cc: Waldek Hebisch

Gabriel Dos Reis writes:
> Waldek Hebisch writes:
>
> | Again on debian unstable using installed gcl fails:
> |
> | make[2]: Wej=B6cie do katalogu `/home/s/test/tt/axiom7/ax-build/lsp'
> | echo '(compiler::link nil "/home/s/test/tt/axiom7/ax-build/build/x86_64=
-unknown-linux/bin/lisp" \
> |                 (format nil "(progn (let ((*load-path* (cons ~S *load-p=
ath*))\
> |                                           (si::*load-types* ~S)) \
> |                                          (compiler::emit-fn t)) \
> |                                     (when (fboundp (quote si::sgc-on)) \
> |                                           (si::sgc-on t)) \
> |                                     (setq compiler::*default-system-p* =
t))" \
> |                         si::*system-directory* (quote (list ".lsp"))) \
> |                 "/home/s/test/tt/axiom7/ax-build/lsp/.././src/lib/cfuns=
-c.o \
> |                   /home/s/test/tt/axiom7/ax-build/lsp/.././src/lib/sock=
io-c.o \
> |                   /home/s/test/tt/axiom7/ax-build/lsp/.././src/lib/libs=
pad.a")'
> | \
> |             | /usr/bin/gcl
> | GCL (GNU Common Lisp)  2.6.7 CLtL1    Dec 19 2005 02:59:03
> | Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> | Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
> | Modifications of this banner must retain notice of a compatible license
> | Dedicated to the memory of W. Schelter
> |
> | Use (help) to get some basic information on how to use GCL.
> |
> | >Error handler called recursively (:UNBOUND-VARIABLE NIL EVAL ""
> |                                       "The variable ~S is unbound."
>
>
> Is it possible this might be a shell issue?  It looks to me as if the
> mutiline format string isn't being properly interpreted as a string
> when passed to GCL.  What shell was that?
>

GNU bash, version 3.1.14(1)-release (x86_64-pc-linux-gnu)

AFAICS shell preserve backslashes (since they are inside apostrophes).
I have checked on another Debian machine (this time using bundled gcl)
and the same problem appeared. Both problematic machnes run Gnu make
3.81. The other machines (without this problem) run Gnu make 3.80.

\start
Date: Sun, 01 Oct 2006 00:23:56 +0200
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: Re: build improvements results

I believe I have run into that problem with one of my own projects. Here =

is my 'svn log' corresponding to it. Maybe that gives some inside.

Cannot you move the \ outside the '...' area.

---My ChangeLog

There was a problem with handling quoted backslash/newline combinations
with a newer version of GNU-make (version 3.81). This came from a recent
bugfix that happened in make 3.81. Here is the corresponding ChangeLog
entry from GNU make 3.81.

   > 2005-06-25  Paul D. Smith  <psmith@gnu.org>
   >
   >	* job.c (construct_command_argv_internal): Sanitize handling of
   >	backslash/newline pairs according to POSIX: that is, keep the
   >	backslash-newline in the command script, but remove a following
   >	TAB character, if present.  In the fast path, make sure that the
   >	behavior matches what the shell would do both inside and outside
   >	of quotes.  In the slow path, quote the backslash and put a
   >	literal newline in the string.
   >	Fixes Savannah bug #1332.

---end ChangeLog


On 09/30/2006 11:53 PM, Waldek Hebisch wrote:
> Gabriel Dos Reis writes:
>> Waldek Hebisch writes:
>>
>> | Again on debian unstable using installed gcl fails:
>> |
>> | make[2]: Wej=B6cie do katalogu `/home/s/test/tt/axiom7/ax-build/lsp'=

>> | echo '(compiler::link nil "/home/s/test/tt/axiom7/ax-build/build/x86=
_64-unknown-linux/bin/lisp" \
>> |                 (format nil "(progn (let ((*load-path* (cons ~S *loa=
d-path*))\
>> |                                           (si::*load-types* ~S)) \
>> |                                          (compiler::emit-fn t)) \
>> |                                     (when (fboundp (quote si::sgc-on=
)) \
>> |                                           (si::sgc-on t)) \
>> |                                     (setq compiler::*default-system-=
p* t))" \
>> |                         si::*system-directory* (quote (list ".lsp"))=
) \
>> |                 "/home/s/test/tt/axiom7/ax-build/lsp/.././src/lib/cf=
uns-c.o \
>> |                   /home/s/test/tt/axiom7/ax-build/lsp/.././src/lib/s=
ockio-c.o \
>> |                   /home/s/test/tt/axiom7/ax-build/lsp/.././src/lib/l=
ibspad.a")'
>> | \
>> |             | /usr/bin/gcl
>> | GCL (GNU Common Lisp)  2.6.7 CLtL1    Dec 19 2005 02:59:03
>> | Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
>> | Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)=

>> | Modifications of this banner must retain notice of a compatible lice=
nse
>> | Dedicated to the memory of W. Schelter
>> |
>> | Use (help) to get some basic information on how to use GCL.
>> |
>> | >Error handler called recursively (:UNBOUND-VARIABLE NIL EVAL ""
>> |                                       "The variable ~S is unbound."
>>
>>
>> Is it possible this might be a shell issue?  It looks to me as if the
>> mutiline format string isn't being properly interpreted as a string
>> when passed to GCL.  What shell was that?
>>
>
> GNU bash, version 3.1.14(1)-release (x86_64-pc-linux-gnu)
>
> AFAICS shell preserve backslashes (since they are inside apostrophes).
> I have checked on another Debian machine (this time using bundled gcl)
> and the same problem appeared. Both problematic machnes run Gnu make
> 3.81. The other machines (without this problem) run Gnu make 3.80.

\start
Date: Sat, 30 Sep 2006 17:22:11 -0500
From: Ben Collins-Sussman
To: Bill Page
Subject: Re: [M#73697383] Re: Disk-quota Request
Cc: Gabriel Dos Reis

On 9/30/06, Bill Page wrote:

> The complete svn repository on SourceForge is only 233,248 Kb.
> It should have fit on Google!

Google Guy Here.  :-)

Can you do me a favor?  Can you try using svk to 'push' your
repository to some other local repository (in the same way you're
pushing it at google)?  Then verify that the target (replicated)
repository is indeed the same size as the original?

I *suspect* there's a bug in the quota-tracking code at google, and if
so, it's my fault.  I may need to investigate ASAP!


> PS. On a related issue. The more I think about the 'zips'
> directory in the Axiom distribution the more I think it was a
> ReallyStupid (tm) invention. Why take a source code tarball from
> another project (gcl) and stick it into the Axiom repository?
> If we really need a copy of gcl, why don't we just add it properly
> into the repository as source code? Why do we work around the
> capabilities of the source code control system by saving the
> tarball and patches against it, having to apply these patches
> during the build instead of just committing these patches to
> Axiom's version of gcl in the repository? All of this stuff is
> stored in the repository in a compressed manner anyway, right?
>

Yes, this is what I was trying to hint at when you guys initially
asked for a gig of space.  :-)

\start
Date: Sat, 30 Sep 2006 17:56:32 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: [M#73697383] Re: Disk-quota Request
Cc: Ben Collins-Sussman

On Sat, 30 Sep 2006, Bill Page wrote:

| PS. On a related issue. The more I think about the 'zips'
| directory in the Axiom distribution the more I think it was a
| ReallyStupid (tm) invention. Why take a source code tarball from
| another project (gcl) and stick it into the Axiom repository?
| If we really need a copy of gcl, why don't we just add it properly
| into the repository as source code? Why do we work around the
| capabilities of the source code control system by saving the
| tarball and patches against it, having to apply these patches
| during the build instead of just committing these patches to
| Axiom's version of gcl in the repository?

I don't know :-)
In fact, I would really prefer to avoid the situation where Axiom
maintains its own forks of GCL and noweb.

However, as per the build-improvements branch, I think we no longer
apply patches against the tarballs.

\start
Date: 01 Oct 2006 01:09:52 +0200
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: build improvements results

Waldek Hebisch writes:

[...]

| > | 
| > | >Error handler called recursively (:UNBOUND-VARIABLE NIL EVAL ""
| > |                                       "The variable ~S is unbound."
| > 
| > 
| > Is it possible this might be a shell issue?  It looks to me as if the
| > mutiline format string isn't being properly interpreted as a string
| > when passed to GCL.  What shell was that?
| >
| 
| GNU bash, version 3.1.14(1)-release (x86_64-pc-linux-gnu)
| 
| AFAICS shell preserve backslashes (since they are inside apostrophes).
| I have checked on another Debian machine (this time using bundled gcl)
| and the same problem appeared. Both problematic machnes run Gnu make
| 3.81. The other machines (without this problem) run Gnu make 3.80.

Thanks for checking.  As ever, I had the wrong guess. :-/

Ralf, the reason the command line was slipt is that everyong on 
online reads gerbish to be -- I can't see whether the next paren
starts from where the previous ends.  All those reasons, why we format
codes :-)

Now, if this is a make bug, then it is really unfortunate. :-(

\start
Date: Sun, 01 Oct 2006 01:37:56 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: build improvements results
Cc: Waldek Hebisch

> Ralf, the reason the command line was slipt is that everyong on 
> online reads gerbish to be -- I can't see whether the next paren
> starts from where the previous ends.  All those reasons, why we format
> codes :-)

Sorry that I suggested to rewrite

mytst:
	@echo \
	'(foo  \
	    (bar baz))'

into

mytst:
	@echo \
	'(foo ' \
	'   (bar baz))'

Just put the apostrophes differently.

I'll be quiet next time.

\start
Date: Sat, 30 Sep 2006 21:17:06 -0400
From: Tim Daly
To: Bill Page
Subject: Re: [M#73697383] Re: Disk-quota Request
Cc: Ben Collins-Sussman, Gabriel Dos Reis

> PS. On a related issue. The more I think about the 'zips'
> directory in the Axiom distribution the more I think it was a
> ReallyStupid (tm) invention. Why take a source code tarball from
> another project (gcl) and stick it into the Axiom repository?

I see your 'reasons' cache has expired again. 
Please refresh it from the mailing list history. :-)

Axiom is NOT the only one to do this and there are prefectly valid
reasons for doing so. Review your version of SVN if you don't
believe me. They include Neon and APR. 

You believe that yum and apt-get work and that they work for
every user. But consider all of the software that got installed
because you needed a couple Perl packages. I believe the number
was in the hundreds. I've run into the same issue trying to
automatically install yum packages. I generally abort the
update if it insists on installing a new version of glibc
when all i wanted was to bring some utility up to date.

And consider what happens when the average user tries to 
update the utility, the update insists on re-installing glibc,
and the user does not have root access.

Plus if you apt-get GCL you might get a version from stable,
unstable, or testing. Yet GCL-2.6.8pre only works on some
systems and GCL-2.6.8pre2 only works on others and there is
no build-time way to distinguish them. Nor is there a tag
so you can't pull from the CVS. I'm waiting to see how this
issue is handled in build-improvements.

Axiom build should 'just work'.

Not, 'just work if you have yum', 'have root access', and
'are willing to install a hundred Perl scripts' or 'know
which CVS tag will work with this axiom version'. Axiom 
can build on Red Flag Linux. As far as I know they don't
have either yum or apt-get (or if they do I don't know the
chinese incantation). Axiom is nearly working on the MAC.
As far as I know there is no yum for the MAC.

Axiom build should 'just work'.

> If we really need a copy of gcl, why don't we just add it properly
> into the repository as source code? Why do we work around the
> capabilities of the source code control system by saving the
> tarball and patches against it, having to apply these patches
> during the build instead of just committing these patches to
> Axiom's version of gcl in the repository? All of this stuff is
> stored in the repository in a compressed manner anyway, right?

The reason to use the GCL tarball with patches is that gradually
the patches get accepted upstream. If we copied the source tree
into Axiom we would be maintaining our own version which would
eventually get out of sync. A source tarball with patches does
not get out of sync since the patches are obvious.

The fact that the repository is or is not compressed has nothing
to do with the whole issue.

Part of your frustration seems to be coming from SVN. I'm using
SVN in work and it 'locks' the source tree, insists I run 'cleanup'
(which NEVER works), and forces me to unwind changes, blow away my
source tree, refetch the repository, re-apply my changes, and commit.
It is tedious. The whole idea of 'locking' is broken.

I also use SVN on Magnus, one of my other open source projects.
The checkouts regularly fail. I have to do a checkout followed
by at least a half-dozen 'updates' to get a good source tree.
And then commit bombs and I'm forced to try to clean up the
resulting mess using the same dance of 'back-out, blow-away,
checkout, update, update, update, update, update, update,
apply changes, commit and pray.

Darcs is slow but it works. 
Arch is complex but has never failed.
CVS is old but never fails.

SVN is broken. Face it. It's not ready for prime time.
The only hope we have is to host it ourselves so you can
use the admin tools to recover.

\start
Date: 01 Oct 2006 03:28:30 +0200
From: Gabriel Dos Reis
To: list
Subject: boottocl

Tim --

there exist two implementations of boottran::boottocl:
  1. one in interp/util.lisp,
  2. and on in boot/ptyout.boot.

Which one is the real boottocl compiled into the Boot translator?

\start
Date: Sat, 30 Sep 2006 21:05:34 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [M#73697383] Re: Disk-quota Request
Cc: Ben Collins-Sussman

On Sat, 30 Sep 2006, root wrote:

| Part of your frustration seems to be coming from SVN. I'm using
| SVN in work and it 'locks' the source tree, insists I run 'cleanup'
| (which NEVER works), and forces me to unwind changes, blow away my
| source tree, refetch the repository, re-apply my changes, and commit.
| It is tedious. The whole idea of 'locking' is broken.
|
| I also use SVN on Magnus, one of my other open source projects.
| The checkouts regularly fail. I have to do a checkout followed
| by at least a half-dozen 'updates' to get a good source tree.
| And then commit bombs and I'm forced to try to clean up the
| resulting mess using the same dance of 'back-out, blow-away,
| checkout, update, update, update, update, update, update,
| apply changes, commit and pray.

I don't know how you guys manage into get such a series of mess.

\start
Date: Sat, 30 Sep 2006 22:10:10 -0400
From: Bill Page
To: Tim Daly
Subject: RE: [M#73697383] Re: Disk-quota Request
Cc: Ben Collins-Sussman, Gabriel Dos Reis

On September 30, 2006 9:17 PM Tim Daly wrote:
> Bill Page wrote: 
> 
> > PS. On a related issue. The more I think about the 'zips'
> > directory in the Axiom distribution the more I think it
> > was a ReallyStupid (tm) invention. Why take a source code
> > tarball from another project (gcl) and stick it into the
> > Axiom repository?
> 
> I see your 'reasons' cache has expired again. 
> Please refresh it from the mailing list history. :-)
> 
> Axiom is NOT the only one to do this and there are prefectly
> valid reasons for doing so. Review your version of SVN if
> you don't believe me. They include Neon and APR.

I DO NOT know any other project that stores source code tarballs
in their source code repository. Do you?

I did not say that storing gcl source code in the Axiom
repository was necessarily a ReallyBad(tm) thing - just storing
it as a compressed zip file is ReallyBad. Whether Axiom should
be distributing gcl as part of it's source code (as patches or
en mass) is a separate issue. 

> 
> You believe that yum and apt-get work and that they work
> for every user.

No they don't work for every user - just 95% of them. The
others either have a unique system of their own choosing or
they have badly screwed something up somehow.

> But consider all of the software that got installed because
> you needed a couple Perl packages. I believe the number
> was in the hundreds.

Yes. But it worked. Scary stuff.

> I've run into the same issue trying to automatically install
> yum packages. I generally abort the update if it insists on
> installing a new version of glibc when all i wanted was to
> bring some utility up to date.

You must be one of those in the 5% category. ;)

> 
> And consider what happens when the average user tries to 
> update the utility, the update insists on re-installing
> glibc, and the user does not have root access.
>

That's just stupidity. No excuses.
 
> Plus if you apt-get GCL you might get a version from stable,
> unstable, or testing.

??? You do have to configure apt-get properyly for it to work
properly.

> Yet GCL-2.6.8pre only works on some systems and GCL-2.6.8pre2
> only works on others and there is no build-time way to
> distinguish them.

Different problem. 'pre' mean 'pre-release'. We are lucky that
it runs at all.

> Nor is there a tag so you can't pull from the CVS. I'm waiting
> to see how this issue is handled in build-improvements.

!!! Wait until gcl-2.6.8 is released, of course. Nobody should be
distributing pre-release software except in highly experiement
branches.

> 
> Axiom build should 'just work'.
>

That's simply unrealistic.

Linux should just work. Windows should just work ... Maple should
just work. None of them do.
 
> Not, 'just work if you have yum', 'have root access', and
> 'are willing to install a hundred Perl scripts' or 'know
> which CVS tag will work with this axiom version'. Axiom 
> can build on Red Flag Linux. As far as I know they don't
> have either yum or apt-get (or if they do I don't know the
> chinese incantation). Axiom is nearly working on the MAC.
> As far as I know there is no yum for the MAC.
>

What *are* you talking about? What does yum or apt-get have
to do with this?
 
> Axiom build should 'just work'.
> 
> 
> > If we really need a copy of gcl, why don't we just add it
> > properly into the repository as source code? Why do we work
> > around the capabilities of the source code control system by
> > saving the tarball and patches against it, having to apply
> > these patches during the build instead of just committing
> > these patches to Axiom's version of gcl in the repository?
> > All of this stuff is stored in the repository in a compressed
> > manner anyway, right?
> 
> The reason to use the GCL tarball with patches is that gradually
> the patches get accepted upstream. If we copied the source tree
> into Axiom we would be maintaining our own version which would
> eventually get out of sync. A source tarball with patches does
> not get out of sync since the patches are obvious.
>

All patches are obvious in a source code control system. What is
the problem?
 
> The fact that the repository is or is not compressed has nothing
> to do with the whole issue.
>

The point is that storing a binary tarball containing source code
in a source code control system defeats the purpose and makes it
necessary to do things in a more complicated way.
 
> 
> Part of your frustration seems to be coming from SVN. I'm using
> SVN in work and it 'locks' the source tree, insists I run
> 'cleanup' (which NEVER works), and forces me to unwind changes,
> blow away my source tree, refetch the repository, re-apply my
> changes, and commit. It is tedious. The whole idea of 'locking'
> is broken.
>

We had previously discussed this long before SVN was ever an issue.
 
> I also use SVN on Magnus, one of my other open source projects.
> The checkouts regularly fail. I have to do a checkout followed
> by at least a half-dozen 'updates' to get a good source tree.
> And then commit bombs and I'm forced to try to clean up the
> resulting mess using the same dance of 'back-out, blow-away,
> checkout, update, update, update, update, update, update,
> apply changes, commit and pray.
>

But I agree about SVN. My experience with subversion is all
negative. I have no idea why the "major projects" have chosen
such a monster. But I guess it works for them and there are a
*lot* of people actively developing it and using it.
 
> Darcs is slow but it works. 

Darcs seems to get faster with each release. 1.0.7 works very
well for me. It is continuing to be actively developed and
maintained.

> Arch is complex but has never failed.

Arch fails on windows and has (mostly) been abandoned by it's
original developers.

> CVS is old but never fails.
>

It's too complex - like subversion and arch - and does less.
 
> SVN is broken. Face it. It's not ready for prime time.
> The only hope we have is to host it ourselves so you can
> use the admin tools to recover.
> 

Yes, I am afraid so. :-(

\start
Date: Sat, 30 Sep 2006 22:18:11 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: boottocl

On September 30, 2006 9:29 PM Gabriel Dos Reis asked:
> 
> there exist two implementations of boottran::boottocl:
>   1. one in interp/util.lisp,
>   2. and on in boot/ptyout.boot.
> 
> Which one is the real boottocl compiled into the Boot
> translator?
> 

As Jurgen Weiss has pointed out, bootsys is technically
superfluous. The boot translator is include in interp as part
of SPAD. And Axiom can be bootstrapped directly from the
version of boot in interp. (This is the method that he used
for the CMUCL version of Axiom.)

So I guess which one is "real" depends on your point of view.

\start
Date: 01 Oct 2006 04:33:38 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: [M#73697383] Re: Disk-quota Request

[ I removed Ben from the CC: list because I don't think he really want
to get into our internal issues. ]

Bill Page writes:

[...]

| No they don't work for every user - just 95% of them. 

Where do you get that from?

\start
Date: 01 Oct 2006 04:36:18 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: boottocl

Bill Page writes:

| On September 30, 2006 9:29 PM Gabriel Dos Reis asked:
| > 
| > there exist two implementations of boottran::boottocl:
| >   1. one in interp/util.lisp,
| >   2. and on in boot/ptyout.boot.
| > 
| > Which one is the real boottocl compiled into the Boot
| > translator?
| > 
| 
| As Jurgen Weiss has pointed out, bootsys is technically
| superfluous. The boot translator is include in interp as part
| of SPAD. And Axiom can be bootstrapped directly from the
| version of boot in interp. (This is the method that he used
| for the CMUCL version of Axiom.)

all that is interesting but does not address my real issue.

Assume I have an issue with how boottocl works, which version am I
supposed to modify?  I'm talking of the system as it currently is --
now how it could theoretically be.

\start
Date: Sat, 30 Sep 2006 23:17:41 -0400
From: Bill Page
To: Ben Collins-Sussman
Subject: RE: [M#73697383] Re: Disk-quota Request
Cc: Gabriel Dos Reis

Ben,

On September 30, 2006 6:22 PM you wrote:
> 
> On 9/30/06, Bill Page wrote:
> 
> > The complete svn repository on SourceForge is only 233,248 Kb.
> > It should have fit on Google!
> 
> Google Guy Here.  :-)
> 

Thank you very much for your reply and your suggestion below.

> Can you do me a favor?  Can you try using svk to 'push' your
> repository to some other local repository (in the same way you're
> pushing it at google)?  Then verify that the target (replicated)
> repository is indeed the same size as the original?
> 

First I created a local backup copy of our SourceForge repository:

  $export RSYNC_PROXY=rsync-svn.sourceforge.net:80
  $mkdir -p ~/test0
  $rsync -v -a rsync-svn-a::svn/axiom/* ~/test0

(This took less that 10 minutes.)

This copy of the repository is 167,364 Kb. Apparently the size of
233,248 Kb that I quoted above was incorrect. Sorry.

  $ du -s /home/page/test0
  167364  /home/page/test0

Then I ran the following test to simulate what I was trying to
do to Google:

  $svnadmin create /home/page/test
  $svk mirror  /mirror/axiom https://svn.sourceforge.net/svnroot/axiom
  $svk mirror /mirror/test file:///home/page/test
  $svk smerge --baseless --incremental --verbatim --remoterev /mirror/axiom
/mirror/test

(This took about 15 minutes on axiom-developer.org.)

Note: I did not use file://home/page/test0 as the source because if
both repositories are local svk uses a short-cut to do the smerge.

> I *suspect* there's a bug in the quota-tracking code at google,
> and if so, it's my fault.  I may need to investigate ASAP!
> 

No. You are "off the hook" :-)

The size of the resulting repository is 326,332 Kb.

$ ls /home/page/test1
conf  dav  db  format  hooks  locks  README.txt
$ du -s /home/page/test1
326332  /home/page/test

This is nearly twice as large as the original!

So this confirms that 'svk smerge' does not re-create the repository
in the same compact form in which it exists on SourceForge. :-(

\start
Date: Sat, 30 Sep 2006 23:18:11 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: boottocl

> there exist two implementations of boottran::boottocl:
>   1. one in interp/util.lisp,
>   2. and on in boot/ptyout.boot.
> 
> Which one is the real boottocl compiled into the Boot translator?

at one time the two parsers handled differently languages,
the 'old' boot language and the 'new' boot language. the
boot parser was written in the old boot language and the
rest of the system was coded in the new boot language.
the goal was to unify the two language.

i don't remember whether we fully resolved that issue.
the only way to guarantee they are the same is to verify
that they ultimately call the same functions. or you can
translate each of the boot files with both functions and
see if the resulting lisp code is equal.

one of the parsers used to live in the boottran package
and the other lived in the boot package. there is a subtle
issue of which macros are loaded into each image which
affects the ultimate expansion of the code.

so the ultimate answer is i don't know. its been too long.

\start
Date: Sat, 30 Sep 2006 23:32:21 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: [M#73697383] Re: Disk-quota Request

On September 30, 2006 10:34 PM Gaby wrote:
> 
> Bill Page writes:
> 
> [...]
> 
> | No they don't work for every user - just 95% of them. 
> 
> Where do you get that from?
> 

It was a rhetorical statement with no basis in fact. I have no
idea if it is true or not or even how to find out. Sorry.

But certainly such general package installation tools as apt-get,
yum, up2date,, pkgadd and fink are very popular among the "boxed
linux" distributions as you can judge by hits on google. And
language specific tools such as cpan for perl have a reputation
for high quality and ease of use. I don't know anyone besides
Tim who has reported such serious problems with these tools.





\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
