Re: [Axiom-developer] RE: algebra Makefiles with explicitdependencies, bootstrap, fixed-points etc.

[Stephen Wilson]

Bill,

On Mon, Jan 10, 2005 at 05:37:27PM -0500, Bill Page wrote:
> You mean the others are built in the same way, with errors? 

Yes. All code is identical to what one obtains after a `make clean &&
make', save for RECLOS and ROIRC. 

> The list of dependencies for RECLOS is

Thanks for the lists! They will come in handy!

> But for example another file that shows up in the fixedPoint list
> as changing, D01AGNT, does not depend on EUCDOM.o and on fewer of
> the bootstrap files
>
> ...
>
> If the bootstrap files and the database files have been updated
> but D01AGNT still changes then it must be from some other cyclic
> dependency.

But the domain vector for D01AGNT does change in a subtle way after
the new bootstrap build. Even though its code is no different, how the
domain is being instantiated has changed. More below.
 
> You are correct. The src/algebra/Makefile.pamphlet that I am using
> on the axiom--windows--1 branch has been updated to properly rebuild
> the databases if any of the *.NRLIBS/code.o files change. In the
> linux branches (e.g. axiom--main--1) the database build is still
> done via a kludge that requires you to delete the file called
> `dbcomplete' in order to force a rebuild. Alternately you could
> also delete the int/*.spad files which will force them to be
> re-extracted from the pamphlet files and also trigger deletion of
> the dbcomplete file.

Thanks for explaining this! So many details! :)

> It is not so clear to me why the build appears to succeed
> even though these definitions are missing. In other languages
> I would presume that this situation would be easily caught
> as a missing file during `linking'. But here we have this
> "domain vector" thing. Is there not some why that the
> compilation could be made more robust by verifying the
> domain vector at compile time?

EUCDOM is missing just the single function `expressIdealMember'. The
bootstrap code appears to have been generated from a spad file which
includes its definition. The generated code just wasnt included. A
quick grep of the algebra tells me that this function is not called
anywhere. As for TSETCAT-, I have not had the chance to determine what
its dependencies are (Im surprised such a high level category is part
of the bootstrap). 

SINT's missing `one?' is more interesting. I need to confirm this, but
I believe that dependent domains are resolving Monoids default
definition for `one?'. This might explain why other domains, such as
D01AGNT, are being instantiated differently under the new bootstrap
build. I need to look into this further.

As far as verification of the domain vectors goes, we already do have
a fair check when comparing the generated code. For each domain there
is a MAKEPROP form, at the end of which is something like:

  (|makeByteWordVec2| 20 (QUOTE (2 6 0 0 .... 0 7 20)))

This is intimately linked to the layout of the domain vectors. It
provides indexes into the domain vector, the arity of function calls,
and probably other things which I dont understand yet :).

However, it is only a map into the vectors layout. The subtle changes
which I have noticed in the bootstrap build do not involve the `shape'
of the vectors. For example, where a certain slot was filled with a
hard reference to a compiled function, now we have a call to the
runtime dispatch mechanism. 

Some of the notes that I promised deal with how byte vectors and
the runtime dispatch mechanisms work. I hope to get around to writing
it down soon ;)

Cheers,
Steve