[Axiom-developer] Re: interval.spad INTRVL

[root]

> > re: lowercase spad files.
> > 
> > These were put there for the purpose of testing. They are in the
> > int directory and would not be part of a "shipped" image (which
> > all resides under the mnt directory). It is convenient to be able
> > to )co foo.spad or )co foo.spad )con bar without having to do the
> > notangle.
> 
> Perhaps. But I understood that your goal was one category, domain
> or package per spad file, presumably so that the dependencies
> could be more "fine grained". Otherwise you could just build
> with the lowercase files and throw away the upper case ones. No?
> 
> In any case, as you say the duplication does no harm.

Actually the organization of a pamphlet file is likely to have
several category/domain/packages (CDP) in it. In fact, most newly
contributed algebra is likely to be packaged that way. It is
not a problem because newly contributed algebra does not need
to be bootstrapped. I prefer the single-CDP per file style but
others do not.

However, in the bootstrap situation you need to have much finer
grain control of which CDP you are building. I found that there
was no possible order that could build the "lowercase" spad files
so I needed to break them apart.

In any case the "user level" presentation of the algebra will be
the "lowercase" spad file pamphlets. This is too ingrained to change.
So consider the "uppercase" spad files to be part of the internal
machinery of the build.


> It seems you would be eliminating the upper case ones as well
> and would depend directly on the pamphlet files. I can see the
> advantage of this in other circumstances, e.g. user application
> files.

Remember that the user will see nothing from the int and obj
directories.  These are purely compiler and makefile caches. They
contain no useful information for the user. However they seriously
reduce the rebuild time and allow optimization to occur (watch for the
warning messages about duplicate functions. that comes from the
special second-pass optimizer based on the .fn files in the int
directory). 

The user will see the "lowercase" spad.pamphlet files
(hopefully with better documentation). In particular, the user should
be able to type:

)co interval

and have the interval.spad file extracted, compiled, and installed.
In the longer term the compiler will be hidden and the user will just type:

)add interval

which will rip the pamphlet into code, compile it, rip out the test cases,
test them, rip out the documentation and integrate it into the system, 
chase biblio references and include them, run included proofs, install
examples, and shine your sneakers. This will take a few weeks to implement
so the scaffolding is still showing thru.

> > 
> > re: INTRVL
> > 
> > The reason it works in Juergen's version is that the interval.spad
> > file is compiled as one file rather than as a category and a domain.
> 
> No, look again. That is not what happens in Juergen's makefile.
> All of the pamphlet files including interval.spad.pamphlet are
> split into upper case name files containing individual modules
> with named by their abbreviations and also as a combined module
> file with a lower case name the same as the pamphlet. *Only*
> the upper case files are compiled. In fact, in my variant of
> Juergen's makefile I have eliminated all of the files with
> lowercase names.
> 
> There must be some other explanation.

Interesting. That's another clue. I missed that.

> > In order to build the first interpsys you need the database files.
> > These are gotten from the src/share/algebra/*.daase files which are
> > the original NAG databases.
> 
> Juergen re-built the src/share/algebra/*.daase files. These
> re-built files are used to build the first version.

Hmmm, yet another clue. I'll look into that also.


> This reminds me to ask about the other ALDOR files that are
> included in the build but apparently not compiled. Are you
> planning that these will at some point be compiled by ALDOR?
> (which is now a separate non-BSD licensed? package) How
> difficult is it for a user to encorporate ALDOR if they so
> wished? There would likely be a considerable speed and memory
> advantage for certain routines. Right?
> 
> Another thing that has happened since Aldor separated from
> Axiom is that a very large part of the algegbra has been
> re-written and apparently improved. Do you think that in
> the medium to long term the Axiom and Aldor algebra libraries
> should be made compatible? How practical (and legal?) would
> it be for Axiom (at least as a option) to implement the
> same library. Is it difficult to convert to spad. Or is
> there any advantage if ALDOR can be easily linked with
> Axiom?

mumble

> > The nature of that problem is that SIGNEF uses INTRVL.
> > 
> 
> With the Thursday version if I compile INTCAT, INTRVL and
> SIGNEF in the same session (and in that order), I get an
> error
> 
> --------constructor---------
> Compiling /home/wspage/projects/axiom2/./SIGNEF.NRLIB/code.lsp.
> End of Pass 1.
> End of Pass 2.
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
> Finished compiling /home/wspage/projects/axiom2/./SIGNEF.NRLIB/code.lsp.
> ------------------------------------------------------------------------
>   
>    >> System error:
>    Caught fatal error [memory may be damaged]
>  
> protected-symbol-warn called with (NIL)
> 
> --------
> 
> Ho hum ... time to get a little sleep.
> 

sleep? at a time like this? where's your dedication, man! Why it's only
3:30am. Sleep. cheese. you'll have time to sleep after you die.

t