[Axiom-developer] Re: interval.spad INTRVL

[Bill Page]

Tim,

On Sat, 2003-08-30 at 22:49, you wrote:
> 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.

> One thing I need to do is try to recompile all of the
> lowercase.spad files to ensure I haven't broken the original
> code. I did that earlier but it needs to be redone for the
> latest changes.
> 
> Additionally the long term will have the interpreter do the
> notangle under the covers directly from the pamphlet file. At
> that time we can eliminate the lowercase.spad files. I didn't
> have time to write this before shipping the Thursday system.

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.

> 
> 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.

> If you start the Thursday version and do:
> 
> )co INTCAT
> )co INTRVL
> 
> then the compiles succeed. This is the same behavior as compiling
> all of interval.spad. The compile of INTCAT implicitly makes the
> |IntervalCategory| function available. However, if you compile 
> the two files in separate interpsys sessions then the compile of
> INTRVL fails because it cannot find INTCAT.
> 

These two files are compiled separately in Juergen's version.

> The databases are indeed bent. There is a another layer of cycle 
> in the game as follows:
> 
> 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.


>  This magic occurs because there is a
> shell variable ($DAASE) that is asserted during the build
> (see the /Makefile.pamphlet file).
> 
> Once the build is complete (which also builds new databases)
> the databases are fetched from mnt/linux/algebra/*.daase.

Juergen's version does not build new database files. It
continues to use the ones from share.

> (You can
> change which databases it uses by setting or unsetting the
> DAASE shell variable. Note that the shell variable has /algebra
> automatically appended so DAASE=/foo/bar becomes /foo/bar/algebra)
> 
> The interval.spad file was rewritten by Juergen and is not part
> of the NAG database but interval.as is. Somehow building INTRVL
> with the NAG databases causes the compile to fail. I'm chasing it
> now but I don't understand it fully yet.
> 

Me neither! <grin> But I don't trust those database files!

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?

> re: SIGNEF
> 
> 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.

Cheers,
Bill Page.


> Tim
> address@hidden
> address@hidden
> 
> ==================================================================
> 
> Tim,
> 
> I am now in the middle of third re-compile with a modified
> Makefile.pamphlet that eliminates the extra lowercase.spad
> files and adds a few of the modules which were not yet
> included in your make file, including INTRVL. I found that
> when a attempted to evaluate
> 
> 
>  -> integrate(exp(sin(x)),x)
> 
> that Axiom complained that it could not load COMBF.o and
> then SIGNEF.o. When I tried to compile SIGNEF.o, I got an
> error saying that it couldn't find Interval.
> 
> The interesting thing is that this works under Juergen's
> version. (It loads all of the required algebra, but Axiom
> returns the expression unevaluated.)
> 
> Could it be that there is still a problem with the databases?
> Are these being re-built in your newest version of the
> Makefile?
> 
> Cheers,
> Bill Page.
> 
> On Sat, 2003-08-30 at 21:00, root wrote:
> > The INTCAT category is not being autoloaded. I'm not sure why.