[Axiom-developer] Re: new/src/boot/Makefile.pamphlet

[root]

re: the patch. thanks.

> > I have corresponded with Norman on several occasions. I've made some
> > changes to noweb that Norman feels should be done with gawk filters.
> > I'm a much better C programmer than a gawk programmer (in fact, I
> > never use awk or gawk) so I made changes in the C code. Since these
> > changes are not of interest to others (well, maybe the /dev/null)
> > and I haven't taken the time to learn gawk there is no common ground
> > to give back the changes. This really isn't Norman's problem, it's me.
> 
> There was one patch to modules.nw (in noweb.modules.nw.patch) that
> looked very much as if it belonged upstream.

noweb appears to digest the file into some syntactic form which can be
processed by filters. i haven't taken the time to understand the intermediate
file format nor the way to reparse them. Norman made the point that the
patch you're looking at can be done in a much cleaner way. I fully agree
but either way it became a patch and I was focused on getting it to run.
Thus, rather than climb the learning curve I stomped the offending code.
mea culpa. I plan to revisit this whole issue in the future. I'm trying
to get a system that will run all of the algebra (which is the heart of
Axiom) and get it so others can at least use it to write new algebra.
At that point I have the free time to rehack the rest of the code. In
the current state no one can fully run the algebra and time passes...

> 
> > It'll get worse in the future as I want the pamphlet files to have
> > more functionality. In the fullness of time I want pamphlet files to
> > be the publication standard for an Axiom Journal. ...
> 
> Yes, I was just browsing the old list archives.  Quite a grand vision
> you have.

Axiom's been around 30 years and it has the potential to be around a lot
longer; provided we solve some fundamental software issues like making it
maintainable, documenting it so the algorithms can be modified, etc. I
plan to spend the next 5 years leading the project and building the
supporting code and social structures. If it isn't at least mildly 
self-sustaining at that point I guess I will have failed. I just hate
to see such unbelievably good research go to waste. 

I spent last year while I was waiting for code release pondering the
reasons that make a large software project like Axiom fail. Most of
the "grand vision" ideas come from that question. After 33 years of
programming I'm tired of watching systems vaporize. Surely we can 
do better. If mathematical software can't span the generations, what
software can? So, in a sense, this is a research project on software
as much as it is a research project in mathematics. Since my day job
at City College is a joint venture of the math dept and comp sci it
fits my interests.

> 
> I thought the TeXmacs authors had a reasonable point, that there's no
> need to remained tied to noweb if it ends up being too limiting.
> OTOH, it's a trivially simple format to parse, so there's no harm
> using it now.

I tried various systems and had a discussion with Joris about Texmacs.
I eventually want Texmacs to be the common front-end of Axiom. But
noweb is clearly the best path for the short term. I've tried to use
noweb on various other projects, the latest being a huge music theory
program in Java. It is unclear if literate programming adds value for
such things as there is very little "theory" in the actual programming
and any decent programmer is better of "reading the source code". 
However, "reading the source code" isn't going to get you far with
Axiom's algebra so literate programming really shines for Axiom.

> 
> So all I want right now is to use the versions of gcl, noweb, and
> cmucl that were already installed on my Debian GNU/Linux system, and
> which are more recent than the versions you included.  Is there some
> simple change to do that?

Um, no. noweb could be made to work if you put the patched version
onto your system. GCL could work if you use the version I ship. 
Just any version won't do. The key problem (assuming you try to
use a newer version of common lisp) is that common lisp has changed
since NAG took over the code and they didn't keep up with the new
common lisp language. So, for example, Axiom assumes that
  (in-package 'foo)
will do a make-package if foo does not exist. That was true in the
original steele version of common lisp but the new standard requires
the make-package to occur first. I have the latest common lisp (GCL 2.5)
and have been sending Camm fixes, changes, and general harassing
email. Axiom will certainly run on the latest common lisp standard
as I feel it is important to keep up to date. However, first I want
to get it running on the common lisp where it used to run (AKCL aka GCL).
NAG used a "different" common lisp called CCL (which has the advantage
that it is byte-coded and platform independent). However, they made
non-common-lisp changes to the source code so it ran better on CCL
and I have to find and rewrite these (unfortunately I didn't keep the
original sources or I could diff them). So, no, unless you use exactly
the versions (including patches) I can't guarantee the build will
succeed.

On the other hand, being a "certified developer" you're welcome to 
try a different common lisp and make it work there. CMUCl and GCL 2.5
are certainly on the "todo" list and it would be most helpful if you
succeeded.

Tim