diff --git a/book/2004-10.txt b/book/2004-10.txt new file mode 100644 index 0000000..eb390a7 --- /dev/null +++ b/book/2004-10.txt @@ -0,0 +1,8356 @@ +\start +Date: Fri, 1 Oct 2004 03:35:55 -0400 +From: "Bill Page" +To: "'Bob McElrath'" +Subject: RE: [Axiom-developer] Re: literate programming pamphlet files forMathAction +Cc: zwiki@zwiki.org + +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: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: chicha@essi.fr, jcai3@uwo.ca + +On Thursday, September 30, 2004 12:25 PM Bob McElrath wrote: +> +> root [daly@idsi.net] 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: [Axiom-developer] Re: literate programming pamphlet files forMathAction +Cc: chicha@essi.fr, jcai3@uwo.ca + +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: [Axiom-developer] 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: [Axiom-developer] Re: literate programming pamphlet files forMathAction + +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: wyscc@cunyvm.cuny.edu +Subject: [Axiom-developer] 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, 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: [Axiom-developer] Re: literate programming pamphlet files for MathAction + +On Friday, October 01, 2004 9:31 AM Martin Rubey +martin.rubey@univie.ac.at 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: [Axiom-developer] 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: [Axiom-developer] 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-developer] Axiom crashing in Zope-Plone +Cc: "Bill Page \(E-mail\)" , 'Hans Peter Wuermli' , Bob McElrath + +Greetings, and thanks for your informative and helpful reply! + +Bob McElrath writes: + +> Page, Bill [Bill.Page@drdc-rddc.gc.ca] 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: [Axiom-developer] 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 (E-mail)" +Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone +Cc: 'Hans Peter Wuermli' , Bob McElrath + +Greetings! Bill your summary is wonderful! Thanks! + +"Page, Bill" 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----- +> > From: Camm Maguire [mailto:camm@enhanced.com] +> > Sent: Tuesday, September 28, 2004 2:21 PM +> > To: Bob McElrath +> > Cc: axiom-developer@nongnu.org; Bill Page; 'Hans Peter Wuermli' +> > Subject: Re: [Axiom-developer] Axiom crashing in Zope-Plone +> > +> > +> > 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 [bill.page1@sympatico.ca] 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) 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) 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-developer] 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: +> +> "Page, Bill" 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-developer] 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: +> > +> > "Page, Bill" 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: [Axiom-developer] 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 + + + + + + + +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: [Axiom-developer] 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 <>= 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: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: Bill Page + + +--ibTvN161/egqYuK8 + +Martin Rubey [martin.rubey@univie.ac.at] 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: [Axiom-developer] 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 <>= 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: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: zwiki@zwiki.org + +Bill Page [bill.page1@sympatico.ca] 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 [bill.page1@sympatico.ca] 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 <>= 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-developer] 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: [Axiom-developer] Re: literate programming pamphlet files for MathAction +Cc: chicha@essi.fr, jcai3@uwo.ca, zwiki@zwiki.org + +Bill Page [bill.page1@sympatico.ca] 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: [Axiom-developer] Re: How to use MathAction + +Martin Rubey [martin.rubey@univie.ac.at] 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-developer] 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: [Axiom-developer] 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: [Axiom-developer] 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: root +To: hemmecke@risc.uni-linz.ac.at +Subject: Re: [Axiom-developer] 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-developer] 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-developer] 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: [Axiom-developer] 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 [wurmli@hispeed.ch] 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: [Axiom-developer] 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: root +To: bob+axiom@mcelrath.org +Subject: Re: [Axiom-developer] Re: Setting up AxiomWiki within Zope +Cc: camm@enhanced.com, bill.page1@sympatico.ca, wurmli@hispeed.ch + +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: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: +Subject: RE: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: [Axiom-developer] 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: [Axiom-developer] 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: [Axiom-developer] 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: root , Bill Page +Subject: Re: [Axiom-developer] Re: Setting up AxiomWiki within Zope +Cc: camm@enhanced.com, wurmli@hispeed.ch + +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. + +root [daly@idsi.net] 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.page1@sympatico.ca] 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: [Axiom-developer] [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: [Axiom-developer] 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: +Subject: RE: [Axiom-developer] 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: [Axiom-developer] 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: [Axiom-developer] 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: [Axiom-developer] foreign concepts +Cc: Bill Page + +Martin Rubey [martin.rubey@univie.ac.at] 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: +Subject: RE: [Axiom-developer] 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: [Axiom-developer] 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: +Subject: RE: [Axiom-developer] 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: root +To: bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] 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: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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. +<>= +one one +one +@ %def one + +And now the second code part. + +<>= +two one two +@ + +Putting everything together... +<<*>>= +<> +<> +@ +%%-- END file.nw -- %% + +\start +Date: Mon, 04 Oct 2004 09:25:21 +0200 +From: Ralf HEMMECKE +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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 
 ...
, so adding + + + +between ... would achieve this. + +Or put it into + +http://page.axiom-developer.org/zope/mathaction/FrontPage/stylesheet + +as a default for 
.
+
+Unfortunately, the above CSS code modifies ALL 
 environments. That 
+may be undesirable.
+
+\start
+Date: Mon, 4 Oct 2004 10:14:00 +0000
+From: Martin Rubey 
+To: Ralf HEMMECKE 
+Subject: [Axiom-developer] 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-developer] Axiom release
+
+Dear Bob, dear all,
+
+Bob McElrath writes:
+ > Martin Rubey [martin.rubey@univie.ac.at] 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: axiom-developer@nongnu.org
+Subject: Re: [Axiom-developer] 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: [Axiom-developer] Re: literate programming pamphlet files for MathAction
+Cc: Bill Page 
+
+On Sun, Oct 03, 2004 at 10:20:54AM -0400, William Sit wrote:
+
+> 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: "Page, Bill" 
+To: 'Mike Dewar' 
+Subject: RE: [Axiom-developer] Re: literate programming pamphlet files for MathAction
+Cc: Bill Page 
+
+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: "Page, Bill" 
+To: gcl-devel@gnu.org
+Subject: [Axiom-developer] 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 ... . 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: "Page, Bill" 
+Subject: [Axiom-developer] 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
+ `.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
+ `.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
+ `.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
+ `.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
+ `.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
+ `.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
+ `.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
+ `.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.
+
+"Page, Bill"  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 ... . 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: "Page, Bill" 
+To: 'Camm Maguire' 
+Subject: [Axiom-developer] RE: GCL on Zaurus Debian - segmentation violation
+Cc: "Bill Page \(E-mail\)" 
+
+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: "Axiom-Developer@Nongnu. Org" 
+Subject: [Axiom-developer] _*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: root 
+To: mike.thomas@brisbane.paradigmgeo.com
+Subject: Re: [Axiom-developer] _*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: [Axiom-developer] _*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: 
+Subject: RE: [Axiom-developer] _*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: [Axiom-developer] _*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: "'Axiom-Developer@Nongnu. Org'" 
+Subject: RE: [Axiom-developer] _*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: [Axiom-developer] 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.page1@sympatico.ca
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] 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.page1@sympatico.ca 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.page1@sympatico.ca
+Subject: Re: [Axiom-developer] 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.page1@sympatico.ca 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.page1@sympatico.ca 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: root 
+To: miked@nag.co.uk
+Subject: Re: [Axiom-developer] SuchThat
+Cc: bill.page1@sympatico.ca
+
+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: [Axiom-developer] 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: 
+Subject: RE: [Axiom-developer] SuchThat
+Cc: 'Mike Dewar' , axiom-developer@nongnu.org
+
+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 root daly@idsi.net
+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 miked@nag.co.uk
+wrote:
+> 
+> According to the browser its used by EigenPackage,
+> PolynomialIdeals, RadicalEigenPackage and RadicalSolvePackage.
+> 
+
+\start
+Date: Mon, 11 Oct 2004 14:01:47 -0400
+From: root 
+To: bill.page1@sympatico.ca
+Subject: Re: [Axiom-developer] SuchThat
+Cc: miked@nag.co.uk
+
+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: 
+Subject: RE: [Axiom-developer] SuchThat
+Cc: miked@nag.co.uk
+
+On Monday, October 11, 2004 2:02 PM Tim Daly daly@idsi.net
+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: 
+Subject: RE: [Axiom-developer] 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: [Axiom-developer] 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: [Axiom-developer] 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: [Axiom-developer] 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.
+
+  
+  \begin{equation}
+  ...
+  \end{equation}
+
+  Some paragraph
+
+  \begin{axiom}
+  ...
+  \end{axiom}
+  
+
+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@univie.ac.at] 
+> Sent: Tuesday, October 12, 2004 5:47 AM
+> To: Bill Page
+> Subject: RE: [Axiom-developer] 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: [Axiom-developer] pamphlet support on MathAction
+Cc: zwiki@zwiki.org
+
+Bill Page [bill.page1@sympatico.ca] 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.
+> 
+>   
+>   \begin{equation}
+>   ...
+>   \end{equation}
+> 
+>   Some paragraph
+> 
+>   \begin{axiom}
+>   ...
+>   \end{axiom}
+>   
+> 
+> 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 "" inside a latex block?  It looks like
+hypextra does what you propose, but it is incapable of placing 
+inside a latex block.
+
+If we can think of nothing better, I would accept enclosing
+latex-in-html with  tags.  However I think a better idea would be
+ and  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: axiom-developer@nongnu.org,gcl-devel@gnu.org
+Subject: [Axiom-developer] 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: [Axiom-developer] pamphlet support on MathAction
+Cc: Bill Page , zwiki@zwiki.org
+
+Dear B & B,
+
+Bob McElrath writes:
+ > Bill Page [bill.page1@sympatico.ca] 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: [Axiom-developer] pamphlet support on MathAction
+Cc: zwiki@zwiki.org
+
+Martin,
+
+On Wednesday, October 13, 2004 6:28 AM you wrote:
+> > Bill Page [bill.page1@sympatico.ca] 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: [Axiom-developer] pamphlet support on MathAction
+Cc: 'Bob McElrath' , zwiki@zwiki.org
+
+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: [Axiom-developer] pamphlet support on MathAction
+Cc: Bill Page 
+
+
+--Bn2rw/3z4jIqBvZU
+
+Martin Rubey [martin.rubey@univie.ac.at] 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-developer] 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@enhanced.com 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: [Axiom-developer] 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@enhanced.com 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: root 
+To: camm@enhanced.com
+Subject: [Axiom-developer] 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: daly@idsi.net
+Subject: [Axiom-developer] Re: patch
+
+Greetings!
+
+root  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: root 
+To: camm@enhanced.com
+Subject: Re: [Axiom-developer] Re: patch
+Reply-To: daly@idsi.net
+
+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: root 
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] 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: root 
+To: axiom-developer@nongnu.org, axiom-mail@nongnu.org
+Subject: [Axiom-developer] 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: axiom-developer@nongnu.org
+Subject: [Axiom-developer] 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: daly@idsi.net
+Subject: Re: [Axiom-developer] 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,
+
+root  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: [Axiom-developer] 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: root 
+To: martin.rubey@univie.ac.at
+Subject: Re: [Axiom-developer] 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: root 
+To: camm@enhanced.com
+Subject: Re: [Axiom-developer] 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: [Axiom-developer] Re: Bug#277692: axiom graphics missing?
+Cc: control@bugs.debian.org, 277692@bugs.debian.org
+
+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
+> dlakelan@street-artists.org
+> http://www.street-artists.org/~dlakelan
+
+\start
+Date: Sat, 23 Oct 2004 14:52:39 +0200
+From: Martin Rubey 
+To: Camm Maguire , axiom-developer@nongnu.org
+Subject: [Axiom-developer] 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: axiom-developer@nongnu.org
+Subject: [Axiom-developer] 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-developer] 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-developer] 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-developer] 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-developer] 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-developer] 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-developer] 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-developer] 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-developer] 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-----
+> From: Martin Rubey [mailto:martin.rubey@univie.ac.at] 
+> Sent: Monday, October 25, 2004 4:37 PM
+> To: Bill Page
+> Cc: 'Martin Rubey'; axiom-developer@nongnu.org
+> Subject: RE: [Axiom-developer] 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: Tue, 26 Oct 2004 09:38:57 +0200
+From: Martin Rubey 
+To: "Bill Page" 
+Subject: RE: [Axiom-developer] 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: root 
+To: camm@enhanced.com
+Subject: [Axiom-developer] 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: "Page, Bill" 
+To: "'daly@idsi.net'" 
+Subject: [Axiom-developer] 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: daly@idsi.net
+Subject: [Axiom-developer] 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,
+
+root  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@wanadoo.fr
+Subject: [Axiom-developer] axiom project homepage
+Cc: gilbert@sci.ccny.cuny.edu
+
+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: [Axiom-developer] Re: axiom project homepage
+Cc: gilbert@sci.ccny.cuny.edu
+
+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: axiom-developer@nongnu.org
+Subject: [Axiom-developer] 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-developer] 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-developer] 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: [Axiom-developer] 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-developer] 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: [Axiom-developer] 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: [Axiom-developer] 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.page1@sympatico.ca] 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: axiom-developer@nongnu.org
+Subject: [Axiom-developer] 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: [Axiom-developer] 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 :-(
+
+
+
+
diff --git a/changelog b/changelog
index 10b0c9b..d3885b7 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,5 @@
+20140423 tpd src/axiom-website/patches.html 20140423.05.tpd.patch
+20140423 tpd book/2004-10.txt regularize
 20140423 tpd src/axiom-website/patches.html 20140423.04.tpd.patch
 20140423 tpd book/2004-09.txt regularize
 20140423 tpd src/axiom-website/patches.html 20140423.03.tpd.patch
diff --git a/src/axiom-website/patches.html b/src/axiom-website/patches.html
index 46f93f8..b7ca399 100644
--- a/src/axiom-website/patches.html
+++ b/src/axiom-website/patches.html
@@ -4304,6 +4304,8 @@ book/2004-07.txt regularize
 book/2004-08.txt regularize
 20140423.04.tpd.patch
 book/2004-09.txt regularize
+20140423.05.tpd.patch
+book/2004-10.txt regularize