\start
Date: Fri, 1 Oct 2004 03:35:55 -0400
From: Bill Page
To: Bob McElrath
Subject: re: literate programming pamphlet files forMathAction

On Wednesday, September 29, 2004 3:10 PM Bob McElrath wrote:
> ...
> Bill Page wrote:
> > ... 
> > There are few more notes and some examples here:
> > 
> >   http://test.axiom-developer.org/wiki/ConversionToHTML
> > 
> > My approach is to use Norman Ramsey's Latex to HTML (l2h)
> > noweave filter. This filter together with noweave, is able
> > to produce HTML files directly from noweb (pamphlet) files.
> ...
> 
> Let me suggest that you do this as a ZWiki "pagetype". (see 
> pagetypes/ in the ZWiki source)  The relevant code for
> latexwiki is in the __init__.py file.

Yes, this is on my to-do-right list :)

> ... 
> Let me tell you what I have been doing, since it is very
> similar...
> 
> ... I have started [rewrite of ZWiki page-rendering code]
> this, and right now have a standalone code which does it
> "properly". This is a subclass of StructuredText and uses
> that machinery to render pages.
> 
> Why this is relevant to you:
> 
> When this is done I will start adding new page types.  For
> me the first will be "true" latex.

Wow, from what I have seen in Norman Ramsey's l2h code, that
sounds like a lot of work to do "from the ground-up", so as
to speak. BTW, if you read the l2h code, you will notice
that it does not use any regular expression pattern matching
stuff at all, but a rather different and seemingly robust,
mostly declarative parsing method that I hadn't seen before
called "continuations" - a little like co routines but different.
The syntax and semantics of Icon is very high level - not so
different from Python, so in principle a conversion of l2h
to Python might not be out of the question. In any case,
before embarking on "true" latex, I think it would be worth
looking at Ramsey's l2h documentation. See

  http://page.axiom-developer.org/zope/mathaction/l2h

> But since this is all done within the StructuredText system,
> new pagetypes (such as "spad") can *inherit* the needed
> latex functionality from latexwiki.  Thus we can combine
> our work into new page types in ways that cannot mangle the
> document.

I am not so sure how possible it might be to use Ramsey's
approach in the StructuredText framework - not such a good
match I think. One of my goals here is *code re-use* and
to avoid writing much new code except that needed as "glue".

> 
> The StructuredText classes are very simple.  Basically for
> each text "object" (like $math$) you have to write one
> function to recognize it and one function to render it. In
> addition there is a list of which "recognizers" have more
> importance than others, so you know what to do with things
> like [foo $bar$] vs. $foo [bar]$ or -- which takes precedence,
> the link [] or the latex?  This is very difficult to do
> properly with successive regexes that operate on the whole
> document. That it works at all right now is a rather large
> hack involving successive conversions to html, and ignoring
> html...

For me, such re-used has only really begun to seem possible
and practical in the new world of supercomputer desktops.
I used to think badly of, and label as a "hack", the sometimes
inefficient and often conceptually muddled software that
results from such "cross-breeding", but the technology has
definitely changed since the last time I did this kind of
work...
 
> 
> This is not as good as a formally defined document grammar,
> but is probably the best we can get with what we are doing.
> 
> Join me on #zwiki at irc.freenode.net if you'd like to
> discuss this further.  I think we should discuss the
> "big scheme" before we head in different directions and
> end up with a pile of incompatible software.

I would like to discuss this further, but I find synchronous
communication via irc etc. to awkward given my irregular
schedule. Let's continue here or via wiki somewhere (your
place or mine? :)

> 
> I have placed my preliminary StructuredText classes here::
> 
>    http://bob.mcelrath.org/WikiStructuredText
>
> along with a standalone example program showing how to use it.
> I hope this should make it obvious how to extend.
>
> This will result in a more extensible, understandable, and
> robust codebase.  Not to mention faster.

Thanks. I *will* look at this but I can not promise that it
will be soon.

> P.S. do I understand that MathAction is your website, and
> not a piece of software?

Yes. Specifically MathAction is what I call the stand-alone
LatexWiki-based website at

  http://page.axiom-developer.org/zope/mathaction

As you know, there is also the Axiom Portal web site that is
Plone-based and supports LatexWiki objects.

  http://page.axiom-developer.org/zope/plone

I really don't want to get into maintaining a piece of
software. I would much prefer to leave that to other people
(such as yourself). But as seems common among "open source
types", I am a bit of a maverick when it comes to using
(and re-using) software, so I can't guarantee that I will
always be working in a structured mode that will be easy
to merge. As usual, our ambitions still far out strip
our resources and time constraints...

\start
Date: Fri, 1 Oct 2004 04:13:59 -0400
From: Bill Page
To: Bob McElrath
Subject: re: literate programming pamphlet files for MathAction
Cc: Yannis Chicha, Jinlong Cai

On Thursday, September 30, 2004 12:25 PM Bob McElrath wrote:
> 
> Tim Daly wrote:
> > I hope that, in the longer term, the mathaction wiki page 
> > presents the original pamphlet file when you click 'edit'.
> > That would imply running noweb in the background when you
> > click 'save'.

That is *exactly* who the pamphlet support in MathAction will
work. You will be able to try it very soon now, once I tweak
l2h just a little more to avoid a problem in the way it creates
cross-references in an HTML+LaTeX file which sometimes messes
up the LatexWiki processing. Running it "in background" is
straight-forward.

> > The hard part, of course, is that the change might actually
> > fail, in which case there will be a noweb msg or latex log
> > file.

That is of course already a problem when writing Axiom and
Reduce code that might fail for a variety of reasons. In fact
it is also true for simple LaTeX coding errors and sometimes
even unexpected results from "structured text" mode.
 
> [Bob replied:]
> Right now the page is not rendered and an error is printed
> at the bottom of the page when you view it.  Ideally, this
> integration should be tighter.  Perhaps a "test" button that
> could pop up the rendered page?

YES! I would like this sort extension of LatexWiki very much.
It would also help solve the problem of "junk email" being
sent to wiki subscribers while just trying to get "something
stupid", right. I like to run the MathAction wiki with the
subscription options set to send all edits and not just the
new page stuff. But this can sometimes get tedious. If a
user could click a Draft or Preview button instead of the
Save button, then editing cycle could be (Edit, Preview)*,
Save with only the final Save resulting in sending the
diffs to the subscribers. A few weeks ago I did look at
the possibility of adding this but I realized that it would
really have to be an extension of ZWiki, not LatexWiki,
and I did not know enough about ZWiki to even attempt it.

> [Tim continued:]
> > If we could do this then it would be possible (at least
> > technically) to maintain axiom directly from the wiki
> > pages. Of course there are a lot of little steps along
> > the way. I'd like to see the ability to integrate CVS
> > (or arch?) automatically into web page changes.

I think that this will be quite easy to implement. The
only step that I see missing in what I am doing right now
would be some means to directly integrate the wiki pages
containing the pamphlet code into the notangle processing
in the build makefile. Wiki pages are Zope objects that are
not directly accessible to the file system.
 
> 
> This was mentioned before...
> 
> Zope has a rudimentary "change history" that can be used
> to undo bad changes, but it is crude as a versioning system.

Personally, I think that Zope's history mechanism would be
sufficient for most purposes (I don't know how many times
the Zope Undo has saved me from loosing important work)
although, granted it is not darcs, arch or even CVS. However
I think there are some Zope products available that do this
sort of integration with CVS and arch. I don't know how well
or even if this would work with ZWiki / LatexWiki / MathAction.

> [Bob replied:] 
> There is also a Zope product called FileSystemSite in which
> your site is stored in a directory on the filesystem, rather
> than in the ZODB. Such a directory can simultaneously be a
> CVS/arch/darcs repository. Presumably it wouldn't be that
> hard to get Zope/ZWiki/LatexWiki to ignore the CVS directory.

That is yet another way to go, but have you ever tried
running ZWiki this way? I suspect that ZWiki might be rather
tightly integrated with the Zope object model so that this
is not straight forward. For example a wiki page actually
contains at least two representations of each page, the
'source' and the rendered 'presentation' form. Which of
these would be stored in the file system. Both?

But there might well be some advantages to this on a large
shared web site. Zope is notoriously slow at serving web
pages (not surprizing considering all that it does). Storing
the rendered pages on the file system would allow greater
use direct use of the Apache front-end server instead of
depending on http proxy. Already I do this kind of optimization
for serving the image files from LatexWiki which are stored
in the file system and not as Zope objects.

\start
Date: Fri, 1 Oct 2004 06:23:01 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: literate programming pamphlet files forMathAction
Cc: Yannis Chicha, Jinlong Cai

On Thursday, September 30, 2004 9:57 AM Ralf HEMMECKE wrote:
> 
> >> I am very much open to everything, even LaTeX, but there
> >> should be some standard of how to document with ++ and
> >> this is missing  currently!
> 
> [Tim Daly wrote:]
> > I'm interested in this thread (though buried under a huge 
> > project work at the moment). The ++ and -- comments were
> > part of the original documentation mechanism. In the long
> > term these will go away.

I am also very interested in this discussion and also
believe that the ++ -- style comments and distinction
between them should go away.

> [Ralf HEMMECKE wrote:]
> Why should they go away? Is there a way in Axiom to
> produce a hyperlinked category hierarchy? Such a hierarchy
> should be generated from the actual CODE and not some
> latex documentation around.

Yes. That is exactly how the MathAction web site works
now with wiki pages containing compiled Axiom library code.
The TouchGraph navigator using the output of the compiler
to display the dependency graph of the Axiom categories,
domains and packages (which is not actually a hierarchy,
BTW).

> If then there is some helpful documentation like the ++
> comments that describe the input/output parameters and
> approximately what the domain/category/function is doing,
> this would greatly help programmers.

Yes, this (and a lot more) will be directly available to
programmers when they navigate the hyperlinked MathAction
wiki pages containing the Axiom pamphlet files.

> 
> I don't say that this should be the only documentation,
> but it should not go away, because programmers need the
> exact interface of functions in a compact way. Sometimes
> one knows what a function is doing, but not exactly in
> which order the parameters go and what there exact 
> specification is. Putting this information away from the 
> function code is dangerous.
> 
> Of course with noweb, one can do everything nicely, but
> the documentation is lost for the Aldor compiler then.
> 

I don't see much point of giving documentation to the
compiler. Perhaps like the built-in Axiom compiler,
Aldor can be made to produce output which could be
interpreted as hyperlinks into the appropriate documentation?

> 
> [Tim Daly wrote:]
> > There will be new environments in the pamphlet file
> > which will be standardized and automatically extracted.
> > Standard environments include \begin{testcase} for
> > integrating .input file tests, \begin{concept} for
> > tagging the introduction of a new concept that needs
> > to be pushed into a semantic network (see the crystal
> > discussion in the history), etc. These stylized environments
> > will, like \begin{list}, probably have special sub-tags
> > (like \testinput and \testresult so testcases can
> > automatically verify the results).

Although this is technically possible, I think that it is
likely to fail for the same reasons that Tim gives below
for the failure of the -- ++ comment mechanism - something
that is not an integral part of the development process is
very likely to be ignored by (most) developers.

> [Tim Daly wrote:]
> > ++ and -- suffer from the usual problem of documentation.
> > Programmers will not maintain documentation tags. mostly
> > because almost nobody but the programmer ever reads code.
> > we tried to be clever about it and make the comments "live"
> > with hyperdoc (a pre-javadoc idea). unfortunately it still
> > suffers from the fact that embedded comments are not the
> > primary reason for a .spad file. I'm hoping that the 
> > pamphlet file (which makes the documentation task primary
> > and coding secondary) will encourage computational
> > mathematicians to actually write papers that include
> > working code and programmers to write real papers that
> > explain their algorithms.

Yes, I think that this is very desirable *but* I think
that it is necessary to make the documentation more
directly usable than is the pamphlet file right now. Writing
LaTeX and thinking noweb/pamphlet organization for the code
is a complex skill that has to be learned. As a result it
is often left as an "after the fact" step in the creation
and publication of new ideas. I think we need to get useful
tools more "up front". This is fairly natural when using
computer algebra in mathematics and physics. Both Maple and
Mathematica have fairly "evolved" worksheet style user
interfaces that aid in the process, but they are missing
a more directly link to publishing.

I am mildly optimistic that the MathAction approach can
do all of this. :)

>
> [Ralf HEMMECKE wrote:]
> I agree to a certain extend, but not completely. The pamphlet
> idea is wonderful, but the paper-style text is quite unhandy
> as a reference manual. An additional documentation like,
> for example,
>
> http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/html/node18.html
>
> would be desirable. Or can this be done already with AXIOM?

Yes, that is exactly what the MathAction interface to Axiom
will provide. See for example

  http://page.axiom-developer.org/zope/mathaction/dhmatrix

The hyperlink category and domain references are shown below the
Axiom code shown in green. For a graphical view of the links
click on the 'navigator' option at the top right of the page. See

    http://page.axiom-developer.org/zope/mathaction/TouchGraph

for more information about how to use the graphical navigator.

The layout and contents of this page is very close to what a user
will see for each pamphlet file in the system although right now
this page was generated in part manually rather than automatically
the way it soon will be when the user clicks Save after editing.
There will also be internal hyperlinks and an index for code chunks
like you see here

  http://page.axiom-developer.org/zope/mathaction/l2h

but I have a small problem right now with generating this links
when the page contains LaTeX codeing.

At this time I am still uncertain as to whether to include the
nontangle+Axiom output in the same page as the documentation,
as shown on the current dhmatrix page above, or whether to
present this in a separate page.

\start
Date: Fri, 1 Oct 2004 12:51:26 +0000
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: literate programming pamphlet files for MathAction

Ralf HEMMECKE writes:

 > As far as I know there are 3 languages, all slightly different.
 > A Aldor
 > S SPAD
 > I Axiom interpreter language
 > 
 > I could live with A \ne I, because the interpreter is there to make life 
 > easier for the lazy user. For serious programming, however, Axiom should 
 > use Aldor, not SPAD. I believe that SPAD and Aldor still differ in some 
 > places, unfortunately.

That is exactly what I meant. Tim Daly said that using Aldor for compiling
Axiom files (i.e., .as files that contain Aldor code but rely on the Axiom
library) should work, but either I'm missing the obvious or it is not obvious
how to do it...

I think this should be first priority for those who can resurrect this.

For lisp and especially compiler gurus -- Camm, I believe that's you... :-) --
a great (non-priority) project might be to make a (simple! non-optimizing) lisp
implementation of the Aldor compiler that could be freely distributed and run
within axiom.

One good reason for that is the following: a bug can have different
origins. Sometimes it is obvious, that it is an algebra bug, or a compiler bug,
or a lisp bug, but sometimes this is not clear at all.

Having different, but semantically -- modulo bugs -- equivalent implementations
would ease debugging quite a bit, I imagine.

On the other hand, given our limited resources, this seems quite out of
reach...

\start
Date: Fri, 1 Oct 2004 13:31:11 +0000
From: Martin Rubey
To: Bill Page
Subject: re: literate programming pamphlet files for MathAction

Bill Page writes:
 > On Thursday, September 30, 2004 9:57 AM Ralf HEMMECKE wrote:

 > I am also very interested in this discussion and also
 > believe that the ++ -- style comments and distinction
 > between them should go away.

I think that both ++ and -- *could* serve one purpose as follows:

as a said before, -- comments often contain old code. I think it is not wise to
ban this code into the archives too early, since it often explains why the new
code looks as it looks like. Clearly, such -- comments need to be rendered just
as the rest of the code, it might be nice if they were a little "lighter".

++ comments currently contain a *short* explanation of what the function
does. Appendix E of Jenks Sutor (which is missing from the electronic version)
seems to be a compilation of this. 

I am absolutely certain that this kind of documentation will be necessary in
future to. )show Integer does not suffice, since it contains only the
modelines. For example:

prefixRagits :
   [1] RadixExpansion D2 -> List Integer from RadixExpansion D2 if D2: 
            INT

      ++ prefixRagits(rx) returns the non-cyclic part of the ragits
      ++ of the fractional part of a radix expansion.
      ++ For example, if \spad{x = 3/28 = 0.10 714285 714285 ...},
      ++ then \spad{prefixRagits(x)=[1,0]}.

In some way or the other, we will need such short "abstracts" of each
function. Many of them are present currently, their style is very close to
StructuredText, so I'd suggest to use them! And yes, even to compile them
in. It will be a lot easier to extract them from a database then to extract
them from the pamphlet files.

If you propose to have some other command in the pamphlet file that creates
such a database, be it.

 > > [Tim Daly wrote:]
 > > > Standard environments include \begin{testcase} for
...
 > > > (like \testinput and \testresult so testcases can
 > > > automatically verify the results).

I think that {testcase}, \testinput and \testresult will be useful and will be
used. I wouldn't bother about the rest.

 > At this time I am still uncertain as to whether to include the
 > nontangle+Axiom output in the same page as the documentation,
 > as shown on the current dhmatrix page above, or whether to
 > present this in a separate page.

I vote for a separate page. However, there seems to be quite a bit missing from
the pamphlet file. I copy it here so you can verify. (note: directly copied
from the dvi file, so some characters are wrong.) The dvi output ends with:


Denavit-Hartenberg Matrices 
hdomain DHMATRIX DenavitHartenbergMatrixi 
? 
--Copyright The Numerical Algorithms Group Limited 1991. 
++ 4x4 Matrices for coordinate transformations 
++ Author: Timothy Daly 
++ Date Created: June 26, 1991 
++ Date Last Updated: 26 June 1991 
++ Description: 
++ This package contains functions to create 4x4 matrices 
++ useful for rotating and transforming coordinate systems. 
++ These matrices are useful for graphics and robotics. 
++ (Reference: Robot Manipulators Richard Paul MIT Press 1981) 
)abbrev domain DHMATRIX DenavitHartenbergMatrix 
--% DHMatrix 
DenavitHartenbergMatrix(R): Exports == Implementation where 
++ A Denavit-Hartenberg Matrix is a 4x4 Matrix of the form: 
++ \spad-nx ox ax px" 
++ \spad-ny oy ay py" 
++ \spad-nz oz az pz" 
++ \spad-0 0 0 1" 
++ (n, o, and a are the direction cosines) 
R : Join(Field, TranscendentalFunctionCategory) 
-- for the implementation of dhmatrix 
minrow ==> 1 
mincolumn ==> 1 
-- 
nx ==> x(1,1)::R 
ny ==> x(2,1)::R 
nz ==> x(3,1)::R 
ox ==> x(1,2)::R 
oy ==> x(2,2)::R 
oz ==> x(3,2)::R 
ax ==> x(1,3)::R 
ay ==> x(2,3)::R 
az ==> x(3,3)::R 
px ==> x(1,4)::R 
py ==> x(2,4)::R 
pz ==> x(3,4)::R 
row ==> Vector(R)
 

col ==> Vector(R) 
radians ==> pi()/180 
Exports ==> MatrixCategory(R,row,col) with 
"*": (%, Point R) -> Point R 
++ t*p applies the dhmatrix t to point p 
identity: () -> % 
++ identity() create the identity dhmatrix 
rotatex: R -> % 
++ rotatex(r) returns a dhmatrix for rotation about axis X for r degrees 
rotatey: R -> % 
++ rotatey(r) returns a dhmatrix for rotation about axis Y for r degrees 
rotatez: R -> % 
++ rotatez(r) returns a dhmatrix for rotation about axis Z for r degrees 
scale: (R,R,R) -> % 
++ scale(sx,sy,sz) returns a dhmatrix for scaling in the X, Y and Z 
++ directions 
translate: (R,R,R) -> % 
++ translate(X,Y,Z) returns a dhmatrix for translation by X, Y, and Z 
Implementation ==> Matrix(R) add 
identity() == matrix([[1,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]]) 
-- inverse(x) == (inverse(x pretend (Matrix R))$Matrix(R)) pretend % 
-- dhinverse(x) == matrix( _ 
-- [[nx,ny,nz,-(px*nx+py*ny+pz*nz)],_ 
-- [ox,oy,oz,-(px*ox+py*oy+pz*oz)],_ 
-- [ax,ay,az,-(px*ax+py*ay+pz*az)],_ 
-- [ 0, 0, 0, 1]]) 
d * p == 
v := p pretend Vector R 
v := concat(v, 1$R) 
v := d * v 
point ([v.1, v.2, v.3]$List(R)) 
hrotatexi 
hrotateyi 
hrotatezi 
hscalei 
htranslatei
 
27
20 
License 
hlicensei 
? 
--Portions Copyright (c) Richard Paul 
--Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd. 
--All rights reserved. 
-- 
--Redistribution and use in source and binary forms, with or without 
--modification, are permitted provided that the following conditions are 
--met: 
-- 
-- - Redistributions of source code must retain the above copyright 
-- notice, this list of conditions and the following disclaimer. 
-- 
-- - Redistributions in binary form must reproduce the above copyright 
-- notice, this list of conditions and the following disclaimer in 
-- the documentation and/or other materials provided with the 
-- distribution. 
-- 
-- - Neither the name of The Numerical ALgorithms Group Ltd. nor the 
-- names of its contributors may be used to endorse or promote products 
-- derived from this software without specific prior written permission. 
-- 
--THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
--IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 
--TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 
--PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER 
--OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 
--EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 
--PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR 
--PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 
--LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
--NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 
--SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
h*i 
? 
hlicensei 
hdomain DHMATRIX DenavitHartenbergMatrixi

\start
Date: Fri, 1 Oct 2004 14:43:16 +0000
From: Martin Rubey
To: William Sit
Subject: Re: How to use MathAction

Dear William,

this post adresses only the simple issue at the end of your mail. I'll have to
think a few minutes about the more complicated issues before...

William Sit writes:

 > Martin Rubey wrote:
 >
 > > Would you be able to write down as cleanly as possible the two proposals
 > > and add them add them at the bottom of
 > > 
 > > http://page.axiom-developer.org/zope/mathaction/WhereDoVariablesBelong
 > > 
 > 
 > I visited your page and it is taken from your posts. However, we have posted
 > back and forth and as you said, comments cannot be taken out of context and
 > in email, we quote each other. I don't know how to do that in mathaction.

That was not my intention. (By the way, please replace "able" by "so kind".
sorry)

 > I could be wrong, but my impression is that the attractiveness of mathaction
 > pages is that you can run live Axiom code and it is browser based. So I
 > think it is an ideal platform for documentation or summaries with examples,

Exactly. So what I meant: write a short summary of your proposal, and modify
the page like

Proposal 1:

  ...

Proposal 2:

  ...

 > but a rather poor platform for casual discussion. For example, one can only
 > add comments at the bottom, making it difficult to refer to lines or codes
 > on the page.

That's only correct if you want to use it via email. I wouldn't suggest
that. What you can do is: press edit, copy the whole content of the page into
your favorite text editor, modify it, paste it back.

 > But even if it becomes more fancy like MS Word, 

BEWARE!

 > Despite the extra effort, in order that someone not familiar with the issues
 > can follow, the pages have to be tutorial in style.  

Yes.

 > And that takes rewriting.  I don't know how detail or how brief I should
 > write (that is, who will be the readers?)

Well, I'd say, those who followed the thread a long time ago and want to make
up their mind what was their conclusion. I.e., no more than 20 lines.


 > I don't like text files and much prefer LaTeX to get pdf or dvi output. 

You can (and should) use LaTeX (where appropriate)!


 > Lots of text editors don't have good line breaks (or paragraph reflow) and
 > arbitrarily change them (like most email programs). 

Don't worry about line breaks.

Here are the essentials, mostly from the help page (5th button on the top left
of every mathaction page)

------------------------------------------------------------------------
Formatting rules in a nutshell

When you save a page, Zwiki normally applies standard ZWiki:TextFormattingRules
- most often ZWiki:StructuredText, which is described here; wiki linking rules;
and some additional formatting for comments.

paragraphs: non-blank lines are run together to form a paragraph; paragraphs
            are separated by blank lines (PLEASE: keep your lines shorter than
            80 chars in your source. That makes the diff's a lot easier to
            read.)
 
headings: a one-line "paragraph" followed by a more-indented paragraph makes a
          heading. Tip: you need only indent the first line.
 
lists: a paragraph beginning with - or a number followed by a space makes a
       bullet or numbered list item; a more-indented list item starts a
       sub-list
 
links: [ProgrammingAxiom]
       "programming":ProgrammingAxiom
       "hacking":http://page.axiom-developer.org/zope/mathaction/ProgrammingAxiom
 
code: short text enclosed in single quotes is quoted, i.e. displayed in
      monospace font and protected from some of the above formatting. For
      reliable quoting of a body of text, indent it after a paragraph ending
      with a double colon ::

       Like this (edit this page to see source).  This is the surest way to
       prevent WikiLinks, <HTML tags> and &dtml-tags; and preserve fixed-width
       formatting.

 
don't bother trying to learn all the text formatting rules and their
interactions. Mimic the text around you; when it does something unexpected,
tweak it until it looks right; go to the docs or ask for help when you get
really stuck or curious.


 > The text file would have to include Axiom code fragments as examples. I don't
 > know how to get "live" axiom with mathaction, the way your pages look.

\begin{axiom}
1+1
\end{axiom\

 > Well, I think this is truely a joint effort and fruitful discussion. I
 > wouldn't have thought of the problem (or proposal) if you didn't raise
 > it. So, thanks.

It's a pleasure. And I'd like to thank you for your patience, too!

\start
Date: Fri, 1 Oct 2004 15:23:51 +0000
From: Martin Rubey
To: list
Subject: exquo issue

Dear all,

as you may have noticed, 

exquo(simplify((A-2^a)*(A+2^a))::UP(A,EXPR INT),(A-2^a)::UP(A,EXPR INT))

currently fails. The reason is that Axiom does not know that

simplify((2^a)^2-2^(2*a))

vanishes.

Of course, that problem is unsolvable in general. However, I'm quite sure that
the current way deals with the problem (it ignores it) is that good.

I see the following possibility:

Every domain (that has a zero element) should know whether it can determine
whether one of its members is zero or not.

If it cannot, it should implement heuristics, but emit a warning.

Opinions?

\start
Date: Fri, 1 Oct 2004 10:14:40 -0400
From: Bill Page
To: Martin Rubey
Subject: re: literate programming pamphlet files for MathAction

On Friday, October 01, 2004 9:31 AM Martin Rubey
Martin Rubey wrote:
> ... 
> I think that both ++ and -- *could* serve one purpose as
> follows: as a said before, -- comments often contain old
> code. I think it is not wise to ban this code into the
> archives too early, since it often explains why the new
> code looks as it looks like. Clearly, such -- comments need 
> to be rendered just as the rest of the code, it might be
> nice if they were a little "lighter".

I am not sure what you mean by "ban this code into the
archives". If one is working in a system like Zope that
retains a history, then nothing is banned. All you need
to do is take a look at the "diffs". For example look at

  http://page.axiom-developer.org/zope/mathaction/dhmatrix

Then click on 'diff' on the top right-hand side of the
page. You can click on 'previous edit' to see the entire
history of the contents of this page.

That said, you are right that some code highlight might
(if artfully done) might make Axiom code a little easier
to read. Shading in-line comments is one such simple thing.
Other examples are variable names in bold and/or maybe
different color depending on type etc. It is possible but
would require more syntax analysis - probably almost as
much work as the compilation itself. It is technically
possible but probably not really worth the effort.

But I think you are missing the point of Tim Daly's remarks.
Really, what is desired is that Axiom developers (and Knuth
and the 'literate programming movement' would claim that
programmers in general should do this) consider that what
they should be doing is creating a document, like writing a
scientific paper - one that is first of all intended to be
read and understood by other people (or oneself many years
later). The content of this document will also include
programming code, or in Axiom's case Axiom commands, which
is intended to be processed by the system in order to provide
proofs and/or demonstrations of mathematical concepts or to
extend the system in some way (e.g. define new categories
and domains).

>From this point of view, 'commented out' old programming
code is no different than other text in the document. The
point of that text would be to describe the development
of the content of document itself, for example like a diary
or 'blog'. But usually it is better to let the system track
this instead of letting it 'clutter up' the document itself. 

> 
> ++ comments currently contain a *short* explanation of what 
> the function does. Appendix E of Jenks Sutor (which is missing
> from the electronic version) seems to be a compilation of this. 
> 
> I am absolutely certain that this kind of documentation will 
> be necessary in future to. )show Integer does not suffice,
> since it contains only the modelines. For example:
> 
> prefixRagits :
>    [1] RadixExpansion D2 -> List Integer from RadixExpansion 
> D2 if D2: 
>             INT
> 
>       ++ prefixRagits(rx) returns the non-cyclic part of the ragits
>       ++ of the fractional part of a radix expansion.
>       ++ For example, if \spad{x = 3/28 = 0.10 714285 714285 ...},
>       ++ then \spad{prefixRagits(x)=[1,0]}.
> 
> In some way or the other, we will need such short "abstracts"
> of each function. Many of them are present currently, their style
> is very close to StructuredText, so I'd suggest to use them!

Yes, of course. They become part of the literate document that
we are creating. Part of that document can be extracted and
organized automatically as needed.

> And yes, even to compile them in. It will be a lot easier to
> extract them from a database then to extract them from the
> pamphlet files.

No. This does not make sense. What you call 'pamphlet files'
are in fact already stored in a database - the Zope database.
That is what allows them to be manipulated in more complex
ways than just plain text files.

> 
> If you propose to have some other command in the pamphlet 
> file that creates such a database, be it.

No, it becomes part of the function of the online system
like on MathAction.

> ...
>  [Bill Page wrote:] 
> > At this time I am still uncertain as to whether to include
> > the nontangle+Axiom output in the same page as the
> > documentation, as shown on the current dhmatrix page
> > above, or whether to present this in a separate page.
> 
> I vote for a separate page.

Ok. Yes, the more I think about this, I agree. It should be
a separate but hyperlinked page.

> However, there seems to be quite a bit missing from the
> pamphlet file. I copy it here so you can verify. (note: 
> directly copied from the dvi file, so some characters are
> wrong.)

I don't understand from what you include below what you
think is "missing". You said: "missing from the pamphlet
file" but everything is generated from the file. Can you
give me an explicit example of something?

> The dvi output ends with:
> 
> 
> Denavit-Hartenberg Matrices 
> hdomain DHMATRIX DenavitHartenbergMatrixi 
> ? 
> --Copyright The Numerical Algorithms Group Limited 1991. 
> ++ 4x4 Matrices for coordinate transformations 
> ++ Author: Timothy Daly 
> ++ Date Created: June 26, 1991 
> ++ Date Last Updated: 26 June 1991 
> ++ Description: 
> ++ This package contains functions to create 4x4 matrices 
> ++ useful for rotating and transforming coordinate systems. 
> ++ These matrices are useful for graphics and robotics. 
> ++ (Reference: Robot Manipulators Richard Paul MIT Press 1981) 
> )abbrev domain DHMATRIX DenavitHartenbergMatrix 
> --% DHMatrix 
> DenavitHartenbergMatrix(R): Exports == Implementation where 
> ...

\start
Date: 01 Oct 2004 10:19:58 -0400
From: Camm Maguire
To: Martin Rubey
Subject: re: Quick question on the symbol issue:

Greetings, and please excuse the delayed reply.

Martin Rubey writes:

> Hi Camm!
> 
>  > As noted in the comment, regardless of resetNew(), subsequent invocations of
>  > new() will start where the counter left off, unless one adds code to
>  > unintern the specified symbols, which in this case might wipe out a symbol
>  > explicitly specified by the user.  Don't know what is best here, though I
>  > suspect the latter.
> 
> I don't understand what you explain here. What symbols do you mean with
> "specified symbols"?

new() ->%A
new() ->%B
new() ->%C
resetNew()
new() ->%A
new() ->%B
new() ->%C

before the patch

new() ->%A
new() ->%B
new() ->%C
resetNew()
new() ->%D
new() ->%E
new() ->%F

after.  As we inspect the package for pre-existing symbols in
selecting the index for new, we need to wipe out those symbols on
resetNew(). 

> If you can spare time I suggest that you look at 
> 
> http://page.axiom-developer.org/zope/mathaction/WishList
> 
> The TodoList currently seems a bit outdated to me. I will update it when I get
> to it. However, I'm not that good at rating what's important and what's not
> that urgent. I find that there are not that many severe unfixed bugs known at
> the moment (on the other hand: a (mathematical) bug is one bug too many), so
> maybe a windows port and more functionality (mathswise) has higher priority.
> 
        
Thanks for the list!  The one that leaps out to me is the
hypergeometric series.  Is there no such support in axiom so far?  In
all honesty, I have not yet acquired sufficient experience using
axiom, as I'm too busy supporting its build infrastructure, along with
that of acl2 and maxima.  I feel I could comment more meaningfully
after spending some time trying to apply axiom to real problems.

The windows port is an obvious low hanging fruit which I'm happy to
help with.  Unfortunately, I have no such machine, nor access to one.
Perhaps someone who has such a box on a fast network connection could
enable ssh access.  Tools needed would be msys, mingw, gdb, emacs, and
a shell.  I'm hoping the graphics will stay out of the way.  Our GCL
windows expert has done this for a time, but it was his home machine
and was understandably quite inconvenient.

> Maybe you could also add to the WishList what would be a real goody for a
> physicist?
> 

Feyncalc.  Actually this one might go at the top.

Another thing I receive requests for are graphics and the hyperdoc
documentation facility.

There is a lot of work to do with GCL too, so at most one of these
might get a small fraction of my spare cpu cycles, alas.

\start
Date: Fri, 01 Oct 2004 17:17:24 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: How to use ALDOR within AXIOM

Hi Martin,

Martin Rubey wrote:
> #include "axiom.as"
> 
> fact(n: PositiveInteger): PositiveInteger == {
>     n <= 1 => 1;
>     res: PositiveInteger := 1;
>     while n > 1 repeat {
>         res := res * n;
>         n := n-1;
>     }
>     res
>  }

I have put this into the file ff.as started axiom and then the following

(1) -> )compile ff
    Compiling AXIOM source code from file /home/hemmecke/ff.as using
       AXIOM-XL compiler and options
-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y 
$AXIOM/../../share/algebra
       Use the system command )set compiler args to change these
       options.
    Compiling Lisp source code from file ./ff.lsp
    Issuing )library command for ff
    Reading ff.asy
(1) -> fact 4

    (1)  24

So what is the problem?

Well, this was not OpenAxiom, but the NAG version. So at least this 
should be the way to use the aldor compiler.

But, under OpenAxiom, I cannot do this.

(1) -> )compile ff
    Compiling AXIOM source code from file
       /z_mnt/kludge/zlocal/md8/hemmecke/ff.as using AXIOM-XL compiler
       and options
-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y 
$AXIOM/algebra
       Use the system command )set compiler args to change these
       options.

    >> System error:
    Cannot get the truename of "/zvol/axiom/axiom/mnt/linux/compiler/bin/".

protected-symbol-warn called with (NIL)

I have AXIOM=/zvol/axiom/axiom/mnt/linux and a compiler directory in 
there is missing. So I said

ln -s /zvol/aldor/Linux $AXIOM/compiler

where /zvol/aldor/Linux is the root of my aldor installation.

I've found libaxiom.al in the CVS directory so...

ln -s /zvol/axiom/cvs/axiom/src/share/algebra/libaxiom.al \
    $AXIOM/compiler/lib

And I've put the file axiom.as

http://lists.gnu.org/archive/html/axiom-mail/2004-09/msg00033.html

into $AXIOM/compiler/include.


Then I started Axiom and...

(1) -> )compile ff
    Compiling AXIOM source code from file
       /z_mnt/kludge/zlocal/md8/hemmecke/ff.as using AXIOM-XL compiler
       and options
-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y 
$AXIOM/algebra
       Use the system command )set compiler args to change these
       options.

    >> System error:
    #p"/z_mnt/kludge/zlocal/md6/aldor/aldor/linux-libc2.2.5/1.0.2/bin/" 
is not of type STRING.

protected-symbol-warn called with (NIL)

The directory after the #p is the the same as /zvol/aldor/Linux/bin.

Does someone have an idea where this error comes from and maybe how to 
resolve it?

\start
Date: 01 Oct 2004 11:33:04 -0400
From: Camm Maguire
To: Bob McElrath
Subject: Re: Axiom crashing in Zope-Plone
Cc: Bill Page, Hans Peter Wuermli, Bob McElrath

Greetings, and thanks for your informative and helpful reply!

Bob McElrath writes:

> Bill Page wrote:
> > Bob McElrath supplied some details of the debian and
> > axiom installation on his Alpha system which was still
> > failing with a seg fault.
> > 
> > Your suggested possible cause being "libc et.al dynamic
> > dependencies" in the case of Bob's system seems plausible
> > to me. I expect he will get back to you about this soon.
> 
> alpha architecture:
>     ii  libc6.1           2.3.2.ds1-11      GNU C Library: Shared libraries
> axiom segfaults
>     ii  libc6.1           2.3.2.ds1-16      GNU C Library: Shared libraries
> axiom runs fine
> 
> i386 architecture:
>     ii  libc6             2.3.2.ds1-12      GNU C Library: Shared libraries
> axiom runs fine
> 
> Thus, it would appear that the debian package needs to add a dependency
> on libc6 2.3.2.ds1-12 or greater.  I do not know why on alpha it is
> "libc6.1" and on intel it is "libc6".  
> 

This is a bug in the glibc maintainer's 'shlibs' file.  If you would
like, I'd recommend filing a bug with this package via reportbug.

The autobuild for the alpha binary is atL

http://buildd.debian.org/fetch.php?&pkg=axiom&ver=0.20040831-1&arch=alpha&stamp=1094075004&file=log&as=raw

The toolchain versions used were:

Toolchain package versions: libc6.1-dev_2.3.2.ds1-16 linux-kernel-headers_2.5.999-test7-bk-17 gcc-3.3_1:3.3.4-9 g++-3.3_1:3.3.4-9 binutils_2.15-2 libstdc++5_1:3.3.4-9 libstdc++5-3.3-dev_1:3.3.4-9

Yet the (calculated from 'shlibs' files) dependencies were:

Depends: libc6.1 (>= 2.3.2.ds1-4), libgmp3, libncurses5 (>= 5.4-1), libreadline4 (>= 4.3-1), axiom-databases (= 0.20040831-1)

Please note also that now that -16 is in testing, the issue will not
bite anyone doing an apt-get upgrade.


> Hans, can you confirm on intel?
> 

My suspicion here is in the python lib calling axiom.  If one can
reproduce an error with the intel axiom standalone, I'd be most
appreciative!

\start
Date: Fri, 1 Oct 2004 17:35:58 +0000
From: Martin Rubey
To: Bill Page
Subject: re: literate programming pamphlet files for MathAction

Bill Page writes:
 > I don't understand from what you include below what you
 > think is "missing". You said: "missing from the pamphlet
 > file" but everything is generated from the file. Can you
 > give me an explicit example of something?


All the code I included does not appear when I look at 

http://page.axiom-developer.org/zope/mathaction/Dhmatrix 

\start
Date: 01 Oct 2004 11:43:58 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Axiom crashing in Zope-Plone
Cc: Hans Peter Wuermli, Bob McElrath

Greetings!  Bill your summary is wonderful!  Thanks!

Bill Page writes:

> Cam,
> 
> The original report from Hans:
> 
>   http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00056.html
> 
> referred to what later was discovered to be a seg fault
> (EXITSTATUS:139 from Python 2.2 popen3) generated by Axiom
> when run as a sub-process (popen3). Hans later reported that
> the failure occured while running a debian binary version
> of Axiom on an Intel i386 box.
> 

My suspicion lies in python's pipe code, possibly in conjunction with
GCL readline.  Can a segault be reproduced with axiom intel
standalone?  Alternatively, can someone please try to reproduce
setting the TERM environment variable to "dumb"?  Might need to check
strace -f on the process to make sure Python does not setup the pipe
environment as a readline capable terminal (e.g. vt100).  If one can
get to axiom at all over the pipe, try doing )lisp (si::readline-off)
at the beginning, or putting this into some axiom rc startup file or
something. 

Please feel free to report all Debian binary bugs to the Debian BTS
via 'reportbug'.

> In
> 
>   http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00059.html
> 
> Bob McElrath reported that he obtained the same failure
> when trying to run a debian binary version of Axiom as a
> sub-process on an Alpha debian system. It also turned
> out that Bob observed the seg fault even when Axiom was
> not run as a sub-process.
> 

(separate email)

> In the message
> 
>   http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00062.html
> 
> and
> 
>   http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00064.html
> 
> Hans reported success on the same hardware platform and
> debian version but with Axiom re-compiled from source.
> 
> In
> 
>   http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg00065.html
> 
> Bob McElrath supplied some details of the debian and
> axiom installation on his Alpha system which was still
> failing with a seg fault.
> 
> Your suggested possible cause being "libc et.al dynamic
> dependencies" in the case of Bob's system seems plausible
> to me. I expect he will get back to you about this soon.
> 
> ----------
> 
> Since Hans' problem was solved with a re-compile of Axiom
> from source (and a different, older? version of gcl) on a
> debian Intel platform, I would worry that this might
> indicated a memory management problem which is more severe
> when Axiom is run as a sub-process - perhaps with limited
> physical memory since Python + Zope + LaTeX + +Ghostscript
> + Axiom is a pretty heavy combination.
> 
> Hans said that he would be busy with his "day job" for
> the next week but that he intended to try to build the
> MathAction configuration again from scratch to see he
> he gets the same problem and solution.
> 
> Thanks for looking into this!

Great!  Please keep me posted.

Take care,

> 
> Regards,
> Bill Page.
> 
> > -----Original Message-----
> > 
> > Greetings!  Haven't heard anything here -- just wondering if this
> > issue is still live.
> > 
> > Take care,
> > 
> > Camm Maguire writes:
> > 
> > > Greetings!  My apologies, but I've lost the head of this 
> > thread.  I'm
> > > assuming that there is a segfault problem with debian alpha axiom
> > > (unstable).  (GCL is built in btw).  I'm also assuming the problem
> > > shows up on startup.  In this case, I cannot reproduce -- just
> > > downloaded the binaries and installed on 
> > escher.debian.org's unstable
> > > dchroot.  Of course you can only run these on Debian testing or
> > > unstable due to the libc et.al dynamic dependencies.  Is that the
> > > problem?  If any of this is close, please fill in a 
> > detailed way I can
> > > reproduce the crash, or better yet, send a copy both to me 
> > and to the
> > > Debian BTS.  'reportbug' is good for this.
> > > 
> > > For the package to build, btw, the compiled axiom must successfully
> > > run the full input test suite, so the very existence of the alpha
> > > package means that this was done.  You can find a log on
> > > buildd.debian.org if interested.
> > > 
> > > Take care,
> > > 
> > > Bob McElrath writes:
> > > 
> > > > Bill Page wrote:
> > > > > Hans,
> > > > > 
> > > > > Do I understand correctly that after re-compiling Axiom that
> > > > > you now have a fully operational LatexWiki system under debian
> > > > > that can run Axiom? If so, congratulations! I think there are
> > > > > a number of other people (including Tim Daly :) who would very
> > > > > much like to setup a similar stand alone LatexWiki/Axiom system.
> > > > 
> > > > And me!
> > > > 
> > > > But we really need to have people setting this up in a 
> > chroot jail.  I
> > > > have been reading up on this...we need a script to create 
> > the jail.
> > > > 
> > > > > I promised Tim that I would set something up for this, but I
> > > > > have not yet had the time. If you have some time to write up a
> > > > > short description of how you did it, I think it would be most
> > > > > appreciated.
> > > > 
> > > > I would like to distribute axiom support with LatexWiki.  
> > I have tied my
> > > > version numbers to ZWiki, and they will release 0.35 on 
> > 10/1.  Do you
> > > > think we could add this by then?  (or maybe a bit after 
> > to ensure 0.35
> > > > compatability)
> > > > 
> > > > Bill our darcs repos have diverged, your patches no 
> > longer apply cleanly
> > > > to latexwiki.  I have moved the functions 'runCommand' 
> > and 'log' into
> > > > util.py so that they can be used by axiom/reduce.  There 
> > are a couple
> > > > other conflicts too (I improved plone/stylesheet in 
> > latexwiki.css).  Why
> > > > do you have a font-size +2 in your latexwiki.css?  Will 
> > you have time to
> > > > merge this in the next week or two?
> > > > 
> > > > FYI, I have gotten MathML/LatexWiki working in Plone::
> > > > 
> > > >     http://mcelrath.org/Plone/ITeXTest
> > > > 
> > > > You will need my zwiki patches to do that::
> > > > 
> > > >     http://bob.mcelrath.org/darcs/zwiki
> > > > 
> > > > Hopefully I will get those into ZWiki 0.35 but I haven't 
> > been able to
> > > > get Simon's attention in the last couple of days.  ;)  As 
> > a reminder my
> > > > latexwiki repo is here::
> > > > 
> > > >     http://bob.mcelrath.org/darcs/latexwiki
> > > > 
> > > > > Did you download the binary version of Axiom that failed from
> > > > > debian unstable? If so, we should be sure to let Camm Maguire
> > > > > know since he is the architect of the debian version. What
> > > > > version of GCL are you using for the re-compile? What is the
> > > > > hardware platform that you are using?
> > > > 
> > > > Mine is a debian binary::
> > > > 
> > > >     (0)<mcelrath@moya:~> dpkg -l axiom
> > > >     Desired=Unknown/Install/Remove/Purge/Hold
> > > >     | 
> > Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-
> > installed
> > > >     |/ Err?=(none)/Hold/Reinst-required/X=both-problems 
> > (Status,Err: uppercase=bad)
> > > >     ||/ Name              Version           Description
> > > >     
> > +++-=================-=================-======================
> > ============================
> > > >     ii  axiom             0.20040831-1      A general 
> > purpose computer algebra system: main bi
> > > >     (0)<mcelrath@moya:~> axiom
> > > >     Segmentation fault
> > > > 
> > > > This is the alpha architecture.
> > > > 
> > > > If I understand correctly, GCL is compiled-in?  I do not 
> > have gcl itself
> > > > installed on this machine.

\start
Date: Fri, 1 Oct 2004 11:56:06 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Axiom crashing in Zope-Plone
Cc: Hans Peter Wuermli

Hans,

When you can find some "spare" time, would it be possible for
you to attempt what Camm describes below?

Camm,

I suppose that "setting TERM environment variable to dumb"
must disable GCL's use of readline? If so, since we definitely
don't want readline functionality when AXIOMsys is called
from the MathAction wiki, I can easily set this environment
variable when AXIOMsys is called.

Thanks!

Bill Page.

On Friday, October 01, 2004 11:44 AM you wrote:
> 
> Bill Page writes:
> 
> > Cam,
> > 
> > The original report from Hans:
> > 
> >   
> http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg0
> 0056.html
> > 
> > referred to what later was discovered to be a seg fault
> > (EXITSTATUS:139 from Python 2.2 popen3) generated by Axiom
> > when run as a sub-process (popen3). Hans later reported that
> > the failure occured while running a debian binary version
> > of Axiom on an Intel i386 box.
> > 
> 
> My suspicion lies in python's pipe code, possibly in conjunction with
> GCL readline.  Can a segault be reproduced with axiom intel
> standalone?  Alternatively, can someone please try to reproduce
> setting the TERM environment variable to "dumb"?  Might need to check
> strace -f on the process to make sure Python does not setup the pipe
> environment as a readline capable terminal (e.g. vt100).  If one can
> get to axiom at all over the pipe, try doing )lisp (si::readline-off)
> at the beginning, or putting this into some axiom rc startup file or
> something. 
> 
> Please feel free to report all Debian binary bugs to the Debian BTS
> via 'reportbug'.

\start
Date: 01 Oct 2004 12:02:48 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Axiom crashing in Zope-Plone
Cc: Hans Peter Wuermli

Greetings!

Bill Page writes:

> Hans,
> 
> When you can find some "spare" time, would it be possible for
> you to attempt what Camm describes below?
> 
> Camm,
> 
> I suppose that "setting TERM environment variable to dumb"
> must disable GCL's use of readline? If so, since we definitely
> don't want readline functionality when AXIOMsys is called
> from the MathAction wiki, I can easily set this environment
> variable when AXIOMsys is called.
> 

Yes, readline is automatically disabled if 1) standard input is not a
terminal (via isatty()) or 2) TERM is unset or 3) TERM is "dumb"
(e.g. emacs shell buffer).

Please let me know if problems persist.

Take care,

> Thanks!
> 
> Bill Page.
> 
> On Friday, October 01, 2004 11:44 AM you wrote:
> > 
> > Bill Page writes:
> > 
> > > Cam,
> > > 
> > > The original report from Hans:
> > > 
> > >   
> > http://lists.gnu.org/archive/html/axiom-developer/2004-09/msg0
> > 0056.html
> > > 
> > > referred to what later was discovered to be a seg fault
> > > (EXITSTATUS:139 from Python 2.2 popen3) generated by Axiom
> > > when run as a sub-process (popen3). Hans later reported that
> > > the failure occured while running a debian binary version
> > > of Axiom on an Intel i386 box.
> > > 
> > 
> > My suspicion lies in python's pipe code, possibly in conjunction with
> > GCL readline.  Can a segault be reproduced with axiom intel
> > standalone?  Alternatively, can someone please try to reproduce
> > setting the TERM environment variable to "dumb"?  Might need to check
> > strace -f on the process to make sure Python does not setup the pipe
> > environment as a readline capable terminal (e.g. vt100).  If one can
> > get to axiom at all over the pipe, try doing )lisp (si::readline-off)
> > at the beginning, or putting this into some axiom rc startup file or
> > something. 
> > 
> > Please feel free to report all Debian binary bugs to the Debian BTS
> > via 'reportbug'.

\start
Date: Fri, 1 Oct 2004 12:18:49 -0400
From: Bill Page
To: Martin Rubey
Subject: re: literate programming pamphlet files for MathAction

Martin,

On Friday, October 01, 2004 1:36 PM you wrote:
> 
> Bill Page writes:
>  > I don't understand from what you include below what you
>  > think is "missing". You said: "missing from the pamphlet
>  > file" but everything is generated from the file. Can you
>  > give me an explicit example of something?
> 
> 
> All the code I included does not appear when I look at 
> 
http://page.axiom-developer.org/zope/mathaction/Dhmatrix 


???? I still don't understand. I see all of the code that
you show as output from dvi and more! In your dvi output
for dhmatrix, the routines are shown just as

<rotatex>
<rotatey>
<rotatez>
<scale>
<translate>

which is normal for the noweave output generated from
the dhmatrix.spad.pamphlet file. The mathaction wiki page
on MathAction shows these chunks as expanded to the actual
code and compiled. That is what I meant about whether I
should included the compiled output on the same page or
separately. If it is separately, then the (for example)

  dhmatrix_pamphlet

page would look eactly like (and have essentially the same
internal navigation as) the dvi output. It will be rendered
by the command 'noweave -html -index -filter l2h' command.

There would be a separate page called just 'dhmatrix' that
contains the compiler output (that part shown in green
shading) obtained by applying notangle and AXIOMsys to the
same underlying source code as the 'dhmatrix_pamphlet'.

** Or **

Perhaps this is a way to have only one wiki page say
called just 'dhmatrix' that renders by default via notangle
AXIOMsys and LatexWiki but then an new method called
maybe 'weave' that would be called like this:

  dhmatrix/weave

which would access the noweave rendering.

Bob McElrath: Can you think of some (simple?) way of
achieving both of these renderings with one source file?

\start
Date: Fri, 1 Oct 2004 13:26:24 -0400
From: Bill Page
To: Martin Rubey
Subject: re: literate programming pamphlet files for MathAction

On Friday, October 01, 2004 12:19 PM I wrote:
> ... 
> Perhaps there is a way to have only one wiki page say
> called just 'dhmatrix' that renders by default via notangle
> AXIOMsys and LatexWiki but then an new method called
> maybe 'weave' that would be called like this:
> 
>   dhmatrix/weave
> 
> which would access the noweave rendering.
> 

Ok, I think I understand how to do this. I would turn it
around. 'dhmatrix' would be the only ZWiki page object
and it should have the default rendering of

 LatexWiki+HTML+(Axiom|Reduce ...)+weave

So when you Edit the wiki page 'dhmatrix' you see
pamphlet source code. When you click Save, it is
automatically rendered via the process

  noweave->(Axiom ..)->LatexWiki

Then there will be a *method* called 'tangle' which
could be applied for any LatexWiki page. A url like
this:

  http://.../zope/mathaction/dhmatrix/tangle/axiom

would have the effect of calling notangle to extract and
expand the default chunk <<*>>= from the 'dhmatrix' source
and call axiom via a /begin{axiom} ... /end{axiom} wrapper
and the render the result via LatexWiki. The rendered
result would be saved with the 'dhmatrix' object so that
this is only done once after the source object is edited,
(i.e. there would be two page renderings). In fact this
could be easily extended to

  http://.../zope/mathaction/dhmatrix/tangle/axiom/root

to allow starting the extraction and expansion with
the chunk named <<root>>= And so then there might be
even more than two renderings.

Note: The Axiom compiler output from .../tangle/axiom
would include category, domain and package hyperlink
of the Axiom modules on which it depends. If we arrange
the naming of pamphlet wiki pages properly, this would
mean that these cross-references would link directly by
default to the associated Axiom documentation.

What do you'all think?

\start
Date: Fri, 1 Oct 2004 10:51:52 -0700
From: Bob McElrath
To: Martin Rubey
Subject: re: literate programming pamphlet files for MathAction
Cc: Bill Page


--ibTvN161/egqYuK8

Martin Rubey [Martin Rubey] wrote:
> I am absolutely certain that this kind of documentation will be necessary in
> future to. )show Integer does not suffice, since it contains only the
> modelines. For example:
> 
> prefixRagits :
>    [1] RadixExpansion D2 -> List Integer from RadixExpansion D2 if D2: 
>             INT
> 
>       ++ prefixRagits(rx) returns the non-cyclic part of the ragits
>       ++ of the fractional part of a radix expansion.
>       ++ For example, if \spad{x = 3/28 = 0.10 714285 714285 ...},
>       ++ then \spad{prefixRagits(x)=[1,0]}.

This has been the single most frustrating thing in using axiom for
actual physics for me.  )show and friends give only interfaces, and if
you want to know what something does that's much more difficult.

I very much want to move away from Maple, but the intellectual cost of
learning a system this complex is high, so documentation should always
be readily available.

\start
Date: Fri, 1 Oct 2004 13:52:20 -0400
From: Bill Page
To: Martin Rubey
Subject: re: literate programming pamphlet files for MathAction

Further,

This idea is entirely general since for example in
a bash shell script or Makefile I could write

  wget http://.../pamphlet-file/tangle/code/hello |
    gcc -o hello.exe

to extract the code chunk named 'hello' from the
pamphlet named 'pamphlet-file' and pipe the source
code to the C compiler to produce an executable. Etc.

I think that's nice.

Bill Page.

On Friday, October 01, 2004 1:26 PM I wrote:
> ... 
> Then there will be a *method* called 'tangle' which
> could be applied for any LatexWiki page. A url like
> this:
> 
>  http://.../zope/mathaction/dhmatrix/tangle/axiom
>
> would have the effect of calling notangle to extract and
> expand the default chunk <<*>>= from the 'dhmatrix' source
> and call axiom via a /begin{axiom} ... /end{axiom} wrapper
> and the render the result via LatexWiki. The rendered
> result would be saved with the 'dhmatrix' object so that
> this is only done once after the source object is edited,
> (i.e. there would be two page renderings). In fact this
> could be easily extended to
>
>  http://.../zope/mathaction/dhmatrix/tangle/axiom/root
>
> to allow starting the extraction and expansion with
> the chunk named <<root>>= And so then there might be
> even more than two renderings.

\start
Date: Fri, 1 Oct 2004 11:08:46 -0700
From: Bob McElrath
To: Bill Page
Subject: re: literate programming pamphlet files for MathAction

Bill Page wrote:
> Bob McElrath: Can you think of some (simple?) way of
> achieving both of these renderings with one source file?

I think you answered your own question.  ;)

Just one quibble.  Given a page::

    http://.../zope/mathaction/dhmatrix

you can then access python methods defined by that zope object like::

    http://.../zope/mathaction/dhmatrix/tangle

I don't think you can chain two methods.  But this isn't really

    http://.../zope/mathaction/dhmatrix/tangle_axiom

or::

    http://.../zope/mathaction/dhmatrix/tangle?output=axiom

    http://.../zope/mathaction/dhmatrix/tangle?output=axiom&chunk=root

Let me point out the new plugin system that Simon Michael has
implemented for zwiki.  See plugins/ in the zwiki source tree.  (maybe
only in darcs)  One can create a plugin class with the methods you
desire (tangle, tangle_axiom, etc), that get inherited by ZWikiPage and
thus would work with any ZWiki Page.

Bill Page  wrote:
> On Friday, October 01, 2004 12:19 PM I wrote:
> > ... 
> > Perhaps there is a way to have only one wiki page say
> > called just 'dhmatrix' that renders by default via notangle
> > AXIOMsys and LatexWiki but then an new method called
> > maybe 'weave' that would be called like this:
> > 
> >   dhmatrix/weave
> > 
> > which would access the noweave rendering.
> > 
> 
> Ok, I think I understand how to do this. I would turn it
> around. 'dhmatrix' would be the only ZWiki page object
> and it should have the default rendering of
> 
>  LatexWiki+HTML+(Axiom|Reduce ...)+weave
> 
> So when you Edit the wiki page 'dhmatrix' you see
> pamphlet source code. When you click Save, it is
> automatically rendered via the process
> 
>   noweave->(Axiom ..)->LatexWiki
> 
> Then there will be a *method* called 'tangle' which
> could be applied for any LatexWiki page. A url like
> this:
> 
>   http://.../zope/mathaction/dhmatrix/tangle/axiom
> 
> would have the effect of calling notangle to extract and
> expand the default chunk <<*>>= from the 'dhmatrix' source
> and call axiom via a /begin{axiom} ... /end{axiom} wrapper
> and the render the result via LatexWiki. The rendered
> result would be saved with the 'dhmatrix' object so that
> this is only done once after the source object is edited,
> (i.e. there would be two page renderings). In fact this
> could be easily extended to
> 
>   http://.../zope/mathaction/dhmatrix/tangle/axiom/root
> 
> to allow starting the extraction and expansion with
> the chunk named <<root>>= And so then there might be
> even more than two renderings.
> 
> Note: The Axiom compiler output from .../tangle/axiom
> would include category, domain and package hyperlink
> references to wiki pages based on the Axiom abbreviations
> of the Axiom modules on which it depends. If we arrange
> the naming of pamphlet wiki pages properly, this would
> mean that these cross-references would link directly by
> default to the associated Axiom documentation.
> 
> What do you'all think?

\start
Date: Fri, 1 Oct 2004 20:13:47 +0200
From: Hans Peter Wuermli
To: Camm Maguire
Subject: Re: Axiom crashing in Zope-Plone
Cc: Bill Page, Bob McElrath

Hello

On Friday 01 October 2004 18.02, you wrote:
> > Hans,
> >
> > When you can find some "spare" time, would it be possible for
> > you to attempt what Camm describes below?
> >

Yes, I found some spare time tonight (and hopefully I find some more over the 
weekend) and checked Camm's suggestions:

1) started the axiom commands with ')lisp  (si::readline-off)'
2) started the cmdLine of Popen3 with 'export TERM="dumb"
3) used both changes.

Again, the standalone python code run without errors, whereas the LatexWiki 
page within Zope crashed with WEXITSTATUS=139.

> > > My suspicion lies in python's pipe code, possibly in conjunction with
> > > GCL readline.  Can a segault be reproduced with axiom intel
> > > standalone?  Alternatively, can someone please try to reproduce
> > > setting the TERM environment variable to "dumb"?  Might need to check
> > > strace -f on the process to make sure Python does not setup the pipe
> > > environment as a readline capable terminal (e.g. vt100).  If one can
> > > get to axiom at all over the pipe, try doing )lisp (si::readline-off)
> > > at the beginning, or putting this into some axiom rc startup file or
> > > something.

Using the bit of sparetime I also experimented with spawing a process (like 
Axiom) reading from stdin and writing to stdout. Because running an AxiomWiki 
seems to take ages I wanted to check if one could leave Axiom running as a 
server process, just waiting for axiom commands and returning the answers. My 
simple assumptions about pipes in any case did not prove right, so there 
could be odd ways python handles standard input (e.g. via some terminal 
emulation).

As promised I will now try to install ZWiki, LatexWiki and the axiom patch 
again and will let you know a.s.a.p. (but I work as a slow Swiss and I can 
only offer a tested prescription on a Debian system). I am a bit afraid of 
dealing with the synchronisation that is expected with further versions of 
LatexWiki. We'll see.

\start
Date: Fri, 1 Oct 2004 11:26:35 -0700
From: Bob McElrath
To: Bill Page
Subject: re: literate programming pamphlet files for MathAction
Cc: Yannis Chicha, Jinlong Cai

Bill Page wrote:
> That is of course already a problem when writing Axiom and
> Reduce code that might fail for a variety of reasons. In fact
> it is also true for simple LaTeX coding errors and sometimes
> even unexpected results from "structured text" mode.

I am busy rewriting StructuredText right now.  My goal is to have it
*never* fail.  This is in keeping with the "wiki design
principles":http://c2.com/cgi/wiki?WikiDesignPrinciples .  Right now
StructuredText failes the 'tolerant' criteria.

However, latex/axiom/reduce *cannot* be tolerant since their input must
be precise.  Beyond being syntactically correct it must also be what the
user desired semantically.  Anyway, please take a look at my
WikiDocument attempts (see prev message).  This is the way of the
future.  As you are probably discovering, it can be very difficult, and
sometimes impossible to get two sets of regexes that operate on a
document from clashing.

Still though even with the StructuredText classes (also called STNG),
this is still fundamentally a pile of regexes.  It adds hierarchy.
i.e. in the example [this $x$] I want the link processor [] to get it
first and the latex processor $$ to get it second.  But this is still
not a formally defined grammar.

Python has a module 'Yappy' that is a true C{SLR}, C{LR(1)} and
C{LALR(1)} parser, if it is deemed desirable to formally specify the
syntax of the documents axiom uses.

> > [Bob replied:] 
> > There is also a Zope product called FileSystemSite in which
> > your site is stored in a directory on the filesystem, rather
> > than in the ZODB. Such a directory can simultaneously be a
> > CVS/arch/darcs repository. Presumably it wouldn't be that
> > hard to get Zope/ZWiki/LatexWiki to ignore the CVS directory.
> 
> That is yet another way to go, but have you ever tried
> running ZWiki this way? I suspect that ZWiki might be rather
> tightly integrated with the Zope object model so that this
> is not straight forward. For example a wiki page actually
> contains at least two representations of each page, the
> 'source' and the rendered 'presentation' form. Which of
> these would be stored in the file system. Both?

I have no idea.  Someone will have to try it.

> But there might well be some advantages to this on a large
> shared web site. Zope is notoriously slow at serving web
> pages (not surprizing considering all that it does). Storing
> the rendered pages on the file system would allow greater
> use direct use of the Apache front-end server instead of
> depending on http proxy. Already I do this kind of optimization
> for serving the image files from LatexWiki which are stored
> in the file system and not as Zope objects.

Be careful, down the road I intend to store latexwiki images in the
zodb.  For instance this makes it easier to let the users decide if they
want to see mathml or images.

\start
Date: Fri, 1 Oct 2004 11:36:39 -0700
From: Bob McElrath
To: Martin Rubey
Subject: re: How to use MathAction

Martin Rubey [Martin Rubey] wrote:
>  > but a rather poor platform for casual discussion. For example, one can only
>  > add comments at the bottom, making it difficult to refer to lines or codes
>  > on the page.
> 
> That's only correct if you want to use it via email. I wouldn't suggest
> that. What you can do is: press edit, copy the whole content of the page into
> your favorite text editor, modify it, paste it back.

Please note the "external edit" icon in the upper right corner on the
mathaction wiki.  (the pencil icon)  Configuring a small helper
application with your browser will allow you to automatically open any
wiki page in your favorite editor.

    http://zwiki.org/ExternalEditor

I was just thinking it might be nice to edit axiom/wiki documents with
some of the tex macros I have for vim, which automatically collapse
sections like \begin{axiom}...\end{axiom}.

>  > I don't like text files and much prefer LaTeX to get pdf or dvi output. 
> 
> You can (and should) use LaTeX (where appropriate)!

Note that future plans for latexwiki include a ps/pdf output mode.

Help on this would be appreciated.  I can give pointers.  There's lots
to do.

\start
Date: 01 Oct 2004 14:48:04 -0400
From: Camm Maguire
To: Hans Peter Wuermli
Subject: Re: Axiom crashing in Zope-Plone
Cc: Bill Page, Bob McElrath

Greetings!

Hans Peter Wuermli writes:

> Hello
> 
> On Friday 01 October 2004 18.02, you wrote:
> > > Hans,
> > >
> > > When you can find some "spare" time, would it be possible for
> > > you to attempt what Camm describes below?
> > >
> 
> Yes, I found some spare time tonight (and hopefully I find some more over the 
> weekend) and checked Camm's suggestions:
> 
> 1) started the axiom commands with ')lisp  (si::readline-off)'
> 2) started the cmdLine of Popen3 with 'export TERM="dumb"
> 3) used both changes.
> 
> Again, the standalone python code run without errors, whereas the LatexWiki 
> page within Zope crashed with WEXITSTATUS=139.
> 

This is with the packages Debian binary, right?  In this case, it
would seem that axiom/gcl is likely not implicated, but rather
Zope/LatexWiki.  Please let me know if you uncover evidence to the
contrary. 

Take care,

> > > > My suspicion lies in python's pipe code, possibly in conjunction with
> > > > GCL readline.  Can a segault be reproduced with axiom intel
> > > > standalone?  Alternatively, can someone please try to reproduce
> > > > setting the TERM environment variable to "dumb"?  Might need to check
> > > > strace -f on the process to make sure Python does not setup the pipe
> > > > environment as a readline capable terminal (e.g. vt100).  If one can
> > > > get to axiom at all over the pipe, try doing )lisp (si::readline-off)
> > > > at the beginning, or putting this into some axiom rc startup file or
> > > > something.
> 
> Using the bit of sparetime I also experimented with spawing a process (like 
> Axiom) reading from stdin and writing to stdout. Because running an AxiomWiki 
> seems to take ages I wanted to check if one could leave Axiom running as a 
> server process, just waiting for axiom commands and returning the answers. My 
> simple assumptions about pipes in any case did not prove right, so there 
> could be odd ways python handles standard input (e.g. via some terminal 
> emulation).
> 
> As promised I will now try to install ZWiki, LatexWiki and the axiom patch 
> again and will let you know a.s.a.p. (but I work as a slow Swiss and I can 
> only offer a tested prescription on a Debian system). I am a bit afraid of 
> dealing with the synchronisation that is expected with further versions of 
> LatexWiki. We'll see.

\start
Date: Fri, 01 Oct 2004 21:54:27 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: literate programming pamphlet files for MathAction

Hi Martin,

> For lisp and especially compiler gurus -- Camm, I believe that's
> you... :-) -- a great (non-priority) project might be to make a
> (simple! non-optimizing) lisp implementation of the Aldor compiler
> that could be freely distributed and run within axiom.

I object to that. There should be only one compiler and this should
probably maintained by the Aldor people. The better way (in my eyes)
would be find a way how to distribute the latest Aldor compiler together
with Axiom or to explain clearly how to proceed to install the compiler
afterwards.

> ... a bug can have different origins. Sometimes it is obvious, that
> it is an algebra bug, or a compiler bug, or a lisp bug, but sometimes
> this is not clear at all.

True, but when you want to head for ONE compiler language then I would 
rather move the effort to remove the bugs from the aldor.org compiler 
and not maintaining another program.

> Having different, but semantically -- modulo bugs -- equivalent
> implementations would ease debugging quite a bit, I imagine.

Well, true, but where is the manpower?

> On the other hand, given our limited resources, this seems quite out
> of reach...

\start
Date: Fri, 1 Oct 2004 22:05:41 +0200
From: Hans Peter Wuermli
To: Camm Maguire, Bill Page, Bob McElrath
Subject: Setting up AxiomWiki within Zope

Hi 

This evening I set-up afresh AxiomWiki on my local system (which I describe as 
far as I find it useful at the end).

This was done on 2004-10-1:

1) Download  ZWiki-0.35.0.tgz from http://www.zwiki.org/FrontPage.

2) (I would have downloaded LatexWiki-0.35, if it had been available as Bob 
McElrath tries to keep LatexWiki and ZWiki in sync. Instead I did the 
following:)

cd /home/LatexW
darcs get http://bob.mcelrath.org/darcs/latexwiki

cd /home/AaxiomW
darcs get http://page.axiom-developer.org/repository/latexwiki

cd $ZOPEHOME/lib/python/Products

cp -r /home/LatexW/latexwiki/LatexWiki .
cp -r /home/LatexW/latexwiki/ZWiki .

cp /home/AxiomW/latexwiki/LatexWiki/ReplaceInline* .
cp /home/AxiomW/latexwiki/LatexWiki/*Wrapper.py .
cp /home/AxiomW/latexwiki/LatexWiki/texbreaker* .

(I had to delete ReplaceInlineReduce.py and comment out any line refering to 
Recude in ReplaceInlineLatex.py as I don't have reduce and it does produce an 
error if you leave it.)

3) If necessary, comment out line 24 and 58 in ReplaceInlineLatex.py, both 
referring to Reduce.

4) Edit axiomWrapper.py: on line 85 the string "cmdLine" exports AXIOM. Edit 
it such that it reflects your local Axiom home. In my case:

cd /usr/local/lib/
darcs get http://page.axiom-developer.org/repository/axiom

.... make .... 

In axiomWrapper.py:
cmdLine = 'export AXIOM=/usr/local/lib/axiom/mnt/linux;\
                    export PATH=$AXIOM/bin:$PATH;\
                    AXIOMsys < %s' %(axiomFileName)

5) Run the commands you find in texbreaker.mak. (I had the change the include 
file in the gcc command:

-I/usr/include/python2.3 to -I/usr/include/python2.2)

6) Restart zope: /etc/init.d/zope restart

Now it should all be set up and work.


My system:

I run Debian testing (Sarge) with a kernel-image-2.6.7-1-686 (with mostly the 
latest library versions of everything, i.e. not a totally robust system, but 
perfectly fine for me).

Zope Version 
(Zope 2.6.4 (source release, python 2.1, linux2), python 2.2.3, linux2) 

Python Version 
2.2.3+ (#1, Jun 20 2004, 13:32:48) [GCC 3.3.4 (Debian)] 

System Platform 
linux2 

SOFTWARE_HOME 
/usr/lib/zope/lib/python 

ZOPE_HOME 
/usr/lib/zope 

INSTANCE_HOME 
/var/lib/zope/instance/default 

CLIENT_HOME 
/var/lib/zope/instance/default/var 

\start
Date: Fri, 1 Oct 2004 16:49:51 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: re: literate programming pamphlet files for MathAction

Historically the Aldor compiler was intended to be an updated version
of the spad (lisp) compiler. The spad compiler has equivalent syntax
and semantics (modulo the embedded/standalone issues).

It would be better if I worked out a way to package the aldor compiler
with the distribution and kept that up to date and tested. I'll pursue
this offline and let you know the result.

\start
Date: Fri, 1 Oct 2004 22:19:08 +0200
From: Hans Peter Wuermli
To: Camm Maguire
Subject: Re: Axiom crashing in Zope-Plone

Hi Camm

> > Again, the standalone python code run without errors, whereas the
> > LatexWiki page within Zope crashed with WEXITSTATUS=139.
>
> This is with the packages Debian binary, right?  In this case, it
> would seem that axiom/gcl is likely not implicated, but rather
> Zope/LatexWiki.  Please let me know if you uncover evidence to the
> contrary.

I am unsure. The combination Zope/LatexWiki cannot be the cause, as I produce 
the crashes without using anything from LatexWiki. So it would have to be 
caused by the combination Zope/Axiom. Remember: I create a so called external 
method in zope, which is nothing else than a python program run either within 
Zope or external as a standalone program.

If I am not mistaken, the GCL used in your Debian version is 2.6.4, whereas 
the version I downloaded and compiled uses 2.6.3. Could this be tested? I.e. 
what would I have to do such that my local version uses the latest version of 
GCL? (Checking which versions is available on Debian I see that it is 2.6.5 
or then 2.5; actually, I don't have gcl installed on my system separately.)

\start
Date: Fri, 1 Oct 2004 16:25:06 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Axiom crashing in Zope-Plone
Cc: Hans Peter Wuermli

Camm,

I think the "evidence to the contrary" might be the fact
that the problem goes away when Hans re-builds Axiom from
CVS sources. Doesn't this isolate the problem to the
Debian binary version of Axiom?

The Debian binary version runs stand alone but segfaults
when run from inside Zope (same code used in both cases).
But after recompiling Axiom, the same code again runs
in *both* places. I can not see how this might be a
Zope/LatexWiki problem.

Regards,
Bill Page.

On Friday, October 01, 2004 2:48 PM Camm Maguire wrote:
> ...
> Hans Peter Wuermli writes: 
> > Yes, I found some spare time tonight (and hopefully I find 
> > some more over the weekend) and checked Camm's suggestions:
> > 
> > 1) started the axiom commands with ')lisp  (si::readline-off)'
> > 2) started the cmdLine of Popen3 with 'export TERM="dumb"
> > 3) used both changes.
> > 
> > Again, the standalone python code run without errors, 
> > whereas the LatexWiki page within Zope crashed with
> > WEXITSTATUS=139.
> > 
> 
> This is with the packages Debian binary, right?  In this case,
> it would seem that axiom/gcl is likely not implicated, but
> rather Zope/LatexWiki.  Please let me know if you uncover
> evidence to the contrary. 

\start
Date: Fri, 1 Oct 2004 14:20:54 -0700
From: Bob McElrath
To: Hans Peter Wuermli
Subject: Re: Setting up AxiomWiki within Zope
Cc: Camm Maguire, Bill Page

Excellent, thank you.

I should note that I've been told ZWiki will not support Zope 2.6 for
very much longer.  :(

If you're making a new installation, it's worth your while to use Zope
2.7 and Plone 2.0 (if you want Plone).  I'll try to fix Zope 2.6
incompatibilities in ZWiki when I find them though.

There are debian repositories for both these, but it's not in main
(yet)::

    deb http://nathan.faho.rwth-aachen.de/debian/zope/ ./

the packages are named 'zope2.7' and 'plone'.

I have released LatexWiki 0.35 with some fixes over the previous
version.  (There is one minor fix over the darcs repository you checked
out before 1:45pm PDT 10/1/2004)  I also added a small axiom plug on my
site, and my site is now world-editable.  Feel free to add axiom info if
you are so inclined.

I hope for the next release we can fix these axiom/latexwiki problems
and possibly merge our two development efforts.

Hans Peter Wuermli wrote:
> 
> Hi 
> 
> This evening I set-up afresh AxiomWiki on my local system (which I describe as 
> far as I find it useful at the end).
> 
> This was done on 2004-10-1:
> 
> 1) Download  ZWiki-0.35.0.tgz from http://www.zwiki.org/FrontPage.
> 
> 2) (I would have downloaded LatexWiki-0.35, if it had been available as Bob 
> McElrath tries to keep LatexWiki and ZWiki in sync. Instead I did the 
> following:)
> 
> cd /home/LatexW
> darcs get http://bob.mcelrath.org/darcs/latexwiki
> 
> cd /home/AaxiomW
> darcs get http://page.axiom-developer.org/repository/latexwiki
> 
> cd $ZOPEHOME/lib/python/Products
> 
> cp -r /home/LatexW/latexwiki/LatexWiki .
> cp -r /home/LatexW/latexwiki/ZWiki .
> 
> cp /home/AxiomW/latexwiki/LatexWiki/ReplaceInline* .
> cp /home/AxiomW/latexwiki/LatexWiki/*Wrapper.py .
> cp /home/AxiomW/latexwiki/LatexWiki/texbreaker* .
> 
> (I had to delete ReplaceInlineReduce.py and comment out any line refering to 
> Recude in ReplaceInlineLatex.py as I don't have reduce and it does produce an 
> error if you leave it.)
> 
> 3) If necessary, comment out line 24 and 58 in ReplaceInlineLatex.py, both 
> referring to Reduce.
> 
> 4) Edit axiomWrapper.py: on line 85 the string "cmdLine" exports AXIOM. Edit 
> it such that it reflects your local Axiom home. In my case:
> 
> cd /usr/local/lib/
> darcs get http://page.axiom-developer.org/repository/axiom
> 
> .... make .... 
> 
> In axiomWrapper.py:
> cmdLine = 'export AXIOM=/usr/local/lib/axiom/mnt/linux;\
>                     export PATH=$AXIOM/bin:$PATH;\
>                     AXIOMsys < %s' %(axiomFileName)
> 
> 5) Run the commands you find in texbreaker.mak. (I had the change the include 
> file in the gcc command:
> 
> -I/usr/include/python2.3 to -I/usr/include/python2.2)
> 
> 6) Restart zope: /etc/init.d/zope restart
> 
> Now it should all be set up and work.
> 
> 
> My system:
> 
> I run Debian testing (Sarge) with a kernel-image-2.6.7-1-686 (with mostly the 
> latest library versions of everything, i.e. not a totally robust system, but 
> perfectly fine for me).
> 
> Zope Version 
> (Zope 2.6.4 (source release, python 2.1, linux2), python 2.2.3, linux2) 
> 
> Python Version 
> 2.2.3+ (#1, Jun 20 2004, 13:32:48) [GCC 3.3.4 (Debian)] 
> 
> System Platform 
> linux2 
> 
> SOFTWARE_HOME 
> /usr/lib/zope/lib/python 
> 
> ZOPE_HOME 
> /usr/lib/zope 
> 
> INSTANCE_HOME 
> /var/lib/zope/instance/default 
> 
> CLIENT_HOME 
> /var/lib/zope/instance/default/var 

\start
Date: Fri, 01 Oct 2004 23:50:43 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: literate programming pamphlet files for MathAction

Hello Tim,

Tim Daly wrote:
> re: Why should ++ comments go away?

> Pamphlet files let you use the full power of tex, including hyperlinking
> packages and, now noweb and a browser. Thus we gain 4 benefits. 
>  (a) the world understands tex so no documentation of the tags is needed, 

OK.

>  (b) the mechanism is entirely general so anyone can make their own tags, 

Not always so good. Assume I want to refer in the documentation to the 
name of a function or a variable from some code junk. To me it is 
unclear how I should typeset this. I could use $function()$ or 
$variable$. Or should I use \verb'function()' or perhaps 
\spad{function()} or \axiom{function} or is it better to say 
\alfun{function}? Having a set of canonically predefined tags (latex 
commands) would leave the actual output style to some stylefile. 
Furthermore latex+hyperref (or whatever program) could produce 
hyperlinks if there where predefined tags. But there aren't. (I consider 
\spad and \axiom to be undocumented and therefore not very useful.)

>  (c) less code needs to be maintained, and 
>  (d) it all works with general purpose tools (mathaction, browser, etc).

Well, but I feel the hyperlinking from the program to the documentation 
is gone.

> (With some cleverness we COULD define a function that could allow a 
> program to reference its own pamphlet at runtime. This might be useful)

Yes, maybe this is the way to go.

> Pamphlet files change the emphasis from programming to writing a document.

That is great, but what if you want to write a new domain A which builds 
on some other (already nicely documented) domain B. You have to know 
every function signature that you intend to use from B by heart or to 
read the whole documentation of B again and again to find the right 
place where an appropriate function is defined. I consider this a 
lengthy process. Better would be to have a summary of the domain 
additionally available (of course automatically generated). Well and for 
that I would use ++ or \begin{functiondescription} ... \end{...}.

It is nowhere said that ++ can only contain a limited set of latex 
commands. It depends very much on the program that takes these comments 
and renders some useful format out of them.

> Fourth, you mention that sometimes a programmer just wants the documentation
> of the arguments. There is no reason why we need special syntax for this
> and, as mentioned above, the previous programmers did not provide this.
> The Axiom compiler does extract this type information while compiling. See
> )show Integer
> for an example of the output.

Yes, > I know it all seems like a lot of work but we are at the beginning of
 > the collision of computing with science. If we go back to the last
 > century and look at math proofs from that time they seem like just so
 > much handwaving compared to the standards of proofs today. In 30 years
 > lightly commented source code with ++ and -- will seem unprofessional.
 > Algorithms will be expected to have termination proofs, correctness
 > proofs, examples, test cases, complexity analysis, working source code
 > and a sound basis in theory in order to pass as professional
 > scientific work.
 >
 > All of which is clearly just my opinion on the subject.  But at least
 > this will give you some idea why I believe ++ comments will die.
 >
 > Tim
I get a list of signatures. And how do I interpret this list? I have to 
guess from the function's name what it does.

I say it again. I am not opposing the pamphlet style, but I would like 
to keep ++ as an _additional_ feature.

> Pamphlet files allow tagging of arguments in such a way that we could
> construct automatic hyperlinks for arguments.

Is there an example somewhere?

I dont like the list of hyperlinks below the green area of

http://page.axiom-developer.org/zope/mathaction/Dhmatrix/

very much. In the green area it goes...

R : Join(Field,  TranscendentalFunctionCategory)

Now suppose, I don't know what TranscendentalFunctionCategory is. I 
cannot simply click on it, but must search the appropriate link at the 
bottom. It's a bit inconvenient, but maybe only a question of the right 
program that puts hyperlinks inside the code part. (As far as I know 
actually noweb could do this partly.)

> Fifth, you said "This is NOT true for the Aldor compiler". Currently the
> Aldor compiler will process ++ comments and pass them along... to nothing.

Sad, but true. And AldorDoc (which should do this job) is not much 
progressing at the moment.

> Sixth, you reference the javadoc-like documentation style
> (http://www-sop.inria.fr/cafe/Manuel.Bronstein/libaldor/html/node18.html)

> Pamphlet files can contain this information and it can be parsed out
> either with noweb, tex, l2h, etc. However, I'd expect that the original
> pages in the pamphlet .dvi file can not only contain this information but
> format it in a similar way if you so desire with additional information.

The point is that I don't want to repeat the function signature in the 
documentation. They should be taken from the actual code. I would only 
like to add a short note on the function. Repetition introduces the 
possibility of getting out of sync when changing code or documentation.

> As for hierarchical information the src/algebra/Makefile.pamphlet contains
> the current lattice of types. This information is waiting for someone to
> exploit it.

I know Axiom is a bit different, but for Aldor I would rather just like 
to extract the type lattice from the .al libraries by translating the 
files to the .asy format.

\start
Date: Fri, 1 Oct 2004 18:37:23 -0400
From: Tim Daly
To: Bob McElrath
Subject: re: Setting up AxiomWiki within Zope
Cc: Camm Maguire, Bill Page, Hans Peter Wuermli

Bob,

Can you give me a 3 sentence description of the relationship between
Zwiki, Plone, and Zope? I'm clearly confused about it.

\start
Date: Fri, 1 Oct 2004 20:16:13 -0400
From: Stephen Wilson
To: Ralf Hemmecke
Subject: re: literate programming pamphlet files for MathAction

Ralf,

On Thu, Sep 30, 2004 at 09:29:00PM +0200, Ralf HEMMECKE wrote:
> Please accept my apologies for mixing the names.

Not a problem at all. Indeed, I am happy the aldor mode was mentioned
on this list, as it seems a few more people will be putting it use
now. 

\start
Date: Sat, 02 Oct 2004 00:33:07 -0000
From: Piotr Sawuk
To: list
Subject: problems with compiling newest axiom version

in order to successfully compile this program I needed to do 2 things:

1) I needed to install a new libbfd. but the fact that the cryptic errors
during compilation didn't explicitely point at this problem is either
just a bug in gcl's configure script, or the fault of some incompletent
installation of binutils on my side. either way, it's probably not your
problem and mentioned in the FAQ anyway. luckily I had some recent
binutils-sources lying around...

2) I needed to alter axiom/src/graph/view3D/Makefile.pamphlet since
putting external include-paths before internal ones in the CFLAGS
did cause "bad things" for me -- i.e. I simply put ${CCF} to the end
of the line where CFLAGS got declared. it might be true that the
existance of header.h in /usr/X11/include is an error on my side,
but I guess that global include-paths getting searched before
program-specific ones is a bad practice anyway.

btw, this is already the 2nd program which clashed with my installation
of cern's "root" into /usr/X11R6, I'd probably better move it away...

\start
Date: Fri, 1 Oct 2004 22:36:54 -0400
From: Bill Page
To: Tim Daly
Subject: re: Setting up AxiomWiki within Zope

Tim,

Let me try to do this for you (Bob: Don't let that stop
you from doing it another way or correcting me ... :)

Zope: is an "integrated application development environment"
consisting of a web server (Zserver) and an object-oriented
database (ZODB) based on the idea of persistent objects
and classes. Zope is written in Python and was originally
a commercial product of Zope Corporation before it went
"open source" (It is still a commercial product in the
sense that Zope Corporation continues to make money from
it's earlier effort, albeit in a different way.)

ZWiki and Plone are two of quite a large number of
applications built using Zope. More specifically these
applications are (usually) build according to a "layered"
architecture that takes full advantage of the object-
orientation at a fairly high level (almost everything
is an object or an attribute of an object, including
web pages, images, files, etc.). Each object has associated
"methods" etc.

Plone is a portal application that is built on top of a
layer called the Content Management Framework (CMF).
CMF provide the object model for distributed management
of website contents. CMF is built directly on Zope.

ZWiki fits into the hierarchy roughly at the same layer
as CMF - just above Zope. Both CMF and ZWiki  define
object types that are inherited by Plone.

--------

Now, are you more confused or less? :) Actually, if you
look at some of the correspondence and history of Zope,
you will find that many (most?) people start out being
quite confused and challenged about this approach. Some
people can't stand it and turn to very different tools
which have similar functionality but are more conventional
such as PHP. Other people are more willing to forget a
lot of the things they thought they knew about computer
systems design and start over, learn Zope from the ground
(Python) up. Often the latter people seem to love it so
much they go one to proselytize about it to others.

Cheers,
Bill Page.

> 
> Bob,
> 
> Can you give me a 3 sentence description of the relationship between
> Zwiki, Plone, and Zope? I'm clearly confused about it.

\start
Date: Sat, 02 Oct 2004 03:13:57 -0400
From: William Sit
To: list
Subject: re: literate programming pamphlet files for MathAction

Hi:

This is not a response to any particular message in this thread, but I think
some information is useful about the use of old spad source, in particular, the
++ --comments that have produced a lot of thoughtful commentaries. I am not a
system programmer and so I know almost nothing about *how* this is done, just
what was the use of ++ and some -- lines.

It is a pity that the current Open Axiom does not yet have hyperdoc, which is a
great replacement for )show, and a vast multifacet browser way ahead of its time
(or even by today's standard). I understand that those who only have the Open
Axiom version will not have experience with hyperdoc. However, there is a
chapter (Chapter 14) in the Axiom Book that is downloadable that describes
hyperdoc and certainly in lot more details than I am writing about. Those who
know hyperdoc need read no further.

Using hyperdoc, you can (I mention only those related to documentation):

(0)  read the entire Axiom Book, with several views -- by topics, language,
examples, commands, search -- kind of a precursor to Tim's crystal: under
[reference] of hyperdoc.

(1)  get what is equivalent to )show or )display for any constructor, operation,
or attributes; just type the name into a box. But hyperdoc does a lot more. This
is the [browse] function of hyperdoc. These pages, unlike ")show" the output, is
formatted to fit separately in the hyperdoc window, with a scroll bar, and is
out of way of any Axiom computation you are doing. They are derived from spad
source and in particular, the ++ lines.  Once the name is entered (and you can
fill in actual parameters for constructors after that or leave them as
undefined), you get not only the documentation, but you can see ancestors,
dependents, exports, parents, operations, examples, users, attributes and more.
For operations, you get a list of all operations of a certain domain, and you
can get descriptions, parameters, signatures, origins or filter the list. You
can also get hyperlinks to the source spad file for any of the items. If you
have your own version of a spad file and have compiled it, your version is
immediately available.

(2)  test solve problems in five topics: calculus, matrix, draw, series, solve
-- much like a live web page; each topic provides further menus to do a
particular computation. On each page, there are default examples, so you can
just click [continue], or you can fill in the parameters. Surely, this is only a
very, very, small fraction of the library (and can be extended), because the
intention is introduction to Axiom, under [Basic Commands] of hyperdoc. Under
the [Topics] menu, more advanced mathematical topics are available, including
basic commands for them.

(3)  (if the author of the spad source provided examples for the Axiom Book)
select  live examples from [Examples] menu and choose the domain. For example,
if you choose the domain OrderlyDifferentialPolynomial (Section 9.60 of Axiom
Book), you get a demonstration of ODPOL(FRAC INT). When any of the Axiom
statements is selected (click a downarrow icon next to it) the result is
displayed (even if you did not select the ones above it on which it depends).
But there is more. If you double click on the statement instead, a new Axiom
frame (interpreter window) opens and the statement, and all others on which it
depends, are executed in real time, and you can insert Axiom statements of your
own, to test your understanding of the examples. This frame is totally
independent of any other frame(s) that might be opened -- that is, all its
variables are scoped only for that frame, by perhaps a child process. You can
check the dpolcat.spad to see what is done: look for the -- Examples: lines and
what follows. (Yes, the -- lines, which are used and it's so easy!)

    I believe Bob Sutor designed (or patched in) this syntax when he wrote the
Book so he could simply extract these and put them into both hyperdoc and the
Axiom Book. It's too bad that not all spad source provided these examples (what
Tim may have called "testcase"). I don't know if the full code for hyperdoc is
available as open-source, but if so, the grammar of documentation in spad files
can be extracted, and it would be a big waste to throw it away and not built
upon it.

So I would suggest that reviving hyperdoc should be one of the highest
priorities and after that, add examples and better commentaries to the spad
source. The final design of pamphlet files (at least the code segment portions)
can then be built upon the experience with hyperdoc from more people. Hyperdoc
can then be expanded (more topics are included in basic commands), improved (for
example, display the mathematics contained in the pamphlet/LaTeX source), or
morphed into a browser plug-in, or even a web-based version like that in
MathAction.

\start
Date: Sat, 2 Oct 2004 11:22:41 +0000
From: Martin Rubey
To: Bill Page
Subject: re: literate programming pamphlet files for MathAction

Bill Page writes:
 > Martin,

 > ...
 > the dhmatrix.spad.pamphlet file. The mathaction wiki page
 > on MathAction shows these chunks as expanded to the actual
 > code and compiled. That is what I meant about whether I
 > should included the compiled output on the same page or
 > separately. If it is separately, then the (for example)
 > 
 >   dhmatrix_pamphlet
 > 
 > page would look eactly like (and have essentially the same
 > internal navigation as) the dvi output. 

That's what I'd like to have. If other pages provide the compiler output as
well, ok, but the "dvi-like" output should be the principal page.

\start
Date: Sat, 2 Oct 2004 16:05:36 +0000
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: How to use ALDOR within AXIOM

Dear Ralf,

In fact, "fact" can be compiled using aldor 1.0.2 and axiom libraries: see

http://lists.nongnu.org/archive/html/axiom-mail/2004-09/msg00035.html

(this mail should really have gone to axiom-developer, sorry.)

Unfurtunately, I did not yet succeed with domains or packages. Maybe you do :-)

\start
Date: Sat, 02 Oct 2004 21:18:16 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: How to use ALDOR within AXIOM

Hi Martin,

I replied to exactly that message. I just wanted to document how to put 
the compiler into the right place.

And as you see from my message. There is a problem (at least on my 
site). How did you compile the file (which I called ff.as)?

Simply, saying )compile ff.as within axiom did not work in my case.
So you must have a slightly different setup.

Ralf

Martin Rubey wrote:
> Dear Ralf,
> 
> In fact, "fact" can be compiled using aldor 1.0.2 and axiom libraries: see
> 
> http://lists.nongnu.org/archive/html/axiom-mail/2004-09/msg00035.html
> 
> (this mail should really have gone to axiom-developer, sorry.)
> 
> Unfurtunately, I did not yet succeed with domains or packages. Maybe you do :-)

\start
Date: Sat, 2 Oct 2004 13:11:05 -0700
From: Bob McElrath
To: Tim Daly, Bill Page
Subject: re: Setting up AxiomWiki within Zope
Cc: Camm Maguire, Hans Peter Wuermli

I'll try to stick to 3 sentences.  ;)

Zope is a pile of python code that is a web server and set of classes
for manipulating web-data stored in its object-oriented database via
what one could think of as a merging of server-side scripting and object
orientation.  Plone is a very pretty and popular "portal" application
built on top of Zope that allows high-level control like multiple users,
owners, access rights, publication rules, and web-based site management.
ZWiki is a powerful wiki implementation that allows several forms of
input type (StructuredText, WikiWikiWeb, MoinMoin, and now Latex) and
because it is built on Zope it is more powerful but not as simple as the
original Wiki idea.

I'll add an answer to one more question you didn't ask directly: If
you're not familiar with the wiki concept, it is intended to be editable
by anyone, simple enough that when anyone runs across it they can
contribute meaningfully by creating content or organization, the pages
themselves have a simple syntax that resembles the web-page output, and
pages are automatically interlinked via the use of camel-case
noun-phrase WikiWord .  This openness and chaos counter-intuitively
*does* result in organization, widespread contribution, and high-quality
content.  In some sense it is the opensource philosophy applied to
documents.

    http://wiki.org/wiki.cgi?WhatIsWiki
    http://c2.com/cgi/wiki?WikiDesignPrinciples

And now I've gotten beyond 3 sentences and am just rambling.  Bill and I
seem to be good at this.  So let's see how many foreign concepts we've
piled on:

    Object-Oriented
    Wiki
    Literate Programming

Not to mention LaTeX, Computer Algebra, Open Source, Zope, ZWiki, Plone.
I just hope the set of concepts most people will have to figure out
isn't so large that this project will have difficulty attracting
contributors.  Your early confusion is a bad sign...  I think I've got
them all mostly figured out except "literate programming".

Wiki's generally have a good number of "curious" edits...people that
come along and think "can I really edit this?"  "What happens if I do?"
and this is to be encouraged because it then leads to more interest...
Pages must also be simple enough that newbies can figure out what it is
when they hit "edit".  The previous discussion of literate
programming/++ comments and document sections...results in a very
complex, non-intuitive document to a newcomer...

Since this Axiom wiki is destined to be relatively complex, a good start
would be to add a simple set of instructions to the editform.

Tim Daly wrote:
> Bob,
> 
> Can you give me a 3 sentence description of the relationship between
> Zwiki, Plone, and Zope? I'm clearly confused about it.

Bill Page [Bill Page] wrote:
> Tim,
> 
> Let me try to do this for you (Bob: Don't let that stop
> you from doing it another way or correcting me ... :)

\start
Date: Sat, 02 Oct 2004 17:59:11 -0400
From: William Sit
To: Martin Rubey
Subject: [Fwd: Integrating UTS] Bug #10350

Hi Martin:

I don't know if you automatically get comments to your bug posts. So I am
forwarding this (slightly edited from the posted version: I can't re-edit what I
posted) to you. I want also to add that EXPR INT is used within UTS rather than
FRAC POLY INT is probably because the coefficients of the Taylor series usually
involve factorials (I guess, hidden in Stream EXPR INT).

William

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

bug #10350 overview: integrating UTS

Neither of these is a bug. In the first one, Axiom coerced 1/x into FRAC POLY
INT correctly: the only / operation available in UTS is one induced from the
coefficient domain, which requires the denominator to be in the coefficient
domain, and the division is done termwise to the coefficients of the series. So
1/x ends up in FRAC POLY INT. Note that to obtain a Taylor series at x = 0 is
mathematically is wrong, since 1/x is not defined at x=0. Also the way to obtain
a Taylor series is taylor(func, x=a). If you do integrate(taylor(1/x,x=1),x),
that would cause no problems. Note that the domain of this command is UTS(EXPR
INT, x,1), so such towers are valid and necessary in Axiom. Note also there are
only two exported [coerce] in UTS and they do NOT apply to 1/x.  The x in UTS is
like the x in UP and is different from the x in FRAC POLY INT. The
representation is Stream Coef (no variable specified because it is univariate).

For the same reason, in the second command, 1/y is correctly coerced into FRAC
POLY INT. However, in UTS(*,x,*), the only integrations allowed are with respect
to x. If you want to do integration in FRAC POLY INT, then you should do so
without coercing 1/y into UTS.

So your examples do not illustrate the problem about mixed up variables. In
fact, they support use of towers like UTS(EXPR INT, x, a).

\start
Date: Sun, 3 Oct 2004 00:16:35 -0400
From: Bill Page
To: Bob McElrath
Subject: foreign concepts

On Saturday, October 02, 2004 4:11 PM Bob McElrath wrote: 
> ... 
> And now I've gotten beyond 3 sentences and am just rambling.  
> Bill and I seem to be good at this.

Rambling on is much easier than programming ...  :} :} :}

> So let's see how many foreign concepts we've piled on:
> 
>     Object-Oriented
>     Wiki
>     Literate Programming
> 
> Not to mention LaTeX, Computer Algebra, Open Source, Zope, 
> ZWiki, Plone. I just hope the set of concepts most people
> will have to figure out isn't so large that this project
> will have difficulty attracting contributors.

Bob, I think you are absolutely right to be concerned about
this. It probably is too complex and it probably is already
having difficulty attracting contributors. I really don't
know what to expect.

The problem is, even the simplest version of what I (we?)
would like to do with all this seems to be too complex -
just Zope + LatexWiki + Axiom. In fact, surely some might
claim that LaTeX is too complex, doing algebra by computer
is too complex, wiki-based collaboration is too complex ...
even individually.

> Your early confusion is a bad sign...  I think I've got
> them all mostly figured out except "literate programming".

No doubt there could be a mix of similar admissions by
people reading this: "I think I know enough about 'x' and
'z' but what is 'y'? Actually this is not such a bad state
to be in and maybe a good reason to be hanging out here.

In my case I certainly might say: I think I've got them
all mostly figured out except "types in Axiom". :)

> 
> Wiki's generally have a good number of "curious" edits...
> people that come along and think "can I really edit this?"
> "What happens if I do?" and this is to be encouraged because
> it then leads to more interest...

Yes, again I agree completely. So far MathAction has only had
what I think is a rather small number of "curiosity edits" in
spite of being fully open. To really know for sure I guess
would might have to take a look at the web logs and set how
the ratio of 'page views' to 'page edits' is compared to other
wiki.

But I have made only limited attempts, mostly indirect, to
advertise MathAction. I am open to suggestions as to how
best to approach this, if at all.

More broadly speaking, I think the Axiom project as a whole
could use more PR. I think there are some quickly evolving
ways to do this on the Internet ranging from being mentioned
in popular blogs to an article in a part-paper / part-electronic
trade magazine. But someone has to step up to the task of
preparing the equivalent of "press notices" etc. We might
worry that "we are not ready yet" for such publication, but
on the other hand one of the reasons we are not ready yet
could well be *because* of the lack of publication.

One of the reasons for my reacting quickly to the possibility
of adding Reduce to MathAction was the thought that sharing
the available audience might be beneficial to both. Of course,
as we say on the FrontPage of MathAction this potentially
extends to other computer algebra systems as well. I have
not seen many comments pro or con about this strategy.

> Pages must also be simple enough that newbies can figure
> out what it is when they hit "edit".

You are right to imply that MathAction does not meet the
usual wiki design goals very well in this respect. But I
think it is first necessary to define what we consider
the target audience for this system to be. For example,
if the result of clicking "edit" and seeing a LaTeX
format-like input file would be interpreted as too complex,
then I am inclined to think that perhaps we have set the
bar a little too low to start with. But I am quite open
to other opinions on this.

> The previous discussion of literate programming/++
> comments and document sections... results in a very
> complex, non-intuitive document to a newcomer...

That is true, however even the fill-in-the-box-and-click-
save" comment box at the bottom of each page seems (so far)
to be little used. Therefore I do think that the main
problem so far is that the audience is just too small. I am
quite reluctant to believe that the underlying complexity
is so obvious to first come page viewers that it prevents
them from even commenting. :(

> 
> Since this Axiom wiki is destined to be relatively complex,
> a good start would be to add a simple set of instructions
> to the editform.

This a good suggestion. We already have a "For editing help,
see HelpPage. But I presume you mean something a little more
"in your face"?

BTW, has anyone thought of providing a settable user
preference that might allow one to select the amount of
help and other verbosity that one might want to see, e.g.
"I'm an expert, don't bother me with that stuff", "I
still need a little help", "I am a novice user who needs
some serious hand holding", etc.

--------

Ok, back to work. Where did I put that Python code that
I was just working on ... 

\start
Date: Sun, 3 Oct 2004 00:59:09 -0400
From: Bill Page
To: William Sit
Subject: re: literate programming pamphlet files for MathAction

William,

I greatly appreciate your discussion of hyperdoc. I think you are
quite right to observe that open axiom is at a serious disadvantage
because of the lack of this part of the former commercial product.

On Saturday, October 02, 2004 3:14 AM William Sit wrote:
> 
> ... 
> 
>     I believe Bob Sutor designed (or patched in) this syntax 
> when he wrote the Book so he could simply extract these and
> put them into both hyperdoc and the Axiom Book. It's too bad
> that not all spad source provided these examples (what
> Tim may have called "testcase"). I don't know if the full 
> code for hyperdoc is available as open-source, but if so,
> the grammar of documentation in spad files can be extracted,
> and it would be a big waste to throw it away and not built
> upon it.

Yes I think the full code for hyperdoc is (or will be) available
as open source but it has not yet been ported to use a modern
graphical user interface. That is a big job even for someone
fully familiar with gui programming.

We did have some previous discussion of this. For references
see:

http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=hyperdoc&submit==
Search
%21&idxname=axiom-developer&max=10&result=normal&sort=score

In particular see

http://lists.gnu.org/archive/html/axiom-developer/2003-07/msg00068.html

for much of that documentation.

> 
> So I would suggest that reviving hyperdoc should be one of the
> highest priorities and after that, add examples and better 
> commentaries to the spad source. The final design of pamphlet
> files (at least the code segment portions) can then be built upon
> the experience with hyperdoc from more people. Hyperdoc can then
> be expanded (more topics are included in basic commands), improved
> (for example, display the mathematics contained in the pamphlet/
> LaTeX source), or morphed into a browser plug-in, or even a web-based
> version like that in MathAction.
>

The pamphlet files now contain all of the spad source code (including
all comments). Editing the commentaries for xxx.spad now means editing
the associated xxx.spad.pamphlet file. The code part of these files
is automatically extracted and used during the Axiom build process.

I notice that in

http://lists.gnu.org/archive/html/axiom-developer/2003-10/msg00071.html

Mike Dewar wrote:

> The only problem I can envisage is that without sman you cannot
> use the unix graphics or browser (hyperdoc will work on its own
> provided it doesn't need to communicate with the running Axiom
> interpreter).  For our own TeX-based interface on Windows we
> dispensed with sman completely and had everything running
> smoothly through TechExplorer except for the graphics which
> needed an external program to display (SceneViewer, an OpenGL
> renderer which we licensed from Template Graphics Software).

Since the functionality of TechExplorer is not so different from
what is possible under LatexWiki, Mike's comment makes me feel
optimistic that it would be possible to implement a large part
of hyperdoc in MathAction.

\start
Date: Sun, 3 Oct 2004 10:03:47 +0000
From: Martin Rubey
To: Bill Page
Subject: Re: foreign concepts

Dear Bill,

first of all: you are doing a wonderful job.

second: I also thought about advertising axiom, BUT, from some experience I had
with close collegs, I am absolutely sure that the following things should be
done before:

* The known math-bugs should be corrected or at least workarounds provided.

  We are in pretty good shape here. From those bugs I *know*, the following two
  are the only ones I'd consider serious: #9217 and #10530. However, there are
  workarounds for both, so I wouldn't consider them as a show stopper.

* editing pamphlets via MathAction should work.

  It seems that we are in good shape here, too. (I think this is a great
  feature)

* Aldor should work as compiler for Axiom

  Rationale: We could attract (and join) the Aldor community here. Furthermore,
  I think that people would gain confidence, since Aldor is probably considered
  more stable than spad.

  Camm, if you are reading this, maybe you can help?

* Windows port.

  Don't know anything about this.

I think we could advertise in the following communities:

* Math and Computeralgebra (via PlanetMath, newsgroups, special math portals I
  don't know by heart, groups like the RISC in Linz)

* Lisp (a CMUCL/SBCL port would be nice. I think some work has been done here
  already)

* LateX and TeXmacs (why not. MathAction and the pamphlet project is related to
  LaTeX)

* emacs. Yes, I think we should make as much noise as possible.

* MuPAD-combinat. Ask them for cooperation, I know that some of them are
  interested.

* Maxima

 > More broadly speaking, I think the Axiom project as a whole
 > could use more PR. I think there are some quickly evolving
 > ways to do this on the Internet ranging from being mentioned
 > in popular blogs to an article in a part-paper / part-electronic
 > trade magazine. But someone has to step up to the task of
 > preparing the equivalent of "press notices" etc. We might
 > worry that "we are not ready yet" for such publication, but
 > on the other hand one of the reasons we are not ready yet
 > could well be *because* of the lack of publication.
 > 
 > One of the reasons for my reacting quickly to the possibility
 > of adding Reduce to MathAction was the thought that sharing
 > the available audience might be beneficial to both. Of course,
 > as we say on the FrontPage of MathAction this potentially
 > extends to other computer algebra systems as well. I have
 > not seen many comments pro or con about this strategy.

I think it was *very* clever. I think it would be clever to add Maxima, too,
But one thing after the other.

Thanks again,

\start
Date: Sun, 03 Oct 2004 10:20:54 -0400
From: William Sit
To: Bill Page
Subject: re: literate programming pamphlet files for MathAction

Dear Bill:

Thanks for taking the time to send me links to discussion on hyperdoc.
Unfortunately, 

(1) The search page produce no document:

http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=hyperdoc&submit=Search%21&idxname=axiom-developer&max=10&result=normal&sort=score

Search String: hyperdoc   [How to search]

Results:

No document matching your query.

Do I have to login in?

(2) I don't follow this document at all (lack of tex and unix expertise):

http://lists.gnu.org/archive/html/axiom-developer/2003-07/msg00068.html

So I don't think I will be able to do much in terms of contributing to this.

> I notice that in
> 
> http://lists.gnu.org/archive/html/axiom-developer/2003-10/msg00071.html
> 
> Mike Dewar wrote:
> 
> > The only problem I can envisage is that without sman you cannot
> > use the unix graphics or browser (hyperdoc will work on its own
> > provided it doesn't need to communicate with the running Axiom
> > interpreter).  For our own TeX-based interface on Windows we
> > dispensed with sman completely and had everything running
> > smoothly through TechExplorer except for the graphics which
> > needed an external program to display (SceneViewer, an OpenGL
> > renderer which we licensed from Template Graphics Software).
> 
> Since the functionality of TechExplorer is not so different from
> what is possible under LatexWiki, Mike's comment makes me feel
> optimistic that it would be possible to implement a large part
> of hyperdoc in MathAction.

Does that mean sman is not open source? I know that hyperdoc will interact with
the interpreter when one enters the actual parameters to a constructor while
browsing in hyperdoc. In fact, sometimes the interpreter will give an error

I also think that hyperdoc has a lot more functionality than TechExplorer
offers. It is true that hyperdoc does not give pretty font output (especially
math), but I'll pass over beauty for utility anytime. Formatting is a very
painstaking job and difficult to do it right (even when done manually and
interactively). It is great that you and so many others devoted so much time to
improve Open Axiom.

\start
Date: Sun, 3 Oct 2004 10:12:38 -0700
From: Bob McElrath
To: Martin Rubey
Subject: Re: foreign concepts
Cc: Bill Page

Martin Rubey [Martin Rubey] wrote:
> Dear Bill,
> 
> first of all: you are doing a wonderful job.
> 
> second: I also thought about advertising axiom, BUT, from some experience I had
> with close collegs, I am absolutely sure that the following things should be
> done before:

[...list of good things to do...]

Recall that this is an open source project.  We are all working in our
spare time.  If we define a set of deliverables that we deem "important"
before outsiders start flooding in, they may very well never get done.

It is very tempting to do this.  We all want the stuff we're working on
to be perfect before we show other people.  However, this attitude is a
hinderance in an open source project.

All that is required for rapid evolution is a *working* codebase.  We
can afford to attract newcomers to an unfinished project.  As long as it
*runs* (with bugs), newcomers can run into those bugs and will be
motivated to try and fix them.  So, make sure that each release
compiles, runs, and passes test cases (same for MathAction) and the
project will grow.

Release early, release often.

Given the nature of axiom, perhaps it we could put warnings in the code
that would be printed to the user in cases where axiom is returning
known-wrong results.  I don't know the difficulty of this suggestion.
Comments?

\start
Date: Sun, 3 Oct 2004 13:33:48 -0400
From: Bill Page
To: William Sit
Subject: re: literate programming pamphlet files for MathAction

On Sunday, October 03, 2004 10:21 AM William Sit wrote: 
> ...
> Unfortunately, 
> 
> (1) The search page produce no document:
> 
http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=hyperdoc
&submit=Search%21&idxname=axiom-developer&max=10&result=normal
&sort=score
> 
> Search String: hyperdoc   [How to search]
> 
> Results:
> References: [ (can't open the index) ] 
> 
> No document matching your query.
> 
> Do I have to login in?

No you don't have to log in. But do be sure that you use the
full url. It should start with http:// and end with &sort=score
If you are using an email program that allows you to just "click
the link" perhaps it was split across two or more lines - this
happens in a lot of email packages with plain ascii messages
and long urls.

The full url works fine for me, but I get exactly the message you
show if I use a url that (incorrectly) ends at query=hyperdoc

\start
Date: Sun, 03 Oct 2004 17:06:49 -0400
From: William Sit
To: Bill Page
Subject: re: literate programming pamphlet files for MathAction

Hi Bill;

OK, thanks. It works now. I was "fooled" by the Undefined Archive Search page:
it is not a 404, but a genuine, workable page with search buttons, etc (when I
looked at the URL *refreshed* by the site, it begins and ends correctly)! So I
typed in the keyword and chose parameters and the URL string looks fine --
except that in the URL, the idxname was replaced by "undefined" instead of
"axiom-developer".  I think the site should return a URL not found rather than a
working page. Or, at the very least, the "link" to "Undefined Archive" should
give an appropriate message, or that page should give a choice of idxnames.

Will read these more fully when I can get around to them. After sampling a few
old messages, I do recall these discussions (I have been reading roughly 90% of
the discussions, though some more carefully than others).

William


Bill Page wrote:
> 
> On Sunday, October 03, 2004 10:21 AM William Sit wrote:
> > ...
> > Unfortunately,
> >
> > (1) The search page produce no document:
> >
> http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=hyperdoc
> &submit=Search%21&idxname=axiom-developer&max=10&result=normal
> &sort=score
> >
> > Search String: hyperdoc   [How to search]
> >
> > Results:
> > References: [ (can't open the index) ]
> >
> > No document matching your query.
> >
> > Do I have to login in?
> 
> No you don't have to log in. But do be sure that you use the
> full url. It should start with http:// and end with &sort=score
> If you are using an email program that allows you to just "click
> the link" perhaps it was split across two or more lines - this
> happens in a lot of email packages with plain ascii messages
> and long urls.
> 
> The full url works fine for me, but I get exactly the message you
> show if I use a url that (incorrectly) ends at query=hyperdoc

\start
Date: Sun, 3 Oct 2004 21:18:25 -0400
From: Bill Page
To: William Sit
Subject: re: literate programming pamphlet files for MathAction

On Sunday, October 03, 2004 10:21 AM William Sit wrote:
> ... 
> Does that mean sman is not open source?

sman is (or will be) open source but as far as I know it
has not yet been fully re-integrated. I believe that sman
is necessary to manage the communication between axiom
and auxillary programs like graphics and hyperdoc. My
limited understanding is that to get this all to work
requires the solution of some compatibility problems with
how network sockets work with GCL. Unfortunately Tim Daly
seems to be the only open axiom developer at this time
with the skills needed to solve this problem - and he is
in rather short supply... :(

> ...
> I also think that hyperdoc has a lot more functionality
> than TechExplorer offers.

Can you give some examples of such functionality?

\start
Date: Sun, 3 Oct 2004 22:07:17 -0400
From: Tim Daly
To: Bill Page
Subject: re: literate programming pamphlet files for MathAction

>sman is (or will be) open source but as far as I know it
>has not yet been fully re-integrated. 

sman has been converted to pamphlet format but does not yet run.
it's the next part of axiom to be released. it is necessary to 
manage other pieces such as the graphics and hyperdoc processes.

\start
Date: Sun, 03 Oct 2004 22:49:04 -0400
From: William Sit
To: Bill Page
Subject: re: literate programming pamphlet files for MathAction

Bill Page wrote:
> 
> On Sunday, October 03, 2004 10:21 AM William Sit wrote:
> > I also think that hyperdoc has a lot more functionality
> > than TechExplorer offers.
> 
> Can you give some examples of such functionality?

Well, no, if you meant have I made a comparison study. Also, I was only
referring to the TechExplorer browser plug-in and I should withdraw that general
comment. Right now, that is only an impression based on limited exposure to
TechExplorer.

\start
Date: Mon, 04 Oct 2004 09:25:09 +0200
From: Ralf Hemmecke
To: list
Subject: Colored/shaded code parts in dvi

Hello,

Somebody interested in the following style code?

It redefines the \nwbegincode and \nwendcode commands of noweb.sty to
achieve shaded code areas in the dvi output.

There is not need to change anything in the .nw/.pamphlet file.

The 'framed' package seems to be a standard package in the latex
distribution.

But be warned, not every dvi viewer is able to handle colors.

For me it works with

home> kdvi --version
Qt: 3.3.3
KDE: 3.2.3
KViewShell: 0.2

and does not work with

home> xdvi --version
xdvik version 22.40v
Copyright (C) 1990-2002 Paul Vojta and others.


Just put the files below into some directory, go there and say

noweave -n file.nw > file.nw.tex
latex wrapper.tex

Ralf Hemmecke


%%-- BEGIN wrapper.tex -- %%
\documentclass{article}

\usepackage{noweb}

\usepackage{color}
\usepackage{framed}
\definecolor{shadecolor}{rgb}{0.8,0.8,0.8}
\let\rhxnwbegincode\nwbegincode
\let\rhxnwendcode\nwendcode
\def\nwbegincode#1{\begin{shaded}\rhxnwbegincode{#1}}
\def\nwendcode#1{\rhxnwendcode{}\end{shaded}}

\begin{document}
\input{file.nw}
\end{document}
%%-- END wrapper.tex -- %%




%%-- BEGIN file.nw -- %%
So let us first define the first code part.
<<Code 1>>=
one one
one
@ %def one

And now the second code part.

<<Code 2>>=
two one two
@

Putting everything together...
<<*>>=
<<Code 1>>
<<Code 2>>
@
%%-- END file.nw -- %%

\start
Date: Mon, 04 Oct 2004 09:25:21 +0200
From: Ralf Hemmecke
To: list
Subject: Shaded code areas in html

One can achieve colored code areas in the html output of noweb by
sneaking some style code into the generated .html file.

Noweb produces the code area set in <pre> ... </pre>, so adding

<style type="text/css">
pre { background : lightgray }
</style>

between <head> ... </head> would achieve this.

Or put it into

http://page.axiom-developer.org/zope/mathaction/FrontPage/stylesheet

as a default for <pre>.

Unfortunately, the above CSS code modifies ALL <pre> environments. That 
may be undesirable.

\start
Date: Mon, 4 Oct 2004 10:14:00 +0000
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: How to use ALDOR within AXIOM

Ralf HEMMECKE writes:
 > And as you see from my message. There is a problem (at least on my 
 > site). How did you compile the file (which I called ff.as)?
 > 
 > Simply, saying )compile ff.as within axiom did not work in my case.
 > So you must have a slightly different setup.

Sorry, I should have quoted

http://lists.nongnu.org/archive/html/axiom-mail/2004-09/msg00013.html

as well:


aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y
$AXIOMSRC/src/share/algebra fact.as

where $AXIOMSRC/src/share/algebra should be the directory that contains
libaxiom.al

\start
Date: Mon, 4 Oct 2004 10:37:59 +0000
From: Martin Rubey
To: Bob McElrath
Subject: Re: Axiom release

Dear Bob, dear all,

Bob McElrath writes:
 > Martin Rubey [Martin Rubey] wrote:

 > > second: I also thought about advertising axiom, BUT, from some experience I had
 > > with close collegs, I am absolutely sure that the following things should be
 > > done before:
 > 
 > [...list of good things to do...]
 > 
 > Recall that this is an open source project.  We are all working in our spare
 > time.  If we define a set of deliverables that we deem "important" before
 > outsiders start flooding in, they may very well never get done.

You are quite right. That's why I tried to be modest. (I failed, it seems?)

The reason I put together this list is that I'm afraid of the following:

* we attract a lot of people, among them many professional researchers, those
  who *I* want to attract most.

* they try it out.

* they find: hey, this could be nice, but in the current state, its just
  unusable for my research, because ... (insert good reason here)

* they never look at it again.

Note that I'm talking mainly about professional researchers.  From my
experience with collegues in combinatorics, I'm confident (unfortunately) that
this would happen.

Regarding my scientific community, bugs #9217 and #10530 are most important. I
don't know about the others. If these two are well documented, I think they are
not such a big problem. In fact, if I manage to release my guessing package at
roughly the same time, I'd probably attract quite some interest. This should be
doable before next monday. 

So, probably you are quite right. 

Tim, do you know about the current state of affairs of the items on

http://page.axiom-developer.org/zope/mathaction/TodoList

?

Can we merge the patches submitted to

http://savannah.nongnu.org/patch/?group=axiom

and do a first release?

Note that I do not have the right to change the priority of a bug.

\start
Date: Mon, 4 Oct 2004 10:52:09 +0000
From: Martin Rubey
To: list
Subject: Re: Axiom release

Dear Axiom Community,

I extend the to-do list on MathAction by some further "nice to have" items and
a list of cummunities to inform of a first release.

Maybe somebody could extend the "phycisians" point!

Also, maybe you know a group with some special interest that might be served by
Axiom or MathAction.

Please edit!

\start
Date: Mon, 4 Oct 2004 10:40:32 +0100
From: Mike Dewar
To: William Sit
Subject: re: literate programming pamphlet files for MathAction
Cc: Bill Page

On Sun, Oct 03, 2004 at 10:20:54AM -0400, William Sit wrote:
<snip>
> I also think that hyperdoc has a lot more functionality than TechExplorer
> offers. It is true that hyperdoc does not give pretty font output (especially
> math), but I'll pass over beauty for utility anytime. Formatting is a very
> painstaking job and difficult to do it right (even when done manually and
> interactively). It is great that you and so many others devoted so much time to
> improve Open Axiom.

Actually there isn't a single thing that you could do in HyperDoc that
you couldn't do in our TechExplorer-based Windows interface, and in
practice the latter was much more natural to work with because it was
more closely integrated into the standard Axiom user-interface.

To clarify, there are two parts of HyperDoc.  The first is a set of
static pages (such as the Axiom book) which are indexed in different
ways.  In some cases links are embedded to allow an Axiom interpreter
frame to be spawned and commands executed in it (either with fixed data
or with data entered via a form-style interface) but that's really the
limit of the dynamic behaviour.

The second is the browser which is driven from the Axiom databases and
generates pages dynamically.  This means that if you add your own code
or change existing code in an Axiom session then the browser view will
reflect this.  You can inspect the exports of a particular type, browse
through its inheritance structure, find all domains which belong to a
particular category ...  Quite honestly I'm amazed (and impressed!) that
anybody can use Axiom seriously without the browser!

When we moved to CCL and ported Axiom to Windows we had to completely
re-write the browser code because it was entirely unix-specific.  This
coincided with a re-design of the databases to make them more compact
and faster to access (a lot of this work was actually done by IBM, and
particularly by the late Dick Jenks).  Unfortunately part of that work
included adding a "grep" function to CCL, so unless that code is ported
to GCL you'll have problems getting the existing browser to work in
OpenAxiom.

As far as user interfaces go, under Unix we stuck with the X11-based
HyperDoc, but under Windows we used TechExplorer.  The static pages
described above work without Axiom being present in both cases (although
obviously the dynamic bits won't work).  The browser requires Axiom to
be present, and on Unix this implies that sman is available.

Personally I'd have thought that you could adapt the TechExplorer
browser code to work with either the TeXmacs or Mathaction interfaces
since in principle they're all very similar.  You'll need to solve the
"grepping with GCL" issue first though.

\start
Date: Mon, 4 Oct 2004 15:50:12 -0400 
From: Bill Page
To: Mike Dewar
Subject: re: literate programming pamphlet files for MathAction

On Monday, October 04, 2004 5:41 AM Mike Dewar wrote:
> ... 
> Personally I'd have thought that you could adapt the
> TechExplorer browser code to work with either the TeXmacs
> or Mathaction interfaces since in principle they're all
> very similar.  You'll need to solve the "grepping with GCL"
> issue first though.

Yes, that was exactly my thought and I would like to try
to get a start on it, having worked with both the TeXmacs
and MathAction interfaces. However right now I feel a distinct
lack of documentation on how the browser code works, combined
with the lack of working example code, is going to make this
very difficult (for me, at least).

\start
Date: Tue, 5 Oct 2004 16:35:49 -0400 
From: Bill Page
To: list
Subject: GCL on Zaurus Debian - segmentation violation
Cc: Camm Maguire

Camm,

Do you know of any successful reports of GCL on Debian Arm,
in particular with Debian on Zaurus?

Recently I have managed to install native debian on the
Zaurus SL-6000. Following the recipes at

  http://pocketworkstation.org/ 

and 

 
http://www.zaurususergroup.com/modules.php?op=modload&name=phpWiki&file=inde
x&pagename=Debian%20on%20the%20Zaurus! 

Debian seems to run great including apt-get etc. although
I do have a problem with the X-windows Fbvnc thing. See

  http://externe.net/zaurus/forum/viewtopic.php?t=1473

Of course the first thing I though of after getting apt-get
running was to install axiom. This went thru fine (takes
a fairly long time - about 2 hours) and seems to complete
normally. BUT when I tried to start axiom it aborted immediately
with a "Segmentation violation". Most other Debian arm
applications however seem to run fine. So I thought I would
try gcl itself. After a little rearranging of the limited
space on the Zaurus SD card, I managed to apt-get install
gcl. But :( it also seg faults on startup. Then I noticed
that when I searched for Debian packages via the web, there
is a version 5.9.1-2 for debian arm. Unfortunately it also
seg faults. So, in desperation I thought I might try maxima...
seg fault. Then I noticed that pocketworkstation.org had a
slightly older version of maxima_5.9.0-27_arm.deb
(apt-get install found version-28) as the current. But it
seems that version-27 was built using clisp ... <sigh>. So,
apt-get install clisp. Surprize! clisp works fine (+ 1 1).
And downloading the maxima version-27 from pocketworkstation
and running dpkg --install works! 1+1; So I am +2 for clisp
and maxima but zip for gcl and axiom :(

Can you suggest what I might try next? If GCL really does
work on arm (I presume it does work on some arm system or
it wouldn't be in the debian archive at all, right?) What
could be wrong with the Zaurus configuration? Could there
be some library dependency that apt-get is not resolving
properly?

\start
Date: 05 Oct 2004 17:11:47 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: GCL on Zaurus Debian - segmentation violation

Greetings!  Great to see your looking into this!

This has got to be a libc version dependency issue.  The author of
http://pocketworkstation.org/ appears to be putting together his own
Debian snapshots.  But if you apt-get upgrade to the standard Debian
distribution, all that should be taken care of.  Perhaps you could
send your /etc/apt/sources.list, and 'dpkg -l |grep libc'.  5.9.1-2 is
not a recognizable gcl version.  You are correct in stating that axiom
had to run (at least the regression suite) to be in Debian at all.
You can see the full results at:

http://buildd.debian.org/fetch.php?&pkg=axiom&ver=0.20040831-1&arch=arm&stamp=1094488923&file=log&as=raw

This was built using:

Toolchain package versions: libc6-dev_2.3.2.ds1-13 gcc-3.3_1:3.3.4-7 g++-3.3_1:3.3.4-7 binutils_2.15-2 libstdc++5_1:3.3.4-7 libstdc++5-3.3-dev_1:3.3.4-7

and generated dependencies:

 Depends: libc6 (>= 2.3.2.ds1-4), libgmp3, libncurses5 (>= 5.4-1), libreadline4 (>= 4.3-1), axiom-databases (= 0.20040831-1)


Please make sure these match your system (which should be automatic
when using apt, but there may be something residual from
'pocketworkstation') 

There are also some known bugs listed on the webpage -- none of these
are applicable I assume.

I've just double checked the general integrity of the arm binary.
(ran in both the 'testing' and 'unstable' chroot environments, which
is a requirement, of course) Here is a sample session in case this
helps:

=============================================================================
camm@debussy:~$ dchroot unstable
dchroot unstable
Executing shell in chroot: /org/debussy.debian.org/chroot/unstable
camm@debussy:~$ wget ftp://ftp.debian.org/debian/pool/main/a/axiom/ax*831*arm*b
<ftp.debian.org/debian/pool/main/a/axiom/ax*831*arm*b
--21:02:03--  ftp://ftp.debian.org/debian/pool/main/a/axiom/ax*831*arm*b
           => `.listing'
Resolving ftp.debian.org... 208.185.25.35, 128.101.80.131
Connecting to ftp.debian.org[208.185.25.35]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /debian/pool/main/a/axiom ... done.
==> PASV ... done.    ==> LIST ... done.

    [ <=>                                 ] 1,641         --.--K/s             

21:02:04 (1.20 MB/s) - `.listing' saved [1641]

Removed `.listing'.
--21:02:04--  ftp://ftp.debian.org/debian/pool/main/a/axiom/axiom_0.20040831-1_arm.deb
           => `axiom_0.20040831-1_arm.deb'
==> CWD not required.
==> PASV ... done.    ==> RETR axiom_0.20040831-1_arm.deb ... done.
Length: 13,927,948

100%[====================================>] 13,927,948   373.43K/s    ETA 00:00

21:02:50 (303.67 KB/s) - `axiom_0.20040831-1_arm.deb' saved [13927948]

camm@debussy:~$ wget ftp://ftp.debian.org/debian/pool/main/a/axiom/ax*831*data*all*b
<ftp.debian.org/debian/pool/main/a/axiom/ax*831*data*all*b
--21:04:58--  ftp://ftp.debian.org/debian/pool/main/a/axiom/ax*831*data*all*b
           => `.listing'
Resolving ftp.debian.org... 128.101.80.131, 208.185.25.35
Connecting to ftp.debian.org[128.101.80.131]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /debian/pool/main/a/axiom ... done.
==> PASV ... done.    ==> LIST ... done.

    [ <=>                                 ] 1,641         --.--K/s             

21:05:00 (12.23 KB/s) - `.listing' saved [1641]

Removed `.listing'.
No matches on pattern `ax*831*data*all*b'.
camm@debussy:~$ wget ftp://ftp.debian.org/debian/pool/main/a/axiom/ax*831*data*b
<ftp.debian.org/debian/pool/main/a/axiom/ax*831*data*b
--21:05:25--  ftp://ftp.debian.org/debian/pool/main/a/axiom/ax*831*data*b
           => `.listing'
Resolving ftp.debian.org... 208.185.25.35, 128.101.80.131
Connecting to ftp.debian.org[208.185.25.35]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /debian/pool/main/a/axiom ... done.
==> PASV ... done.    ==> LIST ... done.

    [ <=>                                 ] 1,641         --.--K/s             

21:05:26 (1.59 MB/s) - `.listing' saved [1641]

Removed `.listing'.
No matches on pattern `ax*831*data*b'.
camm@debussy:~$ wget ftp://ftp.debian.org/debian/pool/main/a/axiom/ax*data*831*all*b
<ftp.debian.org/debian/pool/main/a/axiom/ax*data*831*all*b
--21:05:38--  ftp://ftp.debian.org/debian/pool/main/a/axiom/ax*data*831*all*b
           => `.listing'
Resolving ftp.debian.org... 128.101.80.131, 208.185.25.35
Connecting to ftp.debian.org[128.101.80.131]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /debian/pool/main/a/axiom ... done.
==> PASV ... done.    ==> LIST ... done.

    [ <=>                                 ] 1,641         --.--K/s             

21:05:41 (11.83 KB/s) - `.listing' saved [1641]

Removed `.listing'.
--21:05:41--  ftp://ftp.debian.org/debian/pool/main/a/axiom/axiom-databases_0.20040831-1_all.deb
           => `axiom-databases_0.20040831-1_all.deb'
==> CWD not required.
==> PASV ... done.    ==> RETR axiom-databases_0.20040831-1_all.deb ... done.
Length: 988,742

100%[====================================>] 988,742      173.32K/s    ETA 00:00

21:05:47 (166.76 KB/s) - `axiom-databases_0.20040831-1_all.deb' saved [988742]

camm@debussy:~$ dpkg --fsys-tarfile axiom-databases_0.20040831-1_all.deb | tar xf -
<-tarfile axiom-databases_0.20040831-1_all.deb | tar xf -
camm@debussy:~$ dpkg --fsys-tarfile axiom_0.20040831-1_arm.deb | tar xf -
dpkg --fsys-tarfile axiom_0.20040831-1_arm.deb | tar xf -
which dchroot
which dchroot
camm@debussy:~$ which dchroot
camm@debussy:~$ cd usr/lib/ax*
pwd
cd usr/lib/ax*
camm@debussy:~/usr/lib/axiom-0.20040831$ pwd
/home/camm/usr/lib/axiom-0.20040831
camm@debussy:~/usr/lib/axiom-0.20040831$ export AXIOM=$(pwd)
export AXIOM=$(pwd)
camm@debussy:~/usr/lib/axiom-0.20040831$ bin/AXIOMsys
bin/AXIOMsys
bin/AXIOMsys: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory
camm@debussy:~/usr/lib/axiom-0.20040831$ export LD_LIBRARY_PATH=$HOME/usr/lib
export LD_LIBRARY_PATH=$HOME/usr/lib
camm@debussy:~/usr/lib/axiom-0.20040831$ bin/AXIOMsys
bin/AXIOMsys
bin/AXIOMsys: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory
camm@debussy:~/usr/lib/axiom-0.20040831$ cd
cd
camm@debussy:~$ wget ftp://ftp.debian.org/debian/pool/main/l/libgmp3/libgmp3*arm*b
<ftp.debian.org/debian/pool/main/l/libgmp3/libgmp3*arm*b
--21:08:31--  ftp://ftp.debian.org/debian/pool/main/l/libgmp3/libgmp3*arm*b
           => `.listing'
Resolving ftp.debian.org... 208.185.25.35, 128.101.80.131
Connecting to ftp.debian.org[208.185.25.35]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /debian/pool/main/l/libgmp3 ... 
No such directory `debian/pool/main/l/libgmp3'.

unlink: No such file or directory
camm@debussy:~$ wget ftp://ftp.debian.org/debian/pool/main/g/gmp3/libgmp3*arm*b
<ftp.debian.org/debian/pool/main/g/gmp3/libgmp3*arm*b
--21:08:49--  ftp://ftp.debian.org/debian/pool/main/g/gmp3/libgmp3*arm*b
           => `.listing'
Resolving ftp.debian.org... 208.185.25.35, 128.101.80.131
Connecting to ftp.debian.org[208.185.25.35]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /debian/pool/main/g/gmp3 ... 
No such directory `debian/pool/main/g/gmp3'.

unlink: No such file or directory
camm@debussy:~$ wget ftp://ftp.debian.org/debian/pool/main/l/libg/libgmp3/libgmp3*arm*b
<ftp.debian.org/debian/pool/main/l/libg/libgmp3/libgmp3*arm*b
--21:09:24--  ftp://ftp.debian.org/debian/pool/main/l/libg/libgmp3/libgmp3*arm*b
           => `.listing'
Resolving ftp.debian.org... 208.185.25.35, 128.101.80.131
Connecting to ftp.debian.org[208.185.25.35]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /debian/pool/main/l/libg/libgmp3 ... 
No such directory `debian/pool/main/l/libg/libgmp3'.

unlink: No such file or directory
camm@debussy:~$ wget ftp://ftp.debian.org/debian/pool/main/libg/libgmp3/libgmp3*arm*b
<ftp.debian.org/debian/pool/main/libg/libgmp3/libgmp3*arm*b
--21:09:37--  ftp://ftp.debian.org/debian/pool/main/libg/libgmp3/libgmp3*arm*b
           => `.listing'
Resolving ftp.debian.org... 208.185.25.35, 128.101.80.131
Connecting to ftp.debian.org[208.185.25.35]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /debian/pool/main/libg/libgmp3 ... done.
==> PASV ... done.    ==> LIST ... done.

    [ <=>                                 ] 2,186         --.--K/s             

21:09:39 (586.31 KB/s) - `.listing' saved [2186]

Removed `.listing'.
--21:09:39--  ftp://ftp.debian.org/debian/pool/main/libg/libgmp3/libgmp3-dev_4.0.1-3_arm.deb
           => `libgmp3-dev_4.0.1-3_arm.deb'
==> CWD not required.
==> PASV ... done.    ==> RETR libgmp3-dev_4.0.1-3_arm.deb ... done.
Length: 362,320

100%[====================================>] 362,320      292.44K/s             

21:09:41 (291.56 KB/s) - `libgmp3-dev_4.0.1-3_arm.deb' saved [362320]

--21:09:41--  ftp://ftp.debian.org/debian/pool/main/libg/libgmp3/libgmp3_4.0.1-3_arm.deb
           => `libgmp3_4.0.1-3_arm.deb'
==> CWD not required.
==> PASV ... done.    ==> RETR libgmp3_4.0.1-3_arm.deb ... done.
Length: 256,118

100%[====================================>] 256,118      272.84K/s             

21:09:42 (272.44 KB/s) - `libgmp3_4.0.1-3_arm.deb' saved [256118]

camm@debussy:~$ dpkg --fsys-tarfile libgmp3_4.0.1-3_arm.deb | tar xf -
dpkg --fsys-tarfile libgmp3_4.0.1-3_arm.deb | tar xf -
camm@debussy:~$ cd usr/lib/ax*
cd usr/lib/ax*
camm@debussy:~/usr/lib/axiom-0.20040831$ bin/AXIOMsys
bin/AXIOMsys
GCL (GNU Common Lisp)  2.6.5 CLtL1    Aug 26 2004 04:02:40
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
                        AXIOM Computer Algebra System 
             Version of Saturday September 4, 2004 at 23:23:53 
-----------------------------------------------------------------------------
   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) -> )quit
)quit
   Please enter y or yes if you really want to leave the interactive 
      environment and return to the operating system:
y
y
camm@debussy:~/usr/lib/axiom-0.20040831$ cat /proc/cpuinfo
cat /proc/cpuinfo
Processor	: StrongARM-110 rev 3 (v4l)
BogoMIPS	: 185.95
Features	: swp half 26bit fastmult 

Hardware	: Rebel-NetWinder
Revision	: 52ff
Serial		: 0000000000000c5c
camm@debussy:~/usr/lib/axiom-0.20040831$ dpkg -l |grep libc
dpkg -l |grep libc
ii  libc6          2.3.2.ds1-17   GNU C Library: Shared libraries and Timezone
ii  libc6-dev      2.3.2.ds1-17   GNU C Library: Development Libraries and Hea
ii  libcap1        1.10-14        support for getting/setting POSIX.1e capabil
ii  libcomerr2     1.35-8         The Common Error Description library
ii  libconsole     0.2.3dbs-55    Shared libraries for Linux console and font 
ii  libcupsys2-dev 1.1.20final+rc Common UNIX Printing System(tm) - developmen
ii  libcupsys2-gnu 1.1.20final+rc Common UNIX Printing System(tm) - libs
ii  libdb1-compat  2.1.3-7        The Berkeley database routines [glibc 2.0/2.
ii  liblocale-gett 1.01-17        Using libc functions for internationalizatio
camm@debussy:~/usr/lib/axiom-0.20040831$ 
=============================================================================

Take care, and please keep me posted.

Bill Page writes:

> Camm,
> 
> Do you know of any successful reports of GCL on Debian Arm,
> in particular with Debian on Zaurus?
> 
> Recently I have managed to install native debian on the
> Zaurus SL-6000. Following the recipes at
> 
>   http://pocketworkstation.org/ 
> 
> and 
> 
>  
> http://www.zaurususergroup.com/modules.php?op=modload&name=phpWiki&file=inde
> x&pagename=Debian%20on%20the%20Zaurus! 
> 
> Debian seems to run great including apt-get etc. although
> I do have a problem with the X-windows Fbvnc thing. See
> 
>   http://externe.net/zaurus/forum/viewtopic.php?t=1473
> 
> Of course the first thing I though of after getting apt-get
> running was to install axiom. This went thru fine (takes
> a fairly long time - about 2 hours) and seems to complete
> normally. BUT when I tried to start axiom it aborted immediately
> with a "Segmentation violation". Most other Debian arm
> applications however seem to run fine. So I thought I would
> try gcl itself. After a little rearranging of the limited
> space on the Zaurus SD card, I managed to apt-get install
> gcl. But :( it also seg faults on startup. Then I noticed
> that when I searched for Debian packages via the web, there
> is a version 5.9.1-2 for debian arm. Unfortunately it also
> seg faults. So, in desperation I thought I might try maxima...
> seg fault. Then I noticed that pocketworkstation.org had a
> slightly older version of maxima_5.9.0-27_arm.deb
> (apt-get install found version-28) as the current. But it
> seems that version-27 was built using clisp ... <sigh>. So,
> apt-get install clisp. Surprize! clisp works fine (+ 1 1).
> And downloading the maxima version-27 from pocketworkstation
> and running dpkg --install works! 1+1; So I am +2 for clisp
> and maxima but zip for gcl and axiom :(
> 
> Can you suggest what I might try next? If GCL really does
> work on arm (I presume it does work on some arm system or
> it wouldn't be in the debian archive at all, right?) What
> could be wrong with the Zaurus configuration? Could there
> be some library dependency that apt-get is not resolving
> properly?

\start
Date: Tue, 5 Oct 2004 18:22:37 -0400 
From: Bill Page
To: Camm Maguire
Subject: RE: GCL on Zaurus Debian - segmentation violation
Cc: Bill Page

Camm,

On Tuesday, October 05, 2004 5:12 PM you wrote:
> ...
> 5.9.1-2 is not a recognizable gcl version.

Sorry, you are right. My email was confusing. I was
talking about 5.9.1-2 for maxima (unstable)

  http://packages.debian.org/unstable/math/maxima

There is also a 5.9.0-28 and apparently a 5.9.0-27 (clisp)
version of maxima. Niether the 5.9.1-2 or 5.9.0-28 versions
of maxima worked for me.

Thanks for the other information. Perhaps an app-get
upgrade is indeed a good idea. I will let you know what
happens...

\start
Date: Fri, 8 Oct 2004 12:34:15 +1000
From: Mike Thomas
To: list
Subject: _*STANDARD_-OUTPUT_* and similar

Hi Tim.

I spent some time this morning on Windows Axiom with particular reference to
the sometimes on, sometimes off problem with compiling AHYP.spad:

------------------------------------------------------------------------
   initializing NRLIB AHYP for ArcHyperbolicFunctionCategory
The syntax of the command is incorrect.
Error: equal: x is a NULL pointer
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by RETURN.
Broken at APPLY.  Type :H for Help.
BOOT>>
------------------------------------------------------------------------

There are a couple of problems here:

1. interpsys thinks that the syntax of some command or other is incorrect,
and

2. the error system ends up with a NULL pointer in the GCL C code.

I managed to isolate problem 2 to a simple case: evaluating 2*y at the
interpsys prompt, which in my incomplete system leads immediately to an
attempt to load the as yet uncompiled polynomial domain code in POLY.o,
hence an error and then the NULL pointer.

I then found that in "g-error.boot.pamphlet" the function  "sayErrorly()"
calls "saturnSayErrorly()" which contains the output stream variable
_*STANDARD_-OUTPUT_*.

Altering that line as follows restores order to the error reporting:

---------------------------------------------------------------------
$ cvs diff src/interp/g-error.boot.pamphlet
Index: src/interp/g-error.boot.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/g-error.boot.pamphlet,v
retrieving revision 1.3
diff -r1.3 g-error.boot.pamphlet
175c175
<   _*STANDARD_-OUTPUT_* : fluid := $texOutputStream
---
>   *STANDARD-OUTPUT* : fluid := $texOutputStream
---------------------------------------------------------------------

However I then found that similar strange variations on various IO related
variables and functions exist in the interpreter code as shown further down.

Are these constructs intentional (perhaps some kind of TeXism which my TeX
system is not handling properly for example) or an unfortunate editing
error?

Cheers

Mike Thomas.


$ fgrep -r -i "_*STANDARD" c:/cvs/head/axiom/src/interp
c:/cvs/head/axiom/src/interp/compat.boot.pamphlet:
read_-line(_*STANDARD_-INPUT
_*)
c:/cvs/head/axiom/src/interp/int-top.boot.pamphlet:    a:=
serverReadLine(_*STAN
DARD_-INPUT_*)
c:/cvs/head/axiom/src/interp/msgdb.boot.pamphlet:  _*STANDARD_-OUTPUT_* :
fluid
:= $texOutputStream
c:/cvs/head/axiom/src/interp/msgdb.boot.pamphlet:  _*STANDARD_-OUTPUT_* :
fluid
:= $texOutputStream
c:/cvs/head/axiom/src/interp/msgdb.boot.pamphlet:  _*STANDARD_-OUTPUT_* :
fluid
:= $texOutputStream

miketh@water /c/cvs/head/fptools
$ fgrep -r -i "read_-line" c:/cvs/head/axiom/src/interp
c:/cvs/head/axiom/src/interp/compat.boot.pamphlet:  s => read_-line(first s)
c:/cvs/head/axiom/src/interp/compat.boot.pamphlet:
read_-line(_*STANDARD_-INPUT
_*)
c:/cvs/head/axiom/src/interp/cstream.boot.pamphlet:        a:=shoeread_-line
s
c:/cvs/head/axiom/src/interp/database.boot.pamphlet:--++  while (not PLACEP
(x:=
 READ_-LINE stream)) repeat
c:/cvs/head/axiom/src/interp/g-error.boot.pamphlet:  READ_-LINE
_*TERMINAL_-IO_*

c:/cvs/head/axiom/src/interp/i-syscmd.boot.pamphlet:    line :=
read_-line(files
tream,false)
c:/cvs/head/axiom/src/interp/msgdb.boot.pamphlet:  ans := READ_-LINE
conStream
c:/cvs/head/axiom/src/interp/server.boot.pamphlet:    READ_-LINE(stream)
c:/cvs/head/axiom/src/interp/server.boot.pamphlet:      l :=
READ_-LINE(stream)
c:/cvs/head/axiom/src/interp/server.boot.pamphlet:        parseAndInterpret
READ
_-LINE(CURINSTREAM) )))
c:/cvs/head/axiom/src/interp/word.boot.pamphlet:    while (not PLACEP (x:=
READ_
-LINE stream)) repeat

\start
Date: Thu, 7 Oct 2004 23:54:14 -0400
From: Tim Daly
To: Mike Thomas
Subject: Re: _*STANDARD_-OUTPUT_* and similar

Mike,

In your example code:


  c:/cvs/head/axiom/src/interp/i-syscmd.boot.pamphlet:    line :=
read_-line(files
tream,false)

which appears to be line 1319 in my sources my copy reads:

    line := read_-line(filestream,false)

Since this line is from the original pamphlet file TeX is not involved.
The pamphlet files are hand coded.

Did you pass these files thru a DOS or Windows system or editor?
I don't see where the random linebreaks could come from.
Clearly the line of code you gave has a syntax error.

Very odd. I'm at a loss to explain it. Check the file modification
times and see if some process touched the file and made it later 
than the surrounding pamphlet files.

\start
Date: Fri, 8 Oct 2004 00:20:09 -0400
From: Bill Page
To: Mike Thomas
Subject: RE: _*STANDARD_-OUTPUT_* and similar

Mike,

These symbols with _ look like standard Axiom escapes to
me. In Axiom (starting probably at the bootsys level)
the underscore character acts the same as the \ in C.
I am quite surprized therefore that your change to the
g-error.boot.pamphlet code, removing the _ even compiles
at all. In the bootsys language (as in the Axiom language
itself)

 *STANDARD-OUTPUT* : fluid := $texOutputStream

should be a syntax error because of the unescaped special
symbols appearing on the left.

 ... hmmm.

I would look for reasons why the _ are apparently not
being interpreted properly as escapes.

And I'm really glad you are back looking at Axiom on
Windows! It is entirely resistant to my feeble attempts
to figure it out!

Regards,
Bill Page.

On Thursday, October 07, 2004 10:34 PM Mike Thomas wrote:
> 
> Hi Tim.
> 
> I spent some time this morning on Windows Axiom with 
> particular reference to the sometimes on, sometimes off
> problem with compiling AHYP.spad:
> 
> --------------------------------------------------------------
>    initializing NRLIB AHYP for ArcHyperbolicFunctionCategory
> The syntax of the command is incorrect.
> Error: equal: x is a NULL pointer
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by RETURN.
> Broken at APPLY.  Type :H for Help.
> BOOT>>
> --------------------------------------------------------------
> 
> There are a couple of problems here:
> 
> 1. interpsys thinks that the syntax of some command or other 
> is incorrect,and
> 
> 2. the error system ends up with a NULL pointer in the GCL C code.
> 
> I managed to isolate problem 2 to a simple case: evaluating 2*y
> at the interpsys prompt, which in my incomplete system leads 
> immediately to an attempt to load the as yet uncompiled polynomial
> domain code in POLY.o, hence an error and then the NULL pointer.
> 
> I then found that in "g-error.boot.pamphlet" the function  
> "sayErrorly()"
> calls "saturnSayErrorly()" which contains the output stream
> variable _*STANDARD_-OUTPUT_*.
> 
> Altering that line as follows restores order to the error reporting:
> 
> ---------------------------------------------------------------------
> $ cvs diff src/interp/g-error.boot.pamphlet
> Index: src/interp/g-error.boot.pamphlet
> ===================================================================
> RCS file: /cvsroot/axiom/axiom/src/interp/g-error.boot.pamphlet,v
> retrieving revision 1.3
> diff -r1.3 g-error.boot.pamphlet
> 175c175
> <   _*STANDARD_-OUTPUT_* : fluid := $texOutputStream
> ---
> >   *STANDARD-OUTPUT* : fluid := $texOutputStream
> ---------------------------------------------------------------------
> 
> However I then found that similar strange variations on 
> various IO related variables and functions exist in the
> interpreter code as shown further down.
> 
> Are these constructs intentional (perhaps some kind of TeXism 
> which my TeX system is not handling properly for example) or an
> unfortunate editing error?

\start
Date: Fri, 8 Oct 2004 00:25:06 -0400
From: Bill Page
To: Mike Thomas
Subject: RE: _*STANDARD_-OUTPUT_* and similar

Tim,

I don't think the problem here has anything to do with
strange line breaks. As far as I can tell these are
artifically inserted by the email system on long lines.
The issue that Mike was pointing at was the use of the
_ in the name

  read_-line

My explanation is that the _ acts as an escape so that
- is parsed as part of the name and not an operator.
Does this make sense to you? Is it true that this use
of _ appears first at the bootsys level of the code?

Regards,
Bill Page.

On Thursday, October 07, 2004 11:54 PM you wrote
to Mike Thomas:
> 
> In your example code:
> 
> 
>   c:/cvs/head/axiom/src/interp/i-syscmd.boot.pamphlet:    line :=
> read_-line(files
> tream,false)
> 
> which appears to be line 1319 in my sources my copy reads:
> 
>     line := read_-line(filestream,false)
> 
> Since this line is from the original pamphlet file TeX is not 
> involved.
> The pamphlet files are hand coded.
> 
> Did you pass these files thru a DOS or Windows system or editor?
> I don't see where the random linebreaks could come from.
> Clearly the line of code you gave has a syntax error.
> 
> Very odd. I'm at a loss to explain it. Check the file modification
> times and see if some process touched the file and made it later 
> than the surrounding pamphlet files.

\start
Date: Fri, 8 Oct 2004 14:50:21 +1000
From: Mike Thomas
To: Bill Page
Subject: RE: _*STANDARD_-OUTPUT_* and similar

Hi Bill.

| These symbols with _ look like standard Axiom escapes to
| me. In Axiom (starting probably at the bootsys level)
| the underscore character acts the same as the \ in C.
| I am quite surprized therefore that your change to the
| g-error.boot.pamphlet code, removing the _ even compiles
| at all. In the bootsys language (as in the Axiom language
| itself)
|
|  *STANDARD-OUTPUT* : fluid := $texOutputStream
|
| should be a syntax error because of the unescaped special
| symbols appearing on the left.
|
|  ... hmmm.
|
| I would look for reasons why the _ are apparently not
| being interpreted properly as escapes.

-------------------------------------------------
Thanks for the info - will do.


| And I'm really glad you are back looking at Axiom on
| Windows! It is entirely resistant to my feeble attempts
| to figure it out!

The Windows Axiom failure is the last GCL boundary I need to push back and
so I hope to focus more closely on it.  Unfortunately GCL itself is rapidly
evolving under pressure from the Unix side and that usually spells more work
and therefore distraction from Axiom.

\start
Date: Fri, 8 Oct 2004 10:24:19 +0000
From: Martin Rubey
To: list
Subject: RE: _*STANDARD_-OUTPUT_* and similar
Cc: Mike Thomas

Bill Page writes:

 > And I'm really glad you are back looking at Axiom on
 > Windows! It is entirely resistant to my feeble attempts
 > to figure it out!

I'd just wanted to second that. Wonderful!

\start
Date: Mon, 11 Oct 2004 01:52:25 -0400
From: Bill Page
To: Camm Maguire
Subject: GCL on Zaurus SL-6000 under Debian

Camm,

See the GOOD NEWS below.

On Tuesday, October 05, 2004 5:12 PM you wrote:
> 
> Greetings!  Great to see your looking into this!
> 
> This has got to be a libc version dependency issue.  The
> author of http://pocketworkstation.org/ appears to be
> putting together his own Debian snapshots.  But if you
> apt-get upgrade to the standard Debian distribution, all
> that should be taken care of.

I did the 'apt-get upgrade', unfortunately I still get
immediate seg faults from both Axiom and GCL.

> Perhaps you could send your /etc/apt/sources.list, and
> 'dpkg -l |grep libc'.

# cat /etc/apt/sources.list
deb http://debian.mirror.cygnal.ca/debian testing main
#deb http://http.us.debian.org/debian testing main
deb http://nonUS.debian.org/debian-non-US testing/non-US main
deb-src http://debian.mirror.cygnal.ca/debian testing main
#deb-src http://http.us.debian.org/debian testing main contrib non-free

# dpkg -l |grep libc
ii  libc6          2.3.2.ds1-16   GNU C Library: Shared libraries ...
ii  libc6-dev      2.3.2.ds1-16   GNU C Library: Development Libraries
ii  libcap1        1.10-14        support for getting/setting POSIX
ii  libcomerr2     1.35-6         The Common Error Description library
ii  libcompfaceg1  1989.11.11-24  Compress/decompress images
ii  libcurl2       7.11.2-8       Multi-protocol file transfer library
ii  libdb1-compat  2.1.3-7        The Berkeley database routines
ii  liblocale-gett 1.01-17        Using libc functions for inter...

----------

As per Bob McElrath's message,

> alpha architecture:
>  ii  libc6.1   2.3.2.ds1-11    GNU C Library: Shared libraries
> axiom segfaults
>  ii  libc6.1   2.3.2.ds1-16    GNU C Library: Shared libraries
> axiom runs fine
> 
> i386 architecture:
>  ii  libc6     2.3.2.ds1-12    GNU C Library: Shared libraries
> axiom runs fine
> 
> Thus, it would appear that the debian package needs to add a
> dependency on libc6 2.3.2.ds1-12 or greater.  I do not know
> why on alpha it is "libc6.1" and on intel it is "libc6".  

If what I am seeing is the same seg fault, then it seems
very sensitive to the libc6 version and libc6 2.3.2.ds1-16
may also not work for arm on Zaurus with the debian arm
build of GCL.

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

But the GOOD NEWS is that I did manange to build GCL from the
2.6.5 tarball from the Axiom CVS! First I did

# apt-get build-dep gcl
# tar xzvf axiom/zips/gcl-2.6.5.tgz
# cd gcl-2.6.5
# ./configure --enable-vssize=65536*1 --disable-statsysbfd \
  --enable-locbfd --enable-maxpage=32*1024

Note use of locbfd and smaller memory parameters then currently
specified in the Axiom build:

# ./configure --enable-vssize=65536*4 --enable-statsysbfd \
  --enable-maxpage=128*1024

which gave "Can't allocate" message when first trying to run
raw_pre_gcl. I got the same result with the default ./configure.
But using --enable-locbfd did the trick and it is now working
fine. I am not sure how much bigger I can practically make the
memory options, but I think parameters might be too large.
Can you tell how large they can be set based on the output
of 'free' below?

So, anyway I am now running an Axiom build with 

# ./configure --enable-vssize=65536*2 --disable-statsysbfd \
  --enable-locbfd --enable-maxpage=64*1024

I will let you know how (if) it finishes some time tomorrow.

Regards,
Bill Page.

----------
Build log with Axiom gcl configure options:

...
touch bfdfiles
rm -rf libpre_gcl.a
ar rs libpre_gcl.a ../o/alloc.o ../o/array.o ../o/assignment.o =
../o/backq.o
../o
/bds.o ../o/big.o ../o/bind.o ../o/bitop.o ../o/block.o ../o/catch.o
../o/cfun.o
 ../o/character.o ../o/clxsocket.o ../o/cmpaux.o ../o/conditional.o
../o/earith.
o ../o/error.o ../o/eval.o ../o/fat_string.o ../o/file.o ../o/format.o
../o/fram
e.o ../o/funlink.o ../o/gbc.o ../o/gcl_readline.o ../o/gmp_wrappers.o
../o/hash.
o ../o/init_pari.o ../o/iteration.o ../o/let.o ../o/lex.o ../o/list.o
../o/macro
s.o ../o/main.o ../o/makefun.o ../o/mapfun.o ../o/multival.o =
../o/new_init.o
../
o/nfunlink.o ../o/nsocket.o ../o/num_arith.o ../o/num_co.o =
../o/num_comp.o
../o/
num_log.o ../o/num_pred.o ../o/num_rand.o ../o/num_sfun.o ../o/number.o
../o/pac
kage.o ../o/pathname.o ../o/plt.o ../o/predicate.o ../o/print.o =
../o/prog.o
../o
/read.o ../o/reference.o ../o/regexpr.o ../o/run_process.o =
../o/sequence.o
../o/
sfasl.o ../o/sockets.o ../o/string.o ../o/structure.o ../o/symbol.o
../o/topleve
l.o ../o/typespec.o ../o/unixfasl.o ../o/unixfsys.o ../o/unixsave.o
../o/unixsys
.o ../o/unixtime.o ../o/usig.o ../o/usig2.o ../o/utils.o sys_pre_gcl.o
ar: creating libpre_gcl.a
cp ../o/gcllib.a libgclp.a
ranlib libgclp.a
cp init_pre_gcl.lsp.in init_pre_gcl.lsp.tmp
touch raw_pre_gcl_map
gcc -o raw_pre_gcl /root/axiom/obj/linux/lib/cfuns-c.o
/root/axiom/obj/linux/lib
/sockio-c.o \
        -L.  -Wl,-Map raw_pre_gcl_map   -lpre_gcl -lm  -lgmp
/usr/lib/libbfd.a /
usr/lib/libiberty.a -lreadline -lncurses -lc -lgclp
/root/axiom/obj/linux/lib/li
bspad.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
-mlong-c
alls \"#1" \
        -e "s#@LI-LD@#\"gcc -o \"#1" \
        -e "s#@LI-LD-LIBS@#\"   -lpre_gcl -lm  -lgmp /usr/lib/libbfd.a
/usr/lib/
libiberty.a -lreadline -lncurses -lc -lgclp
/root/axiom/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
/root/axiom/lsp/gcl-2.6.5/unixport/raw_pre_gcl
/root/axiom/lsp/gcl-2.6.5/unixpor
t/ -libdir /root/axiom/lsp/gcl-2.6.5/ < foo

Unrecoverable error: Can't allocate.  Good-bye!.
make[4]: *** [saved_pre_gcl] Error 134
rm raw_pre_gcl init_pre_gcl.lsp
make[4]: Leaving directory `/root/axiom/lsp/gcl-2.6.5/unixport'
make[3]: *** [unixport/saved_pre_gcl] Error 2
make[3]: Leaving directory `/root/axiom/lsp/gcl-2.6.5'
/bin/sh: line 1: unixport/saved_gcl: No such file or directory
make[2]: *** [gcldir] Error 127
make[1]: *** [lspdir] Error 2
make: *** [all] Error 2
make[2]: Leaving directory `/root/axiom/lsp'
make[1]: Leaving directory `/root/axiom'


/root/axiom# free
             total       used       free     shared    buffers     =
cached
Mem:         62048      46756      15292          0       1116      =
30632
-/+ buffers/cache:      15008      47040
Swap:            0          0          0


/root/axiom# vmstat
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy =
id
wa
 1  0      0  15264   1120  30652    0    0     6    71   51    19 12 41 =
47
0


/root/axiom# ps -A
  PID TTY          TIME CMD
    1 ?        00:00:16 init
    2 ?        00:00:00 keventd
    3 ?        00:06:32 kapm-idled
    4 ?        00:00:00 off_thread
    5 ?        00:00:00 battchrgon
    6 ?        00:00:00 battchrgoff
    7 ?        00:03:06 sharpsl_bat
    8 ?        00:00:00 fatalchk
    9 ?        00:00:00 jacketchk
   10 ?        00:00:00 ksoftirqd_CPU0
   11 ?        00:00:08 kswapd
   12 ?        00:00:00 bdflush
   13 ?        00:00:00 kupdated
   14 ?        00:00:00 buzzer
   15 ?        00:00:00 swapper
   16 ?        00:00:00 swapper
   17 ?        00:00:00 mtdblockd
   45 ?        00:00:00 jffs2_gcd_mtd3
   91 ?        00:00:00 khubd
  123 ?        00:00:00 sdmgr
  160 ?        00:00:00 cardmgr
  171 ?        00:00:00 inetd
  181 ?        00:00:00 atd
  215 ?        00:00:02 sh
  216 ?        00:01:14 shsync
  224 ?        00:00:00 zdebian
  227 ?        00:00:00 zdebian
  270 ?        00:00:00 dhcpd
  273 ?        00:00:02 sshd
  274 ?        00:00:00 sh
  279 ?        00:00:00 sh
 4093 ?        00:00:00 ps
/root/axiom#

\start
Date: Mon, 11 Oct 2004 02:31:33 -0500
From: Bill Page
To: list
Subject: SuchThat

This link is sent to you from http://page.axiom-developer.org/zope/Plone

You are receiving this mail because someone read a page at
Axiom Portal
and thought it might interest you.

It is sent by Bill Page with the following comment:
"I am curious if there is any documentation available on the SuchThat domain. Notice that this is *not* directly related to the suchThat operation! What other things besides eigenvalues make use of this construct?"

SuchThat

http://page.axiom-developer.org/zope/Plone/Members/billpage/SuchThat

--
Portal Administrator

\start
Date: Mon, 11 Oct 2004 15:11:16 +0100
From: Mike Dewar
To: Bill Page
Subject: Re: SuchThat

According to the browser its used by EigenPackage, PolynomialIdeals,
RadicalEigenPackage and RadicalSolvePackage.

Mike.
 
On Mon, Oct 11, 2004 at 02:31:33AM -0500, Bill Page wrote:
> 
> 
> This link is sent to you from http://page.axiom-developer.org/zope/Plone
> 
> You are receiving this mail because someone read a page at
> Axiom Portal
> and thought it might interest you.
> 
> It is sent by Bill Page with the following comment:
> "I am curious if there is any documentation available on the SuchThat domain. Notice that this is *not* directly related to the suchThat operation! What other things besides eigenvalues make use of this construct?"
> 
> SuchThat
> 
> 
> 
> http://page.axiom-developer.org/zope/Plone/Members/billpage/SuchThat
> 
> --
> Portal Administrator

\start
Date: Mon, 11 Oct 2004 11:00:50 -0400
From: Tim Daly
To: Mike Dewar
Subject: Re: SuchThat
Cc: Bill Page

Bill,

I wrote the SuchThat domain as part of my PhD thesis work.
The basic idea was to be able to wrap domains with provisos.
You would be able to say 

 1/x such that x != 0

\start
Date: 11 Oct 2004 12:34:24 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: GCL on Zaurus SL-6000 under Debian

Greetings, and thank you so much for your feedback here!

Bill Page writes:

> Camm,
> 
> See the GOOD NEWS below.
> 
> On Tuesday, October 05, 2004 5:12 PM you wrote:
> > 
> > Greetings!  Great to see your looking into this!
> > 
> > This has got to be a libc version dependency issue.  The
> > author of http://pocketworkstation.org/ appears to be
> > putting together his own Debian snapshots.  But if you
> > apt-get upgrade to the standard Debian distribution, all
> > that should be taken care of.
> 
> I did the 'apt-get upgrade', unfortunately I still get
> immediate seg faults from both Axiom and GCL.
> 

I think you've pinned it here.  The virtual memory size of the gcl
default build is 81Mb, and you only have 62.  

If you want to double check you can

gdb /usr/lib/gcl-2.6.5/unixport/saved_gcl
r
bt

and see where the fault is.

The default hole size is 1/10 MAXPAGES, which with the default maxpage
setting is 52Mb.  It is not actually in use until allocated, but the
space must be available nonetheless.  Not sure how tiny axiom itself
can be made, but you can shrink the hole size, giving you finer
grained increments to the growing heap at the expense of gc time, if
things really get tight.

Wondering if you can just setup a swapfile over nfs to see if the
default binary will work for you.

> > Perhaps you could send your /etc/apt/sources.list, and
> > 'dpkg -l |grep libc'.
> 
> # cat /etc/apt/sources.list
> deb http://debian.mirror.cygnal.ca/debian testing main
> #deb http://http.us.debian.org/debian testing main
> deb http://nonUS.debian.org/debian-non-US testing/non-US main
> deb-src http://debian.mirror.cygnal.ca/debian testing main
> #deb-src http://http.us.debian.org/debian testing main contrib non-free
> 
> # dpkg -l |grep libc
> ii  libc6          2.3.2.ds1-16   GNU C Library: Shared libraries ...
> ii  libc6-dev      2.3.2.ds1-16   GNU C Library: Development Libraries
> ii  libcap1        1.10-14        support for getting/setting POSIX
> ii  libcomerr2     1.35-6         The Common Error Description library
> ii  libcompfaceg1  1989.11.11-24  Compress/decompress images
> ii  libcurl2       7.11.2-8       Multi-protocol file transfer library
> ii  libdb1-compat  2.1.3-7        The Berkeley database routines
> ii  liblocale-gett 1.01-17        Using libc functions for inter...
> 
> ----------
> 
> As per Bob McElrath's message,
> 
> > alpha architecture:
> >  ii  libc6.1   2.3.2.ds1-11    GNU C Library: Shared libraries
> > axiom segfaults
> >  ii  libc6.1   2.3.2.ds1-16    GNU C Library: Shared libraries
> > axiom runs fine
> > 
> > i386 architecture:
> >  ii  libc6     2.3.2.ds1-12    GNU C Library: Shared libraries
> > axiom runs fine
> > 
> > Thus, it would appear that the debian package needs to add a
> > dependency on libc6 2.3.2.ds1-12 or greater.  I do not know
> > why on alpha it is "libc6.1" and on intel it is "libc6".  
> 
> If what I am seeing is the same seg fault, then it seems
> very sensitive to the libc6 version and libc6 2.3.2.ds1-16
> may also not work for arm on Zaurus with the debian arm
> build of GCL.

As you have not cleared the fault with an upgrade, and as you are now
running the same libc as I did on the verification run I posted, this
is unrelated to Bob's earlier, presumably alpha specific transient
libc instability, I think.

> 
> ------------
> 
> But the GOOD NEWS is that I did manange to build GCL from the
> 2.6.5 tarball from the Axiom CVS! First I did
> 
> # apt-get build-dep gcl
> # tar xzvf axiom/zips/gcl-2.6.5.tgz
> # cd gcl-2.6.5
> # ./configure --enable-vssize=65536*1 --disable-statsysbfd \
>   --enable-locbfd --enable-maxpage=32*1024
> 
> Note use of locbfd and smaller memory parameters then currently
> specified in the Axiom build:
> 
> # ./configure --enable-vssize=65536*4 --enable-statsysbfd \
>   --enable-maxpage=128*1024
> 
> which gave "Can't allocate" message when first trying to run
> raw_pre_gcl. I got the same result with the default ./configure.
> But using --enable-locbfd did the trick and it is now working
> fine. I am not sure how much bigger I can practically make the
> memory options, but I think parameters might be too large.
> Can you tell how large they can be set based on the output
> of 'free' below?
> 
> So, anyway I am now running an Axiom build with 
> 
> # ./configure --enable-vssize=65536*2 --disable-statsysbfd \
>   --enable-locbfd --enable-maxpage=64*1024
> 
> I will let you know how (if) it finishes some time tomorrow.
> 

You probably won't succeed, but might just luck out.  The AXIOMsys
virtual memory size is actually a little less than the default gcl
vmsize, as it shaves off 4k pages from the relocatable area to more
than compensate for the expanded number of pages for cells:

=============================================================================
(sid)camm@intech66:/fix/g/camm/maxima$ /usr/bin/gcl
GCL (GNU Common Lisp)  2.6.5 CLtL1    Sep  3 2004 17:47:27
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

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

>(room)

   211/211    40.1%         CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
     2/28     25.8%         FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE READTABLE NIL
    47/49     72.4%         SYMBOL STREAM
     1/2      12.8%         PACKAGE
     1/38     50.0%         ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME CCLOSURE FAT-STRING
    16/32     85.2%         STRING
     3/27     97.5%         CFUN BIGNUM
     6/115    87.8%         SFUN GFUN CFDATA SPICE NIL

   316/512                  contiguous (76 blocks)
       13107                hole
       5242    0.0%         relocatable

       287 pages for cells
     18952 total pages
    101834 pages available
     10286 pages in heap but not gc'd + pages needed for gc marking
    131072 maximum pages

>(by)
(sid)camm@intech66:/fix/g/camm/maxima$ axiom
GCL (GNU Common Lisp)  2.6.5 CLtL1    Aug 17 2004 19:17:02
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
                        AXIOM Computer Algebra System 
               Version of Tuesday August 31, 2004 at 22:58: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) -> )lisp (room)

   736/736    95.8%       1 CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
    72/200    94.1%         FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE READTABLE NIL
   214/500    99.5%         SYMBOL STREAM
     1/8      23.1%         PACKAGE
    18/400    77.1%         ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME CCLOSURE FAT-STRING
   116/500    71.3%         STRING
    12/100    63.1%         CFUN BIGNUM
    34/115    97.9%         SFUN GFUN CFDATA SPICE NIL

  1177/1177                 contiguous (312 blocks)
       13348                hole
       1000   10.8%         relocatable

      1203 pages for cells
     16728 total pages
    108009 pages available
      6335 pages in heap but not gc'd + pages needed for gc marking
    131072 maximum pages
Value = NIL
(1) -> 
=============================================================================

I get 74Mb.  Can you get some swap somewhere?  My test arm machine has
the same amount of ram, but generous swap at 256M, which is certainly
overkill for the present purpose.

Take care,

> Regards,
> Bill Page.
> 
> ----------
> Build log with Axiom gcl configure options:
> 
> ...
> touch bfdfiles
> rm -rf libpre_gcl.a
> ar rs libpre_gcl.a ../o/alloc.o ../o/array.o ../o/assignment.o ../o/backq.o
> ../o
> /bds.o ../o/big.o ../o/bind.o ../o/bitop.o ../o/block.o ../o/catch.o
> ../o/cfun.o
>  ../o/character.o ../o/clxsocket.o ../o/cmpaux.o ../o/conditional.o
> ../o/earith.
> o ../o/error.o ../o/eval.o ../o/fat_string.o ../o/file.o ../o/format.o
> ../o/fram
> e.o ../o/funlink.o ../o/gbc.o ../o/gcl_readline.o ../o/gmp_wrappers.o
> ../o/hash.
> o ../o/init_pari.o ../o/iteration.o ../o/let.o ../o/lex.o ../o/list.o
> ../o/macro
> s.o ../o/main.o ../o/makefun.o ../o/mapfun.o ../o/multival.o ../o/new_init.o
> ../
> o/nfunlink.o ../o/nsocket.o ../o/num_arith.o ../o/num_co.o ../o/num_comp.o
> ../o/
> num_log.o ../o/num_pred.o ../o/num_rand.o ../o/num_sfun.o ../o/number.o
> ../o/pac
> kage.o ../o/pathname.o ../o/plt.o ../o/predicate.o ../o/print.o ../o/prog.o
> ../o
> /read.o ../o/reference.o ../o/regexpr.o ../o/run_process.o ../o/sequence.o
> ../o/
> sfasl.o ../o/sockets.o ../o/string.o ../o/structure.o ../o/symbol.o
> ../o/topleve
> l.o ../o/typespec.o ../o/unixfasl.o ../o/unixfsys.o ../o/unixsave.o
> ../o/unixsys
> .o ../o/unixtime.o ../o/usig.o ../o/usig2.o ../o/utils.o sys_pre_gcl.o
> ar: creating libpre_gcl.a
> cp ../o/gcllib.a libgclp.a
> ranlib libgclp.a
> cp init_pre_gcl.lsp.in init_pre_gcl.lsp.tmp
> touch raw_pre_gcl_map
> gcc -o raw_pre_gcl /root/axiom/obj/linux/lib/cfuns-c.o
> /root/axiom/obj/linux/lib
> /sockio-c.o \
>         -L.  -Wl,-Map raw_pre_gcl_map   -lpre_gcl -lm  -lgmp
> /usr/lib/libbfd.a /
> usr/lib/libiberty.a -lreadline -lncurses -lc -lgclp
> /root/axiom/obj/linux/lib/li
> bspad.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
> -mlong-c
> alls \"#1" \
>         -e "s#@LI-LD@#\"gcc -o \"#1" \
>         -e "s#@LI-LD-LIBS@#\"   -lpre_gcl -lm  -lgmp /usr/lib/libbfd.a
> /usr/lib/
> libiberty.a -lreadline -lncurses -lc -lgclp
> /root/axiom/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
> /root/axiom/lsp/gcl-2.6.5/unixport/raw_pre_gcl
> /root/axiom/lsp/gcl-2.6.5/unixpor
> t/ -libdir /root/axiom/lsp/gcl-2.6.5/ < foo
> 
> Unrecoverable error: Can't allocate.  Good-bye!.
> make[4]: *** [saved_pre_gcl] Error 134
> rm raw_pre_gcl init_pre_gcl.lsp
> make[4]: Leaving directory `/root/axiom/lsp/gcl-2.6.5/unixport'
> make[3]: *** [unixport/saved_pre_gcl] Error 2
> make[3]: Leaving directory `/root/axiom/lsp/gcl-2.6.5'
> /bin/sh: line 1: unixport/saved_gcl: No such file or directory
> make[2]: *** [gcldir] Error 127
> make[1]: *** [lspdir] Error 2
> make: *** [all] Error 2
> make[2]: Leaving directory `/root/axiom/lsp'
> make[1]: Leaving directory `/root/axiom'
> 
> 
> /root/axiom# free
>              total       used       free     shared    buffers     cached
> Mem:         62048      46756      15292          0       1116      30632
> -/+ buffers/cache:      15008      47040
> Swap:            0          0          0
> 
> 
> /root/axiom# vmstat
> procs -----------memory---------- ---swap-- -----io---- --system--
> ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id
> wa
>  1  0      0  15264   1120  30652    0    0     6    71   51    19 12 41 47
> 0
> 
> 
> /root/axiom# ps -A
>   PID TTY          TIME CMD
>     1 ?        00:00:16 init
>     2 ?        00:00:00 keventd
>     3 ?        00:06:32 kapm-idled
>     4 ?        00:00:00 off_thread
>     5 ?        00:00:00 battchrgon
>     6 ?        00:00:00 battchrgoff
>     7 ?        00:03:06 sharpsl_bat
>     8 ?        00:00:00 fatalchk
>     9 ?        00:00:00 jacketchk
>    10 ?        00:00:00 ksoftirqd_CPU0
>    11 ?        00:00:08 kswapd
>    12 ?        00:00:00 bdflush
>    13 ?        00:00:00 kupdated
>    14 ?        00:00:00 buzzer
>    15 ?        00:00:00 swapper
>    16 ?        00:00:00 swapper
>    17 ?        00:00:00 mtdblockd
>    45 ?        00:00:00 jffs2_gcd_mtd3
>    91 ?        00:00:00 khubd
>   123 ?        00:00:00 sdmgr
>   160 ?        00:00:00 cardmgr
>   171 ?        00:00:00 inetd
>   181 ?        00:00:00 atd
>   215 ?        00:00:02 sh
>   216 ?        00:01:14 shsync
>   224 ?        00:00:00 zdebian
>   227 ?        00:00:00 zdebian
>   270 ?        00:00:00 dhcpd
>   273 ?        00:00:02 sshd
>   274 ?        00:00:00 sh
>   279 ?        00:00:00 sh
>  4093 ?        00:00:00 ps
> /root/axiom#

\start
Date: Mon, 11 Oct 2004 12:40:44 -0400
From: Bill Page
To: Tim Daly
Subject: RE: SuchThat
Cc: Mike Dewar

Tim,

This seems quite fascinating to me - and quite a powerful idea
as an Axiom type, though at first thought as a 'type' it does
seem a little strange.

You wouldn't happen to have a copy of that PhD thesis online
somewhere, would you? Is there some part of it that we could
extract as documentation for SuchThat?

Tim, were you also involved in writing the EigenPackage,
PolynomialIdeals, RadicalEigenPackage and RadicalSolvePackage
packages? How was it decided to make use of SuchThat in these
cases?

Regards,
Bill Page.


On Monday, October 11, 2004 11:01 AM Tim Daly wrote: 
> 
> I wrote the SuchThat domain as part of my PhD thesis work.
> The basic idea was to be able to wrap domains with provisos.
> You would be able to say 
> 
>  1/x such that x != 0
> 

On Monday, October 11, 2004 10:11 AM Mike Dewar Mike Dewar
wrote:
> 
> According to the browser its used by EigenPackage,
> PolynomialIdeals, RadicalEigenPackage and RadicalSolvePackage.
> 

\start
Date: Mon, 11 Oct 2004 14:01:47 -0400
From: Tim Daly
To: Bill Page
Subject: Re: SuchThat
Cc: Mike Dewar

Ah, would that I did have my PhD thesis online. Since I don't have a
PhD (after 11 years :-) ) it's unlikely to ever be online.  My thesis
topic was on "Provisos". These are fundamental mathematical constraints
on the domain and range of functions. Every computation should produce
them, carry them, and compute the interaction between them. SuchThat
is essentially a "storage" mechanism to wrap results with provisos.
Axiom output should be qualified not just by type but also with the
corresponding provisos. You see this all the time in math textbooks.

I do have some documents moldering in the history pile but it's
probably better if I write the SuchThat docs from scratch. In fact,
there are several improvements I could make.

I didn't write the domains that use it. That was Manuel Bronstein.
He and I had several discussions about the subject.

The interaction between provisos, the domains, and the elements of the
domains is quite complex and absolutely fundamental to computational
mathematics. I never really published anything about my investigations
of the subject. I understand how to compute with them and have some
interesting research results.  I even have a primitive implementation
somewhere on a floppy disk (which I probably can't read
anymore). Axiom clearly needs to develop the proviso capability but
that's a real research issue and the NSF no longer supports that kind
of research. Perhaps one of Buchberger, Bronstein, or Davenport's
students will take up the torch.

What sparked your interest in SuchThat?

\start
Date: Mon, 11 Oct 2004 14:09:01 -0400
From: Bill Page
To: Tim Daly
Subject: RE: SuchThat
Cc: Mike Dewar

On Monday, October 11, 2004 2:02 PM Tim Daly wrote:
>...
> My thesis topic was on "Provisos". These are fundamental
> mathematical constraints on the domain and range of
> functions. Every computation should produce them, carry
> them, and compute the interaction between them.

Yes. I think Maple and Mathematica both are moving in this
direction, albiet not with the notion of a Type. Instead they
are tending to return more results as 'piecewise' conditionals.

> 
> I do have some documents moldering in the history pile but
> it's probably better if I write the SuchThat docs from
> scratch. In fact, there are several improvements I could make.

Ok everyone, let's encourage Tim to do this!

> ... 
> The interaction between provisos, the domains, and the elements
> of the domains is quite complex and absolutely fundamental to
> computational mathematics. I never really published anything
> about my investigations of the subject.

Now would be a good time to do it - looks of space available
on MathAction :)

> I understand how to compute with them and have some
> interesting research results.  I even have a primitive
> implementation somewhere on a floppy disk (which I probably
> can't read anymore). Axiom clearly needs to develop the
> proviso capability but that's a real research issue and
> the NSF no longer supports that kind of research. Perhaps
> one of Buchberger, Bronstein, or Davenport's students will
> take up the torch.

Ok, we have got advertise!

> 
> What sparked your interest in SuchThat?
> 

I was looking for a non-trivial example of 'numeric' versus
'symbolic' mathematics to discuss at the AMS meeting this
weekend. Symbolic eigenvalue computations have been of
interest to me before. So I loooked at section 8.4 of the
AXIOM book (page 241 in the original book). When I tried
the example eq. (1) I found that it produced a result
slightly different than the book.

http://page.axiom-developer.org/zope/Plone/Members/billpage/MathAction2

The 'extra' result was in the form of a SuchThat type.

So in the end, this did not (quite) turn out to be the
numeric computational result that I had expected!

\start
Date: Mon, 11 Oct 2004 14:27:13 -0400
From: Bill Page
To: Tim Daly
Subject: RE: SuchThat

On Monday, October 11, 2004 2:09 PM I wrote:
> ... 
> I was looking for a non-trivial example of 'numeric' versus
> 'symbolic' mathematics to discuss at the AMS meeting this
> weekend. Symbolic eigenvalue computations have been of
> interest to me before. So I loooked at section 8.4 of the
> AXIOM book (page 241 in the original book). When I tried
> the example eq. (1) I found that it produced a result
> slightly different than the book.
> 
http://page.axiom-developer.org/zope/Plone/Members/billpage/MathAction2
>
> The 'extra' result was in the form of a SuchThat type.
>
> So in the end, this did not (quite) turn out to be the
> numeric computational result that I had expected!

In fact the more I think about it, I wonder why the
author choose to return the 2nd and 3rd eigenvalues
in this problem only implicitly. Was it only for
compactness? In the case of problems of low degree the
roots could easily have been given numerically as shown
in the calculation. Perhaps it was for generality?
There is some new algorithm, isn't there, for finding
roots of polynomials of any degree?

\start
Date: Mon, 11 Oct 2004 15:13:10 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: [Gcl-devel] Re: GCL on Zaurus SL-6000 under Debian

Camm,

On Monday, October 11, 2004 12:34 PM you wrote:
>
> I think you've pinned it here.  The virtual memory size
> of the gcl default build is 81Mb, and you only have 62.
> ...  
> The default hole size is 1/10 MAXPAGES, which with the
> default maxpage setting is 52Mb.  It is not actually in
> use until allocated, but the space must be available
> nonetheless.  Not sure how tiny axiom itself can be made,
> but you can shrink the hole size, giving you finer grained
> increments to the growing heap at the expense of gc time,
> if things really get tight.

So, if I set --enable-maxpage=64*1024, then the default
hole size would be --enable-holepage=6*1024, right? How
small can I practically make it?
 
> Wondering if you can just setup a swapfile over nfs to
> see if the default binary will work for you.

I am willing to try but I have never done this. Can you
given me a few (explicit) tips how to proceed? It is
also apparently possible for me to connect a usb disk
drive to this BIG MACHINE in the small box (: Yes, I am
very impressed by the SL-6000! :) There is a nice little
40 Gbyte drive that runs directly off the usb power for
about $200. Perhaps I will run down to the store when
it is open again tomorrow...

Maybe I should just admit that running Axiom isn't (quite)
practical on this system unless I can add swap space?
But as a continued challenge, I note that I can run Clisp
and maxima under Clisp in much less space without swap.

> > ... 
> > So, anyway I am now running an Axiom build with 
> > 
> > # ./configure --enable-vssize=65536*2 --disable-statsysbfd \
> >   --enable-locbfd --enable-maxpage=64*1024
> > 
> > I will let you know how (if) it finishes some time tomorrow.
> > 
> 
> You probably won't succeed, but might just luck out.  The
> AXIOMsys virtual memory size is actually a little less than
> the default gcl vmsize, as it shaves off 4k pages from the
> relocatable area to more than compensate for the expanded
> number of pages for cells:
>

Well you were right. The build stopped apparently at the point
were it was about to create depsys (it built bootsys ok). See
the build log below. Does the message "Can't allocate buffer"
tell you anything specific about memory?
 
> ... 
> I get 74Mb.  Can you get some swap somewhere?  My test arm
> machine has the same amount of ram, but generous swap at 256M,
> which is certainly overkill for the present purpose.
>

Yes, tomorrow.

Regards,
Bill Page.

-------

tail of build.log:

...
Loading /root/axiom/obj/linux/interp/c-util.o
start address -T 0x2064000 Finished loading
/root/axiom/obj/linux/interp/c-util.
o
Compiling /root/axiom/obj/linux/interp/g-util.lsp.
; (DEFUN |reshape| ...) is being compiled.
;; Warning: The variable |b| is not used.
; (DEFUN |update| ...) is being compiled.
;; The variable /VERSION is undefined.
;; The compiler will assume this variable is a global.
;; The variable /WSNAME is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |spadThrow| ...) is being compiled.
;; The variable |$interpOnly| is undefined.
;; The compiler will assume this variable is a global.
;; The variable |$mapName| is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |semchkProplist| ...) is being compiled.
;; Warning: The variable |val| is not used.
; (DEFUN |leftTrim| ...) is being compiled.
;; The variable |$blank| is undefined.
;; The compiler will assume this variable is a global.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling /root/axiom/obj/linux/interp/g-util.o.
Loading /root/axiom/obj/linux/interp/g-util.o
start address -T 0x2088000 Finished loading
/root/axiom/obj/linux/interp/g-util.
o
Finished loading /root/axiom/obj/linux/interp/makedep.lisp
Can't allocate buffer for /root/axiom/obj/linux/bin/lisp
make[3]: *** [/root/axiom/obj/linux/bin/depsys] Error 1
make[3]: Leaving directory `/root/axiom/src/interp'
make[2]: *** [interpdir] Error 2
make[1]: *** [srcdir] Error 2
make[2]: Leaving directory `/root/axiom/src'
make[1]: Leaving directory `/root/axiom'
make: *** [all] Error 2
/root/axiom#

\start
Date: 12 Oct 2004 09:59:25 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: [Gcl-devel] Re: GCL on Zaurus SL-6000 under Debian

Greetings!

Bill Page writes:

> Camm,
> 
> On Monday, October 11, 2004 12:34 PM you wrote:
> >
> > I think you've pinned it here.  The virtual memory size
> > of the gcl default build is 81Mb, and you only have 62.
> > ...  
> > The default hole size is 1/10 MAXPAGES, which with the
> > default maxpage setting is 52Mb.  It is not actually in
> > use until allocated, but the space must be available
> > nonetheless.  Not sure how tiny axiom itself can be made,
> > but you can shrink the hole size, giving you finer grained
> > increments to the growing heap at the expense of gc time,
> > if things really get tight.
> 
> So, if I set --enable-maxpage=64*1024, then the default
> hole size would be --enable-holepage=6*1024, right? How
> small can I practically make it?
>  

You can set it to whatever you want with
--enable-holepage=.... ./configure --help gives all the options.  If a
heap grows from x to y with holepage z, a gc will be triggered at
least (y-x)/z times.

> > Wondering if you can just setup a swapfile over nfs to
> > see if the default binary will work for you.
> 
> I am willing to try but I have never done this. Can you
> given me a few (explicit) tips how to proceed? It is
> also apparently possible for me to connect a usb disk
> drive to this BIG MACHINE in the small box (: Yes, I am
> very impressed by the SL-6000! :) There is a nice little
> 40 Gbyte drive that runs directly off the usb power for
> about $200. Perhaps I will run down to the store when
> it is open again tomorrow...
> 

See my previous post re: nbd.  I think there is a good howto on the
net.  Please write back if you don't find it and I'll take a look.

> Maybe I should just admit that running Axiom isn't (quite)
> practical on this system unless I can add swap space?
> But as a continued challenge, I note that I can run Clisp
> and maxima under Clisp in much less space without swap.
> 
        
This is something we can work on if we agree it is a priority.  GCL
has recently redesigned its default memory layout parameters for
speed.  We are therefore a bit more generous with allocations than we
used to be, but still small relative to cmucl and the like, I think.
two word cons, copying gc algorithm for all types, etc. provide quite
a bit of room for shrinkage.  We've tried to aim for the best
compromise for today's average computer.

> > > ... 
> > > So, anyway I am now running an Axiom build with 
> > > 
> > > # ./configure --enable-vssize=65536*2 --disable-statsysbfd \
> > >   --enable-locbfd --enable-maxpage=64*1024
> > > 
> > > I will let you know how (if) it finishes some time tomorrow.
> > > 
> > 
> > You probably won't succeed, but might just luck out.  The
> > AXIOMsys virtual memory size is actually a little less than
> > the default gcl vmsize, as it shaves off 4k pages from the
> > relocatable area to more than compensate for the expanded
> > number of pages for cells:
> >
> 
> Well you were right. The build stopped apparently at the point
> were it was about to create depsys (it built bootsys ok). See
> the build log below. Does the message "Can't allocate buffer"
> tell you anything specific about memory?
>  

Well, that you are out of it :-)  You failed at mmaping the space for
the final image save in unexec.

> > ... 
> > I get 74Mb.  Can you get some swap somewhere?  My test arm
> > machine has the same amount of ram, but generous swap at 256M,
> > which is certainly overkill for the present purpose.
> >
> 
> Yes, tomorrow.
> 
> Regards,
> Bill Page.
> 

Take care,

> -------
> 
> tail of build.log:
> 
> ...
> Loading /root/axiom/obj/linux/interp/c-util.o
> start address -T 0x2064000 Finished loading
> /root/axiom/obj/linux/interp/c-util.
> o
> Compiling /root/axiom/obj/linux/interp/g-util.lsp.
> ; (DEFUN |reshape| ...) is being compiled.
> ;; Warning: The variable |b| is not used.
> ; (DEFUN |update| ...) is being compiled.
> ;; The variable /VERSION is undefined.
> ;; The compiler will assume this variable is a global.
> ;; The variable /WSNAME is undefined.
> ;; The compiler will assume this variable is a global.
> ; (DEFUN |spadThrow| ...) is being compiled.
> ;; The variable |$interpOnly| is undefined.
> ;; The compiler will assume this variable is a global.
> ;; The variable |$mapName| is undefined.
> ;; The compiler will assume this variable is a global.
> ; (DEFUN |semchkProplist| ...) is being compiled.
> ;; Warning: The variable |val| is not used.
> ; (DEFUN |leftTrim| ...) is being compiled.
> ;; The variable |$blank| is undefined.
> ;; The compiler will assume this variable is a global.
> End of Pass 1.
> End of Pass 2.
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
> Finished compiling /root/axiom/obj/linux/interp/g-util.o.
> Loading /root/axiom/obj/linux/interp/g-util.o
> start address -T 0x2088000 Finished loading
> /root/axiom/obj/linux/interp/g-util.
> o
> Finished loading /root/axiom/obj/linux/interp/makedep.lisp
> Can't allocate buffer for /root/axiom/obj/linux/bin/lisp
> make[3]: *** [/root/axiom/obj/linux/bin/depsys] Error 1
> make[3]: Leaving directory `/root/axiom/src/interp'
> make[2]: *** [interpdir] Error 2
> make[1]: *** [srcdir] Error 2
> make[2]: Leaving directory `/root/axiom/src'
> make[1]: Leaving directory `/root/axiom'
> make: *** [all] Error 2
> /root/axiom#

\start
Date: Tue, 12 Oct 2004 12:19:13 -0400
From: Bill Page
To: Martin Rubey
Subject: pamphlet support on MathAction

Martin,

I am sorry that I do not have anything integrated with
MathAction yet. I ran into a few problems with my modifications
of the l2h (latex to html) noweave -filter and am still
making changes to fix this before adding it to LatexWiki.

In some cases the internal HTML linkages created by
noweave mess up the selected pass thru of the Latex
coding like \begin{equation} and \begin{axiom} because
noweave assume that the output of the l2h filter will be
*pure* html with nothing "strange" embedded like LaTeX
coding. The LatexWiki html+latex document type is a
little strange in that it permits (expects?) the LaTeX
coding just to be inserted in the HTML even though the
the syntax of these two languages is not really compatible.

There are also related problems about how l2h likes to
convert \ref{} to equation \label{} versus the way that
LatexWiki is doing it now. LatexWiki insists on renumbering
equations and that is not compatible with the links that
were earlier inserted by l2h. Plus the insertion of html
anchors for the equations is messed up by the way that
I coded the pass thru of LaTeX coding.

I think what I need to do is have the l2h filter wrap the
LaTeX in a special "html-like" tag e.g.

  <latex>
  \begin{equation}
  ...
  \end{equation}

  Some paragraph

  \begin{axiom}
  ...
  \end{axiom}
  </latex>

Then (hopefully) the rest of the noweave indexing mechanism
wont insist on inserting html inside these html tags.

Anyway, I will be away at a meeting (and short vacation)
for the next 10 days so don't expect much progress until
later this month.

Regards,
Bill Page.

> -----Original Message-----
> From: Martin Rubey [mailto:Martin Rubey] 
> Sent: Tuesday, October 12, 2004 5:47 AM
> To: Bill Page
> Subject: RE: SuchThat
> 
> 
> Bill Page writes:
> 
>  > Now would be a good time to do it - lots of space 
>  > available on MathAction
>  > :)
> 
> Do you have (a maybe preliminary version of) pamphlet-support 
> available already?

\start
Date: Tue, 12 Oct 2004 10:21:44 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: pamphlet support on MathAction

Bill Page [Bill Page] wrote:
> Martin,
> 
> I am sorry that I do not have anything integrated with
> MathAction yet. I ran into a few problems with my modifications
> of the l2h (latex to html) noweave -filter and am still
> making changes to fix this before adding it to LatexWiki.
> 
> In some cases the internal HTML linkages created by
> noweave mess up the selected pass thru of the Latex
> coding like \begin{equation} and \begin{axiom} because
> noweave assume that the output of the l2h filter will be
> *pure* html with nothing "strange" embedded like LaTeX
> coding. The LatexWiki html+latex document type is a
> little strange in that it permits (expects?) the LaTeX
> coding just to be inserted in the HTML even though the
> the syntax of these two languages is not really compatible.

I have been rewriting the StructuredText document type in the last week
or so, and have decided that html+latex must go away because these two
languages are not compatible.  Specifically, latex can contain less-than
and greater-than symbols, and it is not possible to disentangle latex
=66rom html tags.

I have decided on the following "new" pagetypes:
    
    o stx + latex -- cannot contain html, latex is "higher-priority" so
    that e.g. [$a$] is a wiki link with an equation and $[a]$ is an
    equation with brackets in it (and not a wikilink).  There will also
    be a backend which renders mini-latex (below) to generate printable
    (ps/pdf) output.

    o mini-latex -- just enough latex markup to get stx functionality,
    and will render if passed to latex, but will actually be processed
    by the StructuredText machinery as a new pagetype.  i.e. it will
    know \begin{itemize}, \item, \cite, \tt, \bf, \it, etc and not
    require a preamble.

    o latex -- true latex, will be passed to latex2html or tth for the
    web, pdflatex for printable output.

It is only possible to mix html and latex if we require that latex
escape the characters <>&.  This seems very difficult, especially for
hand-coded latex, but maybe your generator can do it?  I am debating
whether stx+latex needs a true escaping mechanism.  I think we can only
retain html+latex if we require the embedded latex to be escaped
properly.

The hyperref and "hypextra":http://www-ssc.igpp.ucla.edu/~newbury/manual/hy=
pextra.html
packages allow one to embed HTML in latex but require latex-style tags
like \htmladdimg.  (see also tex4ht)

My latest work is here::

    http://bob.mcelrath.org/WikiStructuredText

right now it duplicates the ZWiki functionality.  (These classes will be
added to ZWiki and replace stx.py)  I have not added latex yet.  I hope
by looking at WikiDocument.py and WikiHTML.py it is obvious what to do.

I have much work to do here before getting to latexwiki -- like
integrating the WikiLink mechanism and merging with ZWiki.

> There are also related problems about how l2h likes to
> convert \ref{} to equation \label{} versus the way that
> LatexWiki is doing it now. LatexWiki insists on renumbering
> equations and that is not compatible with the links that
> were earlier inserted by l2h. Plus the insertion of html
> anchors for the equations is messed up by the way that
> I coded the pass thru of LaTeX coding.

I want to use \ref and \label instead.  Hopefully this will make it in
the next release.  But if you beat me to making a patch for this, please
send it along!

> I think what I need to do is have the l2h filter wrap the
> LaTeX in a special "html-like" tag e.g.
> 
>   <latex>
>   \begin{equation}
>   ...
>   \end{equation}
> 
>   Some paragraph
> 
>   \begin{axiom}
>   ...
>   \end{axiom}
>   </latex>
> 
> Then (hopefully) the rest of the noweave indexing mechanism
> wont insist on inserting html inside these html tags.

Even this is treacherous.  A mark of a good markup system is that it has
the proper escaping to write a document about itself.  It is obtuse, but
can you place the string "</latex>" inside a latex block?  It looks like
hypextra does what you propose, but it is incapable of placing </latex>
inside a latex block.

If we can think of nothing better, I would accept enclosing
latex-in-html with <latex> tags.  However I think a better idea would be
<equation> and <axiom> tags.

> Anyway, I will be away at a meeting (and short vacation)
> for the next 10 days so don't expect much progress until
> later this month.

Okay.  ;)  Well, let's see how much I've gotten done when you get back.

P.S. this message will hose ZWiki and LatexWiki because it contains
mock-tags.  I propose also that mail-in messages be stx *without* html.
This is required anyway if we mark-up message quoting with '>'.  i.e. if
the mime-type of the message is text/plain we treat it as text/stx
(since no mailer will generate text/stx).  Alternatively if the email
contains mime multipart/alternative with an HTML section, we can use
that directly.  This points toward comments being independent documents
of the parent -- and each comment could have a different pagetype!

\start
Date: Tue, 12 Oct 2004 15:15:40 -0400
From: Camm Maguire
To: list
Subject: Re: bad lisp build on Fedora

I think you have an old (pre 3.0) gcc.  In which case, you need:

--- h/gmp_wrappers.h	2004-08-16 17:28:20.000000000 +0000
+++ ../gclcvs-2.7.0/h/gmp_wrappers.h	2004-09-07 16:20:49.000000000 +0000
@@ -96,8 +96,8 @@
 
 #define MEM_GMP_CALL(n_,rt_,a_,s_,b_...) \
    GMP_EXTERN_INLINE Join(RF_,rt_) Join(m,a_)(Join(P,n_)(b_)) { \
-           Join(RD_,rt_);\
            int j;\
+           Join(RD_,rt_);\
 	   jmp_gmp=0;\
            if ((j=setjmp(gmp_jmp)))\
               GBC(j);\

Please let me know if problems persist.  This and one other minor
issue might trigger a 2.6.6 soon, if that is not too inconvenient. 

Take care,

Tim Daly writes:

> Camm,
> 
> Attached is a console showing a failure in the GCL build.
> This occurs on Mac OSX and Fedora.
> Can you give me a clue?
> 
> Tim
> 
> 
> =======================================================================
> [gilbert@kalman axiom]$ make
> 0 SPAD=/home/users/gilbert/axiom/mnt/linux SYS=linux SPD=/home/users/gilbert/axiom LSP=/home/users/gilbert/axiom/lsp GCLDIR=/home/users/gilbert/axiom/lsp/gcl-2.6.5 SRC=/home/users/gilbert/axiom/src INT=/home/users/gilbert/axiom/int OBJ=/home/users/gilbert/axiom/obj MNT=/home/users/gilbert/axiom/mnt ZIPS=/home/users/gilbert/axiom/zips TMP=/home/users/gilbert/axiom/obj/tmp SPADBIN=/home/users/gilbert/axiom/mnt/linux/bin INC=/home/users/gilbert/axiom/src/include CCLBASE=/home/users/gilbert/axiom/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /home/users/gilbert/axiom/obj/tmp/trace GCLVERSION=gcl-2.6.5 TANGLE=/home/users/gilbert/axiom/mnt/linux/bin/lib/notangle
> 10 copying /home/users/gilbert/axiom/src/scripts to /home/users/gilbert/axiom/mnt/linux/bin
> 1 making a linux system, PART=cprogs SUBPART=everything
> 2 Environment SPAD=/home/users/gilbert/axiom/mnt/linux SYS=linux SPD=/home/users/gilbert/axiom LSP=/home/users/gilbert/axiom/lsp GCLDIR=/home/users/gilbert/axiom/lsp/gcl-2.6.5 SRC=/home/users/gilbert/axiom/src INT=/home/users/gilbert/axiom/int OBJ=/home/users/gilbert/axiom/obj MNT=/home/users/gilbert/axiom/mnt ZIPS=/home/users/gilbert/axiom/zips TMP=/home/users/gilbert/axiom/obj/tmp SPADBIN=/home/users/gilbert/axiom/mnt/linux/bin INC=/home/users/gilbert/axiom/src/include CCLBASE=/home/users/gilbert/axiom/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /home/users/gilbert/axiom/obj/tmp/trace GCLVERSION=gcl-2.6.5 TANGLE=/home/users/gilbert/axiom/mnt/linux/bin/lib/notangle
> make[1]: Entering directory `/home/users/gilbert/axiom'
> 11 checking directory structure
> 12 Environment: PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib CC=gcc AWK=gawk RANLIB=ranlib TOUCH=touch TAR=tar AXIOMXLROOT=/home/users/gilbert/axiom/mnt/linux/compiler O=o BYE=bye LISP=lsp DAASE=/home/users/gilbert/axiom/src/share XLIB=/usr/X11R6/lib
> 18 making /home/users/gilbert/axiom/src
> make[2]: Entering directory `/home/users/gilbert/axiom/src'
> 1 making /home/users/gilbert/axiom/src/scripts
> make[3]: Entering directory `/home/users/gilbert/axiom/src/scripts'
> 1 making /home/users/gilbert/axiom/src/scripts
> make[3]: Leaving directory `/home/users/gilbert/axiom/src/scripts'
> 17 making /home/users/gilbert/axiom/src/lib
> make[3]: Entering directory `/home/users/gilbert/axiom/src/lib'
> 72 finished making /home/users/gilbert/axiom/src/lib
> make[3]: Leaving directory `/home/users/gilbert/axiom/src/lib'
> make[2]: Leaving directory `/home/users/gilbert/axiom/src'
> 0 PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib CC=gcc AWK=gawk RANLIB=ranlib TOUCH=touch TAR=tar AXIOMXLROOT=/home/users/gilbert/axiom/mnt/linux/compiler O=o BYE=bye LISP=lsp DAASE=/home/users/gilbert/axiom/src/share XLIB=/usr/X11R6/lib
> 10 copying /home/users/gilbert/axiom/src/scripts to /home/users/gilbert/axiom/mnt/linux/bin
> 19 making /home/users/gilbert/axiom/lsp
> make[2]: Entering directory `/home/users/gilbert/axiom/lsp'
> 2 building gcl-2.6.5
> 3 applying EXTRAS patch to h/linux.defs
> patching file linux.defs
> 4 setup ini files for EXTRAS patch
> 6 applying libspad.a patch to unixport/makefile
> patching file makefile
> 7 applying toploop patch to unixport/init_gcl.lsp
> patching file init_gcl.lsp.in
> 11 applying tail-recursive noise patch
> patching file gcl_cmpflet.lsp
> Hunk #1 succeeded at 390 with fuzz 2.
> 12 applying tail-recursive noise patch
> patching file gcl_cmpcall.lsp
> 26 copy gcl_collectfn.lsp to /home/users/gilbert/axiom/obj/linux/lsp/collectfn.lsp
> 26a copy sys-proclaim.lisp to /home/users/gilbert/axiom/obj/linux/lsp/sys-proclaim.lisp
> loading cache ./config.cache
> checking host system type... i686-pc-linux-gnu
> host=i686-pc-linux-gnu
> enable_machine=
> use=386-linux
> checking for gcc... (cached) gcc
> checking whether the C compiler (gcc    ) works... yes
> checking whether the C compiler (gcc    ) is a cross-compiler... no
> checking whether we are using GNU C... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking how to run the C preprocessor... (cached) gcc -E
> checking for gawk... (cached) gawk
> checking system version (for dynamic loading)... checking for makeinfo... (cached) makeinfo
> Linux-2.4.22-1.2115.nptl
> checking for gmp.h... (cached) yes
> checking for __gmpz_init in -lgmp... (cached) yes
> checking for external gmp version... checking for leading underscore in object symbols... no
> checking for GNU ld option -Map... yes
> checking for size of gmp limbs... 4
> checking _SHORT_LIMB... no
> checking _LONG_LONG_LIMB... no
> checking for X... (cached) libraries /usr/X11R6/lib, headers /usr/X11R6/include
> checking for dnet_ntoa in -ldnet... (cached) no
> checking for dnet_ntoa in -ldnet_stub... (cached) no
> checking for gethostbyname... (cached) yes
> checking for connect... (cached) yes
> checking for remove... (cached) yes
> checking for shmat... (cached) yes
> checking for IceConnectionNumber in -lICE... (cached) yes
> -I/usr/X11R6/include
> -L/usr/X11R6/lib
> 
> -lSM -lICE
> checking for main in -lXmu... (cached) yes
> checking for main in -lXt... (cached) yes
> checking for main in -lXext... (cached) yes
> checking for main in -lXaw... (cached) yes
> checking for main in -lX11... (cached) yes
> checking for bfd.h... (cached) yes
> checking for bfd_init in -lbfd... (cached) yes
> checking if need to define CONST for bfd... no
> checking for useable bfd_boolean... yes
> checking size of long... (cached) 4
> checking sizeof struct contblock... 8
> checking for endian.h... (cached) yes
> checking endianness... little
> checking for sbrk... yes
> checking for randomized sbrk... yes
> checking for randomized brk remedy... yes
> checking finding DBEGIN... got 0x8000000
> checking finding CSTACK_ADDRESS... got -1075197276
> checking sizeof long long int... yes
> checking for pagewidth... 12
> checking for getcwd... (cached) yes
> checking for getwd... (cached) yes
> checking for uname... (cached) yes
> checking for gettimeofday... (cached) yes
> checking for sys/ioctl.h... (cached) yes
> checking for elf.h... (cached) yes
> checking for elf_abi.h... (cached) no
> checking for BSDgettimeofday... (cached) no
> checking for gettimeofday... (cached) yes
> checking for gettimeofday declaration... present
> checking for sin in -lm... (cached) yes
> checking for main in -lmingwex... (cached) no
> checking for math.h... (cached) yes
> checking for values.h... (cached) yes
> checking for float.h... (cached) yes
> checking for isnormal... yes
> checking for isfinite... yes
> checking for sockets... checking for connect... (cached) yes
> checking for gethostbyname... (cached) yes
> checking for readline/readline.h... (cached) yes
> checking for main in -lreadline... (cached) yes
> checking for rl_completion_matches in -lreadline... (cached) no
> checking For network code for nsocket.c... yes
> checking check for listen using fcntl... yes
> checking for profil... (cached) yes
> checking for setenv... (cached) yes
> checking for _cleanup... (cached) no
> checking FIONBIO vs. O_NONBLOCK for nonblocking I/O... O_NONBLOCK
> checking check for SV_ONSTACK... yes
> checking check for SIGSYS... yes
> checking check for SIGEMT... no
> checking for asm/sigcontext.h... (cached) yes
> checking for asm/signal.h... (cached) yes
> checking for sigcontext...... sigcontext in signal.h
> checking for emacs... (cached) /usr/bin/emacs
> checking emacs site lisp directory... /usr/share/emacs/21.3/site-lisp
> checking emacs default.el... /usr/share/emacs/21.3/site-lisp/default.el
> checking emacs info/dir... /usr/share/info/
> checking for tcl/tk... checking for tclsh... (cached) tclsh
> checking for main in -llieee... (cached) no
> not found
> checking alloca... yes
> checking Checking for buggy gcc version from redhat... no
> creating ./config.status
> creating makedefc
> creating windows/gcl.iss
> creating windows/sysdir.bat
> creating windows/install.lsp
> creating h/gclincl.h
> makedefc
> 
> # begin makedefs
> 
> # use=386-linux
> 
> # for main link of raw_gcl
> LIBS=    -lm  -lgmp /usr/lib/libbfd.a /apps/gcc-2.95.3/lib/libiberty.a -lreadline -lncurses
> 
> #The multi precision library stuff
> MPFILES=$(MPDIR)/@MPI_FILE@ $(MPDIR)/libmport.a
> 
> 
> # root for the installation, eg /usr/local
> # This would cause make install to create /usr/local/bin/gcl and
> # /usr/local/lib/gcl-2-??/* with some basic files.
> prefix=/usr/local
> 
> # where to place the info files
> INFO_DIR=/usr/share/info/
> 
> # where to put emacs lisp files.
> EMACS_SITE_LISP=/usr/share/emacs/21.3/site-lisp
> 
> # the default.el file
> EMACS_DEFAULT_EL=/usr/share/emacs/21.3/site-lisp/default.el
> 
> # numerous TCL/TK variables culled from the tkConfig.sh and tclConfig.sh
> # if these are found.
> TK_CONFIG_PREFIX=
> TK_LIBRARY=
> TCL_LIBRARY=
> TK_XINCLUDES=
> TK_INCLUDE=
> TCL_INCLUDE=
> TK_LIB_SPEC=
> TK_BUILD_LIB_SPEC=
> TK_XLIBSW=
> TK_XINCLUDES=
> TCL_LIB_SPEC=
> TCL_DL_LIBS=
> TCL_LIBS=
> 
> NOTIFY=yes
> CC=gcc
> CFLAGS=  -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I$(GCLDIR)/o
> FINAL_CFLAGS=  -Wall -DVOL=volatile -fsigned-char -pipe 
> NIFLAGS=  -Wall -DVOL=volatile -fsigned-char -pipe   -I$(GCLDIR)/o
> O3FLAGS=-O3 -fomit-frame-pointer
> O2FLAGS=-O
> 
> RL_OBJS=gcl_readline.o
> 
> RL_LIB=
> 
> MAKEINFO=makeinfo
> 
> FLISP=saved_gcl
> SYSTEM=gcl
> BUILD_BFD=
> GMPDIR=gmp3
> X_LIBS= -L/usr/X11R6/lib -lXmu -lXt -lXext -lXaw -lX11
> X_CFLAGS= -I/usr/X11R6/include
> 
> PROCESSOR_FLAGS=
> 
> EXTRA_LOBJS=
> LEADING_UNDERSCORE=
> GNU_LD=1
> add-defs1 386-linux
> using 386-linux.defs
> make[3]: Entering directory `/home/users/gilbert/axiom/lsp/gcl-2.6.5'
> cat h/config.h | sed -e "1,/Begin for cmpincl/d" \
> 	-e "/End for cmpinclude/,50000d" > tmpx
> echo -e '#include "h/config.h"\n#ifdef SGC\n"#define SGC"\n#else\n"#undef SGC"\n#endif' | cpp 2>/dev/null| grep -v '^ *$' | tail -1l | tr -d '"' >>tmpx
> cat h/cmpincl1.h h/gclincl.h h/compbas.h h/enum.h h/mgmp.h h/object.h h/vs.h h/bds.h h/frame.h h/lex.h h/eval.h    h/funlink.h h/att_ext.h h/new_decl.h h/compbas2.h h/compat.h h/cmponly.h o/regexp.h h//protoize.h >> tmpx
> ./xbin/move-if-changed mv tmpx h/cmpinclude.h
> tmpx and h/cmpinclude.h were not the same.
> ln tmpx h/cmpinclude.h
> ./xbin/move-if-changed cp h/cmpinclude.h o/cmpinclude.h
> h/cmpinclude.h and o/cmpinclude.h were not the same.
> ln h/cmpinclude.h o/cmpinclude.h
> (cd bin; make all)
> make[4]: Entering directory `/home/users/gilbert/axiom/lsp/gcl-2.6.5/bin'
> make[4]: Nothing to be done for `all'.
> make[4]: Leaving directory `/home/users/gilbert/axiom/lsp/gcl-2.6.5/bin'
> make mpfiles
> make[4]: Entering directory `/home/users/gilbert/axiom/lsp/gcl-2.6.5'
> make[4]: Nothing to be done for `mpfiles'.
> make[4]: Leaving directory `/home/users/gilbert/axiom/lsp/gcl-2.6.5'
> rm -f o/cmpinclude.h ; cp h/cmpinclude.h o
> (cd o; make all)
> make[4]: Entering directory `/home/users/gilbert/axiom/lsp/gcl-2.6.5/o'
> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/home/users/gilbert/axiom/lsp/gcl-2.6.5/o -I../h -I../gcl-tk -E eval.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > eval.ini
> echo '#include "make-decl.h"' > foo.c
> cat main.ini alloc.ini gbc.ini bitop.ini typespec.ini eval.ini macros.ini lex.ini bds.ini frame.ini predicate.ini reference.ini assignment.ini bind.ini let.ini conditional.ini block.ini iteration.ini mapfun.ini prog.ini multival.ini catch.ini symbol.ini cfun.ini cmpaux.ini package.ini big.ini number.ini num_pred.ini num_comp.ini num_arith.ini num_sfun.ini num_co.ini num_log.ini num_rand.ini earith.ini character.ini sequence.ini list.ini hash.ini array.ini string.ini regexpr.ini structure.ini toplevel.ini file.ini read.ini backq.ini print.ini format.ini pathname.ini unixfsys.ini unixfasl.ini error.ini unixtime.ini unixsys.ini unixsave.ini funlink.ini plt.ini fat_string.ini ./run_process.ini nfunlink.ini usig.ini usig2.ini utils.ini makefun.ini sockets.ini gmp_wrappers.ini clxsocket.ini init_pari.ini nsocket.ini ./sfasl.ini /home/users/gilbert/axiom/obj/linux/lib/cfuns-c.ini /home/users/gilbert/axiom/obj/linux/lib/sockio-c.ini gcl_readline.ini >> foo.c
> gcc -E -I../h foo.c | sed -n -e '/#/d' -e '/DO_/d' -e '/[a-zA-Z;]/p' > ../h/new_decl.h
> rm foo.c
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/home/users/gilbert/axiom/lsp/gcl-2.6.5/o -I../h -I../gcl-tk main.c  
> In file included from ../h/../h/notcomp.h:289,
>                  from ../h/include.h:71,
>                  from main.c:49:
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_add':
> ../h/../h/gmp_wrappers.h:111: parse error before `int'
> ../h/../h/gmp_wrappers.h:111: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h:111: (Each undeclared identifier is reported only once
> ../h/../h/gmp_wrappers.h:111: for each function it appears in.)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_add_ui':
> ../h/../h/gmp_wrappers.h:112: parse error before `int'
> ../h/../h/gmp_wrappers.h:112: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_sub':
> ../h/../h/gmp_wrappers.h:113: parse error before `int'
> ../h/../h/gmp_wrappers.h:113: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_sub_ui':
> ../h/../h/gmp_wrappers.h:114: parse error before `int'
> ../h/../h/gmp_wrappers.h:114: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_mul':
> ../h/../h/gmp_wrappers.h:115: parse error before `int'
> ../h/../h/gmp_wrappers.h:115: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_mul_si':
> ../h/../h/gmp_wrappers.h:116: parse error before `int'
> ../h/../h/gmp_wrappers.h:116: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_mul_2exp':
> ../h/../h/gmp_wrappers.h:117: parse error before `int'
> ../h/../h/gmp_wrappers.h:117: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_neg':
> ../h/../h/gmp_wrappers.h:118: parse error before `int'
> ../h/../h/gmp_wrappers.h:118: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_tdiv_qr':
> ../h/../h/gmp_wrappers.h:119: parse error before `int'
> ../h/../h/gmp_wrappers.h:119: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_fdiv_q_2exp':
> ../h/../h/gmp_wrappers.h:120: parse error before `int'
> ../h/../h/gmp_wrappers.h:120: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_and':
> ../h/../h/gmp_wrappers.h:122: parse error before `int'
> ../h/../h/gmp_wrappers.h:122: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_xor':
> ../h/../h/gmp_wrappers.h:123: parse error before `int'
> ../h/../h/gmp_wrappers.h:123: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_ior':
> ../h/../h/gmp_wrappers.h:124: parse error before `int'
> ../h/../h/gmp_wrappers.h:124: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_com':
> ../h/../h/gmp_wrappers.h:125: parse error before `int'
> ../h/../h/gmp_wrappers.h:125: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_init':
> ../h/../h/gmp_wrappers.h:127: parse error before `int'
> ../h/../h/gmp_wrappers.h:127: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_set':
> ../h/../h/gmp_wrappers.h:128: parse error before `int'
> ../h/../h/gmp_wrappers.h:128: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_set_ui':
> ../h/../h/gmp_wrappers.h:129: parse error before `int'
> ../h/../h/gmp_wrappers.h:129: `j' undeclared (first use in this function)
> ../h/../h/gmp_wrappers.h: In function `m__gmpz_set_si':
> ../h/../h/gmp_wrappers.h:130: parse error before `int'
> ../h/../h/gmp_wrappers.h:130: `j' undeclared (first use in this function)
> make[4]: *** [main.o] Error 1
> make[4]: Leaving directory `/home/users/gilbert/axiom/lsp/gcl-2.6.5/o'
> make[3]: *** [unixport/saved_pre_gcl] Error 2
> make[3]: Leaving directory `/home/users/gilbert/axiom/lsp/gcl-2.6.5'
> /bin/sh: line 1: unixport/saved_gcl: No such file or directory
> make[2]: *** [gcldir] Error 127
> make[2]: Leaving directory `/home/users/gilbert/axiom/lsp'
> make[1]: *** [lspdir] Error 2
> make[1]: Leaving directory `/home/users/gilbert/axiom'
> make: *** [all] Error 2
> [gilbert@kalman axiom]$ 

\start
Date: Wed, 13 Oct 2004 10:28:26 +0000
From: Martin Rubey
To: Bob McElrath
Subject: Re: pamphlet support on MathAction
Cc: Bill Page

Dear B & B,

Bob McElrath writes:
 > Bill Page [Bill Page] wrote:
 > > Martin,
 > > 
 > > I am sorry that I do not have anything integrated with MathAction yet. I
 > > ran into a few problems with my modifications of the l2h (latex to html)
 > > noweave -filter and am still making changes to fix this before adding it
 > > to LatexWiki.

I do understand now that it is indeed a major effort. In fact, I was quite
astonished about your approach: I would have added a "pamphlet" style that
accepts pamphlet files only, generates the latex via the document command, then
the html via l2h or latex2html or hevea or whatever. (hevea would be an
especially nice option: the pictures take a long time to load)

So, in short, I think that Bob's approach is the one to go. By the way: also
the dollar-sign poses problems in StructuredText+LaTeX and has to be escaped in
single-quoted text...

 > I have decided on the following "new" pagetypes:
 >     
 >     o stx + latex -- cannot contain html, latex is "higher-priority" so that
 >     e.g. [$a$] is a wiki link with an equation and $[a]$ is an equation with
 >     brackets in it (and not a wikilink).  There will also be a backend which
 >     renders mini-latex (below) to generate printable (ps/pdf) output.

What's stx?

 >     o latex -- true latex, will be passed to latex2html or tth for the
 >     web, pdflatex for printable output.

I would like to have another pagestyle: 

       o pamphlet, which is passed through document, then latex2html or
       whatever. Note that it is important that pamphlet file writers cannot
       use StructuredText stuff or WikiLinks: The pamphlet files need to
       generate standalone dvi, ps and pdf, too. Thus, an author who wishes to
       refer to other files should use hyperref! I suspect that hyperref and
       latex2html work together nicely.

I don't see any point in mixing html and latex.

 > The hyperref and
 > "hypextra":http://www-ssc.igpp.ucla.edu/~newbury/manual/hypextra.html
 > packages allow one to embed HTML in latex but require latex-style tags like
 > \htmladdimg.  (see also tex4ht)

Ah I didn't know that. So, if you must, you can.

Thanks again for all your work! I suspect that without you the Axiom community
wouldn't be anywhere close to to where it is now!

\start
Date: Wed, 13 Oct 2004 05:00:48 -0400
From: Bill Page
To: Martin Rubey, Bob McElrath
Subject: RE: pamphlet support on MathAction

Martin,

On Wednesday, October 13, 2004 6:28 AM you wrote:
> > Bill Page [Bill Page] wrote:
> > > Martin,
> > > 
> > > I am sorry that I do not have anything integrated with 
> > > MathAction yet. I ran into a few problems with my
> > > modifications of the l2h (latex to html)noweave -filter
> > > and am still making changes to fix this before adding it
> > > to LatexWiki.
> 
> I do understand now that it is indeed a major effort. In 
> fact, I was quite astonished about your approach: I would
> have added a "pamphlet" style that accepts pamphlet files
> only, generates the latex via the document command, then
> the html via l2h or latex2html or hevea or whatever.

But that *is* almost what I am doing. What you call 'document'
is just noweave with a couple of Axiom specific options. l2h
is called as a filter from inside noweave to do the html
conversion. But l2h does not do a reasonable job of converting
equations to html. So what I decided was to use those features
of LatexWiki that already do essentially just this part of the
LaTeX conversion alone. The output of my modified l2h filter is
just the HTML+Latex format of LatexWiki.

> (hevea would be an especially nice option: the pictures take
> a long time to load)

It is true that the LaTeX generated images take a comparatively
long time to load. But most people seem to think that hevea
does a pretty awful job of converting LaTeX equations to HTML.
The fact that it (sort of) does it at all is a kind of miracle
since HTML was not designed to display mathematics. That is
the function of the mathML extension of the language. The *best*
why would be to convert LaTeX equations to mathML. But mathML
is still not supported widely and might not really be identical
to the LaTeX generated result that everyone expects.

> 
> So, in short, I think that Bob's approach is the one to go.

I agree in the long run. But it will take some time to get
there and then to add the Axiom and Reduce functionality etc.
Another few days of my time (when I get time) will probably
be all that is needed to get the current approach working.
 
> By the way: also the dollar-sign poses problems in
> StructuredText+LaTeX and has to be escaped in
> single-quoted text...

Yes. But not such special escaping will be required in
the pamphlet files themselves - it is only necessary
internally between the l2h filter and the LatexWiki
HTML+Latex format.

\start
Date: Wed, 13 Oct 2004 11:22:09 +0000
From: Martin Rubey
To: Bill Page
Subject: RE: pamphlet support on MathAction
Cc: Bob McElrath

Dear Bill,

Bill Page writes:
 > Martin,
 > 
 > On Wednesday, October 13, 2004 6:28 AM Martin wrote:

 > > I do understand now that it is indeed a major effort. In fact, I was quite
 > > astonished about your approach: I would have added a "pamphlet" style that
 > > accepts pamphlet files only, generates the latex via the document command,
 > > then the html via l2h or latex2html or hevea or whatever.
 > 
 > But that *is* almost what I am doing. 

OK, it seems that I did not understand... sorry. 

 > What you call 'document' is just noweave with a couple of Axiom specific
 > options. l2h is called as a filter from inside noweave to do the html
 > conversion.

Yes, I know, but I keep confusing the four possibilities in
{no,}{weave,tangle} ...

 > But l2h does not do a reasonable job of converting equations to html. So
 > what I decided was to use those features of LatexWiki that already do
 > essentially just this part of the LaTeX conversion alone. The output of my
 > modified l2h filter is just the HTML+Latex format of LatexWiki.

Well, but wouldn't it be easy to forget about the equations for a start? It
would be useable, wouldn't it. Making it pretty would be nice, but maybe that
can wait?

 > > (hevea would be an especially nice option: the pictures take
 > > a long time to load)
 > 
 > It is true that the LaTeX generated images take a comparatively long time to
 > load. But most people seem to think that hevea does a pretty awful job of
 > converting LaTeX equations to HTML.  

Yes, but with the pictures I simply cannot use it from my home computer... So
I'd prefer to have both possibilities :-)

 > The fact that it (sort of) does it at all is a kind of miracle since HTML
 > was not designed to display mathematics. That is the function of the mathML
 > extension of the language. The *best* why would be to convert LaTeX
 > equations to mathML. But mathML is still not supported widely and might not
 > really be identical to the LaTeX generated result that everyone expects.

Yes.

 > > So, in short, I think that Bob's approach is the one to go.
 > 
 > I agree in the long run. But it will take some time to get there and then to
 > add the Axiom and Reduce functionality etc.  Another few days of my time
 > (when I get time) will probably be all that is needed to get the current
 > approach working.

OK, great!

\start
Date: Wed, 13 Oct 2004 04:10:20 -0700
From: Bob McElrath
To: Martin Rubey
Subject: Re: pamphlet support on MathAction
Cc: Bill Page


--Bn2rw/3z4jIqBvZU

Martin Rubey [Martin Rubey] wrote:
> Bill Page writes:
>  > It is true that the LaTeX generated images take a comparatively long time to
>  > load. But most people seem to think that hevea does a pretty awful job of
>  > converting LaTeX equations to HTML.  
> 
> Yes, but with the pictures I simply cannot use it from my home computer... So
> I'd prefer to have both possibilities :-)

Why?  Too slow?

To answer another question: stx is a simplified wiki-like markup
suitable for wikis and adding latex to email communications.  It is what
latexwiki is built around.

I'm going as fast as I can but this is a large, and necessary rewrite.
I have my first iteration of this new code working::

    http://mcelrath.org:9675/newstx/

and it's available in my darcs repository::

    http://bob.mcelrath.org/darcs/zwiki-testing

This defines a new page type "Structured Text 2" upon which the new
"Structured Text + LaTeX" will be based.

I gather you guys just want to use my equation rendering though, right?
I'd be happy to separate that out to make it more useful to you.  Also
if you need assistance creating all these pagetypes, I'd be happy to
advise...

\start
Date: Wed, 13 Oct 2004 15:55:46 -0400
From: Bill Page
To: Camm Maguire
Subject: Axiom on Zaurus SL-6000 under Debian - success!
Cc: Michael Koehne

With the help of Camm and Michael I have finally succeeded
in building Axiom on Zaurus! Needless to say, it actually
turned out to be really much easier than the path I took.

The problem in the end was just MEMORY - swap memory to
be specific. I considered the options to use nfs or an
external usb disk drive, but in the end I decided just to
put the swap on a compact flash card. This was something
that was not highly recommended in the Zaurus forums, but
it is working great for me.

So what I have is this:

  Zaurus SL-6000
    (the older ZL-5600 would also probably work)
  1 Gbyte. SD memory card
  256 Mbyte Ultra II CF memory card

The Ultra II is a new faster (10 Mbyte/sec) version of CF
that also uses less power.

If you think that a Gbyte is more than enough beware that
what you want to do with this machine will probably change
as you learn more about it. Larger SD and CF cards are
already available. By Christmas 2 Gbyte SD and 4 Gbyte CF
ultra cards might well be available for what I paid for
the above.

Debian and the entire development environment is on the
SD card and nearly fills it. 128 Mbyte of the CF card is
dedicated to swap space. But that is considerable overkill
since the swap space never exceeded about 15 Mbytes during
the build even though I was periodically using other programs
simultaneously on the Zaurus.

The CF card is by default (off-the-shelf) formatted as
a VFAT partition (Windows compatible). I know that unix
people would probably advise reformatting it as an ext2
unix file system. I had to use ext2 on the SD card for
debian itself. But, pleasant surprize, running a swap
file on VFAT seems to work. If it is more inefficient than
ext2, then I can't really tell because CF is pretty slow
anyway. I created the swap file with the command

      dd if=/dev/zero of=/mnt/cf/swap.img bs=1M count=128
      mkswap /mnt/cf/swap.img

The commands that I added to the unix rc5.d startup just
does 

      swapon /mnt/cf/swap.img

The only changes that I made to the Axiom build was to
use --endable-locbfd and --enable-holepage=4*1024 in the
initial GCL build. Then actually allows GCL to fit within
the available real memory of the Zaurus without swapping.
I cannot really say how much this small hole size affected
the build time but I think that because swapping to CF is
likely to be considerably slower than garbage collection
in ram, I think this is probably a good compromise.
Overall I would say that the total build time was probably
about twice as long as it was the first time I ever built
Axiom which was on a 266 MHz pc.

Anyway, none of this re-building was really necessary! All
that was needed was just to add a little swap space. Now
the debian arm binary runs fine. All I had to do was

  apt-get install gcl

and it works! The same is true of Axiom

  apt-get install axiom

Wonderful (of course it took me four days to get to say
that  :) ...

Perhaps it is good to know that *if* one really needed too,
it would be possible to re-build Axiom stand alone on the
Zaurus. Actually with swap space allocated, it runs quite
well in the background and does not interfere (much) with
the PDA functions (email, calendar, etc.) of the normal
Zaurus desktop. All you need is patience and a power supply.

A have to say again that I am really impressed by the
Zaurus SL-6000. It has taken me a few months to realize
that it really is like having a Linux desktop workstation
in your pocket.

  http://pocketworkstation.org

It even comes with a X-window system that lets you run
all X apps locally and/or from an external PC using VNC
via wireless or usb connection. It's fast. There is a nice
minimal windowing system called 'iceWM' but if you are
really crazy nothing would stop you from added KDE or
GNOME. Simply amazing (and terribly addictive if you have
any geek tendencies at all).

Regards,
Bill Page.


On Tuesday, October 12, 2004 9:41 AM Camm Maguire
Camm Maguire wrote:
> 
> I've heard one can also do this using the network block
> device, aka. NBD, but do not (yet) have direct experience
> myself.  It is said to be more reliable.
> 
> Michael Koehne writes:
> 
> > Moin Bill & Camm,
> > 
> > > > Wondering if you can just setup a swapfile over nfs
> > > > to see if the default binary will work for you.
> > 
> > > I am willing to try but I have never done this.
> > 
> >   swap over nfs is not trivial.
> >   The usual trick is to wrap a loop device around the swapfile :
> > 
> >   on server :
> >       dd if=/dev/zero of=/export/zaurus/swap.img bs=1m count=128
> >       mkswap /export/zaurus/swap.img
> >   on zaurus :
> >       mount -t nfs server:/export/zaurus /mnt
> >       /sbin/losetup /dev/loop0 /mnt/swap.img
> >       /sbin/swapon /dev/loop0
> >   to umount :
> >       /sbin/swapoff /dev/loop0
> >       /sbin/losetup -d /dev/loop0
> >       umount /mnt

\start
Date: 13 Oct 2004 16:49:12 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Axiom on Zaurus SL-6000 under Debian - success!
Cc: Michael Koehne

Hi Bill! Great -- good to hear the good news!  Now you've got me
wanting a zaurus ....

Take care,

Bill Page writes:

> With the help of Camm and Michael I have finally succeeded
> in building Axiom on Zaurus! Needless to say, it actually
> turned out to be really much easier than the path I took.
> 
> The problem in the end was just MEMORY - swap memory to
> be specific. I considered the options to use nfs or an
> external usb disk drive, but in the end I decided just to
> put the swap on a compact flash card. This was something
> that was not highly recommended in the Zaurus forums, but
> it is working great for me.
> 
> So what I have is this:
> 
>   Zaurus SL-6000
>     (the older ZL-5600 would also probably work)
>   1 Gbyte. SD memory card
>   256 Mbyte Ultra II CF memory card
> 
> The Ultra II is a new faster (10 Mbyte/sec) version of CF
> that also uses less power.
> 
> If you think that a Gbyte is more than enough beware that
> what you want to do with this machine will probably change
> as you learn more about it. Larger SD and CF cards are
> already available. By Christmas 2 Gbyte SD and 4 Gbyte CF
> ultra cards might well be available for what I paid for
> the above.
> 
> Debian and the entire development environment is on the
> SD card and nearly fills it. 128 Mbyte of the CF card is
> dedicated to swap space. But that is considerable overkill
> since the swap space never exceeded about 15 Mbytes during
> the build even though I was periodically using other programs
> simultaneously on the Zaurus.
> 
> The CF card is by default (off-the-shelf) formatted as
> a VFAT partition (Windows compatible). I know that unix
> people would probably advise reformatting it as an ext2
> unix file system. I had to use ext2 on the SD card for
> debian itself. But, pleasant surprize, running a swap
> file on VFAT seems to work. If it is more inefficient than
> ext2, then I can't really tell because CF is pretty slow
> anyway. I created the swap file with the command
> 
>       dd if=/dev/zero of=/mnt/cf/swap.img bs=1M count=128
>       mkswap /mnt/cf/swap.img
> 
> The commands that I added to the unix rc5.d startup just
> does 
> 
>       swapon /mnt/cf/swap.img
> 
> The only changes that I made to the Axiom build was to
> use --endable-locbfd and --enable-holepage=4*1024 in the
> initial GCL build. Then actually allows GCL to fit within
> the available real memory of the Zaurus without swapping.
> I cannot really say how much this small hole size affected
> the build time but I think that because swapping to CF is
> likely to be considerably slower than garbage collection
> in ram, I think this is probably a good compromise.
> Overall I would say that the total build time was probably
> about twice as long as it was the first time I ever built
> Axiom which was on a 266 MHz pc.
> 
> Anyway, none of this re-building was really necessary! All
> that was needed was just to add a little swap space. Now
> the debian arm binary runs fine. All I had to do was
> 
>   apt-get install gcl
> 
> and it works! The same is true of Axiom
> 
>   apt-get install axiom
> 
> Wonderful (of course it took me four days to get to say
> that  :) ...
> 
> Perhaps it is good to know that *if* one really needed too,
> it would be possible to re-build Axiom stand alone on the
> Zaurus. Actually with swap space allocated, it runs quite
> well in the background and does not interfere (much) with
> the PDA functions (email, calendar, etc.) of the normal
> Zaurus desktop. All you need is patience and a power supply.
> 
> A have to say again that I am really impressed by the
> Zaurus SL-6000. It has taken me a few months to realize
> that it really is like having a Linux desktop workstation
> in your pocket.
> 
>   http://pocketworkstation.org
> 
> It even comes with a X-window system that lets you run
> all X apps locally and/or from an external PC using VNC
> via wireless or usb connection. It's fast. There is a nice
> minimal windowing system called 'iceWM' but if you are
> really crazy nothing would stop you from added KDE or
> GNOME. Simply amazing (and terribly addictive if you have
> any geek tendencies at all).
> 
> Regards,
> Bill Page.
> 
> 
> On Tuesday, October 12, 2004 9:41 AM Camm Maguire
> Camm Maguire wrote:
> > 
> > I've heard one can also do this using the network block
> > device, aka. NBD, but do not (yet) have direct experience
> > myself.  It is said to be more reliable.
> > 
> > Michael Koehne writes:
> > 
> > > Moin Bill & Camm,
> > > 
> > > > > Wondering if you can just setup a swapfile over nfs
> > > > > to see if the default binary will work for you.
> > > 
> > > > I am willing to try but I have never done this.
> > > 
> > >   swap over nfs is not trivial.
> > >   The usual trick is to wrap a loop device around the swapfile :
> > > 
> > >   on server :
> > >       dd if=/dev/zero of=/export/zaurus/swap.img bs=1m count=128
> > >       mkswap /export/zaurus/swap.img
> > >   on zaurus :
> > >       mount -t nfs server:/export/zaurus /mnt
> > >       /sbin/losetup /dev/loop0 /mnt/swap.img
> > >       /sbin/swapon /dev/loop0
> > >   to umount :
> > >       /sbin/swapoff /dev/loop0
> > >       /sbin/losetup -d /dev/loop0
> > >       umount /mnt

\start
Date: Fri, 15 Oct 2004 16:38:23 -0400
From: Tim Daly
To: Camm Maguire
Subject: patch

Camm,

I applied the patch you sent for h/gmp_wrappers.h

and I still get:

make[5]: Leaving directory `/tmp/axiom/lsp/gcl-2.6.5/gmp3'
touch gmp_all
make[4]: Leaving directory `/tmp/axiom/lsp/gcl-2.6.5'
rm -f o/cmpinclude.h ; cp h/cmpinclude.h o
(cd o; make all)
make[4]: Entering directory `/tmp/axiom/lsp/gcl-2.6.5/o'
gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/tmp/axiom/lsp/gcl-2.6.5/o -I../h -I../gcl-tk main.c  
In file included from ../h/notcomp.h:289,
                 from ../h/include.h:71,
                 from main.c:49:
../h/gmp_wrappers.h: In function `m__gmpz_add':
../h/gmp_wrappers.h:111: parse error before `int'
../h/gmp_wrappers.h:111: `j' undeclared (first use in this function)
../h/gmp_wrappers.h:111: (Each undeclared identifier is reported only once
../h/gmp_wrappers.h:111: for each function it appears in.)
../h/gmp_wrappers.h: In function `m__gmpz_add_ui':
../h/gmp_wrappers.h:112: parse error before `int'
../h/gmp_wrappers.h:112: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_sub':
../h/gmp_wrappers.h:113: parse error before `int'
../h/gmp_wrappers.h:113: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_sub_ui':
../h/gmp_wrappers.h:114: parse error before `int'
../h/gmp_wrappers.h:114: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_mul':
../h/gmp_wrappers.h:115: parse error before `int'
../h/gmp_wrappers.h:115: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_mul_si':
../h/gmp_wrappers.h:116: parse error before `int'
../h/gmp_wrappers.h:116: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_mul_2exp':
../h/gmp_wrappers.h:117: parse error before `int'
../h/gmp_wrappers.h:117: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_neg':
../h/gmp_wrappers.h:118: parse error before `int'
../h/gmp_wrappers.h:118: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_tdiv_qr':
../h/gmp_wrappers.h:119: parse error before `int'
../h/gmp_wrappers.h:119: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_fdiv_q_2exp':
../h/gmp_wrappers.h:120: parse error before `int'
../h/gmp_wrappers.h:120: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_and':
../h/gmp_wrappers.h:122: parse error before `int'
../h/gmp_wrappers.h:122: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_xor':
../h/gmp_wrappers.h:123: parse error before `int'
../h/gmp_wrappers.h:123: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_ior':
../h/gmp_wrappers.h:124: parse error before `int'
../h/gmp_wrappers.h:124: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_com':
../h/gmp_wrappers.h:125: parse error before `int'
../h/gmp_wrappers.h:125: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_init':
../h/gmp_wrappers.h:127: parse error before `int'
../h/gmp_wrappers.h:127: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_set':
../h/gmp_wrappers.h:128: parse error before `int'
../h/gmp_wrappers.h:128: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_set_ui':
../h/gmp_wrappers.h:129: parse error before `int'
../h/gmp_wrappers.h:129: `j' undeclared (first use in this function)
../h/gmp_wrappers.h: In function `m__gmpz_set_si':
../h/gmp_wrappers.h:130: parse error before `int'
../h/gmp_wrappers.h:130: `j' undeclared (first use in this function)
main.c: In function `fLbye':
main.c:687: warning: control reaches end of non-void function
make[4]: *** [main.o] Error 1
make[4]: Leaving directory `/tmp/axiom/lsp/gcl-2.6.5/o'
make[3]: *** [unixport/saved_pre_gcl] Error 2
make[3]: Leaving directory `/tmp/axiom/lsp/gcl-2.6.5'
/bin/sh: unixport/saved_gcl: No such file or directory
make[2]: *** [gcldir] Error 127
make[2]: Leaving directory `/tmp/axiom/lsp'
make[1]: *** [lspdir] Error 2
make[1]: Leaving directory `/tmp/axiom'
make: *** [all] Error 2
[root@localhost axiom]# 

\start
Date: 15 Oct 2004 16:27:51 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: patch

Greetings!

Tim Daly writes:

> Camm,
> 
> I applied the patch you sent for h/gmp_wrappers.h
> 
> and I still get:
> 
> make[5]: Leaving directory `/tmp/axiom/lsp/gcl-2.6.5/gmp3'
> touch gmp_all
> make[4]: Leaving directory `/tmp/axiom/lsp/gcl-2.6.5'
> rm -f o/cmpinclude.h ; cp h/cmpinclude.h o
> (cd o; make all)
> make[4]: Entering directory `/tmp/axiom/lsp/gcl-2.6.5/o'
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/tmp/axiom/lsp/gcl-2.6.5/o -I../h -I../gcl-tk main.c  
> In file included from ../h/notcomp.h:289,
>                  from ../h/include.h:71,
>                  from main.c:49:
> ../h/gmp_wrappers.h: In function `m__gmpz_add':
> ../h/gmp_wrappers.h:111: parse error before `int'
> ../h/gmp_wrappers.h:111: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h:111: (Each undeclared identifier is reported only once

I'm shocked.  Are you sure the patch is applied?  Please give me gcc
-v, cpp -I../h main.c, and (perhaps) access to the machine.

Take care,


> ../h/gmp_wrappers.h:111: for each function it appears in.)
> ../h/gmp_wrappers.h: In function `m__gmpz_add_ui':
> ../h/gmp_wrappers.h:112: parse error before `int'
> ../h/gmp_wrappers.h:112: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_sub':
> ../h/gmp_wrappers.h:113: parse error before `int'
> ../h/gmp_wrappers.h:113: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_sub_ui':
> ../h/gmp_wrappers.h:114: parse error before `int'
> ../h/gmp_wrappers.h:114: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_mul':
> ../h/gmp_wrappers.h:115: parse error before `int'
> ../h/gmp_wrappers.h:115: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_mul_si':
> ../h/gmp_wrappers.h:116: parse error before `int'
> ../h/gmp_wrappers.h:116: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_mul_2exp':
> ../h/gmp_wrappers.h:117: parse error before `int'
> ../h/gmp_wrappers.h:117: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_neg':
> ../h/gmp_wrappers.h:118: parse error before `int'
> ../h/gmp_wrappers.h:118: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_tdiv_qr':
> ../h/gmp_wrappers.h:119: parse error before `int'
> ../h/gmp_wrappers.h:119: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_fdiv_q_2exp':
> ../h/gmp_wrappers.h:120: parse error before `int'
> ../h/gmp_wrappers.h:120: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_and':
> ../h/gmp_wrappers.h:122: parse error before `int'
> ../h/gmp_wrappers.h:122: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_xor':
> ../h/gmp_wrappers.h:123: parse error before `int'
> ../h/gmp_wrappers.h:123: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_ior':
> ../h/gmp_wrappers.h:124: parse error before `int'
> ../h/gmp_wrappers.h:124: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_com':
> ../h/gmp_wrappers.h:125: parse error before `int'
> ../h/gmp_wrappers.h:125: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_init':
> ../h/gmp_wrappers.h:127: parse error before `int'
> ../h/gmp_wrappers.h:127: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_set':
> ../h/gmp_wrappers.h:128: parse error before `int'
> ../h/gmp_wrappers.h:128: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_set_ui':
> ../h/gmp_wrappers.h:129: parse error before `int'
> ../h/gmp_wrappers.h:129: `j' undeclared (first use in this function)
> ../h/gmp_wrappers.h: In function `m__gmpz_set_si':
> ../h/gmp_wrappers.h:130: parse error before `int'
> ../h/gmp_wrappers.h:130: `j' undeclared (first use in this function)
> main.c: In function `fLbye':
> main.c:687: warning: control reaches end of non-void function
> make[4]: *** [main.o] Error 1
> make[4]: Leaving directory `/tmp/axiom/lsp/gcl-2.6.5/o'
> make[3]: *** [unixport/saved_pre_gcl] Error 2
> make[3]: Leaving directory `/tmp/axiom/lsp/gcl-2.6.5'
> /bin/sh: unixport/saved_gcl: No such file or directory
> make[2]: *** [gcldir] Error 127
> make[2]: Leaving directory `/tmp/axiom/lsp'
> make[1]: *** [lspdir] Error 2
> make[1]: Leaving directory `/tmp/axiom'
> make: *** [all] Error 2
> [root@localhost axiom]# 

\start
Date: Fri, 15 Oct 2004 20:16:43 -0400
From: Tim Daly
To: Camm Maguire
Subject: re: patch

Camm,

Mea Culpa. The patch was applied but then I did a make clean (by force
of habit) which removed the patched file. I've added the official patch
to the build and it's building smoothly now. Once the axiom build completes
and passes tests here I'll add the patch to the axiom cvs.

Thanks for the quick responses.

\start
Date: Fri, 15 Oct 2004 23:05:47 -0400
From: Tim Daly
To: list
Subject: book

There is an interesting book on identities containing algorithms.
Apparently you can download the entire book for free.
The algorithms are written for Mathematica and Maple but not Axiom.

Check it out:
http://www.cis.upenn.edu/~wilf/AeqB.html

\start
Date: Fri, 15 Oct 2004 23:10:10 -0400
From: Tim Daly
To: list
Subject: book

The axiom cvs now contains a patch for the gmp_wrappers.h compile bug.

\start
Date: Wed, 20 Oct 2004 14:26:40 +0000
From: Martin Rubey
To: list
Subject: numerical integration

Dear Tim,

what's the state of numerical integration? Is there any chance to resurrect
this any time soon?

\start
Date: 20 Oct 2004 09:47:54 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: book

Greetings!

Downloaded this and gave it a quick look.  Might be an interesting
entry point into learning about extending axiom to translate this into
spad.  Should time for this arise, what would be the most useful way
to proceed?

Take care,

Tim Daly writes:

> There is an interesting book on identities containing algorithms.
> Apparently you can download the entire book for free.
> The algorithms are written for Mathematica and Maple but not Axiom.
> 
> Check it out:
> http://www.cis.upenn.edu/~wilf/AeqB.html

\start
Date: Wed, 20 Oct 2004 17:07:15 +0000
From: Martin Rubey
To: Camm Maguire
Subject: Re: book

Camm Maguire writes:
 > Greetings!
 > 
 > Downloaded this and gave it a quick look.  Might be an interesting
 > entry point into learning about extending axiom to translate this into
 > spad.  Should time for this arise, what would be the most useful way
 > to proceed?

It depends a little on your goals.

1. you can translate any given algorithm into a spad package.

2. you could learn more about all this stuff by looking at the work of the
   people at RISC, especially Carsten Schneiders

http://www.risc.uni-linz.ac.at/research/combinat/publications/#cschneid

and Axel Rieses

http://www.risc.uni-linz.ac.at/research/combinat/publications/#ariese

and Markus Schorn

http://www.risc.uni-linz.ac.at/research/combinat/publications/#mschorn

and ...

(difficult)

3. You might simply ask those people (maybe Peter Paule is appropriate) what
   makes sense. Maybe somebody there volunteers to do some work.

4. if you are more interested in providing a framework within Axiom for all
this stuff, you might want to look at 

http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9217

The files involved are combfunc.spad and sum.spad, the latter implements
Gospers Algorithm.

There are certainly other useful possibilities.

\start
Date: Wed, 20 Oct 2004 17:08:06 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: numerical integration

Martin,

>what's the state of numerical integration? Is there any chance to resurrect
>this any time soon?

the numerical algorthms library used to be the NAG library.
if you have the NAG library then all that is needed is for me to
finish the sman (superman) implementation. sman manages socket
connections between processes. the current implementation uses
XDR format streams between the main axiom process and the NAG libs.

if you don't have the NAG libraries then we fall back on the open
source version. i've done some work on this with the lowest level
stuff. the plan is to work toward packages like Octave but it will
take a while. 

\start
Date: Wed, 20 Oct 2004 17:20:16 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: book

Camm,

>Downloaded this and gave it a quick look.  Might be an interesting
>entry point into learning about extending axiom to translate this into
>spad.  Should time for this arise, what would be the most useful way
>to proceed?

Well, first thought is to try to figure out Zielberger's algorithm.
This seems to be the most complete. Axiom already implements Gosper's
algorithm so a useful place to start is to see what was done in that
instance and try to implement something similar.

I've been working my way thru the first few chapters which has required
a lot of background reading on my part because I'm not really up-to-speed
on the various identities. it's been educational but so far has produced
no code from me.

Ideally you'd work on the algorithm as a literate program and I could
learn what you did from the document. But that's only my measure of
a useful way to proceed. Your path may vary :-)

\start
Date: 22 Oct 2004 17:13:44 -0400
From: Camm Maguire
To: Daniel Lakeland
Subject: Re: Bug#277692: axiom graphics missing?

tags 277692 upstream
thanks

Greetings!  Yes, to my understanding, axiom graphics is awaiting the
resurrection of the sman program.

Take care,

Daniel Lakeland writes:

> Package: axiom
> Version: 0.20040831-1
> 
> The draw command does something but it doesn't produce a graph.
> 
> To wit:
> 
>  -> draw(x^2,x=0..2)
>    Compiling function %D with type DoubleFloat -> DoubleFloat
>    Graph data being transmitted to the viewport manager...
>    AXIOM2D data being transmitted to the viewport manager...
>  
>    (2)  TwoDimensionalViewport: "x*x"
>                                                  Type: TwoDimensionalViewport
> 
> It appears as if some development of the graphics code has occurred
> this year, but searching the axiom archives doesn't give a clear
> picture of the status.
> -- 
> Daniel Lakeland

\start
Date: Sat, 23 Oct 2004 14:52:39 +0200
From: Martin Rubey
To: Camm Maguire
Subject: Re: [Axiom Algebra] Layers 22 & 23 missing

Dear Camm,

Regarding the organisation of the summation algorithms: There are currently two
different ways summation algos are called: The package SUMFS FunctionSpaceSum
looks whether Gosper's algo is applicable, if yes, tries it, and if Gosper
succeeds returns the reult. If Gosper is not applicable or fails -- the latter
is the case for sum(1/k,k=0..n) for example -- it falls back to summation$COMBF
which returns
%defsum[summands,dummy_variable,summation_variable,lower_bound,upper_bound].

SUMFS sits in Layer 20, however, I don't know whether this is too interesting.

The package SUMRF RationalFunctionSum (Layer 14, for what its worth) invokes
Gosper for rational functions. (SUMFS does some normalizing first)

The second way summation can be invoked is through the operators %defsum (for
definite summations) and summation (for indefinite summations - no % here...)

The lines 

    evaluate(opsum, isum)
    evaluate(opdsum, iidsum)

in COMBF tell Axiom to use isum$COMBF and iidsum$COMBF to evaluate these
operators. I.e., when Axiom is told to evaluate such an operator, it goes
there. However, in this case, it does not check whether it could apply
Gosper...

The only thing iidsum does is to check whether the bounds are numbers or
not. If yes, it adds the summands, otherwise it calls idsum.

The statements in COMBF

    idsum l ==
      member?(retract(second l)@SE, variables first l) =>
        kernel(opdsum, l)
      first(l) * (fourth rest l - fourth l + 1)

check whether the summands actually contain the summation variable. If yes, the
operator %defsum (opdsum is a variable containing %defsum) is wrapped into a
"kernel", which prevents it from being evaluated again. Otherwise, the obvious
formula applies.

So, the problem occurs if I have an operator %defsum applied to some summand,
but the summand is changed via eval or subst for example. In this case,
sum$SUMFS won't be called, since Axiom doesn't see a function but an
operator. Instead, iidsum will be called -- since the evaluate line tells Axiom
so...

I don't think that this is horribly difficult to fix, but there should be a
clear design, leaving the possibility to integrate other summation algos.


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

A second remark: Note that Zeilbergers Algo does not return a "closed form"
for the sum. It returns a reccurence relation. At the moment, there is no
notion for such a thing in Axiom. For my guessing package (which will return
reccurence relation at times, too), I simply defined an operator

       oprecur := operator("rootof"::Symbol)$CommonOperators

which works for the moment. If somebody is interested, he should think about
programming a recurrence solver...

\start
Date: Mon, 25 Oct 2004 02:17:51 +0000
From: Christopher Chamber
To: list
Subject: Axiom BNF

The Aldor (external C-based compiler) and the Spad (internal lisp compiler)
accept approximately the same language except that Aldor wants trailing
semi-colons and has some extensions/modifications for dealing with the
fact that it has to run standalone.

The BNF in the book or at the aldor.org site should be nearly correct
for the Spad compiler.

\start
Date: Mon, 25 Oct 2004 14:43:59 +0200
From: Ralf Hemmecke
To: Christopher Chamber
Subject: Re: Axiom BNF

This is a multi-part message in MIME format.
--------------020000000408070508050203

As for the semi-colons in Aldor...
For compatibility reasons Aldor has the #pile directive. Try

aldor -fx -laldor xxx.as
xxx

with the attached program. In my case it compiles and prints 8.

Nevertheless, I would not suggest the #pile mode.

Ralf

Christopher Chamber wrote:
> The Aldor (external C-based compiler) and the Spad (internal lisp compiler)
> accept approximately the same language except that Aldor wants trailing
> semi-colons and has some extensions/modifications for dealing with the
> fact that it has to run standalone.
> 
> The BNF in the book or at the aldor.org site should be nearly correct
> for the Spad compiler.


--------------020000000408070508050203
 name="xxx.as"
 filename="xxx.as"

#include "aldor"
#include "aldorio"

#pile

MyDomain(n: Integer): with
    f: % -> Integer
    coerce: Integer -> %
== add
    Rep == Integer
    coerce(a: Integer): % == 
	per a

    f(x: %): Integer == 
	i: Integer := rep x
	return(i+n)

executeIt(): () ==
    import from Integer
    import from MyDomain 1
    n: Integer := 7
    m: MyDomain 1 := n :: MyDomain 1
    stdout << f m << newline

executeIt()

\start
Date: Mon, 25 Oct 2004 08:53:27 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Axiom BNF

On Monday, October 25, 2004 8:44 AM Ralf HEMMECKE wrote:
> ...
> Nevertheless, I would not suggest the #pile mode.
> 

Why?


\start
Date: Mon, 25 Oct 2004 15:52:04 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Axiom BNF

I simply don't like it. When I once programmed in Axiom I was always
confused about how much I have to indent a line so that the scope is
right. I was so happy to learn that Aldor's native mode is more C-like.
Unfortunately, I cannot reproduce some of the problems that made me wish
to have some more syntax than just indentation to specify the scope.

And I never felt that adding braces and semicolons is so much pain.

And maybe some day the Aldor compiler might not support #pile mode anymore.

By the way, are there already any results about distributing the Aldor
compiler with Axiom?

And may I ask back why you are (or why you are not) in favour of SPAD's
#pile mode? One can have a nice indentation also with the braces and
semicolons.

Ralf

Bill Page wrote:
> On Monday, October 25, 2004 8:44 AM Ralf HEMMECKE wrote:
> 
>>...
>>Nevertheless, I would not suggest the #pile mode.
>>
> 
> 
> Why?

\start
Date: Mon, 25 Oct 2004 13:18:02 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Axiom BNF

On Monday, October 25, 2004 9:52 AM Ralf HEMMECKE wrote:
> 
> I simply don't like it. When I once programmed in Axiom I was
> always confused about how much I have to indent a line so that
> the scope is right.

As a matter of style and personal preference, I understand your
view but I don't sympathize. Because of my programming background,
my initial reaction was similar to yours but reading Axiom algebra
code and programming in Python has changed my mind.

> I was so happy to learn that Aldor's native mode is more
> C-like.

As far as I can tell, Aldor supports both modes interchangeably.
If you include braces and semicolons in your code, then it
expects you to continue to do so. But if you omit them and use
standard indentation it is just as happy.

> Unfortunately, I cannot reproduce some of the problems that
> made me wish to have some more syntax than just indentation
> to specify the scope.
> 
> And I never felt that adding braces and semicolons is so much
> pain.

It is not so much that it is a "pain" to add such decorations
but rather that it tends to obscure the structure of the program
and permits a layout style that is too flexible. I think properly
and consistently indented code (as required by SPAD) is easier
to read than most C-like coding styles.

> 
> And maybe some day the Aldor compiler might not support
> #pile mode anymore.
>

That seems to be a choice over which we might have some
influence.
 
> By the way, are there already any results about distributing
> the Aldor compiler with Axiom?
>

As far as I know, none. :(
 
> And may I ask back why you are (or why you are not) in favour 
> of SPAD's #pile mode? One can have a nice indentation also
> with the braces and semicolons.

Using indentation that is syntactically checked by the compiler,
results in a minimal, natural and more expressive 2-d layout
instead of a 1-d serialization that might be (slightly) more
convenient to the compiler. Yes of course I agree that indentation
as a form of "commenting" is not inconsistent with this 1-d
serialization, but in programming language design I am inclined
to favour the dogmatic, rather than permissiveness, for the sake
of consistency and precision.

Since we use 2-d computer displays and all of the editors in
common use respect such 2-d formatting, why not use it in an
essential way in the programming language? Extra braces,
parenthesis, begin-end, do-od, if-fi, and ; at the end of a
statement, etc. now just seems ugly and unnecessary to me. 

Cheers,
Bill Page.

> 
> Bill Page wrote:
> > On Monday, October 25, 2004 8:44 AM Ralf HEMMECKE wrote:
> > 
> >>...
> >>Nevertheless, I would not suggest the #pile mode.
> >>
> > 
> > Why?
> 

\start
Date: Mon, 25 Oct 2004 20:01:11 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: Axiom BNF

I did run into an example:

Consider two nested if statements, where one else branch is missing:

         if cond1 then
           if cond2 then
               bla
               bla
           else
             bla
             bla

versus

         if cond1 then
           if cond2 then
               bla
               bla
         else
           bla
           bla

It only discovered it by luck.

Martin

PS: is there any progress on using the Aldor compiler for compiling domains
that use other Axiom domains?

\start
Date: Mon, 25 Oct 2004 14:39:41 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Axiom BNF

On Monday, October 25, 2004 2:01 PM Martin Rubey wrote:
> 
> I did run into an example:
> 
> Consider two nested if statements, where one else branch is missing:
> 
>          if cond1 then
>            if cond2 then
>                bla1
>                bla2
>            else
>              bla3
>              bla4
> 
> versus
> 
>          if cond1 then
>            if cond2 then
>                bla1
>                bla2
>          else
>            bla3
>            bla4
> 
> It only discovered it by luck.
> 

Of what is this an example? It just seems like two
reasonable examples of indented coding to me.

(I added 1, 2, 3, 4 to bla to be specific.)

In the first case bla1 and bla2 execute if both cond1
and cond2 are true. bla3 and bla4 execute if cond1 is
true and cond2 is false.

In the second case bla1 and bla2 execute if both cond1
and cond2 are true (same as first case) but now bla3 and
bla4 execute if cond1 is false, independent of cond2.
This is clear because the 'else' block has the same
indentation as the first 'if' block. No?

\start
Date: Mon, 25 Oct 2004 22:36:46 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: Axiom BNF

Hi Bill!

here is the real life thing:

              if degree f.factor = 1 then
                Av := -coefficient(f.factor, 0)/leadingCoefficient f.factor
                if Av ~= 0 then
                  res5 := factor(univariate(eval(p3,'A::Symbol,Av)))$GF
                  for g in factors res5 repeat
                    if degree g.factor = 1 then
                      a1v := -coefficient(g.factor, 0)
                              /leadingCoefficient g.factor 

                      res := cons([rat2expr2(xx, ri.function, Av, a1v)
                                   *(coerce(Av-(len+3)*a1v)
                                     +coerce(a1v)*(xx::EXPRR))
                                    **(xx::EXPRR), 
                                   reduce(max, ri.unattainable, 0)
                                     $List(Integer)::NNI], 
                                  res)
                    else
                      a1v := kernel(opalg, [poly2expr(xx, g.factor), xx::EXPRR])
                      output(a1v::OutputForm)$OutputPackage
              else
                a1v := kernel(opalg, [poly2expr(xx, f.factor), xx::EXPRR])
                output(a1v::OutputForm)$OutputPackage

versus

              if degree f.factor = 1 then
                Av := -coefficient(f.factor, 0)/leadingCoefficient f.factor
                if Av ~= 0 then
                  res5 := factor(univariate(eval(p3,'A::Symbol,Av)))$GF
                  for g in factors res5 repeat
                    if degree g.factor = 1 then
                      a1v := -coefficient(g.factor, 0)
                              /leadingCoefficient g.factor 

                      res := cons([rat2expr2(xx, ri.function, Av, a1v)
                                   *(coerce(Av-(len+3)*a1v)
                                     +coerce(a1v)*(xx::EXPRR))
                                    **(xx::EXPRR), 
                                   reduce(max, ri.unattainable, 0)
                                     $List(Integer)::NNI], 
                                  res)
                 else
                    a1v := kernel(opalg, [poly2expr(xx, g.factor), xx::EXPRR])
                    output(a1v::OutputForm)$OutputPackage
              else
                a1v := kernel(opalg, [poly2expr(xx, f.factor), xx::EXPRR])
                output(a1v::OutputForm)$OutputPackage

If you are not careful, the 2 spaces of indentation are easily overlooked...
Of course, your analysis is correct. My point is only, that with braces or
parenthesis or whatever, this mistake wouldn't happen, not to me at least,
since it was clear to me where the else branch should belong, but I simply
missed the indentation. (I think, one if branch was added later, so I had to
reindent the whole thing)

But certainly, this is highly subjective, and therefore it is a real good thing
that you can choose piles or no piles.

\start
Date: Mon, 25 Oct 2004 22:28:03 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Axiom BNF

Martin,

>From code you show below I would say that the problem is not
the placement of the 'else' block but rather the scope of the
'for' block. The second ("versus") part is very likely wrong
because of the reference to index variable g outside the for
loop. Also there is a minor formating error in the second part
because the 'else' block does not have the same indentation as
any preceeding 'if' block. Does the compiler actually compile
the second part without issuing an error?

I am completely sceptical that adding braces would make this
code any more clear or to help locate problems in the algorithm.

Code structure highlighting or folding of indented sections 
such as found in some Python integrated development environments,
e.g. PythonWin, or see

  http://www-106.ibm.com/developerworks/linux/library/l-pide/
  http://www-106.ibm.com/developerworks/linux/library/l-cpyide/

might help to make the structure of the program more readily
apparent. I wonder if anyone has ever done a good emacs mode for
SPAD "pile" highlighting and editing?

You write: "it is a real good thing that you can choose piles
or no piles". On the other hand in the previous message I rather
directly implied that this was a "bad thing". I think having
two different syntaxes for the same language is undesirable.
In my opinion in both programming and in mathematics adopting a
good (efficient, concise, standard, ...) notation is often more
than half the battle.

Regards,
Bill Page.

> -----Original Message-----

> 
> Hi Bill!
> 
> here is the real life thing:
> 
>               if degree f.factor = 1 then
>                 Av := -coefficient(f.factor, 0)/leadingCoefficient
f.factor
>                 if Av ~= 0 then
>                   res5 := =
factor(univariate(eval(p3,'A::Symbol,Av)))$GF
>                   for g in factors res5 repeat
>                     if degree g.factor = 1 then
>                       a1v := -coefficient(g.factor, 0)
>                               /leadingCoefficient g.factor 
> 
>                       res := cons([rat2expr2(xx, ri.function, Av, =
a1v)
>                                    *(coerce(Av-(len+3)*a1v)
>                                      +coerce(a1v)*(xx::EXPRR))
>                                     **(xx::EXPRR), 
>                                    reduce(max, ri.unattainable, 0)
>                                      $List(Integer)::NNI], 
>                                   res)
>                     else
>                       a1v := kernel(opalg, [poly2expr(xx, g.factor),
xx::EXPRR])
>                       output(a1v::OutputForm)$OutputPackage
>               else
>                 a1v := kernel(opalg, [poly2expr(xx, f.factor), =
xx::EXPRR])
>                 output(a1v::OutputForm)$OutputPackage
> 
> versus
> 
>               if degree f.factor = 1 then
>                 Av := -coefficient(f.factor, 0)/leadingCoefficient
f.factor
>                 if Av ~= 0 then
>                   res5 := =
factor(univariate(eval(p3,'A::Symbol,Av)))$GF
>                   for g in factors res5 repeat
>                     if degree g.factor = 1 then
>                       a1v := -coefficient(g.factor, 0)
>                               /leadingCoefficient g.factor 
> 
>                       res := cons([rat2expr2(xx, ri.function, Av, =
a1v)
>                                    *(coerce(Av-(len+3)*a1v)
>                                      +coerce(a1v)*(xx::EXPRR))
>                                     **(xx::EXPRR), 
>                                    reduce(max, ri.unattainable, 0)
>                                      $List(Integer)::NNI], 
>                                   res)
>                  else
>                     a1v := kernel(opalg, [poly2expr(xx, g.factor),
xx::EXPRR])
>                     output(a1v::OutputForm)$OutputPackage
>               else
>                 a1v := kernel(opalg, [poly2expr(xx, f.factor), =
xx::EXPRR])
>                 output(a1v::OutputForm)$OutputPackage
> 
> If you are not careful, the 2 spaces of indentation are 
> easily overlooked...
> Of course, your analysis is correct. My point is only, that 
> with braces or parenthesis or whatever, this mistake wouldn't
> happen, not to me at least, since it was clear to me where the
> else branch should belong, but I simply missed the indentation.
> (I think, one if branch was added later, so I had to reindent
> the whole thing)
> 
> But certainly, this is highly subjective, and therefore it is 
> a real good thing that you can choose piles or no piles.

\start
Date: Tue, 26 Oct 2004 09:38:57 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: Axiom BNF

Dear Bill,

your analysis is of course correct, my only point being, that *I* just don't
*see* the correct amount of indentation. And yes, the first part is correct and
as I made up the second part, I mis-indented the if, so given this snippet, the
compiler would complain (yes, it would). On the other hand, the reference to g
was not there when I discovered the bug, so both snippets were completely
legal.

An emacs mode for editing piled code would be great and should go on the
WishList.

Since we are most unlikely to agree on a "good" style of coding (there are
simply too many very different mathematician-programmers around, some of them
come from a C backgound, some of them like Lisp, others Phython, I know some
who do their stuff in ML) I maintain that it's a good thing to have two possible
syntaxes to choose from.

Personally I'd favour compatibility with Aldor usage, in order to enlarge the
community.

Regarding the original (BNF) discussion: Note that Aldor has some new concepts,
like extend. Furthermore, it seems to me, that in Aldor you can define domains,
categories and functions in places where the Axiom compiler would complain.

\start
Date: Tue, 26 Oct 2004 21:56:33 -0400
From: Tim Daly
To: Camm Maguire
Subject: MAC OSX port failure for GCL

Camm,

Attached is a portion of the console from today. I spent the day trying
to port Axiom to an apple MAC G5 box. I've applied a few of the changes
to the axiom sources but eventually got this failure.

It appears that 
checking host system type... powerpc-apple-darwin7.5.0
is unrecognized. 

What can I do, if anything, to fix this? Does gcl run on a G5 MAC?

Tim


========================================================================
2 building gcl-2.6.5
3 applying EXTRAS patch to h/linux.defs
patching file linux.defs
4 setup ini files for EXTRAS patch
6 applying libspad.a patch to unixport/makefile
patching file makefile
7 applying toploop patch to unixport/init_gcl.lsp
patching file init_gcl.lsp.in
28 applying gmp_wrappers patch
patching file gmp_wrappers.h
11 applying tail-recursive noise patch
patching file gcl_cmpflet.lsp
Hunk #1 succeeded at 390 with fuzz 2.
12 applying tail-recursive noise patch
patching file gcl_cmpcall.lsp
26 copy gcl_collectfn.lsp to /Users/test/mathprog/axiom/obj/MACOSX/lsp/collectfn.lsp
27 copy sys-proclaim.lisp to /Users/test/mathprog/axiom/obj/MACOSX/lsp/sys-proclaim.lisp
creating cache ./config.cache
checking host system type... powerpc-apple-darwin7.5.0
host=powerpc-apple-darwin7.5.0
enable_machine=
Exactly one loader option must be chosen: dlopen=no statsysbfd=yes dynsysbfd=no locbfd=yes custreloc=no
rm -f bin/gcl xbin/gcl
MGCLDIR=`echo /Users/test/mathprog/axiom/lsp/gcl-2.6.5 | sed -e 'sX^\([a-z]\):X/\1Xg'` ; \
GCLDIR=`echo /Users/test/mathprog/axiom/lsp/gcl-2.6.5` ; \
make install-command "INSTALL_LIB_DIR=$GCLDIR" "prefix=$GCLDIR" "BINDIR=$MGCLDIR/unixport"
rm -f /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gcl
(echo '#!/bin/sh' ; \
echo exec /Users/test/mathprog/axiom/lsp/gcl-2.6.5/unixport/ \\ ; \
echo '   -dir' /Users/test/mathprog/axiom/lsp/gcl-2.6.5/unixport/ \\ ; \
echo '   -libdir' /Users/test/mathprog/axiom/lsp/gcl-2.6.5/ \\ ; \
echo '   -eval '\''(setq si::*allow-gzipped-file* t)'\' \\ ;\
! [ -d "" ] || echo '   -eval '\''(setq si::*tk-library* '\"\"')'\' \\;\
echo '     '\"\$@\" ) > /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gcl;
echo '#' other options: -load "/tmp/foo.o" -load "jo.lsp" -eval '"(joe 3)"' >> /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gcl
chmod a+x /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gcl
rm -f /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gclm.bat
if gcc --version | grep mingw >/dev/null 2>&1 ; then (echo '@SET cd='; \
 echo '@SET promp%prompt%'; \
 echo '@PROMPT SET cd'; \
 echo '@CALL>%temp%.\setdir.bat'; \
 echo '@'; \
 echo '% do not delete this line %'; \
 echo '@ECHO off'; \
 echo 'PROMPT %promp'; \
 echo 'FOR %%c IN (CALL DEL) DO %%c %temp%.\setdir.bat'; \
 echo 'set cwd=%cd%'; \
 echo 'set libdir=%cd%\..\lib\gcl-`cat majvers`.`cat minvers`'; \
 echo 'set unixportdir=%libdir%\unixport'; \
 echo 'path %cd%\..\mingw\bin;%PATH%'; \
 echo "start %unixportdir%\.exe -dir %unixportdir% -libdir %libdir% -eval \"(setq si::*allow-gzipped-file* t)\" %1 %2 %3 %4 %5 %6 %7 %8 %9" ) > /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gclm.bat ; fi
rm -f /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gclfinal.bat
if gcc --version | grep -i mingw >/dev/null 2>&1 ; then (echo 'ECHO path %1\mingw\bin;%PATH% > gcli.bat'; \
 echo "ECHO start %1\lib\gcl-`cat majvers`.`cat minvers`\unixport\.exe -dir %1\lib\gcl-`cat majvers`.`cat minvers`\unixport -libdir %1\lib\gcl-`cat majvers`.`cat minvers` -eval \"(setq si::*allow-gzipped-file* t)\" %1 %2 %3 %4 %5 %6 %7 %8 %9 >> gcli.bat" ) > /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gclfinal.bat ; fi
(cd xbin ; cp ../bin/gcl .)
cd cmpnew && make gcl_collectfn.o
../unixport/saved_pre_gcl ../unixport/ -compile gcl_collectfn.lsp
make[4]: ../unixport/saved_pre_gcl: Command not found
make[4]: *** [gcl_collectfn.o] Error 127
make[3]: *** [cmpnew/gcl_collectfn.o] Error 2
/bin/sh: line 1: unixport/saved_gcl: No such file or directory
make[2]: *** [gcldir] Error 127
make[1]: *** [lspdir] Error 2
make: *** [all] Error 2

\start
Date: Tue, 26 Oct 2004 21:17:46 -0400
From: Bill Page
To: Tim Daly
Subject: RE: [Gcl-devel] MAC OSX port failure for GCL

Tim,

I ain't got a MAC ... but I did notice the message:

> Exactly one loader option must be chosen: dlopen=no statsysbfd=yes
> dynsysbfd=no locbfd=yes custreloc=no

in your console output. Does it make sense that you might be
trying to specify both statsysbfd=yes and locbfd=yes? Or perhaps
this is happening by some incorrect default behaviour.

\start
Date: 26 Oct 2004 21:52:30 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: [Gcl-devel] MAC OSX port failure for GCL
Cc: Aurelien Chanudet

Greetings!  This is odd, as the pattern in configure is
powerpc-*-darwin*.  In any case, I think you want --disable-statsysbfd
--enable-locbfd --enable-machine=powerpc-macosx.

Please keep us posted.

Take care,

Tim Daly writes:

> Camm,
> 
> Attached is a portion of the console from today. I spent the day trying
> to port Axiom to an apple MAC G5 box. I've applied a few of the changes
> to the axiom sources but eventually got this failure.
> 
> It appears that 
> checking host system type... powerpc-apple-darwin7.5.0
> is unrecognized. 
> 
> What can I do, if anything, to fix this? Does gcl run on a G5 MAC?
> 
> Tim
> 
> 
> ========================================================================
> 2 building gcl-2.6.5
> 3 applying EXTRAS patch to h/linux.defs
> patching file linux.defs
> 4 setup ini files for EXTRAS patch
> 6 applying libspad.a patch to unixport/makefile
> patching file makefile
> 7 applying toploop patch to unixport/init_gcl.lsp
> patching file init_gcl.lsp.in
> 28 applying gmp_wrappers patch
> patching file gmp_wrappers.h
> 11 applying tail-recursive noise patch
> patching file gcl_cmpflet.lsp
> Hunk #1 succeeded at 390 with fuzz 2.
> 12 applying tail-recursive noise patch
> patching file gcl_cmpcall.lsp
> 26 copy gcl_collectfn.lsp to /Users/test/mathprog/axiom/obj/MACOSX/lsp/collectfn.lsp
> 27 copy sys-proclaim.lisp to /Users/test/mathprog/axiom/obj/MACOSX/lsp/sys-proclaim.lisp
> creating cache ./config.cache
> checking host system type... powerpc-apple-darwin7.5.0
> host=powerpc-apple-darwin7.5.0
> enable_machine=
> Exactly one loader option must be chosen: dlopen=no statsysbfd=yes dynsysbfd=no locbfd=yes custreloc=no
> rm -f bin/gcl xbin/gcl
> MGCLDIR=`echo /Users/test/mathprog/axiom/lsp/gcl-2.6.5 | sed -e 'sX^\([a-z]\):X/\1Xg'` ; \
> GCLDIR=`echo /Users/test/mathprog/axiom/lsp/gcl-2.6.5` ; \
> make install-command "INSTALL_LIB_DIR=$GCLDIR" "prefix=$GCLDIR" "BINDIR=$MGCLDIR/unixport"
> rm -f /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gcl
> (echo '#!/bin/sh' ; \
> echo exec /Users/test/mathprog/axiom/lsp/gcl-2.6.5/unixport/ \\ ; \
> echo '   -dir' /Users/test/mathprog/axiom/lsp/gcl-2.6.5/unixport/ \\ ; \
> echo '   -libdir' /Users/test/mathprog/axiom/lsp/gcl-2.6.5/ \\ ; \
> echo '   -eval '\''(setq si::*allow-gzipped-file* t)'\' \\ ;\
> ! [ -d "" ] || echo '   -eval '\''(setq si::*tk-library* '\"\"')'\' \\;\
> echo '     '\"\$@\" ) > /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gcl;
> echo '#' other options: -load "/tmp/foo.o" -load "jo.lsp" -eval '"(joe 3)"' >> /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gcl
> chmod a+x /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gcl
> rm -f /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gclm.bat
> if gcc --version | grep mingw >/dev/null 2>&1 ; then (echo '@SET cd='; \
>  echo '@SET promp%prompt%'; \
>  echo '@PROMPT SET cd'; \
>  echo '@CALL>%temp%.\setdir.bat'; \
>  echo '@'; \
>  echo '% do not delete this line %'; \
>  echo '@ECHO off'; \
>  echo 'PROMPT %promp'; \
>  echo 'FOR %%c IN (CALL DEL) DO %%c %temp%.\setdir.bat'; \
>  echo 'set cwd=%cd%'; \
>  echo 'set libdir=%cd%\..\lib\gcl-`cat majvers`.`cat minvers`'; \
>  echo 'set unixportdir=%libdir%\unixport'; \
>  echo 'path %cd%\..\mingw\bin;%PATH%'; \
>  echo "start %unixportdir%\.exe -dir %unixportdir% -libdir %libdir% -eval \"(setq si::*allow-gzipped-file* t)\" %1 %2 %3 %4 %5 %6 %7 %8 %9" ) > /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gclm.bat ; fi
> rm -f /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gclfinal.bat
> if gcc --version | grep -i mingw >/dev/null 2>&1 ; then (echo 'ECHO path %1\mingw\bin;%PATH% > gcli.bat'; \
>  echo "ECHO start %1\lib\gcl-`cat majvers`.`cat minvers`\unixport\.exe -dir %1\lib\gcl-`cat majvers`.`cat minvers`\unixport -libdir %1\lib\gcl-`cat majvers`.`cat minvers` -eval \"(setq si::*allow-gzipped-file* t)\" %1 %2 %3 %4 %5 %6 %7 %8 %9 >> gcli.bat" ) > /Users/test/mathprog/axiom/lsp/gcl-2.6.5/bin/gclfinal.bat ; fi
> (cd xbin ; cp ../bin/gcl .)
> cd cmpnew && make gcl_collectfn.o
> ../unixport/saved_pre_gcl ../unixport/ -compile gcl_collectfn.lsp
> make[4]: ../unixport/saved_pre_gcl: Command not found
> make[4]: *** [gcl_collectfn.o] Error 127
> make[3]: *** [cmpnew/gcl_collectfn.o] Error 2
> /bin/sh: line 1: unixport/saved_gcl: No such file or directory
> make[2]: *** [gcldir] Error 127
> make[1]: *** [lspdir] Error 2
> make: *** [all] Error 2

\start
Date: Wed, 27 Oct 2004 11:52:10 -0400
From: Tim Daly
To: David Mentre
Subject: axiom project homepage
Cc: Gilbert Baumslag

David,

I've moved the Axiom homepage pointer on savannah to point to
http://axiom.axiom-developer.org to allow for easier and more frequent
updates. I'm also in the process of updating the pages to conform to
the current reality.

In the process I've reformatted and rewritten the pages to conform to
the style of the CAISS institute (where I work http://www.caissny.org).  
We're working on a second open-source math program called Magnus which 
will eventually work in conjunction with Axiom and we're merging the styles.

The download site has also moved to axiom-developer.org (which is a
machine I personally pay for somewhere on the web). This will give us
better control over file downloads, which will also be brought up to
date over the next few days.

Hope you don't mind the fact that I stepped on your work but I'm
under a bit of pressure here to bring things up to date. My actions
are not intended as a criticism of your contributions, which I greatly
appreciate.

\start
Date: Wed, 27 Oct 2004 20:06:42 +0200
From: David Mentre
To: Tim Daly
Subject: Re: axiom project homepage
Cc: Gilbert Baumslag

Hello Tim,

Tim Daly writes:

> Hope you don't mind the fact that I stepped on your work but I'm
> under a bit of pressure here to bring things up to date. My actions
> are not intended as a criticism of your contributions, which I greatly
> appreciate.

No worry. I haven't been much active on Axiom recently. And regarding
downloads, the download area of savannah is quite difficult to use, so
it is a good idea to move somewhere else.

I'm still hopping to do something useful on Axiom.

\start
Date: Thu, 28 Oct 2004 14:10:32 +0200
From: Martin Rubey
To: list
Subject: axiom project homepage

Dear Bill, David, Tim, *,

the move is OK to me, here are some random comments of various (unordered!)
levels of significance:

* www.axiom-developer.org currently redirects to page.axiom-developer.org. I
  think it would be better to have it point to axiom.axiom-developer.org. One
  is more likely to remember www.axiom-developer.org than
  axiom.axiom-developer.org

* The wiki link on axiom.axiom-developer.org leads to
  page.axiom-developer.org. I think it would be wiser to make
  page.axiom-developer.org/zope/mathaction/FrontPage the main wiki site. To me,
  the material on page.axiom-developer.org/zope/Plone is highly unorganized,
  confusing and not inviting. Is there material on Plone that is missing on the
  mathaction site? If yes, please provide pointers. I volunteer to move it.
  (Please!)

* the new homepage states that CAISS is supporting Axiom now. In what sense?
  This looks like great news!

* Bill, you added two links to Tutorials to the FrontPage. May I move them to
  the Axiom Documentation page? I have the feeling that they really belong
  there and that it scatters the FrontPage a little -- it doesn't fit on one
  screenfull anymore now... Do you think that 
  "Axiom documentation and community" 
  is misleading, i.e. that you wouldn't look there, if you are looking for a
  tutorial? If this is the case, maybe we should rename it to
  "Axiom tutorials, documentation and community"

\start
Date: Thu, 28 Oct 2004 09:44:30 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: axiom project homepage

On Thursday, October 28, 2004 8:11 AM Martin Rubey wrote:

> 
> * www.axiom-developer.org currently redirects to 
> page.axiom-developer.org. I think it would be better
> to have it point to axiom.axiom-developer.org. One
> is more likely to remember www.axiom-developer.org than
> axiom.axiom-developer.org

I agree and have changed the redirect to point to
  axiom.axiom-developer.org

> 
> * The wiki link on axiom.axiom-developer.org leads to
> page.axiom-developer.org. I think it would be wiser to
> make page.axiom-developer.org/zope/mathaction/FrontPage
> the main wiki site. To me, the material on
> page.axiom-developer.org/zope/Plone is highly unorganized,
> confusing and not inviting. Is there material on Plone that 
> is missing on the MathAction site? If yes, please provide
> pointers. I volunteer to move it.
>   (Please!)

I think a direct link to MathAction is a good idea, BUT
I also think /zope/mathaction needs a more prominent link
to /zope/Plone (Axiom Portal).

Yes there are some documents on /zope/Plone that are not
on /zope/mathaction but I am not sure if they belong on
MathAction or not. There are things that Plone does that
the ZWiki software on MathAction can not do such as private
user files and controlled publication, calendar events,
bibliographies etc. There may also be some material on the
test.axiom-developer.org test site that is not on MathAction.

In principle, MathAction is the less controlled environment
because it is an open publicly accessible wiki. In fact, it
is more organized only because Martin has done a great job of
maintaining the content. The Plone Axiom Portal on the other
hand has not had nearly enough attention. I just don't have
enough time to spend on making things look nicer or even
necessarily configuring things to be most efficient. Plone
is very highly configurable. What we have right now on the
Axiom Portal is almost "straight out of the box". If anyone
has the time and is motivated to make the Axiom Portal site
look and work better I would be very happy to provide the
"technical support" - content however is not my strong point.

> 
> * the new homepage states that CAISS is supporting Axiom now. 
> In what sense? This looks like great news!

I also like Tim Daly's plans for soliciting additional
support and sponsorship from other sources. I think we
should include on this list other major commercial developers
of computer algebra software such as MapleSoft and Mathematica.
I don't see any conflict with asking for their support. After all
both Maple and Mathematica have benefited a great deal from the
pioneering efforts by the Axiom developers.

> 
> * Bill, you added two links to Tutorials to the FrontPage. 
> May I move them to the Axiom Documentation page? I have the
> feeling that they really belong there and that it scatters
> the FrontPage a little -- it doesn't fit on one screenfull
> anymore now...

Screen size is relative :) but I do think that such tutorials
should be VERY easily accessible - more or less right up front.
I expect that many people arrive at MathAction with little or
no knowledge of what Axiom really is. Navigating to a 2nd page
might be a (minor) inconvenience. Of course it is a matter of
preference but generally I do like to have more information
on the first page I see, not less.

> Do you think that "Axiom documentation and community" is
> misleading, i.e. that you wouldn't look there, if you are
> looking for a tutorial? If this is the case, maybe we
> should rename it to "Axiom tutorials, documentation and
> community"
> 

I suggest using just the name "Axiom tutorials and documentation".
The "community" part of it is (mostly) irrelevant. Elsewhere
perhaps we might want to have a page that says "Who's who in
the Axiom community" and list some of the community information
there.

\start
Date: Thu, 28 Oct 2004 17:35:47 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: axiom project homepage

Dear Bill,

Bill Page writes:

 > I think a direct link to MathAction is a good idea, BUT
 > I also think /zope/mathaction needs a more prominent link
 > to /zope/Plone (Axiom Portal).

I think that concentrating on MathAction would be a good idea, since our
community is pretty small, however:


 > Yes there are some documents on /zope/Plone that are not on /zope/mathaction
 > but I am not sure if they belong on MathAction or not. There are things that
 > Plone does that the ZWiki software on MathAction can not do such as private
 > user files and controlled publication, calendar events, bibliographies
 > etc. There may also be some material on the test.axiom-developer.org test
 > site that is not on MathAction.

I propose the following: I integrate into MathAction those things I can move to
MathAction (Please provide pointers). As soon as the need arises, we integrate
MathAction into Plone.

Although MathAction is less controlled, please notice that there is very little
action on MathAction... So, control is not an issue currently.

 > In principle, MathAction is the less controlled environment because it is an
 > open publicly accessible wiki. In fact, it is more organized only because
 > Martin has done a great job of maintaining the content.

Thanks. 

 > The Plone Axiom Portal on the other hand has not had nearly enough
 > attention. 

I do not have the time of maintaining the content of two sites. And -- sorry,
Bill -- I'm quite certain that it would not be a good idea to somehow split the
content. PLEASE: Let's go with MathAction for a while. It provides -- nearly
:-) -- everything we need right now!

 > Screen size is relative :) but I do think that such tutorials should be VERY
 > easily accessible - more or less right up front.  I expect that many people
 > arrive at MathAction with little or no knowledge of what Axiom really
 > is. Navigating to a 2nd page might be a (minor) inconvenience. Of course it
 > is a matter of preference but generally I do like to have more information
 > on the first page I see, not less.

I see your point. However, it seems that you agree to

 > using just the name "Axiom tutorials and documentation".

Please send an OK!, than I'll do this.

 > The "community" part of it is (mostly) irrelevant. Elsewhere perhaps we
 > might want to have a page that says "Who's who in the Axiom community" and
 > list some of the community information there.

That's an option of course. I'll spend a few minutes on thinking how to
reorganize the material on the Documentation page, OK?

\start
Date: Thu, 28 Oct 2004 13:16:47 -0400
From: Bill Page
To: Bob McElrath
Subject: ASCIIMathML

Bob,

For future application on LatexWiki of MathML you might
be interested in the following:

  http://www1.chapman.edu/~jipsen/mathml/asciimath.html

>From mathforge.net:

How to format mathematics 

The impressive browser-based MathML tool was written by Peter
Jipsen at Chapman University. It is called ASCIIMathML and you
can find it here

  http://www1.chapman.edu/~jipsen/mathml/asciimath.html
 
Enclose the following notation within dollar signs ($) or
backticks (`). To write a dollar sign within regular text,
type '\\$' instead. A dollar sign within math is just '\$'. 

`(x+1)/(x-1) x^(i+j) x_(ij) sqrt(x) root(n)(x) text(any)`

Operation symbols `+ - * ** // \\ xx -: @ o+ ox sum prod
^^ ^^^ vv vvv nn nnn uu uuu`

Relation symbols `= != < <= > >= -< >- in !in sub sup sube
supe -= ~= ~~ prop`

Logical symbols `and or not => if iff AA EE _|_ TT |- |=`

Miscellaneous symbols `int oint del grad +- O/ oo aleph ...
cdots \ quad qquad diamond square |_ _| |~ ~| CC NN QQ RR ZZ`

Standard functions `sin cos tan csc sec cot sinh cosh tanh
log ln det dim lim mod gcd lcm`

Grouping brackets `( ) [ ] { } (: :) {: :}` 

Arrows `uarr darr rarr -> larr harr rArr lArr hArr` 

Accents `hatx barx ulx vecx dotx ddotx` 

Font commands `bbA bbbA ccA ttA frA sfA` 

Matrices `[[a,b],[c,d]] ((1,0),(0,1))` 

Greek letters `alpha beta chi delta Delta epsi eta gamma
Gamma iota kappa lambda Lambda mu nu omega Omega phi Phi pi
Pi psi rho sigma Sigma tau theta Theta upsilon xi Xi zeta` 

\start
Date: Thu, 28 Oct 2004 13:30:00 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: axiom project homepage

Martin,

On Thursday, October 28, 2004 11:36 AM you wrote:
> 
> Bill Page writes:
>
>> using just the name "Axiom tutorials and documentation".
> 
> Please send an OK!, than I'll do this.

                    (: OK! :)

Please continue to feel completely free to change the
content on MathAction however you wish. It is an open
and unrestricted place where anyone who cares to can
make whatever changes they want (except deleting pages).
I think your views on how to structure the material in
MathAction are very good.

> Although MathAction is less controlled, please notice that 
> there is very little action on MathAction... So, control
> is not an issue currently.

The kind of "control" that I am concerned about on the
Axiom Portal (Plone) is the really best viewed as "privacy".
Perhaps one of the reasons that we see so little activity
on MathAction - in spite of the fact that everyone who has
seen it has praised it's apparently valuable features - is
that some potential users view it as *too public*. Many
people do not like to experiment in such an environment.
And in the end, a lot of people deprecate their own ability
to contribute useful material for others.

There are now about 30 people registered to use the Axiom
Portal. Some of them have apparently been experimenting on
their own in a less public manner. With Plone

  http://page.axiom-developer.org/zope/Plone

you can access Axiom and Reduce online via the web without
the feeling that everyone is watching what you are doing.
After you develop something that you would like to share
with others, then you can submit it for "Publication".
Then other users of the Axiom Portal will be able to see
and comment on the work.

While on the subject of the "action on MathAction" and
promoting it's use I should mention that I have submitted
the MathAction site to

  http://mathforum.org

however I have not yet heard back from them about adding
it to their quite extensive list of math resources.

I have also recently posted a message about MathAction at

  http://mathforge.net

Description: A set of freely available online mathematics
tools that include a community message board for math-related
news and user-initiated discussions, dynamic non-Java-based
MathML rendering capabilities (try them out and save your
changes in a Wiki), computer maths tools, and Web publishing.
The private message board allows users to form task-related
groups. User registration is required for some of the services.
Mathforge aims to be capable of numerical and symbolic calculation,
publishing documents with mathematical content, analyzing and
visualizing data, and much more.  

---------

> 
> I propose the following: I integrate into MathAction those 
> things I can move to MathAction (Please provide pointers).

I recommend using the Search function, the What's New link
and the Recent Items box to see what there.

> 
>> The Plone Axiom Portal on the other hand has not had nearly
>> enough attention. 
> 
> I do not have the time of maintaining the content of two 
> sites. And -- sorry, Bill -- I'm quite certain that it would
> not be a good idea to somehow split the content. PLEASE:
> Let's go with MathAction for a while. It provides -- nearly
> :-) -- everything we need right now!

I am happy to continue to use both since (for me) they
server rather different purposes.

\start
Date: Thu, 28 Oct 2004 13:49:16 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: ASCIIMathML

On Thursday, October 28, 2004 1:17 PM I wrote:
> 
> For future application on LatexWiki of MathML you might
> be interested in the following:
> 
>   http://www1.chapman.edu/~jipsen/mathml/asciimath.html
> 
> ...

Related to the above, here is a link to a wiki page in the
"Sample Group" on the http://mathforge.net website.  Note that
(like LatexWiki) it allows mathematics to be displayed in a
MathML-capable browser.

http://mathforge.net/index.jsp?page=wikiPage&msgId=337&scope=group&=
groupId=3
2

I wonder if mathforge would be interested in the Axiom
interface?

\start
Date: Thu, 28 Oct 2004 10:59:09 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: ASCIIMathML


--R+My9LyyhiUvIEro

Thanks!

This is interesting but it looks like a very restricted subset of latex
syntax.

I currently use itex2mml for the MathML in LatexWiki, which is also a
restricted subset of latex.  (in fact, I would like to see an
enumeration of exactly what the restriction is...)  It looks like
ascii2math is more restrictive in its syntax than itex2mml...

I haven't made a lot of noise about mathml in latexwiki because of this
unknown restriction, but it does work...

Bill Page [Bill Page] wrote:
> Bob,
> 
> For future application on LatexWiki of MathML you might
> be interested in the following:
> 
>   http://www1.chapman.edu/~jipsen/mathml/asciimath.html

\start
Date: Fri, 29 Oct 2004 16:07:49 +0200
From: Martin Rubey
To: list
Subject: new homepage / download section

Currently, 

http://savannah.nongnu.org/files/?group=axiom

redirects to 

http://axiom.axiom-developer.org/axiom-website/download.html

This is nonsense, because that way you never get to the files :-(

\start
Date: Fri, 29 Oct 2004 11:46:24 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: new homepage / download section

About a month ago I (finally) managed to figure out how
to put files in the savannah files section again - the
procedure to do this changed last year after the hacker
attack on savannah and the files that we preiously had there
were removed by savannah. The method to upload files now
involves signing them using gnupg - not so hard but not
trivial. Anyway, we did not have any files there for a long
time until just last month.

Whatever Tim Daly did in order to change the default home
page has also apparently changed the savannah files link.
Since I don't really understand how this home page re-direct
thing works at savannah, I don't know how to correct this.

Tim, what do you think? Is there an easy way to fix this?
If we store the files somewhere else and link directly to
them via the download.html page, how can we transfer what
we already have at savannah to the new location? Since
the Axiom Portal software on page.axiom-developer.org has
a simple file upload/download feature, maybe we should
locate all such files there.

  http://page.axiom-developer.org/zope/Plone/download

Bill Page.

On Friday, October 29, 2004 10:08 AM Martin Rubey wrote:
> 
> Currently, 
> 
> http://savannah.nongnu.org/files/?group=axiom
>
>redirects to 
>
> http://axiom.axiom-developer.org/axiom-website/download.html
> 
> This is nonsense, because that way you never get to the
> files :-(




