RE: [Axiom-developer] Re: aldor patches

[Peter Broadbery]

On Wed, 2005-08-24 at 17:48 -0400, Page, Bill wrote:
> Peter,
> 
> On Wednesday, August 24, 2005 2:19 PM you wrote:
> > >
> > >   \begin{aldor}
> > >   Aldor code
> > >   \end{aldor}
> > >
> > 
> > This ought to work, but not immediately; One problem may be compiling
> > several aldor stanzas together - in this case you need to be able to
> > refer to earlier stanzas within the aldor block.
> > 
> > Eg:
> > 
> > \begin{aldor}
> >     AldorCat: Category == with { funstuff }
> > \end{aldor}
> > 
> > \begin{aldor}
> >     AldorDomain: AldorCat with { ... } == add { ... }
> > \end{aldor}
> >
> 
> In the case of \begin{axiom} sections, what MathAction does is
> generate a .input or .spad file for each section and then calls
> Axiom just once using stdin to pass )read or )compile commands
> for each section as appropriate. So, for each web page there is
> only one Axiom session and the namespace is the same for the
> entire page. (Except for comments containing \begin{axiom}
> sections which are initially each run in their own Axiom session
> before being appended to the page.)
> 
> Perhaps I can do the same thing for Aldor? Can I run Aldor
> with a series of 'include' files - one for each \begin{aldor}
> section? Would that solve the problem of referring to earlier
> sections?
> 

This would work, I think (and the problem with .ao files goes away),
although a page wouldn't be able to redefine an operator.

> To make this work properly I also need some kind of unique separator
> string between the Aldor compiler output for each include file.
> In the case of Axiom that separator is the interpreter '(99) -> '
> prompt sequence. For Spad sections, the \begin{axiom} \end{axiom}
> group is replaced with <pre>formatted</pre> HTML tag containing
> the Spad code followed by a <div> ... </div> section containing
> the Spad compiler output (which appears as "folded" text"). Can
> you suggest a way to generate such a separator for Aldor compiler
> output if the input consists of a series of 'include' files?
> 

The only compiler output will be error messages from the compiler; If
you call the compiler via axiom (ie. ')co aldor-section.as'), then an
axiom prompt should be a perfectly good separator.


> The use of 'include' files above should handle this case, right?
> 
Yep.

> Where do the .ao files need to be stored in order to be accessible
> to Axiom commands? Can more than one .ao file be generate per run
> of the Aldor compiler? Is it sufficient if they are saved in the
> current working directory?
> 

Storing them in the current working directory should be fine, though 


>   # document Makefile.pamphlet
> 
> in order to generate the Makefile and the type
> 
>   # make 2>&1 | tee aldor.log
> 
> The result of doing this is contained in the new attached log
> file.
> 
> The log file contains two runs of make in sequence. The first run
> stops with the message:
> 
> make[1]: *** No rule to make target
> `/home/page/repository/axiom--main--1/int/aldor/dep_spad.stamp', needed
> by `/home/page/repository/axiom--main--1/int/aldor/saxiom/spadset.mk'.
> Stop.


> The build progressed further but then apparently stopped because
> a statement in the generated Makefile exceeded some command line
> length limit for either make or /bin/sh.
> 
> What linux operating system and utility versions are you using
> to do your development? I am trying to build this on the
> axiom-developer/MathAction server which is running RedHat 9
> (updated almost, I think, to the level when RedHat discontinued
> it's development about two years ago in favor of Fedora). The
> server runs in shared virtual server mode.

I'm using SuSE 9.2; the make version is 3.80 (you may have the previous
version; 3.80 was released in october 2002). The problem seems to be
that Make.functions hasn't been generated from Make.functions.pamphlet;
if you do this manually, it'll get further.

The second error was not due to an excessively long command line, IIRC
bash has no such limit, especially in 'for' statements.  The problem was
an ungenerated include file.

> 
> Is there some way your java program can easily generate a more
> Portable Makefile? Or do you know of anyway to allocate a
> Larger command line buffer?
> 

"Easily", not sure - I think it would mean a different approach, since
the java program currently just spits out sets of mutually dependent
domains, and is just there to help make on its way. 

One way of simplifying matters would be to invoke 3 sequential builds;
Once to run document on everything, then for the dependency graphs, and
then once more to build the library.  However, this may well still need
a more recent make.


> Regards,
> Bill Page.
> 
-- 
Peter Broadbery <address@hidden>