\start\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}

Date: 01 Aug 2006 06:40:11 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Front page esthetic

Bill Page writes:

| Gaby,
| 
| I am glad to receive your comments about the Axiom Wike site.
| Please forgive me if some of my replies sound overly defensive.
| I admit I have a biased view - but that is what makes it even
| more important that other people comment about this stuff...
| 
| On July 31, 2006 9:33 PM you wrote:
| > 
| >   I find the front page of Axiom quite "visually heavy" -- and
| > many times I miss there the information I'm looking for.
| > 
| 
| Could you give an example of information that you were looking
| for but did not find? That sort of observation would be a big
| help.

For example, I was looking for research papers related to Axiom.  I
knew they were buried deeply somewhere in the hierarchical pages.

see the message I sent to axiom-mail.

| >   So, I took a look at few free software or open source 
| > computer algebra systems, to see what other people are up to.
| > 
| >    http://maxima.sourceforge.net/
| >    http://yacas.sourceforge.net/
| >    http://www.singular.uni-kl.de/
| >    http://turnbull.mcs.st-and.ac.uk/~gap/
| > 
| > All of them appears to me to be quite simple -- and I like that
| > simplicity.  Especially that of Maxima.  It takes very little
| > time to display -- compared to Axiom's.
| >
| 
| When I look at
| 
| http://maxima.sourceforge.net
| 
| My first reaction is: Hmmm, that doesn't look so different than the
| Axiom Wiki FrontPage... The time to display seems quite similar over
| a high speed connection and a reasonably fast system (AMD 3500+).
| 
| Differences I noticed:
| 
| 1) Maxima uses just a left side-bar but Axiom Wiki currently uses
|    both left and right side-bars, but just a left side-bar
|    navigation bar on all other pages.
| 
| 2) The Axiom Wiki FrontPage has more graphics including an example
|    Axiom output graphic.

That, from my perspective, contributes to the "visual load".

| 3) The Maxima web site is not a wiki.

I understand that.  I'm not sure I see the benefits of having the
frontpage being a wiki -- but that is a minor point I guess.

| 4) The Maxima web site has no search function.

that is a minus for them, and a plus for us :-)

| I don't find anything that makes the Maxima page seem simpler or
| that gives me the impression that information is more readily
| accessible. What am I missing?
| 
| When I looked at:
| 
| http://yacas.sourceforge.net
| 
| I thought:
| 
| 1) Yacas FrontPage doesn't say much and has only a minimal set
|    of links (no side-bars).

minimal is beautiful :-)

As I said, my preference goes to maxima's style.  Yacas' is at one end
of the spectrum.  I find that Axiom's holds the other end. 


| 2) Yacas uses a fixed left side-bar on other pages.
| 
| 3) Not a wiki.
| 
| 4) No search.
| 
| When I look at:
| 
| http://www.singular.uni-kl.de/
| 
| my reaction is:
| 
| 1) Looks a lot like Axiom Wiki.

but much simpler; visually.  It has direct links to what I would call
the essential stuff.

| 2) Has search.
| 
| 3) Has both left and right side-bars.
| 
| 4) Not a wiki.

Why is having the front-page as wiki a plus?
For all I know, only a handful of people can actually modify that page.
For other pages, due to irritating spams, the system has made it
complicated for good citizens to contribute changes.  I don't see a
difference between that and maintaining the website files as part of
the SVN or CVS repository.  The latter seems simpler to me -- but I'm
not proposing it.  Just observing.

[...]

| > Important to me is that the front-page must send the message that
| > this is related to research.  Yes, we have links to workshops and
| > all that.  But, most importantly, links to research papers related
| > to Axiom must be clearly and unambiguously linked from there --
| 
| Are you aware of the Axiom bibliography on the Axiom Portal?
| 
| http://portal.axiom-developer.org/refs

Yes, I do.

| Maybe this deserves a link on the Axiom Wiki FrontPage?

This is precisely what I suggested in the message I sent (yesterday I
believe) to axiom-mail.

| > I sent a message to axiom-mail to that effect but for some reasons
| > it never shows up :-(
| 
| I did not see any posting to axiom-mail. In fact I haven't seen
| any real postings to axiom-mail for some time - only spam (about
| 10 to 20 spam message per day). I wonder if this list is working
| properly? Most people seem to prefer the axiom-devel list. Maybe
| we have too many lists?

I don't think we have too many lists;  we're just misusing axiom-devel
:-) 

| > My suggestion would be to simplify the "visual load" of the
| > front-page.  I know that sounds a bit unhelpful but it is a
| > start of suggestion :-)
| 
| I am not clear on what you mean by "visual load". Are you
| referring to the layout? The color scheme?

yes, layout.  I think the color is OK.

| > People should be able to find the exciting/appealing things
| > about Axiom from its front-page.  We should not require them
| > to "dig through".
| > 
| 
| I agree.
| 
| Can you give an example of something that is exciting and/or
| appealing about Axiom that is not found on the FrontPage?
| 
| What constituents "dig through" to you?

For example, I know that if I log into the portal I can find the links
to the articles; but I don't know how many clicks it takes to find it
from the frontpage.

Yesterday, I was looking for something in the documentation of the
silver branch and realized there was a page for "development" (or
something like that) that is a hierarchical parent of the silver
stuff.

I don't propose to put all links ono the frontpage though :-)

| Do you mean just
| that they don't find the information on the FrontPage?
| How many clicks to finding the right information do you
| think is reasonable?

at most two.

| > To my mind the description of Axiom should mention
| > application to engineering, computer science -- not just
| > Physics or Mathematics.
| > 
| 
| I agree. I really would like to be able to list examples
| of all of these. Did you see any mention of physics on the
| FrontPage?

I saw it somewhere (that is from yesterday memory)... It turns out
that I read it from Axiom's SF page.  Sorry for that.

Actually, I'm interested in a publically accessible list of
applications of computer algebra in fields other than maths.   Do you
happen to know one?

| I would claim that computer science is clearly
| implied by the contents of the FrontPage even if not
| explicitly named.

we should be explicit about it -- it is part of "they should not dig
through." :-)

\start
Date: Tue, 01 Aug 2006 11:52:26 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Front page esthetic

Hello Gaby,

[Wiki-Frontpage]
> For example, I was looking for research papers related to Axiom.  I
> knew they were buried deeply somewhere in the hierarchical pages.

I agree with Gaby, the FrontPage is missing some information that I 
would like to find there. So I added some questions to the FAQ section.
If everyone would enter questions there (yes just questions other people 
might answer), then that would be a way to know what people are looking 
for and modify the FrontPage accordingly.Unfortunately, I could not come 
up with a better suggestion. I think Bill did a great job. Thank you, 
Bill. But Gaby, imagine you have to design the FrontPage yourself. Maybe 
that seems simple, but the links you put there should lead to some 
reasonable content.

> | http://portal.axiom-developer.org/refs
> 
> Yes, I do.
> 
> | Maybe this deserves a link on the Axiom Wiki FrontPage?

I agree. Maybe it should be called "related literature" in the 
documentation section.

> yes, layout.  I think the color is OK.

I think, layout and color is OK. I am more concerned with the contents 
of the left and right columns.

For example, I quite dislike the Download section. Newcomers don't have 
any idea what we mean by Gold and Silver branch. Although personally, I 
find gold and silver quite nice, but in general it is more clear if we 
call this "stable" and "unstable" for the general public.

Think about what you would like.

(1) Precompiled binaries
(2) Sources (as .tgz and tar.bz2 and .zip)
(3) CVS/SVN/Arch access
(4) Browse sources online

All of that would refer to the stable (gold) release of the sources.

(1) Precompiled binaries
The corresponding page would just list the binaries and some note of how 
to install them.

(2) Sources (as .tgz and tar.bz2 and .zip)
(3) CVS/SVN/Arch access
Maybe these two points could be just one and be called "Sources".
The corresponding page would first tell people about stable=gold, 
unstable=silver then have a section "Gold" and "Silver".
The Gold section comes with subsections
"Tarball" where the links to tgz and tar.bz2 and .zip are given 
directly, and
"Repository access" where it is described that we have CVS and TLA 
archives of GOLD and an algorithm (shell commands) of how to access the 
sources. Additionally, it should be stated that for contributing to 
Axiom one should use the Silver branch. (I know that could be argued.)

See
http://wiki.axiom-developer.org/SandboxAxiomSources
and tell me what you think.
(Could one have a table of contents at the top of that page?)

(4) Browse sources online
That should be something like the "Online Source" that currently exists.
But if you press "Online sources" currently it leads to
	
/mathaction/axiom--test--1/

I know it is irrelevant, but the "test" in the name is misleading. The 
page http://wiki.axiom-developer.org/axiom--test--1/FrontPage
(and archive) should rather be called "Axiom-Stable". Yes, not the same 
naming conventions as the tla archive. Bill, if you could write on top 
of that page that people are browsing the latest stable release, that 
would be wonderful.

I think the "Build Axiom" entry under download is unnecessary. There 
should be just a link from the "AxiomSources" page to the BuildAxiom 
page. And the BuildAxiom page should be cleaned up a bit.

\start
Date: Tue, 01 Aug 2006 12:26:27 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Build-Improvements

Dear Gaby,

last night, I've managed to compile silver/trunk. I've made a few 
changes to makefiles and some pamphlets in order to get rid of the problems.

Now the "re-copying of the .svn directory"-problem is no problem anymore.

There were some problems with pamphlet files, in particular bookvol1 and 
some others.

I really wonder what silver/trunk actually is. It is not Gold, since 
that "just works" and would not have latex problems.

Tim, could you put your "gold-to-be" branch to the public. I strongly 
believe that it should be *identical* with silver/trunk. You need not 
care about the SVN archive, but it would be necessery to **see** your 
latest development even if it does not *just work*. It is totally clear 
for all developers that Silver does not 100% have the "just works" 
predicate.

Gaby, I have now seen that there is a branch build-improvements. 
Currently, I worked on the trunk, but perhaps you tell me it is better 
if I commit my modifications to 'build-improvements'.

Gaby, Antoine, Tim, could you also add a few lines to the bottom of
http://wiki.axiom-developer.org/SandboxAxiomSources
Thank you.

\start
Date: Tue, 01 Aug 2006 13:58:16 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Wiki-Edit Problem

Hi Bill,

Is the FAQ page special?

http://wiki.axiom-developer.org/FAQ/editform

Even if I give a reason it doesn't let me save it.

\start
Date: Tue, 01 Aug 2006 14:00:06 +0200
From: Ralf Hemmecke
To: list
Subject: ${SRC}/scripts/Makefile

Could someone explain the target

${SRC}/scripts/Makefile:

in chunk <<scriptsdir>> in src/Makefile.pamphlet?

${SRC}/scripts/Makefile: ${SRC}/scripts/Makefile.pamphlet
	@echo 2 making ${SRC}/scripts/Makefile from \
            ${SRC}/scripts/Makefile.pamphlet
	@( cd scripts ; \
            ${DOCUMENT} ${NOISE} Makefile ; \
            cp Makefile.dvi ${MNT}/${SYS}/doc/src/scripts.Makefile.dvi )

I don't see that this chunk creates src/scripts/Makefile. It's a bit weird.

\start
Date: 01 Aug 2006 15:28:16 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Build-Improvements

Ralf Hemmecke writes:

| Dear Gaby,
| 
| last night, I've managed to compile silver/trunk. I've made a few
| changes to makefiles and some pamphlets in order to get rid of the
| problems.
| 
| Now the "re-copying of the .svn directory"-problem is no problem anymore.

This is great news!

| There were some problems with pamphlet files, in particular bookvol1
| and some others.

Yes, bookvol1 has issues I could not solve last night (because of lack
of time and I was tired).

| I really wonder what silver/trunk actually is. It is not Gold, since
| that "just works" and would not have latex problems.

To my mind, it is what we agreed on last april.

| Tim, could you put your "gold-to-be" branch to the public. I strongly
| believe that it should be *identical* with silver/trunk. You need not
| care about the SVN archive, but it would be necessery to **see** your
| latest development even if it does not *just work*. It is totally
| clear for all developers that Silver does not 100% have the "just
| works" predicate.
| 
| Gaby, I have now seen that there is a branch
| build-improvements. Currently, I worked on the trunk, but perhaps you
| tell me it is better if I commit my modifications to
| 'build-improvements'.

yes, please put it there.  Add brief descriptions of changes in the
corresponding ChangeLog files.

| Gaby, Antoine, Tim, could you also add a few lines to the bottom of
| http://wiki.axiom-developer.org/SandboxAxiomSources
| Thank you.


Thanks for doing this.

\start
Date: Tue, 1 Aug 2006 10:12:18 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Wiki-Edit Problem

Ralf,

You should be able to edit it now. I had to get rid of the
HTML href links. These are not allowed on Axiom Wiki right now
in order to prevent link spam. You must use the format

  "link text":http://....

instead.

Regards,
Bill Page.

> -----Original Message-----
> 
> Hi Bill,
> 
> Is the FAQ page special?
> 
> http://wiki.axiom-developer.org/FAQ/editform
> 
> Even if I give a reason it doesn't let me save it.

\start
Date: Tue, 01 Aug 2006 16:56:35 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Build-Improvements

Hi Gaby,

> | Now the "re-copying of the .svn directory"-problem is no problem anymore.
> 
> This is great news!

That is revision 75 now in branches/build-improvements

> | There were some problems with pamphlet files, in particular bookvol1
> | and some others.
> 
> Yes, bookvol1 has issues I could not solve last night (because of lack
> of time and I was tired).

Me too, actually, I hope I did not make a mistake somewhere.
But before other people could check out and test build-improvements, you 
should merge with trunk. I have deliberately not put the unescaped "&" 
problem that appears in src/input/zimmer.input.pamphlet since I have 
seen that you have already committed a fix to trunk.

> | I really wonder what silver/trunk actually is. It is not Gold, since
> | that "just works" and would not have latex problems.

> To my mind, it is what we agreed on last april.

But is silver/trunk now identical to Tim's "gold-to-be" branch?

> yes, please put it there.  Add brief descriptions of changes in the
> corresponding ChangeLog files.

Done. But cannot we also use SVN to generate the ChangeLog file from the 
SVN log? Or is this not common practice?

Hope things work out fine now. The build process needs a lot of clean 
up. It is very hard for a human to understand the relation of the makefiles.

\start
Date: 01 Aug 2006 17:15:04 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Build-Improvements

Ralf Hemmecke writes:

| Hi Gaby,
| 
| > | Now the "re-copying of the .svn directory"-problem is no problem anymore.
| > This is great news!
| 
| That is revision 75 now in branches/build-improvements

Thanks.

| > | There were some problems with pamphlet files, in particular bookvol1
| > | and some others.
| > Yes, bookvol1 has issues I could not solve last night (because of
| > lack
| > of time and I was tired).
| 
| Me too, actually, I hope I did not make a mistake somewhere.

I just fired up a build; I'll tell you :-)

| But before other people could check out and test build-improvements,
| you should merge with trunk. I have deliberately not put the unescaped
| "&" problem that appears in src/input/zimmer.input.pamphlet since I
| have seen that you have already committed a fix to trunk.
| 
| > | I really wonder what silver/trunk actually is. It is not Gold, since
| > | that "just works" and would not have latex problems.
| 
| > To my mind, it is what we agreed on last april.
| 
| But is silver/trunk now identical to Tim's "gold-to-be" branch?

To my mind, there certainly will be things that need more testing
before they become candidate for inclusion in the official release
(Gold).  So, I see Gold as almost a subset of silver, in the 
sense that it contains mature stuff and silver may contain more
experimental facilities or improvements that are not ready yet for gold.
silver is kind of "preview."

For this to work out correctly, we need to know what patches are
applied to Gold.  That is, we don't require that Tim also maintain
Silver. But, Tim should send patches he applies to Gold or whateter
"fixed in the next release" refers to.  In other word, we need some
kind of "public record".

| > yes, please put it there.  Add brief descriptions of changes in the
| > corresponding ChangeLog files.
| 
| Done. But cannot we also use SVN to generate the ChangeLog file from
| the SVN log? Or is this not common practice?

Well, usually when I make modification, I describe that modification
right away in the ChangeLog before thinking of commit.  That way I
don't forget about things, hours or days later, when it comes to
commit.  That is why it is not common practice -- from my exprience.
But if you find it easier for you; that is OK too.  As long as we have
a "history" file that is not SVN oriented. 

| Hope things work out fine now. The build process needs a lot of clean
| up. It is very hard for a human to understand the relation of the
| makefiles.

Yup.  I'll commit in a moment an initial setup where I have just
"translated" the existing configure.  Then I'll move more work there.
Ideally, I would like to see this finished before end of month --
before I point students to working on/with Axiom.

\start
Date: Tue, 1 Aug 2006 11:14:10 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Build-Improvements

> But is silver/trunk now identical to Tim's "gold-to-be" branch?

I'll diff my latest with patch-49 and post the diffs.
But that has to be later. I have an impressive work schedule to do first.

\start
Date: Tue, 1 Aug 2006 12:11:30 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Front page esthetic

Gaby,

On August 1, 2006 12:40 AM you wrote:
> ... 
> Why is having the front-page as wiki a plus?
> For all I know, only a handful of people can actually modify 
> that page.

Although the FrontPage is the FrontPage of the Axiom Wiki, unlike
other pages on the wiki, we decided not to let visitors modify it,
otherwise we might be just a little to open to vandalism. So for the
Axiom Wiki FrontPage it is true that only a handful of people can
actually modify it.

> For other pages, due to irritating spams, the system has made it
> complicated for good citizens to contribute changes.

Why do you think it is "complicated for good citizens to contribute
changes"? I think it is very very significant (and disappointing to
me) that you perceive the Axiom Wiki this way. What can we do to
assure everyone that it fact that it is easy to contribute changes?
Afterall, that is the main reason that it is a Wiki.

> I don't see a difference between that and maintaining the website
> files as part of the SVN or CVS repository.  The latter seems
> simpler to me -- but I'm not proposing it.  Just observing.
> ...

This is another very important observation. I have to admit that
contrary to my "great expectations" it seems to me that so far we
have gained very little benefit from trying to maintain the Axiom
website as a wiki. It is true (for the most part) that the maintenance
of the contents of the Axiom web site (with the obvious exception of
the live Axiom and Reduce interface) could have been done using CVS
on Savannah or SourceForge. Contrary to the intent of the wiki, it
seems that almost all of the contributions to the Axiom web site
have been by people who are also active Axiom developers and are
quite familiar with using tools like CVS.

As I have said several times already, I am quite disappointed by
the lack of active contributions to the Axiom Wiki. Perhaps people
just do not have time or the motivation? I would be very surprised
if the reason was because they found it difficult to do, although
there does seem to be a considerable reluctance for people to view
the web as a two-way media where they can (or even are expected to)
contribute content. It seems to me that this is more a "cultural"
issue than a technical one.

In the last couple of years the only wildly successful wiki-based
project that I can think of is Wikipedia. At the present time the
only explanation I have for this is that apparently the ratio of
the number of people willing to contribute to the number of people
who just visit for information is very small - maybe as high as
1 out of 100,000. This would be consistant with the success of
Wikipedia and also the level of contribution that we see in Axiom
Wiki based on our month access statistics.

Anyway, I would very much like to hear from other Axiom developers
about the issue of whether it makes sense to continue to try to
maintain the main Axiom web site as a Wiki.

\start
Date: Tue, 1 Aug 2006 20:39:15 +0200
From: Antoine Hersen
To: Bill Page
Subject: Re: Front page esthetic

Hello,

Summer cleaning !!!

I also think the web page is too cluttered.

There is three category of people new comers, user and contributors.

About the new comers : we are competing to get their attention and time.

We need to be very good at it because Axiom is complex so it is not going to
be an easy  sell.

For them it should be the principle of minimum surprise and maximum
simplicity.
( Next  is a description of me looking at a project I might use, therefore
interpret the "I want" has I really expect to see)

If their is two column I will only read the left one.
(When we discuss the web page with Ralf today I even had forgotten about the
right one I remember only the logo and was surprise to see link.)
Also I expect the "This site" to be on the top right corner.
Our current top of the page do not make any sense, it is pure confusion to
me.

Also the left menu is too long, and redundant :
 Audio/visual <http://wiki.axiom-developer.org/AxiomScreenCast>  audio ???
not common confusing.
Press releases <http://wiki.axiom-developer.org/PressReleases> I have doubt
the general press is going to be interested by us really soon.
Gold Silver , the Olympics maybe ?

What I like is a News section where I can see that a project is alive.
( Also I like a related project link where I can see other CAS, I love it, I
think it is fair play)

I want a "Description" two page long maximum with what is Axiom what is
special and great about it.
I want a screen shoot , yes sorry I always want a screen shoot even for a
cmd line programs.
And then I want a Download with maybe some binary but for sure a tgz of the
source.
I will grab it, type ./configure, make, make install and try.

Then I am going to look for a good introduction. And I hate it when people
give me choice I want the one and definitive introduction. I will read
between 5 and 20 pages max. Any document that go over 100 pages will scare
me to death. A good indicator for me is if I feel ok to print it.
And if I survive I will look for more advanced material.

For the axiom user. We should not expect him to subscribe to the mailing
list.
He will go to the web page to solve his problems and get new version.
Here it is good FAQ, oriented tutorial, documentation and search able mail
list.
Subscribing to a mailing list is a big step, we should not expect people to
do it.

For active user/ contributors/ developer what is needed is a collaboration
tool, I have no answer for that.

Personally I find the wiki difficult to use, it seem a big mess to me and I
spend a lot of time looking for documents I saw before and know should be
somewhere. It lack structure and search will not replace that,  in general
giving a name to your problem is the difficult part.

When you look at the tree structure you see a big mess and all the bugs !

About people contribution :
I almost never find wiki useful.
Wiki as documentation is always an unpleasant mess.
I found comments useful( I think it is the MySQL documentation, it has user
comments at the end of each section, you always find clarification and
corner case described).

And modifying a page is not has easy at it sound. Writing correctly is time
consuming and difficult. I never feel like touching other people stuff. You
can often see it in a wiki where old information is rarely deleted.


So in the end it is a question of balance between people contribution and
time saved not doing it against mess and quality.

I think a fix web page with a few editors and keeping the wiki as a play
ground is the best solution. But easy to say because I am not volunteering
to be an editor.

Also just doing a good cleaning of the wiki might be what we need.

Regards
Antoine Hersen

\start
Date: Tue, 1 Aug 2006 15:21:09 -0400
From: Alfredo Portes
To: Antoine Hersen
Subject: Re: Front page esthetic

Hello everyone,

It seems that modifications to the axiom wiki frontpage has become a
hot topic. I do not see the frontpage that much cluttered, but surely
improvements can be made.

Compared to the other Computer Algebra Systems web pages, I do see the
axiom-developer much more advance and  more user friendly. Their idea
of simplicity, is having couple of links in a fix page, that has not
been updated in years. Simplicity in web pages is measured by: "can I
get what I need in the least amount of clicks".

I do think that probably axiom-developer should morph to a hybrid
between static pages and a wiki page similar to www.ubuntu.com. There
the wiki is used for collaboration among users. Maybe this could
reduce the work load on Bill that has to maintain the wiki, and the
fight the tedious spam problem.

I do not know what was the first expectation with the Wiki. In our
part (Doyen), the Wiki is the foundation of Tim's idea. Maybe it was
expected to do contributions to Axiom directly to the wiki, some kind
of online development environment. This to me is a great idea. But
apparently this is not occurring by reading Bill's comments.

For me the wiki is very useful. Everytime I have to remember some
comment, I need to improve the Doyen, I can find the information
really quick. The Wiki allows me also to see the work done for Axiom,
were it is right now, and the future plans. This cannot be done by
using static pages, and it is much faster than wasting time looking in
mailings lists.

Regarding the frontpage I think the audio/visual section should be
very relevant, together with screenshots. I think this is the
"screenshots" section in many pages, which usually is the most popular
to new comers.Probably more appealing screenshots are needed.

\start
Date: 01 Aug 2006 21:27:43 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Front page esthetic

Bill Page writes:

| Gaby,
| 
| On August 1, 2006 12:40 AM you wrote:
| > ... 
| > Why is having the front-page as wiki a plus?
| > For all I know, only a handful of people can actually modify 
| > that page.
| 
| Although the FrontPage is the FrontPage of the Axiom Wiki, unlike
| other pages on the wiki, we decided not to let visitors modify it,
| otherwise we might be just a little to open to vandalism. So for the
| Axiom Wiki FrontPage it is true that only a handful of people can
| actually modify it.

I don't propose we make the frontpage freely modifiable.  Quite the
contrary.  I'm very happy that only a handful of trusted people will
have write access to that page.  This is why I come to the observation
that having the frontpage as a wiki does not look to me like a plus or
an improvement over others sites we've been comparing to.

[...]

| This is another very important observation. I have to admit that
| contrary to my "great expectations" it seems to me that so far we
| have gained very little benefit from trying to maintain the Axiom
| website as a wiki. It is true (for the most part) that the maintenance
| of the contents of the Axiom web site (with the obvious exception of
| the live Axiom and Reduce interface) could have been done using CVS
| on Savannah or SourceForge. Contrary to the intent of the wiki, it
| seems that almost all of the contributions to the Axiom web site
| have been by people who are also active Axiom developers and are
| quite familiar with using tools like CVS.

Although I'm not a great fan of wiki (probably because I'm showing my
age :-)), I do understand and see what might be its benefits.  And as
a matter of fact, I've found some wiki pages very useful.

However, I find more useful to be able to work offline -- that is I
don't need to connect to the web before being able to browse the
wealth of information.  This is because I don't always work online.
Having the same (at least a good part of) information in some form
that does not require connectivity is great.  I don't propose we
duplicate effort.  I'm just observing.

| As I have said several times already, I am quite disappointed by
| the lack of active contributions to the Axiom Wiki.

In its current form, how many people (say posting to this list) know
Axiom, have time to document and go online and have fun with Wiki?

First, we need a critical mass.  Anything we can do to lower the entry
barrier is good.  I'm just giving my feedback about some of the
current setup.


[...]

| Anyway, I would very much like to hear from other Axiom developers
| about the issue of whether it makes sense to continue to try to
| maintain the main Axiom web site as a Wiki.

I don't propose you destroy eveything :-)

\start
Date: 01 Aug 2006 21:37:42 +0200
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: Front page esthetic

Alfredo Portes writes:

[...]

| For me the wiki is very useful. Everytime I have to remember some
| comment, I need to improve the Doyen, I can find the information
| really quick. The Wiki allows me also to see the work done for Axiom,
| were it is right now, and the future plans. This cannot be done by
| using static pages, and it is much faster than wasting time looking in
| mailings lists.

Most certainly I have not seen suggestions to replace the wiki with
mailing lists.  I believe everyone is for a good documentation
structure.  The issues I had in mind is how we can improve over the
current situations.  I was giving my feedback about what need
improvements. 

>From past experience, I've been able to find most information I need
about GCC by going directly to the main website and lookin up in the left
section (that changed last couple of week, but that is a different
story).

\start
Date: 01 Aug 2006 21:50:23 +0200
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] Requests for discussion


Hi,

   Instead of fiddling at infinitum with the new build machinery on my
local disk.  I decided to trim it down to something "simple" to
request feedback about some aspects of the work.

   The core goal is to move Axiom's build system to GNU Autotools which
have become quite standard now, in the Unix-world.

   For that I've converted the current configure file to configure.ac
(which Autoconf will use to regenerate configure).  The main
motivation here is factor out many platforms variability issues and
dump them on Autoconf -- who already knows how to solve them.

   Axiom has the requirement that the source files must be literate --
use of pamphlet files.  Autoconf expects its input to be in particular
form.  Furthermore, the pamphlet file requirement introduces an
unpleasant bootstrapping issue that will hopefully be resolved.
So, in its current form, I put the literate stuff in comments, so that
if you do

    cat configure.ac | sed -e 's/^## //' > configure.tex

you can an almost LaTeX file.  "Almost" because LaTeX commands need to
start with a backslash.  That character used to be reserved for line
continuation in shell world.  So to avoid any surprise, I used the
percent character (which unfortunately is LaTeX comment character).  So
to get the LaTeX document, one needs to apply another sed that
replaces the percent character with the backslash character.

I've tested that I can feed the file to Autoconf, get a configure file
out of it and launch a successful build.

This work is being done on the "build-improvements" branch -- and it
has not been committed there yet.

Before painting myself into a corner, I would like to have feedbacks
from all y'all.

Thanks.

-- Gaby

## %documentclass[12pt]{article}
## %usepackage{axiom}
## %usepackage[latin1]{inputenc}
## %usepackage[T1]{fontenc}
## %usepackage{fancyvrb}
## %usepackage{pslatex}
## %usepackage{url}

## %newcommand{%file}[1]{%textsf{#1}}
## %newcommand{%code}[1]{%texttt{#1}}
## %newcommand{%email}[1]{%url{#1}}
## %CustomVerbatimEnvironment{chunk}{Verbatim}{frame=none,fontsize=%small}

## %title{The Toplevel %file{configure.ac} File}
## %author{Gabriel Dos~Reis}
## 
## %begin{document}
## %maketitle
## 
## %begin{abstract}
##  ...
## %end{abstract}

## %section{Introduction}
## This is the top-level Autoconf file that sets up the minimum build
## environment for Axiom.  At the moment, the mainline version
## of Axiom is driven by %file{Makefile} pamphlet files.  This effort
## strives to move the build machinery to more abstract description
## and conventional ones.
## The task is compounded by the fact that the Axiom system is very 
## complex -- but much less complex, I suspect, than say GCC.  There does not
## seem to be good reasons why Axiom should build its own ghetto.
## 
## Autoconf supports two kinds of comments:
## %begin{enumerate}
## %item %code{dnl} style, and
## %item %code{%#} style.
## %end{enumerate}
## Comments introduced with %code{dnl} do not appear in the %file{configure}
## output file.  Comments starting with %code{%#} appear verbatim in the
## %file{configure} generated file.
## 
## I have been trying to write this Autoconf file so that it can
## eventually be processed by both Autoconf and noweb -- the currently en
## vogue literate programming tool used by Axiom.  To accommodate that
## requirement, I've strived for introducing noweb chunkname in
## %code{dnl}-style comments, whereas text intended to be part of the text
## processed by LaTeX is introduced by %verb!## !  This is so that the
## poor masochist who will be debugging the generated %file{configure} file
## (if he/she so elected) has a clue about where the macros are expanded
## from and what their purposes are.


## %section{Old Story}
## 
## The contents of top-level %file{configure} file from mainline is 
## reproduced below.  It will serve as the initial basis for the new,
## improved, build machinery.

## %begin{verbatim}
## # The sysname function uses uname -s to try to decode what kind of
## # system to build. Currently the return value of uname is mapped as
## #       Linux          --> linux
## #       MINGW32_NT-5.1 --> windows
## #       SunOS          --> Solaris9
## #       Fedora Core 3  --> fedora3
## #       freebsd        --> freebsd
## #
## # The solaris platform needs patch->gpatch, awk->gawk, tar->gtar
## 
## sysname () {
## if [ -f /etc/redhat-release ] ;
##  then 
##   SYSNAME=`cat /etc/redhat-release` 
##   if [ "$SYSNAME" = "Fedora Core release 3 (Heidelberg)" ] ; 
##    then SYSNAME=fedora3
##   fi
##   echo SYSNAME=$SYSNAME
## fi
## if [ ! "$SYSNAME" = "fedora3" ] ; 
##  then
##    SYSNAME=`uname -s`
##    echo $SYSNAME 
##    if [ "$SYSNAME" = "Linux" ] ; then SYSNAME=linux
##    elif  [ "$SYSNAME" = "MINGW32_NT-5.1" ] ; then SYSNAME=windows
##    elif  [ "$SYSNAME" = "SunOS" ] ; then SYSNAME=solaris9
##    elif  [ "$SYSNAME" = "freebsd" ] ; then SYSNAME=freebsd
##    else
##      echo Your system name is $SYSNAME
##      echo We do not know how to build for this kind of system
##      echo Send a note to list about it
##      echo
##      exit 0
##    fi
## fi
## 
## }
## 
## # This function checks for the gawk command. 
## # If it exists then AWKNAME is the complete pathname
## 
## checkgawk() {
## AWKNAME=`which gawk 2>>trace`
## if [ -n "$AWKNAME" ] ; then
##  if [ -x $AWKNAME ] ; then 
##   echo 
##  fi
## fi
## }
## 
## # This function checks for the nawk command. 
## # If it exists then AWKNAME is the complete pathname
## 
## checknawk() {
## AWKNAME=`which nawk 2>>trace`
## if [ -n "$AWKNAME" ] ; then
##  if [ -x $AWKNAME ] ; then 
##   echo 
##  fi
## fi
## }
## 
## # This function checks for the awk command. 
## # If it exists then AWKNAME is the complete pathname
## 
## checkawk() {
## AWKNAME=`which awk 2>>trace`
## if [ -n "$AWKNAME" ] ; then
##  if [ -x $AWKNAME ] ; then 
##   echo 
##  fi
## fi
## }
## 
## # This function uses the check*awk functions to decide 
## # whether the system can build noweb. If one of gawk, nawk or awk
## # are not found we fail.
## needAwk ()
## {
## checkgawk
## if [ -z "$AWKNAME" ] ; then
##   checknawk
##   if [ -z "$AWKNAME" ] ; then
##     checkawk
##     if [ -z "$AWKNAME" ] ; then
##       echo We need the commands gawk, nawk, or awk
##       exit 0
##     fi
##   fi
## fi
## }
## 
## # The mustSet function tells the user what needs to be typed on the 
## # command line. If any extra variables need to be set we add them here.
## # Currently the only thing we check if for the presence of gawk, which
## # is the default in the Makefile. If gawk does not exist we can use 
## # either nawk or awk but the user has to specify that on the command line.
## 
## # We check the system we are using with the uname command and try to
## # generate the appropriate value. We fail otherwise.
## 
## # We generate the appropriate command line that the user should use.
## 
## mustSet() {
## echo
## echo ===================================================
## echo You must set your AXIOM and PATH variables. Type:
## echo
## echo To build the rest of the system type:
## echo
## echo export AXIOM=`pwd`/mnt/$SYSNAME
## echo 'export PATH=$AXIOM/bin:$PATH'
## if [ "$SYSNAME" = "freebsd" ] ; then
##   echo Note that freebsd usually has noweb available
##   echo If you wish to use the standard version you must type
##   echo touch noweb 
##   echo If you wish to use a pre-installed GCL you must type
##   echo make GCLVERSION=gcl-system
## fi
## if [ "$SYSNAME" = "solaris9" ] ; 
##  then echo make AWK=gawk TAR=gtar PATCH=gpatch
## elif [ "`basename $AWKNAME`" = "gawk"  ] ; 
##  then echo make
##  else echo make AWK=$AWKNAME
## fi
## echo
## echo configure finished.
## }
## 
## #########################################################################
## # This is the main line of configure logic.
## # (1) We test to see if we understand this system name. So far
## #     the recognized strings from uname -s are translated as:
## #       Linux          --> linux
## #       MINGW32_NT-5.1 --> windows
## #       SunOS          --> Solaris9
## #       Fedora Core 3  --> fedora3
## #       freebsd        --> freebsd
## # (1) We test for the AWK variable. We need one of gawk, nawk, or awk
## #     in order to build the noweb software.
## # (2) Then we output the final message for the user.
## #
## # The solaris platform needs patch->gpatch, awk->gawk, tar->gtar
## #########################################################################
## 
## sysname
## needAwk
## 
## if [ "x$AXIOM" = "x" ] ;
##  then mustSet
##  else 
##   if [ ! "`dirname $AXIOM`" = "`pwd`/mnt" ]
##     then mustSet
##     else 
##      echo Configure complete. Now type
##      echo
##      echo make
##      echo
##   fi
## fi
## %end{verbatim}


## %section{Basic Setup}
## %subsection{Autoconf Initialization}
## 
## The Autoconf machinery needs to be initialized with several pieces of
## information:
## %begin{itemize}
## %item the %emph{name} of the system --- ``Axiom silver branch''
## %item its %emph{version}.  I choose to use the date of last checkin.
##   It should probably include the revision number so as to 
##   unambiguously identify which Axiom flavour du jour is being
##   built;
## %item and where to send feedback, %emph{e.g.} bug reports.  I have chosen
##   the %email{axiom-developer} list.  That could change in the future if
##   we reach a high volume traffic.  For the moment, we don't seem to
##   suffer from traffic...
## %end{itemize}
dnl %begin{chunk}
AC_INIT([Axiom silver branch], [2006-07-15], [list])
dnl %end{chunk}

## Autoconf needs some auxilary files that are present in the sub-directory
## %file{config}.  Autoconf needs to be told about that.
dnl %begin{chunk}
AC_CONFIG_AUX_DIR(config)
dnl %end{chunk}

## Notice that since we don't use Automake (yet), we don't initialize
## the Automake subsystem.  

## We require Autoconf 2.59 or higher from the developer part. Please,
## note that this is no requirement on the user build environment.  All,
## it means is that if someone makes changes to the current %file{configure.ac}
## file, that someone needs to have Autoconf 2.59 or higher to process this
## file in order to regenerate %file{configure}.
dnl %begin{chunk}
AC_PREREQ([2.59])
dnl %end{chunk}

## The Autoconf system implements a very basic, simple-minded, sanity check
## whereby it will refuse to run %file{configure} if the source tree does
## not contain a specified file, that serves a witness for a bona fide source
## tree.  Here, I have chosen %file{Makefile.pamphlet} from the %file{src}
## subdirectory.
dnl %begin{chunk}
AC_CONFIG_SRCDIR(src/Makefile.pamphlet)
dnl %end{chunk}


## %subsection{Build Environment}
## 
## Standard build environments consist of
## %begin{enumerate}
## %item the %emph{host} platform,
## %item the %emph{build} platform, and
## %item the %emph{target} platform.
## %end{enumerate}
## FIXME: Example on these notions.
## 
## Get the canonical names for the above three platforms.  After call to
## this macro, those values are available in the variables %code{host},
## %code{build}, and %code{target}, respectively.
dnl %begin{chunk}
AC_CANONICAL_SYSTEM
dnl %end{chunk}

## For the moment, we don't support cross-compiling, nor Canadian cross.
## Consequently, we must bail out if the build is not native.
dnl %begin{chunk}
if test $host != $build -o $host != $target; then
   AC_MSG_ERROR([Sorry, only native builds are currently supported])
fi
dnl %end{chunk}

## Check for a C compiler, %textsl{GCC/gcc} preferably.
dnl %begin{chunk}
AC_PROG_CC
dnl %end{chunk}

## Check for a usable 'install' program.
dnl %begin{chunk}
AC_PROG_INSTALL
dnl %end{chunk}


## The old build machinery needs 'awk'.  Currently, it checks for
## 'gawk', 'nawk', and 'awk'.  Autoconf has a predefined test for that
## task.  It checks for 'gawk', 'mawk', 'nawk', and 'awk' in that order.
## That should be OK and match Axiom's need.

## The old build system claims that on solaris9, gawk, gtar 
## and gpatch are required (with no much explanation of why).  Notice
## that these programs are needed only to build Axiom; so we do
## check based on the value of %code{build}.
dnl %begin{chunk}
case ${build} in
     *-solaris9)
        AC_CHECK_PROG([AWK], [gawk], 
                      [gawk], [AC_MSG_ERROR([Axiom needs gawk])])

        AC_CHECK_PROG([TAR], [gtar], 
                      [gtar], [AC_MSG_ERROR([Axiom needs gtar])])

        AC_CHECK_PROG([PATCH], [gpatch],
                      [gptach], [AC_MSG_ERROR([Axiom needs gpatch])]) 
        ;;

      *)
        AC_PROG_AWK

        AC_CHECK_PROGS([TAR], [gtar tar], 
                       [AC_MSG_ERROR([Axiom needs a tar program])])

        AC_CHECK_PROGS([PATCH], [gpatch patch], 
                       [AC_MSG_ERROR([Axiom needs a patch program])])
        ;;
esac
dnl %end{chunk}


## Once we have found those values, we must substitute them in the
## Makefiles.  For the moment, these actions are effectless as the
## current makefile are hand-written and Autoconf-unaware.
dnl %begin{chunk}
AC_SUBST(AWK)
AC_SUBST(TAR)
AC_SUBST(PATCH)
dnl %end{chunk}

## Obviously we need the 'make' program.  No build will proceed without
## it.
dnl %begin{chunk}
AC_CHECK_PROG([MAKE], [make],
              [make], [AC_MSG_ERROR([`make' program missing.])])

dnl %end{chunk}

## Here, we replicate the behaviour of the old configure, waiting for
## a better alternative, e.g. where it is not needed.  THIS WILL BE
## REMOVED IN THE NEAR FUTURE.

## First, the old machinery has a very coarse target name "discovery"
dnl %begin{chunk}
if test -f /etc/redhat-release; then 
   SYSNAME=`cat /etc/redhat-release` 
   if test "$SYSNAME" = "Fedora Core release 3 (Heidelberg)"; then
       SYSNAME=fedora3
   fi
   AC_MSG_NOTICE([SYSNAME=$SYSNAME])
fi
if test "$SYSNAME" != "fedora3"; then
   SYSNAME=`uname -s`
   AC_MSG_NOTICE([$SYSNAME])
   case "$SYSNAME" in
      Linux)
	 SYSNAME=linux ;;
      MINGW32_NT-5.1)
	 SYSNAME=windows ;;
      SunOS)
	 SYSNAME=solaris9 ;;
      freebsd)
	 ;;
      *)
	 AC_MSG_NOTICE([Your system name is $SYSNAME])
	 AC_MSG_NOTICE([We do not know how to build for this kind of system])
	 AC_MSG_ERROR([Send a note to list about it])
   esac
fi

must_set_AXIOM() {
   AC_MSG_NOTICE([])
   AC_MSG_NOTICE([===================================================])
   AC_MSG_NOTICE([])
   AC_MSG_NOTICE([You must set your AXIOM and PATH variables. Type:])
   AC_MSG_NOTICE([])
   AC_MSG_NOTICE([export AXIOM=`pwd`/mnt/$SYSNAME])
   AC_MSG_NOTICE([export PATH=\$AXIOM/bin:\$PATH])
   case "$SYSNAME" in
      freebsd)
	 AC_MSG_NOTICE([Note that freebsd usually has noweb available])
	 AC_MSG_NOTICE([echo If you wish to use the standard version you must type])
	 AC_MSG_NOTICE([touch noweb])
	 AC_MSG_NOTICE([If you wish to use a pre-installed GCL you must type])
	 AC_MSG_NOTICE([make GCLVERSION=gcl-system])
         ;;
      solaris9)
         AC_MSG_NOTICE([make AWK=gawk TAR=gtar PATCH=gpatch])
         ;;
      *)
         AC_MSG_NOTICE([make AWK=$AWK])
   esac
}

if test "x$AXIOM" = "x"; then
   must_set_AXIOM
elif test "`dirname $AXIOM`" != "`pwd/mnt`"; then
   must_set_AXIOM
else
   AC_MSG_NOTICE([configure complete.  Now type ])
   AC_MSG_NOTICE([                              ])
   AC_MSG_NOTICE([make])
   AC_MSG_NOTICE([                              ])
   AC_MSG_NOTICE([export AXIOM=`pwd`/mnt/$SYSNAME])
   AC_MSG_NOTICE([export PATH=\$AXIOM/bin:\$PATH])
fi
dnl %end{chunk}

## %end{document}

\start
Date: Tue, 1 Aug 2006 16:03:32 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: Re: Front page esthetic

Hi Gaby,

On 01 Aug 2006 21:37:42 +0200, Gabriel Dos Reis
Gabriel Dos Reis wrote:

> | For me the wiki is very useful. Everytime I have to remember some
> | comment, I need to improve the Doyen, I can find the information
> | really quick. The Wiki allows me also to see the work done for Axiom,
> | were it is right now, and the future plans. This cannot be done by
> | using static pages, and it is much faster than wasting time looking in
> | mailings lists.
>
> Most certainly I have not seen suggestions to replace the wiki with
> mailing lists.  I believe everyone is for a good documentation
> structure.  The issues I had in mind is how we can improve over the
> current situations.  I was giving my feedback about what need
> improvements.

There was not direct mention of mailing list, but previous posts
mentioned that they did not see the use of the Wiki. Wikis are a
better way of collaboration. You can see how every major Open Source
project have put in place a wiki for this purpose.

> From past experience, I've been able to find most information I need
> about GCC by going directly to the main website and lookin up in the left
> section (that changed last couple of week, but that is a different
> story).

I do agree with you that maybe certain things could be done in the
front page to access the information faster. This is always the goal.
Probably improvement to the links can be done. Bill has pointed out
that the wiki has an index in the frontpage. I did not know that and
it is very useful. Maybe it should be place in another place, more
visible in the frontpage. Also, including a Search label, for the
label text box, maybe people miss it some times.

I just wanted to comment in the importance of the Wiki and the great
work that the
axiom-developer wiki is.

\start
Date: Tue, 1 Aug 2006 16:04:02 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: ${SRC}/scripts/Makefile

On Tuesday, August 01, 2006 8:00 AM Ralf Hemmecke wrote:
>
> Could someone explain the target
>
> ${SRC}/scripts/Makefile:
>
> in chunk <<scriptsdir>> in src/Makefile.pamphlet?
>
> ${SRC}/scripts/Makefile: ${SRC}/scripts/Makefile.pamphlet
> 	@echo 2 making ${SRC}/scripts/Makefile from \
>             ${SRC}/scripts/Makefile.pamphlet
> 	@( cd scripts ; \
>             ${DOCUMENT} ${NOISE} Makefile ; \
>             cp Makefile.dvi
> ${MNT}/${SYS}/doc/src/scripts.Makefile.dvi )
>
> I don't see that this chunk creates src/scripts/Makefile.
> It's a bit weird.
>

The untangle that creates Makefile is embedded in the script
${DOCUMENT} = 'document'. I agree that it is a bit obscure.
Probably it should be separate.

You can find 'document' in the src/scripts directory.

\start
Date: Tue, 01 Aug 2006 22:21:30 +0200
From: Ralf Hemmecke
To: Antoine Hersen
Subject: Re: Front page esthetic

First of all, I'd like to thank Bill for all the effort he has put into
the Wiki.

In some points I must, however, agree with Antoine. The current Wiki
currently is a bit of a mess. There are only a few pages that are of
real value. You know, when I started I had hard times to find my way
through the information that I was looking for and even now I don't find
things that I am looking for in a few clicks.

Until somebody posted the BeBold principle to the mailing list I was
always hesitating not to edit/delete too much of the existing
information, but surely that slowed down improvements to the wiki. Now I
am a bit bolder, but it is still hard.

If I look now at some pages, I would rather like to see that information
organised in a different way, but different from a text in a
text-editor, I cannot simply drag & drop text from one page to another.
Well, I should have open several browser windows, I know.

What is also important is some more structure of the wiki. I am
personally used to linear text with sections and subsections, ie, some
kind of hierarchy. We should have a number of standard pages that can be
edited only by registered Axiom-developers. These pages should not
change too much once they are set up. But hey, until now we only had
problem with spam, but not with people willingly destroying pages. So
restricting the wiki idea at this stage of Axiom is an unnecessary
effort, there are too few edits anyway. To ALL: Start improving the wiki
pages!!! If you don't like something then change it!!!

Bill, what I would like to see on top of an edit page is a link to
BeBold. Furthermore, it should be said that the first paragraph of the
page is a kind of abstract that is used for the "SiteMap" (which can be
considered as a kind of glossary, if you like).

Actually, I would also like to have some facility that let's me move the
  pages in the tree structure of the wiki. Best would be to see the tree
and take my mouse to move pages in the hierarchy.

> About the new comers : we are competing to get their attention and
> time.

> If their is two column I will only read the left one.

I feel the same, but the right column doesn't disturb me too much. In
fact, I like it, since it gives related material. Only having both "Site
Index" and "Site Map", I find a bit confusing. Maybe one should be
called by a more appropriate name. I cannot easily guess what is what. I
don't like to see the IssueTracker pages on the siteindex/sitemap. It is
too distracting from the hierarchy view.

> I want a "Description" two page long maximum with what is Axiom what
> is special and great about it.

Don't we have it somewhere? Haven't I seen this on one of Tim's pages?

> And then I want a Download with maybe some binary but for sure a tgz
> of the source.

Yes, I have already put a section into SandboxAxiomSource. I just don't
know where the .tgz and friends are. Or would just a file be just too
huge? In that case we declare on SandboxAxiomSource why we don't give a
.tgz file.

> Then I am going to look for a good introduction. And I hate it when 
> people give me choice I want the one and definitive introduction.

I think we should take this consideration seriously. Currently
"Tutorial" links to "AxiomInterface" (very intuitive!) and gives not a
tutorial. I rather think that we should maybe give a weighted list of
introductory material.

http://www.dcs.st-and.ac.uk/~mnd/documentation/axiom_tutorial

The above tutorial looks quite reasonable to me. The tutorial page
should not be like a sandbox were everyone just adds his/her commands.

I hate everything on http://wiki.axiom-developer.org/AxiomInterface that
comes after the "That was easy!". It should go away, because it looks
unprofessional.

> I will read between 5 and 20 pages max. Any document that go over 100
> pages will scare me to death.

So the Axiom Book should come at the end of the tutorial under "Further 
Reading".

> And modifying a page is not has easy at it sound. Writing correctly
> is time consuming and difficult. I never feel like touching other
> people stuff. You can often see it in a wiki where old information is
> rarely deleted.

I also felt like it. We all know that we can unroll changes, but what I 
don't know is, whether everyone can do it. It should be more obvious how 
things can and will be undone if people are too bold. Another suggestion 
that should be visible on top of an edit-page.

I also think we should have a mixture of pages that only a few people 
can edit and freely editable pages. But I strongly think that it is too 
early to make that distinction. We first need more people who edit at all.

\start
Date: Tue, 1 Aug 2006 16:20:23 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Front page esthetic

Gaby,

On Tuesday, August 01, 2006 12:40 AM you wrote:
> ...
> | > Important to me is that the front-page must send the message
> | > that this is related to research.  Yes, we have links to workshops
> | > and all that.  But, most importantly, links to research papers
> | > related to Axiom must be clearly and unambiguously linked from
> | > there --
> |
> | Are you aware of the Axiom bibliography on the Axiom Portal?
> |
> | http://portal.axiom-developer.org/refs
>
> Yes, I do.
>
> | Maybe this deserves a link on the Axiom Wiki FrontPage?
>
> This is precisely what I suggested in the message I sent
> (yesterday I believe) to axiom-mail.

Your email to axiom-mail was queued along with the usual 30 or so
spam messages because when you sent the message to axiom-mail you
were not registered as a user (at least not under the email address
that you used to send the message). The amount of spam these days
is simply horrendous so the chances are quite high that if you
are not registered as a user first before sending an email to the
list, it will might well be deleted. I try to review the queued
"spam candidates" at least once a day but I don't give more than
a few seconds to each email before hitting the "discard" button.

I suppose that you got a bounce message from the email list saying
that it had been held. Right?

In this case I did happen to see your email, so I hit "pass" and
it has just been distributed to the list.

\start
Date: Tue, 01 Aug 2006 22:29:33 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Build-Improvements

Tim, wouldn't it be easier to just put your "gold-to-be" archive as a 
tla mirror to the web? So we would always be up-to-date.

Ralf

On 08/01/2006 05:14 PM, root wrote:
>> But is silver/trunk now identical to Tim's "gold-to-be" branch?
> 
> I'll diff my latest with patch-49 and post the diffs.
> But that has to be later. I have an impressive work schedule to do first.

\start
Date: Tue, 01 Aug 2006 22:40:34 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Front page esthetic

> However, I find more useful to be able to work offline -- that is I
> don't need to connect to the web before being able to browse the
> wealth of information.  This is because I don't always work online.

Right, that was also one of my concerns some time ago. Bill helped be 
quite a lot with mirrory the Wiki locally on my computer, but I must say 
that it did not make me completely happy. I would have to download a big 
zope database and I cannot easily push back changes that I would make 
locally to the wiki. It is just too much to install and not everything 
works perfectly. I would also be happy to have all the information 
available when I am offline, work on Axiom and commit modifications back 
to a server so that they become visible for others.

I think currently the Wiki should be a means to attract people and maybe 
to try out axiom commands only. But I am very much in favour of putting 
valuable information into the SVN/TLA repositories. Maybe the volume 
about axiom development is a good place to describe the building process 
more accurately. But that is "Further Reading" for an ordinary axiom 
user. ;-)

\start
Date: Tue, 01 Aug 2006 22:53:23 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: ${SRC}/scripts/Makefile

On 08/01/2006 10:04 PM, Page, Bill wrote:
> On Tuesday, August 01, 2006 8:00 AM Ralf Hemmecke wrote:
>> Could someone explain the target
>>
>> ${SRC}/scripts/Makefile:
>>
>> in chunk <<scriptsdir>> in src/Makefile.pamphlet?
>>
>> ${SRC}/scripts/Makefile: ${SRC}/scripts/Makefile.pamphlet
>> 	@echo 2 making ${SRC}/scripts/Makefile from \
>>             ${SRC}/scripts/Makefile.pamphlet
>> 	@( cd scripts ; \
>>             ${DOCUMENT} ${NOISE} Makefile ; \
>>             cp Makefile.dvi 
>> ${MNT}/${SYS}/doc/src/scripts.Makefile.dvi )
>>
>> I don't see that this chunk creates src/scripts/Makefile. 
>> It's a bit weird.
>>
> 
> The untangle that creates Makefile is embedded in the script
> ${DOCUMENT} = 'document'. I agree that it is a bit obscure.
> Probably it should be separate.
> 
> You can find 'document' in the src/scripts directory.

If this is the case then the literate document describing the target
${SRC}/scripts/Makefile should mention this behaviour. (And better 
still, the Makefiles would be linked together and a click on ${DOCUMENT} 
jumps to its definition and maybe from value of DOCUMENT there is a link 
to the file and another click into the .dvi and my editor opens inside 
the documentation of the "document" command.)

We have a long way to go...

\start
Date: Tue, 01 Aug 2006 23:35:55 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [build-improvements] Requests for discussion

Does that help you? I am running debian sarge.
I don't see a ./config file in that directory.

woodpecker:~/OTHER/Axiom/Silver/build-improvements>uname -a
Linux woodpecker 2.6.11-rc4 #3 Thu Feb 23 14:31:45 CET 2006 i686 GNU/Linux
woodpecker:~/OTHER/Axiom/Silver/build-improvements>autoconf configure.ac 
 > configure
woodpecker:~/OTHER/Axiom/Silver/build-improvements>./configure
configure: error: cannot find install-sh or install.sh in config ./config

\start
Date: Tue, 1 Aug 2006 17:49:13 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: [build-improvements] Requests for discussion

Gaby,

On Tuesday, August 01, 2006 3:50 PM you wrote:
>
>   Instead of fiddling at infinitum with the new build machinery on
> my local disk.  I decided to trim it down to something "simple" to
> request feedback about some aspects of the work.
>
>   The core goal is to move Axiom's build system to GNU Autotools
> which have become quite standard now, in the Unix-world.

Yes! ++1

>
>    For that I've converted the current configure file to
> configure.ac (which Autoconf will use to regenerate configure).
> The main motivation here is factor out many platforms variability
> issues and dump them on Autoconf -- who already knows how to solve
> them.
>
>    Axiom has the requirement that the source files must be
> literate -- use of pamphlet files.  Autoconf expects its input to
> be in particular form.  Furthermore, the pamphlet file requirement
> introduces an unpleasant bootstrapping issue that will hopefully
> be resolved.

Are you referring to the problem of the noweb dependency? I think
this is not so much of a problem if we treat it properly as a
dependency.

configure.ac itself should be a named chunk - probably in the main
Makefile.pamphlet. This might make regenerating ./configure a little
more complex than usual but not much.

Most open source installations ship a pre-generated ./configure
file and I think Axiom should be no different.

The first thing ./configure should do is check for noweb and tell
you what to do about it if it is not found. One "last resort" option
to ./configure can be to build and install noweb from the sources
supplied with Axiom. But in general Axiom should not be in the
business of re-distributing noweb.

> So, in its current form, I put the literate stuff in comments, so
> that if you do
>
>     cat configure.ac | sed -e 's/^## //' > configure.tex
>
> you can an almost LaTeX file.  "Almost" because LaTeX commands need
> to start with a backslash.  That character used to be reserved for
> line continuation in shell world.  So to avoid any surprise, I used
> the percent character (which unfortunately is LaTeX comment
> character).  So to get the LaTeX document, one needs to apply another
> sed that replaces the percent character with the backslash character.
>
> I've tested that I can feed the file to Autoconf, get a configure
> file out of it and launch a successful build.
>
> This work is being done on the "build-improvements" branch -- and it
> has not been committed there yet.
>
> Before painting myself into a corner, I would like to have feedbacks
> from all y'all.
>

All this looks like a horrible hack to me - unless I am missing
something fairly basic. What is wrong with the usual way of using
noweb?

\start
Date: 01 Aug 2006 23:50:33 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [build-improvements] Requests for discussion

Ralf Hemmecke writes:

| Does that help you? I am running debian sarge.
| I don't see a ./config file in that directory.

Thanks for the feedback.  Let me, first, merge your changes to silver,
then commit mine to build-improvements.  I'll send you a ping for
testing. 

Are you comfortable with the approach of my ad-hoc approach to
literacy here that is not mainstream Axiom not ALLPROSE?  What would
you suggest?

\start
Date: Tue, 1 Aug 2006 18:18:51 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Front page esthetic

On Tuesday, August 01, 2006 5:52 AM Ralf Hemmecke wrote:
> ...
> See
> http://wiki.axiom-developer.org/SandboxAxiomSources
> and tell me what you think.

Thanks Ralf. I think this draft looks great!

> (Could one have a table of contents at the top of that page?)
>

What did you have in mind? Table of Contents for the contents
of the page or something more inclusive?

> (4) Browse sources online
> That should be something like the "Online Source" that
> currently exists.
> But if you press "Online sources" currently it leads to
> 
> /mathaction/axiom--test--1/
>
> I know it is irrelevant, but the "test" in the name is
> misleading. The page
> http://wiki.axiom-developer.org/axiom--test--1/FrontPage
> (and archive) should rather be called "Axiom-Stable". Yes,
> not the same naming conventions as the tla archive. Bill,
> if you could write on top of that page that people are browsing
> the latest stable release, that would be wonderful.

The current "Online sources" are actually pamphlet files implemented
as wiki pages. Some details are provided here

http://wiki.axiom-developer.org/210

You might also wish to review the history of pamphlet file support
on the wiki in the axiom-developer email list.

The main idea here is to provide direct support (including editing
and noweb) for pamphlet files through the wiki interface. But more
needs to be done to integrate this with the rest of the Axiom build
process.

The 'axiom--test--1' pages correspond to what the Axiom sources
were about last August, 2005. There have been some online updates -
especially those required to allow Axiom Wiki to generate hypertex
dvi and pdf files, but none of these changes have been propagated
back to the original sources (either gold or silver). I used a
different name 'axiom--test--1' as a reminder that this source
is not either of these.

The original idea was to have a way to periodically merged these
changes, but that has not been implemented yet. And of course it
is desirable to merge changes from gold (or maybe better silver)
to the "online sources". This also has to been implemented.

And most ambitiously, one could have an automatic build process
that built Axiom directly from the current online sources and if
it was successful, automatically run a series of "test" wiki pages
containing Axiom commands and expected results.

But all of this is just duplicating through-the-web, processes that
are normally accomplished using the more conventional approach.
It is a kind of experiment to see how much we can do with the wiki-
based approach. I still think it is rather sexy, but until (or if)
Axiom developers show more interest in this concept, I am rather
reluctant to spend more of my time on this experiment.

But...

There are alternatives for browsing online source code directly
from source repositories. I have for example also implemented the
darcsweb cgi script that enables browsing the darcs repository. Go to

http://wiki.axiom-developer.org/MathActionRepository

and click on "browsed online", then click on "axiom--main--1".

The axiom--main--1 darcs repository corresponds to the actual version
of Axiom running on the axiom-developer.org server that runs Axiom Wiki
and Axiom Portal. It is currently in synch with the arch axiom--main--1
repository because I just recently updated the version of Axiom.

darcsweb is described here:

http://auriga.wearlab.de/~alb/darcsweb/

I think there are similar online source browsers for arch (tla), cvs
and subversion. Maybe the link to the "Online source" should be to
one of these instead of to 'axiom--test--1'.

But of course these browsers do not allow online update of the source
code.

>
> I think the "Build Axiom" entry under download is unnecessary. There
> should be just a link from the "AxiomSources" page to the BuildAxiom
> page. And the BuildAxiom page should be cleaned up a bit.
>

That sounds good to me.

\start
Date: 02 Aug 2006 00:49:23 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: [build-improvements] Requests for discussion

Bill Page writes:

[...]

| >    For that I've converted the current configure file to
| > configure.ac (which Autoconf will use to regenerate configure).
| > The main motivation here is factor out many platforms variability
| > issues and dump them on Autoconf -- who already knows how to solve
| > them.
| > 
| >    Axiom has the requirement that the source files must be
| > literate -- use of pamphlet files.  Autoconf expects its input to
| > be in particular form.  Furthermore, the pamphlet file requirement
| > introduces an unpleasant bootstrapping issue that will hopefully
| > be resolved.
| 
| Are you referring to the problem of the noweb dependency? I think
| this is not so much of a problem if we treat it properly as a
| dependency.

Currently, it if one modifies the toplevel Makefile.pamphlet, one also
needs to regenerate the corresponding Makefile.  I don't want that.

All Makefiles should be generated at configured time.

Furthermore, one needs to have noweb in order to regenerate it.  If
the target system needs to build noweb, we are hosed.  We don't want.

All that is elimintated by not having to regenarate Makefile before
actual configuration.


| configure.ac itself should be a named chunk - probably in the main
| Makefile.pamphlet. This might make regenerating ./configure a little
| more complex than usual but not much.

configure will swamp the generation of all Makefiles from the
corresponding pamphlets.  Consequently I don't want to tie the
generation of configure to Makefiles that way.  We don't need that
bootstrapping problem.

| Most open source installations ship a pre-generated ./configure
| file and I think Axiom should be no different.

Yes, that is what we will do.  That configure is generated by Autoconf
based on configure.ac.  Autoconf does not expect pamphlet files.
Autoconf want an input in a language it understands. Consequently, we
must present configure.ac in a way appropriate for Autoconf.
Therefore we cannot depend on noweb (notangle).

In my current system, the only dependency of configure on makefiles is
when the makefiles are "touched" in a way that needs reconfiguration;
and way to extract the documentation out of configure.ac.

| The first thing ./configure should do is check for noweb and tell
| you what to do about it if it is not found.

Yes, that is what is done in my current local tree.  That is one
reason why we don' want configure.ac to depends on noweb.

| One "last resort" option
| to ./configure can be to build and install noweb from the sources
| supplied with Axiom. But in general Axiom should not be in the
| business of re-distributing noweb.

That is also an implemented option in my current system.

| > So, in its current form, I put the literate stuff in comments, so
| > that if you do
| > 
| >     cat configure.ac | sed -e 's/^## //' > configure.tex
| > 
| > you can an almost LaTeX file.  "Almost" because LaTeX commands need
| > to start with a backslash.  That character used to be reserved for
| > line continuation in shell world.  So to avoid any surprise, I used
| > the percent character (which unfortunately is LaTeX comment 
| > character).  So to get the LaTeX document, one needs to apply another
| > sed that replaces the percent character with the backslash character.
| > 
| > I've tested that I can feed the file to Autoconf, get a configure
| > file out of it and launch a successful build.
| > 
| > This work is being done on the "build-improvements" branch -- and it
| > has not been committed there yet.
| > 
| > Before painting myself into a corner, I would like to have feedbacks
| > from all y'all.
| > 
| 
| All this looks like a horrible hack to me - unless I am missing
| something fairly basic. What is wrong with the usual way of using
| noweb?

See the explanations above.

This is a hack; I agree.  No more horrible than what we currently do
with noweb.  However, I don't like it.  That is why I called for
discussion and suggestions for improvements :-)

To sum up.

We need

  (1) to write configure.ac directly in a language understood by Autoconf;
  (2) a way to get the documentation out of configure.ac
  (3) no dependency of configure.ac (and therefore configure) on noweb.

For the long term, all Makefiles should be generated at configure time.

\start
Date: Tue, 1 Aug 2006 13:26:53 -0400
From: Cliff Yapp
To: list
Subject: Re: Front page esthetic

On Tuesday 01 August 2006 12:11 pm, Bill Page wrote:
> Contrary to the intent of the wiki, it
> seems that almost all of the contributions to the Axiom web site
> have been by people who are also active Axiom developers and are
> quite familiar with using tools like CVS.

I suspect that is due to Axiom not being seen as "simple" to use, whether or 
not that's actually true.

> As I have said several times already, I am quite disappointed by
> the lack of active contributions to the Axiom Wiki. Perhaps people
> just do not have time or the motivation? I would be very surprised
> if the reason was because they found it difficult to do, although
> there does seem to be a considerable reluctance for people to view
> the web as a two-way media where they can (or even are expected to)
> contribute content. It seems to me that this is more a "cultural"
> issue than a technical one.

I would expect this to be true.  Also, remember there is the additional 
barrior of learning Axiom itself, in addition to the wiki mindset.  The tools 
are very powerful but like all powerful tools there is a minimum skill level 
which must first be obtained before they can be effectively used.

> In the last couple of years the only wildly successful wiki-based
> project that I can think of is Wikipedia.

And the skill level requried to contribute there seems to be ~= 0, and the 
topic list is much broader than mathematics and science.  It's amazing that 
it has worked as well as it has, but there is a VERY active and dedicated 
core group of people that fights off a continuing incoming stream of garbage.

> At the present time the 
> only explanation I have for this is that apparently the ratio of
> the number of people willing to contribute to the number of people
> who just visit for information is very small - maybe as high as
> 1 out of 100,000. This would be consistant with the success of
> Wikipedia and also the level of contribution that we see in Axiom
> Wiki based on our month access statistics.

Yes, I expect this is true.

> Anyway, I would very much like to hear from other Axiom developers
> about the issue of whether it makes sense to continue to try to
> maintain the main Axiom web site as a Wiki.

Some features of Axiom's website I very much like - for example, the Emacs 
mode pamphlet was uploaded effortlessly and a complete online set of 
documents in available formats was generated and downloadable.  The same for 
each incrimental edit.  This is the best such system I have ever seen, and 
IMHO it should be preserved.

The source code being online in axiom--test--1 I also like very much - it's 
extremely convenient to have it available in that form, and as the source 
code becomes true literate documents we effectively have an entire research 
library on our website :-).

The ability to have Axiom sessions which display well formatted output via 
graphics from user input is very good as well.  The SAGE project might be an 
even better outlet for this type of work - I haven't looked closely at it 
yet - but Axiom's system is certainly one of the very best on the web and I 
hope to see it continue.

I don't know how many of these features are due to the wiki nature of the 
website though.  As to the ability of anybody to edit and change pages - 
except for experimentation without on-computer software installation ala the 
sandbox, I don't think I see much benefit to this, to be honest.  Science, 
mathematics, computer science, and the other subjects Axiom deals with are 
not simple or casual pursuits for most people, and I think anyone capable of 
doing work significant to the project would also be able to handle 
interacting with a more "traditional" website structure, with 
one "experimental area" for trying out basic stuff.  Think about it this 
way - if some paper appeared on our wiki, from someone we didn't know who did 
not further contact or become involved with the project, how would we react 
to it?  My first reaction would be that the author probably wasn't all that 
serious about what they were doing (that might not be fair, I know).  Many 
people have put up good work on wikis, including Axiom's, (the Guess work 
being one of many examples) but those peopel are almost all known to us 
through their other work as well.  Also, if we want to use such a work, does 
posting it to the wiki implicitly release it as BSD licensed?  Who would do 
the quality check needed before it became part of the "main" code base?   It 
often takes quite a lot of work to spot a good "fake" paper, and that's why 
peer reviewed journals have the inertia they do.  Reputations must be earned 
for work to be taken seriously.  Tim's idea with an Axiom journal is a good 
one - I would expect that once established that venue would produce more 
usable work than a wiki would.  Sort of like the ToC effort - credible names, 
reputations, and authors are needed to attract serious published works.  
Serious developers would publish through that community rather than use an 
anonymously writable wiki, and so any wiki work ends up being seen as at best 
an amateur effort and at worst internet background noise.  Wikipedia has to 
work hard to remain useful, and their goal is only general information, not 
in-depth highly correct mathematical and scientific papers.

The Axiom portal, on the other hand, I do find very useful for 
individual "storage" of works in progress, relevant bits of information, etc.  
Is that a wiki-like system?

I don't pretend to have all the answers - just my thoughts on the subject.  I 
have a tremendous respect Bill for the work you have done, which has produced 
the best online mathematics website I have seen to date, and I don't know if 
my much less informed opinions are of use.

\start
Date: Tue, 1 Aug 2006 13:36:29 -0400
From: Cliff Yapp
To: list
Subject: Re: Front page esthetic

On Monday 31 July 2006 11:22 pm, Bill Page wrote:

> > All of them appears to me to be quite simple -- and I like that
> > simplicity.  Especially that of Maxima.  It takes very little
> > time to display -- compared to Axiom's.

Heh - glad you like it.  I was the one who came up with the initial design for 
that site, although it has been helped quite a lot since then by others.  It 
uses one file for the menu and validates (or it used to) in the w3c 
validator.  It's far less sophisticated than the Axiom website though.

> When I look at
>
> http://maxima.sourceforge.net
>
> My first reaction is: Hmmm, that doesn't look so different than the
> Axiom Wiki FrontPage... The time to display seems quite similar over
> a high speed connection and a reasonably fast system (AMD 3500+).
>
> I don't find anything that makes the Maxima page seem simpler or
> that gives me the impression that information is more readily
> accessible. What am I missing?

It might be that the Maxima website is a bit more structured generally.  I'm 
probably the wrong person to compare how clean and accessible the two sites 
are since I had a hand in the Maxima website - I can try and offer specific 
suggestions if they are of interest.

> I did not see any posting to axiom-mail. In fact I haven't seen
> any real postings to axiom-mail for some time - only spam (about
> 10 to 20 spam message per day). I wonder if this list is working
> properly? Most people seem to prefer the axiom-devel list. Maybe
> we have too many lists?

For the number of people active now, I think we do have too many.  Maybe we 
could do this - make the other email lists "dormant" until axiom-devel begins 
to be overwhelmed with traffic that isn't dev related, and then re-activate 
them as needed.  Except axiom-legal - those discussions can get very long and 
we need a place to dump them ;-).

> Can you give an example of something that is exciting and/or
> appealing about Axiom that is not found on the FrontPage?

I know the question isn't addressed to me but I might suggest a bit of a 
different arrangement for the downloading information (guess that's not 
exactly front page though.)  I'll try and work on it some tonight and come up 
with a more concrete suggestion.

\start
Date: Tue, 1 Aug 2006 20:01:21 -0400
From: Bill Page
To: Antoine Hersen
Subject: RE: Front page esthetic

On Tuesday, August 01, 2006 2:39 PM Antoine Hersen wrote:

> Summer cleaning !!!

When it's this hot I'd rather be in an air conditioned office
in front of my computer... just call me Canadian. :-)

> I also think the web page is too cluttered.

> There is three category of people new comers, user and
> contributors.

Do you think this means we should really have three different
web sites?

> About the new comers : we are competing to get their attention
> and time.
>
> We need to be very good at it because Axiom is complex so it
> is not going to be an easy sell.
>
> For them it should be the principle of minimum surprise and
> maximum simplicity.

Hmmm... exactly what is it that we are trying to sell? :)

Do you not feel that this might be quite misleading to such
new comers? After all, I do not think either of these
principles apply to Axiom - and some of the reason for this
depends on design choices that are specific to Axiom. I mean
specifically Axiom's type system.

I think this means that right up front we have to admit to
ourselves that Axiom may not have much appeal to most new
comers. But perhaps there is a class of "new comers" consisting
of experianced computer algebra users who have not had previous
exposure to Axiom. I think it is these people who might be most
receptive to the reasons why things are done "differently" in
Axiom.

> ( Next is a description of me looking at a project I might
> use, therefore interpret the "I want" has I really expect to
> see)
>
> If their is two column I will only read the left one.
> (When we discuss the web page with Ralf today I even had
> forgotten about the right one I remember only the logo and
> was surprise to see link.)

Wow! That seems like a big admission to me. Is that also how
you read the newpaper and computer magazines? ;) I admit that
I also am very selective about what I read on a web page, but
not that selective...

> Also I expect the "This site" to be on the top right corner.
> Our current top of the page do not make any sense, it is pure
> confusion to me.

Do you mean the line:

home contents changes issues preferences help  +/-
  full/simple/minimal navigator  subscribe backlinks diff edit
    (external edit icon)

It is obvious, isn't it? that this is the top menu bar similar
to what you see on almost all window applications?

Surely some of these menu items must also be obvious to you?
E.g. 'home', 'help', 'edit' etc.

Could you say exactly what you find confusing? Keeping in
mind that this is a wiki web site, could you suggest how we
can make it less confusing?

One way, maybe, would be to completely hide that fact that this
is a wiki page by removing the top menu bar on the FrontPage.

> Also the left menu is too long, and redundant :
> Audio/visual <http://wiki.axiom-developer.org/AxiomScreenCast>
> audio ??? not common confusing.

Really? Many web sites use audio, especially ScreenCasts.

> Press releases <http://wiki.axiom-developer.org/PressReleases>
> I have doubt the general press is going to be interested by us
> really soon.

I have in mind more specific "press" such as computer magazines
and online "news" sources such as SlashDot etc. Maybe the name
"press releases" is a bit misleading?

> Gold Silver , the Olympics maybe ?

> What I like is a News section where I can see that a project is
> alive.

Right now the best place for this is "changes" on the main menu
bar that you said was confusing to you but it is also in the
right sidebar as Whats New under This Site.

It would be nice to have a nicely formatted wiki page specifically
for this purpose but then we would need someone willing to keep it
up to date.

> (Also I like a related project link where I can see other CAS,
> I love it, I think it is fair play)

Do you mean expand the Related Sites box on the right sidebar?

> I want a "Description" two page long maximum with what is Axiom
> what is special and great about it.

Do you mean something like

http://wiki.axiom-developer.org/AboutAxiom

which is already accessible from several links on the current
FrontPage?

> I want a screen shoot , yes sorry I always want a screen shoot
> even for a cmd line programs.

I wonder why it did not seem obvious to you to click "Audio/visual"?
Could you suggest a change of wording that would have made this
more obvious? I am trying hard here not to appear defensive or
critical. I am serious that we badly need suggestions on how
to word things so that the purpose is obvious on first reading.
I know that this might be difficult to achieve for all people
reading this web site from around the world, but we should at
least try.

Right now the only static screen shots that we have are for
Axiom with TeXmacs.

http://wiki.axiom-developer.org/Screenshots

It would be great if someone could take the time to contribute
a few more.

> And then I want a Download with maybe some binary but for sure
> a tgz of the source. I will grab it, type ./configure, make,
> make install and try.

The 'Download' link on the FrontPage does lead quite quickly
to binary and source code tgz. How can we improve that?

> Then I am going to look for a good introduction. And I hate
> it when people give me choice I want the one and definitive
> introduction. I will read between 5 and 20 pages max. Any
> document that go over 100 pages will scare me to death.

I have to agree that we lack a good introduction. But "the one
and definitive introduction" is rather hard to write for Axiom
I think. Perhaps you would be willing to create a draft? Maybe
we can try to write such an introduction in a collaborative
way?

> A good indicator for me is if I feel ok to print it.
> And if I survive I will look for more advanced material.

> For the axiom user. We should not expect him to subscribe to
> the mailing list.

I find that a rather surprising statement. As a user of new
open source software that is one of the first things that I
expect to have to do. One of the things that people repeatedly
claim for open source software is that the email lists of most
open source projects is a much better source of help and
information that any traditional help resource for commercial
software.

> He will go to the web page to solve his problems and get new
> version. Here it is good FAQ, oriented tutorial, documentation
> and search able mail list. Subscribing to a mailing list is a
> big step, we should not expect people to do it.

I agree that the current Axiom tutorial information could be
much better organized. Do you have any suggestions about how
to do this?

On the Axiom Wiki it is also possible for users to "subscribe"
to specific web pages. Did you notice the word 'subscribe' in
the top menu line? This allows people to automatically receive
notices of new or changed web pages without having to subscribe
to the email list. Do you think this is a useful feature?

> For active user/ contributors/ developer what is needed is a
> collaboration tool, I have no answer for that.

Axiom Wiki? Or do you mean that what we have now does work as
a collaboration tool?

> Personally I find the wiki difficult to use, it seem a big mess
> to me and I spend a lot of time looking for documents I saw
> before and know should be somewhere.

I am surprised that you say "what is needed is a collaboration
tool" and then you say immediately after that you find the wiki
difficult to use. I wonder what you have in mind when you say
"collaboration"?

> It lack structure and search will not replace that, in general
> giving a name to your problem is the difficult part.

Of course there are alternatives to search such as the Site Map
and Site Index links on the right sidebar. But I agree in general
that the structure of the web pages on the Axiom Wiki web site
could be improved.

I did try to make some progress toward improving this structure
by introducing the new Up/Down navigation links on the left side
of each page (except FrontPage). My intention is to make the
structure of the pages more obvious and more useful for "navigating"
(i.e. manually searching) through the web site. Do you think that
is useful?

Note: What is Up and what is down can be changed by clicking
on 'backlinks' from the top menu bar. Maybe that is not obvious.
Can you suggest another way to introduce the concept of the
page structure?

> When you look at the tree structure you see a big mess and all
> the bugs !

Well, it is not really a tree structure. Each page can be linked
to several pages both "up" and "down". So it is really a lattice
(to a mathematician) or an ontology (to at least one branch of
computer science).

When you say "all the bugs" do you mean the issue tracker pages?
These to not appear in most of the links on the left sidebar.
Or do you mean when you look it the overall structure under
'contents'? Because we have over 300 such issue reports (about
the same number as all other contents of the web site), these
do tend to dominate any listing of contents. Perhaps we need a
way to suppress these from the main contents list and only
show them on a more detailed contents list?

> About people contribution :
>  I almost never find wiki useful.

Can you say why you do not find it useful?

>  Wiki as documentation is always an unpleasant mess.

Do you not think the word "always" is too strong? I can give
some examples where it is very good (e.g. Wikipedia) and others
where it is not so good. Of course the quality of the contents
of a wiki depend directly on the contributions of users. Perhaps
what you are saying is equivalent to saying that the users of
software like Axiom are not qualified (or not willing?) to
contribute to it's documentation? Or are your comments really
specific to documentation done via a wiki?

> I found comments useful( I think it is the MySQL documentation,
> it has user comments at the end of each section, you always
> find clarification and corner case described).

Is this not like what you see on the current Axiom Wiki?

> And modifying a page is not has easy at it sound. Writing
> correctly is time consuming and difficult. I never feel like
> touching other people stuff. You can often see it in a wiki
> where old information is rarely deleted.

This is just an attitude that can be changed by experience
isn't it?

> So in the end it is a question of balance between people
> contribution and time saved not doing it against mess and
> quality.

I agree. My conclusion is that we do not have nearly enough
people willing to contribute. For me, time saved is time not
"stolen" from other projects (and paying work) that also
deserve my attention. I am sure that this is similar to many
other people who currently contribute to Axiom.

> I think a fix web page with a few editors and keeping the wiki
> as a play ground is the best solution. But easy to say because
> I am not volunteering to be an editor.

How can we solve this problem if no one volunteers to be editor -
not even editor of their own wiki pages?

> Also just doing a good cleaning of the wiki might be what we
> need.

Please give even a few simple suggestions about what needs to
be cleaned? What can we delete? What things already exist on
the web site that can be linked into a more useful structure?

Thanks again for all you comments.

\start
Date: 02 Aug 2006 02:40:28 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Front page esthetic

Bill Page writes:

[...]

| I think this means that right up front we have to admit to
| ourselves that Axiom may not have much appeal to most new
| comers. But perhaps there is a class of "new comers" consisting
| of experianced computer algebra users who have not had previous
| exposure to Axiom. I think it is these people who might be most
| receptive to the reasons why things are done "differently" in
| Axiom.

I understand that.  I also believe we must attract those who had no
"active" prior exposure to computer algebra system.  If we only
attract experienced computer algebra users, we will be in trouble.
In a good healthy community, "young" or "newbies" must be larger than
"old" or "experienced" people.  We do want the newbies to become very
quickly experienced though :-)  That takes time.  Still.

| > ( Next is a description of me looking at a project I might
| > use, therefore interpret the "I want" has I really expect to
| > see) 
| >
| > If their is two column I will only read the left one.
| > (When we discuss the web page with Ralf today I even had
| > forgotten about the right one I remember only the logo and
| > was surprise to see link.)
| 
| Wow! That seems like a big admission to me. Is that also how
| you read the newpaper and computer magazines? ;) I admit that
| I also am very selective about what I read on a web page, but
| not that selective...

I believe what Antoine says here is not unique.  Ideally, even when
people are selective (and most people are), we don't want them to miss
key information about the project.  We can't win by showing how
selective reading they have :-/

[...]

| > Press releases <http://wiki.axiom-developer.org/PressReleases>
| > I have doubt the general press is going to be interested by us
| > really soon.
| 
| I have in mind more specific "press" such as computer magazines
| and online "news" sources such as SlashDot etc. Maybe the name
| "press releases" is a bit misleading?

I would put that under the heading/page "News".

\start
Date: Tue, 1 Aug 2006 22:11:51 -0400
From: Cliff Yapp
To: list
Subject: Re: [build-improvements] Requests for discussion

On Tuesday 01 August 2006 6:49 pm, Gabriel Dos Reis wrote:

> | Most open source installations ship a pre-generated ./configure
> | file and I think Axiom should be no different.
>
> Yes, that is what we will do.  That configure is generated by Autoconf
> based on configure.ac.  Autoconf does not expect pamphlet files.
> Autoconf want an input in a language it understands. Consequently, we
> must present configure.ac in a way appropriate for Autoconf.
> Therefore we cannot depend on noweb (notangle).

If I understand the question, you are asking how we can have only literate 
program files in Axiom at the get go and still not depend on noweb.  The 
simple answer is, we can't. 

> In my current system, the only dependency of configure on makefiles is
> when the makefiles are "touched" in a way that needs reconfiguration;
> and way to extract the documentation out of configure.ac.

I suppose I'm dense, but I thought it would end up like this:

1)  Have configure.ac and configure.ac.pamphlet both present in the top level 
directory.  configure.ac.pamphlet is where editing is done, and when a commit 
is made (for this one file) a configure.ac file is also committed (or even 
autogenerated by the server, if we want to go so far as to configure it to do 
so.)

2)  Extracting the documentation out of configure.ac.pamphlet would require 
the use of the notangle command, or once we have a lisp noweb using that 
tool. 

I've always wondered why LaTeX itself couldn't handle processing a pamphlet 
file as a regular latex file  - after all, couldn't it just replace 
<<chunckname>> [content] @ by a fancy version of \begin{verbatium}[content] 
\end{verbatium} or some such?  You would still need a notangle command to 
extract source code, but at least you could read the documentation without 
needing anything more than LaTeX.

I suppose I'm missing features noweb gives us though.

> | The first thing ./configure should do is check for noweb and tell
> | you what to do about it if it is not found.
>
> Yes, that is what is done in my current local tree.  That is one
> reason why we don' want configure.ac to depends on noweb.

That's why we will need to have both configure.ac and configure.ac.pamphlet.  
This will always be true if we want to avoid having the end user manually use 
some other tool to extract the first file, whether it is configure.ac or some 
other file.  As long as configure.ac.pamphlet is written and maintained in 
the .pamphlet file I don't see a problem with special casing the continual 
presence of configure.ac  - it's pretty much inevitable.

> | All this looks like a horrible hack to me - unless I am missing
> | something fairly basic. What is wrong with the usual way of using
> | noweb?
>
> See the explanations above.

I understand the desire to be able to bootstrap, but there is no way around 
it - we must have one non-pamphlet file present to kickstart the process.  
Personally I would suggest two or three - a set of Bash and Windows script 
files containing all the autoconf and other incantantations the user would 
need to make might simplify matters even more.

I don't think we should fear a couple of non-pamphlet files being present in 
the top level directory - indeed, it will simplify matters considerably from 
the user standpoint.  They won't know (and may not want to know) what a 
pamphlet file is all about - they just want to build and use the math program 
to do math.  In that case, the complete absence of anything familiar will 
turn them off.

I would suggest the minimal (and maybe maximal) set of:

README
configure.ac
buildaxiom.sh
buildaxiom_windows.<whatever windows uses>

README should be in basic, no frills ASCII text - about as universally 
readable as you can get.  It should explain a little about Axiom, and how to 
get started building it (tools needed, etc.)

> This is a hack; I agree.  No more horrible than what we currently do
> with noweb.  However, I don't like it.  That is why I called for
> discussion and suggestions for improvements :-)

There is no way to bootstrap without a "lower level" file present to kick the 
process off, unless (as you already attempted) the higher level files are 
also legal lower level files.  I don't think we want to redefine the literate 
strategy we use to that degree - it's not worth it.

In a way, it's the same problem Tim faced with Axiom being needed to build 
Axiom.  The only way out was (and still is) to have some files in lisp 
present, to teach lisp to read and understand BOOT and SPAD.  Same deal here.  
It's a universal problem - if we wanted to bootstrap a machine from a cold, 
memoryless, powerless state we would need some binary to feed it before it 
could start speaking assembly. True bootstrapping is a very rare event ;-).  
Normally even new platforms have their software cross compiled from other 
platforms, since the human beings involved don't want to make the translation 
themselves.  Anyway, that's another topic.

> To sum up.
>
> We need
>
>   (1) to write configure.ac directly in a language understood by Autoconf;
>   (2) a way to get the documentation out of configure.ac
>   (3) no dependency of configure.ac (and therefore configure) on noweb.

1 and 3 are solved by always having a current notangle of configure.ac present 
in the tree at all times.  As for two, I think we should assume a working 
notangle is available.  We have to assume SOMETHING is working, and since the 
generated document needs LaTeX to be processed I think the additional 
assumption of notangle (particularly if configure.ac can build it) is 
acceptable.

> For the long term, all Makefiles should be generated at configure time.

Agreed.

\start
Date: Wed, 2 Aug 2006 04:57:40 +0200
From: Antoine Hersen
To: Bill Page
Subject: Re: Front page esthetic

Disclaimer all the use of the word "I want" are to be interpreted as an
expression of a wish based on personal taste.
A wish because if I wanted it so badly I will have done it myself.
And personal taste because I will be happy to argue.

> Summer cleaning !!!
>
> When it's this hot I'd rather be in an air conditioned office
> in front of my computer... just call me Canadian. :-)


Yhea I did not wanted to push the issue to spring thats all ;)

> I also think the web page is too cluttered.
>
> > There is three category of people new comers, user and
> > contributors.
>
> Do you think this means we should really have three different
> web sites?


No but those group have different needs that have to be serve by the same
web page.

> About the new comers : we are competing to get their attention
> > and time.
> >
> > We need to be very good at it because Axiom is complex so it
> > is not going to be an easy sell.
> >
> > For them it should be the principle of minimum surprise and
> > maximum simplicity.
>
> Hmmm... exactly what is it that we are trying to sell? :)


We want people time, first we want people to use Axiom and then we want
people to work on Axiom.

Do you not feel that this might be quite misleading to such
> new comers? After all, I do not think either of these
> principles apply to Axiom - and some of the reason for this
> depends on design choices that are specific to Axiom. I mean
> specifically Axiom's type system.


I was thinking mainly about the web page.
But it is true that axiom has a lot of complicated ideas and we should be
clear about their respective advantages.

People tend to use the simplest tool possible for their problem( not a bad
idea in general) become familiar with it and use it more and more, at what
point even if the tool is not a good fit anymore people dont know or dont
see the advantage of learning a new tool that will be seen has more complex.

And I think Axiom fit in the heavy tool category.

I think this means that right up front we have to admit to
> ourselves that Axiom may not have much appeal to most new
> comers. But perhaps there is a class of "new comers" consisting
> of experianced computer algebra users who have not had previous
> exposure to Axiom. I think it is these people who might be most
> receptive to the reasons why things are done "differently" in
> Axiom.


The problem is those new comers are not "fresh" any more.
If you have been using MMA for some time, you need a good enough reason to
abandon all your experience and change tool.

So we need a sell speech !!!!!!

Also another category of user is people looking for a general CAS that is
open source, and even if those user may lack "sophistication" initially I
think we should still try to be attractive to them and offer support.


> ( Next is a description of me looking at a project I might
> > use, therefore interpret the "I want" has I really expect to
> > see)
> >
> > If their is two column I will only read the left one.
> > (When we discuss the web page with Ralf today I even had
> > forgotten about the right one I remember only the logo and
> > was surprise to see link.)
>
> Wow! That seems like a big admission to me. Is that also how
> you read the newpaper and computer magazines? ;) I admit that
> I also am very selective about what I read on a web page, but
> not that selective...


Dead tree ???? I like only shiny moving picture where every thing comes in
30 second chunk. Honestly I read a lot of books and magazine, even newspaper
when I am off the grid.

But I want to be able to scan rapidly a web page and find what might be of
interest to me.


> Also I expect the "This site" to be on the top right corner.
> > Our current top of the page do not make any sense, it is pure
> > confusion to me.
>
> Do you mean the line:
>
> home contents changes issues preferences help  +/-
>   full/simple/minimal navigator  subscribe backlinks diff edit
>     (external edit icon)
>
> It is obvious, isn't it? that this is the top menu bar similar
> to what you see on almost all window applications?
>
> Surely some of these menu items must also be obvious to you?
> E.g. 'home', 'help', 'edit' etc.
>
> Could you say exactly what you find confusing? Keeping in
> mind that this is a wiki web site, could you suggest how we
> can make it less confusing?


I honestly find this top bar terrible.
The top of the page a very expansive piece of estate.
Look at the wikipedia one, as simple as possible.

I understand it is surely the wiki default and will be difficult to change
but still.

+/- ? does not work for me I imagine that it change the font size, I know
how to do that on my browser and I do not expect a web site to do this for
me.

contents <http://wiki.axiom-developer.org/FrontPage/contents#FrontPage>  ok
changes <http://wiki.axiom-developer.org/FrontPage/recentchanges> ? history
?
issues <http://wiki.axiom-developer.org/IssueTracker>    ? discussion ?
preferences <http://wiki.axiom-developer.org/UserOptions> ok if I am log
help <http://wiki.axiom-developer.org/HelpPage> ? with ?
full<http://wiki.axiom-developer.org/UserOptions?setcookies=1&zwiki_displaymode=full&zwiki_showhierarchy=1&redirectURL=http://wiki.axiom-developer.org/FrontPage>
/simple<http://wiki.axiom-developer.org/UserOptions?setcookies=1&zwiki_displaymode=simple&zwiki_showhierarchy=&redirectURL=http://wiki.axiom-developer.org/FrontPage>
/minimal<http://wiki.axiom-developer.org/UserOptions?setcookies=1&zwiki_displaymode=minimal&zwiki_showhierarchy=&redirectURL=http://wiki.axiom-developer.org/FrontPage>this
one is supper scary
navigator <javascript:toggleNavigator()>  is that content version terminator
?
 subscribe <http://wiki.axiom-developer.org/FrontPage/subscribeform> maybe
only if I click on edit ? not sure
backlinks <http://wiki.axiom-developer.org/FrontPage/backlinks> this one
will be better at the bottom
diff <http://wiki.axiom-developer.org/FrontPage/diff> so what was change ?

One way, maybe, would be to completely hide that fact that this
> is a wiki page by removing the top menu bar on the FrontPage.


For the front page I think it will be nicer especially as people can not
edit it.

> Also the left menu is too long, and redundant :
> > Audio/visual <http://wiki.axiom-developer.org/AxiomScreenCast>
> > audio ??? not common confusing.
>
> Really? Many web sites use audio, especially ScreenCasts.


I dont know about screen cast( I do but dont tell), also audio + CAS makes
weird connection in my brain.

What about :

Screenshots/Video

> Press releases <http://wiki.axiom-developer.org/PressReleases>
> > I have doubt the general press is going to be interested by us
> > really soon.
>
> I have in mind more specific "press" such as computer magazines
> and online "news" sources such as SlashDot etc. Maybe the name
> "press releases" is a bit misleading?


./ is meta content.
But computer magazine is a good idea, especially all those LinuxSomething
but we will need to send them press release not wait for them to come.

> Gold Silver , the Olympics maybe ?
>
> > What I like is a News section where I can see that a project is
> > alive.
>
> Right now the best place for this is "changes" on the main menu
> bar that you said was confusing to you but it is also in the
> right sidebar as Whats New under This Site.


Right side does not exist for me remember :)
New should be in the 1st five on the left.

It would be nice to have a nicely formatted wiki page specifically
> for this purpose but then we would need someone willing to keep it
> up to date.
>
> > (Also I like a related project link where I can see other CAS,
> > I love it, I think it is fair play)
>
> Do you mean expand the Related Sites box on the right sidebar?


> I want a "Description" two page long maximum with what is Axiom
> > what is special and great about it.
>
> Do you mean something like
>
> http://wiki.axiom-developer.org/AboutAxiom
>
> which is already accessible from several links on the current
> FrontPage?


The axiom link in the central description I never clicked on it, I will have
no idea where it will lead me.

I think there should be a clear About it the top 3 on the left side.

> I want a screen shoot , yes sorry I always want a screen shoot
> > even for a cmd line programs.
>
> I wonder why it did not seem obvious to you to click "Audio/visual"?
> Could you suggest a change of wording that would have made this
> more obvious?


Audio/visual seem weird to me, I will expected this from an artist web page.

I am trying hard here not to appear defensive or
> critical.


I am exaggerating a lot my critics.

I am serious that we badly need suggestions on how
> to word things so that the purpose is obvious on first reading.
> I know that this might be difficult to achieve for all people
> reading this web site from around the world, but we should at
> least try.


Yes sadly first impression is critical.

Right now the only static screen shots that we have are for
> Axiom with TeXmacs.
>
> http://wiki.axiom-developer.org/Screenshots
>
> It would be great if someone could take the time to contribute
> a few more.


Martin had some nice one I think.

> And then I want a Download with maybe some binary but for sure
> > a tgz of the source. I will grab it, type ./configure, make,
> > make install and try.
>
> The 'Download' link on the FrontPage does lead quite quickly
> to binary and source code tgz. How can we improve that?


That is something I have been talking about with a friend. There is two
things actually.
The subsection in the left menu  do not show as such they should be a bit
decalled or have some small bullet point.

And all the four title do not feel has link because every think you might
expect from them is detailed bellow.

I am not sure I am clear on this one.

Maybe we could give a try to this for a few day get rid of them no big
Documentation/Discussion/... the color should carry enough information.

And download should be above discussion.

Also testing does not convey best the idea of trying, and it should be
"online try" to emphasize it is not some sort of demo/download.

What about I give it a try :

About
News
Documentation
FAQ
Screenshots/Video
-----------
Online try
Download
---------
Developer
Mail list
Bug report
Bibliography
Related link

I am not sure about bib
On the left just the logo without colored frame around them.
Stats on the bottom

News should be able to fit in the front page.

And most important Axiom completely lack visual identity !!!
I am not suggesting that we change the logo, I like it ok, but it should be
made larger.
Almost banner size with a catch phrase.


> Then I am going to look for a good introduction. And I hate
> > it when people give me choice I want the one and definitive
> > introduction. I will read between 5 and 20 pages max. Any
> > document that go over 100 pages will scare me to death.
>
> I have to agree that we lack a good introduction. But "the one
> and definitive introduction" is rather hard to write for Axiom
> I think. Perhaps you would be willing to create a draft? Maybe
> we can try to write such an introduction in a collaborative
> way?


Cant I just criticize it ? I will have a lot of free time in a month I will
give it a try.

> A good indicator for me is if I feel ok to print it.
> > And if I survive I will look for more advanced material.
>
> > For the axiom user. We should not expect him to subscribe to
> > the mailing list.
>
> I find that a rather surprising statement. As a user of new
> open source software that is one of the first things that I
> expect to have to do. One of the things that people repeatedly
> claim for open source software is that the email lists of most
> open source projects is a much better source of help and
> information that any traditional help resource for commercial
> software.


Send a mail maybe, subscribe I doubt so, do you subscribe to X.org ? bash ?
apache ? gcc ? perl ? and so on

> He will go to the web page to solve his problems and get new
> > version. Here it is good FAQ, oriented tutorial, documentation
> > and search able mail list. Subscribing to a mailing list is a
> > big step, we should not expect people to do it.
>
> I agree that the current Axiom tutorial information could be
> much better organized. Do you have any suggestions about how
> to do this?


I havent think about it much yet sorry.
What I personally like is programming tutorial for programmer.

On the Axiom Wiki it is also possible for users to "subscribe"
> to specific web pages. Did you notice the word 'subscribe' in
> the top menu line? This allows people to automatically receive
> notices of new or changed web pages without having to subscribe
> to the email list. Do you think this is a useful feature?


No I hate it, getting a mail when somebody correct some spelling mistake.
And worse of all it is opt out !!! ( I think)

What I like is a release mailing list, when I get at maximum every 3 month a
mail telling me about a new version or some special events. He has to be
very low traffic.


> For active user/ contributors/ developer what is needed is a
> > collaboration tool, I have no answer for that.
>
> Axiom Wiki? Or do you mean that what we have now does work as
> a collaboration tool?


I mean online collaboration tools in general is a very difficult subject,
and I dont even have very good questions about it.

> Personally I find the wiki difficult to use, it seem a big mess
> > to me and I spend a lot of time looking for documents I saw
> > before and know should be somewhere.
>
> I am surprised that you say "what is needed is a collaboration
> tool" and then you say immediately after that you find the wiki
> difficult to use. I wonder what you have in mind when you say
> "collaboration"?


A wiki with a better organisation ;)

> It lack structure and search will not replace that, in general
> > giving a name to your problem is the difficult part.
>
> Of course there are alternatives to search such as the Site Map
> and Site Index links on the right sidebar. But I agree in general
> that the structure of the web pages on the Axiom Wiki web site
> could be improved.
>
> I did try to make some progress toward improving this structure
> by introducing the new Up/Down navigation links on the left side
> of each page (except FrontPage). My intention is to make the
> structure of the pages more obvious and more useful for "navigating"
> (i.e. manually searching) through the web site. Do you think that
> is useful?


Yes, a nice tree, where every think is accessible from the 1st page in some
meaning full way( easy to say).

> When you look at the tree structure you see a big mess and all
> > the bugs !
>
> Well, it is not really a tree structure. Each page can be linked
> to several pages both "up" and "down". So it is really a lattice
> (to a mathematician) or an ontology (to at least one branch of
> computer science).


I want a spanning tree.

When you say "all the bugs" do you mean the issue tracker pages?
> These to not appear in most of the links on the left sidebar.
> Or do you mean when you look it the overall structure under
> 'contents'? Because we have over 300 such issue reports (about
> the same number as all other contents of the web site), these
> do tend to dominate any listing of contents. Perhaps we need a
> way to suppress these from the main contents list and only
> show them on a more detailed contents list?


That will be very nice indeed, do you think it can be easily done ?

\start
Date: 02 Aug 2006 05:02:01 +0200
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: [build-improvements] Requests for discussion

Cliff Yapp writes:

| On Tuesday 01 August 2006 6:49 pm, Gabriel Dos Reis wrote:
| 
| > | Most open source installations ship a pre-generated ./configure
| > | file and I think Axiom should be no different.
| >
| > Yes, that is what we will do.  That configure is generated by Autoconf
| > based on configure.ac.  Autoconf does not expect pamphlet files.
| > Autoconf want an input in a language it understands. Consequently, we
| > must present configure.ac in a way appropriate for Autoconf.
| > Therefore we cannot depend on noweb (notangle).
| 
| If I understand the question, you are asking how we can have only literate 
| program files in Axiom at the get go and still not depend on noweb.  The 
| simple answer is, we can't. 

Actually, we can if we don't insist that literate files must be
pamphlet files or we must use noweb :-) 

[...]

| I've always wondered why LaTeX itself couldn't handle processing a pamphlet 
| file as a regular latex file  - after all, couldn't it just replace 
| <<chunckname>> [content] @ by a fancy version of \begin{verbatium}[content] 
| \end{verbatium} or some such?  You would still need a notangle command to 
| extract source code, but at least you could read the documentation without 
| needing anything more than LaTeX.

I would like to move away from the @ and [] fancy syntax.  But, that
is a different battle I guess.

[...]

|  As long as configure.ac.pamphlet is written and maintained in 
| the .pamphlet file I don't see a problem with special casing the continual 
| presence of configure.ac  - it's pretty much inevitable.

OK.  I'll write up a development enrivonment minimal requirements and
include noweb (I still dislike that specific requirement).

| > | All this looks like a horrible hack to me - unless I am missing
| > | something fairly basic. What is wrong with the usual way of using
| > | noweb?
| >
| > See the explanations above.
| 
| I understand the desire to be able to bootstrap, but there is no way around 
| it - we must have one non-pamphlet file present to kickstart the process.  
| Personally I would suggest two or three - a set of Bash and Windows script 
| files containing all the autoconf and other incantantations the user would 
| need to make might simplify matters even more.
| 
| I don't think we should fear a couple of non-pamphlet files being present in 
| the top level directory - indeed, it will simplify matters considerably from 
| the user standpoint.  They won't know (and may not want to know) what a 
| pamphlet file is all about - they just want to build and use the math program 
| to do math.  In that case, the complete absence of anything familiar will 
| turn them off.
| 
| I would suggest the minimal (and maybe maximal) set of:
| 
| README
| configure.ac
| buildaxiom.sh
| buildaxiom_windows.<whatever windows uses>

The minimal setting should include

  configure                     -- generated by Autoconf; end-user stuff
  configure.ac                  -- generated by noweb, developer
  configure.ac.pamphlet         -- hand-edited, developer
  build-setup.sh                -- hand-edited; end-user stuff

build-setup.sh will abstract over all the low-level commands that
generate configure.ac from configure.ac.pamphlet, configure from
configure.ac -- and Makefile.am from Makefile.am.pamphlet when we
converts to Automake.

I'm not a windows developer, so I'll leave the windows stuff to others
(hi Bill).

[...]

| > This is a hack; I agree.  No more horrible than what we currently do
| > with noweb.  However, I don't like it.  That is why I called for
| > discussion and suggestions for improvements :-)
| 
| There is no way to bootstrap without a "lower level" file present to kick the 
| process off,

I know.  configure.ac is that file.  And the point that started the
experiment is that once you've written configure.ac, there is very
little gained by putting it in a pamphlet file.  All the documentation
will need to be present in the final generated configure file.
Consequently, the low-level stuff here equals to the high-level variant.

| unless (as you already attempted) the higher level files are 
| also legal lower level files.  I don't think we want to redefine the literate 
| strategy we use to that degree - it's not worth it.

I'm really annoyed by the dependency on noweb to bootstrap the
process.  I would rather, by a large degree, vanilla traditional
tools, e.g. plain 'sed'.  However, I will proceed as outlined above, and 
will at the same time respectfully register my strong disagreement.

[...]

| In a way, it's the same problem Tim faced with Axiom being needed to build 
| Axiom.  The only way out was (and still is) to have some files in lisp 
| present, to teach lisp to read and understand BOOT and SPAD.  Same deal here.  
That is a good recipe for maintenance nightmarre -- recent debates about
redundant boot anyone?  There ought to be a better way to deal with it.  

In the case of configure.ac, I'm pretty convinced because I've tried
several ways.  The conclusion invariably is that there is no
difference between the low-level stuff and the high-level stuff.  Any
attempt to raise the abstraction there is a non-interesting, fruitless
exercise. 

The case for boot might be different though -- I've not spent enough
time there yet.

| It's a universal problem - if we wanted to bootstrap a machine from a cold, 
| memoryless, powerless state we would need some binary to feed it before it 
| could start speaking assembly. True bootstrapping is a very rare event ;-).  

I've been hacking real life compilers for over decade now :-)

[...]

| 1 and 3 are solved by always having a current notangle of configure.ac present 
| in the tree at all times.  As for two, I think we should assume a working 
| notangle is available.  We have to assume SOMETHING is working,

No question we have to assume something is workin -- just assume,
everybody knows that.

The issue is whether it must be noweb.  I think "no".  But, I do
understand your view.

\start
Date: 02 Aug 2006 05:11:09 +0200
From: Gabriel Dos Reis
To: Antoine Hersen
Subject: Re: Front page esthetic

Antoine Hersen writes:

[...]

| The problem is those new comers are not "fresh" any more.
| If you have been using MMA for some time, you need a good enough reason to
| abandon all your experience and change tool.

This is a very good point, and should not be underestimated.

I'm still struggling at how I will "sell" Axiom to my students -- I
need to find a good answer very soon.  Otherwise I'll do the teaching
with Maple and Mathematica.

[...]

| What about I give it a try :
| 
| About
| News
| Documentation
| FAQ
| Screenshots/Video
| -----------
| Online try
| Download
| ---------
| Developer
| Mail list
| Bug report
| Bibliography
| Related link

I like it.

| I am not sure about bib
| On the left just the logo without colored frame around them.

we need to have a link to research papers from the frontpage.

\start
Date: Tue, 1 Aug 2006 23:20:30 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: [build-improvements] Requests for discussion

On Tuesday, August 01, 2006 10:12 PM Cliff Yapp wrote:
> ...
> I thought it would end up like this:
>
> 1)  Have configure.ac and configure.ac.pamphlet both present
> in the top level directory.  configure.ac.pamphlet is where
> editing is done, and when a commit is made (for this one file)
> a configure.ac file is also committed
> ...

I don't see why we need 'configure.ac'. Just 'configure' and
configure.ac.pamphlet should be enough. No? It is not so
different than the fact that we have both Makefile and
Makefile.pamphlet now in the current Axiom distribution. With
the new configure process this "bootstrap" just moves back
one step.

As I understand it configure.ac would only be necessary in
order to generate a new 'configure' file and this would
normally only be done by an ambitious developer *after* they
had successfully installed Axiom at least once.

> 2)  Extracting the documentation out of configure.ac.pamphlet
> would require the use of the notangle command ...
>

Actually the 'noweave' command extracts the LaTeX file. 'notangle'
is required to extract configure.ac from configure.ac.pamphlet.
They are both parts of noweb which is either pre-installed or
optionally installed as one of the first steps in the axiom
build process.

The possibility of using some other literate programming tool
besides noweb is an interesting issue, but I think we should
agree that it is beyond the scope of the work.

> ...
> I don't think we should fear a couple of non-pamphlet files
> being present in the top level directory - indeed, it will
> simplify matters considerably from the user standpoint.

I agree. As a user I would like to see just the usual:

  ./configure
  make
  make test
  make install
  axiom

What happens inside I don't care (unless it fails).

If ./configure says:

  noweb is missing. Please install noweb first or specify
  the option --with-noweb

I think most users of open source who are willing to build
from source would be able to handle that.

I think Axiom developers can live with just a little more
complication than that in order to handle the literate
programming methodology. So they need to have noweb installed.
This would certainly be the case anyway if they had already
built Axiom successfully. In that case they can use notangle
to extract a modified configure.ac from an edited version of
configure.ac.pamphlet before running automake/autoconf to
generate the new 'configure' and Makefile.in for a revised
distribution.

To be nice to new developers we might want to provide

  make distribution

to automate this process.

>
> I would suggest the minimal (and maybe maximal) set of:
>
> README
> configure.ac
> buildaxiom.sh
> buildaxiom_windows.<whatever windows uses>

buildXXX.sh is not so common. I would prefer to see just the
following pre-extracted as read-only files in the root of the
distribution:

  README
  configure
  Makefile.in

with all others just .pamphlet files. The three files above
would also be contained as chunks in one of the .pamphlet
files - probably Makefile.pamphlet where all the other build
documentation is maintained. Because the Axiom build uses
recursive make on subdirectories, perhaps it would be convenient
if the Makefile.in files were present on each sub-directory
of the distribution. But as usual it is just the pamphlet
files that would be edited.

\start
Date: 02 Aug 2006 05:45:11 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: [build-improvements] Requests for discussion

Bill Page writes:

| On Tuesday, August 01, 2006 10:12 PM Cliff Yapp wrote:
| > ...
| > I thought it would end up like this:
| > 
| > 1)  Have configure.ac and configure.ac.pamphlet both present 
| > in the top level directory.  configure.ac.pamphlet is where
| > editing is done, and when a commit is made (for this one file)
| > a configure.ac file is also committed
| > ...
| 
| I don't see why we need 'configure.ac'. Just 'configure' and
| configure.ac.pamphlet should be enough. No? 

Autoconf needs an input to generate configure, that ought to be
configure.ac.  You can imagine that the configure.ac exists only for
the purpose of generating configure, but things are not that simple
when one uses to other tools that depend on configure.ac.

[...]

| > I don't think we should fear a couple of non-pamphlet files 
| > being present in the top level directory - indeed, it will
| > simplify matters considerably from the user standpoint.
| 
| I agree. As a user I would like to see just the usual:
| 
|   ./configure
|   make
|   make test
|   make install
|   axiom
| 
| What happens inside I don't care (unless it fails).

Yes.


[...]

| I think Axiom developers can live with just a little more
| complication than that in order to handle the literate
| programming methodology. So they need to have noweb installed.
| This would certainly be the case anyway if they had already
| built Axiom successfully.

Not necessarily.  If I'm packaging axiom for a system, I'll not
necessarily have nowed installed, even after I built Axiom.

[...]

| To be nice to new developers we might want to provide
| 
|   make distribution

When we move (later) to Automake, we will have 

   make dist

which is standard, and offered by Automake for free.

\start
Date: Tue, 1 Aug 2006 23:48:48 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: [build-improvements] Requests for discussion

Gaby,

On Tuesday, August 01, 2006 11:02 PM you wrote:
> ...
> I'm not a windows developer, so I'll leave the windows stuff
> to others (hi Bill).
>

The windows build uses MSYS/MingGW so there is not much
difference from the usual linux build process. All of the
standard developer tools work in (almost) the same way.

The only complication here about Axiom on windows is that the
patches to the original axiom--main--1 linux distribution made
nearly two years ago by Mike Thomas to create axiom--windows--1
have not yet been merged back into the main sources. This is
not such a big deal - but somebody has to do it ... :)

A new release of Axiom on windows is long over due. Is anyone
interested in taking on the task? I am available to help but
not to lead the effort. And of course there is a chance that
we might be able to get Mike involved again. :)

\start
Date: 02 Aug 2006 05:49:59 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: [silver] you patch

Hi Ralf,

  I've tested you patches to fix build issues.  They are merged to the
silver branch as revision 78.  Many thanks.

  Now, I'll move in the configure stuff.

\start
Date: Wed, 2 Aug 2006 00:10:35 -0400
From: Tim Daly
To: Bill Page
Subject: Re: [build-improvements] Requests for discussion

Bill,

Do you have an up-to-date set of sources from which you can build the
windows image? Are they someplace I can get at them?

\start
Date: Wed, 2 Aug 2006 00:59:10 -0400
From: Bill Page
To: Tim Daly
Subject: RE: [build-improvements] Requests for discussion

Tim,

On Wednesday, August 02, 2006 12:11 AM you asked:
>
> Do you have an up-to-date set of sources from which you can
> build the windows image? Are they someplace I can get at them?
>

Up-to-date? No, only the originals in the arch axiom--windows--1
branch and the same sources in darcs - both dated about Tue,
15 Mar 2005. :(

You can get to either of these for windows (but using tla on
Windows is a bit awkward). For details see:

"How I Built Axiom on Windows" at

http://wiki.axiom-developer.org/BuildAxiom

The only things missing here are the list of gcc files that must
be included in order to compile SPAD code and how to use NSYS to
build the actualy binary distribution for windows. If anyone gets
that far, I can help fill in these gaps.

\start
Date: Wed, 2 Aug 2006 03:13:16 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Be Bold (was: Front page esthetic)

On Tuesday, August 01, 2006 4:22 PM Ralf Hemmecke wrote:
> ...
> First of all, I'd like to thank Bill for all the effort he
> has put into the Wiki.

You are welcome. :-)

>
> In some points I must, however, agree with Antoine. The current
> Wiki currently is a bit of a mess. There are only a few pages
> that are of real value.

I was rather hoping for more than "a few pages" ... ;)

One thing to consider is that what is "real value" to one person
might not be so valuable to someone else (and vice versa). And
of course what is of value to you now changes over time as you
become more experienced.

> You know, when I started I had hard times to find my way
> through the information that I was looking for and even now I
> don't find things that I am looking for in a few clicks.
>

Everytime this happens to you it might be a great benefit to
others if you could note this quickly some where on the web
site. I good place to do this might be on the FAQ page.

> Until somebody posted the BeBold principle to the mailing list
> I was always hesitating not to edit/delete too much of the existing
> information, but surely that slowed down improvements to the
> wiki. Now I am a bit bolder, but it is still hard.

Here is my adapted version of the Wikipedia 'Be Bold' principle.

http://wiki.axiom-developer.org/SandBoxBeBold

I hope people will take the time to practice being bold by
correcting and extending this statement. Then we could advertise
that is it also official our policy.

>
> If I look now at some pages, I would rather like to see that
> information organised in a different way, but different from a
> text in a text-editor, I cannot simply drag & drop text from
> one page to another. Well, I should have open several browser
> windows, I know.

It is also possible to use emacs as an external page editor.
Perhaps some people would find this more convenient.

>
> What is also important is some more structure of the wiki. I am
> personally used to linear text with sections and subsections,
> ie, some kind of hierarchy. We should have a number of standard
> pages that can be edited only by registered Axiom-developers.
> These pages should not change too much once they are set up.
> ...

I think that is a good idea. In fact things have been slowly
evolving in this direction ever since Martin Rubey's first
efforts improve the organization of the Axiom Wiki web site.
Suggestions on what these "standard pages" should be would be
most welcome.

> Bill, what I would like to see on top of an edit page is a
> link to BeBold. Furthermore, it should be said that the first
> paragraph of the page is a kind of abstract that is used for
> the "SiteMap" (which can be considered as a kind of glossary,
> if you like).

I am willing to add such a link to the edit page once we agree
on the draft in SandBoxBeBold.

>
> Actually, I would also like to have some facility that let's
> me move the pages in the tree structure of the wiki. Best
> would be to see the tree and take my mouse to move pages in
> the hierarchy.

Well, we don't have the ability to do it with just your mouse
but you can move pages in the structure using 'backlinks'. If
you click on the page name in the header you will see a list
of pages that link to this page and also a list of the pages to
which this page links. The main purpose of the backlinks page
is to allow you to specify the "parents" of the page. I recently
made some improvements to the backlinks page based on code
from a more recent version of ZWiki.

The list of parents for each page actually forms a "topic lattice"
or "ontology" which specifically relates the current page to
other pages in a "hierarchical" manner (not necessarily a tree
structure). This structure is shown in the left sidebar (except
on FrontPage).

The left side bar displays the topic lattice both above (UP)
and below (DOWN) the current page. In general, clicking on links
in the UP section leads to more general topics, while clicking
links in the DOWN section leads to more detailed topics.

> ...
> > Then I am going to look for a good introduction. And I hate it
> > when people give me choice I want the one and definitive
> > introduction.
>
> I think we should take this consideration seriously. Currently
> "Tutorial" links to "AxiomInterface" (very intuitive!) and gives
> not a tutorial.

Originally this page was intended as a very quick introduction
to the Axiom interface on the Axiom Wiki - not an introduction
to Axiom itself.

> I rather think that we should maybe give a weighted list of
> introductory material.
>
> http://www.dcs.st-and.ac.uk/~mnd/documentation/axiom_tutorial
>
> The above tutorial looks quite reasonable to me. The tutorial
> page should not be like a sandbox were everyone just adds
> his/her commands.
>
> I hate everything on
> http://wiki.axiom-developer.org/AxiomInterface that
> comes after the "That was easy!". It should go away, because
> it looks unprofessional.

I agree. Be Bold!

> ...
> > And modifying a page is not has easy at it sound. Writing
> > correctly is time consuming and difficult. I never feel like
> > touching other people stuff. You can often see it in a wiki
> > where old information is rarely deleted.
>
> I also felt like it. We all know that we can unroll changes,
> but what I don't know is, whether everyone can do it.

Yes. Just click 'diff' on the top line.

> It should be more obvious how things can and will be undone
> if people are too bold.

The proposed SandBoxBeBold page deals with this issue.

> Another suggestion that should be visible on top of an edit-page.

Ok, but I would like a design that does not involve adding
too much more text to the edit-page. Maybe just another link
to some specific help page?

\start
Date: Wed, 2 Aug 2006 03:25:48 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Front page esthetic

On Tuesday, August 01, 2006 3:21 PM Alfredo Portes wrote:
>
> I do not know what was the first expectation with the Wiki.

The MathAction web site (consisting of Axiom Wiki and Axiom
Portal) started out simply as an experiment to demonstrate how
Axiom could be interfaced to LatexWiki (an add-on module to
ZWiki). The idea was **first** to use LatexWiki as an interface
for Axiom and only *second* to see if we could use the wiki
as a way of collaborating on creating an Axiom users and
developer web site... but of course our ambitions grew over
time (without respect to available time :).

> In our part (Doyen), the Wiki is the foundation of Tim's idea.
> Maybe it was expected to do contributions to Axiom directly to
> the wiki, some kind of online development environment. This to
> me is a great idea. But apparently this is not occurring by
> reading Bill's comments.

Yes, I think Doyen is still an important part of the overall
"vision" of where this is all going. And I think the DoyenCD
project is an important new tool that might well encourage
people to also participate on the Axiom Wiki by allowing them
to first experiment and practicing on the own computer by just
booting the DoyenCD (or virtual machine).

\start
Date: Wed, 02 Aug 2006 09:36:08 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Front page esthetic

>> (Could one have a table of contents at the top of that page?)

> What did you have in mind? Table of Contents for the contents
> of the page or something more inclusive?

I have used <h1> and <h2> to structure the page. Since I consider that 
page like a (very short) paper, I would like to see the headlines appear 
either at the top of the page or on the left hand side (without typing 
more myself). We already know that Zwiki handles the first paragraph of 
the page as an abstract that is used also in other places like

http://wiki.axiom-developer.org/SiteIndex

Unfortunately, that "abstract" thing is not/was not know to many 
wiki-contributors. It should be more apparent how to structure a page.
One suggestion from me would be: If a new page is created, a 
StructuredText-Template with 2 or 3 sections and subsections is 
generated, so that one remembers, how to structure the page. If I look 
at wikipedia, they also don't just have random looking pages, but it 
looks they have somethink like a "corporate design" and that even with 
thousands of different people contributing.

>> (4) Browse sources online

> The current "Online sources" are actually pamphlet files implemented
> as wiki pages. Some details are provided here
> 
> http://wiki.axiom-developer.org/210

Aha!!! Then it looks to me that this is ANOTHER repository that can even 
be freely distributed too. Actually, I think that is a great idea, but 
obviously, it is not really apparent that one might change Axiom. And it 
is also not clear, what the process is to make changes to that 
WikiRepository (Is this now a Bronze = testing repository? Or would that 
be too much confusion?). In fact, that repository should appear on the 
http://wiki.axiom-developer.org/SandboxAxiomSources site at the very 
bottom, right? Who is maintaining and testing contributions to it? 
Should we have a branch at SVN that is in sync with the Wiki-repository?

> The 'axiom--test--1' pages correspond to what the Axiom sources
> were about last August, 2005. There have been some online updates -
> especially those required to allow Axiom Wiki to generate hypertex
> dvi and pdf files, but none of these changes have been propagated
> back to the original sources (either gold or silver). I used a
> different name 'axiom--test--1' as a reminder that this source
> is not either of these.

OK the name is clear now to me, but as I said, it should be explained 
somewhere, what happens with contributions and how they might make their 
way to silver and gold. I think it is important to make our development 
process clear to potential contributors. (OK, first, we should come up 
with one.)

> And most ambitiously, one could have an automatic build process
> that built Axiom directly from the current online sources and if
> it was successful, automatically run a series of "test" wiki pages
> containing Axiom commands and expected results.

Very ambitious! Doesn't that cost a lot of server power? And note, you 
expect the user to wait for at least half an hour before the compilation 
is finished. Who is going to wait that long?

> I still think it is rather sexy, but until (or if)
> Axiom developers show more interest in this concept, I am rather
> reluctant to spend more of my time on this experiment.

I don't know exactly, what SCM you have behind axiom--test--1, but I 
guess, it is darcs. Would it be much of an effort to create a branch on 
the SVN archive and keep it in sync with axiom--test--1? Back and forth?
But I see a problem with modifications that break the building process. 
No? Is there currently some connection between the axiom that runs in 
the background of the wiki and axiom--test--1? If not then it would be 
easier to keep the sources in sync.

> But...
> 
> There are alternatives for browsing online source code directly
> from source repositories. I have for example also implemented the
> darcsweb cgi script that enables browsing the darcs repository. Go to
> 
> http://wiki.axiom-developer.org/MathActionRepository
> 
> and click on "browsed online", then click on "axiom--main--1".
> 
> The axiom--main--1 darcs repository corresponds to the actual version
> of Axiom running on the axiom-developer.org server that runs Axiom Wiki
> and Axiom Portal. It is currently in synch with the arch axiom--main--1
> repository because I just recently updated the version of Axiom.

Nice. Could you add entries to SandboxAxiomSources. I think we should 
have just ONE page that describes all the different ways to access sources.

However http://wiki.axiom-developer.org/MathActionRepository is 
read-only, so http://wiki.axiom-developer.org/axiom--test--1/FrontPage
is superior, since it allows contributions. We just have to make it obvious.

\start
Date: Wed, 02 Aug 2006 10:08:12 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Front page esthetic

>> When you look at the tree structure you see a big mess and all
>> the bugs !

> Well, it is not really a tree structure. Each page can be linked
> to several pages both "up" and "down". So it is really a lattice
> (to a mathematician) or an ontology (to at least one branch of
> computer science).

Aha, a lattice. I didn't know. That makes structuring a bit more 
difficult for me. And I think (at least currently) it is also difficult 
for someone who just wants to read something from top to bottom. So 
actually, though it is a lattice, I would like to have an option to 
present the innocent (new) reader a (selected by us) tree structure of 
the information. If this reader got the main ideas from such a 
structured linear text (basically like in a book), he is probably more 
interested in browsing through the whole lattice. But I would like to 
give newcomers a linear view of our information.

Some time ago, I started with thinking about a (handwritten) table of 
contents that tried to impose a structure. I did not come very far since 
I got lost myself in the lattice. And I don't know whether a handwritten 
TOC is good. Basically, it sounds like the LEO idea, but I don't see a 
tool on the wiki that easily lets me combine pages into a new structure. 
My mouse is currently completely useless for such things.

\start
Date: Wed, 02 Aug 2006 10:33:50 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: rate a wiki page

> One thing to consider is that what is "real value" to one person
> might not be so valuable to someone else (and vice versa). And
> of course what is of value to you now changes over time as you
> become more experienced.

Is there actually someone who uses the page rating at the bottom right 
of the wiki? I have never pressed a button there. (Shame on me.)

\start
Date: Wed, 02 Aug 2006 10:40:58 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Be Bold

> Here is my adapted version of the Wikipedia 'Be Bold' principle.
> 
> http://wiki.axiom-developer.org/SandBoxBeBold

Bill, I have clicked to that page. My first impression was: I am not 
going to read it. It's too much.

The first line is not OK for my taste. It will be shown in SiteIndex and 
what does it tell you? You don't learn what BeBold is from that. So the 
SiteIndex is useless.

There should be just one paragraph explaining in short, what BeBold 
means. It should be a teaser to read the rest of the page. 
Unfortunately, I don't have an idea now, but maybe I'll change that page 
tonight.

\start
Date: Wed, 02 Aug 2006 10:42:18 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Be Bold

> It is also possible to use emacs as an external page editor.
> Perhaps some people would find this more convenient.

How??? Please let us know.

\start
Date: 02 Aug 2006 10:42:09 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: rate a wiki page

Ralf Hemmecke writes:

| > One thing to consider is that what is "real value" to one person
| > might not be so valuable to someone else (and vice versa). And
| > of course what is of value to you now changes over time as you
| > become more experienced.
| 
| Is there actually someone who uses the page rating at the bottom right
| of the wiki? I have never pressed a button there. (Shame on me.)

neither did I.

\start
Date: Wed, 02 Aug 2006 11:00:15 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Be Bold

> Well, we don't have the ability to do it with just your mouse
> but you can move pages in the structure using 'backlinks'. If
> you click on the page name in the header you will see a list
> of pages that link to this page and also a list of the pages to
> which this page links. The main purpose of the backlinks page
> is to allow you to specify the "parents" of the page. I recently
> made some improvements to the backlinks page based on code
> from a more recent version of ZWiki.

I am slowly learning... ;-)

Now I see: "Other parent:". Maybe that is clear for a native speaker, 
for me it is not. For example I see on 
http://wiki.axiom-developer.org/SandBoxBeBold/backlinks
just the parent FAQ. So if I put something into "Other parent" will this 
remove the link to "FAQ". Writing "additional parent" would be more 
obvious to me.

Why cannot I add more children? Why not having something like

Parents of this page, i.e this page is a subtopic of

1. Blah
2. Foo
Add new parent: _______ [Browse Index]

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

Children of this page, i.e this pages has the following subtopics:

1. Habl
2. Oof
3. Bar
Add new child: ________ [Browse Index]

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

And maybe at the bottom of the page you write that the whole structure 
of the wiki forms a lattice.

Ralf

\start
Date: 02 Aug 2006 11:22:39 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [build-improvements] Requests for discussion

Ralf Hemmecke writes:

| Does that help you? I am running debian sarge.
| I don't see a ./config file in that directory.

Ralf --

   Based on the feedback I got, I implemented the Autoconf-based
configuration stuff as a pamphlet file (see below).  At the moment,
the only thing it does is to mimic the existing (old) configure file.
Future work aims at reducing the build process to

     ./configure
      make
      make install


   To test this, you don't need to run Autoconf.  Just check out a
fresh copy of the build-improvements branch and proceed as usual.

   Feedback appreciated.

Thanks!

-- Gaby

\documentclass[12pt]{article}
\usepackage{axiom}
\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fancyvrb}
\usepackage{pslatex}
\usepackage{noweb}
\usepackage{url}

\newcommand{\file}[1]{\textsf{#1}}
\newcommand{\email}[1]{\url{#1}}
\CustomVerbatimEnvironment{chunk}{Verbatim}{frame=none,fontsize=\small}

\title{The Toplevel \file{configure.ac} File}
\author{Gabriel Dos~Reis}

\begin{document}
\maketitle

\begin{abstract}
 ...
\end{abstract}

\section{Introduction}
This is the top-level Autoconf file that sets up the minimum build
environment for Axiom.  At the moment, the mainline version
of Axiom is driven by \file{Makefile} pamphlet files.  This effort
strives to move the build machinery to more abstract description
and conventional ones.
The task is compounded by the fact that the Axiom system is very 
complex -- but much less complex, I suspect, than say GCC.  There does not
seem to be good reasons why Axiom should build its own ghetto.

Autoconf supports two kinds of comments:
\begin{enumerate}
\item [[dnl]] style, and
\item [[#]] style.
\end{enumerate}
Comments introduced with [[dnl]] do not appear in the \file{configure}
output file.  Comments starting with [[#]] appear verbatim in the
\file{configure} generated file.  Because this source file is
literate, there almost never is a need to use the [[dnl]]-style
comment.  Consequently, Autoconf comments in this file should be
of [[#]]-style.  Such comments can be of value to the occasional
poor masochist who will be debugging the generated \file{configure}
file.

\section{Old Story}

The contents of top-level \file{configure} file from mainline is 
reproduced below.  It will serve as the initial basis for the new,
improved, build machinery.

\begin{verbatim}
# The sysname function uses uname -s to try to decode what kind of
# system to build. Currently the return value of uname is mapped as
#       Linux          --> linux
#       MINGW32_NT-5.1 --> windows
#       SunOS          --> Solaris9
#       Fedora Core 3  --> fedora3
#       freebsd        --> freebsd
#
# The solaris platform needs patch->gpatch, awk->gawk, tar->gtar
 
sysname () {
if [ -f /etc/redhat-release ] ;
 then 
  SYSNAME=`cat /etc/redhat-release` 
  if [ "$SYSNAME" = "Fedora Core release 3 (Heidelberg)" ] ; 
   then SYSNAME=fedora3
  fi
  echo SYSNAME=$SYSNAME
fi
if [ ! "$SYSNAME" = "fedora3" ] ; 
 then
   SYSNAME=`uname -s`
   echo $SYSNAME 
   if [ "$SYSNAME" = "Linux" ] ; then SYSNAME=linux
   elif  [ "$SYSNAME" = "MINGW32_NT-5.1" ] ; then SYSNAME=windows
   elif  [ "$SYSNAME" = "SunOS" ] ; then SYSNAME=solaris9
   elif  [ "$SYSNAME" = "freebsd" ] ; then SYSNAME=freebsd
   else
     echo Your system name is $SYSNAME
     echo We do not know how to build for this kind of system
     echo Send a note to list about it
     echo
     exit 0
   fi
fi

}

# This function checks for the gawk command. 
# If it exists then AWKNAME is the complete pathname

checkgawk() {
AWKNAME=`which gawk 2>>trace`
if [ -n "$AWKNAME" ] ; then
 if [ -x $AWKNAME ] ; then 
  echo 
 fi
fi
}

# This function checks for the nawk command. 
# If it exists then AWKNAME is the complete pathname

checknawk() {
AWKNAME=`which nawk 2>>trace`
if [ -n "$AWKNAME" ] ; then
 if [ -x $AWKNAME ] ; then 
  echo 
 fi
fi
}

# This function checks for the awk command. 
# If it exists then AWKNAME is the complete pathname

checkawk() {
AWKNAME=`which awk 2>>trace`
if [ -n "$AWKNAME" ] ; then
 if [ -x $AWKNAME ] ; then 
  echo 
 fi
fi
}

# This function uses the check*awk functions to decide 
# whether the system can build noweb. If one of gawk, nawk or awk
# are not found we fail.
needAwk ()
{
checkgawk
if [ -z "$AWKNAME" ] ; then
  checknawk
  if [ -z "$AWKNAME" ] ; then
    checkawk
    if [ -z "$AWKNAME" ] ; then
      echo We need the commands gawk, nawk, or awk
      exit 0
    fi
  fi
fi
}

# The mustSet function tells the user what needs to be typed on the 
# command line. If any extra variables need to be set we add them here.
# Currently the only thing we check if for the presence of gawk, which
# is the default in the Makefile. If gawk does not exist we can use 
# either nawk or awk but the user has to specify that on the command line.

# We check the system we are using with the uname command and try to
# generate the appropriate value. We fail otherwise.

# We generate the appropriate command line that the user should use.

mustSet() {
echo
echo ===================================================
echo You must set your AXIOM and PATH variables. Type:
echo
echo To build the rest of the system type:
echo
echo export AXIOM=`pwd`/mnt/$SYSNAME
echo 'export PATH=$AXIOM/bin:$PATH'
if [ "$SYSNAME" = "freebsd" ] ; then
  echo Note that freebsd usually has noweb available
  echo If you wish to use the standard version you must type
  echo touch noweb 
  echo If you wish to use a pre-installed GCL you must type
  echo make GCLVERSION=gcl-system
fi
if [ "$SYSNAME" = "solaris9" ] ; 
 then echo make AWK=gawk TAR=gtar PATCH=gpatch
elif [ "`basename $AWKNAME`" = "gawk"  ] ; 
 then echo make
 else echo make AWK=$AWKNAME
fi
echo
echo configure finished.
}

#########################################################################
# This is the main line of configure logic.
# (1) We test to see if we understand this system name. So far
#     the recognized strings from uname -s are translated as:
#       Linux          --> linux
#       MINGW32_NT-5.1 --> windows
#       SunOS          --> Solaris9
#       Fedora Core 3  --> fedora3
#       freebsd        --> freebsd
# (1) We test for the AWK variable. We need one of gawk, nawk, or awk
#     in order to build the noweb software.
# (2) Then we output the final message for the user.
#
# The solaris platform needs patch->gpatch, awk->gawk, tar->gtar
#########################################################################

sysname
needAwk

if [ "x$AXIOM" = "x" ] ;
 then mustSet
 else 
  if [ ! "`dirname $AXIOM`" = "`pwd`/mnt" ]
    then mustSet
    else 
     echo Configure complete. Now type
     echo
     echo make
     echo
  fi
fi
\end{verbatim}


\section{Basic Setup}
\subsection{Autoconf Initialization}

The Autoconf machinery needs to be initialized with several pieces of
information:
\begin{itemize}
\item the \emph{name} of the system --- ``Axiom silver branch''
\item its \emph{version}.  I choose to use the date of last checkin.
  It should probably include the revision number so as to 
  unambiguously identify which Axiom flavour du jour is being
  built;
\item and where to send feedback, \emph{e.g.} bug reports.  I have chosen
  the \email{axiom-developer} list.  That could change in the future if
  we reach a high volume traffic.  For the moment, we don't seem to
  suffer from traffic...
\end{itemize}
<<Autoconf init>>=
AC_INIT([Axiom silver branch], [2006-07-15], [list])
@

Autoconf needs some auxilary files that are present in the sub-directory
\file{config}.  Autoconf needs to be told about that.
<<auxiliary config files>>=
AC_CONFIG_AUX_DIR(config)
@

Notice that since we don't use Automake (yet), we don't initialize
the Automake subsystem.  
<<Automake init>>=
# AM_INIT_AUTOMAKE([foreign])
@

We require Autoconf 2.59 or higher from the developer part. Please,
note that this is no requirement on the user build environment.  All,
it means is that if someone makes changes to the current \file{configure.ac}
file, that someone needs to have Autoconf 2.59 or higher to process this
file in order to regenerate \file{configure}.
<<Autoconf prerequirement>>=
AC_PREREQ([2.59])
@


\subsection{Source tree sanity check}

The Autoconf system implements a very basic, simple-minded, sanity check
whereby it will refuse to run \file{configure} if the source tree does
not contain a specified file, that serves a witness for a bona fide source
tree.  Here, I have chosen \file{Makefile.pamphlet} from the \file{src}
subdirectory.
<<sanity check>>=
AC_CONFIG_SRCDIR(src/Makefile.pamphlet)
@


\subsection{Build Environment}

Standard build environments consist of
\begin{enumerate}
\item the \emph{host} platform,
\item the \emph{build} platform, and
\item the \emph{target} platform.
\end{enumerate}
FIXME: Example on these notions.

We need to get the canonical names for the above three platforms.
After call to this macro, those values are available in the variables
[[host]], [[build]], and [[target]], respectively.
<<host build target platfoms>>=
AC_CANONICAL_SYSTEM
@

For the moment, Axiom supports neither cross-compilation, nor Canadian cross.
Consequently, we must bail out if the build is not native.
<<check cross-compilation>>=
if test $host != $build -o $host != $target; then
   AC_MSG_ERROR([Sorry, only native builds are currently supported])
fi
@

Most of the tools we're testing for are with respect to the build
environment, neither the host nor the target.  

First of all, check for a C compiler --- \textsl{GCC/gcc} preferably.  As
written, this test is OK because currently we support only native
builds.  However, it needs to be more carefully written when we move
to cross-compilation.
<<check for C compiler>>=
AC_PROG_CC
@

Then, check for a usable 'install' program.
<<check for install>>=
AC_PROG_INSTALL
@

The old build machinery needs 'awk'.  Currently, it checks for
'gawk', 'nawk', and 'awk'.  Autoconf has a predefined test for that
task.  It checks for 'gawk', 'mawk', 'nawk', and 'awk' in that order.
That should be OK and match Axiom's need.

The old build system claims that on solaris9, gawk, gtar 
and gpatch are required (with no much explanation of why).  Notice
that these programs are needed only to build Axiom; so we do
check based on the value of [[build]].
<<check for awk tar patch>>=
case ${build} in
     *-solaris9)
        AC_CHECK_PROG([AWK], [gawk], 
                      [gawk], [AC_MSG_ERROR([Axiom needs gawk])])

        AC_CHECK_PROG([TAR], [gtar], 
                      [gtar], [AC_MSG_ERROR([Axiom needs gtar])])

        AC_CHECK_PROG([PATCH], [gpatch],
                      [gptach], [AC_MSG_ERROR([Axiom needs gpatch])]) 
        ;;

      *)
        AC_PROG_AWK

        AC_CHECK_PROGS([TAR], [gtar tar], 
                       [AC_MSG_ERROR([Axiom needs a tar program])])

        AC_CHECK_PROGS([PATCH], [gpatch patch], 
                       [AC_MSG_ERROR([Axiom needs a patch program])])
        ;;
esac
@


Once we have found those values, we must substitute them in the
Makefiles.  For the moment, these actions are effectless as the
current makefile are hand-written and Autoconf-unaware.
<<substitute AWK TAR PATCH>>=
AC_SUBST(AWK)
AC_SUBST(TAR)
AC_SUBST(PATCH)
@

Obviously we need the 'make' program.  No build will proceed without
it.
<<check for make>>=
AC_CHECK_PROG([MAKE], [make],
              [make], [AC_MSG_ERROR([`make' program missing.])])
@

Here, we replicate the behaviour of the old configure, waiting for
a better alternative, e.g. where it is not needed.  THIS WILL BE
REMOVED IN THE NEAR FUTURE.

First, the old machinery has a very coarse target name "discovery"
<<replicate old behaviour>>=
if test -f /etc/redhat-release; then 
   SYSNAME=`cat /etc/redhat-release` 
   if test "$SYSNAME" = "Fedora Core release 3 (Heidelberg)"; then
       SYSNAME=fedora3
   fi
   AC_MSG_NOTICE([SYSNAME=$SYSNAME])
fi
if test "$SYSNAME" != "fedora3"; then
   SYSNAME=`uname -s`
   AC_MSG_NOTICE([$SYSNAME])
   case "$SYSNAME" in
      Linux)
	 SYSNAME=linux ;;
      MINGW32_NT-5.1)
	 SYSNAME=windows ;;
      SunOS)
	 SYSNAME=solaris9 ;;
      freebsd)
	 ;;
      *)
	 AC_MSG_NOTICE([Your system name is $SYSNAME])
	 AC_MSG_NOTICE([We do not know how to build for this kind of system])
	 AC_MSG_ERROR([Send a note to list about it])
   esac
fi

must_set_AXIOM() {
   AC_MSG_NOTICE([])
   AC_MSG_NOTICE([===================================================])
   AC_MSG_NOTICE([])
   AC_MSG_NOTICE([You must set your AXIOM and PATH variables. Type:])
   AC_MSG_NOTICE([])
   AC_MSG_NOTICE([export AXIOM=`pwd`/mnt/$SYSNAME])
   AC_MSG_NOTICE([export PATH=\$AXIOM/bin:\$PATH])
   case "$SYSNAME" in
      freebsd)
	 AC_MSG_NOTICE([Note that freebsd usually has noweb available])
	 AC_MSG_NOTICE([echo If you wish to use the standard version you must type])
	 AC_MSG_NOTICE([touch noweb])
	 AC_MSG_NOTICE([If you wish to use a pre-installed GCL you must type])
	 AC_MSG_NOTICE([make GCLVERSION=gcl-system])
         ;;
      solaris9)
         AC_MSG_NOTICE([make AWK=gawk TAR=gtar PATCH=gpatch])
         ;;
      *)
         AC_MSG_NOTICE([make AWK=$AWK])
   esac
}

if test "x$AXIOM" = "x"; then
   must_set_AXIOM
elif test "`dirname $AXIOM`" != "`pwd`/mnt"; then
   must_set_AXIOM
else
   AC_MSG_NOTICE([configure complete.  Now type ])
   AC_MSG_NOTICE([                              ])
   AC_MSG_NOTICE([make])
   AC_MSG_NOTICE([                              ])
   AC_MSG_NOTICE([export AXIOM=`pwd`/mnt/$SYSNAME])
   AC_MSG_NOTICE([export PATH=\$AXIOM/bin:\$PATH])
fi
@

<<*>>=
<<Autoconf init>>

<<auxiliary config files>>

<<Automake init>>

<<Autoconf prerequirement>>

<<sanity check>>

<<host build target platfoms>>

<<check cross-compilation>>

<<check for C compiler>>

<<check for install>>

<<check for awk tar patch>>

<<substitute AWK TAR PATCH>>

<<check for make>>

<<replicate old behaviour>>
@

\end{document}

\start
Date: Wed, 2 Aug 2006 11:42:40 +0200
From: Kai Kaminski
To: Ralf Hemmecke
Subject: re: Be Bold

>> It is also possible to use emacs as an external page editor.
>> Perhaps some people would find this more convenient.
>
> How??? Please let us know.
There are several wiki modes for Emacs (see 
http://www.emacswiki.org/cgi-bin/wiki/WikiModeDiscussion). I tried one 
of them several month ago, but it didn't quite work then. Maybe the 
necessary server support isn't enabled yet.

\start
Date: Wed, 02 Aug 2006 12:01:31 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Front page esthetic

> | What about I give it a try :
> | 
> | About
> | News
> | Documentation
> | FAQ
> | Screenshots/Video
> | -----------
> | Online try
> | Download
> | ---------
> | Developer
> | Mail list
> | Bug report
> | Bibliography
> | Related link
> 
> I like it.

Looks not too bad to me, but Bill made sections with headlines. So you 
are trying to remove the headlines. OK I can live with that.

I like the first section above, but Screenshots/video is a bit too long 
as a name. Also "Online try"? Why in the next section? What has that to 
do with Download?

Screenshot/video/online try all belong into one category I think. That 
is for getting a feeling of what axiom can do. From the About page there 
should certainly be a link to these pages. So I would rather suggest

...
FAQ
------------
Screenshots
Video
Online Try
-----------
Download
-----------

I don't know what you mean with Developer. Should that link to 
http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers/withNavigator

I don't think that Bibliography is the best word. Would you immediately 
think that you can find actual downloadable papers behind it? Is there 
some native speaker who can come up with something better?

\start
Date: 02 Aug 2006 12:08:47 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Front page esthetic

Ralf Hemmecke writes:

[...]

| I don't think that Bibliography is the best word. Would you
| immediately think that you can find actual downloadable papers behind
| it? Is there some native speaker who can come up with something better?

Many websites just say "Papers".  That is short; that is good.

\start
Date: Wed, 02 Aug 2006 12:11:58 +0200
From: Ralf Hemmecke
To: Kai Kaminski
Subject: re: Be Bold

You know, your link costs me several hours just to find out what to do.

I expected that I convince my browser to fire up emacs when I press the 
edit button on the AxiomWiki page. But from the few lines I read on your 
suggested link it looks different. Cannot you just give a paragraph 
explaining how it should work. So that I would know whether I still want 
to invest time into installing something. And a "installing for dummies" 
algorithm would be very much appreciated. Also my time is limited.

Thank you

Ralf

On 08/02/2006 11:42 AM, Kai Oliver Kaminski wrote:
>>> It is also possible to use emacs as an external page editor.
>>> Perhaps some people would find this more convenient.
>>
>> How??? Please let us know.
> There are several wiki modes for Emacs (see 
> http://www.emacswiki.org/cgi-bin/wiki/WikiModeDiscussion). I tried one 
> of them several month ago, but it didn't quite work then. Maybe the 
> necessary server support isn't enabled yet.

\start
Date: Wed, 02 Aug 2006 12:26:55 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [build-improvements] Requests for discussion

Hi Gaby,

your working times are remarkable. Aren't you in Texas? ;-)

I have seen that there are now also ChangeLog files under axiom/src/doc 
and axiom/src/boot. Is it common to have *not* just one top-level 
ChangeLog? Now I am getting confused of where I should enter my 
changelog stuff.

\start
Date: Wed, 2 Aug 2006 06:33:47 -0400
From: Bill Page
To: list
Subject: spam attack

Axiom Developers,

I am sorry but while I slept I see that the link spammers
finally managed to break through. :( I guess my attempts
over the last few days must have really irritated them...

To stop this attack I had to temporarily disable sendmail
from axiom-developer.org. Delete the mail queue. Then I
modified the spam filter to disallow all comments and edits
containing external links. And restarted sendmail. Now
things are back to normal, I think.

Disabling external links means that http:// is no longer allowed
in any comment. Links that are internal to the Axiom Wiki are
still ok and can be written in the form:

  "link name":/xxx/yyy

or as standard wiki names.

I hope that is enough to hold them off for now.

If it continues we could at least disable the notices from
the Axiom Wiki and this would prevent the email part of the
spam (but not the pollution of the web site). Or we may be
forced (as a last resort) to only permit comments and edits
by registered users which would of course defeat the main
purpose of the wiki.

Who ever did this seems to know what they are doing since it
appears as if they have successfully spoofed a large number
of different ip addresses in a kind of "deny of service"
attack.

Here is a list of the ip addresses used by whoever caused
the most recent spam attack on Axiom Wiki.

125.131.171.215
125.7.33.74
193.170.68.244
200.17.89.80
200.242.249.70
200.3.183.52
200.35.89.157
200.71.62.6
201.147.158.52
201.155.170.232
201.52.4.158
202.110.217.130
202.68.151.116
203.128.5.37
203.158.215.2
210.111.191.107
210.87.251.41
211.113.242.88
211.162.0.131
211.168.194.31
211.173.149.116
211.177.83.80
211.186.170.244
211.195.242.221
211.199.92.168
211.210.36.234
211.213.114.26
211.216.169.71
211.219.155.41
211.221.207.78
211.247.92.76
211.48.66.198
211.62.70.97
212.138.113.12
212.138.113.16
212.9.224.211
213.140.56.3
213.249.155.231
216.207.123.200
217.113.234.7
217.56.108.227
218.11.207.244
218.113.240.98
218.128.16.116
218.152.81.59
218.16.121.26
219.136.249.79
219.240.91.191
220.121.133.210
220.121.153.109
220.126.1.182
220.82.189.124
220.85.41.91
220.89.68.166
220.95.73.118
221.13.66.161
221.142.178.181
221.147.115.15
221.153.14.37
222.104.77.104
222.105.70.230
222.108.109.21
222.238.39.79
58.235.225.18
58.74.245.219
58.76.178.142
59.150.212.199
59.15.50.100
59.4.4.84
61.103.229.60
61.109.90.189
61.18.195.245
61.185.219.235
61.248.150.105
61.35.129.226
61.35.225.92
61.35.66.84
61.41.231.149
61.52.97.61
61.74.139.240
72.2.18.19
80.50.243.250
80.50.82.90

-------

I don't see any immediate pattern in this list, so for now
I must assume that these are bogus ip addresses. If they
were real, we would have grounds to contact the people and
companies to which these addresses are assigned.

If anyone sees a pattern to this list of ip addresses
please let me know.

I apologize for the email pain.

\start
Date: Wed, 02 Aug 2006 12:44:09 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [build-improvements] Requests for discussion

>    Based on the feedback I got, I implemented the Autoconf-based
> configuration stuff as a pamphlet file (see below).

I think, Bill's suggestion is the right one. We have a pure ./configure
file that is distributed with the Axiom sources and a configure.ac.pamphlet.

We have two ways to compile Axiom:

1) For ordinary users who want to download and compile and run axiom

>      ./configure
>       make
>       make install
         axiom

should be enough.

2) For developers who want to compile Axiom change it and test their 
stuff. (Same commands as above.)

3) For developers who want to work on the build process and need to 
change configure.ac.pamphlet. Here

	./configure
	make configure
	autoconf configure.ac > configure
	./configure
	make
	make install

should do the compilation. The first configure (that comes with Axiom) 
checks for noweb and generates a simple Makefile that enables a
"make configure". "make configure" could then call notangle to generate 
configure.ac (It could even include "autoconf configure.ac > 
configure".) Would that be a bad bootstrapping?

Gaby, it is only you who must run

notangle configure.ac.pamphlet > configure.ac
autoconf configure.ac > configure

ONCE and then we see a "configure" file in the distribution of Axiom.

\start
Date: Wed, 2 Aug 2006 06:43:38 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Be Bold

Ralf,

I have made some of the improvements in 'backlinks' that
you suggested below.

On Wednesday, August 02, 2006 5:00 AM you wrote:
> ...
> Writing "additional parent" would be more obvious to me.

Now the text field is 'Add new parent' and the button is
'Add/remove parents'. Is that better?

>
> Why cannot I add more children? Why not having something like
> ...
> Children of this page, i.e this pages has the following subtopics:
>
> 1. Habl
> 2. Oof
> 3. Bar
> Add new child: ________ [Browse Index]
>

Children are defined as the inverse of the Parent relation.
Each page has an (internal) list of it's parents and children
(subtopics) are added only implicitly. Adding new children
to a page could be done but it would involve some new Python
coding.

> ------------------------------------------------------------
>
> And maybe at the bottom of the page you write that the whole
> structure of the wiki forms a lattice.
>

Done.

\start
Date: 02 Aug 2006 12:45:13 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [build-improvements] Requests for discussion

Ralf Hemmecke writes:

| Hi Gaby,
| 
| your working times are remarkable. Aren't you in Texas? ;-)

Yes.  One nice thing about having a baby who is growing a tooth is
that you for sure will be awaken some nights :-)

| I have seen that there are now also ChangeLog files under
| axiom/src/doc and axiom/src/boot. Is it common to have *not* just one
| top-level ChangeLog? Now I am getting confused of where I should enter
| my changelog stuff.

I believe both ways of doing things are common; I have a slight
preference for a ChangeLog file in each directory -- having practiced
both ways.  That way I don't have long file names eating up all space
just to give me little clues.

For the Silver branch, you will find a ChangeLog file in each
directory (almost).  Juts put your descriptions there.

For the branches, it is actually more practical to have a different
ChangeLog files -- the convention I use is ChangeLog.<branch-name>.
There are several paratical reasons for that:
  (1) avoid spurious conflicts when merging;
  (2) a glance at the file gives an overview of changes made on
      the branch.


Ah; I've just finished the "./configure && make && make install" stuff.
I'll commit after testing.

\start
Date: Wed, 2 Aug 2006 06:51:16 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: Be Bold
Cc: Kai Kaminski

Ralf,

On Wednesday, August 02, 2006 6:12 AM you wrote:

> On 08/02/2006 11:42 AM, Kai Oliver Kaminski wrote:
> >> Bill Page wrote:
> >>> It is also possible to use emacs as an external page editor.
> >>> Perhaps some people would find this more convenient.
> >>
> >> How??? Please let us know.
> > There are several wiki modes for Emacs (see
> > http://www.emacswiki.org/cgi-bin/wiki/WikiModeDiscussion).
> > I tried one of them several month ago, but it didn't quite
> > work then. Maybe the necessary server support isn't enabled yet.
> >
>
> You know, your link costs me several hours just to find out
> what to do.
>

This is not the use of emacs that I referred to in my previous
email (although these wiki modes do seem interesting in their own
right). The concept of an External Editor is a ZWiki/Zope idea.
You can read about it here:

http://wiki.axiom-developer.org/ExternalEdit

Marten Rubey used to use this mode of editing wiki pages extensively.
Perhaps he can give a more "user-oriented" description of how this
works.

\start
Date: Wed, 2 Aug 2006 06:54:29 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: Be Bold
Cc: Kai Kaminski

On Wednesday, August 02, 2006 6:51 AM I wrote:
> ...
> The concept of an External Editor is a ZWiki/Zope idea.
> You can read about it here:
>
> http://wiki.axiom-developer.org/ExternalEdit
>
> Marten Rubey used to use this mode of editing wiki pages extensively.
> Perhaps he can give a more "user-oriented" description of how this
> works.
> 

I forgot to mention that the icon that starts an external edit
session is the little "pencil" in the top right hand side of the
screen on the extreme right side of the menu line on Axiom Wiki.
But you must first configure your system as described at the
above link.

\start
Date: Wed, 2 Aug 2006 07:03:22 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Front page esthetic

Ralf,

On Wednesday, August 02, 2006 3:36 AM you wrote:
>
> >> (Could one have a table of contents at the top of that page?)
>
> > What did you have in mind? Table of Contents for the contents
> > of the page or something more inclusive?
>
> I have used <h1> and <h2> to structure the page. Since I
> consider that page like a (very short) paper, I would like
> to see the headlines appear either at the top of the page
> or on the left hand side (without typing more myself).

This is possible using a page type of reStructuredText. See

http://zwiki.org/RestructuredText

Axiom Wiki supports this page type but not yet with embedded Axiom
commands. To set the page type select the type in the top right
side of the edit or create new form.

I am not sure of you will be happy to learn yet another "language"
for writing web pages, however there are some people who strongly
prefer reStructuredText over StructuredText because it is apparently
both more powerful and more regular.

I tried converting your original StructuredText page to
reStructuredText here:

http://wiki.axiom-developer.org/SandBoxAxiomSourcesReST

I am still having some trouble with the @ character. I will look\
into this problem later today.

\start
Date: 02 Aug 2006 13:17:27 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [build-improvements] Requests for discussion

Ralf Hemmecke writes:

| >    Based on the feedback I got, I implemented the Autoconf-based
| > configuration stuff as a pamphlet file (see below).
| 
| I think, Bill's suggestion is the right one. We have a pure ./configure
| file that is distributed with the Axiom sources and a configure.ac.pamphlet.

from the outset, the project aimed at shipping ./configure.  However,
that file must be generated from somewhere.  For Autoconf, that must
be something like configure.ac.
The debate was whether configure.ac is sufficient by itself as
literate or whether it must come from a pamphlet file.
My opinion is that it is sufficient.  Others disagree.  So, I
implemented the solution others suggested -- even though I disagree
with it.

| We have two ways to compile Axiom:
| 
| 1) For ordinary users who want to download and compile and run axiom
| 
| >      ./configure
| >       make
| >       make install
|          axiom
| 
| should be enough.
| 
| 2) For developers who want to compile Axiom change it and test their
| stuff. (Same commands as above.)
| 
| 3) For developers who want to work on the build process and need to
| change configure.ac.pamphlet. Here
| 
| 	./configure
| 	make configure

That is too circular and too complicated. It is a good recipe for subtle
bugs.  We don't want to be too clever at that level.

| 	autoconf configure.ac > configure
| 	./configure
| 	make
| 	make install

Currently, here is the sequence I propose -- and I'm using right now

    (1) modify configure.ac.pamphlet
    (2) run ./build-setup.sh            -- you don't need to know what
                                        -- it does, except it does the
                                        -- right thing for you
    (3) ./configure && make && make install

| 
| should do the compilation. The first configure (that comes with Axiom)
| checks for noweb and generates a simple Makefile that enables a
| "make configure". "make configure" could then call notangle to
| generate configure.ac (It could even include "autoconf configure.ac >
| configure".) Would that be a bad bootstrapping?
| 
| Gaby, it is only you who must run
| 
| notangle configure.ac.pamphlet > configure.ac
| autoconf configure.ac > configure

I do expect other developers making changes to
configure.ac.pamphlet (and later to any Makefile.am.pamphlet) to run
equivalent commands.  Fortunately, that is all taken care of by
build-setup.sh.  :-)

build-setup.sh is not an end-user stuff.  It is only for maintainers
of the build machinery.

End users just follow the scenario at 1)

Mainitainers are required to have noweb installed -- so I proceeded to
install noweb myself.


Bill suggested we don't keep configure.ac.  I fear we must kepp it --
for the purpose of preventing the build machinery maintainers from
introducing subtle bugs.  Components of Autotools have dependency on
such files in several circumstances.

\start
Date: Wed, 2 Aug 2006 13:47:24 +0200
From: Antoine Hersen
To: Bill Page
Subject: Re: spam attack

Thank you very much for fighting spam for us.

I like to point how important it is not only because it is annoying but also
because it will make the axiom web page a so called "farm link" meaning
loosing rating or not even showing up in Google and co.


On 8/2/06, Page, Bill Bill Page wrote:
>
> Axiom Developers,
>
> I am sorry but while I slept I see that the link spammers
> finally managed to break through. :( I guess my attempts
> over the last few days must have really irritated them...
>
> To stop this attack I had to temporarily disable sendmail
> from axiom-developer.org. Delete the mail queue. Then I
> modified the spam filter to disallow all comments and edits
> containing external links. And restarted sendmail. Now
> things are back to normal, I think.
>
> Disabling external links means that http:// is no longer allowed
> in any comment. Links that are internal to the Axiom Wiki are
> still ok and can be written in the form:
>
>   "link name":/xxx/yyy
>
> or as standard wiki names.
>
> I hope that is enough to hold them off for now.
>
> If it continues we could at least disable the notices from
> the Axiom Wiki and this would prevent the email part of the
> spam (but not the pollution of the web site). Or we may be
> forced (as a last resort) to only permit comments and edits
> by registered users which would of course defeat the main
> purpose of the wiki.
>
> Who ever did this seems to know what they are doing since it
> appears as if they have successfully spoofed a large number
> of different ip addresses in a kind of "deny of service"
> attack.
>
> Here is a list of the ip addresses used by whoever caused
> the most recent spam attack on Axiom Wiki.
>
> 125.131.171.215
> 125.7.33.74
> 193.170.68.244
> 200.17.89.80
> 200.242.249.70
> 200.3.183.52
> 200.35.89.157
> 200.71.62.6
> 201.147.158.52
> 201.155.170.232
> 201.52.4.158
> 202.110.217.130
> 202.68.151.116
> 203.128.5.37
> 203.158.215.2
> 210.111.191.107
> 210.87.251.41
> 211.113.242.88
> 211.162.0.131
> 211.168.194.31
> 211.173.149.116
> 211.177.83.80
> 211.186.170.244
> 211.195.242.221
> 211.199.92.168
> 211.210.36.234
> 211.213.114.26
> 211.216.169.71
> 211.219.155.41
> 211.221.207.78
> 211.247.92.76
> 211.48.66.198
> 211.62.70.97
> 212.138.113.12
> 212.138.113.16
> 212.9.224.211
> 213.140.56.3
> 213.249.155.231
> 216.207.123.200
> 217.113.234.7
> 217.56.108.227
> 218.11.207.244
> 218.113.240.98
> 218.128.16.116
> 218.152.81.59
> 218.16.121.26
> 219.136.249.79
> 219.240.91.191
> 220.121.133.210
> 220.121.153.109
> 220.126.1.182
> 220.82.189.124
> 220.85.41.91
> 220.89.68.166
> 220.95.73.118
> 221.13.66.161
> 221.142.178.181
> 221.147.115.15
> 221.153.14.37
> 222.104.77.104
> 222.105.70.230
> 222.108.109.21
> 222.238.39.79
> 58.235.225.18
> 58.74.245.219
> 58.76.178.142
> 59.150.212.199
> 59.15.50.100
> 59.4.4.84
> 61.103.229.60
> 61.109.90.189
> 61.18.195.245
> 61.185.219.235
> 61.248.150.105
> 61.35.129.226
> 61.35.225.92
> 61.35.66.84
> 61.41.231.149
> 61.52.97.61
> 61.74.139.240
> 72.2.18.19
> 80.50.243.250
> 80.50.82.90
>
> -------
>
> I don't see any immediate pattern in this list, so for now
> I must assume that these are bogus ip addresses. If they
> were real, we would have grounds to contact the people and
> companies to which these addresses are assigned.
>
> If anyone sees a pattern to this list of ip addresses
> please let me know.
>
> I apologize for the email pain.

\start
Date: Wed, 2 Aug 2006 08:06:51 -0400
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: [build-improvements] Requests for discussion

On Tuesday 01 August 2006 11:02 pm, you wrote:

> Actually, we can if we don't insist that literate files must be
> pamphlet files or we must use noweb :-)

OK, point...

> |  As long as configure.ac.pamphlet is written and maintained in
> | the .pamphlet file I don't see a problem with special casing the
> | continual presence of configure.ac  - it's pretty much inevitable.
>
> OK.  I'll write up a development enrivonment minimal requirements and
> include noweb (I still dislike that specific requirement).

We have discussed alternatives to noweb before, including writing our own Lisp 
version of noweb.  I expect eventually we will be able to move off of noweb, 
but right now it's easier to use what works.

> | unless (as you already attempted) the higher level files are
> | also legal lower level files.  I don't think we want to redefine the
> | literate strategy we use to that degree - it's not worth it.
>
> I'm really annoyed by the dependency on noweb to bootstrap the
> process.  I would rather, by a large degree, vanilla traditional
> tools, e.g. plain 'sed'.  However, I will proceed as outlined above, and
> will at the same time respectfully register my strong disagreement.

Oh, no question I agree that depending specifically on noweb is unfortunate.  

> | In a way, it's the same problem Tim faced with Axiom being needed to
> | build Axiom.  The only way out was (and still is) to have some files in
> | lisp present, to teach lisp to read and understand BOOT and SPAD.  Same
> | deal here.
>
> That is a good recipe for maintenance nightmarre -- recent debates about
> redundant boot anyone?  There ought to be a better way to deal with it.

I think the way out is clear - put all of the low level logic in Lisp, and the 
high level logic in Aldor (or SPAD, until Aldor is available).  Tim has begun 
that process with bookvol5 - once all of interp is in human readable lisp, 
both the boot files in interp and the boot directory itself should become 
unnecessary.  It should also enable a lot of other interesting activities 
with existing Lisp tools, but that's a side benefit.

> | It's a universal problem - if we wanted to bootstrap a machine from a
> | cold, memoryless, powerless state we would need some binary to feed it
> | before it could start speaking assembly. True bootstrapping is a very
> | rare event ;-).
>
> I've been hacking real life compilers for over decade now :-)

Sorry, didn't mean to lecture the experts ;-).  I just find it a really 
interesting problem - the answer to "how do we go from cold, dumb, inert 
lumps of metal and silicon to a running computer"  is a lot less trivial than 
one might think - the technological Dr. Frankenstein, so to speak ;-)

> | 1 and 3 are solved by always having a current notangle of configure.ac
> | present in the tree at all times.  As for two, I think we should assume a
> | working notangle is available.  We have to assume SOMETHING is working,
>
> No question we have to assume something is workin -- just assume,
> everybody knows that.
>
> The issue is whether it must be noweb.  I think "no".  But, I do
> understand your view.

I doubt it has to be noweb - my preference would be for a lisp based tool, but 
I can see arguments for bash, sed, perl, and other such tools.  (Particularly 
since a lisp distribution is a poor assumption to make on most computers in 
the world today :-( .)  Really, we should have a "rosetta" set of tools to 
translate pamphlets to buildable files (e.g. the notangle step)  in as wide a 
variety of tools as possible, since that step is so critical and needs 
something working to bootstrap it.  I expect getting the source code of of a 
pamphlet is probably simpler as a dedicated operation than all of noweb 
(particularly with a universal, standard nomenclature denoting source code) - 
maybe a collection of such scripts could replace the current content of the 
boot directory once we don't need boot ;-).  ('course, I should try writing 
one before I conclude it's doable...)  Then we could reduce the "something 
working" requirement from noweb to "one of noweb, Lisp, perl, sed, bash, csh, 
etc. etc. etc."

In a sense, one might also say that depending on LaTeX is a bit unfortunate to 
produce human readable documentation, because a TeX installation is not 
especially trivial (nor is it common on Windows).  However, the highly 
nontrivial nature of LaTeX and TeX makes that a much more difficult problem, 
and I don't think we have a choice but to assume a working TeX installation 
for the time being.  cl-typesetting might eventually evolve into a viable 
alternative we could build and run off of the same technology used to build 
and run Axiom itself, but it's nowhere near ready yet.  And we can't afford 
the space bundling something like teTeX and MiKTeX (or even a subset of them) 
would take.

Anyway.  Interesting to think about, and maybe even practical, but that's for 
later.  Right now, THANK YOU Gabriel for making a configure/make/make install 
routine for Axiom!!!

\start
Date: Wed, 02 Aug 2006 14:13:56 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Front page esthetic

> http://wiki.axiom-developer.org/SandBoxAxiomSourcesReST

That doesn't look too bad to my eyes, but it seems that reStructuredText 
is not able to handle identically named subsections.

System Message: INFO/1 (<string>, line 73); backlink
Duplicate implicit target name: "gnu arch".

And again a problem. I pressed the edit button to see what you have 
done, then I pressed "Preview" and I was asked to give a reason. 
Annoying, but if it must be to prevent spam I could live with it. But 
after I entered a reason, the password window popped up.... I quit. :-(
I just wanted a preview and the sources of the page on the same page.

\start
Date: Wed, 2 Aug 2006 14:12:43 +0200
From: Antoine Hersen
To: Ralf Hemmecke
Subject: Re: Front page esthetic

------=_Part_49517_617477.1154520763024

> > | About
> > | News
> > | Documentation
> > | FAQ
> > | Screenshots/Video
> > | -----------
> > | Online try
> > | Download
> > | ---------
> > | Developer
> > | Mail list
> > | Bug report
> > | Bibliography
> > | Related link
> >
> > I like it.
>
> Looks not too bad to me, but Bill made sections with headlines. So you
> are trying to remove the headlines. OK I can live with that.


Yes, just keep color to separate the different sections.

I like the first section above, but Screenshots/video is a bit too long
> as a name. Also "Online try"? Why in the next section? What has that to
> do with Download?


Those are two way to use Axiom. And by putting it above download we make
sure that people are aware of that option.

Screenshot/video/online try all belong into one category I think. That
> is for getting a feeling of what axiom can do. From the About page there
> should certainly be a link to these pages. So I would rather suggest


Yes  just "Screenshot" will be better, as people do not epected video and
even are not looking for one.
And when people click on it the video should be at the top because it the
contexte "visual representation" it is relevant.

...
> FAQ
> ------------
> Screenshots
> Video
> Online Try
> -----------
> Download
> -----------
>
> I don't know what you mean with Developer. Should that link to
> http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers/withNavigator


Developer where you will click if you are a developer or want to be one.
Here we find all the informations about our various SCM the distinction
between gold siliver. The developement road map, the forks projects, the
coding sugestion/bounty.
Arguments about design issue and so on.

I don't think that Bibliography is the best word. Would you immediately
> think that you can find actual downloadable papers behind it? Is there
> some native speaker who can come up with something better?


What about a "Research" instead.
People will expected to find publications and so on there.

| About
| News
| FAQ
| Screenshots
| -----------
| Online try
| Download
| -----------
| Documentation
| Reseach
| Developer
| ----------
| Mail list
| Bug report
| Related link

One thing is missing contribution/packages where packages not integrated to
Axiom will be.
I will put it bellow Download

\start
Date: Wed, 2 Aug 2006 14:18:43 +0200
From: Kai Kaminski
To: Ralf Hemmecke
Subject: Using Emacs to edit the Wiki

It isn't difficult at all.

Go to http://www.zope.org/Members/Caseman/ExternalEditor.

Mac Users: Download the ZopeEditManager, put it into your Application 
Folder, start it, change the Preferences to reflect your choice of 
editor and set ZopeEditManager as the MIME handler for 
application/x-zope-edit in your browser.


Unix Users:

     Download zopeedit-src.tgz and extract it. Enter the zopeedit
     directory and run (You may need to be root)::

       python2.2 setup.py install

     This will install the zopeedit.py executable (in /usr/local/bin on 
my
     system). Alternately, you can just copy zopeedit.py to the location 
of
     your choosing.

     Once you have the helper application installed, you need to 
configure your
     browser to fire it off appropriately. To do so, create an entry in 
the
     helper applications list for your browser(s) that associates the 
mime type
     "application/x-zope-edit" with the helper application.

	Step by step instructions for Mozilla and Konqueror are in the README.


   Tips

     The helper application can run any editor program that does not 
detach
     itself from the controlling process.

     To get terminal based editors to work, you need to spawn them 
inside an
     xterm. to do this, use something like the following for the editor 
option::

       editor = xterm -e vi

     You can of course modify the above to fire up your favorite 
terminal and
     editor or add any command line arguments you want.

     As for editors that insist on detaching from the controlling 
process (gvim
     does this by default), you need to configure them so that they do 
not
     detach. For gvim you could use::

       editor = gvim -f


DO NOT FORGET TO WRITE SOMETHING IN THE 'Log: '-LINE, OTHERWISE THE 
CHANGES WON'T BE ACCEPTED.

\start
Date: Wed, 02 Aug 2006 15:03:30 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [build-improvements] Requests for discussion

Hi Gaby,

> | 3) For developers who want to work on the build process and need to
> | change configure.ac.pamphlet. Here
> | 
> | 	./configure
> | 	make configure
> 
> That is too circular and too complicated. It is a good recipe for subtle
> bugs.  We don't want to be too clever at that level.
> 
> | 	autoconf configure.ac > configure
> | 	./configure
> | 	make
> | 	make install
> 
> Currently, here is the sequence I propose -- and I'm using right now
> 
>     (1) modify configure.ac.pamphlet
>     (2) run ./build-setup.sh            -- you don't need to know what
>                                         -- it does, except it does the
>                                         -- right thing for you
>     (3) ./configure && make && make install

First of all let me say that I have no idea how all this 
autoconf/automake works... So I expect to learn something through this 
thread.

I don't see a difference between

 >     (1) modify configure.ac.pamphlet
 >     (2) run ./build-setup.sh

and my suggested

	modify configure.ac.pamphlet
	make configure

In my previous mail I suggested "./configure && make configure" but that 
was only to make sure that "noweb" is found by "configure" if you have 
it installed somewhere, then of course you don't need to run 'configure'.

Now whether you call "build-setup.sh" or "make configure" isn't much of 
a difference. Is it? It is responsible for creating configure.ac from 
configure.ac.pamphlet.

I know that "make" checks whether the "Makefile" is as new as it could 
be. But does it check whether there is Makefile.in or Makefile.am and 
re-generates the Makefile from that???

And why do you insist on having all Makefiles generated during 
"configure"? For me it is perfectly fine if the Makefiles are 
regenerated from their .pamphlets during the build of Axiom. It is only 
that the Makefiles should more rely on variables that define programs 
like using ${TAR} instead of just tar.

Or is the whole thing more complicated than I think?

> | Gaby, it is only you who must run
> | 
> | notangle configure.ac.pamphlet > configure.ac
> | autoconf configure.ac > configure
> 
> I do expect other developers making changes to
> configure.ac.pamphlet (and later to any Makefile.am.pamphlet) to run
> equivalent commands.  Fortunately, that is all taken care of by
> build-setup.sh.  :-)

So each time I modify a file which is called configure.ac.pamphlet or 
Makefile.am.pamphlet, I should run "build-setup.sh". What if I forget 
that? There should be at least a warning telling me that I should run 
"build-setup.sh".

> build-setup.sh is not an end-user stuff.  It is only for maintainers
> of the build machinery.

That's clear.

> Bill suggested we don't keep configure.ac.  I fear we must kepp it --
> for the purpose of preventing the build machinery maintainers from
> introducing subtle bugs.  Components of Autotools have dependency on
> such files in several circumstances.

Can you make up an example so that we see what problems can occur and 
appreciate why we should keep configure.ac. Then that should be 
documented (in a pamphlet file) describing the build process.
Currently, I also don't feel need for configure.ac, given that 
maintainers have noweb and configure.ac.pamphlet.

\start
Date: Wed, 02 Aug 2006 15:15:30 +0200
From: Ralf Hemmecke
To: Antoine Hersen
Subject: Re: Front page esthetic

>     I don't know what you mean with Developer. Should that link to
>     http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers/withNavigator
> 
> Developer where you will click if you are a developer or want to be one.
> Here we find all the informations about our various SCM the distinction 
> between gold siliver. The developement road map, the forks projects, the 
> coding sugestion/bounty.
> Arguments about design issue and so on.

Who feels responsible for writing that page? It's a must for us...

And what I like even more ... "AxiomRoadMap", long term and short term 
goals. Currently everyone does something, but it's not at all clear to 
others what we are actually doing.

Maybe the page http://wiki.axiom-developer.org/TodoList could be reused?

\start
Date: Wed, 02 Aug 2006 16:18:01 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Be Bold

On 08/02/2006 12:43 PM, Page, Bill wrote:
> Ralf, 
> 
> I have made some of the improvements in 'backlinks' that
> you suggested below.

Thank you Bill.

> On Wednesday, August 02, 2006 5:00 AM you wrote:
>> ...
>> Writing "additional parent" would be more obvious to me.
> 
> Now the text field is 'Add new parent' and the button is
> 'Add/remove parents'. Is that better?

Yes, but where is the "Browse" botton? Otherwise I must figure out the 
names through a second window that contains "SiteMap". Cannot I have 
"SiteMap" in a frame on the right hand side of a backlinks page? Then I 
could use cut&paste to add a parent.

One remark still. You wrote

Add new parent: ______ [Add/remove parents]

That is confusing. And in the text below you still refer to the 
"Reparent" button. Just remove the first "Add new parent".

>> Why cannot I add more children? Why not having something like
>> ...
>> Children of this page, i.e this pages has the following subtopics:
>>
>> 1. Habl
>> 2. Oof
>> 3. Bar
>> Add new child: ________ [Browse Index]

> Children are defined as the inverse of the Parent relation.
> Each page has an (internal) list of it's parents and children
> (subtopics) are added only implicitly. Adding new children
> to a page could be done but it would involve some new Python
> coding.

OK, would be a "nice to have" feature, but don't invest time on it now.

But why would I like to order the subtopics? I cannot map that to the 
"lattice" notion.

\start
Date: 02 Aug 2006 16:58:44 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [build-improvements] Requests for discussion

Ralf Hemmecke writes:

[...]

| I don't see a difference between
| 
|  >     (1) modify configure.ac.pamphlet
|  >     (2) run ./build-setup.sh
| 
| and my suggested
| 
| 	modify configure.ac.pamphlet
| 	make configure

"make" means that there is a Makefile that is used to make "configure".
There isn't.  Any makefile must be generated at configure time when
building Axiom.  I know that is not what the current system does;
but it is a bug -- it got me several times.

| In my previous mail I suggested "./configure && make configure" but
| that was only to make sure that "noweb" is found by "configure" if you
| have it installed somewhere, then of course you don't need to run
| 'configure'.
| 
| Now whether you call "build-setup.sh" or "make configure" isn't much
| of a difference. Is it? 

from my perspective; there is.  See above.

[...]

| I know that "make" checks whether the "Makefile" is as new as it could
| be. But does it check whether there is Makefile.in or Makefile.am and
| re-generates the Makefile from that???

No.  Makefile.in usually contains variables that need to be
substituted.  Makefile.am is even at higher level.  You need
Automake.  Now, when you have the full Autotools in place, if you
modify Makefile.am or configure.ac and you say "make", there usually
is a dectection and autoconf is run to regenerate

| And why do you insist on having all Makefiles generated during
| "configure"? 

Because they contain platform-specific information and the standard way to
reduce duplication and make the whole system manageable is to abstract
over the variabilities.  Otherwise, we have the current mess. 
This isn't an innovation.  Look at any other system that uses Autoconf
+ Automake (Maxima is one that additionally has a Lisp-based configure).

| For me it is perfectly fine if the Makefiles are
| regenerated from their .pamphlets during the build of Axiom. It is
| only that the Makefiles should more rely on variables that define
| programs like using ${TAR} instead of just tar.
| 
| Or is the whole thing more complicated than I think?

In part yes.

The only benefit I see of not storing configure.ac is more
complications and more potential for bugs.  I don't see the benefits.

| > | Gaby, it is only you who must run
| > | | notangle configure.ac.pamphlet > configure.ac
| > | autoconf configure.ac > configure
| > I do expect other developers making changes to
| > configure.ac.pamphlet (and later to any Makefile.am.pamphlet) to run
| > equivalent commands.  Fortunately, that is all taken care of by
| > build-setup.sh.  :-)
| 
| So each time I modify a file which is called configure.ac.pamphlet or
| Makefile.am.pamphlet, I should run "build-setup.sh".

Yes.

| What if I forget that? 

I'll catch you.  Your "make configure" suffers from the same problem.

When we move to Automake, the system will assist me.

| There should be at least a warning telling me that I should run
| "build-setup.sh".

Probably; that is low-priority right now.

| 
| > build-setup.sh is not an end-user stuff.  It is only for maintainers
| > of the build machinery.
| 
| That's clear.
| 
| > Bill suggested we don't keep configure.ac.  I fear we must kepp it --
| > for the purpose of preventing the build machinery maintainers from
| > introducing subtle bugs.  Components of Autotools have dependency on
| > such files in several circumstances.
| 
| Can you make up an example so that we see what problems can occur and
| appreciate why we should keep configure.ac.

No, I don't have time for that -- I'm sorry.  You have to take my word
for it for the moment.  When I get more time, I can play with testcases.

| Then that should be
| documented (in a pamphlet file) describing the build process.

Yes.  That is not an issue.

| Currently, I also don't feel need for configure.ac, given that
| maintainers have noweb and configure.ac.pamphlet.

Then just forget about it and run build-setup.sh.

\start
Date: 02 Aug 2006 17:05:55 +0200
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: [build-improvements] Requests for discussion

Cliff Yapp writes:


[...]

| > | In a way, it's the same problem Tim faced with Axiom being needed to
| > | build Axiom.  The only way out was (and still is) to have some files in
| > | lisp present, to teach lisp to read and understand BOOT and SPAD.  Same
| > | deal here.
| >
| > That is a good recipe for maintenance nightmarre -- recent debates about
| > redundant boot anyone?  There ought to be a better way to deal with it.
| 
| I think the way out is clear - put all of the low level logic in Lisp, and the 
| high level logic in Aldor (or SPAD, until Aldor is available).

Unfortunately, I don't have an infinite amount of time to wait.  The
time I'm investing now, I'm expecting it to pay off when I tell
students "go and fetch Axiom" and "follow standard installation", or
when I eventually succeed in convincing some linux distros to have
Axiom in their baskets too.

[...]

| Anyway.  Interesting to think about, and maybe even practical, but
| that's for later.

Yes.

| Right now, THANK YOU Gabriel for making a configure/make/make install 
| routine for Axiom!!!

\start
Date: Wed, 2 Aug 2006 13:29:50 -0400
From: Bill Page
To: Antoine Hersen
Subject: RE: spam attack

On Wednesday, August 02, 2006 7:47 AM Antoine Hersen wrote:

> Thank you very much for fighting spam for us.

Thanks for the encouragement to continue the fight against
these web site abusers.

> I like to point how important it is not only because it is
> annoying but also because it will make the axiom web page a
> so called "farm link" meaning loosing rating or not even showing
> up in Google and co.

Yes you are right, this could happen if we let too much spam
accumulate.

The spam attach is still continuing at the rate of more than 60
attempts per minute. Uncaught spam arriving at this rate could
easily overwhelm our server and cause it to fail.

My first attempt at a remedy for this problem was to configure
the wiki to require user preferences to be set before permitting
comments and then left the ban on http external links. This works
but unfortunately the spam robots are smarter than I thought and
actually do set the cookies necessary to indicate valid preferences.
So when I tried it a few hours ago, we got another burst of spam
that got through and ultimately (partly my fault) it resulted in
having to reboot the axiom-developer.org server.

My second attempt to control this threat is to continue the ban
on http external links for unauthenticated (i.e. non Zope) users.
This is the way the ban was originally supposed to work - users
who have a specially assigned user id - over and above that set
in their preferences - are allowed to ignore the ban. If they
are editing a page or adding a comment that contains banned
content, then they will be prompted to enter their user id and
password. If it is valid, the edit will be allowed to continue.
If not, then they (and all those damned robots!) will receive
a 401 Unauthorized return code.

This seems to be working now. Would those of you who have the
Zope user accounts, i.e. Ralf, Marten, and Bob McElrath, please
try this and confirm that it is working the way it is supposed
to.

It might be possible to lift the ban on external links at some
point in the future if these spam attacks stop, but in the
mean time, if you are an Axiom developer or Axiom user and you
want to be able to freely edit and post comments to the Axiom
Wiki, please contact me by email and I will provide you with a
Zope user id. If you would like just to make one or two simple
pages and you get caught by this ban, maybe the best approach
would be for you to send your changes to one someone who already
has a Zope user id.

\start
Date: Wed, 2 Aug 2006 11:00:07 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: spam attack

Page, Bill [Bill Page] wrote:
> > I like to point how important it is not only because it is
> > annoying but also because it will make the axiom web page a
> > so called "farm link" meaning loosing rating or not even showing
> > up in Google and co. 
> 
> Yes you are right, this could happen if we let too much spam
> accumulate.	
> 
> The spam attach is still continuing at the rate of more than 60
> attempts per minute. Uncaught spam arriving at this rate could
> easily overwhelm our server and cause it to fail.

Since wiki spam must occur over a HTTP connection, it is 2-way.  So, you
have the verified IP's of the attackers.  Someone is clearly using a
zombie net.  Consider spawning:
     iptables -A INPUT -s "$IP" -j DROP
when someone posts something in the banned_links.  Then, one would want
to remove the ban on reguar links or you would hit legitimate users.
I'm assuming banned_links would contain only the bad URL's/domain names.
So in each case you would get at least one spam.  

I don't think it's possible or practical to try to ban spam *before*
seeing spam from a given source.  They can always find a way around any
system you set up.

> My second attempt to control this threat is to continue the ban
> on http external links for unauthenticated (i.e. non Zope) users.
> This is the way the ban was originally supposed to work - users
> who have a specially assigned user id - over and above that set
> in their preferences - are allowed to ignore the ban. If they
> are editing a page or adding a comment that contains banned
> content, then they will be prompted to enter their user id and
> password. If it is valid, the edit will be allowed to continue.
> If not, then they (and all those damned robots!) will receive
> a 401 Unauthorized return code.
> 
> This seems to be working now. Would those of you who have the
> Zope user accounts, i.e. Ralf, Marten, and Bob McElrath, please
> try this and confirm that it is working the way it is supposed
> to.

That's an interesting idea...can the post be held for moderation too, in
case someone makes an interesting edit but doesn't have a zope userid?

> It might be possible to lift the ban on external links at some
> point in the future if these spam attacks stop, but in the
> mean time, if you are an Axiom developer or Axiom user and you
> want to be able to freely edit and post comments to the Axiom
> Wiki, please contact me by email and I will provide you with a
> Zope user id. If you would like just to make one or two simple
> pages and you get caught by this ban, maybe the best approach
> would be for you to send your changes to one someone who already
> has a Zope user id.

This is one of the major drawbacks to ZWiki -- there is no way for the
user to create and manage his account.  Plone, for instance, allows the
user to create an account and login with a password.  User rights can be
managed from there.  (if anyone wants to consider dumping the zwiki
portal in favor of putting everything in plone...)  There are lots of
zope user management products:
    http://www.zope.org/Products/user_management
but it would require some coding to get it to interface with zwiki.

\start
Date: Wed, 2 Aug 2006 14:38:12 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: spam attack

Hi Bob,

On Wednesday, August 02, 2006 2:00 PM you wrote:
> ...
> Since wiki spam must occur over a HTTP connection, it is
> 2-way.  So, you have the verified IP's of the attackers.
> Someone is clearly using a zombie net.  Consider spawning:
>      iptables -A INPUT -s "$IP" -j DROP
> when someone posts something in the banned_links.

Are you suggesting that I drop all connections from the
complete list of ip addresses that are being used by the
spammers? So far there are about 200 of these addresses
scattered over several different subnets so I am not sure
that this is practical. And as far as I can tell the number
of ip addresses they are using is growing. I could also
do something similar using our Apache hosts.deny file but
I am quite concerned that these are spoofed ip addresses
and do not really uniquely identify the spammers. Blocking
all of these addresses might well affect ligitimit users.

> Then, one would want to remove the ban on reguar links
> or you would hit legitimate users. I'm assuming banned_links
> would contain only the bad URL's/domain names. So in each
> case you would get at least one spam. 

No, this does seem practical either because there are
literally hundreds of these domain names. What I did
instead was to ban all use of the http: prefix thus
eliminating the possibility of directly specifying an
external link in any form. (ZWikiRemote links are still
possible for predefined urls.)

>
> I don't think it's possible or practical to try to ban
> spam *before* seeing spam from a given source.  They can
> always find a way around any system you set up.

Yes. If they got real mean, they could even start posting
random stuff with no embedded links just to bypass the ban
and overrun or server... but I am counting on them going to
all this trouble for a real purpose (i.e. link jamming) and
not just to annoy us - at least not for long.

>
> > My second attempt to control this threat is to continue the
> > ban on http external links for unauthenticated (i.e. non
> > Zope) users. This is the way the ban was originally supposed
> > to work - users who have a specially assigned user id - over
> > and above that set in their preferences - are allowed to
> > ignore the ban. If they are editing a page or adding a comment
> > that contains banned content, then they will be prompted to
> > enter their user id and password. If it is valid, the edit
> > will be allowed to continue. If not, then they (and all those
> > damned robots!) will receive a 401 Unauthorized return code.
> >
> > This seems to be working now. Would those of you who have the
> > Zope user accounts, i.e. Ralf, Marten, and Bob McElrath, please
> > try this and confirm that it is working the way it is supposed
> > to.
>
> That's an interesting idea...can the post be held for moderation
> too, in case someone makes an interesting edit but doesn't have
> a zope userid?

Hmmm, you mean maybe write it to a non-web accessible or otherwise
protected log file somewhere? Maybe even to a set of "shadow" pages
that are only readable by registered Zope users? Moderation is a
neat idea but it would take some programming work to implement.

> ...
> This is one of the major drawbacks to ZWiki -- there is no way
> for the user to create and manage his account.  Plone, for
> instance, allows the user to create an account and login with
> a password. User rights can be managed from there.  (if anyone
> wants to consider dumping the zwiki portal in favor of putting
> everything in plone...)

I agree that Plone has a smooth and reliable user management
system. It is certainly possible to move the Axiom Wiki over to
Plone and can even be done in a fairly nice and transparent way
by using switchable skins so that you can chose between seeing
the pages in conventional ZWiki style or as embeded in a Plone
portal wrapper. Simon set up something like that for the Ubuntu
wiki at one time, I think. I don't know if they are still using
it or not. Is anyone interested in experimenting with this on the
test.axiom-developer.org server? I did an initial setup like this
6 months ago and it seems to work. I recall that I had a few
issues trying to get authentication to work properly with the skin
switching. But I did not go as far as actually moving the content
of the wiki over a wiki hosted inside my test version of Plone.

> There are lots of zope user management products:
>     http://www.zope.org/Products/user_management
> but it would require some coding to get it to interface with
> zwiki.
>

I might look at these if it turns out we need a non-Plone longer
term solution.

\start
Date: Wed, 2 Aug 2006 11:42:11 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: spam attack

Page, Bill [Bill Page] wrote:
> Hi Bob, 
> 
> On Wednesday, August 02, 2006 2:00 PM you wrote:
> > ... 
> > Since wiki spam must occur over a HTTP connection, it is 
> > 2-way.  So, you have the verified IP's of the attackers.
> > Someone is clearly using a zombie net.  Consider spawning:
> >      iptables -A INPUT -s "$IP" -j DROP
> > when someone posts something in the banned_links.
> 
> Are you suggesting that I drop all connections from the
> complete list of ip addresses that are being used by the
> spammers? 

Yes.

> So far there are about 200 of these addresses
> scattered over several different subnets so I am not sure
> that this is practical. And as far as I can tell the number
> of ip addresses they are using is growing. I could also
> do something similar using our Apache hosts.deny file but
> I am quite concerned that these are spoofed ip addresses
> and do not really uniquely identify the spammers. Blocking
> all of these addresses might well affect ligitimit users.

Only legitimate users that are using a hacked windows box.  And, good
riddance, they should fix their computers.

> > Then, one would want to remove the ban on reguar links
> > or you would hit legitimate users. I'm assuming banned_links
> > would contain only the bad URL's/domain names. So in each
> > case you would get at least one spam.  
> 
> No, this does seem practical either because there are
> literally hundreds of these domain names. 

Yep.  Why is that a problem?

> > That's an interesting idea...can the post be held for moderation
> > too, in case someone makes an interesting edit but doesn't have
> > a zope userid?
> 
> Hmmm, you mean maybe write it to a non-web accessible or otherwise
> protected log file somewhere? Maybe even to a set of "shadow" pages
> that are only readable by registered Zope users? Moderation is a
> neat idea but it would take some programming work to implement.

Well, ideally something like a mailing list moderation where some
administrator can look at it and just hit a button to allow the edit.

\start
Date: Wed, 2 Aug 2006 15:18:25 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: spam attack

Bob,

On Wednesday, August 02, 2006 2:42 PM you wrote:
> >
> > Are you suggesting that I drop all connections from the
> > complete list of ip addresses that are being used by the
> > spammers?
>
> Yes.
>
> > So far there are about 200 of these addresses
> > scattered over several different subnets so I am not sure
> > that this is practical. And as far as I can tell the number
> > of ip addresses they are using is growing. I could also
> > do something similar using our Apache hosts.deny file but
> > I am quite concerned that these are spoofed ip addresses
> > and do not really uniquely identify the spammers. Blocking
> > all of these addresses might well affect legitimate users.
>
> Only legitimate users that are using a hacked windows box.
> And, good riddance, they should fix their computers.

If this is really being done via zombie net then I guess we
should be happy that is was only a couple hundred, right?
Maybe you are right that this is not such a problem, but
I would feel bad denying people access just because they are
being exploited without being able to give any explanation
even though the chance that any one of these users might
really want to know about Axiom is probably not that high.

>
> > > Then, one would want to remove the ban on regular links
> > > or you would hit legitimate users. I'm assuming banned_links
> > > would contain only the bad URL's/domain names. So in each
> > > case you would get at least one spam. 
> >
> > No, this does seem practical either because there are
> > literally hundreds of these domain names.
>
> Yep.  Why is that a problem?

The problem as I see it is that using this method we actually
have to let the spam through initially in order to capture
the domain names. And we don't have any easy way to harvest
the banned links from the spam postings and update the
pattern list. So it's an ongoing manual process. Plus I am
not sure how large this list can be practically speaking
since this is processed by Python as a large set of regular
expressions.

Maybe there are some new anti-spam options that Simon has
invented for ZWiki that could help, but merging our modified
ZWiki/LatexWiki code with the new ZWiki code is also likely
to be a serious amount of work. So far I have only done that
on a piecemeal basis.

> ...

\start
Date: Wed, 02 Aug 2006 23:09:47 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [build-improvements] Requests for discussion

Hi Gaby,

I'm sorry if I steal your precious time by my stupid questions...

On 08/02/2006 04:58 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> [...]
> 
> | I don't see a difference between
> | 
> |  >     (1) modify configure.ac.pamphlet
> |  >     (2) run ./build-setup.sh
> | 
> | and my suggested
> | 
> | 	modify configure.ac.pamphlet
> | 	make configure
> 
> "make" means that there is a Makefile that is used to make "configure".
> There isn't.  Any makefile must be generated at configure time when
> building Axiom.  I know that is not what the current system does;
> but it is a bug -- it got me several times.

That is your point of view and years of experience. I will trust you in 
setting up Autotools support for Axiom, since for now that is more 
important then sticking to pamphlet style. That you are going to 
document everything in some form is clear to me.

But still. I assumed that we distribute the sources with configure and 
an initial Makefile. That would be generated first by you via

   notangle configure.ac.pamphlet > configure.ac
   autoconf configure.ac > configure
   ./configure
   svn commit configure
   svn commit Makefile

That Makefile would contain code to generate "configure". So it 
basically contains your "build-setup.sh" script.

If I am an ordinary user, I start with ./configure && make.
If I am more advanced and change some stuff in configure.ac.pamphlet,
I start with "./configure" to make sure that I have "noweb" and then 
re-iterate via "make configure && ./configure". I really cannot see a 
problem with that.

> | I know that "make" checks whether the "Makefile" is as new as it could
> | be. But does it check whether there is Makefile.in or Makefile.am and
> | re-generates the Makefile from that???
> 
> No.  Makefile.in usually contains variables that need to be
> substituted.  Makefile.am is even at higher level.  You need
> Automake.  Now, when you have the full Autotools in place, if you
> modify Makefile.am or configure.ac and you say "make", there usually
> is a dectection and autoconf is run to regenerate

But I never modify Makefile.am or configure.ac. Only the corresponding 
pamphlet files. So there clearly there is a target like

%: %.pamphlet
	notangle $< > $@

or something the like.

\start
Date: Wed, 02 Aug 2006 23:38:02 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [build-improvements] Requests for discussion

> | If I understand the question, you are asking how we can have only literate 
> | program files in Axiom at the get go and still not depend on noweb.  The 
> | simple answer is, we can't. 
> 
> Actually, we can if we don't insist that literate files must be
> pamphlet files or we must use noweb :-) 

Well, isn't it much simpler? We are speaking here about the generation 
of code, so we mean notangle.

If for the bootstrapping file configure.ac.pamplet (that should be 
enough?) we restrict to just several code chunks of the form

<<*>>=
code here
@
...
<<*>>=
other code
@

All these <<*>> chunks are linearly concatenated by notangle to give the 
final output. For that simple task, I am sure that it is not too 
difficult to write a sed or awk script. And the initial dependency on 
noweb would be gone. Any sed/awk-programmers out there? Ehm, but then it 
might depend on awk... what programs are usually assumed to exist before 
I run ./configure? Windows/Un*x-like/MacOS systems are quite differnt.

I am not sure whether also the Makefile.am.pamphlet files could/should 
be written in such a linear way. But all the non-pamphlet world can 
handle just Makefile.am and that is linear. So where would a pamphlet 
format impose some dependency on noweb for the configure process?

\start
Date: 03 Aug 2006 01:39:33 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [build-improvements] Requests for discussion

Ralf Hemmecke writes:

[...]

| > | I know that "make" checks whether the "Makefile" is as new as it could
| > | be. But does it check whether there is Makefile.in or Makefile.am and
| > | re-generates the Makefile from that???
| > No.  Makefile.in usually contains variables that need to be
| > substituted.  Makefile.am is even at higher level.  You need
| > Automake.  Now, when you have the full Autotools in place, if you
| > modify Makefile.am or configure.ac and you say "make", there usually
| > is a dectection and autoconf is run to regenerate
| 
| But I never modify Makefile.am or configure.ac.

That is right.  But Autotools have implicit dependency on those.

\start
Date: 03 Aug 2006 01:51:59 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [build-improvements] Requests for discussion

Ralf Hemmecke writes:

| > | If I understand the question, you are asking how we can have only
| > literate | program files in Axiom at the get go and still not depend
| > on noweb.  The | simple answer is, we can't. Actually, we can if we
| > don't insist that literate files must be
| > pamphlet files or we must use noweb :-)
| 
| Well, isn't it much simpler? We are speaking here about the generation
| of code, so we mean notangle.

We're speaking of the bootstrapping process.  We need to start
from somewhere.  I believe notangle is not a wrong starting point.

But as I said, I implemented the majority's view.  I just disagree
with it.  My disagreement does nto change what end user will have to
type to install Axiom, when the project is completed.

| If for the bootstrapping file configure.ac.pamplet (that should be
| enough?) we restrict to just several code chunks of the form
| 
| <<*>>=
| code here
| @
| ...
| <<*>>=
| other code
| @
| 
| All these <<*>> chunks are linearly concatenated by notangle to give
| the final output.

Yes, that is what I implemented in configure.ac.pamphlet.

| For that simple task, I am sure that it is not too
| difficult to write a sed or awk script. 

If you have that script, I'll drop my objection -- because it means
our bootstrapping dependency is much weaker, i.e. only traditional
tools. 

| And the initial dependency on noweb would be gone. 

Exactly.

| Any sed/awk-programmers out there? Ehm, but then it might depend on
| awk...

Awk is traditional enough.

| what programs are usually assumed to exist 
| before I run ./configure?

That is the next round of patches I'll send.  Currently, there are
lots of unspoken dependencies deeply hidden in the makefiles.

| Windows/Un*x-like/MacOS systems are quite differnt.

Oh yeah, but I don't worry too much for the MacOS system as the
Unix-like enough.

| I am not sure whether also the Makefile.am.pamphlet files could/should
| be written in such a linear way. But all the non-pamphlet world can
| handle just Makefile.am and that is linear. So where would a pamphlet
| format impose some dependency on noweb for the configure process?

Makefile.am does not need to be linear.  In fact, Makefile.am is
sufficiently high-level enough that if and when we get there, we will
see that Tim already did the job.  We just need to re-structure
Makefile.pamphlet first.  You won't have to write Makefile.am,
because you will write Makefile.pamphlet (should they be renamed to 
Makefile.am.pamphlet? I don't know).  Then you get Makefile.am out of
it by build-setup.sh.  Once the system is in place, I do expect very
little modifications of makefiles; I suspect that 95% contribution
will be about algebra codes, 2% about the compiler...  So, the current
project is not a big deal.

\start
Date: Wed, 02 Aug 2006 22:57:52 -0700
From: Simon Michael
To: list
Subject: Zwiki update, anti-spam thoughts

Page, Bill wrote:
> Maybe there are some new anti-spam options that Simon has
> invented for ZWiki that could help, but merging our modified
> ZWiki/LatexWiki code with the new ZWiki code is also likely
> to be a serious amount of work. So far I have only done that
> on a piecemeal basis.

It has to be done sooner or later though, if you continue to use Zwiki, 
otherwise you fork more and more and you don't get the benefit of the 
latest enhancements. I know you know this. I think the best approach is for 
you and I to work on this together on IRC. I know Zwiki and you know the 
latexwiki/mathaction changes and together we could probably get over this 
hump in an hour or three.

Regarding the anti-spam features - these are documented best at 
http://zwiki.org/LinkSpam . I'm not sure which of them are available in 
your version at this point. Personally I don't bother with banned_links at 
all, updating it is too labour-intensive. max_anonymous_links and 
max_identified_links are quite effective although not perfect.

Each of these tends to raise the annoyance level for legitimate users even 
while it protects them. For your site, I have the feeling it may be best to 
bite the bullet and require a login for all or most kinds of edit. Signing 
up is annoying, but once you've done that, there should be no further 
hindrance to editing. And registering for a login (approved by human, if 
necessary) still seems to be a sufficient barrier to keep out spammers.

As for how to implement this: there are zope products which allow 
self-registration without the need for CMF or Plone (exUserFolder is an old 
one, there must be something better by now). Or, you could put the wiki 
inside Plone to take advantage of its polished membership system, but still 
have it use the fast zwiki skin (easy; see how-tos at zwiki.org or ask me).

\start
Date: Wed, 2 Aug 2006 23:26:48 -0700
From: Bob McElrath
To: Simon Michael
Subject: Re: Zwiki update, anti-spam thoughts

Simon Michael [Simon Michael] wrote:
> Page, Bill wrote:
> >Maybe there are some new anti-spam options that Simon has
> >invented for ZWiki that could help, but merging our modified
> >ZWiki/LatexWiki code with the new ZWiki code is also likely
> >to be a serious amount of work. So far I have only done that
> >on a piecemeal basis.
> 
> It has to be done sooner or later though, if you continue to use Zwiki, 
> otherwise you fork more and more and you don't get the benefit of the 
> latest enhancements. I know you know this. I think the best approach is for 
> you and I to work on this together on IRC. I know Zwiki and you know the 
> latexwiki/mathaction changes and together we could probably get over this 
> hump in an hour or three.

I think this is unwise.  I chased ZWiki "improvements" for more than a
year.  Maintaining a forked codebase that is up-to-date with the main
one is a full-time job.  Unfortunately, for dynamic web sites such as on
zope, EVERY site is essentially a forked codebase.  Mathaction
especially so due to LatexWiki, axiom, reduce, and the other enhancments
Bill has added.  Only the most trivial clone of zwiki.org could ever
hope to maintain an up-to-date copy of the zwiki code.

I do not think ZWiki will gain vast quantities of features that will be
critical for mathaction anytime soon.  This is the Microsoft/Intel
marketing ploy...don't buy (build) what you need, buy what will let you
run nebulous nonexistant things that we promise tomorrow.  I have a
different idea.  Use what works, NOW.

It is better to keep mathaction working, and add needed things
piecemeal.  It will be more work to merge mathaction with the latest
ZWiki than to import only the latest anti-spam features.

\start
Date: Thu, 03 Aug 2006 10:06:47 +0200
From: Ralf Hemmecke
To: list
Subject: Be Bold

Hi Bill,

thank you for all your changes.

I just want to say that I like the *red* "Be Bold!" link in the "Add 
Comments" section at the end of each page. I like it even if I think 
that commenting on the page is not too helpful. People should really 
edit the page if they don't like something there.

Comments on a page look to me always like "the page should be improved, 
but nobody had time to do it". So it basically shows that Axiom (or at 
least the Axiom Wiki content) is not maintained well enough.

\start
Date: Thu, 03 Aug 2006 10:13:17 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [build-improvements] Requests for discussion

Hi Gaby,

> | If for the bootstrapping file configure.ac.pamplet (that should be
> | enough?) we restrict to just several code chunks of the form
> | 
> | <<*>>=
> | code here
> | @
> | ...
> | <<*>>=
> | other code
> | @
> | 
> | All these <<*>> chunks are linearly concatenated by notangle to give
> | the final output.
> 
> Yes, that is what I implemented in configure.ac.pamphlet.
> 
> | For that simple task, I am sure that it is not too
> | difficult to write a sed or awk script. 
> 
> If you have that script, I'll drop my objection -- because it means
> our bootstrapping dependency is much weaker, i.e. only traditional
> tools.

Last night I saw that Automake depends on Perl. I am much more fluent in 
Perl. And Perl runs und Window, too. I believe a simple notangle 
replacement for the configure files would be much easier in Perl. Do you 
allow me to write it in Perl? Or is that dependency already too strong?

\start
Date: Thu, 03 Aug 2006 10:34:54 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [build-improvements] Requests for discussion

> Makefile.am does not need to be linear.  In fact, Makefile.am is
> sufficiently high-level enough that if and when we get there, we will
> see that Tim already did the job.  We just need to re-structure
> Makefile.pamphlet first.  You won't have to write Makefile.am,
> because you will write Makefile.pamphlet (should they be renamed to 
> Makefile.am.pamphlet? I don't know).

I guess the literate idea even says that it does not matter how a file 
is called. It is most important that you write a paper from which you 
can generate all the code (even different files from one pamphlet 
source). That sounds nice, but in some sense I find that very difficult 
to maintain. For ALLPROSE I set the convention every file is a .nw file. 
(I don't yet had the need to store file types like .fig or .png or other 
strange formats where the noweb-style makes no sense.)
The file keeps its original name with just .nw added. From that I 
generate .nw.tex files (that basically makes just one Makefile rule to 
generate latex). That naming convention has some advantages.

1) If you generate .dvi from the .nw.tex file. It is easily possible to 
click into the dvi file and jump to the .nw (not .nw.tex) source. VERY 
convenient.

2) At least for .as.nw file... If the compilation breaks and the Aldor 
compiler were able to understand the "#line ..." directives correctly, 
then one could use a smart editor (e.g emacs) to run the compilation 
inside a buffer and jump directly to the place in the source where the 
compiler found the error.

I suggest to adopt that convention for axiom (replace .nw by .pamphlet).

\start
Date: 03 Aug 2006 12:19:40 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [build-improvements] Requests for discussion

Ralf Hemmecke writes:

| Hi Gaby,
| 
| > | If for the bootstrapping file configure.ac.pamplet (that should be
| > | enough?) we restrict to just several code chunks of the form
| > | | <<*>>=
| > | code here
| > | @
| > | ...
| > | <<*>>=
| > | other code
| > | @
| > | | All these <<*>> chunks are linearly concatenated by notangle to
| > give
| > | the final output.
| > Yes, that is what I implemented in configure.ac.pamphlet.
| > | For that simple task, I am sure that it is not too
| > | difficult to write a sed or awk script. If you have that script,
| > I'll drop my objection -- because it means
| > our bootstrapping dependency is much weaker, i.e. only traditional
| > tools.
| 
| Last night I saw that Automake depends on Perl. I am much more fluent
| in Perl. And Perl runs und Window, too. I believe a simple notangle
| replacement for the configure files would be much easier in Perl. Do
| you allow me to write it in Perl? Or is that dependency already too
| strong?

That would be a good thing, at least.

Many thanks for your feedback.

\start
Date: Thu, 3 Aug 2006 10:10:31 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: [build-improvements] Requests for discussion

> I guess the literate idea even says that it does not matter how a file 
> is called. It is most important that you write a paper from which you 
> can generate all the code (even different files from one pamphlet 
> source). That sounds nice, but in some sense I find that very difficult 
> to maintain. For ALLPROSE I set the convention every file is a .nw file. 

> I suggest to adopt that convention for axiom (replace .nw by .pamphlet).

Ralf,

In fact the system direction is the exact opposite, at least the parts
I touch. C (and, even more egregious, Java) adopt the file-per-function
kinds of idea.

If you look back in history (or lived it as I have), you'll see that the
tiny-file idea is based on computer restrictions. Memory was small and
the compiler couldn't handle large files. Furthermore, the loader couldn't
load large files. So everyone uses small files (or, in my case, short
paper tapes).

You see this legacy everywhere. It is still possible to write memory
overlays in linkers so that when one function completes it can be 
relaced in memory by another link section. This allows a large program
to run in small physical memory. This "feature" is still supported by
the intel chip with segmented memory (which is rarely used but still
causes pain). Limits of storage, compiler technology and imagination 
caused the idea of splitting out header files as a way to expose
signatures. Now we live in header-file hell. "Libraries" were ways
to collect all the little pieces so the linker could connect them
and now we have DLL hell and lib* hell. Indeed we are forced to use
"IDE"s because the tiny files have overwhelmed our ability to cope.

The #line directive is a hack to allow a runtime to figure out which
grain-of-sand-file contains this particular function. It is also a
legacy of history. I am building a program for work that lives in one
literate file, has 30,000 lines of Lisp code, and has 2000+ pages of
final pdf documentation (so far) and 7000 test cases. It is never
ambiguous which file contains the failing function.




Computer programs have nothing to do with their file storage but
we have linked these ideas and suffered for it. Suppose we follow
the past and make Axiom "include" files which separate out the
signature information in a domain or category into separate files.
Then we could add an "include" statement. This way lies madness.

Consider what happens if you scale Axiom by a factor of 100 in
the next 30 years onto a petamachine. You end up with 110,000
domains and categories with roughly 1,100,000 functions. I don't
want 110K files. I want 110 books.



I have a library that must include 20 books on group theory. 
They each have a section on permutation groups. It would be more
"efficient" if there were a standardized "permutation group" booklet
that everyone referenced as "included" into their text. That way there
would be no duplication. But that misses the point of literate works.

The key point is not that I talk about permutation groups but that I
talk about them in a certain way, in a certain place, with a certain
style, for a certain audience. The fact that the information is
available elsewhere means nothing to the human.

And we're trying to write for humans, not for machines.

I want to send you one book that you can just sit and read.
Not read by computer, but sit and read for educational purposes.
And, as a side-effect, you can also compile and run it. The running
program illustrates the ideas in a way that you can build on them.
You can modify them, extend them, write about them, and distribute
them, solve problems with them. You can build on other people's work. 

We need to lift our eyes back to the humans, away from the technology.
Communicate, don't program.

\start
Date: Thu, 03 Aug 2006 16:24:41 +0200
From: Gernot Hueber
To: list
Subject: Axiom patch-49 (+ Aldor 1.0.3) compiles on FreeBSD :-))

I am working with Axiom/Aldor on FreeBSD systems (FreeBSD 6.1 and 5.4,
gcl-2.6.6 and gcl-2.6.7). After Axiom compiles fine (with some with some
minor patches I will provide after cleaning up them). Especially the
Aldor part causes some serious headache.

Is anybody interested in or able to build a FreeBSD port?
... and is able to get compiler::link working for interpsys?

\start
Date: Thu, 3 Aug 2006 10:27:26 -0400
From: Tim Daly
To: Gernot Hueber
Subject: Re: Axiom patch-49 (+ Aldor 1.0.3) compiles on FreeBSD :-))

I have not been successful building Axiom on FreeBSD.
I would like to see your patches.

\start
Date: Thu, 03 Aug 2006 18:19:06 +0200
From: Gernot Hueber
To: list
Subject: Re: Axiom patch-49 (+ Aldor 1.0.3) compiles on	FreeBSD :-))

Hi,

Here is the patchfile. Pls check.
util.ht is broken, but I think this is not a FreeBSD issue. I used one
from an older build and hyperdoc works again.

You need bash, gsed and gawk installed!
Install gcl from the ports with "--enable-ansi" removed from the
Makefile.

Go into bash, start ./configure, and follow the messages (exports +
gmake GCL...).

Aldor works fine in the emulator, but I think you need the
linux-develtools port.

On Thu, 2006-08-03 at 11:37 -0400, root wrote:
> There are C files that are part of the lisp build.
> Once the lisp builds all will go smoothly.
> The Lisp is portable; C is not.
> 
> t
> 

--=-0/PoPos6L0FhxfyLS++8

--- ./src/algebra/Makefile.pamphlet.orig	Wed Aug  2 16:51:37 2006
+++ ./src/algebra/Makefile.pamphlet	Wed Aug  2 16:52:04 2006
@@ -1770,7 +1770,7 @@
 <<findSpadFiles>>=
 
 egrep '@<<(domain|package|category) .*>>=' *.spad.pamphlet | sort | uniq | \
-awk -F: '{
+${AWK} -F: '{
   chunk=substr($2,3,length($2)-5);
   split(chunk,part," ");
   spadfile="\${MID}/"part[2]".spad";
@@ -1833,7 +1833,7 @@
 <<findBootstrapFiles>>=
 
 egrep '@<<.*BOOTSTRAP>>=' *.spad.pamphlet | sort | uniq | \
-awk -F: '{
+${AWK} -F: '{
   chunk=substr($2,3,length($2)-5);
   split(chunk,part," ");
   lspfile="\${MID}/"part[1];
--- ./src/boot/Makefile.pamphlet.orig	Tue Aug  1 09:27:25 2006
+++ ./src/boot/Makefile.pamphlet	Tue Aug  1 09:44:52 2006
@@ -1173,7 +1173,7 @@
 
 Until this is fixed we need to continue to use the old scheme.
 <<environment>>= 
-CMD0=	(progn (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system "${SAVESYS}"))
+CMD0=	(mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system "${SAVESYS}")
  
 @
 \subsection{boothdr.lisp \cite{1}}
@@ -1732,7 +1732,7 @@
 	@ echo INT= ${INT}
 	@ echo OBJ= ${OBJ} 
 	@ echo MNT= ${MNT}
-	@ (cd ${OBJ}/${SYS}/bin ; echo '${CMD0}' | ${LOADSYS} >${TMP}/console )
+	@ (cd ${OBJ}/${SYS}/bin ; echo '${CMD0}' | ${LOADSYS} >${TMP}/console_bootsys )
 	@ echo 45 ${SAVESYS} created
 
 boot: ${BOOTS}
--- ./src/graph/view2D/globals2.h.orig	Thu Aug  3 09:28:39 2006
+++ ./src/graph/view2D/globals2.h	Thu Aug  3 10:03:58 2006
@@ -30,6 +30,7 @@
 NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
+#include "../../src/include/hash.h"
 
 extern int           scrn;
 extern Display       *dsply;
--- ./src/graph/view3D/globals.h.orig	Thu Aug  3 10:05:41 2006
+++ ./src/graph/view3D/globals.h	Thu Aug  3 10:06:02 2006
@@ -31,6 +31,8 @@
 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
 
+#include "../../src/include/hash.h"
+
 extern int              scrn;
 extern Display          *dsply;
 extern XFontStruct      *globalFont, *buttonFont, *headerFont, 
--- ./src/hyper/hthits.pamphlet.orig	Thu Aug  3 10:07:41 2006
+++ ./src/hyper/hthits.pamphlet	Thu Aug  3 10:08:44 2006
@@ -93,7 +93,9 @@
 {
     cmdline(argc, argv);
 
+/*
     compile(pattern, expbuf, expbuf + MAX_COMP_REGEX, '\0');
+*/
 
     handleHtdb();
     return(0);
@@ -337,11 +339,13 @@
     char *bodyrest;
     int nhits = 0;
 
+/*
     if (step(pgtitle, expbuf))
         nhits++;
 
     for (bodyrest = pgbody; step(bodyrest, expbuf); bodyrest = loc2)
         nhits++;
+*/
     if (nhits) {
         printf("\\newsearchresultentry{%d}{%s}",nhits, pgtitle);
         squirt(pgname, strlen(pgname));
--- ./src/include/hash.H1.orig	Tue Aug  1 08:40:42 2006
+++ ./src/include/hash.H1	Tue Aug  1 08:39:35 2006
@@ -1,3 +1,4 @@
+#include "hash.h"
 #ifdef _NO_PROTO
 extern char * alloc_string();
 extern HashEntry * hash_copy_entry();
--- ./src/aldor/types.mk.pamphlet.orig	Thu Aug  3 16:56:07 2006
+++ ./src/aldor/types.mk.pamphlet	Thu Aug  3 16:56:20 2006
@@ -200,7 +200,7 @@
 
 
 $(MID)/sax0/spadset.lst: $(MID)/sax0/spadset.mk $(IN)/list_spadset.mk
-	make -f $(IN)/list_spadset.mk MID=$(MID) spadset=sax0 dest=$@
+	gmake -f $(IN)/list_spadset.mk MID=$(MID) spadset=sax0 dest=$@
 
 #
 # Everything else
--- ./src/aldor/Makefile.pamphlet.orig	Thu Aug  3 16:56:57 2006
+++ ./src/aldor/Makefile.pamphlet	Thu Aug  3 16:57:22 2006
@@ -74,7 +74,7 @@
 	else										\
 		echo "Building libaxiom.al and associated files";			\
 		echo $(MID);\
-		make REALLY_BUILD=1 -f $(IN)/Makefile aldor_libraries;			\
+		gmake REALLY_BUILD=1 -f $(IN)/Makefile aldor_libraries;			\
 	fi
 
 .PHONY: all
@@ -85,10 +85,10 @@
 
 <<boringrules>>=
 clean: $(IN)/Makefile 
-	make -f $(IN)/Makefile REALLY_BUILD=1 _clean
+	gmake -f $(IN)/Makefile REALLY_BUILD=1 _clean
 
 list_sources: $(IN)/Makefile 
-	make -f $(IN)/Makefile REALLY_BUILD=1 _list_sources
+	gmake -f $(IN)/Makefile REALLY_BUILD=1 _list_sources
 
 .PHONY: clean list_sources
 @
--- ./src/aldor/Make.aldor.pamphlet.orig	Thu Aug  3 16:57:29 2006
+++ ./src/aldor/Make.aldor.pamphlet	Thu Aug  3 16:57:36 2006
@@ -36,7 +36,7 @@
 	 rm -f $@.tmp; \
 	 aldor $(ap_compile_options) \
 		-fap=$@.tmp $(filter %/$(shell basename $@ .ap).as, $^))
-	@sed -e 's/\([->A-Za-z0-9\\]\+\)/|\1|/g' < $@.tmp > $@
+	@gsed -e 's/\([->A-Za-z0-9\\]\+\)/|\1|/g' < $@.tmp > $@
 
 #
 # .ap/.as -> .ao
--- ./src/aldor/gen-axiom-types.sh.pamphlet.orig	Thu Aug  3 17:10:33 2006
+++ ./src/aldor/gen-axiom-types.sh.pamphlet	Thu Aug  3 17:11:00 2006
@@ -15,12 +15,12 @@
 
 case $1 in
 all)
-	ls $2/../algebra/*.spad | xargs grep '^)abbrev' | awk '{print $3}';;
+	find $2/../algebra/ -name \*.spad | xargs grep '^)abbrev' | awk '{print $3}';;
 
 categories)
-	ls $2/../algebra/*.spad | xargs grep -E '^\)abbrev[\t ]+category' | awk '{print $3}';;
+	find $2/../algebra/ -name \*.spad | xargs grep -E '^\)abbrev[\t ]+category' | awk '{print $3}';;
 typemap)
-	ls $2/../algebra/*.spad | xargs grep -E '^\)abbrev' | awk '{printf("%s:%s:\n",$3,$4)}';;
+	find $2/../algebra/ -name \*.spad | xargs grep -E '^\)abbrev' | awk '{printf("%s:%s:\n",$3,$4)}';;
 *)
 	echo "What??"
 	exit 2
--- src/interp/debugsys.lisp.pamphlet.orig	Thu Aug  3 17:57:20 2006
+++ src/interp/debugsys.lisp.pamphlet	Thu Aug  3 18:07:36 2006
@@ -169,7 +169,7 @@
       (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 "/obj/linux/interp/sockio.o")
       (thesymb "/int/interp/spad.lisp")
       (thesymb "/int/interp/spaderror.lisp")
       (thesymb "/int/interp/template.clisp")
--- configure.orig	Thu Aug  3 17:42:25 2006
+++ configure	Thu Aug  3 18:09:07 2006
@@ -4,7 +4,7 @@
 #       MINGW32_NT-5.1 --> windows
 #       SunOS          --> Solaris9
 #       Fedora Core 3  --> fedora3
-#       freebsd        --> freebsd
+#       freebsd        --> FreeBSD
 #
 # The solaris platform needs patch->gpatch, awk->gawk, tar->gtar
 
@@ -24,7 +24,7 @@
    if [ "$SYSNAME" = "Linux" ] ; then SYSNAME=linux
    elif  [ "$SYSNAME" = "MINGW32_NT-5.1" ] ; then SYSNAME=windows
    elif  [ "$SYSNAME" = "SunOS" ] ; then SYSNAME=solaris9
-   elif  [ "$SYSNAME" = "freebsd" ] ; then SYSNAME=freebsd
+   elif  [ "$SYSNAME" = "FreeBSD" ] ; then SYSNAME=freebsd
    else
      echo Your system name is $SYSNAME
      echo We do not know how to build for this kind of system
@@ -115,7 +115,7 @@
   echo If you wish to use the standard version you must type
   echo touch noweb 
   echo If you wish to use a pre-installed GCL you must type
-  echo make GCLVERSION=gcl-system
+  echo gmake GCLVERSION=gcl-system
 fi
 if [ "$SYSNAME" = "solaris9" ] ; 
  then echo make AWK=gawk TAR=gtar PATCH=gpatch

--=-0/PoPos6L0FhxfyLS++8--

\start
Date: Thu, 3 Aug 2006 12:51:02 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Front page esthetic

Gaby, Ralf, Cliff, Antoine, Alfredo, and others who I hope
I haven't forgotten:

Thank you all very much for the valuable comments, criticisms
and suggestions regarding the Axiom Wiki web site that you have
contributed to this thread. I have read each message carefully
although I have not responded specifically to everyone. I did
at least try to respond where I could help to explain something
or what I might have been thinking at the time of making (or just
sliding :) into an effective design decision about how the web
site should look and work. If I missed something don't hesitate
to ask or to repeat your comments.

Over the last few days, I did tried quite hard however to
incorporate as many of the suggested design changes as
practical in the, as usual, insufficient time and which my
limited availability allowed. Of course I couldn't do everything
and somethings I decided (unilaterally ;) that I didn't really
want to do. And there were some other changes I made were of
my own initiative. So I remain laregely responsible for the
overall result (both good and bad). Reviewing it again though
this morning my overal impression is quite positive. I think
that as a result of all of your suggestions these changes
have resulted in a better and significantly easier to use web
site with which to support the Axiom project. And I am very
interested in hearing your reactions.

This email is just to say "thanks" again, and to remind you
that this process is of necessity an on going one that will
likely never be finished and fully satisfactory... there is more
to do, so please keep your comments, criticisms and suggestions
coming! In particular, when you have a moment in the next few
days, could you please take a few minutes to look and play with
the Axiom Wiki web site and let me know of things that I might
have missed or anything that I have just done to the site that
you particularly dislike. Of course, when and where it is
possible you should also feel free as usual to continue to make
changes and improvements to the content yourselves. (That is
addressed to *everyone* on the Axiom developer email list! :)

I can't say for sure right now when I will next be able to
schedule some time like the last few days (and off-and-on
over the last month) to make additional changes that require
programming - now I really have to attend to other things for
a while - but you should feel free to comment and mention
them now anyway. Or another thing might be to submit a few
IssueTracker reports and feature enhancements and/or bugs.

\start
Date: Thu, 3 Aug 2006 09:58:02 -0700
From: Bob McElrath
To: list
Subject: interesting new CAS

Today appeared "A field-theory motivated approach to symbolic computer
algebra":http://arxiv.org/abs/cs.SC/0608005 which is of course very
interesting to me.  Anyone who has used any tensor package in any CAS
will sympathize with the  goals of the author.

The code is GPL and he even wrote a texmacs interface:
    http://www.aei.mpg.de/~peekas/cadabra/

\start
Date: 03 Aug 2006 19:52:49 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Front page esthetic

Bill Page writes:

[...]

| This email is just to say "thanks" again

Thank *you*.  

Indeed, this is excellent!

\start
Date: Thu, 3 Aug 2006 13:59:52 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: interesting new CAS

Bob,

Thanks very much for the reference to this new work. Having
actually written a tensor package for Maple a few years ago
and now contemplating the limitations of the CartesianTensor
domain in Axiom, I do have a great respect for this problem.

On Thursday, August 03, 2006 12:58 PM you wrote:
>
> Today appeared "A field-theory motivated approach to symbolic
> computer algebra":http://arxiv.org/abs/cs.SC/0608005 which is
> of course very interesting to me.  Anyone who has used any
> tensor package in any CAS will sympathize with the  goals of
> the author.
>
> The code is GPL and he even wrote a texmacs interface:
>     http://www.aei.mpg.de/~peekas/cadabra/

Whenever I see GPL these days my mind goes immediately to
thoughts of integrating the software into some other piece
of open source software with which I am more familiar. In
fact the number of open source packages is growing so rapidly
that we really have a large number of options. Already there
is a TeXmacs interface. Interfacing to MathAction to provide
a common web interface should be very easy. Some sort of
integration between Cadabra and Axiom would be nice - but
how to solve the problem of interfacing with lisp and passing
symbolic expressions? Another option we have to consider now
also is the potential for integration with Sage.

Any ideas about this?

There is another recent paper and a package, this one written
in Aldor on a similar subject of symbolic vector algebra, by
some people in the group where Steven Watt is a principle
resarcher. I sent the email request attached below for
information about the source code, but I have not heard back
from them yet.

Regards,
Bill Page.

-----Original Message-----
From: Page, Bill
Sent: Tuesday, July 18, 2006 7:33 PM
To: 'sliang22@uwo.ca'
Cc: 'Stephen Watt'; 'djeffrey@uwo.ca'
Subject: Component-free vector algebra in Aldor

Dear Sirs;

I read with great interest in your publication:

Component-free vector algebra in Aldor, Songxin Liang,
David J. Jeffrey and Stephen M. Watt, pp. 415-418,
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-vectalg.pdf

In the paper you state:

"Because of space limitations, this description of the
program is necessarily brief, and omits most details. However,
the source code for the program will be made available on the
Aldor web site, from where it may be downloaded and inspected."

However I have not been able to locate this source code at
www.aldor.org and it seems that the Aldor web site may not
have been updated for some time. I would be very pleased if
you could direct me to the appropriate location or if you
could send me this code by email.

As an example of the application of your work that I have in
mind, you might refer to:

http://wiki.axiom-developer.org/SandBoxCategoricalRelativity

And of course I would be very interested in hearing about
other work of this kind.

\start
Date: Thu, 03 Aug 2006 20:33:55 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: [build-improvements] Requests for discussion

On 08/03/2006 04:10 PM, root wrote:
>> I guess the literate idea even says that it does not matter how a file 
>> is called. It is most important that you write a paper from which you 
>> can generate all the code (even different files from one pamphlet 
>> source). That sounds nice, but in some sense I find that very difficult 
>> to maintain. For ALLPROSE I set the convention every file is a .nw file. 
> 
>> I suggest to adopt that convention for axiom (replace .nw by .pamphlet).
> 
> Ralf,
> 
> In fact the system direction is the exact opposite, at least the parts
> I touch. C (and, even more egregious, Java) adopt the file-per-function
> kinds of idea.

You won't believe, but I agree. The literate idea contradicts Java's 
one-file-per-class.

But what I think is important is, not just to write HUGE files that 
nobody can manage anymore, but to add a bit of structure to it. Nowadays 
we could write a whole book into just one latex file. But I bet, most 
people structure that via several files to keep things manageable (in 
the head not because of the file system).

We should also note that we are not yet at a point where we can really 
start to work on the mathematics that we all love to do. We are 
struggeling with the building process. So my suggestion/convention is 
just to keep the build simple. If you come up with a better one, welcome.

I think any convention is better then the mess we currently have. What I 
have seen in the Axiom build process is one-pamphlet-per-Makefile. That 
is very much JAVA-like. One would have ONE document that describes the 
whole build process, that is clear. But that document is a generated one 
(dvi/pdf/...) but not necessarily just ONE pamphlet.

If you have the dvi, click on it and your editor jumps directly to the 
appropriate source, you would not even care how the file is called. But 
if you impose a certain structure on the files (like the 
Makefile.am.pamphlet structure that Gaby is going to create), the whole 
build process can be described a lot easier, since it relies on the 
standard GNU Autotools. If you put all the various Makefile.am files 
into just ONE big pamphlet, you even need a description (and some shell 
script) that extracts all those different files from your .pamphlet. 
Note that you would have to call notangle several times.

If everyone adopts his own conventions of what files are in the 
pamphlet, that basically means that everyone provides his own (certainly 
non-standard) scripts to transform the pamphlet into actual source code.
I don't think I would call that manageable, even if the pamphlet 
describes what it does. Conventions/Rules are the way to go.

One rule we already have: Everything should be a pamphlet.
Next rule should be that there has to be a certain structure of the 
pamphlet so that a number of the pamphlets can be used to produce one 
document (a book if you like) that describes the build, another set of 
pamphlets (that need not be disjoint from the first one) that describes 
the interpreter etc. (But the "certain" above is still unclear, at least 
I want that there is no \documentclass, \begin{document}, \end{document} 
anymore.--The \usepackage is a problem, I know and have not yet a good 
solution.)

> Indeed we are forced to use "IDE"s because the tiny files have
 > overwhelmed our ability to cope.

If you think that IDE's are just for that purpose, I think you missed 
something. You get more than that. For example, if your mouse moves over 
a function, you see its API description. You could click and jump to the 
definition of the function. Right, that sounds like programming, but 
even if we write pamphlets we finally have to write some code so if your 
IDE would bring you immediately to the section where the function that 
you want to use is described/defined, that would be convenient and make 
your work more productive. It is just another workflow you have to 
become accustomed to.

And somehow you have to turn all the codepieces into an actual source 
code of a certain programming language. Pamphlets are nice, but it is a 
bit hard to debug the code that comes out. You know, we are all not 
perfect, so debugging is still an issue.

> The #line directive is a hack to allow a runtime to figure out which
> grain-of-sand-file contains this particular function. It is also a
> legacy of history. I am building a program for work that lives in one
> literate file, has 30,000 lines of Lisp code, and has 2000+ pages of
> final pdf documentation (so far) and 7000 test cases. It is never
> ambiguous which file contains the failing function.

OK, an example: My Aldor program tells me that there is an error in
the + function. How long would it take you to find the right function 
definition without a compiler telling you a line number, if you have 100 
definitions of + in you 10,000 lines pamphlet? Even having just 10 
definitions of +. It's a waste of time if I am looking at the wrong 
place in 90% of the cases.

> Computer programs have nothing to do with their file storage but
> we have linked these ideas and suffered for it. Suppose we follow
> the past and make Axiom "include" files which separate out the
> signature information in a domain or category into separate files.
> Then we could add an "include" statement. This way lies madness.

If I use a category like "Ring" I am surely NOT going to "include" a 
definition of "Ring" into my code. It is completely enough for me if the 
"Ring" that appears in my code+description is a hyperlink and leads me 
to the right place in the generated DVI/PDF/HTML. Especially if you 
think of the web as a big document, why would you want to include and 
reproduce all existing things again and again?


> Consider what happens if you scale Axiom by a factor of 100 in
> the next 30 years onto a petamachine. You end up with 110,000
> domains and categories with roughly 1,100,000 functions. I don't
> want 110K files. I want 110 books.

Yes. But if your editor would not even tell you how many different files 
your document consists of, why would you care whether you have 110K or 
220K or just 110 files? We don't yet have the right tools to abstract 
from the file system.

> We need to lift our eyes back to the humans, away from the technology.
> Communicate, don't program.

I support this idea. But somebody has to provide the underlying 
technology, right? And Axiom partly is or will become such a system. You 
don't want to start from the very beginning, but you want to draw a 
line. You don't explain how a computer is built if you want to speak 
about permutation groups.

And the "book" idea is good, but it is not perfect. You have already 
said that you want to write books for different people, look from a 
different perspective onto the same data. So wouldn't it be nice to have 
all these data (= some information) split into atoms that could be put 
together to new molecules (=books)? Read about the LEO system, they 
basically have such an idea of different view onto the same data.

And actually, if we used our Wiki more extensively, also that could 
provide different views onto Axiom. I think, even in 20 years the 30 
years horizon is still that far away.

\start
Date: Thu, 3 Aug 2006 15:37:03 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [build-improvements] Requests for discussion

On Thursday, August 03, 2006 2:34 PM Ralf Hemmecke wrote:

> ...
> And the "book" idea is good, but it is not perfect. You have
> already said that you want to write books for different people,
> look from a different perspective onto the same data. So wouldn't
> it be nice to have all these data (= some information) split into
> atoms that could be put together to new molecules (=books)? Read
> about the LEO system, they basically have such an idea of
> different view onto the same data.

+1 For sure. Leo is a "new generation" literaterate programming
tool that is well worth looking into. I think we would learn
a lot about Axiom if we were to set up a Leo environment of
building Axiom.

>
> And actually, if we used our Wiki more extensively, also that
> could provide different views onto Axiom. I think, even in 20
> years the 30 years horizon is still that far away.
>

++1 Double for sure! :) I would very much like to continue to
explore this possibility :( if I ever find some more time ):

To put it crudely in the vernacular of the current generation:

"We don't need no stink'n 2000 page book! We're web connected."

Seriously, I think the web (the whole web, not just what fits
on your desktop) is the only technology that can solve this
sort of problem at the "peta-scale" that, as Tim has suggested,
is nearlly here already. Unfortunately we are only just being
to learn how to build such systems.

\start
Date: Thu, 3 Aug 2006 14:05:57 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: [build-improvements] Requests for discussion

--- Ralf Hemmecke wrote:

> But what I think is important is, not just to write HUGE files that 
> nobody can manage anymore, but to add a bit of structure to it.
> Nowadays we could write a whole book into just one latex file. But 
> I bet, most people structure that via several files to keep things
> manageable (in the head not because of the file system).

Bingo.  When I started trying to write Maximabook way back when, one of
the first things I did was learn how to combine individual files using
a "master" control document file.  Even if the editor can handle tens
of thousands of lines (and syntax highlighting those lines!) I can't
parse that much information without help.

I prefer the idea of "one file per concept", which happens to map
fairly well to the journal/academic paper model if we want an Axiom
journal.  I envision the algebra structure as being composed of "core"
files which implement the basic foundations the system is built on and
most basic functionality (e.g. the current pamphlets) and then seeing
the system gradually expand in two ways.  1)  individual papers
(pamphlets) contributed via journal or individual authors having to do
with specific subjects 2)  as the quality of individual contributions
is proven and they become more central to the functionality being
implemented, fold the individual paper or papers that are becoming
"core" into the main file pertaining to that subject (so in a core
file, "chapters" or maybe "sections" would have their own subject
categorization.  Or, using MSC, we have one file for each "top-level"
category that implements the standard functionality of Axiom for that
mathematical domain, and papers in sub-topics that address more
specific areas.

This could also address a concern I have with the wiki and "open"
nature of Axiom - namely, that Axiom is not really a "peer-reviewed"
work.  Normal open source is "potentially" peer-reviewed, meaning
anybody can review it but it is not guaranteed that it has been
reviewed.  The wiki content, by design, is even less guaranteed to be
"correct" in any academically verified sense.  This could pose a
problem with being accepted for use in academic work - e.g. the lack of
authority behind the conceptual correctness of the work in question. 
The question arises - "is this functionality I'm using written by
someone who knows what he/she is doing, and/or has it been checked and
verified by someone who can recognize when it's working incorrectly?" 
The "core" files in each subject will be Axiom's "branded"
functionality - the functionality that we as a project stand behind as
being high quality.  There are a few other ideas that need exploring
here, like systematic peer review of functionality, but I think it is
an important question that will bear on the acceptance of Axiom into
the academic community in the future.  Wikipedia faces the same issue -
how do you know what you're reading is written by someone who knows
what they are doing, and doesn't just represent "common wisdom?"

> We should also note that we are not yet at a point where we can
> really start to work on the mathematics that we all love to do. We
> are struggeling with the building process. So my 
> suggestion/convention is just to keep the build simple. If you come
> up with a better one, welcome.

I think we are moving in that direction.  Axiom is a complex system, so
there are certain limitations to the build simplicity, but I am very
glad to see a configure/make/make install routine arrive - I think that
is a very important first step.

> I think any convention is better then the mess we currently have.
> What I have seen in the Axiom build process is one-pamphlet-per-
> Makefile. That is very much JAVA-like. One would have ONE document
> that describes the whole build process, that is clear. But that
> document is a generated one (dvi/pdf/...) but not necessarily just
> ONE pamphlet.

As I understand it, the autotools will eventually get us close to that
goal.  I think we won't be able to reduce it beyond an autotools build
process triggering a lisp based build process, but that IMHO is the
best possible situation.  Maxima was brought to that point some time
ago and the system has been remarkably successful - I think it shows
"the way forward" for large free lisp programs in general.  Autotools
interfaces with the "normal" software development world (as well as
handling a score of practical points we don't want to worry about), and
lets us keeps the "lisp and beyond" parts in Lisp, which has a number
of advantages from a development standpoint.  Autotools +
defsystem/asdf is a very powerful and flexible setup.
 
> One rule we already have: Everything should be a pamphlet.
> Next rule should be that there has to be a certain structure of the 
> pamphlet so that a number of the pamphlets can be used to produce one
> document (a book if you like) that describes the build, another set
> of pamphlets (that need not be disjoint from the first one) that
> describes the interpreter etc. (But the "certain" above is still
> unclear, at least I want that there is no \documentclass, \begin
> {document}, \end{document} anymore.--The \usepackage is a problem,
> I know and have not yet a good solution.)

I experimented with this some time ago, actually - having the actual
content be in a "content-only" latex file, and having two types of
"top-level" files - one that pulled several "content-only" files into a
book, and the other type (a standard file for all pamphlet files which
could be altered on an individual file basis) which would let the user
print an individual "paper".  IIRC there wasn't much interest in this
at the time and I abandoned the experiment.

> If I use a category like "Ring" I am surely NOT going to "include" a 
> definition of "Ring" into my code. It is completely enough for me if
> the "Ring" that appears in my code+description is a hyperlink and
> leads me to the right place in the generated DVI/PDF/HTML.
> Especially if you think of the web as a big document, why would you
> want to include and reproduce all existing things again and again?

One illustration of presenting information in different ways might be
illustrated by the dimensions example.  In the units paper, I need to
explain several programming concepts "polymorphism" in order to make
sense of how to express dimensional ideas in a computer algebra system.
 Now, if we make all of Axiom fully literate there will undoubtedly be
a "proper" explanation of polymorphism somewhere in the compiler part
of the software, but I'll want to explain it with respect to the units
code because someone reading up on units is probably doing it for
scientific work in the physical sciences.  Thus, an explanation of
polymorphism for a programmer might be less useful to a physical
scientist than the explanation targeted for that particular audience.

However, I agree that in general a link to an explanation is preferable
- we should avoid information duplication which does provide a real
benefit to the end user.
 
\start
Date: 03 Aug 2006 23:16:04 +0200
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: [build-improvements] Requests for discussion

Cliff Yapp writes:


[...]

| I prefer the idea of "one file per concept",

strongly agreed.  

For me, the issue here is that of organizing information for human
comprehension.  I simply cannot handle gigantic file, no matter how
powerful my computers are.

\start
Date: Fri, 04 Aug 2006 08:46:42 +0200
From: Gernot Hueber
To: list
Subject: interpsys with dlopen in underlying lisp

Hi,

I have managed to build interpsys with dlopen in the image.
Next step is to use dlopen, which in fact is the more interesting part.
Has anybody experience with dlopen yet?

Regards

hawkings# /home/hueber/src/axiom--main--1--patch-49/obj/freebsd/bin/interpsys
GCL (GNU Common Lisp)  2.6.7 CLtL1    Aug  3 2006 20:14:50
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE 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.
                        AXIOM Computer Algebra System
                         Version: Axiom (April 2006)
                Timestamp: Friday August 4, 2006 at 08:25:29
-----------------------------------------------------------------------------
   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) -> )lisp (load "syslisp")
symbol "nputs" is not in base image
Value = 376
(1) -> )co syslisp.lsp
   Compiling Lisp source code from file syslisp.lsp
   Issuing )library command for syslisp
   )library cannot find the file syslisp.
(1) -> )lisp (load "syslisp")
symbol "nputs" is not in base image
Value = 376
(1) -> )lisp (|dlopen| "/usr/local/lib/libxslt.so" 1)

Value = 672816128
(1) -> )lisp (|dlopen| "/usr/local/lib/libxslt1.so" 1)

Value = 0
(1) -> )lisp (|dlopen| "/usr/local/lib/libsdpa.a" 1)

Value = 0
(1) -> )q
   Please enter y or yes if you really want to leave the interactive
      environment and return to the operating system:
y
hawkings# more syslisp.lsp
(defentry |dlopen| (string int) (int "dlopen"))
(defentry |nputs| (int string) (int "nputs"))
(defentry |printf| (string) (int "printf"))

\start
Date: 04 Aug 2006 10:43:14 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: Front page esthetic

Dear Bill et al,

I'm not sure whether intentional or not:

* the wiki menu (especially the item "changes") is missing now. I very much
  liked to click on it on the FrontPage, though, and I also think it is
  interesting for people who come by only occasionally.

* The boxes "Download and Try online" now appear nested inside of
  "Documentation". This looks quite weird. (At least on Konqueror 3.1.4, I
  don't have any other browser installed here, unfortunately)

Thanks in any case for your work and your thoughts about fighting spam...

(very sad that this is necessary)

\start
Date: Fri, 4 Aug 2006 10:52:25 +0200
From: Antoine Hersen
To: Martin Rubey
Subject: Re: Front page esthetic

Thank you for the changes.
My minimalist instinc feel better.


> * the wiki menu (especially the item "changes") is missing now. I very
> much
>   liked to click on it on the FrontPage, though, and I also think it is
>   interesting for people who come by only occasionally.


I think you can use the RSS feed.

* The boxes "Download and Try online" now appear nested inside of
>   "Documentation". This looks quite weird. (At least on Konqueror 3.1.4, I
>   don't have any other browser installed here, unfortunately)


Weird it does not show in Safari.

\start
Date: 04 Aug 2006 12:07:13 +0200
From: Martin Rubey
To: Antoine Hersen
Subject: Re: Front page esthetic

Antoine Hersen writes:

> > * the wiki menu (especially the item "changes") is missing now. I very
> > much
> >   liked to click on it on the FrontPage, though, and I also think it is
> >   interesting for people who come by only occasionally.
> 
> I think you can use the RSS feed.

Well, I think the "changes" button should be there. It also gives people a hint
that this is a wiki. 

> * The boxes "Download and Try online" now appear nested inside of
> >   "Documentation". This looks quite weird. (At least on Konqueror 3.1.4, I
> >   don't have any other browser installed here, unfortunately)
> 
> Weird it does not show in Safari.

OK, good to know that this is a browser problem and not intentional.

\start
Date: Fri, 4 Aug 2006 05:19:32 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Some latex packages that may help with multiple individual files in books

There seem to be two main packages for taking complete individual latex
documents and combining them into larger ones (if I've missed an
important one, please let me know)

http://www.tug.org/tex-archive/macros/latex/contrib/combine/

http://www.tug.org/tex-archive/macros/latex/contrib/subfiles/

I'm thinking combine looks like it might be a good fit for the "combine
various pamphlets into a book" question, but I have no experience with
it (yet).  Has anyone here happened to use it?  Does it work fairly
well?

\start
Date: 04 Aug 2006 15:34:38 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: Some latex packages that may help with multiple individual files in books

Cliff Yapp writes:

> I'm thinking combine looks like it might be a good fit for the "combine
> various pamphlets into a book" question, but I have no experience with
> it (yet).  Has anyone here happened to use it?  Does it work fairly
> well?

I did and I was very satisfied.

\start
Date: Fri, 04 Aug 2006 15:39:23 +0200
From: Gernot Hueber
To: list
Subject: Using a shared lib in Axiom

Hi,

see below for results. elf-test and the loader-stuff is based on
gcl-elf-loader (http://www.copyleft.de/Lisp).
System is FreeBSD 5.4, Axiom--main--1-patch-49 and Aldor 1.0.3


Howto:

Maybe not all of my changes are really necessary.
(I use a gcl compiled with dlopen enabled)

1) Generate a gclelf (Makefile of gcl-elf-loader)
Minor changes to the elf-loader.lsp file, due to that defCfun causes a
compile error:

[...]
(defentry cast-obj2int (object) (int cast_obj2int))
;;(defCfun "int cast_obj2int(s) object s;" 0
;;  " return( (int) s->st.st_self);" )
(clines "int cast_obj2int(s) object s; { object *vs=vs_top; object
*old_top=vs_top+0; { return( (int) s->st.st_self); } vs_top=vs; } ")
[...]


2) Adapt lsp/Makefile to build obj/${syslisp}/bin/lisp from gclelf
e.g. for gcl-system:

[...]
        echo '(compiler::link
'"'"'("/home/hueber/src/test/elf-loader.o") "${OUT}/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"))) "${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o
${OBJ}/${SYS}/lib/libspad.a -lc")' | /home/hueber/src/test/gclelf
        ln -fs /usr/local/lib/gcl-2.6.7/h ${MNT}/${SYS}/
[...]

3) use the generation of interpsys proposed by Camm
(http://www.mail-archive.com/gcl-devel@gnu.org/msg00576.html)

[...]
        @ (cd ${OBJ}/${SYS}/bin ; \
          echo '#+native-reloc(progn (gbc t) (setq x
si::*system-directory*)(load "${OUT}/makeint.lisp") (setq
si::*system-directory* x) (unintern (quote x))(gbc t)(user::spad-save
"${SAVESYS}"))#-native-reloc(progn \
                        (setq si::*collect-binary-modules* t)\
                        (setq x si::*system-directory*)\
                        (load "${OUT}/makeint.lisp")\
                        (setq si::*system-directory* x)\
                        (unintern (quote x))\
                        (compiler::link \
                                (remove-duplicates
si::*binary-modules* :test (quote equal))\
                                "$(SAVESYS)" \
                                (format nil "\
                                        (let ((si::*load-path* (cons ~S
si::*load-path*))\
                                              (si::*load-types* ~S))\
                                                (compiler::emit-fn t))\
                                         (setq
si::*collect-binary-modules* t)\
                                  (setq x si::*system-directory*)\
                                         (load \"$(OUT)/makeint.lisp\")\
                                         (setq si::*system-directory*
x)\
                                         (unintern (quote x))\
                                         (when si::*binary-modules* \
                                                (error
si::*binary-modules*))\
                                        (setq
si::collect-binary-modules* nil si::*binary-modules* nil)\
                                        (gbc t)\
                                        (when (fboundp (quote
si::sgc-on)) (si::sgc-on t))\
                                        (setq
compiler::*default-system-p* t)\
                                " si::*system-directory* (quote (list
".lsp")))\                        "$(OBJ)/$(SYS)/lib/sockio-c.o
$(OBJ)/$(SYS)/lib/cfuns-c.o $(OBJ)/$(SYS)/lib/libspad.a" \
                               nil))' | $(LISPSYS))
[...]






hawkings# /home/hueber/src/axiom--main--1--patch-49/mnt/freebsd/bin/AXIOM=
sys
GCL (GNU Common Lisp)  2.6.7 CLtL1    Aug  3 2006 20:14:50
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE 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.
                        AXIOM Computer Algebra System
                         Version: Axiom (April 2006)
                Timestamp: Friday August 4, 2006 at 10:07:45
-------------------------------------------------------------------------=
----
   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) -> )lisp (dyn-cos 1.1)

   >> System error:
   The function DYN-COS is undefined.

(1) -> )lisp (load "elf-test3")
[unknown global sym call_d1d]
Value = 936
(1) -> )lisp (dyn-cos 1.1)

Value = 0.45359612142557731
(1) ->
[...]
(2) -> DYN_-COS(1.0::DoubleFloat)$Lisp

   (2)  0.54030230586813977
                                                            Type:
SExpression
(3) -> DYN_-COS(1.1::DoubleFloat)$Lisp

   (3)  0.45359612142557748
                                                            Type:
SExpression
(4) ->

\start
Date: Fri, 04 Aug 2006 16:43:30 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: source tarballs on MathAction

Hello,

What about adding recent source tarballs on MathAction
(http://wiki.axiom-developer.org/AxiomSources) even for Windows.
If I remember correctly I downloaded the axiom--windows--1 branch, in
the past, from Linux (some difficulties to have a functional tla).

\start
Date: Fri, 4 Aug 2006 10:55:14 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Front page esthetic

Martin,

There was a small coding error on the FrontPage. Some browsers
are more sensitive to these errors than others. It should
be ok now.

For "changes" you should now click "What's New".

Regards,
Bill Page.

On August 4, 2006 4:43 AM Martin Rubey wrote:
> 
> I'm not sure whether intentional or not:
> 
> * the wiki menu (especially the item "changes") is missing 
>   now. I very much liked to click on it on the FrontPage,
>   though, and I also think it is interesting for people who
>   come by only occasionally.
> 
> * The boxes "Download and Try online" now appear nested inside of
>   "Documentation". This looks quite weird. (At least on 
>   Konqueror 3.1.4, I don't have any other browser installed here,
>   unfortunately)
> 
> Thanks in any case for your work and your thoughts about 
> fighting spam...
> 
> (very sad that this is necessary)

\start
Date: Fri, 04 Aug 2006 17:17:57 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Some latex packages that may help with multiple individual files in books

I have once tried "combine". But IIRC it only takes the \usepackage(s) 
from the first file. For the other files \usepackage just absorbs its 
argument and does nothing. So it is not a real solution for me.

When I saw the hyperlink in endpaper.pamhlet that linked to a .dvi file, 
I tried another idea. Basically along the following lines...
Remember I want to combine (crosslink) the documentation of different 
aldor libraries which are each by themselves consisting of several noweb 
files. I think it is doable to compile the first library documentation 
(dvi-1), then use the .aux file from that compilation and use it in the 
compilation of the second library documentation (dvi-2). One would still 
have 2 .dvi files, but if you open dvi-2 and click on a link that refers 
to something in dvi-1, then the dviviewer opens dvi-1 at the right page.
As a user you would not even recognize that these are two files. That 
would be OK for me. And there would be no problem with \usepackage since 
an author could use anything she likes.

Unfortunately, I am not very far with an implementation. What would 
people think about such an approach?

On 08/04/2006 02:19 PM, C Y wrote:
> There seem to be two main packages for taking complete individual latex
> documents and combining them into larger ones (if I've missed an
> important one, please let me know)
> 
> http://www.tug.org/tex-archive/macros/latex/contrib/combine/
> 
> http://www.tug.org/tex-archive/macros/latex/contrib/subfiles/
> 
> I'm thinking combine looks like it might be a good fit for the "combine
> various pamphlets into a book" question, but I have no experience with
> it (yet).  Has anyone here happened to use it?  Does it work fairly
> well?

\start
Date: Fri, 4 Aug 2006 11:37:54 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Some latex packages that may help with multiple individual files in books

look at src/doc/booklet

this file reads chunknames and allows URLs such as

<<file:/home/daly/foo>>

and will insert foo inline.

\start
Date: Fri, 04 Aug 2006 18:22:35 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Front page esthetic

Hi Bill,

First of all, a big THANKS to you.

But may I ask you why there is still a link

"Literate Source"

on the FrontPage? What were your reasons for leaving it just next to 
"Source Code"? I think that is confusing. There should be just ONE link 
to the sources.

If you really want to make it obvious that we have a way to edit a 
branch, then I think a better place is just a statement like

"Browse and edit sources online (see below)"

You could make this a link to the bottom of the page.
In the Section "Testing" I would then add a new subsection "Browse and 
edit sources online". There it should be described how one can 
contribute back and how these changes find their way to Silver and Gold.

Ralf

PS: Comparison, Programming, and Screenshots is wrongly indented on the 
Frontpage.

\start
Date: Fri, 04 Aug 2006 18:29:19 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Front page esthetic

I find it a bit strange to read "Bug Reports" under the heading "Try 
online".

Same for "UnrelatedLinks" appearing under "Related Links". Sorry, but I 
even don't have a better idea. Somebody else perhaps?

\start
Date: Fri, 4 Aug 2006 10:43:57 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Some latex packages that may help with multiple individual files in books

--- Ralf Hemmecke wrote:

> I have once tried "combine". But IIRC it only takes the
> \usepackage(s) from the first file. For the other files \usepackage
> just absorbs its argument and does nothing. So it is not a real
> solution for me.

I think there is a variable to grab additional usepackage commands from
other files, but it's not the default.  I'll look more closely.  Thanks
for the thumbs up on your combine experience Martin, that's good to
hear.

I think I can put together a reasonable test case with the sistyle?
package which formats things according to the NIST formatting rules for
units.  There will be some cases where package load order is important
and we might have to figure out something to take care of that issue,
but I would think it's doable.
 
> When I saw the hyperlink in endpaper.pamhlet that linked to a .dvi
> file, I tried another idea. Basically along the following lines...
> Remember I want to combine (crosslink) the documentation of different
> aldor libraries which are each by themselves consisting of several
> noweb files. I think it is doable to compile the first library
> documentation (dvi-1), then use the .aux file from that compilation
> and use it in the compilation of the second library documentation
> (dvi-2). One would still have 2 .dvi files, but if you open dvi-2 
> and click on a link that refers to something in dvi-1, then the
> dviviewer opens dvi-1 at the right page.
> As a user you would not even recognize that these are two files.
> That would be OK for me. And there would be no problem with
> \usepackage since an author could use anything she likes.

My first question is whether this would work for formats beyond dvi,
such as pdf.  Also, it doesn't seem able to produce a "printable" book
which incorporates the individual files.  For online linking it sounds
interesting.

> Unfortunately, I am not very far with an implementation. What would 
> people think about such an approach?

It sounds interesting, but I think my first instinct is to see if
combine can incorporate "usepackage" commands from mulitple files.

I'm not entirely sure, but I think your idea Ralf and the combine
packages goals are slightly different - combine aimes to produce
something you could bind up and sell as a paper archive of a
conference, and your work enables intelligent hyperlinking between dvi
documents.  Am I not understanding properly?

\start
Date: Fri, 04 Aug 2006 22:45:06 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Some latex packages that may help with multiple individual files in books

What does that have to do with the problem that appears when different 
pamphlet files rely on different and maybe even conflicting latex packages?

For code chunks your URL extension seems to make sense though. But we 
want both, documentation and code.

On 08/04/2006 05:37 PM, root wrote:
> look at src/doc/booklet
> 
> this file reads chunknames and allows URLs such as
> 
> <<file:/home/daly/foo>>
> 
> and will insert foo inline.

\start
Date: Fri, 04 Aug 2006 23:04:35 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Some latex packages that may help with multiple individual files in books

On 08/04/2006 07:43 PM, C Y wrote:
> --- Ralf Hemmecke wrote:
> 
>> I have once tried "combine". But IIRC it only takes the
>> \usepackage(s) from the first file. For the other files \usepackage
>> just absorbs its argument and does nothing. So it is not a real
>> solution for me.

> I think there is a variable to grab additional usepackage commands from
> other files, but it's not the default. 

Oh, that might be true. But what does that help if you want to combine 
pamphlets from different authors who use conflicting latex packages???

>> When I saw the hyperlink in endpaper.pamhlet that linked to a .dvi
>> file, I tried another idea. Basically along the following lines...
>> Remember I want to combine (crosslink) the documentation of different
>> aldor libraries which are each by themselves consisting of several
>> noweb files. I think it is doable to compile the first library
>> documentation (dvi-1), then use the .aux file from that compilation
>> and use it in the compilation of the second library documentation
>> (dvi-2). One would still have 2 .dvi files, but if you open dvi-2 
>> and click on a link that refers to something in dvi-1, then the
>> dviviewer opens dvi-1 at the right page.
>> As a user you would not even recognize that these are two files.
>> That would be OK for me. And there would be no problem with
>> \usepackage since an author could use anything she likes.
> 
> My first question is whether this would work for formats beyond dvi,
> such as pdf.

Should work. I think I have once seen linking from one pdf to another in 
acroread. But I have no explicit running example available. :-( But I 
see no big difference between pdf and dvi.

> Also, it doesn't seem able to produce a "printable" book
> which incorporates the individual files.

What do you actually want? Can't you produce a book which is a 
collection of works? Look at conference proceedings, they do it all the 
time. I don't care so much about a 1000 pages book. If you don't like to 
read stuff online, print it. If you have just 100 pages, it is not so 
heavy. ;-) I care more for the hyperlinks. That also adds some value if 
you really want to find information quickly inside a book.

For example, you take some book and read the word "ring". Tell me in a 
few seconds whether the author speaks of a ring with or without a 1. If 
"ring" is a hyperlink to its definition, that is easy. You don't have to 
browse backwards to find the phrase:

   For this and only this chapter all our rings have a 1.

> I'm not entirely sure, but I think your idea Ralf and the combine
> packages goals are slightly different - combine aimes to produce
> something you could bind up and sell as a paper archive of a
> conference, and your work enables intelligent hyperlinking between dvi
> documents.

Some time ago I looked into combine, but I gave up since one needs to 
make sure that the packages that authors use do not conflict each other.
(Start with the packages verbatim, fancyvrb, moreverb, each of them 
appearing in a \usepackage of a different pamphlet. I have not tested 
whether they are really conflicting, but it pretty much looks like that 
and you surely find other examples.

\start
Date: Fri, 4 Aug 2006 17:00:05 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Some latex packages that may help with multiple individual files in books

> What does that have to do with the problem that appears when different 
> pamphlet files rely on different and maybe even conflicting latex packages?
> 
> For code chunks your URL extension seems to make sense though. But we 
> want both, documentation and code.
> 
> Ralf
> 
> 
> On 08/04/2006 05:37 PM, root wrote:
> > look at src/doc/booklet
> > 
> > this file reads chunknames and allows URLs such as
> > 
> > <<file:/home/daly/foo>>
> > 
> > and will insert foo inline.
> > 
> > t

The booklet program could easily strip the \documentstyle and other
header/trailer information and collect up the \usepackage information.
It's only a simple prototype of the idea intended to allow us to play
with various ways of combining pamphlets into a book form.

\start
Date: Fri, 04 Aug 2006 23:10:55 +0200
From: Frithjof Schulze
To: list
Subject: I would like to work

Hello,

my name is Frithjof Schulze. I'm currently trying to understand Axiom
and am very much interested in computer algebra systems and computer
algebra in general. Though I don't know much yet I'm disposed to learn.
I like Axiom and what you are trying to do (that is the 30 year
horizon), and would like to help you to achieve that goal. Also I think
I will learn pretty much that way.

I have no practical experience in projects much bigger than textbook
exercises let alone open source projects this big. So presumably I can
not do much coding now and will just have lot of questions. Is it OK, if
I ask some of them here?

Still, I'm studying mathematics and already know Common Lisp fairly
well. At some point in the near future I should know enough about the
mathematics and the code to be able to contribute.

What I can do now is this: While reading the Axiom documentation I saw a
lot of stuff that I think I could improve even with my current
knowledge. In particular in volume one of the Axiom-Book, that I think
addresses newbies like myself, I would like too clarify some parts that
weren't clear to me in the beginning. Also I would like to rearrange
some parts, to make the tutorial a better reading. 

Would that be welcomed? If yes, shall I post patches here or directly to
Sourceforge or somewhere else?

\start
Date: Fri, 4 Aug 2006 17:16:52 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Front page esthetic

Ralf,

On August 4, 2006 12:23 PM you wrote:
> ... 
> But may I ask you why there is still a link
> 
> "Literate Source"
> 
> on the FrontPage? What were your reasons for leaving it
> just next to "Source Code"? I think that is confusing.
> There should be just ONE link to the sources.

Maybe you are right. One reason maybe is just a matter of
pride since I still think having the source online as
literate programs is a pretty cool idea and I want people
to be sure to see it. And I do think the whole literate
programming thing is very important to Axiom and we that
we can't really emphasize that too much.

> 
> If you really want to make it obvious that we have a way
> to edit a branch, then I think a better place is just a
> statement like
> 
> "Browse and edit sources online (see below)"
> 
> You could make this a link to the bottom of the page.
> In the Section "Testing" I would then add a new subsection 
> "Browse and edit sources online". There it should be
> described how one can contribute back and how these changes
> find their way to Silver and Gold.
>

All that sounds good to me. Of course one would have to actually
make this work first, I guess. :)

> 
> PS: Comparison, Programming, and Screenshots is wrongly 
> indented on the Frontpage.
> 

Fixed. Thanks.

\start
Date: Fri, 4 Aug 2006 17:15:07 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Front page esthetic

Is it possible to put the tutorial online where it can be edited? --t

\start
Date: Fri, 4 Aug 2006 17:17:43 -0400
From: Tim Daly
To: Frithjof Schulze
Subject: Re: I would like to work

This is the right place.

Feel free to post changes to the tutorial. Beginner's mind eyes are
always welcome.

At the moment, the way to get changes into the main path is to
post patch files. the sequence, for a file Foo, is

cp Foo Foo.org
(edit Foo, save changed file)
diff -Naur Foo.org Foo >Foo.patch
post the patch file

\start
Date: Fri, 04 Aug 2006 23:49:27 +0200
From: Frithjof Schulze
To: Tim Daly
Subject: Re: Front page esthetic 

There is a version online that can be edited. But that seems to be an
much older version than for example the one in the silver branch.

\start
Date: Fri, 4 Aug 2006 18:09:02 -0400
From: Bill Page
To: Tim Daly
Subject: RE: Front page esthetic

On August 4, 2006 5:15 PM

> 
> Is it possible to put the tutorial online where it can be edited?
>

Of course. But which one? And do we have the source somewhere?
Or would someone have to re-key it?

\start
Date: Fri, 4 Aug 2006 19:06:50 -0400
From: Cliff Yapp
To: list
Subject: Re: Some latex packages that may help with multiple

On Friday 04 August 2006 5:04 pm, Ralf Hemmecke wrote:

> > I think there is a variable to grab additional usepackage commands from
> > other files, but it's not the default.
>
> Oh, that might be true. But what does that help if you want to combine
> pamphlets from different authors who use conflicting latex packages???

Obviously, it doesn't.  However, I'm hopeful that such conflicts will either 
be minimal and easily resolved, or we can improve the latex packages 
themselves.

> Should work. I think I have once seen linking from one pdf to another in
> acroread. But I have no explicit running example available. :-( But I
> see no big difference between pdf and dvi.

PDF and Acrobat Reader are common on Windows, DVI is not.  Other than that, I 
would tend to agree.

> > Also, it doesn't seem able to produce a "printable" book
> > which incorporates the individual files.
>
> What do you actually want? Can't you produce a book which is a
> collection of works? Look at conference proceedings, they do it all the
> time.

Indeed, that's the purpose of the combine package, as I understand it.

> I don't care so much about a 1000 pages book. If you don't like to 
> read stuff online, print it. If you have just 100 pages, it is not so
> heavy. ;-) I care more for the hyperlinks. That also adds some value if
> you really want to find information quickly inside a book.

Oh, true.  I am probably more concerned with the idea of a printed set of 
books than most - call it a desire to see the work put into Axiom survive in 
some form even if we lose our current technology levels - "disaster recovery" 
so to speak ;-).  I'm hopeful that the quality of work done on this system 
will be such that it will be worth taking steps to ensure its preservation 
over hundreds or maybe even thousands of years.

> For example, you take some book and read the word "ring". Tell me in a
> few seconds whether the author speaks of a ring with or without a 1. If
> "ring" is a hyperlink to its definition, that is easy. You don't have to
> browse backwards to find the phrase:

Oh, no question online is better for quick work like that.

> Some time ago I looked into combine, but I gave up since one needs to
> make sure that the packages that authors use do not conflict each other.

Yes, that's an ongoing issue with LaTeX.  However, it might be regarded as 
bugs to be fixed, as much as anything else.

> (Start with the packages verbatim, fancyvrb, moreverb, each of them
> appearing in a \usepackage of a different pamphlet. I have not tested
> whether they are really conflicting, but it pretty much looks like that
> and you surely find other examples.

Yes.  But it would be a benefit both to Axiom and to the wider LaTeX community 
to have such issues addressed.

\start
Date: Fri, 4 Aug 2006 19:19:24 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Front page esthetic

src/doc/bookvol1.pamphlet

\start
Date: Fri, 4 Aug 2006 20:14:10 -0400
From: Tim Daly
To: list
Subject: vacation

I'm going away on vacation for a week, sunday to sunday,
and won't have net access (New Jersey is still in the
dark ages wrt internet). I hope to make great strides on
Axiom, cause isn't that what vacation is for? :-)

\start
Date: Fri, 4 Aug 2006 22:27:12 -0400
From: Bill Page
To: Tim Daly
Subject: axiom tutorial online

Tim,

> 
> On August 4, 2006 5:15 PM you wrote:
> > 
> > Is it possible to put the tutorial online where it can be
> > edited?
> >

On August 4, 2006 6:09 PM Bill Page wrote
> 
> Of course. But which one? And do we have the source somewhere?
> Or would someone have to re-key it?
> 

On August 4, 2006 7:19 PM you wrote:
> 
> src/doc/bookvol1.pamphlet
> 

Oh, that tutorial! :)

But ???

All of the original book volumes have been online and on the Axiom
Wiki as editable pamphlet files since about October last year when
I first implemented pamphlet file support on MathAction.

See:

http://wiki.axiom-developer.org/book--main--1

Volume 1 is here:

http://wiki.axiom-developer.org/book--main--1/Bookvol1

The most recent comment was by Frithjof Schulze just yesterday.
He wrote:

Working drafts ? --Frithjof Schulze, Thu, 03 Aug 2006 08:58:37

On ../AxiomDocumentation it says that this are working drafts.
Doesn't that mean that it are the newest versions? I was reading
the tutorial and thought about changing some things. Later I saw
that in Axiom Silver there is a newer and better version of the
tutorial. Does it make any sense to work on this one?

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

Unfortunately it seems that no one beside me was subscribed to
to the book--main--1 wiki page.

Apparently it has not been kept up to date with the version in
the source distribution. :(

But perhaps you will recall that work I did with

http://wiki.axiom-developer.org/book--main--1/Endpaper3

involving GraphViz with hyperref links to the source?

----------

I thought you meant something like the tutorial that was done by
NAG in Texplorer. I remember now that way back in the early days
I did prepare a TeXmacs version of that tutorial by importing the
original tex source and then editing back in the actual Axiom
commands.

http://savannah.nongnu.org/download/axiom/tutorial.tgz.gz

The pdf version of this tutorial is here:

http://download.savannah.gnu.org/releases/axiom/tutorial.pdf

I think it could be easily adapted for use as a set of easialy
updated tutorial web pages on the wiki.

\start
Date: Fri, 4 Aug 2006 22:40:22 -0400
From: Bill Page
To: Tim Daly, Frithjof Schulze
Subject: RE: I would like to work

Tim,

On August 4, 2006 5:11 PM Frithjof Schulze wrote:
> ... 
> What I can do now is this: While reading the Axiom 
> documentation I saw a lot of stuff that I think I could
> improve even with my current knowledge. In particular in
> volume one of the Axiom-Book, that I think addresses newbies
> like myself, I would like too clarify some parts that
> weren't clear to me in the beginning. Also I would like to
> rearrange some parts, to make the tutorial a better reading. 
> 
> Would that be welcomed? If yes, shall I post patches here or 
> directly to Sourceforge or somewhere else?
> 

On August 4, 2006 5:18 PM you wrote:

> 
> This is the right place.
> 
> Feel free to post changes to the tutorial. Beginner's mind
> eyes are always welcome.
> 
> At the moment, the way to get changes into the main path is to
> post patch files. the sequence, for a file Foo, is
> 
> cp Foo Foo.org
> (edit Foo, save changed file)
> diff -Naur Foo.org Foo >Foo.patch
> post the patch file
> 

I guess we really do live in different worlds, don't we ... :(
See my previous email about the 

http://wiki.axiom-developer.org/book--main--1

pamphlet files. All of these volumes can be updated directly through
the web. We can create diffs of these against the versions in the
current source distribution and vice versa. Maybe we could even
hack together a good way to make periodic automatic commits from
one to the other.

Right now the version on the web is about 9 months old and was
based on the tla archive by the same name. I don't know the status
of that archive relative to the versions of similar files in the
axiom--main--1 source distribution.

I guess we should make some kind of effort to coordinate this
and make sure everything is upto date and in sync before deciding
how best to proceed with large scale edits. No?

\start
Date: Fri, 04 Aug 2006 22:09:09 -0500
From: Jay Belanger
To: list
Subject: Re: Front page esthetic

Gabriel Dos Reis writes:

> Bill Page writes:
...
> | 2) The Axiom Wiki FrontPage has more graphics including an example
> |    Axiom output graphic.
>
> That, from my perspective, contributes to the "visual load".

I agree with this, but what's more, I don't think that linking "Try
Axiom" to the SandBox is that helpful.  If a visitor to the webpage
wants to give Axiom a quick try, sending them to a lengthy discussion
of the sandbox might be discouraging.  Perhaps a link to a
"TryingAxiom" page which has a couple of lines of how to try it out
might be helpful.  I'd be happy to give it a shot myself, if desired.

Also, I don't think it's necessary (or even desirable) to keep all the
old tried-out commands in the wiki.  I think a link to a page which
interactively runs Axiom would be more desirable: Yacas has something
like that (Yacas runs in a Java applet: 
http://yacas.sourceforge.net/yacasconsole.html)  and Maxima does also
(http://math.msarnoff.org/).

By the way, I'm entering the discussion late.  I don't recall what the
front page looked like, but I recall thinking it looked a bit
unfriendly.  (Of course, my memory may be wrong.)  Now I think it
looks great!

\start
Date: Fri, 4 Aug 2006 23:34:05 -0400
From: Bill Page
To: Jay Belanger
Subject: RE: Front page esthetic

On August 4, 2006 11:09 PM Jay Belanger wrote:
> 
> Gabriel Dos Reis writes:
> 
> > "Bill Page" writes:
> ...
> > | 2) The Axiom Wiki FrontPage has more graphics including an
> > |    example Axiom output graphic.
> >
> > That, from my perspective, contributes to the "visual load".
> 
> I agree with this,

:( Well, I really like the example ... in fact I have even given
a wild thought to how we might make the from page choose randomly
between a large set of similar examples so that a visitor might
be treated to a new one at each visit ...

I still don't know what is meant by the phrase "visual load".

> but what's more, I don't think that linking "Try Axiom" to the
> SandBox is that helpful.

Really??! As far as I can see this is actually one of the most
frequently used wiki features of this web site.

> If a visitor to the webpage wants to give Axiom a quick try,
> sending them to a lengthy discussion of the sandbox might be
> discouraging.

Perhaps it is verbose but it does not seem to be very discouraging
given the number of quick tries that we record.

> Perhaps a link to a "Trying Axiom" page which has a couple of
> lines of how to try it out might be helpful.  I'd be happy to
> give it a shot myself, if desired.

Yes, I think it is very desirable. Please give it a try.

> 
> Also, I don't think it's necessary (or even desirable) to keep
> all the old tried-out commands in the wiki.

That's true. Anytime anyone feels like cleaning up all the crap
they are certainly welcome to do it. :) But every once in a while
there seems to be something very useful that can be easily
generalized and made useful for other people. That is what wikis
are for. I keep getting this sinking feeling that almost no one
hear on this list understands anything about wikiwiki. :(

> I think a link to a page which interactively runs Axiom would
> be more desirable: Yacas has something
> like that (Yacas runs in a Java applet: 
> http://yacas.sourceforge.net/yacasconsole.html)
>  and Maxima does also (http://math.msarnoff.org/).

To me these interfaces seem trivial and nearly useless. But if we
really do want something like this then it is easily done.

> 
> By the way, I'm entering the discussion late.

I am glad you are here. Your comments are very much appreciated.

> I don't recall what the front page looked like, but I recall
> thinking it looked a bit unfriendly.  (Of course, my memory
> may be wrong.)  Now I think it looks great!
> 

Yes, it has gone through quite a few revisions over the last
6 months and it is still evolving. It is a community effort.

\start
Date: Fri, 4 Aug 2006 23:54:00 -0400
From: Tim Daly
To: Alfredo Portes
Subject: Re: Doyen Wiki

Jose,

I've been chasing a couple pointers to try to look at the drag-and-drop
issue in Doyen. These are the big five:

First, javascript has a drag-and-drop set of events, ondrag, ondragstart,
ondragend, ondragenter, ondragleave, and ondragover. These allow javascript
code to know where the user starts and ends a drag.

Second, javascript can get at the clipboarddata allowing us to pass data
to the browser thru the clipboard.

Both of those are covered in the JavaScript Bible by Danny Goodman

Third, firefox allows you to code extensions in javascript. Extensions
are local and are allowed to read/write the file system, etc. The game
is to create a directory structure containing your code, zip it up,
and put it in the chrome subdirectory. A tutorial example is at:
  http://daly.axiom-developer.org/firefox.tgz

Fourth, a more detailed example of a working extension is at:
  http://daly.axiom-developer.org/dbx.tgz

Fifth, the XMLHttpRequest object is a javascript object that allows
you to construct an XML request without leaving the page. You store
data in the object, invoke the send method, and then go thru a 5-state
machine to get the information back. If Axiom is set up to listen for
the requests then Axiom can sit behind the browser and service requests
to d anything, like start graphics independently or start graphics and
store the resulting image and forward it to the browser for inlining.

So the game is to pick on a literate document, drag it onto the browser,
fire up a firefox extension to read the clipboard, write the file into
the appropriate place, and then talk to axiom to compile and load the
file and build the documentation. I know this can be done but everything
is moving at a glacial pace due to multitasking.

I'm going on vacation next week and I'll try to get an example working
if time permits (which it never does).

\start
Date: Sat, 5 Aug 2006 00:13:58 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Translation of the interp to lisp

> 2.  I noticed a lot of implementation specific code having to do with
> things like (system:getenv $AXIOM) - is the plan to write some generic
> macros to handle these operations and get all of the implementation
> specific logic into one file?

Any luck identifying GCL-specific code and writing "generic macros"?

\start
Date: Sat, 5 Aug 2006 00:17:13 -0400
From: Tim Daly
To: Jason Allen
Subject: Re: axiom entry
Cc: Scott Collison

> Moving forward, could you please let me know whether you'd prefer we  
> never list Axiom again or wait until we have your new and updated  
> project's information? I would be happy to give you a preview of the  
> new info before publishing it (you could change your mind at any point).
> 
> Ohloh is a young service with kinks to iron out. I would like the  
> opportunity to work through them with your cooperation. However, I  
> respect your perspective and will adhere to your preference.

I understand "swamped with work" as I'm just now getting a chance to
reply to week-old emails.

I don't have any objection to having Axiom listed on your site
but it is important that the information be at least semi-correct.
Google has a way of preserving both good and bad information and
it hurts the Axiom project to list it as "unchanged for 2 years".

Please list us but please take the time to get it right.

\start
Date: Sat, 5 Aug 2006 00:34:01 -0400
From: Tim Daly
To: William Stein
Subject: download SAGE

I just saw your request at the bottom of your homepage 
for people to send you a note about downloading SAGE.

I've downloaded it twice so far. I was part of the team
that built the DVDs for the ISSAC 2006 conference proceedings
and I included a copy of SAGE on them.

I've also downloaded it today to look at the issue of 
adding Axiom to your list of available system.

I'd suggest you take a look at the Doyen project, outlined here:

   http://daly.axiom-developer.org/doyen
   http://wiki.axiom-developer.org/Doyen
   http://sourceforge.net/projects/doyencd


The basic idea is that technical papers are written in a literate
style that includes both latex and source code (using noweb, a
derivative of Knuth's Web idea).

Doyen will integrate a browser, a wiki, and several CA systems.
We're investigating the ability to drag-and-drop a literate
research paper onto the browser, have it automatically unpacked,
compiled, added to the system along with its documentation.
We hope to demonstrate this ability at the next ISSAC conference.

It might be interesting to put the SAGE technology behind the
browser and have Axiom as one of the back-end components.

\start
Date: Sat, 5 Aug 2006 01:13:29 -0400
From: Tim Daly
To: Marc Moreno Maza, Xin Li
Subject: Re: code

Marc, 

Sorry for the delay but I had to catch up on the weeks worth of work
that I didn't do at ISSAC. I have the files and will look at integrating
them into Axiom. 

\start
Date: Sat, 5 Aug 2006 01:14:37 -0400
From: Tim Daly
To: Marc Moreno Maza, Xin Li
Subject: Re: code

Marc, 

> Could you please semd me pointers or slides for the AXIOM
> talk at ICMS 06?

I copied the mailing list since I have no idea about an ICMS talk.
Did you ever get a reply to this request? 

\start
Date: Sat, 5 Aug 2006 01:18:30 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

> | patched. fixed in the next release. --t
> | 
> | (no, i still don't have SVN working. there is no time)
> 
> Then, please could send a patch to the list?  

I now have a working subversion and will look at keeping silver
up to date with patches (but not testing it thoroughly due to time)

\start
Date: Sat, 5 Aug 2006 01:43:56 -0400
From: Tim Daly
To: Frithjof Schulze
Subject: Re: Front page esthetic

I've asked Bill Page to put the tutorial up on the wiki.
It should be possible to edit it there.
If you manage to change it there you'll be the first to try
the idea of maintaining the sources directly from the wiki
rather than from a CVS/TLA/SVN/DARCS pile.

\start
Date: Sat, 05 Aug 2006 12:11:20 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: I would like to work

> See my previous email about the 
> 
> http://wiki.axiom-developer.org/book--main--1
> 
> pamphlet files. All of these volumes can be updated directly through
> the web. We can create diffs of these against the versions in the
> current source distribution and vice versa. Maybe we could even
> hack together a good way to make periodic automatic commits from
> one to the other.
> 
> Right now the version on the web is about 9 months old and was
> based on the tla archive by the same name. I don't know the status
> of that archive relative to the versions of similar files in the
> axiom--main--1 source distribution.
> 
> I guess we should make some kind of effort to coordinate this
> and make sure everything is upto date and in sync before deciding
> how best to proceed with large scale edits. No?

Yes. Now we have Gold=stable, Silver=unstable, and several testing 
branches. See http://wiki.axiom-developer.org/AxiomSources .
The tutorial should be edited on one of the testing branches (either on
http://wiki.axiom-developer.org/axiom--test--1/ or on a specially 
created branch on SVN).

I must say, I would like to see axiom--test--1 kept in sync with a 
branch on our sourceforge archive. I have no idea whether that is easy 
to achive, but it would avoid questions like "Where is the most 
up-to-date source that I should edit?".

The tla branch book--main--1 on http://axiom-developer.org/archive/axiom 
should be merged to the testing branch on SVN and then *REMOVED*.
Look at book--main--1. It does not contain the other axiom sources and 
when I first found out, I was confused about the 
src/doc/bookvol1.pamphlet appearing in axiom--main--1 and the same file 
in book--main--1. Cannot we just have book-main--1 in a subdirectory of 
the ordinary Axiom/Gold/Silver/Testing? Nobody cares if the other 
volumes are not yet written, but it would be easier to know where to 
edit. And merging would proably also be easier.

Any other opinions about this?

We currently have more branches of Axiom than we have developers. And 
even worse, all these branches are quite badly documented what they are 
worth for.

\start
Date: Sat, 05 Aug 2006 12:38:22 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Some latex packages that may help with multiple individual files in books

>> Oh, that might be true. But what does that help if you want to combine
>> pamphlets from different authors who use conflicting latex packages???

> Obviously, it doesn't.  However, I'm hopeful that such conflicts will either 
> be minimal and easily resolved, or we can improve the latex packages 
> themselves.

1) If you need to edit the pamphlet files to make them work in the 
context of a big book. That sounds as if you have too much time to spare.

2) Where are our priorities? Improving LaTeX or improving computational 
mathematics?

I could imagine to impose restrictions on the LaTeX packages that are 
approved be used inside an Axiom pamphlet. But do you know all the LaTeX 
packages and the preferences of authors that you feel able to decide 
which package to allow and which package to forbid? I don't.

>> Some time ago I looked into combine, but I gave up since one needs to
>> make sure that the packages that authors use do not conflict each other.
> 
> Yes, that's an ongoing issue with LaTeX.  However, it might be regarded as 
> bugs to be fixed, as much as anything else.

Hmm, yes, you could call it a bug. In fact, I know LaTeX not well enough 
to understand why it is so difficult to set up a wrapper file around a 
collection of latex files so that each file would appear (nearly) 
identical to the way it would appear as dvi when compiled separately.
The collection should, of course produce running page numbers.

And what I want is that links would be allowed between the parts. These 
links forbid an implementation that puts each part of the collection 
into a separate box, since there must be "communication" between them. 
So basically, it calls for a nicely defined API.

What I don't believe is that you can convince package authors to take 
every effort to keep their package compatible with any other package out 
there. Some people just write a package because they need it for their 
work and then suddenly it becomes useful for others. The was probably 
only a question that the package need to be compatible with packages 
that the original author used.

\start
Date: Sat, 5 Aug 2006 12:57:13 +0200
From: Antoine Hersen
To: Ralf Hemmecke
Subject: Re: I would like to work

> > I guess we should make some kind of effort to coordinate this
> > and make sure everything is upto date and in sync before deciding
> > how best to proceed with large scale edits. No?
>
> Yes. Now we have Gold=stable, Silver=unstable, and several testing
> branches. See http://wiki.axiom-developer.org/AxiomSources .
> The tutorial should be edited on one of the testing branches (either on
> http://wiki.axiom-developer.org/axiom--test--1/ or on a specially
> created branch on SVN).


To honor the spirit of competition I have decided to create a Bronze branch.
The Bronze branch will collect all code deleted or modified from the Gold
and Silver branch plus original addition.
The intent is to have a more lively version of Axiom away from all the
restriction of cold mathematical logic.

I must say, I would like to see axiom--test--1 kept in sync with a
> branch on our sourceforge archive. I have no idea whether that is easy
> to achive, but it would avoid questions like "Where is the most
> up-to-date source that I should edit?".


That is one of the main advantage of the Bronze branch no need to stay in
sync it will have is own rhythm.

The tla branch book--main--1 on http://axiom-developer.org/archive/axiom
> should be merged to the testing branch on SVN and then *REMOVED*.
> Look at book--main--1. It does not contain the other axiom sources and
> when I first found out, I was confused about the
> src/doc/bookvol1.pamphlet appearing in axiom--main--1 and the same file
> in book--main--1. Cannot we just have book-main--1 in a subdirectory of
> the ordinary Axiom/Gold/Silver/Testing? Nobody cares if the other
> volumes are not yet written, but it would be easier to know where to
> edit. And merging would proably also be easier.
>
> Any other opinions about this?


I think the solution is more SCM therefore the bronze branch will use  Linux
last creation git (
http://www.netfort.gr.jp/~dancer/column/200504-git.html.en )
If it is good for the kernel it is good for axiom.

We currently have more branches of Axiom than we have developers. And
> even worse, all these branches are quite badly documented what they are
> worth for.


The problem is not has much as the number of branch is that they are all
over the place.

Could we all agree to use only one SCM at least.
I will advocate for SVN has I am so far quite pleased with it. Also SVK make
it possible for people who work of line to do so easly.

The biggest advande I see is that all work will be visible for everybody.
And we should be able to use well understood concept of branching and
tagging to make release a clear and manageable process.

The online literate version of Axiom will just be one branch and even maybe
one should be able to choose wich version/branche to be use.

Also SVN is surely on his way to remplace CVS and therefore offer us a large
choice of project host if needed.

SVN work on all system *nix/Win/Mac

What do you think ?

\start
Date: Sat, 05 Aug 2006 13:10:23 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Front page esthetic

On 08/04/2006 11:16 PM, Bill Page wrote:
> Ralf,
> 
> On August 4, 2006 12:23 PM you wrote:
>> ... 
>> But may I ask you why there is still a link
>>
>> "Literate Source"
>>
>> on the FrontPage? What were your reasons for leaving it
>> just next to "Source Code"? I think that is confusing.
>> There should be just ONE link to the sources.

> Maybe you are right. One reason maybe is just a matter of
> pride since I still think having the source online as
> literate programs is a pretty cool idea and I want people
> to be sure to see it. And I do think the whole literate
> programming thing is very important to Axiom and we that
> we can't really emphasize that too much.

I guessed that this was your thought, but I could only guess that 
because meanwhile I know a bit about the internals of Axiom.

>> If you really want to make it obvious that we have a way
>> to edit a branch, then I think a better place is just a
>> statement like
>>
>> "Browse and edit sources online (see below)"
>>
>> You could make this a link to the bottom of the page.
>> In the Section "Testing" I would then add a new subsection 
>> "Browse and edit sources online". There it should be
>> described how one can contribute back and how these changes
>> find their way to Silver and Gold.

> All that sounds good to me. Of course one would have to actually
> make this work first, I guess. :)

I could edit the AxiomSources page with a prominent link to the literate 
sources at the top. In fact, you are right, the AxiomSources page should 
at least give a link to an explanation about what a *pamphlet* is or 
even contain a few words about pamplets itself.

But you should somehow think about how the modifications could be made 
in sync with an SVN branch. Or at least explain how that axiom--test--1 
is related to at least silver/trunk. I think axiom--test--1 should have 
ALL the patches of silver/trunk. Is that easily possible to achieve?

Is it possible to write an explanation how to browse and edit the 
sources and how and when the will be integrated into the Gold release.
It should even be said what will happen to modifications that are not 
approved. Anyway, I would feel better if the sources can only be edited 
by registed people, but maybe that is not yet an issue.

Bill, on http://wiki.axiom-developer.org/axiom--test--1/src I see

___New Page___ [Create this page]

and a "folder" icon in front of it. So it seems I can create a folder, 
but not a file. But the text tells me I can create neither. It says, 
that I can create a page. Hmmmm, I find this confusing. Should there be 
two buttons to create a file and to create a directory? And it should be 
written somewhere that in the Wiki context page and pamphlet file is the 
same.

Oh, and I clicked onto [create this page]. Why does there pop up a 
password window?

\start
Date: 05 Aug 2006 13:45:47 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Tim Daly writes:

| > | patched. fixed in the next release. --t
| > | 
| > | (no, i still don't have SVN working. there is no time)
| > 
| > Then, please could send a patch to the list?  
| 
| 
| I now have a working subversion and will look at keeping silver
| up to date with patches (but not testing it thoroughly due to time)

That is great!  

Please, also send them to the list.

\start
Date: 05 Aug 2006 14:26:47 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Toplevel Makefile.dvi

  The toplevel Makefile.dvi gets copied in the installation directory
twice:

     * once at part of 

   all: noweb ${MNT}/${SYS}/bin/Makefile.pamphlet
           @ echo 1 making a ${SYS} system, PART=${PART}
           SUBPART=${SUBPART}
           @ echo 2 Environment ${ENV}
           @ ${TANGLE} -t8 -RMakefile.${SYS} Makefile.pamphlet
           >Makefile.${SYS}
           @ ${DOCUMENT} Makefile
           @ mkdir -p ${MNT}/${SYS}/doc/src
           @ cp Makefile.dvi ${MNT}/${SYS}/doc/src/root.Makefile.dvi
           @ ${ENV} $(MAKE) -f Makefile.${SYS} 
           @echo 3 finished system build on `date` | tee >lastBuildDate


     * a second time, right after "making" the lsp directory

   <<LSPMakefile>>=
   ${LSP}/Makefile: ${LSP}/Makefile.pamphlet
           @echo 20 making ${LSP}/Makefile from ${LSP}/Makefile.pamphlet
           @( cd lsp ; \
            ${DOCUMENT} ${NOISE} Makefile ; \
            if [ "${GCLVERSION}" != "gcl-2.4.1" ] ; then \
            ${TANGLE} -t8 -R"${GCLVERSION}" Makefile.pamphlet >Makefile ; \
            fi )
           @cp Makefile.dvi ${MNT}/${SYS}/doc/src

\start
Date: Sat, 05 Aug 2006 15:30:08 +0200
From: Frithjof Schulze
To: list
Subject: patches

here are some minor modifications of bookvol1 and ComputerTutorial.

In bookvol1 there were two nearly identical sections about the "%"
macro. I removed one and moved a short explanation to the place "%" is
used the first time.

In ComputerTutorial I changed all occurences of "\<\<" in verbatim
environments into "<<" as (at least my) latex dosn't execute the
command there. I also added ComputerTutorial to the Makefile.phamphlet.

There is more duplication in the tutorial. I found that
distracting. Reading something I had already read, I got bored, started
to skip sections and finally was out of it. I would like to splice those
sections in where they belong or remove them. Is that an acceptable
policy?

--- bookvol1.org.pamphlet	2006-08-02 14:16:49.000000000 +0200
+++ bookvol1.pamphlet	2006-08-05 01:59:19.734104296 +0200
@@ -421,6 +421,11 @@
 \end{array}
 \right]
 $$
+
+Note the use of ``\%'' here. This means the value of the last
+expression we computed. In this case it is the matrix we defined
+above.
+
 \returnType{Type: Union(Matrix Fraction Polynomial Complex Integer,...)}
 
 \subsection{HyperDoc}
@@ -645,10 +650,8 @@
 $$
 \returnType{Type: Expression Integer}
 
-\index{\%}
-Note the use of ``\%'' here. This means the value of the last
-expression we computed. In this case it is the long expression
-above. 
+Here again we use ''\%'' for the last result, that is the long expression
+above.
 
 \subsection{Pattern Matching}
 
@@ -1358,46 +1361,6 @@
 $$
 \returnType{Type: Fraction Integer}
 
-\subsection{Previous Results}
-\label{sec:Previous Results}
-\index{\%}
-\index{\%\%}
-Use the percent sign ``{\tt \%}'' to refer to the last result.
-\index{result!previous} Also, use ``{\tt \%\%}' to refer to
-previous results.  \index{percentpercent@{\%\%}} ``{\tt \%\%(-1)}'' is
-equivalent to ``{\tt \%}'', ``{\tt \%\%(-2)}'' returns the next to
-the last result, and so on.  ``{\tt \%\%(1)}'' returns the result from
-step number 1, ``{\tt \%\%(2)}'' returns the result from step number 2,
-and so on.  ``{\tt \%\%(0)}'' is not defined.
-
-This is ten to the tenth power.
-\spadcommand{10 ** 10}
-$$
-10000000000 
-$$
-\returnType{Type: PositiveInteger}
-
-This is the last result minus one.
-\spadcommand{\% - 1}
-$$
-9999999999 
-$$
-\returnType{Type: PositiveInteger}
-
-This is the last result.
-\spadcommand{\%\%(-1)}
-$$
-9999999999 
-$$
-\returnType{Type: PositiveInteger}
-
-This is the result from step number 1.
-\spadcommand{\%\%(1)}
-$$
-10000000000 
-$$
-\returnType{Type: PositiveInteger}
-
 \subsection{Some Types}
 \label{sec:Some Types}
 Everything in Axiom has a type.  The type determines what operations
@@ -1841,8 +1804,7 @@
 $$
 \returnType{Type: Fraction Integer}
 
-\index{\%}
-where ``\%'' represents the previous {\it result} (not the calculation).
+where again ``\%'' represents the previous {\it result} (not the calculation).
 
 Although Axiom has the ability to work with floating-point numbers to
 a very high precision it must be remembered that calculations with these
@@ -2472,16 +2434,52 @@
 \returnType{Type: PositiveInteger}
 
 \subsection{Accessing Earlier Results}
+\label{sec:Accesing Earlier Results}
 \index{\%}
 \index{\%\%}
+\index{percent@{\%}}
+\index{percentpercent@{\%\%}}
+
 The ``\%'' macro represents the result of the previous computation. The 
 ``\%\%'' macro is available which takes a single integer argument. If the
 argument is positive then it refers to the step number of the calculation
 where the numbering begins from one and can be seen at the end of each
 prompt (the number in parentheses). If the argument is negative then it
-refers to previous results counting backwards from the last result. That is,
-``\%\%(-1)'' is the same as ``\%''. The value of ``\%\%(0)'' is not defined and
-will generate an error if requested.
+refers to previous results counting backwards from the last result. 
+
+That is,``{\tt \%\%(-1)}'' is equivalent to ``{\tt \%}'', 
+``{\tt\%\%(-2)}'' returns the next to the last result, and so on.  
+``{\tt\%\%(1)}'' returns the result from step number 1, ``{\tt \%\%(2)}''
+returns the result from step number 2, and so on. The value of
+``\%\%(0)'' is not defined and will generate an error if requested.
+
+This is ten to the tenth power.
+\spadcommand{10 ** 10}
+$$
+10000000000 
+$$
+\returnType{Type: PositiveInteger}
+
+This is the last result minus one.
+\spadcommand{\% - 1}
+$$
+9999999999 
+$$
+\returnType{Type: PositiveInteger}
+
+This is the last result.
+\spadcommand{\%\%(-1)}
+$$
+9999999999 
+$$
+\returnType{Type: PositiveInteger}
+
+This is the result from step number 1.
+\spadcommand{\%\%(1)}
+$$
+10000000000 
+$$
+\returnType{Type: PositiveInteger}
 
 \subsection{Splitting Expressions Over Several Lines}
 Although Axiom will quite happily accept expressions that are longer than

--=-=-=
  filename=ComputerTutorial.pamphlet.patch

--- ComputerTutorial.org.pamphlet	2006-08-05 02:31:26.139246200 +0200
+++ ComputerTutorial.pamphlet	2006-08-05 02:28:39.053647072 +0200
@@ -151,7 +151,7 @@
 \begin{small}
 \begin{verbatim}
        #include "axllib"
-       print \<\< "hello, world" \<\< newline;
+       print << "hello, world" << newline;
 \end{verbatim}
 \end{small}
 
@@ -197,9 +197,9 @@
 }
 
 import from SingleInteger;
-print \<\< signum 10 \<\< newline;
-print \<\< signum 0  \<\< newline;
-print \<\< signum(-10) \<\< newline;
+print << signum 10 << newline;
+print << signum 0  << newline;
+print << signum(-10) << newline;
 \end{verbatim}
 \end{small}
 
@@ -307,7 +307,7 @@
 
 \begin{small}
 \begin{verbatim}
-  (stream: TextWriter) \<\< (thing: String): TextWriter ==
+  (stream: TextWriter) << (thing: String): TextWriter ==
 \end{verbatim}
 \end{small}
 
@@ -321,7 +321,7 @@
 
 \begin{small}
 \begin{verbatim}
- print \<\< "first thing" \<\< "second thing" \<\< ... \<\< newline;
+ print << "first thing" << "second thing" << ... << newline;
 \end{verbatim}
 \end{small}
 
@@ -329,7 +329,7 @@
 
 \begin{small}
 \begin{verbatim}
- ((((print \<\< "first thing") \<\< "second thing") \<\< ...) \<\< newline);
+ ((((print << "first thing") << "second thing") << ...) << newline);
 \end{verbatim}
 \end{small}
 
@@ -360,9 +360,9 @@
 
 \begin{small}
 \begin{verbatim}
-  print \<\< signum(10) \<\< newline;
-  print \<\< signum(0) \<\< newline;
-  print \<\< signum(-10) \<\< newline;
+  print << signum(10) << newline;
+  print << signum(0) << newline;
+  print << signum(-10) << newline;
 \end{verbatim}
 \end{small}
 
@@ -398,9 +398,9 @@
 
 import from SingleInteger;
 import from Properties;
-print \<\< signum(10) \<\< newline;
-print \<\< signum(0) \<\< newline;
-print \<\< signum(-10) \<\< newline;
+print << signum(10) << newline;
+print << signum(0) << newline;
+print << signum(-10) << newline;
 
 \end{verbatim}
 \end{small}
@@ -813,7 +813,7 @@
 
 \begin{small}
 \begin{verbatim}
-  print \<\< new(10, char "x")
+  print << new(10, char "x")
 \end{verbatim}
 \end{small}
 
@@ -831,7 +831,7 @@
  
 \begin{small}
 \begin{verbatim}
- \<\<: (TextWriter, %) -> TextWriter;
+ <<: (TextWriter, %) -> TextWriter;
 \end{verbatim}
 \end{small}
 
@@ -847,10 +847,10 @@
 
 \begin{small}
 \begin{verbatim}
-  (port: TextWriter) \<\< (term1: %): TextWriter == {
-           port \<\< rep(term1).coef;
-           port \<\< "*";
-           port \<\< rep(term1).var
+  (port: TextWriter) << (term1: %): TextWriter == {
+           port << rep(term1).coef;
+           port << "*";
+           port << rep(term1).var
    }
 \end{verbatim}
 \end{small}
@@ -886,7 +886,7 @@
 
 \begin{small}
 \begin{verbatim}
-  port \<\< rep(term1).coef;
+  port << rep(term1).coef;
 \end{verbatim}
 \end{small}
 
@@ -895,7 +895,7 @@
 
 \begin{small}
 \begin{verbatim}
-  \<\<: (TextWriter, SingleInteger) -> TextWriter
+  <<: (TextWriter, SingleInteger) -> TextWriter
 \end{verbatim}
 \end{small}
 
@@ -913,7 +913,7 @@
  
 \begin{small}
 \begin{verbatim}
- \<\<: (TextWriter, String) -> TextWriter
+ <<: (TextWriter, String) -> TextWriter
 \end{verbatim}
 \end{small}
 
@@ -949,7 +949,7 @@
 
 \begin{small}
 \begin{verbatim}
-  port \<\< rep(term1).var;
+  port << rep(term1).var;
 \end{verbatim}
 \end{small}
 
@@ -958,7 +958,7 @@
 
 \begin{small}
 \begin{verbatim}
-  \<\<: (TextWriter, Character) -> TextWriter
+  <<: (TextWriter, Character) -> TextWriter
 \end{verbatim}
 \end{small}
 
@@ -1097,7 +1097,7 @@
 Term: with {
         new: (SingleInteger, Character) -> %;
         dispose!: % -> ();
-        \<\<: (TextWriter, %) -> TextWriter;
+        <<: (TextWriter, %) -> TextWriter;
         coef: % -> SingleInteger;
         var:  % -> Character;
  }
@@ -1111,9 +1111,9 @@
         dispose!(ignore: %):() == {}
 
         (port: TextWriter) \<\< (term1: %): TextWriter == {
-                port \<\< rep(term1).coef;
-                port \<\< "*";
-                port \<\< rep(term1).var
+                port << rep(term1).coef;
+                port << "*";
+                port << rep(term1).var
         }
 
         coef(term: %): SingleInteger == rep(term).coef;
@@ -1125,9 +1125,9 @@
 import from Character;
 import from Term;
 term1 := new(3, char "x");
-print \<\< term1 \<\< newline;
-print \<\< coef term1 \<\< newline;
-print \<\< var term1 \<\< newline;
+print << term1 << newline;
+print << coef term1 << newline;
+print << var term1 << newline;
 dispose! term1;
 
 \end{verbatim}
@@ -1260,14 +1260,14 @@
 define BasicType: Category == with {
         =:      (%, %) -> Boolean;              ++ Equality test.
         ~=:     (%, %) -> Boolean;              ++ Inequality test.
-        \<\<:     (TextWriter, %) -> TextWriter;  ++ Basic output.
-        \<\<:     % -> TextWriter -> TextWriter;  ++ Basic output.
+        <<:     (TextWriter, %) -> TextWriter;  ++ Basic output.
+        <<:     % -> TextWriter -> TextWriter;  ++ Basic output.
         sample: %;                              ++ Example element.
         hash:   % -> SingleInteger;             ++ Hashing function.
 
         default (x: %) ~= (y: %): Boolean == not (x = y);
         default hash(x: %): SingleInteger == (0$Machine)::SingleInteger;
-        default (\<\<)(x: %)(p: TextWriter): TextWriter == p \<\< x;
+        default (<<)(x: %)(p: TextWriter): TextWriter == p << x;
 }
 \end{verbatim}
 \end{small}
@@ -1415,7 +1415,7 @@
   Term: BasicType with {
           new: (SingleInteger, Character) -> %;
           dispose!: % -> ();
-          \<\<: (TextWriter, %) -> TextWriter;
+          <<: (TextWriter, %) -> TextWriter;
           coef: % -> SingleInteger;
           var:  % -> Character;
    }
@@ -1432,13 +1432,13 @@
 \begin{verbatim}
         =:      (%, %) -> Boolean;              ++ Equality test.
         ~=:     (%, %) -> Boolean;              ++ Inequality test.
-        \<\<:     (TextWriter, %) -> TextWriter;  ++ Basic output.
-        \<\<:     % -> TextWriter -> TextWriter;  ++ Basic output.
+        <<:     (TextWriter, %) -> TextWriter;  ++ Basic output.
+        <<:     % -> TextWriter -> TextWriter;  ++ Basic output.
         sample: %;                              ++ Example element.
         hash:   % -> SingleInteger;             ++ Hashing function.
         new:    (SingleInteger, Character) -> %;
         dispose!: % -> ();
-        \<\<:     (TextWriter, %) -> TextWriter;
+        <<:     (TextWriter, %) -> TextWriter;
         coef:   % -> SingleInteger;
         var:    % -> Character;
 \end{verbatim}
@@ -1519,7 +1519,7 @@
 
 \begin{small}
 \begin{verbatim}
-  \<\<: (TextWriter, %) -> TextWriter;
+  <<: (TextWriter, %) -> TextWriter;
 \end{verbatim}
 \end{small}
 
@@ -1533,7 +1533,7 @@
 
 \begin{small}
 \begin{verbatim}
-   (stream: TextWriter) \<\< (poly: %): TextWriter 
+   (stream: TextWriter) << (poly: %): TextWriter 
 \end{verbatim}
 \end{small}
 
@@ -1544,7 +1544,7 @@
 
 \begin{small}
 \begin{verbatim}
-   stream \<\< poly \<\< newline;
+   stream << poly << newline;
 \end{verbatim}
 \end{small}
 
@@ -1557,11 +1557,11 @@
  
 \begin{small}
 \begin{verbatim}
-  (stream: TextWriter) \<\< (poly: %): TextWriter == {
+  (stream: TextWriter) << (poly: %): TextWriter == {
           size: SingleInteger := #(rep(poly));
           for i in 1..(size-1) repeat 
-                  stream \<\< poly.i \<\< "^" \<\< (size - i) \<\< " + ";
-          stream \<\< poly.size
+                  stream << poly.i << "^" << (size - i) << " + ";
+          stream << poly.size
   }
 \end{verbatim}
 \end{small}
@@ -1585,11 +1585,11 @@
      
 \begin{small}
 \begin{verbatim}
-  (stream: TextWriter) \<\< (poly: %): TextWriter == {
+  (stream: TextWriter) << (poly: %): TextWriter == {
           size: SingleInteger := #(rep(poly));
           for i in 1..(size-1) repeat
-                  stream \<\< poly.i \<\< "^" \<\< (size - i) \<\< " + ";
-          stream \<\< coef(poly.size)
+                  stream << poly.i << "^" << (size - i) << " + ";
+          stream << coef(poly.size)
   }
 \end{verbatim}
 \end{small}
@@ -1599,12 +1599,12 @@
      
 \begin{small}
 \begin{verbatim}
-  (stream: TextWriter) \<\< (poly: %): TextWriter == {
+  (stream: TextWriter) << (poly: %): TextWriter == {
           size: SingleInteger := #(rep(poly));
           for i in 1..(size-2) repeat 
-                  stream \<\< poly.i \<\< "^" \<\< (size-i) \<\< " + ";
-          stream \<\< poly.(size-1) \<\< " + "
-          stream \<\< coef(poly.size)
+                  stream << poly.i << "^" << (size-i) << " + ";
+          stream << poly.(size-1) << " + "
+          stream << coef(poly.size)
   }
 \end{verbatim}
 \end{small}
@@ -1629,19 +1629,19 @@
      
 \begin{small}
 \begin{verbatim}
-  (stream: TextWriter) \<\< (poly: %): TextWriter == {
+  (stream: TextWriter) << (poly: %): TextWriter == {
           size: SingleInteger := #(rep(poly));
 
           for i in 1..(size-2) repeat 
                 if not zero?(poly.i) then 
-                        stream \<\< poly.i \<\< "^" \<\< (size - i) \<\< " + ";
+                        stream << poly.i << "^" << (size - i) << " + ";
 
           if not zero?(poly.(size-1)) then 
-                stream \<\< poly.(size-1) \<\< " + ";
+                stream << poly.(size-1) << " + ";
           if zero?(poly.size) then
-                stream \<\< 0
+                stream << 0
           else
-                stream \<\< coef(poly.size)
+                stream << coef(poly.size)
   }
 \end{verbatim}
 \end{small}
@@ -1662,20 +1662,20 @@
      
 \begin{small}
 \begin{verbatim}
-  (stream: TextWriter) \<\< (poly: %): TextWriter == {
+  (stream: TextWriter) << (poly: %): TextWriter == {
           size: SingleInteger := #(rep(poly));
           prefix: String := "";
           for i in 1..(size-2) repeat
                 if not zero?(poly.i) then {
-                        stream \<\< prefix \<\< poly.i \<\< "^" \<\< (size - i);
+                        stream << prefix << poly.i << "^" << (size - i);
                         prefix := " + "
                 }
           if not zero?(poly.(size-1)) then {
-                  stream \<\< prefix \<\< poly.(size-1);
+                  stream << prefix << poly.(size-1);
                   prefix := " + "
           }
           if not zero?(poly.size) then 
-                  stream \<\< prefix \<\< coef(poly.size);
+                  stream << prefix << coef(poly.size);
          stream
   }
 \end{verbatim}
@@ -1735,23 +1735,23 @@
 
 \begin{small}
 \begin{verbatim}
-  (stream: TextWriter) \<\< (poly: %): TextWriter == {
-          zero? poly => stream \<\< 0;
+  (stream: TextWriter) << (poly: %): TextWriter == {
+          zero? poly => stream << 0;
 
           size: SingleInteger := #(rep(poly));
           prefix: String := "";
 
           for i in 1..(size-2) repeat
                   if not zero?(poly.i) then {
-                         stream \<\< prefix \<\< poly.i \<\< "^" \<\< (size-i);
+                         stream << prefix << poly.i << "^" << (size-i);
                          prefix := " + "
                   }
           if not zero?(poly.(size-1)) then {
-                  stream \<\< prefix \<\< poly.(size-1);
+                  stream << prefix << poly.(size-1);
                   prefix := " + "
           }
           if not zero?(poly.size) then 
-                  stream \<\< prefix \<\< coef(poly.size);
+                  stream << prefix << coef(poly.size);
           stream
   }
 \end{verbatim}
@@ -1822,24 +1822,24 @@
   abs(term: Term): Term ==
           if negative? term then -term else term;
 
-  (stream: TextWriter) \<\< (poly: %): TextWriter == {
-          zero? poly => stream \<\< 0;
+  (stream: TextWriter) << (poly: %): TextWriter == {
+          zero? poly => stream << 0;
 
           size: SingleInteger := #(rep(poly));
           prefix: String := if negative?(poly.1) then " - " else "";
 
           for i in 1..(size-2) repeat
                   if not zero?(poly.i) then {
-                          stream \<\< prefix \<\< abs(poly.i);
-                          stream \<\< "^" \<\< (size - i);
+                          stream << prefix << abs(poly.i);
+                          stream << "^" << (size - i);
                           prefix := prefix(poly.(i+1))
                   }
           if not zero?(poly.(size-1)) then {
-                  stream \<\< prefix \<\< abs(poly.(size-1));
+                  stream << prefix << abs(poly.(size-1));
                   prefix := prefix(poly.size)
           }
           if not zero?(poly.size) then 
-                  stream \<\< prefix \<\< abs(coef(poly.size));
+                  stream << prefix << abs(coef(poly.size));
           stream
   }
 \end{verbatim}
@@ -1887,7 +1887,7 @@
 Term: BasicType with {
         new: (SingleInteger, Character) -> %;
         dispose!: % -> ();
-        \<\<: (TextWriter, %) -> TextWriter;
+        <<: (TextWriter, %) -> TextWriter;
         coef: % -> SingleInteger;
         var:  % -> Character;
         zero?: % -> Boolean;
@@ -1906,12 +1906,12 @@
 
         dispose!(ignore: %):() == {}
 
-        (stream: TextWriter) \<\< (term: %): TextWriter ==
+        (stream: TextWriter) << (term: %): TextWriter ==
                 if rep(term).coef = 1 then
-                         stream \<\< rep(term).var
+                         stream << rep(term).var
                 else {
-                         stream \<\< rep(term).coef;
-                         stream \<\< "*" \<\< rep(term).var
+                         stream << rep(term).coef;
+                         stream << "*" << rep(term).var
                 }
 
         coef(term: %): SingleInteger == rep(term).coef;
@@ -1950,7 +1950,7 @@
 Polynomial: with {
         new: List(Term) -> %;
         dispose!: % -> ();
-        \<\<: (TextWriter, %) -> TextWriter;
+        <<: (TextWriter, %) -> TextWriter;
         leadingMonomial: % -> Term;
         apply: (%, SingleInteger) -> Term;
         degree: % -> SingleInteger;
@@ -1981,25 +1981,25 @@
         abs(term: Term): Term == 
                 if negative? term then -term else term;
 
-        (stream: TextWriter) \<\< (poly: %): TextWriter == {
-                zero? poly => stream \<\< 0;
+        (stream: TextWriter) << (poly: %): TextWriter == {
+                zero? poly => stream << 0;
 
                 size: SingleInteger := #(rep(poly));
                 sign: String := if negative?(poly.1) then " - " else "";
 
                 for i in 1..(size-2) repeat
                         if not zero?(poly.i) then {
-                                stream \<\< sign \<\< abs(poly.i);
-                                stream \<\< "^" \<\< (size - i);
+                                stream << sign << abs(poly.i);
+                                stream << "^" << (size - i);
                                 sign := prefix(poly.(i + 1))
                         }
 
                if not zero?(poly.(size - 1)) then {
-                       stream \<\< sign \<\< abs(poly.(size-1));
+                       stream << sign << abs(poly.(size-1));
                        sign := prefix(poly.size)
                }
                if not zero?(poly.size) then 
-                       stream \<\< sign \<\< abs(coef(poly.size));
+                       stream << sign << abs(coef(poly.size));
                stream
         }              
 
@@ -2027,17 +2027,17 @@
 term4 := new(0, var);
 term5 := new(-3, var);
 --  term6 := -term5;
-print \<\< new(list(term5,term5,term5)) \<\< newline; -- negative signs
-print \<\< new(list(term3,term2,term1)) \<\< newline; -- 1 elision
-print \<\< new(list(term1,term2,term3)) \<\< newline;
-print \<\< new(list(term4,term2,term3)) \<\< newline;
-print \<\< new(list(term1,term4,term3)) \<\< newline;
-print \<\< new(list(term4,term4,term3)) \<\< newline;
-print \<\< new(list(term1,term2,term4)) \<\< newline; -- bad leading term
-print \<\< new(list(term4,term2,term4)) \<\< newline; -- bad leading term
-print \<\< new(list(term1,term4,term4)) \<\< newline; -- bad leading term
-print \<\< new(list(term4,term4,term4)) \<\< newline; -- bad leading term
-print \<\< new(list())@Polynomial \<\< newline; -- true zero polynomial
+print << new(list(term5,term5,term5)) << newline; -- negative signs
+print << new(list(term3,term2,term1)) << newline; -- 1 elision
+print << new(list(term1,term2,term3)) << newline;
+print << new(list(term4,term2,term3)) << newline;
+print << new(list(term1,term4,term3)) << newline;
+print << new(list(term4,term4,term3)) << newline;
+print << new(list(term1,term2,term4)) << newline; -- bad leading term
+print << new(list(term4,term2,term4)) << newline; -- bad leading term
+print << new(list(term1,term4,term4)) << newline; -- bad leading term
+print << new(list(term4,term4,term4)) << newline; -- bad leading term
+print << new(list())@Polynomial << newline; -- true zero polynomial
 
 #endif -- TEST
 
@@ -2176,7 +2176,7 @@
 
 \begin{small}
 \begin{verbatim}
-print \<\< new(list(term5,term5,term5)) \<\< newline; -- negative signs
+print << new(list(term5,term5,term5)) << newline; -- negative signs
 \end{verbatim}
 \end{small}
 
@@ -2184,7 +2184,7 @@
 
 \begin{small}
 \begin{verbatim}
-print \<\< new(list(term3,term2,term1)) \<\< newline; -- 1 elision
+print << new(list(term3,term2,term1)) << newline; -- 1 elision
 \end{verbatim}
 \end{small}
 
@@ -2192,14 +2192,14 @@
 
 \begin{small}
 \begin{verbatim}
-print \<\< new(list(term1,term2,term3)) \<\< newline;
-print \<\< new(list(term4,term2,term3)) \<\< newline;
-print \<\< new(list(term1,term4,term3)) \<\< newline;
-print \<\< new(list(term4,term4,term3)) \<\< newline;
-print \<\< new(list(term1,term2,term4)) \<\< newline; -- bad leading term
-print \<\< new(list(term4,term2,term4)) \<\< newline; -- bad leading term
-print \<\< new(list(term1,term4,term4)) \<\< newline; -- bad leading term
-print \<\< new(list(term4,term4,term4)) \<\< newline; -- bad leading term
+print << new(list(term1,term2,term3)) << newline;
+print << new(list(term4,term2,term3)) << newline;
+print << new(list(term1,term4,term3)) << newline;
+print << new(list(term4,term4,term3)) << newline;
+print << new(list(term1,term2,term4)) << newline; -- bad leading term
+print << new(list(term4,term2,term4)) << newline; -- bad leading term
+print << new(list(term1,term4,term4)) << newline; -- bad leading term
+print << new(list(term4,term4,term4)) << newline; -- bad leading term
 \end{verbatim}
 \end{small}
 
@@ -2207,8 +2207,8 @@
 
 \begin{small}
 \begin{verbatim}
-print \<\< new(list())@Polynomial \<\< newline; -- true zero polynomial
-print \<\< 0@Polynomial \<\< newline; -- true zero polynomial
+print << new(list())@Polynomial << newline; -- true zero polynomial
+print << 0@Polynomial << newline; -- true zero polynomial
 \end{verbatim}
 \end{small}
 
@@ -2216,10 +2216,10 @@
 
 \begin{small}
 \begin{verbatim}
-print \<\< term1 + term2 \<\< newline;
-print \<\< term1 - term2 \<\< newline;
-print \<\< term2 - term1 \<\< newline;
-print \<\< term1 - term1 \<\< newline;
+print << term1 + term2 << newline;
+print << term1 - term2 << newline;
+print << term2 - term1 << newline;
+print << term1 - term1 << newline;
 \end{verbatim}
 \end{small}
 %#endif --example5
@@ -2236,7 +2236,7 @@
 Term: BasicType with {
         new: (SingleInteger, Character) -> %;
         dispose!: % -> ();
-        \<\<: (TextWriter, %) -> TextWriter;
+        <<: (TextWriter, %) -> TextWriter;
         coef: % -> SingleInteger;
         var:  % -> Character;
         zero?: % -> Boolean;
@@ -2255,12 +2255,12 @@
 
         dispose!(ignore: %):() == {}
 
-        (stream: TextWriter) \<\< (term: %): TextWriter == 
+        (stream: TextWriter) << (term: %): TextWriter == 
                 if rep(term).coef = 1 then
-                         stream \<\< rep(term).var
+                         stream << rep(term).var
                 else {
-                         stream \<\< rep(term).coef;
-                         stream \<\< "*" \<\< rep(term).var
+                         stream << rep(term).coef;
+                         stream << "*" << rep(term).var
                 }
 
         coef(term: %): SingleInteger == rep(term).coef;
@@ -2299,7 +2299,7 @@
 Polynomial: with {
         new: List(Term) -> %;
         dispose!: % -> ();
-        \<\<: (TextWriter, %) -> TextWriter;
+        <<: (TextWriter, %) -> TextWriter;
         leadingMonomial: % -> Term;
         apply: (%, SingleInteger) -> Term;
         degree: % -> SingleInteger;
@@ -2332,8 +2332,8 @@
         abs(term: Term): Term == 
                 if negative? term then -term else term;
 
-        (stream: TextWriter) \<\< (poly: %): TextWriter == {
-                zero? poly => stream \<\< 0@%;
+        (stream: TextWriter) << (poly: %): TextWriter == {
+                zero? poly => stream << 0@%;
 
                 size: SingleInteger := #(rep(poly));
 
@@ -2342,16 +2342,16 @@
 
                 for i in 1..(size - 2) repeat
                         if not zero?(poly.i) then {
-                                stream \<\< sign \<\< abs(poly.i);
-                                stream \<\< "^" \<\< (size - i);
+                                stream << sign << abs(poly.i);
+                                stream << "^" << (size - i);
                                 sign := prefix(poly.(i+1))
                         }
                 if not zero?(poly.(size-1)) then {
-                        stream \<\< sign \<\< abs(poly.(size-1));
+                        stream << sign << abs(poly.(size-1));
                         sign := prefix(poly.size)
                 }
                 if not zero?(poly.size) then 
-                        stream \<\< sign \<\< abs(coef(poly.size));
+                        stream << sign << abs(coef(poly.size));
                 stream
                 }
 
@@ -2653,7 +2653,7 @@
 Term(CoefType: OrderedRing): BasicType with {          
         new: (CoefType, Character) -> %;                    
         dispose!: % -> ();
-        \<\<: (TextWriter, %) -> TextWriter;
+        <<: (TextWriter, %) -> TextWriter;
         coef: % -> CoefType;                                     
         var:  % -> Character;
         zero?: % -> Boolean;
@@ -2672,12 +2672,12 @@
 
         dispose!(ignore: %):() == {}  -- undefined
 
-        (stream: TextWriter) \<\< (term: %): TextWriter == 
+        (stream: TextWriter) << (term: %): TextWriter == 
                 if rep(term).coef = 1 then
-                        stream \<\< rep(term).var
+                        stream << rep(term).var
                 else {
-                        stream \<\< rep(term).coef;
-                        stream \<\< "*" \<\< rep(term).var
+                        stream << rep(term).coef;
+                        stream << "*" << rep(term).var
                 }
 
         coef(term: %): CoefType == rep(term).coef;
@@ -2717,9 +2717,9 @@
 
 import from Character;
 import from Term SingleInteger;
-print \<\< new(0$SingleInteger,char "x") \<\< newline;
+print << new(0$SingleInteger,char "x") << newline;
 import from Term Float;
-print \<\< new(0$Float,char "x") \<\< newline;
+print << new(0$Float,char "x") << newline;
 
 #endif -- TEST
 

--=-=-=

--- Makefile.org.pamphlet	2006-08-05 12:37:17.794397200 +0200
+++ Makefile.pamphlet	2006-08-05 13:19:04.263356000 +0200
@@ -151,6 +151,28 @@
 	@echo 8 making ${INT}/booklet.c from ${IN}/booklet.c.pamphlet
 	@(cd ${INT} ; \
 	  ${TANGLE} ${IN}/booklet.c.pamphlet >booklet.c )
+
+@
+\section{ComputerTutorial}
+ComputerTutorial introduces some aspects of axiom programming. It
+mainly talks about how to build your own domains and types and
+explains some concepts by comparison with C/C++.
+
+<<ComputerTutorial>>=
+${DVI}/ComputerTutorial.dvi: ${IN}/ComputerTutorial.pamphlet
+	@echo 4 building ${DVI}/ComputerTutorial.dvi from \
+	${IN}/ComputerTutorial.pamphlet
+	@(cd ${MID} ; \
+	cp ${IN}/ComputerTutorial.pamphlet ${MID} ; \
+	if [ -n "${NOISE}" ] ; then \
+	  latex ComputerTutorial.pamphlet --interaction nonstopmode >${TMP}/trace ; \
+	  latex ComputerTutorial.pamphlet --interaction nonstopmode >${TMP}/trace ; \
+	else \
+	  latex ComputerTutorial.pamphlet --interaction nonstopmode ; \
+	  latex ComputerTutorial.pamphlet --interaction nonstopmode ; \
+	fi ; \
+	cp ComputerTutorial.dvi ${DVI} )
+
 	  
 @
 \section{The Makefile}
@@ -165,7 +187,7 @@
 
 FILES= ${MID}/axiom.bib ${STY}/axiom.sty ${DVI}/DeveloperNotes.dvi \
        ${DVI}/book.dvi ${DVI}/bookvol1.dvi ${DVI}/endpaper.dvi \
-       ${DVI}/Rosetta.dvi
+       ${DVI}/Rosetta.dvi ${DVI}/ComputerTutorial.dvi
 
 CMDS=${OUT}/booklet
 
@@ -180,6 +202,7 @@
 <<bookvol1>>
 <<Endpapers>>
 <<Rosetta>>
+<<ComputerTutorial>>
 
 document:
 	@echo 10 documenting ${SRC}/doc

\start
Date: 05 Aug 2006 17:12:24 +0200
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] Support traditional build	commands

   This patchlet adds support for the traditional

      ./configure && make && make install

There no longer should be a need to set and export the variables AXIOM
and PATH before doing make.

The other version I had was doing a major overhall of toplevel
Makefile.  To allow people follow the changes, I decided on this
alternative way of doing it.  Nevertheless, the current Makefiles
remain a big mess :-(

Tested on i686-suse-linux and i686-redhat-linux.

-- Gaby

2006-08-05  Gabriel Dos Reis  Gabriel Dos Reis

	Provide support for "./configure && make && make install".
	* build-setup.sh: Generate Makefile.in too.

	* configure.ac.pamphlet (must_set_AXIOM): Don't ask user to
	set the AXIOM variable.
	* configure.ac: Regenerate.
	* configure: Regenerate.

	* Makefile.pamphlet (do-all): New target.  Rename from target all.
	(all): Export the variable AXIOM, then make do-all.
	(VERSION): Update.
	* Makefile.in: Generate.

*** Makefile.pamphlet	(revision 15558)
--- Makefile.pamphlet	(local)
*************** it walked the Makefile hierarchy trying 
*** 24,39 ****
  method often fails for various reasons (e.g. permissions, incomplete
  builds, etc). Now we simply remove the created files directly.
  \eject
  \subsection{The Top Level Makefile}
  <<*>>=
  <<environment>>
! all: noweb ${MNT}/${SYS}/bin/Makefile.pamphlet
  	@ echo 1 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
  	@ echo 2 Environment ${ENV}
  	@ ${TANGLE} -t8 -RMakefile.${SYS} Makefile.pamphlet >Makefile.${SYS}
! 	@ ${DOCUMENT} Makefile
! 	@ mkdir -p ${MNT}/${SYS}/doc/src
! 	@ cp Makefile.dvi ${MNT}/${SYS}/doc/src/root.Makefile.dvi
  	@ ${ENV} $(MAKE) -f Makefile.${SYS} 
  	@echo 3 finished system build on `date` | tee >lastBuildDate
  
--- 24,48 ----
  method often fails for various reasons (e.g. permissions, incomplete
  builds, etc). Now we simply remove the created files directly.
  \eject
+ 
  \subsection{The Top Level Makefile}
  <<*>>=
  <<environment>>
! 
! PATH_EXPORTS = AXIOM=@AXIOM@; export AXIOM; PATH=@AXIOM@/bin:$${PATH}
! 
! all:
! 	$(PATH_EXPORTS); $(MAKE) do-all
! 
! do-all: noweb ${MNT}/${SYS}/bin/Makefile.pamphlet
  	@ echo 1 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
  	@ echo 2 Environment ${ENV}
  	@ ${TANGLE} -t8 -RMakefile.${SYS} Makefile.pamphlet >Makefile.${SYS}
! 	@ (cp Makefile.pamphlet root-Makefile.pamphlet; \
! 	   ${DOCUMENT} root-Makefile; \
! 	   cp root-Makefile.dvi Makefile.dvi; \
! 	   mkdir -p ${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
  
*************** The [[DOCUMENT]] variable is now set to 
*** 291,297 ****
  to the [[$SPADBIN/document]] command. This will allow it to be
  changed on the command line.
  <<environment>>=
! VERSION="Axiom (build improvements branch) -- 2006-08-01"
  SPD=$(shell pwd)
  SYS=$(notdir $(AXIOM))
  SPAD=${SPD}/mnt/${SYS}
--- 300,306 ----
  to the [[$SPADBIN/document]] command. This will allow it to be
  changed on the command line.
  <<environment>>=
! VERSION="Axiom (build improvements branch) -- 2006-08-05"
  SPD=$(shell pwd)
  SYS=$(notdir $(AXIOM))
  SPAD=${SPD}/mnt/${SYS}
*************** ${LSP}/Makefile: ${LSP}/Makefile.pamphle
*** 549,556 ****
  	 if [ "${GCLVERSION}" != "gcl-2.4.1" ] ; then \
  	 ${TANGLE} -t8 -R"${GCLVERSION}" Makefile.pamphlet >Makefile ; \
           fi )
! 	@cp Makefile.dvi ${MNT}/${SYS}/doc/src
! 
  
  @
  Here we add [[mkdir -p ${OBJ}/${SYS}/lsp]] because we need to rename the
--- 558,564 ----
  	 if [ "${GCLVERSION}" != "gcl-2.4.1" ] ; then \
  	 ${TANGLE} -t8 -R"${GCLVERSION}" Makefile.pamphlet >Makefile ; \
           fi )
! 	 @cp Makefile.dvi ${MNT}/${SYS}/doc/src
  
  @
  Here we add [[mkdir -p ${OBJ}/${SYS}/lsp]] because we need to rename the
*** build-setup.sh	(revision 15558)
--- build-setup.sh	(local)
*************** error() {
*** 9,14 ****
--- 9,39 ----
  notangle ./configure.ac.pamphlet > ./configure.ac \
     || error "could not extract configure.ac from pamphlet file"
  
+ notangle -t8 ./Makefile.pamphlet > ./Makefile.in \
+    || error "could not extract Makefile.in from pamphlet file"
+ 
  autoconf || error "could not re-generate configure"

*** configure.ac.pamphlet	(revision 15558)
--- configure.ac.pamphlet	(local)
*************** if test "$SYSNAME" != "fedora3"; then
*** 394,406 ****
  fi
  
  must_set_AXIOM() {
-    AC_MSG_NOTICE([])
-    AC_MSG_NOTICE([===================================================])
-    AC_MSG_NOTICE([])
-    AC_MSG_NOTICE([You must set your AXIOM and PATH variables. Type:])
-    AC_MSG_NOTICE([])
-    AC_MSG_NOTICE([export AXIOM=`pwd`/mnt/$SYSNAME])
-    AC_MSG_NOTICE([export PATH=\$AXIOM/bin:\$PATH])
     case "$SYSNAME" in
        freebsd)
  	 AC_MSG_NOTICE([Note that freebsd usually has noweb available])
--- 394,399 ----
*************** must_set_AXIOM() {
*** 409,419 ****
  	 AC_MSG_NOTICE([If you wish to use a pre-installed GCL you must type])
  	 AC_MSG_NOTICE([make GCLVERSION=gcl-system])
           ;;
-       solaris9)
-          AC_MSG_NOTICE([make AWK=gawk TAR=gtar PATCH=gpatch])
-          ;;
-       *)
-          AC_MSG_NOTICE([make AWK=$AWK])
     esac
  }
  
--- 402,407 ----
*************** else
*** 425,436 ****
     AC_MSG_NOTICE([configure complete.  Now type ])
     AC_MSG_NOTICE([                              ])
     AC_MSG_NOTICE([make])
-    AC_MSG_NOTICE([                              ])
-    AC_MSG_NOTICE([export AXIOM=`pwd`/mnt/$SYSNAME])
-    AC_MSG_NOTICE([export PATH=\$AXIOM/bin:\$PATH])
  fi
  @
  
  <<*>>=
  <<Autoconf init>>
  
--- 413,429 ----
     AC_MSG_NOTICE([configure complete.  Now type ])
     AC_MSG_NOTICE([                              ])
     AC_MSG_NOTICE([make])
  fi
+ AXIOM=`pwd`/mnt/$SYSNAME
+ AC_SUBST(AXIOM)
  @
  
+ <<instantiate config files>>=
+ AC_CONFIG_FILES(Makefile)
+ AC_OUTPUT
+ @
+ 
+ 
  <<*>>=
  <<Autoconf init>>
  
*************** fi
*** 457,462 ****
--- 450,456 ----
  <<check for make>>
  
  <<replicate old behaviour>>
+ <<instantiate config files>>
  @
  
  \end{document}

\start
Date: Sat, 5 Aug 2006 08:27:46 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Translation of the interp to lisp

> > 2.  I noticed a lot of implementation specific code having to do
> > with things like (system:getenv $AXIOM) - is the plan to write some
> > generic macros to handle these operations and get all of the
> > implementation specific logic into one file?
> 
> Any luck identifying GCL-specific code and writing "generic macros"?

Not too much yet, unfortunately - my original push was trying to see
how much of the axiom build process I could complete in sbcl, and I
stalled out a bit after discovering that all the effort on the boot dir
was essentially redundant.  A few not very exciting functions are about
all I have to show for that effort, unfortunately.  I put them at the
end of  this message just in case anybody ever wants to do something
similar.

A question Tim, if I may.  In looking at sys-pkg.lisp, it seems like
there are a rather large number of import and export commands contained
there.  Is this normal in lisp to have to hand-import and hand-export
so many symbols?  Also, I'm a bit confused by the BOOT and VMLISP
package relations - are they in fact cross-pollinating and importing
from/exporting to each other?  If so, wouldn't it be a bit cleaner to
get the common functionality into one package and have both BOOT and
VMLISP use that one?

As an example of a problem I don't yet understand:  in sys-pkg.lisp,
there is code of the form:

(lisp:import '(
#+:GCL    SYSTEM:DEFINE-MACRO 
#+:GCL    SYSTEM:MEMQ 
#+:GCL    SYSTEM:PNAME
          BOOT:|directoryp|))

I have changed this file somewhat for sbcl (the diff is at the very end
of the email) and I can load sys-pkg.lisp successfully after this.  But
if I try to compile the file, I get:

* (compile-file "./interp/sys-pkg.lisp")

; compiling file
"/home/user/mathtoplevel/axiomtoplevel/axiomasdf/interp/sys-pkg.lisp"
(written 05 AUG 2006 11:12:42 AM):
; compiling (DEFPACKAGE :BOOT ...)
; compiling (DEFPACKAGE :BOOTTRAN ...)
; compiling (DEFPACKAGE :VMLISP ...)
; compiling (USE-PACKAGE :VMLISP ...)
; compiling (DEFPACKAGE :FOAM ...)
; compiling (DEFPACKAGE :FOAM-USER ...)
; compiling (IN-PACKAGE "BOOT")
; compiling (IMPORT (QUOTE #))
; compiling (EXPORT (QUOTE #))
; compiling (IN-PACKAGE "VMLISP"); 
; compilation unit aborted
;   caught 1 fatal ERROR condition
compilation aborted because of fatal error:
                                   READ failure in COMPILE-FILE:
                                     READER-ERROR at 15046 (line 278,
column 27) on #<SB-SYS:FD-STREAM for "file
/home/user/mathtoplevel/axiomtoplevel/axiomasdf/interp/sys-pkg.lisp"
{A7D7491}>:
The symbol "directoryp" is not external in the BOOT package.

Does anyone know why loading would succeed when compiling fails? 

I'm beginning to think that refactoring this into ANSI lisp might have
to be sort of an ongoing thing - start by defining one piece of
functionality, and add in more as it becomes clear.  So far I'm aware
of the History mechanism and the Frames mechanism thanks to bookvol5,
the SPAD compiler, and whatever we are calling the current B-natural
like mechanism that handles actual user input.  Undoubtedly there are
more pieces I'm not even aware of.  I am able to get sys-pkg to work
with asdf by removing the directoryp reference above, but I have no
idea what its purpose is, what breaks when I do that, etc. :-(.  Not
doubt many more such problems await.

Lisp code for bootstrap:

These are set up in order to let me get at things like the notangle
command and filenames from lisp.  The results of the directory command
on lisp doesn't provide strings as such, so with the help of #lisp I
put these together.  I think this is likely to be made completely
useless by the autotools work, though - I don't know if we will ever do
this from lisp.  These are only defined in sbcl, but other
implementation specific code can certainly be added - I just don't know
at the moment what is needed.

(defun pathname-to-string (file)
 #+sbcl (sb-ext:native-namestring file)
   )

(defun run-ext-program (string args out)
 #+sbcl (sb-ext:run-program string args :input nil :output out :wait t)
   )

(defun pamphletname-to-filename (file)
   (subseq (pathname-to-string file) 0 
           (position #\. (pathname-to-string file) :from-end t)))

This was my "run notangle from lisp" code using the above.  Again
rather specific to the bootstrap problem, and not likely of importance
for the future.  I should mention the above definitions and the
contents below were in a separate setup directory so they didn't erase
themselves ;-).

;; boot pamphlet files

(dolist (file (directory "./boot/*.boot"))
   (run-ext-program "/usr/bin/rm" (list (pathname-to-string file))
nil))

(dolist (file (directory "./boot/*.l*sp"))
   (run-ext-program "/usr/bin/rm" (list (pathname-to-string file))
nil))

#+sbcl(dolist (file (directory "./boot/*.fasl"))
        (run-ext-program "/usr/bin/rm" (list (pathname-to-string file))
nil))

(dolist (file (directory "./boot/*.l*sp.pamphlet"))
   (run-ext-program "/usr/bin/notangle" (list (pathname-to-string
file)) (pamphletname-to-filename file)))

(dolist (file (directory "./boot/*.boot.pamphlet"))
   (run-ext-program "/usr/bin/notangle" (list (pathname-to-string
file)) (pamphletname-to-filename file)))

;; In the case of boot, there are special steps which need to be taken
in order to bootstrap the language.
;; Because of that, the .boot files in this directory also contain lisp
code, which will be needed.
(run-ext-program "/usr/bin/notangle" (list "-Rptyout.clisp"
"./boot/ptyout.boot.pamphlet") "./boot/ptyout.lisp")
(run-ext-program "/usr/bin/notangle" (list "-Rbtincl2.clisp"
"./boot/btincl2.boot.pamphlet") "./boot/btincl2.lisp")
(run-ext-program "/usr/bin/notangle" (list "-Rtyprops.clisp"
"./boot/typrops.boot.pamphlet") "./boot/typrops.lisp")
(run-ext-program "/usr/bin/notangle" (list "-Rbtpile2.clisp"
"./boot/btpile2.boot.pamphlet") "./boot/btpile2.lisp")
(run-ext-program "/usr/bin/notangle" (list "-Rbtscan2.clisp"
"./boot/btscan2.boot.pamphlet") "./boot/btscan2.lisp")
(run-ext-program "/usr/bin/notangle" (list "-Rtypars.clisp"
"./boot/typars.boot.pamphlet") "./boot/typars.lisp")
(run-ext-program "/usr/bin/notangle" (list "-Rtyextra.clisp"
"./boot/tyextra.boot.pamphlet") "./boot/tyextra.lisp")
(run-ext-program "/usr/bin/notangle" (list "-Rtytree1.clisp"
"./boot/tytree1.boot.pamphlet") "./boot/tytree1.lisp")

;; interp pamphlet files

#+sbcl(dolist (file (directory "./interp/*.fasl"))
        (run-ext-program "/usr/bin/rm" (list (pathname-to-string file))
nil))

(dolist (file (directory "./interp/*.boot"))
   (run-ext-program "/usr/bin/rm" (list (pathname-to-string file))
nil))

(dolist (file (directory "./interp/*.l*sp"))
   (run-ext-program "/usr/bin/rm" (list (pathname-to-string file))
nil))

(dolist (file (directory "./interp/*.l*sp.pamphlet"))
   (run-ext-program "/usr/bin/notangle" (list (pathname-to-string
file)) (pamphletname-to-filename file)))

(dolist (file (directory "./interp/*.boot.pamphlet"))
   (run-ext-program "/usr/bin/notangle" (list (pathname-to-string
file)) (pamphletname-to-filename file)))

(run-ext-program "/usr/bin/notangle" (list "-RInterpreter"
"./interp/bookvol5.pamphlet") "./interp/bookvol5.lisp")




This is the diff of sys-pkg.lisp mentioned earlier:


--- ../axiom/src/interp/sys-pkg.lisp	2006-08-05 11:10:01.000000000
-0400
+++ interp/sys-pkg.lisp	2006-08-05 11:12:42.000000000 -0400
@@ -30,38 +30,33 @@
 ;; SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 
-(make-package "SCRATCHPAD_COMPILER")
-(make-package "SPECFNSF")
+(defpackage :boot
+    (:use :cl))
 
-(make-package "VMLISP")
-(in-package "VMLISP")
-(lisp::use-package '("USER" "SYSTEM" "LISP"))
-
-(make-package "BOOTTRAN")
-(in-package "BOOTTRAN")
-(lisp::use-package '("LISP"))
+(defpackage :boottran
+    (:use :cl))
 
-(make-package "BOOT")
-(in-package "BOOT")
-(lisp::use-package '("VMLISP" "LISP"))
+(defpackage :vmlisp
+    (:use :cl-user :cl #+gcl :system))
+
+(use-package :VMLISP :boot)
+
+(defpackage :foam
+    (:use :cl))
+
+(defpackage :foam-user
+    (:use :cl :foam))
+
+(cl::in-package "BOOT")
 
-(make-package "FOAM")
-(in-package "FOAM")
-(lisp::use-package '("LISP"))
 
-(make-package "FOAM-USER")
-(in-package "FOAM-USER")
-(lisp::use-package '("LISP" "FOAM"))
-
-(lisp:in-package "BOOT")
-
-(lisp:import
-    '(VMLISP::ERROROUTSTREAM LISP::COUNT VMLISP::NE VMLISP::FLUID
-         LISP:SEQUENCE VMLISP::OBEY LISP:NUMBER VMLISP::|union|
-         LISP:STEP VMLISP::OPTIONLIST VMLISP::EXIT
VMLISP::throw-protect
+(cl:import
+    '(VMLISP::ERROROUTSTREAM cl::COUNT VMLISP::NE VMLISP::FLUID
+         cl:SEQUENCE VMLISP::OBEY cl:NUMBER VMLISP::|union|
+         cl:STEP VMLISP::OPTIONLIST VMLISP::EXIT VMLISP::throw-protect
 #+:GCL   SYSTEM:GETENV
          VMLISP::*INDEX-FILENAME*))
-(lisp:export
+(cl:export
     '(BOOT::|$FormalMapVariableList| BOOT::|$userModemaps|
          boot::restart boot::$IEEE
          BOOT::|directoryp| boot::help boot::|version| boot::|pp|
@@ -76,7 +71,7 @@
          BOOT::|$InteractiveTimingStatsIfTrue|
BOOT::|$leaveLevelStack|
          BOOT::|$xyMin| BOOT::|lcm| BOOT::STRINGSUFFIX
          BOOT::|Category| BOOT::ESCAPE-CHARACTER
-         LISP:COUNT BOOT::|break| BOOT::$DIRECTORY
+         cl:COUNT BOOT::|break| BOOT::$DIRECTORY
          BOOT::CONVERSATION BOOT::|fillerSpaces|
          BOOT::$REVERSEVIDEOSTRING BOOT::|$DomainsInScope|
          BOOT::|$gauss01| BOOT::|$mostRecentOpAlist| BOOT::SUBLISLIS
@@ -169,7 +164,7 @@
          BOOT::|$userConstructors| BOOT::BOOT-NEQUAL BOOT::RPLAC
          BOOT::GETTAIL BOOT::|QuotientField| BOOT::CURRENT-TOKEN
          BOOT::|$suffix| BOOT::|$VariableCount| BOOT::COMPARE
-         LISP:SEQUENCE BOOT::|$Exit| BOOT::BOOT-EQUAL BOOT::LT
+         cl:SEQUENCE BOOT::|$Exit| BOOT::BOOT-EQUAL BOOT::LT
          VMLISP::OBEY BOOT::|UnSizedBox| BOOT::|Integer| BOOT::|Nud|
          BOOT::IOCLEAR BOOT::|$BigFloatOpt| BOOT::|$EmptyEnvironment|
          BOOT::|$forceDatabaseUpdate| BOOT::$LINESTACK BOOT::ULCASEFG
@@ -188,7 +183,7 @@
          BOOT::SPADCALL BOOT::DELASC BOOT::FAIL BOOT::$COMPILE
          BOOT::|$lastUntraced| BOOT::|$lisplibKind|
          BOOT::|$tracedModemap| BOOT::|$inputPromptType| BOOT::LASSOC
-         LISP:NUMBER BOOT::|$prefix| BOOT::|$TranslateOnly| BOOT::SAY
+         cl:NUMBER BOOT::|$prefix| BOOT::|$TranslateOnly| BOOT::SAY
          BOOT::|$CategoryFrame| BOOT::|$croakIfTrue| BOOT::|$exitMode|
          BOOT::|$lisplibDependentCategories| BOOT::|$NoValue|
          BOOT::MOAN BOOT::POP-STACK-2 BOOT::BAC
@@ -249,7 +244,7 @@
          BOOT::|$lisplibModemap| BOOT::|$NoValueMode|
BOOT::|$PrintBox|
          BOOT::ADVANCE-TOKEN BOOT::|$NegativeIntegerOpt|
          BOOT::|$polyDefaultAssoc| BOOT::|$PrimitiveDomainNames|
-         LISP:STEP BOOT::|rassoc| BOOT::|$Res|
+         cl:STEP BOOT::|rassoc| BOOT::|$Res|
          BOOT::MATCH-CURRENT-TOKEN BOOT::/GENSYMLIST BOOT::|$false|
          BOOT::|$ignoreCommentsIfTrue| BOOT::|$ModeVariableList|
          BOOT::|$useBFasDefault| BOOT::|$CommonDomains|
@@ -275,13 +270,13 @@
          BOOT::$DALYMODE))
 
 ;;; Definitions for package VMLISP of type EXPORT
-(lisp:in-package "VMLISP")
-(lisp:import '(
+(cl:in-package "VMLISP")
+(cl:import '(
 #+:GCL    SYSTEM:DEFINE-MACRO 
 #+:GCL    SYSTEM:MEMQ 
 #+:GCL    SYSTEM:PNAME
           BOOT:|directoryp|))
-(lisp:export
+(cl:export
     '(VMLISP::SINTP VMLISP::$FCOPY 
 #+:GCL    SYSTEM:DEFINE-MACRO 
 #+:GCL    SYSTEM:MEMQ 
@@ -401,21 +396,21 @@
          VMLISP::COMPILE-LIB-FILE
VMLISP::RECOMPILE-LIB-FILE-IF-NECESSARY))
 
 ;;; Definitions for package BOOT of type SHADOW
-(lisp:in-package "BOOT")
-(lisp:shadow '(BOOT::MAP))
-(lisp:import
-    '(VMLISP::ERROROUTSTREAM LISP:COUNT VMLISP::NE VMLISP::FLUID
-         LISP:SEQUENCE VMLISP::OBEY LISP::NUMBER VMLISP::|union|
-         LISP:STEP VMLISP::OPTIONLIST VMLISP::EXIT
VMLISP::LEXGREATERP))
-(lisp:import '(vmlisp::make-input-filename))
-(lisp:import '(vmlisp::libstream-dirname))
-(lisp:import '(user::spad-save))
-(lisp:import '(vmlisp::eqcar))
-(lisp:export '(boot::eqcar))
+(cl:in-package "BOOT")
+(cl:shadow '(BOOT::MAP))
+(cl:import
+    '(VMLISP::ERROROUTSTREAM cl:COUNT VMLISP::NE VMLISP::FLUID
+         cl:SEQUENCE VMLISP::OBEY cl::NUMBER VMLISP::|union|
+         cl:STEP VMLISP::OPTIONLIST VMLISP::EXIT VMLISP::LEXGREATERP))
+(cl:import '(vmlisp::make-input-filename))
+(cl:import '(vmlisp::libstream-dirname))
+(cl:import '(cl-user::spad-save))
+(cl:import '(vmlisp::eqcar))
+(cl:export '(boot::eqcar))
 
 ;;; Definitions for package VMLISP of type SHADOW
-(lisp:in-package "VMLISP")
-(lisp:import '(SYSTEM::DEFINE-MACRO SYSTEM::MEMQ SYSTEM::PNAME))
+(cl:in-package "VMLISP")
+#+gcl (cl:import '(SYSTEM::DEFINE-MACRO SYSTEM::MEMQ SYSTEM::PNAME))
 
 
 (in-package "BOOT") ;; Used to be "UNCOMMON"
@@ -549,183 +544,183 @@
 ))
 
 (in-package "BOOT")
-(lisp:export '(boot::ncloop boot::ncrecover))
-(lisp:import '(vmlisp::make-input-filename vmlisp::is-console))
-;; (lisp:import '(boot::|openServer|))
-;; (lisp:import '(boot::|sockGetInt|))
-;; (lisp:import '(boot::|sockSendInt|))
-;; (lisp:import '(boot::|sockGetInts|))
-;; (lisp:import '(boot::|sockSendInts|))
-;; (lisp:import '(boot::|sockGetString|))
-;; (lisp:import '(boot::|sockSendString|))
-;; (lisp:import '(boot::|sockGetFloat|))
-;; (lisp:import '(boot::|sockSendFloat|))
-;; (lisp:import '(boot::|sockGetFloats|))
-;; (lisp:import '(boot::|sockSendFloats|))
-;; (lisp:import '(boot::|sockSendWakeup|))
-;; (lisp:import '(boot::|sockSendSignal|))
-(lisp:import '(vmlisp::qsdifference))
-(lisp:import '(vmlisp::qsminusp))
-(lisp:import '(vmlisp::qsplus))
-(lisp:import '(vmlisp::absval))
-(lisp:import '(vmlisp::cgreaterp))
-(lisp:import '(vmlisp::char2num))
-(lisp:import '(vmlisp::charp))
-(lisp:import '(vmlisp::concat))
-(lisp:import '(vmlisp::copy))
-(lisp:import '(vmlisp::difference))
-(lisp:import '(vmlisp::digitp))
-(lisp:import '(vmlisp::divide))
-(lisp:import '(vmlisp::eqcar))
-(lisp:import '(vmlisp::fixp))
-(lisp:import '(vmlisp::greaterp))
-(lisp:import '(vmlisp::hasheq))
-(lisp:import '(vmlisp::hput))
-(lisp:import '(vmlisp::hrem))
-(lisp:import '(vmlisp::identp))
-(lisp:import '(vmlisp::lessp))
-(lisp:import '(vmlisp::ln))
-(lisp:import '(vmlisp::make-cvec))
-(lisp:import '(vmlisp::make-full-cvec))
-(lisp:import '(vmlisp::make-vec))
-#-(or :lispm :lucid) (lisp:import '(vmlisp::memq))
-#+(and :lucid (not :ibm/370)) (lisp:import '(system:memq))
-(lisp:import '(vmlisp::movevec))
-(lisp:import '(vmlisp::pname))
-(lisp:import '(vmlisp::prettyprin0))
-(lisp:import '(vmlisp::prettyprint))
-(lisp:import '(vmlisp::printexp))
-(lisp:import '(vmlisp::qassq))
-(lisp:import '(vmlisp::qcar))
-(lisp:import '(vmlisp::qcdr))
-(lisp:import '(vmlisp::qcaar))
-(lisp:import '(vmlisp::qcadr))
-(lisp:import '(vmlisp::qcdar))
-(lisp:import '(vmlisp::qcddr))
-(lisp:import '(vmlisp::qcaaar))
-(lisp:import '(vmlisp::qcaadr))
-(lisp:import '(vmlisp::qcadar))
-(lisp:import '(vmlisp::qcaddr))
-(lisp:import '(vmlisp::qcdaar))
-(lisp:import '(vmlisp::qcdadr))
-(lisp:import '(vmlisp::qcddar))
-(lisp:import '(vmlisp::qcdddr))
-(lisp:import '(vmlisp::qcaaaar))
-(lisp:import '(vmlisp::qcaaadr))
-(lisp:import '(vmlisp::qcaadar))
-(lisp:import '(vmlisp::qcaaddr))
-(lisp:import '(vmlisp::qcadaar))
-(lisp:import '(vmlisp::qcadadr))
-(lisp:import '(vmlisp::qcaddar))
-(lisp:import '(vmlisp::qcadddr))
-(lisp:import '(vmlisp::qcdaaar))
-(lisp:import '(vmlisp::qcdaadr))
-(lisp:import '(vmlisp::qcdadar))
-(lisp:import '(vmlisp::qcdaddr))
-(lisp:import '(vmlisp::qcddaar))
-(lisp:import '(vmlisp::qcddadr))
-(lisp:import '(vmlisp::qcdddar))
-(lisp:import '(vmlisp::qcddddr))
-(lisp:import '(vmlisp::qcsize))
-(lisp:import '(vmlisp::qenum))
-(lisp:import '(vmlisp::qeset))
-(lisp:import '(vmlisp::qlength))
-(lisp:import '(vmlisp::qmemq))
-(lisp:import '(vmlisp::qsadd1))
-(lisp:import '(vmlisp::qslessp))
-(lisp:import '(vmlisp::qsdec1))
-(lisp:import '(vmlisp::qsetvelt))
-(lisp:import '(vmlisp::qsgreaterp))
-(lisp:import '(vmlisp::qsinc1))
-(lisp:import '(vmlisp::qsmax))
-(lisp:import '(vmlisp::qsmin))
-(lisp:import '(vmlisp::qsoddp))
-(lisp:import '(vmlisp::qsquotient))
-(lisp:import '(vmlisp::qsremainder))
-(lisp:import '(vmlisp::qssub1))
-(lisp:import '(vmlisp::qstimes))
-(lisp:import '(vmlisp::qszerop))
-(lisp:import '(vmlisp::qszerop))
-(lisp:import '(vmlisp::qvelt))
-(lisp:import '(vmlisp::qvsize))
-(lisp:import '(vmlisp::setandfileq))
-(lisp:import '(vmlisp::sintp))
-(lisp:import '(vmlisp::size))
-(lisp:import '(vmlisp::stringimage))
-(lisp:import '(vmlisp::strpos))
-(lisp:import '(vmlisp::strposl))
-(lisp:import '(vmlisp::substring))
-;; (lisp:import '(boot::|error|))
-(lisp:import '(vmlisp::ivecp))
-(lisp:import '(vmlisp::rvecp))
-(lisp:import '(vmlisp::dig2fix))
-(lisp:import '(vmlisp::rnump))
-(lisp:import '(vmlisp::fix))
-(lisp:import '(vmlisp::sortgreaterp))
-(lisp:import '(vmlisp::qsort))
-(lisp:import '(vmlisp::sortby))
-(lisp:import '(vmlisp::make-instream))
-(lisp:import '(vmlisp::list2vec))
-(lisp:import '(vmlisp::vec2list))
-(lisp:import '(vmlisp::sub1))
-(lisp:import '(vmlisp::add1))
-(lisp:import '(vmlisp::neq))
-(lisp:import '(vmlisp::hashtable-class))
-(lisp:import '(vmlisp::maxindex))
-;; (lisp:import '(boot::remdup))
-(lisp:import '(vmlisp::upcase))
-(lisp:import '(vmlisp::downcase))
-(lisp:import '(vmlisp::vecp))
-(lisp:import '(vmlisp::strconc))
-(lisp:import '(vmlisp::defiostream))
-(lisp:import '(vmlisp::shut))
-(lisp:import '(vmlisp::prin2cvec))
-;; (lisp:import '(boot::lasttail))
-;; (lisp:import '(boot::lastpair))
-;; (lisp:import '(boot::lastatom))
-;; (lisp:import '(boot::|last|))
-(lisp:import '(vmlisp::ncons))
-(lisp:import '(vmlisp::rplpair))
-(lisp:import '(vmlisp::nump))
-(lisp:import '(vmlisp::intp))
-(lisp:import '(vmlisp::makeprop))
-(lisp:import '(vmlisp::ifcar))
-(lisp:import '(vmlisp::ifcdr))
-(lisp:import '(vmlisp::quotient))
-(lisp:import '(vmlisp::remainder))
-(lisp:import '(vmlisp::make-hashtable))
-(lisp:import '(vmlisp::hget))
-(lisp:import '(vmlisp::hkeys))
-(lisp:import '(vmlisp::$infilep))
-(lisp:import '(vmlisp::$findfile))
-(lisp:import '(vmlisp::pairp))
-(lisp:import '(vmlisp::cvec))
-(lisp:import '(vmlisp::uequal))
-(lisp:import '(vmlisp::id))
-(lisp:import '(vmlisp::vec-setelt))
-(lisp:import '(vmlisp::make-bvec))
-;; (lisp:import '(boot::bvec-make-full))
-;; (lisp:import '(boot::bvec-setelt))
-(lisp:import '(vmlisp::|shoeread-line|))
-(lisp:import '(vmlisp::|shoeInputFile|))
-(lisp:import '(vmlisp::|shoeConsole|))
-(lisp:import '(vmlisp::|startsId?|))
-(lisp:import '(vmlisp::|idChar?|))
-(lisp:import '(vmlisp::|npPC|))
-(lisp:import '(vmlisp::|npPP|))
-;; (lisp:import '(boot::mkprompt))
-;; (lisp:import '(boot::|fillerSpaces|))
-;; (lisp:import '(boot::|sayString|))
-;; (lisp:import '(boot::help))
-;; (lisp:import '(boot::|version|))
-;; (lisp:import '(boot::|pp|))
-;; (lisp:import '(boot::$dalymode))
+(cl:export '(boot::ncloop boot::ncrecover))
+(cl:import '(vmlisp::make-input-filename vmlisp::is-console))
+;; (cl:import '(boot::|openServer|))
+;; (cl:import '(boot::|sockGetInt|))
+;; (cl:import '(boot::|sockSendInt|))
+;; (cl:import '(boot::|sockGetInts|))
+;; (cl:import '(boot::|sockSendInts|))
+;; (cl:import '(boot::|sockGetString|))
+;; (cl:import '(boot::|sockSendString|))
+;; (cl:import '(boot::|sockGetFloat|))
+;; (cl:import '(boot::|sockSendFloat|))
+;; (cl:import '(boot::|sockGetFloats|))
+;; (cl:import '(boot::|sockSendFloats|))
+;; (cl:import '(boot::|sockSendWakeup|))
+;; (cl:import '(boot::|sockSendSignal|))
+(cl:import '(vmlisp::qsdifference))
+(cl:import '(vmlisp::qsminusp))
+(cl:import '(vmlisp::qsplus))
+(cl:import '(vmlisp::absval))
+(cl:import '(vmlisp::cgreaterp))
+(cl:import '(vmlisp::char2num))
+(cl:import '(vmlisp::charp))
+(cl:import '(vmlisp::concat))
+(cl:import '(vmlisp::copy))
+(cl:import '(vmlisp::difference))
+(cl:import '(vmlisp::digitp))
+(cl:import '(vmlisp::divide))
+(cl:import '(vmlisp::eqcar))
+(cl:import '(vmlisp::fixp))
+(cl:import '(vmlisp::greaterp))
+(cl:import '(vmlisp::hasheq))
+(cl:import '(vmlisp::hput))
+(cl:import '(vmlisp::hrem))
+(cl:import '(vmlisp::identp))
+(cl:import '(vmlisp::lessp))
+(cl:import '(vmlisp::ln))
+(cl:import '(vmlisp::make-cvec))
+(cl:import '(vmlisp::make-full-cvec))
+(cl:import '(vmlisp::make-vec))
+#-(or :lispm :lucid) (cl:import '(vmlisp::memq))
+#+(and :lucid (not :ibm/370)) (cl:import '(system:memq))
+(cl:import '(vmlisp::movevec))
+(cl:import '(vmlisp::pname))
+(cl:import '(vmlisp::prettyprin0))
+(cl:import '(vmlisp::prettyprint))
+(cl:import '(vmlisp::printexp))
+(cl:import '(vmlisp::qassq))
+(cl:import '(vmlisp::qcar))
+(cl:import '(vmlisp::qcdr))
+(cl:import '(vmlisp::qcaar))
+(cl:import '(vmlisp::qcadr))
+(cl:import '(vmlisp::qcdar))
+(cl:import '(vmlisp::qcddr))
+(cl:import '(vmlisp::qcaaar))
+(cl:import '(vmlisp::qcaadr))
+(cl:import '(vmlisp::qcadar))
+(cl:import '(vmlisp::qcaddr))
+(cl:import '(vmlisp::qcdaar))
+(cl:import '(vmlisp::qcdadr))
+(cl:import '(vmlisp::qcddar))
+(cl:import '(vmlisp::qcdddr))
+(cl:import '(vmlisp::qcaaaar))
+(cl:import '(vmlisp::qcaaadr))
+(cl:import '(vmlisp::qcaadar))
+(cl:import '(vmlisp::qcaaddr))
+(cl:import '(vmlisp::qcadaar))
+(cl:import '(vmlisp::qcadadr))
+(cl:import '(vmlisp::qcaddar))
+(cl:import '(vmlisp::qcadddr))
+(cl:import '(vmlisp::qcdaaar))
+(cl:import '(vmlisp::qcdaadr))
+(cl:import '(vmlisp::qcdadar))
+(cl:import '(vmlisp::qcdaddr))
+(cl:import '(vmlisp::qcddaar))
+(cl:import '(vmlisp::qcddadr))
+(cl:import '(vmlisp::qcdddar))
+(cl:import '(vmlisp::qcddddr))
+(cl:import '(vmlisp::qcsize))
+(cl:import '(vmlisp::qenum))
+(cl:import '(vmlisp::qeset))
+(cl:import '(vmlisp::qlength))
+(cl:import '(vmlisp::qmemq))
+(cl:import '(vmlisp::qsadd1))
+(cl:import '(vmlisp::qslessp))
+(cl:import '(vmlisp::qsdec1))
+(cl:import '(vmlisp::qsetvelt))
+(cl:import '(vmlisp::qsgreaterp))
+(cl:import '(vmlisp::qsinc1))
+(cl:import '(vmlisp::qsmax))
+(cl:import '(vmlisp::qsmin))
+(cl:import '(vmlisp::qsoddp))
+(cl:import '(vmlisp::qsquotient))
+(cl:import '(vmlisp::qsremainder))
+(cl:import '(vmlisp::qssub1))
+(cl:import '(vmlisp::qstimes))
+(cl:import '(vmlisp::qszerop))
+(cl:import '(vmlisp::qszerop))
+(cl:import '(vmlisp::qvelt))
+(cl:import '(vmlisp::qvsize))
+(cl:import '(vmlisp::setandfileq))
+(cl:import '(vmlisp::sintp))
+(cl:import '(vmlisp::size))
+(cl:import '(vmlisp::stringimage))
+(cl:import '(vmlisp::strpos))
+(cl:import '(vmlisp::strposl))
+(cl:import '(vmlisp::substring))
+;; (cl:import '(boot::|error|))
+(cl:import '(vmlisp::ivecp))
+(cl:import '(vmlisp::rvecp))
+(cl:import '(vmlisp::dig2fix))
+(cl:import '(vmlisp::rnump))
+(cl:import '(vmlisp::fix))
+(cl:import '(vmlisp::sortgreaterp))
+(cl:import '(vmlisp::qsort))
+(cl:import '(vmlisp::sortby))
+(cl:import '(vmlisp::make-instream))
+(cl:import '(vmlisp::list2vec))
+(cl:import '(vmlisp::vec2list))
+(cl:import '(vmlisp::sub1))
+(cl:import '(vmlisp::add1))
+(cl:import '(vmlisp::neq))
+(cl:import '(vmlisp::hashtable-class))
+(cl:import '(vmlisp::maxindex))
+;; (cl:import '(boot::remdup))
+(cl:import '(vmlisp::upcase))
+(cl:import '(vmlisp::downcase))
+(cl:import '(vmlisp::vecp))
+(cl:import '(vmlisp::strconc))
+(cl:import '(vmlisp::defiostream))
+(cl:import '(vmlisp::shut))
+(cl:import '(vmlisp::prin2cvec))
+;; (cl:import '(boot::lasttail))
+;; (cl:import '(boot::lastpair))
+;; (cl:import '(boot::lastatom))
+;; (cl:import '(boot::|last|))
+(cl:import '(vmlisp::ncons))
+(cl:import '(vmlisp::rplpair))
+(cl:import '(vmlisp::nump))
+(cl:import '(vmlisp::intp))
+(cl:import '(vmlisp::makeprop))
+(cl:import '(vmlisp::ifcar))
+(cl:import '(vmlisp::ifcdr))
+(cl:import '(vmlisp::quotient))
+(cl:import '(vmlisp::remainder))
+(cl:import '(vmlisp::make-hashtable))
+(cl:import '(vmlisp::hget))
+(cl:import '(vmlisp::hkeys))
+(cl:import '(vmlisp::$infilep))
+(cl:import '(vmlisp::$findfile))
+(cl:import '(vmlisp::pairp))
+(cl:import '(vmlisp::cvec))
+(cl:import '(vmlisp::uequal))
+(cl:import '(vmlisp::id))
+(cl:import '(vmlisp::vec-setelt))
+(cl:import '(vmlisp::make-bvec))
+;; (cl:import '(boot::bvec-make-full))
+;; (cl:import '(boot::bvec-setelt))
+(cl:import '(vmlisp::|shoeread-line|))
+(cl:import '(vmlisp::|shoeInputFile|))
+(cl:import '(vmlisp::|shoeConsole|))
+(cl:import '(vmlisp::|startsId?|))
+(cl:import '(vmlisp::|idChar?|))
+(cl:import '(vmlisp::|npPC|))
+(cl:import '(vmlisp::|npPP|))
+;; (cl:import '(boot::mkprompt))
+;; (cl:import '(boot::|fillerSpaces|))
+;; (cl:import '(boot::|sayString|))
+;; (cl:import '(boot::help))
+;; (cl:import '(boot::|version|))
+;; (cl:import '(boot::|pp|))
+;; (cl:import '(boot::$dalymode))
 
-(lisp:import 'boot::$IEEE)
+(cl:import 'boot::$IEEE)
 
 (in-package "FOAM")
 
-(lisp:export '(
+(cl:export '(
 FOAM::|printDFloat|
 FOAM::|printSFloat|
 FOAM::|printBInt|

\start
Date: Sat, 5 Aug 2006 08:45:00 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Some latex packages that may help with multiple individual files in books

--- Ralf Hemmecke wrote:

> 1) If you need to edit the pamphlet files to make them work in the 
> context of a big book. That sounds as if you have too much time to
> spare.

Not really.  I take it you regard the idea as frivolous?
 
> 2) Where are our priorities? Improving LaTeX or improving
> computational mathematics?

As a literate project I would think typesetting technology and
conventations are very important to our effort.  Also different members
of the project with different skill sets may have varying priorities -
those less skilled as mathematical researchers can attack other
problems.

> I could imagine to impose restrictions on the LaTeX packages that are
> approved be used inside an Axiom pamphlet. But do you know all the
> LaTeX packages and the preferences of authors that you feel able to
> decide which package to allow and which package to forbid? I don't.

Surely it could be discussed as it came up.  I don't imagine there
would be more than a dozen or so key packages (some of which are
already on our radar screen) and if over time a few more came up we
could deal with it on a case by case basis.

> Hmm, yes, you could call it a bug. In fact, I know LaTeX not well
> enough to understand why it is so difficult to set up a wrapper file
> around a collection of latex files so that each file would appear
> (nearly) identical to the way it would appear as dvi when compiled
> separately.

Because latex packages sometimes change the way output is produced from
commands.  If two different packages redefine the same command, there
is a collision and one of the papers won't get what it expects.  More
difficult, sometimes there are mutually exclusive options which must be
resolved one way or another between packages.

> The collection should, of course produce running page numbers.

There are also desirable features such as a common table of contents
and index.


> What I don't believe is that you can convince package authors to take
> every effort to keep their package compatible with any other package
> out there. Some people just write a package because they need it for
> their work and then suddenly it becomes useful for others. The was
> probably only a question that the package need to be compatible with
> packages that the original author used.

Probably.  But then, for the purposes of Axiom, why not take that
package to the next level and make it a more general tool?  I fully
expect that Axiom will eventually push the bounds of LaTeX's
typesetting abilities, and I think this is a good thing.  Human
readable mathematical documents are a very interesting problem in
themselves - Knuth solved many of those problems well but some things
like automatic line breaking are still imperfectly solved, at best.

Anyway.  It's possible I am underestimating the difficulties involved,
but the only way to know for sure is experimentation.

\start
Date: Sat, 5 Aug 2006 13:58:52 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Translation of the interp to lisp

> A question Tim, if I may.  In looking at sys-pkg.lisp, it seems like
> there are a rather large number of import and export commands contained
> there.  Is this normal in lisp to have to hand-import and hand-export
> so many symbols?  Also, I'm a bit confused by the BOOT and VMLISP
> package relations - are they in fact cross-pollinating and importing
> from/exporting to each other?  If so, wouldn't it be a bit cleaner to
> get the common functionality into one package and have both BOOT and
> VMLISP use that one?

Note that Axiom was written before common lisp existed. The initial
common lisps and other prior lisps (like MACLISP, VMLISP, etc) did
not have the idea of a "package" so I had to globally modify the
code to make it work in common lisp (some of which had incompatible
implementations before the standard).

SYS-PKG was a hack to enable/disable package symbols in various lisps.
It is poorly designed, badly implemented, horribly documented, and
unmaintained. I think they should transfer the programmer who wrote
it to a non-lisp related job or (equivalently) lift his license to 
program. In short, it is a hack and will go away in the rewrite.

\start
Date: Sat, 05 Aug 2006 15:07:26 -0700
From: Arthur Ralfs
To: list
Subject: tex to mathml

Hello,

I'm working on a tex to mathml program in C.  It's rudimentary and
only meant to transform the stuff between the $$ signs that comes
out of axiom so it can be displayed in firefox.  However it seems
to work so I thought I should make it available in case someone
was interested. 

My question is what license I should use?  My first inclination is to
use the GPL except that axiom is released under the BSD license.
Does it make any difference?

\start
Date: Sat, 5 Aug 2006 18:43:10 -0400
From: Bill Page
To: Arthur Ralfs
Subject: RE: tex to mathml

On August 5, 2006 6:07 PM Arthur Ralfs wrote:
> 
> I'm working on a tex to mathml program in C.  It's rudimentary
> and only meant to transform the stuff between the $$ signs that
> comes out of axiom so it can be displayed in firefox.  However
> it seems to work so I thought I should make it available in case
> someone was interested.

Yes please do. I am definitely interested. I presume that you are
aware that there exist a few other packages that do this? Bob
McElrath has done some work with integrating MathML output with
LatexWiki - the software on which the Axiom Wiki is based. See:

http://mcelrath.org/Notes/LatexWiki

But we have not yet adopted any of these methods for use with
Axiom.

> 
> My question is what license I should use?  My first inclination
> is to use the GPL except that axiom is released under the BSD
> license. Does it make any difference?
> 

In my opinion definitely GPL, but no it does really make much
difference.

\start
Date: Sun, 06 Aug 2006 02:04:59 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis,
Subject: rhxtangle

Hi Gaby,

it turned out that it is not totally easy to mimic the behaviour of 
notangle, in particular if multiline chunks have to be indented correctly.

Below you find rhxtangle.pl.pamphlet. I hope you find it useful to drop 
the initial noweb dependency for the configuration phase of Axiom.

--------------010907050400000300040807
 name="rhxtangle.pl.pamphlet"
 filename="rhxtangle.pl.pamphlet"

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% rhxtangle.pl
% Copyright (C) 06-Aug-2006  Ralf Hemmecke
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% noweave -delay rhxtangle.pl.pamphlet > rhxtangle.tex
% latex rhxtangle.tex
% makeindex rhxtangle
% latex rhxtangle.tex
% 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\documentclass{article}
\usepackage{axiom}
\usepackage{noweb}
\usepackage{makeidx}
\makeindex
\usepackage{hyperref}

\newcommand{\file}[1]{\textsf{#1}}
\newcommand{\email}[1]{\url{#1}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Definition taken from allprose.sty
\makeatletter
\def\xnamedefstyle{\textsc}
\def\xnamedef#1{\@ifnextchar[%
  {\@xnamedef{#1}}%
  {\@xnamedef{#1}[#1@\xnamedefstyle{#1}]}}
\def\@xnamedef#1[#2]#3{%
  \expandafter\def\csname x#1\endcsname{\@@xnamedef{#1}{#2}{#3}}}
\def\@@xnamedef#1#2#3{%
  \@ifundefined{!x#1}{%
    \defineterm{#2}%
    \footnote{\href{#3}{\useterm{#2}: \url{#3}}}%
    \expandafter\gdef\csname !x#1\endcsname{}%
  }{\useterm{#2}}}
\def\rhxterm{%
  \def\xnamedef##1{\@xnamedef{##1}[##1]}%
  \def\useterm##1{##1}%
  \def\defineterm##1{##1}%
}
\makeatother
\IfFileExists{rhxterm.sty}{\usepackage{rhxterm}}{\rhxterm}
  

\xnamedef{Automake}{http://www.gnu.org/}
\xnamedef{Axiom}{http://www.axiom-developer.org/}
\xnamedef{Noweb}{http://www.eecs.harvard.edu/~nr/noweb}
\xnamedef{Perl}{http://www.perl.org}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\title{A Poor Man's NoTangle}
\author{Ralf Hemmecke}

\begin{document}
\maketitle

\begin{abstract}
  In order to drop the dependency of the configuration step of
  \xAxiom{} on \xNoweb{} we present a \xPerl{} program that basically
  behaves like a simple version of the \texttt{notangle} program from
  \xNoweb{}.
\end{abstract}

\tableofcontents

\section{Introduction}
\xAxiom{} is written in a literate programming style using \xNoweb{}.
That means that (nearly) all sourcefiles of \xAxiom{} are actually
\LaTeX{} files with additional code chunks that are of the form
\begin{verbatim}
@<<code chunk name@>>=
some code comes here
@@
\end{verbatim}
These special files are known to \xAxiom{} developers as
\defineterm{pamphlet} files and come with the extension
\texttt{.pamphlet}. The source file of this text is one example of a
\useterm{pamphlet} file.

Since also the configuration files for \xAxiom{} should be written as
\useterm{pamphlet} files, it would be nice to depend on as few
prerequisites as possible. \xNoweb{} is not by default installed on
every computer. We replace a dependency on \xNoweb{} by a dependency
on \xPerl{} since \xAutomake{} from the GNU Autotools depends on
\xPerl{}, too and writing the script is relatively easy.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{What do we want?}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The script should be called via
\begin{verbatim}
perl rhxtangle.pl file.ext.pamphlet > file.ext
\end{verbatim}
in order to tangle the code in the same way \texttt{notangle} does.

The output of \texttt{rhxtangle} and \texttt{notangle} should be
identical modulo the translation of tabs to spaces done by
\texttt{notangle} and modulo spaces at the end of a line.

Currently \texttt{rhxtangle} does not translate tabulators to spaces
and removes trailing spaces and tabulators.

In order to keep our script simple, we impose some restrictions to the
file format.

\begin{enumerate}
\item We only accept one file on the command line and no options.
\item Code chunks \emph{must} be ended by an \verb'@' sign in the
  first column.
\item Inside code chunks an \verb'@' sign is forbidden in the first
  column.
\item Double square brackets may not appear inside double angle
  brackets.
\item A code chunk name may not contain \verb'@<<' or \verb'@>>', not
  even if they are escaped by an \verb'@' sign.
\item Double angle brackets, i.e. \verb'@<<', that should not be
  considered as part of a code chunk use \emph{must} be escaped by
  \verb'@'.
\item No translation of initial whitespace takes place, so it is
  important for Makefile to already contain tabulator characters at
  the corresponding places.  
\end{enumerate}

The last item is a major difference between our implementation and
\texttt{notangle}.





%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{How to extract code chunks?}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The input file can basically be seen as a collection of code chunks.

Our script works in two passes.

<<*>>=
<<global variables>>
<<read the code chunks from stdin>>
<<write code chunks to stdout>>
@





%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Reading the code chunks from standard input}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

We are going to store every chunk into a hashtable that is indexed by
the chunk name.

<<global variables>>=
%chunks = ();
$chunkname = "";
@
%$

Our script skips everything that is not between an initial code chunk
definition of the form \verb'@<<chunk definition@>>=' and the following
\verb'@' in the first columm.

<<read the code chunks from stdin>>=
while (<>) {
    chomp; # strip off trailing newline character
    if (/^@<<(.+)@>>=\s*$/) { #chunk definition
        $chunkname = $1;
        if (! defined($chunks{$chunkname})) {$chunks{$chunkname} = []}
        next;
    }
    if (/^@/) {$chunkname = ""; next} #chunk end
    if ($chunkname eq "") {next} #skip non-code-chunk lines
    push @{$chunks{$chunkname}}, $_; #append $_ at the end of the list
}
@
%$

After executing the above code, the hash variable \verb'%chunks' %$
contains all the code chunk lines where lines that came from
chunks with identical name have already been joined.











%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Writing the code chunks to standard output}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Writing out the code is done recursively starting with the code chunk
\verb'@<<*@>>'. Since [[printCodeChunk]] does not add a final newline,
we do it afterwards explicitly and thus trigger a flushing of an
internal buffer.
 
<<write code chunks to stdout>>=
&printCodeChunk('*', '');
&printout("\n");
<<printCodeChunk>>
@

The function \verb'printCodeChunk' takes the name of the chunk and the
amount of whitespace that must be printed after each newline in a
multiline code chunk.

If \texttt{notangle} sees the use of a code chunk in a line it
replaces that with the text from that code chunk. Where a trailing
newline in the code chunk text is removed.

For single line chunk text the replacement is simple. For multiline
text, \texttt{notangle} adds spaces after a newline so that the chunk
is basically shifted as a whole.

If the first \verb'<' of the code chunk use starts in column $n$ and
the corresponding code chunk represents multiple lines, then after
each newline $n$ spaces are added.

Let us take the following file, which we name \file{example.nw}.
<<example.nw>>=
@<<*@>>=
Text1
     @<<C1@>>@<<C1@>>Text2
      Text3
@@
@<<C1@>>=
TextC11
    @<<C2@>>@<<C2@>>
TextC12
@@
@<<C2@>>=
TextC21
TextC22
@@
@

Running
\begin{verbatim}
notangle example.nw > ex.1
\end{verbatim}
yields the following output.
\begin{verbatim*}
Text1
     TextC11
         TextC21
         TextC22TextC21
               TextC22
     TextC12TextC11
               TextC21
               TextC22TextC21
                     TextC22
           TextC12Text2
      Text3
\end{verbatim*}

For a Makefile one usually adds the command line switch \verb'-t8'.
The command
\begin{verbatim}
notangle -t8 example.nw > ex.2
\end{verbatim}
yields the following text, where we have replaced tabulator characters
by arrows in order to show them here. (Note that there appears
\emph{no} tabulator character in the third line.
\begin{verbatim*}
Text1
     TextC11
         TextC21
|------> TextC22TextC21
|------>       TextC22
     TextC12TextC11
|------>       TextC21
|------>       TextC22TextC21
|------>|------>     TextC22
|------>   TextC12Text2
      Text3
\end{verbatim*}

Our program behaves differently. Instead of adding a fixed amount of
spaces \texttt{rhxtangle} concatenates initial whitespace that appears
in the input line and only adds spaces to account for positioning
the second use of \verb'@<<C1@>>' in the file \file{example.nw}.

Executing
\begin{verbatim}
perl rhxtangle.pl example.nw > ex.3
\end{verbatim}
results in a file that is identical to \file{ex.1}.


In the function [[printCodeChunk]] we use an auxiliary function
[[printout]] which delays the actual output and removes the escape
character \verb'@' and trainling spaces.

<<printCodeChunk>>=
<<printout>>
@


The function [[printCodeChunk]] is called recursively for each use of
a code chunk inside a line.
<<printCodeChunk>>=
sub printCodeChunk {
    my($chunkname, $indentation) = @_;
    my($nextIndentation, $chars, $rest) = ($indentation, "", "");
    my($chunkNameUse) = ("");
    my(@lines, $line);
    if (! defined($chunks{$chunkname})) {
        print STDOUT "\nrhxtangle: Undefined chunkname @<<$chunkname@>>\n";
        die "rhxtangle: Undefined chunkname @<<$chunkname@>>\n";
    }
    @lines = @{$chunks{$chunkname}};
    if (scalar(@lines) == 0) {return}

    <<handle first of the @lines array and prepare for next>>

    while (scalar(@lines) > 0) { #more than one line left
        &printout("$line\n$indentation"); #print leftover from last round
        <<handle first of the @lines array and prepare for next>>
    }
    &printout($line); #print leftover from last round
}
@ %def printCodeChunk
%$
Note that there is no newline printed at the end of [[printCodeChunk]].


The following code chunk treats exactly one input line.
It scans for code chunk uses and replaces them by the corresponding
text by recursively calling the function [[printCodeChunk]].

<<handle first of the @lines array and prepare for next>>=
$line = shift @lines;
$nextIndentation = $indentation;
while ($line =~ /^(.*?)(.)?@<<(.*?[^@])@>>(.*)/) {
    $chars = "$1$2";
    $chunkNameUse = $3;
    $rest = $4;

    &printout($chars);
    <<replace non-tabulator characters in 'chars' by spaces>>
    $nextIndentation .= $chars;

    if ($2 eq "@") { # the @<< is escaped --> no chunk use
        &printout("@<<");
        $nextIndentation .= "  "; # for @<<
        $line = "$chunkNameUse@>>$rest";
        next;
    }
    $chars = "@<<$chunkNameUse@>>";
    <<replace non-tabulator characters in 'chars' by spaces>>
    &printCodeChunk($chunkNameUse, $nextIndentation);
    $nextIndentation .= $chars;
    $line = $rest;
}
@
%$

<<replace non-tabulator characters in 'chars' by spaces>>=
$chars =~ s/[^\t]/ /g;
@
%$

The [[printout]] function first buffers strings that it gets as input
until a newline character is detected. The newline character triggers
the actual output.

Before the line is actually written to standard output, trailing
whitespace are removed and escaped sequences are resolved.

<<global variables>>=
$printoutBuffer = '';
@

<<printout>>=
sub printout {
    my($str) = @_;
    while ($str =~ /(.*?)\n(.*)/) {
        $printoutBuffer .= $1;
        $str = $2;
        <<flush printoutBuffer>>
        print "\n";
    }
    $printoutBuffer .= $str;
}
@ %def printout

<<flush printoutBuffer>>=
$printoutBuffer =~ s/\s*$//;
$printoutBuffer =~ s/@(@<<|@>>)/$1/g;
print $printoutBuffer;
$printoutBuffer = '';
@
%$





%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Tests}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Testing \texttt{rhxtangle} basically means to compare its output with
the output of \texttt{notangle}. There should be only spacing
differences for relevant files.
So we produce below a short script that could be extracted via
\begin{verbatim}
notangle -Rrhxtangletest.pl rhxtangle.pl.pamphlet > rhxtangletest.pl
\end{verbatim}
and run via
\begin{verbatim}
perl rhxtangletest.pl
\end{verbatim}

That program lists relevant files and compares the output with that
ouf \texttt{notangle}.

In fact, if the function [[tab2spc]] is applied in the function
[[printout]] before actually writing to stdout, the script
\texttt{rhxtangle} would be closer to \texttt{notangle} called without
the option \verb'-t8'.

We believe however that \texttt{rhxtangle} is good enough as a ``poor
man's replacement for \texttt{notangle}''.

<<rhxtangletest.pl>>=
<<tab2spc>>
@files=`find . -name '*.pamphlet'`;

for $f (@files) {
    chomp $f;
    $f =~ s/\.pamphlet$//;
    if ($f =~ /\.bib$/) {next}
    #print ":: $f\n";
    if ($f =~ /Makefile/) {$opt="-t8"} else {$opt=''}
    @no = `notangle $opt     $f.pamphlet`;
    @rh = `perl rhxtangle.pl $f.pamphlet`;
    if (scalar(@no) != scalar(@rh)) {
        print "Different number of lines. [$f]\n";
    }
    while (scalar(@no) > 0) {
	$n = shift @no; $n =~ s/\s*$//;
        $r = shift @rh; $r =~ s/\s*$//;
	if ($n ne $r) {
            $nn = &tab2spc($n); $n =~ s/[\t]/_/g;
            $rr = &tab2spc($r); $r =~ s/[\t]/_/g;
            if ($nn ne $rr) {
                $nn =~ s/[\t]/_/g;
                $rr =~ s/[\t]/_/g;
                print "[[[$f]]]\n";
                print "n $nn\n";
                print "r $rr\n";
            }
        }
    }
}
@

<<tab2spc>>=
sub tab2spc {
    my($s) = @_;
    my($p) = index($s, "\t");
    while($p != -1) {
	# $q = (8 - ($p % 8)); print "$q <-- $p\n";
	$sp = ''; for (1 .. (8 - ($p % 8))) {$sp .= " "}
        $s =~ s/\t/$sp/;
        $p = index($s, "\t");
    }
    $s;
}
@ %def tab2spc

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% We want the name of the section and the hypertarget command on the
% same page, but \printindex issues \clearpage. Thus we do it by hand
% her and redefine \clearpage.
{\let\rhxclearpage\clearpage%
\clearpage%
\renewcommand{\clearpage}{\def\clearpage{\rhxclearpage}}%
\hypertarget{sec:Index}{}%
\printindex
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
--------------010907050400000300040807--

\start
Date: Sun, 06 Aug 2006 02:17:05 +0200
From: Ralf Hemmecke
To: list
Subject: pamphlet problems

In order to remove the need to distribute a version of noweb with Axiom, 
we must modify the sources a bit.

I've run every .pamphlet file from silver/branches/build-improvements 
through noweb.

There are the following problems

notangle src/hyper/token.pamphlet > dummy
undefined chunk name: <<token.c>>

notangle src/doc/primesp.spad.pamphlet > dummy
The root module <<*>> was not defined.

rhx: The file src/doc/primesp.spad.pamphlet is a pure latex file. But 
the .spad extension is quite misleading.

There are more files under src/doc that happen to have no <<*>> chunk, 
but the above .spad file looks most strange.

\start
Date: Sat, 5 Aug 2006 17:30:39 -0700
From: Bob McElrath
To: Arthur Ralfs
Subject: Re: tex to mathml

Arthur Ralfs [Arthur Ralfs] wrote:
> Hello,
> 
> I'm working on a tex to mathml program in C.  It's rudimentary and
> only meant to transform the stuff between the $$ signs that comes
> out of axiom so it can be displayed in firefox.  However it seems
> to work so I thought I should make it available in case someone
> was interested. 

Are you familiar with itex2mml?  It uses lex/yacc so ultimately it's a C
program.  I have an adaptation in python that I haven't released...

Do you have something working that displays axiom in firefox?

I think ultimately it's a better idea to get axiom to output mathml
directly, rather than insert yet-another translation layer (and
therefore, another layer of confusion and bugs) between the program and
the user.

> My question is what license I should use?  My first inclination is to
> use the GPL except that axiom is released under the BSD license.
> Does it make any difference?

How do you intend this to used WRT axiom?  Also remember that as the
author you're free to change the license later.  (But old versions will
still fall under old licenses...)  If you start accepting patches from
other people, it becomes difficult to change the license because
contributors generally contribute with an understanding of the current
license, and you'd have to get their permission to change licenses.

\start
Date: Sat, 05 Aug 2006 21:37:50 -0500
From: Jay Belanger
To: Bill Page
Subject: Re: Front page esthetic

Bill Page writes:
...
>> ...
>> > | 2) The Axiom Wiki FrontPage has more graphics including an
>> > |    example Axiom output graphic.
>> >
>> > That, from my perspective, contributes to the "visual load".
>>
>> I agree with this,
>
> :( Well, I really like the example ... in fact I have even given
> a wild thought to how we might make the from page choose randomly
> between a large set of similar examples so that a visitor might
> be treated to a new one at each visit ...

That's a pretty neat idea.

> I still don't know what is meant by the phrase "visual load".

Too many things calling for their attention at the same time.
This doesn't seem to be a problem anymore.

>> but what's more, I don't think that linking "Try Axiom" to the
>> SandBox is that helpful.
>
> Really??! As far as I can see this is actually one of the most
> frequently used wiki features of this web site.

That just means that people want to try Axiom out than add anything to
the wiki.

>> If a visitor to the webpage wants to give Axiom a quick try,
>> sending them to a lengthy discussion of the sandbox might be
>> discouraging.
>
> Perhaps it is verbose but it does not seem to be very discouraging
> given the number of quick tries that we record.

Well, then, I'm wrong.  It would discourage me, but perhaps the
typical visitor is more wiki savvy than I am.

>> Perhaps a link to a "Trying Axiom" page which has a couple of
>> lines of how to try it out might be helpful.  I'd be happy to
>> give it a shot myself, if desired.
>
> Yes, I think it is very desirable. Please give it a try.

Okay, but according to your numbers, it isn't very important.

>> I think a link to a page which interactively runs Axiom would
>> be more desirable: Yacas has something
>> like that (Yacas runs in a Java applet:
>> http://yacas.sourceforge.net/yacasconsole.html)
>>  and Maxima does also (http://math.msarnoff.org/).
>
> To me these interfaces seem trivial and nearly useless. But if we
> really do want something like this then it is easily done.

If I want to try out a command line program (like Axiom), I'd like to
just enter a command and see what happens, rather than edit a wiki.
But I guess that's just me.

> Yes, it has gone through quite a few revisions over the last
> 6 months and it is still evolving. It is a community effort.

Yes, but you seem to be in charge of the community effort.  So let me
add my voice to all the thanks you've been getting!

\start
Date: Sun, 6 Aug 2006 10:51:15 +0200
From: Antoine Hersen
To: Jay Belanger
Subject: Re: Front page esthetic

Hello,

About the example on the front page. It is astehetic but the type result is
almost the equivalent to any.

I do not have super good replament idea.
But I will proprose some Taylor expansion maybe ?

Regards,
Antoine Hersen


On 8/6/06, Jay Belanger wrote:
>
>
> Bill Page writes:
> ...
> >> ...
> >> > | 2) The Axiom Wiki FrontPage has more graphics including an
> >> > |    example Axiom output graphic.
> >> >
> >> > That, from my perspective, contributes to the "visual load".
> >>
> >> I agree with this,
> >
> > :( Well, I really like the example ... in fact I have even given
> > a wild thought to how we might make the from page choose randomly
> > between a large set of similar examples so that a visitor might
> > be treated to a new one at each visit ...
>
> That's a pretty neat idea.
>
> > I still don't know what is meant by the phrase "visual load".
>
> Too many things calling for their attention at the same time.
> This doesn't seem to be a problem anymore.
>
> >> but what's more, I don't think that linking "Try Axiom" to the
> >> SandBox is that helpful.
> >
> > Really??! As far as I can see this is actually one of the most
> > frequently used wiki features of this web site.
>
> That just means that people want to try Axiom out than add anything to
> the wiki.
>
> >> If a visitor to the webpage wants to give Axiom a quick try,
> >> sending them to a lengthy discussion of the sandbox might be
> >> discouraging.
> >
> > Perhaps it is verbose but it does not seem to be very discouraging
> > given the number of quick tries that we record.
>
> Well, then, I'm wrong.  It would discourage me, but perhaps the
> typical visitor is more wiki savvy than I am.
>
> >> Perhaps a link to a "Trying Axiom" page which has a couple of
> >> lines of how to try it out might be helpful.  I'd be happy to
> >> give it a shot myself, if desired.
> >
> > Yes, I think it is very desirable. Please give it a try.
>
> Okay, but according to your numbers, it isn't very important.
>
> >> I think a link to a page which interactively runs Axiom would
> >> be more desirable: Yacas has something
> >> like that (Yacas runs in a Java applet:
> >> http://yacas.sourceforge.net/yacasconsole.html)
> >>  and Maxima does also (http://math.msarnoff.org/).
> >
> > To me these interfaces seem trivial and nearly useless. But if we
> > really do want something like this then it is easily done.
>
> If I want to try out a command line program (like Axiom), I'd like to
> just enter a command and see what happens, rather than edit a wiki.
> But I guess that's just me.
>
> > Yes, it has gone through quite a few revisions over the last
> > 6 months and it is still evolving. It is a community effort.
>
> Yes, but you seem to be in charge of the community effort.  So let me
> add my voice to all the thanks you've been getting!

\start
Date: 06 Aug 2006 07:25:32 +0200
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] progress on X11 locations

  The patch below takes a step further in dealing with X11 header
files and archive locations.  As I mentioned earlier, the solution is
to delegate this delicate problem to Autoconf.  Indeed, Autoconf comes
with a macro (AC_PATH_XTRA) that does quite extensive and elaborate
tests to figure out which -I, -L, and -l flags are needed to compiler
and link a program using X11.  If you believe that this problem can be
easily dealt with by special-casing makefiles, have a look at the
configure file generated by Autoconf -- that should give you an idea
of the extent of the variabilities.

  Concretely, this patch takes care of the build failure I reported
here 

   http://lists.nongnu.org/archive/html/axiom-developer/2006-07/msg00242.html

I complete a successful build on that machine.  I suspect this cures
the problems on many other platforms that are not special-cased in the
top-level Makefiles.  I suspect I also break builds on some other
machines, so you can test, please give it a try.  Check out the
build-improvements branch, configure, and make.


  There remains the issue of Xpm.  That library is very curious.  It
had been deprecated, replaced with xpm-nox, resurrected, and still not
widely supported.  A long term fix in Axiom is to move away from it
(no, don't think about including a copy of it in Axiom!).  A
short-term fix may be of:

   (1) abort configuration if Xpm is missing -- not my favour
   (2) don't build parts of Axiom that uses Xpm, if it is missing.
   (3) do (2), but allow users to specify Xpm locations.
   (4) do (3), but include configure test to detect it -- sounds nice.

I'm including toward (4) but I don't have time to implement it right now.

Generated files are not included in the patch.


Tested on x86_64-suse-linux
          i686-suse-linux

-- Gaby

2006-08-05  Gabriel Dos Reis  Gabriel Dos Reis
 
	* Makefile.pamphlet (AWK): Define as substituted variable.
	(PATCH): Likewise.
	(TAR): Likewise.
	(AXIOM_X11_CFLAGS): New. Define as substituted variable. Document.
	(AXIOM_X11_LDFLAGS): Likewise.
	(\subsection{Environment}): Include AXIOM_X11_CFLAGS and
	AXIOM_X11_CFLAGS in ENV.
	(\subsubsection{The XLIB variable}): Remove.
        * Makefile.in: Regenerate.

	* Throughout, remove special-case definition of TAR, XLIB, PATCH.
	Remove XLIB from ENV.

	* configure.ac.pamphlet (\section{Old Story}): Remove.
	(\section{Where is X11?}): New.
	Add test for detecting include files and libraries directories for
	X11.  Punt on Xpm for the moment.
	* configure.ac: Likewise.
	* configure: Likewise.

src/graph/view2D/
2006-08-06  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet: Remove explicit mention of X11 and Xpm.

src/graph/view3D/
2006-08-06  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet: Remove explicit mention of X11 and Xpm.

src/graph/viewAlone/
2006-08-06  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet: Remove explicit mention of X11 and Xpm.

2006-08-06  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet: Remove explicit mention of X11 and Xpm.

2006-08-06  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet: Remove explicit mention of X11 and Xpm.

 
 PATH_EXPORTS = AXIOM=@AXIOM@; export AXIOM; PATH=@AXIOM@/bin:$${PATH}
=== Makefile.pamphlet
==================================================================
--- Makefile.pamphlet	(revision 15029)
+++ Makefile.pamphlet	(local)
@@ -163,6 +163,20 @@
 will return the string following the final slash and would thus return
 the empty string.
 
+\subsubsection{AXIOM\_X11\_CFLAGS}
+
+The variable [[AXIOM_X11_CFLAGS]] holds the C compiler flags necessary
+to compile part of Axiom that depends on the X Window System.  It is
+computed at configure-time, based on the characteristics of the target
+platform. 
+
+\subsubsection{AXIOM\_X11\_LDFLAGS}
+
+The variable [[AXIOM_X11_LDFLAGS]] holds the linker flags necessary
+for parts of Axiom thar depends on the X Window System.  It is
+computed at configure-time, based on the characteristics of the target
+platform. 
+
 \subsubsection{SRC}
 The [[SRC]] subdirectory is a hand-generated, read-only top level 
 directory containing the source code. This is assumed to be completely
@@ -306,7 +320,6 @@
 SPAD=${SPD}/mnt/${SYS}
 LSP=${SPD}/lsp
 <<GCLVERSION>>
-AWK=gawk
 GCLDIR=${LSP}/${GCLVERSION}
 SRC=${SPD}/src
 INT=${SPD}/int
@@ -323,8 +336,14 @@
 TANGLE=${SPADBIN}/lib/notangle
 WEAVE=${SPADBIN}/lib/noweave
 NOISE="-o ${TMP}/trace"
-PATCH=patch
 
+AWK = @AWK@
+PATCH = @PATCH@
+TAR = @TAR@
+
+AXIOM_X11_CFLAGS = @X_CFLAGS@ 
+AXIOM_X11_LDFLAGS = @X_LIBS@ @X_PRE_LIBS@ -lX11 @X_EXTRA_LIBS@
+
 <<part>>
 
 ENV= SPAD=${SPAD} SYS=${SYS} SPD=${SPD} LSP=${LSP} GCLDIR=${GCLDIR} \
@@ -332,7 +351,8 @@
      SPADBIN=${SPADBIN} INC=${INC} CCLBASE=${CCLBASE} PART=${PART} \
      SUBPART=${SUBPART} NOISE=${NOISE} GCLVERSION=${GCLVERSION} \
      TANGLE=${TANGLE} VERSION=${VERSION} PATCH=${PATCH} DOCUMENT=${DOCUMENT} \
-     WEAVE=${WEAVE}
+     WEAVE=${WEAVE} AXIOM_X11_CFLAGS="${AXIOM_X11_CFLAGS}" \
+     AXIOM_X11_LDFLAGS="${AXIOM_X11_LDFLAGS}"
 
 @
 \subsection{rootdirs}
@@ -728,10 +748,6 @@
 so [[${SRC}/share/algebra/*.daase]] will be the
 Axiom bootstrap database files.
 
-\subsubsection{The XLIB variable}
-The XLIB variable tells us where the X11 libraries live.
-Axiom needs to use libXpm.a to build the graph subdirectory.
-
 \subsubsection{The [[SRCDIRS]] variable}
 The [[SRCDIRS]] variable is used in the [[src/Makefile.pamphlet]]
 to decide what directories to build on a given platform. This is
@@ -813,21 +829,18 @@
 AWK="/systems/pub/bin.alpha/gawk -W version -W compat"
 RANLIB=ranlib
 TOUCH=/bin/touch
-TAR=tar
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
 # where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -859,21 +872,17 @@
 AWK=/systems/pub/bin.alpha/gawk -W compat
 RANLIB=ranlib
 TOUCH=/bin/touch
-TAR=tar
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP}  DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -897,9 +906,9 @@
 # Platform variable
 PLF= HP10platform
 # C compiler flags
-CCF=" +O2 +Onolimit -D${PLF} -D_HPUX_SOURCE -I /usr/include/X11R6"
+CCF=" +O2 +Onolimit -D${PLF} -D_HPUX_SOURCE"
 # Loader flags
-LDF= -L /usr/lib/X11R6 -Wl,+vnocompatwarnings
+LDF= -Wl,+vnocompatwarnings
 # C compiler to use
 CC= c89
 AWK="/usr/local/bin/gawk -W version -W compat"
@@ -911,15 +920,12 @@
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP}  DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -943,9 +949,9 @@
 # Platform variable
 PLF= HP10platform
 # C compiler flags
-CCF=" +O2 +Onolimit -D${PLF} -D_HPUX_SOURCE -I /usr/include/X11R6"
+CCF=" +O2 +Onolimit -D${PLF} -D_HPUX_SOURCE"
 # Loader flags
-LDF= -L /usr/lib/X11R6 -Wl,+vnocompatwarnings -lnsl
+LDF="-Wl,+vnocompatwarnings -lnsl"
 # C compiler to use
 CC= c89
 AWK="/usr/local/bin/gawk -W version -W compat"
@@ -957,15 +963,12 @@
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -989,9 +992,9 @@
 # Platform variable
 PLF= HP9platform
 # C compiler flags
-CCF=" -D${PLF} -Ae -I /usr/include/X11R5"
+CCF=" -D${PLF} -Ae"
 # Loader flags
-LDF= -L /usr/lib/X11R5
+LDF=
 # C compiler to use
 CC= cc -O
 AWK="/usr/local/bin/gawk -W version -W compat"
@@ -1003,15 +1006,12 @@
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1040,7 +1040,6 @@
 LDF=
 # C compiler to use
 CC= cc
-AWK=awk
 RANLIB=echo
 TOUCH=touch
 TAR=gnutar
@@ -1049,15 +1048,12 @@
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1085,7 +1081,6 @@
 LDF=
 # C compiler to use
 CC= cc -mips3 -n32
-AWK=awk
 RANLIB=echo
 TOUCH=touch
 TAR=gnutar
@@ -1094,15 +1089,12 @@
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1131,29 +1123,24 @@
 # Platform variable
 PLF=BSDplatform
 # C compiler flags
-CCF="-O2 -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11R6/include -I/usr/local/include"
+CCF="-O2 -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/local/include"
 # Loader flags
-LDF="-L/usr/X11R6/lib -L/usr/local/lib"
+LDF="-L/usr/local/lib"
 # C compiler to use
 CC=gcc 
-AWK=gawk
 RANLIB=ranlib
 TOUCH=touch
-TAR=tar
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lsp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH} TANGLE=${TANGLE}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1186,27 +1173,22 @@
 # C compiler flags
 CCF="-O2 -Wall -D_GNU_SOURCE -D${PLF}"
 # Loader flags
-LDF= -L/usr/X11R6/lib 
+LDF=
 # C compiler to use
 CC=gcc 
-AWK=awk
 RANLIB=ranlib
 TOUCH=touch
-TAR=tar
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lsp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 SRCDIRS=bootdir interpdir sharedir algebradir etcdir docdir inputdir
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1235,29 +1217,24 @@
 # Platform variable
 PLF=LINUXplatform
 # C compiler flags
-CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11/include"
+CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
 # Loader flags
-LDF= -L/usr/X11R6/lib 
+LDF=
 # C compiler to use
 CC=gcc 
-AWK=gawk
 RANLIB=ranlib
 TOUCH=touch
-TAR=tar
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lsp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1289,29 +1266,24 @@
 # Platform variable
 PLF=LINUXplatform
 # C compiler flags
-CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11/include"
+CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
 # Loader flags
-LDF= -L/usr/X11R6/lib 
+LDF=
 # C compiler to use
 CC=gcc 
-AWK=gawk
 RANLIB=ranlib
 TOUCH=touch
-TAR=tar
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lsp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1333,36 +1305,31 @@
 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/X11R6/lib64 -L/usr/local/lib64 -L/usr/openwin/lib64 -L/usr/lib64 "
+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} -I/usr/X11/include"
+CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
 # Loader flags
 <<fedora64 loader flags>>
 # C compiler to use
 CC=gcc 
-AWK=gawk
 RANLIB=ranlib
 TOUCH=touch
-TAR=tar
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lsp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1387,29 +1354,24 @@
 # Platform variable
 PLF=LINUXplatform
 # C compiler flags
-CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11/include"
+CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
 # Loader flags
-LDF= -L/usr/X11R6/lib 
+LDF=
 # C compiler to use
 CC=gcc 
-AWK=gawk
 RANLIB=ranlib
 TOUCH=touch
-TAR=tar
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lsp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1433,29 +1395,24 @@
 # Platform variable
 PLF= LINUXplatform
 # C compiler flags
-CCF=" -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE  -D${PLF} -I/usr/X11R6/include"
+CCF=" -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE  -D${PLF}"
 # Loader flags
-LDF= -L/usr/X11R6/lib #-lefence
+LDF=
 # C compiler to use
 CC= gcc 
-AWK=awk
 RANLIB=ranlib
 TOUCH=/usr/5bin/touch
-TAR=tar
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1479,29 +1436,24 @@
 # Platform variable
 PLF= LINUXplatform
 # C compiler flags
-CCF=" -g  -Wall -D_GNU_SOURCE  -D${PLF} -I/usr/X11R6/include"
+CCF=" -g  -Wall -D_GNU_SOURCE  -D${PLF}"
 # Loader flags
-LDF= -L/usr/X11R6/lib
+LDF=
 # C compiler to use
 CC= gcc 
-AWK=awk
 RANLIB=ranlib
 TOUCH=/usr/5bin/touch
-TAR=tar
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1530,29 +1482,24 @@
 # Platform variable
 PLF=LINUXplatform
 # C compiler flags
-CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11/include"
+CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}"
 # Loader flags
-LDF= -L/usr/X11R6/lib 
+LDF=
 # C compiler to use
 CC=gcc 
-AWK=gawk
 RANLIB=ranlib
 TOUCH=touch
-TAR=gtar
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lsp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS-LOCBFD>>
 <<SRCDIRS>>
-PATCH=gpatch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1590,15 +1537,12 @@
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1636,15 +1580,12 @@
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1682,15 +1623,12 @@
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1728,15 +1666,12 @@
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1767,22 +1702,18 @@
 CC= cc
 AWK=/systems/pub/sun4/gawk
 TOUCH=/bin/touch
-TAR=tar
 RANLIB= ar tvs 
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1813,22 +1744,18 @@
 CC= gcc
 AWK=/systems/pub/sun4/gawk
 TOUCH=/bin/touch
-TAR=tar
 RANLIB= ar tvs 
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1859,22 +1786,18 @@
 CC= cc
 AWK=/systems/pub/sun4/gawk
 TOUCH=/bin/touch
-TAR=tar
 RANLIB= ar tvs 
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1912,15 +1835,12 @@
 BYE=bye
 LISP=lisp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
@@ -1961,29 +1881,25 @@
 PLF=MACOSXplatform
 # C compiler flags
 CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} \
-     -I/usr/X11/include -I/usr/include -I/usr/include/sys"
+     -I/usr/include -I/usr/include/sys"
 # Loader flags
-LDF= -L/usr/X11R6/lib 
+LDF=
 # C compiler to use
 CC=gcc 
 AWK=awk
 RANLIB=ranlib
 TOUCH=touch
-TAR=tar
 AXIOMXLROOT=${AXIOM}/compiler
 O=o
 BYE=bye
 LISP=lsp
 DAASE=${SRC}/share
-# where the libXpm.a library lives
-XLIB=/usr/X11R6/lib
 <<GCLOPTS-CUSTRELOC>>
 <<SRCDIRS>>
-PATCH=patch
 
 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} XLIB=${XLIB} GCLOPTS=${GCLOPTS} \
+    LISP=${LISP} DAASE=${DAASE} GCLOPTS=${GCLOPTS} \
     SRCDIRS=${SRCDIRS} PATCH=${PATCH}
 
 all: rootdirs noweb srcsetup lspdir srcdir
=== configure.ac.pamphlet
==================================================================
--- configure.ac.pamphlet	(revision 15029)
+++ configure.ac.pamphlet	(local)
@@ -45,176 +45,7 @@
 poor masochist who will be debugging the generated \file{configure}
 file.
 
-\section{Old Story}
 
-The contents of top-level \file{configure} file from mainline is 
-reproduced below.  It will serve as the initial basis for the new,
-improved, build machinery.
-
-\begin{verbatim}
-# The sysname function uses uname -s to try to decode what kind of
-# system to build. Currently the return value of uname is mapped as
-#       Linux          --> linux
-#       MINGW32_NT-5.1 --> windows
-#       SunOS          --> Solaris9
-#       Fedora Core 3  --> fedora3
-#       freebsd        --> freebsd
-#
-# The solaris platform needs patch->gpatch, awk->gawk, tar->gtar
- 
-sysname () {
-if [ -f /etc/redhat-release ] ;
- then 
-  SYSNAME=`cat /etc/redhat-release` 
-  if [ "$SYSNAME" = "Fedora Core release 3 (Heidelberg)" ] ; 
-   then SYSNAME=fedora3
-  fi
-  echo SYSNAME=$SYSNAME
-fi
-if [ ! "$SYSNAME" = "fedora3" ] ; 
- then
-   SYSNAME=`uname -s`
-   echo $SYSNAME 
-   if [ "$SYSNAME" = "Linux" ] ; then SYSNAME=linux
-   elif  [ "$SYSNAME" = "MINGW32_NT-5.1" ] ; then SYSNAME=windows
-   elif  [ "$SYSNAME" = "SunOS" ] ; then SYSNAME=solaris9
-   elif  [ "$SYSNAME" = "freebsd" ] ; then SYSNAME=freebsd
-   else
-     echo Your system name is $SYSNAME
-     echo We do not know how to build for this kind of system
-     echo Send a note to list about it
-     echo
-     exit 0
-   fi
-fi
-
-}
-
-# This function checks for the gawk command. 
-# If it exists then AWKNAME is the complete pathname
-
-checkgawk() {
-AWKNAME=`which gawk 2>>trace`
-if [ -n "$AWKNAME" ] ; then
- if [ -x $AWKNAME ] ; then 
-  echo 
- fi
-fi
-}
-
-# This function checks for the nawk command. 
-# If it exists then AWKNAME is the complete pathname
-
-checknawk() {
-AWKNAME=`which nawk 2>>trace`
-if [ -n "$AWKNAME" ] ; then
- if [ -x $AWKNAME ] ; then 
-  echo 
- fi
-fi
-}
-
-# This function checks for the awk command. 
-# If it exists then AWKNAME is the complete pathname
-
-checkawk() {
-AWKNAME=`which awk 2>>trace`
-if [ -n "$AWKNAME" ] ; then
- if [ -x $AWKNAME ] ; then 
-  echo 
- fi
-fi
-}
-
-# This function uses the check*awk functions to decide 
-# whether the system can build noweb. If one of gawk, nawk or awk
-# are not found we fail.
-needAwk ()
-{
-checkgawk
-if [ -z "$AWKNAME" ] ; then
-  checknawk
-  if [ -z "$AWKNAME" ] ; then
-    checkawk
-    if [ -z "$AWKNAME" ] ; then
-      echo We need the commands gawk, nawk, or awk
-      exit 0
-    fi
-  fi
-fi
-}
-
-# The mustSet function tells the user what needs to be typed on the 
-# command line. If any extra variables need to be set we add them here.
-# Currently the only thing we check if for the presence of gawk, which
-# is the default in the Makefile. If gawk does not exist we can use 
-# either nawk or awk but the user has to specify that on the command line.
-
-# We check the system we are using with the uname command and try to
-# generate the appropriate value. We fail otherwise.
-
-# We generate the appropriate command line that the user should use.
-
-mustSet() {
-echo
-echo ===================================================
-echo You must set your AXIOM and PATH variables. Type:
-echo
-echo To build the rest of the system type:
-echo
-echo export AXIOM=`pwd`/mnt/$SYSNAME
-echo 'export PATH=$AXIOM/bin:$PATH'
-if [ "$SYSNAME" = "freebsd" ] ; then
-  echo Note that freebsd usually has noweb available
-  echo If you wish to use the standard version you must type
-  echo touch noweb 
-  echo If you wish to use a pre-installed GCL you must type
-  echo make GCLVERSION=gcl-system
-fi
-if [ "$SYSNAME" = "solaris9" ] ; 
- then echo make AWK=gawk TAR=gtar PATCH=gpatch
-elif [ "`basename $AWKNAME`" = "gawk"  ] ; 
- then echo make
- else echo make AWK=$AWKNAME
-fi
-echo
-echo configure finished.
-}
-
-#########################################################################
-# This is the main line of configure logic.
-# (1) We test to see if we understand this system name. So far
-#     the recognized strings from uname -s are translated as:
-#       Linux          --> linux
-#       MINGW32_NT-5.1 --> windows
-#       SunOS          --> Solaris9
-#       Fedora Core 3  --> fedora3
-#       freebsd        --> freebsd
-# (1) We test for the AWK variable. We need one of gawk, nawk, or awk
-#     in order to build the noweb software.
-# (2) Then we output the final message for the user.
-#
-# The solaris platform needs patch->gpatch, awk->gawk, tar->gtar
-#########################################################################
-
-sysname
-needAwk
-
-if [ "x$AXIOM" = "x" ] ;
- then mustSet
- else 
-  if [ ! "`dirname $AXIOM`" = "`pwd`/mnt" ]
-    then mustSet
-    else 
-     echo Configure complete. Now type
-     echo
-     echo make
-     echo
-  fi
-fi
-\end{verbatim}
-
-
 \section{Basic Setup}
 \subsection{Autoconf Initialization}
 
@@ -271,6 +102,7 @@
 
 \subsection{Build Environment}
 
+\subsubsection{Canonical triplets}
 Standard build environments consist of
 \begin{enumerate}
 \item the \emph{host} platform,
@@ -286,6 +118,7 @@
 AC_CANONICAL_SYSTEM
 @
 
+\subsubsection{Cross compilation}
 For the moment, Axiom supports neither cross-compilation, nor Canadian cross.
 Consequently, we must bail out if the build is not native.
 <<check cross-compilation>>=
@@ -294,6 +127,7 @@
 fi
 @
 
+\subsubsection{Build utilities}
 Most of the tools we're testing for are with respect to the build
 environment, neither the host nor the target.  
 
@@ -361,6 +195,8 @@
               [make], [AC_MSG_ERROR([`make' program missing.])])
 @
 
+
+\subsubsection{Old behaviour}
 Here, we replicate the behaviour of the old configure, waiting for
 a better alternative, e.g. where it is not needed.  THIS WILL BE
 REMOVED IN THE NEAR FUTURE.
@@ -418,12 +254,58 @@
 AC_SUBST(AXIOM)
 @
 
+\subsubsection{Instantiating configuration files}
+
 <<instantiate config files>>=
 AC_CONFIG_FILES(Makefile)
 AC_OUTPUT
 @
 
+\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)
+@
+
+\section{configure.ac}
+
 <<*>>=
 <<Autoconf init>>
 
@@ -449,6 +331,8 @@
 
 <<check for make>>
 
+<<locate X11>>
+
 <<replicate old behaviour>>
 <<instantiate config files>>
 @
=== src/graph/view2D/Makefile.pamphlet
==================================================================
--- src/graph/view2D/Makefile.pamphlet	(revision 15029)
+++ src/graph/view2D/Makefile.pamphlet	(local)
@@ -283,7 +283,7 @@
 ${OUT}/view2D: ${VIEW2D_OBJS} ${GDRAW_OBJS} ${LIBFILES}
 	@ echo 34 linking ${OUT}/view2D
 	@ ${CC} ${VIEW2D_OBJS} ${GDRAW_OBJS} ${LIBFILES} \
-	 -o ${OUT}/view2D ${XLIB}/libXpm.a $(LDFLAGS) 
+	 -o ${OUT}/view2D $(LDFLAGS) 
 
 @
 \section{axiom.sty}
@@ -300,8 +300,8 @@
 
 <<environment>>
 
-CFLAGS  = ${CCF} -I${LINC} -I${GINC} -I${IN}
-LDFLAGS = ${LDF} ${STATIC} -lX11 -lm ${LDF}
+CFLAGS  = ${CCF} ${AXIOM_X11_CFLAGS} -I${LINC} -I${GINC} -I${IN}
+LDFLAGS = ${AXIOM_X11_LDFLAGS} -lm
 
 DOCFILES= ${DOC}/buttons2d.c.dvi    ${DOC}/control2d.c.dvi \
           ${DOC}/graph2d.c.dvi      ${DOC}/main2d.c.dvi \
=== src/graph/view3D/Makefile.pamphlet
==================================================================
--- src/graph/view3D/Makefile.pamphlet	(revision 15029)
+++ src/graph/view3D/Makefile.pamphlet	(local)
@@ -702,8 +702,8 @@
           ${DOC}/viewport3d.c.dvi   ${DOC}/volume3d.c.dvi \
           ${DOC}/write3d.c.dvi
 
-CFLAGS  = ${CCF} -I${LINC} -I${GINC} -I${IN}
-LDFLAGS =  ${LDF} ${STATIC} -lX11 -lm 
+CFLAGS  = ${CCF} ${AXIOM_X11_CFLAGS} -I${LINC} -I${GINC} -I${IN}
+LDFLAGS =  ${AXIOM_X11_LDFLAGS} -lm 
 
 OBJS = \
  ${MIDOBJ}/buttons3d.o    ${MIDOBJ}/closeView3d.o  ${MIDOBJ}/component3d.o   \
=== src/graph/viewAlone/Makefile.pamphlet
==================================================================
--- src/graph/viewAlone/Makefile.pamphlet	(revision 15029)
+++ src/graph/viewAlone/Makefile.pamphlet	(local)
@@ -28,7 +28,7 @@
 <<viewAlone>>=
 ${OUT}/viewAlone: $(OBJS)  ${OBJ}/${SYS}/lib/util.o
 	@ echo 1 linking viewAlone
-	@ ${CC} $(OBJS) ${OBJ}/${SYS}/lib/util.o -o ${OUT}/viewAlone ${LDFLAGS} -lX11
+	@ ${CC} $(OBJS) ${OBJ}/${SYS}/lib/util.o -o ${OUT}/viewAlone ${LDFLAGS}
 
 <<viewAlone.c (MIDINT from IN)>>=
 ${MIDINT}/viewAlone.c: ${IN}/viewAlone.c.pamphlet
@@ -120,8 +120,8 @@
 DOCFILES= ${DOC}/viewAlone.c.dvi ${DOC}/spoonComp.c.dvi \
           ${DOC}/spoon2D.c.dvi 
 
-CFLAGS = ${CCF} -I${IN} -I${LINC} -I${GINC} 
-LDFLAGS= ${LDF}
+CFLAGS = ${CCF} ${AXIOM_X11_CFLAGS} -I${IN} -I${LINC} -I${GINC} 
+LDFLAGS= ${AXIOM_X11_LDFLAGS}
 
 OBJS=  ${MIDOBJ}/viewAlone.o ${MIDOBJ}/spoonComp.o ${MIDOBJ}/spoon2D.o 
 
=== src/graph/viewman/Makefile.pamphlet
==================================================================
--- src/graph/viewman/Makefile.pamphlet	(revision 15029)
+++ src/graph/viewman/Makefile.pamphlet	(local)
@@ -268,8 +268,8 @@
 <<*>>=
 <<environment>>
 
-CFLAGS  = ${CCF} -I${LINC} -I${GINC} -I${IN}
-LDFLAGS = ${LDF} -lX11
+CFLAGS  = ${CCF} ${AXIOM_X11_CFLAGS} -I${LINC} -I${GINC} -I${IN}
+LDFLAGS = ${AXIOM_X11_LDFLAGS}
 
 DOCFILES=${DOC}/viewman.c.dvi ${DOC}/sselect.c.dvi ${DOC}/cleanup.c.dvi \
          ${DOC}/fun2D.c.dvi   ${DOC}/make2D.c.dvi  ${DOC}/makeGraph.c.dvi \
=== src/hyper/Makefile.pamphlet
==================================================================
--- src/hyper/Makefile.pamphlet	(revision 15029)
+++ src/hyper/Makefile.pamphlet	(local)
@@ -36,8 +36,8 @@
 # this is where the hypertex documentation files are
 HYPER=${MNT}/${SYS}/doc/hypertex
 
-CFLAGS=	${CCF} -I${MID}
-LDFLAGS= -L${LIB} -lspad ${LDF}
+CFLAGS=	${CCF} -I${MID} ${AXIOM_X11_CFLAGS}
+LDFLAGS= -L${LIB} -lspad ${AXIOM_X11_LDFLAGS} -lm
 
 HTADD=${OUT}/htadd
 
@@ -1058,7 +1058,7 @@
 	 (cd ${OUT} ; \
 	 ${CC} -g ${HYPER_OBJS} -o ${OUT}/hypertex ${LIB}/sockio-c.o \
 	   ${LIB}/pixmap.o ${LIB}/spadcolors.o ${LIB}/util.o \
-           ${LIB}/bsdsignal.o ${LDFLAGS} ${XLIB}/libXpm.a -lX11 -lm -L${LIB} )
+           ${LIB}/bsdsignal.o ${LDFLAGS})
 
 @
 \section{htsearch binary}

\start
Date: 06 Aug 2006 12:33:47 +0200
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] Bye bye generated toplevel makefile


We no longer need the generated toplevel Makefile.  All makefiles are
now generated at configure or build time.  But, we are still far from
a simple build machinery.

Tested on an i686-pc-linux-gnu

-- Gaby

2006-08-06  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile: Remove.

=== Makefile
==================================================================
--- Makefile	(revision 15030)
+++ Makefile	(local)
@@ -1,148 +0,0 @@
-VERSION="Axiom (build improvements branch) -- 2006-08-01"
-SPD=$(shell pwd)
-SYS=$(notdir $(AXIOM))
-SPAD=${SPD}/mnt/${SYS}
-LSP=${SPD}/lsp
-#GCLVERSION=gcl-2.4.1
-#GCLVERSION=gcl-2.5
-#GCLVERSION=gcl-2.5.2
-#GCLVERSION=gcl-2.6.1
-#GCLVERSION=gcl-2.6.2
-#GCLVERSION=gcl-2.6.2a
-#GCLVERSION=gcl-2.6.3
-#GCLVERSION=gcl-2.6.5
-#GCLVERSION=gcl-2.6.6
-#GCLVERSION=gcl-2.6.7pre
-#GCLVERSION=gcl-2.6.7
-GCLVERSION=gcl-2.6.8pre
-AWK=gawk
-GCLDIR=${LSP}/${GCLVERSION}
-SRC=${SPD}/src
-INT=${SPD}/int
-OBJ=${SPD}/obj
-MNT=${SPD}/mnt
-ZIPS=${SPD}/zips
-TMP=${OBJ}/tmp
-SPADBIN=${MNT}/${SYS}/bin
-INC=${SPD}/src/include
-CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
-INSTALL=/usr/local/axiom
-COMMAND=${INSTALL}/mnt/${SYS}/bin/axiom
-DOCUMENT=${SPADBIN}/document
-TANGLE=${SPADBIN}/lib/notangle
-WEAVE=${SPADBIN}/lib/noweave
-NOISE="-o ${TMP}/trace"
-PATCH=patch
-
-PART=	cprogs
-SUBPART= everything
-
-
-ENV= SPAD=${SPAD} SYS=${SYS} SPD=${SPD} LSP=${LSP} GCLDIR=${GCLDIR} \
-     SRC=${SRC} INT=${INT} OBJ=${OBJ} MNT=${MNT} ZIPS=${ZIPS} TMP=${TMP} \
-     SPADBIN=${SPADBIN} INC=${INC} CCLBASE=${CCLBASE} PART=${PART} \
-     SUBPART=${SUBPART} NOISE=${NOISE} GCLVERSION=${GCLVERSION} \
-     TANGLE=${TANGLE} VERSION=${VERSION} PATCH=${PATCH} DOCUMENT=${DOCUMENT} \
-     WEAVE=${WEAVE}
-
-all: noweb ${MNT}/${SYS}/bin/Makefile.pamphlet
-	@ echo 1 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
-	@ echo 2 Environment ${ENV}
-	@ ${TANGLE} -t8 -RMakefile.${SYS} Makefile.pamphlet >Makefile.${SYS}
-	@ ${DOCUMENT} Makefile
-	@ mkdir -p ${MNT}/${SYS}/doc/src
-	@ cp Makefile.dvi ${MNT}/${SYS}/doc/src/root.Makefile.dvi
-	@ ${ENV} $(MAKE) -f Makefile.${SYS} 
-	@echo 3 finished system build on `date` | tee >lastBuildDate
-
-start: noweb ${MNT}/${SYS}/bin/Makefile.pamphlet
-
-book:
-	@ echo 79 building the book as ${MNT}/${SYS}/doc/book.dvi 
-	@ mkdir -p ${TMP}
-	@ mkdir -p ${MNT}/${SYS}/doc
-	@ cp ${SRC}/doc/book.pamphlet ${MNT}/${SYS}/doc
-	@ cp -pr ${SRC}/doc/ps ${MNT}/${SYS}/doc
-	@ (cd ${MNT}/${SYS}/doc ; \
-          if [ .${NOISE} = . ] ; then \
-	    ( latex book.pamphlet --interaction nonstopmode ; \
-	      latex book.pamphlet --interaction nonstopmode ) ; \
-	   else \
-	    ( latex book.pamphlet --interaction nonstopmode >${TMP}/trace ; \
-	      latex book.pamphlet --interaction nonstopmode >${TMP}/trace ) ; \
-	  fi ; \
-	  rm book.pamphlet ; \
-	  rm book.toc ; \
-	  rm book.log ; \
-	  rm book.aux )
-	@ echo 80 The book is at ${MNT}/${SYS}/doc/book.dvi 
-
-noweb:
-	@echo 13 making noweb
-	@mkdir -p ${OBJ}/noweb
-	@mkdir -p ${TMP}
-	@mkdir -p ${MNT}/${SYS}/bin/lib
-	@( cd ${OBJ}/noweb ; \
-	tar -zxf ${ZIPS}/noweb-2.10a.tgz ; \
-	cd ${OBJ}/noweb/src/c ; \
-	${PATCH} <${ZIPS}/noweb.modules.c.patch ; \
-	cd ${OBJ}/noweb/src ; \
-	${PATCH} <${ZIPS}/noweb.src.Makefile.patch ; \
-	./awkname ${AWK} ; \
-	${ENV} ${MAKE} BIN=${MNT}/${SYS}/bin/lib LIB=${MNT}/${SYS}/bin/lib \
-                MAN=${MNT}/${SYS}/bin/man \
-                TEXINPUTS=${MNT}/${SYS}/bin/tex all install >${TMP}/trace )
-	@echo The file marks the fact that noweb has been made > noweb
-
-nowebclean:
-	@echo 14 cleaning ${OBJ}/noweb
-	@rm -rf ${OBJ}/noweb
-	@rm -f noweb
-
-${MNT}/${SYS}/bin/Makefile.pamphlet:
-	@echo 0 ${ENV}
-	@echo 10 copying ${SRC}/scripts to ${MNT}/${SYS}/bin
-	@cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin
-
-install:
-	@echo 78 installing Axiom in ${INSTALL}
-	@mkdir -p ${INSTALL}
-	@cp -pr ${MNT} ${INSTALL}
-	@echo '#!/bin/sh -' >${COMMAND}
-	@echo AXIOM=${INSTALL}/mnt/${SYS} >>${COMMAND}
-	@echo export AXIOM >>${COMMAND}
-	@echo PATH='$${AXIOM}/bin':'$${PATH}' >>${COMMAND}
-	@echo export PATH >>${COMMAND}
-	@cat ${SRC}/etc/axiom >>${COMMAND}
-	@chmod +x ${COMMAND}
-	@echo 79 Axiom installation finished.
-	@echo
-	@echo Please add $(shell dirname ${COMMAND}) to your PATH variable
-	@echo Start Axiom with the command $(shell basename ${COMMAND})
-	@echo 
-
-
-document: noweb ${MNT}/${SYS}/bin/Makefile.pamphlet
-	@ 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
-
-clean: 
-	@ 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
-

Property changes on: Makefile
___________________________________________________________________
Name: svn:eol-style
 -native
Name: svn:keywords
 -Author Date Id Revision

\start
Date: Sun, 6 Aug 2006 07:29:00 -0400
From: Tim Daly
To: list
Subject: SAGE and Axiom
Cc: Tom Boothby

This is a reply from the SAGE people. 

I think we can profitably work together to get an interesting user
interface. Bill Page's work on integrating the wiki with inline
pamphlets and inline algebra from multiple systems is surely of
interest. Jose's Doyen work would also be of interest.

I've also attached my note to Jose related to work I've been doing
on the Doyen effort to make it possible to drag-and-drop literate
programs onto a local wiki.

Anyone interested should contact SAGE directly and copy the mailing
list. I'll be away for the next week.

Tim


------- Start of forwarded message -------
> Date: Sat, 5 Aug 2006 23:56:25 -0700 (PDT)
> From: Tom Boothby
> To: sage-devel@lists.sourceforge.net
> cc: Tim Daly
> Subject: Re: Fwd: Axiom point of view... 
> 
> I'm very excited about the notebook getting used by more systems.
> Like David said, you can already do this to a large extent with SAGE
> as it stands.  However, you'll undoubtably want tighter integration.
> I'm sure you'll understand that I'd rather see this happen through
> SAGE -- I'm willing to help a fair amount to this end.
> 
> However, if you would be interested in helping make a wiki-style IDE,
> I'm quickly starting to believe that this may become a new way to work
> on a project.  William and I have discussed this a little, but this
> idea has been brewing over the past few months.  Within the next week
> or two, I'll try and outline my ideas for what this system would
> entail.  Oooh.  Maybe I'll do this on our new wiki.
> 
>     --tom




> ------- Forwarded message -------
> From: Tim Daly
> To: William Stein
> Cc: list, doyencd-developer@lists.sourceforge.net, Alfredo Portes
> Subject: download SAGE
> Date: Fri, 04 Aug 2006 21:34:01 -0700
>
> I just saw your request at the bottom of your homepage
> for people to send you a note about downloading SAGE.
>
> I've downloaded it twice so far. I was part of the team
> that built the DVDs for the ISSAC 2006 conference proceedings
> and I included a copy of SAGE on them.
>
> I've also downloaded it today to look at the issue of
> adding Axiom to your list of available system.
>
> I'd suggest you take a look at the Doyen project, outlined here:
>
>   http://daly.axiom-developer.org/doyen
>   http://wiki.axiom-developer.org/Doyen
>   http://sourceforge.net/projects/doyencd
>
>
> The basic idea is that technical papers are written in a literate
> style that includes both latex and source code (using noweb, a
> derivative of Knuth's Web idea).
>
> Doyen will integrate a browser, a wiki, and several CA systems.
> We're investigating the ability to drag-and-drop a literate
> research paper onto the browser, have it automatically unpacked,
> compiled, added to the system along with its documentation.
> We hope to demonstrate this ability at the next ISSAC conference.
>
> It might be interesting to put the SAGE technology behind the
> browser and have Axiom as one of the back-end components.
>
> Tim Daly
> Axiom Lead Developer
>


==================================================================

> Jose,
>
> I've been chasing a couple pointers to try to look at the drag-and-drop
> issue in Doyen. These are the big five:
>
> First, javascript has a drag-and-drop set of events, ondrag, ondragstart,
> ondragend, ondragenter, ondragleave, and ondragover. These allow javascript
> code to know where the user starts and ends a drag.
>
> Second, javascript can get at the clipboarddata allowing us to pass data
> to the browser thru the clipboard.
>
> Both of those are covered in the JavaScript Bible by Danny Goodman
>
> Third, firefox allows you to code extensions in javascript. Extensions
> are local and are allowed to read/write the file system, etc. The game
> is to create a directory structure containing your code, zip it up,
> and put it in the chrome subdirectory. A tutorial example is at:
>   http://daly.axiom-developer.org/firefox.tgz
>
> Fourth, a more detailed example of a working extension is at:
>   http://daly.axiom-developer.org/dbx.tgz
>
> Fifth, the XMLHttpRequest object is a javascript object that allows
> you to construct an XML request without leaving the page. You store
> data in the object, invoke the send method, and then go thru a 5-state
> machine to get the information back. If Axiom is set up to listen for
> the requests then Axiom can sit behind the browser and service requests
> to d anything, like start graphics independently or start graphics and
> store the resulting image and forward it to the browser for inlining.
>
> So the game is to pick on a literate document, drag it onto the browser,
> fire up a firefox extension to read the clipboard, write the file into
> the appropriate place, and then talk to axiom to compile and load the
> file and build the documentation. I know this can be done but everything
> is moving at a glacial pace due to multitasking.
>
> I'm going on vacation next week and I'll try to get an example working
> if time permits (which it never does).

\start
Date: Sun, 6 Aug 2006 09:24:23 -0700
From: Bob McElrath
To: list
Subject: Re: tex to mathml

Arthur Ralfs [Arthur Ralfs] wrote:
> I wrote a wrapper in C which connects to axiom via pipes, basically
> copying what was done for Texmacs, and then setting up a listening
> socket.  Firefox connects through a trivial php script running under
> apache.  

What happened with the axiomui project, is axiom capable of serving its
interface over HTTP?  (or, any connection which can be convinced to be
non-blocking?)

> The firefox extension is written in xul and javascript.  I can access
> axiom this way by either entering a chrome url, which can just be a
> bookmark, or via the tools menu.  Here's the xul file (webax.xul):

Cool.  

> I can tar it up and email the works to you if you're eager to try it out.
> Might take me a day or two to get done.

I'm eager to see this kind of work proceeding, though I'm basically too
busy to do much myself.  :(

You might take a look at tiddlywiki with my jsmath plugin:
http://bob.mcelrath.org/tiddlyjsmath-2.0.3.html which is a fairly
complex javascript application.  When I put together firefox with axiom,
I used an older version of tiddlywiki.  jsMath is okay for the time
being, but too slow for a serious math interface.  An XHTML plugin for
it was posted last week:
    http://tiddlywiki.abego-software.de/#XHTML10Plugin

If you have a C tex->mathml converter, have you investigated making a
C++ firefox extension with it?

Attached is the web-based axiom interface I created.  You should just be
able to run ./fifo-axiom on a linux system.  (you need firefox
installed)  Perhaps it will give you some ideas...

Perhaps the SAGE people would like to look at this too...


H4sIAAqi1UQAA+xaW3fbRpLOs35FG5oIpAWCBHgVaTpjy3aiXcv2Wso6c2SNDgg0SUQgwAVA
UYqk/75fVTcu1Dibl8lezlnaIoHq6rp13bqBeThPWt5tmKy++9M+HXyG/T79OsN+p/5LH6fb
633ndHqDftcZuB3nu47T6w3c70TnzxOp+myy3EuF+G7lyyj18uXv4f3RuFam/P0/8tl/1p6F
cXvmZcu9vXAuLsQz0VqLdr5at9kt7DAWlxORL2Us9gQ+F6Iln46LgwORrnahjLy6nsPBnqDv
zcNvs0o2+X/NixH+kRnAv8ONJhC7vf32JktZVR4QrTi5FQ+CoVHiexGPhbm8dU9P34sXT0R2
Xx44v0cjl1K0vKdcn1DY+9bcl38widmKg7198S5JfSm8WCRr2MaLA+FHSSZFMidrCcxdY/o6
XEsb2CciSGIzF9dxshXb5Z0lZhjNl2Em8D+V/7EJUxmIPBHZXewv0yQOf5NMyE9Wq00c+l4e
JjEobcN8KVbJb2EUeRbz1TdiBqtdg95cZMlKgna8IOJbEFvYQowbe1kk5Vo4e0vpBaLlC+ep
tqwdbBDIm3a8iSJoWszZn0PCOUzUSuUqyaUwSPF3YSQbf/n05U0bUqisZS/zVdQ09gr8b4zu
/U/H2P/mz6/ZKZKa/Wv2J/KgfDhAjv9m/u92uz23U+Z/Zzig/N9FBv3//P/f8Gk//2d+9sRz
QX9CudVY0LdcIZv4mUhiTjFf5IxR+OuccpJCFmvPv/YWUqy8a4nEgnSWZFk4iyQlqiDM1pF3
h8GKIBLkT+dI1mvMyphcvvRy4aVS3IRy69HU2Z3wkMUCKVIvXnDCnKXJNpMpCzRLwJikOvV8
Tm90ffL6VHw6tphiGPvRJqDkVk5jJirBrtPEl1nGap6+R9o7k7JSrvos83w9bre3261NCthI
sUlsy2DDtSeXbWUCzOKJ8yRlQSIMZbm4AVfgq/xLY0Hib1YyzjlLkxpL5HkYaYOKoAO6IHWc
rO/ScLFEtu10ei18Dcgmb7wbssknWxzL9CaJZbly70NfxhmqwyYOpBLjFVYGP3rEEv+u5BGu
3RENQjD0kNGcMI27ZIOFuhNxkrNMXHnmSN5C3vpyndPKodKso9CLUda4yOQVB5uJ/E0TSWa5
B3wPM9Z3RcHTmMLLS8Gf2Nljoe0kXbQjhZy1358cv/1w9rYFwctpP8cRrWBZFMlh1pDMZ/eJ
vK2Awb1FKlXBhCTbNMzhEBYK3zzfwtuYDhw0T0PU2R3TFXJC/zpCQjVcGK/OxMmZIV6/Ojs5
U+725eT8p48/n4svrz5/fvXh/OTtmfj4WRx//PDm5Pzk4wfcvROvPvxN/OvJhzeWkDAcGMnb
dUo6QNCQjCoDZUE4444QhVtla+mH89CHdvFiQyG3SOBjMXn5WqarMKPlzcjdmE4UrkLla9k/
qmYX/v7P/LS5F20824ZxkGxt5dNNca8zxVTcPz4qDO3uZ34arvMSQ99rxL0doP1zTL7HFpuK
+Sb2OYoagZd7ILCnwq9xg6pwDYTOBD8vsL4YtiMZL/IlIIeHClUIwguAR+MX1+heCRAToMBm
tJJmqGiGoBnjhwmRJvndWibzRnARXjbFdCrMeLOaydTEMMGI4AVdXEIhIqj5MaNfkzBumCZF
n6BReeNFrE85giHYod2mYkdmieUWOSCXjaa9kPl5uMLV5Hft1LgA0QsznDeemZapFgUXel1w
9fCAAQcQXGsiuIoSL5ABLpr3pHk5dpVEBJ3SFNcyJ6bVscwip9FEiPQ2knT3+u4kKOn3LdNf
hlHwIQlkVoFSCUU0PjPDlxfJNG8YuDpfSnzv1A3ccy1CUFLpKGI/E1+6x+LNx1ORbdbrJOU0
FeaZ+BfvxtM2Ecah8XOMxcw3MbhGaK2R7Fg3XR+IWZDILP6K+pBJuaKssfRuVBa0kSIfgSKj
TN5r/af3OsGPja7d9Q2rMMW4uLDYuGP+tjL06tn4ot+xBh1r2LFGfcvpdCzHxV+vZznDruV2
hpbbO7q0svwO2W18b3DZAV9jbMyTOG/NvVUY3Y0hYBrOJ4JhjDxG0k5XXqRhW0m1owASAcuw
yVUzCVt3hwwIwhvyBg0GC+yi8pYXhYt4TJZBnshlOsEapIsQIAdG6axvJ5iarb3YtHrQK5Jz
ojiC+Qj4hIoaNSco2GnARh4ThYIkrnl07QVUq/XwrriCPKvQA5L3wZRs2amZhe5Z5D5Bv386
m4Yd0+oPLHMAhP5IgVwFGtZAXQUa9StQT4GwVhWsr2FuDTbQsF6vgg01bNitYCMFw1pXsCMN
6x0pmL9Knc43ll3FYcu0jhBAlvICky3ir2a3NOVowF6FwTJsW5qaQsvDEm2g0NDC67FVOea4
GpTdlaCBBsmSEVyXQLTgYf4HXkrLwI6KkoQqbZYzZ9DAcaGP9tkZZxkajcL4GiRNhdcKpJ+k
XM7IT+DasVR4Mk2TtFildb4bFordhBIABTt61UWaoBq2/CRK2CHF/jt8jo/hz0d065CDAl25
LLsVQOgaopBymtg/PqadguI9Qy3WQupWdxzGEFy2eKPN3k15C6liHiXb8TIMAkmhM1S+zmpM
qNNF282hsVRm0IG268fojTiImKHTU2G8r7PzChkfaVEJgx48JFON5+Et53IKwTxPVmOlzoRD
c+zSFUh1SfP9twP6x8g1/VlxsorYP+rTv3r4lrFb2mmkYxoUfmuh5MjbsdNxJ6KyN2ymLVMG
r8lp0swQ5BEbTBnE2+QJIda0RI6RUWkCrLnThxkcuy9XE8Ed85hvitW0R8hajj2gYfYBresb
/hSJaUxHMWRmUHb1+lfSd9lGgxH+MFfYWGnqMgPIwFqN90f8eSqmsEPUnPdw46e5yqQcQ3lq
v6quaDFz9u0nqpE4SrGd1douw1ySWPBCcqQu/hz1S9AuUNjQagbdqohxBoi18W1L21rZBLop
R/U3aQaFlughC8NXEi6iZOZFhSIUtoPdxYGLe3mhQeWD3gw+tCFpwSRP1spx2AF1NbhtqQUf
db5/YnunsL1ZhobyCrfT57VIvYUyGKziDAuDaVTHVdbo68Aup/ExXDUPJZkjEq0DeQGT0BLV
qI1qpYtt7dYoZugn/IokhZNL/3SsFw5WZBellOt0tJ+OaPn6enAni/ogHMrUEjqUtTZHne9r
lo+Tdwm3UcKu8kC9EhfFvAzXemAUQdAt8pxAfFCSU4ngSdJUGXP0bqSDGvevXinsuoc7g6HS
seOWHqTEFLZO7aUw5MB9ZVD6LWxGt8pu9Sw1on8smWKv84myC3tQzaPdjrMjwac0jPMvHu+a
MNqFB9+2KmHZnf+6kkHoiTWhQkpEgDPqwbT3RYpXkWQ+fv0aQ4piDSqqVMMfK0IZel0ZK0ou
qoYef7Sq7ndcbGgauLlymvepzDdpDAUoDUA0y2wYmo9xCITJI6q3+fp1cvuO0qpLymfcRnO/
iitVapCCYpnSeQu17saLOJmlL19Qqyb8yMuy6devhq4xuHo6kvnoyAluHGaHxos2jb4sf5iW
MaFNwlV3er8d77Km5jKZz0H5C4USbq1lgeJSpOrRnzi6yJ6TcrRPwhoTbYWrLtR9u3qqLKx4
1Z+SicwfOTXZPh0eEN/Pandy1b9gknJ12byv3UzvH6mfZwygl/ALMuGl2vdcUSWc8khpZrOR
NSc0xUX/Y16SzlcDe9vW86Efz7KXBQRsypU0q4lq9QqNTrhHyXYVG7Fi7lGnps2ors3oW9qM
Cg5ahyO6Hym5sQ/MaEPhLxvtF+HLh3KVG6G/elCN0kNIRybXD6HnU8ZotsMmWB3Z25LOIdv7
tdo10WKriWd5qjr4pr1tEUqXejo1dpykqfR15zZ5rIRk+x3t2g8SdyleKywY6yQOd6OEd4tQ
iIU5g4XXcHQURKpaz6YODXdICNqi0E2JRUGTBHfYNj/q6YzDc+qA6bTFLb9ZhCJZ2EUZPclF
lCTXmYjC6+LYTsy9MNJPZpDjN2s6YVzLNLoTDe5OkSgDiYxVkj80mragFHaCOhNFIk/vaPY1
PUZZJHxMRc9+wpzSfxSIBZFdRHe0Ea1kdCaPj9p0xfoYKoK5+6W11TxpMbgjPTQmZXvldJH8
i0pJJExOAW21uzNfQsZt2+mS42gu02mHohPJsM4xXC1ElvoVO9UWHxoAVJLQ7q3DLNol5Ud2
Uq/m6q+1q3t1V/d2XN3cGaYVnc1KYW5hICK6XE5pW0qyzOzlRF8HNTwlKWVG+/Mmkg3apJvL
ZZvBctVs2svWcjkpnAIW7FK/Q97EtEJfiT3ExCco9hYLU4K6HT400ZNYutmskk6JO2Ux+VSq
GApUOlxOG8tW0CxiRAGDabALWAYqVS0P1biC3nLmJdrbIrd2e9D/XP5CpZqyXUPZ62o+LbJ3
kZYKX+I8QbmQF5G2nuQmp7oM8FK6ijrI2qdXyqOmV/PnDXfQdnrNanCphawgWuyghlNoomEn
q4V9RnWo0VS+wVCK9hDJ5TcKefJI1uuMDlmUUoU2NP3ndeDlklqPjAKfh9aFnI0Ck5ir7e0F
7jqXhS3RjdD5BgBYhY496k8I4qr4sz5LlZy6hEOW3NZ9EXaHA22fTWvLoSOIppE0j9Z7feDG
JNjfjrgEOM70wviknlWgm9BXr+U8SeXZMtkiTQB8nMTYXeaQfufGre7eezuDx5sMG0G654sz
6aX+Erdn1UNl3J16fprQKZE+zDIuKfDAWh2HTjuT8AX3Kg4VPH1mSuei91oD8wJjdPLZvA9k
JHMpdqBQ/FFjanNkdPanEqrFqHzmht8pPWXmtDfURn8VBLpaBlluIfc070vJAjr/Y5DJwxdh
cDnF/QVv34mvpXgpCr1hl42uMQ8O1ImuaKgpl83p1Ehmv6J+GQcH1J0V43oCjdMOX6E8PFDv
CpmLSmU0dUem9dOzrII6l5UjzOkp2R6tT+p5mtYPdK1Azs0dIwFoo8LkCclCw+RGk1ojNL0P
s/f0esTYsbgnGpMxzsf3j9Yb+vpMX6+pot6D43EEFzhWrRP5oM7F03vaRLsKCUb/MVHEtWRX
zow7lU0aTVX15yyoj5P5ARn0p5jlsPCnqliH2fFPpyuUQ8B/MPbRFf9gcG8Ces17IoY/O5Vo
tH3ZaH/9+oP9vG0ZRvMQiOh8ZxPOrCacOU+TiCP3s6Qza0U/TZL80ChPyky1aeU3CoxD/1Ci
pV3LBng0m2VjUQVenbCPMh9yN6loYKG9aOvdZXCEZ4waJ5VNzKIlib2bcOHlCTdHqo06pn3K
B29F9sW+vqPMpPoSR5+om0qvvtPVXl7cmVhfbxPlyIjcVhcMe7RdYdcqhGiUU9DrHLP05LBu
k7PMZ7kIs5zOj8pUdeXIabFmay+FpBPVN6lVwiIpGfsOucO3lle5IfZhVB+mxup6TCfl6GZ0
A0Yz2XPfJCsvjHXbBb4mHaEfHODK1m6hdEC1L0CFwAXfJhdV0+cOFm2VWZiw7/Z0M2QpNtWK
Vovhrde0AhDyNERmo4eA4oT2xDFaq7e3a6yQTLGy1Qx4YI6ssqIpnv/p0/HOKLhvEIxIyvSE
lNtOSlNqhZUzcRup7KrByujzqd7WmQGLOyF7bZf0lkyebmBzugcFNdVWz0vyMI9kwaPWlT7S
kTF7E28BKqpFq//1q20/x1cbmWiWSu9aOVqF+ESaKvb+fvF3+5KnUvw9YcVTBp0jSgTzMv2o
5y3Te3o2I7N8TOI+CbJnyk1d8iSPX2Q6OKgg8KcFPbsiHXUpIfAvp+9/yvP1Z0VWWcjU7q95
kQfS87Fd1ElNaDbQoMuOVz73eoU0fSN/+cj5mxPa7SpC3T09AyGXGZ+ff7Jpm2h3qC7uwAna
g/Q9eKDd1ReEVfhYgcjls9fvM3ldLlUaIXlU4VRKMYA1IXLUXGIGPV7cUaWmDNWcgep/1Aoe
L+mdCd0XmdRd6CZLRt6dDAig2qNYyiCj7ZAKHhrQyR350bpyu7wC/Mure6qOlmykl4ZB2PTo
2TikZFpffjLrG+LVcHbhnzbZsqGXzTKgll4kwwIJWnHGHgwHNWZ0bGBwhTKKYqlR6AiBM1tF
qJK+WboHb3vU3hRq1mxs07tpDePHt+fM35p7USZZBB7NZBw0yH/rhs/RIG2FLi/C9/hxIRUf
frbO70p8Ndki2P2Y6nwIBEdURWEpZK3ifK7YfypeuZdvyOc5FAAa0hb45bRHW9ABdZNveRup
8MZqJ1mg6b0/lc0q5H/N/kIBD5L6/KHkhehaJ+gjzuUtP3fVmzCXTlKUxWDKDR/WmtbQAe/p
xeWkyP38jFozp1MpttcRZbrOZGf+tLpEJY2Rtfloy+3r1lx3s6gIWkDDQD326c2SiB5sJ5t8
3O08xya8Y4XzFKlbJZNiOcedGnKqxkp/xiBzHl9cWrW2tuhcsEm7codFwS4aOhZv0Hw2NTJu
Zwzl9eRrJpMv5u26IT/dNcguBmGwR5Kjl8xGAB/hzyN6bNAL/avzwOX0ooZ1OSmSJJn14aGx
G6q696B8PcNts+gvK3sSf3Wjk64qLbs8FRlwoI2GS9tRJVnnUm0HXb8A2Rm9iKNCuXQHhRNM
MbWaIvnWKW7nfOuyPsBFZXcDKCovcTcvjGjyoKRBqeEYGNKeGTKwMrW0VcW3Tm6cUVQ64Xck
CImjmZq7EvKttKB8yuTui81J5adhKDCfstTxbD7GoMR2E2bhLIzC/I76fj7HpCOV4ahfPfFA
o6gfeZRDfOIyNTrr2xKk958KprvPYlnteZhm+TG9NlG2OeVYyLsAtQ+kZaX9hqUxhkdDvXFi
Dy3mUJ1CB4SUxjSLWYyowtcpd8y6B+dWcEjtKGHadMBDUEW5gqn+cKBfG0lVo83JjRJStpkh
mBodq+zNtf+RVtNpCa06fz2DRkZuKSJCzdELUot6Wr1MvQeDdEHvjRBil3pEwlFLbzaahvVk
JrDJQWCOmntcdV3dcYwoapr3PlWdgngBnegLtSlVslF6t7lGNdRWpusiiyh2KovoDFmPVHVM
Af8+IzfVocoI+Wr9bzoFF0FYj71H622sTwsoTkZ9tlK5x+Z7PmAe9VzGInlpt1BIyuX7uFa7
qG4Z/8nev+63cST5ouj6evwUULVHAIQiiMIdpCCPRMktrZFsL1Fudy8K1salSMDCrQFQJJvi
/M6TnPMo58N6sRP/iMhLFQok5ZZnZq29ZZOsyspLZGRkZERkZKTyZcVJwYJPVfFibrFUcz2K
DjPRT3VoEUY+ighA7boomOA7kIcLuo8xmdGKeLQ4l72QSvhLf7KBYXzmFOEPtbppt03k1kb7
pZK1TU5mZ10Vjpkx4B24YpMAPUOe0urq2PShtBNT0LJhej7E+2IOtHQ9azM1s7dn+sdtd7sV
sz7UuGMymlpefRLyXVcdf4GlYN4fLDDgnQiuLDSFqGuEBue3ZXvcZHZlLBsfiYA+ss2l1jQG
F3i0XYvVkFLhyMZ+bF3rxaZC51wkTHBWgpS91UitEV81olAkdNVRjTohVXXVQy0QwSsKW9Cz
0LhJtmYHpqvuNZt9ZSlWKUdesBEpTzyl0lpBxWNU7B8mykCT1kSnTKmEK65Rb+M+LX2Wl8+s
qNj1TP3PX/2lEJjd0PDaMe6DwG5QBTeGV3bqVS3eqTcgw9vta8fMQarqRhFExLVD3sMOqnjM
+94lR8bZIVCniiDUPdZgy50iCHVLmReC0OyJBupMEYT/eGW8KELZ8Ax4xzMIYcKFxZMqxWZ+
EIpZP8AGuXZMGYqIelbRE987CIA/iCGGxzjPOGhH1bDTUMmOkUL0O1uQrjtaXIiumH+36s/X
8HIuHzGTIOo9jjeWbAc044dWumLOi2FPMVT3QSX/vJ/ShneNDrwhhrxs6wA634Jq0poVV4Q3
PDbawWfnZ7qISn8SW6IErqEA9Lo8pwJ/6U/BfTudhpaQ1T+59IskQIxTOP7Q1S+5xZWCd12X
NF82NNEEVMpDUm3dQSRv3QBeFwHbPLka1vi7QU5wnNNlAyoXSausfwQe7ZpKgsNU+YAlKiNq
1QZuTW5D1rVqnDFHsU4haDG2QZmmnVbV2GSB/e2VlxeX0UIXwgAgVcDgNSlh4KYaeAx1uGV5
Mo0HKg8JHV7LQwdqEHdHvqGPHgYjI4sB6mdgRH57RhXk5LwyGSccgc1EFWzLdy2nYfYh/l3h
tWUGjrpm60n8kyZ/D9cMIbPvHLs4CNhlIyiGcHqR6S0cgx8NJ+EX8fCRZzvhoVl0GnXwEXb3
waT2CRwgcFcdhXMvOh0mhYfzwXp5CIKQvilhqigaRZV/2fpmZFL5eINVaQuXUiAlk+K816fY
CJeahZcNQatIS8ZKBP4M8zK8PEhFI1Qr85iMiHfEbIYZTT4lRXNKIC5Fv8uTUdc5Q0xGiY0J
WP95jSSdAnm5X1jeKIX+iLLsAT7ur4+sd3KyU3lmhgAkIVC3MS6UmBa5VY+lL+CHbPEwLLEe
hR/qRroUWhQv6xP6JC4H3i5zJ4yiWoT98cjs69cj1e2DXwsn/b1/PN37n73Swf53xe/2scNA
350sXaI3IzTXxP5TMBAQZC917VNLPyaN6OpM8PI1tVyKntNpEDLYfUuouGLWtIpdtCpmLavc
qOVHVtp3i6VullJrh6ar4TH7TKXs709p9QJyxCpoX8vomtWFuKNCHnDeytvxkQ+BeqXUa3bN
c87p62dX7/pnMAazp/maR0r3IOos3LLIRM/pnS11h2eZrV4jaoIGxH4Vq+HDh/TLDFLh18/7
RYbzt/W3QVHJir3ykIutMmpkNbnExjpBxabNG7NFZlSn4bi/eropVCC77QderdzFBkitFOzv
y9Y2Om3N9OPFelOyFSm2KrZiBhtywP6voC6QFhw/CFZjVfV3eKipSsvvUJ7NStIhZH4bn724
XLJccfLrfu8RoYB3cBwAxiTBXsRVZNznnPvv6V+Zf+0n8KYF4XQYRbvyh8DK4Y3svfPObz5R
Wjzr1vvBofNS8OaNcPvy2eQ0EF3IbVokNxbUiOib8NVE6Kz89aajwlba4G+0fe37wf5+gbtT
1Nnc7AoKy9/STMYr/Ti7/MH796OSIRgQbZPoIfj8mR+oNVnPGu0WlI3Xk3mMqZT3ty4a7bba
Ghmqvt23MG2tlzTz2ZC4XzxEB+gnmSgNK6k+rqL1lveW57pOXBbsxTGre4C6Tlxu/tBDiYgd
46rsWEpzutpzzmyCfuthl7dmQ7Ve1uEupeV7paCMKSCvUe/QbVrXDiePuw6mhw/5tYUZ39L8
E9M8qUhmv8SvfiLVU5LdR5FdEEpQaJuYiLxPzXU1mWjYd2ieY47Jx4rUhrxZ5AZxrq/nJa0p
GQwVM7c/FUfH2ZKUSqJdOcY42chBvTgehZxduYhYoGfn6w0qZdszEUHudLWY5frwx/9EjU/k
QOeaGGBO6DHXX3MSH6vhBrjNOU7w4UhnOZd7Fg/7ciYQza/5jCCfPO/bE2p6LidE4Q32kiGi
qMtkPMqN41VsjxfCFoVNYfEME78m8Ymbw1VKnFl17eyLQ1x9oMpH/FeiHjGTUuJJpVce+ntv
nQhOwNW2040/1Ek7ppykHcsfehud1GwNlMDlMfP4Df508li+4LwVU7I85vdIy45Oqr0HibLl
UVeSbQ1DC3Y5RueIgAEJyVbfiwsOqAMrjmY67c/AtVo8G3WrsIYNWEgv3Kp6A0RV+OLgnXle
qE49Bm84C8MekpGHt0ZF6qBEf7sSWPrlJeerV1vi6kM03qiwD9cTPEYnTeyBUX+sI6hYSekT
fHZ+eVkeH+J5NO5WypWGPN9ZJepjeRZClFRV9Booj/ckkasj5PMLp7HYx32psAsGDq3kA7h5
RuX1x/gCiyW2NKJqy0hVwDQOskS1OuETM/gGRFdnLy0zCIxs8AMP78qIFMOFxJgI8tXzSIQq
4HrZX/Vn7DZ14jjQb93K4W+PeTj4PJhZ6X8T4wxqhT//yW/Gp5Pk8I5WaKw3OpTU8APrmeLc
X+7fAmRil48SHuVd3fukUbH8ER6zwcUSVUt0cHmiX1oFZ6Ixap14R1bYezjodb2DDyKayFYv
fy4F/6KLrWfZ6Vr5tWk2C7FTOxoxMMfjOOZTBiGASChEXIdsfxoDpNvEsfuQYcAfSUFl+yt7
ljdMB9s6azpmzaapWIWxvk+KnN3raPSxuid9jqgsUNIvdSejUpC7Bom34eRTCthT3HqcOhOM
6w9KdtSy/3T0Wx9uIzBRkArKdv4X81EQikNeHmftnFdl3vdKx9S6NLOH5hHny2FE2NE7vtzs
D9drMwH7PNOQ5YndXBXppTFM6l6cKYDv85DHt2vrCpAmmhLn72DtpEnZLyJ3R3UoysO4fibq
tsr71pOPvd8aTc+3Lx51WTA4tPq4aCZs74nqNUJh9dCMe6dd17TaoWczyovCrxTA1glWZgui
mHKBumtAKN1roGF9cFwDTX+LmvXYMPiZBo0GZ7mK90Dpgauh5ecGuw+Do3E8/BhYsuVUEu3E
1UVna4JmpRi0OOMQA5OCejEqqiBr/MynWJWKR/AREClXnB/ZmatqqTx2HINZ+KmozVEdQuOH
ZkXoOaYF47SX9q0z6SeUr6fqmCwumsYed4lcSBF2oiz0CNq2gbZZdU18aNa4DaQZRaxZpUpq
vYQq5lqlL9DESCXTfKzl35juq6d695qE3MXFU7XNHERh4p0YwmRG6us6Bt+miflxslzT+yc+
PvPsHKotPLr7QoXfTy4PArb5wgRzxGdrKBMls9HXfnnFZwGfYct669sxTvO51MnsjL1cCbJV
PCfZ7Md/O4iEN3V4T4S3QSnJnDrGnhphYL2hiubmDIVR6vn8hOEWT7BpkHYLd74R4hKufuDV
eHYoZuQ8H6WC13aEKpSnHBqSaerJCz1m4vYrjcMfdl0oV+qLsHoL8V/6qwl77HYLHyBfVOFm
8QS7Jvr88KGXXilmVPFusXg2OUtX4WoQQ4Q9UnJj0OaNjb/5Zs5tdgPDV/cQl8ic6lzw/q1k
HffXiUp09+FZ0n36FpyrGz4OwSn6G8tL54PPvtVPKoc45AsX86iBnQmlfVkuT5InRMVc2VPe
DcuhMXkGvbJncuCzo/shV1kzKOICEYw8fg1IoIeOKRPYlULKdu1R1EMDoRYmnkq/iHgLD/QL
LPRSqtTl7PgaqAO8jFJkHKfVR5xw7+GY5pir3JBsUBqXAkKhYtPR7CVWQDSNVbyBsySH8H+e
0DTTY3F7WtaUQLtPqo+0ba6QpI71M9bavG4BbntywjWt59nFLLbHRrI8H0q2x4dtMxdPIucw
w3ZcLiSGXB+BBLbpDQH3IPUpalYATs3Pc+hs3exvLkiLmpH1FdPy2LWvJDvfJfHRzpC3yod8
thJhOaRf0HibbYWmWuW3MpHh041GSykEKByw5Ka22o146ZmdZsPmulYoStjojIEuEp+6orJ/
YQIGGMjxzAOd4LcFbT736rmISlJVQkYSca7Z8XrCTvzEunB2qiV77yIhsJiYL1zziUBUFUGm
qFYq/wLDvCr/wq/Bi0z5bvciDbKG4nm6eR33rdfaJ5Y8B59gNMBeDleo3B6CrNpfAjkDlLf5
PvFxR5GoPpFqapRZfg4qgbVMDz6R/PoEvz5/LvBLt4vfDx8OkPdJF7+TXtEAGnP8fI6gdPPA
9rJRj3gjPWqQgsIPTdJN5KEhD/k3x69e6Hb7Gwk/p28/YiU1z7P55Jd4oG/H/VNaEfTl3xbz
v5/HspFeUIlJsLK9djvLMHHfMie9uNzE81E3K9EUPbQfX/evFuebburd5rPm5fvU/pZWajiV
3lW7zXfjdS0hgbhe8Tmln8C/u+6dPnPScaqMNPxOFgZ3UsDmF2Jv1flXDdbzm1AGy9vlYa9q
dhOLGrWqAUTIAZnBwBs47mT8pPPsAv7LZF6rsm06Eo8ViPBRq8ZO7YBNuBMfdmdZ2HkeRZVW
y3kigSk+n3yyLMzPJj4gKmJt4rNVf8qck1MvPOeRdd7lfDpdjvsuWx+vfBzYphExR7Jfq7t9
KzNCOY/yK7zq5XTZO/S/GP5Yj1r8VRmrjAefqCkEcJ6geokzwmyNAC/0do3nj/FqvteYnd8E
xdCt4DQf+lOrRZtT4e/zT5EOUQyBH2UbP/fm+H1eWzPyQSo8RN6t7m1ejbGyQ/PaB6dGBBqw
Whge2jU5ES1LfmadNhiDqTGq36PGSHTFrdpcAATqrC+DHurJSWK3rfvXH7HnwppwPp12jSJH
jOhT/Iwbuq/Mw9XpLrKc5C6P4k+TYfzX5z+9yosZ3XyYLs4gXXhfojaCOGDZjuCYZXyTWNR/
ZFLz+ybjodNdmT6xHJuDe5hrJNRPsHhNDFGZw3qyb42YLsqrMDWjVrPKk1LPL6gZiyeDcjY3
H1gIYcxwWtRqVdyM9NxqxIZS8I7YoOTerD8s/7Y2lPJTf4XjwY71zED8xLjnZyQMnwRvRRal
SUBiDwwbIO7cKXgTLc/HV7PBYop1+uGfLtvPDh/v4/MTyieBgAL1R2Z6a8MzpF6VAB8pMnTU
YE4X0HS/6K/mwOuNPyvni03GjFxN+0s7NWuzc+rs/s0N7zGFdknzdy/lXPvTd+/evnr287sX
H3748fmLBOOUQoZ32gEyXFNXN48ziS3M46U6D9ykM5MCoQ4wKTSGh3E62TF3/VAM3hTu1KJ7
1BZ1MO0EFboKfKKFj8iwG3wvIV1lCWjCniB7JxWT5/h84NEon6J5eoaDLnYXMshpJfuFk8pe
p9wrFQu5z98WZUdQK/V2yMSMSzgSf0euNnXyyh8EzZp3mlxCnhABXFSZQ4t6euhgsITbW7tA
94F+oKGE40Xkpst8IQKpHsmLDuV8jtPhojaO2S2moz0TpJJmkAjI6JFKSf6SnF6HOYuRYUcG
z1GHtS75mmuJPYqBNy6obEvoRvqWNGx0gxPnatQT76bmyIM46kCtViCNwObwvlyqdGtOI0iW
9+/394s+7JJsgI/TwMtnIQAaf9geKROBEhe/o18kqR7UKxX1b8y22qsHAaxECYu9b7RKfpDN
i8jwBmzH9C8naz0qXJKNDftJD+Z9WJ1P4w+EyeHHOWGNc1UbjnII2idd6puaublfr75/+/TN
i8H5mXytRVUYOuLH9ajqZ7P8uJvx8dXszHJvJby8kKHqINGhmRdNNz7Ekkfnww2vTTwpNcG4
Lmj+fFDcmjJNVfINKdkeVgw7k7HbN7lpzAvYqy6+f1+Wh3051GXn7uMaqSL2rdutPXxo3qqP
azLdITvyCuUmneGDKWo0Nj9wtu71Kc1quGQeBGteT4LQmFnhc2QcVIPHgyc/LMxuLA0rB7FZ
0+/z+ejx/uBJbm8vd76WbeccOyprjsmc6mIP8/LjwWr/iZz2eTcmoTvPoQuvsAm7Js4iEbg5
nCs2P3kVyl3E06lf8Oe1hP00Z4vkGGpOIkltFhwCwtsVRmip1Uy8O9imGF9uVv0Ptlsv8Or1
Bw1znw5y1GMxTU1GWG11QeACZktSbX6UEQAydBLapgKRsCwRgFn6Ygqi/riW3y20h2Pqcbza
W8XMVxGtE2trTkZjHeaGU5oy6LOHBYLt5QRFct/rMKxyvBRS8zwaIiXmWFDciS+HV2CG11MH
3yuJRevDogD31xKcLDdYXMYEIGvNi9NTYExGnqvKDYmvUytriyCBnamE63787MmPS468+nj/
2ROGiephfLXFYBEZ4zchcB5+aFXpp8bqHk6tGhV+TnyjbtRDymT3qemxKkdpWzWXWGMDJ9sv
xtHtxkhPmcjL2TQqTj+VUqCBBWWTyNnZW5XeyZxjiVXURjKuitGu0uZoTXeWapFclifIyhdP
qAOPqDzmzsXDh0gbP+hWis72VLX4aTJ+2vQDg0oFnvb06jrdtpjouMTOFiYMlOhoh36auzva
/F0dbW51tModbVNHMdrszskaL+X340WME5VbsRrhFeHy6hriMBSRtsECBk/tbqFwMS5fPKo9
oT/jz5/xG6cTSHfXXWsit0Jgg0qGclYOv4wQD1d+syGltXKwA1mRWUh9YLUIsSFWW5KmAq26
1GI3juQzWHGjcgOH01Ldu0e/qhEHKC2KZ7eDyBeanvX/bfGmz9tta1E72FkZ2PXPt7fEQMPC
vyydZgAKtsPVqClnDCh3Ga7z4kSR//wZCXjp8m4nXAtMAldl1pdDLQu9QiULgVhPsNJqZT7z
SimaKFvGKxYKaCc/sEjuzr0aj+xqBNwV7A6tcTOC9dF6Qh/KmWD6XuUweB60GkIzz97RCqz2
S74E3nFyRwYkX+hyUIUyELVo1OipJk9wtRAck1R2zfrLQbAcBqFQyUFAGl9wUzxJEFHv8+fg
fD65DLxdV0+dzPdCjlgsaqXBLz3uYdbGpcBomF60YpjTaDzni7nJT0Nes+liDWMPwES6HTzn
d8uH04EbXgxIHjOPGLm8H1qNFyQ3ToWC1OxiYiU0OIhata24EjZb8TujhSTWUUosOW3Qrl4S
hMpEr6KxaKcMXhyfyD+JrYeua877wT9dhQWypttExTR1qNxkqvTU/7yLR7fHR+n3dCU1I1Tb
OTLN1IhAaRNnTWpAoxgWrg23OjgJcLSlh3XBRKjFprAJTSvPEpNWngfeM6LdmhpuFCy0hN10
0xQxRuEj7ILmRjUZkq91ahZnrkS3KdiB2HklBv6Ja1l+8saRvZY4lgRXHrDi6xv1aDdHUrrB
YwnV+OTxBk6B9AePI/bmoJyoMCG2iR7Pm4b62cZ1U5oxjBad0EqsGOCFiMR2lQsB6AQFxPTk
jy72JYJVVvSnWpEtS/Y2QcnFnOU6Dfnl0f1Pai0sFBEXTE6n4CnPGwJz9WPUqZ3TYjlTKoes
tmuwWqBVnCkM857Diw1eluqGD3q14uA/zEkH+fzFrf1gR408+6HElkoQp+stH33Q2xJgU7kQ
gsjZmdzuSDHJYwt3RMimAXmSHBXdWWyazWDOMVjl+LAMMhBBcxw1/bQvVGZpxFYkVtQqG8fc
dqWrlDFGxEW/VvglFLdvKHAM2Z9lMmx8paLvMfNvR0zaJL4yPYtbcDtCeEKOCyWnSnQnvRvA
RSlQrZS0do5zSJIeycBcRz4ZnbNVD1sNN39acN4jVbAStjk+YBXAYzug6mLF5LXSevgBQbyh
nZjj/ZQIv3l7tp/eu9fYgTygpxtmfQ+8aWrDCZIYRXW5w4Yr2xTO8UfYqHJnmntdqoz4DOD+
0G7irYw2xMrRblGC58gdVdSLW762hU04J1AEPNVtL1S0XMWn7C9i5FzdgjCHoh4gE2OceyeP
qX0DdoxGoRJBYkXgwHQ/b8uZvaeoge0O8UbMe5nEoGsztdkmX+NY9vkT6gsw0Tz0OwQzHH1p
4kv7UAoha6vXPQlekoo8Zb/fIERpKfl0NBJ+u8OeHGotbOECoL4/RFDSxrRHh/4qJr5eWkql
MAQCc2HlZNXDORxvBRWHL3ViAqRNEz+j3ekK+Vj5GQ1jy5sorxmal6Nxf2Vfvu8PN4tVmNd9
Bg7g2RFxARKrkz15beFYLFRSZDYZYnrQ6tuo1Z5CMvTg1QauZN8iTGiJY1XzBGwzB2Q+t8wm
tHIsjQLp2xls7/uGD+SdHcGwg75MRHpIHL0k7YFFiypsO6VuEMpxRn1LUqoRTBOIsRtfUUcD
agl6oH0kkWIm5ACETH+EDFUwYLoAGVChgQgJ0AhQRZ5H5W66IJkiDHhPR4WfjM9eEMLAhv1z
Ln15DsSfN8H15IAMQuyBw3CQanh8t8URCEznZFIq9diFVRMkNoAENBAuaGBFKR67n9++LiAZ
kg49m3yxF29YJSQ5SNYmmXt/FJ9CqpPTe96C3r0WSfbgei2Oa5UKH0nmwNNBaFSpgyjk71Tr
QSVkaZaSQI30x8rXyLXpX41xoQdOlrGVhzNIPCg47HGwKHzkY+YVKUx/ETX1IKg8D0IJ1KYn
oEM/XtpBdBMKuD/hhqtgny1D88WRSUMkMEh9+78WcIji8+xj8YC4s7hCRNYfg81LZjnK8xtJ
ccZVTBY4OaX5wIjn6Y01qkpeodHxjSLJk7S+zGQyBmGDz9IiPCDLQ4Cotn0SO+kmYW5yQZNv
9CSTXmEiJOqFVhFKTUTPGxooOKaH+O/qHq2l1Q/tU4sNGTQRaindHmBm6U4ktVzAX3xxN0vY
QngUFhOfCCjWW8cu0hrwGWuSRDp0vAyhMW0wOb+xkmktIUALzSRFUoZYBVGpSuRQFkJJaEqB
W8ORNDRbiBhoKSLHby3orFsROF5I7Me1ioCYOJjLxGsXZDkUb0MRCo65FJ8O8He0dVhQ0HOy
kOGXZ8ukdai8GAGSkn3SXSYSlPYae4ibg+834Z9NoEHXtqnQhC1kr+KwVmsYCQHSHpyjoXlG
vHhzfuwD0voKDi2hqysiDtkbhgwSojqq0fuMyuaIY16Cx3EwQt3LUHWdXT85jHXFxrjlu0M9
4PMFL+KPEJT9hH0UjF2nYna0hDK6hZNfD3uypyEQR25T0hyWC/eLh8mgqZTNinbmhNJll1Lh
xawNFMqPigf4JQftLk+q9tOvcviP2kRqN3p0yYeNFJcnlydRr9flNB+rmh7piZcaLXc8Xsr2
z+caF5Opuc6xfTgsrAkWEPGScewQxgtHp2563pAYYfmkp7gAZcab3cJZcoUFUcClJPhG2O8Y
pcYJ/SiKenyWgo+N2AIIUEIN0o8GIgmNO32NtH6WNDr1brdqFzXngtgNSrajlKtRtN4VQhHH
PkXQ9xBdVJ7JJNDostCCBioJty23trBITDnh4gp9dintEnRtDsyzVcgeLe1UbEhGzo9T/MbQ
w5G4sNCR1EQrneB9RmvwcyxaiLTwqMn/V+uYWL/kwzrszY9a4RvzWKuEf7PPzYZMs/hy2TW3
ih3SS1nXogKe7R1jJR8CF6IpXyH549FsfSKf62BHJFsWe8T/FQFUDZZ0IJ4q3Cz+/OadHiVW
axOGukpqHeiOHVzsSNEn5QSdbl6/Y+5jeKGUdTqp+YhJoTeIySiu7VHIeM43toAo5QQmQrXj
di9l8gvZrRE7spKNhCzAbGm3lN77RBADEZP5QeXKztBFwNX5U8wKYcvicKcvHUYxQtF3qJ8r
6RuMDB903TwcrxD9Fyxco9zSd43nOrWiHkc2kwWj2qmmgtZ3zG5tDQff6BmR7Q/tuuWi/4rw
oFHSTPumGxJTzUkP+pFBYqypcMjr4jWb2fnZsIrYoA3KaScW3q48PP6E0LM34udOH8v96ebf
4isBQ2SBQ2Pefz6YJuo9NfWeol4RRuo4l66CAmcum1JqymQ/TfZReCuXyBWC0eKcKGSP13U+
GSah6SvEZ04PUTFHnq/hBiBK5bbknEu/okxpW+7nJsPANB6ExNlOQ7XqbnpFK1KTQtmFdXlO
9Ppxsjyo7dN0msUjfa3jlR0MNKGBhMsP5q6ocr1Wgd/a38/7IxKU5+eziBKbrWaj0sZbld5q
nVqrVsVbDQXq9BbSor6QrO1GpxHJO2eu19t1ksjPl/haJ72DiIje+FvTvKGiKt98RG8D5Iwa
eEKuar0FIqdcH0YrxIwo19rNqMI5TUqlgUMtE4KgSuDJcxWCvnO5QE3IleVogRqa4WBy9mGx
/IC7sWgCMhD8L/UBMEVN/Et94E6k0upASSqtgQpCOEGdxauDZqNRoywSO4Lv5ZL+gGdwPyak
T5j0qBratFNW+Q86lcilrceL1QY2csrbCFWZCvsIDnOi/nGLJf0aTEi4DsR3FLFL6Y/cYxQG
S5jm1JuuF572UZJN6MjDZnN+gM2cH2Aw54eNfOLngSRKBbDWHIgZHqE2uQ5EE+c6Dqqh1HFQ
C9XKXg+lgoMm4urJOWcC4uGfLo8quFQHD5F5qJqHmnmom4eGeWiah5Z5aJuHjnl4ah6emYcj
8/DcPLwwD9/rwzMDz3MDz3MDz3MDz3MDz3MDz3MDzzMDz3MDz3MDz3MDz3MDz3MDzzNTzzNT
z3MDzwt+eCAvVQblT/TzLf38iyaaMlVumyUe+nlEPyX6wX97uCwuQACMMMAgRvSDKwBq9FOn
nwb9NOmnRT+4qKxDPwcwuUjFNYazqy+Msu9wgRH9PKWfZ7gtgH5IxQ5e0M/39PNn+nlJP6/o
57/Tz7/Rz2uEPqafH+jnR1xZQD//g37e4noB+nlHPz/Tz1/o5xf6wa0Ef6Of/0k/J9J4gyHp
0c+v9POBfv4v+umD/EGkuJGAfkDzp/SDCxBwd8GEfn6jH+KxAaYHrjfA/MANBpg6f8fEoR/c
o4B5ck4/n+jngn4u6eeKfv5BP9f085l+bgSYliGe72mMeqHMhpMT4g5VHIYPwTlrvZAS6K1d
q5F4hR2BVqutT81O3Tw1W+ZrwzxUq1sFbk9rtGvaLMmGlfB6MjzgpiuUOfy4mh9cB7VOAFaE
hKBZc88177keueeOTb8Jp5MzqiGqNAL2vK4TGVXawUHUuLkxnWw0mhaCRFoDHpWMgtRTFf1A
iXotMiXgqMwJ8iXy6tJS9i+aqrb5s5/WaEpayyTW68AI1dVK5GXcNaoVxSc/cflqm35XOq0q
Z+9UanYwo3IlcmNAyVg3KS+l0Fdgu+z3CeNAL4J9xtce9wRnf4JWk19rUYdRSADg+I8bQMF4
p8kIb1YUzw0fiTa3ookBUOproSu09DcTNNhA7DzpbmIAtE2BFO3x0GOtVOqI+DIPQwegpFrd
DT3pL16r1UYivYGoAg3+aGAU5BHJAkYCzEMeOlMB0eC8VY1h5stkud26kl+1ZnAGc6xFjGmo
iZtWNVle7TP6xvewIn7AjqdUQRkZJg+Bj4mT4ZP3hr61DDZrzVZIQxu5jpHI42WkN1SKM+NV
RaIbk5ZjH4khiSJML6aZChMQukKMg2MbwgFKHiJ9wB6XPNiUuhQmfBOj7/gvQoo83O2WeXbD
26pk8KAmMAZn0nbbNGCgadq2m+YBzTEmALurudk286nZqCX67eZNFHmgRpXEW9RKvPk97Pif
mg3Xw1bHQ2Kz5b20Iu+l7V6U2EC47UaaVdeakSKiVQN1cjjKRlT3ebV8NmPkRs0OTcTo4aK8
fqAAn8rsRNtrg63xCzAvVbcNqBywxcMP05eBJqqYp46pt47qMD3qdcPEUNAjEZ4JTSxCMhdq
TW2K6TbV77uplTvPq4ejO6mumgQTQAno8lTXJwadJ3TDfmsp7M0kPpMTzi6cbGUKm7gglfg+
dayFOCJ+sq4xXzC4yC/V0C+zLnxRN1rEhxj+ZmSmDnNxYX4+X0+noIu6NOZNFvCgTtVbW8Br
zbxrW0Q3WRCg4aBJ5vAfeaSFbzKjsZIAode2e1yY5xTPZftSrXjTLapU3KdOxy9T81/aiTJJ
wPxPUSc5fRm4OrN5r4+Vuu1jK9EZJzqoZFDjRYm0VJxqJSpE61USgCIjCdUcFu3yj3WZWVmC
qBxLrzQdx+A2+VpfO2GiyBBTx46Fh/52xkC0sCCKDEWDrZORJBqtG+Sk856Rls+c7Y4VdLwh
rtolqm2XZUMq/wTE2vOvVpsnPUoo+xZ8Hu1waHh7EfLcSl7rGGGw1rFD3u4AjVHDrcO7qT/V
Bf9jNSkRKi20Ojq92zgxf+9RYE7YRrdQ/t7FhARYxMVTCwZkH5Av5P7MgdzkaAhIeZ57EKRg
7a2KgBh53262ZHmPKZnnnjEpsDYVGY5JMwdoFAQ3I4+IGx23uDfa7jmqtoIDC60QrSwhnB41
W9761VQG3wE1mMHmfMmFjtU2VNPBxnqrXjUMvYX5FXYgxLdBVpKKI4YGZB1qBVdhb3svFuA8
3j3g2qY6FlGlEVb4HGY6NQTnrqk2iUtYOBetoyZXlAIEQVu5RKtlO9GAx5SWrJuBq8DpOoEU
Q1RNp/EZZmc5HWaYATVKkBx3jvsmFFTBFYo1q6bmHWT1Smpe6YgksFOvUe0dOH5VWjXbZh3U
67VZazD55CUCch0hGNAwhpvz1xq6NPB3wrMh7bbRVpssA9DXDmGF+1/vWBw1CUc++PnUwuNg
rPMIcqGklN1omcoIVpcaaT8Ek63Iy6QtSigtUJbRMAV5NVMhLaEJ4Gjlou+Nul9V3nUL0UMS
Y2oootpUUICiZiMyXXLlqWYWYZVHRZUasw8dRelCJ0ronGbOgC2hTAdH0ZK9rjVrdkWFXq5U
Vml1OpZa0RszOHlv0rLEG/Ehgqy/RumuN+tQ2SrUlFX5ogq23YQx1ZsN+V5v8Xf6VlNt23BA
/2+70eZ1xf+bNwsQJnG7WRV9M61MkkxgNdukVtmoYTmq1DqRVfWdxm0XKCUFiIv80DIrDKrh
h3bHCU2dik8x3FTEYRBN9xg6nqDIr8i2Uq8ygzxTKrEhj2WBKLd4Ssty8wo9evwIywwoUzh1
te14MdNaq5bFAZv1LQ4okj0rP4YD3sqMHaepW8Cwq+QRc6NhYe40q9JMPrF2tOud7F4lWrDK
VwSXLJ5ozKIY/oonFfolBR9G+SCxoibfRSVIIy6xiCmKqtko6kRG40lMcW/YKi347ZpVpObj
f7uHTTFB1l1juwa32U50xl+7MatqzK7oxdTusOUWvCr4S95yP6mh2XKrP55VREiw2E697qOD
RBSf3GTsPbgzkdxoRz4YUoft1S4S4KIiULbEPCa2MT7q4z1jWGrELAB5vSqsptriuVgHT4xw
ytIjzmpHGU+dn1hnMdK5rGRVFf2T096KnZ7phxUag768CDiOd/Oy2VGWj+26xIrCLqr1lnJt
vnQhn1hTWla9qXqaVq0uUp9IA1GVX6zl15cmWtXUase0wjOrUbVMqhY1ZLCr0BgkLeo4wcwa
es3yXm83fGTZJZ5FiHoz3R1ObkRmpbKioi+zsGhhakRIVatDGHFIzH+RJ0i0GzvW4haUIZWf
m3a1y6ihkwZVxBxbL5yvFaRqunCtXfe63aw13VKqZAayjdy+QtSoO5s1Y7nWIZGlZ/YAT3gB
a7jVtS6rq5ij5RsvMRyYXlfYjDy7fnj1rnck7JbE3lITqlmzxR7lrerGIKyGqhpEnAg9jeCb
kvXL5leJwVZKXBOVRs2Oy8GrZj7xEm093Jo3IZ2oMabjP/l5zLvk8Hq+XRHbiTSje76jMrV2
83YIj0dk5g20C9OBxEvb42fes/dXO2aNK+6JK7LyE+9RMJG6bZrISEKpJ+kRp3WMWbTeVi2K
WIjy/mbDLLWVWqXuFg+TlVYZ5qY2Fy82UaNS0U+tlpUi2A7Cn2Q9cMtHG9Idf8kn7eeRXVU7
HVsvB9lrdHzroy/dMtdL5W7XrSxCwkgjWZP7BjXI9c8YfwVsSP5R2xZlvt1qWgUwqpsuiNDS
UZmlzkYClfCictVLFgS1raCBoPkOPa1OU9d7GM48eJvmA+GNF1JbpB21UgjxOyMcqV1veyCI
ZFGxFbYaicFzqKk26hmYqTa3h0dtrDUPxu2SnXZ7Rx9atmSEVcQDhs1yMg5bhapuCC0pmVIt
OxeZYGEgT/3yJoN7EhUbpuDbnxqpv27rzj0lzcr+X2nPT1H7srCDGg8l9MlO0+7N1q1Vhp9Y
vBHhguaO303X+fwWe1aLLjez69nngMr+RbfVRQHNwGNsx2PPOLTAHlVvqDZGvYlIUgqv57wj
aQwa+ByJDb+lSSy2SVKlnpHWcFYCLOsm2dTop7Uy0toZaWo+ECamOwqVdFrUxElYr1xzu6qm
1lTT7WbgLrxm96QDOc+6PIjs/gEPEN/TxenWIt6ySKk3t5O0Uw22TRvM0hfUPz+I2t7nqIWB
p0QFi3eZtEy1XDOjUat6nyMOuVCraTXg1ppU305q+EiSpOZ2Ums7qb2dZGBsmJR6ZSsl2kqp
bqXUhOVi2dKU+laKwt3qVD18dAw+6m3vc9RCUIB6gkQ4qVHZTlL4mqwtSVJ1O6m2nVTfTlIY
25WmTWpuJ7W8JK8nxuShWRExgFahdtYzZYoiRys17VYyUTvWVjxX+MALiBq3WDHKcAnbAcmP
IOWmMTe6/FEL/r3EVDgbn1ngnJ5dQMQjl7lR4cykKCBnw8om6WyRZKtJtsZWNgMqcsFCeEt9
8CvfUVFFr+wiqLKK28+Rlob7hyIBaix4ueUEijRSLWeT0UFT+9kW3DHNdVgHlM/av076c3Nn
sVT+JCBRuW0BQQ52X+Hjecz3Oimoa2n+ZX0w3JCZziMgSZ4v9qRHQUTT2wtIU4PpAfS0qB1V
MnK0TB9TOQzTTFNaBeHj2hVdYQ35VnVCJxNh4NbCWHDDSKd/KxJ+ERmfKkKZdcVhzxQsZZHR
7WhtlGI16/bAu7s0D6tGOK0bHkTFeLeX22o1JLEhibahdLaWny3CXcTmS8d8QTq2HSI48mpX
2trrDvtzSVJHYIz44uUOV4cDI53IPlXtU80+1e2TQlyvuwaZk+CZIKsIeKlfrmcJYDraL1uB
wVyZdBjozozWjhmmSK23RoSoVAwszlcqavNWWoU70WLDSy2dyyzYhgwqNxmJUXKtk8RqVmIt
K7GeldjYYkyU2MxKbKkl3sgiNfNu1vOo7lLqyNGw73WWCJu65DXNhM/rjCINhqcUtFCWOqLW
jZeXILEvIoGqCC06szfTm26mt7SmjmM1jjHQtK3pXK1lfeTlGLOsamTYDuL+2l9513LUqTRU
VrJsKvG1ye33jCO1uJdao7GRadqRdc9qWgW2Y1bgTtW6mVrjp1mxW86C3qx76qrRh6Kqt0Gq
VYvY6PKQkmoknV1ZlGiFw0LqZjG/aq3x4piKU2fql8qPNfcoXqn82DGpKZ/UBiipwQb6dlXD
DTbabf+13U58ZW3dvdYqdv+NOmLE3mpyE7FlJoLVr+SJDY2dpuPADXA87i8cDcyGVbvmF0eh
CK51UUdWj6rnHqAw1qwe10z4sNZUWYqgJvtWwpaR2ZJpthHr3Gpg6hhhum0t8x1mpu2G/9pi
Hcz5u9riipGqcYFoYMJWYWU2Hq5VYwphFEu3q/XQObg679bI7gc3O02PumWfsdk00nHTGLvp
q+/syo5HsowZwd3Qrh2jLFjUYK+0VXXEx9Zz2JQqSQ9X00rTzRDKsvW9UgOkgnrh9VKs7qYM
syTGaoNeXDELZtIjttG29mCMvPG1qN2k8js6q1Z4b5gJElcTVDKQlPhaxa6t+5WXXcu7U3Fk
zJtFjXbVQ7W//e99EK/YiI+bEZ02fbQ4N1qDliZLhULIxrfJTSV69WjKetb6g++xPWwQWncd
44nGXhiVtv9mnEr1rZXI2Ul8aya+Nby3pl+s5ZeyPqdSyG+sYx3G5b3tnDar1nmrxZE3jT+U
eeyYx3Zkn7Rq4Na6/8qL7gGB7o37b6Xq+dqCOqw/Lb9Yp1x5q1T8jJ3Ep1qimHvz3YvrhtOA
53nrhtVrvT1YM1nbtrttiwO+5EfSmvap42PNE/WNV43wN/Y/Nuuqcc1kidnDlHGXqwIMeGLm
JZ39NTmR93TlyfgcA5XoZWcnPfgk0I4yYG217PY0SYGptZvgx/VmbYu1hjFGWHNiVPf4pkGt
3cCrRri3gAULWFQlcmvbbE5L9anWEoLG7xgQiflohwASguHBDYvvG58Z8A6r8gmz5rSq1q6O
g7iottHRQIG3TxkzX8xk0ZnC02RryAFwpF3IJ8a0zaZuJor/kJnC8k2Gr7Ivp0WMaCZjt8+R
V8/JyDj4RcZTUB7q8sA2NuN4GUWWhr3RyCstcBNGaHQpQJ94m2231trRmmxkiA+1elCr/7Tx
nk7Ph06nk2yPJRQLBNbI6o4Kcf7X5ewYcO+PE2YWkamg7qy3vMx5IoJbZoF9o7yyiJNxTitK
CCbY2OBtJGMd5mWO45nRItjwl0/eT8gnqjI2U66KCyXlLefxbUwCSddUTwLOi/entgxpFDyg
ralQZ0hsadhUB2ZU8ciPl9Q0MbsaWD7VGiwWrf9ZXlBRhScjxupraAu3OXAraCknbhXg2268
bV8jNvfKYGChithDvJIQcqAReb2BS4LFq7Xh51lw9hHIYZ1YAgamuCHmAYo3ULZBibAlf2Al
kz9oIuZ5vtCM2e1xZQtx1bTDOor5XOmYitvGqFBjpYA9dbnrxJ+NdbnW8iA3Ax6Jm2rdr547
WjdpiORVb1tIbJtRtbbVv06VadgdELOOxyI5efnSUymyFhARf5ttM3hRc8cHzMeeOc98YvRr
Ycn2qF2HGRBv2DKD4SeI8Pwko4anjvnG+E/lvzWt2Yq2uYjzIjNTpOOmSMdNkY6bIh03RTp3
H/Js1jq2VStGIa0KPw/pdfKpFmmJet2WqDUim2boUA/rtcwRPeHLUeKpVt1Ka+h2YrtpgOAB
8/RkFsesG2AVYYXbzFh4g1AqqVdDe94zEiORDGZUjlpuEFj9bYT2uCef3fR64p/VUxWCMjg1
2PoD1xqJscs+6Mnexg6bEbXM0G6d66TPjLRqy9g0kpjfcbSzag/+0mPmuc56XRaifOJNgRC0
M1KavLvrHXZEr+Ej5By57NCbQ8p1q4f689ac6kRcEtfZasOMux2yP+DJDSgTiTw1zDYzjzvg
gM+idLvWiVg7rYgXEO6udFkaLGG0at4JTzc0TK3KMnYe8WTSyYvwUkNsFggz8hDpA4RbebAp
quOBJqyOJy+q42HYjY5X9Q428hqTZjywl4G580FDacBA07RtN81Dx4fd9wS2jK9ad53Ob53v
ZDitJC1vRt3WN797Hf+T0bXQPaNoMQaNoiUzMfJe2lESWEZDp2J4reHN9VpTkcCXMLAYk+hf
w7LnTiUyWc1YudGL/LFi1aij2IUPJPY5OqmW21gNvwj9XG+rbQA2wrsiz0AQVcxTx1RXb3o5
6w7L3lZXU8fOzIGmoQ0m2lRn7yZV7rSuKNJbU13VgzMJ/xeRwjYBeZ1pNyyOO6ZbIrogkfDI
IxLt/KYrzr3HequZalsktzp2iVrM6lE7cx3Lct0SYNLN8uczK/OZuY2T7BucZPRcRagclySk
6zlOSY4M6TT5hMGuE5w8a8wJTnkxJzjlTU9w8oue4NQyNf+lnSiTBMn/FHUyuIlYNLlflbrt
V8t1wMgB1Zbh5Kxc1HAXLnvONpSvG5E+ano6MoS0GrNtrqnd8OmbNUCZOBalHhbbW/j0Rogt
8LCc6Mi2tHZDuoKA7Znppm1nu1aRs2SQfzeQ0tN/shJBa4cIGp2SKgnJ8sadtUtpvVXXkak3
7FOddaRa+qTlLaDaNK6dWm7IkcUvRqesd6aC+5WRRgG57VzDnr3cwWTr0EJUAbOCBz8JS6ip
0Rb2C5PHfrnx5ONM4Zh4Qu/Gu/7i1Yxvi77m6M0HJwRgs4IAiO0G63xwbEA87ohoHfdkVuvE
XDrtEEcP6rVKL7yApz3N52YZiyg9tMs1WkDpoVOGyRjyGvZhZdZHtbJhB1ET3yMsItRGECEo
Aq37QRUHrKttFKHGIGaWm/QIG3c9KkOBx+GNegcZCILgoEGPN+EgXm8O6uE5R0g+uL4JNUpW
FEoE24NK6O6GSN7L0K8Wr03QyQ/9GgL8cZofPVXqPaHP0EH4VhUc7O9xwGT7Yh7Kw8V82N8U
qBoU4Sht4dOR3hfRxK7Ih34dMclMK00ERaW8danbvpmo6TpaCGbu7i2hseNMXBHCMbvw0Pns
WPv9ZtfrDsjARnoVNGVdPvGh3+JSJwmq4Qs+0M6JxH4l/PcS8Ts/9NuCyiZXmoxgytU2Cfp2
TyPfu0imw675dDLpIZzgsNvlMNsyTEMJC2pAkRv48sjOqGt05OVk2CtPlLgJhybsIL43+fI5
Tr3x0MEp4TNcBT75B+KTYpNBbvLWtuLZI722B7TF4f1mXUMiF4IIRgsLiYQO1+lIOu2y5G3M
f+m5jMXFY1ydgwMck16vVH00K+7XvDHhqzv2osMbNGuyMQHCX4K/hBxDXKBvYsqb0bTDJCRg
+lnQ2LkxVwnCo56gwijk3Xm5LVDqzHcLFhP7WqqoVMTJ/QEC4jfhTbYXFR9D0OZBadu7BCVk
uMyAOPzQPw2PNADsIMIt7mZYd191E+zzw35wEOwvp/3JfJ9jOh+ZGw2OuoENN86DTgnDcX8V
lI5KQXk5P9M4yv1TiR5PD6VusM+R4w2aTURXCWHej0sEXQkZjzQ8uj+TB9JH4JrLId43ok1q
TxJX3roQ6oMqwnm6q9KZ2uTmJDizcWByviYLbzaueV6vdLJZuvLSguX50CPOR92aRrrewmje
BryWEKefPz/QLBoRW79ybFLY8mxI20LF3BpkKt11YZEF0l5BLEH+B7VuUCEFvt5ottqdp8+O
nr/4Xm+/fhlfHi1GsUQBbsoJsLbjCuMuN3g6XdCcmuxHTQmvOe0S1TcfjRN1EN/oUlNlDPvT
TWFcLHlvUxOxVzgek+WhdofjiV+/mOnQzqTpebcBXM4eV4rX81KJ51uHPxOFV/AvKl7P0Enk
XptArjQ11t21C+JaeP++/P79SP4vlkv7YfBtJLfhYvauS0E8Q0DsY8R8XCkIF7xCXOAyNhuL
ODAzHu5iHBuei3w/uSwFYDIcoNzec8MhJFeIOp66yQZxlnApz0Egt0S9mGFgL4qlQG53MUHH
w2cIlm/gCcfhKPwwiM2sPcXVIfw4rOARUwtf6ZWm1YBD5e7hIpaK1J1bL6aT0WEg4Za5Bxy0
nJa29TPOXby+YIKx/XY5OWy/uc7dtCE31OCS7+CQ4XmMq5FoNvGFPAd79roa0yFhC35hhwGA
eCgcYmQ4ykgDNY+lzy+7JvO4NCpqhx8+HD+yvPExLq67ftkNqOngcNyN9u2nwxtpV2OTBqWX
tj3t42zxj1fz6WQeP5suhh+5n6Pu3jiRBdcBMK74brAHjPDRnlmmRgK+wQ8W/3i1wa3iek8T
X+VkOrE3KtoVhNBn7i6y9MM410uWLAXJZVBUfZpW3p7z4qOkwmM3Nngcd92avePmW75nA3sN
THMFUFuFL6gIjwCPYbnDevhh2HAzIgVyUKIcAhoeG+ZSJ4bwJ8xGWxHbHi/DK4bUrmGXOrNp
Xl/q4NtvV+7bFb7J8nf5+fOVTokhDFzd9G2Zy8V6okHmD3KreNrfTD5hSZWZgLtYhh3cWWLn
Js+YS0eOVzZLXlwRLdHSe2HvSnNSl7rIZ3uPHvoIMEM9bBpkHMfL/ooEoOOPk6VDMa5cwQa/
aZrfqyGf9kZUcg6XY9p1zfU1cI7pVF9mizA1SpIseXPLDAuYw74BxV2grVCMFAp9IuI/6LtL
thkOiydcq2DgYrAMTKNSkLpJwSKB5kqYbnRUCYXNXYUvmS6uHui9U7KsUZ40EVAZAa8N4mVI
ZIjcUom1BeskTTkGLse8txJj+AykqCVvgA38URN+ZKAYaZslleXMZNkbhaPiYZJRmN4JxzRw
5g8cDeIcHY+Z6wUKA4Cc8Ee+SaeNvXfLIumb8rDEx5fy0WvfY2a8Qtmuet0zwzGqSDxrK14s
+K6qhLo2aoYfRi0ZIR4dj087Bsh4wT1O3UBvc1Ix46J7IQ/jrgoNo+5IHgY2aWDTLs1951cc
/1y4Ji4z6TIsLZW5+B7lLsF2yPdH484hgh0nCJjLvST18weCETs3CJXvusfX/wH8ABGUK/iv
GL6LL610ORpQd4f0Q6vuKA776DSzmRj3plktSPoIBZEZpWAKxQbFw+yseb4bi2+xktzSAGUW
yerZM6BeC72Y6SXAyGlyIOQ4jTwsNrgOVWuQb4TBAqVAddOY0Z8/m1eOHF387tmz8ngPS8H4
gBeER0jY54QRaxVcz+ISbeBUOi4aDNCjkDJehFx8MAoHlJly6VVlBIS8kWpDL6zj4n0zlPUj
T4lDzBDcy/ZACQcZ6JUGnX4/AgSs8Kj+YL/KQtA3F1DQQyRlceN7h8u90aDjXlFa/ssRfzTR
1ku2hUd9X+ug3Ob24r/q8B/ReLTop00/HaMeGy03bvVOjnp6W8+wbOcBHu3CNCzjOgn3iV4I
3LxeCzGEjixoyOOeumF5KFqRXvv711dv/lwACEehjjQTDCuOBipzgVc8SFCDflVUighPwJQ8
6Muj8SGKtPwBJhDo5+IR1ReO+Tf1B38Twxy3vWGOO2wm0EEGk243CYyuSTk0PZXhGgAQeqMH
roRoVd9H3rhRLmrUCHU2p5c2cmYFaY/6dOgV9XuaKJ9AQYpdQ7NkqY5phxiNuaHi4Z9wOYVJ
LW0JGOYCKSwR4LGX7iLLgK8WaCPkn3dvrUdip+GH0wr9RKxfpqjs1FDZA4dh80TdOYUfb1P0
Uhbdkhe24nZhmDyLSm9joTaQWh8ladz7oIs9zBJPPry0M0koJK8UebkpCIUIAAZwSuh//lwB
rdAfvXrhtJ6gSMlpKJKhGYzzHGIpzzQxIHo7rTuaGIz4XQZZKFi+lWSUtZUmc6i2EEFoRoj4
rnxpwJoKVq6QUnJR28DXGr40zRIqS3lEonORcDI25EScjguwtkHdAucBvF0FBLAqbKI5WSth
GwfyRe4zBEBz2qwup5jZH063WMupZS0yMzDP3MCZlG6XipoEmJaSWdjY5K08rzTNGDEQ/uzD
6QBmHzE88cA86OryMsHN250aX9932tmrA5rJCEr4BPwNJSN3sc5k9IShr1u7mtjURqnUvciU
FK51OjJ2rxPNiLs4egLB7Ix6ODox6JACp6TPJUxlrhDD8SAJNssoxNDMYoMK6HWfKj+p9LQD
lPjIAErNdXr75qXee2QetVr3TS4NEROlVEf0eqq8FgmRSyAdEilVl/JJ+hNV6l3AZ5Y1q+hQ
2t4Fy7lR8bsgOLC6yUpVVyf1SVZWQLTOBmwBR9akaAwzykhoBPiyNTFu6dV+jKjqo4vH48+f
EwIsTEh6CbazKeE2Lm5G2ATUqqBU0E5raXpTa2iegGMDwQ0KQYkyin9BESdF+PyIyfvJoAzv
gSO1e8DI0eUSKBqnWsiCxZOxt3PjBlvzeWTW3KjS7DrVdCSjxahl0D6xvg/JXwaQkhGd7ZMd
qZ/fvrZjxGbJU7hHW+oKj7a0iezBuGYJZEiLEmEst14NrZFA5z5bEVj4Vy0N20ym0iO+LJhq
hYLASEHH8KvO+lDudDKlDAe4yXEyOnj+V753nC8uhORdfjPBTa6LU5J/AQ1/hZWWFE6AAu00
H5Sof3gIc8S6JvOzN/FmvBh13wv9IUNQhB6W4wuLdV2PeDNfSrIJxMAdVeDWK6lcwK6IpKOR
MjANDo2M0R2XRuaFZqF5FtHltHPoMUud4cYI6GyAoiCxlMQ3KYZKC6pWXxRJH4LqkLDAtODD
zMxA9BUugc9QFY3d0asTv8MLGETGUhVutxv3jSkSF6Xy7ZypxQJJvRN87R0amdNKlUlJEllD
uXA1H9aNSGBkcxYGFIvIKRcYElktZktSYEe/YM27kDUT623eCgGUh9ZLgC5LljU5DbHNYu1O
uE7eaGRqT+PDsl4TXYTvgePKkPr/HOe/sVHy/cToYy/DIeMAYvqHKJJtQlJrKg8fnsrmom+q
lfu/VJU5EsYse2TzjW8MO+3PTjRZVhm20R8fdwtow1iuI1w+fax3PdPn5NeK+Sr3vg4f2P2Q
5DiZQTpyWDoCoeOs+ZFTIo5EiRh3KV/pSMRU+gOM5N3tYLkTQQfGk/TXlz1GK0B/+LBSbjwa
P+m+ROUcjDE4Pg5CTrXZkKuVzoVMLZMJ3z5/PirPu6qlmGzviGApy5AAnOuY6XVrPGx8P9fo
rTVyYPSIqUDcDAltAyFigxyqtCqjtFksxaiixG86XaYP33nPB+Z5FS9lVvCw0Ft28WS2wWKT
nY0+fOc9Z7Si1ESCsIqdOBhsJgIehzbPRRfvFyoQ5CXnuITf0HQ5/Uqkg0tLFdLebKJ2BnrI
hpQ+eB2ay/bMMJ5MC4WXewXCELWE36PiXoHy0ht+o11KYK18Q2n4zWnFfVpXC+zKAGWCtMqX
3eqjuZdUSlRaQh2pepEWsau6mOV5mK/yfHed4ej5q+7L/WqpLwvo37pXuPcbIQKZO7IRsqB4
RUOKVzwOiyFHebjaYziKulxH8Fnn/OiL5scj5eeOIvcFd/SiuF8Nr/YIP9zt4nYV6IpWgUew
L9TChbmftgp+G+9x3ymteDi67BYu8A6Wh2yHvtV65Jm0R8amTYnXokz6NkpdU+jj4c3VXtdD
OlPOOHUZ6Vz26LbrEVwSnYZ7FwTy5NFY7oqlOmkE9rguglI3++Z2G1xq8jCTT9WBSqxKdjvh
bROZozDgx8v9GDYc7/O11jzrX5I+Nqd2X3YdORKZNTJpLeIbdW8jMjvaEhHPkJMOIL2gkio+
16rpAnwLu6Olv3m0JLvaDMZYBk1pfmxg8UxqaSOkJwAwyyAJ4OXeuGjUT8/XglcRZ87Y+jI6
TFuzPHactLQ7dlzTW2Bh/LAcGe4NR10kYdEycgxjsoPCkD755BvzExkLeedhzjM78Vkef8yn
mUvUatjRbJoaSqkaD43Jd4vATZeUaWiUw6LluVy/sloeFgFDp1KKk7NkYXl4cl4wOUQRDnNj
PlTCq5KZUu6TUgkImHPMH41logm7KB5elYiIYYTzevv7m8pgeclWef6Zgpg1rZpihMdgewS2
MO5165/AbITjp78Xn1U4V8h6yrxc5jto1kw0O+/NXLvqjvd0DvrCtyUWEbUxO0Df5XEoOzvh
3lWo3AA1woXwubni0QqgH6I65kx9gF9DmTisTNQzrfLIiM9yozwKW0sdc/oCBNDtSyeLll/Q
n6Pvj3XX2xeJCwILJNdqTx4j/jvgtriQGhXwfFLrPX7JmK/C8lPXIjVT5CZRxgAZsUeofsJ1
1Wye1g54rIWAUUBJmw/5LwEjxvSydx0oJFXGmzEscgAeMDCQYhUo15YYa2AXZbZ5jwrK6IFz
cL+r7p5K1toa7NmwstXB//cKBbYEsqkQKzRb8EZ73EiV7aG6l8h1udVZqpYFmp9Z3AbT9rSY
43jzesKWtMIJfUJHqdq2VsuGPpXXjljbsgqckEte4kNzyklFrV1bzHeozBeZInbuo0lKWAdi
rfJ2oXqbp5dRrqbdXxDtgLOw1iPvVsUyG1bGIBk1GrwMYZhE12ScNxqGKvjZVcLt1XAPORTW
1/2rxfkmKfTnMYw05NQt+oWZ08DMaQzxa2Tq73v199mrU9IHXvrASx966UNOF3tMIzbDhGbX
J/jd2ye+ZuTtX5BZ3Ej04bl5YJWyWeXLlSuiJoy7SDE7ang29Uz492+idCwuWChzvpUR3Pqb
0GkUXLhEeRDjlUiMCnYlbx6+li+RbDY8Hkk9vM3+3Psw8j+g1d+opt/QKtVmXBp/A4+l95Pf
el35U34bz+L++nxlJpImj5+g1eI1t23SGMv6MnrynDM89zKIh8tvT7q/WFvvL15TF85WZ1Ke
4HsyF5ydxFiuCYPxkwHVREi3CT4gg9GTAdELjYNNgAepQbDiUQHqOS6Wz/xsN+ioOR5Yblin
/cgmmZ08ppjn1v9yzGtdVDRjIUrcFSwCjdHnz/QBqftNownyIqSOWpS0/KUrBDY0D6okeioh
5Deh6VZkHqrJMf8lMdwMSisCNRP7Axve455XeofcXl6cgLOIFFUzIdIYE2aFz7aqDx/it+6u
wwfjnL2A84aq+xhNdnBC8oUuwlGNnb+Q0sV473ElhiYuugUvEWrSzQ0/X3Yv9pa/AFT5VLo4
5Icrkt7RrxP8ssOHT2LEKEWPpSedOkvzkBKt4vDyeQi6LRF1l6JesTS6KhmCQMKhIZ8B98Rx
GrzyuMp32/ATRK7jy5M4la0gsrjnU/pC3uxDhcNfYM2jkeZ+I/mipG0oToa/lLo25eaiu8cv
v9gdEzYZEXG9tCnFR15PKrw01HBq5Rcd0IsStUb95oom7KIsGV5qBpJDfSRh9pd4nptamSUx
isbdK5KpPGuZt5rr1sbV3thHgDGLDn/Z6klJ5oUVLx2+GFfyNRTNRx0PIo6JLwVr7HVi1CK3
f0ysQJddWYJSLkW6BJG8Sr+a+NXCrzZ+dXQJajUdAdCzXWpaLS+95aW3vfS2twS1+juWIB4l
mPqRx+MYrY5yjFZ/v8nBUzCCyhiEJQgruOKPda6g4a8vrXZifZFXu760JHJTWxpmICrecxW/
asKMb0zfTkwxhC1IJrRwQKquqR7tKWlFuAWIP+IDLhCoiWTR7hwyNNpJnNQgNR1salxK1+V1
EAW5Ez5vanfAm9qdnbyp1aS8zL+aCSZ1aZgUH/MBk7o0TIpqM0zq0jIpJAqTSmgs/EGUiNJl
eLVn51Il5E+D8Z5dx9FlNQ8Is0LXhFnBzEKKTFOR6bOkVivBkuSVCeeGJ/dvmEqceigcg56T
84wQXbuFMVB+MAZfPdJpa8YoXyyxLUhnab1mjC26HwX3hpfMBv7SX03iNXzxXL8VlSxK+5O9
imvCxqWR+PfRoBc9HxQ71wG8zHWd16+wRTXvT1G5zmr4qwj3vcZjF7+cu/e/vn9fKJz8Wuw9
Kr5/X9w/C4PH30ZPAlHDOKs6drx//+3n9/yvAA8P60VxuSlwC2ZDyTF7p5DcGDsc/n40i7ou
152K9c2OOpGRMum56qwpZqWXTYPJ4w27njF1DKVDur0ArZk3V3iLI/g2ULZFjcgb8+1O1fCe
n/qrdcwdKK+nE0LIx3ACj3N2MQlBVk4rRblyvFotViC1DpbajltqneOHyxcG/MfhJMR5uWrR
bKcj49PNYiYHXLbr5AyzKalQxh+ukIVdg8OP3Ql7TBkb8m1A+l2GFjPZky5vDaMBWeqrAIto
yDgV6cEn0AVjN6rDiYRSCgH4CuPdfGhxO1V+7pjqilqdX1vRlS2awsROpCSsKWDBN1onVyaG
AlE3MQC+zHGDM3U6GQbsqkncp9M0ijNe2kwm9FEcmuCLaZikee86F02z0Zln42EyD49WIPqx
jJwZYNumPUvh8pjR9fKk6mWvM1Gw3SDyd0w+ce2K6nAqZtee/noYz0nEZgpmlT72UvLWHNxp
P8BGIHI4evJNo7wFYtv8Kzc55BpFu+U2o3q7Jdu0bKX4QTa4rPavOnMHqm2nr7xIJ/nQTHi0
phY+ZFVGjLbxCibMjXUkzdk4Z6827JxscUifZU5Am+kMLe1zd7TVU9+07CF/aMcGmfwvfTMs
N0XP8/en/vBj/yz2TjuyP62g0p2W8r1v7VBCbKvoFg67ARvfz9B67zJbRybjnCXH3FC7ZBIS
jhpYpUfxNN7E9lCY+hTy146eiUi4AYs13Xra4xP25a3+mwL/4klFd8nVhuKcjHlPm20lUgmj
KMJFeRzHGhQsp0iduzN+meNMOC6KL3pA1Hgm88CG15g+ZiVDRR8iPt3qNq/dQBpSKHDG6z6V
PIiIiWMxOEC5GzADzJx0pTyJKEfTeS6jNFOJdiXChYX5g2vkP5Ax5GIHXFawjUaa6D4ccPPO
cxd1lQkOPoDG87Dbl60tVI5VTKcnXHsZkSjBsP41DarZySZ42imgKHcQDg8kxwF+3XCPv1/1
h3Kog6uZ92cxYWVG+J5TpweVED7+eKpqtflCcKplgvD6dEV4NIUOtOABCtsDMQe2mgOuS3yv
UCMDkHATcW2wBZcauDi4kJGR6eazapN1sRoF/oge0Fcugy0OLSAGOVNC9op4w+8Av25k7hpS
Ec7E9AkOLN4SqgANRNlButIsc+kufulC5aVaVWfQcYIoPdMCxB/EBVE+qAFc/P5H/U2/e71Y
xvNXB8ynF5/ilff4vTzawYSZGBUcMJg8oYFijtIsM3syn2y6WC5xtJ4Sb2QeEn1xf2kyjUYO
u3YKFVxvYCV3b8o78zg1LmwVzjZaw8QKgVISYnL4WgvwuV7cytKAHsA2z3Xi+Ch/iCoks3pV
aHIeujyxov78zFDNJPyNx+Q3g8nfuppZXCo8JsAigNcHEXKoglLEB1mfM5/Uvb0mAqdNzHFR
v9QSxfLiA0rZCG7UsUfKR9Fztf0QDSugALPZDOH242PTj8OPsDhR3R8fTz5//vjkN5DGsHKC
X0mZTPr/EXqNR1rIh+PIPxKNKCIwvXjtsM7GYJ/5JArABwvBYHE+H/VXVwGHJwK1HVi6uymq
83E0rHdt6qFHlzduA50PyFNGnQz4zmdXKclYTXiNwYcyE/HhVtL3ru4yk3zXDTbYJfqlTs54
7OKX3SQ4mi7W9txTNGyqUD9sWm9VekaFzcgeqETSjaoezE3xgJa7KUDkA4HY1aUzalbVywac
D6l5jcLKC6vXJUMymtpNkBBMQ2igJ6gliFGIxUpeW/zBKhsWXUCTZWa2ytRFoAz5j4wfz4sC
qi5FzCj2ouLNndnR9k3I1Vu2La/MsfmJMWeOygOBeeNoz9L/cKALYt7JOzO7wZMP66bHIToY
ogJSW7mz2JTRJb0sKxqx6Ml8jg3DfJAJvDbJfNufb8OudP1QYQRGq3xKqJBX8jhEtr29wxvX
NnZlC5L/O2k4OMCqkkccSCouWEK54g3vTlV53444BWM65AThboUio8ieDKxygEc0Bfby4yfu
U0ZcC6YxrsebKJbM8CEyW5lN4LJ7gjrBCVWFyKdjgkSjimoxbLUaica8XMWfoA7mfXkR+jDy
HzIAvA7hlx8Kw5i869sxH1B3VwaYJjzeIHGTxLnpi8mcx2JUNdrKcLwg7slCLjoiAySdKMu3
AiLes/I1qoaTkPOR3IRBy6vfDPNkV/DENpDn4CaMOa4aZz2JBZsqbQ+lcqCDpeVwAlJi7DCu
bhRo6JrSIYV+MJkHtts2nWUQsx3iY+lJV6tgsVurUN4L6oYTMjBXwWZOm0YqcCRr980h+KNW
2RyFRwrCD7EyNGomBrktO29q90RX2mpf5sft0cRKIXNnNHSDKJ0flkFjnz/zo4X9kiDk81jW
YEcv45AzQYyFJVIfr4qHI43sM3IZRnt+BnH+lx3/SDb8GeJ+9nk/3eTm4zhbVnSq91TbG++R
sF7qy0L2UhO98AtSFQlFm/iM5+QjFN5vVCrFR3K2W3EvsSh4c5oo6VGhyhn3EnnW48Vqg9NC
xeK+ZpTIDliszPgqhLGZKz6VQKZB5rLoI/42ed7znxAHAc4oSyJPEWZpcVXKIvAW3FTynLRy
7gLIxiWVXolvBYdaC49zNzpULRG1wIWbq5DsQyyyAadA067B+MuiG/BoJHOhyLjmU2TcMHoS
TBAdoWOQMSJFSQasqvolasgxK1ESK+CdKEeJ5eVqsVkAGGMzCa+Vd2mzTSOhx22Z1vTUx+of
982JO/okjwS4wKhlB7bsyJY95bKn6uROX/iJSi7H/TmvUlL4tGIKn1YtOxdTUhdpblxggxLW
TKm2FgzOKQehM/YfYZiUZ8zGFwxQYuc573bG8sxAMW98v0fNcFF0hwAQnYz4PhtnLnSP9gE3
8omBlmOebAzCxKsY4449lIWNXUcfuKbrEMUdBwRnEIJYz/rrsUVP3aKHV2NsHjFimh7B8slt
JGlRxknd6DTFdPejDt9kgxj4AgZ2QxBnetWfrO2onrZty0wHp/3tFjkJOdpuAFSkueryd67y
0GQ156YtxsVDNPEZflhFr0SJd1/1bbSnb6mlI6/g6Ey8Caf9pe3I0HYkNij0OxGbTgz5XgDD
0asV0j7gWeNIKi5TtbqTQ0+BHfrLruyq+ibiKiboSrKhspOolzatlVV5zxfgFNTuSJlzKSNe
QExSOma4GrlKzIlzjfxc3PrYZmMbrumZmzysvQFTBA33F41WvUaxVtlOagOmmjKWQ32U4AN4
82hXqZuT1cRCi70OQpVWHBmEqkR7B5tgVQMPeRw8xoOKIGrY6tokdtR1AsTnz/qyWLrnVTz1
P8RetiUEO/ca8Mktlha0WTByPvXMQ1VLCCW6n8Bwt+tuAIHNbbZaPj5fHp8PIF01RN4ICTCL
habFAgdK7ygVCxhUfxVBnfiJpiepZ9VWRSoZipqm1fRtNcP7VdPWahgTtprYVBNV7ldNR6tZ
sNIstURVW0tddXrkrVU0r2oimrlhM7cSmZuSGfx/yGfBbIm2LdE3JoPEBKZ0mcBVCUzcYdGE
vUMb6gDJX0Dq4mnXzWf5BO6Jt96e8dY7NDWzdVuar5JswvDCKKzwQtdAfAsL8MgCfMqkvA3N
SOEUM5zXk1OVYELN/9NqMouPVcfgkkWfR21MT7JD6eRVjlrxeTDmAnz2i1lVSMooPoB38d8L
eeXDEuK3WHu0gZyBuwx9DgKmyJeYUvZeKN0Bcmt83yHx682h9N1iq+awRaJ7El1Vs8BVcbd2
Frqq9R3oqjaT6OJIwVzAYKlGMn8NwlEKDzW4n3bVH5O6uccdVbKqwXfRdK5a185h3S2PpHOA
1Hau2dJp3h8hwJLt18D2a7SjXwPt19Gym+rAgJfpJJlXR0zmR8vMvi0JMCxSVJY43HOwcn18
D51o2U2eqGd0dDel5b64DJNwMFISceKykWvEgZXeSqvSJjypQJumWQ8/7irjaIAATTDHUi3l
0RNCAR+NXBWvV93CqiTJe6npdcPJV0prq3tQ6lVXiuxtqDinELHR6PERkmrNuIIfrQyef16a
4CZ4rVcFjwO1zyG0Xz6FYaTpzt7Rykw1wat8hE/jYgP33HKjAd916SpBQd2Vzh0ylJeqNHH2
i71CFO1H7eIj/nYBdyydfIWWl37IuWlGFqRYSTJhz03HP7Waw6aMoiHyh8gdsjOwUBezPCFA
Q651w5b7Q/BZQ621ttuyrdb62QRba+8i2Fo7g2BrfTM9j5Za8JxHWzwN19blWAiXssPUem51
ZY6BAuJVt2RVb6H5wXBZlrOSYl1mN2XTZHnYK39czVmqYOf69cf4Ak4Mxes1tEdM5ZPEB/V5
Wdu9BBPKb9jlSgVZJ1XRQk8T8PDRTT8XHKVTIAuo4mGhx1nKcwHuxL73yhePu+fFa+N0TUm6
qVqt19RcMJnLKoXdK6DLzGir9wga6xAbAt0Irtbrnp1OtnsUhyRn09fy+nwp/aQHkzIwKQNO
yYfNSAgIrDNEEheulboFLsEiosxx4zrHTXTNVysgmoaS7wM1Jw8NiYPm7ElbbrV4SF8Nx9hD
45xghO/SulQ430OKOftm8DgZFq85517XJflRfgRWy/wpb881KiYpJrmLB12V86GdV+swjFex
TSicas/mw3iYKuuk73MysNb0Kr6RqWanpmK21hcRy8xN+q0rSb2TPTHrLbdCHkq2pto7J+vn
Xc2RT5wThmGEXZFEsqh3ysz2OUCSxvCgspCH7ScoVkxjlJKksSOP1vkzqEFOG7O+ISkMgoTI
WD9/+PCoPIc0x3u0ZT7Ee6j1NMBW6J2mpV3zWfs3NYUWK3kdoSMeZOm7sZ4eJUcZXW0gVNzn
zw+4IiI6xFcF4CaKqYQr28Rnq/702flZXg9e5C1tyGhzcW6kyCdMLDh6NlG1soJZH/zDH+zP
WEwczdx1/oOtDLybaGFowO8xpdHfmJ4RbfzicdhL7/lDtWHUWTZojtVTbARdzgwqzUomMP7r
cXL5FCaW0XrLiqL0DQuZzgG8YQKWzMgznvarxT0+YUwtY0gGk7MPi+UHbFNP5meNw190ufwl
lPKHl6Uu11vi90P8NrICniUAz1XJWlG3K43C7bQagyfBxYCSE/yy24W8mHqMSfrtiJ4IRvEz
2MbPwAjtzxcXc09mTyBqkEDUgBFFNNGAMkpDcRdmBhYzA8bMgDEzMBaAEdcp8prnEbpdazUD
NXUpDNQ0YEUAS05iYsCY+OWJGMeuxfBR+EW4L1guQcaJnO/y8S88vXFDD0+aX/YuefcHE14u
KarKIITCnyCtCDMgsY7jgskbCd2jEYcFZXNmAzGWHj40MBEfASvB7HdVY6bytIbvlbWxJPlB
sRf605ar15NYXk1g3nk9X9WACkw/DZoBOHrKW1zCoxtWr220jHkDL51wIhuqlG55JuK14p1o
yz0OdE1pDLpCmx3nNcBeuVLLAD1vDNjCoo+ishfsc7crm295VgJcInTVpQZdYssMP7F1gp9E
qedHtTbwsxhPiqYbA68b/GpYfbfLPTGvYMb0Cg+e9dVssJh25QwJCWaJxcIr0nOvIsEd0s+j
5FKniPZCeFGehw/p14mFZthz4fw/dh0qXfynj08mhx/39iQGFYHyscTGOXmWcOp85lCShXzT
TRyKnyQIArchs1B9ar2BlCyshaVZyV66cYiKl+6N4cPNittEthFUusl0Q66cytvL6kkMYwRc
iCF8inIoG0QqBqA19uF5rjFEjuaSzDpj8bvgXXBg36E4Ugr9OUhw/oYaeY9GXSzkyTxN6BcF
l2l+PkuwSoIXXk5Hc9+OMQLhJTPBBepo5Gc690JWXej5OWnfbiZFB/axqqtec9g9yVtekNfN
HbQgjlkAtGfyjvwNIOThDSDJhMEhyElGJ9DA/vBC7I/f9vgLWCBeob9xQonzFA8vupzrEODA
DEzJ8lztdbnvsOrmpaiU3JNGqEJpZk/aKXEeVMi5bIWUbCtE5RJbhaS3866c7Z3R5OsKcuaL
WaQtnncLG/iofqeZqgf6UPNzy24uzW8h4aVivfVISeygZp5Ere6SFA7wRhLlAyCP9z7Jib/H
S7aZn5PWsNxboX+f3KPni2AaIb36YGM3NCE6tapED/3SBgEvTI1UHVVxeENN92Ec4IZbuCfy
k37JMi4kTGDG+tXlCmA5Y3zily8eINPhDXp31T3nwaal9xOijfN8b44OlcRVi9E1rjkMZfKp
Rg5uALFfH7EjaOeGW3RlGhwqj2mLzhCKgdlwmJY1n7V2mM9axnwGUyYvLS1jNzs0+0mIahXZ
GYhnKCKm7gpjWvyS1c9Wz7qInmfKyomFIHCO7nkPxKK3v6+qA2+iARy3SnAffHXCLQ7Cd31h
H11uQGHTamgVNVsyHlgqDDRxeKRgEMBCKcT7Xigowsi0YN9mwdts4rgUC6tZtU175nYNaTDv
fL2VRyb5YquuH867CaZq0v/uD97RuS52Iph+GK0WS51jfq6Rn2vgcp2rjP9J/y6Fhw1VYjBP
D9RtOpECf9dEgo74uWrffycOwSJnaaXyseAjUz6WT8TPdQLY7yxdiegsi6xIZ7goQ0IQ9BwZ
5k0EUTsMxWuVfa2k+4nlWkqNWFge7xXq+w0ckQWy2iRF19v1BF2gca8N7+RH3np9c3OC20P/
Ypy0liRAhUfntpfLRC+X2ksOrS1nBKhdWXnVQEuZIre2gyyt0p53KfYIJg6HiMdL3pavKW+3
CeCr56pDnIfLULQng5KmsyHt18Uc0FLgmcXl0+ha+hOmzUcbSUWyeNGGPoUO50AcH3JxFmvq
Oy0SoortFWSoPhUf1x8hslyX/pR0+EymQ1oQeCh9M7b3GRuJcKLHSnD4aY9+3dwI/rFlJ/RG
T+2GUCdz7UPRW3WSi/0acZo4+YkoW9f8stcVVWsLGYOQEZKXmPjMM1g12+v6dRUzsBgy4UlB
i8W8eRw4Hw727XDxzz9U2w11cUrFNhd3MHwX32Tr/oEKwutzsYUfXD8/QHy1d/ybrUAQ3oJj
+h2KICfPx/T3GEpEeMyPkvlYMkjuY++NN3dGnuYrDSHfO1M74gAT/t/bOk0qeL3a6s261mZv
h1oNHVXQT5Da420kcFPN17L5OnB0QaaWZIJxWjO1VXvB9ZhtPuyoj21xo6E3TDvzzNEisdSi
2b/0p+cOrE74ydTV4Wh70LHkUaciKkH0uk/KF+WjnzGZs4Gc8vLJtHnsvGuqbQ3eoq0OXKv8
mGeEqvu7dwgU7zhtVy06hiIljkU1hBccIQ3UURezFUBQJx22vWv7o0T7I9f+SNrnKhLNjJLN
NOucp9PAVqBZ2HHhxEyPJksUkOT4n4rswWdgtOlT1/TprqZPk023WrbpvJ4XeNCtS6yybvrS
EHwNSvht7ijIayyyxOUZQBOfnPRjlwjUnaoPcKcKnwKoyfykQpE27jnBSLx+VzrZiGEEeXMg
Ku/N6ufv1vHy4Fr0ffq7PIjgdXFQhdfBQU023w8i2aheSp7ViDIhJwwVqWwoyzmqyFHljX76
I9+r7Msg32v4XpPvpnxNHANw954aEDrwKlKfgw5uK+UKIskWmVx5euRM9FchoUTrOSAF/V6J
pSKqwH/phqbMsUGCYECM51xMe6SAp+AzuaXta21QU29CqvSXgxOIs6R3z2fn64+TJb3M4pF9
ZoVc39gQ/Od4o3epWCvANFzRitkRx/rpw4dTtd2s+K9afTotceTl8RTRoNNUXf2YHYhMDu6s
KjQ4W08fTqYspPU0pgpVvbg4WUnaAxuExE29E/Hipe6deDlxjZwSXoX5J0hMybqjLEC8gNFo
h52dYYwW3bkzMK6zXPlFVx/GyDyQ55H3PBhLd8b6OlLvbXndDM5Pxc0aL5emMneFg/k29DOO
Ey+XKvVSm0NGgnXglgy2Vg6GmO3aKw7NVMEh12IdfNcXE5hbkKgHWof9dZwTDgLvenYO/356
vh7z5FaJ0niHcznjIs41M1iDVdz/eCg15fVYIdtVKjhyNFEnbKxf/KdtB2No/dB15VLtpQEB
oM3hhLmWNp+YH1Kl6k+1OM1JJy4gSy4Gv8Uw9V37TeUj3S1SMkSccLlf95ECX744qfT24WKT
V0ZMRfkEXQXTH3YCeuqIWKo1aBKfNtZBKElPLvY4SgUDy+fMfATIsUgMs7uiYnxpDpfkL/Vw
AXKUugY8ZqNpLKvHzIHoE52hNah2rMYjvtqS/cZUpicNL0tdAzYfLqjAIaigVt8OHAnFFVfO
Y3HQxivea+LHS4k+h0d3MtjRopKn/CnJfNJpxeEaNAakrc1vJX0SVh39JbjvA1NaXuE87z4F
xnWeyVYuoMkXzHV/ZlLyguamniu1MQBrTzY6BgKWxm00rSXgAF14JK6dcti60hbUV1RHQcP0
YU9bm6SXjt+c0oJoJHgKLTQlV7dhRzbbwOUbjPXzyH4d2Y8cyC1Zics2cPn4dhohopvEXObh
lr4J6LSqt9ua7I03J7hhGHt4V54O06YcDLeZusxrFXMmqpRyYf+TRpcSM5B1Nc97IUFto/J0
oQnyx0XCUTSacDiKEPVTN5FAabjgSuUQACrhHWf0x1lSlLxKxszhXWpkSCi05Yvba4ZSGe5J
DH0uDCcvRjfOwhV0empjeQmrJCS1SdJUI3FTUuokjK2hmFyT7EVzWEQnfHxaedrOq+Ey7oVD
wbKN0mtvYNBrGz0p8sXM5LUXxvH7lStrLiTzy+xJpry9koDfGUoRfUUStqmJO7vyklzqSiWH
/Ge0l3gFR5N3vXQo88o5gyPmWAZu/gsbStRKXanGQb7YjuLfPaf5Ozj66KHO9ShvJlneoMo0
EXVg96/WeUlyEveK5VOnfq+9w8y8JPSbKsH1W9704YI4FpMogNxwmum3NDaKPcZBSUZpj2oc
z1Aswn0zTdd8oWh3LRQ24UWi7s9Y6L4Fe6bZtjcomnpT6gNaIf1hOBsdSIAREY2D60Bl4+Am
CKfxBpcu7J/09/7R25/gjPqA3yt7nd5+KIY6osf1wf6vhQKtO+PPWHaK5fJnvAz7088n41kP
Hgzf7oecNO6TgB08CA5OcIN7rdYLgwK91OmlXqGXon6pR/TyiF6q1GHkKvEzfcBLSC+0aISN
Dr3saS4UL9NzBR/a9LKvL03UdUAvNSrPXw65fEXKP+YvlA0VdDUbl3livlTp5TuFrAkAThTm
DrL19EsHXz5zo2BBzR7pEMt4OOmT6hH8O0HwbjIdxQT8r/T8sj8fkaJ/voxXgkdK/+ClD2xq
DjYWOc5PQ3WJ6+LziSTIm5glsKqvzMPcz4L87EtML/9iGzlazGbxHE08tGkv5pvVVXBjB4vk
pAOSgaie6QgdI3RUCRucsrIpNU2ZnpuUusljUxq9kG8KkTGJCHGDeGPeqMqz/mxmXmu40Xxq
v1Jl8XI9mRKDlASq6x+ucJM+25dWL9yM3SuN9mRh32i4P/aXS32t0oBP+7PByLwTTLNzfSaI
5uaZwLmc6DPBsjTPBMZqvNCXJsLFnpkuVAFH31RAUJz7HagSIMuxVlMjMIb2hWCgnPpCQCxm
8ZnWidlCOkoCFbU6p3ldrjU4xQBZa/KrhbPW4ncP1FpbClgQCLg/y2C0cKVID8f6N/pG4L2T
tvBG8L1WBOKV4PvrRB4JrJ/0keA5ltbwRuD8bDqAdwLnp7HmJEB+WuszAfGjdJ2brYB64uVY
JleTqp+ARA35UMu/+e+gmOlU3jrU5MXSfCFo3sZaC1X6aqbPwDvhEZNVmAaamJ9uruR7HSOG
GaSvBGo8W26u1vFGUsBK5v3BtK/TH0QLz9yDk0j8pXuI66yNYQYttCD4CXH3/vxsqpU36DPJ
8X3pAL2DwC8n681a3wln8/hMXwiS6dxUhrdTkiC05xFgIqHKdKqDmMY0qxUbYFjDKbGa84mW
Z8yNJv3ZYj7yUwlr45jQ46eB4Jf9UeynEWTDxXK14G7XGPWDydmnOJb3dovfL+LRmUmRHOdL
ktI0pcEpw/5S3+vyfm7eaxgYxiW/VjEwpsF2BKzP9KXCJRcbGjatvNWWJNdcSwBYjIBCTqD2
Fl4DrSpnWP/dQtCietczGh7KZYa34QaRRbMTnDivt9goZD6Y46T6URo2H1F5VQffS4ZJXT9Q
vxVxeO3UwbzmI/fGWOYXAma6WLkXxiW/UOVD0xKoYzTqn53FmpU5ezIB6Py7LR6Buyoi5L0J
xsa45BoJxD4h5sx8rlli0j5Q30hGiTeagd4vTFtYEUaTT/KGMeARETDobU0S/NhkpXcdVH6v
gE1O5hYMenVA0YjPFF6CfjmTRwJ8OFkNtQIlMZdAgNPM9uqM0MjQgUQdXW+sdOIBgxlGMpGM
MeY2Eedys4AgUWWCWP99TTMu3sR/l7QIaxQSl4nEDvMjIrJ4qkkVKjybjMxbE2O1Hn+S9w7Y
+ohRxK/0dWoq43Uuds9n9kOEF/e8Ph8O5Y2XoVVs3sB9l9SRS83bkLy2nprktu9AAvdH39Ft
7rS+N81329+OyWFTIKdN5oG8NQiC+USfMfwX87V7OzvTeqmWqaILay6zRc4EZjyZ6Rd5MQ1h
uSMhbClvGLH47+cTRSsIvr++mulX0Pt6NhFkRjzrTlc8Q/mV0PKaJj/Pc1pyFxc66nVJ95Oo
P2/T2aIeh3lKF681Jd1PgrwUb9bubasQqHLhnmf95XqzYPFbMNKQSrEYLBbz86V0AXDl5Yy8
fgEDYp7FnyNtKV2smkwfWZxAXJ/HPmCghUQCBurCxwOoK5FACBgP+iuBHjckg8Cm48XiozZS
Z0HMvqJvNFWXqiS0ZebyK0/d4YLFj6ZRB/4UqPxCBYNvzQu1CmFZXghqSMny0ibJ3kYvINm+
EAhYdUi6RovhBCwXkeoLFdYXKKGqOgMn1CihplqI6A11lKmo+iFJDT5sZVUa3vysMdvy9Q0W
s60SpP/1QtHvDuBIKpIJy+MN/YDRni3OiWcNxzFrNSzi029IQJxl5X9viMCP76aK6dlqcb7k
sk3BAWOVi5pPDXxC51nlwice4E/xasPqjNcHem8asJ+aTDYHOs7KGT6ziiF1RDW4LbCmhi9/
SZcBS+cvn7OT/VoiU8v5kqFUJlQT3BjYQOSJz4KayJZNZ4gqbQBvWvw5UXmdD9SBM/LH56my
9Rp/btmy25V3mEgMenHzLq+ZPPLULyiHLFLwaCSoigfRfKsniZBHkfFsywEU08zUfJJi6IQZ
+5vMAteZeVe4vcnmZyHLNKBfpAyIy6BoxaFItFAHvbcEab6gUAdIr/vgfkxPRttH+0VmJdRg
3Ct5cK1XK5ttloMTo6fzHo34UQQ9DlqoeaIavEreUaL6M/nJxy454yO+rmZ+Mzi1xN50FYgA
TKdwQMdCOB25wpLEh1DljTrnckPIOTUvzZ65tY8a4ftT1hyRED3Bh0CWB2MWwPIVaOhBTeLl
KwiJLa8nskIEP/Rn8ejHZRDKKkKfhos1NhIRTpzeNriM2rydmUcvDz2O3fPGe3TJ66F5HMVn
7lHuf7UQwBsF9xTK5/hyaR7PhiN2uIQNe2EzkKZnUj/CcCepU1v/VOqqySPnTnSYLW8BfUoZ
dn1rbS4oRfvNUhDPYK1UK2qe2wa2JzNxWKrD85wekWbRNV1YUGb9SwPKbDI3jz+tzNM6tgha
T+beo0WhtoPM3ojQo8lRgzXREh8iGzBhcDLvcyOeeoRzlBxYXZIQZ52T6AFJCw3WpbUgdldg
zstfTDZjXkB55LFD2Zdbz+xzRo7BAmZx72U7DzMjf+JoxLDA8B7DmcQ69ZE3uTv8/STAogxL
zIKdEuyHQoD1XPqj9ROSKhCScL/sWjb++Vy7/1liQ6KQE822PlmxbusLRwSSdrhqet/TdK9B
lytqILr+lMOeWJy/7stMWHFy1KhqoA/zPPKeOVDLQfAWf14vLjBYU/xJJs0IBo16dBC8oRcw
BuUElIbPquVGDZAGDkQcBIjAF/ARZaqNfgek76zo+Zh+ByzayZi9AbcNrFxiZD680qyc75Ub
8Sw3DiBRcgNEaCTidznh7+kU0hDnJg2moVU8vdaKgY9rU2t1dr5/c4M30jYgG87PtFjUqPPU
o55TJlNY66Kna07iyrpcAeOwOTvHM2kYOCACSpstRj4gg8lcCs5y9AU5ll4OgJSL2rPzXMHP
hceQf/0pKgYsU07mkHASSGOzBR7mCzmyGYgtw1S+yMpAorHD3uB8Mh1R95DHrmZlvHGIvUAk
67XfH/aaMdhhuZtX2sQDejn0CkYNbNANTZ7kAzJ/2spsB42x3F5urhkseOTnKstNrkk/9FeG
Mpm5jsw3N2VUPNqqGBiPZNA4d4tyJ2puSc258o1HM6nKs75EiS/UBNr/jcaAyccjMSbuunyn
bzwfvM8c1WnvRub929T3FvY5YU682EziRLKMSMSRK/CsLWuyzeKbragiIrZ4uk5U9NkrjbZE
l3QkYDRLM7ssvwtUK/TUSVMzryXXFpZqenxrOuGS2uaNjC73ikYOKIHal+CwDBQrhwqP1+8E
aOAwlMvnwVLWJGwhLc9KJhV9TUxiq1GODCxxV9+m2plm5c/LUGuHmojJh3xpeOhL3eTVprdA
fr0TZAlXjGlL5RIDFzUgbGLcroez9VVUubmu3GQBk4FdvzmT/fWu7Bw5VsL8Tk5PUxzr0FSB
0xmcwATGm4fJRcFwGPqQ+1N0wzyQefGMiyN82SzxgYVd/jA4tR+UgQ8G+i1q1qvKxjYm+2Rj
s4MFcgOW2y1WI4ZkPFhcXlM2Wy2yTjZZWdlrDR4/TXgO3CSLJ8ozyIKzRg2/mvgl5zw8VLxz
K2LUbLYgUBKfxTpFK+Tl9Ysb73sVa+ZfRcCcwGIUvBbGj2bNKuClVnR7VTYPacknmVW3T1NJ
T/yk6n5H91VtUmOfbXgP/LQ9LkrKBt4TNZKq8vfz/shPo5RUEjZRaL3ZLt3kHZGsb9LiGC6a
JBaJ3yZQY1/A5ik/joRRx2EaWsWjgPc2ht6HASnImPqDyZmhy4/xs8mZqEwcVKNSxt7FM2Sg
YalqalSOZEcjnVyXzOnkluSe2mSEMnN1p9IjeKOZBsy3qInjCKb+ZKpWvzLVSGhKV3/6Q6KB
la0KxypMA8lUbWBm6kFcNld9MtnhJp1u6k6no3adW3nRNxhvmri0aUubxK7CmhjPDXeZqpCP
dOmpMo2JzT5geVCXSkkCEJJPnZolWY5Iywd1WpYPEgzZch0Jz2sk9ha8WkBRKnIdBM/w9BYd
BXsgCn22uNSbEPR55qWfSlAI1hHwDJrdrM4hV+NPwOBwimFKnzRq5nWBpU55IVL+SZ4CbJCS
6JX5gfjCOOMD7wizgELN4k8Q9od87ZnMkc34KUfFCUI2nYKWOr1eeLbqszLXQjAMYhMil9mE
aquHTZXpyOWpNilJJB9OqFbxvopdNdWoB/UtZrVOUiqUMu7bejv1HrbJhhnACWihNOOB0mnQ
+8VkFFtoELkVtrFIP2j9ktxBV+DHcRKwrMY3QRGL0AP5+OROR+5VynWaGZDlc1KCqhGl8+F8
sF4eury9UPeHE5n+dFmtViuJbDTmqwmRyBv+C/PMqn/lXpf6/cSmqH5LnA8ien+NfSz3EQsJ
tOYyoSjAzUVog40dVeyT9KeTs7nFJhfhj/yLUbDSMieyGtTCAHYyNachDhwEwhaWuKGpWfMM
V9bSRGKUsWL7SfMFt2/Sflg8xWtg4JovTNUCRBisBJA2DO7aCm92pPJHLYSYGMRnE6r7Gf5Q
nfPRQfBiThya1MqrhAkQPt9qm3vH36h8gy1xatyTi2Q4sao7x+YduyM8dH4m3tldndl3bCv5
77SevX769s8vzHuLiPzcfSY0v/ReO0zPVmNj9Y015ovhYjbrm/j72KLFgFlboNCryTYfCbLg
D8REyJ6OC95m5ldkhk+hCtYrm8/7ELAkpKTOB0X5SJp9Ha7Xr0bu9Xw+wc3DLmEA7udqHQjT
W2G/bhUfyIzjZ4Edsi1RDO5AlvNp8fzTZLWYw+lpzWdhdHY8xZ9AuTRRsQyvpjqCRgNDVtfT
ufKepUhm0sDkgX+fNS/Jt2epb2aS4e+N5vmUkYf3QRKPyPmXjJx/cTn/4nLy7N5qtYzJMQ28
WT3vS59gwFkN6RNP3tCfwXJgS5zb8l7ofLg8Lga/8ZFUe6RihEsuTKp/OdzKxU+lL2V1ljvJ
h3zH9GTU63WpGB4Qtv0F7nsTT9HCWp3/cSmbdf8XJ8m8C7Gfl0NfSNG75czRjFjqynf10d2R
9gDfccKQQ2h1ceXSDU2Wy82rtUaSYQC4KntNgbkMAO2bA7sWPpyfyMEdmD7PuA71d+WL4sxd
aOY4hmoCxQfdQOqTK9HaksyhSfQZ3bJ3Df76/v26RIo6OlvCVYOBBtz8abUYxuaEWoHN7u7e
ie2bNcx9G4dsvz/zIhbn1a0VdYSaSy8qy9t3E0RQXnS3RO5sQsvgq9wWj2VB2vBvfOBzOhon
gD4pTOZuiC7H1gY+Oh3eDMJdgpA59S6KvCuSxz2s603BRDiTs1Z5PeaRlyJeuJzg4UNzk9TD
hw/4kYMLmcflw4cFU8qLUaijFehpBVbUgqIZMZObaEj7l3UZhwX6RkYM17YLy7W0Zq4JqQ5q
3f1fC+yPW/pcLua+25dbwIczHK4a1MrxZTy01+0oQcotPSZxUjTBAqmQmUalLr2cRD03c/hy
eE7j8dBsJW+shKgF4Kers/NZLPtJ1lkaV60ocRBsfKA3zzEQMSBcoTevCkVvSlM7N+a4z+RJ
N9kfN8HN3HkAg1A1QVoYmTeT9Vry5/oKX46YUi4oATI+QNIxdybhtnuiL8NKWCWQABVSd4TA
cbQ2rvo5/pYzWw3BVj0RX50J3OaxYyvzFfVSWsl0BeTS9s7XcPsPpH3RWdw1bPIVt2/ysb/f
wLdKJUHOoSONtkZYGsopiAh8XlH42CcHD3c40mbqVppQHCj8+cSQ2HskAYGDFefCBoiwjCsS
TXmLQIasW5GrJnmLg5Fmcba3pznYQMK+B/nf5Aq+yV5UdPdRVuyIbg+BYAojLRwkVLb3lLcZ
+dpYuXmOWJrBf1UuTcgLMeTdATNdK9J1OsrnXNpCgTmYz2qPWeqzLSPSvmkLUfajTjuMtO+Y
+iYoY94SjvA0wkrcRQb4RW1WhUhDRgzAd7CvQgsDfS51g+uglOgT8hRLwQ1TgWntfllNX+1Q
IwOPdoAtG9vkia0Hs/8Z9tJilqlMjb3f0XgVQ6+RrIRg7QGD4n37ajsgBwuxRhCANqaxJQaZ
H1GtLpSts8jMB1k1cL06JjBu7aZPooGUEtPXDaltOK+cQKaOdROC+81Qj+MKpXOA+KGcuuWZ
ARUyR/zpfL6Kh4uzOa2lo5ytQFmXJdjEiqls+PlkJqG0oM7OF7NzIaVVvNYbXqrDOscZy7uu
++yP0Au6x61TMD0yhpVXMkHgEw7RVKt2MTnkOiMrmChVsKig4OQLKBfyzVvIzZDJnKm2a7LG
UXrD5mh5sNNrp4uvJsQZJJ1HhZO9Uu+7wvv35ffvR5B7RiV9eVT8rlgsLDef49nn+PLz7Pzz
8rK4L3cuoy7LhxjbI0AIbQd4n2zWhHv8NqjG4OpUBVhutURNuHTI3OXkI/RGbwxClqi3p2Hd
6KWOW8CXOFQ62icstqlivlPz0JttJhslLzeSE8H5OZp+zEUf+Tf7JKMAa77ZuRz8ZDRfj7oj
Ety1jVH3ZBQGlKFnpggGbSSXD/7AQqUVbxMThDPK1OBxq9aZyjBCQyaWvFZQsHdEPwCbsIsY
DsQpCcJy1+RDU8O4W9GlCpMtL8uXW5NkQWKqzEt+u8rQlNfTrVJPaoXJsaCRmy4WH7FgnLK0
n3uf7713iw/K4VIsc8kLprlZ70wrPb3lWprwlij0I71KmWXqaHE+Hc3f50ncmECKy/OCBTgY
ACYvK5FsFkJqjQ7H+QIef17yLg3P4g/VUeSPRrXOkwKXZ3FQC53Xo9pOTLKPBnJIr2o1qaCW
QlkNsQYsKHlu1yJqVEsjSs7qOkaguAB/aoCTsPmEj4yPakRAZuLUHbFL8Rr2y2ooEc9HBtmj
GoL5aLOmKAIZCbeqoYfJGgCukWxwwBVIs5Tkf2SaMrzk5Fc52VbkkMCUyaRrshMa8mbUR1Vv
1B07GEWI4ipS/+oMkFqJ2RFGjSkzgeJSYJkNj77KECkKQHRUEiNqiLdQUC45ahW9JdasdC+s
1hDP5eKO/GAxujLXwKOsLx7i/UGXsiKW2+iqZIQjaUkGkZZcyoA1NpQx8ld2kfHtYmHl3IDN
LS5ztdFk5KAVd2ut8hqVniYzkzRUyPvrGIyyya6T+QK/8wr6+XPhAd7y7M7KGc2x/TwfN5ab
4SBQiajE1+XVo4Sqi2sNE9fx5OVCPHMlLutqaA03euq6zi1x7DGd6wx2btg/X8fr3GhxPiCu
E18uF3PVhnLnRlJdY6oPp/3V5PTKF1mt9IEw7N7YDE14L0ovdR1m+RhScChstwbfHZPRIzkD
J2dq43AogIaUa76UJ2tFeZ5vTHJuPnnL2sfWvGKECzfCRruLzBDzJfS8J4E42dgSTmbmqZcp
YLMQwqQpdyuxr1HxetzdG8s9pXIF5fY1rHn1W6LB0ouLQ/FjGvOQhQkPJdetS5AZTmPUUoBr
Z33lAdei1+E8a1yfCLDL7h6fD69jP1e010vWqjnBIyGcfLXpknHvsqhLaNPCc8o6sU4ivof9
8AZpIiQgqODPb18XkKJH1s36f0wYXJYZZf1RPDqRinCDo1VWnPbOZlM5IwxhFHl7AkqknAZW
G99I927Vn6+nfd7NKUOG6682Xb4cVAffRZcxwfLUdsf32Ea9z58D8aANeicowrYE7RJjIF/g
nOwv2sB+S7m/vpoPx6vFfHG+ZtvRhl4ucoE2H+id224wOcJsvVOTkcJQckhVk5K3A2XvgQ0W
7Iuot23zcMATzatSSJhkHFsnm6+8OvWWuuRNszLyehEM9l7OjF45l/gaCI4g146YWTk3syfP
eoAhdb0Rmgq/1VtKfMjq8BIs6CrCy0GwOA0S8zABb6Opoa3RdhcRRamdBpZGs+PoWmA/zB1t
AG2p2b5J4X6xVMnWx0ieN2Rx5LF4uFi62wToGTyPmjx0XV8seebK7no+QZnKJ9n2pnSjN3Uq
vT2StpeJWy2rp8IqEXsxSREMHd/8LuUQR8NdfzMOUTQM3tHqAZCwj+DwJJZPb85y9+fpaSwW
JE9eP1GTKc/RJmSxHi65tjO0gfsCNDvfUcJTX8oUe+5KQu6A3h1ZcOAjIOh8ryJRAAj0kBGL
e7y5E0Cs7BaobFGrqAlVTcGUua0Bl5mE0h2kAohB2fV4sZjyYcsouUWKdWXZU7CGYTYEUoMn
DTAGQushaoO0gSCroDFJQFwrQgk/b/q0oNq3lcaqtwkmjgKkRoasWQk7CiZHso8czGW7dSgi
VCQRV71ZDAS+7l8tzjeFNNAKCSPspNrTO4L4rea9ORDlW12/GQgjItmHD/kh0nt21Z3Wh8HR
oHf/0p5mGI/26+G2bUEr7zG9CuHXKiQ3NltV+Uh5cDWNfE912l4nxEGx9X4vlO85yz6M+aFv
5C8m51HBNFLpJW6BDoq6DDI786IMeLaYvNl4UWJgE39L+A5JyMM+6efz6VWuv1zG2FGa5/o5
2fbKsSqFjbqiDULKSyTYibuIHKuLkjXfUy7f/yxThyTTjgnJqrbXsrkL3pkKAo+6zUnewLsi
FBk7Ytu8SYOA66gFBKTBKb2gxtzEtGMWKPcIwibT4gsEDY0KoPWaSWdoEL/NrO/0rEoO2Avf
Wufddy+RQpgz81C7bc082ENHI9jbOWI4xLQPaxBbYmqVmDcGmv4YYX1oot8qv/HEJ92NMidW
UeGFSBZd3n6H9sbpob/YVEJWqpUmmpxJ7DFMK4AKey4tiL9Pos+fLTYqPY1S7WIW8zeevifu
0e0i9KzVn30WW1CwpTqdyl4pH8GMjxvTMFiSQZ96IiTtv5aFwu2MDbtu8678qPAJyZ8/Sdjj
giimxf1JGHxbDeRyNfquzXe7cnyGnR5ViBbJx0Mp8huUvo3PXlwuy99GYSVvxV6J1oYtuV63
YJ4+f64US7AH6b62WSZwt6MQQdTo4tVchkXPTUmo9cTIRjkw/lHDrR7QDY0uKXP6JvAFH1Nr
w+Hk5NfhdNXTnUz3fb2cThBjXObF9qJFmdoCji4yh/5SVkckJ89oq0sarnZsQkZCaW6tn1qV
KMGuSvTsrUr4kliVKCGxKnHlZlWK+t6qxF8Qq8XVCUw38KsZJqrmEaDVxNRZ13WEHpLriLJ7
zpBYC3BLo/2IxyY/jsDhlaOk2Tnnw3lI9oFxog9bFrbEHEpNmFUeiQFF1eRX80/96YRtYZ4X
Bm+uiCqRI7ahhgY8OW4uHAfB/E/oa8/W+PP845zPJrdrNPwwXulGqM4BzX+Y5zvsOZ1N3N6u
OlK7J/SrJ/MYj8Ab+hLSs+6cRrx4sWXlFhRYbqirljWb5HBOiWSKHGMHVkB/KVE7mbGJmB2K
8KJ4ndAbL/YqDAZ7rTpALqS3zVZKtNVCUuTZ4tIutnxvaHy58bfBbNF8SiDKi1CJG7FW8/4U
aey04EmVqt029Z4cbvCt3rQgrAM3ESqoW1r3OCNtlEwjwHAfkAj6iOtHtDbGrRXXYxfvOCpX
GvvGpB6OZVeV+GTl8+cL/g0wYJVkL14bgtcI2hwMDZ3F58IFV8DruubjCNV6aYRWPpJKILml
o7kBj/FqAyVwTz3USloHAq6NijvCC9OrRBi2CHWLtheQjy/JJjj2RuFINJNjcfKEmyq0B44x
akcIqhVPYtYOUhc0QENIBb7XeH4ax69yKFebV8rtQ7nevFKuHZpr0DPG/idzMTuGv4k+p1Vn
hqyONWppvEivjWcpfEs+HRibwPhA9Tqx5hzL7eb3qHgtnqjX4phK+dQcZD0+HXXWOnmzi+Er
sjiKTnhvIsRwX51Eh8VD9uiQ9y7KQgN1qiu+oh09FuqD2mWdw2OQw/hstrc+h525WPwuOtDr
2FL5zn5b/v2Kc1TK1QPeSlKUFK9Z4NI37jxGWdRujLOaoXA4lbX34WwVVYKwH0q4fMWxseBg
RFUvN5r1jTMTvNarAU1/GDvGKssuMp8/W4eaB3wvtyceGjF+ss71pzDujUSax67bMl5RwRXq
7kQYRK4mDUnIJx88fDIHM599pOhqv8ZanPd80DSsb97ga1Iq8Zby+gS/aI3AmDtWeCMOVthh
QSi2zWRzvomfck52olqzV7bEIK01OR8RADIYB65QdgwQKkF3SLoSVrnTaVpfrDURYL0vBMhd
UjM9pQ7N85B/s6NbRa8Q5Z5ISZYB5V4XejfOBOKwIXeyNqTqUnfIcROjurqSWGcOYot/CmS3
xH0WM6P5phV4XnJuCyVCLMDi58/DJ4JJQCRL/nQan/WnObYA5jjee4x97FV8Gq/i+TB2G3HU
XVlOKxXjIWbQiW+hursVQx6x4R6N9KHBl/oqWBB1UzOq1PSmW63JeA5G4brK20zrqt1SNvs9
Dx+u7R5Q4dfPJ79Cm+kVC+/1X/ERfov71bcs3qyjknj3yU4qva6rWAFFjBWKbUAFYnONTksE
9m5YWmSl+qSqf2s9ZlXv1N3caFqJ8gXnT552FC86Je5135MT2LwNBpcveIK31SuZa05xXNga
0untABP3xqvy6V2c3cmP6AxbQF1psN+jhe1WOOTnvCpokudd/FfQMBMffcYqwH8j/Vvtufo0
r3GmhB2PzV7IyCMsTnotbAVhMYzECKDX90oKLO3yXsMxO9zla+8VfmAMdLeY6pqg9G27XPxX
RoLWCp52wkHWGTaGUqxx1iLyl/5qImqp2QCLKlANaC5hk2XIMxvI4/tbE8aUHzgq53bBCm+O
VUy2Hzdjl8uQVFRBHFBa2rIISONDOsFi6O8w6+5qVKlGwijev18FxAb4ae6F870x9R2bQBWy
8jZrgMIaSUR8QrJdVGUtlxAb1+Irrt99opTLMqRWE6ZeZZ8u3lPVsbs+X5dxoF/9yr5fOOFA
rjG0lNLFuyxHip9jDzWqdxivPjvFzJ6X7IOwsqH3MteaHVlhvE+qrci3Nl8eRo/dE/w2Sgqe
WUuhAkBjx1NTVLf0HJC8QJ4nogT1EhPOTMqCqENyb08buRKVwVmJ13KuIzKPYfJLT0GphDUL
jK+s5YaEwtVimlvHfz/HEpB7n7fb4WI3ZvuZIvhHNsZZhxS2nVFSwSNROcelWYzVjc15Xbs3
ZTwcIGHoJsVtJsAH+AzjEucri15N48oiT55bLKTsfryvv1jlZsbjtFWpGYHGsmOpR/mx1Jre
lbA9ZPOjM8clty9pzONE2Vs71cQKCxYYwephbJDSDdSU7Ir6uKIy2bX2upXQW2Ur1HVPIm2Y
5S5vhqJV6XCbXPfTGUI9Ls7XvCm+OLWuEAxZ1DIF8toP4/d9mLKlft9l4VeWJyP+qW3sSSXB
VTg775ASvF2h1rwKjsoWoiqfEQKOExlwj7sVeHyp3MUd+Xa/qK1JJTtH1Wsj/d1gP1GJXFjh
EqMqzFPqYZgC51cOhpKCxF4VmlSmo2qrlZGpqzUbjuqiElsOB+eJOx0x2OHiFu8LLDm45rze
qJmrAJstFXC8z3mfIJ+nfSrq4JlpFwfxNwjWXjxl38BoOzb4I7vlOYgMiin416bpte2ByZrs
wCALfI1EfvdCnOD5J0PLqsHXa8rXLVHLURcILENdFE78pB678RV9jy2pX+KCw4K+idcbkiZ0
RYHs0WmoFFLDyIqXvwoolIRg+tzRoanWutNWWpp8c+P2T8DA7ty5YQ63tWMDFtwi6St7Y8bw
JX8/hlQF2XxxiHYG5vxkPtkcJg4IoZqoaa2nJLTLduzu4mpek2Vfb27b2tjRYc+lr6dirxlj
OAI78K+l2nFBp+d8ic/GyJO8P16kkVbHXJhTa/VF29RKB+Mn4lRVHj98aBNglcJGSAnX1kew
+FMNkYUEJUZ8VfhIC420kMTfIuzYWj5/5nzmO9fV70a6qcE2OG5drX9oyfh+mk3M1eIC58ko
hU0MTwfrxZSPIWPBxD5GvdqUxgy8V+qoMN6TLh3e+MY+U0GBrW1s71IngXFYCa9C23+m86iO
KBKf2Nj37PyMbcuZFz3gxOueOCccBCXf+vhiZnzR2FBdCg7NUHcgUj4xt/qwleiq6+yJ3p1v
guY9hW1U3K8xNdWxs6MXJeTsVRPmpolDvRZidEU5cqgXqumVs1Ha9m9kWHQjr9U3F0soLGI8
FSgYy41QbgjFI80PQ4uP54vB6kn67jVc551s8fE+Zwz0QgbIWGV36rAgdxcYSdzcX+AER3uR
gScpBlyTIRrn/xdiwDwbk0hZrdOuNisS+mFeUrHJzd5MXT4xK1E5et4VUtHh5LHx712zX2ie
7U0oLCVP3KPdhbQlcMPUjXRafKW61+v+aaxnWw8i3xpGWgr7fAnE7ZpAHNXbcuGdfGThlR2+
ZD/rBjlBGO22HKVlXzASN1/37cV/vAeSqLtpsJHn3ZVDJPEWS9ceyUV+HJPFd7iYh06diiJs
0QAkSRKQoHqLdTCqGAfxWrvj9wLvPqx5o3OrQffImQBY+ydFZy0wkzLv6fUwylrnG7ARSlM4
JCKR5uPxcsaA/qzHit+h1ERZW7ADcEbdPmyPHJ1YZcuSwxDuCgAK498enQwJX3ilB1g3qKLQ
vLLEqb6B0iHgcz1eXBTNcl32KOHhQ85g5EA+/0D/738++XWvv/ePyl4HbwcfSt1/+Xdxck7k
P9gvPnzICXrCqKJcDV5ixl36QdelFYtyA1ydfhpAQqQqHpLycuxJgLTuigI8jRSl5F2fitdM
jEJeEINL3+pOLxZYH0hz2PHgMzqGgVh/js0R9TWlFdkMx9UF7sN+UEKS+F+lkPSbiO1ILXUD
erXWOynCF6bA5bONCO4h37NWx/7J6Krgsw/pMB92OV+PC+rAyKfEnyadGIk5DX4rulNpz2Ii
jviYUMPKomskarTsPnan3vUWuCNRnEn5womGmBc6buQ7zL0GTP8Bn4A/TrbMC0AD9xo14AjI
EKJuhUg4K1K71/E0Bvs5OMFJcdLNpwcVT+6EjwbJdrBYd1qGJ3TaSh5/ni4G/SmfnESc4BPk
NTY0znei/eADL7KJ24TM3ete38i8xyrYtcknaymOVOzeeW32tU3ZZV97B/TRKrbvO/2ycaMp
HnK9nGa85fQwENXpwUENdpH10ByKkZcQNtc3bKgU8zEaGaq8KxDwHpokU/7nEtoiXSROFnmu
ReKiPbv1QtD/zh3Coe+01rQhFa7i4flqTat1Ipdk4R6flvvTTZePiINT0N8yomwTyQcPg+IT
Oeohewz80fpZ4Cz0dHOI6fdYqKWJo7RnkvTES/r7+UISZX/eJPdnS059KCdh3Un1MC9hvbQv
/cie16Hn8pwQpFfr5v1TcVGz3lC7mck6HE+mox8o/9o57fDhFf8gst3XZg/6DhbOZqPi1l7Z
HzDahrkMnvPgSkcDOzUfwV+G6OTlZDSy9icCpA4G3q+X2bcN1AFBBRdgTtaTwWQ62Vwd5MZc
5tBJWX2VI0XKqiwvDzkWLB68KLBsB2EZkjfEpOXvJ5eH3CALST/Ykxss3HGOLn8+nazWmyPg
SCcc7xc/W1x+j3PQl0GxfOE7dWvRxNs7vhtWnbOp969IWSkoaRLnwW52gi778FHhq6/AWZrs
yI3UvHVM8zCo4ygfDXH6h/mwpzJfMOMQx6ene/+zVxSDRl7ayXc3q/P4MIN+UxXsS+QD5+Gg
Ey6PWMy8j8SQY84wRD5yvau0DcBusLuWqA1GdKY7pLRRdSeNFByMZv81+9zg5w4/txA42sLV
YbgkV8eVgCFRlw6d/67RgTumrS7yorvJItIfdhX9A9dTVtwXfNTjqA9jprfllSuakch9/pbG
QPeHD9lfM8+ns1DXpn+GmpLVyOmN0eRT4OwBbFblMujfkPs3KC/mw+lk+NEQ4RFeykcI3cSP
JtNoMN2V7/lgym95c3wSW52YjZhPfvutlkbagkg95H6SIl20PSG2afdfuyblUHglxtxQGrjt
/kNmdOB4wgBbPMj7jzmZiiVSn3DqGadyxQla4oyIGNENIDUGotj2eWdGPmBjUQcjkEPCHMBN
t42S9GB2Nz9ycaz3+cF0McTZR+wN85mNjy6Qgi71zpuRzd1i3OWl323LuaaOFrMlznjk3dWJ
UQvGMJ+7vKGM/TOWT45pqSWCwDGHHL4d5I647lhPhbVgMTua0iol15+KmNICF6wYqYXPSDgL
dd4/nqNdL/g9gjPsx56FLjJnva0ExDWEHEWrxjtfH52EpE0TC3g3mcXwAg8SYED3EC49It35
yoD1sVSSq4XFHYljzxeiSuXRx33GUF2MOmkMMXq0KzCu42MeB8aC0rIU/AvhKAmIHI8xgBeC
0sdSkAESUwcLhEwQJObxWGJlUABgiSIFGqfLi9eaZhi+j0t78As5DJ1xdJ9DM/LEZ9RgCK2I
9QEPlfzaAus7yFX+JYBH761dqmR0RzxYa7Yz4URuiOwakaEFz2X2rXCQRBWOr8eY5+nURJ5t
sgCPNfKy+LQnoGrwdrmEfipNgO1iii7NDhmO3BmO08KOKqI18JlqH3dG0lcBf1DHbjJvOCE2
Ev3yPNJGi6EJqMJuugQJDyXvCUrWqA09uHxmRcdnV69GMj7m2Am9eN/Xz67eCd/Oq/t2R2AB
A5IKmbKIg4vqYFTYj4Tej4+Ryxx4/wiRihpB2snHnltbEksJvuo6wrlTxrpVDNX/x397+HAL
TlRVvDa1E9U83WxWkwEMcgEKIZKe1PbB+uADoyf4ZS0qWl58QvKpXorHXdRumN0qITwDVB6b
ZjJ7tkFj/PEIco6o3QSlWJDybHjWPTArraGm9eJ8NSTxahRf2joocbUp2Kg5/XAgknAe7j1t
WPj3Bubp8KZoFRSUlQkCklN5YNBXKZt7Q4BFqjYNBoZkGFr61UyM8aSLPIq6PVownsAAvLfH
MA5IQqbhwhHI9EAU/aUpwT5OjD/4oC+zUDjB88U83rEAcMLPczEkmtnKo7Lun/ZXk1ezs2fn
ZxyJiThcR+1H3WB9NRssphKEyU+fzIjRBsWiv3exEfbD2B+ibcOPYHbHmTcBhR+7SXZl5iZp
7aPFBcQtYhrPIBcV9qKwUuQbalEWq3fBSxGOoi3nuhyzI8CR7QpvGxzpkms3uiW/rMRy3tIs
6pIGmFZupZfE14s+3yPu7BdOdP+rlRcHI1eOzRbaJ5JIqpggvDR2sOMShJw7pQT8teqqit3S
2sGFEB24yHCxOFnMNyvS19N0uXqk5U6T5Y7O1+xwpAWHla2CbSk4rJiCXOKYNV8tt5iFw1m4
GIXDUX5LGpAbc83UM2uCQQbYeQe7rx0Y+oo8+ULz8eBaMQWmjivM0X37XI+857Z7ptrMoXdn
4W1jx7xrAOM3CNxKtkpuy/5K1oMHXUl5+FC/yBA+Pd8scAyYe9jBHcf6QaXnQ7NidO13s8io
UinV2c+HCXlZD+42MS/exmeT9YY3zaTkaz5+bF+tsYpDmcFepWslzITMAU1WqU+lD0OX9pUL
wIS8ttxA1jxEEbCyixyCVvMcWH3vG1rqv9nfj+cjTLb4Ive8v4GacybTucBf+1OisALl2WOt
idL+2//N/s0W/9jrX04Wcjn2H9MG8bhKs17HX2LvFf9vpVJrNKq12n+LKvVmo1atNKPaf6vg
3pDWf8tV/hhwkv9wq9kql/tvM2KfKyKlXfnu+l6Rf/bv/yb/Hj94/uPRu7/99ILPVeR++vnZ
61dHuWBvf/+X2tH+/vN3z9kom6uXK1GOYwGwTas/3d9/8UPw5JvHD/b2vnlHss306pfJx0ku
KlfL1WpucJX77zEJC1e5t+DG8zBX+E3eT/qbXm6xni3Wi9NN7mS0oNfhYlb85pufzgfTyXoc
j3J8r02un3t2/Fy8kERkysGvbL6Ov3k1Hy5WywUNB5SmyWy5IqGERTM0/GrdX+SOF/PFIA6p
V5vlwf7+xcXF3ln/nFSu9XA5vlqXP14tNou983J/WP5tuf/va86+/+PZKv63ycb8RY94Xnzz
zdFiecWuO7nCsJj70cDPTvHxKMxF9dzT5WoyzdGK3vjmm7fxaLIWIQmBpfrEheDuNLFdQcpg
Mu+vrhD7ZbYO+YQQHK3sSaHFaHI6Ie5LFYTfEOPPLeMVtUbN5dDhCXHb3Gbc39CvmCrBljfH
xVvMRzxG6xwKzeLNQRqeNfyuFBA4o+ZmNEi5VbzpT+ZcG3sT0SfTZ1ykMyRsQnr6BkdJUYHf
0HyUgoKaI30AMkp5u3Vqxeu7aR03+J4TRF8bgJx2yqx0fTMk+4TtBTxiv6G1PF6RPrx2mOXh
4GIe6NSXH+IJivAnCL8ABM9pkiCQXSZGOIKKse8jKlus1qRyXeUG8TdEGCOEhaFliFLZ2Y6g
mC02cU5QQuVoPkw+UbZT+sBIyKGtCwywoReOnEsE8w2RIchoBVKZC9Gs1wL8u5evjnPHP37/
7penb1/k6Pmntz/+5dXzF89zz/6We/fyRe7ox5/+9vbVn1++y7388fXzF2+Pc09/eE6pP7x7
++rZz+9+pITg6TGVDPjD0x/+9s2Lv/709sXxce7Ht7lXb356/Yoqo9rfPv3h3asXx2Hu1Q9H
r39+/uqHP4c5qiD3w4/vcq9fvXn1jrK9+zHkRreLffPj97k3L94evaTXp89evX717m/c3vev
3v2Atr6nxp7mfnr69t2ro59fP31LfOvtTz8ev8ihW89fHR+9fvrqzYvnZWqdWsy9+MuLH959
c/zy6evXqV7++MsPL94C9EQXn70gGJ8+e/1CGvrhb1Tn2xdH79AbffqG+kWII/Beh7njn14c
vcLDi7++oL48ffu3UOs8fvE/fqZM9DH3/Ombp39+cZwr7MbIN8AIDcnRz29fvKFiOULD8c/P
jt+9evfzuxe5P//443PG8/GLt395dfTi+DD3+kdg/vvcz8cvQmrh3VNumKogTNHnH99+8+zn
41eMs1c/vHvx9u3PP7179eMPRRreXwgrBONTKvqckfvjD9xVQtCPb/+GSoEDxn2Y++XlC0qn
Ef7hG8bUUyDjmDB29M7PRm0TAt95fcz98OLPr1/9+cUPRy/w9UfU8sur4xdFGqpXx8hAVaLZ
X55Smz9zlzFEBJU8egQb8kDmXn2fe/r8L68AtmamoT9+pWTCKDt6+Y2gu/zN3h4tUuDh+BP3
R/SHWGKfF4Y9vuW3G0BWJcawh83BgOcodNcAFvl9djjCfj7ctM43p3vtIEd1bCabafzELXyP
9yXlm8fiupfjcwdSxW/9T3116HvyTY7Eztze1/6HSt8Q9/5jKketz+PT/vmU+O6SOe434own
3Lebu/7m/5Ubjj/KGfOD3Cmx0jiUNOwLHNOynUx9Op+A6XqJm8vNz+t4BdPKQS74G61OP7CR
R/If9z/Fz/rDj+dLqgj7QKYeYqX4lqz9z/EcZ8rip/O36/X3cTxKfkaBF7Pl5updPFtOt8A4
Ol9BzXrXHxAgm/4A+gKctgL9Th/eLFaAckZ/6O0pqfL06eaQMSVnMYTjx7O1WX7e0hw8JVAY
c/PzGUH2ir93SWaQkurWlNuArOKVIFkjor/TNMp+EhxTze9Ab0HIz8fng42+ggrexPNzetQh
MyWRlzp+NO7Pz+K1lvx5hROg7BN4PI5xsSCBws3SEhWr6uTIHGoTIH2HM8wSI/MptAekPZ3T
eq5qtAgmF32IZLS0YTGK8cCqhiz4w/50eoBy9G8eb9bD/pKkM+xxTzZX5Z9ovZtM47P4TX/e
PyMpIp7jaIxNLgQ/zye4C7E//etPNH/n8RDusqiP90LL3InNgqELed3Ux7V9PvTzfA83G5dP
XhlchMoAPekr8DePp1KYU0iz7IuD2YqnAnq0mB9Do4SXTrzeHDjEFFaSRICcL0mG3ayLueuc
KKJBshT1J3cT2uoWy/vUFuZISB8tZuJwm6rbVpGoGvA//dSfTIHhOyqfzEkaivszPG0i/l1N
NJKoTJu5EWStaNwul4zenwjPy42Sl3CNQvD+feGkstfpld6/L+b2ngQhTbAzDGqqMNh0qiiS
DnKF8qMilzKFeHhgIPipD2/leapU4buDk/fvN+/fr96/n/c+l3G071v63yXmeo8KlItePtMb
cnxXTHzlW7fiv88XBLxCXyTwU3lQ6TZgHKU8GzKaV+8DlAswa0S0u0I80+E4B6rnaLUieNrh
ulqcUx3x6P37cgbS2MYaj1LtEOeCYrLKfdKzZyJK2zpH8SlvFYHLj4l5kLwaw2OT68KtEdwj
1yVuhdoIipwHZ33fzwOvz7Dr8HdaTnMkti5Jcu1Pz+IBDpycnr6f+x9o9STy1LSZ7JkRgGrk
8vLTMr4hrRE3SRAfIBTMU+2DL3wP2fnf+pNvbO/6o9+IEx3NRq+Ju/8yGeGcCc9foyqkN1YC
4OrDZE7ABcXUloSeUQsuUM9BQLWUcgW1zvGuLzeQ28tFlUqRvnEU4MNvbhw4Y+EhxMxnMH4p
JwHkr/765oWI/asYXV8nFJpyuUw52YAPyAi994L/UAuRvLNeTOPbimkWKcMslohEjJGqiOGz
1gevHizdVKF+ULsl3HfKk5G6GtICUmhaIHTJozK88IiZjpMKpj6blwgYchXI6D1Rx/v3ElaG
6esmINRyB8uf4FkERL9/T6qV+YxKtALrQCLT5HiC65UgZBzjznS9bajIg5DLpTL/EF+AaEI5
55j6eNRf0Ww6i9+ybxJ7o1At2sUyw17qGiiIOIFTdlROdzlksUSxrhcmbeWxDxXPDU4KZpbj
PLeWWcWnq3g9zhgA+mgivmW4MRYMATHE3ijAaYlSdDaQLExq+rtFoRJaihN/eC6nHl0Mjavn
lHLCBEwThkUlrJPQ88+XbgLNSPYpFL+RebOGSfgtj0eB66Uk4mDvYr4RRN6Z1DChwBueTz5h
FlPSU1rhaCbzc6B5eaas1xkEKgE1PBFKS+Bc/Xpt6CdH3GbEmdbIxJ8kH9r/USRpayh3PdAv
P/VJ5ijICHxNeQm1eRIQdQ8uHnzKai07uvH6JPjX2eIfk+m0X16szvbhIbs/XZD8dhgFvbLt
H/4NCXOb+BUJCdiPKnh1TRA/5hQhcMvz9avXKP49BzNNg8C+Cb9MeM0eF4L9zWy5LxZqjpHj
Z78PtISqi8XqI0O9J+vKnogwvx96gPkjV3XMNRmoVlfKsz0YuTuFhJBZuaxUc5/pT1Shl2az
Tr9JUCKqZjk55BB38xHXdJPT/ZeiV7XOaPUiwdBirCEpsLV0KMPLYvhC5HPSVYgTwlfrWDhv
UWG+MWsMl+zPdQkRDIm5CZjjXAnh+D+LUhJA7KaVhaxwpnfEl8+nNIMBUbKLBfaR0mlqK/9i
yuI6PcJK9NX/V/4SIns1T9OYhVDoKqWvEGWRTF6p14mkIiEpKjtKlfwf5/Hq6pVp7BbU0wKX
hMCffGUm1oKV6kL7ZMOsf2M5J9Rn6EY3IT+yFtsLSeJZQ4WWro0WHonrF8rn4EZXAFMBVYTa
Pxm+3EHBFuUGyktsbONRViDKbDOw/hpT5RyM5qJ/RX/Y5EoaSf90w8Zd+sSt5Nakvca59Rjh
/InvEguVJnPrCc6uX8R+taPFPL9hPkATD+CynKZVMw6u4o2bB7RCbEvocn2TB3kxN6CqPmoH
buRWg4IiyCBZl2yS5wvegsW7mjuXrLR9wK1bulBj6rLZmxobF9Psx5QTiWIo2/U/v/u+/W7x
s9zaVxjF+PPz21eZNbpbbYrFMHKCiMIBhx4AI1uzt7fOeVJ1kKBgJQO38qt0wNjRxNskX5PH
Q45JQh+OrFs6cVS30osy/GqjwUrXZp+GqMrbK6Pyok9NsJ+1IpY9vWKgRuXcT0QM1P11HHtb
WGUWIa8usC01XMz2//R8cTGH+HBsNgNgkBlhH2dqh9OCK6sKQ2wFNeVGoAf0Qvq74f5aUevr
2xMxAVW2LOJSQOr5H2S4tARg29PxVz+gDS9kfPLdSxblIpUq+3GsomR/GW1/oVn8UXidX33/
zE/z7pMyGIcrBbEkoxPxKkxLM2/EPn/1l2+0M+7mRF+GBcs0ziyjyae38Wk4Gf1E/GFymdl5
yeP0soLJ7dh4GjNaxB06yH23neZOd+QOciL/J2vh53Pi1ZBkwdefgc2tC8VspGsDZwml23wP
MgqN7ig0cnM6V0gULG7Vo9wNKP4b/Xvz5vnzly/fvEkV82CA1xiNcyETAFBAUPSzD9koOzJ9
z6CJ7/lUN68njD/MdLB1EgA5FvKt5ME8YJEiDkMN5oa5xwRrbjLqit6TJ3nRo5NSLh/kTEe7
AX3dKeHgn+Lr3eIWbCXqXHGdqUEv5W5thEoDk17JM8W61P3kLiixt/NiziuVeC1ukSJX9JhU
6E9P8vcfCZj6YfvfORJvWZG0I3G+mibWJY87qCATPEZ9TyxPN6my6QTZPt0X/sJ2JrM1tVWY
Vi3elSIQsqvYtpFYs8fjwSq3T1VqC4mq0u2AC3ID1E9k/xPrInMVDaz4WZAkWSCplY9+R7Qd
qSrdwPJ8AO8ubiNBY6Tv/PnNO6PySBU2c7qW/QSKZVYU1uXfFpN5IYCVx66IsoXiKAAmU3Yk
yPXNJOcdf8vCswgh3vgkwL2UM0CG/EM7U5Q2cG6KJ+MDWWicwJFg6PzXSisM4I4CyofZCKXZ
7dzLLuLxY/OYLjq6vejIFR19EQM8jnXO9XXjyS2QBY6Yba/JG4W5cz5OcXIy0FsJez0uwmWx
v9sn7YkycDnS/TKH552s026I6N0fCn5NIlRKQPDXGjnMOud0Mm1mmVukgT/v7ngfmovYUv8I
JJxtI8FHgAHfYcHpb7L7sCb1wu8d/hln8023cpjbPLa1mGMFuU2pVEywba1H5ukOJkEVnGx6
Zk31MGkKyzTOBV6Om+0hcbFSgHy3hWKtwi/SOzV87hAbIamdKlsiI/9t2V/w0pAusc4o8oJX
q4zMhXIxa+8sZd++H1zK8NOZs3qctHqnS6xsCeagIh/AgM87XJSV1XYCm/rK9+G9DzIocltc
zCJOJq8xazUe8bEdor/e/LRAoUqG0YFD88C8PRzzNHZYFqXcck2PiPTszHAs1Zri35mn8gQH
PUgEdkuqErrHBxhUoW+XTcVxBTm0rexpik/srl8mV6nqviIcj0DjWxGTX06iXq7bzeXneWzn
JkDixe9Qp4v5x9p5KqOrKpH9RjMnyn+FTt8kDCKmhyk+Kq3I7A/cCq70Z+hOKG6eRXL3ITi7
R0dqEyxGrO5PNkRd8RoWobNFDkHoZL8WJkj2LuwLieXY0EVFcMHJMC6n14EsOWzHXtU/u0kl
yPl5OepDggG06xhelnDVnMwlsBR7BkwnH+GOS9rtSU/uXimq6ayfG6p0tLhV/tEFPwubmaqz
bPxdJmevTnSsAzums8BspjQsJ9jJ0rswdk5qDlFjCyZXo60J5OUE5W9pHK47Qux+/krPa9VO
q1SljS+u1EyjaphK16Nd9WKq2eRU8vvuTycmkEwxwTgg3cKN3zjRMSFKWvnxgZfJF6z8kkHh
XKKIFoPDjMpHqcpHTgx2ebLqloL2jc+0IxqVUR0ypTe/8BZgqj/44JP6EeZER3HA/PFWNnXc
UkObkfzWziS2/g8xvikYSROU9Wm7vvGUgdFktbkCKckWsLJscejwDagep7W9mi+c+5zL6jMe
dVGxdLpeDW+DypB8uh45CvnO+i0kVbktOVkrPeGv3oTWOxOzMu1uO2nJ39YjR2rZB1fzZ6EF
Nrs5A7CkOxjNYuQ5MNjMiaZSBbxvGRPIv7z8Hj3diWIfwi/Cotq+d1Qf4oDZtjIe+mpgVnu+
zyQfj9taz9fOt0XV/jvb292J9W4EhQTHO/Pw7O7e/DMkcisZM6psxRnYMZSFyEx3A11Ml2Gb
n6dlJ6EwFfbYNsKJyTExaZ7xXX3AfSsOb7vssMWnB2WHOZ44zavnW9Z4TCKzHSMB2BHA3GF2
65u/w0cLutRG7aQM9/42oGyl7trlYriKXowl3Ws2mjoLXPTnsfGY8TT1lLwVm91G0sYT8hQ8
v5JijCa6yHO2L0VoIhZNKYlrm1IzCMr/ZwjF9/OJ3ShkFEgRsXK9TBry/3kazx1rmarIREcs
O7Mrp1l17A1R/ZxE71IDz67pz1l8IuMU8NxwqK73E8T4DM/XKveGCDbw/SSeepbFXOGB/e6G
ydVFLYgipAq9++IR44q/JTX/XeCQhhzMAmwNTWZBoo600ciR4STF4bMMT7Kn7qT7Yu7z59xq
S963o9sT2f8Wi1O6wJYGCtnVQ6lFnkmCeCju+YbvSO2JmA85BH0gWqfK+ie2KOvkA++9aARL
eAyxsqBcLFnqcarQd7m9iHBdikgvT65ICswtlNmfTp39kYaA6KSce9EnqpvF5qQDn9njAvCp
mKsxnBMu2NWClA98Sp+aozrZeg7rg/lsj08shsPzFZxkdkhyt5gnvwYl3bocpgyaZzBmnj22
vMK3Z56l7ZlJfsbNEBq6Ob/0yVnvcCvbqeMj/icbZRRADB8b8jLtD9Pt22nC+SQGKeiM2t3O
uA2wbRYgIyJb5lev9qhXKmVnSpqUOE7nNgSJyXhCQIZRWmtOc967Z1hFZ1bl1hlVkZlU+Sdn
EFO64e+sscBXg3pyZg6a9nNnxBPnSLuN1im/dw7I35kI48vh9HwUb/N2X/JcwX9pHb9eLD6e
L3UfOswu/UXdgSFCDD7aDd/sk9GVt7j+CYtaZm9Y+vs9/WF7SBDuquCLusSnHfrmVC2NU4z7
is1hLpdsdn6lqsIkJhVf4MBBXt3q36VBetD7GJhyCgMdyjP7UezGyX8ku9vBiJxSULablApv
MZNbScfAsuTJMM8Tr/c9y8QkcQcnyyqpLzzNPRxmM7htVgYT3G0ygeo//zcQBRJTQzYcqTai
fKb4u7T2xMw+/To0ex/pjOOeJ8bgblSfemg+vRPFpw69p79XyjLsx8YI2F4l+Ka8lUQIGJxz
JAQ5lRWPduL+jdzV81pN6E41+M/kG6bWOab83IpKYsPWaT6/W1TipcbJSrIHMU8JS1tWN2Tj
kU06JmQ3Y5qKs8UtvzMQubYkrkyBS8FyYlG3C6CyM+JfvFO8ApPZwcgSU4Prv01NTb5liE5f
KujcQsdKs5aGPbreScc/rnAn7FcW8A1tZIkhpC7qIIJWKrctAMUMBn4rur6+gd250Vr8/FGm
fAQAEL/r3BpSi3dIXU1iOROVRdxQ1jEu+8Qywcvd2m0GpP2316uhSGxreHFv4nA8ORtPcRqM
jQb27ShhzFhPFxfTqwzL5Q9MghlOONxEMU0n3UQ5F/pwg9CHm729XX7nCrYrSrzud8BviMMg
17n2iFrAURJMBCE5N4eb4LEOI+rL2ZgRL8L3ZOM8yjlkMt+xyyfsCVjY5STij8ZmNPtBhfiM
qyiKb5FtMT49jRF6Bi2bUOYwQ6G+hKuZN98BhuJJ2gVCYD2Ecj8yESSIbUqEBfke5qIcn2zt
653AaLGKpHg02WxwtIkrS+BV/dbQoE23gX4EAqY90UMSxRMDAd4yJe0bfb8Yxza0j6uUmyFg
huKPr+V20bMj599PzV/3dN+dZ7ORKeNMD2cPvaJJf3Bzqkfe9vd3HNMpmu9YtO512MV6VOSy
DrpReT7hDe66JH4XC/vxDrn5Z360qhsLMTtA3HbeQylG52MCh+ze0OWzz0fWe84bdjmP9Auf
0bfzAUc+FnM4fEynNDXtTIL8jApt9QM+SGuFV20tLbBILoKCO+KH/bf7a7Z0Ge4Sx5MBOEZG
DVt5MrbobGZ3rsH4VlmJL7GLVmC4Qin3xfPAO2ODPVkDRcqjY7roy0jsHETN4vv6eSXfmYMP
O87AyOZiUhWUkh6+UzqtflcPGzlj4zcXZtSQaEFD6ZRdaJzbBGE3AHJlbnlBi+6E9xkqSYGP
D0b9z8ViRmOjMITMomwNbinyyzmxMEEQ+Ld9ipvG73wV/wV3YEzhO26qTjpr6TY+I9tb6Can
vqdUfAkxosCr33xB4vd8eGUWJZAx+IKZxBqAQNcz/uQIFmHt9E3CZtBKIQO9j317X639f5a0
1JL2Nad0yiUzm20cf8T2MYn3220pCSWy85RSO+EX8BWF4S+T+OJ2/vGJc7CnjgeCFn9BI7i4
tXjMOdLF10TTw3GBUZfF23gwKgdbFnEH8cOHuQcWgPsosUmkLRbTQd+4HLjAErcUkXa/HNHZ
jAT/5CRrss/RAdZNaWtbi9fOZ3nA6Sc/uog45Qj/dWUzjAM7sWg/3VKtlk1W+4XI/qqIzkJr
ldEqoGYR1f3J6PZx+KfG4g7Ewf5xVwnpx9aqbf7dSn/G5GFc9cy6lTw8nAqHknA++kMicXyh
GP5P8LTsoXUk8LsGdjdpp494yxj4uL73srBrXblLss/AwANv5LNxkLlsXZnLZ+R2ENx5FG61
4lLS/fZkuMV8tjhfx+wi3iWB4Q3ecCPxu7SrSUYhDvhkypxvtors7ycKmfuUuJC5QWmrkKL1
FeJW3d55T5AUFAg2Jl7Jra7bQRORa0e1fuMOvdg78ZHLUQ931C+85AtbkEJ+G5oS5rKbgZPa
l7UBTz+vAX5N90EUvAlpuKuNBFnyUS1TYWv76S5O9s9JUekpt7k9aFhyrBIM551M4e255rEW
Yjcua0JXSknN3VwQJJeltFjttFcDv82hHlH2nZ3ed7d2m1KWqjPpBnUfBLNL1Jn6RJ0FqcUs
CSLVnmpPvZsylkG3BG7VsT4fwOx+emVRrRJ+Rf7qYhPejq/0nLAMQ9wFM/1BDTGk+S7+GVi8
I63CvryTBoX0EpKlW+rUzfWHw8VqBKc6BCNVnWiyycO6mRNxHTrcfLHZNVcSYkmsolNyPlhu
s3tGpHhLck7Ix3vOCs3s4ZI5xTGM76sdObBtlCH0JakYAWwX8z1FikK8S3K9ena+wfrs2gsD
DmRHTI4v2xYDmF0CF3NZbiQv50gL53d24x4gAHiCAJLhrQAgwx/RPmKu92FTJyB+Ms9y9vYW
aDjn6+09u68CEm+3xfClQ7jf8eJihwePMVimgXtry9/fULRFWC9+N1GNGCSOX6zny9YW2h3o
RN4/ApNy0xIB8/N8tLgvMMj7RwAjbvcc69n63++CQbLsHL674blFUv9psTxfwmqr/M7njUt8
u40tcgYvwJIUePhQSvomaiz2fiPblDaejJIwbZ8IT0oDN4lWXZXS9g6tR/JKJaZ7d2kG0sst
FUjaESsurgXO+T0sL05P1/HmNaVv594sllmZ31FyaTv5JQfY3K5FLYvYF+K4Zroh5Je/VdFg
LG+V8WNN+cjSIVhKIZ+csisuxAkX9bhoHTPUCh1/wt1VltZW8ZQ3nbu5AkaMX971V0Rx8M5J
JZGgBSwqzFIJH4BE5Gup54F4tIAYTZJ7LJvAqMkrcFFIZHrf+cjAZco6yrJ0n2q0SKmZ6uhk
nRyTJEHfNgM04oFeK/fsfDCYJt1MgOWYKGOx/Gm1WPbPeCu4mNtKSro6FIyByx/QbTj+aZ7w
hbMzIRTCAo5BwYnmjYbP7rOFfo8t9Mauns3fvtxAlxQOVUfc2d2ERpgQC1HyDrcr1XIyg/yl
9QGv2AtstcBVouDXY4K3JOXGRJGUsJ4AInjnrUB2V+cq1p2dcu754pyIbk9sEHZPhoTxYEux
tkatHao1nw5T7poyb9mEtFp9V2esvUu4Iy6R5KC96NpkQ4Lc0IPzQlUnh4HQVvClZtyvojgl
JS6eaCbQvnXOdUcT2McJSifOzMJPOXcgDssHXh+98dDDFjtGQ7udGI93XKuzpLC/uYCUkkPS
UWG2oc0IDLPd5SS0KWA9+YmqDf024L2TFos99/y8dCKRH8e5807G6p9lniRDU6lA8VQ+SDee
UXZLHnPnG/1/u7z5bDh4OYN4+6DlZNRyNtA7PbLFmWvoIxx2ilT5AyKh7ajbNE0VIZqAGs+2
TGi2mhSOFnOJgg9A3PU5Byo+pALlB/eosM9MHdVl9sTeR7GzL6iTSvPV8vSX04SSg3BrUKSv
gYQSfpLLbPIejUmgfnpIh+13Va0ZB19SFz9IMb8ySUmTKi5EQq/vlz0byRK/PTtnIiMt1q82
ufMlZV3nZrEopq/kJAZuwdA4WLhxV85sYD9dndkmc78aRzK4DkV3wPvzXBBVKv8SuAC8X+ee
B/OvlHNTSqVuc+eDR2T+l73IvwrCTeK7JZe58yS4Q3RJ7I/931YqwZUxiYiNedsxZuQ5nFIs
b8sgdrf/HjJIat/fJmTs/OgW82L+Mb5armKO+bWYI/Xf4qvsjZJni8vdYEh9oZnl2vK75G5J
1u6bV3vm3OcbzIIdBeSGjUTEwdvrxNSlOuuVNBtTTN6rj4CoLzc0SDefJbZTdvRSq/dgtgSS
BAUX09P3qJJMNmHLvXJ6z30i1lKSQqWQEi80R4lNruLXE24r5WQurSfylXKNzK4kcYuSQcg1
Zm7FZqHS27ATVP6kK1rAsp5z4mYpSAIFhrmTE9xleq+oghnjjJp/Dy0nRMldpCx134+Sv0ji
9ipPURAJ0N72hIafdRGPb4Uscz54I2wvPTHfkiY4Diab5ZWgt+TcuUWXxSaK0sFDv6K7FoqM
eZhVjSoQd4Hjj3SiGhmjrfApWxFDjDOld6Vg6K4ADxUSRWvm9TimRi+ivH9HjpTkoESyyUEC
ydT65sGKwsIJzsLnVjFOxdi10wZw1SZ2raJU3+93asA/V8EuO4nLkbGRbK8TSC3+vqOq3r3o
nXN09wsWUuYgjQOh8+seUSoMLfN+EgFii3qeL8yAY3cpj9R6n8ptf1Lz3hX1YzRlkIjXRhTu
bFDJJedd7sjOWTgnw2XAKpMxXRnf3LTTibWf7nhK7s7zKQykluMoF0rPd4Fqcft3wqrFF6wE
+2wfyAeJaWNc85MQQqTyDggtzucjF9cExPp3mKhdcBFK2CKXKUm7O5nb7Y4HO7dZM0Inx2rp
+QTv5clUnKiDT+LLrH29tbUMS8c/1aCPhVH8n4yHMTUcz//j0GDbS2IBG1eZOEjcmrbtbCmT
OxGpLcHPdrA5XGZKvA3c7J9lexkA7jy69vu810zhLQy79YRU4fPBq9E649j6PY4e8BGC4+lk
xD0Q/yO5Lld6Egb96dQXYLY2gje3r0PbUKXEHAO+H1UvGU8Kb1vHVIbqMEEf4t3BrcTgaPJm
GxuTSzPO0pn86TBXw60wV8M0aNsd3F7iLHkTjzQs1uPN/8QxJkdr2UeITJzVhEughAXdMjk7
tHglPFvz1uGiJMlmRQRzn1xcsBbHA7NT4N424JTzkKuylWVuPS08uLdHf7YXtCD0dsp2BGCe
3IBsod1Syh91fPitXotG+iuMEDzZNuenp3/QKWKMyvlyGa9exxs5whWcPN37n//r/733v/4/
Pb0ldoqNVO97f+8f/+v/u/e//n8fKnud9+/3TLb+/CpZCfKhnh2Zn0/O5OJZvqPXpctl3cS8
V+bj+/flFyaDiRfsLunFncF8lYXXDRJ2Snzy0APdpCXzOajp+6Pi5+zKrqvhTVZ9RYXqfDVN
AoQboj7j1/rzrD+ZbhafTzfL4sHJr+/fr/Pvg16J8ux/fv9+YGqg8Z5OhpMNvI28qt6/P6H/
CyhHD7337z/zbcaft1LowaBIzQApLHk19fwSWVhdJ3EtAuehXkK+Oh9uzleprCw5JJPYEuoX
lYTFxdFi6idP5qRPcuy/X5JQHCaET+/qUBfi+x1bW9lCs5RClmNSotf7Xw3O5rj8+XOxcHI6
Hva+K35rTts6YJNeoq4aEyw/0fRwMT2fzbdbVyN4kijo/2d/Pvrx9Y9vPw/OqORiVeQ7qgms
olxSfVD8LvBuyAkKQfIlg0pKAZVJ5tomAM7kV4w2P/ce+QVBVglseCOVxEmyc2HgowWQGWys
ZaVK0RYjA5MpPZW9u4UCmoh6Pc2OrzJNs2ZNZsaMOZHIpx1PUnyy1+l++PSwk4ZxqtdwGIuj
Y51DpHomMCWTN+4nGcAcoeIPbUB7m3O8WE3+Aeve9O351J/pv4K1f0ulvvMico/jPkmLfq4H
11HYuPGyDEgeijcIzfBqE8+Sk+dRycso8QDjUVbWP/kZmY6ScwB0p/OQQSz6+dnd6e/ni026
0JP7F6kyGI8fP6asuCj+18J3D+itaCf/vFgqFpBBKvPqIkn7LMUyT15NeidvZr2TP5/1wD5p
EsvUYS5c/G4XHzZVfopXg/5mksLmtflfIPRB+45ge//+Rv5PQLjFee1EStBMxizKppSsjAki
yciQTSIZGXeRSEbWBJFktblFFNkzfJsQMvMlBjkzR3rMshgFz2I4oWxP4MV05I12Po8hPvk1
z0t+Hg9FouBiPu9RCcLJfvQpr9slwuoSQXW7XrbzOY0O9iG8nB8+UM4PlPPDB5+S2S/Gy7a/
T9n2Kdv+vt/u+TJB7kR5vzJF/8q0jIdE7oGX+9//nXL+O+X793/38swW80WiSiX1QvnRd0VL
114BXga9Ev/6r4QmTkwvjWbN3Foyryth9YaS/pUS/vVffSzMgSzcjZ4A6VviCPS7yLV8y7WY
JK+wsaZtlUZuWczLnzFluSino4Yi9xOZvLrYcSNRC0l+8dmEWPs1fyOcEBNZMRtgetGXz2XU
Zz+hXDwfeaW0EWUQngzmCcY+RWYSfJL8MrNskV723EqQXXZbjuR2fB/c+j1BL5k5fBLMhnKL
LDKzZRBAZr7E4KZ5RcJtgC0Ust8NP1UJ5MNu/ipRreWSYmh+8KDoszyyx0EtcTxVPQ3Wi5ns
mjvx2Li9wYYsJp0vcokkEEl0WXII1HGs1yzp6QgvSgFia7Lxk5o0Rp9bT37tPvV13xNfu097
XW+38vVPed3zhFfyqpobK0qeXhlRL14XdFx4jPhXJfTunrrfea7fcKPSuPzTajGM12s5hAgf
OdyIIvWLsTNNGbvAYKdrxgybFHG/E/EX/LkDHM9UOpCdSKk3saZJk1mjsiXL+MK07kpDdMhx
IDkmUE05qfQO9FLvc7VpMqtfv5rj8xsEGUnECDRfX7Jss+v7D3LrVPKT3EquV3ZrSNrTVf9M
YnWdOu+VQYxdFHjqwSQbjxJmu8T1SHybwWJJRVccK4w9iSZyq4H1KuK5jdyJu5O8ewfn6jIz
I+yhZd7ISRhEk5cspcZCqdYOfmoH3rs7za/mO//N3aFma9m6RA0y0vlACJDBJnaK4CmCsdOF
cpsk8DThDdIeW0huve4pe+x2zmAzIWitXBf4go/UVFCTJKaUQhJaOOw0KZlPNsHkuf/BTMcr
FFvPz2fLHA4QMKHJ8MajjNGdxp/i1PFZuChYCThh2r3ntVnp9nldIsqMp6cm5E1/uVwtlqsJ
1jKpNW0rvuvirW2zMBVyI/jwYWIif0no8wTDyMyRwae2gNnJRdL/brZSTaCvJK/5ki7cE8Bd
jOx+IH4BPP7M2h1VHlDfdpG9cSMKBqsgfcfZblAzbjZMkVf1fuR1O3f4og6MsztwN6i1e4HK
kzrJc6mk276PMnZI7u7dFsVkj6SyEMmZ24rE5nDAVnBAmoEJodwELm2dGdmV3m2W34Pa+u9G
bb23tWB9IVo9TrErKjC7H7PYwiDcEu84G3D8S9ewc2zOp+kABebfFokn67z3rHRMVp/Ka9L3
Yr4oCBgmIt09zrvAnk6ywE5CmAAe9f2ueZh1a+P9iKXxfxyxLP4fYnH/soil+bXWlx0SKO8f
eQJosu0MudKmpKV53MP7CuL4l4me90ND62uhgR3YIJyOzAWJiVbsVbj+FdW/Pik8eVTUa6rD
4Ntox+A7yfcW0nEG4qxa1B/2ZQqDflIqEI3tO03cFOKzLkjDv+0GdhgrdGQ3C3PbaZgZgCar
XkNl222J2ufG4E56wL8t+0EC3aGrzX+seC/GvnEf5O7gB2lu5Nr/XSTd/lok/XUob6eGugPl
W9yincEtSvV78Is9v5ZO74sjC/2BYxTdU3u8H99B0C9s+9wyRjtmlylZ7k/TPCuqZCiaNr/E
d0916X6o4wp+H9a+mlJkznvrVtgtiFuuMqnaK3ybcuVCPHtXzX8Fao6s5rRnSu7Zi+vrxSw9
LmsoTBe+4JTv/n7ujYlmzHY6E1+c1KN1wrSzbblz5sKdvRRA7roWPJe2pd9smYT5Kpqvaw3+
T7eXWstx5uXz/4QBNfOW+v9d7ae3hJzzyeFrmjrva9z838FcaYf3Sa4Ci6Unv+10A8Kp6jTV
lIfj/urpxtW3RwrRDj/WW5Q9vnvpNpvhP20H9NrxzwciyRCMj8hKb2co6x3w3BEEEQ2lSHJb
KUrN0D9UJ7rfKpvG2otLUEJ/uhtv9xEO/2tj5n6Wzi/FTP2rYqZUzUorZZpd/wgc3c8K9WVz
rrF7zn0VPO2iob3qP4uhry047YL0q8lNunP41bfRBaTszXLPryfthfyV5S32VppO2afFnK83
G2r/OXvXPl7+TxO87pbE/8M2o/+PkdBs7Aq+2jUroIFiOhgEqaPkX2KcYSag7WybZKIsk4zH
TxNE/RW56e+XVhRtx+wKeAfixF/wa2BPmtvGX/W/EP7uJ9Mo/n42fpJ3oPD8a2DPNraNwNp/
IQTeb4/W2OnYhfQO7E2+BvakpW3U1f8Loe5+sqKZuzuD3tqJmwh3+/tn7flyG22N/0Jou9/e
nUXb4E60fZWlghq631bffxbaOl+EtmV/nr0Zlto/FKfg3OfPue10RiWMKKkNmuwybVfmC80k
APauQeYwghJ5adZffYxHW1HCdmPTx+ofCdlt9GfQn8LyA3bJNk1piAf2ot/ag71fne0ddQ76
w49nKw4s0k0N231RePcUoua251Cnd/d82bHX9Z8yz6LKl0y0I/EauY1ChpTla3AoNJUhzFay
eFTtTtzV/hDckRaQuz/yqND4iyb+ZhyE6fZ+71bc14XTiwyXAWb1d4KZLd1uJX3dS9XSCJCr
1BazWX+LeRCApcBeiuz/y7qZTaoIExUmb2dLN62y+vVNmHP2jhDXds/s5b/pMnOTsxJyVLG5
7KZSDUT7bF/oVrJLYuCi+4+zC/ibhTkNAeIAyHVziciHYi7xcVHc5Zmyvy8lj+PZBIvDPGmC
Cg5PcnwSefX+/ab36NtdjihCzZO1QpMYBmfJsGgKPeDFMLOjXv+yaguiWoO0OeqajEuptMNJ
5tavFqZcN7cFVXYRHsz7bW5bGH9nTXc5Ud/cMq8QaNUa07J3+xO2Ov+f4D1ZDZEQ22rPp5vJ
Ehfznm8QvjjHN0awmSdbBNIpBSiyLyYPIwnLxu4y69xBIXugOA7n8nw99i8pP9zmtfiXMGVu
F8ouk0aad0c6krcuSN9FsjfCcXdhlhGfuk39exafiMcu5qP+6kpsb8AsmjsgNph1m3pGy7ua
fBYP+4gUOl+/+p6YxyuwluMNjcJMsR7mLmK5JJmUSb5BJ3swqS6O4HsQ5IT1DbRma+JlFlBg
66lEl+cL13dVxq3n1pP5MLa3gNELFeRLdLjPO6TTwhZ5Zu875gwL2NvbsTOZMzeWrM/Z20eo
5rfFZF4IdnE8U4iBwCpuqMYmqOVeyEbqvqUu0x9b1W390QLpCXprfvxLkx2PFQeUZYI7yCXp
jGMHDs43OaAiHvEdEriZTeKA9/1Cd/ZvC18+qozx9J7FX/x9vtguXr1HcTBcAfViBba7K5y0
rsl3IhT/NGC/t3JLC7dRjg9PLL3JAmML3N8LEdoIQsSIsQgsBcX7QmgnxleH0Rdr7XDeEyrE
Ev5qw+fhSmIUJ6fWSaY24P9Lb5pl/bt1YfC798WcyBT8injBv/9I3GSbCu7CmOMJq9VileDB
nJJgwneuoPhnGLGr8C5OfPfqYiDNHFda3e/LNxkmKn7nAN4y+Dn23DSXgCh7QL2Udi8u/k+M
5rb8qsqMkRHhVsX1P6lkQHGHnvu1XQqyzRt3ORTs76dW2aQs6sb8TgeExDWqHHUs7ZMgZ0n+
q/ty2mjzg+ltntjcRT8WAPwK3i4uXnPYUK8uRCvKSj9dLDZZ6VqPT7NeNelkrSWdDCtZn8Oz
5vx4Fv85vhFe1Lr/ONeI3+MmkD6znzIpV8XgPwyyWCxHCeov03ahnmdQqKQ2321U7mzHdDeA
u2hwKDm+6LiGNaJKWZmHVFGG7TRyaZThd/uaAY3+5OiKQ6o/LzTJnxKUtGslc9CnLwciOPgW
oc1imYWUW9fnu2sdLDabxSyz4iRnNzbMTPIZZ5LPbcfvCCUFM/1Dh7b7+XNkjGsmFX75uDpI
0taq2xFw+rsQYBhd6IjkPxsBDpIdCPjyXhrmH7oJ85/dSwfJVi+/2X5yy6nP9e8tjvAvPWNs
+J+JT564ylTW5/RBGC2ild0kq/QYzpMkc/GXfBzyv23ZRy0+C1DZVQdw7SaqX6GXfxfo6bwp
4D0Gegvw6etW0sDL5bK7gbfk51d4X+C9vCngPb5+C/DfU67bgEcttwFvOYRf4X2B9/J6wGeH
iuACX+qQa6c4wgDjtiXxbv+vIgbHr3RXwZNEbbi3/2zn2q1Av/9BYuTt4iGjKOOUeNqyx1cj
27hz/87+Iu79SeZqaFB/IuOCEAlx8sYxptRdy4wFTbSLOLN3fmaWcXLdxOVTW/Dz/O3mIohq
sX82qCJx9nOZXcmqorZVhf2K40V31IZ/FuAhoSleZYBtUalDFKcclaMw0ebuCvb3XcZurnpH
S5Rtl23lTvOQ7dQKM/z39OmWbtwJ3S5xOT141X9q8GwfcWf9ji7u6l7lPkPmhiurp9u9zJwP
xKUSt7v7/+49Hx7sRIKr/lZRY5el7UuH/1aE3KET3QPO0d0qEf5lIlLIQT217gKibIiH//7u
NlPe+nc3e4fnWNZO0D1AuVNF1+ZFRogT4kFpe0l0Hk1muO+XO/pylSBjddo1YVK+PZzf1yNu
7lAIIC2dGGmJl0Ft+97iV1pMZPlLo5B6B5smYe63MPcxROhed9NPrjBhmSg3yT1mWOw1P5NS
yacclMImPMCdePSgzIRavm0GrfwZxM3+Js3+Rs2iatvsb8lm8Q8kjTwnv/VUwijyfZqTeTqA
05b4AnDFszMVto1hwLG+SSk6zH1Md/7jNhQGEsbAxx6AeaDAcOD3bSrSxndrlZkgo6e7Qd7C
GBaKTKylMfdAZbEdwGqzXwhsgn9qS9vCoRmFJ1g9t6H0GVH64tZj9grUCrLNiDvLru9f9tPt
4tZNJj3+ni5ROemSVvAlXdIiu8omgZQ5mdbstOJimj/hX7YuSJVYtVE2QV7GU+zUgxzt2bz+
Rq+eXztWtWZXhsk8tzqfi/4U+7Gyb4928MXq4dE4Hn5koBwA/E13tJJrEVzd01Ge7IpBg2rA
KCZz+orV45yAKFlMAZecFSIbZvu4PxUfj90nGm17vqKWCYQHaWL0kxSZMbL3iP8CgcsOR1br
W+FbLBK6uaz8u8h1Cyvb/U/EKX/BAgpcE8qzyXz3OCoNFbcWKxvt6gtckm0rQXgnjl7Aw9O1
moUWypLYzfnhfHQWk9i3mJ+pv5cYEWwBcJ2LOE8UMloYLyG+Snfh+fnxra3a2JPtKOkWM3ec
h71/dHUMnUB7Pvfj0zNFQwHKLT7Fq2/SsNlJkjFHvgKxmhmYOFfrjYJ8T/dFRK3ClnD4B94y
p3fa7a3iKV8mfr6R+z4Nk1z/gdfNqTvlLHXKPXgYmLPtLtfreL1+N+6nvZEfZ2T9Mw/RKiP3
k4zc/0NDtvn53gc2I++5L+ZEQpvcQ8yL4GF/tjwMQqIgfptu8PJEXs7ohe9yCOQdYc8OA7fi
jDez6Yv50FCOWTx03JmYTPRDi5xQWyymPhmMhAJD+rOHhVAAS+fgnocGyKKlM71TINfPCVXn
pgjeaa5CxIXZ69xkTv0j/PZXq/5V2VCRfuTFGFdIwDMQK+wvi9VonZudr7HG5E5O9A6ueNTr
OdzA11TrQQhPuZB1nbhfwBS7x2V2psz5PKsU3773bc+/Pmq5dY3gVsGSu41su9aSuxJIiCtJ
U8vtq+N4KZAO/8B4czbghFXXmlvZA1lZoSAnYUedbbt8prUYycMaOXyATR+2BUAPLHGWtgWT
S6g5STJTsyzX+7PDzr1r3jq1ktRaZ76+qrPFq6mY1EdjnmJeoJTEvcTmpncRCX48LbApjdS6
vchhzzbi7vNNHOnT78HJib15FCTQ6wXFTN04sbrTavWTSpyeCWIcv3qO30e0SMoOi8ci2Ny8
W7/dEqzRSa0q637nIT4AdWJX4Hx+wVfPM2+FTigDk1EgQCeaZLtZRtn7nY6QPicqFExtV2k/
JapObhrx667ReHa+2SzmycFgCxD+LhY41IDHp1wycSX0OJayt9gb+kGiE6aS7YlpKysv5sPp
ZPhRRkQKHGZkSw7CeBWf0mL13/uf+sfD1WS5OTgMtmSkXYWZbAOvv1sjeTvEv2NME0BljJ+t
PDXZveRd4ykhkbDAhXKZ94QQej7amkYbsex6X3Pf6Qw+SF1MRJLdO3zYYti5rt5fru/rE66g
5/CXvo/ZVJVzlx6fxZvj8wEXLGTxmEQRZTDsco87b67iTS6+pIXSv2XRzHjbBi402ljsvEB+
WtH5giOX/MNibr+4ygab9HFknTCKYtaVFcJwMT8C7dr1e/5RO0S13MJs8DVNkgaqIEzeBs90
QAUyKSAZOIwBPF9NU5NWw2jdOWU1awLuIPZaCJL5MAcpCzWYTDeXXAcGOol8A8lQbjRNZedd
UuT/MJj2bStyc/VWGHaLYTdDNFGkuO9pdZNNaaWEyZz0D5yqKZAe159fiQWTlH+IeCTrLePh
hC8YU/OvQ/EpVXVk8+oYJy98345Qr2B5B5ATQg0XeuAG4w65Jd66j9z78AW3kXuQpV2+nTUA
YxaXRQsEDztMiCJJsBNjoJ31yTPl+suzBlSQZkqz9dlTIsfcLffGz6QOZPNFSCq56yCG1Okf
JOVfnh6tWXT7RYEFCfIxrMCyMwfy9hDp4dl0hDoPipDmlte+rcwNwNSbR+Zz6uuO6SFDl+AI
07i/Mgj/53GsAqgiatxf8yQEXawLnonNZPCvmDdpp5PVesNJd6F9vpjHwR+q8L+J5+esosI9
ZQA/kD9Y0/cUvNNVvB4/nU4LY9IfWVX4kZ3JiDNCc7RuNMqxoEfm17khqbBnpEoYXZlrkYti
Cnb+cSL6lko6ll6mUp8LxgWO5ITNyuHR0HiyESvaHFKDyABERG/j03i1ctxxrV1MCxQ61Ew9
t9GhokChINV9aInObpwVeFnrVg43j/1qzQ7SplTaNVshtbMHnlfsZNMjVppQKCXbw4eS/55c
Nsm6RWRSGcavpZXivmxeTi8D2/WZOk93H2E2mBkTZnLjxxgwu6k29nGy1fxmfTLumVVbZa7d
RygBAi5wyVqVTnetPExbZgX15Rv/33awhq0s96gp7Tp6242R3nImrOet1I9j0zCHOu8zuRh6
a7qY6ZgUuIz0aqeJwgvuXgiOJxvJQfqLe/aNIxwpaXNnJSaT1mNfrdyhk8wjxHdWnt5jYcxr
yjMJQfK6bZau01DLWiESm2P627qr5PCXinQZU6GNzypytoi26dAu9wI0jZY/EFbTVAa4GaxW
uLZHOXd2Z0aSKEr9YV1haQEL5S6ye2MgCN1jEg0ofr/+2yXKnzz9ASTulFfQ9rBySc1pAFhf
TDbDcWHBS+u6vLncHJ2vIMu+6w+yVoRhfx3ncNjq3WQW40xacGC/jeLT/vl0c5DgLA64pIrk
0m1NSZZkuJZrqpBiWinXAAda/2wdfDEUKLQTAvp439bfEAl8cetcaFfr+HhH62az+8UnUIHs
bcueN5uJoLURDfFBQEdSRg/vD3z9LFd4EBetCZE4/mhxUY4/xf4tveJ0zSbm9WL6iV4gblst
KZOalJf2B1ZyWPc/xSLTHS0WHydQ6P0CwU7hLGNeJMjEnxsqYmVMzjXxhsWI1Vh/IbkHf8ya
SH8IW8EO6HMR9gMryuUKm67plj2ydpjbPIEMs9nb2ynIWWuUs0Nte0ZJc0PZxXq3+Bv9e/Pm
+fOXL9+8MXaqskFb0Yl57eT2glZEvdcu3Cn3ocDmHt6NvMmdmgxeBe6QXhrY8mbxejHsTzmb
uSArWU8SiPtaLL1m0x4GqQoTk1/JiJY/yEPOnJYklJQpx6uteFf224MBJZ2jHKHJyO2SDu9s
xSJGMFxG0J6jMWYLpUXNSmKX++vWttO8K3QgQgaE8C+BYFcIpZtdTIhXisTifJZkPt5S8l+J
3WDSEmjGTY/Pe2ai1nqdMHbT5qLg3Thexbqhi86fwb1C+Y0BXpkY2NVjr1F6vVUNJdTdamSm
moijnVR6LKvz3qtJi3qy50pCP2kxblVQANk9Je8XkErygTVW98/SR5fO0tbo/lngAfHVqIzl
S6IelgTEFCCo0cSn0+lB7nraH8T0N6C3INTgSfLqejshEWC6HFPOzYQ4YW6xIj0suAn92t5M
1muaal6NmuLX+s7iT1zpPkmc9rX6As047I/Z1CexEPF/Uu38uCJA5muvHU3Z3Y6pEE2BqhYc
Egzm6dyCWnWLfaqpY1ir+z6SNGV3U+t4RX1aS7bc8ny1XKxj6yEoxAdnhUB3ng8zmYEIbl+i
rPwHyhbrePrL7VGM0hM8Ja/+xKhLhLvVendU6FoMA3pGZMcwIFlRMRVsqaqUCRudbNKjOmkq
8qPmT9q2ZqBuf5rsYiTU4G74GB4c4fdYml/pyaxXZiLyJimV0IBX3dwsIQXNwEY9YVgBT8pC
KC7YiEe59DW/N450GNv/5FAlurINWK+sQdfcaEpMl/UuZXGrR2lN0fGouxRFbSlbUE8YI8y/
TA0sycaCO9vQjHKbxhc0YLjVnQ1oxi+p27CnnXXLd4Mec0NyqgXNX14vVps71Uf8lmVZDjps
cMRAK7hjdYbkcLWMF6emAK1/bPMVj7CUyXeHlOaKpkW0LZPmnTX8oaJeigkVdvrcpFm7x+ic
yJU5c7bnF+8xMo9xYGVqz6kWhAx22RFu/sitIwFtTfPg/PT0j94tIkHsfKkt/tSfx1M7LGZ5
ANenBUJRu2ttuG0AF0tf5UqOHY+HZY5OK65lRJzf3qNQ09HlJjXhzb/YLi8KPlj3jvBZu47L
cBPD8cedTQxxIIFXoN/dyM2OKTNd9Ec6OEqq/qQZclJig0uS7CTRHEY1eeJrJneNL/5tWxvm
0k2I+N2U2s1rLVtApFHj95c+vkJwLQkU3w0wuz38W+ZKJKvdeuI7zmgzOAzCZXE7v3GiyGoc
//y6bmvzk5dPaXYZxntZTd6XurP7j393UTn++aQHJ5l5zOHDC59uOUe9gxhdk7upPqPJT7Jb
SUvHLce9b2ky49R2ypTiz4wtHo6d7cTkgGMwDEYepepQIDl7LLas9Vs4H4IeFbcGAaiv590d
fx95ZRu1XHOiSvYqAz7hR8bbsMGtNQu+uJ7gMBdfLie0fHW/X03CXJT77/15rlqptXNR9aBS
of9zP787OoQ/9ri7H6S28IS0QeOHmUu4YP5Lbd+iP2QbvmliYob47kduMLwp5LshpWdRcvbc
Nms80qUae8LT0mLCDizfNoa769ZF4l61O7rfonLFkUdN/nhsfU2cd1Gpzuw894ebnJwuEIhh
jMBuxyCO59YZxHn7+O34c82bU7vnEWFKHPRT+No1NY7o4Tje0hGyN44uNz+vxUH99ux/qNB2
zMj7A0/x8KkmaiVW36r8Y9JZc5NRN8gTi8uz0sT+VE/yHNT9eDmdbBBUnM+QbC4WufVCLDRm
jSyKs8GEJM3F+WoYW59XOCLmJhtulkT+RKP7I25u8oma+UY7Hkst4lOKfVnv2COV5zg9TD7r
JP8WXuKMvkmPMhk4L9bOz29fG/cIw6gca1lNzibz/vQnCXBtGdl0MexzIDzHnW29cpD0/9/e
07a3bSN5X6+/glWztdRIsiQ7TuLE7ubNrXfrJBc71+1ZTh5Kgiw2FKklqdhu1v/9ZgbvICjJ
SrK9ex5zt45NAoN5w2AwAAYXDP4P8wR0tcCJ43ExYEFMDSrbZMDXBuhegw5bY+Hdmk/7Q5hk
wrTot3QeJIwH3nLFLx0Lo37I2xSHQ6+gxjDkbJLMM6cmYkuR3JjCIxfHmqe1Zqf6ehpuD1wr
QUYB418UFpSMo20pku2SIbTvJ8xFYiKLN8oB+86Yq8my39qOlyM0P49FXUNs4pgY8SwBJAFj
Yh1PuRCEeT6fYl8U5bl4Njc3L3c3cbTTP9rtNm5MmQ2J2phDabX2g9rlbh8L6B9YtARwc5OC
ndlmPgkz5gd+AGPwQXqJjSQMemH2wWim3+cA+gRglSa9bUzD4eY8iS5LZHiKuxCXU/AZmNNC
LOKEIn3k7Usiz8xDvtcNehEiZ0lEqYuCZPq3PqV50NBn8Mzzhpu1Zu281mgC9lI55cEqvw5r
QfOTSx3CrkKkXjyhKWiMjrItQLjb+dIYm/h61OPmPL3fMNvnMvpC1N9fnXhK2hbyDfcSlG7e
HAhwgzOUxEs36gqlRkkHyxvqS8b7EDfH4uLJLM3zCFMpSysu7HIwxzAot+kDTELBsnYALolS
FPCOhT3/+iYcF+oLnlxAuQTQ1MeNXLEI6HgF4zLg/Dz6aNhdpUWWq2EuuKb5szjNyxXVcXOo
bDgMmt11p00aBzB7XN2BSR8WCANzA5IVoiVHrWu44qj8F4xU4rpnisdgwwBTfozMladV+Cjc
GhiQw+GH+cyYo1CAEXxULPGUPlYGxXhd0RkUsnps069MDtbatUYDKWojjd79JMfHR0dH1Flw
W0NdFMdjz8YMUWOAgW/AljqDxqkp5WcH53gBe2bl3l/C6eaSQMgjGHUD6K7C/NCxXtXOooi0
EOuzdB6PUHTUrwYaevmQnZTNmzz3COUnlrAMWPIkge8H4HJViSbL8/XlclniM4AjrAxGixaa
QoBvk4hOy6ZvTw4e1M8FnoBl3dqKAeQIWIsl8Ob4OBijS1nBftH6Crw/CKGWdk0l4GrOs+ms
wNSY0xnmMqjoGS+w0IkoUxk0xkLEpJnFgfrMkoslhE0UwrflCJ6C5RfpjCS3SaXcjiKH1EXN
4hi0frv9fmXDy4GRynnrKx6axlg3bdncu/YMUl7Spy2MX0FJjtzAuC1YprvhwcrtEVrc9Juz
JiBrLNb7F5byVWm/aunm+m9r9xIjhBbYcj8y9jHK+VrAl5VHGKtFyyf5z6AGq8uEogeOKJRy
NQXGeqzOLRm4/Mdt2ObMddEQ4PpdlgT83JfsNoOOlq00IrzuTREjkQqCD4n6ffX2cjzG8DaL
AWvDwXyS52xKbp4+h4GfRB6F2uMfwfwHeNEmILfXr3XbnX7tx321LVwWAwtslOphqXIhdCET
FtOH/1RvaRV2v0Y6suxIR40MzONNUcdtAHf8EKQ5L8b/tlobgW+OR9oB0SVtGidAZLNWZQts
DF7sHHRmnyWteQ4ty7/tYsN0dkVJYvefyd/oqMgIMTgAr/c3hluXaWMavjdyuxirvTICKLDS
QO3GZvMBasc+b6BIfzo6kWEhXlEVcEjJi6fzKB4truwUs5mcDvP9SVHMoG8M4hR37oUXbZj8
goaO2mw03yzYcLIJSgM8xbJ2ddEH0mxf973Hm/qtob8nInm10v+bb+TmV61MocMdgiHMMe2O
vWuaTvLbb3bdNy0DAgdNuyT4aTr/LuzE2YUtyDc2XbfRSpykaArmDaPPJiO6w8Dtqpv+/oVs
NllGtjwq8BiWETAP7IuifCZJjI6mUUJTeKI5Lg2UXG3Nce9m/tjdhyI3iuQLtnFWpURwYJ3m
Z2fWyFrKkUAsMvG02CxYDONHvZxNQnLGql3FJc+YtQKnbq6yWq/0DpzC5ay1BaeaekPJTA6s
Qjem5Dk5aD3geXEwJJDNY5bv4ofOZQeeoEW/3D/Y/c/OJX/kxwfi4/0D+Njt8s+B+FeWeiBA
HBzwUvyzKqWLG+s2wpkAHwI8Ce5SQNdxhlF5RkIzUf056DaDQQ/+2+LvxCXIwOK59Fk8CjvA
S5fnFN3DHedPijry355ndgFG5/JBx1FMXL70bVofdB1nzgDyorNoJXDQW4zMwmbr2Mb30Eb3
oBE8fhzsNIJ/BXUAie+2DtzF3msLxc9EarD1JRDneHd7hLiBuUHN1kJqrFVENwmU11u18onN
7UM4xnnqVQ5R4zp+brHAVqNh8Bj09fL+gXP7+7yKL8NFcwKqVfv+O4q8GItGOMA/qvmtIXSn
R6W9CeRlozcL/mWTUoA4WZrRkE/TP6I4Do8ry+sAWqYilRQ2oz9pS4ARLUOQEVsGTSCdOUir
aKmoVoHrL26xdVCsAGJjRutR+CInoBhFhSF6GGKYaJTC700OHT/gHnbGLzGmKxWbtBlYVOGz
k1d/17Q6TKJ5kCujIruq0MhxnoqZBmaP+sj+8WrwOxuii8w9YVA4BH18lYPrw7+VZ5BDzLTm
38S4uSnmRi8uh4wvzZPRDTC33ZQakPOlfsKvqGb+3Sfl5DAaAaIkooPaQFAbZ6bo6NtM6TVb
3abcHYtv279mMA+o2xpFH3Dayeq2JJ0dB2sLE8Z3lSVRLEUKDLB8Ph/iUfvxPDYlbOkYTUL/
vwgWe+LXFqwcS/k2QnkCmgT5Bqa8mDxkmXC1Dnzdzuozkt4eCzZI7Dt6lk5naYK59Y08dobY
bbHgk7CCFqjaORvOQcWv2q+z6CO0dM6OwgRmrVmbJZh4X72u12DIw/l9GP/j9bMUZhnD0s3T
hig0SvwsI8tPa38VpLXT7HwTy21SxORRt3YmNlYfimRSdaN6hGnLxyGofDvJD+lgJvLFaZrE
FiVR8WtEN6JPdD+wC9LWLSpNac6sZDsWMI5RvdMMOjs72x5K8YrKFQgVq4ZEcAvqzOZFC/o2
C6c3IhxpfkW1j6mygxAAJvKJbED5stcBTwd8aHBl0RXfdlfUZKUL08ApHZOubrn8OMbZg+fD
0Owz8rENo/lFO44lC4KPra7rDBF+TPgA7UPFTbaF7/7tdtzndZjGfGmfD247/Zqd3j/GSAqj
RPW8G3d6qrtunz9Mqrq8gZLd9Ttd2eeDCmryw5uRw2OeqBrU6BqkHCsI1QSZWHGKosqycnZm
VsFUz/ab8GMYxXR3dSml/9ewP5Yn87n256tt3bQyf3z19Gxp8mIUFX9nVzfZPe3bGSlct3xO
SRGMLF1iRy5rf2BXOOOt3Jbb3dqlDXVFFrdeJDJ4qj93nM+YCOXwRfD6mV3u/n23XJQHtaMa
Fs/TKd19UeDmvNyxQYDiECoBL3j2swg6ycj4VS+d7fDtYQw4l/ryTX4qvaEQnkzbZYPbcVWf
KFGctI+R2jopH99G5B5nwwsaUlxKvyxxvq1DJSKbXWP7kK+bfTbZ/CMIEU1d/HQ+4PfMC5gq
MCD+1oTRtXPtvEhnr7N0Fp7TRtNGUHrlTDi+lYAefbNqzh5aK6FT7+XcPTqH7lo5fESWTP9p
BjsTripvBrh5jjSdttBK22qkUKOctedVyXsNkVrtUa2q1Koq9R65cDzxIFWVx+KV6JzcfPZ0
OeWL2fYqfnvKihB7NF4NKru3e2yb6i068SlzHsqc7w2JrRMBdi6q0pBtbabtKfTJu7lA2wkh
J5HY2tx/B8o5icaFoiyM8fdFoUTy/63MgcuBXFda+1Iv0xSu2Z2kSajqStN0DhzGW11kTzIT
EqbJEX5/BZ9LmYqNFRytSa7Vq8xuaSRbsuvcN/XSTftNaQA0t/nnpcTNaWv7AvLmxf8F6kbs
pvSN0jmqCc90r22hTeLzQWyaQk2iTwEBL9VdOTZWpv3yN75lyfRW/t1c842S/I9mzzM2rjKm
FGkaYzZf6tzlMYV/5dGyz3TvJH+0EbcOx9nWpVRQ82ex0fn3mxUfN2csm4b+UZqXeI0F3KF6
IX/soUqPp9WMemTXwMQBtM3k7ZtDNYurV1x5Yi9JCQGrs0d4hAXHViftrrcYlDKHgy+mk8+h
WxZsaRdfxNIRgVhF51YVPyahFshnmNkZuMtyzIBUpEkVIW9Uwa/jts3SGW2YNnJlsOw1viSS
Nat4QenQfyU1NNiytygNtsjb4eQnluunTgpnuQiLURyjhYWHaUuZQ5D6pq58mlUkD6Ha3vnF
tdlnvh3azRP8lRLc1V6mBhG18p6VP9fGqZEXE6R5Moie/5lqLNLsSZU8L2Vl86l7eL6+fnc7
rp3laeTsNH/nepMNptZbS6854DV0mlf8c/XZTsrmzbXHk+z9X9P2lcYiDIB93khUFf+o8oE+
193DaFIVNbgwubJbUgpLfeYIugJ+b8GIrIzfjTnrCzKJzItiey4uQOu+aiY4qhjoxec17CIl
MFqSSUolOpK2zUbzW+NPpYvG2ZYnSTS1TrTwXfxxNOIBBALdNIBU+N9NfgeJdMPN4IGEUrq2
xMT0R3l3DOYGEdeZfPXuLxMrH0OPHU5O+AVftRrlGzgA1fzA2IxC/3gvIc6sLyaMu3k51eB3
goXDYh7G8ZVKCsBzHxLIaMr4MjIP9pi6wRu9YeB85Vh4776dOwJ1ERrkja6UA450kLOkOkml
YlytYaYbwe1TdC2pStTU47dNF+KaP5vr3hOSeHTDZKKTPA6pEV+ccpoQVwg5K2SV2ihVvKg1
e52ONfBYVzGpguXL4G7MGImRdAbwXiejN8o8IeY7cX+4GfEu6WxB9x45mW1Mea+JOm+OJCkT
j8mdj+4wZzd+ANDzL9c4D8LU9SjCPrTb7SDCo8wDOj8dFvzAMvyfrpn+GIWYgkJlYg25B4KX
+4ZBgpkVaCPh7KqFy4cB3iFVMtw0S//viF1YJGBCEC6TwL7+9x16MvgVD24Y97veMc7jGGGj
58oOrnydj4bBc+yWt+Pzfah2PeMSoFUu+eF15b17VZD4vT++aR6hxvege6ILCnjZ06uIH3ii
FrwJvl09MK4g/vLrnHQWA0fIiO6HPY8S9pUWVK2WJhisFaMPDSch/0RrAR0anw4T8LNRVfCk
WsGHbRyiWAjjUighNYMRM8qNQScvwmyUt4PDcfAHy9ImDWe0lg89HOQ95eudMEpjxxgZrbPs
8Dlv+rm+cguLz/GEILpyCkukZuOPNIWvG8E0Hc1jdUtX6LAzyKcpTA9g+MRcLXx3jUj9T7lr
KOtOmkdYZTOP/lCAOMWyrLh6Xtz2Ju8iROQ5Gvo6ARqJaWVTvBow5Cs5NWz0SO0DQifEAHCM
zVG9XymvOb/SnmphdcTVKC3WxyqLF6kL+niYpQIxqwa9rmxhaS2rIXCKzmGKnVP5TrvdRV5i
FvQx2jXK1W6hxWalktM5uj0pp4QrWw7lSOA5eY3LBY7FLEErFcBVrSAV0y2uexzocvFhTgS7
ukeUHBiPHR7ROqJ+K86yEuwTsYET8ZdIYjYMagpbsZB7w8L4Z4bH83imKhQnFpzQO6Pgqvzn
pW/E/29kwyV+G/v48fsT2UfrxhRKddy7d518/7rra38U3KhDYTDQjxJTCO5I3VPG+Bi88IXI
pDMvLq2WYewsXETz5HkoBDSCDXkRPctwdwbdM+/qXgHDOoz7Ie8cxD6hph+S9MKswJU4N/1A
RahG1jIu5urR/9AHY/5v6bFZUsy1DL6hFMEY8iQsWgE32EbZJEr0VSES8oa0h5XFuKHccJRD
YM2a9FeTF2rmcXoRX6kEeSA4mzrXwjLzNSdnj8MvfeD2i7ZqJyP+x282WNPOkTeQzzP23xFl
rqlzBD3l0XUxtijY5k8fCNOGDjEkMmEm2ml3ujAN7bS7PeG1Ox3HUXGwW8l5iuLi8LQW2eou
ubZUfbRH5vQS7TJZNSsvBLVLc9aIwjA9HkaUaaH7yO1hfPg4SeudZlkIVUgE7o6Ga7c/Uu+T
mljNKt15BKMc6d3dMwcom5Wq0D7Q1e40LEbaWmvFKGwfeCy04TA5hp+vYLpoQ3dCt4Y+/8LG
hdDm12n+j7rxqbrSSTrTdX5brc6v0Yiyahiv2ul4DKaZvlTW4+OUt6IYwjw1ufj9tJ2YXdBX
zUvd0lo2fUJzlxDISzkUWlVdEn29KOZkukK9G9RdZrScMo3gh2C8GHhBzHBk74CGVy27xAqA
L8r6wFnoAKeXLbfUCg1MPIojWO00wd+2SuVWaKTiJumlJsxxb5faM3PscbDnb1ulcoS9GyRS
wzWO7nQhunJq8dtIOZp4XyjZ5GZQA+ejFpzyb86EhW5YjvjtxTDTzlhy1gxO0yS+OsM8svwV
VMZLdTCFW3nKc+aM6MK7YE2xYUwM5k2Nmjmua1+E3jjeMoYqDNdZFykN/aVPi+XrK6r0rRbO
i9QqqP1tstNm3XI3t5x7Cjobu/y0o+0f/3eMkLmz3+6TQ2jZuVhOWW92WVuLYVwB8WfFKGYR
1jLmE9VYd13QPnxw+9wY+IQITaLRCLRxBRdJ9g46IMNvdVTdxPKQpP5pD6nCbV7BQ1KVX/m2
Sq6sciUm280TLB6Ud7vL6hc+kGXwJ6ZfohSOn2c+C+9/CGP3Thl/g8YymXmZlC2VNdpXtsyP
BN/Xa6MyCfNnKvzoO+Djp6AS7fJdWCtS4Kbx97Z7Q2+Y1/V7w06ncDru3b3A7d64+uKUeoy5
U/EUu/N+n7xk2022B4Ebuck2dMe9myhrrQ34D+MVbWV9gnkReg0wzz2wzZPF1bRnMC5L4DPC
tP5HuAHJKIxx6WFeRDE2LkX41Y/g8Fy0YhlCpapQZzdohiovsBMrF5h/IhwWuBlD5DYPC/0y
mGVsyDB9+OAKFBXzV+ZxmE8IrjyZ5c1xe9qn512/f6ff/6Hfv9vv/9jv1/v9Rr+/1+9/2+//
q99v9vuf+v3rfh9Kn/X77TOdGPfO90Y4n5/MBARGmLkuSvCGh8BMGypSZJeSdziX1Y4kSwTq
GPd+HY7qTkqu5jamxbA+HqVJMak37nabvdI3npbN8+HndJ7l3i9HUTIvGP+mqKSZxCwc6aOk
JJFOzjOCD4EezFFHDr6mVMJNmiNzcQoH8nJyeBwK5VLs48DcvoFjSKf6qem9zKNWbuT0y60l
9Xw1kbVVqtfVBMezwn596fHEtGvI0P12zICOUVW9OI5yVWBbK4BMAL9Uz1EhqAheslbi3UGW
Tv1qL3aTIMmBkVIQxvacHSZF3dixvt1odjuNZuXYik+53jbQi/Va3ZvW3BE1b1rvwZr1uh1Z
saPygMgz7JxDSixH4QxEQrF3vvYN3Me/mnSlKY57MDZjyLgwlqNw/sYS454Re3ycyZHRVulu
q14/ouzxaa7KwHyT3r0+BA1ubPZMu0i7JM3ZX0rZO+jwB4wHHy3H2t1UaWgFVDP30ohwquIp
fMY5XdsMpYpMVbT1JhuWHHNZRX/TDcC3doILwqC+GNrfonTuIzZmwMPjcBxmEfD23IGFtdyT
X4Jv8EkxRd6qwef6OvCN65JOGAC6AB7MD7MrWknhFcLgPAK+6eUevGbkY8QujHHWij1bjITm
nDiXvXk1f5qiFyOKYR6U8kyVby5INBwnHi6+q5kvFvmVKOOvnHK8RQHwrq6phgSBzGNRxkhq
xLnLvzcssdcFKfuihYqNOzZ5vAkRBLI6rNVS0Arqmr6WwyNzv0BpPubDGB/PHFkUFTTb+1bK
HLX7qdCjKElYJtD8MfC83NVbOjBzZXsYR/C7oKPcpJKztzWun7/pluQLtxWp3jPVJ3BICP5r
HmUfcpyQgnmZ2i1THBd7kXnR2DwTIdCO3XW5NF5TV+Ri1DLnp+UritlF8ZFt3OXdm1dBR8ie
bWkDYAJ1xXtt2yUsfmkcLLKbujQNiPx4E3795uEXj+p+VXZhExa3QM5fiFlXFrOMhq5cXhXY
pnBaaJM37aVKWjRRplV4mHcZnkmU5OCYHOPLjN/NKhm39ApWtX3cl/Kuu9NpNJyOZMzzgW5t
nXkogVWHD+zIhnNFNrRAO3NG3D2HuWU+YcwYXMPR6Fi91pMvf1Iu88whJ5PqHmNdZ2e/fRC4
sla99nv4MeTpO3ZpK30uNtI/siEsyuNol5QJc6vuxI35OW27UgJMxOXZmuZRrVQEN9lhGfBh
w13c17c5zPMmJdPgt6nkLljPzrj86dVJeI47yOo1zGZda5x2zixNcu/nvHa6wIKMZr69+4SH
m7Ud8/+gp64lsRvw/GZTXsazUvDlQwA4xQeHE7w+rgFfK9LwWCSI2f/mMcmXJiB7NSnC2v43
3+AIJBiJ4YLzLJ0no9YwjdNsN/huTA9nyRhmZa1xOI3iq11MKD4Kk7AJrl8YNycM/NQiGoa8
5BTczijZDTpsav7HP8KMGWPKnq/A7XAXtbQZhLsfwVvDrW+iWwLGrRFMwjKKsu3SziBRY4Kx
bawSUrK8pTW+47nURTmOa2uQFkU63VWIfEdnbn7BrSe8nI8jHobh5Htry6G0CxQa/7kNhE4T
z54dHOzs8FK5zLAuypAQcDfdbtDbmRW6kEyJLsqJtls4Su7yRp3q3Y6sPg2j5Iglc9lEnIZQ
J1ajOkUwsIKEAjJiLR7hg9c7O39x6W3fQ5m6PytQMEgfwOgiArckvzCOzkF0GXd/LVxdpj18
uLODjLcLceWo1m9ZyydhhCTsB11e9MnSbZLltlDf7paUqrAiRgVvq1tbnY6/VbuLLGJkqZe1
d8x+JlA3Fd9ETvY056Xd7RSMKEGZP/L3LCCNZfq7pGg4fPgQqSy3bArFKz+rtNWtPUKSCcht
zffbF+7tn/grlLppZY8x1aKts6C8wBxm6E4ZffVCdJNBGo8WVn6ZJr76ZLdBAAX0haEHAAiD
ZUkYU96UCtNnCIjzy2tPdG/0IO7VBgImTn55SOa79UtsfCCbqZaUKemQngoM8CWq7IAi97sB
X9q0MXtSUox2j7oL9V79e6X2akiW5laMMDaQ8Xhnp3KwkHbAbmOhvldAMvsaPyD7yWcEiA0i
wLIbhIM8jecFq5bQDelwucwNVvkfASjNQC1bmRhGZpcBoBONgu8QmAQnCsnh2VNKkxy6RNPK
ezUl9jDW6fzFArZs6DAhyXcGTm3DsZKDMUzDdqUFxyIYpWJW15HuFUy/orENmwf2fZhvd/5S
tlX34GWwyUORdOdrHgyicyoiLqTDrHx0huaHTRMbOTBwAlZ0xCosuYbpM/lLdNocm6u9OdkE
yfqf87TwWDalzzbf7km+CSXjvtKWVrEdeiy9FoU67Qf2MCze90rCnce2oynr33P8YemplQCk
nwtg0mtOtpqT7ebkXnOyUz02LRGvtwug3fHzZ7uEhWfE6YkBVRXa8hTquoW2q8Yus9C9cqGH
bpmdClUxylBmTGkEuJoA9XE4y6Gw/M3UItABw0Z18H8ePem2O47+SDNY+iCMhqtvasKiv1j8
ENZM0TFZ5I5iV7OJMAztTgf/t4K3Cj3HbnOEGbUt5lUCrgQyDHlaz0+Li80yBiZL1sE9bx4d
kf3dNgPlsX9nR5rxgD9aZWxyuHBGYT4BA4mUWTRZZsXoSNa4V3ovBas/KExnly6e3D6R/xCe
5+s4YWoWwacXq8/WTURMH63SHUME1/PFLD+JwHxNR4w38JleWHsC7I9RBKCWwOMPagT1jefe
yAu73xMTHJ6Rc8G4Jittd3rP7m97nHipBQY0SuG7wGMqd1hjdq5CAtLMCKAoilDPfX1wES90
4Cfg4hTrN/U6S6ezYgWemBPLPBoxY7LCAx2ZXlyTbZU00BSWr7EloTPtc2csppviOSkCn+P5
4GdwxtyZHzVx36XH9HuH6XQaJiOebqLa11yirj5u+QgttfhkgZiNHr5l9O0tc27t6X5OA1+v
n7sNefu7ObFZMAUogTP7ljaw2ypQY3HBMzJKdUPAZqqQBbO6lUJGHhoYPNJ0L1K7bXi8KKlA
kvPWnjdIMPfhsTpSOT7iwLmhBiwx0QYZbdEQpWKwXGzRd3r3Kn2u+8rJFkDwdkEAYhiZE5he
L5o96r5nBaB0NE82YQF0w56mwldZfBvA58xrF8ig3I63R5maDb41ZvWIdZB91cBTZffWxksx
Fd1xnNN1+L+O1wMvu+JjV7iUhFeFN7UOTp7YyFo4HaXZF+KTKc71cQJPafCM35rhiHFV0Sy0
VfLEgutFqja1iFYPSX1ue1ZwbQFn7aqG5FaVxmehiu1Z/tHCaZu0Ol0jTi67sgBYaXZ8Rb2x
Hiumt9joLDAwcTRkSc48/o41gZG/eSqt6LL0DJdF/ax2WuwmvqLT4jT0uU4L5TrEdQQYvtVV
xX4nA4uTw8w8ExG9dOBxTUTDF5OoqDZJgweDBw9lqK0iQr14oUYcHSBFEONhFBfoWIXxbBLW
xfe9e52GIB5T4LG8mt52eBmlU1wy94Vop2mS0rYZQ2tL65UchOkOlmmnWeJ5xmSet6pWFLiM
5fNYwvNNLVaCwv6ZpLbmDFS2q/LMyE/eKPpoUMgnfkHFCBVAhe+o3EyYpqBKGfBaWRlXlN4x
dQBeP58PppGq74k3UFPznGXvF3O+oiEPBaUoip+zf53C5DQMZlmUYKulpXVPn1qywqxts28G
W4Z3TZs+cM1wH37BnQ7wL0Xy0wRvwdmrIUr1Rm2fADzm+0OCPBvu1X7Pad/y73ltX20cCR5/
22oF03mO+Vpw4wzBGrBhiHnr8cot2mSEjilnPuD0ERcYMoaLjptTFuLeWyCqmAStlmj1+Nmb
w9cn+4Fo8SgcZml9I59tNDfebTQ7jeDxpijCyyPMCHBXNkqg/yuLh3ixC7SnryPHsy9/Yxmb
XgVvAG/MpaRvdP8eQTwKep3OveBVPk3zdFwEv0RTnKrwtjahMadZaSmQL+WvfDuJwMj6orZ4
GB8512dhwiHL7R3Ecni7qKC69b5U1kTLhz9XGh+K5rTVxTKk7Gp7tb+FH0N+TdTuI7xMhxJ/
7hmJ+Go84e5e7VhkV8SEblogtX2eHe7xZui0wLsnoajzxwU4pux170FLf2dXb2d7NSvnIu6R
byAaY0xVhx/NnHXyMx4EBdpmeKZzLx2Pl2Hop9zYo2dSTmmKnuhLxVWrohHKu4+3jssOCtNg
lUO3zuiqKjrcRae3wGyKBEUY2WIj6JtDCaDMsiWolTLgOajRNgE8n5QEb9/8whHIWJFFjHJ4
AcrGWd/4ykNAbZ+y5GNA/MbYYUd6xpNtuohh9lrevko2nArjgptV2YWtUFhapO1cl0cqvasj
PIJqtCbK1fbFVN9qz+huVr+yErw66GEZus5NFSO93z+ZMGeH5wJq9MaRvdqhvNFNolqi1bpk
iOh9VNt3q5UYiQ9l+kUzOoVxNjlfBz1DcKshpit4UcIOw69nhfHoKp1nwSBLL3Lj2jCPZBZy
/jcEgg5DgtkTkeQcPB3skgQe+2XeDujKYRzzQhzu1uEEkvQr+Bkr8kEW93Khzs7XwuFvKXsa
p+fnq2qJKo9YOHeb+3isbXpxWbzNedJIr1HnPY0rX6XhXipBjLzBiMibpf2twwkbfhiklxZ9
5baALzQCTj6g7XkK3uF8ltfKjF6BpyaA1bhq1Cjbr5U09wvQ/QR4jYisR7SqvRrFsvifR+5P
LGEwC2dPkjd5fsDYaD26y2BWY0Cp3p/HCZTDC7wV6YRN8VLENTWgDGZ15bfq/Xmc4Off1yOf
1+Ue5YqUm1X+PKJltur1yJa1Iww23Ih6T80/0fjxpJDr8eAFXces8v6uavXdasuor/IujYWW
G05d1HUvAzXi0lCtl2LQ/eK/retY+4CH4G/s488vCBTD3LV9/LmSS27HqWtSo8qrGLXlsMw4
bFkCGYtVkZqgblIUs93NzYuLC7HnGxOO40HFmjgKvld7D7McjzoakQ2YtM7mgzii/UaDKx3B
oB3e4JQ+PX7Ok+nm4LcOWSCQcHTMzyxf5MDYie8PfsgAl/+rEdzyx0esNOn7Dre/Twa5cVZS
VRNh6No+L7As+CFj3ADfenesJ6M1zBobjSMG3zA01LnX2+p0ulvqfQZ+M4WUeEQJZXYOukMz
B7x1PjCA4flMmDZgOuc5TpmCgyhjB2iZsoCmXAkrYBCIAYVst598VyrPTzLnwT9e4/tgSoGr
bJ7wo+3HLPsIUn0NzmPvdZaCPZnmCIXHt9RFi6enFOPAtfl/0QWI7Ukxjc/OKNMBT8sfbNCk
G4vAlKbdbm8givylSE/AX/eTH37Ae2E3NpK02Nig6+wBE4wAYrQAb0PfpFoimuTOy1S8MB0T
o94mswzmVEPoehi4jVjepiaGkxTjHheUEBtP+IciWQK/QB0hX0x4Og3MBIxTsTrmdMCE61Su
/fPJ0S8BHomAQSZNGsgX6g74EXoXBjTSCwqEYuZzPMvroIo1OA+xyoYYbjbEFTHysjjOa8QQ
eHRlTh6xPk4Xmyp2AUjLlIGUeF1EN1CyF2FSEOFXQot4RIMKHvO8PydmNMT4qo6FIfwjGWVm
xbDtUGBGSqrJwEJEhyiJQAy7cxEBt6fhByaSCs1ndAWDSk4sz61oORV44YpINIRyEsmKSAp4
eBDF009Ef7X75XM2DuexvGO03Dd3evc7vW2rbz5NB0fDFzFeFqG75unpw3bvfnu7HTxJgheX
Ic4pd4PnIIlsGiXAen7l6s9RPMAsLkdhkUWXZ2denH7BGHdxXMzH4wp8tpficyKuuQA5P8E1
E9lb8GL6fn/AzqPkEy2mXGNW/3OcKtQv3/Wal41+nyUj8c2LnlQAL27b3eW4nZ4ejmAEpL54
doYYEYoY9MY/viQrFeAKZHeWInuICkx2i+3ejHlYegq6FQH+VD/3AOgnJogtBJG4QKqb3Poh
Ts/rl41VxKZ5vjYv8LYjhmlueN71OE1ngUAnRuLqs3bQfdgJXrP8A5i670F0j4Lj4SRL2QhP
zT6h89fRZfCsvQWGnMUj492T9nZFRWRJcswwYpunMNY8B9eJTC7PVDaPwyz6g3zcs7M2lr1z
p98fZ+HwU/f605P33SfvezCwPHmfXAd7Qb8PGL/rvu8Eo8v3XfgPv8E/CXwB01mE9X4/n0+D
y/dR0Aq6DRzeBbR60uo2vr3+VL9EmN27UBdAB3cDvGUGIEALjXefkutraJ9jkVBrsv7o3csY
avf6/VnUePfyWsGN3/Ua795c0y+taePdESGaGE1HdWj63af6m9ZR4xoKdncQCFb79HJz+/o6
mL77BN/uvtzsXds1+/2fQuj59Td3NU961y8bgfxw1HrTsj9dq0r2e1WjcS2oS35F05+lBd9u
IGlmcfyu8/4FEBHRH9DWhNYtP3WHUyT7I0PE4Mv1+xd7LfNvCZhaUsnxFGSJFpvlUYz3eO0F
Gkf1+hok1++fE4i78BuuB8IY/unVtVFVttRPXqdagwKQPe+neJopz3HHw3k4h5FwAM5vEtR/
DuM/mFTRI7rDIUC133rYoGrIegTMRQDQ3gNecTgdjMJr1fh7wGn+Tn34AXmiPyXzd/KLkCU+
e0HrHGFN5wEWuSbKiPQZgQtmVPX609G73rXGAwk5QMtpIM+HcUS9SSNsMI7DWWM3qGfsn3Pw
H/OAEvlhpr8mXpS0UdDFB3S1BC7njEZ8TQt+54uqjYrRdQ1DXmGcHiw1TjCvyik9Jt1owH1V
bADju/NCJpYdua13Ozi3gZ8SjSmh0YapEBS/U4+avzfutMCfAOuZXdkY86I4zPKsUADoTnez
Ht39/W63cYdM0QHmCUF3lla6CBWuZ9z75vt0wI4l8+lAeF7pgFL5cV8nHOKSGW7BaPsGj3BX
sC04wKSMCBi9/nNgw+6exO/0VCFFyw2/ox/aabcfntGfkfqzPPSQGyE8KKT99NRgIPj34Inm
wU/gbucRJbWO8Avdy+TDdoRImRII4d3u7gFOscptvwRtQz8etHB0gcswNBXLQTIvU3JwcTkT
nOJphDssQLsfNVAUdM8QsBG8frpFkqQucuEKF1KIuIzgQLHzOV0lT5hpTq7MyEcuNahLYieN
UhWHLsR9mGYZZWhLYpr0jNFLptWhcTREho2i8wiKpuM+zmqGEcoFGHLI1eV3mEdxOYE6sQyq
xNDXw/gqj3J+hVNZc/MwGokzmt/jicZH4H23MP8gbfRhozZ/6xWnIcmBX37glDOR+s5UfpIc
HloRWUSJDtElTk+J63wod1vk5G93+slQa/76QjIpGJYpeMNwygU6T82CugOfsP0RnzTwjH/V
aPY6ZZBeM6kmWH7j17u31PhxH59PogK+llnRjtrXsW5TGHGa07VflNUJHVt+mX1OhuyCDTDp
PBuk6Qc+EcPpzCWNOYQlx0zgJwIpuM+HthAV03j/m/+4fW6f2+f2uX1un9vn9rl9bp/b5/a5
fW6f2+f2uX1un9vn9rl9bp/b5/a5fW6f2+f2uX1un9vn9rl9bp/bZ/Hzv8Ucz1EAwAMA

\start
Date: Sun, 6 Aug 2006 14:42:10 -0400
From: Bill Page
To: list
Subject: RE: SAGE and Axiom
Cc: Tom Boothby

On Sat 5 Aug 2006 23:56:25 -0700 (PDT) Tom Boothby wrote:

> Subject: Re: Fwd: Axiom point of view... 
> 
> I'm very excited about the notebook getting used by more systems.
> Like David said, you can already do this to a large extent with SAGE
> as it stands.  However, you'll undoubtably want tighter integration.
> I'm sure you'll understand that I'd rather see this happen through
> SAGE -- I'm willing to help a fair amount to this end.
>

I apologize for starting in the middle of this exchange. I wasn't
able to retrieve any archived messages from this thread in the
SourceForge archive, so I hope you will forgive that some of my
questions have already been addressed.

By "tighter integration" are you referring to converting to and
from Axiom data structures and Sage data structures and therefore
allowing the results of calculations from one system to be
translated and used in another? As you might know, Axiom is
quite distinct from most other computer algebra systems in the
extent to which it employs strong typing and an object-orientation.
Do you think that therefore such "tight integration" might present
more problems with Axiom and Sage compared to, say the existing
Maxima-Sage interface?
 
> However, if you would be interested in helping make a wiki-style
> IDE, I'm quickly starting to believe that this may become a new 
> way to work on a project.  William and I have discussed this a
> little, but this idea has been brewing over the past few months.
> Within the next week or two, I'll try and outline my ideas for what
> this system would entail.  Oooh.  Maybe I'll do this on our new
> wiki.
>

I am very glad to hear confirmation of interest in concept of using
a wiki for integrated collaborative development of mathematical
software. This is something that we have been trying to do for some
time now in Axiom. I am still a strong believer in this idea even
though I have to admit that we have not yet been very successful in
establishing any serious and long term projects of this nature that
depend critically on the Axiom Wiki.

http://wiki.axiom-developer.org

I would be very interested to hear more about your plans for "our
new wiki". I recall that parts of Sage are written in Python and
depends on Zope. The Axiom Wiki is uses the Zwiki Zope product with
extensions to provide LaTeX support and interfaces to Axiom and
Reduce. As Tim has mentioned we have also developed a new page
type for ZWiki which implements some of the components of a
literate programming environment for Axiom. At the present time
all of the Axiom source code is accessible (and editable) in this
environment but we have not yet completed the direct integration of
this wiki interface with the rest of the Axiom build environment.

So I am very interested to hear your ideas about how this sort
of thing should work.

\start
Date: 07 Aug 2006 00:04:56 +0200
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] Rename INSTALL to DESTDIR

  The current toplevel makefile uses the variable INSTALL to designate
the prefix of the installation directory.  That usage does not seem
common; at least, it clashes with the classical meaning of INSTALL in
the Autotools world (it holds the name of the 'install' program, or
equivalent).  This patch changes that to DESTDIR, which is the
conventional name.

Tested on an i686-pc-linux-gnu.

-- Gaby
2006-08-06  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet (DESTDIR): Rename from INSTALL, throughout.
        * Makefile.in: Regenerate.

*** Makefile.pamphlet	(revision 15561)
--- Makefile.pamphlet	(local)
*************** PART=	cprogs
*** 300,313 ****
  SUBPART= everything
  
  @
! \subsubsection{INSTALL and COMMAND}
  The install directory is [[/usr/local/axiom]] by default 
  but this can be changed on the command line by typing:
  \begin{verbatim}
! make INSTALL=/yourabsolutepath COMMAND=fullPathAndCommand install
  \end{verbatim}
  
! The [[COMMAND]] string has been modified to use the [[INSTALL]]
  variable so we can properly find the axiom command.
  
  The [[DOCUMENT]] variable is now set to replace the direct call
--- 300,313 ----
  SUBPART= everything
  
  @
! \subsubsection{DESTDIR and COMMAND}
  The install directory is [[/usr/local/axiom]] by default 
  but this can be changed on the command line by typing:
  \begin{verbatim}
! make DESTDIR=/yourabsolutepath COMMAND=fullPathAndCommand install
  \end{verbatim}
  
! The [[COMMAND]] string has been modified to use the [[DESTDIR]]
  variable so we can properly find the axiom command.
  
  The [[DOCUMENT]] variable is now set to replace the direct call
*************** TMP=${OBJ}/tmp
*** 330,337 ****
  SPADBIN=${MNT}/${SYS}/bin
  INC=${SPD}/src/include
  CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
! INSTALL=/usr/local/axiom
! COMMAND=${INSTALL}/mnt/${SYS}/bin/axiom
  DOCUMENT=${SPADBIN}/document
  TANGLE=${SPADBIN}/lib/notangle
  WEAVE=${SPADBIN}/lib/noweave
--- 330,337 ----
  SPADBIN=${MNT}/${SYS}/bin
  INC=${SPD}/src/include
  CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
! DESTDIR=/usr/local/axiom
! COMMAND=${DESTDIR}/mnt/${SYS}/bin/axiom
  DOCUMENT=${SPADBIN}/document
  TANGLE=${SPADBIN}/lib/notangle
  WEAVE=${SPADBIN}/lib/noweave
*************** lspclean:
*** 615,625 ****
  \subsection{install}
  <<install>>=
  install:
! 	@echo 78 installing Axiom in ${INSTALL}
! 	@mkdir -p ${INSTALL}
! 	@cp -pr ${MNT} ${INSTALL}
  	@echo '#!/bin/sh -' >${COMMAND}
! 	@echo AXIOM=${INSTALL}/mnt/${SYS} >>${COMMAND}
  	@echo export AXIOM >>${COMMAND}
  	@echo PATH='$${AXIOM}/bin':'$${PATH}' >>${COMMAND}
  	@echo export PATH >>${COMMAND}
--- 615,625 ----
  \subsection{install}
  <<install>>=
  install:
! 	@echo 78 installing Axiom in ${DESTDIR}
! 	@mkdir -p ${DESTDIR}
! 	@cp -pr ${MNT} ${DESTDIR}
  	@echo '#!/bin/sh -' >${COMMAND}
! 	@echo AXIOM=${DESTDIR}/mnt/${SYS} >>${COMMAND}
  	@echo export AXIOM >>${COMMAND}
  	@echo PATH='$${AXIOM}/bin':'$${PATH}' >>${COMMAND}
  	@echo export PATH >>${COMMAND}

\start
Date: Mon, 7 Aug 2006 17:06:10 -0400
From: Bill Page
To: Antoine Hersen
Subject: RE: Front page esthetic

> On 8/6/06, Jay Belanger wrote:
> ...
> Bill Page wrote:
> > :( Well, I really like the example ... in fact I have even
> > given a wild thought to how we might make the from page choose
> > randomly between a large set of similar examples so that a
> > visitor might be treated to a new one at each visit ...
>
> That's a pretty neat idea. 
> ...

On August 6, 2006 4:51 AM Antoine Hersen wrote:

> About the example on the front page. It is aesthetic but the
> type result is almost the equivalent to any.
>
> I do not have super good replacement idea.
> But I will propose some Taylor expansion maybe ?

The kind of thing I had in mind should appear non-trivial. (I admit
the current example could be considered nearly trivial.) It should
be largely self-explanatory. And it should generate some nicely
formatted LaTeX output but not too much output. In short, designed
to impress. Integration results often seem to quality.

I don't worry too much about the type of the result but the fact
that Axiom's results are typed is certainly worth illustrating.

Of course Axiom can do a lot more than just integration. I think
it would be great to have more suggestions and examples of
favourite Axiom calculations that Axiom users would like to see
on the FrontPage. Send your examples and I will see if I can find
a way to select them at random. 

\start
Date: Mon, 7 Aug 2006 17:12:12 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: pamphlet problems

Ralf,

On August 5, 2006 8:17 PM you wrote:
> 
> In order to remove the need to distribute a version of noweb 
> with Axiom, we must modify the sources a bit.

I must have missed something. Why do you think there is a need
to distribute noweb with Axiom? From my point of view noweb is
just a dependency like several other packages required to build
axiom.

> ...

\start
Date: Tue, 08 Aug 2006 00:53:31 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: pamphlet problems

Well, that

notangle src/hyper/token.pamphlet > dummy
undefined chunk name: <<token.c>>

error occurs if you run "original" notangle on token.pamphlet. So either 
my Silver/build-improvement version uses its own (modified) notangle or 
notangle is never called on that file.

But I've now run (axiom--main--1)

mnt/linux/bin/lib/notangle src/hyper/token.pamphlet 

echo $?

and got error code 2.

So the question is actually not about a dependency on noweb but it shows 
a bug in a Makefile. Why is that error ignored? Or is token.c never 
generated? The latter seems to be the case. So what do we need 
token.pamphlet for?

Ralf

On 08/07/2006 11:12 PM, Bill Page wrote:
> Ralf,
> 
> On August 5, 2006 8:17 PM you wrote:
>> In order to remove the need to distribute a version of noweb 
>> with Axiom, we must modify the sources a bit.
> 
> I must have missed something. Why do you think there is a need
> to distribute noweb with Axiom? From my point of view noweb is
> just a dependency like several other packages required to build
> axiom.



\start
Date: 08 Aug 2006 03:33:25 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: pamphlet problems

Bill Page writes:

| Ralf,
| 
| On August 5, 2006 8:17 PM you wrote:
| > 
| > In order to remove the need to distribute a version of noweb 
| > with Axiom, we must modify the sources a bit.
| 
| I must have missed something. Why do you think there is a need
| to distribute noweb with Axiom? From my point of view noweb is
| just a dependency like several other packages required to build
| axiom.

Hmm, I don't seem to have Ralf's original message...

\start
Date: Mon, 7 Aug 2006 21:37:55 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: pamphlet problems

Look here:

http://lists.gnu.org/archive/html/axiom-developer/2006-08/msg00154.html

On August 7, 2006 9:33 PM Gaby wrote:
> 
> "Bill Page" writes:
> 
> | Ralf,
> | 
> | On August 5, 2006 8:17 PM you wrote:
> | > 
> | > In order to remove the need to distribute a version of noweb 
> | > with Axiom, we must modify the sources a bit.
> | 
> | I must have missed something. Why do you think there is a need
> | to distribute noweb with Axiom? From my point of view noweb is
> | just a dependency like several other packages required to build
> | axiom.
> 
> Hmm, I don't seem to have Ralf's original message...

\start
Date: Mon, 7 Aug 2006 21:56:07 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: pamphlet problems

Ralf,

On August 7, 2006 6:54 PM you wrote:
> 
> notangle src/hyper/token.pamphlet > dummy
> undefined chunk name: <<token.c>>
> 
> error occurs if you run "original" notangle on 
> token.pamphlet. So either my Silver/build-improvement
> version uses its own (modified) notangle or notangle
> is never called on that file.
> 
> But I've now run (axiom--main--1)
> 
> mnt/linux/bin/lib/notangle src/hyper/token.pamphlet 
> 
> echo $?
> 
> and got error code 2.
> 
> So the question is actually not about a dependency on noweb 
> but it shows a bug in a Makefile. Why is that error ignored?
> Or is token.c never generated? The latter seems to be the
> case. So what do we need token.pamphlet for?
>

'token.pamphlet' contains token.h, so yes it is needed.

When I run

mnt/linux/bin/lib/notangle src/hyper/token.pamphlet

I get:

...
*/

ignoring undefined chunk name: <<token.c>>
<<token.c>>

------

This message is a result of Tim's patch to noweb (which should
be handled via a simple awk filter instead of a patch to the
noweb source).

But from other examples of Tim Daly's usual coding practice in the
Makefiles I believe that notangle is never called that way with this
file. It is acutally used this way:

$ mnt/linux/bin/lib/notangle -R'token.h' src/hyper/token.pamphlet

with a specified 'root' to extract just the header file. See:

$ cd src/hyper
$ grep token.h *.pamphlet
hyper.pamphlet:#include "token.h"
Makefile.pamphlet:        ${MID}/titlebar.h ${MID}/token.h
Makefile.pamphlet:${MID}/token.h: ${IN}/token.pamphlet
Makefile.pamphlet:      @ echo 139 making ${MID}/token.h from
${IN}/token.pamphlet
Makefile.pamphlet:      @ (cd ${MID} ; ${TANGLE} -R"token.h"
${IN}/token.pamphlet >token.h )
token.pamphlet:\section{token.h}
token.pamphlet:<<token.h>>=

--------

BTW, I am still curious about "my Silver/build-improvement version".
Is this a new version of noweb?

\start
Date: Tue, 8 Aug 2006 00:48:17 -0400
From: Bill Page
To: Frithjof Schulze
Subject: RE: patches

Frithjof,

On August 5, 2006 9:30 AM you wrote:

> 
> here are some minor modifications of bookvol1 and ComputerTutorial.
>

Thank you very much for sending the patches. I have not applied
these patches to any of the Axiom distributions yet however I
did take the opportunity to update the online versions of these
documents on the Axiom Wiki from the Axiom Silver distribution and
then I applied your patches there. If you wish you can continue to
make your proposed changes to this online version. This would
allow the changes to be quickly reviewed by other Axiom users and
developers.

I would like to ask the other Axiom Developers for their opinion
about how best to handle these sort of changes to documentation in
the Axiom source distribution: Should we accumulate and review the
changes online and only then apply a cumulative patch to Silver
and Gold?
 
> In bookvol1 there were two nearly identical sections about the
> "%" macro. I removed one and moved a short explanation to the
> place "%" is used the first time.
>

See revised online version:

http://wiki.axiom-developer.org/book--main--1/Bookvol1
 
> In ComputerTutorial I changed all occurrences of "\<\<" in
> verbatim environments into "<<" as (at least my) latex doesn't
> execute the command there. I also added ComputerTutorial to the 
> Makefile.phamphlet.
>

See revised online version:

http://wiki.axiom-developer.org/book--main--1/ComputerTutorial
 
> There is more duplication in the tutorial. I found that
> distracting. Reading something I had already read, I got 
> bored, started to skip sections and finally was out of it.
> I would like to splice those sections in where they belong
> or remove them. Is that an acceptable policy?
> 

I consider this a completely acceptable policy and I would like
to encourage you (and others) to continue to make these changes.
As the saying goes: Be Bold! You contributions will be greatly
appreciated by all.

\start
Date: Tue, 08 Aug 2006 10:01:34 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: patches

> I would like to ask the other Axiom Developers for their opinion
> about how best to handle these sort of changes to documentation in
> the Axiom source distribution: Should we accumulate and review the
> changes online and only then apply a cumulative patch to Silver
> and Gold?

I would very much like that there is only ONE version, namely 
axiom--test--1 editable through the wiki and that version is always in 
sync with a branch (call it silver/branches/axiom--test--1) on our 
subversion repository. Is that sync'ing easily achievable?

I don't like very much that there is a separate (completely different 
looking branch book--main--1). I guess that makes the axiom sources even 
more a mess than they are in axiom--main--1.

Reduce the number of different repositories!

\start
Date: Tue, 08 Aug 2006 10:10:52 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: pamphlet problems

> BTW, I am still curious about "my Silver/build-improvement version".
> Is this a new version of noweb?

No, not that I know of. I used the original "noweb".

\start
Date: Tue, 8 Aug 2006 09:15:28 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: patches

On August 8, 2006 4:02 AM Ralf Hemmecke wrote:
> 
> > I would like to ask the other Axiom Developers for their opinion
> > about how best to handle these sort of changes to documentation
> > in the Axiom source distribution: Should we accumulate and review
> > the changes online and only then apply a cumulative patch to Silver
> > and Gold?
> 
> I would very much like that there is only ONE version, namely 
> axiom--test--1 editable through the wiki and that version is 
> always in sync with a branch (call it silver/branches/axiom--test--1)
> on our subversion repository.

I rather dislike these weird "arch" names. Perhaps we can define
a new branch in Silver specifically for this purpose? On the other
hand having too many branches seems like the same kind of "trap"
that we got into with arch - defining branches and then no one
shows up to maintain them and no one bothers to merge them etc.
Maybe we should just sync the Silver main branch.

> Is that sync'ing easily achievable?

Yes. We could automatically do an 'svn update' every evening.
I have been thinking about how best to view the online wiki
version of the source and documentation. I believe that it
should be treated in much the same way as one would treat one's
own local copy of a repository. The only difference here is
that this online version might be edited in a collaborative
fashion. We should not think of it as "yet another repository"
but rather just the online collaborative shared version of
one of the main repositories. Using 'svn update' can be automatic
but I think we might need to take more care with 'svn commit'.
Should we limit commits to only one file at a time?

Another alternative that I have been thinking about is only
supporting a "diff and patch" interface for the online wiki
version of the source and documentation. This would mean adding
two new options to the pamphlet thumbnail menu. Clicking on
'diff' would ask you to upload an 'original' file and then
perform a 'diff -au' against that file. The output would be
presented in the browser and could be saved as a patch file.
Clicking on 'patch' would ask you to upload a patch file and
then attempt to apply that patch to the online pamphlet source.

This "diff and patch" interface would keep the online source
and documentation pamphlets independent of the choice of underlying
repository software, but synching and committing would then be
a more manual process.

I am not sure yet which model I prefer.

> 
> I don't like very much that there is a separate (completely
> different looking branch book--main--1).

I think originally Tim had in mind that there might be people
who only wished to work on the Axiom documentation. Note there
are some files in book--main--1 that are not in any other
branch, e.g. bookvol2.pamphlet etc. I still inclined to agree
that the "large" documentation with no direct connection to
the source pamphlets should be separable. Rather than what
you suggest, I would be in favour of moving bookvol1.pamphlet
out of the Silver source distribution and into it's own svn
repository.

> I guess that makes the axiom sources even more a mess than
> they are in axiom--main--1.
> 
> Reduce the number of different repositories!
> 

I agree! My personal opinion is still that svn is a poor choice:
I would rate it only slightly above cvs and below arch. And I
rate darcs as much better than both. I still have a lot of
trouble getting svn to work properly on windows. (darcs works
fine on windows.) But in the interests of easing cooperation and
collaboration I think we need to compromise and standardize on
svn.

In fact I think we should drop the entire arch (tla) archive.
Now that we have Silver, I don't see that the arch version has
any real purpose.

\start
Date: Tue, 08 Aug 2006 15:20:07 +0200
From: Ralf Hemmecke
To: list
Subject: Building Axiom with unmodified noweb

I've grepped the silver/branches/build-improvements branch for the word 
'notangle'.

grep -l -R 'notangle' * |grep -v 'svn-base'

The following files contain explicit reference to 'notangle'
build-setup.sh
   reference to notangle will go away in the near future...

Makefile.pamphlet
   sets the variables TANGLE/WEAVE (that should be OK)
   TANGLE=${SPADBIN}/lib/notangle
   WEAVE=${SPADBIN}/lib/noweave

src/scripts/document
   Uses noweb by setting the following variables.
   tangle=$AXIOM/bin/lib/notangle
   weave=$AXIOM/bin/lib/noweave

src/algebra/Lattice.pamphlet
   MANY lines like
   ${SPADBIN}/notangle -R"domain XPR XPolynomialRing" \
      ${IN}/xpoly.spad.pamphlet >XPR.spad
   appear here.


The 'src/scripts/document' should get the TANGLE and WEAVE variables 
from Makefile.pamphlet or the configure script. Gaby, is the latter 
possible?

The file src/algebra/Lattice.pamphlet is just 1.7 MB and about 45,000 
lines. My emacs dies when it automatically tries to font-lock that file. :-(

Anyway, I believe quite a lot of the Makefile code in there could be 
made much shorter. In particular, lines like the one above could be 
generated by looking into ${IN}/xpoly.spad.pamphlet.

 >perl -n -e 'if 
(/^<<(domain|category|package)\s+([^\s]+)\s+([^\s]+)>>=\s*$/){print 
"[$1] ($2) <$3>\n"}' src/algebra/xpoly.spad.pamphlet

(that is just ONE line and it produces...)

[domain] (OFMONOID) <OrderedFreeMonoid>
[category] (FMCAT) <FreeModuleCat>
[domain] (FM1) <FreeModule1>
[category] (XALG) <XAlgebra>
[category] (XFALG) <XFreeAlgebra>
[category] (XPOLYC) <XPolynomialsCat>
[domain] (XPR) <XPolynomialRing>
[domain] (XDPOLY) <XDistributedPolynomial>
[domain] (XRPOLY) <XRecursivePolynomial>
[domain] (XPOLY) <XPolynomial>

In Lattice.pamphlet we find ...
cd ${MID};${SPADBIN}/notangle ${IN}/xpoly.spad.pamphlet >xpoly.spad
cp ${MID}/FMCAT.NRLIB/code.o ${OUT}/FMCAT.o
cd ${MID} ;  echo ')co FMCAT.spad' | ${INTERPSYS}
${SPADBIN}/notangle -R"category FMCAT FreeModuleCat"
     ${IN}/xpoly.spad.pamphlet >FMCAT.spad
cp ${MID}/FM1.NRLIB/code.o ${OUT}/FM1.o
cd ${MID} ;  echo ')co FM1.spad' | ${INTERPSYS}
${SPADBIN}/notangle -R"domain FM1 FreeModule1" ${IN}/xpoly.spad.pamphlet
     >FM1.spad

etc.

I am quite sure that all the hundreds of targets in Lattice.pamphlet 
follow exactly the same pattern. Shouldn't we have a short program that 
replaces 40,000 Makefile lines???

\start
Date: Tue, 08 Aug 2006 16:11:06 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: patches

Hi Bill,

>> I would very much like that there is only ONE version, namely 
>> axiom--test--1 editable through the wiki and that version is always
>>  in sync with a branch (call it silver/branches/axiom--test--1) on 
>> our subversion repository.

> I rather dislike these weird "arch" names.

No problem, but the branch on the SVN repository and the name you put
onto the website should be identical.

> Perhaps we can define a new branch in Silver specifically for this 
> purpose?

Yes, exactly.

> On the other hand having too many branches seems like the same kind 
> of "trap" that we got into with arch - defining branches and then no 
> one shows up to maintain them and no one bothers to merge them etc. 
> Maybe we should just sync the Silver main branch.

Hmmm, I would say that what now is axiom--test--1 should just become

silver/branches/axiom--test--1

or whatever name you like to give it. And it should live on Sourceforge
and on the wiki with identical data. The Wiki could be freely updated by
everyone (maybe some registration would be useful, so we would know whom
to contact if we like or dislike a modification). Then we (ax-dev
mailing list) have about one (or two?) month to give
opinions/testresults etc. If there is no serious problem then the
modifications can be merged with silver/trunk.

I strongly believe that axiom--main--1 should be a "testing" branch and
things from their should only enter the silver/trunk if they do not
break anything serious. Note that silver/trunk is supposed to become Gold.

On the other hand, patches to silver/trunk should be immediately applied
to silver/branches/axiom--test--1 and thus become available on the
website. axiom--test--1 is not supposed to compile, but it should be
close to it and should be at least as hot as silver/trunk.

>> Is that sync'ing easily achievable?

> Yes. We could automatically do an 'svn update' every evening. I have 
> been thinking about how best to view the online wiki version of the 
> source and documentation. I believe that it should be treated in much
>  the same way as one would treat one's own local copy of a
> repository. The only difference here is that this online version
> might be edited in a collaborative fashion. We should not think of it
> as "yet another repository" but rather just the online collaborative
> shared version of one of the main repositories. Using 'svn update'
> can be automatic but I think we might need to take more care with
> 'svn commit'.

I believe that people should register before they can change code. Then
commiting is not a problem, you just forward the registered name (and
allow it).

> Should we limit commits to only one file at a time?

I would say so, since we might accept some changes and reject others. It
is easier to pick the stuff if you have per-file-commits. I believe that
it is a bit hard to submit changesets through the webinterface. But it
should be required to add a reason for the change and that reason should
become an svn-log.

> Another alternative that I have been thinking about is only 
> supporting a "diff and patch" interface for the online wiki version 
> of the source and documentation.

Maybe some people like diff and patch, I don't. I am not a computer and
have problems in reading the diffs. It is simply not natural for a human.

>> I don't like very much that there is a separate (completely 
>> different looking branch book--main--1).

> I think originally Tim had in mind that there might be people who 
> only wished to work on the Axiom documentation.

Hmmm, that is strange. Axiom should become just one big documentation
(all is literate). Seems like the book stuff is a project that is
"about" Axiom but not Axiom itself similar to "The TeXbook" and
"TeX---The Program". If that was the intension? Then I could understand
the splitting, but I still believe that we should have everything in
just one repository. If I come to the Axiom project I would not like to
learn after some weeks of studying the sources that the Axiom-Book is
actually another project and doesn't live in axiom--main--1.

>> Reduce the number of different repositories!

> I agree! My personal opinion is still that svn is a poor choice: I 
> would rate it only slightly above cvs and below arch.

Yes, yes. And I also believed that arch is better than svn (and still
do), but Gaby is right in the sense that we must lower the barrier for
new people. That is more important than a non-perfect SCM.

> I still have a lot of trouble getting svn to work properly on
> windows.

That is not my main concern. I rather think that the missing starmerge
is a problem. SVK should overcome that, but I have not yet tested it
properly.

> But in the interests of easing cooperation and collaboration I think
> we need to compromise and standardize on svn.

Yes. Let's for the moment concentrate on svn/svk. If the SCM becomes a 
problem we can switch later.

> In fact I think we should drop the entire arch (tla) archive.

We can. It is as simple as this: remove any reference to any other 
repository than axiom--main--1 from 
http://wiki.axiom-developer.org/AxiomSources. If nobody knows about 
these archives, they are gone.

But we should ask Tim about it and, in fact, I believe, now that we have 
the AxiomSources page, they don't hurt that much. What I would actually 
like to see is how much alive a branch is. But maybe that is asking for 
too much. Is it possible to see branch activities on sourceforge without 
actually downloading the branch?

\start
Date: 08 Aug 2006 17:20:52 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: patches

Bill Page writes:

| On August 8, 2006 4:02 AM Ralf Hemmecke wrote:
| > 
| > > I would like to ask the other Axiom Developers for their opinion
| > > about how best to handle these sort of changes to documentation
| > > in the Axiom source distribution: Should we accumulate and review
| > > the changes online and only then apply a cumulative patch to Silver
| > > and Gold?
| > 
| > I would very much like that there is only ONE version, namely 
| > axiom--test--1 editable through the wiki and that version is 
| > always in sync with a branch (call it silver/branches/axiom--test--1)
| > on our subversion repository.
| 
| I rather dislike these weird "arch" names. Perhaps we can define
| a new branch in Silver specifically for this purpose? On the other
| hand having too many branches seems like the same kind of "trap"
| that we got into with arch - defining branches and then no one
| shows up to maintain them and no one bothers to merge them etc.
| Maybe we should just sync the Silver main branch.

I'm for that.  If the silver branch is supposed to be the "live"
source, then I see no reason to branch from different places.

I hope to have enough cleanup on build-improvements, so that we can
merge part  of the work there.

\start
Date: Tue, 8 Aug 2006 11:22:06 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Building Axiom with unmodified noweb

Ralf,

On August 8, 2006 9:20 AM Ralf Hemmecke wrote:
> ... 
> The file src/algebra/Lattice.pamphlet is just 1.7 MB and about
> 45,000 lines. My emacs dies when it automatically tries to
> font-lock that file. :-(
> 

Yes, it is ridiculously huge. The same is true of several other
Makefiles. I argued with Tim Daly over this. He claimed that the
regular structure of these "dirt simple" files makes them easy
to maintain and he adamantly resisted any sort of more sophisticated
gnu make methods that would make the files much shorter. I still do
not accept this view. I think shorter is (almost) always better even
if it means you have to learn a little more about the tools you are
using.

> Anyway, I believe quite a lot of the Makefile code in there could be 
> made much shorter. In particular, lines like the one above could be 
> generated by looking into ${IN}/xpoly.spad.pamphlet.
> 
>  >perl -n -e 'if 
> (/^<<(domain|category|package)\s+([^\s]+)\s+([^\s]+)>>=\s*$/){print 
> "[$1] ($2) <$3>\n"}' src/algebra/xpoly.spad.pamphlet
> 
> (that is just ONE line and it produces...)
> 
> [domain] (OFMONOID) <OrderedFreeMonoid>
> ...
> etc.

This is similar to the awk scripts that I wrote for
src/algebra/Makefile.pamphlet take a look at the chunks

<<findSpadFiles>>
<<findBootstrapFiles>>

> 
> I am quite sure that all the hundreds of targets in Lattice.pamphlet 
> follow exactly the same pattern. Shouldn't we have a short program
> that replaces 40,000 Makefile lines???
> 

Yes! Before I finally got Tim to accept my change to
src/algebra/Makefile.pamphlet it was similar in size and as far
as I was concerned it was unmaintainable.

A minor point: Should we assume 'perl' as a build dependency? I
only assumed 'awk' - which one might view as an older and simpler
version of 'perl'. But I am not against assuming the presence of
'perl' and getting rid of the old 'awk' scripts.

\start
Date: 08 Aug 2006 17:23:09 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: patches

Ralf Hemmecke writes:

[...]

| > On the other hand having too many branches seems like the same kind
| > of "trap" that we got into with arch - defining branches and then no
| > one shows up to maintain them and no one bothers to merge them
| > etc. Maybe we should just sync the Silver main branch.
| 
| Hmmm, I would say that what now is axiom--test--1 should just become
| 
| silver/branches/axiom--test--1

Can we get rid of the weird double dashes?

[...]

| Maybe some people like diff and patch, I don't. I am not a computer and
| have problems in reading the diffs. It is simply not natural for a human.

Agreed.

\start
Date: 08 Aug 2006 17:28:14 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Building Axiom with unmodified noweb

Ralf Hemmecke writes:

[...]

| The 'src/scripts/document' should get the TANGLE and WEAVE variables
| from Makefile.pamphlet or the configure script. Gaby, is the latter
| possible?

yes; and it is planned.  Good to hear the request comes from another
source :-)

| The file src/algebra/Lattice.pamphlet is just 1.7 MB and about 45,000
| lines.

Well, I think a file that gigantic is unworkable for mortables like me.

[...]

| I am quite sure that all the hundreds of targets in Lattice.pamphlet
| follow exactly the same pattern. Shouldn't we have a short program
| that replaces 40,000 Makefile lines???

We should.  

I'm certainly  not going to encourage students to dive into gigantic
monsters. 

\start
Date: Tue, 08 Aug 2006 17:44:25 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Building Axiom with unmodified noweb

> A minor point: Should we assume 'perl' as a build dependency? I
> only assumed 'awk' - which one might view as an older and simpler
> version of 'perl'. But I am not against assuming the presence of
> 'perl' and getting rid of the old 'awk' scripts.

Hmm, PERL is certainly not installed on every machine, but I now write 
all my scripts in perl simply because I cannot remember all those 
different variants of sh, ksh, csh, zsh, etc and awk, nawk, oawk, mawk.
It is quite human to make error with that.

I am all in favour of PERL. It is quite common nowadays anyway. And for 
our simple usage we probably don't need any fancy perl module.

That's my 1 1/2 cents. ;-)

\start
Date: 08 Aug 2006 22:06:45 +0200
From: Gabriel Dos Reis
To: list
Subject: Do we need to install spad files?

The current build machinery installs spad files generated from
pamphlet files.  Do we need that?

\start
Date: Tue, 08 Aug 2006 22:22:22 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Do we need to install spad files?

What exactly do you mean by that?

On 08/08/2006 10:06 PM, Gabriel Dos Reis wrote:
> The current build machinery installs spad files generated from
> pamphlet files.  Do we need that?

\start
Date: Tue, 8 Aug 2006 16:37:12 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Do we need to install spad files?

On Tuesday, August 08, 2006 4:22 PM Ralf Hemmecke wrote:
>
> What exactly do you mean by that?
>
> On 08/08/2006 10:06 PM, Gabriel Dos Reis wrote:
> > The current build machinery installs spad files generated
> > from pamphlet files.  Do we need that?
> >

I presume that Gaby is talking about the spad source files
contained in

   mnt/linux/src/algebra

These files are created by notangle of the root <<*>> from
all of the *.spad.pamphlet files.

Yes, in principle these files are needed. They are the "source"
files referred to by the ')sh' command and in hyperdoc. But
there is currently a problem with accessing these files and
also a conceptual problem of how to handle the editing of
these files since for that purpose they have been replaced
by .pamphlet files.

See:

http://wiki.axiom-developer.org/144

and

http://wiki.axiom-developer.org/116

I may have to take back what I said ealier about noweb not
being a required part of the run-time environment if we decide
that we want to maintain this "edit source" feature.

\start
Date: 08 Aug 2006 22:40:47 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Do we need to install spad files?

Ralf Hemmecke writes:

| What exactly do you mean by that?
| 
| On 08/08/2006 10:06 PM, Gabriel Dos Reis wrote:
| > The current build machinery installs spad files generated from
| > pamphlet files.  Do we need that?

[15:40]% ls /usr/local/axiom/mnt/linux
algebra  autoload  bin  doc  input  lib  src  timestamp
[15:40]% ls /usr/local/axiom/mnt/linux/src
algebra
[15:40]% ls /usr/local/axiom/mnt/linux/src/algebra
 ... pages of spad files ...

\start
Date: 08 Aug 2006 22:52:40 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Do we need to install spad files?

Bill Page writes:

[explanation and answers]

| I may have to take back what I said ealier about noweb not
| being a required part of the run-time environment if we decide
| that we want to maintain this "edit source" feature.

I'm going to assume that, for the moment, noweb is just a build
utility, not intended to be installed with Axiom.

We can revise that decision later. 
I'm trying to simplify/rationalize the Makefiles and the build machinery.

\start
Date: Tue, 8 Aug 2006 18:42:38 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: [Axiom-mail] Re: noweb

On Tuesday, August 08, 2006 5:56 PM in axiom-mail Gaby wrote:
> ...
> I need to get this Autoconf stuff move on.
>

I think you are doing a great job! Thanks.

> Did you test build-improvements branch recently?
>

I just did:

  svn update
  ./configure
  make

on the axiom-developer.org server and got the following
build failure:

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 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 how to run the C preprocessor... gcc -E
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include

...

touch raw_pre_gcl_map
gcc -o raw_pre_gcl
/home/page/axiom.build-improvements/obj/linux/lib/cfuns-c.o
/home/page/axiom.build-improvements/obj/linux/lib/sockio-c.o \
        -L.  -Wl,-Map raw_pre_gcl_map   -lpre_gcl -lm  -lgmp
/usr/local/lib/libbfd.a /usr/local/lib/libiberty.a -lreadline -lncurses
-lc -lgclp /home/page/axiom.build-improvements/obj/linux/lib/libspad.a
cat init_pre_gcl.lsp.tmp | sed \
        -e "s#@LI-VERS@#(`cat ../majvers`.`cat ../minvers`) `date`#1" \
        -e "s#@LI-EXTVERS@#`cat ../minvers | cut -f2 -d.`#1" \
        -e "s#@LI-MINVERS@#`cat ../minvers | cut -f1 -d.`#1" \
        -e "s#@LI-MAJVERS@#`cat ../majvers`#1" \
        -e "s#@LI-CC@#\"gcc -c -Wall -DVOL=volatile -fsigned-char =
-pipe
\"#1" \
        -e "s#@LI-LD@#\"gcc -o \"#1" \
        -e "s#@LI-LD-LIBS@#\"   -lpre_gcl -lm  -lgmp
/usr/local/lib/libbfd.a /usr/local/lib/libiberty.a -lreadline -lncurses
-lc -lgclp /home/page/axiom.build-improvements/obj/linux/lib/libspad.a
\"#1" \
        -e "s#@LI-OPT-THREE@#\"-O3 -fomit-frame-pointer\"#1" \
        -e "s#@LI-OPT-TWO@#\"-O\"#1" \
        -e "s#@LI-INIT-LSP@#\"init_pre_gcl.lsp\"#1" >init_pre_gcl.lsp
cp init_pre_gcl.lsp foo
echo " (in-package \"USER\")(system:save-system \"saved_pre_gcl\")"
>>foo
/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/unixport/raw_pre_gc
l /home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/unixport/ -libdir
/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/ < foo
GCL (GNU Common Lisp)  April 1994  262144 pages

Unrecoverable error: NULL_OR_ON_C_STACK macro invalid.
make[5]: *** [saved_pre_gcl] Error 134
rm raw_pre_gcl init_pre_gcl.lsp
make[5]: Leaving directory
`/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/unixport'
make[4]: *** [unixport/saved_pre_gcl] Error 2
make[4]: Leaving directory
`/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre'
/bin/sh: line 1: unixport/saved_gcl: No such file or directory
make[3]: *** [gcldir] Error 127
make[3]: Leaving directory `/home/page/axiom.build-improvements/lsp'
make[2]: *** [lspdir] Error 2
make[2]: Leaving directory `/home/page/axiom.build-improvements'
make[1]: *** [do-all] Error 2
make[1]: Leaving directory `/home/page/axiom.build-improvements'
make: *** [all] Error 2

---------

axiom.developer.org is

$ uname -a
Linux axiom-developer.org 2.6.16.14-RH202rc19 #3 SMP
  Sun May 7 18:39:41 CDT 2006 i686 i686 i386 GNU/Linux

running as a shared virtual host with

$ gcc --version
gcc (GCC) 3.4.4

This is a failure during the sub-build of GCL but the cause is
not immediately clear to me.

axiom.build-improvements/lsp/gcl-2.6.8pre/config.status shows:

# ./configure  '--enable-vssize=65536*2' --enable-statsysbfd
  '--enable-maxpage=256*1024'

These options for the gcl build are different from the
axiom--main--1-patch-49 that builds successfully on this
system:

# ./configure  '--enable-vssize=65536*2' --enable-statsysbfd
  '--enable-maxpage=128*1024'

I previously reported the message "NULL_OR_ON_C_STACK macro invalid"
to Camm MacQuire when using the --enable-maxpage=256*1024 option
on this system but he was not able to suggest a solution. The
suspicion is that this has something to do with memory management
on a linux virtual host.

I will repeat the build using --enable-maxpage=128*1024. Maybe we
need a way to conveniently pass build options through ./configure
to the gcl ./configure?

If you like I can send you the full build log or other intermediate
files.

\start
Date: Tue, 8 Aug 2006 21:00:42 -0400
From: Bill Page
To: Camm Maguire
Subject: FW: [Axiom-mail] Re: noweb

Camm,

I have encountered the error message:

  NULL_OR_ON_C_STACK macro invalid

again while building gcl-2.6.8pre (contain in the current Axiom
distribution), on the axiom-developer.org shared virtual server
with option --enable-maxpage=256*1024. As before, the build of
gcl and of Axiom completes normally if I change the gclopts to
--enable-maxpage=128*1024. Tim did say that he was going to
revert to the smaller value

http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00392.html

but the current build still uses 256*1024.

I am wondering whether anything in the forth coming gcl-2.7
might help to eliminate this problem? Did you manage to "relax the
power of two constraint"?

----------

Background:

http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00396.html

> Bill, here is the problem -- Redhat 9 is apparently placing the
> stack within the first 1Gb of memory, but you are requesting this
> amount for your heap.  GCL won't (or tries not to) allow the head
> to overrun the stack:
>
> p/x -1073750720   /* This is my cstack address.  Just built 2.6.7 with
*/
> $1 = 0xbfffdd40   /* 256*1024 maxpages just fine*/
> (gdb) p/x 1073738356 /* here is yours */
> $2 = 0x3ffff274
> (gdb) p/x 256*1024*4096+0x8000000
> $3 = 0x48000000   /* here is the end of your requested heap */
> (gdb)
>
> In all of the machines I've looked at, this is about the worst stack
> placement I've seen.  Is this 'enterprise' or 'normal'?   I thought
> the former had a sophisticated mechanism to push the stack and the
> shared memory area as high up in memory as possible.
>
> I know of no way to change this short of getting a different Linux
> kernel, where the issue should be addressable.
>
> One thing we could do is relax the power of two constraint on
> maxpages if a lesser amount would suffice.

-------

We are currently using linux kernel 2.6.16.14. Could you explain
what you mean by "the issue should be addressable"? How could I
go about addressing it, given that this is a share virtual server?

I was wondering if it might be possible to change the
NULL_OR_ON_C_STACK macro to be something like that proposed by
Mike Thomas for Windows:

http://lists.gnu.org/archive/html/gcl-devel/2005-12/msg00091.html

Actually, it seems that for Axiom we often do need more memory.
Anything you can suggest here would be appreciated.

Regards,
Bill Page.

-----Original Message-----
From: Page, Bill [mailto:Bill Page]
Sent: Tuesday, August 08, 2006 6:43 PM
To: Gabriel Dos Reis
Cc: Bill Page; list
Subject: RE: [Axiom-mail] Re: noweb

On Tuesday, August 08, 2006 5:56 PM in axiom-mail Gaby wrote:
> ...
> I need to get this Autoconf stuff move on.
>

I think you are doing a great job! Thanks.

> Did you test build-improvements branch recently?
>

I just did:

  svn update
  ./configure
  make

on the axiom-developer.org server and got the following
build failure:

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 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 how to run the C preprocessor... gcc -E
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include

...

touch raw_pre_gcl_map
gcc -o raw_pre_gcl
/home/page/axiom.build-improvements/obj/linux/lib/cfuns-c.o
/home/page/axiom.build-improvements/obj/linux/lib/sockio-c.o \
        -L.  -Wl,-Map raw_pre_gcl_map   -lpre_gcl -lm  -lgmp
/usr/local/lib/libbfd.a /usr/local/lib/libiberty.a -lreadline -lncurses
-lc -lgclp /home/page/axiom.build-improvements/obj/linux/lib/libspad.a
cat init_pre_gcl.lsp.tmp | sed \
        -e "s#@LI-VERS@#(`cat ../majvers`.`cat ../minvers`) `date`#1" \
        -e "s#@LI-EXTVERS@#`cat ../minvers | cut -f2 -d.`#1" \
        -e "s#@LI-MINVERS@#`cat ../minvers | cut -f1 -d.`#1" \
        -e "s#@LI-MAJVERS@#`cat ../majvers`#1" \
        -e "s#@LI-CC@#\"gcc -c -Wall -DVOL=volatile -fsigned-char =
-pipe
\"#1" \
        -e "s#@LI-LD@#\"gcc -o \"#1" \
        -e "s#@LI-LD-LIBS@#\"   -lpre_gcl -lm  -lgmp
/usr/local/lib/libbfd.a /usr/local/lib/libiberty.a -lreadline -lncurses
-lc -lgclp /home/page/axiom.build-improvements/obj/linux/lib/libspad.a
\"#1" \
        -e "s#@LI-OPT-THREE@#\"-O3 -fomit-frame-pointer\"#1" \
        -e "s#@LI-OPT-TWO@#\"-O\"#1" \
        -e "s#@LI-INIT-LSP@#\"init_pre_gcl.lsp\"#1" >init_pre_gcl.lsp
cp init_pre_gcl.lsp foo
echo " (in-package \"USER\")(system:save-system \"saved_pre_gcl\")"
>>foo
/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/unixport/raw_pre_gc
l /home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/unixport/ -libdir
/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/ < foo
GCL (GNU Common Lisp)  April 1994  262144 pages

Unrecoverable error: NULL_OR_ON_C_STACK macro invalid.
make[5]: *** [saved_pre_gcl] Error 134
rm raw_pre_gcl init_pre_gcl.lsp
make[5]: Leaving directory
`/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/unixport'
make[4]: *** [unixport/saved_pre_gcl] Error 2
make[4]: Leaving directory
`/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre'
/bin/sh: line 1: unixport/saved_gcl: No such file or directory
make[3]: *** [gcldir] Error 127
make[3]: Leaving directory `/home/page/axiom.build-improvements/lsp'
make[2]: *** [lspdir] Error 2
make[2]: Leaving directory `/home/page/axiom.build-improvements'
make[1]: *** [do-all] Error 2
make[1]: Leaving directory `/home/page/axiom.build-improvements'
make: *** [all] Error 2

---------

axiom.developer.org is

$ uname -a
Linux axiom-developer.org 2.6.16.14-RH202rc19 #3 SMP
  Sun May 7 18:39:41 CDT 2006 i686 i686 i386 GNU/Linux

running as a shared virtual host with

$ gcc --version
gcc (GCC) 3.4.4

This is a failure during the sub-build of GCL but the cause is
not immediately clear to me.

axiom.build-improvements/lsp/gcl-2.6.8pre/config.status shows:

# ./configure  '--enable-vssize=65536*2' --enable-statsysbfd
  '--enable-maxpage=256*1024'

These options for the gcl build are different from the
axiom--main--1-patch-49 that builds successfully on this
system:

# ./configure  '--enable-vssize=65536*2' --enable-statsysbfd
  '--enable-maxpage=128*1024'

I previously reported the message "NULL_OR_ON_C_STACK macro invalid"
to Camm MacQuire when using the --enable-maxpage=256*1024 option
on this system but he was not able to suggest a solution. The
suspicion is that this has something to do with memory management
on a linux virtual host.

I will repeat the build using --enable-maxpage=128*1024. Maybe we
need a way to conveniently pass build options through ./configure
to the gcl ./configure?

If you like I can send you the full build log or other intermediate
files.

\start
Date: 09 Aug 2006 04:34:46 +0200
From: Gabriel Dos Reis
To: list
Subject: boxup script

The script src/scripts/boxup reads:

   [21:30]% cat axiom.silver/src/scripts/boxup
   cp /usr/local/bin/boxhead $1.pamphlet
   cat $1 >>$1.pamphlet
   cat /usr/local/bin/boxtail >>$1.pamphlet
   mv $1 $1.org
   document $1
   echo diffing $1 $1.org
   diff $1 $1.org
   rm -f $1.dvi
   echo if files do not differ it is safe to rm $1 $1.org

Given the current makefiles, there is no way a "normal" install of
Axiom will put the files named boxhead and boxtail in /usr/local/bin.
I must therefore assume that that script has not been run recently.
Furthemore, boxhead and boxtail really are not scripts; there are
LaTeX fragments.  Their logical directory should be something like a
"share" directory.

I'll implement that -- unless people believe that boxup and friends
may just disappear...

\start
Date: Tue, 8 Aug 2006 23:14:50 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: boxup script

Gaby,

On Tuesday, August 08, 2006 10:35 PM you wrote:

> ...
> I'll implement that -- unless people believe that boxup and
> friends may just disappear...
>

I think they should disappear. This is just a way of making
a template *.spad.pamphlet file from a *.spad file. They seem
completely obsolete to me.

\start
Date: 09 Aug 2006 05:51:26 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: boxup script

Bill Page writes:

| Gaby, 
| 
| On Tuesday, August 08, 2006 10:35 PM you wrote:
| 
| > ... 
| > I'll implement that -- unless people believe that boxup and
| > friends may just disappear...
| > 
| 
| I think they should disappear. This is just a way of making
| a template *.spad.pamphlet file from a *.spad file. They seem
| completely obsolete to me.

OK.  I'm in the middle of implementing the convervative solution.  
I'll go with your suggestion.

\start
Date: Wed, 9 Aug 2006 13:44:24 -0400
From: Bill Page
To: list
Subject: Maxima on MathAction and Sage

Axiom Developers;

After being inspired by the Sage code for their interface to
Maxima, I (finally!) got around to implementing a simple
interface for Maxima on Axiom Wiki and the Axiom Portal.
See:

http://wiki.axiom-developer.org/SandBoxMaxima

This is just a first attempt. Please give it a try. Create
a few more new SandBox test pages, etc.

I would like to do better but I need some help from
knowledgeable Maxima people about how to better handle the
input and output.

Your comments and questions would be greatly appreciated.

BTW, with the help of William Stein (the primary developer
of Sage) I am also working on a similar interface between
MathAction and Sage. So you will soon also be able to run
Sage sessions via:

  \begin{sage}
   ...
  \end{sage}

http://modular.math.washington.edu/sage

This will provide access to several more open source
mathematics packages including GAP, Maxima, Singular,
PARI, MWRANK, NTL and others. Unlike MathAction (which
merely provides a collaborative web-based user interface),
Sage also allows you to exchange many computer algebra
data structures (e.g. polynomials) between these packages.

Currently Sage is running on the axiom-developer.org server
but we still have some problems with clisp and Maxima. clisp
refuses to run on this server - always returning an "out of
memory error" no matter what I try. William Stein explained
how to install Sage with Maxima built with GCL - which works
fine on this server, however there are now a few interface
problems between Sage and Maxima that may be due to the
different lisp platform. I expect we (William at least :)
can resolve this fairly easily.

Stay tuned.

\start
Date: 09 Aug 2006 22:04:55 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Building Axiom with unmodified noweb

Ralf Hemmecke writes:

[...]

| The 'src/scripts/document' should get the TANGLE and WEAVE variables
| from Makefile.pamphlet or the configure script. Gaby, is the latter
| possible?

Done.
document is longer installed.

Now, I'm on making noweb optional.  But, I understandd from various
postings that Tim added a patch to make noweb more lenient about Axiom
source files.  I'm inclined to think that is a bug in Axiom.  Could
anyone familiar with the issue makes a summary for me?

\start
Date: Wed, 9 Aug 2006 16:05:44 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Maxima on MathAction and Sage

Alfredo,

On Wednesday, August 09, 2006 2:32 PM you wrote:

> ... Cant wait to put this in Doyen, if it is
> possible to start working on this, let me know.
>

If you have a test version of Doyen with Maxima installed,
you should be able to add the new interface scripts very
easily. I will update the MathAction darcs repository later
today and you can pull it from there. I will be sure to post
the Maxima changes in a separate patch so you can pick it
separately if you wish. Note: You will also see some changes
to other files in both LatexWiki and ZWiki product directories
since my last commit. I hope applying these changes doesn't
cause you much trouble... :)

I will let you know when the repository is updated.

BTW, have you given any thought to including Sage on the
Doyen CD?

Regards,
Bill Page.

> > See:
> >
> > http://wiki.axiom-developer.org/SandBoxMaxima
> >

\start
Date: Wed, 09 Aug 2006 22:52:56 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Building Axiom with unmodified noweb

Hi Gaby,

I've once made a test and Bill confirmed my findings...

http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00262.html

It seems that there is only ONE line in Axiom that still needs the noweb 
  patch. I think we should simple add an @ to escape the << and get rid 
of the noweb sources.
Tim seems to want the following "non-noweb convention".

   If
   ... <<Blah>> ...
   appears in the text and the chunk name <<Blah>> is not defined,
   then noweb should output "<<Blah>>" literally.

That is not Norman Ramsey's definition, he doesn't like it and he even 
presented an awk-script that can be used as a filter to achieve that 
behaviour.

We should get rid of this convention and we should not have need for the 
awk script. I would rather tell to people that they should write 
according to noweb's definition than introducing a slight modification 
like given through the above convention. (Where should we document that 
anyway?)

\start
Date: 09 Aug 2006 19:21:08 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: FW: [Axiom-mail] Re: noweb

Greetings!

Bill Page writes:

> Camm,
> 
> I have encountered the error message:
> 
>   NULL_OR_ON_C_STACK macro invalid
> 
> again while building gcl-2.6.8pre (contain in the current Axiom
> distribution), on the axiom-developer.org shared virtual server
> with option --enable-maxpage=256*1024. As before, the build of
> gcl and of Axiom completes normally if I change the gclopts to
> --enable-maxpage=128*1024. Tim did say that he was going to
> revert to the smaller value
> 
> http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00392.html
> 
> but the current build still uses 256*1024.
> 
> I am wondering whether anything in the forth coming gcl-2.7
> might help to eliminate this problem? Did you manage to "relax the
> power of two constraint"?
> 

The power of two constraint remains in 2.7, hopefully for only a short
time.  Can I log in to look at this?

Take care,


> ----------
> 
> Background:
> 
> http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00396.html
> 
> > Bill, here is the problem -- Redhat 9 is apparently placing the
> > stack within the first 1Gb of memory, but you are requesting this
> > amount for your heap.  GCL won't (or tries not to) allow the head
> > to overrun the stack: 
> >
> > p/x -1073750720   /* This is my cstack address.  Just built 2.6.7 with
> */
> > $1 = 0xbfffdd40   /* 256*1024 maxpages just fine*/
> > (gdb) p/x 1073738356 /* here is yours */
> > $2 = 0x3ffff274
> > (gdb) p/x 256*1024*4096+0x8000000
> > $3 = 0x48000000   /* here is the end of your requested heap */
> > (gdb) 
> >
> > In all of the machines I've looked at, this is about the worst stack
> > placement I've seen.  Is this 'enterprise' or 'normal'?   I thought
> > the former had a sophisticated mechanism to push the stack and the
> > shared memory area as high up in memory as possible.
> >
> > I know of no way to change this short of getting a different Linux
> > kernel, where the issue should be addressable.
> >
> > One thing we could do is relax the power of two constraint on
> > maxpages if a lesser amount would suffice.
> 
> -------
> 
> We are currently using linux kernel 2.6.16.14. Could you explain
> what you mean by "the issue should be addressable"? How could I
> go about addressing it, given that this is a share virtual server?
> 
> I was wondering if it might be possible to change the
> NULL_OR_ON_C_STACK macro to be something like that proposed by
> Mike Thomas for Windows:
> 
> http://lists.gnu.org/archive/html/gcl-devel/2005-12/msg00091.html
> 
> Actually, it seems that for Axiom we often do need more memory.
> Anything you can suggest here would be appreciated.
> 
> Regards,
> Bill Page.
> 
> -----Original Message-----
> From: Page, Bill [mailto:Bill Page] 
> Sent: Tuesday, August 08, 2006 6:43 PM
> To: Gabriel Dos Reis
> Cc: Bill Page; list
> Subject: RE: [Axiom-mail] Re: noweb
> 
> On Tuesday, August 08, 2006 5:56 PM in axiom-mail Gaby wrote:
> > ... 
> > I need to get this Autoconf stuff move on.
> >
> 
> I think you are doing a great job! Thanks.
>  
> > Did you test build-improvements branch recently?
> > 
> 
> I just did:
> 
>   svn update
>   ./configure
>   make
> 
> on the axiom-developer.org server and got the following
> build failure:
> 
> 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 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 how to run the C preprocessor... gcc -E
> checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
> 
> ...
> 
> touch raw_pre_gcl_map
> gcc -o raw_pre_gcl
> /home/page/axiom.build-improvements/obj/linux/lib/cfuns-c.o
> /home/page/axiom.build-improvements/obj/linux/lib/sockio-c.o \
>         -L.  -Wl,-Map raw_pre_gcl_map   -lpre_gcl -lm  -lgmp
> /usr/local/lib/libbfd.a /usr/local/lib/libiberty.a -lreadline -lncurses
> -lc -lgclp /home/page/axiom.build-improvements/obj/linux/lib/libspad.a
> cat init_pre_gcl.lsp.tmp | sed \
>         -e "s#@LI-VERS@#(`cat ../majvers`.`cat ../minvers`) `date`#1" \
>         -e "s#@LI-EXTVERS@#`cat ../minvers | cut -f2 -d.`#1" \
>         -e "s#@LI-MINVERS@#`cat ../minvers | cut -f1 -d.`#1" \
>         -e "s#@LI-MAJVERS@#`cat ../majvers`#1" \
>         -e "s#@LI-CC@#\"gcc -c -Wall -DVOL=volatile -fsigned-char -pipe
> \"#1" \
>         -e "s#@LI-LD@#\"gcc -o \"#1" \
>         -e "s#@LI-LD-LIBS@#\"   -lpre_gcl -lm  -lgmp
> /usr/local/lib/libbfd.a /usr/local/lib/libiberty.a -lreadline -lncurses
> -lc -lgclp /home/page/axiom.build-improvements/obj/linux/lib/libspad.a
> \"#1" \
>         -e "s#@LI-OPT-THREE@#\"-O3 -fomit-frame-pointer\"#1" \
>         -e "s#@LI-OPT-TWO@#\"-O\"#1" \
>         -e "s#@LI-INIT-LSP@#\"init_pre_gcl.lsp\"#1" >init_pre_gcl.lsp
> cp init_pre_gcl.lsp foo
> echo " (in-package \"USER\")(system:save-system \"saved_pre_gcl\")"
> >>foo
> /home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/unixport/raw_pre_gc
> l /home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/unixport/ -libdir
> /home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/ < foo
> GCL (GNU Common Lisp)  April 1994  262144 pages
> 
> Unrecoverable error: NULL_OR_ON_C_STACK macro invalid.
> make[5]: *** [saved_pre_gcl] Error 134
> rm raw_pre_gcl init_pre_gcl.lsp
> make[5]: Leaving directory
> `/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre/unixport'
> make[4]: *** [unixport/saved_pre_gcl] Error 2
> make[4]: Leaving directory
> `/home/page/axiom.build-improvements/lsp/gcl-2.6.8pre'
> /bin/sh: line 1: unixport/saved_gcl: No such file or directory
> make[3]: *** [gcldir] Error 127
> make[3]: Leaving directory `/home/page/axiom.build-improvements/lsp'
> make[2]: *** [lspdir] Error 2
> make[2]: Leaving directory `/home/page/axiom.build-improvements'
> make[1]: *** [do-all] Error 2
> make[1]: Leaving directory `/home/page/axiom.build-improvements'
> make: *** [all] Error 2
> 
> ---------
> 
> axiom.developer.org is
> 
> $ uname -a
> Linux axiom-developer.org 2.6.16.14-RH202rc19 #3 SMP
>   Sun May 7 18:39:41 CDT 2006 i686 i686 i386 GNU/Linux
> 
> running as a shared virtual host with
> 
> $ gcc --version
> gcc (GCC) 3.4.4
> 
> This is a failure during the sub-build of GCL but the cause is
> not immediately clear to me.
> 
> axiom.build-improvements/lsp/gcl-2.6.8pre/config.status shows:
> 
> # ./configure  '--enable-vssize=65536*2' --enable-statsysbfd
>   '--enable-maxpage=256*1024'
> 
> These options for the gcl build are different from the
> axiom--main--1-patch-49 that builds successfully on this
> system:
> 
> # ./configure  '--enable-vssize=65536*2' --enable-statsysbfd
>   '--enable-maxpage=128*1024'
> 
> I previously reported the message "NULL_OR_ON_C_STACK macro invalid"
> to Camm MacQuire when using the --enable-maxpage=256*1024 option
> on this system but he was not able to suggest a solution. The
> suspicion is that this has something to do with memory management
> on a linux virtual host.
> 
> I will repeat the build using --enable-maxpage=128*1024. Maybe we
> need a way to conveniently pass build options through ./configure
> to the gcl ./configure?
> 
> If you like I can send you the full build log or other intermediate
> files.

\start
Date: Wed, 9 Aug 2006 19:46:50 -0400
From: Bill Page
To: Camm Maguire
Subject: NULL_OR_ON_C_STACK macro invalid (was: noweb)

Camm,

On Wednesday, August 09, 2006 7:21 PM you wrote:
> ...
> Bill Page wrote:
> >
> >   NULL_OR_ON_C_STACK macro invalid
> >
> > ... while building gcl-2.6.8pre (contain in the current Axiom
> > distribution), on the axiom-developer.org shared virtual server
> > with option --enable-maxpage=256*1024. As before, the build of
> > gcl and of Axiom completes normally if I change the gclopts to
> > --enable-maxpage=128*1024.
> > ... but the current build still uses 256*1024.
> >
> ...
> Can I log in to look at this?
>

Well, sure! :-) You user id 'camm' still exists on the
axiom-developer.org machine. Do you need a password reset?

\start
Date: 10 Aug 2006 04:15:22 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Building Axiom with unmodified noweb

Ralf Hemmecke writes:

| Hi Gaby,
| 
| I've once made a test and Bill confirmed my findings...
| 
| http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00262.html
| 
| It seems that there is only ONE line in Axiom that still needs the
| noweb patch. I think we should simple add an @ to escape the << and
| get rid of the noweb sources.
| Tim seems to want the following "non-noweb convention".
| 
|    If
|    ... <<Blah>> ...
|    appears in the text and the chunk name <<Blah>> is not defined,
|    then noweb should output "<<Blah>>" literally.
| 
| That is not Norman Ramsey's definition, he doesn't like it and he even
| presented an awk-script that can be used as a filter to achieve that
| behaviour.
| 
| We should get rid of this convention and we should not have need for
| the awk script. I would rather tell to people that they should write
| according to noweb's definition than introducing a slight modification
| like given through the above convention. (Where should we document
| that anyway?)

Given, your assessment, I agree that we should not have that
modification.  I don't see a compelling reason to modify the standard
noweb convention, given the only one evidence for its need so far.

Thanks!

\start
Date: Thu, 10 Aug 2006 04:04:27 -0400
From: Bill Page
To: list
Subject: FW: [SandBox Maxima] Try this

On Wednesday, August 09, 2006 2:02 PM Bob McElrath wrote:

> Use the texmacs scripts directly, and modify them...
>
> echo "integrate(x^2,x);" | maxima -p \
>
/usr/share/texmacs/TeXmacs/plugins/maxima/lisp/texmacs-maxima-5.9.2.lisp
\
>     > integral.txt
>
> Note that the texmacs inserts a lot of control characters
> that will make your xterm go goofy, so above I sent the
> output to a file and you can look at it with a text editor.
>
> We really don't want to parse maxima's ascii-art... ;)
>
> Good work!

Thanks to this wonderful suggestion the new Maxima interface
on MathAction is looking pretty good! :)

http://wiki.axiom-developer.org/SandBoxMaxima

I modified the texmacs-maxima-5.9.2.lisp code a little to emit
XML-style tags instead of the TeXmacs weird control characters.
The resulting protocol is much easier to handle in Python.

So thanks to Bob and the original authors: James Amundson and
A.G. Grozin, this was a lot easier to do than I thought. :)

Please give this a try and report any problems via IssueTracker.

\start
Date: Thu, 10 Aug 2006 02:54:11 -0700
From: Bob McElrath
To: list
Subject: Re: FW: [SandBox Maxima] Try this

Page, Bill [Bill Page] wrote:
> Thanks to this wonderful suggestion the new Maxima interface
> on MathAction is looking pretty good! :)
> 
> http://wiki.axiom-developer.org/SandBoxMaxima
> 
> I modified the texmacs-maxima-5.9.2.lisp code a little to emit
> XML-style tags instead of the TeXmacs weird control characters.
> The resulting protocol is much easier to handle in Python.
> 
> So thanks to Bob and the original authors: James Amundson and
> A.G. Grozin, this was a lot easier to do than I thought. :)
> 
> Please give this a try and report any problems via IssueTracker.

Wow it even tex' the input?  Interesting...

\start
Date: Thu, 10 Aug 2006 06:54:00 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Maxima on MathAction and Sage

Alfredo,

On Thursday, August 10, 2006 5:39 AM you wrote:
>
> On 8/9/06, Bill Page wrote:
>
> > If you have a test version of Doyen with Maxima installed,
> > you should be able to add the new interface scripts very
> > easily.
>
> I just finished installing Maxima on my test version of Doyen.
>

Great. Did you build it using GCL or Clisp?

> > Note: You will also see some changes to other files in
> > both LatexWiki and ZWiki product directories since my
> > last commit. I hope applying these changes doesn't
> > cause you much trouble... :)
>
> That is the fun part :).
>

For the time being I don't think you need any of the changes
to ZWiki. These mostly related to the new left sidebar outline
navigation which you aren't using on Doyen (at least not yet).

> > I will let you know when the repository is updated.
>

I have updated both the ZWiki and LatexWiki repositories
on MathAction:

http://wiki.axiom-developer.org/MathActionRepository

I recommend that you just start with the changes in the
LatexWiki archive. These changes should be relatively safe
and should give you the Maxima interface without much
trouble.

You should also update your stylesheet file for the
definitions used by Maxima. You can get that here:

http://wiki.axiom-developer.org/stylesheet.css

Look for the entries

#maximalabel
#maximacode
#maximaoutput
#maximainput
#maximacode pre

Let me know if you have any problems - of course there
is likely to be the usual problems with paths etc.

The changes to ZWiki have the potential to break a few things
if they are applied to a version substantially different
than what we are running on MathAction. Until/unless you want
the left sidebar thing, I think you can ignore these changes
for now.

Finally, be aware that I have not completed recently any fully
and separate install from the darcs ZWiki and LatexWiki
repositories so I am not 100% sure they will build a working
system. Be cautious. Sorry, not enough time... as usual :(
And of course, please let me know if you find something missing
from the repository.

\start
Date: Thu, 10 Aug 2006 15:38:53 +0200
From: Frithjof Schulze
To: Bill Page
Subject: Re: patches 

Bill Page wrote:

> I consider this a completely acceptable policy and I would like
> to encourage you (and others) to continue to make these changes.
> As the saying goes: Be Bold! 

I'll try. But please let me know if make changes you don't like or
consider unnecessary. I welcome all constructive critic.

\start
Date: Thu, 10 Aug 2006 16:23:02 +0200
From: Ralf Hemmecke
To: Frithjof Schulze
Subject: Re: patches

Hi Bill,

Are the modifications that Frithjof is going to make to 
http://wiki.axiom-developer.org/axiom--test--1 also sent to the 
axiom-developer mailing list so that we all can watch?

I still don't like the diff-format. So all those mathaction mails are 
actually nearly like spam to me. (But don't care to change it, it's 
currently not so frequent anyway.) If I am interested in the topic I 
just click on the link ath the bottom of the mail. (BTW, could the

   forwarded from ...

stuff be moved to the top of the mail?)

Somehow instead of
http://wiki.axiom-developer.org/HowToSubmitPatches/diff
I would like to see something like an ediff in emacs. Can that be easily 
achieved?

On 08/10/2006 03:38 PM, Frithjof Schulze wrote:
> Bill Page wrote:
> 
>> I consider this a completely acceptable policy and I would like
>> to encourage you (and others) to continue to make these changes.
>> As the saying goes: Be Bold! 
> 
> I'll try. But please let me know if make changes you don't like or
> consider unnecessary. I welcome all constructive critic.

\start
Date: 10 Aug 2006 11:50:34 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

Greetings!

I have a trial version there now which eliminates the power of two
constraint.  Am testing locally before committing, but you might want
to too.  The issue here, as you recall, is that your machine for some
reason is placing the stack below the 0x40000000 mark.  I could get a
build with 220000 maximum pages (which is what is in my home right
now), but this might leave a very thin C stack.  I also need to check
that C stack limiting code is working, lest your heap and your C stack
collide.

Take care,

Bill Page writes:

> Camm, 
> 
> On Wednesday, August 09, 2006 7:21 PM you wrote:
> > ...
> > Bill Page wrote:
> > > 
> > >   NULL_OR_ON_C_STACK macro invalid
> > > 
> > > ... while building gcl-2.6.8pre (contain in the current Axiom
> > > distribution), on the axiom-developer.org shared virtual server
> > > with option --enable-maxpage=256*1024. As before, the build of
> > > gcl and of Axiom completes normally if I change the gclopts to
> > > --enable-maxpage=128*1024.
> > > ... but the current build still uses 256*1024.
> > > 
> > ...
> > Can I log in to look at this?
> > 
> 
> Well, sure! :-) You user id 'camm' still exists on the
> axiom-developer.org machine. Do you need a password reset?

\start
Date: Thu, 10 Aug 2006 13:08:58 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: patches

On Thursday, August 10, 2006 10:23 AM Ralf Hemmecke wrote:
>
> Are the modifications that Frithjof is going to make to
> http://wiki.axiom-developer.org/axiom--test--1 also sent
> to the axiom-developer mailing list so that we all can
> watch?

Actually, the up-to-date book volumes are in

http://wiki.axiom-developer.org/book--main--1

But no the modifications to these files will not be
automatically sent to the axiom-developer list - for two
reasons:

First. The Axiom Wiki is no longer directly connected to the
axiom-developer list. The wiki used to be subscribed to
the axiom-developer list so that all postings and changes
on the wiki were distributed to all subscribers to axiom-
developer. Doing this has always been a bit controversial...
The Wiki is capable of operating like an email list without
connection to axiom-developer. Starting a few months ago
(when we had some technical problems with the Savannah email
lists) I copied all the current axiom-developer subscribers
as subscribers to the Axiom Wiki and then I disabled the
Axiom Wiki subscription to axiom-developer. Since that time,
those people who still receive notices of changes on Axiom
Wiki are receiving these because they were automatically
subscribed to Axiom Wiki at that time.

Because the axiom-developer list and Axiom Wiki are no
longer directly connected, it is possible for a subscriber
to unsubscribe and for new users to subscribe to the wiki
without changing their subscription to axiom-developer.
Just click on the 'Subscribe' link in the This Site box
at the upper right corner of FrontPage

http://wiki.axiom-developer.org

Or at the right of the top menu line on other pages.

Second reason.

http://wiki.axiom-developer.org/book--main--1

is a "sub-folder wiki" of the Axiom Wiki. This means that
although it is contained in Axiom Wiki, it has it's own subset
of wiki pages - just like a folder or subdirectory. In this
case it has one "wiki page" per pamphlet file i.e. one for
each book volume. At the present time (this feature could
change in the future), sub-folder wikis behave almost
independently of the wiki in which they are contained. In
particular sub-folder wikis do not inherit the subscriber
lists of their container.

http://wiki.axiom-developer.org/axiom--test--1 is also a sub-
folder wiki. In fact it consists of several nested sub-folders
corresponding to the directory structure of the Axiom source
code distribution. Subscription to each of these sub-folders
is independent of the others.

So to receive notices of changes made by Frithjof and others
to the volumes at

http://wiki.axiom-developer.org/book--main--1

It is necessary to click the subscribe link at the right of
the top menu line.

>
> I still don't like the diff-format. So all those mathaction mails
> are actually nearly like spam to me.

'diff -au' format is pretty near universal isn't it?

> (But don't care to change it, it's currently not so frequent
> anyway.)

If it gets to be too much you can control your own subscriptions
as I described above.

> If I am interested in the topic I just click on the link at
> the bottom of the mail. (BTW, could the
>
>    forwarded from ...
>
> stuff be moved to the top of the mail?)

This is easily changed.

Do you think the first line of the email, e.g.

  Changes http://wiki.axiom-developer.org/FrontPage/diff

should be removed? Do you like the 'diff' web page any
better than the diff content of the email? Should both
the forwarded from and diff links be at the top of the
email?

>
> Somehow instead of
> http://wiki.axiom-developer.org/HowToSubmitPatches/diff
> I would like to see something like an ediff in emacs.
> Can that be easily achieved?
>

I don't know anything about ediff. Do you have some
examples?

The contents of the diff web page is generated by a
function within the Python 'differ' library module which
is quite flexible. It is possible that it might be able
to generate 'ediff' format - in that case the change
would be quite easy. But email is more limiting than
web-page or emacs the screen, so I think we have to choose
carefully.

\start
Date: Thu, 10 Aug 2006 13:34:23 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Maxima on MathAction and Sage

Alfredo,

I see you are using the Clisp verision of Maxima.
I suppose that might create some minor differences.

In my experience the error message "Maxima output parse
error" is most generated if for some reason the routine
'renderMaxima' in 'maximaWrapper.py' is not able to split
the maxima output into the same number of sections as
occurred in the input. Recall that the input consists of
a series of

  batch("section1.max");
  batch("section2.max");

commands. When maxima executes these commands that result
is a series of <prompt> ... </prompt> output that serves to
delimit the output. After some experimentation I determined that
the follow regular expression worked reliably for me:

outputSplit = '<prompt>.*</prompt>\nbatching #p.*\n'

Maybe the output is subtley different from Clisp? I find writing
reliable Python regular expressions to be very tediouos.
Comparing your output below to this pattern:

<prompt>(\mathrm{\$\%i}1)
</prompt><latex>\mbox{\tt\red(\mathrm{\$\%o1}) \black}4</latex>

It looks like this splitting might fail because there is no \n
after </prompt>. You could try changing the regular expression
to something like this:

outputSplit = '<prompt>.*</prompt>\s*batching #p.*\n'

Note: the output string "batching" is apparently generated
by maxima when it processes a batch() command. The only reason
it is part of this patter is so that it can be conveniently
ignored - just some Python trickery... :)

If you could create a test.input file containing several

  batch("section1.max");
  batch("section2.max");

commands containing other maxima commands and then run

  maxima < test.input >test.output

then send me the file, I will try to help you debug this.

Regards,
Bill Page.

> -----Original Message-----
> From: Alfredo Portes [mailto:Alfredo Portes]
> Sent: Thursday, August 10, 2006 11:55 AM
> To: Bill Page
> Subject: Re: Maxima on MathAction and Sage
>
> Hi Bill,
>
> I am having a little issue with the Maxima output, just getting:
>
> Maxima output parse error!
>
> You can see the output here: http://doyen.sytes.net/Doyen/SandBox
>
> I run the command manually, and get the right output.
>
> echo "2+2;" | /usr/bin/maxima -p
> /var/lib/zope/Products/LatexWiki/mathaction-maxima-5.9.3.lisp
> >output.txt
>
> output.txt
>
> <maxima>
> Maxima 5.9.3.99rc2 http://maxima.sourceforge.net
> Using Lisp CLISP 2.39 (2006-07-16)
> Distributed under the GNU Public License. See the file COPYING.
> Dedicated to the memory of William Schelter.
> This is a development version of Maxima. The function bug_report()
> provides bug reporting information.
> <prompt>(\mathrm{\$\%i}1)
> </prompt><latex>\mbox{\tt\red(\mathrm{\$\%o1}) \black}4</latex>
> <prompt>(\mathrm{\$\%i}2) </prompt></maxima>
>
> Any advice I would appreciate it,

\start
Date: 10 Aug 2006 13:59:03 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)

Greetings!  FYI, just committed the removal of the power of 2
constraint on maxpage in both cvs head and version 2.6.8pre.

Take care,

Bill Page writes:

> Camm, 
> 
> On Wednesday, August 09, 2006 7:21 PM you wrote:
> > ...
> > Bill Page wrote:
> > > 
> > >   NULL_OR_ON_C_STACK macro invalid
> > > 
> > > ... while building gcl-2.6.8pre (contain in the current Axiom
> > > distribution), on the axiom-developer.org shared virtual server
> > > with option --enable-maxpage=256*1024. As before, the build of
> > > gcl and of Axiom completes normally if I change the gclopts to
> > > --enable-maxpage=128*1024.
> > > ... but the current build still uses 256*1024.
> > > 
> > ...
> > Can I log in to look at this?
> > 
> 
> Well, sure! :-) You user id 'camm' still exists on the
> axiom-developer.org machine. Do you need a password reset?

\start
Date: 10 Aug 2006 20:20:37 +0200
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)

Camm Maguire writes:

| Greetings!  FYI, just committed the removal of the power of 2
| constraint on maxpage in both cvs head and version 2.6.8pre.

That is good news!

\start
Date: Thu, 10 Aug 2006 14:15:12 -0500
From: Tim Daly
To: Bertfried Fauser
Subject: ordering

> I have experimented with the AXIOM Groebner bases package and was somehoe
> wondering how to define an ordering and how to define elimination orders.
> In the code I couldn't find any hint how to impose these conditions and
> groebner() takes as input only a list of polynomials, not an order
> function and not a list of to be kept or elimated variables?

There are various kinds of polynomials used with Groebner.
If memory serves me you can specify the order in DMP or HDMP.

\start
Date: Thu, 10 Aug 2006 14:47:59 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: lattice

> I am quite sure that all the hundreds of targets in Lattice.pamphlet 
> follow exactly the same pattern. Shouldn't we have a short program that 
> replaces 40,000 Makefile lines???

Two points: 

Point 1: Lattice is not used. It is there so that we can create the
lattice of the algebra code for documentation purposes. The new sed/awk
based version does not contain that information.

Point 2: Make is a rule-based programming language. Each rule 
specifies a particular situation and then specifies the MINIMUM
amount of work necessary to rebuild the system. The rules are 
written to optimize the most frequent case. The most frequent
case is changing a file and rebuilding the system.

Perl/sed/awk scripts tend to minimize the number of places you need to 
change to modify the way the system is built. Reducing the rules
to perl scripts optimizes this, the least most frequent action and
sacrifices the most frequent case.

Bill and I had this discussion years ago. The algebra Makefile is
no longer 40k lines of rules and uses sed/awk scripts.

\start
Date: Thu, 10 Aug 2006 16:04:32 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: NULL_OR_ON_C_STACK macro invalid (was: noweb)

Camm,

On Thursday, August 10, 2006 1:59 PM you wrote:
>
> Greetings!  FYI, just committed the removal of the
> power of 2 constraint on maxpage in both cvs head and
> version 2.6.8pre.
>

Thanks for looking into this.

I just grabbed 2.6.8pre from cvs into a temp directory and
created a replacement tarball for the Axiom build, thus:

  cd /home/page/temp-dir
  export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
  cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
  tar czvf gcl-2.6.8pre.tgz gcl-2.6.8pre
  cd /home/page/axiom.build-improvements/zips
  mv gcl-2.6.8pre.tgz old_gcl-2.6.8pre.tgz
  mv /home/page/temp-dir/gcl-2.6.8pre.tgz .
  cd /home/page/axiom.build-improvements

I edited the GCLOPTS in Makefile from
  --enable-maxpage=256*1024
to
  --enable-maxpage=196*1024
resulting in

  GCLOPTS=--enable-vssize=65536*2 --enable-statsysbfd \
          --enable-maxpage=196*1024

in the default build for Axiom Silver build-improvements branch:

  make clean
  ./configure | tee build.log
  make 2>&1 | tee -a build.log

The build proceeded much further than before - the GCL sub-build
finished without errors - yeah! But the build of Axiom failed
with the following error message quite far along into the
interpsys build phase :(

  error: conflicting types for 'MYCOMBINE'

This is not something I have seen before. This same source builds
fine with the older version of 2.6.8pre and 128*256.

Here is the tail end of the log. I can send you the rest if you
like.

Please let me know how I can help.

Regards,
Bill Page

----------

...
25 making /home/page/axiom.build-improvements/int/interp/cfuns.lisp from
/home/page/axiom.build-improvements/src/interp/cfuns.lisp.pamphlet
24 making /home/page/axiom.build-improvements/obj/linux/interp/cfuns.o
from /home/page/axiom.build-improvements/int/interp/cfuns.lisp
/home/page/axiom.build-improvements/obj/linux/interp/cfuns.c:5238:
error: conflicting types for 'MYCOMBINE'
/home/page/axiom.build-improvements/obj/linux/interp/cfuns.h:15: error:
previous declaration of 'MYCOMBINE' was here
/home/page/axiom.build-improvements/obj/linux/interp/cfuns.c:5238:
error: conflicting types for 'MYCOMBINE'
/home/page/axiom.build-improvements/obj/linux/interp/cfuns.h:15: error:
previous declaration of 'MYCOMBINE' was here
make[4]: ***
[/home/page/axiom.build-improvements/obj/linux/interp/cfuns.o] Error 255
make[4]: Leaving directory
`/home/page/axiom.build-improvements/src/interp'
make[3]: *** [interpdir] Error 2
make[3]: Leaving directory `/home/page/axiom.build-improvements/src'
make[2]: *** [srcdir] Error 2
make[2]: Leaving directory `/home/page/axiom.build-improvements'
make[1]: *** [do-all] Error 2
make[1]: Leaving directory `/home/page/axiom.build-improvements'
make: *** [all] Error 2
[page@axiom-developer axiom.build-improvements]$

\start
Date: Thu, 10 Aug 2006 16:09:03 -0400
From: Bill Page
To: Bill Page
Subject: RE: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Camm Maguire

On Thursday, August 10, 2006 4:05 PM I wrote:

> ...
> I edited the GCLOPTS in Makefile from
>   --enable-maxpage=256*1024
> to
>   --enable-maxpage=196*1024
> resulting in
>
>   GCLOPTS=--enable-vssize=65536*2 --enable-statsysbfd \
>           --enable-maxpage=196*1024
>

Of course what I really and meant to write was:

  I edited the GCLOPTS in Makefile.pamphlet from
    --enable-maxpage=256*1024
  to
    --enable-maxpage=196*1024
  ...

\start
Date: Thu, 10 Aug 2006 22:28:05 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: patches

Hello

> Actually, the up-to-date book volumes are in
> 
> http://wiki.axiom-developer.org/book--main--1

I hope this book--main--1 and the tla archive are synchronised. 
Otherwise there will be again confusion.

And why don't other people give there opinion about whether to have two 
projects like Gold and Silver (that basically contain the sources to 
build Axiom) and that book--main--1 stuff which at the moment has 
approximately empty intersection with Gold/Silver.

I strongly opt for just ONE archive. The book project should live in the
src/doc directory of the Gold/Silver sources. Otherwise we are speaking 
about Axiom sources and exclude the Axiom book. That is completely 
counter-intuitive. Please keep/make it simple.

>> I still don't like the diff-format. So all those mathaction mails
>> are actually nearly like spam to me.
> 
> 'diff -au' format is pretty near universal isn't it?

I am not a computer. I still believe that I am human. ;-)

> Do you think the first line of the email, e.g.
> 
>   Changes http://wiki.axiom-developer.org/FrontPage/diff
> 
> should be removed?

No.

> Do you like the 'diff' web page any better than the diff content
 > of the email?

Well, at least it is red an green. I get the plus'es and minus'es more 
easily. But still some ediff-like page would be even better.

> Should both the forwarded from and diff links be at the top of the
> email?

I would prefer it.

>> Somehow instead of
>> http://wiki.axiom-developer.org/HowToSubmitPatches/diff
>> I would like to see something like an ediff in emacs.
>> Can that be easily achieved?

> I don't know anything about ediff. Do you have some
> examples?

I don't think that ediff is a special format. I would say, it is just a 
nice way to show the differences of two files.

Just take a text file a.txt copy it to b.txt and make a few 
modifications to b.txt. Then start emacs via

emacs --eval '(ediff-files "a.txt" "b.txt")'

Or use Eclipse, add the subclipse plug-in, add some SVN repository (for 
example, silver/branches/build-improvements), check out the sources, 
then right-click on a file and go to  "Compare With"-> Revision.
(You can probably also do that with standard Eclipse and an CVS repository.)

\start
Date: 10 Aug 2006 22:41:13 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: patches

Ralf Hemmecke writes:

[...]

| I strongly opt for just ONE archive. The book project should live in the
| src/doc directory of the Gold/Silver sources. Otherwise we are
| speaking about Axiom sources and exclude the Axiom book.

I agree.  I'm a bit disappointed that we don't branch our
experiements/works from a single "referential" source.

\start
Date: Thu, 10 Aug 2006 16:52:14 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: patches

Gaby, Ralf,

On Thursday, August 10, 2006 4:41 PM Gaby wrote:
>
> Ralf Hemmecke writes:
>
> | I strongly opt for just ONE archive. The book project
> | should live in the src/doc directory of the Gold/Silver
> | sources. Otherwise we are speaking about Axiom sources
> | and exclude the Axiom book.
>
> I agree.  I'm a bit disappointed that we don't branch our
> experiements/works from a single "referential" source.
>

I agree too. As I explained in an earlier email, on Tuesday
I updated the 'bookvol1' and 'ComputerTutorial' pamphlets in
book--main--1 on the Axiom Wiki directly from the src/doc
directory of the Silver branch. Then I applied the patches
supplied by Frithjof Schulze. So now these files on the wiki
are ready for online editing. Later we will merge these back
to Silver and then from Silver to gold. Isn't that how it's
supposed to work?

Since I don't know the status of the tla archive, I am ignoring
it for now until Tim can say how it's contents relate to Gold
and Silver.

\start
Date: Thu, 10 Aug 2006 18:16:42 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Maxima on MathAction and Sage

Alfredo,

Yes, the \$ seems to be an artifact of Clisp or of the slightly
newer version of Maxima that you are using. I don't think that
your test necessarily demonstrates that this is the cause of the
current problem but it is something that you will have to deal
with later.

The test that I would like you to do is the follows:

Set up 3 text files like this:

$ cat xxx.max
1+1;
sin(x)^2;
---

$ cat yyy.max
integrate(sin(x),x);
---

$ cat max.in
batch("xxx.max");
batch("yyy.max");
batch("xxx.max");
quit();
---

Then run maxima like this:

$ /usr/local/bin/maxima \
   -p /var/zope/Products/LatexWiki/mathaction-maxima-5.9.3.lisp \
      < max.in > max.out

(modifying the paths appropriately).

Then send me the contents of the file 'max.out'

-------

These regexp either have to match *exactly* the prompt codes
that maxima sends or else you have to very carefully choose the
parts that are variable.

In the case of the \$ sequence in your example, I think that
is more likely to affect another regexp

    maximaOutPattern = re.compile(
        #r'<latex>.*?black\}(.*?)</latex>'              #1 LaTeX
        r'<latex>\\mbox{\\tt\\red\(\\mathrm{\\%(i\d+)}\)
\\black}(.*?)</latex>|'   #1 #2 Input
        r'<latex>\\mbox{\\tt\\red\(\\mathrm{\\%(o\d+)}\)
\\black}(.*?)</latex>|'   #3 #4 Output
        r'stdin:((?:.(?!<latex>))*.)',  #5 Other stuff
        reConsts)

This one is in ReplaceInlineMaxima.py. It's purpose is to classify
the contents of <latex> ... </latex> tags as either "input" or
"output" and to handle error messages. Note especially the

  \\mathrm{\\%

sequence which appears to differ from your results (no \$).
When reading Python string constants remember that you may have
to escape certain characters - in this case \, so \\ really
matches on one literal \ character.

So if \$ is present you may need to write:

  \\mathrm{\\\$\\%

You end up with 3 \\\ because you need 2 \\ to represent one \
and you need also to escape the $ special character.

Getting all this right can give you a headache... :-)

Regards,
Bill Page.
-------

On Thursday, August 10, 2006 5:17 PM Alfredo Portes wrote:

> Bill,
>
> I hope this was the right test to do. On my box this is the
> output of passing  file with three commands to maxima and
> using the lisp file:


	<maxima>
	Maxima 5.9.3.99rc2 http://maxima.sourceforge.net
	Using Lisp CLISP 2.39 (2006-07-16)
	Distributed under the GNU Public License. See the file COPYING.
	Dedicated to the memory of William Schelter.
	This is a development version of Maxima. The function
bug_report()
	provides bug reporting information.
	<prompt>(\mathrm{\$\%i}1)
</prompt><latex>\mbox{\tt\red(\mathrm{\$\%o1}) \black}4</latex>
	<prompt>(\mathrm{\$\%i}2)
</prompt><latex>\mbox{\tt\red(\mathrm{\$\%o2}) \black}234310</latex>
	<prompt>(\mathrm{\$\%i}3)
</prompt><latex>\mbox{\tt\red(\mathrm{\$\%o3}) \black}625</latex>
	<prompt>(\mathrm{\$\%i}4) </prompt></maxima>


> On axiom-developer running the same command on my directory is:


	<maxima>
	Maxima 5.9.3 http://maxima.sourceforge.net
	Using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka GCL)
	Distributed under the GNU Public License. See the file COPYING.
	Dedicated to the memory of William Schelter.
	This is a development version of Maxima. The function
bug_report()
	provides bug reporting information.
	<prompt>(\mathrm{\%i}1)
</prompt><latex>\mbox{\tt\red(\mathrm{\%o1}) \black}4</latex>
	<prompt>(\mathrm{\%i}2)
</prompt><latex>\mbox{\tt\red(\mathrm{\%o2}) \black}234310</latex>
	<prompt>(\mathrm{\%i}3)
</prompt><latex>\mbox{\tt\red(\mathrm{\%o3}) \black}625</latex>
	<prompt>(\mathrm{\%i}4) </prompt></maxima>


> The "\$\" appears only on my installation of maxima. I do
> not know if this matters.
>
> Please let me know, if not I will continue trying to look
> for a regex that works.


\start
Date: Thu, 10 Aug 2006 19:02:49 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Maxima on MathAction and Sage

Alfredo,

On Thursday, August 10, 2006 6:47 PM you wrote:

> Thanks Bill. I will do the testing like you suggested
> me. I wonder if I could install the same version of
> maxima you have on axiom-developer.

Installing the same version might simplify things but
you probably wouldn't learn as much ;) It all depends on
your frustration budget...

> Would I have to compile from source?

Installing Maxima using GCL in the Doyen CD environment
should be dead simple since you already have Axiom installed
and running with GCL. Maxima uses the Ansi common lisp mode
of GCL but Axiom does not so you have to re-build GCL with
the option

  --anable-ansi

>From the root of your Axiom source distribution go to

  $ cd lsp/gcl-2.6.8pre

Then rebuild GCL like this:

  $ make clean
  $ ./configure --enable-ansi
  $ make

Installing it will put a copy in /usr/local/bin

  $ make install

Then download the sources for Maxima 5.9.3 from the Maxima
web site. Untar it and then build Maxima like this:

  $ cd ~/maxima-5.9.3
  $ ./configure --with-gcl
  $ make
  $ make install

Everything should go fine.

\start
Date: Fri, 11 Aug 2006 01:56:56 +0200
From: Gregory Vanuxem
To: list
Subject: lsp/Makefile.pamphlet reorganisation

Hello,

The lsp/Makefile.pamphlet file needs a reorganisation. You can quickly
read the dvi and you'll see that nearly all code chunks that patches gcl
are in subsubsections of the section "Gnu Common Lisp 2.5.2" and that
the "gcl-version stanzas" (definition of targets) are in subsections of
this section. If you want I can reorganise it but there are two
important things: first, the silver branch is moving to autotools so
Gaby or other will probably work on it and so it's, perhaps, preferable
to reorganise it later, second, if I modify it I need to know how to
restructure it.

Greg

PS : I don't plan to add documentation, just reorganise it.

\start
Date: 11 Aug 2006 03:08:34 +0200
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: lsp/Makefile.pamphlet reorganisation

Gregory Vanuxem writes:

| Hello,
|
| The lsp/Makefile.pamphlet file needs a reorganisation. You can quickly
| read the dvi and you'll see that nearly all code chunks that patches gcl
| are in subsubsections of the section "Gnu Common Lisp 2.5.2" and that
| the "gcl-version stanzas" (definition of targets) are in subsections of
| this section. If you want I can reorganise it but there are two
| important things: first, the silver branch is moving to autotools so
| Gaby or other will probably work on it and so it's, perhaps, preferable
| to reorganise it later, second, if I modify it I need to know how to
| restructure it.

Parts of my current work touch that area, but I definitely welcome
additional brains and hands :-)  Just let me know what your plans are.

Mine is to first get Autoconf in, then gradually move to Automake.
We should also get rid of the old GCL build stanzas.
If possible, have the work on the build-improvements branch so that we
don't have too many conflict when merging.
One of the thing to do is to get rid of the direct usage of OBJ, MNT,
SYS in the make files.  We should be able to abstract over those
implementations details, have the directories defined once and used
everywhere.  In the near term, we will have the following structure in
the build directory:

    top-level-build-directory/
       build/
          scripts/
          $build                # i686-pc-linux-gnu for example
            bin/
            lib/
            share/
       target/                  # staging directory for DESTDIR
          $target               # x86_64-unknown-linux for example
             bin/
             lib/
             share/
             ...

I have a patch for "optional build of noweb"; tests are running.
Next will be to have "optional build of GCL".
Then. we will get to the monsters.

BTW, I hate to have to wait for hours watching Axioms build "serialy",
with no possibility to have "parallel" builds.  That sucks. :-(

\start
Date: 11 Aug 2006 03:28:44 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: lattice

Tim Daly writes:

| > I am quite sure that all the hundreds of targets in Lattice.pamphlet 
| > follow exactly the same pattern. Shouldn't we have a short program that 
| > replaces 40,000 Makefile lines???
| 
| Two points: 
| 
| Point 1: Lattice is not used. It is there so that we can create the
| lattice of the algebra code for documentation purposes. The new sed/awk
| based version does not contain that information.
| 
| Point 2: Make is a rule-based programming language. Each rule 
| specifies a particular situation and then specifies the MINIMUM
| amount of work necessary to rebuild the system. The rules are 
| written to optimize the most frequent case. The most frequent
| case is changing a file and rebuilding the system.

Lattice.pampphlet is unimpressive.  There ought to be a way to
automate the a large part of the process.

A project might be to have the compiler output spad dependencies --
just like GCC is able to output dependencies, which greatly
facilitates the tedious part of writing Makefiles and keeping them in
sync; Automake uses it.

\start
Date: Thu, 10 Aug 2006 21:42:11 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: lattice

Gaby,

On Thursday, August 10, 2006 9:29 PM you wrote:
> ...
> A project might be to have the compiler output spad
> dependencies --
> just like GCC is able to output dependencies, which greatly
> facilitates the tedious part of writing Makefiles and
> keeping them in sync; Automake uses it.
>

Where you here "years ago" when we first discussed the fact
that Axiom's build dependencies form a digraph with loops?
That makes the problem of using Automake rather more
difficult, I think - not impossible, but one would still
have to manually define a set of "bootstrap" modules which
when removed from the graph, turn it into a lattice that
can be sorted. Tim Daly did this entirely manually as part
of the initial steps in making Axiom available as open source.
Prior to that it was always necessary to have a running
version of Axiom in order to build Axiom - and that was
considered by some people contrary to the intention of making
Axiom "fully available" as open source (i.e. without also
having to distribute a binary version).

Having software find a optimal minimal set of bootstrap
modules is an interest (open?) question.

What to actually do about the circular dependencies themselves
is, perhaps a separate, but interesting subject in it's own
right.

I am very interested in you opinions on this subject because
of your background with gcc which also involves a bootstrapping
process, although I think no circular dependencies, right?

\start
Date: 11 Aug 2006 04:10:06 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: lattice

Bill Page writes:

| Gaby, 
| 
| On Thursday, August 10, 2006 9:29 PM you wrote:
| > ... 
| > A project might be to have the compiler output spad
| > dependencies --
| > just like GCC is able to output dependencies, which greatly
| > facilitates the tedious part of writing Makefiles and
| > keeping them in sync; Automake uses it.
| > 
| 
| Where you here "years ago" when we first discussed the fact
| that Axiom's build dependencies form a digraph with loops?

I was probably not here; or I was here but not paying attention. :-/

| That makes the problem of using Automake rather more
| difficult, I think - not impossible, but one would still
| have to manually define a set of "bootstrap" modules which
| when removed from the graph, turn it into a lattice that
| can be sorted.

I don't expect to have Automake figure out the dependencies by itself.
However, I do expect that at some point, Axiom compiler should be able
to output the dependencies.  It may not be a simple task; but that is
the whole point!

| Tim Daly did this entirely manually as part
| of the initial steps in making Axiom available as open source.

yes; I understand that.  That must have taken him a good deal of resources.

| Prior to that it was always necessary to have a running
| version of Axiom in order to build Axiom - and that was
| considered by some people contrary to the intention of making
| Axiom "fully available" as open source (i.e. without also
| having to distribute a binary version).
| 
| Having software find a optimal minimal set of bootstrap
| modules is an interest (open?) question.

It is an ideal.  If we can't get it 100%, we must approximate to the
point where the residual is sufficiently small and manageable.

| What to actually do about the circular dependencies themselves
| is, perhaps a separate, but interesting subject in it's own
| right.
| 
| I am very interested in you opinions on this subject because
| of your background with gcc which also involves a bootstrapping
| process, although I think no circular dependencies, right?

Bootstrapping problems, by definition, involve circularities.

GCC, for example, provides a sufficiently ANSI C89-conformant compiler.
It is written in C.  Therefore we have a bootstrapping problem.
"Fortunately", there are many flavours of C.  K&R being the most
popular.  Well, you have to define which "K&R".
Consequently, GCC was written in K&R C, restricted or augmented as
appropriate.  But, the new stream of developers had ANSI C89
background, and very few knew the subtle differences between K&R and
ANSI C.  And even the experts that knew them got trapped from time to
time.  The result was hard-to-find miscompilation bugs.
Consequently, we decided to bit the bullet and require ANSI C89
bootstrapping compiler.  For the few remaining platforms (notably
some old HPUX) where the system compiler is not ANSI C89, there are
binaries people can download install.

The project I know that is close to Axiom's dilemma is the Glorious
Glasgow Haskell Compiler System (GHC).
GHC is written in Haskell and you need a Haskell compiler to bootstrap
it.  To facilitate porting to new platforms, they also problem
generated C files that people to compile with "C" to build a
boostrapping compiler.  They also distribute binaries.

Where we are now is a bit different from where Tim was four years ago.
We have to think about how to reduce the surface complexity (as would
say a friend of mine). We're not going to attract lot of people
because we try to make Axiom look complicated.  We can gain by making
it look simpler to use, simpler to understand, simpler to modify. 

\start
Date: Thu, 10 Aug 2006 22:25:45 -0700
From: Arthur Ralfs
To: Tim Daly
Subject: Re: firefox chrome extension

Tim Daly wrote:
>> I can tar it up and email the works to you if you're eager to try it out.
>> Might take me a day or two to get done.
>>     
>
> Please do. I'd like to read your code.  
> I'm sure I'll find it helpful.
>   
You can get it mathbrane.ca/axiom/webax-0.0.1.tar
I hope you find it useful.

\start
Date: Fri, 11 Aug 2006 09:12:36 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: patches

>> I agree.  I'm a bit disappointed that we don't branch our
>> experiements/works from a single "referential" source.

> I agree too.

Good.

> As I explained in an earlier email, on Tuesday
> I updated the 'bookvol1' and 'ComputerTutorial' pamphlets in
> book--main--1 on the Axiom Wiki directly from the src/doc
> directory of the Silver branch.

Super. BUT...
If I haven't read the mailing list. I wouldn't even find
http://wiki.axiom-developer.org/book--main--1/FrontPage

If there is a reference to a source it MUST appear on the 
http://wiki.axiom-developer.org/AxiomSources page. Otherwise nobody will 
find it. I even believe that it would be enough to have axiom--test--1 
on the wiki. Cannot you merge your book--main--1 with axiom--test--1 and 
remove the wiki--book--main--1 thing? Furthermore there should be a SVN 
branch on sourceforge so that people who want to contribute to the book 
could also do this via SVN. Both the SVN branch and the wiki-axiom 
sources should be in sync. I guess that might be a bit hard, since svn 
doen't feature star-merge.

 > Then I applied the patches
> supplied by Frithjof Schulze. So now these files on the wiki
> are ready for online editing. Later we will merge these back
> to Silver and then from Silver to gold. Isn't that how it's
> supposed to work?

Right, but I would rather like to restrict the attribute "silver" to the 
SVN trunk. All the other branches on sourceforge are in a testing phase 
and only enter silver (=trunk) if they are at least reasonably stable. 
And they can enter it only by a request of the maintainer of the testing 
branch. (Which also means there should never be a branch that has no 
responsible person attached.)

\start
Date: Fri, 11 Aug 2006 10:25:07 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: automatic dependency generation  was: Re: lattice

> A project might be to have the compiler output spad dependencies --
> just like GCC is able to output dependencies, which greatly
> facilitates the tedious part of writing Makefiles and keeping them in
> sync; Automake uses it.

That would be a nice feature, but even if it probably will not happen 
that often, Aldor's "extend" might complicate that process (I don't say 
it makes it impossible).

Look at the files given below.
My intention is to compile them via

--aldor         aaaf1.as;  ar rv libmyprj.al aaaf1.ao;  rm aaaf1.ao
--aldor -lmyprj aaaf2.as;  ar rv libmyprj.al aaaf2.ao;  rm aaaf2.ao
--aldor -lmyprj aaaf3.as;  ar rv libmyprj.al aaaf3.ao;  rm aaaf3.ao

Assume the compiler first gets aaaf3.as. It sees either #library or 
"extend" and gives up, since no library is existing.
So it takes aaaf2.as and delays it for the same reason.
It can, however, compile aaaf1.as. Fine. But it really has to produce 
the .ao file and the library in order to be able to go on. So it is not 
just a lightweight compilation without producing code.
Then it starts again by looking at aaaf3.as. No compilation possible, 
since the function "bar" cannot be found. Now, is this just because 
there is a spelling mistake in "bar" or because the compiler has not yet 
seen aaaf2.as? OK, the compiler delays aaaf3.as and compiles aaaf2.as 
(with which options?). That works. Again the compiler must produce code 
so that aaaf3.as can compile.

One can easily setup several more extensions and finding the 
dependencies just explodes combinatorially.

A simple workaround would be to introduce a CONVENTION. One library may 
only extend a domain once. If there is need to extend another time, then 
that should happen in another library. In this way one gets a (more or 
less) natural layered structure and the library structure becomes easier 
to understand for a human.

There already happen several "extend"s in libalgebra (distributed with 
Aldor) and it is quite hard to find your way through the sources. One 
constantly has to check what the Makefile says.

Ralf

---BEGIN aaaf1.as
#include "aldor"
define CatA: Category == with {foo: () -> ()}
Dom: with {foo: () -> ()} == add {foo(): () == {}}
---END aaaf1.as

---BEGIN aaaf2.as
#include "aldor"
#library MyPrj "myprj"
import from MyPrj
extend Dom with {bar: () -> ()} == add {bar(): () == foo()}
---END aaaf2.as

---BEGIN aaaf3.as
#include "aldor"
#library MyPrj "myprj"
import from MyPrj
extend Dom with {ans: () -> ()} == add {ans(): () == bar()}
---END aaaf3.as

\start
Date: 11 Aug 2006 10:23:46 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

Greetings!

I had to make the following modifications to 20050901 to work with the
latest 2.6.8pre:

/fix/t1/camm/debian/axiom/axiom-20050901/int/interp/hash.lisp: remove static

(clines "int mem_value(x ,i)object x;int i; { return ((short *)x)[i];}")
#+AKCL
(defentry memory-value-short(object int) (int "mem_value"))


/fix/t1/camm/debian/axiom/axiom-20050901/int/interp/cfuns.lisp: match unsigned/signed

#+(AND KCL (NOT ELF))
(Clines
"int MYCOMBINE(i,j)"
"int i,j;"
"{"
"return ( (((((unsigned int)j) & 16777215) << 6)+((unsigned int)i)) % 1073741789);"
"}"
)

/fix/t1/camm/debian/axiom/axiom-20050901/int/interp/sockio.lisp: match float/double

  (clines "extern float sock_get_float();")
  (defentry open_server (string) (int "open_server"))
  (defentry sock_get_int (int) (int "sock_get_int"))
  (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"))


The defentry code has been enhanced to support xgcl natively.

I just did a successful build of axiom 20050901 and acl2 3.0.1 with
the same maxpage -- hope this works for you, though you might still
have a stack/heap collision problem on your machine.

Take care,

Bill Page writes:

> Camm, 
> 
> On Thursday, August 10, 2006 1:59 PM you wrote:
> > 
> > Greetings!  FYI, just committed the removal of the
> > power of 2 constraint on maxpage in both cvs head and
> > version 2.6.8pre.
> > 
> 
> Thanks for looking into this.
> 
> I just grabbed 2.6.8pre from cvs into a temp directory and
> created a replacement tarball for the Axiom build, thus:
> 
>   cd /home/page/temp-dir
>   export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
>   cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
>   tar czvf gcl-2.6.8pre.tgz gcl-2.6.8pre
>   cd /home/page/axiom.build-improvements/zips
>   mv gcl-2.6.8pre.tgz old_gcl-2.6.8pre.tgz
>   mv /home/page/temp-dir/gcl-2.6.8pre.tgz .
>   cd /home/page/axiom.build-improvements
> 
> I edited the GCLOPTS in Makefile from
>   --enable-maxpage=256*1024
> to
>   --enable-maxpage=196*1024
> resulting in
> 
>   GCLOPTS=--enable-vssize=65536*2 --enable-statsysbfd \
>           --enable-maxpage=196*1024
> 
> in the default build for Axiom Silver build-improvements branch:
> 
>   make clean
>   ./configure | tee build.log
>   make 2>&1 | tee -a build.log
> 
> The build proceeded much further than before - the GCL sub-build
> finished without errors - yeah! But the build of Axiom failed
> with the following error message quite far along into the
> interpsys build phase :(
> 
>   error: conflicting types for 'MYCOMBINE'
> 
> This is not something I have seen before. This same source builds
> fine with the older version of 2.6.8pre and 128*256.
> 
> Here is the tail end of the log. I can send you the rest if you
> like.
> 
> Please let me know how I can help.
> 
> Regards,
> Bill Page
> 
> ----------
> 
> ...
> 25 making /home/page/axiom.build-improvements/int/interp/cfuns.lisp from
> /home/page/axiom.build-improvements/src/interp/cfuns.lisp.pamphlet
> 24 making /home/page/axiom.build-improvements/obj/linux/interp/cfuns.o
> from /home/page/axiom.build-improvements/int/interp/cfuns.lisp
> /home/page/axiom.build-improvements/obj/linux/interp/cfuns.c:5238:
> error: conflicting types for 'MYCOMBINE'
> /home/page/axiom.build-improvements/obj/linux/interp/cfuns.h:15: error:
> previous declaration of 'MYCOMBINE' was here
> /home/page/axiom.build-improvements/obj/linux/interp/cfuns.c:5238:
> error: conflicting types for 'MYCOMBINE'
> /home/page/axiom.build-improvements/obj/linux/interp/cfuns.h:15: error:
> previous declaration of 'MYCOMBINE' was here
> make[4]: ***
> [/home/page/axiom.build-improvements/obj/linux/interp/cfuns.o] Error 255
> make[4]: Leaving directory
> `/home/page/axiom.build-improvements/src/interp'
> make[3]: *** [interpdir] Error 2
> make[3]: Leaving directory `/home/page/axiom.build-improvements/src'
> make[2]: *** [srcdir] Error 2
> make[2]: Leaving directory `/home/page/axiom.build-improvements'
> make[1]: *** [do-all] Error 2
> make[1]: Leaving directory `/home/page/axiom.build-improvements'
> make: *** [all] Error 2
> [page@axiom-developer axiom.build-improvements]$

\start
Date: Fri, 11 Aug 2006 23:33:07 +0200
From: Gregory Vanuxem
To: Camm Maguire
Subject: re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

Le vendredi 11 ao=FBt 2006 =E0 10:23 -0400, Camm Maguire a =E9crit :
> Greetings!
>
> I had to make the following modifications to 20050901 to work with the
> latest 2.6.8pre:
>
> /fix/t1/camm/debian/axiom/axiom-20050901/int/interp/hash.lisp: remove s=
tatic

So it seems that it's no longer necessary to define functions as static,
am I wrong with this (I use functions in a library written in Fortran) ?

\start
Date: Fri, 11 Aug 2006 23:50:33 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [Axiom-mail] Re: noweb

> | \begin{chunk}{MyCode} % The chunkname should not be optional!!
> | false
> | \end{chunk}
> | 
> | \begin{chunk}{MyChunk} % The chunkname should not be optional!!
> | apply(x: Boolean, y: Boolean): Boolean == x and y;
> | (x: Boolean)/(y: Boolean): Boolean == x and y;
> | MyCode: Boolean == true;
> | use: Boolean := true;
> | b: Boolean := MyCode /\ use/\use {MyCode} % How should that be parsed???
> | \end{chunk}

> | Doing that kind of programming in TeX is extremely difficult, since in
> | one place \ must be taken literally and in another it is considered as
> | a character that starts commands. If you want the code also reasonably
> | readable as a LaTeX source, I don't think that going the LaTeX way is
> | the right choice.

> Is this issue similar to that the package fancyvrb faces?

I haven't used fancyvrb, so I am not completely sure whether my 
reasoning is correct. But I have looked into the verbatim package. 
You'll probably believe that there are quite some tricks to recognise 
the \end{verbatim} in a stream of characters that TeX is actually 
supposed to output literally.

I bet even fancyvrb cannot correctly do a line like

b: Boolean := MyCode /\ use/\use {MyCode}

You could write

\begin{Verbatim}[commandchars=\\\{\}]
b: Boolean := MyCode /\ use/\use {MyCode}
\end{Verbatim}

That would probably correctly expand "\use {MyCode}", but the backslash 
after / is followed by a space and thus is expanded to output a space 
character. So in the output you would probably see something like

b: Boolean := MyCode / use/<MyCode>

where I wanted

b: Boolean := MyCode /\ use/<MyCode>

One must escape the first \ somehow in such a case. Doable, but it makes 
the code harder to read.

Of course you could write

\begin{Verbatim}[commandchars=|\{\}]
b: Boolean := MyCode /\ use/|use {MyCode}
\end{Verbatim}

and it would come out nicely, but then you have to make the 
corresponding tangle command a bit smarter to recognise | as the 
character that introduces TeX commands inside that Verbatim environment.

Anyway, fancyvrb seems to be quite smart, even though it does not solve 
the problem that in the output of the above code I would like see 
"Boolean" turn into a hyperlink to the definition of Boolean. 
Fortunately, the documentation of fancyvrb refers to the listings 
package for doing such fancy "pretty printing". But I have not yet 
looked into listings more closely.

\start
Date: 12 Aug 2006 01:55:26 +0200
From: Gabriel Dos Reis
To: list
Subject: /dev/null, noweb and Axiom

noweb uses /dev/null as a special place where to copy Emacs mode
support file, if the user does not want to have that file installed.

Axiom believes that writing to /dev/null is immoral and should not be
allowed.  Consequently it patches noweb's src/Makefile so that it uses
$(TMP)/null.  And at the same time, Axiom uses $(TMP)/null where to
send error messages in case a command fails -- for post-morterm
analysis.  The result of this mic-mac is that after noweb is built and
"installed", the file $(TMP)/null contains noweb's elisp file intead
of log messages.  :-/

I like the idea of having a log somehwere. 
I disagree with the idea that writing to /dev/null should be banned.

(Arguably, noweb's uses of /dev/null is "interesting", but that is a
different debate.)

\start
Date: 12 Aug 2006 02:04:34 +0200
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] noweb optional

As of revision 93, the build-improvements branch has made noweb
optional.  That means that, if noweb is already installed on the
build machine, then Axiom will not build its own version.

More precisely, we now have a new option:

    --with-noweb (negative counterpart: --without-noweb)

--with-noweb instructs the build machinery to assume that noweb is
present on the build machine -- configure does a check and errors out
if it cannot find notangle and noweave.

Conversely, --without-noweb instructs the build machinery not to
bother checking anything and assume that noweb is absent.
Axiom's copy of noweb is built.

If you don't specify any of those two options, configure will detect
whether both notangle and noweave are present.  If yes, it will use
them.  If one of both are missing, then Axiom's copy is used.

Of course, all of that will be added to the documentation.  This is
just a "heads up".

\start
Date: Fri, 11 Aug 2006 21:31:40 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Maxima on ZWiki

Bill,

Maxima is working now for me. Thanks for all the help. I needed actually 3 \
characters.
One to scape \ and the other one to scape the $ sign. Now, I just need to
add the nice
formatting from stylesheet.

I have another question. At some point, I saw on the list a bug about the
image created
for pamphlet files not been updated after saving. I remember that somebody
said that it
was necessary to click on preview first. However, this is not working for
me. I would like
to know if you know how to solve this issue.

Regards,

AP

On 8/11/06, Alfredo Portes wrote:
>
> Hi Bill,
>
> I got to a point where I see the output but in this form:
>
> \mbox{\tt\red(\mathrm{$\%i2}) \black}2+2\mbox{\tt\red(\mathrm{$\%o2})
> \black}4
>
> I havent been able to track the error. I would like to know how to test
> these files, without Zope.
>
> To scape the \$, I added \\$ to the regex on ReplaceInlineMaxima file.
> Regards,

\start
Date: Sat, 12 Aug 2006 02:20:16 -0400
From: Bill Page
To: Alfredo Portes
Subject: re: Maxima on ZWiki

Alfredo,

On August 11, 2006 9:32 PM you wrote:

> Maxima is working now for me. Thanks for all the help.

Great!

> I needed actually 3 \ characters. One to scape \ and the other
> one to scape the $ sign. Now, I just need to add the nice
> formatting from stylesheet. 

I made one simple change relating to formatting in ReplaceInlineMaxima.py
yesterday. You should also pull that change from the MathAction repository.

> I have another question. At some point, I saw on the list a bug about
> the image created for pamphlet files not been updated after saving.
> I remember that somebody said that it was necessary to click on preview
> first. However, this is not working for me.

No. Preview doesn't have anything to do with this. It is caused because
the web server is configured to agressively cache all graphics files
for reasons of efficiency.

> I would like to know if you know how to solve this issue.

To clear the cache hold down the Shift key while you click 'Reload Current
Page' in your browser. (I guess I should put that in the FAQ on the wiki,
eh?)

\start
Date: Sat, 12 Aug 2006 13:23:04 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: /dev/null, noweb and Axiom

> I disagree with the idea that writing to /dev/null should be banned.

But isn't /dev/null quite Unix-specific? It basically means that in 
order to build Axiom one must have a Unix-like environment. Not that I 
want to make the build process more complicated, but I am just curious 
how difficult it would be to build Axiom without mingw or cygwin.

\start
Date: 12 Aug 2006 15:25:52 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: /dev/null, noweb and Axiom

Ralf Hemmecke writes:

| > I disagree with the idea that writing to /dev/null should be banned.
| 
| But isn't /dev/null quite Unix-specific?

As is Autoconf?

| It basically means that in
| order to build Axiom one must have a Unix-like environment. Not that I
| want to make the build process more complicated, but I am just curious
| how difficult it would be to build Axiom without mingw or cygwin.

I don't think it is an issue.

\start
Date: 12 Aug 2006 16:17:39 +0200
From: Gabriel Dos Reis
To: list
Subject: Old Lisp

  Part of planning to clean up a bit the lsp/ directory, I'm removing
old GCL bits.  Old GCL here means anything prior to GCL-2.6.7.

\start
Date: Sat, 12 Aug 2006 12:04:25 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Old Lisp

On August 12, 2006 10:18 AM Gabriel Dos Reis
> 
>   Part of planning to clean up a bit the lsp/ directory, I'm removing
> old GCL bits.  Old GCL here means anything prior to GCL-2.6.7.
> 

I think that is a very good idea. I would encourage you to delete
*everything* that is not directly related to the current Axiom
build. I think we should not let the Axiom distribution collect
any cruft and we should not use it to re-distribute other packages
just because they might be a little hard to find.

I continue to be very impressed and pleased by your work on the
new Silver build_improvements branch. It cheers me up immensely. :-)

\start
Date: Sat, 12 Aug 2006 16:57:37 -0400
From: Bill Page
To: Alfredo Portes
Subject: Maxima on DoyenCD

On August 12, 2006 2:44 AM Alfredo Portes wrote:

>...
>>> Maxima is working now for me [in Doyen CD wiki]. Thanks for
>>> all the help.
>>

You are welcome. :)

> ...
> This is a great work you did with Maxima. Now that I have
> been reading the code these days, I wonder if I could get
> another CAS to work inside the wiki, maybe YACAS???

I think it would be great to have interfaces to more computer
algebra systems in Doyen CD and on MathAction. I would be glad
to help with any project of this kind that you or anyone else
decide to undertake. YACAS might be a good choice. I am currently
looking at another more specialized package recently recommended
by Bertfried Fauser called Cadabra, written by Kasper Peeters

http://www.aei.mpg.de/~peekas/cadabra/

As I have said several times before, the extensions that I made
to LatexWiki to support Axiom, Reduce and most recently Maxima
are really just a simple source filter hack in two parts.

The first part is a module to "wrap" the external program (e.g.
maximaWrapper.py) which runs a complete external session containing
multiple input sections in "batch mode" and then parses the
resulting output into sections corresponding to each input section.
The second part is a module (e.g. ReplaceInlineMaxima.py) that
extracts the input sections from the raw page source, e.g.

  ...
  \begin{maxima}
  section 1 commands
  \end{maxima}
  ...
  \begin{maxima}
  section 2 commands
  \end{maxima}
  ...

contains two input sections. It calls the wrapper to run the
external session and then replaces the input sections with output
sections in the page source. The result is passed on to the next
filter.

This is a batch process that is done once for each page preview
or when the page is saved so it does not have to be particularly
efficient.

The only challenging part is parsing the session output. In the
case of Maxima this was made particularly simple by the use of the
modified TeXmacs interface. All of the rest of the work is done by
LatexWiki and Zwiki and Zope.

> When I started working with Tim, this was one of his concerns, 
> getting other CAS output in the browser. Of course I never got
> to do something so advance and nice as you have inside the Wiki.

:) Well, thanks. But I think the Doyen CD is a pretty neat idea
too. I like how this is all coming together.

> ...
> I plan to make a new iso of Doyen tomorrow, please let me know
> if there is anything you would like me to include in it.

Well, I would definitely like to see the new web pages that you
created for Doyen on the new CD. For both Axiom and Maxima there
should be a few pages containing some examples and references
to other documentation. You can get these from the Axiom Wiki.
See for example:

http://wiki.axiom-developer.org/SandBoxMaxima

\start
Date: Sat, 12 Aug 2006 16:29:07 -0700
From: Simon Michael
To: list
Subject: heads-up, code updates

Greetings all.

Bob - I'll see your scare quotes and Microsoft/Intel characterisation, and 
raise you Working Code.. ;-)

Here's where I'm at with LatexWiki and MathAction. I updated LatexWiki 0.42 
to be compatible with current Zwiki.
http://joyful.com/darcsweb/darcsweb.cgi?r=latexwiki;a=summary

Now I've copied that into the Zwiki product as an internal plugin.
http://joyful.com/darcsweb/darcsweb.cgi?r=ZWiki;a=filehistory;f=/plugins
This is running on zwiki.org at the moment.

I'm following the same process with the latest MathAction. Here it is 
updated to work with current Zwiki, at least to the point of rendering LaTeX:
http://joyful.com/darcsweb/darcsweb.cgi?r=mathaction;a=summary
I have this installed as an internal plugin but it's not as yet added to 
the Zwiki repo.

This mathaction plugin is still using it's own older version of LatexWiki. 
I haven't made any attempt to refactor it to use the newer latexwiki 
plugin, but this may be a good thing to work towards. And that looks a lot 
easier now. In the past I tried to reconcile the two by pulling patches 
between your repos, but the differences were too large for me to resolve.

About internal vs. external plugins - a lot of projects seem to end up 
organised this way: many independent plugins, but distributed en masse. At 
the cost of some independence, it ensures users always have compatible 
code, solving a whole lot of problems with version skew and backwards 
compatibility, and also makes the overall codebase more maintainable and 
likely to be kept up to date. I think it's a good approach for zwiki 
plugins and pagetypes.

Should I bundle a mathaction plugin with Zwiki ? I'm not sure yet. I might 
check it in, refactor it and split it out again later. Anyway, ideally I'll 
achieve a clean up-to-date mathaction that's enticing enough for Bill to 
switch to. If not, well nothing lost.

Comments welcome - Simon

\start
Date: 13 Aug 2006 02:56:28 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Old Lisp

Bill Page writes:

| On August 12, 2006 10:18 AM Gabriel Dos Reis
| > 
| >   Part of planning to clean up a bit the lsp/ directory, I'm removing
| > old GCL bits.  Old GCL here means anything prior to GCL-2.6.7.
| > 
| 
| I think that is a very good idea.

Done.

| I would encourage you to delete
| *everything* that is not directly related to the current Axiom
| build. I think we should not let the Axiom distribution collect
| any cruft and we should not use it to re-distribute other packages
| just because they might be a little hard to find.

For the moment, I left in GCL-2.6.7 and GCL-2.6.8pre.  Once GCL-2.6.8
is out and working we can ditch the old ones. 

There are still some patches against GCL that Tim developed.
Ideally, I think we should not be in the business of patching GCL.
Camm has been collaborating with us very effectively; we should
communicate those issues with him and see how they can be addressed in
GCL upstream.

| I continue to be very impressed and pleased by your work on the
| new Silver build_improvements branch. It cheers me up immensely. :-)

Thank you very much for the kind words.

\start
Date: Sun, 13 Aug 2006 03:10:06 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: Old Lisp

Le dimanche 13 ao=FBt 2006 =E0 02:56 +0200, Gabriel Dos Reis a =E9crit :
> Bill Page writes:
>
> | On August 12, 2006 10:18 AM Gabriel Dos Reis
> | >
> | >   Part of planning to clean up a bit the lsp/ directory, I'm removi=
ng
> | > old GCL bits.  Old GCL here means anything prior to GCL-2.6.7.
> | >
> |
> | I think that is a very good idea.
>
> Done.

OK, so no need to reorganise the Makefile.pamphlet, cool :-)

\start
Date: Sat, 12 Aug 2006 22:08:22 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Old Lisp

On August 12, 2006 8:56 PM Gaby wrote:
> ... 
> There are still some patches against GCL that Tim developed.
> Ideally, I think we should not be in the business of patching
> GCL. Camm has been collaborating with us very effectively; we
> should communicate those issues with him and see how they can
> be addressed in GCL upstream.
> 

I think all of the patches made by Tim are obsolete. I agree
that we should not be in the business of patching GCL. Although
GCL is currently the primary vehicle for delivering Axiom, it
is not the only Lisp that is capable of doing so. (For example
there is the open source CMUCL version of Axiom done by Jurgen
Weiss and the commercial version of Axiom used yet another lisp
and that lisp is now open source too.

In fact I am fairly sure that Camm has already addressed all of
the GCL issues that have been identified so far. None of these
patches are used in the Debian release of Axiom which is built
from an unmodified standard distribution of GCL. There is no
reason that I can think of way this should not become the standard
way of building Axiom from GCL on all platforms (including Windows).

\start
Date: 13 Aug 2006 04:34:22 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Old Lisp

Bill Page writes:

| On August 12, 2006 8:56 PM Gaby wrote:
| > ... 
| > There are still some patches against GCL that Tim developed.
| > Ideally, I think we should not be in the business of patching
| > GCL. Camm has been collaborating with us very effectively; we
| > should communicate those issues with him and see how they can
| > be addressed in GCL upstream.
| > 
| 
| I think all of the patches made by Tim are obsolete. I agree
| that we should not be in the business of patching GCL. Although
| GCL is currently the primary vehicle for delivering Axiom, it
| is not the only Lisp that is capable of doing so. (For example
| there is the open source CMUCL version of Axiom done by Jurgen
| Weiss and the commercial version of Axiom used yet another lisp
| and that lisp is now open source too.

OK.

| In fact I am fairly sure that Camm has already addressed all of
| the GCL issues that have been identified so far. None of these
| patches are used in the Debian release of Axiom which is built
| from an unmodified standard distribution of GCL. There is no
| reason that I can think of way this should not become the standard
| way of building Axiom from GCL on all platforms (including Windows).

For GCL-2.6.7, Tim has a patch against configure.in.  The reason being
that:

   There is a typo in configure.in that is only detected under some
   versions of bash. The problem is a missing single-quote mark.

For that to work correctly, there is an implicit assumption that the
user's build environment has Autoconf -- to regenerate configure from
the patched configure.in.  I don't how serious that is.  Anyway, it
GCL-2.6.7 that we might just abandon from the silver branch.

For GCL-2.6.8pre we have four patches:

  * gcl-2.6.8pre.socket.patch
  * gcl-2.6.8pre.libspad.patch
  * gcl-2.6.8pre.toploop.patch
  * gcl-2.6.8pre.collectfn.fix

Can you check with Camm that they are indeed not needed anymore?  I'm
sorry, I don't fully understand the issues they are trying to address.

\start
Date: Sun, 13 Aug 2006 00:21:37 -0700
From: Ed Borasky
To: Bill Page
Subject: Re: Old Lisp

Bill Page wrote:
> On August 12, 2006 8:56 PM Gaby wrote:
>> ... 
>> There are still some patches against GCL that Tim developed.
>> Ideally, I think we should not be in the business of patching
>> GCL. Camm has been collaborating with us very effectively; we
>> should communicate those issues with him and see how they can
>> be addressed in GCL upstream.
>>
> 
> I think all of the patches made by Tim are obsolete. I agree
> that we should not be in the business of patching GCL. Although
> GCL is currently the primary vehicle for delivering Axiom, it
> is not the only Lisp that is capable of doing so. (For example
> there is the open source CMUCL version of Axiom done by Jurgen
> Weiss and the commercial version of Axiom used yet another lisp
> and that lisp is now open source too.
Ack ... Lisp wars! :) Well ...

1. As far as I know, GCL and CLISP are the only open source Lisps that 
run on Windows. CMUCL for sure doesn't and SBCL may not either. CMUCL 
probably never will, but SBCL has a good chance.

2. I think GCL is faster than CLISP.

3. If you have GCL installed, does Axiom still build its own copy, or 
does it know about the installed version?

\start
Date: Sun, 13 Aug 2006 01:55:32 -0700
From: Simon Michael
To: list
Subject: Re: heads-up, code updates

Simon Michael wrote:
> Should I bundle a mathaction plugin with Zwiki ? I'm not sure yet. I 
> might check it in

I did that, and made more changes, and it's running reasonably well now at 
zwiki.org. See http://zwiki.org/MathActionTests (and subtopics).

This means you can check out the latest Zwiki and get latex, axiom, reduce, 
maxima, & pamphlets up and running without too much pain, at least on my 
debian system. All helper programs are assumed to be in /usr/bin, axiom.sty 
should be copied to /usr/local/share/texmf/tex/latex/ (and mktexlsr should 
be run).

All: I learned about and played with a lot of cool stuff today. Thanks for 
all this great work!

\start
Date: 13 Aug 2006 16:23:34 +0200
From: Gabriel Dos Reis
To: Ed Borasky
Subject: Re: Old Lisp

Ed Borasky writes:


[...]

| 3. If you have GCL installed, does Axiom still build its own copy, or
| does it know about the installed version?

You can convince Axiom to use the installed GCL by defining the
variable GCLVERSION=gcl-system -- this is what FreeBSD folks do,
according to the documentation.

I'm working on a patch that have Axiom autodetect GCL and use it.

\start
Date: Sun, 13 Aug 2006 10:59:18 -0400
From: Cliff Yapp
To: list
Subject: Re: Old Lisp

On Sunday 13 August 2006 3:21 am, Ed Borasky wrote:

> 1. As far as I know, GCL and CLISP are the only open source Lisps that
> run on Windows. CMUCL for sure doesn't and SBCL may not either. CMUCL
> probably never will, but SBCL has a good chance.

I believe ECL also works on Windows, but I don't know too much about it beyond 
that.

> 2. I think GCL is faster than CLISP.

Yes, this is what I have heard as well.  (Indeed, new-clx on clisp was written
specificly to solve performance issues that the usual clx has, IIRC.)

SBCL has made strides on Windows, but keep in mind some issues are EXTREMELY 
difficult to handle in porting and it will likely be a very long time before 
sbcl is full featured on both Linux and Windows.

For a quick summary of platforms supported by sbcl, there is this page:
http://sbcl.sourceforge.net/platform-table.html

These are the to-do lists I am aware of for the sbcl port:
http://www.dridus.com/~nyef/TODO.Win32
http://www-jcsu.jesus.cam.ac.uk/~csr21/TODO.win32

\start
Date: 13 Aug 2006 17:09:06 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [Axiom-mail] Re: noweb

Ralf Hemmecke writes:

| > | \begin{chunk}{MyCode} % The chunkname should not be optional!!
| > | false
| > | \end{chunk}
| > | | \begin{chunk}{MyChunk} % The chunkname should not be optional!!
| > | apply(x: Boolean, y: Boolean): Boolean == x and y;
| > | (x: Boolean)/(y: Boolean): Boolean == x and y;
| > | MyCode: Boolean == true;
| > | use: Boolean := true;
| > | b: Boolean := MyCode /\ use/\use {MyCode} % How should that be parsed???
| > | \end{chunk}
| 
| > | Doing that kind of programming in TeX is extremely difficult, since in
| > | one place \ must be taken literally and in another it is considered as
| > | a character that starts commands. If you want the code also reasonably
| > | readable as a LaTeX source, I don't think that going the LaTeX way is
| > | the right choice.
| 
| > Is this issue similar to that the package fancyvrb faces?
| 
| I haven't used fancyvrb, so I am not completely sure whether my
| reasoning is correct. But I have looked into the verbatim
| package. You'll probably believe that there are quite some tricks to
| recognise the \end{verbatim} in a stream of characters that TeX is
| actually supposed to output literally.

Well, I'm not a TeXnician, nor a LaTeX expert.  I just find the
package fancyvrb amazing, flexible, and happen to prefer it over other
alternatives I've tried.  Given the sort of things it does, I thought
it might have faced similar issues, but again I'm not a LaTeX expert.

\start
Date: 13 Aug 2006 17:14:51 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [build-improvements] Requests for discussion

Ralf Hemmecke writes:

[...]

| So each time I modify a file which is called configure.ac.pamphlet or
| Makefile.am.pamphlet, I should run "build-setup.sh". What if I forget
| that? There should be at least a warning telling me that I should run
| "build-setup.sh".

Ralf --

  As of revision 96, if you're in the middle of development, you
modify configure.ac.pamphlet or Makefile.pamphlet, the top level Makefile
will regenerate configure, Makefile.in, and Makefile as appropriate.

\start
Date: Sun, 13 Aug 2006 08:22:54 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Has anybody attempted to build Aldor+Axiom lately?

I tried the binary and found it didn't work on Gentoo, so it was back
to building from source.  I got most of the way there with a gold
branch cvs checkout (I think it's fairly recent) and started up the
aldor part of the build.  This was the error:

mkdir -p
/home/user/mathtoplevel/axiomtoplevel/axiom/obj/linux/aldor/build
touch -t 199901010000
/home/user/mathtoplevel/axiomtoplevel/axiom/obj/linux/aldor/build/.dir
MERGE: libaxiom_lang.lst (1)
(cd /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/ao; \
         ar x /usr/local/aldor/linux/1.0.3/lib/libaxllib.al lang.ao)
mkdir -p /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/lsp
touch -t 199901010000
/home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/lsp/.dir
aldor -Flsp -R
/home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/lsp
/home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/ao/lang.ao 
mkdir -p
/home/user/mathtoplevel/axiomtoplevel/axiom/mnt/linux/aldor/lib
touch -t 199901010000
/home/user/mathtoplevel/axiomtoplevel/axiom/mnt/linux/aldor/lib/.dir
cp /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/lsp/lang.lsp
/home/user/mathtoplevel/axiomtoplevel/axiom/mnt/linux/aldor/lib/lang.lsp
echo LSP->O: lang.o
Built lang.o
mkdir -p /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/as
touch -t 199901010000
/home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/as/.dir
cp
/home/user/mathtoplevel/axiomtoplevel/axiom/src/aldor/as/attrib.as.head
 /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/as/attrib.as
Please add new attributes to /attrib.as.head
make[1]: ***
[/home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/as/attrib.as]
Error 1
make[1]: *** Deleting file
`/home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/as/attrib.as'
make[1]: Leaving directory
`/home/user/mathtoplevel/axiomtoplevel/axiom/src/aldor'
make: *** [all] Error 2

Has anybody seen anything like this before? 

\start
Date: 13 Aug 2006 17:44:07 +0200
From: Martin Rubey
To: Cliff Yapp, Antoine Hersen
Subject: Re: Old Lisp

Cliff Yapp writes:

> On Sunday 13 August 2006 3:21 am, Ed Borasky wrote:
> 
> > 1. As far as I know, GCL and CLISP are the only open source Lisps that
> > run on Windows. CMUCL for sure doesn't and SBCL may not either. CMUCL
> > probably never will, but SBCL has a good chance.

There is a list of available lisps here:

http://www.cliki.net/Common Lisp implementation

Thus, we should also target 

Armed Bear Lisp - Armed Bear Common Lisp is a Common Lisp implementation that
runs on a Java Virtual Machine

and

PowerLisp - PowerLisp is a free Common Lisp implementation for the Macintosh

Maybe the latter would bring us on the Mac faster, which would cheer up Antoine
considerably, I guess.

What concerns speed, I think this depends very much on the application. I don't
think it's fair to say that gcl is faster than clisp. This is very likely an
oversimplification.

\start
Date: 13 Aug 2006 17:46:54 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: Old Lisp

Martin Rubey writes:

> PowerLisp - PowerLisp is a free Common Lisp implementation for the Macintosh

sorry, that should read

OpenMCL - OpenMCL is a Common Lisp implementation

(for the Mac)

\start
Date: Sun, 13 Aug 2006 19:38:44 +0200
From: Gregory Vanuxem
To: Cliff Yapp
Subject: Re: Has anybody attempted to build Aldor+Axiom	lately?

Le dimanche 13 ao=FBt 2006 =E0 08:22 -0700, C Y a =E9crit :
[...]
> Please add new attributes to /attrib.as.head

[...]

> Has anybody seen anything like this before?

Yes I faced the same problem, I commented out (dirty hack) the "@false",
ligne 68 of src/aldor/libaxiom.mk :

$(MID)/as/attrib.as:: $(INT)/algebra/ATTREG.spad
        @echo "Please add new attributes to $(Ax0Dir)/attrib.as.head"
#       @false

You can probably "touch" src/aldor/as/attrib.as.head as well. See
http://lists.gnu.org/archive/html/axiom-developer/2006-04/msg00285.html

\start
Date: Sun, 13 Aug 2006 10:45:18 -0700
From: Ed Borasky
To: Cliff Yapp
Subject: Re: Has anybody attempted to build Aldor+Axiom	lately?

C Y wrote:
> I tried the binary and found it didn't work on Gentoo, so it was back
> to building from source.  I got most of the way there with a gold
> branch cvs checkout (I think it's fairly recent) and started up the
> aldor part of the build.  This was the error:
> 
> mkdir -p
> /home/user/mathtoplevel/axiomtoplevel/axiom/obj/linux/aldor/build
> touch -t 199901010000
> /home/user/mathtoplevel/axiomtoplevel/axiom/obj/linux/aldor/build/.dir
> MERGE: libaxiom_lang.lst (1)
> (cd /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/ao; \
>          ar x /usr/local/aldor/linux/1.0.3/lib/libaxllib.al lang.ao)
> mkdir -p /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/lsp
> touch -t 199901010000
> /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/lsp/.dir
> aldor -Flsp -R
> /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/lsp
> /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/ao/lang.ao 
> mkdir -p
> /home/user/mathtoplevel/axiomtoplevel/axiom/mnt/linux/aldor/lib
> touch -t 199901010000
> /home/user/mathtoplevel/axiomtoplevel/axiom/mnt/linux/aldor/lib/.dir
> cp /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/lsp/lang.lsp
> /home/user/mathtoplevel/axiomtoplevel/axiom/mnt/linux/aldor/lib/lang.lsp
> echo LSP->O: lang.o
> Built lang.o
> mkdir -p /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/as
> touch -t 199901010000
> /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/as/.dir
> cp
> /home/user/mathtoplevel/axiomtoplevel/axiom/src/aldor/as/attrib.as.head
>  /home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/as/attrib.as
> Please add new attributes to /attrib.as.head
> make[1]: ***
> [/home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/as/attrib.as]
> Error 1
> make[1]: *** Deleting file
> `/home/user/mathtoplevel/axiomtoplevel/axiom/int/aldor/as/attrib.as'
> make[1]: Leaving directory
> `/home/user/mathtoplevel/axiomtoplevel/axiom/src/aldor'
> make: *** [all] Error 2
> 
> Has anybody seen anything like this before? 
> 
> Cheers,
> CY
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> list
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
> 

I recently did a complete end-to-end build of Axiom Silver on Gentoo. It 
worked fine.

# ls -lR|more
.:
total 8
-rw-r--r-- 1 root root   68 Aug  6 21:13 GetSilver
drwxr-xr-x 5 root root 4096 Aug  6 21:13 axiom.silver

./axiom.silver:
total 8
drwxr-xr-x  3 root root 4096 Aug  6 21:13 CVSROOT
drwxr-xr-x 10 root root 4096 Aug  7 07:42 axiom

./axiom.silver/CVSROOT:
total 44
-rw-r--r-- 1 root root  493 Aug  6 21:13 checkoutlist
-rw-r--r-- 1 root root  760 Aug  6 21:13 commitinfo
-rw-r--r-- 1 root root  527 Aug  6 21:13 config
-rw-r--r-- 1 root root  753 Aug  6 21:13 cvswrappers
-rw-r--r-- 1 root root 1025 Aug  6 21:13 editinfo
-rw-r--r-- 1 root root 1141 Aug  6 21:13 loginfo
-rw-r--r-- 1 root root 1151 Aug  6 21:13 modules
-rw-r--r-- 1 root root  564 Aug  6 21:13 notify
-rw-r--r-- 1 root root  649 Aug  6 21:13 rcsinfo
-rw-r--r-- 1 root root  879 Aug  6 21:13 taginfo
-rw-r--r-- 1 root root 1026 Aug  6 21:13 verifymsg


# more GetSilver
svn co https://svn.sourceforge.net/svnroot/axiom/trunk axiom.silver

I have GCL installed, and I'm just about to try using that for the build.

By the way, Axiom is actually in Portage (sci-mathematics/axiom) but 
it's the September 2005 tarball. I should bug the Gentoo Science folks 
about putting up a newer tarball, like the most recent Golden.

\start
Date: Sun, 13 Aug 2006 12:18:43 -0700 (PDT)
From: Cliff Yapp
To: Ed Borasky
Subject: Re: Has anybody attempted to build Aldor+Axiom	lately?

--- Ed Borasky wrote:

> I recently did a complete end-to-end build of Axiom Silver on Gentoo.
> It worked fine.

Yes, I can build axiom sans Aldor on gentoo as well.  The new
build-improvements work also functions on gentoo - very smooth!

> I have GCL installed, and I'm just about to try using that for the
> build.
> 
> By the way, Axiom is actually in Portage (sci-mathematics/axiom) but 
> it's the September 2005 tarball. I should bug the Gentoo Science
> folks about putting up a newer tarball, like the most recent Golden.

Probably a good idea.

\start
Date: Sun, 13 Aug 2006 12:26:23 -0700 (PDT)
From: Cliff Yapp
To: regory Vanuxem
Subject: Re: Has anybody attempted to build Aldor+Axiom	lately?

Hmm - I just tried to update AldorForAxiom with this info, and it won't
let me.  My preferences are set up - guess I need to go re-read the
anti-spam changes, I must be missing something.  Thanks Vanuxem!

Cheers,
CY

--- Vanuxem Grgory Gregory Vanuxem wrote:

> Le dimanche 13 aot 2006  08:22 -0700, C Y a crit :
> [...]
> > Please add new attributes to /attrib.as.head
> 
> [...]
> 
> > Has anybody seen anything like this before? 
> 
> Yes I faced the same problem, I commented out (dirty hack) the
> "@false",
> ligne 68 of src/aldor/libaxiom.mk :
> 
> $(MID)/as/attrib.as:: $(INT)/algebra/ATTREG.spad
>         @echo "Please add new attributes to $(Ax0Dir)/attrib.as.head"
> #       @false
> 
> You can probably "touch" src/aldor/as/attrib.as.head as well. See
>
http://lists.gnu.org/archive/html/axiom-developer/2006-04/msg00285.html

\start
Date: Sun, 13 Aug 2006 13:51:22 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Re: Has anybody attempted to build Aldor+Axiom	lately?

Bill, sorry for being such a dork - I'm looking at AldorForAxiom, and I
don't quite see why it's not letting me save the change.  It looks like
most of the links are using the "link text":http... method, so I'm not
quite sure what it's objecting to.

Cheers,
CY

--- Cliff Yapp wrote:

> Hmm - I just tried to update AldorForAxiom with this info, and it
> won't
> let me.  My preferences are set up - guess I need to go re-read the
> anti-spam changes, I must be missing something.  Thanks Vanuxem!
> 
> Cheers,
> CY
> 
> --- Vanuxem Grgory Gregory Vanuxem wrote:
> 
> > Le dimanche 13 aot 2006  08:22 -0700, C Y a crit :
> > [...]
> > > Please add new attributes to /attrib.as.head
> > 
> > [...]
> > 
> > > Has anybody seen anything like this before? 
> > 
> > Yes I faced the same problem, I commented out (dirty hack) the
> > "@false",
> > ligne 68 of src/aldor/libaxiom.mk :
> > 
> > $(MID)/as/attrib.as:: $(INT)/algebra/ATTREG.spad
> >         @echo "Please add new attributes to
> $(Ax0Dir)/attrib.as.head"
> > #       @false
> > 
> > You can probably "touch" src/aldor/as/attrib.as.head as well. See
> >
>
http://lists.gnu.org/archive/html/axiom-developer/2006-04/msg00285.html

\start
Date: Sun, 13 Aug 2006 17:13:04 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Has anybody attempted to build Aldor+Axiomlately?

On August 13, 2006 4:51 PM C Y wrote:
>
> Bill, sorry for being such a dork - I'm looking at AldorForAxiom,
> and I don't quite see why it's not letting me save the change. It
> looks like most of the links are using the "link text":http...
> method, so I'm not quite sure what it's objecting to.
>

Cliff, the problem is not you - it's those dork spam artists who
insist on abusing our web site... :(

The reason your edit to AldorForAxiom was being rejected is
because the page contained at least one (actually there were
several) occurrences of http:// Since the very aggressive link
spam attach of last week that actually caused the wiki software
to crash at one point, this common prefix for links has been
banned on Axiom Wiki. Unfortunately this applies to both any new
text you enter as well as any pre-existing source text on that
page.

You can still enter links however they must be written using
WebSite: instead of http://, for example do not write:

  http://abc.com/help.html

instead write:

  WebSite:abc.com/help.html

Right now this also applies to

  "link text":http://...

which must be written like this:

  "link text" WebSite:...

although I will try to make the banned_links more flexible to
allow the latter form.

The reason for all this is to make it unattractive for people
who run spam robots to target our website.

I have updated the text of AldorForAxiom to remove the http's
so now you should be able to edit it.

I am very sorry for the trouble. I need to think about some way
of making the reason for the rejection and the way to get around
it more obvious for people who want to post to the wiki.

Regards,
Bill Page.


>
> --- Cliff Yapp wrote:
>
> > Hmm - I just tried to update AldorForAxiom with this info, and it
> > won't
> > let me.  My preferences are set up - guess I need to go re-read the
> > anti-spam changes, I must be missing something.  Thanks Vanuxem!
> >
> > Cheers,
> > CY
> >
> > --- Vanuxem Gr=E9gory Gregory Vanuxem wrote:
> >
> > > Le dimanche 13 ao=FBt 2006 =E0 08:22 -0700, C Y a =E9crit :
> > > [...]
> > > > Please add new attributes to /attrib.as.head
> > >
> > > [...]
> > >
> > > > Has anybody seen anything like this before?
> > >
> > > Yes I faced the same problem, I commented out (dirty hack) the
> > > "@false",
> > > ligne 68 of src/aldor/libaxiom.mk :
> > >
> > > $(MID)/as/attrib.as:: $(INT)/algebra/ATTREG.spad
> > >         @echo "Please add new attributes to
> > $(Ax0Dir)/attrib.as.head"
> > > #       @false
> > >
> > > You can probably "touch" src/aldor/as/attrib.as.head as well. See
> > >
> >
> http://lists.gnu.org/archive/html/axiom-developer/2006-04/msg0
> 0285.html

\start
Date: Sun, 13 Aug 2006 14:31:57 -0700
From: Simon Michael
To: list
Subject: Re: Has anybody attempted to build Aldor+Axiomlately?

Bill - banning http:// on a wiki ? This makes me cringe.. what good is it 
if legitimate users can't add links.

I saw you have implemented a restriction on editing - it seemed to require 
a username configured in preferences, similar to my edits_need_username 
property. Are you getting significant spam even with this turned on ? They 
are configuring a username cookie ?

\start
Date: Sun, 13 Aug 2006 14:56:09 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Has anybody attempted to build Aldor+Axiomlately?

--- Bill Page wrote:

> The reason your edit to AldorForAxiom was being rejected is
> because the page contained at least one (actually there were
> several) occurrences of http:// Since the very aggressive link
> spam attach of last week that actually caused the wiki software
> to crash at one point, this common prefix for links has been
> banned on Axiom Wiki. Unfortunately this applies to both any new
> text you enter as well as any pre-existing source text on that
> page.

Ah ha!  OK, that makes sense.  I had been assuming that either a)
pre-existing links were OK in a re-save, or b) all existing links had
been converted.  My mistake.
 
> You can still enter links however they must be written using
> WebSite: instead of http://, for example do not write:
> 
>   http://abc.com/help.html
> 
> instead write:
> 
>   WebSite:abc.com/help.html

That's what I was looking for - just didn't get far enough into that
thread on my archives.  Thanks!

> I have updated the text of AldorForAxiom to remove the http's
> so now you should be able to edit it.

Cool - I'll confirm that the libaxiom.mk fix is all that's needed and
then try again (building axiom silver now.)
 
> I am very sorry for the trouble. I need to think about some way
> of making the reason for the rejection and the way to get around
> it more obvious for people who want to post to the wiki.

No problem - thank you for putting the effort into keeping things
clean.  It might be worth looking at wikipedia - I think they have some
kind of bot which inspects changes and disallows the obvious spam,
although that's based on a comment I saw and I don't know much about
it.

\start
Date: Sun, 13 Aug 2006 15:10:44 -0700
From: Simon Michael
To: list
Subject: Re: Has anybody attempted to build Aldor+Axiomlately?

Also, current Zwiki is smarter about this - it tries not to count links 
that were in the page already.

             # does this edit look like spam ?
             # Tries to count the links added by this edit. Not perfect -
             # existing links on a line that you tweak will be counted.
             # Not sure what happens if you replace existing links.
             self.checkForSpam(self.addedText(old, new))

Most of these anti-spam refinements have been added in the last year, as it 
became a problem.

\start
Date: Sun, 13 Aug 2006 15:15:42 -0700
From: Bob McElrath
To: Simon Michael
Subject: re: Has anybody attempted to build Aldor+Axiomlately?

I'm gonna vote with Simon here...I know spam is a problem but this is
overkill.  Banning http will cause a lot of problems for new users,
exactly those a budding young project can't afford to alienate...

Simon Michael [Simon Michael] wrote:
> Bill - banning http:// on a wiki ? This makes me cringe.. what good is it 
> if legitimate users can't add links.
> 
> I saw you have implemented a restriction on editing - it seemed to require 
> a username configured in preferences, similar to my edits_need_username 
> property. Are you getting significant spam even with this turned on ? They 
> are configuring a username cookie ?

Simon Michael [Simon Michael] wrote:
> Also, current Zwiki is smarter about this - it tries not to count links 
> that were in the page already.
> 
>             # does this edit look like spam ?
>             # Tries to count the links added by this edit. Not perfect -
>             # existing links on a line that you tweak will be counted.
>             # Not sure what happens if you replace existing links.
>             self.checkForSpam(self.addedText(old, new))
> 
> Most of these anti-spam refinements have been added in the last year, as it 
> became a problem.

\start
Date: Sun, 13 Aug 2006 18:29:47 -0400
From: Bill Page
To: Simon Michael
Subject: re: Has anybody attempted to buildAldor+Axiomlately?

On August 13, 2006 5:32 PM you wrote:
> 
> Bill - banning http:// on a wiki ? This makes me cringe.. 
> what good is it if legitimate users can't add links.

Me too. Although I set up a generic RemoteWikiURL page called
WebSite defined as just http:// so it is still possible to create
links to external sites - it's just harder. My intention was to
selectively create other more specific RemoteWikiURL pages when
I get a chance.

> 
> I saw you have implemented a restriction on editing - it seemed
> to require a username configured in preferences, similar to my 
> edits_need_username property.

Yes.

> Are you getting significant spam even with this turned on?

And yes.

> They are configuring a username cookie ?
> 

Yes! :(( <weeping>

Not only that but someone who must really hate us (for no
reason as far as I can tell) actually setup a 350 member zombie
net that blasted our web site all day long last week. I admit
that banning http:// was a drastic move, but I was desparate.

BTW, I did read your recent posts about successfully merging
MathAction/LatexWiki back into Zwiki... :) That's what I like
about open source, if you wait long enough then you might just
get lucky and find someone willing to do the work you were
supposed to do! :) Thanks for doing this. I will setup a test
server on axiom-developer.org and install your merged version
to give it a test run. Then I will try to move the current
production contents into the test site. I will let you know
how it goes and then make it available for everyone to test.

\start
Date: Sun, 13 Aug 2006 15:59:42 -0700
From: Simon Michael
To: list
Subject: Re: Has anybody attempted to buildAldor+Axiomlately?

Bill Page wrote:
> I will setup a test
> server on axiom-developer.org and install your merged version
> to give it a test run. 

Great!

With that version, you'll have the max_anonymous_links and 
max_identified_links options which you can use to allow links but only up 
to a certain number. Perhaps this will be enough to keep out most spam 
edits painlessly.

I should say: clearly there's times when you need to lock down temporarily 
to respond to an attack, I'm referring more to the long-term. Your use of 
remotewikilinks is clever, but too much hassle for users I think.

\start
Date: Sun, 13 Aug 2006 20:12:08 -0400
From: William Sit
To: Simon Michael
Subject: Issues with documentation revisions

In the thread: Re: heads-up, code updates

> Simon Michael wrote:
> > Should I bundle a mathaction plugin with Zwiki ? I'm not sure yet. I 
> > might check it in
> 
> I did that, and made more changes, and it's running reasonably well now at 
> zwiki.org. See http://zwiki.org/MathActionTests (and subtopics).
> 

I visited the page above and found Tim Daly's AutoDocPamphlet. It was a
rather simple pamphlet but I found the documentation difficult to
follow. As an exercise, I totally revised the documentation (with a few
minor editing of the lisp code, which I don't think was for production
use). This experience raised a few issues, in particular, that revising
documentation may accidentally change the code because the code may be
editorially revised as well. For details see NewAutodocPamphlet by
following the link above or read the pdf file from 
http://zwiki.org/NewAutodocPamphlet

\start
Date: Mon, 14 Aug 2006 02:46:57 +0200
From: Frithjof Schulze
To: list
Subject: Problem with log in wiki.

I thing there is a problem with the log line when editing a file in the
wiki. When the statement is too long it is first cut off and printed
appropriate and nice. Only after the next edit a rest of the first
statement is appended to the new log line a gives nonsense.

Moreover, I have two questions concerning the tutorial. 

There are some parts about Fortran and IBM Script output and about the
extended ASCII code on IBM workstations. Is this still relevent or is it
sufficient, if this is just a topic in the second volume?

Does anybody know about good and short examples for the usage of Axiom
that make use of a kind of programming. That means short (one or two
pages) examples which consist of more than just calling predefined
functions.

Unfortunately, I won't be able to read emails in the next week so I
won't be able to react to any answers. Many thanks in advance. 

\start
Date: Sun, 13 Aug 2006 21:41:01 -0400
From: Tim Daly
To: Bill Page
Subject: Re: pamphlet problems

sigh.

noweb, configure, GCL, latex, svn, arch, darcs, etc....

i think we need to create a new top level file called "PROCON"
which contains a particular issue and summarizes the arguments
both for (PRO) and against (CON) a particular decsion. there
are many topics that keep coming up again and again. the mailing
list isn't a sufficiently specific way to collect these arguments.

once these are summarized we can point new people to the file.
unless some truly new argument is advanced we should not have to
revisit these decisions.

agree or disagree?

\start
Date: Sun, 13 Aug 2006 21:45:47 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: pamphlet problems

The token.pamphlet file contained a mistake. It should generate token.h,
not token.c. hyper.pamphlet does a #include for token.h. This is likely
a source of errors in the hyperdoc program. I'll fix it.

\start
Date: Sun, 13 Aug 2006 21:56:19 -0400
From: Bill Page
To: Bob McElrath, Simon Michael
Subject: re: Has anybody attempted to buildAldor+Axiomlately?

On August 13, 2006 6:16 PM Bob McElrath wrote:
> 
> I'm gonna vote with Simon here...I know spam is a problem but
> this is overkill.  Banning http will cause a lot of problems
> for new users, exactly those a budding young project can't
> afford to alienate...
> 

After two years of running the Axiom Wiki I am inclined to disagree.
It seems to me that there is very little we can do to overcome the
reluctance that new users feel to using a wiki. Those who do not
have this reluctance already have a high tolerance for the kind of
problems created by banning the use of http://anything. And then
there are people out there on the wild web who are willing and able
to exploit our resources for there own ends, no matter what we do
to try to prevent it.

Mostly I would conclude from this excersize that simply building
a wiki (however sexy or easy to use) and hoping that people will
simply show up to create content is misguided. You can point to
the counter-example of Wikipedia but I am convinced that here the
difference is only a matter of scale and not one of ease of use.

On the other hand I notice that a relatively high number of new
users (more than 120 people!) have registered for a user id and
password on the Axiom Portal - the Plone site that we run in
parallel to the Wiki. This in spite of the fact that we do not
make much of an effort to advertize it's existence. Plone's user
registration process does seem very easy to use. Oddly perhaps,
like the Axiom Wiki users most of these Portal users also do not
seem to create much in the way of new content. But they were
willing to register. 

Now personally I do not much like sites that require me to register
although I have to admit that I have gotten used to it over the
last couple of years.

So the solution to the spam problem that I like most right now is
to embed the existing Axiom Wiki site inside Plone and use the
standard Wiki skin to keep the same look and feel as the existing
site. This gives us access to the Plone user registration process
which allow us to limit edits and comments to authenticated users
and also would allow us to merge the content of both the Wiki and
the Portal without loosing any functionality.

What do you think?

\start
Date: 14 Aug 2006 03:56:22 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: pamphlet problems

Tim Daly writes:

| sigh.
| 
| noweb, configure, GCL, latex, svn, arch, darcs, etc....
| 
| i think we need to create a new top level file called "PROCON"
| which contains a particular issue and summarizes the arguments
| both for (PRO) and against (CON) a particular decsion. there
| are many topics that keep coming up again and again. the mailing
| list isn't a sufficiently specific way to collect these arguments.
| 
| once these are summarized we can point new people to the file.
| unless some truly new argument is advanced we should not have to
| revisit these decisions.
| 
| agree or disagree?

Sounds familiar to me, so I don't have any objection.

[ that is the way we used to operate for libstdc++ and GCC.  that
does not means decision in stones, just that once we all agree, we
need new inputs, either not available at the time, or based on the
experience gained from following earlier directions. ]

I'm looking forward to the long threads we are going to have :-)

\start
Date: Sun, 13 Aug 2006 19:07:10 -0700
From: Bob McElrath
To: Bill Page
Subject: re: Has anybody attempted to buildAldor+Axiomlately?
Cc: Simon Michael

Bill Page [Bill Page] wrote:
> Mostly I would conclude from this excersize that simply building
> a wiki (however sexy or easy to use) and hoping that people will
> simply show up to create content is misguided. You can point to
> the counter-example of Wikipedia but I am convinced that here the
> difference is only a matter of scale and not one of ease of use.

I would mostly agree.  But there's a lot to be said for ease of use.
More than ease of use I would say simply "aesthetic" -- kludgy, but
pretty interfaces are better than well-designed but ugly ones.
Wikipedia has aesthetic and scale on its side.

> So the solution to the spam problem that I like most right now is
> to embed the existing Axiom Wiki site inside Plone and use the
> standard Wiki skin to keep the same look and feel as the existing
> site. This gives us access to the Plone user registration process
> which allow us to limit edits and comments to authenticated users
> and also would allow us to merge the content of both the Wiki and
> the Portal without loosing any functionality.

I think that's a fine idea.  I think it will handily solve your spam
problem, especially if the plone registration involves email
verification.  I'm not sure what you mean about wiki skins...but the
Plone interface is just fine.

But, plone is dog slow.  I'm not sure how axiom-developer is set up, but
you'll want a caching proxy.

\start
Date: Sun, 13 Aug 2006 22:04:31 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: patches

Ralf,

The books live in the arch archive branch
 book--main--1

see http://arch.axiom-developer.org

\start
Date: Sun, 13 Aug 2006 22:22:36 -0400
From: Bill Page
To: William Sit
Subject: RE: Issues with documentation revisions
Cc: Simon Michael

On August 13, 2006 8:12 PM William Sit wrote:
> 
> > Simon Michael wrote:
> > ...
> > See
> > http://zwiki.org/MathActionTests (and subtopics).
> > 
> 
> I visited the page above and found Tim Daly's AutoDocPamphlet.
> It was a rather simple pamphlet but I found the documentation
> difficult to follow. As an exercise, I totally revised the
> documentation (with a few minor editing of the lisp code, which
> I don't think was for production use).

As a matter of style I agree completely with all of William Sitt's
changes. I think this is a good example of the fact that the
existence of literate programming tools does not guarrantee either
good documentation or good programming. Writing and programming
both involve issues of objective skills and subjective styles. It
is very hard to say in advance what really "works" but it is not
so hard to decide after the fact.

> This experience raised a few issues, in particular, that revising
> documentation may accidentally change the code because the code may
> be editorially revised as well. For details see NewAutodocPamphlet
> by following the link above or read the pdf file from 
> http://zwiki.org/NewAutodocPamphlet
> 

I think this is an important point. I believe that noweb as a literate
programming environment is actually too flexible and generic. It does
not in and of itself encourage good style (either writing or
programming) and without some additional editing tools (such as one
might find as emacs modes) it does not even respect the distinction
between code chunks and documentation.

There is at least one better tool than noweb: Leo

http://webpages.charter.net/edreamleo/front.html

I believe that many of the design features of Leo would be beneficial
to the Axiom project.

\start
Date: Sun, 13 Aug 2006 22:35:14 -0400
From: Bill Page
To: Bob McElrath
Subject: re: Has anybody attempted to buildAldor+Axiomlately?
Cc: Simon Michael

On August 13, 2006 10:07 PM Bob McElrath wrote:
> ...
> Bill Page wrote: 
> > So the solution to the spam problem that I like most right now is
> > to embed the existing Axiom Wiki site inside Plone and use the
> > standard Wiki skin to keep the same look and feel as the existing
> > site. This gives us access to the Plone user registration process
> > which allow us to limit edits and comments to authenticated users
> > and also would allow us to merge the content of both the Wiki and
> > the Portal without loosing any functionality.
> 
> I think that's a fine idea.  I think it will handily solve your
> spam problem, especially if the plone registration involves email
> verification.

Yes.

> I'm not sure what you mean about wiki skins...

http://zwiki.org/HowToUseTheStandardSkinInPlone

> but the Plone interface is just fine.

I like Plone too, but I think a lot of people are put off by the
complex top header menus and the left and right sidebars. We
discussed this back at the beginning of the Axiom Wiki project and
Martin Rubey (who was very active maintaining the content of initial
version of the Axiom Wiki site) was quite adement that *he* did not
like Plone.

When viewing Zwiki inside Plone, I usually feel a kind of clash of
style and a feeling that the limited real estate on my monitor is not
being used very efficiently.

> 
> But, plone is dog slow.

Apparently you have not tried the setup with Zwiki inside Plone
using Standard skins. I think you would be surprized that the
difference in performance seems to be almost entirely due to the
skins.

> I'm not sure how axiom-developer is set up, but you'll want a
> caching proxy.
> 

Axiom-developer uses both an Apache frontend and external cache
provided by the host environment. 

\start
Date: Sun, 13 Aug 2006 22:38:55 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: patches

> I strongly believe that axiom--main--1 should be a "testing" branch and
> things from their should only enter the silver/trunk if they do not
> break anything serious. Note that silver/trunk is supposed to become Gold.

I could be mistaken or confused. Are you suggesting using an SVN
branch called axiom--main--1? Or are you suggesting that the arch
version axiom--main--1 should be considered a testing branch?

In arch, axiom--main--1 is the golden version of the system.
It is supposed to be updated every 2 months. I'm way behind on this
due to conference/work/vacation collisions but testing is nearing
completion. 

axiom--main--1 is a fully tested/blessed version of the system.
It is mirrored on sourceforge (in cvs) and savannah (in cvs) once
it has been uploaded. All three updates occur at the same time.
This has been going on for the past 2 years.

My understanding was that the sourceforge svn was intended to be
a place where people can make and maintain their own branches. This
was previously available to anyone on http://arch.axiom-developer.org
The svn idea has morphed into the silver version of the system which,
as i understand it, is intended to contain proposed changes, similar
to Andrew Morton's -mm branch of linux. Morton's version of linux
has many changes that have never been put in the main branch.

If there is going to be an naming convention in svn it should 
probably NOT have an axiom--main--1 in the tree as this will only
cause confusion.

\start
Date: Sun, 13 Aug 2006 22:42:52 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: patches

> > Should we limit commits to only one file at a time?
> 
> I would say so, since we might accept some changes and reject others. It
> is easier to pick the stuff if you have per-file-commits. I believe that
> it is a bit hard to submit changesets through the webinterface. But it
> should be required to add a reason for the change and that reason should
> become an svn-log.

The philosophical difference between CVS and SVN is the idea of changesets.
In CVS it is not possible, except thru elaborate tagging, to associate a
set of changes of multiple files to a single idea. Axiom uses changesets
in arch as a substitute for tagging. However it would make more sense to
use changesets in svn since it would make it possible to apply a single
change to many files (eg, to update all the makefiles for one global change).
this change might add a feature and be completely independent of every other
change even though it changes multiple files. Limiting commits to one file
at a time makes SVN equivalent to CVS.

\start
Date: Sun, 13 Aug 2006 22:45:29 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: patches

> > Another alternative that I have been thinking about is only 
> > supporting a "diff and patch" interface for the online wiki version 
> > of the source and documentation.
> 
> Maybe some people like diff and patch, I don't. I am not a computer and
> have problems in reading the diffs. It is simply not natural for a human.

diff and patch are not intended to be read by humans. the fact that i
do read them and hand-apply the changes is a part of my twisted personality.
in general though, diff and patch are used virtually everywhere including
source code control systems.

\start
Date: 14 Aug 2006 04:58:29 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: pamphlet problems

Tim Daly writes:

| The token.pamphlet file contained a mistake. It should generate token.h,
| not token.c. hyper.pamphlet does a #include for token.h. This is likely
| a source of errors in the hyperdoc program. I'll fix it.

Please, remember to post the patches when you apply them to then gold
branch.

\start
Date: Sun, 13 Aug 2006 22:54:09 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: patches

> >> I don't like very much that there is a separate (completely 
> >> different looking branch book--main--1).
> 
> > I think originally Tim had in mind that there might be people who 
> > only wished to work on the Axiom documentation.
> 
> Hmmm, that is strange. Axiom should become just one big documentation
> (all is literate). Seems like the book stuff is a project that is
> "about" Axiom but not Axiom itself similar to "The TeXbook" and
> "TeX---The Program". If that was the intension? Then I could understand
> the splitting, but I still believe that we should have everything in
> just one repository. If I come to the Axiom project I would not like to
> learn after some weeks of studying the sources that the Axiom-Book is
> actually another project and doesn't live in axiom--main--1.

The book--main--1 files are subsets of the original Jenks book 
broken along the lines of the first 4 volumes of the 10 volumes
in the axiom project. I had originally been keeping these on my
own systems but people requested that I post them so they could
work on writing them. That's why there is a separate branch. I'm 
unaware of anyone other than myself making changes. 

One of the changes I've been making is to search the axiom mailing
list archive to find emails that are related to particular volumes.
I copy the emails onto the end of the volumes so I know that these
topics need to be covered in the books. This is an example of a
very useful task that would help the books.

Volumes 1 thru 4 do not contain source code. Volumes 5 and onward
do contain source code. That's why Volume 5 is in the source tree.
(src/interp/bookvol5.pamphlet). Volume 1 in the book--main--1 is
now in the source tree as src/doc/bookvol1.pamphlet. Volume 1 is
the axiom tutorial, which has now been published. I'm working on
Volume 2.

\start
Date: 14 Aug 2006 05:02:50 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Has anybody attempted to buildAldor+Axiomlately?
Cc: Simon Michael

Bill Page writes:

[...]

| Mostly I would conclude from this excersize that simply building
| a wiki (however sexy or easy to use) and hoping that people will
| simply show up to create content is misguided. You can point to
| the counter-example of Wikipedia but I am convinced that here the
| difference is only a matter of scale and not one of ease of use.

100% agreed.

[...]

| What do you think?

Can we just have the documentations as part of the SVN repository?

\start
Date: Sun, 13 Aug 2006 23:10:22 -0400
From: Bill Page
To: Tim Daly
Subject: RE: pamphlet problems

On August 13, 2006 9:41 PM Tim Daly wrote:
> 
> sigh.
> 
> noweb, configure, GCL, latex, svn, arch, darcs, etc....
> 
> i think we need to create a new top level file called "PROCON"
> which contains a particular issue and summarizes the arguments
> both for (PRO) and against (CON) a particular decsion. there
> are many topics that keep coming up again and again. the mailing
> list isn't a sufficiently specific way to collect these arguments.
> 
> once these are summarized we can point new people to the file.
> unless some truly new argument is advanced we should not have to
> revisit these decisions.
> 
> agree or disagree?
> 

I think this would be a good use of the Axiom Wiki.

I suggest starting at

http://wiki.axiom-developer.org/AxiomCommunity

Add a comment explaining the intent and the page name

  ProCon

and then click on the blue ? to create the new page.

\start
Date: Sun, 13 Aug 2006 23:09:06 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: patches

> > In fact I think we should drop the entire arch (tla) archive.
> 
> We can. It is as simple as this: remove any reference to any other 
> repository than axiom--main--1 from 
> http://wiki.axiom-developer.org/AxiomSources. If nobody knows about 
> these archives, they are gone.
> 
> But we should ask Tim about it and, in fact, I believe, now that we have 
> the AxiomSources page, they don't hurt that much. What I would actually 
> like to see is how much alive a branch is. But maybe that is asking for 
> too much. Is it possible to see branch activities on sourceforge without 
> actually downloading the branch?

In general, the tla archives are not used by anyone except me so we
can ignore the many branches.

However, the tla archive axiom--main--1 isn't going away any time soon.
It's my main location for work. But axiom is available under tla, svn,
cvs, or darcs so you can choose your own way of working. Posting 
diff -Naur changes to the mailing list allows anyone to see and adopt
your changes. 

In general, it is very difficult to coordinate multiple developers
working in parallel using their own working methods. It is unlikely
that we will all use the same techniques.

\start
Date: Sun, 13 Aug 2006 23:17:14 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: Has anybody attempted to buildAldor+Axiomlately?
Cc: Simon Michael

On August 13, 2006 11:03 PM Gaby wrote:
> 
> Bill Page writes:
> 
> [...]
> 
> | Mostly I would conclude from this excersize that simply building
> | a wiki (however sexy or easy to use) and hoping that people will
> | simply show up to create content is misguided. You can point to
> | the counter-example of Wikipedia but I am convinced that here the
> | difference is only a matter of scale and not one of ease of use.
> 
> 100% agreed.
> 
> [...]
> 
> | What do you think?
> 
> Can we just have the documentations as part of the SVN repository?
> 

??? What "documentations" are you talking about? We do have all of
the available documentation for Axiom in SVN already, don't we?

What does this have to do with the Axiom Wiki?

\start
Date: Sun, 13 Aug 2006 23:32:09 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Building Axiom with unmodified noweb

> > The file src/algebra/Lattice.pamphlet is just 1.7 MB and about
> > 45,000 lines. My emacs dies when it automatically tries to
> > font-lock that file. :-(
> > 
> 
> Yes, it is ridiculously huge. The same is true of several other
> Makefiles. I argued with Tim Daly over this. He claimed that the
> regular structure of these "dirt simple" files makes them easy
> to maintain and he adamantly resisted any sort of more sophisticated
> gnu make methods that would make the files much shorter. I still do
> not accept this view. I think shorter is (almost) always better even
> if it means you have to learn a little more about the tools you are
> using.

font-lock?

Makefiles are rule based programs. Rule based programs are very hard
to debug. Axiom makefiles include debugging information in each stanza
making it trivially easy to figure out what failed (see the echo lines).

Makefiles that are dynamically generated (e.g. using -MM, using awk/sed
or Perl) move the debugging problem "up a level". Axiom maintained
the "dirt simple" principle that every file must have a stanza in the 
makefile. Do you want to know how a file is built? Find the file, look
at the Makefile in that directory. Find the stanza corresponding to that
file. There is your answer. Dirt simple. Easy to learn, easy to extend,
easy to debug, easy to customize. Did something fail? Read the failing
line for the file, search the makefile for the echo number. There is 
the failing stanza. 

Or you can use gcc -MM to create .d files, generate a makefile, dynamically
cons the makefile with the .d files, write out some perl scripts to handle
special cases and create both a perl dependency and a maintenance headache.

Frankly I can't figure out why the Makefiles are so hard to learn. They
are all so regular in structure and follow that dirt simple principle.
Every one except the src/algebra Makefile. And that Makefile will fail
under certain conditions (eg. forgetting to erase it during make clean).

Adding awk/sed/Perl/Python/Ruby/Java/JUnit/ccache/apt/yum/automake
has a complexity cost. Do we really need to depend on Perl to add
10 lines of code to a Makefile? Do we want to get into the problems that
causes? The last time I tried to update Perl on a system it ended
up requiring me to update GCC which broke EVERYTHING else. Oh, and
the next generation is now required to know Perl to maintain axiom.

The problem isn't that I don't understand the complex methods. 
The problem is that I am optimizing toward simplicity. 

\start
Date: Sun, 13 Aug 2006 23:39:38 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: configure on MAC/FreeBSD

Gaby,

I'd suggest testing your configure scripts on both the MAC and FreeBSD,
both of which have given me a great deal of grief. If you can get 
configure to work on those systems it will prove very worthwhile.

\start
Date: Mon, 14 Aug 2006 00:55:18 -0400
From: William Sit
To: Bill Page
Subject: re: Has anybody attempted tobuildAldor+Axiomlately?
Cc: Simon Michael

Bill Page wrote:
> 
> On August 13, 2006 6:16 PM Bob McElrath wrote:
> >
> > I'm gonna vote with Simon here...I know spam is a problem but
> > this is overkill.  Banning http will cause a lot of problems
> > for new users, exactly those a budding young project can't
> > afford to alienate...
> >

I don't agree with Simon's solution, which seems to me to be a stop-gap
fix and not a long term solution. I don't like being limited in the
number of links I post on a Wiki-page. Example pages would be survey
articles with many links. Spammers do not need to post many links.  I
don't like Bill's change either, because since the new method of posting
URL is public, it is only a matter of time when spammers will be able to
write some new script to use the new convention and we will be back to
square one. This change in convention is also costly because we need to
modify all existing link references each time a page using the old
convention is updated. The ban on using "http://" anywhere in the source
is similar to the ban on using "<<" in pamphlet documentation sections.
Simon's solution partially solves this updating problem for now. 

However, I do find it easier to type "Website: abc.com" than
"http://abc.com," or the html way.

> Now personally I do not much like sites that require me to register
> although I have to admit that I have gotten used to it over the
> last couple of years.

I think requiring user registration is a must. A naive suggestion to
make use of the user registration to avoid spam is to ban the user from
editing (put him in a blacklist for say 30 days) once he is known to the
system to have spam any page. Of course, the spammer can create new user
id, and perhaps one can also ban the IP address when repeat new user id
requests come from the same IP. The objective should be to cost the
spammer time, not at the inconvenience of regular users.

Requiring an email address to supply an initial password is also an
effective way to lessen spam. Other sites have also require the user to
read a random gif message and type it back to validate human presence.

Alternatively, we can also maintain a gold list of users, once people
have established their trustworthiness (after some constructive editing
or contribution).

> So the solution to the spam problem that I like most right now is
> to embed the existing Axiom Wiki site inside Plone and use the
> standard Wiki skin to keep the same look and feel as the existing
> site. This gives us access to the Plone user registration process
> which allow us to limit edits and comments to authenticated users
> and also would allow us to merge the content of both the Wiki and
> the Portal without loosing any functionality.
> 
That sounds great. 

\start
Date: Mon, 14 Aug 2006 01:11:46 -0400
From: William Sit
To: Bill Page
Subject: a link to sandbox/edit

May I suggest putting a link sandox, which will open up a new SandBox
page with edit, on the top left of every Wiki page, right between
preferences and help? The page can be named SandBoxyyy where yyy is the
user id. When it is saved, the main sandbox page would be updated with a
link to it. A user can rename the page as well as reparent it as usual.
It would ease navigation each time someone wants to try something. Or at
least link that to 
http://wiki.axiom-developer.org/SandBox if that is not feasible.

I find the set up at the bottom of Zwiki.org quite easy to use. (It
would be even better if it were on the top of a page rather than at the
bottom, which may be missed unless one scrolls all the way down.)

\start
Date: Mon, 14 Aug 2006 01:04:56 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

> I had to make the following modifications to 20050901 to work with the
> latest 2.6.8pre:

Axiom has had several releases since 20050901.
What do we need to do to bring it up to date?

\start
Date: Mon, 14 Aug 2006 01:12:36 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: /dev/null, noweb and Axiom

> > I disagree with the idea that writing to /dev/null should be banned.
> 
> But isn't /dev/null quite Unix-specific? It basically means that in 
> order to build Axiom one must have a Unix-like environment. Not that I 
> want to make the build process more complicated, but I am just curious 
> how difficult it would be to build Axiom without mingw or cygwin.

The use of ${TMP}/null rather than /dev/null is intentional.
Axiom does not write outside of it's directory subtree for any reason.
Following this philosophy it cannot write to /dev/null, which may not
even exist on certain platforms such as windows. 

\start
Date: Sun, 13 Aug 2006 22:26:38 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, William Sit
Subject: RE: Issues with documentation revisions
Cc: Simon Michael

> There is at least one better tool than noweb: Leo
> 
> http://webpages.charter.net/edreamleo/front.html
> 
> I believe that many of the design features of Leo would be beneficial
> to the Axiom project.

I took one run at Leo and bounced - I'm willing to try again, though. 
I may have also thought of a specific example which might be a good
test/showcase.

In outputing TeX instead of ASCII art, there are any number of specific
issues and design decisions that might need to be made on a per-topic
basis - the use of the SI style package for correct formatting of units
being once case I am aware of, another is the use of chemical packages
for LaTeX when implementing chemistry related pamphlets. 
Unfortunately, neither a centralized mechanism for all TeX style
outputs nor spreading these things over many pamphlets is ideal - the
centralized mechanism separates the TeX logic from the conceptual work
that it is linked to, and the diluted method makes a specific display
bug hard to track without knowing exactly what part of the codebase it
relates to.

Leo (if I understand it's concepts) could solve both of these problems.
 If the tex output code is in one or several discrete chuncks, and its
corresponding documentation is also organized this way, then it would
be possible using Leo to assemble either a document with all tex output
code in it (for output debugging) or a document with all code
pertaining to (say) the unit concept, which is more logical for
authoring and updating in a non-debugging context.  Both of these
outputs could be consistent, latexable pamphlet files, just generated
based on the focus of interest at the time of the query.

Bill, is that a reasonable use case for Leo+Axiom?  You are far more
fluent with it than I am.

\start
Date: Mon, 14 Aug 2006 01:22:29 -0400
From: Tim Daly
To: Ed Borasky
Subject: Re: Old Lisp

> 1. As far as I know, GCL and CLISP are the only open source Lisps that 
> run on Windows. CMUCL for sure doesn't and SBCL may not either. CMUCL 
> probably never will, but SBCL has a good chance.

SBCL runs on Windows.

> 2. I think GCL is faster than CLISP.

GCL is compiled code. CLISP is a byte-coded interpreted lisp.

> 3. If you have GCL installed, does Axiom still build its own copy, or 
> does it know about the installed version?

Yes, Axiom builds and uses GCL. It is not yet ansi lisp.

\start
Date: Sun, 13 Aug 2006 23:11:24 -0700
From: Ed Borasky
To: Tim Daly
Subject: Re: Old Lisp

root wrote:
>> 1. As far as I know, GCL and CLISP are the only open source Lisps that 
>> run on Windows. CMUCL for sure doesn't and SBCL may not either. CMUCL 
>> probably never will, but SBCL has a good chance.
>>     
>
> SBCL runs on Windows.
>   
That's good to hear! Native or CygWin?

>   
>> 2. I think GCL is faster than CLISP.
>>     
>
> GCL is compiled code. CLISP is a byte-coded interpreted lisp.
>   
IIRC clisp is what's enabled under CygWin.
>   
>> 3. If you have GCL installed, does Axiom still build its own copy, or 
>> does it know about the installed version?
>>     
>
> Yes, Axiom builds and uses GCL. It is not yet ansi lisp.
>   
My existing GCL is compiled with ANSI support, since Maxima requires
that. Will Axiom work with a GCL (2.6.7 IIRC) with ANSI support enabled?

\start
Date: Mon, 14 Aug 2006 02:12:33 -0400
From: William Sit
To: Bill Page, list
Subject: date of pamphlet documents

When a pamphlet file is rendered, the date of the pdf file is always
\today. That seems to be misleading, as many of the source files have
not been updated for ages. Would it be possible to post the date of the
last modification of the pamphlet file (taken from the file attribute of
the PAMPHLET file, not the tex or pdf file)? Of course, this change of
date from \today to file date should not be done to the pamphlet itself,
but should be part of the extraction process by weave (or better, by the
\usepackage{axiom} using a modified \maketitle macro) so that instead of
inserting \today, one inserts the last modification date of the pamphlet
file (without touching it) to the tex source before applying latex.

BTW, in generating the tex source, perhaps one could also set up to
\usepackage{hyperref}, as part of \usepackage{axiom}? or should this be
left to the author?

Just minor suggestions. Not a high priority if there is no easy
solution.

\start
Date: Sun, 13 Aug 2006 23:28:53 -0700
From: Ed Borasky
To: list
Subject: Re: Issues with documentation revisions

C Y wrote:
> --- Bill Page wrote:
>
>> There is at least one better tool than noweb: Leo
>>
>> http://webpages.charter.net/edreamleo/front.html
>>
>> I believe that many of the design features of Leo would be beneficial
>> to the Axiom project.
>
> I took one run at Leo and bounced - I'm willing to try again, though. 
> I may have also thought of a specific example which might be a good
> test/showcase.
>
> In outputing TeX instead of ASCII art, there are any number of specific
> issues and design decisions that might need to be made on a per-topic
> basis - the use of the SI style package for correct formatting of units
> being once case I am aware of, another is the use of chemical packages
> for LaTeX when implementing chemistry related pamphlets. 
> Unfortunately, neither a centralized mechanism for all TeX style
> outputs nor spreading these things over many pamphlets is ideal - the
> centralized mechanism separates the TeX logic from the conceptual work
> that it is linked to, and the diluted method makes a specific display
> bug hard to track without knowing exactly what part of the codebase it
> relates to.
>
> Leo (if I understand it's concepts) could solve both of these problems.
>  If the tex output code is in one or several discrete chuncks, and its
> corresponding documentation is also organized this way, then it would
> be possible using Leo to assemble either a document with all tex output
> code in it (for output debugging) or a document with all code
> pertaining to (say) the unit concept, which is more logical for
> authoring and updating in a non-debugging context.  Both of these
> outputs could be consistent, latexable pamphlet files, just generated
> based on the focus of interest at the time of the query.
>
> Bill, is that a reasonable use case for Leo+Axiom?  You are far more
> fluent with it than I am.
I am just now trying to learn Leo. My first impression is that it is
*way* too integrated with Python. I'm on the Leo message forums, and
unless you're a Python hacker (which I'm not) most of it goes way over
your head.

I like what Leo is *trying* to be, and I suppose I'll learn how to make
it do what I want *eventually*. But for now, I've more or less fallen
back on more "manual" techniques in my attempts to do "literate
programming."

To be fair, the two languages I'm attempting to program in Leo are R and
Ruby, not Axiom and not Python. On the R side, I've had pretty good luck
with LyX ... it seems to edit the R noweb files (.rnw) directly and not
require a whole lot of messing around to make a usable document. For
now, though, Leo is just an outliner of ASCII text files and not a
"literate programming IDE" for R or Ruby. Good luck with it -- if any of
you have any pointers on how to use it without having to learn Python,
I'm all ears. :)

\start
Date: Mon, 14 Aug 2006 00:27:00 -0700
From: Simon Michael
To: list
Subject: Re: Has anybody attempted tobuildAldor+Axiomlately?

>> So the solution to the spam problem that I like most right now is
>> to embed the existing Axiom Wiki site inside Plone and use the
>> standard Wiki skin to keep the same look and feel

I think this is definitely worth a try. If you're being targetted by 
persistent spammers I too think that requiring a one-time registration for 
edits is the way to go.

\start
Date: Mon, 14 Aug 2006 03:35:12 -0400
From: William Sit
To: Bill Page
Subject: Re: Issues with documentation revisions
Cc: Simon Michael

I updated http://Zwiki.org/NewAutodocPamphlet to use hyperref package
and everything works fine there.

I then tried to copy it to [SandBox NewAutodocPamphlet] and parent it
under [SandBoxPamphlet]. I get some problems when previewing.
Most of these were temporarily solved by avoiding any "http" in the
text. The pdf file read fine and the links worked (subject to bad url
because Website under \href does not get translated; the Zwiki site
allows "http"). There are other problems as well, see [SandBoxPamphlet].

However, after I actually saved it, the pamphlet is not processed
correctly. I even tried to change the makefile section to give some new
names like 'SandBox NewAutodocPamphlet.pamphlet' but that did not work
either. It seems to be a mismatch of file names, or mixing up filenames
with Tim's dhmatrix pamphlet file.

I also tried reparenting it to [SandBox], the error messages were
slightly different, but essentially the same processing problems.

Most importantly, the idea of banning "http" does not work (unless more
code is added) when used with \usepackage{hyperref} if \href is used.
For info on hyperref, see
http://www.etdguide.org/content/3.2.4.2%20%20PDF%20from%20LaTeX.htm .

Any help would be much appreciated. The solution probably requires a
comparison between the setups at Zwiki (where things worked) and Axiom
(where they did'nt).

Many thanks,

William 

PS: I'll be in Vancouver, Canada from Aug 15 to 21. So no need to fix
this immediately.

\start
Date: Mon, 14 Aug 2006 10:29:05 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: pamphlet problems

Why don't people use http://wiki.axiom-developer.org/FAQ for that?
Who would look for a file called PROCON?

Ralf

On 08/14/2006 03:41 AM, root wrote:
> sigh.
> 
> noweb, configure, GCL, latex, svn, arch, darcs, etc....
> 
> i think we need to create a new top level file called "PROCON"
> which contains a particular issue and summarizes the arguments
> both for (PRO) and against (CON) a particular decsion. there
> are many topics that keep coming up again and again. the mailing
> list isn't a sufficiently specific way to collect these arguments.
> 
> once these are summarized we can point new people to the file.
> unless some truly new argument is advanced we should not have to
> revisit these decisions.
> 
> agree or disagree?

\start
Date: Mon, 14 Aug 2006 10:57:45 +0200
From: Ralf Hemmecke
To: William Sit
Subject: Re: Issues with documentation revisions
Cc: Simon Michael

http://zwiki.org/NewAutodocPamphlet

I am not a lisp programmer at all, but the lisp code is missing ">>" so 
I guess, a line like

<<pa SHORT Long=

will be accepted as introducing a code chunk name. I am pretty sure that 
I could even produce a valid Aldor program that contains exactly this line.

William, I like your style much more than the original one from
http://zwiki.org/AutodocPamphlet , but I was once told that I should 
write an executive summary. Honestly, when I read the abstract it was 
not completely clear to me what this program does. It is nice that you 
show the usage, but I must say, if the output is not too long, it is 
also illustrative to include it in the Usage section. (That should even 
be a kind of simple unit test.)

\start
Date: Mon, 14 Aug 2006 11:04:47 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: patches

On 08/14/2006 04:38 AM, root wrote:
>> I strongly believe that axiom--main--1 should be a "testing" branch and
>> things from their should only enter the silver/trunk if they do not
>> break anything serious. Note that silver/trunk is supposed to become Gold.

> I could be mistaken or confused. Are you suggesting using an SVN
> branch called axiom--main--1? Or are you suggesting that the arch
> version axiom--main--1 should be considered a testing branch?

Sorry that was a terrible error on my part. In that mail you refer to
http://lists.nongnu.org/archive/html/axiom-developer/2006-08/msg00175.html
I spoke about http://wiki.axiom-developer.org/axiom--test--1/FrontPage 
and of course I would not turn the Gold branch axiom--main--1 into a 
testing one.

\start
Date: Mon, 14 Aug 2006 11:16:34 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: [Axiom-mail] Re: noweb

> The 'document' script is intended to centralize all of the information
> necessary to extract information from a file in various ways within the
> axiom system. It is ultimately intended to support the drag-and-drop
> feature I'm working on as well as a )compile command in Axiom. Many
> (but not all) of the Makefiles have been changed to use it.

But that script must certainly be improved.

1) It does not call bibtex.
2) It does not call makeindex.
3) It ALWAYS applies latex twice where sometimes 1 application would be 
enough and sometimes one needs 3 or 4 iterations.

\start
Date: Mon, 14 Aug 2006 09:42:40 -0400
From: Bill Page
To: list
Subject: FW: [SAGEdev] SAGE Days 2: First Announcement

On August 14, 2006 4:55 AM William Stein wrote:

Hello,

SAGE Days 2 will take place October 6-10, 2006.

Come and work very hard to build, using the best open source tools
available, what I hope will soon be the finest general purpose
mathematics software available:

      http://modular.math.washington.edu/sage/days2/

\start
Date: Mon, 14 Aug 2006 10:50:05 -0400
From: Bill Page
To: William Sit
Subject: RE: Issues with documentation revisions
Cc: Simon Michael

On August 14, 2006 3:35 AM William Sit wrote:
> 
> I updated http://Zwiki.org/NewAutodocPamphlet to use hyperref package
> and everything works fine there.
>

Nice. I would still like to know why LaTeX does strange things to
< and > in the raw.
 
> I then tried to copy it to [SandBox NewAutodocPamphlet] and parent
> it under [SandBoxPamphlet]. I get some problems when previewing.

There is a bug in the software that occurs if the page name contains
a space.

> Most of these were temporarily solved by avoiding any "http" in the
> text. The pdf file read fine and the links worked (subject to bad url
> because Website under \href does not get translated; the Zwiki site
> allows "http").

I have relaxed the restrictions on the use of http:// on the Axiom
Wiki. Now it is allowed following "...": (the way links are done
in Structured Text) and up to 5 bare occurrences of http://. So it
should now be possible to use http:// (almost) normally again.

> There are other problems as well, see  [SandBoxPamphlet].
>

I am not sure about the rendering of $hp$$pt:$. I think it is a
LaTeX artifact. But this sort of hack shouldn't be necessary any
more.
 
> However, after I actually saved it, the pamphlet is not processed
> correctly. I even tried to change the makefile section to give some
> new names like 'SandBox NewAutodocPamphlet.pamphlet' but that did
> not work either. It seems to be a mismatch of file names, or mixing
> up filenames with Tim's dhmatrix pamphlet file.
> 
> I also tried reparenting it to [SandBox], the error messages were
> slightly different, but essentially the same processing problems.
> 

These problem were all probably caused by the page name that
contained a space. I have removed the space and it seems ok now.

> Most importantly, the idea of banning "http" does not work (unless
> more code is added) when used with \usepackage{hyperref} if \href is
> used. For info on hyperref, see
> http://www.etdguide.org/content/3.2.4.2%20%20PDF%20from%20LaTeX.htm .
>

As I said above, I have relaxed the restriction on the use of http://
 
> Any help would be much appreciated. The solution probably requires a
> comparison between the setups at Zwiki (where things worked) and Axiom
> (where they did'nt).

Again the difference was caused just by the blank in the page name.
I will correct this bug in the near future.

> 
> Many thanks,
> 
> William 
> 
> 
> PS: I'll be in Vancouver, Canada from Aug 15 to 21. So no need to fix
> this immediately.
> 

\start
Date: Mon, 14 Aug 2006 10:58:21 -0400
From: Bill Page
To: William Sit
Subject: RE: date of pamphlet documents

On August 14, 2006 2:13 AM William Sit wrote:
> 
> When a pamphlet file is rendered, the date of the pdf file is always
> \today. That seems to be misleading, as many of the source files have
> not been updated for ages.

I think the use of \today in the LaTeX source is inappropriate unless
for some reason the author really does want the date on which the
document was compiled displayed in the text. Usually it is better
to simply hard code a fixed date and manually update that when it
is appropriate.

> Would it be possible to post the date of the last modification of
> the pamphlet file (taken from the file attribute of the PAMPHLET
> file, not the tex or pdf file)? Of course, this change of date from
> \today to file date should not be done to the pamphlet itself, but
> should be part of the extraction process by weave (or better, by
> the \usepackage{axiom} using a modified \maketitle macro) so that 
> instead of inserting \today, one inserts the last modification date
> of the pamphlet file (without touching it) to the tex source before
> applying latex.

That is a neat idea, but it is a LaTeX thing that is beyond my skill
level in LaTeX. If there was such a macro that used the file date,
then we could use that in our pamphlet files.

> 
> BTW, in generating the tex source, perhaps one could also set up
> to \usepackage{hyperref}, as part of \usepackage{axiom}? or 
> should this be left to the author?

I think it should be left to the author.

> 
> Just minor suggestions. Not a high priority if there is no easy
> solution.
> 

\start
Date: 14 Aug 2006 17:21:21 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: patches

Tim Daly writes:

| > > Another alternative that I have been thinking about is only 
| > > supporting a "diff and patch" interface for the online wiki version 
| > > of the source and documentation.
| > 
| > Maybe some people like diff and patch, I don't. I am not a computer and
| > have problems in reading the diffs. It is simply not natural for a human.
| 
| diff and patch are not intended to be read by humans. 

Maybe.  The fact that we have so many diff options (in particular -p)
is evidence that it is intended to be read by humans, albeit with
particular skill set. 

\start
Date: 14 Aug 2006 17:23:24 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: patches

Tim Daly writes:

[...]

| In general, it is very difficult to coordinate multiple developers
| working in parallel using their own working methods. It is unlikely
| that we will all use the same techniques.

That is true.  However, to make sure we don't end up in a bizarre
situation, we must have a live mainline source.

\start
Date: 14 Aug 2006 17:29:01 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Building Axiom with unmodified noweb

Tim Daly writes:

[...]

| Frankly I can't figure out why the Makefiles are so hard to learn.

I don't think Makefiles in general are that very hard.  Just like one
may write very twisted spaghetti codes in higher level programming
languages, one can write hard to understand Makefiles.

I happen to find Axiom Makefiles quite non-palatable.  Part of the
problem is that similar information are not properly abstracted over
and particular information of interested are deeply hidden in a sea of
noise. Fortunately, we're working to improve thge situation.

\start
Date: 14 Aug 2006 17:29:51 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [Axiom-mail] Re: noweb

Ralf Hemmecke writes:

| > The 'document' script is intended to centralize all of the information
| > necessary to extract information from a file in various ways within the
| > axiom system. It is ultimately intended to support the drag-and-drop
| > feature I'm working on as well as a )compile command in Axiom. Many
| > (but not all) of the Makefiles have been changed to use it.
| 
| But that script must certainly be improved.

I would like to see the document script either go away or deeply improved.

\start
Date: 14 Aug 2006 17:33:31 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: /dev/null, noweb and Axiom

Tim Daly writes:

| > > I disagree with the idea that writing to /dev/null should be banned.
| > 
| > But isn't /dev/null quite Unix-specific? It basically means that in 
| > order to build Axiom one must have a Unix-like environment. Not that I 
| > want to make the build process more complicated, but I am just curious 
| > how difficult it would be to build Axiom without mingw or cygwin.
| 
| The use of ${TMP}/null rather than /dev/null is intentional.

I know it is intentional.  However, I seriously question the decision
behind it. 

Anyway, currently ${TMP}/null is useless one build noweb.

| Axiom does not write outside of it's directory subtree for any reason.
| Following this philosophy it cannot write to /dev/null, which may not
| even exist on certain platforms such as windows. 

That is close to theology.  /dev/null is very particular and must be
exempted from the general rule.

Which "flavour" of windows that can built Axiom (with current build
system) and does not have /dev/null?

\start
Date: 14 Aug 2006 17:34:28 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Has anybody attempted to buildAldor+Axiomlately?
Cc: Simon Michael

Bill Page writes:

| On August 13, 2006 11:03 PM Gaby wrote:
| > 
| > Bill Page writes:
| > 
| > [...]
| > 
| > | Mostly I would conclude from this excersize that simply building
| > | a wiki (however sexy or easy to use) and hoping that people will
| > | simply show up to create content is misguided. You can point to
| > | the counter-example of Wikipedia but I am convinced that here the
| > | difference is only a matter of scale and not one of ease of use.
| > 
| > 100% agreed.
| > 
| > [...]
| > 
| > | What do you think?
| > 
| > Can we just have the documentations as part of the SVN repository?
| > 
| 
| ??? What "documentations" are you talking about?

The one we currently have as wiki.

\start
Date: 14 Aug 2006 17:36:53 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: configure on MAC/FreeBSD

Tim Daly writes:

| Gaby,
| 
| I'd suggest testing your configure scripts on both the MAC and FreeBSD,

I don't have access to a MAC of a freebsd, thay is why I repeatedly
call for testing and feedback.  If you have problems, please send me
the logs so that I can look into the problems.  Otherwise, I cannot do
anything. 

\start
Date: Mon, 14 Aug 2006 13:08:07 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: /dev/null, noweb and Axiom

> | > > I disagree with the idea that writing to /dev/null should be banned.
> | > 
> | > But isn't /dev/null quite Unix-specific? It basically means that in 
> | > order to build Axiom one must have a Unix-like environment. Not that I 
> | > want to make the build process more complicated, but I am just curious 
> | > how difficult it would be to build Axiom without mingw or cygwin.
> | 
> | The use of ${TMP}/null rather than /dev/null is intentional.
> 
> I know it is intentional.  However, I seriously question the decision
> behind it. 
> 
> Anyway, currently ${TMP}/null is useless one build noweb.
> 
> | Axiom does not write outside of it's directory subtree for any reason.
> | Following this philosophy it cannot write to /dev/null, which may not
> | even exist on certain platforms such as windows. 
> 
> Which "flavour" of windows that can built Axiom (with current build
> system) and does not have /dev/null?

It's not a question of theology or flavors (or flavours).  The issue
again comes back to basic, easily stated, easily learned, universally
followed principles. In Axiom 

  all files are literate.  
  all directories have Makefiles that handle their subtrees.  
  all Makefiles have a stanza per file (or used to)
  all stanzas have unique identifing numbers
  all non-axiom tools live under zips
  all human written files live under SRC
  all machine-generated, system-independent files live under INT
  all machine-generated, system-dependent files live under OBJ
  all final shipped files live under MNT. 
  all literate files use the same bibtex file or will once we get it working.
  etc...


If you state a principle there is nothing else to explain.

The guiding principle in this case is that 

  Axiom never writes outside its own directory

Thus Axiom does not use /tmp but creates and saves files in OBJ. Axiom
does not use /dev/null by the same principle.  It cannot and does not
assume that /dev exists. It doesn't need to make that assumption since
the ${TMP}/null file is always overwritten unless the build fails. And
if the build fails you have a record of the last failure. So /dev/null
is not needed and loses information.

Every effort is made to use the simple and most general rules.  At one
point Axiom's Makefiles worked both under traditional 'make' and 'gnu
make'. Now they have been changed to only work under 'gnu make'. This
makes porting to the MAC, FreeBSD, and Solaris ever so much more
tedious. Axiom used to build cleanly under Solaris. It no longer does.
In the 30 year horizon view, this is not progress.

> That is close to theology.  /dev/null is very particular and must be
> exempted from the general rule.
> 

Why? If we assume /dev/null exists we will open ourselves to a porting
issue as soon as we attempt a native Windows port. The current system
does not have that problem. Why introduce it? And under what principle?
I don't see why we 'must' do anything special. 

\start
Date: Mon, 14 Aug 2006 13:34:00 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: Has anybody attempted to buildAldor+Axiomlately?
Cc: Simon Michael

On August 14, 2006 11:34 AM Gaby wrote:

> ... 
> | > 
> | > Can we just have the documentations as part of the SVN
> | > repository?
> | > 
> | 
> Bill Page writes:
> | ??? What "documentations" are you talking about?
> 
> The one we currently have as wiki.
> 

Your question, or perhaps more accurately the assumptions behind
your question, still seems unclear to me.

SVN is a source code repository. The wiki is a web site with
dynamic content, e.g. the results of Axiom calculations, and
the status of issue reports etc. So I think the answer to your
question is: No.

\start
Date: Mon, 14 Aug 2006 13:41:02 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: configure on MAC/FreeBSD

On August 14, 2006 11:37 AM Gabriel Dos Reis wrote:
> 
> Tim Daly writes:
> 
> | Gaby,
> | 
> | I'd suggest testing your configure scripts on both the MAC 
> and FreeBSD,
> 
> I don't have access to a MAC of a freebsd, thay is why I repeatedly
> call for testing and feedback.  If you have problems, please send me
> the logs so that I can look into the problems.  Otherwise, I cannot
> do anything. 
> 

I do not mean to imply the Gaby should be doing this additional work,
since he is already doing a great deal to improve the build environment,
but in fact we do have easy access to these systems.

http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1

The following OS platforms and hardware architectures are represented in
the SourceForge.net Compile Farm:

32-bit x86 Architecture:

    * x86-linux2: Fedora Linux FC2 running Linux 2.6 kernel
    * x86-openbsd1: OpenBSD 3.4
    * x86-solaris1: Sun Solaris 9
    * x86-linux1: Debian GNU/Linux 3.0 running Linux 2.4 kernel
    * x86-freebsd1: FreeBSD 4.8
    * x86-netbsd1: NetBSD 1.6.1

AMD 64-bit (Opteron) Architecture:

    * amd64-linux1: Fedora Core release 3 running Linux 2.6 kernel
    * amd64-linux2: Fedora Core release 3 running Linux 2.6 kernel

DEC Alpha (ev67) Architecture:

    * alpha-linux1: Debian GNU/Linux 3.0 running Linux 2.2 kernel

PowerPC Architecture:

    * ppc-osx1: Apple Mac OS X 10.1 Server with Fink running on an
      Apple Mac G4
    * ppc-osx2: Apple Mac OS X 10.2 Server with Fink running on an
      Apple Mac G4

Sparc (UltraSPARC-II) Architecture:

    * sparc-solaris1, sparc-solaris2: Sun Solaris 9, running on two
      Sun Enterprise 220R systems

IBM Power5 Architecture:

    * openpower-linux1: SuSE Enterprise Linux 9, running on an IBM
      OpenPower 720 (e-Series) host.

-----------

Anyone who is motivated to try this can be registered as an Axiom developer
to try the Axiom builds on these systems.

\start
Date: Mon, 14 Aug 2006 19:55:22 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: Has anybody attempted to buildAldor+Axiomlately?
Cc: Simon Michael

>> | > Can we just have the documentations as part of the SVN
>> | > repository?

> SVN is a source code repository. The wiki is a web site with
> dynamic content, e.g. the results of Axiom calculations, and
> the status of issue reports etc. So I think the answer to your
> question is: No.

I can understand Gaby. For working offline it would be good to have the 
wiki locally and have it updated like any SCM repository. But it seems 
that cannot be easily achieved, because at least one needs to set up 
Zope, Zwiki, latexwiki, mathaction on the local computer. That is hard 
enough. And always downloading a >1MB Zope database if just a single 
file changes is not very convenient.

So, I guess, the answer is: "Currently, no. Until somebody improves the 
situation."

\start
Date: Mon, 14 Aug 2006 19:58:12 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: /dev/null, noweb and Axiom

> It's not a question of theology or flavors (or flavours).  The issue
> again comes back to basic, easily stated, easily learned, universally
> followed principles. In Axiom 
> 
>   all files are literate.  
>   all directories have Makefiles that handle their subtrees.  
>   all Makefiles have a stanza per file (or used to)
>   all stanzas have unique identifing numbers
>   all non-axiom tools live under zips
>   all human written files live under SRC
>   all machine-generated, system-independent files live under INT
>   all machine-generated, system-dependent files live under OBJ
>   all final shipped files live under MNT. 
>   all literate files use the same bibtex file or will once we get it working.
>   etc...

Thank you, Tim, for sharing these principles with the rest of the axiom 
developers. I did not know all of them. Where are they written down, 
except now hidden in the mailing archive under a strange "Subject"???

\start
Date: Mon, 14 Aug 2006 20:05:29 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [Axiom-mail] Re: noweb

> | > The 'document' script is intended to centralize all of the information
> | > necessary to extract information from a file in various ways within the
> | > axiom system. It is ultimately intended to support the drag-and-drop
> | > feature I'm working on as well as a )compile command in Axiom. Many
> | > (but not all) of the Makefiles have been changed to use it.
> | 
> | But that script must certainly be improved.
> 
> I would like to see the document script either go away or deeply improved.

Oh, another person who does not like "document" very much...

I can understand Tim's idea of a drag&drop system, but it implies that a 
new "algebra idea" is completely coded in ONE file. It's not like the 
"changeset" stuff. And for the Axiom build system it would be better to 
have not just a collection of Makefiles that you document (and read) 
separately. It is really hard to get an overview of what relates to 
what. I would rather like to have a document that describes the build. 
But I guess that document consists of several Makefiles and a 
description of their relations.

\start
Date: Mon, 14 Aug 2006 14:00:08 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: /dev/null, noweb and Axiom

The SRC/INT/OBJ/MNT principles are in README (near line 416)
The Makefile principles are in Makefile.pamphlet, first paragraph

\start
Date: Mon, 14 Aug 2006 14:02:10 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: /dev/null, noweb and Axiom

The Makefile principles are also in Makefile.pamphlet, near line 157.
The restriction about not writing outside the source tree is on line 202.

\start
Date: 14 Aug 2006 20:17:25 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: /dev/null, noweb and Axiom

Tim Daly writes:

| > | > > I disagree with the idea that writing to /dev/null should be banned.
| > | > 
| > | > But isn't /dev/null quite Unix-specific? It basically means that in 
| > | > order to build Axiom one must have a Unix-like environment. Not that I 
| > | > want to make the build process more complicated, but I am just curious 
| > | > how difficult it would be to build Axiom without mingw or cygwin.
| > | 
| > | The use of ${TMP}/null rather than /dev/null is intentional.
| > 
| > I know it is intentional.  However, I seriously question the decision
| > behind it. 
| > 
| > Anyway, currently ${TMP}/null is useless one build noweb.
| > 
| > | Axiom does not write outside of it's directory subtree for any reason.
| > | Following this philosophy it cannot write to /dev/null, which may not
| > | even exist on certain platforms such as windows. 
| > 
| > Which "flavour" of windows that can built Axiom (with current build
| > system) and does not have /dev/null?
| 
| It's not a question of theology or flavors (or flavours). 

I'm sorry to say, but a principle followed blinded without taking into
account reality is theology.

[...]

| If you state a principle there is nothing else to explain.

That *is* theology.

| The guiding principle in this case is that 
| 
|   Axiom never writes outside its own directory

This *is simply untrue*, at least if you build Axiom+GCL.

[...]

| > That is close to theology.  /dev/null is very particular and must be
| > exempted from the general rule.
| > 
| 
| Why?

Because there simply is no single system on which Axiom has been built
and where it was impossible to redirect to /dev/null/  That is a
*fact*.  Your principles must take that fact into account.

| If we assume /dev/null exists we will open ourselves to a porting
| issue as soon as we attempt a native Windows port.

Exactly on which windows where will you be able to build Axiom without the
ability to rediect to /dev/null.  I believe you are trying to solve a
theoretical problems that has no practical foundation.


As a data point, there are plenty of software Autoconfiscated that
build and runs perfectly on windows.

\start
Date: Mon, 14 Aug 2006 14:23:02 -0400
From: Alfredo Portes
To: Ralf Hemmecke
Subject: re: Has anybody attempted to buildAldor+Axiomlately?
Cc: Simon Michael

> I can understand Gaby. For working offline it would be good to have the
> wiki locally and have it updated like any SCM repository. But it seems
> that cannot be easily achieved, because at least one needs to set up
> Zope, Zwiki, latexwiki, mathaction on the local computer. That is hard
> enough.
>

  The installation of Zope -> ZWiki -> LatexWiki -> Mathaction is has
not been that difficult, at least in the systems I have tried them
(Fedora, Ubuntu, Gentoo).  With the work done by Bill, and the
information online I would dare to say that has become "trivial".  For
Doyen, a single script does the whole installation. Of course, this is
not bullet proof for every system. A virtual machine can be also a
solution.

 And always downloading a >1MB Zope database if just a single
> file changes is not very convenient.
>

   I wonder if one could have the Zope database on svn and then do an
update to keep with the latest changes.

\start
Date: Mon, 14 Aug 2006 14:15:42 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: [Axiom-mail] Re: noweb

> Oh, another person who does not like "document" very much...

'document' is a script intended to collect the usual document handling
functions which standard options. i put it there so i can use it to
build files during make and later to build files during development.
it's unlikely that you would use it yet.

> I can understand Tim's idea of a drag&drop system, but it implies that a 
> new "algebra idea" is completely coded in ONE file. It's not like the 
> "changeset" stuff. And for the Axiom build system it would be better to 
> have not just a collection of Makefiles that you document (and read) 
> separately. It is really hard to get an overview of what relates to 
> what. I would rather like to have a document that describes the build. 
> But I guess that document consists of several Makefiles and a 
> description of their relations.

That's the purpose of book volume 4, the developer's guide. 
Understand the process, write it as a chapter, and add it to the guide.

\start
Date: 14 Aug 2006 20:31:50 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: configure on MAC/FreeBSD

Bill Page writes:

| On August 14, 2006 11:37 AM Gabriel Dos Reis wrote:
| > 
| > Tim Daly writes:
| > 
| > | Gaby,
| > | 
| > | I'd suggest testing your configure scripts on both the MAC 
| > and FreeBSD,
| > 
| > I don't have access to a MAC of a freebsd, thay is why I repeatedly
| > call for testing and feedback.  If you have problems, please send me
| > the logs so that I can look into the problems.  Otherwise, I cannot
| > do anything. 
| > 
| 
| I do not mean to imply the Gaby should be doing this additional work,
| since he is already doing a great deal to improve the build environment,
| but in fact we do have easy access to these systems.

Bill, thank you very much for sharing this information with me.  
I suspected we somehow had access to SF machines but did not know how
to get them.  I should have asked.

I'm certainly an amateur as far as Axiom goes, but not an amateur for
large projects development so I don't take offense :-)
It certainly makes sense that large infrastracture changes be tested
on at least three primary targets before committing to mainline --
though we should not put the dogma to require that all platforms are
tested before committing to mainline.

As a matter of fact, on purpose I did NOT propose to merge the 
"build improvements" work to mainline because I do not feel satisfied
with it.  Rather, I've begged for testing from people, and I thank all
of you who tested and send feedback either publically or privately.
I'm committed to improve this and propose it for mainline (i.e. silver).
It will be up to Tim whether he wants it for the gold branch.

I will like us to define "primary platforms" and "secondary platforms".
A primary platform is one where any regression must be fixed after it
is noticed or the patch reverted if its author cannot fix it in timely
manner (e.g. within 48 hours).  We cannot maintian silver broken for a
known primary platform.

A secondary platform is one where the patch reversal ruls has a
relaxed content.

For concretness, here is a initial list of primary platforms:

  * i686-pc-linux-gnu
  * x86_64-*-linux
  * stable supported *BSD
  * powerpc-*-darwin*

[...]

| Anyone who is motivated to try this can be registered as an Axiom developer
| to try the Axiom builds on these systems.

I have a private script for automatically building Axiom; do you think
there is a was to set up a cron job on those systems?

\start
Date: Mon, 14 Aug 2006 11:32:36 -0700
From: Bob McElrath
To: Alfredo Portes
Subject: re: Has anybody attempted to buildAldor+Axiomlately?
Cc: Simon Michael

Alfredo Portes [Alfredo Portes] wrote:
> >I can understand Gaby. For working offline it would be good to have the
> >wiki locally and have it updated like any SCM repository. But it seems
> >that cannot be easily achieved, because at least one needs to set up
> >Zope, Zwiki, latexwiki, mathaction on the local computer. That is hard
> >enough.

Well, one could always set up FileSystemSite:
    http://www.infrae.com/download/FileSystemSite
and put the wiki there.  It is a single directory after all.  That would
help with SCM.

Then one could just "pull" the entire wiki as a series of text files.  I
think if the relevant directory were under svn/cvs/darcs control, the
wiki will ignore the extraneous files.  Of course, what happens when
Zope writes an update to a wiki file?

> And always downloading a >1MB Zope database if just a single
> >file changes is not very convenient.
> 
>   I wonder if one could have the Zope database on svn and then do an
>   update to keep with the latest changes.

The entire zope database!?!?  One big 1GB file?  Each minor ZODB change
would be a single replacement of the ~1GB ZODB.  -- Which is why
FileSystemSite is probably required if you want to use SCM.

\start
Date: 14 Aug 2006 20:36:27 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [Axiom-mail] Re: noweb

Ralf Hemmecke writes:

| > | > The 'document' script is intended to centralize all of the information
| > | > necessary to extract information from a file in various ways within the
| > | > axiom system. It is ultimately intended to support the drag-and-drop
| > | > feature I'm working on as well as a )compile command in Axiom. Many
| > | > (but not all) of the Makefiles have been changed to use it.
| > | | But that script must certainly be improved.
| > I would like to see the document script either go away or deeply
| > improved.
| 
| Oh, another person who does not like "document" very much...

It stands in my way for having a more structured build system.

When in the cyle design-code-build-test; I don't need all those dvi
that document insist on building.  I have configure generate my
Makefiles, but document want to generate its own.

document was a necessary step to get Axiom to the state where it is
now.  But now, it either has to give the way or mutate significantly.
Most of the functionalities offered by document are superceded in my
work. So, unless, it mutates and offers me something I need and I don't
have now, it must be retired.

\start
Date: Mon, 14 Aug 2006 14:33:37 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: /dev/null, noweb and Axiom

....[snip]....

> | It's not a question of theology or flavors (or flavours). 
> 
> I'm sorry to say, but a principle followed blinded without taking into
> account reality is theology.
> 
> [...]
> 
> | If you state a principle there is nothing else to explain.
> 
> That *is* theology.

ok. if you insist lets call it theology. i'll be the cleric.
where did i put my stone chisels......



> 
> | The guiding principle in this case is that 
> | 
> |   Axiom never writes outside its own directory
> 
> This *is simply untrue*, at least if you build Axiom+GCL.


it is untrue? i'm confused.

axiom builds gcl in the lsp subdirectory which is contained
within the axiom build tree. 





> 
> [...]
> 
> | > That is close to theology.  /dev/null is very particular and must be
> | > exempted from the general rule.
> | > 
> | 
> | Why?
> 
> Because there simply is no single system on which Axiom has been built
> and where it was impossible to redirect to /dev/null/  That is a
> *fact*.  Your principles must take that fact into account.

and every single system has /tmp but we don't use it.

the ${TMP} directory was created because i ran into a build problem.
another user tried to build Axiom and was using files on /tmp with
the same name. this caused permission problems and caused the build 
to fail. this can't happen anymore.





> 
> | If we assume /dev/null exists we will open ourselves to a porting
> | issue as soon as we attempt a native Windows port.
> 
> Exactly on which windows where will you be able to build Axiom without the
> ability to rediect to /dev/null.  I believe you are trying to solve a
> theoretical problems that has no practical foundation.
> 
> 
> As a data point, there are plenty of software Autoconfiscated that
> build and runs perfectly on windows.


i understand your point that /dev/null seems "ok".
the current ${TMP}/null works.
why change it? did something break?

Father O'Daly.
Chief Cleric and Wearer of Strange Hats.

\start
Date: 14 Aug 2006 20:56:14 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: configure on MAC/FreeBSD

Gabriel Dos Reis writes:

[...]

| I have a private script for automatically building Axiom; do you think
| there is a was to set up a cron job on those systems?

I found answer to my question.  It is "yes".

\start
Date: Mon, 14 Aug 2006 14:50:25 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: [Axiom-mail] Re: noweb

> It stands in my way for having a more structured build system.
> 
> When in the cyle design-code-build-test; I don't need all those dvi
> that document insist on building.  I have configure generate my
> Makefiles, but document want to generate its own.
> 
> document was a necessary step to get Axiom to the state where it is
> now.  But now, it either has to give the way or mutate significantly.
> Most of the functionalities offered by document are superceded in my
> work. So, unless, it mutates and offers me something I need and I don't
> have now, it must be retired.

eh? again i'm confused.

'document' is like 'tar', it handles a pamphlet file format with options
just like 'tar' handles gzip files.

'document' is intended to be the primary command used throughout axiom
to manipulate pamphlets, including drag-and-drop. it also handles 
issues of "NOISE" which is a top-level make function. if you say

   make NOISE=

you will see all of the latex output. without the NOISE= it will
not output the latex. the makefiles don't need to know how to
suppress noise.

there is no reason that the makefiles need to know about the
command sequences necessary to translate pamphlet files just like
there is no reason that makefiles need to know how to gunzip tar files.

why would a single command which centralizes all of the knowledge
of how to translate a pamphlet to tex, dvi, pdf, spad, etc be an issue?

lost, perhaps in limbo,

Tim
The Monty Python Wizard

\start
Date: 14 Aug 2006 21:02:26 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: /dev/null, noweb and Axiom

Tim Daly writes:

[...]

| > | The guiding principle in this case is that 
| > | 
| > |   Axiom never writes outside its own directory
| > 
| > This *is simply untrue*, at least if you build Axiom+GCL.
| 
| it is untrue?

Yes, GCL's configure redirects to /dev/null.

Frankly, the Autotools guys have faced more exotic systems than Axiom
is likely to ever face.

[...]

| and every single system has /tmp but we don't use it.

That really it is very different issue.  /dev/null *is* special.

[...]

| the current ${TMP}/null works.

No, it does not.  After noweb is built, have a look at ${TMP}/null; is
that what you were expecting?
On all my builds, I see elisp file for emacs support for noweb.

| why change it?

it does not work and it is mostly pointless.

| Father O'Daly.
| Chief Cleric and Wearer of Strange Hats.

:-)

\start
Date: Mon, 14 Aug 2006 15:04:29 -0400
From: William Sit
To: Bill Page
Subject: Re: date of pamphlet documents

Bill Page wrote:
> 
> On August 14, 2006 2:13 AM William Sit wrote:
> >
> > When a pamphlet file is rendered, the date of the pdf file is always
> > \today. That seems to be misleading, as many of the source files have
> > not been updated for ages.
> 
> I think the use of \today in the LaTeX source is inappropriate unless
> for some reason the author really does want the date on which the
> document was compiled displayed in the text. Usually it is better
> to simply hard code a fixed date and manually update that when it
> is appropriate.

I tend to agree, but that puts the burden on whoever revises a file
(which adds one more tiny step to the process). I would prefer if is
done automatically.
The \today seems to be a default when \date is not present in the tex
source.
I now added \date to NewAutodocPamphlet (and some other additional
documentation).

> > Would it be possible to post the date of the last modification of
> > the pamphlet file (taken from the file attribute of the PAMPHLET
> > file, not the tex or pdf file)? Of course, this change of date from
> > \today to file date should not be done to the pamphlet itself, but
> > should be part of the extraction process by weave (or better, by
> > the \usepackage{axiom} using a modified \maketitle macro) so that
> > instead of inserting \today, one inserts the last modification date
> > of the pamphlet file (without touching it) to the tex source before
> > applying latex.
> 
> That is a neat idea, but it is a LaTeX thing that is beyond my skill
> level in LaTeX. If there was such a macro that used the file date,
> then we could use that in our pamphlet files.

No, the latex thing is simply to add a line \date{...} where you can put
pretty much anything there (see [SandBoxNewAutodocPamphlet]).  It can be
done probably  with a unix hack to obtain the date of last modification
(maybe looking at the inode of the file system). However, I am sure
there is a utility to do just that.
Once the date is known, some batch editor can insert the \date line into
the generated latex file (it has to also detect that no \date line is
there), right before \maketitle. Alternately, may be those in the know
can make a \filedate macro. Any takers?

Come to think of it, each pamphlet file should include a revision
history, with dates, much like code. So we should have latex macros
\creationdate, \revisiondates, and \filedate (which may be included in
\revisiondates).

> >
> > BTW, in generating the tex source, perhaps one could also set up
> > to \usepackage{hyperref}, as part of \usepackage{axiom}? or
> > should this be left to the author?
> 
> I think it should be left to the author.

I think pamphlet docs should be more uniform in general appearance. Why
would anyone be against using hyperref?

BTW, there is an error in [SandBoxNewAutodocPamphlet]:

Traceback (most recent call last): File
"/var/zope/Products/ZWiki/plugins/Fit.py", line 29, in ? from fit.Parse
import Parse ImportError: No module named fit.Parse

The file does display correctly as far as I can tell.

I think I will remove NewAutodocPamphlet from the Zwiki site (so I don't
have to maintain two versions, the zwiki version is already out of date
:-). I'll leave a pointer there to SandBox. What do you think?

\start
Date: Mon, 14 Aug 2006 21:14:29 +0200
From: David Mentre
To: William Sit
Subject: Revision history (was: re: date of pamphlet documents)

As Bill, I think hard-coded modification date is preferable, as it
allows minor modification (e.g. fixing typo). Of course, it depends on
the semantics you espect on the date.

William Sit writes:

> Come to think of it, each pamphlet file should include a revision
> history, with dates, much like code. So we should have latex macros
> \creationdate, \revisiondates, and \filedate (which may be included in
> \revisiondates).

Doesn't that revision history belong to the changesets of the Source
Code Management system, whichever it is?

\start
Date: 14 Aug 2006 21:14:40 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [Axiom-mail] Re: noweb

Tim Daly writes:

| > It stands in my way for having a more structured build system.
| > 
| > When in the cyle design-code-build-test; I don't need all those dvi
| > that document insist on building.  I have configure generate my
| > Makefiles, but document want to generate its own.
| > 
| > document was a necessary step to get Axiom to the state where it is
| > now.  But now, it either has to give the way or mutate significantly.
| > Most of the functionalities offered by document are superceded in my
| > work. So, unless, it mutates and offers me something I need and I don't
| > have now, it must be retired.
| 
| eh? again i'm confused.
| 
| 'document' is like 'tar', it handles a pamphlet file format with options
| just like 'tar' handles gzip files.

Here is the content of 'document' (silver branch, same as gold branch).

    #!/bin/sh
    latex=`which latex`
    if [ "$latex" = "" ] ; then
      echo document ERROR You must install latex first
      exit 0
    fi

    tangle=$AXIOM/bin/lib/notangle
    weave=$AXIOM/bin/lib/noweave
    if [ "$#" = "3" ]; then
     REDIRECT=$2
     FILE=`basename $3 .pamphlet`
     $tangle -t8 $FILE.pamphlet >$FILE
     $weave -delay $FILE.pamphlet >$FILE.tex
     $latex --interaction nonstopmode $FILE.tex >$REDIRECT
     $latex --interaction nonstopmode $FILE.tex >$REDIRECT
     rm -f $FILE~
     rm -f $FILE.pamphlet~
     rm -f $FILE.log
     rm -f $FILE.tex
     rm -f $FILE.toc
     rm -f $FILE.aux
     exit 0
    fi
    if [ "$#" = "1" ]; then
     FILE=`basename $1 .pamphlet`
     $tangle -t8 $FILE.pamphlet >$FILE
     $weave -delay $FILE.pamphlet >$FILE.tex
     $latex $FILE.tex 
     $latex $FILE.tex
     rm -f $FILE~
     rm -f $FILE.pamphlet~
     rm -f $FILE.log
     rm -f $FILE.tex
     rm -f $FILE.toc
     rm -f $FILE.aux
     exit 0
    fi
    echo "document [ -o redirect ] pamphlet"


As you can see, document insists on LaTeXing a file, which, as I said,
when in a design-code-build-test mode, I'm not interested in.  It just
wastes my time.  I rather have a separate [hase for building .dvi
files than trying to conflate everything together.  Maybe that mode
will be only for developers, but then document is not my solution.

Futhermore, my Makefiles are generated from configure using .in files
as inputs (the infiles themselves are generated from pamphlet files)
-- I don't want document to touch them, it simply it not sophisticated
enough to understand what is going on.

On the build-improvements branch for example, here is the sequence of
events:

  * developer edits Makefile.pamphlet.
  * developer produces Makefile.in from pamphlet files

  * users invokes ./configure
  * configure reads in Makefile.in, compute values for some
    placeholders  in Makefile.in (Makefile.pamphlet) and instantiate
    Makefile (in the build directory) reflection configure options,
    build and target systems.

document can't understand that and handle that.

BTW, document has been modified (on the build-improvments branch) to
the point where it can use either system supplied noweb or noweb from
aXiom.  And document is also generated by configure.

\start
Date: Mon, 14 Aug 2006 15:47:18 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: [Axiom-mail] Re: noweb

> As you can see, document insists on LaTeXing a file, which, as I said,
> when in a design-code-build-test mode, I'm not interested in.  It just
> wastes my time.  I rather have a separate [hase for building .dvi
> files than trying to conflate everything together.  Maybe that mode
> will be only for developers, but then document is not my solution.

i work in a literate style all the time now. every few lines i change
i completely notangle-compile-test-noweeave-latex-xdvi as a single
process. that way i know that the program still works, still TeXs, 
and the code and text are in sync.

literate programming is a fundamental change in the way one thinks.
programs are written for people, not machines so TeXing the file is primary.

surely you can't be suggesting that people still write naked code files....

you are, in fact, working as a developer so i'd hope that all of your
new makefile machinery is pamphlet files.  and the design principles
should come first, as in the top level Makefile so the next generation
can follow the religion.  so why wouldn't a greatly improved
'document' command be primary? 

a two-pass process would allow a latex typo to stop the system build
very late in the process whereas it logically should occur the first
time the file is used. 'document', with the appropriate options,
should completely handle the file, no?

it's hard for me to consider 'document', the primary command for handling
pamphlet files, as unnecessary.

Brother Tim
Keeper of the Flame and secret pyromaniac.

\start
Date: 14 Aug 2006 22:21:09 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [Axiom-mail] Re: noweb

Tim Daly writes:

| > As you can see, document insists on LaTeXing a file, which, as I said,
| > when in a design-code-build-test mode, I'm not interested in.  It just
| > wastes my time.  I rather have a separate [hase for building .dvi
| > files than trying to conflate everything together.  Maybe that mode
| > will be only for developers, but then document is not my solution.
| 
| i work in a literate style all the time now. every few lines i change
| i completely notangle-compile-test-noweeave-latex-xdvi as a single
| process. that way i know that the program still works, still TeXs, 
| and the code and text are in sync.

I think you misundertood.  The issue is not that of removing TeXing.
The issue is that of *delyaing* TeXing to another phase.

The TeXing is pointless when it is not needed.

| literate programming is a fundamental change in the way one thinks.
| programs are written for people, not machines so TeXing the file is primary.

By now, I think I know that psaulm by heart :-)

[...]

| surely you can't be suggesting that people still write naked code files....

And surely, I'm not suggesting that; right?

| you are, in fact, working as a developer so i'd hope that all of your
| new makefile machinery is pamphlet files.

they are.  What I'm saying that I work in various modes -- just like
various people work different.  They are modes where the TeXing is
just a pure waste of time for no reason.

In another mode, where full build is necessery to check that the
system is working, TeXing is mandatory.  No single size fits all.

| and the design principles
| should come first, as in the top level Makefile so the next generation
| can follow the religion.  so why wouldn't a greatly improved
| 'document' command be primary? 

because, it is secondary.  When I'm in a position where I'm satsified
with the build system, I will at how document can be improved to do
what it should be doing with the build system.  document is not an end
in itself.  It is tool.  I need to explore the landscape before I know
how to manufacture the tool to suit my needs.

| a two-pass process would allow a latex typo to stop the system build
| very late in the process whereas it logically should occur the first
| time the file is used. 'document', with the appropriate options,
| should completely handle the file, no?

TeXing and compiling SPAD, C, or LISP are two aspects of checking that
source files we check in the repository are "correct".  At the moment
they are entangled.  I'm saying that that entaglment ignores the
important fact that at various stages of development not all two
aspects need to be done simulatenously at the same time.  However,
they must be done before modification happens in the repositories.

\start
Date: Mon, 14 Aug 2006 22:54:26 +0200
From: David Mentre
To: Gabriel Dos Reis
Subject: re: [Axiom-mail] Re: noweb

Ok, so why not modifiying 'document' itself, like in:

--start document--
#!/bin/sh

REDIRECT=""
FILE=""
gaby_mode=no

while : ; do
    case "$1" in
        "") break;;
        -o)
            REDIRECT=$2; shift;;
        -gaby-mode)
            gaby_mode=yes;;
        *) 
            FILE=`basename $1 .pamphlet`;;
    esac
    shift
done

latex=`which latex`
if [ "$latex" = "" ] ; then
  echo document ERROR You must install latex first
  exit 1
fi

if [ "$FILE" = "" ] ; then
  echo document ERROR You must provide a file name
  echo "document [ -o redirect ] [ -gaby-mode ] file.pamphlet"
  exit 1
fi

tangle=$AXIOM/bin/lib/notangle
weave=$AXIOM/bin/lib/noweave

$tangle -t8 $FILE.pamphlet >$FILE

if [ "$gaby_mode" == "no" ]; then
    $weave -delay $FILE.pamphlet >$FILE.tex
    if [ "$REDIRECT" == "" ]; then
        $latex $FILE.tex 
        $latex $FILE.tex
    else
        $latex --interaction nonstopmode $FILE.tex >$REDIRECT
        $latex --interaction nonstopmode $FILE.tex >$REDIRECT
    fi
    rm -f $FILE~
    rm -f $FILE.pamphlet~
    rm -f $FILE.log
    rm -f $FILE.tex
    rm -f $FILE.toc
    rm -f $FILE.aux
fi
exit 0
--end document--

Shell Scribe David

\start
Date: Mon, 14 Aug 2006 23:04:37 +0200
From: Ralf Hemmecke
To: David Mentre
Subject: Re: Revision history

> As Bill, I think hard-coded modification date is preferable, as it
> allows minor modification (e.g. fixing typo). Of course, it depends on
> the semantics you espect on the date.

I also vote for hardcoded version or date information in a file. If you 
take the modification time of the file, it might be a bit confusing if 
an identical file appears in another branch of Axiom. Those two files 
will probably have different times and all you see in the .dvi is that 
they seem to be different.

> William Sit writes:
> 
>> Come to think of it, each pamphlet file should include a revision
>> history, with dates, much like code. So we should have latex macros
>> \creationdate, \revisiondates, and \filedate (which may be included in
>> \revisiondates).
> 
> Doesn't that revision history belong to the changesets of the Source
> Code Management system, whichever it is?

I am also wondering why we would use some SCM and then hardcode 
\creationdate, etc. You can use, for example, "svn log FILENAME" and get 
all the wonderful history.

\start
Date: 14 Aug 2006 23:08:10 +0200
From: Gabriel Dos Reis
To: David Mentre
Subject: re: [Axiom-mail] Re: noweb

David Mentre writes:

| Hello,
| 
| Ok, so why not modifiying 'document' itself, like in:

Really, I don't believe the issue is that of "gaby mode".  
document is doing too many things at the same time.
There was a comparison with tar earlier.  However, tar does many
things at the same only if you give many options :-).

I would like to see:

   --all                # do "everything"
   --weave              # extract tex files, don't compile
                        # probably with more options, e.g. --delay

   --tangle             # extract source code, probably with more
                        # option, e.g. --tabs=8

Those are what I currently use; you're welcome to expand and submit as
a patch and pray Father Tim accepts it :-)

\start
Date: Mon, 14 Aug 2006 23:32:08 +0200
From: Gregory Vanuxem
To: list
Subject: Hypertex and util.ht

Hypertex does not work for me with the last version of axiom (gold)
checked out from cvs at Savannah. I have just a white window with two
buttons (exit and help) that do not work. Here is the output:

===================================================================
syntax error: expected a newcommand
not a word
(HyperDoc) While parsing RootPage on line 1
        in the
file /usr/local/axiom/mnt/linux/doc/hypertex/pages/rootpage.ht
Trying to print the next ten tokens
\{ up3d \} \} \par \newcommand \{ \MenuDotBitmap \} \{ 
syntax error: expected a newcommand
not a word
(HyperDoc) While parsing ErrorPage on line 1
        in the
file /usr/local/axiom/mnt/linux/doc/hypertex/pages/util.ht
Trying to print the next ten tokens
\{ ProtectedQuitPage \} \} \newcommand \{ \UpButton \} \{ \upbutton 
Compute_text_extent: Unknown node type 30448
Compute_text_extent: Unknown node type 30576
Compute_text_extent: Unknown node type 30640
Compute_text_extent: Unknown node type 31568
Compute_text_extent: Unknown node type 31664
Compute_text_extent: Unknown node type 31760
Compute_text_extent: Unknown node type 31856
Compute_text_extent: Unknown node type 31952
Compute_text_extent: Unknown node type 32048
Compute_text_extent: Unknown node type 32144
Compute_text_extent: Unknown node type 32256
Compute_text_extent: Unknown node type 31472
Compute_text_extent: Unknown node type 32368
Compute_text_extent: Unknown node type 32432
Compute_text_extent: Unknown node type 32496
Compute_text_extent: Unknown node type 32560
Compute_text_extent: Unknown node type 32656
Compute_text_extent: Unknown node type 30736
Compute_text_extent: Unknown node type -31968
Compute_text_extent: Unknown node type -31616
Compute_text_extent: Unknown node type -31552
Compute_text_extent: Unknown node type -31456
Compute_text_extent: Unknown node type -31360
Compute_text_extent: Unknown node type -31264
Show_text: Unknown Node Type 30448
(1) -> Show_text: Unknown Node Type 30448

===================================================================

If I use an older version of util.ht Hypertex works (I think Martin
encountered a similar problem if it is not the same). The diff between
the two versions is attached.

Greg








--=-Nlcc/lBHYJJp6Z/AD8ck

--- /home/greg/TDevel/cvs/axiom/src/share/doc/hypertex/pages/util.ht	2003-08-28 16:23:45.000000000 +0200
+++ /usr/local/axiom/mnt/linux/doc/hypertex/pages/util.ht	2006-08-14 23:13:38.000000000 +0200
@@ -135,7 +135,7 @@
 % 5. Bitmaps and bitmap manipulation macros.
 % ----------------------------------------------------------------------
 
-\newcommand{\htbmdir}{\env{AXIOM}/../../share/doc/hypertex/bitmaps}
+\newcommand{\htbmdir}{\env{AXIOM}/doc/hypertex/bitmaps}
 \newcommand{\htbmfile}[1]{\htbmdir /#1.bitmap}
 \newcommand{\htbitmap}[1]{\inputbitmap{\htbmfile{#1}}}
 \newcommand{\ControlBitmap}[1]{\controlbitmap{\htbmfile{#1}}}
@@ -153,7 +153,7 @@
 
 % Including control panel pixmaps for help pages:
 
-\newcommand{\helpbit}[1]{\centerline{\inputpixmap{\env{AXIOM}/../../share/doc/hypertex/pixmaps/{#1}}}}
+\newcommand{\helpbit}[1]{\centerline{\inputpixmap{\env{AXIOM}/doc/hypertex/pixmaps/{#1}}}}
 
 % ----------------------------------------------------------------------
 % 6. HyperDoc button objects.
@@ -194,19 +194,19 @@
 % Including viewport bitmaps within \HyperName pages:
 
 \newcommand{\viewport}[1]{\inputimage{{#1}.VIEW/image}}
-\newcommand{\axiomViewport}[1]{\inputimage{\env{AXIOM}/../../share/doc/viewports/{#1}.VIEW/image}}
+\newcommand{\axiomViewport}[1]{\inputimage{\env{AXIOM}/doc/viewports/{#1}.VIEW/image}}
 \newcommand{\spadviewport}[1]{\axiomViewport{#1}}
 
 % Creating a real live viewport:
 
 \newcommand{\viewportbutton}[2]{\unixcommand{#1}{viewAlone #2}}
-\newcommand{\axiomViewportbutton}[2]{\unixcommand{#1}{viewAlone \$AXIOM/../../share/doc/viewports/{#2}}}
+\newcommand{\axiomViewportbutton}[2]{\unixcommand{#1}{viewAlone \$AXIOM/doc/viewports/{#2}}}
 \newcommand{\spadviewportbutton}[2]{\axiomViewportbutton{#1}{#2}}
 
 % Making active viewport buttons:
 
 \newcommand{\viewportasbutton}[1]{\unixcommand{\inputimage{{#1}.VIEW/image}}{viewAlone {#1}}}
-\newcommand{\axiomViewportasbutton}[1]{\unixcommand{\inputimage{\env{AXIOM}/../../share/doc/viewports/{#1}.VIEW/image}}{viewAlone \$AXIOM/../../share/doc/viewports/{#1}}}
+\newcommand{\axiomViewportasbutton}[1]{\unixcommand{\inputimage{\env{AXIOM}/doc/viewports/{#1}.VIEW/image}}{viewAlone \$AXIOM/doc/viewports/{#1}}}
 \newcommand{\spadviewportasbutton}[1]{\axiomViewportasbutton{#1}}
 
 % ----------------------------------------------------------------------
@@ -432,11 +432,9 @@
 % redundant defns for system commands
 \newcommand{\syscom}[1]{\lispdownlink{)#1}{(|syscomPage| '|#1|)}}
 %
-% 20030110000 tpd added a leading open paren
-\newcommand{\spadsyscom}[1]{){\tt #1}}
-% 20030110000 tpd these two commands are never used
-%\newcommand{\spadcmd}[1]{\spadsyscom{#1}}
-%\newcommand{\spadsys}[1]{\spadsyscom{#1}}
+\newcommand{\spadsyscom}[1]{{\tt #1}}
+\newcommand{\spadcmd}[1]{\spadsyscom{#1}}
+\newcommand{\spadsys}[1]{\spadsyscom{#1}}
 
 
 % Following macros should be phased out in favor of ones above:

\start
Date: Tue, 15 Aug 2006 00:04:09 +0200
From: Gregory Vanuxem
To: list
Subject: Re: Hypertex and util.ht

Le lundi 14 ao=FBt 2006 =E0 23:32 +0200, Vanuxem Gr=E9gory a =E9crit :
> Hello,
>
>
> Hypertex does not work for me with the last version of axiom (gold)
> checked out from cvs at Savannah. I have just a white window with two
> buttons (exit and help) that do not work.

I forgot to say that I do not use the "install" target of the makefile.
I use axiom directly in its built tree.

\start
Date: Mon, 14 Aug 2006 18:12:07 -0400
From: William Sit
To: Ralf Hemmecke
Subject: Re: Revision history

Ralf Hemmecke wrote:
> 
> > As Bill, I think hard-coded modification date is preferable, as it
> > allows minor modification (e.g. fixing typo). Of course, it depends on
> > the semantics you espect on the date.
> 
> I also vote for hardcoded version or date information in a file. If you
> take the modification time of the file, it might be a bit confusing if
> an identical file appears in another branch of Axiom. Those two files
> will probably have different times and all you see in the .dvi is that
> they seem to be different.

Why would two identical files have different modification time? I
suppose people are not careful with using -p to copy files? Ok, forget
that, but then insist that \date appears hardcoded.
 
> > William Sit writes:
> >
> >> Come to think of it, each pamphlet file should include a revision
> >> history, with dates, much like code. So we should have latex macros
> >> \creationdate, \revisiondates, and \filedate (which may be included in
> >> \revisiondates).
> >
> > Doesn't that revision history belong to the changesets of the Source
> > Code Management system, whichever it is?
> 
> I am also wondering why we would use some SCM and then hardcode
> \creationdate, etc. You can use, for example, "svn log FILENAME" and get
> all the wonderful history.

There is a difference: when such info is given in the pamphlet file, it
is given in context, not as logs. Moreover, one has to actively ask for
the log, but if there is no indication in the pamphlet file, where would
one get a reason to look through a log file? Imagine that in my recent
revision of Tim's autodoc.lisp.pamphlet, if I had checked out the
original, made the revisions, checked it back in and documented the
revision notes separately at check-in, then when someone reads my
version, it would just look like an original document, where there would
be no indication why I made the changes (that info would be kept as a
terse comment when I checked the revision in) and a trip to the
changeset or diff file wouldn't work because the revision is a total
rewrite. I don't know how Tim applies patches, but if it only involves
removing the minus lines and insert the plus lines, someone reading the
source code would not be helped unless the changes are documented in the
pamphlet file -- but that would meant maintaining revision history
(albeit not necessarily with dates) in the pamphlet file itself.

Since I am not a developer (certainly not the system-related stuffs), if
SCM already maintains history info to your satisfaction, good for you.
My own experience is that I seldom would have the need to retract back
to a certain date since I don't remember what particular date would
still have a working version. Rather, if some half-baked ideas in an
attempted new version did not work out, I would revert completely to a
previously frozen version that I know worked and start over. Even that
is quite seldom, and often I just keep working until the half-baked
ideas got cooked and working, then I freeze and save it and proceed to
explore other ideas.

\start
Date: Mon, 14 Aug 2006 23:50:16 -0400
From: Bill Page
To: William Sit
Subject: RE: date of pamphlet documents

On August 14, 2006 3:04 PM William Sit wrote:
> ...
> BTW, there is an error in [SandBoxNewAutodocPamphlet]:
> 
> Traceback (most recent call last): File
> "/var/zope/Products/ZWiki/plugins/Fit.py", line 29, in ? from 
> fit.Parse
> import Parse ImportError: No module named fit.Parse
> 
> The file does display correctly as far as I can tell.
>

I corrected the problem. It turned out that there was some legacy
ZWiki code relating to something called the "Framework for
Interactive Tests"

http://zwiki.org/ZwikiAndFit

that was being incorrectly triggered by the specific content of
your document. I have disabled 'Fit' on MathAction. This problem
has probably been corrected in a later version of Zwiki than what
we are currently using on MathAction, which is the reason why it
did not show up on the zwiki.org version.
 
> I think I will remove NewAutodocPamphlet from the Zwiki site 
> (so I don't have to maintain two versions, the zwiki version is
> already out of date :-). I'll leave a pointer there to SandBox.
> What do you think?
> 

I think it looks good.

\start
Date: Tue, 15 Aug 2006 00:19:35 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Old Lisp

On August 13, 2006 10:24 AM you wrote:
> 
> Ed Borasky writes:
> [...]
> 
> | 3. If you have GCL installed, does Axiom still build its 
> |    own copy, or does it know about the installed version?
> 
> You can convince Axiom to use the installed GCL by defining the
> variable GCLVERSION=gcl-system -- this is what FreeBSD folks do,
> according to the documentation.
>

I am not sure that this option is currently working on FreeBSD.
Can anyone confirm?

I any case this same method of building Axiom is used in Debian
although it has never been incorporated in to the main Axiom
source distribution.
 
> I'm working on a patch that have Axiom autodetect GCL and use
> it.
> 

Great! This should also make the Debian port a lot simpler.

\start
Date: Tue, 15 Aug 2006 00:45:36 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Old Lisp

When you have a moment could you please confirm that I am not
leading Gaby astray here. :-)

Thanks.

On August 12, 2006 10:34 PM Gaby wrote:
> 
> Bill Page writes:
> 
> | On August 12, 2006 8:56 PM Gaby wrote:
> | > ... 
> | > There are still some patches against GCL that Tim developed.
> | > Ideally, I think we should not be in the business of patching
> | > GCL. Camm has been collaborating with us very effectively; we
> | > should communicate those issues with him and see how they can
> | > be addressed in GCL upstream.
> | > 
> | 
> | I think all of the patches made by Tim are obsolete. I agree
> | that we should not be in the business of patching GCL. Although
> | GCL is currently the primary vehicle for delivering Axiom, it
> | is not the only Lisp that is capable of doing so. (For example
> | there is the open source CMUCL version of Axiom done by Jurgen
> | Weiss and the commercial version of Axiom used yet another lisp
> | and that lisp is now open source too.
> 
> OK.
> 
> | In fact I am fairly sure that Camm has already addressed all of
> | the GCL issues that have been identified so far. None of these
> | patches are used in the Debian release of Axiom which is built
> | from an unmodified standard distribution of GCL. There is no
> | reason that I can think of way this should not become the standard
> | way of building Axiom from GCL on all platforms (including Windows).
> 
> For GCL-2.6.7, Tim has a patch against configure.in.  The reason
> being that:
> 
>    There is a typo in configure.in that is only detected under
>    some versions of bash. The problem is a missing single-quote
>    mark.
> 
> For that to work correctly, there is an implicit assumption that
> the user's build environment has Autoconf -- to regenerate configure
> from the patched configure.in.  I don't how serious that is.

It was corrected in GCL-2.6.7 shortly after Tim took the tarball
image from cvs.

> Anyway, it GCL-2.6.7 that we might just abandon from the silver
> branch.

Good idea.

> 
> For GCL-2.6.8pre we have four patches:
> 
>   * gcl-2.6.8pre.socket.patch
>   * gcl-2.6.8pre.libspad.patch

The above two are handled by compiler-link in an unmodified
previously installed copy of GCL.

>   * gcl-2.6.8pre.toploop.patch

This one is handled by setting an option.

>   * gcl-2.6.8pre.collectfn.fix

This one just copies (and renames) gcl_collectfn.lsp to a different
location in the file system and copies sys-proclaim.lisp to that
location for use at a later stage in the build. It has nothing to
do with patching GCL and should be addressed by modifications to
the appropriate makefile.pamphlet.

> 
> Can you check with Camm that they are indeed not needed anymore?
> I'm sorry, I don't fully understand the issues they are trying to
> address.
> 

\start
Date: 15 Aug 2006 08:16:29 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Old Lisp

Bill Page writes:

| Gaby,
| 
| On August 13, 2006 10:24 AM you wrote:
| > 
| > Ed Borasky writes:
| > [...]
| > 
| > | 3. If you have GCL installed, does Axiom still build its 
| > |    own copy, or does it know about the installed version?
| > 
| > You can convince Axiom to use the installed GCL by defining the
| > variable GCLVERSION=gcl-system -- this is what FreeBSD folks do,
| > according to the documentation.
| >
| 
| I am not sure that this option is currently working on FreeBSD.

I was just repeating what the pamphlet file says :-)

| Can anyone confirm?

I have requested access to SF compile farm.  I hope to be in position
to test tomorrow, but we should definitely have some *BSD guys shime it.

\start
Date: 15 Aug 2006 15:39:38 +0200
From: Martin Rubey
To: list
Subject: AldorForAxiom

Dear all,

I did not follow all of the discussions lately, so I might have missed
something.

I only noticed that on

http://wiki.axiom-developer.org/AldorForAxiom

the calculations done in Aldor do not work anymore, axiom says, for example,

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

\start
Date: Tue, 15 Aug 2006 10:57:27 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: AldorForAxiom

On August 15, 2006 9:40 AM Martin Rubey wrote:
> 
> I did not follow all of the discussions lately, so I might
> have missed something.
> 
> I only noticed that on
> 
> http://wiki.axiom-developer.org/AldorForAxiom
> 
> the calculations done in Aldor do not work anymore, axiom 
> says, for example,
> 
>       >> System error:
>      The storage for STRING is exhausted.
>   Currently, 112 pages are allocated.
>   Use ALLOCATE to expand the space.
> 
> ???
> 

This is happening because on the axiom-developer server we are
not able to build Axiom with the maxpages option set to 256*1024
because of a GCL memory allocation limitation on this particular
architecture. In the version of GCL that we are using, the next
largest allowed memory size is 128*1024.

Camm Maquire has worked on this problem.

http://lists.gnu.org/archive/html/axiom-developer/2006-08/msg00195.html

and has provided a modified gcl-2.6.8pre in cvs. I tried this but ran
into additional problems. Camm has a fix:

http://lists.gnu.org/archive/html/axiom-developer/2006-08/msg00225.html

that allows maxpages to be increased but also requires a patch to
some Axiom lisp code.

When I get a chance I plan to complete the build Axiom Silver build
improvements branch with these changes and install that on MathAction.
That should solve the problems and also more help to test Silver.

\start
Date: 15 Aug 2006 18:18:36 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

--- axiom-20050901.orig/src/interp/cfuns.lisp.pamphlet
+++ axiom-20050901/src/interp/cfuns.lisp.pamphlet
@@ -103,10 +103,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))
--- axiom-20050901.orig/src/interp/hash.lisp.pamphlet
+++ axiom-20050901/src/interp/hash.lisp.pamphlet
@@ -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"))
 
--- axiom-20050901.orig/src/interp/sockio.lisp.pamphlet
+++ axiom-20050901/src/interp/sockio.lisp.pamphlet
@@ -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"))


Please let me know if there is any problem with these.

Take care,

Tim Daly writes:

> Camm,
> 
> > I had to make the following modifications to 20050901 to work with the
> > latest 2.6.8pre:
> 
> Axiom has had several releases since 20050901.
> What do we need to do to bring it up to date?

\start
Date: Tue, 15 Aug 2006 18:53:06 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: building Silver

Gaby,

I just did a

  $ svn update

and tried to build Silver on axiom-developer.org

I get the following error message at the end of

  $ ./configure

...
config.status: creating Makefile
config.status: error: cannot find input file: config/setup-dep.mk

  $ ls config
config.guess  config.sub  install-sh  missing

---------

Any idea what is going wrong?

\start
Date: Tue, 15 Aug 2006 19:08:24 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: building Silver

On Tuesday, August 15, 2006 6:53 PM I wrote:
> ...
> I get the following error message at the end of
>
>   $ ./configure
>
> ...
> config.status: creating Makefile
> config.status: error: cannot find input file: config/setup-dep.mk
>
>   $ ls config
> config.guess  config.sub  install-sh  missing
>
> ---------
>
> Any idea what is going wrong?
>

The ChangeLog says:

  $ more ChangeLog.*
  2006-08-13  Gabriel Dos Reis  Gabriel Dos Reis

          * config/setup-dep.mk: New file.
  ...

But svn update wont give me the file. Maybe you forgot to add it?

\start
Date: 16 Aug 2006 03:40:14 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: building Silver

Bill Page writes:

| Gaby, 
| 
| On Tuesday, August 15, 2006 6:53 PM I wrote:
| > ... 
| > I get the following error message at the end of
| > 
| >   $ ./configure
| > 
| > ...
| > config.status: creating Makefile
| > config.status: error: cannot find input file: config/setup-dep.mk
| > 
| >   $ ls config
| > config.guess  config.sub  install-sh  missing
| > 
| > ---------
| > 
| > Any idea what is going wrong?
| > 
| 
| The ChangeLog says:
| 
|   $ more ChangeLog.*
|   2006-08-13  Gabriel Dos Reis  Gabriel Dos Reis
| 
|           * config/setup-dep.mk: New file.
|   ...
| 
| But svn update wont give me the file. Maybe you forgot to add it?

Yes, I did forgpt to add it.  How embarrasing :-(
Please try again and let me know.  Sorry for that.

\start
Date: Tue, 15 Aug 2006 22:02:30 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: building Silver

On Tuesday, August 15, 2006 9:40 PM you wrote:

> Bill Page wrote:
> ...
> |
> | The ChangeLog says:
> |
> |   $ more ChangeLog.*
> |   2006-08-13  Gabriel Dos Reis  Gabriel Dos Reis
> |
> |           * config/setup-dep.mk: New file.
> |   ...
> |
> | But svn update wont give me the file. Maybe you forgot to
> | add it?
>
> Yes, I did forgpt to add it.  How embarrasing :-(
> Please try again and let me know.  Sorry for that.
>

No problem!

My test build with Camm's patches is running now on
axiom-developer.

\start
Date: Tue, 15 Aug 2006 22:42:22 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

With your patch below applied to the current Silver version
of Axiom with the modified gcl-2.6.8pre pulled from cvs,
I get a different result, but an error persists:

  $tail -18 build3.log

Loading /home/page/axiom.build-improvements/obj/linux/interp/cformat.o
start address -T 0x857a700 Finished loading
/home/page/axiom.build-improvements/obj/linux/interp/cformat.o
Loading /home/page/axiom.build-improvements/obj/linux/interp/cfuns.o
directoryp is undefined

Error: Cannot get relocated section contents

Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at BUILD-INTERPSYS.  Type :H for Help.
BOOT>>make[4]: ***
[/home/page/axiom.build-improvements/obj/linux/bin/interpsys] Error 255
make[4]: Leaving directory
`/home/page/axiom.build-improvements/src/interp'
make[3]: *** [interpdir] Error 2
make[3]: Leaving directory `/home/page/axiom.build-improvements/src'
make[2]: *** [srcdir] Error 2
make[2]: Leaving directory `/home/page/axiom.build-improvements'
make[1]: *** [do-all] Error 2
make[1]: Leaving directory `/home/page/axiom.build-improvements'
make: *** [all] Error 2

--------

directoryp is a C function defined in 'src/lib/cfuns-c.c.pamphlet'.
I have checked the rest of the build3.log and it seems to me that
cfuns-c was built and linked properly, i.e. the "old way" via an ini
file.

Got any ideas?

Regards,
Bill Page.

> -----Original Message-----
> From: Camm Maguire [mailto:Camm Maguire]
> Sent: Tuesday, August 15, 2006 6:19 PM
> To: Tim Daly
> Cc: Bill Page;
> list; Gabriel Dos Reis;
> gcl-devel@gnu.org; Robert Boyer
> Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
>
> Greetings!
>
> --- axiom-20050901.orig/src/interp/cfuns.lisp.pamphlet
> +++ axiom-20050901/src/interp/cfuns.lisp.pamphlet
> @@ -103,10 +103,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))
> --- axiom-20050901.orig/src/interp/hash.lisp.pamphlet
> +++ axiom-20050901/src/interp/hash.lisp.pamphlet
> @@ -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"))
> 
> --- axiom-20050901.orig/src/interp/sockio.lisp.pamphlet
> +++ axiom-20050901/src/interp/sockio.lisp.pamphlet
> @@ -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"))
>
>
> Please let me know if there is any problem with these.
>
> Take care,
>
> Tim Daly writes:
>
> > Camm,
> >
> > > I had to make the following modifications to 20050901 to
> work with the
> > > latest 2.6.8pre:
> >
> > Axiom has had several releases since 20050901.
> > What do we need to do to bring it up to date?

\start
Date: Tue, 15 Aug 2006 22:55:04 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

patches applied. testing restarted. --t

\start
Date: Tue, 15 Aug 2006 23:15:13 -0400
From: Bill Page
To: Tim Daly
Subject: RE: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer, Camm Maguire

Tim,

On Tuesday, August 15, 2006 10:55 PM you wrote:
>
> patches applied. testing restarted. --t
>

Do you recall that this patch also involves a new version of
gcl-2.6.8pre? I am not sure whether the patch is applicable to
the older version of gcl-2.6.8pre in the Axiom repositories.

Regards,
Bill Page.


> -----Original Message-----
> From: Camm Maguire [mailto:Camm Maguire]
> Sent: Friday, August 11, 2006 10:24 AM
> To: Bill Page
> Cc: list; Tim Daly;
> Gabriel Dos Reis; gcl-devel@gnu.org; Robert Boyer
> Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
>
> Greetings!
>
> I had to make the following modifications to 20050901 to work with the
> latest 2.6.8pre:
>
> /fix/t1/camm/debian/axiom/axiom-20050901/int/interp/hash.lisp:
>  remove static
>
> (clines "int mem_value(x ,i)object x;int i; { return ((short
> *)x)[i];}")
> #+AKCL
> (defentry memory-value-short(object int) (int "mem_value"))
>
>
> /fix/t1/camm/debian/axiom/axiom-20050901/int/interp/cfuns.lisp
> : match unsigned/signed
>
> #+(AND KCL (NOT ELF))
> (Clines
> "int MYCOMBINE(i,j)"
> "int i,j;"
> "{"
> "return ( (((((unsigned int)j) & 16777215) << 6)+((unsigned
> int)i)) % 1073741789);"
> "}"
> )
>
> /fix/t1/camm/debian/axiom/axiom-20050901/int/interp/sockio.lis
> p: match float/double
>
>   (clines "extern float sock_get_float();")
>   (defentry open_server (string) (int "open_server"))
>   (defentry sock_get_int (int) (int "sock_get_int"))
>   (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"))
>
>
> The defentry code has been enhanced to support xgcl natively.
>
> I just did a successful build of axiom 20050901 and acl2 3.0.1 with
> the same maxpage -- hope this works for you, though you might still
> have a stack/heap collision problem on your machine.
>
> Take care,
>
> Bill Page writes:
>
> > Camm,
> >
> > On Thursday, August 10, 2006 1:59 PM you wrote:
> > >
> > > Greetings!  FYI, just committed the removal of the
> > > power of 2 constraint on maxpage in both cvs head and
> > > version 2.6.8pre.
> > >
> >
> > Thanks for looking into this.
> >
> > I just grabbed 2.6.8pre from cvs into a temp directory and
> > created a replacement tarball for the Axiom build, thus:
> >
> >   cd /home/page/temp-dir
> >   export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
> >   cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
> >   tar czvf gcl-2.6.8pre.tgz gcl-2.6.8pre
> >   cd /home/page/axiom.build-improvements/zips
> >   mv gcl-2.6.8pre.tgz old_gcl-2.6.8pre.tgz
> >   mv /home/page/temp-dir/gcl-2.6.8pre.tgz .
> >   cd /home/page/axiom.build-improvements
> >
> > I edited the GCLOPTS in Makefile from
> >   --enable-maxpage=256*1024
> > to
> >   --enable-maxpage=196*1024
> > resulting in
> >
> >   GCLOPTS=--enable-vssize=65536*2 --enable-statsysbfd \
> >           --enable-maxpage=196*1024
> >
> > in the default build for Axiom Silver build-improvements branch:
> >
> >   make clean
> >   ./configure | tee build.log
> >   make 2>&1 | tee -a build.log
> >
> > The build proceeded much further than before - the GCL sub-build
> > finished without errors - yeah! But the build of Axiom failed
> > with the following error message quite far along into the
> > interpsys build phase :(
> >
> >   error: conflicting types for 'MYCOMBINE'
> >
> > This is not something I have seen before. This same source builds
> > fine with the older version of 2.6.8pre and 128*256.
> >
> > Here is the tail end of the log. I can send you the rest if you
> > like.
> >
> > Please let me know how I can help.

\start
Date: Wed, 16 Aug 2006 08:11:27 +0200
From: Gernot Hueber
To: Gabriel Dos Reis
Subject: Re: Old Lisp

On Tue, 2006-08-15 at 08:16 +0200, Gabriel Dos Reis wrote:
> Bill Page writes:
>
> | Gaby,
> |
> | On August 13, 2006 10:24 AM you wrote:
> | >
> | > Ed Borasky writes:
> | > [...]
> | >
> | > | 3. If you have GCL installed, does Axiom still build its
> | > |    own copy, or does it know about the installed version?
> | >
> | > You can convince Axiom to use the installed GCL by defining the
> | > variable GCLVERSION=gcl-system -- this is what FreeBSD folks do,
> | > according to the documentation.
> | >
> |
> | I am not sure that this option is currently working on FreeBSD.

> I was just repeating what the pamphlet file says :-)
>
> | Can anyone confirm?
>
>
I can confirm, it is.I have requested access to SF compile farm.  I hope
to be in position
> to test tomorrow, but we should definitely have some *BSD guys shime it.

Can you give me some instruction, where do get the respective sources
etc (off-the-list)

\start
Date: Wed, 16 Aug 2006 07:48:48 -0400
From: Bill Page
To: list
Subject: Sage on MathAction
Cc: William Stein

Axiom Developers and computer algebra enthusiasts!

I have a very preliminary demonstration of the integration
of Sage with the MathAxiom wiki here:

http://wiki.axiom-developer.org/SandBoxSageTest

I would like to encourage you to test this further. You will
find that Sage is quite different than any other computer
algebra system with which you might be familiar - truly a
"new generation".

This approach to interfacing with Sage is based directly on
the work of Gonzalo Tornaria and Joe Wetherell et al. for use
with LaTeX. The LatexWiki software on which MathAction is
based needed only minor modifications to make direct use
of the 'examples/latex_embed' code in the Sage distribution.
Long live open source... :-)

\start
Date: Wed, 16 Aug 2006 10:02:03 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Sage on MathAction

It's all yours - it's open source. :) I will update the MathAction
repositories later today after we get a little more testing done.
It should be easy for you to incorporate this into the Doyen CD

http://wiki.axiom-developer.org/DoyenCD

You might also be interested in the pamphlet support for Sage
which comes very naturally with the way pamphlets are implemented
on MathAction (MathAxiom? ;)

http://wiki.axiom-developer.org/SandBoxSagePamphlet

So now we can start to discuss literate programming with
the Sage developers.

You asked:

> Do people in Sage considering including Axiom???

Yes, this has been considered by some of the Sage developers.
They chose Maxima as the first system of this kind to integrate
with Sage apparently because it was easier. Axiom, however is
both more difficult and at the same time perhaps more interesting
than Maxima because of it's strong typing and underlying object-
orientation. Sage provides a strongly-typed object-oriented view
of mathematical objects not so different than SPAD and Aldor,
except that types are (mostly) static in Aldor but dynamic in
Sage. In principle it should be possible to develop an interface
between Axiom and Sage that preserves much more of the mathematical
structure than what is possible in other computer algebra systems.

The ability to transfer mathematical structures between very
different mathematical systems (only a little structure in some
cases, but it other cases a lot) is one of the most innovative
things about Sage. (This is in contrast to MathAction which only
provides a common user interface but does not transfer data
between systems.) So the way I see it, Sage provides the much
needed glue to take advantage of the huge prior investment in
mathematical software - of which Axiom is one very important
example. From the point of view of Axiom we can also view Sage
as a new user interface, not so different than what B# (Bnatural)
was intended to be.

I think the Sage developers were very bold - maybe even audacious -
to actually attempt this. And they are doing it in a largely
pragmatic way without attempting to incorporate the more formal
and theoretical ideas developed by the OpenMath community. One
might have been tempted to predict an early failure to this
effort but on the contrary Sage seems to be growing more rapidly
than any other computer algebra research and development effort.
I guess this just provides one more demonstration that software
development - particularly open source software development -
is not a linear process. :)

So I am very enthusiastic about the idea of developing a serious
Axiom interface for Sage and I hope we can find more resources
here in the Axiom developer group to work on this. I have read
most of the Sage Maxima interface code and I think it forms a
pretty good basis on which to start to build an Axiom interface.

Is anyone interested?

Regards,
Bill Page.

________________________________


	From: Alfredo Portes [mailto:Alfredo Portes]
	Sent: Wednesday, August 16, 2006 8:35 AM
	To: Bill Page
	Subject: Re: Sage on MathAction


	Bill,

	I want !!! I want !!! :-)

	Really nice work. MathAxiom just becomes better every week.

	Do people in Sage considering including Axiom???

	Whenever LatexWiki gets updated with these changes please
	let me know or if you have plans of using the new version of
	ZWiki available.

	Again, props on this incredible job,

	Regards,


	On 8/16/06, Bill Page wrote:

		Axiom Developers and computer algebra enthusiasts!
	
		I have a very preliminary demonstration of the
integration
		of Sage with the MathAction wiki here:
	
		http://wiki.axiom-developer.org/SandBoxSageTest
	
		I would like to encourage you to test this further. You
will
		find that Sage is quite different than any other
computer
		algebra system with which you might be familiar - truly
a
		"new generation".
	
		This approach to interfacing with Sage is based directly
on
		the work of Gonzalo Tornaria and Joe Wetherell et al.
for use
		with LaTeX. The LatexWiki software on which MathAction
is
		based needed only minor modifications to make direct use
		of the 'examples/latex_embed' code in the Sage
distribution.
		Long live open source... :-)
	
		Enjoy!
	
		Regards,
		Bill Page.


	Jose Alfredo Perez





\start
Date: Wed, 16 Aug 2006 10:53:00 -0400
From: Bill Page
To: Bill Page
Subject: new version of Graphviz on MathAction includes	psfrag
Cc: Derek Rayside, list

I have upgraded Graphviz to the most recent version of GraphViz
that I could find on the web:

http://people.csail.mit.edu/drayside/latex/graphviz.new/graphviz.pdf

http://people.csail.mit.edu/drayside/latex/graphviz.new

Thus web site was a little hard to find and there are other
older versions at different locations. Anyway, these files are
dated 11-Jan-2006 and make reference to some improvements
submitted by Ralf Hammecke, so I think these are probably the
right ones.

This version also incorporates the psfrag package to permit
arbitrary LaTeX symbols and equations to be inserted into
the graphs. This works very nicely as you can see from

http://wiki.axiom-developer.org/GraphViz

The new version also allows an arbitrary number of graphs
to appear on a page by working around a limitation of LaTeX
on the number of open files.

The new version of Graphviz is also supported in pamphlet
files and works with the hyperref package to include clickable
links on graphs. See for example:

http://wiki.axiom-developer.org/book--main--1/Endpaper3

Challenge: Create a GraphViz graphic like a flowchart that
automatically includes the computed output of \sage{...}
commands. (Note: This might require a change to the graphviz.sty
and sagetex.sty packages or the MathAction/LatexWiki page
rendering software.)

Regards,
Bill Page.



\start
Date: Wed, 16 Aug 2006 11:04:40 -0400 (EDT)
From: Derek Rayside
To: Bill Page
Subject: Re: new version of Graphviz on MathAction includes psfrag

Yes, those are the files.  I should really update the website and get 
graphviz.org to update their links ... sorry about that ... glad you guys 
are finding it useful.

I'm not familiar with SAGE, but I'm certainly open to making enhancements 
...

best,
Derek.


On Wed, 16 Aug 2006, Page, Bill wrote:

> I have upgraded Graphviz to the most recent version of GraphViz
> that I could find on the web:
>
> http://people.csail.mit.edu/drayside/latex/graphviz.new/graphviz.pdf
>
> http://people.csail.mit.edu/drayside/latex/graphviz.new
>
> Thus web site was a little hard to find and there are other
> older versions at different locations. Anyway, these files are
> dated 11-Jan-2006 and make reference to some improvements
> submitted by Ralf Hammecke, so I think these are probably the
> right ones.
>
> This version also incorporates the psfrag package to permit
> arbitrary LaTeX symbols and equations to be inserted into
> the graphs. This works very nicely as you can see from
>
> http://wiki.axiom-developer.org/GraphViz
>
> The new version also allows an arbitrary number of graphs
> to appear on a page by working around a limitation of LaTeX
> on the number of open files.
>
> The new version of Graphviz is also supported in pamphlet
> files and works with the hyperref package to include clickable
> links on graphs. See for example:
>
> http://wiki.axiom-developer.org/book--main--1/Endpaper3
>
> Challenge: Create a GraphViz graphic like a flowchart that
> automatically includes the computed output of \sage{...}
> commands. (Note: This might require a change to the graphviz.sty
> and sagetex.sty packages or the MathAction/LatexWiki page
> rendering software.)
>
> Regards,
> Bill Page.
>



\start
Date: Wed, 16 Aug 2006 12:45:15 -0400
From: Bill Page
To: Alfredo Portes
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: Wed, 16 Aug 2006 09:40:21 -0700
From: William Stein
To: Bill Page, Alfredo Portes
Subject: Re: [SAGEdev] Sage on MathAction
Cc: list, sage-devel@lists.sourceforge.net

On Wed, 16 Aug 2006 07:02:03 -0700, Page, Bill Bill Page wrote:
> So I am very enthusiastic about the idea of developing a serious
> Axiom interface for Sage and I hope we can find more resources
> here in the Axiom developer group to work on this. I have read
> most of the Sage Maxima interface code and I think it forms a
> pretty good basis on which to start to build an Axiom interface.
>
> Is anyone interested?

Well I definitely am interested.   I've already started thinking about
writing an interface.   Here are some quick questions to get things started:

    -- Is there a way to get a list of all the types that are defined
       in a given Axiom session?
    -- Is there a way to change the prompts, i.e., to be much more
       difficult to confuse with valid output?
    -- If X is an Axiom variable, is there a way to ask the Axiom command
       line for a list of function that take X as the first argument?
    -- Could you give me an example that illustrates "exec"'ing the
       contents of a text file from within Axiom?  (This sort of thing
       is used by SAGE when input lines are huge.)

\start
Date: Wed, 16 Aug 2006 14:12:42 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: SandBox Request

Alfred,

On Wednesday, August 16, 2006 1:30 PM you asked:

> Sorry Bill. Is it possible to have sandbox for Doyen ???

I am not sure about the exact meaning of your question. But
the answer is yes in both cases below.

If you are asking if you can have a "SandBox" on the Doyen CD,
then this seems a little strange because all that SandBox means
is that all page additions and edits are silent, i.e. the
wiki will not send out email notices. But normally the option
of sending emails would not even be enabled on the DoyenCD
because it is local to your workstation. So all pages are
"SandBox" pages.

On Axiom Wiki it is easy to create SandBox pages. "Sandbox" is
just a set of pages whose names all begin with the default
prefix 'SandBox' (there is a parameter that can be set to
designate other prefixes as as "silent"). All you have to do
is write a WikiWord like:

  SandBoxMyPageName

somewhere (using the SandBox prefix) when you edit a page or
when you make a comment. Then that name will become a link to
a new page. Just click on the blue ? beside the name to create
the new page. Because it begins with the SandBox prefix, it
will automatically be silent.

Does that answer your question?

\start
Date: 16 Aug 2006 16:05:10 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

Greetings!

Bill Page writes:

> Camm,
> 
> With your patch below applied to the current Silver version
> of Axiom with the modified gcl-2.6.8pre pulled from cvs,
> I get a different result, but an error persists:
> 
>   $tail -18 build3.log
> 
> Loading /home/page/axiom.build-improvements/obj/linux/interp/cformat.o
> start address -T 0x857a700 Finished loading
> /home/page/axiom.build-improvements/obj/linux/interp/cformat.o
> Loading /home/page/axiom.build-improvements/obj/linux/interp/cfuns.o
> directoryp is undefined
> 
> Error: Cannot get relocated section contents
> 
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by LOAD.
> Broken at BUILD-INTERPSYS.  Type :H for Help.
> BOOT>>make[4]: ***
> [/home/page/axiom.build-improvements/obj/linux/bin/interpsys] Error 255
> make[4]: Leaving directory
> `/home/page/axiom.build-improvements/src/interp'
> make[3]: *** [interpdir] Error 2
> make[3]: Leaving directory `/home/page/axiom.build-improvements/src'
> make[2]: *** [srcdir] Error 2
> make[2]: Leaving directory `/home/page/axiom.build-improvements'
> make[1]: *** [do-all] Error 2
> make[1]: Leaving directory `/home/page/axiom.build-improvements'
> make: *** [all] Error 2
> 
> --------
> 
> directoryp is a C function defined in 'src/lib/cfuns-c.c.pamphlet'.
> I have checked the rest of the build3.log and it seems to me that
> cfuns-c was built and linked properly, i.e. the "old way" via an ini
> file.
> 
> Got any ideas?
> 

My apologies -- all my testing is with the Debian package, so I did
not see this.  Can you please give me simple instructions whereby I
might obtain silver and reproduce this?  Preferably stable
retrieve-and-make-the-latest instructions that I can store in 1 cons
of long term brain memory :-)?

Take care,

> Regards,
> Bill Page.
> 
> > -----Original Message-----
> > From: Camm Maguire [mailto:Camm Maguire] 
> > Sent: Tuesday, August 15, 2006 6:19 PM
> > To: Tim Daly
> > Cc: Bill Page; 
> > list; Gabriel Dos Reis; 
> > gcl-devel@gnu.org; Robert Boyer
> > Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
> > 
> > Greetings!
> > 
> > --- axiom-20050901.orig/src/interp/cfuns.lisp.pamphlet
> > +++ axiom-20050901/src/interp/cfuns.lisp.pamphlet
> > @@ -103,10 +103,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))
> > --- axiom-20050901.orig/src/interp/hash.lisp.pamphlet
> > +++ axiom-20050901/src/interp/hash.lisp.pamphlet
> > @@ -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"))
> >  
> > --- axiom-20050901.orig/src/interp/sockio.lisp.pamphlet
> > +++ axiom-20050901/src/interp/sockio.lisp.pamphlet
> > @@ -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"))
> > 
> > 
> > Please let me know if there is any problem with these.
> > 
> > Take care,
> > 
> > Tim Daly writes:
> > 
> > > Camm,
> > > 
> > > > I had to make the following modifications to 20050901 to 
> > work with the
> > > > latest 2.6.8pre:
> > > 
> > > Axiom has had several releases since 20050901.
> > > What do we need to do to bring it up to date?

\start
Date: 16 Aug 2006 22:14:45 +0200
From: Martin Rubey
To: William Stein
Subject: Re: [SAGEdev] Sage on MathAction

unfortunately, I don't have all the answers. But, anyway, that's what I know:

>     -- Could you give me an example that illustrates "exec"'ing the
>        contents of a text file from within Axiom?  (This sort of thing
>        is used by SAGE when input lines are huge.)

This one is very easy. You just write the functions into a file "myfile.input",
and then say

)read myfile.input

or

)re myfile.input

at the axiom prompt. Here is a real life example: the following is a file I
currently use. it reads a file called "stripped" from my harddisk and does some
computations. Note that it reads another input file itself. To minus signs mean
"comment", a close parenthesis in the first column means "system command", "_"
is the line continuation character.

-- getsloane.input ---------------------------------------------------------
)re guess2.input

-- get next sequence
-- we assume that f is a TextFile containing sequences in the format
-- A120493 ,1,2,3,4,

coerceINT(s: String): Integer == integer(PARSE_-INTEGER(s)$Lisp)

coerceLINT(r: String): List Integer ==
        map(c +-> coerceINT c, split(r, char(","))$String)_
          $FiniteLinearAggregateFunctions2(String, List String, Integer, _
                                           List Integer)

-- transforms a list into a SUP
makef(l:List INT):SUP INT == 
  reduce(_+, [monomial(e, n)$SUP(INT) for e in l for n in 0..#l])

-- we return the list of integers [1,2,3,4]
getSequence!(f: TextFile): List Integer ==
   r:String := readLine!(f)$TextFile
   r := delete(r, 1..8)
   coerceLINT(r)

f := open("stripped")$TextFile

repeat (l := getSequence!(f); n := #l; r := min(30, n); _
        if # guessADE(l, safety==(n-r)::NNI, debug==true) > 0 then output l)

-- getsloane.input ---------------------------------------------------------

>     -- If X is an Axiom variable, is there a way to ask the Axiom command
>        line for a list of function that take X as the first argument?

I doubt it, but that might be doable. However, what would you need this for?
Very likely, there will be very many operations taking an integer as first
argument, for example.

>     -- Is there a way to get a list of all the types that are defined
>        in a given Axiom session?

Yes, this is possible. Enter

)what domain

to get all domains,

)wh cat

to get all categories,

)wh pack

to get all packages

)wh op

to get all operations,

)wh th

to get all things.

Again, the lists are quite long.

>     -- Is there a way to change the prompts, i.e., to be much more
>        difficult to confuse with valid output?

I think this is unneccessary given axioms ability to speak in various
modes. For example, say

)set tex on
)set algebra off

to get a feeling for it.



I think, the truly interesting thing will be how to deal with axioms type
system. I once wrote a wrapper for polymake which was not difficult. The
tedious bit however is, that you have to decide for each function which type it
should have in axiom, and, since axiom is not perfect, many types are
missing. (Eg., there is no type for graphs)

Note, furthermore, that in axiom the displayed output does not nearly capture
everything of the internal datastructure. Using output as input works only for
those types that have ConvertibleTo(InputForm). Well that makes 57 Domains,
which is quite OK, I guess..

(To see them, use HyperDoc: click Browse, enter KONVERT, click Constructors,
enter INFORM, click Domains.)

\start
Date: Wed, 16 Aug 2006 16:58:35 -0400
From: Bill Page
To: William Stein
Subject: RE: [SAGEdev] Sage on MathAction

On Wednesday, August 16, 2006 12:40 PM William Stein wrote:
> On Wed, 16 Aug 2006 07:02:03 -0700, Bill Page wrote:
> > So I am very enthusiastic about the idea of developing a serious
> > Axiom interface for Sage and I hope we can find more resources
> > here in the Axiom developer group to work on this. I have read
> > most of the Sage Maxima interface code and I think it forms a
> > pretty good basis on which to start to build an Axiom interface.
> >
> > Is anyone interested?
>
> Well I definitely am interested.  I've already started thinking
> about writing an interface.

Wonderful!

> Here are some quick questions to get things started:
>
>     -- Is there a way to get a list of all the types that are
>        defined in a given Axiom session?

The Axiom command: )display will provide some useful information.

 )display      : display Library operations and objects in your
workspace

E.g.

---------

(1) -> I:Integer
                                Type: Void
(2) -> S:String
                                Type: Void
(3) -> M:Matrix Integer
                                Type: Void
(4) -> f(x)==x+1
                                Type: Void
(5) -> g:(Integer,Float)->String
                                Type: Void
(6) -> g(x,y)==unparse((y^x)::InputForm)
                                Type: Void
(6) -> )display properties
Properties of % :
   Value (has type Void):  "()"
Properties of %e :
   This is a system-defined macro.
   macro %e () == exp(1)
Properties of %i :
   This is a system-defined macro.
   macro %i () == complex(0,1)
Properties of %infinity :
   This is a system-defined macro.
   macro %infinity () == infinity()
Properties of %minusInfinity :
   This is a system-defined macro.
   macro %minusInfinity () == minusInfinity()
Properties of %pi :
   This is a system-defined macro.
   macro %pi () == pi()
Properties of %plusInfinity :
   This is a system-defined macro.
   macro %plusInfinity () == plusInfinity()
Properties of I :
   Declared type or mode:   Integer
Properties of M :
   Declared type or mode:   Matrix Integer
Properties of S :
   Declared type or mode:   String
Properties of SF :
   This is a system-defined macro.
   macro SF () == DoubleFloat()
Properties of f :
   This is an interpreter function.
   Definition:   f x == x + 1
Properties of g :
   Declared type or mode:   ((Integer,Float) -> String)
   This is an interpreter function.
   This depends on the following functions or rules:
      String OutputForm concat string latex Float InputForm unparse
                                      x
   Definition:   g (x,y) == unparse((y ) :: InputForm)

--------

>     -- Is there a way to change the prompts, i.e., to be much
>        more difficult to confuse with valid output?

Here is one way involving specifying a "frame" with a odd name
and using that name in the prompt. (Frames are separate named
workspaces.)

E.g.
---------

(1) -> )set message prompt verbose
initial [14:59:53] [1] -> )frame new <-\begin{sage-input}
<-\begin{sage-input} [15:01:04] [1] -> )set message autoload off
<-\begin{sage-input} [15:01:20] [1] -> )set output algebra off
<-\begin{sage-input} [15:01:29] [1] -> )set output tex on
<-\begin{sage-input} [15:01:56] [1] -> 1/2

$$
1 \over 2
\leqno(1)
$$

                                                       Type: Fraction
Integer
<-\begin{sage-input} [15:02:00] [2] -> integrate(sin(x)^2,x)

$$
{-{{\cos
\left(
{x}
\right)}
\  {\sin
\left(
{x}
\right)}}+x}
\over 2
\leqno(2)
$$

                                          Type: Union(Expression
Integer,...)
<-\begin{sage-input} [15:02:44] [3] ->

----------

>     -- If X is an Axiom variable, is there a way to ask the
>        Axiom command line for a list of function that take X as
>        the first argument?

Hmmm... I don't think so. What do you mean by "take X"? Do you
mean the type of X? But see ')display properties' output above
for functions. There is also

  )show         : show constructor information

E.g.

  )show Integer

and

  )display operations

In addtion to these standard commands it may be possible to
call some of the underlying lisp functions which are used, by
other user interfaces such as Axiom's browser HyperTex.

>     -- Could you give me an example that illustrates "exec"'ing
>        the contents of a text file from within Axiom?  (This
>        sort of thing is used by SAGE when input lines are huge.)
>

The usual command is

  )read filename.input

This reads interpreter commands from the named file.
There are also compiler commands which might be relevant.

  )compile filename.spad
  )compile filename.as
  )compile filename.lisp

SPAD (.spad) and Aldor (.as) are the Axiom library programming
languages.

I hope this helps.

\start
Date: Wed, 16 Aug 2006 23:10:47 +0200
From: Ralf Hemmecke
To: Camm Maguire
Subject: re: NULL_OR_ON_C_STACK macro invalid
Cc: Robert Boyer

 > Can you please give me simple instructions whereby I
> might obtain silver and reproduce this?  Preferably stable
> retrieve-and-make-the-latest instructions that I can store in 1 cons
> of long term brain memory :-)?

See http://wiki.axiom-developer.de/AxiomSources and get the 
"build-improvements" branch from sourceforge.

Then ./configure && make should do.

\start
Date: Wed, 16 Aug 2006 17:19:10 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

Camm,

On Wednesday, August 16, 2006 4:05 PM you wrote:
>
> Bill Page writes:
>
> > With your patch below applied to the current Silver version
> > of Axiom with the modified gcl-2.6.8pre pulled from cvs,
> > I get a different result, but an error persists:
> >
> >   $tail -18 build3.log
> >
> > Loading
> /home/page/axiom.build-improvements/obj/linux/interp/cformat.o
> > start address -T 0x857a700 Finished loading
> > /home/page/axiom.build-improvements/obj/linux/interp/cformat.o
> > Loading /home/page/axiom.build-improvements/obj/linux/interp/cfuns.o
> > directoryp is undefined
> >
> > Error: Cannot get relocated section contents
> >
> ...
> My apologies -- all my testing is with the Debian package, so
> I did not see this.

I hope that we will soon move to the Debian style build on all
Axiom systems.

> Can you please give me simple instructions whereby I
> might obtain silver and reproduce this?  Preferably stable
> retrieve-and-make-the-latest instructions that I can store
> in 1 cons of long term brain memory :-)?

Can you spare 6? :)

1 svn co \
  https://svn.sourceforge.net/svnroot/axiom/branches/build-improvements
\
    axiom.build-improvements
2 cd axiom.build-improvements
3 replace gcl-2.6.8pre tarball from cvs
4 apply Camm's patchs in src/interp
5 ./configure
6 make

Let me know if you have any questions. Or take a look
at

http://wiki.axiom-developer.org/AxiomSilverBranch

\start
Date: 16 Aug 2006 23:21:48 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: NULL_OR_ON_C_STACK macro invalid
Cc: Camm Maguire, Robert Boyer

Ralf Hemmecke writes:

|  > Can you please give me simple instructions whereby I
| > might obtain silver and reproduce this?  Preferably stable
| > retrieve-and-make-the-latest instructions that I can store in 1 cons
| > of long term brain memory :-)?
| 
| See http://wiki.axiom-developer.de/AxiomSources and get the
| "build-improvements" branch from sourceforge.
| 
| Then ./configure && make should do.

Ralf; many thanks for taking care of this -- I'm very busy at the
moment.

Camm; I suspect Bill did not want to bother you with the
build-improvements quirks.  So, you can just grab the "trunk" of the
svn repo; that is the silver branch.  

\start
Date: Wed, 16 Aug 2006 23:35:17 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: [SAGEdev] Sage on MathAction
Cc: William Stein

>>     -- If X is an Axiom variable, is there a way to ask the Axiom command
>>        line for a list of function that take X as the first argument?
> 
> I doubt it, but that might be doable. However, what would you need this for?
> Very likely, there will be very many operations taking an integer as first
> argument, for example.

Each axiom variable has a type. If (like Martin suggests) you get all 
the operations using

    )what operations

then you could use

    )display operations zero?

(where "zero?" is just an example)
to figure out the type of (possibly several) zero? functions.
Now you have to parse the output to match the type of X with one of the 
functions. :-(  I am sure somebody can provide you with a better suggestion.

>>     -- Is there a way to change the prompts, i.e., to be much more
>>        difficult to confuse with valid output?

> I think this is unneccessary given axioms ability to speak in various
> modes. For example, say
> 
> )set tex on
> )set algebra off
> 
> to get a feeling for it.

Or you just name your own frame and let Axiom show that frame name

)frame new MyFancyFrameName
)set message prompt frame

Would you like

)frame new Axiom
)set message prompt verbose

\start
Date: Wed, 16 Aug 2006 18:08:21 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: axiom.risc.uni-linz.ac.at

Ralf,

On Wednesday, August 16, 2006 5:15 PM you wrote:
>
> I actually wanted to ask the question whether axiom.risc is
> setup in such a way that I could edit a wiki page there and
> it would be magically syncronize with the axiom-developer wiki...

Yes. No so magically but fairly easily. There is a zope utility
installed on both axiom-developer and axiom.risc called ZSyncer.
This program identifies what pages have been changed at each
site and allows one to copy page two and fro until both are up
to date (and any possible conflicts are resolved).

It works pretty well. I usually have been performing the synch
about once a week, except for the last two or three weeks
because I have been making a lot of changes on axiom-developer
org and decided to freeze axiom.risc for a while I case I needed
a quick recovery path.

I was planning to perform another sync this weekend. The content
would probably look be ok without it, but I was also planning to
propagate and test the changes to the underlying Python code.

> but now I've found out that axiom.risc is not connected.

Yes. I confirm that I do not have any access to the server.
Not even network ping. So it's either dead or disconnected.

>
> I have to figure out the reason tomorrow.
>

Ok, please let me know.

> But still, could you answer my question.
>

Would you like to know more about how to do the ZSyncer?

http://sourceforge.net/projects/zsyncer

http://zwiki.org/1252ZWikiPageModifiedTimeWrongInDifferentTimeZones

\start
Date: Thu, 17 Aug 2006 00:48:57 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: axiom.risc.uni-linz.ac.at

> Would you like to know more about how to do the ZSyncer?

Before I take a closer look to the documentation, your description 
sounds as if I have to sync manually. I though that just using 
axiom.risc (reading/editing) would automatically (once a day or so) 
forward my changes to the axiom-developer wiki.

And what about the portal, ie the plone stuff? No no, you don't need to 
install anything if it is not there. I am just curious.

\start
Date: Wed, 16 Aug 2006 19:01:45 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: axiom.risc.uni-linz.ac.at

Ralf,

On Wednesday, August 16, 2006 6:49 PM you wrote:
> Bill Page wrote:
> > Would you like to know more about how to do the ZSyncer?
>
> Before I take a closer look to the documentation, your
> description sounds as if I have to sync manually. I though
> that just using axiom.risc (reading/editing) would
> automatically (once a day or so) forward my changes to the
> axiom-developer wiki.

I would say that it is "semi-manual" :) It produces a two
column listing - one column for each server - with pages marked
as unchanged, new, updated or deleted on one side or the other.
All you have to do is to click check boxes to decide what you
want to do about the differences. And then click 'update' to
start the batch transfer (which can work both ways, either
updating or reverting pages as you decide).

Its not as smart as it could be and it is not completely
foolproof, but usually it doesn't take very long to move a
few hundred pages from one site to another. Only the page
source is moved. The pages must be re-rendered on the host
machine in order to generate the computational results and
the LaTeX graphics. This regeneration is transparent to the
user and occurs when the new/revised page is first requested.

>
> And what about the portal, i.e. the plone stuff? No no, you
> don't need to install anything if it is not there. I am
> just curious.
>

ZSyncer works at the Zope level for both Axiom Wiki and Axiom
Portal. The same method is used for both.

\start
Date: Thu, 17 Aug 2006 12:04:53 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: axiom.risc.uni-linz.ac.at

http://sourceforge.net/projects/zsyncer

> I would say that it is "semi-manual" :) It produces a two
> column listing - one column for each server - with pages marked
> as unchanged, new, updated or deleted on one side or the other.
> All you have to do is to click check boxes to decide what you
> want to do about the differences. And then click 'update' to
> start the batch transfer (which can work both ways, either
> updating or reverting pages as you decide).

Since I am a beginner, I don't even know how to get these two columns. 
:-( So how do I invoke ZSyncer on axiom.risc?

\start
Date: Thu, 17 Aug 2006 16:29:31 +0200
From: Gregory Vanuxem
To: list
Subject: repetition of  \subsection{Layer21} in	src/algebra/Makefile.pamphlet

There are two subsections "Layer 21" in the file
src/algebra/Makefile.pamphlet. The line 1054 can be removed.

\start
Date: Thu, 17 Aug 2006 15:36:51 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: axiom.risc.uni-linz.ac.at

On Thursday, August 17, 2006 7:34 AM Ralf Hemmecke wrote:
>
> I've found the Sync Tab in the Zope management interface
> http://axiom.risc.uni-linz.ac.at/mathaction/manage
> and pressed GET for the not up-to-date files. It did do
> something, but I don't know why the Frontpage is still
> the old one although it is shown with a green tick mark.
>

I am not sure what went wrong. Did you select those pages and
folders that you intented to update? But take care when you
do this because ZSyncer is not very bright about what it
transfers and you can easily end up transferring everything
when you did not mean to and possibily overwriting something
that you did not intend.

Unfortunately ZSyncer also has some bugs which we sometimes
have to work around. Usually I work by running ZSyncer on
axiom-developer instead of the other way around. Because of
the timezone bug this can be significant.

We are still using a slightly modified version of ZSyncer
(0.7.0). See explanation of problem here:

http://zwiki.org/1252ZWikiPageModifiedTimeWrongInDifferentTimeZones

The version in cvs at

http://sourceforge.net/projects/zsyncer

is 0.7.2 (UNRELEASED)

Maybe we want to upgrade it but we still need the patch time
zones on Zwiki pages. ZSyncer works out-of-the-box with all
other Zope objects but for some reason ZWiki pages do not
seem to conform to the current standard where times and
timezones are concerned.

My current hack works but not very well. There are still bugs
in the way that it adjusts the time and I am not (yet) skilled
enough in Zope internals to solve this problem. We really need
a more general solution to get the properly timezone adjusted
date and time for ZWiki pages. And I am still hopeful that
someone will come along and fix these problems for me. :)

> Hmm, I think, I have to learn a bit... Please help.

I think your understanding is good. It is just the tool that
is a bit faulty. I have just completed updating axiom.risc
with the new and modified pages from axiom-developer so from
the point of view of ZSyncer on axiom-developer axiom.risc
is now showing as (almost) all up to date. It might be easier
to understand what is going on with fewer changes pending.

Although the page content has been transferred, I have not
yet updated the MathAction software itself, so some of the
pages, e.g. Maxima and Sage pages, will not work the same
as on axiom-developer. I plan to complete the software part
of the upgrade to axiom.risc some time this weekend.

-----------

Here is an annotated partial transcript of my session with
ZSyncer this morning. Maybe it will help to show you how
this works. If you have any questions, just let me know.

1 At http://page.axiom-developer.org/zope/manage

  Although you can work from either location, I prefer to use
  axiom-developer as the host. The reason this works out
  better this way has to do with the bugs in the timezone-based
  time comparisons. Since the axiom.risc computer is +7 hours
  from axiom-developer few pages get incorrectly flagged as
  updated. :(

2 Click  'ZSyncer (ZSyncer)'

  I have changed a few options this morning since you looked at
  it. Using the 'Filter out types' options under 'Properties'
  allows us to look at only those things that need syncing,
  ignoring the other stuff. Maybe this is make it a little less
  confusing.

3 Click ' Sync' tab

4 First sync the Axiom Portal. This is less confusing because
  the times work out properly for most Plone objects (except
  ZWiki pages in Plone :(

5 Click the 'Plone' link

6 You should also remove the checkbox next to green checkmark
  to avoid having to look at things that are already up-to-date.
  Then click 'Reload'.

7 Finally some real work to do! The blue checkboxes mean that
  something has been added to axiom.risc or deleted from
  axiom-developer - you wont know which or why until you check
  the content. If you decide it is a valid new page or if for
  some reason you need to recover this page from the axiom.risc
  backup, click the checkboxe beside the blue + (extra) for
  those items.

8 Click 'Get' to update axiom-developer from these files at
  axiom.risc or click 'Delete' to remove the file.

9 We will see messages like:

   Getting objects from server
http://page.axiom-developer.org:8080/ZSyncer
   Getting "Plone/refs/articles/aldordoc.pdf"...
   OK: Plone/refs/articles/aldordoc.pdf downloaded
   Getting "Plone/refs/articles/define.pdf"...
   OK: Plone/refs/articles/define.pdf downloaded
   ...

   Click 'Ok' to continue.

10 Rather than the blue + marks you are more likely to see the
   orange crosses and red question marks? That orange means that
   the page has been modified (one either axiom-developer or
   axiom.risc (time zone bugs notwithstanding). Red means that
   it is a new page on axiom-developer. Now you have to decide
   to use Put to transfer/update the page to axiom.risc or (maybe)
   to click Delete.

10 Now check the Axiom Wiki. Click on 'ZSyner', then the 'Sync'
   tab and the 'mathaction' link. Click the checkbox beside the
   green checkmark and click 'Reload'

  You should see at least the following:

  + 2000NewBaseIssueForRisc
  + 2001TestIssue

  These are dummy entries on axiom.risc to make sure that if someone
  creates an issue report on axiom.risc, then it will not have the
  same number as one on axiom-developer.  If there is a real issue
  report that must be move to axiom-developer, my plan is to renumber
  it at that time. They should not be moved without first renumbering.

\start
Date: Thu, 17 Aug 2006 21:56:22 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: axiom.risc.uni-linz.ac.at

Thank you, Bill,

I've saved your mail to remember what I have to do if that becomes 
necessary.

You do a sync every week or so?

\start
Date: Thu, 17 Aug 2006 15:45:25 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: repetition of  \subsection{Layer21} in src/algebra/Makefile.pamphlet

> There are two subsections "Layer 21" in the file
> src/algebra/Makefile.pamphlet. The line 1054 can be removed.

fixed. available in the next release --t

\start
Date: Thu, 17 Aug 2006 15:57:57 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: axiom.risc.uni-linz.ac.at

Ralf,

On Thursday, August 17, 2006 3:56 PM you asked:
> ...
> You do a sync every week or so?
>

Normally every Sunday evening. But sometimes I am later.
If there is an important change or set of changes,
there is no reason why one of us couldn't do it right
away. Once you get used to the tool (and it's limitations)
it doesn't seem to take long: 5 - 10 minutes.

\start
Date: Thu, 17 Aug 2006 22:12:19 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: axiom.risc.uni-linz.ac.at

OK,

ZSync

> there is no reason why one of us couldn't do it right
> away. Once you get used to the tool (and it's limitations)
> it doesn't seem to take long: 5 - 10 minutes.

I have seen that you could even roll back changes if I make some stupid 
mistake, right?

\start
Date: Fri, 18 Aug 2006 09:46:09 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: http://wiki.axiom-developer.org/MutualRecursion
Cc: Camm Maguire

On August 18, 2006 8:09 AM Ralf Hemmecke wrote:
> 
> http://wiki.axiom-developer.org/MutualRecursion
> 
> I think you need to remove the .erlib file from the harddisk. 
> (Click on the first "+spad" of that site.)
> 

The problem is not the 'xxx.erlib' directory as such but rather the
failure to overwrite the existing 'xxx.NRLIB' directory. Something
has changed in recent versions of Axiom, gcl or linux which prevents
the lisp function delete-file from deleting the directory.

See details:

http://wiki.axiom-developer.org/SandBoxArrays

This is a known and annoying bug described here:

http://wiki.axiom-developer.org/302CannotRenameTheFileErlibToNRLIB

Tim believes the problem is in GCL but Camm says that aspect of GCL
has not changed. We need to find a solution.

As a work-round to the problem perhaps we should modify Axiom to
call

  (system "rm -r xxx.NRLIB")

before the rename?

\start
Date: 18 Aug 2006 10:14:48 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

Greetings!  I seem to be missing some dependency:

make[2]: Leaving directory `/fix/t1/camm/debian/axiom/build-improvements'
/bin/sh: t8: command not found
make[1]: [do-all] Error 127 (ignored)
/fix/t1/camm/debian/axiom/build-improvements/build/scripts/document: line 23: -t8: command not found
/fix/t1/camm/debian/axiom/build-improvements/build/scripts/document: line 24: -delay: command not found


What is t8?

Take care,

Bill Page writes:

> Camm, 
> 
> On Wednesday, August 16, 2006 4:05 PM you wrote:
> > 
> > Bill Page writes:
> > 
> > > With your patch below applied to the current Silver version
> > > of Axiom with the modified gcl-2.6.8pre pulled from cvs,
> > > I get a different result, but an error persists:
> > > 
> > >   $tail -18 build3.log
> > > 
> > > Loading 
> > /home/page/axiom.build-improvements/obj/linux/interp/cformat.o
> > > start address -T 0x857a700 Finished loading
> > > /home/page/axiom.build-improvements/obj/linux/interp/cformat.o
> > > Loading /home/page/axiom.build-improvements/obj/linux/interp/cfuns.o
> > > directoryp is undefined
> > > 
> > > Error: Cannot get relocated section contents
> > > 
> > ... 
> > My apologies -- all my testing is with the Debian package, so
> > I did not see this.
> 
> I hope that we will soon move to the Debian style build on all
> Axiom systems.
> 
> > Can you please give me simple instructions whereby I
> > might obtain silver and reproduce this?  Preferably stable
> > retrieve-and-make-the-latest instructions that I can store
> > in 1 cons of long term brain memory :-)?
> 
> Can you spare 6? :)
> 
> 1 svn co \
>   https://svn.sourceforge.net/svnroot/axiom/branches/build-improvements
> \
>     axiom.build-improvements
> 2 cd axiom.build-improvements
> 3 replace gcl-2.6.8pre tarball from cvs
> 4 apply Camm's patchs in src/interp
> 5 ./configure
> 6 make
> 
> Let me know if you have any questions. Or take a look
> at
> 
> http://wiki.axiom-developer.org/AxiomSilverBranch

\start
Date: Fri, 18 Aug 2006 16:35:46 +0200
From: Ralf Hemmecke
To: Camm Maguire
Subject: re: NULL_OR_ON_C_STACK macro invalid
Cc: Robert Boyer

On 08/18/2006 04:14 PM, Camm Maguire wrote:
> Greetings!  I seem to be missing some dependency:
> 
> make[2]: Leaving directory `/fix/t1/camm/debian/axiom/build-improvements'
> /bin/sh: t8: command not found
> make[1]: [do-all] Error 127 (ignored)
> /fix/t1/camm/debian/axiom/build-improvements/build/scripts/document: line 23: -t8: command not found
> /fix/t1/camm/debian/axiom/build-improvements/build/scripts/document: line 24: -delay: command not found
> 
> 
> What is t8?

If you look at build/scripts/document you'll find a lie that looks like

  $tangle -t8 $FILE.pamphlet >$FILE

Obviously your $tangle variable expands to nothing. Something wrong with 
  "configure", because build/scripts/document is generated during 
./configure.

\start
Date: Fri, 18 Aug 2006 10:45:54 -0400
From: Tim Daly
To: Alfredo Portes
Subject: Re: Help/Guidance/anything...

Jose,

The fundamental idea we are trying to achieve is to take a pamphlet
file from an external website URL and somehow "drag-and-drop" it onto
a browser location. The paper and its embedded code should become
part of Axiom so the user can read it and use the code, perhaps in a
\begin{axiom} block.

It would be ideal if the drag-and-drop facility were not axiom specific
(or could be customized that way) so we could drag-and-drop onto any
system. That way the researcher can use any language to implement their
work. I realize that this does not benefit Axiom but the Doyen idea is
not just about Axiom, it is a science platform.

The drag-and-drop will work any way you choose to implement it.
The implementation determines a lot of what we can do. Since you've
looked at the wiki and the axiom connection you are in the best
situation to say how it should work. Since no-one knows how to do it
your work is clearly research and you get to decide everything.

Like any good research idea it will likely get adopted. The SAGE
people could clearly use such a feature, especially if they adopt
some or all of Bill's work.

Of course, once people try the feature they will have new ideas so
your first implementation will likely get additional feedback.

Please be sure to document how it works so we can build and maintain it.
Doyen is as much about documenting the process as it is about building
the CD.

\start
Date: Fri, 18 Aug 2006 10:48:29 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

looks like there is a place where a ${NOTANGLE} symbol is not defined.
the -t8 -delay are options on that command.

\start
Date: 18 Aug 2006 16:56:09 +0200
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

Camm Maguire writes:

| Greetings!  I seem to be missing some dependency:
| 
| make[2]: Leaving directory `/fix/t1/camm/debian/axiom/build-improvements'
| /bin/sh: t8: command not found
| make[1]: [do-all] Error 127 (ignored)
| /fix/t1/camm/debian/axiom/build-improvements/build/scripts/document: line 23: -t8: command not found
| /fix/t1/camm/debian/axiom/build-improvements/build/scripts/document: line 24: -delay: command not found
| 

Camm please send me your config.log

if you don't have noweb installed, the one comming with Axiom should
be
built, and configure substitute the right value for $tangle.

\start
Date: Fri, 18 Aug 2006 11:01:59 -0400
From: Bill Page
To: Ralf Hemmecke, Camm Maguire
Subject: re: NULL_OR_ON_C_STACK macro invalid
Cc: Robert Boyer

On August 18, 2006 10:36 AM Ralf Hemmecke wrote:
> 
> On 08/18/2006 04:14 PM, Camm Maguire wrote:
> > ... 
> /fix/t1/camm/debian/axiom/build-improvements/build/scripts/doc
> ument: line 24: -delay: command not found
> > 
> > 
> > What is t8?
> 
> If you look at build/scripts/document you'll find a lie that 
> looks like
> 
>   $tangle -t8 $FILE.pamphlet >$FILE
> 
> Obviously your $tangle variable expands to nothing. Something 
> wrong with "configure", because build/scripts/document is
> generated during 
> ./configure.
>

This did not happen in my copy of build-improvements from
August 15. In the 'documents' script I see:

[page@axiom-developer axiom.build-improvements]$ ls -l
build/scripts/document
-rwxrwxr-x    1 page     page          748 Aug 15 20:57
build/scripts/document

[page@axiom-developer axiom.build-improvements]$ cat build/scripts/document
#!/bin/sh
latex=latex
tangle=notangle
weave=noweave

if [ "$#" = "3" ]; then
 REDIRECT=$2
 FILE=`basename $3 .pamphlet`
 $tangle -t8 $FILE.pamphlet >$FILE
 $weave -delay $FILE.pamphlet >$FILE.tex
 $latex --interaction nonstopmode $FILE.tex >$REDIRECT
 $latex --interaction nonstopmode $FILE.tex >$REDIRECT
 rm -f $FILE~
 rm -f $FILE.pamphlet~
 rm -f $FILE.log
 rm -f $FILE.tex
 rm -f $FILE.toc
 rm -f $FILE.aux
 exit 0
fi
if [ "$#" = "1" ]; then
 FILE=`basename $1 .pamphlet`
 $tangle -t8 $FILE.pamphlet >$FILE
 $weave -delay $FILE.pamphlet >$FILE.tex
 $latex $FILE.tex
 $latex $FILE.tex
 rm -f $FILE~
 rm -f $FILE.pamphlet~
 rm -f $FILE.log
 rm -f $FILE.tex
 rm -f $FILE.toc
 rm -f $FILE.aux
 exit 0
fi
echo "document [ -o redirect ] pamphlet"

\start
Date: Fri, 18 Aug 2006 11:13:01 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: axiom.risc.uni-linz.ac.at

Ralf,

On August 17, 2006 4:12 PM you wrote:
> 
> ZSync
> 
> > there is no reason why one of us couldn't do it right
> > away. Once you get used to the tool (and it's limitations)
> > it doesn't seem to take long: 5 - 10 minutes.
> 
> I have seen that you could even roll back changes if I make 
> some stupid mistake, right?
> 

Ummm, well... usually. Zope does have a general "history"
mechanism and you can usually 'undo' changes or at least
copy old versions of objects (pages) forward. But for reasons
I do not understand, replacing a copy of an object on a web
site with a newer one from another web site does not copy the
objects history :( and further it seems as if the history of
the object to which we are copying also appears to be lost.
<scary> This needs more testing but I think I would call this
a bug in Zsyncer.

A related problem is that the creation date of the copied object
gets updated. This is apparently a "known problem". But it seems
that no one is particularly active about maintaining Zsyncer.

So when using Zsyncer caution is appropriate. :)

\start
Date: 18 Aug 2006 11:21:38 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

Greetings, and thanks!
=============================================================================
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by Axiom silver branch configure 2006-07-15, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  $ ./configure 

## --------- ##
## Platform. ##
## --------- ##

hostname = intech19
uname -m = i686
uname -r = 2.4.25
uname -s = Linux
uname -v = #5 SMP Thu Feb 24 18:54:17 EST 2005

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = i686
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
hostinfo               = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: .
PATH: /home/camm/bin/i386
PATH: /home/camm/bin/scripts
PATH: /usr/local/bin
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/bin/X11
PATH: /usr/games
PATH: /usr/bin/X11
PATH: /home/camm/openoffice60


## ----------- ##
## Core tests. ##
## ----------- ##

configure:1319: checking build system type
configure:1337: result: i686-pc-linux
configure:1345: checking host system type
configure:1359: result: i686-pc-linux
configure:1367: checking target system type
configure:1381: result: i686-pc-linux
configure:1457: checking for gcc
configure:1483: result: gcc
configure:1727: checking for C compiler version
configure:1730: gcc --version </dev/null >&5
gcc (GCC) 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:1733: $? = 0
configure:1735: gcc -v </dev/null >&5
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)
configure:1738: $? = 0
configure:1740: gcc -V </dev/null >&5
gcc: '-V' option must have argument
configure:1743: $? = 1
configure:1766: checking for C compiler default output file name
configure:1769: gcc    conftest.c  >&5
configure:1772: $? = 0
configure:1818: result: a.out
configure:1823: checking whether the C compiler works
configure:1829: ./a.out
configure:1832: $? = 0
configure:1849: result: yes
configure:1856: checking whether we are cross compiling
configure:1858: result: no
configure:1861: checking for suffix of executables
configure:1863: gcc -o conftest    conftest.c  >&5
configure:1866: $? = 0
configure:1891: result: 
configure:1897: checking for suffix of object files
configure:1918: gcc -c   conftest.c >&5
configure:1921: $? = 0
configure:1943: result: o
configure:1947: checking whether we are using the GNU C compiler
configure:1971: gcc -c   conftest.c >&5
configure:1977: $? = 0
configure:1981: test -z 
			 || test ! -s conftest.err
configure:1984: $? = 0
configure:1987: test -s conftest.o
configure:1990: $? = 0
configure:2003: result: yes
configure:2009: checking whether gcc accepts -g
configure:2030: gcc -c -g  conftest.c >&5
configure:2036: $? = 0
configure:2040: test -z 
			 || test ! -s conftest.err
configure:2043: $? = 0
configure:2046: test -s conftest.o
configure:2049: $? = 0
configure:2060: result: yes
configure:2077: checking for gcc option to accept ANSI C
configure:2147: gcc  -c -g -O2  conftest.c >&5
configure:2153: $? = 0
configure:2157: test -z 
			 || test ! -s conftest.err
configure:2160: $? = 0
configure:2163: test -s conftest.o
configure:2166: $? = 0
configure:2184: result: none needed
configure:2202: gcc -c -g -O2  conftest.c >&5
conftest.c:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'me'
configure:2208: $? = 1
configure: failed program was:
| #ifndef __cplusplus
|   choke me
| #endif
configure:2354: checking for a BSD-compatible install
configure:2409: result: /usr/bin/install -c
configure:2546: checking for gawk
configure:2562: found /usr/bin/gawk
configure:2572: result: gawk
configure:2587: checking for gtar
configure:2616: result: no
configure:2587: checking for tar
configure:2603: found /bin/tar
configure:2613: result: tar
configure:2631: checking for gpatch
configure:2660: result: no
configure:2631: checking for patch
configure:2647: found /usr/bin/patch
configure:2657: result: patch
configure:2675: checking for make
configure:2691: found /usr/bin/make
configure:2704: result: make
configure:2753: checking for ranlib
configure:2769: found /usr/bin/ranlib
configure:2780: result: ranlib
configure:2795: checking for touch
configure:2811: found /usr/bin/touch
configure:2824: result: touch
configure:2834: checking for latex
configure:2850: found /usr/bin/latex
configure:2863: result: latex
configure:2892: checking for notangle
configure:2921: result: no
configure:2927: checking for noweave
configure:2956: result: no
configure:2987: checking how to run the C preprocessor
configure:3022: gcc -E  conftest.c
configure:3028: $? = 0
configure:3060: gcc -E  conftest.c
conftest.c:9:28: error: ac_nonexistent.h: No such file or directory
configure:3066: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME "Axiom silver branch"
| #define PACKAGE_TARNAME "axiom-silver-branch"
| #define PACKAGE_VERSION "2006-07-15"
| #define PACKAGE_STRING "Axiom silver branch 2006-07-15"
| #define PACKAGE_BUGREPORT "list"
| /* end confdefs.h.  */
| #include <ac_nonexistent.h>
configure:3105: result: gcc -E
configure:3129: gcc -E  conftest.c
configure:3135: $? = 0
configure:3167: gcc -E  conftest.c
conftest.c:9:28: error: ac_nonexistent.h: No such file or directory
configure:3173: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME "Axiom silver branch"
| #define PACKAGE_TARNAME "axiom-silver-branch"
| #define PACKAGE_VERSION "2006-07-15"
| #define PACKAGE_STRING "Axiom silver branch 2006-07-15"
| #define PACKAGE_BUGREPORT "list"
| /* end confdefs.h.  */
| #include <ac_nonexistent.h>
configure:3217: checking for X
configure:3322: gcc -E  conftest.c
configure:3328: $? = 0
configure:3378: gcc -o conftest -g -O2   conftest.c -lXt  >&5
configure:3384: $? = 0
configure:3388: test -z 
			 || test ! -s conftest.err
configure:3391: $? = 0
configure:3394: test -s conftest
configure:3397: $? = 0
configure:3447: result: libraries , headers 
configure:3619: gcc -o conftest -g -O2   conftest.c   -lX11 >&5
configure:3625: $? = 0
configure:3629: test -z 
			 || test ! -s conftest.err
configure:3632: $? = 0
configure:3635: test -s conftest
configure:3638: $? = 0
configure:3796: checking for gethostbyname
configure:3853: gcc -o conftest -g -O2   conftest.c  >&5
configure:3859: $? = 0
configure:3863: test -z 
			 || test ! -s conftest.err
configure:3866: $? = 0
configure:3869: test -s conftest
configure:3872: $? = 0
configure:3884: result: yes
configure:4035: checking for connect
configure:4092: gcc -o conftest -g -O2   conftest.c  >&5
configure:4098: $? = 0
configure:4102: test -z 
			 || test ! -s conftest.err
configure:4105: $? = 0
configure:4108: test -s conftest
configure:4111: $? = 0
configure:4123: result: yes
configure:4198: checking for remove
configure:4255: gcc -o conftest -g -O2   conftest.c  >&5
configure:4261: $? = 0
configure:4265: test -z 
			 || test ! -s conftest.err
configure:4268: $? = 0
configure:4271: test -s conftest
configure:4274: $? = 0
configure:4286: result: yes
configure:4361: checking for shmat
configure:4418: gcc -o conftest -g -O2   conftest.c  >&5
configure:4424: $? = 0
configure:4428: test -z 
			 || test ! -s conftest.err
configure:4431: $? = 0
configure:4434: test -s conftest
configure:4437: $? = 0
configure:4449: result: yes
configure:4533: checking for IceConnectionNumber in -lICE
configure:4563: gcc -o conftest -g -O2   conftest.c -lICE   >&5
configure:4569: $? = 0
configure:4573: test -z 
			 || test ! -s conftest.err
configure:4576: $? = 0
configure:4579: test -s conftest
configure:4582: $? = 0
configure:4595: result: yes
configure:4635: Linux
configure:4830: creating ./config.status

## ---------------------- ##
## Running config.status. ##
## ---------------------- ##

This file was extended by Axiom silver branch config.status 2006-07-15, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  CONFIG_FILES    = 
  CONFIG_HEADERS  = 
  CONFIG_LINKS    = 
  CONFIG_COMMANDS = 
  $ ./config.status 

on intech19

config.status:675: creating Makefile
config.status:675: creating build/scripts/document

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=i686-pc-linux
ac_cv_build_alias=i686-pc-linux
ac_cv_c_compiler_gnu=yes
ac_cv_env_CC_set=set
ac_cv_env_CC_value=gcc
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_exeext=
ac_cv_func_connect=yes
ac_cv_func_gethostbyname=yes
ac_cv_func_remove=yes
ac_cv_func_shmat=yes
ac_cv_have_x='have_x=yes 		ac_x_includes= ac_x_libraries='
ac_cv_host=i686-pc-linux
ac_cv_host_alias=i686-pc-linux
ac_cv_lib_ICE_IceConnectionNumber=yes
ac_cv_objext=o
ac_cv_path_install='/usr/bin/install -c'
ac_cv_prog_AWK=gawk
ac_cv_prog_CPP='gcc -E'
ac_cv_prog_LATEX=latex
ac_cv_prog_MAKE=make
ac_cv_prog_PATCH=patch
ac_cv_prog_TAR=tar
ac_cv_prog_TOUCH=touch
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_ac_ct_RANLIB=ranlib
ac_cv_prog_cc_g=yes
ac_cv_prog_cc_stdc=
ac_cv_target=i686-pc-linux
ac_cv_target_alias=i686-pc-linux

## ----------------- ##
## Output variables. ##
## ----------------- ##

AWK='gawk'
AXIOM='/fix/t1/camm/debian/axiom/build-improvements/mnt/linux'
CC='gcc'
CFLAGS='-g -O2'
CPP='gcc -E'
CPPFLAGS=''
DEFS='-DPACKAGE_NAME=\"Axiom\ silver\ branch\" -DPACKAGE_TARNAME=\"axiom-silver-branch\" -DPACKAGE_VERSION=\"2006-07-15\" -DPACKAGE_STRING=\"Axiom\ silver\ branch\ 2006-07-15\" -DPACKAGE_BUGREPORT=\"list\" '
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EXEEXT=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
LATEX='latex'
LDFLAGS=''
LIBOBJS=''
LIBS=''
LTLIBOBJS=''
MAKE='make'
NOTANGLE=''
NOWEAVE=''
OBJEXT='o'
PACKAGE_BUGREPORT='list'
PACKAGE_NAME='Axiom silver branch'
PACKAGE_STRING='Axiom silver branch 2006-07-15'
PACKAGE_TARNAME='axiom-silver-branch'
PACKAGE_VERSION='2006-07-15'
PATCH='patch'
PATH_SEPARATOR=':'
RANLIB='ranlib'
SHELL='/bin/sh'
TAR='tar'
TOUCH='touch'
X_CFLAGS=''
X_CLFAGS=''
X_EXTRA_LIBS=''
X_LIBS=''
X_PRE_LIBS='-lXpm  -lSM -lICE'
ac_ct_CC='gcc'
ac_ct_RANLIB='ranlib'
axiom_build_bindir='/fix/t1/camm/debian/axiom/build-improvements/build/i686-pc-linux/bin'
axiom_build_libdir='/fix/t1/camm/debian/axiom/build-improvements/build/i686-pc-linux/lib'
axiom_build_notangle='/fix/t1/camm/debian/axiom/build-improvements/mnt/linux/bin/lib/notangle'
axiom_build_noweave='/fix/t1/camm/debian/axiom/build-improvements/mnt/linux/bin/lib/noweave'
axiom_builddir='/fix/t1/camm/debian/axiom/build-improvements/build/i686-pc-linux'
axiom_required_build_utils=''
bindir='${exec_prefix}/bin'
build='i686-pc-linux'
build_alias=''
build_cpu='i686'
build_os='linux'
build_vendor='pc'
datadir='${prefix}/share'
exec_prefix='${prefix}'
host='i686-pc-linux'
host_alias=''
host_cpu='i686'
host_os='linux'
host_vendor='pc'
includedir='${prefix}/include'
infodir='${prefix}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
oldincludedir='/usr/include'
prefix='/usr/local'
program_transform_name='s,x,x,'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target='i686-pc-linux'
target_alias=''
target_cpu='i686'
target_os='linux'
target_vendor='pc'

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_BUGREPORT "list"
#define PACKAGE_NAME "Axiom silver branch"
#define PACKAGE_STRING "Axiom silver branch 2006-07-15"
#define PACKAGE_TARNAME "axiom-silver-branch"
#define PACKAGE_VERSION "2006-07-15"

configure: exit 0
=============================================================================

Gabriel Dos Reis writes:

> Camm Maguire writes:
> 
> | Greetings!  I seem to be missing some dependency:
> | 
> | make[2]: Leaving directory `/fix/t1/camm/debian/axiom/build-improvements'
> | /bin/sh: t8: command not found
> | make[1]: [do-all] Error 127 (ignored)
> | /fix/t1/camm/debian/axiom/build-improvements/build/scripts/document: line 23: -t8: command not found
> | /fix/t1/camm/debian/axiom/build-improvements/build/scripts/document: line 24: -delay: command not found
> | 
> 
> Camm please send me your config.log
> 
> if you don't have noweb installed, the one comming with Axiom should
> be
> built, and configure substitute the right value for $tangle.

\start
Date: Fri, 18 Aug 2006 11:20:20 -0400
From: Tim Daly
To: Bill Page
Subject: re: NULL_OR_ON_C_STACK macro invalid
Cc: Camm Maguire, Robert Boyer

> If you look at build/scripts/document you'll find a lie that 
> looks like
                                                      ^^^
guffaw.... 

\start
Date: Fri, 18 Aug 2006 11:36:54 -0400
From: Bill Page
To: Alfredo Portes, Tim Daly
Subject: RE: Help/Guidance/anything...
Cc: Bob McElrath

Alfredo,

On August 18, 2006 3:21 AM you wrote:

> Hope not to take your time, but I would like to ask you couple
> of things, and go over couple Tim's ideas.

Time is something that should be freely given ... :)

> Tim Daly wrote:
>>Fifth, the XMLHttpRequest object is a JavaScript object that allows
>>you to construct an XML request without leaving the page. You store 
>>data in the object, invoke the send method, and then go thru a
>>5-state machine to get the information back. If Axiom is set up to
>>listen for the requests then Axiom can sit behind the browser and
>>service requests to do anything, like start graphics independently
>>or start graphics and store the resulting image and forward it to
>>the browser for inlining.
>
> Are you assuming that all this will happen outside the Wiki. Wouldn't
> be better to pass the pamphlet after dragged and dropped to the Wiki
> for processing? Thanks to the work done by Bill and Sage developers,
> it is possible to do inline commands and display it as Latex inside
> MathAction (Maxima and others now, Axiom probably later I assume).
> Or what you are looking for is to create another type of user
> interface for Axiom?

I think what Tim is talking about is more similar to the Sage Notebook
interface than it is to MathAction. MathAction does not use a "live"
Axiom process running in the background. The only interaction with
Axiom is during 'Preview' and 'Save'.

AJAX (XMLHttpRequest etc.) might still be very useful in MathAction
however in order to reduce the network traffic during a preview
operation, for example.

> I assume that another solution will be to have this machinery you
> described in the browser, and then have an option "Save to Wiki".

This latter suggestion is possible and is very similar to the method
used by TiddlyWiki. See also Bob McElrath's version of TiddlyWiki
with the jsMath and Axiom interface.

http://bob.mcelrath.org/tiddlymath/tiddlyjsmath.html
http://www.math.union.edu/~dpvc/jsMath

I think that for personal use (maybe even in Doyen) this is a
very nice wiki model.

Also if you haven't already done this, I think you might find it
useful to go back and review the early part of the discussions on
the AxiomUI project with Kai Kaminski about this time last year.
Check the axiom-developer archives.

>>So the game is to pick on a literate document, drag it onto the
>>browser,

> Like this: http://doyen.sytes.net/Test . This page is inside ZWiki.
> If you drag and drop an object into the textbox, it will try to
> look if it has .pamphlet extension outputting what it found. This
> happens without reloading the page like you said using the
> XMLHttpRequest.

Yes. This is a good start. I am not sure whether Tim has even looked
at this. Some of his comments seem written without knowledge of that
part of your work.

Perhaps it is appropriate to ask: What else besides just copying
the source text would we want the browser to do in this case?

Tim is thinking about updating a local installation of Axiom with
some new packages, tests and other files. It seems to me that in
the current Doyen/MathAction model this is best done by the
pamphlet mechanism in the wiki server, not in JavaScript on the
browser. E.g. one might imagine adding 'Build' and 'Run' commands
to supplement the existing 'tangle' function on the Pamphlet
thumbnail page so that it also becomes a kind of collaborative
web-based IDE (which also works local as Doyen).

>>fire up a firefox extension to read the clipboard, write the file
>> into the appropriate place, 

> This can be done by calling a script from the XMLHttpRequest. In
> the example above, it calls a Python script. So the script can
> take care of writing the files, calling Axiom, etc.

>> and then talk to axiom to compile and load the
>> file and build the documentation. 

> Then it comes back to the question of ZWiki and the work already
> done in MathAction to take care of this.

Again from my point of view this functionality is best implemented
on the server side, not in JavaScript.

If you choose another model like TiddlyWiki for example where there
is no "server side" then of course this would have to be done in
the browser. But this is not how Doyen works now.

>So my questions are: 
>
> Is it going to be a drag and drop box on the Wiki??? or is it
> going to located in the edit page??

I like the way you have implemented it now because it scales easily
to MathAction. We could implement your current drag-and-drop there
right now.

> After a pamphlet is dragged and dropped, is a new page with the
> document added to the wiki? 

I would prefer additional "IDE" type commands on the pamphlet
thumbnail as I suggested above.

> Sorry if I am totally off target (I should know what we are
> looking for after all this time), but I would like to know where
> to go from here?

No, you are asking the right questions. Thank you for continuing
this work.

\start
Date: Fri, 18 Aug 2006 12:10:24 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: Help/Guidance/anything...

Thanks Tim for taking time to respond.

The fundamental idea we are trying to achieve is to take a pamphlet
> file from an external website URL and somehow "drag-and-drop" it onto
> a browser location.


   Ok this is clear. I ran into a big problem right now. The ondrag (start,
end..)
   events are not implemented in Firefox :-( .

   Bug#: https://bugzilla.mozilla.org/show_bug.cgi?id=112288

   Looking for a workaround now.

The paper and its embedded code should become
> part of Axiom so the user can read it and use the code, perhaps in a
> \begin{axiom} block.


 This is something that troubles me. What does it mean to become part of
 axiom.

 If you have in a pamphlet:

   \begin{axiom} integrate(sin, x) \end{axiom}

 then this command should be executed and displayed inline, similar to
 what Bill has now with

  \begin{sage}
  maxima(....)
  \end{sage}

  Now to include a file, function or something else then the right way
should be to
  use something like:

  <<newfunction>>=
   .....................
  @

   and have something similar to what the tangle button inside Mathaction
does, but
   looking for all the chunks and putting them together as one file. Maybe
this is what
   you mean to added it then to axiom (assuming that we can determine that
is axiom),
   maybe: <<newfunction.axiom>>= or <<newfunction.maxima>>= or maybe let the
user
   add the file manually.

It would be ideal if the drag-and-drop facility were not axiom specific
> (or could be customized that way) so we could drag-and-drop onto any
> system. That way the researcher can use any language to implement their
> work. I realize that this does not benefit Axiom but the Doyen idea is
> not just about Axiom, it is a science platform.


  Understood.

The drag-and-drop will work any way you choose to implement it.
> The implementation determines a lot of what we can do. Since you've
> looked at the wiki and the axiom connection you are in the best
> situation to say how it should work. Since no-one knows how to do it
> your work is clearly research and you get to decide everything.


 I guess I better start writing specs and design for this, so anybody can
 give more input in a page in MathAction.

Like any good research idea it will likely get adopted. The SAGE
> people could clearly use such a feature, especially if they adopt
> some or all of Bill's work.
>
> Of course, once people try the feature they will have new ideas so
> your first implementation will likely get additional feedback.


  I really hope so. Without feedback I feel that I am not doing the right
thing.

Please be sure to document how it works so we can build and maintain it.
> Doyen is as much about documenting the process as it is about building
> the CD.


  Loud and clear.

\start
Date: Fri, 18 Aug 2006 12:30:39 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Help/Guidance/anything...
Cc: Bob McElrath

Bill,

Time is something that should be freely given ... :)


  Yes but I do not want to burn that bridge. :-).

I think what Tim is talking about is more similar to the Sage Notebook
> interface than it is to MathAction. MathAction does not use a "live"
> Axiom process running in the background. The only interaction with
> Axiom is during 'Preview' and 'Save'.


  Well then I guess it should be a combination of both. The drag and drop
seems
  more static to me in the sense that you just drag and drop a pamphlet it
  is processed and added to the wiki.

AJAX (XMLHttpRequest etc.) might still be very useful in MathAction
> however in order to reduce the network traffic during a preview
> operation, for example.
>

  Then we can have something like SageNotebook (
http://toolbox1.sytes.net/~alfredo/axiomui/ ) or if the  efforts of adding
Axiom to Sage goes well then this can be used.

This latter suggestion is possible and is very similar to the method
> used by TiddlyWiki. See also Bob McElrath's version of TiddlyWiki
> with the jsMath and Axiom interface.
>
> http://bob.mcelrath.org/tiddlymath/tiddlyjsmath.html
> http://www.math.union.edu/~dpvc/jsMath
>
> I think that for personal use (maybe even in Doyen) this is a
> very nice wiki model.


 I will look into it.

Also if you haven't already done this, I think you might find it
> useful to go back and review the early part of the discussions on
> the AxiomUI project with Kai Kaminski about this time last year.
> Check the axiom-developer archives.


  I think I read it a long time ago, but I will go over it again.

Perhaps it is appropriate to ask: What else besides just copying
> the source text would we want the browser to do in this case?
>
> Tim is thinking about updating a local installation of Axiom with
> some new packages, tests and other files. It seems to me that in
> the current Doyen/MathAction model this is best done by the
> pamphlet mechanism in the wiki server, not in JavaScript on the
> browser. E.g. one might imagine adding 'Build' and 'Run' commands
> to supplement the existing 'tangle' function on the Pamphlet
> thumbnail page so that it also becomes a kind of collaborative
> web-based IDE (which also works local as Doyen).


  I agree with you that the current pamphlet mechanism should be the
way to go.

Again from my point of view this functionality is best implemented
> on the server side, not in JavaScript.


  Server side it is.

  Thank you for taking time to answer my demands, I mean my questions. :-)

\start
Date: Fri, 18 Aug 2006 12:50:28 -0400
From: Alfredo Portes
To: Bill Page
Subject: AxiomUI

http://wiki.axiom-developer.org/AxiomUI

what is the status of this project???

Regards,

\start
Date: 18 Aug 2006 19:03:13 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: NULL_OR_ON_C_STACK macro invalid
Cc: Camm Maguire, Robert Boyer

Bill Page writes:

| On August 18, 2006 10:36 AM Ralf Hemmecke wrote:
| > 
| > On 08/18/2006 04:14 PM, Camm Maguire wrote:
| > > ... 
| > /fix/t1/camm/debian/axiom/build-improvements/build/scripts/doc
| > ument: line 24: -delay: command not found
| > > 
| > > 
| > > What is t8?
| > 
| > If you look at build/scripts/document you'll find a lie that 
| > looks like
| > 
| >   $tangle -t8 $FILE.pamphlet >$FILE
| > 
| > Obviously your $tangle variable expands to nothing. Something 
| > wrong with "configure", because build/scripts/document is
| > generated during 
| > ./configure.
| >
| 
| This did not happen in my copy of build-improvements from
| August 15. In the 'documents' script I see:
| 
| [page@axiom-developer axiom.build-improvements]$ ls -l
| build/scripts/document
| -rwxrwxr-x    1 page     page          748 Aug 15 20:57
| build/scripts/document
| 
| [page@axiom-developer axiom.build-improvements]$ cat build/scripts/document
| #!/bin/sh
| latex=latex
| tangle=notangle
| weave=noweave

This is because configure found:
   * latex in your build environment
   * noweb in your build environment

and consequently substituted those values in src/scripts/document.in,
producing build/scripts/document.

src/scripts/document.in reads

    #!/bin/sh
    latex=@LATEX@
    tangle=@NOTANGLE@
    weave=@NOWEAVE@

    if [ "$#" = "3" ]; then
     REDIRECT=$2
     FILE=`basename $3 .pamphlet`
     $tangle -t8 $FILE.pamphlet >$FILE
     $weave -delay $FILE.pamphlet >$FILE.tex
     $latex --interaction nonstopmode $FILE.tex >$REDIRECT
     $latex --interaction nonstopmode $FILE.tex >$REDIRECT
     rm -f $FILE~
     rm -f $FILE.pamphlet~
     rm -f $FILE.log
     rm -f $FILE.tex
     rm -f $FILE.toc
     rm -f $FILE.aux
     exit 0
    fi
    if [ "$#" = "1" ]; then
     FILE=`basename $1 .pamphlet`
     $tangle -t8 $FILE.pamphlet >$FILE
     $weave -delay $FILE.pamphlet >$FILE.tex
     $latex $FILE.tex 
     $latex $FILE.tex
     rm -f $FILE~
     rm -f $FILE.pamphlet~
     rm -f $FILE.log
     rm -f $FILE.tex
     rm -f $FILE.toc
     rm -f $FILE.aux
     exit 0
    fi
    echo "document [ -o redirect ] pamphlet"

\start
Date: 18 Aug 2006 19:20:53 +0200
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

[...]

| configure:2892: checking for notangle
| configure:2921: result: no
| configure:2927: checking for noweave
| configure:2956: result: no

[...]

| ## ----------------- ##
| ## Output variables. ##
| ## ----------------- ##

[...]

| NOTANGLE=''
| NOWEAVE=''


OK, I got it.  You don't noweb in your environement.  That is OK.
However, for some reasons, NOTANGLE and NOWEAVE are not set to
point to those build as part of Axiom.  That is weird because, you
configure.ac should have these lines

-----------------
axiom_use_noweb=
AC_ARG_WITH([noweb], [assume noweb is present in the build environment],
            [case $withval in
                yes|no) axiom_use_noweb=$withval ;;
                *) AC_MSG_ERROR([erroneous value for --with-noweb]) ;;
             esac])

## Check for notangle and noweb if we are not explicitly told
## to build noweb from Axiom sources.
if test x$axiom_use_noweb != xno; then
    AC_CHECK_PROG([NOTANGLE], [notangle], [notangle])
    AC_CHECK_PROG([NOWEAVE], [noweave], [noweave])

    ## Ensure the build environment is consistent with specified option.
    if test x$axiom_use_noweb = xyes \
        && test -z $NOTANGLE -o -z $NOWEAVE; then
        AC_MSG_ERROR([noweb utils are missing but --with-noweb is specified])
    fi
## Otherwise, either noweb is missing from the build environment or
## we are told not to check.  In both cases, we do need noweb; so
## tell the Makefiles to build one and use it.
else
    NOTANGLE=$axiom_build_bindir/notangle
    NOWEAVE=$axiom_build_bindir/noweave
    axiom_required_build_utils="$axiom_required_build_utils noweb"
    AC_SUBST(NOTANGLE)
    AC_SUBST(NOWEAVE)
fi
-----------------

\start
Date: 18 Aug 2006 14:33:42 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

Greetings, and thanks!  I'm just after Bill's directoryp relocation
error at the moment, and have a ton of other items on the plate.  What
should I do to work around to reproduce Bill's bug?

Take care,

Gabriel Dos Reis writes:

> [...]
> 
> | configure:2892: checking for notangle
> | configure:2921: result: no
> | configure:2927: checking for noweave
> | configure:2956: result: no
> 
> [...]
> 
> | ## ----------------- ##
> | ## Output variables. ##
> | ## ----------------- ##
> 
> [...]
> 
> | NOTANGLE=''
> | NOWEAVE=''
> 
> 
> OK, I got it.  You don't noweb in your environement.  That is OK.
> However, for some reasons, NOTANGLE and NOWEAVE are not set to
> point to those build as part of Axiom.  That is weird because, you
> configure.ac should have these lines
> 
> -----------------
> axiom_use_noweb=
> AC_ARG_WITH([noweb], [assume noweb is present in the build environment],
>             [case $withval in
>                 yes|no) axiom_use_noweb=$withval ;;
>                 *) AC_MSG_ERROR([erroneous value for --with-noweb]) ;;
>              esac])
> 
> ## Check for notangle and noweb if we are not explicitly told
> ## to build noweb from Axiom sources.
> if test x$axiom_use_noweb != xno; then
>     AC_CHECK_PROG([NOTANGLE], [notangle], [notangle])
>     AC_CHECK_PROG([NOWEAVE], [noweave], [noweave])
> 
>     ## Ensure the build environment is consistent with specified option.
>     if test x$axiom_use_noweb = xyes \
>         && test -z $NOTANGLE -o -z $NOWEAVE; then
>         AC_MSG_ERROR([noweb utils are missing but --with-noweb is specified])
>     fi
> ## Otherwise, either noweb is missing from the build environment or
> ## we are told not to check.  In both cases, we do need noweb; so
> ## tell the Makefiles to build one and use it.
> else
>     NOTANGLE=$axiom_build_bindir/notangle
>     NOWEAVE=$axiom_build_bindir/noweave
>     axiom_required_build_utils="$axiom_required_build_utils noweb"
>     AC_SUBST(NOTANGLE)
>     AC_SUBST(NOWEAVE)
> fi
> -----------------

\start
Date: Fri, 18 Aug 2006 14:40:15 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: AxiomUI

On August 18, 2006 12:50 PM Alfredo Portes

> http://wiki.axiom-developer.org/AxiomUI
>
> what is the status of this project???

Kai Kaminski is still hear on this email list (I think). Probably
currently interested in different things. Last I heard he was
preparing a version of the hyperdoc content for browsing in
HTML format. I recall seeing an earlier version of this that
looked quite nice but I haven't heard anything more about it
lately.

The source code that Kai produced during the SoC project is
available in the tla archive. I have looked at it only briefly,
first to test that it worked as claimed on linux and then
(with a little more frustration) at trying to get it to run
on Windows - which writing it in Clisp was supposed to make
possible, but didn't .. :(

No one else has taken up the task of extending and completing
the AxiomUI work. One of the results of the this work that
would be very nice to have even without completing the rest
of the user interface is the kind external program interface
like the one done for Maxima. This would make interfacing with
Axiom much easier for MathAction and any other program that
wants to use Axiom.

\start
Date: Fri, 18 Aug 2006 14:42:04 -0400
From: Bill Page
To: Camm Maguire, Gabriel Dos Reis
Subject: RE: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

On August 18, 2006 2:34 PM you wrote:
> 
> Greetings, and thanks!  I'm just after Bill's directoryp relocation
> error at the moment, and have a ton of other items on the plate.

I really appreciate you taking the time to look at this.

> What should I do to work around to reproduce Bill's bug?
> 

apt-get install noweb ? :)

\start
Date: 18 Aug 2006 15:08:03 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: http://wiki.axiom-developer.org/MutualRecursion

Greetings!

This one I believe is machine specific -- can I log in and reproduce?
(is this axiom-developer.org?)

In general, the easiest way for me to fix these things is to work with
a build atop GCL configured with --enable-debug.  If anyone has the
time to produce such a build somewhere and confirm that the error
persists, then point me to it, we can take care of this in short
order.  I realize that everyeon else's time is also limited, so if
this is not possible please so state.

Take care,

Bill Page writes:

> On August 18, 2006 8:09 AM Ralf Hemmecke wrote:
> > 
> > http://wiki.axiom-developer.org/MutualRecursion
> > 
> > I think you need to remove the .erlib file from the harddisk. 
> > (Click on the first "+spad" of that site.)
> > 
> 
> The problem is not the 'xxx.erlib' directory as such but rather the
> failure to overwrite the existing 'xxx.NRLIB' directory. Something
> has changed in recent versions of Axiom, gcl or linux which prevents
> the lisp function delete-file from deleting the directory.
> 
> See details:
> 
> http://wiki.axiom-developer.org/SandBoxArrays
> 
> This is a known and annoying bug described here:
> 
> http://wiki.axiom-developer.org/302CannotRenameTheFileErlibToNRLIB
> 
> Tim believes the problem is in GCL but Camm says that aspect of GCL
> has not changed. We need to find a solution.
> 
> As a work-round to the problem perhaps we should modify Axiom to
> call
> 
>   (system "rm -r xxx.NRLIB")
> 
> before the rename?

\start
Date: 18 Aug 2006 15:24:04 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

Thank you!  Off and running ...

Take care,

Bill Page writes:

> Camm,
> 
> On August 18, 2006 2:34 PM you wrote:
> > 
> > Greetings, and thanks!  I'm just after Bill's directoryp relocation
> > error at the moment, and have a ton of other items on the plate.
> 
> I really appreciate you taking the time to look at this.
> 
> > What should I do to work around to reproduce Bill's bug?
> > 
> 
> apt-get install noweb ? :)

\start
Date: Fri, 18 Aug 2006 15:38:16 -0400
From: Alfredo Portes
To: Bill Page 
Subject: Axiom LatexWiki

Bill any idea what is this:

vp1:=draw(sin(x), x=%pi/10..%pi)
   >> System error:
  (SYSTEM "gcc -c -Wall -DVOL=volatile -fsigned-char -pipe
-I/home/page/repository/axiom--main--1/mnt/linux/bin/../h -O3
-fomit-frame-pointer -c \"/tmp/gazonk1.c\" -o \"/tmp/gazonk1.o\" -w")
returned a non-zero value 0.

I get this error if I try to do:

\begin{axiom}
vp1:=draw(sin(x), x=%pi/10..%pi)
\end{axiom}

That is using the binaries files of Axiom from MathAction:

)version
Value = "Wednesday June 21, 2006 at 03:45:56 "

\start
Date: 18 Aug 2006 22:05:06 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Camm Maguire, Robert Boyer

Bill Page writes:

| Camm,
| 
| On August 18, 2006 2:34 PM you wrote:
| > 
| > Greetings, and thanks!  I'm just after Bill's directoryp relocation
| > error at the moment, and have a ton of other items on the plate.
| 
| I really appreciate you taking the time to look at this.
| 
| > What should I do to work around to reproduce Bill's bug?
| > 
| 
| apt-get install noweb ? :)

yes, that may solve his immediate issue.  However, while I understand
how his build is failing, I don't understand how he got there.
My builds are OK.  How are yours, except the GCL issue?

\start
Date: Fri, 18 Aug 2006 16:45:32 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: NULL_OR_ON_C_STACK macro invalid (was: noweb)

On August 18, 2006 4:05 PM Gaby wrote:
> 
> | On August 18, 2006 2:34 PM Camm wrote:
> | > What should I do to work around to reproduce Bill's bug?
> | > 
> | 
> Bill Page writes:
> | apt-get install noweb ? :)
> 
> yes, that may solve his immediate issue.  However, while
> I understand how his build is failing, I don't understand
> how he got there. My builds are OK.  How are yours, except
> the GCL issue?
> 

I am not having any problems with the build process but I
have not tried to build without having noweb pre-installed.
I could do it later if you like. Maybe someone else can
report on their experience?

\start
Date: Fri, 18 Aug 2006 16:59:04 -0400
From: Alfredo Portes
To: Bill Page
Subject: Another question

Probably this has come out many times in previous discussions.
Given the latex output from Axiom, what would be the best way to
display it on a webpage.

Complete as latex document -> latex -> dvipng???

or how is it done on MathAction?

\start
Date: 18 Aug 2006 17:26:03 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

Greetings!

OK, this one is my fault, as I fogot we were still using EXTRAS in the
makefile here.  2.6.8pre incorporates Gordon Novak's xgcl, and the way
I build it was using compiler::link from within lisp as it was
simpler.  This overrides EXTRAS at the very end, as it copies the
compiler::link generated saved_xgcl over the saved_gcl left by
unixport/makefile.

I'll probably have to revert this and do xgcl the old fashioned way.
In the meantime, --disable-xgcl should work.  Please let me know if
not. 

Take care,

Bill Page writes:

> Camm,
> 
> On August 18, 2006 2:34 PM you wrote:
> > 
> > Greetings, and thanks!  I'm just after Bill's directoryp relocation
> > error at the moment, and have a ton of other items on the plate.
> 
> I really appreciate you taking the time to look at this.
> 
> > What should I do to work around to reproduce Bill's bug?
> > 
> 
> apt-get install noweb ? :)

\start
Date: Fri, 18 Aug 2006 17:36:28 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Questions

Alfredo,

On August 18, 2006 2:27 PM you asked:

> 1. When you are adding a CAS system, how do you go about
> testing outside ZWiki.  With this I mean, if I would like
> to write a let's say yacasWrapper or octaveWrapper and
> ReplaceInlineYacas or ReplaceInlineOctave,  what would be
> a good way to test them outside ZWiki? 

I used to have a simple test harness that read in some test
page source from a file and called ReplaceInlineAxiom. That is
very simple but you have to comment-out any reference to the
Zope environment (one one case I think). If you like, I can
take a look for it and send you a copy.

But now that I have tried iPython interactive shell for Python
- motivated by the fact that Sage uses a customized version of
iPython for it's command line interpreter - I would say that
is definitely a better way to fly!

http://ipython.scipy.org/moin

> 2. In the Axiom projects I see a comment from you:
>
>   Extend the interface to Axiom to permit display of Axiom
>   graphics on MathAction Axiom graphics requires the X-windows
>   environment. This can be done on the server using the virtual
>   framebuffer driver Xfbdev and fbrun or gRun. When Axiom is run
>   to process commands from a wiki page the Axiom command, e.g.: 
>        viewport1 := draw(sin x, x=-%Pi..Pi)
>   needs to be able to communicate with the graphics processor in
>   the X-windows environment to create the graphic image. Additional
>   Axiom commands can write this to a postscript file and display it
>   on the web page. E.g.: 
>        write(viewport1, "graphic1.ps")
>        \begin{latex}
>        \psfig {graphic1.ps} ...
>        \end{latex}
>
> Is anybody working on this?

Not that I know of. Almost a year ago! I did try running Axiom
inside fbrun and it seemed to work as I described. This is one
of those projects that I was hoping to get to real-soon-now. :)

> Is any more information you could provide me?

Hmmm... Well as I recall I did get so far as installing X-windows
with Xfbdev on axiom-developer.org but its been too long since
I did anything with this so I don't recall much more about it.

http://en.wikipedia.org/wiki/Xvfb

\start
Date: 18 Aug 2006 23:54:05 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)

Bill Page writes:

| On August 18, 2006 4:05 PM Gaby wrote:
| > 
| > | On August 18, 2006 2:34 PM Camm wrote:
| > | > What should I do to work around to reproduce Bill's bug?
| > | > 
| > | 
| > Bill Page writes:
| > | apt-get install noweb ? :)
| > 
| > yes, that may solve his immediate issue.  However, while
| > I understand how his build is failing, I don't understand
| > how he got there. My builds are OK.  How are yours, except
| > the GCL issue?
| > 
| 
| I am not having any problems with the build process but I
| have not tried to build without having noweb pre-installed.

I did on different x86-based systems.

| I could do it later if you like.

if you have time, yes :-)

| Maybe someone else can report on their experience?

that would be definitely helpful.

I tried to set up a cron job to mail results to axiom-testresults but
at the moment, the build log is just too large for SF mailers to
handle :-(

\start
Date: Sat, 19 Aug 2006 01:11:09 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [Aldor-l] Using Aldor or SPAD

On 08/19/2006 12:23 AM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> [...]
> 
> | > It should be a mater of days or weeks to have a good front-end.
> | 
> | Oh, really? 
> 
> when you get a handful of motivated people, yes.

Maybe we should open up a Wiki and call for people on the FrontPage 
similar to the FreeAldor link.

> | Why then wait any longer? Maybe, because there is no 100%
> | clear definition of the language Aldor?
> 
> That is an important factor I guess. I.e. what do we want?  What kind
> of problems do we want to see solved by the language?

I believe that some research is involved here. I would definitely like 
to see better support in the language to state the input-output 
conditions in formal terms that could be used by a theorem prover.
If that just appears in the comments it is lost for checking program 
correctness.

> | > It would take momths to have decent optimizations in.
> | > but, that is definitely in our reach.
> | 
> | Does somebody volunteer to start such a project, preferably under GPL?
> 
> well, I'm already burried with Axiom and other projects; but I do
> definitely have an interest here.

Axiom is really big, may I ask on which part of Axiom do you want to 
concentrate?

In my eyes Aldor is/should become one of the most important pieces in 
Axiom. The mathematical knowledge that is hidden in all the SPAD 
domains, must be rewritten in Aldor and in a pamphlet style.

> | I don't want the Aldor **language** to split, because of different
> | compiler implementation, but staying in an uncertain future is just
> | bad for the Aldor language to reach the masses.

> it would not be good for anybody to have the community split; however,
> more than one implementations are beneficial for both the language and
> the community.

The availability of manpower is a big question mark for a second 
implementation of Aldor.

\start
Date: Fri, 18 Aug 2006 19:10:21 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: re: [Aldor-l] Using Aldor or SPAD

>From historical experience a new Aldor compiler would be a
3 year, 5 person project.

\start
Date: 19 Aug 2006 01:28:42 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: [Aldor-l] Using Aldor or SPAD

Tim Daly writes:

| >From historical experience a new Aldor compiler would be a
| 3 year, 5 person project.

but, such a new compiler would have to reinvent everything from
scratch.  A lot have been done in recent years in terms for dependent
types (Nurpl, epigram, etc.), functional languages implementations
techniques and optimizations (OCaml, Haskell, etc.).  Furthermore
it may attract more students.  

Of course, that is not said to underestimate the task; just to remind
that not everything has to be reinvented.

\start
Date: 19 Aug 2006 01:35:11 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [Aldor-l] Re:  Using Aldor or SPAD

Gabriel Dos Reis writes:

| Tim Daly writes:
| 
| | >From historical experience a new Aldor compiler would be a
| | 3 year, 5 person project.
| 
| but, such a new compiler would have to reinvent everything from
                                ^

ouch, there is a missing "NOT" here. Sorry for that.

\start
Date: Fri, 18 Aug 2006 17:12:46 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Anybody up for a few basic Aldor questions?

Well, it's Friday night and I decided to take a first look at doing
some Dimension related stuff in Aldor.  So I don't flounder uselessly
about, could someone guide me to the right things to read to answer the
following?

1)  For anyone who has slogged through the old draft of the units
paper, you know some of the problems with defining the ideas of basic
and derived dimensions.  I may be a little off course here, but this is
what I'm thinking:

a)  A basic dimension cannot be multiplied and remain a basic dimension
- the result is always a derived dimension.

b)  A derived dimension is always defined in terms of one or more basic
definitions and uses the multiplicative operator both in its definition
and its exported function.

So we have two types of dimension - the BasicDimension, and the
DerivedDimension.  The multiplication rules are:

basic * basic -> derived
basic * derived -> derived
derived * derived -> derived

However, derived / derived MIGHT yield a basic dimension, e.g.
Force*Acceleration/Length -> Mass.  Is there a way to conditionalize
the type of the output?  (BTY, the dimension 1 is always assumed part
of the set of basic dimensions).

I'm also looking at a bit of a problem with definitions.  If I do
something like this for BasicDimension (I suppose I'm writing this
wrong):

BasicDimension: Abelian with {
  "*": (%,%) -> DerivedDimension
}
== add {
	Rep = Record(name : String, definition : String, system : String)
}

DerivedDimension is undefined at this stage, because (presumably) part
of the representation of DerivedDimension is going to have to be
defined in terms of some kind of Abelian Polynomial of Basic
Dimensions.  Am I thinking about this incorrectly?

Unfortunately the difficulties don't stop there - some DerivedDimension
in the SI system have no definitive definition in terms of
BasicDimensions, so some DerivedDimensions will have to have parts of
their structure undefined.  I'm not quite sure how to do this - I'm
floundering around:

DerivedDimension: Abelian with{
  "*": (%,%) -> %
}
==add {
  D == BasicDimension Polynomial
        Rep = Record(name: String, definitiverepresentation : D,
reducedrepresentation : D)
  x * y  == if (x::Rep).definitiverepresentation = "" then
[(x::Rep).name::DerivedDimension * (y::Rep).definitiverepresentation]
else if (x::Rep).definitiverepresentation = "" then
[(x::Rep).definitiverepresentation * (y::Rep).name::DerivedDimension]
else [(x::Rep).definitiverepresentation *
(y::Rep).definitiverepresentation]
} 

Anyway.  Any advice appreciated.

\start
Date: Fri, 18 Aug 2006 17:27:39 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Re: Anybody up for a few basic Aldor questions?


> However, derived / derived MIGHT yield a basic dimension, e.g.
> Force*Acceleration/Length -> Mass.  Is there a way to conditionalize

I beg your pardon, that should be Force*Time*Time/Length -> Mass.  Been
a long day.

\start
Date: Sat, 19 Aug 2006 03:00:44 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Anybody up for a few basic Aldor questions?

Hi Cliff,

if I think about dimensions then that is a multiplicative structure. In 
fact, to me it looks like a commutative group where the free generators 
are the basic SI dimensions.

So an implementation would be

Dimension: with {
     *: (%, %) -> %;
     /: (%, %) -> %;
     kilogramm: %;
     meter: %;
     second: %;
     ...
} == add {
     Rep == Array Integer;
     import from Rep;
     -- Suppose we have n basic units then the array would ALWAYS be
     -- of length n. For simplicity I set n = 4;
     local new(): Rep == per new(4, 0); -- create array of size 4
     kilogram: % == {x := new(); x.1 := 1; per x}
     meter: %    == {x := new(); x.2 := 1; per x}
     second: %   == {x := new(); x.3 := 1; per x}
     (x: %) * (y: %): % == per [xx+yy for xx in rep x for yy in rep y];
     (x: %) / (y: %): % == per [xx-yy for xx in rep x for yy in rep y];
     ...
}

You can easily recognize if your dimension is a basic unit by just 
running through the array and testing whether there is exactly ONE 1.

Why would you want anything else? Can you give an explicit pointer to 
the text you have already written about units and dimensions?

If you like, you could change the representation to allow infinitely 
many basic dimensions (= infinitely many variables).

Your suggestion

 > BasicDimension: Abelian with {
 >   "*": (%,%) -> DerivedDimension
 > }
 > == add {
 >   Rep = Record(name : String, definition : String, system : String)
 > }

looks completely unnatural to me.

How would you ever define * explicitly?

To me it looks more like you define a box that contains name and 
definition of the dimension, but no multiplicative structure. Remove the 
* signature. That would appear in DerivedDimension anyway.

And if you want BasicDimension, just add an exponent entry to your 
representation

Rep = Record(exponent: Integer,
              name : String,
              definition : String,
              system : String)

and change my representation to

Rep == Array BasicDimension;

(And of course adapt the functions.)

On 08/19/2006 02:12 AM, C Y wrote:
> Well, it's Friday night and I decided to take a first look at doing
> some Dimension related stuff in Aldor.  So I don't flounder uselessly
> about, could someone guide me to the right things to read to answer the
> following?
> 
> 1)  For anyone who has slogged through the old draft of the units
> paper, you know some of the problems with defining the ideas of basic
> and derived dimensions.  I may be a little off course here, but this is
> what I'm thinking:
> 
> a)  A basic dimension cannot be multiplied and remain a basic dimension
> - the result is always a derived dimension.
> 
> b)  A derived dimension is always defined in terms of one or more basic
> definitions and uses the multiplicative operator both in its definition
> and its exported function.
> 
> So we have two types of dimension - the BasicDimension, and the
> DerivedDimension.  The multiplication rules are:
> 
> basic * basic -> derived
> basic * derived -> derived
> derived * derived -> derived
> 
> However, derived / derived MIGHT yield a basic dimension, e.g.
> Force*Acceleration/Length -> Mass.  Is there a way to conditionalize
> the type of the output?  (BTY, the dimension 1 is always assumed part
> of the set of basic dimensions).
> 
> I'm also looking at a bit of a problem with definitions.  If I do
> something like this for BasicDimension (I suppose I'm writing this
> wrong):
> 
> BasicDimension: Abelian with {
>   "*": (%,%) -> DerivedDimension
> }
> == add {
> 	Rep = Record(name : String, definition : String, system : String)
> }
> 
> DerivedDimension is undefined at this stage, because (presumably) part
> of the representation of DerivedDimension is going to have to be
> defined in terms of some kind of Abelian Polynomial of Basic
> Dimensions.  Am I thinking about this incorrectly?
> 
> Unfortunately the difficulties don't stop there - some DerivedDimension
> in the SI system have no definitive definition in terms of
> BasicDimensions, so some DerivedDimensions will have to have parts of
> their structure undefined.

Can you give an example.

> I'm not quite sure how to do this - I'm floundering around:
> 
> DerivedDimension: Abelian with{
>   "*": (%,%) -> %
> }
> ==add {
>   D == BasicDimension Polynomial
>         Rep = Record(name: String, definitiverepresentation : D,
> reducedrepresentation : D)
>   x * y  == if (x::Rep).definitiverepresentation = "" then
> [(x::Rep).name::DerivedDimension * (y::Rep).definitiverepresentation]
> else if (x::Rep).definitiverepresentation = "" then
> [(x::Rep).definitiverepresentation * (y::Rep).name::DerivedDimension]
> else [(x::Rep).definitiverepresentation *
> (y::Rep).definitiverepresentation]
> } 

Looking at your code, I find it unreadable. And if that is the case one 
should clearly think about another way of doing it.

And I cannot follow why you would like "Polynomial" to appear. Is there 
a dimension that looks like

   4*m^2 + 5*kg/s

???

> Anyway.  Any advice appreciated.
> 
> Thanks,
> CY

\start
Date: Fri, 18 Aug 2006 18:38:53 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Anybody up for a few basic Aldor questions?

> Hi Cliff,
> 
> if I think about dimensions then that is a multiplicative structure.

Right

> In fact, to me it looks like a commutative group where the free
> generators are the basic SI dimensions.

The SI system dimensions can be defined this way as a first
approximation.

> So an implementation would be
> 
> Dimension: with {
>      *: (%, %) -> %;
>      /: (%, %) -> %;
>      kilogramm: %;
>      meter: %;
>      second: %;
>      ...
> } == add {
>      Rep == Array Integer;
>      import from Rep;
>      -- Suppose we have n basic units then the array would ALWAYS be
>      -- of length n. For simplicity I set n = 4;
>      local new(): Rep == per new(4, 0); -- create array of size 4
>      kilogram: % == {x := new(); x.1 := 1; per x}
>      meter: %    == {x := new(); x.2 := 1; per x}
>      second: %   == {x := new(); x.3 := 1; per x}
>      (x: %) * (y: %): % == per [xx+yy for xx in rep x for yy in rep
> y];
>      (x: %) / (y: %): % == per [xx-yy for xx in rep x for yy in rep
> y];
>      ...
> }
> 
> You can easily recognize if your dimension is a basic unit by just 
> running through the array and testing whether there is exactly ONE 1.

The thing is, different systems may have different basic dimensions -
they are not universal.
 
> Why would you want anything else? Can you give an explicit pointer to
> the text you have already written about units and dimensions?

Yes - it is incomplete, but there is a pdf here: 
http://portal.axiom-developer.org/Members/starseeker/axiomunit_diagramtest.pdf/download

> If you like, you could change the representation to allow infinitely 
> many basic dimensions (= infinitely many variables).

Probably not necessary, but different systems will have different
numbers of basic dimensions.  I think SI actually has one of the
largest.
 
> Your suggestion
> 
>  > BasicDimension: Abelian with {
>  >   "*": (%,%) -> DerivedDimension
>  > }
>  > == add {
>  >   Rep = Record(name : String, definition : String, system :
> String)
>  > }
> 
> looks completely unnatural to me.

Not surprising.  This is also my first foray into Aldor coding, and I'm
not familiar enough with what's there in Axiom to know how to build
this :-(.  However, I see no remedy to that but to try.

> How would you ever define * explicitly?
> 
> To me it looks more like you define a box that contains name and 
> definition of the dimension, but no multiplicative structure. Remove
> the * signature. That would appear in DerivedDimension anyway.

OK.

> And if you want BasicDimension, just add an exponent entry to your 
> representation
> 
> Rep = Record(exponent: Integer,
>               name : String,
>               definition : String,
>               system : String)

Hmm - that might work.  I was stuck thinking that a dimension to a
power is a different physical property.  Is time^2 a derived dimension
since it isn't in the array of basic dimensions as time^2, but just
time?

> and change my representation to
> 
> Rep == Array BasicDimension;
> 
> (And of course adapt the functions.)

> > Unfortunately the difficulties don't stop there - some
> > DerivedDimension in the SI system have no definitive definition in
> > terms of BasicDimensions, so some DerivedDimensions will have to
> > have parts of their structure undefined.
> 
> Can you give an example.

It is discussed in the paper - the primary difficulty revolves around
derived dimensions incorporating radians.

> Looking at your code, I find it unreadable. And if that is the case
> one should clearly think about another way of doing it.

Heh - I'm looking for A way to do it.  That was just pseudocode at
best.

> And I cannot follow why you would like "Polynomial" to appear. Is
> there a dimension that looks like
> 
>    4*m^2 + 5*kg/s

Actually, there will be some cases with a derived dimension not being
simplifiable directly to basic dimensions where such expressions might
arise.  In a system with no definition issues for derived dimensions
the answer would be no, but unfortunately that's not the situation with
SI.  For example, the distinction between Work and Moment of Force
cannot be expressed in terms of basic SI dimensions.  So they cannot be
added to either each other or a basic dimensional expression containing
their "definition", because that definition is not unique.  It's
discussed more in the writeup.

\start
Date: Fri, 18 Aug 2006 22:42:22 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Axiom LatexWiki

Alfredo,

On August 18, 2006 3:38 PM you asked:

> Bill any idea what is this:
>
> vp1:=draw(sin(x), x=%pi/10..%pi)
>   >> System error: 
>  (SYSTEM "gcc -c -Wall -DVOL=volatile -fsigned-char -pipe
> -I/home/page/repository/axiom--main--1/mnt/linux/bin/../h -O3
> -fomit-frame-pointer -c \"/tmp/gazonk1.c\" -o \"/tmp/gazonk1.o\" -w")

> returned a non-zero value 0. 
>
> I get this error if I try to do:
>
> \begin{axiom}
> vp1:=draw(sin(x), x=%pi/10..%pi)
> \end{axiom}
>
> That is using the binaries files of Axiom from MathAction:
>
> )version 
> Value = "Wednesday June 21, 2006 at 03:45:56 "

I don't get that error on Axiom Developer. See:

http://wiki.axiom-developer.org/SandBoxAxiom#bottom

The "gazonk" files are temporary files created by the gcl lisp
compiler. I presume that the lisp compiler is being called to
compile the function 'sin(x)' prior to using it to generate the
data for the graph (which makes more sense of course if the
function to be plotted is more complex than in this example).

Anyway, the Axiom interpreter (all of Axiom for that matter) is
implemented in gcl and because this is lisp that means that it
*is* gcl plus the code that implements the interpreter. So Axiom/gcl
converts 'sin(x)' into a lisp function and then tries to compile
it into machine code. To do that it first generates C code
(gazonk1.c) and then calls gcc. The system error that you see
above is due to a failure of the C compile. I do not know the
cause but I think you might get this kind of error if no gcc
compiler is available. Or some other basic problem in your system.
But I would not expect any gcc compiler failure for lisp generated
from expressions as simple as 'sin(x)'.

This whole gazonk temporary file thing is not particularly well
done in the current version of gcl (especially in the case of
multi-user systems) because of possible race conditions while
generating unique temporary file names and there have been some
discussions on the gcl-devel list about replacing it with a linux
operating system standard method for tmp files.

\start
Date: Fri, 18 Aug 2006 23:22:36 -0400
From: Bill Page
To: list
Subject: Cannot create the file /tmp/gazonk0.fn

On August 18, 2006 10:42 PM I wrote:
> 
> On August 18, 2006 3:38 PM Alfredo asked:
> 
> > Bill any idea what is this: [in Axiom]
> >
> > vp1:=draw(sin(x), x=%pi/10..%pi)
> >   >> System error: 
> >  (SYSTEM "gcc -c -Wall -DVOL=volatile -fsigned-char -pipe
> > -I/home/page/repository/axiom--main--1/mnt/linux/bin/../h -O3
> > -fomit-frame-pointer -c \"/tmp/gazonk1.c\"
> > -o \"/tmp/gazonk1.o\" -w")
> > returned a non-zero value 0. 
> >
> > I get this error if I try to do:
> > vp1:=draw(sin(x), x=%pi/10..%pi)
> >
> 
> The "gazonk" files are temporary files created by the gcl lisp
> compiler. I presume that the lisp compiler is being called to
> compile the function 'sin(x)' prior to using it to generate the
> data for the graph (which makes more sense of course if the
> function to be plotted is more complex than in this example).
> ... 
> This whole gazonk temporary file thing is not particularly well
> done in the current version of gcl (especially in the case of
> multi-user systems) because of possible race conditions while
> generating unique temporary file names and there have been some
> discussions on the gcl-devel list about replacing it with a linux
> operating system standard method for tmp files.
> 

I have taken another look at this and I think there is indeed a
problem with gazonk files here. On the axiom-developer server when
I run the above commmand I do not get any problem. On the other
hand after the Axiom session is ended there is still a in /tmp
file named 'gazonk0.fn'

  # ls -l /tmp

-rw-r--r--    1 plone    plone         352 Aug 18 21:09 gazonk0.fn

I think this is the so called "proclaim" file for the compiled
function that contains information about the data types used in
the lisp function (but my understanding of gcl may be so good, so
don't count on these details). Anyway, I think this temporary file
should have been deleted by gcl.

I am using Axiom built from current sources in June 2006 with the
gcl-2.6.8pre source from that Axiom distribution.

Notice that it is owned by user plone and has some write limitations.

Later if I try this axiom command while logged in as a different
user I get the error message:

>> System error:
   Cannot create the file /tmp/gazonk0.fn.

And after that there are even more files left in /tmp

-bash-2.05b# ls -l /tmp
-rw-rw-r--    1 page     page       163098 Aug 18 21:52 gazonk0.c
-rw-rw-r--    1 page     page          100 Aug 18 21:52 gazonk0.data
-rw-r--r--    1 plone    plone         352 Aug 18 21:09 gazonk0.fn
-rw-rw-r--    1 page     page          232 Aug 18 21:52 gazonk0.h
-rw-rw-r--    1 page     page          112 Aug 18 21:52 gazonk0.lsp

If I remove the file '/tmp/gazonk0.fn' this error goes away.

BTW, because of this error we can actually see the lisp code that was
generated by the Axiom interpreter:

-bash-2.05b# cat /tmp/gazonk0.lsp

(lisp::defun boot::%a (boot::|x|)
  (lisp::declare (lisp::float boot::|x|))
  (boot::c-to-r (lisp::sin boot::|x|)))

------

The C code generated by gcl was a lot longer so I wont include it
here. :)

\start
Date: Fri, 18 Aug 2006 23:41:48 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer

Camm,

Thanks Camm! My test build just completed using the option

--disable-xgcl

On August 18, 2006 5:26 PM you wrote:
> 
> OK, this one is my fault, as I fogot we were still using EXTRAS
> in the makefile here.  2.6.8pre incorporates Gordon Novak's xgcl,
> and the way I build it was using compiler::link from within lisp
> as it was simpler.  This overrides EXTRAS at the very end, as it
> copies the compiler::link generated saved_xgcl over the saved_gcl
> left by unixport/makefile.
> 
> I'll probably have to revert this and do xgcl the old fashioned
> way.

I am not sure that it continues to make sense to support the old
"EXTRAS" method of linking external libraries. Does any gcl-based
software use this besides the "standard" Axiom distribution? Since
this method is not used of Axiom on Debian and on BSD, I think it
would make sense to move as soon as possible to using compiler::link
on all the other systems.

Is there any advantage to enabling xgcl in Axiom in any case? Would
it change Axiom's user interface? Have you tried this on the Debian
build where it does not have to be disabled?

> In the meantime, --disable-xgcl should work.  Please let me know
> if not. 
> 

It did. Thanks again.

Regards,
Bill Page.

Ref. http://www.mail-archive.com/gcl-devel@gnu.org/msg01074.html

\start
Date: Fri, 18 Aug 2006 23:58:24 -0400
From: Alfredo Portes
To: Bill Page
Subject: Axiom Session

In http://toolbox1.sytes.net/~alfredo/axiomui/

is any way to keep the Axiom session open in a server side script.

With this I mean, when I call axiom, I open a FILE stream and call
certain functions in Axiom and get the result like this:

In perl, I am doing something like this:

open (FILE, "| /usr/bin/AXIOMsys >/tmp/axiom");
print FILE ")set output tex on\n";
print FILE ")set output algebra off\n";
print FILE ")set message autoload off\n";
print FILE ")set message type off\n";
print FILE $question;

however after the script finishes, the session too. So if you input a
command after
it doesn't know about the previous calculation, like you can do inside Sage.

Is there a way to do this in python??? or any other language?

\start
Date: Sat, 19 Aug 2006 00:29:35 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: [Aldor-l] Re:  Using Aldor or SPAD

| Tim Daly writes:
| 
| | >From historical experience a new Aldor compiler would be a
| | 3 year, 5 person project.
| 
| but, such a new compiler would NOT have to reinvent everything from

of course, if it were written in lisp and assumed the axiom system
underneath it then it is a much less complex problem.

\start
Date: Sat, 19 Aug 2006 08:58:06 +0200
From: Christian Aistleitner
To: Ralf Hemmecke, Gabriel Dos Reis
Subject: Re: [Aldor-l] Using Aldor or SPAD

On Sat, 19 Aug 2006 01:11:09 +0200, Ralf Hemmecke wrote:

> On 08/19/2006 12:23 AM, Gabriel Dos Reis wrote:
>> Ralf Hemmecke writes:
>>
>> [...]
>>
>> | > It should be a mater of days or weeks to have a good front-end.
>> |
>> | Oh, really?
>>
>> when you get a handful of motivated people, yes.
>
> Maybe we should open up a Wiki and call for people on the FrontPage
> similar to the FreeAldor link.

Bear in mind, that you are trying to rewrite an existing product.
IANAL and I do not know French/British/Canadian law.
But I have been reading several traits of US law (which I have been told  
to be not too different from Canadian law).
According to my understanding of US law, someone who has seen Aldor source  
code cannot work on rewriting Aldor (without explicit permission by those  
who hold the rights of the Aldor source code).
I am not sure, to what extend the US law situation is reflected by  
Canadian, French or British law.
However, as (I guess) most of the ppl interested in Aldor, have seen the  
compiler's source code, they (probably) should not work on the  
reimplementation of it.

This is not some funny side remark of myself, but a real issue. Just think  
about the pain ReactOS is going through.

\start
Date: Sat, 19 Aug 2006 09:07:56 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Anybody up for a few basic Aldor questions?

I am just in the middle of

> http://portal.axiom-developer.org/Members/starseeker/axiomunit_diagramtest.pdf/download

Quite a nice introduction to that stuff so far. I appreciate it.

But I very much wonder, why you don't give proper references. A 
bibliography is completely missing. With all you literature review I 
would have expected that. Also the systems should be cited properly by 
giving links to their respective homepages.

That critisism is, however, not my main concern now.

In section 4.2.2 I read

[u1]<U>
------- = 1<1>
[u1]<U>

[u1]<U>   [u1]          1
------- = ----<1> = --------<U>^2
[u2]<U>   [u2]      f(u1,u2)

The latter <U>^2 must be a spelling error. If you really mean that, then 
I cannot follow anymore. Shouldn't it be <1>?

\start
Date: Sat, 19 Aug 2006 13:14:31 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Units and dimensions

Hi Cliff,

At the end of section 4.4.2 of
http://portal.axiom-developer.org/Members/starseeker/axiomunit_diagramtest.pdf/download
where you have discussed the problem of curvature, you say that the SI 
system is not a perfect one and that it is missing a dimension of 
<CircularCurvature>.

At the same time you say:

   Unfortunately, Axiom must work with systems as they exist and are used
   rather than than their ideal implementations, we must somehow allow
   the current fundamental disodance to exist in Axiom's SI definitions
   and function non the less.

I understand your wish, but to my taste that is a non-mathematical 
approach. As you have described, expressed in the SI base dimensions, 
<Work> and <Momentum of Force> are indistinguishable. So why would you 
want to implement an imperfect system? If there is nothing in SI that 
helps you to distinguish <Work> and <Momentum of Force> then you cannot 
express it. You are basically saying that the SI system is 
7-dimensional, but the world is 8-dimensional (or even 
higher-dimensional), but you want to describe your world with 7 
dimensions. That with fewer dimensions you don't see everything is 
clear---draw a 4-dimensional hypercube on a sheet of (two-dimensional) 
paper and try to figure out from the latter, what properties the 4-dim 
object has. Of course, impossible.

So if I were to implement dimensions and units, I would design a perfect 
system and allow the user to add dimensions and work with them. 
Depending on which system the user chooses, he/she can work with 
<CircularCurvature> or leave it out. Such an open system would even 
enable one to experiment whether <CircularCurvature> is the right concept.

In the SI-system plus <CircularCurvature> you could distinguish <Work> 
and <Momentum of Force> in the pure SI system you cannot.

All I want to say, forget about the nature and all those systems like SI 
and cgs or whatever. In Axiom you should build a system that is flexible 
enough to accomodate for any system you like. If, for example, you want 
to replace the "fundamental dimension" <Length> by <Force>, then that is 
possible mathematically and should be allowed by Axiom. <Length> is then 
simply a "derived dimension" that depends on the "fundamental 
dimensions" <Force>, <Time>, and <Mass>. Where would be the problem? As 
a mathematician I can choose any axioms (fundamental things) I like as 
long as they are non-contradicting. Maybe a physicist thinks differently 
here?

By the way, if I look at section 4.2.2, then that very much suggests 
that the *type* of a unit is a *dimension*.
To my taste, that suggests to implement 7 (or 8 or how many dimensions 
you like) dimension domains:

Length: Dimension == add {
   Rep == -- I don't yet know.
   meter: % == ...
   inch: % == ...
   ...
}

or you don't hardcode meter, inch etc., but make those units dynamic.
Similar domains for other dimensions.

I could even imagine something like

Length(u: Unit): Dimension == add {
    Rep == Unit;
    unit: Unit == ...
}

where out of the many units that are possible for lengths units, u would 
be the reference unit for this dimension. (So you could have the SI 
system and cgs system easily by using the Length constructor with a 
different unit.

I don't yet have a good idea for the domain Unit, though. :-(
Please don't take all this too serious, I am just thinking aloud.

Once you have these dimension domains, you could form an algebra with 
them, ehm, a abelian group, of course. No, no, there are still no 
coefficients. So with that "abelian group" you cannot express 3m or 6s. 
All you could do is to express, what you probably called "derived 
dimensions". So Length, Length*Time^(-1) etc. are examples for such 
monomials. As you see, each "fundamental dimension" is then also a 
"derived dimension", but no conversions would be possible, since you 
don't have coefficients.

Now, having the monomials, you can think about quantities (= units (as 
elements of dimensions) together with numbers).

I don't have a well developed idea of how I would implement what I am 
writing about here, but it reminds me a bit of what I am currently doing 
in aldor-combinat. There we define combinatorial species (which are 
endo-functors from the category of finite sets and isomorphisms to 
itself. They are implemented as domain constructors in Aldor, but as the 
theory goes, one can form a semi-ring where species would be the 
elements. This is in so far similar to what I was writing about above as 
I like dimensions to be domains. But later on you should be able to 
multiply together such domains.

Another remark concerns dimensional analysis... If in Axiom dimensions 
are implemented as types, couldn't then the dimensional analysis be done 
by the compiler? Types on the right and left hand side must match. What 
about thinking along these lines for implementing dimensions in Axiom?

Maybe some day I'll find time to code my ideas into Aldor which would 
then be open for criticism.

\start
Date: Sat, 19 Aug 2006 04:31:51 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Anybody up for a few basic Aldor questions?

> Hi Cliff,
> 
> I am just in the middle of
>
http://portal.axiom-developer.org/Members/starseeker/axiomunit_diagramtest.pdf/download
> 
> Quite a nice introduction to that stuff so far. I appreciate it.

Thanks.
 
> But I very much wonder, why you don't give proper references. A 
> bibliography is completely missing. With all you literature review I 
> would have expected that. Also the systems should be cited properly
> by giving links to their respective homepages.

Yes, I know.  I am working on a bibliography - that was why I did the
MSC2000 and PACS work earlier.  I wanted to have the "final" Axiom
system in place and integrate my bibliography properly with that.  As
you know we don't (yet) have a final solution to that, and I tried to
push towards something that could be a final solution before building
my final bibliography.  Unfortunately, in all that, I didn't get proper
references into the units paper yet.  As I said earlier it's
unfinished, and when it IS finished it will be properly cited.

> That critisism is, however, not my main concern now.
> 
> In section 4.2.2 I read
> 
> [u1]<U>
> ------- = 1<1>
> [u1]<U>
> 
> [u1]<U>   [u1]          1
> ------- = ----<1> = --------<U>^2
> [u2]<U>   [u2]      f(u1,u2)
> 
> The latter <U>^2 must be a spelling error. If you really mean that,
> then I cannot follow anymore. Shouldn't it be <1>?

Er, yes - that's a typo.  Thanks for spotting it!

\start
Date: Sat, 19 Aug 2006 05:33:34 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Units and dimensions

> Hi Cliff,
> 
> At the end of section 4.4.2 of
>
http://portal.axiom-developer.org/Members/starseeker/axiomunit_diagramtest.pdf/download
> where you have discussed the problem of curvature, you say that the
> SI system is not a perfect one and that it is missing a dimension of 
> <CircularCurvature>.

That's the best way I have been able to find to express the problem.

> At the same time you say:
> 
> Unfortunately, Axiom must work with systems as they exist and are
> used rather than than their ideal implementations, we must somehow
> allow the current fundamental disodance to exist in Axiom's SI
> definitions and function non the less.
> 
> I understand your wish, but to my taste that is a non-mathematical 
> approach. As you have described, expressed in the SI base dimensions,
> <Work> and <Momentum of Force> are indistinguishable. So why would
> you want to implement an imperfect system? If there is nothing in SI
> that helps you to distinguish <Work> and <Momentum of Force> then you
> cannot  express it. You are basically saying that the SI system is 
> 7-dimensional, but the world is 8-dimensional (or even 
> higher-dimensional), but you want to describe your world with 7 
> dimensions.

In principle, I agree with you.  The reason I want to work with the
"real" SI system as such is basically that the scientific community
seems to be very accustomed to radians having dimension 1, but treating
Work and Moment of Force as two different dimensions.  In my opinion
this is a flaw of the system, but I wanted to be very "correct" about
implimenting the actual true-to-life SI system in order to cultivate
the interest of the scientific community in Axiom.  Now to be fair I
think most other tools that deal with this type of issue HAVE
introduced angle as a dimension, so perhaps that isn't so outlandish a
solution after all.  I guess the nagging question in my mind is whether
I (who am not formally trained in this stuff beyond a BS in Physics)
should presume to second guess the SI committee.  Finding the other
papers discussing that helped.  Maybe the thing to do is use the NIST
publication as the basis of a literate document implementation of the
SI system on top of the eventual Unit/Dimension framework, and update
it there with some of this discussion.

> That with fewer dimensions you don't see everything is 
> clear---draw a 4-dimensional hypercube on a sheet of
> (two-dimensional) paper and try to figure out from the latter,
> what properties the 4-dim object has. Of course, impossible.

Yes.  My impression is that because radian is an accepted unit in SI,
it is convenient for people solving for things like length using these
quantities to multiply by the numerical constant and ignore the
curvature aspect of the problem - in the end this is usually safe
because the radian multiplicative factor takes care of things, and
there is a "de-facto" curvature dimensional correction at the same
time.  I guess most people don't worry about the SI dimensional set
without thinking about the units as well, which masks the problem.  Heh
- maybe we can petition the SI committee to fix this issue - I wonder
what the procedure is :-).

> So if I were to implement dimensions and units, I would design a
> perfect system and allow the user to add dimensions and work with
> them. 
> Depending on which system the user chooses, he/she can work with 
> <CircularCurvature> or leave it out. Such an open system would even 
> enable one to experiment whether <CircularCurvature> is the right
> concept.

In the framework I'm thinking about this would be done by defining a
custom System, using these steps:

1.  Define as BasicDimensions your desired BasicDimensions for the new
system (that's why the BasicDimension definition needs a system slot -
whether a dimension is Basic or not depends entirely on what system it
is being used in.)

2.  Define your named DerivedDimensions using the BasicDimensions,
again specifying the System.

3.  I don't know if the System needs to be explicitly defined or not -
probably.  But it will need existing Basic and named Derived dimensions
defined for it.
 
> In the SI-system plus <CircularCurvature> you could distinguish
> <Work> and <Momentum of Force> in the pure SI system you cannot.

Yes.

> All I want to say, forget about the nature and all those systems like
> SI and cgs or whatever. In Axiom you should build a system that is
> flexible enough to accomodate for any system you like.

Absolutely.  But in order to make sure it IS flexible enough, my
approach was to look at a use case and see what features and structure
are needed.  It get's a bit weird - for example, to handle some high
energy physics unit systems the only thing that is axiomatic are some
dimensionless constants!  I'm still not quite sure how to handle that
one.

> If, for example, you want to replace the "fundamental dimension"
> <Length> by <Force>, then that is possible mathematically and should
> be allowed by Axiom.

Absolutely, but then you are no longer working in the SI system.  To do
this (which I agree should be allowed) you need to create your own
system.  If you use the SI system, it will enforce SI as defined by the
NIST Special Publication, give or take the CircularCurvature issue.

> <Length> is then simply a "derived dimension" that depends on the
> "fundamental dimensions" <Force>, <Time>, and <Mass>. Where would be
> the problem?

There wouldn't be - I agree this should be doable.  Just not in the SI
system - that would be MyNewSystem or some such.

> As a mathematician I can choose any axioms (fundamental things) I
> like as long as they are non-contradicting. Maybe a physicist thinks
> differently here?

In principle, no.  In practice, the SI definitions will be used in
almost all situations, except in cases where units from other system
need to be converted to SI.  But Axiom should be able to handle any
legally possible combination of setups correctly.

> By the way, if I look at section 4.2.2, then that very much suggests 
> that the *type* of a unit is a *dimension*.
> To my taste, that suggests to implement 7 (or 8 or how many
> dimensions you like) dimension domains:
> 
> Length: Dimension == add {
>    Rep == -- I don't yet know.
>    meter: % == ...
>    inch: % == ...
>    ...
> }
> 
> or you don't hardcode meter, inch etc., but make those units dynamic.

Yes, that's what I was thinking.  Something kind of along the lines of:

Length: BasicDimension == add{
     Rep == Record{name : String, system : String}
}

Meter : Unit == add{
     Rep == Record{name : String, system : String, physdef : String,
                   dimension : Length, pivotunit : Unit}
     convert: %,% == something
     etc...
}
> Similar domains for other dimensions.

Right - each dimension gets defined once for each system.  So for each
large scale built in system, we would have a pamphlet which uses the
core structural pamphlet defining things like BasicDimension and Unit,
and the specifics (Length, Meter, etc.) would be in the system
pamphlets.  There will also need to be some kind of Conversion pamphlet
that Axiom uses to know how to go from cgs->SI - I'm not sure how to
handle that yet.  Planck -> SI is going to be interesting.

> I could even imagine something like
> 
> Length(u: Unit): Dimension == add {
>     Rep == Unit;
>     unit: Unit == ...
> }
> 
> where out of the many units that are possible for lengths units, u
> would be the reference unit for this dimension. (So you could have
> the SI system and cgs system easily by using the Length constructor
> with a different unit.

That's an interesting idea.  The thing is though, I can envision a case
where someone wants to define just a Dimensional system with no Unit
component defined, in order to do dimensional analysis (which does not
involve units.)  Maybe optionally specifying a unit?

> I don't yet have a good idea for the domain Unit, though. :-(
> Please don't take all this too serious, I am just thinking aloud.

On the contrary, this is excellent!  It's exactly the kind of thinking
needed and that I'm not nearly expert enough in Aldor to do yet.

I'm afraid I didn't pick an easy topic for a first topic in Axiom,
despite what I thought earlier - because these ideas are so fundamental
to all scientific computation it is crucial to get them right the first
time, and mapping them into Axiom's systems takes some serious
thinking.

> Once you have these dimension domains, you could form an algebra with
> them, ehm, a abelian group, of course. No, no, there are still no 
> coefficients. So with that "abelian group" you cannot express 3m or
> 6s. 
> All you could do is to express, what you probably called "derived 
> dimensions".

Right.

> So Length, Length*Time^(-1) etc. are examples for such 
> monomials.

That's where I get in trouble.  (Well, one of the places.)  Length IS
basic in the SI system, but Length/Time is a different dimension from
Length OR Time and is not basic.  It's COMPOSED of basic dimensions,
but that could be said of every derived dimension in a complete system.
 

> As you see, each "fundamental dimension" is then also a 
> "derived dimension", but no conversions would be possible, since you 
> don't have coefficients.

I don't quite follow.  Length and Time are basic all right, but
Length/Time is a single derived dimension.  That's why I was originally
trying to say that if you multiply two basic dimensions (or take one to
a power, or divide - ANY such operation) the result is not a basic
dimension but a derived dimension.  However, Length/Time^2 * Time^2 is
composed of two derived dimensions - Length/Time^2 and Time^2 - but
will simplify to a basic dimension.  I was thinking some kind of
conditional definition of type output for those operators - if the
resulting dimensional expression is in the basic dimensions list for
the system, return type BasicDimension, else the result is a
DerivedDimension.  I'm sure I wrote crazy pseudocode trying to express
that, but I don't really see a way around it.  Derived Dimension almost
needs a generic Dimension type which can be either a BasicDimension or
a DerivedDimension, since either can be used to define a
DerivedDimension.  DerivedDimension is a bit recursive - a
DerivedDimension can be defined using DerivedDimensions.

> Now, having the monomials, you can think about quantities (= units
> (as elements of dimensions) together with numbers).

Makes sense. 

> I don't have a well developed idea of how I would implement what I am
> writing about here, but it reminds me a bit of what I am currently
> doing in aldor-combinat. There we define combinatorial species (which
> are  endo-functors from the category of finite sets and isomorphisms
> to itself. They are implemented as domain constructors in Aldor, but 
> as the theory goes, one can form a semi-ring where species would be
> the elements. This is in so far similar to what I was writing about
> above as I like dimensions to be domains. But later on you should be
> able to multiply together such domains.

Right.  Dimensional analysis would require that ability, as does
defining derived dimensions.

> Another remark concerns dimensional analysis... If in Axiom
> dimensions are implemented as types, couldn't then the dimensional
> analysis be done by the compiler? Types on the right and left hand 
> side must match. What about thinking along these lines for
> implementing dimensions in Axiom?

Yes, that is an interesting way to go - it would mean that equations
defined using dimensions could be checked as dimensionally correct
before they are ever used (that's one of the ideas I REALLY like about
a dimensional system in Axiom - any equation properly defined using the
units and dimensions system could be guaranteed to be dimensionally
correct.  Not a guarantee that the formula is correct of course, but it
would catch certain types of conceptual errors.)  I was hoping to get
this more or less for free from Axiom's domain/type systems - does it
require extra work?

> Maybe some day I'll find time to code my ideas into Aldor which would
> then be open for criticism.

That would be great!  I'm trying to think about this in order to make
the units paper something more than just an idea exposition (i.e. make
it a real pamphlet) but as Tim says there is no such thing as a simple
job.  This is compounded by being somewhat different from "typical"
mathematical programming in Axiom.

\start
Date: 19 Aug 2006 14:56:47 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: re: Units and dimensions

Cliff Yapp writes:

> --- Ralf Hemmecke wrote:

> > Once you have these dimension domains, you could form an algebra with them,
> > ehm, a abelian group, of course. No, no, there are still no
> > coefficients. So with that "abelian group" you cannot express 3m or 6s.
> > All you could do is to express, what you probably called "derived
> > dimensions".
> 
> Right.
> 
> > So Length, Length*Time^(-1) etc. are examples for such 
> > monomials.
> 
> That's where I get in trouble.  (Well, one of the places.)  Length IS
> basic in the SI system, but Length/Time is a different dimension from
> Length OR Time and is not basic.  It's COMPOSED of basic dimensions,
> but that could be said of every derived dimension in a complete system.

I think what Ralf meant is that the *derived* dimensions form a group, not the
basic dimensions.

> However, Length/Time^2 * Time^2 is composed of two derived dimensions -
> Length/Time^2 and Time^2 - but will simplify to a basic dimension.  I was
> thinking some kind of conditional definition of type output for those
> operators - if the resulting dimensional expression is in the basic
> dimensions list for the system, return type BasicDimension, else the result
> is a DerivedDimension.

No, the concept here is called "retract". You'd have an operation

retractIfCan: DerivedDimension -> Union("failed", BasicDimension)

(I know, Ralf, that you hate that return type, but so far we don't have
Partial...)

just as an operation

coerce: BasicDimension -> DerivedDimension

In Axiom there are categories for these operations, by the way.

\start
Date: 19 Aug 2006 15:51:14 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Camm Maguire, Robert Boyer

Bill Page writes:

| Camm,
| 
| Thanks Camm! My test build just completed using the option
| 
| --disable-xgcl

Yay!

[...]

| > In the meantime, --disable-xgcl should work.  Please let me know
| > if not. 
| > 
| 
| It did. Thanks again.

OK; so let's me summarize a candidate patch for axiom.silver or
axiom.build-improvements:

   * apparently, GCL 2.6.8pre from CVS has more improvements;
   * if we grab that, we must patch Axiom with patches suggested by 
     Camm.  Camm, could you give me a list of those?
   * We must, for the moment, configure GCL with --disable-xgcl.

Is that correct?

\start
Date: 19 Aug 2006 15:54:06 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [Aldor-l] Re:  Using Aldor or SPAD

Tim Daly writes:

| | Tim Daly writes:
| | 
| | | >From historical experience a new Aldor compiler would be a
| | | 3 year, 5 person project.
| | 
| | but, such a new compiler would NOT have to reinvent everything from
| 
| of course, if it were written in lisp and assumed the axiom system
| underneath it then it is a much less complex problem.

It would be difficult for me to find good and motivated students
sufficiently fluent in Lisp :-)  But, I get your point.  If, we have a
new compiler, it would be engineered so that it solves problems
encountered by Axiom uses and improve the way people think of or write
Axiom libraries.

\start
Date: 19 Aug 2006 15:58:13 +0200
From: Gabriel Dos Reis
To: Christian Aistleitner
Subject: Re: [Aldor-l] Using Aldor or SPAD

Christian Aistleitner writes:

| Hello,
| 
| On Sat, 19 Aug 2006 01:11:09 +0200, Ralf Hemmecke wrote:
| 
| > On 08/19/2006 12:23 AM, Gabriel Dos Reis wrote:
| >> Ralf Hemmecke writes:
| >>
| >> [...]
| >>
| >> | > It should be a mater of days or weeks to have a good front-end.
| >> |
| >> | Oh, really?
| >>
| >> when you get a handful of motivated people, yes.
| >
| > Maybe we should open up a Wiki and call for people on the FrontPage
| > similar to the FreeAldor link.
| 
| Bear in mind, that you are trying to rewrite an existing product.
| IANAL and I do not know French/British/Canadian law.
| But I have been reading several traits of US law (which I have been
| told  to be not too different from Canadian law).
| According to my understanding of US law, someone who has seen Aldor
| source  code cannot work on rewriting Aldor (without explicit
| permission by those  who hold the rights of the Aldor source code).

I never touched/saw Aldor compiler source code.  

I'm not trying to rewrite the existing compiler.  I'm only interested
in a new compiler for the *Aldor language*.  If the *Aldor language*
is defined to be the behaviour of its *current compiler*, then we are
all in trouble. 

| I am not sure, to what extend the US law situation is reflected by
| Canadian, French or British law.
| However, as (I guess) most of the ppl interested in Aldor, have seen
| the  compiler's source code, they (probably) should not work on the
| reimplementation of it.

That is a very good point.  Does that also imply that you cannot
answer any technical question about the *Aldor language*?

| This is not some funny side remark of myself, but a real issue. Just
| think  about the pain ReactOS is going through.

:-)

\start
Date: Sat, 19 Aug 2006 17:49:54 +0200
From: Gregory Vanuxem
To: list
Subject: Typo in src/algebra/attreg.spad.pamphlet

Hello,

--- attreg.spad.pamphlet.old    2006-08-19 17:00:41.000000000 +0200
+++ attreg.spad.pamphlet        2006-08-19 17:01:06.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.

\start
Date: Sat, 19 Aug 2006 18:47:04 +0200
From: Gregory Vanuxem
To: list
Subject: reproducibility of a segmentation fault when the compiler encounters a macro (with $lisp) badly indented


--=-r0PeBCsaZTY2UpqZ5ATP

Hello,

Is this bug reproducible ?

If someone can try to compile, in a fresh new axiom session, the
attached file. I get a segmentation fault.

Greg

--=-r0PeBCsaZTY2UpqZ5ATP

)abbrev domain MYIARR MyIndexedOneDimensionalArray
MyIndexedOneDimensionalArray(S:Type, mn:Integer):_
                 Exports == Implementation where
   Qsetelt ==> SETELT$Lisp
   Qnew ==> GETREFV$Lisp

  Exports == OneDimensionalArrayAggregate S with

    myProperty

  Implementation == add

   minIndex x       == mn


--=-r0PeBCsaZTY2UpqZ5ATP--

\start
Date: 19 Aug 2006 18:59:55 +0200
From: Martin Rubey
To: Gregory Vanuxem
Subject: Re: reproducibility of a segmentation fault when the compiler encounters a macro (with $lisp) badly indented

Gregory Vanuxem writes:

> Hello,
>
> Is this bug reproducible ?

Yes it is. However, I think that the macro definitions should all be indent=
ed
by the same amount. I.e., try

)abbrev domain MYIARR MyIndexedOneDimensionalArray
MyIndexedOneDimensionalArray(S:Type, mn:Integer):_
                 Exports == Implementation where
  Qsetelt ==> SETELT$Lisp
  Qnew ==> GETREFV$Lisp

  Exports == OneDimensionalArrayAggregate S with


> If someone can try to compile, in a fresh new axiom session, the
> attached file. I get a segmentation fault.
>
> Greg
>
> )abbrev domain MYIARR MyIndexedOneDimensionalArray
> MyIndexedOneDimensionalArray(S:Type, mn:Integer):_
>                  Exports == Implementation where
>    Qsetelt ==> SETELT$Lisp
>    Qnew ==> GETREFV$Lisp
>
>   Exports == OneDimensionalArrayAggregate S with
>
>     myProperty
>
>   Implementation == add
>
>    minIndex x       == mn

\start
Date: Sat, 19 Aug 2006 19:08:56 +0200
From: Gregory Vanuxem
To: Martin Rubey
Subject: Re: reproducibility of a segmentation fault when the compiler encounters a macro (with $lisp) badly indented

Le samedi 19 ao=FBt 2006 =E0 18:59 +0200, Martin Rubey a =E9crit :
> Vanuxem Gr=E9gory Gregory Vanuxem writes:
>
> > Hello,
> >
> > Is this bug reproducible ?
>
> Yes it is.

Thank you very much.

> However, I think that the macro definitions should all be indented
> by the same amount.

Exactly, I think I will report this bug (segmentation fault).

\start
Date: Sat, 19 Aug 2006 19:14:48 +0200
From: Ralf Hemmecke
To: Gregory Vanuxem
Subject: Re: reproducibility of a segmentation fault when the compiler encounters a macro (with $lisp) badly indented

Reproducible, with my compilation of axiom--main-1 on debian sarge.

But have you tried the slightly modified file (see attachment).
I simply have removed the Q... macros. ;-)

Anyway that is a very good example why pile syntax is terrible.

Ralf

--------------020708060303080000000209
 name="rhxtest.spad"
 filename="rhxtest.spad"

)abbrev domain MYIARR MyIndexedOneDimensionalArray
MyIndexedOneDimensionalArray(S:Type, mn:Integer):_
                 Exports == Implementation where
  Exports == OneDimensionalArrayAggregate S with
    myProperty

  Implementation == add
   minIndex x       == mn


\start
Date: Sat, 19 Aug 2006 19:34:01 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Units and dimensions

>>> So Length, Length*Time^(-1) etc. are examples for such 
>>> monomials.
>> That's where I get in trouble.  (Well, one of the places.)  Length IS
>> basic in the SI system, but Length/Time is a different dimension from
>> Length OR Time and is not basic.  It's COMPOSED of basic dimensions,
>> but that could be said of every derived dimension in a complete system.
> 
> I think what Ralf meant is that the *derived* dimensions form a group, not the
> basic dimensions.

Right, and as such they must form a domain where all the group 
operations are implemented. Informally, one can think of that domain (of 
"derived dimension") as a container that has as its elements 
powerproducts (negative powers allowed) of BasicDimensions.

I somehow have a slight feeling that the trouble comes when the design 
should be such that the compiler is doing the dimension analysis. For 
that we have to think a bit whether it is possible at all.

>> However, Length/Time^2 * Time^2 is composed of two derived dimensions -
>> Length/Time^2 and Time^2 - but will simplify to a basic dimension.  I was
>> thinking some kind of conditional definition of type output for those
>> operators - if the resulting dimensional expression is in the basic
>> dimensions list for the system, return type BasicDimension, else the result
>> is a DerivedDimension.
> 
> No, the concept here is called "retract". You'd have an operation

> retractIfCan: DerivedDimension -> Union("failed", BasicDimension)

Sorry, but I really don't quite understand, why one would need such a 
retract at all. But maybe I'll learn more while implementing something 
and getting feedback.

> (I know, Ralf, that you hate that return type, but so far we don't have
> Partial...)

Martin, you are right. ;-)

\start
Date: Sat, 19 Aug 2006 13:34:52 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Camm Maguire, Robert Boyer

On August 19, 2006 9:51 AM Gaby wrote:
> ... 
> OK; so let's me summarize a candidate patch for axiom.silver or
> axiom.build-improvements:
> 
>    * apparently, GCL 2.6.8pre from CVS has more improvements;
>    * if we grab that, we must patch Axiom with patches suggested
>      by Camm.  Camm, could you give me a list of those?
>    * We must, for the moment, configure GCL with --disable-xgcl.
> 
> Is that correct?
> 

Yes, that is correct. Do you have all the pieces?

\start
Date: Sat, 19 Aug 2006 11:01:57 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke, Martin Rubey
Subject: re: Units and dimensions

Thanks all for taking the time to think about this.  If we are going to
go ahead and use CircularCurvature as a basic dimension, (e.g. insist
on a complete system definition before implementing it in Axiom) then
that (greatly) simplifies the needed structure for dimensional
definitions.  I'm going to proceed to update the text part of the paper
and clean out a lot of the workaround discussions, and I'll also try
and get a units bibliography going (we can always update it later to
meet final conventions, I suppose - sigh.)  I'll upload it to the
portal once I've got something reasonable.

\start
Date: Sat, 19 Aug 2006 14:01:50 -0400
From: Bill Page
To: Ralf Hemmecke, Gregory Vanuxem
Subject: RE: reproducibility of a segmentation fault when the compiler encounters a macro (with $lisp) badly indented

>
> > If someone can try to compile, in a fresh new axiom session,
> > the attached file. I get a segmentation fault.
> >
> > )abbrev domain MYIARR MyIndexedOneDimensionalArray
> > MyIndexedOneDimensionalArray(S:Type, mn:Integer):_
> >                  Exports == Implementation where
> >    Qsetelt ==> SETELT$Lisp
> >    Qnew ==> GETREFV$Lisp
> >
> >   Exports == OneDimensionalArrayAggregate S with
> >
> ...

On August 19, 2006 1:00 PM Martin Rubey

> Yes it is. However, I think that the macro definitions should
> all be indented by the same amount. I.e., try
>
> )abbrev domain MYIARR MyIndexedOneDimensionalArray
> MyIndexedOneDimensionalArray(S:Type, mn:Integer):_
>                  Exports == Implementation where
>   Qsetelt ==> SETELT$Lisp
>   Qnew ==> GETREFV$Lisp
>
>   Exports == OneDimensionalArrayAggregate S with
> ...

On August 19, 2006 1:15 PM Ralf Hemmecke wrote:
>
> ...
> Anyway that is a very good example why pile syntax is
> terrible.
>

Ralf, I am sorry but your comment makes be rather angry. :(
I cannot understand why an otherwise very intelligent
programmer would blame the language for how a compiler
handles a syntax error. Arrrgh!

(: Of course I mean this a the spirit of friendly criticism... :)

In my opinion the notation without the {}; decoration is still
superior even when the compiler writers get it wrong. There are
several other instances when SPAD does not consistently implement
the language.

If you compile this in #pile mode in Aldor you get the expected
result.

http://wiki.axiom-developer.org/SandBoxPileNotation

\start
Date: 19 Aug 2006 20:22:38 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Camm Maguire, Robert Boyer

Bill Page writes:

| On August 19, 2006 9:51 AM Gaby wrote:
| > ... 
| > OK; so let's me summarize a candidate patch for axiom.silver or
| > axiom.build-improvements:
| > 
| >    * apparently, GCL 2.6.8pre from CVS has more improvements;
| >    * if we grab that, we must patch Axiom with patches suggested
| >      by Camm.  Camm, could you give me a list of those?
| >    * We must, for the moment, configure GCL with --disable-xgcl.
| > 
| > Is that correct?
| > 
| 
| Yes, that is correct. Do you have all the pieces?

if you could give me a collection of pointers to them that would be
appreciated. 

\start
Date: Sat, 19 Aug 2006 22:35:55 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: #pile vs. non-#pile

>>> )abbrev domain MYIARR MyIndexedOneDimensionalArray
>>> MyIndexedOneDimensionalArray(S:Type, mn:Integer):_
>>>                  Exports == Implementation where
>>>    Qsetelt ==> SETELT$Lisp
>>>    Qnew ==> GETREFV$Lisp
>>>
>>>   Exports == OneDimensionalArrayAggregate S with

> On August 19, 2006 1:15 PM Ralf Hemmecke wrote:
>> ... 
>> Anyway that is a very good example why pile syntax is
>> terrible.

> Ralf, I am sorry but your comment makes be rather angry. :(

I hope you have some mercy with me. But I cannot believe that you find 
that code easily readable.

Is it so obvious for the untrained eye that the indentation of the line 
after the _ is irrelevant? (Actually, I don't know this rule by heart.)
What if the line "Exports == Implementation where" were a bit longer so 
that you have to break it again with _? How much would you indent this 
third line then?

I agree that in some cases #pile mode might look nice, but I turned away 
from it long ago (because of code like the above).

Sorry that I posted my personal opinion. Important for me is that code 
should be easily readable (whether pile or not) and for that we should 
introduce some style conventions. (I have mine for non-pile mode more or 
less encoded in aldor-mode.el. But if more people start programming in 
Aldor I'll probably start a Wikipage about style conventions.)

\start
Date: Sat, 19 Aug 2006 18:42:27 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: #pile vs. non-#pile

> >> Anyway that is a very good example why pile syntax is
> >> terrible.
> 
> > Ralf, I am sorry but your comment makes be rather angry. :(
> 
> I hope you have some mercy with me. But I cannot believe that you find 
> that code easily readable.

Sorry for re-opening this debate again but....

Having lived with Spad code for years I consider pile syntax to be
the biggest mistake the language designers made so I clearly come
down on Ralf's side of the game.

Even the trivial case of sending code in email that has proportional
font makes the code unreadable. Moving a function from one place to
another within a file can cause mistakes. I had the task of making
many global changes to the algebra code. I could not write an emacs
macro to walk across the files because the insertions were sensitive
to spaces.

Modifications to files in a single line can cause semantic errors
many, many lines away. And adding a line requires that you take
the global syntax of the file into account.

Spaces cannot be counted visually and lead to THE most common
SEMANTIC mistake made in Spad. Fortran made the same mistake
but at least the punched cards had explicit column numbers. Once
the design error was explored with Fortran it should have been
forever banned. I've never forgiven Make for the tab character mistake.
If we are going to count spaces we might as well add line numbers.

What possible advantage can piles claim?

\start
Date: Sat, 19 Aug 2006 16:04:13 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: IRC meeting?

Since the Axiom developers are in such remote geographic locations, I
was wondering if there was/is any interest in having an online meeting
in the axiom IRC channel.  I have seen this done occasionally for other
projects and it would be less expensive for those of us who can't
attend the odd in-person meeting.

The trick, of course, is to get a time which works for everyone, but
presumably some something could be worked out.  Is that of any
interest/potential use?

\start
Date: Sat, 19 Aug 2006 19:37:30 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: IRC meeting?

I suppose we could work out a scheduled time for "group meetings".
I'm usually online all day and late into the night but a scheduled
time would make it reasonable. I have not been monitoring the IRC
channel because the beta version of Gaim cannot handle the IRC helper
plugin. I just downgraded my version of Gaim and now it works.

\start
Date: Sat, 19 Aug 2006 21:06:30 -0400
From: Tim Daly
To: list
Subject: line-breaking

CY, Kai, and I discussed line-breaking on the IRC channel
and the point was raised that line-breaking involves breaking
the equation into chunks that mean something to the viewer.

the axiom way to handle this would be the same method we use
during simplification. in simplification we format
  POLYNOMIAL(FRACTION(INT))
different from
  FRACTION(POLYNOMIAL(INT))

so perhaps we need output routines that format
  SUM(PRODUCT(X,Y))
different from
  PRODUCT(SUM(X,Y))

and other format domains. each would do line-breaking in
different places using different rules.

\start
Date: 20 Aug 2006 05:09:00 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: reproducibility of a segmentation fault when the compiler encounters a macro (with $lisp) badly indented

[...]

| On August 19, 2006 1:15 PM Ralf Hemmecke wrote:
| > 
| > ... 
| > Anyway that is a very good example why pile syntax is
| > terrible.
| > 
| 
| Ralf, I am sorry but your comment makes be rather angry. :(
| I cannot understand why an otherwise very intelligent
| programmer would blame the language for how a compiler
| handles a syntax error. Arrrgh!

Well, I find the pile stuff a terrible language feature.
But, I suspect we have been through that before...

\start
Date: Sun, 20 Aug 2006 00:38:45 -0400
From: Bill Page
To: Tim Daly, Ralf Hemmecke
Subject: RE: #pile vs. non-#pile

On August 19, 2006 6:42 PM Tim Daly wrote:
>
> > > Ralf wrote:
> > >> Anyway that is a very good example why pile syntax is
> > >> terrible.
> > Bill Page wrote:
> > > Ralf, I am sorry but your comment makes me rather angry. :(
> > Ralf replied:
> > I hope you have some mercy with me. But I cannot believe
> > that you find that code easily readable.
>
> Sorry for re-opening this debate again but....
>
> What possible advantage can piles claim?
>

Hmmm... 20,000 Python programmers? ;)

http://www.tiobe.com/tpci.htm

(Actually it seems no one really knows how many people program
in any given language but the statistics do show some languages
becoming more popular and others declining.) My point is that a
large number of programmers do use Python and the number is
increasing.

Contrary to my philosophy on a number of other issues, I do
believe that there are very significant advantages in numbers
in open source programming. After all, what is the limiting
resource in almost every open source project? People.

One of my *first* reactions on learning to program in SPAD was
"Hey, this looks a lot like Python!"

http://lists.nongnu.org/archive/html/axiom-developer/2004-10/msg00109.htm=
l

So quite contrary to the opinion Tim Daly stated in a much earlier
email, I do not believe that Python (and it's programming style)
does not seem likely to disappear any time soon. And more over,
now we find the newest and fastest growing open source computer
algebra project ever - Sage - was largely motivated by and
incorporates Python in it's basic machinery both internally and
at the user interface level (iPython).

----------

But it's an old debate alright. Using indentation to represent
(not just document) program structure was in fact proposed by
Donald Knuth and several others 46 years ago!

http://jeremyhylton.blogspot.com/2006/06/using-indentation-to-represent-p=
rog
ram.html

http://en.wikipedia.org/wiki/Off-side_rule

http://foldoc.org/foldoc/foldoc.cgi?off-side+rule

The popularity of Python re-ignited this debate.

Myths about Indentation
http://www.secnetix.de/~olli/Python/block_indentation.hawk

But there are some well known languages other than Python use
indentation for program structure (notably: Haskell).

http://home.tiac.net/~cri/2001/indentation.html

http://www.cs.man.ac.uk/~pjj/cs2112/langdes/indent.html

In my opinion SPAD and Aldor #pile syntax was not a mistake -
it was just implementing yet another important idea in
programming language design, way before it's time.

\start
Date: 20 Aug 2006 06:57:19 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: #pile vs. non-#pile

Bill Page writes:

| On August 19, 2006 6:42 PM Tim Daly wrote:
| >
| > > > Ralf wrote:
| > > >> Anyway that is a very good example why pile syntax is
| > > >> terrible.
| > > Bill Page wrote:
| > > > Ralf, I am sorry but your comment makes me rather angry. :(
| > > Ralf replied:
| > > I hope you have some mercy with me. But I cannot believe 
| > > that you find that code easily readable.
| > 
| > Sorry for re-opening this debate again but....
| >
| > What possible advantage can piles claim?
| > 
| 
| Hmmm... 20,000 Python programmers? ;)

That is hardly a conclusive argument.

[...]

| But it's an old debate alright. Using indentation to represent
| (not just document) program structure was in fact proposed by
| Donald Knuth and several others 46 years ago!

well, given TeX's syntax, I would not claim his language syntax design
choices are always very spectacular, compared to his strength at other
computer science matters :-/

[...]

| But there are some well known languages other than Python use
| indentation for program structure (notably: Haskell).

yes, and I hate it.  Two months ago I wasted whole day chasing a
bug in one of my Haskell programs, only to discover that it was an
identation issue in an instance declaration.  That bug happened after
reformating a correct, working, program.  It is a misfeature.

\start
Date: Sat, 19 Aug 2006 22:53:58 -0700
From: Ed Borasky
To: Cliff Yapp
Subject: Re: IRC meeting?

C Y wrote:
> Since the Axiom developers are in such remote geographic locations, I
> was wondering if there was/is any interest in having an online meeting
> in the axiom IRC channel.  I have seen this done occasionally for other
> projects and it would be less expensive for those of us who can't
> attend the odd in-person meeting.
> 
> The trick, of course, is to get a time which works for everyone, but
> presumably some something could be worked out.  Is that of any
> interest/potential use?
Well, I'm not a developer, but I like IRC meetings. The best deal on
time zones is probably something early morning Saturday Pacific (US)
time. This gives the folks who work full time a chance to get some rest,
and just about everyone else is in some part of the weekend.

\start
Date: Sat, 19 Aug 2006 22:55:41 -0700
From: Ed Borasky
To: Tim Daly
Subject: Re: IRC meeting?

root wrote:
> I suppose we could work out a scheduled time for "group meetings".
> I'm usually online all day and late into the night but a scheduled
> time would make it reasonable. I have not been monitoring the IRC
> channel because the beta version of Gaim cannot handle the IRC helper
> plugin. I just downgraded my version of Gaim and now it works.

I'm not a big fan of Gaim for IRC -- either XChat or KVIrc has a much
better interface. XChat is a good bit lighter in weight, if that matters.

\start
Date: Sun, 20 Aug 2006 09:23:48 +0200
From: Christian Aistleitner
To: Gabriel Dos Reis
Subject: Re: [Aldor-l] Using Aldor or SPAD

Hello,

> | I am not sure, to what extend the US law situation is reflected by
> | Canadian, French or British law.
> | However, as (I guess) most of the ppl interested in Aldor, have seen
> | the  compiler's source code, they (probably) should not work on the
> | reimplementation of it.
>
> That is a very good point.  Does that also imply that you cannot
> answer any technical question about the *Aldor language*?

I assume the "you" does not refer to me, but someone having seen the  
compiler sources.
The term "technical question" is rather vague to me in this context.
Up to my knowledge, people having seen the compiler sources may do only  
one thing (in the US): Write specifications.

\start
Date: 20 Aug 2006 15:00:06 +0200
From: Gabriel Dos Reis
To: Christian Aistleitner
Subject: Re: [Aldor-l] Using Aldor or SPAD

Christian Aistleitner writes:

| Hello,
| 
| > | I am not sure, to what extend the US law situation is reflected by
| > | Canadian, French or British law.
| > | However, as (I guess) most of the ppl interested in Aldor, have seen
| > | the  compiler's source code, they (probably) should not work on the
| > | reimplementation of it.
| >
| > That is a very good point.  Does that also imply that you cannot
| > answer any technical question about the *Aldor language*?
| 
| I assume the "you" does not refer to me, but someone having seen the
| compiler sources.

well, I meant you (Christian).

| The term "technical question" is rather vague to me in this context.
| Up to my knowledge, people having seen the compiler sources may do
| only  one thing (in the US): Write specifications.

:-)

\start
Date: Sun, 20 Aug 2006 11:29:14 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Unit paper now has references

I've added most of the references used so far to the Unit paper and put
up a new version here: 
http://portal.axiom-developer.org/Members/starseeker/axiomunit-current.pdf/download

Haven't had time to rework the dimension and unit definitions section
yet.

Just for some more fun, this is using the eprint.sty system to add some
hyperlinks to the bibliography (when available.)

\start
Date: Sun, 20 Aug 2006 15:52:15 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: #pile vs. non-#pile

On August 20, 2006 12:57 AM you wrote:
> ...
> | Tim Daly wrote:
> | > What possible advantage can piles claim?
> | > 
> Bill Page wrote:
> | Hmmm... 20,000 Python programmers? ;)
> 
> That is hardly a conclusive argument.
> 

Agreed. I do not know of any conclusive argument one way or the
other. All I wish to point out is that the statements made by you,
Tim, and Ralf about #pile syntax is based only on personal bias
and not on fact.

My reference to 20,000 programmers was in relationship to my
desire that programming in Axiom should be made to seem appealing
to the "next generation". I think associating Axiom (and Aldor in
#pile mode) with Python and Haskell via the (admittedly somewhat
superficial) resemblance of their syntax might be one small PR
step in that direction.

> [...]
> 
> | But it's an old debate alright. Using indentation to represent
> | (not just document) program structure was in fact proposed by
> | Donald Knuth and several others 46 years ago!
> 
> well, given TeX's syntax, I would not claim his language syntax
> design choices are always very spectacular, compared to his
> strength at other computer science matters :-/

I think your argument is not strengthened when you choose to argue
with spectacular success. If Knuth had invented MathML in the 1970's
instead of TeX do you think he would be so widely known today? ;)

> 
> [...]
> 
> | But there are some well known languages other than Python use
> | indentation for program structure (notably: Haskell).
> 
> yes, and I hate it.  Two months ago I wasted whole day chasing
> a bug in one of my Haskell programs, only to discover that it
> was an indentation issue in an instance declaration.  That bug
> happened after reformatting a correct, working, program. It is
> a misfeature.
> 

Get serious! Your experience is at best only anecdotal. Programmers
have collectively sent many days chasing bugs due to misplaced ;
and logic errors hidden by meaninglessly indented code. I don't know
what you mean by "reformatting a correct, working program" but if
your "reformatting" involved changing indentation, then how is that
different from randomly moving { } symbols to other parts of your
program? I think your problem with Haskell stems for simple lack
of experience in programming in that language.

I would be very interested if you could point to any instance in
the SPAD coding in the Axiom library of a logic error due to
incorrect indentation. I am not saying that it is not possible,
but simply that I find it unlikely.

\start
Date: 20 Aug 2006 21:54:32 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: [Aldor-l] implementing aldor / new species	approach

Tim Daly writes:

> Ring is implemented as a lisp object. You can put these into a list.

(2) -> l : List Ring := [Integer]
 
   Cannot convert an element of the construct to type Any .
(2) -> l : Ring := Integer
 
   Ring is a category, not a domain, and declarations require domains.

Martin

PS: PLEASE (!!!!) copy to aldor-combinat only stuff specific to the
combinat project!

\start
Date: 20 Aug 2006 22:31:49 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: #pile vs. non-#pile

Bill Page writes:

[...]

| > | But it's an old debate alright. Using indentation to represent
| > | (not just document) program structure was in fact proposed by
| > | Donald Knuth and several others 46 years ago!
| > 
| > well, given TeX's syntax, I would not claim his language syntax
| > design choices are always very spectacular, compared to his
| > strength at other computer science matters :-/
| 
| I think your argument is not strengthened when you choose to argue
| with spectacular success. If Knuth had invented MathML in the 1970's
| instead of TeX do you think he would be so widely known today? ;)

Yes.

| > [...]
| > 
| > | But there are some well known languages other than Python use
| > | indentation for program structure (notably: Haskell).
| > 
| > yes, and I hate it.  Two months ago I wasted whole day chasing
| > a bug in one of my Haskell programs, only to discover that it
| > was an indentation issue in an instance declaration.  That bug
| > happened after reformatting a correct, working, program. It is
| > a misfeature.
| > 
| 
| Get serious! Your experience is at best only anecdotal.

When discussing _language syntax_, what else can you expect except
personal experience?  Call it anectotal if you like, but syntax is a
primary tool to express ideas.  It should not get in the way.

| Programmers have collectively sent many days chasing bugs due to misplaced ;

and you probably heard of the cancer of semicolon.

| and logic errors hidden by meaninglessly indented code. 

a factual difference between semicolon and space is that I can count
semilcolon.  I can't count what I can't see.

| I don't know what you mean by "reformatting a correct, working
| program" but if your "reformatting" involved changing indentation,

yes.

| then how is that different from randomly moving { } symbols to other
| parts of your program?

I can count them.

| I think your problem with Haskell stems for simple lack
| of experience in programming in that language.

Sure, my name is not Simon Peyton Jones; but I don't think you have
enough data to back up your assertion :-)

| I would be very interested if you could point to any instance in
| the SPAD coding in the Axiom library of a logic error due to
| incorrect indentation.

That is a meaningless request.  Ask Tim what he thinks about the pile
syntax; he knows the Axiom library and worked on it. 

I'm just glad Adlor provided a better alternative.

\start
Date: Sun, 20 Aug 2006 22:55:14 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: #pile vs. non-#pile

On 08/20/2006 09:52 PM, Bill Page wrote:
> All I wish to point out is that the statements made by you,
> Tim, and Ralf about #pile syntax is based only on personal bias
> and not on fact.

I am sorry for having started all that.

> My reference to 20,000 programmers was in relationship to my
> desire that programming in Axiom should be made to seem appealing
> to the "next generation". I think associating Axiom (and Aldor in
> #pile mode) with Python and Haskell via the (admittedly somewhat
> superficial) resemblance of their syntax might be one small PR
> step in that direction.

If Bill can attract more people to help with Axiom, I wouldn't care 
whether they come because of #pile or other reasons.

More important than #pile or not is that we get more developers.
Let Aldor/Axiom develop and see what people like most.

Perhaps some day there appears a "beautifier" program that translates 
between pile and non-pile, so you/we could read the code in the way 
you/we like.

Don't waste time arguing about "blanks".

\start
Date: 20 Aug 2006 23:13:20 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: #pile vs. non-#pile

Ralf Hemmecke writes:

[...]

| Don't waste time arguing about "blanks".

:-)

This line is intentionally left blank.

\start
Date: Sun, 20 Aug 2006 17:58:19 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: #pile vs. non-#pile

On August 20, 2006 4:32 PM Gaby wrote:
> ...
> When discussing _language syntax_, what else can you expect
> except personal experience?

I believe there is a **lot** more to syntax than just personal
experience. (Of course you know that...) There are some very
good formal tools for describing the syntax natural languages
which carry over well to programming languages. The basic point
is to be able to deduce structure from some serialization, i.e.
from a 1-dimensional linear representation of that structure. But
these formal languages tools do have some limitations. Although
serialization certainly has wide application, humans and computers
are not limited to communicating in this manner. How often have
you heard: "A picture is worth a thousand words."?

Mathematicians have understand the importance of this concept
for some time. This is certainly clear in graph theory and I
would claim that it is evident in the wide spread use of commutative
diagrams in category theory.

The point of using indentation to representation program structure
actually has less to do with syntax and more to do with the
expressiveness of the language. You are probably not arguing that
indentation has no purpose in programming languages but rather that
it should be limited to illustrating program structure for human
readability and not for compiler construction. But I would argue
the other way. I think we need to do more to aid the communication
between human and computer and that encoding program structure by
indentation is only one small step in that direction. There are,
for example some rather well developed programming languages which
make use of a graphical input to define programs - so called
"visual programming".

http://en.wikipedia.org/wiki/Visual_programming_language

BTW, There are some statistics (probably not very reliable) which
suggest that Python is one of the most "expressive" widely used
programming languages ever invented:

http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Expressi=
ven
ess

I think it would be very interesting to consider the Axiom library
from the point of view of these "statement ratio" measures. It seems
to me that SPAD would probably rate even higher on this scale.

> Call it anecdotal if you like, but syntax is a primary tool to
> express ideas.  It should not get in the way.

I did not call syntax anecdotal. To say it another way: I think your
personal experience with using indentation in Haskell is not a
reliable guide on which to base judgements about syntax.

> ...
> | I would be very interested if you could point to any instance in
> | the SPAD coding in the Axiom library of a logic error due to
> | incorrect indentation.
>
> That is a meaningless request.

Why is it meaningless? I thought you were arguing that #pile notation
might lead to a larger number of logic errors than in those programs
that use the {]; decorations.

> Ask Tim what he thinks about the pile syntax; he knows the Axiom
> library and worked on it.
>

Tim is not the only person (or even the main person) who worked
on the Axiom library.

> I'm just glad Adlor provided a better alternative.
>

As far as I know, Aldor processes both #pile and non-pile inputs in
the same way. The use of #pile mode just increases the expressiveness
of the language a little.

\start
Date: Sun, 20 Aug 2006 15:47:17 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Gabriel Dos Reis
Subject: RE: #pile vs. non-#pile

I think Ralf called it - the way to do this is have some kind of
pretty-printer that can convert between the two.  They are, after all,
at some level functionally the same.  The difference is just in how we
(the human programmers) are viewing the logic.

Eventually, we should have a button on editors that can switch code
between pile and no-pile with one push.  Then everybody's happy.

I suppose that's a project in itself though.

\start
Date: 21 Aug 2006 00:54:30 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: #pile vs. non-#pile

Cliff Yapp writes:

> I think Ralf called it - the way to do this is have some kind of
> pretty-printer that can convert between the two.  They are, after all,
> at some level functionally the same.  The difference is just in how we
> (the human programmers) are viewing the logic.
> 
> Eventually, we should have a button on editors that can switch code
> between pile and no-pile with one push.  Then everybody's happy.
> 
> I suppose that's a project in itself though.

Note that a (rudimentary) converter from pile to nopile is included in the
axiom compiler. just say

(1) -> )co test.spad )tr
   Compiling AXIOM source code from file test.spad using old system 
      compiler.
   Warning: translation of an old-style source code ".spad" file to a 
      new-style ".as" file changes the old system compiler. If you wish
      to use the old system compiler for regular compilation, you must 
      exit and re-enter AXIOM.
   Creating output file with name test.as .
#include "axiom.as"
   Compiling AXIOM source code from file test.spad using old system 
      compiler.
   TEST abbreviates package Test 
   compiling exported tst : Integer -> Integer
--)abbrev package TEST Test
No documentation for tst
No documentation for tst

+++ 
Test(): with tst: Integer -> Integer;  == {
        add {
                import from PositiveInteger; 
                import from SingleInteger; 
                import from String; 
                import from OutputForm; 
                import from NoValueMode; 
                tst(n:Integer):Integer == {
                    for (free i) in 1..n repeat {
                        i = 2 => 0; 
                        output(i::OutputForm)$OutputPackage; 
                    }
                    0; 
                }
                
        }
}

Note that it makes many mistakes, but that's probably fixable.

\start
Date: Sun, 20 Aug 2006 23:22:09 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Another question

Alfredo

On August 18, 2006 4:59 PM you asked:

> Probably this has come out many times in previous discussions.
> Given the latex output from Axiom, what would be the best way
> to display it on a webpage. 
>
> Complete as latex document -> latex -> dvipng??? 

By "complete" do you mean the output of an entire Axiom session?
Using just dvipng would result in one png file for each page of
the latex document. Certainly it is possible to present the output
of LaTeX in this format but treating everything as an image has
severe limitations in a web browser.

To render a LaTeX document, I think you would be better off using
latex to HTML tool like TeX4ht

http://www.cse.ohio-state.edu/~gurari/TeX4ht/mn.html

instead of just dvipng. TeX4ht will generate HTML with embedded
graphics or with MathML. Many people consider MathML the best
available format for web browsers. I agree that it probably will
be "real-soon-now".

> or how is it done on MathAction?

In MathAction (actually in ZWiki/LatexWiki) a wiki page is
composed of HTML with embedded png images only to represent the
mathematical formula. In the current version of MathAction the
png files are generated by ghostscript but Bob McElrath did have
an experimental version of LatexWiki that used dvipng. As I
recall there were some subtle issues regarding defining the image
baseline for proper inline placement of LaTeX-generated symbols.

This is very much like what TeX4ht does except that the source
format of the page is not LaTeX but rather StructuredText and/or
HTML with embedded LaTeX and Axiom commands.

As I mentioned earlier, an alternative to embedded graphics and
MathML is jsMath which uses Javascript to emulate the LaTeX math
typesetting functions directly on the web browser. Because this
is a complex process that runs in Javascript, it is quite a bit
slower than rendering HTML with embedded graphics. The AxiomUI
project made use of jsMath.

As you know, pamphlet files on MathAction are treated a little
differently with only a "thumbnail" displayed on the web page
containing links to the pdf and dvi format generated by LaTeX.
Originally we had planned to use TeX4ht to produce a web page
(or set of web pages) from the pamphlet source but there turned
out to be some technical limitations. It is quite possible with
some additional effort these problems could be solved. If you are
interested about this possibility, please ask.

\start
Date: Mon, 21 Aug 2006 01:27:59 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Axiom Session

On August 18, 2006 11:58 PM Alfredo Portes wrote:

> In http://toolbox1.sytes.net/~alfredo/axiomui/
>
> is any way to keep the Axiom session open in a server side
> script.
>
> With this I mean, when I call axiom, I open a FILE stream and
> call certain functions in Axiom and get the result like this:
>
> In perl, I am doing something like this:
>
> open (FILE, "| /usr/bin/AXIOMsys >/tmp/axiom");
> print FILE ")set output tex on\n";
> print FILE ")set output algebra off\n";
> print FILE ")set message autoload off\n";
> print FILE ")set message type off\n";
> print FILE $question;
>
> however after the script finishes, the session too. So if you
> input a command after it doesn't know about the previous
> calculation, like you can do inside Sage.

The main problem here I think is that you seem to be trying to do
this using a simple cgi script in Apache?

Normally the Apache web server processes cgi requests in a stateless
manner, i.e. it starts a process, collects output and stops the
process on each request and doesn't remember anything from one call
to the next. To do something more sophisticated you will have to use
a different technique on the server side that permits a processes to
persist. See for example:

http://en.wikipedia.org/wiki/Mod_perl
http://en.wikipedia.org/wiki/Mod_python

Another possibility is instead of using Apache, you could use a web
application server such as Zope or even PHP. Zope for example would
allow you to write methods in Python that communicate with an external
process and return results via xmlhttp.

> Is there a way to do this in python??? or any other language?

Yes, certainly. Besides established a web application server
environment the 2nd problem you have to solve is the communication
between Mod_perl/Mod_python/Zope and Axiom. To do this, I think your
best option here is to use a package such as pexpect

http://pexpect.sourceforge.net

(in python). There is something similar for perl

http://sourceforge.net/projects/expectperl
http://sourceforge.net/docman/display_doc.php?docid=9977&group_id=689=
4#descr
iption

but I haven't used it.

Pexpect starts some external process and uses the pseudo terminal (pty)
interface to send and receive commands and output to and from it.

For example Sage uses a version of pexpect to communicate with Maxima.

In the near future I intend to convert MathAction to using pexpect
instead of pipes (similar to what you describe above) because there
are problems with pipes as soon as you try to call processes that
communicate with other processes such as the way in which 'sman'
starts 'AXIOMsys' and a separate Axiom graphics process. The pty
interface solves this sort of problem because it interacts with
the processes at the level of the virtual serial pty device.

\start
Date: Mon, 21 Aug 2006 09:40:14 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [Axiom-mail] Category parameters and "this" domain

Why is this a mail to axiom-mail instead of axiom-developer?

On 08/21/2006 01:22 AM, Gabriel Dos Reis wrote:
> 
> Hi,
> 
>    The SPAD compiler accepts and happily compiles this:
> 
>    )abbrev category FOO Foo
> 
>    ++ A Foo is something we can foo with.
>    Foo(m : ($, $) ->$) : Category == SetCategory with
>      ++ A Foo has a foo
>      foo : ($, $) -> $ 
> 
> Is it a feature or a bug?  [Similar Aldor code is rejected]

Nobody can say whether bug or feature, because there is no strict 
definition of the SPAD language.

\start
Date: 21 Aug 2006 09:57:26 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [Axiom-mail] Category parameters and "this" domain

Ralf Hemmecke writes:

| Why is this a mail to axiom-mail instead of axiom-developer?

because it is about use of Axiom.  I'm wearing my Axiom user hat here.

| On 08/21/2006 01:22 AM, Gabriel Dos Reis wrote:
| > Hi,
| >    The SPAD compiler accepts and happily compiles this:
| >    )abbrev category FOO Foo
| >    ++ A Foo is something we can foo with.
| >    Foo(m : ($, $) ->$) : Category == SetCategory with
| >      ++ A Foo has a foo
| >      foo : ($, $) -> $ Is it a feature or a bug?  [Similar Aldor
| > code is rejected]
| 
| Nobody can say whether bug or feature, because there is no strict
| definition of the SPAD language.

still, we have an Axiom library written in something...

I'll appreciate an explanation of whether it is supposed to have any
at all.

\start
Date: 21 Aug 2006 10:00:56 +0200
From: Martin Rubey
To: Bill Page
Subject: re: Another question

Bill Page writes:

> As you know, pamphlet files on MathAction are treated a little differently
> with only a "thumbnail" displayed on the web page containing links to the pdf
> and dvi format generated by LaTeX.  Originally we had planned to use TeX4ht
> to produce a web page (or set of web pages) from the pamphlet source but
> there turned out to be some technical limitations. It is quite possible with
> some additional effort these problems could be solved. If you are interested
> about this possibility, please ask.

Please note that Ralf's ALLPROSE does this already, also using tex4ht. In fact,
I think it's high time to switch to ALLPROSE. As far as I know, the only bit
missing is to make it talk to axiom instead of aldor, but that shouldn't be too
difficult, Ralf?

\start
Date: 21 Aug 2006 10:34:14 +0200
From: Gabriel Dos Reis
To: list
Subject: [mainline] PATCH to op.spad.pamphlet: fix typo in comment


*** src/algebra/ChangeLog	(revision 15555)
--- src/algebra/ChangeLog	(local)
***************
*** 1,3 ****
--- 1,7 ----
+ 2006-08-21  Gabriel Dos Reis  Gabriel Dos Reis
+ 
+ 	* op.spad.pamphlet: Fix typo in comment.
+ 
  2006-07-31  Ralf Hemmecke  Ralf Hemmecke
  
  	* transsolve.spad.pamphlet: Escape "#".
*** src/algebra/op.spad.pamphlet	(revision 15555)
--- src/algebra/op.spad.pamphlet	(local)
*************** BasicOperator(): Exports == Implementati
*** 108,114 ****
        ++ Argument op is modified "in place", i.e. no copy is made.
  
    Implementation ==> add
!     -- if narg < 0 then the operator ahs variable arity.
      Rep := Record(opname:Symbol, narg:SingleInteger, props:P)
  
      oper: (Symbol, SingleInteger, P) -> $
--- 108,114 ----
        ++ Argument op is modified "in place", i.e. no copy is made.
  
    Implementation ==> add
!     -- if narg < 0 then the operator has variable arity.
      Rep := Record(opname:Symbol, narg:SingleInteger, props:P)
  
      oper: (Symbol, SingleInteger, P) -> $


\start
Date: 21 Aug 2006 10:41:46 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: repetition of \subsection{Layer21} in src/algebra/Makefile.pamphlet

Tim Daly writes:

| > There are two subsections "Layer 21" in the file
| > src/algebra/Makefile.pamphlet. The line 1054 can be removed.
|
| fixed. available in the next release --t

*** ChangeLog	(revision 15577)
--- ChangeLog	(local)
***************
*** 1,3 ****
--- 1,7 ----
+ 2006-08-21  Vanuxem Gr=E9gory  Gregory Vanuxem
+
+ 	* Makefile.pamphlet (\subsection{Layer21}): Remove duplicate.
+
  2006-08-21  Gabriel Dos Reis  Gabriel Dos Reis

  	* op.spad.pamphlet: Fix typo in comment.
*** Makefile.pamphlet	(revision 15577)
--- Makefile.pamphlet	(local)
*************** sttf.spad.pamphlet (STTF)
*** 1051,1057 ****
  transsolve.spad.pamphlet (SOLVETRA)
  zerodim.spad.pamphlet (RGCHAIN ZDSOLVE)
  \end{verbatim}
- \subsection{Layer21}
  <<layer22>>=

  LAYER22=\
--- 1051,1056 ----


\start
Date: Mon, 21 Aug 2006 10:43:54 -0400
From: Bill Page
To: Martin Rubey
Subject: re: Another question

Martin,

On August 21, 2006 4:01 AM you wrote:
> 
> Bill Page writes:
> > As you know, pamphlet files on MathAction are treated a 
> > little differently with only a "thumbnail" displayed on
> > the web page containing links to the pdf and dvi format
> > generated by LaTeX.  Originally we had planned to use
> > TeX4ht to produce a web page (or set of web pages) from
> > the pamphlet source but there turned out to be some
> > technical limitations. It is quite possible with some
> > additional effort these problems could be solved. If 
> > you are interested about this possibility, please ask.
> 
> Please note that Ralf's ALLPROSE does this already, also 
> using tex4ht.

I am sorry Martin, but I don't understand. ALLPROSE does what
already? The problem referred to above is related to generating
HTML from Axiom pamphlet source that can be used on the Axiom
Wiki. Does Ralf have a version of ALLPROSE that can do that?
If so, could you add some example pages to wiki?

> In fact, I think it's high time to switch to ALLPROSE. As
> far as I know, the only bit missing is to make it talk to
> axiom instead of aldor, but that shouldn't be too difficult,
> Ralf?
> 

:) I have read the ALLPROSE documentation but it is not at
all clear to me how this could be done. Perhaps you can
elaborate on this idea? I think that in a open source project
saying "that it shouldn't be too difficult" can only be
interpreted as a "taunt" (i.e. trying to force someone to do
something) or a promise to actually do something yourself. :)

\start
Date: Mon, 21 Aug 2006 12:36:11 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Another question

Bill,

On 8/20/06, Bill Page wrote:

>
> By "complete" do you mean the output of an entire Axiom session?
> Using just dvipng would result in one png file for each page of
> the latex document. Certainly it is possible to present the output
> of LaTeX in this format but treating everything as an image has
> severe limitations in a web browser.
>
> To render a LaTeX document, I think you would be better off using
> latex to HTML tool like TeX4ht
>
> http://www.cse.ohio-state.edu/~gurari/TeX4ht/mn.html
>
> instead of just dvipng. TeX4ht will generate HTML with embedded
> graphics or with MathML. Many people consider MathML the best
> available format for web browsers. I agree that it probably will
> be "real-soon-now".


   I have installed tex4ht. For a single image to display, which is my
   current test case, dvipng is much faster. However, probably for a
   complete latex document to later be rendered as html probably
   TeX4ht should be better (maybe for the pamphlets).

As I mentioned earlier, an alternative to embedded graphics and
> MathML is jsMath which uses Javascript to emulate the LaTeX math
> typesetting functions directly on the web browser. Because this
> is a complex process that runs in Javascript, it is quite a bit
> slower than rendering HTML with embedded graphics. The AxiomUI
> project made use of jsMath.


    I see two projects listed in:
http://wiki.axiom-developer.org/SummerOfCode
    to get Axiom to output jsMath and MathML. Are these still needed?

As you know, pamphlet files on MathAction are treated a little
> differently with only a "thumbnail" displayed on the web page
> containing links to the pdf and dvi format generated by LaTeX.
> Originally we had planned to use TeX4ht to produce a web page
> (or set of web pages) from the pamphlet source but there turned
> out to be some technical limitations. It is quite possible with
> some additional effort these problems could be solved. If you are
> interested about this possibility, please ask.


    The first time I used the pamphlet inside MathAction I was expecting to
have
    the whole pamphlet rendered as html. But displaying the "thumbnail" is
okay
    because you have the options to see the dvi or pdf.

    What I think is missing is have things like commands and graphics be
displayed
    also when save pamphlet. One way by using the method you already have
in:

    http://wiki.axiom-developer.org/SandBoxSagePamphlet

    or displaying in html pages. Whatever option you consider is more
convenient. I
    would be glad to work on achieving this.

\start
Date: 21 Aug 2006 19:07:46 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: Using ALLPROSE for SPAD programming

Bill Page writes:

> I am sorry Martin, but I don't understand. ALLPROSE does what already? The
> problem referred to above is related to generating HTML from Axiom pamphlet
> source that can be used on the Axiom Wiki. Does Ralf have a version of
> ALLPROSE that can do that?  If so, could you add some example pages to wiki?

ALLPROSE produces HTML from a format very similar to pamphlet.
 

> I wrote:

> > In fact, I think it's high time to switch to ALLPROSE. As far as I know,
> > the only bit missing is to make it talk to axiom instead of aldor, but that
> > shouldn't be too difficult, Ralf?
 
> :) I have read the ALLPROSE documentation but it is not at all clear to me
> how this could be done. Perhaps you can elaborate on this idea? I think that
> in a open source project saying "that it shouldn't be too difficult" can only
> be interpreted as a "taunt" (i.e. trying to force someone to do something) or
> a promise to actually do something yourself. :)

Sorry, I didn't mean to force anybody. What I did intend was encouragement. In
fact, that's why I wrote ", Ralf?" instead of "!". I don't really know how
difficult it is. Thus, I tried. 

Result: Generating documentation doesn't seem to be very difficult at all. The
main obstacle is, that ALLPROSE expects a semicolon to end a definition. Thus,
I cheated and wrote:


<<exports: testSPAD>>=
      double: R -> R --;
@

It seems that ALLPROSE also expects that the signature appears on one line,
Ralf? At least

<<exports: testSPAD>>=
      double: R -> _
                   R --;
@

did not work.

The main principle obstacle however is pile syntax (sorry Bill). It does not
mix well with neither .pamphlet_s nor .nw_s:

Continuing with

<<exports: testSPAD>>=
       triple: R -> R --;
@

Will produce an error, of course. But I guess, we have to live with that
problem anyway.

For compiling, we would have to change the extension .as to .spad and change
calls to aldor to axiom. This is beyond my knowledge of allprose though.

\start
Date: Mon, 21 Aug 2006 14:58:27 -0400
From: Tim Daly
To: Camm Maguire
Subject: latest GCL problem

Camm,

I've been trying to build Axiom with the latest gcl-2.6.8pre checkout.

It fails when trying to compile the file in 
  src/interp/sockio.lisp.pamphlet

specifically it fails with:

========================================================================
118 making /tmp/axiom49/int/interp/sockio.lisp from /tmp/axiom49/src/interp/sockio.lisp.pamphlet
117 making /tmp/axiom49/obj/linux/interp/sockio.o from /tmp/axiom49/int/interp/sockio.lisp

>
Compiling /tmp/axiom49/int/interp/sockio.lisp.
End of Pass 1.  
End of Pass 2.  
/tmp/axiom49/obj/linux/interp/sockio.c:5139: conflicting types for `sock_get_float'
/tmp/axiom49/obj/linux/interp/sockio.h:46: previous declaration of `sock_get_float'

Error: (SYSTEM "gcc -c -I/usr/X11R6/include -Wall -DVOL=volatile -fsigned-char -pipe  -I/tmp/axiom49/lsp/gcl-2.6.8pre2/unixport/../h  -O3 -fomit-frame-pointer -c \"/tmp/axiom49/obj/linux/interp/sockio.c\" -o \"/tmp/axiom49/obj/linux/interp/sockio.o\" -w") returned a non-zero value 0.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by UNLESS.
Broken at APPLY.  Type :H for Help.
BOOT>>make[3]: *** [/tmp/axiom49/obj/linux/interp/sockio.o] Error 255
make[3]: Leaving directory `/tmp/axiom49/src/interp'
make[2]: *** [interpdir] Error 2
make[2]: Leaving directory `/tmp/axiom49/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/tmp/axiom49'
make: *** [all] Error 2
========================================================================


which is generated from the lines:

========================================================================
#+KCL
(progn
  (clines "extern double plus_infinity(), minus_infinity(), NANQ();")
  (clines "extern double sock_get_float();")
  (defentry open_server (string) (int "open_server"))
  (defentry sock_get_int (int) (int "sock_get_int"))
  (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_send_float (int float) (int "sock_send_float"))
  (defentry sock_send_wakeup (int int) (int "sock_send_wakeup"))
  (defentry server_switch () (int "server_switch"))
  (defentry flush_stdout () (int "flush_stdout"))
  (defentry sock_send_signal (int int) (int "sock_send_signal"))
  (defentry print_line (string) (int "print_line"))
  (defentry plus_infinity () (double "plus_infinity"))
  (defentry minus_infinity () (double "minus_infinity"))
  (defentry NANQ () (double "NANQ"))
  )

========================================================================

which generated the C code that looks like


========================================================================


.....[snip]....

extern double sock_get_float();

.....[snip]....

/*	function definition for SOCK_GET_FLOAT	*/

static void L6()
{	object *old_base=vs_base;
	float x;
	x=
	sock_get_float(
	object_to_int(vs_base[0]));
	vs_top=(vs_base=old_base)+1;
	vs_base[0]=make_shortfloat(x);
}


========================================================================

This code used to compile. Any guesses?

\start
Date: 21 Aug 2006 22:13:13 +0200
From: Martin Rubey
To: Igor Khavkine
Subject: Re: [Axiom-math] Curious behavior of Taylor series

Dear Igor,

great that you found the reason. Do you think you'd have the time to document
properly just the function powern? What you found is not the first bug in these
10 lines of code :-(

If you do have time, you should also look at the corresponding code for SUPXS
(very likely in ISUPS which is in sups.spad.pamphlet), since the bug does not
occur in that domain. (By the way, neither did the other one I fixed ages ago).

The operation is called cRationalPower(uts,r) there.

If you don't, please say so.

\start
Date: Mon, 21 Aug 2006 17:59:09 -0400
From: Bill Page
To: Tim Daly
Subject: RE: latest GCL problem
Cc: Camm Maguire

Tim,

You seem to be missing Camm's patches. See attached email sent
to you by Camm on Tuesday, August 15, 2006 6:19 PM.

Regards,
Bill Page.

On Monday, August 21, 2006 2:58 PM you wrote:
>
> I've been trying to build Axiom with the latest gcl-2.6.8pre checkout.
>
> It fails when trying to compile the file in
>   src/interp/sockio.lisp.pamphlet
>
> specifically it fails with:
>
> =
==========================
==========================
============
> ==========
> 118 making /tmp/axiom49/int/interp/sockio.lisp from
> /tmp/axiom49/src/interp/sockio.lisp.pamphlet
> 117 making /tmp/axiom49/obj/linux/interp/sockio.o from
> /tmp/axiom49/int/interp/sockio.lisp
>
> >
> Compiling /tmp/axiom49/int/interp/sockio.lisp.
> End of Pass 1. 
> End of Pass 2. 
> /tmp/axiom49/obj/linux/interp/sockio.c:5139: conflicting
> types for `sock_get_float'
> /tmp/axiom49/obj/linux/interp/sockio.h:46: previous
> declaration of `sock_get_float'
>
> Error: (SYSTEM "gcc -c -I/usr/X11R6/include -Wall
> -DVOL=volatile -fsigned-char -pipe 
> -I/tmp/axiom49/lsp/gcl-2.6.8pre2/unixport/../h  -O3
> -fomit-frame-pointer -c
> \"/tmp/axiom49/obj/linux/interp/sockio.c\" -o
> \"/tmp/axiom49/obj/linux/interp/sockio.o\" -w") returned a
> non-zero value 0.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by UNLESS.
> Broken at APPLY.  Type :H for Help.
> BOOT>>make[3]: *** [/tmp/axiom49/obj/linux/interp/sockio.o] Error 255
> make[3]: Leaving directory `/tmp/axiom49/src/interp'
> make[2]: *** [interpdir] Error 2
> make[2]: Leaving directory `/tmp/axiom49/src'
> make[1]: *** [srcdir] Error 2
> make[1]: Leaving directory `/tmp/axiom49'
> make: *** [all] Error 2
> =
==========================
==========================
============
> ==========
>
>
> which is generated from the lines:
>
> =
==========================
==========================
============
> ==========
> #+KCL
> (progn
>   (clines "extern double plus_infinity(), minus_infinity(), NANQ();")
>   (clines "extern double sock_get_float();")
>   (defentry open_server (string) (int "open_server"))
>   (defentry sock_get_int (int) (int "sock_get_int"))
>   (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_send_float (int float) (int "sock_send_float"))
>   (defentry sock_send_wakeup (int int) (int "sock_send_wakeup"))
>   (defentry server_switch () (int "server_switch"))
>   (defentry flush_stdout () (int "flush_stdout"))
>   (defentry sock_send_signal (int int) (int "sock_send_signal"))
>   (defentry print_line (string) (int "print_line"))
>   (defentry plus_infinity () (double "plus_infinity"))
>   (defentry minus_infinity () (double "minus_infinity"))
>   (defentry NANQ () (double "NANQ"))
>   )
>
> =
==========================
==========================
============
> ==========




-----Original Message-----
From: Camm Maguire [mailto:Camm Maguire]
Sent: Tuesday, August 15, 2006 6:19 PM
To: Tim Daly
Cc: Bill Page; list;
Gabriel Dos Reis; gcl-devel@gnu.org; Robert Boyer
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)

Greetings!

--- axiom-20050901.orig/src/interp/cfuns.lisp.pamphlet
+++ axiom-20050901/src/interp/cfuns.lisp.pamphlet
@@ -103,10 +103,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))
--- axiom-20050901.orig/src/interp/hash.lisp.pamphlet
+++ axiom-20050901/src/interp/hash.lisp.pamphlet
@@ -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"))

--- axiom-20050901.orig/src/interp/sockio.lisp.pamphlet
+++ axiom-20050901/src/interp/sockio.lisp.pamphlet
@@ -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"))


Please let me know if there is any problem with these.

Take care,

Tim Daly writes:

> Camm,
>
> > I had to make the following modifications to 20050901 to work with
the
> > latest 2.6.8pre:
>
> Axiom has had several releases since 20050901.
> What do we need to do to bring it up to date?

\start
Date: Tue, 22 Aug 2006 00:14:44 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: Another question

On 08/21/2006 04:43 PM, Bill Page wrote:
> Martin,
> 
> On August 21, 2006 4:01 AM you wrote:
>> Bill Page writes:
>>> As you know, pamphlet files on MathAction are treated a 
>>> little differently with only a "thumbnail" displayed on
>>> the web page containing links to the pdf and dvi format
>>> generated by LaTeX.  Originally we had planned to use
>>> TeX4ht to produce a web page (or set of web pages) from
>>> the pamphlet source but there turned out to be some
>>> technical limitations. It is quite possible with some
>>> additional effort these problems could be solved. If 
>>> you are interested about this possibility, please ask.
>> Please note that Ralf's ALLPROSE does this already, also 
>> using tex4ht.
> 
> I am sorry Martin, but I don't understand. ALLPROSE does what
> already? The problem referred to above is related to generating
> HTML from Axiom pamphlet source that can be used on the Axiom
> Wiki. Does Ralf have a version of ALLPROSE that can do that?
> If so, could you add some example pages to wiki?

Currently, I don't think that you need ALLPROSE to get the pamphlet 
files shown as html. Tex4ht should be quite enough.
The problem I see is that every pamphlet file is a separate thing. No 
links between different files. But let's not bother with that now. As I 
understood, someone wants an html button for the pamphlet files that 
triggers a routine to produce HTML from the .pamphlet.

First of all, we still haven't agreed on a general structure of pamphlet 
files. All I have seen is that most (if not all) contain the lines

\documentclass{article}
\usepackage{axiom}
\begin{document}
...
\end{document}

If for the purpose of translating that file to html you provide an 
appropriate axiom.sty (and axiom.4ht) which can be different from the 
current existing axiom.sty, then I believe that should be doable.

Let's press the html button.

Then noweave is called to produce .tex.
Then htlatex is called to produce .html. (you might want to call 
makeindex/bibtex... in the middle)

I don't see the problem except that tex4ht sometimes needs a little help 
if strange commands appear in the LaTeX text.

Or maybe that is not the goal, then please clarify what should be 
achieve and what is the input.

\start
Date: Mon, 21 Aug 2006 18:16:23 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Robert Boyer, Camm Maguire

Gaby,

On Saturday, August 19, 2006 2:23 PM you wrote:
>
> Bill Page writes:
>
> | On August 19, 2006 9:51 AM Gaby wrote:
> | > ...
> | > OK; so let's me summarize a candidate patch for axiom.silver or
> | > axiom.build-improvements:
> | >
> | >    * apparently, GCL 2.6.8pre from CVS has more improvements;
> | >    * if we grab that, we must patch Axiom with patches suggested
> | >      by Camm.  Camm, could you give me a list of those?
> | >    * We must, for the moment, configure GCL with --disable-xgcl.
> | >
> | > Is that correct?
> | >
> |
> | Yes, that is correct. Do you have all the pieces?
>
> if you could give me a collection of pointers to them that would be
> appreciated.
>

Here is a

  svn -diff

of my working copy with the accummulated patches

http://wiki.axiom-developer.org/public/camm-patches-2.6.8pre.txt

Will this work for you?

You will also need to pull a new version of gcl-2.6.8pre from the
cvs, thus:

>   export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
>   cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
>   tar czvf gcl-2.6.8pre.tgz gcl-2.6.8pre
>   cd /home/page/axiom.build-improvements/zips
>   mv gcl-2.6.8pre.tgz old_gcl-2.6.8pre.tgz
>   mv /home/page/temp-dir/gcl-2.6.8pre.tgz .

Let me know if this is enough.

\start
Date: 22 Aug 2006 00:24:11 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: latest GCL problem
Cc: Camm Maguire

Bill Page writes:

| Tim, 
| 
| You seem to be missing Camm's patches. See attached email sent
| to you by Camm on Tuesday, August 15, 2006 6:19 PM.

Bill, could you collect all the relevant links in a single message?
That would be very helpful

\start
Date: Mon, 21 Aug 2006 18:24:15 -0400
From: Tim Daly
To: Bill Page
Subject: Re: latest GCL problem
Cc: Camm Maguire

ah. i had 2 out of 3.
meatloaf claims this isn't bad but he's clearly not a programmer :-)

\start
Date: 22 Aug 2006 01:05:12 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Camm Maguire, Robert Boyer

Bill Page writes:

| Here is a
| 
|   svn -diff
| 
| of my working copy with the accummulated patches
| 
| http://wiki.axiom-developer.org/public/camm-patches-2.6.8pre.txt
| 
| Will this work for you?

Many thanks.  This is exactly what I was looking for.

| You will also need to pull a new version of gcl-2.6.8pre from the
| cvs, thus:
| 
| >   export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
| >   cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
| >   tar czvf gcl-2.6.8pre.tgz gcl-2.6.8pre
| >   cd /home/page/axiom.build-improvements/zips
| >   mv gcl-2.6.8pre.tgz old_gcl-2.6.8pre.tgz
| >   mv /home/page/temp-dir/gcl-2.6.8pre.tgz .
| 
| Let me know if this is enough.

\start
Date: Mon, 21 Aug 2006 19:17:44 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: Another question
Cc: Eitan Gurari

Ralf,

On Monday, August 21, 2006 6:15 PM you wrote:
>
> On 08/21/2006 04:43 PM, Bill Page wrote:
> > Martin,
> >
> > On August 21, 2006 4:01 AM you wrote:
> >> Bill Page writes:
> >>> As you know, pamphlet files on MathAction are treated a
> >>> little differently with only a "thumbnail" displayed on
> >>> the web page containing links to the pdf and dvi format
> >>> generated by LaTeX.  Originally we had planned to use
> >>> TeX4ht to produce a web page (or set of web pages) from
> >>> the pamphlet source but there turned out to be some
> >>> technical limitations. It is quite possible with some
> >>> additional effort these problems could be solved. If
> >>> you are interested about this possibility, please ask.
> >>
> >> Martin Rubey wrote:
> >> Please note that Ralf's ALLPROSE does this already, also
> >> using tex4ht.
> >
> > Bill Page wrote:
> > I am sorry Martin, but I don't understand. ALLPROSE does what
> > already? The problem referred to above is related to generating
> > HTML from Axiom pamphlet source that can be used on the Axiom
> > Wiki. Does Ralf have a version of ALLPROSE that can do that?
> > If so, could you add some example pages to wiki?
>
> Currently, I don't think that you need ALLPROSE to get the
> pamphlet files shown as html. Tex4ht should be quite enough.

Understood.

> The problem I see is that every pamphlet file is a separate thing.
> No links between different files. But let's not bother with that
> now. As I understood, someone wants an html button for the pamphlet
> files that triggers a routine to produce HTML from the .pamphlet.

Or perhaps as a replacement for the "thumbnail" image of the first
page which is currently rendered as a png? Or maybe it better to
keep this thumbnail since in some cases the document can be very
large, e.g. the entire Axiom Book.

For example:

http://wiki.axiom-developer.org/book--main--1/Bookvol1

I'll agree to an 'html' button on the header line. :)

>
> First of all, we still haven't agreed on a general structure of
> pamphlet files. All I have seen is that most (if not all) contain
> the lines
>
> \documentclass{article}
> \usepackage{axiom}
> \begin{document}
> ...
> \end{document}
>

Yes.

> If for the purpose of translating that file to html you provide
> an appropriate axiom.sty (and axiom.4ht) which can be different
> from the current existing axiom.sty, then I believe that should
> be doable.

Sorry, I've forgotten most of what I once knew about tex4ht. :)
Of course we want only one source file from which to generate all
of the dvi, ps, pdf and html. I presume that the required changes
to 'axiom.sty' can be made compatible with all these formats?

What is axiom.4ht? Can it be present in the source .tex even
if I just run latex to get the standard dvi, ps, and pdf?

>
> Let's press the html button.
>

You mean metaphorically speaking ... :)

I the case of the Axiom Wiki this action actually takes place
during the 'Save' button processing. The 'html' link on the
header line would be just that - a link to the html file
previously generated by htlatex.

> Then noweave is called to produce .tex.
> Then htlatex is called to produce .html.
> (you might want to call makeindex/bibtex... in the middle)

When generating .html with embedded images for the formula
where do the image files go? Subdirectory? Since there will
be multiple pamphlet files on the wiki, we must take care
where to put the bits and pieces.

>
> I don't see the problem except that tex4ht sometimes needs
> a little help if strange commands appear in the LaTeX text.

Yes, as I recall this is were we ran into some trouble. The Axiom
pamphlet files contain a lot of tex neologisms which are acceptable
to latex but the author of tex4ht, Eitan Gurari, considers need
not be accepted by tex4ht.

http://lists.nongnu.org/archive/html/axiom-developer/2005-10/msg00233.ht
ml

So it seems that to get reliable HTML this way, we may need to
upgrade the standard of LaTeX used in the Axiom pamphlet files.

Eitan Gurari was also working on a jsMath version of tex4ht. I am
not sure of the status of that version.

>
> Or maybe that is not the goal, then please clarify what should be
> achieve and what is the input.
>

Yes, I think that is the goal.

I am willing to give this a try. But I am probably going to need
some help. :)

When latex is called during 'Save' we save the log file and make
it accessible by the 'log' link on the header line so that the
use can check it for errors. Perhaps we also need a separate link
for the log produced by 'htlatex' since these apparently will some
times be different.

\start
Date: Mon, 21 Aug 2006 20:10:25 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Using ALLPROSE for SPAD programming

On Monday, August 21, 2006 1:08 PM Martin Rubey wrote:
>
> > I wrote:
> > > In fact, I think it's high time to switch to ALLPROSE. As
> > > far as I know, the only bit missing is to make it talk to
> > > axiom instead of aldor, but that shouldn't be too difficult,
> > > Ralf?
> Bill Page wrote:
> > :) I have read the ALLPROSE documentation but it is not at
> > all clear to me how this could be done. Perhaps you can
> > elaborate on this idea?
> ...
> Result: Generating documentation doesn't seem to be very
> difficult at all. The main obstacle is, that ALLPROSE expects
> a semicolon to end a definition. Thus, I cheated and wrote:
>
> <<exports: testSPAD>>=
>       double: R -> R --;
> @
>
> It seems that ALLPROSE also expects that the signature
> appears on one line, Ralf? At least
>
> <<exports: testSPAD>>=
>       double: R -> _
>                    R --;
> @
>
> did not work.
>
> The main principle obstacle however is pile syntax (sorry
> Bill). It does not mix well with neither .pamphlet_s nor
> .nw_s:

(: No problem. :)

What is ".pamphlet_s nor .nw_s"?

>
> Continuing with
>
> <<exports: testSPAD>>=
>        triple: R -> R --;
> @
>
> Will produce an error, of course. But I guess, we have to
> live with that problem anyway.
>

To deal with pile syntax maybe we could make use of the
SPAD to Aldor translation option built into Axiom that
you mentioned in another thread? Even if it is not perfect,
perhaps it is good enough to enable ALLPROSE to more easily
extract the necessary information?

> For compiling, we would have to change the extension .as to
> .spad and change calls to aldor to axiom. This is beyond my
> knowledge of allprose though.

>From my point of view the objectives of using ALLPROSE are a
little different than the objectives satisfied by the Axiom
pamphlet files. As I understand it, one of the main points
is to be able to extract the comments embedded in the Aldor/SPAD
source code and typeset it along with other parts of the
documentation that are just LaTeX segments of the pamphlet
file. And also to create appropriate hyperlinks to this stuff.
Is that right? In that case, in the end will it be at least
a partial replacement for the hyperdoc browser?

I think we need to talk more about how this would work both
in a stand alone desktop environment and on the Axiom Wiki.

\start
Date: Mon, 21 Aug 2006 21:50:07 -0400
From: Bill Page
To: Camm Maguire
Subject: Cannot Rename The File Erlib To NRLIB

On Friday, August 18, 2006 3:08 PM Camm Maguire wrote:
>
> This one I believe is machine specific -- can I log in and
> reproduce? (is this axiom-developer.org?)

Yes. Please do.

>
> In general, the easiest way for me to fix these things is to
> work with a build atop GCL configured with --enable-debug.
> If anyone has the time to produce such a build somewhere and
> confirm that the error persists, then point me to it, we can
> take care of this in short order.  I realize that everyone
> else's time is also limited, so if this is not possible please
> so state.
>

No problem. Or more to the point: I understand the problem. ;)

I have built a version of Axiom using the most recent gcl-2.6.8pre
from your CVS and Axiom source from the build-improvements branch
of Axiom Silver with the following gcl configure options:

GCLOPTS="--enable-debug --disable-xgcl --enable-vssize=65536*2
 --enable-statsysbfd --enable-maxpage=196*1024"

Note: This is the same version (except for --enable-debug) that
I used to test your recent patches for the new gcl-2.6.8pre.

You should be able access it on axiom-developer.org by setting:

  $ export AXIOM=/home/page/axiom.build-improvements/mnt/linux
  $ export PATH=$AXIOM/bin:$PATH

> >
> > The problem is not the 'xxx.erlib' directory as such but rather the
> > failure to overwrite the existing 'xxx.NRLIB' directory. Something
> > has changed in recent versions of Axiom, gcl or linux which prevents
> > the lisp function delete-file from deleting the directory.
> >
> > See details:
> >
> > http://wiki.axiom-developer.org/SandBoxArrays
> >
> > This is a known and annoying bug described here:
> >
> > http://wiki.axiom-developer.org/302CannotRenameTheFileErlibToNRLIB
> >
> > Tim believes the problem is in GCL but Camm says that aspect of GCL
> > has not changed. We need to find a solution.
> >
> > As a work-round to the problem perhaps we should modify Axiom to
> > call
> >
> >   (system "rm -r xxx.NRLIB")
> >
> > before the rename?
> >

Here is an annotated console transcript that confirms the problem
and also shows another problem :-(

   >> System error:
   #p"/var/lib/plone2/main/" is not of type SEQUENCE.

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

In the transcript below we are logged in as the user 'plone' who
is the owner of the directory and it's contents.

  $ AXIOMsys

                        AXIOM Computer Algebra System
          Version: Axiom (build improvements branch) -- 2006-08-08
               Timestamp: Monday August 21, 2006 at 17:40:41
------------------------------------------------------------------------
-----
   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) -> )cd
   The current AXIOM default directory is /var/lib/plone2/main/
(1) -> )cd /var/zope/var/LatexWiki

   >> System error:
   #p"/var/lib/plone2/main/" is not of type SEQUENCE.

(1) -> )cd
   The current AXIOM default directory is /var/lib/plone2/main/
(1) -> )quit
   Please enter y or yes if you really want to leave the interactive
      environment and return to the operating system:
yes

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

Darn! Another bug??

Ok, forget that for now. '/var/zope/var/LatexWiki' is where the
directory XPRIMARR.NRLIB lives. When compiling SPAD source code
Axiom wants to replace the existing XPRIMARR.NRLIB with another
directory called XPRIMARR.erlib. The problem seems to be that
the gcl function that Axiom uses to do this will not even allow
the directory XPRIMARR.NRLIB to be over written or deleted
even though similar gcl functions can delete the individual
files in that directory.  Try it this way:

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

  $ cd /var/zope/var/LatexWiki

  $ AXIOMsys

                        AXIOM Computer Algebra System
          Version: Axiom (build improvements branch) -- 2006-08-08
               Timestamp: Monday August 21, 2006 at 17:40:41
------------------------------------------------------------------------
-----
   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) -> -- Check the directory and files are there
(1) -> )sys ls XPRIMARR.NRLIB
code.lsp  code.o  index.KAF  info  XPRIMARR.fn  XPRIMARR.lsp

(1) -> -- We can delete the individual files inside the directory
(1) -> )lisp (mapcar 'delete-file (directory (truename
#p"XPRIMARR.NRLIB/*"))))

Value = (T T T T T T)

(1) -> )sys ls XPRIMARR.NRLIB

(1) -> -- Now try to delete the directory itself
(1) -> )lisp (delete-file (truename #p"XPRIMARR.NRLIB"))

   >> System error:
   Cannot delete the file #p"/var/zope/var/LatexWiki/XPRIMARR.NRLIB".

(1) -> -- But the file priveleges says that we should be able to do
this!
(1) -> )sys ls -l -d XPRIMARR.NRLIB
drwxrwxrwx    2 plone    plone        4096 Aug 21 20:20 XPRIMARR.NRLIB

(1) ->

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

Please let me know what else I can do to help you debug this.

\start
Date: Mon, 21 Aug 2006 22:20:39 -0400
From: Eitan Gurari
To: Bill Page
Subject: re: Another question

 > > \documentclass{article}
 > > \usepackage{axiom}
 > > \begin{document}
 > > ...
 > > \end{document}

 > What is axiom.4ht? Can it be present in the source .tex even
 > if I just run latex to get the standard dvi, ps, and pdf?

The \usepackage{axiom} instruction requests a general purpose style
file axiom.sty.  When a compilation is done under tex4ht, a search is
automatically triggered for an extra axiom.4ht file.  An axiom.4ht
file is expected to introduce html configurations for the features
defined in axiom.sty.

 > Eitan Gurari was also working on a jsMath version of tex4ht. I am
 > not sure of the status of that version.

A jsmath configuration for tex4ht went public on 21 Dec 2005 (see
http://www.cse.ohio-state.edu/~gurari/TeX4ht/bugfixes.html).  

\start
Date: Tue, 22 Aug 2006 07:45:51 +0200
From: Gernot Hueber
To: Bill Page
Subject: RE: Using ALLPROSE for SPAD programming

Hi,

First of all, I want to point out that I don't want to advocate against
ALLPROSE for documentation, which is in fact an interesting development
framework.
Nevertheless, my contribution do the documentation discussion is
non-ALLPROSE. Did you consider using an "javadoc" style for
documentation. E.g. doxygen is a mature and flexible tool aimed primary
at C++ but extended to some more languages. The output formats include
html, latex, and rtf. Furthermore, doxygen can be "easily" extended by
using a preprocessor. I used a simple (and short) perl script to
generate a doxygen documentation for a bunch of VHDL source files (VHDL
is a language for hardware description of digital circuits) by mapping
part of the VHDL syntax to C++. In terms of documentation, the Axiom
Types correspond to C++ objects. Furthermore, both languages have public
exports and private functions, ...

In my opinion, this is _not_ an out-of-the-box solution, yet worth
considering.

On Mon, 2006-08-21 at 20:10 -0400, Page, Bill wrote:
> On Monday, August 21, 2006 1:08 PM Martin Rubey wrote:
> >
> > > I wrote:
> > > > In fact, I think it's high time to switch to ALLPROSE. As
> > > > far as I know, the only bit missing is to make it talk to
> > > > axiom instead of aldor, but that shouldn't be too difficult,
> > > > Ralf?
> > Bill Page wrote:
> > > :) I have read the ALLPROSE documentation but it is not at
> > > all clear to me how this could be done. Perhaps you can
> > > elaborate on this idea?
> > ...
> > Result: Generating documentation doesn't seem to be very
> > difficult at all. The main obstacle is, that ALLPROSE expects
> > a semicolon to end a definition. Thus, I cheated and wrote:
> >
> > <<exports: testSPAD>>=
> >       double: R -> R --;
> > @
> >
> > It seems that ALLPROSE also expects that the signature
> > appears on one line, Ralf? At least
> >
> > <<exports: testSPAD>>=
> >       double: R -> _
> >                    R --;
> > @
> >
> > did not work.
> >
> > The main principle obstacle however is pile syntax (sorry
> > Bill). It does not mix well with neither .pamphlet_s nor
> > .nw_s:
>
> (: No problem. :)
>
> What is ".pamphlet_s nor .nw_s"?
>
> >
> > Continuing with
> >
> > <<exports: testSPAD>>=
> >        triple: R -> R --;
> > @
> >
> > Will produce an error, of course. But I guess, we have to
> > live with that problem anyway.
> >
>
> To deal with pile syntax maybe we could make use of the
> SPAD to Aldor translation option built into Axiom that
> you mentioned in another thread? Even if it is not perfect,
> perhaps it is good enough to enable ALLPROSE to more easily
> extract the necessary information?
>
> > For compiling, we would have to change the extension .as to
> > .spad and change calls to aldor to axiom. This is beyond my
> > knowledge of allprose though.
>
> >From my point of view the objectives of using ALLPROSE are a
> little different than the objectives satisfied by the Axiom
> pamphlet files. As I understand it, one of the main points
> is to be able to extract the comments embedded in the Aldor/SPAD
> source code and typeset it along with other parts of the
> documentation that are just LaTeX segments of the pamphlet
> file. And also to create appropriate hyperlinks to this stuff.
> Is that right? In that case, in the end will it be at least
> a partial replacement for the hyperdoc browser?
>
> I think we need to talk more about how this would work both
> in a stand alone desktop environment and on the Axiom Wiki.

\start
Date: Tue, 22 Aug 2006 02:02:50 -0400
From: Eitan Gurari
To: Bill Page
Subject: re: Another question

 >  I am "scratching
 > my head" ... how do I update my installation?

Bill,

I added a pointer to instructions at the end of the first paragraph in

   http://www.cse.ohio-state.edu/~gurari/TeX4ht/bugfixes.html

Hopefully they are not buggy.

\start
Date: Tue, 22 Aug 2006 02:19:34 -0400
From: Tim Daly
To: Gernot Hueber
Subject: Re: Using ALLPROSE for SPAD programming

> Nevertheless, my contribution do the documentation discussion is
> non-ALLPROSE. Did you consider using an "javadoc" style for
> documentation. E.g. doxygen is a mature and flexible tool aimed primary
> at C++ but extended to some more languages. The output formats include
> html, latex, and rtf. Furthermore, doxygen can be "easily" extended by
> using a preprocessor. I used a simple (and short) perl script to
> generate a doxygen documentation for a bunch of VHDL source files (VHDL
> is a language for hardware description of digital circuits) by mapping
> part of the VHDL syntax to C++. In terms of documentation, the Axiom
> Types correspond to C++ objects. Furthermore, both languages have public
> exports and private functions, ...

yes, i wrote a document on the internal details of the Jikes compiler
using doxygen and i have used javadoc extensively on many projects.
both are excellent tools for documentation. but we're not trying to 
write documentation.

the choice of noweb-style programming is more a matter of philosophy
than technical details. the hardest and most subtle part of the choice
is a change of mindset. it really can be distinguished by the difference
between the words "document" and "literature". "documents" are what 
programmers write to help other programmers. "literature" is what you
write when you want to communicate with another person above the level
of implementation.

after a few false starts i eventually settled on knuth's style.
most scientists know latex and use it to write technical papers.
noweb only adds a trivial amount of syntax to latex and is an
easy learning curve. so for computational science, latex is a natural
choice.

and latex is widely used to write books (aka literature) so for 
writing mathematics "literature" it is also a natural.

the hardest part is that it really is a cliff-like transition to 
do literate programming. it is NOT the same as hacking the source
and adding some words around it. more like writing the ideas and
then reducing them to practice. it took me a couple years to 
finally realize the subtle but vital difference. it is the same
insight a programmer gets when he first learns lisp, mistakenly
thinking that lisp is "just another language". at some point there
is a "religious conversion" when, having seen the light, you can
only mourn the wasted years of non-enlightenment :-)

literate programming is not the same as documentation.

\start
Date: Tue, 22 Aug 2006 04:03:30 -0400
From: Bill Page
To: Eitan Gurari
Subject: re: Another question

Eitan,

On Tuesday, August 22, 2006 2:03 AM you wrote:
>
> I added a pointer to instructions at the end of the first
> paragraph in
>
>    http://www.cse.ohio-state.edu/~gurari/TeX4ht/bugfixes.html
>
> Hopefully they are not buggy.
>

Thank you! I feel a little more human now. :) and I've now got
jsMath from the command:

  htlatex test2 "xhtml,jsmath" " -cmozhtf"

See: http://page.axiom-developer.org/test2.html

I think your instructions are fine but I have just a few
comments and questions:

1) [Configuration files]

   On my system teTeX is apparently looking in a different
   (non-standard?) place for texmf/tex/generic/tex4ht. From
   the output of htlatex I deduced that I had to use:

   cp texmf/tex/generic/tex4ht/* \
      /usr/local/teTeX/share/texmf-dist/tex/generic/tex4ht

   instead of /usr/share/texmf/tex/generic/tex4ht, although
   it do also have this directory on my system.

   At first I completely followed your instructions exactly
   as you wrote them. Everything seemed to go fine, and passed
   the simple test each time but there was no jsMath output
   from

     htlatex test2 "xhtml,jsmath" " -cmozhtf"

   After I repeated just your step 2 using using the copy
   command shown above, now it works.

2. [Fonts]

   I also have a directory:

     /usr/local/teTeX/share/texmf-dist/tex4ht/ht-fonts

   in addition to /usr/share/texmf/tex4ht/ht-fonts but I did only
   the copy
     
     cp -rp ht-fonts /usr/share/texmf/tex4ht

3. paths

   In step 20 I did a global replace of '~/tex4ht.dir/texmf/tex4ht'
   with '/usr/share/texmf/tex4ht' in the file

     /usr/share/texmf/tex4ht/base/unix/tex4ht.env

   Is this sufficient to make sure that tex4ht also finds the new
   fonts? Or should I also put them in texmf-dist?

     cp -rp ht-fonts /usr/local/teTeX/share/texmf-dist/tex4ht

4. The html file that is generated from jsmath option contains
   the following location for the jsMath:

    <script type="text/javascript" src="jsMath/jsMath/jsMath.js">
    </script>

  with jsMath/ repeated twice in the path. This seems (perhaps)
  a non-standard location for jsMath.js. On the axiom-developer
  server it needs only one instance of jsMath/. Is this
  configurable?

Many, many thanks for this work! :)

\start
Date: Tue, 22 Aug 2006 10:19:32 +0200
From: Gernot Hueber
To: Tim Daly
Subject: Re: Using ALLPROSE for SPAD programming

On Tue, 2006-08-22 at 02:19 -0400, root wrote:
> > Nevertheless, my contribution do the documentation discussion is
> > non-ALLPROSE. Did you consider using an "javadoc" style for
> > documentation. E.g. doxygen is a mature and flexible tool aimed primary
> > at C++ but extended to some more languages. The output formats include
> > html, latex, and rtf. Furthermore, doxygen can be "easily" extended by
> > using a preprocessor. I used a simple (and short) perl script to
> > generate a doxygen documentation for a bunch of VHDL source files (VHDL
> > is a language for hardware description of digital circuits) by mapping
> > part of the VHDL syntax to C++. In terms of documentation, the Axiom
> > Types correspond to C++ objects. Furthermore, both languages have public
> > exports and private functions, ...
> 
> yes, i wrote a document on the internal details of the Jikes compiler
> using doxygen and i have used javadoc extensively on many projects.
> both are excellent tools for documentation. but we're not trying to 
> write documentation.
> 
> the choice of noweb-style programming is more a matter of philosophy
> than technical details. the hardest and most subtle part of the choice
> is a change of mindset. it really can be distinguished by the difference
> between the words "document" and "literature". "documents" are what 
> programmers write to help other programmers. "literature" is what you
> write when you want to communicate with another person above the level
> of implementation.
> 
> after a few false starts i eventually settled on knuth's style.
> most scientists know latex and use it to write technical papers.
> noweb only adds a trivial amount of syntax to latex and is an
> easy learning curve. so for computational science, latex is a natural
> choice.

I agree with you, there are no alternatives to latex.

> 
> and latex is widely used to write books (aka literature) so for 
> writing mathematics "literature" it is also a natural.
> 
> the hardest part is that it really is a cliff-like transition to 
> do literate programming. it is NOT the same as hacking the source
> and adding some words around it. more like writing the ideas and
> then reducing them to practice. it took me a couple years to 
> finally realize the subtle but vital difference. it is the same
> insight a programmer gets when he first learns lisp, mistakenly
> thinking that lisp is "just another language". at some point there
> is a "religious conversion" when, having seen the light, you can
> only mourn the wasted years of non-enlightenment :-)
> 
> literate programming is not the same as documentation.

I see I have to work on my enlightenment :-)

Thank you for your extensive explanation.

\start
Date: 22 Aug 2006 10:38:29 +0200
From: Martin Rubey
To: Igor Khavkine
Subject: Re: [Axiom-math] Curious behavior of Taylor series

Igor Khavkine writes:

> On 21 Aug 2006 22:13:13 +0200, Martin Rubey wrote:

> I can try. But I hope my small patch will still be accepted even if I
> can't find the time to thoroughly document that function.

I'm afraid: no. In fact, I will very likely use it myself, but it won't go into
the distribution until it is documented.

But it is certainly enough to explain roughly what is happening in every couply
of lines in powern and to explain exactly what your patch is doing. Thus,
along the lines of


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

      smult: (RN,ST A) -> ST A
      smult(rn,x) == map(rn * #1,x)
@

The following operation [[powerrn]] computes lazily ???

<<package STTAYLOR StreamTaylorSeriesOperations>>=
      powerrn:(RN,ST A,ST A) -> ST A
      powerrn(rn,x,c) == delay
        concat(1,integ(smult(rn + 1,c * deriv x)) - rst x * c)
@

[[powern(rn, x)]] computes $x^{rn}$, $x$ being a power series. Compare with
[[cRationalPower$ISUPS]].

<<package STTAYLOR StreamTaylorSeriesOperations>>=
      powern(rn,x) ==
        order : I := 0
        for n in 0.. repeat
          empty? x => return zro()
          not zero? frst x => (order := n; leave x)
          x := rst x
          n = 1000 =>
            error "**: series with many leading zero coefficients"
@

First we determine the order of [[x]], i.e., the index of the first non-zero
coefficient. (Is that true ???)

Remarks:
\begin{itemize}
\item Note that usually [[leave]] takes no arguments. I don't know what it does
      here.
\item [[empty? x]] tests whether the stream [[x]] has no elements. This is
      mathematically the same as the corresponding power series being zero.
\end{itemize}

<<package STTAYLOR StreamTaylorSeriesOperations>>=
        (ord := (order exquo denom(rn))) case "failed" =>
          error "**: rational power does not exist"
@

[[ord]] will be the order of the new power series. If it is not an integer, we
won't get a Taylor expansion.

<<package STTAYLOR StreamTaylorSeriesOperations>>=
        co := frst x
        (invCo := recip co) case "failed" =>
           error "** rational power of coefficient undefined"
-- This error message is misleading, isn't it? see sups.spad/cRationalPower
@

The leading coefficient has to be invertible???

<<package STTAYLOR StreamTaylorSeriesOperations>>=
        power :=
--          one? co => YS(powerrn(rn,x,#1))
          (co = 1) => YS(powerrn(rn,x,#1))
          (denom rn) = 1 =>
            not negative?(num := numer rn) => 
-- It seems that this cannot happen, but I don't know why
              (co**num::NNI) * YS(powerrn(rn,(invCo :: A) * x,#1))
            (invCo :: A)**((-num)::NNI) * YS(powerrn(rn,(invCo :: A) * x,#1))

          RATPOWERS => co**rn * YS(powerrn(rn,(invCo :: A) * x,#1))
          error "** rational power of coefficient undefined"

        zeropref: ST A := new(ord::I::NNI,0::A)$LA :: ST A
        concat(zeropref, power)
@


<<package STTAYLOR StreamTaylorSeriesOperations>>=
    if A has Field then

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

> In any case, I'm not sure I completely understand what powern does.  I've
> looked at servarl power series manipulation routines already, but I get
> stumped every time I run into this object: Y from
> ParadoxicalCombinatorsForStreams. Can someone explain what it does?

Not really. The documentation says

  A  :   Type
  ST ==> Stream

    Y: (ST A -> ST A) -> ST A
      ++ Y(f) computes a fixed point of the function f.

In our case A is the ring of coefficients and powern calls

Y(powerrn(rn,x,#1))

Here, rn is the exponent, and x is the power series. Thus, Y computes a fixed
point - whatever that is - of the function

f +-> powerrn(rn, x, f)

I guess it would help to know what powerrn does. A different possibility to
find out is to look at cRationalPower in sups.spad.pamphlet. The block
(formally) corresponding to 

        power := 
          one? co => YS(powerrn(rn, x, #1))
          one? (denom rn) =>
            not negative?(num := numer rn) => 
-- It seems that this cannot happen, but I don't know why
              (co ** num::NNI) * YS(powerrn(rn, (invCo::A) * x, #1))
            (invCo::A)**((-num)::NNI) * YS(powerrn(rn, (invCo::A) * x, #1))

          RATPOWERS => co ** rn * YS(powerrn(rn, (invCo::A) * x, #1))
          error "** rational power of coefficient undefined"

        zeropref: ST A := new(ord::I::NNI, 0$A)$LA :: ST A
        concat(zeropref, power)


reads (ccInv == invCo, n == ord, cc == co, r == rn, uts == x)

        ccPow :=
          one? cc => cc
          one? denom r =>
            not negative?(num := numer r) => cc ** (num::NNI)
            (ccInv::Coef) ** ((-num)::NNI)

          RATPOWERS => cc ** r
          error "** rational power of coefficient undefined"

        uts1 := (ccInv::Coef) * uts
        uts2 := uts1 * monomial(1, -order)
        monomial(ccPow, (n::I) * numer(r)) * cPower(uts2, r::Coef)



So, it seems that in ISUPS, the equivalent to YS(powerrn(rn, (invCo::A) * x,
#1)) is factored out. We have the equivalence

ccPow  * z^(n*numer r) * cPower(ccInv * uts * z^(-order), r)

power  * z^ord         * YS(powerrn(rn, (invCo::A) * x, #1)) 

Note that n*numer r = order/denom r * numer r = order * r

     but  ord       = order/denom rn          = order * rn / numer rn

so that "explains" the appearance of z^(-order) in the ISUPS version.


I have to stop here, sorry,

\start
Date: Tue, 22 Aug 2006 11:08:31 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: Another question
Cc: Eitan Gurari

>> If for the purpose of translating that file to html you provide
>> an appropriate axiom.sty (and axiom.4ht) which can be different
>> from the current existing axiom.sty, then I believe that should
>> be doable.
> 
> Sorry, I've forgotten most of what I once knew about tex4ht. :)
> Of course we want only one source file from which to generate all
> of the dvi, ps, pdf and html. I presume that the required changes
> to 'axiom.sty' can be made compatible with all these formats?
> 
> What is axiom.4ht? Can it be present in the source .tex even
> if I just run latex to get the standard dvi, ps, and pdf?

If you latex the .pamplet.tex file then (of course) latex does not know 
about axiom.4ht and ignores it completely. So nothing will change.

Now, htlatex... that does invoke latex, too, but before the 
\documentclass of the file is touched, several tweaks specific to tex4ht 
are done. One of that is that whenever you have a \usepackage{blah} it 
reads the file blah.sty and later also blah.4ht if that is there. (I 
hope, I remember that correctly.)

Normally tex4ht is clever enough so that you simply don't need the .4ht 
file. In ALLPROSE, however, I have these colored environments done with 
the "framed" package which did not work with tex4ht. Fortunately, it was 
quite easy to find an equivalent for the html output. That I have 
written into allprose.4ht. See Chapter 26 or the ALLPROSE documentation.

Anyway, forget about the, .4ht until something does not htlatex. Then 
post to the list and to Eitan Guari. He tries to be quite responsive in 
such matters. I really don't know why the LaTeX people haven't included 
tex4ht in normal TeX distributions. Tex4ht is really quite powerful 
because it uses the tex machine.

>> Let's press the html button.
>>
> 
> You mean metaphorically speaking ... :)
> 
> I the case of the Axiom Wiki this action actually takes place
> during the 'Save' button processing. The 'html' link on the
> header line would be just that - a link to the html file
> previously generated by htlatex.

Oh, if that is done this way, no problem. Of course it is better to 
cache the html output.

>> Then noweave is called to produce .tex.
>> Then htlatex is called to produce .html.
>> (you might want to call makeindex/bibtex... in the middle)

> When generating .html with embedded images for the formula
> where do the image files go? Subdirectory? Since there will
> be multiple pamphlet files on the wiki, we must take care
> where to put the bits and pieces.

Ehm.... the html target in ALLPROSE looks like

html: tex4htlatex tex4htpostproces docdir
	$(CP) $(projectname)*.html $(DOCDIR)
	$(CP) $(projectname)*.css  $(DOCDIR)
	-$(CP) $(projectname)*.png  $(DOCDIR)
	@echo
	@echo "$(HTMLVIEWER) $(DOCDIR)/$(projectname).html &"
	@echo

So everything is output in the directory where you process the file 
$(projectname).tex. Then I simply copy them to the place I want them to be.

By the way, if you look at the toplevel Makefile, you'll realize that I 
don't call htlatex. The version of tex4ht that I get with debian sarge 
did not meet my needs. Meanwhile I had conversations with Eitan and some 
other guy who improved htlatex and friends quite a lot. I don't know, 
however, whether this is already released.

>> I don't see the problem except that tex4ht sometimes needs
>> a little help if strange commands appear in the LaTeX text.

> Yes, as I recall this is were we ran into some trouble. The Axiom
> pamphlet files contain a lot of tex neologisms which are acceptable
> to latex but the author of tex4ht, Eitan Gurari, considers need
> not be accepted by tex4ht.

> http://lists.nongnu.org/archive/html/axiom-developer/2005-10/msg00233.ht
> ml

> So it seems that to get reliable HTML this way, we may need to
> upgrade the standard of LaTeX used in the Axiom pamphlet files.

Well, maybe we should start with dhmatrix. I somehow agree with you and 
Eitan. Writing TeX should not be considered the best way of writing a 
.pamphlet file. LaTeX is so much more structured that it is easier to 
convert to other formats. One cannot do all the TeX tricks and outputs 
equivalent HTML. Page numbers is one thing that you don't need in html.

Anyway, would it be a good start to take dhmatrix. We could tex->latex 
it while we try to get an html out of it.

And... perhaps we should first forget about mathml. I think the .png 
generation is the easier way to go.

> I am willing to give this a try. But I am probably going to need
> some help. :)

Well, do we have an svn branch for that? I just want to say "svn update" 
and "htlatex dhmatix" (or better make dhmatrix.html). Once we have some 
experience with compiling dhmatrix, we could cary on for the other 
files. Then you could try to write a python wrapper to get it into 
mathaction.

Let us also forget for a moment about the \begin{axiom} ... \end{axiom} 
environments. Just translating them as verbatim would be fine.

Later, I think, one needs a script that runs over the .pamphlet.tex 
file, extracts the content of the environment, writes it out to a 
file/several files axiom.somenumber.input, and at the same time modifies 
the environment \begin{axiom} ... \end{axiom} to 
\begin{axiomoutput}{somenumber} ... \end{axiomoutput} and writes a file 
.pamphlet.ax.tex.
Then run axiom and produce files axiom.somenumber.tex (maybe a script is 
involve here to split the axiom output into its parts -- but that you 
know already from mathaction, I guess).
After that call htlatex on the generated .pamphlet.ax.tex file. The 
\begin{axiomoutput}{somenumber} ... \end{axiomoutput} environments 
should simply ignore there content and set the content of the file 
axiom.somenumber.tex.

Doesn't sound un-doable to me.

\start
Date: 22 Aug 2006 11:46:10 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: Another question

Dear Ralf,

Ralf Hemmecke writes:

> Anyway, would it be a good start to take dhmatrix. We could tex->latex it while
> we try to get an html out of it.

The one thing I don't understand about all this is:

why won't we use ALLPROSE?

> On Monday, August 21, 2006 1:08 PM Martin Rubey wrote:

> > The main obstacle is, that ALLPROSE expects a semicolon to end a
> > definition. Thus, I cheated and wrote: 

> > <<exports: testSPAD>>= double: R -> R --; @
> > 
> > It seems that ALLPROSE also expects that the signature appears on one line,
> > Ralf? At least
> > 
> > <<exports: testSPAD>>=
> >       double: R -> _
> >                    R --;
> > @
> > 
> > did not work.
> > 
> > The main principle obstacle however is pile syntax (sorry Bill). It does
> > not mix well with neither .pamphlet_s nor .nw_s:
> 
> (: No problem. :)
> 
> What is ".pamphlet_s nor .nw_s"?

I meant, neither with pamphlet (i.e., Axiom project) files, nor with noweb
(i.e., ALLPROSE) files.

> To deal with pile syntax maybe we could make use of the SPAD to Aldor
> translation option built into Axiom that you mentioned in another thread?
> Even if it is not perfect, perhaps it is good enough to enable ALLPROSE to
> more easily extract the necessary information?

No. First of all, I don't think it's necessary. You only have to teach ALLPROSE
how to find out where a line ends. Currently, in ALLPROSE, the regexp used is
described in Section tools/addaldortypedef.pl of the ALLPROSE documentation,
but Ralf certainly knows better than me.

That's one thing I cannot do.

> From my point of view the objectives of using ALLPROSE are a little different
> than the objectives satisfied by the Axiom pamphlet files. 

Well, the pamphlets satisfy only a subset of our needs. In particular, there is
very little support for HyperDoc. Using ALLPROSE, you get that (nearly) for
free: the +++ environments are copied into the code. When compiling the file
with Axiom, they magically appear in HyperDoc. Of course, within the +++
environments, one would have to restrict oneself to those things hyperdoc
understands. For example, ALLPROSE produces

+++   \begin{addescription}{Generates all isomorphism types.}
+++   \end{addescription}
+++   \begin{ToDo}
+++     \begin{rhx} 14-Aug-2006:
+++       It is not yet clear what the type of this function/constant
+++       should be.
+++ %
+++       In general, isomorphism types are equivalence classes of
+++       structures. It could be reasonable to say that \adthisname{}
+++       returns (unique) representatives of these classes. (The
+++       \emph{unique} is probably a though thing, since we might have no
+++       order on the input set or on $L$ in general.
+++     \end{rhx}
+++   \end{ToDo}
--#line 384 "species.as.nw"
isomorphismTypes: Set L -> Generator %;


Now, the main problem are the commands \adthisname and \adthistype. In the dvi
(or html or whatever) generated by ALLPROSE, they are replaced by the
appropriate names. In the example above, one would read:

+++       structures. It could be reasonable to say that isomorphismTypes
+++       returns (unique) representatives of these classes. (The

HyperDoc cannot handle that, unfortunately.

Ralf, would it be very difficult to make ALLPROSE magically replace \adthisname
with \spadfun{isomorphismTypes} (or, if you like that better, with
\adthisname{isomorphismTypes}) and \adthistype with
\spadType{CombinatorialSpecies}?

That's the second thing I cannot do.

All the other things I can do within HyperDoc.

\start
Date: Tue, 22 Aug 2006 06:19:30 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: Another question
Cc: Eitan Gurari

Ralf,

Thanks for the explanations about .4ht etc.

On Tuesday, August 22, 2006 5:09 AM you wrote:
> ...
> Bill Page wrote:
> > When generating .html with embedded images for the formula
> > where do the image files go? Subdirectory? Since there will
> > be multiple pamphlet files on the wiki, we must take care
> > where to put the bits and pieces.
>
> ...
> So everything is output in the directory where you process the
> file $(projectname).tex. Then I simply copy them to the place I
> want them to be.

I read somewhere in the tex4ht that the path prefix of the
images directory is configurable. I suppose this is not normally
to significant, but I just did a few experiments using htlatex on

http://wiki.axiom-developer.org/images/book--main--1/bookvol1.tex

As a pdf file this is about 800 pages.  As html it generates nearly
600 png files and my browsers (both FireFox and Explorer) die while
trying to render it. And the download is pretty horrendous anyway
:( htlatex indicates a large number of errors which I simply skipped
for this test.

So it seems that ""one big file" here is not really such a good idea.

Running mzhtml on this file to generate MathML unfortunately results
in an improperly formatted XML file:

http://wiki.axiom-developer.org/images/book--main--1/bookvol1m.xml

The xml file is about 3 times the size of the pdf file.

Interestingly, running the command

  htlatex bookvol1 "xhtml,jsmath" " -cmozhtf"

to produce a jsMath HTML file results in a file that is slightly
smaller than the pdf file:

http://wiki.axiom-developer.org/images/book--main--1/bookvol1.html

Unfortunately the jsMath rendering takes quite a long time - about
2 minutes on my 1 GHz system. It's only about a minute if I set
the option to delay display until after the jsMath processing.
But it does do a pretty nice job ... To bad there doesn't seem
to be any way to get more speed out of JavaScript.

> ...
> > So it seems that to get reliable HTML this way, we may need
> > to upgrade the standard of LaTeX used in the Axiom pamphlet
> > files.
>
> Well, maybe we should start with dhmatrix. I somehow agree with
> you and Eitan. Writing TeX should not be considered the best way
> of writing a  .pamphlet file. LaTeX is so much more structured
> that it is easier to convert to other formats. One cannot do all
> the TeX tricks and outputs equivalent HTML. Page numbers is one
> thing that you don't need in html.

Agreed.

>
> Anyway, would it be a good start to take dhmatrix. We could
> tex->latex it while we try to get an html out of it.

Good idea except it looks like this one works already! This document
was one of the test files that I originally recommended to Eitan so
perhaps he did tweak tex4ht a little more to help make this work.
(If so, thanks Eitan. :)

The tex file is available here:

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/DhmatrixSpad

>
> And... perhaps we should first forget about mathml. I think the
> .png generation is the easier way to go.

htlatex generates

http://wiki.axiom-developer.org/images/axiom--test--1/src/algebra/dhmatr
ix2.spad.html

and about 70 png files with no errors.

Running

  htlatex dhmatrix.spad "xhtml,jsmath" " -cmozhtf"

produced the following jsMath document (also with no errors):

http://wiki.axiom-developer.org/images/axiom--test--1/src/algebra/dhmatr
ix.spad.html

It takes about 30 seconds to render but I think it looks great.

Finally mzlatex gives:

http://wiki.axiom-developer.org/images/axiom--test--1/src/algebra/dhmatr
ix3.spad.xml

unfortunately with another xml error message:

XML Parsing Error: mismatched tag. Expected: </msub>.
Line Number 310, Column 17:>D</mi></mrow></msup

>
> > I am willing to give this a try. But I am probably going to need
> > some help. :)
>
> Well, do we have an svn branch for that? I just want to say
> "svn update" and "htlatex dhmatix" (or better make dhmatrix.html).
> Once we have some experience with compiling dhmatrix, we could cary
> on for the other files. Then you could try to write a python wrapper
> to get it into mathaction.

You should be able to do that now. Take a look for

  src/algebra/dhmatrix.spad.pamphlet

and just noweave the dhmatrix.spad.tex file.

>
> Let us also forget for a moment about the \begin{axiom} ...
> \end{axiom} environments. Just translating them as verbatim
> would be fine.
>
> Later, I think, one needs a script that runs over the
> .pamphlet.tex file, extracts the content of the environment,
> writes it out to a file/several files axiom.somenumber.input,
> and at the same time modifies the environment \begin{axiom}
> ... \end{axiom} to \begin{axiomoutput}{somenumber} ...
> \end{axiomoutput} and writes a file .pamphlet.ax.tex. Then
> run axiom and produce files axiom.somenumber.tex (maybe
> a script is involve here to split the axiom output into its
> parts -- but that you know already from mathaction, I guess).
> After that call htlatex on the generated .pamphlet.ax.tex file.

Sage has a very nice little latex package for doing exactly
this sort of thing (but more simply). I think we can easily
adapt it for Axiom. If you have the Sage distribution, it is
in the 'examples/latex-embed' directory. If you don't want
do download and install all of Sage, then I can just send it
to you. Also the new graphviz.sty has a similar technique that
could even be used to run Axiom automatically as part of the
LaTeX compile.

> The \begin{axiomoutput}{somenumber} ... \end{axiomoutput}
> environments should simply ignore there content and set the
> content of the file axiom.somenumber.tex.
>
> Doesn't sound un-doable to me.
>

Quite doable. Now, the question is: Are Axiom developers and
users really motivated to use this sort of thing??

\start
Date: Tue, 22 Aug 2006 14:18:48 +0200
From: Ralf Hemmecke
To: Gernot Hueber
Subject: Re: Using ALLPROSE for SPAD programming

> First of all, I want to point out that I don't want to advocate against
> ALLPROSE for documentation, which is in fact an interesting development
> framework.
> Nevertheless, my contribution do the documentation discussion is
> non-ALLPROSE. Did you consider using an "javadoc" style for
> documentation.

Of course. You certainly know about the +++ comments. These things have 
been invented before Java came into existence. The only problem with 
Aldor is that there is not yet a proper tool to make use of this data.

ALLPROSE hast \begin{+++} ... \end{+++} for that.

 > E.g. doxygen is a mature and flexible tool aimed primary
> at C++ but extended to some more languages.

Yep, doxygen is too much tailored for C/C++. If you make it work for 
Aldor, it might be worth another try.

But as Tim suggests, that is not the point of literate programming. LP 
is here to express your ideas and illustrate these ideas by real (in 
contrast to pseudo) code. So you basically write a research article (or 
so). In that sense I fully support Tim and Knuth.

But as you can see with my \begin{+++} ... \end{+++} environments, I 
also strongly believe that for using other peoples work it is often 
quite sufficient if you know about the API of what that library/program 
does on which you want to build. You do not usually want to read 
thousands of pages and books before you are able to write one single 
line of code.

I, for example, would be quite happy if someone writes a library for 
factorization of multivariate polynomials in an LP style and 
additionally gives me a short API description of what his function does 
and how I have to call it. I am simply not interested in learning all 
the difficult stuff about an efficient implementation and about tricks 
in this implementation to make it even more efficient. I want to use 
factorization. If I ever become interested in the details, I can come 
back to that later.

So my approach in ALLPROSE is to write in an LP style and *additionally* 
provide an API description for those who don't want to delve too deeply 
into the details.

If you can make some tool available that supports such a combined 
approach, I would be quite happy to see them.

But I would never sacrifice the LP approach to doxygen. Doxygen (to my 
taste--correct me if I'm wrong) is only about the API, ie half of the 
story -- if not less.

\start
Date: Tue, 22 Aug 2006 14:35:21 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Another question

>> Anyway, would it be a good start to take dhmatrix. We could tex->latex it while
>> we try to get an html out of it.
> 
> The one thing I don't understand about all this is:
> 
> why won't we use ALLPROSE?

All the current pamphlet stuff is legacy code. It simply doesn't fit so 
easily into ALLPROSE, yet making it available in an HTML form should be 
simple enough before we go the ALLPROSE way.

And as Bill pointed out, ALLPROSE is an environment for writing 
libraries. As I understood, making pamphlets available as HTML has 
nothing to do with libraries. At least not at the moment.

>>> The main principle obstacle however is pile syntax (sorry Bill). It does
>>> not mix well with neither .pamphlet_s nor .nw_s:
>> (: No problem. :)
>>
>> What is ".pamphlet_s nor .nw_s"?

I guess, that is simply a plural s.

>> To deal with pile syntax maybe we could make use of the SPAD to Aldor
>> translation option built into Axiom that you mentioned in another thread?
>> Even if it is not perfect, perhaps it is good enough to enable ALLPROSE to
>> more easily extract the necessary information?
> 
> No. First of all, I don't think it's necessary. You only have to teach ALLPROSE
> how to find out where a line ends. Currently, in ALLPROSE, the regexp used is
> described in Section tools/addaldortypedef.pl of the ALLPROSE documentation,
> but Ralf certainly knows better than me.

All that parsing of the source .as.nw files in ALLPROSE, is probably 
unnecessary for the generation of HTML from pamphlets. In ALLPROSE, I 
have added some conventions to make this parsing easier. These 
conventions are not there for pamphlet files so the parsing would mean 
to write a SPAD parser that understands noweb chunks. Ufff.

>> From my point of view the objectives of using ALLPROSE are a little different
>> than the objectives satisfied by the Axiom pamphlet files. 

> Well, the pamphlets satisfy only a subset of our needs.

I simply have the suspicion that Martin talks about pamphlet files of 
the form .spad.pamphlet and anybody else means pamphlets with general 
content so also .lisp.pamphlet or Makefile.pamphlet. Am I wrong?

\start
Date: 22 Aug 2006 14:45:27 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: Another question

Ralf Hemmecke writes:

> Martin wrote:

> > why won't we use ALLPROSE?


> I simply have the suspicion that Martin talks about pamphlet files of the form
> .spad.pamphlet and anybody else means pamphlets with general content so also
> .lisp.pamphlet or Makefile.pamphlet. Am I wrong?

Oh, yes you are right. I had only SPAD in mind. On the other hand, you do
document your perl and Makefile stuff with ALLPROSE too, so, I guess that we
can focus on the differences between Aldor and SPAD.

> All the current pamphlet stuff is legacy code. It simply doesn't fit so
> easily into ALLPROSE, yet making it available in an HTML form should be
> simple enough before we go the ALLPROSE way.

OK. Although I think it would be high time to move from pamphlet files to
ALLPROSE files. After all, nothing forces us to use all the features of
ALLPROSE right away. The only thing we *have* to do is to transform the ++ and
+++ bits into +++ environments, because otherwise hyperdoc won't work anymore.

> And as Bill pointed out, ALLPROSE is an environment for writing libraries. As
> I understood, making pamphlets available as HTML has nothing to do with
> libraries. At least not at the moment.

What? In what way is DHMATRIX different from a library?

> All that parsing of the source .as.nw files in ALLPROSE, is probably
> unnecessary for the generation of HTML from pamphlets. In ALLPROSE, I have
> added some conventions to make this parsing easier. These conventions are not
> there for pamphlet files so the parsing would mean to write a SPAD parser
> that understands noweb chunks. Ufff.

No no, the conventions are quite OK. No way we are going to write yet another
SPAD parser. As far as I understand, since ALLPROSE literally copies the +++
environment into a +++ section, there is no need to adhere to the ALLPROSE
conventions at first. This becomes necessary only from the point from which we
want to use \adthisname and \adthistype. So I guess that the transformation of
spad.pamphlet into ALLPROSE files could be done in a semi-automatic way.

Am I missing something? I guess I'll have to try it out with some file.

\start
Date: Tue, 22 Aug 2006 15:04:58 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: Another question
Cc: Eitan Gurari

> http://wiki.axiom-developer.org/images/book--main--1/bookvol1.tex
> 
> As a pdf file this is about 800 pages.  As html it generates nearly
> 600 png files and my browsers (both FireFox and Explorer) die while
> trying to render it. And the download is pretty horrendous anyway
> :( htlatex indicates a large number of errors which I simply skipped
> for this test.
> 
> So it seems that ""one big file" here is not really such a good idea.

I wouldn't care too much. tex4ht can split pages at section points (or 
in fact anywhere you like). Unfortunately, for some strange reason I do 
not get it to work with ALLPROSE. Maybe I haven't tried hard enough. And 
it was not so urgent to me.

> Running mzhtml on this file to generate MathML unfortunately results
> in an improperly formatted XML file:
> 
> http://wiki.axiom-developer.org/images/book--main--1/bookvol1m.xml

XML Parsing Error: mismatched tag. Expected: </mrow>.
Location: http://wiki.axiom-developer.org/images/book--main--1/bookvol1m.xml
Line Number 19994, Column 3:

</math>
--^

Hmm, my Firefox 1.5.0.6 doesn't like that file. :-(

> The xml file is about 3 times the size of the pdf file.
> 
> Interestingly, running the command
> 
>   htlatex bookvol1 "xhtml,jsmath" " -cmozhtf"
> 
> to produce a jsMath HTML file results in a file that is slightly
> smaller than the pdf file:
> 
> http://wiki.axiom-developer.org/images/book--main--1/bookvol1.html

Wow, that looks amazingly good. Hmm... but I think I would want colored 
backgrounds for the axiom-input and axiom-output lines.

But forget about it. If you look at bookvol1.pamphlet you see something like

\spadcommand{digits(49)}
and then we execute the command:

\spadcommand{solve(x**49-49*x**4+9 = 0,1.e-49)}
$$
\begin{array}{@{}l}
\displaystyle
\left[{x = -{0.6546536706904271136718122105095984761851224331
556}},  \right.
\\
\\
\displaystyle
\left.{x ={1.086921395653859508493939035954893289009213388763}},
   \right.
\\
\\
\displaystyle
\left.{x ={0.654653670725527173969468606613676483536148760766
1}}\right]
\end{array}
$$

instead of
\begin{axiominput}
solve(x**49-49*x**4+9 = 0,1.e-49)
\end{axiominput}
\begin{axiomoutput}
... repeat the thing above (which should be autogenerated anyway)
\end{axiomoutput}

I have no way to simply modify a .sty or .4ht file to make that coloring 
happen. That is the problem with writing plain TeX. No good markup. :-(

>> Anyway, would it be a good start to take dhmatrix. We could 
>> tex->latex it while we try to get an html out of it.
> 
> Good idea except it looks like this one works already! This document
> was one of the test files that I originally recommended to Eitan so
> perhaps he did tweak tex4ht a little more to help make this work.
> (If so, thanks Eitan. :)

So what next? Where are now the problems?

> Sage has a very nice little latex package for doing exactly
> this sort of thing (but more simply). I think we can easily
> adapt it for Axiom. If you have the Sage distribution, it is
> in the 'examples/latex-embed' directory. If you don't want
> do download and install all of Sage, then I can just send it
> to you. Also the new graphviz.sty has a similar technique that
> could even be used to run Axiom automatically as part of the
> LaTeX compile.

I remember I have seen that thing in graphviz.sty. Nevertheless, could 
you send over this SAGE file. I don't have SAGE running here.

>> The \begin{axiomoutput}{somenumber} ... \end{axiomoutput}
>> environments should simply ignore there content and set the
>> content of the file axiom.somenumber.tex.
>>
>> Doesn't sound un-doable to me.
>>
> 
> Quite doable. Now, the question is: Are Axiom developers and
> users really motivated to use this sort of thing??

Ooops. What sort of thing?

\start
Date: Tue, 22 Aug 2006 15:15:37 +0200
From: Gernot Hueber
To: Ralf Hemmecke
Subject: Re: Using ALLPROSE for SPAD programming

Hi Ralf,

On Tue, 2006-08-22 at 14:18 +0200, Ralf Hemmecke wrote:
> > First of all, I want to point out that I don't want to advocate against
> > ALLPROSE for documentation, which is in fact an interesting development
> > framework.
> > Nevertheless, my contribution do the documentation discussion is
> > non-ALLPROSE. Did you consider using an "javadoc" style for
> > documentation.
> 
> Of course. You certainly know about the +++ comments. These things have 
> been invented before Java came into existence. The only problem with 
> Aldor is that there is not yet a proper tool to make use of this data.
> 
> ALLPROSE hast \begin{+++} ... \end{+++} for that.
> 
>  > E.g. doxygen is a mature and flexible tool aimed primary
> > at C++ but extended to some more languages.
> 
> Yep, doxygen is too much tailored for C/C++. If you make it work for 
> Aldor, it might be worth another try.
> 
> But as Tim suggests, that is not the point of literate programming. LP 
> is here to express your ideas and illustrate these ideas by real (in 
> contrast to pseudo) code. So you basically write a research article (or 
> so). In that sense I fully support Tim and Knuth.
> 
> But as you can see with my \begin{+++} ... \end{+++} environments, I 
> also strongly believe that for using other peoples work it is often 
> quite sufficient if you know about the API of what that library/program 
> does on which you want to build. You do not usually want to read 
> thousands of pages and books before you are able to write one single 
> line of code.
> 
> I, for example, would be quite happy if someone writes a library for 
> factorization of multivariate polynomials in an LP style and 
> additionally gives me a short API description of what his function does 
> and how I have to call it. I am simply not interested in learning all 
> the difficult stuff about an efficient implementation and about tricks 
> in this implementation to make it even more efficient. I want to use 
> factorization. If I ever become interested in the details, I can come 
> back to that later.

I agree with you, most important is the API _together_ with a
description and examples, not the actual implementation. From my
experience far too often even the API is badly documented. In this case
a half of the story solution is much better than none at all.

> 
> So my approach in ALLPROSE is to write in an LP style and *additionally* 
> provide an API description for those who don't want to delve too deeply 
> into the details.
> 
> If you can make some tool available that supports such a combined 
> approach, I would be quite happy to see them.
> 
> But I would never sacrifice the LP approach to doxygen. Doxygen (to my 
> taste--correct me if I'm wrong) is only about the API, ie half of the 
> story -- if not less.

Yes, you are right, I am/was too much focused on the API.

Thanks for your comments. 

\start
Date: Tue, 22 Aug 2006 15:35:08 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Another question

Hi Martin,

On 08/22/2006 02:45 PM, Martin Rubey wrote:
> Ralf Hemmecke writes:
> 
>> Martin wrote:
> 
>>> why won't we use ALLPROSE?
> 
> 
>> I simply have the suspicion that Martin talks about pamphlet files of the form
>> .spad.pamphlet and anybody else means pamphlets with general content so also
>> .lisp.pamphlet or Makefile.pamphlet. Am I wrong?
> 
> Oh, yes you are right. I had only SPAD in mind. On the other hand, you do
> document your perl and Makefile stuff with ALLPROSE too, so, I guess that we
> can focus on the differences between Aldor and SPAD.

Aha. Maybe you were misled.
Maybe it is not so clear, what ALLPROSE actually is. The goal is to 
support the writing of Aldor libraries. But ALLPROSE itself is a program 
(or a collection of programs if you look deeper into it) and so it 
should also be documented properly using a LP style. That is what you 
see if you say

make include-allprose-documentation
make dvi

without the first make you only get the documentation of the library, 
and I guess most people are just happy with it, but the documentation of
ALLPROSE itself always sleeps somewhere in the background and can be 
awakened.

In some sense you are right that I would like such a system for all of 
Axiom. But for now I cannot do this since I simply do not yet understand 
the Axiom build process. You can see ALLPROSE as a small example of 
where I want to see the Axiom sources in the future. You type "make dvi" 
at the top-level and get a (probably HUGE) document that describes all 
the sources, the buildprocess and the library code (and yes, it 
describes also how "make dvi" works). But that is a big task and it has 
to fight agains lots of legacy code. I cannot simply introduce some 
conventions because they might conflict with some part of Axiom deep 
deep into the jungle (which, of course is currently undocumented). So 
first comes the documentation (or an experimentation in some 
svn-branch). But it's a super long way to go.


>> All the current pamphlet stuff is legacy code. It simply doesn't fit so
>> easily into ALLPROSE, yet making it available in an HTML form should be
>> simple enough before we go the ALLPROSE way.
> 
> OK. Although I think it would be high time to move from pamphlet files to
> ALLPROSE files. After all, nothing forces us to use all the features of
> ALLPROSE right away. The only thing we *have* to do is to transform the ++ and
> +++ bits into +++ environments, because otherwise hyperdoc won't work anymore.

Oh yes, good suggestion. But again, you speak just of the .spad.pamphlet 
files.

Anyway, you are right that all new code should follow the few simple 
guidelines that Christian and I have worked out. You can find it in 
ALLPROSE in the description of aldordoc.sty.

>> And as Bill pointed out, ALLPROSE is an environment for writing libraries. As
>> I understood, making pamphlets available as HTML has nothing to do with
>> libraries. At least not at the moment.
> 
> What? In what way is DHMATRIX different from a library?

Maybe, I am wrong, but for me DHMATRIX is just a domain. A library is 
something like libaldor, libalgebra, libaxiom.

> No no, the conventions are quite OK. No way we are going to write yet another
> SPAD parser. As far as I understand, since ALLPROSE literally copies the +++
> environment into a +++ section, there is no need to adhere to the ALLPROSE
> conventions at first.

OK. If you want. \begin{+++} ... \end{+++} should be written just in 
front of the chunk you want to document. If ALLPROSE finds a

define CategoryName(...): Category ==

or

DomainName(...): ...

in that chunk, then that corresponds to \atthistype. (And, yes Martin, 
that can be replaced on the fly by the appropriate \adtype{DomainName}, 
but that is only half of the story.)

Other types of chunks look like

foo: Type1 -> Type2;

So they should look like function of constant declarations in a with 
part. The +++ environment then is associated to the name foo.

That is not too hard. The problem only is that such a "foo" line has to 
be one line. It is an important restriction, because the whole line is 
translated into a command

\addefinename{foo: Type1 -> Type2}{...}{...}{...}

and later used to distinugish a link to that function from a link to a 
function

foo: % -> Type2

Even note that ALLPROSE allows to have two domains A and be defining the 
same function foo. One can writing \adname{foo} is ambiguous, but 
\adname[A]{foo} or even better \adname[B]{foo:%->Type2} would be more 
appropriate. Don't worry about the %. A script takes care before latex 
has a chance to see it.

\start
Date: 22 Aug 2006 15:44:15 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: Another question

Hi Ralf,

Ralf Hemmecke writes:

> Aha. Maybe you were misled.

no, I don't think so.

> In some sense you are right that I would like such a system for all of
> Axiom. [...]

Yes, but I think that converting the algebra to allprose would be a good start.

> >> And as Bill pointed out, ALLPROSE is an environment for writing
> >> libraries. As I understood, making pamphlets available as HTML has nothing
> >> to do with libraries. At least not at the moment.

> > What? In what way is DHMATRIX different from a library?
 
> Maybe, I am wrong, but for me DHMATRIX is just a domain. A library is
> something like libaldor, libalgebra, libaxiom.

I don't think there is much (formal) difference between a domain and a library.

> [...]  in that chunk, then that corresponds to \atthistype. (And, yes Martin,
> that can be replaced on the fly by the appropriate \adtype{DomainName}, 

GREAT! could you send me an appropriate patch, please. Then I can document my
guessing package with ALLPROSE.

> but that is only half of the story.)

Why?
> 
> That is not too hard. The problem only is that such a "foo" line has to be
> one line. It is an important restriction, because the whole line is
> translated into a command

I have no probelm with that. In fact, Axiom also needs it on one line. If a
definition is longer than that, you have to use _

Thus, If you want to do a super trooper thing, change the regexp in a way that
instead looking for a semicolon, it just goes on until it finds a newline
without a preceding underscore.

\start
Date: Tue, 22 Aug 2006 16:12:19 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Another question

>> Maybe, I am wrong, but for me DHMATRIX is just a domain. A library is
>> something like libaldor, libalgebra, libaxiom.
> 
> I don't think there is much (formal) difference between a domain and a library.

If one domain for you makes a library, so be it. But for me a library 
covers a certain small area. And that usually involves several domains. 
Look at our species stuff. You already see several domains in just one 
file. You would not tell me that putting each of them into a separate 
library makes much sense.

>> [...]  in that chunk, then that corresponds to \atthistype. (And, yes Martin,
>> that can be replaced on the fly by the appropriate \adtype{DomainName}, 
> 
> GREAT! could you send me an appropriate patch, please. Then I can document my
> guessing package with ALLPROSE.

>> but that is only half of the story.)

> Why?

That is the reason why it is completely unnecessary to replace 
\adthistype by \adtype{DomainName}. If you look at the generated 
.as.nw.tex file, you see that after \begin{+++} there suddenly appears 
an \addefinetype{DomainName} that you have never typed yourself. This 
command defines \adthistype. So you should be already happy.

I don't know your scenario. First of all, would it be an option for you 
to translate your code into Aldor and use libaxiom. Then I see a better 
chance for your guessing package to use ALLPROSE.

Otherwise, could you exactly specify what you want?

>> That is not too hard. The problem only is that such a "foo" line has to be
>> one line. It is an important restriction, because the whole line is
>> translated into a command
> 
> I have no probelm with that. In fact, Axiom also needs it on one line. If a
> definition is longer than that, you have to use _
> 
> Thus, If you want to do a super trooper thing, change the regexp in a way that
> instead looking for a semicolon, it just goes on until it finds a newline
> without a preceding underscore.

I don't want a such a thing, I want a semicolon. ;-)

\start
Date: 22 Aug 2006 16:20:22 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: Another question

Ralf Hemmecke writes:

> >> [...]  in that chunk, then that corresponds to \atthistype. (And, yes Martin,
> >> that can be replaced on the fly by the appropriate \adtype{DomainName},
> > GREAT! could you send me an appropriate patch, please. Then I can document my
> > guessing package with ALLPROSE.
> 
> >> but that is only half of the story.)
> 
> > Why?
> 
> That is the reason why it is completely unnecessary to replace \adthistype by
> \adtype{DomainName}. If you look at the generated .as.nw.tex file, you see that
> after \begin{+++} there suddenly appears an \addefinetype{DomainName} that you
> have never typed yourself. This command defines \adthistype. So you should be
> already happy.

No, I'm not. I need this in the generated .spad (or .as) file, i.e., here

+++   \begin{addescription}{Generates all isomorphism types.}
+++   \end{addescription}
+++   \begin{ToDo}
+++     \begin{rhx} 14-Aug-2006:
+++       It is not yet clear what the type of this function/constant
+++       should be.
+++ %
+++       In general, isomorphism types are equivalence classes of
+++       structures. It could be reasonable to say that \adthisname{}
+++       returns (unique) representatives of these classes. (The
+++       \emph{unique} is probably a though thing, since we might have no
+++       order on the input set or on $L$ in general.
+++     \end{rhx}
+++   \end{ToDo}
--#line 384 "species.as.nw"
isomorphismTypes: Set L -> Generator %;

> I don't know your scenario. First of all, would it be an option for you to
> translate your code into Aldor and use libaxiom.

No. Currently not. (No time and Aldor being non-free)

> Otherwise, could you exactly specify what you want?

I'd like to have ALLPROSE instead of \adthisname{} write
\spadfun{isomorphismTypes}. And, if possible

> > ... change the regexp in a way that instead looking for a semicolon, it
> > just goes on until it finds a newline without a preceding underscore.
> 
> I don't want a such a thing, I want a semicolon. ;-)

I know, Ralf. Me too. And I'd like to have at least a promise from Stephen Watt
and Algebra.as and SumIt.as

\start
Date: Tue, 22 Aug 2006 17:08:09 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Using ALLPROSE for SPAD programming

> To deal with pile syntax maybe we could make use of the
> SPAD to Aldor translation option built into Axiom that
> you mentioned in another thread? Even if it is not perfect,
> perhaps it is good enough to enable ALLPROSE to more easily
> extract the necessary information?

Don't leave me in the dark. Specify exactly what you want to do/achieve 
otherwise I cannot follow.

>> For compiling, we would have to change the extension .as to 
>> .spad and change calls to aldor to axiom. This is beyond my
>> knowledge of allprose though.
> 
>>From my point of view the objectives of using ALLPROSE are a
> little different than the objectives satisfied by the Axiom
> pamphlet files. As I understand it, one of the main points
> is to be able to extract the comments embedded in the Aldor/SPAD
> source code and typeset it along with other parts of the
> documentation that are just LaTeX segments of the pamphlet
> file.

Wrong. In ALLPROSE there are no places where you should write +++ or ++ 
inside code chunks. If you do it, ALLPROSE doesn't care, but such 
documentation is NEVER extracted by ALLPROSE. Instead you write the 
documentation into a \begin{+++} ...\end{+++} environment. And all that 
appears in the Latex part of the noweb file. Of course, inside that 
environment you use latex as usual, but you should not just write 
arbitrary latex, you should follow some style.

\begin{+++}
   \begin{adusage}
      -- write here aldor code to demonstrate hoe the function type
      -- is used in a common situation (kind of example code)
   \end{adusage}
   \begin{adparameters}
     % Describe here the input parameters by using
     % \adparameter{foo: A->B} instead of \item
   \end{adparameters}
   \begin{addescription}{Short docu goes here}
     Extensive documentation of the function/type
   \end{addescription}
   \begin{adexceptions}
     % Use \adthrows{SyntaxException} instead of \item to
     % describe all the exceptions this function throws.
   \end{adexceptions}
   \begin{adremarks}
     % Here you should mention exceptional stuff, maybe your function
     % works in a destructive way
   \end{adremarks}
   \begin{adseealso}
     % Give links to relates things.
   \end{adseealso}
\end{+++}

If you don't follow that convention/structure, it's also fine, but then 
it is the same as it is now. Every one invents his/her own style for the 
+++ comments and it is hard (if not impossible) to write good tools that 
handle all the various stiles.

 > And also to create appropriate hyperlinks to this stuff.
> Is that right? In that case, in the end will it be at least
> a partial replacement for the hyperdoc browser?

Right. That part of ALLPROSE aims at replacing hyperdoc. But as I said 
before, I would rather like to take a set of libraries, extract all the 
+++ comments and then produce a hyperlinked document (website or such) 
as an API description just from the libraries. No .as source code should 
be needed.

> I think we need to talk more about how this would work both
> in a stand alone desktop environment and on the Axiom Wiki.

The stand alone way, I just describe above. The Wiki way is maybe as 
simple as extracting the +++ environments and the corresponding code 
chunk and putting it together. But note, in order to get links from one 
piece of code to another you have to noweave all the files together (for 
getting links inside the codechunks) and latex them all together for 
latex taking care of the hyperlinks across different files. Maybe the 
latter could also done separately but sharing .aux files, but that is 
beyond my abilities.

\start
Date: Tue, 22 Aug 2006 11:16:39 -0400
From: Eitan Gurari
To: Bill Page
Subject: re: Another question

 > to significant, but I just did a few experiments using htlatex on
 > 
 > http://wiki.axiom-developer.org/images/book--main--1/bookvol1.tex

I tried to compile the file for native dvi latex output and was
successful only after introducing the following disabling instructions.

     \let\spadfunFrom=\empty 
     \def\spadgraph#1{} 
     \let\nwfilename=\empty 
     \long\def\nwbegincode#1\nwendcode{} 
     \long\def\moddef#1\endmoddef{}

Not sure what is the reason, unless my axiom.sty is outdated.

 > :( htlatex indicates a large number of errors which I simply skipped
 > for this test.

A compilation under htlatex shows a support problem for
\begin{list}...\end{list}. I'll need to look into this case.

 > Running mzhtml on this file to generate MathML unfortunately results
 > in an improperly formatted XML file:
 > 
 > http://wiki.axiom-developer.org/images/book--main--1/bookvol1m.xml

Quite a few problems resulting from sources similar to

    $$ 
    [{ \mbox{\rm Hue: } {22} \mbox{\rm Weight: } {1.0}} \mbox{\rm ] from
    the }  
    Dark \mbox{\rm palette}  
    $$ 

in which the fences [ and ] improperly set to take the form [...\mbox{]}.

 > The tex file is available here:
 > 
 > http://wiki.axiom-developer.org/axiom--test--1/src/algebra/DhmatrixSpad

 > Finally mzlatex gives:
 > 
 > http://wiki.axiom-developer.org/images/axiom--test--1/src/algebra/dhmatr
 > ix3.spad.xml
 > 
 > unfortunately with another xml error message:

I detected the following 5 errors.

Extra line break \\ after tabular:

    \end{tabular}\\ 
 
    We will use point vectors, planes, and coordinate frames as variables 

Three formulas similar to:

    ${^{HAND}{\bf tv}}_{\bf x}$

with implicit base for ^ (details at
http://lists.nongnu.org/archive/html/axiom-developer/2005-10/msg00233.html).


An exponent on a left parenthesis:

   $${\bf Rot(k,\theta)} = {\bf Rot(^C{\bf z},\theta)}\eqno(1.60)$$ 

\start
Date: Tue, 22 Aug 2006 11:26:17 -0400
From: Eitan Gurari
To: Ralf Hemmecke
Subject: re: Another question
Cc: Eitan Gurari

 > I wouldn't care too much. tex4ht can split pages at section points (or 
 > in fact anywhere you like). Unfortunately, for some strange reason I do 
 > not get it to work with ALLPROSE. Maybe I haven't tried hard enough. And 
 > it was not so urgent to me.

It should be easy for me to identify the reason for the problem given
a minimal miniature latex file demonstrating the problem.

\start
Date: Tue, 22 Aug 2006 11:26:54 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: re: Another question
Cc: Eitan Gurari

> Well, maybe we should start with dhmatrix. I somehow agree with you and 
> Eitan. Writing TeX should not be considered the best way of writing a 
> .pamphlet file. LaTeX is so much more structured that it is easier to 
> convert to other formats. One cannot do all the TeX tricks and outputs 
> equivalent HTML. Page numbers is one thing that you don't need in html.

can you give me an example?

\start
Date: Tue, 22 Aug 2006 17:40:30 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Another question

On 08/22/2006 04:20 PM, Martin Rubey wrote:
> Ralf Hemmecke writes:
 
>>>> [...]  in that chunk, then that corresponds to \atthistype. (And,
>>>> yes Martin, that can be replaced on the fly by the appropriate
>>>> \adtype{DomainName},

>>> GREAT! could you send me an appropriate patch, please. Then I can
>>> document my guessing package with ALLPROSE.  > but that is only
>>> half of the story.)  Why?

>> That is the reason why it is completely unnecessary to replace
>> \adthistype by \adtype{DomainName}. If you look at the generated
>> .as.nw.tex file, you see that after \begin{+++} there suddenly
>> appears an \addefinetype{DomainName} that you have never typed
>> yourself. This command defines \adthistype. So you should be
>> already happy.
 
> No, I'm not. I need this in the generated .spad (or .as) file, i.e., here
> 
> +++   \begin{addescription}{Generates all isomorphism types.}
> +++   \end{addescription}
> +++   \begin{ToDo}
> +++     \begin{rhx} 14-Aug-2006:
> +++       It is not yet clear what the type of this function/constant
> +++       should be.
> +++ %
> +++       In general, isomorphism types are equivalence classes of
> +++       structures. It could be reasonable to say that \adthisname{}
> +++       returns (unique) representatives of these classes. (The
> +++       \emph{unique} is probably a though thing, since we might have no
> +++       order on the input set or on $L$ in general.
> +++     \end{rhx}
> +++   \end{ToDo}
> --#line 384 "species.as.nw"
> isomorphismTypes: Set L -> Generator %;

Hmm, I don't understand why? The function name and its type appears at 
the bottom. So the information is there. I don't have any glue which 
(existing) tool you want to use in order to process the +++ stuff from 
the .spad or .as file. Be a bit more precise.

> I'd like to have ALLPROSE instead of \adthisname{} write
> \spadfun{isomorphismTypes}. And, if possible

Would you be happy with the \addefinename{...} thing at the beginning. I 
don't know yet whether this is easily achievable, but I have the feeling 
that it would be easier.

But still, what use is it to have that stuff inside the spad file if you 
have no tool to process it, or have you?

>>> ... change the regexp in a way that instead looking for a semicolon, it
>>> just goes on until it finds a newline without a preceding underscore.
>> I don't want a such a thing, I want a semicolon. ;-)

> I know, Ralf. Me too. And I'd like to have at least a promise from Stephen Watt
> and Algebra.as and SumIt.as

Then you should write to Stephen for compiler and libraries and to 
Stephane Dalmas for SumIt.

\start
Date: Tue, 22 Aug 2006 11:41:41 -0400
From: Tim Daly
To: Bill Page
Subject: re: Another question
Cc: Eitan Gurari

> Quite doable. Now, the question is: Are Axiom developers and
> users really motivated to use this sort of thing??

probably i am; but i can't figure out what 'this sort of thing' is.

*) what are you trying to achieve?
*) where can i see examples
*) what are the benefits/cost?
*) what tools do i need, 
*) where do i get them, 
*) how do i set them up?

\start
Date: Tue, 22 Aug 2006 17:57:19 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: re: Another question
Cc: Eitan Gurari

On 08/22/2006 05:26 PM, root wrote:
>> Well, maybe we should start with dhmatrix. I somehow agree with you and 
>> Eitan. Writing TeX should not be considered the best way of writing a 
>> .pamphlet file. LaTeX is so much more structured that it is easier to 
>> convert to other formats. One cannot do all the TeX tricks and outputs 
>> equivalent HTML. Page numbers is one thing that you don't need in html.

> can you give me an example?

I don't know exactly what example you want. First. TeX is a programming 
language and HTML is not. In latex you would write "as we have seen on 
page 67" in HTML that make no good sense. You would rather like to see a 
link to the place you are referring to.

You've probably seen the difference between TeX and LaTeX (well, I know 
LaTeX is TeX) in my recent mail.

So here I quote it again since I don't yet see it in the archive.

------
Hmm... but I think I would want colored backgrounds for the axiom-input 
and axiom-output lines.

But forget about it. If you look at bookvol1.pamphlet you see something like

\spadcommand{digits(49)}
and then we execute the command:

\spadcommand{solve(x**49-49*x**4+9 = 0,1.e-49)}
$$
\begin{array}{@{}l}
\displaystyle
\left[{x = -{0.6546536706904271136718122105095984761851224331
556}},  \right.
\\
\\
\displaystyle
\left.{x ={1.086921395653859508493939035954893289009213388763}},
   \right.
\\
\\
\displaystyle
\left.{x ={0.654653670725527173969468606613676483536148760766
1}}\right]
\end{array}
$$

instead of
\begin{axiominput}
solve(x**49-49*x**4+9 = 0,1.e-49)
\end{axiominput}
\begin{axiomoutput}
... repeat the thing above (which should be autogenerated anyway)
\end{axiomoutput}

I have no way to simply modify a .sty or .4ht file to make that coloring 
happen. That is the problem with writing plain TeX. No good markup.  :-(

Writing proper environments makes translation to other formats a lot easier.

\start
Date: Tue, 22 Aug 2006 12:08:29 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Using ALLPROSE for SPAD programming

On Tuesday, August 22, 2006 11:08 AM you wrote:
> Bill Page wrote:
> > To deal with pile syntax maybe we could make use of the
> > SPAD to Aldor translation option built into Axiom that
> > you mentioned in another thread? Even if it is not perfect,
> > perhaps it is good enough to enable ALLPROSE to more easily
> > extract the necessary information?
>
> Don't leave me in the dark. Specify exactly what you want to
> do/achieve otherwise I cannot follow.

???


On Sunday, August 20, 2006 6:55 PM Martin Rubey wrote:
> ...
> Note that a (rudimentary) converter from pile to nopile is
> included in the axiom compiler. just say
>
> (1) -> )co test.spad )tr
>    Compiling AXIOM source code from file test.spad using old
>       system  compiler.
>    Warning: translation of an old-style source code ".spad"
>       file to a new-style ".as" file changes the old system
>       compiler.
> If you wish to use the old system compiler for regular
> compilation, you must exit and re-enter AXIOM.
>    Creating output file with name test.as .
> #include "axiom.as"
>    Compiling AXIOM source code from file test.spad using old
>       system compiler.
>    TEST abbreviates package Test
>    compiling exported tst : Integer -> Integer
> --)abbrev package TEST Test
> No documentation for tst
> No documentation for tst
>
> +++
> Test(): with tst: Integer -> Integer;  == {
>         add {
>                 import from PositiveInteger;
>                 import from SingleInteger;
>                 import from String;
>                 import from OutputForm;
>                 import from NoValueMode;
>                 tst(n:Integer):Integer == {
>                     for (free i) in 1..n repeat {
>                         i = 2 => 0;
>                         output(i::OutputForm)$OutputPackage;
>                     }
>                     0;
>                 }
>                
>         }
> }
>
> Note that it makes many mistakes, but that's probably fixable.
>
> ...
> Bill Page wrote:
> > From my point of view the objectives of using ALLPROSE are a
> > little different than the objectives satisfied by the Axiom
> > pamphlet files. As I understand it, one of the main points
> > is to be able to extract the comments embedded in the Aldor/SPAD
> > source code and typeset it along with other parts of the
> > documentation that are just LaTeX segments of the pamphlet
> > file.
>
> Wrong. In ALLPROSE there are no places where you should write
> +++ or ++ inside code chunks. If you do it, ALLPROSE doesn't
> care, but such documentation is NEVER extracted by ALLPROSE.

That is a pity. It means that *somebody* has to edit 1,300
packages, domains and categories and manually extract all
that documentation. In order that it can become "proper"
documentation. :(

Wouldn't it be nice if ALLPROSE treated both occurrence
of ++ comments the same way?

Of course this same information is already extracted by the
SPAD compiler and stored in the Axiom database. This database
is what is consulted by Hyperdoc and the )sh command etc. I
wonder whether a system like ALLPROSE should also have such
a database component?

> Instead you write the documentation into a \begin{+++} ...
> \end{+++} environment. And all that appears in the Latex part
> of the noweb file. Of course, inside that environment you use
> latex as usual, but you should not just write arbitrary latex,
> you should follow some style.

Agreed. I think you might find it very interesting to study
how this was handled in the Sage project. A very large
amount of program-level documentation is coded as a LaTeX
document in the docstring of each Python module. This text
is extracted and processed by LaTeX to create the 1000+ page
reference manual and also available for online help in the
interpreter.

It is not literate programming in the style of Knuth, but
is a **lot** better than what we have sprinkled throughout
Axiom's SPAD code. And this is a project that is only two
years old...

> ...
> > And also to create appropriate hyperlinks to this stuff.
> > Is that right? In that case, in the end will it be at least
> > a partial replacement for the hyperdoc browser?
>
> Right. That part of ALLPROSE aims at replacing hyperdoc. But
> as I said before, I would rather like to take a set of libraries,
> extract all the +++ comments and then produce a hyperlinked
> document (website or such) as an API description just from the
> libraries. No .as source code should be needed.

Again I wonder about the need for a database. The web pages
on the Axiom Wiki for example are stored in the Zope Database.
This allows pages to carry additional attributes such as the
list of "parents" that define the subtopic lattice, last editor,
dates, etc. This information is being searched dynamically to
create the left sidebar navigation for the wiki. A similar
thing could be code for navigating between pages containing
literate source code. But this does require a web site interface
and does not translate easily to a printed format.

>
> > I think we need to talk more about how this would work both
> > in a stand alone desktop environment and on the Axiom Wiki.
>
> The stand alone way, I just describe above. The Wiki way is
> maybe as simple as extracting the +++ environments and the
> corresponding code chunk and putting it together.

In principle there is no reason why the Axiom Wiki could not
directly consult the Axiom database (daase files) the way
hyperdoc does now.

> But note, in order to get links from one piece of code to
> another you have to noweave all the files together (for
> getting links inside the codechunks) and latex them all
> together for latex taking care of the hyperlinks across
> different files. Maybe the latter could also done separately
> but sharing .aux files, but that is beyond my abilities.

Sometimes I wonder just how appropriate LaTeX-oriented tools
are for this task...

\start
Date: Tue, 22 Aug 2006 18:16:07 +0200
From: Ralf Hemmecke
To: Eitan Gurari
Subject: re: Another question

On 08/22/2006 05:26 PM, Eitan Gurari wrote:
> 
>  > I wouldn't care too much. tex4ht can split pages at section points (or 
>  > in fact anywhere you like). Unfortunately, for some strange reason I do 
>  > not get it to work with ALLPROSE. Maybe I haven't tried hard enough. And 
>  > it was not so urgent to me.
> 
> It should be easy for me to identify the reason for the problem given
> a minimal miniature latex file demonstrating the problem.

I believe it would, but the problem is that I cannot easily make the 
documentation smaller, because it would basically mean that I find the 
problem myself.

I cannot blame you, since the reason why it doesn't work is probably on 
my side.

If it is small enough for you, then try to get ALLPROSE 
http://www.hemmecke.de/aldor/
and type

make html     or     make colored html

But maybe, before that you should modify Makefile.nw and replace

\g@addto@macro\@documentclasshook{\RequirePackage[html,frames]{tex4ht}}

by

\g@addto@macro\@documentclasshook{\RequirePackage[html,2,frames]{tex4ht}}

What I get is a the two frames (toc and text) where the text is just two 
pages. First page just contains the title with the abstract and the 
second contains everything.

If you find time to take a look at it. It would be very appreciated.

Once you have said

make html

you can investigate the .nw.tex files manually and apply htlatex or 
whatever you find appropriate.

If you don't understand the code, just ask.

\start
Date: 22 Aug 2006 18:16:31 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: Another question

Ralf Hemmecke writes:

> > No, I'm not. I need this in the generated .spad (or .as) file, i.e., here
> > +++   \begin{addescription}{Generates all isomorphism types.}
> > +++   \end{addescription}
> > +++   \begin{ToDo}
> > +++     \begin{rhx} 14-Aug-2006:
> > +++       It is not yet clear what the type of this function/constant
> > +++       should be.
> > +++ %
> > +++       In general, isomorphism types are equivalence classes of
> > +++       structures. It could be reasonable to say that \adthisname{}
> > +++       returns (unique) representatives of these classes. (The
> > +++       \emph{unique} is probably a though thing, since we might have no
> > +++       order on the input set or on $L$ in general.
> > +++     \end{rhx}
> > +++   \end{ToDo}
> > --#line 384 "species.as.nw"
> > isomorphismTypes: Set L -> Generator %;
> 
> Hmm, I don't understand why? The function name and its type appears at the
> bottom. So the information is there. I don't have any glue which (existing)
> tool you want to use in order to process the +++ stuff from the .spad or .as
> file. Be a bit more precise.

HyperDoc processes exactly the lines preceded by +++ . So the line

  isomorphismTypes: Set L -> Generator %;

is out of reach for HyperDoc.

> > I'd like to have ALLPROSE instead of \adthisname{} write
> > \spadfun{isomorphismTypes}. And, if possible
> 
> Would you be happy with the \addefinename{...} thing at the beginning. I
> don't know yet whether this is easily achievable, but I have the feeling that
> it would be easier.

Yes, but unfortunately it wouldn't help me at all. In fact, I just discovered
that there is yet another problem: HyperDoc doesn't allow to define
environments. So I'd need some way to have \begin{addescription} replaced by
\beginaddescription and \end{addescription} by \endaddescription and so on.

Note that this kind of processing must only happen for the output to
csspecies.as.

Unfortunately, HyperDoc doesn't understand much of LaTeX...

> But still, what use is it to have that stuff inside the spad file if you have
> no tool to process it, or have you?

HyperDoc understands \newcommand.
 
> >>> ... change the regexp in a way that instead looking for a semicolon, it
> >>> just goes on until it finds a newline without a preceding underscore.  >
> >>> >> I don't want a such a thing, I want a semicolon. ;-)
> 
> > I know, Ralf. Me too. And I'd like to have at least a promise from Stephen
> > Watt and Algebra.as and SumIt.as
> 
> Then you should write to Stephen for compiler and libraries and to Stephane
> Dalmas for SumIt.

I did this many times, didn't even get an answer.

\start
Date: Tue, 22 Aug 2006 12:23:45 -0400
From: Eitan Gurari
To: Ralf Hemmecke
Subject: re: Another question

 > I believe it would, but the problem is that I cannot easily make the 
 > documentation smaller, because it would basically mean that I find the 
 > problem myself.

Yes, in the sense that the problem will be isolated and so its cause
easier to identify.  For pagination essentially one needs to find
where the sectioning commands of latex come from, and how those
commands are configured in tex4ht.

 > If it is small enough for you, then try to get ALLPROSE ...

:-(

\start
Date: Tue, 22 Aug 2006 12:35:15 -0400
From: Eitan Gurari
To: Ralf Hemmecke
Subject: re: Another question

 > instead of
 > \begin{axiominput}
 > solve(x**49-49*x**4+9 = 0,1.e-49)
 > \end{axiominput}
 > \begin{axiomoutput}
 > ... repeat the thing above (which should be autogenerated anyway)
 > \end{axiomoutput}
 > 
 > I have no way to simply modify a .sty or .4ht file to make that coloring 
 > happen. That is the problem with writing plain TeX. No good markup.  :-(
 > 
 > Writing proper environments makes translation to other formats a lot easier.

Indeed. A configuration similar to the following one, in the case of tex4ht.

   \ConfigureEnv{axiominput}
      {\HCode{<div class="axiominput">}}
      {\HCode{</div>}}
      {}{}
   \Css{div.axiominput {background-color:...;}}

\start
Date: Tue, 22 Aug 2006 18:46:36 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Using ALLPROSE for SPAD programming

>> Bill Page wrote:
>>> From my point of view the objectives of using ALLPROSE are a
>>> little different than the objectives satisfied by the Axiom
>>> pamphlet files. As I understand it, one of the main points
>>> is to be able to extract the comments embedded in the Aldor/SPAD
>>> source code and typeset it along with other parts of the
>>> documentation that are just LaTeX segments of the pamphlet
>>> file.
>> Wrong. In ALLPROSE there are no places where you should write 
>> +++ or ++ inside code chunks. If you do it, ALLPROSE doesn't
>> care, but such documentation is NEVER extracted by ALLPROSE.
> 
> That is a pity. It means that *somebody* has to edit 1,300
> packages, domains and categories and manually extract all
> that documentation. In order that it can become "proper"
> documentation. :(

Come on, if you like I'll write a 10 lines perl script that translates 
the +++ stuff into \begin{+++}..\end{+++} environments.

But there would be more to do. Take

+++ text
MyDomain: with {
     0: %;
        ++ that is a zero
     +++ This is a one.
     1: %;
     foo: () -> (); ++ and that is a foo.
} == add { ... }

In ALLPROSE that should have the format

\begin{+++}
   text
\end{+++}
<<dom: MyDomain>>=
MyDomain: with {
    <<exports: MyDomain>>
} == add {...}
@

\begin{+++}
   that is a zero
\end{+++}
%
<<exports: MyDomain>>=
0: %;
@


\begin{+++}
   This is a one.
\end{+++}
%
<<exports: MyDomain>>=
1: %;
@

\begin{+++}
   and that is a foo.
\end{+++}
%
<<exports: MyDomain>>=
foo: () -> ();
@

(OK, I guess the Perl script is going to be a bit longer.)

Now if you believe that it becomes unreadable then you forgot that we 
are actually writing in a literate programming style. All the empty 
lines above should be filled with your ideas and explain why this or 
that function is needed here or there, what your overall design is etc.

> Wouldn't it be nice if ALLPROSE treated both occurrence
> of ++ comments the same way?

NO. A strict NO. The reason is,

a) if I allow several ways for the user, he/she has to deal with several 
ways to write the documentation. Such a flexibility steepens the 
learning curve and complicates the code that has to deals with the 
extraction of the documentation

b) documentation is documentation why would you want to write +++ in 
front of each line if you can have it in a Latex environment? Code 
chunks should be code chunks, why would you want documentation inside 
it? Let's keep it simple.

c) If someone happens to write +++ comments inside code chunks ALLPROSE 
simply considers them as code (they are in a code chunk), but if you go 
all the way down, ie, compile the .spad.pamplet or .as.pamphlet file 
into a library then extract the +++ comments from the .ao files in that 
library, ALL the +++ comments are there. ALLPROSE simply doesn't use 
them while it is compiling to dvi. If you go the long way

.nw -> .as -> .ao -> (extract +++ comments) .tex -> .dvi

then everything would be there, but the result is the API description only.

> Of course this same information is already extracted by the
> SPAD compiler and stored in the Axiom database. This database
> is what is consulted by Hyperdoc and the )sh command etc. I
> wonder whether a system like ALLPROSE should also have such
> a database component?

Yep. Going the 'long way' is exactly that. But I have not yet written 
the AldorDoc tool to do the "extract +++ comments".

\start
Date: Tue, 22 Aug 2006 19:03:17 +0200
From: Ralf Hemmecke
To: Eitan Gurari
Subject: re: Another question

> I tried to compile the file for native dvi latex output and was
> successful only after introducing the following disabling instructions.
> 
>      \let\spadfunFrom=\empty 
>      \def\spadgraph#1{} 
>      \let\nwfilename=\empty 
>      \long\def\nwbegincode#1\nwendcode{} 
>      \long\def\moddef#1\endmoddef{}

Somehow it seems that you are not using "\usepackage{noweb}".
The last three commands should be defined in there.

\start
Date: Tue, 22 Aug 2006 19:08:55 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Another question

> HyperDoc processes exactly the lines preceded by +++ . So the line
> 
>   isomorphismTypes: Set L -> Generator %;
> 
> is out of reach for HyperDoc.

>>> I'd like to have ALLPROSE instead of \adthisname{} write
>>> \spadfun{isomorphismTypes}. And, if possible
>> Would you be happy with the \addefinename{...} thing at the beginning. I
>> don't know yet whether this is easily achievable, but I have the feeling that
>> it would be easier.
> 
> Yes, but unfortunately it wouldn't help me at all. In fact, I just discovered
> that there is yet another problem: HyperDoc doesn't allow to define
> environments. So I'd need some way to have \begin{addescription} replaced by
> \beginaddescription and \end{addescription} by \endaddescription and so on.
> 
> Note that this kind of processing must only happen for the output to
> csspecies.as.
> 
> Unfortunately, HyperDoc doesn't understand much of LaTeX...

I am not going to invest my time in such legacy stuff. Let HyperDoc work 
as it is now and for new code use newer technology. We have webbrowsers 
meanwhile.

\start
Date: Tue, 22 Aug 2006 13:11:43 -0400
From: Eitan Gurari
To: Ralf Hemmecke
Subject: re: Another question

 > > I tried to compile the file for native dvi latex output and was
 > > successful only after introducing the following disabling instructions.
 > > 
 > >      \let\spadfunFrom=\empty 
 > >      \def\spadgraph#1{} 
 > >      \let\nwfilename=\empty 
 > >      \long\def\nwbegincode#1\nwendcode{} 
 > >      \long\def\moddef#1\endmoddef{}
 > 
 > Somehow it seems that you are not using "\usepackage{noweb}".
 > The last three commands should be defined in there.

The file bookvol1.tex I downloaded doesn't explicitly request such a
file. I guess it should have be requested indirectly elsewhere.  -eitan

\start
Date: Tue, 22 Aug 2006 13:31:09 -0400
From: Bill Page
To: Ralf Hemmecke, Tim Daly
Subject: re: Another question

On Tuesday, August 22, 2006 9:05 AM Ralf Hemmecke wrote:
> ..
> I remember I have seen that thing in graphviz.sty.
> Nevertheless, could you send over this SAGE file. I don't
> have SAGE running here.
>

See attachment below.

> >> The \begin{axiomoutput}{somenumber} ... \end{axiomoutput}
> >> environments should simply ignore there content and set
> >> the content of the file axiom.somenumber.tex.
> >>
> >> Doesn't sound un-doable to me.
> >>
> > Bill Page wrote:
> > Quite doable. Now, the question is: Are Axiom developers
> > and users really motivated to use this sort of thing??
>
> Ooops. What sort of thing?
>

<sigh> I guess I had better try to answer this since on
Tuesday, August 22, 2006 11:42 AM Tim Daly asked:
>
> > Quite doable. Now, the question is: Are Axiom developers
> > and users really motivated to use this sort of thing??
>
> probably i am; but i can't figure out what 'this sort of thing'
> is.
>
> *) what are you trying to achieve?

1) Write pamphlet files containing embedded Axiom commands that
   generate output that becomes part of the literate programming/
   mathematics document in a collaborative wiki-based environment.

2) Search and display these document online in a web browser as
   efficient HTML/MathML/jsMath etc. PDF and DVI still seem very
   awkward in comparison to web pages although they have a more
   reliable presentation.

3) Generate hyperlinks related to program call and inheritance
   structures like ALLPROSE and hyperdoc. Browser through the
   Axiom library online.

4) Other aspects as discussed in this thread.

> *) where can i see examples

We do have some related examples:

http://wiki.axiom-developer.org/SandBoxSagePamphlet

http://wiki.axiom-developer.org/book--main--1/Endpaper3

See also the Up/Down navigation left sidebar on each Axiom
Wiki page (except FrontPage). In some case the Topic/subtopic
links reflect the structure of the Axiom library - this could
be made more so.

> *) what are the benefits/cost?

Probably 0/0. This is open source, remember?

> *) what tools do i need,
> *) where do i get them,
> *) how do i set them up?

This is open source, remember? ;) Consult the axiom-developer
email list archive. See also

http://wiki.axiom-developer.org/MathAction

(but you knew that :)

The reason why I asked: "Are Axiom developers and users really
motivated to use this sort of thing?" is because no one has
shown very much motivation so far. :( I am beginning to
seriously wonder if investing more time in better tools is
really worth the effort. It seems that we are still as stuck
in the old situation where (almost) the only people who use
the tools are the people who built them, e.g. MathAction and
ALLPROSE. And I guess what I really want to do is just that...
which is probably the reason I have been feeling so conflicted
lately.

I am amazed (and pleased) to see the amount of effort going
into the development of Sage. I am disappointed at the rate
of progress in Axiom. I worry about the delay in the open
source status of Aldor. I am disappointed that in the Sage
project I see some things that Axiom does very well being
re-invented badly. I am thinking about the best strategy for
the survival of a legacy project like Axiom when something
old made new (Sage) can attract so much interest. I am
tempted to suggest that hooking Axiom to the Sage bandwagon
as soon as possible might be the best idea. But that makes
Axiom seem subordinate when I really believe that it does
many things better even though it was designed nearly 30 years
earlier. Which rather leads off-topic, I have to admit...

Regards,
Bill Page.

--------

For an example pamphlet file on the Axiom Wiki that uses the
sagetex.sty file, see:

http://wiki.axiom-developer.org/SandBoxSagePamphlet

For stand alone use one does

  $ latex example.tex
  $ sage example.sage      <--- created by first pass
  $ latex example.tex      <--- reads output from sage

to generate the dvi file containing embedded Sage output.

Something similar is done by the graphviz.sty package but
in that case is used \write18 in order to directly issue
shell commands so the intermediate step is hidden.

-------

$cat sage-1.3.6.2/examples/latex_embed/sagetex.sty:

\RequirePackage{verbatim}

\newcounter{@sage}
\newwrite\@sagefile

\immediate\openout\@sagefile=\jobname.sage
\typeout{Writing sage input file \jobname.sage}
\immediate\write\@sagefile{import sagetex}
\immediate\write\@sagefile{sagetex.openout('\jobname.sout')}

\def\sage@out#1{
  \@namedef{@sage@\the@sage}{#1}
  \stepcounter{@sage}
}

\InputIfFileExists{\jobname.sout}{}

\setcounter{@sage}{0}

% this macro typesets the corresponding output (read from the *.sout
auxiliary file)
\def\@sage{\@bsphack%

\@ifundefined{@sage@\the@sage}{?}{\@esphack\@nameuse{@sage@\the@sage}}%
  \stepcounter{@sage}%
}

\def\sage{\@sage\@bsphack\begingroup\obeyspaces\obeylines\@@@sage}

\def\@@@sage#1{%
 \toks@{#1}%
 \immediate\write\@sagefile{sagetex.inline(\the\toks@)}%
 \endgroup\@esphack
}

\def\sageverb{\begingroup\@verbatim\frenchspacing\@vobeyspaces
 \@sage
 \immediate\write\@sagefile{sagetex.block_begin()}%
 \immediate\write\@sagefile{for _ in [1]:}%
 \def\verbatim@processline{%
   \immediate\write\@sagefile{ \the\verbatim@line}%
   \the\verbatim@line\par%
 }%
 \verbatim@start
}
\def\endsageverb{%
  \immediate\write\@sagefile{sagetex.block_end()}%
  \endtrivlist\endgroup\@doendpe
}

\def\sageblock{%
 \@bsphack\@sage
 \par\tt\vspace{3ex}\parindent 6em
 \immediate\write\@sagefile{sagetex.block_begin()}%
 \immediate\write\@sagefile{if True:}%    % hack to allow indentation
  \let\do\@makeother\dospecials
  \catcode`\^^M\active
  \@vobeyspaces  % to get actual spaces
  \def\verbatim@processline{%
    \immediate\write\@sagefile{ \the\verbatim@line}%
    \the\verbatim@line\par%
  }%
  \verbatim@start
}
\def\endsageblock{%
  \immediate\write\@sagefile{sagetex.block_end()}%
  \vspace{3ex}
  \@esphack
}

\def\sagesilent{%
 \@bsphack\@sage
 \immediate\write\@sagefile{sagetex.block_begin()}%
 \immediate\write\@sagefile{if True:}%   % hack to allow indentation
  \let\do\@makeother\dospecials
  \catcode`\^^M\active
  \@vobeyspaces  % to get actual spaces
  \def\verbatim@processline{%
    \immediate\write\@sagefile{ \the\verbatim@line}%
  }%
  \verbatim@start
}
\def\endsagesilent{%
  \immediate\write\@sagefile{sagetex.block_end()}%
  \@esphack
}

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

$cat sage-1.3.6.2/examples/latex_embed/sagetex.py:

from sage.misc.latex import latex

def openout(f):
  global _file_
  _file_=open(f,'w')

def inline(s):
  _file_.write('\sage@out{' + latex(s) + '}\n')

def block_begin():
  _file_.write('\sage@out{')

def block_end():
  _file_.write('}\n')

\start
Date: Tue, 22 Aug 2006 13:49:43 -0400
From: Bill Page
To: Eitan Gurari, Ralf Hemmecke
Subject: re: Another question

Eitan,

On Tuesday, August 22, 2006 1:12 PM you wrote:
>
>  > > I tried to compile the file for native dvi latex output and
>  > > was successful only after introducing the following disabling
>  > > instructions.
>  > >
>  > >      \let\spadfunFrom=\empty
>  > >      \def\spadgraph#1{}
>  > >      \let\nwfilename=\empty
>  > >      \long\def\nwbegincode#1\nwendcode{}
>  > >      \long\def\moddef#1\endmoddef{}
>  >
> Ralf wrote:
>  > Somehow it seems that you are not using "\usepackage{noweb}".
>  > The last three commands should be defined in there.
>
> The file bookvol1.tex I downloaded doesn't explicitly request such
> a file. I guess it should have be requested indirectly
> elsewhere.  -eitan
>

You can get the source of the version of 'axiom.sty' that is used
on axiom-developer.org here:

http://wiki.axiom-developer.org/public/axiom.sty

I believe this is the same as the version in the current Axiom source
distribution - at least it was as of last fall.

It's been a while since I looked at this, but yes it appears
that Tim has merged the noweb.sty into this file.

\start
Date: Tue, 22 Aug 2006 13:46:58 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: SAGE, Axiom, and usage

--- Bill Page wrote:

> The reason why I asked: "Are Axiom developers and users really
> motivated to use this sort of thing?" is because no one has
> shown very much motivation so far. :( I am beginning to
> seriously wonder if investing more time in better tools is
> really worth the effort. It seems that we are still as stuck
> in the old situation where (almost) the only people who use
> the tools are the people who built them, e.g. MathAction and
> ALLPROSE. And I guess what I really want to do is just that...
> which is probably the reason I have been feeling so conflicted
> lately.

There has been some usage Bill - I really like what MathAction was able
to do with that Emacs file I worked on a while back.  The primary
reason the units work isn't on MathAction yet is there isn't any code
to speak of yet.  There is other interesting code on MathAction -
Guess, for example.

I guess my first question is "What usage had you envisioned?"  A
broader audience for Axiom is going to take many years.  Most people
want to use the tool rather than work on it, and we are nowhere near
that stage as a project.  Axiom can be used to do other work, but it
doesn't look or feel like a modern program and that's going to have an
impact.  I think SAGE is getting a fair bit of attention because it
looks more "familiar" to people.  When I look at this: 
http://modular.math.washington.edu/sage/screen_shots/.html/37a.html or
http://modular.math.washington.edu/sage/screen_shots/.html/ec-soya.html
my first thought is "that looks a lot like Maple."  Now it probably
isn't all that similar when you get down to it, but that's my first
thought.  I think the SAGE project looks like it is doing some very
interesting work, but it has not yet withstood the test of time.

> I am amazed (and pleased) to see the amount of effort going
> into the development of Sage. I am disappointed at the rate
> of progress in Axiom.

At the bottom of the SAGE website is this:
"Work on SAGE is partially supported by the National Science Foundation
under Grant No. 0555776."

That helps, and being centered at a university also helps - after all,
in one sense Axiom has very few links to academia in terms of
sponsering/patronage.  Most of us have something else as our primary
responsibility, so there is less intense, focused effort on Axiom. 
Also, SAGE doesn't have to go through the process of bringing code from
thirty years ago up to modern standards, which is a lot of work and is
less "sexy".

> I worry about the delay in the open source status of Aldor.

I think this is probably the biggest single holdup.  We don't have much
serious work on SPAD code because we all think and hope it will
eventually have to become Aldor code.  We don't want to start the
SPAD->Aldor (plus actual literate documents with academic research and
theory background as opposed to source code in a pamphlet file) because
if for whatever reason Aldor DOESN'T become open source the way we need
it to be then we are back to square one, and all the Aldor based work
becomes marginalized.  Then we have to turn the SPAD compiler into
Aldor and add the improvements we need.  Statements made earlier on the
list seem to indicate that such a project might not be workable, which
would leave Axiom in a rather precarious position.  All of this
uncertainty does not help Axiom in becoming a major "player" in either
open source or academia.

> I am disappointed that in the Sage
> project I see some things that Axiom does very well being
> re-invented badly. I am thinking about the best strategy for
> the survival of a legacy project like Axiom when something
> old made new (Sage) can attract so much interest.

It's easier to start a new project than understand an old one.  At
least in the beginning.

> I am tempted to suggest that hooking Axiom to the Sage bandwagon
> as soon as possible might be the best idea.

I don't think so, personally.  SAGE is new, and has some impressive
pieces, but it's long term success is not decided.  Axiom has the hard
parts - the core mathmatical logic, the type system, the focus on
combining research and code.  We don't have the sexy GUIs and notebook
interfaces, but they will come in time.

> But that makes
> Axiom seem subordinate when I really believe that it does
> many things better even though it was designed nearly 30 years
> earlier. Which rather leads off-topic, I have to admit...

It's a long standarding problem in computers generally that newer and
prettier is always seen as better.  That's I think been due largely to
the increases in physical hardware power that people have seen, and the
benefits that provides in terms of usability.  The core designs of
software, algorithms, and systems are more timeless than that.  TeX has
been and continues to be the best typesetting solution available for
scientific papers, decades after it was written.  Despite this, it is
not as widely used as one would expect.  I think that rather than say
Axiom was designed 30 years earlier, we should say that it takes
decades to make the kind of program Axiom is and wants to become.  This
isn't Yet Another Editor - this is rocket science, the TeX of
mathematics software, if we do it right.  The space program didn't look
very sexy either early on (except a) people knew the goal was the moon
and b) rockets blowing up is more interesting than software crashes)
but everybody paid attention when it starting doing really amazing
stuff.  I think Axiom is like that - we're in the conference room
working on blackboards right now.  Drawing blueprints and looking at
the technologies we want to use, what we have available, and how it all
works together.  We'll start getting press when we start doing stuff no
one else can do, and everyone WANTS to do.  Things like being able to
answer the question "why should I trust this result" by saying "here is
a proof generated for this result that was checked in ACL2/COQ/Isabelle
and you can also either check by hand or in any of a dozen other
industrial strength proof checkers."  In the end, if we do what we are
trying to do, the question people will be asking is why would you use
anything BUT Axiom.  The problem is, that's never easy.  

\start
Date: 22 Aug 2006 23:24:37 +0200
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: SAGE, Axiom, and usage

Cliff Yapp writes:

[...]

| That helps, and being centered at a university also helps - after all,
| in one sense Axiom has very few links to academia in terms of
| sponsering/patronage.  Most of us have something else as our primary
| responsibility, so there is less intense, focused effort on Axiom. 
| Also, SAGE doesn't have to go through the process of bringing code from
| thirty years ago up to modern standards, which is a lot of work and is
| less "sexy".

How true!

| > I worry about the delay in the open source status of Aldor.
| 
| I think this is probably the biggest single holdup.  We don't have much
| serious work on SPAD code because we all think and hope it will
| eventually have to become Aldor code.

I'm starting to believe that is probably a mistake.  We should be
investing in improving the SPAD compiler.  After all, we do have an
impressive library out there to support and to improve.

[...]

| All of this uncertainty does not help Axiom in becoming a major
| "player" in either open source or academia.

For my own courses, I've been preparing materials for using Axiom as
my main vehicle for introducing students to symbolic computation.
Yesterday, I had to reconsider that decision given the many whoops to
jump through and unfavorable impression when comparedn to recent
versions of Maple or Mathematica.  Now, I'm thinking about switching
to Maple alright for this fall.  

[...]

| > I am tempted to suggest that hooking Axiom to the Sage bandwagon
| > as soon as possible might be the best idea.

I would resist the temptation to jump on the many bandwagons du jour
without more data...

[...]

| > But that makes Axiom seem subordinate

or uncertain and unfocused project.

[ rest of message I wholeheartly agree with ]

\start
Date: 22 Aug 2006 23:36:27 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: SAGE, Axiom, and usage

Gabriel Dos Reis writes:

> For my own courses, I've been preparing materials for using Axiom as my main
> vehicle for introducing students to symbolic computation.

So, may I offer you support?

\start
Date: 22 Aug 2006 23:53:14 +0200
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: SAGE, Axiom, and usage

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| > For my own courses, I've been preparing materials for using Axiom as my main
| > vehicle for introducing students to symbolic computation.
| 
| So, may I offer you support?

do you mean you have class material with Axiom as the main CAS?  

Mostly my topics include polynomial systems (of course), hybrid
numeric/symbolic techniques, algorithmic differentiation (I know
existing pakcages in Maple, and I've written some for my own uses),
geometry, etc.

\start
Date: 23 Aug 2006 00:05:11 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: SAGE, Axiom, and usage

Gabriel Dos Reis writes:

> Martin Rubey writes:
> 
> | Gabriel Dos Reis writes:
> | 
> | > For my own courses, I've been preparing materials for using Axiom as my main
> | > vehicle for introducing students to symbolic computation.
> | 
> | So, may I offer you support?
> 
> do you mean you have class material with Axiom as the main CAS?  

No, I don't teach currently. But still, maybe I can help with specific things.

Martin

> Mostly my topics include polynomial systems (of course), hybrid
> numeric/symbolic techniques, algorithmic differentiation (I know existing
> packages in Maple, and I've written some for my own uses), geometry, etc.

\start
Date: Tue, 22 Aug 2006 18:07:46 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: SAGE, Axiom, and usage

it might be possible to develop course materials using axiom
on various topics and make them available for teaching. --t

\start
Date: 23 Aug 2006 00:36:39 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: SAGE, Axiom, and usage

Tim Daly writes:

| it might be possible to develop course materials using axiom
| on various topics and make them available for teaching. --t

I agree in principle -- and that is what I tried to do.
However:
  (1) At the moment, Axiom does not look simple to build/install
      despite efforts in that direction;

  (2) the extension language seems to have a very fuzzy definition,
      when compared to other recent versions of CASes.

Particularly, with respect to (2), I have become unimpressed by the
Aldor mic-mac and the sort of self-infliged paralysis we have put
ourselves into (e.g. don't improve SPAD compiler, because something
better might come out of the blue).

I have less than a week left, so I'll try to use it as best as I can.

\start
Date: 23 Aug 2006 00:53:43 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: SAGE, Axiom, and usage

Gabriel Dos Reis writes:

>   (2) the extension language seems to have a very fuzzy definition,
>       when compared to other recent versions of CASes.
> 
> Particularly, with respect to (2), I have become unimpressed by the Aldor
> mic-mac and the sort of self-infliged paralysis we have put ourselves into
> (e.g. don't improve SPAD compiler, because something better might come out of
> the blue).

I agree, unfortunately. I'd be very very happy if it would be possible to make
SPAD understand a greater subset of Aldor. However, I have no idea how.

Thus, for the time being I write my stuff in SPAD, and I hope I write good
stuff. Meanwhile my program found quite a few -- previously unknown -- formulas
for sequences in sloanes encyclopedia :-)

If I can help with specific things, don't hesitate. I can understand your
frustration very well.

\start
Date: Tue, 22 Aug 2006 20:21:48 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: SAGE, Axiom, and usage

On Tuesday, August 22, 2006 5:25 PM Gabriel Dos Reis wrote:
> ...
> For my own courses, I've been preparing materials for using
> Axiom as my main vehicle for introducing students to symbolic
> computation.

I am sure that you do not doubt that I am a strong supporter
of Axiom, but I must say that if I were you I probably would
*not* use Axiom to introduce students to symbolic computation.

There is of course the question of what you mean by
"introduce" and about the level of sophistication (or not)
of the students. If my intention was to demonstrate
(truthfully) just how hard using a computer to do mathematics
really is, then I think Axiom might be good place to start.
But if your purpose is to give (a mostly false) impression
of how easy it is, then the Maple and Mathematica sales
literature would probably make a good handout for your first
seminar. ;)

I think that at the root of this problem is really an issue
recently addressed by Steven Watt.

Gaby would like to introduce his students to "symbolic
computation", but really Axiom (and Aldor) are not very
good at this -- by design. Axiom however does excel at
"computer algebra".

In the paper:

http://www.csd.uwo.ca/~watt/pub/reprints/2006-tc-sympoly.pdf

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.

and his talk

http://math.unm.edu/~aca/ACA/2006/Proceedings/Nonstandard/Watt_abstract.
txt

Symbolic Computation versus Computer Algebra, Stephen M. Watt,
Proc. 2006 Conference on the Applications of Computer Algebra,
(ACA 2006), June 26-29 2006, Varna, Bulgaria.

Steven presented this distinction:

"We observe that ``symbolic computation'' and ``computer algebra''
are really two different things and that neither one sufficiently
addresses the problems that arise in applications.  Symbolic
computation may be seen as working with expression trees
representing mathematical formulae and applying various rules
to transform them.  Computer algebra may be seen as developing
constructive algorithms to compute quantities in various
arithmetic domains, possibly involving indeterminates. 

Symbolic computation allows a wider range of expression, but
lacks efficient algorithms.  It is often unclear what is the
algebraic structure of a domain defined by rewrite rules.
Computer algebra admits greater algorithmic precision, but is
limited in the problems that it can model.

We argue that considerable work is still required to make
symbolic computation more effective and computer algebra
more expressive.  We use polynomials with symbolic exponents,
e.g. $x^{n^2 + n} - y^{2m}$, as an example that lies in
the middle ground and we present algorithms for their
factorization and gcd."

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

I think Steven's thesis is a philosophically hard one for
mathematicians to accept but computer scientists in general
have developed a much more refined, and at the same time more
concrete, notion of "type" and "structure" as fundamental to
computer programming. So they have an easier time to accept
this view.

Under this distinction, Mathematica, Maple, Maxima, Reduce
are *symbolic* computation systems. They are designed to
manipulate expressions in a primarily linguistic and pragmatic
manner as dictated by the underlying mathematics.

A computer algebra system on the other hand, emphasizes
structure over language. For example a polynomial in Axiom
is a specific (abstract) data structure object with certain
very specific designed-in properties and operations. It only
has a symbolic representation during input and output. It
is this metaphysical view of mathematics as dealing with
concretely realized abstract objects (as implemented in a
computer) instead of merely manipulating formal systems of
symbols, that is at the root of this debate.

As we have discussed in several different contexts, Axiom's
"Expression" domain constructor is an attempt to provide Axiom
with some (limited) symbolic computational ability. Unfortunately
it is also one of the most complex and problematic domains in
Axiom. I think the reason that this is true is directly related
to the difficulty of merging these two points of view about
computation.

So presenting students with Axiom ends up confronting them
almost immediately with this difficult and largely unresolved
problem.

> Yesterday, I had to reconsider that decision given the many
> whoops to jump through and unfavorable impression when compared
> to recent versions of Maple or Mathematica.  Now, I'm thinking
> about switching to Maple alright for this fall.

Although I am also a supporter of Maple and (at least in years
past was) quite active as a beta test volunteer during Maplesoft's
annual beta test cycles, I think choosing Maple (or Mathematica)
to introduce students to symbolic computation is also a mistake
since as commercial products they both try hard to give the
impression that this problem is solved.

>
> [...]
>
> | > I am tempted to suggest that hooking Axiom to the Sage
> ! > bandwagon as soon as possible might be the best idea.
>
> I would resist the temptation to jump on the many bandwagons
> du jour without more data...
>

Your prudence is justified, but since you must teach students
symbolic computation this fall, what should you do?

> [...]
>
> | > But that makes Axiom seem subordinate
>
> or uncertain and unfocused project.
>

I think the truth hurts. :) And that is why one is sometimes
forced to teach in a somewhat less than optimal ways.

I have been trying to understand the reasons for the apparently
phenomenal success of the Sage project. Certainly the enthusiastic
personalities of some of the principle developers such as William
Stein and David Joyner is one factor, but more importantly perhaps
is the fact that Sage seems to take a sort of "middle ground" in
this "symbolic versus algebra" debate. By choosing a dynamic
strongly typed interpreted language like Python as the underlying
glue, it can in fact straddle these two worlds. Although there
remains considerable skepticism over whether it can do so in a
sufficiently efficient manner. Certainly only a few years ago
this approach would not have been technically viable due to the
lack of sufficient computer resources to waste. But the days of
Tim Daly's "peta-computer" are fast approaching and as Axiom
developers we need to take a close look at the consequences.
I think one of the consequences is Sage.

On the other hand, I think one might reasonably characterize
the design of the programming language Aldor as an earlier
and more formally correct approach to solve the same problem.
Unfortunately for completely non-technical reasons Aldor seems
to have lost at least the first round of this fight.

\start
Date: Tue, 22 Aug 2006 20:41:01 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: Re: SAGE, Axiom, and usage

On 23 Aug 2006 00:36:39 +0200, Gabriel Dos Reis <
Gabriel Dos Reis> wrote:

> I agree in principle -- and that is what I tried to do.
> However:
>   (1) At the moment, Axiom does not look simple to build/install
>       despite efforts in that direction;



  Maybe you can use  the  Live CD or the Virtual Machine for your students
until the new build/install process is completed.

\start
Date: Tue, 22 Aug 2006 20:41:53 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: Re: SAGE, Axiom, and usage

On 8/22/06, Alfredo Portes wrote:
>
> On 23 Aug 2006 00:36:39 +0200, Gabriel Dos Reis <
> Gabriel Dos Reis> wrote:
>
> > I agree in principle -- and that is what I tried to do.
> > However:
> >   (1) At the moment, Axiom does not look simple to build/install
> >       despite efforts in that direction;
>
>
>
>   Maybe you can use  the  Live CD or the Virtual Machine for your students
> until the new build/install process is completed.
>
>
>
  Actually, thinking about it, the class notes can be included as part of
the Live CD.

\start
Date: 23 Aug 2006 02:49:48 +0200
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: SAGE, Axiom, and usage

Martin Rubey writes:

[...]

| I agree, unfortunately. I'd be very very happy if it would be
| possible to make SPAD understand a greater subset of Aldor. However,
| I have no idea how. 

I would like to see those who understand SPAD better than I do attempt
a clearer definition of the language.  I suspect it is something we
would need to do if we were to Aldor anyway, to ensure that the
translated programs continue to have the same meaning.

| Thus, for the time being I write my stuff in SPAD, and I hope I write good
| stuff. Meanwhile my program found quite a few -- previously unknown -- formulas
| for sequences in sloanes encyclopedia :-)

I believe that is a good thing!

| If I can help with specific things, don't hesitate. I can understand your
| frustration very well.

Thank you veyr much.

\start
Date: 23 Aug 2006 03:17:48 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: SAGE, Axiom, and usage

Bill Page writes:

[...]

| Gaby would like to introduce his students to "symbolic
| computation", but really Axiom (and Aldor) are not very
| good at this -- by design.

    The appearance of AXIOM in the scientific market moves symbolic
    computations into a higher plane, where scientists can formulate 
    their statements in their own language and receive computer
    assistance in their proofs. [...] AXIOM provides a powerful
    scientific environment for easy construction of mathematical tools
    and algorithms; it is a symbolic manipulation system, and a high
    performance numerical system, with full graphic capabilities.

             -- Gregory V. Chudnovsky in the Foreword of
                AXIOM, the Scientific Computation System


I suspect the authors of the book forgot to tell him that the
designers of AXIOM, by design, really did make it "not very good at
symbolic computation". 

\start
Date: Tue, 22 Aug 2006 18:23:12 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: SAGE, Axiom, and usage

--- Gabriel Dos Reis wrote:

> For my own courses, I've been preparing materials for using Axiom as
> my main vehicle for introducing students to symbolic computation.
> Yesterday, I had to reconsider that decision given the many whoops to
> jump through and unfavorable impression when comparedn to recent
> versions of Maple or Mathematica.  Now, I'm thinking about switching
> to Maple alright for this fall.  

I hate to say this, but I think Bill made a good point about Axiom
probably not being the best way to introduce folks to computer algebra.
 I myself came to Axiom only through 1st Mathematica and then Maxima. 
Looking back on it, the benefits of Axiom become more apparent when you
start to reach the limits of what other systems are easily able to
accomplish (I didn't necessarily reach mathematical limits, but
certainly units in Maxima brought up some issues that made me think
about things differently.)

I'm not a teacher (only done a few labs over the years and a bit of
tutoring) but if I were to offer a suggestion (just what you needed ;-)
I would say this:

1.  Start by introducing either Maxima using the wxMaxima interface or
perhaps Yacas.  Either of those will probably be less intimidating to
students up front, and their limitations will not be readily apparent. 
Their prior experience with calculators will map to either of these
systems reasonably well - they will most likely be less intimidated if
they don't need to comprehend what a "type" is or why it matters up
front.

2.  Develop the students by gradually exploring more of the potential
of the first system, and take them to some problems that "symbolic
computation" doesn't handle so well.  I.e., show them both the utility
of symbolic computation (which the commercial success of Mathematica
and Maple prove is considerable) and its limitations.  This is good
both for showing the limitations of the approach and also why computers
can't substitute for an educated brain.

3.  Then, later on in the course, introduce them to a more formal
approach that avoids these limitations.  Most will probably not be real
excited about this because it will look harder (being precise is always
hard work ;-) but most will probably remember and if, in the future,
they begin to do work that would benefit from Axiom's more rigorous
approach they will know both about Axiom and why it might be better.

Of course, that was easy to say and hard to do.  Just a thought, for
whatever it may be worth.

\start
Date: 23 Aug 2006 03:41:59 +0200
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: SAGE, Axiom, and usage

Cliff Yapp writes:

[...]

| I'm not a teacher (only done a few labs over the years and a bit of
| tutoring) but if I were to offer a suggestion (just what you needed ;-)
| I would say this:
| 
| 1.  Start by introducing either Maxima using the wxMaxima interface or
| perhaps Yacas.  Either of those will probably be less intimidating to
| students up front, and their limitations will not be readily apparent. 
| Their prior experience with calculators will map to either of these
| systems reasonably well - they will most likely be less intimidated if
| they don't need to comprehend what a "type" is or why it matters up
| front.

this course is at a graduate level, and many of the students have some
basic knowledge of data structures, algorithms, programming languages,
generic programming, compilers, etc.

| 2.  Develop the students by gradually exploring more of the potential
| of the first system, and take them to some problems that "symbolic
| computation" doesn't handle so well.  I.e., show them both the utility
| of symbolic computation (which the commercial success of Mathematica
| and Maple prove is considerable) and its limitations.  This is good
| both for showing the limitations of the approach and also why computers
| can't substitute for an educated brain.

You have a good point.

| 3.  Then, later on in the course, introduce them to a more formal
| approach that avoids these limitations.  Most will probably not be real
| excited about this because it will look harder (being precise is always
| hard work ;-) but most will probably remember and if, in the future,
| they begin to do work that would benefit from Axiom's more rigorous
| approach they will know both about Axiom and why it might be better.

That is an excellent observation.  I will work out some of these
constructive suggestions.  Thanks!

\start
Date: Tue, 22 Aug 2006 22:08:47 -0400
From: Tim Daly
To: Alfredo Portes
Subject: Re: SAGE, Axiom, and usage

>   (1) At the moment, Axiom does not look simple to build/install
>       despite efforts in that direction;

ummm....

export AXIOM=`pwd`/mnt/linux
make

i can't make it easier.

\start
Date: Tue, 22 Aug 2006 19:21:47 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: SAGE, Axiom, and usage

--- Gabriel Dos Reis wrote:

> this course is at a graduate level, and many of the students have
> some basic knowledge of data structures, algorithms, programming
> languages, generic programming, compilers, etc.

Opps - yes, that would make a difference.  For a minute I was back in
the undergrad physics lab showing people Mathematica again ;-).

> | This is good both for showing the limitations of the approach and
> | also why computers can't substitute for an educated brain.
> 
> You have a good point.

Thanks.  I always thought this was a weakness of high schools in
particular - they don't do a good job of explaining why the students
can't just "use the calculator all the time and skip all of this". 
Undergraduate work didn't really have that problem so much, but I still
think the allure of programs like Mathematica makes it important to
demonstrate what the problems of relying on them are.  (Ironically, it
is making a system that CAN be depended on that is one of the
directions I would like to see things head, but I do agree there are
any number of reasons for an educated human brain being indespensible.)

> | 3.  Then, later on in the course, introduce them to a more formal
> | approach that avoids these limitations.  Most will probably not be
> | real excited about this because it will look harder (being precise
> | is always hard work ;-) but most will probably remember and if, in
> | the future, they begin to do work that would benefit from Axiom's
> | more rigorous approach they will know both about Axiom and why it
> | might be better.
> 
> That is an excellent observation.  I will work out some of these
> constructive suggestions.  Thanks!

No problem - glad they made sense :-). 

\start
Date: Tue, 22 Aug 2006 20:07:42 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Axiom, SPAD, and Aldor

For those of you not on or watching the Aldor list, there was a
discussion some days ago by some of our key players about it being time
either to bring the SPAD compiler up to a standard that supports what
we need or begin a re-implementation of Aldor.  With that in mind, I
have a couple of questions:

1)  If we want to bring things up to the Aldor standard, what do we do
about literate documentation?  In the Aldor User Guide (which IIRC has
the formal Aldor language specification somewhere in the back) are the
following tidbits:

"No part of this Manual may be reproduced, transcribed, stored in a
retrieval system, translated into any language or computer language or
transmitted in any form or by any means, electronic, mechanical,
photocopying, recording or otherwise, without the prior written
permission of the copyright owner."

That would seem to rule out our incorporating this into Axiom as a
literate documentation of any sort.  In fact, if you interpret this
strongly, just downloading it and printing it seems to be an issue.  I
assume this is not what they were after but regardless we seem to be
out of luck.

I dislike the thought of drifting away from the Aldor community as far
as language goes but the above restrictions are going to make it a bit
tough to make something that is documented and compatible with Aldor. 
(In particular, if we can't reproduce the language definition in the
back, how are we supposed to formally describe the lanaguage in Axiom?)

"Aldor, AXIOM and the AXIOM logo are trademarks of NAG."

Axiom we presumably have permission to use (since we're calling our
project Axiom, after all) but Aldor we don't have permission to use so
whatever we do develop calling the result Aldor might not be the best
move.

2)  If we take SPAD as a start, use Aldor as a source of ideas, and
roll our own improvements and docs (either keeping the SPAD name or
calling it something else) that would avoide the problems above, but
that leaves the more mundane issues:  how to proceed and what actually
needs to be done/documented/designed.

3)  Whatever happened to the implementation of Aldor in Aldor that was
mentioned on the list some time back?  Was that for real and if so is
it available?

\start
Date: 23 Aug 2006 05:10:14 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: SAGE, Axiom, and usage

Tim Daly writes:

| >   (1) At the moment, Axiom does not look simple to build/install
| >       despite efforts in that direction;
| 
| ummm....
| 
| export AXIOM=`pwd`/mnt/linux
| make
| 
| i can't make it easier.

that is one definition of it :-)

\start
Date: 23 Aug 2006 05:38:53 +0200
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Axiom, SPAD, and Aldor

Cliff Yapp writes:

[...]

| Axiom we presumably have permission to use (since we're calling our
| project Axiom, after all) but Aldor we don't have permission to use so
| whatever we do develop calling the result Aldor might not be the best
| move.

I have been using, for a week now, "Bemol" as a code-name for a
language that is SPAD-like but with more defined type system and
semantics.  It is still a work-in-program a colleague and I are
conducting.  When ee find it unembarrsing enough we will send the
result here for feedback. 

\start
Date: Wed, 23 Aug 2006 15:45:25 +0200
From: Christian Aistleitner
To: Gabriel Dos Reis
Subject: Re: [Aldor-l] Using Aldor or SPAD

Hello,

> | > | I am not sure, to what extend the US law situation is reflected by
> | > | Canadian, French or British law.
> | > | However, as (I guess) most of the ppl interested in Aldor, have  
> seen
> | > | the  compiler's source code, they (probably) should not work on the
> | > | reimplementation of it.
> | >
> | > That is a very good point.  Does that also imply that you cannot
> | > answer any technical question about the *Aldor language*?
> |
> | I assume the "you" does not refer to me, but someone having seen the
> | compiler sources.
>
> well, I meant you (Christian).

ok. If its about me, I'll shift to a private discussion.

\start
Date: Wed, 23 Aug 2006 10:32:43 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: SAGE, Axiom, and usage

On August 22, 2006 11:10 PM Gabriel Dos Reis
> 
> Tim Daly writes:
> 
> | Gaby wrote:
> | >   (1) At the moment, Axiom does not look simple to
> | >       build/install despite efforts in that direction;
> | 
> | ummm....
> | 
> | export AXIOM=`pwd`/mnt/linux
> | make
> | 
> | i can't make it easier.
> 
> that is one definition of it :-)
> 

Here is another defintion:

  ./configure
  make

It works great in the Axiom Silver build_improvements branch.

\start
Date: Wed, 23 Aug 2006 11:22:54 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: SAGE, Axiom, and usage

On August 22, 2006 9:18 PM Gaby wrote:
> 
> Bill Page writes:
> 
> [...]
> 
> | Gaby would like to introduce his students to "symbolic
> | computation", but really Axiom (and Aldor) are not very
> | good at this -- by design.
> 
>     The appearance of AXIOM in the scientific market moves symbolic
>     computations into a higher plane, where scientists can formulate 
>     their statements in their own language and receive computer
>     assistance in their proofs. [...] AXIOM provides a powerful
>     scientific environment for easy construction of mathematical
>     tools and algorithms; it is a symbolic manipulation system,
>     and a high performance numerical system, with full graphic
>     capabilities.
> 
>              -- Gregory V. Chudnovsky in the Foreword of
>                 AXIOM, the Scientific Computation System
> 
> 
> I suspect the authors of the book forgot to tell him that the
> designers of AXIOM, by design, really did make it "not very good
> at symbolic computation". 
> 

Chudnovsky was not making the distinction between "symbolic
computation" and "computer algebra" that Steven Watt is making
in the papers that I cited previously. Perhaps Gaby, you were
also was using "symbolic" in this more general sense? Still I
believe that Steven's distinction is relevant and worth making
when comparing Axiom to it's alternatives.

The Chudnovsky brothers are certainly prolific and well known
mathematicians - particularly when it comes to computing pi to
high precision. I think it was great that Axiom received such
an endorsement from them.

Gregory Chudnovsky was a contemporary of Richard Jenks, one of the
original developers of Axiom.

http://en.wikipedia.org/wiki/Gregory_Chudnovsky

http://www.poly.edu/faculty/chudnowskygregory/index.php

http://www.math.poly.edu/research/gchudnovsky_publications.phtml

But one should keep in mind that in spite of a very considerable
investment by Numerical Algorithms Group in a completely new user
interface (based on Techexplorer) and extensive work on integration
of Axiom with the NAG numerical libraries, Axiom was a commercial
failure when placed in direct competition with Mathematica and
Maple from 1991 - 2001.

The quote from Chudnovsky above and in fact the entire Axiom book
from 1992 was clearly part of the marketing strategy for Axiom
at that time. I wonder what Dr. Chudnovsky would write today if
asked to compare the Axiom open source project to other open
source projects and the commercial counterparts?

\start
Date: 23 Aug 2006 18:12:47 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: SAGE, Axiom, and usage

Bill Page writes:

| On August 22, 2006 9:18 PM Gaby wrote:
| > 
| > Bill Page writes:
| > 
| > [...]
| > 
| > | Gaby would like to introduce his students to "symbolic
| > | computation", but really Axiom (and Aldor) are not very
| > | good at this -- by design.
| > 
| >     The appearance of AXIOM in the scientific market moves symbolic
| >     computations into a higher plane, where scientists can formulate 
| >     their statements in their own language and receive computer
| >     assistance in their proofs. [...] AXIOM provides a powerful
| >     scientific environment for easy construction of mathematical
| >     tools and algorithms; it is a symbolic manipulation system,
| >     and a high performance numerical system, with full graphic
| >     capabilities.
| > 
| >              -- Gregory V. Chudnovsky in the Foreword of
| >                 AXIOM, the Scientific Computation System
| > 
| > 
| > I suspect the authors of the book forgot to tell him that the
| > designers of AXIOM, by design, really did make it "not very good
| > at symbolic computation". 
| > 
| 
| Chudnovsky was not making the distinction between "symbolic
| computation" and "computer algebra" that Steven Watt is making
| in the papers that I cited previously. Perhaps Gaby, you were
| also was using "symbolic" in this more general sense? 

Yes, and as a matter of fact, I'm deeply skeptical of your previous
assertion. 
Furthermore, I'm unconvinced that Axiom will attract people if we
insist on painting it in a corner.

[...]

| Gregory Chudnovsky was a contemporary of Richard Jenks, one of the
| original developers of Axiom.

I know.

[...]

| I wonder what Dr. Chudnovsky would write today if
| asked to compare the Axiom open source project to other open
| source projects and the commercial counterparts?

you mean after Axiom has been deeply hibernating, and now has great
difficulties taking again the leadership of principled CAS?
Unless we have gotten a time-travel machine, I don't believe what is
happening to Axiom today must be retroactively used to redesign its
past foundation.

\start
Date: Wed, 23 Aug 2006 13:55:02 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: SAGE, Axiom, and usage

On August 23, 2006 12:13 PM you wrote:
> ...
> Bill Page wrote:
> | 
> | Chudnovsky was not making the distinction between "symbolic
> | computation" and "computer algebra" that Steven Watt is making
> | in the papers that I cited previously. Perhaps Gaby, you were
> | also was using "symbolic" in this more general sense? 
> 
> Yes, and as a matter of fact, I'm deeply sceptical of your
> previous assertion.

Which assertion?

1) That making the distinction drawn by Steven Watt between
   "symbolic computation" and "computer algebra" is important for
   understanding the difference between Axiom and systems like
   Mathematica and Maple.

2) That Axiom is not particularly well suited for teaching introductory
   symbolic computation.

3) That Axiom was not designed primarily to do symbolic computation
   (in the sense defined by Steven Watt) but rather to implement the
   computer algebra in a manner which today we would probably call
   and object-oriented approach.

Or was it something else that I said?

> Furthermore, I'm unconvinced that Axiom will attract people if we
> insist on painting it in a corner.
>

On the contrary, I do not think I am "painting it into a corner".
I agree with Steven Watt (I hope I am not overstating his views.)
that the proper foundation for all mathematical computation is really
the kind of computer algebra implemented by Axiom and Aldor. Pure
symbolic manipulation of expressions is just another domain
(SExpression) in Axiom. The fact that it is not particularly well
developed in Axiom is because the Axiom developers were largely
concerned with other issues. The Expression domain constructor (not
to be confused with SExpression!) in Axiom was an early and still
incomplete attempt to provide Axiom with some of the abilities to
symbolic manipulate symbolic expressions like Maple and Mathematica
while retaining some underlying general algebraic structure. It
seems clear from Steven Watt's paper that this is still "research
in progress".

> [...]
> 
> | I wonder what Dr. Chudnovsky would write today if asked to
> | compare the Axiom open source project to other open source
> | projects and the commercial counterparts?
> 
> you mean after Axiom has been deeply hibernating,

??? Axiom wasn't really "hibernating" until 2001 and it became
open source in 2003.

> and now has great difficulties taking again the leadership of
> principled CAS?

Do you think Axiom ever really had a "leadership" role? Certainly
as a research project at IBM up to about 1992 it was far ahead of
it's time in both mathematics and computer programming language
design. I know that experience with Axiom influenced the designs
of both Maple and MuPad. But I seriously doubt whether it is
possible for the Axiom open source project to regain that status.
Although I must admit the very fact that *you* are interested in
pursuing this work is very encouraging to me. :)

> Unless we have gotten a time-travel machine, I don't believe what
> is happening to Axiom today must be retroactively used to redesign
> its past foundation.
> 

Could you explain what you mean by "retroactively used to redesign
its past foundation"?

\start
Date: 23 Aug 2006 20:20:33 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: SAGE, Axiom, and usage

Bill Page writes:

| Gaby,
| 
| On August 23, 2006 12:13 PM you wrote:
| > ...
| > Bill Page wrote:
| > | 
| > | Chudnovsky was not making the distinction between "symbolic
| > | computation" and "computer algebra" that Steven Watt is making
| > | in the papers that I cited previously. Perhaps Gaby, you were
| > | also was using "symbolic" in this more general sense? 
| > 
| > Yes, and as a matter of fact, I'm deeply sceptical of your
| > previous assertion.
| 
| Which assertion?

  #  Gaby would like to introduce his students to "symbolic
  #  computation", *but really Axiom (and Aldor) are not very
  #  good at this -- by design.*

(emphasis is mine).

[...]

| > Furthermore, I'm unconvinced that Axiom will attract people if we
| > insist on painting it in a corner.
| >
| 
| On the contrary, I do not think I am "painting it into a corner".

what you said only reinforces the perception I have had since some
time now, from discussions on this list.

[...]

| > | I wonder what Dr. Chudnovsky would write today if asked to
| > | compare the Axiom open source project to other open source
| > | projects and the commercial counterparts?
| > 
| > you mean after Axiom has been deeply hibernating,
| 
| ??? Axiom wasn't really "hibernating" until 2001 and it became
| open source in 2003.

well, between 1995 (when I first heard of it, and later got
presentation by Stephen about A# at FRISCO workshops, and repeated
"conversion attempts" from colleagues -- mostly French you suspect) and
2002, nearly nothing  widely appreciated happened to Axiom -- contrast
that to other CAS on the market.  I call that deep hibernation; you
may call it differently. 2002 was when Tim came to Lyon putting Axiom
hard forward at the international workshop on open source CAS :-) 

| > and now has great difficulties taking again the leadership of
| > principled CAS?
| 
| Do you think Axiom ever really had a "leadership" role? 

As a *principled* CAS, yes.

That is different from being leader in terms of number of users or
sale. 

[...]

| > Unless we have gotten a time-travel machine, I don't believe what
| > is happening to Axiom today must be retroactively used to redesign
| > its past foundation.
| > 
| 
| Could you explain what you mean by "retroactively used to redesign
| its past foundation"?

My understanding of your comments is that "people tried to show Axiom
as competing symbolic computation systems, it fails.  Let's try to
present it as not having anything to do with that, by design."  I
don't believe Axiom's foundational and design principles can be
meaningfully understood that way.  I don't believe earlier failure had
to do with the fact that Axiom was presented a symbolic computation
system.  But I suspect all have our own religions and beliefs :-)

\start
Date: 23 Aug 2006 14:26:39 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Cannot Rename The File Erlib To NRLIB

Greetings!

Bill Page writes:

> On Friday, August 18, 2006 3:08 PM Camm Maguire wrote:
> > 
> > This one I believe is machine specific -- can I log in and
> > reproduce? (is this axiom-developer.org?)
> 
> Yes. Please do.
> 
> > 
> > In general, the easiest way for me to fix these things is to
> > work with a build atop GCL configured with --enable-debug.
> > If anyone has the time to produce such a build somewhere and
> > confirm that the error persists, then point me to it, we can
> > take care of this in short order.  I realize that everyone
> > else's time is also limited, so if this is not possible please
> > so state.
> >
> 
> No problem. Or more to the point: I understand the problem. ;)
> 
> I have built a version of Axiom using the most recent gcl-2.6.8pre
> from your CVS and Axiom source from the build-improvements branch
> of Axiom Silver with the following gcl configure options:
> 
> GCLOPTS="--enable-debug --disable-xgcl --enable-vssize=65536*2
>  --enable-statsysbfd --enable-maxpage=196*1024"
> 
> Note: This is the same version (except for --enable-debug) that
> I used to test your recent patches for the new gcl-2.6.8pre.
> 
> You should be able access it on axiom-developer.org by setting:
> 
>   $ export AXIOM=/home/page/axiom.build-improvements/mnt/linux
>   $ export PATH=$AXIOM/bin:$PATH
> 
> > > 
> > > The problem is not the 'xxx.erlib' directory as such but rather the
> > > failure to overwrite the existing 'xxx.NRLIB' directory. Something
> > > has changed in recent versions of Axiom, gcl or linux which prevents
> > > the lisp function delete-file from deleting the directory.
> > > 
> > > See details:
> > > 
> > > http://wiki.axiom-developer.org/SandBoxArrays
> > > 
> > > This is a known and annoying bug described here:
> > > 
> > > http://wiki.axiom-developer.org/302CannotRenameTheFileErlibToNRLIB
> > > 
> > > Tim believes the problem is in GCL but Camm says that aspect of GCL
> > > has not changed. We need to find a solution.
> > > 
> > > As a work-round to the problem perhaps we should modify Axiom to
> > > call
> > > 
> > >   (system "rm -r xxx.NRLIB")
> > > 
> > > before the rename?
> > > 
> 
> Here is an annotated console transcript that confirms the problem
> and also shows another problem :-(
> 
>    >> System error:
>    #p"/var/lib/plone2/main/" is not of type SEQUENCE.
> 
> --------------
> 
> In the transcript below we are logged in as the user 'plone' who
> is the owner of the directory and it's contents.
> 
>   $ AXIOMsys
> 
>                         AXIOM Computer Algebra System
>           Version: Axiom (build improvements branch) -- 2006-08-08
>                Timestamp: Monday August 21, 2006 at 17:40:41
> ------------------------------------------------------------------------
> -----
>    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) -> )cd
>    The current AXIOM default directory is /var/lib/plone2/main/
> (1) -> )cd /var/zope/var/LatexWiki
> 
>    >> System error:
>    #p"/var/lib/plone2/main/" is not of type SEQUENCE.
> 
> (1) -> )cd
>    The current AXIOM default directory is /var/lib/plone2/main/
> (1) -> )quit
>    Please enter y or yes if you really want to leave the interactive
>       environment and return to the operating system:
> yes
> 
> --------------
> 
> Darn! Another bug??
> 

You need this in patches.lisp.pamphlet:

         (setq $current-directory (truename (user-homedir-pathname))) )
 goes to

         (setq $current-directory (namestring (truename (user-homedir-pathname)))))


> Ok, forget that for now. '/var/zope/var/LatexWiki' is where the
> directory XPRIMARR.NRLIB lives. When compiling SPAD source code
> Axiom wants to replace the existing XPRIMARR.NRLIB with another
> directory called XPRIMARR.erlib. The problem seems to be that
> the gcl function that Axiom uses to do this will not even allow
> the directory XPRIMARR.NRLIB to be over written or deleted
> even though similar gcl functions can delete the individual
> files in that directory.  Try it this way:
> 
> ----------------
> 
>   $ cd /var/zope/var/LatexWiki
> 
>   $ AXIOMsys
> 
>                         AXIOM Computer Algebra System
>           Version: Axiom (build improvements branch) -- 2006-08-08
>                Timestamp: Monday August 21, 2006 at 17:40:41
> ------------------------------------------------------------------------
> -----
>    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) -> -- Check the directory and files are there
> (1) -> )sys ls XPRIMARR.NRLIB
> code.lsp  code.o  index.KAF  info  XPRIMARR.fn  XPRIMARR.lsp
> 
> (1) -> -- We can delete the individual files inside the directory
> (1) -> )lisp (mapcar 'delete-file (directory (truename
> #p"XPRIMARR.NRLIB/*"))))
> 
> Value = (T T T T T T)
> 
> (1) -> )sys ls XPRIMARR.NRLIB
> 
> (1) -> -- Now try to delete the directory itself
> (1) -> )lisp (delete-file (truename #p"XPRIMARR.NRLIB"))
> 
>    >> System error:
>    Cannot delete the file #p"/var/zope/var/LatexWiki/XPRIMARR.NRLIB".
> 
> (1) -> -- But the file priveleges says that we should be able to do
> this!
> (1) -> )sys ls -l -d XPRIMARR.NRLIB
> drwxrwxrwx    2 plone    plone        4096 Aug 21 20:20 XPRIMARR.NRLIB
> 
> (1) ->

OK, I've made delete-file remove directories, and provide an errno
explanation on failure.  In Version_2_6_8pre.

Lisp has a bit of a different idea on some of these things.
probe-file, delete-file, open-file, etc. are not supposed to work on
directories, it appears, in keeping with some olden days in which
directories were not accessible as files on the fs.  I'm too busy now
to try to provide another function, so I hope this will do.

I though you had problems renaming, not deleting?  I have not done
anything here (yet).

Also, we build xgcl now the old fashioned way, so you might not need
--disable-xgcl anymore.

Take care, and thanks so much!

> 
> ----------------
> 
> Please let me know what else I can do to help you debug this.

\start
Date: Wed, 23 Aug 2006 21:37:23 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: SAGE, Axiom, and usage

> I agree with Steven Watt (I hope I am not overstating his views.)

I heard about Symbolic Computation vs. Computer Algebra first at the 
Dagstuhl seminar http://www.dagstuhl.de/06271/ .

I must say for me I was first a bit puzzled by this distinction, but no 
matter how you name the two distinct ends there is a difference. And we 
all know that.

We are more on the structured side (computer algebra) and most other 
systems just deal with expressions (symbolic computation).

Interestingly, there was a question after his talk which started by...

   I am not sure that I understand your distinction between Symbolic
   Computation and Computer Algebra ...

It seems that people are spoiled by all the typeless systems and usually 
SC and CA are understood to be the same or CA is a subtopic of SC. I 
haven't heard before somebody putting emphasis on a distiction wrt 
structure.

I believe there is need for both ends.

And no matter how strongly typed Axiom will be, it must provide a nice 
way to deal with arbitrary expressions. But it should allow to add more 
and more structure to these expressions as the user understands the 
mathematics behind it.

\start
Date: Wed, 23 Aug 2006 15:35:55 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: SAGE, Axiom, and usage

On August 23, 2006 2:21 PM Gaby wrote:
> | > 
> | > Yes, and as a matter of fact, I'm deeply sceptical of your
> | > previous assertion.
> | 
> | Which assertion?
> 
>   #  Gaby would like to introduce his students to "symbolic
>   #  computation", *but really Axiom (and Aldor) are not very
>   #  good at this -- by design.*
> 
> (emphasis is mine).
>

Sorry. I did not mean to imply that Axiom and Aldor are not good
"by design". Certainly a lot of effort went into making Axiom
with Aldor the best possible tool for doing general mathematics by
computer. The point I was trying to make was that the basic design
of Axiom was such as to emphasise mathematical *structure* over
linguistically oriented formal symbolic computation. It is clear
from the early literature on Axiom that this was a deliberate design
choice. Other early systems being developed at the same time, such
as Reduce, took the opposite view.
 
> | 
> | On the contrary, I do not think I am "painting it into a corner".
> 
> what you said only reinforces the perception I have had since
> some time now, from discussions on this list.
>

Could you explain what you mean "the perception you have had"?
Do you mean that idea that I am (we are?) are "painting Axiom
into a corner" by emphasising how it differs from some other
systems? I don't understand why you would think that.
 
>...
> between 1995 (when I first heard of it, and later got presentation
> by Stephen about A# at FRISCO workshops, and repeated "conversion
> attempts" from colleagues -- mostly French you suspect) and 2002,
> nearly nothing widely appreciated happened to Axiom -- contrast
> that to other CAS on the market.

On the contrary this was the period of time when NAG was investing
a lot of time and money into developing Axiom as a commercial
product. An entirely new and I think potentially quite revolutionary
user interface was developed. Axiom was ported to a new lisp environment
that permitted Axiom to be delivered on Windows. And the numerical
abilities of Axiom were greatly extended. Perhaps it is true that this
is not now "widely appreciated" but I think that is only because it
turned out that NAG decided to abandon it's attempt to market this
new version of Axiom. :(

Unfortunately when first Aldor and then later Axiom were made open
source very little of the innovative work done by NAG during this
period could be made available in the open source release due to
licensing restrictions. :( :( :(

> I call that deep hibernation; you may call it differently.

Yes. I call that a "damn shame". :)

> 2002 was when Tim came to Lyon putting Axiom hard forward at the
> international workshop on open source CAS :-)

Yes. My understanding is that Mike Dewar from NAG had been looking
for someone willing to take on Axiom as open source for some time
when Tim stepped forward. Thank you Tim.

> | 
> | Could you explain what you mean by "retroactively used to redesign
> | its past foundation"?
> 
> My understanding of your comments is that "people tried to show Axiom
> as competing symbolic computation systems, it fails.  Let's try to
> present it as not having anything to do with that, by design."

I think that is an unfair assessment of my statements.

> I don't believe Axiom's foundational and design principles can be
> meaningfully understood that way.  I don't believe earlier failure
> had to do with the fact that Axiom was presented a symbolic
> computation system.

I did not say that. The reasons for Axiom's failure as a commercial
product were no doubt very different and largely non-technical.

> But I suspect all have our own religions and beliefs :-)

Yes I suppose, but what does that have to do with Axiom?

\start
Date: 23 Aug 2006 21:53:46 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: SAGE, Axiom, and usage

Ralf Hemmecke writes:

[...]

| And no matter how strongly typed Axiom will be, it must provide a nice
| way to deal with arbitrary expressions. But it should allow to add
| more and more structure to these expressions as the user understands
| the mathematics behind it.

Yes.

For the distinction is more about how types are used and viewed.  It
it more at the level of our -approach- to the subject (computattional
mathematics and logic).  I would not name weather prediction science
differently just because it uses software written in Fortran instead
of, say, Ada or vice versa.

\start
Date: 23 Aug 2006 22:11:38 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: SAGE, Axiom, and usage

Bill Page writes:

| On August 23, 2006 2:21 PM Gaby wrote:
| > | > 
| > | > Yes, and as a matter of fact, I'm deeply sceptical of your
| > | > previous assertion.
| > | 
| > | Which assertion?
| > 
| >   #  Gaby would like to introduce his students to "symbolic
| >   #  computation", *but really Axiom (and Aldor) are not very
| >   #  good at this -- by design.*
| > 
| > (emphasis is mine).
| >
| 
| Sorry. I did not mean to imply that Axiom and Aldor are not good
| "by design". Certainly a lot of effort went into making Axiom
| with Aldor the best possible tool for doing general mathematics by
| computer. The point I was trying to make was that the basic design
| of Axiom was such as to emphasise mathematical *structure* over
| linguistically oriented formal symbolic computation.

and my point is that that distinction is largely an academic exercise
in ways we approach the subject matter, and NOT a really deep one (though
it may be given substance).  And the level of a graduate course where I
would like to attract students and get them excited about the 
subject, and potential contributors, that is largely a pointless and
confusing exercise.   As a matter of fact, *there are structures* in
formal symbolic computation -- rewriting rules are seldom used bindly
without structures, nor assumptions.  It is a matter of how and when
those structures are expressed and taken advantages of.

| It is clear
| from the early literature on Axiom that this was a deliberate design
| choice. Other early systems being developed at the same time, such
| as Reduce, took the opposite view.

Clearly, Axiom emphasis structures -- that is one of the aspects I
refer to when I say "principled CAS".  However, my thesis is that it
is -paradigmic- aspect of the subject matter, not a "semantically"
different field.

| > | On the contrary, I do not think I am "painting it into a corner".
| > 
| > what you said only reinforces the perception I have had since
| > some time now, from discussions on this list.
| >
| 
| Could you explain what you mean "the perception you have had"?
| Do you mean that idea that I am (we are?) are "painting Axiom
| into a corner" by emphasising how it differs from some other
| systems? I don't understand why you would think that.

As I said, it is a perception I have had for some time, it is not a
perception given by the single message you just sent.

it is NOT a general matter of showing how different Axiom is; but it
is the matter of saying we are targetting a narrow field, with
unfocused means.

| >...
| > between 1995 (when I first heard of it, and later got presentation
| > by Stephen about A# at FRISCO workshops, and repeated "conversion
| > attempts" from colleagues -- mostly French you suspect) and 2002,
| > nearly nothing widely appreciated happened to Axiom -- contrast
| > that to other CAS on the market.
| 
| On the contrary this was the period of time when NAG was investing
| a lot of time and money into developing Axiom as a commercial
| product. An entirely new and I think potentially quite revolutionary
| user interface was developed. Axiom was ported to a new lisp environment
| that permitted Axiom to be delivered on Windows. And the numerical
| abilities of Axiom were greatly extended.

yes, but how widely was it noticed and appreciated?

| Perhaps it is true that this
| is not now "widely appreciated" but I think that is only because it
| turned out that NAG decided to abandon it's attempt to market this
| new version of Axiom. :(

we can hardly accuse NAG to stop losing money :-/

OK, I appreciate other CAS company have been more effective at
marketing that acheiving technical advances.


[...]

| > | Could you explain what you mean by "retroactively used to redesign
| > | its past foundation"?
| > 
| > My understanding of your comments is that "people tried to show Axiom
| > as competing symbolic computation systems, it fails.  Let's try to
| > present it as not having anything to do with that, by design."
| 
| I think that is an unfair assessment of my statements.
| 
| > I don't believe Axiom's foundational and design principles can be
| > meaningfully understood that way.  I don't believe earlier failure
| > had to do with the fact that Axiom was presented a symbolic
| > computation system.
| 
| I did not say that. The reasons for Axiom's failure as a commercial
| product were no doubt very different and largely non-technical.
| 
| > But I suspect all have our own religions and beliefs :-)
| 
| Yes I suppose, but what does that have to do with Axiom?

our respective beliefs of why Axiom failed.

\start
Date: 23 Aug 2006 22:30:15 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: SAGE, Axiom, and usage

Bill Page writes:

[...]

| > | Could you explain what you mean by "retroactively used to redesign
| > | its past foundation"?
| > 
| > My understanding of your comments is that "people tried to show Axiom
| > as competing symbolic computation systems, it fails.  Let's try to
| > present it as not having anything to do with that, by design."
| 
| I think that is an unfair assessment of my statements.

OK; I'm glad to hear you did not mean it that way.  Aopolgies.

\start
Date: Wed, 23 Aug 2006 16:48:31 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: SAGE, Axiom, and usage

On August 23, 2006 4:12 PM you wrote:

> ...
> my point is that that distinction is largely an academic exercise
> in ways we approach the subject matter, and NOT a really deep 
> one (though it may be given substance).

I think you are wrong. I think Steven Watt's paper provides
a very substantive example:

http://www.csd.uwo.ca/~watt/pub/reprints/2006-tc-sympoly.pdf

> And the level of a graduate course where I would like to attract
> students and get them excited about the subject, and potential
> contributors, that is largely a pointless and confusing exercise.

I disagree... but you're the teacher, not me. :)

> As a matter of fact, *there are structures* in formal symbolic
> computation -- rewriting rules are seldom used bindly without
> structures, nor assumptions.  It is a matter of how and when
> those structures are expressed and taken advantages of.
>

When you have an opportunity I would like to see you expand
on this idea. I do not clearly understand what you mean by
"structure" in this case.
 
> ... 
> | Perhaps it is true that this is not now "widely appreciated"
> | but I think that is only because it turned out that NAG
> | decided to abandon it's attempt to market this new version
> | of Axiom. :(
> 
> we can hardly accuse NAG to stop losing money :-/
>

Hmmmm... keep in mind that NAG is described as a "not-for-profit
company". But I agree that money was a factor.

http://www.nag.co.uk/about_nag.asp
 
> ... 
> our respective beliefs of why Axiom failed.
> 

I do not agree that Axiom has "failed". Lack of commercial
success should not be construed as failure in this kind of
research.

\start
Date: Wed, 23 Aug 2006 17:06:46 -0400
From: Tim Daly
To: list
Subject: Axiom and commercial success

>From my understanding NAG picked up Axiom as a way to sell their
numeric library. And when they partnered with Maple they withdrew
Axiom. The commercial success of interest is NAG's numeric library.
Axiom was just the sweetener.

Axiom succeeded commercially much more than I would have thought
since Axiom is really a research platform, not a production tool.
Amazingly, many hundreds of people paid for copies.

Having been involved with Axiom for so many years I find it interesting 
that my measure of success and other people's measures are not on the 
same scale.

I'm not interested in commercial success in any sense. A sudden
influx of money would certainly change the project and in ways that
would not necessarily be good, mostly because they would require
short term gain and thus short term focus. Nobody will fund us for
long term research. The very concept seems lost on funding sources.

Perhaps we need to re-invent the "patronage" idea from the middle ages.
Don't get me wrong, I'd love to work on Axiom full time. However,
only long-term research grants can minimize the harm.

Free and open source has given us the only method I know to conduct
really long term fundamental research outside the major universities.

My measure of success is that we conduct research into long-term
ideas such as literate computational math, provably correct 
mathematical algorithms, mathematically sound organization,
correct handling of provisos, etc.

The true measure of success is that we define, solidify, and
enhance computational science in ways that survive the next
hundred years. 

So I don't see Mathematica, Maple, Reduce, or any of the other
systems as competitors. Indeed, I don't know what it would mean
to compete since anyone trying to achieve the stated goals can
only enhance our understanding and thus help us along. Thats how
science works.

I encourage you to raise your eyes to the horizon and ignore the
rocky road under your feet.

\start
Date: 24 Aug 2006 00:00:59 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom and commercial success

Tim Daly writes:

[...]

| I encourage you to raise your eyes to the horizon and ignore the
| rocky road under your feet.

that is well put; however, the rocky road needs to be dealt with, not
just ignored.  How do you get people on board for long-term projects
when you don't make room for them to make sure they can embark on the
long journey?

\start
Date: 24 Aug 2006 00:07:31 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: SAGE, Axiom, and usage

Bill Page writes:

| Gaby,
| 
| On August 23, 2006 4:12 PM you wrote:
| 
| > ...
| > my point is that that distinction is largely an academic exercise
| > in ways we approach the subject matter, and NOT a really deep 
| > one (though it may be given substance).
| 
| I think you are wrong.  I think Steven Watt's paper provides
| a very substantive example:

it seems we have entered the traditional phase of
opinion-vs-proof-by-authority.  I guess, the best we can  do is to
postpone the discussion for more data.

[...]

| > As a matter of fact, *there are structures* in formal symbolic
| > computation -- rewriting rules are seldom used bindly without
| > structures, nor assumptions.  It is a matter of how and when
| > those structures are expressed and taken advantages of.
| >
| 
| When you have an opportunity I would like to see you expand
| on this idea. I do not clearly understand what you mean by
| "structure" in this case.

think of it as "types" in software construction.

[...]

| > our respective beliefs of why Axiom failed.
| > 
| 
| I do not agree that Axiom has "failed". Lack of commercial
| success should not be construed as failure in this kind of
| research.

when, given the many times you have blamed NAG for the impact of its
commercial failure with Axiom, I suspect you can just decree that
these aspects of the project are independent and have no impact on
each other.

How do you measure success?

\start
Date: 24 Aug 2006 00:26:32 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom and commercial success

Tim Daly writes:

[...]

| My measure of success is that we conduct research into long-term
| ideas such as literate computational math, provably correct 
| mathematical algorithms, mathematically sound organization,
| correct handling of provisos, etc.

Do you know what happened to the "Restricted Equational Derivations"
project described in

    "Representation of Inference in Computer Algebra Systems with
     Application to Intelligent Tutoring"
     T. A. Ager, R. A. Ravaglia, S. Dooley

?

\start
Date: Wed, 23 Aug 2006 15:38:17 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: re: Axiom and commercial success

--- Gabriel Dos Reis wrote:

> Tim Daly writes:
> | I encourage you to raise your eyes to the horizon and ignore the
> | rocky road under your feet.

I think the SPAD vs. Aldor question is probably the single biggest rock
at the moment.  I am very glad indeed to hear there is work on this
being done behind the scenes.

May I suggest as a constructive focus for current work that some of us
start to check out the SPAD compiler as a unit of the code and see what
might be done to start updating/polishing/figuring it out?  For myself
I couldn't even identify at the moment which parts of the code contain
the SPAD compiling system or how integrated they are with other parts
of the system.  I assume other folks have better knowledge of this, but
if we have a concrete task we can focus on it might help get this
moving in the right direction.  Gabriel, since you're working on some
of this already can you suggest constructive work that those less
skilled in the compiler arts might do to help you?  One thing which I
might be able to do something with - since there is a cmucl port out
there presumably part of that work must have gotten SPAD -> lisp
translation working on a more or less ANSI system - would figuring out
what those changes were and getting that work into the silver branch be
of some help?  Or is that kind of orthogonal to the main direction?

I don't have all that much time available, and less compiler skill, but
I would like to be able to do something more constructive and helpful
than writing emails :-).

\start
Date: Wed, 23 Aug 2006 21:28:35 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: SAGE, Axiom, and usage

Gaby,

On August 23, 2006 6:08 PM you wrote:
> | > ... [symbolic computation versus computer algebra]
> | > my point is that that distinction is largely an academic
> | > exercise in ways we approach the subject matter, and NOT
> | > a really deep one (though it may be given substance).
> | 
> | I think you are wrong.  I think Steven Watt's paper
> | provides a very substantive example:
> 
> it seems we have entered the traditional phase of
> opinion-vs-proof-by-authority.  I guess, the best we can
> do is to postpone the discussion for more data.

I did not mention Steven Watt as an appeal to authority (or did
you have some other authority in mind?) but I would be glad to
continue the discussion of his paper on this subject after you
get a chance to read it. :)

> 
> [...]
> 
> | > our respective beliefs of why Axiom failed.
> | > 
> | 
> | I do not agree that Axiom has "failed". Lack of commercial
> | success should not be construed as failure in this kind of
> | research.
> 
> when, given the many times you have blamed NAG for the impact
> of its commercial failure with Axiom,

I do not blamed NAG for the commercial failure of Axiom. I am
sorry if I have somehow given you that impression. On the
contrary I think NAG and specifically Mike Dewar was extremely
generous to agree to license Axiom as open source and also
to support the idea of making Aldor available this way. The
impact of the commercial failure has been that Axiom is now
open source. From my point of view that is a positive out come.
I regret the loss of NAG's investment in the extensions made
to Axiom when it was a commercial product, but I think that was
largely due to restrictive licensing of non-Axiom components
beyond their control.

> I suspect you can just decree that these aspects of the
> project are independent and have no impact on each other.

No. I think commercial conflict of interest has had a large
negative impact on both Axiom and Aldor. However since that
time open source has been proven as a viable alternative and
we are now in the process of recovering from these earlier
mistakes.

> 
> How do you measure success?
> 

One measure of success that makes sense to me is the number
of people who actively contribute to the improvement of Axiom.
Another measure is the number of people who actually use Axiom
in their research and/or teaching. In terms of these measures
Axiom is not (yet) a failure but I believe that we could do
much better and I am disappointed with rate of change.

\start
Date: Wed, 23 Aug 2006 22:02:17 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: Axiom and commercial success

On August 23, 2006 6:01 PM Gabriel Dos Reis wrote:
> 
> Tim Daly writes:
> | [...] 
> | I encourage you to raise your eyes to the horizon and ignore the
> | rocky road under your feet.
> 
> that is well put;

I agree.

On August 23, 2006 5:07 PM Tim also wrote:

> 
> From my understanding NAG picked up Axiom as a way to sell their
> numeric library. And when they partnered with Maple they withdrew
> Axiom. The commercial success of interest is NAG's numeric library.
> Axiom was just the sweetener.
> 

I am glad that you put it that way. :)

> .. 
> Free and open source has given us the only method I know to conduct
> really long term fundamental research outside the major universities.

Hear, hear! I enthusiastically agree. But of course many universities
also continue to contribute directly to open source. Sage, for example
is very deliberately an open source project even though it is partially
funded by a university research grant. I think Axiom could benefit
from the exposure that it would gain by association with this project.

> however, the rocky road needs to be dealt with, not just ignored.
> How do you get people on board for long-term projects when you
> don't make room for them to make sure they can embark on the long
> journey?
> 

You are right. We *must* make room for them! Most of the things I
have been doing with Axiom over the last two years have been devoted
to precisely that goal. In my opinion, Gaby, with your work on the
Axiom Silver branch you are making an important contribution to the
same goal. I strongly encourage you to continue and for others to help
when possible. What else can we do to make more room?

But your question remains: "How do you get people on board for
long-term projects ... ?" I do not know the answer.

Regards,
Bill Page.

PS. I will be silent for the next 5 days or so, not because I have
suddenly lost interest but only because I am away on a trip.

\start
Date: Thu, 24 Aug 2006 04:40:10 -0400
From: Tim Daly
To: list
Subject: Re: Axiom and commercial success

> | I encourage you to raise your eyes to the horizon and ignore the
> | rocky road under your feet.
> 
> that is well put; however, the rocky road needs to be dealt with, not
> just ignored.  How do you get people on board for long-term projects
> when you don't make room for them to make sure they can embark on the
> long journey?

Do research. I define research as "doing something nobody in the world
knows how to do". 

People can do "big research". They can pick a rock that is distant and
hard to reach like 
  * "define B natural"
  * "define a new Aldor"
  * "define 
            n
    +-    -+
    | a  b |
    | c  d |
    +-    -+
  * "merge GAP and Axiom"
  * "document the algebra in ALLPROSE""
  * "define a complete, correct type coercion graph"
  * "define an [algebra domain] <=> [relational database] isomorphism
  * "symbolically solve for points on an elliptic curve"
  * "automatically compute the complexity of axiom algorithms"
  * "build a computer algebra test suite mechanism"
  * "define an algebra <=> graph isomorphism and reduction algorithms"
  * "add higher function support (eg polylogs) globally"
  * "define a "delta-epsilon algebra"
  * "architect a classroomt textbook mechanism"
  * "automatically derive a numerically stable approximate poly algorithm"
  * "define a "numerically stable simplification" algorithm
  * "create a cluster-aware axiom"
  * "create a parallel axiom"
  * "define a group theory type hierarchy"
  * "define a chemistry type hierarchy"
  * "organize an axiom video tutorial series"
  * "automatically generate flash-based time series graphs"
  * "define infinite reals"
  * "deeply embed literate algebra"
  * "entwin ACL2 and Axiom to do proofs"
  * "do automatic literate technical paper classification"
  * "define a NIST symbolic classification"
  * "automate a general bibliography mechanism"
  * "handle wave-equation mathematics"
  * "organize an existing math topic, collect papers, make them axiom-literate"
  * "add general genetic algorithm machinery"
  * "define propositional logic in axiom"

People can do "little research"
  * "expand SExpression to accept Maple syntax"
  * "expand SPAD to handle dependent types"
  * "implement symbolic summation"
  * "implement a clifford algebra"
  * "document an algebra domain in ALLPROSE"
  * "graph the existing algebra lattice""
  * "document the axiom domain to algebra database implementation"
  * "define tools for elliptic curve algebra"
  * "automatically compute the complexity of factoring polynomials"
  * "build a computer algebra test for a domain"
  * "define a way to graph polynomial operations and do them graphically"
  * "implement polylogs"
  * "handle stress/strain using a simple "delta-epsilon algebra"
  * "implement Strang's MIT linear algebra course"
  * "hand derive a numerically stable approximate poly algorithm"
  * "derive a "numerically stable simplification" polynomial simplifier"
  * "write a cluster-aware matrix domain"
  * "write a parallel processing matrix domain"
  * "extend axiom's group theory type hierarchy"
  * "implement a chemistry domain"
  * "make an axiom video tutorial"
  * "make a flash-based time series graph"
  * "implement an infinite real domain"
  * "implement literate )compile"
  * "decorate Axiom functions with ACL2-style axioms"
  * "investigate automatic technical paper classification"
  * "organize and name existing algebra for symbolic classification"
  * "create a build-time bibliography mechanism"
  * "accept and compute with feynman diagrams"
  * "pick an existing paper, make it axiom-literate"
  * "write a simple genetic algorithm solver"
  * "make the boolean domain work right"

Axiom is an ideal research platform and we're in the first 36 years
of the collision of mathematics and computation. Somebody just handed
us 36 years and 300+ man-years of research. We have complete and
total freedom to do anything we can dream.

> when you don't make room for them to make sure they can embark on the
> long journey?

Room? I see intellectual room in every direction. I could have a team
of computational mathematicians, add a new person every month, and
never live long enough to cover the space.

If you suddenly got a job working on Axiom and were given complete
freedom to do anything you want, what would you do?

Room really isn't the issue. Time and money are.


\begin{flame}

All existing computational math platforms have suffered from the 
total lack of vision by the traditional funding sources. The 
NSF/Universities/Research Labs (traditional funding sources) used
to consider "computer math" as leading edge research. They now 
consider it a "solved problem with commercial implementations" (NSF).
Or not a good revenue stream since it won't make money this quarter (IBM).
Or a cross-discipline crevice (Universities).

Traditional funding sources, (at least in the US, the rest of the world
seems rather more rational) seem unable to understand that the science 
of computational mathematics is hardly born yet. It's like the funders
have said "Plato discovered geometry... math is complete."

The NSF has a policy that "if there is a commercial implementation we
don't fund it" and feels that Axiom has something to do with MMA and
Maple.  We are being compared with the "commercial systems" and
considered losers.

"Do not compare yourselves to others or you will become vain or bitter"

\end{flame}


Axiom is a research platform in computational mathematics.
There is no competition, commercial or otherwise.
Real science is not a commercial enterprise.
Fund it with your time and energy.

> How do you get people on board for long-term projects

I don't know what motivates people to skip sunshine and wrestle
with hard problems. I'm irish. I don't do sunshine :-).

My primary job seems to be to carry this software thru the funding
dark ages. I'd make progress quicker if I could but it takes a LOT
of time to make sure it "just works". Most of the things I'm
actually working on will take years to complete. But I'm in no hurry.

\start
Date: 24 Aug 2006 11:39:59 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Axiom and commercial success

Tim Daly writes:

| > | I encourage you to raise your eyes to the horizon and ignore the
| > | rocky road under your feet.
| > 
| > that is well put; however, the rocky road needs to be dealt with, not
| > just ignored.  How do you get people on board for long-term projects
| > when you don't make room for them to make sure they can embark on the
| > long journey?
| 
| Do research.

yes, that is what counts; and you know what counts for tenure :-)
publish or prish; get grant or perish; etc. How does one convince NSF
to spend money in a legacy codes that only one person on the planet
understands, instead of building a new shiny tool? 

Axiom is an oportunity, no doubt.

[...good list of things to do snipped...]

interestingly, I spend a good of my night on only 5 points of your
long list before I saw it.  Three of them are listed "big" and the
other 2 are "small" :-/

| Room really isn't the issue. Time and money are.

Yes, that is part of what I call "room".  If we narrow sufficiently
the window for Axiom to shoot at the nearest target (e.g. "computer
algebra systems") we probably would have something for the immediat
future. I'm however less convinced that window is sufficient enough to
attract people that might contribute to many points on your list, and
attract fundings...

| \begin{flame}
| 
| All existing computational math platforms have suffered from the 
| total lack of vision by the traditional funding sources. The 
| NSF/Universities/Research Labs (traditional funding sources) used
| to consider "computer math" as leading edge research. They now 
| consider it a "solved problem with commercial implementations" (NSF).
| Or not a good revenue stream since it won't make money this quarter (IBM).
| Or a cross-discipline crevice (Universities).

That is a real concern for those of us in the US.

| Traditional funding sources, (at least in the US, the rest of the world
| seems rather more rational) seem unable to understand that the science 
| of computational mathematics is hardly born yet. It's like the funders
| have said "Plato discovered geometry... math is complete."
| 
| The NSF has a policy that "if there is a commercial implementation we
| don't fund it" and feels that Axiom has something to do with MMA and
| Maple.  We are being compared with the "commercial systems" and
| considered losers.

still; from time to time I see fundings for projcts "similar" in nature...

| "Do not compare yourselves to others or you will become vain or bitter"
| 
| \end{flame}
| 
| 
| Axiom is a research platform in computational mathematics.
| There is no competition, commercial or otherwise.
| Real science is not a commercial enterprise.
| Fund it with your time and energy.

I need to feed my family too :-)

| > How do you get people on board for long-term projects
| 
| I don't know what motivates people to skip sunshine and wrestle
| with hard problems. I'm irish. I don't do sunshine :-).
| 
| My primary job seems to be to carry this software thru the funding
| dark ages. I'd make progress quicker if I could but it takes a LOT
| of time to make sure it "just works". Most of the things I'm
| actually working on will take years to complete. But I'm in no hurry.

tenure-track has a clock ;-p

\start
Date: 24 Aug 2006 12:04:31 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: SAGE, Axiom, and usage

Bill Page writes:

| Gaby,
| 
| On August 23, 2006 6:08 PM you wrote:
| > | > ... [symbolic computation versus computer algebra]
| > | > my point is that that distinction is largely an academic
| > | > exercise in ways we approach the subject matter, and NOT
| > | > a really deep one (though it may be given substance).
| > | 
| > | I think you are wrong.  I think Steven Watt's paper
| > | provides a very substantive example:
| > 
| > it seems we have entered the traditional phase of
| > opinion-vs-proof-by-authority.  I guess, the best we can
| > do is to postpone the discussion for more data.
| 
| I did not mention Steven Watt as an appeal to authority (or did
| you have some other authority in mind?) but I would be glad to
| continue the discussion of his paper on this subject after you
| get a chance to read it. :)

I read it; I don't know why you thought I did not :-)
As I said, we may might have to suspend the debate for more data.

[...]

| > How do you measure success?
| > 
| 
| One measure of success that makes sense to me is the number
| of people who actively contribute to the improvement of Axiom.
| Another measure is the number of people who actually use Axiom
| in their research and/or teaching. In terms of these measures
| Axiom is not (yet) a failure but I believe that we could do
| much better and I am disappointed with rate of change.


My first approximation of success is the number of users.  The number
of contributors, to me, is essentially secondary -- as long as it is
not close to zero.  

\start
Date: 24 Aug 2006 12:30:12 +0200
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: spad: language and compiler

[ I added my colleague Jaakko in CC: as he is not on axiom lists. ]

Cliff Yapp writes:

| --- Gabriel Dos Reis wrote:
| 
| > Tim Daly writes:
| > | I encourage you to raise your eyes to the horizon and ignore the
| > | rocky road under your feet.
| 
| I think the SPAD vs. Aldor question is probably the single biggest rock
| at the moment.  I am very glad indeed to hear there is work on this
| being done behind the scenes.
| 
| May I suggest as a constructive focus for current work that some of us
| start to check out the SPAD compiler as a unit of the code and see what
| might be done to start updating/polishing/figuring it out?  For myself
| I couldn't even identify at the moment which parts of the code contain
| the SPAD compiling system or how integrated they are with other parts
| of the system.  I assume other folks have better knowledge of this, but
| if we have a concrete task we can focus on it might help get this
| moving in the right direction.  Gabriel, since you're working on some
| of this already can you suggest constructive work that those less
| skilled in the compiler arts might do to help you?  One thing which I
| might be able to do something with - since there is a cmucl port out
| there presumably part of that work must have gotten SPAD -> lisp
| translation working on a more or less ANSI system - would figuring out
| what those changes were and getting that work into the silver branch be
| of some help?  Or is that kind of orthogonal to the main direction?
| 
| I don't have all that much time available, and less compiler skill, but
| I would like to be able to do something more constructive and helpful
| than writing emails :-).
| 
| Cheers,
| CY


First of, thanks for your constructive suggestions.

I suspect one of the problem we need to solve is why we would want to
move to Aldor.  I mean, what is missing from SPAD that Aldor fixes and
that makes life easier to add new libraries to Axiom?  Surely people
woudl like to Aldor to have more.  What?

I know Martin has examples for dependent types.  Are those the only
things we are missing?  

My take is that the improvement to the SPAD compiler, first, needs to
be driven by needs we have for writing Axiom libraries.


We need a clearer type system and semantics description -- this
independently of whether we convert to Aldor or not.

Jaakko and I are interested in the dependent type system aspect, and
exploration of the notion of "concepts" (read mathematical structures)
as way to design generic and resuable libraries -- the bedrock of
Axiom.  Notice that aspect is mostly from -software engineering- point
of view (a problem that many mathematical software seem to suffer
from).  So that work is at the frontier of "applied type systems" --
so not hardcore computational algebra.  I think that is alright, since
most of Axiom developers and users are more concerned with
computational math than obscure compiler technicalities, and Axiom
needs that to be solved.  We settled on exploring the "B natural"
language.  For initial exploratory purpose, I simplified many points
and call the resulting language "Bemol". 

If people can look at the existing Axiom libraries (of planned libraries)
souces and say what they would like to express _directly_ -- assuming they
had the linguistic constructs -- that would help us shape directions
for the SPAD language and compiler.  It is important we aim at "ideal
expression", not just limited to what the current SPAD or Aldor
languages accept (hi Martin, Ralf).

Of course, we have gotten the lisp problem.  I don't volunteer to
attack that one yet.  :-/  However, I have the desire to target not
just Lisp, but C, C++ and probably Java or C#.  There are interesting
problems lurking there, but not none that is urgent. 

We need a clearer object model.  Currently, one has to read many boot
and lisp files in src/interp to start getting a little bit of sense of
what is going on.  I suspect the object model goes hand in hand with
the type system.

Thanks,

\start
Date: 24 Aug 2006 13:16:56 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: spad: language and compiler
Cc: Jaakko Jarvi

Gabriel Dos Reis writes:

> I know Martin has examples for dependent types.  Are those the only things we
> are missing?

Yes:

* types being first class objects, i.e., being able to have a list of Rings.

Examples:

f(m: INT, n: INT): PF n == m::PF(n)

[f(100, n) for n in primes(1,100)]

L := [PF(n) for n in primes(1,100)]

[a::P for P in L]

> My take is that the improvement to the SPAD compiler, first, needs to be
> driven by needs we have for writing Axiom libraries.

If we had dependent types, we could get rid of "Any" in the series
operations. If we have both of the above, Combinat will work in Axiom.

By the way, I think it is more important to make the interpreter understand
these things. Since:

* it would maybe be easier, I guess 

* we have to do it anyway: having the compiler understand won't help since we
                           couldn't use it in the interpreter

                           the aldor interpreter doesn't work too well

* we could use aldor meanwhile

* it will help us understand the issues involved, I guess


> We need a clearer type system and semantics description -- this independently
> of whether we convert to Aldor or not.

As far as I know, the SPAD implementation does not "conflict" with the Aldor
language. I.e., those concepts that are present work just as specified in the
Aldor User Guide.

So, this amounts to clarifying the Aldor User guide. Quite a bit of work has
been done on this side. Consult the archives or ask specific questions on
aldor-devel.

> Jaakko and I are interested in the dependent type system aspect, 

great!

> If people can look at the existing Axiom libraries (of planned libraries)
> souces and say what they would like to express _directly_ -- assuming they
> had the linguistic constructs -- that would help us shape directions for the
> SPAD language and compiler.

I think, that the series stuff in the algebra(SPAD) library and our species
stuff serve as very good examples for the things I personally would like to
have. I would really like you to start on that one :-)

BTW, I think that there is no SPAD language, only a SPAD implementation. There
is however an Aldor language (more or less) and an Aldor
implementation. Fortunately, the SPAD implementation implements a subset (in
some sense) of the Aldor language.

> It is important we aim at "ideal expression", not just limited to what the
> current SPAD or Aldor languages accept (hi Martin, Ralf).

I think that we first need to explore the possibilities of the Aldor language
before we embark to modify it. When we do, I think the thesis of Nic Doye is a
good starting point, as well as FOCAL by Renaud Rioboo and THEOREMA by
Buchberger et al.,

> Of course, we have gotten the lisp problem.  I don't volunteer to
> attack that one yet.  :-/  

for the interpreter I guess that this is nearly a must (or was it BOOT?).Unless
you rewrite it from scratch. In this case, Aldor would be a natural choice, I
guess. Christian has a parser written in Aldor, but you know that.

> However, I have the desire to target not just Lisp, but C, C++ and probably
> Java or C#.  There are interesting problems lurking there, but not none that
> is urgent.

So, that's a point for FOAM :-)

\start
Date: Thu, 24 Aug 2006 13:50:09 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: spad: language and compiler
Cc: Jaakko Jarvi

> f(m: INT, n: INT): PF n == m::PF(n)
> 
> [f(100, n) for n in primes(1,100)]

Ask yourself, what type that list will have and you realise that Aldor 
will reject that its compilation.

> L := [PF(n) for n in primes(1,100)]

That is fine, though.

> [a::P for P in L]

That is as problematic as the first list.

> So, this amounts to clarifying the Aldor User guide. Quite a bit of work has
> been done on this side. Consult the archives or ask specific questions on
> aldor-devel.

aldor-l@aldor.org to be precise.

> BTW, I think that there is no SPAD language, only a SPAD implementation.

That's a good one. There is an implementation of a non-language. How 
could someone have implemented that?

>> It is important we aim at "ideal expression", not just limited to what the
>> current SPAD or Aldor languages accept (hi Martin, Ralf).

I am all with you, Gaby, As you know, I would like to see support for 
formal specification inside the language. An Aldor program should allow 
to be fed to a proof checker, so I would like to be able to express 
invariants and all that stuff formally and not just in the documentation.

>> However, I have the desire to target not just Lisp, but C, C++ and probably
>> Java or C#.  There are interesting problems lurking there, but not none that
>> is urgent.
> 
> So, that's a point for FOAM :-)

I also think so. You can completely forget about Aldor if you just want 
to generate different target languages. That is as I understand the foam 
business.

\start
Date: 24 Aug 2006 14:38:19 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: spad: language and compiler
Cc: aakko Jarvi,


> > f(m: INT, n: INT): PF n == m::PF(n)
that's OK.

> > [f(100, n) for n in primes(1,100)]
that's stupid.

> Ask yourself, what type that list will have and you realise that Aldor will
> reject that its compilation.
Excuse me, Gaby. Sorry about being so stupid.


> > [a::P for P in L]
> That is as problematic as the first list.
"problematic" is an understatement. Sorry.

> > BTW, I think that there is no SPAD language, only a SPAD implementation.
> 
> That's a good one. There is an implementation of a non-language. How could
> someone have implemented that?

Quite unbelievable, isn't it? (Maybe I'm being too critical though. I wouldn't
call Basic a "language" in the sense I'm trying to establish here. I probably
should have said: specification)

\start
Date: 24 Aug 2006 11:57:53 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)
Cc: Gordon Novak

Greetings!  Hope you got my last message regarding the directory
deletion fixes, etc.

Bill Page writes:

> Camm,
> 
> Thanks Camm! My test build just completed using the option
> 
> --disable-xgcl
> 
> On August 18, 2006 5:26 PM you wrote:
> > 
> > OK, this one is my fault, as I fogot we were still using EXTRAS
> > in the makefile here.  2.6.8pre incorporates Gordon Novak's xgcl,
> > and the way I build it was using compiler::link from within lisp
> > as it was simpler.  This overrides EXTRAS at the very end, as it
> > copies the compiler::link generated saved_xgcl over the saved_gcl
> > left by unixport/makefile.
> > 
> > I'll probably have to revert this and do xgcl the old fashioned
> > way.
> 
> I am not sure that it continues to make sense to support the old
> "EXTRAS" method of linking external libraries. Does any gcl-based
> software use this besides the "standard" Axiom distribution? Since
> this method is not used of Axiom on Debian and on BSD, I think it
> would make sense to move as soon as possible to using compiler::link
> on all the other systems.

Well, for this reason, and to work around a current Debian ia64 gprof
problem, I'm building xgcl now via the makefiles, at least for the
moment. 

> 
> Is there any advantage to enabling xgcl in Axiom in any case? Would
> it change Axiom's user interface? Have you tried this on the Debian
> build where it does not have to be disabled?
> 

It is a very nice, light xwindows interface if you want to use it.
Most people now use a higher level toolkit built on top, such as gtk.
There are lisp wrappers for these, but not incorporated yet, and
likely will remain so unless someone is really using them.

\start
Date: 24 Aug 2006 20:31:20 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: NULL_OR_ON_C_STACK macro invalid (was: noweb)

Greetings!  Just going through old mail -- can we use expanded
maxpages now?

Take care,

Bill Page writes:

> On Thursday, August 10, 2006 4:05 PM I wrote: 
> 
> > ... 
> > I edited the GCLOPTS in Makefile from
> >   --enable-maxpage=256*1024
> > to
> >   --enable-maxpage=196*1024
> > resulting in
> > 
> >   GCLOPTS=--enable-vssize=65536*2 --enable-statsysbfd \
> >           --enable-maxpage=196*1024
> > 
> 
> Of course what I really and meant to write was:
> 
>   I edited the GCLOPTS in Makefile.pamphlet from
>     --enable-maxpage=256*1024
>   to
>     --enable-maxpage=196*1024
>   ...

\start
Date: 25 Aug 2006 12:37:59 -0400
From: Camm Maguire
To: Robert Dodier
Subject: Misc. re: 2.6.7

Greetings, and thank you so much for your very valuable reports in
email and on the web!  Please excuse the sluggishness of my reply
mechanism :-).

si::newline is a funtion which currently appears unused in the
debugging code.  Several functions in this file appear to have been in
progress when some interruption intervened, possibly the death of
Dr. Schelter.

I believe the whitespace issue is resolved in 2.6.8pre.  Please test
if you have a moment.

export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl

Please note that the Debian package of 2.6.7 (currently 2.6.7-18) is a
2.6.8pre cvs snapshot for autobuilder testing purposes. 

The large number segfault issue has also been resolved in 2.6.8pre,
though the division takes essentially forever.  In 2.7.0, we use gmp's
gcd for bignums, so your example finishes in seconds.  Given the time
2.7.0 is taking, perhaps it is worth migrating this one feature back
into 2.6.8.  Comments most welcome.  I know that the axiom people had
patches contributed doing essentially the same thing in the past.
There are many other gmp enhancements in 2.7, but I don't have time to
maintain two branches in this manner.

Regarding the windows gazonk files issue, as I do not have access to
such a machine, could one please check the variable
compiler::*keep-gaz*?  These files are supposed to be deleted
automatically unless this is set.  When using the
--enable-gcl-alt-link mechanism in maxima, this is (should be)
temporarily set to capture certain automatically compiled objects
in maxima, but it should not be left on in the final image.

The *read-base* error I've just fixed in 2.6.8pre by backporting a
function from cvs head.  In general, if you are in the mood, testing
with cvs head might be useful, though be warned much has changed and
is changing.

Are these all of our issues outstanding?  Someday, I'll figure out how
I can control that silly website from emacs, but for now I'll get to
closing those items soon.  If you feel in the mood and agree with the
expalnations here, please feel free to do so yourself.

\start
Date: 27 Aug 2006 01:10:10 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] GCL-2.6.7 is history

Hi,

  with this, we no longer have to care about GCL-2.6.7 -- as we still
have gcl-2.6.8pre.tgz.

-- Gaby
2006-08-26  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet (GCLVERSION): Remove support for 2.6.7.

lsp/
2006-08-26  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet: Remove support for 2.6.7.

zips/
2006-08-26  Gabriel Dos Reis  Gabriel Dos Reis

	* gcl-2.6.8pre.configure.in.patch: Delete.
	* gcl-2.6.8pre.configure.patch: Likewise.

	* gcl-2.6.7.tgz: Delete.
	* gcl-2.6.7.configure.in.patch: Likewise.
	* gcl-2.6.7.h.linux.defs.patch: Likewise.
	* gcl-2.6.7.unixport.init_gcl.lsp.in.patch: Likewise.
	* gcl-2.6.7.unixport.makefile.patch: Likewise.

*** Makefile.in	(revision 15809)
--- Makefile.in	(local)
*************** SPD=$(shell pwd)
*** 42,48 ****
  SYS=$(notdir $(AXIOM))
  SPAD=${SPD}/mnt/${SYS}
  LSP=${SPD}/lsp
- #GCLVERSION=gcl-2.6.7
  GCLVERSION=gcl-2.6.8pre
  GCLDIR=${LSP}/${GCLVERSION}
  SRC=${SPD}/src
--- 42,47 ----
*** Makefile.pamphlet	(revision 15809)
--- Makefile.pamphlet	(local)
*************** lsp/Makefile.pamphlet file and get the c
*** 850,856 ****
  forget to erase the lsp/Makefile the wrong patches will be applied.
  
  <<GCLVERSION>>=
- #GCLVERSION=gcl-2.6.7
  GCLVERSION=gcl-2.6.8pre
  @
  
--- 850,855 ----
*** lsp/Makefile.pamphlet	(revision 15809)
--- lsp/Makefile.pamphlet	(local)
*************** variable and move them up to the top lev
*** 44,65 ****
  	echo '(progn (load "cmpnew/gcl_collectfn.lsp") (load "lsp/sys-proclaim.lisp") (compiler::emit-fn t) (system::save-system "${OUT}/lisp"))' | unixport/saved_gcl )
  @
  
! \section{Gnu Common Lisp 2.6.7}
! There is a typo in configure.in that is only detected under some
! versions of bash. The problem is a missing single-quote mark.
! <<gcl-2.6.7.configure.in.patch>>=
! 	@(cd ${GCLVERSION} ; \
! 	  echo 28a applying configure.in patch ; \
! 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.configure.in.patch )
! @
! <<gcl-2.6.7.socket.patch>>=
! 	@(cd ${GCLVERSION}/h ; \
! 	  echo 3 applying EXTRAS patch to h/linux.defs ; \
! 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.h.linux.defs.patch )
! 	@(echo 4 setup ini files for EXTRAS patch ; \
! 	  touch ${OBJ}/${SYS}/lib/cfuns-c.ini ; \
! 	  touch ${OBJ}/${SYS}/lib/sockio-c.ini )
! @
  <<gcl-2.6.8pre.socket.patch>>=
  	@(cd ${GCLVERSION}/h ; \
  	  echo 3 applying EXTRAS patch to h/linux.defs ; \
--- 44,50 ----
  	echo '(progn (load "cmpnew/gcl_collectfn.lsp") (load "lsp/sys-proclaim.lisp") (compiler::emit-fn t) (system::save-system "${OUT}/lisp"))' | unixport/saved_gcl )
  @
  
! \section{Gnu Common Lisp 2.6.8pre}
  <<gcl-2.6.8pre.socket.patch>>=
  	@(cd ${GCLVERSION}/h ; \
  	  echo 3 applying EXTRAS patch to h/linux.defs ; \
*************** versions of bash. The problem is a missi
*** 71,81 ****
  \subsubsection{fortran patch}
  Communication over sockets (basically to the NAG fortran library)
  requires us to have XDR enabled.
- <<gcl-2.6.7.libspad.patch>>=
- 	@(cd ${GCLVERSION}/unixport ; \
- 	  echo 6 applying libspad.a patch to unixport/makefile ; \
- 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.unixport.makefile.patch )
- @
  <<gcl-2.6.8pre.libspad.patch>>=
  	@(cd ${GCLVERSION}/unixport ; \
  	  echo 6 applying libspad.a patch to unixport/makefile ; \
--- 56,61 ----
*************** We could use the -batch flag but that wo
*** 87,97 ****
  It isn't critical to the system builds but we will later be 
  capturing stdin and stdout and we do not want extra information
  printed.
- <<gcl-2.6.7.toploop.patch>>=
- 	@(cd ${GCLVERSION}/unixport ; \
- 	  echo 7 applying toploop patch to unixport/init_gcl.lsp ; \
- 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.unixport.init_gcl.lsp.in.patch )
- @
  
  Now, for some reason, lisp needs to tell you what the temporary directory
  for the compiler will be. We eliminate this noise as well as the banner.
--- 67,72 ----
*************** collects type information. The compile-f
*** 110,123 ****
  type information to a [[.fn]] file as structs. These structs can
  be loaded and written out as a file of lisp proclaims. The sys-proclaim.lisp
  file contains the proclaims for GCL's function definitions.
- <<gcl-2.6.7.collectfn.fix>>=
- 	@(cd ${GCLVERSION}/cmpnew ; \
- 	  echo 26 copy gcl_collectfn.lsp to ${OBJ}/${SYS}/lsp/collectfn.lsp ; \
- 	  cp gcl_collectfn.lsp ${OBJ}/${SYS}/lsp/collectfn.lsp )
- 	@(cd ${GCLVERSION}/lsp ; \
- 	  echo 27 copy sys-proclaim.lisp to ${OBJ}/${SYS}/lsp/sys-proclaim.lisp ; \
- 	  cp sys-proclaim.lisp ${OBJ}/${SYS}/lsp/sys-proclaim.lisp )
- @
  <<gcl-2.6.8pre.collectfn.fix>>=
  	@(cd ${GCLVERSION}/cmpnew ; \
  	  echo 26 copy gcl_collectfn.lsp to ${OBJ}/${SYS}/lsp/collectfn.lsp ; \
--- 85,90 ----
*************** file contains the proclaims for GCL's fu
*** 127,178 ****
  	  cp sys-proclaim.lisp ${OBJ}/${SYS}/lsp/sys-proclaim.lisp )
  @
  
- \subsection{The GCL-2.6.7 stanza}
- This stanza will be written out when the GCLVERSION variable is
- ``gcl-2.6.7''. It will overwrite the default version. See the 
- top level Makefile.pamphlet.
- <<gcl-2.6.7>>=
- # gcl version 2.6.7
- OUT=${OBJ}/${SYS}/bin
- 
- all:
- 	@echo 1 building ${LSP} ${GCLVERSION}
- 
- gcldir: 
- 	@echo 2 building ${GCLVERSION}
- 	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
- <<gcl-2.6.7.configure.in.patch>>
- <<gcl-2.6.7.socket.patch>>
- <<gcl-2.6.7.libspad.patch>>
- <<gcl-2.6.7.toploop.patch>>
- <<gcl-2.6.7.collectfn.fix>>
- <<gclConfigureMake>>
- 	@echo 13 finished system build on `date` | tee >gcldir
- 
- ccldir: ${LSP}/ccl/Makefile
- 	@echo 14 building CCL
- 	@mkdir -p ${INT}/ccl
- 	@mkdir -p ${OBJ}/${SYS}/ccl
- 	@( cd ccl ; ${ENV} ${MAKE} )
- 
- ${LSP}/ccl/Makefile: ${LSP}/ccl/Makefile.pamphlet
- 	@echo 15 making ${LSP}/ccl/Makefile from ${LSP}/ccl/Makefile.pamphlet
- 	@( cd ccl ; ${DOCUMENT} ${NOISE} Makefile )
- 
- document:
- 	@echo 16 making docs in ${LSP}
- 	@mkdir -p ${INT}/doc/lsp/ccl
- 	@( cd ccl ; ${ENV} ${MAKE} document )
- 
- clean:
- 	@echo 17 cleaning ${LSP}/ccl
- 	@( cd ccl ; ${ENV} ${MAKE} clean )
- 
- @
  \subsection{The GCL-2.6.8pre stanza}
- This stanza will be written out when the GCLVERSION variable is
- ``gcl-2.6.8pre''. It will overwrite the default version. See the 
- top level Makefile.pamphlet.
  <<gcl-2.6.8pre>>=
  # gcl version 2.6.8pre
  OUT=${OBJ}/${SYS}/bin
--- 94,100 ----
*************** clean:
*** 248,289 ****
  	@echo 24 cleaning ${LSP}/ccl
  	@( cd ccl ; ${ENV} ${MAKE} clean )
  @
- <<*>>=
- # gcl version 2.6.8pre
- OUT=${OBJ}/${SYS}/bin
- 
- all:
- 	@echo 1 building ${LSP} ${GCLVERSION}
- 
- gcldir: 
- 	@echo 2 building ${GCLVERSION}
- 	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
- <<gcl-2.6.8pre.socket.patch>>
- <<gcl-2.6.8pre.libspad.patch>>
- <<gcl-2.6.8pre.toploop.patch>>
- <<gcl-2.6.8pre.collectfn.fix>>
- <<gclConfigureMake>>
- 	@echo 13 finished system build on `date` | tee >gcldir
- 
- ccldir: ${LSP}/ccl/Makefile
- 	@echo 14 building CCL
- 	@mkdir -p ${INT}/ccl
- 	@mkdir -p ${OBJ}/${SYS}/ccl
- 	@( cd ccl ; ${ENV} ${MAKE} )
- 
- ${LSP}/ccl/Makefile: ${LSP}/ccl/Makefile.pamphlet
- 	@echo 15 making ${LSP}/ccl/Makefile from ${LSP}/ccl/Makefile.pamphlet
- 	@( cd ccl ; ${DOCUMENT} ${NOISE} Makefile )
  
! document:
! 	@echo 16 making docs in ${LSP}
! 	@mkdir -p ${INT}/doc/lsp/ccl
! 	@( cd ccl ; ${ENV} ${MAKE} document )
! 
! clean:
! 	@echo 17 cleaning ${LSP}/ccl
! 	@( cd ccl ; ${ENV} ${MAKE} clean )
  
  @
  \eject
  \begin{thebibliography}{99}
--- 170,182 ----
  	@echo 24 cleaning ${LSP}/ccl
  	@( cd ccl ; ${ENV} ${MAKE} clean )
  @
  
! This stanza will be written out when the GCLVERSION variable is
! ``gcl-2.6.8pre''. It will overwrite the default version. See the 
! top level Makefile.pamphlet.
  
+ <<*>>=
+ <<gcl-2.6.8pre>>
  @
  \eject
  \begin{thebibliography}{99}
*** zips/gcl-2.6.7.configure.in.patch	(revision 15809)
--- zips/gcl-2.6.7.configure.in.patch	(local)
***************
*** 1,11 ****
- --- configure.in	Sat Jan 15 14:17:17 2005
- +++ configure.in.tpd	Tue Jan 17 09:32:15 2006
- @@ -538,7 +538,7 @@
-  	# results, and the version is kept in special file).
-      
-  	if test -r /etc/.relid -a "X`uname -n`" = "X`uname -s`" ; then
- -	    system=MP-RAS-`${AWK} '{print $3}' /etc/.relid'`
- +	    system=MP-RAS-`${AWK} '{print $3}' '/etc/.relid'`
-  	fi
-  	if test "`uname -s`" = "AIX" ; then
-  	    system=AIX-`uname -v`.`uname -r`
--- 0 ----
*** zips/gcl-2.6.7.h.linux.defs.patch	(revision 15809)
--- zips/gcl-2.6.7.h.linux.defs.patch	(local)
***************
*** 1,13 ****
- --- linux.defs	Sun Jul 24 12:55:14 2005
- +++ linux.defs.tpd	Sun Jul 24 13:55:26 2005
- @@ -8,6 +8,10 @@
-  
-  # Machine dependent makefile definitions for intel 386,486 running linux
-  
- +# 20031022000 tpd link Axiom's code into the image
- +EXTRAS = ${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o
- +OFLAG = -O
- +
-  LBINDIR=/usr/local/bin
-  
-  #OFLAG	=  -g -Wall
--- 0 ----

Property changes on: zips/gcl-2.6.7.h.linux.defs.patch
___________________________________________________________________
Name: svn:eol-style
 -native
Name: svn:keywords
 -Author Date Id Revision

Files zips/gcl-2.6.7.tgz	(revision 15809) and zips/gcl-2.6.7.tgz	(local) differ

Property changes on: zips/gcl-2.6.7.tgz
___________________________________________________________________
Name: svn:mime-type
 -application/octet-stream

*** zips/gcl-2.6.7.unixport.init_gcl.lsp.in.patch	(revision 15809)
--- zips/gcl-2.6.7.unixport.init_gcl.lsp.in.patch	(local)
***************
*** 1,13 ****
- --- init_gcl.lsp.in	Sun Jul 24 12:55:39 2005
- +++ init_gcl.lsp.in.tpd	Sun Jul 24 14:04:35 2005
- @@ -84,8 +84,8 @@
-  	 (bye (if (or compiler::*error-p* (equal result '(nil))) 1 0))))
-     (cond ((si::get-command-arg "-batch")
-  	  (setq si::*top-level-hook* 'bye))
- -	 ((si::get-command-arg "-f"))
- -	 (t (format t si::*system-banner*)))
- +	 ((si::get-command-arg "-f")))
- +;	 (t (format t si::*system-banner*)))
-     (setq si::*ihs-top* 1)
-     (in-package 'system::user) (incf system::*ihs-top* 2)
-     (funcall system::*old-top-level*))
--- 0 ----

Property changes on: zips/gcl-2.6.7.unixport.init_gcl.lsp.in.patch
___________________________________________________________________
Name: svn:eol-style
 -native
Name: svn:keywords
 -Author Date Id Revision

*** zips/gcl-2.6.7.unixport.makefile.patch	(revision 15809)
--- zips/gcl-2.6.7.unixport.makefile.patch	(local)
***************
*** 1,12 ****
- --- makefile	Sun Jul 24 12:55:39 2005
- +++ makefile.tpd	Sun Jul 24 15:40:01 2005
- @@ -14,7 +14,8 @@
-  PORTDIR = $(shell pwd)
-  
-  LD_LIBS_PRE=$(FIRST_FILE) $(addprefix -u ,$(PATCHED_SYMBOLS))
- -LD_LIBS_POST=$(LIBS) $(LIBC) -lgclp $(LAST_FILE)
- +# 20031022000 tpd link axiom's C library code
- +LD_LIBS_POST=$(LIBS) $(LIBC) -lgclp ${OBJ}/${SYS}/lib/libspad.a $(LAST_FILE) 
-  
-  ifeq ($(ARRS),)
-  ARRS:=ar rs
--- 0 ----

Property changes on: zips/gcl-2.6.7.unixport.makefile.patch
___________________________________________________________________
Name: svn:eol-style
 -native
Name: svn:keywords
 -Author Date Id Revision

*** zips/gcl-2.6.8pre.configure.in.patch	(revision 15809)
--- zips/gcl-2.6.8pre.configure.in.patch	(local)
***************
*** 1,11 ****
- --- configure.in	Sat Jan 15 14:17:17 2005
- +++ configure.in.tpd	Tue Jan 17 09:32:15 2006
- @@ -538,7 +538,7 @@
-  	# results, and the version is kept in special file).
-      
-  	if test -r /etc/.relid -a "X`uname -n`" = "X`uname -s`" ; then
- -	    system=MP-RAS-`${AWK} '{print $3}' /etc/.relid'`
- +	    system=MP-RAS-`${AWK} '{print $3}' '/etc/.relid'`
-  	fi
-  	if test "`uname -s`" = "AIX" ; then
-  	    system=AIX-`uname -v`.`uname -r`
--- 0 ----
*** zips/gcl-2.6.8pre.configure.patch	(revision 15809)
--- zips/gcl-2.6.8pre.configure.patch	(local)
***************
*** 1,11 ****
- --- configure	Sat Jan 15 14:17:17 2005
- +++ configure.tpd	Sun Apr 16 23:12:48 2006
- @@ -6187,7 +6187,7 @@
-  echo "configure:6188: checking emacs site lisp directory" >&5
-  if [ "$EMACS_SITE_LISP" = "unknown" ] ; then
-  	if [ "$EMACS" != "" ] ; then
- -		EMACS_SITE_LISP=`$EMACS -q -batch --no-site-file -l conftest.el 2>&1 | sed -e /Loading/d | sed -e /load/d `
- +		EMACS_SITE_LISP=`$EMACS -q -batch --no-site-file -l conftest.el 2>&1 | grep -v ^Warning: | sed -e /Loading/d | sed -e /load/d `
-  	else
-  		EMACS_SITE_LISP=""
-  	fi
--- 0 ----

\start
Date: 27 Aug 2006 01:15:52 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] Upgrade to latest	GCL-2.6.8pre

this patchlet makes us use the latest GCL-2.6.8pre based on the
patches contributed by Camm.

built and tested on i686-pc-linux-gnu and x86_64-suse-linux.

-- Gaby

2006-08-26  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet (abs_top_builddir): Rename from top_builddir.
	(VERSION): Update.
	* Makefile.in: Regenerate.

	* config/setup-dep.mk (Makefile): change dir to
	$(abs_top_builddir) before regenerating.

src/interp/ 
2006-08-26  Camm Maguire  Camm Maguire

	* hash.lisp.pamphlet (mem_value): no longer static.
	* sockio.lisp.pamphlet (sock_get_float): Value type is now a double.
	* cfuns.lisp.pamphlet (MYCOMBINE): Now take ints and return an int.

zips/
2006-08-26  Gabriel Dos Reis  Gabriel Dos Reis

	* Update gcl-2.6.8pre.tgz.

*** Makefile.in	(revision 15808)
--- Makefile.in	(local)
*************** top_srcdir = @top_srcdir@
*** 17,23 ****
  abs_srcdir = @abs_srcdir@
  
  builddir = @builddir@
! top_builddir = @top_builddir@
  datadir = @datadir@
  
  AR = @AR@
--- 17,23 ----
  abs_srcdir = @abs_srcdir@
  
  builddir = @builddir@
! abs_top_builddir = @abs_top_builddir@
  datadir = @datadir@
  
  AR = @AR@
*************** STAMP = echo timestamp >
*** 37,43 ****
  ## -- Axiom variables --
  ## ---------------------
  
! VERSION="Axiom (build improvements branch) -- 2006-08-08"
  SPD=$(shell pwd)
  SYS=$(notdir $(AXIOM))
  SPAD=${SPD}/mnt/${SYS}
--- 37,43 ----
  ## -- Axiom variables --
  ## ---------------------
  
! VERSION="Axiom (build improvements branch) -- 2006-08-26"
  SPD=$(shell pwd)
  SYS=$(notdir $(AXIOM))
  SPAD=${SPD}/mnt/${SYS}
*** Makefile.pamphlet	(revision 15808)
--- Makefile.pamphlet	(local)
*************** top_srcdir = @top_srcdir@
*** 347,353 ****
  abs_srcdir = @abs_srcdir@
  
  builddir = @builddir@
! top_builddir = @top_builddir@
  datadir = @datadir@
  
  AR = @AR@
--- 347,353 ----
  abs_srcdir = @abs_srcdir@
  
  builddir = @builddir@
! abs_top_builddir = @abs_top_builddir@
  datadir = @datadir@
  
  AR = @AR@
*************** STAMP = echo timestamp >
*** 367,373 ****
  ## -- Axiom variables --
  ## ---------------------
  
! VERSION="Axiom (build improvements branch) -- 2006-08-08"
  SPD=$(shell pwd)
  SYS=$(notdir $(AXIOM))
  SPAD=${SPD}/mnt/${SYS}
--- 367,373 ----
  ## -- Axiom variables --
  ## ---------------------
  
! VERSION="Axiom (build improvements branch) -- 2006-08-26"
  SPD=$(shell pwd)
  SYS=$(notdir $(AXIOM))
  SPAD=${SPD}/mnt/${SYS}
*** config/setup-dep.mk	(revision 15808)
--- config/setup-dep.mk	(local)
*************** $(srcdir)/Makefile.in: $(build_setup_fil
*** 13,16 ****
  
  .PRECIOUS: Makefile
  Makefile: $(srcdir)/Makefile.in $(top_srcdir)/configure
! 	cd $(top_builddir) && $(SHELL) ./config.status $@
--- 13,16 ----
  
  .PRECIOUS: Makefile
  Makefile: $(srcdir)/Makefile.in $(top_srcdir)/configure
! 	cd $(abs_top_builddir) && $(SHELL) ./config.status $@
*** src/interp/cfuns.lisp.pamphlet	(revision 15808)
--- src/interp/cfuns.lisp.pamphlet	(local)
***************
*** 103,112 ****
  
  #+(AND KCL (NOT ELF))
  (Clines
! "unsigned int MYCOMBINE(i,j)"
! "unsigned int i,j;"
  "{"
! "return ( (((j & 16777215) << 6)+i) % 1073741789);"
  "}"
  )
  #+(AND KCL (NOT ELF))
--- 103,112 ----
  
  #+(AND KCL (NOT ELF))
  (Clines
! "int MYCOMBINE(i,j)"
! "int i,j;"
  "{"
! "return ( (((((unsigned int)j) & 16777215) << 6)+((unsigned int)i)) % 1073741789);"
  "}"
  )
  #+(AND KCL (NOT ELF))
*** src/interp/hash.lisp.pamphlet	(revision 15808)
--- src/interp/hash.lisp.pamphlet	(local)
***************
*** 81,87 ****
  (define-function 'HASHTABLE-CLASS #'system::hash-table-test)
  
  #+AKCL
! (clines "static int mem_value(x ,i)object x;int i; { return ((short *)x)[i];}")
  #+AKCL
  (defentry memory-value-short(object int) (int "mem_value"))
  
--- 81,87 ----
  (define-function 'HASHTABLE-CLASS #'system::hash-table-test)
  
  #+AKCL
! (clines "int mem_value(x ,i)object x;int i; { return ((short *)x)[i];}")
  #+AKCL
  (defentry memory-value-short(object int) (int "mem_value"))
  
*** src/interp/sockio.lisp.pamphlet	(revision 15808)
--- src/interp/sockio.lisp.pamphlet	(local)
***************
*** 78,84 ****
    (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_send_float (int float) (int "sock_send_float"))
    (defentry sock_send_wakeup (int int) (int "sock_send_wakeup"))
    (defentry server_switch () (int "server_switch"))
--- 78,84 ----
    (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) (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"))

\start
Date: 27 Aug 2006 02:00:19 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] rationalize lsp/

this patchlet rationalizes the logic for lsp/Makefile.  In particular,
it factorizes the various stanzas in lsp/Makefile.pamphlet, delegating
administrative bits to configure.

built and tested on an x86_64-suse-linux.

Nest step is to implement --with-gcl (similar to --with-noweb).

-- Gaby

2006-08-26  Gabriel Dos Reis  Gabriel Dos Reis

	* build-setup.sh: Regenerate lsp/Makefile.in too.

	* config/var-def.mk: New file.  Hold boileplate definition of
	standard Autoconf/Automake variables.
	* config/axiom.m4: New file.  
	* configure.ac.pamphlet: Include it.  Add configuration macro
	directory.  Use AXIOM_MAKEFILE from config/axiom.m4.
	Create lsp/Makefile at configure time.
	* configure.ac: Regenerate.
	* configure: Likewise.

	* Makefile.pamphlet: Move standard Autoconf variables to
	config/var-def.mk.
	(noweb): Fix thinko in TEXINPUTS substitution.
	(\subsubsection{LSPMakefile}): Remove, as lsp/Makefile is now
	created by configure at configure-time.
	(stamp-gcldir): Rename from gcldir throughout.
	* Makefile.in: Regenerate.

lsp/
2006-08-26  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet: Rework.  Factorize stanzas.
	(gcl-2.6.8predir): Rename from gcl-2.6.8pre.
	(gcl-systemdir): Rename from gcl-system.
	(stamp-gcldir): Rename from all.
	* Makefile.in: Generate.

*** Makefile.in	(revision 15050)
--- Makefile.in	(local)
***************
*** 1,38 ****
- ## ---------------------------------
- ## -- Standard Autoconf variables --
- ## ---------------------------------
- 
- prefix = @prefix@
- exec_prefix = @exec_prefix@
- 
- host = @host@
- host_alias = @host_alias@
- build = @build@
- build_alias = @build_alias@
- target = @target@
- target_alias = @target_alias@
- 
- srcdir = @srcdir@
- top_srcdir = @top_srcdir@
- abs_srcdir = @abs_srcdir@
- 
- builddir = @builddir@
- abs_top_builddir = @abs_top_builddir@
- datadir = @datadir@
- 
- AR = @AR@
- CC = @CC@
- CFLAGS = @CFLAGS@
- 
- AUTOCONF = autoconf
- AWK = @AWK@
- INSTALL = @INSTALL@
- PATCH = @PATCH@
- RANLIB = @RANLIB@
- TAR = @TAR@
- 
- STAMP = echo timestamp >
- 
  ## ---------------------
  ## -- Axiom variables --
  ## ---------------------
--- 1,3 ----
*************** noweb:
*** 162,168 ****
  	      | sed -e "s|^BIN=.*|BIN=$(axiom_build_bindir)|" \
                      -e "s|^LIB=.*|LIB=$(axiom_build_libdir)|" \
  		    -e "s|^MAN=.*|MAN=$(axiom_build_mandir)|" \
!                     -e "s|TEXINPUTS=.*|TEXINPUTS=$(axiom_build_texdir)|" \
  		    -e 's/ make / $$\(MAKE\) /' \
  	      > Makefile.tmp && mv Makefile.tmp Makefile && \
  	  ./awkname $(AWK) && \
--- 127,133 ----
  	      | sed -e "s|^BIN=.*|BIN=$(axiom_build_bindir)|" \
                      -e "s|^LIB=.*|LIB=$(axiom_build_libdir)|" \
  		    -e "s|^MAN=.*|MAN=$(axiom_build_mandir)|" \
!                     -e "s|^TEXINPUTS=.*|TEXINPUTS=$(axiom_build_texdir)|" \
  		    -e 's/ make / $$\(MAKE\) /' \
  	      > Makefile.tmp && mv Makefile.tmp Makefile && \
  	  ./awkname $(AWK) && \
*** Makefile.pamphlet	(revision 15050)
--- Makefile.pamphlet	(local)
***************
*** 3,9 ****
  \usepackage{src/scripts/tex/axiom}
  \begin{document}
  \title{The Top Level Makefile}
! \author{Timothy Daly}
  \maketitle
  \begin{abstract}
  \end{abstract}
--- 3,9 ----
  \usepackage{src/scripts/tex/axiom}
  \begin{document}
  \title{The Top Level Makefile}
! \author{Timothy Daly \and Gabriel Dos~Reis}
  \maketitle
  \begin{abstract}
  \end{abstract}
*************** The [[DOCUMENT]] variable is now set to 
*** 328,368 ****
  to the [[$SPADBIN/document]] command. This will allow it to be
  changed on the command line.
  <<environment>>=
- ## ---------------------------------
- ## -- Standard Autoconf variables --
- ## ---------------------------------
- 
- prefix = @prefix@
- exec_prefix = @exec_prefix@
- 
- host = @host@
- host_alias = @host_alias@
- build = @build@
- build_alias = @build_alias@
- target = @target@
- target_alias = @target_alias@
- 
- srcdir = @srcdir@
- top_srcdir = @top_srcdir@
- abs_srcdir = @abs_srcdir@
- 
- builddir = @builddir@
- abs_top_builddir = @abs_top_builddir@
- datadir = @datadir@
- 
- AR = @AR@
- CC = @CC@
- CFLAGS = @CFLAGS@
- 
- AUTOCONF = autoconf
- AWK = @AWK@
- INSTALL = @INSTALL@
- PATCH = @PATCH@
- RANLIB = @RANLIB@
- TAR = @TAR@
- 
- STAMP = echo timestamp >
- 
  ## ---------------------
  ## -- Axiom variables --
  ## ---------------------
--- 328,333 ----
*************** common failure of boxing up a file into 
*** 504,513 ****
  file lives in the [[ZIPS]] directory and will be applied
  after noweb is untarred but before the make occurs.
  
- We have added a patch to the [[${SPAD}/obj/noweb/src/Makefile]]
- which does two things. First it uses [[${TMP}/null]] rather than
- [[/dev/null]] as we do not wish to write outside our own build tree.
- 
  We also patch the use of [[make]] to use [[${MAKE}]]. BSD style
  systems use [[gmake]] rather than [[make]] so we need to pass this
  information from above for the build to succeed.
--- 469,474 ----
*************** noweb:
*** 580,586 ****
  	      | sed -e "s|^BIN=.*|BIN=$(axiom_build_bindir)|" \
                      -e "s|^LIB=.*|LIB=$(axiom_build_libdir)|" \
  		    -e "s|^MAN=.*|MAN=$(axiom_build_mandir)|" \
!                     -e "s|TEXINPUTS=.*|TEXINPUTS=$(axiom_build_texdir)|" \
  		    -e 's/ make / $$\(MAKE\) /' \
  	      > Makefile.tmp && mv Makefile.tmp Makefile && \
  	  ./awkname $(AWK) && \
--- 541,547 ----
  	      | sed -e "s|^BIN=.*|BIN=$(axiom_build_bindir)|" \
                      -e "s|^LIB=.*|LIB=$(axiom_build_libdir)|" \
  		    -e "s|^MAN=.*|MAN=$(axiom_build_mandir)|" \
!                     -e "s|^TEXINPUTS=.*|TEXINPUTS=$(axiom_build_texdir)|" \
  		    -e 's/ make / $$\(MAKE\) /' \
  	      > Makefile.tmp && mv Makefile.tmp Makefile && \
  	  ./awkname $(AWK) && \
*************** the subtree. We need only ensure that th
*** 642,673 ****
  We build two lisps, Codemist Common Lisp (CCL) and Gnu Common Lisp (GCL)
  at the current time. Carnegie-Mellon University Common Lisp (CMUCL) is planned.
  
! When we first make GCL we the src/Makefile will create a marker file
! called gcldir. This file has the same name as the stanza to create
  GCL and thus will prevent GCL from rebuilding. We need to do this
  since we have no control over the GCL makefiles.
  
  The [[${OBJ}/${SYS}/bin]] directory is where the lisps get built.
- \subsubsection{LSPMakefile}
- We need to specialize the Makefile stanza based on the version
- of Lisp we plan to use. At the moment there are 3 GCL versions
- which run Axiom: 2.4.1, 2.5, and 2.6 These are incompatible versions
- so we have different patches against them. The details are in
- the lsp/Makefile.pamphlet file. Here we just decide which section
- to choose. The default is 2.4.1 but if the GCLVERSION is changed
- then the Makefile is rewritten to extract the later version.
- It looks for a chunk name that matches the version number.
- <<LSPMakefile>>=
- ${LSP}/Makefile: ${LSP}/Makefile.pamphlet
- 	@echo 20 making ${LSP}/Makefile from ${LSP}/Makefile.pamphlet
- 	@( cd lsp ; \
- 	 ${DOCUMENT} ${NOISE} Makefile ; \
- 	 if [ "${GCLVERSION}" != "gcl-2.4.1" ] ; then \
- 	 ${TANGLE} -t8 -R"${GCLVERSION}" Makefile.pamphlet >Makefile ; \
-          fi )
- 	 @cp Makefile.dvi ${MNT}/${SYS}/doc/src
  
! @
  Here we add [[mkdir -p ${OBJ}/${SYS}/lsp]] because we need to rename the
  [[gcl_collectfn.lsp]] back to collectfn.lsp. We also start adding support
  for [[sys-proclaim.lsp]] and other dynamically collected proclaim information.
--- 603,617 ----
  We build two lisps, Codemist Common Lisp (CCL) and Gnu Common Lisp (GCL)
  at the current time. Carnegie-Mellon University Common Lisp (CMUCL) is planned.
  
! When we first make GCL the src/Makefile will create a marker file
! called [[stamp-gcldir]]. This file has the same name as the stanza to create 
  GCL and thus will prevent GCL from rebuilding. We need to do this
  since we have no control over the GCL makefiles.
  
  The [[${OBJ}/${SYS}/bin]] directory is where the lisps get built.
  
! \subsubsection{[[lsp]]}
! 
  Here we add [[mkdir -p ${OBJ}/${SYS}/lsp]] because we need to rename the
  [[gcl_collectfn.lsp]] back to collectfn.lsp. We also start adding support
  for [[sys-proclaim.lsp]] and other dynamically collected proclaim information.
*************** lspdir: stamp-rootdirs stamp-build-scrip
*** 686,701 ****
  	@echo 19 making ${LSP}
  	@mkdir -p ${OBJ}/${SYS}/bin
  	@mkdir -p ${OBJ}/${SYS}/lsp
! 	@(cd lsp ; ${ENV} ${MAKE} gcldir )
  #	@(cd lsp ; ${ENV} ${MAKE} ccldir )
  
- <<LSPMakefile>>
  lspclean:
  	@echo 21 cleaning ${OBJ}/${SYS}/ccl
  	@rm -rf ${LSP}/${GCLVERSION}
  	@rm -rf ${INT}/ccl
  	@rm -rf ${OBJ}/${SYS}/ccl
! 	@rm -rf ${LSP}/gcldir
  	@rm -f ${LSP}/Makefile ${LSP}/Makefile.dvi
  
  @
--- 630,644 ----
  	@echo 19 making ${LSP}
  	@mkdir -p ${OBJ}/${SYS}/bin
  	@mkdir -p ${OBJ}/${SYS}/lsp
! 	@(cd lsp ; ${ENV} ${MAKE} stamp-gcldir )
  #	@(cd lsp ; ${ENV} ${MAKE} ccldir )
  
  lspclean:
  	@echo 21 cleaning ${OBJ}/${SYS}/ccl
  	@rm -rf ${LSP}/${GCLVERSION}
  	@rm -rf ${INT}/ccl
  	@rm -rf ${OBJ}/${SYS}/ccl
! 	@rm -rf ${LSP}/stamp-gcldir
  	@rm -f ${LSP}/Makefile ${LSP}/Makefile.dvi
  
  @
*** build-setup.sh	(revision 15050)
--- build-setup.sh	(local)
*************** notangle ./configure.ac.pamphlet > ./con
*** 12,17 ****
--- 12,20 ----
  notangle -t8 ./Makefile.pamphlet > ./Makefile.in \
     || error "could not extract Makefile.in from pamphlet file"
  
+ notangle -t8 ./lsp/Makefile.pamphlet > ./lsp/Makefile.in \
+    || error "could not extract Makefile.in from pamphlet file"
+ 
  autoconf || error "could not re-generate configure"
  
  
*** config/setup-dep.mk	(revision 15050)
--- config/setup-dep.mk	(local)
***************
*** 1,14 ****
  build_setup_files= $(top_srcdir)/configure.ac.pamphlet \
  		   $(top_srcdir)/Makefile.pamphlet \
  		   $(top_srcdir)/build-setup.sh
  
  
! $(top_srcdir)/configure: $(build_setup_files)
  	cd $(top_srcdir) && \
! 	notangle ./configure.ac.pamphlet > configure.ac && \
! 	$(AUTOCONF)
  
! $(srcdir)/Makefile.in: $(build_setup_files)
  	cd $(srcdir) && notangle -t8 Makefile.pamphlet > ./Makefile.in
  
  .PRECIOUS: Makefile
--- 1,20 ----
+ ## ---------------------------------------
+ ## -- Standard boilerplate dependencies --
+ ## ---------------------------------------
+ 
  build_setup_files= $(top_srcdir)/configure.ac.pamphlet \
  		   $(top_srcdir)/Makefile.pamphlet \
  		   $(top_srcdir)/build-setup.sh
  
  
! $(top_srcdir)/configure.ac: $(top_srcdir)/configure.ac.pamphlet
  	cd $(top_srcdir) && \
! 	notangle ./configure.ac.pamphlet > configure.ac
! 
! $(top_srcdir)/configure: $(top_srcdir)/configure.ac
! 	cd $(top_srcdir) && $(AUTOCONF)
  
! $(srcdir)/Makefile.in: $(srcdir)/Makefile.pamphlet $(top_srcdir)/configure.ac
  	cd $(srcdir) && notangle -t8 Makefile.pamphlet > ./Makefile.in
  
  .PRECIOUS: Makefile
*** config/axiom.m4	(revision 15050)
--- config/axiom.m4	(local)
***************
*** 0 ****
--- 1,3 ----
+ AC_DEFUN([AXIOM_MAKEFILE],
+ [AC_CONFIG_FILES([$1:config/var-def.mk:$2:config/setup-dep.mk])])
+ 
*** config/var-def.mk	(revision 15050)
--- config/var-def.mk	(local)
***************
*** 0 ****
--- 1,47 ----
+ ## ---------------------------------
+ ## -- Standard Autoconf variables --
+ ## ---------------------------------
+ 
+ prefix = @prefix@
+ exec_prefix = @exec_prefix@
+ 
+ host = @host@
+ host_alias = @host_alias@
+ build = @build@
+ build_alias = @build_alias@
+ target = @target@
+ target_alias = @target_alias@
+ 
+ srcdir = @srcdir@
+ abs_srcdir = @abs_srcdir@
+ top_srcdir = @top_srcdir@
+ abs_top_srcdir = @abs_top_srcdir@
+ 
+ builddir = @builddir@
+ top_builddir = @top_builddir@
+ abs_top_builddir = @abs_top_builddir@
+ datadir = @datadir@
+ 
+ AR = @AR@
+ CC = @CC@
+ CFLAGS = @CFLAGS@
+ 
+ AUTOCONF = autoconf
+ AWK = @AWK@
+ INSTALL = @INSTALL@
+ install_sh = @install_sh@
+ install_sh_DATA = $(install_sh) -c -m 644
+ install_sh_PROGRAM = $(install_sh) -c
+ install_sh_script = $(install_sh) -c
+ mkinstalldirs = $(install_sh) -d
+ INSTALL_DATA = @INSTALL_DATA@
+ INSTALL_PROGRAM = @INSTALL_PROGRAM@
+ INSTALL_SCRIPT = @INSTALL_SCRIPT@
+ PATCH = @PATCH@
+ RANLIB = @RANLIB@
+ TAR = @TAR@
+ 
+ mkdir_p = @mkdir_p@
+ 
+ STAMP = echo timestamp >
+ 
*** configure	(revision 15050)
--- configure	(local)
***************
*** 1,6 ****
  #! /bin/sh
  # Guess values for system-dependent variables and create Makefiles.
! # Generated by GNU Autoconf 2.59 for Axiom silver branch 2006-07-15.
  #
  # Report bugs to <list>.
  #
--- 1,6 ----
  #! /bin/sh
  # Guess values for system-dependent variables and create Makefiles.
! # Generated by GNU Autoconf 2.59 for Axiom build improvements branch 2006-08-26.
  #
  # Report bugs to <list>.
  #
*************** SHELL=${CONFIG_SHELL-/bin/sh}
*** 267,276 ****
  : ${ac_max_here_lines=38}
  
  # Identity of this package.
! PACKAGE_NAME='Axiom silver branch'
! PACKAGE_TARNAME='axiom-silver-branch'
! PACKAGE_VERSION='2006-07-15'
! PACKAGE_STRING='Axiom silver branch 2006-07-15'
  PACKAGE_BUGREPORT='list'
  
  ac_unique_file="src/Makefile.pamphlet"
--- 267,276 ----
  : ${ac_max_here_lines=38}
  
  # Identity of this package.
! PACKAGE_NAME='Axiom build improvements branch'
! PACKAGE_TARNAME='axiom-build-improvements-branch'
! PACKAGE_VERSION='2006-08-26'
! PACKAGE_STRING='Axiom build improvements branch 2006-08-26'
  PACKAGE_BUGREPORT='list'
  
  ac_unique_file="src/Makefile.pamphlet"
*************** if test "$ac_init_help" = "long"; then
*** 743,749 ****
    # Omit some internal or obsolete options to make the list less imposing.
    # This message is too long to be a string in the A/UX 3.1 sh.
    cat <<_ACEOF
! \`configure' configures Axiom silver branch 2006-07-15 to adapt to many kinds of systems.
  
  Usage: $0 [OPTION]... [VAR=VALUE]...
  
--- 743,749 ----
    # Omit some internal or obsolete options to make the list less imposing.
    # This message is too long to be a string in the A/UX 3.1 sh.
    cat <<_ACEOF
! \`configure' configures Axiom build improvements branch 2006-08-26 to adapt to many kinds of systems.
  
  Usage: $0 [OPTION]... [VAR=VALUE]...
  
*************** fi
*** 809,815 ****
  
  if test -n "$ac_init_help"; then
    case $ac_init_help in
!      short | recursive ) echo "Configuration of Axiom silver branch 2006-07-15:";;
     esac
    cat <<\_ACEOF
  
--- 809,815 ----
  
  if test -n "$ac_init_help"; then
    case $ac_init_help in
!      short | recursive ) echo "Configuration of Axiom build improvements branch 2006-08-26:";;
     esac
    cat <<\_ACEOF
  
*************** fi
*** 927,933 ****
  test -n "$ac_init_help" && exit 0
  if $ac_init_version; then
    cat <<\_ACEOF
! Axiom silver branch configure 2006-07-15
  generated by GNU Autoconf 2.59
  
  Copyright (C) 2003 Free Software Foundation, Inc.
--- 927,933 ----
  test -n "$ac_init_help" && exit 0
  if $ac_init_version; then
    cat <<\_ACEOF
! Axiom build improvements branch configure 2006-08-26
  generated by GNU Autoconf 2.59
  
  Copyright (C) 2003 Free Software Foundation, Inc.
*************** cat >&5 <<_ACEOF
*** 941,947 ****
  This file contains any messages produced by compilers while
  running configure, to aid debugging if configure makes a mistake.
  
! It was created by Axiom silver branch $as_me 2006-07-15, which was
  generated by GNU Autoconf 2.59.  Invocation command line was
  
    $ $0 $@
--- 941,947 ----
  This file contains any messages produced by compilers while
  running configure, to aid debugging if configure makes a mistake.
  
! It was created by Axiom build improvements branch $as_me 2006-08-26, which was
  generated by GNU Autoconf 2.59.  Invocation command line was
  
    $ $0 $@
*************** ac_config_guess="$SHELL $ac_aux_dir/conf
*** 1303,1308 ****
--- 1303,1319 ----
  ac_config_sub="$SHELL $ac_aux_dir/config.sub"
  ac_configure="$SHELL $ac_aux_dir/configure" # This should be Cygnus configure.
  
+ case config in
+   [\\/]* | ?:[\\/]* ) ac_macro_dir=config         ;;
+   *)                      ac_macro_dir=$srcdir/config ;;
+ esac
+ if test -d "$ac_macro_dir"; then :
+ else
+   { { echo "$as_me:$LINENO: error: cannot find macro directory \`config'" >&5
+ echo "$as_me: error: cannot find macro directory \`config'" >&2;}
+    { (exit 1); exit 1; }; }
+ fi
+ 
  
  # AM_INIT_AUTOMAKE([foreign])
  
*************** echo "$as_me: make" >&6;}
*** 4685,4691 ****
  fi
  AXIOM=`pwd`/mnt/$SYSNAME
  
!           ac_config_files="$ac_config_files Makefile:Makefile.in:config/setup-dep.mk"
  
  
  ## We now generate the "document" script and support files at configure time.
--- 4696,4704 ----
  fi
  AXIOM=`pwd`/mnt/$SYSNAME
  
!           ac_config_files="$ac_config_files Makefile:config/var-def.mk:Makefile.in:config/setup-dep.mk"
! 
!           ac_config_files="$ac_config_files lsp/Makefile:config/var-def.mk:lsp/Makefile.in:config/setup-dep.mk"
  
  
  ## We now generate the "document" script and support files at configure time.
*************** _ASBOX
*** 5094,5100 ****
  } >&5
  cat >&5 <<_CSEOF
  
! This file was extended by Axiom silver branch $as_me 2006-07-15, which was
  generated by GNU Autoconf 2.59.  Invocation command line was
  
    CONFIG_FILES    = $CONFIG_FILES
--- 5107,5113 ----
  } >&5
  cat >&5 <<_CSEOF
  
! This file was extended by Axiom build improvements branch $as_me 2006-08-26, which was
  generated by GNU Autoconf 2.59.  Invocation command line was
  
    CONFIG_FILES    = $CONFIG_FILES
*************** _ACEOF
*** 5149,5155 ****
  
  cat >>$CONFIG_STATUS <<_ACEOF
  ac_cs_version="\\
! Axiom silver branch config.status 2006-07-15
  configured by $0, generated by GNU Autoconf 2.59,
    with options \\"`echo "$ac_configure_args" | sed 's/[\\""\`\$]/\\\\&/g'`\\"
  
--- 5162,5168 ----
  
  cat >>$CONFIG_STATUS <<_ACEOF
  ac_cs_version="\\
! Axiom build improvements branch config.status 2006-08-26
  configured by $0, generated by GNU Autoconf 2.59,
    with options \\"`echo "$ac_configure_args" | sed 's/[\\""\`\$]/\\\\&/g'`\\"
  
*************** for ac_config_target in $ac_config_targe
*** 5252,5258 ****
  do
    case "$ac_config_target" in
    # Handling of arguments.
!   "Makefile" ) CONFIG_FILES="$CONFIG_FILES Makefile:Makefile.in:config/setup-dep.mk" ;;
    "build/scripts/document" ) CONFIG_FILES="$CONFIG_FILES build/scripts/document:$srcdir/src/scripts/document.in" ;;
    *) { { echo "$as_me:$LINENO: error: invalid argument: $ac_config_target" >&5
  echo "$as_me: error: invalid argument: $ac_config_target" >&2;}
--- 5265,5272 ----
  do
    case "$ac_config_target" in
    # Handling of arguments.
!   "Makefile" ) CONFIG_FILES="$CONFIG_FILES Makefile:config/var-def.mk:Makefile.in:config/setup-dep.mk" ;;
!   "lsp/Makefile" ) CONFIG_FILES="$CONFIG_FILES lsp/Makefile:config/var-def.mk:lsp/Makefile.in:config/setup-dep.mk" ;;
    "build/scripts/document" ) CONFIG_FILES="$CONFIG_FILES build/scripts/document:$srcdir/src/scripts/document.in" ;;
    *) { { echo "$as_me:$LINENO: error: invalid argument: $ac_config_target" >&5
  echo "$as_me: error: invalid argument: $ac_config_target" >&2;}
*** configure.ac	(revision 15050)
--- configure.ac	(local)
***************
*** 1,6 ****
! AC_INIT([Axiom silver branch], [2006-07-15], [list])
  
  AC_CONFIG_AUX_DIR(config)
  
  # AM_INIT_AUTOMAKE([foreign])
  
--- 1,9 ----
! sinclude(config/axiom.m4)
! AC_INIT([Axiom build improvements branch], [2006-08-26], 
!         [list])
  
  AC_CONFIG_AUX_DIR(config)
+ AC_CONFIG_MACRO_DIR(config)
  
  # AM_INIT_AUTOMAKE([foreign])
  
*************** else
*** 164,170 ****
  fi
  AXIOM=`pwd`/mnt/$SYSNAME
  AC_SUBST(AXIOM)
! AC_CONFIG_FILES(Makefile:Makefile.in:config/setup-dep.mk)
  
  ## We now generate the "document" script and support files at configure time.
  ## We put them in the build directory because they are intended to be 
--- 167,174 ----
  fi
  AXIOM=`pwd`/mnt/$SYSNAME
  AC_SUBST(AXIOM)
! AXIOM_MAKEFILE([Makefile], [Makefile.in])
! AXIOM_MAKEFILE([lsp/Makefile], [lsp/Makefile.in])
  
  ## We now generate the "document" script and support files at configure time.
  ## We put them in the build directory because they are intended to be 
*** configure.ac.pamphlet	(revision 15050)
--- configure.ac.pamphlet	(local)
*************** information:
*** 100,112 ****
    suffer from traffic...
  \end{itemize}
  <<Autoconf init>>=
! AC_INIT([Axiom silver branch], [2006-07-15], [list])
  @
  
  Autoconf needs some auxilary files that are present in the sub-directory
  \file{config}.  Autoconf needs to be told about that.
  <<auxiliary config files>>=
  AC_CONFIG_AUX_DIR(config)
  @
  
  Notice that since we don't use Automake (yet), we don't initialize
--- 100,115 ----
    suffer from traffic...
  \end{itemize}
  <<Autoconf init>>=
! sinclude(config/axiom.m4)
! AC_INIT([Axiom build improvements branch], [2006-08-26], 
!         [list])
  @
  
  Autoconf needs some auxilary files that are present in the sub-directory
  \file{config}.  Autoconf needs to be told about that.
  <<auxiliary config files>>=
  AC_CONFIG_AUX_DIR(config)
+ AC_CONFIG_MACRO_DIR(config)
  @
  
  Notice that since we don't use Automake (yet), we don't initialize
*************** AC_SUBST(AXIOM)
*** 329,335 ****
  \subsubsection{Instantiating configuration files}
  
  <<instantiate config files>>=
! AC_CONFIG_FILES(Makefile:Makefile.in:config/setup-dep.mk)
  
  ## We now generate the "document" script and support files at configure time.
  ## We put them in the build directory because they are intended to be 
--- 332,339 ----
  \subsubsection{Instantiating configuration files}
  
  <<instantiate config files>>=
! AXIOM_MAKEFILE([Makefile], [Makefile.in])
! AXIOM_MAKEFILE([lsp/Makefile], [lsp/Makefile.in])
  
  ## We now generate the "document" script and support files at configure time.
  ## We put them in the build directory because they are intended to be 
*** lsp/Makefile.pamphlet	(revision 15050)
--- lsp/Makefile.pamphlet	(local)
***************
*** 10,18 ****
  \tableofcontents
  \eject
  \section{The Makefile}
! We create a dummy file {\bf gcldir} after gcl has been built so
  it is not rebuilt. We need to do this because we have no control
! over the gcl Makefiles.
  
  \section{Configure and Make GCL}
  We enable several features of GCL.
--- 10,18 ----
  \tableofcontents
  \eject
  \section{The Makefile}
! We create a dummy file {\bf stamp-gcldir} after GCL has been built so
  it is not rebuilt. We need to do this because we have no control
! over the GCL Makefiles.
  
  \section{Configure and Make GCL}
  We enable several features of GCL.
*************** file contains the proclaims for GCL's fu
*** 96,135 ****
  
  \subsection{The GCL-2.6.8pre stanza}
  <<gcl-2.6.8pre>>=
! # gcl version 2.6.8pre
! OUT=${OBJ}/${SYS}/bin
! 
! all:
! 	@echo 1 building ${LSP} ${GCLVERSION}
! 
! gcldir: 
! 	@echo 2 building ${GCLVERSION}
  	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
  <<gcl-2.6.8pre.socket.patch>>
  <<gcl-2.6.8pre.libspad.patch>>
  <<gcl-2.6.8pre.toploop.patch>>
  <<gcl-2.6.8pre.collectfn.fix>>
  <<gclConfigureMake>>
! 	@echo 13 finished system build on `date` | tee >gcldir
! 
! ccldir: ${LSP}/ccl/Makefile
! 	@echo 14 building CCL
! 	@mkdir -p ${INT}/ccl
! 	@mkdir -p ${OBJ}/${SYS}/ccl
! 	@( cd ccl ; ${ENV} ${MAKE} )
! 
! ${LSP}/ccl/Makefile: ${LSP}/ccl/Makefile.pamphlet
! 	@echo 15 making ${LSP}/ccl/Makefile from ${LSP}/ccl/Makefile.pamphlet
! 	@( cd ccl ; ${DOCUMENT} ${NOISE} Makefile )
! 
! document:
! 	@echo 16 making docs in ${LSP}
! 	@mkdir -p ${INT}/doc/lsp/ccl
! 	@( cd ccl ; ${ENV} ${MAKE} document )
! 
! clean:
! 	@echo 17 cleaning ${LSP}/ccl
! 	@( cd ccl ; ${ENV} ${MAKE} clean )
  
  @
  
--- 96,110 ----
  
  \subsection{The GCL-2.6.8pre stanza}
  <<gcl-2.6.8pre>>=
! # Rules for building GCL from Axiom distribution.
! gcl-2.6.8predir: 
  	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
  <<gcl-2.6.8pre.socket.patch>>
  <<gcl-2.6.8pre.libspad.patch>>
  <<gcl-2.6.8pre.toploop.patch>>
  <<gcl-2.6.8pre.collectfn.fix>>
  <<gclConfigureMake>>
! 	$(STAMP) stamp-gcldir
  
  @
  
*************** On some systems, notably freebsd, we ass
*** 140,182 ****
  installed and available using the command [[gcl]]. In that case
  we need to extract this Makefile instead of the standard one.
  <<gcl-system>>=
! # locally installed GCL
  OUT=${OBJ}/${SYS}/bin
  
! all:
! 	@echo 21 building ${LSP} ${GCLVERSION}
  
! gcldir: 
! 	@echo 22 building for ${GCLVERSION}
! 	echo '(compiler::link nil "${OUT}/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"))) "${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o ${OBJ}/${SYS}/lib/libspad.a")' | gcl
! 	@echo 23 finished gcl build on `date` | tee >gcldir
  
  ccldir: ${LSP}/ccl/Makefile
! 	@echo 21 building CCL
  	@mkdir -p ${INT}/ccl
  	@mkdir -p ${OBJ}/${SYS}/ccl
  	@( cd ccl ; ${ENV} ${MAKE} )
  
  ${LSP}/ccl/Makefile: ${LSP}/ccl/Makefile.pamphlet
! 	@echo 22 making ${LSP}/ccl/Makefile from ${LSP}/ccl/Makefile.pamphlet
  	@( cd ccl ; ${DOCUMENT} ${NOISE} Makefile )
  
  document:
! 	@echo 23 making docs in ${LSP}
  	@mkdir -p ${INT}/doc/lsp/ccl
  	@( cd ccl ; ${ENV} ${MAKE} document )
  
  clean:
! 	@echo 24 cleaning ${LSP}/ccl
  	@( cd ccl ; ${ENV} ${MAKE} clean )
- @
- 
- This stanza will be written out when the GCLVERSION variable is
- ``gcl-2.6.8pre''. It will overwrite the default version. See the 
- top level Makefile.pamphlet.
  
- <<*>>=
- <<gcl-2.6.8pre>>
  @
  \eject
  \begin{thebibliography}{99}
--- 115,156 ----
  installed and available using the command [[gcl]]. In that case
  we need to extract this Makefile instead of the standard one.
  <<gcl-system>>=
! # Rules for preparing system-installed GCL for use within Axiom.
! gcl-systemdir: 
! 	echo '(compiler::link nil "${OUT}/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"))) "${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o ${OBJ}/${SYS}/lib/libspad.a")' | gcl
! 	@echo 23 finished gcl build on `date` | tee > stamp-gcldir
! @
! 
! <<*>>=
  OUT=${OBJ}/${SYS}/bin
  
! stamp-gcldir:
! 	@echo 1 building ${LSP} ${GCLVERSION}
! 	@$(ENV) $(MAKE) $(GCLVERSION)dir
  
! <<gcl-2.6.8pre>>
! 
! <<gcl-system>>
  
  ccldir: ${LSP}/ccl/Makefile
! 	@echo 14 building CCL
  	@mkdir -p ${INT}/ccl
  	@mkdir -p ${OBJ}/${SYS}/ccl
  	@( cd ccl ; ${ENV} ${MAKE} )
  
  ${LSP}/ccl/Makefile: ${LSP}/ccl/Makefile.pamphlet
! 	@echo 15 making ${LSP}/ccl/Makefile from ${LSP}/ccl/Makefile.pamphlet
  	@( cd ccl ; ${DOCUMENT} ${NOISE} Makefile )
  
  document:
! 	@echo 16 making docs in ${LSP}
  	@mkdir -p ${INT}/doc/lsp/ccl
  	@( cd ccl ; ${ENV} ${MAKE} document )
  
  clean:
! 	@echo 17 cleaning ${LSP}/ccl
  	@( cd ccl ; ${ENV} ${MAKE} clean )
  
  @
  \eject
  \begin{thebibliography}{99}
*** lsp/Makefile.in	(revision 15050)
--- lsp/Makefile.in	(local)
***************
*** 0 ****
--- 1,58 ----
+ OUT=${OBJ}/${SYS}/bin
+ 
+ stamp-gcldir:
+ 	@echo 1 building ${LSP} ${GCLVERSION}
+ 	@$(ENV) $(MAKE) $(GCLVERSION)dir
+ 
+ # Rules for building GCL from Axiom distribution.
+ gcl-2.6.8predir: 
+ 	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
+ 	@(cd ${GCLVERSION}/h ; \
+ 	  echo 3 applying EXTRAS patch to h/linux.defs ; \
+ 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.h.linux.defs.patch )
+ 	@(echo 4 setup ini files for EXTRAS patch ; \
+ 	  touch ${OBJ}/${SYS}/lib/cfuns-c.ini ; \
+ 	  touch ${OBJ}/${SYS}/lib/sockio-c.ini )
+ 	@(cd ${GCLVERSION}/unixport ; \
+ 	  echo 6 applying libspad.a patch to unixport/makefile ; \
+ 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.unixport.makefile.patch )
+ 	@(cd ${GCLVERSION}/unixport ; \
+ 	  echo 7 applying toploop patch to unixport/init_gcl.lsp ; \
+ 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.unixport.init_gcl.lsp.in.patch )
+ 	@(cd ${GCLVERSION}/cmpnew ; \
+ 	  echo 26 copy gcl_collectfn.lsp to ${OBJ}/${SYS}/lsp/collectfn.lsp ; \
+ 	  cp gcl_collectfn.lsp ${OBJ}/${SYS}/lsp/collectfn.lsp )
+ 	@(cd ${GCLVERSION}/lsp ; \
+ 	  echo 27 copy sys-proclaim.lisp to ${OBJ}/${SYS}/lsp/sys-proclaim.lisp ; \
+ 	  cp sys-proclaim.lisp ${OBJ}/${SYS}/lsp/sys-proclaim.lisp )
+ 	@(cd ${GCLVERSION} ; \
+ 	./configure ${GCLOPTS} ; \
+ 	${ENV} ${MAKE} ; \
+ 	echo '(progn (load "cmpnew/gcl_collectfn.lsp") (load "lsp/sys-proclaim.lisp") (compiler::emit-fn t) (system::save-system "${OUT}/lisp"))' | unixport/saved_gcl )
+ 	$(STAMP) stamp-gcldir
+ 
+ 
+ # Rules for preparing system-installed GCL for use within Axiom.
+ gcl-systemdir: 
+ 	echo '(compiler::link nil "${OUT}/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"))) "${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o ${OBJ}/${SYS}/lib/libspad.a")' | gcl
+ 	@echo 23 finished gcl build on `date` | tee > stamp-gcldir
+ 
+ ccldir: ${LSP}/ccl/Makefile
+ 	@echo 14 building CCL
+ 	@mkdir -p ${INT}/ccl
+ 	@mkdir -p ${OBJ}/${SYS}/ccl
+ 	@( cd ccl ; ${ENV} ${MAKE} )
+ 
+ ${LSP}/ccl/Makefile: ${LSP}/ccl/Makefile.pamphlet
+ 	@echo 15 making ${LSP}/ccl/Makefile from ${LSP}/ccl/Makefile.pamphlet
+ 	@( cd ccl ; ${DOCUMENT} ${NOISE} Makefile )
+ 
+ document:
+ 	@echo 16 making docs in ${LSP}
+ 	@mkdir -p ${INT}/doc/lsp/ccl
+ 	@( cd ccl ; ${ENV} ${MAKE} document )
+ 
+ clean:
+ 	@echo 17 cleaning ${LSP}/ccl
+ 	@( cd ccl ; ${ENV} ${MAKE} clean )
+ 

\start
Date: Sun, 27 Aug 2006 14:42:07 -0400
From: Eitan Gurari
To: Bill Page
Subject: re: Another question

Page, Bill writes:

 > http://wiki.axiom-developer.org/images/book--main--1/bookvol1.tex
 > 
 > As a pdf file this is about 800 pages.  As html it generates nearly
 > 600 png files and my browsers (both FireFox and Explorer) die while
 > trying to render it. And the download is pretty horrendous anyway
 > :( htlatex indicates a large number of errors which I simply skipped
 > for this test.

Gurari, Eitan writes:

 > A compilation under htlatex shows a support problem for 
 > \begin{list}...\end{list}. I'll need to look into this case.

The problem seems to be in the source bookvol1.tex file.  There are
quite a few usages of a list environment file of the form

   \begin{list}{} 
   \item ...
   \end{list} 

instead of the following form.

   \begin{list}{}{}
   \item ...
   \end{list} 

The correct syntax is:

 \begin{list}{label}{spacing}
 \item First item
 \item Second item
 ....
 \end{list}

http://www.eng.cam.ac.uk/help/tpl/textprocessing/teTeX/latex/latex2e-html/ltx-260.html

\start
Date: 27 Aug 2006 21:24:27 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] add support for --with-gcl

Hi the patchlet below adds support for --with-gcl.

By default, configure will try to detect the presence of a gcl command
in the build environment, and use it.  You can instruct Axiom not to
autotect through the configure option --without-gcl.  Of course, you
can also explicitly tell Axiom the availability of GCL throught
--with-gcl.  All this follows standard GNU build tools semantics.

When I tried this, I had
  * an outright segmentation fault with a _separately_ installed
    GCL-2.6.8pre.  That SIGSEV was preceeded by failure to load
    sysdef.lsp from GCL-2.6.8pre installation.  Investigation revealed
    that indeed, that file is missing from the installation
    repository.  That seems a plain bug from GCL part.

  * a C compile failure, with a _separately_ installed GCL-2.6.7.
    Here is a snippet of the build log:
    [...]
      =====================================
      === algebra bootstrap complete ======
      =====================================
      compiling AHYP.spad to AHYP.NRLIB
      AHYP.NRLIB/AHYP.c:2:24: error: cmpinclude.h: No such file or directory
      In file included from AHYP.NRLIB/AHYP.c:3:
      AHYP.NRLIB/AHYP.h:4: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'LI2'

   The root of the error seems to be a failure of the C compiler (GCC)
   to locate the GCL-specific include file cmpinclude.h.  That file is
   present in the installation location

     /usr/local/lib/gcl-2.6.7/h

   so there seems to be a bug in the way the C compiler is called to
   compile the generated C codes -- that should add
   -I/usr/local/lib/gcl-2.6.7/h.  That is either a GCL bug (very
   likely), or an Axiom bug (not sure). 


Trying to fix all of that before commitring led me to learn about GCL
more than I wanted.  Consequently I postponed the investigation --
hopefully, those more familiar with GCL than me will come up with 
recommendations. 


Notice that none of the above problems manifests if one uses GCL as
part of the Axiom sources.  Consequently, until the above issues
are fixed, be sure to specify --without-gcl when invoking configure.

Built and tested on an i686-pc-linux-gnu.

-- Gaby

2006-08-27  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet (GCLVERSION): Define as Autoconf-substituted
	variable. 
	* Makefile.in: Regenerate.

	* configure.ac.pamphlet: Add support for --with-gcl, auto-detect.
	* configure.ac: Regenerate.
	* configure: Likewise.

*** Makefile.pamphlet	(revision 15812)
--- Makefile.pamphlet	(local)
*************** lsp/Makefile.pamphlet file and get the c
*** 793,799 ****
  forget to erase the lsp/Makefile the wrong patches will be applied.
  
  <<GCLVERSION>>=
! GCLVERSION=gcl-2.6.8pre
  @
  
  \subsubsection{The [[GCLOPTS]] configure variable}
--- 793,799 ----
  forget to erase the lsp/Makefile the wrong patches will be applied.
  
  <<GCLVERSION>>=
! GCLVERSION=@axiom_gcl_version@
  @
  
  \subsubsection{The [[GCLOPTS]] configure variable}
*** configure.ac.pamphlet	(revision 15812)
--- configure.ac.pamphlet	(local)
*************** else
*** 267,272 ****
--- 267,316 ----
      AC_SUBST(NOWEAVE)
  fi
  
+ ## -----------------------
+ ## -- Which GCL to use? --
+ ## -----------------------
+ ##
+ ## By default, we assume that GCL is not present in the build
+ ## environment, so we should roll our own.  That is a reasonable
+ ## assumption since GCL does not seem to be as widespread as one
+ ## would like to think.
+ 
+ axiom_use_gcl=
+ AC_ARG_WITH([gcl], [assume GCL is present in the build environment],
+             [case $withval in
+                 yes|no) axiom_use_gcl=$withval ;;
+                 *) AC_MSG_ERROR([erroneous value for --with-gcl]) ;;
+              esac])
+ 
+ ## Check for GCL only if we're told to or if we should guess
+ if test x$axiom_use_gcl != xno; then
+     AC_CHECK_PROG([GCL], [gcl], [gcl])
+ else
+     ## Make sure GCL is Autoconf-substituted in generated files
+     AC_SUBST(GCL)
+     :
+ fi
+ 
+ ## If we were told to use system-installed GCL, but the 'gcl' command
+ ## is missing from the build environment, then something is wrong.
+ if test -z $GCL; then
+     if test x$axiom_use_gcl = xyes; then
+         AC_MSG_ERROR([--with-gcl is specified but GCL is missing])
+     fi
+ 
+     ## gcl-2.6.8pre is the most recent version we use.
+     axiom_gcl_version=gcl-2.6.8pre
+     GCL=$axiom_build_bindir/gcl
+ 
+     ## FIXME: add gcl to axiom_required_build_utils
+ 
+ else
+     axiom_gcl_version=gcl-system
+ fi
+ AC_SUBST(axiom_gcl_version)
+ 
+ 
  AC_SUBST(axiom_required_build_utils)
  @
  
\start
Date: Tue, 29 Aug 2006 11:44:11 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Dimensions as types...

Hi Cliff,

I'll copy that to axiom-developer, because it might start another 
discussion about dimensions in Axiom.

> So what we need, in effect, is types that have types.

You have NOTHING in Aldor that has no type.

> And we also need a * operation that can take two types that are
> themselves of type Dimension and generate a new type (also of type
> Dimension) as the output type, not determined in advance because the
> output type is in fact GENERATED based on the input types.

Do you see a problem?

> Does Aldor permit this "types having types" behavior?

Of course.

Analyse the code below and ask if something is unclear.
I would very much like to see an upcoming dimensions package programmed 
along these lines. There are certainly lots of things just rudimentary, 
but as you can see, multiplying types to construct new types is not at 
all complicated. That is the power of having types as first class citizens.

Run the program via

 >aldor -grun -laldor -mno-mactext -mno-abbrev dimension.as
a = 2e-2*meter
b = 1.08000003e+4*second
c = 2.16000008e+2*meter*second
d = 6.48000001e+2*meter*second*second

And if you think that the numbers are wrong, then complain at aldor.org. 
My guess is that the SingleFloat implementation has a bug when it comes 
to printing floats.

Enjoy.

Ralf

PS: I think it gets a bit complicated to convince Aldor to believe that
Length*Time and Time*Length are not so different. With the code below 
these are different dimensions.

---BEGIN dimension.as
#include "aldor"
#include "aldorio"

macro Unit == String; -- for simplicity
macro R == SingleFloat; -- R could be a parameter to Dimension.
extend SingleFloat: with {
	integer: Literal -> %; -- to make input easier
} == add {
	integer(l: Literal): % == integer(l)$MachineInteger :: %;
}
import from R;

define Dimension: Category == with {
	OutputType;
	value: % -> R;
	unit: % -> Unit;
	bracket: (R, Unit) -> %;
	apply: (R, %) -> %;
}

AuxiliaryDimension: Dimension == add {
	Rep == Record(val: R, unit: Unit);
	import from Rep;
	(tw: TextWriter) << (x: %): TextWriter == {
		tw << rep(x).val << "*" << rep(x).unit;
	}
	value(x: %): R == rep(x).val;
	unit(x: %): Unit == rep(x).unit;
	bracket(r: R, u: Unit): % == per [r, u];
	apply(r: R, x: %): % == per [r * value x, unit x];
}

Length: Dimension with {
	meter: %;
	centimeter: %;
} == AuxiliaryDimension add {
	meter: % == [1, "meter"];
	centimeter: % == [1/100, "meter"];
}

Time: Dimension with {
	second: %;
	minute: %;
	hour: %;
} == AuxiliaryDimension add {
	second: % == [1, "second"];
	minute: % == [60, "second"];
	hour: % == [3600, "second"];
}

(*)(A: Dimension, B: Dimension): Dimension with {
	*: (A, B) -> %;	
} == AuxiliaryDimension add {
	(a: A) * (b: B): % == {
		[value a * value b, unit a + "*" + unit b];
	}
}

main(): () == {
	a: Length := 2 centimeter;
	b: Time := 3 hour;
	c: (Length * Time) := a * b;
	import from Length * Time * Time;
	d := c * 3 second;
	stdout << "a = " << a << newline;
	stdout << "b = " << b << newline;
	stdout << "c = " << c << newline;
	stdout << "d = " << d << newline;
}

main();
---END dimension.as

\start
Date: 29 Aug 2006 05:02:53 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Dimensions as types...

Ralf Hemmecke writes:

| Hi Cliff,
| 
| I'll copy that to axiom-developer, because it might start another
| discussion about dimensions in Axiom.
| 
| > So what we need, in effect, is types that have types.
| 
| You have NOTHING in Aldor that has no type.

Indeed.  

At the logical level, as I have observed some time ago, there is an
inconsistency problem with Type:Type.  I'm wondering how Aldor gets
away with that.  Many languages (mostly functional) use stratified
types. 

\start
Date: Tue, 29 Aug 2006 12:42:04 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Type: Type

> At the logical level, as I have observed some time ago, there is an
> inconsistency problem with Type:Type.  I'm wondering how Aldor gets
> away with that.  Many languages (mostly functional) use stratified
> types.

That question should be asked at aldor-l.

Can you construct a paradox that demonstrates the problem in terms of 
Aldor code? To me it looks like the class (not set) of all classes. 
Would there be a problem in class theory?

\start
Date: 29 Aug 2006 06:24:46 -0500
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Install problem with GCL-2.6.8pre

Hi Camm,

I'm experiencing a problem when installing GCL-2.6.8pre in a custom prefix.

Here are the details:

* check out cvs GCL-2.6.8pre

* configure --prefix=$HOME

* make # works fine

* make install # troublesome

the install fails with the following error:

chmod a+x /home/gdr/lib/gcl-2.6.8/gcl-tk/gcltksrv ; fi
if test "/usr/share/emacs/21.3/site-lisp" != "" ; then (cd elisp ; make install DESTDIR=) ; fi
make[2]: Entering directory `/media/usbdisk_2/software.src/GCL/2.6.8pre/elisp'
mkdir -p /usr/share/emacs/21.3/site-lisp
cp *.el /usr/share/emacs/21.3/site-lisp
cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/add-default.el': Permission denied
cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/ansi-doc.el': Permission denied
cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/dbl.el': Permission denied
cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/doc-to-texi.el': Permission denied
cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/gcl.el': Permission denied
cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/man1-to-texi.el': Permission denied
cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/smart-complete.el': Permission denied
cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/sshell.el': Permission denied


The problem seems to be that GCL wants to install elisp files in
$(EMACS_SITE_LISP).  User installing GCL (like me, or as part of another
package like Axiom) may not have write permission to that directory.
Any particular reason why the elisp files are not installed in
$(prefix)/share/emacs for example?

\start
Date: Tue, 29 Aug 2006 05:11:35 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Dimensions as types...

--- Ralf Hemmecke wrote:

> Hi Cliff,
> 
> I'll copy that to axiom-developer, because it might start another 
> discussion about dimensions in Axiom.

OK :-).
 
> > So what we need, in effect, is types that have types.
> 
> You have NOTHING in Aldor that has no type.

OK.

> > And we also need a * operation that can take two types that are
> > themselves of type Dimension and generate a new type (also of type
> > Dimension) as the output type, not determined in advance because
> > the output type is in fact GENERATED based on the input types.
> 
> Do you see a problem?

Well, I think it's just that I'm not thinking clearly enough yet in
Aldor.  I was thinking maybe something like (warning, pseudocode, maybe
even conceptually wrong)

define Dimension: Category == with {
     "*" : (%,%) -> %
}

DerivedDimension: AbelianGroup with {
     "*": (A: Dimension, B: Dimension) -> C: Dimension
     "^": (D: Dimension, E: Integer) -> F: Dimension
} == add{
     ***Some A*B operation that returns C according to Abelian rules***
}

where the return type of the "*" operation is C and defined by
multiplying A and B, but A, B, and C all must be Dimensions.  Then,
Unit would be a Rep with a name unit and a type of dimension Dim, and
multiplying units u1 and u2 would result in a name of 
unit1:String*unit2:String -> unit3:String with a type Dim1:Dimension *
Dim2:Dimension -> Dim3:Dimension.  Quantities then would have a rep of
a value (integer, float, what have you) and a Unit, and the type of a
Quantity would be Union(Float,Dimension) or something of the sort.

> > Does Aldor permit this "types having types" behavior?
> 
> Of course.
> 
> Analyse the code below and ask if something is unclear.
> I would very much like to see an upcoming dimensions package
> programmed along these lines. There are certainly lots of things just
> rudimentary, but as you can see, multiplying types to construct new
> types is not at all complicated. That is the power of having types as
> first class citizens.

Thanks!  I will study what you have done in more detail.  Am I correct
in that you are not actually "multiplying" dimensions in the Abelian
group sense but are combining the names of the types and the "*"
character?  (/me winces at what is probably a horrible description).

> Enjoy.

Thanks again!
 
> Ralf
> 
> PS: I think it gets a bit complicated to convince Aldor to believe
> that Length*Time and Time*Length are not so different. With the code
> below these are different dimensions.

I think in an Abelian group aren't a*b and b*a the same?  I think
that's why the literature is more or less at a consensus that
dimensions should be modeled by Abelian groups over the multiplicative
operation.

\start
Date: Tue, 29 Aug 2006 08:51:47 -0400
From: Stephen Watt
To: Ralf Hemmecke
Subject: Re: [Aldor-l] Type: Type
Cc: Gabriel Dos Reis

You are correct that there is a potential inconsistency.

We avoid Russel's paradox by limiting the operations for
constructing and testing membership in type categories.

Note that many programming languages have the problem of
allowing types with no elements, which can lead to the type
theory equivalent of a division by zero error.

Aldor is no exception in this regard:  It is possible to construct
a domain with no effective way to make elements.  

These kinds of errors have to be seen as  bugs in programs, just as 
division by zero is a programming error and not an invalidation of
integer arithmetic.

-- Stephen
    

On Tue, Aug 29, 2006 at 12:42:04PM +0200, Ralf Hemmecke wrote:
> > At the logical level, as I have observed some time ago, there is an
> > inconsistency problem with Type:Type.  I'm wondering how Aldor gets
> > away with that.  Many languages (mostly functional) use stratified
> > types.
> 
> That question should be asked at aldor-l.
> 
> Can you construct a paradox that demonstrates the problem in terms of 
> Aldor code? To me it looks like the class (not set) of all classes. 
> Would there be a problem in class theory?

\start
Date: Tue, 29 Aug 2006 15:08:28 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Dimensions as types...

Hi Cliff,
> Well, I think it's just that I'm not thinking clearly enough yet in
> Aldor.  I was thinking maybe something like (warning, pseudocode, maybe
> even conceptually wrong)
> 
> define Dimension: Category == with {
>      "*" : (%,%) -> %
> }
> 
> DerivedDimension: AbelianGroup with {
>      "*": (A: Dimension, B: Dimension) -> C: Dimension
>      "^": (D: Dimension, E: Integer) -> F: Dimension
> } == add{
>      ***Some A*B operation that returns C according to Abelian rules***
> }

First of all, forget these double quotes around * an ^. We are speaking 
Aldor here.

Then I actually see no reason for adding the "C:" and "F:" above.

 > Quantities then would have a rep of
> a value (integer, float, what have you) and a Unit, and the type of a
> Quantity would be Union(Float,Dimension) or something of the sort.

Why would the type of a quantity be a union of Float and Dimension? You 
are not telling me that you must model dimensionless constants? These 
constants should be modelled as being of type Dimension. You did the 
same thing in your text. That is the dimension <1>. Am I wrong?

>>> Does Aldor permit this "types having types" behavior?
>> Of course.

> Thanks!  I will study what you have done in more detail.  Am I correct
> in that you are not actually "multiplying" dimensions in the Abelian
> group sense but are combining the names of the types and the "*"
> character?

That was for simplicity reasons. Of course, what I called Unit should be 
an multiplicative Abelian group. Also Dimension should be modelled a bit 
differently than what I did. Maybe one needs an extra wrapper domain 
that models the abelian group behaviour.

The problem is that it is not so terribly easy to construct a 
commutative type constructor. But one can certainly do it.

\start
Date: Mon, 21 Aug 2006 16:46:42 -0400
From: Igor Khavkine
To: Martin Rubey
Subject: Re: [Axiom-math] Curious behavior of Taylor series

On 21 Aug 2006 22:13:13 +0200, Martin Rubey wrote:
> Dear Igor,
>
> great that you found the reason. Do you think you'd have the time to document
> properly just the function powern? What you found is not the first bug in these
> 10 lines of code :-(

I can try. But I hope my small patch will still be accepted even if I
can't find the time to thoroughly document that function.

In any case, I'm not sure I completely understand what powern does.
I've looked at servarl power series manipulation routines already, but
I get stumped every time I run into this object: Y from
ParadoxicalCombinatorsForStreams. Can someone explain what it does?

\start
Date: Sat, 26 Aug 2006 09:38:42 -0600
From: Robert Dodier
To: Camm Maguire
Subject: Re: Misc. re: 2.6.7

Hello Camm, you wrote:

> si::newline is a funtion which currently appears unused in the
> debugging code.

OK, thanks for the info. I resolved the Maxima problem
(I believe) by not calling si::newline (and calling a local
version instead, as with other Lisp implementations).

> The large number segfault issue has also been resolved in 2.6.8pre,
> though the division takes essentially forever.  In 2.7.0, we use gmp's
> gcd for bignums, so your example finishes in seconds.  Given the time
> 2.7.0 is taking, perhaps it is worth migrating this one feature back
> into 2.6.8.  Comments most welcome.

Well, operations with numbers like 255^(2^22) are fairly
rare, so I don't think it is worth the trouble to backport
the patch from 2.7.0.

> Regarding the windows gazonk files issue, as I do not have access to
> such a machine, could one please check the variable
> compiler::*keep-gaz*?  These files are supposed to be deleted
> automatically unless this is set.

In Maxima 5.9.3.99rc2 / GCL 2.6.7 on Linux, I find
compiler::*keep-gaz* is nil. So I guess that's OK.
I don't have a Windows box at hand, maybe someone
else can check that.

I notice the GCL version in the bug report is 2.6.5.
Was *keep-gaz* introduced after that?

> The *read-base* error I've just fixed in 2.6.8pre by
> backporting a function from cvs head.

Terrific!

> Are these all of our issues outstanding?

Well, the one other Maxima-related issue that I can see
(after scanning the GCL bug list) is bug #14367,
dribble file has newlines in wrong places.

Thanks a lot for all your hard work!

\start
Date: 29 Aug 2006 15:32:57 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: re: Dimensions as types...

Cliff Yapp writes:

> Well, I think it's just that I'm not thinking clearly enough yet in
> Aldor.  I was thinking maybe something like (warning, pseudocode, maybe
> even conceptually wrong)
> 
> define Dimension: Category == with {
>      "*" : (%,%) -> %
> }
> 
> DerivedDimension: AbelianGroup with {
>      "*": (A: Dimension, B: Dimension) -> C: Dimension
>      "^": (D: Dimension, E: Integer) -> F: Dimension
> } == add{
>      ***Some A*B operation that returns C according to Abelian rules***
> }

I just wanted to point out that you can give the Aldor Category "Dimension" an
algebraic structure. This is in fact one of the main advantages of Aldor over
SPAD.

The code will read roughly as follows:

Scalar: Dimension with {
        scalar: %;
} == AuxiliaryDimension add {
        scalar: % == [1, ""];
}

DimensionThing: Group == add {
        Rep == Dimension;
        1: % == per ConstantDimension;
        (x: %) * (y: %): % == per(x * y);
        (x: %) / (y: %): % == ...
}

Thus, each "element" in the domain DimensionThing has type
Dimension. Multiplying two dimensions gives you another dimension. The unit
(i.e., neutral) element is the "dimension" Scalar.

Keep in mind: in Aldor, types are first class. They even can be the elements of
a domain.

\start
Date: Tue, 29 Aug 2006 16:12:46 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: [build-improvements] make clean and xgcl

Hello Gaby,

I tested the build-improvements branch and if we build gcl the XLIB
(xgcl) package is compiled in (gcl and AXIOMsys are thus linked against
the X libraries). Don't know what you think about this, it's just a
remark.

Another thing, more important, is that if you stop the build process
after the creation of bootsys, do a make clean, reconfigure and remake,
the build process stops and complains about the fact that lisp can not
be found (with or without building gcl).

And of course many thanks for your work.

\start
Date: Tue, 29 Aug 2006 16:45:19 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Dimensions as types...

> I just wanted to point out that you can give the Aldor Category "Dimension" an
> algebraic structure. This is in fact one of the main advantages of Aldor over
> SPAD.
> 
> The code will read roughly as follows:
> 
> Scalar: Dimension with {
>         scalar: %;
> } == AuxiliaryDimension add {
>         scalar: % == [1, ""];
> }
> 
> DimensionThing: Group == add {
>         Rep == Dimension;
>         1: % == per ConstantDimension;
>         (x: %) * (y: %): % == per(x * y);
>         (x: %) / (y: %): % == ...
> }

Yep, that is exactly what I called a wrapper domain in my previous mail. 
And note that the line

(x: %) * (y: %): % == per(x * y);

is wrong. It should read "per(rep x * rep y)" on the right hand side.
And note also that the * on the right hand side is the _domain 
constructor_ that I defined in the file dimension.as.

The main point is that one defines the various dimension domains like 
Length, Time, etc. on the top level with basically no relation to each 
other. In order to work with these things one creates another domain 
that has domains like Length, Time, Mass, etc as elements.

Ralf

PS: Martin probably wanted Scalar = ConstantDimension. No?

\start
Date: 29 Aug 2006 16:48:50 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: Dimensions as types...

Ralf Hemmecke writes:

> > I just wanted to point out that you can give the Aldor Category "Dimension" an
> > algebraic structure. 

> > Scalar: Dimension with {
> >         scalar: %;
> > } == AuxiliaryDimension add {
> >         scalar: % == [1, ""];
> > }
> > DimensionThing: Group == add {
> >         Rep == Dimension;
> >         1: % == per ConstantDimension;
> >         (x: %) * (y: %): % == per(x * y);
> >         (x: %) / (y: %): % == ...
> > }
>
> note that the line
> 
> (x: %) * (y: %): % == per(x * y);
> 
> is wrong. It should read "per(rep x * rep y)" on the right hand side.

Yes yes, you know me by now. Thank God there is somebody correcting me when
necessary! (honestly)

> PS: Martin probably wanted Scalar = ConstantDimension. No?

Yes. Isn't that synonymous?

\start
Date: 29 Aug 2006 10:01:56 -0500
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: [build-improvements] make clean and xgcl

| Hello Gaby,
|
| I tested the build-improvements branch and if we build gcl the XLIB
| (xgcl) package is compiled in (gcl and AXIOMsys are thus linked against
| the X libraries). Don't know what you think about this, it's just a
| remark.

Ah, I have no particular idea about which direction to go here.  What
would be your recommendation?

| Another thing, more important, is that if you stop the build process
| after the creation of bootsys, do a make clean, reconfigure and remake,
| the build process stops and complains about the fact that lisp can not
| be found (with or without building gcl).

yes, that is very annoying.  We don't have a good dependency at the
moment.  We should have one.  I know I had similar problem in the past
and I heared that it would NOT be recommended.  I think that is wrong.
We should have a dependency that make knows about.  That way we can
also have a parallel build (make -jN) -- Axiom just takes too long to
build.

I'm working in major restructuring of the makefiles.  I have class
today, so unfortunately I won't do much today.

But, please, list your priority about the build machinery.

\start
Date: Tue, 29 Aug 2006 11:15:13 -0400
From: Tim Daly
To: list
Subject: --patch-50

Patch 50 is up in arch.

There are three major things of note.

FEDORA CORE 5

There is the Fedora Core 5 issue. There is a new branch of
the configure script that will tell you to put 'fedora5' as the
last directory on the AXIOM command thus:

  export AXIOM=`pwd`/mnt/fedora5

The issue is two-fold. First, there is an X library issue which
seems to require a special case for fedora 5. Renaud brought this
to my attention at ISSAC. I've tried to resolve this issue across
all of the platforms without success. Second, there is the GCL issue.




GCL-2.6.8PRE VS GCL-2.6.8PRE

There is an upgrade of the system to run on the latest GCL
but the patches are not compatible with the current axiom version
of GCL. Axiom's policy has been to use a 'stepping stone' approach.
That is, we keep the last version of GCL and the previous version
of GCL in the distribution in case the new version cannot be built
on some platforms.

In this case there is a bit of an issue because the latest GCL (2.6.8pre)
requires changes that are incompatible with the prior version of
GCL (2.6.8pre). As you can see there is no way to distinguish these
versions by name. They also cannot be distinguished at runtime.
So Axiom now has gcl-2.6.8pre and gcl-2.6.8pre2.

   (Gaby, how will automake handle this?)

The gcl-2.6.8pre is the old version, gcl-2.6.8pre2 is the new version.
By default the system builds on the latest (gcl-2.6.8pre2) version.




GCL-2.6.8PRE2 AND FEDORA CORE 5

It appears that GCL-2.6.8pre (latest version, which we call gcl-2.6.8pre2)
will not build on Fedora Core 5. Thus the Fedora 5 version will 
automatically build using the GCL-2.6.8pre version.

I have not yet had time to resolve this issue. It has been delayed
by a motherboard failure on my fedora 5 system which should be
resolved today.




NEXT STEPS

  *) update the CVS on savannah
  *) update the CVS on sourceforge
  *) create a diif list for SVN on sourceforge
  *) work with Gaby to apply patches to SVN Silver
  *) work with Camm to resolve Fedora 5 compile issues



CHANGELOG

====================================================================

Summary: many patches
Keywords: 

20060829 tpd --patch-50
20060829 tpd Makefile VERSION changed
20060829 tpd Makefile GCLVERSION=gcl-2.6.8pre in fedora5 build
20060826 cxm src/interp/patches.lisp add namestring to current-directory
20060821 cxm src/interp/sockio.lisp sock_get_float float->double
20060821 tpd lsp/Makefile add gcl-2.6.8pre2
20060821 tpd zips/gcl-2.6.8pre2.unixport.makefile.patch added
20060821 tpd zips/gcl-2.6.8pre2.unixport.init_gcl.lsp.in.patch added
20060821 tpd zips/gcl-2.6.8pre2.h.linux.defs.patch added
20060821 tpd zips/gcl-2.6.8pre2.configure.patch added
20060821 tpd zips/gcl-2.6.8pre2.configure.in.patch added
20060821 tpd zips/gcl-2.6.8pre2.cmpnew.gcl_cmpflet.lsp.patch added
20060821 tpd zips/gcl-2.6.8pre2.tgz added
20080821 gdr src/algebra/op.spad fix typo in comment
20060817 gxv src/algebra/Makefile removed duplicate \section
20060815 cxm src/inter/hash.lisp rewrite mem_value function
20060815 tpd src/inter/cfuns.lisp escape noweb chunk syntax in verbatim
20060815 cxm src/inter/cfuns.lisp rewrite MYCOMBINE function
20060814 tpd share/doc/hypertex/pages/util.ht remove ../../share path
20060813 tpd src/hyper/token generate token.h, not token.c
20060813 gdr Makefile rename INSTALL to DESTDIR
20060803 tpd src/hyper/Makefile remove -l Xpm from hypertex stanza
20060803 tpd Makefile document the LISP variable
20060730 tpd src/interp/dedbugsys.lisp
20060730 tpd configure handle fedora5 systems
20060729 tpd src/input/zimmer.input change & to and
20060725 tpd src/doc/book remove redundant code
20060724 tpd src/algebra/transsolve.spad escape macro char
20060723 tpd src/interp/Makefile copy the src/doc/ps subdir 
20060723 tpd Makefile use localbfd
20060722 tpd src/lib/bsdsignal fix latex typo
20060716 rxr src/hyper/Makefile use -l Xpm for Fedora 5
20060716 rxr src/graph/view2D/Makefile use -l Xpm for Fedora 5
20060702 rhx src/lib/bsdsignal.c fix \wf typo
20060603 mxr src/algebra/perm.spad handle fixed points
20060512 gxv src/doc/book fixed typos
20060506 gdr lsp/Makefile remove <<gcl-2.6.8pre.tail-recursive.patch>>
20060506 gdr lsp/Makefile remove <<gcl-2.6.7.tail-recursive.patch>>
20060506 gdr lsp/Makefile remove <<gcl-2.6.7pre.tail-recursive.patch>>
20060506 gdr zips/gcl-2.6.8pre.cmpnew.gcl_cmpcall.lsp.patch removed
20060506 gdr zips/gcl-2.6.7pre.cmpnew.gcl_cmpflet.lsp.patch removed
20060506 gdr zips/gcl-2.6.7pre.cmpnew.gcl_cmpcall.lsp.patch removed
20060506 gdr zips/gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch removed
20060506 gdr zips/gcl-2.6.7.cmpnew.gcl_cmpcall.lsp.patch removed
20060425 gxv src/doc/DeveloperNotes )end{verbatim) -> \end{verbatim}

\start
Date: Tue, 29 Aug 2006 09:13:48 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Dimensions as types...

--- Ralf Hemmecke wrote:

> Hi Cliff,
> > Well, I think it's just that I'm not thinking clearly enough yet in
> > Aldor.  I was thinking maybe something like (warning, pseudocode,
> maybe
> > even conceptually wrong)
> > 
> > define Dimension: Category == with {
> >      "*" : (%,%) -> %
> > }
> > 
> > DerivedDimension: AbelianGroup with {
> >      "*": (A: Dimension, B: Dimension) -> C: Dimension
> >      "^": (D: Dimension, E: Integer) -> F: Dimension
> > } == add{
> >      ***Some A*B operation that returns C according to Abelian
> rules***
> > }
> 
> First of all, forget these double quotes around * an ^. We are
> speaking Aldor here.

OK.

> Then I actually see no reason for adding the "C:" and "F:" above.

I think I got ahead of myself - I was thinking about what I wanted to
happen at the unit level.  I agree that a dimension * a dimension is a
dimension, so C and F aren't needed.

Looking ahead to units:

Let's say I multiply meters:Length and seconds:Time together.  I want
to end up with meters*seconds:Length*Time, which is both a new unit and
a new dimensional type.

For this to work and generate the new type Length*Time, but not in
general allow Length*Anything as a new type, both Length and Time must
in turn be of type Dimension. (meter:Length:Dimension?)  So from the
point of view of meters*seconds, the resulting type is different from
BOTH of the input types and cannot be predicted - it must be
calculated.  So I'm not sure what the *: (%,%) -> % should look like
for units, because the type of none of the inputs to * are determined
in advance.  All that is known in advance is the type of the types of
the inputs - the types actually operating at the level of the *
operation are not known until the computation is made.

Manipulating Length*Time in dimensional analysis is much simpler - they
are both constants of type Dimension and return an expression that is
also of type Dimension, in the same way that 1*2 are integers and
return a result of type integer.  But meters*seconds is not so simple,
because meters of type length and seconds of type time multiply to give
meters*seconds of type length*time.  The governing behavior of the
legality of * for units is not the type of the unit but the type of the
dimension of the unit, and I'm not sure how to specify that.  That was
why I had *: (A: Dimension, B: Dimension) -> C: Dimension (which should
have been in the unit entry not the DerivedDimension entry), as a way
to try and express that the demand for type correctness is not at the
level of A, B and C (length, time and length*time) but that the type of
any type input into or returned out of the * operation must be of type
Dimension.  Otherwise, there are no constraints on the types that may
be multiplied, which would seem to be the same as saying that you can
multiply 1:Integer*2.0:Float*(2/3)Fraction as long as they are all
Numbers, and Integer*Float*Fraction would then become a new numerical
type for the value 4/3. (Note that this is different from the +
operator, which will need to enforce type not at the type of the type
level but at the A,B,C level -> length+time will fail, as will
length+anything where anything is any type other than length, whether
or not anything is of type dimension.)

Sorry if I'm saying this incorrectly, but hopefully my concern is
clear.

>  > Quantities then would have a rep of
> > a value (integer, float, what have you) and a Unit, and the type of
> a
> > Quantity would be Union(Float,Dimension) or something of the sort.
> 
> Why would the type of a quantity be a union of Float and Dimension?
> You are not telling me that you must model dimensionless constants?
> These constants should be modelled as being of type Dimension. You
> did the same thing in your text. That is the dimension <1>. Am I 
> wrong?

I'm not sure - I might have said that wrong.  I would argue that a
dimensionless constant has two components - the numerical value of the
constant, which has some numerical type, and the dimensional type <1>. 
The dimensional type <1> is what has the type Dimension - <1> is itself
a type as well - the type of a dimensionless constant *as a whole* is
<1>.  At least, I would like it to be - I had assumed that since the
numerical type of the constant number must be retained that would wind
up with the expression of the constant being some combination of the
two, but maybe that doesn't have to be the case.

> >>> Does Aldor permit this "types having types" behavior?
> >> Of course.
> 
> > Thanks!  I will study what you have done in more detail.  Am I
> > correct in that you are not actually "multiplying" dimensions in
> > the Abelian group sense but are combining the names of the types
> > and the "*" character?
> 
> That was for simplicity reasons. Of course, what I called Unit should
> be an multiplicative Abelian group. Also Dimension should be
> modelled a bit differently than what I did. Maybe one needs an extra
> wrapper domain that models the abelian group behaviour.

That could be.

> The problem is that it is not so terribly easy to construct a 
> commutative type constructor. But one can certainly do it.

Yes, I think that is one of the challenges of this task.  The Sun team
deliberately chose dimensions and units to look at because they are a
challenge to represent in conventional type systems in most languages
(actually, impossible might be a better word - Sun basically made a new
one).  I am hopeful that Aldor can do it but it certainly will require
some not-normal ways of working with and generating types.

\start
Date: Tue, 29 Aug 2006 18:58:29 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Dimensions as types...

Hi Cliff,

> Looking ahead to units:

> Let's say I multiply meters:Length and seconds:Time together.  I want
> to end up with meters*seconds:Length*Time, which is both a new unit and
> a new dimensional type.

What do you think the code

main(): () == {
	a: Length := 2 centimeter;
	b: Time := 3 hour;
	c: (Length * Time) := a * b;
	import from Length * Time * Time;
	d := c * 3 second;
	stdout << "a = " << a << newline;
	stdout << "b = " << b << newline;
	stdout << "c = " << c << newline;
	stdout << "d = " << d << newline;
}

that I sent before represents?

Look at the line

        c: (Length * Time) := a * b;

It constructs a type Length*Time and imports the operations from that 
NEW domain. Only after that import it is clear what the * on the right 
hand side actually is. The * on the left and the * on the right hand 
side are terribly different. The first is of type

(Dimension, Dimension) -> Dimension

and the second of type

(Length, Time) -> Length*Time;

And my code is unable to do something like

Integer * String

because neither Integer nor String is of type Dimension, so the (first) 
* cannot apply.

Take your time and study my code in detail. At each step you should 
understand what it is doing.

For example, do you know why I could simply write

	a: Length := 2 centimeter;

? There is only a space between 2 and centimeter.

\start
Date: 29 Aug 2006 16:26:43 -0500
From: Gabriel Dos Reis
To: Camm Maguire
Subject: GCL-2.6.8pre unable to make new image

Hi Camm,

  GCL-2.6.9pre, checkout of cvs as of this morning, has problems
making new lisp image.  More precisely, the instruction

     % echo '(compiler::link nil "foo")' | gcl

has GCL die with the message

[...]
loading /home/gdr/lib/gcl-2.6.8/unixport/../xgcl-2/sysdef.lisp

Error: Cannot open the file /home/gdr/lib/gcl-2.6.8/unixport/../xgcl-2/sysdef.lisp.
Error signalled by PROGN.
Broken at SYSTEM::BREAK-LEVEL.  Type :H for Help.
COMPILER>>
"foo"


Indeed the file sysdef.lisp is NOT present in the install directory

        /home/gdr/lib/gcl-2.6.8/unixport/xgcl-2/

it looks like the install machinery forgot to install it.

\start
Date: 29 Aug 2006 17:12:47 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: --patch-50

Tim Daly writes:

| Patch 50 is up in arch.
| 
| There are three major things of note.
| 
| FEDORA CORE 5
| 
| There is the Fedora Core 5 issue. There is a new branch of
| the configure script that will tell you to put 'fedora5' as the
| last directory on the AXIOM command thus:
| 
|   export AXIOM=`pwd`/mnt/fedora5
| 
| The issue is two-fold. First, there is an X library issue which
| seems to require a special case for fedora 5. Renaud brought this
| to my attention at ISSAC. I've tried to resolve this issue across
| all of the platforms without success.

Is this issue related to missing libXpm?  Or is it a different one?


| Second, there is the GCL issue.
| 
| GCL-2.6.8PRE VS GCL-2.6.8PRE
| 
| There is an upgrade of the system to run on the latest GCL
| but the patches are not compatible with the current axiom version
| of GCL. Axiom's policy has been to use a 'stepping stone' approach.
| That is, we keep the last version of GCL and the previous version
| of GCL in the distribution in case the new version cannot be built
| on some platforms.
| 
| In this case there is a bit of an issue because the latest GCL (2.6.8pre)
| requires changes that are incompatible with the prior version of
| GCL (2.6.8pre). As you can see there is no way to distinguish these
| versions by name. They also cannot be distinguished at runtime.
| So Axiom now has gcl-2.6.8pre and gcl-2.6.8pre2.

Maybe we should talk to Camm to either make public numbered 
pre-releases or include the date of official preleases in the tarball
name. 

|    (Gaby, how will automake handle this?)

I'm afraid I have lost the distinctive features of old 2.6.8pre
vs. new 2.6.8pre.  If we need to run the system before knowing it is
bad then we're almost out of luck. 

[...]

| GCL-2.6.8PRE2 AND FEDORA CORE 5
| 
| It appears that GCL-2.6.8pre (latest version, which we call gcl-2.6.8pre2)
| will not build on Fedora Core 5. Thus the Fedora 5 version will 
| automatically build using the GCL-2.6.8pre version.

OK, if you decide in advance that Axiom won't use GCL-2.6.8pre2 then,
we can handle this based on the output of config.guess -- or
approximate it as you currently do on the golden branch.  But, again
I'm unclear about what the build failure is.  Could you elaborate?

| I have not yet had time to resolve this issue. It has been delayed
| by a motherboard failure on my fedora 5 system which should be
| resolved today.
| 
| 
| 
| 
| NEXT STEPS
| 
|   *) update the CVS on savannah
|   *) update the CVS on sourceforge

Can we have only one master CVS with the othe one rsync-ing? 

|   *) create a diif list for SVN on sourceforge
|   *) work with Gaby to apply patches to SVN Silver
|   *) work with Camm to resolve Fedora 5 compile issues

OK.

\start
Date: Tue, 29 Aug 2006 18:42:20 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: --patch-50

> Is this issue related to missing libXpm?  Or is it a different one?

Yes. I'm trying to resolve this across all of the system.


> Maybe we should talk to Camm to either make public numbered 
> pre-releases or include the date of official preleases in the tarball
> name. 
> 
> |    (Gaby, how will automake handle this?)
> 
> I'm afraid I have lost the distinctive features of old 2.6.8pre
> vs. new 2.6.8pre.  If we need to run the system before knowing it is
> bad then we're almost out of luck. 

I'm not sure what the issue is about updating the gcl version numbers.
i was unable to find a way to distinguish the two cases except at build
time. There is no runtime #+ flag. However since I know which one I
need at build time I just set the correct version in the Makefile.pamphlet
fedora stanza.

> Can we have only one master CVS with the othe one rsync-ing? 

Two questions, why? and how?. It's only two cvs stores and 
it takes only a few minutes to update the second once the first
is complete.

At this time all of the CVS files are up to date.

I've checked out the SVN branch and will be creating a set
of diff-Naur files for you to look at.

\start
Date: Wed, 30 Aug 2006 01:48:18 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: [build-improvements] make clean and xgcl

Le mardi 29 ao=FBt 2006 =E0 10:01 -0500, Gabriel Dos Reis a =E9crit :
> Vanuxem Gr=E9gory Gregory Vanuxem writes:
>
> | Hello Gaby,
> |
> | I tested the build-improvements branch and if we build gcl the XLIB
> | (xgcl) package is compiled in (gcl and AXIOMsys are thus linked again=
st
> | the X libraries). Don't know what you think about this, it's just a
> | remark.
>
> Ah, I have no particular idea about which direction to go here.  What
> would be your recommendation?

Personally I think that if we don't use a package we can remove it. So
for gcl it can be removed from the lisp image and added later if
necessary. In fact there is also the TK package that Axiom doesn't use
but I don't know if and how it is possible to remove it.

> | Another thing, more important, is that if you stop the build process
> | after the creation of bootsys, do a make clean, reconfigure and remak=
e,
> | the build process stops and complains about the fact that lisp can no=
t
> | be found (with or without building gcl).
>
> yes, that is very annoying.  We don't have a good dependency at the
> moment.  We should have one.  I know I had similar problem in the past
> and I heared that it would NOT be recommended.  I think that is wrong.
> We should have a dependency that make knows about.  That way we can
> also have a parallel build (make -jN) -- Axiom just takes too long to
> build.

I think so.

> I'm working in major restructuring of the makefiles. 

Yes the big part. A quick note, it would be great if a modified
src/algebra/*.spad.pamphlet file can be used by Axiom after a remake. In
fact I think that your work will fix that. More precisely actually (it
used to work in the past) if someone modify an algebra pamphlet file and
type make in the root directory the modified file is apparently compiled
but not copied to the mnt/linux/algebra directory. I have not
investigated this problem but it's really annoying when you want to add
some algebra files and modify them (I even don't speak about the
dependency issues).

>
> I have class
> today, so unfortunately I won't do much today.
>
> But, please, list your priority about the build machinery.

I haven't no priority at all for this branch, it's not the silver
branch, it's a work in progress branch (as silver you can say). So if
there are some problems that will be fixed later because some
preliminary work has to be done it's not a problem. But what about
adding a file, say README.build-improvement, that quickly explain how to
build Axiom and lists the known issues, the workarounds and why not the
TODO (it can refer to the "gold" README for more information about
Axiom).

\start
Date: 29 Aug 2006 23:24:19 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: --patch-50

Tim Daly writes:

| > Is this issue related to missing libXpm?  Or is it a different one?
| 
| Yes. I'm trying to resolve this across all of the system.

Aha.  
libXpm does not seem to be much appreciated these days among system
packagers.  It has gone through deprecation, active non-support,
tentatively replaced with xpm-nox, then came back again then gone.
Long term, it might be best just to find a different way to accomplish
what is currently done with xpm in Axiom.  I may be able to come up
with an Autoconf test (based on how we find X11), but that may take
some time. 

| 
| > Maybe we should talk to Camm to either make public numbered 
| > pre-releases or include the date of official preleases in the tarball
| > name. 
| > 
| > |    (Gaby, how will automake handle this?)
| > 
| > I'm afraid I have lost the distinctive features of old 2.6.8pre
| > vs. new 2.6.8pre.  If we need to run the system before knowing it is
| > bad then we're almost out of luck. 
| 
| I'm not sure what the issue is about updating the gcl version numbers.
| i was unable to find a way to distinguish the two cases except at build
| time. There is no runtime #+ flag. However since I know which one I
| need at build time I just set the correct version in the Makefile.pamphlet
| fedora stanza.
| 
| > Can we have only one master CVS with the othe one rsync-ing? 
| 
| Two questions, why? and how?. It's only two cvs stores and 
| it takes only a few minutes to update the second once the first
| is complete.

Oh, the suggestion was just to relieve you, but if you don't find it a
problem, I don't find it a problem :-) 

| At this time all of the CVS files are up to date.
| 
| I've checked out the SVN branch and will be creating a set
| of diff-Naur files for you to look at.

OK, thanks!

\start
Date: 29 Aug 2006 23:28:17 -0500
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: re: [build-improvements] make clean and xgcl


| Le mardi 29 ao=FBt 2006 =E0 10:01 -0500, Gabriel Dos Reis a =E9crit :
| > Vanuxem Gr=E9gory Gregory Vanuxem writes:
| >
| > | Hello Gaby,
| > |
| > | I tested the build-improvements branch and if we build gcl the XLIB
| > | (xgcl) package is compiled in (gcl and AXIOMsys are thus linked again=
st
| > | the X libraries). Don't know what you think about this, it's just a
| > | remark.
| >
| > Ah, I have no particular idea about which direction to go here.  What
| > would be your recommendation?
|
| Personally I think that if we don't use a package we can remove it. So
| for gcl it can be removed from the lisp image and added later if
| necessary. In fact there is also the TK package that Axiom doesn't use
| but I don't know if and how it is possible to remove it.

I see.  I havw a working patch that builds GCL-2.6.8pre with
--disable-xgcl.  I came to it when solving the other GCL issue I
mentioned earlier today.

[...]

| > But, please, list your priority about the build machinery.
|
| I haven't no priority at all for this branch, it's not the silver
| branch, it's a work in progress branch (as silver you can say). So if
| there are some problems that will be fixed later because some
| preliminary work has to be done it's not a problem. But what about
| adding a file, say README.build-improvement, that quickly explain how to
| build Axiom and lists the known issues, the workarounds and why not the
| TODO (it can refer to the "gold" README for more information about
| Axiom).

that is a very good suggestion.  Thanks!

\start
Date: Wed, 30 Aug 2006 03:05:55 -0400
From: Bill Page
To: Gabriel Dos Reis, Camm Maguire
Subject: RE: GCL-2.6.8pre unable to make new image

Gaby,

On Tuesday, August 29, 2006 5:27 PM you wrote:
>
>   GCL-2.6.9pre, checkout of cvs as of this morning, has problems
> making new lisp image.  More precisely, the instruction
>
>      % echo '(compiler::link nil "foo")' | gcl
>
> has GCL die with the message
>
> [...]
> loading /home/gdr/lib/gcl-2.6.8/unixport/../xgcl-2/sysdef.lisp
>
> Error: Cannot open the file
> /home/gdr/lib/gcl-2.6.8/unixport/../xgcl-2/sysdef.lisp.
> ...

I am not sure if this is the right track or not, but this error
does not occur if you build gcl with '--enable-ansi'. I believe
that this option is used on the Axiom Debian build which uses
a pre-installed gcl.

However after 'svn update' of the build_improvements branch,
my attempt to build Axiom using a pre-installed gcl built with
--enable-ansi fails with:

...
Loading /home/page/axiom.build-improvements/obj/linux/interp/setq.lsp
Finished loading
/home/page/axiom.build-improvements/obj/linux/interp/setq.lsp
Error in CONDITIONS::CLCS-LOAD [or a callee]: Cannot open the file
/home/page/axiom.build-improvements/obj/linux/interp/astr.o.

Fast links are on: do (use-fast-links nil) for debugging
Broken at BUILD-INTERPSYS.  Type :H for Help.

--------

It seems there may be other problems. Perhaps it might be a good
idea to review the Camm's Debian patches.

\start
Date: Wed, 30 Aug 2006 03:16:38 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: [build-improvements] add support for --with-gcl

Gaby,

On Sunday, August 27, 2006 10:24 PM you wrote:
>
> Hi the patchlet below adds support for --with-gcl.
>
> By default, configure will try to detect the presence of a gcl
> command in the build environment, and use it.  You can instruct
> Axiom not to autotect through the configure option --without-gcl.
> Of course, you can also explicitly tell Axiom the availability of
> GCL throught --with-gcl.  All this follows standard GNU build
> tools semantics.
>
> When I tried this, I had
>   * an outright segmentation fault with a _separately_ installed
>     GCL-2.6.8pre.  That SIGSEV was preceeded by failure to load
>     sysdef.lsp from GCL-2.6.8pre installation.  Investigation
>     revealed that indeed, that file is missing from the installation
>     repository.  That seems a plain bug from GCL part.
>

I think it might be the case that 'compiler::link' expects that
gcl is built with option '--enable-ansi'. At least in that case
I did not get the error you quote.

> ...
> Notice that none of the above problems manifests if one uses
> GCL as part of the Axiom sources.  Consequently, until the above
> issues are fixed, be sure to specify --without-gcl when invoking
> configure.
>

After repeat attempts with different options

  # make clean
  # ./configure ...
  # make

I observed that

  lsp/stamp-gcldir

is not being removed by 'make clean'.

I hate these stupid "stamp-xxx" files. Surely there is a way to
specify a proper dependency for gcl, no?

Thanks for your continuing work on this branch!

\start
Date: Wed, 30 Aug 2006 03:09:43 -0400
From: Tim Daly
To: Bill Page
Subject: Re: GCL-2.6.8pre unable to make new image
Cc: Camm Maguire, Gabriel Dos Reis

clearly burning the midnight oil, eh?

> --enable-ansi fails with:

Axiom won't work in an ansi lisp yet. 

\start
Date: Wed, 30 Aug 2006 03:37:25 -0400
From: Bill Page
To: Tim Daly
Subject: RE: GCL-2.6.8pre unable to make new image
Cc: Camm Maguire, Gabriel Dos Reis

Tim,

It's too late for the midnight oil isn't it? ;)

As I understand it --enable-ansi in GCL does not require
that the source be ansi compliant but rather builds several
variants of the gcl binary, one of which is ansi compliant.

There is the GCL_ANSI env variable mentioned by Camm here:

http://lists.nongnu.org/archive/html/axiom-developer/2005-12/msg00276.ht
ml

whose abscense tells gcl to run in the non-ansi image.

At least, I did not get any error messages that specifically
suggested problems with non-ansi source.

Note especially Camm's suggested plan towards the end of his
email:

> 1) Mod GCL to
>    1) build axiom as is under ansi.  This is a simple conversion
>    of the in-package failure to a warning afaict. or
>    1a) ship both images starting with 2.6.8 everywhere.
>    2) remove compile-time memory limits in GCL.

Camm recently complete 2). I am not sure of the other items.

Regards,
Bill Page.


> -----Original Message-----
> From: root [mailto:Tim Daly]
> Sent: Wednesday, August 30, 2006 3:10 AM
> To: Bill Page
> Cc: Gabriel Dos Reis; Camm Maguire;
> list; gcl-devel@gnu.org
> Subject: Re: GCL-2.6.8pre unable to make new image
>
> clearly burning the midnight oil, eh?
>
> > --enable-ansi fails with:
>
> Axiom won't work in an ansi lisp yet.

\start
Date: 30 Aug 2006 03:14:35 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: [build-improvements] add support for --with-gcl

Bill Page writes:

| Gaby, 
| 
| On Sunday, August 27, 2006 10:24 PM you wrote:
| > 
| > Hi the patchlet below adds support for --with-gcl.
| > 
| > By default, configure will try to detect the presence of a gcl
| > command in the build environment, and use it.  You can instruct
| > Axiom not to autotect through the configure option --without-gcl.
| > Of course, you can also explicitly tell Axiom the availability of
| > GCL throught --with-gcl.  All this follows standard GNU build
| > tools semantics.
| > 
| > When I tried this, I had
| >   * an outright segmentation fault with a _separately_ installed
| >     GCL-2.6.8pre.  That SIGSEV was preceeded by failure to load
| >     sysdef.lsp from GCL-2.6.8pre installation.  Investigation
| >     revealed that indeed, that file is missing from the installation
| >     repository.  That seems a plain bug from GCL part.
| > 
| 
| I think it might be the case that 'compiler::link' expects that
| gcl is built with option '--enable-ansi'. At least in that case
| I did not get the error you quote.

Aha; that is good to know.  Thanks!  Can we make the working
assumption that Axiom does not use anything beyond ANSI LISP, or is
that goal that is not attained at the moment?

| > Notice that none of the above problems manifests if one uses
| > GCL as part of the Axiom sources.  Consequently, until the above
| > issues are fixed, be sure to specify --without-gcl when invoking
| > configure.
| >
| 
| After repeat attempts with different options
| 
|   # make clean
|   # ./configure ...
|   # make
| 
| I observed that
| 
|   lsp/stamp-gcldir
| 
| is not being removed by 'make clean'.
| 
| I hate these stupid "stamp-xxx" files. Surely there is a way to
| specify a proper dependency for gcl, no?

yes, that is my fault.  Will be fixed.

| Thanks for your continuing work on this branch!

You're welcome.

\start
Date: 30 Aug 2006 03:19:47 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: GCL-2.6.8pre unable to make new image
Cc: Camm Maguire

Bill Page writes:

| Gaby, 
| 
| On Tuesday, August 29, 2006 5:27 PM you wrote:
| > 
| >   GCL-2.6.9pre, checkout of cvs as of this morning, has problems
| > making new lisp image.  More precisely, the instruction
| > 
| >      % echo '(compiler::link nil "foo")' | gcl
| > 
| > has GCL die with the message
| > 
| > [...]
| > loading /home/gdr/lib/gcl-2.6.8/unixport/../xgcl-2/sysdef.lisp
| > 
| > Error: Cannot open the file 
| > /home/gdr/lib/gcl-2.6.8/unixport/../xgcl-2/sysdef.lisp.
| > ...
| 
| I am not sure if this is the right track or not, but this error
| does not occur if you build gcl with '--enable-ansi'. I believe
| that this option is used on the Axiom Debian build which uses
| a pre-installed gcl.

--disable-xgcl also fixes it -- that way, compiler::link does not get
the idea of looking for system definition for xgcl.

| However after 'svn update' of the build_improvements branch,
| my attempt to build Axiom using a pre-installed gcl built with
| --enable-ansi fails with:
| 
| ...
| Loading /home/page/axiom.build-improvements/obj/linux/interp/setq.lsp
| Finished loading
| /home/page/axiom.build-improvements/obj/linux/interp/setq.lsp
| Error in CONDITIONS::CLCS-LOAD [or a callee]: Cannot open the file
| /home/page/axiom.build-improvements/obj/linux/interp/astr.o.
| 
| Fast links are on: do (use-fast-links nil) for debugging
| Broken at BUILD-INTERPSYS.  Type :H for Help.

I think I know the reason for this.  As I reproduced it yesterday but
did not get enough time to fix it -- and I spent my whole evening
chasing and fixing a stupid, mysterious kernel panic after a crash.

The above problem seems to come from the fact that astr.clisp needs
the boot compiler which was not built yet (or not found).  But the
build continued instead of failing. Later LISP found that the object
file astr.o was missing.  I think I fixed it.  I just need to find the
right "experimental directory" that has it :-( Sorry for that.

\start
Date: Wed, 30 Aug 2006 04:24:18 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: [build-improvements] add support for --with-gcl

Gaby,

On Wednesday, August 30, 2006 4:15 AM you wrote:
> ...
> Bill Page wrote:
> | I think it might be the case that 'compiler::link' expects that
> | gcl is built with option '--enable-ansi'. At least in that case
> | I did not get the error you quote.
>
> Aha; that is good to know.  Thanks!  Can we make the working
> assumption that Axiom does not use anything beyond ANSI LISP, or
> is that goal that is not attained at the moment?
>

No, it's more complicated than that. The Axiom source is not ANSI
LISP compliant (yet) but GCL even in --enable-ansi mode apparently
accepts some non-ansi constructs. Plus even with ansi enabled GCL
consists of at least two binaries (at least on Debian), one of
which still accepts the older lisp standard.

It's confusing, and I admit I might well be confused by all this...
So it's best to get the straight goods from Camm.

\start
Date: Wed, 30 Aug 2006 04:57:20 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: NULL_OR_ON_C_STACK macro invalid (was: noweb)

Camm,

On Thursday, August 24, 2006 8:31 PM you asked:
>
> Greetings!  Just going through old mail -- can we use expanded
> maxpages now?
>

Yes the maxpage parameter seems to be working as promised! :)

Thank you.

>
> Bill Page writes:
>
> > On Thursday, August 10, 2006 4:05 PM I wrote:
> >
> > > ...
> > > I edited the GCLOPTS in Makefile.pamphlet from
> > >   --enable-maxpage=256*1024
> > > to
> > >   --enable-maxpage=196*1024
> > > resulting in
> > >
> > >   GCLOPTS=--enable-vssize=65536*2 --enable-statsysbfd \
> > >           --enable-maxpage=196*1024
> > >

\start
Date: Wed, 30 Aug 2006 05:12:34 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Cannot Rename The File Erlib To NRLIB

Camm,

On Wednesday, August 23, 2006 2:27 PM you wrote:
> ...
> You need this in patches.lisp.pamphlet:
>
>          (setq $current-directory (truename
> (user-homedir-pathname))) )
>  goes to
>
>          (setq $current-directory (namestring (truename
> (user-homedir-pathname)))))
>

Thanks. I applied this patch to my local copy of the Axiom
Silver build_improvements branch.

> ...
> OK, I've made delete-file remove directories, and provide an
> errno explanation on failure.  In Version_2_6_8pre.
>
> Lisp has a bit of a different idea on some of these things.
> probe-file, delete-file, open-file, etc. are not supposed to work
> on directories, it appears, in keeping with some olden days in
> which directories were not accessible as files on the fs.  I'm
> too busy now to try to provide another function, so I hope this
> will do.
>
> I though you had problems renaming, not deleting?  I have not
> done anything here (yet).
>

You are right. So in addition to your change to
'gcl-2.6.8pre/o/unixfsys.c' in delete_file:

        if (unlink(filename) < 0 && rmdir(filename) < 0)
                FEerror("Cannot delete the file ~S: ~s.", 2,
                  path, make_simple_string(strerror(errno)));

and I added the following to rename_file:

#ifdef HAVE_RENAME
        /* Make sure we can rename */
        if (unlink(newfilename) < 0) rmdir(newfilename);
        if (rename(filename, newfilename) < 0)
                FEerror("Cannot rename the file ~S to ~S.",
                        2, vs_base[0], vs_base[1]);
#else
...

I am testing the build now.

\start
Date: Wed, 30 Aug 2006 05:30:26 -0400
From: Bill Page
To: list
Subject: RE: [Aldor-l] Type: Type
Cc: Stephen Watt, Gabriel Dos Reis

On Tuesday, August 29, 2006 6:03 AM Gabriel Dos Reis wrote:
>>> At the logical level, as I have observed some time ago, there
>>> is an inconsistency problem with Type:Type.  I'm wondering how
>>> Aldor gets away with that.  Many languages (mostly functional)
>>> use stratified types.

On Tue, Aug 29, 2006 at 12:42:04PM +0200, Ralf Hemmecke wrote:
>> Can you construct a paradox that demonstrates the problem in
>> terms of Aldor code? To me it looks like the class (not set)
>> of all classes. Would there be a problem in class theory?

On Tuesday, August 29, 2006 8:52 AM Stephen Watt wrote:
>
> You are correct that there is a potential inconsistency.
>
> We avoid Russel's paradox by limiting the operations for
> constructing and testing membership in type categories.
> ...

I think the fact that Aldor defines the type of Type as Type
is very interesting from a theoretical point of view and that
it is not correct to suggest that it implies any inconsistency
or even necessarily any fundamental limitation.

In mathematics it is often necessary to deal formally with
"very large" objects, for example, to be able to reason and
compute with things like streams and formal series or for that
matter even objects such as exact real numbers. These things
do not have simple finite representations inside the computer
yet we do have means to manipulate such objects in the Aldor
and Axiom libaries. Even larger objects such as categories and
the category of all categories can be effectively represented.

Non-well-founded set theory deals specifically with this kind
of situation. (Note: The term "non-well-founded" should not be
interpreted pejoratively, in the same way "imaginary" does not
imply any algebraic defect in reference to a number.)

http://en.wikipedia.org/wiki/Non-well-founded_set_theory

I am particularly fond of the book by Barwise and Moss:
Vicious Circles: on the mathematics of circular phenomena,
CSLI Lecture Notes, 1996.

An earlier but very important reference is the book by
Peter Aczel, Non-Well-Founded Sets. Center for the Study of
Language and Information, CSLI Lecture Notes no. 14, 1988.

http://standish.stanford.edu/pdf/00000056.pdf

One of the ways of axiomatizing non-well-founded sets is via
"accessible pointed graphs". It seems to me that these graphs
also provide an excellent model for Types in Aldor and Axiom.

This is particularly evident in the Axiom library where there
are many inherent circular dependencies. Given the presence of
circulary dependencies and the potential for mutual recursion,
fixed point methods seem especially appropropriate for compiling
the Axiom library. It seems that the SPAD language leaves no
alternative to this process, but Aldor is able to compile some
mutually recursive definitions when they occur in the same source
file. And post-facto extension makes many (most?) cases of mutual
recursion over larger groups of library modules unnecessary. It
remains to be determined whether this is sufficient to implement
Axiom's library without any essential compromises.

http://wiki.axiom-developer.org/MutualRecursion

Further, it seems to me that in principle the concept of
bi-simulation introduced in the theory of non-well-founded sets
might provide an effective definition of equivalence for Aldor's
types.

\start
Date: Wed, 30 Aug 2006 06:15:54 -0400
From: William Sit
To: Martin Rubey, Ralf Hemmecke
Subject: Re: spad: language and compiler

On 24 Aug 2006 14:38:19 +0200
  Martin Rubey wrote:
>Ralf Hemmecke writes:
>
>> > f(m: INT, n: INT): PF n == m::PF(n)
>that's OK.
>
>
>> > [f(100, n) for n in primes(1,100)]
>that's stupid.

Why? I would think it is an element (not a list) in a 
cartesian product of #primes(1,100) prime fields.

>> Ask yourself, what type that list will have and you 
>>realise that Aldor will
>> reject that its compilation.
>Excuse me, Gaby. Sorry about being so stupid.

It's a perfectly good mathematical object in a cartesian 
product.

>
>> > [a::P for P in L]
>> That is as problematic as the first list.
>"problematic" is an understatement. Sorry.

Ditto. The only problem I see that can't be handled is if 
you make it into a function of k:

[f(100, n) for n in primes(1,k)]

To have true dependent types means the compiler should be 
able to handle

[f(100, n) for n in primes(1,100)]

because the list primes(1,100) is computable at compile 
time and hence the prime fields can be constructed and 
their cartesian product too. prime(1,k) is a totally 
different ball game, but even that should be doable with 
generated code to instantiate the prime fields when k is 
given a value at run time.

\start
Date: 30 Aug 2006 05:15:57 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: [Aldor-l] Type: Type
Cc: Stephen Watt

Bill Page writes:

| On Tuesday, August 29, 2006 6:03 AM Gabriel Dos Reis wrote:
| >>> At the logical level, as I have observed some time ago, there
| >>> is an inconsistency problem with Type:Type.  I'm wondering how
| >>> Aldor gets away with that.  Many languages (mostly functional)
| >>> use stratified types.
| 
| On Tue, Aug 29, 2006 at 12:42:04PM +0200, Ralf Hemmecke wrote:
| >> Can you construct a paradox that demonstrates the problem in
| >> terms of Aldor code? To me it looks like the class (not set)
| >> of all classes. Would there be a problem in class theory?
| 
| On Tuesday, August 29, 2006 8:52 AM Stephen Watt wrote:
| > 
| > You are correct that there is a potential inconsistency.
| > 
| > We avoid Russel's paradox by limiting the operations for
| > constructing and testing membership in type categories.
| > ...
| 
| I think the fact that Aldor defines the type of Type as Type
| is very interesting from a theoretical point of view and that
| it is not correct to suggest that it implies any inconsistency
| or even necessarily any fundamental limitation.

I believe I need more explanations than the vague allusion to
co-inductive formalism.  Epigram, for example, faces the same issue, and
I don't think it is just mirage:

   http://www.mail-archive.com/epigram@durham.ac.uk/msg00038.html

\start
Date: 30 Aug 2006 12:29:04 +0200
From: Martin Rubey
To: William Sit
Subject: Re: [Axiom-math] Curious behavior of Taylor series
Cc: Igor Khavkine

William Sit writes:

> Igor Khavkine writes:
> 
> >OK, but the following definitely looks like a bug.
> >
> >(279) -> monx := monomial(1,1)$UTS(EXPR INT,x,0)
> >   (279)  x
> >                         Type: UnivariateTaylorSeries(Expression Integer,x,0)
> >(281) -> sqrt(monx*monx)
> >(281) ->
> >   (281)  1
> >                         Type:
> 
> In the Windows version, I get the correct answer. So this bug is newly
> introduced.

OOPs, I'm afraid that I was the only one who touched that function.

Martin

(redirecting to axiom-developer, since it is a bug, not a
maths-related question)

\start
Date: Wed, 30 Aug 2006 13:35:55 +0200
From: Ralf Hemmecke
To: William Sit
Subject: Re: spad: language and compiler

>>> > f(m: INT, n: INT): PF n == m::PF(n)
>> that's OK.
>>
>>
>>> > [f(100, n) for n in primes(1,100)]
>> that's stupid.

> Why? I would think it is an element (not a list) in a cartesian product 
> of #primes(1,100) prime fields.

OK, if you like. But then I would like to see the definition of the 
bracket function. Can you give that?

I strongly believe you can't, because that would require Aldor to 
compute "primes(1,100)" at compile time. Which is currently not possible 
and if the compiler is allowed to evaluate it then it might run into an 
infinite loop (at compile time) since the "primes" function does not 
terminate as you would expect. Compile time evaluation in full 
generality introduces a way make it really hard to find bugs.

But anyway, maybe Aldor should allow compile time evaluation.

>>> Ask yourself, what type that list will have and you realise that 
>>> Aldor will
>>> reject that its compilation.
>> Excuse me, Gaby. Sorry about being so stupid.
> 
> It's a perfectly good mathematical object in a cartesian product.

William is right, but I cannot believe that a construction like

[f(100, n) for n in [2,3,5]$List(Integer)]

would work.

[f(100, n), f(100, n), f(100, n)]

should be easily definable and give an element in the cartesian product 
of   PF(2), PF(3), and PF(5). But that is a finite construct and not 
done via Generator as above.

>>> > [a::P for P in L]
>>> That is as problematic as the first list.
>> "problematic" is an understatement. Sorry.
> 
> Ditto. The only problem I see that can't be handled is if you make it 
> into a function of k:

> [f(100, n) for n in primes(1,k)]

Initially, I believe, Martin wanted lists. What you are calling for is a 
cartesian product constructor of the form.

PFCartesian(k: Integer): with {
     coerce: ((n: Integer) -> PF(n)) -> %;
     ...
} == add {
     ...
}

Then instead of [f(100, n) for n in primes(1,k)] it would be more 
appropriate to define

k: Integer == << stdin; -- read from standard input and make it constant
foo(m: Integer)(n: Integer): PF(n) == m :: PF(n);
import from PFCartesian(k);
z := foo(42) :: PFCartesian(k);

Such a construction would work, but it does not involve a Generator or 
something that you must compute at compile time.

\start
Date: Wed, 30 Aug 2006 08:14:35 -0400
From: Jacques Carette
To: Ralf Hemmecke
Subject: Re: [Aldor-l] spad: language and compiler

Ralf Hemmecke wrote:
> Compile time evaluation in full 
> generality introduces a way make it really hard to find bugs.
>
> But anyway, maybe Aldor should allow compile time evaluation.
>   
Quick remark --  it has been shown that:
1) C++'s template language is a Turing Complete PL
2) Haskell's class types (with common extensions) is also a Turing 
Complete PL
3) All meta-programming systems allow arbitrary compile time evaluation

Yes, it does make debugging harder.  But the advantages seem to _far_ 
outweigh the problems.  One just develops new debugging (and coding) 
techniques to deal with the added power/complexity.

I could re-use Stephen's brilliant closing line from yesterday's email:
    "These kinds of errors have to be seen as bugs in programs, just as 
division by zero is a programming error and not an invalidation of 
integer arithmetic." -- S.M. Watt
[where 'These kinds of errors' is now /Programs with infinite loops in 
types/]

\start
Date: 30 Aug 2006 08:05:22 -0500
From: Gabriel Dos Reis
To: Jacques Carette
Subject: Re: [Aldor-l] spad: language and compiler

Jacques Carette writes:

| Ralf Hemmecke wrote:
| > Compile time evaluation in full 
| > generality introduces a way make it really hard to find bugs.
| >
| > But anyway, maybe Aldor should allow compile time evaluation.
| >   
| Quick remark --  it has been shown that:
| 1) C++'s template language is a Turing Complete PL
| 2) Haskell's class types (with common extensions) is also a Turing 
| Complete PL
| 3) All meta-programming systems allow arbitrary compile time evaluation
| 
| Yes, it does make debugging harder.  But the advantages seem to _far_ 
| outweigh the problems.  One just develops new debugging (and coding) 
| techniques to deal with the added power/complexity.
| 
| I could re-use Stephen's brilliant closing line from yesterday's email:
|     "These kinds of errors have to be seen as bugs in programs, just as 
| division by zero is a programming error and not an invalidation of 
| integer arithmetic." -- S.M. Watt
| [where 'These kinds of errors' is now /Programs with infinite loops in 
| types/]

I agree with most of what you said.  However, the slogan "well-typed
programs don't go wrong" does some value that I would heisate to
compromise...

\start
Date: 30 Aug 2006 10:31:58 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: GCL-2.6.8pre unable to make new image

Greetings, and thanks!  I think this should be fixed now.  Please let
me know if problems persist.

Take care,

Gabriel Dos Reis writes:

> Hi Camm,
> 
>   GCL-2.6.9pre, checkout of cvs as of this morning, has problems
> making new lisp image.  More precisely, the instruction
> 
>      % echo '(compiler::link nil "foo")' | gcl
> 
> has GCL die with the message
> 
> [...]
> loading /home/gdr/lib/gcl-2.6.8/unixport/../xgcl-2/sysdef.lisp
> 
> Error: Cannot open the file /home/gdr/lib/gcl-2.6.8/unixport/../xgcl-2/sysdef.lisp.
> Error signalled by PROGN.
> Broken at SYSTEM::BREAK-LEVEL.  Type :H for Help.
> COMPILER>>
> "foo"
> 
> 
> Indeed the file sysdef.lisp is NOT present in the install directory
> 
>         /home/gdr/lib/gcl-2.6.8/unixport/xgcl-2/
> 
> it looks like the install machinery forgot to install it.

\start
Date: 30 Aug 2006 10:35:53 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: GCL-2.6.8pre unable to make new image
Cc: Gabriel Dos Reis

Bill Page writes:

> Gaby, 
> 
> On Tuesday, August 29, 2006 5:27 PM you wrote:
> > 
> >   GCL-2.6.9pre, checkout of cvs as of this morning, has problems
> > making new lisp image.  More precisely, the instruction
> > 
> >      % echo '(compiler::link nil "foo")' | gcl
> > 
> > has GCL die with the message
> > 
> > [...]
> > loading /home/gdr/lib/gcl-2.6.8/unixport/../xgcl-2/sysdef.lisp
> > 
> > Error: Cannot open the file 
> > /home/gdr/lib/gcl-2.6.8/unixport/../xgcl-2/sysdef.lisp.
> > ...
> 
> I am not sure if this is the right track or not, but this error
> does not occur if you build gcl with '--enable-ansi'. I believe
> that this option is used on the Axiom Debian build which uses
> a pre-installed gcl.
> 

THe reported error should only occur using the Debian way of building
aciom. 

I believe the first problem you will encounter with the ansi image is
that ansi triggers an error if an (in-package ...) is encountered
before the corresponding (make-package ...), whereas the older
standard implied the latter with the former.  There is some file
earlier in your log which failed to compile is my guess.
Unfortunately, I have not yet been able to get all exits in the error
handler to return non-zero to the shell to abort the build immediately
at sign of trouble.

Do you want to use the ansi image?  GCL has kept the older one around
specifically for reasons like this.  Unless you are using oop, all you
get is extra unused image size.

Take care,

> However after 'svn update' of the build_improvements branch,
> my attempt to build Axiom using a pre-installed gcl built with
> --enable-ansi fails with:
> 
> ...
> Loading /home/page/axiom.build-improvements/obj/linux/interp/setq.lsp
> Finished loading
> /home/page/axiom.build-improvements/obj/linux/interp/setq.lsp
> Error in CONDITIONS::CLCS-LOAD [or a callee]: Cannot open the file
> /home/page/axiom.build-improvements/obj/linux/interp/astr.o.
> 
> Fast links are on: do (use-fast-links nil) for debugging
> Broken at BUILD-INTERPSYS.  Type :H for Help.
> 
> --------
> 
> It seems there may be other problems. Perhaps it might be a good
> idea to review the Camm's Debian patches.

\start
Date: 30 Aug 2006 10:49:00 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: GCL-2.6.8pre unable to make new image
Cc: Gabriel Dos Reis

Bill Page writes:

> Tim,
> 
> It's too late for the midnight oil isn't it? ;)
> 
> As I understand it --enable-ansi in GCL does not require
> that the source be ansi compliant but rather builds several
> variants of the gcl binary, one of which is ansi compliant.
> 

This is not quite right -- the ansi build will trigger errors in
several places allowed to pass in the traditional image.


> There is the GCL_ANSI env variable mentioned by Camm here:
> 
> http://lists.nongnu.org/archive/html/axiom-developer/2005-12/msg00276.ht
> ml
> 
> whose abscense tells gcl to run in the non-ansi image.

This is read by the wrapper script in the Debian gcl package.  People
building from source by hand just get one image, the Debian package
builds four and allows the user to select at runtime with these env
variables. 

> 
> At least, I did not get any error messages that specifically
> suggested problems with non-ansi source.
> 
> Note especially Camm's suggested plan towards the end of his
> email:
> 
> > 1) Mod GCL to
> >    1) build axiom as is under ansi.  This is a simple conversion
> >    of the in-package failure to a warning afaict. or 

We can step over the in-package error, but Paul Dietz' 'definitive'
ansi test suite demands an error here, so I think this will break
compliance. 

> >    1a) ship both images starting with 2.6.8 everywhere.

Not sure what I was thinking here.

> >    2) remove compile-time memory limits in GCL.
> 

Yes, please note that these are no longer constrained to a power of 2,
but we still have a little work to support 32bit heaps ober 2Gb.

> Camm recently complete 2). I am not sure of the other items.
> 

Take care,

> Regards,
> Bill Page.
> 
> 
> > -----Original Message-----
> > From: root [mailto:Tim Daly] 
> > Sent: Wednesday, August 30, 2006 3:10 AM
> > To: Bill Page
> > Cc: Gabriel Dos Reis; Camm Maguire; 
> > list; gcl-devel@gnu.org
> > Subject: Re: GCL-2.6.8pre unable to make new image
> > 
> > clearly burning the midnight oil, eh?
> > 
> > > --enable-ansi fails with:
> > 
> > Axiom won't work in an ansi lisp yet. 

\start
Date: 30 Aug 2006 11:17:43 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: Install problem with GCL-2.6.8pre

Greetings!  OK, please try it now, think this is done too.

Take care,

Gabriel Dos Reis writes:

> Hi Camm,
> 
> I'm experiencing a problem when installing GCL-2.6.8pre in a custom prefix.
> 
> Here are the details:
> 
> * check out cvs GCL-2.6.8pre
> 
> * configure --prefix=$HOME
> 
> * make # works fine
> 
> * make install # troublesome
> 
> the install fails with the following error:
> 
> chmod a+x /home/gdr/lib/gcl-2.6.8/gcl-tk/gcltksrv ; fi
> if test "/usr/share/emacs/21.3/site-lisp" != "" ; then (cd elisp ; make install DESTDIR=) ; fi
> make[2]: Entering directory `/media/usbdisk_2/software.src/GCL/2.6.8pre/elisp'
> mkdir -p /usr/share/emacs/21.3/site-lisp
> cp *.el /usr/share/emacs/21.3/site-lisp
> cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/add-default.el': Permission denied
> cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/ansi-doc.el': Permission denied
> cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/dbl.el': Permission denied
> cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/doc-to-texi.el': Permission denied
> cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/gcl.el': Permission denied
> cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/man1-to-texi.el': Permission denied
> cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/smart-complete.el': Permission denied
> cp: cannot create regular file `/usr/share/emacs/21.3/site-lisp/sshell.el': Permission denied
> 
> 
> The problem seems to be that GCL wants to install elisp files in
> $(EMACS_SITE_LISP).  User installing GCL (like me, or as part of another
> package like Axiom) may not have write permission to that directory.
> Any particular reason why the elisp files are not installed in
> $(prefix)/share/emacs for example?

\start
Date: 30 Aug 2006 11:21:26 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Cannot Rename The File Erlib To NRLIB

Greetings!

Bill Page writes:

> Camm, 
> 
> On Wednesday, August 23, 2006 2:27 PM you wrote:
> > ... 
> > You need this in patches.lisp.pamphlet:
> > 
> >          (setq $current-directory (truename 
> > (user-homedir-pathname))) )
> >  goes to
> > 
> >          (setq $current-directory (namestring (truename 
> > (user-homedir-pathname)))))
> >
> 
> Thanks. I applied this patch to my local copy of the Axiom
> Silver build_improvements branch.
>  
> > ... 
> > OK, I've made delete-file remove directories, and provide an
> > errno explanation on failure.  In Version_2_6_8pre.
> > 
> > Lisp has a bit of a different idea on some of these things.
> > probe-file, delete-file, open-file, etc. are not supposed to work
> > on directories, it appears, in keeping with some olden days in
> > which directories were not accessible as files on the fs.  I'm
> > too busy now to try to provide another function, so I hope this
> > will do.
> > 
> > I though you had problems renaming, not deleting?  I have not
> > done anything here (yet).
> > 
> 
> You are right. So in addition to your change to
> 'gcl-2.6.8pre/o/unixfsys.c' in delete_file:
> 
>         if (unlink(filename) < 0 && rmdir(filename) < 0)
>                 FEerror("Cannot delete the file ~S: ~s.", 2,
>                   path, make_simple_string(strerror(errno)));
> 
> and I added the following to rename_file:
> 
> #ifdef HAVE_RENAME
>         /* Make sure we can rename */
>         if (unlink(newfilename) < 0) rmdir(newfilename);

OK, but shouldn't we follow the C semantics and cause an error unless
an explicit delete was issued before a rename?  

I don't know what lisp is supposed to do on collisions here - perhaps
you guys might check clisp or comp.lang.lisp:


20.2.7 rename-file                                                      [Function]
----------------------------------------------------------------------------------

`rename-file'  filespec new-name =>  defaulted-new-name, old-truename,
new-truename

Arguments and Values::
......................

filespec--a pathname designator.

   new-name--a pathname designator other than a stream.

   defaulted-new-name--a pathname

   old-truename--a physical pathname.

   new-truename--a physical pathname.

Description::
.............

rename-file modifies the file system in such a way that the file
indicated by filespec is renamed to defaulted-new-name.

   It is an error to specify a filename containing a wild component,
for filespec to contain a nil component where the file system does not
permit a nil component, or for the result of defaulting missing
components of new-name from filespec to contain a nil component where
the file system does not permit a nil component.

   If new-name is a logical pathname, rename-file returns a logical
pathname as its primary value.

   rename-file returns three values if successful.  The primary value,
defaulted-new-name, is the resulting name which is composed of new-name
with any missing components filled in by performing a merge-pathnames
operation using filespec as the defaults.  The secondary value,
old-truename, is the truename of the file before it was renamed.  The
tertiary value, new-truename, is the truename of the file after it was
renamed.

   If the filespec designator is an open stream, then the stream itself
and the file associated with it are affected (if the file system
permits).

Examples::
..........

     ;; An example involving logical pathnames.
      (with-open-file (stream "sys:chemistry;lead.text"
                              :direction :output :if-exists :error)
        (princ "eureka" stream)
        (values (pathname stream) (truename stream)))
     =>  #P"SYS:CHEMISTRY;LEAD.TEXT.NEWEST", #P"Q:>sys>chem>lead.text.1"
      (rename-file "sys:chemistry;lead.text" "gold.text")
     =>  #P"SYS:CHEMISTRY;GOLD.TEXT.NEWEST",
        #P"Q:>sys>chem>lead.text.1",
        #P"Q:>sys>chem>gold.text.1"

Exceptional Situations::
........................

If the renaming operation is not successful, an error of type
file-error is signaled.

   An error of type file-error might be signaled if filespec is wild.

See Also::
..........

*Note truename:: , pathname, logical-pathname, *Note File System
Concepts::,

   *Note Pathnames as Filenames::



Take care,

>         if (rename(filename, newfilename) < 0)
>                 FEerror("Cannot rename the file ~S to ~S.",
>                         2, vs_base[0], vs_base[1]);
> #else
> ...
> 
> I am testing the build now.
> 
> Thanks.

\start
Date: Wed, 30 Aug 2006 13:03:25 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Cannot Rename The File Erlib To NRLIB

On Wednesday, August 30, 2006 5:13 AM I wrote:
> Camm Maguire wrote:
> >
> > I though you had problems renaming, not deleting?  I have
> > not done anything here (yet).
> >
>
> You are right. So in addition to your change to
> 'gcl-2.6.8pre/o/unixfsys.c' in delete_file:
>
>         if (unlink(filename) < 0 && rmdir(filename) < 0)
>                 FEerror("Cannot delete the file ~S: ~s.", 2,
>                   path, make_simple_string(strerror(errno)));
>
> and I added the following to rename_file:
>
> #ifdef HAVE_RENAME
>         /* Make sure we can rename */
>         if (unlink(newfilename) < 0) rmdir(newfilename);
>         if (rename(filename, newfilename) < 0)
>                 FEerror("Cannot rename the file ~S to ~S.",
>                         2, vs_base[0], vs_base[1]);
> #else
>         sprintf(command, "mv %s %s", filename, newfilename);
>         system(command);
> #endif
> ...
>
> I am testing the build now.
>

My tests of re-compiling a SPAD function still failed. :-(

Unfortunately my patch to rename_file is not sufficient for Axiom.
Axiom really does seem to expect that rename is as destructive
as the 'mv' shell command. But the semantics of 'rename' is
different:

http://www.gnu.org/software/libc/manual/html_node/Renaming-Files.html

int rename (const char *oldname, const char *newname)

"If oldname is a directory, then either newname must not exist
or it must name a directory that is empty. In the latter case,
the existing directory named newname is deleted first."

It seems that to simulate the behaviour of 'mv' with the Gnu C
library one must write a simple recursive routine to hit all of
the files and subdirectories of a given directory, etc. etc.

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

But wait a minute! Does hacking away at GCL really make any
sense? Let's take a look at exactly what Axiom is doing with
this ... dig dig dig ... Aha:

    src/interp/nlib.lisp.pamphlet

Ok, here is the offensive coding in Axiom!

---------

;; ($ERASE filearg) -> 0 if succeeds else 1
(defun $erase (&rest filearg)
  (setq filearg (make-full-namestring filearg))
  (if (probe-file filearg)
#+:CCL (delete-file filearg)
#+:AKCL
      (if (library-file filearg)
          (delete-directory filearg)
          (delete-file filearg))
      1))

(defun library-file (filename)
; (format t "library-file: ~a~%" filename)
 t)


#+:AKCL
(defun delete-directory (dirname)
   (system (concat "rm  -r " dirname)))

(defun $REPLACE (filespec1 filespec2)
    ($erase (setq filespec1 (make-full-namestring filespec1)))
    (rename-file (make-full-namestring filespec2) filespec1))

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

Elsewhere Axiom calls $REPLACE to replace xxx.NRLIB with the
contents of xxx.erlib. This used to work. What has changed?

The only thing I see here that I know has changed around about
gcl-2.6.7pre is 'probe-file'. The change was the 'probe-file'
returning nil for directories.

http://lists.nongnu.org/archive/html/axiom-developer/2005-05/msg00283.ht
ml

Yes, indeed! So now Axiom only deleted files but not directories!
It used to do both. I think what it wants to know is whether
the file or directory exists.

I should have remembered this:

http://lists.nongnu.org/archive/html/axiom-developer/2006-02/msg00219.ht
ml
http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00045.ht
ml

Although the lisp spec is a horrible mish-mash, as near as I
can figure it

 (directory (truename filearg))

will test of a particular file or *directory* exists, although it
seems to do some kind of "wild card" since it also finds files
or directories that have something after a dot (.). So

 (directory (truename "xxx"))

returns a list of all files or directories of the form "xxx.*"
Contrary to the documentation at

http://www.cs.queensu.ca/software_docs/gnudev/gcl-ansi/gcl_1138.html#SEC
1138

Yuck!

Anyway it seems the following patch replacing (probe-file filearg)
with (directory (truename filearg)) should work (for Axiom's purposes
at least):

----------

;; ($ERASE filearg) -> 0 if succeeds else 1
(defun $erase (&rest filearg)
  (setq filearg (make-full-namestring 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?

\start
Date: Wed, 30 Aug 2006 13:17:37 -0400
From: Jacques Carette
To: Gabriel Dos Reis
Subject: Re: [Aldor-l] spad: language and compiler

Gabriel Dos Reis wrote:
> I agree with most of what you said.  However, the slogan "well-typed
> programs don't go wrong" does some value that I would heisate to
> compromise...
>   
But well-typed programs can still diverge!  So "go wrong" just means 
that _when_ they return a value, it is guaranteed to be of the right type.

You can do the same thing for types - this is usually called a 'kinding' 
system.  In fact some languages (like Tim Sheard's Omega -- 
http://web.cecs.pdx.edu/~sheard/Omega/index.html) push that further by 
having a complete hierarchy (the names often used for the lower levels 
are term - type - kind - sort).

A "well-kinded" type doesn't "go wrong" either [assuming termination].

\start
Date: Wed, 30 Aug 2006 12:25:25 -0500 (CDT)
From: Gabriel Dos Reis
To: Jacques Carette
Subject: Re: [Aldor-l] spad: language and compiler

On Wed, 30 Aug 2006, Jacques Carette wrote:

| Gabriel Dos Reis wrote:
| > I agree with most of what you said.  However, the slogan "well-typed
| > programs don't go wrong" does some value that I would heisate to
| > compromise...
| >
| But well-typed programs can still diverge!  So "go wrong" just means
| that _when_ they return a value, it is guaranteed to be of the right type.

No dispute there.

With Type:Type, it is not clear to me that when a well-typed
expression does not diverge, its value is not "wrong".

\start
Date: Wed, 30 Aug 2006 14:04:11 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: [Aldor-l] spad: language and compiler
Cc: Jacques Carette

On Wed, 30 Aug 2006, Page, Bill wrote:

| But I supposed Gaby would claim that these are still more
| "vague allusions to co-inductive formalism" ;) Oh well...

I hope we would make progress with scientific skepticism :-)

\start
Date: Wed, 30 Aug 2006 16:06:45 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: GCL-2.6.8pre unable to make new image
Cc: Gabriel Dos Reis

Camm,

On Wednesday, August 30, 2006 10:36 AM you wrote:
> ...
> I believe the first problem you will encounter with the ansi
> image is that ansi triggers an error if an (in-package ...) is
> encountered before the corresponding (make-package ...), whereas
> the older standard implied the latter with the former.  There is
> some file earlier in your log which failed to compile is my guess.
> Unfortunately, I have not yet been able to get all exits in the
> error handler to return non-zero to the shell to abort the build
> immediately at sign of trouble.

Yes, I think you are correct. However the log does not show any
prior error message.

>
> Do you want to use the ansi image?  GCL has kept the older one
> around specifically for reasons like this.  Unless you are using
> oop, all you get is extra unused image size.
>

Yes, I still think it is a good idea to make Axiom build under
the ansi version of gcl in spite of the fact that in it's
currrent form it will not be taking advantage of the extra image
size. Standardizing the lisp dialect used in Axiom could have
some long term benefits, e.g. attract some new developers? and
make it easier to integrate standard lisp packages. (Of course
you know the "sales pitch"... :)

Anyway, I was quite pleased by how far the Axiom build got before
dying of ansi fever. Perhaps this confirms that there is not
much to be done to make the Axiom sources at least as gcl-ansi
compliant as Maxima.

\start
Date: Wed, 30 Aug 2006 14:22:48 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Camm Maguire
Subject: ANSI and Axiom
Cc: Gabriel Dos Reis

Given the Axiom CMU port that was done, I think we can probably do this
in a reasonable amount of time as long as we just patch it enough to
get it working.  Re-factoring it to make it into clean, sensible ANSI
code is probably another story... however, we can do it incrementally
once we can run on an ANSI lisp in the first place.  As appealing as a
from the ground up re-write is, I think a gradual re-factor is more
realistic and a lot less up front work, for some significant gains.

I took a stab at SBCL once, and I have a feeling it will be the most
challenging of the ANSI lisps (it has a reputation as a stickler). 
However, since SBCL is also being (gradually) ported to Windows it
becomes a more attractive target.  A couple of hard things like threads
aren't there yet, IIRC, but I doubt Axiom would immediately need those
anyway.

The CMU work doesn't seem to quite work on current cmucl versions, so
there is probably some more cleanup to do even starting from those
changes as a foundation, but if we get serious about it I think it is
quite doable.

Should we draw the line in the sand and focus on that?  

\start
Date: Wed, 30 Aug 2006 17:40:00 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: ANSI and Axiom
Cc: Gabriel Dos Reis

On Wednesday, August 30, 2006 5:23 PM C Y wrote:
> ...
> As appealing as a from the ground up re-write is, I think a
> gradual re-factor is more realistic and a lot less up front work,
> for some significant gains.
> ...
> Should we draw the line in the sand and focus on that? 
>

Absolutely! Here's a recipe:

  1) svn co
https://svn.sourceforge.net/svnroot/axiom/branches/build-improvements \
                axiom.build-improvements

  2) edit Makefile.pamphlet in three places

     GCLOPTS = --enable-ansi ...

  3) modify any in-package commands that don't comply or anything else
     obvious

  4) make clean

  5) ./configure --without-gcl

  6) make | tee build.log

  7) find out why the build stopped and repeat steps 3 to 6,
     shake and bake until done.

  8) svn diff > ansi.patches

  9) send the result to Gaby :-)

\start
Date: Wed, 30 Aug 2006 17:51:42 -0400
From: William Sit
To: Ralf Hemmecke
Subject: Re: spad: language and compiler

On Wed, 30 Aug 2006 13:35:55 +0200
  Ralf Hemmecke wrote:
>>>>> f(m: INT, n: INT): PF n == m::PF(n)
Martin's expression:
>>>>> [f(100, n) for n in primes(1,100)]
>>I would think it is an element (not a list) in a 
>>cartesian product of #primes(1,100) prime fields.
>
>OK, if you like. But then I would like to see the 
>definition of the bracket function. Can you give that?

One main difference between list of mathematical objects 
and say C++ objects is that the former is often 
homogeneous (elements of the list are of the same type) 
but the latter is often heterogeneous (elements need not 
be of the same type). In Axiom, all lists are homogeneous 
(even List Any) by definition of the domain List (or the 
domain Tuple). A variant that allows hetergeneous objects 
in a "list" is the domain Record. The bracket constructor 
is by default the list constructor but can be used to 
construct elements of Record. But since Record must have 
pre-defined named fields, Martin's line could not have 
meant a Record element. It certainly is not a list in the 
Axiom sense. So the remaining possibility is an element of 
a cartesian product. Axiom currently has a constructor for 
cartesian product of two sets: Product, where elements are 
constructed using the function makeprod. But here, we are 
not discussing existing domains, but rather whether 
Martin's expression is mathematically meaningful and 
whether the language allows its construction in Aldor. 

Getting back to your question, it is up to the programmer 
to define the bracket function for the domain where 
Martin's expression lives. Even though it may not be 
possible in Axiom to directly program tuples of 
heterogeneous domains, such tuples are present in most 
function signatures like foo:(INT, Boolean)->INT. I would 
expect Aldor therefore to be able to directly program 
tuples of heterogeneous domains. Thus Martin's expression, 
perhaps using round parentheses instead of brackets, 
should work in Aldor.

>I strongly believe you can't, because that would require 
>Aldor to compute "primes(1,100)" at compile time. Which 
>is currently not possible and if the compiler is allowed 
>to evaluate it then it might run into an infinite loop 
>(at compile time) since the "primes" function does not 
>terminate as you would expect. Compile time evaluation in 
>full generality introduces a way make it really hard to 
>find bugs.

I don't know how "primes" is implemented but it is 
probably a built-in using both a table for lower range and 
some sophisticated algorithms for higher ones. I am not 
suggesting compile time evaluation be extended to all 
static computations, but my guess is "primes" is special. 
A bit of compiler optimization would probably evaluate 
expressions like 2+3, so why not primes(1,100)? Obviously, 
compile time evaluation should be severely restricted 
(otherwise many programs may compile to just the output if 
no input is required).

>But anyway, maybe Aldor should allow compile time 
>evaluation.
>
>>>>Ask yourself, what type that list will have and you 
>>>>realise that 
>>>>Aldor will
>>>>reject that its compilation.
>>>Excuse me, Gaby. Sorry about being so stupid.
>>
>>It's a perfectly good mathematical object in a cartesian 
>>product.
>
>William is right, but I cannot believe that a 
>construction like
>
>[f(100, n) for n in [2,3,5]$List(Integer)]
>
>would work.

The main reason why it is not working presently is because 
we have not constructed cartesian product over an 
arbitrary set of domains. But nothing in the language 
(even Spad) seems to prevent one from doing this.

>[f(100, n), f(100, n), f(100, n)]

You meant: [f(100,2), f(100,3), f(100,5)], I assume.

>should be easily definable and give an element in the 
>cartesian product of   PF(2), PF(3), and PF(5). But that 
>is a finite construct and not done via Generator as 
>above.

As discussed above, what is missing is cartesian product 
over an arbitrary set of domains. If domains are first 
class objects, we should be able to construct sets of 
them, even via Generator, and hence also cartesian 
product. At the very least, one should be able to form a 
set or list of domains of the same category (which IS 
homogeneous). Something like:

Product(A: List PrimeField, B: List) 

where B is the index "set." Or, as you did below, using an 
anonymous function as the argument.

>>>>> [a::P for P in L]
>>>>That is as problematic as the first list.
>>>"problematic" is an understatement. Sorry.
>>
>>Ditto. The only problem I see that can't be handled is if 
>>you make it into a function of k:
>
>>[f(100, n) for n in primes(1,k)]
>
>Initially, I believe, Martin wanted lists. What you are 
>calling for is a cartesian product constructor of the 
>form.
>
>PFCartesian(k: Integer): with {
>     coerce: ((n: Integer) -> PF(n)) -> %;
>     ...
>}== add {
>     ...
>}

I am not following. Is PFCartesian(k) a cartesian product 
of the first k prime fields, like PFCartesian(3) is PF(2) 
x PF(3) x PF(5)? Then given a function (n:Integer)->PF(n) 
(basically, an sequence of elements, one from each PF(n), 
and n better be a prime! but let's pretend we interpret 
PF(n) as Integer mod n), the coerce function maps the 
anonymous function to PFCartesian(k) by using the first k 
elements in the sequence?

>Then instead of [f(100, n) for n in primes(1,k)] it would 
>be more appropriate to define
>
>k: Integer == << stdin; -- read from standard input and 
>make it constant
>foo(m: Integer)(n: Integer): PF(n) == m :: PF(n);
>import from PFCartesian(k);
>z := foo(42) :: PFCartesian(k);
>
>Such a construction would work, but it does not involve a 
>Generator or something that you must compute at compile 
>time.

The construction of the domain PFcartesian(k) might, even 
when k is given at instantiation time, depending on the 
meaning of that domain.

\start
Date: Thu, 31 Aug 2006 01:05:18 +0200
From: Ralf Hemmecke
To: William Sit
Subject: Re: spad: language and compiler

Dear William,

> Getting back to your question, it is up to the programmer to define
> the bracket function for the domain where Martin's expression lives.
> Even though it may not be possible in Axiom to directly program
> tuples of heterogeneous domains, such tuples are present in most
> function signatures like foo:(INT, Boolean)->INT. I would expect
> Aldor therefore to be able to directly program tuples of
> heterogeneous domains.

As you know Record and Cross are two ways in Aldor to construct
heterogeneous tuples. The problem is that both must have a certain fixed
length when you write them into your program.

> Thus Martin's expression, perhaps using round parentheses instead of 
> brackets, should work in Aldor.

Martin's line contained a "for n in primes(1,100)" iterator, so the type
would only be know if the compiler were able to evaluate "primes(1,100)"
at compile time.

> I don't know how "primes" is implemented but it is probably a
> built-in using both a table for lower range and some sophisticated
> algorithms for higher ones.

Whatever "built-in" means for you. It is certainly not built into the 
Aldor language, it is part of a library and as such it could mean 
anything I like.

 > I am not suggesting compile time
> evaluation be extended to all static computations, but my guess is
> "primes" is special. A bit of compiler optimization would probably
> evaluate expressions like 2+3, so why not primes(1,100)?

To what should 2+3 evaluate? To the Integer 5? To the MachineInteger 5? 
To a sparse univariate polynomial 5? To 0 mod 5? It is awfully ambiguous 
and would in general involve more than just a call to the addition of 
machine size integers. I could have even overloaded + for 
MachineInteger. I guess, optimizing 2+3 to 5 is not even correct in some 
circumstances.

>> William is right, but I cannot believe that a construction like
>> 
>> [f(100, n) for n in [2,3,5]$List(Integer)]
>> 
>> would work.
> 
> The main reason why it is not working presently is because we have
> not constructed cartesian product over an arbitrary set of domains.
> But nothing in the language (even Spad) seems to prevent one from
> doing this.

Of course not, but note that you have a generator in the above 
construction and thus the compiler does not know the length of the tuple 
until it is *computed*. To make myself clear: I believe that one can 
write a constuctor for arbitrary tuples of variable length, but Martin's 
syntax to construct an element of such a type would not work. (Please 
convince me otherwise by providing running code.)

>> [f(100, n), f(100, n), f(100, n)]
> 
> You meant: [f(100,2), f(100,3), f(100,5)], I assume.

Of course.

>> should be easily definable and give an element in the cartesian 
>> product of   PF(2), PF(3), and PF(5). But that is a finite
>> construct and not done via Generator as above.
> 
> As discussed above, what is missing is cartesian product over an 
> arbitrary set of domains. If domains are first class objects, we
> should be able to construct sets of them, even via Generator, and
> hence also cartesian product.

Oh, yes, of course it is possible (even now) to construct a 
heterogeneous tuple type via Generator. But Martin's construction would 
mean to construct the type AND the element at the same time. And that (I 
believe) is impossible.

> At the very least, one should be able
> to form a set or list of domains of the same category (which IS
> homogeneous).

No problem in Aldor.

#include "aldor"
U: List PrimitiveType := [Integer, String, Character];

That is a completely valid Aldor program.

>> PFCartesian(k: Integer): with {
 >>     coerce: ((n: Integer) -> PF(n)) -> %;
 >>     ...
 >> }== add { ... }

> I am not following. Is PFCartesian(k) a cartesian product of the
> first k prime fields, like PFCartesian(3) is PF(2) x PF(3) x PF(5)?
> Then given a function (n:Integer)->PF(n) (basically, an sequence of
> elements, one from each PF(n), and n better be a prime! but let's
> pretend we interpret PF(n) as Integer mod n), the coerce function
> maps the anonymous function to PFCartesian(k) by using the first k
> elements in the sequence?

I was not thinking too much about it. I wanted that PFCartesian(7) 
stands for PF(2) x PF(3) x PF(5) x PF(7) and PF for PrimeField. And the 
coerce function basically turns the projection functions into an element 
of PFCartesian.

As representation I could choose

Rep == (n: Integer) -> PF(n);

But I still cannot make

[f(100, n) for n in [2,3,5]$List(Integer)]

into valid Aldor code if f is the function given by Martin.

Can you?

\start
Date: Wed, 30 Aug 2006 21:47:30 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Cannot Rename The File Erlib To NRLIB

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?

\start
Date: Wed, 30 Aug 2006 23:20:54 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [Aldor-l] spad: language and compiler

On Wednesday, August 30, 2006 7:05 PM Ralf Hemmecke wrote:
> ...
> As you know Record and Cross are two ways in Aldor to construct
> heterogeneous tuples. The problem is that both must have a
> certain fixed length when you write them into your program.
> ...

What does "fixed" mean in this context?

> Martin's line contained a "for n in primes(1,100)" iterator,
> so the type would only be known if the compiler were able to
> evaluate "primes(1,100)" at compile time.

>From our earlier discusion of 'random()' in the context of
Aldor types that are determined at compile-time, it seems
clear that it should be no problem to define a constant such
as

  P:List Integer == primes(1,100);

In fact, 'primes(1,100)' is a constant expression. As we
discovered, although P is a constant it's actual *value* is
only determined during run-time initialization, and then it
is fixed for the duration of the program execution. I recall
that you demonstrated in several programs that types in Aldor
(which must be constant) are also evaluated in exactly this
way.

At first I found this very surprising but now I am pretty
happy about it. :) That this is the case should not really
be so surprising considering that one of the target runtime
environments for Aldor is lisp!

Anyway I see no reason in principle for Aldor to reject
something like:

  [f(100,n) for n in P]::Cross(PF(n) for n in P)

where the bracket function is define by the Cross domain
constructor.

This is not the only type which satisfies Martin's original
example. Another possibility is:

  [f(100,n) for n in P]::List Union(n:PF(n) for n in P)

i.e. a List over a type union. This would be a more general
type than the cross product, but equally valid from a
conceptual point of view.

> ...
> >> I cannot believe that a construction like
> >>
> >> [f(100, n) for n in [2,3,5]$List(Integer)]
> >>
> >> would work.
> >
> > The main reason why it is not working presently is because
> > we have not constructed cartesian product over an arbitrary
> > set of domains. But nothing in the language (even Spad)
> > seems to prevent one from doing this.

I am afraid that there may indeed be such a restriction --
at least in SPAD. The problem is how and when the arity of
functions is decided. The arity is actually encoded into
the names given to the functions and as far as I know these
names *must* be decided strictly at compile-time.

The situation in Aldor might be different but I do not
understand in sufficient detail the actual FOAM that Aldor
generates.

>
> Of course not, but note that you have a generator in the
> above construction and thus the compiler does not know the
> length of the tuple until it is *computed*.

Although the length is not known at compile-time, nontheless
it is fixed at run-time initialization. That is not an
unusual sitation in Aldor.

>
> Oh, yes, of course it is possible (even now) to construct a
> heterogeneous tuple type via Generator.

Really?

> But Martin's construction would mean to construct the type
> AND the element at the same time. And that (I believe) is
> impossible.
> ...
> But I still cannot make
>
> [f(100, n) for n in [2,3,5]$List(Integer)]
>
> into valid Aldor code if f is the function given by Martin.
>

Probably what we need is some kind of recursive type constructor.
See for example:

http://www.cs.kent.ac.uk/people/staff/sjt/Atypical/AldorExs/vector.as

Something like ... ?

PFCartesian(k: Integer): Type
    == if k<=1 then PF(1) else =
Record(fst:PF(k),rst:PFCartesian(k-1));

See also section 23.8 "Recursive Strurctures" page 324 of the
Axiom Library Compiler Users Guide, 1994:

www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/documentation/axlugII.pdf

I hope to have more time some to work with these examples.

\start
Date: Thu, 31 Aug 2006 10:41:41 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Aldor-l] spad: language and compiler

On 08/31/2006 05:20 AM, Page, Bill wrote:
> On Wednesday, August 30, 2006 7:05 PM Ralf Hemmecke wrote:
>> ... 
>> As you know Record and Cross are two ways in Aldor to construct
>> heterogeneous tuples. The problem is that both must have a 
>> certain fixed length when you write them into your program.
>> ...
> 
> What does "fixed" mean in this context?

If you write Cross(A1, A2, ..., Ak) in your program with k types 
A1,...,Ak then the the k must be a natural number. Of course you can write

Cross(A1);
Cross(A1, A2);
Cross(A1, A2, A3);

but you cannot write

Cross [x for x in g]

for some Generator G and an appropriate definition of bracket.

Oh... maybe one can... but I am too lazy to check that you can write a 
bracket: Generator Type -> Tuple Type
and hand the result to Cross.

Anyway it doesn't solve the problem of having to generate the value and 
the type at the same time.


>> Martin's line contained a "for n in primes(1,100)" iterator, 
>> so the type would only be known if the compiler were able to
>> evaluate "primes(1,100)" at compile time.
> 
>>From our earlier discusion of 'random()' in the context of
> Aldor types that are determined at compile-time, it seems
> clear that it should be no problem to define a constant such
> as
> 
>   P:List Integer == primes(1,100);
> 
> In fact, 'primes(1,100)' is a constant expression. As we
> discovered, although P is a constant it's actual *value* is
> only determined during run-time initialization, and then it
> is fixed for the duration of the program execution. I recall
> that you demonstrated in several programs that types in Aldor
> (which must be constant) are also evaluated in exactly this
> way.

Oh, yes. Good remark.

> At first I found this very surprising but now I am pretty
> happy about it. :) That this is the case should not really
> be so surprising considering that one of the target runtime
> environments for Aldor is lisp!
> 
> Anyway I see no reason in principle for Aldor to reject
> something like:
> 
>   [f(100,n) for n in P]::Cross(PF(n) for n in P)
> 
> where the bracket function is define by the Cross domain
> constructor.

Interesting. That looks good, but is terribly wrong. Why? Because
    for n in P
accesses P destructively. Depending on what is evaluated first, either 
the Cross is essentially Cross() or the bracket is []. What language 
specification tells you the compiler should produce? (And both would be 
wrong anyway.)

>>>> I cannot believe that a construction like
>>>>
>>>> [f(100, n) for n in [2,3,5]$List(Integer)]
>>>>
>>>> would work.
>>> The main reason why it is not working presently is because
>>> we have not constructed cartesian product over an arbitrary
>>> set of domains. But nothing in the language (even Spad)
>>> seems to prevent one from doing this.
> 
> I am afraid that there may indeed be such a restriction --
> at least in SPAD. The problem is how and when the arity of
> functions is decided. The arity is actually encoded into
> the names given to the functions and as far as I know these
> names *must* be decided strictly at compile-time.

This is exactly what I meant by "fixed length" above.

>> Oh, yes, of course it is possible (even now) to construct a 
>> heterogeneous tuple type via Generator.
> 
> Really?

You want me to produce code, right? ;-)

>> But Martin's construction would mean to construct the type
>> AND the element at the same time. And that (I believe) is
>> impossible.
>> ... 
>> But I still cannot make
>>
>> [f(100, n) for n in [2,3,5]$List(Integer)]
>>
>> into valid Aldor code if f is the function given by Martin.

> Probably what we need is some kind of recursive type constructor.
> See for example:
> 
> http://www.cs.kent.ac.uk/people/staff/sjt/Atypical/AldorExs/vector.as
> 
> Something like ... ?
> 
> PFCartesian(k: Integer): Type 
>     == if k<=1 then PF(1) else Record(fst:PF(k),rst:PFCartesian(k-1));

Oh! Although it is done a bit different, you should take a look at the 
definition of RecursiveMultivariatePolynomial0. Do you have the sources 
of Aldor's LibAlgebra?

> See also section 23.8 "Recursive Strurctures" page 324 of the
> Axiom Library Compiler Users Guide, 1994:

> www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/documentation/axlugII.pdf

> I hope to have more time some to work with these examples.

Oh, a definition of Tree... Not very exciting. We now have a way to 
construct a binary tree as a combinatorial species in aldor-combinat

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

Look at the end of the file src/species.as.nw and you'll find the 
following definition for a tree...

BinaryTree(L: LabelType): CombinatorialSpecies L == {
         macro {
                 + == Plus;
                 * == Times;
                 1 == EmptySetSpecies;
                 X == SingletonSpecies;
                 B == BinaryTree;
         }
         (1 + X * B * B)(L) add;
}

But I have the suspicion that it is not the right code to construct 
heterogeneous products. Anyway, the interesting part in the BinaryTree 
definition is that at the same time of constructing the tree you get a 
function that generates all (labelled) trees of a given size and a 
function that counts trees of a given size (the generating function).

\start
Date: Thu, 31 Aug 2006 12:16:54 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Aldor-l] spad: language and compiler

> Probably what we need is some kind of recursive type constructor.
> See for example:
> 
> http://www.cs.kent.ac.uk/people/staff/sjt/Atypical/AldorExs/vector.as

If you look closer to that, then you see that vector.as is implementing 
"List" in a terribly complicated way.

Look at

-- Add up the entries of a Vector(n).
addVec(n:Integer,v:Vector(n)):Integer
     == {
     import from Record(fst:Integer,rst:Vector(n-1));
     if n<=1
           then 0
	  else vec.fst + addVec(n-1,vec.rst);
	  where { vec == (v pretend				-- A
	  		 Record(fst:Integer,rst:Vector(n-1))); }};

in particular look at the argument. If it were a list you could forget 
about the n, but here you have to give it. I am sure, nobody would ever 
use such code.

If you must have a union over Vectors of arbitrary lenght then a cleaner 
design would be to define vectors of lenght n and in a second step 
define operations on vectors of different length.

In aldor-combinat you would define that thing like in the BinaryTree 
example I gave before but just use the equation V = 1 + X * V.
And, by the way, I did not use "pretend" in my code.

\start
Date: Thu, 31 Aug 2006 13:35:47 -0400
From: Tim Daly
To: list
Subject: Google Books Partner Program

Axiom is now a Google partner program member.
The Axiom Tutorial should soon be available as a 
free book download from Google.

\start
Date: Thu, 31 Aug 2006 18:11:09 -0400
From: William Sit
To: Bill Page
Subject: obsolete pages and portal download

Dear Bill:

Is there any info that is still useful on
http://page.axiom-developer.org?
Can some of these pages be deleted (or made unreadable by the public)?
It becomes very confusing to new users with so many info pages from the
past. Below are some sample wanderings:

I went and logged into http://portal.axiom-developer.org and click on
the Download button on the left. It said "Binary images and source
files", but "There are currently no items in the folder."

>From there, I selected the Home page. I don't think the posts after the
"add comment" button should belong there. The first post is "I try again
..." is dated 2004-09-02. While users should be allowed to post
comments, these should be monitored by everyone on the developer-list to
keep the info relevant.

When I viewed the download.html page (result after search on "axiom
download", the page seemed to be quite out of date). For example, it
says:
"The first release of Axiom is under development."

The page: http://portal.axiom-developer.org/wiki/AxiomWiki Main page,
which is: http://page.axiom-developer.org/zope/Plone/wiki/AxiomWiki, is
2 years old. 

Just a random comment from random browsing. Your work on the site is
always appreciated.

\start
Date: Fri, 01 Sep 2006 01:53:57 +0200
From: Gregory Vanuxem
To: Tim Daly
Subject: Re: --patch-50

Le mardi 29 ao=FBt 2006 =E0 11:15 -0400, root a =E9crit :
> Patch 50 is up in arch.

Bad news... As I said previously axiom patch 50 does not compile under
Debian testing (and Debian unstable) . The error is:

------------------------------------------------------------------------
45 making /usr/local/axiom/src/graph
make[3]: entrant dans le r=E9pertoire =AB /usr/local/axiom/src/graph =BB
1 making /usr/local/axiom/src/graph/viewman
make[4]: entrant dans le r=E9pertoire =AB /usr/local/axiom/src/graph/view=
man
=BB
1 linking /usr/local/axiom/mnt/linux/lib/viewman
gcc: /usr/X11R6/lib/libXpm.a: Aucun fichier ou r=E9pertoire de ce type
------------------------------------------------------------------------

where "Aucun fichier ou r=E9pertoire de ce type" means "not such file or
directory".

In Debian (testing/unstable) libXpm.a is in /usr/lib/ so the variable
XLIB is wrong (XLIB=/usr/X11R6/lib). Modifying the XLIB variable
corrects the problem (or eventually linking against the shared library).

\start
Date: Thu, 31 Aug 2006 19:56:30 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: --patch-50

try changing the AXIOM variable to:

export AXIOM=`pwd`/mnt/fedora5

\start
Date: Thu, 31 Aug 2006 20:16:04 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: --patch-50

does it compile in debian stable?
i'll try to build a debian machine here.

\start
Date: Fri, 01 Sep 2006 02:57:44 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: aldor for axiom link in the page

Hello Bill,

I wanted to add "If you want to use the aldor compiler see [Aldor For
Axiom]." at the end of the 'Building Axiom on Linux' paragraph (page :
http://wiki.axiom-developer.org/BuildAxiom) without success, it asked me
a password that I do not have (even if I give a reason).  

I'm sure you can add that :)

\start
Date: Fri, 01 Sep 2006 03:03:12 +0200
From: Gregory Vanuxem
To: Tim Daly
Subject: Re: --patch-50

Le jeudi 31 ao=FBt 2006 =E0 20:16 -0400, root a =E9crit :
> 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.

\start
Date: Thu, 31 Aug 2006 21:05:58 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: --patch-50

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

\start
Date: Thu, 31 Aug 2006 23:24:49 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: RE: aldor for axiom link in the page

Greg,

On August 31, 2006 8:58 PM you wrote:
> 
> I wanted to add "If you want to use the aldor compiler see
> [Aldor For Axiom]." at the end of the 'Building Axiom on Linux'
> paragraph (page :
> http://wiki.axiom-developer.org/BuildAxiom) without success, 
> it asked me a password that I do not have (even if I give a reason).
> 
> I'm sure you can add that :)

Yes, sorry. The reason your change was rejected is because of the
large number of bare http://... links on that page. The number of
such links is restricted becase of spam. But you can still use the
format "xxxx":http://...

I have added the text you wanted and I have also changed the links
to the new format so if you wish you can now edit it without a
password.

\start
Date: Thu, 31 Aug 2006 23:40:05 -0400
From: Bill Page
To: William Sit
Subject: RE: obsolete pages and portal download

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.

> 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?

See also for example Tim's personal page at:

http://daly.axiom-developer.org

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.

> It becomes very confusing to new users with so many info 
> pages from the past.

I agree.

> Below are some sample wanderings:
> 
> I went and logged into http://portal.axiom-developer.org and click
> on the Download button on the left. It said "Binary images and
> source files", but "There are currently no items in the folder."
> 
> From there, I selected the Home page. I don't think the posts
> after the "add comment" button should belong there. The first
> post is "I try again ..." is dated 2004-09-02. While users should
> be allowed to post comments, these should be monitored by everyone
> on the developer-list to keep the info relevant.

Agreed.

> 
> When I viewed the download.html page (result after search on
> "axiom download", the page seemed to be quite out of date). For
> example, it says: "The first release of Axiom is under development."
> 
> The page: http://portal.axiom-developer.org/wiki/AxiomWiki
> Main page, which is: 
> http://page.axiom-developer.org/zope/Plone/wiki/AxiomWiki,
> is 2 years old. 
> 
> 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. :-)

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






\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
