\documentclass{book}
%\newcommand{\VolumeName}{Volume 2: Axiom Users Guide}
%\input{bookheader.tex}
\pagenumbering{arabic}
\mainmatter
\setcounter{chapter}{0} % Chapter 1

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Wed, 1 Nov 2006 07:36:11 -0500
From: Bill Page
To: Camm Maguire, Bill Page
Subject: RE: gcl-2.6.8pre on MAC OSX 10.2

Camm,

On Tuesday, October 31, 2006 8:43 AM you wrote:
>
> Greetings, and thanks!  OK, please try it now, I think it should be
> fixed.  Please let me know if problems persist.
>

I have rebuilt gcl and restarted the build of Axiom from scratch.

Ooops! Looks like the problem has shifted to another symbol. :-(

...
Compiling
/home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-app
le-darwin6.8/interp/g-util.lsp.
...skipping...
Error: Undefined symbol "_sqrt"
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at BUILD-INTERPSYS.  Type :H for Help.
BOOT>>make[2]: ***
[/home/users/b/bi/billpage/osx/axiom.build-improvements/build
/powerpc-apple-darwin6.8/bin/interpsys] Error 255
make[1]: *** [interp/stamp] Error 2
make: *** [all-recursive] Error 1
ppc-osx3:~/osx/axiom.build-improvements $


\start
Date: 01 Nov 2006 09:46:57 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: gcl-2.6.8pre on MAC OSX 10.2

Greetings, and thanks so much!

Bill Page writes:

> Camm,
> 
> On Tuesday, October 31, 2006 8:43 AM you wrote:
> > 
> > Greetings, and thanks!  OK, please try it now, I think it should be
> > fixed.  Please let me know if problems persist.
> >
> 
> I have rebuilt gcl and restarted the build of Axiom from scratch.
> 
> Ooops! Looks like the problem has shifted to another symbol. :-(
> 
> ... 
> Compiling
> /home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-app
> le-darwin6.8/interp/g-util.lsp.
> ...skipping...
> Error: Undefined symbol "_sqrt"
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by LOAD.
> Broken at BUILD-INTERPSYS.  Type :H for Help.
> BOOT>>make[2]: ***
> [/home/users/b/bi/billpage/osx/axiom.build-improvements/build
> /powerpc-apple-darwin6.8/bin/interpsys] Error 255
> make[1]: *** [interp/stamp] Error 2
> make: *** [all-recursive] Error 1
> ppc-osx3:~/osx/axiom.build-improvements $
> 

Sigh.  As usual, I cannot reproduce on the mac to which I have
access.  I'm assuming you see the same issue with

(defun foo (x) (declare (long-float x)) (the long-float (sqrt x)))
(compile 'foo)

Am also assuming that the read-byte test I posted earlier now passes. 

In any case, would you please mind stepping through gdb again to the
same place?  It should be obvious what is going on.  The idea is that
the MY_PLT list in plt.h should have one _ stripped, and that the
string passed to my_plt should do the strip in the stn() C macro right
before the (second) call to bsearch.

I'll be leaving town tomorrow afternoon until Sunday, but would be
happy to fix this quickly today if possible.

\start
Date: 01 Nov 2006 10:16:19 -0500
From: Camm Maguire
To: Colin Turner
Subject: Re: Bug#328480: axiom: Still seems to be a problem
Cc: Bill Page

reopen 328480
forwarded 328480 list
thanks

Greetings, and thanks so much for your feedback!

Colin Turner writes:

> Hi Camm,
> 
> Camm Maguire wrote:
> > Greetings!
> > 
> > OK, just double checked with the latest 20050901-7, and I cannot
> > reproduce.  I think this must be come xserver/configuration problem.
> 
> Possible, I suppose it might have coincided with an xorg upgrade;
> however, the issue is exactly as identified in previous bug report -
> it's also exactly replicated on several machines on which I have axiom,
> and it all worked in the past.
> 
> I can't now test Tim's num-lock theory for the reasons stated below.
> However, I was able to change the cell of focus with the mouse, but no
> keys produced any output, on the keypad or otherwise.
> 
> > There is an axiom wiki for frequently encountered problems.  Can you
> > identify anything there with something similar?  Can you try asking at
> > <list>?
> 
> I've just had a look through it. I don't see anything yet.
> 
> >> I'm still experiencing this bug in version 20050901-6.
> >> As before no input in the areas in hyperdoc is accepted.
> 
> Unfortunately, in 20050901-7 I'm having a different problem.
> 
> If I go to reference -> search in the hyperdoc system, I *can* enter text.
> 

OK, so this issue would appear closed.

> However, if I for example go to
> 
> Settings -> Settings
> 
> or
> 
> Basic Commands -> Calculus -> Differentiate
> 
> an hourglass appears, never dismisses and
> 
> (1) ->
> (1) ->
>    >> System error:
>    Unexpected end of #<string-input stream from "                ...">.
> 
> (1) ->
> 
> appears in the console (which is still active). Again, this happens on
> two machines I have dist-upgraded. Num-lock makes no difference for this
> at least.
> 

OK, sock_get_string_buf, which appears correctly prototyped, is
returning 0, which from the code appears to indicate a socket read
error in one of the routines in sockio-c.c.

Fellow axiom developers -- any ideas here?

Take care,

> I'll keep searching the wiki. Thanks for the help.

\start
Date: Wed, 1 Nov 2006 10:27:11 -0500
From: Bill Page
To: Camm Maguire
Subject: RE: gcl-2.6.8pre on MAC OSX 10.2

Camm,

On Wednesday, November 01, 2006 9:47 AM you wrote:
> Bill Page wrote:
> > Ooops! Looks like the problem has shifted to another symbol. :-(
> >
> > ...
> > Compiling
> >
> /home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-app
> > le-darwin6.8/interp/g-util.lsp.
> > ...skipping...
> > Error: Undefined symbol "_sqrt"
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by LOAD.
> > Broken at BUILD-INTERPSYS.  Type :H for Help.
> > BOOT>>make[2]: ***
> > [/home/users/b/bi/billpage/osx/axiom.build-improvements/build
> > /powerpc-apple-darwin6.8/bin/interpsys] Error 255
> > make[1]: *** [interp/stamp] Error 2
> > make: *** [all-recursive] Error 1
> > ppc-osx3:~/osx/axiom.build-improvements $
> >
>
> Sigh.  As usual, I cannot reproduce on the mac to which I have
> access.  I'm assuming you see the same issue with
>
> (defun foo (x) (declare (long-float x)) (the long-float (sqrt x)))
> (compile 'foo)
>
> Am also assuming that the read-byte test I posted earlier now
> passes.
>

Yes. It seems that problem might be that 'sqrt' does not
appear in plt.h. So I added a call to sqrt(d); in plttest.c
and I am running it again.

Make sense?

> In any case, would you please mind stepping through gdb again to the
> same place?  It should be obvious what is going on.  The idea is that
> the MY_PLT list in plt.h should have one _ stripped, and that the
> string passed to my_plt should do the strip in the stn() C macro right
> before the (second) call to bsearch.
>
> I'll be leaving town tomorrow afternoon until Sunday, but would be
> happy to fix this quickly today if possible.
>

I will let you know.

\start
Date: 01 Nov 2006 12:37:50 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: gcl-2.6.8pre on MAC OSX 10.2

Greetings!

Bill Page writes:

> Camm, 
> 
> On Wednesday, November 01, 2006 9:47 AM you wrote:
> > Bill Page wrote:
> > > Ooops! Looks like the problem has shifted to another symbol. :-(
> > > 
> > > ... 
> > > Compiling
> > > 
> > /home/users/b/bi/billpage/osx/axiom.build-improvements/obj/powerpc-app
> > > le-darwin6.8/interp/g-util.lsp.
> > > ...skipping...
> > > Error: Undefined symbol "_sqrt"
> > > Fast links are on: do (si::use-fast-links nil) for debugging
> > > Error signalled by LOAD.
> > > Broken at BUILD-INTERPSYS.  Type :H for Help.
> > > BOOT>>make[2]: ***
> > > [/home/users/b/bi/billpage/osx/axiom.build-improvements/build
> > > /powerpc-apple-darwin6.8/bin/interpsys] Error 255
> > > make[1]: *** [interp/stamp] Error 2
> > > make: *** [all-recursive] Error 1
> > > ppc-osx3:~/osx/axiom.build-improvements $
> > > 
> > 
> > Sigh.  As usual, I cannot reproduce on the mac to which I have
> > access.  I'm assuming you see the same issue with
> > 
> > (defun foo (x) (declare (long-float x)) (the long-float (sqrt x)))
> > (compile 'foo)
> > 
> > Am also assuming that the read-byte test I posted earlier now
> > passes. 
> > 
> 
> Yes. It seems that problem might be that 'sqrt' does not
> appear in plt.h. So I added a call to sqrt(d); in plttest.c
> and I am running it again.
> 
> Make sense?
> 

Yes, indeed, and this is now committed.  Thanks!

As the comments in plt.c indicate, we still need a mechanism whereby
improvements to gcl_cmpopt.lsp (which result in writing more C symbols
into compiled files) seemlessly updates plttest.c.  Right now, we just
have to remember to make the change in both places, which in this case
failed :-(.

cvs head has a more thorough plttest which resists C optimizers'
attempts to eliminate dead code.  I see no reason for a backport at
the moment.

Take care,

> > In any case, would you please mind stepping through gdb again to the
> > same place?  It should be obvious what is going on.  The idea is that
> > the MY_PLT list in plt.h should have one _ stripped, and that the
> > string passed to my_plt should do the strip in the stn() C macro right
> > before the (second) call to bsearch.
> > 
> > I'll be leaving town tomorrow afternoon until Sunday, but would be
> > happy to fix this quickly today if possible.
> > 
> 
> I will let you know.

\start
Date: Wed, 1 Nov 2006 12:47:30 -0500
From: Bill Page
To: Camm Maguire
Subject: RE: gcl-2.6.8pre on MAC OSX 10.2

Camm,

On Wednesday, November 01, 2006 10:27 AM I wrote:
> ...
> It seems that problem might be that 'sqrt' does not appear in
> plt.h. So I added a call to sqrt(d); in plttest.c and I am
> running it again.
> ...

Ok, with your earlier change plus adding 'sqrt(d);' to plttest.c
that did it! At least I think so. The Axiom build is still
proceeding but it is well into the algebra compiles now and it
seldom fails in gcl if it gets this far... This machine is
pretty slow, so it'll probably two or three hours to complete.

Here's the patch:

ppc-osx3:~/osx $ diff -au old/gcl*/o/plttest.c new/gcl*/o/plttest.c
--- old/gcl-2.6.8pre/o/plttest.c        Thu Dec 15 10:14:18 2005
+++ new/gcl-2.6.8pre/o/plttest.c        Wed Nov  1 07:22:26 2006
@@ -40,7 +40,7 @@

   exp(d);
   log(d);
-
+  sqrt(d);
   return 0;

 }
ppc-osx3:~/osx $

--------

The only other problem I encountered is a problem with the
Axiom source, I think. All occurrence of

  echo ')load ${OUT}/xxxx' >> ...

in the src/*/Makefile.pamphlet files had to be replaced with

  echo ')load ${OUT}/xxxx.${OUTEXT}' >> ...

Without the extension the build fails looking for a file
names xxxx.8

I don't know where the .8 comes from, but I think it must
have something to do with how Axiom handles the default
extension. Although I am surprised that I have only seen
this here on this PowerPC OSX 10.2 platform and not on any
other builds... ???

I'll send a patch for Axiom after I get a change to repeat
the Axiom build with a newer version of build-improvements.

Thanks for all your help!

Regards,
Bill Page.

PS. Does anyone want me to try an gcl-based Maxima build
on this OSX machine?

\start
Date: 01 Nov 2006 19:02:53 +0100
From: Martin Rubey
To: Bill Page, Antoine Hersen
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

Bill Page writes:

> Camm, 
> 
> On Wednesday, November 01, 2006 10:27 AM I wrote:
> > ...
> > It seems that problem might be that 'sqrt' does not appear in
> > plt.h. So I added a call to sqrt(d); in plttest.c and I am
> > running it again.
> > ... 
> 
> Ok, with your earlier change plus adding 'sqrt(d);' to plttest.c
> that did it! At least I think so. The Axiom build is still
> proceeding but it is well into the algebra compiles now and it
> seldom fails in gcl if it gets this far... This machine is
> pretty slow, so it'll probably two or three hours to complete.

WOW, that's cool! Axiom on the Mac!

\start
Date: Wed, 1 Nov 2006 19:16:12 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: sock_get_string_buf
Cc: Camm Maguire

I again had problem with "sock_get_string_buf": trying to use hypertex
functions which require Axiom (for example search or tutorial input)
gives:

(1) ->
   >> System error:
   Unexpected end of #<string-input stream from "                ...">.

Recent patch to gcl fixed the problem on many machines. But on one
machine (using 2.4.31 kerenel) I was still getting this error.

So I tried the patch below and it solved the problem.  AFAICS the
problem is that GCL string parameter wants to preserve string
_value_, but what Axiom want is pass by reference.  My undersanding
is that GCL has full right to copy the string, so the only relaiable
solution must use 'object' type and extract string address from it.

Remark1: It seems that "official" GCL foreign function interface is
is very incomplete for real world needs. I would suggest either
promoting 'object' structure as documented, official low level
interface, or adding few more arguments types (mostly arrays by reference).

Remark 2: This may be related to Debian bug 328480 (but what Camm
wrote seem indicate different problem).



diff -ru pp/build-improvements/src/interp/sockio.lisp.pamphlet build-improvements/src/interp/sockio.lisp.pamphlet
--- pp/build-improvements/src/interp/sockio.lisp.pamphlet	Sun Oct 29 21:57:59 2006
+++ build-improvements/src/interp/sockio.lisp.pamphlet	Sun Oct 29 13:33:48 2006
@@ -73,10 +73,14 @@
 (progn
   (clines "extern double plus_infinity(), minus_infinity(), NANQ();")
   (clines "extern double sock_get_float();")
+  (clines "int sock_get_string_buf_wrapper(int i, object x, int j)"
+          "{ if (type_of(x)!=t_string) FEwrong_type_argument(sLstring,x);"
+          "   return sock_get_string_buf(i, x->st.st_self, j); }")
   (defentry open_server (string) (int "open_server"))
   (defentry sock_get_int (int) (int "sock_get_int"))
   (defentry sock_send_int (int int) (int "sock_send_int"))
-  (defentry sock_get_string_buf (int string int) (int "sock_get_string_buf"))
+  (defentry sock_get_string_buf (int object int) 
+     (int "sock_get_string_buf_wrapper"))
   (defentry sock_send_string_len (int string int) (int "sock_send_string_len"))
   (defentry sock_get_float (int) (double "sock_get_float"))
   (defentry sock_send_float (int double) (int "sock_send_float"))

\start
Date: Wed, 01 Nov 2006 14:23:04 -0400
From: Humberto Zuazaga
To: list
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Martin Rubey wrote:

> WOW, that's cool! Axiom on the Mac!
> 

I have PowerPC and Intel Macs running OS X 10.4.8 with fink, and I'd 
like to try building axiom on them as well.

Are these changes in the build-improvements branch?

\start
Date: Wed, 1 Nov 2006 19:44:33 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: silver--1--patch-10

> axiom--silver--1--patch-10 is available
> 
> Improve the database documentation
> 
> 20061031 tpd src/interp/daase.lisp add database documentation
> 20061031 tpd src/etc/asq.c add database documentation
> 

You should add that 'asq' does not work with uncompressed databases.

\start
Date: Wed, 1 Nov 2006 14:00:10 -0500
From: Bill Page
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On Wednesday, November 01, 2006 1:23 PM Humberto Ortiz Zuazaga wrote:
>
> Martin Rubey wrote:
>
> > WOW, that's cool! Axiom on the Mac!
> >
>
> I have PowerPC and Intel Macs running OS X 10.4.8 with fink, and
> I'd like to try building axiom on them as well.

Great!

>
> Are these changes in the build-improvements branch?
>

No, not everything is in build-improvements yet - give us a few
more hours. :-)

In the mean time I would be very interested if you could start
by just trying to buiuld the gcl lisp compiler. This is a pre-
requiste for the Axiom build. You can get the version we will be
using in build-improvements directly from the gcl CVS archive via
the command line:

$ cvs -d :pserver:anonymous@cvs.sv.gnu.org:/sources/gcl -z9 export \
  -Dtoday -d gcl-2.6.8pre -r Version_2_6_8pre gcl

and then do

$ cd gcl-2.6.8pre
$ ./configure --prefix=/usr/local
$ make

Ask if you need mor details. Let us know how it works.

\start
Date: Wed, 1 Nov 2006 20:17:07 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: util.ht

Axiom sources contain two copies of 'util.ht': one is
'src/hyper/pages/util.ht', the second is
'src/share/doc/hypertex/pages/util.ht'.  This causes build problems
since when re-making different copy may be installed. Also
'ht.db' is build when pages from 'src/hyper/pages' (including 'util.ht')
are installed. If 'src/share/doc/hypertex/pages/util.ht' is intalled
later it makes 'ht.db' out of date.

I would propose removing one copy of 'util.ht' (removing
'src/share/doc/hypertex/pages/util.ht' would make Makefile logic
simpler, so IMHO this one is preferred).  Also, 'src/hyper/pages/ht.db'
us useless (it should be re-created by the build process) and
potentially confusing (it may easily get out of date), so
it should be also removed from the repository.

\start
Date: 01 Nov 2006 16:16:51 -0500
From: Camm Maguire
To: Waldek Hebisch
Subject: Re: sock_get_string_buf

Greetings, and thanks so much!

Waldek Hebisch writes:

> I again had problem with "sock_get_string_buf": trying to use hypertex
> functions which require Axiom (for example search or tutorial input)
> gives:
> 
> (1) ->
>    >> System error:
>    Unexpected end of #<string-input stream from "                ...">.
> 
> Recent patch to gcl fixed the problem on many machines. But on one
> machine (using 2.4.31 kerenel) I was still getting this error.
> 
> So I tried the patch below and it solved the problem.  AFAICS the
> problem is that GCL string parameter wants to preserve string
> _value_, but what Axiom want is pass by reference.  My undersanding
> is that GCL has full right to copy the string, so the only relaiable
> solution must use 'object' type and extract string address from it.
> 
> Remark1: It seems that "official" GCL foreign function interface is
> is very incomplete for real world needs. I would suggest either
> promoting 'object' structure as documented, official low level
> interface, or adding few more arguments types (mostly arrays by reference).
> 
> Remark 2: This may be related to Debian bug 328480 (but what Camm
> wrote seem indicate different problem).
> 

This indeed fixes the above -- thanks!  Some axiom code must be
declining do write to a copied buffer or some such.

May I suggest adding

          "   if (x->st.st_fillp<j) FEerror(\"string too small\",0);"

to the wrapper.  In general, we might want a non-null terminated
buffer type of a given length in the C interface too.  I'm guessing
this is what you mean by arrays by reference.  Documenting object is a
good idea too.

Last comment -- GCL stores strings by default in relocatable memory --
i.e. they are copied at each gc.  This is much faster.  An immovable
type in 'contiguous" memory is also an option, via

(make-array 10 :element-type 'character :static t)

If axiom needs these pointers not to move across gc, may I please
suggest using the latter.  I've already checked, the pointers in use
are relocatable.

I'll apply this patch and upload a new Debian package closing the
bug.  BTW, axiom is again in Debian testing (aka etch).

Take care,

> 
> 
> diff -ru pp/build-improvements/src/interp/sockio.lisp.pamphlet build-improvements/src/interp/sockio.lisp.pamphlet
> --- pp/build-improvements/src/interp/sockio.lisp.pamphlet	Sun Oct 29 21:57:59 2006
> +++ build-improvements/src/interp/sockio.lisp.pamphlet	Sun Oct 29 13:33:48 2006
> @@ -73,10 +73,14 @@
>  (progn
>    (clines "extern double plus_infinity(), minus_infinity(), NANQ();")
>    (clines "extern double sock_get_float();")
> +  (clines "int sock_get_string_buf_wrapper(int i, object x, int j)"
> +          "{ if (type_of(x)!=t_string) FEwrong_type_argument(sLstring,x);"
> +          "   return sock_get_string_buf(i, x->st.st_self, j); }")
>    (defentry open_server (string) (int "open_server"))
>    (defentry sock_get_int (int) (int "sock_get_int"))
>    (defentry sock_send_int (int int) (int "sock_send_int"))
> -  (defentry sock_get_string_buf (int string int) (int "sock_get_string_buf"))
> +  (defentry sock_get_string_buf (int object int) 
> +     (int "sock_get_string_buf_wrapper"))
>    (defentry sock_send_string_len (int string int) (int "sock_send_string_len"))
>    (defentry sock_get_float (int) (double "sock_get_float"))
>    (defentry sock_send_float (int double) (int "sock_send_float"))
> 

\start
Date: Wed, 1 Nov 2006 23:20:30 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: hypertex and uses info

All versions of hypertex that I used crashed (or maybe showed nothing)
when I clicked "Uses" or "Dependants" field in a description of a constructor.

AFAICS recent versions of Axiom have two problems here:

1) databases which contain corresponding information (USERS.DAASE
   and DEPENDENTS.DAASE) were not installed
2) infamous 'probe-file' problem

The patch below correct both problems. It also fixes the
"Cannot rename the file erlib to NRLIB" problem. I also added
sensible dependency in database rule, so that all databses
are re-made when one get out of date. And 'RDEFIOSTREAM' is
now called in error-checking mode (old code happily passed
bad pathnames and supressed error checking).


diff -ru build-improvements.pp/src/etc/Makefile.in build-improvements/src/etc/Makefile.in
--- build-improvements.pp/src/etc/Makefile.in	2006-11-01 19:33:11.000000000 +0100
+++ build-improvements/src/etc/Makefile.in	2006-11-01 19:36:00.000000000 +0100
@@ -2,6 +2,10 @@
 MID=${OBJ}/${SYS}/etc
 DOC=${INT}/doc/src/etc
 INTERPSYS=$(axiom_build_bindir)/interpsys
+DATABASES_SHORT=compress.daase interp.daase browse.daase category.daase \
+                operation.daase libdb.text comdb.text USERS.DAASE/index.KAF \
+                DEPENDENTS.DAASE/index.KAF
+DATABASES=$(addprefix $(axiom_targetdir)/algebra/, $(DATABASES_SHORT))
 
 subdir = src/etc/
 
@@ -10,7 +14,7 @@
 
 all: all-ax
 
-all-ax: $(axiom_targetdir)/algebra/*.daase $(axiom_target_bindir)/asq \
+all-ax: $(DATABASES) $(axiom_target_bindir)/asq \
 		$(axiom_target_libdir)/summary \
 		$(axiom_target_libdir)/copyright \
 		$(axiom_target_bindir)/axiom
@@ -18,8 +22,8 @@
 	-rm -f stamp
 	$(STAMP) stamp
 
-$(axiom_targetdir)/algebra/*.daase: ${INT}/algebra/*.NRLIB/code.o
-	@ echo 4 rebuilding databases...
+$(DATABASES): ${INT}/algebra/*.NRLIB/code.o
+	@ echo 4 rebuilding databases ...
 	@ cp $(axiom_src_docdir)/gloss.text ${INT}/algebra
 	@ cp $(axiom_src_docdir)/gloss.text ${INT}/algebra
 	@ cp $(axiom_src_docdir)/topics.data ${INT}/algebra
@@ -29,6 +33,12 @@
 	@ $(INSTALL_DATA) ${INT}/algebra/*.daase $(axiom_targetdir)/algebra
 	@ $(INSTALL_DATA) ${INT}/algebra/libdb.text $(axiom_targetdir)/algebra
 	@ $(INSTALL_DATA) ${INT}/algebra/comdb.text $(axiom_targetdir)/algebra
+	@ $(mkinstalldirs) $(axiom_targetdir)/algebra/USERS.DAASE \
+             $(axiom_targetdir)/algebra/DEPENDENTS.DAASE
+	@ $(INSTALL_DATA) ${INT}/algebra/USERS.DAASE/index.KAF \
+                   $(axiom_targetdir)/algebra/USERS.DAASE
+	@ $(INSTALL_DATA) ${INT}/algebra/DEPENDENTS.DAASE/index.KAF \
+                   $(axiom_targetdir)/algebra/DEPENDENTS.DAASE
 
 asq_sources = asq.c
 asq_SOURCES = $(addsuffix .pamphlet, $(asq_sources))
Tylko w build-improvements/src/etc: Makefile.in.orig
diff -ru build-improvements.pp/src/etc/Makefile.pamphlet build-improvements/src/etc/Makefile.pamphlet
--- build-improvements.pp/src/etc/Makefile.pamphlet	2006-11-01 19:33:11.000000000 +0100
+++ build-improvements/src/etc/Makefile.pamphlet	2006-11-01 19:36:00.000000000 +0100
@@ -26,8 +26,8 @@
 the databases. If any if any of these are changed, the databases must
 be re-built.
 <<dbcomplete>>=
-$(axiom_targetdir)/algebra/*.daase: ${INT}/algebra/*.NRLIB/code.o
-	@ echo 4 rebuilding databases...
+$(DATABASES): ${INT}/algebra/*.NRLIB/code.o
+	@ echo 4 rebuilding databases ...
 	@ cp $(axiom_src_docdir)/gloss.text ${INT}/algebra
 	@ cp $(axiom_src_docdir)/gloss.text ${INT}/algebra
 	@ cp $(axiom_src_docdir)/topics.data ${INT}/algebra
@@ -37,6 +37,12 @@
 	@ $(INSTALL_DATA) ${INT}/algebra/*.daase $(axiom_targetdir)/algebra
 	@ $(INSTALL_DATA) ${INT}/algebra/libdb.text $(axiom_targetdir)/algebra
 	@ $(INSTALL_DATA) ${INT}/algebra/comdb.text $(axiom_targetdir)/algebra
+	@ $(mkinstalldirs) $(axiom_targetdir)/algebra/USERS.DAASE \
+             $(axiom_targetdir)/algebra/DEPENDENTS.DAASE
+	@ $(INSTALL_DATA) ${INT}/algebra/USERS.DAASE/index.KAF \
+                   $(axiom_targetdir)/algebra/USERS.DAASE
+	@ $(INSTALL_DATA) ${INT}/algebra/DEPENDENTS.DAASE/index.KAF \
+                   $(axiom_targetdir)/algebra/DEPENDENTS.DAASE
 
 @
 \section{summary}
@@ -90,6 +96,10 @@
 MID=${OBJ}/${SYS}/etc
 DOC=${INT}/doc/src/etc
 INTERPSYS=$(axiom_build_bindir)/interpsys
+DATABASES_SHORT=compress.daase interp.daase browse.daase category.daase \
+                operation.daase libdb.text comdb.text USERS.DAASE/index.KAF \
+                DEPENDENTS.DAASE/index.KAF
+DATABASES=$(addprefix $(axiom_targetdir)/algebra/, $(DATABASES_SHORT))
 
 subdir = src/etc/
 
@@ -98,7 +108,7 @@
 
 all: all-ax
 
-all-ax: $(axiom_targetdir)/algebra/*.daase $(axiom_target_bindir)/asq \
+all-ax: $(DATABASES) $(axiom_target_bindir)/asq \
 		$(axiom_target_libdir)/summary \
 		$(axiom_target_libdir)/copyright \
 		$(axiom_target_bindir)/axiom
Tylko w build-improvements/src/etc: Makefile.pamphlet.orig
diff -ru build-improvements.pp/src/interp/lisplib.boot.pamphlet build-improvements/src/interp/lisplib.boot.pamphlet
--- build-improvements.pp/src/interp/lisplib.boot.pamphlet	2006-11-01 19:33:09.000000000 +0100
+++ build-improvements/src/interp/lisplib.boot.pamphlet	2006-11-01 19:36:52.000000000 +0100
@@ -56,9 +56,8 @@
   readLibPathFast p
  
 readLibPathFast p ==
-  -- assumes 1) p is a valid pathname
-  --         2) file has already been checked for existence
-  RDEFIOSTREAM([['FILE,:p], '(MODE . INPUT)],false)
+  -- DO NOT assume that p is a valid pathname
+  RDEFIOSTREAM([['FILE,:p], '(MODE . INPUT)])
  
 writeLib(fn,ft) == writeLib1(fn,ft,"*")
  
diff -ru build-improvements.pp/src/interp/nlib.lisp.pamphlet build-improvements/src/interp/nlib.lisp.pamphlet
--- build-improvements.pp/src/interp/nlib.lisp.pamphlet	2006-11-01 19:33:09.000000000 +0100
+++ build-improvements/src/interp/nlib.lisp.pamphlet	2006-11-01 19:36:00.000000000 +0100
@@ -448,17 +448,23 @@
                       :test #'string=) 
               :test #'string=))))
 
+(defun axiom-probe-file (file)
+    (if (equal (|directoryp| file) -1)
+         nil
+         (truename file))
+)
+
 (defun make-input-filename (filearg &optional (filetype nil))
    (let*
      ((filename  (make-filename filearg filetype))
       (dirname (pathname-directory filename))
       (ft (pathname-type filename))
       (dirs (get-directory-list ft))
-      (newfn nil))   
+      (newfn nil))
     (if (or (null dirname) (eqcar dirname :relative))
 	(dolist (dir dirs (probe-name filename))
 		(when 
-		 (probe-file 
+		 (axiom-probe-file 
 		  (setq newfn (concatenate 'string dir filename)))
 		 (return newfn)))
       (probe-name filename))))
@@ -476,7 +482,7 @@
 ;; ($ERASE filearg) -> 0 if succeeds else 1
 (defun $erase (&rest filearg)
   (setq filearg (make-full-namestring filearg))
-  (if (probe-file filearg)
+  (if (axiom-probe-file filearg)
 #+:CCL (delete-file filearg)
 #+:AKCL
       (if (library-file filearg)

\start
Date: Wed, 01 Nov 2006 23:38:47 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: hypertex and uses info

Le mercredi 01 novembre 2006 =E0 23:20 +0100, Waldek Hebisch a =E9crit :

[...]
 
> diff -ru build-improvements.pp/src/interp/nlib.lisp.pamphlet build-impr=
ovements/src/interp/nlib.lisp.pamphlet
> --- build-improvements.pp/src/interp/nlib.lisp.pamphlet	2006-11-01 19:3=
3:09.000000000 +0100
> +++ build-improvements/src/interp/nlib.lisp.pamphlet	2006-11-01 19:36:0=
0.000000000 +0100
> @@ -448,17 +448,23 @@
>                        :test #'string=)
>                :test #'string=))))
> 
> +(defun axiom-probe-file (file)
> +    (if (equal (|directoryp| file) -1)
> +         nil
> +         (truename file))
> +)
> +
>  (defun make-input-filename (filearg &optional (filetype nil))
>     (let*
>       ((filename  (make-filename filearg filetype))
>        (dirname (pathname-directory filename))
>        (ft (pathname-type filename))
>        (dirs (get-directory-list ft))
> -      (newfn nil))  
> +      (newfn nil))
>      (if (or (null dirname) (eqcar dirname :relative))
>  	(dolist (dir dirs (probe-name filename))
>  		(when
> -		 (probe-file
> +		 (axiom-probe-file
>  		  (setq newfn (concatenate 'string dir filename)))
>  		 (return newfn)))
>        (probe-name filename))))
> @@ -476,7 +482,7 @@
>  ;; ($ERASE filearg) -> 0 if succeeds else 1
>  (defun $erase (&rest filearg)
>    (setq filearg (make-full-namestring filearg))
> -  (if (probe-file filearg)
> +  (if (axiom-probe-file filearg)
>  #+:CCL (delete-file filearg)
>  #+:AKCL
>        (if (library-file filearg)


Why not modifying and using probe-name ? Actually I use:

@@ -436,7 +436,11 @@
   (namestring (merge-pathnames (make-filename filearg filetype))))

 (defun probe-name (file)
-  (if (probe-file file) (namestring file) nil))
+  (cond
+    ; no need to use namestring, it is already a string
+    ((probe-file file) file)
+    ((eql (|directoryp| file) 1) (namestring (truename file)))
+    (t nil)))

 (defun get-directory-list (ft &aux (cd (namestring
$current-directory)))
   (cond ((member ft '("NRLIB" "DAASE" "EXPOSED") :test #'string=)
@@ -457,8 +461,8 @@
       (newfn nil))  
     (if (or (null dirname) (eqcar dirname :relative))
        (dolist (dir dirs (probe-name filename))
-               (when
-                (probe-file
+               (when
+                 (probe-name
                  (setq newfn (concatenate 'string dir filename)))
                 (return newfn)))
       (probe-name filename))))

It's just what I use, not that I disagree.

Greg

PS: For $erase (see another mail) I directly use directoryp.

\start
Date: Thu, 2 Nov 2006 00:08:23 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: hypertex and uses info

Vanuxem Gr=E9gory wrote:
> Le mercredi 01 novembre 2006 ? 23:20 +0100, Waldek Hebisch a =E9crit :
>
> [...]
>  
> > diff -ru build-improvements.pp/src/interp/nlib.lisp.pamphlet build-impr=
ovements/src/interp/nlib.lisp.pamphlet
> > --- build-improvements.pp/src/interp/nlib.lisp.pamphlet	2006-11-01 19:3=
3:09.000000000 +0100
> > +++ build-improvements/src/interp/nlib.lisp.pamphlet	2006-11-01 19:36:0=
0.000000000 +0100
> > @@ -448,17 +448,23 @@
> >                        :test #'string=)
> >                :test #'string=))))
> > 
> > +(defun axiom-probe-file (file)
> > +    (if (equal (|directoryp| file) -1)
> > +         nil
> > +         (truename file))
> > +)
> > +
> >  (defun make-input-filename (filearg &optional (filetype nil))
> >     (let*
> >       ((filename  (make-filename filearg filetype))
> >        (dirname (pathname-directory filename))
> >        (ft (pathname-type filename))
> >        (dirs (get-directory-list ft))
> > -      (newfn nil))  
> > +      (newfn nil))
> >      (if (or (null dirname) (eqcar dirname :relative))
> >  	(dolist (dir dirs (probe-name filename))
> >  		(when
> > -		 (probe-file
> > +		 (axiom-probe-file
> >  		  (setq newfn (concatenate 'string dir filename)))
> >  		 (return newfn)))
> >        (probe-name filename))))
> > @@ -476,7 +482,7 @@
> >  ;; ($ERASE filearg) -> 0 if succeeds else 1
> >  (defun $erase (&rest filearg)
> >    (setq filearg (make-full-namestring filearg))
> > -  (if (probe-file filearg)
> > +  (if (axiom-probe-file filearg)
> >  #+:CCL (delete-file filearg)
> >  #+:AKCL
> >        (if (library-file filearg)
>
>
> Why not modifying and using probe-name ? Actually I use:
>
> @@ -436,7 +436,11 @@
>    (namestring (merge-pathnames (make-filename filearg filetype))))
> 
>  (defun probe-name (file)
> -  (if (probe-file file) (namestring file) nil))
> +  (cond
> +    ; no need to use namestring, it is already a string
> +    ((probe-file file) file)
> +    ((eql (|directoryp| file) 1) (namestring (truename file)))
> +    (t nil)))
> 
>  (defun get-directory-list (ft &aux (cd (namestring
> $current-directory)))
>    (cond ((member ft '("NRLIB" "DAASE" "EXPOSED") :test #'string=)
> @@ -457,8 +461,8 @@
>        (newfn nil))  
>      (if (or (null dirname) (eqcar dirname :relative))
>         (dolist (dir dirs (probe-name filename))
> -               (when
> -                (probe-file
> +               (when
> +                 (probe-name
>                   (setq newfn (concatenate 'string dir filename)))
>                  (return newfn)))
>        (probe-name filename))))
>
> It's just what I use, not that I disagree.
>
> Greg
>
> PS: For $erase (see another mail) I directly use directoryp.

No very strong reason. However:

1) 'axiom-probe-file' is intended to be good replacement for 'probe-file'.
   More precisely, Axiom uses directories to implement what Microsoft
   would call "structured storage" and old IBM systems called "partitioned
   data sets". Such directories from Axiom point of view are equivalent
   to files.
2) I did not check all uses of 'probe-name', so it was not clear if
   change in 'probe-name' is apropriate.
3) 'probe-name' is doing a lot of extra work (calls 'probe-file' first,
   then calls 'namestring'

Concerning erase: I would prefer to limit use of 'directoryp':
something which has name endig in 'p' should return a boolean.
What 'directoryp' returns is unexepected, so wide use of 'directoryp'
would make interpreter code hareder to read.

\start
Date: Wed, 1 Nov 2006 18:04:51 -0500
From: Bill Page
To: Martin Rubey
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

On Wednesday, November 01, 2006 1:03 PM Martin Rubey wrote:
> ...
> WOW, that's cool! Axiom on the Mac!
>

Well, the build of AXIOMsys completed successfully. You can
download a console-only version of Axiom for native MAC OSX 10
on PowerPC here:

http://wiki.axiom-developer.org/public/AXIOMsys-ppc-20061101.tgz

As usual, untar it into a convenient place like /usr/local

  $ cd /usr/local
  $ tar xzf ~/AXIOMsys-ppc-20061101.tgz

and then setup the AXIOM and PATH variables like this:

  $ export AXIOM=/usr/local/powerpc-apple-darwin6.8
  $ export PATH=$AXIOM/bin:$PATH

and start Axiom like this:

  $ AXIOMsys

  (1) -> integrate(1/sqrt(1-x^2),x)

exit Axiom with this command:

  (99) -> )quit
  yes

--------

The MAC server on which this was compiled did not have an X-windows
environment so it was not possible to compile and test Axiom Graphics
and the Hyperdoc browser. Also native MAC OSX10 apparently does not
have support for the pts virtual terminal interface so it is not
possible yet to compile clef (the replacement for readline).

Because of these problems, it is not possible to use the existing
Axiom source distribution without some changes to accommodate
the limited hardware environment. But if you are familiar with
development on a MAC and would like to give this a try, please
let you know and I can make the current preliminary sources
available.

I look forward to some comments from MAC users! :-)

\start
Date: 01 Nov 2006 18:29:55 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: gcl-2.6.8pre on MAC OSX 10.2

Greetings!

Bill Page writes:

> Camm, 
> 
> On Wednesday, November 01, 2006 10:27 AM I wrote:
> > ...
> > It seems that problem might be that 'sqrt' does not appear in
> > plt.h. So I added a call to sqrt(d); in plttest.c and I am
> > running it again.
> > ... 
> 
> Ok, with your earlier change plus adding 'sqrt(d);' to plttest.c
> that did it! At least I think so. The Axiom build is still
> proceeding but it is well into the algebra compiles now and it
> seldom fails in gcl if it gets this far... This machine is
> pretty slow, so it'll probably two or three hours to complete.
> 
> Here's the patch:
> 
> ppc-osx3:~/osx $ diff -au old/gcl*/o/plttest.c new/gcl*/o/plttest.c
> --- old/gcl-2.6.8pre/o/plttest.c        Thu Dec 15 10:14:18 2005
> +++ new/gcl-2.6.8pre/o/plttest.c        Wed Nov  1 07:22:26 2006
> @@ -40,7 +40,7 @@
> 
>    exp(d);
>    log(d);
> -
> +  sqrt(d);
>    return 0;
> 
>  }
> ppc-osx3:~/osx $
> 
> --------
> 
> The only other problem I encountered is a problem with the
> Axiom source, I think. All occurrence of
> 
>   echo ')load ${OUT}/xxxx' >> ...
> 
> in the src/*/Makefile.pamphlet files had to be replaced with
> 
>   echo ')load ${OUT}/xxxx.${OUTEXT}' >> ...
> 
> Without the extension the build fails looking for a file
> names xxxx.8
> 

OK, as you've gotten a successful build, there is really very little
chance of memory corruption.  And I'm surmising that the larger
save-system image has to do with the native unexmacosx code we have
courtesy of Aurelien.  In fact, I have never really studied this code,
so he is currently the only person in the world likely to have such
knowledge at the moment!

This .8 is still odd.  Might be interesting to add )lisp
si::*load-types* somewhere to examine the defaults.

> I don't know where the .8 comes from, but I think it must
> have something to do with how Axiom handles the default
> extension. Although I am surprised that I have only seen
> this here on this PowerPC OSX 10.2 platform and not on any
> other builds... ???
> 
> I'll send a patch for Axiom after I get a change to repeat
> the Axiom build with a newer version of build-improvements.
> 
> Thanks for all your help!
> 
> Regards,
> Bill Page.
> 
> PS. Does anyone want me to try an gcl-based Maxima build
> on this OSX machine?
> 

I've built macosx maxima in the past, but youre mileage may vary :-). 

I am concluding that with the possible exception of fc6, gcl 2.6.8 is
ready vis a vis axiom.  It would be most helpful if someone could
confirm the Fedora status for me.

\start
Date: 02 Nov 2006 00:33:20 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: hypertex and uses info

Waldek Hebisch writes:

> All versions of hypertex that I used crashed (or maybe showed nothing)
> when I clicked "Uses" or "Dependants" field in a description of a constructor.
> 
> AFAICS recent versions of Axiom have two problems here:
> 
> 1) databases which contain corresponding information (USERS.DAASE
>    and DEPENDENTS.DAASE) were not installed
> 2) infamous 'probe-file' problem
> 
> The patch below correct both problems. It also fixes the
> "Cannot rename the file erlib to NRLIB" problem. I also added
> sensible dependency in database rule, so that all databses
> are re-made when one get out of date. And 'RDEFIOSTREAM' is
> now called in error-checking mode (old code happily passed
> bad pathnames and supressed error checking).

Does this mean that "uses" works now?

If so, I have to get build improvements immediately!

\start
Date: Thu, 2 Nov 2006 00:33:45 +0100 (CET)
From: Waldek Hebisch
To: Camm Maguire
Subject: Re: sock_get_string_buf

> Greetings, and thanks so much!
> 
> Waldek Hebisch writes:
> 
> > I again had problem with "sock_get_string_buf": trying to use hypertex
> > functions which require Axiom (for example search or tutorial input)
> > gives:
> > 
> > (1) ->
> >    >> System error:
> >    Unexpected end of #<string-input stream from "                ...">.
> > 
> > Recent patch to gcl fixed the problem on many machines. But on one
> > machine (using 2.4.31 kerenel) I was still getting this error.
> > 
> > So I tried the patch below and it solved the problem.  AFAICS the
> > problem is that GCL string parameter wants to preserve string
> > _value_, but what Axiom want is pass by reference.  My undersanding
> > is that GCL has full right to copy the string, so the only relaiable
> > solution must use 'object' type and extract string address from it.
> > 
> > Remark1: It seems that "official" GCL foreign function interface is
> > is very incomplete for real world needs. I would suggest either
> > promoting 'object' structure as documented, official low level
> > interface, or adding few more arguments types (mostly arrays by reference).
> > 
> > Remark 2: This may be related to Debian bug 328480 (but what Camm
> > wrote seem indicate different problem).
> > 
> 
> This indeed fixes the above -- thanks!  Some axiom code must be
> declining do write to a copied buffer or some such.
> 
> May I suggest adding
> 
>           "   if (x->st.st_fillp<j) FEerror(\"string too small\",0);"
>

Yes, good idea.
 
> to the wrapper.  In general, we might want a non-null terminated
> buffer type of a given length in the C interface too.  I'm guessing
> this is what you mean by arrays by reference.  Documenting object is a
> good idea too.
> 

Typical uses I can see are:

1) calling operating system.  This typically uses scalars and strings,
   but may require structures.
2) calling numerial librarires.  Such librarires typically operate
   on floating point arrays, but may also need integer arrays.

While support for C structures would be nice, one can use arrays
of apropriate size and use Lisp byte operations to emulate C
structures.  OTOH direct support for arrays seems essential.

> Last comment -- GCL stores strings by default in relocatable memory --
> i.e. they are copied at each gc.  This is much faster.  An immovable
> type in 'contiguous" memory is also an option, via
> 
> (make-array 10 :element-type 'character :static t)
> 
> If axiom needs these pointers not to move across gc, may I please
> suggest using the latter.  I've already checked, the pointers in use
> are relocatable.
> 

AFAICS C code does not store pointers to Lisp data (and there are no
callbacks from C to Lisp). If (as I hope) GCL will not trigger garbage
collection form a signal handler, keeping strings in relocatable memory
should be safe.

\start
Date: Thu, 2 Nov 2006 00:38:38 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: hypertex and uses info

> Waldek Hebisch writes:
> 
> > All versions of hypertex that I used crashed (or maybe showed nothing)
> > when I clicked "Uses" or "Dependants" field in a description of a constructor.
> > 
> > AFAICS recent versions of Axiom have two problems here:
> > 
> > 1) databases which contain corresponding information (USERS.DAASE
> >    and DEPENDENTS.DAASE) were not installed
> > 2) infamous 'probe-file' problem
> > 
> > The patch below correct both problems. It also fixes the
> > "Cannot rename the file erlib to NRLIB" problem. I also added
> > sensible dependency in database rule, so that all databses
> > are re-made when one get out of date. And 'RDEFIOSTREAM' is
> > now called in error-checking mode (old code happily passed
> > bad pathnames and supressed error checking).
> 
> Does this mean that "uses" works now?
> 
> If so, I have to get build improvements immediately!
>

With the patch yes (ATM the patch is not commited). 

\start
Date: Thu, 02 Nov 2006 00:48:56 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: hypertex and uses info

Le jeudi 02 novembre 2006 =E0 00:08 +0100, Waldek Hebisch a =E9crit :
[...]
> No very strong reason. However:
>
> 1) 'axiom-probe-file' is intended to be good replacement for 'probe-fil=
e'.
>    More precisely, Axiom uses directories to implement what Microsoft
>    would call "structured storage" and old IBM systems called "partitio=
ned
>    data sets". Such directories from Axiom point of view are equivalent
>    to files.

I have no knowledge on this.

> 2) I did not check all uses of 'probe-name', so it was not clear if
>    change in 'probe-name' is apropriate.

As far as I know probe-name is only used in nlib.lisp.pamphlet.

> 3) 'probe-name' is doing a lot of extra work (calls 'probe-file' first,
>    then calls 'namestring'

Yes, and namestring is not necessary.

> Concerning erase: I would prefer to limit use of 'directoryp':
> something which has name endig in 'p' should return a boolean.
> What 'directoryp' returns is unexepected, so wide use of 'directoryp'
> would make interpreter code hareder to read.

Yes, not the lisp convention.

Anyway these things need to be fixed, no matter for me how this will be
done. Thank you so much (as Martin implicitly says :-). I am, as Martin,
a Hyperdoc adept.

\start
Date: 02 Nov 2006 00:49:05 +0100
From: Gabriel Dos Reis
To: list
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:


[...]

| The MAC server on which this was compiled did not have an X-windows
| environment so it was not possible to compile and test Axiom Graphics
| and the Hyperdoc browser. Also native MAC OSX10 apparently does not
| have support for the pts virtual terminal interface so it is not
| possible yet to compile clef (the replacement for readline).

I never quite understood why readline needs to be replaced.  Do you know?

\start
Date: Wed, 1 Nov 2006 19:05:52 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On Wednesday, November 01, 2006 6:49 PM Gabriel Dos Reis wrote:

> | ... Also native MAC OSX10 apparently does not
> | have support for the pts virtual terminal interface so it is
> | not possible yet to compile clef (the replacement for readline).
>
> I never quite understood why readline needs to be replaced. 
> Do you know?
>

I think the foremost reason is that clef (aka. "edible") was part
of Axiom long before readline existed.

Second, clef does have some Axiom command completions that are not
built-in to readline but I think readline is also configurable,
and could provide such functionality, right?

Third, to the best of my knowledge readline is the only part of
GCL that is licenses as GPL. If readline is disabled, then GCL might
be considered compatible with Axiom's BSD-style non-copyleft license.
(I am not sure if this is important to anyone interesting in Axiom
any more.)

Personally, I would prefer to get rid of clef and adapt readline
because it would simply the Axiom process tree structure. On the
other hand, readline can be a pain sometimes when you are trying
to drive a program through a pipe and/or pty interface... so it
is desirable also to be able to disable readline also.

\start
Date: 02 Nov 2006 01:02:51 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: sock_get_string_buf
Cc: Camm Maguire

Waldek Hebisch writes:

| > Greetings, and thanks so much!
| > 
| > Waldek Hebisch writes:
| > 
| > > I again had problem with "sock_get_string_buf": trying to use hypertex
| > > functions which require Axiom (for example search or tutorial input)
| > > gives:
| > > 
| > > (1) ->
| > >    >> System error:
| > >    Unexpected end of #<string-input stream from "                ...">.
| > > 
| > > Recent patch to gcl fixed the problem on many machines. But on one
| > > machine (using 2.4.31 kerenel) I was still getting this error.
| > > 
| > > So I tried the patch below and it solved the problem.  AFAICS the
| > > problem is that GCL string parameter wants to preserve string
| > > _value_, but what Axiom want is pass by reference.  My undersanding
| > > is that GCL has full right to copy the string, so the only relaiable
| > > solution must use 'object' type and extract string address from it.
| > > 
| > > Remark1: It seems that "official" GCL foreign function interface is
| > > is very incomplete for real world needs. I would suggest either
| > > promoting 'object' structure as documented, official low level
| > > interface, or adding few more arguments types (mostly arrays by reference).
| > > 
| > > Remark 2: This may be related to Debian bug 328480 (but what Camm
| > > wrote seem indicate different problem).
| > > 
| > 
| > This indeed fixes the above -- thanks!  Some axiom code must be
| > declining do write to a copied buffer or some such.
| > 
| > May I suggest adding
| > 
| >           "   if (x->st.st_fillp<j) FEerror(\"string too small\",0);"
| >
| 
| Yes, good idea.


Great!

I would like to see the final patch, e.g. the things that would be
committed, including the explanation of what the code and what is
going in the pamphletss.

\start
Date: 02 Nov 2006 01:04:21 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: hypertex and uses info

Waldek Hebisch writes:

[...]

| Concerning erase: I would prefer to limit use of 'directoryp': 
| something which has name endig in 'p' should return a boolean.
| What 'directoryp' returns is unexepected, so wide use of 'directoryp'
| would make interpreter code hareder to read.

Then directoryp should be probably fixed.

\start
Date: 02 Nov 2006 01:08:11 +0100
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: hypertex and uses info

Vanuxem Gr=E9gory Gregory Vanuxem writes:

[...]

| Anyway these things need to be fixed, no matter for me how this will be
| done.

Yes.  I would like to see those fixed, instead of being worke-around
by bits-n-pieces.

I'm no adept of don't touch it because "it works."  That is how the
source code gets bit-rotten

\start
Date: Thu, 2 Nov 2006 01:17:00 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> Bill Page writes:
> 
> 
> [...]
> 
> | The MAC server on which this was compiled did not have an X-windows
> | environment so it was not possible to compile and test Axiom Graphics
> | and the Hyperdoc browser. Also native MAC OSX10 apparently does not
> | have support for the pts virtual terminal interface so it is not
> | possible yet to compile clef (the replacement for readline).
> 
> I never quite understood why readline needs to be replaced.  Do you know?
> 

The point is that Axiom can take input from multiple sources.  For
example you can fire a few copies of 'spadclient' and you can
interact with each copy separately.  In particular, hypertex can
send spad expresions for Axiom to evaluate.  Currently, input is
sent via sockets and line buferred, so in this mode readline
included in Axiom is not used.

Strictly speaking, clef could be dropped: one could link
readline into spadclient.  However, this will remove one
use of pty.  The second pty is used by 'sman' to intercept
normal Axiom input and output.  AFAICS this pty may be
eliminated with moderate effort.

BTW: I do not belive that MACOSX does not support pty's.
It may do it in slightly different way, but quite a lot
of unix programs (beggining with Xterm) would brake
without pty's.

\start
Date: 02 Nov 2006 01:18:29 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

| On Wednesday, November 01, 2006 6:49 PM Gabriel Dos Reis wrote:
| 
| > | ... Also native MAC OSX10 apparently does not
| > | have support for the pts virtual terminal interface so it is
| > | not possible yet to compile clef (the replacement for readline).
| > 
| > I never quite understood why readline needs to be replaced.  
| > Do you know?
| > 
| 
| I think the foremost reason is that clef (aka. "edible") was part
| of Axiom long before readline existed.

OK; but we should not continue to have clef just for that reason.

| Second, clef does have some Axiom command completions that are not
| built-in to readline but I think readline is also configurable,
| and could provide such functionality, right?

Yes.

| Third, to the best of my knowledge readline is the only part of
| GCL that is licenses as GPL. If readline is disabled, then GCL might
| be considered compatible with Axiom's BSD-style non-copyleft license.
| (I am not sure if this is important to anyone interesting in Axiom
| any more.)

I don't know; that is probably true; I have to read GCL's configuration
options.  But, building Axiom as we currently do, I have

    [18:20]% strings =AXIOMsys | grep rl_                          
    rl_line_buffer
    rl_instream
    rl_attempted_completion_function
    rl_readline_name
    rl_completion_matches
    rl_completion
    rl_completion_words_new
    rl_ungetc_em_char
    rl_putc_em_line
    rl_line_buffer
    rl_getc_em
    rl_instream
    rl_ungetc_em
    rl_attempted_completion_function
    rl_readline_name
    rl_putc_em
    rl_completion_matches
    rl_getc_em(FILE *);
    rl_completion_matches

| Personally, I would prefer to get rid of clef and adapt readline
| because it would simply the Axiom process tree structure. On the
| other hand, readline can be a pain sometimes when you are trying
| to drive a program through a pipe and/or pty interface... so it
| is desirable also to be able to disable readline also.

We have to investigate that case.

\start
Date: Wed, 1 Nov 2006 19:24:19 -0500
From: Bill Page
To: Waldek Hebisch
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On Wednesday, November 01, 2006 7:17 PM Waldek Hebisch wrote:
> ...
> BTW: I do not belive that MACOSX does not support pty's.
> It may do it in slightly different way, but quite a lot
> of unix programs (beggining with Xterm) would brake
> without pty's.
>

I would be glad to hear more information about this.
I found several references on the web stating clearly that
the pty interface was not available on the MAC. With respect
to Xterm on MAC is did also see some references to special
purpose code in Xterm to provide some kind of emulation of
pty for the MAC. Maybe it would be possible use/adapt that
code... but that is beyond my level of experience and
available time.

It would be greate if someone could share their knowledge
and experience with this issue.

\start
Date: Wed, 1 Nov 2006 19:18:22 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> | The MAC server on which this was compiled did not have an X-windows
> | environment so it was not possible to compile and test Axiom Graphics
> | and the Hyperdoc browser. Also native MAC OSX10 apparently does not
> | have support for the pts virtual terminal interface so it is not
> | possible yet to compile clef (the replacement for readline).
> 
> I never quite understood why readline needs to be replaced.  Do you know?

clef knows more than readline. given an input file it can do smart
command line completion of things like domain names.

\start
Date: Wed, 1 Nov 2006 19:29:27 -0500
From: Bill Page
To: Raymond Manzoni
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On Wednesday, November 01, 2006 6:59 PM Raymond Manzoni wrote:
> ...
> 	Thank you for the binary! (I am on OS X 10.4.8)
> 	Unfortunately I got :
>
> $ AXIOMsys
> dyld: Library not loaded: /home/users/b/bi/billpage/osx/lib/libintl.
> 8.dylib
>    Referenced from: /Users/raym/Desktop/powerpc-apple-darwin6.8/bin/
> AXIOMsys
>    Reason: image not found
> Trace/BPT trap
>
> 	So some remaining path problems I fear...
>

Hmmm... Yes I do have a path set to point at a library that is
compiled as part of gettext:

  $ echo $LIBRARY_PATH
  /home/users/b/bi/billpage/osx/lib:/usr/lib:

I set this originally because I had some problems compiling
GCL with built-in gettext support. But perhaps this is not
necessary. I will try a build of GCL and Axiom without this
set.

If you do have libintl somewhere on you system, perhaps you
can try setting

export LIBRARY_PATH=/usr/lib/where-ever-it-is

I am surprised to see the AXIOMsys binary include a full
path name to this external library! Must be something pretty
weird about these .dylib files. ;)

> 	Ready to give it a new try or, better,  to compile the
> gcl/axiom  source code if it's available somewhere.
> 	(tomorrow since it's late here...).
>

Ok, tommorrow.

Thanks for checking in to this!

\start
Date: Thu, 2 Nov 2006 01:44:58 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> On Wednesday, November 01, 2006 7:17 PM Waldek Hebisch wrote:
> > ... 
> > BTW: I do not belive that MACOSX does not support pty's.
> > It may do it in slightly different way, but quite a lot
> > of unix programs (beggining with Xterm) would brake
> > without pty's.
> > 
> 
> I would be glad to hear more information about this.
> I found several references on the web stating clearly that
> the pty interface was not available on the MAC. With respect
> to Xterm on MAC is did also see some references to special
> purpose code in Xterm to provide some kind of emulation of
> pty for the MAC. Maybe it would be possible use/adapt that
> code... but that is beyond my level of experience and
> available time.
> 
> It would be greate if someone could share their knowledge
> and experience with this issue.
>
 
I am affraid I can not really offer Mac experience. However
the first Goole hit for: MACOSX pty is:

Mac OS X pty Permission Security Issue

Now, something which does not exits should have no security
problems, so I would belive that Mac OS X has pty.  OTOH
this security problem is solved by Unix 98 pty's (in other
words Linux /dev/ptmx and /dev/pts), so we can infer that
Mac OS X has only legacy pty (so you should use BSD
branch). 

BTW: I you are logged into a Mac OS X machine you can try
to look is '/dev' directory contains things like '/dev/ptyq0'
and '/dev/ttyq0' (this is a traditional name for legacy
pty's).
 
\start
Date: Wed, 1 Nov 2006 16:56:10 -0800 (PST)
From: Cliff Yapp
To: Bill Page, Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

--- Bill Page wrote:

> Personally, I would prefer to get rid of clef and adapt readline
> because it would simply the Axiom process tree structure. On the
> other hand, readline can be a pain sometimes when you are trying
> to drive a program through a pipe and/or pty interface... so it
> is desirable also to be able to disable readline also.

Perhaps linedit would be of interest?

http://common-lisp.net/project/linedit/

I doubt it's a drop-in replacement but in theory it would be a good fit
with a lot of lisps instead of just GCL, which might be useful for
things like porting down the road.  And its license should pose no
problem.

\start
Date: Wed, 01 Nov 2006 21:18:22 -0400
From: Humberto Zuazaga
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1C344BD2C7EE7FD7EB45C9A7

Page, Bill wrote:
> On Wednesday, November 01, 2006 1:23 PM Humberto Ortiz Zuazaga wrote:
>> Martin Rubey wrote:
>>
>>> WOW, that's cool! Axiom on the Mac!
>>>
>> I have PowerPC and Intel Macs running OS X 10.4.8 with fink, and
>> I'd like to try building axiom on them as well.
>
> Great!
>
>> Are these changes in the build-improvements branch?
>>
>
> No, not everything is in build-improvements yet - give us a few
> more hours. :-)
>
> In the mean time I would be very interested if you could start
> by just trying to buiuld the gcl lisp compiler. This is a pre-
> requiste for the Axiom build. You can get the version we will be
> using in build-improvements directly from the gcl CVS archive via
> the command line:
>
> $ cvs -d :pserver:anonymous@cvs.sv.gnu.org:/sources/gcl -z9 export \
>   -Dtoday -d gcl-2.6.8pre -r Version_2_6_8pre gcl
>
> and then do
>
> $ cd gcl-2.6.8pre
> $ ./configure --prefix=/usr/local
> $ make
>
> Ask if you need mor details. Let us know how it works.

On PowerPC, make fails:

gcc  -o raw_pre_gcl  \
-L.    -lpre_gcl `echo -lSM -lICE  -L/usr/X11R6/lib -lXmu -lXt -lXext
-lXaw -lX11    -lm  -lreadline -lncurses | sed -e 's/-lncurses/ /'`
-lintl -lc -lgclp
/usr/bin/ld: can't locate file for: -lintl
collect2: ld returned 1 exit status

Fink installed a version of libintl from gettext-dev 0.10.40, so I've
added a "-L/sw/lib" and am retrying the build now.

On Intel, configure of gmp fails, as it can't figure out the machine
type. I have gmp 4.2.1 installed with fink, but I don't think I can
build gcl with that version of gmp.

\start
Date: Wed, 1 Nov 2006 20:21:39 -0500
From: Bill Page
To: Waldek Hebisch
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On Wednesday, November 01, 2006 7:45 PM Waldek Hebisch wrote:
> 
> I am affraid I can not really offer Mac experience. However
> the first Goole hit for: MACOSX pty is:
>
> Mac OS X pty Permission Security Issue
>
> Now, something which does not exits should have no security
> problems, so I would belive that Mac OS X has pty.

Yes you are right. The reference I read earlier was that OSX 10.3
does not have support for posix grantpt... Maybe things have
change in OSX a lot since 10.3.


> OTOH this security problem is solved by Unix 98 pty's (in
> other words Linux /dev/ptmx and /dev/pts), so we can infer
> that Mac OS X has only legacy pty (so you should use BSD
> branch).
>

What do you mean by "BSD branch"?

> BTW: I you are logged into a Mac OS X machine you can try
> to look is '/dev' directory contains things like '/dev/ptyq0'
> and '/dev/ttyq0' (this is a traditional name for legacy
> pty's).
> 

Yes, I see for example:

ppc-osx3:~/osx $ ls /dev/ptyq*
/dev/ptyq0 /dev/ptyq3 /dev/ptyq6 /dev/ptyq9 /dev/ptyqc /dev/ptyqf
/dev/ptyq1 /dev/ptyq4 /dev/ptyq7 /dev/ptyqa /dev/ptyqd
/dev/ptyq2 /dev/ptyq5 /dev/ptyq8 /dev/ptyqb /dev/ptyqe
ppc-osx3:~/osx $

But when I try to build clef I get:

ppc-osx3:~/osx/axiom.build-improvements/src/clef $ make
gcc ./edible.o
-L/home/users/b/bi/billpage/osx/axiom.build-improvements/src/clef/../../
./src/lib -L/usr/lib -lspad  -lc -o
/home/users/b/bi/billpage/osx/axiom.build-improvements/target/powerpc-ap
ple-darwin6.8/bin/clef
ld: warning table of contents of library:
/home/users/b/bi/billpage/osx/axiom.build-improvements/src/clef/../.././
src/lib/libspad.a not sorted slower link editing will result (use the
ranlib(1) -s option)
ld: Undefined symbols:
_grantpt
_ptsname
_unlockpt

-----------

These are all pty external routines.

Maybe it is just that I don't understand that MAC library setup.
>From what else I can get from the web, I should expect to find
these functions in libc (-lc).

\start
Date: 01 Nov 2006 20:29:05 -0500
From: Camm Maguire
To: Waldek Hebisch
Subject: Re: sock_get_string_buf

Greetings!

Waldek Hebisch writes:

> > Greetings, and thanks so much!
> > 
> > Waldek Hebisch writes:
> > 
> > > I again had problem with "sock_get_string_buf": trying to use hypertex
> > > functions which require Axiom (for example search or tutorial input)
> > > gives:
> > > 
> > > (1) ->
> > >    >> System error:
> > >    Unexpected end of #<string-input stream from "                ...">.
> > > 
> > > Recent patch to gcl fixed the problem on many machines. But on one
> > > machine (using 2.4.31 kerenel) I was still getting this error.
> > > 
> > > So I tried the patch below and it solved the problem.  AFAICS the
> > > problem is that GCL string parameter wants to preserve string
> > > _value_, but what Axiom want is pass by reference.  My undersanding
> > > is that GCL has full right to copy the string, so the only relaiable
> > > solution must use 'object' type and extract string address from it.
> > > 
> > > Remark1: It seems that "official" GCL foreign function interface is
> > > is very incomplete for real world needs. I would suggest either
> > > promoting 'object' structure as documented, official low level
> > > interface, or adding few more arguments types (mostly arrays by reference).
> > > 
> > > Remark 2: This may be related to Debian bug 328480 (but what Camm
> > > wrote seem indicate different problem).
> > > 
> > 
> > This indeed fixes the above -- thanks!  Some axiom code must be
> > declining do write to a copied buffer or some such.
> > 
> > May I suggest adding
> > 
> >           "   if (x->st.st_fillp<j) FEerror(\"string too small\",0);"
> >
> 
> Yes, good idea.
>  
> > to the wrapper.  In general, we might want a non-null terminated
> > buffer type of a given length in the C interface too.  I'm guessing
> > this is what you mean by arrays by reference.  Documenting object is a
> > good idea too.
> > 
> 
> Typical uses I can see are:
> 
> 1) calling operating system.  This typically uses scalars and strings,
>    but may require structures.
> 2) calling numerial librarires.  Such librarires typically operate
>    on floating point arrays, but may also need integer arrays.
> 
> While support for C structures would be nice, one can use arrays
> of apropriate size and use Lisp byte operations to emulate C
> structures.  OTOH direct support for arrays seems essential.

There was another axiom user of late who implemented a GCL blas/lapack
interface within axiom.  It is fairly straightforward, but one needs
to make sure the arrays are static.  One can ensure this by checking
that the address is < heap_end.  Even though these external routines
do not call lisp, nor do they store references across calls, static is
still needed as they call malloc, which GCL redirects to protect
itself, and which can therefore trigger a gc.  I believe the same
logic should apply to the axiom socket code.  If 1) no pointers are
stored across calls 2) no lisp callbacks are made 3) no heap
allocation is made (alloca is OK), then relocatable pointers are fine.
Of course if one can use relocatable, it is better, as it is faster.

(On Debian, BTW, one can compile and load a simple defentry
blas/lapack api, call compiler::link adding -lblas -llapack -lg2c to
the command line, and then run the new image against whatever
optimized atlas library that might be available without
recompilation.)

We went through this with GMP bignums.  We had to implement a special
GC escape mechanism within GMP calls to protect the much faster
relocatable bignum algorithm.

Take care,

> 
> > Last comment -- GCL stores strings by default in relocatable memory --
> > i.e. they are copied at each gc.  This is much faster.  An immovable
> > type in 'contiguous" memory is also an option, via
> > 
> > (make-array 10 :element-type 'character :static t)
> > 
> > If axiom needs these pointers not to move across gc, may I please
> > suggest using the latter.  I've already checked, the pointers in use
> > are relocatable.
> > 
> 
> AFAICS C code does not store pointers to Lisp data (and there are no
> callbacks from C to Lisp). If (as I hope) GCL will not trigger garbage
> collection form a signal handler, keeping strings in relocatable memory
> should be safe.

\start
Date: 01 Nov 2006 20:31:55 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: re: sock_get_string_buf

Greetings!  Here is the patch in 2005901-9:

--- ./src/interp/sockio.lisp.pamphlet.orig	2006-11-01 16:18:42.000000000 -0500
+++ ./src/interp/sockio.lisp.pamphlet	2006-11-01 16:20:19.000000000 -0500
@@ -73,13 +73,18 @@
 (progn
   (clines "extern double plus_infinity(), minus_infinity(), NANQ();")
   (clines "extern double sock_get_float();")
+  (clines "int sock_get_string_buf_wrapper(int i, object x, int j)"
+          "{ if (type_of(x)!=t_string) FEwrong_type_argument(sLstring,x);"
+          "   if (x->st.st_fillp<j) FEerror(\"string too small in sock_get_string_buf_wrapper\",0);"
+          "   return sock_get_string_buf(i, x->st.st_self, j);}")
   (defentry open_server (string) (int "open_server"))
   (defentry sock_get_int (int) (int "sock_get_int"))
   (defentry sock_send_int (int int) (int "sock_send_int"))
-  (defentry sock_get_string_buf (int string int) (int "sock_get_string_buf"))
+;  (defentry sock_get_string_buf (int string int) (int "sock_get_string_buf"))
+  (defentry sock_get_string_buf (int object int)  (int "sock_get_string_buf_wrapper"))
   (defentry sock_send_string_len (int string int) (int "sock_send_string_len"))
   (defentry sock_get_float (int) (double "sock_get_float"))
-  (defentry sock_send_float (int float) (int "sock_send_float"))
+  (defentry sock_send_float (int double) (int "sock_send_float"))
   (defentry sock_send_wakeup (int int) (int "sock_send_wakeup"))
   (defentry server_switch () (int "server_switch"))
   (defentry flush_stdout () (int "flush_stdout"))


There are a few others to be found in debian/patch.all and
debian/patch.merge against this source.  I still use this (20050901)
as the base as it is the last posted tarball.

Take care,

Gabriel Dos Reis writes:

> Waldek Hebisch writes:
> 
> | > Greetings, and thanks so much!
> | > 
> | > Waldek Hebisch writes:
> | > 
> | > > I again had problem with "sock_get_string_buf": trying to use hypertex
> | > > functions which require Axiom (for example search or tutorial input)
> | > > gives:
> | > > 
> | > > (1) ->
> | > >    >> System error:
> | > >    Unexpected end of #<string-input stream from "                ...">.
> | > > 
> | > > Recent patch to gcl fixed the problem on many machines. But on one
> | > > machine (using 2.4.31 kerenel) I was still getting this error.
> | > > 
> | > > So I tried the patch below and it solved the problem.  AFAICS the
> | > > problem is that GCL string parameter wants to preserve string
> | > > _value_, but what Axiom want is pass by reference.  My undersanding
> | > > is that GCL has full right to copy the string, so the only relaiable
> | > > solution must use 'object' type and extract string address from it.
> | > > 
> | > > Remark1: It seems that "official" GCL foreign function interface is
> | > > is very incomplete for real world needs. I would suggest either
> | > > promoting 'object' structure as documented, official low level
> | > > interface, or adding few more arguments types (mostly arrays by reference).
> | > > 
> | > > Remark 2: This may be related to Debian bug 328480 (but what Camm
> | > > wrote seem indicate different problem).
> | > > 
> | > 
> | > This indeed fixes the above -- thanks!  Some axiom code must be
> | > declining do write to a copied buffer or some such.
> | > 
> | > May I suggest adding
> | > 
> | >           "   if (x->st.st_fillp<j) FEerror(\"string too small\",0);"
> | >
> | 
> | Yes, good idea.
> 
> 
> Great!
> 
> I would like to see the final patch, e.g. the things that would be
> committed, including the explanation of what the code and what is
> going in the pamphletss.

\start
Date: Wed, 1 Nov 2006 21:01:51 -0500
From: Bill Page
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

On Wednesday, November 01, 2006 8:18 PM Humberto Ortiz-Zuazaga wrote:
> ...
> On PowerPC, make fails:
>
> gcc  -o raw_pre_gcl  \
> -L.    -lpre_gcl `echo -lSM -lICE  -L/usr/X11R6/lib -lXmu -lXt -lXext
> -lXaw -lX11    -lm  -lreadline -lncurses | sed -e 's/-lncurses/ /'`
> -lintl -lc -lgclp
> /usr/bin/ld: can't locate file for: -lintl
> collect2: ld returned 1 exit status
>
> Fink installed a version of libintl from gettext-dev 0.10.40, so I've
> added a "-L/sw/lib" and am retrying the build now.
>

Here is a recipe that seems to work for me and avoids reference
to fink or other non-gcl related libraries:

 $ export
LIBRARY_PATH=/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/binutils/in=
t
l
 $ make clean
 $ ./configure --prefix=/usr/local --enable-locbfd =
--disable-statsysbfd
 $ make
 $ make install

I have a new batch of Axiom cooking with this version of gcl.

Note: It seems to be necessary to specify the --endable-locfd option
to ensure that the bfd internal to gcl is configured with internal
gettext.

> On Intel, configure of gmp fails, as it can't figure out the machine
> type. I have gmp 4.2.1 installed with fink, but I don't think I can
> build gcl with that version of gmp.
>

Too bad. :-( There are some options that affect gcl's use of gmp.
See ./configure --help  You might try:

  --disable-dynsysgmp

I have also Cc: Camm Maquire, the primary GCL developer who might
have some other suggestions for your Mac Intel platform.

\start
Date: Wed, 01 Nov 2006 22:21:21 -0400
From: Humberto Zuazaga
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig66135B90A32B972C0BE791BA

Page, Bill wrote:
> On Wednesday, November 01, 2006 8:18 PM Humberto Ortiz-Zuazaga wrote:

>> On Intel, configure of gmp fails, as it can't figure out the machine
>> type. I have gmp 4.2.1 installed with fink, but I don't think I can
>> build gcl with that version of gmp.
>>
>
> Too bad. :-( There are some options that affect gcl's use of gmp.
> See ./configure --help  You might try:
>
>   --disable-dynsysgmp

My bad, this was a configure error in gcl, not gmp. The gmp configure
and build seems to work. I made a copy of h/powerpc-macosx.defs and
h/powerpc-macosx.h and called

 ./configure --enable-machine=i386-macosx --prefix=/usr/local
--enable-locbfd --disable-statsysbfd

Now there's some problems with malloc.h not being found. configure.in
has a test for powerpc-macosx that should be duplicated for the new
i386-macosx target. I'll work on it some more tomorrow.

\start
Date: Wed, 1 Nov 2006 21:18:32 -0500
From: Tim Daly
To: Camm Maguire
Subject: re: sock_get_string_buf

cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl

yields 

gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/tmp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
fat_string.c:231: parse error before `bfd_combined_table_update'
fat_string.c:231: warning: return type defaults to `int'
fat_string.c: In function `fSset_up_combined':
fat_string.c:303: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
fat_string.c:310: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
make[1]: *** [fat_string.o] Error 1
make[1]: Leaving directory `/tmp/gcl-2.6.8pre/o'
make: *** [unixport/saved_pre_gcl] Error 2

on RedHat 7.2

\start
Date: Wed, 1 Nov 2006 21:36:14 -0500
From: Tim Daly
To: Camm Maguire
Subject: re: sock_get_string_buf

cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl

successfully builds on RedHat 9

================================================================

yields 

gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/tmp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
fat_string.c:231: parse error before `bfd_combined_table_update'
fat_string.c:231: warning: return type defaults to `int'
fat_string.c: In function `fSset_up_combined':
fat_string.c:303: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
fat_string.c:310: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
make[1]: *** [fat_string.o] Error 1
make[1]: Leaving directory `/tmp/gcl-2.6.8pre/o'
make: *** [unixport/saved_pre_gcl] Error 2

on RedHat 7.2

\start
Date: Wed, 1 Nov 2006 22:48:38 -0500
From: Tim Daly
To: Camm Maguire
Subject: re: sock_get_string_buf

cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl

successfully builds on FreeBSD

================================================================

fails on MAC OSX PPC

config.status: creating po/Makefile.in
config.status: executing depfiles commands
config.status: executing default commands
file=./`echo fr | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
/bin/sh: line 1: msgfmt: command not found
make[3]: *** [fr.gmo] Error 127
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [binutils/bfd/libbfd.a] Error 2
sh-2.05b# 

================================================================

fails on debian 

gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/root/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
fat_string.c:17:17: bfd.h: No such file or directory
fat_string.c:18:21: bfdlink.h: No such file or directory
fat_string.c:231: error: syntax error before "bfd_combined_table_update"
fat_string.c:231: error: syntax error before "PTR"
fat_string.c:231: warning: `struct bfd_link_hash_entry' declared inside parameter list
fat_string.c:231: warning: its scope is only this definition or declaration, which is probably not what you want
fat_string.c:231: warning: return type defaults to `int'
fat_string.c: In function `bfd_combined_table_update':
fat_string.c:233: error: `ct' undeclared (first use in this function)
fat_string.c:233: error: (Each undeclared identifier is reported only once
fat_string.c:233: error: for each function it appears in.)
fat_string.c:236: error: `h' undeclared (first use in this function)
fat_string.c:236: error: `bfd_link_hash_defined' undeclared (first use in this function)
fat_string.c: In function `fSset_up_combined':
fat_string.c:299: error: invalid use of undefined type `struct bfd_link_info'
fat_string.c:302: warning: implicit declaration of function `bfd_link_hash_traverse'
fat_string.c:302: error: invalid use of undefined type `struct bfd_link_info'
fat_string.c:309: error: invalid use of undefined type `struct bfd_link_info'
fasdump.c: At top level:
../h/ptable.h:53: error: storage size of `link_info' isn't known
make[1]: *** [fat_string.o] Error 1
make[1]: Leaving directory `/root/gcl-2.6.8pre/o'
make: *** [unixport/saved_pre_gcl] Error 2
debian:~/gcl-2.6.8pre# 

================================================================

fails on ubuntu

gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/tmp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
fat_string.c:17:17: error: bfd.h: No such file or directory
fat_string.c:18:21: error: bfdlink.h: No such file or directory
fat_string.c:231: error: syntax error before ‘bfd_combined_table_update’
fat_string.c:231: error: syntax error before ‘PTR’
fat_string.c:231: warning: return type defaults to ‘int’
fat_string.c: In function ‘bfd_combined_table_update’:
fat_string.c:233: error: ‘ct’ undeclared (first use in this function)
fat_string.c:233: error: (Each undeclared identifier is reported only once
fat_string.c:233: error: for each function it appears in.)
fat_string.c:236: error: ‘h’ undeclared (first use in this function)
fat_string.c:236: error: ‘bfd_link_hash_defined’ undeclared (first use in this function)
fat_string.c: In function ‘fSset_up_combined’:
fat_string.c:299: error: invalid use of undefined type ‘struct bfd_link_info’
fat_string.c:302: warning: implicit declaration of function ‘bfd_link_hash_traverse’
fat_string.c:302: error: invalid use of undefined type ‘struct bfd_link_info’
fat_string.c:309: error: invalid use of undefined type ‘struct bfd_link_info’
make[1]: *** [fat_string.o] Error 1
make[1]: Leaving directory `/tmp/gcl-2.6.8pre/o'
make: *** [unixport/saved_pre_gcl] Error 2


================================================================

successfully builds on Fedora 4

================================================================

successfully builds on Fedora 5

================================================================

fails on Fedora 6


gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/root/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
fat_string.c:17:17: error: bfd.h: No such file or directory
fat_string.c:18:21: error: bfdlink.h: No such file or directory
fat_string.c:231: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘bfd_combined_table_update’
fat_string.c: In function ‘fSset_up_combined’:
fat_string.c:299: error: invalid use of undefined type ‘struct bfd_link_info’
fat_string.c:302: warning: implicit declaration of function ‘bfd_link_hash_traverse’
fat_string.c:302: error: invalid use of undefined type ‘struct bfd_link_info’
fat_string.c:303: error: ‘bfd_combined_table_update’ undeclared (first use in this function)
fat_string.c:303: error: (Each undeclared identifier is reported only once
fat_string.c:303: error: for each function it appears in.)
fat_string.c:309: error: invalid use of undefined type ‘struct bfd_link_info’
make[1]: *** [fat_string.o] Error 1
make[1]: Leaving directory `/root/gcl-2.6.8pre/o'
make: *** [unixport/saved_pre_gcl] Error 2
[root@dhcppc0 gcl-2.6.8pre]# 



================================================================

successfully builds on RedHat 9

================================================================

yields 

gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/tmp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
fat_string.c:231: parse error before `bfd_combined_table_update'
fat_string.c:231: warning: return type defaults to `int'
fat_string.c: In function `fSset_up_combined':
fat_string.c:303: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
fat_string.c:310: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
make[1]: *** [fat_string.o] Error 1
make[1]: Leaving directory `/tmp/gcl-2.6.8pre/o'
make: *** [unixport/saved_pre_gcl] Error 2

on RedHat 7.2

\start
Date: Wed, 1 Nov 2006 23:09:45 -0500
From: Alfredo Portes
To: Tim Daly
Subject: re: sock_get_string_buf

> fails on ubuntu
>
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/tmp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c
> fat_string.c:17:17: error: bfd.h: No such file or directory
> fat_string.c:18:21: error: bfdlink.h: No such file or directory
> fat_string.c:231: error: syntax error before 'bfd_combined_table_update'
> fat_string.c:231: error: syntax error before 'PTR'
> fat_string.c:231: warning: return type defaults to 'int'
> fat_string.c: In function 'bfd_combined_table_update':
> fat_string.c:233: error: 'ct' undeclared (first use in this function)
> fat_string.c:233: error: (Each undeclared identifier is reported only once
> fat_string.c:233: error: for each function it appears in.)
> fat_string.c:236: error: 'h' undeclared (first use in this function)
> fat_string.c:236: error: 'bfd_link_hash_defined' undeclared (first use in this function)
> fat_string.c: In function 'fSset_up_combined':
> fat_string.c:299: error: invalid use of undefined type 'struct bfd_link_info'
> fat_string.c:302: warning: implicit declaration of function 'bfd_link_hash_traverse'
> fat_string.c:302: error: invalid use of undefined type 'struct bfd_link_info'
> fat_string.c:309: error: invalid use of undefined type 'struct bfd_link_info'
> make[1]: *** [fat_string.o] Error 1
> make[1]: Leaving directory `/tmp/gcl-2.6.8pre/o'
> make: *** [unixport/saved_pre_gcl] Error 2

apt-get install  binutils-dev

Maybe on Debian too.

\start
Date: Wed, 1 Nov 2006 23:33:50 -0500
From: Alfredo Portes
To: Tim Daly
Subject: re: sock_get_string_buf

Tim,

For the Fedora Core 6 it looks like it is also missing the binutils package.

It compiled fine for me in Ubuntu after installing it.

\start
Date: Thu, 2 Nov 2006 02:28:33 -0500
From: Tim Daly
To: list
Subject: re: sock_get_string_buf
Cc: Camm Maguire

following Alfredo's advice to apt-get install binutils-dev


cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl

successfully builds on FreeBSD

================================================================

fails on MAC OSX PPC

config.status: creating po/Makefile.in
config.status: executing depfiles commands
config.status: executing default commands
file=./`echo fr | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
/bin/sh: line 1: msgfmt: command not found
make[3]: *** [fr.gmo] Error 127
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [binutils/bfd/libbfd.a] Error 2
sh-2.05b# 

================================================================

successfully builds on debian 

================================================================

successfully builds on ubuntu

================================================================

successfully builds on Fedora 4

================================================================

successfully builds on Fedora 5

================================================================

fails on Fedora 6


gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/root/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
fat_string.c:17:17: error: bfd.h: No such file or directory
fat_string.c:18:21: error: bfdlink.h: No such file or directory
fat_string.c:231: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘bfd_combined_table_update’
fat_string.c: In function ‘fSset_up_combined’:
fat_string.c:299: error: invalid use of undefined type ‘struct bfd_link_info’
fat_string.c:302: warning: implicit declaration of function ‘bfd_link_hash_traverse’
fat_string.c:302: error: invalid use of undefined type ‘struct bfd_link_info’
fat_string.c:303: error: ‘bfd_combined_table_update’ undeclared (first use in this function)
fat_string.c:303: error: (Each undeclared identifier is reported only once
fat_string.c:303: error: for each function it appears in.)
fat_string.c:309: error: invalid use of undefined type ‘struct bfd_link_info’
make[1]: *** [fat_string.o] Error 1
make[1]: Leaving directory `/root/gcl-2.6.8pre/o'
make: *** [unixport/saved_pre_gcl] Error 2
[root@dhcppc0 gcl-2.6.8pre]# 



================================================================

successfully builds on RedHat 9

================================================================

fails on RedHat 7.2

gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/tmp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
fat_string.c:231: parse error before `bfd_combined_table_update'
fat_string.c:231: warning: return type defaults to `int'
fat_string.c: In function `fSset_up_combined':
fat_string.c:303: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
fat_string.c:310: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
make[1]: *** [fat_string.o] Error 1
make[1]: Leaving directory `/tmp/gcl-2.6.8pre/o'
make: *** [unixport/saved_pre_gcl] Error 2

\start
Date: Thu, 2 Nov 2006 14:31:42 +0600 (NOVT)
From: Andrey G. Grozin
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On Thu, 2 Nov 2006, Gabriel Dos Reis wrote:
> Bill Page writes:
> | The MAC server on which this was compiled did not have an X-windows
> | environment so it was not possible to compile and test Axiom Graphics
> | and the Hyperdoc browser. Also native MAC OSX10 apparently does not
> | have support for the pts virtual terminal interface so it is not
> | possible yet to compile clef (the replacement for readline).
> I never quite understood why readline needs to be replaced.  Do you know?
readline is licensed under GPL (not LGPL). When Axiom was a commercial 
product, it could not use readline. Now it cannot use readline, too, 
because it is BSD-licensed (arrgh).

\start
Date: Thu, 2 Nov 2006 03:40:50 -0500
From: Tim Daly
To: Andrey G. Grozin
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> > Bill Page writes:
> > | The MAC server on which this was compiled did not have an X-windows
> > | environment so it was not possible to compile and test Axiom Graphics
> > | and the Hyperdoc browser. Also native MAC OSX10 apparently does not
> > | have support for the pts virtual terminal interface so it is not
> > | possible yet to compile clef (the replacement for readline).
> > I never quite understood why readline needs to be replaced.  Do you know?
> readline is licensed under GPL (not LGPL). When Axiom was a commercial 
> product, it could not use readline. Now it cannot use readline, too, 
> because it is BSD-licensed (arrgh).

Ooops. Wrong list. This discussion should go to axiom-legal
which was created for the express purpose of keeping legal
issues out of the developer list. Please use that list instead.

I had an email discussion with Richard Stallman about the issue of
using GPL and BSD licensed programs together in a non-commmercial
setting. His statement is that the two licenses are compatible and he
sees no license problems that arise in either direction.

That said, I beg of you not to continue a legal discussion in
the developer list.

\start
Date: Thu, 2 Nov 2006 10:50:02 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> On Wednesday, November 01, 2006 7:45 PM Waldek Hebisch wrote:
> >  
> > I am affraid I can not really offer Mac experience. However
> > the first Goole hit for: MACOSX pty is:
> > 
> > Mac OS X pty Permission Security Issue
> > 
> > Now, something which does not exits should have no security
> > problems, so I would belive that Mac OS X has pty.
> 
> Yes you are right. The reference I read earlier was that OSX 10.3
> does not have support for posix grantpt... Maybe things have
> change in OSX a lot since 10.3.
> 
> 
> > OTOH this security problem is solved by Unix 98 pty's (in
> > other words Linux /dev/ptmx and /dev/pts), so we can infer
> > that Mac OS X has only legacy pty (so you should use BSD
> > branch). 
> >
> 
> What do you mean by "BSD branch"?
>

To change openpty.c.pamphlet like below (untested, I took oportunity
to remove some obfuscation).

--- openpty.c.pamphlet.bb	2006-11-02 11:25:27.000000000 +0100
+++ openpty.c.pamphlet	2006-11-02 11:33:03.243288784 +0100
@@ -10,17 +10,9 @@
 \tableofcontents
 \eject
 \section{MAC OSX and BSD platform changes}
-Since we have no other information we are adding the [[MACOSXplatform]] variable
-to the list everywhere we find [[LINUXplatform]]. This may not be correct but
-we have no way to know yet. We have also added the [[BSDplatform]] variable.
-MAC OSX is some variant of BSD. These should probably be merged but we
-cannot yet prove that.
-<<mac osx platform change 1>>=
-#if defined(SUN4OS5platform) ||defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(MACOSXplatform) || defined(BSDplatform)
-@
-<<mac osx platform change 2>>=
-#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(MACOSXplatform) || defined(BSDplatform)
-@
+We should really use autotools to check for Unix 98 pty support.
+Before this is done below we hardcode information about each platform.
+
 \section{License}
 <<license>>=
 /*
@@ -104,7 +96,7 @@
 #endif
 
 {
-#if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) ||defined(AIX370platform) || defined(BSDplatform)
+#if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) ||defined(AIX370platform) || defined(BSDplatform) || defined(MACOSXplatform)
   int looking = 1, i;
   int oflag = O_RDWR;                  /* flag for opening the pty */
   
@@ -147,7 +139,8 @@
   return(fdm);
 #endif
 
-<<mac osx platform change 1>>
+/* MAC OS X 10.3 does not support Unix 98 pty's */
+#if defined(SUN4OS5platform) ||defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(BSDplatform)
 extern int grantpt(int);
 extern int unlockpt(int);
 extern char* ptsname(int);
@@ -216,7 +209,7 @@
 	sprintf(serv, "/dev/ttyp%02x", channelNo);
 	channelNo++;
 #endif
-<<mac osx platform change 2>>
+#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(MACOSXplatform) || defined(BSDplatform)
 	static int channelNo = 0;
 	static char group[] = "pqrstuvwxyzPQRST";
 	static int groupNo = 0;
  
> > BTW: I you are logged into a Mac OS X machine you can try
> > to look is '/dev' directory contains things like '/dev/ptyq0'
> > and '/dev/ttyq0' (this is a traditional name for legacy
> > pty's).
> >  
> 
> Yes, I see for example:
> 
> ppc-osx3:~/osx $ ls /dev/ptyq*
> /dev/ptyq0 /dev/ptyq3 /dev/ptyq6 /dev/ptyq9 /dev/ptyqc /dev/ptyqf
> /dev/ptyq1 /dev/ptyq4 /dev/ptyq7 /dev/ptyqa /dev/ptyqd
> /dev/ptyq2 /dev/ptyq5 /dev/ptyq8 /dev/ptyqb /dev/ptyqe
> ppc-osx3:~/osx $
> 
> But when I try to build clef I get:
> 
> ppc-osx3:~/osx/axiom.build-improvements/src/clef $ make
> gcc ./edible.o
> -L/home/users/b/bi/billpage/osx/axiom.build-improvements/src/clef/../../
> ./src/lib -L/usr/lib -lspad  -lc -o
> /home/users/b/bi/billpage/osx/axiom.build-improvements/target/powerpc-ap
> ple-darwin6.8/bin/clef
> ld: warning table of contents of library:
> /home/users/b/bi/billpage/osx/axiom.build-improvements/src/clef/../.././
> src/lib/libspad.a not sorted slower link editing will result (use the
> ranlib(1) -s option)
> ld: Undefined symbols:
> _grantpt
> _ptsname
> _unlockpt
> 
> -----------
> 
> These are all pty external routines.
>

These are Unix 98 pty routines.  Somebody should check if Mac OS X
10.4 supports them, but all sources claim that earlier versions
do not have them.
 
\start
Date: Thu, 2 Nov 2006 13:04:19 +0100 (CET)
From: Waldek Hebisch
To: Ralf Hemmecke
Subject: Re: viewport in build-improvements

Ralf Hemmecke wrote:
> Sure many files *look* like text files, but you have heard Tim saying that
> 
> 1) a SCM should never change the line ending format

Tell that to Windows folks.

> 2) some files are random access files. If SVN replaces \n by \r\n at 
> checkout time, they are corrupt, since the byte count at the beginning 
> of the file does not work anymore.
> 

.ht, .pht, .bitmap, .pixmap, .xbm and .data in Axiom distribution are
text files.  Hyperdoc uses byte counts to access .ht and .pht, but
the file positions should be recomputed anyway.

Postscript files are more tricky: .ps files in Axiom distribution
are text files, but in general Postscript may contain binary data.
I think in the future we should decide if we want binary Postscript
in source repository (ATM I did not touch .ps files).

\start
Date: Thu, 2 Nov 2006 13:21:06 +0100
From: Juan Rivas
To: list
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Hi,

On Wed, Nov 01, 2006 at 07:05:52PM -0500, Page, Bill wrote:
> Second, clef does have some Axiom command completions that are not
> built-in to readline but I think readline is also configurable,
> and could provide such functionality, right?

I've been using Axiom together with readline plus completions using:

rlwrap -c -f /usr/local/axiom/mnt/fedora5/lib/command.list axiom -noclef

in order to get vi style command line editing capabilities:

http://blog.superadditive.com/2006/10/28/using-axiom-with-vi-keystrokes/

For the moment it has worked well.

\start
Date: Thu, 02 Nov 2006 14:04:58 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: Re: viewport in build-improvements

Hello,

On 11/02/2006 01:04 PM, Waldek Hebisch wrote:
> Ralf Hemmecke wrote:
>> Sure many files *look* like text files, but you have heard Tim saying that
>>
>> 1) a SCM should never change the line ending format

> Tell that to Windows folks.

Well, as you see, I did not (yet) remove the svn:eol-style property from 
the .pamphlet files in the SourceForge trunk for exactly that reason. 
But I tend to agree with Bill when he said that we should simply 
introduce the rule: Axiom uses Unix-style line endings, no matter on 
which OS you are working.

>> 2) some files are random access files. If SVN replaces \n by \r\n at 
>> checkout time, they are corrupt, since the byte count at the beginning 
>> of the file does not work anymore.

> .ht, .pht, .bitmap, .pixmap, .xbm and .data in Axiom distribution are
> text files.  Hyperdoc uses byte counts to access .ht and .pht, but
> the file positions should be recomputed anyway.

Since I don't live too deep in .ht and .pht things, what does that mean?
Do you want to recompute the byte-offsets at the time these files are 
copied to the /mnt directory? If you do that then it clearly classifies 
those files as being generated and no source anymore. Then they should 
not live under SVN at all.

> Postscript files are more tricky: .ps files in Axiom distribution
> are text files, but in general Postscript may contain binary data.

Ooops. I didn't know that also postscript can contain binary stuff. I 
thought that binaries (pictures) are somehow converted into some 7bit 
ASCII before they go into a .ps file. I must be wrong, but I cannot 
rememeber that I have ever looked at a .ps with binary data. Maybe I did 
not look closely enough.

> I think in the future we should decide if we want binary Postscript
> in source repository (ATM I did not touch .ps files).

I somehow believe that sooner or later at least the pictures that are 
generated from Axiom commands will go away.

The HyperDoc screenshots are probably more tricky to generate 
automatically at compile-time.

\start
Date: Thu, 2 Nov 2006 08:48:31 -0500
From: Bill Page
To: Tim Daly
Subject: re: sock_get_string_buf
Cc: Camm Maguire

On November 2, 2006 2:29 AM Tim Daly wrote:
> ... 
> fails on MAC OSX PPC
> 
> config.status: creating po/Makefile.in
> config.status: executing depfiles commands
> config.status: executing default commands
> file=./`echo fr | sed 's,.*/,,'`.gmo \
>   && rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
> /bin/sh: line 1: msgfmt: command not found
> make[3]: *** [fr.gmo] Error 127
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all] Error 2
> make: *** [binutils/bfd/libbfd.a] Error 2
> sh-2.05b# 
> 

msgfmt is part of gettext. You need the following options to
encourage gcl to use it's own built-in version of gettext:

./configure --enable-locbfd --disable-statsysbfd

These should be the default of MAC OSX

\start
Date: 02 Nov 2006 09:03:16 -0500
From: Camm Maguire
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Humberto Zuazaga writes:

> Page, Bill wrote:
> > On Wednesday, November 01, 2006 8:18 PM Humberto Ortiz-Zuazaga wrote:
> 
> >> On Intel, configure of gmp fails, as it can't figure out the machine
> >> type. I have gmp 4.2.1 installed with fink, but I don't think I can
> >> build gcl with that version of gmp.
> >>

GCL should work fine with this version.  The Debian GCL package links
against this version externally (i.e. gmp not built from gcl sources)

> > 
> > Too bad. :-( There are some options that affect gcl's use of gmp.
> > See ./configure --help  You might try:
> > 
> >   --disable-dynsysgmp
> 

Just a note, this should be the default if no external gmp is found.

> My bad, this was a configure error in gcl, not gmp. The gmp configure
> and build seems to work. I made a copy of h/powerpc-macosx.defs and
> h/powerpc-macosx.h and called
> 
>  ./configure --enable-machine=i386-macosx --prefix=/usr/local
> --enable-locbfd --disable-statsysbfd
> 
> Now there's some problems with malloc.h not being found. configure.in
> has a test for powerpc-macosx that should be duplicated for the new
> i386-macosx target. I'll work on it some more tomorrow.
> 

Thanks so much for your work on this!  Will be back in town on Sunday.

\start
Date: 02 Nov 2006 15:03:07 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Tim Daly writes:

| > | The MAC server on which this was compiled did not have an X-windows
| > | environment so it was not possible to compile and test Axiom Graphics
| > | and the Hyperdoc browser. Also native MAC OSX10 apparently does not
| > | have support for the pts virtual terminal interface so it is not
| > | possible yet to compile clef (the replacement for readline).
| > 
| > I never quite understood why readline needs to be replaced.  Do you know?
| 
| clef knows more than readline. given an input file it can do smart
| command line completion of things like domain names.

In what sense that "more knowledge" is unattainable with readline.
I dislike all those duplicated things in Axiom.  They are nothing but
source of confusion.

\start
Date: 02 Nov 2006 09:08:20 -0500
From: Camm Maguire
To: Tim Daly
Subject: re: sock_get_string_buf

Tim Daly writes:

> cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
> 
> successfully builds on RedHat 9
> 
> 
> 
> ================================================================
> 
> yields 
> 
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/tmp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
> fat_string.c:231: parse error before `bfd_combined_table_update'
> fat_string.c:231: warning: return type defaults to `int'
> fat_string.c: In function `fSset_up_combined':
> fat_string.c:303: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
> fat_string.c:310: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
> make[1]: *** [fat_string.o] Error 1
> make[1]: Leaving directory `/tmp/gcl-2.6.8pre/o'
> make: *** [unixport/saved_pre_gcl] Error 2
> 
> on RedHat 7.2
> 

Yes, GCL has upgraded to more recent binutils, which is compile-time
incompatible with the older version.  configure should figure this out
and backoff to the local copy automatically, but this really might be
more of a feature than a bug.  --disable-statsysbfd --enable-locbfd is
needed here, and in fact in most of your other examples.  Would it be
possible to retest with these configure commands?  Perhaps this should
be the default, though it is wasteful from a compile-time point of
view.  Still bfd is somewhat unique in that the upstream specifically
forbids the normal type of shared library dependency as its internal
api changes so frequently and without notice.

\start
Date: 02 Nov 2006 15:10:33 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: sock_get_string_buf
Cc: Camm Maguire

Tim Daly writes:

[...]

| fails on Fedora 6
| 
| 
| gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/root/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
| fat_string.c:17:17: error: bfd.h: No such file or directory
| fat_string.c:18:21: error: bfdlink.h: No such file or directory

Either you install BDF development package, or you call GCL's
configure with --enable-locbfd so that GCL builds its own version of
BFD.  Axiom.build-improvements test at configure time whether BFD
development is present, is not not it invokes GCL's configure with
--enable-locbfd. 

In the future, GCL should do that -- I'll commit patch to GCL's trunk,
not 2.6.8pre branch.

\start
Date: 02 Nov 2006 09:14:47 -0500
From: Camm Maguire
To: Tim Daly
Subject: re: sock_get_string_buf

Tim Daly writes:

> cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
>
> successfully builds on FreeBSD
>
> =========================
==========================
===============
>
> fails on MAC OSX PPC
>
> config.status: creating po/Makefile.in
> config.status: executing depfiles commands
> config.status: executing default commands
> file=./`echo fr | sed 's,.*/,,'`.gmo \
>   && rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
> /bin/sh: line 1: msgfmt: command not found
> make[3]: *** [fr.gmo] Error 127
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all] Error 2
> make: *** [binutils/bfd/libbfd.a] Error 2
> sh-2.05b#
>

OK, am looking into --disable-nls for this.

> =========================
==========================
===============

In all of the following, --disable-statsysbfd --enable-locbfd is
needed.  configure should be smarter, but I'm unsure as to whether
automating this determination should go into 2.6.8, as it could be
tricky.

>
> fails on debian
>
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointe=
r  -I/root/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c
> fat_string.c:17:17: bfd.h: No such file or directory
> fat_string.c:18:21: bfdlink.h: No such file or directory
> fat_string.c:231: error: syntax error before "bfd_combined_table_update"
> fat_string.c:231: error: syntax error before "PTR"
> fat_string.c:231: warning: `struct bfd_link_hash_entry' declared inside p=
arameter list
> fat_string.c:231: warning: its scope is only this definition or declarati=
on, which is probably not what you want
> fat_string.c:231: warning: return type defaults to `int'
> fat_string.c: In function `bfd_combined_table_update':
> fat_string.c:233: error: `ct' undeclared (first use in this function)
> fat_string.c:233: error: (Each undeclared identifier is reported only once
> fat_string.c:233: error: for each function it appears in.)
> fat_string.c:236: error: `h' undeclared (first use in this function)
> fat_string.c:236: error: `bfd_link_hash_defined' undeclared (first use in=
 this function)
> fat_string.c: In function `fSset_up_combined':
> fat_string.c:299: error: invalid use of undefined type `struct bfd_link_i=
nfo'
> fat_string.c:302: warning: implicit declaration of function `bfd_link_has=
h_traverse'
> fat_string.c:302: error: invalid use of undefined type `struct bfd_link_i=
nfo'
> fat_string.c:309: error: invalid use of undefined type `struct bfd_link_i=
nfo'
> fasdump.c: At top level:
> ../h/ptable.h:53: error: storage size of `link_info' isn't known
> make[1]: *** [fat_string.o] Error 1
> make[1]: Leaving directory `/root/gcl-2.6.8pre/o'
> make: *** [unixport/saved_pre_gcl] Error 2
> debian:~/gcl-2.6.8pre#



>
> =========================
==========================
===============
>
> fails on ubuntu
>
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointe=
r  -I/tmp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c
> fat_string.c:17:17: error: bfd.h: No such file or directory
> fat_string.c:18:21: error: bfdlink.h: No such file or directory
> fat_string.c:231: error: syntax error before =C3=A2=C2=80=C2=98bfd_combin=
ed_table_update=C3=A2=C2=80=C2=99
> fat_string.c:231: error: syntax error before =C3=A2=C2=80=C2=98PTR=C3=A2=
=C2=80=C2=99
> fat_string.c:231: warning: return type defaults to =C3=A2=C2=80=C2=98int=
=C3=A2=C2=80=C2=99
> fat_string.c: In function =C3=A2=C2=80=C2=98bfd_combined_table_update=C3=
=A2=C2=80=C2=99:
> fat_string.c:233: error: =C3=A2=C2=80=C2=98ct=C3=A2=C2=80=C2=99 undeclare=
d (first use in this function)
> fat_string.c:233: error: (Each undeclared identifier is reported only once
> fat_string.c:233: error: for each function it appears in.)
> fat_string.c:236: error: =C3=A2=C2=80=C2=98h=C3=A2=C2=80=C2=99 undeclared=
 (first use in this function)
> fat_string.c:236: error: =C3=A2=C2=80=C2=98bfd_link_hash_defined=C3=A2=C2=
=80=C2=99 undeclared (first use in this function)
> fat_string.c: In function =C3=A2=C2=80=C2=98fSset_up_combined=C3=A2=C2=80=
=C2=99:
> fat_string.c:299: error: invalid use of undefined type =C3=A2=C2=80=C2=98=
struct bfd_link_info=C3=A2=C2=80=C2=99
> fat_string.c:302: warning: implicit declaration of function =C3=A2=C2=80=
=C2=98bfd_link_hash_traverse=C3=A2=C2=80=C2=99
> fat_string.c:302: error: invalid use of undefined type =C3=A2=C2=80=C2=98=
struct bfd_link_info=C3=A2=C2=80=C2=99
> fat_string.c:309: error: invalid use of undefined type =C3=A2=C2=80=C2=98=
struct bfd_link_info=C3=A2=C2=80=C2=99
> make[1]: *** [fat_string.o] Error 1
> make[1]: Leaving directory `/tmp/gcl-2.6.8pre/o'
> make: *** [unixport/saved_pre_gcl] Error 2
>
>
> =========================
==========================
===============
>
> successfully builds on Fedora 4
>
> =========================
==========================
===============
>
> successfully builds on Fedora 5
>
> =========================
==========================
===============
>
> fails on Fedora 6
>
>
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointe=
r  -I/root/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c
> fat_string.c:17:17: error: bfd.h: No such file or directory
> fat_string.c:18:21: error: bfdlink.h: No such file or directory
> fat_string.c:231: error: expected =C3=A2=C2=80=C2=98==C3=A2=C2=80=C2=99=
, =C3=A2=C2=80=C2=98,=C3=A2=C2=80=C2=99, =C3=A2=C2=80=C2=98;=C3=A2=C2=80=C2=
=99, =C3=A2=C2=80=C2=98asm=C3=A2=C2=80=C2=99 or =C3=A2=C2=80=C2=98__attribu=
te__=C3=A2=C2=80=C2=99 before =C3=A2=C2=80=C2=98bfd_combined_table_update=
=C3=A2=C2=80=C2=99
> fat_string.c: In function =C3=A2=C2=80=C2=98fSset_up_combined=C3=A2=C2=80=
=C2=99:
> fat_string.c:299: error: invalid use of undefined type =C3=A2=C2=80=C2=98=
struct bfd_link_info=C3=A2=C2=80=C2=99
> fat_string.c:302: warning: implicit declaration of function =C3=A2=C2=80=
=C2=98bfd_link_hash_traverse=C3=A2=C2=80=C2=99
> fat_string.c:302: error: invalid use of undefined type =C3=A2=C2=80=C2=98=
struct bfd_link_info=C3=A2=C2=80=C2=99
> fat_string.c:303: error: =C3=A2=C2=80=C2=98bfd_combined_table_update=C3=
=A2=C2=80=C2=99 undeclared (first use in this function)
> fat_string.c:303: error: (Each undeclared identifier is reported only once
> fat_string.c:303: error: for each function it appears in.)
> fat_string.c:309: error: invalid use of undefined type =C3=A2=C2=80=C2=98=
struct bfd_link_info=C3=A2=C2=80=C2=99
> make[1]: *** [fat_string.o] Error 1
> make[1]: Leaving directory `/root/gcl-2.6.8pre/o'
> make: *** [unixport/saved_pre_gcl] Error 2
> [root@dhcppc0 gcl-2.6.8pre]#
>


Has the segfault at the raw_pre_gcl stage you reported earlier disappeared?

>
>
> =========================
==========================
===============
>
> successfully builds on RedHat 9
>
> =========================
==========================
===============
>
> yields
>
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointe=
r  -I/tmp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c
> fat_string.c:231: parse error before `bfd_combined_table_update'
> fat_string.c:231: warning: return type defaults to `int'
> fat_string.c: In function `fSset_up_combined':
> fat_string.c:303: warning: passing arg 2 of `bfd_link_hash_traverse' from=
 incompatible pointer type
> fat_string.c:310: warning: passing arg 2 of `bfd_link_hash_traverse' from=
 incompatible pointer type
> make[1]: *** [fat_string.o] Error 1
> make[1]: Leaving directory `/tmp/gcl-2.6.8pre/o'
> make: *** [unixport/saved_pre_gcl] Error 2
>
> on RedHat 7.2

\start
Date: 02 Nov 2006 15:12:31 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

[...]

| If you do have libintl somewhere on you system, perhaps you
| can try setting
| 
| export LIBRARY_PATH=/usr/lib/where-ever-it-is

That should be taken care of by configure

| I am surprised to see the AXIOMsys binary include a full
| path name to this external library! Must be something pretty
| weird about these .dylib files. ;)

Rumour has it that macos is not for development :-)

\start
Date: 02 Nov 2006 09:22:09 -0500
From: Camm Maguire
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

> On Wednesday, November 01, 2006 8:18 PM Humberto Ortiz-Zuazaga wrote:
> > ... 
> > On PowerPC, make fails:
> > 
> > gcc  -o raw_pre_gcl  \
> > -L.    -lpre_gcl `echo -lSM -lICE  -L/usr/X11R6/lib -lXmu -lXt -lXext
> > -lXaw -lX11    -lm  -lreadline -lncurses | sed -e 's/-lncurses/ /'`
> > -lintl -lc -lgclp
> > /usr/bin/ld: can't locate file for: -lintl
> > collect2: ld returned 1 exit status
> > 
> > Fink installed a version of libintl from gettext-dev 0.10.40, so I've
> > added a "-L/sw/lib" and am retrying the build now.
> >
> 
> Here is a recipe that seems to work for me and avoids reference
> to fink or other non-gcl related libraries:
> 
>  $ export
> LIBRARY_PATH=/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/binutils/int
> l
>  $ make clean
>  $ ./configure --prefix=/usr/local --enable-locbfd --disable-statsysbfd
>  $ make
>  $ make install
> 

locbfd should be the default on macosx, as we have Aurelien's specific
mods for .o file loading.  Extending this default to the intel should
resolve the -lintl 'out of the box'.  This said, I'd be quite
(pleasantly) surprised if Aurelien's code works as is on intel.  This
should be tried first -- if you can compile and load a simple file,
all is well.  Otherwise, the brain-dead default entry-level loading
option is --disable-statsysbfd --enable-dlopen.  This is limited in
that compiler::link instead of save-system must be used to save
images, and that no more than 1024 loads are supported on most
machines (as each requires an open file descriptor).

BTW, out of town till Sunday.

Take care,

> I have a new batch of Axiom cooking with this version of gcl.
> 
> Note: It seems to be necessary to specify the --endable-locfd option
> to ensure that the bfd internal to gcl is configured with internal
> gettext.
>  
> > On Intel, configure of gmp fails, as it can't figure out the machine
> > type. I have gmp 4.2.1 installed with fink, but I don't think I can
> > build gcl with that version of gmp.
> > 
> 
> Too bad. :-( There are some options that affect gcl's use of gmp.
> See ./configure --help  You might try:
> 
>   --disable-dynsysgmp
> 
> I have also Cc: Camm Maquire, the primary GCL developer who might
> have some other suggestions for your Mac Intel platform.

\start
Date: 02 Nov 2006 09:26:43 -0500
From: Camm Maguire
To: Bill Page
Subject: msgfmt requirement in GCL
Cc: Tom Hargreaves

... should now be removed, thanks to Gaby's suggestion --
--disable-nls added to the subconfigures.

Please let me know if problems persist here.

\start
Date: Thu, 2 Nov 2006 09:36:50 -0500
From: Bill Page
To: Camm Maguire
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On November 2, 2006 9:22 AM you wrote:
> ...
> Bill Page wrote:
> > 
> > Here is a recipe that seems to work for me and avoids reference
> > to fink or other non-gcl related libraries:
> > 
> >  $ export
LIBRARY_PATH=/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/binutils/intl
> >  $ make clean
> >  $ ./configure --prefix=/usr/local --enable-locbfd 
> --disable-statsysbfd
> >  $ make
> >  $ make install
> > 
> 
> locbfd should be the default on macosx, as we have Aurelien's specific
> mods for .o file loading.

Something subtle is still not right about this. If I omit --enable-locbfd
from the .configure then I get problems later gettext (unless gettext
is already installed elsewhere).

But worse is this:

 $ export
LIBRARY_PATH=/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/binutils/intl

Something is strange about the way that gcl links to libintl.
On MAC OS if I do not include LIBRARY_PATH and if libintl is
not in the system default path, then building gcl fails.

If I do include the 'export LIBRARY_PATH ..." then the build
succeeds but loading this library is "dynamic". This causes
trouble later if I try to use gcl to build Axiom without first
setting LIBRARY_PATH. Isn't there some way to force the MAC
to static link this library?

> Extending this default to the intel should
> resolve the -lintl 'out of the box'.  This said, I'd be quite
> (pleasantly) surprised if Aurelien's code works as is on intel.
> ...
> 
> BTW, out of town till Sunday.
>

\start
Date: 02 Nov 2006 10:00:11 -0500
From: Camm Maguire
To: Bill Page
Subject: re: sock_get_string_buf

Bill Page writes:

> On November 2, 2006 2:29 AM Tim Daly wrote:
> > ... 
> > fails on MAC OSX PPC
> > 
> > config.status: creating po/Makefile.in
> > config.status: executing depfiles commands
> > config.status: executing default commands
> > file=./`echo fr | sed 's,.*/,,'`.gmo \
> >   && rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
> > /bin/sh: line 1: msgfmt: command not found
> > make[3]: *** [fr.gmo] Error 127
> > make[2]: *** [all-recursive] Error 1
> > make[1]: *** [all] Error 2
> > make: *** [binutils/bfd/libbfd.a] Error 2
> > sh-2.05b# 
> > 
> 
> msgfmt is part of gettext. You need the following options to
> encourage gcl to use it's own built-in version of gettext:
> 
> ./configure --enable-locbfd --disable-statsysbfd
> 
> These should be the default of MAC OSX
> 

Yes, up until a few minutes ago, by default on macosx you should get
local bfd with gettext, providing the -lintl on the link command
line.  But msgfmt is still not in the path, though might be made so.
In any case, I just added --disable-nls which omits these calls to
msgfmt. 

\start
Date: 02 Nov 2006 15:55:58 +0100
From: Gabriel Dos Reis
To: Camm Maguire
Subject: re: sock_get_string_buf

Camm Maguire writes:

[...]

| In all of the following, --disable-statsysbfd --enable-locbfd is
| needed.  configure should be smarter, but I'm unsure as to whether
| automating this determination should go into 2.6.8, as it could be
| tricky. 

I have the following on axiom.build-improvements to detect that.

    If GCL is not present in the build environment (a very common
    situation on
    most platforms), we must build one from a copy included in the
    Axiom tarball.  However, GCL relies on the libirary BFD, the include
    headers of which may not exist (quite common).  In order to avoid
    failure while building GCL, we test for the existence of [[<bfd.h>]]
    and the corresponding library.  We configure GCL to
    use its own copy of BFD accordingly.

    <<gcl options>>=
    axiom_host_has_bfd_h=
    axiom_host_has_libbfd=
    AC_CHECK_HEADER([bfd.h], [axiom_host_has_bfd_h=yes])
    AC_HAVE_LIBRARY([bfd], [axiom_host_has_libbfd=yes])

    axiom_gcl_bfd_option=
    if test x"$axiom_host_has_bfd_h" = xyes \
        && test x"$axiom_host_has_libbfd" = xyes; then
        axiom_gcl_bfd_option="--enable-statsysbfd"
    else
        axiom_gcl_bfd_option="--disable-statsysbfd --enable-locbfd"
    fi

    GCLOPTS="--enable-vssize=65536*2 --disable-dynsysbfd \
                $axiom_gcl_bfd_option --enable-maxpage=256*1024"
    @

\start
Date: Thu, 2 Nov 2006 10:20:24 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: Re: viewport in build-improvements

> > Sure many files *look* like text files, but you have heard Tim saying that
> > 
> > 1) a SCM should never change the line ending format
> 
> Tell that to Windows folks.

Consider the domain and range of an SCM. It should map files to files
as an identity operation with a side-effect of maintaining history.
An SCM only needs to know that bytes are bytes. Maintaining history
as diff-format files is an optimization, not a requirement.

Changing \n-files to \r\n-files is the responsibility of some other tool.
If the translation occurs at all it should live in the client end since
that is the part that knows about the user environment.

> > 2) some files are random access files. If SVN replaces \n by \r\n at 
> > checkout time, they are corrupt, since the byte count at the beginning 
> > of the file does not work anymore.
> > 
> 
> .ht, .pht, .bitmap, .pixmap, .xbm and .data in Axiom distribution are
> text files.  Hyperdoc uses byte counts to access .ht and .pht, but
> the file positions should be recomputed anyway.
> 
> Postscript files are more tricky: .ps files in Axiom distribution
> are text files, but in general Postscript may contain binary data.
> I think in the future we should decide if we want binary Postscript
> in source repository (ATM I did not touch .ps files).

In general the repository should contain whatever files are needed
to make the project. Clearly documentation will require various
binary files such as jpg, flv, mov, mp3, etc. These will change 
over the life of the project and need to be historically tracked
just like everything else.

Although I chose arch and it "does the right thing" I have to say
that GIT seems to have the SCM philosophy most clearly implemented.

\start
Date: Thu, 02 Nov 2006 11:12:13 -0400
From: Humberto Zuazaga
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

Page, Bill wrote:
> On Wednesday, November 01, 2006 8:18 PM Humberto Ortiz-Zuazaga wrote:
>> ... 
>> On PowerPC, make fails:
>>
>> gcc  -o raw_pre_gcl  \
>> -L.    -lpre_gcl `echo -lSM -lICE  -L/usr/X11R6/lib -lXmu -lXt -lXext
>> -lXaw -lX11    -lm  -lreadline -lncurses | sed -e 's/-lncurses/ /'`
>> -lintl -lc -lgclp
>> /usr/bin/ld: can't locate file for: -lintl
>> collect2: ld returned 1 exit status
>>
>> Fink installed a version of libintl from gettext-dev 0.10.40, so I've
>> added a "-L/sw/lib" and am retrying the build now.
>>
> 
> Here is a recipe that seems to work for me and avoids reference
> to fink or other non-gcl related libraries:
> 
>  $ export
> LIBRARY_PATH=/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/binutils/int
> l
>  $ make clean
>  $ ./configure --prefix=/usr/local --enable-locbfd --disable-statsysbfd
>  $ make
>  $ make install
> 
> I have a new batch of Axiom cooking with this version of gcl.
> 
> Note: It seems to be necessary to specify the --endable-locfd option
> to ensure that the bfd internal to gcl is configured with internal
> gettext.
>  
>> On Intel, configure of gmp fails, as it can't figure out the machine
>> type. I have gmp 4.2.1 installed with fink, but I don't think I can
>> build gcl with that version of gmp.
>>
> 
> Too bad. :-( There are some options that affect gcl's use of gmp.
> See ./configure --help  You might try:
> 
>   --disable-dynsysgmp
> 
> I have also Cc: Camm Maquire, the primary GCL developer who might
> have some other suggestions for your Mac Intel platform.
> 
> Thanks.
> 
> Regards,
> Bill Page.

On Mac OS X 10.4.8 PowerPC:

code checked out today with:

$ cvs -d :pserver:anonymous@cvs.sv.gnu.org:/sources/gcl -z9  co  \
   -d gcl-2.6.8pre -r Version_2_6_8pre gcl

$ export LIBRARY_PATH=`pwd`/binutils/intl
$ make clean
$ ./configure --prefix=/usr/local  --enable-locbfd --disable-statsysbfd
$ make

fails with a bunch of warnings like:

/usr/bin/ld: warning multiple definitions of symbol _Tcl_InitStubs
/sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _Tcl_InitStubs

and then

/usr/bin/ld: Undefined symbols:
_my_free
_my_malloc
collect2: ld returned 1 exit status

\start
Date: Thu, 2 Nov 2006 10:37:00 -0500
From: Tim Daly
To: Bill Page
Subject: re: sock_get_string_buf
Cc: Camm Maguire

> > ... 
> > fails on MAC OSX PPC
> > 
> > config.status: creating po/Makefile.in
> > config.status: executing depfiles commands
> > config.status: executing default commands
> > file=./`echo fr | sed 's,.*/,,'`.gmo \
> >   && rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
> > /bin/sh: line 1: msgfmt: command not found
> > make[3]: *** [fr.gmo] Error 127
> > make[2]: *** [all-recursive] Error 1
> > make[1]: *** [all] Error 2
> > make: *** [binutils/bfd/libbfd.a] Error 2
> > sh-2.05b# 
> > 
> 
> msgfmt is part of gettext. You need the following options to
> encourage gcl to use it's own built-in version of gettext:
> 
> ./configure --enable-locbfd --disable-statsysbfd
> 
> These should be the default of MAC OSX

Actually that fails also with the same output.

The apt-get worked for debian-style systems like debian and ubuntu.

Yum does not know about binutils-dev which is a debian package
so Fedora 6 still won't build. I searched for the binutils-dev
equivalent but have not yet found it.

There is no apt-get or yum tool for the MAC that I can find.

\start
Date: Thu, 2 Nov 2006 11:08:58 -0500
From: Alfredo Portes
To: Tim Daly
Subject: re: sock_get_string_buf
Cc: Camm Maguire

> Yum does not know about binutils-dev which is a debian package
> so Fedora 6 still won't build. I searched for the binutils-dev
> equivalent but have not yet found it.

Here is the binutils-dev package from Fedora:

http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386/os/Fedora/RPMS/binutils-devel-2.17.50.0.3-6.i386.rpm

rpm -ivh binutils-devel-2.17.50.0.3-6

\start
Date: Thu, 2 Nov 2006 11:08:32 -0500
From: Bill Page
To: Tim Daly
Subject: Re: sock_get_string_buf
Cc: Camm Maguire

On November 2, 2006 10:37 AM Tim Daly wrote:
> 
> > > ... 
> > > fails on MAC OSX PPC
> > > 
> > > config.status: creating po/Makefile.in
> > > config.status: executing depfiles commands
> > > config.status: executing default commands
> > > file=./`echo fr | sed 's,.*/,,'`.gmo \
> > >   && rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
> > > /bin/sh: line 1: msgfmt: command not found
> > > make[3]: *** [fr.gmo] Error 127
> > > make[2]: *** [all-recursive] Error 1
> > > make[1]: *** [all] Error 2
> > > make: *** [binutils/bfd/libbfd.a] Error 2
> > > sh-2.05b# 
> > > 
> > 
> > msgfmt is part of gettext. You need the following options to
> > encourage gcl to use it's own built-in version of gettext:
> > 
> > ./configure --enable-locbfd --disable-statsysbfd
> > 
> > These should be the default of MAC OSX
> 
> Actually that fails also with the same output.
>

???

Are you double sure of this? Your result doesn't make sense
because gcl internally builds it's own version of gettext
as part of the bfd build and finds msgfmt there *internally*.
This works for me on the MAC OSX that I have been using.
 
> The apt-get worked for debian-style systems like debian and
> ubuntu.
> 
> Yum does not know about binutils-dev which is a debian package
> so Fedora 6 still won't build. I searched for the binutils-dev
> equivalent but have not yet found it.

You should not have to install binutils-dev *if* you ask gcl
to use it's own built-in version.

> 
> There is no apt-get or yum tool for the MAC that I can find.
> 

You don't need to install binutils so you don't need
apt-get or yum.

\start
Date: Thu, 2 Nov 2006 17:11:08 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: re: gcl-2.6.8pre
Cc: Camm Maguire

root wrote:
> Yum does not know about binutils-dev which is a debian package
> so Fedora 6 still won't build. I searched for the binutils-dev
> equivalent but have not yet found it.
> 
> There is no apt-get or yum tool for the MAC that I can find.
> 

Fedora name is 'binutils-devel' (for i386 the full name is
'Fedora/RPMS/binutils-devel-2.17.50.0.3-6.i386.rpm')

\start
Date: Thu, 2 Nov 2006 11:15:06 -0500
From: Bill Page
To: Tim Daly
Subject: Re: sock_get_string_buf
Cc: Camm Maguire

On November 2, 2006 11:09 AM I wrote:
> ...
> > > 
> > > ./configure --enable-locbfd --disable-statsysbfd
> > > 
> > > These should be the default of MAC OSX
> > 
> > Actually that fails also with the same output.
> >
> 
> ???
> 
> Are you double sure of this?

By that I mean, did you scrap the previous gcl directory 'rm -rf *'
and start completely fresh? I've seem a few case where gcl does
not cleanup very well. (Sorry, I didn't document at the time.)

> Your result doesn't make sense because gcl internally builds
> it's own version of gettext as part of the bfd build and finds
> msgfmt there *internally*. This works for me on the MAC OSX
> that I have been using.
> ... 

Note also that Camm committed new changes to gcl-2.6.8pre
just this morning that could affect this behaviour.

\start
Date: Thu, 2 Nov 2006 11:10:18 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> | > | The MAC server on which this was compiled did not have an X-windows
> | > | environment so it was not possible to compile and test Axiom Graphics
> | > | and the Hyperdoc browser. Also native MAC OSX10 apparently does not
> | > | have support for the pts virtual terminal interface so it is not
> | > | possible yet to compile clef (the replacement for readline).
> | > 
> | > I never quite understood why readline needs to be replaced.  Do you know?
> | 
> | clef knows more than readline. given an input file it can do smart
> | command line completion of things like domain names.
> 
> In what sense that "more knowledge" is unattainable with readline.
> I dislike all those duplicated things in Axiom.  They are nothing but
> source of confusion.

At the time clef, hyperdoc, graphics, etc were written we were using
X10 (not the house wireless, the pre-X11 windows) on 6MHz PCs. These
ideas were invented within the group to solve problems, not because
we wanted our own copies.

At the time the internet did not have google. Heck, it didn't even
have gopher, the browser didn't exist, and graphics amounted to the
original "screensaver" ideas of Dave Chess. Linux wasn't around until
later (and fit on 3 diskettes, collecting mold in my basement).

If readline can do completions perhaps we should feed it the
symbols in compress.daase.

\start
Date: 02 Nov 2006 17:41:29 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Tim Daly writes:

| > | > | The MAC server on which this was compiled did not have an X-windows
| > | > | environment so it was not possible to compile and test Axiom Graphics
| > | > | and the Hyperdoc browser. Also native MAC OSX10 apparently does not
| > | > | have support for the pts virtual terminal interface so it is not
| > | > | possible yet to compile clef (the replacement for readline).
| > | > 
| > | > I never quite understood why readline needs to be replaced.  Do you know?
| > | 
| > | clef knows more than readline. given an input file it can do smart
| > | command line completion of things like domain names.
| > 
| > In what sense that "more knowledge" is unattainable with readline.
| > I dislike all those duplicated things in Axiom.  They are nothing but
| > source of confusion.
| 
| At the time clef, hyperdoc, graphics, etc were written we were using
| X10 (not the house wireless, the pre-X11 windows) on 6MHz PCs. These
| ideas were invented within the group to solve problems, not because
| we wanted our own copies.

I suspected they were invented to solve problems.  Thankfully, we are in
2006 now.  readline has been around for more than a decade.
I'm trying to understand what would a barrier to stop the homegrown
clef (which from my experience is source of frustration) and use a
standard readline.

[...]

| If readline can do completions perhaps we should feed it the
| symbols in compress.daase.

We should put that on the TODO list.

\start
Date: 02 Nov 2006 17:43:44 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: sock_get_string_buf
Cc: Camm Maguire

Tim Daly writes:

| > > ... 
| > > fails on MAC OSX PPC
| > > 
| > > config.status: creating po/Makefile.in
| > > config.status: executing depfiles commands
| > > config.status: executing default commands
| > > file=./`echo fr | sed 's,.*/,,'`.gmo \
| > >   && rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
| > > /bin/sh: line 1: msgfmt: command not found
| > > make[3]: *** [fr.gmo] Error 127
| > > make[2]: *** [all-recursive] Error 1
| > > make[1]: *** [all] Error 2
| > > make: *** [binutils/bfd/libbfd.a] Error 2
| > > sh-2.05b# 
| > > 
| > 
| > msgfmt is part of gettext. You need the following options to
| > encourage gcl to use it's own built-in version of gettext:
| > 
| > ./configure --enable-locbfd --disable-statsysbfd
| > 
| > These should be the default of MAC OSX
| 
| Actually that fails also with the same output.

Please use --disable-nls.

Until, Axiom officially support internationalization.

\start
Date: 02 Nov 2006 11:49:13 -0500
From: Camm Maguire
To: Bill Page
Subject: re: sock_get_string_buf

Bill Page writes:

> On November 2, 2006 10:37 AM Tim Daly wrote:
> > 
> > > > ... 
> > > > fails on MAC OSX PPC
> > > > 
> > > > config.status: creating po/Makefile.in
> > > > config.status: executing depfiles commands
> > > > config.status: executing default commands
> > > > file=./`echo fr | sed 's,.*/,,'`.gmo \
> > > >   && rm -f $file && PATH=../src:$PATH msgfmt -o $file fr.po
> > > > /bin/sh: line 1: msgfmt: command not found
> > > > make[3]: *** [fr.gmo] Error 127
> > > > make[2]: *** [all-recursive] Error 1
> > > > make[1]: *** [all] Error 2
> > > > make: *** [binutils/bfd/libbfd.a] Error 2
> > > > sh-2.05b# 
> > > > 
> > > 
> > > msgfmt is part of gettext. You need the following options to
> > > encourage gcl to use it's own built-in version of gettext:
> > > 
> > > ./configure --enable-locbfd --disable-statsysbfd
> > > 
> > > These should be the default of MAC OSX
> > 
> > Actually that fails also with the same output.
> >
> 
> ???
> 
> Are you double sure of this? Your result doesn't make sense
> because gcl internally builds it's own version of gettext
> as part of the bfd build and finds msgfmt there *internally*.
> This works for me on the MAC OSX that I have been using.
>  

Without any path setting?  In any case, I jsut checked, and it just
skips the msgfmt calls now, the libintl et.al. stuff is the same.
Remove --disable-nls from configure.in and autoconf if you want to
revert. 

> > The apt-get worked for debian-style systems like debian and
> > ubuntu.
> > 
> > Yum does not know about binutils-dev which is a debian package
> > so Fedora 6 still won't build. I searched for the binutils-dev
> > equivalent but have not yet found it.
> 
> You should not have to install binutils-dev *if* you ask gcl
> to use it's own built-in version.
> 

Indeed this is the preferred route if one has any hint of bfd version
skew, quite common.

Take care,

> > 
> > There is no apt-get or yum tool for the MAC that I can find.
> > 
> 
> You don't need to install binutils so you don't need
> apt-get or yum.

\start
Date: 02 Nov 2006 17:45:22 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: sock_get_string_buf
Cc: Camm Maguire

Bill Page writes:

| On November 2, 2006 11:09 AM I wrote:
| > ...
| > > > 
| > > > ./configure --enable-locbfd --disable-statsysbfd
| > > > 
| > > > These should be the default of MAC OSX
| > > 
| > > Actually that fails also with the same output.
| > >
| > 
| > ???
| > 
| > Are you double sure of this?
| 
| By that I mean, did you scrap the previous gcl directory 'rm -rf *'
| and start completely fresh? I've seem a few case where gcl does
| not cleanup very well. (Sorry, I didn't document at the time.)

yes, there are several Makefile issues with GCL, but that is for another
time :-)

\start
Date: Thu, 2 Nov 2006 11:42:03 -0500
From: Tim Daly
To: Bill Page
Subject: re: sock_get_string_buf
Cc: Camm Maguire

> Note also that Camm committed new changes to gcl-2.6.8pre
> just this morning that could affect this behaviour.

ok. i'll do a fresh checkout and walk it across all of the systems again.

\start
Date: Thu, 2 Nov 2006 23:12:50 +0600 (NOVT)
From: Andrey G. Grozin
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On Thu, 2 Nov 2006, Gabriel Dos Reis wrote:
> Tim Daly writes:
> | At the time clef, hyperdoc, graphics, etc were written we were using
> | X10 (not the house wireless, the pre-X11 windows) on 6MHz PCs. These
> | ideas were invented within the group to solve problems, not because
> | we wanted our own copies.
> I suspected they were invented to solve problems.  Thankfully, we are in
> 2006 now.  readline has been around for more than a decade.
> I'm trying to understand what would a barrier to stop the homegrown
> clef (which from my experience is source of frustration) and use a
> standard readline.
We cannot do this, unless we change the license of Axiom to GPL.
Remember the story of clisp? RMS has forced the author of clisp to change 
his license to GPL, because it used (and still uses) readline, which is 
GPL (not LGPL) (in spite of the fact that this author claimed that 
readline is optional).

In fact, the current Axiom distribution falls under GPL anyway, because 
gcl is built with several GPL parts (including readline, but not only); 
this is (correctly!) stated in Camm's .deb package.

\start
Date: Thu, 2 Nov 2006 13:37:42 -0500
From: Bill Page
To: Waldek Hebisch
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Thank you! Your patch to openpty for MAC OSX worked perfectly.
clef now compiles correctly. :-)

I think this change should go in.

On November 2, 2006 4:50 AM Waldek Hebisch wrote:
> > ...
> > > OTOH this security problem is solved by Unix 98 pty's (in
> > > other words Linux /dev/ptmx and /dev/pts), so we can infer
> > > that Mac OS X has only legacy pty (so you should use BSD
> > > branch).
> > >
> Bill Page asked:
> >
> > What do you mean by "BSD branch"?
> >
>
> To change openpty.c.pamphlet like below (untested, I took oportunity
> to remove some obfuscation).
>

--- openpty.c.pamphlet.bb	2006-11-02 11:25:27.000000000 +0100
+++ openpty.c.pamphlet	2006-11-02 11:33:03.243288784 +0100
@@ -10,17 +10,9 @@
 \tableofcontents
 \eject
 \section{MAC OSX and BSD platform changes}
-Since we have no other information we are adding the [[MACOSXplatform]]
variable
-to the list everywhere we find [[LINUXplatform]]. This may not be =
correct
but
-we have no way to know yet. We have also added the [[BSDplatform]]
variable.
-MAC OSX is some variant of BSD. These should probably be merged but we
-cannot yet prove that.
-<<mac osx platform change 1>>=
-#if defined(SUN4OS5platform) ||defined(ALPHAplatform) ||
defined(HP10platform) || defined(LINUXplatform) || =
defined(MACOSXplatform)
|| defined(BSDplatform)
-@
-<<mac osx platform change 2>>=
-#if defined(SUNplatform) || defined(HP9platform) || =
defined(LINUXplatform)
|| defined(MACOSXplatform) || defined(BSDplatform)
-@
+We should really use autotools to check for Unix 98 pty support.
+Before this is done below we hardcode information about each platform.
+
 \section{License}
 <<license>>=
 /*
@@ -104,7 +96,7 @@
 #endif

 {
-#if defined(SUNplatform) || defined (HP9platform) || =
defined(RTplatform)
||defined(AIX370platform) || defined(BSDplatform)
+#if defined(SUNplatform) || defined (HP9platform) || =
defined(RTplatform)
||defined(AIX370platform) || defined(BSDplatform) || =
defined(MACOSXplatform)
   int looking = 1, i;
   int oflag = O_RDWR;                  /* flag for opening the pty */
  
@@ -147,7 +139,8 @@
   return(fdm);
 #endif

-<<mac osx platform change 1>>
+/* MAC OS X 10.3 does not support Unix 98 pty's */
+#if defined(SUN4OS5platform) ||defined(ALPHAplatform) ||
defined(HP10platform) || defined(LINUXplatform) || defined(BSDplatform)
 extern int grantpt(int);
 extern int unlockpt(int);
 extern char* ptsname(int);
@@ -216,7 +209,7 @@
 	sprintf(serv, "/dev/ttyp%02x", channelNo);
 	channelNo++;
 #endif
-<<mac osx platform change 2>>
+#if defined(SUNplatform) || defined(HP9platform) || =
defined(LINUXplatform)
|| defined(MACOSXplatform) || defined(BSDplatform)
 	static int channelNo = 0;
 	static char group[] = "pqrstuvwxyzPQRST";
 	static int groupNo = 0;
 
> ...

\start
Date: Thu, 2 Nov 2006 14:23:17 -0500
From: Bill Page
To: Raymond Manzoni
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Raymond,

Please download the new binary for AXIOMsys on MAC OSX PowerPC from:

http://wiki.axiom-developer.org/public/AXIOMsys-ppc-20061102.tgz

This version was created using the version of libintl that is
internal to gcl. I have tried it without any LIBRARY_PATH setting
and after removing the original build directories, and it seems
to work for me.

Everyone else with a PowerPC MAC is encouraged to try it too!

Please let me know how/if it works.

On November 1, 2006 6:59 PM Raymond Manzoni wrote:

> ...
> 	Hi Bill,
>
> 	Thank you for the binary! (I am on OS X 10.4.8)
> 	Unfortunately I got :
>
> $ AXIOMsys
> dyld: Library not loaded: /home/users/b/bi/billpage/osx/lib/libintl.
> 8.dylib
>    Referenced from: /Users/raym/Desktop/powerpc-apple-darwin6.8/bin/
> AXIOMsys
>    Reason: image not found
> Trace/BPT trap
>
> 	So some remaining path problems I fear...
>
> 	Ready to give it a new try or, better,  to compile the
> gcl/axiom 
> source code if it's available somewhere.
> 	(tomorrow since it's late here...).
>


> To: Bill Page
> Subject: re: gcl-2.6.8pre on MAC OSX 10.2
>
>
>
> Le 2 nov. 06 =E0 00:04, Page, Bill a =E9crit :
>
> > On Wednesday, November 01, 2006 1:03 PM Martin Rubey wrote:
> >> ...
> >> WOW, that's cool! Axiom on the Mac!
> >>
> >
> > Well, the build of AXIOMsys completed successfully. You can
> > download a console-only version of Axiom for native MAC OSX 10
> > on PowerPC here:
> >
> > http://wiki.axiom-developer.org/public/AXIOMsys-ppc-20061101.tgz
> >
> > As usual, untar it into a convenient place like /usr/local
> >
> >   $ cd /usr/local
> >   $ tar xzf ~/AXIOMsys-ppc-20061101.tgz
> >
> > and then setup the AXIOM and PATH variables like this:
> >
> >   $ export AXIOM=/usr/local/powerpc-apple-darwin6.8
> >   $ export PATH=$AXIOM/bin:$PATH
> >
> > and start Axiom like this:
> >
> >   $ AXIOMsys
> >
> >   (1) -> integrate(1/sqrt(1-x^2),x)
> >
> > exit Axiom with this command:
> >
> >   (99) -> )quit
> >   yes
> >
> > --------
> >
> > The MAC server on which this was compiled did not have an X-windows
> > environment so it was not possible to compile and test
> Axiom Graphics
> > and the Hyperdoc browser. Also native MAC OSX10 apparently does not
> > have support for the pts virtual terminal interface so it is not
> > possible yet to compile clef (the replacement for readline).
> >
> > Because of these problems, it is not possible to use the existing
> > Axiom source distribution without some changes to accommodate
> > the limited hardware environment. But if you are familiar with
> > development on a MAC and would like to give this a try, please
> > let you know and I can make the current preliminary sources
> > available.
> >
> > I look forward to some comments from MAC users! :-)

\start
Date: Thu, 2 Nov 2006 14:27:40 -0500
From: Tim Daly
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> Please download the new binary for AXIOMsys on MAC OSX PowerPC from:
> 
> http://wiki.axiom-developer.org/public/AXIOMsys-ppc-20061102.tgz

Error: Cannot open the file /home/users/b/bi/billpage/asx/axiom.build-improvements/target/powerpc-apple-darwin6/algebra/compress.daase

\start
Date: Thu, 2 Nov 2006 14:30:18 -0500
From: Tim Daly
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> Please download the new binary for AXIOMsys on MAC OSX PowerPC from:
> 
> http://wiki.axiom-developer.org/public/AXIOMsys-ppc-20061102.tgz

chdir /tmp/powerpc-apple-darwin6
export AXIOM=`pwd`
cd bin
./AXIOMsys

starts ok, loads databases, but typing 1 at the axiom prompt hangs.

\start
Date: Thu, 2 Nov 2006 14:35:57 -0500
From: Tim Daly
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> Please download the new binary for AXIOMsys on MAC OSX PowerPC from:
> 
> http://wiki.axiom-developer.org/public/AXIOMsys-ppc-20061102.tgz

chdir /tmp/powerpc-apple-darwin6
export AXIOM=`pwd`
cd bin
./AXIOMsys

-> )set mes auto on

Error: The variable BLOCK is unbound
>> :bt
#0   APPLY (loc0=#<compiled-function system:universal-error-handler>,loc1=:unbound-variable...} [ihs=7]
#1   APPLY (loc0=#<compiled-function system:universal-error-handler>,loc1=:unbound-variable...} [ihs=6]
Error: NIL is an illegal ihs index

Error signalled by SYSTEM::DBL-BACKTRACE
Backtrace: system:univeral-error-handler > system::break-call > system::dbl-backtrace -> system:ihs-fun > lambda > lambda-closure > block > apply > APPLY

\start
Date: 02 Nov 2006 21:10:55 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

| Waldek,
| 
| Thank you! Your patch to openpty for MAC OSX worked perfectly.
| clef now compiles correctly. :-)
| 
| I think this change should go in.

If it is tested to work, then please add apporpriate ChangeLog entry
to commit to both build-improvements and trunk.

\start
Date: Thu, 2 Nov 2006 22:06:59 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> Bill Page writes:
> 
> | Waldek,
> | 
> | Thank you! Your patch to openpty for MAC OSX worked perfectly.
> | clef now compiles correctly. :-)
> | 
> | I think this change should go in.
> 
> If it is tested to work, then please add apporpriate ChangeLog entry
> to commit to both build-improvements and trunk.
> 

I think we should state clearly what is the status of /trunk and
how /trunk is related to /silver on SourceForge? 

\start
Date: 02 Nov 2006 23:42:27 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Waldek Hebisch writes:

| > Bill Page writes:
| > 
| > | Waldek,
| > | 
| > | Thank you! Your patch to openpty for MAC OSX worked perfectly.
| > | clef now compiles correctly. :-)
| > | 
| > | I think this change should go in.
| > 
| > If it is tested to work, then please add apporpriate ChangeLog entry
| > to commit to both build-improvements and trunk.
| > 
| 
| I think we should state clearly what is the status of /trunk and
| how /trunk is related to /silver on SourceForge? 

My understanding is that silver and tunk are synonymous.   Any
difference is not supposed to last.

\start
Date: Fri, 3 Nov 2006 00:13:02 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | > Bill Page writes:
> | > 
> | > | Waldek,
> | > | 
> | > | Thank you! Your patch to openpty for MAC OSX worked perfectly.
> | > | clef now compiles correctly. :-)
> | > | 
> | > | I think this change should go in.
> | > 
> | > If it is tested to work, then please add apporpriate ChangeLog entry
> | > to commit to both build-improvements and trunk.
> | > 
> | 
> | I think we should state clearly what is the status of /trunk and
> | how /trunk is related to /silver on SourceForge? 
> 
> My understanding is that silver and tunk are synonymous.   Any
> difference is not supposed to last.
> 

AFAICS the differences are small but growing -- the robot forwards
Tims patches to /silver but in the last few days nothing went to
/trunk. 

\start
Date: Thu, 02 Nov 2006 19:21:23 -0400
From: Humberto Zuazaga
To: Camm Maguire
Subject: re: sock_get_string_buf

Camm Maguire wrote:
>
> Without any path setting?  In any case, I jsut checked, and it just
> skips the msgfmt calls now, the libintl et.al. stuff is the same.

I still was having problems with libintl not being found, I finally
figured out that my makedefs file still had -lintl, I think we need to
change h/powerpc-macosx.defs:

Index: h/powerpc-macosx.defs
==========================
==========================
=================
RCS file: /sources/gcl/gcl/h/powerpc-macosx.defs,v
retrieving revision 1.2.2.3.4.1.10.1
diff -a -u -r1.2.2.3.4.1.10.1 powerpc-macosx.defs
--- h/powerpc-macosx.defs       18 Oct 2006 17:08:56 -0000
1.2.2.3.4.1.10.1
+++ h/powerpc-macosx.defs       2 Nov 2006 23:16:54 -0000
@@ -6,7 +6,7 @@

 # Set this to avoid warnings when linking against libncurses.
 # This is due to the requirements of the two level namespace.
-LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'` -lintl
+LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'`

 # Set this for the linker to operate correctly.
 MACOSX_DEPLOYMENT_TARGET = 10.2

now gcl-2.6.8pre builds on my PowerPC Mac OS X 10.4.8 machine.

\start
Date: Thu, 02 Nov 2006 19:31:30 -0400
From: Humberto Zuazaga
To: list
Subject: re: sock_get_string_buf

root wrote:

> I moved from fink to Xcode for Axiom development at the suggestion
> of someone on the list. Fink was not working well for me, probably
> due to my lack of MAC experience.

I'm a little confused. I have both fink and XCode installed. AFAIK, fink
requires the XCode gcc compilers and the rest of the toolchain installed.

On the other hand, the current gcl sources require pdflatex to process
the documentation, and I have that installed from fink. Which pdflatex
are you using?

Have you removed fink from your system, or just installed the XCode
compilers?

\start
Date: Fri, 3 Nov 2006 00:31:09 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: re: Bug#346552: naive methods of exiting axiom	can blow up catastrophically
Cc: Camm Maguire, Tom Hargreaves

I wrote:
> root wrote:
> > Apparently the ptys are opened in raw mode and do not interpret the
> > control characters but pass them down the pipe to AXIOMsys. However
> > the (read) from axiom simply gets the cntrl-D and tries to parse it.
> > 
> > I'm not really sure how this should be handled. Clearly you don't
> > want sman to open up a pty that interprets control characters.
> > Nor do you want lisp's (read) to interpret control characters.
> > 
> 
> It is not the case.  One thing is a bug in sman: when the user
> presses ^D\n sman passes "(1) ->\n" (more precisly AXIOMsys
> reads what is inside quotes).  AXIOMsys reacts with an error
> message (exactly like if user gave this input).

I tracked the problem one step further:

There is a bug in 'sockio-c.c.pamphlet'. Namely, 'remote_stdio'
function contains the following code:

    if (FD_ISSET(0, &rd)) {
      fgets(buf,1024,stdin);
      len = strlen(buf);
      /*
          gets(buf);
          len = strlen(buf);
          *(buf+len) = '\n';
          *(buf+len+1) = '\0';
      */
      swrite(sock, buf, len, "writing to remote stdin");

If we have EOF on stdin fgets reads nothing and the old content
of 'buf' (containing the last AXIOMsys output!) is sent back to
AXIOMsys.  I am not sure what the correct fix is: we can easily
detect EOF, but we can not just exit: to exit we have kill
the whole tree of processes spawned by 'sman'.  The code above
is executed from 'spadclient' and it is possible to have
more than one copy of 'spadclient' connected to one AXIOMsys,
so we probably should track number of connected clients
and exit AXIOMsys when number of clients goes down to zero
(but we have to be careful at startup, as for short time
there is no client).

\start
Date: Thu, 2 Nov 2006 18:45:54 -0500
From: Tim Daly
To: Humberto Zuazaga
Subject: re: sock_get_string_buf
Cc: Camm Maguire

Camm,

I removed the -lintl from powerpc-macosx.defs LIBS line
and now I can successfully build GCL on MAC OSX with the options
./configure --enable-locbfd --disable-statsysbfd --disable-nls
on the MAC OSX PPC platform.

I tried:

GCL
> (setq a 3)
> (system::save-system "test")
./test
a
 
and get the answer 3

===========================================

the same configure options work on RedHat 7.2


I'm going to try the test on FC6.

\start
Date: Fri, 3 Nov 2006 01:09:31 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: hypertex and documentation search

On one machine documentation searching did not work. The problem
was that on that machine there was already intalled 'htsearch'
program (which is searching trough HTML pages) and hypertex
picked the instlled program (which was on the PATH) insted of
Axiom version.  AFAICS the simplest solution for this problem
is to put Axiom directory first in the PATH.

I also noticed that summary of search results was incorrect.

The patch below fixes both problems:

diff -ru pp/build-improvements/src/etc/axiom build-improvements/src/etc/axiom
--- pp/build-improvements/src/etc/axiom	Fri Sep  8 03:06:52 2006
+++ build-improvements/src/etc/axiom	Tue Oct 31 15:32:57 2006
@@ -77,7 +77,7 @@
   if [ "$AXIOM" = "" ] ; then
     SPAD=$SPADDEFAULT
     echo "AXIOM variable is not set"
-    echo "assuming AXIOM = /axiom/mnt/linuxglibc"
+    echo "assuming AXIOM = $SPAD"
     AXIOM=$SPAD
     export AXIOM
   else
@@ -103,7 +103,7 @@
 AXIOMXLROOT=${AXIOM}/compiler
 fi
 export AXIOMXLROOT
-PATH=$AXIOMXLROOT/bin:${PATH}
+PATH=$AXIOM/bin:$AXIOMXLROOT/bin:${PATH}
 export PATH
 
 
diff -ru pp/build-improvements/src/hyper/search.pamphlet build-improvements/src/hyper/search.pamphlet
--- pp/build-improvements/src/hyper/search.pamphlet	Fri Sep 29 21:09:42 2006
+++ build-improvements/src/hyper/search.pamphlet	Sun Oct 29 22:00:34 2006
@@ -38,7 +38,8 @@
 	a[n] = $0;
 	n=n+1;
         j=split($0,b,"{");
-        m=m+substr(b[j],1,length(b[j])-1);
+        if (j >= 2)
+          m=m+substr(b[2],1,length(b[2])-1);
 }
 
 END {

\start
Date: 03 Nov 2006 01:12:31 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Waldek Hebisch writes:
| > 
| > | > Bill Page writes:
| > | > 
| > | > | Waldek,
| > | > | 
| > | > | Thank you! Your patch to openpty for MAC OSX worked perfectly.
| > | > | clef now compiles correctly. :-)
| > | > | 
| > | > | I think this change should go in.
| > | > 
| > | > If it is tested to work, then please add apporpriate ChangeLog entry
| > | > to commit to both build-improvements and trunk.
| > | > 
| > | 
| > | I think we should state clearly what is the status of /trunk and
| > | how /trunk is related to /silver on SourceForge? 
| > 
| > My understanding is that silver and tunk are synonymous.   Any
| > difference is not supposed to last.
| > 
| 
| AFAICS the differences are small but growing -- the robot forwards
| Tims patches to /silver but in the last few days nothing went to
| /trunk. 

Bill --

  There should be only one main repository -- /trunk.  My
understanding was that /silver was created as an intermediate step,
preventively, to make sure that we did not lose any data.  Is that
correct? 

\start
Date: Thu, 2 Nov 2006 19:13:42 -0500
From: Tim Daly
To: Camm Maguire
Subject: lastest tests

I did a checkout of

cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
With the patch to remove the -lintl from h/powerpc-macosx.defs LIBS line
./configure --enable-locbfd --disable-statsysbfd --disable-nls
make
./bin/gcl
(setq a 3)
(system::save-system "test")
./test
a
yields 3


successfully builds and saves on MAC OSX PPC
successfully builds and saves on FreeBSD
successfully builds and saves on Debian
successfully builds and saves on Ubuntu
successfully builds and saves on Fedora 4
successfully builds and saves on Fedora 5
successfully builds and saves on Fedora 6
successfully builds and saves on RedHat 9
successfully builds and saves on RedHat 7.2

\start
Date: 03 Nov 2006 01:22:32 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: hypertex and documentation search

Waldek Hebisch writes:

| On one machine documentation searching did not work. The problem
| was that on that machine there was already intalled 'htsearch'
| program (which is searching trough HTML pages) and hypertex
| picked the instlled program (which was on the PATH) insted of
| Axiom version.

The complete correction should invoke Axiom's htsearch with either
absolute or relative path, instead of relying on PATH.  
Could you give that a shot?

\start
Date: 03 Nov 2006 01:27:52 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: lastest tests
Cc: Camm Maguire

Tim Daly writes:

| I did a checkout of
| 
| cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
| With the patch to remove the -lintl from h/powerpc-macosx.defs LIBS line
| ./configure --enable-locbfd --disable-statsysbfd --disable-nls
| make
| ./bin/gcl
| (setq a 3)
| (system::save-system "test")
| ./test
| a
| yields 3
| 
| 
| successfully builds and saves on MAC OSX PPC
| successfully builds and saves on FreeBSD
| successfully builds and saves on Debian
| successfully builds and saves on Ubuntu
| successfully builds and saves on Fedora 4
| successfully builds and saves on Fedora 5
| successfully builds and saves on Fedora 6
| successfully builds and saves on RedHat 9
| successfully builds and saves on RedHat 7.2

We're back to home.  Great!

\start
Date: 03 Nov 2006 01:28:45 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: lastest tests
Cc: Camm Maguire

Tim Daly writes:

| I did a checkout of
| 
| cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
| With the patch to remove the -lintl from h/powerpc-macosx.defs LIBS line

I'll commit that patch to gcl-2.8.pre, and update axiom.build-improvements.

\start
Date: Thu, 02 Nov 2006 20:48:07 -0400
From: Humberto Zuazaga
To: Camm Maguire
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Camm Maguire wrote:

> locbfd should be the default on macosx, as we have Aurelien's specific
> mods for .o file loading.  Extending this default to the intel should
> resolve the -lintl 'out of the box'.  This said, I'd be quite
> (pleasantly) surprised if Aurelien's code works as is on intel.  This
> should be tried first -- if you can compile and load a simple file,
> all is well.

No such luck. Considering that h/powerpc-macosx.h has inline (PowerPC)
assembly, it's not likely to work (line 91).

The code is for "Processor cache synchronization code." I'm definitely
in over my head here. I don't have the foggiest notion how to implement
the equivalent on Intel Macs.


>  Otherwise, the brain-dead default entry-level loading
> option is --disable-statsysbfd --enable-dlopen.

Can I simply delete the cache sync code and try this?

\start
Date: Fri, 3 Nov 2006 01:52:28 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: gcl-2.6.8pre on Debian unstable

I just re-tried using gcl-2.6.8 on Debian unstable.  Previously
build died when making BSD (due to 'msgfmt').  I wanted to test
'--disable-nls' option, but this time build failed much earlier,
already gcl configure barfed:

....
# Subconfigure of BFD done
# ------------------------
#
checking for long... yes
checking size of long... 8
checking sizeof struct contblock... Cannot find sizeof struct contblock
checking build system type... make[1]: *** [/home/s/test/tt/axiom5/ax-build3/build/x86_64-unknown-linux/bin/gcl] Error 1
make[1]: Leaving directory `/home/s/test/tt/axiom5/ax-build3/lsp'
make: *** [all-recursive] Error 1
x86_64-unknown-linux-gnu
....

The machine was not updated for long time, so this may be due to
machine misconfiguration...

\start
Date: Fri, 3 Nov 2006 02:08:46 +0100 (CET)
From: Waldek Hebisch
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

Humberto Ortiz-Zuazaga wrote:
> No such luck. Considering that h/powerpc-macosx.h has inline (PowerPC)
> assembly, it's not likely to work (line 91).
> 
> The code is for "Processor cache synchronization code." I'm definitely
> in over my head here. I don't have the foggiest notion how to implement
> the equivalent on Intel Macs.
> 
> 
> >  Otherwise, the brain-dead default entry-level loading
> > option is --disable-statsysbfd --enable-dlopen. 
> 
> Can I simply delete the cache sync code and try this?

AFAIK that this code is not needed on Intel processors (processor
should automatically keep caches in sync).

\start
Date: Fri, 3 Nov 2006 02:28:10 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: hypertex and documentation search

> Waldek Hebisch writes:
> 
> | On one machine documentation searching did not work. The problem
> | was that on that machine there was already intalled 'htsearch'
> | program (which is searching trough HTML pages) and hypertex
> | picked the instlled program (which was on the PATH) insted of
> | Axiom version.
> 
> The complete correction should invoke Axiom's htsearch with either
> absolute or relative path, instead of relying on PATH.  
> Could you give that a shot?
> 

For htsearch alone this is resonably easy, the following snippet
from 'man0.ht' (in two copies) is responsible for its invocation.

\menuunixlink{Search}
  {htsearch "\stringvalue{pattern}"}
  \tab{15} Reference documentation ({\em *} wild card is not accepted).

We should use '{\$SPAD/bin/htsearch "\stringvalue{pattern}"}' or
'{\$AXIOM/bin/htsearch "\stringvalue{pattern}"}' instead.  
But there is also a lot of references to 'viewAlone' (this can be
solved with extra sed rule). 'spadclient' use wrong path...

\start
Date: Thu, 02 Nov 2006 22:05:14 -0400
From: Humberto Zuazaga
To: list
Subject: Turtles all the way down.

Axiom's a pretty complex system, and it seems to have picked up a bunch
of other projects like clef, noweb, and gcl, and like all good lisp
systems,  even recursive project dependencies like gcl has it's own bfd,
and gmp.

There is still a set of external dependencies that have to be satisfied,
like pdflatex, gcc, and others.

The recent clef/readline thread points out it may be advantageous to
review the list of internal and external dependencies, and prune some cod=
e.

What are people thinking about the builds of axiom? Debian tries to
patch axiom to use system supplied tools and libraries where possible,
the Mac OS X port tries to use local copies of everything.
build-improvements stated goals are to automagically pick up any
installed copies and build the rest internally.

I ask because I had to mangle ./configure to fix a test for
malloc/malloc.h on Intel Mac. Neither of the autoconf programs installed
on my Mac like the configure.in in gcl-2.6.8pre:

$ /sw/bin/autoconf --version
autoconf (GNU Autoconf) 2.60

$ /usr/bin/autoconf --version
autoconf (GNU Autoconf) 2.59

configure says it's been generated with autoconf 2.13.

I guess there's really no way to ship axiom with it's own autoconf if we
have any expectation of using configure to build axiom, but how far down
do we plan to go? I saw Gaby is seriously considering integrating gcl
and gcc.

\start
Date: Thu, 2 Nov 2006 21:23:14 -0500
From: Bill Page
To: Waldek Hebisch, Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Gaby and Waldek,

As we discussed last week (see "famous" diagram attached below),
SourceForge svn /silver was created so that we would have an
svn branch automatically maintained in sync with Tim's "official"
tla axiom--silver--1. This is now in place. A Tailor script runs
every night to update svn /silver with Tim's latest patches.

To get this to work, Tailor has to *start* in a state with the
svn branch exactly equal to the tla branch. I could not find any
automatic way to merge the existing svn /trunk with tla
axiom--silver--1, so I let Tailor bootstrap svn /silver directly
from tla axiom--silver--1 as the first step in setting up the
automatic synchronization.

Tim Daly agreed to apply all the patches that are unique to
svn /trunk to axiom--silver--1. These were accurately identified
by Waldek Hebisch in a series of emails last week. Because of the
auto sync, this will effectively merge svn /trunk into svn /silver
(see diagram below). In addition Tim will also continue to merge
any patches that he receives by email (and approves) into tla
axiom--silver--1, whence to svn /silver.

My current proposal is that when Tim's merge of the old svn /trunk
into svn /silver is accomplished, then svn /silver should become the
new official "trunk" and the existing svn /trunk should be deleted.
As I understand it, whether or not we eventually rename svn /silver
to svn /trunk is probably only important to people who care more
about standard svn terminology than either Tim Daly or me. ;)

There are two active svn branches on SourceForge, build-improvements
and hersen-algebra-improvements. Both of these were originally
cloned from svn /trunk. There might be some advantage to retain
the original svn /trunk until at least the merging of these
branches into the new svn /silver "trunk" is complete. Again,
please refer to diagram.

Of course this discussion is not over and I am open to suggestions
as to how to improve the situation.

In any case, please keep in mind that we had previously agreed that
all patches to silver would be sent by email to Tim Daly and that
he would be responsible for review and applying these changes to
axiom--silver--1. That is the route by which patches are supposed
to the new svn /silver "trunk".

Regards,
Bill Page.

On November 2, 2006 4:07 PM Waldek Hebisch wrote:
> ... 
> I think we should state clearly what is the status of /trunk and
> how /trunk is related to /silver on SourceForge? 
> 

On November 2, 2006 5:42 PM Gaby wrote:
> 
> My understanding is that silver and trunk are synonymous.   Any
> difference is not supposed to last.
> 

On November 2, 2006 6:13 PM Waldek Hebisch wrote:
> 
> AFAICS the differences are small but growing -- the robot forwards
> Tim's patches to /silver but in the last few days nothing went to
> /trunk. 
> 

On November 2, 2006 7:13 PM Gaby wrote:
> 
> Bill --
> 
>   There should be only one main repository -- /trunk.  My
> understanding was that /silver was created as an intermediate
> step, preventively, to make sure that we did not lose any data.
> Is that correct? 
> 

On October 27, 2006 3:58 PM Bill Page wrote:

> 
> Here is how I see the situation:
> 
>             |       |            |           |
>             |       |        darcs and       |
>             |    next big =  hg mirrors      |
>             |    experiment      |           |
>  gold       |   /                            |
>  gold <---- |  /                             |
>  (52)     silver  (SourceForge) <=====> Google Code
>             |                             mirror
>             |\___merge___                    |
>  gold <---- |            \        |          |
>  (51)       |\__          |       |          |
>            /    \   back  |   darcs and      |
>  gold <---|-<----\ .....> / = hg mirrors     |
>  (50)     /      /  port |        |          |
>          |      |        |        |          |
> Now:   silver trunk    build
>          |      |   improvements
>         tla     |    /
>                 |   /
>                 |  /
>  gold <------ trunk
>  (49)           |
>                CVS
> 
> ...
>
> SVN /trunk was created to be Silver from which the
> experimental branches would be branched.
>  
> > axiom--silver--1 was created to be a pre-gold version of
> > the system with "early release" of changes so they can be
> > tested.
> 
> No. axiom--silver--1 was created to be a mirror of SVN /trunk
> (now called SVN /silver) so that you would not have to deal
> with the problems of using SVN.
> 
> > 
> > axiom--main--1 is the "official system"
> >
> 
> Right. Gold.
> ...

\start
Date: 03 Nov 2006 03:35:56 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: Re: Turtles all the way down.

Humberto Zuazaga writes:

| Axiom's a pretty complex system, and it seems to have picked up a bunch
| of other projects like clef, noweb, and gcl, and like all good lisp
| systems,  even recursive project dependencies like gcl has it's own bfd,
| and gmp.
| 
| There is still a set of external dependencies that have to be satisfied,
| like pdflatex, gcc, and others.
| 
| The recent clef/readline thread points out it may be advantageous to
| review the list of internal and external dependencies, and prune some code.
| 
| What are people thinking about the builds of axiom?

The current build machinery is needlessly too complex, flawed, and
would gain in reducing the number of things it currently duplicates.

| Debian tries to
| patch axiom to use system supplied tools and libraries where possible,
| the Mac OS X port tries to use local copies of everything.

:-(

| build-improvements stated goals are to automagically pick up any
| installed copies and build the rest internally.
| 
| I ask because I had to mangle ./configure to fix a test for
| malloc/malloc.h on Intel Mac. Neither of the autoconf programs installed
| on my Mac like the configure.in in gcl-2.6.8pre:
| 
| $ /sw/bin/autoconf --version
| autoconf (GNU Autoconf) 2.60
| 
| $ /usr/bin/autoconf --version
| autoconf (GNU Autoconf) 2.59

yes, that is annoying.  I tripped over that issue a couple of days ago. 
Mostly, it is a matter of GCL's configure.in being "under-quoted" --
it needs more quotes in several places, especially those with nested
macro invokations.  The world is at Autoconf 2.60; GCL's is stuck at
Autoconf 2.13.  I did not want to mess with it more than needed
especially on the gcl-2.6.8pre branch.  However, I definitely consider
a lifting for gcl-2.7.x.

| configure says it's been generated with autoconf 2.13.

yes.  

| I guess there's really no way to ship axiom with it's own autoconf if we

I do hope we don't go down that path.

| have any expectation of using configure to build axiom, but how far down
| do we plan to go? I saw Gaby is seriously considering integrating gcl
| and gcc.

The integration of GCL to GCC is not going to happen for GCC-4.3 (we
just entered the initial development phase for GCC-4.3).  It
probably is something like GCC-4.4.0 or GCC-4.5.0.

However, GCL's configure.in issue is easily solved though.  

What specifically did you want to do with malloc/malloc.h?

\start
Date: Thu, 02 Nov 2006 22:42:26 -0400
From: Humberto Zuazaga
To: Humberto Zuazaga
Subject: Re: Turtles all the way down.

Humberto Ortiz-Zuazaga wrote:
> Axiom's a pretty complex system, and it seems to have picked up a bunch=

> of other projects like clef, noweb, and gcl, ...

> What are people thinking about the builds of axiom?

I'm sorry, I just found the September 2006 archive of the
axiom-developer list where these very issues are discussed at length.

http://lists.nongnu.org/archive/html/axiom-developer/2006-09/

Please excuse my ignorance, I'll try to stick to useful patches for a whi=
le.

:-)

\start
Date: 03 Nov 2006 03:45:43 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

[...]

| There are two active svn branches on SourceForge, build-improvements
| and hersen-algebra-improvements. Both of these were originally
| cloned from svn /trunk. There might be some advantage to retain
| the original svn /trunk until at least the merging of these
| branches into the new svn /silver "trunk" is complete. Again,
| please refer to diagram.

SVK/SVN can do merge across branches, so we should be able -in
principle- to merge existing branches to whatever becomes The trunk.

[...]

| > Here is how I see the situation:
| > 
| >             |       |            |           |
| >             |       |        darcs and       |
| >             |    next big =  hg mirrors      |
| >             |    experiment      |           |
| >  gold       |   /                            |
| >  gold <---- |  /                             |
| >  (52)     silver  (SourceForge) <=====> Google Code
| >             |                             mirror
| >             |\___merge___                    |
| >  gold <---- |            \        |          |
| >  (51)       |\__          |       |          |
| >            /    \   back  |   darcs and      |
| >  gold <---|-<----\ .....> / = hg mirrors     |
| >  (50)     /      /  port |        |          |
| >          |      |        |        |          |
| > Now:   silver trunk    build
| >          |      |   improvements
| >         tla     |    /
| >                 |   /
| >                 |  /
| >  gold <------ trunk
| >  (49)           |
| >                CVS
| > 
| > ...
| >
| > SVN /trunk was created to be Silver from which the
| > experimental branches would be branched.
| >  
| > > axiom--silver--1 was created to be a pre-gold version of
| > > the system with "early release" of changes so they can be
| > > tested.
| > 
| > No. axiom--silver--1 was created to be a mirror of SVN /trunk
| > (now called SVN /silver) so that you would not have to deal
| > with the problems of using SVN.

This clarifiers the terminology for me.

\start
Date: Thu, 02 Nov 2006 22:57:21 -0400
From: Humberto Zuazaga
To: Gabriel Dos Reis
Subject: Re: configure changes for intel mac

Gabriel Dos Reis wrote:

> What specifically did you want to do with malloc/malloc.h?

Add i386-macosx to powerpc-macosx test for malloc/malloc.h:

$ cvs diff -Nau configure.in
Index: configure.in
==========================
==========================
=================
RCS file: /sources/gcl/gcl/configure.in,v
retrieving revision 1.112.4.1.2.2.2.47.2.3.2.1.4.2.4.2.4.24
diff -a -u -r1.112.4.1.2.2.2.47.2.3.2.1.4.2.4.2.4.24 configure.in
--- configure.in        2 Nov 2006 14:25:39 -0000
1.112.4.1.2.2.2.47.2.3.2.1.4.2.4.2.4.24
+++ configure.in        3 Nov 2006 02:52:22 -0000
@@ -563,7 +563,7 @@
     fi
 fi

-if test "$use" = "powerpc-macosx" ; then
+if test "$use" = "powerpc-macosx" -o "$use" = "i386-macosx" ; then
    AC_CHECK_HEADER(malloc/malloc.h,[AC_DEFINE([HAVE_MALLOC_MALLOC_H])],
       [AC_CHECK_HEADER(objc/malloc.h,[AC_DEFINE([HAVE_OBJC_MALLOC_H])],
        [AC_MSG_ERROR([need malloc.h on macosx])])])


The build still won't work, but I've made some progress.

\start
Date: Thu, 2 Nov 2006 22:04:13 -0500
From: Bill Page
To: list
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On November 2, 2006 2:28 PM Tim Daly wrote:

>
> Bill Page wrote:
> 
> > Please download the new binary for AXIOMsys on MAC OSX PowerPC from:
> >
> > http://wiki.axiom-developer.org/public/AXIOMsys-ppc-20061102.tgz
>
> Error: Cannot open the file
> /home/users/b/bi/billpage/asx/axiom.build-improvements/target/
> powerpc-apple-darwin6/algebra/compress.daase
>

I assume this error was spurious?

On November 2, 2006 2:30 PM Tim Daly wrote:

> ...
> chdir /tmp/powerpc-apple-darwin6
> export AXIOM=`pwd`
> cd bin
> ./AXIOMsys
>
> starts ok, loads databases, but typing 1 at the axiom prompt hangs.
>

Very odd. :-(


On November 2, 2006 2:36 PM Tim Daly wrote:

> ...
> chdir /tmp/powerpc-apple-darwin6
> export AXIOM=`pwd`
> cd bin
> ./AXIOMsys
>
> -> )set mes auto on
>
> Error: The variable BLOCK is unbound
> >> :bt
> #0   APPLY (loc0=#<compiled-function
> system:universal-error-handler>,loc1=:unbound-variable...} [ihs=7]
> #1   APPLY (loc0=#<compiled-function
> system:universal-error-handler>,loc1=:unbound-variable...} [ihs=6]
> Error: NIL is an illegal ihs index
>
> Error signalled by SYSTEM::DBL-BACKTRACE
> Backtrace: system:univeral-error-handler > system::break-call
> > system::dbl-backtrace -> system:ihs-fun > lambda >
> lambda-closure > block > apply > APPLY
>

This looks like a Lisp problem, but on the SourceForge compile
farm MAC OSX server where I compiled this binary I get:

---------

Welcome to SF.net Compile Farm - OSX X-Serve, provided by Apple
OS X Version 10.2.x

ppc-osx3:~/osx $ export `pwd`/local/powerpc-apple-darwin6.8
bash: export: =
`/home/users/b/bi/billpage/osx/local/powerpc-apple-darwin6.8':
not a valid identifier
ppc-osx3:~/osx $ export AXIOM=`pwd`/local/powerpc-apple-darwin6.8
ppc-osx3:~/osx $ export PATH=$AXIOM/bin:$PATH
ppc-osx3:~/osx $ AXIOMsys

GCL (GNU Common Lisp)  2.6.8 CLtL1    Nov  1 2006 17:41:53
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
                        AXIOM Computer Algebra System
          Version: Axiom (build improvements branch) -- 2006-10-10
              Timestamp: Thursday November 2, 2006 at 10:29:25
-------------------------------------------------------------------------=
---
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-------------------------------------------------------------------------=
---
-

   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase
(1) -> )set mes auto on
(1) -> 1

   (1)  1
                                                        Type:
PositiveInteger
(2) -> 1+1

   (2)  2
                                                        Type:
PositiveInteger
(3) -> )quit
   Please enter y or yes if you really want to leave the interactive
      environment and return to the operating system:
yes
ppc-osx3:~/osx $ exit

--------

On November 2, 2006 3:08 PM Humberto Ortiz Zuazaga wrote:
>
> Bill Page wrote:
> >
> > Please download the new binary for AXIOMsys on MAC OSX PowerPC from:
> >
> > http://wiki.axiom-developer.org/public/AXIOMsys-ppc-20061102.tgz
>
> Testing on PowerPC Mac OS X 10.4.8:
>
> $ export AXIOM=/tmp/axiom/powerpc-apple-darwin6.8
> $ export PATH=$AXIOM/bin:$PATH
> $ AXIOMsys
> GCL (GNU Common Lisp)  2.6.8 CLtL1    Nov  1 2006 17:41:53
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (BFD UNEXEC)
> Modifications of this banner must retain notice of a
> compatible license
> Dedicated to the memory of W. Schelter
>
> Use (help) to get some basic information on how to use GCL.
> Temporary directory for compiler files set to /tmp/
>                          AXIOM Computer Algebra System
>            Version: Axiom (build improvements branch) -- 2006-10-10
>                Timestamp: Thursday November 2, 2006 at 10:29:25
> --------------------------------------------------------------
>     Issue )copyright to view copyright notices.
>     Issue )summary for a summary of useful system commands.
>     Issue )quit to leave AXIOM and return to shell.
> --------------------------------------------------------------
>
>     Re-reading compress.daase   Re-reading interp.daase
>     Re-reading operation.daase
>     Re-reading category.daase
>     Re-reading browse.daase
> Illegal instruction
>

I would like to be able to explain the differences between Tim
Daly's results above and this one. Could you both please provide
detailed information about the computer hardware and operating
system? What cpu? What version of OSX?

On November 2, 2006 4:37 PM Raymond Manzoni wrote:

> ...
> 	I got this time on my OSX 10.4.8 PPC :
>
> $ AXIOMsys
> GCL (GNU Common Lisp)  2.6.8 CLtL1    Nov  1 2006 17:41:53
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (BFD UNEXEC)
> Modifications of this banner must retain notice of a
> compatible license
> Dedicated to the memory of W. Schelter
>
> Use (help) to get some basic information on how to use GCL.
> Temporary directory for compiler files set to /tmp/
>                          AXIOM Computer Algebra System
>            Version: Axiom (build improvements branch) -- 2006-10-10
>                Timestamp: Thursday November 2, 2006 at 10:29:25
> --------------------------------------------------------------
>     Issue )copyright to view copyright notices.
>     Issue )summary for a summary of useful system commands.
>     Issue )quit to leave AXIOM and return to shell.
> --------------------------------------------------------------
>     Re-reading compress.daase   Re-reading interp.daase
>     Re-reading operation.daase
>     Re-reading category.daase
>     Re-reading browse.daase
> Illegal instruction
>

Hmmm... at least that is consistent with Humberto's results. :-(

Can you give me any more specific information about the cpu?
Can you suggest some command that I can give to the SourceForge
compile farm OSX system that I am using that will give equivalent
information for comparison?

> =09
> --------------------------------------------------------------
> 	I tried to launch it with gdb (my first use of gdb...) and got :
> (gdb) run
>     ...
>     Re-reading browse.daase
>
> Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/
> operand.
> 0x00de9c44 in socket_mask ()
> (gdb) up
> #1  0x00de9c44 in socket_mask ()
> (gdb) up
> Previous frame identical to this frame (corrupt stack?)
>

If we compile gcl with the .configure option --enable-debug, then
we can get a more detailed traceback that Camm Maguire (gcl
developer) should be able to use to help diagnose the problem.

>
> --------------------------------------------------------------
> 	The CrashReporter (Library/Logs/AXIOMsys.crash.log
> file) reported :
>
> Host Name:      Raym
> Date/Time:      2006-11-02 21:54:40.899 +0100
> OS Version:     10.4.8 (Build 8L127)
> Report Version: 4
>
> Command: AXIOMsys
> Path:    /Users/raym/Desktop/powerpc-apple-darwin6.8/bin/AXIOMsys
> Parent:  bash [244]
>
> Version: ??? (???)
>
> PID:    247
> Thread: 0
>
> Exception:  EXC_BAD_INSTRUCTION (0x0002)
> Code[0]:    0x00000002
> Code[1]:    0x00de9c44
> ...
>
> 	Looks as if it tried to execute the instruction
> '0x00000002'  called 
> by 0x00de9c44 (socket_mask?)... not too good...
>
> 	Ready for more tests,

At this point I am not sure exactly what to do.

First I suppose I should start this all over again using the
newest version of gcl-2.6.8pre from cvs. This version has a
new (better) treatment of the llibintl problem.

Second, I will build gcl with --enable-debug

Third I will re-build Axiom start with the most recent source
in build-improvements. The source I used to build the current
Axiom binary for MAC is based on build-improvements as of a
couple of weeks ago plus local patches I thought I needed as
I tried to get this to work.

I will let you know when I have another binary. It will probably
not be before the weekend. Maybe someone else with there hands
directly on a MAC would like also to give this a try? If so I
recommend pulling the most recent sources from the build-
improvements branch on SourceForge. If anyone needs help with
this, just ask.

\start
Date: Thu, 02 Nov 2006 23:25:05 -0400
From: Humberto Zuazaga
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page wrote:
> I would like to be able to explain the differences between Tim
> Daly's results above and this one. Could you both please provide
> detailed information about the computer hardware and operating
> system? What cpu? What version of OSX?

The machine is a Dual G5 running OS X 10.4.8.

neverblows:~/src/working humberto$ arch
ppc
neverblows:~/src/working humberto$ uname -a
Darwin neverblows.hpcf.upr.edu 8.8.0 Darwin Kernel Version 8.8.0: Fri
Sep  8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power
Macintosh powerpc
neverblows:~/src/working humberto$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.4.8
BuildVersion:   8L127
neverblows:~/src/working humberto$ system_profiler -detailLevel mini

hangs, but prints out a bunch of information including:

Hardware:

    Hardware Overview:

      Machine Name: Power Mac G5
      Machine Model: PowerMac7,3
      CPU Type: PowerPC G5  (3.0)
      Number Of CPUs: 2
      CPU Speed: 2.5 GHz
      L2 Cache (per CPU): 512 KB
      Memory: 4 GB
      Bus Speed: 1.25 GHz
      Boot ROM Version: 5.1.8f7

\start
Date: Thu, 02 Nov 2006 23:36:24 -0400
From: Humberto Zuazaga
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page wrote:

> I will let you know when I have another binary. It will probably
> not be before the weekend. Maybe someone else with there hands
> directly on a MAC would like also to give this a try? If so I
> recommend pulling the most recent sources from the build-
> improvements branch on SourceForge. If anyone needs help with
> this, just ask.

I have a working gcl on the ppc, what do I need to do to build
build-improvements?

Just pull the source with:

svn co https://svn.sourceforge.net/svnroot/axiom/ \
         branches/build-improvements axiom.build-improvements

and build with the out-of-tree gcl? or do I have to splice the gcl into
the axiom sources?

\start
Date: Thu, 2 Nov 2006 22:46:49 -0500
From: Bill Page
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Thanks!

For the record the same details for the machine I am using is
attached below your message.

Regards,
Bill Page.

On November 2, 2006 10:25 PM Humberto Ortiz-Zuazaga wrote:
> ...
> The machine is a Dual G5 running OS X 10.4.8.
>
> neverblows:~/src/working humberto$ arch
> ppc
> neverblows:~/src/working humberto$ uname -a
> Darwin neverblows.hpcf.upr.edu 8.8.0 Darwin Kernel Version 8.8.0: Fri
> Sep  8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power
> Macintosh powerpc
> neverblows:~/src/working humberto$ sw_vers
> ProductName:    Mac OS X
> ProductVersion: 10.4.8
> BuildVersion:   8L127
> neverblows:~/src/working humberto$ system_profiler -detailLevel mini
>
> hangs, but prints out a bunch of information including:
>
> Hardware:
>
>     Hardware Overview:
>
>       Machine Name: Power Mac G5
>       Machine Model: PowerMac7,3
>       CPU Type: PowerPC G5  (3.0)
>       Number Of CPUs: 2
>       CPU Speed: 2.5 GHz
>       L2 Cache (per CPU): 512 KB
>       Memory: 4 GB
>       Bus Speed: 1.25 GHz
>       Boot ROM Version: 5.1.8f7
>

-----------------

SourceForge Compile Farm MAC OSX 10.2 Server:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2006.11.02 =
22:39:52
=~=~=~=~=~=~=~=~=~=~=~=
system_profiler -detailLevel mini
ppc-osx3:~/osx $ sw_versuname -aarchexitarch
ppc
ppc-osx3:~/osx $ archsystem_profiler -detailLevel mini
ppc-osx3:~/osx $ sw_versuname -aarchuname -a
Darwin ppc-osx3.cf.sourceforge.net 6.8 Darwin Kernel Version 6.8: Wed =
Sep 10
15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC  Power =
Macintosh
powerpc
ppc-osx3:~/osx $ uname -aarchsystem_profiler -detailLevel mini
ppc-osx3:~/osx $ sw_vers
ProductName:Mac OS X Server
ProductVersion:10.2.8
BuildVersion:6R73
ppc-osx3:~/osx $ sw_versuname -aarchsystem_profiler -detailLevel mini

Overview:

    Software Overview:
   
      System version: Mac OS X Server 10.2.8 (6R73) [ Mac OS X 10.2.8 =
(6R73)
]
      Kernel version: Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT
2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC 
      Boot volume:
      User name: Bill Page    (billpage)
   
    Hardware Overview:
   
      Machine model: RackMac1,2 (version = 3.3)
      Number of processors: 2
      Bus speed: 167 MHz
      Machine speed: 1.333 Ghz
      L2 cache size: 256K (times 2)
      Boot ROM info: 4.6.3f1
      Customer serial number: XB31000F-N9C
      L3 cache size: 2MB (times 2)
      Sales order number: Not available
   
    Memory Overview:
   
      DIMM0/J21: 512 MB DDR SDRAM
      DIMM1/J22: <empty>
      DIMM2/J23: <empty>
      DIMM3/J20: <empty>
   
    Network Overview:
   
        Built-in:
       
          Ethernet address: 00.03.93.CC.38.84
          Flags: 0x8863<Up,Broadcast,b6,Running,Simplex,Multicast>
          IP: 10.8.5.44
          Broadcast: 10.8.255.255
          Subnet Mask: 255.255.0.0
       
        :
       
          Ethernet address: 00.03.93.F4.0D.72
          Flags: 0x8863<Up,Broadcast,b6,Running,Simplex,Multicast>
       
        Built-in:
       
          Ethernet address: 00.0A.27.CC.38.84
          Flags: 0x8863<Up,Broadcast,b6,Running,Simplex,Multicast>
       
       

Devices:

    PCI/AGP:
   
        pci106b,9:
       
          Bus: PCI
          Device ID: 0x000016a7
          Revision ID: 0x00000002
          Vendor ID: 0x000014e4
       
        ATY,BlueStar:
       
          Model: ATY,RV100
          Type: display
          Bus: PCI
          Device ID: 0x00005159
          Revision ID: 0x00000000
          Vendor ID: 0x00001002
       
        AppleKiwi:
       
          Type: pci-ide
          Bus: PCI
          Device ID: 0x00006269
          Revision ID: 0x00000003
          Vendor ID: 0x0000105a
       
        AppleKiwi:
       
          Type: pci-ide
          Bus: PCI
          Device ID: 0x00006269
          Revision ID: 0x00000003
          Vendor ID: 0x0000105a
       
    IDE (ATA-4) Bus:
   
        CD-ROM:
       
          Model: QSI CD-ROM TCR-241                     
          Revision: WL09   
          Serial Number:                    
          Device Type: ATAPI
       
    USB 1.1 Bus:
   
      Bus Power (mA): 500
      Speed: Full Speed
      Product ID: 32773 ($8005)
      Serial Number: 0
      Vendor Name: Apple Computer, Inc.
   
        Hub in Apple Extended USB Keyboard:
       
          Bus Power (mA): 500
          Speed: Full Speed
          Product ID: 4099 ($1003)
          Serial Number: 0
          Vendor Name: Mitsumi Electric
       
            Apple Extended USB Keyboard:
           
              Bus Power (mA): 250
              Speed: Full Speed
              Product ID: 523 ($20b)
              Serial Number: 0
              Vendor Name: Mitsumi Electric
           
            Apple Optical USB Mouse:
           
              Bus Power (mA): 100
              Speed: Low Speed
              Product ID: 772 ($304)
              Serial Number: 0
              Vendor Name: Mitsumi Electric
           
    USB 1.1 Bus:
   
      Bus Power (mA): 500
      Speed: Full Speed
      Product ID: 32773 ($8005)
      Serial Number: 0
      Vendor Name: Apple Computer, Inc.
   
    FireWire Bus:
   
      BSD Name: en2
   
        FireWire Device:
       
          Speed: 400 Mb/sec Speed
       
    Modem Information:
   
        Modem Device:
       
          Modem:  (V.90)
          Driver:  (v1.2.3)
          Country:
          Modem In Use By: sshd, bash, system_profiler, lsof
       
\start
Date: Thu, 2 Nov 2006 23:03:43 -0500
From: Bill Page
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Humberto,

On November 2, 2006 10:36 PM you wrote:
> ... 
> I have a working gcl on the ppc,

Excellent! :-)

> what do I need to do to build build-improvements?
> 
> Just pull the source with:
> 
> svn co https://svn.sourceforge.net/svnroot/axiom/ \
>          branches/build-improvements axiom.build-improvements
>

Yes.
 
> and build with the out-of-tree gcl?

Yes. This should be automatic if gcl is accessible in your PATH.
but you can specify ./configure --with-gcl

> or do I have to splice the gcl into the axiom sources?

No, that is not necessary.

The only problem you *might* have is that to build Axiom you
also need the noweb literate programming tools. A version of
noweb is in the build-improvements distribution and should be
built automatically as the first step of the build if you do
not already have it installed and in your PATH. But I have
had some problems in the past getting this to work (maybe it
is fixed now?) and have had to resort to untarring the noweb
tarball from the axiom build-improvements /zip directory
and building and installing it manually before attempting
to build Axiom. If you do have noweb previously installed
then use --with-noweb.

The build-improvements branch supports "out-of-source" builds
which simplifies things considerably when repeating builds.
I usuall do something like this:

 $ mkdir axiom.test
 $ cd axiom.test
 $ ../axiom.build-improvements/configure --prefix=/home/page \
  --with-noweb --with-gcl

To build Axiom you will also need latex and X11.

You might also need the openpty patch provided earlier today
by Waldek Hebisch.

\start
Date: 03 Nov 2006 05:17:07 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

[...]

| The only problem you *might* have is that to build Axiom you
| also need the noweb literate programming tools. A version of
| noweb is in the build-improvements distribution and should be
| built automatically as the first step of the build if you do
| not already have it installed and in your PATH. But I have
| had some problems in the past getting this to work (maybe it
| is fixed now?) and have had to resort to untarring the noweb
| tarball from the axiom build-improvements /zip directory
| and building and installing it manually before attempting
| to build Axiom. If you do have noweb previously installed
| then use --with-noweb.

I believe that was a dependency thinko that was fixed by a patch from
Waldek. 

\start
Date: Thu, 2 Nov 2006 23:15:23 -0500
From: Tim Daly
To: Humberto Zuazaga
Subject: Re: Turtles all the way down.

> Axiom's a pretty complex system, and it seems to have picked up a bunch
> of other projects like clef, noweb, and gcl, and like all good lisp
> systems,  even recursive project dependencies like gcl has it's own bfd,
> and gmp.
> 
> There is still a set of external dependencies that have to be satisfied,
> like pdflatex, gcc, and others.
> 
> The recent clef/readline thread points out it may be advantageous to
> review the list of internal and external dependencies, and prune some cod=
> e.
> 
> What are people thinking about the builds of axiom? Debian tries to
> patch axiom to use system supplied tools and libraries where possible,
> the Mac OS X port tries to use local copies of everything.
> build-improvements stated goals are to automagically pick up any
> installed copies and build the rest internally.
> 
> I ask because I had to mangle ./configure to fix a test for
> malloc/malloc.h on Intel Mac. Neither of the autoconf programs installed
> on my Mac like the configure.in in gcl-2.6.8pre:
> 
> $ /sw/bin/autoconf --version
> autoconf (GNU Autoconf) 2.60
> 
> $ /usr/bin/autoconf --version
> autoconf (GNU Autoconf) 2.59
> 
> configure says it's been generated with autoconf 2.13.
> 
> I guess there's really no way to ship axiom with it's own autoconf if we
> have any expectation of using configure to build axiom, but how far down
> do we plan to go? I saw Gaby is seriously considering integrating gcl
> and gcc.

Well this is a long running controvery with opinions ranging from
rewriting Axiom completely in Aldor to the current bundle (which
except for noweb, gcl, and latex) are all part of the commercial 
version, to the more extreme case of fully bundling GCL and noweb.

Since opinion varies widely on this it will continue to be debated,
which is the point, really.

I'm working from a philosophy that borders on the pragmatic with a
focus on the long term (the 30 year horizon). We need to try to invent
the environment and the organization of computational mathematics that
will be considered "state of the art" in 30 years For example, we
might consider a system that allows direct manipulation of
n-dimensional varieties.  This would correspond to the underlying
mathematics similar in spirit to current solid models based on
mathematical relationships such as spline curves or finite meshes.

In the middle term we need to critique the current methods (e.g.
textual literate programming) and seek out new methods (e.g video and
interactive tools).  We need to build prototypes of these ideas.  We
also need to consider ideas like Doyen, Sage, Scientific Linux, and
Knoppix Math (a Japanese effort).

In the short term the idea is to choose tools which achieve certain
goals (e.g.  noweb for textual literate programming), modified as
necessary to fit new ideas. Some of these tools are packaged along with
the axiom distribution in the zips directory.  Everything in the
repository outside of zips (and some inside of zips) is part of the
commercial axiom build or later developments. GCL even has other
systems packaged within it.

These short term tools have been the source of controversy for
various reaons. Axiom is not yet ansi common lisp but aspires
to that goal, at which point it should run in any common lisp
rather than just GCL. However, GCL was historically developed
specifically for Axiom by Bill Schelter under contract to IBM.
I worked with Bill on various aspects of GCL, thus making it
rather easy as a first target port. In the long term the GCL
bundle should assume the status of "just another ansi common
lisp". Axiom used to run on about a dozen common lisps so it
is nearly ported except for ansi changes

Noweb was chosen as an initial literate programming tool and
axiom was completely rewritten to make every source file (almost)
into a trivial case of a literate file. There has been some
controvery over what the long term format of Axiom will be,
spread among things like ALLPROSE, straight latex, noweb, 
a lisp-based noweb, etc. All of these are "tactical" discussions
rather than long term "strategic" discussions. 

Part of the difficulty in our discussions is that we are often
arguing from different starting points. I tend to start from
the philosophy and work "top down" and insist that the ideas
should shape the tools, Some others tend to start with the tool 
and work "bottom up", insisting that the tools should shape the
ideas. The results lie somewhere in between. Running code tends
to determine the actual result.

\start
Date: Thu, 2 Nov 2006 23:16:43 -0500
From: Tim Daly
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill,

> My current proposal is that when Tim's merge of the old svn /trunk
> into svn /silver is accomplished, then svn /silver should become the
> new official "trunk" and the existing svn /trunk should be deleted.
> As I understand it, whether or not we eventually rename svn /silver
> to svn /trunk is probably only important to people who care more
> about standard svn terminology than either Tim Daly or me. ;)

I believe this process is complete.

\start
Date: Thu, 2 Nov 2006 23:27:49 -0500
From: Tim Daly
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> I would like to be able to explain the differences between Tim
> Daly's results above and this one. Could you both please provide
> detailed information about the computer hardware and operating
> system? What cpu? What version of OSX?

Machine Name: iBook G4
Machine Model: PowerBook6.5
CPU Type: PowerPC G4 (1.2)
Number Of CPUs: 1
CPU Speed: 1.2 GHz
L2 Cache (per CPU): 512 KB
Memory: 512 MB
Bus Speed: 133 MHz
Boot ROM Version: 4.8.7f1


Darwin dalys-Computer.local 8.4.0 Darwin Kernel Version 8.4.0:
Tue Jan 3 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC
Power Macintosh powerpc

\start
Date: 03 Nov 2006 06:02:29 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Turtles all the way down.

Tim Daly writes:

[...]

| Part of the difficulty in our discussions is that we are often
| arguing from different starting points. I tend to start from
| the philosophy and work "top down" and insist that the ideas
| should shape the tools, Some others tend to start with the tool 
| and work "bottom up", insisting that the tools should shape the
| ideas. The results lie somewhere in between. Running code tends
| to determine the actual result.

I think most of what you said is close to a good summary.  Except the
paragraphs on "bottom up", where I'm having difficulty to  see who are
proposing/insisting that the tools should shape the ideas, and how
that is different from your perspective.

\start
Date: Fri, 3 Nov 2006 11:27:56 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page wrote:
> Waldek,
> 
> Thank you! Your patch to openpty for MAC OSX worked perfectly.
> clef now compiles correctly. :-)
> 
> I think this change should go in.
> 

Bill, you did not write if clef works.

\start
Date: Fri, 3 Nov 2006 11:46:08 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> Bill,
> 
> > My current proposal is that when Tim's merge of the old svn /trunk
> > into svn /silver is accomplished, then svn /silver should become the
> > new official "trunk" and the existing svn /trunk should be deleted.
> > As I understand it, whether or not we eventually rename svn /silver
> > to svn /trunk is probably only important to people who care more
> > about standard svn terminology than either Tim Daly or me. ;)
> 
> I believe this process is complete.
> 

There are still two changes to /trunk which did not appear in SF
/silver:

1) removal of 'zips/tla-1.1.tar.gz'.  

2) 8 patches in /silver/zips contain '\r' but only 2 in '/trunk/zips'
   (AFAICS each '\r' in patches is an error)
  
\start
Date: Fri, 3 Nov 2006 12:23:15 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Gabriel Dos Reis wrote:
> This clarifiers the terminology for me.
> 

I do not think the problem is in terminology: each SF tag refer
to a unique branch.  Bill proposed to abandon /trunk and move
work to /silver. So the questions are:

1) Should any new patch be applied to /trunk ?

2) Should new patches be applied to /silver (AFAIU Bill proposed
   that)?  Tim routinely edits patches, so any patch applied to
   /silver is likely to conflict with Tim version picked from
   axiom--silver--1 (if both versions are identical, then the
   robot could easily identify a duplicate). 

\start
Date: Fri, 03 Nov 2006 09:36:30 -0400
From: Humberto Zuazaga
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page wrote:

>> what do I need to do to build build-improvements?
>>
>> Just pull the source with:
>>
>> svn co https://svn.sourceforge.net/svnroot/axiom/ \
>>          branches/build-improvements axiom.build-improvements
>>
>
> Yes.
>

Can't svn co the source, I've tried several times from a clean slate and
get:

$ svn co https://svn.sourceforge.net/svnroot/axiom/ \
          branches/build-improvements axiom.build-improvements

[normal output, then]

A
axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/HTXFormatPage5=
=2Eht
svn: In directory
'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages'
svn: Can't copy
'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/.svn/tmp/text=
-base/poly.pht.svn-base'
to
'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/poly.pht.tmp'=
:
No such file or directory

after that, svn co fails because of a lock in the working directory:

$ svn co https://svn.sourceforge.net/svnroot/axiom/
branches/build-improvements axiom.build-improvements
svn: Working copy
'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for detai=
ls)

and svn cleanup barfs:

$ svn cleanup axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages
svn: In directory
'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages'
svn: Can't copy
'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/.svn/tmp/text=
-base/exlap.ht.svn-base'
to
'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/exlap.ht.2.tm=
p':
No such file or directory

\start
Date: Fri, 3 Nov 2006 08:48:17 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> 1) removal of 'zips/tla-1.1.tar.gz'.  

my version says it's been removed.
i tried to remove it again and get the message

tla delete tla-1.1.tar.gz
attempt to remove non-existent id for tla-1.1.tar.gz

\start
Date: Fri, 3 Nov 2006 14:59:50 +0100 (CET)
From: Waldek Hebisch
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Humberto Ortiz-Zuazaga wrote::
> Can't svn co the source, I've tried several times from a clean slate and
> get:
> 
> $ svn co https://svn.sourceforge.net/svnroot/axiom/ \
>           branches/build-improvements axiom.build-improvements
> 
> [normal output, then]
> 
> A
> axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/HTXFormatPage5.ht
> svn: In directory
> 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages'
> svn: Can't copy
> 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/.svn/tmp/text-base/poly.pht.svn-base'
> to
> 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/poly.pht.tmp':
> No such file or directory
> 

I think this problem was reported here: it is only possible to
checkout Axiom on a case-sensitive filesytem -- so on Windows and
traditional Mac filesystem checkout fails.  This is due to files
which have names differing only in case: poly.ht contra POLY.ht
and poly.pht contra POLY.pht.  

In principle checkout should work if you use Unix filesystem on
yout Mac (but I have no idea what trick Mac OS X or svn can play
with Unix filesystem).

We should probably rename one of offending files, maybe have
'polys.ht' insted of 'poly.ht'?

In the meantime I can provide a tarball with recent checkout
if you wish.

\start
Date: 03 Nov 2006 15:13:18 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Humberto Zuazaga writes:

| Bill Page wrote:
| 
| >> what do I need to do to build build-improvements?
| >>
| >> Just pull the source with:
| >>
| >> svn co https://svn.sourceforge.net/svnroot/axiom/ \
| >>          branches/build-improvements axiom.build-improvements
| >>
| > 
| > Yes.
| > 
| 
| Can't svn co the source, I've tried several times from a clean slate and
| get:
| 
| $ svn co https://svn.sourceforge.net/svnroot/axiom/ \
|           branches/build-improvements axiom.build-improvements
| 
| [normal output, then]
| 
| A
| axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/HTXFormatPage5.ht
| svn: In directory
| 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages'
| svn: Can't copy
| 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/.svn/tmp/text-base/poly.pht.svn-base'
| to
| 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/poly.pht.tmp':
| No such file or directory

The problem, as discussed recently, is that it is a typical problem
with "case preserving, case insensitive" filesystems (e.g. windows,
macos, etc.) because there is two files POLY.pht and poly.pht.  
I seem to remember that Waldek proposed to remove one of them.

\start
Date: Fri, 3 Nov 2006 15:22:20 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Gabriel Dos Reis wrote:
> Humberto Zuazaga writes:
> | svn: In directory
> | 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages'
> | svn: Can't copy
> | 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/.svn/tmp/text-base/poly.pht.svn-base'
> | to
> | 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/poly.pht.tmp':
> | No such file or directory
> 
> The problem, as discussed recently, is that it is a typical problem
> with "case preserving, case insensitive" filesystems (e.g. windows,
> macos, etc.) because there is two files POLY.pht and poly.pht.  
> I seem to remember that Waldek proposed to remove one of them.
> 

Not yet.  In a message that I sent few minutes ago I proposed to
rename 'poly.ht' to 'polys.ht' and 'poly.pht' to 'polys.pht'.

\start
Date: 03 Nov 2006 15:21:07 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

| Tim,
| 
| On November 3, 2006 8:48 AM Tim Daly wrote:
| > Waldek Hebisch wrote: 
| > 
| > > 1) removal of 'zips/tla-1.1.tar.gz'.  
| > 
| > my version says it's been removed.
| > i tried to remove it again and get the message
| > 
| > tla delete tla-1.1.tar.gz
| > attempt to remove non-existent id for tla-1.1.tar.gz
| > 
| 
| I am still learning about the Tailor synchronization "robot".
| It is possible that it does not copy file deletion requests.

the .arch-ids subdirectories should also disappear from silver

\start
Date: Fri, 3 Nov 2006 09:15:36 -0500
From: Tim Daly
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> How about the \r problem?

still looking into it.

\start
Date: 03 Nov 2006 15:25:27 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Tim Daly writes:

| > 1) removal of 'zips/tla-1.1.tar.gz'.  
| 
| my version says it's been removed.

done on silver.

\start
Date: 03 Nov 2006 15:28:20 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

[...]

| > axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/HTX
| > FormatPage5.ht
| > svn: In directory
| > 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages'
| > svn: Can't copy
| > 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/.s
| > vn/tmp/text-base/poly.pht.svn-base'
| > to
| > 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/po
| > ly.pht.tmp':
| > No such file or directory
| > 
| > after that, svn co fails because of a lock in the working directory:
| >
| 
| Welcome to SVN on SourceForge ... ;)

This particular issue has nothing to do with SVN on SF.  
It is a brain-damaged filesystem issue.  Ben from Google explained the
problem a couple of days ago.

\start
Date: Fri, 03 Nov 2006 10:40:55 -0400
From: Humberto Zuazaga
To: list
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page wrote:
>
> Welcome to SVN on SourceForge ... ;)

No, that's what I get for trying to develop on Mac OS X, a.k.a, the
bastard son of FreeBSD and Mac OS. Case preserving case insensitive
indeed. It's almost, but not quite, like developing on a real operating
system.

I'm trying a darcs get
http://page.axiom-developer.org/repository/axiom-darcs/ now, and if that
fails, I'll just pull the sources on a linux box and rsync them over to
the mac.

\start
Date: Fri, 03 Nov 2006 15:45:46 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On 11/03/2006 12:23 PM, Waldek Hebisch wrote:
> Gabriel Dos Reis wrote:
>> This clarifiers the terminology for me.

Not for me.

Bill seemed to conflict himself when he said that
a)

 > In any case, please keep in mind that we had previously agreed that
 > all patches to silver would be sent by email to Tim Daly and that
 > he would be responsible for review and applying these changes to
 > axiom--silver--1. That is the route by which patches are supposed
 > to the new svn /silver "trunk".

and

b)
 > SVN /trunk was created to be Silver from which the
 > experimental branches would be branched.
 >
 > > > axiom--silver--1 was created to be a pre-gold version of
 > > > the system with "early release" of changes so they can be
 > > > tested.
 >
 > No. axiom--silver--1 was created to be a mirror of SVN /trunk
 > (now called SVN /silver) so that you would not have to deal
 > with the problems of using SVN.


And I have written something on
http://wiki.axiom-developer.org/AxiomSources
which is certainly not up-to-date. Unfortunately I am to confused by 
what is master-silver and what are the copies so that I cannot update 
this page.

Please, please, don't let the AxiomSources page get out-of-date. With 
all this SCM mess nobody is going to understand where to start with.

> 1) Should any new patch be applied to /trunk ?

If we all agreed to send patches to Tim for review, then I would say no.
Silver should always be the same on axiom--silver--1, SF-/silver 
Google/trunk (or is it also Google/silver?).

\start
Date: Fri, 3 Nov 2006 09:45:08 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/HTX
> FormatPage5.ht
> svn: In directory
> 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages'
> svn: Can't copy
> 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/.s
> vn/tmp/text-base/poly.pht.svn-base'
> to
> 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/po
> ly.pht.tmp':
> No such file or directory
> 
> after that, svn co fails because of a lock in the working directory:
>

i fought the same issue on the Magnus project (another open source
project i'm leading). i never managed to unlock the directory. the
only method i found was to destroy the local directory, submit
delete changes to fix the host, and restart the process from 
scratch. svn cleanup does nothing (or at least it doesn't clean up).
the whole dance cost me 8 hours. 

\start
Date: 03 Nov 2006 16:09:00 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

| On November 3, 2006 9:13 AM Gaby wrote:
| > | 
| > | Can't svn co the source, I've tried several times from a 
| > clean slate and
| > | get:
| > | 
| > | $ svn co https://svn.sourceforge.net/svnroot/axiom/ \
| > |           branches/build-improvements axiom.build-improvements
| > | 
| > | [normal output, then]
| > | 
| > | A
| > | 
| > axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/HTX
| > FormatPage5.ht
| > | svn: In directory
| > | 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages'
| > | svn: Can't copy
| > | 
| > 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/.s
| > vn/tmp/text-base/poly.pht.svn-base'
| > | to
| > | 
| > 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/po
| > ly.pht.tmp':
| > | No such file or directory
| > 
| > The problem, as discussed recently, is that it is a typical problem
| > with "case preserving, case insensitive" filesystems (e.g. windows,
| > macos, etc.) because there is two files POLY.pht and poly.pht.  
| > I seem to remember that Waldek proposed to remove one of them.
| > 
| 
| This misbehaviour of SVN - particularly the obscure mode of
| failure and the subsequent inability to correct the corrupted
| respository - seems like a serious problem in SVN. Does anyone
| know if it has been previously reported to the SVN developers?

Like I said Ben from Google was the one who explained the
filesystem issue.

I don't think it is an SVN issue.  GCC ran into similar issue (not the
rpo, the compiler) very recently.

Bill, forget about SVN for a moment.  How to you plan to keep POLY.pht
and poly.pht as separate files in the same directory using a case
preserving and case insensitive filesystem?  

\start
Date: 03 Nov 2006 16:49:22 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Ralf Hemmecke writes:

| On 11/03/2006 12:23 PM, Waldek Hebisch wrote:
| > Gabriel Dos Reis wrote:
| >> This clarifiers the terminology for me.
| 
| Not for me.
| 
| Bill seemed to conflict himself when he said that
| a)
| 
|  > In any case, please keep in mind that we had previously agreed that
|  > all patches to silver would be sent by email to Tim Daly and that
|  > he would be responsible for review and applying these changes to
|  > axiom--silver--1. That is the route by which patches are supposed
|  > to the new svn /silver "trunk".
| 
| and
| 
| b)
|  > SVN /trunk was created to be Silver from which the
|  > experimental branches would be branched.
|  >
|  > > > axiom--silver--1 was created to be a pre-gold version of
|  > > > the system with "early release" of changes so they can be
|  > > > tested.
|  >
|  > No. axiom--silver--1 was created to be a mirror of SVN /trunk
|  > (now called SVN /silver) so that you would not have to deal
|  > with the problems of using SVN.
| 
| 
| And I have written something on
| http://wiki.axiom-developer.org/AxiomSources
| which is certainly not up-to-date. Unfortunately I am to confused by
| what is master-silver and what are the copies so that I cannot update
| this page.
| 
| Please, please, don't let the AxiomSources page get out-of-date. With
| all this SCM mess nobody is going to understand where to start with.
| 
| > 1) Should any new patch be applied to /trunk ?
| 
| If we all agreed to send patches to Tim for review, then I would say no.
| Silver should always be the same on axiom--silver--1, SF-/silver
| Google/trunk (or is it also Google/silver?).

Thanks Ralf.

Clearly I, too, am confused about this whole replictor business.

If we can manage to be confused about which is which at this point, then
clearly something is wrong.  A week ago, I received private
communications about decreasing the number of "master" repos --
because it just is too confusing.  I suspect this is another strong
evidence to support the claim.

Now, I'm really confused about what we said we will do (and we are not 
doing), what are doing (and we should not be doing), and what we
should be doing (and are not doing).

As I have stated publically, I'm not a big fan of "forks".
But at this very point I'm considering very seriously about forking
and be done with it.

\start
Date: 03 Nov 2006 16:51:19 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Humberto Zuazaga writes:
| > | svn: In directory
| > | 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages'
| > | svn: Can't copy
| > | 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/.svn/tmp/text-base/poly.pht.svn-base'
| > | to
| > | 'axiom.build-improvements/axiom/trunk/axiom/src/hyper/pages/poly.pht.tmp':
| > | No such file or directory
| > 
| > The problem, as discussed recently, is that it is a typical problem
| > with "case preserving, case insensitive" filesystems (e.g. windows,
| > macos, etc.) because there is two files POLY.pht and poly.pht.  
| > I seem to remember that Waldek proposed to remove one of them.
| > 
| 
| Not yet.  In a message that I sent few minutes ago I proposed to
| rename 'poly.ht' to 'polys.ht' and 'poly.pht' to 'polys.pht'.

Please go ahead and commit to build-improvements.  Add an explanation
(in the pamphlets) about the renaming.

\start
Date: 03 Nov 2006 16:55:21 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

[...]

| Granted that case-preserving case-insensitive is a stupid idea
| that makes some types of programming more difficult, but none
| of the other source code control systems that I use on Windows
| fail catastrophically and irrevocably lock the entire source
| tree just because they have trouble dealing with this case. :-(

they just corrupt the source tree :-)

\start
Date: Fri, 3 Nov 2006 20:15:39 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
>
> | Not yet.  In a message that I sent few minutes ago I proposed to
> | rename 'poly.ht' to 'polys.ht' and 'poly.pht' to 'polys.pht'.
> 
> Please go ahead and commit to build-improvements.  Add an explanation
> (in the pamphlets) about the renaming.

Commited.  But after extra checking I see more problem.  Namely
in 'src/hyper/bitmaps' we have the following pairs:

xi.bitmap Xi.bitmap
upsilon.bitmap Upsilon.bitmap
theta.bitmap Theta.bitmap
sigma.bitmap Sigma.bitmap
psi.bitmap Psi.bitmap
pi.bitmap Pi.bitmap
phi.bitmap Phi.bitmap
omega.bitmap Omega.bitmap
lambda.bitmap Lambda.bitmap
gamma.bitmap Gamma.bitmap
delta.bitmap Delta.bitmap

aTx=b.bitmap ATX=B.bitmap

The first group consists of images of greek letters, version with
lowercase name is lowercase letter, while uppercase letter has
the first letter of filename in upper case.

Also in 'src/doc/ps' we have 'SEGBIND.ps' and 'segbind.ps'.  'segbind.ps'
is a screen dump of a graphic window containig a parabola.  I can not
really see 'SEGBIND.ps' because it triggers Postscript stack error
in ghostscript (like many other files in 'src/doc/ps' :(.

\start
Date: Fri, 03 Nov 2006 15:22:54 -0400
From: Humberto Zuazaga
To: list
Subject: Mac OS X 10.4.8 PowerPC success!

I built the build-improvements branch with the GCL I made last night, 
and it looks like it works:

Sorry about the formatting, I think the Mac Terminal is mangling the lines.

(1) -> )set mes auto on
(1) -> 1
(1)  1                                                        Type: 
PositiveInteger
(2) -> 1+1
(2)  2                                                        Type: 
PositiveInteger

Here's the build process:

darcs get http://page.axiom-developer.org/repository/axiom-darcs/

  535  chmod +x configure
  536  ./configure --prefix=/usr/local --with-gcl
  552  chmod +x config/mkinstalldirs
  553  make
  568  ls target/powerpc-apple-darwin8.8.0/bin/AXIOMsys
  569  export 
AXIOM=/Users/humberto/src/axiom-darcs/target/powerpc-apple-darwin8.8.0
  570  PATH=$PATH:$AXIOM/bin
  571  AXIOMsys

Success!

darcs or the Mac mangled the permissions on configure and 
config/mkinstalldirs, the rest went smoothly.

\start
Date: 03 Nov 2006 17:34:22 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

[...]

| > Thanks Ralf.
| > 
| > Clearly I, too, am confused about this whole replictor
| > business.
| > 
| > If we can manage to be confused about which is which at
| > this point, then clearly something is wrong.
| 
| Surely you are imagining confusion where this is nothing
| but the usual complications... ;)

I have managed to think I knew what the state was, then get told it
wasn't, then get told what I was told wasn't wasn't.  That happened
for real; it is not imaginary.

| > A week ago, I received private communications about
| > decreasing the number of "master" repos -- because it
| > just is too confusing.  I suspect this is another strong
| > evidence to support the claim.
| 
| As far as I am concerned, private communications on this
| issue don't exist. Why private?

Different people act differently.  Some prefer courteous private
communication, others prefer public vocalization.  I have no trouble
with that.

| > Now, I'm really confused about what we said we will do
| > (and we are not doing), what are doing (and we should
| > not be doing), and what we should be doing (and are not
| > doing).
| 
| I hope this email helps solve your problem. Really this
| is not so complicated.
| 
| > 
| > As I have stated publicly, I'm not a big fan of "forks".
| > But at this very point I'm considering very seriously
| > about forking and be done with it.
| > 
| 
| If you have an issue about the decision to let Tim Daly manage
| the update of Axiom Silver via his manual updates of his tla
| axiom--silver--1 archive (with auto sync to svn /silver),
| then I think that should be treated separately from the issue
| of the configuration of the source code archives.

I'm very happy to see Tim is making changes more visible now, than waiting
for ages before seeing light. The main reason I originally volunteered to
maintain Silver is that I do believe in "live sources". Tim suggested
at the time that he did not have time do maintain too many branches.
It therefore was a natural thing for me to volunteer to take on the
job.  Now, if Tim has more time to do the job, I'm all for it.

However, I see practical issue here:  

  (1) first, we should not have one single person as authority to
      commit changes.  Every contributor we grant write access should
      commit its own changes to silver/trunk/whatever it is
      called.  That way, we don't have to wait that only a single
      person has time and do the job.

  (2) second, he review should be public, instead of being done in
      private.  This helps people to learn possible obscure cases of
      the system -- instead of the only-one-who-knows has a
      conversation with himself and commit. 
      The changes should be sent to the list instead of Tim.

  (3) third, I'm having diffculty in following the reasoning that,
      most people would develop patches against the SVN repo,
      they will see their patches applied by someone else to a repo
      under a different SCM, and wait a day and then copied back, to
      the SVN repo just to see their changes.  That does not strike me
      as efficient.
      I consider that an extraodinary waste of time and resources.

\start
Date: 03 Nov 2006 20:24:10 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Waldek Hebisch writes:
| >
| > | Not yet.  In a message that I sent few minutes ago I proposed to
| > | rename 'poly.ht' to 'polys.ht' and 'poly.pht' to 'polys.pht'.
| > 
| > Please go ahead and commit to build-improvements.  Add an explanation
| > (in the pamphlets) about the renaming.
| 
| Commited.  But after extra checking I see more problem.  Namely
| in 'src/hyper/bitmaps' we have the following pairs:
| 
| xi.bitmap Xi.bitmap
| upsilon.bitmap Upsilon.bitmap
| theta.bitmap Theta.bitmap
| sigma.bitmap Sigma.bitmap
| psi.bitmap Psi.bitmap
| pi.bitmap Pi.bitmap
| phi.bitmap Phi.bitmap
| omega.bitmap Omega.bitmap
| lambda.bitmap Lambda.bitmap
| gamma.bitmap Gamma.bitmap
| delta.bitmap Delta.bitmap
| 
| aTx=b.bitmap ATX=B.bitmap

OK, we need a general systematic naming scheme to handle that.
I'll come back to you later.

Thanks for the detective work.

\start
Date: Fri, 3 Nov 2006 21:10:59 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: sock_get_string_buf
Cc: Camm Maguire

Gabriel Dos Reis wrote: 
> I would like to see the final patch, e.g. the things that would be
> committed, including the explanation of what the code and what is
> going in the pamphletss.
> 

diff -ru build-improvements.bb/src/interp/ChangeLog.build-improvements build-improvements/src/interp/ChangeLog.build-improvements
--- build-improvements.bb/src/interp/ChangeLog.build-improvements	2006-11-03 18:07:12.000000000 +0100
+++ build-improvements/src/interp/ChangeLog.build-improvements	2006-11-03 21:00:59.000000000 +0100
@@ -1,3 +1,9 @@
+2006-11-03  Waldek Hebisch  Waldek Hebisch
+
+	* sockio.lisp.pamphlet (sock_get_string_buf_wrapper): new
+	function
+	(sock_get_string_buf): call it
+
 2006-10-31  Gabriel Dos Reis  Gabriel Dos Reis
 
 	* Makefile.pamphlet: Make extracted Boot .PRECIOUS.
diff -ru build-improvements.bb/src/interp/sockio.lisp.pamphlet build-improvements/src/interp/sockio.lisp.pamphlet
--- build-improvements.bb/src/interp/sockio.lisp.pamphlet	2006-11-03 18:07:12.000000000 +0100
+++ build-improvements/src/interp/sockio.lisp.pamphlet	2006-11-03 18:27:31.000000000 +0100
@@ -73,10 +73,20 @@
 (progn
   (clines "extern double plus_infinity(), minus_infinity(), NANQ();")
   (clines "extern double sock_get_float();")
+;; GCL may pass strings by value.  'sock_get_string_buf' should fill
+;; string with data read from connection, therefore needs address of
+;; actual string buffer. We use 'sock_get_string_buf_wrapper' to
+;; resolve the problem
+  (clines "int sock_get_string_buf_wrapper(int i, object x, int j)"
+          "{ if (type_of(x)!=t_string) FEwrong_type_argument(sLstring,x);"
+          "  if (x->st.st_fillp<j)"
+          "    FEerror(\"string too small in sock_get_string_buf_wrapper\",0);"
+          "  return sock_get_string_buf(i, x->st.st_self, j); }")
   (defentry open_server (string) (int "open_server"))
   (defentry sock_get_int (int) (int "sock_get_int"))
   (defentry sock_send_int (int int) (int "sock_send_int"))
-  (defentry sock_get_string_buf (int string int) (int "sock_get_string_buf"))
+  (defentry sock_get_string_buf (int object int) 
+     (int "sock_get_string_buf_wrapper"))
   (defentry sock_send_string_len (int string int) (int "sock_send_string_len"))
   (defentry sock_get_float (int) (double "sock_get_float"))
   (defentry sock_send_float (int double) (int "sock_send_float"))

\start
Date: 03 Nov 2006 21:22:24 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: sock_get_string_buf
Cc: Camm Maguire

Waldek Hebisch writes:

| +2006-11-03  Waldek Hebisch  Waldek Hebisch
| +
| +	* sockio.lisp.pamphlet (sock_get_string_buf_wrapper): new
| +	function
| +	(sock_get_string_buf): call it

OK for build-improvements. 

\start
Date: Fri, 03 Nov 2006 21:39:59 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On 11/03/2006 05:22 PM, Bill Page wrote:
> On November 3, 2006 10:49 AM Gabriel Dos Reis wrote:
>> Ralf Hemmecke writes:
>>
>> | On 11/03/2006 12:23 PM, Waldek Hebisch wrote:
>> | > Gabriel Dos Reis wrote:
>> | >> This clarifiers the terminology for me.
>> | 
>> | Not for me.
>> | 
>> | Bill seemed to conflict himself when he said that
>> | a)
>> | 
>> |  > In any case, please keep in mind that we had previously 
>> |  > agreed that all patches to silver would be sent by email
>> |  > to Tim Daly and that he would be responsible for review
>> |  > and applying these changes to axiom--silver--1. That is
>> |  > the route by which patches are supposed to the new
>> |  > svn /silver "trunk".
>> | 
>> | and
>> | 
>> | b)
>> |  > SVN /trunk was created to be Silver from which the
>> |  > experimental branches would be branched.
>> |  >
>> |  > > > axiom--silver--1 was created to be a pre-gold version of
>> |  > > > the system with "early release" of changes so they can be
>> |  > > > tested.
>> |  >
>> |  > No. axiom--silver--1 was created to be a mirror of SVN /trunk
>> |  > (now called SVN /silver) so that you would not have to deal
>> |  > with the problems of using SVN.
>> |
> 
> What is the conflict?

The conflict is that the master-silver is axiom--silver--1 in a) and 
SF/trunk in b). At least that is my understanding of that words. But I 
am not a native speaker, so forgive me if I am wrong.

>> | 
>> | > 1) Should any new patch be applied to /trunk ?
>> |
> 
> Obviously no since Tim is actively involved in trying to
> update his axiom--silver--1 so that it includes all changes
> in /trunk and then there after all new changes would be
> done by him.

OK. Then you also say that axiom--silver--1 is the master.

> Come on guys, what are you confused about??? :-(

Thank you, Bill. I appreciate all your work. I was just a bit puzzled.

> So svn /silver is the new Axiom Silver master on SourceForge.

... and should be condidered as read-only except for Bill's Tailor-program.

\start
Date: Fri, 03 Nov 2006 22:03:40 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> I'm very happy to see Tim is making changes more visible now, than waiting
> for ages before seeing light. The main reason I originally volunteered to
> maintain Silver is that I do believe in "live sources". Tim suggested
> at the time that he did not have time do maintain too many branches.
> It therefore was a natural thing for me to volunteer to take on the
> job.  Now, if Tim has more time to do the job, I'm all for it.

> However, I see practical issue here:  
> 
>   (1) first, we should not have one single person as authority to
>       commit changes.

We are speaking here _only_ of the changes that go to the next Gold 
release.

>       Every contributor we grant write access should
>       commit its own changes to silver/trunk/whatever it is
>       called.  That way, we don't have to wait that only a single
>       person has time and do the job.

Why not first develop on a branch as you do and then (if public review 
was long enough and (most) axiom developers agree that it should go to 
the next gold release) have Tim do the actual merge to silver?

I am so happy that Tim opened his pre-gold to the public so that we can 
see what is going to be gold.

>   (2) second, he review should be public, instead of being done in
>       private.

But now we _do_ it in public. You are watched by many people on 
build-improvements.

>       This helps people to learn possible obscure cases of
>       the system -- instead of the only-one-who-knows has a
>       conversation with himself and commit. 
>       The changes should be sent to the list instead of Tim.

Of course, to the list.

>   (3) third, I'm having diffculty in following the reasoning that,
>       most people would develop patches against the SVN repo,
>       they will see their patches applied by someone else to a repo
>       under a different SCM, and wait a day and then copied back, to
>       the SVN repo just to see their changes.  That does not strike me
>       as efficient.
>       I consider that an extraodinary waste of time and resources.

I somehow must admit that this is probably a good point. But nobody 
forbids to commit anything on sorceforge except to the /silver directory.

I must say, it was a quite wise idea of Bill to create /silver as an 
exact copy of axiom--silver--1. View it as the opportunity to see 
(read-only) Tim's commits in SVN format.

In fact, there is no problem if /trunk is kept as a central place that 
is under Gaby's responsibility. And although I would find it sad, but if 
/trunk and /silver do not become one in the near future, there is no 
problem as long as it is clearly described which directory contains what.

I share your efficiency considerations, though. But up to now, it wasn't 
a big problem.

\start
Date: Fri, 3 Nov 2006 22:07:29 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: viewport in build-improvements

root wrote:
> > > Sure many files *look* like text files, but you have heard Tim saying that
> > > 
> > > 1) a SCM should never change the line ending format
> > 
> > Tell that to Windows folks.
> 
> Consider the domain and range of an SCM. It should map files to files
> as an identity operation with a side-effect of maintaining history.
> An SCM only needs to know that bytes are bytes. Maintaining history
> as diff-format files is an optimization, not a requirement.
> 

I think you miss the point here: you treat SCM like a backup device.
With such an attitude CVS should work fine for you... For me an
essential feature of SCM is ability to concisly and adeqatly summarize
differnces (managing changesets). Also, SCM is really a convenience
device for developers (note that in principle one can just just
a bunch of shell scripts as an SCM). In particular, checkout
should give "ready to build" sources. Now, in many cases
files containing '\r' will not work on Unix, OTOH without '\r'
the same files will not work on Windows.


> Changing \n-files to \r\n-files is the responsibility of some other tool.
> If the translation occurs at all it should live in the client end since
> that is the part that knows about the user environment.
> 

In general, I do not like automatic convertions of line endings. But
IMHO SCM are an exception: usually there is clear separation
between binaries and text files, and since SCM stores metadata,
it can also store information about text/binary properties.
External tool would be forced to guess (and likely to be wrong).
I agree that that conversion should be done in client part of SCM.

> Although I chose arch and it "does the right thing" I have to say
> that GIT seems to have the SCM philosophy most clearly implemented.
> 

I looked quickly at GIT, and I do not think it will be succeful
as-is.  It may "mature" and get extra functions present in other
SCM-s or alternatively some other "higher level SCM" may use
GIT as a backend. ATM the main strong point of GIT is its
packing algoritm, but alone that is too little to win.

\start
Date: 03 Nov 2006 22:22:30 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Ralf Hemmecke writes:

| > I'm very happy to see Tim is making changes more visible now, than waiting
| > for ages before seeing light. The main reason I originally volunteered to
| > maintain Silver is that I do believe in "live sources". Tim suggested
| > at the time that he did not have time do maintain too many branches.
| > It therefore was a natural thing for me to volunteer to take on the
| > job.  Now, if Tim has more time to do the job, I'm all for it.
| 
| > However, I see practical issue here:    (1) first, we should not
| > have one single person as authority to
| >       commit changes.
| 
| We are speaking here _only_ of the changes that go to the next Gold
| release.

we are talking of Silver, right?

| 
| >       Every contributor we grant write access should
| >       commit its own changes to silver/trunk/whatever it is
| >       called.  That way, we don't have to wait that only a single
| >       person has time and do the job.
| 
| Why not first develop on a branch as you do and then (if public review
| was long enough and (most) axiom developers agree that it should go to
| the next gold release) have Tim do the actual merge to silver?

you end up with N people having N branches, when in fact they want 1
common "true" live source to branch off.

But, I'm not going to insist since the idea of a common source
code that people can develop from and check-in lively is alien here.  
I have enough on the plate.  I'll finish build-improvements.  People
take what they want and I'll probably fork.

What I've seen with build-improvements is that people try it and find
problem, they propose fixes and if the fixes are correct they check
them in and everybody has it immediately.  The only time they have to
wait for me, is for review.  But if we have more "authorized" reviewers,
they would not have to wait for one single person.

| I am so happy that Tim opened his pre-gold to the public so that we
| can see what is going to be gold.

I think everything is happy about that; and there is no discussion.

[...]

| I must say, it was a quite wise idea of Bill to create /silver as an
| exact copy of axiom--silver--1. View it as the opportunity to see
| (read-only) Tim's commits in SVN format.
| 
| In fact, there is no problem if /trunk is kept as a central place that
| is under Gaby's responsibility.

There is a problem.  If Tim develops his stuff on one hand, and /trunk
develops its own way,  we have a mess.  If I'm the only one in charge
of trunk, we have a problem as I said above (only one person as
central authority is a serious failure mode point).

| And although I would find it sad, but
| if /trunk and /silver do not become one in the near future, there is
| no problem as long as it is clearly described which directory contains
| what.

In a sense, we would have a fork  but not calling it that way.  Why not do
the real thing and be clear it?

| I share your efficiency considerations, though. But up to now, it
| wasn't a big problem.

I'm expecting to see more "Waldek"s coming in.  If there must be only
one Axiom source, then I would like to see their fixes go in as
quickly as possible (after clear review, that is).  And I would like
to see those changes spread as quickly as possible.  Also, you should
get in the habit of crediting developers responsabilities -- they should
commit themselves.  There are lots of things you learn that way :-)

\start
Date: Fri, 03 Nov 2006 23:13:27 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: RE: hypertex and uses info

Waldek,

> All versions of hypertex that I used crashed (or maybe showed 
> nothing) 
> when I clicked "Uses" or "Dependants" field in a description of a constructor.

> AFAICS recent versions of Axiom have two problems here:

> 1) databases which contain corresponding information (USERS.DAASE
>    and DEPENDENTS.DAASE) were not installed
> 2) infamous 'probe-file' problem

> The patch below correct both problems. It also fixes the
> "Cannot rename the file erlib to NRLIB" problem. I also added
> sensible dependency in database rule, so that all databses
> are re-made when one get out of date. And 'RDEFIOSTREAM' is
> now called in error-checking mode (old code happily passed
> bad pathnames and supressed error checking).

I'm in the process of applying these patches. Do you know a situation where
readLibPathFast is used on a non existent file ? Since you prefer to remove
some assumptions, I want to know :-)

And again, thanks a lot,

Greg

PS : It was suggested to change the behavior of directoryp, I understand that
but I have seen code that relies on its actual behavior (for example in RDEFIOSTREAM).
I have seen too what can be considered duplicate code (directory?).


===============================================================================
diff -ru build-improvements.pp/src/etc/Makefile.in 
build-improvements/src/etc/Makefile.in
--- build-improvements.pp/src/etc/Makefile.in   2006-11-01 19:33:11.000000000 
+0100
+++ build-improvements/src/etc/Makefile.in      2006-11-01 19:36:00.000000000 
+0100
@@ -2,6 +2,10 @@
 MID=${OBJ}/${SYS}/etc
 DOC=${INT}/doc/src/etc
 INTERPSYS=$(axiom_build_bindir)/interpsys
+DATABASES_SHORT=compress.daase interp.daase browse.daase category.daase \
+                operation.daase libdb.text comdb.text USERS.DAASE/index.KAF \
+                DEPENDENTS.DAASE/index.KAF
+DATABASES=$(addprefix $(axiom_targetdir)/algebra/, $(DATABASES_SHORT))
 
 subdir = src/etc/
 
@@ -10,7 +14,7 @@
 
 all: all-ax
 
-all-ax: $(axiom_targetdir)/algebra/*.daase $(axiom_target_bindir)/asq \
+all-ax: $(DATABASES) $(axiom_target_bindir)/asq \
                $(axiom_target_libdir)/summary \
                $(axiom_target_libdir)/copyright \
                $(axiom_target_bindir)/axiom
@@ -18,8 +22,8 @@
        -rm -f stamp
        $(STAMP) stamp
 
-$(axiom_targetdir)/algebra/*.daase: ${INT}/algebra/*.NRLIB/code.o
-       @ echo 4 rebuilding databases...
+$(DATABASES): ${INT}/algebra/*.NRLIB/code.o
+       @ echo 4 rebuilding databases ...
        @ cp $(axiom_src_docdir)/gloss.text ${INT}/algebra
        @ cp $(axiom_src_docdir)/gloss.text ${INT}/algebra
        @ cp $(axiom_src_docdir)/topics.data ${INT}/algebra
@@ -29,6 +33,12 @@
        @ $(INSTALL_DATA) ${INT}/algebra/*.daase $(axiom_targetdir)/algebra
        @ $(INSTALL_DATA) ${INT}/algebra/libdb.text $(axiom_targetdir)/algebra
        @ $(INSTALL_DATA) ${INT}/algebra/comdb.text $(axiom_targetdir)/algebra
+       @ $(mkinstalldirs) $(axiom_targetdir)/algebra/USERS.DAASE \
+             $(axiom_targetdir)/algebra/DEPENDENTS.DAASE
+       @ $(INSTALL_DATA) ${INT}/algebra/USERS.DAASE/index.KAF \
+                   $(axiom_targetdir)/algebra/USERS.DAASE
+       @ $(INSTALL_DATA) ${INT}/algebra/DEPENDENTS.DAASE/index.KAF \
+                   $(axiom_targetdir)/algebra/DEPENDENTS.DAASE
 
 asq_sources = asq.c
 asq_SOURCES = $(addsuffix .pamphlet, $(asq_sources))
Tylko w build-improvements/src/etc: Makefile.in.orig
diff -ru build-improvements.pp/src/etc/Makefile.pamphlet 
build-improvements/src/etc/Makefile.pamphlet
--- build-improvements.pp/src/etc/Makefile.pamphlet     2006-11-01 
19:33:11.000000000 +0100
+++ build-improvements/src/etc/Makefile.pamphlet        2006-11-01 
19:36:00.000000000 +0100
@@ -26,8 +26,8 @@
 the databases. If any if any of these are changed, the databases must
 be re-built.
 <<dbcomplete>>=
-$(axiom_targetdir)/algebra/*.daase: ${INT}/algebra/*.NRLIB/code.o
-       @ echo 4 rebuilding databases...
+$(DATABASES): ${INT}/algebra/*.NRLIB/code.o
+       @ echo 4 rebuilding databases ...
        @ cp $(axiom_src_docdir)/gloss.text ${INT}/algebra
        @ cp $(axiom_src_docdir)/gloss.text ${INT}/algebra
        @ cp $(axiom_src_docdir)/topics.data ${INT}/algebra
@@ -37,6 +37,12 @@
        @ $(INSTALL_DATA) ${INT}/algebra/*.daase $(axiom_targetdir)/algebra
        @ $(INSTALL_DATA) ${INT}/algebra/libdb.text $(axiom_targetdir)/algebra
        @ $(INSTALL_DATA) ${INT}/algebra/comdb.text $(axiom_targetdir)/algebra
+       @ $(mkinstalldirs) $(axiom_targetdir)/algebra/USERS.DAASE \
+             $(axiom_targetdir)/algebra/DEPENDENTS.DAASE
+       @ $(INSTALL_DATA) ${INT}/algebra/USERS.DAASE/index.KAF \
+                   $(axiom_targetdir)/algebra/USERS.DAASE
+       @ $(INSTALL_DATA) ${INT}/algebra/DEPENDENTS.DAASE/index.KAF \
+                   $(axiom_targetdir)/algebra/DEPENDENTS.DAASE
 
 @
 \section{summary}
@@ -90,6 +96,10 @@
 MID=${OBJ}/${SYS}/etc
 DOC=${INT}/doc/src/etc
 INTERPSYS=$(axiom_build_bindir)/interpsys
+DATABASES_SHORT=compress.daase interp.daase browse.daase category.daase \
+                operation.daase libdb.text comdb.text USERS.DAASE/index.KAF \
+                DEPENDENTS.DAASE/index.KAF
+DATABASES=$(addprefix $(axiom_targetdir)/algebra/, $(DATABASES_SHORT))
 
 subdir = src/etc/
 
@@ -98,7 +108,7 @@
 
 all: all-ax
 
-all-ax: $(axiom_targetdir)/algebra/*.daase $(axiom_target_bindir)/asq \
+all-ax: $(DATABASES) $(axiom_target_bindir)/asq \
                $(axiom_target_libdir)/summary \
                $(axiom_target_libdir)/copyright \
                $(axiom_target_bindir)/axiom
Tylko w build-improvements/src/etc: Makefile.pamphlet.orig
diff -ru build-improvements.pp/src/interp/lisplib.boot.pamphlet 
build-improvements/src/interp/lisplib.boot.pamphlet
--- build-improvements.pp/src/interp/lisplib.boot.pamphlet      2006-11-01 
19:33:09.000000000 +0100
+++ build-improvements/src/interp/lisplib.boot.pamphlet 2006-11-01 
19:36:52.000000000 +0100
@@ -56,9 +56,8 @@
   readLibPathFast p
  
 readLibPathFast p ==
-  -- assumes 1) p is a valid pathname
-  --         2) file has already been checked for existence
-  RDEFIOSTREAM([['FILE,:p], '(MODE . INPUT)],false)
+  -- DO NOT assume that p is a valid pathname
+  RDEFIOSTREAM([['FILE,:p], '(MODE . INPUT)])
  
 writeLib(fn,ft) == writeLib1(fn,ft,"*")
  
diff -ru build-improvements.pp/src/interp/nlib.lisp.pamphlet 
build-improvements/src/interp/nlib.lisp.pamphlet
--- build-improvements.pp/src/interp/nlib.lisp.pamphlet 2006-11-01 
19:33:09.000000000 +0100
+++ build-improvements/src/interp/nlib.lisp.pamphlet    2006-11-01 
19:36:00.000000000 +0100
@@ -448,17 +448,23 @@
                       :test #'string=) 
               :test #'string=))))
 
+(defun axiom-probe-file (file)
+    (if (equal (|directoryp| file) -1)
+         nil
+         (truename file))
+)
+
 (defun make-input-filename (filearg &optional (filetype nil))
    (let*
      ((filename  (make-filename filearg filetype))
       (dirname (pathname-directory filename))
       (ft (pathname-type filename))
       (dirs (get-directory-list ft))
-      (newfn nil))   
+      (newfn nil))
     (if (or (null dirname) (eqcar dirname :relative))
        (dolist (dir dirs (probe-name filename))
                (when 
-                (probe-file 
+                (axiom-probe-file 
                  (setq newfn (concatenate 'string dir filename)))
                 (return newfn)))
       (probe-name filename))))
@@ -476,7 +482,7 @@
 ;; ($ERASE filearg) -> 0 if succeeds else 1
 (defun $erase (&rest filearg)
   (setq filearg (make-full-namestring filearg))
-  (if (probe-file filearg)
+  (if (axiom-probe-file filearg)
 #+:CCL (delete-file filearg)
 #+:AKCL
       (if (library-file filearg)

\start
Date: Fri, 3 Nov 2006 23:35:52 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: hypertex and uses info

Vanuxem Gr=E9gory wrote:
> Waldek,
>
> > All versions of hypertex that I used crashed (or maybe showed
> > nothing)
> > when I clicked "Uses" or "Dependants" field in a description of a const=
ructor.
>
> > AFAICS recent versions of Axiom have two problems here:
>
> > 1) databases which contain corresponding information (USERS.DAASE
> >    and DEPENDENTS.DAASE) were not installed
> > 2) infamous 'probe-file' problem
>
> > The patch below correct both problems. It also fixes the
> > "Cannot rename the file erlib to NRLIB" problem. I also added
> > sensible dependency in database rule, so that all databses
> > are re-made when one get out of date. And 'RDEFIOSTREAM' is
> > now called in error-checking mode (old code happily passed
> > bad pathnames and supressed error checking).
>
> I'm in the process of applying these patches. Do you know a situation whe=
re
> readLibPathFast is used on a non existent file ? Since you prefer to remo=
ve
> some assumptions, I want to know :-)
>

The prime example is if you forget to install USERS.DAASE or
DEPENDENTS.DAASE, even with probe-file problem resolved you
still get crash.

BTW 1: I would say that somebody making an assumption should justify
it (and the assumption is completly unjustified, as the pathname
does no error checking).

BTW 2: Expensive part of error checking in RDEFIOSTREAM is done
anyway, so there is no excuse to skip cheap error check.

BTW 3: IMHO the approach check first and then go on without checking
has fundamental problems, Unix way "try and check if OK" works
much better.

\start
Date: Fri, 3 Nov 2006 18:01:00 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: Re: hypertex and uses info

Based on your extensive work would you consider being the
person who maintains axiom--silver--1? That would settle
one of the items raised by Gaby.

\start
Date: Sat, 4 Nov 2006 00:49:29 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: Maintainers

root wrote:
> Based on your extensive work would you consider being the
> person who maintains axiom--silver--1? That would settle
> one of the items raised by Gaby.
> 

Yes, however some clarificatinons are needed:

1) ATM I work with SVN on SourceForge and I hope to avoid contact
   with arch
2) "one of persons who maintain ..." -- IIUC Gaby wants to avoid
   single point of failure (me too).

\start
Date: Fri, 3 Nov 2006 19:17:06 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: Re: Maintainers

> > Based on your extensive work would you consider being the
> > person who maintains axiom--silver--1? That would settle
> > one of the items raised by Gaby.
> > 
> 
> Yes, however some clarificatinons are needed:
> 
> 1) ATM I work with SVN on SourceForge and I hope to avoid contact
>    with arch

Arch holds the master sources, which get mirrored everywhere, into
CVS on sourceforge and savannah, as well as SVN on sourceforge and
google. If you're not willing to do this because of arch then that's 
fine. I just thought that you were showing great initiative and might
find it worthwhile to try. Handling multiple SCMs would be the least
problem (currently axiom lives in arch, cvs, svn, and darcs).

The hard part is trying to figure out how to agree to things
that you disagree with because other people have perfectly
rational opinions. Working with arch is trivial. Working with
people is hard. And among them I'm probably one of the most painful.

> 2) "one of persons who maintain ..." -- IIUC Gaby wants to avoid
>    single point of failure (me too).

How you maintain axiom--silver--1 would be up to you. Be aware
that about 22 people have write access to silver at the moment.

I don't think "single point of failure" is a rational notion
in terms of SCM. You or I could simply stop patching the code
and the world would hardly notice since many people have write
access.

A "single point of control", however, is vitally important.
You're basically "putting your name" on the dotted line 
claiming that you "control" the repository. If you allow
anyone to make any change they want you'll quickly find that
you have no idea what the changes mean and how they impact
the stability of "silver". That behavior is fine in a branch
but means chaos in the "pre-production" master copy. You 
can't track every person's "hot topic", nor have an instant
understanding of their "obviously correct patch".

You would need to think about how the changes will affect
many things including outstanding branches. Suppose
someone checks in Java Ant sripts to do builds instead of
using autoconf. Is that the best thing for the project?
Do we want to add Java as a global dependency? How do you
plan to resolve the Perl build mechanism with the current
mechanism? Or the build-improvements mechanism? Or suppose
someone renames files. What code depends on those files?
Does it break things we are not testing?

I am very careful about putting patches into silver until
I understand them. Silver patches are gold-to-be so its
not the same as maintaining a branch. You not only need
to apply the patch, you need to figure out how to check
that it is right and you need to figure out how to test
that it works. Thus a silver patch is very expensive.

Just because it works does not make it right for the project.

And you have to give strong pushback to maintain quality.
Changes and addtions NEED excellent documentation (not just
code changes). This will be the big discussion about getting
anything into gold in the future. 

It's a hard job and one that will put you in a position 
of contention with people at times.

Think carefully about it and let me know.

\start
Date: Fri, 3 Nov 2006 22:39:49 -0500
From: Bill Page
To: Humberto Zuazaga
Subject: RE: Mac OS X 10.4.8 PowerPC success!

On November 3, 2006 2:23 PM Humberto Ortiz Zuazaga wrote:
> 
> I built the build-improvements branch with the GCL I made last
> night, and it looks like it works:
>...

Wonderful!
 
> 
> Here's the build process:
> 
> darcs get http://page.axiom-developer.org/repository/axiom-darcs/
> 
>   535  chmod +x configure
>   536  ./configure --prefix=/usr/local --with-gcl
>   552  chmod +x config/mkinstalldirs
>   553  make
>   568  ls target/powerpc-apple-darwin8.8.0/bin/AXIOMsys
>   569  export
AXIOM=/Users/humberto/src/axiom-darcs/target/powerpc-apple-darwin8.8.0
>   570  PATH=$PATH:$AXIOM/bin
>   571  AXIOMsys
> 
> Success!
> 
> darcs or the Mac mangled the permissions on configure and 
> config/mkinstalldirs, the rest went smoothly.
> 

That's much easier than I expected. :-)

You only show running the Axiom main console program AXIOMsys.
How about the other parts of Axiom? If you type the command:

  $ axiom

You should see the hyperdoc window where you can browse the
Axiom library, run tutorial examples, search some documentation.
Does that work?

Note: We already suspect some possible errors in the display of
certain symbols in hyperdoc because of some mixed case file names,
e.g. Greek letters.

If you start Axiom as above and type the following Axiom command:

  (1) -> draw(sin x, x=0..2*%pi)

Does the Axiom graphics window open displaying the plot?

Finally, would you be willing to post a tarball of the Axiom
binaries distribution? You would create it like this:

  $ cd .../target
  $ tar czf powerpc-apple-darwin8.8.0.tgz powerpc-apple-darwin8.8.0

Then copy the tarball someplace where others can download it.

Thanks for giving this a try. As far as I know, you are only the
2nd person to ever report successfully running Axiom on a MAC!
:-)

\start
Date: 04 Nov 2006 05:49:34 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Maintainers

Tim Daly writes:

[...]

| A "single point of control", however, is vitally important.
| You're basically "putting your name" on the dotted line 
| claiming that you "control" the repository. If you allow
| anyone to make any change they want you'll quickly find that
| you have no idea what the changes mean and how they impact
| the stability of "silver".

That does not make much sense.  People should be allowed to make
changes to silver when their patches are approved.  That is very
different from people making random changes willy-nilly as you seem to
imply. 

[...]

| You would need to think about how the changes will affect
| many things including outstanding branches. Suppose
| someone checks in Java Ant sripts to do builds instead of
| using autoconf. Is that the best thing for the project?
| Do we want to add Java as a global dependency? How do you
| plan to resolve the Perl build mechanism with the current
| mechanism? Or the build-improvements mechanism? Or suppose
| someone renames files. What code depends on those files?
| Does it break things we are not testing?

But, the check-in would have been approved after review, not before!

[...]

| Just because it works does not make it right for the project.

Yes, indeed.  And we should erase silver. <g>.

\start
Date: Sat, 4 Nov 2006 00:34:00 -0500
From: Bill Page
To: Waldek Hebisch,
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On November 3, 2006 2:16 PM Waldek Hebisch wrote:
> 
> Gabriel Dos Reis wrote:
> > Waldek Hebisch writes:
> >
> > | Not yet.  In a message that I sent few minutes ago I proposed to
> > | rename 'poly.ht' to 'polys.ht' and 'poly.pht' to 'polys.pht'.
> > 
> > Please go ahead and commit to build-improvements.  Add an 
> > explanation (in the pamphlets) about the renaming.
> 
> Commited.  But after extra checking I see more problem.  Namely
> in 'src/hyper/bitmaps' we have the following pairs:
> 
> xi.bitmap Xi.bitmap
> upsilon.bitmap Upsilon.bitmap
> theta.bitmap Theta.bitmap
> sigma.bitmap Sigma.bitmap
> psi.bitmap Psi.bitmap
> pi.bitmap Pi.bitmap
> phi.bitmap Phi.bitmap
> omega.bitmap Omega.bitmap
> lambda.bitmap Lambda.bitmap
> gamma.bitmap Gamma.bitmap
> delta.bitmap Delta.bitmap
> 
> aTx=b.bitmap ATX=B.bitmap
> 
> The first group consists of images of greek letters, version with
> lowercase name is lowercase letter, while uppercase letter has
> the first letter of filename in upper case.
>

I suggest the following changes:

s/Xi.bitmap/xi-cap.bitmap/
s/Upsilon.bitmap/upsilon-cap.bitmap/
s/Theta.bitmap/theta-cap.bitmap/
s/Sigma.bitmap/sigma-cap.bitmap/
s/Psi.bitmap/psi-cap.bitmap/
s/Pi.bitmap/pi-cap.bitmap/
s/Phi.bitmap/phi-cap.bitmap/
s/Omega.bitmap/omega-cap.bitmap/
s/Lambda.bitmap/lambda-cap.bitmap/
s/Gamma.bitmap/gamma-cap.bitmap/
s/Delta.bitmap/delta-cap.bitmap/

I think the following two files are not used anywhere:

aTx=b.bitmap
ATX=B.bitmap

(See list of unused bitmap files below.)
 
> Also in 'src/doc/ps' we have 'SEGBIND.ps' and 'segbind.ps'.  
> 'segbind.ps' is a screen dump of a graphic window containing a
> parabola.  I can not really see 'SEGBIND.ps' because it triggers
> Postscript stack error in ghostscript (like many other files in
> 'src/doc/ps' :(.
> 

I think all .ps files that are not referenced in any *.pamphlet file
(such as SEGBIND.ps and segbind.ps) should be deleted from the /ps
directory.

Here is a quick hack to show which files in src/doc/ps are not
used in any src/doc/*.pamphlet file:

$ cd /home/page/axiom.build-improvements/src/doc
$ ls ps > ps_old
$ grep 'ps/.*\.ps.*}' *.pamphlet | \
  awk '{FS="ps/"; print substr($2,0,index($2,".ps")+2);}' | \
  sort | uniq > ps_new
$ diff --unified=0 ps_old ps_new | \
  awk '/^-[^-]/ { print substr($1,2)}'

2Dcos.ps
2Dsincos.ps
2Dsin.ps
atan-1.epsi
basic2d.ps
bessintr.eps
bessintr.epsi
h-browse.ps
h-condition.ps
h-crossref.ps
h-inverse.ps
h-matrixops1.ps
h-matrixops2.ps
h-matrix.ps
h-matusers.ps
h-opsearch.ps
h-origins.ps
h-parameter.ps
h-signature.ps
knot3.ps
P28a.eps
P28b.eps
segbind.ps
SEGBIND.ps
wd-atanz.ps
wd-bessi3.ps
wd-bessi3s.ps
wd-bessi.ps
wd-bessj.ps
wd-beta.ps
wd-expz.ps
wd-gammaz.ps

--------

Here is a similar hack for bitmaps:

$ cd 
$ ls ../bitmaps > bitmap_old
$ grep 'inputbitmap{\\htbmdir{}' * | \
  awk '{FS="{}/";print substr($2,1,index($2,"}}")-1)}' | \
  sort | uniq > bitmap_new
$ diff --unified=0 bitmap_old bitmap_new | \
  awk '/^-[^-]/ { print substr($1,2)}'

ai.bitmap
Al.bitmap
alphaj.bitmap
alpha.xbm
aTx=b.bitmap
ATX=B.bitmap
betaj.bitmap
beta.xbm
c02aff.bitmap
c1.bitmap
ci.bitmap
clearall.bitmap
clear.bitmap
ClickToSet.bitmap
Continue.bitmap
ctb.bitmap
d01aqf.xbm
d01fcf.bitmap
d01gaf1.bitmap
d01gaf2.bitmap
d02gaf.bitmap
d03edf1.bitmap
d03edf.bitmap
d03eef2.bitmap
d03eef.bitmap
d03faf.bitmap
delta.xbm
DoIt.bitmap
door
door.bitmap
down.bitmap
dr.bitmap
e01baf1.bitmap
e01baf.bitmap
e01bef.bitmap
e01daf1.bitmap
e01daf.bitmap
e02adf1.bitmap
e02adf.bitmap
e02aef.bitmap
e02agf1.bitmap
e02agf.bitmap
e02ahf1.bitmap
e02ahf.bitmap
e02ajf.bitmap
e02baf.bitmap
e02bdf.bitmap
e02bef.bitmap
e02daf1.bitmap
e02daf.bitmap
e04fdf1.bitmap
e04fdf.bitmap
e04mbf.bitmap
e04naf.bitmap
e04ucf.bitmap
ep1.bitmap
ep2.bitmap
epi.bitmap
epp.bitmap
epsilon.xbm
erase.bitmap
error.bitmap
exit3d.bitmap
exit3di.bitmap
exit3d_old.bitmap
f01qcf1.bitmap
f01qcf2.bitmap
f01qcf3.bitmap
f01qcf.bitmap
f01qdf1.bitmap
f01qdf2.bitmap
f01qdf.bitmap
f01rdf1.bitmap
f01rdf2.bitmap
f01rdf.bitmap
fi.bitmap
fqr.bitmap
fr.bitmap
gammak.bitmap
gamma.xbm
gi.bitmap
great=.bitmap
help2.bakmap
help3d.bitmap
help3di.bitmap
help3d_old.bitmap
help.bitmap
home3d.bitmap
home3di.bitmap
home3d_old.bitmap
ing1.bitmap
ing2.bitmap
ing.bitmap
int12.xbm
integral.bitmap
integral.bm
l1.bitmap
lamdab.bitmap
lamdai.bitmap
lamdaj.bitmap
ldlt.bitmap
less=.bitmap
lj.bitmap
llt.bitmap
lt.bitmap
mask.bitmap
menudot.bitmap
mkm.bitmap
mui.bitmap
muj.bitmap
mx.bitmap
my.bitmap
ncap.bitmap
newrho.bitmap
nl.bitmap
nn.bitmap
noop3d.bitmap
noop.bitmap
notequal.xbm
nx.bitmap
ny.bitmap
ode3.xbm
omicron.bitmap
pelzel.bitmap
phi.xbm
pick.bitmap
pick_old.bitmap
plusminus.xbm
psi.xbm
px.bitmap
py.bitmap
quit.bitmap
return2.bitmap
rho=r.bitmap
rhosq=.bitmap
s13aaf1.bitmap
s13aaf2.bitmap
s13aaf.bitmap
s13acf.bitmap
s13adf.bitmap
s14baf.bitmap
s15adf.bitmap
s15aef.bitmap
s17acf.bitmap
s17adf.bitmap
s17aef1.bitmap
s17aef.bitmap
s17aff1.bitmap
s17aff.bitmap
s17dcf.bitmap
s17def.bitmap
s17dlf1.bitmap
s17dlf2.bitmap
s17dlf.bitmap
s18acf1.bitmap
s18acf.bitmap
s18adf1.bitmap
s18adf.bitmap
s18aef1.bitmap
s18aef.bitmap
s18aff1.bitmap
s18aff.bitmap
s18dcf.bitmap
s18def.bitmap
s21baf1.bitmap
s21baf1.bitmap.wrong
s21baf.bitmap
s21baf.bitmap.wrong
s21bbf1.bitmap
s21bbf.bitmap
s21bcf1.bitmap
s21bcf.bitmap
s21bdf1.bitmap
s21bdf.bitmap
sdown3d.bitmap
sdown3dpr.bitmap
sdown.bitmap
si-integral.bitmap
source.bitmap
subtwo.bitmap
sum.bm
sup3d.bitmap
sup3dpr.bitmap
uij.bitmap
uj.bitmap
unpick.bitmap
unpick_old.bitmap
up2.bitmap
up3d.bitmap
up3di.bitmap
up.bitmap
updots.bitmap
wr.bitmap
x1.xbm
xbar.bitmap
xe.xbm
xii.bitmap
xiii.bitmap
xj.bitmap
xmax.bitmap
xmin.bitmap
xq.bitmap
xr.bitmap
xs.xbm
y1.xbm
y2.xbm
ye.xbm
yi.bitmap
yr.bitmap
ys.xbm
zetak.bitmap
zk.bitmap

\start
Date: Sat, 4 Nov 2006 00:33:09 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Maintainers

> | A "single point of control", however, is vitally important.
> | You're basically "putting your name" on the dotted line 
> | claiming that you "control" the repository. If you allow
> | anyone to make any change they want you'll quickly find that
> | you have no idea what the changes mean and how they impact
> | the stability of "silver".
> 
> That does not make much sense.  People should be allowed to make
> changes to silver when their patches are approved.  That is very
> different from people making random changes willy-nilly as you seem to
> imply. 

..."when their patches are approved"...

if the idea is tested in a branch
and if people feel it's a reasonable idea
and if there is a changeset from the branch to gold
the only remaining task is to make sure that the changeset
does not break other changesets that are already added to silver.

this responsibility should be the work of a single person
so that there is a focal point for coordinating discussion.
if two perfectly good branches make incompatible changes to silver
which one wins and who has to redo their changeset?

one person has total control over the whole source tree in their branch,
such as you have with build-improvements. why isn't it reasonable to
have one person coordinating silver? 

there are a lot of "other tasks" besides checking in changes 
that need to be performed in order to keep a silver version.
who would have the responsibility to do this?

\start
Date: Sat, 4 Nov 2006 00:35:02 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Maintainers

> But, the check-in would have been approved after review, not before!

Actually, both. 

The check-in needs to be reviewed before it is committed back to the
axiom--silver--1 branch to make sure it doesn't break other pending
changes.

The check-in needs to be reviewed after it is committed by the author
to make sure their changes are all correctly applied and by the silver
maintainer to make sure that nothing broke.

\start
Date: 04 Nov 2006 06:41:52 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

| On November 3, 2006 2:16 PM Waldek Hebisch wrote:
| > 
| > Gabriel Dos Reis wrote:
| > > Waldek Hebisch writes:
| > >
| > > | Not yet.  In a message that I sent few minutes ago I proposed to
| > > | rename 'poly.ht' to 'polys.ht' and 'poly.pht' to 'polys.pht'.
| > > 
| > > Please go ahead and commit to build-improvements.  Add an 
| > > explanation (in the pamphlets) about the renaming.
| > 
| > Commited.  But after extra checking I see more problem.  Namely
| > in 'src/hyper/bitmaps' we have the following pairs:
| > 
| > xi.bitmap Xi.bitmap
| > upsilon.bitmap Upsilon.bitmap
| > theta.bitmap Theta.bitmap
| > sigma.bitmap Sigma.bitmap
| > psi.bitmap Psi.bitmap
| > pi.bitmap Pi.bitmap
| > phi.bitmap Phi.bitmap
| > omega.bitmap Omega.bitmap
| > lambda.bitmap Lambda.bitmap
| > gamma.bitmap Gamma.bitmap
| > delta.bitmap Delta.bitmap
| > 
| > aTx=b.bitmap ATX=B.bitmap
| > 
| > The first group consists of images of greek letters, version with
| > lowercase name is lowercase letter, while uppercase letter has
| > the first letter of filename in upper case.
| >
| 
| I suggest the following changes:
| 
| s/Xi.bitmap/xi-cap.bitmap/
| s/Upsilon.bitmap/upsilon-cap.bitmap/
| s/Theta.bitmap/theta-cap.bitmap/
| s/Sigma.bitmap/sigma-cap.bitmap/
| s/Psi.bitmap/psi-cap.bitmap/
| s/Pi.bitmap/pi-cap.bitmap/
| s/Phi.bitmap/phi-cap.bitmap/
| s/Omega.bitmap/omega-cap.bitmap/
| s/Lambda.bitmap/lambda-cap.bitmap/
| s/Gamma.bitmap/gamma-cap.bitmap/
| s/Delta.bitmap/delta-cap.bitmap/

I agree.

| I think the following two files are not used anywhere:
| 
| aTx=b.bitmap
| ATX=B.bitmap
| 
| (See list of unused bitmap files below.)

How do we determine that they are referenced at run-time through
dynamic generation of their names?
It is because we know no such things exist?

| > Also in 'src/doc/ps' we have 'SEGBIND.ps' and 'segbind.ps'.  
| > 'segbind.ps' is a screen dump of a graphic window containing a
| > parabola.  I can not really see 'SEGBIND.ps' because it triggers
| > Postscript stack error in ghostscript (like many other files in
| > 'src/doc/ps' :(.
| > 
| 
| I think all .ps files that are not referenced in any *.pamphlet file
| (such as SEGBIND.ps and segbind.ps) should be deleted from the /ps
| directory.

Before deletion, we have to determine that they are not referenced at
runtime through name generation on the fly.  Do you know whether that
can ever happen?

\start
Date: Sat, 4 Nov 2006 00:36:54 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Maintainers

> | Just because it works does not make it right for the project.
> 
> Yes, indeed.  And we should erase silver. <g>.

"Sometimes humor is the only possible solution" -- Tim Daly

\start
Date: Sat, 4 Nov 2006 01:05:04 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On November 3, 2006 11:34 AM Gaby wrote:
> ...
> Bill Page wrote:
> | 
> | If you have an issue about the decision to let Tim Daly manage
> | the update of Axiom Silver via his manual updates of his tla
> | axiom--silver--1 archive (with auto sync to svn /silver),
> | then I think that should be treated separately from the issue
> | of the configuration of the source code archives.
> 
> I'm very happy to see Tim is making changes more visible now, 
> than waiting for ages before seeing light. The main reason I
> originally volunteered to maintain Silver is that I do believe
> in "live sources". Tim suggested at the time that he did not have
> time do maintain too many branches. It therefore was a natural
> thing for me to volunteer to take on the job.

Of course your offer was sincere and with good intentions. But since
Tim cant or wont solve his problems with using svn, that would have
meant that he would have had to send his patches to you manually in
addition to recording the changes in his own tla axiom--silver--1
repository. Or alternatively you would have had to learn how to use
arch (tla). Obviously that arrangement was not working.

>  Now, if Tim has more time to do the job, I'm all for it.
> 
> However, I see practical issue here:  
> 
>   (1) first, we should not have one single person as authority to
>       commit changes.  Every contributor we grant write access should
>       commit its own changes to silver/trunk/whatever it is
>       called.  That way, we don't have to wait that only a single
>       person has time and do the job.
>

Yes I agree in principle, however there is a technical problem so
long as Tim insists on using arch (tla): There is no available
automatic synchronization program from svn to tla, but it does work
in the other direction. This would mean that changes committed to
svn would not automatically be made to axiom--silver--1 and would
again rely on Tim to try to manually keep axiom--silver--1 in sync.
This also was not working.

This technical problem could be solved if Tim were to convert to
using another more current repository software, e.g. GIT with which
is can do a two-way sync. (Or of course, if we all agreed to use
exactly one type of repository!)
 
>   (2) second, the review should be public, instead of being done
>       in private.  This helps people to learn possible obscure
>       cases of the system -- instead of the only-one-who-knows has
>       a conversation with himself and commit. The changes should
>       be sent to the list instead of Tim.

Absolutely correct. I am sorry if I was not clear on that.

> 
>   (3) third, I'm having difficulty in following the reasoning that,
>       most people would develop patches against the SVN repo, they
>       will see their patches applied by someone else to a repo under
>       a different SCM, and wait a day and then copied back, to the
>       SVN repo just to see their changes.  That does not strike me
>       as efficient.

In fact I do I agree with you. But projects like Axiom are about
people as well as technology. Sometimes we need to do things to
accommodate other people no matter how awkward that makes the
process.

>       I consider that an extraordinary waste of time and resources.
> 

Well awkward, yes, but I don't see it as a waste of time or of
resources. The most limited resource for Axiom right now is people
with knowledge of how Axiom works. It seems that we might have to
do some extraordinary things in order to retain all of these "eggs"
in one basket... :-)

\start
Date: Sat, 4 Nov 2006 01:19:44 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On November 4, 2006 12:42 AM Gaby wrote:
>...
> Bill Page wrote: 
> | I think the following two files are not used anywhere:
> | 
> | aTx=b.bitmap
> | ATX=B.bitmap
> | 
> | (See list of unused bitmap files below.)
> 
> How do we determine that they are referenced at run-time through
> dynamic generation of their names? It is because we know no such
> things exist?

I do not know that they are not referenced at run-time through
dynamic generation of their names, however given what I know about
this programs it seems very unlikely to me.

> 
> | > Also in 'src/doc/ps' we have 'SEGBIND.ps' and 'segbind.ps'.  
> | > 'segbind.ps' is a screen dump of a graphic window containing a
> | > parabola.  I can not really see 'SEGBIND.ps' because it triggers
> | > Postscript stack error in ghostscript (like many other files in
> | > 'src/doc/ps' :(.
> | > 
> | 
> | I think all .ps files that are not referenced in any *.pamphlet file
> | (such as SEGBIND.ps and segbind.ps) should be deleted from the /ps
> | directory.
> 
> Before deletion, we have to determine that they are not referenced
> at runtime through name generation on the fly.  Do you know whether
> that can ever happen?
> 

I do not know and I think it might be prohibitive in time to examine
the code in sufficient detail to ensure that this is not the case but
it seems to me the benefits of cleaning up this mess out weight the
risk, especially since these files are among the problematic binary
and mixed-case files in the distribution.

Here is one suggestion: For now we could just move all of the "unused"
files that I listed in my previous email to temporary location in the
source tree. The recent improvements to hyperdoc made by Waldek suggest
that now would be a good time in any case to have Axiom users focus
more attention on this part of the system. If problems of missing
files occur, it should be difficult to document which of the presumed
"unused" files is actually referenced dynamically (if any).

\start
Date: 04 Nov 2006 07:26:49 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Maintainers

Tim Daly writes:

| > | A "single point of control", however, is vitally important.
| > | You're basically "putting your name" on the dotted line 
| > | claiming that you "control" the repository. If you allow
| > | anyone to make any change they want you'll quickly find that
| > | you have no idea what the changes mean and how they impact
| > | the stability of "silver".
| > 
| > That does not make much sense.  People should be allowed to make
| > changes to silver when their patches are approved.  That is very
| > different from people making random changes willy-nilly as you seem to
| > imply. 
| 
| ..."when their patches are approved"...
| 
| if the idea is tested in a branch

You're not going to require people to create a branch for *every
single* patch, right?

[...]

| one person has total control over the whole source tree in their branch,
| such as you have with build-improvements. why isn't it reasonable to
| have one person coordinating silver? 

For that matter, I feel the control of branches should be shared
responsabilities when and where that appropriate.  In the case of the
trunk/silver I feel even more so that it should not depend on a single
point of failure.

| there are a lot of "other tasks" besides checking in changes 
| that need to be performed in order to keep a silver version.
| who would have the responsibility to do this?

Please be more specific, so that I can offer meaningful answer.

\start
Date: 04 Nov 2006 07:32:07 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Maintainers

Tim Daly writes:

| > But, the check-in would have been approved after review, not before!
| 
| Actually, both. 
| 
| The check-in needs to be reviewed before it is committed back to the
| axiom--silver--1 branch to make sure it doesn't break other pending
| changes.
| 
| The check-in needs to be reviewed after it is committed by the author
| to make sure their changes are all correctly applied and by the silver
| maintainer to make sure that nothing broke.

Only because you have introduced an unnecessary step.

Patch is reviewed, and accepted.  Author has the responsability to
check in as approved.  Period.

Now, if you introduce that walk-around, people have to check that you
did not mess up their changes.  This is compounded by the fact that we
know of this changes only after a day, when possibly other changes
have been applied too.  Remove the unnecessary step; make the source
live. 

\start
Date: 04 Nov 2006 07:34:10 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Maintainers

Tim Daly writes:

| > | Just because it works does not make it right for the project.
| > 
| > Yes, indeed.  And we should erase silver. <g>.
| 
| "Sometimes humor is the only possible solution" -- Tim Daly

In this case, it wasn't "the only possible solution", but it was an
adequate answer that carries a point that I hope successfully reaches
the target. 

\start
Date: 04 Nov 2006 07:37:30 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

[...]

| > | > Also in 'src/doc/ps' we have 'SEGBIND.ps' and 'segbind.ps'.  
| > | > 'segbind.ps' is a screen dump of a graphic window containing a
| > | > parabola.  I can not really see 'SEGBIND.ps' because it triggers
| > | > Postscript stack error in ghostscript (like many other files in
| > | > 'src/doc/ps' :(.
| > | > 
| > | 
| > | I think all .ps files that are not referenced in any *.pamphlet file
| > | (such as SEGBIND.ps and segbind.ps) should be deleted from the /ps
| > | directory.
| > 
| > Before deletion, we have to determine that they are not referenced
| > at runtime through name generation on the fly.  Do you know whether
| > that can ever happen?
| > 
| 
| I do not know and I think it might be prohibitive in time to examine
| the code in sufficient detail to ensure that this is not the case but
| it seems to me the benefits of cleaning up this mess out weight the
| risk, especially since these files are among the problematic binary
| and mixed-case files in the distribution.
| 
| Here is one suggestion: For now we could just move all of the "unused"
| files that I listed in my previous email to temporary location in the
| source tree. The recent improvements to hyperdoc made by Waldek suggest
| that now would be a good time in any case to have Axiom users focus
| more attention on this part of the system. If problems of missing
| files occur, it should be difficult to document which of the presumed
| "unused" files is actually referenced dynamically (if any).

I agree.  I subscribe to your suggestion to move "unused" files to a
"jail" directory. 

\start
Date: Sat, 4 Nov 2006 01:42:00 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Maintainers

> | > | A "single point of control", however, is vitally important.
> | > | You're basically "putting your name" on the dotted line 
> | > | claiming that you "control" the repository. If you allow
> | > | anyone to make any change they want you'll quickly find that
> | > | you have no idea what the changes mean and how they impact
> | > | the stability of "silver".
> | > 
> | > That does not make much sense.  People should be allowed to make
> | > changes to silver when their patches are approved.  That is very
> | > different from people making random changes willy-nilly as you seem to
> | > imply. 
> | 
> | ..."when their patches are approved"...
> | 
> | if the idea is tested in a branch
> 
> You're not going to require people to create a branch for *every
> single* patch, right?

idea == patch? surely you jest.
you clearly don't think that's a reasonable sentence or 
you would not have organized build-improvements the way you did.

> [...]
> 
> | one person has total control over the whole source tree in their branch,
> | such as you have with build-improvements. why isn't it reasonable to
> | have one person coordinating silver? 
> 
> For that matter, I feel the control of branches should be shared
> responsabilities when and where that appropriate.  In the case of the
> trunk/silver I feel even more so that it should not depend on a single
> point of failure.

please lose the notion of "single point of failure" as it is meaningless.
the axiom sources exist in a dozen places and are freely writeable by
two dozen people. a sudden heart attack on my part would have little
if any effect on axiom development.

> | there are a lot of "other tasks" besides checking in changes 
> | that need to be performed in order to keep a silver version.
> | who would have the responsibility to do this?
> 
> Please be more specific, so that I can offer meaningful answer.

well, answering related email would be one :-)

\start
Date: Sat, 4 Nov 2006 01:54:34 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Maintainers

> | > But, the check-in would have been approved after review, not before!
> | 
> | Actually, both. 
> | 
> | The check-in needs to be reviewed before it is committed back to the
> | axiom--silver--1 branch to make sure it doesn't break other pending
> | changes.
> | 
> | The check-in needs to be reviewed after it is committed by the author
> | to make sure their changes are all correctly applied and by the silver
> | maintainer to make sure that nothing broke.
> 
> Only because you have introduced an unnecessary step.

or you left out an important step. even programs do this in several
steps with different responsibilities. think of databases. when you
insert or modify a record there are pre-scripts and post-scripts that
run to validate the change even though you claim it is correct.
sometimes a change you make gets rejected for reasons you didn't expect.




> 
> Patch is reviewed, and accepted.  Author has the responsability to
> check in as approved.  Period.
> 
> Now, if you introduce that walk-around, people have to check that you
> did not mess up their changes.  This is compounded by the fact that we
> know of this changes only after a day, when possibly other changes
> have been applied too.  Remove the unnecessary step; make the source
> live. 

so if you add build improvements as a changeset and i add an ant
build-xml as a changeset who is responsible for mediating the
breakage?  we both have our reasons. you want BI because it follows
standard GNU practice. i want ant because i've written java-based
regression testing (no, i haven't written such a thing).

it is really a separation-of-concerns issue.  every author has a
vested interest in making sure his changeset is accepted.  but the
owner of the silver branch is responsible for making sure that ALL
changesets are checked. Further, the silver owner has to deal with
convincing me that the changes should get accepted into gold.

think of it as a human-mediated "svn merge" with rationality.
the machine may think the changeset is ok but not the human.

if we're developing literate programs for the humans rather than
patch files for the machine somebody has to review the result.
you wouldn't expect a conference chair to allow anyone to submit
a paper without review, nor are they allowed to change it after
it has been accepted.

\start
Date: Sat, 4 Nov 2006 01:55:45 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Maintainers

> | > | Just because it works does not make it right for the project.
> | > 
> | > Yes, indeed.  And we should erase silver. <g>.
> | 
> | "Sometimes humor is the only possible solution" -- Tim Daly
> 
> In this case, it wasn't "the only possible solution", but it was an
> adequate answer that carries a point that I hope successfully reaches
> the target. 

silver came into being in response to your requests.
a silver-maintainer leader is also in response to your requests.
methinks you're making your points.

\start
Date: 04 Nov 2006 08:28:00 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Maintainers

Tim Daly writes:

| > | > | A "single point of control", however, is vitally important.
| > | > | You're basically "putting your name" on the dotted line 
| > | > | claiming that you "control" the repository. If you allow
| > | > | anyone to make any change they want you'll quickly find that
| > | > | you have no idea what the changes mean and how they impact
| > | > | the stability of "silver".
| > | > 
| > | > That does not make much sense.  People should be allowed to make
| > | > changes to silver when their patches are approved.  That is very
| > | > different from people making random changes willy-nilly as you seem to
| > | > imply. 
| > | 
| > | ..."when their patches are approved"...
| > | 
| > | if the idea is tested in a branch
| > 
| > You're not going to require people to create a branch for *every
| > single* patch, right?
| 
| idea == patch? surely you jest.
| you clearly don't think that's a reasonable sentence or 
| you would not have organized build-improvements the way you did.

As you probably realized, I don't require people to create a branch
off build-improvements just to provide a patch.  right?  

build-improvements is a substantial work; consequently, it needs a
branch.  However, when a dependency rule is missing (as evidenced by
patch to this list), it would very bureaucratuic and inefficient use of
resources to require people to branch of build-improvements just to
provide a branch to correct the missing dependency.  I hope you get
the point.

[...]

| > | one person has total control over the whole source tree in their branch,
| > | such as you have with build-improvements. why isn't it reasonable to
| > | have one person coordinating silver? 
| > 
| > For that matter, I feel the control of branches should be shared
| > responsabilities when and where that appropriate.  In the case of the
| > trunk/silver I feel even more so that it should not depend on a single
| > point of failure.
| 
| please lose the notion of "single point of failure" as it is meaningless.

No, it is not.  You have provide evidence for this over the past,
feeling you're obliged to offer aplogogies after apologies.

[...]

| > | there are a lot of "other tasks" besides checking in changes 
| > | that need to be performed in order to keep a silver version.
| > | who would have the responsibility to do this?
| > 
| > Please be more specific, so that I can offer meaningful answer.
| 
| well, answering related email would be one :-)

Please, don't be afraid to be more *specific*.

\start
Date: 04 Nov 2006 08:43:47 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Maintainers

Tim Daly writes:

| > | > But, the check-in would have been approved after review, not before!
| > | 
| > | Actually, both. 
| > | 
| > | The check-in needs to be reviewed before it is committed back to the
| > | axiom--silver--1 branch to make sure it doesn't break other pending
| > | changes.
| > | 
| > | The check-in needs to be reviewed after it is committed by the author
| > | to make sure their changes are all correctly applied and by the silver
| > | maintainer to make sure that nothing broke.
| > 
| > Only because you have introduced an unnecessary step.
| 
| or you left out an important step. even programs do this in several
| steps with different responsibilities. think of databases. when you
| insert or modify a record there are pre-scripts and post-scripts that
| run to validate the change even though you claim it is correct.
| sometimes a change you make gets rejected for reasons you didn't expect.

If something is missing from the patch, then it must be discussed on
the list; have the author take care of it instead of you having
conversation with yourself, mangling the patches and require author
that what you applied did not go beyond reason.  The only exception I
can think of this is that of automatically generated files that need
not be included in the patch (case in point configure.ac -> configure).

But, again that should not be your responsability of mangling
patches and have people check that the applied mangling is correct.

| > Patch is reviewed, and accepted.  Author has the responsability to
| > check in as approved.  Period.
| > 
| > Now, if you introduce that walk-around, people have to check that you
| > did not mess up their changes.  This is compounded by the fact that we
| > know of this changes only after a day, when possibly other changes
| > have been applied too.  Remove the unnecessary step; make the source
| > live. 
| 
| so if you add build improvements as a changeset and i add an ant
| build-xml as a changeset who is responsible for mediating the
| breakage? 

Please don't be afraid of the specific breakage so that we work out
the details.   

If build-improvements changeset goes in first, then you have to take
that into account in preparing your following patch that you don't
break existing semantics without good reasons.  If build-xml goes in
first then it is my responsability to make sure that I don't break
existing semantics without good reasons.  That procedure is not
different from any other patches.  It is a no-brainer.

| we both have our reasons. you want BI because it follows
| standard GNU practice. i want ant because i've written java-based
| regression testing (no, i haven't written such a thing).
| 
| it is really a separation-of-concerns issue.  every author has a
| vested interest in making sure his changeset is accepted.

Not only that.  Every author has the responsability of making sure
that his changes does not break the whole system and does not prevent
further progress of the whole system.  It is not an individual-thing.
It is a collective product. 

|  but the
| owner of the silver branch is responsible for making sure that ALL
| changesets are checked.

The owner of silver branch has to make sure that the whole system does
not fall apart.  For this to be workable, he has to make sure that
every contribution is made to the point that the whole system is still
coherent.  But, that does not imply that he has the burden and
responsability to mangle patches and afterward has people guess what
was done is faithful to their ideas.  Rather, it should be explained
to the contributors how their contributions should be structured to
ensure that the whole system is functionning, so that others can
contribute too.

| Further, the silver owner has to deal with
| convincing me that the changes should get accepted into gold.

That is a very different issue.  

[...]

| if we're developing literate programs for the humans rather than
| patch files for the machine somebody has to review the result.
| you wouldn't expect a conference chair to allow anyone to submit
| a paper without review, nor are they allowed to change it after
| it has been accepted.

that is an interesting analogy, but:
  (1) Did anyone suggestion anything along those lines?
  (2) for an anology to be meaningful, you have to explain how Axiom
      relates  a conference and why that analogy is sound to lead to
      any meaningful conclusion.


\start
Date: Sat, 4 Nov 2006 02:40:24 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Maintainers

> | please lose the notion of "single point of failure" as it is meaningless.
> 
> No, it is not.  You have provide evidence for this over the past,
> feeling you're obliged to offer aplogogies after apologies.

well, this is your claim.
i claim such a single point does not exist.
you claim it does exist.
it is much harder to prove non-existence of a non-point
so i invite you to go first. 
state where. 
be specific.
prove your claim that a single failure destroys the project.
show your work. :-)

\start
Date: 04 Nov 2006 08:52:11 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Maintainers

Tim Daly writes:

| > | > | Just because it works does not make it right for the project.
| > | > 
| > | > Yes, indeed.  And we should erase silver. <g>.
| > | 
| > | "Sometimes humor is the only possible solution" -- Tim Daly
| > 
| > In this case, it wasn't "the only possible solution", but it was an
| > adequate answer that carries a point that I hope successfully reaches
| > the target. 
| 
| silver came into being in response to your requests.

No, I did not ask the creation of silver.  I requested you make your
changes public and live -- before they move to gold.  What is
currently called silver is not what I requested.  I did not request a
repository that is effectively read-only.

At the risk of repeating myself, let me more specific:

  (1) make your changes live and not just read-only.
  (2) in particular, make it possible that we all see the patches
      applied (not just a message "patch --xxx" is available).
  (3) make the master repository under SVN.  This the "main" source
      which which expriments, including releases are made of.
  (4) commit changes to the master repository before they go do gold.
  (6) have more than just one maintainer.

Go back to the discussion in March-April 2006; which of those points
were not already made?

\start
Date: 04 Nov 2006 09:00:11 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Maintainers

Tim Daly writes:

| > | please lose the notion of "single point of failure" as it is meaningless.
| > 
| > No, it is not.  You have provide evidence for this over the past,
| > feeling you're obliged to offer aplogogies after apologies.
| 
| well, this is your claim.
| i claim such a single point does not exist.
| you claim it does exist.

A single point of failure is when we have only one person

  (1) that has authority to approve and apply changes to the main source,
  (2) make official realeases.

   When that single person becomes unavailable temporarily or forever,
   the project is stalled.

Do you want to be remind you how late --patch-50 was?

| it is much harder to prove non-existence of a non-point

indeed; but thankfully, we are in that business.

\start
Date: Sat, 4 Nov 2006 03:34:19 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Maintainers

> | silver came into being in response to your requests.
> 
> No, I did not ask the creation of silver.  I requested you make your
> changes public and live -- before they move to gold.  What is
> currently called silver is not what I requested.  I did not request a
> repository that is effectively read-only.
> 
> At the risk of repeating myself, let me more specific:
> 

>   (1) make your changes live and not just read-only.

They're not read-only. Search the CHANGELOG file for 'gdr' and
you'll see that you have made changes. It is just that my review 
is part of the change process. 

>   (2) in particular, make it possible that we all see the patches
>       applied (not just a message "patch --xxx" is available).

All patches are posted to the list.

All patches to silver get automatically posted due to Bill's robot.

>   (3) make the master repository under SVN.  This the "main" source
>       which which expriments, including releases are made of.

No, SVN is not the "main" source. Arch is. SVN was created at your
request and now you insist that it become the "main" source. This
has not been the case for the last 5 years and won't be the case
for the forseeable future. One key argument is that several developers
from this list other than myself have experienced problems with SVN.

SVN is fine for "experiments" and developers. It is NOT the release site,
never was, and is not planned as such. Arch has gold which gets published
every couple months with changes mirrored to savannah and sourceforge.
We've been doing that for many years.

>   (4) commit changes to the master repository before they go do gold.

They are committed to the master repository... axiom--silver--1
with changes that are pending in the next gold release. Multiple
direct changes to the master tree are not appropriate.

As an example, the most recent case of removing "duplicate" filenames
in the debugsys image was proposed. The change seems simple and
obvious and did not break the build-improvements branch. However, a
careful review of the change before accepting it into silver found it
to be incorrect.

>   (6) have more than just one maintainer.

There are 22 maintainers for Arch, 6 people with complete admin access
on savannah, and 3 people (including yourself) with complete admin
access on sourceforge.

Ulitmately we differ on philosophy. I believe that each branch
has one person ultimately responsible for that branch. The responsible
person determines policy. 

You are responsible for build-improvements and allow multiple changes
directly to the sources. That is appropriate for development software.

I am responsible for gold and silver and don't allow multiple changes
to the sources. That is appropriate for final release of software.

\start
Date: Sat, 4 Nov 2006 03:41:52 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Maintainers

> A single point of failure is when we have only one person
> 
>   (1) that has authority to approve and apply changes to the main source,
>   (2) make official realeases.
> 

That is a single point of control, not a single point of failure.
Axiom has a single point of control, one per branch and one per
silver and gold. 


>    When that single person becomes unavailable temporarily or forever,
>    the project is stalled.

I don't recall that everyone was required to stop development.


> Do you want to be remind you how late --patch-50 was?

And, indeed, life intervenes. The project was not stalled though
because I spent time getting a hundred copies of Axiom built and
handed out at the ISSAC conference. The result of this time gained
us (hopefully) access to Manuel's work and a few other connections
to other people in our target audience. 

\start
Date: Sat, 04 Nov 2006 11:05:57 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On 11/03/2006 10:22 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> | > I'm very happy to see Tim is making changes more visible now, than waiting
> | > for ages before seeing light. The main reason I originally volunteered to
> | > maintain Silver is that I do believe in "live sources". Tim suggested
> | > at the time that he did not have time do maintain too many branches.
> | > It therefore was a natural thing for me to volunteer to take on the
> | > job.  Now, if Tim has more time to do the job, I'm all for it.
> | 
> | > However, I see practical issue here:    (1) first, we should not
> | > have one single person as authority to
> | >       commit changes.
> | 
> | We are speaking here _only_ of the changes that go to the next Gold
> | release.
> 
> we are talking of Silver, right?

Right. Gold=axiom--main--1 only gets patches every two months.
The gold-to-be=axiom--silver--1 is the branch that Tim commits to in 
order to prepare the next gold.

In my understanding we requested that in order to let axiom-developers 
see how the current gold gradually develops into the next gold. We all 
agreed that Tim commits to gold. Since now that thing is called 
axiom--silver--1 does not change that.

axiom--silver--1 is mirrored on sourceforge /silver and is where people 
should branch from (which is currently not done because /trunk and 
/silver exist simultaneously).

Up to now silver in the form of axiom--silver--1 is maintained by Tim to 
assure quality for the next gold release.

build-improvements has been branched from (a not so perfect copy of) 
silver (which was actually gold=axiom--main--1--patch-49 at that time, 
if I remember correctly).

I haven't yet completely understood how Gaby wants the development 
process. Gaby certainly has quite a lot of experience with development 
on gcc. So we all would be happy to learn.

Gaby, could you post how you think Axiom development should work? (You 
should probably avoid the usage of Gold/silver/bronze.) Just post your 
dream. Where should be the main source? How many stages should be there 
before something is released? How is quality ensured? What _roles_ (not 
persons) should be responsible for what.

Actually, I should ask the same from Tim, but I have the impression I 
somehow already understand his model.

Only if we have a clear picture what the options are, we can discuss how 
we clear the current confusion or how we agree on another development model.

I found the discussion up to now not very fruitful. To me it seemed that 
it is still not clear what Silver actually is. I also have the 
impression that Gaby wanted something else when he opted to maintain 
Silver. Names can sometimes be misleading and I think this is now what 
we have. Tim-Silver is not the intention of Gaby-Silver.

So please Gaby, try to make clear what you like even if you have already 
said that several times before. We must somehow settle the problem that 
you and Tim obviously have different understanding of "Silver".

\start
Date: 04 Nov 2006 11:00:20 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Maintainers

Tim Daly writes:

| > | silver came into being in response to your requests.
| > 
| > No, I did not ask the creation of silver.  I requested you make your
| > changes public and live -- before they move to gold.  What is
| > currently called silver is not what I requested.  I did not request a
| > repository that is effectively read-only.
| > 
| > At the risk of repeating myself, let me more specific:
| > 
| 
| 
| 
| 
| >   (1) make your changes live and not just read-only.
| 
| They're not read-only.

silver in its current state is effectively read-only:  If I commit
changes there, you don't get it automatically the next time you update
your local tree -- because you're using a different source-base. You
have to go and mangle it and have me check it what you mangled is what
I intended.

[...]

| >   (2) in particular, make it possible that we all see the patches
| >       applied (not just a message "patch --xxx" is available).
| 
| All patches are posted to the list.

I have not seen you posting changes to the list.  I've however seen
messages saying that "patch --xxx"" is available.

| All patches to silver get automatically posted due to Bill's robot.

Only a day after, and not all changes are propagated; it seems.
One reason for sending the patches as *you* apply to silver as is that
they get more eyes to review it and test it than you would do on your
own.  Case in point is the the recent change that broke Vanuxem's code.  

[...]

| >   (3) make the master repository under SVN.  This the "main" source
| >       which which expriments, including releases are made of.
| 
| No, SVN is not the "main" source. Arch is. SVN was created at your
| request and now you insist that it become the "main" source. This

Since I do not want to get into the revisionism business, I went to
the archive in April 2006 to see what the discussion was.

In this message:

  http://lists.nongnu.org/archive/html/axiom-developer/2006-04/msg00057.html

you said:

   If any other developer feels the desire to maintain their own SVN
   branch this can also be set up on sourceforge. You can use this
   for 'public development' if you like.  
       ^^^^^^^^^^^^^^^^^^^^

and after the creation of the SVN repository, you wrote in message:

  http://lists.nongnu.org/archive/html/axiom-developer/2006-04/msg00054.html


  [...]

  The SVN version is expected to be used as a hotpatch 'latest change' version. 
  The CVS version will still track the Arch. 
  On a best-effort, two-month interval I'll look to merge the changes
  from the Sourceforge/SVN to the Arch/Sourceforge CVS/Savannah CVS.

How can that be meaningfully for "public development", expected to
be used as a hotpatch 'latest change' version,  and not the main
source?  It looks to me that you just negated everything with the
recent development of silver.

I summarized the rationale of request here

  http://lists.nongnu.org/archive/html/axiom-developer/2006-04/msg00043.html

as

   * instant availability of patches applied to mainline

   * public informative review that helps gain understanding of why
     things are the way they are, possible improvements, and things
     that should not be tried.  That is very essential to attain
     critical mass of people understanding the system.

     I've learnt a lot about Axiom through discussions between you,
     Tim and others. I think that should happen more often, on patches
     -- not just in abstract ;-)

| has not been the case for the last 5 years and won't be the case
| for the forseeable future. One key argument is that several developers
| from this list other than myself have experienced problems with SVN.

Please let be more specific about the "several developers" and discuss
what the issues really are and how they are representative and should
constitute key argument.   
>From what I've seen:

  (1) there is a problem with *SF* SVN setup
  (2) the axiom systems contain many ill-formed protability constructs
      and assumptions exposed by using SVN.

| SVN is fine for "experiments" and developers. It is NOT the release site,

For release, there should be *official tarballs*, not just --patch-xxx
under repo XYZ.

[...]

| >   (4) commit changes to the master repository before they go do gold.
| 
| They are committed to the master repository... axiom--silver--1
| with changes that are pending in the next gold release. Multiple
| direct changes to the master tree are not appropriate.
| 
| As an example, the most recent case of removing "duplicate" filenames

I see you have carefully constructed a very deformed idea of the patch
-- it was not about removing duplicate "filenames" as explained many
times. 

| in the debugsys image was proposed. The change seems simple and
| obvious and did not break the build-improvements branch. However, a
| careful review of the change before accepting it into silver found it
| to be incorrect.

And it was a very good thing that we had that review in public
"instantly", instead of waiting that it is published days later buried
with other changes.  The outcome of the review was a better
documentation of the relations between several components and
unwritten assumptions.  That is Good and that is why silver patches to
silver should be sent to the list and when applied made instantly
available to the community.


| >   (6) have more than just one maintainer.
| 
| There are 22 maintainers for Arch, 6 people with complete admin access
| on savannah, and 3 people (including yourself) with complete admin
| access on sourceforge.

But, by your very words, if the main source is not SF, then it is
pointless that you have three people with complete admin access to SF
-- whether that included me or not.  That is the point.  Don't just
count.  Count right.

| Ulitmately we differ on philosophy. I believe that each branch
| has one person ultimately responsible for that branch. The responsible
| person determines policy. 

We most certainly differ on philosophy. But obviously you don't see
exactly how we differ.  So, it probably is better when you speak for
your philosophy you don't attempt to denature mine.

I believe we need a stable branch (gold), and it should be made
available, live just as any other branches.  Made live means that
changes to that branch are immediately available to everybody; instead
of being kept secret and suddenly released to the world when time
permits. 
Made live does not imply that people makes applies changes willy nilly.

We should make sure that things are setup so that eventually, more
people understand the system, in particular gold and attain the point
where we don't just have one person on which everything depends.

\start
Date: Sat, 04 Nov 2006 11:09:28 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: ActiveAxiomDevelopers

Hello Waldek,

You are one of the most active developers currently. You should 
definitely put an entry on

http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers

\start
Date: 04 Nov 2006 11:09:27 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Maintainers

Tim Daly writes:

| > A single point of failure is when we have only one person
| > 
| >   (1) that has authority to approve and apply changes to the main source,
| >   (2) make official realeases.
| > 
| 
| That is a single point of control, not a single point of failure.

when the control fails to function properly, the development of system
fails to progress. By implication, the "point of control" is a "point
of failure".

[...]

| >    When that single person becomes unavailable temporarily or forever,
| >    the project is stalled.
| 
| I don't recall that everyone was required to stop development.

the availability of the newer version wwas delayed, and nobody else
could do it, because nobody else had the source.

| > Do you want to be remind you how late --patch-50 was?
| 
| And, indeed, life intervenes.

thanks God, nobody blames you for that.  But, it did happen.

As you mention build-improvements; let me point out that I would very
much like to see more people involved, capable of making changes to
the "right" directions so that I do not become a single point of failure.
So, in case you would be under the impression I would like a single
maintainership on build-improvements and question that of gold and
silver, be assure it is not the case.  I've repeated it enough.
And I hope we've gotten build-improvements out of the way.

| The project was not stalled though
| because I spent time getting a hundred copies of Axiom built and
| handed out at the ISSAC conference. The result of this time gained
| us (hopefully) access to Manuel's work and a few other connections
| to other people in our target audience. 

 "... gained us acceess to Manuel's work", in which form?

\start
Date: 04 Nov 2006 11:47:32 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Ralf Hemmecke writes:

| On 11/03/2006 10:22 PM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke writes:
| > | > I'm very happy to see Tim is making changes more visible now,
| > than waiting
| > | > for ages before seeing light. The main reason I originally volunteered to
| > | > maintain Silver is that I do believe in "live sources". Tim suggested
| > | > at the time that he did not have time do maintain too many branches.
| > | > It therefore was a natural thing for me to volunteer to take on the
| > | > job.  Now, if Tim has more time to do the job, I'm all for it.
| > | | > However, I see practical issue here:    (1) first, we should
| > not
| > | > have one single person as authority to
| > | >       commit changes.
| > | | We are speaking here _only_ of the changes that go to the next
| > Gold
| > | release.
| > we are talking of Silver, right?
| 
| Right. Gold=axiom--main--1 only gets patches every two months.
| The gold-to-be=axiom--silver--1 is the branch that Tim commits to in
| order to prepare the next gold.

That is the current situation as it has been set recently.  
I'm not sure that was the situation in April 2006 when we set up the
framework.  At the time, I believe there was something called silver
(and its implications), which is not what is currently called silver.  


| In my understanding we requested that in order to let axiom-developers
| see how the current gold gradually develops into the next gold. We all
| agreed that Tim commits to gold. Since now that thing is called
| axiom--silver--1 does not change that.

Yes, we all agreed that Tim commits to gold; yes.  
If gold is now called silver, what is gold?

[...]

| Gaby, could you post how you think Axiom development should work? (You
| should probably avoid the usage of Gold/silver/bronze.) Just post your
| dream. Where should be the main source? How many stages should be
| there before something is released? How is quality ensured? What
| _roles_ (not persons) should be responsible for what.


Ideally, I would like to see a *main common source tree* (call it
Trunk) from which everything develops.

On a regular bases, we branch off Trunk to make release branches.  For
example, we could decide that next Tuesday, we will branch off for
Axiom 4.1.0.  A release branch from Trunk will be created for that
purpose. That branch will have stricter rules for checking than for
Trunk.  For example, we would not fiddle with/upgrade GCL versions
there.  Only bug fixes will be applied to release branches.  After the
initial major release from that branch, we will be making minor
releases from there, say Axiom 4.1.3 that are only regression bug
fixes. (Ideally, we should not have regressions, but that happens only
in dream, especially with with impenetrable systems).

In parallel, Trunk develops its life.  Any bug fixes to release
branches (that also happen to be present on Trunk) must first be
tested on Trunk before being applied to a release branch.
Trunk is less restricted than release branches in the sense that it
contains "experimental" phases where more features are added [say we
have drag-n-drop, integration of ACL, SPAD understands dependent
types, or we get rid of ')abbrev' command to introduce types, or that
SPAD understands "extend" for extending domains, etc.]  This is
usually the time where development branches are merged to trunk.
Then, there should be a period where we make "pause" in the feature
accretion, stabilize for release purposes, then branch off for the
next major release (say 4.2.0).

People will create experimental branches from Trunk.  There are
well-defined rules about how an experimental branch gets merged to
Trunk.  No experimental branch gets merged to an existing release
branch. 

During the process, we should try to do everything possible to
increase the number of people that understands the system.  This
includes, better documentation.  Even those who understand the system
should justify their changes.  People should apply their patches
directly, instead of going through a single person.  The sources
should be immediately available. 
We should use less superstition, e.g. "don't touch because it
currently works."  Trunk should be open to move more aggressively in its
"experimental" phase.  Release branches, must be conservative.

Notice that in my model, no changes get merged to a release branch if
it is not a regression bug fix.  Any new functionality should appear
in the next major release.  Everything is publically available in a
lively fashion.  The most stable branch (to serve a release source)
and the main Trunk. 

To my mind, we can have many repo if that is felt necessary, but: only
one repo is the master, others are mirrors to simplify our lives.

Now, I understand that is not what we have; I'm trying to see how it
can be approximated and made to work.

\start
Date: Sat, 4 Nov 2006 12:59:35 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page wrote:
> I think the following two files are not used anywhere:
> 
> aTx=b.bitmap
> ATX=B.bitmap
> 
> (See list of unused bitmap files below.)
>

'aTx=b' is referenced from 'nag-f04.boot.pamphlet' (among others).
For ATX=B.bitmap you are probably right.
  
> > Also in 'src/doc/ps' we have 'SEGBIND.ps' and 'segbind.ps'.  
> > 'segbind.ps' is a screen dump of a graphic window containing a
> > parabola.  I can not really see 'SEGBIND.ps' because it triggers
> > Postscript stack error in ghostscript (like many other files in
> > 'src/doc/ps' :(.
> > 
> 
> I think all .ps files that are not referenced in any *.pamphlet file
> (such as SEGBIND.ps and segbind.ps) should be deleted from the /ps
> directory.
> 

ATM we use only few .ps files. However there are many commented out 
references in the axiom book, that is files we should use but
for some reason (problems with flat environment???) we do not use
them now. There is a lot of junk: files that do not show up in
ghostscript at all, files which probably have bogus boundig box,
duplicates. We can easily recreate graphs, screenshots need
more work to recreate and a few files (probably 2 or 3) are
"original artwork". In ideal world sombody would sort the
.ps files into "valuable" (needing some/lot of effort to recreate),
"cache" (the ones which we put in the distribution, but can
easily recreate) and junk. But in short term mass deletion
may be the best solution.


> Here is a quick hack to show which files in src/doc/ps are not
> used in any src/doc/*.pamphlet file:
> 
> $ cd /home/page/axiom.build-improvements/src/doc
> $ ls ps > ps_old
> $ grep 'ps/.*\.ps.*}' *.pamphlet | \
>   awk '{FS="ps/"; print substr($2,0,index($2,".ps")+2);}' | \
>   sort | uniq > ps_new
> $ diff --unified=0 ps_old ps_new | \
>   awk '/^-[^-]/ { print substr($1,2)}'
>

You missed '.eps' endinig: 
 
> P28a.eps

P28a.eps is very special, because it actually shows in the book :)

> Here is a similar hack for bitmaps:
> 

You missed references from the browser:

> s21bdf1.bitmap

This one is "used":

nag-s.boot.pamphlet:  htInitPage("S21BDF - Symmetrised Elliptic Integral of 3rd
Kind \space{1} \vspace{-28} \inputbitmap{\htbmdir{}/s21bdf1.bitmap}", nil)

I think that finding unused bitmaps need some more work: it seems that
some references to bitmaps appear without file suffix, also because of
quoting rules some names appear mangled.  OTOH I think it is safe bet
that browser do not access '.ps' files from 'src/doc/ps'. First, 
browser do not have support for showing '.ps' files, and while
ANNA-ES.ht contains (commented out) call to ghostscript it seem to be
the only case. Second, it seems that browser were supposed to access
only files from 'share' subtree and that files from 'src/doc/ps'
were not installed here.

\start
Date: Sat, 04 Nov 2006 08:25:33 -0400
From: Humberto Zuazaga
To: Bill Page
Subject: Re: Mac OS X 10.4.8 PowerPC success!

Bill Page wrote:

> You only show running the Axiom main console program AXIOMsys.
> How about the other parts of Axiom? If you type the command:
>
>   $ axiom

No, sman didn't build. Make stops on viewman:

21 finished making /Users/humberto/src/axiom-darcs/src/Gdraws
1 making /Users/humberto/src/axiom-darcs/src/graph/viewman
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DMACOSXplatform
      -I/usr/include -I/usr/include/sys -I/usr/X11R6/include
-I/Users/humberto/src/axiom-darcs/src/graph/include
-I/Users/humberto/src/axiom-darcs/src/include -I. -c -o sselect.o sselect=
=2Ec
sselect.c: In function 'superSelect':
sselect.c:94: error: 'SIGCLD' undeclared (first use in this function)
sselect.c:94: error: (Each undeclared identifier is reported only once
sselect.c:94: error: for each function it appears in.)
make[3]: *** [sselect.o] Error 1
make[2]: *** [viewman/stamp] Error 2
make[1]: *** [graph/stamp] Error 2
make: *** [all-recursive] Error 1

I haven't had time to look at the errors yet.

> Finally, would you be willing to post a tarball of the Axiom
> binaries distribution?

http://www.hpcf.upr.edu/~humberto/axiom-ppc-2006110301.tar.gz

\start
Date: Sat, 4 Nov 2006 15:59:22 +0100
From: Raymond Manzoni
To: Humberto Zuazaga
Subject: Re: Mac OS X 10.4.8 PowerPC success!

Le 4 nov. 06 =E0 13:25, Humberto Ortiz-Zuazaga a =E9crit :

> Bill Page wrote:
>
>> You only show running the Axiom main console program AXIOMsys.
>> How about the other parts of Axiom? If you type the command:
>>
>>   $ axiom
>
> No, sman didn't build. Make stops on viewman:
>
> 21 finished making /Users/humberto/src/axiom-darcs/src/Gdraws
> 1 making /Users/humberto/src/axiom-darcs/src/graph/viewman
> gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DMACOSXplatform
>       -I/usr/include -I/usr/include/sys -I/usr/X11R6/include
> -I/Users/humberto/src/axiom-darcs/src/graph/include
> -I/Users/humberto/src/axiom-darcs/src/include -I. -c -o sselect.o 
> sselect.c
> sselect.c: In function 'superSelect':
> sselect.c:94: error: 'SIGCLD' undeclared (first use in this function)
> sselect.c:94: error: (Each undeclared identifier is reported only once
> sselect.c:94: error: for each function it appears in.)
> make[3]: *** [sselect.o] Error 1
> make[2]: *** [viewman/stamp] Error 2
> make[1]: *** [graph/stamp] Error 2
> make: *** [all-recursive] Error 1
>
> I haven't had time to look at the errors yet.
>
>> Finally, would you be willing to post a tarball of the Axiom
>> binaries distribution?
>
> http://www.hpcf.upr.edu/~humberto/axiom-ppc-2006110301.tar.gz
>

	Hi Humberto,

	And thanks for providing this binary!
	My machine is a Dual G5 running OS X 10.4.8 (PPC build 8L127, =
Darwin 
Kernel Version 8.8.0, PowerMac7,2 Darwin similar to your 
configuration I think...)  and your binary worked here too!  Great!!


	In fact I tried earlier to repeat your manipulations to compile =
from 
source and could repeat the second part (use adacs to get axiom 
source and so on) but the first part (install gcl) didn't work here...

	The gcl generation ends (depending on paths and/or parameter) =
with 
either a gcl readline error :
gcl_readline.d: In function 'rl_completion':
gcl_readline.d:221: warning: implicit declaration of function 
'rl_completion_matches'
gcl_readline.d:221: error: 'rl_compentry_func_t' undeclared (first 
use in this function)
gcl_readline.d:221: error: (Each undeclared identifier is reported 
only once
gcl_readline.d:221: error: for each function it appears in.)
gcl_readline.d:221: error: parse error before ')' token

	or the more annoying tk problem :
/usr/bin/ld: warning -L: directory name (/sw/src/tcltk-8.4.6-2/
tk8.4.6/unix) does not exist
/usr/bin/ld: warning multiple definitions of symbol _tclPlatStubsPtr 
and others...
/usr/bin/ld: Undefined symbols:
_my_free
_my_malloc
	(at this point there was a usable saved_gcl but...)

	I did this (and some variants without --disable-nls or the =
export 
line and so on...) :

	Get a working gcl with CVS :
	export CVS_RSH=ssh
	export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
	cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl

	In gcl-2.6.8pre :
	- remove  -lintl  from the LIBS:= line of  =
h/powerpc-macosx.defs

  	export LIBRARY_PATH=`pwd`/binutils/intl
	./configure --enable-locbfd --disable-statsysbfd --disable-nls
	make=09

	With the results previously given...

	Do you see something inappropriate in the previous lines or =
could 
you give me the commands you used to successfully compile gcl on PPC?


	In any case many thanks again for your binary!
				Raymond

\start
Date: Sat, 4 Nov 2006 16:49:36 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: Maintainers

root wrote:
> > > Based on your extensive work would you consider being the
> > > person who maintains axiom--silver--1? That would settle
> > > one of the items raised by Gaby.
> > > 
> > 
> > Yes, however some clarificatinons are needed:
> > 
> > 1) ATM I work with SVN on SourceForge and I hope to avoid contact
> >    with arch
> 
> Arch holds the master sources, which get mirrored everywhere, into
> CVS on sourceforge and savannah, as well as SVN on sourceforge and
> google. If you're not willing to do this because of arch then that's 
> fine. I just thought that you were showing great initiative and might
> find it worthwhile to try. Handling multiple SCMs would be the least
> problem (currently axiom lives in arch, cvs, svn, and darcs).
> 
> The hard part is trying to figure out how to agree to things
> that you disagree with because other people have perfectly
> rational opinions. Working with arch is trivial. Working with
> people is hard. And among them I'm probably one of the most painful.
> 

Arch in itself is not big problem. But I belive that development
will take place in SVN and I prefer to be there. Also, I misunderstood
your message: my first impression was that you argeed with Gaby
critique and wanted to implement one of his proposals.

> > 2) "one of persons who maintain ..." -- IIUC Gaby wants to avoid
> >    single point of failure (me too).
> 
> How you maintain axiom--silver--1 would be up to you. Be aware
> that about 22 people have write access to silver at the moment.
> 
> I don't think "single point of failure" is a rational notion
> in terms of SCM. You or I could simply stop patching the code
> and the world would hardly notice since many people have write
> access.
> 

Maybe "single person bottleneck" is better term.  If key person
on a project say "I stop working on a project", this is bad but
the project has good chance to survive.  If key person is slow
responding ("I will do that next week", "Sorry, I forgot aboy this")
at first the effects look harmless, but this can easily kill
the project.


> It's a hard job and one that will put you in a position 
> of contention with people at times.
> 
> Think carefully about it and let me know.
> 

Tim, I have some experience managing software relases and have
my views what high quality means and how to attain it.  And
frankly, my views differ from current Axiom practice.  I thought
that your proposal is part of establishing new practice
-- I see now that I again misundrestood you.

\start
Date: Sat, 4 Nov 2006 17:01:29 +0100 (CET)
From: Waldek Hebisch
To: Raymond Manzoni
Subject: Re: Mac OS X 10.4.8 PowerPC success!

Raymond Manzoni wrote:
> 
> 
> 	In fact I tried earlier to repeat your manipulations to compile from  
> source and could repeat the second part (use adacs to get axiom  
> source and so on) but the first part (install gcl) didn't work here...
> 
> 	The gcl generation ends (depending on paths and/or parameter) with  
> either a gcl readline error :
> gcl_readline.d: In function 'rl_completion':
> gcl_readline.d:221: warning: implicit declaration of function  
> 'rl_completion_matches'
> gcl_readline.d:221: error: 'rl_compentry_func_t' undeclared (first  
> use in this function)
> gcl_readline.d:221: error: (Each undeclared identifier is reported  
> only once
> gcl_readline.d:221: error: for each function it appears in.)
> gcl_readline.d:221: error: parse error before ')' token
> 

You should be able to find explanation of you problem in Google. 
Yesterday searching (IIRC) for

readline BSD 

I have found message stating that Apple ships BSD 'libedit' library
which in partial (but incomplete) replacement for 'readline'.  What
is worse Apple istalls symbolic link from 'readline.dynlib' to
'libedit.dynlib' so that programs which want to use GNU 'readline'
end up using 'libedit' -- in many cases leading to errors like
above.  The message described what configure has to do to distingush
'libedit' from true 'readline', but I do not remember details.

\start
Date: Sat, 4 Nov 2006 12:44:31 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> On a regular bases, we branch off SILVER to make release branches.
> For example, we could decide that next Tuesday, we will branch off
> for Axiom 4.1.0.  A release branch from SILVER will be created for
> that purpose. That branch will have stricter rules for checking than
> for SILVER.  For example, we would not fiddle with/upgrade GCL
> versions there.  Only bug fixes will be applied to release branches
> (GOLD).  After the initial major release from that branch (GOLD), we
> will be making minor releases from there, say Axiom 4.1.3 that are
> only regression bug fixes. (Ideally, we should not have regressions,
> but that happens only in dream, especially with with impenetrable
> systems).


> In parallel, SILVER develops its life.  Any bug fixes to release
> branches (that also happen to be present on SILVER) must first be
> tested on SILVER before being applied to a release branch (GOLD).
> SILVER is less restricted than release branches in the sense that it
> contains "experimental" phases where more features are added [say we
> have drag-n-drop, integration of ACL, SPAD understands dependent
> types, or we get rid of ')abbrev' command to introduce types, or that
> SPAD understands "extend" for extending domains, etc.]  This is
> usually the time where development branches are merged to SILVER.
> Then, there should be a period where we make "pause" in the feature
> accretion, stabilize for release purposes, then branch off for the
> next major release (say 4.2.0) (GOLD).



> People will create experimental branches from SILVER.  There are
> well-defined rules about how an experimental branch gets merged to
> SILVER.  No experimental branch gets merged to an existing release
> branch. 



> During the process, we should try to do everything possible to
> increase the number of people that understands the system.  This
> includes, better documentation.  Even those who understand the system
> should justify their changes. 



> People should apply their patches directly, instead of going through
> a single person.  The sources should be immediately available.  We
> should use less superstition, e.g. "don't touch because it currently
> works."  SILVER should be open to move more aggressively in its
> "experimental" phase.  Release branches (GOLD), must be conservative.


> Notice that in my model, no changes get merged to a release branch
> if it is not a regression bug fix (GOLD).  Any new functionality
> should appear in the next major release SILVER.  Everything is
> publically available in a lively fashion.  The most stable branch
> (to serve a release source) and the main SILVER.
> 
> To my mind, we can have many repo if that is felt necessary, but: only
> one repo is the master (GOLD), others are mirrors to simplify our lives.



> Now, I understand that is not what we have; I'm trying to see how it
> can be approximated and made to work.





I made a minor name-edit to your text to reflect my understanding
of the current situation. s/trunk/silver/ and s/release/gold/

It seems your model differs from the current model in only one
truly essential aspect. You feel that I'm a bottleneck and that
Axiom cannot develop properly if a single person is in charge
of the final version. You feel that this limits what people can do
and that I'm holding back Axiom development. You feel that such a
centralized "point of failure" cannot work.

Linux is developed with this same centralized model.
Linus controls all of the things that get accepted, essentially GOLD.
Andrew Morton controls his version of the kernel, essentially SILVER.
Linus and Andrew are both "points of failure". Indeed Linus is 
regularly flamed on the kernel mailing list for his decisions
(e.g. to use BitKeeper, to write GIT, to reject ReiserFS, etc).
It is stated regularly that he's holding back Linux, that he's
a control freak, that he's arbitrary and misguided and that the
central model of development cannot work. Axiom uses the same
model and you're making the same arguments.





Gaby, at this point we've raised every question and answer.
What remains unsettled is my role in the development process.

I'd like to hear from the other people lurking on this list.
What is your opinion. Try to speak freely and clearly.
My feelings will not be hurt so don't mince words.

\start
Date: Sat, 04 Nov 2006 13:56:55 -0400
From: Humberto Zuazaga
To: Raymond Manzoni Raymond Manzoni
Subject: Re: Mac OS X 10.4.8 PowerPC success!

Raymond Manzoni wrote:
>     And thanks for providing this binary!
>     My machine is a Dual G5 running OS X 10.4.8 (PPC build 8L127, Darwi=
n
> Kernel Version 8.8.0, PowerMac7,2 Darwin similar to your configuration =
I
> think...)  and your binary worked here too!  Great!!

Good.

>     The gcl generation ends (depending on paths and/or parameter) with
> either a gcl readline error :
> gcl_readline.d: In function 'rl_completion':
> gcl_readline.d:221: warning: implicit declaration of function
> 'rl_completion_matches'
> gcl_readline.d:221: error: 'rl_compentry_func_t' undeclared (first use
> in this function)
> gcl_readline.d:221: error: (Each undeclared identifier is reported only=

> once
> gcl_readline.d:221: error: for each function it appears in.)
> gcl_readline.d:221: error: parse error before ')' token
>
>     or the more annoying tk problem :
> /usr/bin/ld: warning -L: directory name
> (/sw/src/tcltk-8.4.6-2/tk8.4.6/unix) does not exist
> /usr/bin/ld: warning multiple definitions of symbol _tclPlatStubsPtr an=
d
> others...
> /usr/bin/ld: Undefined symbols:
> _my_free
> _my_malloc

I think these are both symptoms of the gcl configure picking up packages
from fink (/sw/bin, /sw/lib, ...) and having the compile break.


>     export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
>     cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
>
>     In gcl-2.6.8pre :
>     - remove  -lintl  from the LIBS:= line of  h/powerpc-macosx.defs
>
>      export LIBRARY_PATH=`pwd`/binutils/intl

You don't need that anymore if you patch, as we won't use libintl anymore=
=2E

I manipulated my PATH to remove /sw/bin and similar, so gcl's configure
doesn't see the fink tcl/Tk, I think you can pass some kind of configure
option to gcl to do the same thing, but I kept having wierd problems
until I changed the PATH.

In any case, I used fink's latex and pdflatex for the gcl documentation
build, so you could try something like:

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin
=2E/configure --enable-locbfd --disable-statsysbfd --disable-nls

all on one line. Good luck.

\start
Date: Sat, 4 Nov 2006 13:23:57 -0500
From: Tim Daly
To: Raymond Manzoni
Subject: Re: Mac OS X 10.4.8 PowerPC success!

> > http://www.hpcf.upr.edu/~humberto/axiom-ppc-2006110301.tar.gz
> >
> 
> 	Hi Humberto,
> 
> 	And thanks for providing this binary!
> 	My machine is a Dual G5 running OS X 10.4.8 (PPC build 8L127, Darwin  
> Kernel Version 8.8.0, PowerMac7,2 Darwin similar to your  
> configuration I think...)  and your binary worked here too!  Great!!

Unfortunately this does not work for me. I get:

dyld: Library not loaded: /usr/X11R6/lib/libSM.6.dylib
 Referenced from: /private/var/root/axiom50/powerpc-apple-darwin8.8.0/bin/./AXIOMsys
 Reason: image not found

\start
Date: 04 Nov 2006 19:35:16 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Tim Daly writes:

| > On a regular bases, we branch off SILVER to make release branches.
| > For example, we could decide that next Tuesday, we will branch off
| > for Axiom 4.1.0.  A release branch from SILVER will be created for
| > that purpose. That branch will have stricter rules for checking than
| > for SILVER.  For example, we would not fiddle with/upgrade GCL
| > versions there.  Only bug fixes will be applied to release branches
| > (GOLD).  After the initial major release from that branch (GOLD), we
| > will be making minor releases from there, say Axiom 4.1.3 that are
| > only regression bug fixes. (Ideally, we should not have regressions,
| > but that happens only in dream, especially with with impenetrable
| > systems).
| 
| 
| > In parallel, SILVER develops its life.  Any bug fixes to release
| > branches (that also happen to be present on SILVER) must first be
| > tested on SILVER before being applied to a release branch (GOLD).
| > SILVER is less restricted than release branches in the sense that it
| > contains "experimental" phases where more features are added [say we
| > have drag-n-drop, integration of ACL, SPAD understands dependent
| > types, or we get rid of ')abbrev' command to introduce types, or that
| > SPAD understands "extend" for extending domains, etc.]  This is
| > usually the time where development branches are merged to SILVER.
| > Then, there should be a period where we make "pause" in the feature
| > accretion, stabilize for release purposes, then branch off for the
| > next major release (say 4.2.0) (GOLD).
| 
| 
| 
| > People will create experimental branches from SILVER.  There are
| > well-defined rules about how an experimental branch gets merged to
| > SILVER.  No experimental branch gets merged to an existing release
| > branch. 
| 
| 
| 
| > During the process, we should try to do everything possible to
| > increase the number of people that understands the system.  This
| > includes, better documentation.  Even those who understand the system
| > should justify their changes. 
| 
| 
| 
| > People should apply their patches directly, instead of going through
| > a single person.  The sources should be immediately available.  We
| > should use less superstition, e.g. "don't touch because it currently
| > works."  SILVER should be open to move more aggressively in its
| > "experimental" phase.  Release branches (GOLD), must be conservative.
| 
| 
| > Notice that in my model, no changes get merged to a release branch
| > if it is not a regression bug fix (GOLD).  Any new functionality
| > should appear in the next major release SILVER.  Everything is
| > publically available in a lively fashion.  The most stable branch
| > (to serve a release source) and the main SILVER.
| > 
| > To my mind, we can have many repo if that is felt necessary, but: only
| > one repo is the master (GOLD), others are mirrors to simplify our lives.
| 
| 
| 
| > Now, I understand that is not what we have; I'm trying to see how it
| > can be approximated and made to work.
| 
| 
| 
| 
| 
| I made a minor name-edit to your text to reflect my understanding
| of the current situation. s/trunk/silver/ and s/release/gold/
| 
| It seems your model differs from the current model in only one
| truly essential aspect. You feel that I'm a bottleneck and that
| Axiom cannot develop properly if a single person is in charge
| of the final version. 

I believe your edit probably reflects your ideas, but I do not believe
you represented the differences in our approaches correctly, in particular
I believe it is a mischaracterization to think the essential
difference is being you in charge of the release branches.
Consequently, let me go over again, before going on family life.

The model I presented, and your edits do not reflect existing
practice.  Notice that in my model, release branches are made from
Trunk (your SILVER) on a *regular basis* to make a new major release.
After that, the release branches continue their lives as minor release
for regression bug fixes only.  That is not the current model.

In my model, the Trunk (yoru SILVER) has phases were it is more
experimental and more aggressive in capabilities.  After such an
experimental phase, it goes into stabilization, then branch for a new
major release.

In my model, all branches, including release and Trunk are "live".

Try to work out those points.  If you believe you agree with them, we
wouold have agreed on the essential aspects.  And we would have made a
major change.  

But, please, refrain your presenting the essential differences as you
just did.  

Don't base decisions on mischaracterizations.

\start
Date: Sat, 04 Nov 2006 14:40:09 -0400
From: Humberto Zuazaga
To: list
Subject: viewman and hyper on Mac OS X

I patched src/graph/sselect.c.pamphlet (well, first I patched the .c
file, but I wised up before mailing the patch, shouldn't notangle mangle
line numbers in C sources so they point at the pamphlets?)

I guess Macs have BSD style signals:

Sat Nov  4 14:32:19 GMT+4 2006  Humberto Ortiz-Zuazaga
Humberto Zuazaga
  * mac-sselect
diff -rN -u old-axiom-darcs/src/graph/viewman/sselect.c.pamphlet
new-axiom-darcs/src/graph/viewman/sselect.c.pamphlet
--- old-axiom-darcs/src/graph/viewman/sselect.c.pamphlet
2006-11-04 14:34:48.000000000 -0400
+++ new-axiom-darcs/src/graph/viewman/sselect.c.pamphlet
2006-11-04 14:34:49.000000000 -0400
@@ -104,7 +104,7 @@
        /* flush(spadSock); */
         /* send_int(spadSock,1);   acknowledge to spad */
         checkClosedChild = no;
-#if defined(BSDplatform)
+#if defined(BSDplatform) || defined(MACOSXplatform)
         bsdSignal(SIGCHLD,endChild,DontRestartSystemCalls);
 #else
         bsdSignal(SIGCLD,endChild,DontRestartSystemCalls);


and viewman now compiles. Next problem is hyper, the Mac doesn't have
regexp.h:


Sat Nov  4 14:06:48 GMT+4 2006  Humberto Ortiz-Zuazaga
Humberto Zuazaga
  * regex-mac
diff -rN -u old-axiom-darcs/src/hyper/hthits.pamphlet
new-axiom-darcs/src/hyper/hthits.pamphlet
--- old-axiom-darcs/src/hyper/hthits.pamphlet   2006-11-04
14:23:58.000000000 -0400
+++ new-axiom-darcs/src/hyper/hthits.pamphlet   2006-11-04
14:23:59.000000000 -0400
@@ -71,7 +71,12 @@
 /* AIX3 regexp.h includes NLregexp which we don't want */
 #undef _XOPEN_SOURCE
 #endif
+#if !defined(MACOSXplatform)
+/* Mac OS X doesn't have regexp.h */
 # include <regexp.h>
+#else
+#include <regex.h>
+#endif

 /*
  * Global variables set according to the command line.

Hyper still fails to build:

13 making /Users/humberto/src/axiom-darcs/src/hyper
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DMACOSXplatform
      -I/usr/include -I/usr/include/sys
-I/Users/humberto/src/axiom-darcs/src/include -I. -I/usr/X11R6/include
  -c -o hthits.o hthits.c
hthits.c: In function 'main':
hthits.c:121: warning: implicit declaration of function 'compile'
hthits.c: In function 'searchPage':
hthits.c:365: warning: implicit declaration of function 'step'
hthits.c:368: error: 'loc2' undeclared (first use in this function)
hthits.c:368: error: (Each undeclared identifier is reported only once
hthits.c:368: error: for each function it appears in.)
make[2]: *** [hthits.o] Error 1
make[1]: *** [hyper/stamp] Error 2
make: *** [all-recursive] Error 1

I can't figure out what loc2 is supposed to be, I can't see any
definition in any of the other pamphlets in the hyper directory.

\start
Date: Sat, 04 Nov 2006 14:51:08 -0400
From: Humberto Zuazaga
To: Tim Daly
Subject: Re: Mac OS X 10.4.8 PowerPC success!

root wrote:
>>> http://www.hpcf.upr.edu/~humberto/axiom-ppc-2006110301.tar.gz
>>>
>> 	Hi Humberto,
>>
>> 	And thanks for providing this binary!
>> 	My machine is a Dual G5 running OS X 10.4.8 (PPC build 8L127, Darwin =

>> Kernel Version 8.8.0, PowerMac7,2 Darwin similar to your 
>> configuration I think...)  and your binary worked here too!  Great!!
>
> Unfortunately this does not work for me. I get:
>
> dyld: Library not loaded: /usr/X11R6/lib/libSM.6.dylib
>  Referenced from: /private/var/root/axiom50/powerpc-apple-darwin8.8.0/b=
in/./AXIOMsys
>  Reason: image not found
>
> Tim

AXIOMsys doesn't need X support does it? I'm going to try to rebuild gcl
without X support and build a new axiom from it. Is there an equivalent
to the linux ldd command on Mac OS? On linux, ldd lists out the dynamic
libraries used by a program.

I think there is another solution, in XCode, I can specify what kind of
project to build, and one of the options is (I think) a binary that is
compatible with OS X 10.2 or later (I don't know if it's static or uses
compatibility libraries). It may be possible to pass flags to the
command line tools to achieve the same thing. I'll ask around

\start
Date: Sat, 4 Nov 2006 13:48:46 -0500
From: Tim Daly
To: Humberto Zuazaga
Subject: Re: Mac OS X 10.4.8 PowerPC success!

> AXIOMsys doesn't need X support does it? I'm going to try to rebuild gcl
> without X support and build a new axiom from it. Is there an equivalent
> to the linux ldd command on Mac OS? On linux, ldd lists out the dynamic
> libraries used by a program.

AXIOMsys is just a pure lisp image and only requires a command line.

> I think there is another solution, in XCode, I can specify what kind of
> project to build, and one of the options is (I think) a binary that is
> compatible with OS X 10.2 or later (I don't know if it's static or uses
> compatibility libraries). It may be possible to pass flags to the
> command line tools to achieve the same thing. I'll ask around

I really can't say. I'm not well versed in using a MAC for development.

\start
Date: Sat, 04 Nov 2006 15:08:53 -0400
From: Humberto Zuazaga
To: Humberto Zuazaga
Subject: Re: Mac OS X 10.4.8 PowerPC success!

Humberto Ortiz-Zuazaga wrote:
> root wrote:
>>>> http://www.hpcf.upr.edu/~humberto/axiom-ppc-2006110301.tar.gz
>>>>
>>> 	Hi Humberto,
>>>
>>> 	And thanks for providing this binary!
>>> 	My machine is a Dual G5 running OS X 10.4.8 (PPC build 8L127, Darwin=
 
>>> Kernel Version 8.8.0, PowerMac7,2 Darwin similar to your 
>>> configuration I think...)  and your binary worked here too!  Great!!
>> Unfortunately this does not work for me. I get:
>>
>> dyld: Library not loaded: /usr/X11R6/lib/libSM.6.dylib
>>  Referenced from: /private/var/root/axiom50/powerpc-apple-darwin8.8.0/=
bin/./AXIOMsys
>>  Reason: image not found
>>
>> Tim
>
> AXIOMsys doesn't need X support does it? I'm going to try to rebuild gc=
l
> without X support and build a new axiom from it. Is there an equivalent=

> to the linux ldd command on Mac OS? On linux, ldd lists out the dynamic=

> libraries used by a program.
>
> I think there is another solution, in XCode, I can specify what kind of=

> project to build, and one of the options is (I think) a binary that is
> compatible with OS X 10.2 or later (I don't know if it's static or uses=

> compatibility libraries). It may be possible to pass flags to the
> command line tools to achieve the same thing. I'll ask around
>
>
>
> -----------------------------------------------------------------------=
-
>
> _______________________________________________
> Axiom-developer mailing list
> list
> http://lists.nongnu.org/mailman/listinfo/axiom-developer

Well, here's the old AXIOMsys:

neverblows:~/src/working humberto$ strings
=2E./axiom-darcs/target/powerpc-apple-darwin8.8.0/bin/AXIOMsys |grep '\.d=
ylib'
/usr/X11R6/lib/libXt.6.dylib
/usr/X11R6/lib/libXmu.6.dylib
/usr/X11R6/lib/libSM.6.dylib
/usr/X11R6/lib/libXaw.7.dylib
/usr/X11R6/lib/libX11.6.dylib
/usr/lib/libSystem.B.dylib
/usr/X11R6/lib/libICE.6.dylib
/usr/lib/libedit.2.dylib
/usr/X11R6/lib/libSM.6.dylib
/usr/X11R6/lib/libXext.6.dylib
/usr/X11R6/lib/libXext.6.dylib
/usr/X11R6/lib/libXt.6.dylib
/usr/X11R6/lib/libXmu.6.dylib
/usr/X11R6/lib/libICE.6.dylib
/usr/lib/libedit.2.dylib
/usr/lib/libSystem.B.dylib
/usr/X11R6/lib/libX11.6.dylib
/usr/X11R6/lib/libXaw.7.dylib

and here's the new gcl I just built:

neverblows:~/src/working humberto$ strings unixport/saved_gcl |grep
'\.dylib'
/usr/lib/libedit.2.dylib
/usr/lib/libSystem.B.dylib

Hopefully, the AXIOMsys I built with this gcl will work.

http://www.hpcf.upr.edu/~humberto/axiom-ppc-2006110401.tar.gz

The configure invocation for GCL is:

  552  PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin=

  555  make clean
  556  ./configure --prefix=/usr/local  --enable-locbfd
--disable-statsysbfd --disable-nls --disable-xgcl --disable-x
  557  PATH=$PATH:/sw/bin
  558  make

\start
Date: Sat, 4 Nov 2006 20:08:32 +0100 (CET)
From: Waldek Hebisch
To: Humberto Zuazaga
Subject: Re: viewman and hyper on Mac OS X

Humberto Ortiz-Zuazaga wrote:
> Sat Nov  4 14:06:48 GMT+4 2006  Humberto Ortiz-Zuazaga
> Humberto Zuazaga
>   * regex-mac
> diff -rN -u old-axiom-darcs/src/hyper/hthits.pamphlet
> new-axiom-darcs/src/hyper/hthits.pamphlet
> --- old-axiom-darcs/src/hyper/hthits.pamphlet   2006-11-04
> 14:23:58.000000000 -0400
> +++ new-axiom-darcs/src/hyper/hthits.pamphlet   2006-11-04
> 14:23:59.000000000 -0400
> @@ -71,7 +71,12 @@
>  /* AIX3 regexp.h includes NLregexp which we don't want */
>  #undef _XOPEN_SOURCE
>  #endif
> +#if !defined(MACOSXplatform)
> +/* Mac OS X doesn't have regexp.h */
>  # include <regexp.h>
> +#else
> +#include <regex.h>
> +#endif
> 
>  /*
>   * Global variables set according to the command line.
> 
> Hyper still fails to build:
> 
> 13 making /Users/humberto/src/axiom-darcs/src/hyper
> gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DMACOSXplatform
>       -I/usr/include -I/usr/include/sys
> -I/Users/humberto/src/axiom-darcs/src/include -I. -I/usr/X11R6/include
>   -c -o hthits.o hthits.c
> hthits.c: In function 'main':
> hthits.c:121: warning: implicit declaration of function 'compile'
> hthits.c: In function 'searchPage':
> hthits.c:365: warning: implicit declaration of function 'step'
> hthits.c:368: error: 'loc2' undeclared (first use in this function)
> hthits.c:368: error: (Each undeclared identifier is reported only once
> hthits.c:368: error: for each function it appears in.)
> make[2]: *** [hthits.o] Error 1
> make[1]: *** [hyper/stamp] Error 2
> make: *** [all-recursive] Error 1
> 
> I can't figure out what loc2 is supposed to be, I can't see any
> definition in any of the other pamphlets in the hyper directory.
> 

regex.h is not a plug-in replacemnt for regexp.h -- the headers are
incompatible.  In prarticular regexp.h declares functions 'compile',
'step' and variable 'loc2' while interface exported by 'regex.h'
is quite different.

AFAICS we should rewrite hthits.c to use regex.h on all platforms,
but this slightly more then changing include line.

\start
Date: Sat, 4 Nov 2006 14:05:52 -0500
From: Tim Daly
To: Humberto Zuazaga
Subject: Re: viewman and hyper on Mac OS X

This patch has been added to silver. 
I'm not sure about the hyper changes. 
I need to investigate further.

> Sat Nov  4 14:32:19 GMT+4 2006  Humberto Ortiz-Zuazaga
> Humberto Zuazaga
>   * mac-sselect
> diff -rN -u old-axiom-darcs/src/graph/viewman/sselect.c.pamphlet
> new-axiom-darcs/src/graph/viewman/sselect.c.pamphlet
> --- old-axiom-darcs/src/graph/viewman/sselect.c.pamphlet
> 2006-11-04 14:34:48.000000000 -0400
> +++ new-axiom-darcs/src/graph/viewman/sselect.c.pamphlet
> 2006-11-04 14:34:49.000000000 -0400
> @@ -104,7 +104,7 @@
>         /* flush(spadSock); */
>          /* send_int(spadSock,1);   acknowledge to spad */
>          checkClosedChild = no;
> -#if defined(BSDplatform)
> +#if defined(BSDplatform) || defined(MACOSXplatform)
>          bsdSignal(SIGCHLD,endChild,DontRestartSystemCalls);
>  #else
>          bsdSignal(SIGCLD,endChild,DontRestartSystemCalls);

\start
Date: Sat, 4 Nov 2006 21:02:22 +0100 (CET)
From: Waldek Hebisch
To: Humberto Zuazaga
Subject: Re: viewman and hyper on Mac OS X

Humberto Ortiz-Zuazaga wrote:
> and viewman now compiles. Next problem is hyper, the Mac doesn't have
> regexp.h:
> 

> Hyper still fails to build:
> 
> 13 making /Users/humberto/src/axiom-darcs/src/hyper
> gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DMACOSXplatform
>       -I/usr/include -I/usr/include/sys
> -I/Users/humberto/src/axiom-darcs/src/include -I. -I/usr/X11R6/include
>   -c -o hthits.o hthits.c
> hthits.c: In function 'main':
> hthits.c:121: warning: implicit declaration of function 'compile'

The patch below converts hthits to use 'regexp.h'.  The <sys/types.h>
include is correct on Linux, but may need adjustment on Mac.

diff -u build-improvements.pp/src/hyper/hthits.pamphlet build-improvements/src/hyper/hthits.pamphlet
--- build-improvements.pp/src/hyper/hthits.pamphlet	2006-11-02 18:27:40.000000000 +0100
+++ build-improvements/src/hyper/hthits.pamphlet	2006-11-04 21:44:43.926067992 +0100
@@ -53,25 +53,8 @@
 
 #include "hthits.H1"
 
-
-
-/*
- * Things for the regular expression scanning.
- */
-char expbuf[MAX_COMP_REGEX];
-
-#define INIT      register char *sp = instring;
-#define GETC()    (*sp++)
-#define PEEKC()   (*sp)
-#define UNGETC(c) (--sp)
-#define RETURN(c) return(c);
-#define ERROR(c)  regerr(c);
-
-#if defined(RIOSplatform) && !defined(_AIX41) && defined(_XOPEN_SOURCE) 
-/* AIX3 regexp.h includes NLregexp which we don't want */
-#undef _XOPEN_SOURCE
-#endif
-# include <regexp.h>
+#include <sys/types.h>
+#include <regex.h>
 
 /*
  * Global variables set according to the command line.
@@ -81,6 +64,7 @@
 char *pattern;
 char *htdbFName;
 int gverifydates=0;
+regex_t reg_pattern;
 
 int
 #ifdef _NO_PROTO
@@ -93,7 +77,7 @@
 {
     cmdline(argc, argv);
 
-    compile(pattern, expbuf, expbuf + MAX_COMP_REGEX, '\0');
+    regcomp(&reg_pattern, pattern, REG_NEWLINE);
 
     handleHtdb();
     return(0);
@@ -335,13 +319,17 @@
 #endif
 {
     char *bodyrest;
+    regmatch_t match_pos;
     int nhits = 0;
 
-    if (step(pgtitle, expbuf))
+    if (!regexec(&reg_pattern, pgtitle, 1, &match_pos, 0)) 
         nhits++;
 
-    for (bodyrest = pgbody; step(bodyrest, expbuf); bodyrest = loc2)
+    for (bodyrest = pgbody; 
+        !regexec(&reg_pattern, bodyrest, 1, &match_pos, 0);) {
         nhits++;
+        bodyrest += match_pos.rm_eo;
+    }
     if (nhits) {
         printf("\\newsearchresultentry{%d}{%s}",nhits, pgtitle);
         squirt(pgname, strlen(pgname));

\start
Date: Sat, 04 Nov 2006 16:49:08 -0400
From: Humberto Zuazaga
To: Waldek Hebisch
Subject: Re: viewman and hyper on Mac OS X

Waldek Hebisch wrote:
> Humberto Ortiz-Zuazaga wrote:
>> and viewman now compiles. Next problem is hyper, the Mac doesn't have
>> regexp.h:

> The patch below converts hthits to use 'regexp.h'.  The <sys/types.h>
> include is correct on Linux, but may need adjustment on Mac.

Thanks Waldek, that patch worked perfectly. Now that's what I call
distributed development, you're writing code for a system you don't even
have :-).

axiom is now processing a bunch of input files like:

p:POLY PF 7 :=6*x +6*y +6*z +x^49+y^49+z^49


         49         49         49
   (1)  z   + 6z + y   + 6y + x   + 6x
                                                Type: Polynomial
PrimeField 7
factor p

I'm waiting for it to finish to upload another tarball, with sman and
hypertex and the other tools.

\start
Date: Sat, 4 Nov 2006 22:35:19 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: configure.ac.pamphlet

configure.ac.pamphlet contains the following:

    *darwin*)
        PLF=MACOSXplatform
        CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} \
            -I/usr/include -I/usr/include/sys"
        GCLOPTS="--enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-locbfd \
            --disable-statsysbfd  --enable-custreloc --disable-tkconfig \
            --enable-machine=pwerpc-macosx"
        ;;
                             ^^^^^^^^^^^^^

This look wrong on two accounts: 
1) standard name is 'powerpc-macosx'
2) seem to ignore Intel Macs

\start
Date: Sat, 04 Nov 2006 18:44:15 -0400
From: Humberto Zuazaga
To: list
Subject: Re: configure.ac.pamphlet

Waldek Hebisch wrote:
> configure.ac.pamphlet contains the following:
>
>     *darwin*)
>         PLF=MACOSXplatform
>         CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} \
>             -I/usr/include -I/usr/include/sys"
>         GCLOPTS="--enable-vssize=65536*2 --enable-maxpage=256*102=
4 --disable-locbfd \
>             --disable-statsysbfd  --enable-custreloc --disable-tkconfig=
 \
>             --enable-machine=pwerpc-macosx"
>         ;;
>                              ^^^^^^^^^^^^^
>
> This look wrong on two accounts:
> 1) standard name is 'powerpc-macosx'
> 2) seem to ignore Intel Macs
>

There still isn't a working gcl for Intel Mac OS X, I started mangling
the source to support "--enable-machine=i386-macosx", but it's still no=
t
working. Configure thinks my mac is "i686-apple-darwin8.8.1", as opposed
to the G5 which is "powerpc-apple-darwin8.8.0". I don't think there will
ever be a i386 Apple Mac, so we may as well decide to call the machine
"i686-macosx" instead.

I think we should use "--disable-statsysbfd --enable-locbfd --disable-x
--disable-xgcl --disable-nls", those are the flags I used on the
external gcl I have that built axiom sucessfully. The
"--disable-tkconfig" should help with the Tcl/Tk issues we've been
having. What are the memory and custreloc flags for?

\start
Date: Sun, 5 Nov 2006 02:01:32 +0100
From: Raymond Manzoni
To: Humberto Zuazaga
Subject: Re: Mac OS X 10.4.8 PowerPC success!

> Raymond Manzoni wrote:
>>     And thanks for providing this binary!
>>     My machine is a Dual G5 running OS X 10.4.8 (PPC build 8L127, 
>> Darwin
>> Kernel Version 8.8.0, PowerMac7,2 Darwin similar to your 
>> configuration I
>> think...)  and your binary worked here too!  Great!!
>
> Good.
>
>>     The gcl generation ends (depending on paths and/or parameter) 
>> with
>> either a gcl readline error :
>> gcl_readline.d: In function 'rl_completion':
>> gcl_readline.d:221: warning: implicit declaration of function
>> 'rl_completion_matches'
>> gcl_readline.d:221: error: 'rl_compentry_func_t' undeclared (first =

>> use
>> in this function)
>> gcl_readline.d:221: error: (Each undeclared identifier is reported =

>> only
>> once
>> gcl_readline.d:221: error: for each function it appears in.)
>> gcl_readline.d:221: error: parse error before ')' token
>>
>>     or the more annoying tk problem :
>> /usr/bin/ld: warning -L: directory name
>> (/sw/src/tcltk-8.4.6-2/tk8.4.6/unix) does not exist
>> /usr/bin/ld: warning multiple definitions of symbol 
>> _tclPlatStubsPtr and
>> others...
>> /usr/bin/ld: Undefined symbols:
>> _my_free
>> _my_malloc
>
> I think these are both symptoms of the gcl configure picking up 
> packages
> from fink (/sw/bin, /sw/lib, ...) and having the compile break.
>
>
>>     export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
>>     cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
>>
>>     In gcl-2.6.8pre :
>>     - remove  -lintl  from the LIBS:= line of  =
h/powerpc-macosx.defs
>>
>>      export LIBRARY_PATH=`pwd`/binutils/intl
>
> You don't need that anymore if you patch, as we won't use libintl 
> anymore.
>
> I manipulated my PATH to remove /sw/bin and similar, so gcl's 
> configure
> doesn't see the fink tcl/Tk, I think you can pass some kind of 
> configure
> option to gcl to do the same thing, but I kept having wierd problems
> until I changed the PATH.
>
> In any case, I used fink's latex and pdflatex for the gcl 
> documentation
> build, so you could try something like:
>
> PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin
> ./configure --enable-locbfd --disable-statsysbfd --disable-nls
>

	Thanks for the trick of isolating Fink (/sw/... by default) and =

DarwinPort (/opt/local/...).
	It worked indeed with exactly these instructions!
	I just added two symbolic links in /usr/local/bin : the first =
since 
pdflatex was needed for completion of the make and the second 
(optional) for .dvi generation of the make install :

cd /usr/local/bin	=09
ln -s /sw/bin/pdflatex pdflatex
ln -s /sw/bin/tex tex

	make
	sudo make install

	installed gcl so that I could start the (very long...) axiom 
compilation (NRLIBS generation)

	I got the SIGCLD errors and applied your corrections :

in sselect.c.pamphlet and viewman.c.pamphlet replace :
#if defined(BSDplatform)
by
#if defined(BSDplatform) || defined(MACOSXplatform)

	I got stuck with the hyper problem :
13 making /Users/raym/Desktop/dev/axio/axiom/src/hyper
make[2]: *** No rule to make target `addfile.pamphlet', needed by 
`addfile.h'.  Stop.
make[1]: *** [hyper/stamp] Error 2
make: *** [all-recursive] Error 1
	I fear there is an order problem here since the hthits.pamphlet =

doesn't exist in the 'hyper' folder at this point (as opposed to the 
older axiom projects I have).

	I'll stop here (it's late in France).

	Thanks again for the help (I don't forget Tim, Bill, Aurelien =
and 
many others!)

\start
Date: Sat, 04 Nov 2006 21:37:52 -0400
From: Humberto Zuazaga
To: list
Subject: Tarball for Mac OS X

With Waldek's latest patches it looks like the build completed. I've put
a tarball up:

http://www.hpcf.upr.edu/~humberto/axiom-ppc-2006110402.tar.gz

but I'm pretty sure something's broken. xlogo works from the PPC to my
home, but HyperDoc can't connect to the X server:

ptyopen: Failed to open /dev/ptmx: No such file or directory
ptyopen failed: No such file or directory
(HyperDoc) Cannot connect to the X11 server!

Sorry, I have to check if darcs overwrote the openpty patches.

\start
Date: Sat, 4 Nov 2006 21:06:08 -0500
From: Tim Daly
To: Humberto Zuazaga
Subject: Re: Tarball for Mac OS X

I downloaded your latest version

http://www.hpcf.upr.edu/~humberto/axiom-ppc-2006110402.tar.gz

but don't know how to set the AXIOM variable.

\start
Date: Sat, 04 Nov 2006 22:54:42 -0400
From: Humberto Zuazaga
To: Tim Daly
Subject: Re: Tarball for Mac OS X

root wrote:
> I downloaded your latest version
>
> http://www.hpcf.upr.edu/~humberto/axiom-ppc-2006110402.tar.gz
>
> but don't know how to set the AXIOM variable.
>
> t

The tarfile contains the powerpc-apple-darwin8.8.0 directory that should
be the target of the AXIOM variable:

tar zxf axiom-ppc-2006110402.tar.gz
export AXIOM=`pwd`/powerpc-apple-darwin8.8.0
PATH=$AXIOM/bin:$PATH
AXIOMsys

should work at least on PowerPC Mac OS X 10.4 systems.

\start
Date: Sat, 4 Nov 2006 21:55:03 -0500
From: Tim Daly
To: Humberto Zuazaga
Subject: Re: Tarball for Mac OS X

> > I downloaded your latest version
> > 
> > http://www.hpcf.upr.edu/~humberto/axiom-ppc-2006110402.tar.gz
> > 
> > but don't know how to set the AXIOM variable.
> 
> The tarfile contains the powerpc-apple-darwin8.8.0 directory that should
> be the target of the AXIOM variable:
> 
> tar zxf axiom-ppc-2006110402.tar.gz
> export AXIOM=`pwd`/powerpc-apple-darwin8.8.0
> PATH=$AXIOM/bin:$PATH
> AXIOMsys
> 
> should work at least on PowerPC Mac OS X 10.4 systems.

Nope. Fails for me. 

AXIOMsys
Error: Caught fatal error

\start
Date: Sat, 4 Nov 2006 22:10:41 -0500
From: Alfredo Portes
To: Humberto Zuazaga
Subject: Re: Tarball for Mac OS X

Hi Humberto,

> The tarfile contains the powerpc-apple-darwin8.8.0 directory that should
> be the target of the AXIOM variable:
>
> tar zxf axiom-ppc-2006110402.tar.gz
> export AXIOM=`pwd`/powerpc-apple-darwin8.8.0
> PATH=$AXIOM/bin:$PATH
> AXIOMsys
>
> should work at least on PowerPC Mac OS X 10.4 systems.

Maybe you can write the instructions down to build on MAC PPC on the wiki.

Maybe in here (Bill can probably say a better location):

http://wiki.axiom-developer.org/BuildAxiom

\start
Date: 05 Nov 2006 04:21:27 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: configure.ac.pamphlet

Waldek Hebisch writes:

| configure.ac.pamphlet contains the following:
| 
|     *darwin*)
|         PLF=MACOSXplatform
|         CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} \
|             -I/usr/include -I/usr/include/sys"
|         GCLOPTS="--enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-locbfd \
|             --disable-statsysbfd  --enable-custreloc --disable-tkconfig \
|             --enable-machine=pwerpc-macosx"
|         ;;
|                              ^^^^^^^^^^^^^
| 
| This look wrong on two accounts: 
| 1) standard name is 'powerpc-macosx'
| 2) seem to ignore Intel Macs

Yes on both accounts.  Those are what were in the Makefiles when I
branched.  I never committed my changes to that.  The test should be
based on the target canonical triplet.

\start
Date: 05 Nov 2006 04:25:02 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: Re: configure.ac.pamphlet

Humberto Zuazaga writes:

| Waldek Hebisch wrote:
| > configure.ac.pamphlet contains the following:
| > 
| >     *darwin*)
| >         PLF=MACOSXplatform
| >         CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} \
| >             -I/usr/include -I/usr/include/sys"
| >         GCLOPTS="--enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-locbfd \
| >             --disable-statsysbfd  --enable-custreloc --disable-tkconfig \
| >             --enable-machine=pwerpc-macosx"
| >         ;;
| >                              ^^^^^^^^^^^^^
| > 
| > This look wrong on two accounts: 
| > 1) standard name is 'powerpc-macosx'
| > 2) seem to ignore Intel Macs
| > 
| 
| There still isn't a working gcl for Intel Mac OS X, I started mangling
| the source to support "--enable-machine=i386-macosx", but it's still not
| working. Configure thinks my mac is "i686-apple-darwin8.8.1", as opposed
| to the G5 which is "powerpc-apple-darwin8.8.0". I don't think there will
| ever be a i386 Apple Mac, so we may as well decide to call the machine
| "i686-macosx" instead.

I would like to see GCL (and therefore Axiom) use the canonical
triplet.  That creates less opportunities for confusion.  
Furthermore, I think --enable-machine should be dropped in favor of
the standard and traditional --target.

| I think we should use "--disable-statsysbfd --enable-locbfd --disable-x
| --disable-xgcl --disable-nls", those are the flags I used on the
| external gcl I have that built axiom sucessfully. The
| "--disable-tkconfig" should help with the Tcl/Tk issues we've been
| having. What are the memory and custreloc flags for?

We don't need Tcl/Tk -- that was observed by Vanuxem a while ago.

\start
Date: 05 Nov 2006 04:26:12 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: Re: Tarball for Mac OS X

Humberto Zuazaga writes:

| With Waldek's latest patches it looks like the build completed. 

Is there a chance you can summarize all the patches that enables the
build? 

\start
Date: Sun, 5 Nov 2006 00:32:19 -0500
From: Bill Page
To: Alfredo Portes
Subject: RE: Suggestion

On November 4, 2006 11:40 PM Alfredo Portes wrote:
> 
> I have a little suggestion about MathAction frontpage.
> 
> I think the link Download should point to:
> 
> http://wiki.axiom-developer.org/AxiomBinaries
> 
> having here the different binaries for the platforms.
> 
> then the link Executables can be removed and it can appear
> in both:
> 
> http://wiki.axiom-developer.org/AxiomBinaries
> 
> and
> 
> http://wiki.axiom-developer.org/AxiomSources
> 
> as
> 
> Building Axiom (http://wiki.axiom-developer.org/BuildAxiom)
> 
> I do not know if you consider this a good idea.
> 

Thanks for noticing this Alfredo. Yes I think that is a good idea
so I just modified it as you suggested, except that I changed the
link Executables to Programs instead of deleting it since some
people seem to miss the fact that the headings are in fact also
links.

\start
Date: Sun, 5 Nov 2006 00:42:25 -0500
From: Bill Page
To: Alfredo Portes
Subject: RE: Suggestion

Alfredo,

On November 5, 2006 12:36 AM you wrote:

> ...
> But what about:
> 
> http://wiki.axiom-developer.org/BuildAxiom
> 
> This looks like a very important page, especially to add the new
> procedure to build on OS X. I think there should be way to get this
> content.
> 

Both AxiomBinaries and AxiomSources link to BuildAxiom. Do you mean
you think there should still be a link to it directly from FrontPage?

I agree that BuildAxiom is the right place to add the build procedure
for OS X. Feel free ... :-)

\start
Date: Sun, 5 Nov 2006 01:05:14 -0500
From: Bill Page
To: Alfredo Portes
Subject: RE: Suggestion

On November 5, 2006 12:52 AM Alfredo Portes asked:
> ... 
> > I agree that BuildAxiom is the right place to add the build 
> > procedure for OS X. Feel free ... :-)
> 
> I will. I emailed Humberto to see if he can write the steps...
> 
> what is the status of Axiom on Windows, maybe I should look into the
> mailing list. :-).
> 
> This is when I would hope that discussions were done in the wiki, it
> is much faster to search and find information.
> 

I don't think there has been any recent work. I updated the build
instructions last month and tested building Axiom using the new
gcl-2.6.8pre release. It works but I did not have time to make
any improvements to the existing Windows binaries. I am still
planning (real-soon-now) to start a new build for Windows based
on the new build-improvements branch... That shouldn't be any
harder than it turned out to be for the MAC! :-)

Do you have any interest in working on the Windows version?

\start
Date: Sun, 5 Nov 2006 01:16:32 -0500
From: Alfredo Portes
To: Bill Page
Subject: Re: Suggestion

On 11/5/06, Bill Page wrote:
> On November 5, 2006 12:52 AM Alfredo Portes asked:
> > ...
> > > I agree that BuildAxiom is the right place to add the build
> > > procedure for OS X. Feel free ... :-)
> >
> > I will. I emailed Humberto to see if he can write the steps...
> >
> > what is the status of Axiom on Windows, maybe I should look into the
> > mailing list. :-).
> >
> > This is when I would hope that discussions were done in the wiki, it
> > is much faster to search and find information.
> >
>
> I don't think there has been any recent work. I updated the build
> instructions last month and tested building Axiom using the new
> gcl-2.6.8pre release. It works but I did not have time to make
> any improvements to the existing Windows binaries. I am still
> planning (real-soon-now) to start a new build for Windows based
> on the new build-improvements branch... That shouldn't be any
> harder than it turned out to be for the MAC! :-)
>
> Do you have any interest in working on the Windows version?

I will be done with my midterms this week, so I will have time finally
to work on a new Doyen CD (with the Sage goodies), but Axiom on
Windows sounds like a fun project :-).

It would be nice to have the Linux, OS X and Windows binaries on the livecd.

\start
Date: Sun, 5 Nov 2006 02:51:23 -0500
From: Tim Daly
To: Bill Page
Subject: re: Suggestion

Bill, Alfredo,

I might suggest that we reorganize a portion of the axiom binary
page to use a table form. I placed a mockup at

http://daly.axiom-developer.org/axiombinary

That way we can not only keep track of which binaries are current
for a given platform but we can provide release notes (e.g. windows
does not currently support graphics).

We could also keep the Doyen in the list.

Opinions?

\start
Date: Sun, 5 Nov 2006 02:54:11 -0500
From: Tim Daly
To: Bill Page
Subject: re: Suggestion

Bill,

Did you ever add the asq setup?
I don't see it anywhere.

\start
Date: Sun, 5 Nov 2006 03:25:52 -0500
From: Alfredo Portes
To: Tim Daly
Subject: re: Suggestion

http://wiki.axiom-developer.org/AxiomBinaries

The page does need some reorganization.

Something similar to your table concept, I was thinking of having
at the beginning of the page some kind of index like:

Axiom Binaries

1. Linux
2. Debian
3. Fedora
4. Redhat
5. OS X (PPC)
6. OS X (Intel)
7. Windows

and so on, being each of these links to its specific "level" or section
in the same page, with the proper explanation about the binary
for that particular platform:

2. OS X(PPC)

The Axiom binary file for the........

I do not know if this makes sense or I dont know if you would prefer
to have individual pages for each platform.

On 11/5/06, Tim Daly wrote:
> Bill, Alfredo,
>
> I might suggest that we reorganize a portion of the axiom binary
> page to use a table form. I placed a mockup at
>
> http://daly.axiom-developer.org/axiombinary
>
> That way we can not only keep track of which binaries are current
> for a given platform but we can provide release notes (e.g. windows
> does not currently support graphics).
>
> We could also keep the Doyen in the list.

\start
Date: Sun, 5 Nov 2006 03:29:12 -0500
From: Tim Daly
To: Alfredo Portes
Subject: re: Suggestion

well, clearly i think the table organization is clearer :-)
the advantage is that you can see at a glance which binaries
are available, which are downlevel, and which are missing.
that way we can direct efforts at making binaries.

entries in the table can point to the same binaries if they
work across multiple platforms so there is no need for a
page per table entry.

we could even color code the table entries for "partial",
"experimental branch", "silver" and "gold" versions so it
would be possible to have multiple versions per platform.

\start
Date: Sun, 5 Nov 2006 03:46:15 -0500
From: Alfredo Portes
To: Tim Daly
Subject: re: Suggestion

On 11/5/06, Tim Daly wrote:
> well, clearly i think the table organization is clearer :-)
> the advantage is that you can see at a glance which binaries
> are available, which are downlevel, and which are missing.
> that way we can direct efforts at making binaries.

Ok.

> entries in the table can point to the same binaries if they
> work across multiple platforms so there is no need for a
> page per table entry.

but then, where are the release notes going to be placed?

> we could even color code the table entries for "partial",
> "experimental branch", "silver" and "gold" versions so it
> would be possible to have multiple versions per platform.

That sounds interesting.

\start
Date: Sun, 5 Nov 2006 04:08:07 -0500
From: Tim Daly
To: Alfredo Portes
Subject: re: Suggestion

> > entries in the table can point to the same binaries if they
> > work across multiple platforms so there is no need for a
> > page per table entry.
> 
> but then, where are the release notes going to be placed?

place the release note link in the same box as the binary thus:


-------------------------------------------------
BINARY | Fedora | 
------------------------------------------------
BI     | Notes  |
       | Binary |
------------------------------------------------
Silver | Notes  |
       | Binary |
------------------------------------------------
Gold 50| Notes  |
       | Binary |
------------------------------------------------

\start
Date: Sun, 5 Nov 2006 12:57:01 +0100 (CET)
From: Waldek Hebisch
To: Ralf Hemmecke
Subject: Re: ActiveAxiomDevelopers


> Hello Waldek,
> 
> You are one of the most active developers currently. You should 
> definitely put an entry on
> 
> http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers
> 

Sorry, last time when I tried to update wiki (different page) it
did not work -- I typed in all that silly info which 'preferences'
want to gather but it still did not work.

\start
Date: Sun, 5 Nov 2006 14:31:36 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Ping: file removals

I proposed removing several files from Axiom repository.  ATM only
Gaby commented on some files.  

Here is updated list:

files unused both in silver and in build-improvements, up to date
copies are created during build process:

 src/share/algebra/comdb.text
 src/share/algebra/libdb.text
 src/share/algebra/DEPENDENTS.DAASE
 src/share/algebra/USERS.DAASE
 src/interp/libdb.text
 src/interp/temp.text

files created during build process, but version from repo is referenced
form Makefiles ('src/algebra/libdb.text' is unused in build-improvements):
 src/algebra/libdb.text
 src/hyper/pages/ht.db
 src/share/algebra/gloss.text
 
duplicate, referenced from Makefile (removal needs Makefile changes):
 src/share/doc/hypertex/pages/util.ht

generated documentation files:

 src/doc/bookvol1.pdf

I would give high priority to removing extra copy of 'util.ht', since
'util.ht' contains paths to files which we need to rename.

\start
Date: Sun, 05 Nov 2006 10:03:18 -0400
From: Humberto Zuazaga
To: Alfredo Portes
Subject: Re: Tarball for Mac OS X

Alfredo Portes wrote:

> Maybe you can write the instructions down to build on MAC PPC on the wi=
ki.


Since the process relies on at least 3 patches to gcl and axiom that are
being incorporated into the development sources I'd rather wait.

Hopefully in a few days we can say the instructions will be:

$ svn co
https://svn.sourceforge.net/svnroot/axiom/branches/build-improvements \
                axiom.build-improvements

$ cd axiom.build-improvements
$ ./configure
$ make

:-)

\start
Date: Sun, 05 Nov 2006 15:08:31 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: Re: ActiveAxiomDevelopers

Send it to me then, I'll do it for you. The page should actually still 
be editable by everyone, but I also realized that sometimes I am asked 
for a password even if I entered a "Reason for change". But fortunately, 
I have a password.

Ralf

On 11/05/2006 12:57 PM, Waldek Hebisch wrote:
>> Hello Waldek,
>>
>> You are one of the most active developers currently. You should 
>> definitely put an entry on
>>
>> http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers
>>
> 
> Sorry, last time when I tried to update wiki (different page) it
> did not work -- I typed in all that silly info which 'preferences'
> want to gather but it still did not work.

\start
Date: 05 Nov 2006 15:50:25 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Ping: file removals

Waldek Hebisch writes:

| I proposed removing several files from Axiom repository.  ATM only
| Gaby commented on some files.  
| 
| Here is updated list:
| 
| files unused both in silver and in build-improvements, up to date
| copies are created during build process:
| 
|  src/share/algebra/comdb.text
|  src/share/algebra/libdb.text
|  src/share/algebra/DEPENDENTS.DAASE
|  src/share/algebra/USERS.DAASE
|  src/interp/libdb.text
|  src/interp/temp.text

Please remove these from build-improvements.

| files created during build process, but version from repo is referenced
| form Makefiles ('src/algebra/libdb.text' is unused in build-improvements):
|  src/algebra/libdb.text
|  src/hyper/pages/ht.db
|  src/share/algebra/gloss.text

those "clearly" are bugs.  We should reference those created during
the build process.  And those from repo should go away.

| duplicate, referenced from Makefile (removal needs Makefile changes):
|  src/share/doc/hypertex/pages/util.ht

Unless I'm misremebring, someone suggested that there might a slight
difference in content with its duplicate.  If that is correct, it
would be good to merge the content (with expalanation as usual) and
remove it.

| generated documentation files:
| 
|  src/doc/bookvol1.pdf

this call is slighlty harder.  We don't generate PDFs at the moment
(but we should), and this is a copy of a book already published.  So
the question is how "authentic" we want the copy in SVN to be.
Personnaly, I would go for its complete deletion, augment the build
machinery to generate PDF for documentation.  (I'm planning to put in
the PDF generatin anyway).

This morning I'll merge some changes from silver and work on the build
without X11 item.

\start
Date: Sun, 5 Nov 2006 11:20:54 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Ping: file removals

> | files created during build process, but version from repo is referenced
> | form Makefiles ('src/algebra/libdb.text' is unused in build-improvements):
> |  src/algebra/libdb.text
> |  src/hyper/pages/ht.db
> |  src/share/algebra/gloss.text
> 
> those "clearly" are bugs.  We should reference those created during
> the build process.  And those from repo should go away.

exact memory fails me but i believe the libdt.text might contain
the command completion list of clef. the fact that it is not currently
used might be that i never got around to connecting it. 

gloss.text is supposed to be an automated glossary for the original
axiom book. i don't believe i ever picked that up when i recreated
the book.

there is another bit of functionality to recover. axiom had a 
'javadoc' functionality which creates per-domain/cat/pkg documentation
in single page format. i have a printed pile containing such info.
unfortunately the command to create it only ran on the mainframe
so i can find no surviving record of the code.

ulitmately these files had some purpose in the system which might
still remain to be recovered. removing them won't hurt anything but
it might be interesting to investigate why they exist.

\start
Date: Sun, 5 Nov 2006 11:24:06 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Ping: file removals

> | generated documentation files:
> | 
> |  src/doc/bookvol1.pdf
> 
> this call is slighlty harder.  We don't generate PDFs at the moment
> (but we should), and this is a copy of a book already published.  So
> the question is how "authentic" we want the copy in SVN to be.
> Personnaly, I would go for its complete deletion, augment the build
> machinery to generate PDF for documentation.  (I'm planning to put in
> the PDF generatin anyway).

the pdf differs from the sources. the pdf is an exact copy of the
published book as printed with the ISBN. there have been patches
applied to the sources which people have submitted so the sources
differ marginally, thus it is not possible to recreate the pdf
unless you go into the archive and fetch the unpatched sources.

\start
Date: 05 Nov 2006 17:42:43 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Ping: file removals

Tim Daly writes:

| > | generated documentation files:
| > | 
| > |  src/doc/bookvol1.pdf
| > 
| > this call is slighlty harder.  We don't generate PDFs at the moment
| > (but we should), and this is a copy of a book already published.  So
| > the question is how "authentic" we want the copy in SVN to be.
| > Personnaly, I would go for its complete deletion, augment the build
| > machinery to generate PDF for documentation.  (I'm planning to put in
| > the PDF generatin anyway).
| 
| the pdf differs from the sources. the pdf is an exact copy of the
| published book as printed with the ISBN. there have been patches
| applied to the sources which people have submitted so the sources
| differ marginally, thus it is not possible to recreate the pdf
| unless you go into the archive and fetch the unpatched sources.

In that case, we could 

  (1) rename the current bookvol1.pdf to original-bookvol1.pdf
      so that its name suggests its purporse
  (2) generate PDF for the patched version -- we might add that it
      is not officially publsihed yet and contains correction to
      previous edition.

What do you think?

\start
Date: Sun, 5 Nov 2006 19:41:33 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: Ping: file removals

> > | files created during build process, but version from repo is referenced
> > | form Makefiles ('src/algebra/libdb.text' is unused in build-improvements):
> > |  src/algebra/libdb.text
> > |  src/hyper/pages/ht.db
> > |  src/share/algebra/gloss.text
> > 
> > those "clearly" are bugs.  We should reference those created during
> > the build process.  And those from repo should go away.
> 
> exact memory fails me but i believe the libdt.text might contain
> the command completion list of clef. the fact that it is not currently
> used might be that i never got around to connecting it. 
>

libdt.text contains information about constructors.  We create 
up-to date version, but gold/silver do not install it.  See:

http://lists.nongnu.org/archive/html/axiom-developer/2006-10/msg00549.html

for a patch.
 
> gloss.text is supposed to be an automated glossary for the original
> axiom book. i don't believe i ever picked that up when i recreated
> the book.
> 

AFAICS gloss.text contains identical information as the glossary
section of axiom book -- so one can be generated for the other
(I would prefer to generate 'gloss.text' from the book).  
I wrote that 'gloss.text' was generated -- I was wrong, 'gloss.text'
was just copied around. 'gloss.text' is unused, but
there is code which could generate 'glosskey.text', 'gloss.ht'
and 'glossdef.text' from it.  ATM I withdraw proposal to remove
'gloss.text' (will investigate this further).


> there is another bit of functionality to recover. axiom had a 
> 'javadoc' functionality which creates per-domain/cat/pkg documentation
> in single page format. i have a printed pile containing such info.
> unfortunately the command to create it only ran on the mainframe
> so i can find no surviving record of the code.
>

If you install fresly build 'libdb.txt', then this functionality
works.
 
> ulitmately these files had some purpose in the system which might
> still remain to be recovered. removing them won't hurt anything but
> it might be interesting to investigate why they exist.
> 

with the exception of 'gloss.text' the files in first and second
group are generated during build and have known purpose.

\start
Date: Sun, 5 Nov 2006 20:03:01 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: Ping: file removals

> > | generated documentation files:
> > | 
> > |  src/doc/bookvol1.pdf
> > 
> > this call is slighlty harder.  We don't generate PDFs at the moment
> > (but we should), and this is a copy of a book already published.  So
> > the question is how "authentic" we want the copy in SVN to be.
> > Personnaly, I would go for its complete deletion, augment the build
> > machinery to generate PDF for documentation.  (I'm planning to put in
> > the PDF generatin anyway).
> 
> the pdf differs from the sources. the pdf is an exact copy of the
> published book as printed with the ISBN. there have been patches
> applied to the sources which people have submitted so the sources
> differ marginally, thus it is not possible to recreate the pdf
> unless you go into the archive and fetch the unpatched sources.
> 

I think that having two versions of bookvol1 is confusing for users.
Since later edits should improve the book (or update it to match
the program), I would opt for distributing with sources only the
latest version.
For people who want exact copy of published book we could provide
instructions how to fetch the pamphlet from the SCM (say add 
README.original-bookvol1).  Additionaly we can provide .pdf on
Axiom web site. 

One extra remark:  It make sense to put generated documentation
into distribution tarball, but IMHO generated files (with the exception
of files needed to bootstrap) should be removed from source archive.
And even for bootstrap files I think that we should remove them
from main source directory and put them in separate area (say
in subdirectories of 'bootstrap' directory, paralel to 'src').

\start
Date: Sun, 5 Nov 2006 14:12:03 -0500
From: Bill Page
To: Alfredo Portes, Tim Daly
Subject: re: Suggestion

Alfredo and Tim,

Please update the Axiom wiki page to improve it as you suggest.

Thanks.

Regards,
Bill Page.

> -----Original Message-----
> From: Alfredo Portes [mailto:Alfredo Portes] 
> Sent: November 5, 2006 3:26 AM
> To: Tim Daly
> Cc: Bill Page; list
> Subject: re: Suggestion
> 
> 
> http://wiki.axiom-developer.org/AxiomBinaries
> 
> The page does need some reorganization.
> 
> Something similar to your table concept, I was thinking of having
> at the beginning of the page some kind of index like:
> 
> Axiom Binaries
> 
> 1. Linux
> 2. Debian
> 3. Fedora
> 4. Redhat
> 5. OS X (PPC)
> 6. OS X (Intel)
> 7. Windows
> 
> and so on, being each of these links to its specific "level" 
> or section
> in the same page, with the proper explanation about the binary
> for that particular platform:
> 
> 2. OS X(PPC)
> 
> The Axiom binary file for the........
> 
> I do not know if this makes sense or I dont know if you would prefer
> to have individual pages for each platform.
> 
> On 11/5/06, Tim Daly wrote:
> > Bill, Alfredo,
> >
> > I might suggest that we reorganize a portion of the axiom binary
> > page to use a table form. I placed a mockup at
> >
> > http://daly.axiom-developer.org/axiombinary
> >
> > That way we can not only keep track of which binaries are current
> > for a given platform but we can provide release notes (e.g. windows
> > does not currently support graphics).
> >
> > We could also keep the Doyen in the list.
> >
> > Opinions?

\start
Date: Sun, 5 Nov 2006 14:17:25 -0500
From: Bill Page
To: Waldek Hebisch
Subject: re: ActiveAxiomDevelopers

On November 5, 2006 6:57 AM Waldek Hebisch wrote:
> Ralf Hemmecke wrote:
> > 
> > You are one of the most active developers currently. You should 
> > definitely put an entry on
> > 
> > http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers
> > 
> 
> Sorry, last time when I tried to update wiki (different page) it
> did not work -- I typed in all that silly info which 'preferences'
> want to gather but it still did not work.
> 

The only information required is name and email address - it can be
a psuedo-name if you prefer. Is that silly?

It would be very helpful to me (and other people trying to use the
wiki) if you would report any problems you have so that they can be
addressed. "did not work" is not very helpful :-(

\start
Date: Sun, 5 Nov 2006 11:47:24 -0800
From: Richard Harke
To: list
Subject: drawRibbons from the book

I have been working my way through the book.  The first version of
drawRibbons (Section 10.2, page 487) seems to work as described.
The second version (section 10.3,  page 489) produces some error
messages which I don't understand. The following is the session.
(after a )clear all)

(1) -> )read ribbons
drawRibbons(flist, xrange, yrange) ==
  sp := createThreeSpace()
  num := # flist
  yVar := variable yrange
  y0:Float := lo segment yrange
  width:Float := (hi segment yrange - y0)/num
  for f in flist for color in 1..num repeat
    makeObject(f, xrange, yVar=y0..y0+width,
       var2Steps == 1, colorFunction == (x,y) +-> color,
       space == sp)
    y0 := y0 + width
  vp := makeViewport3D(sp, "Ribbons")
  drawStyle(vp, "shade")
  outlineRender(vp, "on")
  showRegion(vp, "on")
  vp

  Line   1: drawRibbons(flist, xrange, yrange) ==
  Line   2:   sp := createThreeSpace()
  Line   3:   num := # flist
  Line   4:   yVar := variable yrange
  Line   5:   y0:Float := lo segment yrange
  Line   6:   width:Float := (hi segment yrange - y0)/num
  Line   7:   for f in flist for color in 1..num repeat
  Line   8:     makeObject(f, xrange, yVar=y0..y0+width,
           ....A.........B
  Error  A: (from #\A and on) Ignored from here
  Error  B: Missing mate.
  Line   9:        var2Steps == 1, colorFunction == (x,y) +-> color,
           .......A
  Error  A: (from #\A up to ) Ignored.
  Line  10:        space == sp)
           .......A..........B
  Error  A: (from #\A up to #\B) Ignored.
  Error  B: Improper syntax.
  Error  B: Improper syntax.
  Error  B: Possibly missing a )
  Error  B: (up to #\B) to here.
  Line  11:     y0 := y0 + width
  Line  12:   vp := makeViewport3D(sp, "Ribbons")
  Line  13:   drawStyle(vp, "shade")
  Line  14:   outlineRender(vp, "on")
  Line  15:   showRegion(vp, "on")
  Line  16:   vp
   8 error(s) parsing

\start
Date: 05 Nov 2006 20:39:29 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Ping: file removals

Waldek Hebisch writes:

[...]

| And even for bootstrap files I think that we should remove them
| from main source directory and put them in separate area (say
| in subdirectories of 'bootstrap' directory, paralel to 'src').

You just revealed to the world, my long-term secret plan for Axiom. :-)

\start
Date: 05 Nov 2006 20:54:04 +0100
From: Francois Maltey
To: list
Subject: axiom for trigonometric functions again...

Hello,

I used axiom last year and I was afflicted because I couldn't use axiom
for the little computations I make with/for my students.

This list gave me pretty advices, but my attempts for improving
trigonometric functions in manip.spad failled.  
Changing this file is to difficult for me.

However Axiom is the better free computer algebra system, 
so I use it again this year even if I can't do what I want !

Now I'll try to make my own little package for pretty expand, combine and 
rewrite functions only over Expression Integer and Expression Complex Integer.

In fact I try today to get a nice result for this exercice I'll give to my
students : 

   sum ((cos x)^k * cos (k*x), k=0..n) 

Is it possible to load at the boot-time the packages or the 
functions that we prefer ?

So I won't need to type expand$MyExpand (cos (3*x/2)) but only expand
(cos (3*x/2)) in the interpreter, even if my expand function in
MyExpand.spad package will use sometimes the expand function of the
manip.spad file.

For this example axiom prefers real (sum ((cos x)^k * exp(%i*k*x), k=0..n))
to sum ((cos x)^k * cos (k*x), k=0..n). 

Where can be the nice rewrite command trigo. to exp. added ? in sum.spad ?

Long life to axiom.

\start
Date: Sun, 5 Nov 2006 20:53:46 +0100
From: Raymond Manzoni
To: list
Subject: Re: Mac OS X 10.4.8 PowerPC success!

	This is a resume of the methods given here by Humberto Ortiz-Zuazaga  
as I used them to get a working gcl and AXIOMsys (for people like me  
in a hurry to get gcl and axiom working on OSX 10.4.8 PPC) both  
installed in /usr/local and using bash.

	Building gcl :

	remove  -lintl from the LIBS line of ./h/powerpc-macosx.defs
	isolate Fink (/sw/... by default) and DarwinPorts (/opt/local/...)  
from gcl's path :

	PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin
	./configure --enable-locbfd --disable-statsysbfd --disable-nls

	(I added two symbolic links in /usr/local/bin : the first since  
pdflatex was needed for completion of the make and the second  
(optional) for .dvi generation of the make install (the location of  
your pdflatex and tex may vary...) :
	  cd /usr/local/bin		
  	  sudo ln -s /sw/bin/pdflatex pdflatex
	  sudo ln -s /sw/bin/tex tex
	)

	make     (*)
	sudo make install
	

	Building axiom (very long...) :

	I used exactly Humberto's method here (I got darcs 1.0.7 here :  
http://el-tramo.be/software/darcs-ppc-static/ since Fink's darcs  
wouldn't install) :

	darcs get http://page.axiom-developer.org/repository/axiom-darcs/

	chmod +x configure
  	./configure --prefix=/usr/local --with-gcl
	(verify that the right gcl is chosen!)
  	chmod +x config/mkinstalldirs
  	make

	If you get the SIGCLD errors then, in the files sselect.c.pamphlet  
and viewman.c.pamphlet, replace :
	#if defined(BSDplatform)
	by
	#if defined(BSDplatform) || defined(MACOSXplatform)

	Should you get errors in hyper apply the patch to src/hyper/ 
hthits.pamphlet as proposed by Waldek Hebisch a day earlier in the  
'viewman and hyper on Mac OS X' thread. (here some .pamphlet files  
were missing in my hyper directory and I had to restore them first...)

	make
	sudo make install
	
	In your .profile file (for bash) add the path :
	/usr/local/axiom/target/powerpc-apple-darwin8.8.0/bin

	And you should have a working AXIOMsys...

	axiom itself fails with the lines :

	ptyopen: Failed to open /dev/ptmx: No such file or directory
	start_the_Axiom: ptyopen failed: No such file or directory
	
	Humberto got an additional error :
	(HyperDoc) Cannot connect to the X11 server!

	Of course all this it is far from the ideal
	./configure
	make
	he suggested but it worked for me so if you need to build it from  
source now...
	

	With my sincere thanks to Humberto and all of you,
				Raymond


(*) you may get an error in gcl_readline.d:221 (readline completion)  
I (hope temporarily...) just returned NULL;

\start
Date: Sun, 5 Nov 2006 22:01:06 +0100
From: Juan Rivas
To: list
Subject: Re: Mac OS X 10.4.8 PowerPC success!

On Sun, Nov 05, 2006 at 08:53:46PM +0100, Raymond Manzoni wrote:
> 	darcs get http://page.axiom-developer.org/repository/axiom-darcs/
> 
> 	chmod +x configure

Just for the record, if you do a

darcs get --set-scripts-executable http://page.axiom-developer.org/repository/axiom-darcs/

then it won't be necessary to chmod +x configure.

\start
Date: Sun, 5 Nov 2006 22:17:29 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Axiom documentation and asq.c.pamphlet

I just neticed that a large documentation hunk was copied almost
verbatim from 'src/interp/daase.lisp.pamphlet' into 'src/etc/asq.c.pamphlet'
IMHO this is _very_ bad practise. It increas work needed to maintain
Axiom.  And the to copies are likely to get out of sync anyway, which
will cause confusion to the readers.

AFAICS the copy in 'src/etc/asq.c.pamphlet' should be removed and
replaced by text like:

Database structure is described in [[src/interp/daase.lisp.pamphlet]].
Note that [[asq]] currently works only with compressed databases.

\start
Date: Mon, 6 Nov 2006 00:10:57 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: better pty patch

Many systems (Linux, BSD and supposedly also Mac OS X) provide 'openpty'
function as a preferred method to open a pty (for example on Linux
'openpty' will use Unix 98 ptys, but if those are not available it
will fall back to legacy ptys).  'openpty' seem to be available
in 'libutil', so in order to use it we must link to 'libutil'.

The patch below tries to 'openpty': add configure check and auguments
compiler and linker argument.  There are some things which probably
should be done in different way (please comment):

1) configure defines 'HAVE_OPENPTY' preprocessor symbol, this symbol
   is then propagated via 'DEFS' make variable and compile command
   line.  Alternatively we could have a common header file generated
   by configure

2) I only modified clef and sman Makefiles, but it is probably better
   to use the same set of libraries and the same compiler command line
   for all compilations.


diff -ru build-improvements.bb/config/var-def.mk build-improvements/config/var-def.mk
--- build-improvements.bb/config/var-def.mk	2006-11-03 18:07:14.000000000 +0100
+++ build-improvements/config/var-def.mk	2006-11-04 23:02:43.000000000 +0100
@@ -112,6 +112,8 @@
 
 AXIOM_X11_CFLAGS = @X_CFLAGS@ 
 AXIOM_X11_LDFLAGS = @X_LIBS@ @X_PRE_LIBS@ -lX11 @X_EXTRA_LIBS@
+EXTRA_LIBS = @EXTRA_LIBS@
+DEFS = @DEFS@
 
 ## Where the staging build directory is found
 AXIOM = @AXIOM@
diff -ru build-improvements.bb/configure build-improvements/configure
diff -ru build-improvements.bb/configure.ac.pamphlet build-improvements/configure.ac.pamphlet
--- build-improvements.bb/configure.ac.pamphlet	2006-11-03 18:07:14.000000000 +0100
+++ build-improvements/configure.ac.pamphlet	2006-11-04 22:50:25.000000000 +0100
@@ -580,6 +580,17 @@
 AC_SUBST(X_PRE_LIBS)
 @
 
+\section{Extra libraries}
+
+Axiom supporting programs [[sman]] and [[clef]] use pseudo terminals.
+To open pseudo terminals we use [[openpty]] if available, otherwise
+we fall back to platform specific code.
+
+<<extra libraries>>=
+AC_CHECK_FUNCS(openpty,, AC_CHECK_LIB(util,openpty, [AC_DEFINE(HAVE_OPENPTY)]
+ [EXTRA_LIBS="-lutil"]))
+AC_SUBST(EXTRA_LIBS)
+@
 
 \section{configure.ac}
 
@@ -602,6 +613,8 @@
 
 <<locate X11>>
 
+<<extra libraries>>
+
 <<define AXIOM>>
 
 <<platform specific bits>>
diff -ru build-improvements.bb/src/clef/Makefile.pamphlet build-improvements/src/clef/Makefile.pamphlet
--- build-improvements.bb/src/clef/Makefile.pamphlet	2006-11-03 18:07:14.000000000 +0100
+++ build-improvements/src/clef/Makefile.pamphlet	2006-11-04 22:57:58.000000000 +0100
@@ -25,7 +25,7 @@
 clef_objects = $(clef_sources:.c=.o) 
 
 CFLAGS=	${CCF} 
-LDFLAGS= -L${LIB} -lspad ${LDF}
+LDFLAGS= -L${LIB} -lspad ${EXTRA_LIBS} ${LDF}
 
 @
 \section{The clef sources, edible}
diff -ru build-improvements.bb/src/lib/Makefile.pamphlet build-improvements/src/lib/Makefile.pamphlet
--- build-improvements.bb/src/lib/Makefile.pamphlet	2006-11-03 18:07:14.000000000 +0100
+++ build-improvements/src/lib/Makefile.pamphlet	2006-11-04 23:04:53.000000000 +0100
@@ -49,7 +49,7 @@
 .PRECIOUS: %.o
 
 %.o: %.c
-	$(CC) $(CCF) -c -I$(INC) $< -o $@
+	$(CC) $(DEFS) $(CCF) -c -I$(INC) $< -o $@
 @
 
 
diff -ru build-improvements.bb/src/lib/openpty.c.pamphlet build-improvements/src/lib/openpty.c.pamphlet
--- build-improvements.bb/src/lib/openpty.c.pamphlet	2006-11-03 18:07:14.000000000 +0100
+++ build-improvements/src/lib/openpty.c.pamphlet	2006-11-05 22:45:03.000000000 +0100
@@ -10,17 +10,9 @@
 \tableofcontents
 \eject
 \section{MAC OSX and BSD platform changes}
-Since we have no other information we are adding the [[MACOSXplatform]] variable
-to the list everywhere we find [[LINUXplatform]]. This may not be correct but
-we have no way to know yet. We have also added the [[BSDplatform]] variable.
-MAC OSX is some variant of BSD. These should probably be merged but we
-cannot yet prove that.
-<<mac osx platform change 1>>=
-#if defined(SUN4OS5platform) ||defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(MACOSXplatform) || defined(BSDplatform)
-@
-<<mac osx platform change 2>>=
-#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(MACOSXplatform) || defined(BSDplatform)
-@
+We should really use autotools to check for Unix 98 pty support.
+Before this is done below we hardcode information about each platform.
+
 \section{License}
 <<license>>=
 /*
@@ -70,6 +62,9 @@
 #include <stropts.h>
 #endif
 
+#ifdef HAVE_OPENPTY
+#include <pty.h>
+#endif
 
 #include "openpty.H1"
 
@@ -104,7 +99,10 @@
 #endif
 
 {
-#if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) ||defined(AIX370platform) || defined(BSDplatform)
+#ifdef HAVE_OPENPTY
+  return openpty(controller, server, serverPath, 0, 0);
+#else
+#if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) ||defined(AIX370platform) || defined(BSDplatform) || defined(MACOSXplatform)
   int looking = 1, i;
   int oflag = O_RDWR;                  /* flag for opening the pty */
   
@@ -147,7 +145,8 @@
   return(fdm);
 #endif
 
-<<mac osx platform change 1>>
+/* MAC OS X 10.3 does not support Unix 98 pty's */
+#if defined(SUN4OS5platform) ||defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(BSDplatform)
 extern int grantpt(int);
 extern int unlockpt(int);
 extern char* ptsname(int);
@@ -199,6 +198,7 @@
   return (*controller);
 
 #endif
+#endif
 }
 
 
@@ -216,7 +216,7 @@
 	sprintf(serv, "/dev/ttyp%02x", channelNo);
 	channelNo++;
 #endif
-<<mac osx platform change 2>>
+#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(MACOSXplatform) || defined(BSDplatform)
 	static int channelNo = 0;
 	static char group[] = "pqrstuvwxyzPQRST";
 	static int groupNo = 0;
diff -ru build-improvements.bb/src/sman/Makefile.pamphlet build-improvements/src/sman/Makefile.pamphlet
--- build-improvements.bb/src/sman/Makefile.pamphlet	2006-11-03 18:07:09.000000000 +0100
+++ build-improvements/src/sman/Makefile.pamphlet	2006-11-04 22:58:41.000000000 +0100
@@ -25,7 +25,7 @@
 # this is where the documentation ends up
 DOC=    $(axiom_target_docdir)/src/sman
 CFLAGS=	${CCF} -I$(INC) -I$(builddir)
-LDFLAGS= -L${LIB} -lspad ${LDF}
+LDFLAGS= -L${LIB} -lspad ${EXTRA_LIBS} ${LDF}
 
 SMANOBJS= ${LIB}/libspad.a
 
\start
Date: Sun, 5 Nov 2006 18:39:12 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: Re: Axiom documentation and asq.c.pamphlet

> I just neticed that a large documentation hunk was copied almost
> verbatim from 'src/interp/daase.lisp.pamphlet' into 'src/etc/asq.c.pamphlet'
> IMHO this is _very_ bad practise. It increas work needed to maintain
> Axiom.  And the to copies are likely to get out of sync anyway, which
> will cause confusion to the readers.
> 
> AFAICS the copy in 'src/etc/asq.c.pamphlet' should be removed and
> replaced by text like:
> 
> Database structure is described in [[src/interp/daase.lisp.pamphlet]].
> Note that [[asq]] currently works only with compressed databases.

Although the text in some blocks is the same the structure of the
documents are different. Asq does not contain all of the information
that is in daase. Both documents needs explanation and they
will diverge in the future. I'm looking at changing asq to handle
html style output. The information will certainly diverge (and you'll
notice that they are structured differently) as I continue to change asq.
The asq changes are not fully documented. Please have patience.

\start
Date: Mon, 06 Nov 2006 00:49:18 +0100
From: Gregory Vanuxem
To: Richard Harke
Subject: Re: drawRibbons from the book

Le dimanche 05 novembre 2006 =E0 11:47 -0800, Richard Harke a =E9crit :
> I have been working my way through the book.  The first version of
> drawRibbons (Section 10.2, page 487) seems to work as described.
> The second version (section 10.3,  page 489) produces some error
> messages which I don't understand. The following is the session.
> (after a )clear all)


>
> (1) -> )read ribbons
> drawRibbons(flist, xrange, yrange) ==
>   sp := createThreeSpace()
>   num := # flist
>   yVar := variable yrange
>   y0:Float := lo segment yrange
>   width:Float := (hi segment yrange - y0)/num
>   for f in flist for color in 1..num repeat
>     makeObject(f, xrange, yVar=y0..y0+width,
>        var2Steps == 1, colorFunction == (x,y) +-> color,
>        space == sp)
        ^
You have to indent this line (it will be be considered as a continuation
of the previous line) or use an underscore (line continuation
character), so:

    makeObject(f, xrange, yVar=y0..y0+width,
       var2Steps == 1, colorFunction == (x,y) +-> color,
          space == sp)
or

    makeObject(f, xrange, yVar=y0..y0+width,
       var2Steps == 1, colorFunction == (x,y) +-> color,_
       space == sp)

With an underscore the indentation does not matter. I don't know if your
code used to work in the past.

\start
Date: Mon, 06 Nov 2006 00:58:32 +0100
From: Gregory Vanuxem
To: Richard Harke
Subject: Re: drawRibbons from the book

Le lundi 06 novembre 2006 =E0 00:49 +0100, Vanuxem Gr=E9gory a =E9crit :

> I don't know if your
> code used to work in the past.

In fact there is an error in the book, the underscore does not need to
be escaped.

\start
Date: Mon, 06 Nov 2006 01:30:42 +0100
From: Ralf Hemmecke
To: list
Subject: Aldor compilation for Axiom

Hello,

could someone tell me what ")compile blah.as" is actually doing in Axiom?

It is certainly more than saying

aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y 
$AXIOM/algebra blah.as

(without having an Axiom session running).

I think someone once said that )compile calls aldor with the above flags 
and then also generates object files from the .lsp files. How could I 
achieve that from outside Axiom? Or is it enough to provide the .lsp 
files and the compilation to object files is triggered when the code is 
first used?

Further, I actually have a whole library (several .as files). What would 
be the right procedure to compile them externally (I want to do that via 
  Makefiles) and then provide some nice mechanism to load the compiled 
library into Axiom.

I just need a rough overview.

\start
Date: Sun, 5 Nov 2006 21:37:10 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Aldor compilation for Axiom

On November 5, 2006 7:31 PM Ralf Hemmecke wrote:
> 
> could someone tell me what ")compile blah.as" is actually 
> doing in Axiom?
> 
> It is certainly more than saying
> 
> aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y 
> $AXIOM/algebra blah.as
> 
> (without having an Axiom session running).
> 
> I think someone once said that )compile calls aldor with the 
> above flags and then also generates object files from the .lsp
> files.

Yes.

> How could I achieve that from outside Axiom?

Do you mean generate stand alone object files from .lsp files? This
would be done with a Lisp compiler, of course. In principle you can
use GCL just like Axiom does, but you must also provide a Lisp
run-time. The Aldor distribution has such a lisp run-time that is
supposed to be equivalent to the Aldor C run-time environment, but
my initial attempts to use it with GCL ran into trouble - maybe
some GCL incompatibility with the lisp run-time source?

If you want to generate object files that can later be loaded into
Axiom, I am not sure that it is possible to do this outside of Axiom
because I suspect there symbols that are known only to Axiom. If you
discover a way, I would be quite interested. Remember that because
it is written in Lisp AXIOM really just GCL + a lot of extra Lisp code.
So internally in AXIOM, compiling Lisp to object code is done by the
same underlying GCL mechanisms.

> Or is it enough to provide the .lsp files and the compilation to
> object files is triggered when the code is first used?
> 

No. You must compile the .lsp files inside Axiom.

Ralf, do you know section 18.12 : Using Aldor outside AXIOM for AXIOM
of the Aldor User's Guide?

http://www.aldor.org/docs/HTML/chap18.html#12

"When you are ready to test and use your code within AXIOM, start
up AXIOM and then )cd to the directory containing your compiled code.
Invoke )compile on each .lsp file you wish to use."

See also section 18.11.

> Further, I actually have a whole library (several .as files). 
> What would be the right procedure to compile them externally
> (I want to do that via Makefiles) and then provide some nice
> mechanism to load the compiled library into Axiom.
> 

Why compile "externally"? Why not just use Axiom in your Makefile,
the way it is currently done in the Axiom build. E.g.

myfile.NRLIB/code.o: myfile.as
	echo ')compile myfile.as' | AXIOMsys

You can use the ')dir' option of the ')library' command to load
all the object files in a given subdirectory

)library )dir mylib

See section 16.4 of the Axiom book:

http://wiki.axiom-developer.org/public/book2.pdf

> I just need a rough overview.
> 

I hope these comments are some some use.

\start
Date: Sun, 5 Nov 2006 21:53:23 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Axiom documentation and asq.c.pamphlet

On November 5, 2006 6:11 PM Waldek Hebisch wrote:
> I just neticed that a large documentation hunk was copied
> almost verbatim from 'src/interp/daase.lisp.pamphlet' into
> 'src/etc/asq.c.pamphlet' IMHO this is _very_ bad practise. It
> increas work needed to maintain Axiom.  And the to copies are
> likely to get out of sync anyway, which will cause confusion
> to the readers.
> 
> AFAICS the copy in 'src/etc/asq.c.pamphlet' should be removed
> and replaced by text like:
> 
> Database structure is described in [[src/interp/daase.lisp.pamphlet]].
> Note that [[asq]] currently works only with compressed databases.
>

On November 5, 2006 6:39 PM Tim Daly replied:
>
> Although the text in some blocks is the same the structure of the
> documents are different. Asq does not contain all of the information
> that is in daase. Both documents needs explanation and they will
> diverge in the future. I'm looking at changing asq to handle html
> style output. The information will certainly diverge (and you'll
> notice that they are structured differently) as I continue to 
> change asq. The asq changes are not fully documented. Please have
> patience.
> 

I strongly agree with Waldek. You should not be duplicating information
from src/interp/daase.lisp.pamphlet in the documentation for asq. This
is independent of whether asq produces HTML styly output or not. In
reference to the underlying database structure I think you should use
Waldek's version.

\start
Date: Sun, 5 Nov 2006 22:11:41 -0500
From: Bill Page
To: Gregory Vanuxem, Richard Harke
Subject: RE: drawRibbons from the book

On November 5, 2006 6:59 PM Vanuxem Gr=E9gory wrote:
>
> In fact there is an error in the book, the underscore does not need
> to be escaped.
>

Although it's small, so this kind of thing doesn't get lost in the
email trash, as a matter of discipline can one of you submit a patch,
create an issue report

http://wiki.axiom-developer.org/IssueTracker

or make the correction to the online version of the book?

http://wiki.axiom-developer.org/axiom--test--1/src/doc/Book

\start
Date: Sun, 5 Nov 2006 19:58:10 -0800
From: Richard Harke
To: list
Subject: Re: drawRibbons from the book

On Sun November 5 2006 15:49, Vanuxem Gr=E9gory wrote:
> Le dimanche 05 novembre 2006 =E0 11:47 -0800, Richard Harke a =E9crit :
> > I have been working my way through the book.  The first version of
> > drawRibbons (Section 10.2, page 487) seems to work as described.
> > The second version (section 10.3,  page 489) produces some error
> > messages which I don't understand. The following is the session.
> > (after a )clear all)
> >
> >
> >
> > (1) -> )read ribbons
> > drawRibbons(flist, xrange, yrange) ==
> >   sp := createThreeSpace()
> >   num := # flist
> >   yVar := variable yrange
> >   y0:Float := lo segment yrange
> >   width:Float := (hi segment yrange - y0)/num
> >   for f in flist for color in 1..num repeat
> >     makeObject(f, xrange, yVar=y0..y0+width,
> >        var2Steps == 1, colorFunction == (x,y) +-> color,
> >        space == sp)
>
>         ^
> You have to indent this line (it will be be considered as a continuation
> of the previous line) or use an underscore (line continuation
> character), so:
>
>     makeObject(f, xrange, yVar=y0..y0+width,
>        var2Steps == 1, colorFunction == (x,y) +-> color,
>           space == sp)
> or
>
>     makeObject(f, xrange, yVar=y0..y0+width,
>        var2Steps == 1, colorFunction == (x,y) +-> color,_
>        space == sp)
>
> With an underscore the indentation does not matter. I don't know if your
> code used to work in the past.
>
> Greg
Well, that fix does allow the file to load. I have hardbound version
of the book and the underscore is there but is very small and
runs against the line number so I thought it was just a piece of dirt.
I am surprised that the second indenting is required as the line
aboce is at the same nesting level, i.e. parameters to makeObject.

When I try to execute with
drawRibbons([x**i for i in 1..5], x=-1..1, y=0..1)
axiom quietly exits, that is, no error message.
The session looks like

(2) -> drawRibbons([x**i for i in 1..5], x=-1..1, y=0..1)
   Loading /usr/lib/axiom-20050201/algebra/UPMP.o for package
      UnivariatePolynomialMultiplicationPackage
   Loading /usr/lib/axiom-20050201/algebra/SEG.o for domain Segment
   Loading /usr/lib/axiom-20050201/algebra/SEGBIND.o for domain
      SegmentBinding
   Loading /usr/lib/axiom-20050201/algebra/TOPSP.o for package
      TopLevelThreeSpace
   Loading /usr/lib/axiom-20050201/algebra/FLOAT.o for domain Float
   Loading /usr/lib/axiom-20050201/algebra/FPS-.o for domain
      FloatingPointSystem&
   Loading /usr/lib/axiom-20050201/algebra/RNS-.o for domain
      RealNumberSystem&
   Loading /usr/lib/axiom-20050201/algebra/DROPT.o for domain
      DrawOption
   Loading /usr/lib/axiom-20050201/algebra/ANY.o for domain Any
   Loading /usr/lib/axiom-20050201/algebra/SEX.o for domain SExpression

   Loading /usr/lib/axiom-20050201/algebra/DFLOAT.o for domain
      DoubleFloat
   Loading /usr/lib/axiom-20050201/algebra/DRAW.o for package
      TopLevelDrawFunctions
   Loading /usr/lib/axiom-20050201/algebra/VIEW3D.o for domain
      ThreeDimensionalViewport
   Loading /usr/lib/axiom-20050201/algebra/SPACE3.o for domain
      ThreeSpace
   Loading /usr/lib/axiom-20050201/algebra/SUBSPACE.o for domain
      SubSpace
   Loading /usr/lib/axiom-20050201/algebra/POINT.o for domain Point
   Loading /usr/lib/axiom-20050201/algebra/COMPPROP.o for domain
      SubSpaceComponentProperty
   Compiling function drawRibbons with type (List Polynomial Integer,
      SegmentBinding Integer,SegmentBinding NonNegativeInteger) ->
      ThreeDimensionalViewport

I'd be happy to try to debug this but I don't yet have a clue how to go
about it. My intent was to learn how to use it first, then worry about
changing/maintaining, etc.

\start
Date: Sun, 5 Nov 2006 20:17:29 -0800
From: Richard Harke
To: list
Subject: Re: drawRibbons from the book

On Sun November 5 2006 19:11, Bill Page wrote:
> On November 5, 2006 6:59 PM Vanuxem Gr=E9gory wrote:
> > In fact there is an error in the book, the underscore does not need
> > to be escaped.
>
> Although it's small, so this kind of thing doesn't get lost in the
> email trash, as a matter of discipline can one of you submit a patch,
> create an issue report
>
> http://wiki.axiom-developer.org/IssueTracker
>
> or make the correction to the online version of the book?
>
> http://wiki.axiom-developer.org/axiom--test--1/src/doc/Book

There is also a surperfluous \ in the line num := \# flist
I have editted the version per the above url, I think. First
time I have tried this.

\start
Date: Sun, 5 Nov 2006 23:06:39 -0500
From: Tim Daly
To: Richard Harke
Subject: Re: drawRibbons from the book

fixed axiom--silver--1

--- book.pamphlet	Tue Sep 19 23:22:26 2006
+++ book.pamphlet.new	Sun Nov  5 23:05:17 2006
@@ -54451,7 +54451,7 @@
 
 \begin{figure}
 \begin{verbatim}
-drawRibbons(flist, xrange) ==}{}
+drawRibbons(flist, xrange) ==
   sp := createThreeSpace()                     Create empty space $sp$.
   y0 := 0                                      The initial ribbon position.
   for f in flist repeat                        For each function $f$,
@@ -54562,7 +54562,7 @@
 \begin{figure}
 \hrule
 \begin{verbatim}
-drawRibbons(flist, xrange, yrange) ==}{}
+drawRibbons(flist, xrange, yrange) ==
   sp := createThreeSpace()                     Create empty space $sp$.
   num := \# flist                              The number of ribbons.
   yVar := variable yrange                      The ribbon variable.
@@ -54570,7 +54570,7 @@
   width:Float := (hi segment yrange - y0)/num  The width of a ribbon.
   for f in flist for color in 1..num repeat    For each function $f$,
     makeObject(f, xrange, yVar = y0..y0+width, create and add ribbon to
-      var2Steps == 1, colorFunction == (x,y) +-> color, \_
+      var2Steps == 1, colorFunction == (x,y) +-> color, _
       space == sp)                             $sp$ of a different color.
     y0 := y0 + width                           The next ribbon coordinate.
   vp := makeViewport3D(sp, "Ribbons")          Create viewport.

\start
Date: Sun, 5 Nov 2006 23:17:43 -0500
From: Tim Daly
To: Richard Harke
Subject: Re: drawRibbons from the book

fixed in axiom--silver--1

--- book.pamphlet	Sun Nov  5 23:15:52 2006
+++ book.pamphlet.new	Sun Nov  5 23:16:05 2006
@@ -54564,7 +54564,7 @@
 \begin{verbatim}
 drawRibbons(flist, xrange, yrange) ==}{}
   sp := createThreeSpace()                     Create empty space $sp$.
-  num := \# flist                              The number of ribbons.
+  num := # flist                               The number of ribbons.
   yVar := variable yrange                      The ribbon variable.
   y0:Float    := lo segment yrange             The first ribbon coordinate.
   width:Float := (hi segment yrange - y0)/num  The width of a ribbon.

\start
Date: Sun, 5 Nov 2006 20:40:24 -0800
From: Richard Harke
To: list
Subject: Re: drawRibbons from the book

On Sun November 5 2006 20:17, Richard Harke wrote:
> On Sun November 5 2006 19:11, Bill Page wrote:
> > On November 5, 2006 6:59 PM Vanuxem Gr=E9gory wrote:
> > > In fact there is an error in the book, the underscore does not need
> > > to be escaped.
> >
> > Although it's small, so this kind of thing doesn't get lost in the
> > email trash, as a matter of discipline can one of you submit a patch,
> > create an issue report
> >
> > http://wiki.axiom-developer.org/IssueTracker
> >
> > or make the correction to the online version of the book?
> >
> > http://wiki.axiom-developer.org/axiom--test--1/src/doc/Book
>
> There is also a surperfluous \ in the line num := \# flist
> I have editted the version per the above url, I think. First
> time I have tried this.
> Richard
I guess I didn't. The following is the last thing I got

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request
POST /axiom--test--1/src/doc/Book.

Reason: Error reading from remote server

Additionally, a 502 Bad Gateway error was encountered while trying to use a=
n
ErrorDocument to handle the request.

\start
Date: Sun, 5 Nov 2006 23:33:52 -0500
From: Tim Daly
To: Richard Harke
Subject: Re: drawRibbons from the book

Richard,

The proper procedure for making changes to the sources is:

1) find the bug in the file foo.pamphlet
2) fix the bug and save it in foo.pamphlet.new
3) diff -Naur foo.pamphlet foo.pamphlet.new >foo.pamphlet.patch
4) send foo.pamphlet.patch to the list

In this case I've already fixed the typos. 
Thanks for the report.

\start
Date: Mon, 6 Nov 2006 00:34:50 -0500
From: Alfredo Portes
To: Bill Page
Subject: Axiom Binaries

I started working on the modifications to the
http://wiki.axiom-developer.org/AxiomBinaries page.

The initial try is in: http://wiki.axiom-developer.org/SandBoxDoyen

I added the table, but reversed the columns and the rows. Much work
is needed on the page, and suggestions are welcome.

AxiomBinaries contains a lot of useful information, but it is just too much
for one page.

I also want to add info from http://wiki.axiom-developer.org/SilverBinaries

\start
Date: Mon, 6 Nov 2006 00:36:20 -0500
From: Bill Page
To: Tim Daly
Subject: FW: [book] more verbatim #

-----Original Message-----
From: Bill Page [mailto:mathaction-bounces@axiom-developer.org]
Sent: November 6, 2006 12:27 AM
To: MathAction
Subject: [book] more verbatim #


--

??changed:
   showRegion(vp,"on")                          Enclose in a box.
-  n := \# flist                                The number of ribbons
+  n := # flist                                 The number of ribbons
   zoom(vp,n,1,n)                               Zoom in x- and =
z-directions.

??changed:
   sp := createThreeSpace()                     Create empty space =
$sp$.
-  num := # flist                              The number of ribbons.
+  num := # flist                               The number of ribbons.
   yVar := variable yrange                      The ribbon variable.

??changed:
   vl := variables f                            The list of variables
-  nv := \# vl                                  The number of =
variables
+  nv := # vl                                   The number of =
variables
   nv > 1 => error "Expression is not univariate."

??changed:
     arrowAngle : DFLOAT := pi()-pi()/(20::DFLOAT)        Local =
variable 2
-    realSteps  : INT := 11 --\# real steps               Local =
variable 3
-    imagSteps  : INT := 11 --\# imaginary steps          Local =
variable 4
+    realSteps  : INT := 11 --# real steps                Local =
variable 3
+    imagSteps  : INT := 11 --# imaginary steps           Local =
variable 4
     clipValue  : DFLOAT  := 10::DFLOAT --maximum vector length

??changed:
     bubbleSort!(m,f) ==
-      n := \#m
+      n := #m
       for i in 1..(n-1) repeat

??changed:
     insertionSort!(m,f) ==
-      for i in 2..\#m repeat
+      for i in 2..#m repeat
         j := i

\start
Date: Mon, 6 Nov 2006 00:39:33 -0500
From: Bill Page
To: Richard Harke
Subject: RE: drawRibbons from the book

On November 5, 2006 11:40 PM you wrote:
> >
> > There is also a surperfluous \ in the line num := \# flist
> > I have editted the version per the above url, I think. First
> > time I have tried this.
> > Richard
> I guess I didn't.

Actually your change to

http://wiki.axiom-developer.org/axiom--test--1/src/doc/Book

did work.

The following error was caused by me while correcting a different
problem on the server:

> The following is the last thing I got
> 
> Proxy Error
> 
> The proxy server received an invalid response from an upstream server.
> The proxy server could not handle the request 
> POST /axiom--test--1/src/doc/Book.
> 
> Reason: Error reading from remote server
> 
> Additionally, a 502 Bad Gateway error was encountered while 
> trying to use an 
> ErrorDocument to handle the request.
> 

Sorry. It should be ok now. Please let me know if it happens again.

Thanks for the edit.

\start
Date: Mon, 6 Nov 2006 00:45:05 -0500
From: Bill Page
To: Waldek Hebisch
Subject: RE: Ping: file removals

On November 5, 2006 2:03 PM Waldek Hebisch wrote:
> 
> > > | generated documentation files:
> > > | 
> > > |  src/doc/bookvol1.pdf
> > > 
> > > this call is slighlty harder.  We don't generate PDFs at 
> > > the moment (but we should), and this is a copy of a book
> > > already published.  So the question is how "authentic" we
> > > want the copy in SVN to be. Personnaly, I would go for its
> > > complete deletion, augment the build machinery to generate
> > > PDF for documentation.  (I'm planning to put in the PDF
> > > generation anyway).
> > 

I agree. In general there should not be any pdf files in the source
code repository.

> ...
> Additionaly we can provide .pdf on Axiom web site. 

See http://wiki.axiom-developer.org/axiom--test--1/src/doc/Bookvol1

> 
> One extra remark:  It make sense to put generated documentation
> into distribution tarball, but IMHO generated files (with the 
> exception of files needed to bootstrap) should be removed from
> source archive.

Yes, I agree completely.

> ...

\start
Date: Mon, 6 Nov 2006 01:30:49 -0500
From: Tim Daly
To: Bill Page
Subject: Re: FW: [book] more verbatim #

patched in axiom--silver--1


--- book.pamphlet	Sun Nov  5 23:19:25 2006
+++ book.pamphlet.new	Mon Nov  6 01:23:12 2006
@@ -14174,7 +14174,7 @@
 
 \begin{verbatim}
 greatGrandParents == [x for x in people |
-  reduce(\_or,
+  reduce(_or,
     [not empty? children(y) for y in grandchildren(x)],false)]
 \end{verbatim}
 \returnType{Type: Void}
@@ -54462,7 +54462,7 @@
   drawStyle(vp, "shade")                       Select shading style.
   outlineRender(vp, "on")                      Show polygon outlines.
   showRegion(vp,"on")                          Enclose in a box.
-  n := \# flist                                The number of ribbons
+  n := # flist                                 The number of ribbons
   zoom(vp,n,1,n)                               Zoom in x- and z-directions.
   rotate(vp,0,75)                              Change the angle of view.
   vp                                           Return the viewport.
@@ -54725,7 +54725,7 @@
 Here is a program to draw a bouquet of $n$ arrows.
 
 \begin{verbatim}
-drawBouquet(n,title) ==}{}
+drawBouquet(n,title) ==
   angle := 0.0@DFLOAT                          The initial angle
   sp := createThreeSpace()                     Create empty space $sp$
   for i in 0..n-1 repeat                       For each index i, create:
@@ -54961,7 +54961,7 @@
   real := lo(realRange)                            The initial real value
   for i in 1..realSteps+1 repeat                   Begin real iteration
     imag := lo(imagRange)                          initial imaginary value
-    lp := []\$(List Point DFLOAT)                  initial list of points $lp$
+    lp := []$(List Point DFLOAT)                   initial list of points $lp$
     for j in 1..imagSteps+1 repeat                 Begin imaginary iteration
       z := f complex(real,imag)                    value of $f$ at the point
       pt := point [real,imag, clipFun sqrt norm z, Create a point
@@ -55101,7 +55101,7 @@
 
 complexNumericFunction f ==                    Turn an expression $f$ into a
   v := theVariableIn f                         function
-  compiledFunction(f, v)\$complexFunPack
+  compiledFunction(f, v)$complexFunPack
 
 complexDerivativeFunction(f,n) ==              Create an nth derivative
   v := theVariableIn f                         function
@@ -55110,7 +55110,7 @@
 
 theVariableIn f ==                             Returns the variable in $f$
   vl := variables f                            The list of variables
-  nv := \# vl                                  The number of variables
+  nv := # vl                                   The number of variables
   nv > 1 => error "Expression is not univariate."
   nv = 0 => 'x                                 Return a dummy variable
   first vl
@@ -55276,8 +55276,8 @@
   Implementation == add                           Implementation part begins
     arrowScale : DFLOAT := (0.2)::DFLOAT --relative size Local variable 1
     arrowAngle : DFLOAT := pi()-pi()/(20::DFLOAT)        Local variable 2
-    realSteps  : INT := 11 --\# real steps               Local variable 3
-    imagSteps  : INT := 11 --\# imaginary steps          Local variable 4
+    realSteps  : INT := 11 --# real steps                Local variable 3
+    imagSteps  : INT := 11 --# imaginary steps           Local variable 4
     clipValue  : DFLOAT  := 10::DFLOAT --maximum vector length
                                                          Local variable 5
 
@@ -55705,13 +55705,13 @@
 
   Implementation == add
     bubbleSort!(m,f) ==
-      n := \#m
+      n := #m
       for i in 1..(n-1) repeat
         for j in n..(i+1) by -1 repeat
           if f(m.j,m.(j-1)) then swap!(m,j,j-1)
       m
     insertionSort!(m,f) ==
-      for i in 2..\#m repeat
+      for i in 2..#m repeat
         j := i
         while j > 1 and f(m.j,m.(j-1)) repeat
           swap!(m,j,j-1)
@@ -55755,8 +55755,8 @@
   Implementation == add
        ...
     if S has OrderedSet then
-      bubbleSort!(m) == bubbleSort!(m,<\$S)
-      insertionSort!(m) == insertionSort!(m,<\$S)
+      bubbleSort!(m) == bubbleSort!(m,<$S)
+      insertionSort!(m) == insertionSort!(m,<$S)
 \end{verbatim}
 
 In \ref{ugUserBlocks} on page~\pageref{ugUserBlocks}, 
@@ -56047,7 +56047,7 @@
 \begin{verbatim}
 SetCategory(): Category ==
    Join(Type,CoercibleTo OutputForm) with
-      "=" : (\$, \$) -> Boolean
+      "=" : ($, $) -> Boolean
 \end{verbatim}
 
 The definition starts off with the name of the
@@ -56166,7 +56166,7 @@
 
 SetCategory(): Category ==
   Join(Type, CoercibleTo OutputForm) with
-    "=": (\$, \$) -> Boolean
+    "=": ($, $) -> Boolean
       ++ \bs{}axiom\{x = y\} tests if \bs{}axiom\{x\} and
       ++ \bs{}axiom\{y\} are equal.
 \end{verbatim}
@@ -56229,8 +56229,8 @@
 
 \begin{verbatim}
 SemiGroup(): Category == SetCategory with
-      "*":  (\$,\$) -> \$
-      "**": (\$, PositiveInteger) -> \$
+      "*":  ($,$) -> $
+      "**": ($, PositiveInteger) -> $
 \end{verbatim}
 
 This definition is as simple as that for {\tt SetCategory},
@@ -56316,11 +56316,11 @@
 
 \begin{verbatim}
 SemiGroup(): Category == SetCategory with
-      "*": (\$, \$) -> \$
-      "**": (\$, PositiveInteger) -> \$
+      "*": ($, $) -> $
+      "**": ($, PositiveInteger) -> $
     add
-      import RepeatedSquaring(\$)
-      x: \$ ** n: PositiveInteger == expt(x,n)
+      import RepeatedSquaring($)
+      x: $ ** n: PositiveInteger == expt(x,n)
 \end{verbatim}
 
 The $add$ part at the end is used to give ``default definitions'' for
@@ -56375,13 +56375,13 @@
 {\tt SemiGroup}.
 
 \begin{verbatim}
-SemiGroup\_\&(\$): Exports == Implementation where
-  \$: SemiGroup
+SemiGroup_&($): Exports == Implementation where
+  $: SemiGroup
   Exports == with
-    "**": (\$, PositiveInteger) -> \$
+    "**": ($, PositiveInteger) -> $
   Implementation == add
-    import RepeatedSquaring(\$)
-    x:\$ ** n:PositiveInteger == expt(x,n)
+    import RepeatedSquaring($)
+    x:$ ** n:PositiveInteger == expt(x,n)
 \end{verbatim}
 
 \section{Axioms}
@@ -56526,13 +56526,13 @@
 
 \begin{verbatim}
 Ring(): Category ==
-  Join(Rng,Monoid,LeftModule(\$: Rng)) with
+  Join(Rng,Monoid,LeftModule($: Rng)) with
       characteristic: -> NonNegativeInteger
-      coerce: Integer -> \$
+      coerce: Integer -> $
       unitsKnown
     add
       n:Integer
-      coerce(n) == n * 1\$\$
+      coerce(n) == n * 1$$
 \end{verbatim}
 
 There are only two new things here.
@@ -56632,7 +56632,7 @@
 QuotientFieldCategory(R) : Category == ... with ...
      if R has OrderedSet then OrderedSet
      if R has IntegerNumberSystem then
-       ceiling: \$ -> R
+       ceiling: $ -> R
          ...
 \end{verbatim}
 
@@ -56807,10 +56807,10 @@
         ++ \bs{}axiom\{quadraticForm(m)\} creates a quadratic
         ++ quadratic form from a symmetric,
         ++ square matrix \bs{}axiom\{m\}.
-      matrix: \$ -> SquareMatrix(n,K)       -- export matrix
+      matrix: $ -> SquareMatrix(n,K)       -- export matrix
         ++ \bs{}axiom\{matrix(qf)\} creates a square matrix
         ++ from the quadratic form \bs{}axiom\{qf\}.
-      elt: (\$, DirectProduct(n,K)) -> K    -- export elt
+      elt: ($, DirectProduct(n,K)) -> K    -- export elt
         ++ \bs{}axiom\{qf(v)\} evaluates the quadratic form
         ++ \bs{}axiom\{qf\} on the vector \bs{}axiom\{v\},
         ++ producing a scalar.
@@ -57507,19 +57507,19 @@
 PI ==> PositiveInteger
 Database(S): Exports == Implementation where
   S: Object with 
-    elt: (\$, Symbol) -> String
-    display: \$ -> Void
-    fullDisplay: \$ -> Void
+    elt: ($, Symbol) -> String
+    display: $ -> Void
+    fullDisplay: $ -> Void
 
   Exports == with
-    elt: (\$,QueryEquation) -> \$                   Select by an equation
-    elt: (\$, Symbol) -> DataList String            Select by a field name
-    "+": (\$,\$) -> \$                              Combine two databases
-    "-": (\$,\$) -> \$                              Subtract one from another
-    display: \$ -> Void                             A brief database display
-    fullDisplay: \$ -> Void                         A full database display
-    fullDisplay: (\$,PI,PI) -> Void                 A selective display
-    coerce: \$ -> OutputForm                        Display a database
+    elt: ($,QueryEquation) -> $                     Select by an equation
+    elt: ($, Symbol) -> DataList String             Select by a field name
+    "+": ($,$) -> $                                 Combine two databases
+    "-": ($,$) -> $                                 Subtract one from another
+    display: $ -> Void                              A brief database display
+    fullDisplay: $ -> Void                          A full database display
+    fullDisplay: ($,PI,PI) -> Void                  A selective display
+    coerce: $ -> OutputForm                         Display a database
   Implementation == add
       ...
 \end{verbatim}
@@ -57621,15 +57621,15 @@
 \begin{verbatim}
 QueryEquation(): Exports == Implementation where
   Exports == with
-    equation: (Symbol, String) -> \$
-    variable: \$ -> Symbol
-    value:\ \ \ \ \$ -> String
+    equation: (Symbol, String) -> $
+    variable: $ -> Symbol
+    value: $ -> String
 
   Implementation == add
     Rep := Record(var:Symbol, val:String)
     equation(x, s) == [x, s]
     variable q == q.var
-    value\ \ \ \ q == q.val
+    value q == q.val
 \end{verbatim}
 
 Axiom converts an input expression of the form
@@ -65031,8 +65031,8 @@
   sx2 := sin(x/2)
   cx2 := cos(x/2)
   sq2 := sqrt(2.0@DFLOAT)
-  point [cx * (cx2 * (sq2 + cy) + (sx2 * sy * cy)), \_
-         sx * (cx2 * (sq2 + cy) + (sx2 * sy * cy)), \_
+  point [cx * (cx2 * (sq2 + cy) + (sx2 * sy * cy)), _
+         sx * (cx2 * (sq2 + cy) + (sx2 * sy * cy)), _
          -sx2 * (sq2 + cy) + cx2 * sy * cy]
 
 draw(klein, 0..4*\%pi, 0..2*\%pi, var1Steps==50,       Figure-8 Klein bottle
@@ -65081,7 +65081,7 @@
                                                    respectively.
 
 draw(gam, -\%pi..\%pi, -\%pi..\%pi,                The Gamma Function
-     title == "Gamma(x + \%i*y)", \_
+     title == "Gamma(x + \%i*y)", _
      var1Steps == 100, var2Steps == 100)
 
 b(x,y) == Beta(x,y)
@@ -65376,8 +65376,8 @@
 \begin{verbatim}
 ntubeDraw: (ThreeCurve,TwoCurve,S,S) -> VIEW3D
 ntubeDraw(spaceCurve,planeCurve,uRange,tRange) ==
-  ntubeDrawOpt(spaceCurve, planeCurve, uRange, \_
-               tRange, []\$List DROPT)
+  ntubeDrawOpt(spaceCurve, planeCurve, uRange, _
+               tRange, []$List DROPT)
 
 ntubeDrawOpt: (ThreeCurve,TwoCurve,S,S,List DROPT)
     -> VIEW3D
@@ -65410,7 +65410,7 @@
       error "Frenet Frame not well defined"
   n := (1/ln)*n                              Make into unit length vectors
   b := (1/lb)*b
-  [f0, t0, n, b]\$FrenetFrame
+  [f0, t0, n, b]$FrenetFrame
 \end{verbatim}
 
 {\bf ngeneralTube}{\it (spaceCurve, planeCurve,}{\it  delT, oltT)}
@@ -65456,7 +65456,7 @@
   m2 * inverse(m1)                              in 3-space
 
 makeColumnMatrix(t) ==                          Put the vertices of a tetra-
-  m := new(4,4,0)\$DHMATRIX(DFLOAT)             hedron into matrix form
+  m := new(4,4,0)$DHMATRIX(DFLOAT)              hedron into matrix form
   for x in t for i in 1..repeat
     for j in 1..3 repeat
       m(j,i) := x.j

\start
Date: Mon, 6 Nov 2006 01:57:16 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Ping: file removals

> I agree. In general there should not be any pdf files in the source
> code repository.

Eh? Methinks you've missed the whole point of aim of the axiom project.

Documentation in any form is to be desired and it often cannot be
created "from the source". PDFs can contain things, like fonts, which
the target machine may not have available. Video documentation will
certainly not be able to be created from the source as the rendering
of the video may require special equipment and tools.

The user might not have tools, like dvitopdf, or have different tools,
like dvi2pdf giving different results. Or the user might be on windows
without these tools at all. And if a 10 minute tutorial takes weeks to
create and hours to render with special tools (e.g. Camtasia) why
would we want the user to do that?  Why rerender .ps files that
exist? There are already complaints posted that axiom takes too long
to build.


I must say I'm completely confused by the current directions.
Who invented the idea that we need to recreate everything from source?
And who invented the idea that we don't keep exact copies of published
documentation (with ISBN numbers) in the archive?






> > One extra remark:  It make sense to put generated documentation
> > into distribution tarball, but IMHO generated files (with the 
> > exception of files needed to bootstrap) should be removed from
> > source archive.
> 
> Yes, I agree completely.

Again, methinks you've missed the whole point of the axiom project.

There is NO distinction between documentation and "source code". That is
oldthink. In this brave new world there are only literate programs.
Creating human readable output from human oriented input is THE soul
of the project. We need to completely entwine the research with the old
idea of source code and conflate the idea of compiling with the idea of
latexing the code. This is THE PRIMARY DESIGN GOAL of the axiom project.

Gaby and Waldek, you are both new to this project but it has now been
around for some 33+ years and free for the last 6 years. Under the guise
of "build improvements", which was originally started as an effort to
bring autoconf to axiom, I now see changes made and proposed that go
against the fundamental project goals. Please look around, read and
understand these goals. They've been written down and talked about
at length both in this group and online at various places.

\start
Date: 06 Nov 2006 08:34:04 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Aldor compilation for Axiom

Ralf Hemmecke writes:

> Hello,
> 
> could someone tell me what ")compile blah.as" is actually doing in Axiom?
> 
> It is certainly more than saying
> 
> aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y
> $AXIOM/algebra blah.as
> 
> (without having an Axiom session running).
> 
> I think someone once said that )compile calls aldor with the above flags and
> then also generates object files from the .lsp files. How could I achieve that
> from outside Axiom? Or is it enough to provide the .lsp files and the
> compilation to object files is triggered when the code is first used?
> 
> Further, I actually have a whole library (several .as files). What would be the
> right procedure to compile them externally (I want to do that via Makefiles)
> and then provide some nice mechanism to load the compiled library into Axiom.
> 
> I just need a rough overview.

If you say

> aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y
> $AXIOM/algebra blah.as

then

axiom

then

)lib blah

it should work. I guess that in this case the lisp is interpreted rather than
compiled. But usually, that doesn't matter anyway, at least not for
development.

Unfortunately,

)lib )dir .

(as described in HyperDoc) doesn't work properly in this case, I have no idea
why. The signatures seem to get loaded, but calling a function makes axiom
stumble.

\start
Date: 06 Nov 2006 09:01:18 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Ping: file removals

Tim Daly writes:

[...]

| Documentation in any form is to be desired and it often cannot be
| created "from the source".

If you cannot reproduce the documentation from the source, then the
source is incomplete and must be completed.  

[...]

| Gaby and Waldek, you are both new to this project but it has now been
| around for some 33+ years and free for the last 6 years.

Please, don't fool yourself into thinking that "being new to a
project" is equivalent to "being new to software development and
management for the real world".  It is not all about "being around for
long time".

| Under the guise
| of "build improvements", which was originally started as an effort to
| bring autoconf to axiom, I now see changes made and proposed that go
| against the fundamental project goals.

If you feel you must accuse people of evil intentions, please be more
specific.  Otherwise, you are harming more than doing any good.
I would invite you to be more specific in your accusations and write
specifically what is being disguised, for the purpose of going against
the projects goals.

[...]

| Please look around, read and
| understand these goals. They've been written down and talked about
| at length both in this group and online at various places.

Not just people don't agree with your particular choice of
*implementations* of ideas means that they don't understand the ideas.
Please try the assumption that people understand the fundamental
ideas, and if they happen not to agree with your particular
implementation then maybe:
  (1) there is more than one way to do it; or
  (2) your implementation is really questionable.

\start
Date: Mon, 6 Nov 2006 06:05:58 -0500
From: Alfredo Portes
To: Tim Daly
Subject: Re: Ping: file removals

On 11/6/06, Tim Daly wrote:
> > I agree. In general there should not be any pdf files in the source
> > code repository.
>
> Eh? Methinks you've missed the whole point of aim of the axiom project.
>

Sorry, but I felt I have to give my 2 cent on this. Tim, I think everybody on
the project understands the goals of Axiom :-), specially Bill.

I think what Bill and Waldek are saying is that pdf's, dvis, ps files
should be available to the user by another medium (www, etc...) and
not the SCM programs.

I do not think this contradicts in any way the concept of LP and the
Axiom goals.

\start
Date: Mon, 6 Nov 2006 14:44:32 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: Ping: file removals

> > I agree. In general there should not be any pdf files in the source
> > code repository.
> 
> Eh? Methinks you've missed the whole point of aim of the axiom project.
>

Tim, first I must question your monopoly on stating Axiom goals. 
In open source project all members choose goals.  If members
goals are fundamentally incompatible, then there is time to fork.
However, (as I belive is in Axiom case) if goals differ slightly,
it should be possible to work togehter (compromising on lesser
goals if needed).

Secondly, I read many times what you wrote about Axiom goals and
I find it still not clear -- there are nice dreams (which I share
with you) and implementation strategy (which I doubt will work).
 
> I must say I'm completely confused by the current directions.
> Who invented the idea that we need to recreate everything from source?
> And who invented the idea that we don't keep exact copies of published
> documentation (with ISBN numbers) in the archive?
> 

I think here is crucial misconception: what I (and other people) propose
is separation of SCM and Axiom distribution.  Typical user will
fetch _distribution_.  Exact content of distribution may be discussed
separately, but the point is that distribution should be usable
"immediatly" (or maybe with minimal effort).  Axiom servers should
archive past distribitions -- from may point of view it is not
very important how (dated tarballs, blobs in datbase or version
contrion could do that).  SCM should contain just source.

If sombody thinks that we should distribute a Git pack containing
full Axiom archive (including history), I have nothing against
it (as long as int in not the only distribition format).
 
> > > One extra remark:  It make sense to put generated documentation
> > > into distribution tarball, but IMHO generated files (with the 
> > > exception of files needed to bootstrap) should be removed from
> > > source archive.
> > 
> > Yes, I agree completely.
> 
> Again, methinks you've missed the whole point of the axiom project.
> 
> There is NO distinction between documentation and "source code". That is
> oldthink. In this brave new world there are only literate programs.
> Creating human readable output from human oriented input is THE soul
> of the project. We need to completely entwine the research with the old
> idea of source code and conflate the idea of compiling with the idea of
> latexing the code. This is THE PRIMARY DESIGN GOAL of the axiom project.
>

Tim, I am affraid that the newspeak does not allow you to say clearly
what you want.  For me compilation is basicaly freezing some aspects
of source and caching intermediate low-level data to gain execution
efficiency.  Now, human oriented input means that we really _do not
want_ latexing as extra step: Axiom content should be presented in
optimal way without any extra effort.  Similarly with compilation:
the user should see human oriented input and the final result, while
the intermediate data should be hidden.  

Whith this in mind, can you sincerely say that machine generated
Lisp is a "human oriented output"?  We may wish to show some
specimens of machine generated Lisp to illustrate how the compiler
works, but the bulk of it belongs to a special ghetto.
 
\start
Date: 06 Nov 2006 08:50:03 -0500
From: Camm Maguire
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page writes:

> Camm,
> 
> On November 2, 2006 9:22 AM you wrote:
> > ...
> > Bill Page wrote:
> > > 
> > > Here is a recipe that seems to work for me and avoids reference
> > > to fink or other non-gcl related libraries:
> > > 
> > >  $ export
> LIBRARY_PATH=/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/binutils/intl
> > >  $ make clean
> > >  $ ./configure --prefix=/usr/local --enable-locbfd 
> > --disable-statsysbfd
> > >  $ make
> > >  $ make install
> > > 
> > 
> > locbfd should be the default on macosx, as we have Aurelien's specific
> > mods for .o file loading.
> 
> Something subtle is still not right about this. If I omit --enable-locbfd
> from the .configure then I get problems later gettext (unless gettext
> is already installed elsewhere).
> 
> But worse is this:
> 
>  $ export
> LIBRARY_PATH=/home/users/b/bi/billpage/osx/new/gcl-2.6.8pre/binutils/intl
> 
> Something is strange about the way that gcl links to libintl.
> On MAC OS if I do not include LIBRARY_PATH and if libintl is
> not in the system default path, then building gcl fails.
> 
> If I do include the 'export LIBRARY_PATH ..." then the build
> succeeds but loading this library is "dynamic". This causes
> trouble later if I try to use gcl to build Axiom without first
> setting LIBRARY_PATH. Isn't there some way to force the MAC
> to static link this library?

OK, I've commited the removal of -lintl from powerpc-macosx.defs from
both branches.  This and the --disable-nls which is now in
configure.in and passed to the binutils subconfigures should remove
the above.  I.e. ./configure --prefix=...  should work, if anyone has
a moment to verify.

\start
Date: 06 Nov 2006 08:51:49 -0500
From: Camm Maguire
To: Humberto Zuazaga
Subject: re: sock_get_string_buf

Greetings and thanks!  This should be in cvs now.

Take care,

Humberto Zuazaga writes:

> Camm Maguire wrote:
> > 
> > Without any path setting?  In any case, I jsut checked, and it just
> > skips the msgfmt calls now, the libintl et.al. stuff is the same.
> 
> I still was having problems with libintl not being found, I finally
> figured out that my makedefs file still had -lintl, I think we need to
> change h/powerpc-macosx.defs:
> 
> Index: h/powerpc-macosx.defs
> ===================================================================
> RCS file: /sources/gcl/gcl/h/powerpc-macosx.defs,v
> retrieving revision 1.2.2.3.4.1.10.1
> diff -a -u -r1.2.2.3.4.1.10.1 powerpc-macosx.defs
> --- h/powerpc-macosx.defs       18 Oct 2006 17:08:56 -0000
> 1.2.2.3.4.1.10.1
> +++ h/powerpc-macosx.defs       2 Nov 2006 23:16:54 -0000
> @@ -6,7 +6,7 @@
> 
>  # Set this to avoid warnings when linking against libncurses.
>  # This is due to the requirements of the two level namespace.
> -LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'` -lintl
> +LIBS := `echo $(LIBS) | sed -e 's/-lncurses/ /'`
> 
>  # Set this for the linker to operate correctly.
>  MACOSX_DEPLOYMENT_TARGET = 10.2
> 
> now gcl-2.6.8pre builds on my PowerPC Mac OS X 10.4.8 machine.
> 
> -- 
> Humberto Ortiz-Zuazaga
> Programmer-Archaeologist
> University of Puerto Rico
> http://www.hpcf.upr.edu/~humberto/
> 
> 

\start
Date: Mon, 6 Nov 2006 08:52:26 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Ping: file removals

On November 6, 2006 1:57 AM Tim Daly wrote:
> Bill Page wrote: 
> > I agree. In general there should not be any pdf files in the
> > source code repository.
> 
> Eh? Methinks you've missed the whole point of aim of the axiom
> project.

I certainly don't think so. I am only talking about the Axiom source
code repository, not the Axiom project as a whole. The source code
repository is the part of the Axiom project that contains the Axiom
source code. Period.

> 
> Documentation in any form is to be desired and it often cannot be
> created "from the source".

True. Documentation is not source code but source code i.e. pamphlet
files, can be used to create some of the Axiom documentation.

> PDFs can contain things, like fonts, which the target machine may
> not have available. Video documentation will certainly not be able
> to be created from the source as the rendering of the video may
> require special equipment and tools.

True.

> 
> The user might not have tools, like dvitopdf, or have different
> tools, like dvi2pdf giving different results. Or the user might
> be on windows without these tools at all.

We are talking about the source code repository. For someone to
use this repository they will have to have appropriate tools for
the types of products they expect to create from this source.

> And if a 10 minute tutorial takes weeks to create and hours to
> render with special tools (e.g. Camtasia) why would we want the
> user to do that?

I don't want the user to do that. They should be able to just
click on a hyperlink and listen, watch or read.

> Why rerender .ps files that exist? There are already complaints
> posted that axiom takes too long to build.

The build should only produce those products that the user asks for
and the things required to make these products, recursively, from
the source. Of course these intermediate products can be cached
during the build but should not be retained in the repository. In
addition the source code repository should not contain anything
that is pre-generated by some means not available in the source.

> 
> 
> I must say I'm completely confused by the current directions.
> Who invented the idea that we need to recreate everything from
> source?

Not me. I am only talking about the source code repository.

> And who invented the idea that we don't keep exact copies of
> published documentation (with ISBN numbers) in the archive?
>

I did not say we don't keep exact copies of published documentation.
I just said it doesn't belong in the source code repository.
 
> 
> > > One extra remark:  It make sense to put generated documentation
> > > into distribution tarball, but IMHO generated files (with the 
> > > exception of files needed to bootstrap) should be removed from
> > > source archive.
> > 
> > Yes, I agree completely.
> 
> Again, methinks you've missed the whole point of the axiom project.
>

You are wrong.
 
> There is NO distinction between documentation and "source code".

Yes there is. You just said yourself above that there are things
that we want to call documentation that can not generated from an
source code.

> That is oldthink. In this brave new world there are only literate
> programs.

I have no problem at all with "literate programs", but I agree with
your first statement about this (that there are important kinds of
documentation that can not be created from any source) rather than
you second statement. Not all things are literate programs.

> Creating human readable output from human oriented input is THE
> soul of the project.

Well I agree that it is an important aspect. I don't see any
conflict with the proposal to only keep source code in the source
code repository.

> We need to completely entwine the research with the old idea of
> source code and conflate the idea of compiling with the idea of
> latexing the code. This is THE PRIMARY DESIGN GOAL of the axiom
> project.

I agree with the philosophy of literate programming.

> 
> Gaby and Waldek, you are both new to this project but it has now
> been around for some 33+ years and free for the last 6 years. 
> Under the guise of "build improvements", which was originally
> started as an effort to bring autoconf to axiom, I now see changes
> made and proposed that go against the fundamental project goals.

I strongly disagree with you. I think both Gaby and Waldek have
made an extraordinary contribution to ensuring that the Axiom
project does not sink into a self-made blackhole. As far as I can
the work they are doing is the only viable way forward.

> Please look around, read and understand these goals. They've
> been written down and talked about at length both in this group
> and online at various places.
> 

I agree with all of the goals but I disagree on a number of
specific points about how you think we should achieve them.

\start
Date: 06 Nov 2006 08:59:36 -0500
From: Camm Maguire
To: Waldek Hebisch
Subject: re: Bug#346552: naive methods of exiting axiom	can blow up catastrophically
Cc: Tom Hargreaves

Greetings, and thanks for looking into this!

Waldek Hebisch writes:

> I wrote:
> > root wrote:
> > > Apparently the ptys are opened in raw mode and do not interpret the
> > > control characters but pass them down the pipe to AXIOMsys. However
> > > the (read) from axiom simply gets the cntrl-D and tries to parse it.
> > > 
> > > I'm not really sure how this should be handled. Clearly you don't
> > > want sman to open up a pty that interprets control characters.
> > > Nor do you want lisp's (read) to interpret control characters.
> > > 
> > 
> > It is not the case.  One thing is a bug in sman: when the user
> > presses ^D\n sman passes "(1) ->\n" (more precisly AXIOMsys
> > reads what is inside quotes).  AXIOMsys reacts with an error
> > message (exactly like if user gave this input).
> 
> I tracked the problem one step further:
> 
> There is a bug in 'sockio-c.c.pamphlet'. Namely, 'remote_stdio'
> function contains the following code:
> 
>     if (FD_ISSET(0, &rd)) {
>       fgets(buf,1024,stdin);
>       len = strlen(buf);
>       /*
>           gets(buf);
>           len = strlen(buf);
>           *(buf+len) = '\n';
>           *(buf+len+1) = '\0';
>       */
>       swrite(sock, buf, len, "writing to remote stdin");
> 
> If we have EOF on stdin fgets reads nothing and the old content
> of 'buf' (containing the last AXIOMsys output!) is sent back to
> AXIOMsys.  I am not sure what the correct fix is: we can easily
> detect EOF, but we can not just exit: to exit we have kill
> the whole tree of processes spawned by 'sman'.  The code above
> is executed from 'spadclient' and it is possible to have
> more than one copy of 'spadclient' connected to one AXIOMsys,
> so we probably should track number of connected clients
> and exit AXIOMsys when number of clients goes down to zero
> (but we have to be careful at startup, as for short time
> there is no client).
> 

It seems that ^D can only be read from the AXIOMsys terminal, which I
think should cause an exit of that AXIOMsys.  This will close the
socket, so that sman or spadclient should be able to have read return
0, which should then cause it to close that connection on its end
too.  When this should cause a general exit from sman is beyond me --
perhaps there is useful work that can be done with just the hypertex
up but no console.  Personally, I don't think it too egregious to
terminate everything when the 'master' axiom sys (i.e. the first one
opened') reads EOF.

\start
Date: 06 Nov 2006 09:01:18 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: lastest tests

Thank you so much Tim!  The intl patch is in now.

Are we also OK on windows?  And I guess the last, which may not be
that important anymore, is sparc solaris.

Take care,

Tim Daly writes:

> I did a checkout of
> 
> cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
> With the patch to remove the -lintl from h/powerpc-macosx.defs LIBS line
> ./configure --enable-locbfd --disable-statsysbfd --disable-nls
> make
> ./bin/gcl
> (setq a 3)
> (system::save-system "test")
> ./test
> a
> yields 3
> 
> 
> successfully builds and saves on MAC OSX PPC
> successfully builds and saves on FreeBSD
> successfully builds and saves on Debian
> successfully builds and saves on Ubuntu
> successfully builds and saves on Fedora 4
> successfully builds and saves on Fedora 5
> successfully builds and saves on Fedora 6
> successfully builds and saves on RedHat 9
> successfully builds and saves on RedHat 7.2

\start
Date: 06 Nov 2006 09:02:49 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: lastest tests

Greetings, and thanks!  I guess I must have beat you to it.  Just a
quick note -- when we do commit a bug fix to the proto-stable branch,
kindly also make sure it is fixed in cvs head -- it is the converse
which of course does not apply.

Take care,

Gabriel Dos Reis writes:

> Tim Daly writes:
> 
> | I did a checkout of
> | 
> | cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl
> | With the patch to remove the -lintl from h/powerpc-macosx.defs LIBS line
> 
> I'll commit that patch to gcl-2.8.pre, and update axiom.build-improvements.

\start
Date: 06 Nov 2006 09:08:53 -0500
From: Camm Maguire
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

May I suggest trying this entry from amd64-linux.h:

#ifdef IN_SFASL
#include <sys/mman.h>
#define CLEAR_CACHE {\
   void *p,*pe; \
   p=(void *)((unsigned long)memory->cfd.cfd_start & ~(PAGESIZE-1)); \
   pe=(void *)((unsigned long)(memory->cfd.cfd_start+memory->cfd.cfd_size) & ~(PAGESIZE-1)) + PAGESIZE-1; \
   if (mprotect(p,pe-p,PROT_READ|PROT_WRITE|PROT_EXEC)) {\
     fprintf(stderr,"%p %p\n",p,pe);\
     perror("");\
     FEerror("Cannot mprotect", 0);\
   }\
}
#endif


I.e., copy powerpc-macosx.{defs,h} to i386-macosx.{defs,h}, make the
above modification, make sure configure detects the host right, and
then see where we are.

This code flushes the data cache so that the cpu ca properly execute
code that has just ben loaded into the data segment.  I typical
symptom of this not having been done is SIGILL as some random
instruction gets fed to the cpu.  Historically, i386 has not needed
this, but I have noticed a tendency towards requiring this
functionality as computers have been evolving over the past few
years.  mprotect is a generic syscall way to achieve the same end
without cpu specific assembly.  It might work across the board -- I
have not had time to check.

Please keep me posted.

Take care,

Humberto Zuazaga writes:

> Camm Maguire wrote:
> 
> > locbfd should be the default on macosx, as we have Aurelien's specific
> > mods for .o file loading.  Extending this default to the intel should
> > resolve the -lintl 'out of the box'.  This said, I'd be quite
> > (pleasantly) surprised if Aurelien's code works as is on intel.  This
> > should be tried first -- if you can compile and load a simple file,
> > all is well.
> 
> No such luck. Considering that h/powerpc-macosx.h has inline (PowerPC)
> assembly, it's not likely to work (line 91).
> 
> The code is for "Processor cache synchronization code." I'm definitely
> in over my head here. I don't have the foggiest notion how to implement
> the equivalent on Intel Macs.
> 
> 
> >  Otherwise, the brain-dead default entry-level loading
> > option is --disable-statsysbfd --enable-dlopen. 
> 
> Can I simply delete the cache sync code and try this?

\start
Date: 06 Nov 2006 15:33:15 +0100
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: lastest tests

Camm Maguire writes:

| Greetings, and thanks!  I guess I must have beat you to it.  Just a
| quick note -- when we do commit a bug fix to the proto-stable branch,
| kindly also make sure it is fixed in cvs head -- it is the converse
| which of course does not apply.

Hello Camm,

  Yes, you're of course right on both accounts.

After GCL-2.6.8 is out (I hope we are reaching the end of the pressing
issues this wee), could we make GCL head's configure wrok with
Autoconf 2.52 and higher?

\start
Date: Mon, 06 Nov 2006 11:03:42 -0400
From: Humberto Zuazaga
To: Camm Maguire
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Camm Maguire wrote:
> OK, I've commited the removal of -lintl from powerpc-macosx.defs from
> both branches.  This and the --disable-nls which is now in
> configure.in and passed to the binutils subconfigures should remove
> the above.  I.e. ./configure --prefix=...  should work, if anyone has=

> a moment to verify.

I just tested with a new copy from CVS, and gcl compiles without problems=
=2E

I used:

$ ./configure --prefix=/usr/local --disable-statsysbfd --enable-locbfd
--enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-x
--disable-xgcl --disable-tkconfig

I'll try to build an axiom with that later today.

Gaby, how current is the tarball in build-improvements? Have you
included these patches?

\start
Date: 06 Nov 2006 16:12:45 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Humberto Zuazaga writes:

| Camm Maguire wrote:
| > OK, I've commited the removal of -lintl from powerpc-macosx.defs from
| > both branches.  This and the --disable-nls which is now in
| > configure.in and passed to the binutils subconfigures should remove
| > the above.  I.e. ./configure --prefix=...  should work, if anyone has
| > a moment to verify.
| 
| I just tested with a new copy from CVS, and gcl compiles without problems.
| 
| I used:
| 
| $ ./configure --prefix=/usr/local --disable-statsysbfd --enable-locbfd
| --enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-x
| --disable-xgcl --disable-tkconfig
| 
| I'll try to build an axiom with that later today.
| 
| Gaby, how current is the tarball in build-improvements? 

| Have you  included these patches?

Not those against GCL (I just woke up and started reading Axiom list - I
should probably be grading students homework :-).  I synced
build-improvements with silver yesterday.

While composing this message, I fired the upgrade to the most recent
GCL-2.6.8pre.  Do you see any other patches that I may have forgotten
that should go into build-improvements?

\start
Date: 06 Nov 2006 16:26:33 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

Gabriel Dos Reis writes:

[...]

| While composing this message, I fired the upgrade to the most recent
| GCL-2.6.8pre.

As of revision 252, axiom.build-improvements uses the latest version
of GCL-2.6.8pre.

| Do you see any other patches that I may have forgotten
| that should go into build-improvements?

\start
Date: 06 Nov 2006 10:53:25 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: lastest tests

Gabriel Dos Reis writes:

> Camm Maguire writes:
> 
> | Greetings, and thanks!  I guess I must have beat you to it.  Just a
> | quick note -- when we do commit a bug fix to the proto-stable branch,
> | kindly also make sure it is fixed in cvs head -- it is the converse
> | which of course does not apply.
> 
> Hello Camm,
> 
>   Yes, you're of course right on both accounts.
> 
> After GCL-2.6.8 is out (I hope we are reaching the end of the pressing
> issues this wee), could we make GCL head's configure wrok with
> Autoconf 2.52 and higher?
> 

Of course.  In fact, if time and manpower allows, I'd like to rewrite
configure.in and move to Makefile.am sources.  But there is so much
more that is more pressing than this, that the status quo has
prevailed for some time.

\start
Date: 06 Nov 2006 10:55:45 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

If someone has a moment, could someone please explain to me the
relationship between the various axiom branches, and which one is
connected to an 'official release', and if same at such time will
accompany a tarball or not.

Take care,

Gabriel Dos Reis writes:

> Humberto Zuazaga writes:
> 
> | Camm Maguire wrote:
> | > OK, I've commited the removal of -lintl from powerpc-macosx.defs from
> | > both branches.  This and the --disable-nls which is now in
> | > configure.in and passed to the binutils subconfigures should remove
> | > the above.  I.e. ./configure --prefix=...  should work, if anyone has
> | > a moment to verify.
> | 
> | I just tested with a new copy from CVS, and gcl compiles without problems.
> | 
> | I used:
> | 
> | $ ./configure --prefix=/usr/local --disable-statsysbfd --enable-locbfd
> | --enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-x
> | --disable-xgcl --disable-tkconfig
> | 
> | I'll try to build an axiom with that later today.
> | 
> | Gaby, how current is the tarball in build-improvements? 
> 
> | Have you  included these patches?
> 
> Not those against GCL (I just woke up and started reading Axiom list - I
> should probably be grading students homework :-).  I synced
> build-improvements with silver yesterday.
> 
> While composing this message, I fired the upgrade to the most recent
> GCL-2.6.8pre.  Do you see any other patches that I may have forgotten
> that should go into build-improvements?
> 
> -- Gaby

\start
Date: 06 Nov 2006 17:23:04 +0100
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: lastest tests

Camm Maguire writes:

| Greetings!
| 
| Gabriel Dos Reis writes:
| 
| > Camm Maguire writes:
| > 
| > | Greetings, and thanks!  I guess I must have beat you to it.  Just a
| > | quick note -- when we do commit a bug fix to the proto-stable branch,
| > | kindly also make sure it is fixed in cvs head -- it is the converse
| > | which of course does not apply.
| > 
| > Hello Camm,
| > 
| >   Yes, you're of course right on both accounts.
| > 
| > After GCL-2.6.8 is out (I hope we are reaching the end of the pressing
| > issues this wee), could we make GCL head's configure wrok with
| > Autoconf 2.52 and higher?
| > 
| 
| Of course.  In fact, if time and manpower allows, I'd like to rewrite
| configure.in and move to Makefile.am sources. 

Great!

| But there is so much
| more that is more pressing than this, that the status quo has
| prevailed for some time.

Yes. :-(

I hope to have some students interested in GCL, research-wise.

\start
Date: 06 Nov 2006 12:03:39 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: lastest tests

Gabriel Dos Reis writes:

> Camm Maguire writes:
> 
> | Greetings!
> | 
> | Gabriel Dos Reis writes:
> | 
> | > Camm Maguire writes:
> | > 
> | > | Greetings, and thanks!  I guess I must have beat you to it.  Just a
> | > | quick note -- when we do commit a bug fix to the proto-stable branch,
> | > | kindly also make sure it is fixed in cvs head -- it is the converse
> | > | which of course does not apply.
> | > 
> | > Hello Camm,
> | > 
> | >   Yes, you're of course right on both accounts.
> | > 
> | > After GCL-2.6.8 is out (I hope we are reaching the end of the pressing
> | > issues this wee), could we make GCL head's configure wrok with
> | > Autoconf 2.52 and higher?
> | > 
> | 
> | Of course.  In fact, if time and manpower allows, I'd like to rewrite
> | configure.in and move to Makefile.am sources. 
> 
> Great!
> 
> | But there is so much
> | more that is more pressing than this, that the status quo has
> | prevailed for some time.
> 
> Yes. :-(
> 
> I hope to have some students interested in GCL, research-wise.
> 

This of course would be most appreciated, presuming of course it meets
the needs of the students as well.

Take care,

> -- Gaby

\start
Date: Mon, 06 Nov 2006 19:00:35 +0100
From: Gregory Vanuxem
To: Richard Harke
Subject: Re: drawRibbons from the book

Le dimanche 05 novembre 2006 =E0 19:58 -0800, Richard Harke a =E9crit :

[...]

> When I try to execute with
> drawRibbons([x**i for i in 1..5], x=-1..1, y=0..1)
> axiom quietly exits, that is, no error message.

I believe your version of Axiom has a bug which was recently fixed in
silver and build-improvents, see:

http://lists.gnu.org/archive/html/axiom-developer/2006-10/msg00582.html

\start
Date: Mon, 6 Nov 2006 10:56:20 -0800
From: Richard Harke
To: list
Subject: Re: drawRibbons from the book

On Mon November 6 2006 10:00, Vanuxem Gr=E9gory wrote:
> Le dimanche 05 novembre 2006 =E0 19:58 -0800, Richard Harke a =E9crit :
>
> [...]
>
> > When I try to execute with
> > drawRibbons([x**i for i in 1..5], x=-1..1, y=0..1)
> > axiom quietly exits, that is, no error message.
>
> I believe your version of Axiom has a bug which was recently fixed in
> silver and build-improvents, see:
>
> http://lists.gnu.org/archive/html/axiom-developer/2006-10/msg00582.html
Quite right. That was an older version installed from Debian. On another
machine installed from CVS this June, there is no problem.

\start
Date: Mon, 6 Nov 2006 13:52:34 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: The 30 Year Horizon

> Tim, first I must question your monopoly on stating Axiom goals. 

Really? Why? Axiom didn't drop magically from the sky.

I picked up a collection of source files that were being removed from
commercial distribution and thrown out. The collection was not
complete and not functional.

As one of the original authors of the code, prior to its becoming
a commercial product, I was quite upset to see that all of that 
fundamental research in computational math was going to be destroyed.

It took nearly 3 years of my work to put Axiom back together.

I spent a great deal of time in discussion with others and pondering
the past to decide what killed Axiom and what might keep it alive.
I attended a research conference in France and called old developers.
Further, I spent time discussing goals that would make it interesting
30 years from now. Out of these discussions came the project goals.
That's not a monopoly, that's cooperation. I'm open to discussing
goals but not in this "we're right, you're wrong" adversarial
approach. The goals define the project and the development, not the
other way around.

After Axiom started working I set up a new project on Savannah
and Sourceforge. Based on limitations of these services I purchased
my own domain and server (axiom-developer.org). I ran a conference
on Axiom. I recreated our prior book and constructed a second book.
I lectured on Axiom. I attended conferences and recovered old
connections with people I knew and constantly try to form new ones,
such as the sage connection and the numerical mathematics consortium
connection.

I work on Axiom probably 60 hours a week and have done so into
the distant past. I spent about $4000 in the last twelve months
in server support costs, freely distributed books, CDs mailed to
people, purchasing special purpose hardware such as a MAC, attending
conferences, and trips to visit universities to discuss ideas. I've
worked to get old research brought into free code and am still 
working to free vital work such as Manuel's before it gets lost.

I created the project from nothing and brought it to where it is 
today. The project is an open source effort to achieve certain
fundamental goals, one of which is literate programming. I rewrote
virtually every file in Axiom into a document form and rebuilt the
whole build machinery to use that form. There is still much work
to be done and many ideas to explore which tighten the relationship
between the literate tools, the pamphlet files, and the gestalt
which is the future of axiom. Doing things like removing the
prototype version of the document command or splitting off the
"documentation" from the "source"  make it clear that either
you don't understand this or you don't agree with the goal.

Working under the assumption that you don't understand it I've asked
that you step back, stop slicing off "dead" portions of the project,
and try to invent, extend, and enhance the prototypes so they can
achieve the long term goals. Instead of removing duplicate
documentation, as in the asq discussion, you should propose a long
term idea, like arranging pamphlet file machinery which can share
sections, and construct new literate tools to make it work.

If, however, you don't agree with the goals then you're clearly
not working on Axiom but working on your own project under the
guise of working on Axiom. That's a fork. If this is the case
then I ask two things:
  1) Please set up your own savannah project under a different name.
     You're welcome to take any code, as per the license agreement.
  2) As a professional courtesy please stop using the Axiom name.
     I've invested a lifetime of work in defining what it means.






> In open source project all members choose goals.  If members
> goals are fundamentally incompatible, then there is time to fork.
> However, (as I belive is in Axiom case) if goals differ slightly,
> it should be possible to work togehter (compromising on lesser
> goals if needed).

Axiom is a project with stated goals. Those goals are supposed
to set the direction of the project. Axiom's been quite flexible
about methods of reaching those goals. For instance, Bill has 
insisted that the browser be the basis for future user interface
work. He's been very convincing and at this point I agree with him.
The Crystal effort and the new hyperdoc browser are trying to use 
the firefox browser as a base.

However I see the build-improvements branch completely ignoring goals.
When *I* don't understand why decisions are being made and how they
fit the future direction I have to say something fundamental is broken.

I'm watching the build-improvements branch fit Axiom to the tools
rather than the other way around. Axiom's being laid upon a 
procrustean bed, with parts being cut off because they don't "fit"
the tools. 

* I see files being rewritten because noweb can't handle them.
* I see patches to tools being rejected as inappropriate, treating
  the tool as more important that the project.
* I see files being rejected and modified because SVN has a problem.
* I see files being thrown out, like the document command, because
  they don't fit some standard.
* I see the designed structure of Axiom, rather than being implemented
  using autoconf, being restructured to fit the dictates of autoconf and
  the free software foundation.
* I see the idea of literate programming being pulled apart into
  "source" and "documentation" to fit ideas foreign to the project
  in the name of "today's standards".

Axiom is not about the tools. Axiom is about creating new ideas.
Axiom had a browser before browsers existed. Axiom created clef
with features that enhanced Axioms useability. Axiom created
object-oriented programming before the idea existed and still
does things that some other OO systems don't such as distinguishing
on return types. These ideas were ahead of their time.

Axiom needs to be ahead of its time so that it is alive and
interesting in 30 years. We can't do that by following the crowd.
Each issue should raise a question about the best way to do it
regardless of whether current tools support the idea or current
standards support the idea. Instead I see the tool defining the
chosen solution.

This isn't about compromise and this isn't about standards. This is
about inventing the future. I hear people complaining about keeping
a snapshot of GCL and how "wrong" this is to subsume other projects
(even though GCL has several projects subsumed in it). I can't
imagine the outcry when Axiom swallows ACL2 in order to support
a program proof technology, one of the stated goals.

> Secondly, I read many times what you wrote about Axiom goals and
> I find it still not clear -- there are nice dreams (which I share
> with you) and implementation strategy (which I doubt will work).

If you don't understand the goals of the project or they are unclear
perhaps the proper course of action is to discuss what you plan to
implement to see if it conforms to the goals rather than implement
something and claim the project goals need to compromise.

Yes, Axiom has dreams. Dreams of the 30 year horizon. Almost nothing
we see today as "standard" will be interesting or useful in 30 years.
I believed "top-down structured programming" and "decision table"
programs were the only way to program. I now know enough to know
that autoconf standards are a passing fad. They fix problems that
don't need to exist in the first place. Strong literate programming,
however, attacks a fundamental problem, namely that the research is 
now separated from the implementation. That is a fundamental flaw in
computational mathematics. We must dream and invent new ways, both
social and technical, which overcome this fundamental rift. That's
why I am trying so strongly to make my case. Axiom has a fundamental
project goal to eliminate the distinction between "documentation"
and "source". I'm trying to implement "drag-and-drop" research
papers. I'm working with Carlo Traverso, head of the math department
in Pisa to create a peer-reviewed "live", literate journal. I'm on
a program committee of a conference related to the topic.

I'm trying to craft a multi-fuel transportation system for the next 30
years and you're busy optimizing the gas engine for speed by removing
the experimental modifications.

I see that you're doing excellent work and that you're making great
strides in adapting Axiom to today's technology. And you've clearly
energized people by showing such rapid progress in optimizations and
adoption of standards. Your car will be blindingly fast.

But you've missed the goal.

\start
Date: 06 Nov 2006 20:52:14 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: The 30 Year Horizon

Tim Daly writes:

[...]

| I attended a research conference in France and called old developers.

I think I was in the room.  The idea of open source algebra was
enthusiastically embraced.  I distinctly remember you vigorously
defending the idea that people should gather around Axiom, while other
ideas (liek starting a *new* project) were floating around.  How many
did actually follow?  Do you believe it is just a matter of them not
knowing or being "immature"? 

Over the last couple of months I've been talking to colleagues in
France about gathering effort around Axiom.  I can't reproduce the
reactions here.  I don't believe this is just a matter of people not
knowing the value of a project.  There is something deeper to be
analyzed.  No, it is not just because they don't understand
"literate programming".  

[...]

| I'm open to discussing goals but not in this "we're right, you're
| wrong" adversarial approach.

Please could you be more specific about what you mean?

[...]

| However I see the build-improvements branch completely ignoring goals.

then, you don't see the build-improvements clear enough.

| When *I* don't understand why decisions are being made and how they
| fit the future direction I have to say something fundamental is broken.

When you don't understand the decisions, you can ask for clarifications.

[...]

| * I see files being thrown out, like the document command, because
|   they don't fit some standard.

Tim, please check *facts* before you make a fool of yourself in public
accusing people of wrong-doing, when in fact you just prefer to ignore
reality because it does not match your preconceived ideas of how
evil people must be.   As a matter of fact document on
build-improvements is enhanced to handle more complex cases of code
extraction, documentation in DVI generation: Its content is reproduced
below.  Please tell me how it "is being thrown out".  

[...]

|                                                Axiom created
| object-oriented programming before the idea existed and still
| does things that some other OO systems don't such as distinguishing
| on return types. These ideas were ahead of their time.

Tim, Simula invented object-oriented programming, before Axiom even
existed.  Don't make people think that Axiom is about History Revisionism.

  http://heim.ifi.uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_OO_start.html

That doing will only shed profound doubts about his scientific value,
and chase away respectable and potential contributors.  Maybe that is
what you want, I don't know.

-- Gaby

#!/bin/sh

# usage:
#    document --latex file
#    document --weave file.pamphlet
#    document --weave --latex file.pamphlet
#    document --tangle file.pamphlet
#    document --tangle=chunk --output=fileout filein.pamphlet
#   [ plus any legacy usage ]


# set -x

latex=@LATEX@
index=@MAKINDEX@

tangle=@NOTANGLE@
weave=@NOWEAVE@

TEXINPUTS=.:@axiom_builddir@/share/texmf/tex:$TEXINPUTS
export TEXINPUTS
BIBINPUTS=.:@axiom_builddir@/share/texmf/tex:$BIBINPUTS
export BIBINPUTS


do_index=
do_latex=
do_tangle=
do_weave=
chunk=
file=
output=

while : ; do
    case $1 in
	--weave)
	   do_weave=yes
	   shift
	   ;;

        --latex)
	   do_latex=yes
	   shift
           ;;

        --index)
	   do_index=yes
	   # FIXME: --index may be used only with --latex.  Check.
	   shift
           ;;

	--tangle=*)
	   do_tangle=yes
	   chunk=`echo $1 | awk -F'=' '{ print $2; }'`
	   shift
	   ;;

	--tangle)
	   do_tangle=yes
	   # --tangle may not be combined with any other
	   # options.  FIXME:  Check that. 
	   shift
	   ;;

	--output=*)
	   output=`echo $1 | awk -F'=' '{ print $2; }'`
	   shift
	   ;;

	--*)
	   echo unrecognized option $1
	   exit 1
	   ;;

        *) break ;;
    esac
done

if test x$do_tangle = xyes; then
    # FIXME: Check that the input file name does indeed have
    # a pamphlet extension.
    file=$1
    if [ -z $output ]; then
	output=`basename $file .pamphlet`;
    fi

    # FIXME: Ideally, we should just prepend -R to $chunk
    #        if it is non-null, and say $tangle $chunk $file > $output
    #        Alternatively, we could initialize chunk to '*' and
    #        unconditionally use -R"$chunk".
    if [ -z "$chunk" ]; then
	$tangle $file > $output
    else
	$tangle -R"$chunk" $file > $output
    fi
    # FIXME: Handle errors.
    exit $?;
fi


if test x$do_weave = xyes; then
    file=`basename $1 .pamphlet`
    $weave -delay $1 > $file.tex
    if test x$do_latex != xyes; then
	exit 0;
    fi
fi

if test x$do_latex = xyes; then
    if [ -z $file ]; then
	file=`basename $1 .tex`
    fi
    $latex --interaction nonstopmode $file;
    if [ x$do_index = xyes ]; then
	$makeindex $file.idx
    fi
    $latex --interaction nonstopmode $file;
    exit $?
fi


if [ "$#" = "3" ]; then
 REDIRECT=$2
 FILE=`basename $3 .pamphlet`
 $tangle -t8 $FILE.pamphlet >$FILE
 $weave -delay $FILE.pamphlet >$FILE.tex
 $latex --interaction nonstopmode $FILE.tex >$REDIRECT
 $latex --interaction nonstopmode $FILE.tex >$REDIRECT
 rm -f $FILE~
 rm -f $FILE.pamphlet~
 rm -f $FILE.log
 rm -f $FILE.tex
 rm -f $FILE.toc
 rm -f $FILE.aux
 exit 0
fi
if [ "$#" = "1" ]; then
 FILE=`basename $1 .pamphlet`
 $tangle -t8 $FILE.pamphlet >$FILE
 $weave -delay $FILE.pamphlet >$FILE.tex
 $latex $FILE.tex 
 $latex $FILE.tex
 rm -f $FILE~
 rm -f $FILE.pamphlet~
 rm -f $FILE.log
 rm -f $FILE.tex
 rm -f $FILE.toc
 rm -f $FILE.aux
 exit 0
fi
echo "document [ -o redirect ] pamphlet"

# set +x

\start
Date: Mon, 6 Nov 2006 14:42:48 -0600 (CST)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On Mon, 6 Nov 2006, Camm Maguire wrote:

| Greetings!
|
| If someone has a moment, could someone please explain to me the
| relationship between the various axiom branches, and which one is
| connected to an 'official release', and if same at such time will
| accompany a tarball or not.

Hi Camm,

  As you see the project is a bit unfocused at the moment.

However, there are basically three branches:

  * silver -- this is a dayly mirror of the source bas ethat Tim uses.
    It is effectively read-only, even if theoretically you could
    commit there.  How it should evolve is unclear, and a lot of
    debate is going on.

  * build-improvements -- this is a branch that I maintain.  Its goal
    is to bring Axiom to a state where the build machinery is
    simplified for both developers and end-users: Ideallym they should
    just say

       ./configure && make && make install

    I'm using Autoconf (no Automake at the moment).  You can commit to
    that branch if you have write access to the SourceForge repository.
    When completed, it will be proposed for merge to the main source.

    People have been able to build and run Axiom from
    build-improvements on systems that traditional releases of Axiom
    where unable to support.

    I did not originally anticipate making tarballs out of that
    branch, but repeated experience with students and some users
    around here had shown that I need to make a tarball.  I've done
    that but, not officially.  Depending on how all this issue
    developed, how much of interest it generates, and how long it
    takes to complete the branch, I may have to make regular tarballs
    out of that branch.  But, it is not something I planned on.  It is
    up to the community.

  * the third branch is by Antoine.  It "looks" less active at the
    moment. I'm not really qualified to comment.

\start
Date: 06 Nov 2006 21:42:04 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Ping: file removals

Bill Page writes:

[...]

| > Documentation in any form is to be desired and it often cannot be
| > created "from the source".
| 
| True. Documentation is not source code but source code i.e. pamphlet
| files, can be used to create some of the Axiom documentation.

Indeed.  Let me expand on this.
We are talking of pamphlet files.  So, the way I read Waldek's use
of "documentation" is "the produced PDF format (or any other
processed) file that explains the system".  I did not realize it could
be parsed as meaning that the pamphlet should be thrown away.  I could
be wrong and I cannot speak for Waldek, but I certainly did not read
it as meaning that the pamphlet should be thrown away.  If axiom is
suffering from something, it is certainly is from lack or documentation.

It it my belief that the Axiom source code repository should ideally
contain all of the system explanation that is needed to reproduce,
say, a PDF format of all that is needed to know, to understand, to
use, and to extend the system.  If the source code repository in not
in a state where that is achievable, then the source code repository
is incomplete, and must be completed.  Consequently, if the corrected 
bookvol1 cannot be reproduced with current sources, then someone is hiding
something.  If the source code is complete, then there is no need to
maintain the PDF format in the source core repository.  That does not
necesarily mean information is thrown away.

\start
Date: 06 Nov 2006 16:11:38 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Greetings, and thanks so much!

What about 'golden'?  Would it be appropriate to make 'official' axiom
release tarballs from this branch when updated from silver?  Or is the
notion of 'release' slower than the progress of 'golden'?

Take care,

Gabriel Dos Reis writes:

> On Mon, 6 Nov 2006, Camm Maguire wrote:
> 
> | Greetings!
> |
> | If someone has a moment, could someone please explain to me the
> | relationship between the various axiom branches, and which one is
> | connected to an 'official release', and if same at such time will
> | accompany a tarball or not.
> 
> Hi Camm,
> 
>   As you see the project is a bit unfocused at the moment.
> 
> However, there are basically three branches:
> 
>   * silver -- this is a dayly mirror of the source bas ethat Tim uses.
>     It is effectively read-only, even if theoretically you could
>     commit there.  How it should evolve is unclear, and a lot of
>     debate is going on.
> 
>   * build-improvements -- this is a branch that I maintain.  Its goal
>     is to bring Axiom to a state where the build machinery is
>     simplified for both developers and end-users: Ideallym they should
>     just say
> 
>        ./configure && make && make install
> 
>     I'm using Autoconf (no Automake at the moment).  You can commit to
>     that branch if you have write access to the SourceForge repository.
>     When completed, it will be proposed for merge to the main source.
> 
>     People have been able to build and run Axiom from
>     build-improvements on systems that traditional releases of Axiom
>     where unable to support.
> 
>     I did not originally anticipate making tarballs out of that
>     branch, but repeated experience with students and some users
>     around here had shown that I need to make a tarball.  I've done
>     that but, not officially.  Depending on how all this issue
>     developed, how much of interest it generates, and how long it
>     takes to complete the branch, I may have to make regular tarballs
>     out of that branch.  But, it is not something I planned on.  It is
>     up to the community.
> 
>   * the third branch is by Antoine.  It "looks" less active at the
>     moment. I'm not really qualified to comment.

\start
Date: Mon, 6 Nov 2006 16:06:00 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: The 30 Year Horizon

Ok. Clearly I'm not getting my point across.
And we're not communicating.
So I'm going to try something else.

As of this moment Axiom is a complete democracy.

Gaby, I believe you have write access to both Gold and Silver.
You also have complete access on sourceforge. If you want
contact myself or Bill Page and we'll set you up as admin
on savannah.

Anyone else who desires read/write access can contact myself or 
Bill Page who has admin access everywhere. Anyone who wants
admin access on savannah or sourceforge please contact myself
or Bill Page.

I will no longer be the "point of failure" in the project.
You are all now responsible for either checking in your own
changes or electing someone to do it for you.

Releases will be done in any way you can all agree upon.

Choose your own goals, create your own future.

I'm stepping away from the lead developer role and will now
act as just another developer.

\start
Date: Tue, 07 Nov 2006 00:02:17 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Aldor compilation for Axiom

Hello Bill,

Thanks a lot for your answer.

On 11/06/2006 03:37 AM, Bill Page wrote:
> On November 5, 2006 7:31 PM Ralf Hemmecke wrote:
>> could someone tell me what ")compile blah.as" is actually 
>> doing in Axiom?
>>
>> It is certainly more than saying
>>
>> aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y 
>> $AXIOM/algebra blah.as
>>
>> (without having an Axiom session running).
>>
>> I think someone once said that )compile calls aldor with the 
>> above flags and then also generates object files from the .lsp
>> files.
> 
> Yes.
> 
>> How could I achieve that from outside Axiom?
> 
> Do you mean generate stand alone object files from .lsp files? This
> would be done with a Lisp compiler, of course. In principle you can
> use GCL just like Axiom does, but you must also provide a Lisp
> run-time. The Aldor distribution has such a lisp run-time that is
> supposed to be equivalent to the Aldor C run-time environment, but
> my initial attempts to use it with GCL ran into trouble - maybe
> some GCL incompatibility with the lisp run-time source?

No no. I just want to compile files for later use within Axiom, but I 
don't want to start an interactive axiom session, obviously.

> If you want to generate object files that can later be loaded into
> Axiom, I am not sure that it is possible to do this outside of Axiom
> because I suspect there symbols that are known only to Axiom. If you
> discover a way, I would be quite interested. Remember that because
> it is written in Lisp AXIOM really just GCL + a lot of extra Lisp code.
> So internally in AXIOM, compiling Lisp to object code is done by the
> same underlying GCL mechanisms.
> 
>> Or is it enough to provide the .lsp files and the compilation to
>> object files is triggered when the code is first used?
>>
> 
> No. You must compile the .lsp files inside Axiom.
> 
> Ralf, do you know section 18.12 : Using Aldor outside AXIOM for AXIOM
> of the Aldor User's Guide?
> 
> http://www.aldor.org/docs/HTML/chap18.html#12
> 
> "When you are ready to test and use your code within AXIOM, start
> up AXIOM and then )cd to the directory containing your compiled code.
> Invoke )compile on each .lsp file you wish to use."
> 
> See also section 18.11.

Good point. I should really even more often read the AUG. But I usually 
read the .pdf version and there the part about AXIOM is missing. I hope 
the html doc does not get removed suddenly. Hopefully it is mirrored 
somewhere.

>> Further, I actually have a whole library (several .as files). 
>> What would be the right procedure to compile them externally
>> (I want to do that via Makefiles) and then provide some nice
>> mechanism to load the compiled library into Axiom.

> Why compile "externally"? Why not just use Axiom in your Makefile,
> the way it is currently done in the Axiom build. E.g.
> 
> myfile.NRLIB/code.o: myfile.as
> 	echo ')compile myfile.as' | AXIOMsys

Very good suggestion. It seems that I will take that approach. I have to 
test whether I still like it if some error occurs, though.

Hmmm, maybe I rather generate first a .al library and the .lsp files and 
only then use your approach to compile the .lsp files via AXIOMsys as 
you suggested.

>> I just need a rough overview.

> I hope these comments are some some use.

Yes, definitely. Thanks a lot.

\start
Date: 07 Nov 2006 00:06:35 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: The 30 Year Horizon

Tim Daly writes:

| Ok. Clearly I'm not getting my point across.
| And we're not communicating.
| So I'm going to try something else.

[...]

| I'm stepping away from the lead developer role and will now
| act as just another developer.

If you think people want you to step away, then clearly we're not
communicating. 

\start
Date: Mon, 6 Nov 2006 17:23:19 -0600 (CST)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On Mon, 6 Nov 2006, Camm Maguire wrote:

| Greetings, and thanks so much!
|
| What about 'golden'?  Would it be appropriate to make 'official' axiom
| release tarballs from this branch when updated from silver?  Or is the
| notion of 'release' slower than the progress of 'golden'?


Ralf asked me to explain how, ideally, I envision the development
model, I've tried to explain it here:

  http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00179.html

That is not current situation; my hope is that if Tim agrees on that,
then it looks to me as if we would  make 'official' axiom release
tarballs from the "gold  branch (which is not anywhere under SVN at
the moment).

\start
Date: Mon, 06 Nov 2006 21:14:31 -0400
From: Humberto Zuazaga
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

Gabriel Dos Reis wrote:

> While composing this message, I fired the upgrade to the most recent
> GCL-2.6.8pre.  Do you see any other patches that I may have forgotten
> that should go into build-improvements?

I still can't pull the svn source on the Mac, so I pulled on a linux box
and copied them over to the Mac this morning.

I have built axiom again. I needed to patch 2 files:

1) src/hyper/hthits.pamphlet, using Waldek's patch:

http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00195.htm=
l

and

2) $ svn diff src/graph/viewman/viewman.c.pamphlet
Index: src/graph/viewman/viewman.c.pamphlet
==========================
==========================
=================
--- src/graph/viewman/viewman.c.pamphlet        (revision 252)
+++ src/graph/viewman/viewman.c.pamphlet        (working copy)
@@ -116,7 +116,7 @@
   int keepLooking,code;

   bsdSignal(SIGPIPE,brokenPipe,DontRestartSystemCalls);
-#if defined(BSDplatform)
+#if defined(BSDplatform) || defined (MACOSXplatform)
   bsdSignal(SIGCHLD,endChild,RestartSystemCalls);
 #else
   bsdSignal(SIGCLD,endChild,RestartSystemCalls);

I built --without-noweb --with-gcl, the configure for the built in gcl
isn't working right. I think it's a bug in gcl-2.6.8pre (if you call
configure with no --prefix, the make tries to echo data into /bin/gcl
and fails with permission problems).

I'll try to send Camm a patch (or at least a real bug report).

\start
Date: Mon, 6 Nov 2006 22:38:50 -0500
From: Bill Page
To: Tim Daly
Subject: RE: The 30 Year Horizon

Tim,

On November 6, 2006 4:06 PM you wrote:
> 
> Ok. Clearly I'm not getting my point across.
> And we're not communicating.

I think you should try harder to communicate. Communication
involves both listening and speaking. You especially need to
read email messages more carefully. Actually it seems to me
that you got your point across a long time ago and that people
are in fact acting on the goals that you set, even if they are
not doing it in exactly the way you envisaged.

> So I'm going to try something else.
>

I know I'm not going to like it already ... ;)

 
> As of this moment Axiom is a complete democracy.
> 

I don't think organizing a project as a democracy is good idea
nor is it possible to create a democracy by fiat. People naturally
follow those people who lead, not necessarily those who are the
most vocal. As you have so often said when suggestions are being
made: "advocacy is volunteering" in other words "show me the code".
I strongly suspect that is how the Axiom project will continue to
evolve.

It seems to me that most open source project work by consensus
and compromise. When this fails, they either fork or die. I still
believe that consensus is possible here - after all we are not
such a big group of developers!

> ... 
> I will no longer be the "point of failure" in the project.
> You are all now responsible for either checking in your own
> changes or electing someone to do it for you.
>

I prefer the option of checking in our own changes following some
discussion on the axiom-devel email list.
 
> Releases will be done in any way you can all agree upon.
> 

I think we should adopt the standard open source policy of release
early and release often. This is not a commercial software project
with milestones and cut-off dates. It is an ongoing, evolving
collaboration between interesting parties to achieve a set of
common goals.

> Choose your own goals, create your own future.
>

We all do this every day.
 
> I'm stepping away from the lead developer role and will now
> act as just another developer.
> 

I regret your decision, but I respect it. :-) I don't think that
it really should need to be said, but since I am in the mood and
it surely can't hurt let me just say: Thank you for all your
previous hard work and for your continued commitment to Axiom.
I have no doubt that it will continue to be a benefit to many
people over the next 30 years...

\start
Date: Mon, 6 Nov 2006 23:17:25 -0500
From: Bill Page
To: Tim Daly
Subject: RE: The 30 Year Horizon

Tim,

I worry that some of your statements below might be interpreted badly
by some other people important to Axiom.

On November 6, 2006 1:53 PM you wrote:
> ... 
> I picked up a collection of source files that were being removed
> from commercial distribution and thrown out. The collection was
> not complete and not functional.

I am not sure how you define "complete" but NAG did claim that
they had delivered to you a completely functional Axiom system
which ran on Linux. True, it was based on a different lisp system
(ccl) then the one you were most familiar with and some parts
that involved other commercial licenses had been removed, but
the decision to re-implement Axiom under gcl was yours. This
involved some significant extra work since both Axiom and gcl had
evolved some since this combination was last fully operational.

> 
> As one of the original authors of the code, prior to its becoming
> a commercial product, I was quite upset to see that all of that 
> fundamental research in computational math was going to be
> destroyed.

I don't think you were the only one. I recall several emails from
Mike Dewar of NAG to various email lists asking for people willing
to take on Axiom as an open source project. It's just a good thing
that you came along when you did. :-) Or do you think my summary
of this part of Axiom's history is not accurate? (It could be,
I wasn't there.)

> 
> It took nearly 3 years of my work to put Axiom back together.
>

Getting Axiom working under GCL also involved some very critical
input from both Camm Maguire and Jergen Weiss. In fact the email
archive shows that Jergen Weiss was the first one to report an
operational system and he contributed the updated Axiom database
that was essential to solve the remaining problems. (I remember,
I was there by then. :).

Anyway, this is not intended to reduce the importance of your
contribution by rather just to ensure that other people who
contributed in the "early days" are also properly recognized.

> ... 
> Axiom is a project with stated goals. Those goals are supposed
> to set the direction of the project. Axiom's been quite flexible
> about methods of reaching those goals.

You mean "you" are trying to be flexible. To that I can only say,
well, um ...

> For instance, Bill has insisted that the browser be the basis for
> future user interface work. He's been very convincing and at this
> point I agree with him. The Crystal effort and the new hyperdoc
> browser are trying to use the firefox browser as a base.

Ok that's a point, but I felt at the time that it was a pretty
"hard sell". :-)

> 
> However I see the build-improvements branch completely ignoring
> goals. When *I* don't understand why decisions are being made and
> how they fit the future direction I have to say something fundamental 
> is broken.

I agree, but I don't think it is with the approach being taken by
the build-improvements branch.

> 
> I'm watching the build-improvements branch fit Axiom to the tools
> rather than the other way around. Axiom's being laid upon a 
> procrustean bed, with parts being cut off because they don't "fit"
> the tools. 

That is not true.

> 
> * I see files being rewritten because noweb can't handle them.

I see files being written in a standard literate programming language.

> * I see patches to tools being rejected as inappropriate, treating
>   the tool as more important that the project.

I see cooperation with other open source projects and relying on those
resources instead of alienating them.

> * I see files being rejected and modified because SVN has a problem.

I did see that at all. The only files being modified were because of
limitations in the target operating systems such as MAC OSX and
Windows.

> * I see files being thrown out, like the document command, because
>   they don't fit some standard.

That is not true.

> * I see the designed structure of Axiom, rather than being implemented
    using autoconf, being restructured to fit the dictates of autoconf
    and the free software foundation.

If by "designed structure" you mean the old make scripts, then I think
that is good thing. There are good ways to use the available tools and
there are bad ways. As I have said previously, in my opinion your
original make scripts were "just crazy". 

> * I see the idea of literate programming being pulled apart into
>   "source" and "documentation" to fit ideas foreign to the project
>   in the name of "today's standards".
>

I don't see any of that happening.
 
> ... 
> This isn't about compromise and this isn't about standards. This
> is about inventing the future.

That is out of scope of the Axiom project. The future will invent
itself.

> I hear people complaining about keeping a snapshot of GCL and
> how "wrong" this is to subsume other projects (even though GCL
> has several projects subsumed in it).

It is wrong to subsume other projects. That policy kills possible
collaboration and taxes limited resources. Concerning GCL: Camm has
said that he would like to correct this situation when possible.

> I can't imagine the outcry when Axiom swallows ACL2 in order to
> support a program proof technology, one of the stated goals.
> 

There is no way that Axiom is going to "swallow" ACL2. Get
serious!

> ...
> [Concerning Waldek's recent contributions you wrote:] 
> I see that you're doing excellent work and that you're making great
> strides in adapting Axiom to today's technology. And you've clearly
> energized people by showing such rapid progress in optimizations
> and adoption of standards. Your car will be blindingly fast.
> 
> But you've missed the goal.
> 

If we don't "energize people by showing rapid progress" and
thereby attract new developers and new contributions, there is
no way to achieve any of the goals that you have set for Axiom.

\start
Date: Tue, 7 Nov 2006 14:01:51 +0100 (CET)
From: Waldek Hebisch
To: Francois Maltey
Subject: Re: axiom for trigonometric functions again...

Francois Maltey wrote:
> In fact I try today to get a nice result for this exercice I'll give to my
> students : 
> 
>    sum ((cos x)^k * cos (k*x), k=0..n) 
> 
> Is it possible to load at the boot-time the packages or the 
> functions that we prefer ?
> 
> So I won't need to type expand$MyExpand (cos (3*x/2)) but only expand
> (cos (3*x/2)) in the interpreter, even if my expand function in
> MyExpand.spad package will use sometimes the expand function of the
> manip.spad file.
> 

AFAICS you want to make your function visible and hide the system one
-- you can do this using )set expose system command.
At startup Axiom reads you initialization file, so probably you can
do this from initialization file (but I did not try).

BTW. Did you look at rischNormalize function in
ElementaryFunctionStructurePackage?  In principle rischNormalize
should be able to do all possible trigonometric (and logarithmic)
simplifications.

\start
Date: Tue, 7 Nov 2006 14:18:59 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Ping: file removals

Gabriel Dos Reis wrote:
> Bill Page writes:
> 
> [...]
> 
> | > Documentation in any form is to be desired and it often cannot be
> | > created "from the source".
> | 
> | True. Documentation is not source code but source code i.e. pamphlet
> | files, can be used to create some of the Axiom documentation.
> 
> Indeed.  Let me expand on this.
> We are talking of pamphlet files.  So, the way I read Waldek's use
> of "documentation" is "the produced PDF format (or any other
> processed) file that explains the system".  I did not realize it could
> be parsed as meaning that the pamphlet should be thrown away.  I could
> be wrong and I cannot speak for Waldek, but I certainly did not read
> it as meaning that the pamphlet should be thrown away.  If axiom is
> suffering from something, it is certainly is from lack or documentation.
> 
> It it my belief that the Axiom source code repository should ideally
> contain all of the system explanation that is needed to reproduce,
> say, a PDF format of all that is needed to know, to understand, to
> use, and to extend the system.  If the source code repository in not
> in a state where that is achievable, then the source code repository
> is incomplete, and must be completed.  Consequently, if the corrected 
> bookvol1 cannot be reproduced with current sources, then someone is hiding
> something.  If the source code is complete, then there is no need to
> maintain the PDF format in the source core repository.  That does not
> necesarily mean information is thrown away.
> 

\start
Date: 07 Nov 2006 15:31:26 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Axiom unsoundness

Bill Page writes:

| On Friday, October 27, 2006 1:01 PM Gabriel Dos Reis wrote:
| > 
| > Waldek Hebisch writes:
| > ... 
| > | 
| > |    >> System error:
| > |    Caught fatal error [memory may be damaged]
| > 
| > I've been running into this "memory may be damaged" stuff very
| > often these days ]with students, everything is possible :-)].
| > Most of them happens on invalid syntax and such.  The system
| > should be more resilient should not corrupt memory just because
| > of syntax errors and such.
| > 
| 
| Actually I believe that in *most* cases this error message
| greatly over states the case and is probably rather poorly
| choosen from a user psychology point of view. (Many of Axiom
| error message suffer from this.) In spite of this message,
| have not seen  any clear evidence of corrupt memory. Really
| this is a Lisp issue and my experience with GCL is that in
| spite of some surprising things that it does to manage
| memory, it does in fact do quite a good job.
| 
| I'd be interested if you have any evidence actual memory
| problems.

Here is a case where the system did not issue a diagnostic, but just
terminates with exit status 0 (!) [so it is not a case of message with
evidence of actual memory damage.  It is a case of non-message with
actuall memory damage.].  Type in

     VALUES(Integer)$Lisp

Even when we think the operation is meaningless, the system should try
hard not to crash.  In fact, the system can predict that the operation
is nonsensical and issue appropriate message.

\start
Date: 07 Nov 2006 09:49:01 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Greetings!  Thanks!  I'll give it a read.

Take care,

Gabriel Dos Reis writes:

> On Mon, 6 Nov 2006, Camm Maguire wrote:
> 
> | Greetings, and thanks so much!
> |
> | What about 'golden'?  Would it be appropriate to make 'official' axiom
> | release tarballs from this branch when updated from silver?  Or is the
> | notion of 'release' slower than the progress of 'golden'?
> 
> 
> Ralf asked me to explain how, ideally, I envision the development
> model, I've tried to explain it here:
> 
>   http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00179.html
> 
> That is not current situation; my hope is that if Tim agrees on that,
> then it looks to me as if we would  make 'official' axiom release
> tarballs from the "gold  branch (which is not anywhere under SVN at
> the moment).

\start
Date: Tue, 7 Nov 2006 11:01:18 -0500
From: Bill Page
To: list
Subject: FW: Pyrex and SAGE

Axiom Developers,

Although the attached email is from another list and is specifically
about Sage and Python, I decided to forward it here to the Axiom
Developer list because I think it is an excellent example of the
*right way* for open source projects to collaborate and co-operate.
I hope that we can achive this in the Axiom project.

Greg Ewing is the developer of an open source tool that compiles a
subset of Python to C++ for reasons of efficiency. Pyex for Sage
plays a similar role as Aldor for Axiom.

Regards,
Bill Page.

-----Original Message-----
Sent: November 7, 2006 5:00 AM
To: Greg Ewing
Subject: [sage-devel] Pyrex and SAGE

Hi Greg,

Pyrex is *awesome*.  It's existence is one of the main reasons that
I choose Python as the main interpreter language for SAGE
(http://modular.math.washington.edu/sage/).

I have lofty goals for SAGE, and Pyrex plays a key roll
in them.  E.g., we have used Pyrex a *huge* amount already
in SAGE:

sha:~/d/sage/sage was$ cat */*.pyx */*/*.pyx */*.pxd */*/*.pxd |wc -l
    51162

Also, I've written code to inline Pyrex in Python scripts (like
scipy's weave, but for Pyrex), and make it easy to use Pyrex 
from an interactive GUI (put %pyrex at the beginning of a block
in the SAGE notebook).

However, there are numerous specific goals for SAGE that absolutely
require me to modify Pyrex.  For example, it's crucial for SAGE
that it be easy to view the source code of functions from the
interactive prompt, like IPython does with Python code (via
Python's inspect module).  I very recently added support to the
SAGE version of Pyrex so it can embed file and line number
information in docstrings, so now source code of Pyrex functions
is easily viewable from Ipython (this isn't released yet).  Also,
Martin Albrecht and I made numerous changes to properly support
cimporting of modules defined in other directories (this works
very nicely now).

All these changes (and others) were easier than I thought they
would be, because you did an excellent job writing Pyrex in the
first place.   A potential problem is that the SAGE project is
creating a variant of Pyrex that is significantly different from
yours.  In particular, our version could (in theory -- hopefully
not in practice!) contain new bugs, misfeatures, and other things
you would not be proud to be attributed to you.   So what would
*you* prefer I do?:

    (1) Continue to distribute the SAGE-modified Pyrex as "pyrex",
        and make it very clear that the SAGE version has numerous
        modifications from your version, and that questions should
        be directed to the sage-forum instead of the pyrex forum.

    (2) Distribute the SAGE-modified version, but give it a different
        name, e.g., "SageX", so nobody will confuse it with Pyrex.
        If we do this, it will be made *extremely* clear in README's,
        documentation, etc., that "SageX" is a based very heavily on
        Pyrex by you. Hopefully this could be viewed not as a fork,
        but as an adaptation of Pyrex for use in the SAGE project.

    (3) Make a concerted effort to convince you to include in the
        next official release of Pyrex many of the modifications
        that we've made for SAGE.

In all cases, SAGE is a very strongly open source project, and all
of the SAGE modifications to Pyrex will always be made freely
available. So whatever you prefer it won't stop people interested
in using Pyrex from potentially benefiting from any SAGE work on
Pyrex.

\start
Date: Tue, 7 Nov 2006 20:22:10 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Ping: file removals

Gabriel Dos Reis wrote:
> | files created during build process, but version from repo is referenced
> | form Makefiles ('src/algebra/libdb.text' is unused in build-improvements):
> |  src/algebra/libdb.text
> |  src/hyper/pages/ht.db
> |  src/share/algebra/gloss.text
> 
> those "clearly" are bugs.  We should reference those created during
> the build process.  And those from repo should go away.
>

After re-checking I have found out that both 'src/algebra/libdb.text'
and 'src/hyper/pages/ht.db' are not referenced from build improvements
Makefiles.  ATM I withdraw proposal to remove 'src/share/algebra/gloss.text',
pending extra investigation.
 
> | duplicate, referenced from Makefile (removal needs Makefile changes):
> |  src/share/doc/hypertex/pages/util.ht
> 
> Unless I'm misremebring, someone suggested that there might a slight
> difference in content with its duplicate.  If that is correct, it
> would be good to merge the content (with expalanation as usual) and
> remove it.
> 

Actually, ATM both copies of 'util.ht' are in sync.  The following
patch removes reomves all references to 'src/share/doc/hypertex/pages/util.ht'
from the makefiles, allowing removal of 'src/share/doc/hypertex':

diff -ru build-improvements.bb/src/share/Makefile.pamphlet build-improvements/src/share/Makefile.pamphlet
--- build-improvements.bb/src/share/Makefile.pamphlet	2006-11-05 13:54:52.000000000 +0100
+++ build-improvements/src/share/Makefile.pamphlet	2006-11-05 14:22:29.000000000 +0100
@@ -10,18 +10,6 @@
 \eject
 \tableofcontents
 \eject
-\section{util.ht}
-This file is the magic 'first page' that gets displayed when
-Hyperdoc starts. There is a macro (see [[./doc/hypertex/pages/util.ht]])
-called /localinfo which is intended to allow the luser to add
-her own pages without modifying the system copies. 
-<<util.ht>>=
-${HYPER}/util.ht: ${IN}/doc/hypertex/pages/util.ht
-	@ echo 1 making $@ from $<
-	$(mkinstalldirs) $(HYPER)
-	@ $(INSTALL_DATA) ${IN}/doc/hypertex/pages/util.ht ${HYPER}
-
-@
 \section{command.list}
 The [[command.list]] file contains command completion strings used by
 the [[clef]] command line editor function. In the NAG version this 
@@ -36,11 +24,10 @@
 
 <<*>>=
 IN=$(axiom_src_srcdir)/share
-HYPER=$(axiom_target_datadir)/hypertex/pages
 
 subdir = src/share/
 
-FILES=${HYPER}/util.ht $(axiom_target_libdir)/command.list
+FILES=$(axiom_target_libdir)/command.list
 
 all: all-ax
 
@@ -53,7 +40,6 @@
 clean-local: mostlyclean-local
 distclean-local: clean-local
 
-<<util.ht>>
 <<command.list>>
 @
 \eject

\start
Date: Tue, 7 Nov 2006 21:32:34 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: build-improvements and latex

I tried again 'make dvi' in build-improvements. There are still three
problems:
1) typo in 'src/etc/Makefile.pamphlet'
2) confusion because Latex prefers 'axiom.sty.tex' in current directory
   to 'axiom.sty' in search path
3) axiom.bib.tex file contains 10 file names with unescaped underscores
   inside.

I have a patch solving problems 1 and 2 (included below). BTW the patch
to solve 1 is trival.  I think that we shall agree that trivial patches
may be commited without review (but still posted to the mailing list).
Of course we need also agree what trivial means -- the solution to 2
(since it involves file renaming) is probably slightly beyond trival...

BTW.  I am a bit annoyed because of discrimination of underscores (I like
them very much), so I am tempted to solve 3 by making underscore into
an active character, which expands to ordinary underscore outside math
mode and to subscript char in math mode.


Beside applying the diff one has to also rename 'src/doc/axiom.sty.pamphlet'
to 'src/doc/axiom-sty.pamphlet'

diff -ru build-improvements.bb/config/setup-dep.mk build-improvements/config/setup-dep.mk
--- build-improvements.bb/config/setup-dep.mk	2006-11-07 02:34:28.000000000 +0100
+++ build-improvements/config/setup-dep.mk	2006-11-07 17:51:37.000000000 +0100
@@ -101,7 +101,7 @@
 	$(axiom_build_document) --weave --output=$@ $<
 
 
-$(axiom_build_texdir)/axiom.sty: $(axiom_src_docdir)/axiom.sty.pamphlet
+$(axiom_build_texdir)/axiom.sty: $(axiom_src_docdir)/axiom-sty.pamphlet
 	$(mkinstalldirs) $(axiom_build_texdir)/
 	$(axiom_build_document) --tangle=axiom.sty --output=$@ $<
 
diff -ru build-improvements.bb/src/doc/Makefile.pamphlet build-improvements/src/doc/Makefile.pamphlet
--- build-improvements.bb/src/doc/Makefile.pamphlet	2006-11-07 02:34:25.000000000 +0100
+++ build-improvements/src/doc/Makefile.pamphlet	2006-11-07 17:54:25.000000000 +0100
@@ -31,7 +31,7 @@
 originally written by Norman Ramsey. To this we've added macros to
 support the CATS (Computer Algebra Test Suite).
 <<axiom.sty>>=
-${STY}/axiom.sty: $(srcdir)/axiom.sty.pamphlet ${STY}
+${STY}/axiom.sty: $(srcdir)/axiom-sty.pamphlet ${STY}
 	$(axiom_build_document) --tangle=axiom.sty --output=$@ $<
 
 ${STY}:
@@ -144,7 +144,7 @@
 
 subdir = src/doc/
 
-pamphlets = axiom.sty.pamphlet \
+pamphlets = axiom-sty.pamphlet \
 	axiom.bib.pamphlet \
 	DeveloperNotes.pamphlet \
 	Rosetta.pamphlet \
Only in build-improvements/src/doc: axiom-sty.pamphlet
Only in build-improvements.bb/src/doc: axiom.sty.pamphlet
diff -ru build-improvements.bb/src/etc/Makefile.pamphlet build-improvements/src/etc/Makefile.pamphlet
--- build-improvements.bb/src/etc/Makefile.pamphlet	2006-11-07 02:34:26.000000000 +0100
+++ build-improvements/src/etc/Makefile.pamphlet	2006-11-07 17:45:45.000000000 +0100
@@ -3,7 +3,7 @@
 \usepackage{axiom}
 \begin{document}
 \title{\$SPAD/src/etc Makefile}
-\author{Timothy Daly \andd Gabriel Dos~Reis}
+\author{Timothy Daly \and Gabriel Dos~Reis}
 \maketitle
 \begin{abstract}
 \end{abstract}

\start
Date: Tue, 07 Nov 2006 21:59:49 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: Re: build-improvements and latex

I oppose against special treatment of .sty files.

The general rule should be

notangle file.ext.pamphlet > file.ext
noweave  file.ext.pamphlet > file.ext.pamphlet.tex

remove ".pamphlet" and add ".tex". That rule seems to be a bit simpler 
than having to explain why .sty files must be treated separately.

On 11/07/2006 09:32 PM, Waldek Hebisch wrote:
> I tried again 'make dvi' in build-improvements. There are still three
> problems:
> 1) typo in 'src/etc/Makefile.pamphlet'
> 2) confusion because Latex prefers 'axiom.sty.tex' in current directory
>    to 'axiom.sty' in search path
> 3) axiom.bib.tex file contains 10 file names with unescaped underscores
>    inside.
> 
> I have a patch solving problems 1 and 2 (included below). BTW the patch
> to solve 1 is trival.  I think that we shall agree that trivial patches
> may be commited without review (but still posted to the mailing list).
> Of course we need also agree what trivial means -- the solution to 2
> (since it involves file renaming) is probably slightly beyond trival...
> 
> BTW.  I am a bit annoyed because of discrimination of underscores (I like
> them very much), so I am tempted to solve 3 by making underscore into
> an active character, which expands to ordinary underscore outside math
> mode and to subscript char in math mode.
> 
> 
> Beside applying the diff one has to also rename 'src/doc/axiom.sty.pamphlet'
> to 'src/doc/axiom-sty.pamphlet'
> 
> diff -ru build-improvements.bb/config/setup-dep.mk build-improvements/config/setup-dep.mk
> --- build-improvements.bb/config/setup-dep.mk	2006-11-07 02:34:28.000000000 +0100
> +++ build-improvements/config/setup-dep.mk	2006-11-07 17:51:37.000000000 +0100
> @@ -101,7 +101,7 @@
>  	$(axiom_build_document) --weave --output=$@ $<
>  
>  
> -$(axiom_build_texdir)/axiom.sty: $(axiom_src_docdir)/axiom.sty.pamphlet
> +$(axiom_build_texdir)/axiom.sty: $(axiom_src_docdir)/axiom-sty.pamphlet
>  	$(mkinstalldirs) $(axiom_build_texdir)/
>  	$(axiom_build_document) --tangle=axiom.sty --output=$@ $<
>  
> diff -ru build-improvements.bb/src/doc/Makefile.pamphlet build-improvements/src/doc/Makefile.pamphlet
> --- build-improvements.bb/src/doc/Makefile.pamphlet	2006-11-07 02:34:25.000000000 +0100
> +++ build-improvements/src/doc/Makefile.pamphlet	2006-11-07 17:54:25.000000000 +0100
> @@ -31,7 +31,7 @@
>  originally written by Norman Ramsey. To this we've added macros to
>  support the CATS (Computer Algebra Test Suite).
>  <<axiom.sty>>=
> -${STY}/axiom.sty: $(srcdir)/axiom.sty.pamphlet ${STY}
> +${STY}/axiom.sty: $(srcdir)/axiom-sty.pamphlet ${STY}
>  	$(axiom_build_document) --tangle=axiom.sty --output=$@ $<
>  
>  ${STY}:
> @@ -144,7 +144,7 @@
>  
>  subdir = src/doc/
>  
> -pamphlets = axiom.sty.pamphlet \
> +pamphlets = axiom-sty.pamphlet \
>  	axiom.bib.pamphlet \
>  	DeveloperNotes.pamphlet \
>  	Rosetta.pamphlet \
> Only in build-improvements/src/doc: axiom-sty.pamphlet
> Only in build-improvements.bb/src/doc: axiom.sty.pamphlet
> diff -ru build-improvements.bb/src/etc/Makefile.pamphlet build-improvements/src/etc/Makefile.pamphlet
> --- build-improvements.bb/src/etc/Makefile.pamphlet	2006-11-07 02:34:26.000000000 +0100
> +++ build-improvements/src/etc/Makefile.pamphlet	2006-11-07 17:45:45.000000000 +0100
> @@ -3,7 +3,7 @@
>  \usepackage{axiom}
>  \begin{document}
>  \title{\$SPAD/src/etc Makefile}
> -\author{Timothy Daly \andd Gabriel Dos~Reis}
> +\author{Timothy Daly \and Gabriel Dos~Reis}
>  \maketitle
>  \begin{abstract}
>  \end{abstract}
> 
> 
> 



\start
Date: Tue, 7 Nov 2006 22:23:39 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Bill Page wrote:
> On November 3, 2006 2:16 PM Waldek Hebisch wrote:
> > 
> > Gabriel Dos Reis wrote:
> > > Waldek Hebisch writes:
> > >
> > > | Not yet.  In a message that I sent few minutes ago I proposed to
> > > | rename 'poly.ht' to 'polys.ht' and 'poly.pht' to 'polys.pht'.
> > > 
> > > Please go ahead and commit to build-improvements.  Add an 
> > > explanation (in the pamphlets) about the renaming.
> > 
> > Commited.  But after extra checking I see more problem.  Namely
> > in 'src/hyper/bitmaps' we have the following pairs:
> > 
> > xi.bitmap Xi.bitmap
> > upsilon.bitmap Upsilon.bitmap
> > theta.bitmap Theta.bitmap
> > sigma.bitmap Sigma.bitmap
> > psi.bitmap Psi.bitmap
> > pi.bitmap Pi.bitmap
> > phi.bitmap Phi.bitmap
> > omega.bitmap Omega.bitmap
> > lambda.bitmap Lambda.bitmap
> > gamma.bitmap Gamma.bitmap
> > delta.bitmap Delta.bitmap
> > 
> > aTx=b.bitmap ATX=B.bitmap
> > 
> > The first group consists of images of greek letters, version with
> > lowercase name is lowercase letter, while uppercase letter has
> > the first letter of filename in upper case.
> >
> 
> I suggest the following changes:
> 
> s/Xi.bitmap/xi-cap.bitmap/
> s/Upsilon.bitmap/upsilon-cap.bitmap/
> s/Theta.bitmap/theta-cap.bitmap/
> s/Sigma.bitmap/sigma-cap.bitmap/
> s/Psi.bitmap/psi-cap.bitmap/
> s/Pi.bitmap/pi-cap.bitmap/
> s/Phi.bitmap/phi-cap.bitmap/
> s/Omega.bitmap/omega-cap.bitmap/
> s/Lambda.bitmap/lambda-cap.bitmap/
> s/Gamma.bitmap/gamma-cap.bitmap/
> s/Delta.bitmap/delta-cap.bitmap/
> 
> I think the following two files are not used anywhere:
> 
> aTx=b.bitmap
> ATX=B.bitmap
>

The string 'ATX=B' does not appear in interpreter sources, so I think
it is reasonable to assume that 'ATX=B.bitmap' is unused.
 
>  
> > Also in 'src/doc/ps' we have 'SEGBIND.ps' and 'segbind.ps'.  
> > 'segbind.ps' is a screen dump of a graphic window containing a
> > parabola.  I can not really see 'SEGBIND.ps' because it triggers
> > Postscript stack error in ghostscript (like many other files in
> > 'src/doc/ps' :(.
> > 
> 
> I think all .ps files that are not referenced in any *.pamphlet file
> (such as SEGBIND.ps and segbind.ps) should be deleted from the /ps
> directory.
> 

AFAICS segbind.ps is just a parabola (graph of square function). 
I think it is safe to delete both 'SEGBIND.ps' and 'segbind.ps'
-- both look like trash left by developers.

I propose: rename capital Greek letters according to
Bill Page proposal.  Adjust 'util.ht' to match (all other
hypertex pages should access Greek letters only via macros
defined in 'util.ht').  
Next, remove 'ATX=B.bitmap', 'SEGBIND.ps' and 'segbind.ps'.

Those changes should solve problems with duplicate filenames on
case insensitive filesystems.

--- build-improvements.pp/src/hyper/pages/util.ht	2006-11-02 18:27:39.000000000 +0100
+++ build-improvements/src/hyper/pages/util.ht	2006-11-07 22:43:56.499790528 +0100
@@ -240,7 +240,7 @@
 \newcommand{\coprod}{\inputbitmap{\htbmdir{}/coprod.bitmap}}
 \newcommand{\del}{\inputbitmap{\htbmdir{}/del.bitmap}}
 \newcommand{\delta}{\inputbitmap{\htbmdir{}/delta.bitmap}}
-\newcommand{\Delta}{\inputbitmap{\htbmdir{}/Delta.bitmap}}
+\newcommand{\Delta}{\inputbitmap{\htbmdir{}/Delta-cap.bitmap}}
 \newcommand{\div}{\inputbitmap{\htbmdir{}/div.bitmap}}
 \newcommand{\dot}{\inputbitmap{\htbmdir{}/dot.bitmap}}
 \newcommand{\ell}{\inputbitmap{\htbmdir{}/ell.bitmap}}
@@ -253,7 +253,7 @@
 \newcommand{\footnote}[1]{ {(#1)}}
 \newcommand{\frenchspacing}{}
 \newcommand{\gamma}{\inputbitmap{\htbmdir{}/gamma.bitmap}}
-\newcommand{\Gamma}{\inputbitmap{\htbmdir{}/Gamma.bitmap}}
+\newcommand{\Gamma}{\inputbitmap{\htbmdir{}/Gamma-cap.bitmap}}
 \newcommand{\hbar}{\inputbitmap{\htbmdir{}/hbar.bitmap}}
 \newcommand{\hbox}[1]{{#1}}
 \newcommand{\hfill}{}
@@ -269,7 +269,7 @@
 \newcommand{\kappa}{\inputbitmap{\htbmdir{}/kappa.bitmap}}
 \newcommand{\label}[1]{}
 \newcommand{\lambda}{\inputbitmap{\htbmdir{}/lambda.bitmap}}
-\newcommand{\Lambda}{\inputbitmap{\htbmdir{}/Lambda.bitmap}}
+\newcommand{\Lambda}{\inputbitmap{\htbmdir{}/Lambda-cap.bitmap}}
 \newcommand{\large}{}
 \newcommand{\ldots}{...}
 \newcommand{\le}{<=}
@@ -282,41 +282,41 @@
 \newcommand{\nabla}{\inputbitmap{\htbmdir{}/nabla.bitmap}}
 \newcommand{\nu}{\inputbitmap{\htbmdir{}/nu.bitmap}}
 \newcommand{\omega}{\inputbitmap{\htbmdir{}/omega.bitmap}}
-\newcommand{\Omega}{\inputbitmap{\htbmdir{}/Omega.bitmap}}
+\newcommand{\Omega}{\inputbitmap{\htbmdir{}/Omega-cap.bitmap}}
 \newcommand{\pageref}[1]{???}
 \newcommand{\parallel}{\inputbitmap{\htbmdir{}/parallel.bitmap}}
 \newcommand{\partial}{\inputbitmap{\htbmdir{}/partial.bitmap}}
 \newcommand{\phi}{\inputbitmap{\htbmdir{}/phi.bitmap}}
-\newcommand{\Phi}{\inputbitmap{\htbmdir{}/Phi.bitmap}}
+\newcommand{\Phi}{\inputbitmap{\htbmdir{}/Phi-cap.bitmap}}
 \newcommand{\pi}{\inputbitmap{\htbmdir{}/pi.bitmap}}
-\newcommand{\Pi}{\inputbitmap{\htbmdir{}/Pi.bitmap}}
+\newcommand{\Pi}{\inputbitmap{\htbmdir{}/Pi-cap.bitmap}}
 \newcommand{\prime}{\inputbitmap{\htbmdir{}/prime.bitmap}}
 \newcommand{\prod}{\inputbitmap{\htbmdir{}/prod.bitmap}}
 \newcommand{\protect}{}
 \newcommand{\psi}{\inputbitmap{\htbmdir{}/psi.bitmap}}
-\newcommand{\Psi}{\inputbitmap{\htbmdir{}/Psi.bitmap}}
+\newcommand{\Psi}{\inputbitmap{\htbmdir{}/Psi-cap.bitmap}}
 \newcommand{\quad}{\inputbitmap{\htbmdir{}/quad.bitmap}}
 \newcommand{\Re}{\inputbitmap{\htbmdir{}/Re.bitmap}}
 \newcommand{\rho}{\inputbitmap{\htbmdir{}/rho.bitmap}}
 \newcommand{\sc}{\rm}
 \newcommand{\sf}{\bf}
 \newcommand{\sigma}{\inputbitmap{\htbmdir{}/sigma.bitmap}}
-\newcommand{\Sigma}{\inputbitmap{\htbmdir{}/Sigma.bitmap}}
+\newcommand{\Sigma}{\inputbitmap{\htbmdir{}/Sigma-cap.bitmap}}
 \newcommand{\small}{}
 \newcommand{\sum}{\inputbitmap{\htbmdir{}/sum.bitmap}}
 \newcommand{\surd}{\inputbitmap{\htbmdir{}/surd.bitmap}}
 \newcommand{\tau}{\inputbitmap{\htbmdir{}/tau.bitmap}}
 \newcommand{\theta}{\inputbitmap{\htbmdir{}/theta.bitmap}}
-\newcommand{\Theta}{\inputbitmap{\htbmdir{}/Theta.bitmap}}
+\newcommand{\Theta}{\inputbitmap{\htbmdir{}/Theta-cap.bitmap}}
 \newcommand{\times}{\inputbitmap{\htbmdir{}/times.bitmap}}
 \newcommand{\top}{\inputbitmap{\htbmdir{}/top.bitmap}}
 \newcommand{\triangle}{\inputbitmap{\htbmdir{}/triangle.bitmap}}
 \newcommand{\upsilon}{\inputbitmap{\htbmdir{}/upsilon.bitmap}}
-\newcommand{\Upsilon}{\inputbitmap{\htbmdir{}/Upsilon.bitmap}}
+\newcommand{\Upsilon}{\inputbitmap{\htbmdir{}/Upsilon-cap.bitmap}}
 \newcommand{\vbox}[1]{{#1}}
 \newcommand{\wp}{\inputbitmap{\htbmdir{}/wp.bitmap}}
 \newcommand{\xi}{\inputbitmap{\htbmdir{}/xi.bitmap}}
-\newcommand{\Xi}{\inputbitmap{\htbmdir{}/Xi.bitmap}}
+\newcommand{\Xi}{\inputbitmap{\htbmdir{}/Xi-cap.bitmap}}
 \newcommand{\zeta}{\inputbitmap{\htbmdir{}/zeta.bitmap}}
 \newcommand{\bs}{\\}
 
\start
Date: 07 Nov 2006 22:38:23 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: build-improvements and latex

Waldek Hebisch writes:

| I tried again 'make dvi' in build-improvements. There are still three
| problems:
| 1) typo in 'src/etc/Makefile.pamphlet'
| 2) confusion because Latex prefers 'axiom.sty.tex' in current directory
|    to 'axiom.sty' in search path
| 3) axiom.bib.tex file contains 10 file names with unescaped underscores
|    inside.
| 
| I have a patch solving problems 1 and 2 (included below). BTW the patch
| to solve 1 is trival.  I think that we shall agree that trivial patches
| may be commited without review (but still posted to the mailing list).
| Of course we need also agree what trivial means -- the solution to 2
| (since it involves file renaming) is probably slightly beyond trival...
| 
| BTW.  I am a bit annoyed because of discrimination of underscores (I like
| them very much), so I am tempted to solve 3 by making underscore into
| an active character, which expands to ordinary underscore outside math
| mode and to subscript char in math mode.

Hi Waldek,

  I'm busy at the moment; but patch for (1) is obviously OK.

  Patch for (2) needs an explanation in the pamphlet as to why 
we are renaming.  You explained why in previous mails, but we need the
explanation in the pamphlet, not just in the mail [yes, it shows up
only for in-source build, because LaTeX looks in the current directory
first, but we need those in the pamphlet.  This is an exception to a
general naming scheme so it needs documentation. ]

  For problem (3), I'm awaiting for input from others.

  As for your other tentative patch for checking for openpty, I
believe you're reading in my mind.  I'll comment later. Then, I'll
have to add comments to the fixes to regex issue.  However simple, it
looks, we have to explain in the pamphlets (to people not versed in
system programming), especially the faith of regexp.h and why we must
use <regex.h> and remove the old macro interface.

\start
Date: 07 Nov 2006 22:45:24 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:

| I oppose against special treatment of .sty files.
| 
| The general rule should be
| 
| notangle file.ext.pamphlet > file.ext
| noweave  file.ext.pamphlet > file.ext.pamphlet.tex
| 
| remove ".pamphlet" and add ".tex".

Ralf,

   remove ".pamphlet" and add ".tex".

translates to
   
   noweave  file.ext.pamphlet > file.ext.tex

not
 
   noweave  file.ext.pamphlet > file.ext.pamphlet.tex

I believe that is what we currently do:

    if test x$do_weave = xyes; then
        file=`basename $1 .pamphlet`
        $weave -delay $1 > $file.tex
        if test x$do_latex != xyes; then
            exit 0;
        fi
    fi

\start
Date: Tue, 07 Nov 2006 23:07:58 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

On 11/07/2006 10:45 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> | I oppose against special treatment of .sty files.
> | 
> | The general rule should be
> | 
> | notangle file.ext.pamphlet > file.ext
> | noweave  file.ext.pamphlet > file.ext.pamphlet.tex
> | 
> | remove ".pamphlet" and add ".tex".
> 
> Ralf,
> 
>    remove ".pamphlet" and add ".tex".
> 
> translates to
>    
>    noweave  file.ext.pamphlet > file.ext.tex
> 
> not
>  
>    noweave  file.ext.pamphlet > file.ext.pamphlet.tex
> 
> I believe that is what we currently do:
> 
>     if test x$do_weave = xyes; then
>         file=`basename $1 .pamphlet`
>         $weave -delay $1 > $file.tex
>         if test x$do_latex != xyes; then
>             exit 0;
>         fi
>     fi
> 
> -- gaby

Right.

And I _suggested_ to change the current rule. That would avoid the 
problem with .sty files without renaming them.

Whether we have file.ext.tex or file.ext.pamphlet.tex does not matter 
from the point of view of filenames, since there are (at least) two dots 
already. And both are generated anyway.

But my naming scheme makes it simpler to allow srcltx.sty to work. That 
would allow 'inverse search' (i.e. click in the .dvi file and jump 
directly to the corresponding line in the corresponding file in the 
editor of your choice.

We don't have that yet in Axiom that one .dvi file consists of several 
pamphlets, but I am sure that will come.


Something like below would go to axiom.sty.pamphlet.
\SOURCEROOT is only there to allow relative or absolute path in the .dvi 
file.

<<srcltx patch>>=
% For our purpose it is better to keep it in a similar form to that in
% version 1.4 of srcltx.
\@ifundefined{SOURCEROOT}{\def\SOURCEROOT{}}{}
\def\patched@src@@@input#1#2{%
   \src@before@file@hook{\ifx\@empty\SOURCEROOT\else\SOURCEROOT/\fi#2}%
     %--rhx: NO '.tex' extension in the line above.
   \src@input{#2}%
   \src@after@file@hook{#1}%
}
@

<<package srcltx>>=
<<srcltx patch>>
\IfFileExists{srcltx.sty}%
   {\usepackage{srcltx}[2004/05/15 
v1.4]\let\src@@@input\patched@src@@@input}%
   {\typeout{ALLPROSE warning: Cannot find srcltx.sty.}}
@

\start
Date: Tue, 7 Nov 2006 23:17:01 +0100 (CET)
From: Waldek Hebisch
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke wrote:
> I oppose against special treatment of .sty files.
> 
> The general rule should be
> 
> notangle file.ext.pamphlet > file.ext
> noweave  file.ext.pamphlet > file.ext.pamphlet.tex
> 
> remove ".pamphlet" and add ".tex". That rule seems to be a bit simpler 
> than having to explain why .sty files must be treated separately.
> 

Well, .sty files _are_ special (normal files do not contain "self
references").  And if you think about rule:

notangle file.ext.pamphlet > file.ext

this _is_ alredy broken by many files (in 'src/hyper') when we
have

file.pamphlet -> file.c

or

               /-> file.h
file.pamphlet -|
               \-> file.c

I agree that you proposal is logical, but it is also clumsy: .pamphlet
extension is already pretty long and sticking on it another extension
will give very long files names.

\start
Date: 07 Nov 2006 23:32:31 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:

| On 11/07/2006 10:45 PM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke writes:
| > | I oppose against special treatment of .sty files.
| > | | The general rule should be
| > | | notangle file.ext.pamphlet > file.ext
| > | noweave  file.ext.pamphlet > file.ext.pamphlet.tex
| > | | remove ".pamphlet" and add ".tex".
| > Ralf,
| >    remove ".pamphlet" and add ".tex".
| > translates to
| >       noweave  file.ext.pamphlet > file.ext.tex
| > not
| >     noweave  file.ext.pamphlet > file.ext.pamphlet.tex
| > I believe that is what we currently do:
| >     if test x$do_weave = xyes; then
| >         file=`basename $1 .pamphlet`
| >         $weave -delay $1 > $file.tex
| >         if test x$do_latex != xyes; then
| >             exit 0;
| >         fi
| >     fi
| > -- gaby
| 
| Right.
| 
| And I _suggested_ to change the current rule.

I thought your suggestion was

   remove ".pamphlet" and add ".tex". That rule seems to be a bit simpler
   than having to explain why .sty files must be treated separately.

Is that correct?

\start
Date: Tue, 07 Nov 2006 23:42:41 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: Re: build-improvements and latex

On 11/07/2006 11:17 PM, Waldek Hebisch wrote:
> Ralf Hemmecke wrote:
>> I oppose against special treatment of .sty files.
>>
>> The general rule should be
>>
>> notangle file.ext.pamphlet > file.ext
>> noweave  file.ext.pamphlet > file.ext.pamphlet.tex
>>
>> remove ".pamphlet" and add ".tex". That rule seems to be a bit simpler 
>> than having to explain why .sty files must be treated separately.
>>
> 
> Well, .sty files _are_ special (normal files do not contain "self
> references").  And if you think about rule:
> 
> notangle file.ext.pamphlet > file.ext
> 
> this _is_ alredy broken by many files (in 'src/hyper') when we
> have
> 
> file.pamphlet -> file.c
> 
> or
> 
>                /-> file.h
> file.pamphlet -|
>                \-> file.c
> 
> I agree that you proposal is logical, but it is also clumsy: .pamphlet
> extension is already pretty long and sticking on it another extension
> will give very long files names.

First. Why do you care about length of _generated_ filenames? You'll 
almost never see or touch them.

Second. With srcltx and inverse search, you _never_ have to type 
anything else than the command to start your dvi viewer with the right 
.dvi file. Everything else you read in the .dvi file, click there and 
magically your editor opens the right file at exactly the right place. I 
cannot imagine why you don't want that.

Third. I perhaps agree that just removing ".pamphlet" is not the best 
idea in general as you showed for pamphlets that contain .h and .c 
files. But note that then the corresponding Makefile must be more 
complex, since some logic of the .pamphlet file (namely that 
file.pamphlet contains file.h and file.c) is maintained externally to 
the .pamphlet.

Still, I would rather like to see a general scheme than just adjusting 
locally. Keep the rules simple (or rather: introduce simple rules).

One suggestion could be to have particular chunk names that say what are 
the "top-level" chunks and which are the corresponding filenames for 
notangle. (I explicitly say notangle, since I still want to see my 
suggestion of adding ".tex" to obtain ".pamphlet.tex" for noweave.)

\start
Date: 07 Nov 2006 23:38:59 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: build-improvements and latex

Waldek Hebisch writes:

[...]

| this _is_ alredy broken by many files (in 'src/hyper') when we
| have
| 
| file.pamphlet -> file.c
| 
| or
| 
|                /-> file.h
| file.pamphlet -|
|                \-> file.c
| 

I considered that some time ago.  

However, I must confess: file.h and file.c, to my mind, forms a
logical unit.  Consequently I think of file.pamphlet as that logical
unit be described.  I see no logical problem or exception that from
that logical unit, different sub-units are extracted to be processed by
the same tool (the C compiler). 
Consequently, I'm not convinced that it can be used an evidence for
the axiom.sty treatment.

| I agree that you proposal is logical, but it is also clumsy: .pamphlet
| extension is already pretty long and sticking on it another extension
| will give very long files names.

I agree that the .pamphlet is clumsy, and we should not sacrifice
logic. 

I would like to understand more Ralf's suggestion, because I got
the impression that we already implemented what he is suggesting (but
apparently no).

\start
Date: Tue, 7 Nov 2006 17:45:42 -0500
From: Bill Page
To: Waldek Hebisch
Subject: RE: build-improvements and latex

On Tuesday, November 07, 2006 5:17 PM Waldek Hebisch wrote:
>
> Ralf Hemmecke wrote:
> > I oppose against special treatment of .sty files.
> >
> > The general rule should be
> >
> > notangle file.ext.pamphlet > file.ext
> > noweave  file.ext.pamphlet > file.ext.pamphlet.tex
> >
> > remove ".pamphlet" and add ".tex". That rule seems to be
> > a bit simpler than having to explain why .sty files must
> > be treated separately.
> >

I don't think what Waldek proposes amounts to "separate treatment".
He is just observing that the existing name for the pamphlet file
conflicts with the behaviour of latex.

>
> Well, .sty files _are_ special (normal files do not contain
> "self references").

I think Waldek is right. This name for the pamphlet file is
unusal. The only convention that we have is really just:

  noweave  filename.pamphlet > filename.tex
  latex filename.tex

and I think that is very natural because noweave always applies to
the entire file. Normally, the filename part does not contain any dot.

> And if you think about rule:
>
> notangle file.ext.pamphlet > file.ext

notangle is completely different because it can either apply to
the whole file or to just one chunk of the file (-R option). If
we have a convention for notangle, then I think it should be like
this:

  notangle filename.pamphlet -R 'file.ext' > file.ext

>
> this _is_ alredy broken by many files (in 'src/hyper') when we
> have
>
> file.pamphlet -> file.c
>

Is there a case like this? Maybe it should be written:

  notangle file.pamphlet -R 'file.c' > file.c

With <<file.c>>= defined appropriately.

> or
>
>                /-> file.h
> file.pamphlet -|
>                \-> file.c
>

In this case I think it is really

  notangle file.pamphlet -R 'file.h' > file.h
  notangle file.pamphlet -R 'file.c' > file.c

Right?

> I agree that you proposal is logical, but it is also clumsy:
> .pamphlet extension is already pretty long and sticking on it
> another extension will give very long files names.
>

I think the only convincing reason that Ralf gave for his
convention for noweave was interaction with point-and-click
in dvi. But this could be achieved through a different
patch to srcltx. No?

\start
Date: Tue, 07 Nov 2006 23:56:40 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

> | And I _suggested_ to change the current rule.

> I thought your suggestion was
> 
>    remove ".pamphlet" and add ".tex". That rule seems to be a bit simpler
>    than having to explain why .sty files must be treated separately.
> 
> Is that correct?

If I ever suggested that, I must have made a terrible mistake. I 
remember that we recently (about a week ago or so) had something on the 
list about .sty files. At that time your document had already been written.

No my suggestion is as I said in my last mail.
noweave file.pamphlet > file.pamphlet.tex.

Removing .pamphlet leads to the problem with
axiom.sty.pamphlet ---> axiom.sty.tex
axiom.sty.pamphlte ---> axiom.sty
both seen by TeX.

Rather change the document script.

\start
Date: 07 Nov 2006 23:56:51 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:

[...]

| Still, I would rather like to see a general scheme than just adjusting
| locally. Keep the rules simple (or rather: introduce simple rules).

I, too, would like to see simple rules that resolve this issue in
general and simple manner (I can think of many solutions, but I don't
see any of them general and simple yet), and has some taste to it :-)

| One suggestion could be to have particular chunk names that say what
| are the "top-level" chunks and which are the corresponding filenames
| for notangle. (I explicitly say notangle, since I still want to see my
| suggestion of adding ".tex" to obtain ".pamphlet.tex" for noweave.)

I suspect I don't see why it *must* be that we must have ".pamphlet.tex".


There is a related issue, which is how serious Axiom is about
portability.  In some places, it seems quite stringent in its demand
(leading to quite awkward and unnatural acts, e.g. abbreviation
names), and yet it cavalierly overlooks them (e.g. not all filesystems
can handle filenames with more than on does in them).

\start
Date: 08 Nov 2006 00:02:19 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements and latex

Bill Page writes:

[...]

| > this _is_ alredy broken by many files (in 'src/hyper') when we
| > have
| > 
| > file.pamphlet -> file.c
| >
| 
| Is there a case like this?

yes, many of the C pamphlet files.  My eyes was caught by that, but
quickly my brain said it was OK, because they form a logical unit.

| Maybe it should be written:
| 
|   notangle file.pamphlet -R 'file.c' > file.c

Yes, that is was it is written:

    $(builddir)/%.c: $(srcdir)/%.pamphlet
            $(axiom_build_document) --tangle --output=$@ $<

| With <<file.c>>= defined appropriately.
|  
| > or
| > 
| >                /-> file.h
| > file.pamphlet -|
| >                \-> file.c
| >
| 
| In this case I think it is really
| 
|   notangle file.pamphlet -R 'file.h' > file.h
|   notangle file.pamphlet -R 'file.c' > file.c
|  
| Right?

Yes, you're correct.

| > I agree that you proposal is logical, but it is also clumsy:
| > .pamphlet extension is already pretty long and sticking on it
| > another extension will give very long files names.
| > 
| 
| I think the only convincing reason that Ralf gave for his
| convention for noweave was interaction with point-and-click
| in dvi. But this could be achieved through a different
| patch to srcltx. No?

I completely agree with that.

\start
Date: Wed, 08 Nov 2006 00:30:36 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: build-improvements and latex

> I think the only convincing reason that Ralf gave for his
> convention for noweave was interaction with point-and-click
> in dvi. But this could be achieved through a different
> patch to srcltx. No?

But I guess that patch would be a bit longer. In the patch I gave, I use 
the fact that \src@input (which is defined as \let\src@input\input) 
automatically adds the .tex extension.

I didn't want to change srcltx.sty too much and when I stumbled over 
that file.sty/file.sty.tex problem, I decided for file.sty.nw.tex (just 
adding the .tex extension) in ALLPROSE. In that way I made the patch 
short and I avoided another problem. And my rule is simple.

It is even a bit more complicated. My patch basically gets the clicks 
right, if the file contains \input of other files. It does not work with 
the master file. So if one translates file.pamphlet to file.tex even 
with my patch one doesn't get point&click. (Or rather the click will 
lead to the .tex file and not to the .pamphlet.) For that to work 
correctly, it would need yet another patch. I haven't investigated it 
since in ALLPROSE I automatically generate a wrapper that includes the 
generated latex files (plural!).

What speaks so much against just adding .tex?
Portability? Look at the output of

cd build-improvements
find . -name '*.*.pamphlet'

Is there a plan to rename them all?

\start
Date: Tue, 7 Nov 2006 18:53:31 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: build-improvements and latex

On November 07, 2006 5:43 PM Ralf Hemmecke wrote:
> ...
> One suggestion could be to have particular chunk names that
> say what are the "top-level" chunks and which are the
> corresponding filenames for notangle.

Yes, I agree that the convention for notangle should interact
with chunk names. There is at least one system that uses noweb
format with the convention that all chunk names that "look like
file names" automatically imply extraction as a file name. E.g.

http://en.literateprograms.org/LiteratePrograms

Or we could adopt something like you suggest, i.e. a special
"top-level" chunk that contains that names of chunks to create
as files. But I think that would also have the negative effect
of hiding implicit file names inside the pamphlet file. In a
make script I think it is better to make it obvious how the
dependency is satisfied e.g.

file.c: filename.pamphlet
	document --tangle='file.c' filename.pamphlet

would extract the chunk -R 'file.c' as a file named 'file.c'
from the file 'filename.pamphlet'. Or see Gaby's stanza
template rule and my proposed modification below.

>  (I explicitly say notangle, since I still want to see my
> suggestion of adding ".tex" to obtain ".pamphlet.tex" for
> noweave.)

It is possible to use srcltx even if we don't keep the
*.pamphlet.* part if we assume that all .dvi files are
derived from .pamphlet files. Right? I think this is a
reasonable assumption for Axiom given the policy on literate
programming.

On Tuesday, November 07, 2006 6:02 PM Gaby wrote:

> ...
> Bill Page wrote:
> | Maybe it should be written:
> |
> |   notangle file.pamphlet -R 'file.c' > file.c
>
> Yes, that is was it is written:
>
>     $(builddir)/%.c: $(srcdir)/%.pamphlet
>             $(axiom_build_document) --tangle --output=$@ $<

I think with the current 'document' script that would have to
be:

     $(builddir)/%.c: $(srcdir)/%.pamphlet
             $(axiom_build_document) --tangle=$@ --output=$@ $<

because by default the --tangle option in 'document' will
extract the root chunk.

I would suggest allowing the --output option to default to the
chunk name instead of begin derived from the pamphlet name.  Then
one could wrote:

     $(builddir)/%.c: $(srcdir)/%.pamphlet
             $(axiom_build_document) --tangle=$@ $<


I.e. patch 'document' like this:

    if [ -z $output ]; then
-	output=`basename $file .pamphlet`;
+	output=$chunk;
    fi

\start
Date: Wed, 08 Nov 2006 01:04:49 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

> | 3) axiom.bib.tex file contains 10 file names with unescaped underscores
> |    inside.

> | BTW.  I am a bit annoyed because of discrimination of underscores (I like
> | them very much), so I am tempted to solve 3 by making underscore into
> | an active character, which expands to ordinary underscore outside math
> | mode and to subscript char in math mode.

>   For problem (3), I'm awaiting for input from others.

The drastic way... Remove axiom.bib.pamphlet (from which probably 
axiom.bib.tex was generated).
That is not really a .bib file. It is a collection of filenames. And I 
would rather see that the translated documentation has hyperlinks 
instead of references to a "bibliography" that consists of filenames.

If someone thinks that axiom.bib.pamphlet is a file in good LP style, I 
have not understood what LP means.

Underscores would be no problem at all if filenames where properly 
tagged. Note that there is a latex package called url
(/usr/share/texmf/tex/latex/misc/url.sty)
which provides a \path command. Together with hyperref one can turn that 
also into hyperlinks.

(I don't like underscores. They cause problems in many places.)

\start
Date: Wed, 08 Nov 2006 01:17:46 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: build-improvements and latex

> It is possible to use srcltx even if we don't keep the
> *.pamphlet.* part if we assume that all .dvi files are
> derived from .pamphlet files. Right? I think this is a
> reasonable assumption for Axiom given the policy on literate
> programming.

srcltx does nothing else than writing setting a counter for the line 
number and writes calls

\special{src:\the\inputlineno\src@maybe@space\CurrentInput

or

\special{src:1\CurrentInput}

which puts some bytes into the .dvi for the point&click.

Hmmm... the task would than be to write a tex macro which
replaces the .tex extension of \CurrentInput by .pamphlet.

Maybe that would be a solution. But it doesn't solve the axiom.sty.tex 
problem.

\start
Date: Tue, 7 Nov 2006 19:19:21 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: build-improvements and latex

Ralf,

On Tuesday, November 07, 2006 6:31 PM you wrote:

> ...
> What speaks so much against just adding .tex?
> Portability? Look at the output of
>
> cd build-improvements
> find . -name '*.*.pamphlet'
>
> Is there a plan to rename them all?
>

Ugh! You are right. Despite Gaby's implication, I can not think
of any file system in use today where we might want to run Axiom
that does not permit multiple dots in file names.

But yes, I think Tim did promote a plan that would (eventually)
change most of these names. For example I think all the .input
test files would likely be collected as chunks within a single
testing "volume" .pamphlet.

However pamphlet files with multiple chunks interact badly with
the make dependency processing since changing or adding a single
chunk in a pamphlet file triggers re-extraction of all files
dependent on that pamphlet and subseqent dependent make processing.
To over come this, we would have modify the 'document' script so
that it does not touch an existing file if it has not changed
(i.e. extract the chunk to a temporary file and overwrite the
original only if diff -q fails).

In the mean time, I think just renaming axiom.sty as Waldek
suggested is not so confusing, given the discussion in the rest
of this thread. Maybe instead of 'axiom-sty.pamphlet' something
like 'axiom-latex.pamphlet' might be a better name with
<<axiom.sty>= and possibly other latex-related chunks collected
in a single pamphlet file.

\start
Date: Wed, 08 Nov 2006 01:20:44 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

On 11/07/2006 10:45 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> | I oppose against special treatment of .sty files.
> | 
> | The general rule should be
> | 
> | notangle file.ext.pamphlet > file.ext
> | noweave  file.ext.pamphlet > file.ext.pamphlet.tex
> | 
> | remove ".pamphlet" and add ".tex".

Gaby, maybe the last sentence of mine was misleading.
I meant: remove .pamphlet for notangle and add .tex for noweave.

\start
Date: Wed, 08 Nov 2006 01:32:03 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: build-improvements and latex

> However pamphlet files with multiple chunks interact badly with
> the make dependency processing since changing or adding a single
> chunk in a pamphlet file triggers re-extraction of all files
> dependent on that pamphlet and subseqent dependent make processing.
> To over come this, we would have modify the 'document' script so
> that it does not touch an existing file if it has not changed
> (i.e. extract the chunk to a temporary file and overwrite the
> original only if diff -q fails).

I would use "cpif" for that purpose. Norman Ramsey has already thought 
of that case.

> In the mean time, I think just renaming axiom.sty as Waldek
> suggested is not so confusing, given the discussion in the rest
> of this thread. Maybe instead of 'axiom-sty.pamphlet' something
> like 'axiom-latex.pamphlet' might be a better name with
> <<axiom.sty>= and possibly other latex-related chunks collected
> in a single pamphlet file.

I agree that LP suggests to think in terms of logical units for humans, 
but on the other hand I am still a bit old-fashioned (and maybe also 
human), since I would have hard times to look in the file system for the 
place of a particular file (which is hidden in a .pamphlet file with 
another name). In that sense pamphlet files would not fit me as a human. 
Maybe I should change ... ;-)

\start
Date: Tue, 7 Nov 2006 19:39:27 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: build-improvements and latex

On Tuesday, November 07, 2006 7:05 PM Ralf Hemmecke wrote:
>
> Waldek wrote:
> ...
> > | 3) axiom.bib.tex file contains 10 file names with
> > |    unescaped underscores inside.
> ...
> Gaby wrote:
> >   For problem (3), I'm awaiting for input from others.
>
> The drastic way... Remove axiom.bib.pamphlet (from which probably
> axiom.bib.tex was generated). That is not really a .bib file. It
> is a collection of filenames. And I would rather see that the
> translated documentation has hyperlinks instead of references to
> a "bibliography" that consists of filenames.
>
> If someone thinks that axiom.bib.pamphlet is a file in good
> LP style, I have not understood what LP means.

I support Ralf's view. The axiom.bib.pamphlet file doesn't make
any sense to me.

>
> Underscores would be no problem at all if filenames where
> properly tagged. Note that there is a latex package called url
> (/usr/share/texmf/tex/latex/misc/url.sty) which provides a \path
> command. Together with hyperref one can turn that also into
> hyperlinks.
>

I like this idea but I think it might need more thought. How do
we want to present this large collection of Axiom documentation
files to a user? How will they navigate? How will this interact,
or will it interact with hyperdoc? Will they be searchable? What
is better, dvi or pdf? Etc.

\start
Date: Tue, 7 Nov 2006 19:55:19 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: build-improvements and latex

On Tuesday, November 07, 2006 7:32 PM Ralf Hemmecke wrote:
> ...
> I agree that LP suggests to think in terms of logical units for
> humans, but on the other hand I am still a bit old-fashioned
> (and maybe also human), since I would have hard times to look
> in the file system for the place of a particular file (which is
> hidden in a .pamphlet file with another name). In that sense
> pamphlet files would not fit me as a human.
> Maybe I should change ... ;-)
>

:-) That is definitely not "new think". There are many places
in the Axiom source where you already must do this, e.g. the
src/algebra/*.spad.pamphlet files.

Anyway, I think that if you are reading the .dvi file you will
already know the names of the generated files. If you are a
developer working directly with the generated files then I
think you would know enough to check the Makefile to see how
this file is generated. But it might well be convenient if there
was a nice wrapper for

  grep '<<whatever.h>>=' *.pamphlet

along the lines of what Martin Rubey wrote for the
*.spad.pamphlet files.

\start
Date: Wed, 08 Nov 2006 01:58:41 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: build-improvements and latex

>> Underscores would be no problem at all if filenames where
>> properly tagged. Note that there is a latex package called url
>> (/usr/share/texmf/tex/latex/misc/url.sty) which provides a \path
>> command. Together with hyperref one can turn that also into
>> hyperlinks.

> I like this idea but I think it might need more thought. How do
> we want to present this large collection of Axiom documentation
> files to a user? How will they navigate? How will this interact,
> or will it interact with hyperdoc? Will they be searchable? What
> is better, dvi or pdf? Etc.

I have a simple suggestion. Forget the Axiom user for a moment. First we 
need to have good documentation for developers. A user probably cares 
mose about the "algebra" subdirectory. I don't care too much about 
interaction with hyperdoc and such. The current pamphlet -> dvi way also 
does not involve hyperdoc.

My dream would be to have for each bigger unit one document (which is 
.dvi, .pdf or .html -- you have already seen in ALLPROSE that it is not 
so hard to generate different output formats). By "bigger unit" I 
approximately mean the subdirectories in src. Such a document would be 
similar to the ALLPROSE stuff -- hyperlinks here and there.

The question is whether other Axiom developers would like it or whether 
there are other suggestions we could agree upon. It's a lot of effort 
after all. And before I invest time there I would rather like to know in 
advance what other peoples dreams are. So that I don't have to throw 
away my stuff in the end.

\start
Date: Wed, 8 Nov 2006 02:35:57 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: PRECIOUS and Rosetta

I wrote that there are three problem latexing build improvement
but in fact there are more.  Namely, Makefile mark .dvi files
as .PRECIOUS so that even if Latex fails, garbled .dvi lies on
disk and is used (skipping Latex run) on the next make run.
This can easily hide errors: it seems that I re-run make twice
and it skipped over an error.

I think that in general we should remove most .PRECIOUS rules
fom Makefile: when we get error generating a file we _want_ the
file to be re-made on the next run (after all, we want to fix
the problem and check our solution).

The Latex error is that noweb garbles Rosetta.pamphlet and Latex
fails.  I reported this prevoisly and Bill Page proviede a patch:

http://lists.nongnu.org/archive/html/axiom-developer/2006-10/msg00450.html

The patch I got is probably garbled by mail (in repo '\\' combination
appears at the end of lines, while in the patch it is at begining next
line), but otherwise it looks good.  I understand that it is still
hot topic but we should do something: apply the patch, skip noweb
run on plain tex or add noweb filter to protect [[ combination
(or maybe something else).

\start
Date: Tue, 7 Nov 2006 20:49:15 -0500
From: Bill Page
To: Waldek Hebisch
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

On Tuesday, November 07, 2006 4:24 PM Waldek Hebisch wrote:

> ...
> I propose: rename capital Greek letters according to
> Bill Page proposal.  Adjust 'util.ht' to match (all other
> hypertex pages should access Greek letters only via macros
> defined in 'util.ht'). 
> Next, remove 'ATX=B.bitmap', 'SEGBIND.ps' and 'segbind.ps'.
>
> Those changes should solve problems with duplicate filenames on
> case insensitive filesystems.
>
> --- build-improvements.pp/src/hyper/pages/util.ht=09
> 2006-11-02 18:27:39.000000000 +0100
> +++ build-improvements/src/hyper/pages/util.ht=09
> 2006-11-07 22:43:56.499790528 +0100
> @@ -240,7 +240,7 @@
>  \newcommand{\coprod}{\inputbitmap{\htbmdir{}/coprod.bitmap}}
>  \newcommand{\del}{\inputbitmap{\htbmdir{}/del.bitmap}}
>  \newcommand{\delta}{\inputbitmap{\htbmdir{}/delta.bitmap}}
> -\newcommand{\Delta}{\inputbitmap{\htbmdir{}/Delta.bitmap}}
> +\newcommand{\Delta}{\inputbitmap{\htbmdir{}/Delta-cap.bitmap}}
>  \newcommand{\div}{\inputbitmap{\htbmdir{}/div.bitmap}}
>  \newcommand{\dot}{\inputbitmap{\htbmdir{}/dot.bitmap}}
>  \newcommand{\ell}{\inputbitmap{\htbmdir{}/ell.bitmap}}
> @@ -253,7 +253,7 @@
>  \newcommand{\footnote}[1]{ {(#1)}}
>  \newcommand{\frenchspacing}{}
>  \newcommand{\gamma}{\inputbitmap{\htbmdir{}/gamma.bitmap}}
> -\newcommand{\Gamma}{\inputbitmap{\htbmdir{}/Gamma.bitmap}}
> +\newcommand{\Gamma}{\inputbitmap{\htbmdir{}/Gamma-cap.bitmap}}
>  \newcommand{\hbar}{\inputbitmap{\htbmdir{}/hbar.bitmap}}
>  \newcommand{\hbox}[1]{{#1}}
>  \newcommand{\hfill}{}
> @@ -269,7 +269,7 @@
>  \newcommand{\kappa}{\inputbitmap{\htbmdir{}/kappa.bitmap}}
>  \newcommand{\label}[1]{}
>  \newcommand{\lambda}{\inputbitmap{\htbmdir{}/lambda.bitmap}}
> -\newcommand{\Lambda}{\inputbitmap{\htbmdir{}/Lambda.bitmap}}
> +\newcommand{\Lambda}{\inputbitmap{\htbmdir{}/Lambda-cap.bitmap}}
>  \newcommand{\large}{}
>  \newcommand{\ldots}{...}
>  \newcommand{\le}{<=}
> @@ -282,41 +282,41 @@
>  \newcommand{\nabla}{\inputbitmap{\htbmdir{}/nabla.bitmap}}
>  \newcommand{\nu}{\inputbitmap{\htbmdir{}/nu.bitmap}}
>  \newcommand{\omega}{\inputbitmap{\htbmdir{}/omega.bitmap}}
> -\newcommand{\Omega}{\inputbitmap{\htbmdir{}/Omega.bitmap}}
> +\newcommand{\Omega}{\inputbitmap{\htbmdir{}/Omega-cap.bitmap}}
>  \newcommand{\pageref}[1]{???}
>  \newcommand{\parallel}{\inputbitmap{\htbmdir{}/parallel.bitmap}}
>  \newcommand{\partial}{\inputbitmap{\htbmdir{}/partial.bitmap}}
>  \newcommand{\phi}{\inputbitmap{\htbmdir{}/phi.bitmap}}
> -\newcommand{\Phi}{\inputbitmap{\htbmdir{}/Phi.bitmap}}
> +\newcommand{\Phi}{\inputbitmap{\htbmdir{}/Phi-cap.bitmap}}
>  \newcommand{\pi}{\inputbitmap{\htbmdir{}/pi.bitmap}}
> -\newcommand{\Pi}{\inputbitmap{\htbmdir{}/Pi.bitmap}}
> +\newcommand{\Pi}{\inputbitmap{\htbmdir{}/Pi-cap.bitmap}}
>  \newcommand{\prime}{\inputbitmap{\htbmdir{}/prime.bitmap}}
>  \newcommand{\prod}{\inputbitmap{\htbmdir{}/prod.bitmap}}
>  \newcommand{\protect}{}
>  \newcommand{\psi}{\inputbitmap{\htbmdir{}/psi.bitmap}}
> -\newcommand{\Psi}{\inputbitmap{\htbmdir{}/Psi.bitmap}}
> +\newcommand{\Psi}{\inputbitmap{\htbmdir{}/Psi-cap.bitmap}}
>  \newcommand{\quad}{\inputbitmap{\htbmdir{}/quad.bitmap}}
>  \newcommand{\Re}{\inputbitmap{\htbmdir{}/Re.bitmap}}
>  \newcommand{\rho}{\inputbitmap{\htbmdir{}/rho.bitmap}}
>  \newcommand{\sc}{\rm}
>  \newcommand{\sf}{\bf}
>  \newcommand{\sigma}{\inputbitmap{\htbmdir{}/sigma.bitmap}}
> -\newcommand{\Sigma}{\inputbitmap{\htbmdir{}/Sigma.bitmap}}
> +\newcommand{\Sigma}{\inputbitmap{\htbmdir{}/Sigma-cap.bitmap}}
>  \newcommand{\small}{}
>  \newcommand{\sum}{\inputbitmap{\htbmdir{}/sum.bitmap}}
>  \newcommand{\surd}{\inputbitmap{\htbmdir{}/surd.bitmap}}
>  \newcommand{\tau}{\inputbitmap{\htbmdir{}/tau.bitmap}}
>  \newcommand{\theta}{\inputbitmap{\htbmdir{}/theta.bitmap}}
> -\newcommand{\Theta}{\inputbitmap{\htbmdir{}/Theta.bitmap}}
> +\newcommand{\Theta}{\inputbitmap{\htbmdir{}/Theta-cap.bitmap}}
>  \newcommand{\times}{\inputbitmap{\htbmdir{}/times.bitmap}}
>  \newcommand{\top}{\inputbitmap{\htbmdir{}/top.bitmap}}
>  \newcommand{\triangle}{\inputbitmap{\htbmdir{}/triangle.bitmap}}
>  \newcommand{\upsilon}{\inputbitmap{\htbmdir{}/upsilon.bitmap}}
> -\newcommand{\Upsilon}{\inputbitmap{\htbmdir{}/Upsilon.bitmap}}
> +\newcommand{\Upsilon}{\inputbitmap{\htbmdir{}/Upsilon-cap.bitmap}}
>  \newcommand{\vbox}[1]{{#1}}
>  \newcommand{\wp}{\inputbitmap{\htbmdir{}/wp.bitmap}}
>  \newcommand{\xi}{\inputbitmap{\htbmdir{}/xi.bitmap}}
> -\newcommand{\Xi}{\inputbitmap{\htbmdir{}/Xi.bitmap}}
> +\newcommand{\Xi}{\inputbitmap{\htbmdir{}/Xi-cap.bitmap}}
>  \newcommand{\zeta}{\inputbitmap{\htbmdir{}/zeta.bitmap}}
>  \newcommand{\bs}{\\}
> 

Great. I think this patch should go in as a priority since at this
time Axiom developers on a MAC still can not use svn to get Axiom.

But I almost hesitate to ask the following: Why aren't the files
in src/hyper/pages in pamphlet format? Well, ok, they do look like
latex files already but in this case they are also source files for
hyperdoc. Would including these files as chunks in a pamphlet file
present any technical problem to noweb?

\start
Date: Tue, 7 Nov 2006 20:57:26 -0500
From: Tim Daly
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> But I almost hesitate to ask the following: Why aren't the files
> in src/hyper/pages in pamphlet format? Well, ok, they do look like
> latex files already but in this case they are also source files for
> hyperdoc. Would including these files as chunks in a pamphlet file
> present any technical problem to noweb?

I never got the time to convert them. They should be. --t

\start
Date: Tue, 7 Nov 2006 21:12:55 -0500
From: Bill Page
To: Waldek Hebisch
Subject: RE: PRECIOUS and Rosetta

On Tuesday, November 07, 2006 8:36 PM Waldek Hebisch wrote:
>
> The Latex error is that noweb garbles Rosetta.pamphlet and Latex
> fails.  I reported this prevoisly and Bill Page provided a patch:
>
>
http://lists.nongnu.org/archive/html/axiom-developer/2006-10/msg00450.ht
ml
>
> The patch I got is probably garbled by mail (in repo '\\'
> combination appears at the end of lines, while in the patch it
> is at begining next line), but otherwise it looks good.

Here is a good copy of the patch

http://wiki.axiom-developer.org/public/rosetta.patch

But invoke the right to change my opinion... ;)

> I understand that it is still hot topic but we should do something:
> apply the patch, skip noweb run on plain tex or add noweb filter to
> protect [[ combination (or maybe something else).
>

Maybe "skip noweb run on plain tex" makes good sense if all files are
processed by the 'document' command. Really I cannot think of any good
excuse for the rosetta.pamphlet to actually be a pamphlet file, so
probably it's name should just be changed to rosetta.tex and 'document'
changed so that it does not preprocess files with noweave if the
file already has a .tex extension.

\start
Date: 08 Nov 2006 03:23:11 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements and latex

Bill Page writes:

[...]

| > Bill Page wrote: 
| > | Maybe it should be written:
| > | 
| > |   notangle file.pamphlet -R 'file.c' > file.c
| > 
| > Yes, that is was it is written:
| > 
| >     $(builddir)/%.c: $(srcdir)/%.pamphlet
| >             $(axiom_build_document) --tangle --output=$@ $<
| 
| I think with the current 'document' script that would have to
| be:
| 
|      $(builddir)/%.c: $(srcdir)/%.pamphlet
|              $(axiom_build_document) --tangle=$@ --output=$@ $<
| 
| because by default the --tangle option in 'document' will
| extract the root chunk.

Yes; but the root chunk corresponds to the .c files.  Most of them
look like this:

    <<*>>=
    <<license>>
    <<titlebar.c>>
    @ 

I must confess that I did not invent anything there:  I just
abstracted over the repetitions.

However, for header files, the rules look like this:

   <<header files>>=
   .PRECIOUS: $(builddir)/%.h

   $(HEADERS): $(builddir)/%.h: $(srcdir)/%.pamphlet
           $(axiom_build_document) --tangle=$*.h --output=$@ $<
   @

| I would suggest allowing the --output option to default to the
| chunk name instead of begin derived from the pamphlet name.  Then
| one could wrote:
| 
|      $(builddir)/%.c: $(srcdir)/%.pamphlet
|              $(axiom_build_document) --tangle=$@ $<
| 
| 
| I.e. patch 'document' like this:
| 
|     if [ -z $output ]; then
| -	output=`basename $file .pamphlet`;
| +	output=$chunk;
|     fi

this is when $chunk is specified.  That is doable.  We just have to
check when it is not specified and use the other rule.

\start
Date: 08 Nov 2006 03:26:03 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:

[...]

| What speaks so much against just adding .tex?

Simplicity in the extensions.  And yes, portability matters if you
take it seriously.

| Portability? Look at the output of
| 
| cd build-improvements
| find . -name '*.*.pamphlet'
| 
| Is there a plan to rename them all?

:-)  

Given recent discussions, I would wait till the dust gets down.

\start
Date: 08 Nov 2006 03:30:00 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements and latex

Bill Page writes:

[...]

| However pamphlet files with multiple chunks interact badly with
| the make dependency processing since changing or adding a single
| chunk in a pamphlet file triggers re-extraction of all files
| dependent on that pamphlet and subseqent dependent make processing.

Like for most (all?) generated files, there is a way out within the
GNU build system:  change a file only if its content really changed.
Use the move-if-change script.  

It is on the list of things to do for build-improvements.

\start
Date: 08 Nov 2006 03:33:33 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:

[...]

| > In the mean time, I think just renaming axiom.sty as Waldek
| > suggested is not so confusing, given the discussion in the rest
| > of this thread. Maybe instead of 'axiom-sty.pamphlet' something
| > like 'axiom-latex.pamphlet' might be a better name with
| > <<axiom.sty>= and possibly other latex-related chunks collected
| > in a single pamphlet file.
| 
| I agree that LP suggests to think in terms of logical units for
| humans, but on the other hand I am still a bit old-fashioned (and
| maybe also human), since I would have hard times to look in the file
| system for the place of a particular file (which is hidden in a
| .pamphlet file with another name). In that sense pamphlet files would
| not fit me as a human. Maybe I should change ... ;-)

The LP idea, and the pamphlet files by implication, works beautifully
when you get everything right from the start and you don't have to
look under the hood (e.g. debugging, etc.).  By definition, if you're
not using it for an evolving system -- which by definition is buggy.
By the minutes you have to deal also with the generated and
intermediate files, it becomes very very messy.

Fire!

\start
Date: 08 Nov 2006 03:37:06 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements and latex

Bill Page writes:

| On Tuesday, November 07, 2006 7:05 PM Ralf Hemmecke wrote:
| > 
| > Waldek wrote:
| > ...
| > > | 3) axiom.bib.tex file contains 10 file names with 
| > > |    unescaped underscores inside.
| > ...
| > Gaby wrote:
| > >   For problem (3), I'm awaiting for input from others.
| > 
| > The drastic way... Remove axiom.bib.pamphlet (from which probably 
| > axiom.bib.tex was generated). That is not really a .bib file. It
| > is a collection of filenames. And I would rather see that the
| > translated documentation has hyperlinks instead of references to
| > a "bibliography" that consists of filenames.
| > 
| > If someone thinks that axiom.bib.pamphlet is a file in good 
| > LP style, I have not understood what LP means.
| 
| I support Ralf's view. The axiom.bib.pamphlet file doesn't make
| any sense to me.

So, what concretly do you propose as course of action?

| > Underscores would be no problem at all if filenames where
| > properly tagged. Note that there is a latex package called url
| > (/usr/share/texmf/tex/latex/misc/url.sty) which provides a \path
| > command. Together with hyperref one can turn that also into
| > hyperlinks.
| > 
| 
| I like this idea but I think it might need more thought. How do
| we want to present this large collection of Axiom documentation
| files to a user?

You are right that the need for presenting the collection of Axiom
source files are references will not go away by axiom.bib.pamphlet.
We still need to links to references sections in other files.

| How will they navigate? How will this interact,
| or will it interact with hyperdoc? Will they be searchable? What
| is better, dvi or pdf? Etc.

PDF has my vote.

\start
Date: 08 Nov 2006 03:39:47 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:

| >> Underscores would be no problem at all if filenames where
| >> properly tagged. Note that there is a latex package called url
| >> (/usr/share/texmf/tex/latex/misc/url.sty) which provides a \path
| >> command. Together with hyperref one can turn that also into
| >> hyperlinks.
| 
| > I like this idea but I think it might need more thought. How do
| > we want to present this large collection of Axiom documentation
| > files to a user? How will they navigate? How will this interact,
| > or will it interact with hyperdoc? Will they be searchable? What
| > is better, dvi or pdf? Etc.
| 
| I have a simple suggestion. Forget the Axiom user for a moment. First
| we need to have good documentation for developers. A user probably

I care a lot about users.  I have no chance of attracting a developer
if I cannot first get him as a user.

| cares mose about the "algebra" subdirectory. I don't care too much
| about interaction with hyperdoc and such. The current pamphlet -> dvi
| way also does not involve hyperdoc.
| 
| My dream would be to have for each bigger unit one document (which is
| .dvi, .pdf or .html -- you have already seen in ALLPROSE that it is
| not so hard to generate different output formats). By "bigger unit" I
| approximately mean the subdirectories in src. Such a document would be
| similar to the ALLPROSE stuff -- hyperlinks here and there.
| 
| The question is whether other Axiom developers would like it or
| whether there are other suggestions we could agree upon. It's a lot of
| effort after all. And before I invest time there I would rather like
| to know in advance what other peoples dreams are. So that I don't have
| to throw away my stuff in the end.

I very much like hyperlinks pointing to sections in other files.  
I really disliuke duplicating documentation for no good reasons.
But, I don't know what ALLPROSE looks like in practice (sorry, I
cannot do everything...)

\start
Date: 08 Nov 2006 03:43:03 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: PRECIOUS and Rosetta

Waldek Hebisch writes:

| I wrote that there are three problem latexing build improvement
| but in fact there are more.  Namely, Makefile mark .dvi files
| as .PRECIOUS so that even if Latex fails, garbled .dvi lies on
| disk and is used (skipping Latex run) on the next make run.
| This can easily hide errors: it seems that I re-run make twice
| and it skipped over an error.
| 
| I think that in general we should remove most .PRECIOUS rules
| fom Makefile: when we get error generating a file we _want_ the
| file to be re-made on the next run (after all, we want to fix
| the problem and check our solution).

I would like to see your candidates for removal before I say
anything.  I don't see a blank rule for removing "most .PRECIOUS"
rules yet.  

\start
Date: Tue, 7 Nov 2006 22:39:09 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: build-improvements and latex

>
> | On Tuesday, November 07, 2006 7:05 PM Ralf Hemmecke wrote:
> | >
> | > Waldek wrote:
> | > ...
> | > > | 3) axiom.bib.tex file contains 10 file names with
> | > > |    unescaped underscores inside.
> | > ...
> | > Gaby wrote:
> | > >   For problem (3), I'm awaiting for input from others.
> | >
> | > The drastic way... Remove axiom.bib.pamphlet
> | ...
> Bill Page wrote:
> |
> | I support Ralf's view. The axiom.bib.pamphlet file doesn't make
> | any sense to me.

On Tuesday, November 07, 2006 9:37 PM Gaby wrote:
>
> So, what concretly do you propose as course of action?
>

I propose that we remove axiom.bib.pamphlet.

There is no axiom.bib.tex as far as I can tell - only axiom.bib.

But the idea of including citations to pamphlet files seems ill-
conceived to me. There is no documentation in the axiom.bib.pamphlet
file itself but in src/doc/Makefile.pamphlet we can read:

--------

\section{The bibtex stanza}
Axiom pamphlet files have citations. We collect all of the
pamphlet file citations into this one file so we have a standard
place and format for bibliographic references.

Citations of pamphlet files which are local are generally by the
name. For example, [[asq.c.pamphlet]] would be cited using
[[\cite{asq.c}]].

--------

But as far as I can tell this method is not actually used in any
other pamphlet file. Looking at the contents of axiom.bib I see
many non-unique entries.Further, I don't see how this wculd work
in the case where there are multiple root code chunks in a single
pamphlet file (e.g. algebra/*.spad.pamphlet).

I think that in future updates to the pamphlet files we should
encourage the use hyperref where relevant to include hypertex
links directly in the dvi/pdf files. See for example:

http://wiki.axiom-developer.org/book--main--1/Endpaper3

which contains hyperlinks in the graphics.

\start
Date: Tue, 7 Nov 2006 23:06:55 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: build-improvements and latex

On Tuesday, November 07, 2006 7:59 PM Ralf Hemmecke wrote:
> ...
> I have a simple suggestion. Forget the Axiom user for a
> moment. First we need to have good documentation for developers.
> A user probably cares most about the "algebra" subdirectory.
> I don't care too much about interaction with hyperdoc and such.
> The current pamphlet -> dvi way also does not involve hyperdoc.

I think perhaps the pamplet files should interact with hyperdoc.
Or rather hyperdoc should be replaced with a web browser interface
that would integrate with the dvi/pdf files including hyperlinks
between them.

>
> My dream would be to have for each bigger unit one document
> (which is .dvi, .pdf or .html -- you have already seen in
> ALLPROSE that it is not so hard to generate different output
> formats). By "bigger unit" I approximately mean the subdirectories
> in src. Such a document would be similar to the ALLPROSE stuff --
> hyperlinks here and there.
>
> The question is whether other Axiom developers would like it
> or whether there are other suggestions we could agree upon. It's
> a lot of effort after all. And before I invest time there I would
> rather like to know in advance what other peoples dreams are. So
> that I don't have to throw away my stuff in the end.
>

Ralf, I appreciate that you have put a lot of work into ALLPROSE
but when I look at it I see a tool that seems more suitable to
the user/developer of Axiom library code then to the general build
environment for Axiom. It that sense I see it as part of the type
of web browser interface that I referred to above.

But for development *my* dream really is not just bigger units but
rather a single outline for the entire Axiom project such as is
possible in Leo. This outline allows you to navigate freely just
like navigating in the src directory right down to the "chunk"
level with quick access to generated documentation, source code
and the build environment. The outline is like a tree structure
but includes "cloning" which actually creates a lattice and makes
it possible to create different "views" of the same information
without duplicating content.

\start
Date: Wed, 8 Nov 2006 00:13:36 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: build-improvements and latex

On Tuesday, November 07, 2006 10:39 PM I wrote:

> ...
>
> I propose that we remove axiom.bib.pamphlet.
>
> There is no axiom.bib.tex as far as I can tell - only axiom.bib.
>
> But the idea of including citations to pamphlet files seems ill-
> conceived to me. There is no documentation in the axiom.bib.pamphlet
> file itself but in src/doc/Makefile.pamphlet we can read:
>
> --------
>
> \section{The bibtex stanza}
> Axiom pamphlet files have citations. We collect all of the
> pamphlet file citations into this one file so we have a standard
> place and format for bibliographic references.
>
> Citations of pamphlet files which are local are generally by the
> name. For example, [[asq.c.pamphlet]] would be cited using
> [[\cite{asq.c}]].
>
> --------

I see also \cite mentioned here in the FAQ file:

--------

FAQ 11: How do I add a new pamphlet file
...

You must also modify src/doc/axiom.bib.pamphlet to include
the file. Axiom uses bibtex to cross-reference the various
pamphlet files. The normal method of citing a file involves
just using the name, for example \cite{asq.c} will build
a citation to the ./src/etc/asq.c.pamphlet file.

You must include the following two lines in your pamphlet file:

\bibliographystyle{plain}
\bibliography{axiom}

---------

>
> But as far as I can tell this method is not actually used in any
> other pamphlet file. Looking at the contents of axiom.bib I see
> many non-unique entries. Further, I don't see how this would work
> in the case where there are multiple root code chunks in a single
> pamphlet file (e.g. algebra/*.spad.pamphlet).
>

Am I wrong about this?

\start
Date: 08 Nov 2006 09:00:03 +0100
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

Gabriel Dos Reis writes:

> I very much like hyperlinks pointing to sections in other files.  I really
> disliuke duplicating documentation for no good reasons.  But, I don't know
> what ALLPROSE looks like in practice (sorry, I cannot do everything...)

Do you have Axiom with Aldor support installed, or, at least Aldor installed?

Do you have $ALDORROOT set?



The following should not take more than 15 minutes. If it takes longer, drop me
an email...

Go to Ralf's webpage and download packaged-allprose

http://www.hemmecke.de/aldor/packaged-allprose.tar.gz

-------------------------------------------------------------------------------

tar -xzf packaged-allprose.tar.gz

cd packaged-allprose

notangle -t8 Makefile.nw > Makefile

make

## you should now have three new shiny things: aldorextio aldorunit (these are
## due to Christian Aistleitner) and allprose (due to Ralf)

cd ~

svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat 

cd combinat/trunk/combinat

notangle -t8 Makefile.nw > Makefile


## make the documentation

make dvi

## if tex4ht is installed

make html

## or, if you actually want to use it:

make check



### or, if you prefer to use it from within axiom
### WARNING: HIGHLY EXPERIMENTAL

cd ~/combinat/branches/axiom-port/combinat

notangle -t8 Makefile.nw > Makefile

make VARIANTSTOBUILD=axiom

cd src

axiom

)lib csaxal csstream csseries csspexpr csspecies csparse csinterp

s: String := "Plus(SingletonSpecies, Times(Self, Self))"

BinTree ==> Interpret([parse s], IntegerLabel)

 l: SetSpecies IntegerLabel := set [1,2,3]

trees := structures(l)$BinTree

[retract partialNext! trees for i in 1..12]

## enjoy.


\start
Date: 08 Nov 2006 09:06:31 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Dear all,

Ralf Hemmecke writes:

> What speaks so much against just adding .tex?

I'd also speak in *favour* of simply adding .tex. It makes life easier also in
other places: 

### The following is only for those who use auctex in emacs for latexing!) ###

I use auctex and added a dead simple "document" command. Thus I can visit a
pamphlet file (for example, by clicking in HyperDoc on INT.spad)

make some changes

press

C-c C-c

\start
Date: 08 Nov 2006 09:11:17 +0100
From: Martin Rubey
To: Martin Rubey
Subject: Re: build-improvements and latex

I pressed C-c C-c in gnus, not in the pamphlet... Sorry, continuation below

Martin Rubey writes:

> Dear all,
> 
> Ralf Hemmecke writes:
> 
> > What speaks so much against just adding .tex?
> 
> I'd also speak in *favour* of simply adding .tex. It makes life easier also in
> other places: 
> 
> ### The following is only for those who use auctex in emacs for latexing!) ###
> 
> I use auctex and added a dead simple "document" command. Thus I can visit a
> pamphlet file (for example, by clicking in HyperDoc on INT.spad)
> 
> make some changes
> 
> press
> 
> C-c C-c

enter document

press C-c C-c again

auctex proposes "View". But of course, the parameter is wrong, it is

name.pamphlet.dvi

instead of

name.dvi

-------------------------------------------------------------------------------

I fail to see a reason why simply adding the tex is a bad idea.

But very often in this Makefile business I only know half of the story, so
please don't be angry with me.

\start
Date: Wed, 08 Nov 2006 10:07:50 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

On 11/08/2006 03:39 AM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> | >> Underscores would be no problem at all if filenames where | >> 
> properly tagged. Note that there is a latex package called url | >> 
> (/usr/share/texmf/tex/latex/misc/url.sty) which provides a \path | >>
>  command. Together with hyperref one can turn that also into | >> 
> hyperlinks. | | > I like this idea but I think it might need more 
> thought. How do | > we want to present this large collection of Axiom
>  documentation | > files to a user? How will they navigate? How will
>  this interact, | > or will it interact with hyperdoc? Will they be 
> searchable? What | > is better, dvi or pdf? Etc. | | I have a simple
>  suggestion. Forget the Axiom user for a moment. First | we need to 
> have good documentation for developers. A user probably
> 
> I care a lot about users.  I have no chance of attracting a developer
>  if I cannot first get him as a user.

Don't take me too seriously. What I meant was that we cannot do
everything in one stroke. Of course, I care about documentation for the
end user. All of the Axiom source code should become documentation for
an end user. An end user shoul actually just find his/her way quickly to
the section of the documentation in which he/she is interested. But, in
fact, even the documentation for developers should be written in a form
that makes it easy for "users of axiom" to become "developers of axiom".
So, in fact, I don't actually distinguish too much between developer and
end user. It's just that they will read different parts.

What I care about is that the overall documentation method should be in
some sense simple. And currently we have the Axiom-book for end-users
but we have a mess for developers.

I hope that makes my intentions a bit clearer.

> I very much like hyperlinks pointing to sections in other files. I 
> really disliuke duplicating documentation for no good reasons. But, I
> don't know what ALLPROSE looks like in practice (sorry, I cannot do
> everything...)

Understood.

For a 30 seconds impression click on

http://www.hemmecke.de/aldor/allprose/

Maybe that gives you a feeling of what I would like to see also for
axiom. (.pdf and .dvi basically look the same.)
And this is *not* just one .nw file (or .pamphlet if you like). That are
many. So in fact, it isn't really a problem to have file.c.pamphlet and
file.h.pamphlet separate, since the workflow would be: Read the .dvi and
if you find something that you want to edit, click there and suddenly
your editor opens the right file. In some sense that is like Tim's idea
of having a huge .pamphlet file, only that I have not. Only the
generated (more human readable) format is one file. The actual sources
are organised so that the build process gets simple.
Also note that all newer dvi viewers allow to search inside .dvi files. 
You can forget about grep.

\start
Date: Wed, 08 Nov 2006 10:20:48 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: build-improvements and latex

>> | > The drastic way... Remove axiom.bib.pamphlet

Sorry, I take that back. Only remove (most of) the (file referencing) 
content.

I am very much in favour of having a central .bib file (or a collection 
of them in a central place), but with actual references to papers and 
books. Even better would be what once was in discussion... Online 
documentation should directly link a reference in text to the actual 
paper if that is somewhere on the internet. But I guess we also care 
about printed versions so a .bib file is not such a bad idea in the end. 
We should however care about uniqe bibkeys, that would avoid 
duplications of entries in axiom.bib.

Maybe some day .bib files go away since there would be a central 
database of references on the internet and one only has to know a unique 
key into that database to extract all relevant information needed for a 
printed version. But up to then .bib files are of some use.

\start
Date: 08 Nov 2006 10:31:44 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:

> I am very much in favour of having a central .bib file (or a collection of
> them in a central place), but with actual references to papers and
> books. Even better would be what once was in discussion... Online
> documentation should directly link a reference in text to the actual paper if
> that is somewhere on the internet.

If you use the right style file, you get the links to the articles quite
easily. Look for example, at

http://front.math.ucdavis.edu/math.CO/0604140

(click on pdf or dvi and go to the very last page)

In fact, in my community this is standard now.

But I guess you know that?

\start
Date: Wed, 8 Nov 2006 01:45:29 -0800
From: Richard Harke
To: list
Subject: Re: [Axiom Developer FAQ] (new) from Axiom source code distribution

On Tue November 7 2006 23:05, billpage wrote:
> Changes http://wiki.axiom-developer.org/AxiomDeveloperFAQ/diff

> ===================================================================
> FAQ 1: Xlib.h is not found
> ===================================================================
>
> You need to have Xlib.h to build the graphics. If you are building
> on a RedHat 8 system you need to install the following RPM::
>
>   rpm -i !XFree86-devel-4.2.0-72.i386.rpm
>
> On Debian GNU/Linux, the package 'xlibs-dev' is needed.
>
On my ia64 debian-linux workstation, apt-get refuses to install
xlibs-dev. I think I have gotten around this by installing libxt-dev

\start
Date: Wed, 8 Nov 2006 01:51:48 -0800
From: Richard Harke
To: list
Subject: GCL loader option

I'm attempting to build the build-improvements branch on linux-ia64
build stops with message
Exactly one loader option must be chosen: dlopen=yes statsysbfd=no
       dynsysbfd=no locbfd=yes custreloc=no

I have only a vague idea of what these mean and no idea how to make the
choice into the build process.

This seems to be coming from configure for gcl-2.6.8pre

\start
Date: Wed, 08 Nov 2006 10:53:47 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: build-improvements and latex

> I think perhaps the pamplet files should interact with hyperdoc. Or
> rather hyperdoc should be replaced with a web browser interface that
> would integrate with the dvi/pdf files including hyperlinks between
> them.

I am more in favour of any webbrowser than hyperdoc. Hyperdoc looks old.
The contents is what we should care about. And then I'd like to see a 
nice help system. I think Mathematica has quite a reasonable one. It 
also links to the Mathematica book. I am not an expert in that but I 
guess, we can achieve it also in a normal webbrowser. The Eclipse 
documenation would be an example.

And yes, I like some features of hyperdoc. I like to click on a category 
or a domain and see its documentation and I can ask a category for all 
domains that implement this category. That is sometimes quite helpful. 
So in a replacement of hyperdoc must be as "active" as hyperdoc is now.

>> My dream would be to have for each bigger unit one document (which
>> is .dvi, .pdf or .html -- you have already seen in ALLPROSE that it
>> is not so hard to generate different output formats). By "bigger
>> unit" I approximately mean the subdirectories in src. Such a
>> document would be similar to the ALLPROSE stuff -- hyperlinks here
>> and there.

>> The question is whether other Axiom developers would like it or
>> whether there are other suggestions we could agree upon. It's a lot
>> of effort after all. And before I invest time there I would rather
>> like to know in advance what other peoples dreams are. So that I
>> don't have to throw away my stuff in the end.

> Ralf, I appreciate that you have put a lot of work into ALLPROSE but
> when I look at it I see a tool that seems more suitable to the
> user/developer of Axiom library code then to the general build 
> environment for Axiom.

OK, maybe I should say half-ALLPROSE. When I speak about ALLPROSE in the 
context of Axiom, it makes no sense to carry over all of the build 
procedures that are in there. Only that related to documentation is 
perhaps relevant at the moment for Axiom.  It basically concerns some 
.sty files and some conventions of how documentation should be written.

 > It that sense I see it as part of the type of
> web browser interface that I referred to above.

> But for development *my* dream really is not just bigger units but 
> rather a single outline for the entire Axiom project such as is 
> possible in Leo. This outline allows you to navigate freely just like
> navigating in the src directory right down to the "chunk" level with
> quick access to generated documentation, source code and the build
> environment. The outline is like a tree structure but includes
> "cloning" which actually creates a lattice and makes it possible to
> create different "views" of the same information without duplicating
> content.

Bill, believe me, I am actually on your side. But there are a few problems.

First. I did not find Leo too attractive to me since it does not 
actually enforce an LP style.

Second. Although I like this idea with different views (oh that would be 
the "crystal idea" right?) on code+documentation, it becomes harder to 
actually write the documentation so that it stays human readable. The 
question namely is: What are the smallest resonable units that can be 
moved around and included in other views. If you change the content of 
one unit, it also has influence on another "view" where this unit is used.

So my current position is a bit hesitant although I like this 
"multiple-views" thing.

\start
Date: Wed, 08 Nov 2006 06:09:42 -0400
From: Humberto Zuazaga
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

Gabriel Dos Reis wrote:

> The LP idea, and the pamphlet files by implication, works beautifully
> when you get everything right from the start and you don't have to
> look under the hood (e.g. debugging, etc.).  By definition, if you're
> not using it for an evolving system -- which by definition is buggy.
> By the minutes you have to deal also with the generated and
> intermediate files, it becomes very very messy.
>
> Fire!

I've used the "-L" notangle option to great effect when writing C code
with noweb. Even gdb can find the proper source lines.

\start
Date: Wed, 8 Nov 2006 11:09:34 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

> On Tuesday, November 07, 2006 4:24 PM Waldek Hebisch wrote:
> 
> > ... 
> > I propose: rename capital Greek letters according to
> > Bill Page proposal.  Adjust 'util.ht' to match (all other
> > hypertex pages should access Greek letters only via macros
> > defined in 'util.ht').  
> > Next, remove 'ATX=B.bitmap', 'SEGBIND.ps' and 'segbind.ps'.
> > 
> > Those changes should solve problems with duplicate filenames on
> > case insensitive filesystems.
> > 
> > --- build-improvements.pp/src/hyper/pages/util.ht	
> > 2006-11-02 18:27:39.000000000 +0100
> > +++ build-improvements/src/hyper/pages/util.ht	
> > 2006-11-07 22:43:56.499790528 +0100
> > @@ -240,7 +240,7 @@
> >  \newcommand{\coprod}{\inputbitmap{\htbmdir{}/coprod.bitmap}}
> >  \newcommand{\del}{\inputbitmap{\htbmdir{}/del.bitmap}}
> >  \newcommand{\delta}{\inputbitmap{\htbmdir{}/delta.bitmap}}
> > -\newcommand{\Delta}{\inputbitmap{\htbmdir{}/Delta.bitmap}}
> > +\newcommand{\Delta}{\inputbitmap{\htbmdir{}/Delta-cap.bitmap}}
> >  \newcommand{\div}{\inputbitmap{\htbmdir{}/div.bitmap}}
> >  \newcommand{\dot}{\inputbitmap{\htbmdir{}/dot.bitmap}}
> >  \newcommand{\ell}{\inputbitmap{\htbmdir{}/ell.bitmap}}
> > @@ -253,7 +253,7 @@
> >  \newcommand{\footnote}[1]{ {(#1)}}
> >  \newcommand{\frenchspacing}{}
> >  \newcommand{\gamma}{\inputbitmap{\htbmdir{}/gamma.bitmap}}
> > -\newcommand{\Gamma}{\inputbitmap{\htbmdir{}/Gamma.bitmap}}
> > +\newcommand{\Gamma}{\inputbitmap{\htbmdir{}/Gamma-cap.bitmap}}
> >  \newcommand{\hbar}{\inputbitmap{\htbmdir{}/hbar.bitmap}}
> >  \newcommand{\hbox}[1]{{#1}}
> >  \newcommand{\hfill}{}
> > @@ -269,7 +269,7 @@
> >  \newcommand{\kappa}{\inputbitmap{\htbmdir{}/kappa.bitmap}}
> >  \newcommand{\label}[1]{}
> >  \newcommand{\lambda}{\inputbitmap{\htbmdir{}/lambda.bitmap}}
> > -\newcommand{\Lambda}{\inputbitmap{\htbmdir{}/Lambda.bitmap}}
> > +\newcommand{\Lambda}{\inputbitmap{\htbmdir{}/Lambda-cap.bitmap}}
> >  \newcommand{\large}{}
> >  \newcommand{\ldots}{...}
> >  \newcommand{\le}{<=}
> > @@ -282,41 +282,41 @@
> >  \newcommand{\nabla}{\inputbitmap{\htbmdir{}/nabla.bitmap}}
> >  \newcommand{\nu}{\inputbitmap{\htbmdir{}/nu.bitmap}}
> >  \newcommand{\omega}{\inputbitmap{\htbmdir{}/omega.bitmap}}
> > -\newcommand{\Omega}{\inputbitmap{\htbmdir{}/Omega.bitmap}}
> > +\newcommand{\Omega}{\inputbitmap{\htbmdir{}/Omega-cap.bitmap}}
> >  \newcommand{\pageref}[1]{???}
> >  \newcommand{\parallel}{\inputbitmap{\htbmdir{}/parallel.bitmap}}
> >  \newcommand{\partial}{\inputbitmap{\htbmdir{}/partial.bitmap}}
> >  \newcommand{\phi}{\inputbitmap{\htbmdir{}/phi.bitmap}}
> > -\newcommand{\Phi}{\inputbitmap{\htbmdir{}/Phi.bitmap}}
> > +\newcommand{\Phi}{\inputbitmap{\htbmdir{}/Phi-cap.bitmap}}
> >  \newcommand{\pi}{\inputbitmap{\htbmdir{}/pi.bitmap}}
> > -\newcommand{\Pi}{\inputbitmap{\htbmdir{}/Pi.bitmap}}
> > +\newcommand{\Pi}{\inputbitmap{\htbmdir{}/Pi-cap.bitmap}}
> >  \newcommand{\prime}{\inputbitmap{\htbmdir{}/prime.bitmap}}
> >  \newcommand{\prod}{\inputbitmap{\htbmdir{}/prod.bitmap}}
> >  \newcommand{\protect}{}
> >  \newcommand{\psi}{\inputbitmap{\htbmdir{}/psi.bitmap}}
> > -\newcommand{\Psi}{\inputbitmap{\htbmdir{}/Psi.bitmap}}
> > +\newcommand{\Psi}{\inputbitmap{\htbmdir{}/Psi-cap.bitmap}}
> >  \newcommand{\quad}{\inputbitmap{\htbmdir{}/quad.bitmap}}
> >  \newcommand{\Re}{\inputbitmap{\htbmdir{}/Re.bitmap}}
> >  \newcommand{\rho}{\inputbitmap{\htbmdir{}/rho.bitmap}}
> >  \newcommand{\sc}{\rm}
> >  \newcommand{\sf}{\bf}
> >  \newcommand{\sigma}{\inputbitmap{\htbmdir{}/sigma.bitmap}}
> > -\newcommand{\Sigma}{\inputbitmap{\htbmdir{}/Sigma.bitmap}}
> > +\newcommand{\Sigma}{\inputbitmap{\htbmdir{}/Sigma-cap.bitmap}}
> >  \newcommand{\small}{}
> >  \newcommand{\sum}{\inputbitmap{\htbmdir{}/sum.bitmap}}
> >  \newcommand{\surd}{\inputbitmap{\htbmdir{}/surd.bitmap}}
> >  \newcommand{\tau}{\inputbitmap{\htbmdir{}/tau.bitmap}}
> >  \newcommand{\theta}{\inputbitmap{\htbmdir{}/theta.bitmap}}
> > -\newcommand{\Theta}{\inputbitmap{\htbmdir{}/Theta.bitmap}}
> > +\newcommand{\Theta}{\inputbitmap{\htbmdir{}/Theta-cap.bitmap}}
> >  \newcommand{\times}{\inputbitmap{\htbmdir{}/times.bitmap}}
> >  \newcommand{\top}{\inputbitmap{\htbmdir{}/top.bitmap}}
> >  \newcommand{\triangle}{\inputbitmap{\htbmdir{}/triangle.bitmap}}
> >  \newcommand{\upsilon}{\inputbitmap{\htbmdir{}/upsilon.bitmap}}
> > -\newcommand{\Upsilon}{\inputbitmap{\htbmdir{}/Upsilon.bitmap}}
> > +\newcommand{\Upsilon}{\inputbitmap{\htbmdir{}/Upsilon-cap.bitmap}}
> >  \newcommand{\vbox}[1]{{#1}}
> >  \newcommand{\wp}{\inputbitmap{\htbmdir{}/wp.bitmap}}
> >  \newcommand{\xi}{\inputbitmap{\htbmdir{}/xi.bitmap}}
> > -\newcommand{\Xi}{\inputbitmap{\htbmdir{}/Xi.bitmap}}
> > +\newcommand{\Xi}{\inputbitmap{\htbmdir{}/Xi-cap.bitmap}}
> >  \newcommand{\zeta}{\inputbitmap{\htbmdir{}/zeta.bitmap}}
> >  \newcommand{\bs}{\\}
> >  
> 
> Great. I think this patch should go in as a priority since at this
> time Axiom developers on a MAC still can not use svn to get Axiom.
>
Bill Page wrote: 
> But I almost hesitate to ask the following: Why aren't the files
> in src/hyper/pages in pamphlet format? Well, ok, they do look like
> latex files already but in this case they are also source files for
> hyperdoc. Would including these files as chunks in a pamphlet file
> present any technical problem to noweb?
> 

The crucial part _is_ in a pamphlet file: the files contain extracts
from Axiom book.  We just do not know (yet) how to extract them.
.pht file should be machine generated (from corresponding .ht), but
to make this process automatic one needs to fix some bugs in Axiom
(and to build without X11 we need a version of hypertex and graphic
which does not use X11).

Actually, by volume, the biggest part of .ht files are NAG manuals.  
AFAICS they were converted from other form into plain text format
and then embedded into hypertex verbatim blocks.  Proper treatement
of those files would require adding logical markup.  OTOH I am not
sure if we want to maintain NAG manuals at all -- if we switch to
a different numerical library we need different manuals.

\start
Date: Wed, 08 Nov 2006 11:23:50 +0100
From: Ralf Hemmecke
To: Humberto Zuazaga
Subject: Re: build-improvements and latex

On 11/08/2006 11:09 AM, Humberto Ortiz-Zuazaga wrote:
> Gabriel Dos Reis wrote:
> 
>> The LP idea, and the pamphlet files by implication, works beautifully
>> when you get everything right from the start and you don't have to
>> look under the hood (e.g. debugging, etc.).  By definition, if you're
>> not using it for an evolving system -- which by definition is buggy.
>> By the minutes you have to deal also with the generated and
>> intermediate files, it becomes very very messy.
>>
>> Fire!
> 
> I've used the "-L" notangle option to great effect when writing C code
> with noweb. Even gdb can find the proper source lines.

I very much support that. But what you write after the -L depends on the 
programming language that notangle spits out. Seeing #line statements in 
a generated .bib file, is maybe not such a good idea.

As I said earlier, I would rather like to see generic rules  than having 
always to look at the Makefile what actually happens. Distinguishing 
according to filetypes is probably ok, there are not too many types 
around. But I would like to see no exceptions to general rules on a 
per-file basis.

\start
Date: Wed, 8 Nov 2006 11:25:59 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: PRECIOUS and Rosetta

> Waldek Hebisch writes:
> 
> | I wrote that there are three problem latexing build improvement
> | but in fact there are more.  Namely, Makefile mark .dvi files
> | as .PRECIOUS so that even if Latex fails, garbled .dvi lies on
> | disk and is used (skipping Latex run) on the next make run.
> | This can easily hide errors: it seems that I re-run make twice
> | and it skipped over an error.
> | 
> | I think that in general we should remove most .PRECIOUS rules
> | fom Makefile: when we get error generating a file we _want_ the
> | file to be re-made on the next run (after all, we want to fix
> | the problem and check our solution).
> 
> I would like to see your candidates for removal before I say
> anything.  I don't see a blank rule for removing "most .PRECIOUS"
> rules yet.  
> 

ATM most Makfiles (and 'config/setup-dep.mk) contain rules of the sort:

.PRECIOUS: %.tex
.PRECIOUS: %.dvi
.PRECIOUS: %.o

I think that blank .PRECIOUS is may be justified _only_ for self-modifying
Makefiles.  All other files need strong justification.

\start
Date: Wed, 8 Nov 2006 05:28:00 -0500
From: Bill Page
To: Richard Harke
Subject: RE: GCL loader option

On Wednesday, November 08, 2006 4:52 AM Richard Harke wrote:
>
> I'm attempting to build the build-improvements branch on linux-ia64
> build stops with message
> Exactly one loader option must be chosen: dlopen=yes statsysbfd=no
>        dynsysbfd=no locbfd=yes custreloc=no
>
> I have only a vague idea of what these mean and no idea how
> to make the choice into the build process.
>
> This seems to be coming from configure for gcl-2.6.8pre
>

Apparently the build-improvments ./configure script does not find
bfd.h and libbfd on your system so it chooses to try to build gcl
with --disable-statsysbfd --enable-locbfd which unfortunately
seems to conflict with gcl's default for the ia64 platform.

You could try to build and install gcl first before attempting to
build build-improvements. That would allow you to specify the exact
options to use with gcl. I suggest:

$ tar xzf ~/build-improvements/zips/gcl-2.6.8pre.tgz
$ cd gcl-2.6.8pre
$ ./configure --prefix=/usr/local --disable-dlopen =
--disable-statsysbfd
\
--enable-locbfd --enable-vssize=65536*2 --enable-maxpage=256*1024 \
--disable-x --disable-xgcl --disable-tkconfig
$ make
$ make install

If that succeeds, then continue with build-improvements using

$ cd ~/build-improvments
$ ./configure --prefix=/usr/local --with-gcl
$ make

\start
Date: Wed, 8 Nov 2006 06:03:10 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: build-improvements and latex

On Wednesday, November 08, 2006 3:11 AM Martin Rubey wrote:
>
> I pressed C-c C-c in gnus, not in the pamphlet... Sorry,
> continuation below
>

What is 'gnus'?

> Martin Rubey writes:
>
> >
> > Ralf Hemmecke writes:
> >
> > > What speaks so much against just adding .tex?
> >
> > I'd also speak in *favour* of simply adding .tex. It makes
> > life easier also in other places:
> >
> > ### The following is only for those who use auctex in emacs
> > for latexing!) ###
> >
> > I use auctex and added a dead simple "document" command.
> > Thus I can visit a pamphlet file (for example, by clicking in
> > HyperDoc on INT.spad)
> >
> > make some changes
> >
> > press
> >
> > C-c C-c
>
> enter document

What does your 'document' command do?

I presume that it runs noweave and latex to create the dvi
file?

>
> press C-c C-c again
>
> auctex proposes "View". But of course, the parameter is wrong,
> it is
>
> name.pamphlet.dvi
>
> instead of
>
> name.dvi
>

Why does emacs simply assume .dvi should be appended? Is this
because it does not know that .pamphlet files create .dvi
files? I presume that if the file ends in .tex then the
parameter that emacs proposes would not be

  name.tex.dvi

which would be wrong in most cases.

Perhaps you can somehow configure emacs so that .pamphlet is
similar to .tex as an extension and should be ignored when
proposing the parameter for tex-view?


> --------------------------------------------------------------
>
> I fail to see a reason why simply adding the tex is a bad idea.
>
> But very often in this Makefile business I only know half of
> the story, so please don't be angry with me.
>

I do not think "anger" would be appropriate here... :-)

I would give the following reasons why it is bad:

1) All other programs that I can think of that process an
   input file with a given extension, generate output files
   by replacing the extension with one appropriate to the
   output. E.g.

     latex name.tex --> name.dvi
     dvipdfm name.dvi --> name.pdf

   In latex this happens even if the extension is not .tex

     latex name.pamphlet --> name.dvi

   It would be very strange to see

     latex name.tex --> name.tex.dvi
     dvipdfm name.tex.dvi --> name.tex.dvi.pdf

   wouldn't it?

2) File names with more than one . are may not be portable to
   non-linux file systems - although the only ones I can think of
   are old and unlikely candidates for Axiom.

3) Files with unnecessarily long names are more awkward to use.

Ok I admit that reasons 2) and 3) are not very strong reasons...

\start
Date: 08 Nov 2006 12:15:25 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: build-improvements and latex

Bill Page writes:

> On Wednesday, November 08, 2006 3:11 AM Martin Rubey wrote:
> > 
> > I pressed C-c C-c in gnus, not in the pamphlet... Sorry, 
> > continuation below
> >
> 
> What is 'gnus'?

the mailer/newsreader I use...

Thanks for your explanations, I think I understand now.

\start
Date: Wed, 08 Nov 2006 12:29:29 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: build-improvements and latex

> 1) All other programs that I can think of that process an
>    input file with a given extension, generate output files
>    by replacing the extension with one appropriate to the
>    output. E.g.
> 
>      latex name.tex --> name.dvi
>      dvipdfm name.dvi --> name.pdf

>    In latex this happens even if the extension is not .tex

>      latex name.pamphlet --> name.dvi

OK, that is the common state.

>    It would be very strange to see
> 
>      latex name.tex --> name.tex.dvi
>      dvipdfm name.tex.dvi --> name.tex.dvi.pdf
> 
>    wouldn't it?

Of course.

> 2) File names with more than one . are may not be portable to
>    non-linux file systems - although the only ones I can think of
>    are old and unlikely candidates for Axiom.

That is an argument. But perhaps for all those of us who are not so 
familiar with non-Linux, it would be more helpful to say which systems 
these are. The only system I know would be DOS. But then forget about 
the .pamphlet extension. You only have 3 characters. ;-)

Anything else that cannot handle 2 dots or long filenames?

> 3) Files with unnecessarily long names are more awkward to use.

> Ok I admit that reasons 2) and 3) are not very strong reasons...

Not even 1) is a reason. Why do you believe one can say

make dvi

in ALLPROSE and then say

xdvi myalps.dvi

to get the whole documentation although I have the convention
notangle removes .nw
noweave adds .tex  (result is .nw.tex)
?

There will never be generated anything else than one dvi file. And I 
don't understand, why people care so much about the names of 
intermediate files. You can remove .nw.tex files and no harm is done. If 
make would already remove them, one would not even see what strange 
things are done under the hat.
But that naming scheme simplifies the understanding of the system (only 
in my opinion, of course). One doesn't have to rename axiom.sty.pamphlet 
to axiom-sty.pamphlet.

So the only reason I see not to just add ".tex" would be portability. 
But which are systems we want to build Axiom on that cannot handle two dots?

\start
Date: Wed, 8 Nov 2006 12:52:44 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

> Bill Page writes:
> 
> [...]
> 
> | However pamphlet files with multiple chunks interact badly with
> | the make dependency processing since changing or adding a single
> | chunk in a pamphlet file triggers re-extraction of all files
> | dependent on that pamphlet and subseqent dependent make processing.
> 
> Like for most (all?) generated files, there is a way out within the
> GNU build system:  change a file only if its content really changed.
> Use the move-if-change script.  
> 
> It is on the list of things to do for build-improvements.
> 

move-if-change solves only part of the problem: if you have a file
which has dependency newer than the file itself make will try
to rebuild the file on _every_ run.  Even if extraction is not very
expensive the cost of extracting and then discarding exctracted version
may quickly accumulate.  AFAICS within make paradigm one would need
_two_ times: modification time and update time.  File needs update
if its update time is before modification time of one of its dependencies.
However, if update do not change file content only update time changes,
modification time would stay the same.  But I do not know of a make like
tool which offers such model (possibly because normal filesystems do
not provide a way to store update time).

\start
Date: Wed, 8 Nov 2006 07:04:00 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: build-improvements and latex

Oh, so much email over such a simple thing ... :-(

On Wednesday, November 08, 2006 6:29 AM Ralf Hemmecke wrote:
> ...
> Bill Page wrote:
> >    It would be very strange to see
> >
> >      latex name.tex --> name.tex.dvi
> >      dvipdfm name.tex.dvi --> name.tex.dvi.pdf
> >
> >    wouldn't it?
>
> Of course.
>
> > 2) File names with more than one . are may not be portable to
> >    non-linux file systems - although the only ones I can think of
> >    are old and unlikely candidates for Axiom.
>
> That is an argument. But perhaps for all those of us who are not so
> familiar with non-Linux, it would be more helpful to say which systems

> these are. The only system I know would be DOS. But then forget about
> the .pamphlet extension. You only have 3 characters. ;-)
>
> Anything else that cannot handle 2 dots or long filenames?
>

I think older CDrom formats also had this sort of limitation

http://en.wikipedia.org/wiki/ISO_9660

and still cause some trouble in rare cases with very long file
names.


> > 3) Files with unnecessarily long names are more awkward to use.
>
> > Ok I admit that reasons 2) and 3) are not very strong reasons...
>
> Not even 1) is a reason. Why do you believe one can say
>
> make dvi
>
> in ALLPROSE and then say
>
> xdvi myalps.dvi
>
> to get the whole documentation although I have the convention
> notangle removes .nw
> noweave adds .tex  (result is .nw.tex)
> ?
>

Good question. If the rule is "add .tex" then the result is

  latex myalps.nw.tex --> myalps.nw.dvi

not myalps.dvi. You must be doing something more to hide the .nw.

Your suggestion would require that we use awkwqard names like

  xdvi axiom.sty.pamphlet.dvi

No?

> There will never be generated anything else than one dvi file.
> And I don't understand, why people care so much about the names
> of intermediate files. You can remove .nw.tex files and no harm
> is done. If make would already remove them, one would not even
> see what strange things are done under the hat.

I don't think anyone is that worried about internal file names,
but this discussion is about making the makefiles "simpler" and
more obvious, so we do care what goes on under the hat, right?
Using a file name for dvi files that retains the original
.pamphlet extension is not so obvious to me.

> But that naming scheme simplifies the understanding of the
> system (only in my opinion, of course). One doesn't have to
> rename axiom.sty.pamphlet to axiom-sty.pamphlet.

In my opinion it is only an accident that axiom.sty.pamphlet
has this name and contains only one root chunk. In general this
is not the case.

>
> So the only reason I see not to just add ".tex" would be portability.
> But which are systems we want to build Axiom on that cannot
> handle two dots?
>

I would guess: none.

\start
Date: Wed, 08 Nov 2006 07:58:37 -0500
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke wrote:
>> I think perhaps the pamplet files should interact with hyperdoc. Or
>> rather hyperdoc should be replaced with a web browser interface that
>> would integrate with the dvi/pdf files including hyperlinks between
>> them.
> 
> I am more in favour of any webbrowser than hyperdoc. Hyperdoc looks old.
> The contents is what we should care about.

Agreed.

> And then I'd like to see a
> nice help system. I think Mathematica has quite a reasonable one. It
> also links to the Mathematica book. I am not an expert in that but I
> guess, we can achieve it also in a normal webbrowser. The Eclipse
> documenation would be an example.

I think the help system is extremely important, especially in such a
complex tool as Axiom.  Linking to the book will be somewhat tricky
though - we need to think carefully about what to link to for any given
type of help request, and possibly even write documentation with such
requests in mind in order to help make it more "searchable".  Whether
this meshes well with book style documentation I am not yet sure.

> And yes, I like some features of hyperdoc. I like to click on a category
> or a domain and see its documentation and I can ask a category for all
> domains that implement this category. That is sometimes quite helpful.

Definitely agree!

> So in a replacement of hyperdoc must be as "active" as hyperdoc is now.

I don't think that's in doubt.  Once we achieve ANSI lisp compliance
there are a number of interesting things that could be attempted in this
department.  One might be to explore the idea of using Lisp based http
server tools as a general communications protocol between all front ends
- things like Uncommon Web http://common-lisp.net/project/ucw/ and
http://www.cliki.net/araneida may prove useful in that respect.  Kai and
I talked about this briefly on IRC - one option might be to use araneida
as the "gateway" part of the client-server system.  Different clients
might not care to speak html, of course, but I doubt if there is any
fundamental reason we couldn't send arbitrary data down the pipe and
have araneida farm it out to the appropriate input handler.  I still
think McCLIM offers some very intriguing potential for an Axiom
interface in such a framework.  Anyway, interesting possibilities.


> Bill, believe me, I am actually on your side. But there are a few problems.
> 
> First. I did not find Leo too attractive to me since it does not
> actually enforce an LP style.

Perhaps that could be changed?  Or is the design of the tool not
compatible with such a requirement?  I do like the idea of the tools
enforcing the literate programming paradigm - it's too easy to get
sidetracked.  (Of course, we're going to need several hour long
"training videos" on how to work with the Axiom source code, sorta like
that SLIME tutorial movie.)

> Second. Although I like this idea with different views (oh that would be
> the "crystal idea" right?) on code+documentation, it becomes harder to
> actually write the documentation so that it stays human readable. 

I do have to agree there.

> The
> question namely is: What are the smallest resonable units that can be
> moved around and included in other views. If you change the content of
> one unit, it also has influence on another "view" where this unit is used.

I think the end consequence of such a method is that we will have to
write very small, "self contained" documentation for units that will be
used multiple places, and then "plug them in" to larger components.  I'm
dubious that discrete units below the scale of an academic paper will
prove really useful, but at a minimum it should be possible to (say)
document various TeX output formatting code (let's say I add knowledge
of siunits in a unit pamphlet, and someone else adds some chemistry
specific LaTeX output methods in a chemistry pamphlet) as part of the
original pamphlet, and then use a different view to collect all of the
various TeX output methods into a single view that could produce one
document describing all TeX output methods.  In this fashion, a general
change to all TeX output routines (for a new TeX distribution, say)
could be carried out very rapidly across many distinct categories,
without risk of "missing one" due to having to look at dozens or
hundreds of individual documents to check for special TeX output routines.

It may prove that the only really useful unit is the code chunk itself,
with the views being documents into which they plug in.  But if we could
as a chunk we were editing what views (documents) it was included in,
and check each of them before we commit the change, we could at least
keep everything consistent with a high degree of confidence and convenience.

> So my current position is a bit hesitant although I like this
> "multiple-views" thing.

I think it needs exploring, which I suppose means I need to take another
good hard run at Leo.  Such a setup also means we would need to "chunk"
the whole source code pretty much at the outset, and then fit in the
pieces - correct?  That's a mean job even without adding documentation,
but I suppose it would be a benefit in any case.

\start
Date: 08 Nov 2006 13:53:50 +0100
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: build-improvements and latex

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| > I very much like hyperlinks pointing to sections in other files.  I really
| > disliuke duplicating documentation for no good reasons.  But, I don't know
| > what ALLPROSE looks like in practice (sorry, I cannot do everything...)
| 
| Do you have Axiom with Aldor support installed, or, at least Aldor installed?

I don't have Axiom support on the machine I usually work with.

\start
Date: 08 Nov 2006 13:57:27 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:

[...]

| I hope that makes my intentions a bit clearer.

It does; thanks!

| > I very much like hyperlinks pointing to sections in other files. I
| > really disliuke duplicating documentation for no good reasons. But, I
| > don't know what ALLPROSE looks like in practice (sorry, I cannot do
| > everything...)
| 
| Understood.
| 
| For a 30 seconds impression click on
| 
| http://www.hemmecke.de/aldor/allprose/

OK, thanks.

\start
Date: 08 Nov 2006 14:01:08 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements and latex

Bill Page writes:

[...]

| I think that in future updates to the pamphlet files we should
| encourage the use hyperref where relevant to include hypertex
| links directly in the dvi/pdf files.

That makes sense.

\start
Date: 08 Nov 2006 14:05:05 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements and latex

Bill Page writes:

| On Wednesday, November 08, 2006 3:11 AM Martin Rubey wrote:
| > 
| > I pressed C-c C-c in gnus, not in the pamphlet... Sorry, 
| > continuation below
| >
| 
| What is 'gnus'?

News and mail reader:  That is what I've been for ages now, to read
bpth newsgroups and mails, and therefore write codes too :-)

\start
Date: Wed, 08 Nov 2006 08:10:20 -0500
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke wrote:
>>> | > The drastic way... Remove axiom.bib.pamphlet
> 
> Sorry, I take that back. Only remove (most of) the (file referencing)
> content.
> 
> I am very much in favour of having a central .bib file (or a collection
> of them in a central place), but with actual references to papers and
> books. Even better would be what once was in discussion... Online
> documentation should directly link a reference in text to the actual
> paper if that is somewhere on the internet. But I guess we also care
> about printed versions so a .bib file is not such a bad idea in the end.
> We should however care about uniqe bibkeys, that would avoid
> duplications of entries in axiom.bib.
> 
> Maybe some day .bib files go away since there would be a central
> database of references on the internet and one only has to know a unique
> key into that database to extract all relevant information needed for a
> printed version. But up to then .bib files are of some use.

I did some work earlier on the bibliography question and got pretty
close to something I would be happy with, it is still available on my
Axiom portal site:

http://portal.axiom-developer.org/Members/starseeker/axiombibliographysystem.tar.gz/file_view
http://portal.axiom-developer.org/Members/starseeker/axiombibliography.pdf/file_view

I suppose the pdf structuring part is of less interest to most, but I
also was able to use the ToC style files to generate links from the
bibliography to some of the online sources (not all - more work is
needed for sources Axiom would want).

Also, this bib file allows a comments section on each source.  I would
suggest this a a preferable way to have a "literate" bib file - it
remains a valid bib file, can be referenced directly by all documents
without any complications, and can still include comments on the
document by us - which to me should be sort of the best of all possible
worlds.  If it MUST be a pamphlet I would suggest that the noweb part
generate, if possible, the simple file to incorporate the bib file and
explain our conventions, plus the bib file itself.  I doubt any purpose
would be served by adding in the bib entries as "source code" in a
document, but of course I may be wrong.

\start
Date: 08 Nov 2006 14:12:09 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:

[...]

| That is an argument. But perhaps for all those of us who are not so
| familiar with non-Linux, it would be more helpful to say which systems
| these are. The only system I know would be DOS. But then forget about
| the .pamphlet extension. You only have 3 characters. ;-)

Yes.  My question is how serious Axiom takes portability?
Notice that the notion of filename limitations enshrines in the user
interface that I really dislike.

[...]

| There will never be generated anything else than one dvi file. And I
| don't understand, why people care so much about the names of
| intermediate files.

if you don't understand why you care, then I'm confused :-)

[...]

| (only in my opinion, of course). One doesn't have to rename
| axiom.sty.pamphlet to axiom-sty.pamphlet.

Yes.  This problem has many roots.  Part of it is that
build-improvements extracts the TeX file in the same directory as it
latexs it.  The problem can be papered over in many different way:
  (1) add .tex unconditionally.
  (2) replace .pamphlet with .tex and pay attention
  (3) extract to a different directory
  (4) find a btter solution.

\start
Date: 08 Nov 2006 14:17:20 +0100
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

Gabriel Dos Reis writes:

> Martin Rubey writes:
> 
> | Gabriel Dos Reis writes:
> | 
> | > I very much like hyperlinks pointing to sections in other files.  I really
> | > disliuke duplicating documentation for no good reasons.  But, I don't know
> | > what ALLPROSE looks like in practice (sorry, I cannot do everything...)
> | 
> | Do you have Axiom with Aldor support installed, or, at least Aldor installed?
> 
> I don't have Axiom support on the machine I usually work with.

That means, you have axiom and aldor installed, but they don't work together
yet?

Well, meanwhile Ralf gave you an easier way to get an impression for
ALLPROSE. Just in case you want Axiom to support Aldor on your machine, here
are the instructions:

http://wiki.axiom-developer.org/AldorForAxiom

Although I guess that you know that anyway.

BTW, is it planned to have a debian package with support for Aldor built-in?

\start
Date: 08 Nov 2006 14:19:10 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements and latex

Bill Page writes:

[...]

| Good question. If the rule is "add .tex" then the result is
| 
|   latex myalps.nw.tex --> myalps.nw.dvi
| 
| not myalps.dvi. You must be doing something more to hide the .nw.

>From my perspective, I find .nw and .pamphlet as implementation
details.  I find it unfortunate when implementation details enshrine
in the user interface.  Users should not be concerned when the
extension of the PDF or DVI files changes (because we switch to a
better tool); they should just enjoy better documentation.

[...]

| In my opinion it is only an accident that axiom.sty.pamphlet
| has this name and contains only one root chunk. In general this
| is not the case.

The axiom.sty.pamphlet is inded very special.  Its purpose and its
functionality are not the same like any others.  We should not forget
that. 

\start
Date: Wed, 8 Nov 2006 14:47:10 +0100 (CET)
From: Waldek Hebisch
To: Richard Harke
Subject: Re: GCL loader option

Richard Harke wrote:
> I'm attempting to build the build-improvements branch on linux-ia64
> build stops with message
> Exactly one loader option must be chosen: dlopen=yes statsysbfd=no
>        dynsysbfd=no locbfd=yes custreloc=no
> 
> I have only a vague idea of what these mean and no idea how to make the
> choice into the build process.
> 
> This seems to be coming from configure for gcl-2.6.8pre
> 

It seems that gcl on ia64 can only use dlopen.  Axiom tries to force
gcl to use bdf library (which is better solution when it works).  So you
should probably build gcl separately with default settings.

\start
Date: Wed, 8 Nov 2006 14:49:43 +0100 (CET)
From: Waldek Hebisch
To: Richard Harke
Subject: re: [Axiom Developer FAQ] (new) from Axiom source code distribution

Richard Harke wrote:
> On Tue November 7 2006 23:05, billpage wrote:
> > Changes http://wiki.axiom-developer.org/AxiomDeveloperFAQ/diff
> 
> > ===================================================================
> > FAQ 1: Xlib.h is not found
> > ===================================================================
> >
> > You need to have Xlib.h to build the graphics. If you are building
> > on a RedHat 8 system you need to install the following RPM::
> >
> >   rpm -i !XFree86-devel-4.2.0-72.i386.rpm
> >
> > On Debian GNU/Linux, the package 'xlibs-dev' is needed.
> >
> On my ia64 debian-linux workstation, apt-get refuses to install
> xlibs-dev. I think I have gotten around this by installing libxt-dev

debian testing has Xlib.h in libx11-dev.

\start
Date: Wed, 8 Nov 2006 09:47:47 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: build-improvements and latex

On Wednesday, November 08, 2006 8:19 AM Gaby wrote:
> ...
> Bill Page wrote:
> | In my opinion it is only an accident that axiom.sty.pamphlet
> | has this name and contains only one root chunk. In general this
> | is not the case.
>
> The axiom.sty.pamphlet is inded very special.  Its purpose and
> its functionality are not the same like any others.  We should
> not forget that.
>

I don't understand. In what way is it special? To me it looks
just like any other "header" file and could easily be a chunk
in some other latex-related file.

It seems to me the only peculiarity here is with the latex
command as reported by Waldek:

http://www.mail-archive.com/list/msg07222.html

that when given the command:

  \usepackage{axiom}

by default looks for

  axiom.sty.tex

in the current directory even though the common practice is to name
the file

  axiom.sty

and to locate it in the shared texmf file tree. To me this is
strange and unexpected. I cannot find this behaviour documented
anywhere on the web. So it looks like a bug in tex to me.

Changing axiom.sty.pamphlet to axiom-sty.pamphlet and added a
chunk named <<asxiom.sty>>= still seems like the right thing to
do to avoid this "bug". I one sentence explanation in the pamphlet
file should be enough documentation for such a simple change that
is otherwise consistent with the rest of the Axiom source code.

\start
Date: 08 Nov 2006 15:46:06 +0100
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: build-improvements and latex

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| > Martin Rubey writes:
| > 
| > | Gabriel Dos Reis writes:
| > | 
| > | > I very much like hyperlinks pointing to sections in other files.  I really
| > | > disliuke duplicating documentation for no good reasons.  But, I don't know
| > | > what ALLPROSE looks like in practice (sorry, I cannot do everything...)
| > | 
| > | Do you have Axiom with Aldor support installed, or, at least Aldor installed?
| > 
| > I don't have Axiom support on the machine I usually work with.
                 ^^^^^

sorry, that should read "Aldor".

| That means, you have axiom and aldor installed, but they don't work together
| yet?

no, that I don't have Aldor (or course, Axiom is installed).

| Well, meanwhile Ralf gave you an easier way to get an impression for
| ALLPROSE.

Yes.

[...]

| BTW, is it planned to have a debian package with support for Aldor built-in?

I don't know.  I've decided not to spend too much time on Aldor as far
as it is free only in promises.  I'm concentratig on Axiom and SPAD.

\start
Date: 08 Nov 2006 15:53:44 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: GCL loader option

Waldek Hebisch writes:

| Richard Harke wrote:
| > I'm attempting to build the build-improvements branch on linux-ia64
| > build stops with message
| > Exactly one loader option must be chosen: dlopen=yes statsysbfd=no
| >        dynsysbfd=no locbfd=yes custreloc=no
| > 
| > I have only a vague idea of what these mean and no idea how to make the
| > choice into the build process.
| > 
| > This seems to be coming from configure for gcl-2.6.8pre
| > 
| 
| It seems that gcl on ia64 can only use dlopen.  Axiom tries to force
| gcl to use bdf library (which is better solution when it works).  So you
| should probably build gcl separately with default settings.

That is a bug.  Ideally, Axiom (build-improvements, that is) should
NOT decide itself on the configure options.  However, GCL should be
able to detect that BFD is missing (or present) and decide accordingly.
Now, I rememebr Humberto asked recently what --enable-custreloc was
about.  It was put there a very long time ago.  But since then GCL's
configure's gotten smarter and needs not be told about that.  Those
are bugs that should be corrected.

\start
Date: 08 Nov 2006 16:00:11 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements and latex

Bill Page writes:

| On Wednesday, November 08, 2006 8:19 AM Gaby wrote:
| > ...
| > Bill Page wrote:
| > | In my opinion it is only an accident that axiom.sty.pamphlet
| > | has this name and contains only one root chunk. In general this
| > | is not the case.
| > 
| > The axiom.sty.pamphlet is inded very special.  Its purpose and
| > its functionality are not the same like any others.  We should
| > not forget that. 
| > 
| 
| I don't understand. In what way is it special?

It is self-referencing, and foundational to anything else for Axiom
documentation, and therefore has a more intimate relationship with TeX
than others. 

| To me it looks
| just like any other "header" file and could easily be a chunk
| in some other latex-related file.

No argument there.

| It seems to me the only peculiarity here is with the latex
| command as reported by Waldek:
| 
| http://www.mail-archive.com/list/msg07222.html
| 
| that when given the command:
| 
|   \usepackage{axiom}
| 
| by default looks for
| 
|   axiom.sty.tex
| 
| in the current directory even though the common practice is to name
| the file
| 
|   axiom.sty
| 
| and to locate it in the shared texmf file tree. To me this is
| strange and unexpected. I cannot find this behaviour documented
| anywhere on the web. So it looks like a bug in tex to me.

Probably.

| Changing axiom.sty.pamphlet to axiom-sty.pamphlet and added a
| chunk named <<asxiom.sty>>= still seems like the right thing to
| do to avoid this "bug". I one sentence explanation in the pamphlet
| file should be enough documentation for such a simple change that
| is otherwise consistent with the rest of the Axiom source code.

I'm not disagreeing with that.  I'm explaning, *why* from my
perspective, that exception to the general rule is acceptable -- even
when I don't find it perfect or don't like it.

\start
Date: Wed, 8 Nov 2006 10:53:07 -0500
From: Bill Page
To: list
Subject: porting axiom

Axiom Developers,

Well, here's our next target for Axiom build-improvements:

http://www.flypentop.com/view/page.home/home?s=algebra

Maybe we will have to seriously consider cross-compilation
afterall. :-)

Regards,
Bill Page.

PS. I want one for Christmas!

\start
Date: 08 Nov 2006 17:01:15 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: porting axiom

Bill Page writes:

[...]

| Maybe we will have to seriously consider cross-compilation
| afterall. :-)

He?  You went into great details explaining to skeptical Gaby that was
not a good idea ;-/

\start
Date: Wed, 08 Nov 2006 13:56:21 -0400
From: Humberto Zuazaga
To: Waldek Hebisch
Subject: Re: better pty patch

Waldek Hebisch wrote:
> Many systems (Linux, BSD and supposedly also Mac OS X) provide 'openpty'
> function as a preferred method to open a pty (for example on Linux

> +#ifdef HAVE_OPENPTY
> +#include <pty.h>
> +#endif

On Mac OS X 10.4 using XCode 2.2 I need to #include <util.h> instead.

\start
Date: Wed, 8 Nov 2006 15:29:52 -0500
From: Tim Daly
To: list
Subject: Latex on Compile Farm

Latex should now be on the compile farm machines --t


------- Start of forwarded message -------

Support Requests item #1551244, was opened at 2006-09-03 00:56
Message generated for change (Comment added) made by xunil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid0001&aid=1551244&group_id=1

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: SF.net Compile Farm
Group: Second Level Support
>Status: Pending
Priority: 5
Private: No
Submitted By: Tim Daly (daly)
Assigned to: Robert Liesenfeld (xunil)
Summary: Latex on Compile Farm

Initial Comment:
Axiom uses literate programming. In order to use
the compile farm machines we need to have latex
installed. Latex is fairly standard software that
has been around for 20 years so it is not experimental.
Most distributions have it installed.

Axiom runs on a wide range of hardware and we need
the compile farm to test. 

Is it possible to have it installed on the compile 
farm machines?

Tim Daly
Tim Daly


- ----------------------------------------------------------------------

>Comment By: Robert Liesenfeld (xunil)
Date: 2006-11-08 20:26

Message:
Logged In: YES 
user_id=1054

This should be installed on most of the compile farm
machines (having trouble getting it installed on a couple).
 Please let me know if there's a specific machine you need
it on, that doesn't already have it.

- ----------------------------------------------------------------------

Comment By: Wayne Davison (wdavison)
Date: 2006-09-07 16:17

Message:
Logged In: YES 
user_id=1546419

Greetings,

This canned response is used by the SourceForge.net team to
convey information about how this Support Request will be
handled.  Please read the entirety of this comment before
taking any further action; information enclosed in this comment
will help you to ensure that you have an excellent support
experience.

The SourceForge.net team takes all reported issues seriously;
we will work to provide you a complete, accurate, and timely
response to your inquiry.  Information about our support
policies and procedures may be found at:
https://sourceforge.net/docman/display_doc.php?docid=11230&group_id=1

ABOUT THIS ISSUE: Based on the initial review of this request,
we have determined that this issue will be considered to have
Moderate Priority (this is signified by the summary line we use
on this request, not by the Priority setting on this request).
Issues within this category typically include service
questions, usage problems, Compile Farm usage or system issues,
statistics, and specialized requests (such as those requiring
significant administrative overview, or which require the
development of a custom solution).  A description of this class
of issues may be found at:
https://sourceforge.net/docman/display_doc.php?docid=11230&group_id=1#issueclass_moderate

TRIAGE PROCESS: The initial review of this issue has resulted
in a member of the SourceForge.net staff determining who should
process this issue, and a change in the Priority, Summary,
Assignee, Group and Category settings for this request.

WHAT TO EXPECT: Issues of this nature will typically be
reviewed again by the assigned member of the SourceForge.net
team within 5 business days (the SourceForge.net team works at
least Monday through Friday, 9am to 5pm Pacific, excepting
holidays).  Within our next response, we will typically request
additional information about the problem you have reported, or
provide you specific troubleshooting instructions.  Please wait
patiently for our next review of, and response to, this
request.

INQUIRING ABOUT THE STATUS OF THIS ISSUE: Should you have
questions or concerns regarding the status of this issue,
simply add a comment to this support request.  All comments
you post to this support request will be received by the
SourceForge.net team member who has been assigned this issue.
Please do not submit a second support request about this issue
(add a comment to this request instead), and do not attempt to
contact the assignee of this request via email; all additional
information or comments about this request should be posted as
a comment to this request.

\start
Date: Wed, 8 Nov 2006 15:58:47 -0500
From: Bill Page
To: Tim Daly
Subject: RE: [ alexandria-SupportRequests-1551244 ] Latex on Compile Farm

On Wednesday, November 08, 2006 3:30 PM Tim Daly wrote:
>
> Latex should now be on the compile farm machines --t
>
> ...
>
> Comment By: Robert Liesenfeld (xunil)
> Date: 2006-11-08 20:26
>
> Message:
> Logged In: YES
> user_id=1054
>
> This should be installed on most of the compile farm
> machines (having trouble getting it installed on a couple).
> Please let me know if there's a specific machine you need
> it on, that doesn't already have it.
>
> ...

It looks like latex is still not available on the MAC OSX 10.2 server.

:-(

---------

Welcome to SF.net Compile Farm - OSX X-Serve, provided by Apple
OS X Version 10.2.x

ppc-osx3:~/osx $ which latex
no latex in /bin /sbin /usr/bin /usr/sbin
ppc-osx3:~/osx $ latex
bash: latex: command not found
ppc-osx3:~/osx $ ls /usr/local
ppc-osx3:~/osx $ echo $PATH
/bin:/sbin:/usr/bin:/usr/sbin
ppc-osx3:~/osx $ exit

\start
Date: Wed, 08 Nov 2006 22:38:42 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

On 11/08/2006 04:00 PM, Gabriel Dos Reis wrote:
> Bill Page writes:
> 
> | On Wednesday, November 08, 2006 8:19 AM Gaby wrote:
> | > ...
> | > Bill Page wrote:
> | > | In my opinion it is only an accident that axiom.sty.pamphlet
> | > | has this name and contains only one root chunk. In general this
> | > | is not the case.
> | > 
> | > The axiom.sty.pamphlet is inded very special.  Its purpose and
> | > its functionality are not the same like any others.  We should
> | > not forget that. 
> | > 
> | 
> | I don't understand. In what way is it special?
> 
> It is self-referencing, and foundational to anything else for Axiom
> documentation, and therefore has a more intimate relationship with TeX
> than others. 

I still don't see a reason that makes axiom.sty.pamphlet special.
First one extracts any file via notangle (tex is completely irrelevant 
here). Then one transforms pamphlets to .tex files (tex is still 
irrelevant). Now you have all the generated files you need to start the 
latex process. From that point of view even axiom.sty is not special. 
There is no bootstrapping problem.

> | It seems to me the only peculiarity here is with the latex
> | command as reported by Waldek:
> | 
> | http://www.mail-archive.com/list/msg07222.html
> | 
> | that when given the command:
> | 
> |   \usepackage{axiom}
> | 
> | by default looks for
> | 
> |   axiom.sty.tex
> | 
> | in the current directory even though the common practice is to name
> | the file
> | 
> |   axiom.sty
> | 
> | and to locate it in the shared texmf file tree. To me this is
> | strange and unexpected. I cannot find this behaviour documented
> | anywhere on the web. So it looks like a bug in tex to me.
> 
> Probably.

Is there someone who wants to earn money for finding a bug in TeX? I can 
report that in the TeXBook I have not found clearly stated that \input 
always appends the .tex extension although in all cases that are given 
as examples the .tex extension is missing and always something like 
\input story refers to story.tex.

That could perhaps be considered a bug in the TeXBook. I haven't checked 
the literate source of TeX, since \input is a TeX primitive.

But life is not so easy if you look into latex.ltx. The \input in LaTeX 
is redefined so that one can write

   \input{file}

instead of

   \input file

(in fact, one can do both).

Anyway, it all boils down to

\@@input axiom.sty

where \@@input is the original TeX primitive.

OK, let's make an experiment that doesn't involve LaTeX.

%%%BEGIN aaa.tex
\input aaa.sty
\bye
%%%END aaa.tex

%%%BEGIN aaa.sty
\message{======= I am aaa.sty =======}
%%%END aaa.sty

%%%BEGIN aaa.sty.tex
\message{======= I am aaa.sty.tex =======}
%%%END aaa.sty.tex

 >tex aaa.tex
This is TeX, Version 3.14159 (Web2C 7.4.5)
(./aaa.tex (./aaa.sty.tex ======= I am aaa.sty.tex =======) )
No pages of output.
Transcript written on aaa.log.

You can replace "sty" by "bbb" if you like.

Since when you compile axiom.sty.tex also axiom.sty must be in the path 
\usepackage will always take axiom.sty.tex instead. So the option of 
moving the files to another place does not help since they must be 
visible at the same time.

Most of you opt now for renaming axiom.sty.pamphlet to something else 
(like axiom-sty.pamphlet). I rather like to see the general rule that 
the generation should go

noweave file.pamphlet > file.pamphlet.tex

no matter how many dots are in "file".

Up to now I have only heard about MS-DOS and old CD formats that 
restrict more flexible names. Both also have the 8+3 restriction so they 
are actually out anyway if we stick to .pamphlet.

> | Changing axiom.sty.pamphlet to axiom-sty.pamphlet and added a
> | chunk named <<asxiom.sty>>= still seems like the right thing to
> | do to avoid this "bug". I one sentence explanation in the pamphlet
> | file should be enough documentation for such a simple change that
> | is otherwise consistent with the rest of the Axiom source code.
> 
> I'm not disagreeing with that.  I'm explaning, *why* from my
> perspective, that exception to the general rule is acceptable -- even
> when I don't find it perfect or don't like it.

Why would you accept even a single exception if you can have something 
without it?

\start
Date: Wed, 08 Nov 2006 23:18:23 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: build-improvements and latex

>>> 3) Files with unnecessarily long names are more awkward to use.
>>> Ok I admit that reasons 2) and 3) are not very strong reasons...
>> Not even 1) is a reason. Why do you believe one can say
>>
>> make dvi
>>
>> in ALLPROSE and then say
>>
>> xdvi myalps.dvi
>>
>> to get the whole documentation although I have the convention
>> notangle removes .nw
>> noweave adds .tex  (result is .nw.tex)
>> ?
>>
> 
> Good question. If the rule is "add .tex" then the result is
> 
>   latex myalps.nw.tex --> myalps.nw.dvi
> 
> not myalps.dvi. You must be doing something more to hide the .nw.
> 
> Your suggestion would require that we use awkwqard names like
> 
>   xdvi axiom.sty.pamphlet.dvi
> 
> No?

Wow. I must be doing something wrong. I already question whether I 
should use German to get my idea through. English doesn't seem to work. ;-)

OK. Let me repeat. In ALLPROSE and any project that is built with 
ALLPROSE there are many files. All of them have the extension .nw 
(forget about README, GPL and that). Actually all have a second 
extension. So the general form is file.ext.nw. Now my Makefile basically 
have the rule that notangle removes .nw and noweave adds .tex.

There is only *one* dvi file that will be produced and *not* one for 
every .nw file. So "xdvi axiom.sty.pamphlet.dvi" is absolutely no 
argument. One should not even look at something like 
axiom.sty.pamphlet.tex, because that is generated and could look like a 
big mess --- if you have really looked at files that come out of noweave 
you will know that theses files are not for humans even if they are .tex 
files.

So now the trick why I don't have myalps.nw.dvi.

The top-level project file is called myalps.tex.nw. Applying my rules 
gives myalps.tex and myalps.tex.nw.tex. The first one is just a wrapper 
that in shortended form looks like

\documentclass{article}
\usepackage{allprose}
\begin{document}
\author{Ralf Hemmecke}
   \title{\xProject{} \LIBRARYVERSION}}
   \maketitle
   \begin{abstract}
   ...
   \end{abstract}
\hypertarget{sec:Contents}{}\tableofcontents
\input{\projectname.tex.nw}
\end{document}

and that will be latex'ed. As you can see, it's some kind of template.
And my Makefiles make sure that the setup will be such that all other 
.nw.tex files will be included into the documentation.


There is another point that speaks against the current practise of 
translating each .pamphlet file into one .dvi, namely "literate 
programming". Ideas don't just live in one file. That completely misses 
the point that there are relations from one part of the system to 
another. For example, there should not be 5 Makefile.dvi files lying 
around in different directories. Since the build procedure should be 
described as a whole.

It would better to describe the interpreter as a whole rather than 
producing a .dvi file for each of the 187 files in src/interp.
Tim's approach (if I understood that correctly) is to make *one* huge 
.pamphlet file.
My approach is to have as many pamphlet file as you like but produce 
*one* human readable document from all of them to describe a _unit_ 
(i.e. the interpreter).

Eventually, we perhaps want just one document (a web-site, for example) 
that describe all of axiom (including the source code). For a web site 
the size doesn't matter. But still, there should be some backlinks from 
the human-readable format (.dvi) to the actual .pamphlets.


>> There will never be generated anything else than one dvi file.
>> And I don't understand, why people care so much about the names
>> of intermediate files. You can remove .nw.tex files and no harm 
>> is done. If make would already remove them, one would not even
>> see what strange things are done under the hat.
> 
> I don't think anyone is that worried about internal file names,
> but this discussion is about making the makefiles "simpler" and
> more obvious, so we do care what goes on under the hat, right?

Of course, we care about Makefiles and conventions and such but as long 
as that becomes simple, generated file names can be complicated.

> Using a file name for dvi files that retains the original
> .pamphlet extension is not so obvious to me.

I hope, this time my English is understandable.

>> But that naming scheme simplifies the understanding of the 
>> system (only in my opinion, of course). One doesn't have to
>> rename axiom.sty.pamphlet to axiom-sty.pamphlet.
> 
> In my opinion it is only an accident that axiom.sty.pamphlet
> has this name and contains only one root chunk. In general this
> is not the case.
> 
>> So the only reason I see not to just add ".tex" would be portability. 
>> But which are systems we want to build Axiom on that cannot 
>> handle two dots?

> I would guess: none.

I agree. Other opinions concerning filename portability?

\start
Date: Wed, 08 Nov 2006 23:21:46 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

> Yes.  This problem has many roots.  Part of it is that
> build-improvements extracts the TeX file in the same directory as it
> latexs it.  The problem can be papered over in many different way:
>   (1) add .tex unconditionally.
>   (2) replace .pamphlet with .tex and pay attention
>   (3) extract to a different directory
>   (4) find a btter solution.

(3) is not an option, since when you compile axiom.sty.tex --> 
axiom.sty.dvi then it does not matter whether axiom.sty is visible or 
not. \usepackage will choose the wrong file.

\start
Date: Wed, 8 Nov 2006 17:57:32 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: build-improvements and latex

On Wednesday, November 08, 2006 4:39 PM Ralf Hemmecke wrote:

>...
> Most of you opt now for renaming axiom.sty.pamphlet to something
> else (like axiom-sty.pamphlet). I rather like to see the general
> rule that the generation should go (Rule 2) :
>
> noweave file.pamphlet > file.pamphlet.tex
>
> no matter how many dots are in "file".

You should not forget to mention how the .tex name (which is only
internal) is converted to a .dvi name (which is visible to all
users). If you use latex with no extra processing then Rule 2
implies

  latex file.pamphlet.tex  --> file.pamphlet.dvi

-------

The rule used in the current Axiom make files is also simple
(Rule 1) :

  noweave file.pamphlet > file.tex
  latex file.tex   --> file.dvi
 
  no matter how many dots are in "file".

>
> > Bill Page wrote:
> > | Changing axiom.sty.pamphlet to axiom-sty.pamphlet and added a
> > | chunk named <<asxiom.sty>>= still seems like the right thing
> > | to do to avoid this "bug". I one sentence explanation in the
> > | pamphlet file should be enough documentation for such a simple
> > | change that is otherwise consistent with the rest of the Axiom
> > | source code.
> >
> Gsby wrote:
> > I'm not disagreeing with that.  I'm explaining, *why* from my
> > perspective, that exception to the general rule is acceptable
> > -- even when I don't find it perfect or don't like it.
>

I do not understand your point of view. As far as I can see there
is *no* exception to the either Rule 1 or Rule 2! What do you think
is violated by the use of the "axiom-sty.pamphlet" file name?

Perhaps you are really concerned about a different more implicit
rule (Rule 3) :

  The 'file' part of the file.pamphlet name should the same as the
  "name" of the program in the file - in other words the same as
  the name of a code chunk in the file.

Of course if there is only one such code chunk then it is natural
to try to make these names the same or at least similar. But the
application of Rule 3 is not always straightforward. If there is
more than one program or style file in the pamphlet file there
will be multiple code chunk names.

> Why would you accept even a single exception if you can have
> something without it?
>

There is *no* exception to the rule whether we choose Rule 1 or
Rule 2.

If we try to apply *both* Rule 1 and Rule 3, without renaming
axiom.sty.pamphlet to axiom-sty.pamphlet, then in this single
case of a file continuing a code chunk named <<axiom.sty>>= the
result is a conflict with the behavior of latex.

If we apply *both* Rule 2 and Rule 3, then yes this single
problem case is avoided. BUT *all* the names of all the dvi
files and the internal .tex files will change to include the
extra 'pamphlet' suffix.

But if we admit just *one more* exception to Rule 3 (there are
already many exceptions to Rule 3 in the src/algebra files),
then the combination of Rule 1 and Rule 3 is ok because we are
not obliged to make the file name and the chunk name the same
even though at this time there is only one code chunk in the
axiom-sty.pamphlet file. And we do not change any of the other
names of the intermediate .tex or external .dvi files.

-----------

Ok. I think that really is my last word on this subject! :-) In
the end I will agree to either of these choices. I just think
that Rule 1 with a small compromise to Rule 3 is the most simple
and easy approach. Obviously both methods will solve the problem.

\start
Date: 09 Nov 2006 00:17:41 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:

[...]

| Since when you compile axiom.sty.tex also axiom.sty must be in the
| path \usepackage will always take axiom.sty.tex instead. So the option
| of moving the files to another place does not help since they must be
| visible at the same time.

Sorry, I don't follow.

\start
Date: Thu, 09 Nov 2006 00:27:05 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

On 11/09/2006 12:17 AM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> [...]
> 
> | Since when you compile axiom.sty.tex also axiom.sty must be in the
> | path \usepackage will always take axiom.sty.tex instead. So the option
> | of moving the files to another place does not help since they must be
> | visible at the same time.
> 
> Sorry, I don't follow.

Can I quote a sentence of yours? "Be more specific." ;-)
What was unclear in the TeX example I gave?

\start
Date: Wed, 8 Nov 2006 18:32:19 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: build-improvements and latex

On Wednesday, November 08, 2006 5:18 PM Ralf Hemmecke wrote:
> ...
> Wow. I must be doing something wrong. I already question whether
> I should use German to get my idea through. English doesn't
> seem to work. ;-)
> ...
> There is only *one* dvi file that will be produced and *not* one
> for every .nw file. So "xdvi axiom.sty.pamphlet.dvi" is absolutely
> no argument. One should not even look at something like
> axiom.sty.pamphlet.tex, because that is generated and could
> look like a big mess --- if you have really looked at files that
> come out of noweave you will know that theses files are not for
> humans even if they are .tex files.
>

Ok, thank you! I finally understand what you are saying. :-)

  axiom.sty.pamphlet.tex

is never processed by

  latex axiom.sty.pamphlet.tex

Maybe it would be much less confusing if these files did not have
the extension .tex. Why not something like

  axiom.sty.pamphlet.inc

to make it clear that we will not be directly apply latex to this
file?

> So now the trick why I don't have myalps.nw.dvi.
>
> The top-level project file is called myalps.tex.nw. Applying my
> rules gives myalps.tex and myalps.tex.nw.tex. The first one is
> just a wrapper that in shortened form looks like
>
> \documentclass{article}
> \usepackage{allprose}
> \begin{document}
> \author{Ralf Hemmecke}
>    \title{\xProject{} \LIBRARYVERSION}}
>    \maketitle
>    \begin{abstract}
>    ...
>    \end{abstract}
> \hypertarget{sec:Contents}{}\tableofcontents
> \input{\projectname.tex.nw}
> \end{document}
>
> and that will be latex'ed.

Ok, so this is a file that we do not currently have in any of the
Axiom directories, right? We would have to create at least one for
each src directory.

> As you can see, it's some kind of template. And my Makefiles make
> sure that the setup will be such that all other .nw.tex files will
> be included into the documentation.
>

Ok.

>
> There is another point that speaks against the current practice
> of  translating each .pamphlet file into one .dvi, namely "literate
> programming". Ideas don't just live in one file. That completely
> misses the point that there are relations from one part of the
> system to another. For example, there should not be 5 Makefile.dvi
> files lying around in different directories. Since the build
> procedure should be described as a whole.

I agree.

>
> It would better to describe the interpreter as a whole rather than
> producing a .dvi file for each of the 187 files in src/interp.
> Tim's approach (if I understood that correctly) is to make *one*
> huge .pamphlet file. My approach is to have as many pamphlet file
> as you like but produce *one* human readable document from all of
> them to describe a _unit_ (i.e. the interpreter).

Yes, I like your approach much more than Tim's book volumes even
though the end result for the user is nearly the same. Nice.

>
> Eventually, we perhaps want just one document (a web-site, for
> example) that describe all of axiom (including the source code).
> For a web site the size doesn't matter. But still, there should
> be some backlinks from the human-readable format (.dvi) to the
> actual .pamphlets.
>

Ok.

> ...
> > Using a file name for dvi files that retains the original
> > .pamphlet extension is not so obvious to me.
>
> I hope, this time my English is understandable.
>

Yes certainly. I don't think the problem is your English. It
just takes time to say the critical things so that someone
else can appreciate a beautiful idea.

> ...

But now I understand, I do feel like I have to take a step back
and because this is an even bigger change then what I incorrectly
thought you were suggesting - instead of changing nearly 1000 files
we would probably be reducing the number of dvi files to less than
100. I think that might take some planning - as you originally
suggested - but I am starting to agree that the result would be
worth it.

Thanks again for your patience.

\start
Date: 09 Nov 2006 00:29:53 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements and latex
Cc: Ralf Hemmecke

Bill Page writes:

[...]

| > > Bill Page wrote: 
| > > | Changing axiom.sty.pamphlet to axiom-sty.pamphlet and added a
| > > | chunk named <<asxiom.sty>>= still seems like the right thing
| > > | to do to avoid this "bug". I one sentence explanation in the
| > > | pamphlet file should be enough documentation for such a simple
| > > | change that is otherwise consistent with the rest of the Axiom
| > > | source code.
| > >
| > Gsby wrote: 
| > > I'm not disagreeing with that.  I'm explaining, *why* from my
| > > perspective, that exception to the general rule is acceptable
| > > -- even when I don't find it perfect or don't like it.
| >
| 
| I do not understand your point of view. As far as I can see there
| is *no* exception to the either Rule 1 or Rule 2! What do you think
| is violated by the use of the "axiom-sty.pamphlet" file name?

It is ironic that we're agreeing, but we seem to think we disagree.

Let me explain again.  The *current* situation is that we have
axiom.sty.pamphlet, from which we extract axiom.sty.  Everything is
OK.  Except that for very obscure reasons, it does not seem to work
properly when LaTeXinig that specific file (sorry, Ralf, the more yyou
explain, the less I become convinced we should just add .tex).  
*A* solution is to rename the source file to axiom-sty.pamphlet, which
departs from the original naming.  axiom-sty.pamphlet is the only file
to go through that mutification.

| Perhaps you are really concerned about a different more implicit
| rule (Rule 3) :
| 
|   The 'file' part of the file.pamphlet name should the same as the
|   "name" of the program in the file - in other words the same as
|   the name of a code chunk in the file.

No.

| Of course if there is only one such code chunk then it is natural
| to try to make these names the same or at least similar. But the
| application of Rule 3 is not always straightforward. If there is
| more than one program or style file in the pamphlet file there
| will be multiple code chunk names.

yes; of course.  From my perspective, the basename should match a
logical unit, that also cleanly translates to automation.

[...]

| Ok. I think that really is my last word on this subject! :-) In
| the end I will agree to either of these choices. I just think
| that Rule 1 with a small compromise to Rule 3 is the most simple
| and easy approach. Obviously both methods will solve the problem.

For the record, I think that the renaming is my favoured option.

\start
Date: Thu, 09 Nov 2006 00:37:15 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: build-improvements and latex

> Thanks again for your patience.

Thank you for listening. ;-)

\start
Date: 09 Nov 2006 00:37:02 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:

[...]

| There is only *one* dvi file that will be produced and *not* one for
| every .nw file.

Ah, but that is a fundamental distinction between the respective
states of Axiom and your peoject.

| So "xdvi axiom.sty.pamphlet.dvi" is absolutely no argument.

Unfortunately, for Axiom, that is going to be an argument for the
short and mi-term.

[...]

| The top-level project file is called myalps.tex.nw. Applying my rules
| gives myalps.tex and myalps.tex.nw.tex. The first one is just a
| wrapper that in shortended form looks like
| 
| \documentclass{article}
| \usepackage{allprose}
| \begin{document}
| \author{Ralf Hemmecke}
|    \title{\xProject{} \LIBRARYVERSION}}
|    \maketitle
|    \begin{abstract}
|    ...
|    \end{abstract}
| \hypertarget{sec:Contents}{}\tableofcontents
| \input{\projectname.tex.nw}
| \end{document}

Aha! thanks for going through the details.
Now that you've explained the magic, I think I give a higher rank to
axiom-sty.pamphlet :-)

[...]

| It would better to describe the interpreter as a whole rather than
| producing a .dvi file for each of the 187 files in src/interp.

That is absolutely true; but I'm not sure that is solved by
systematically appending .tex.

| Tim's approach (if I understood that correctly) is to make *one* huge
| .pamphlet file.
| My approach is to have as many pamphlet file as you like but produce
| *one* human readable document from all of them to describe a _unit_
| (i.e. the interpreter).

Yes.

\start
Date: 09 Nov 2006 00:38:35 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:

| > Yes.  This problem has many roots.  Part of it is that
| > build-improvements extracts the TeX file in the same directory as it
| > latexs it.  The problem can be papered over in many different way:
| >   (1) add .tex unconditionally.
| >   (2) replace .pamphlet with .tex and pay attention
| >   (3) extract to a different directory
| >   (4) find a btter solution.
| 
| (3) is not an option,

but that is what silver does.

| since when you compile axiom.sty.tex -->
| axiom.sty.dvi then it does not matter whether axiom.sty is visible or
| not. \usepackage will choose the wrong file.

No.  It depends on where you call LaTeX from and the value of TEXINPUTS.

\start
Date: Thu, 09 Nov 2006 00:50:57 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: build-improvements and latex

Ah, one last remark. I don't yet have a complete understanding of LEO, 
but, in fact, what I am suggesting now should not prevent us from 
introducing LEO at a later stage (I think). Noweb files are noweb files. 
LEO maintains them in some way I suggest to do it in another way (maybe 
only because I did not understand LEO). Whether the compilation to dvi 
is achieved through a set of Makefile rules and perl scripts (in my 
case) or through LEO is just a matter of the tool. The .nw files should 
be the same.

And thank you, Bill. I really should change "appending .tex" to 
"appending .texinclude" or something like that. I have to explore first 
what implications that has to my srcltx setup, but with a little 
TeX-hacking that should work.

\start
Date: Thu, 09 Nov 2006 01:06:35 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

On 11/09/2006 12:37 AM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:

> | There is only *one* dvi file that will be produced and *not* one for
> | every .nw file.
> 
> Ah, but that is a fundamental distinction between the respective
> states of Axiom and your peoject.

Of course.

> | So "xdvi axiom.sty.pamphlet.dvi" is absolutely no argument.

> Unfortunately, for Axiom, that is going to be an argument for the
> short and mi-term.

Are you so sure? Where should I branch from for that experiment?

\start
Date: Wed, 8 Nov 2006 19:23:59 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: build-improvements and latex

On Wednesday, November 08, 2006 6:27 PM Ralf Hemmecke wrote:
>
> On 11/09/2006 12:17 AM, Gabriel Dos Reis wrote:
> > Ralf Hemmecke writes:
> >
> > [...]
> >
> > | Since when you compile axiom.sty.tex also axiom.sty must be in
> > | the path \usepackage will always take axiom.sty.tex instead.
> > | So the option of moving the files to another place does not
> > | help since they must be visible at the same time.
> >
> > Sorry, I don't follow.
>
> Can I quote a sentence of yours? "Be more specific." ;-)
> What was unclear in the TeX example I gave?
>

Ralf,

I think what Gaby is suggesting is that aaa.tex would be extracted
to some directory other than the current directory, e.g.

  $ noweave axiom.sty.pamphlet > intermediate/axiom.sty.tex

then presumably calling

  $ tex intermediate/axiom.sty.tex

even though it contains

  \usepackage{axiom.sty)

will not look for axiom.sty in the intermediate directory -
only the current directory.

Your test did not test this case.

Try this:

$ mkdir intermediate

Create the file 'intermediate/axiom.sty.tex'

%%%BEGIN intermediate/axiom.sty.tex
\documentclass{book}
\usepackage{axiom}
\begin{document}
test
\end{document}
%%%END intermediate/axiom.sty.tex

Now create 'axiom.sty.tex' file in the current directory

%%%BEGIN axiom.sty.tex
\message{======= I am axiom.sty.tex =======}
%%%END axiom.sty.tex

Plus two 'axiom.sty' files - one in the current directory

%%%BEGIN axiom.sty
\message{======= I am just axiom.sty =
=======}
%%%END axiom.sty

and one in the intermediate directory

%%%BEGIN intermediate/axiom.sty
\message{======= I am intermediate/axiom.sty =
=======}
%%%END intermediate/axiom.sty

Remember also that we still have the axiom.sty file in the share
texmf directory tree and tex appropriately initialized to look
for it there. That makes three 'axiom.sty' files in all.

--------

Now from the current directory run

$ latex intermediate/axiom.sty.tex
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./intermediate/axiom.sty.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german,
ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,
norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,
swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/book.cls
Document Class: book 2004/02/16 v1.4f Standard LaTeX document class
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/bk10.clo))
(./axiom.sty.tex
======= I am axiom.sty.tex =======) =
(./axiom.sty.aux) [1]
(./axiom.sty.aux) )
Output written on axiom.sty.dvi (1 page, 216 bytes).
Transcript written on axiom.sty.log.

---------

So indeed, \usepackage{axiom} does cause latex to look in the
*current* directory for 'axiom.sty.tex'.

What happens if we rename 'axiom.sty.tex' and try again?

$ mv axiom.sty.tex axiom.sty.tex_old

$ latex intermediate/axiom.sty.tex
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./intermediate/axiom.sty.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german,
ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,
norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,
swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/book.cls
Document Class: book 2004/02/16 v1.4f Standard LaTeX document class
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/bk10.clo))
(./axiom.sty
======= I am just axiom.sty =======) =
(./axiom.sty.aux) [1]
(./axiom.sty.aux) )
Output written on axiom.sty.dvi (1 page, 216 bytes).
Transcript written on axiom.sty.log.

----------

Now the devil finds 'axiom.sty' in the current directory!

Finally, let's rename 'axiom.sty' and try a 3rd time.

$ mv axiom.sty axiom.sty_old

$ latex intermediate/axiom.sty.tex
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./intermediate/axiom.sty.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german,
ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,
norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,
swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/book.cls
Document Class: book 2004/02/16 v1.4f Standard LaTeX document class
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/bk10.clo))
(/usr/local/teTeX/share/texmf-dist/tex/latex/base/axiom.sty)
(./axiom.sty.aux)
[1] (./axiom.sty.aux) )
Output written on axiom.sty.dvi (1 page, 216 bytes).
Transcript written on axiom.sty.log.

---------

Finally success. latex finds the copy of axiom.sty where it is
supposed to - in the share texmf tree (no messages).

Summary: One way to solve this stupid problem is to extract the
.tex file to an intermediate directory different from the current
directory when we run latex.

\start
Date: Wed, 8 Nov 2006 19:31:24 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: build-improvements and latex

On Wednesday, November 08, 2006 7:07 PM Ralf Hemmecke wrote:
> On 11/09/2006 12:37 AM, Gabriel Dos Reis wrote:
> > Ralf Hemmecke writes:
>
> > | There is only *one* dvi file that will be produced and
> > | *not* one for every .nw file.
> >
> > Ah, but that is a fundamental distinction between the respective
> > states of Axiom and your peoject.
>
> Of course.
>
> > | So "xdvi axiom.sty.pamphlet.dvi" is absolutely no argument.
>
> > Unfortunately, for Axiom, that is going to be an argument for
> > the short and mi-term.
>
> Are you so sure? Where should I branch from for that experiment?
>

Yes a new branch! I strongly encourage you to do that. :-)

I am just a little uncertain of the technical implications for
merging later, but I suggest that you clone build-improvements -
primarily because I think it represents the best environment in
which to experiment with alternate build scripts. It is more
modular than Axiom Gold and once you get used to it, autoconf
really does make things simpler and easier to understand.

Gaby, what do you think about branching from build-improvements?

\start
Date: 09 Nov 2006 01:44:41 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements and latex

Bill Page writes:

| On Wednesday, November 08, 2006 6:27 PM Ralf Hemmecke wrote:
| > 
| > On 11/09/2006 12:17 AM, Gabriel Dos Reis wrote:
| > > Ralf Hemmecke writes:
| > > 
| > > [...]
| > > 
| > > | Since when you compile axiom.sty.tex also axiom.sty must be in
| > > | the path \usepackage will always take axiom.sty.tex instead. 
| > > | So the option of moving the files to another place does not
| > > | help since they must be visible at the same time.
| > > 
| > > Sorry, I don't follow.
| > 
| > Can I quote a sentence of yours? "Be more specific." ;-)
| > What was unclear in the TeX example I gave?
| > 
| 
| Ralf,
| 
| I think what Gaby is suggesting is that aaa.tex would be extracted
| to some directory other than the current directory, e.g.

Yes, exactly.

\start
Date: 09 Nov 2006 01:47:21 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements and latex

Ralf Hemmecke writes:


[...]

| And thank you, Bill. I really should change "appending .tex" to
| "appending .texinclude" or something like that.

We should appoint Bill as Axiom Speaker :-)
I'm semi serious :-)

\start
Date: 09 Nov 2006 01:53:17 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements and latex

Bill Page writes:

[...]

| > > | So "xdvi axiom.sty.pamphlet.dvi" is absolutely no argument.
| > 
| > > Unfortunately, for Axiom, that is going to be an argument for
| > > the short and mi-term.
| > 
| > Are you so sure? Where should I branch from for that experiment?
| > 
| 
| Yes a new branch! I strongly encourage you to do that. :-)
| 
| I am just a little uncertain of the technical implications for
| merging later, but I suggest that you clone build-improvements -
| primarily because I think it represents the best environment in
| which to experiment with alternate build scripts. It is more
| modular than Axiom Gold and once you get used to it, autoconf
| really does make things simpler and easier to understand.
| 
| Gaby, what do you think about branching from build-improvements?

That makes perfect sense to me.  Ralf can sync from build-improvements
at any time.

Given recent discussions, I would very much appreciate Tim shime in.

\start
Date: Wed, 8 Nov 2006 20:02:32 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

> Given recent discussions, I would very much appreciate Tim shime in.

I have no opinion.

\start
Date: Thu, 9 Nov 2006 02:58:53 +0100 (CET)
From: Waldek Hebisch
To: Francois Maltey
Subject: Re: axiom for trigonometric functions again...

> Hi Waldek,
> 
> Thanks for your reponse. 
> It is my purpose.
> 
> My main idea is to get expand (cos (2*x)) working as expand (cos (x+y)).
> 
> Do you know if it's possible or must I write my own package ?
>

So, you want expand (cos (2*x)) giving you: 

             2         2
    - sin(x)  + cos(x)

Well, rischNormalize will not help you doing this.  My point was
that rischNormalize can collapse rather compilcated expressions to
zero (ATM rischNormalize handles only expressions in one variable,
but the method is general and it should be easy to make own version
which handles arbitrary many variables).  

I think you need your own package -- rischNormalize may help you
write it.

\start
Date: Wed, 8 Nov 2006 21:17:14 -0500
From: Bill Page
To: list
Subject: LANL NetworkX and algebra dependency graph

Axiom Developers;

Over a year ago we were discussing how best to represent Axiom's
algebra dependency graph. This is a complex problem because Axiom
has over 1,300 mathematically modules that are tightly integrated
with each other - even to the point of generating a large number
cyclical dependency chains in the underlying code. This considerably
complicates bootstrap process by which Axiom is built and could
even call into question the fundamental means by which these
dependency loops are solved in the current build (e.g. It is known
that just a single iteration of bootstrap -> compile -> bootstrap
is not sufficient to produce a fixed point solution.)

A Java graph theory-based package is also currently used as part
of the build process for the Axiom Aldor extension written by
Peter Broadbery. I believe that Peter is currently re-writing this
graph package (in Aldor?) so that the Axiom Aldor extensions can
be built as part of the Axiom build without requiring Java. Ralf
Hemmecke and I had previously started work on a graphics package
for Axiom/Aldor but time constraints and other priorities have
resulted in no new progress over the last several months.

Anyway, I think I may have finally stumbled across some open source
graphics software that might be up to the task of visualizing and
manipulating Axiom's dependency graph and it may well also be a
suitable model for developing a native graphics package for Axiom.

https://networkx.lanl.gov/wiki

High productivity software for complex networks

NetworkX (NX) is a Python package for the creation, manipulation,
and study of the structure, dynamics, and functions of complex
networks.

Features:

* Allows for 1M+ nodes, 10M+ edges
* Includes standard graph-theoretic and statistical physics functions
* Easy exchange of network algorithms between applications,
  disciplines, and platforms
* Includes many classic graphs and synthetic networks
* Nodes and edges can be "anything" (e.g. time-series, text,
  images, XML records)
* Exploits existing code from high-quality legacy software in C,
  C++, Fortran, etc.
* Open source (encourages community input)

------------

It is also notable that the Sage developers have chosen to
integrate NetworkX into Sage rather than build their own graphics
package. The Sage Graph Theory project

http://sage-wiki.axiom-developer.org/graph

has produced a very interesting review of open source graphics
programs. See:

http://sage-wiki.axiom-developer.org/graph_survey

If anyone else is interested in discussing the development and
use of a graph theory package for Axiom, I would be very glad
to hear from you.

\start
Date: Thu, 9 Nov 2006 03:18:13 +0100 (CET)
From: Waldek Hebisch
To: Ralf Hemmecke
Subject: Re: Bug?

> Does somebody know what happens here?
> 
> Ralf
> 
> )expose PrimitiveElement
> primitiveElement([x^2-2,x^2-3]$List(Polynomial Fraction Integer),[z2,z3])
> 
>     >> Error detected within library code:
>     (1 . failed) cannot be coerced to mode (OrderedVariableList (z2 z3 %A))
> 
> 

AFAICS x^2-2 and x^2-3 have no common 0, so ideal generated by
the two polynomials is generated by constant 1.  The constant does
not depend on z2 and z3, and Axiom chokes (Axiom definitely needs
better error checking).

BTW.  You probably wanted:

primitiveElement([z2^2-2, z3^2-3], [z2,z3])

which gives me:

                          1  3   19    1  3    9           4      2
   [coef= [- 3,1],poly= [-- ?  - -- ?,-- ?  - -- ?],prim= ?  - 42?  + 225]
                         90      30   30      10
Type: Record(coef: List Integer,poly: List SparseUnivariatePolynomial Fraction Integer,prim: SparseUnivariatePolynomial Fraction Integer)

(I did not check if this is correct, but looks sensible).

\start
Date: 09 Nov 2006 03:48:12 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: LANL NetworkX and algebra dependency graph

Bill Page writes:

| Axiom Developers;
| 
| Over a year ago we were discussing how best to represent Axiom's
| algebra dependency graph. This is a complex problem because Axiom
| has over 1,300 mathematically modules that are tightly integrated
| with each other - even to the point of generating a large number
| cyclical dependency chains in the underlying code. This considerably
| complicates bootstrap process by which Axiom is built and could
| even call into question the fundamental means by which these
| dependency loops are solved in the current build (e.g. It is known
| that just a single iteration of bootstrap -> compile -> bootstrap
| is not sufficient to produce a fixed point solution.)

I believe extending SPAD to understand "extend" (no pun intended)
might help decrease the complexity of the dependency graph to a more
manageable shape.

[...]

| If anyone else is interested in discussing the development and
| use of a graph theory package for Axiom, I would be very glad
| to hear from you.

I'm interested in a graph theory package for Axiom (but I have no
immediate interest in graphics).  I got a copy of "Computational
Discrete Mathematics", by Sriram Pemmaraju and Steven Skiena, to get an
idea of existing work in the area of symbolic computations.  I'm not
done with it yet.

\start
Date: Thu, 09 Nov 2006 06:27:22 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

> | I think what Gaby is suggesting is that aaa.tex would be extracted
> | to some directory other than the current directory, e.g.
> 
> Yes, exactly.

Yep. When Gaby was saying something about "from where latex is called" 
that made me test this situation. You are right. In that way we can 
avoid to rename axiom.sty.pamphlet no matter what naming scheme we agree 
upon. The only problem that remains is srcltx. It works as I have it now 
and I have to investigate how to twist that. But I already have an idea.

\start
Date: Thu, 09 Nov 2006 06:46:39 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: build-improvements and latex

On 11/09/2006 01:53 AM, Gabriel Dos Reis wrote:
> Bill Page writes:
> 
> [...]
> 
> | > > | So "xdvi axiom.sty.pamphlet.dvi" is absolutely no argument.
> | > 
> | > > Unfortunately, for Axiom, that is going to be an argument for
> | > > the short and mi-term.
> | > 
> | > Are you so sure? Where should I branch from for that experiment?
> | > 
> | 
> | Yes a new branch! I strongly encourage you to do that. :-)
> | 
> | I am just a little uncertain of the technical implications for
> | merging later, but I suggest that you clone build-improvements -
> | primarily because I think it represents the best environment in
> | which to experiment with alternate build scripts. It is more
> | modular than Axiom Gold and once you get used to it, autoconf
> | really does make things simpler and easier to understand.
> | 
> | Gaby, what do you think about branching from build-improvements?
> 
> That makes perfect sense to me.  Ralf can sync from build-improvements
> at any time.
> 
> Given recent discussions, I would very much appreciate Tim shime in.

Maybe it doesn't matter to much from where I branch since I intend to do 
the first approximation with my own Makefiles. What I currently have in 
ALLPROSE seems to be in conflict with autoconf (I generate Makefiles and 
things that are included in Makefiles on the fly).

I would be happy to discuss later how this could be integrated with 
build-improvements. But, in fact, it is rather independent of that.
Still though I am currently reading about autoconf and also want to add 
autoconf facilities to ALLPROSE, maybe it is easier for me to learn 
something about autoconf if I branch from build-improvements.

It seems that I am going to have some sleepless nights coming. ;-)

\start
Date: 09 Nov 2006 14:24:52 +0100
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: LANL NetworkX and algebra dependency graph

Gabriel Dos Reis writes:

> | If anyone else is interested in discussing the development and
> | use of a graph theory package for Axiom, I would be very glad
> | to hear from you.
> 
> I'm interested in a graph theory package for Axiom (but I have no immediate
> interest in graphics).  I got a copy of "Computational Discrete Mathematics",
> by Sriram Pemmaraju and Steven Skiena, to get an idea of existing work in the
> area of symbolic computations.  I'm not done with it yet.

I did some thinking about a graph theory package. If anybody is interested, I
can write up what I believe after November 19.

\start
Date: Thu, 9 Nov 2006 09:19:05 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: LANL NetworkX and algebra dependency graph

On November 9, 2006 8:25 AM Martin Rubey wrote:
> 
> > Bill Pag wrote:
> > | If anyone else is interested in discussing the development
> > | and use of a graph theory package for Axiom, I would be
> > | very glad to hear from you.
> >
> ... 
> Gabriel Dos Reis writes:
> > I'm interested in a graph theory package for Axiom (but I 
> > have no immediate interest in graphics).  I got a copy of
> > "Computational Discrete Mathematics", by Sriram Pemmaraju
> > and Steven Skiena, to get an idea of existing work in the
> > area of symbolic computations.  I'm not done with it yet.
> 
> I did some thinking about a graph theory package. If anybody 
> is interested, I can write up what I believe after November
> 19.
> 

Martin, I think it would be great if you could write up something
about a graph theory package for Axiom. I have been watching
with great interest your work on Combinat and I wonder if some
of the same methods would also apply in the more general setting
of Graphs.

I would of cource also be interested in what you believe about
graph theory before November 19. :-)

Is humour based on English ambiguity too obvious?

\start
Date: Thu, 09 Nov 2006 15:56:10 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: LANL NetworkX and algebra dependency graph

>> I did some thinking about a graph theory package. If anybody 
>> is interested, I can write up what I believe after November
>> 19.

> I would of cource also be interested in what you believe about
> graph theory before November 19. :-)
> 
> Is humour based on English ambiguity too obvious?

No. I think that Martin meant that he will write something up today if 
someone is interested. I am interested. ;-)

\start
Date: 09 Nov 2006 16:23:13 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: Graph theory

I'll write something up as soon as possible. But this won't be before
November~19, since I'm under pressure until then.

However, I talked a bit with Ralf about this before the axiom workshop, and
then I think he was more interested in graphs as datastructures, which doesn't
interest me at all.

I'm into Matroids, Simplicial Complexes, Graphs, Digraphs, Polytopes etc. I
have thought only about Categories, not implementations.

But I didn't get very far anyway.

\start
Date: Thu, 9 Nov 2006 12:14:55 -0800
From: Richard Harke
To: list
Subject: build-improvements on ia64

I built gcl manually per suggestion. Based on suggestions
I used the following configure command:

./configure --prefix=/usr/local \
--enable-vssize=65536*2 --enable-maxpage=256*1024 \
--disable-x --disable-xgcl --disable-tkconfig

After installing gcl, I configured Axiom:
./configure --with-gcl

During make, I have problem with bootsys:
make[2]: Entering directory 
`/home/harke/Axiom-svn/build-improvements/src/boot'
Building stage 1
[ -d stage1 ] || ../../config/mkinstalldirs stage1
make OBJECTS="boothdr.o exports.o npextras.o ptyout.o btincl2.o btscan2.o 
typrops.o btpile2.o typars.o tyextra.o tytree1.o" bootsys
make[3]: Entering directory 
`/home/harke/Axiom-svn/build-improvements/src/boot'
echo '(boottran::boottocl "ptyout.boot")' | prev-stage/bootsys
GCL (GNU Common Lisp)  2.6.8 CLtL1    Nov  8 2006 19:12:07
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

>
Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at BOOTTRAN:BOOTTOCL.  Type :H for Help.
>>make[3]: *** [ptyout.clisp] Error 255
make[3]: Leaving directory `/home/harke/Axiom-svn/build-improvements/src/boot'
make[2]: *** [stage1/bootsys] Error 2
make[2]: Leaving directory `/home/harke/Axiom-svn/build-improvements/src/boot'
make[1]: *** [boot/stamp] Error 2
make[1]: Leaving directory `/home/harke/Axiom-svn/build-improvements/src'
make: *** [all-recursive] Error 1

I have been doing a make clean between attempts but I think
some file times don't reflect this. I tried make dist-clean but
didn't work. What is the best way to reset?

\start
Date: Thu, 9 Nov 2006 15:47:00 -0500
From: Bill Page
To: Richard Harke
Subject: RE: build-improvements on ia64

On November 9, 2006 3:15 PM Richard Harke wrote:
> 
> I built gcl manually per suggestion. Based on suggestions
> I used the following configure command:
> 
> ./configure --prefix=/usr/local \
> --enable-vssize=65536*2 --enable-maxpage=256*1024 \
> --disable-x --disable-xgcl --disable-tkconfig
>

Good.
 
> After installing gcl, I configured Axiom:
> ./configure --with-gcl
> 
> During make, I have problem with bootsys:
> make[2]: Entering directory 
> `/home/harke/Axiom-svn/build-improvements/src/boot'
> Building stage 1
> [ -d stage1 ] || ../../config/mkinstalldirs stage1
> make OBJECTS="boothdr.o exports.o npextras.o ptyout.o 
> btincl2.o btscan2.o 
> typrops.o btpile2.o typars.o tyextra.o tytree1.o" bootsys
> make[3]: Entering directory 
> `/home/harke/Axiom-svn/build-improvements/src/boot'
> echo '(boottran::boottocl "ptyout.boot")' | prev-stage/bootsys
> GCL (GNU Common Lisp)  2.6.8 CLtL1    Nov  8 2006 19:12:07
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (UNEXEC)
> Modifications of this banner must retain notice of a 
> compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> Temporary directory for compiler files set to /tmp/
> 
> >
> Error: Caught fatal error [memory may be damaged]

If this problem persists after re-building with a fresh copy of
the Axiom source (see below), it might be a bit hard to diagnose
with only the information above. :-) My first suggestion is to
look for the possibility of another error somewhere earlier in
the build.

Since this looks like the error occurred quite early in the Axiom
build process, the problem might be a gcl problem so it would
also probably be worthwhile to double check the log of the gcl
build. You could try also some simple confidence tests of gcl's
ability to save a working system such as:

  $ gcl
  > (+ 1 1)
  > (si::save-system "gcl-test1")

  $ ./gcl-test1
  > (+ 1 1)
  > (compiler::link nil "gcl-test2")
  > (quit)

  $ ./gcl-test2
  > (+ 1 1)
  > (quit)

If you get stuck, it might be useful if you could make a copy of
the console log available for review.

> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVAL.
> Broken at BOOTTRAN:BOOTTOCL.  Type :H for Help.
> >>make[3]: *** [ptyout.clisp] Error 255
> make[3]: Leaving directory 
> `/home/harke/Axiom-svn/build-improvements/src/boot'
> make[2]: *** [stage1/bootsys] Error 2
> make[2]: Leaving directory 
> `/home/harke/Axiom-svn/build-improvements/src/boot'
> make[1]: *** [boot/stamp] Error 2
> make[1]: Leaving directory 
> `/home/harke/Axiom-svn/build-improvements/src'
> make: *** [all-recursive] Error 1
> 

> I have been doing a make clean between attempts but I think
> some file times don't reflect this. I tried make dist-clean but
> didn't work. What is the best way to reset?
> 

I recommend that you do an "out of source" build. This means
that Axiom is built in a different directory then where the
source distribution exists.

To do this, first use svn to check-out a clean copy of the
Axiom source to some directory, e.g. ~/axiom.improvements.
After that you will not change anything in that directory.
Instead, create a 2nd directory, e.g.

  $ mkdir ~/axiom.build
  $ cd ~/axiom.build
  $ ../axiom.improvements/configure --with-gcl

This will setup the ~/axiom.build directory with just the
subdirectories and makefiles needed for the build. Then

  $ make

builds all of the axiom intermediate files and the final target
in this 2nd directory.

If the build fails and you want to start entirely from scratch
then just delete the contents of this directory and issue the
configure command again:

  $ rm -rf *
  $ ../axiom.improvements/configure --with-gcl

\start
Date: Thu, 09 Nov 2006 22:12:04 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: build-improvements on ia64

> I recommend that you do an "out of source" build. This means
> that Axiom is built in a different directory then where the
> source distribution exists.
> 
> To do this, first use svn to check-out a clean copy of the
> Axiom source to some directory, e.g. ~/axiom.improvements.
> After that you will not change anything in that directory.
> Instead, create a 2nd directory, e.g.
> 
>   $ mkdir ~/axiom.build
>   $ cd ~/axiom.build
>   $ ../axiom.improvements/configure --with-gcl
> 
> This will setup the ~/axiom.build directory with just the
> subdirectories and makefiles needed for the build. Then
> 
>   $ make
> 
> builds all of the axiom intermediate files and the final target
> in this 2nd directory.
> 
> If the build fails and you want to start entirely from scratch
> then just delete the contents of this directory and issue the
> configure command again:
> 
>   $ rm -rf *
>   $ ../axiom.improvements/configure --with-gcl

Maybe that should go to the wiki. BuildAxiom perhaps? (That page seems 
to be out of date somehow.)

\start
Date: 09 Nov 2006 22:23:16 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: build-improvements on ia64

Ralf Hemmecke writes:

| > I recommend that you do an "out of source" build. This means
| > that Axiom is built in a different directory then where the
| > source distribution exists.
| > To do this, first use svn to check-out a clean copy of the
| > Axiom source to some directory, e.g. ~/axiom.improvements.
| > After that you will not change anything in that directory.
| > Instead, create a 2nd directory, e.g.
| >   $ mkdir ~/axiom.build
| >   $ cd ~/axiom.build
| >   $ ../axiom.improvements/configure --with-gcl
| > This will setup the ~/axiom.build directory with just the
| > subdirectories and makefiles needed for the build. Then
| >   $ make
| > builds all of the axiom intermediate files and the final target
| > in this 2nd directory.
| > If the build fails and you want to start entirely from scratch
| > then just delete the contents of this directory and issue the
| > configure command again:
| >   $ rm -rf *
| >   $ ../axiom.improvements/configure --with-gcl
| 
| Maybe that should go to the wiki. BuildAxiom perhaps? (That page seems
| to be out of date somehow.)

I hope to make the future entry unnecessary.  Academic deadlines took
precedence over Axiom plans, so...

I'm testing Waldek and Humberto's patch to allow build on MAC OS.
Then, I'll look into some of the Makefile bugs (hopefully, there
should be very few).

I very much appreciate the number of testings, interest and feddback
going into the build-improvements.  That pressure helps keep me up :-)

\start
Date: 10 Nov 2006 01:46:50 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: viewman and hyper on Mac OS X

Waldek Hebisch writes:

| Humberto Ortiz-Zuazaga wrote:
| > and viewman now compiles. Next problem is hyper, the Mac doesn't have
| > regexp.h:
| > 
| 
| > Hyper still fails to build:
| > 
| > 13 making /Users/humberto/src/axiom-darcs/src/hyper
| > gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DMACOSXplatform
| >       -I/usr/include -I/usr/include/sys
| > -I/Users/humberto/src/axiom-darcs/src/include -I. -I/usr/X11R6/include
| >   -c -o hthits.o hthits.c
| > hthits.c: In function 'main':
| > hthits.c:121: warning: implicit declaration of function 'compile'
| 
| The patch below converts hthits to use 'regexp.h'.  The <sys/types.h>
| include is correct on Linux, but may need adjustment on Mac.

hthits already includes <sys/types.h>.  Is there any reason why you
would include it a second time?

\start
Date: Thu, 9 Nov 2006 19:37:11 -0600 (CST)
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

On Mon, 6 Nov 2006, Humberto Ortiz-Zuazaga wrote:

| Gabriel Dos Reis wrote:
|
| > While composing this message, I fired the upgrade to the most recent
| > GCL-2.6.8pre.  Do you see any other patches that I may have forgotten
| > that should go into build-improvements?
|
| I still can't pull the svn source on the Mac, so I pulled on a linux box
| and copied them over to the Mac this morning.
|
| I have built axiom again. I needed to patch 2 files:
|
| 1) src/hyper/hthits.pamphlet, using Waldek's patch:
|
| http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00195.html
|
| and
|
| 2) $ svn diff src/graph/viewman/viewman.c.pamphlet
| Index: src/graph/viewman/viewman.c.pamphlet
| ===================================================================
| --- src/graph/viewman/viewman.c.pamphlet        (revision 252)
| +++ src/graph/viewman/viewman.c.pamphlet        (working copy)
| @@ -116,7 +116,7 @@
|    int keepLooking,code;
|
|    bsdSignal(SIGPIPE,brokenPipe,DontRestartSystemCalls);
| -#if defined(BSDplatform)
| +#if defined(BSDplatform) || defined (MACOSXplatform)
|    bsdSignal(SIGCHLD,endChild,RestartSystemCalls);
|  #else
|    bsdSignal(SIGCLD,endChild,RestartSystemCalls);


Humberto --

  Thanks for your patience.  I'm testing the patch below.  I'll commit
it once build and test completed.

-- Gaby

2006-11-09  Gabriel Dos Reis  Gabriel Dos Reis

 	* configure.ac.pamphlet (\subsection{C headers}): New.  Check for
	<regex.h>.  Document that the macros XXXplatform should be removed.
	* configure.ac: Regenerate.
	* configure: Likewise.

src/hyper/
2006-11-09  Waldek Hebisch  Waldek Hebisch
	    Gabriel Dos Reis  Gabriel Dos Reis

	* hthits.pamphlet: Remove use of <regexp.h>, and required C
	preprocessor macro interface.  Explain why.
	(searchPage): Update.

src/graph/viewman/
2006-11-09  Humberto Zuazaga

	* viewman.c.pamphlet (main): Use SIGHLD on MAC OS X too.

*** configure.ac.pamphlet	(revision 16865)
--- configure.ac.pamphlet	(local)
*************** AC_SUBST(LISP)
*** 521,526 ****
--- 521,532 ----
  AC_SUBST(GCLOPTS)
  @

+ The C preprocessor symbols [[BSDplatform]], [[LINUXplatform]], etc. are being
+ used as ``catch all'' for unstructured codes.  They should be
+ removed from the source base.  Any source file using those should be
+ properly documented as its needs are, and a narrowed, specific configure
+ test should be added.
+

  \subsubsection{The [[SRC_SUBDIRS]] variable}
  The [[SRC_SUBDIRS]] variable is used in the [[src/Makefile.pamphlet]]
*************** AC_SUBST(X_PRE_LIBS)
*** 619,624 ****
--- 625,642 ----
  @


+ \subsection{C headers}
+
+ \subsubsection{Regex}
+
+ We need string pattern matching.  We require [[<regex.h>]] from POSIX
+ definition, as we assume that the host is sufficiently POSIX conformant
+ enough for our needs.
+ <<headers>>=
+ AC_CHECK_HEADER([regex.h], [], [AC_MSG_ERROR([Axiom needs <regex.h>])])
+ @
+
+

  \section{A note about comments}
  \label{sec:comment}
*************** poor masochist who will be debugging the
*** 658,663 ****
--- 676,683 ----

  <<build utils>>

+ <<headers>>
+
  <<locate X11>>

  <<define AXIOM>>

*** src/graph/viewman/viewman.c.pamphlet	(revision 16865)
--- src/graph/viewman/viewman.c.pamphlet	(local)
*************** main (void)
*** 116,122 ****
    int keepLooking,code;

    bsdSignal(SIGPIPE,brokenPipe,DontRestartSystemCalls);
! #if defined(BSDplatform)
    bsdSignal(SIGCHLD,endChild,RestartSystemCalls);
  #else
    bsdSignal(SIGCLD,endChild,RestartSystemCalls);
--- 116,122 ----
    int keepLooking,code;

    bsdSignal(SIGPIPE,brokenPipe,DontRestartSystemCalls);
! #if defined(BSDplatform) || defined (MACOSXplatform)
    bsdSignal(SIGCHLD,endChild,RestartSystemCalls);
  #else
    bsdSignal(SIGCLD,endChild,RestartSystemCalls);

*** src/hyper/hthits.pamphlet	(revision 16865)
--- src/hyper/hthits.pamphlet	(local)
***************
*** 1,15 ****
  \documentclass{article}
  \usepackage{axiom}
! \begin{document}
  \title{\$SPAD/src/hthits}
  \author{The Axiom Team}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
  \section{hthits.c}
  <<hthits.c>>=
  /*
   * hthits pattern htdb-file
--- 1,33 ----
  \documentclass{article}
  \usepackage{axiom}
!
  \title{\$SPAD/src/hthits}
  \author{The Axiom Team}
+
+ \begin{document}
  \maketitle
+
  \begin{abstract}
  \end{abstract}
  \eject
+
  \tableofcontents
  \eject
+
  \section{hthits.c}
+
+ This source file implements HyperDoc's ability to scan files for a
+ given pattern.  For that purpose it needs a ``regex'' for string
+ pattern matching.
+
+ This source file used to rely on [[<regexp.h>]],
+ which was originally part of the X/Open System Interface and Headers
+ Issue 2.  However, since then, it has been withdrawn and no longer
+ always available on newer platfroms.  Consequently,
+ we need to use a different, portable regex library.  The POSIX
+ definition provides one, namely through [[<regex.h>]].  That is what we
+ use now.  Its availability is tested at configure time.
+
  <<hthits.c>>=
  /*
   * hthits pattern htdb-file
*************** typedef struct pgInfo {
*** 53,77 ****

  #include "hthits.H1"

!
!
! /*
!  * Things for the regular expression scanning.
!  */
! char expbuf[MAX_COMP_REGEX];
!
! #define INIT      register char *sp = instring;
! #define GETC()    (*sp++)
! #define PEEKC()   (*sp)
! #define UNGETC(c) (--sp)
! #define RETURN(c) return(c);
! #define ERROR(c)  regerr(c);
!
! #if defined(RIOSplatform) && !defined(_AIX41) && defined(_XOPEN_SOURCE)
! /* AIX3 regexp.h includes NLregexp which we don't want */
! #undef _XOPEN_SOURCE
! #endif
! # include <regexp.h>

  /*
   * Global variables set according to the command line.
--- 71,78 ----

  #include "hthits.H1"

! #include <sys/types.h>
! #include <regex.h>

  /*
   * Global variables set according to the command line.
*************** char *progName;
*** 81,86 ****
--- 82,88 ----
  char *pattern;
  char *htdbFName;
  int gverifydates=0;
+ regex_t reg_pattern;

  int
  #ifdef _NO_PROTO
*************** main(int argc,char ** argv)
*** 93,99 ****
  {
      cmdline(argc, argv);

!     compile(pattern, expbuf, expbuf + MAX_COMP_REGEX, '\0');

      handleHtdb();
      return(0);
--- 95,101 ----
  {
      cmdline(argc, argv);

!     regcomp(&reg_pattern, pattern, REG_NEWLINE);

      handleHtdb();
      return(0);
*************** searchPage(char *pgname,char * pgtitle,c
*** 335,347 ****
  #endif
  {
      char *bodyrest;
      int nhits = 0;

!     if (step(pgtitle, expbuf))
          nhits++;

!     for (bodyrest = pgbody; step(bodyrest, expbuf); bodyrest = loc2)
          nhits++;
      if (nhits) {
          printf("\\newsearchresultentry{%d}{%s}",nhits, pgtitle);
          squirt(pgname, strlen(pgname));
--- 337,353 ----
  #endif
  {
      char *bodyrest;
+     regmatch_t match_pos;
      int nhits = 0;

!     if (!regexec(&reg_pattern, pgtitle, 1, &match_pos, 0))
          nhits++;

!     bodyrest = pgbody;
!     while (!regexec(&reg_pattern, bodyrest, 1, &match_pos, 0)) {
          nhits++;
+         bodyrest += match_pos.rm_eo;
+     }
      if (nhits) {
          printf("\\newsearchresultentry{%d}{%s}",nhits, pgtitle);
          squirt(pgname, strlen(pgname));


\start
Date: Thu, 9 Nov 2006 19:47:17 -0600 (CST)
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

On Mon, 6 Nov 2006, Humberto Ortiz-Zuazaga wrote:

| I built --without-noweb --with-gcl, the configure for the built in gcl
| isn't working right. I think it's a bug in gcl-2.6.8pre (if you call
| configure with no --prefix, the make tries to echo data into /bin/gcl
| and fails with permission problems).

Camm --

  Did you had a chance to look into this?

\start
Date: Fri, 10 Nov 2006 03:04:29 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: viewman and hyper on Mac OS X

> Waldek Hebisch writes:
> 
> | Humberto Ortiz-Zuazaga wrote:
> | > and viewman now compiles. Next problem is hyper, the Mac doesn't have
> | > regexp.h:
> | > 
> | 
> | > Hyper still fails to build:
> | > 
> | > 13 making /Users/humberto/src/axiom-darcs/src/hyper
> | > gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DMACOSXplatform
> | >       -I/usr/include -I/usr/include/sys
> | > -I/Users/humberto/src/axiom-darcs/src/include -I. -I/usr/X11R6/include
> | >   -c -o hthits.o hthits.c
> | > hthits.c: In function 'main':
> | > hthits.c:121: warning: implicit declaration of function 'compile'
> | 
> | The patch below converts hthits to use 'regexp.h'.  The <sys/types.h>
> | include is correct on Linux, but may need adjustment on Mac.
Gabriel Dos Reis wrote:
> 
> hthits already includes <sys/types.h>.  Is there any reason why you
> would include it a second time?
> 

Just overlooked that <sys/types.h> is already included...

\start
Date: Thu, 09 Nov 2006 22:09:12 -0400
From: Humberto Zuazaga
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

Gabriel Dos Reis wrote:
> On Mon, 6 Nov 2006, Humberto Ortiz-Zuazaga wrote:
> 
> | I built --without-noweb --with-gcl, the configure for the built in gcl
> | isn't working right. I think it's a bug in gcl-2.6.8pre (if you call
> | configure with no --prefix, the make tries to echo data into /bin/gcl
> | and fails with permission problems).
> 
> Camm --
> 
>   Did you had a chance to look into this?
> 
> -- Gaby

I think it's more like you need to run configure after a make clean, 
even if you don't specify any prefix it will work, but

make clean; make

fails with the permission problem on /bin/gcl (I think a GCLDIR 
configuration variable is being blown away). I'm sorry I haven't had the 
time to fix this yet.

\start
Date: Fri, 10 Nov 2006 18:01:26 +0100
From: Vanuxem =?ISO-8859-1?Q?Gr=E9gory?= Gregory Vanuxem
To: list
Subject: presea and htsearch

Hello,


The chunk/file presea (in src/hyper/search.pamphlet) contains
'#!/bin/awk -f' which does not work on my Debian system (awk is
under /usr/bin). I know that there is a variable for awk, so maybe this
can help.

Always in src/hyper/search.pamphlet, the chunk/file htsearch uses
'sort ... +number ...' which issues a warning on my system :
sort: Warning: "+number" syntax is deprecated, please use "-k number"

You can reproduce these issues when you click, in Hyperdoc, the
hyperlink browse->reference.

Greg

PS : I will report these issues on IssueTracker.

\start
Date: Fri, 10 Nov 2006 18:41:09 +0100
From: Gregory Vanuxem
To: list
Subject: Experimental support of the mouse wheel in Hyperdoc

Hello,

For those who are fed up to click on arrow keys in Hyperdoc (I'm) here
is patch against Hyperdoc. This patch is for personal use and is not
documented (I know nothing about the X libraries). It adds support of
the mouse wheel (dirty hack !!!).

I insist, this patch is experimental, I just coded it in 30 minutes.
Comments and critics are welcome of course.

Greg

PS : Next thing, allow to type text when NumLock is enabled, but I will
probably not do it in the near future.

--=-vu++/Vl0doFYLVSdjLuK

diff -Naur /home/greg/TDevel/cvs/axiom/src/hyper/event.pamphlet ./event.pamphlet
--- /home/greg/TDevel/cvs/axiom/src/hyper/event.pamphlet	2005-01-30 12:49:54.000000000 +0100
+++ ./event.pamphlet	2006-11-10 17:36:45.000000000 +0100
@@ -659,6 +666,19 @@
     HyperDocPage *page = NULL;
     char *page_name;
 
+
+    if (event->window == gWindow->fMainWindow || 
+        event->window == gWindow->fScrollWindow) {
+      if(button == 4){
+        scrollUp();
+        return;
+      }
+      else if (button == 5){
+        scrollDown();
+        return;
+      }
+    }
+
     /* find page name from sub-window handle */
 
     link = get_hyper_link(event);

\start
Date: 10 Nov 2006 19:08:13 +0100
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: presea and htsearch

Vanuxem Gr=E9gory Gregory Vanuxem writes:

| Hello,
|
|
| The chunk/file presea (in src/hyper/search.pamphlet) contains
| '#!/bin/awk -f' which does not work on my Debian system (awk is
| under /usr/bin). I know that there is a variable for awk, so maybe this
| can help.

Yes, we can ask Autoconf to give use the full path to the AWK executable.

| Always in src/hyper/search.pamphlet, the chunk/file htsearch uses
| 'sort ... +number ...' which issues a warning on my system :
| sort: Warning: "+number" syntax is deprecated, please use "-k number"

OK.

\start
Date: Fri, 10 Nov 2006 19:29:50 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: build un-portability

Looking at document script I noticed that it normally uses unquoted
values, which may cause trouble with embedded spaces.  So I decided
to try building axiom in a directory which contained space in its
name. Configure worked nice, but build failed immediatly...

\start
Date: Fri, 10 Nov 2006 19:34:30 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: presea and htsearch

> Always in src/hyper/search.pamphlet, the chunk/file htsearch uses
> 'sort ... +number ...' which issues a warning on my system :
> sort: Warning: "+number" syntax is deprecated, please use "-k number"
> 

The following removes the warning.  OTOH I am not sure if all our
potential targets support '-k' option to sort.

diff -u build-improvements.bb/src/hyper/search.pamphlet build-improvements/src/hyper/search.pamphlet
--- build-improvements.bb/src/hyper/search.pamphlet	2006-11-05 23:55:40.000000000 +0100
+++ build-improvements/src/hyper/search.pamphlet	2006-11-10 18:51:14.000000000 +0100
@@ -26,7 +26,7 @@
 then 
 	echo ""|$htbindir/presea case=1 -
 else
-( cd $htpagedir; $htbindir/hthits "$1" $htpagedir/ht.db |sort -r -n +0.22 |$htbindir/presea case=0 expr="$1" -)
+( cd $htpagedir; $htbindir/hthits "$1" $htpagedir/ht.db |sort -r -n -k 1.22 |$htbindir/presea case=0 expr="$1" -)
 fi
 @ 
 <<presea>>=

\start
Date: Fri, 10 Nov 2006 10:52:41 -0800
From: Richard Harke
To: list
Subject: Re: build-improvements on ia64

On Thu November 9 2006 12:47, Bill Page wrote:
> If this problem persists after re-building with a fresh copy of
> the Axiom source (see below), it might be a bit hard to diagnose
> with only the information above. :-) My first suggestion is to
> look for the possibility of another error somewhere earlier in
> the build.
>
> Since this looks like the error occurred quite early in the Axiom
> build process, the problem might be a gcl problem so it would
> also probably be worthwhile to double check the log of the gcl
> build. You could try also some simple confidence tests of gcl's
> ability to save a working system such as:
>
>   $ gcl
>
>   > (+ 1 1)
>   > (si::save-system "gcl-test1")
>
>   $ ./gcl-test1
>
>   > (+ 1 1)
>   > (compiler::link nil "gcl-test2")
>   > (quit)
>
>   $ ./gcl-test2
>
>   > (+ 1 1)
>   > (quit)
>
> If you get stuck, it might be useful if you could make a copy of
> the console log available for review.
>
>
> I recommend that you do an "out of source" build. This means
> that Axiom is built in a different directory then where the
> source distribution exists.
>
> To do this, first use svn to check-out a clean copy of the
> Axiom source to some directory, e.g. ~/axiom.improvements.
> After that you will not change anything in that directory.
> Instead, create a 2nd directory, e.g.
>
>   $ mkdir ~/axiom.build
>   $ cd ~/axiom.build
>   $ ../axiom.improvements/configure --with-gcl
>
> This will setup the ~/axiom.build directory with just the
> subdirectories and makefiles needed for the build. Then
>
>   $ make
>
> builds all of the axiom intermediate files and the final target
> in this 2nd directory.
>
> If the build fails and you want to start entirely from scratch
> then just delete the contents of this directory and issue the
> configure command again:
>
>   $ rm -rf *
>   $ ../axiom.improvements/configure --with-gcl
>
> Regards,
> Bill Page.
Thanks. This was very helpful. I still have the problem, however.
I agree it appears to be a gcl problem. I didn't see any thing in the
gcl build log and the save-system and compiler::link tests
given above both appeared to work fine. I did try to run this manually:

harke@hestenes:~/Axiom-svn/build/src/boot$ stage0/bootsys
GCL (GNU Common Lisp)  2.6.8 CLtL1    Nov  9 2006 23:01:51
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

>(boottran::boottocl "ptyout.boot")

Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at BOOTTRAN:BOOTTOCL.  Type :H for Help.
>>:bt

#0   BOOTTOCL {loc0="ptyout.boot"} [ihs=7]
#1   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function 
boottran:boottocl>} [ihs=6]
#2   TOP-LEVEL 
{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7="/usr/local/lib...} 
[ihs=5]
#3   FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
NIL
>>:env

Error: bad env
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LAMBDA-CLOSURE.
Backtrace: system:universal-error-handler > system::break-call > funcall > 
funcall > lambda-closure > SYSTEM::DESCRIBE-ENVIRONMENT

Broken at BOOTTRAN:BOOTTOCL.


I did make a feeble attempt to provide more info with :bt and :env
I would like to debug this but my knowledge of lisp is pretty limited.
My knowledge of ia64 is much better.

I also tried to do (si:use-fast-links nil) but that gets segfault
Alos, if I just try gdb stage0/bootsys when I give run, it crashes
(sgfault)

\start
Date: 10 Nov 2006 20:06:38 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: build un-portability

Waldek Hebisch writes:

| Looking at document script I noticed that it normally uses unquoted
| values, which may cause trouble with embedded spaces.  So I decided
| to try building axiom in a directory which contained space in its
| name. Configure worked nice, but build failed immediatly...

>From my experience, pathnames with embedded space always cause
problems for Unix-based tools.  I'm not worried about them at the
moment, e.g. they are very low priority on my list of things to do in
build-improvements. 

\start
Date: Fri, 10 Nov 2006 20:22:51 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: Re: presea and htsearch

On 11/10/2006 07:34 PM, Waldek Hebisch wrote:
> The following removes the warning.  OTOH I am not sure if all our
> potential targets support '-k' option to sort.

Interesting, somebody knows about our potential targets. Where are they 
listed? Isn't that relevant of how portable Axiom should become? I would 
actually like to see two lists.

1) Where does Axiom currently compile and/or run?
2) Where should Axiom compile and/or run? (Future plans)

\start
Date: 10 Nov 2006 20:46:09 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: presea and htsearch

Ralf Hemmecke writes:

| On 11/10/2006 07:34 PM, Waldek Hebisch wrote:
| > The following removes the warning.  OTOH I am not sure if all our
| > potential targets support '-k' option to sort.
| 
| Interesting, somebody knows about our potential targets. Where are
| they listed? Isn't that relevant of how portable Axiom should become?

I would like to see Axiom run (ideally) wherever GCC runs,
e.g. desktops, laptops, etc.  I do not insist on 16K memory machines
though :-)

\start
Date: Fri, 10 Nov 2006 22:27:22 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: presea and htsearch

> | Interesting, somebody knows about our potential targets. Where are
> | they listed? Isn't that relevant of how portable Axiom should become?
> 
> I would like to see Axiom run (ideally) wherever GCC runs,
> e.g. desktops, laptops, etc.  I do not insist on 16K memory machines
> though :-)

Do you have a link to a list of systems for GCC?

OK. But there were actually two questions (if not more). Or do you mean 
by "run" also "compile" on these machines?

Maybe it is much too early in the current development process to think 
about it, but I have the feeling that for the end-user it is not so much 
important that he can actually build Axion on his system from scratch.

It would be of course a feature (or a must) that people can extend an 
already running Axiom. But I guess some people will never extend Axiom 
but rather be happy with .input files. That all says something about how 
powerful the machine must be to do certain things. Clearly, "running on 
some system" and "compiling on some system" is not the same thing.

\start
Date: 10 Nov 2006 22:50:03 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: presea and htsearch

Ralf Hemmecke writes:

| > | Interesting, somebody knows about our potential targets. Where are
| > | they listed? Isn't that relevant of how portable Axiom should become?
| > I would like to see Axiom run (ideally) wherever GCC runs,
| > e.g. desktops, laptops, etc.  I do not insist on 16K memory machines
| > though :-)
| 
| Do you have a link to a list of systems for GCC?

The list of *known reports* (which is not the same as supported) is here:
 
  http://gcc.gnu.org/buildstat.html


| OK. But there were actually two questions (if not more). Or do you
| mean by "run" also "compile" on these machines?

I mean run, then compile.

| Maybe it is much too early in the current development process to think
| about it, but I have the feeling that for the end-user it is not so
| much important that he can actually build Axion on his system from
| scratch.

I would like to see Axiom support native build for a wide range of
machines in use.  I would hate to build a system that second-guess
what users want to do with it.  I've come to be very suspcious of the
distinction "user" and "developer".

\start
Date: Fri, 10 Nov 2006 18:24:02 -0500
From: Alfredo Portes
To: Ralf Hemmecke
Subject: Re: presea and htsearch

Ralf,

> OK. But there were actually two questions (if not more). Or do you mean
> by "run" also "compile" on these machines?

Tim suggested creating a table with the different platforms and
binaries. This will make it easier for the end user:

http://wiki.axiom-developer.org/SandBoxDoyen

Bill created the table, and probably later this will become the
http://wiki.axiom-developer.org/AxiomBinaries page.

If anybody wants to add a platform or a binary, please free to do so.

\start
Date: Sat, 11 Nov 2006 00:38:57 +0100
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: presea and htsearch

Le vendredi 10 novembre 2006 =E0 22:50 +0100, Gabriel Dos Reis a =E9crit =
:
> Ralf Hemmecke writes:
>
> | > | Interesting, somebody knows about our potential targets. Where ar=
e
> | > | they listed? Isn't that relevant of how portable Axiom should bec=
ome?
> | > I would like to see Axiom run (ideally) wherever GCC runs,
> | > e.g. desktops, laptops, etc.  I do not insist on 16K memory machine=
s
> | > though :-)
> |
> | Do you have a link to a list of systems for GCC?
>
> The list of *known reports* (which is not the same as supported) is her=
e:
> 
>   http://gcc.gnu.org/buildstat.html
>
>
> | OK. But there were actually two questions (if not more). Or do you
> | mean by "run" also "compile" on these machines?
>
> I mean run, then compile.

I extend this to object code (architecture dependant binary format (to
be opposed to what is called bytecode)).

Just my thought.

\start
Date: Fri, 10 Nov 2006 18:16:01 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Final Stix font license is now available

Just in case anyone else is interested, the STIX font project
(comprehensive set of freely available math fonts) has released the
final form of their license: http://stixfonts.org/user_license.html and
is targeting beta availability of the fonts in December.  Very good
news.  I find the license a bit confusing at first glance but at least
it is progress!

\start
Date: Fri, 10 Nov 2006 21:27:32 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: build un-portability

On November 10, 2006 2:07 PM you wrote:
> 
> Waldek Hebisch writes:
> 
> | Looking at document script I noticed that it normally uses
> | unquoted values, which may cause trouble with embedded
> | spaces. So I decided to try building axiom in a directory
> | which contained space in its name. Configure worked nice,
> | but build failed immediatly...
> 
> From my experience, pathnames with embedded space always
> cause problems for Unix-based tools.  I'm not worried about
> them at the moment, e.g. they are very low priority on my
> list of things to do in build-improvements. 
> 

I am afraid that you have also just stated the reason why
embedded space in file names always cause problems for unix
based tools - because the developers give this a very low
priority. But it is a serious issue when porting to both
Windows and MAC where spaces in file names are common. At
very least we should try not to write code that we know is
not portable.

Speaking of your "list of things to do in buid-improvments":
Have you already or are you planning to publish this list?
Since build-improvements has become very important to the
future of Axiom (at least in my opinion), I think it would
be good to have such a list so that we can see just how
close or how far away completion of this branch is. It might
also help other people who are working on build-improvements
to more efficiently contribute to the progress.

\start
Date: Fri, 10 Nov 2006 22:00:37 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: Graph theory

On November 9, 2006 10:23 AM Martin Rubey wrote:
> 
> I'll write something up as soon as possible. But this won't be
> before November~19, since I'm under pressure until then.

Ok.

> 
> However, I talked a bit with Ralf about this before the axiom 
> workshop, and then I think he was more interested in graphs as 
> datastructures, which doesn't interest me at all.
> 
> I'm into Matroids, Simplicial Complexes, Graphs, Digraphs, 
> Polytopes etc. I have thought only about Categories, not
> implementations.

I think one of the neat things about Axiom is that it is usually
not necessary or even desirable to make a distinction between
data structures and mathematical structures. Data structures are
just another kind of "mathematical" object.

For example, is an Axiom set, i.e. a member of the domain Set, a
data structure or a mathematical structure? Should we call the
domain Set a mathematical structure or only the category SetCategory
to which it belongs? And of course not everything that we would
like to call a set in Axiom is finite.

Essentially the only requirement of SetCategory is that the domain
has equality and inequality.

I think a Graph in Axiom has to be something nearly as fundamental
as a Set.

\start
Date: 11 Nov 2006 04:23:23 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build un-portability

Bill Page writes:

| Gaby,
| 
| On November 10, 2006 2:07 PM you wrote:
| > 
| > Waldek Hebisch writes:
| > 
| > | Looking at document script I noticed that it normally uses
| > | unquoted values, which may cause trouble with embedded
| > | spaces. So I decided to try building axiom in a directory
| > | which contained space in its name. Configure worked nice,
| > | but build failed immediatly...
| > 
| > From my experience, pathnames with embedded space always
| > cause problems for Unix-based tools.  I'm not worried about
| > them at the moment, e.g. they are very low priority on my
| > list of things to do in build-improvements. 
| > 
| 
| I am afraid that you have also just stated the reason why
| embedded space in file names always cause problems for unix
| based tools - because the developers give this a very low
| priority. But it is a serious issue when porting to both
| Windows and MAC where spaces in file names are common. At
| very least we should try not to write code that we know is
| not portable.

In this particular case, I suspect that Axiom will be best built under
Cygwin or variants where Unix convertion is quite dominant (I know you
can use the Windows style, but very often they cause troubles).  And
it is just easy to fix the environment.  In this particular case.  I'm
not saying Axiom should not support them.  I'm saying it really has
low priority on lis of things to do.  From experience, I know that for
GCC we had people trying to build GCC with embedded colons.  That was
a pain in the ass and usually led to obscure codes.  
My personal opinion is that the codes should not be obscured just to
support exotic stuff.  YMMV.

| Speaking of your "list of things to do in buid-improvments":
| Have you already or are you planning to publish this list?

I suspect a good part of it is in README.build-improvements.  The rest
keeps poping when I try different ideas in different local trees.
I'll upate README.build-improvements.  Some of them are not really
related to build machinery.

\start
Date: Fri, 10 Nov 2006 22:48:23 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: build un-portability

On November 10, 2006 10:23 PM Gaby wrote:
> ...
> Bill Page wrote: 
> | I am afraid that you have also just stated the reason why
> | embedded space in file names always cause problems for unix
> | based tools - because the developers give this a very low
> | priority. But it is a serious issue when porting to both
> | Windows and MAC where spaces in file names are common. At
> | very least we should try not to write code that we know is
> | not portable.
> 
> In this particular case, I suspect that Axiom will be best built
> under Cygwin or variants where Unix convertion is quite dominant
> (I know you can use the Windows style, but very often they cause
> troubles).

Well, at the moment Axiom can not be built under Cygwin because
GCL cannot be built under Cygwin. Maybe someday we will find
someone who wants to solve the problems of building GCL under
Cygwin...

On Windows GCL and Axiom (only AXIOMsys) are currently built under
MSYS/MinGW which provides a native Windows environment without
conversion. File name with spaces are suppored but some of the
unix-specific system commands on which Axiom depends (e.g. 'rm'
and 'cat'), another source of un-portability, have to be emulated
in such a way as to parse blanks in a non-standard way.

> And it is just easy to fix the environment.

I am not sure what you mean "fix the environment". Do you mean
target only linux-based systems for Axiom?

> In this particular case.  I'm not saying Axiom should not
> support them.  I'm saying it really has low priority on list
> of things to do.

Ok.

> From experience, I know that for GCC we had people trying to
> build GCC with embedded colons.  That was a pain in the ass
> and usually led to obscure codes.  My personal opinion is that
> the codes should not be obscured just to support exotic stuff.
> YMMV.

I suppose, but I suspect that the codes would not have been
so obscured if the original code had not made unnecessary
assumptions about the character set from which file names are
composed.

> 
> | Speaking of your "list of things to do in buid-improvments":
> | Have you already or are you planning to publish this list?
> 
> I suspect a good part of it is in README.build-improvements.
> The rest keeps poping when I try different ideas in different
> local trees. I'll upate README.build-improvements.  Some of
> them are not really related to build machinery.
> 

After you update README.build-improvements, I would like to
publish it on the Axiom Wiki. Ok?

\start
Date: 11 Nov 2006 14:22:26 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build un-portability

Bill Page writes:

| On November 10, 2006 10:23 PM Gaby wrote:
| > ...
| > Bill Page wrote: 
| > | I am afraid that you have also just stated the reason why
| > | embedded space in file names always cause problems for unix
| > | based tools - because the developers give this a very low
| > | priority. But it is a serious issue when porting to both
| > | Windows and MAC where spaces in file names are common. At
| > | very least we should try not to write code that we know is
| > | not portable.
| > 
| > In this particular case, I suspect that Axiom will be best built
| > under Cygwin or variants where Unix convertion is quite dominant
| > (I know you can use the Windows style, but very often they cause
| > troubles).
| 
| Well, at the moment Axiom can not be built under Cygwin because
| GCL cannot be built under Cygwin. Maybe someday we will find
| someone who wants to solve the problems of building GCL under
| Cygwin...

I got report that GCL be built under Cygwin; maybe that was wrong?

| On Windows GCL and Axiom (only AXIOMsys) are currently built under
| MSYS/MinGW which provides a native Windows environment without
| conversion. File name with spaces are suppored but some of the
| unix-specific system commands on which Axiom depends (e.g. 'rm'
| and 'cat'), another source of un-portability, have to be emulated
| in such a way as to parse blanks in a non-standard way.
| 
| > And it is just easy to fix the environment.
| 
| I am not sure what you mean "fix the environment". Do you mean
| target only linux-based systems for Axiom?

Oh no.  I meant "avoid space in names".

| > In this particular case.  I'm not saying Axiom should not
| > support them.  I'm saying it really has low priority on list
| > of things to do.
| 
| Ok.
| 
| > From experience, I know that for GCC we had people trying to
| > build GCC with embedded colons.  That was a pain in the ass
| > and usually led to obscure codes.  My personal opinion is that
| > the codes should not be obscured just to support exotic stuff.
| > YMMV.
| 
| I suppose, but I suspect that the codes would not have been
| so obscured if the original code had not made unnecessary
| assumptions about the character set from which file names are
| composed.

That is not the case.  It fell out of the basic tools used.

| > | Speaking of your "list of things to do in buid-improvments":
| > | Have you already or are you planning to publish this list?
| > 
| > I suspect a good part of it is in README.build-improvements.
| > The rest keeps poping when I try different ideas in different
| > local trees. I'll upate README.build-improvements.  Some of
| > them are not really related to build machinery.
| > 
| 
| After you update README.build-improvements, I would like to
| publish it on the Axiom Wiki. Ok?

Sure, as long as you keep the published and the repo versions in sync.

\start
Date: Sat, 11 Nov 2006 17:10:52 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: data structure vs. mathematical structure (was: Graph theory)

> I think one of the neat things about Axiom is that it is usually
> not necessary or even desirable to make a distinction between
> data structures and mathematical structures. Data structures are
> just another kind of "mathematical" object.

Oh, don't believe that I don't see data structures as mathematical 
structures. They are. But I rather have the feeling that for efficiency 
reasons it is desirable to have some basic data structures underlying 
the mathematics where one can say something about the complexity of the 
functions. After all that is a distincion between classic mathematics 
and constructive mathematics.

Example. You want to implement quicksort. Would someone choose lists to 
do that instead of arrays? Both basically represent the mathematical 
idea of tuples. But we care about the actual representation on a 
computer. Why does Axiom have distributed and recursive polynomials. 
Mathematically it's the same thing, so why bother?

I hope you get somehow the feeling what I meant when I said that I care 
for data structures of graphs. We all know that some representation is 
better than the other for certain algorithms.

Drawing the line between "data structures" and "mathematical structures" 
is hard if not impossible. But for data structures I somehow feel that 
their documentation should clearly say something about the complexity of 
operations.

> For example, is an Axiom set, i.e. a member of the domain Set, a
> data structure or a mathematical structure?

How expensive is it to add a new element to an existing set of type 
Set(T) where T has no ordering function?
How expensive is it to add a new element to Set(T) if T provides an 
ordering function?

I actually don't care about much about whether to call it "data 
structure" or "mathematical structure" since in a general sense the 
first is (as an abstract data type) clearly a mathematical object.
What I care about is stating complexity properties and providing a rich 
set of basic data structures for Axiom/Aldor.

\start
Date: 11 Nov 2006 20:28:43 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: data structure vs. mathematical structure (was: Graph theory)

Ralf Hemmecke writes:

[...]

| What I care about is stating complexity properties and providing a
| rich set of basic data structures for Axiom/Aldor.

This is what we do in the Generic Programming community under the
heading of "Musser--Stepanov style Generic Programming".

\start
Date: Sat, 11 Nov 2006 22:24:19 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: build problem

Version 257 of build-improvements does not build due to missing
quotes. The following fixes the problem:

--- build-improvements.bb/Makefile.pamphlet	2006-11-11 21:10:48.000000000 +0100
+++ build-improvements/Makefile.pamphlet	2006-11-11 22:15:25.000000000 +0100
@@ -559,7 +559,7 @@
 ## -- Old-style Axiom makefile variables --
 ## ----------------------------------------
 
-VERSION = @PACKAGE_STRING@
+VERSION = "@PACKAGE_STRING@"
 SPAD=$(axiom_targetdir)
 LSP=$(abs_builddir)/lsp
 SRC=${SPD}/src

\start
Date: 12 Nov 2006 03:32:06 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: build problem

Waldek Hebisch writes:

| Version 257 of build-improvements does not build due to missing
| quotes. The following fixes the problem:

You're right.  
This was caused by a thinko and duplicate local tree problems.  I
fixed in one tree and commit the other one :-(
It should be fixed by now.

\start
Date: 12 Nov 2006 15:03:07 +0100
From: Gabriel Dos Reis
To: Richard Harke
Subject: Re: build-improvements on ia64

Richard Harke writes:

[...]

| Thanks. This was very helpful. I still have the problem, however.
| I agree it appears to be a gcl problem. I didn't see any thing in the
| gcl build log and the save-system and compiler::link tests
| given above both appeared to work fine. I did try to run this manually:

Could you send the config.log and the build log?

I'm able to build Axiom (--without-gcl) on a x86_64-suse-linux and
use it.

\start
Date: Sun, 12 Nov 2006 15:22:45 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Graph theory

> For example, is an Axiom set, i.e. a member of the domain Set, a
> data structure or a mathematical structure? Should we call the
> domain Set a mathematical structure or only the category SetCategory
> to which it belongs? And of course not everything that we would
> like to call a set in Axiom is finite.

Actually, "Set" is a bad choice for the domain of finite sets that all
have the same type of elements. It should at least be called
"FiniteSet". But then, would make "Set" as a _domain_ in the sense of
mathematics be an interesting domain at all?

> Essentially the only requirement of SetCategory is that the domain
> has equality and inequality.

That is OK, I think.

> I think a Graph in Axiom has to be something nearly as fundamental
> as a Set.

As a category, I agree, but there is not *the* graph domain.

\start
Date: Sun, 12 Nov 2006 17:34:03 +0100
From: Gregory Vanuxem
To: list
Subject: Multiset Hyperdoc examples page (was : Re: Graph theory)

Le dimanche 12 novembre 2006 =E0 15:22 +0100, Ralf Hemmecke a =E9crit :
> > For example, is an Axiom set, i.e. a member of the domain Set, a
> > data structure or a mathematical structure? Should we call the
> > domain Set a mathematical structure or only the category SetCategory
> > to which it belongs? And of course not everything that we would
> > like to call a set in Axiom is finite.
>
> Actually, "Set" is a bad choice for the domain of finite sets that all
> have the same type of elements. It should at least be called
> "FiniteSet". But then, would make "Set" as a _domain_ in the sense of
> mathematics be an interesting domain at all?

I played a little with this and reread aggcat which contains the
aggregate categories used in src/algebra. I displayed in Hyperdoc
Multiset and clicked on the example link (I wanted to know the "users"
of Multiset thanks to Waldek for its patch/remark), the interpreter
returned "Unknown page: MultisetXmpPage". This page seems to exist,
MSET.[p]ht contain some of what I think are examples.

Any idea why this page is not found ? Some other questions, is ph.awk
available somewhere, same thing for the sources of theses files, are
they available somewhere ? What is the difference between a .ht file and
a .pht file ?

A remark, my version of Axiom is not installed, it's just built, so
maybe this bug ("Unknown page: MultisetXmpPage") is specific to me. I
wanted to use the Debian version but encountered another bug ("string
something").

\start
Date: Sun, 12 Nov 2006 18:31:25 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: Multiset Hyperdoc examples page (was : Re: Graph theory)

Vanuxem Gr=E9gory wrote:
> I played a little with this and reread aggcat which contains the
> aggregate categories used in src/algebra. I displayed in Hyperdoc
> Multiset and clicked on the example link (I wanted to know the "users"
> of Multiset thanks to Waldek for its patch/remark), the interpreter
> returned "Unknown page: MultisetXmpPage". This page seems to exist,
> MSET.[p]ht contain some of what I think are examples.
>

MSET.ht contains MultiSetXmpPage, which due to different capitalization
does not match MultisetXmpPage. 

> Any idea why this page is not found ? Some other questions, is ph.awk
> available somewhere, same thing for the sources of theses files, are
> they available somewhere ? What is the difference between a .ht file and
> a .pht file ?
>

.pht was generated form .ht file.  It contains Axiom output, so that
Hypertex can show the output without recomputiong it.  I affraid that
we need to re-create ph.awk (maybe using another language).

\start
Date: Mon, 13 Nov 2006 00:57:34 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: Multiset Hyperdoc examples page (was : Re: Graph theory)

Le dimanche 12 novembre 2006 =E0 18:31 +0100, Waldek Hebisch a =E9crit :
> Vanuxem Gr=E9gory wrote:
> > I played a little with this and reread aggcat which contains the
> > aggregate categories used in src/algebra. I displayed in Hyperdoc
> > Multiset and clicked on the example link (I wanted to know the "users=
"
> > of Multiset thanks to Waldek for its patch/remark), the interpreter
> > returned "Unknown page: MultisetXmpPage". This page seems to exist,
> > MSET.[p]ht contain some of what I think are examples.
> >
>
> MSET.ht contains MultiSetXmpPage, which due to different capitalization
> does not match MultisetXmpPage.

I'll look further at it.

> 
> > Any idea why this page is not found ? Some other questions, is ph.awk
> > available somewhere, same thing for the sources of theses files, are
> > they available somewhere ? What is the difference between a .ht file =
and
> > a .pht file ?
> >
>
> .pht was generated form .ht file.  It contains Axiom output, so that
> Hypertex can show the output without recomputiong it.  I affraid that
> we need to re-create ph.awk (maybe using another language).
>

Thanks for these explanations.

\start
Date: 13 Nov 2006 09:29:40 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: data structure vs. mathematical structure (was: Graph theory)

Bill Page writes:

| On November 11, 2006 2:29 PM Gaby wrote:
| > 
| > This is what we do in the Generic Programming community under
| > the heading of "Musser--Stepanov style Generic Programming".
| >
| 
| See:
| 
| http://www.cs.rpi.edu/~musser
| 
| Algorithm-Oriented Generic Libraries (1994)
| 
| http://citeseer.ist.psu.edu/41800.html
| 
| It is irritating to me to realize how isolated the IBM ScratchPad
| (Axiom) project was from mainstream computer science and yet how
| much they were ahead of the curve on some ideas in programming
| language design.

Hey, Dave and Alex gave an invited talk at ISSAC almost two decades
ago :-)

     http://www.stepanovpapers.com/genprog.pdf

If you browse through the papers by Dave, Alex and collaborators
(especially, those in the early '80), you'll see that they noted
the potential of ScratchPad.  See, for example, the paper 
"Operators and Alegbraic Structures"

    http://www.stepanovpapers.com/p59-kapur.pdf

where they cite the paper by Jenks and Tragger.

| I think that it is clear that in modern terms
| a lot of the innovation in the design of the SPAD language (and
| Aldor) would be described as "generic programming". No?

Yes and No.  In many aspects, Axiom has painted itself into a corner
and insisting beyond reason on object-orientation, which clearly leads
to absurdities like having an Abelian monoid that is not a monoid,
or a ring that is just a monoid without being a group.  I don't think
any freshman in math would get its degree with those nonsense, but
Axiom seems to get away with it :-(  See past discussions on the topic.

You'll see many aspects of generic programming on Alex's site, in
particular in his class on generic programming he is giving at Adobe.

In our collaborative effort to design a "concept system" for C++, we
have tried very hard to ensure that we don't get into the same trap as
Axiom (but it is hard :-).  See for example, our paper "Specifying C++
concepts" 

      http://www.research.att.com/~bs/popl06.pdf

(where it in the related work, you'll see we have specifically mention
computer algebra as area of exploration, referring to Axiom), where we
insisted that we must resist class hierarchies (it has been tried many
times, and it fails). And further work

     http://www.research.att.com/~bs/oopsla06.pdf

There is a another aspect to Generic Programming, called "data-type
generic programming" in the functional programming community that put
less emphasis on algorithmic complexities and more on the structure
of datatype, abstracting over the concrete algebras and focusing on
the pattern functors and algorithms that could be defined solely in
terms of those.  We are working on connecting both views.

      http://lcsd05.cs.tamu.edu/papers/dos_reis_et_al.pdf

Chase the citations to the datatype generic programming.

\start
Date: 13 Nov 2006 12:55:38 +0100
From: Francois Maltey
To: list
Subject: import and map in *.spad files.

Hello,

I try to write a package for my own use from the manip.spad file
for expanding trigonometric functions.

The manip.spad has this definition.

smpExpand p == map (kerExpand, #1::F, p)

It's a map with THREE arguments. 

In Polynomial Domain there is only the usual map with TWO arguments.

I show it by )sh Polynomial Integer by exemple.

In my expand.spad I can't copy this line. 
I get an error when I compile.

If I add theses import thecompilation is fine :

    import FactoredFunctions(P)
    import PolynomialCategoryLifting(IndexedExponents K, K, R, P, F)
    import
      PolynomialCategoryQuotientFunctions(IndexedExponents K,K,R,P,F)


What are theses import command ?

Thanks a lot and have a good day !

\start
Date: 13 Nov 2006 14:47:36 +0100
From: Martin Rubey
To: Francois Maltey
Subject: Re: import and map in *.spad files.

Francois Maltey writes:

> Hello,
> 
> I try to write a package for my own use from the manip.spad file
> for expanding trigonometric functions.
> 
> The manip.spad has this definition.
> 
> smpExpand p == map (kerExpand, #1::F, p)
> 
> It's a map with THREE arguments. 
> 
> In Polynomial Domain there is only the usual map with TWO arguments.

use HyperDoc:

click Browse 

=> enter "map" (without quotes) 

=> click Operations 

=> click Parameters 

=> click map(f, g, x) (usually, f, g, h are functions, but don't rely on
                       this. you really need to check all 3 argument
                       forms. That's a shortcoming of HyperDoc, in fact.  Note
                       that #1::F is a shorthand for the function x +-> x::F)

there is only one such map, and it's in PolynomialCategoryLifting.



import PolynomialCategoryLifting(IndexedExponents K, K, R, P, F)

tells axiom to bring PolynomialCategoryLifting(IndexedExponents K, K, R, P, F)
into scope, so that you don't have to package call (using $) these functions
all the time.

\start
Date: 13 Nov 2006 10:29:20 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Axiom ia64

Greetings!  Please excuse -- I am no longer receiving axiom developer
mail due to some spam blockage somewhere.  Have read on the web how
some have difficulty building axiom on ia64.

At present, there are 5 platforms in gcl-2.6.x (hppa, ia64, alpha,
mips, and mipsel) and 2 platforms on gcl-2.7.x (hppa and ia64) which
cannot natively relocate compiled object files.  This means that (load
"foo.o")(si::save-system "bar") will give garbage in bar (perhaps in
should simple be an error.  This is because loads happen via dlopen
and exist outside the heap.  Instead, images must be saved with
compiler::link.  Thus, there are some alternate commands which need
issuing in the axiom build to make this all work.  These are
summarized in the debian/patch.merge file in the debian axiom package.
With these commands, axiom builds on all 12 Debian platforms.


Here is patch.merge.  Note that one can conditionalize the alternate
procedures on #-native-reloc without having to keep track of specific
cpus.  

=============================================================================
--- ./lsp/Makefile.pamphlet.~1.5.~	2005-09-05 18:50:31.000000000 +0000
+++ ./lsp/Makefile.pamphlet	2005-09-20 21:20:10.000000000 +0000
@@ -1012,14 +1012,7 @@
 	@echo 1 building ${LSP} ${GCLVERSION}
 
 gcldir: 
-	@echo 2 building ${GCLVERSION}
-	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
-<<gcl-2.6.7.socket.patch>>
-<<gcl-2.6.7.libspad.patch>>
-<<gcl-2.6.7.toploop.patch>>
-<<gcl-2.6.7.tail-recursive.patch>>
-<<gcl-2.6.7.collectfn.fix>>
-<<gclConfigureMake>>
+	echo '(compiler::link nil "${OUT}/lisp" (format nil "(progn (let ((*load-path* (cons ~S *load-path*))(si::*load-types* ~S)) (compiler::emit-fn t))(when (fboundp (quote si::sgc-on)) (si::sgc-on t))#-native-reloc(setq compiler::*default-system-p* t))" si::*system-directory* (quote (list #+native-reloc".o" ".lsp"))) "${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o ${OBJ}/${SYS}/lib/libspad.a")' | gcl
 	@echo 13 finished system build on `date` | tee >gcldir
 
 ccldir: ${LSP}/ccl/Makefile
--- ./src/algebra/Lattice.pamphlet.orig	2005-01-04 23:45:59.000000000 +0000
+++ ./src/algebra/Lattice.pamphlet	2005-02-14 18:45:10.000000000 +0000
@@ -39620,13 +39620,14 @@
 	@ cp -p ${SRC}/doc/gloss.text ${LIB}
 	@ cp -p ${SRC}/doc/topics.data ${MID}
 	@ echo rebuilding daase files
-	@ (cd ${MID} ; \
-	   echo ')set out le 200' >/tmp/tmp.input ; \
-	   echo ')fin' >>/tmp/tmp.input ; \
-	   echo '(make-databases "" (QUOTE ("unix")))' >>/tmp/tmp.input ; \
-	   echo '(bye)' >>/tmp/tmp.input ; \
-	   cat /tmp/tmp.input | ${INTERPSYS} ; \
-	   rm -f /tmp/tmp.input )
+	@ (cd ${MID} ; \
+	   echo ')set out le 200' >/tmp/tmp.input ; \
+	   echo ')fin' >>/tmp/tmp.input ; \
+	   echo "#+native-reloc(make-databases \"\" (QUOTE (\"unix\")))#-native-reloc(system \"cp ${SRC}/../debian/*.daase ${MID}\")" >>/tmp/tmp.input ; \
+	   echo '(bye)' >>/tmp/tmp.input ; \
+	   cat /tmp/tmp.input | ${INTERPSYS} ; \
+	   rm -f /tmp/tmp.input )
+#	@ (cp ${SRC}/../debian/*.daase ${MID})
 	@ echo If all went well, go-ahead Mike and do a db-install as well !
 
 db-install:
@@ -39758,7 +39759,8 @@
 	@ echo rebuilding databases...
 	@ cp ${SRC}/doc/gloss.text ${MID}
 	@ cp ${SRC}/doc/topics.data ${MID}
-	@ (cd ${MID} ; echo ')lisp (make-databases "" nil)' | ${INTERPSYS} )
+	@ (cd ${MID} ; echo ")lisp (progn #+native-reloc(make-databases \"\" nil)#-native-reloc(system \"cp ${SRC}/../debian/*.daase ${MID}\"))" | ${INTERPSYS} )
+#	@ (cp ${SRC}/../debian/*.daase ${MID})
 
 check:
 	@ echo Checking that INTERP.EXPOSED and NRLIBs are consistent
--- ./src/etc/Makefile.pamphlet.orig	2005-01-30 12:03:12.000000000 +0000
+++ ./src/etc/Makefile.pamphlet	2005-02-14 18:47:16.000000000 +0000
@@ -33,9 +33,10 @@
 	@ cp ${SRC}/doc/gloss.text ${INT}/algebra
 	@ cp ${SRC}/doc/topics.data ${INT}/algebra
 	@ cp ${SRC}/doc/topics.data ${INT}/algebra
-	@ (cd ${INT}/algebra ; \
-           echo ')lisp (make-databases "" nil)' | ${INTERPSYS} )
-	@ cp ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra
+	@ (cd ${INT}/algebra ; \
+           echo ")lisp (progn #+native-reloc(progn (make-databases \"\" nil)(system \"cp ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra\"))#-native-reloc(system \"cp ${SRC}/../debian/*.daase ${MNT}/${SYS}/algebra\"))" | ${INTERPSYS} )
+#	@ cp ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra
+#	@ (cp ${SRC}/../debian/*.daase ${MNT}/${SYS}/algebra)
 
 @
 \section{summary}
--- ./src/boot/Makefile.pamphlet.orig	2005-06-05 03:23:35.000000000 +0000
+++ ./src/boot/Makefile.pamphlet	2005-09-20 21:36:15.000000000 +0000
@@ -1173,7 +1173,8 @@
 
 Until this is fixed we need to continue to use the old scheme.
 <<environment>>= 
-CMD0=	(progn (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system "${SAVESYS}"))
+#CMD0=	(progn (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system "${SAVESYS}"))
+CMD0=	(if (member :native-reloc *features*) (progn (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system "${SAVESYS}")) (compiler::link (quote (${OBJS1})) "${SAVESYS}" (format nil "(let ((*load-path* (cons ~S *load-path*))(si::*load-types* ~S)) (compiler::emit-fn t)) (when (fboundp (quote si::sgc-on)) (si::sgc-on t)) (setq compiler::*default-system-p* t)" si::*system-directory* (quote  (list ".lsp")))))
  
 @
 \subsection{boothdr.lisp \cite{1}}
--- ./src/interp/Makefile.pamphlet.orig	2005-09-20 21:48:56.000000000 +0000
+++ ./src/interp/Makefile.pamphlet	2005-09-20 21:49:14.000000000 +0000
@@ -576,7 +576,28 @@
 \begin{verbatim}
 <<save depsys image>>=
 	@ (cd ${MNT}/${SYS}/bin ; \
-	   echo '(progn (load "${OUT}/makedep.lisp") (spad-save "${DEPSYS}"))' | ${LISPSYS})
+	   echo '#+native-reloc(progn (load "${OUT}/makedep.lisp") (spad-save "${DEPSYS}"))#-native-reloc(progn\
+			(setq si::*collect-binary-modules* t)\
+			(load "${OUT}/makedep.lisp")\
+			(compiler::link\
+				(remove-duplicates si::*binary-modules* :test (quote equal))\
+				"$(DEPSYS)"\
+				(format nil "\
+					(setq si::*collect-binary-modules* t)\
+					(let ((si::*load-path* (cons ~S si::*load-path*))\
+	                                     (si::*load-types* ~S))\
+						(compiler::emit-fn t))\
+					(load \"$(OUT)/makedep.lisp\")\
+					(gbc t)\
+					(when si::*binary-modules*\
+						(error si::*binary-modules*))\
+					(setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+					(gbc t)\
+					(when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+					(setq compiler::*default-system-p* t)\
+				" si::*system-directory* (quote (list ".lsp")))\
+				""\
+				nil))' | sed 's,\\$$,,g' | ${LISPSYS})
 @
 \end{verbatim}
 
@@ -880,8 +901,36 @@
 	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (si::gbc-time 0)' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' >> ${OUT}/makeint.lisp
+#	@ (cd ${OBJ}/${SYS}/bin ; \
+#	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
 	@ (cd ${OBJ}/${SYS}/bin ; \
-	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+	  echo '#+native-reloc(progn (gbc t) (setq x si::*system-directory*)(load "${OUT}/makeint.lisp") (setq si::*system-directory* x) (unintern (quote x))(gbc t)(user::spad-save "${SAVESYS}"))#-native-reloc(progn\
+			(setq si::*collect-binary-modules* t)\
+			(setq x si::*system-directory*)\
+			(load "${OUT}/makeint.lisp")\
+			(setq si::*system-directory* x)\
+			(unintern (quote x))\
+			(compiler::link\
+				(remove-duplicates si::*binary-modules* :test (quote equal))\
+				"$(SAVESYS)"\
+				(format nil "\
+					(let ((si::*load-path* (cons ~S si::*load-path*))\
+                                             (si::*load-types* ~S))\
+						(compiler::emit-fn t))\
+					 (setq si::*collect-binary-modules* t)\
+					 (setq x si::*system-directory*)\
+					 (load \"$(OUT)/makeint.lisp\")\
+					 (setq si::*system-directory* x)\
+					 (unintern (quote x))\
+					 (when si::*binary-modules*\
+						(error si::*binary-modules*))\
+					(setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+					(gbc t)\
+					(when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+					(setq compiler::*default-system-p* t)\
+				" si::*system-directory* (quote (list ".lsp")))\
+			"$(OBJ)/$(SYS)/lib/sockio-c.o $(OBJ)/$(SYS)/lib/cfuns-c.o $(OBJ)/$(SYS)/lib/libspad.a" \
+			nil))' | sed 's,\\$$,,g' | $(LISPSYS))
 	@ echo 6 ${SAVESYS} created
 	@ cp ${SAVESYS} ${AXIOMSYS}
 	@ echo 6a ${AXIOMSYS} created
=============================================================================

If anyone would like to help getting bfd support for ia64 and friends,
please look at sfaslbfd_alpha.c and sfaslbfd_mips.c from the HEAD cvs
tree.  This should serve as an example for the needed sfaslbfd_ia64.c

\start
Date: 13 Nov 2006 10:43:05 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: gcl and readline

Greetings!  GCL can be built without readline with
--disable-readline.  At runtime, readline can be turned on and off
with (si::readline-on) and (si::readline-off).  There is some support
for autocompletion.  readline should be automatically disabled when
the terminal is uncapable.  (si::readline-on in such circumstances
should reveal this.

GCL readline support should be reworked to avoid malloc if possible.

\start
Date: Mon, 13 Nov 2006 11:50:37 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: test from support

Thanks for the replies.

I am sorry to clutter the email list with this test. :-( In fact
it was sent by my email provider in response to my problem report
attached below. They claim that it is not their problem so perhaps
it has something to do with changes in the nongnu.org email list
software and the mx10.gnu.org server. Has anyone else received a
"fatal error" response like:

  550-Callback setup failed while verifying

On November 13, 2006 11:30 AM Ralf Hemmecke wrote:
> 
> Do you want to test how many people are active?
> 
> Ralf
> 
> On 11/13/2006 04:55 PM, Bill Page wrote:
> > hi there,
> > please reply to this email if you receive it.
> > tech support

-----Original Message-----
Good Morning Bill,

I have forwarded the information including the error message to our email
provider for investigation.  I will contact you once I receive their
response.

Quoting Bill Page:

> Dear Tech Support;
>
> Can you confirm that the following error message which I received
> while posting to an email list that used to work properly is due
> to some problem with the Anikast email server? The message suggests
> that my mail server is rejecting a certain type of request to verify
> my email address and that therefore the email list is refusing to
> post my message to the group. This error has happened frequently
> over the last week but not for every message that I have sent.
>
> Regards,
> Bill Page.
>
> -----Original Message-----
> From: Mail Delivery Subsystem [mailto:MAILER-DAEMON]
> Sent: November 13, 2006 1:14 AM
> To: Bill Page
> Subject: Returned mail: see transcript for details
>
>
> The original message was received at Mon, 13 Nov 2006 01:13:37 -0500
> from [207.35.46.72]
>
>    ----- The following addresses had permanent fatal errors -----
> <list>
>     (reason: 550-Callback setup failed while verifying
> Bill Page)
>
>    ----- Transcript of session follows -----
> ... while talking to mx10.gnu.org.:
>>>> DATA
> <<< 550-Callback setup failed while verifying
> Bill Page
> <<< 550-(result of an earlier callout reused).
> <<< 550-The initial connection, or a HELO or MAIL FROM:<> command was
> <<< 550-rejected. Refusing MAIL FROM:<> does not help fight spam,
disregards
> <<< 550-RFC requirements, and stops you from receiving standard bounce
> <<< 550-messages. This host does not accept mail from domains whose
servers
> <<< 550-refuse bounces.
> <<< 550 Sender verify failed
> 550 5.1.1 <list>... User unknown
> <<< 503 valid RCPT command must precede DATA

\start
Date: Mon, 13 Nov 2006 13:03:24 -0400
From: Humberto Zuazaga
To: Bill Page
Subject: Re: test from support

Bill Page wrote:
> Thanks for the replies.
> 
> I am sorry to clutter the email list with this test. :-( In fact
> it was sent by my email provider in response to my problem report
> attached below. They claim that it is not their problem so perhaps
> it has something to do with changes in the nongnu.org email list
> software and the mx10.gnu.org server. Has anyone else received a
> "fatal error" response like:
> 
>   550-Callback setup failed while verifying
> 
> ?
> 
> Regards,
> Bill Page.
> 
> On November 13, 2006 11:30 AM Ralf Hemmecke wrote:
>> Do you want to test how many people are active?
>>
>> Ralf
>>
>> On 11/13/2006 04:55 PM, Bill Page wrote:
>>> hi there,
>>> please reply to this email if you receive it.
>>> tech support
>>>
>>>
>>> _______________________________________________
>>> Axiom-developer mailing list
>>> list
>>> http://lists.nongnu.org/mailman/listinfo/axiom-developer
> 
> 
> 
> -----Original Message-----
> From: support@anikast.ca [mailto:support@anikast.ca] 
> Sent: November 13, 2006 8:31 AM
> To: Bill Page
> Subject: RE: Megamailserver
> 
> 
> Good Morning Bill,
> 
> I have forwarded the information including the error message to our email
> provider for investigation.  I will contact you once I receive their
> response.
> 
> Regards,
> Michelle
> Anikast CSR
> 
> Quoting Bill Page:
> 
>> Dear Tech Support;
>>
>> Can you confirm that the following error message which I received
>> while posting to an email list that used to work properly is due
>> to some problem with the Anikast email server? The message suggests
>> that my mail server is rejecting a certain type of request to verify
>> my email address and that therefore the email list is refusing to
>> post my message to the group. This error has happened frequently
>> over the last week but not for every message that I have sent.
>>
>> Regards,
>> Bill Page.
>>
>> -----Original Message-----
>> From: Mail Delivery Subsystem [mailto:MAILER-DAEMON]
>> Sent: November 13, 2006 1:14 AM
>> To: Bill Page
>> Subject: Returned mail: see transcript for details
>>
>>
>> The original message was received at Mon, 13 Nov 2006 01:13:37 -0500
>> from [207.35.46.72]
>>
>>    ----- The following addresses had permanent fatal errors -----
>> <list>
>>     (reason: 550-Callback setup failed while verifying
>> Bill Page)
>>
>>    ----- Transcript of session follows -----
>> ... while talking to mx10.gnu.org.:
>>>>> DATA
>> <<< 550-Callback setup failed while verifying
>> Bill Page
>> <<< 550-(result of an earlier callout reused).
>> <<< 550-The initial connection, or a HELO or MAIL FROM:<> command was
>> <<< 550-rejected. Refusing MAIL FROM:<> does not help fight spam,
> disregards
>> <<< 550-RFC requirements, and stops you from receiving standard bounce
>> <<< 550-messages. This host does not accept mail from domains whose
> servers
>> <<< 550-refuse bounces.
>> <<< 550 Sender verify failed
>> 550 5.1.1 <list>... User unknown
>> <<< 503 valid RCPT command must precede DATA
>>
>>
>>
> 
> 
> 
> support@anikast.ca
> 1-877-264-5278
> Mon-Fri 8am to 11pm est and Sat-Sun 9am to 9pm est
> 
> 
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> list
> http://lists.nongnu.org/mailman/listinfo/axiom-developer

We've had problems with mailing lists on other servers, and there's a 
thread on problems between gmail and sourceforge:

http://it.slashdot.org/it/06/10/04/1324214.shtml

sourceforge mailing lists were implementing "callbacks" and were 
dropping mail.

Here's a description of what might be happening:

http://atm.tut.fi/list-archive/nanog/msg37172.html

For what it's worth, I haven't seen problems with mail to 
axiom-developer on my end (knock on wood).

\start
Date: Mon, 13 Nov 2006 13:01:31 -0500
From: Bill Page
To: list
Subject: (no subject)

this is a test sent directly from the server, by telneting into the port 1025

\start
Date: Mon, 13 Nov 2006 13:08:57 -0500
From: Bill Page
To: list
Subject: (no subject)

this is a message for axiom developer..it will end up on bill.page1@ 
inbox which means there is a forwrading set on axiom-developer@testing

\start
Date: Mon, 13 Nov 2006 14:44:26 -0800
From: Antoine Hersen
To: list
Subject: Eval in Axiom/Aldor

Hello,

I am having some issue with the eval function, any ideas ?
I have reduced my problem to the simplest form.
It is making me crazy !!!

Because UP, which is a PolynomialCat, has InnerEvalable

PolynomialCategory(R:Ring, E:OrderedAbelianMonoidSup, VarSet:OrderedSet):
        Category ==
  Join(PartialDifferentialRing VarSet, FiniteAbelianMonoidRing(R, E),
       Evalable %, InnerEvalable(VarSet, R),
       InnerEvalable(VarSet, %), RetractableTo VarSet,
       FullyLinearlyExplicitRingOver R)

What am I missing ?

Prog :

#include "axiom.as"

TestEval( x:Symbol , F:Field): with {}
== add {


    import from UnivariatePolynomial(x,F) ;
    import from Fraction UnivariatePolynomial(x,F) ;

    test(a:Fraction UnivariatePolynomial(x,F)):Fraction
UnivariatePolynomial(x,F) == {
        eval(a, x, 1)
    }

And here his the error message :

 aldor -M no-abbrev -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete
-DAxiom -Y $AXIOM/algebra eval.as
#1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
"eval.as", line 11:                 eval(a, x, 1)
                    ................^
[L11 C17] #2 (Error) No one possible return type satisfies the context type.
  These possible return types were rejected:
          -- Fraction(UnivariatePolynomial(x, F))
  The context requires an expression of type
Fraction(UnivariatePolynomial(x, F)).
The following could be suitable if imported:
  eval: (Fraction(UnivariatePolynomial(x, F)), Symbol pretend SetCategory,
UnivariatePolynomial(x, F) pretend Type) -> Fraction(UnivariatePolynomial(x,
F)) from Fraction(UnivariatePolynomial(x, F)), if UnivariatePolynomial(x, F)
has InnerEvalable(Symbol, UnivariatePolynomial(x, F))

\start
Date: Tue, 14 Nov 2006 00:26:50 +0100
From: Ralf Hemmecke
To: Antoine Hersen
Subject: Re: Eval in Axiom/Aldor

Hi Antoine,

I don't know whether this is the right way to go, but at least it 
compiles and it might let you go further.

Suggestion:

Replace "eval(a, x, 1)" by

     z: SingletonAsOrderedSet := create();
     eval(numer a, z, 1)/eval(denom a, z, 1);

Maybe you can make that shorter. In particular the numer/denom part is 
perhaps too much, but that is what I have found to work, ehm compile.

Now, don't ask me how to relate x and z. The reason why I have 
introduced that z lies in the definition of UP. It is not defined as 
PolynomialCategory as such, but the code says...

UnivariatePolynomial(x:Symbol, R:Ring):
   UnivariatePolynomialCategory(R) with
   ...

and there you already see that in a category default, you have no chance 
of seeing the x.

But then it says...

UnivariatePolynomialCategory(R:Ring): Category ==
  Join(PolynomialCategory(R, NonNegativeInteger, SingletonAsOrderedSet),

which let me to define z as the only element of SingletonAsOrderedSet.

Maybe that helps a bit.

Ralf


On 11/13/2006 11:44 PM, Antoine Hersen wrote:
> Hello,
> 
> I am having some issue with the eval function, any ideas ?
> I have reduced my problem to the simplest form.
> It is making me crazy !!!
> 
> Because UP, which is a PolynomialCat, has InnerEvalable
> 
> PolynomialCategory(R:Ring, E:OrderedAbelianMonoidSup, VarSet:OrderedSet):
>         Category ==
>   Join(PartialDifferentialRing VarSet, FiniteAbelianMonoidRing(R, E),
>        Evalable %, InnerEvalable(VarSet, R),
>        InnerEvalable(VarSet, %), RetractableTo VarSet,
>        FullyLinearlyExplicitRingOver R)
> 
> What am I missing ?
> 
> Prog :
> 
> #include "axiom.as <http://axiom.as>"
> 
> TestEval( x:Symbol , F:Field): with {}
> == add {
> 
> 
>     import from UnivariatePolynomial(x,F) ;
>     import from Fraction UnivariatePolynomial(x,F) ;
> 
>     test(a:Fraction UnivariatePolynomial(x,F)):Fraction 
> UnivariatePolynomial(x,F) == {
>         eval(a, x, 1)
>     }
> 
> And here his the error message :
> 
>  aldor -M no-abbrev -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete 
> -DAxiom -Y $AXIOM/algebra eval.as <http://eval.as>
> #1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
> "eval.as <http://eval.as>", line 11:                 eval(a, x, 1)
>                     ................^
> [L11 C17] #2 (Error) No one possible return type satisfies the context type.
>   These possible return types were rejected:
>           -- Fraction(UnivariatePolynomial(x, F))
>   The context requires an expression of type 
> Fraction(UnivariatePolynomial(x, F)).
> The following could be suitable if imported:
>   eval: (Fraction(UnivariatePolynomial(x, F)), Symbol pretend 
> SetCategory, UnivariatePolynomial(x, F) pretend Type) -> 
> Fraction(UnivariatePolynomial(x, F)) from 
> Fraction(UnivariatePolynomial(x, F)), if UnivariatePolynomial(x, F) has 
> InnerEvalable(Symbol, UnivariatePolynomial(x, F))

\start
Date: Tue, 14 Nov 2006 02:36:22 +0100 (CET)
From: Waldek Hebisch
To: Camm Maguire
Subject: Re: Axiom ia64
Cc: Gabriel Dos Reis

Camm Maguire wrote:
> At present, there are 5 platforms in gcl-2.6.x (hppa, ia64, alpha,
> mips, and mipsel) and 2 platforms on gcl-2.7.x (hppa and ia64) which
> cannot natively relocate compiled object files.  This means that (load
> "foo.o")(si::save-system "bar") will give garbage in bar (perhaps in
> should simple be an error.  This is because loads happen via dlopen
> and exist outside the heap.  Instead, images must be saved with
> compiler::link.  Thus, there are some alternate commands which need
> issuing in the axiom build to make this all work.  These are
> summarized in the debian/patch.merge file in the debian axiom package.
> With these commands, axiom builds on all 12 Debian platforms.
> 

> +	@ (cd ${MID} ; \
> +	   echo ')set out le 200' >/tmp/tmp.input ; \
> +	   echo ')fin' >>/tmp/tmp.input ; \
> +	   echo "#+native-reloc(make-databases \"\" (QUOTE (\"unix\")))#-native-reloc(system \"cp ${SRC}/../debian/*.daase ${MID}\")" >>/tmp/tmp.input ; \
> +	   echo '(bye)' >>/tmp/tmp.input ; \
> +	   cat /tmp/tmp.input | ${INTERPSYS} ; \
> +	   rm -f /tmp/tmp.input )
> +#	@ (cp ${SRC}/../debian/*.daase ${MID})
>  	@ echo If all went well, go-ahead Mike and do a db-install as well !

I see that you skip database build when native-reloc does not hold.  Did
you try loading all domain files in interpreted mode?  AFAICS one gets
the same database and speed is also quite similar.

BTW.  To load domain files in interpreted mode I just removed .o files (there
is probably a better way).

\start
Date: Mon, 13 Nov 2006 21:39:00 -0500
From: Bill Page
To: list
Subject: FW: data structure vs. mathematical structure (was: Graph theory)

-----Original Message-----

On November 11, 2006 11:11 AM Ralf Hemmecke wrote:
> ...
> Bill Page wrote:
> > I think one of the neat things about Axiom is that it is
> > usually not necessary or even desirable to make a distinction
> > between data structures and mathematical structures. Data
> > structures are just another kind of "mathematical" object.
>
> Oh, don't believe that I don't see data structures as
> mathematical structures. They are. But I rather have the feeling
> that for efficiency reasons it is desirable to have some basic
> data structures underlying the mathematics where one can say
> something about the complexity of the functions.

Axiom actually has a very specific notion of what it means for
one mathematical structure to underly another - representation.
In Axiom domains have an associated internal representation, Rep.
The domain Rep is given in terms of domain constructors (such as
Record) applied to other previously defined domains. Then members
of the new domain % are mapped into Rep via the rep operator and
from Rep into % by the per operator. The exported operations of
% are defined in terms of the "underlying" operations in Rep.

We usual think of Rep as more "primitive" than % and as if Rep
is the underlying "data" structure and % is the mathematical
structure. But in general in Axiom this need to be the case.
There is indeed a most primitive domain which is not defined
in terms of any other, called simply Lisp. But it would not be
possible if the representation graph to contain loops so that
one can not say of any domain in the loop that it is more
primitive than another.

So using previously defined domains, and domain constructors
one builds a representation for the desired new domain and then
"encapsulates" it by exporting an interface to the essential
operations of this representation and hiding the non-essential
and irrelevant parts. And I think this might be applied in a
mutually recursive manner.

So is computational complexity a relative thing, i.e. we take
the operations from the representation as units and then express
the complexity of the operations of the new domain in terms of
these? Or is it an absolute thing that must be expressed in
terms of the most primitive domain (Lisp) or even deeper in
terms of a given hardware architecture?

> After all that is a distincion between classic mathematics
> and constructive mathematics.
>

I am not sure that I would agree that this is the right distinction.
Ultimately in computer algebra systems I think all mathematics must
be constructive. In a sense, that is what we mean by "algebra". An
existence proof or a proof by contradiction is not of much use in
such a system.

> Example. You want to implement quicksort. Would someone choose
> lists to do that instead of arrays?

In Axiom this is not really an appropriate question. quicksort
would be implemented in a generic manner so that it can be applied
to any domain that provides the necessary methods. In fact in the
Axiom book contains exactly this example (bubble sort actually).

> Both basically represent the mathematical idea of tuples.

No, I don't think so. As mathematical objects lists, arrays and
tuples are all quite distinct however I agree that they all provide
the necessary methods on which sort may operate.

> But we care about the actual representation on a computer.

Agreed.

> Why does Axiom have distributed and recursive polynomials.
> Mathematically it's the same thing, so why bother?

This may not be such a good example since I think the difference
here is primarily related to how these domains coerce to OutputForm.
It is not clear to me how or when we can say that something is
"mathematically the same thing".

>
> I hope you get somehow the feeling what I meant when I said
> that I care for data structures of graphs. We all know that
> some representation is better than the other for certain
> algorithms.
>

Yes that is true and I agree that it is an important issue.

> Drawing the line between "data structures" and "mathematical
> structures" is hard if not impossible. But for data structures
> I somehow feel that their documentation should clearly say
> something about the complexity of operations.
>

The current Axiom library does make such a distinction at least
conceptually. See for example the Algebra and Data structure
hierachies in the end covers of the Axiom book. However note that
at least SetCategory, Finite, and OrderedSet appear in both
diagrams.

> > For example, is an Axiom set, i.e. a member of the domain Set,
> > a data structure or a mathematical structure?
>
> How expensive is it to add a new element to an existing set of
> type Set(T) where T has no ordering function? How expensive is
> it to add a new element to Set(T) if T provides an ordering
> function?
>

All domains that have SetCategory are required to have a hash into
SmallInteger. I suppose that this means that the cost of adding
new elements is independent of Type T.

> I actually don't care about much about whether to call it "data
> structure" or "mathematical structure" since in a general sense
> the first is (as an abstract data type) clearly a mathematical
> object. What I care about is stating complexity properties and
> providing a rich set of basic data structures for Axiom/Aldor.
>

On November 12, 2006 9:23 AM Ralf Hemmecke wrote:
> ...
> Bill Page wrote:
> > Should we call the domain Set a mathematical structure or only
> > the category SetCategory to which it belongs? And of course not
> > everything that we would like to call a set in Axiom is finite.
>
> Actually, "Set" is a bad choice for the domain of finite sets
> that all have the same type of elements. It should at least be
> called "FiniteSet".

I don't agree. Finite is yet another category.

> But then, would make "Set" as a _domain_ in the sense of
> mathematics be an interesting domain at all?

Why not? As a domain, Set need not be finite.

(1) -> Integer has SetCategory

   (1)  true
                                                 Type: Boolean

(2) -> ZMOD 7 has SetCategory

   (2)  true
                                                 Type: Boolean

(3) -> Set Integer has Finite

   (3)  false
                                                 Type: Boolean

(4) -> Set ZMOD 7 has Finite

   (4)  true
                                                 Type: Boolean

(5) -> size()$Set ZMOD 7

   (5)  128
                                       Type: NonNegativeInteger

Note that size:()->NNI, i.e. the size of the Domain, is different
then #:%->NNI, or cardinality of the size of a given set. It is
true that all members of Set have a finite cardinality. But not
all domains in SetCategory are Finite.

>
> > Essentially the only requirement of SetCategory is that the
> > domain has equality and inequality.
>
> That is OK, I think.
>
> > I think a Graph in Axiom has to be something nearly as
> > fundamental as a Set.
>
> As a category, I agree, but there is not *the* graph domain.

Similar to Set, I think we need to admit the possibility of an
infinite number of members of the Graph domain, i.e. Graph need
not have Finite.

As a category I think I would want GraphCategory to require at
least

  Node: SetCategory
  Edge: SetCategory
  Source: Edge -> Node
  Target: Edge -> Node

But I do not want to require that all domains in GraphCategory
are Finite. Just as all domains in SetCategory are not Finite.

On November 12, 2006 11:34 AM Vanuxem Gr=E9gory wrote:
> ...
> I played a little with this and reread aggcat which contains the
> aggregate categories used in src/algebra.
> ...

I think it is interesting that multisets only have cardinality if
the domain has finiteAggregate since count is unbounded.

\start
Date: Mon, 13 Nov 2006 21:40:41 -0500
From: Bill Page
To: list
Subject: FW: Multiset Hyperdoc examples page

-----Original Message-----

On November 12, 2006 12:31 PM Waldek Hebisch wrote:
>
> Vanuxem Gr=E9gory wrote:
> > I played a little with this and reread aggcat which contains
> > the aggregate categories used in src/algebra. I displayed in
> > Hyperdoc Multiset and clicked on the example link (I wanted
> > to know the "users" of Multiset thanks to Waldek for its
> > patch/remark), the interpreter returned
> >   "Unknown page: MultisetXmpPage".
> > This page seems to exist, MSET.[p]ht contain some of what I
> > think are examples.
> >
>
> MSET.ht contains MultiSetXmpPage, which due to different
> capitalization does not match MultisetXmpPage. 
>

It seems that there is a realistic prospect of making hyperdoc
more useful and more reliable. Is there enough interest to warrant
establishing a new branch focusing on hyperdoc-improvements?
 
> > Any idea why this page is not found ? Some other questions,
> > is ph.awk available somewhere, same thing for the sources of
> > theses files, are they available somewhere ? What is the
> > difference between a .ht file and a .pht file ?
> >
>
> .pht was generated form .ht file.  It contains Axiom output,
> so that Hypertex can show the output without recomputiong it.
> I am afraid that we need to re-create ph.awk (maybe using
> another language).
>

There are awk scripts like ht.awk that sound similar to this in
the htex directory that is part of the original Axiom source
distribution (not currently in the Open Source version but could
be if we want them, I think). Where can I find a reference to
ph.awk?

I believe that Kai Kaminski worked on some code (in Perl?) to
extract the executable parts of the .ht files as .input files
and then run Axiom to re-generate the Axiom output sections.
I don't know if this work was completed or not. In principle
it is not difficult. Some parts of this would be similar to
what is done on the Axiom wiki to product wiki pages with
embedded Axiom output (using Python).

\start
Date: 14 Nov 2006 04:16:55 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: FW: data structure vs. mathematical structure (was: Graph theory)

[ Is it normal that I don't see Ralf's messages? ]


Bill Page writes:

[...]

| So is computational complexity a relative thing, i.e. we take
| the operations from the representation as units and then express
| the complexity of the operations of the new domain in terms of
| these? Or is it an absolute thing that must be expressed in
| terms of the most primitive domain (Lisp) or even deeper in
| terms of a given hardware architecture?

relative.

| > After all that is a distincion between classic mathematics
| > and constructive mathematics.
| >
| 
| I am not sure that I would agree that this is the right distinction.
| Ultimately in computer algebra systems I think all mathematics must
| be constructive. In a sense, that is what we mean by "algebra". An
| existence proof or a proof by contradiction is not of much use in
| such a system.
|  
| > Example. You want to implement quicksort. Would someone choose
| > lists to do that instead of arrays?
| 
| In Axiom this is not really an appropriate question. quicksort
| would be implemented in a generic manner so that it can be applied
| to any domain that provides the necessary methods. In fact in the
| Axiom book contains exactly this example (bubble sort actually).

However, to call it quicksort, you have to meet some algorithmic
complexity  guarantee.  

| > Both basically represent the mathematical idea of tuples.
| 
| No, I don't think so. As mathematical objects lists, arrays and
| tuples are all quite distinct however I agree that they all provide
| the necessary methods on which sort may operate.

The notion of sorting is defined terms of order and permutation.

[...]

| > > For example, is an Axiom set, i.e. a member of the domain Set,
| > > a data structure or a mathematical structure?
| > 
| > How expensive is it to add a new element to an existing set of
| > type Set(T) where T has no ordering function? How expensive is
| > it to add a new element to Set(T) if T provides an ordering
| > function?
| > 
| 
| All domains that have SetCategory are required to have a hash into
| SmallInteger.

That is not a mathematical requirement.

| I suppose that this means that the cost of adding
| new elements is independent of Type T.

Why?

\start
Date: Mon, 13 Nov 2006 22:36:22 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: mercurial source code control system

Cliff,

On November 13, 2006 4:57 PM you wrote:

>
> Just thought you might like to know I'm installing mercurial
> to try out working with build-improvements, after seeing this
> interview about the Java open sourcing:
>

http://java.sun.com/developer/technicalArticles/Interviews/gosling_os1_qa=
.ht
ml

Great. Thanks for the reference. Sun seems to be a big user
of Mercurial. It is also used in the OpenSolaris project.
Let me know how it goes with build-improvements and hg.

You might be interested in the draft of a book on Mercurial:

http://www.red-bean.com/~bos/hgbook.pdf

\start
Date: Mon, 13 Nov 2006 23:35:24 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: FW: data structure vs. mathematical structure (was: Graph theory)

Gaby,

On November 13, 2006 10:17 PM you wrote:
> ...
> [ Is it normal that I don't see Ralf's messages? ]
>

I believe that all messages that I received recently from Ralf are
here in the axiom-developer email archive:

http://lists.nongnu.org/archive/html/axiom-developer/2006-11/index.html

which means that under normal circumstances these would also have
been forwarded to you. Are you missing some?

> Bill Page writes:
> ...
> |
> | All domains that have SetCategory are required to have a hash
> | into SmallInteger.
>
> That is not a mathematical requirement.
>

I would tend to agree but perhaps Kurt G=F6del would not have... ;-)

[Concerning the complexity of Set(T) for some type T ...]

> | I suppose that this means that the cost of adding
> | new elements is independent of Type T.
>
> Why?
>

hash makes testing equality O(1).

Axiom's implementation of Set is rather primitive.

See:

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/SetsSpad

Set(S:SetCategory): FiniteSetAggregate S

...
++ \spad{insert(x,t)} and \spad{remove(x,t)} is \spad{O(n)}
...
      insert_!(x, s) ==
        for k in minIndex s .. maxIndex s repeat
          s.k = x => return s
        insert_!(x, s, inc maxIndex s)
...

\start
Date: 14 Nov 2006 06:01:13 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: FW: data structure vs. mathematical structure (was: Graph theory)

Bill Page writes:

[...]

| > Bill Page writes:
| > ...
| > |
| > | All domains that have SetCategory are required to have a hash
| > | into SmallInteger.
| >
| > That is not a mathematical requirement.
| >
|
| I would tend to agree but perhaps Kurt G=F6del would not have... ;-)

>From constructive mathematics point of view, the only things that are
required for a set are:

  (1) say how to build element of a set
  (2) equality test.

\start
Date: 14 Nov 2006 09:18:48 +0100
From: Martin Rubey
To: Antoine Hersen
Subject: Re: Eval in Axiom/Aldor

Dear Antoine,

great to see you here!

Antoine Hersen writes:

>     test(a:Fraction UnivariatePolynomial(x,F)):Fraction
> UnivariatePolynomial(x,F) == {
>         eval(a, x, 1)
>     }


I also had problems with that. In general, I think it is better to avoid UP
whenever possible and use SUP instead.

For your problem, one workaround is to use elt instead:

     test(a:Fraction UnivariatePolynomial(x,F)):Fraction
 UnivariatePolynomial(x,F) == elt(a, 1)

(Note that 1 refers to a Fraction UP here...)



I can only guess why 

 eval : (%,Symbol,UnivariatePolynomial(x,Integer)) -> %

does not work: it seems that it is not implemented. "Fraction" takes it from
"QuotientFieldCategory", which exports it unconditionally:

QuotientFieldCategory(S: IntegralDomain): Category ==
  Join(Field, Algebra S, RetractableTo S, FullyEvalableOver S,
         DifferentialExtension S, FullyLinearlyExplicitRingOver S,
           Patternable S, FullyPatternMatchable S)

However, "QuotientFieldCategory" doesn't provide a default definition... I
guess this should be reported on issueTracker. Currently I don't have the time
to check this more thoroughly, it would be interesting to see whether the
compiler issues a warning when compiling "Fraction".


In any case, the fix is probably very easy, since QuotientFieldCategory has
numer and denom. However, we should to check which definitions of "eval" should
be provided. There are so many defaults...

\start
Date: Tue, 14 Nov 2006 15:43:54 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: New branch?

I consider starting a new branch.  I feel that Axiom needs a period
of faster developement, in particular removing and/or cleaning old
code.

General directions:
-- generate all information that can be generated (documentation,
   images, databases)
-- remove unused code (both old and new but unfinished)
-- rework file handling (current code is buggy, complicated and
   inefficient)
-- improve SPAD compiler

My goals partially overlap with goals of build-improvements, but
I reached a point where I need deeper changes (including compiler)
to support better build.  Also, unused/needlessy complicated code
makes changes and understanding harder, so I think that cleanups
and removals should be done quickly -- accepting risks of 
temporary breakage.

\start
Date: Tue, 14 Nov 2006 10:22:04 -0500
From: Bill Page
To: Waldek Hebisch
Subject: RE: New branch?

On November 14, 2006 9:44 AM Waldek Hebisch wrote:
> 
> I consider starting a new branch.  I feel that Axiom needs a
> period of faster developement, in particular removing and/or
> cleaning old code.
> 

Great!

> General directions:
> -- generate all information that can be generated (documentation,
>    images, databases)
> -- remove unused code (both old and new but unfinished)
> -- rework file handling (current code is buggy, complicated and
>    inefficient)
> -- improve SPAD compiler
> 
> My goals partially overlap with goals of build-improvements,
> but I reached a point where I need deeper changes (including
> compiler) to support better build.  Also, unused/needlessy
> complicated code makes changes and understanding harder, so
> I think that cleanups and removals should be done quickly --
> accepting risks of temporary breakage.
> 

I agree.

There are at least two other possible branches that we should
consider:

  - documentation improvements branch (Ralf?)
  - hyperdoc improvements branch

However for each such branch I think we need someone to take
primary responsibility. Is there anyone sufficiently strongly
motivated to take on the task of hyperdoc improvements?

\start
Date: 14 Nov 2006 16:25:53 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: New branch?

Waldek Hebisch writes:

| I consider starting a new branch.  I feel that Axiom needs a period
| of faster developement, in particular removing and/or cleaning old
| code.
| 
| General directions:
| -- generate all information that can be generated (documentation,
|    images, databases)
| -- remove unused code (both old and new but unfinished)
| -- rework file handling (current code is buggy, complicated and
|    inefficient)
| -- improve SPAD compiler
| 
| My goals partially overlap with goals of build-improvements, but
| I reached a point where I need deeper changes (including compiler)
| to support better build.  Also, unused/needlessy complicated code
| makes changes and understanding harder, so I think that cleanups
| and removals should be done quickly -- accepting risks of 
| temporary breakage.

>From my priority list, "improve SPAD compiler" has a strong list.
I do hope there is no duplicate effort there.  Yesterday, I was
considerig gdr-sandbox from build-improvements, but maybe we should
just work on compiler-improvements branch and deal with the merges?

As for the databse, I have strong feeling that we should not
underestimate the work done by the dynamic libraries community. 

\start
Date: Tue, 14 Nov 2006 16:40:42 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: New branch?

> There are at least two other possible branches that we should
> consider:
> 
>   - documentation improvements branch (Ralf?)
>   - hyperdoc improvements branch
> 
> However for each such branch I think we need someone to take
> primary responsibility.

I would take responsibility in the documentation improvements, but I 
will not start immediately. Anyway, I indend to introduce just a new 
directory and leave all .pamphlet files untouched in the first approach.
This way it is probably easier to integrate documentation improvements 
into both silver and build-improvements.

I actually would feel better if build-improvements is finished first and 
becomes silver, before I start branching from one of them.
Tim, Gaby, when do you expect the build-improvements branch to be merged 
back to silver?

\start
Date: Tue, 14 Nov 2006 11:16:32 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: New branch?

> I actually would feel better if build-improvements is finished first and 
> becomes silver, before I start branching from one of them.
> Tim, Gaby, when do you expect the build-improvements branch to be merged 
> back to silver?

All responsibility for silver/gold/release is now a community effort.
It's up to everyone to decide what, when, and how things should happen.
I'm working on several subtasks that are not yet ready for release
so I have no changes to promote.

\start
Date: Tue, 14 Nov 2006 11:29:55 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: FW: data structure vs. mathematical structure (was: Graph theory)

> Bill Page writes:
> | > | All domains that have SetCategory are required to have a
> | > | hash| into SmallInteger.
> | >
> | Gaby wrote:
> | > That is not a mathematical requirement.
> |
> Bill Page wrote;
> | I would tend to agree but perhaps Kurt G=F6del would not have...
> | ;-)
>

On November 14, 2006 12:01 AM Gaby wrote:

> From constructive mathematics point of view, the only things
> that are required for a set are:
>
>   (1) say how to build element of a set
>   (2) equality test.
>

No, there is a lot more to the mathematics of set than that. It
would mean that all sets are finite and that is quite far from
the case. Rather, sets should be strongly related to types.

I think the "constructive mathematics" that is most suitable
to Axiom is probably is probably Intuitionist type theory
(Martin-L=F6f). See:

http://en.wikipedia.org/wiki/Constructive_type_theory

"A logical framework, such as Martin-L=F6f's takes the form of
closure conditions on the context dependent sets of types and
terms: that there should be a type called Set, and for each set
a type, that the types should be closed under forms of dependent
sum and product, and so forth."

In Axiom types are implemented as domains or categories. So this
means that for examle the set

  {1,2,3}

should not be considered as just member of the domain Set, but
rather it should denote a *domain* which has as members the
Integers 1, 2 and 3 in other words a sub-domain of Integer (or
PositiveInteger, NNI, etc.). And Integer itself can be viewed
as a set.

As a domain constructor Set(T) is best viewed as a "powerset"
type, i.e. the type associated with all subsets of a given type
T.

Axiom (SPAD) does have a "subdomain" construction which is used
for example to define NonNegativeInteger and PositiveInteger
from the type Integer. This is one of the less developed ideas
in Axiom but I think this is exactly the place where computer
algebra meets proof theory and is therefore ripe for further
development.

\start
Date: Tue, 14 Nov 2006 17:43:27 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: New branch?

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | I consider starting a new branch.  I feel that Axiom needs a period
> | of faster developement, in particular removing and/or cleaning old
> | code.
> | 
> | General directions:
> | -- generate all information that can be generated (documentation,
> |    images, databases)
> | -- remove unused code (both old and new but unfinished)
> | -- rework file handling (current code is buggy, complicated and
> |    inefficient)
> | -- improve SPAD compiler
> | 
> | My goals partially overlap with goals of build-improvements, but
> | I reached a point where I need deeper changes (including compiler)
> | to support better build.  Also, unused/needlessy complicated code
> | makes changes and understanding harder, so I think that cleanups
> | and removals should be done quickly -- accepting risks of 
> | temporary breakage.
> 
> >From my priority list, "improve SPAD compiler" has a strong list.
> I do hope there is no duplicate effort there.  Yesterday, I was
> considerig gdr-sandbox from build-improvements, but maybe we should
> just work on compiler-improvements branch and deal with the merges?
> 

My curent plan for the compiler is as follows: parse all the algebra
files and invoke a new mini-compiler on the result. In the first stage
this new compiler should just collect declarations and emit 
databases.  Besides direct benefits this is intened to verify my
understandig of abstract syntax and typechecking of SPAD. In the
next stages the new compiler should act as a pre-pass for current
SPAD compiler, incrementally taking more and more responsibilities.

However, I think that before making such changes I need preparations
(cleanups, helper variables and routines ...).  Here I would like
to go fast forward -- the whole thing is experimental and if 
something fails it is better if it fails quickly.  

Concerning compiler-improvements branch: If you think about merging
changes for private branches I would think that first we need some
real working code to merge.

> As for the databse, I have strong feeling that we should not
> underestimate the work done by the dynamic libraries community. 

Could you elaborate: I feel that I have adequate understanding
of dynamic code generation and linking but maybe I am missing
something?

\start
Date: Tue, 14 Nov 2006 13:14:46 -0400
From: Humberto Zuazaga
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire, Gabriel Dos Reis

Humberto Ortiz-Zuazaga wrote:

>> | I built --without-noweb --with-gcl, the configure for the built in gcl
>> | isn't working right.

I think I tracked down the problem. In build-improvements, on the Mac, 
the configure for gcl was being called with a broken --enable-machine 
flag, and the subsequent make would fail.

I think this patch to configure.ac.pamphlet fixes it.

I also incorporated other suggested changes to the configure flags:

1) we should use locbfd instead of custreloc

2) we don't need X Window system support or xgcl

With these changes a full build of noweb, gcl and axiom work on my 
PowerPC Mac OS X 10.4.8 machine with the following steps:

# remove fink /sw/bin from the path
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
./configure --without-noweb --without-gcl
make

-- 
Humberto Ortiz-Zuazaga
Programmer-Archaeologist
UPR Bioinformatics Resource Center
http://www.hpcf.upr.edu/~humberto/

--------------060705010106010306030309
	name="mac-configure.patch"
 filename="mac-configure.patch"

--- build-improvements/configure.ac.pamphlet	2006-11-11 18:33:41.000000000 -0400
+++ test/configure.ac.pamphlet	2006-11-14 13:00:04.000000000 -0400
@@ -504,13 +504,14 @@
     *solaris*)
         PLF=SUNplatform
 	;;
-    *darwin*)
+    powerpc*darwin*)
         PLF=MACOSXplatform
 	CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} \
 	    -I/usr/include -I/usr/include/sys"
-	GCLOPTS="--enable-vssize=65536*2 --enable-maxpage=256*1024 --disable-locbfd \
-	    --disable-statsysbfd  --enable-custreloc --disable-tkconfig \
-	    --enable-machine=pwerpc-macosx"
+	GCLOPTS="--enable-vssize=65536*2 --enable-maxpage=256*1024 --enable-locbfd \
+	    --disable-statsysbfd  --disable-tkconfig \
+	    --disable-x --disable-xgcl \
+	    --enable-machine=powerpc-macosx"
 	;;
 esac
 

\start
Date: Tue, 14 Nov 2006 11:18:34 -0600 (CST)
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

On Tue, 14 Nov 2006, Humberto Ortiz Zuazaga wrote:

| Humberto Ortiz-Zuazaga wrote:
|
| >> | I built --without-noweb --with-gcl, the configure for the built in gcl
| >> | isn't working right.
|
| I think I tracked down the problem. In build-improvements, on the Mac,
| the configure for gcl was being called with a broken --enable-machine
| flag, and the subsequent make would fail.
|
| I think this patch to configure.ac.pamphlet fixes it.
|
| I also incorporated other suggested changes to the configure flags:
|
| 1) we should use locbfd instead of custreloc
|
| 2) we don't need X Window system support or xgcl
|
| With these changes a full build of noweb, gcl and axiom work on my
| PowerPC Mac OS X 10.4.8 machine with the following steps:
|
| # remove fink /sw/bin from the path
| PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
| ./configure --without-noweb --without-gcl
| make

This is great!  We should disable xgcl for all of the targets.
Could your update your patch accordingly and commit?
I can do it but not now (unfortunately).

\start
Date: Tue, 14 Nov 2006 19:12:56 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: Re: FW: data structure vs. mathematical structure (was: Graph theory)

Le lundi 13 novembre 2006 =E0 21:39 -0500, Bill Page a =E9crit :

[...]

> > Oh, don't believe that I don't see data structures as
> > mathematical structures. They are. But I rather have the feeling
> > that for efficiency reasons it is desirable to have some basic
> > data structures underlying the mathematics where one can say
> > something about the complexity of the functions.
>
> Axiom actually has a very specific notion of what it means for
> one mathematical structure to underly another - representation.
> In Axiom domains have an associated internal representation, Rep.
> The domain Rep is given in terms of domain constructors (such as
> Record) applied to other previously defined domains. Then members
> of the new domain % are mapped into Rep via the rep operator and
> from Rep into % by the per operator. The exported operations of
> % are defined in terms of the "underlying" operations in Rep.

>From my point of view, Axiom has no real notion of what is Rep.
If I restrict me to Spad since I do not really use Aldor (it's not free) =
even
if the compiler has a notion of Rep it's just a "conventional" notation. =
If you
play with an element of type Rep you "package call" function. Of course i=
f the
compiler know its type it's not necessary. You can hide this representati=
on,
see for example the Integer domain but you can have more than one represe=
ntation
too. My experimentation on this:

http://wiki.axiom-developer.org/LispsFractionIntegerDomain

This is an experimentation, in particular I played in what I call the "da=
rk side".
I do not like this experimentation, in the Axiom world (more below).

[...]

> > Example. You want to implement quicksort. Would someone choose
> > lists to do that instead of arrays?
>
> In Axiom this is not really an appropriate question. quicksort
> would be implemented in a generic manner so that it can be applied
> to any domain that provides the necessary methods. In fact in the
> Axiom book contains exactly this example (bubble sort actually).

I do not totally agree. Yes it's good to implement default algorithm in
categories but each domain has the possibility to provide its own
implementation and this is a good thing. Do you want, for the
exponentiation of Integers, to use the repeatedSquaring algorithm coded
in Spad ? For me it's an important question.

[...]

> > Why does Axiom have distributed and recursive polynomials.
> > Mathematically it's the same thing, so why bother?
>
> This may not be such a good example since I think the difference
> here is primarily related to how these domains coerce to OutputForm.

I totally disagree :-) This is a good example. I forgot where and
if this is the example used in the Axiom book but the authors insisted
on this point. I do not think this is related only to the coercion to Out=
putForm.
Just an example, if you want to implement sparse matrix you'll inherit op=
eration
from MatrixCategory, but you'll have to provide your own implementation t=
o
access each element (the *elt* family). After that it'll be possible to u=
se
the matrix multiplication algorithm implemented in MatrixCategory. The
representation problem is for me is important. I'm not a specialist of th=
e
Polynomial domains/categories in Axiom (which are, I think, the most deve=
loped
areas in Axiom) so I can not argue about this, but some
algorithms depends intimately on the internal representation used.


> > I hope you get somehow the feeling what I meant when I said
> > that I care for data structures of graphs. We all know that
> > some representation is better than the other for certain
> > algorithms.
> >
>
> Yes that is true and I agree that it is an important issue.

Yes :-) But even for the question of implementing generic things. You hav=
e
to choose a category or create a new one. You can use a general category =
but
you can choose a more specialised category expressively defined (definiti=
on in the usual
sense for example in the documentation) to handle efficiently what you ar=
e
trying to do. I'm not a fan of performance and, in another mail, I said t=
hat
Axiom need to be able to compile to object code. I'm not against compilin=
g to
bytecode, but sometimes it's necessary to have optimised code.

I'm, when I say that, in the "dark side" of Axiom. A lot of
algorithm (I do not speak about Polynomials) in Axiom are extremely gener=
al
and I love that but... some of them from my point of view need to be spec=
ialised
in the sense that another implementation need to be added in the domains
(this is the "dark side").

It seems to me that the authors of Axiom were sometimes too general proba=
bly
by lack of time but sometimes I'm asking if in fact, no, "they did not wa=
nt to
specialise the code" they wanted to have the more general algorithm possi=
ble
(which is necesssary too :-)).

It's a pity that, for example, Manuel Bronstein did not
implement modular algorithm for computation of determinant of matrices
(since I know it worked on this) or any other specialised thing.
I have some difficulties to express what I think, this is somewhat
a philosophical question :-) :  do we want sometimes to restrict the gene=
rality of an
operation (and restrict the user to use what we think it has to use) ?
For example quickSort is implemented for FiniteLinearAggregate and I'm
happy with that, but do you want to apply this operation on a big list ?

Hmm... I'm pretty sure you'll not understand me...

Greg

PS: the Lisp's fraction integer specialisation is not a good example of w=
hat I think !!!
(it opens some questions on the architecture of Axiom though).
PS2: I love how Axiom and Mupad (it's no longer free :-() are, conceptual=
ly, implemented.

\start
Date: 14 Nov 2006 19:19:32 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: FW: data structure vs. mathematical structure (was: Graph theory)

Bill Page writes:

| > Bill Page writes:
| > | > | All domains that have SetCategory are required to have a
| > | > | hash| into SmallInteger.
| > | >
| > | Gaby wrote:
| > | > That is not a mathematical requirement.
| > |
| > Bill Page wrote;
| > | I would tend to agree but perhaps Kurt G=F6del would not have...
| > | ;-)
| >
|
| On November 14, 2006 12:01 AM Gaby wrote:
|
| > From constructive mathematics point of view, the only things
| > that are required for a set are:
| >
| >   (1) say how to build element of a set
| >   (2) equality test.
| >
|
| No, there is a lot more to the mathematics of set than that. It
| would mean that all sets are finite and that is quite far from
| the case.

How do you arrive to that conclusion?

| Rather, sets should be strongly related to types.
|
| I think the "constructive mathematics" that is most suitable
| to Axiom is probably is probably Intuitionist type theory
| (Martin-L=F6f). See:

In fact, I prefer the definition given by Erret Bishop.  See chapters 1
and 2 "his" book

   "Constructive Analysis",

       Erret Bishop
       Douglas Bridges


>From my perspective, it shows a much deeper impact.

\start
Date: Tue, 14 Nov 2006 21:20:54 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: src/hyper/Makefile.in

Gaby,

You applied change in version 259 only to Makefile.in (Makefile.pamphlet
stayed unchanged).

\start
Date: 14 Nov 2006 21:49:57 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: src/hyper/Makefile.in

Waldek Hebisch writes:

| Gaby,
| 
| You applied change in version 259 only to Makefile.in (Makefile.pamphlet
| stayed unchanged).

I'll fix that when I get back to my home computer.  Thanks for the
report.  Ill also create a branch for trying to improve the compiler.
One of my goals is to remove the requirement for ')abbrev' commands, 
"extend", and better dependent types.

If we have post facto extensions, I believe we can significantly
reduce the complexity of the bootstrapping process.  I would also like
the interpreter being a kind of Spad algebra over the compiler.  Maybe
that would also give a good way to bnatural, and better surpport for
generic programming (good for Axiom!).

\start
Date: Tue, 14 Nov 2006 22:12:51 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: compiler-improvements (was: src/hyper/Makefile.in)
Cc: Stephen Watt

Hi Gaby,

On 11/14/2006 09:49 PM, Gabriel Dos Reis wrote:

> Ill also create a branch for trying to improve the compiler. One of
> my goals is to remove the requirement for ')abbrev' commands, 
> "extend", and better dependent types.

Oh, good news.

> If we have post facto extensions, I believe we can significantly 
> reduce the complexity of the bootstrapping process.

That would be great. If we have that we can really start cleaning up the 
algebra code.

> I would also like the interpreter being a kind of Spad algebra over
> the compiler.

That is what I wished for so long...

 > Maybe that would also give a good way to bnatural, and
> better surpport for generic programming (good for Axiom!).

It seems that with the speed of Axiom, SPAD is soon becoming the better 
Aldor. AFAIK, there is no move in opening Aldor.

\start
Date: Tue, 14 Nov 2006 16:17:08 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: FW: data structure vs. mathematical structure (was: Graph theory)

On November 14, 2006 12:01 AM Gaby wrote:
> |
> | > From constructive mathematics point of view, the only things
> | > that are required for a set are:
> | >
> | >   (1) say how to build element of a set
> | >   (2) equality test.
> | >
> Bill Page wrote:
> | No, there is a lot more to the mathematics of set than that.
> | It would mean that all sets are finite and that is quite far
> | from the case.

On Tuesday, November 14, 2006 1:20 PM Gaby wrote:
>
> How do you arrive to that conclusion?
>

I thought I was stating something obvious. Are you asking why I
think all sets would be finite if the only operation you require
to form sets is the ability to "build an element"? Ok, maybe there
is also induction so that for example we could define the set of
positive integers (natural numbers) as consisting of the element 1
and the operation +1 that "builds a new element". So depending on
what else you assume about the "environment", I would have to
withdraw my claim of finiteness. But considering complexity issues
in constructing these numbers we would be better off with at least
one more element forming operation - doubling - leading to binary
representation.

However it is not clear to me that there always exists the
possibility to define a set by it's elements. For example is this
possible if we wish to define the set of exact real numbers such
as suggested by your reference below?

> | Rather, sets should be strongly related to types.
> |
> | I think the "constructive mathematics" that is most suitable
> | to Axiom is probably is probably Intuitionist type theory
> | (Martin-L=F6f). See:
>
> In fact, I prefer the definition given by Erret Bishop.  See
> chapters 1 and 2 "his" book
>
>    "Constructive Analysis",
>
>        Erret Bishop
>        Douglas Bridges
>
> From my perspective, it shows a much deeper impact.
>

When it comes to the concept of exact real numbers I think you
are absolutely right but is not clear to me why you would prefer
this text in the context of set theory and Axiom. Can you explain?

Exact reals for Axiom is a subject that we have previously
discussed on this list. See:

http://wiki.axiom-developer.org/RealNumbers

Here is a recent article on this subject.

http://www.cs.ru.nl/~herman/PUBS/exactreals.pdf

by Herman Geuvers et al. http://www.cs.ru.nl/~herman

\start
Date: Tue, 14 Nov 2006 22:39:45 +0100
From: Ralf Hemmecke
To: Gregory Vanuxem
Subject: Re: FW: data structure vs. mathematical structure(was: Graph theory)

>>> Why does Axiom have distributed and recursive polynomials. 
>>> Mathematically it's the same thing, so why bother?

>> This may not be such a good example since I think the difference
>> here is primarily related to how these domains coerce to OutputForm.

> I totally disagree :-) This is a good example. I forgot where and
> if this is the example used in the Axiom book but the authors insisted
> on this point. I do not think this is related only to the coercion to OutputForm.
[snip]
> I'm not a specialist of the
> Polynomial domains/categories in Axiom (which are, I think, the most developed
> areas in Axiom) so I can not argue about this, but some
> algorithms depends intimately on the internal representation used.

Think of implementing Buchberger's algorithm for multivariate 
commutative polynomial rings. In order to test whether one polynomial is 
reducible with respect to another, one has to access the exponent vector 
of the leading term. In a distributed format with keeping the terms 
sorted LT(p) would be a O(1) operation. I cannot think of something of 
that complexity for recursive polynomials if the term order is chosen to 
be "degree reverse lexicographical".

\start
Date: Tue, 14 Nov 2006 16:40:39 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: src/hyper/Makefile.in

On Tuesday, November 14, 2006 3:50 PM Gabriel Dos Reis wrote:

> ... Ill also create a branch for trying to improve the compiler.
> One of my goals is to remove the requirement for ')abbrev'
> commands,  "extend", and better dependent types.
>
> If we have post facto extensions, I believe we can significantly
> reduce the complexity of the bootstrapping process.

My number one wish for improving the *SPAD* compiler is:

   Better compiler error messages!

For me, this is the number one reason for strongly prefering Aldor.
In fact without starting in Aldor first, I still find it very
difficult to write fluently in SPAD.

The number two reason only being language features such as fully
supported dependent types and extend.

> I would also like the interpreter being a kind of Spad algebra
> over the compiler. Maybe that would also give a good way to
> bnatural, and better support for generic programming (good for
> Axiom!).
>

If by "Spad algebra over the compiler" you mean: implementing the
interpreter in SPAD rather than Boot and Lisp, then I think this
was clearly the original intention of (at least some of) the Axiom
developers. Boot is really a kind of pre-SPAD.

Finally "better support for generic programming" sounds a little
frightening to me, but I can't think of anyone better suited to
do this than you, Gaby. :-)

\start
Date: Tue, 14 Nov 2006 23:03:26 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: FW: data structure vs. mathematical structure

On 11/14/2006 10:17 PM, Page, Bill wrote:
> On November 14, 2006 12:01 AM Gaby wrote:
>> | 
>> | > From constructive mathematics point of view, the only things
>> | > that are required for a set are:
>> | > 
>> | >   (1) say how to build element of a set
>> | >   (2) equality test.
>> | > 
>> Bill Page wrote: 
>> | No, there is a lot more to the mathematics of set than that.
>> | It would mean that all sets are finite and that is quite far
>> | from the case.
> 
> On Tuesday, November 14, 2006 1:20 PM Gaby wrote:
>> How do you arrive to that conclusion?

> I thought I was stating something obvious.

I remember I said that "Set" is somehow a bad name for a domain in Axiom 
that only implements "(the collection of) finite sets of elements of a 
given type T".

Or (from sets.spad):

++ A set over a domain D models the usual mathematical notion of a
++ finite set of elements from D.

Although

i: Integer

and

s: FinitePowerSet T

would be in perfect analogy if one read ":" as "element of", then to go 
on "l: List T" would mean "List" is the container of all finite 
sequences (with some information about their representation (linked 
list)). It's soon getting confusing. So I would rather choose 
"FiniteSet". But then (except proper classes) everything is a set. Why 
would one need a domain of sets? "SetCategory" is more important.

And in Axiom it is an approximation anyway, since it is Set(T), ie a 
collection of things of a common type T. The name "Set" is probably an 
exception one could accept.

\start
Date: Tue, 14 Nov 2006 17:13:34 -0500
From: Bill Page
To: Ralf Hemmecke, Gregory Vanuxem
Subject: RE: FW: data structure vs. mathematical structure (was: Graph theory)

On Tuesday, November 14, 2006 4:40 PM Ralf Hemmecke wrote:
> Cc: Bill Page; list
> Subject: Re: FW: data structure vs. mathematical structure
> (was: Graph theory)
>
> >>> Why does Axiom have distributed and recursive polynomials.
> >>> Mathematically it's the same thing, so why bother?
> >
> > Bill Page wrote:
> >> This may not be such a good example since I think the
> >> difference here is primarily related to how these domains
> >> coerce to OutputForm.
>
> Vanuxem Gr=E9gory wrote:
> > I totally disagree :-) This is a good example. I forgot where
> > and if this is the example used in the Axiom book but the
> > authors insisted on this point. I do not think this is related
> > only to the coercion to OutputForm.

My statement about recursive polynomials in Axiom was incorrect.

> [snip]
> > I'm not a specialist of the Polynomial domains/categories in
> > Axiom (which are, I think, the most developed areas in Axiom)
> > so I can not argue about this, but some algorithms depends
> > intimately on the internal representation used.
>
> Think of implementing Buchberger's algorithm for multivariate
> commutative polynomial rings. In order to test whether one
> polynomial is reducible with respect to another, one has to
> access the exponent vector of the leading term. In a distributed
> format with keeping the terms sorted LT(p) would be a O(1)
> operation. I cannot think of something of that complexity for
> recursive polynomials if the term order is chosen to be "degree
> reverse lexicographical".
>

Ralf and Greg are correct. Notice in particular the different
representations below:

Compare

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/GdpolySpad

)abbrev domain GDMP GeneralDistributedMultivariatePolynomial
++ Author: Barry Trager
...
++ Description:
++   This type supports distributed multivariate polynomials
++ whose variables are from a user specified list of symbols.
++ The coefficient ring may be non commutative,
++ but the variables are assumed to commute.
++ The term ordering is specified by its third parameter.
++ Suggested types which define term orderings include: =
\spadtype{DirectProduct},
++ \spadtype{HomogeneousDirectProduct}, =
\spadtype{SplitHomogeneousDirectProduct}
++ and finally \spadtype{OrderedDirectProduct} which accepts an =
arbitrary user
++ function to define a term ordering.

GeneralDistributedMultivariatePolynomial(vl,R,E): public == private =
where
  vl: List Symbol
  R: Ring
  E: DirectProductCategory(#vl,NonNegativeInteger)
  OV  ==> OrderedVariableList(vl)
  SUP ==> SparseUnivariatePolynomial
  NNI ==> NonNegativeInteger

  public == PolynomialCategory(R,E,OV) with
      reorder: (%,List Integer) -> %
        ++ reorder(p, perm) applies the permutation perm to the =
variables
        ++ in a polynomial and returns the new correctly ordered =
polynomial

  private == PolynomialRing(R,E) add
    --representations
      Term := Record(k:E,c:R)
      Rep := List Term
...

and

http://wiki.axiom-developer.org/images/axiom--test--1/src/algebra/multpol=
y.spad.pamphlet

)abbrev domain SMP SparseMultivariatePolynomial
++ Author: Dave Barton, Barry Trager
...
++ Description:
++   This type is the basic representation of sparse recursive =
multivariate
++ polynomials. It is parameterized by the coefficient ring and the
++ variable set which may be infinite. The variable ordering is =
determined
++ by the variable set parameter. The coefficient ring may be =
non-commutative,
++ but the variables are assumed to commute.

SparseMultivariatePolynomial(R: Ring,VarSet: OrderedSet): C == T =
where
  pgcd ==> PolynomialGcdPackage(IndexedExponents VarSet,VarSet,R,%)
  C == PolynomialCategory(R,IndexedExponents(VarSet),VarSet)
  SUP ==> SparseUnivariatePolynomial
  T == add
    --constants
    --D := F(%) replaced by next line until compiler support completed

    --representations
      D := SparseUnivariatePolynomial(%)
      VPoly:=  Record(v:VarSet,ts:D)
      Rep:=  Union(R,VPoly)
...

\start
Date: Tue, 14 Nov 2006 15:13:11 -0800
From: Richard Harke
To: Camm Maguire
Subject: Re: Axiom ia64

On Mon November 13 2006 07:29, Camm Maguire wrote:

> If anyone would like to help getting bfd support for ia64 and friends,
> please look at sfaslbfd_alpha.c and sfaslbfd_mips.c from the HEAD cvs
> tree.  This should serve as an example for the needed sfaslbfd_ia64.c
>
>
> Take care,
Do the versions for mips and alpha work? Tested?
What is the relation of HEAD to 2.6.8pre?
I have taken a brief look at this and am considering taking it on.

\start
Date: Tue, 14 Nov 2006 15:19:31 -0800
From: Antoine Hersen
To: Martin Rubey
Subject: Re: Eval in Axiom/Aldor

Hello,

I get nasty FOAM run time error with Ralf solution( I used it in a
more involved context)

And I cant compile Martin one, maybe I should not assume that a Field
is an INTDOM ...

On 14 Nov 2006 09:18:48 +0100, Martin Rubey wrote:
> Dear Antoine,
>
> great to see you here!
>
> Antoine Hersen writes:
>
> >     test(a:Fraction UnivariatePolynomial(x,F)):Fraction
> > UnivariatePolynomial(x,F) == {
> >         eval(a, x, 1)
> >     }
>
>
> I also had problems with that. In general, I think it is better to avoid UP
> whenever possible and use SUP instead.
>
> For your problem, one workaround is to use elt instead:
>
>      test(a:Fraction UnivariatePolynomial(x,F)):Fraction
>  UnivariatePolynomial(x,F) == elt(a, 1)
>
> (Note that 1 refers to a Fraction UP here...)
>
>
>
> I can only guess why
>
>  eval : (%,Symbol,UnivariatePolynomial(x,Integer)) -> %
>
> does not work: it seems that it is not implemented. "Fraction" takes it from
> "QuotientFieldCategory", which exports it unconditionally:
>
> QuotientFieldCategory(S: IntegralDomain): Category ==
>   Join(Field, Algebra S, RetractableTo S, FullyEvalableOver S,
>          DifferentialExtension S, FullyLinearlyExplicitRingOver S,
>            Patternable S, FullyPatternMatchable S)
>
> However, "QuotientFieldCategory" doesn't provide a default definition... I
> guess this should be reported on issueTracker. Currently I don't have the time
> to check this more thoroughly, it would be interesting to see whether the
> compiler issues a warning when compiling "Fraction".
>
>
> In any case, the fix is probably very easy, since QuotientFieldCategory has
> numer and denom. However, we should to check which definitions of "eval" should
> be provided. There are so many defaults...

\start
Date: Tue, 14 Nov 2006 18:44:16 -0500
From: Bill Page
To: Franz Huber
Subject: RE: [TeXmacs] WinTeXmacs - Axiom problems

On Friday, November 10, 2006 7:19 AM Franz wrote:
>
> I=B4m a WinTeXmacs user since a few days, and I=B4m using (and
> needing) it only as a frontend for Axiom (latest versions:
> Axiom 0.1.4 and WinTeXmacs 1.0.5).
>
> First I had big problems to start an Axiom session at all (I
> always got the error message "Could not create pipe" in
> WinTeXmacs), until I found the reason for this problem after
> quite a lot of trials:
> The line =B4(:launch "tm_axiom")=B4 of the file =B4init-axiom.scm=B4
> in the folder
> =B4...\WinTeXmacs\TeXmacs\plugins\axiom\progs\init-axiom.scm=B4
> doesn=B4t work!
> When I insert a space after =B4tm_axiom=B4, then it works - so
> this line shoud be:
> (:launch "tm_axiom ")
>
> Ok, at least Axiom is now =B4running=B4 under WinTeXmacs as a
> session, but it is not =B4working=B4, at least not correctly!
> There are 2 main problems I=B4ve found yet:
>
> 1) Since Axiom uses a space (=B4 =B4) instead of a multiplication
> character (=B4*=B4) in the output, such expressions are displayed
> terribly in WinTexmacs.
> Trying e.g. "factor(15)" displays "35" in WinTeXmacs, where
> of course there actually IS a space between 3 and 5, but you
> can=B4t see it (since this space is too small)!
> This problem is even more dramatically for variables:
> Entering e.g. "x*y-xy" gives the result "xy-xy" ...
>
> 2) Even correctly formatted results from Axiom are displayed
> wrong in WinTeXmacs - here=B4s only one example:
> Entering "xy/y" gives the following output:
>  y
> x-
>  y
>
> (If that=B4s not correctly displayed here, it=B4s a "x"
> immediately followed by a fraction "y/y")
> Here WinTeXmacs seem to interpret "xy" as if it would be "x
> y", although Axiom is correctly returning a TeX expression
> =B4xy \over y=B4!
>
> So only these 2 problems are absolutely enough, to not trust
> any WinTeXmacs output of Axiom results at all - maybe you can
> imagine, what terribly wrong =B4results=B4 would happen for more
> complicated expressions ...
>
> Is there any way to solve these problems?
> Or is there a newer version of the Axiom-WinTeXmacs interface
> (tm_axiom) available, where these bugs have been fixed?
>
> Well, I hope so - otherwise we can simply forget using Axiom
> as a WinTeXmacs session ... :-(
>

I presume that you are aware of the following page on the Axiom
Wiki?

http://wiki.axiom-developer.org/TeXmacs

If you installed Axiom-0.1.4 after WinTeXmacs (and therefore the
Axiom programs appear before any other in the PATH) then you should
be using a modified version of tm_axiom distributed with Axiom (see
info on above web page). In that case, setting the following options
at the top of your TeXmacs document might help:

  )set output texmacs over no
  )set output texmacs space yes

You can also set these are default by creating an environment
variable

  TM_AXIOM='over no, space yes'

If you have problems with the Axiom verison of tm_axiom then you
can also report them here:

http://wiki.axiom-developer.org/IssueTracker

or on the Axiomm Developer list

  list

BTW: Welcome to Axiom. :-) We are actively looking for people to do
Axiom development on Windows. Please drop in if you are interested.

\start
Date: 15 Nov 2006 02:26:28 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: FW: data structure vs. mathematical structure (was: Graph theory)

Bill Page writes:

| On November 14, 2006 12:01 AM Gaby wrote:
| > |
| > | > From constructive mathematics point of view, the only things
| > | > that are required for a set are:
| > | >
| > | >   (1) say how to build element of a set
| > | >   (2) equality test.
| > | >
| > Bill Page wrote:
| > | No, there is a lot more to the mathematics of set than that.
| > | It would mean that all sets are finite and that is quite far
| > | from the case.
|
| On Tuesday, November 14, 2006 1:20 PM Gaby wrote:
| >
| > How do you arrive to that conclusion?
| >
|
| I thought I was stating something obvious. Are you asking why I
| think all sets would be finite if the only operation you require
| to form sets is the ability to "build an element"?

Why all sets would be finite.  I hoenestly don't see how it is obvious.

| Ok, maybe there
| is also induction so that for example we could define the set of
| positive integers (natural numbers) as consisting of the element 1
| and the operation +1 that "builds a new element". So depending on
| what else you assume about the "environment", I would have to
| withdraw my claim of finiteness. But considering complexity issues
| in constructing these numbers we would be better off with at least
| one more element forming operation - doubling - leading to binary
| representation.
|
| However it is not clear to me that there always exists the
| possibility to define a set by it's elements. For example is this
| possible if we wish to define the set of exact real numbers such
| as suggested by your reference below?
|
| > | Rather, sets should be strongly related to types.
| > |
| > | I think the "constructive mathematics" that is most suitable
| > | to Axiom is probably is probably Intuitionist type theory
| > | (Martin-L=F6f). See:
| >
| > In fact, I prefer the definition given by Erret Bishop.  See
| > chapters 1 and 2 "his" book
| >
| >    "Constructive Analysis",
| >
| >        Erret Bishop
| >        Douglas Bridges
| >
| > From my perspective, it shows a much deeper impact.
| >
|
| When it comes to the concept of exact real numbers I think you
| are absolutely right but is not clear to me why you would prefer
| this text in the context of set theory and Axiom. Can you explain?

I don't think Bishop is dealing with exact realy numbers, as opposed
to constructive mathametics -- with analysis as an example.
I don't believe Axiom has a clear constructive notion of set theory,
so I'm not preferring anything.  I'm just ignoring what Axiom does :-)
Reflecting my view that the requirement of "hash" is non-mathematical.

| Exact reals for Axiom is a subject that we have previously
| discussed on this list. See:
|
| http://wiki.axiom-developer.org/RealNumbers
|
| Here is a recent article on this subject.
|
| http://www.cs.ru.nl/~herman/PUBS/exactreals.pdf
|
| by Herman Geuvers et al. http://www.cs.ru.nl/~herman

Thanks, I'll have a deeper look.

\start
Date: 15 Nov 2006 02:29:39 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: FW: data structure vs. mathematical structure

Ralf Hemmecke writes:

[...]

| ++ A set over a domain D models the usual mathematical notion of a
| ++ finite set of elements from D.
| 
| Although
| 
| i: Integer
| 
| and
| 
| s: FinitePowerSet T
| 
| would be in perfect analogy if one read ":" as "element of", then to
| go on "l: List T" would mean "List" is the container of all finite
| sequences (with some information about their representation (linked
| list)).

And that would match the usual definition of List as the least fixed
point of the functor

     X |-> 1 + X

in CPO.

However, the existence of 1.. in Axiom would suggest that actually
some people think of List as the greatest fixed point.

\start
Date: Wed, 15 Nov 2006 03:07:14 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Typo in shoe description

Index: src/boot/Makefile.pamphlet
===================================================================
--- src/boot/Makefile.pamphlet	(wersja 259)
+++ src/boot/Makefile.pamphlet	(kopia robocza)
@@ -241,7 +241,7 @@
             ^            NOT
             ^=           NE
             ..           SEG
-            #            LENGHT
+            #            LENGTH
             =>           EXIT
             :=           BEC
             ==           DEF

\start
Date: 14 Nov 2006 21:43:36 -0500
From: Camm Maguire
To: Richard Harke
Subject: Re: Axiom ia64

Richard Harke writes:

> On Mon November 13 2006 07:29, Camm Maguire wrote:
> 
> > If anyone would like to help getting bfd support for ia64 and friends,
> > please look at sfaslbfd_alpha.c and sfaslbfd_mips.c from the HEAD cvs
> > tree.  This should serve as an example for the needed sfaslbfd_ia64.c
> >
> >
> > Take care,
> Do the versions for mips and alpha work? Tested?

Yes.  Essentially once this code can load a few .o files, it can load
any of them.  The self build of gclcvs on the Debian autobuilders
works the code heavily.

> What is the relation of HEAD to 2.6.8pre?

HEAD is 2.7.0, the active development version, where new features are
added and ansi compliance is approached.  When ready, we will release
it as 2.8.0, following the Linux kernel numbering scheme.  2.6.x is
the stable branch, critical bug fix only (more or less), for maxima,
acl2, axiom, hol88 and nqthm support.

> I have taken a brief look at this and am considering taking it on.
> 

This would be most appreciated, and I'd be happy to lend assistance.
Knowledge of the ia64 reloc definitions is obviously key, though I put
together the alpha version mostly as a guesswork based on the mips
example.  If ia64 were done, we could also share with the lush
project, on which the original sfaslbfd_mips was inspired.  And
someday it would be great to get this back into bfd upstream.

The basic idea is that each section of the .o file has a got table
appended to handle the relocs that refer to the special gp register
value.

\start
Date: 14 Nov 2006 21:48:57 -0500
From: Camm Maguire
To: Waldek Hebisch
Subject: Re: Axiom ia64
Cc: Gabriel Dos Reis

Greetings!

Waldek Hebisch writes:

> Camm Maguire wrote:
> > At present, there are 5 platforms in gcl-2.6.x (hppa, ia64, alpha,
> > mips, and mipsel) and 2 platforms on gcl-2.7.x (hppa and ia64) which
> > cannot natively relocate compiled object files.  This means that (load
> > "foo.o")(si::save-system "bar") will give garbage in bar (perhaps in
> > should simple be an error.  This is because loads happen via dlopen
> > and exist outside the heap.  Instead, images must be saved with
> > compiler::link.  Thus, there are some alternate commands which need
> > issuing in the axiom build to make this all work.  These are
> > summarized in the debian/patch.merge file in the debian axiom package.
> > With these commands, axiom builds on all 12 Debian platforms.
> > 
> 
> > +	@ (cd ${MID} ; \
> > +	   echo ')set out le 200' >/tmp/tmp.input ; \
> > +	   echo ')fin' >>/tmp/tmp.input ; \
> > +	   echo "#+native-reloc(make-databases \"\" (QUOTE (\"unix\")))#-native-reloc(system \"cp ${SRC}/../debian/*.daase ${MID}\")" >>/tmp/tmp.input ; \
> > +	   echo '(bye)' >>/tmp/tmp.input ; \
> > +	   cat /tmp/tmp.input | ${INTERPSYS} ; \
> > +	   rm -f /tmp/tmp.input )
> > +#	@ (cp ${SRC}/../debian/*.daase ${MID})
> >  	@ echo If all went well, go-ahead Mike and do a db-install as well !
> 
> I see that you skip database build when native-reloc does not hold.  Did
> you try loading all domain files in interpreted mode?  AFAICS one gets
> the same database and speed is also quite similar.
> 

What a great idea -- no I have not tried this, hoping instead to get
the native relocs working, but this has taken longer than expected.

> BTW.  To load domain files in interpreted mode I just removed .o files (there
> is probably a better way).

It might be possible to rebind si::*load-types* at the right moment.  

\start
Date: 15 Nov 2006 06:07:07 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Typo in shoe description

Waldek Hebisch writes:

| Index: src/boot/Makefile.pamphlet
| ===================================================================
| --- src/boot/Makefile.pamphlet	(wersja 259)
| +++ src/boot/Makefile.pamphlet	(kopia robocza)
| @@ -241,7 +241,7 @@
|              ^            NOT
|              ^=           NE
|              ..           SEG
| -            #            LENGHT
| +            #            LENGTH
|              =>           EXIT
|              :=           BEC
|              ==           DEF

yes, please commit. 
Thanks!

\start
Date: Wed, 15 Nov 2006 01:44:24 -0500
From: Bill Page
To: Antoine Hersen
Subject: RE: Eval in Axiom/Aldor

On Tuesday, November 14, 2006 6:20 PM Antoine Hersen wrote:
>
> I get nasty FOAM run time error with Ralf solution (I used it
> in a more involved context)

Ralf wrote:

> Replace "eval(a, x, 1)" by
>
>     z: SingletonAsOrderedSet := create();
>     eval(numer a, z, 1)/eval(denom a, z, 1);

I don't understand why Ralf introduces a new variable z. But
I think that is the right idea.

According to Axiom:

  )display op eval

There is only one possible 3-argument form of eval that could
apply

   [26] (D,D1,D2) -> D from D
            if D has IEVALAB(D1,D2) and D1 has SETCAT and D2 has TYPE

Thus

    if Fraction UnivariatePolynomial(x, F) has InnerEvalable(Symbol,
Fraction UnivariatePolynomial(x,F)) then {
      test3(a:Fraction UnivariatePolynomial(x,F)):Fraction
UnivariatePolynomial(x,F) == {
        eval(a, x, 1)
      }
    }

compiles but will not work as one might expect because the
condition is false for Fraction UnivariatePolynomial(x, F)

However

  UnivariatePolynomial(x, F) has
InnerEvalable(UnivariatePolynomial(x,F),
  UnivariatePolynomial(x,F))

is true so one way that does work is:

    import from UnivariatePolynomial(x, F);
    import from NonNegativeInteger;

    test1(a:Fraction UnivariatePolynomial(x,F)):Fraction
UnivariatePolynomial(x,F) == {
        eval(numer a, monomial(1$F,1),1)/eval(denom a,
monomial(1$F,1),1)
    };

    -- equivalently
    test(n:UnivariatePolynomial(x,F)):UnivariatePolynomial(x,F) ==
eval(n,monomial(1$F,1),1);
    test2(a:Fraction UnivariatePolynomial(x,F)):Fraction
UnivariatePolynomial(x,F) == {
        map(test, a)
    };

monomial(1$F,1) is just one way to get x in the right form.
(Perhaps Ralf missed this possibility.)

See for example:

http://wiki.axiom-developer.org/SandBox7#msg20061114232755-0600@wiki.axi
om-developer.org

>
> And I cant compile Martin one, maybe I should not assume that
> a Field is an INTDOM ...
>

No it not necessary to assume that a Field is an INTDOM.

I also don't understand Martin's workaround since Fraction does
not export elt with this signature.

However I agree with him that QuotientFieldCategory should probably
provide a default implementation of eval such as I show above and
as it does now for map.

>
> On 14 Nov 2006 09:18:48 +0100, Martin Rubey
> Martin Rubey wrote:
> > Dear Antoine,
> >
> > great to see you here!
> >
> > Antoine Hersen writes:
> >
> > >     test(a:Fraction UnivariatePolynomial(x,F)):Fraction
> > > UnivariatePolynomial(x,F) == {
> > >         eval(a, x, 1)
> > >     }
> >
> >
> > I also had problems with that. In general, I think it is
> > better to avoid UP whenever possible and use SUP instead.
> >
> > For your problem, one workaround is to use elt instead:
> >
> >      test(a:Fraction UnivariatePolynomial(x,F)):Fraction
> >  UnivariatePolynomial(x,F) == elt(a, 1)
> >
> > (Note that 1 refers to a Fraction UP here...)
> >

This gives the error:

  There are no suitable meanings for the operator `elt'

> >
> >
> > I can only guess why
> >
> >  eval : (%,Symbol,UnivariatePolynomial(x,Integer)) -> %
> >
> > does not work: it seems that it is not implemented.
> > "Fraction" takes it from "QuotientFieldCategory", which
> > exports it unconditionally:
> >
> > QuotientFieldCategory(S: IntegralDomain): Category ==
> >   Join(Field, Algebra S, RetractableTo S, FullyEvalableOver S,
> >      DifferentialExtension S, FullyLinearlyExplicitRingOver S,
> >         Patternable S, FullyPatternMatchable S)
> >
> > However, "QuotientFieldCategory" doesn't provide a default
> > definition... I guess this should be reported on issueTracker.
> > Currently I don't have the time to check this more thoroughly,
> > it would be interesting to see whether the compiler issues a
> > warning when compiling "Fraction".
> >
> > In any case, the fix is probably very easy, since
> > QuotientFieldCategory has numer and denom. However, we
> > should check which definitions of "eval" should be provided.
> > There are so many defaults...
> >

\start
Date: Wed, 15 Nov 2006 02:02:02 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: Ping: case insensitive filesystems

Gaby,

Are you willing to give Waldek the "go ahead" to commit the
following patch?

I think this is very important because these naming problems
still prevent svn from being used on both Windows and MAC.

Regards,
Bill Page.

On Tuesday, November 07, 2006 4:24 PM Waldek Hebisch wrote:
> ...
> I propose: rename capital Greek letters according to
> Bill Page proposal.  Adjust 'util.ht' to match (all other
> hypertex pages should access Greek letters only via macros
> defined in 'util.ht'). 
> Next, remove 'ATX=B.bitmap', 'SEGBIND.ps' and 'segbind.ps'.
>
> Those changes should solve problems with duplicate filenames on
> case insensitive filesystems.
>

--- build-improvements.pp/src/hyper/pages/util.ht	2006-11-02
18:27:39.000000000 +0100
+++ build-improvements/src/hyper/pages/util.ht	2006-11-07
22:43:56.499790528 +0100
@@ -240,7 +240,7 @@
 \newcommand{\coprod}{\inputbitmap{\htbmdir{}/coprod.bitmap}}
 \newcommand{\del}{\inputbitmap{\htbmdir{}/del.bitmap}}
 \newcommand{\delta}{\inputbitmap{\htbmdir{}/delta.bitmap}}
-\newcommand{\Delta}{\inputbitmap{\htbmdir{}/Delta.bitmap}}
+\newcommand{\Delta}{\inputbitmap{\htbmdir{}/Delta-cap.bitmap}}
 \newcommand{\div}{\inputbitmap{\htbmdir{}/div.bitmap}}
 \newcommand{\dot}{\inputbitmap{\htbmdir{}/dot.bitmap}}
 \newcommand{\ell}{\inputbitmap{\htbmdir{}/ell.bitmap}}
@@ -253,7 +253,7 @@
 \newcommand{\footnote}[1]{ {(#1)}}
 \newcommand{\frenchspacing}{}
 \newcommand{\gamma}{\inputbitmap{\htbmdir{}/gamma.bitmap}}
-\newcommand{\Gamma}{\inputbitmap{\htbmdir{}/Gamma.bitmap}}
+\newcommand{\Gamma}{\inputbitmap{\htbmdir{}/Gamma-cap.bitmap}}
 \newcommand{\hbar}{\inputbitmap{\htbmdir{}/hbar.bitmap}}
 \newcommand{\hbox}[1]{{#1}}
 \newcommand{\hfill}{}
@@ -269,7 +269,7 @@
 \newcommand{\kappa}{\inputbitmap{\htbmdir{}/kappa.bitmap}}
 \newcommand{\label}[1]{}
 \newcommand{\lambda}{\inputbitmap{\htbmdir{}/lambda.bitmap}}
-\newcommand{\Lambda}{\inputbitmap{\htbmdir{}/Lambda.bitmap}}
+\newcommand{\Lambda}{\inputbitmap{\htbmdir{}/Lambda-cap.bitmap}}
 \newcommand{\large}{}
 \newcommand{\ldots}{...}
 \newcommand{\le}{<=}
@@ -282,41 +282,41 @@
 \newcommand{\nabla}{\inputbitmap{\htbmdir{}/nabla.bitmap}}
 \newcommand{\nu}{\inputbitmap{\htbmdir{}/nu.bitmap}}
 \newcommand{\omega}{\inputbitmap{\htbmdir{}/omega.bitmap}}
-\newcommand{\Omega}{\inputbitmap{\htbmdir{}/Omega.bitmap}}
+\newcommand{\Omega}{\inputbitmap{\htbmdir{}/Omega-cap.bitmap}}
 \newcommand{\pageref}[1]{???}
 \newcommand{\parallel}{\inputbitmap{\htbmdir{}/parallel.bitmap}}
 \newcommand{\partial}{\inputbitmap{\htbmdir{}/partial.bitmap}}
 \newcommand{\phi}{\inputbitmap{\htbmdir{}/phi.bitmap}}
-\newcommand{\Phi}{\inputbitmap{\htbmdir{}/Phi.bitmap}}
+\newcommand{\Phi}{\inputbitmap{\htbmdir{}/Phi-cap.bitmap}}
 \newcommand{\pi}{\inputbitmap{\htbmdir{}/pi.bitmap}}
-\newcommand{\Pi}{\inputbitmap{\htbmdir{}/Pi.bitmap}}
+\newcommand{\Pi}{\inputbitmap{\htbmdir{}/Pi-cap.bitmap}}
 \newcommand{\prime}{\inputbitmap{\htbmdir{}/prime.bitmap}}
 \newcommand{\prod}{\inputbitmap{\htbmdir{}/prod.bitmap}}
 \newcommand{\protect}{}
 \newcommand{\psi}{\inputbitmap{\htbmdir{}/psi.bitmap}}
-\newcommand{\Psi}{\inputbitmap{\htbmdir{}/Psi.bitmap}}
+\newcommand{\Psi}{\inputbitmap{\htbmdir{}/Psi-cap.bitmap}}
 \newcommand{\quad}{\inputbitmap{\htbmdir{}/quad.bitmap}}
 \newcommand{\Re}{\inputbitmap{\htbmdir{}/Re.bitmap}}
 \newcommand{\rho}{\inputbitmap{\htbmdir{}/rho.bitmap}}
 \newcommand{\sc}{\rm}
 \newcommand{\sf}{\bf}
 \newcommand{\sigma}{\inputbitmap{\htbmdir{}/sigma.bitmap}}
-\newcommand{\Sigma}{\inputbitmap{\htbmdir{}/Sigma.bitmap}}
+\newcommand{\Sigma}{\inputbitmap{\htbmdir{}/Sigma-cap.bitmap}}
 \newcommand{\small}{}
 \newcommand{\sum}{\inputbitmap{\htbmdir{}/sum.bitmap}}
 \newcommand{\surd}{\inputbitmap{\htbmdir{}/surd.bitmap}}
 \newcommand{\tau}{\inputbitmap{\htbmdir{}/tau.bitmap}}
 \newcommand{\theta}{\inputbitmap{\htbmdir{}/theta.bitmap}}
-\newcommand{\Theta}{\inputbitmap{\htbmdir{}/Theta.bitmap}}
+\newcommand{\Theta}{\inputbitmap{\htbmdir{}/Theta-cap.bitmap}}
 \newcommand{\times}{\inputbitmap{\htbmdir{}/times.bitmap}}
 \newcommand{\top}{\inputbitmap{\htbmdir{}/top.bitmap}}
 \newcommand{\triangle}{\inputbitmap{\htbmdir{}/triangle.bitmap}}
 \newcommand{\upsilon}{\inputbitmap{\htbmdir{}/upsilon.bitmap}}
-\newcommand{\Upsilon}{\inputbitmap{\htbmdir{}/Upsilon.bitmap}}
+\newcommand{\Upsilon}{\inputbitmap{\htbmdir{}/Upsilon-cap.bitmap}}
 \newcommand{\vbox}[1]{{#1}}
 \newcommand{\wp}{\inputbitmap{\htbmdir{}/wp.bitmap}}
 \newcommand{\xi}{\inputbitmap{\htbmdir{}/xi.bitmap}}
-\newcommand{\Xi}{\inputbitmap{\htbmdir{}/Xi.bitmap}}
+\newcommand{\Xi}{\inputbitmap{\htbmdir{}/Xi-cap.bitmap}}
 \newcommand{\zeta}{\inputbitmap{\htbmdir{}/zeta.bitmap}}
 \newcommand{\bs}{\\}

\start
Date: 15 Nov 2006 08:52:04 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Ping: case insensitive filesystems

Bill Page writes:

| Gaby,
| 
| Are you willing to give Waldek the "go ahead" to commit the
| following patch?

Yes. 
During the conversion, I thought I agreed with this renaming you
proposed.

\start
Date: 15 Nov 2006 08:58:27 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: src/hyper/Makefile.in

Waldek Hebisch writes:

| Gaby,
| 
| You applied change in version 259 only to Makefile.in (Makefile.pamphlet
| stayed unchanged).

I just synced my tree with SVN and it says that Makefile.pamphlet was
modified as well.  Then, I looked in my archive of axiom-commits.
Same thing.  The online archive seems to agree:

http://sourceforge.net/mailarchive/forum.php?thread_id=30927504&forum_id=48483

Is it possible you're at a wrong local tree?

\start
Date: 15 Nov 2006 09:19:57 +0100
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] fix boottoclc description

boottoclc translates .boot files to .clisp files (and not .oclisp).

-- Gaby
2006-11-15  Gabriel Dos Reis  Gabriel Dos Reis

	* ptyout.boot.pamphlet (boottoclc): Fix description to match
	implementation. 
	* Makefile.pamphlet: Likewise.
	(BOOT_TO_LISP): Use boottran::boottoclc.

*** src/boot/Makefile.pamphlet	(revision 16870)
--- src/boot/Makefile.pamphlet	(local)
*************** table.
*** 902,908 ****
  \begin{verbatim}  
  (boottoclc "filename")
  translates the file "filename.boot" to
! the common lisp file "filename.oclisp" 
  with the original boot code as comments
  \end{verbatim} 
   
--- 902,908 ----
  \begin{verbatim}  
  (boottoclc "filename")
  translates the file "filename.boot" to
! the common lisp file "filename.clisp" 
  with the original boot code as comments
  \end{verbatim} 
   
*** src/boot/ptyout.boot.pamphlet	(revision 16870)
--- src/boot/ptyout.boot.pamphlet	(local)
*************** shoeClLines(a,fn,lines,outfn)==
*** 107,113 ****
         shoeConsole CONCAT(outfn,'" PRODUCED")
   
  -- (boottoclc "filename") translates the file "filename.boot" to
! -- the common lisp file "filename.oclisp" with the original boot
  -- code as comments
   
  BOOTTOCLC fn==BOOTTOCLCLINES(nil,fn)
--- 107,113 ----
         shoeConsole CONCAT(outfn,'" PRODUCED")
   
  -- (boottoclc "filename") translates the file "filename.boot" to
! -- the common lisp file "filename.clisp" with the original boot
  -- code as comments
   
  BOOTTOCLC fn==BOOTTOCLCLINES(nil,fn)

\start
Date: Wed, 15 Nov 2006 05:36:41 -0500
From: Bill Page
To: list
Subject: RE: FW: data structure vs. mathematical structure

Ralf Hemmecke writes:
>
> [...]
>
> | ++ A set over a domain D models the usual mathematical notion of
> | ++ a finite set of elements from D.
> |
> | Although
> |
> | i: Integer
> |
> | and
> |
> | s: FinitePowerSet T
> |
> | would be in perfect analogy if one read ":" as "element of", then
> | to go on "l: List T" would mean "List" is the container of all
> | finite sequences (with some information about their representation
> | (linked list)).

On Tuesday, November 14, 2006 8:30 PM Gaby wrote:
> 
> And that would match the usual definition of List as the least fixed
> point of the functor
>
>      X |-> 1 + X
>
> in CPO.

In case anyone is wondering what Gaby is talking about, I think the
following paper by Dos Reis and Jarvi:

  What is Generic Programming?
  Library-Centric Software Design LCSD'05

http://lcsd05.cs.tamu.edu/papers/dos_reis_et_al.pdf

provides a good introduction. It defines a List as the least fixed
point of

      X |-> 1 + T x X

Hopefully a future paper will deal more specifically with Axiom. :-)

In Axiom List could be defined something like this

  List(T:Type):ListAggregate == add
    Rep == Union(nil,Record(first:T,rest:%))
    ...

(perhaps it is in Aldor?) but in fact the actual definition refers
directly to the underlying Lisp architecture.

There is also a recent paper by Pablo Nogueira
http://www.cs.nott.ac.uk/~pni

  When is an Abstract Data Type a Functor? (31 Oct 06)
  7th Symposium on Trends in Functional Programming (TFP'06)

http://www.cs.nott.ac.uk/~pni/Papers/adt-functors.pdf

It contains a lot of references to Haskell and some category theory
but most of what it says about ADTs can also be applied to Axiom.

See also

http://www.cs.nott.ac.uk/~pni/Papers/index.html

>
> However, the existence of 1.. in Axiom would suggest that actually
> some people think of List as the greatest fixed point.
>

I don't think so.

In Axiom 1.. is called a UniversalSegment or a "Segment which may
be half open". Open segments can be expanded as Streams.

(1) -> expand(1..)

   (1)  [1,2,3,4,5,6,7,8,9,10,...]
                                             Type: Stream Integer

Formally Streams are defined as the greatest fixed point of the
functor

   X |-> T x X

Streams are like Lists but can be infinite. Axiom has both lists and
streams. E.g.

(2) -> generate(x+->nextItem(x),0)$Stream(INT)

   (2)  [0,1,- 1,2,- 2,3,- 3,4,- 4,5,...]
                                             Type: Stream Integer
\start
Date: Wed, 15 Nov 2006 12:07:57 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: FW: data structure vs. mathematical structure

>> And that would match the usual definition of List as the least fixed
>> point of the functor
>>
>>      X |-> 1 + X
>>
>> in CPO.
> 
> In case anyone is wondering what Gaby is talking about, I think the
> following paper by Dos Reis and Jarvi:
> 
>   What is Generic Programming?
>   Library-Centric Software Design LCSD'05
> 
> http://lcsd05.cs.tamu.edu/papers/dos_reis_et_al.pdf
> 
> provides a good introduction. It defines a List as the least fixed
> point of
> 
>       X |-> 1 + T x X
> 
> Hopefully a future paper will deal more specifically with Axiom. :-)
> 
> In Axiom List could be defined something like this
> 
>   List(T:Type):ListAggregate == add
>     Rep == Union(nil,Record(first:T,rest:%))
>     ...
> 
> (perhaps it is in Aldor?) but in fact the actual definition refers
> directly to the underlying Lisp architecture.

I had no need to define List this way, but what about binary trees?
The following code snipped is from Aldor-Combinat and it is running code.

---BEGIN test/species.as.nw
[snip]

testRecursive1(): () == {
         macro {
                 I == EmptySetSpecies;
                 X == SingletonSpecies;
                 + == Plus;
                 * == Times;
         }

         A(L: LabelType): CombinatorialSpecies L == (I + X*A*A)(L) add;

         import from Integer, Array Integer;
         checkExpOrd(
             A,
             [1, 1, 4, 30, 336, 5040],
             [1, 1, 2, 5, 14, 42]
         );
}

[snap]
---END test/species.as.nw

If you want List the line should be simply ...

   MyList(L: LabelType): CombinatorialSpecies L == (I + X*MyList)(L) add;

Well, but in LibAldor List is not defined as a real Union. It rather 
relies on the fact that an actual record can never be the nil pointer.

Oh, by the way, the above recursive definition of binary trees not only 
defines the data structure but also the exponential and ordinary 
generating series. So one could ask how many trees are there with 7 
nodes (labelled or unlabelled). I fact, it should also be possible, to 
generate all these trees.

Recently, Martin Rubey has done some work to make Aldor-combinat 
available for Axiom, but for the underlying compilation we still need 
the Aldor compiler. So, Gaby, I consider Aldor-combinat a testcase for 
the compiler-improvements branch. ;-)

\start
Date: 15 Nov 2006 12:11:26 +0100
From: Martin Rubey
To: Bill Page
Subject: re: FW: data structure vs. mathematical structure

Bill Page writes:
> [...] It defines a List as the least fixed
> point of
>
>       X |-> 1 + T x X
>
By the way, in aldor-combinat (or axiom-combinat, if you like), you can define
an equivalent to "List L" as


macro {
        I == EmptySetSpecies;
        X == SingletonSpecies;
        + == Plus;
        * == Times;
}

List(L: LabelType): CombinatorialSpecies L == (I + X*List)(L) add;

That's all. All the logic is hidden in CombinatorialSpecies, Plus and
Times. Well, not quite, but to see what's missing (and how to easily add it)
you'll have to read the docs.

It's Ralf who made this possible, I'd like to add.

\start
Date: 15 Nov 2006 12:17:14 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: FW: data structure vs. mathematical structure

Ralf Hemmecke writes:

> Oh, by the way, the above recursive definition of binary trees not only
> defines the data structure but also the exponential and ordinary generating
> series. So one could ask how many trees are there with 7 nodes (labelled or
> unlabelled). In fact, it should also be possible, to generate all these
> trees.

Yes it is. With and without labels.

And the prettiest thing of all is that it should be quite easy to add code that
gives those recursively generated domains more structure. For example, one
would maybe like to construct a specific binary tree, or take two and add them
together and so on.

\start
Date: Wed, 15 Nov 2006 12:37:56 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: src/hyper/Makefile.in

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | Gaby,
> | 
> | You applied change in version 259 only to Makefile.in (Makefile.pamphlet
> | stayed unchanged).
> 
> I just synced my tree with SVN and it says that Makefile.pamphlet was
> modified as well.  Then, I looked in my archive of axiom-commits.
> Same thing.  The online archive seems to agree:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_id=30927504&forum_id=48483
> 
> Is it possible you're at a wrong local tree?
> 

Yes, that was a local problem (probably due to NFS) -- I see correct
file now.

\start
Date: Wed, 15 Nov 2006 13:03:32 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Ping: case insensitive filesystems

> Bill Page writes:
> 
> | Gaby,
> | 
> | Are you willing to give Waldek the "go ahead" to commit the
> | following patch?
> 
> Yes. 
> During the conversion, I thought I agreed with this renaming you
> proposed.
> 

I waited for:

http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00294.html

I tested file renaming from

http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00297.html

only with patch 2006-11/msg00294 which removes second copy of 'util.ht'.
I think that renaming from 2006-11/msg00297 should work even without
2006-11/msg00294 applied, but I did not test that combination.  Also
I having the to compies of 'util.ht' out of sync _may_ cause troubles
(I was hit by this).

\start
Date: Wed, 15 Nov 2006 13:14:07 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Eval in Axiom/Aldor

>> And I cant compile Martin one, maybe I should not assume that
>> a Field is an INTDOM ...

> No it not necessary to assume that a Field is an INTDOM.

But it is true.

Field(): Category == Join(EuclideanDomain,UniqueFactorizationDomain,
   DivisionRing) with ...
EuclideanDomain(): Category == PrincipalIdealDomain with ...
PrincipalIdealDomain(): Category == GcdDomain with ...
GcdDomain(): Category == IntegralDomain with ...

> I also don't understand Martin's workaround since Fraction does
> not export elt with this signature.

But ...

UnivariatePolynomial(x:Symbol, R:Ring):
   UnivariatePolynomialCategory(R) with ...

UnivariatePolynomialCategory(R:Ring): Category ==
     ...
     if R has IntegralDomain then
         Eltable(Fraction %, Fraction %)
         elt  : (Fraction %, Fraction %) -> Fraction %
              ++ elt(a,b) evaluates the fraction of univariate 
polynomials \spad{a}
              ++ with the distinguished variable replaced by b.

So Martin's suggestion does not sound so wrong to me.

\start
Date: Wed, 15 Nov 2006 13:25:40 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Eval in Axiom/Aldor

On 11/15/2006 07:44 AM, Page, Bill wrote:
> On Tuesday, November 14, 2006 6:20 PM Antoine Hersen wrote:
>> I get nasty FOAM run time error with Ralf solution (I used it
>> in a more involved context)
> 
> Ralf wrote:
> 
>> Replace "eval(a, x, 1)" by
>>
>>     z: SingletonAsOrderedSet := create();
>>     eval(numer a, z, 1)/eval(denom a, z, 1);
> 
> I don't understand why Ralf introduces a new variable z. But
> I think that is the right idea.

Since I worked backwards to find where "eval" is implemented. That 
compiled and I was in a rush. I don't claim it is the way to go.

[snip]

> However
> 
>   UnivariatePolynomial(x, F) has
> InnerEvalable(UnivariatePolynomial(x,F),
>   UnivariatePolynomial(x,F))
> 
> is true so one way that does work is:
> 
>     import from UnivariatePolynomial(x, F);
>     import from NonNegativeInteger;
> 
>     test1(a:Fraction UnivariatePolynomial(x,F)):Fraction
> UnivariatePolynomial(x,F) == {
>         eval(numer a, monomial(1$F,1),1)/eval(denom a,
> monomial(1$F,1),1)
>     };

> monomial(1$F,1) is just one way to get x in the right form.
> (Perhaps Ralf missed this possibility.)

I hope you see that the eval from above is not the same function as the 
eval here.

I considered the definitions ...

UnivariatePolynomial(x:Symbol, R:Ring):
   UnivariatePolynomialCategory(R) with ...

UnivariatePolynomialCategory(R:Ring): Category ==
  Join(PolynomialCategory(R, NonNegativeInteger, SingletonAsOrderedSet),
       Eltable(R, R), Eltable(%, %), DifferentialRing,
       DifferentialExtension R) with ...

PolynomialCategory(R:Ring, E:OrderedAbelianMonoidSup, VarSet:OrderedSet):
         Category ==
   Join(PartialDifferentialRing VarSet, FiniteAbelianMonoidRing(R, E),
        Evalable %, InnerEvalable(VarSet, R),
        InnerEvalable(VarSet, %), RetractableTo VarSet,
        FullyLinearlyExplicitRingOver R) with

while I am using InnerEvalable(VarSet, R) (which has nothing to do with 
the symbol x from UnivariatePolynomial, you suggested

InnerEvalable(%, %)

from UnivariatePolynomial(x,F) where I must say, that I would have to 
dig deeper in the category hierarchy of UP in order to find that signature.

Two different "eval"s, where yours is probably a bit more general. I 
don't believe that they end up in the same implementation.

\start
Date: Wed, 15 Nov 2006 08:27:53 -0400
From: Humberto Zuazaga
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Gabriel Dos Reis wrote:
> On Tue, 14 Nov 2006, Humberto Ortiz Zuazaga wrote:
>
> | Humberto Ortiz-Zuazaga wrote:
> |
> | >> | I built --without-noweb --with-gcl, the configure for the built in gcl
> | >> | isn't working right.
> |
> | I think I tracked down the problem. In build-improvements, on the Mac,
> | the configure for gcl was being called with a broken --enable-machine
> | flag, and the subsequent make would fail.
> |
> | I think this patch to configure.ac.pamphlet fixes it.
> |
> | I also incorporated other suggested changes to the configure flags:
> |
> | 1) we should use locbfd instead of custreloc
> |
> | 2) we don't need X Window system support or xgcl
> |
> | With these changes a full build of noweb, gcl and axiom work on my
> | PowerPC Mac OS X 10.4.8 machine with the following steps:
> |
> | # remove fink /sw/bin from the path
> | PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
> | ./configure --without-noweb --without-gcl
> | make
>
> This is great!  We should disable xgcl for all of the targets.
> Could your update your patch accordingly and commit?
> I can do it but not now (unfortunately).
>   

I'm slowly going crazy. gcl builds without problems, but not from the 
axiom build-improvements makefiles if I configure axiom --without-gcl. A 
gcl is built and installed into build/{ARCH}, but it segfaults as soon 
as it starts.

A build from the lsp directory seems to work, but not from the toplevel. 
It produces a working gcl in build/{ARCH}/bin/gcl.

I suspect a problem with the ENV= definition in the top-level Makefile, 
but haven't been able to track it down. Are we supposed to define 
GCLDIR? It currently isn't being defined, and an empty GCLDIR is being 
passed on to make in the lsp directory

A make distclean in the toplevel leaves the broken gcl in the lsp 
directory, so I'm deleting the whole source tree between every build.

\start
Date: 15 Nov 2006 13:43:22 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2

Humberto Zuazaga writes:

[...]

| I suspect a problem with the ENV= definition in the top-level
| Makefile, but haven't been able to track it down. Are we supposed to
| define GCLDIR? It currently isn't being defined, and an empty GCLDIR
| is being passed on to make in the lsp directory

I'm looking into it.  

\start
Date: Wed, 15 Nov 2006 07:55:12 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Eval in Axiom/Aldor

Ralf,

On Wednesday, November 15, 2006 7:14 AM you wrote:
>
> >> And I cant compile Martin one, maybe I should not assume that
> >> a Field is an INTDOM ...
>
> > No it not necessary to assume that a Field is an INTDOM.
>
> But it is true.
>
> Field(): Category == =
Join(EuclideanDomain,UniqueFactorizationDomain,
>    DivisionRing) with ...
> EuclideanDomain(): Category == PrincipalIdealDomain with ...
> PrincipalIdealDomain(): Category == GcdDomain with ...
> GcdDomain(): Category == IntegralDomain with ...
>

You are right. I was not clear. I meant it is not necessary to
assume it *as an additional assumption* since it is true by
Axiom's definition of Field. But it is irrelevant to this problem.

> > I also don't understand Martin's workaround since Fraction does
> > not export elt with this signature.
>
> But ...
>
> UnivariatePolynomial(x:Symbol, R:Ring):
>    UnivariatePolynomialCategory(R) with ...
>
> UnivariatePolynomialCategory(R:Ring): Category ==
>      ...
>      if R has IntegralDomain then
>          Eltable(Fraction %, Fraction %)
>          elt  : (Fraction %, Fraction %) -> Fraction %
>               ++ elt(a,b) evaluates the fraction of univariate
> polynomials \spad{a}
>               ++ with the distinguished variable replaced by b.
>
> So Martin's suggestion does not sound so wrong to me.
>

Yes. However as I said, Fraction UnivariatePolynomial(x,F) does
not export elt so the workaround cannot work as it was written.

I tried writing:

  test(a:Fraction UnivariatePolynomial(x, F)):Fraction
UnivariatePolynomial(x, F) ==
    elt(a,1$Fraction(UnivariatePolynomial(x,
F)))$UnivariatePolynomial(x, F)

but Aldor continues to insist that there is no such elt that
returns Fraction UnivariatePolynomial(x, F). Perhaps it is a
compiler bug?

In any case, isn't it strange that UnivariatePolynomialCategory
should be Eltable(Fraction %, Fraction %)? What is Fraction doing
in that definition of UnivariatePolynomial(x, F)?

Note the presence of

eval : (%,UnivariatePolynomial(x,Fraction
Integer),UnivariatePolynomial(x,Fraction Integer)) -> %

in the example below. This is the eval that I used in my version.

(1) -> F:=FRAC INT

   (1)  Fraction Integer
                                                     Type: Domain

(2) -> F has Field

   (2)  true
                                                     Type: Boolean

(3) -> F has IntegralDomain

   (3)  true
                                                     Type: Boolean

(4) -> UP(x,FRAC INT) has Eltable(FRAC UP(x,FRAC INT),FRAC UP(x,FRAC
INT))

   (4)  true
                                                     Type: Boolean

(5) -> )sh Fraction UnivariatePolynomial(x,FRAC INT)
 Fraction UnivariatePolynomial(x,Fraction Integer) is a domain
constructor.
 Abbreviation for Fraction is FRAC
 This constructor is exposed in this frame.
 Issue )edit C:/Program
Files/axiom/mnt/windows/../../src/algebra/FRAC.spad to s
ee algebra source code for FRAC

------------------------------- Operations
--------------------------------

 ?*? : (Fraction Integer,%) -> %       ?*? : (Integer,%) -> %
...
 euclideanSize : % -> NonNegativeInteger
 eval : (%,Equation UnivariatePolynomial(x,Fraction Integer)) -> %
 eval : (%,List Equation UnivariatePolynomial(x,Fraction Integer)) -> %
 eval : (%,List Symbol,List UnivariatePolynomial(x,Fraction Integer)) ->
%
 eval : (%,List UnivariatePolynomial(x,Fraction Integer),List
UnivariatePolynomial(x,Fraction Integer)) -> %
 eval : (%,Symbol,UnivariatePolynomial(x,Fraction Integer)) -> %
 eval : (%,UnivariatePolynomial(x,Fraction
Integer),UnivariatePolynomial(x,Fraction Integer)) -> %
 expressIdealMember : (List %,%) -> Union(List %,"failed")
...
 wholePart : % -> UnivariatePolynomial(x,Fraction Integer)

\start
Date: 15 Nov 2006 13:52:36 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Ping: case insensitive filesystems

Waldek Hebisch writes:

| > Bill Page writes:
| > 
| > | Gaby,
| > | 
| > | Are you willing to give Waldek the "go ahead" to commit the
| > | following patch?
| > 
| > Yes. 
| > During the conversion, I thought I agreed with this renaming you
| > proposed.
| > 
| 
| I waited for:
| 
| http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00294.html

I agree with the sentiment of not rmoving gloss.text.

Please include explanation in pamphlets so as not to delay patch
review.  

| I tested file renaming from
| 
| http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00297.html
| 
| only with patch 2006-11/msg00294 which removes second copy of 'util.ht'.
| I think that renaming from 2006-11/msg00297 should work even without
| 2006-11/msg00294 applied, but I did not test that combination.  Also
| I having the to compies of 'util.ht' out of sync _may_ cause troubles
| (I was hit by this).

Please let separate the patches:
  (1) one for renaming -- contains explanations
  (2) one for deletiing the redundant file -- also must contain
      explanation of why.

\start
Date: 15 Nov 2006 13:59:18 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: FW: data structure vs. mathematical structure

Ralf Hemmecke writes:

| >> And that would match the usual definition of List as the least fixed
| >> point of the functor
| >>
| >>      X |-> 1 + X
| >>
| >> in CPO.
| > In case anyone is wondering what Gaby is talking about, I think the
| > following paper by Dos Reis and Jarvi:
| >   What is Generic Programming?
| >   Library-Centric Software Design LCSD'05
| > http://lcsd05.cs.tamu.edu/papers/dos_reis_et_al.pdf
| > provides a good introduction. It defines a List as the least fixed
| > point of
| >       X |-> 1 + T x X
| > Hopefully a future paper will deal more specifically with Axiom. :-)
| > In Axiom List could be defined something like this
| >   List(T:Type):ListAggregate == add
| >     Rep == Union(nil,Record(first:T,rest:%))
| >     ...
| > (perhaps it is in Aldor?) but in fact the actual definition refers
| > directly to the underlying Lisp architecture.
|
| I had no need to define List this way, but what about binary trees?

The definition you gave is it: least fixed point of

    X |-> 1 + T =D7 X =D7 X


The interesting bit about those inductive definition is that they come
with "fold" (reduce in Axiom-speak) for free.

| The following code snipped is from Aldor-Combinat and it is running code.
|
| ---BEGIN test/species.as.nw
| [snip]
|
| testRecursive1(): () == {
|          macro {
|                  I == EmptySetSpecies;
|                  X == SingletonSpecies;
|                  + == Plus;
|                  * == Times;
|          }
|
|          A(L: LabelType): CombinatorialSpecies L == (I + X*A*A)(L) ad=
d;
|
|          import from Integer, Array Integer;
|          checkExpOrd(
|              A,
|              [1, 1, 4, 30, 336, 5040],
|              [1, 1, 2, 5, 14, 42]
|          );
| }
|
| [snap]
| ---END test/species.as.nw
|
| If you want List the line should be simply ...
|
|    MyList(L: LabelType): CombinatorialSpecies L == (I + X*MyList)(L) =
add;
|
| Well, but in LibAldor List is not defined as a real Union. It rather
| relies on the fact that an actual record can never be the nil pointer.
|
| Oh, by the way, the above recursive definition of binary trees not
| only defines the data structure but also the exponential and ordinary
| generating series. So one could ask how many trees are there with 7
| nodes (labelled or unlabelled). I fact, it should also be possible, to
| generate all these trees.

Yes!

|
| Recently, Martin Rubey has done some work to make Aldor-combinat
| available for Axiom, but for the underlying compilation we still need
| the Aldor compiler. So, Gaby, I consider Aldor-combinat a testcase for
| the compiler-improvements branch. ;-)

OK, I don't feel it like a pressure :-) :-)

\start
Date: Wed, 15 Nov 2006 14:35:56 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Ping: case insensitive filesystems

> Waldek Hebisch writes:
> 
> | > Bill Page writes:
> | > 
> | > | Gaby,
> | > | 
> | > | Are you willing to give Waldek the "go ahead" to commit the
> | > | following patch?
> | > 
> | > Yes. 
> | > During the conversion, I thought I agreed with this renaming you
> | > proposed.
> | > 
> | 
> | I waited for:
> | 
> | http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00294.html
> 
> I agree with the sentiment of not rmoving gloss.text.
> 
> Please include explanation in pamphlets so as not to delay patch
> review.  
> 
> | I tested file renaming from
> | 
> | http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00297.html
> | 
> | only with patch 2006-11/msg00294 which removes second copy of 'util.ht'.
> | I think that renaming from 2006-11/msg00297 should work even without
> | 2006-11/msg00294 applied, but I did not test that combination.  Also
> | I having the to compies of 'util.ht' out of sync _may_ cause troubles
> | (I was hit by this).
>

Sorry, I do not get what you mean: 
> Please let separate the patches:

Do you mean that I should test and apply renaming patch without
removing 'util.ht'?  I really do not like this -- that would mean
patching both copies or leaving a potential bug.

>   (1) one for renaming -- contains explanations
>   (2) one for deletiing the redundant file -- also must contain
>       explanation of why.
> 

So you want something like:

: We messed up.  We hade the rule:
: 
: <old rule>
:
: We should not try to install two source files into single location,
: so we removed the rule.

I find such "explanation" silly: we have version control and change
logs to keep history.  And does not explain anything about the system
_after_ the fix is applied.

\start
Date: Wed, 15 Nov 2006 14:47:30 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: compiler-improvements

Gabriel Dos Reis wrote:
> Please include explanation in pamphlets so as not to delay patch
> review.  
<snip>
>   (2) one for deletiing the redundant file -- also must contain
>       explanation of why.
> 

I must say here that I want a private branch for experiments precisely
to avoid fuss about trivial details.  For experimental work that
would be deadly.  And even on "release" branch I think you go too
far.

\start
Date: 15 Nov 2006 15:47:18 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Ping: case insensitive filesystems

Waldek Hebisch writes:

[...]

| Sorry, I do not get what you mean: 
| > Please let separate the patches:
| 
| Do you mean that I should test and apply renaming patch without
| removing 'util.ht'?  I really do not like this -- that would mean
| patching both copies or leaving a potential bug.

That is a good point.

| 
| >   (1) one for renaming -- contains explanations
| >   (2) one for deletiing the redundant file -- also must contain
| >       explanation of why.
| > 
| 
| So you want something like:
| 
| : We messed up.  We hade the rule:
| : 
| : <old rule>
| :
| : We should not try to install two source files into single location,
| : so we removed the rule.
| 
| I find such "explanation" silly: we have version control and change
| logs to keep history.  And does not explain anything about the system
| _after_ the fix is applied.

Not because you can come up with a silly explanation means that any
explanation should be silly.  Please, let's keep things in perspective.

What about:

   There are two files for each (special) character glyph, one
   for the upper case form, and one for the lower case form.
   Historically, the names for these files used to differ only in the 
   first character (which is upper case for the upper case form).
   That was non-portable and caused griefs on brain damaged file
   systems that identify themselves as ``case preserving, case insensitive''
   where alpha.ps and Alpha.ps ended up designating the same file.
   Consequently, the files for the upper case form have been renamed
   to xxx-cap.ps, where "xxx" used to be the historic name.

?

Please feel free to elaborate/improve it.


I'm of the opinion that you get should in the habit of including
explanation in the pamphlets when you submit them for consideration.
I would like to see the changes explained.  One reason, in this
particular case, is that when it comes to merge build-improvements
back to trunk (whatever it is called) there will be differences and
conflicts, and I would hate to have to spend hours in front of a
browser digging in the archive.  Yes, we have ChangeLog files, but
they are no substitute for documentation files (which are the pamphlets).

You're making invaluable contributions to Axiom; let's make sure we
don't end up in the same trap as current system.  Thanks!

\start
Date: 15 Nov 2006 15:48:35 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: compiler-improvements

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Please include explanation in pamphlets so as not to delay patch
| > review.  
| <snip>
| >   (2) one for deletiing the redundant file -- also must contain
| >       explanation of why.
| > 
| 
| I must say here that I want a private branch for experiments precisely
| to avoid fuss about trivial details.

Please, consider that you're free to make branches at any time.

\start
Date: Wed, 15 Nov 2006 10:42:48 -0500
From: Bill Page
To: Gabriel Dos Reis, Waldek Hebisch
Subject: RE: Ping: case insensitive filesystems

On Wednesday, November 15, 2006 9:47 AM Gaby wrote:
> ...
> Not because you can come up with a silly explanation means that
> any explanation should be silly.  Please, let's keep things in
> perspective.
>

I am sympathetic to Waldek's complaint - not because I think
explanations are silly but rather because I know how annoying
it is to write such explanations after the solution is complete
and when your mind is ready to focus on the next issue.

My experience (on other projects) is that it is much better,
whenever possible to work as a two person team. One person is
"lead" and other can be mostly "audience" or "apprentice". The
presence of the 2nd person is the motivation for providing an
explanation. That is why it is so easy to write such explanation
in the form of email. But we can also assign the responsibility
of writing documentation based on the explanations to the 2nd
person. Also they can ask important questions when the explanation
is not clear.  It can be their main contribution to the work.

My suggestiong is that when we start to work on a patch, we first
ask on the axiom-developer list for someone to play the role of
2nd person. Perhaps this is a way for people who do not yet feel
bold enough to work on Axiom themselves yet to get started.

Yes, I would agree to act as the 2nd person and write such
documentation from time to time. :-)

> What about:
>
>    There are two files for each (special) character glyph, one
>    for the upper case form, and one for the lower case form.
>    Historically, the names for these files used to differ only in the
>    first character (which is upper case for the upper case form).
>    That was non-portable and caused griefs on brain damaged file
>    systems that identify themselves as ``case preserving, case
>    insensitive'' where alpha.ps and Alpha.ps ended up designating
>    the same file. Consequently, the files for the upper case form
>    have been renamed to xxx-cap.ps, where "xxx" used to be the
>    historic name.
>
> ?
>
> Please feel free to elaborate/improve it.
>

Here Gaby has done a excellent job as 2nd person. If I were Waldek
I would just take this and add it to the pamphlet file. :-)

>
> I'm of the opinion that you get should in the habit of including
> explanation in the pamphlets when you submit them for consideration.
> I would like to see the changes explained.  One reason, in this
> particular case, is that when it comes to merge build-improvements
> back to trunk (whatever it is called) there will be differences and
> conflicts, and I would hate to have to spend hours in front of a
> browser digging in the archive.  Yes, we have ChangeLog files, but
> they are no substitute for documentation files (which are the
> pamphlets).

I agree.

>
> You're making invaluable contributions to Axiom; let's make sure
> we don't end up in the same trap as current system.  Thanks!
>

I think we can work together to make sure that does not happen.

\start
Date: 15 Nov 2006 16:48:25 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Ping: case insensitive filesystems

Bill Page writes:

[...]

| My suggestiong is that when we start to work on a patch, we first
| ask on the axiom-developer list for someone to play the role of
| 2nd person. Perhaps this is a way for people who do not yet feel
| bold enough to work on Axiom themselves yet to get started.

That would definitely increase the among of shared knowledge.

| Yes, I would agree to act as the 2nd person and write such
| documentation from time to time. :-)

OK, you're officially appointed as that second person :-)

\start
Date: Wed, 15 Nov 2006 16:55:00 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Ping: case insensitive filesystems

> Not because you can come up with a silly explanation means that any
> explanation should be silly.  Please, let's keep things in perspective.
> 
> What about:
> 
>    There are two files for each (special) character glyph, one
>    for the upper case form, and one for the lower case form.
>    Historically, the names for these files used to differ only in the 
>    first character (which is upper case for the upper case form).
>    That was non-portable and caused griefs on brain damaged file
>    systems that identify themselves as ``case preserving, case insensitive''
>    where alpha.ps and Alpha.ps ended up designating the same file.
>    Consequently, the files for the upper case form have been renamed
>    to xxx-cap.ps, where "xxx" used to be the historic name.
> 
> ?
> 
> Please feel free to elaborate/improve it.
>

Gaby, we are miscomunicating here.  I wrote about 2006-11/msg00294
for which _really_ I that best explantion is "remove reference to
redundant file" (and ChangeLog is _the_ place to put it).

Expanation you wrote is about 2006-11/msg00297 (you wrote that it
contains explanation, but in fact explanantion is in the text
outside the patch). Again ChangeLog is logical place to put
it.  If you insist on some info outside ChangeLog i would 
propose to create a new pamplets called "Coding guide" (or
maybe into DeveloperNotes).
 
> 
> I'm of the opinion that you get should in the habit of including
> explanation in the pamphlets when you submit them for consideration.
> I would like to see the changes explained.  One reason, in this
> particular case, is that when it comes to merge build-improvements
> back to trunk (whatever it is called) there will be differences and
> conflicts, and I would hate to have to spend hours in front of a
> browser digging in the archive.  Yes, we have ChangeLog files, but
> they are no substitute for documentation files (which are the pamphlets).
> 

Well:
1) AFAIU the whole SCM discussion started because we wanted chageset
   support.  ChangeLog entry is part of a chageset and would be the
   first place I would look at during merge.
2) I you are concerned that ChangeLog is not a pamphlet we can easily
   correct this: write a few Latex macros, header and footer. Then
   a little script can easily convert format (bidirectionally if
   for some reason we also want conventional ChangeLog).

I think we have conflicting paradigms here.  I belive that history
has place in documentation only if it explains _significant_ aspect
of current system.  In case of current filename change past status
really tells you nothing about new system.

\start
Date: 15 Nov 2006 17:25:47 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Ping: case insensitive filesystems

Waldek Hebisch writes:

| > Not because you can come up with a silly explanation means that any
| > explanation should be silly.  Please, let's keep things in perspective.
| > 
| > What about:
| > 
| >    There are two files for each (special) character glyph, one
| >    for the upper case form, and one for the lower case form.
| >    Historically, the names for these files used to differ only in the 
| >    first character (which is upper case for the upper case form).
| >    That was non-portable and caused griefs on brain damaged file
| >    systems that identify themselves as ``case preserving, case insensitive''
| >    where alpha.ps and Alpha.ps ended up designating the same file.
| >    Consequently, the files for the upper case form have been renamed
| >    to xxx-cap.ps, where "xxx" used to be the historic name.
| > 
| > ?
| > 
| > Please feel free to elaborate/improve it.
| >
| 
| Gaby, we are miscomunicating here.  I wrote about 2006-11/msg00294
| for which _really_ I that best explantion is "remove reference to
| redundant file" (and ChangeLog is _the_ place to put it).
| 
| Expanation you wrote is about 2006-11/msg00297 (you wrote that it
| contains explanation, but in fact explanantion is in the text
| outside the patch). Again ChangeLog is logical place to put
| it.  If you insist on some info outside ChangeLog i would 
| propose to create a new pamplets called "Coding guide" (or
| maybe into DeveloperNotes).


The comment I wrote is effectively for justifying the renaming patch,
which is I thought you're objecting to on the ground that we can find
an explanation that does not look good.  Is that wrong?


For 2006-11/msg00294 I still believe that we need explanation saying
why we removed the redundant file.  This explanation is better placed
in the Makefile pamphlet than the ChangeLog.  Say something like 

  The Axiom system from which this branch had been made appears 
  to contain a redundant copy of util.ht. The version in x/y/z has
  been removed so as to minimize blah.

That needs to go in the Makefile, not the ChangeLog.  When we come to
merge, they will be very helpful -- my experience with GCC branches
makes me very skeptikal of changes on branches that are only (briefly)
described in ChangeLogs.  The patch is approved with that caveat.

When the merge is done, some of the comments will become obselete, but
not before.  When it comes to merge and someone question removal, it
would be much better to point them at the documentation why it
happened.  We would not want to start yet another discussion on
literate programming when we will be busy trying to merge and have a
wonderful system.

| > I'm of the opinion that you get should in the habit of including
| > explanation in the pamphlets when you submit them for consideration.
| > I would like to see the changes explained.  One reason, in this
| > particular case, is that when it comes to merge build-improvements
| > back to trunk (whatever it is called) there will be differences and
| > conflicts, and I would hate to have to spend hours in front of a
| > browser digging in the archive.  Yes, we have ChangeLog files, but
| > they are no substitute for documentation files (which are the pamphlets).
| > 
| 
| Well:
| 1) AFAIU the whole SCM discussion started because we wanted chageset
|    support.

Yes.

|    ChangeLog entry is part of a chageset and would be the
|    first place I would look at during merge.

yes, but a ChangeLog is not a substitute for documentation.  It helps
track changes; it does not explain why changes have been made.  My
whole point is that, yes, we record a change with brief description
(ChangeLog), but we need to explain *why* we made the change.  That
will prove helpful to ourselves when we will face skepticals.

| 2) I you are concerned that ChangeLog is not a pamphlet we can easily

I don't think ChangeLog should be a pamphlet.  Its purpose is to
contain brief description of changes, to assist in archeology.

|    correct this: write a few Latex macros, header and footer. Then
|    a little script can easily convert format (bidirectionally if
|    for some reason we also want conventional ChangeLog).

:-)

| I think we have conflicting paradigms here.

I'm not so sure.

|  I belive that history
| has place in documentation only if it explains _significant_ aspect
| of current system.

The trouble is how to define "significant".  Some people think that if
something changes Axiom to do better error message, it is
significant.  And I agree.  Others think that if it changes any code
in a software that is alredy undocumented, then it is significant
too.  I tend to agree.

|  In case of current filename change past status
| really tells you nothing about new system.

Except that this is a *branch* we are going to merge back to trunk.  We
need to know why we did a change.

\start
Date: Wed, 15 Nov 2006 09:34:47 -0600 (CST)
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-758783491-1163604887=:20095

On Tue, 14 Nov 2006, Humberto Ortiz Zuazaga wrote:

| Humberto Ortiz-Zuazaga wrote:
|
| >> | I built --without-noweb --with-gcl, the configure for the built in gcl
| >> | isn't working right.
|
| I think I tracked down the problem. In build-improvements, on the Mac,
| the configure for gcl was being called with a broken --enable-machine
| flag, and the subsequent make would fail.
|
| I think this patch to configure.ac.pamphlet fixes it.
|
| I also incorporated other suggested changes to the configure flags:
|
| 1) we should use locbfd instead of custreloc
|
| 2) we don't need X Window system support or xgcl
|
| With these changes a full build of noweb, gcl and axiom work on my
| PowerPC Mac OS X 10.4.8 machine with the following steps:
|
| # remove fink /sw/bin from the path
| PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
| ./configure --without-noweb --without-gcl
| make

Hello Humberto,

  How about this patch I'm testing?  I splitted the GCLOPTS into
independent parts, and disabled X and TK for all targets.

-- Gaby

---559023410-758783491-1163604887=:20095

MjAwNi0xMS0xNSAgSHVtYmVydG8gT3J0aXogWnVhemFnYSAgPGh1bWJlcnRv
QGhwY2YudXByLmVkdT4NCgkgICAgR2FicmllbCBEb3MgUmVpcyAgPGdkckBj
cy50YW11LmVkdT4NCg0KCSogY29uZmlndXJlLmFjLnBhbXBobGV0ICg8PGdj
bCBvcHRpb25zPj4pOiBTcGxpdCBHQ0xPUFRTIGluDQoJb3J0aG9nb25hbCB2
YXJpYWJsZXMuICBXaGVuIGJ1aWxkaW5nIEdDTCwgZGlzYWJsZSBzdXBwb3J0
IGZvcg0KCVggV2luZG93IHN5c3RlbSBhbmQgVEsuICBMb3NlIC0tZW5hYmxl
LWN1c3RyZWxvYyBmb3IgTUFDIE9TLg0KCSogY29uZmlndXJlLmluOiBSZWdl
bmVyYXRlLg0KCSogY29uZmlndXJlIiBMaWtld3NlLg0KDQoqKiogY29uZmln
dXJlCShyZXZpc2lvbiAxNjg3MSkNCi0tLSBjb25maWd1cmUJKGxvY2FsKQ0K
KioqKioqKioqKioqKioqIGFjX2N2X2xpYl9iZmQ9YWNfY3ZfbGliX2JmZF9t
YWluDQoqKiogNTQ4NCw1NDk2ICoqKioNCiAgYXhpb21fZ2NsX2JmZF9vcHRp
b249DQogIGlmIHRlc3QgeCIkYXhpb21faG9zdF9oYXNfYmZkX2giID0geHll
cyBcDQogICAgICAmJiB0ZXN0IHgiJGF4aW9tX2hvc3RfaGFzX2xpYmJmZCIg
PSB4eWVzOyB0aGVuDQohICAgICBheGlvbV9nY2xfYmZkX29wdGlvbj0iLS1l
bmFibGUtc3RhdHN5c2JmZCINCiAgZWxzZQ0KICAgICAgYXhpb21fZ2NsX2Jm
ZF9vcHRpb249Ii0tZGlzYWJsZS1zdGF0c3lzYmZkIC0tZW5hYmxlLWxvY2Jm
ZCINCiAgZmkNCiEgDQohIEdDTE9QVFM9Ii0tZW5hYmxlLXZzc2l6ZT02NTUz
NioyIC0tZGlzYWJsZS1keW5zeXNiZmQgXA0KISAgICAgICAgICAgICAkYXhp
b21fZ2NsX2JmZF9vcHRpb24gLS1lbmFibGUtbWF4cGFnZT0yNTYqMTAyNCIN
CiAgDQogIFBGTD0NCiAgQ0NGPSItTzIgLWZuby1zdHJlbmd0aC1yZWR1Y2Ug
LVdhbGwgLURfR05VX1NPVVJDRSAtRFwke1BMRn0iDQotLS0gNTQ4NCw1NDk1
IC0tLS0NCiAgYXhpb21fZ2NsX2JmZF9vcHRpb249DQogIGlmIHRlc3QgeCIk
YXhpb21faG9zdF9oYXNfYmZkX2giID0geHllcyBcDQogICAgICAmJiB0ZXN0
IHgiJGF4aW9tX2hvc3RfaGFzX2xpYmJmZCIgPSB4eWVzOyB0aGVuDQohICAg
ICBheGlvbV9nY2xfYmZkX29wdGlvbj0iLS1lbmFibGUtc3RhdHN5c2JmZCAt
LWRpc2FibGUtZHluc3lzYmZkIg0KICBlbHNlDQogICAgICBheGlvbV9nY2xf
YmZkX29wdGlvbj0iLS1kaXNhYmxlLXN0YXRzeXNiZmQgLS1lbmFibGUtbG9j
YmZkIg0KICBmaQ0KISBheGlvbV9nY2xfbW1fb3B0aW9uPSItLWVuYWJsZS12
c3NpemU9NjU1MzYqMiAtLWVuYWJsZS1tYXhwYWdlPTI1NioxMDI0Ig0KISBh
eGlvbV9nY2xfeF9vcHRpb249Ii0tZGlzYWJsZS10a2NvbmZpZyAtLWRpc2Fi
bGUteCAtLWRpc2FibGUteGdjbCINCiAgDQogIFBGTD0NCiAgQ0NGPSItTzIg
LWZuby1zdHJlbmd0aC1yZWR1Y2UgLVdhbGwgLURfR05VX1NPVVJDRSAtRFwk
e1BMRn0iDQoqKioqKioqKioqKioqKiogY2FzZSAkdGFyZ2V0IGluDQoqKiog
NTUxMyw1NTI4ICoqKioNCiAgICAgICpzb2xhcmlzKikNCiAgICAgICAgICBQ
TEY9U1VOcGxhdGZvcm0NCiAgICAgICAgICA7Ow0KISAgICAgKmRhcndpbiop
DQogICAgICAgICAgUExGPU1BQ09TWHBsYXRmb3JtDQogICAgICAgICAgQ0NG
PSItTzIgLWZuby1zdHJlbmd0aC1yZWR1Y2UgLVdhbGwgLURfR05VX1NPVVJD
RSAtRCR7UExGfSBcDQogICAgICAgICAgICAgIC1JL3Vzci9pbmNsdWRlIC1J
L3Vzci9pbmNsdWRlL3N5cyINCiEgICAgICAgICBHQ0xPUFRTPSItLWVuYWJs
ZS12c3NpemU9NjU1MzYqMiAtLWVuYWJsZS1tYXhwYWdlPTI1NioxMDI0IC0t
ZGlzYWJsZS1sb2NiZmQgXA0KISAgICAgICAgICAgICAtLWRpc2FibGUtc3Rh
dHN5c2JmZCAgLS1lbmFibGUtY3VzdHJlbG9jIC0tZGlzYWJsZS10a2NvbmZp
ZyBcDQohICAgICAgICAgICAgIC0tZW5hYmxlLW1hY2hpbmU9cHdlcnBjLW1h
Y29zeCINCiAgICAgICAgICA7Ow0KICBlc2FjDQogIA0KICANCiAgDQogIA0K
LS0tIDU1MTIsNTUyOCAtLS0tDQogICAgICAqc29sYXJpcyopDQogICAgICAg
ICAgUExGPVNVTnBsYXRmb3JtDQogICAgICAgICAgOzsNCiEgICAgIHBvd2Vy
cGMqZGFyd2luKikNCiAgICAgICAgICBQTEY9TUFDT1NYcGxhdGZvcm0NCiAg
ICAgICAgICBDQ0Y9Ii1PMiAtZm5vLXN0cmVuZ3RoLXJlZHVjZSAtV2FsbCAt
RF9HTlVfU09VUkNFIC1EJHtQTEZ9IFwNCiAgICAgICAgICAgICAgLUkvdXNy
L2luY2x1ZGUgLUkvdXNyL2luY2x1ZGUvc3lzIg0KISAgICAgICAgIGF4aW9t
X2djbF9iZmRfb3B0aW9uPSItLWVuYWJsZS1sb2NiZmQgLS1kaXNhYmxlLXN0
YXRzeXNiZmQgXA0KISAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IC0tZW5hYmxlLW1hY2hpbmU9cG93ZXJwYy1tYWNvc3giDQogICAgICAgICAg
OzsNCiAgZXNhYw0KICANCisgR0NMT1BUUz0iJGF4aW9tX2djbF9iZmRfb3B0
aW9uICRheGlvbV9nY2xfbW1fb3B0aW9uICRheGlvbV9nY2xfeF9vcHRpb24i
DQorIA0KICANCiAgDQogIA0KKioqIGNvbmZpZ3VyZS5hYwkocmV2aXNpb24g
MTY4NzEpDQotLS0gY29uZmlndXJlLmFjCShsb2NhbCkNCioqKioqKioqKioq
KioqKiBBQ19IQVZFX0xJQlJBUlkoW2JmZF0sIFtheGlvbV9ob3N0X2hhc19s
DQoqKiogMTkxLDIwMyAqKioqDQogIGF4aW9tX2djbF9iZmRfb3B0aW9uPQ0K
ICBpZiB0ZXN0IHgiJGF4aW9tX2hvc3RfaGFzX2JmZF9oIiA9IHh5ZXMgXA0K
ICAgICAgJiYgdGVzdCB4IiRheGlvbV9ob3N0X2hhc19saWJiZmQiID0geHll
czsgdGhlbg0KISAgICAgYXhpb21fZ2NsX2JmZF9vcHRpb249Ii0tZW5hYmxl
LXN0YXRzeXNiZmQiDQogIGVsc2UNCiAgICAgIGF4aW9tX2djbF9iZmRfb3B0
aW9uPSItLWRpc2FibGUtc3RhdHN5c2JmZCAtLWVuYWJsZS1sb2NiZmQiDQog
IGZpDQohIA0KISBHQ0xPUFRTPSItLWVuYWJsZS12c3NpemU9NjU1MzYqMiAt
LWRpc2FibGUtZHluc3lzYmZkIFwNCiEgICAgICAgICAgICAgJGF4aW9tX2dj
bF9iZmRfb3B0aW9uIC0tZW5hYmxlLW1heHBhZ2U9MjU2KjEwMjQiDQogIA0K
ICBQRkw9DQogIENDRj0iLU8yIC1mbm8tc3RyZW5ndGgtcmVkdWNlIC1XYWxs
IC1EX0dOVV9TT1VSQ0UgLURcJHtQTEZ9Ig0KLS0tIDE5MSwyMDIgLS0tLQ0K
ICBheGlvbV9nY2xfYmZkX29wdGlvbj0NCiAgaWYgdGVzdCB4IiRheGlvbV9o
b3N0X2hhc19iZmRfaCIgPSB4eWVzIFwNCiAgICAgICYmIHRlc3QgeCIkYXhp
b21faG9zdF9oYXNfbGliYmZkIiA9IHh5ZXM7IHRoZW4NCiEgICAgIGF4aW9t
X2djbF9iZmRfb3B0aW9uPSItLWVuYWJsZS1zdGF0c3lzYmZkIC0tZGlzYWJs
ZS1keW5zeXNiZmQiDQogIGVsc2UNCiAgICAgIGF4aW9tX2djbF9iZmRfb3B0
aW9uPSItLWRpc2FibGUtc3RhdHN5c2JmZCAtLWVuYWJsZS1sb2NiZmQiDQog
IGZpDQohIGF4aW9tX2djbF9tbV9vcHRpb249Ii0tZW5hYmxlLXZzc2l6ZT02
NTUzNioyIC0tZW5hYmxlLW1heHBhZ2U9MjU2KjEwMjQiDQohIGF4aW9tX2dj
bF94X29wdGlvbj0iLS1kaXNhYmxlLXRrY29uZmlnIC0tZGlzYWJsZS14IC0t
ZGlzYWJsZS14Z2NsIg0KICANCiAgUEZMPQ0KICBDQ0Y9Ii1PMiAtZm5vLXN0
cmVuZ3RoLXJlZHVjZSAtV2FsbCAtRF9HTlVfU09VUkNFIC1EXCR7UExGfSIN
CioqKioqKioqKioqKioqKiBjYXNlICR0YXJnZXQgaW4NCioqKiAyMjAsMjM1
ICoqKioNCiAgICAgICpzb2xhcmlzKikNCiAgICAgICAgICBQTEY9U1VOcGxh
dGZvcm0NCiAgICAgICAgICA7Ow0KISAgICAgKmRhcndpbiopDQogICAgICAg
ICAgUExGPU1BQ09TWHBsYXRmb3JtDQogICAgICAgICAgQ0NGPSItTzIgLWZu
by1zdHJlbmd0aC1yZWR1Y2UgLVdhbGwgLURfR05VX1NPVVJDRSAtRCR7UExG
fSBcDQogICAgICAgICAgICAgIC1JL3Vzci9pbmNsdWRlIC1JL3Vzci9pbmNs
dWRlL3N5cyINCiEgICAgICAgICBHQ0xPUFRTPSItLWVuYWJsZS12c3NpemU9
NjU1MzYqMiAtLWVuYWJsZS1tYXhwYWdlPTI1NioxMDI0IC0tZGlzYWJsZS1s
b2NiZmQgXA0KISAgICAgICAgICAgICAtLWRpc2FibGUtc3RhdHN5c2JmZCAg
LS1lbmFibGUtY3VzdHJlbG9jIC0tZGlzYWJsZS10a2NvbmZpZyBcDQohICAg
ICAgICAgICAgIC0tZW5hYmxlLW1hY2hpbmU9cHdlcnBjLW1hY29zeCINCiAg
ICAgICAgICA7Ow0KICBlc2FjDQogIA0KICBBQ19TVUJTVChQTEYpDQogIEFD
X1NVQlNUKENDRikNCiAgQUNfU1VCU1QoTERGKQ0KLS0tIDIxOSwyMzUgLS0t
LQ0KICAgICAgKnNvbGFyaXMqKQ0KICAgICAgICAgIFBMRj1TVU5wbGF0Zm9y
bQ0KICAgICAgICAgIDs7DQohICAgICBwb3dlcnBjKmRhcndpbiopDQogICAg
ICAgICAgUExGPU1BQ09TWHBsYXRmb3JtDQogICAgICAgICAgQ0NGPSItTzIg
LWZuby1zdHJlbmd0aC1yZWR1Y2UgLVdhbGwgLURfR05VX1NPVVJDRSAtRCR7
UExGfSBcDQogICAgICAgICAgICAgIC1JL3Vzci9pbmNsdWRlIC1JL3Vzci9p
bmNsdWRlL3N5cyINCiEgICAgICAgICBheGlvbV9nY2xfYmZkX29wdGlvbj0i
LS1lbmFibGUtbG9jYmZkIC0tZGlzYWJsZS1zdGF0c3lzYmZkIFwNCiEgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLWVuYWJsZS1tYWNoaW5l
PXBvd2VycGMtbWFjb3N4Ig0KICAgICAgICAgIDs7DQogIGVzYWMNCiAgDQor
IEdDTE9QVFM9IiRheGlvbV9nY2xfYmZkX29wdGlvbiAkYXhpb21fZ2NsX21t
X29wdGlvbiAkYXhpb21fZ2NsX3hfb3B0aW9uIg0KKyANCiAgQUNfU1VCU1Qo
UExGKQ0KICBBQ19TVUJTVChDQ0YpDQogIEFDX1NVQlNUKExERikNCioqKiBj
b25maWd1cmUuYWMucGFtcGhsZXQJKHJldmlzaW9uIDE2ODcxKQ0KLS0tIGNv
bmZpZ3VyZS5hYy5wYW1waGxldAkobG9jYWwpDQoqKioqKioqKioqKioqKiog
QUNfSEFWRV9MSUJSQVJZKFtiZmRdLCBbYXhpb21faG9zdF9oYXNfbA0KKioq
IDQ2Niw0NzggKioqKg0KICBheGlvbV9nY2xfYmZkX29wdGlvbj0NCiAgaWYg
dGVzdCB4IiRheGlvbV9ob3N0X2hhc19iZmRfaCIgPSB4eWVzIFwNCiAgICAg
ICYmIHRlc3QgeCIkYXhpb21faG9zdF9oYXNfbGliYmZkIiA9IHh5ZXM7IHRo
ZW4NCiEgICAgIGF4aW9tX2djbF9iZmRfb3B0aW9uPSItLWVuYWJsZS1zdGF0
c3lzYmZkIg0KICBlbHNlDQogICAgICBheGlvbV9nY2xfYmZkX29wdGlvbj0i
LS1kaXNhYmxlLXN0YXRzeXNiZmQgLS1lbmFibGUtbG9jYmZkIg0KICBmaQ0K
ICANCiEgR0NMT1BUUz0iLS1lbmFibGUtdnNzaXplPTY1NTM2KjIgLS1kaXNh
YmxlLWR5bnN5c2JmZCBcDQohICAgICAgICAgICAgICRheGlvbV9nY2xfYmZk
X29wdGlvbiAtLWVuYWJsZS1tYXhwYWdlPTI1NioxMDI0Ig0KICBADQogIA0K
ICBPdGhlciBhc3BlY3RzIGRlcGVuZCBvbiB0aGUgcGxhdGZvcm0gYmVpbmcg
Y29uc2lkZXJlZC4NCi0tLSA0NjYsNDg4IC0tLS0NCiAgYXhpb21fZ2NsX2Jm
ZF9vcHRpb249DQogIGlmIHRlc3QgeCIkYXhpb21faG9zdF9oYXNfYmZkX2gi
ID0geHllcyBcDQogICAgICAmJiB0ZXN0IHgiJGF4aW9tX2hvc3RfaGFzX2xp
YmJmZCIgPSB4eWVzOyB0aGVuDQohICAgICBheGlvbV9nY2xfYmZkX29wdGlv
bj0iLS1lbmFibGUtc3RhdHN5c2JmZCAtLWRpc2FibGUtZHluc3lzYmZkIg0K
ICBlbHNlDQogICAgICBheGlvbV9nY2xfYmZkX29wdGlvbj0iLS1kaXNhYmxl
LXN0YXRzeXNiZmQgLS1lbmFibGUtbG9jYmZkIg0KICBmaQ0KKyBADQorIA0K
KyBHQ0wgaGFzIGFuIGVsYWJvcmF0ZSBtZW1vcnkgbWFuYWdlbWVudCBzeXN0
ZW0gYW5kIEF4aW9tIHNlZW1zIHRvIA0KKyBwdXQgYGB1bnVzdWFsJycgcHJl
c3N1cmUgb24gaXQuICBIZXJlIHdlIHNwZWNpZnkgc29tZSB2YWx1ZXMgdGhh
dCBoYXZlDQorIGJlZW4gZW1waXJpY2FsbHkga25vd24gdG8gd29yay4NCisg
PDxnY2wgb3B0aW9ucz4+PQ0KKyBheGlvbV9nY2xfbW1fb3B0aW9uPSItLWVu
YWJsZS12c3NpemU9NjU1MzYqMiAtLWVuYWJsZS1tYXhwYWdlPTI1NioxMDI0
Ig0KKyBADQogIA0KISBGdXJ0aGVybW9yZSwgd2UgZG9uJ3QgbmVlZCAoYXQg
dGhlIG1vbWVudCkgR0NMIHRvIGJ1aWxkIHN1cHBvcnQgZm9yDQohIFggV2lu
ZG93IHN5c3RlbSBvciBUSzoNCiEgPDxnY2wgb3B0aW9ucz4+PQ0KISBheGlv
bV9nY2xfeF9vcHRpb249Ii0tZGlzYWJsZS10a2NvbmZpZyAtLWRpc2FibGUt
eCAtLWRpc2FibGUteGdjbCINCiAgQA0KICANCiAgT3RoZXIgYXNwZWN0cyBk
ZXBlbmQgb24gdGhlIHBsYXRmb3JtIGJlaW5nIGNvbnNpZGVyZWQuDQoqKioq
KioqKioqKioqKiogY2FzZSAkdGFyZ2V0IGluDQoqKiogNTA0LDUxOSAqKioq
DQogICAgICAqc29sYXJpcyopDQogICAgICAgICAgUExGPVNVTnBsYXRmb3Jt
DQogIAk7Ow0KISAgICAgKmRhcndpbiopDQogICAgICAgICAgUExGPU1BQ09T
WHBsYXRmb3JtDQogIAlDQ0Y9Ii1PMiAtZm5vLXN0cmVuZ3RoLXJlZHVjZSAt
V2FsbCAtRF9HTlVfU09VUkNFIC1EJHtQTEZ9IFwNCiAgCSAgICAtSS91c3Iv
aW5jbHVkZSAtSS91c3IvaW5jbHVkZS9zeXMiDQohIAlHQ0xPUFRTPSItLWVu
YWJsZS12c3NpemU9NjU1MzYqMiAtLWVuYWJsZS1tYXhwYWdlPTI1NioxMDI0
IC0tZGlzYWJsZS1sb2NiZmQgXA0KISAJICAgIC0tZGlzYWJsZS1zdGF0c3lz
YmZkICAtLWVuYWJsZS1jdXN0cmVsb2MgLS1kaXNhYmxlLXRrY29uZmlnIFwN
CiEgCSAgICAtLWVuYWJsZS1tYWNoaW5lPXB3ZXJwYy1tYWNvc3giDQogIAk7
Ow0KICBlc2FjDQogIA0KICBBQ19TVUJTVChQTEYpDQogIEFDX1NVQlNUKEND
RikNCiAgQUNfU1VCU1QoTERGKQ0KLS0tIDUxNCw1MzAgLS0tLQ0KICAgICAg
KnNvbGFyaXMqKQ0KICAgICAgICAgIFBMRj1TVU5wbGF0Zm9ybQ0KICAJOzsN
CiEgICAgIHBvd2VycGMqZGFyd2luKikNCiAgICAgICAgICBQTEY9TUFDT1NY
cGxhdGZvcm0NCiAgCUNDRj0iLU8yIC1mbm8tc3RyZW5ndGgtcmVkdWNlIC1X
YWxsIC1EX0dOVV9TT1VSQ0UgLUQke1BMRn0gXA0KICAJICAgIC1JL3Vzci9p
bmNsdWRlIC1JL3Vzci9pbmNsdWRlL3N5cyINCiEgICAgICAgICBheGlvbV9n
Y2xfYmZkX29wdGlvbj0iLS1lbmFibGUtbG9jYmZkIC0tZGlzYWJsZS1zdGF0
c3lzYmZkIFwNCiEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt
LWVuYWJsZS1tYWNoaW5lPXBvd2VycGMtbWFjb3N4Ig0KICAJOzsNCiAgZXNh
Yw0KICANCisgR0NMT1BUUz0iJGF4aW9tX2djbF9iZmRfb3B0aW9uICRheGlv
bV9nY2xfbW1fb3B0aW9uICRheGlvbV9nY2xfeF9vcHRpb24iDQorIA0KICBB
Q19TVUJTVChQTEYpDQogIEFDX1NVQlNUKENDRikNCiAgQUNfU1VCU1QoTERG
KQ0K

\start
Date: 15 Nov 2006 17:02:06 +0100
From: Gabriel Dos Reis
To: list
Subject: boottocl and boottoclc

The main difference between boottran::boottocl and boottran::boottoclc
is that the latter includes the Boot codes (as comment) in
translation.

Well, that is the theory.

In practice, they happen to translate very subtly in different ways.
I think the reason for that is bug instead of design.

boottran::boottocl translates Boot code while in the scope of the 
package boottran.  boottran::boottoclc does not.  Consequently, 
boottoclc would translate (Boot) "not" to (Lisp) "|not|", when in fact
it should have translated to (Lisp) "NOT".

One possible fix is to have boottoclc push into package boottran
before doing the translation.  This would have to be done for all
callers of boottocllines.  That is not good.  So, I'm considering
fixing boottocllines instead.

If you know more about this, please let me know.

\start
Date: 15 Nov 2006 17:55:54 +0100
From: Francois Maltey
To: list
Subject: )set expose add constructor doesn't expose

Hello,

I test my own expand function in its package UsualExpand.
The code is in ~/Axiom/expand.spad file.

I can compile this function without problem.
)cd 
)cd Axiom
)co expand.spad

When I run a new axiom session I use this function by :

)cd                    -- go to the home diectory
)cd Axiom
)library USEXPAND
expand (cos (2*x))$UsualExpand(Integer,Expression Integer)
gives me cos x^2 - sin x^2.

Then I want to remplace in this axiom session the old expand in 
TranscendentalManipulations(Integer, Expression Integer) by this expand.

So I test :
)cd 
)cd Axiom
)set expose drop constructor TranscendentalManipulations
)library USEXPAND
)set expose add constructor UsualExpand

But expand (cos (2*x)) uses the original expand, not the new expand.

What must I correct in this code ?

Can I use a parameter on the command line in order to set path and 
initialisation of axiom ?

There are some *.input files for testing axiom in the main axiom Makefile.
How can I rerun them and compare the results between the native expand
command and mine ?

\start
Date: Wed, 15 Nov 2006 12:14:57 -0500
From: Bill Page
To: Gabriel Dos Reis, Waldek Hebisch
Subject: RE: Ping: case insensitive filesystems

On Wednesday, November 15, 2006 10:48 AM Gaby wrote:
>
> Bill Page writes:
>
> [...]
>
> | My suggestiong is that when we start to work on a patch, we first
> | ask on the axiom-developer list for someone to play the role of
> | 2nd person. Perhaps this is a way for people who do not yet feel
> | bold enough to work on Axiom themselves yet to get started.
>
> That would definitely increase the among of shared knowledge.
>
> | Yes, I would agree to act as the 2nd person and write such
> | documentation from time to time. :-)
>
> OK, you're officially appointed as that second person :-)
>

Here is my proposed documentation patch to src/hyper/Makefile:

$ diff -au Makefile.pamphlet_orig Makefile.pamphlet

--- Makefile.pamphlet_orig      2006-11-12 22:20:19.000000000 -0600
+++ Makefile.pamphlet   2006-11-15 11:11:09.000000000 -0600
@@ -145,6 +145,11 @@


 \section{bitmaps}
+There are two files for each (special) character glyph, one
+for the upper case form, and one for the lower case form.
+For more information about hese bitmaps see 'util.ht' in the
+section 'pages', below.
+
 <<bitmaps>>=
 mouse11.bitmap: $(srcdir)/bitmaps.pamphlet
        $(axiom_build_document) --tangle=mouse11.bitmap --output=$@ =
$<
@@ -236,6 +241,17 @@
 @

 \section{pages}
+The 'ht.db' is built when pages from 'src/hyper/pages' such as
'util.ht'
+and 'util.pht' are installed in the target directory. Because the .db
+file must be kept in sync with the page filesof course care must be
+taken not to overwrite these files at a later time without re-building
+the database.
+
+The Axiom system from which this branch had been made appears
+to contain a redundant copy of util.ht. Removing the version of
+'util.ht' in 'src/share/doc/hypertex/pages/util.ht' would make
+Makefile logic simpler has been removed so as to minimize problems
+when this file is updated.

 The [[.pht]] files contain hardcoded pathnames to viewport directories
 in the installed system.  Of course, that is asking for trouble.
During
@@ -259,8 +275,19 @@
              ${HTADD} *.ht *.pht
 \end{verbatim}

-To avoid conflicts on case-insensitive filesytems we renamed
[[poly.ht]]
-to [[polys.ht]] and [[poly.pht]] to [[polys.pht]].
+On case-insensitive filesytems such as Windows and traditional Mac
+checkout from the source archive can fail if files have names
+differing only in case: poly.ht contra POLY.ht and
+poly.pht contra POLY.pht. To avoid conflicts on case-insensitive
+filesytems we renamed [[poly.ht]] to [[polys.ht]] and [[poly.pht]]
+to [[polys.pht]].
+
+The page [[util.ht]] refers to two files for each (special) character
+glyph, one for the upper case form, and one for the lower case form.
+The names for these files avoid the use of upper and lower letters
+to distinguish these forms. Intstead we use 'xxx.bitmap' for lower case
+and 'xxx-cap.bitmap' for upper case, where "xxx" is the common name for
+the glyth. For example alpha.bitmap and alpha-cap.bitmape.

 We need to make sure that [[ht.db]], the hypertex database file
 is up to date. The file contains absolute offsets into the various

\start
Date: 15 Nov 2006 18:46:50 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Ping: case insensitive filesystems

Bill Page writes:

| On Wednesday, November 15, 2006 10:48 AM Gaby wrote:
| > 
| > Bill Page writes:
| > 
| > [...]
| > 
| > | My suggestiong is that when we start to work on a patch, we first
| > | ask on the axiom-developer list for someone to play the role of
| > | 2nd person. Perhaps this is a way for people who do not yet feel
| > | bold enough to work on Axiom themselves yet to get started.
| > 
| > That would definitely increase the among of shared knowledge.
| > 
| > | Yes, I would agree to act as the 2nd person and write such
| > | documentation from time to time. :-)
| > 
| > OK, you're officially appointed as that second person :-)
| > 
| 
| Here is my proposed documentation patch to src/hyper/Makefile:

That is excellent!  Go!

\start
Date: Wed, 15 Nov 2006 09:52:50 -0800
From: Simon Michael
To: list
Subject: Re: The 30 Year Horizon

Bravo! Thank you Tim. Your work and writings are inspiring.

\start
Date: Wed, 15 Nov 2006 20:42:49 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Loading of databases

The following patch makes caching of databases effective and
reduces startup time of AXIOMsys.  Debian uses similar patch
and claims huge reduction of time needed to run tests, but
for me test time remained effectively unchanged.

diff -ru build-improvements.bb/src/etc/Makefile.in build-improvements/src/etc/Makefile.in
--- build-improvements.bb/src/etc/Makefile.in	2006-11-15 13:15:29.000000000 +0100
+++ build-improvements/src/etc/Makefile.in	2006-11-15 13:46:07.000000000 +0100
@@ -14,6 +14,7 @@
 		$(axiom_target_libdir)/summary \
 		$(axiom_target_libdir)/copyright \
 		$(axiom_target_bindir)/axiom
+	(cd ../interp && $(ENV) $(MAKE) axiomsys)
 	@echo 6 finished $(builddir)
 	-rm -f stamp
 	$(STAMP) stamp
diff -ru build-improvements.bb/src/etc/Makefile.pamphlet build-improvements/src/etc/Makefile.pamphlet
--- build-improvements.bb/src/etc/Makefile.pamphlet	2006-11-15 13:15:29.000000000 +0100
+++ build-improvements/src/etc/Makefile.pamphlet	2006-11-15 13:23:43.000000000 +0100
@@ -102,6 +102,7 @@
 		$(axiom_target_libdir)/summary \
 		$(axiom_target_libdir)/copyright \
 		$(axiom_target_bindir)/axiom
+	(cd ../interp && $(ENV) $(MAKE) axiomsys)
 	@echo 6 finished $(builddir)
 	-rm -f stamp
 	$(STAMP) stamp
diff -ru build-improvements.bb/src/interp/daase.lisp.pamphlet build-improvements/src/interp/daase.lisp.pamphlet
--- build-improvements.bb/src/interp/daase.lisp.pamphlet	2006-11-15 13:15:27.000000000 +0100
+++ build-improvements/src/interp/daase.lisp.pamphlet	2006-11-15 13:44:32.000000000 +0100
@@ -56,9 +56,13 @@
 into the image before it is saved. The system would be easier to
 understand and the interpreter would be faster.
 
-The fastest optimization is to fix the time stamp mechanism
-which is currently broken. Making this work requires a small
-bit of coordination at 'make' time which I forgot to implement.
+The system uses another optimization: database contains a stamp
+(consisting of offset to the main list and build time).  Before
+saving the image selected data is fetched to memory.  When the
+saved image starts it checks if the stamp of saved data matches
+in-core data -- in case of agreement in-core data is used.
+Parts of the datatabase which was not pre-loaded is still
+(lazily) fetched from the filesystem.
 
 \subsection{Database Files}
 
diff -ru build-improvements.bb/src/interp/Makefile.in build-improvements/src/interp/Makefile.in
--- build-improvements.bb/src/interp/Makefile.in	2006-11-15 13:15:27.000000000 +0100
+++ build-improvements/src/interp/Makefile.in	2006-11-15 18:03:42.000000000 +0100
@@ -365,7 +365,8 @@
 distclean-local: clean-local
 
 $(SAVESYS): $(axiom_build_bindir)
-${SAVESYS}:	${DEPSYS} ${OBJS} ${OUT}/bookvol5.$(OBJEXT) ${OUT}/util.$(OBJEXT) \
+
+${OUT}/makeint.lisp:	${DEPSYS} ${OBJS} ${OUT}/bookvol5.$(OBJEXT) ${OUT}/util.$(OBJEXT) \
                 nocompil.lisp sys-pkg.lisp \
 	        ${OUTINTERP} ${OCOBJS} ${OPOBJS} ${BROBJS} ${OUT}/obey.$(OBJEXT) \
 		${OUT}/database.date ${INOBJS} ${ASCOMP} ${ASAUTO} \
@@ -405,12 +406,11 @@
 	@ echo '(load "${OUT}/obey")' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (si::gbc-time 0)' >> ${OUT}/makeint.lisp
+
+${SAVESYS}: ${OUT}/makeint.lisp
 	@echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) (user::spad-save "$@"))' | ${LISPSYS}
 	@ echo 6 ${SAVESYS} created
 	$(mkinstalldirs) $(axiom_target_bindir)
-	@ $(INSTALL_PROGRAM) $(SAVESYS) $(AXIOMSYS)
-	@ echo 6a ${AXIOMSYS} created
-
 depsys_lisp_sources += parsing.lisp metalex.lisp bootlex.lisp \
 			newaux.lisp preparse.lisp postprop.lisp \
 			metameta.lisp fnewmeta.lisp
@@ -483,6 +483,14 @@
 	@ echo '(progn (load "makedep.lisp") (spad-save "$@"))' \
                | ${LISPSYS}
 	@ echo 4 ${DEPSYS} created
+.PHONY: axiomsys
+
+axiomsys: ${AXIOMSYS}
+
+${AXIOMSYS}: ${OUT}/makeint.lisp
+	@echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t)' \
+	   '(user::spad-save "$@"))' | DAASE=$(axiom_targetdir) ${LISPSYS}
+	@ echo 6a ${AXIOMSYS} created
 ${DEBUGSYS}: ${MID}/debugsys.lisp
 	@ echo 7 building debugsys
 	@ echo '(progn (gbc t) (load "${MID}/debugsys.lisp") (user::spad-save "$@"))' | ${LISPSYS}
diff -ru build-improvements.bb/src/interp/Makefile.pamphlet build-improvements/src/interp/Makefile.pamphlet
--- build-improvements.bb/src/interp/Makefile.pamphlet	2006-11-15 13:15:27.000000000 +0100
+++ build-improvements/src/interp/Makefile.pamphlet	2006-11-15 17:08:33.000000000 +0100
@@ -1008,7 +1008,8 @@
 
 <<savesys>>=
 $(SAVESYS): $(axiom_build_bindir)
-${SAVESYS}:	${DEPSYS} ${OBJS} ${OUT}/bookvol5.$(OBJEXT) ${OUT}/util.$(OBJEXT) \
+
+${OUT}/makeint.lisp:	${DEPSYS} ${OBJS} ${OUT}/bookvol5.$(OBJEXT) ${OUT}/util.$(OBJEXT) \
                 nocompil.lisp sys-pkg.lisp \
 	        ${OUTINTERP} ${OCOBJS} ${OPOBJS} ${BROBJS} ${OUT}/obey.$(OBJEXT) \
 		${OUT}/database.date ${INOBJS} ${ASCOMP} ${ASAUTO} \
@@ -1048,12 +1049,29 @@
 	@ echo '(load "${OUT}/obey")' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (si::gbc-time 0)' >> ${OUT}/makeint.lisp
+
+${SAVESYS}: ${OUT}/makeint.lisp
 	@echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) (user::spad-save "$@"))' | ${LISPSYS}
 	@ echo 6 ${SAVESYS} created
 	$(mkinstalldirs) $(axiom_target_bindir)
-	@ $(INSTALL_PROGRAM) $(SAVESYS) $(AXIOMSYS)
-	@ echo 6a ${AXIOMSYS} created
+@
+
+\section{Building SAVESYS and AXIOMSYS}
 
+We want to cache database data in the final image, so we dump it only
+after databases are build (triggered from \File{etc/Makefile.pamphlet}).
+Note that having dependency on databases is not enough, since databases
+are re-generated after leaving \File{interp/} directory.
+
+<<axiomsys>>=
+.PHONY: axiomsys
+
+axiomsys: ${AXIOMSYS}
+
+${AXIOMSYS}: ${OUT}/makeint.lisp
+	@echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t)' \
+	   '(user::spad-save "$@"))' | DAASE=$(axiom_targetdir) ${LISPSYS}
+	@ echo 6a ${AXIOMSYS} created
 @
 
 \section{Building debugsys}
@@ -4597,6 +4615,7 @@
 
 <<savesys>>
 <<depsys>>
+<<axiomsys>>
 <<debugsys>>
 <<databases>>
 
\start
Date: Wed, 15 Nov 2006 20:48:52 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: wh-sandbox

I created now a new branch named wh-sandbox.  ATM there only new file
id README.wh, but in few days there will be more changes.

\start
Date: 15 Nov 2006 21:01:04 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Loading of databases

Waldek Hebisch writes:

[...]

| +The system uses another optimization: database contains a stamp
| +(consisting of offset to the main list and build time).  Before
| +saving the image selected data is fetched to memory.  When the
| +saved image starts it checks if the stamp of saved data matches
| +in-core data -- in case of agreement in-core data is used.
| +Parts of the datatabase which was not pre-loaded is still
| +(lazily) fetched from the filesystem.

OK; thanks!

\start
Date: Thu, 16 Nov 2006 00:15:13 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: FW: data structure vs. mathematical structure

> The definition you gave is it: least fixed point of
>
>     X |-> 1 + T =D7 X =D7 X

Hmmm, good question. In Aldor-combinat (AC) we deal with combinatorial
species. They encode actual structures. The corresponding generating
series G(x) for binary trees given by your X above has to fulfil the
equation

G(x) = 1 + x * G(x) * G(x)                                (+)

As a quadratic formula it has at most 2 solutions. And only one of those =

solution is a power series with only non-negative coefficients. Since I
don't know what it should mean to say "there are -5 trees with 3 nodes", =

it is clear which solution I choose for the generating series.

Assuming that I understand a bit of the theory of species, then there is =

only *one* solution to

      X = 1 + T * X * X.

We are not yet dealing with "virtual species" which would allow negative =

coefficients in the generating series.

> The interesting bit about those inductive definition is that they come
> with "fold" (reduce in Axiom-speak) for free.

Hmmm, lazyness is important here. Unfortunately the internal definition
of formal power series in AC does not allow to write equation (+) as
such. One first has to say (something like)

g: FormalPowerSeries Integer := new();
set!(g, 1+x*g*g);

where x corresponds to the inteterminate of "FormalPowerSeries Integer".

> | Recently, Martin Rubey has done some work to make Aldor-combinat
> | available for Axiom, but for the underlying compilation we still need=

> | the Aldor compiler. So, Gaby, I consider Aldor-combinat a testcase fo=
r
> | the compiler-improvements branch. ;-)

> OK, I don't feel it like a pressure :-) :-)

No. No pressure intended. It's just something to motivate you. ;-)

\start
Date: Wed, 15 Nov 2006 18:49:32 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Ping: case insensitive filesystems

On Wednesday, November 15, 2006 12:47 PM Gaby wrote:
> ...
> Bill Page wrote:
> | Here is my proposed documentation patch to src/hyper/Makefile:
>
> That is excellent!  Go!
>

Ok, done. I compiled Axiom with the two patches - one for file renames
and one for file cleanup

http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00294.ht
ml

http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00297.ht
ml

plus the documentation on the axiom-developer.org server with no
problems.
Then I committed this to build-improvements as revision  272. Oops, I
guess
you asked that they be separate commits... Sorry. But the changes are
simple
and related so perhaps better treated as one anyway.

BTW, the output of the algebra/Makefile looks a little strange:

...
rm -rf /home/page/axiom.test/int/algebra/FTEM.NRLIB
copying FTEM.NRLIB to FTEM.o
compiling GENEEZ.spad to GENEEZ.NRLIB
rm -rf /home/page/axiom.test/int/algebra/GENEEZ.NRLIB
copying GENEEZ.NRLIB to GENEEZ.o
compiling GENMFACT.spad to GENMFACT.NRLIB
rm -rf /home/page/axiom.test/int/algebra/GENMFACT.NRLIB
copying GENMFACT.NRLIB to GENMFACT.o
...

Notice how it appears as if the *.NRLIB directory is deleted before
*.NRLIB/code.o is copied! :-) I am sure it is ok but we need to check
the
order of the echo statements.

\start
Date: Thu, 16 Nov 2006 01:07:11 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: Re: Ping: case insensitive filesystems

Bill Page wrote:
> BTW, the output of the algebra/Makefile looks a little strange:
> 
> ...
> rm -rf /home/page/axiom.test/int/algebra/FTEM.NRLIB
> copying FTEM.NRLIB to FTEM.o
> compiling GENEEZ.spad to GENEEZ.NRLIB
> rm -rf /home/page/axiom.test/int/algebra/GENEEZ.NRLIB
> copying GENEEZ.NRLIB to GENEEZ.o
> compiling GENMFACT.spad to GENMFACT.NRLIB
> rm -rf /home/page/axiom.test/int/algebra/GENMFACT.NRLIB
> copying GENMFACT.NRLIB to GENMFACT.o
> ...
> 
> Notice how it appears as if the *.NRLIB directory is deleted before
> *.NRLIB/code.o is copied! :-) I am sure it is ok but we need to check
> the
> order of the echo statements.

Well the relevant code is:

.PRECIOUS: ${MID}/%.NRLIB/code.o
${MID}/%.NRLIB/code.o: ${MID}/%.spad
        @ echo compiling $*.spad to $*.NRLIB
        rm -rf ${MID}/$*.NRLIB
        @ (cd ${MID} ; \
           if [ -z "${NOISE}" ] ; then \
            echo ")co $*.spad" | ${INTERPSYS}  ; \
           else \
             echo ")co $*.spad" | ${INTERPSYS} >> ${TMP}/trace ; \
           fi )

Logically removing old file is the first step of compilation. But
because of '@' char make does not echo the compile command, so you
get the output as-is.

BTW: I would write the above as:

${MID}/%.NRLIB/code.o: ${MID}/%.spad
	rm -rf ${MID}/$*.NRLIB
	echo ")co $*.spad" | ${INTERPSYS}  ${COMPOUTPUT}

with COMPOUTPUT beeeing ">> ${TMP}/trace" if we want silent
compilation and "| cat" if we want all messages. Note that
once we remove '@' char the first echo command is useless, since
the second line contains requested information.

\start
Date: 16 Nov 2006 01:15:02 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Ping: case insensitive filesystems

Bill Page writes:


[...]

| Oops, I guess you asked that they be separate commits... Sorry. But
| the changes are simple and related so perhaps better treated as one
| anyway. 

No, that is fine.  Waldek explained why it is better they are
committed jointly.

\start
Date: Thu, 16 Nov 2006 01:22:26 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Eval in Axiom/Aldor

On 11/15/2006 01:55 PM, Page, Bill wrote:
> I tried writing:
> 
>   test(a:Fraction UnivariatePolynomial(x, F)):Fraction
> UnivariatePolynomial(x, F) ==
>     elt(a,1$Fraction(UnivariatePolynomial(x,
> F)))$UnivariatePolynomial(x, F)
> 
> but Aldor continues to insist that there is no such elt that
> returns Fraction UnivariatePolynomial(x, F). Perhaps it is a
> compiler bug?

I cannot say whether that is a bug or not. I just tend to say it is.
When I started with Axiom, I always wondered about the "elt". Now I 
interpret it as abbreviation of "element" whose meaning is similar to 
extracting the n-th element of an array. So why not replacing "elt" by 
the "." in the form given below?

#include "axiom.as"

P ==> UnivariatePolynomial(x,F);
Q ==> Fraction P;

TestEval(x: Symbol, F: Field): with {
	test1: Q -> Q;
	test2: Q -> Q;
} == add {
	import from P;
	test1(a: Q): Q == a.(1$Q);
	test2(a: Q): Q == elt(a, 1$Q);
}

If you remove test2. That code compiles

F ==> Fraction Integer
P ==> UP(x, F)
Q ==> Fraction P
p1: P := x + 3
p2: P := x+4
q: Q := p1/p2
)co eval.as
T ==> TestEval(x, F)
test1(q)$T

(8) ->
         4
    (8)  -
         5
            Type: Fraction UnivariatePolynomial(x,Fraction Integer)

The interesting part is when one simply writes ...

	test1(a: Q): Q == a.1;

The error message will be...

)set compiler args "-O -Fasy -Fao -Flsp -laxiom 
-Mno-Aldor_W_WillObsolete -DAxiom -Y $AXIOM/algebra -mno-abbrev"
)co eval.as

"eval.as", line 11:         test1(a: Q): Q == a.1;
                     ...........................^
[L11 C28] #1 (Error) There are 2 meanings for the operator `apply'.
         Meaning 1: (Fraction(UnivariatePolynomial(x, F) pretend 
IntegralDomain), Fraction(UnivariatePolynomial(x, F) pretend 
IntegralDomain)) -> Fraction(UnivariatePolynomial(x, F) pretend 
IntegralDomain)
         Meaning 2: (Fraction(UnivariatePolynomial(x, F)), 
UnivariatePolynomial(x, F) pretend SetCategory) -> 
Fraction(UnivariatePolynomial(x, F)) pretend Type

Ooops, "." is translated to "apply". Well, that is the usual translation 
in Aldor. But since HyperDoc finds only one apply with 2 arguments and 
there the first artument must be a Matrix, it seems that libaxiom.al 
does not reflect the SPAD source code in a 1-1 manner. It is still 
reasonable if we consider elt = apply, but I don't know where this 
translation happened. I could not find it in Broadbery's code that 
builds libaxiom.al. And so I am not even sure about whether elt=apply 
actually holds. I am certainly missing something.

That compiling test2 fails is certainly in connection with elt=apply. 
Who knows...

\start
Date: 16 Nov 2006 01:20:22 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: FW: data structure vs. mathematical structure

Ralf Hemmecke writes:

| > The definition you gave is it: least fixed point of
| >     X |-> 1 + T =D7 X =D7 X
|
| Hmmm, good question. In Aldor-combinat (AC) we deal with combinatorial
| species. They encode actual structures. The corresponding generating
| series G(x) for binary trees given by your X above has to fulfil the
| equation
|
| G(x) = 1 + x * G(x) * G(x)                                (+)
|
| As a quadratic formula it has at most 2 solutions. And only one of
| those solution is a power series with only non-negative
| coefficients. Since I don't know what it should mean to say "there are
| -5 trees with 3 nodes", it is clear which solution I choose for the
| generating series.
|
| Assuming that I understand a bit of the theory of species, then there
| is only *one* solution to
|
|       X = 1 + T * X * X.
|
| We are not yet dealing with "virtual species" which would allow
| negative coefficients in the generating series.

I realize my sentence could be ambiguous:  I meant "least fixed point
in the category of continuous partial orders (CPO)."  I'm not familiar
with the theory of species.  At any rate I did not intend "least" in
terms of numerical coefficient.

| > The interesting bit about those inductive definition is that they come
| > with "fold" (reduce in Axiom-speak) for free.
|
| Hmmm, lazyness is important here. Unfortunately the internal
| definition of formal power series in AC does not allow to write
| equation (+) as such. One first has to say (something like)
|
| g: FormalPowerSeries Integer := new();
| set!(g, 1+x*g*g);
|
| where x corresponds to the inteterminate of "FormalPowerSeries Integer".

Aha! Good point.  Now, I just need you to point me to a good
introductory point on species.

\start
Date: Thu, 16 Nov 2006 01:39:08 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: FW: data structure vs. mathematical structure

On 11/16/2006 01:20 AM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
>
> | > The definition you gave is it: least fixed point of
> | >     X |-> 1 + T =D7 X =D7 X
> |
> | Hmmm, good question. In Aldor-combinat (AC) we deal with combinatoria=
l
> | species. They encode actual structures. The corresponding generating
> | series G(x) for binary trees given by your X above has to fulfil the
> | equation
> |
> | G(x) = 1 + x * G(x) * G(x)                                (+)
> |
> | As a quadratic formula it has at most 2 solutions. And only one of
> | those solution is a power series with only non-negative
> | coefficients. Since I don't know what it should mean to say "there ar=
e
> | -5 trees with 3 nodes", it is clear which solution I choose for the
> | generating series.
> |
> | Assuming that I understand a bit of the theory of species, then there=

> | is only *one* solution to
> |
> |       X = 1 + T * X * X.
> |
> | We are not yet dealing with "virtual species" which would allow
> | negative coefficients in the generating series.
>
> I realize my sentence could be ambiguous:  I meant "least fixed point
> in the category of continuous partial orders (CPO)."

Well, it seems you have to be even more precise. I still cannot
understand that. You mean X, 1, T are continuous partial orders?
And what does then + and =D7 stand for?

> Aha! Good point.  Now, I just need you to point me to a good
> introductory point on species.

The short one you find at

http://en.wikipedia.org/wiki/Combinatorial_species

and the book I currently like best is given as the second reference on
the above page:

Fran=E7ois Bergeron, Gilbert Labelle, Pierre Leroux, Th=E9orie des esp=E8=
ces
et combinatoire des structures arborescentes, LaCIM, Montr=E9al (1994).
English version: Combinatorial Species and Tree-like Structures,
Cambridge University Press (1998).

\start
Date: 16 Nov 2006 02:07:44 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Eval in Axiom/Aldor

Ralf Hemmecke writes:


[...]

| that builds libaxiom.al. And so I am not even sure about whether
| elt=apply actually holds. I am certainly missing something.

I don't if it is of any help, see ax.boot:

     axOpTran(name) ==
        ATOM name =>
           name = 'elt => 'apply
           name = 'setelt => 'set!
           name = 'SEGMENT => ".."
           name = 1 => '_1
           name = 0 => '_0
           name
        opOf name = 'Zero => '_0
        opOf name = 'One => '_1
        error "bad op name"

\start
Date: 16 Nov 2006 02:41:44 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: FW: data structure vs. mathematical structure

Ralf Hemmecke writes:

| On 11/16/2006 01:20 AM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke writes:
| > | > The definition you gave is it: least fixed point of
| > | >     X |-> 1 + T =D7 X =D7 X
| > | | Hmmm, good question. In Aldor-combinat (AC) we deal with
| > combinatorial
| > | species. They encode actual structures. The corresponding generating
| > | series G(x) for binary trees given by your X above has to fulfil the
| > | equation
| > | | G(x) = 1 + x * G(x) * G(x)                                (+)
| > | | As a quadratic formula it has at most 2 solutions. And only one
| > of
| > | those solution is a power series with only non-negative
| > | coefficients. Since I don't know what it should mean to say "there are
| > | -5 trees with 3 nodes", it is clear which solution I choose for the
| > | generating series.
| > | | Assuming that I understand a bit of the theory of species, then
| > there
| > | is only *one* solution to
| > | |       X = 1 + T * X * X.
| > | | We are not yet dealing with "virtual species" which would allow
| > | negative coefficients in the generating series.
| > I realize my sentence could be ambiguous:  I meant "least fixed point
| > in the category of continuous partial orders (CPO)."
|
| Well, it seems you have to be even more precise. I still cannot
| understand that. You mean X, 1, T are continuous partial orders?
| And what does then + and =D7 stand for?

First consider CPO, the category of complete partial partial orders,
where the morphisms are continuous functions.  Here

  * 1 denotes "the" least object

  * + is the discriminated union

  * =D7 is the Cartesian product


Both "+" and "=D7" are (bi)functors of CPO.  More generally any
"polynomial" expression is a functor in CPO.  For example, if T is a
fixed object of CPO,

    X +-> 1 + T =D7 X, where X ranges over CPO

is a functor, so is

    X +-> a + T =D7 X =D7 X

There is a general theorem that says that any polynomial (endo)functor F of
CPO has a least fixed point.  Notice that, in reality, this fixed
point is understood as "F(X) is isomorphic to X", but one usually writes
F(X) = X.  The set of finite lists of element of type T can be thought
of as the least fixed point of

    X +-> 1 + T =D7 X

Similarly, the set of finite binary trees can be thought of as the
least fixed point of

    X +-> 1 + T =D7 X =D7 X

The categorial viewpoint explains very neatly the generalization of
the reduce operator (over lists) to more general inductive types.

| > Aha! Good point.  Now, I just need you to point me to a good
| > introductory point on species.
|
| The short one you find at
|
| http://en.wikipedia.org/wiki/Combinatorial_species


Thanks!  It looks like we are actually using the same terminology
(except that I was not doing any natural number interpretation).

| and the book I currently like best is given as the second reference on
| the above page:
|
| Fran=E7ois Bergeron, Gilbert Labelle, Pierre Leroux, Th=E9orie des esp=E8=
ces
| et combinatoire des structures arborescentes, LaCIM, Montr=E9al
| (1994). English version: Combinatorial Species and Tree-like
| Structures, Cambridge University Press (1998).

Thanks!

\start
Date: Wed, 15 Nov 2006 21:00:56 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: FW: data structure vs. mathematical structure

On Wednesday, November 15, 2006 7:39 PM Ralf Hemmecke wrote:
>
> On 11/16/2006 01:20 AM, Gabriel Dos Reis wrote:
> > | > The definition you gave is it: least fixed point of
> > | >     X |-> 1 + T =D7 X =D7 X
> > |
> > | Hmmm, good question. In Aldor-combinat (AC) we deal with
> > | combinatorial species. They encode actual structures. The
> > | corresponding generating series G(x) for binary trees given
> > | by your X above has to fulfil the equation
> > |
> > | G(x) = 1 + x * G(x) * G(x)                           (+)
> > ...
> > | Assuming that I understand a bit of the theory of species,
> > | then there is only *one* solution to
> > |
> > |       X = 1 + T * X * X.
> > |
> > | We are not yet dealing with "virtual species" which would
> > | allow negative coefficients in the generating series.
> >
> > I realize my sentence could be ambiguous:  I meant "least
> > fixed point in the category of continuous partial orders
> > (CPO)."
>
> Well, it seems you have to be even more precise. I still
> cannot understand that. You mean X, 1, T are continuous
> partial orders? And what does then + and =D7 stand for?
>

It is indeed a remarkable achievement of the level of abstraction
that these formulas are (nearly) identical but refer to seemingly
very different things!

>From a categorical perspective, the + and =D7 above stand for
abstract direct sum and direct product like the disjoint union
and cartesian product of intuitive set theory. Or you can read
the same equation like a production rule in a grammar (universal
algebra) and then + denotes an altenative construction and =D7
denotes a pair (or triple as in the case above). The X denotes
a "production". And the general abstract solution is represented
by a particular structure preserving operation called a functor
which in the example above can be thought of as mapping types
into more complex type structures - lists and binary trees -
this is also called a "functor" or type constructor in Axiom
and Aldor.

>From the point of view of combinatorics (counting structures)
these operations behave just like the usual arithmetic ones,
so we also have the interpretation to which you referred as
the solution of a numerical quadratic equation.

The reference to complete partial orders is a way to define an
ordering or "size" of the solutions of the equation so that it
makes sense to speak of the (unique) "least" or "greatest"
solution.

http://en.wikipedia.org/wiki/Complete_partial_order

(Depending on the application the adjective "continuous"
might also be applicable.)

There are other ways to achieve effectively the same thing
in category theory via universal constructions such as limits
and co-limits. The most important thing is to be able to
define abstractly the essential characteristics of the + and
=D7 operations.

>From my point of view, the best way to understand least fixed
points is to also try to understand greatest fixed points at
the same time. As I mentioned in a previous message the Stream
type in Axiom (and some other languages) is related to the
same defining equation as the List functor X = 1 + T * X
except that it is greatest fixed point solution rather than
the least fixed point. It is seems easy (trivial?) to understand
the action of the List type constructor but it is a little more
challenging to understand the Stream constructor. Playing with
Stream in Axiom makes this a little easier.

In particular Streams are possibly infinite types corresponding
to possibily repeating sequences of things of a given Type. For
example

    expand(1..)

is the sequence of PositiveIntegers. And

   repeating [1,2,3]

is a sequence of those three Integers repeated 1,2,3,1,2,3,...
indefinitely. In Axiom such infinite repeating sequences have
a convenient finite representation as a circular list (denoted
by a bar over the list of repeated elements).

Now having thought about Stream as a type constructor solution
of the equation X = 1 + T * X, I would like to ask you what you
think might be the equivalent greatest fixed point solution of

  X = 1 + T * X * X

Recall first that the least fixed point solution corresponds to
the BinaryTree type constructor.

I think I know the answer although I have not seen this written
anyware else, so I want to see if you come to the same conclusion.
:-) Ultimately it is the connection to Azcel and Jon Barwise's
notions of non-wellfounded sets that intrigues me most.

Please forgive me for going on about this ...

\start
Date: 16 Nov 2006 03:17:55 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: FW: data structure vs. mathematical structure

Bill Page writes:

[...excellent stuff snipped...]

| Now having thought about Stream as a type constructor solution
| of the equation X = 1 + T * X, I would like to ask you what you
| think might be the equivalent greatest fixed point solution of
| 
|   X = 1 + T * X * X
| 
| Recall first that the least fixed point solution corresponds to
| the BinaryTree type constructor.

Isn't a potentially infinite binary tree?
An effective traversal of that structure would be a breath first
traversal.  Does Axiom have a domain for that?

| I think I know the answer although I have not seen this written
| anyware else, so I want to see if you come to the same conclusion.
| :-) Ultimately it is the connection to Azcel and Jon Barwise's
| notions of non-wellfounded sets that intrigues me most. 

co-induction.

\start
Date: Thu, 16 Nov 2006 03:26:28 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: Re: Ping: case insensitive filesystems

Bill Page wrote:
> On Wednesday, November 15, 2006 12:47 PM Gaby wrote:
> > ...
> > Bill Page wrote: 
> > | Here is my proposed documentation patch to src/hyper/Makefile:
> > 
> > That is excellent!  Go!
> > 
> 
> Ok, done. I compiled Axiom with the two patches - one for file renames
> and one for file cleanup
> 

You forgot to remove the second copy of util.ht (so I did that).

\start
Date: Wed, 15 Nov 2006 21:39:46 -0500
From: Bill Page
To: Waldek Hebisch
Subject: RE: Ping: case insensitive filesystems

Waldek,

On Wednesday, November 15, 2006 9:26 PM you wrote:
> ...
> You forgot to remove the second copy of util.ht (so I did that).
>

Thanks. It's been a long day but your night must be even longer...
:-)

\start
Date: 15 Nov 2006 21:35:58 -0600
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] Pretty-print when boottocl and boottoclc

  This patchlet makes the functions boottocl and boottoclc translators
pretty print their results -- instead of producing long lines of 
unreadable sequences of parenthesis and vertical bars.

I just bootsys from stage 2 to check the results and alter
the cached version.

Built and tested on an i686-pc-linux-gnu.

-- Gaby

2006-11-15  Gabriel Dos Reis  Gabriel Dos Reis

	* ptyout.boot.pamphlet (shoeFileTrees): Use REALLYPRETTYPRINT
	instead of shoePPtoFile.

*** ptyout.boot.pamphlet	(revision 16886)
--- ptyout.boot.pamphlet	(local)
*************** shoeFileTrees(s,st)==
*** 310,316 ****
              a:=CAR s
              if EQCAR (a,"+LINE")
              then shoeFileLine(CADR a,st)
!             else shoePPtoFile(a,st)
              s:=CDR s
   
   
--- 310,316 ----
              a:=CAR s
              if EQCAR (a,"+LINE")
              then shoeFileLine(CADR a,st)
!             else REALLYPRETTYPRINT(a,st)
              s:=CDR s
   
   
*************** PSTOUT string==
*** 1192,1198 ****
                  (SETQ |a| (CAR |s|))
                  (COND
                    ((EQCAR |a| '+LINE) (|shoeFileLine| (CADR |a|) |st|))
!                   ('T (|shoePPtoFile| |a| |st|)))
                  (SETQ |s| (CDR |s|)))))))))))
  
  (DEFUN |shoePPtoFile| (|x| |stream|)
--- 1192,1198 ----
                  (SETQ |a| (CAR |s|))
                  (COND
                    ((EQCAR |a| '+LINE) (|shoeFileLine| (CADR |a|) |st|))
!                   ('T (REALLYPRETTYPRINT |a| |st|)))
                  (SETQ |s| (CDR |s|)))))))))))
  
  (DEFUN |shoePPtoFile| (|x| |stream|)

\start
Date: 15 Nov 2006 22:02:23 -0600
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] boottocl

With this patchlet we return whather shoeNotFound returns when the
input file is invalid.  This behaviour now matches that of other
translation functions.

-- Gaby

2006-11-15  Gabriel Dos Reis  Gabriel Dos Reis

	* ptyout.boot.pamphlet (shoeClLines): Return the result of 
	shoeNotFound is input file is not existent.

*** ptyout.boot.pamphlet	(revision 16887)
--- ptyout.boot.pamphlet	(local)
*************** BOOTCLAMLINES(lines, fn) ==
*** 96,104 ****
  <<BOOTTOCLLINES>>
  shoeClLines(a,fn,lines,outfn)==
        if null a
!       then
!            shoeNotFound fn
!            nil
        else
         $GenVarCounter:local := 0
         shoeOpenOutputFile(stream,outfn,
--- 96,102 ----
  <<BOOTTOCLLINES>>
  shoeClLines(a,fn,lines,outfn)==
        if null a
!       then shoeNotFound fn
        else
         $GenVarCounter:local := 0
         shoeOpenOutputFile(stream,outfn,
*************** PSTOUT string==
*** 860,866 ****
      (DECLARE (SPECIAL |$GenVarCounter|))
      (RETURN
        (COND
!         ((NULL |a|) (|shoeNotFound| |fn|) NIL)
          ('T (SETQ |$GenVarCounter| 0)
           (|shoeOpenOutputFile| |stream| |outfn|
               (PROGN
--- 858,864 ----
      (DECLARE (SPECIAL |$GenVarCounter|))
      (RETURN
        (COND
!         ((NULL |a|) (|shoeNotFound| |fn|))
          ('T (SETQ |$GenVarCounter| 0)
           (|shoeOpenOutputFile| |stream| |outfn|
               (PROGN


\start
Date: Thu, 16 Nov 2006 00:41:21 -0500
From: Cliff Yapp
To: Waldek Hebisch
Subject: re: Ping: case insensitive filesystems

Waldek Hebisch wrote:

> I think we have conflicting paradigms here.  I belive that history
> has place in documentation only if it explains _significant_ aspect
> of current system.  In case of current filename change past status
> really tells you nothing about new system.

(insert 'mouth 'foot)

At the risk of getting into trouble, I must agree with Waldek that there
needs to be a distinction between documentation of the system which
describes its workings, and documentation which describes its evolution.
(If that is a fair characterization.)

Changelogs are, AFAICS, what we make them.  If we are planning to remove
or restructure something and want to explain why we are shifting from
the old to the new, that seems to me like a Changelog type of entry.  If
normal changelogs are too brief for what we are after and don't
highlight exact changes, why not create a changelog format that does
what we want?

I have always thought that if we are making Axiom into literate
documents, they should read as such - if I am looking for the pamphlet
that describes the SPAD compiler I am interested in what it IS doing and
what it is intended to do and why, not what it did in the past before it
was fixed.  If I run into a bug I might want to check what changes were
made and why, but that is the precise purpose of a changelog - to
preserve the description of system evolution.  If we want more extensive
changelogs than are standard today, let's define what would work for us.
 However, I must agree that I wouldn't want such things cluttering up
the pamphlet.  If the job that (say, for example) PDP11 specific code
did has no modern equivalent and is no longer needed, removal and a
changelog entry should suffice.  We don't need to document why that code
was there and how it worked if it handles a problem that no longer exists.

That's why I took the approach I did with the Units paper - study the
problem domain, determine what should happen, and then make the code fit
the ideas.  When I tried a Maxima units package I did it the other way
around, and while the code does do some things I rather doubt it would
scale correctly or handle some of the more subtle questions/issues.
Admittedly there isn't working code for Axiom yet, but the eventual
result of the Unit paper approach will be much more useful.

To take another example, I would like to see us first write the
paper/book on WHAT the SPAD language definition is, WHY we want it that
way, and HOW we want it to work (compilation algorithms, compiler design
considerations, etc.).  In the process, we will probably learn how it
SHOULD be done, rather than how it is done now.  The existing code will
be very useful as a reference and some pieces might be drop in, but I
would like to see the ideas lead the code instead of the code leading
the ideas.

In such a paradigm, what the old code was doing is less important than
the question of do we have code that does the right thing?  The pamphlet
literature then is driven not by the existing code but by what the code
SHOULD be, and in that sense adding notes for the reasons for removal of
old code are beside the point of the document.  Such removals should
indeed be explained, but in the changelogs and not the document itself.
 If the changelog should reference specific files/line numbers as part
of its format that makes sense to me - perhaps there is a way to
automate that as part of the SCMs.

Anyway, my 2c.

\start
Date: Thu, 16 Nov 2006 10:05:53 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Eval in Axiom/Aldor

Aha! Thanks. So whenever I write a spad function "elt" internally it is 
translated to "apply" and thus the interpreter never sees "elt".

Is that interpretation of the snippet correct? Or what is that actually 
translating?

Oh, I must be wrong, since it reads src/interp/ax.boot.pamphlet, ie, it 
belongs to the interpreter.
But what is strange then is that the *Aldor compiler* complains about 
not finding "elt". So this translation must have been done for 
libaxiom.al, since that is the only thing that the aldor compiler sees. 
Sounds like that translation is *not* an interpreter thing. --- No no, 
don't explain. That will pop up again when its time has come.

Ralf

On 11/16/2006 02:07 AM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> 
> [...]
> 
> | that builds libaxiom.al. And so I am not even sure about whether
> | elt=apply actually holds. I am certainly missing something.
> 
> I don't if it is of any help, see ax.boot:
> 
>      axOpTran(name) ==
>         ATOM name =>
>            name = 'elt => 'apply
>            name = 'setelt => 'set!
>            name = 'SEGMENT => ".."
>            name = 1 => '_1
>            name = 0 => '_0
>            name
>         opOf name = 'Zero => '_0
>         opOf name = 'One => '_1
>         error "bad op name"

\start
Date: 16 Nov 2006 14:20:31 +0100
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: Ping: case insensitive filesystems

Cliff Yapp writes:


[...]

| I have always thought that if we are making Axiom into literate
| documents, they should read as such - if I am looking for the pamphlet
| that describes the SPAD compiler I am interested in what it IS doing and
| what it is intended to do and why, not what it did in the past before it
| was fixed.

This type of stance is appropriate for trunk.  My experience with
workind on branches tells me that it creates troubles when it comes to
merge do merges.  But, hey the system is already largely
non-documented, so why not continue that way?  

[...]

| To take another example, I would like to see us first write the
| paper/book on WHAT the SPAD language definition is, WHY we want it that
| way, and HOW we want it to work (compilation algorithms, compiler design
| considerations, etc.). 

Yes, we just need volunteers to tackle the problem.

| In the process, we will probably learn how it
| SHOULD be done, rather than how it is done now.  The existing code will
| be very useful as a reference and some pieces might be drop in, but I
| would like to see the ideas lead the code instead of the code leading
| the ideas.

since you feel you must say that, could you explain in how you see the
codes leading the ideas in the current practice?

| In such a paradigm, what the old code was doing is less important than
| the question of do we have code that does the right thing? 

Explainingg why the new code is right implies one needs to understand
what the old code is doing and why it is wrong.  In that respect, it
is just as important as the why of new code.

\start
Date: 16 Nov 2006 14:23:15 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Eval in Axiom/Aldor

Ralf Hemmecke writes:

| Aha! Thanks. So whenever I write a spad function "elt" internally it
| is translated to "apply" and thus the interpreter never sees "elt".

What I showed is the code for the SPAD to Axiom interface.

The SPAD interpreter likes "elt" and works with it.

| Is that interpretation of the snippet correct? Or what is that
| actually translating?
| 
| Oh, I must be wrong, since it reads src/interp/ax.boot.pamphlet, ie,
| it belongs to the interpreter.
| But what is strange then is that the *Aldor compiler* complains about
| not finding "elt". So this translation must have been done for
| libaxiom.al, since that is the only thing that the aldor compiler
| sees. Sounds like that translation is *not* an interpreter thing. ---

indeed, it is not for the interpreter.  See the comment in
interp/Makefile around it.

| No no, don't explain. That will pop up again when its time has come.

Too late :-)

\start
Date: Thu, 16 Nov 2006 16:54:12 +0100
From: Gregory Vanuxem
To: Ludovic Courtes
Subject: Re: [Axiom-mail] Re: `)read' and large inputs

Le jeudi 16 novembre 2006 =E0 13:49 +0100, Ludovic Court=E8s a =E9crit :
> Hi,
>
> Themos Tsikas Themos Tsikas writes:
>
> > The Library domain is for putting AXIOM values from different domains=
 into one
> > Keyed-Acess-File. It's a useful way for transmitting values from one =
AXIOM
> > session to another. Your first session should have created a director=
y called
> > data.KAF containing a file called index.KAF and in this file would be=
 a
> > Lisp-readable representation of the values you put in it. Do you get =
these
> > files at the end of the first session?
> > The second session must be started at the same working directory as t=
he first.
> > Is there a directory called data.KAF when you start the second sessio=
n?
>
> Yes, but it only contains a 23-octet long `index.KAF' containing the
> following line:
>
>   20                  NIL
>
> The issue is that the first session (where `axiom-large.input' is passe=
d
> on axiom's standard input) _does_ create the `data.KAF' directory and
> the `index.KAF' above but it outputs the following error message:
>
>    >> Error detected within library code:
>    File is not readable
>    "data.KAF"
>
> This message does not correspond to any actual read/open error from wha=
t
> I can see from the output of `strace'.

This is a bug. The problem is that you are trying to work with KAF files
which involve directories as explained by Themos Tsikas. So all function
such as writable? readable? are applied on this directory and not on the
index.KAF file. The behavior of GCL in this regard has changed (since
2.6.7 I think) : it's not possible, actually, to (open ...) a directory
(readable?, internally, uses this) nor to use (probe-file ...) on it.

I'm CC'ing this mail since Waldek Hebisch (will) work on issues related
to this problem and I don't know if it is aware of this problem.

I _think_ that even if you try to modify the Spad file to avoid the
readability/writability tests your library file (KAF) will be unreadable
because of another problem to open (for reading) these types of file.
This bug was fixed by Waldek but actually this fix is only available in
the svn wh-sandbox branch which is highly experimental.

Sorry,

Greg

PS: I think too (I can not test, my version of Axiom has the same bug)
that some objects can not be saved and retrieved, for example
continuedFraction(0). Themos, am I correct?

\start
Date: Thu, 16 Nov 2006 12:22:01 -0400
From: Humberto Zuazaga
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

Gabriel Dos Reis wrote:

>   How about this patch I'm testing?  I splitted the GCLOPTS into
> independent parts, and disabled X and TK for all targets.

It wasn't working. I think I've finally tracked it down.

On Mac OS X, the gcl configure option:

--enable-maxpage=256*1024

causes gcl to segfault immediately upon starting.

I'm building axiom now on my Mac, I'm pretty sure it's using the 
contained gcl (the one in build/), and it seems to be working.

What's the default size for this parameter? I'm going to try 128*1024 to 
see if it works, but it's likely pointing to some kind of memory 
management bug, isn't it.

The current build is working with the following configure flags:

# ./configure 
--prefix=/Users/humberto/src/axiom/test/build/powerpc-apple-darwin8.8.0 
--disable-xgcl --enable-locbfd --disable-statsysbfd 
--enable-machine=powerpc-macosx '--enable-vssize=65536*2' 
--disable-tkconfig --disable-x

\start
Date: Thu, 16 Nov 2006 10:39:41 -0600 (CST)
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire

On Thu, 16 Nov 2006, Humberto Ortiz Zuazaga wrote:

| Gabriel Dos Reis wrote:
|
| >   How about this patch I'm testing?  I splitted the GCLOPTS into
| > independent parts, and disabled X and TK for all targets.
|
| It wasn't working. I think I've finally tracked it down.
|
| On Mac OS X, the gcl configure option:
|
| --enable-maxpage=256*1024
|
| causes gcl to segfault immediately upon starting.

Arg.  I don't know what the proper value must be.  The above is what
is on trunk but since nobody reported it worked I believe we must
follow what you advise here.

Bill had a different value for that parameter (which is not a power of
2).  Personaly, I don't think users must get into  the business of
fiddling with that parameter.  Ideally, GCL should just figure out
what is the right thing to do.

| I'm building axiom now on my Mac, I'm pretty sure it's using the
| contained gcl (the one in build/), and it seems to be working.

OK.

| What's the default size for this parameter? I'm going to try 128*1024 to
| see if it works, but it's likely pointing to some kind of memory
| management bug, isn't it.
|
| The current build is working with the following configure flags:
|
| # ./configure
| --prefix=/Users/humberto/src/axiom/test/build/powerpc-apple-darwin8.8.0
| --disable-xgcl --enable-locbfd --disable-statsysbfd
| --enable-machine=powerpc-macosx '--enable-vssize=65536*2'
| --disable-tkconfig --disable-x

OK, maybe we should just leave out --enable-maxpage.  Camm?

\start
Date: 16 Nov 2006 13:31:59 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Aurelien Chanudet

Greetings!

Gabriel Dos Reis writes:

> On Thu, 16 Nov 2006, Humberto Ortiz Zuazaga wrote:
> 
> | Gabriel Dos Reis wrote:
> |
> | >   How about this patch I'm testing?  I splitted the GCLOPTS into
> | > independent parts, and disabled X and TK for all targets.
> |
> | It wasn't working. I think I've finally tracked it down.
> |
> | On Mac OS X, the gcl configure option:
> |
> | --enable-maxpage=256*1024
> |
> | causes gcl to segfault immediately upon starting.
> 
> Arg.  I don't know what the proper value must be.  The above is what
> is on trunk but since nobody reported it worked I believe we must
> follow what you advise here.
> 
> Bill had a different value for that parameter (which is not a power of
> 2).  Personaly, I don't think users must get into  the business of
> fiddling with that parameter.  Ideally, GCL should just figure out
> what is the right thing to do.
> 
> | I'm building axiom now on my Mac, I'm pretty sure it's using the
> | contained gcl (the one in build/), and it seems to be working.
> 
> OK.
> 
> | What's the default size for this parameter? I'm going to try 128*1024 to
> | see if it works, but it's likely pointing to some kind of memory
> | management bug, isn't it.
> |
> | The current build is working with the following configure flags:
> |
> | # ./configure
> | --prefix=/Users/humberto/src/axiom/test/build/powerpc-apple-darwin8.8.0
> | --disable-xgcl --enable-locbfd --disable-statsysbfd
> | --enable-machine=powerpc-macosx '--enable-vssize=65536*2'
> | --disable-tkconfig --disable-x
> 
> OK, maybe we should just leave out --enable-maxpage.  Camm?
> 

The short story is I'd recommend leaving out the maxpage at least on
macosx.  In fact, we might make it a configure error at the moment.

The long story is that GCL supports two platforms without OS sbrk, and
therefore emulates same -- Windows and Macosx.  GCL would use some
volunteers to help making this emulation flow more nicely with the
basic settings governing the traditional unix memory model,
e.g. maxpage in the current context.  (I've posted a pictorial
representation of GCL's memory layout -- if anyone is interested I'll
dig up the URL).

On the mac, we have in unexmacosx.c:

/* This used to be the size of the heap, but this is no longer used.  */
#define BIG_HEAP_SIZE 0x50000000

...

/* Size of the heap.  */
int big_heap = BIG_HEAP_SIZE;

...

void *my_sbrk (int incr)
{
  char               *temp, *ptr;
  kern_return_t       rtn;
  
  if (mach_brkpt == 0) {
    if ((rtn = vm_allocate (mach_task_self (), (vm_address_t *) &mach_brkpt,
                            big_heap, 1)) != KERN_SUCCESS) {
      malloc_printf ("sbrk_macosx(): vm_allocate() failed\n");
      abort ();
      return ((char *)-1);
    }
    if (!mach_brkpt) {
      /* Call this instead of fprintf() because no allocation is performed.  */
      malloc_printf ("sbrk_macosx(): cannot allocate heap\n");
      return ((char *)-1);        
    }
    mark_region ((unsigned long) mach_brkpt, (unsigned long) big_heap);
        
    mach_mapstart = mach_brkpt;
    mach_maplimit = mach_brkpt + big_heap;
  }
 ...

In the first raw image produced by gcc, the first thing the mac does
is allocate this huge block, do an image save, and then an exec to the
new image.  The emulated sbrk then steps contiguously through this
preset block until the end.  A real sbrk will continue to append pages
contiguously until the OS is oom, but this is OK (at the moment)
because GCL has maxpages as a compile time limit anyway (this will be
relaxed at some point).  Perhaps all that needs doing is making sure
big_heap and maxpage are synchronized, but I don't fully understand
the memory layout on the mac and whether there are other obstacles
that need checking for, and/or what the signs of collision might be.  

This is probably also why saved images seem larger on the mac than
necessary. 

So in sum an effective limit on --enable-maxpage on the mac at the
moment is something like 0x50000000 / PAGESIZE, which is not checked
by configure.

Other macosx issues that need some loving care by mac afficionados:

1) SGC is not working.  Aurelien ran into difficulties in the past
   getting gdb to trap segfaults properly, without which debugging
   this is almost impossible.
2) i386 support.  I posted earlier that an initial attempt shows a
   failure on launching the first saved image described above, with a
   "Cannot allocate memory" error from the OS (on an 8gb machine)
   before malloc or main are reached.  Something about the layout
   requirements for the new .data section in the saved image must have
   changed.  

I'd like not to spend too much personal time on Windows and Mac, as my
main concern here is the advanecment of free software.  That said I
will make it easy for anyone else so inclined to step in.

\start
Date: Thu, 16 Nov 2006 21:16:12 +0100
From: Gregory Vanuxem
To: Themos Tsikas
Subject: Re: [Axiom-mail] Re: `)read' and large inputs

Le jeudi 16 novembre 2006 =E0 16:18 +0000, Themos Tsikas a =E9crit :
> On Thursday 16 November 2006 15:54, Vanuxem Gr=E9gory wrote:
> >
> > PS: I think too (I can not test, my version of Axiom has the same bug=
)
> > that some objects can not be saved and retrieved, for example
> > continuedFraction(0). Themos, am I correct?
> >
>
> trying to put that value in the library goes through without error, I g=
et a
> line in index.KAF like this
>
> ((|ContinuedFraction| (|Integer|)) (0 "NullStream") . T)
>
> but retrieving the value, I get
>
>
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
>
>    >> System error:
>    Caught fatal error [memory may be damaged]
>
> protected-symbol-warn called with (NIL)

Thanks!!
I encountered the same issue with the history of Axiom in a file which
is buggy (see
http://wiki.axiom-developer.org/323HandlingOfTheHistoryInAFile)

I reported the Library file problem too on IssueTracker.

\start
Date: Thu, 16 Nov 2006 21:47:30 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: Link and spam on MathAction

Hello Bill,

Just wanted to say that I'm very happy with MathAction. There are no
spam actually and it's possible to add link on MathAction without any
problems. Thanks!!!

\start
Date: Thu, 16 Nov 2006 22:38:21 +0100
From: Gregory Vanuxem
To: list
Subject: map instead of map! in src/doc/book.pamphlet

Hello,

A small typo in the Axiom book:

--- /home/greg/TDevel/cvs/axiom/src/doc/book.pamphlet
+++ src/doc/book.pamphlet
@@ -48550,7 +48548,7 @@
 \returnType{Type: TwoDimensionalArray Integer}
 
 To change the array destructively, use
-\spadfunFrom{map}{TwoDimensionalArray} instead of
+\spadfunFrom{map!}{TwoDimensionalArray} instead of
 \spadfunFrom{map}{TwoDimensionalArray}.  If you need to make a copy of
 any array, use \spadfunFrom{copy}{TwoDimensionalArray}.


Beware I don't know what \spadfunFrom does.

\start
Date: Thu, 16 Nov 2006 23:04:30 +0100
From: Ralf Hemmecke
To: Gregory Vanuxem
Subject: Re: map instead of map! in src/doc/book.pamphlet

On 11/16/2006 10:38 PM, Vanuxem Gr=E9gory wrote:
> Hello,
>
> A small typo in the Axiom book:
>
> --- /home/greg/TDevel/cvs/axiom/src/doc/book.pamphlet
> +++ src/doc/book.pamphlet
> @@ -48550,7 +48548,7 @@
>  \returnType{Type: TwoDimensionalArray Integer}
> 
>  To change the array destructively, use
> -\spadfunFrom{map}{TwoDimensionalArray} instead of
> +\spadfunFrom{map!}{TwoDimensionalArray} instead of
>  \spadfunFrom{map}{TwoDimensionalArray}.  If you need to make a copy of=

>  any array, use \spadfunFrom{copy}{TwoDimensionalArray}.
>
>
> Beware I don't know what \spadfunFrom does.

I don't know either, but src/hyper/pages/util.ht says the stuff below...

Obviously, there are a lot of commands that look pretty much like LaTeX. =

But I guess, hypertex code is not really processed by THE TeX so what
language is that actually? And any chance that there is a bit more
documentation than that given in util.ht?

Ralf

=2E.. from util.ht

% Function names:
%
% The X versions below are used because AXIOM function names that end
% in ``!'' cause problems for makeindex for had-copy.
%
% Example: \spadfunFromX{reverse}{List} prints as   reverse!
%
% In the "From" versions, the first arg is function name, second is
constructor
% where exported.
%
% Use the "op" flavors of "-", "+", "*" etc, otherwise the "fun" flavors

\newcommand{\userfun} [1]{{\bf #1}}              % example, non-library
function names

\newcommand{\fakeAxiomFun}[1]{{\bf #1}}          % not really a library
function
\newcommand{\pspadfun} [1]{\fakeAxiomFun{#1}}

\newcommand{\axiomFun} [1]{\lispdownlink{#1}{(|oPage| '|#1|)}}
\newcommand{\spadfun} [1]{\axiomFun{#1}}
\newcommand{\axiomFunX}[1]{\axiomFun{#1!}}
\newcommand{\spadfunX}[1]{\axiomFun{#1!}}

\start
Date: Thu, 16 Nov 2006 23:13:08 +0100
From: Ralf Hemmecke
To: list
Subject: ht.awk

Does somebody know where the file ht.awk is?

All the .ht files say...

% !! DO NOT MODIFY THIS FILE BY HAND !! Created by ht.awk.

So if there is/were a script that generates the .ht files, why keep them 
under source code control?

And, Waldek, didn't you say that also the .pht files are generated?

\start
Date: Thu, 16 Nov 2006 23:47:16 +0100
From: Gregory Vanuxem
To: Ralf Hemmecke
Subject: Re: map instead of map! in src/doc/book.pamphlet

Le jeudi 16 novembre 2006 =E0 23:04 +0100, Ralf Hemmecke a =E9crit :
> On 11/16/2006 10:38 PM, Vanuxem Gr=E9gory wrote:
> > Hello,
> >
> > A small typo in the Axiom book:
> >
> > --- /home/greg/TDevel/cvs/axiom/src/doc/book.pamphlet
> > +++ src/doc/book.pamphlet
> > @@ -48550,7 +48548,7 @@
> >  \returnType{Type: TwoDimensionalArray Integer}
> > 
> >  To change the array destructively, use
> > -\spadfunFrom{map}{TwoDimensionalArray} instead of
> > +\spadfunFrom{map!}{TwoDimensionalArray} instead of
> >  \spadfunFrom{map}{TwoDimensionalArray}.  If you need to make a copy =
of
> >  any array, use \spadfunFrom{copy}{TwoDimensionalArray}.
> >
> >
> > Beware I don't know what \spadfunFrom does.
>
> I don't know either, but src/hyper/pages/util.ht says the stuff below..=
.
>
> Obviously, there are a lot of commands that look pretty much like LaTeX=
.
> But I guess, hypertex code is not really processed by THE TeX so what
> language is that actually? And any chance that there is a bit more
> documentation than that given in util.ht?

It seems that you didn't see that book.pamphlet is a LaTeX book (THE
Axiom book :-) (\spadfunFrom is a LaTeX macro here). I use \spadfunFrom
for Hyperdoc and I like it though it processes incorrectly function
ending with a number (no link are generated).

\start
Date: Fri, 17 Nov 2006 00:04:07 +0100
From: Gregory Vanuxem
To: Ralf Hemmecke
Subject: Re: ht.awk

Le jeudi 16 novembre 2006 =E0 23:13 +0100, Ralf Hemmecke a =E9crit :
> Does somebody know where the file ht.awk is?
>
> All the .ht files say...
>
> % !! DO NOT MODIFY THIS FILE BY HAND !! Created by ht.awk.
>
> So if there is/were a script that generates the .ht files, why keep the=
m
> under source code control?

I asked the same question some days ago (forget the typos)
http://lists.gnu.org/archive/html/axiom-developer/2006-11/msg00436.html
No other response so I'm assuming it is no longer available.

Greg

> And, Waldek, didn't you say that also the .pht files are generated?

\start
Date: Thu, 16 Nov 2006 18:37:20 -0600 (CST)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Aurelien Chanudet

On Thu, 16 Nov 2006, Camm Maguire wrote:

| > | What's the default size for this parameter? I'm going to try 128*1024 to
| > | see if it works, but it's likely pointing to some kind of memory
| > | management bug, isn't it.
| > |
| > | The current build is working with the following configure flags:
| > |
| > | # ./configure
| > | --prefix=/Users/humberto/src/axiom/test/build/powerpc-apple-darwin8.8.0
| > | --disable-xgcl --enable-locbfd --disable-statsysbfd
| > | --enable-machine=powerpc-macosx '--enable-vssize=65536*2'
| > | --disable-tkconfig --disable-x
| >
| > OK, maybe we should just leave out --enable-maxpage.  Camm?
| >
|
| The short story is I'd recommend leaving out the maxpage at least on
| macosx.  In fact, we might make it a configure error at the moment.

Hello Camm,

  Thanks for the extensive explanation -- I liked it.  I'll implement
you suggestion.

\start
Date: Thu, 16 Nov 2006 20:45:50 -0500
From: Bill Page
To: Gregory Vanuxem, Ralf Hemmecke
Subject: RE: ht.awk

On November 16, 2006 6:04 PM Vanuxem Gregory wrote:
>
> Le jeudi 16 novembre 2006 =E0 23:13 +0100, Ralf Hemmecke a =E9crit :
> > Does somebody know where the file ht.awk is?
> >
> > All the .ht files say...
> >
> > % !! DO NOT MODIFY THIS FILE BY HAND !! Created by ht.awk.
> >
> > So if there is/were a script that generates the .ht files,
> > why keep them under source code control?
>
> I asked the same question some days ago (forget the typos)
> =
http://lists.gnu.org/archive/html/axiom-developer/2006-11/msg00436.html
> No other response so I'm assuming it is no longer available.

???

You asked about a file called 'ph.awk'. I do not know this file, but ...

On Mon, 13 Nov 2006 21:40:41 -0500 I replied to you:

http://lists.gnu.org/archive/html/axiom-developer/2006-11/msg00456.html

> There are awk scripts like 'ht.awk' that sound similar to this
> in the htex directory that is part of the original Axiom source
> distribution (not currently in the Open Source version but could
> be if we want them, I think). Where can I find a reference to
> ph.awk?

I have a copy of this from the original source distribution from
NAG. For some reason Tim Daly never included it in the open source
version. It appears to contain all the mechanism required to produce
both the Axiom Book and the hyperdoc .ht files from another source
form called .htex files. There are scripts here that extract Axiom
commands and run them to produce output that is inserted in the
.htex files to create .tex files.

Tim, is there any legal reason why you did not include the htex
directory in the open source version of Axiom?

> And, Waldek, didn't you say that also the .pht files are generated?
>

Perhaps there is something here also to produce .pht files but
I did not find it right away. Also included in the htex directory
is the original tex linebreak program that is used on MathAction
and in the TeXmacs tm_axiom interface on Windows.

\start
Date: Fri, 17 Nov 2006 03:31:23 +0100 (CET)
From: Waldek Hebisch
To: Ralf Hemmecke
Subject: Re: ht.awk

> Does somebody know where the file ht.awk is?
> 
> All the .ht files say...
> 
> % !! DO NOT MODIFY THIS FILE BY HAND !! Created by ht.awk.
> 
> So if there is/were a script that generates the .ht files, why keep them 
> under source code control?

I think we can forget about 'ht.awk': the whole process could not
be very complicated, so it should be easy to create a new script.
But the bigger problem is which workflow _we_ want to have?  IMO
we should stick to a small controlled subset of latex as a main
format and generate rest from it (the point is that once we allow
more Latex features we will spent more time developing tools then
writing documentation).

There is a second problem: .ht files in general contain more precise
markup then 'book.pamphlet', but some differences may be due to
editing done by Tim.  ATM the main difference I see is that
book contains Tex formulas, but hypertex pages use textual output
from Axiom.

> 
> And, Waldek, didn't you say that also the .pht files are generated?
> 

I put the following in 'src/hyper/Makefile.pamphlet':

In the long term, the [[.pht]] and viewports should be generated at either
build time or installation time using commands like:
\begin{verbatim}
             rm -f ht.db
             ${HTADD} *.ht
             for A in `ls *.ht`; do ${SMAN} -paste $$a ; done
             rm -f ht.db
             ${HTADD} *.ht *.pht
\end{verbatim}

Hypertex has special code to extract parts of .ht file and prepare
.input file for Axiom.  Once .input is ready Hypertex tells
AXIOMsys to execute it, writing output to a file.  Then Hypertex
should collect the output into .pht page.

This 'almost' works: some pages are nicely generated, but on other
it stops and one has manually quit Axiom.  It seems that Hypertex
has problem detecting that AXIOMsys finished writing output file.  

\start
Date: Fri, 17 Nov 2006 04:40:44 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: ht.awk

Le jeudi 16 novembre 2006 =E0 20:45 -0500, Bill Page a =E9crit :
> On November 16, 2006 6:04 PM Vanuxem Gregory wrote:
> >
> > Le jeudi 16 novembre 2006 =E0 23:13 +0100, Ralf Hemmecke a =E9crit :
> > > Does somebody know where the file ht.awk is?
> > >
> > > All the .ht files say...
> > >
> > > % !! DO NOT MODIFY THIS FILE BY HAND !! Created by ht.awk.
> > >
> > > So if there is/were a script that generates the .ht files,
> > > why keep them under source code control?
> >
> > I asked the same question some days ago (forget the typos)
> > http://lists.gnu.org/archive/html/axiom-developer/2006-11/msg00436.ht=
ml
> > No other response so I'm assuming it is no longer available.
>
> ???

Yes, this why I say "forget the typos". I think Waldek understood.

>
> You asked about a file called 'ph.awk'. I do not know this file, but ..=
.
>
> On Mon, 13 Nov 2006 21:40:41 -0500 I replied to you:
>
> http://lists.gnu.org/archive/html/axiom-developer/2006-11/msg00456.html
>
> > There are awk scripts like 'ht.awk' that sound similar to this
> > in the htex directory that is part of the original Axiom source
> > distribution (not currently in the Open Source version but could
> > be if we want them, I think). Where can I find a reference to
> > ph.awk?

All my apologies. I probably forgot because of its possible "no free"
nature. No excuse...

> I have a copy of this from the original source distribution from
> NAG. For some reason Tim Daly never included it in the open source
> version. It appears to contain all the mechanism required to produce
> both the Axiom Book and the hyperdoc .ht files from another source
> form called .htex files. There are scripts here that extract Axiom
> commands and run them to produce output that is inserted in the
> .htex files to create .tex files.

Ok, this is why in util.ht there are some reference to LaTeX as Ralf
pointed out.

Sorry again :-(

\start
Date: Fri, 17 Nov 2006 04:57:34 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: ht.awk

Le jeudi 16 novembre 2006 =E0 20:45 -0500, Bill Page a =E9crit :

[...]

>
> > There are awk scripts like 'ht.awk' that sound similar to this
> > in the htex directory that is part of the original Axiom source
> > distribution (not currently in the Open Source version but could
> > be if we want them, I think). Where can I find a reference to
> > ph.awk?

This mail was not destined to me and I thought it was a script known to
Waldek (not me, I even did not know my error).

\start
Date: Thu, 16 Nov 2006 23:09:26 -0500
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: re: Ping: case insensitive filesystems

Gabriel Dos Reis wrote:
> Cliff Yapp writes:
> 
> 
> [...]
> 
> | I have always thought that if we are making Axiom into literate
> | documents, they should read as such - if I am looking for the pamphlet
> | that describes the SPAD compiler I am interested in what it IS doing and
> | what it is intended to do and why, not what it did in the past before it
> | was fixed.
> 
> This type of stance is appropriate for trunk.  My experience with
> workind on branches tells me that it creates troubles when it comes to
> merge do merges.  But, hey the system is already largely
> non-documented, so why not continue that way?  

Experience trumps ideas ;-), and I must concede with so many SCMs being
used for Axiom a coherent changlog setup is probably close to impossible
in any case.

> | To take another example, I would like to see us first write the
> | paper/book on WHAT the SPAD language definition is, WHY we want it that
> | way, and HOW we want it to work (compilation algorithms, compiler design
> | considerations, etc.). 
> 
> Yes, we just need volunteers to tackle the problem.

I think we should make the decision as a project not to wait any longer
for Aldor, and commit to improving SPAD - up until now I think there has
been hesitation to commit serious effort to SPAD due to the possibility
of Aldor becoming available and making such work unnecessary.  To my
mind the first step to improving SPAD is to decide what SPAD should be,
since right now it doesn't have a formal language definition.
Unfortunately I am not an expert in this field.

> | In the process, we will probably learn how it
> | SHOULD be done, rather than how it is done now.  The existing code will
> | be very useful as a reference and some pieces might be drop in, but I
> | would like to see the ideas lead the code instead of the code leading
> | the ideas.
> 
> since you feel you must say that, could you explain in how you see the
> codes leading the ideas in the current practice?

Hmm.  I thought I knew what I was thinking when I said that, but on
reflection I'm not sure.  Strike it.

\start
Date: Thu, 16 Nov 2006 23:36:11 -0500
From: Bill Page
To: Waldek Hebisch
Subject: RE: ht.awk

On November 16, 2006 9:31 PM Waldek Hebisch wrote:
>
> Ralf asked:
>
> > Does somebody know where the file ht.awk is?
> >
> > All the .ht files say...
> >
> > % !! DO NOT MODIFY THIS FILE BY HAND !! Created by ht.awk.
> >
> > So if there is/were a script that generates the .ht files,
> why keep them
> > under source code control?
>

You can find the ht.awk script in the src/htex directory in this
tarball

http://wiki.axiom-developer.org/public/htex.tgz

See also the src/doc/htex files.

> I think we can forget about 'ht.awk': the whole process could not
> be very complicated, so it should be easy to create a new script.
> But the bigger problem is which workflow _we_ want to have?  IMO
> we should stick to a small controlled subset of latex as a main
> format and generate rest from it (the point is that once we allow
> more Latex features we will spent more time developing tools then
> writing documentation).
>

It looks to me like the original Axiom developers had already
given this some thought. Perhaps the src/doc/htex files represent
this sort of process?

> There is a second problem: .ht files in general contain more
> precise markup then 'book.pamphlet', but some differences may be
> due to editing done by Tim.

Yes, I think so. Tim has been editing the .tex files, not the
original .htex files.

> ATM the main difference I see is that book contains Tex formulas,
> but hypertex pages use textual output from Axiom.

I think that reflects the limitations of hyperdoc that cannot
display actual Tex formulas. On the other hand NAG did have a
commerical version of Axiom that used the Texplorer browser to
display these formula, hyperdoc documentation, and even live
graphics.

>
> >
> > And, Waldek, didn't you say that also the .pht files are
> > generated?
> >
>
> I put the following in 'src/hyper/Makefile.pamphlet':
>
> In the long term, the [[.pht]] and viewports should be
> generated at either
> build time or installation time using commands like:
> \begin{verbatim}
>              rm -f ht.db
>              ${HTADD} *.ht
>              for A in `ls *.ht`; do ${SMAN} -paste $$a ; done
>              rm -f ht.db
>              ${HTADD} *.ht *.pht
> \end{verbatim}
>

Ah, so it is 'htadd' that is supposed to create .pht files from the
.ht files. I see. Is there any documentation of this process?

> Hypertex has special code to extract parts of .ht file and prepare
> .input file for Axiom.  Once .input is ready Hypertex tells
> AXIOMsys to execute it, writing output to a file.  Then Hypertex
> should collect the output into .pht page.
>
> This 'almost' works: some pages are nicely generated, but on other
> it stops and one has manually quit Axiom.  It seems that Hypertex
> has problem detecting that AXIOMsys finished writing output file. 
>

Wow! How did you learn/know that this functionality even existed?
:-) By reading the code? I am very pleased and amazed.

I tried the following:

[page@axiom-developer pages]$ pwd
/home/page/axiom.build-improvements/src/hyper/pages

[page@axiom-developer pages]$ sman -paste CYCLES.ht
GCL (GNU Common Lisp)  2.6.8 CLtL1    Nov 15 2006 13:37:33
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
                        AXIOM Computer Algebra System
             Version: Axiom build-improvements branch 2006-11-09
             Timestamp: Wednesday November 15, 2006 at 19:04:51
-------------------------------------------------------------------------=
---
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-------------------------------------------------------------------------=
---
-

(1) ->
(1) -> making CYCLES.input
parsing: CycleIndicatorsXmpPage
writing:        )expose EVALCYC
   Loading =
/home/page/axiom.test/target/i686-pc-linux/autoload/bc-matrix.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/bc-misc.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/bc-solve.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/bc-util.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/ht-util.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/htsetvar.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/ht-root.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/br-con.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/br-data.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/showimp.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/br-op1.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/br-op2.
   Loading =
/home/page/axiom.test/target/i686-pc-linux/autoload/br-search.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/br-util.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/topics.
   Loading /home/page/axiom.test/target/i686-pc-linux/autoload/br-prof.
   Loading =
/home/page/axiom.test/target/i686-pc-linux/autoload/br-saturn.
   All user variables and function definitions have been cleared.
   EvaluateCycleIndicators is now explicitly
writing:        complete 1
      exposed in frame frame0
writing:        complete 2
writing:        complete 3
writing:        complete 7
writing:        elementary 7
writing:        alternating 7
writing:        cyclic 7
writing:        dihedral 7
writing:        graphs 5
writing:        cap(complete 2**2, complete 2*complete 1**2)
writing:        cap(elementary 2**2, complete 2*complete 1**2)
writing:        cap(complete 3*complete 2*complete 1,complete =
2**2*complete
1**2)
writing:        cap(elementary 3*elementary 2*elementary 1,complete
2**2*complete 1**2)
writing:        cap(complete 3*complete 2*complete 1,elementary
2**2*elementary 1**2)
writing:        eval(cup(complete 3*complete 2*complete 1, cup(complete
2**2*complete 1**2,complete 2**3)))
writing:        square:=dihedral 4
writing:        cap(complete 2**2,square)
writing:        cap(complete 3*complete 2**2,dihedral 7)
writing:        cap(graphs 5,complete 7*complete 3)
writing:        s(x) == powerSum(x)
writing:        cube:=(1/24)*(s 1**8+9*s 2**4 + 8*s 3**2*s 1**2+6*s =
4**2)
                   Compiling function s with type PositiveInteger
       -> SymmetricPolynomial Fraction Integer
writing:        cap(complete 4**2,cube)
writing:        cap(complete 2**3*complete 1**2,wreath(elementary
4,elementary 2))
writing:        cap(complete 2**3*complete 1**2,wreath(elementary =
4,complete
2))
writing:        cap(complete 2**3*complete 1**2,wreath(complete =
4,elementary
2))
writing:        cap(complete 2**3*complete 1**2,wreath(complete =
4,complete
2))
writing:        x: ULS(FRAC INT,'x,0) := 'x
writing:        ZeroOrOne: INT -> ULS(FRAC INT, 'x, 0)
writing:        Integers: INT -> ULS(FRAC INT, 'x, 0)
writing:        ZeroOrOne n == 1+x**n
writing:        ZeroOrOne 5
   Compiling function ZeroOrOne with type Integer
       -> UnivariateLaurentSeries(Fraction
      Integer,x,0)
writing:        Integers n == 1/(1-x**n)
writing:        Integers 5
   Compiling function Integers with type Integer
       -> UnivariateLaurentSeries(Fraction
      Integer,x,0)
writing:        eval(ZeroOrOne, graphs 5)
writing:        eval(ZeroOrOne,dihedral 8)
writing:        eval(Integers,complete 4)
writing:        eval(Integers,elementary 4)
writing:        eval(ZeroOrOne,cube)
writing:        eval(Integers,cube)
writing:        eval(Integers,graphs 5)
writing:        eval(ZeroOrOne ,graphs 15)
writing:        cap(dihedral 30,complete 7*complete 8*complete =
5*complete
10)
writing:        sf3221:= SFunction [3,2,2,1]
writing:        cap(sf3221,complete 2**4)
writing:        cap(sf3221, powerSum 1**8)
writing:        eval(Integers, sf3221)

At this point Axiom appeared to hang, but I hit Enter and got a
promt.

(47) -> )quit
   Please enter y or yes if you really want to
      leave the interactive environment and
      return to the operating system:
yes

----------

The following .input file was generated.

[page@axiom-developer pages]$ cat CYCLES.input

-- Input for page CycleIndicatorsXmpPage
)clear all

)expose EVALCYC
complete 1
complete 2
complete 3
complete 7
elementary 7
alternating 7
cyclic 7
dihedral 7
graphs 5
cap(complete 2**2, complete 2*complete 1**2)
cap(elementary 2**2, complete 2*complete 1**2)
cap(complete 3*complete 2*complete 1,complete 2**2*complete 1**2)
cap(elementary 3*elementary 2*elementary 1,complete 2**2*complete 1**2)
cap(complete 3*complete 2*complete 1,elementary 2**2*elementary 1**2)
eval(cup(complete 3*complete 2*complete 1, cup(complete 2**2*complete
1**2,complete 2**3)))
square:=dihedral 4
cap(complete 2**2,square)
cap(complete 3*complete 2**2,dihedral 7)
cap(graphs 5,complete 7*complete 3)
s(x) == powerSum(x)
cube:=(1/24)*(s 1**8+9*s 2**4 + 8*s 3**2*s 1**2+6*s 4**2)
cap(complete 4**2,cube)
cap(complete 2**3*complete 1**2,wreath(elementary 4,elementary 2))
cap(complete 2**3*complete 1**2,wreath(elementary 4,complete 2))
cap(complete 2**3*complete 1**2,wreath(complete 4,elementary 2))
cap(complete 2**3*complete 1**2,wreath(complete 4,complete 2))
x: ULS(FRAC INT,'x,0) := 'x
ZeroOrOne: INT -> ULS(FRAC INT, 'x, 0)
Integers: INT -> ULS(FRAC INT, 'x, 0)
ZeroOrOne n == 1+x**n
ZeroOrOne 5
Integers n == 1/(1-x**n)
Integers 5
eval(ZeroOrOne, graphs 5)
eval(ZeroOrOne,dihedral 8)
eval(Integers,complete 4)
eval(Integers,elementary 4)
eval(ZeroOrOne,cube)
eval(Integers,cube)
eval(Integers,graphs 5)
eval(ZeroOrOne ,graphs 15)
cap(dihedral 30,complete 7*complete 8*complete 5*complete 10)
sf3221:= SFunction [3,2,2,1]
cap(sf3221,complete 2**4)
cap(sf3221, powerSum 1**8)
eval(Integers, sf3221)

------------

And a new CYCLES.pht file seems to have been generated.

[page@axiom-developer pages]$ ls -l CYCLES.*
-rw-rw-r--    1 page     page        11323 Nov  3 21:47 CYCLES.ht
-rw-rw-r--    1 page     page         1587 Nov 16 22:28 CYCLES.input
-rw-rw-r--    1 page     page        68987 Nov 16 22:28 CYCLES.pht

[page@axiom-developer pages]$

\start
Date: 17 Nov 2006 08:43:19 +0100
From: Martin Rubey
To: Cliff Yapp
Subject: Re: SPAD and Aldor again

Cliff Yapp writes:

> I think we should make the decision as a project not to wait any longer for
> Aldor, and commit to improving SPAD - up until now I think there has been
> hesitation to commit serious effort to SPAD due to the possibility of Aldor
> becoming available and making such work unnecessary.  To my mind the first
> step to improving SPAD is to decide what SPAD should be, since right now it
> doesn't have a formal language definition.

For me this is totally clear: SPAD should become a free implementation of the
Aldor language. It would not make sense to have to different languages around.

And, as you know, in my opinion the first step in making this happen is to make
the Axiom interpreter (!) understand Aldor generated code, i.e., dependent
types.

Peter Broadbery is currently making Aldor extend work in Axiom. That's a giant
step, in fact! Unfortuantely, it seems that support for dependent types is even
more difficult. One would have to understand how aldor and axiom work
together. As far as I know, there are only very few people around who know
about this already. 

I guess it's Peter. Laurentiu says he doesn't know about the axiom side, but I
know he knows foam. Tim, do you know about that stuff?  Gaby, Waldek, did you
dig into this connection yet?

\start
Date: Fri, 17 Nov 2006 10:19:40 +0000
From: Peter Broadbery
To: Martin Rubey
Subject: re: SPAD and Aldor again

On Fri, 2006-11-17 at 08:43 +0100, Martin Rubey wrote:
> Cliff Yapp writes:
> 
> > I think we should make the decision as a project not to wait any longer for
> > Aldor, and commit to improving SPAD - up until now I think there has been
> > hesitation to commit serious effort to SPAD due to the possibility of Aldor
> > becoming available and making such work unnecessary.  To my mind the first
> > step to improving SPAD is to decide what SPAD should be, since right now it
> > doesn't have a formal language definition.
> 
> For me this is totally clear: SPAD should become a free implementation of the
> Aldor language. It would not make sense to have to different languages around.
> 
> And, as you know, in my opinion the first step in making this happen is to make
> the Axiom interpreter (!) understand Aldor generated code, i.e., dependent
> types.
> 

This is currently stymied by the aldor compiler not being able to generate .asy files 
where there are dependent types in signatures (try 'foo: (R: Ring, t: R)').  The .asy 
generation code enters a loop, which is a bit poor.  

Even once you've got your dependent signatures into axiom, it has to (presumably) be 
able to interpret them, which will need a more complex type matching process than 
what currently exists (I think).  On the plus side, doing this is a good step towards a 
real compiler. 


> Peter Broadbery is currently making Aldor extend work in Axiom. That's a giant
> step, in fact! Unfortuantely, it seems that support for dependent types is even
> more difficult. One would have to understand how aldor and axiom work
> together. As far as I know, there are only very few people around who know
> about this already. 

The mechanism is fairly simple - just fake up objects that look like
aldor domains and categories in axiom (interop.boot does this), and on
the other side interpret asy files as defining axiom types (daase.lisp).
Unfortunately this doesn't add any aldor semantics into axiom, or the
other way round.

\start
Date: Fri, 17 Nov 2006 11:24:03 +0100 (CET)
From: Waldek Hebisch
To: Peter Broadbery
Subject: re: SPAD and Aldor again

Peter Broadbery  wrote:
> On Fri, 2006-11-17 at 08:43 +0100, Martin Rubey wrote: 
> > Peter Broadbery is currently making Aldor extend work in Axiom. That's a giant
> > step, in fact! Unfortuantely, it seems that support for dependent types is even
> > more difficult. One would have to understand how aldor and axiom work
> > together. As far as I know, there are only very few people around who know
> > about this already. 
> 
> The mechanism is fairly simple - just fake up objects that look like
> aldor domains and categories in axiom (interop.boot does this), and on
> the other side interpret asy files as defining axiom types (daase.lisp).
                                                              ^^^^^^^^^^
You mean 'as.boot'?

\start
Date: Fri, 17 Nov 2006 10:35:04 +0000
From: Peter Broadbery
To: Waldek Hebisch
Subject: re: SPAD and Aldor again

On Fri, 2006-11-17 at 11:24 +0100, Waldek Hebisch wrote:
> Peter Broadbery  wrote:
> > On Fri, 2006-11-17 at 08:43 +0100, Martin Rubey wrote: 
> > > Peter Broadbery is currently making Aldor extend work in Axiom. That's a giant
> > > step, in fact! Unfortuantely, it seems that support for dependent types is even
> > > more difficult. One would have to understand how aldor and axiom work
> > > together. As far as I know, there are only very few people around who know
> > > about this already. 
> > 
> > The mechanism is fairly simple - just fake up objects that look like
> > aldor domains and categories in axiom (interop.boot does this), and on
> > the other side interpret asy files as defining axiom types (daase.lisp).
>                                                               ^^^^^^^^^^
> You mean 'as.boot'?
> 
> 

That one as well (my mistake).  daase does the reading and setting up
imports, as.boot does the mapping to axiom types.

\start
Date: 17 Nov 2006 11:36:01 +0100
From: Martin Rubey
To: Peter Broadbery
Subject: re: SPAD and Aldor again

Peter Broadbery writes:

> On Fri, 2006-11-17 at 08:43 +0100, Martin Rubey wrote:

> > And, as you know, in my opinion the first step in making this happen is to
> > make the Axiom interpreter (!) understand Aldor generated code, i.e.,
> > dependent types.
> 
> This is currently stymied by the aldor compiler not being able to generate
> .asy files where there are dependent types in signatures
> (try 'foo: (R: Ring, t: R)').  The .asy generation code enters a loop, which
> is a bit poor.

Does this mean that one would need to modify the Aldor compiler? I.e., we would
need access to the sources?

> Even once you've got your dependent signatures into axiom, it has to
> (presumably) be able to interpret them, which will need a more complex type
> matching process than what currently exists (I think).  On the plus side,
> doing this is a good step towards a real compiler.

So, is there any way to make this happen? Money?

\start
Date: Fri, 17 Nov 2006 12:27:36 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: re: SPAD and Aldor again

Martin Rubey wrote:
> Cliff Yapp writes:
> 
> > I think we should make the decision as a project not to wait any longer for
> > Aldor, and commit to improving SPAD - up until now I think there has been
> > hesitation to commit serious effort to SPAD due to the possibility of Aldor
> > becoming available and making such work unnecessary.  To my mind the first
> > step to improving SPAD is to decide what SPAD should be, since right now it
> > doesn't have a formal language definition.
> 
> For me this is totally clear: SPAD should become a free implementation of the
> Aldor language. It would not make sense to have to different languages around.
> 

I am affraid we will have two different languages: there are legal reasons
and technical ones: I do not see why we should limit ourselfs to capabilites
present in Aldor and (assuming that we want this) implementing _all_
capabilities of Aldor is likely to take long time.  I do not want to
underestimate big things (dependent types) but getting little details
100% compatible would probably take more time.

I do not want to diverge just for beeing different, but agreeing that
we just one _some_ Aldor features in Axiom language is IMHO a better
way: we will not waste time trying to be 100% compatible.

> And, as you know, in my opinion the first step in making this happen is to make
> the Axiom interpreter (!) understand Aldor generated code, i.e., dependent
> types.
> 

I tend to think that adding dependent types to compiler is easier: compiler
has to do typechecking and probably some runtime support (the rest should
work the same).  Interpreter needs more runtime support and type 
inferencing.  Inferencing is harder. And of course there is added burden
of keeping thing Aldor compatible.

OTOH design of dependent types in Aldor can be criticised.  One thing
is "Type : Type" (personaly I find this reasonable design choice).
Another is using unevaluated parameters (not doing beta convertion)
for typechecking (more precisely for deciding type equivalence).  However,
"Type : Type" + equivalence after evaluating parameters would make compile 
time typechecking undecidable.  I think that we should use evaluated
parameters for deciding type equivalence, but postpone some checking to
runtime.

> Peter Broadbery is currently making Aldor extend work in Axiom. That's a giant
> step, in fact! Unfortuantely, it seems that support for dependent types is even
> more difficult. One would have to understand how aldor and axiom work
> together. As far as I know, there are only very few people around who know
> about this already. 
> 
> I guess it's Peter. Laurentiu says he doesn't know about the axiom side, but I
> know he knows foam. Tim, do you know about that stuff?  Gaby, Waldek, did you
> dig into this connection yet?
> 

I looked at extend first: after reading Aldor doc I think that compiler
part should be easy.  Namely, Aldor requires that you import an extension
before you use it.  So basically, all you need is to patch compiler
symbol tables after importing an extension (AFAIU Spad compiler alredy
have needed functionality, to support recompilation in a single image).

More tricky is allowing dynamic loading of extensions: start interpreter,
stash few instances of a type in datastructres, then extend it.  In fact,
this is not very hard if you use double indirection (element -> unique
proxy -> type), but AFAICS Spad uses only single indirection (element
-> type).  I am not sure how well extension works in Aldor interpreter.
My impression is that Aldor uses single indirection and lazyness,
which should work nicely for loading at startup but may have problem
if you load new extensions in the middle of the run.

\start
Date: Fri, 17 Nov 2006 12:51:23 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: Re: ht.awk

Bill Page wrote:
> On November 16, 2006 9:31 PM Waldek Hebisch wrote:
> > I put the following in 'src/hyper/Makefile.pamphlet':
> > 
> > In the long term, the [[.pht]] and viewports should be 
> > generated at either
> > build time or installation time using commands like:
> > \begin{verbatim}
> >              rm -f ht.db
> >              ${HTADD} *.ht
> >              for A in `ls *.ht`; do ${SMAN} -paste $$a ; done
> >              rm -f ht.db
> >              ${HTADD} *.ht *.pht
> > \end{verbatim}
> > 
> 
> Ah, so it is 'htadd' that is supposed to create .pht files from the
> .ht files. I see. Is there any documentation of this process?
>

It is the 'hypertex' program ('htadd' can not do this).  See 
HTXAdvPage5.ht in hypertex documentation (I did not found corresponding
part in Axiom book, so maybe it is missing from printed version).
 
> > Hypertex has special code to extract parts of .ht file and prepare
> > .input file for Axiom.  Once .input is ready Hypertex tells
> > AXIOMsys to execute it, writing output to a file.  Then Hypertex
> > should collect the output into .pht page.
> > 
> > This 'almost' works: some pages are nicely generated, but on other
> > it stops and one has manually quit Axiom.  It seems that Hypertex
> > has problem detecting that AXIOMsys finished writing output file.  
> > 
> 
> Wow! How did you learn/know that this functionality even existed?
> :-) By reading the code? I am very pleased and amazed.
> 

Yes, reading the code.  Actually, I have found corrct place serching
for embedded paths (I wanted to fix a different problem).  It is possible
that I have read HTXAdvPage5.ht earlier, but since a lot of browser
functionality did not work I would probably ignore it (and forget later).

\start
Date: Fri, 17 Nov 2006 14:08:05 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: re: [Axiom-mail] Re: `)read' and large inputs
Cc: Themos Tsikas

Vanuxem Gr=E9gory wrote:
> I encountered the same issue with the history of Axiom in a file which
> is buggy (see
> http://wiki.axiom-developer.org/323HandlingOfTheHistoryInAFile)
>
> I reported the Library file problem too on IssueTracker.
>

I applied the patch below to wh-sandbox -- so library and history
handling should now work in wh-sandbox.  The last part (adding slash)
is not needed for the testcase, but my show up in other situations.
ATM Axiom code handles slashes in ad hoc manner: sometimes directory
names end in slashes sometimes names without slashes are used and
slash is added later.  We should use uniform convention here --
probably store directory names without slases and add slases when
forming files nemes (that would agree with Lisp namestring and with
user expectation about filenames).

diff -ru wh-sandbox.bb/src/algebra/files.spad.pamphlet wh-sandbox/src/algeb=
ra/files.spad.pamphlet
--- wh-sandbox.bb/src/algebra/files.spad.pamphlet	2006-11-15 23:00:59.00000=
0000 +0100
+++ wh-sandbox/src/algebra/files.spad.pamphlet	2006-11-17 01:54:38.00000000=
0 +0100
@@ -389,10 +389,8 @@
 
         defstream(fn: Name, mode: IOMode): FileState ==
             mode = "input"  =>
-              not readable? fn => error ["File is not readable", fn]
               RDEFINSTREAM(fn::String)$Lisp
             mode = "output" =>
-              not writable? fn => error ["File is not writable", fn]
               RDEFOUTSTREAM(fn::String)$Lisp
             error ["IO mode must be input or output", mode]
 
@@ -409,9 +407,7 @@
             mode = "either" =>
                 exists? fname =>
                     open(fname, "input")
-                writable? fname =>
-                    reopen_!(open(fname, "output"), "input")
-                error "File does not exist and cannot be created"
+                reopen_!(open(fname, "output"), "input")
             [fname, defstream(fname, mode), mode]
         reopen_!(f, mode) ==
             close_! f
@@ -506,6 +502,10 @@
              ++ \spad{lib.k := v} saves the value \spad{v} in the library
              ++ \spad{lib}.  It can later be extracted using the key \spad=
{k}.

+         close_!: % -> %
+          ++ close!(f) returns the library f closed to input and output.
+
+
     == KeyedAccessFile(Any) add
          Rep := KeyedAccessFile(Any)
          library f == open f
diff -ru wh-sandbox.bb/src/interp/fname.lisp.pamphlet wh-sandbox/src/interp=
/fname.lisp.pamphlet
--- wh-sandbox.bb/src/interp/fname.lisp.pamphlet	2006-11-15 23:01:44.000000=
000 +0100
+++ wh-sandbox/src/interp/fname.lisp.pamphlet	2006-11-17 01:33:03.000000000=
 +0100
@@ -94,7 +94,7 @@
     (if s s "") ))
 
 (defun |fnameExists?| (f)
-  (if (probe-file f) 't nil))
+  (if (vmlisp::axiom-probe-file (namestring f)) 't nil))

 (defun |fnameReadable?| (f)
 #+:CCL (file-readablep f)
@@ -112,7 +112,8 @@
     (do ((fn))
         (nil)
         (setq fn (|fnameMake| d (string (gensym n)) e))
-        (if (not (probe-file fn)) (return-from |fnameNew| fn)) )))
+        (if (not (vmlisp::axiom-probe-file (namestring fn)))
+           (return-from |fnameNew| fn)) )))
 @
 \eject
 \begin{thebibliography}{99}
diff -ru wh-sandbox.bb/src/interp/nlib.lisp.pamphlet wh-sandbox/src/interp/=
nlib.lisp.pamphlet
--- wh-sandbox.bb/src/interp/nlib.lisp.pamphlet	2006-11-15 23:01:45.0000000=
00 +0100
+++ wh-sandbox/src/interp/nlib.lisp.pamphlet	2006-11-16 22:32:36.000000000 =
+0100
@@ -435,9 +435,6 @@
 (defun make-full-namestring (filearg &optional (filetype nil))
   (namestring (merge-pathnames (make-filename filearg filetype))))

-(defun probe-name (file)
-  (if (probe-file file) (namestring file) nil))
-
 (defun get-directory-list (ft &aux (cd (namestring $current-directory)))
   (cond ((member ft '("NRLIB" "DAASE" "EXPOSED") :test #'string=)
 	   (if (eq BOOT::|$UserLevel| 'BOOT::|development|)
@@ -451,8 +448,10 @@
 (defun axiom-probe-file (file)
     (if (equal (|directoryp| file) -1)
          nil
-         (truename file))
-)
+         (truename file)))
+
+(defun probe-name (file)
+  (if (axiom-probe-file file) (namestring file) nil))

 (defun make-input-filename (filearg &optional (filetype nil))
    (let*
@@ -465,7 +464,7 @@
 	(dolist (dir dirs (probe-name filename))
 		(when
 		 (axiom-probe-file
-		  (setq newfn (concatenate 'string dir filename)))
+		  (setq newfn (concatenate 'string dir "/" filename)))
 		 (return newfn)))
         (probe-name filename))))

\start
Date: Fri, 17 Nov 2006 08:28:09 -0500
From: Cliff Yapp
To: Waldek Hebisch
Subject: re: SPAD and Aldor again

Waldek Hebisch wrote:
> Martin Rubey wrote:
>> Cliff Yapp writes:
>>
>>> I think we should make the decision as a project not to wait any longer for
>>> Aldor, and commit to improving SPAD - up until now I think there has been
>>> hesitation to commit serious effort to SPAD due to the possibility of Aldor
>>> becoming available and making such work unnecessary.  To my mind the first
>>> step to improving SPAD is to decide what SPAD should be, since right now it
>>> doesn't have a formal language definition.
>> For me this is totally clear: SPAD should become a free implementation of the
>> Aldor language. It would not make sense to have to different languages around.
>>
> 
> I am affraid we will have two different languages: there are legal reasons

Indeed.  The Aldor documentation is not free at all, and any attempt to
define Aldor in a literate style would have to duplicate Aldor without
duplicating too closely its documentation - that's a real problem.

> and technical ones: I do not see why we should limit ourselfs to capabilites
> present in Aldor and (assuming that we want this) implementing _all_
> capabilities of Aldor is likely to take long time.  I do not want to
> underestimate big things (dependent types) but getting little details
> 100% compatible would probably take more time.

I don't know the full history of Aldor, but my impression is that it
grew beyond just being "the language used to implement mathematics in
Axiom" into a more general purpose language.  We need a language to
implement mathematics in Axiom, so hopefully retaining that focus will
make the task somewhat simpler.

> I do not want to diverge just for beeing different, but agreeing that
> we just one _some_ Aldor features in Axiom language is IMHO a better
> way: we will not waste time trying to be 100% compatible.

Agreed.  One thought - it looks like libaldor and Algebra were Manuel
Bronstein's projects - did he assign copyright to Aldor.org or was it
still his projects and just being distributed with Aldor.org's offering?
 If so perhaps that could make use of those libraries (if they become
available) and target SPAD to support them, perhaps tweaking both as needed.

I know that situation is moving slowly as well (quite understandable) so
perhaps a logical direction to take is look at what features are used in
libaldor, Algebra, SumIT etc. and see what would be required to support
those libraries directly that SPAD doesn't supply.

>> And, as you know, in my opinion the first step in making this happen is to make
>> the Axiom interpreter (!) understand Aldor generated code, i.e., dependent
>> types.
>>
> 
> I tend to think that adding dependent types to compiler is easier: compiler
> has to do typechecking and probably some runtime support (the rest should
> work the same).  Interpreter needs more runtime support and type 
> inferencing.  Inferencing is harder. And of course there is added burden
> of keeping thing Aldor compatible.

I think that will be an important discussion to be had as a project -
just how compatible with Aldor we want to stay.

\start
Date: 17 Nov 2006 14:28:49 +0100
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: Ping: case insensitive filesystems

Cliff Yapp writes:

| Gabriel Dos Reis wrote:
| > Cliff Yapp writes:
| > 
| > 
| > [...]
| > 
| > | I have always thought that if we are making Axiom into literate
| > | documents, they should read as such - if I am looking for the pamphlet
| > | that describes the SPAD compiler I am interested in what it IS doing and
| > | what it is intended to do and why, not what it did in the past before it
| > | was fixed.
| > 
| > This type of stance is appropriate for trunk.  My experience with
| > workind on branches tells me that it creates troubles when it comes to
| > merge do merges.  But, hey the system is already largely
| > non-documented, so why not continue that way?  
| 
| Experience trumps ideas ;-),

and with no experience, no ideas.

[...]

| I think we should make the decision as a project not to wait any longer
| for Aldor,

I don't know for you, but I'm not waiting for Aldor.  I've decided a
long time ago to go with SPAD and improve it.  I think I've sid that
many times.  But, yes, the project has to decide.

\start
Date: 17 Nov 2006 14:30:41 +0100
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: SPAD and Aldor again

Martin Rubey writes:

[...]

| I guess it's Peter. Laurentiu says he doesn't know about the axiom
| side, but I know he knows foam. Tim, do you know about that stuff?
| Gaby, Waldek, did you dig into this connection yet?

I've looked into FOAM, yes.  

But, from my perspective improved SPAD should not be a clone of Aldor.

\start
Date: 17 Nov 2006 14:39:12 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: SPAD and Aldor again

Waldek Hebisch writes:

| Martin Rubey wrote:
| > Cliff Yapp writes:
| > 
| > > I think we should make the decision as a project not to wait any longer for
| > > Aldor, and commit to improving SPAD - up until now I think there has been
| > > hesitation to commit serious effort to SPAD due to the possibility of Aldor
| > > becoming available and making such work unnecessary.  To my mind the first
| > > step to improving SPAD is to decide what SPAD should be, since right now it
| > > doesn't have a formal language definition.
| > 
| > For me this is totally clear: SPAD should become a free implementation of the
| > Aldor language. It would not make sense to have to different languages around.
| > 
| 
| I am affraid we will have two different languages: there are legal reasons
| and technical ones: I do not see why we should limit ourselfs to capabilites
| present in Aldor and (assuming that we want this) implementing _all_
| capabilities of Aldor is likely to take long time. 

I agree.  I don't believe that the goal of improved SPAD shall be a
clone of Aldor.  

[...]

| OTOH design of dependent types in Aldor can be criticised.  One thing
| is "Type : Type" (personaly I find this reasonable design choice).

This choice must be explored and studied carefully.  Improved SPAD
must ideally have a formal semantics (but, in reallity I suspect we
will only approximate it) and the implications of Type:Type must be
understood, especially since people has expressed many times
connection with proof theory.  I don't consider use of "pretend" a
good solution.

| Another is using unevaluated parameters (not doing beta convertion)
| for typechecking (more precisely for deciding type equivalence).  However,
| "Type : Type" + equivalence after evaluating parameters would make compile 
| time typechecking undecidable.

I'm fine with undecidable type checking in general , as long as we
have identified a large subset where it is decidable.

We must also look at how to convince the compiler to do delta
conversion without getting in a blackhole.

\start
Date: 17 Nov 2006 15:39:51 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: KUDOS

Dear Waldek,

I'd just like to send you a BIG

             _______ _                 _     __     __           _ 
            |__   __| |               | |    \ \   / /          | |
               | |  | |__   __ _ _ __ | | __  \ \_/ /__  _   _  | |
               | |  | '_ \ / _` | '_ \| |/ /   \   / _ \| | | | | |
               | |  | | | | (_| | | | |   <     | | (_) | |_| | |_|
               |_|  |_| |_|\__,_|_| |_|_|\_\    |_|\___/ \__,_| (_)


for your wonderful work on HyperDoc. Being able to use users, uses, dependents
is just wonderful!

\start
Date: Fri, 17 Nov 2006 15:39:39 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: Ping: case insensitive filesystems

Gabriel Dos Reis wrote:
> Explainingg why the new code is right implies one needs to understand
> what the old code is doing and why it is wrong.  In that respect, it
> is just as important as the why of new code.
> 

I would say that one of the major sins of Axiom code is that it is
hard to say what the code is doing.  More precisely: I belive that
even designers of Axiom could not tell you what Axiom is doing on
invalid inputs.  And while designers had some idea what is 
considered as valid input, Spad compiler accepts without complaint
a lot of garbage.  I belive that in general algebra files give
you better idea about Spad language then the compiler.

So, I belive that if we understand what Spad compiler is doing
with algebra and we implement equivalent functionality in new 
compiler we can reasonably scrap the old one.  

\start
Date: 17 Nov 2006 15:51:42 +0100
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: SPAD and Aldor again

Cliff Yapp writes:

| Waldek Hebisch wrote:
| > Martin Rubey wrote:
| >> Cliff Yapp writes:
| >>
| >>> I think we should make the decision as a project not to wait any longer for
| >>> Aldor, and commit to improving SPAD - up until now I think there has been
| >>> hesitation to commit serious effort to SPAD due to the possibility of Aldor
| >>> becoming available and making such work unnecessary.  To my mind the first
| >>> step to improving SPAD is to decide what SPAD should be, since right now it
| >>> doesn't have a formal language definition.
| >> For me this is totally clear: SPAD should become a free implementation of the
| >> Aldor language. It would not make sense to have to different languages around.
| >>
| > 
| > I am affraid we will have two different languages: there are legal reasons
| 
| Indeed.  The Aldor documentation is not free at all, and any attempt to
| define Aldor in a literate style would have to duplicate Aldor without
| duplicating too closely its documentation - that's a real problem.

I cannot parse this. Could you elaborate?

| > and technical ones: I do not see why we should limit ourselfs to capabilites
| > present in Aldor and (assuming that we want this) implementing _all_
| > capabilities of Aldor is likely to take long time.  I do not want to
| > underestimate big things (dependent types) but getting little details
| > 100% compatible would probably take more time.
| 
| I don't know the full history of Aldor, but my impression is that it
| grew beyond just being "the language used to implement mathematics in
| Axiom" into a more general purpose language.  We need a language to
| implement mathematics in Axiom, so hopefully retaining that focus will
| make the task somewhat simpler.

You don't need a language to do *just* mathematics in Axiom.  You also
need a language to communicate with the world around.  All major
systems for computation mathematics have grown into that position.
Don't get blindsighted.

[...]

| I think that will be an important discussion to be had as a project -
| just how compatible with Aldor we want to stay.

Probably.  I would like to see a discussion about what is necessary to
support computational mathematics in Axiom, rather than how closely SPAD
should ressemble another language.

\start
Date: 17 Nov 2006 16:04:48 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: Ping: case insensitive filesystems

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Explainingg why the new code is right implies one needs to understand
| > what the old code is doing and why it is wrong.  In that respect, it
| > is just as important as the why of new code.
| > 
| 
| I would say that one of the major sins of Axiom code is that it is
| hard to say what the code is doing. 

Yes.  

| More precisely: I belive that
| even designers of Axiom could not tell you what Axiom is doing on
| invalid inputs. 

Yes.

| And while designers had some idea what is 
| considered as valid input, Spad compiler accepts without complaint
| a lot of garbage.

Yes. And it usually crashes.

|  I belive that in general algebra files give
| you better idea about Spad language then the compiler.

That is true of any language, especially for any language that evolves.

However, as is the case in many languages, the algebras contains in
many places workaround limitations of the compiler (not just the
language).  Consequently, it is also hard to tell what the language is.

| So, I belive that if we understand what Spad compiler is doing
| with algebra and we implement equivalent functionality in new 
| compiler we can reasonably scrap the old one.  

yes, but you'll notice that to get that point, understanding the
existing one is equally important.  

It is not a static thing.  It is a living thing.  Until one gets to
the point where one has an improved version, the current version is
important.  When we have the improved version, the old version would 
be said to *have been* important -- even it *is not* as important
anymore. Software live, breath until they die.  And when they die we
can't rewrite history.  

\start
Date: 17 Nov 2006 16:41:21 +0100
From: Martin Rubey
To: Gabriel Dos Reis, Christian Aistleitner, Waldek Hebisch
Subject: re: SPAD and Aldor again

Dear Christian, Gaby, Waldek,

Christian, I'm copying this to you since I think that you have a lot to say
with respect to features and shortcomings of Aldor. I would like to ask you to
join the discussion, time permitting.

Gabriel Dos Reis writes:

> I would like to see a discussion about what is necessary to support
> computational mathematics in Axiom, rather than how closely SPAD should
> ressemble another language.

I think that this is beyond a group of a dozen part-time developers, and in
fact, I believe that this is very likely beyond the abilities of the average
mathematician. As evidence I'd like to present the "languages" of maple and
mupad, which I believe to be quite inferior (maple: obviously, mupad: very
likely) to Aldor.

Of course, if you or somebody else has the resources, don't hesitate and go
ahead. If not, I'd rather stick (as far as possible) with the semantics of
Aldor.

Don't get me wrong, please: I would not insist on a clone of Aldor, but at
least in the beginning, I think it will be easier to clone certain features.

I did quite a bit of work with Aldor now (within the species project together
with Ralf), and I'm quite convinced of the features of this language. In
particular, the semantics of Aldor feel very "sound" to me, i.e., Aldor usually
does what I expect it to do and allows what I would expect it to allow.

There is another point for staying compatible with Aldor: In that case,
mathematically inclined developers can code using Aldor for the time being, and
switch to a free version when it is available. There is no way I can help with
improving the compiler. But I need dependent types now, not in one or two
years. Thus, I mainly need improvements of the interpreter.

Of course, there are things one might be able to improve, as you showed with
the Monoid - AbelianMonoid example.  However, I do not really see how to
circumvent this in a sensible way.

Furthermore, the restrictions on code in type context (see AUG Section 7.3),
where the Aldor language does not specify when code is evaluated, can be a
pain. (In fact, part of our code is not conforming with respect to this
restriction, although it "works".)

Waldek writes:

> I do not want to underestimate big things (dependent types) but getting
> little details 100% compatible would probably take more time.

I'm not sure about the amount of "little details". In fact, I am too blind to
see any "little details" at all. I don't care to much for exceptions currently,
for example. Is this a "little detail"? Generators, on the other hand, are
really useful, and, it seems to me, beautifully integrated. Other than that, I
guess we need that types are first class objects. 

Gaby pointed out that "==" has different semantics in Aldor and Axiom, but I
have the feeling that this difference is not so severe: in fact, I don't know
of a way to define a constant in SPAD, currently, other than to define a
macro. As far as I know, in Axiom "==" can only be used to define functions
and, in SPAD, types. (Aren't types just a special kind of functions?)

Should we copy this discussion to Stephen Watt? :-)

\start
Date: Fri, 17 Nov 2006 16:48:45 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: SPAD and Aldor again

> I've looked into FOAM, yes.  
> 
> But, from my perspective improved SPAD should not be a clone of Aldor.

Do you also consider to forget about FOAM? I guess, it is not below SPAD 
anyway.

\start
Date: Fri, 17 Nov 2006 10:55:20 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: ht.awk

# Copyright The Numerical Algorithms Group Limited 1992-94.
#
# This is the main file for processing htex files and creating ht files
# It accepts one argument or four arguments. After processing the
# arguments, ARGC is reset to 2, if necessary.
#
# One argument case:
#   - argument 1 is a ugXX.htex Users Guide chapter file where XX
#     is the chapter number.
#   - \head{chapter}... or \headTODO{chapter}... tags are included
#
# Four argument case:
#   - this is an example file for an exposed constructor of the form
#     abbr.htex where abbr is the constructor abbreviation. This file
#     name is the first argument
#   - 2nd argument = full constructor name
#   - 3rd argument = the users guide chapter number for the examples
#     chapter
#   - 4th argument = the section number to be used for the constructor

BEGIN           {
        globalPagePrefix = "NOT-ASSIGNED-YET"
        globalTitle      = "NOT-ASSIGNED-YET"
        globalNumber     = "NOT-ASSIGNED-YET"

        fn = ARGV[1]
        if (ARGC > 2) { # example file, not chapter file
                conName = ARGV[2]
                example = 1
                chapNum = ARGV[3]
                secNum  = ARGV[4]
                ARGC = 2
                inSect = 1
        }
        else {  # chapter file, not example file
                # figure out what the chapter number is. we assume the
                # filename is of the form ugXX.htex
                chapNum = 0 + substr(fn,length(fn)-1,2)
                secNum = 0
                example = 0
                inSect = 0
        }
        ARGV[1] = fn".htex"
        xmpStepCounter = 0
        inChap = 0
        inSubSect = 0
        inCenter = 0
        indent = 0
        inItem = 0
        inEnum = 0
        subSecNum = 0
        comsep = "% ====================================================================="
        print "% Copyright The Numerical Algorithms Group Limited 1992-94. All rights reserved."
        print "% !! DO NOT MODIFY THIS FILE BY HAND !! Created by ht.awk."
        if (example) {
                num = chapNum"."secNum
                unConName = unnumber(conName)
                addStdDefs(unConName"Xmp",conName,num)
                printf "\\begin{page}{%sXmpPage}{%s %s}\n",unConName,num,conName
                print comsep
                print "\\beginscroll"
        }
}

# just kill full line comments that have a blank in col 2
/^% /            {
        next
}

# delete index entries
/^\\index/ || /^\\exptypeindex/ || /^\\syscmdindex/ {
        printf("%%-%% \\HD%s{%sPage}{%s}{%s}\n",substr($0,2), globalPagePrefix, globalNumber, globalTitle)
        next
}

# delete lines between \begin{texonly} and \end{texonly}
/^\\begin{texonly}/     {
        while (substr($1,1,13) != "\\end{texonly}") # might have trailing %
                getline
        next
}
# delete lines between \texonly and \endtexonly
/^\\texonly/     {
        while (substr($1,1,11) != "\\endtexonly") # might have trailing %
                getline
        next
}

# delete lines between \begin{inputonly} and \end{inputonly}
/^\\begin{inputonly}/     {
        while (substr($1,1,15) != "\\end{inputonly}") # might have trailing %
                getline
        next
}

# handle discard stuff (delete the lines)
/^\\begin{discard}/   {
        while (substr($1,1,13) != "\\end{discard}") # might have trailing %
                getline
        next
}

# delete \htonly and \endhtonly lines (leaving what is in between)
/^\\htonly/ || /^\\endhtonly/  {
        next
}

# ignore towrite environment
/^\\begin{towrite}/ || /^\\end{towrite}/ {
    next
}

# translate tinyverbatim mode to verbatim and pass through
/^\\begin{tinyverbatim}/        {
        print "\\begin{verbatim}"
        getline
        while ($1 != "\\end{tinyverbatim}") {
                print
                getline
        }
        print "\\end{verbatim}"
        next
}

# handle various xmpLines and figXmpLines environments

/^\\begin{xmpLinesNoReset}/ {
        print "\\beginImportant"
        print "  "
        print "\\noindent"
        next
}
/^\\end{xmpLinesNoReset}/ {
        print "\\endImportant"
        next
}
/^\\begin{xmpLinesNoResetPlain}/ || /^\\end{xmpLinesNoResetPlain}/{
        print "  "
        print "\\noindent"
        next
}
/^\\begin{xmpLinesPlain}/ || /^\\end{xmpLinesPlain}/{
        xmpStepCounter = 0
        print "  "
        print "\\noindent"
        next
}
/^\\begin{xmpLines}/ || /^\\begin{figXmpLines}/ {
        print "\\beginImportant"
        print "  "
        print "\\noindent"
        xmpStepCounter = 0
        next
}
/^\\end{xmpLines}/ || /^\\end{figXmpLines}/ {
        print "\\endImportant"
        xmpStepCounter = 0
        next
}

/^\\xmpLine\{/  {
        code = extractArg($0,1) # throw away comments
        gsub(/ /,"\\ ",code)
        xmpStepCounter++
        sc = xmpStepCounter"."
        scl = length(sc)
        while (scl < 4) {
          sc = sc"\\ "    # adding two characters
          scl++
        }
        printf "{\\tt %s\\ %s}\\newline\n",sc,code
        next
}


/^\\begin{simpleList}/ {
        print "\\begin{items}"
        next
}

/^\\end{simpleList}/ {
        print "\\end{items}"
        next
}

# pass through lines in spadsrc environment (piles) removing backslashes
/^\\begin{spadsrc}/     {
        print
        getline
        while ($1 != "\\end{spadsrc}") {
                gsub(/\\/,"")
                print
                getline
        }
        print
        next
}

/^\\spadcommand/        {
        gsub(/\\_/,"_")
        print "\\spadpaste"substr($0,13)
        next
}
/^\\nullspadcommand/        {
        gsub(/\\_/,"_")
        print "\\spadpaste"substr($0,17)
        next
}
/^\\spadpaste/          {
        gsub(/\\_/,"_")
        print
        next
}
/^\\spadgraph/          {
        gsub(/\\_/,"_")
        print "\\graphpaste"substr($0,11)
        next
}

# do some translations
        {
        gsub(/upclick/,"uparrow")
}

# handle cross references
/\\spadref/             {
        while (i = match($0,/\\spadref{/)) {
          lab = substr($0,i+9) # front of label
          lab = substr(lab,1,-1 + index(lab,"}"))
          lab = unnumber(lab)
          str = "\\downlink{``\\" lab "Title''}{" lab "Page} in Section \\" lab "Number\\ignore"
          sub(/\\spadref/,str)
        }
}
/\\xmpref/             {
        while (i = match($0,/\\xmpref{/)) {
          lab = substr($0,i+8) # front of label
          lab = substr(lab,1,-1 + index(lab,"}"))
          str = "\\downlink{`" lab "'}{" unnumber(lab) "XmpPage}\\ignore"
          sub(/\\xmpref/,str)
        }
}
/\\menuxmpref/             {
        while (i = match($0,/\\xmpref{/)) {
          lab = substr($0,i+12) # front of label
          lab = substr(lab,1,-1 + index(lab,"}"))
          str = "\\menudownlink{`" lab "'}{" unnumber(lab) "XmpPage}\\ignore"
          sub(/\\menuxmpref/,str)
        }
}
/\\chapref/             {
        while (i = match($0,/\\chapref{/)) {
          lab = substr($0,i+9) # front of label
          lab = substr(lab,1,-1 + index(lab,"}"))
          lab = unnumber(lab)
          str = "\\downlink{``\\" lab "Title''}{" lab "Page} in Chapter \\" lab "Number\\ignore"
          sub(/\\chapref/,str)
        }
}
/\\appxref/             {
        while (i = match($0,/\\appxref{/)) {
          lab = substr($0,i+9) # front of label
          lab = substr(lab,1,-1 + index(lab,"}"))
          lab = unnumber(lab)
          str = "\\downlink{``\\" lab "Title''}{" lab "Page} in Appendix \\" lab "Number\\ignore"
          sub(/\\appxref/,str)
        }
}
/^\\menuspadref/ || /^\\titledspadref/       {
        # we want to skip the first argument and get label
        n = length($0)
        while (substr($0,n,1) != "}")
          --n
        lastpos = --n
        while (substr($0,n,1) != "{")
          --n
        firstpos = ++n
        lab = substr($0,firstpos,lastpos-firstpos+1)
        lab = unnumber(lab)
        if (substr($1,2,1) == "m")
          printf "\\menudownlink{``\\" lab "Title''}{" lab "Page} in section \\" lab "Number\n"
        else
          printf "\\downlink{``\\" lab "Title''}{" lab "Page} in section \\" lab "Number\n"
        next
}

/^\\begin{center}/      {
        inCenter = 1
        next
}

/^\\end{center}/      {
        inCenter = 0
        next
}

(inCenter == 1)         {
        sub("\\\\\\\\$","") # seems like 4 should suffice here
#       sub("/\\\\/","")
        printf "\\centerline{{%s}}\n",$0
        next
}

/^\\head{chapter}/      {
        inChap = 1
        inSubSect = 0
        subSecNum = 0
        startPage(16)
        next
}
/^\\headTODO{chapter}/      {
        inChap = 1
        inSubSect = 0
        subSecNum = 0
        startPage(20)
        next
}

/^\\head{section}/      {
        handleSection(16)
        next
}
/^\\headTODO{section}/      {
        handleSection(20)
        next
}

/^\\head{subsection}/      {
        handleSubSection(19)
        next
}
/^\\headTODO{subsection}/      {
        handleSubSection(23)
        next
}

/^\\begin{description}/   {
        startList(0)
        next
}
/^\\end{description}/   {
        stopList(0)
        next
}

/^\\begin{enumerate}/   {
        inEnum = 1
        startList(4)
        next
}
/^\\end{enumerate}/   {
        inEnum = 0
        stopList(4)
        next
}

/^\\begin{itemize}/   {
        inItem = 1
        startList(4)
        next
}
/^\\end{itemize}/     {
        inItem = 0
        stopList(4)
        next
}

($1 == "\\item")      {
        if (inItem)             {
                printf "\\item[-] "
                for (i = 2; i < NF; i++)
                        printf "%s ",$i
                printf "%s\n",$i
        }
        else if (inEnum)        {
                printf "\\item[%d. ] ",inEnum
                for (i = 2; i < NF; i++)
                        printf "%s ",$i
                printf "%s\n",$i
                inEnum = inEnum + 1
        }
        else
                print
        next
}

# otherwise
                {
        print $0
        next
}

END             {
        if (inChap) {
          printSectionMenu()
          endPage()
        }
        if (inSect || inSubSect)
          endPage()
        else if (example)
          endPage()
}

function startList(i) {
        indent = indent + i
        printf "\\indent{%d}\n",indent
        print "\\beginitems"
}

function stopList(i) {
        print "\\enditems"
        indent = indent - i
        printf "\\indent{%d}\n",indent
}

function extractTitleAndLabel(type,line,  et,pagePrefix) {
        # return title in slot 1, label in slot 2
        et = index(line,"}{")
        if (et == 0) {
          printf "%! ERROR: badly formed \\head form.\n"
          return "\\begin{page}{ERRORPage}{ERROR}\n"
        }
        else {
          if (chapNum > 15) {
                chap = substr("ABCDEFGHIJKLMNOPQRSTUVWXYZ",chapNum-14,1)
          }
          else
                chap = chapNum
          if (type == 1) # chapter
                num = chap"."
          else if (type == 2) # section
                num = chap"."secNum"."
          else if (type == 3) # section
                num = chap"."secNum"."subSecNum"."
          conName = substr(line,1,et-1)
          pagePrefix = substr(line,et+2,length(line)-et-2)
          pagePrefix = unnumber(pagePrefix)
          addStdDefs(pagePrefix,conName,num)
          return "\\begin{page}{" pagePrefix "Page}{" num " " conName "}\n"
        }
}

function startPage(preflen) {
        printf "%\n"
        if (match(substr($0,1,preflen),/chapter/))
                type = 1
        else if (match(substr($0,1,preflen),/subsection/))
                type = 3
        else
                type = 2
        printf extractTitleAndLabel(type,substr($0,preflen)) # skip prefix
        print comsep
        print "\\beginscroll"
}

function endPage() {
        printf "\\endscroll\n\\autobuttons\n\\end{page}\n%\n"
}

function printSectionMenu() {
        system("cat /tmp/"fn".menu")
}

function printSubSectionMenu() {
        system("cat /tmp/ug"chapNum"."secNum".menu")
}

function handleSection(prefLen) {
        if (inChap) {
          printSectionMenu()
          endPage()
          inChap = 0
        }
        else if (inSect || inSubSect)
          endPage()
        inSect = 1
        inSubSect = 0
        subSecNum = 0
        secNum++
        startPage(prefLen)
}

function handleSubSection(prefLen) {
        if (inSubSect)
          endPage()
        else if (inSect) {
          printSubSectionMenu()
          endPage()
          inSect = 0
        }
        inSubSect = 1
        subSecNum++
        startPage(prefLen)
}

function addStdDefs(pagePrefix,conName,num) {
        globalPagePrefix = pagePrefix
        globalTitle      = conName
        globalNumber     = num

        printf "\\newcommand{\\%sTitle}{%s}\n",pagePrefix,conName
        printf "\\newcommand{\\%sNumber}{%s}\n",pagePrefix,num
        print  "%"
        print comsep
}

function unnumber(s) {
        gsub(/1/,"One",s)
        gsub(/2/,"Two",s)
        gsub(/3/,"Three",s)
        gsub(/4/,"Four",s)
        gsub(/5/,"Five",s)
        gsub(/6/,"Six",s)
        gsub(/7/,"Seven",s)
        gsub(/8/,"Eight",s)
        gsub(/9/,"Nine",s)
        gsub(/0/,"Zero",s)
        return s
}

function endMacroIndex(line,parms,    pp,x,bc,cc) {
# assumes start of line is a macro call and returns position of final "}"
        x = 0
        pp = index(line,"{")
        if (pp != 0) {
          bc = 1
          for (x = pp+1; ; x++) {
            cc = substr(line,x,1)
            if (cc == "{")
              bc++
            else if (cc == "}") {
              bc--
              if (bc == 0) {
                parms--
                if (parms == 0)
                  break
              }
            }
          }
        }
        return x
}

function extractArg(line,num,   p,arg) {
# assumes line is a macro call and extracts the num-th arg
        arg = ""
        p = index(line,"{")
        if (p != 0) {
          line = substr(line,p)

          if (num > 1) {
            p = endMacroIndex(line,num-1)
            line = substr(line,p+1)
          }
          p = endMacroIndex(line,1)
          arg = substr(line,2,p-2)
        }
        return arg
}

\start
Date: Fri, 17 Nov 2006 17:09:07 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: SPAD and Aldor again

> | I think that will be an important discussion to be had as a project -
> | just how compatible with Aldor we want to stay.
> 
> Probably.  I would like to see a discussion about what is necessary to
> support computational mathematics in Axiom, rather than how closely SPAD
> should ressemble another language.

Well, as you know I would rather like to improve the Aldor compiler than 
the SPAD compiler, since that would probably safe some time. But since 
there are no signs that Aldor becomes free, I find Gaby's suggestion 
quite good. Let's discuss, what we want and then design a language that 
fits best. Looking at this Monoid/AbeleanMonoid discussion we had 
before, this language will probably be something else than Aldor and SPAD.

So let me start with a few thoughts.

That Monoid/AbeleanMonoid should be resolved. I want to be able to say 
that the positive integers are a Monoid wrt. + and wrt *.

I would very much like to be able to use any fancy character to denote 
the multiplication of a monoid (not just ASCII). Code should pretty much 
look like actual mathematics. Mathematica and Maple already have some 
kind of that, but it lives in the interpreter. In fact, that would mean 
reducing reduncancy from pamphlets. One would write a mathematical 
formula which would be typeset in the way we like it and at the same 
time be a program.

I would like to define new syntax and use that in a program (nearly) 
exactly as one would do it in a paper.
The literate idea should be pushed to an extreme.

Of course it should also mean to have a way to specify the behaviour of 
algorithms in a formal way so that programs can be checked 
automatically. Proof checkers should, of course, also be written in that 
language.

Yes that is a big dream, but we still have 27 years. ;-)

\start
Date: Fri, 17 Nov 2006 10:57:50 -0500
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: ht.awk

> I asked the same question some days ago (forget the typos)
> http://lists.gnu.org/archive/html/axiom-developer/2006-11/msg00436.html
> No other response so I'm assuming it is no longer available.

Sorry, I've been away on business and unable to reach the net.

There are still some files from the NAG release that are not
part of the axiom distribution. If anyone is interested I can
put the NAG released file tree under source code control.

\start
Date: Fri, 17 Nov 2006 11:01:29 -0500
From: Tim Daly
To: Bill Page
Subject: Re: ht.awk

> Tim, is there any legal reason why you did not include the htex
> directory in the open source version of Axiom?

Nope. The axiom conversion to open source took a couple years
and I never got around to handling the hypertex portions. Along
with several other tasks it is still on the todo list.

\start
Date: 17 Nov 2006 17:07:43 +0100
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: SPAD and Aldor again
Cc: Christian Aistleitner

Martin Rubey writes:

| Dear Christian, Gaby, Waldek,
| 
| Christian, I'm copying this to you since I think that you have a lot to say
| with respect to features and shortcomings of Aldor. I would like to ask you to
| join the discussion, time permitting.
| 
| Gabriel Dos Reis writes:
| 
| > I would like to see a discussion about what is necessary to support
| > computational mathematics in Axiom, rather than how closely SPAD should
| > ressemble another language.
| 
| I think that this is beyond a group of a dozen part-time developers, and in
| fact, I believe that this is very likely beyond the abilities of the average
| mathematician. As evidence I'd like to present the "languages" of maple and
| mupad, which I believe to be quite inferior (maple: obviously, mupad: very
| likely) to Aldor.

However, we must be envision beyond today horizon, and define
ideals and must try hard to approximate them.  If you think of Axiom as
just a mere compiler to write today codes, it will not excite, not evolve
and therefore will die.  We must not improve SPAD just for what we
want to write today.  We must improve it to handle construct beyond
what we're doing today.  

[...]

| I did quite a bit of work with Aldor now (within the species project together
| with Ralf), and I'm quite convinced of the features of this language. In
| particular, the semantics of Aldor feel very "sound" to me, i.e., Aldor usually
| does what I expect it to do and allows what I would expect it to allow.

except when it does not, then you get depressed :-)


I'm not saying we should not having anything that is in Aldor.  I'm
saying, we should define the goal beyond being a clone of Aldor.
Cloning Aldor is not that much interesting.  People who wants Aldor
know where to get it.  The features should be cloned only when they
support the goals very well and beyond.

[...]

| Gaby pointed out that "==" has different semantics in Aldor and Axiom, but I
| have the feeling that this difference is not so severe: in fact, I don't know

yes, those are "little details" that are easy to fix in principle, but
might consume lot of resource to get right. 

>From my perspective, I would like to support recursive types (get rid
of )abbrev), dependent types, algebraic types.  

| of a way to define a constant in SPAD, currently, other than to define a
| macro. As far as I know, in Axiom "==" can only be used to define functions
| and, in SPAD, types. (Aren't types just a special kind of functions?)

depending on the perspective, yes.

\start
Date: 17 Nov 2006 17:09:16 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: SPAD and Aldor again

Ralf Hemmecke writes:

| > I've looked into FOAM, yes.  But, from my perspective improved SPAD
| > should not be a clone of Aldor.
| 
| Do you also consider to forget about FOAM? I guess, it is not below
| SPAD anyway.

I don't propose to forget it.
But, it is not on _my_ list of things to focuse on.  Someone else has
to do it :-)

\start
Date: 17 Nov 2006 17:17:27 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: SPAD and Aldor again

Ralf Hemmecke writes:

> I would very much like to be able to use any fancy character to denote the
> multiplication of a monoid (not just ASCII).

I strongly disagree on this point. Any character OK, i.e., defining some
operation to be infix or postfix, but please stay with ASCII. You know, not all
keyboards provide all symbols, and it's a pain to look for a certain symbol
when you're on a conference in Prag or China. And no, I don't want to remember
character codes. And no, I don't want to have to use a GUI, since I often work
through a modem.


I agree with

> That Monoid/AbeleanMonoid should be resolved. I want to be able to say that
> the positive integers are a Monoid wrt. + and wrt *.

and

> Of course it should also mean to have a way to specify the behaviour of
> algorithms in a formal way so that programs can be checked
> automatically. Proof checkers should, of course, also be written in that
> language.

However, I'm afraid, I don't have 27 years left. And, top issue on my priority
list are dependent types. As everybody knows meanwhile. I want to get rid of
that stupid ANY workaround in the series domains.

\start
Date: 17 Nov 2006 17:19:13 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: ht.awk

Tim Daly writes:

| > I asked the same question some days ago (forget the typos)
| > http://lists.gnu.org/archive/html/axiom-developer/2006-11/msg00436.html
| > No other response so I'm assuming it is no longer available.
| 
| Sorry, I've been away on business and unable to reach the net.
| 
| There are still some files from the NAG release that are not
| part of the axiom distribution. If anyone is interested I can
| put the NAG released file tree under source code control.

I'm interested :-)

\start
Date: Fri, 17 Nov 2006 11:16:09 -0500
From: Tim Daly
To: Martin Rubey
Subject: re: SPAD and Aldor again

> I guess it's Peter. Laurentiu says he doesn't know about the axiom
> side, but I know he knows foam. Tim, do you know about that stuff?
> Gaby, Waldek, did you dig into this connection yet?

I'm afraid that I'm more inclined to deeply document the existing
compiler before trying to tackle the problem of language modification.
Experience shows me that all of my programming mistakes occur in places
where my understanding is weakest. So first I understand, then I change.

I was not part of the Aldor compiler effort as I strongly objected to coding
the new compiler in C rather than rewriting the existing compiler. My
contribution to the Aldor effort involved making Aldor work inside Axiom 
and writing a tutorial for the Aldor final product. Despite my objections
I did use the compiler to implement my PhD thesis work.

\start
Date: 17 Nov 2006 17:31:44 +0100
From: Martin Rubey
To: Tim Daly
Subject: re: SPAD and Aldor again

Dear Tim,

Tim Daly writes:

> I'm afraid that I'm more inclined to deeply document the existing compiler
> before trying to tackle the problem of language modification. [...]

> [...] My contribution to the Aldor effort involved making Aldor work inside
> Axiom [...]

In fact, I consider this good news: if your contribution was to make Aldor work
inside Axiom, maybe you can help make dependent types coming from code compiled
with Aldor work in Axiom? Peter has made some effort to make Aldor "extend"
work (it does not work yet, it seems), maybe you could shortcut.

Is the interface between Aldor and Axiom documented somewhere?

I would be very happy to pay the price :-)

\start
Date: Fri, 17 Nov 2006 17:39:32 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: SPAD and Aldor again

On 11/17/2006 05:17 PM, Martin Rubey wrote:
> Ralf Hemmecke writes:
> 
>> I would very much like to be able to use any fancy character to denote the
>> multiplication of a monoid (not just ASCII).
> 
> I strongly disagree on this point. Any character OK, i.e., defining some
> operation to be infix or postfix, but please stay with ASCII.

You won't believe once I told my students to send files in plain ASCII. 
They had no idea what that is. In 10 years we will be laughing about 
that 128 character restriction. Come on... *dream*!

> However, I'm afraid, I don't have 27 years left.

I don't know how much is left for me, but I still have some dreams... ;-)

\start
Date: Fri, 17 Nov 2006 17:48:29 +0100
From: Gregory Vanuxem
To: list
Subject: PATCH : retrieval of Stream from a KAF file

Hello,

Here is a small patch that fixes the incorrect retrieval of some Streams
from a KAF file. It replaces 'EQ' by 'EQUAL' for comparisons of strings.
There are some other unmodified uses of EQ in this file. They need
further investigations and in particular I need to look at what I
consider a big issue : equality with object of type 'Any' (I postponed
my work on Stream).

--- src/algebra/stream.spad.pamphlet.old	2006-11-17 16:59:13.000000000
+0100
+++ src/algebra/stream.spad.pamphlet	2006-11-17 17:24:39.000000000 +0100
@@ -647,8 +647,8 @@
 
     Rep := Record(firstElt: S, restOfStream: %)
 
-    explicitlyEmpty? x == EQ(frst x,NullStream)$Lisp
-    lazy? x            == EQ(frst x,NonNullStream)$Lisp
+    explicitlyEmpty? x == EQUAL(frst x,NullStream)$Lisp
+    lazy? x            == EQUAL(frst x,NonNullStream)$Lisp
 
 --% signatures of local functions
 
\start
Date: 17 Nov 2006 17:55:55 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: SPAD and Aldor again

Ralf Hemmecke writes:

> You won't believe once I told my students to send files in plain ASCII. 

I still do this. By the way, currently, I do not have umlauts when ssh'ing from
home to work. Our local support looked at it, but didn't find the reason. Very
likely, it is a problem between Mandrake and Kubuntu. Kubuntu -> Kubuntu works.

> They had no idea what that is. In 10 years we will be laughing about that 128
> character restriction. Come on... *dream*!

I have not yet seen an american keyboard that allows input of german umlauts
without hassle.
 
> > However, I'm afraid, I don't have 27 years left.
> 
> I don't know how much is left for me, but I still have some dreams... ;-)

I do have dreams: dependent types in Axiom, resolving the Monoid-AbelianMonoid
conflict, having a nice graph theory package, having good support for symmetric
functions... Just have a look at the WishList for some others.

Oh, I think we should drop Mupad-combinat from the wishlist. That's done. :-)

\start
Date: 17 Nov 2006 17:57:44 +0100
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: SPAD and Aldor again
Cc: Christian Aistleitner

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| 
| > | I did quite a bit of work with Aldor now (within the species project
| > | together with Ralf), and I'm quite convinced of the features of this
| > | language. In particular, the semantics of Aldor feel very "sound" to me,
| > | i.e., Aldor usually does what I expect it to do and allows what I would
| > | expect it to allow.
| > 
| > except when it does not, then you get depressed :-)
| 
| But so far not because of Aldor, only because of Axiom's inability to handle
| Aldor code.

well, I had impression following the discussion on aldor-l -- but that
is not important :-)

[...]

| > | Gaby pointed out that "==" has different semantics in Aldor and Axiom, but I
| > | have the feeling that this difference is not so severe: in fact, I don't know
| > 
| > yes, those are "little details" that are easy to fix in principle, but
| > might consume lot of resource to get right. 
| 
| Ahem, what I am saying is that if we want constants in future SPAD, we will use
| the symbol "==" to introduce them. There are no constants in SPAD currently. If
| we want to have types being first class, we will very likely need constants.

Yes, that is right.

| > From my perspective, I would like to support recursive types (get rid
| > of )abbrev), dependent types, algebraic types.  
| 
| What are "algebraic types"?

Ralf and you have been doing it in your project, I think.  Basically,
an algebraic type is any data type on can construct with sum and
products.  Examples,

    BinaryTree t = Nil | Node t (BinaryTree t) (BinaryTree t)


Data of algebraic type are constructed with the constructors, and they
are deconstructed through pattern matching. 

Boot has a very limited support for algebraic types, but from what I
understand so far it does not have pattern matching yet.

\start
Date: 17 Nov 2006 18:13:03 +0100
From: Martin Rubey
To: Gabriel Dos Reis
Subject: re: SPAD and Aldor again
Cc: Christian Aistleitner

Gabriel Dos Reis writes:

> | What are "algebraic types"?
> 
> Ralf and you have been doing it in your project, I think.  Basically,
> an algebraic type is any data type on can construct with sum and
> products.  Examples,
> 
>     BinaryTree t = Nil | Node t (BinaryTree t) (BinaryTree t)
> 
> 
> Data of algebraic type are constructed with the constructors, and they
> are deconstructed through pattern matching. 

Well, in fact I need more than that, namely mutually dependent recursively
defined types. I.e., I want to be able to say

A: SomeCat; B: SomeCat;
A == f(A,B) add;
B == g(A,B) add;

as currently possible in Aldor, or, even

l := [SomeDomain, SomeDomain];
l.1 := f(l) add;
l.2 := g(l) add;

(the latter is currently not allowed in Aldor, but it happens to work...)

But I guess, you know that.

\start
Date: 17 Nov 2006 17:22:13 +0100
From: Martin Rubey
To: Gabriel Dos Reis
Subject: re: SPAD and Aldor again
Cc: Christian Aistleitner

Gabriel Dos Reis writes:


> | I did quite a bit of work with Aldor now (within the species project
> | together with Ralf), and I'm quite convinced of the features of this
> | language. In particular, the semantics of Aldor feel very "sound" to me,
> | i.e., Aldor usually does what I expect it to do and allows what I would
> | expect it to allow.
> 
> except when it does not, then you get depressed :-)

But so far not because of Aldor, only because of Axiom's inability to handle
Aldor code.

> I'm not saying we should not having anything that is in Aldor.  I'm saying,
> we should define the goal beyond being a clone of Aldor.  Cloning Aldor is
> not that much interesting.  People who wants Aldor know where to get it.  The
> features should be cloned only when they support the goals very well and
> beyond.

That's true.

> | Gaby pointed out that "==" has different semantics in Aldor and Axiom, but I
> | have the feeling that this difference is not so severe: in fact, I don't know
> 
> yes, those are "little details" that are easy to fix in principle, but
> might consume lot of resource to get right. 

Ahem, what I am saying is that if we want constants in future SPAD, we will use
the symbol "==" to introduce them. There are no constants in SPAD currently. If
we want to have types being first class, we will very likely need constants.

> From my perspective, I would like to support recursive types (get rid
> of )abbrev), dependent types, algebraic types.  

What are "algebraic types"?

\start
Date: Fri, 17 Nov 2006 12:17:28 -0500
From: Bill Page
To: Martin Rubey, Ralf Hemmecke
Subject: Re: SPAD and Aldor again

On November 17, 2006 11:56 AM Martin Rubey wrote:

> ...
> Just have a look at the WishList for some others.
> 
> Oh, I think we should drop Mupad-combinat from the wishlist. 
> That's done. :-)
> 

I would love to see some documentation of this work. My
impression is that it was largely done in a "closed" non-
open source manner. Was there a reason for that? Is there a
license issue?

Are you planning to put anything on the Axiom Wiki about
the Axiom/Aldor-combinat work?

\start
Date: 17 Nov 2006 18:20:59 +0100
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: SPAD and Aldor again
Cc: Christian Aistleitner

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| > | What are "algebraic types"?
| > 
| > Ralf and you have been doing it in your project, I think.  Basically,
| > an algebraic type is any data type on can construct with sum and
| > products.  Examples,
| > 
| >     BinaryTree t = Nil | Node t (BinaryTree t) (BinaryTree t)
| > 
| > 
| > Data of algebraic type are constructed with the constructors, and they
| > are deconstructed through pattern matching. 
| 
| Well, in fact I need more than that, namely mutually dependent recursively
| defined types.

Recursive algebraic types is a redundancy :-)

   A = F(A,B)
   B = G(A,B)

goes without saying.

\start
Date: Fri, 17 Nov 2006 18:40:18 +0100
From: Ralf Hemmecke
To: Gregory Vanuxem
Subject: Re: map instead of map! in src/doc/book.pamphlet

On 11/16/2006 11:47 PM, Vanuxem Gr=E9gory wrote:
> Le jeudi 16 novembre 2006 =E0 23:04 +0100, Ralf Hemmecke a =E9crit :
>> On 11/16/2006 10:38 PM, Vanuxem Gr=E9gory wrote:
>>> Hello,
>>>
>>> A small typo in the Axiom book:
>>>
>>> --- /home/greg/TDevel/cvs/axiom/src/doc/book.pamphlet
>>> +++ src/doc/book.pamphlet
>>> @@ -48550,7 +48548,7 @@
>>>  \returnType{Type: TwoDimensionalArray Integer}
>>> 
>>>  To change the array destructively, use
>>> -\spadfunFrom{map}{TwoDimensionalArray} instead of
>>> +\spadfunFrom{map!}{TwoDimensionalArray} instead of
>>>  \spadfunFrom{map}{TwoDimensionalArray}.  If you need to make a copy =
of
>>>  any array, use \spadfunFrom{copy}{TwoDimensionalArray}.
>>>
>>>
>>> Beware I don't know what \spadfunFrom does.
>> I don't know either, but src/hyper/pages/util.ht says the stuff below.=
=2E.
>>
>> Obviously, there are a lot of commands that look pretty much like LaTe=
X.
>> But I guess, hypertex code is not really processed by THE TeX so what =

>> language is that actually? And any chance that there is a bit more
>> documentation than that given in util.ht?
>
> It seems that you didn't see that book.pamphlet is a LaTeX book (THE
> Axiom book :-) (\spadfunFrom is a LaTeX macro here). I use \spadfunFrom=

> for Hyperdoc and I like it though it processes incorrectly function
> ending with a number (no link are generated).

Ooops. I am really blind... :-( Thanks for telling me the obvious.

 >>> Beware I don't know what \spadfunFrom does.

OK, then let's look at it.

% spadfunFrom records the function name and domain in the index
\newcommand{\spadfunFrom}[2]{{\bf #1}\index{#1 @\begingroup \string\it{} =

#1 \endgroup}\index{#2}}

 From that one sees the intension. You write something like

\spadfunFrom{name}{Type}

prints "name" in the text and also puts two entries into the index.
Namely "name" and "Type".

Now when I saw that you replaced "map" by "map!" I thought that must be
wrong... But no, there are already other things in book.pamphlet that
look like \spadfunFrom{concat!}{List}$(u,v)$. Oh, but then clearly the
definition of \spadfunFrom is wrong. It does not consider the case that
the exclamation mark is a special character for makeindex.
Unfortunately, LaTeX, makeindex, bibtex are not totally compatible. The
exclamation mark is used by makeindex to introduce subindices. So it
must be escaped by " if it is part of the actual text.

Given that error, you will realize that the index in the Axiom-Book (at
least in bookvol1.dvi) is wrong (or if you don't consider it wrong, it
is at least ugly).

In order to show that at a small example and also to give a remedy for
it I have created the file below where I check for ! (but only at the
end of the word) and replace it by "!. In particular look what I did
with the second \index entry and how that appears in the index.

Replace \iffalse by \iftrue and investigate the differences in the .dvi
file.

Have fun!

Ralf

%%%BEGIN spadfunFrom.tex
\documentclass{article}
\usepackage{makeidx}
\makeindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Replace \iffalse by \iftrue and call ...
% latex spadfunFrom.tex
% makeindex spadfunFrom
% latex spadfunFrom.tex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\iftrue
\iffalse
\usepackage{hyperref}
\usepackage{color}

\makeatletter
\def\rhx@parse@name#1{\expandafter\rhx@@parse@name#1!\\}
\def\rhx@@parse@name#1!#2\\{%
   \ifx\\#2\\%
     \edef\rhx@@indexlabel{#1}%
     \edef\rhx@@indextext{#1}%
   \else
     \edef\rhx@@indexlabel{#1"!}%
     \edef\rhx@@indextext{#1"!}%
   \fi
}
\newcommand{\spadfunFrom}[2]{%
   \rhx@parse@name{#1}%
   \spadfunTextStyle{#1}%
   \index{\rhx@@indexlabel
     @\protect\spadfunIndexStyle{\rhx@@indextext}%
     !\protect\spadTypeIndexStyle{#2}}%
   \index{#2%
     @\protect\spadTypeIndexStyle{#2}%
     !\protect\spadfunIndexStyle{\rhx@@indextext}}%
}

\def\spadfunTextStyle#1{\textcolor{blue}{\textbf{#1}}}
\def\spadfunIndexStyle#1{\textcolor{red}{#1}}
\def\spadTypeIndexStyle#1{\textcolor{blue}{\textsf{#1}}}
\makeatother

\else %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% spadfunFrom records the function name and domain in the index
\newcommand{\spadfunFrom}[2]{{\bf #1}\index{#1 @\begingroup \string\it{} =

#1 \endgroup}\index{#2}}

\fi
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\begin{document}

While these operations are common, others such as
\spadfunFrom{odd?}{Integer} and \spadfunFrom{bit?}{Integer} are not.
In addition the Exports section can contain symbols that represent
properties that can be tested. For example, the Category

The operation \spadfunFrom{concat!}{List}$(u,v)$ replaces the
last link of the list $u$ to point to some other list $v$.
Since $u$ refers to the original list, this change is seen by $u$.


To change the array destructively, use
\spadfunFrom{map}{TwoDimensionalArray} instead of
\spadfunFrom{map!}{TwoDimensionalArray}.  If you need to make a copy of
any array, use \spadfunFrom{copy}{TwoDimensionalArray}.
\newpage

To change the array destructively, use
\spadfunFrom{map}{TwoDimensionalArray} instead of
\spadfunFrom{map!}{TwoDimensionalArray}.  If you need to make a copy of
any array, use \spadfunFrom{copy}{TwoDimensionalArray}.

To change the array destructively, use
\spadfunFrom{map}{OneoDimensionalArray} instead of
\spadfunFrom{map!}{OneDimensionalArray}.  If you need to make a copy of
any array, use \spadfunFrom{copy}{TwoDimensionalArray}.

\printindex

\end{document}
%%%END spadfunFrum.tex

\start
Date: Fri, 17 Nov 2006 19:03:16 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: re: SPAD and Aldor again

On 11/17/2006 06:17 PM, Bill Page wrote:
> On November 17, 2006 11:56 AM Martin Rubey wrote:
>> Just have a look at the WishList for some others.
>>
>> Oh, I think we should drop Mupad-combinat from the wishlist. 
>> That's done. :-)

> I would love to see some documentation of this work. My
> impression is that it was largely done in a "closed" non-
> open source manner. Was there a reason for that? Is there a
> license issue?

Are we "closed"? I think I miss something. It is true that we have not 
yet released a tarball but the repository is readable by anyone.

svn://svn.risc.uni-linz.ac.at/hemmecke/combinat

If you cannot read it, tell me and I'll fix it.

Of course, it's a license issue... Is GPL open enough?

> Are you planning to put anything on the Axiom Wiki about
> the Axiom/Aldor-combinat work?

Of course. I actually wanted to show the generated html, but did not 
consider that so important, since it is generatable from the sources by 
a simple "make html". Once, we have setup a website, we'll let the world 
know.

\start
Date: Fri, 17 Nov 2006 19:02:41 +0100
From: Gregory Vanuxem
To: Martin Rubey
Subject: re: SPAD and Aldor again

Le vendredi 17 novembre 2006 =E0 17:17 +0100, Martin Rubey a =E9crit :

[...]

> I want to get rid of
> that stupid ANY workaround in the series domains.

Get rid of ANY almost everywhere.

\start
Date: Fri, 17 Nov 2006 13:13:10 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: Re: SPAD and Aldor again

On November 17, 2006 1:03 PM Ralf Hemmecke wrote:
> 
> On 11/17/2006 06:17 PM, Bill Page wrote:
> ... 
> > I would love to see some documentation of this work. My
> > impression is that it was largely done in a "closed" non-
> > open source manner. Was there a reason for that? Is there a
> > license issue?
> 
> Are we "closed"? I think I miss something.

I said it is "my impression". By that I mean that the project
appears or looks like it is closed to me. Of course I know
about it from cross-postings to other lists like the aldor
list and the Axiom developer list, but I have never seen any
annoucement about it or any advertisement about it or any
design ideas or other information on the wiki. So to me, yes
it "seems" closed.

> It is true that we have not yet released a tarball but the
> repository is readable by anyone.
> 
> svn://svn.risc.uni-linz.ac.at/hemmecke/combinat
> 
> If you cannot read it, tell me and I'll fix it.
> 

Yes I expect that I can, however I am not strongly motivated
to try because I do not know very much about it.

> Of course, it's a license issue... Is GPL open enough?
>

;) No, I meant something like the mupad problems...
 
> > Are you planning to put anything on the Axiom Wiki about
> > the Axiom/Aldor-combinat work?
> 
> Of course. I actually wanted to show the generated html, but
> did not  consider that so important, since it is generatable
> from the sources by a simple "make html". Once, we have setup
> a website, we'll let the world know.

Most open source projects "let the world know" first so that
they can attract interest in the work and maybe more volunteers.

Why not put the output of "make hmtl" on the web now? I think
it is very important.

\start
Date: Fri, 17 Nov 2006 13:15:04 -0500
From: Bill Page
To: Gregory Vanuxem, Martin Rubey
Subject: re: SPAD and Aldor again

On November 17, 2006 1:03 PM Vanuxem Gregory
>
> Le vendredi 17 novembre 2006 =E0 17:17 +0100, Martin Rubey a =E9crit :
>
> [...]
>
> > I want to get rid of
> > that stupid ANY workaround in the series domains.
>
> Get rid of ANY almost everywhere.
>

Why get rid of ANY? What is wrong with this idea? A very similar
idea is used in Java that is often called "type ducking". This
is a way to have dynamic types in an otherwise statically typed
language. What is wrong with that?

\start
Date: 17 Nov 2006 19:26:52 +0100
From: Martin Rubey
To: Gabriel Dos Reis
Subject: re: SPAD and Aldor again
Cc: Christian Aistleitner

Gabriel Dos Reis writes:

> Martin Rubey writes:
> 
> | Gabriel Dos Reis writes:
> | 
> | > | What are "algebraic types"?
> | > 
> | > Ralf and you have been doing it in your project, I think.  Basically,
> | > an algebraic type is any data type on can construct with sum and
> | > products.  Examples,
> | > 
> | >     BinaryTree t = Nil | Node t (BinaryTree t) (BinaryTree t)
> | > 
> | > 
> | > Data of algebraic type are constructed with the constructors, and they
> | > are deconstructed through pattern matching. 
> | 
> | Well, in fact I need more than that, namely mutually dependent recursively
> | defined types.
> 
> Recursive algebraic types is a redundancy :-)

But I didn't say "algebraic"! I want it for any functions F, G:
> 
>    A = F(A,B)
>    B = G(A,B)
> 
> goes without saying.

So, in what sense is "algebraic" not covered by the above?

\start
Date: 17 Nov 2006 19:40:16 +0100
From: Martin Rubey
To: Bill Page
Subject: re: SPAD and Aldor again

Bill Page writes:

> On November 17, 2006 1:03 PM Vanuxem Gregory
> >
> > Le vendredi 17 novembre 2006 =C3=A0 17:17 +0100, Martin Rubey a =C3=A9c=
rit :
> >
> > [...]
> >
> > > I want to get rid of
> > > that stupid ANY workaround in the series domains.
> >
> > Get rid of ANY almost everywhere.
> >
>
> Why get rid of ANY? What is wrong with this idea? A very similar
> idea is used in Java that is often called "type ducking". This
> is a way to have dynamic types in an otherwise statically typed
> language. What is wrong with that?

There is nothing wrong with that in certain circumstances or as a temporary
workaround. But it is completely wrong if you can do better without. The on=
ly
reason why series needs ANY is that the type, for example,

UPXS(INT, x, 0)

has a parameter "expansion point", (in the example equal to zero), which is
given as argument to "series":

series(sin x, x=1783) returns an element of domain ANY, although it really
should be an element of UPXS(FRAC INT, x, 1783). There is some code hidden =
in
the interpreter that makes the user believe that it is an element of
UPXS(FRAC INT, x, 1783), but if you want to use series in SPAD code, you ar=
e in
trouble.

The signature of series currently is

   [4] (D2,Equation D2) -> Any from ExpressionToUnivariatePowerSeries(
            D4,D2)
            if D2 has Join(AlgebraicallyClosedField,
            TranscendentalFunctionCategory,FunctionSpace D4) and D4 has
            Join(GcdDomain,OrderedSet,RetractableTo Integer,
            LinearlyExplicitRingOver Integer)

but it "should" be something like

   [4] (D2,eq: Equation D2) -> UPXS(D2, retract(lhs eq)@Symbol, rhs eq)
            from ExpressionToUnivariatePowerSeries(D4,D2)
            if D2 has Join(AlgebraicallyClosedField,
            TranscendentalFunctionCategory,FunctionSpace D4) and D4 has
            Join(GcdDomain,OrderedSet,RetractableTo Integer,
            LinearlyExplicitRingOver Integer)


Then you could use it also in SPAD.

No problem at all for Aldor.

\start
Date: Fri, 17 Nov 2006 13:34:37 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: ht.awk

> | > I asked the same question some days ago (forget the typos)
> | > http://lists.gnu.org/archive/html/axiom-developer/2006-11/msg00436.html
> | > No other response so I'm assuming it is no longer available.
> | 
> | Sorry, I've been away on business and unable to reach the net.
> | 
> | There are still some files from the NAG release that are not
> | part of the axiom distribution. If anyone is interested I can
> | put the NAG released file tree under source code control.
> 
> I'm interested :-)

Likely you'll want it to live in SVN and since I can't do SVN 
I put the tarball up on axiom-developer.org for a short while.

Please let me know if you're interested in placing it in SVN and, if
you do, please let me know when you've downloaded the tarball
so I can remove it.

http://daly.axiom-developer.org/Axiom.NAG.tgz

\start
Date: Fri, 17 Nov 2006 19:16:44 +0000
From: Peter Broadbery
To: Martin Rubey
Subject: re: SPAD and Aldor again

On Fri, 2006-11-17 at 11:36 +0100, Martin Rubey wrote:
> Peter Broadbery writes:
> 
> > On Fri, 2006-11-17 at 08:43 +0100, Martin Rubey wrote:
> 
> > > And, as you know, in my opinion the first step in making this happen is to
> > > make the Axiom interpreter (!) understand Aldor generated code, i.e.,
> > > dependent types.
> > 
> > This is currently stymied by the aldor compiler not being able to generate
> > .asy files where there are dependent types in signatures
> > (try 'foo: (R: Ring, t: R)').  The .asy generation code enters a loop, which
> > is a bit poor.
> 
> Does this mean that one would need to modify the Aldor compiler? I.e., we would
> need access to the sources?

Yup.  Reverse engineering the .ao is possible, but not a serious
proposition.

\start
Date: 17 Nov 2006 21:02:40 +0100
From: Martin Rubey
To: Peter Broadbery
Subject: re: SPAD and Aldor again

Peter Broadbery writes:

> On Fri, 2006-11-17 at 11:36 +0100, Martin Rubey wrote:
> > Peter Broadbery writes:

> > > On Fri, 2006-11-17 at 08:43 +0100, Martin Rubey wrote:

> > > > And, as you know, in my opinion the first step in making this
> > > > happen is to make the Axiom interpreter (!) understand Aldor
> > > > generated code, i.e., dependent types.

> > > This is currently stymied by the aldor compiler not being able
> > > to generate .asy files where there are dependent types in
> > > signatures (try 'foo: (R: Ring, t: R)').  The .asy generation
> > > code enters a loop, which is a bit poor.

> > Does this mean that one would need to modify the Aldor compiler?
> > I.e., we would need access to the sources?

> Yup.  Reverse engineering the .ao is possible, but not a serious
> proposition.

> Peter

Oops. That's the worst news I heard for a long time. It's time to send email to
Stephen Watt again.

\start
Date: Fri, 17 Nov 2006 21:19:09 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: ht.awk

root wrote:
> 
> http://daly.axiom-developer.org/Axiom.NAG.tgz
> 

I have fetched the file. Thanks.

\start
Date: Fri, 17 Nov 2006 21:46:37 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: re: SPAD and Aldor again

Le vendredi 17 novembre 2006 =E0 13:15 -0500, Bill Page a =E9crit :
> On November 17, 2006 1:03 PM Vanuxem Gregory
> >
> > Le vendredi 17 novembre 2006 =E0 17:17 +0100, Martin Rubey a =E9crit =
:
> >
> > [...]
> >
> > > I want to get rid of
> > > that stupid ANY workaround in the series domains.
> >
> > Get rid of ANY almost everywhere.
> >
>
> Why get rid of ANY? What is wrong with this idea? A very similar
> idea is used in Java that is often called "type ducking". This
> is a way to have dynamic types in an otherwise statically typed
> language. What is wrong with that?

It's difficult and practically impossible to use it in Spad. In the
interpreter there is no problem, it coerces it for you (not sure
though). For example imagine that you want to emulate dependent type in
Spad:

==========================
==========================
===============
)abbrev package TEST Test
++ test package
Test(): Exports == Implementation where
  I   ==> integer
  Exports ==> with
    test: (n:Integer,p:Integer) -> Any
    ++ just a test
    withtest: (a:Integer,p:Integer) -> Any
    ++ just anaother test
  Implementation ==> add
    test(n,p) ==
      z := coerce(n::PrimeField(p))$AnyFunctions1(PrimeField(p))
      z
    withtest(a,p) ==
      --b := retract(test(a,p))-- + 9::PrimeField(p)
      t := test(a,p)
      b := retract(t)$AnyFunctions1(PrimeField(p))
      b := b + 8::PrimeField(p)
      coerce(b)$AnyFunctions1(PrimeField(p))
      --coerce(b)$AnyFunction1(PrimeField(p))
==========================
==========================
===============

Here, in function test, you create a type that depends on one of the
parameter passed to this function. In the second function (withtest) you
don't/can't know what is its real type. You first have to coerce it, but
Spad will not allow you to coerce it (via retract@AnyFunctions1) if its
type is not known at compile time. Here it's possible only because the
prime number is known at compile time (p, a function parameter (again)).

Another example:

(4) -> ((1/4)=(1/4)::ANY)@Boolean

   (4)  false

\start
Date: Fri, 17 Nov 2006 21:50:03 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: PATCH : retrieval of Stream from a KAF file

> Hello,
> 
> Here is a small patch that fixes the incorrect retrieval of some Streams
> from a KAF file. It replaces 'EQ' by 'EQUAL' for comparisons of strings.
> There are some other unmodified uses of EQ in this file. They need
> further investigations and in particular I need to look at what I
> consider a big issue : equality with object of type 'Any' (I postponed
> my work on Stream).
> 
> --- src/algebra/stream.spad.pamphlet.old	2006-11-17 16:59:13.000000000
> +0100
> +++ src/algebra/stream.spad.pamphlet	2006-11-17 17:24:39.000000000 +0100
> @@ -647,8 +647,8 @@
>  
>      Rep := Record(firstElt: S, restOfStream: %)
>  
> -    explicitlyEmpty? x == EQ(frst x,NullStream)$Lisp
> -    lazy? x            == EQ(frst x,NonNullStream)$Lisp
> +    explicitlyEmpty? x == EQUAL(frst x,NullStream)$Lisp
> +    lazy? x            == EQUAL(frst x,NonNullStream)$Lisp
>  
>  --% signatures of local functions
>  
> 

That looks strange for me. NullStream and NonNullStream should be
unique objects, so I would probably turn them into symbols.  Your
change would make a one element list:

 ["NonNullStream"]

into invalid stream (I think such list is a valid stream od strings).

\start
Date: 17 Nov 2006 21:56:04 +0100
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: SPAD and Aldor again
Cc: Christian Aistleitner

Martin Rubey writes:

[...]

| > Recursive algebraic types is a redundancy :-)
| 
| But I didn't say "algebraic"! I want it for any functions F, G:

The point I'm trying to make -- I suspect it must be too indirect --
is that if we have algebraic types, recursive types (whether algebraic
or not) comes with the framework.

\start
Date: 17 Nov 2006 21:59:56 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: ht.awk

Tim Daly writes:

| > | > I asked the same question some days ago (forget the typos)
| > | > http://lists.gnu.org/archive/html/axiom-developer/2006-11/msg00436.html
| > | > No other response so I'm assuming it is no longer available.
| > | 
| > | Sorry, I've been away on business and unable to reach the net.
| > | 
| > | There are still some files from the NAG release that are not
| > | part of the axiom distribution. If anyone is interested I can
| > | put the NAG released file tree under source code control.
| > 
| > I'm interested :-)
| 
| Likely you'll want it to live in SVN and since I can't do SVN 
| I put the tarball up on axiom-developer.org for a short while.
| 
| Please let me know if you're interested in placing it in SVN and, if
| you do, please let me know when you've downloaded the tarball
| so I can remove it.
| 
| http://daly.axiom-developer.org/Axiom.NAG.tgz

I'm done with downloading it.  Thanks! 

Just to make sure. Yes, I would like to have it undr SVN.  I have a
question: Do I legally have the right to do that?

\start
Date: Fri, 17 Nov 2006 22:11:41 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: re: SPAD and Aldor again

I forgot,

Le vendredi 17 novembre 2006 =E0 21:46 +0100, Vanuxem Gregory a =E9crit :

[...]

> (4) -> ((1/4)=(1/4)::ANY)@Boolean
>
>    (4)  false

But

 (8) -> (3=(3::ANY))@Boolean

   (8)  true

\start
Date: Fri, 17 Nov 2006 22:29:24 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: PATCH : retrieval of Stream from a KAF file

Le vendredi 17 novembre 2006 =E0 21:50 +0100, Waldek Hebisch a =E9crit :
> > Hello,
> >
> > Here is a small patch that fixes the incorrect retrieval of some Stre=
ams
> > from a KAF file. It replaces 'EQ' by 'EQUAL' for comparisons of strin=
gs.
> > There are some other unmodified uses of EQ in this file. They need
> > further investigations and in particular I need to look at what I
> > consider a big issue : equality with object of type 'Any' (I postpone=
d
> > my work on Stream).
> >
> > --- src/algebra/stream.spad.pamphlet.old	2006-11-17 16:59:13.00000000=
0
> > +0100
> > +++ src/algebra/stream.spad.pamphlet	2006-11-17 17:24:39.000000000 +0=
100
> > @@ -647,8 +647,8 @@
> > 
> >      Rep := Record(firstElt: S, restOfStream: %)
> > 
> > -    explicitlyEmpty? x == EQ(frst x,NullStream)$Lisp
> > -    lazy? x            == EQ(frst x,NonNullStream)$Lisp
> > +    explicitlyEmpty? x == EQUAL(frst x,NullStream)$Lisp
> > +    lazy? x            == EQUAL(frst x,NonNullStream)$Lisp
> > 
> >  --% signatures of local functions
> > 
> >
>
> That looks strange for me. NullStream and NonNullStream should be
> unique objects, so I would probably turn them into symbols.  Your
> change would make a one element list:

This is because NullStream and NonNullStream are globales variables
(NullStream is a macro (NullStream ==> $NullStream$Lisp)) but when yo=
u
store a Stream and retrieve it a new string is created and therefore
these strings do not share their memory locations. I do not understand
why you say "Your change would make a one element list", they are just
strings.

If you want )trace STREAM and restore a '[]::Stream(PI)', you'll see:

  1<enter Stream.explicitlyEmpty?,12 : ("NullStream")
   1<enter Stream.frst,10 : ("NullStream")
   1>exit  Stream.frst,10 : "NullStream"
  1>exit  Stream.explicitlyEmpty?,12 : NIL

This is because they do not share the same memory location. The output
of Stream.explicitlyEmpty? has to be T.

\start
Date: Fri, 17 Nov 2006 22:32:36 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: PATCH : retrieval of Stream from a KAF file

Le vendredi 17 novembre 2006 =E0 22:29 +0100, Vanuxem Gregory a =E9crit :
> Le vendredi 17 novembre 2006 =E0 21:50 +0100, Waldek Hebisch a =E9crit =
:
> > > Hello,
> > >
> > > Here is a small patch that fixes the incorrect retrieval of some St=
reams
> > > from a KAF file. It replaces 'EQ' by 'EQUAL' for comparisons of str=
ings.
> > > There are some other unmodified uses of EQ in this file. They need
> > > further investigations and in particular I need to look at what I
> > > consider a big issue : equality with object of type 'Any' (I postpo=
ned
> > > my work on Stream).
> > >
> > > --- src/algebra/stream.spad.pamphlet.old	2006-11-17 16:59:13.000000=
000
> > > +0100
> > > +++ src/algebra/stream.spad.pamphlet	2006-11-17 17:24:39.000000000 =
+0100
> > > @@ -647,8 +647,8 @@
> > > 
> > >      Rep := Record(firstElt: S, restOfStream: %)
> > > 
> > > -    explicitlyEmpty? x == EQ(frst x,NullStream)$Lisp
> > > -    lazy? x            == EQ(frst x,NonNullStream)$Lisp
> > > +    explicitlyEmpty? x == EQUAL(frst x,NullStream)$Lisp
> > > +    lazy? x            == EQUAL(frst x,NonNullStream)$Lisp
> > > 
> > >  --% signatures of local functions
> > > 
> > >
> >
> > That looks strange for me. NullStream and NonNullStream should be
> > unique objects, so I would probably turn them into symbols.  Your
> > change would make a one element list:
>
> This is because NullStream and NonNullStream are globales variables
> (NullStream is a macro (NullStream ==> $NullStream$Lisp)) but when =
you
> store a Stream and retrieve it a new string is created and therefore
> these strings do not share their memory locations. I do not understand
> why you say "Your change would make a one element list", they are just
> strings.

I forgot (not the first time) that equal return t or nil so there is no
'["NonNullStream"]'.

Sorry,

\start
Date: Fri, 17 Nov 2006 19:49:43 -0500
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: re: SPAD and Aldor again

Gabriel Dos Reis wrote:
> Cliff Yapp writes:
>
> | Indeed.  The Aldor documentation is not free at all, and any attempt to
> | define Aldor in a literate style would have to duplicate Aldor without
> | duplicating too closely its documentation - that's a real problem.
> 
> I cannot parse this. Could you elaborate?

Sorry, this seems to be an off week for me communication wise.  If we
define and document properly a language like Aldor, we must include
descriptions of the behavior of the language.  The problem with
specifying a language behavior is that the description cannot vary too
much from one description to another and still be defining the same
concepts.  The problem of (for example) writing a document that
describes ANSI lisp without running into any copyright problems is very
difficult, because if you stray too far from the text of the
specification you run the risk of not defining the behavior you need to
define.  And it would be even more difficult to avoid such a description
being a "derivative work" of the previous description.

In Aldor's case, a concrete example would be the language grammar, which
is included in the Aldor User Guide in Chapter 22.4.  If we wanted to
define a similar language I would think any reasonable literate
description of the language would include such a formal grammar
definition.  But Aldor's grammar is defined in this user guide, and at
the beginning of the guide is the statement:

"c 2000 The Numerical Algorithms Group Limited. c 2002 Aldor.org.
All rights reserved. No part of this Manual may be reproduced,
transcribed, stored in a retrieval system, translated into any language
or computer language or transmitted in any form or by any means,
electronic, mechanical, photocopying, recording or otherwise, without
the prior written permission of the copyright owner."

I don't know how exactly the law applies in this situation, but with the
Aldor grammar defined in a copyrighted document we have no permission to
use for anything, how do we handle defining a similar grammar?  Are
grammar definitions not protected?  I don't know how copyright laws
apply in these situations.

Perhaps this is a trivial/silly concern, or something that can be safely
ignored, but it is a concern I thought should be raised.

> 
> You don't need a language to do *just* mathematics in Axiom.  You also
> need a language to communicate with the world around.  All major
> systems for computation mathematics have grown into that position.
> Don't get blindsighted.

I would prefer to let the Lisp level handle the outside world as much as
possible.  What are you referring to by communication?  Exporting
algorithms as Fortran code?  Interacting with C libraries?  File and
Data Input/Output APIs?

> [...]
> 
> | I think that will be an important discussion to be had as a project -
> | just how compatible with Aldor we want to stay.
> 
> Probably.  I would like to see a discussion about what is necessary to
> support computational mathematics in Axiom, rather than how closely SPAD
> should ressemble another language.

Agreed.

\start
Date: Fri, 17 Nov 2006 19:45:24 -0500
From: Tim Daly
To: list
Subject: Axiom download

Gentlemen,

Having just returned from a business trip and being overtired
I made a mistake and copied the wrong directory for upload.
Please delete that copy and I'll upload a corrected version shortly.

\start
Date: 18 Nov 2006 01:59:43 +0100
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: SPAD and Aldor again

Cliff Yapp writes:

| Gabriel Dos Reis wrote:
| > Cliff Yapp writes:
| >
| > | Indeed.  The Aldor documentation is not free at all, and any attempt to
| > | define Aldor in a literate style would have to duplicate Aldor without
| > | duplicating too closely its documentation - that's a real problem.
| > 
| > I cannot parse this. Could you elaborate?
| 
| Sorry, this seems to be an off week for me communication wise.  If we
| define and document properly a language like Aldor, we must include
| descriptions of the behavior of the language.  The problem with
| specifying a language behavior is that the description cannot vary too
| much from one description to another and still be defining the same
| concepts.  The problem of (for example) writing a document that
| describes ANSI lisp without running into any copyright problems is very
| difficult, because if you stray too far from the text of the
| specification you run the risk of not defining the behavior you need to
| define.  And it would be even more difficult to avoid such a description
| being a "derivative work" of the previous description.

OK, thanks for the explanation.

Since I'm not in the business of cloning Aldor, I'm not sure how that
affects Axiom.
I don't see a point of cloning Aldor.  
I see great benefits in an improved SPAD.

[...]

| > You don't need a language to do *just* mathematics in Axiom.  You also
| > need a language to communicate with the world around.  All major
| > systems for computation mathematics have grown into that position.
| > Don't get blindsighted.
| 
| I would prefer to let the Lisp level handle the outside world as much as
| possible.

But you still need to specify what that does to a SPAD program.  Just
delegating to Lisp does not solve the fundamental problem.

|  What are you referring to by communication?  Exporting
| algorithms as Fortran code?  Interacting with C libraries?  File and
| Data Input/Output APIs?

All of that, including interfacing with nay reasonable language used
in the computational science community -- that list goes beyond
Fortran and C.

\start
Date: 18 Nov 2006 02:01:31 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom download

Tim Daly writes:

| Gentlemen,
| 
| Having just returned from a business trip and being overtired
| I made a mistake and copied the wrong directory for upload.
| Please delete that copy and I'll upload a corrected version shortly.

Done. :-)
And I can wait for tomorrow, when the jet-lag is over. :-)

\start
Date: 18 Nov 2006 02:26:26 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: branches/build-improvements/src

Waldek Hebisch writes:

| Revision: 266
|           http://svn.sourceforge.net/axiom/?rev=266&view=rev
| Author:   whebisch
| Date:     2006-11-15 12:29:45 -0800 (Wed, 15 Nov 2006)
| 
| Log Message:
| -----------
| Make preloading of databases effective
| 
| Modified Paths:
| --------------
|     branches/build-improvements/src/etc/ChangeLog.build-improvements
|     branches/build-improvements/src/etc/Makefile.in
|     branches/build-improvements/src/etc/Makefile.pamphlet
|     branches/build-improvements/src/interp/ChangeLog.build-improvements
|     branches/build-improvements/src/interp/Makefile.in
|     branches/build-improvements/src/interp/Makefile.pamphlet
|     branches/build-improvements/src/interp/daase.lisp.pamphlet

Waldek --

  This patch seems to have broken build-improvements: Many of the
components are no longer built, in particular the regression test is
not longer run.  I spent the whole day tracking down the breakage.
I'll revert this patch, so that you can fletch it out in greater
details, and the branch remains still operational.  

\start
Date: 18 Nov 2006 03:57:58 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: branches/build-improvements/src
Cc: Waldek Hebisch


Bill Page writes:

| On November 17, 2006 8:26 PM Gabriel Dos Reis
| > 
| > Waldek Hebisch writes:
| > 
| > | Revision: 266
| > |           http://svn.sourceforge.net/axiom/?rev=266&view=rev
| > | Author:   whebisch
| > | Date:     2006-11-15 12:29:45 -0800 (Wed, 15 Nov 2006)
| > | 
| > | Log Message:
| > | -----------
| > | Make preloading of databases effective
| > | 
| > ... 
| >   This patch seems to have broken build-improvements: Many of the
| > components are no longer built, in particular the regression test
| > is not longer run.
| 
| That's odd. I built Axiom on Nov 15 19:04 from the build-improvements
| repository (Revision: 274) on the axiom-developer.org server with no
| problems - at least none that I noticed. The build log shows that
| the regression tests were all run and Axiom seems to work fine in
| simple manual confidence tests.
| 
| What components in particular were not built?


graph, sman, hyper and input.

| What error message should I look for in the log?

There is no dirct error message on console.  However, when I looked at
build/$target/trace, there are many instances of hyperdoc complaining
it does not understand \spad.

I'm running a binary search on another machine, and I'll revert only
when it is cross-checked.

| What machine were you using for the test?

I did the binary search on my laptop, i686-pc-linux-gnu.
I'm cross checking on a x86-suse-linux.

| The only thing I did a little differently from the standard build
| was that I pre-built gcl from the zips because on axiom-developer
| I need to set maxpages < 256*1024. This time I built it with
| 200*1024.

That should not matter.

| > I spent the whole day tracking down the breakage. I'll revert this
| > patch, so that you can fletch it out in greater details, and the
| > branch remains still operational.  
| > 
| 
| What do you think is going wrong?

I don't know yet -- if I knew I would just fix it :-)

\start
Date: 18 Nov 2006 04:42:18 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: [Axiom-commit] Re: SF.net SVN: axiom:
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

| Bill Page writes:
| 
| | On November 17, 2006 8:26 PM Gabriel Dos Reis
| | > 
| | > Waldek Hebisch writes:
| | > 
| | > | Revision: 266
| | > |           http://svn.sourceforge.net/axiom/?rev=266&view=rev
| | > | Author:   whebisch
| | > | Date:     2006-11-15 12:29:45 -0800 (Wed, 15 Nov 2006)
| | > | 
| | > | Log Message:
| | > | -----------
| | > | Make preloading of databases effective
| | > | 
| | > ... 
| | >   This patch seems to have broken build-improvements: Many of the
| | > components are no longer built, in particular the regression test
| | > is not longer run.
| | 
| | That's odd. I built Axiom on Nov 15 19:04 from the build-improvements
| | repository (Revision: 274) on the axiom-developer.org server with no
| | problems - at least none that I noticed. The build log shows that
| | the regression tests were all run and Axiom seems to work fine in
| | simple manual confidence tests.
| | 
| | What components in particular were not built?
| 
| 
| graph, sman, hyper and input.

False alarm -- they are built "early".  

However.

I think I have a better understanding than I had three hours ago.
The last test I did was with revision 283.

In that revision, the whole AXIOMsys seems to be built twice:

  (1) once as usual
      - then the testsuite is run
  (2) and a second time
      - this time it is not tested any more.
      - this time, the other component are not built

I think it is wrong not to test the second time AXIOMsys is built (it
is the one that is installed).   We would need an explanation of why
AXIOMsys needs to be built twice -- the first time it is tested, and the
second time it is not.  

The dependencies are wrong somewhere but I don't know yet where.
Furthermore, I come realize that the rule

          (cd ../interp && $(ENV) $(MAKE) axiomsys)

is no good.  Because by the time the build flow reaches src/etc/ we may
already have done lot of things on the way (and we do).  Now, it looks
like src/etc wants to ask AXIOMsys to be rebuilt a second time,
without necessarily "making" other things that might depend on it.
That is no good.  We should not have the rule written that way.

I think we must take a step back and lay down what is that the patch
is trying to achieve.  And do that in a more controlled way.
Waldek?



The "generic" errors from hyperdoc are  of the form:

--->/home/gdr/build/axiom/target/x86_64-suse-linux/../../src/algebra/ES.spad-->E
xpressionSpace((odd? ((Boolean) %))): Unexpected HT command: \spad

These may actually be not related to the patch.  Sorry for that.

\start
Date: 18 Nov 2006 04:48:34 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: branches/build-improvements/src
Cc: Waldek Hebisch

Bill Page writes:

| On November 17, 2006 9:58 PM Gaby wrote:
| > ...
| > | 
| > | What components in particular were not built?
| > 
| > 
| > graph, sman, hyper and input.
| >
| 
| These all built for me with no visible problems.

Yes.  See the message I just sent.

| > | What error message should I look for in the log?
| > 
| > There is no dirct error message on console.  However, when I looked
| > at build/$target/trace, there are many instances of hyperdoc
| > complaining it does not understand \spad.
| >
| 
| I do not see any such messages from hyperdoc in my
| 
|   build/i686-pc-linux/trace

grep for "Unexpected HT command:"

[...]

| > | What machine were you using for the test?
| > 
| > I did the binary search on my laptop, i686-pc-linux-gnu.
| > I'm cross checking on a x86-suse-linux.
| >
| 
| axiom-developer is seen as i686-pc-linux. I would not expect
| results to differ significantly from yours.

Yes.  Now, I think I understand what is going go.  See the other
message.  AXIOMsys is built twice.  The first time it is tested, the
second time it is not -- and that is no good.

First, we should not build twice.  Second, if we must build twice,
then we must test the second version -- the one that is installed.

Finally, I think we must rewrite the patch to src/etc/ that introduces
this new behaviour.



Th reason why I thought the branch is broken is that I have a script
that "watches" the output of the build log and it got confused by
the new behaviour.  Then I spend the whole day on it :-/

\start
Date: 18 Nov 2006 08:33:40 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: branches/build-improvements/src
Cc: Waldek Hebisch

Bill Page writes:

[...]

| > First, we should not build twice.  Second, if we must build
| > twice, then we must test the second version -- the one that
| > is installed.
| 
| Building Axiom twice is normal practice in order to obtain
| optimized function calls in gcl.

Ahem, it is new -- not "normal" build process :-).  I believe the
build system on trunk does not build twice.

| I did not notice this change
| in Waldek's patch, but it is not unexpected to me. Perhaps
| Waldek does this also because in the etc/Makefile he has just
| re-built the databases. It is conceivable that new databases
| could affect the code that is generated by the algebra compiles.

then the algebra files should be rebuilt, no?

| In fact, compiling twice also turns out to be the minimum
| required due to some mutual dependencies that are not fully
| resolved by the current bootstrap procedure. (See previous
| discussion of the algebra fixed-point iteration tests that
| I did over a year ago.) But that is a different issue.

if you're referring to the $boosttrap hack, yes, I believe that is a
different issue.  It does not appear to me that this change is
actually planned and intended by the patch.

| > Finally, I think we must rewrite the patch to src/etc/ that
| > introduces this new behaviour.
| > 
| 
| I agree that it needs further explanation.

it needs more than explanation, because we don't know whether the
rebuild may affect the generation of the algebra files.

[...]

| On November 15, 2006 2:43 PM Waldek Hebisch wrote:
| > 
| > The following patch makes caching of databases effective and
| > reduces startup time of AXIOMsys.  Debian uses similar patch
| > and claims huge reduction of time needed to run tests, but
| > for me test time remained effectively unchanged.
| > 
| > diff -ru build-improvements.bb/src/etc/Makefile.in 
| > build-improvements/src/etc/Makefile.in
| > --- build-improvements.bb/src/etc/Makefile.in	2006-11-15 
| > 13:15:29.000000000 +0100
| > +++ build-improvements/src/etc/Makefile.in	2006-11-15 
| > 13:46:07.000000000 +0100
| > @@ -14,6 +14,7 @@
| >  		$(axiom_target_libdir)/summary \
| >  		$(axiom_target_libdir)/copyright \
| >  		$(axiom_target_bindir)/axiom
| > +	(cd ../interp && $(ENV) $(MAKE) axiomsys)
| >  	@echo 6 finished $(builddir)
| >  	-rm -f stamp
| >  	$(STAMP) stamp
| > ...
| 
| I recall now that Camm Maquire did include the "compile Axiom
| twice" optimization in the Debian build.

If we want to do that optimization, then we must build AXIOMsys only
twice, I think.  And we must do the same step twice.  Here, the patch
is doing something different the second time.

| Indeed the build log shows that AXIOMsys is built twice although
| the lisp source is not re-compiled which I believe is required
| for the function call optimization.

Yes.

| (Full SPAD re-compile is required for the fixed-point solution.) 

that is true, but it is a different issue from the optimization.
The full SPAD issue is there because because we have no way of
extending domains gradually.

| The regression tests were
| not re-executed. Perhaps there is a missing dependency in the test
| stanza. But you are right. It makes sense to run the tests only
| after the 2nd build.
| 
| If we really want to do this optimization, then I guess you are
| right that this patch needs to be re-evaluated.

I would suggest that we address the optimization latter -- put it on
the list of README.build-improvements so that we don't forget about it.

| In order to do
| the optimation, it is necessary to retain the *.NRLIB directories
| and in particular the *.fn files which contain the necessary
| "proclaim" information from the 1st build for use in the 2nd.
| But the current build procedure deletes the NRLIBs doesn't it?

yes, it deletes the existing NRLIBs.  
However, I'm not sure where whole SPAD needs to be recompiled, or only
AXIOMSsys.   I believe it is AXIOMsys only.  In that case, we need to 
keep the previous .fn and .data files for latter use.  And it should
be planned ahead.

Given that, I would like to temporarilly revert the patch and work
it out in fuller details.  Opinions?

\start
Date: Sat, 18 Nov 2006 03:14:20 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: branches/build-improvements/src
Cc: Waldek Hebisch

> yes, it deletes the existing NRLIBs.  
> However, I'm not sure where whole SPAD needs to be recompiled, or only
> AXIOMSsys.   I believe it is AXIOMsys only.  In that case, we need to 
> keep the previous .fn and .data files for latter use.  And it should
> be planned ahead.

The function optimization stuff that Schelter and I worked on
requires two compiles. If the optimizing code is loaded and enabled
the first lisp compile has a side-effect output of .fn files. These
.fn files contain static type information that describes the types
of the lisp function call and arguments.

In order to optimize lisp code you:

 1) load the optimizer program (gcl_collectfn)
 2) enable the optimizer
 3) 1st compile the lisp function or file
 4) (lisp generates a .fn file)
 5) load the .fn file
 6) 2nd compile the lisp function or file

If the .fn files are loaded and a second compile is done then there is
a significant speedup of the generated code because the lisp compiler
can almost completely eliminate the function calling overhead.




In axiom this process is planned to be automated during the build 
process (see src/interp/Makefile.pamphlet around line 368). 

The idea is that during an axiom build you generate the .fn files
At the end of each subdirectory such as boot, interp, and algebra
you gather up the .fn files into a proclaims file. Thus the first
time you compile boot you gather up the .fn files into 
src/boot/boot-proclaims.lisp. The first time you compile interp
you gather the .fn files into src/interp/interp-proclaims.lisp.
The first time you compile the algebra you gather the .fn files
into src/interp/algebra-proclaims.lisp

The second time you build the system you can increase the speed
of the build and the speed of the compiled code because you have
cached the correct type information into these proclaim files.

This machinery is only partially built but you can see that it
is partially documented in the Makefile and the partial proclaim
files exist. (src/boot/boot-proclaims, src/interp/interp-proclaims)
These need to be automatically built, cached in the source tree,
 and pre-loaded in the bootsys, interpsys, and axiomsys images.
Someone could create a branch to explore this machinery.

Notice the implications of this for the whole build mechanism.
Past builds create information used by future builds. This
already exists with the databases although there are still
bugs in that process. The end result is that builds are much
faster because two-pass processing can be eliminated and the
generated code is faster even though the build is shorter.

As you guys dive into the code you're beginning to overrun
areas where I've been working.

\start
Date: 18 Nov 2006 10:03:09 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Boot

Tim Daly writes:

[...]

| first, bill burge loved puns and i remember him explaining to me
| that the latest version of boot was much better and more comfortable,

Indeed, the "new boot" is much more comfortable than "old boot", in
many respects.  It has a preliminary support for (dynamic)
type-checking, algebra datatype and pattern matching. 

I don't think there is much code in Axiom that takes advantage of the 
features of "new boot".

I believe I understand enough of it to start documenting it properly.
Very interestingly, it has much ressemblance with core Haskell.

However, the "new boot" still needs some tuning, but I prefer it over
the "old boot".

\start
Date: 18 Nov 2006 10:14:55 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: branches/build-improvements/src
Cc: Waldek Hebisch

Tim Daly writes:

| Gaby,
| 
| > yes, it deletes the existing NRLIBs.  
| > However, I'm not sure where whole SPAD needs to be recompiled, or only
| > AXIOMSsys.   I believe it is AXIOMsys only.  In that case, we need to 
| > keep the previous .fn and .data files for latter use.  And it should
| > be planned ahead.
| 
| The function optimization stuff that Schelter and I worked on
| requires two compiles. If the optimizing code is loaded and enabled
| the first lisp compile has a side-effect output of .fn files. These
| .fn files contain static type information that describes the types
| of the lisp function call and arguments.
| 
| In order to optimize lisp code you:
| 
|  1) load the optimizer program (gcl_collectfn)
|  2) enable the optimizer
|  3) 1st compile the lisp function or file
|  4) (lisp generates a .fn file)
|  5) load the .fn file
|  6) 2nd compile the lisp function or file
| 
| If the .fn files are loaded and a second compile is done then there is
| a significant speedup of the generated code because the lisp compiler
| can almost completely eliminate the function calling overhead.

Yes, I understood that part.

My question is whether the optimization we're talking about
is about just AXIOMsys, or about whole AXIOMsys+algebras.

I don't believe Waldek's original patch planned any of those
optimizations.  And if it did, then it is not right.

I'll update README.build-improvements to have this item as goal.

I've spent the last couple of days on the "new boot" translator.  I
uncovered a "package hell" bug that I'll fix in a moment.

Then, I'll move on making sure Humberto can build Axiom on MAC, then
support Axiom build without X, then work on the optimization stuff.
I'll be working on/off on documenting "new boot".

[...]

| This machinery is only partially built but you can see that it
| is partially documented in the Makefile and the partial proclaim
| files exist. (src/boot/boot-proclaims, src/interp/interp-proclaims)

Yes.

| These need to be automatically built, cached in the source tree,
|  and pre-loaded in the bootsys, interpsys, and axiomsys images.
| Someone could create a branch to explore this machinery.

I'm not sure they should be cached in the source tree, as opposed to
being generated during the build.

| Notice the implications of this for the whole build mechanism.

Yes.  That is why I came to believe that the change in the behaviour
is accidental, as opposed to being intended.

| Past builds create information used by future builds. This
| already exists with the databases although there are still
| bugs in that process. 

I think the database part is what Waldek originally wanted to fix.

| The end result is that builds are much
| faster because two-pass processing can be eliminated and the
| generated code is faster even though the build is shorter.
| 
| 
| 
| 
| As you guys dive into the code you're beginning to overrun
| areas where I've been working.

Hey, that is why it is opens source, right? ;-)

\start
Date: 18 Nov 2006 04:23:33 -0600
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] src/boot package hell

Hi,

  The basic idea of this patch is to push into package boottran when
translating Boot files.  

  Apparently, boottran::boottocl is the most tested function.  It gets
it right.  But other similar translation functions (e.g. the cousine
boottran::boottoclc) do not; therefore the will do incorrect translation.
The faults in the output is failure to recognize Boot-specific
keywords or functions.  For example, before this patch

  * boottocl translates true to T         -- correct
  * boottoclc translates true to |true|   -- incorrect.

The reason is that when the current package is not boottran, the
translaters get hold on inexistant translation tables, which
results in their thinking that some identifiers that are special are
not. 

This patch always push into boottran before doing translation.  I've
also made a list of functions for which the behaviour is defined.

Build and tested on an i686-pc-linux-gnu.

-- Gaby

2006-11-16  Gabriel Dos Reis  Gabriel Dos Reis

	* ptyout.boot.pamphlet (BOOTTOCLLINES, BOOTTOMC, BOCLAM,
	STEVAL, STTOMC, PSTOU): Temporarily push
	into package BootTran and default float format to double.
	(BOOTTOCL): Don't do it here.
	(shoeNotFound): Return nil.

*** ptyout.boot.pamphlet	(revision 16896)
--- ptyout.boot.pamphlet	(local)
***************
*** 1,14 ****
  \documentclass{article}
  \usepackage{axiom}
! \begin{document}
  \title{\$SPAD/src/boot ptyout.boot}
  \author{The Axiom Team}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
  We assume that we are translating a file called {\bf ``foo.boot''}
  and expect to generate a file called {\bf ``foo.clisp''}.
  
--- 1,42 ----
  \documentclass{article}
  \usepackage{axiom}
! 
  \title{\$SPAD/src/boot ptyout.boot}
  \author{The Axiom Team}
+ 
+ \begin{document}
  \maketitle
+ 
  \begin{abstract}
+ This file implement various Boot translaters.
  \end{abstract}
  \eject
+ 
  \tableofcontents
  \eject
+ 
+ \section{Entry points to this module}
+ 
+ The only entry points to this module are:
+ \begin{itemize}
+ \item [BOOTTOCL]
+ \item [BOOTCLAM]
+ \item [BOOTTOCLC]
+ \item [BOOTTOMC]
+ \item [BOOT]
+ \item [COMPILE-BOOT-FILE]
+ \item [EVAL-BOOT-FILE]
+ \item [BO]
+ \item [BOCLAM]
+ \item [STOUT]
+ \item [STEVAL]
+ \item [STTOMC]
+ \end{itmize}
+ 
+ Calling other functions defined here, from outside of this module,
+ may lead to unpredictable results.  
+ 
+ 
  We assume that we are translating a file called {\bf ``foo.boot''}
  and expect to generate a file called {\bf ``foo.clisp''}.
  
*************** return the string ``foo.clisp PRODUCED''
*** 27,36 ****
  
  <<BOOTTOCLLINES>>= 
  BOOTTOCLLINES(lines, fn)==
     infn:=shoeAddbootIfNec fn
     outfn:=CONCAT(shoeRemovebootIfNec fn,'".clisp")
!    shoeOpenInputFile(a,infn,
!         shoeClLines(a,fn,lines,outfn))
   
  @
  \section{License}
--- 55,69 ----
  
  <<BOOTTOCLLINES>>= 
  BOOTTOCLLINES(lines, fn)==
+    _*READ_-DEFAULT_-FLOAT_-FORMAT_* := 'DOUBLE_-FLOAT
+    callingPackage := PACKAGE_-NAME _*PACKAGE_*
+    IN_-PACKAGE 'BOOTTRAN
     infn:=shoeAddbootIfNec fn
     outfn:=CONCAT(shoeRemovebootIfNec fn,'".clisp")
!    result := shoeOpenInputFile(a,infn,
!                 shoeClLines(a,fn,lines,outfn))
!    IN_-PACKAGE callingPackage
!    result
   
  @
  \section{License}
*************** BOOTTOCLLINES(lines, fn)==
*** 75,86 ****
  -- the common lisp file "filename.clisp"
   
  BOOTTOCL fn ==
-          a:=PACKAGE_-NAME _*PACKAGE_*
-          IN_-PACKAGE 'BOOTTRAN
           $bfClamming:local:=false
-          _*READ_-DEFAULT_-FLOAT_-FORMAT_* := 'DOUBLE_-FLOAT
           BOOTTOCLLINES(nil,fn)
-          IN_-PACKAGE a
   
  -- (bootclam "filename") translates the file "filename.boot" to
  -- the common lisp file "filename.clisp" , producing, for each function
--- 108,115 ----
*************** shoeClLines(a,fn,lines,outfn)==
*** 111,121 ****
  BOOTTOCLC fn==BOOTTOCLCLINES(nil,fn)
   
  BOOTTOCLCLINES(lines, fn)==
    $bfClamming:local:=false
    infn:=shoeAddbootIfNec fn
    outfn:=shoeRemovebootIfNec fn
!   shoeOpenInputFile(a,infn,
!          shoeClCLines(a,fn,lines,CONCAT(outfn,'".clisp")))
   
  shoeClCLines(a,fn,lines,outfn)==
        if null a
--- 140,155 ----
  BOOTTOCLC fn==BOOTTOCLCLINES(nil,fn)
   
  BOOTTOCLCLINES(lines, fn)==
+   callingPackage := PACKAGE_-NAME _*PACKAGE_*
+   IN_-PACKAGE 'BOOTTRAN
    $bfClamming:local:=false
    infn:=shoeAddbootIfNec fn
    outfn:=shoeRemovebootIfNec fn
!   result := shoeOpenInputFile(a,infn,
!                shoeClCLines(a,fn,lines,CONCAT(outfn,'".clisp")))
!   IN_-PACKAGE callingPackage
!   result
!   
   
  shoeClCLines(a,fn,lines,outfn)==
        if null a
*************** shoeClCLines(a,fn,lines,outfn)==
*** 132,141 ****
  -- to machine code and loads it one item at a time
   
  BOOTTOMC fn==
     $bfClamming:local:=false
     $GenVarCounter:local := 0
     infn:=shoeAddbootIfNec fn
!    shoeOpenInputFile(a,infn,shoeMc(a,fn))
   
  shoeMc(a,fn)==
     if null a
--- 166,179 ----
  -- to machine code and loads it one item at a time
   
  BOOTTOMC fn==
+    callingPackage := PACKAGE_-NAME _*PACKAGE_*
+    IN_-PACKAGE 'BOOTTRAN
     $bfClamming:local:=false
     $GenVarCounter:local := 0
     infn:=shoeAddbootIfNec fn
!    result := shoeOpenInputFile(a,infn,shoeMc(a,fn))
!    IN_-PACKAGE callingPackage
!    result
   
  shoeMc(a,fn)==
     if null a
*************** BO fn==
*** 182,191 ****
       IN_-PACKAGE b
   
  BOCLAM fn==
       $GenVarCounter:local := 0
       $bfClamming:local := true
       infn:=shoeAddbootIfNec fn
!      shoeOpenInputFile(a,infn,shoeToConsole(a,fn))
   
  shoeToConsole(a,fn)==
       if null a
--- 220,233 ----
       IN_-PACKAGE b
   
  BOCLAM fn==
+      callingPackage := PACKAGE_-NAME _*PACKAGE_*
+      IN_-PACKAGE 'BOOTTRAN
       $GenVarCounter:local := 0
       $bfClamming:local := true
       infn:=shoeAddbootIfNec fn
!      result := shoeOpenInputFile(a,infn,shoeToConsole(a,fn))
!      IN_-PACKAGE callingPackage
!      result
   
  shoeToConsole(a,fn)==
       if null a
*************** STOUT string==   PSTOUT [string]
*** 203,227 ****
  --   shoeConsoleTrees shoeTransformString [string]
   
  STEVAL string==
     $GenVarCounter:local := 0
     $bfClamming:local:=false
     a:=  shoeTransformString [string]
!    if bStreamPackageNull a
!    then nil
!    else
!     fn:=stripm(CAR a,_*PACKAGE_*,FIND_-PACKAGE '"BOOTTRAN")
!     EVAL fn
   
  -- (sttomc "string") translates the string "string"
  -- to common lisp, and compiles it.
   
  STTOMC string==
     $GenVarCounter:local := 0
     $bfClamming:local:=false
     a:=  shoeTransformString [string]
!    if bStreamPackageNull a
!    then nil
!    else shoePCompile car a
   
   
  shoeCompileTrees s==
--- 245,276 ----
  --   shoeConsoleTrees shoeTransformString [string]
   
  STEVAL string==
+    callingPackage := PACKAGE_-NAME _*PACKAGE_*
+    IN_-PACKAGE 'BOOTTRAN
     $GenVarCounter:local := 0
     $bfClamming:local:=false
     a:=  shoeTransformString [string]
!    result := 
!       bStreamPackageNull a => nil
!       fn:=stripm(CAR a,_*PACKAGE_*,FIND_-PACKAGE '"BOOTTRAN")
!       EVAL fn
!    IN_-PACKAGE callingPACKAGE
!    result
   
  -- (sttomc "string") translates the string "string"
  -- to common lisp, and compiles it.
   
  STTOMC string==
+    callingPackage := PACKAGE_-NAME _*PACKAGE_*
+    IN_-PACKAGE 'BOOTTRAN
     $GenVarCounter:local := 0
     $bfClamming:local:=false
     a:=  shoeTransformString [string]
!    result := 
!       bStreamPackageNull a => nil
!       shoePCompile car a
!    IN_-PACKAGE callingPACKAGE
!    result
   
   
  shoeCompileTrees s==
*************** shoeCompile fn==
*** 234,240 ****
            COMPILE (name,['LAMBDA,bv,:body])
      EVAL fn
   
! shoeNotFound fn==  shoeConsole CONCAT(fn ,'" NOT FOUND")
   
  shoeTransform str==
      bNext(function shoeTreeConstruct,
--- 283,291 ----
            COMPILE (name,['LAMBDA,bv,:body])
      EVAL fn
   
! shoeNotFound fn ==  
!    shoeConsole CONCAT(fn ,'" NOT FOUND")
!    nil
   
  shoeTransform str==
      bNext(function shoeTreeConstruct,
*************** BOOTPO ()==
*** 816,824 ****
      BOOTPO()
   
  PSTOUT string==
     $GenVarCounter:local := 0
     $bfClamming:local:=false
!    shoeConsoleTrees shoeTransformString string
   
  @
  <<ptyout.clisp>>=
--- 867,879 ----
      BOOTPO()
   
  PSTOUT string==
+    callingPackage := PACKAGE_-NAME _*PACKAGE_*
+    IN_-PACKAGE 'BOOTTRAN
     $GenVarCounter:local := 0
     $bfClamming:local:=false
!    result := shoeConsoleTrees shoeTransformString string
!    IN_-PACKAGE callingPackage
!    result
   
  @
  <<ptyout.clisp>>=
*************** PSTOUT string==
*** 826,840 ****
  (IN-PACKAGE 'BOOTTRAN)
  
  (DEFUN BOOTTOCL (|fn|)
!   (PROG (|$bfClamming| |a|)
      (DECLARE (SPECIAL |$bfClamming|))
!     (RETURN
!       (PROGN
!         (SETQ |a| (PACKAGE-NAME *PACKAGE*))
!         (IN-PACKAGE 'BOOTTRAN)
!         (SETQ |$bfClamming| NIL)
!         (BOOTTOCLLINES NIL |fn|)
!         (IN-PACKAGE |a|)))))
  
  (DEFUN BOOTCLAM (|fn|) (PROG () (RETURN (BOOTCLAMLINES NIL |fn|))))
  
--- 881,889 ----
  (IN-PACKAGE 'BOOTTRAN)
  
  (DEFUN BOOTTOCL (|fn|)
!   (PROG (|$bfClamming|)
      (DECLARE (SPECIAL |$bfClamming|))
!     (RETURN (PROGN (SETQ |$bfClamming| NIL) (BOOTTOCLLINES NIL |fn|)))))
  
  (DEFUN BOOTCLAM (|fn|) (PROG () (RETURN (BOOTCLAMLINES NIL |fn|))))
  
*************** PSTOUT string==
*** 845,857 ****
        (PROGN (SETQ |$bfClamming| T) (BOOTTOCLLINES |lines| |fn|)))))
  
  (DEFUN BOOTTOCLLINES (|lines| |fn|)
!   (PROG (|outfn| |infn|)
      (RETURN
        (PROGN
          (SETQ |infn| (|shoeAddbootIfNec| |fn|))
          (SETQ |outfn| (CONCAT (|shoeRemovebootIfNec| |fn|) ".clisp"))
!         (|shoeOpenInputFile| |a| |infn|
!             (|shoeClLines| |a| |fn| |lines| |outfn|))))))
  
  (DEFUN |shoeClLines| (|a| |fn| |lines| |outfn|)
    (PROG (|$GenVarCounter|)
--- 894,913 ----
        (PROGN (SETQ |$bfClamming| T) (BOOTTOCLLINES |lines| |fn|)))))
  
  (DEFUN BOOTTOCLLINES (|lines| |fn|)
!   (PROG (|result| |outfn| |infn| |callingPackage|
!             *READ-DEFAULT-FLOAT-FORMAT*)
      (RETURN
        (PROGN
+         (SETQ *READ-DEFAULT-FLOAT-FORMAT* 'DOUBLE-FLOAT)
+         (SETQ |callingPackage| (PACKAGE-NAME *PACKAGE*))
+         (IN-PACKAGE 'BOOTTRAN)
          (SETQ |infn| (|shoeAddbootIfNec| |fn|))
          (SETQ |outfn| (CONCAT (|shoeRemovebootIfNec| |fn|) ".clisp"))
!         (SETQ |result|
!               (|shoeOpenInputFile| |a| |infn|
!                   (|shoeClLines| |a| |fn| |lines| |outfn|)))
!         (IN-PACKAGE |callingPackage|)
!         |result|))))
  
  (DEFUN |shoeClLines| (|a| |fn| |lines| |outfn|)
    (PROG (|$GenVarCounter|)
*************** PSTOUT string==
*** 877,891 ****
  (DEFUN BOOTTOCLC (|fn|) (PROG () (RETURN (BOOTTOCLCLINES NIL |fn|))))
  
  (DEFUN BOOTTOCLCLINES (|lines| |fn|)
!   (PROG (|$bfClamming| |outfn| |infn|)
      (DECLARE (SPECIAL |$bfClamming|))
      (RETURN
        (PROGN
          (SETQ |$bfClamming| NIL)
          (SETQ |infn| (|shoeAddbootIfNec| |fn|))
          (SETQ |outfn| (|shoeRemovebootIfNec| |fn|))
!         (|shoeOpenInputFile| |a| |infn|
!             (|shoeClCLines| |a| |fn| |lines| (CONCAT |outfn| ".clisp")))))))
  
  (DEFUN |shoeClCLines| (|a| |fn| |lines| |outfn|)
    (PROG (|$GenVarCounter|)
--- 933,953 ----
  (DEFUN BOOTTOCLC (|fn|) (PROG () (RETURN (BOOTTOCLCLINES NIL |fn|))))
  
  (DEFUN BOOTTOCLCLINES (|lines| |fn|)
!   (PROG (|$bfClamming| |result| |outfn| |infn| |callingPackage|)
      (DECLARE (SPECIAL |$bfClamming|))
      (RETURN
        (PROGN
+         (SETQ |callingPackage| (PACKAGE-NAME *PACKAGE*))
+         (IN-PACKAGE 'BOOTTRAN)
          (SETQ |$bfClamming| NIL)
          (SETQ |infn| (|shoeAddbootIfNec| |fn|))
          (SETQ |outfn| (|shoeRemovebootIfNec| |fn|))
!         (SETQ |result|
!               (|shoeOpenInputFile| |a| |infn|
!                   (|shoeClCLines| |a| |fn| |lines|
!                       (CONCAT |outfn| ".clisp"))))
!         (IN-PACKAGE |callingPackage|)
!         |result|))))
  
  (DEFUN |shoeClCLines| (|a| |fn| |lines| |outfn|)
    (PROG (|$GenVarCounter|)
*************** PSTOUT string==
*** 913,926 ****
           (|shoeConsole| (CONCAT |outfn| " PRODUCED")))))))
  
  (DEFUN BOOTTOMC (|fn|)
!   (PROG (|$GenVarCounter| |$bfClamming| |infn|)
!     (DECLARE (SPECIAL |$bfClamming| |$GenVarCounter|))
      (RETURN
        (PROGN
          (SETQ |$bfClamming| NIL)
          (SETQ |$GenVarCounter| 0)
          (SETQ |infn| (|shoeAddbootIfNec| |fn|))
!         (|shoeOpenInputFile| |a| |infn| (|shoeMc| |a| |fn|))))))
  
  (DEFUN |shoeMc| (|a| |fn|)
    (PROG ()
--- 975,994 ----
           (|shoeConsole| (CONCAT |outfn| " PRODUCED")))))))
  
  (DEFUN BOOTTOMC (|fn|)
!   (PROG (|$GenVarCounter| |$bfClamming| |result| |infn|
!             |callingPackage|)
!     (DECLARE (SPECIAL |$GenVarCounter| |$bfClamming|))
      (RETURN
        (PROGN
+         (SETQ |callingPackage| (PACKAGE-NAME *PACKAGE*))
+         (IN-PACKAGE 'BOOTTRAN)
          (SETQ |$bfClamming| NIL)
          (SETQ |$GenVarCounter| 0)
          (SETQ |infn| (|shoeAddbootIfNec| |fn|))
!         (SETQ |result|
!               (|shoeOpenInputFile| |a| |infn| (|shoeMc| |a| |fn|)))
!         (IN-PACKAGE |callingPackage|)
!         |result|))))
  
  (DEFUN |shoeMc| (|a| |fn|)
    (PROG ()
*************** PSTOUT string==
*** 970,976 ****
  
  (DEFUN BO (|fn|)
    (PROG (|$bfClamming| |$GenVarCounter| |infn| |b|)
!     (DECLARE (SPECIAL |$GenVarCounter| |$bfClamming|))
      (RETURN
        (PROGN
          (SETQ |b| (PACKAGE-NAME *PACKAGE*))
--- 1038,1044 ----
  
  (DEFUN BO (|fn|)
    (PROG (|$bfClamming| |$GenVarCounter| |infn| |b|)
!     (DECLARE (SPECIAL |$bfClamming| |$GenVarCounter|))
      (RETURN
        (PROGN
          (SETQ |b| (PACKAGE-NAME *PACKAGE*))
*************** PSTOUT string==
*** 982,995 ****
          (IN-PACKAGE |b|)))))
  
  (DEFUN BOCLAM (|fn|)
!   (PROG (|$bfClamming| |$GenVarCounter| |infn|)
!     (DECLARE (SPECIAL |$GenVarCounter| |$bfClamming|))
      (RETURN
        (PROGN
          (SETQ |$GenVarCounter| 0)
          (SETQ |$bfClamming| T)
          (SETQ |infn| (|shoeAddbootIfNec| |fn|))
!         (|shoeOpenInputFile| |a| |infn| (|shoeToConsole| |a| |fn|))))))
  
  (DEFUN |shoeToConsole| (|a| |fn|)
    (PROG ()
--- 1050,1070 ----
          (IN-PACKAGE |b|)))))
  
  (DEFUN BOCLAM (|fn|)
!   (PROG (|$bfClamming| |$GenVarCounter| |result| |infn|
!             |callingPackage|)
!     (DECLARE (SPECIAL |$bfClamming| |$GenVarCounter|))
      (RETURN
        (PROGN
+         (SETQ |callingPackage| (PACKAGE-NAME *PACKAGE*))
+         (IN-PACKAGE 'BOOTTRAN)
          (SETQ |$GenVarCounter| 0)
          (SETQ |$bfClamming| T)
          (SETQ |infn| (|shoeAddbootIfNec| |fn|))
!         (SETQ |result|
!               (|shoeOpenInputFile| |a| |infn|
!                   (|shoeToConsole| |a| |fn|)))
!         (IN-PACKAGE |callingPackage|)
!         |result|))))
  
  (DEFUN |shoeToConsole| (|a| |fn|)
    (PROG ()
*************** PSTOUT string==
*** 1005,1036 ****
  (DEFUN STOUT (|string|) (PROG () (RETURN (PSTOUT (LIST |string|)))))
  
  (DEFUN STEVAL (|string|)
!   (PROG (|$bfClamming| |$GenVarCounter| |fn| |a|)
!     (DECLARE (SPECIAL |$GenVarCounter| |$bfClamming|))
      (RETURN
        (PROGN
          (SETQ |$GenVarCounter| 0)
          (SETQ |$bfClamming| NIL)
          (SETQ |a| (|shoeTransformString| (LIST |string|)))
!         (COND
!           ((|bStreamPackageNull| |a|) NIL)
!           ('T
!            (SETQ |fn|
!                  (|stripm| (CAR |a|) *PACKAGE*
!                            (FIND-PACKAGE "BOOTTRAN")))
!            (EVAL |fn|)))))))
  
  (DEFUN STTOMC (|string|)
!   (PROG (|$bfClamming| |$GenVarCounter| |a|)
!     (DECLARE (SPECIAL |$GenVarCounter| |$bfClamming|))
      (RETURN
        (PROGN
          (SETQ |$GenVarCounter| 0)
          (SETQ |$bfClamming| NIL)
          (SETQ |a| (|shoeTransformString| (LIST |string|)))
!         (COND
!           ((|bStreamPackageNull| |a|) NIL)
!           ('T (|shoePCompile| (CAR |a|))))))))
  
  (DEFUN |shoeCompileTrees| (|s|)
    (PROG ()
--- 1080,1123 ----
  (DEFUN STOUT (|string|) (PROG () (RETURN (PSTOUT (LIST |string|)))))
  
  (DEFUN STEVAL (|string|)
!   (PROG (|$bfClamming| |$GenVarCounter| |result| |fn| |a|
!             |callingPackage|)
!     (DECLARE (SPECIAL |$bfClamming| |$GenVarCounter|))
      (RETURN
        (PROGN
+         (SETQ |callingPackage| (PACKAGE-NAME *PACKAGE*))
+         (IN-PACKAGE 'BOOTTRAN)
          (SETQ |$GenVarCounter| 0)
          (SETQ |$bfClamming| NIL)
          (SETQ |a| (|shoeTransformString| (LIST |string|)))
!         (SETQ |result|
!               (COND
!                 ((|bStreamPackageNull| |a|) NIL)
!                 ('T
!                  (PROGN
!                    (SETQ |fn|
!                          (|stripm| (CAR |a|) *PACKAGE*
!                              (FIND-PACKAGE "BOOTTRAN")))
!                    (EVAL |fn|)))))
!         (IN-PACKAGE |callingPACKAGE|)
!         |result|))))
  
  (DEFUN STTOMC (|string|)
!   (PROG (|$bfClamming| |$GenVarCounter| |result| |a| |callingPackage|)
!     (DECLARE (SPECIAL |$bfClamming| |$GenVarCounter|))
      (RETURN
        (PROGN
+         (SETQ |callingPackage| (PACKAGE-NAME *PACKAGE*))
+         (IN-PACKAGE 'BOOTTRAN)
          (SETQ |$GenVarCounter| 0)
          (SETQ |$bfClamming| NIL)
          (SETQ |a| (|shoeTransformString| (LIST |string|)))
!         (SETQ |result|
!               (COND
!                 ((|bStreamPackageNull| |a|) NIL)
!                 ('T (|shoePCompile| (CAR |a|)))))
!         (IN-PACKAGE |callingPACKAGE|)
!         |result|))))
  
  (DEFUN |shoeCompileTrees| (|s|)
    (PROG ()
*************** PSTOUT string==
*** 1062,1068 ****
          ('T (EVAL |fn|))))))
  
  (DEFUN |shoeNotFound| (|fn|)
!   (PROG () (RETURN (|shoeConsole| (CONCAT |fn| " NOT FOUND")))))
  
  (DEFUN |shoeTransform| (|str|)
    (PROG ()
--- 1149,1156 ----
          ('T (EVAL |fn|))))))
  
  (DEFUN |shoeNotFound| (|fn|)
!   (PROG ()
!     (RETURN (PROGN (|shoeConsole| (CONCAT |fn| " NOT FOUND")) NIL))))
  
  (DEFUN |shoeTransform| (|str|)
    (PROG ()
*************** PSTOUT string==
*** 1174,1180 ****
               (SETQ |bfVar#4| (CDR |bfVar#4|))))
           |lines| NIL)
          (|shoeConsole| " ")))))
- 
  (DEFUN |shoeFileLine| (|x| |stream|)
    (PROG () (RETURN (PROGN (WRITE-LINE |x| |stream|) |x|))))
  
--- 1262,1267 ----
*************** PSTOUT string==
*** 1217,1224 ****
  (DEFUN |shoeOutParse| (|stream|)
    (PROG (|$bpParenCount| |$bpCount| |$returns| |$typings| |$wheredefs|
              |$op| |$ttok| |$stok| |$stack| |$inputStream| |found|)
!     (DECLARE (SPECIAL |$stok| |$ttok| |$op| |$wheredefs| |$typings|
!                       |$returns| |$bpCount| |$bpParenCount| |$stack|
                        |$inputStream|))
      (RETURN
        (PROGN
--- 1304,1311 ----
  (DEFUN |shoeOutParse| (|stream|)
    (PROG (|$bpParenCount| |$bpCount| |$returns| |$typings| |$wheredefs|
              |$op| |$ttok| |$stok| |$stack| |$inputStream| |found|)
!     (DECLARE (SPECIAL |$bpParenCount| |$bpCount| |$returns| |$typings|
!                       |$wheredefs| |$op| |$ttok| |$stok| |$stack|
                        |$inputStream|))
      (RETURN
        (PROGN
*************** PSTOUT string==
*** 1338,1345 ****
          ((|bStreamNull| (CAR |z|))
           (COND
             ((|bStreamNull| (CADR |z|)) (LIST '|nullstream|))
!            ('T (CADR |z|))))
!         ('T (CONS (CAAR |z|) (|bAppend| (CDAR |z|) (CADR |z|))))))))
  
  (DEFUN |bMap| (|f| |x|)
    (PROG () (RETURN (|bDelay| #'|bMap1| (LIST |f| |x|)))))
--- 1425,1432 ----
          ((|bStreamNull| (CAR |z|))
           (COND
             ((|bStreamNull| (CADR |z|)) (LIST '|nullstream|))
!            (#0='T (CADR |z|))))
!         (#0# (CONS (CAAR |z|) (|bAppend| (CDAR |z|) (CADR |z|))))))))
  
  (DEFUN |bMap| (|f| |x|)
    (PROG () (RETURN (|bDelay| #'|bMap1| (LIST |f| |x|)))))
*************** PSTOUT string==
*** 1433,1440 ****
  (DEFUN |shoeDfu| (|a| |fn|)
    (PROG (|$bfClamming| |$GenVarCounter| |$bootDefinedTwice| |$bootUsed|
              |$bootDefined| |$lispWordTable| |out|)
!     (DECLARE (SPECIAL |$bootDefined| |$bootUsed| |$bootDefinedTwice|
!                       |$GenVarCounter| |$bfClamming| |$lispWordTable|))
      (RETURN
        (COND
          ((NULL |a|) (|shoeNotFound| |fn|))
--- 1520,1528 ----
  (DEFUN |shoeDfu| (|a| |fn|)
    (PROG (|$bfClamming| |$GenVarCounter| |$bootDefinedTwice| |$bootUsed|
              |$bootDefined| |$lispWordTable| |out|)
!     (DECLARE (SPECIAL |$bfClamming| |$GenVarCounter|
!                       |$bootDefinedTwice| |$bootUsed| |$bootDefined|
!                       |$lispWordTable|))
      (RETURN
        (COND
          ((NULL |a|) (|shoeNotFound| |fn|))
*************** PSTOUT string==
*** 1463,1469 ****
                       ((OR (ATOM |bfVar#5|)
                            (PROGN (SETQ |i| (CAR |bfVar#5|)) NIL))
                        (RETURN (NREVERSE |bfVar#6|)))
!                      ('T
                        (AND (NULL (GETHASH |i| |$bootUsed|))
                             (SETQ |bfVar#6| (CONS |i| |bfVar#6|)))))
                     (SETQ |bfVar#5| (CDR |bfVar#5|))))
--- 1551,1557 ----
                       ((OR (ATOM |bfVar#5|)
                            (PROGN (SETQ |i| (CAR |bfVar#5|)) NIL))
                        (RETURN (NREVERSE |bfVar#6|)))
!                      (#0='T
                        (AND (NULL (GETHASH |i| |$bootUsed|))
                             (SETQ |bfVar#6| (CONS |i| |bfVar#6|)))))
                     (SETQ |bfVar#5| (CDR |bfVar#5|))))
*************** PSTOUT string==
*** 1481,1487 ****
                       ((OR (ATOM |bfVar#7|)
                            (PROGN (SETQ |i| (CAR |bfVar#7|)) NIL))
                        (RETURN (NREVERSE |bfVar#8|)))
!                      ('T
                        (AND (NULL (GETHASH |i| |$bootDefined|))
                             (SETQ |bfVar#8| (CONS |i| |bfVar#8|)))))
                     (SETQ |bfVar#7| (CDR |bfVar#7|))))
--- 1569,1575 ----
                       ((OR (ATOM |bfVar#7|)
                            (PROGN (SETQ |i| (CAR |bfVar#7|)) NIL))
                        (RETURN (NREVERSE |bfVar#8|)))
!                      (#0#
                        (AND (NULL (GETHASH |i| |$bootDefined|))
                             (SETQ |bfVar#8| (CONS |i| |bfVar#8|)))))
                     (SETQ |bfVar#7| (CDR |bfVar#7|))))
*************** PSTOUT string==
*** 1492,1498 ****
                 ((OR (ATOM |bfVar#9|)
                      (PROGN (SETQ |i| (CAR |bfVar#9|)) NIL))
                  (RETURN NIL))
!                ('T
                  (PROGN
                    (SETQ |b| (CONCAT (PNAME |i|) " is used in "))
                    (|bootOutLines| (SSORT (GETHASH |i| |$bootUsed|))
--- 1580,1586 ----
                 ((OR (ATOM |bfVar#9|)
                      (PROGN (SETQ |i| (CAR |bfVar#9|)) NIL))
                  (RETURN NIL))
!                (#0#
                  (PROGN
                    (SETQ |b| (CONCAT (PNAME |i|) " is used in "))
                    (|bootOutLines| (SSORT (GETHASH |i| |$bootUsed|))
*************** PSTOUT string==
*** 1532,1538 ****
                                      (PROGN
                                        (SETQ |bv| (CAR |ISTMP#2|))
                                        (SETQ |body| (CDR |ISTMP#2|))
!                                       'T))))))
                   (LIST |name| (CONS 'LAMBDA (CONS |bv| |body|))))
                  ((AND (CONSP |x|) (EQ (CAR |x|) 'DEFMACRO)
                        (PROGN
--- 1620,1626 ----
                                      (PROGN
                                        (SETQ |bv| (CAR |ISTMP#2|))
                                        (SETQ |body| (CDR |ISTMP#2|))
!                                       #0='T))))))
                   (LIST |name| (CONS 'LAMBDA (CONS |bv| |body|))))
                  ((AND (CONSP |x|) (EQ (CAR |x|) 'DEFMACRO)
                        (PROGN
*************** PSTOUT string==
*** 1545,1551 ****
                                      (PROGN
                                        (SETQ |bv| (CAR |ISTMP#2|))
                                        (SETQ |body| (CDR |ISTMP#2|))
!                                       'T))))))
                   (LIST |name| (CONS 'LAMBDA (CONS |bv| |body|))))
                  ((AND (CONSP |x|) (EQ (CAR |x|) 'EVAL-WHEN)
                        (PROGN
--- 1633,1639 ----
                                      (PROGN
                                        (SETQ |bv| (CAR |ISTMP#2|))
                                        (SETQ |body| (CDR |ISTMP#2|))
!                                       #0#))))))
                   (LIST |name| (CONS 'LAMBDA (CONS |bv| |body|))))
                  ((AND (CONSP |x|) (EQ (CAR |x|) 'EVAL-WHEN)
                        (PROGN
*************** PSTOUT string==
*** 1572,1578 ****
                                               (PROGN
                                                 (SETQ |exp|
                                                  (CAR |ISTMP#5|))
!                                                'T))))))))))))
                   (LIST |id| |exp|))
                  ((AND (CONSP |x|) (EQ (CAR |x|) 'SETQ)
                        (PROGN
--- 1660,1666 ----
                                               (PROGN
                                                 (SETQ |exp|
                                                  (CAR |ISTMP#5|))
!                                                #0#))))))))))))
                   (LIST |id| |exp|))
                  ((AND (CONSP |x|) (EQ (CAR |x|) 'SETQ)
                        (PROGN
*************** PSTOUT string==
*** 1585,1593 ****
                                      (EQ (CDR |ISTMP#2|) NIL)
                                      (PROGN
                                        (SETQ |exp| (CAR |ISTMP#2|))
!                                       'T))))))
                   (LIST |id| |exp|))
!                 ('T (LIST 'TOP-LEVEL |x|))))
          (SETQ |nee| (CAR |LETTMP#1|))
          (SETQ |niens| (CADR |LETTMP#1|))
          (COND
--- 1673,1681 ----
                                      (EQ (CDR |ISTMP#2|) NIL)
                                      (PROGN
                                        (SETQ |exp| (CAR |ISTMP#2|))
!                                       #0#))))))
                   (LIST |id| |exp|))
!                 (#1='T (LIST 'TOP-LEVEL |x|))))
          (SETQ |nee| (CAR |LETTMP#1|))
          (SETQ |niens| (CADR |LETTMP#1|))
          (COND
*************** PSTOUT string==
*** 1595,1601 ****
             (SETQ |$bootDefinedTwice|
                   (COND
                     ((EQ |nee| 'TOP-LEVEL) |$bootDefinedTwice|)
!                    ('T (CONS |nee| |$bootDefinedTwice|)))))
            ('T (HPUT |$bootDefined| |nee| T)))
          (|defuse1| |e| |niens|)
          ((LAMBDA (|bfVar#10| |i|)
--- 1683,1689 ----
             (SETQ |$bootDefinedTwice|
                   (COND
                     ((EQ |nee| 'TOP-LEVEL) |$bootDefinedTwice|)
!                    (#1# (CONS |nee| |$bootDefinedTwice|)))))
            ('T (HPUT |$bootDefined| |nee| T)))
          (|defuse1| |e| |niens|)
          ((LAMBDA (|bfVar#10| |i|)
*************** PSTOUT string==
*** 1623,1630 ****
                      ((MEMQ |y| |e|) |$used|)
                      ((MEMQ |y| |$used|) |$used|)
                      ((|defusebuiltin| |y|) |$used|)
!                     ('T (UNION (LIST |y|) |$used|)))))
!            ('T NIL)))
          ((AND (CONSP |y|) (EQ (CAR |y|) 'LAMBDA)
                (PROGN
                  (SETQ |ISTMP#1| (CDR |y|))
--- 1711,1718 ----
                      ((MEMQ |y| |e|) |$used|)
                      ((MEMQ |y| |$used|) |$used|)
                      ((|defusebuiltin| |y|) |$used|)
!                     (#0='T (UNION (LIST |y|) |$used|)))))
!            (#0# NIL)))
          ((AND (CONSP |y|) (EQ (CAR |y|) 'LAMBDA)
                (PROGN
                  (SETQ |ISTMP#1| (CDR |y|))
*************** PSTOUT string==
*** 1632,1638 ****
                       (PROGN
                         (SETQ |a| (CAR |ISTMP#1|))
                         (SETQ |b| (CDR |ISTMP#1|))
!                        'T))))
           (|defuse1| (APPEND (|unfluidlist| |a|) |e|) |b|))
          ((AND (CONSP |y|) (EQ (CAR |y|) 'PROG)
                (PROGN
--- 1720,1726 ----
                       (PROGN
                         (SETQ |a| (CAR |ISTMP#1|))
                         (SETQ |b| (CDR |ISTMP#1|))
!                        #1='T))))
           (|defuse1| (APPEND (|unfluidlist| |a|) |e|) |b|))
          ((AND (CONSP |y|) (EQ (CAR |y|) 'PROG)
                (PROGN
*************** PSTOUT string==
*** 1641,1647 ****
                       (PROGN
                         (SETQ |a| (CAR |ISTMP#1|))
                         (SETQ |b| (CDR |ISTMP#1|))
!                        'T))))
           (PROGN
             (SETQ |LETTMP#1| (|defSeparate| |a|))
             (SETQ |dol| (CAR |LETTMP#1|))
--- 1729,1735 ----
                       (PROGN
                         (SETQ |a| (CAR |ISTMP#1|))
                         (SETQ |b| (CDR |ISTMP#1|))
!                        #1#))))
           (PROGN
             (SETQ |LETTMP#1| (|defSeparate| |a|))
             (SETQ |dol| (CAR |LETTMP#1|))
*************** PSTOUT string==
*** 1652,1675 ****
                    ((OR (ATOM |bfVar#11|)
                         (PROGN (SETQ |i| (CAR |bfVar#11|)) NIL))
                     (RETURN NIL))
!                   ('T (HPUT |$bootDefined| |i| T)))
                  (SETQ |bfVar#11| (CDR |bfVar#11|))))
              |dol| NIL)
             (|defuse1| (APPEND |ndol| |e|) |b|)))
          ((AND (CONSP |y|) (EQ (CAR |y|) 'QUOTE)
!               (PROGN (SETQ |a| (CDR |y|)) 'T))
           NIL)
          ((AND (CONSP |y|) (EQ (CAR |y|) '+LINE)
!               (PROGN (SETQ |a| (CDR |y|)) 'T))
           NIL)
!         ('T
           ((LAMBDA (|bfVar#12| |i|)
              (LOOP
                (COND
                  ((OR (ATOM |bfVar#12|)
                       (PROGN (SETQ |i| (CAR |bfVar#12|)) NIL))
                   (RETURN NIL))
!                 ('T (|defuse1| |e| |i|)))
                (SETQ |bfVar#12| (CDR |bfVar#12|))))
            |y| NIL))))))
  
--- 1740,1763 ----
                    ((OR (ATOM |bfVar#11|)
                         (PROGN (SETQ |i| (CAR |bfVar#11|)) NIL))
                     (RETURN NIL))
!                   (#2='T (HPUT |$bootDefined| |i| T)))
                  (SETQ |bfVar#11| (CDR |bfVar#11|))))
              |dol| NIL)
             (|defuse1| (APPEND |ndol| |e|) |b|)))
          ((AND (CONSP |y|) (EQ (CAR |y|) 'QUOTE)
!               (PROGN (SETQ |a| (CDR |y|)) #1#))
           NIL)
          ((AND (CONSP |y|) (EQ (CAR |y|) '+LINE)
!               (PROGN (SETQ |a| (CDR |y|)) #1#))
           NIL)
!         (#0#
           ((LAMBDA (|bfVar#12| |i|)
              (LOOP
                (COND
                  ((OR (ATOM |bfVar#12|)
                       (PROGN (SETQ |i| (CAR |bfVar#12|)) NIL))
                   (RETURN NIL))
!                 (#2# (|defuse1| |e| |i|)))
                (SETQ |bfVar#12| (CDR |bfVar#12|))))
            |y| NIL))))))
  
*************** PSTOUT string==
*** 1678,1689 ****
      (RETURN
        (COND
          ((NULL |x|) (LIST NIL NIL))
!         ('T (SETQ |f| (CAR |x|))
           (SETQ |LETTMP#1| (|defSeparate| (CDR |x|)))
           (SETQ |x1| (CAR |LETTMP#1|)) (SETQ |x2| (CADR |LETTMP#1|))
           (COND
             ((|bfBeginsDollar| |f|) (LIST (CONS |f| |x1|) |x2|))
!            ('T (LIST |x1| (CONS |f| |x2|)))))))))
  
  (DEFUN |unfluidlist| (|x|)
    (PROG (|y| |ISTMP#1|)
--- 1766,1777 ----
      (RETURN
        (COND
          ((NULL |x|) (LIST NIL NIL))
!         (#0='T (SETQ |f| (CAR |x|))
           (SETQ |LETTMP#1| (|defSeparate| (CDR |x|)))
           (SETQ |x1| (CAR |LETTMP#1|)) (SETQ |x2| (CADR |LETTMP#1|))
           (COND
             ((|bfBeginsDollar| |f|) (LIST (CONS |f| |x1|) |x2|))
!            (#0# (LIST |x1| (CONS |f| |x2|)))))))))
  
  (DEFUN |unfluidlist| (|x|)
    (PROG (|y| |ISTMP#1|)
*************** PSTOUT string==
*** 1727,1738 ****
      (RETURN
        (COND
          ((NULL |l|) (|shoeFileLine| |s| |outfn|))
!         ('T (SETQ |a| (PNAME (CAR |l|)))
           (COND
             ((< 70 (+ (LENGTH |s|) (LENGTH |a|)))
              (|shoeFileLine| |s| |outfn|)
              (|bootOutLines| |l| |outfn| " "))
!            ('T (|bootOutLines| (CDR |l|) |outfn| (CONCAT |s| " " |a|)))))))))
  
  (DEFUN XREF (|fn|)
    (PROG (|infn|)
--- 1815,1827 ----
      (RETURN
        (COND
          ((NULL |l|) (|shoeFileLine| |s| |outfn|))
!         (#0='T (SETQ |a| (PNAME (CAR |l|)))
           (COND
             ((< 70 (+ (LENGTH |s|) (LENGTH |a|)))
              (|shoeFileLine| |s| |outfn|)
              (|bootOutLines| |l| |outfn| " "))
!            (#0#
!             (|bootOutLines| (CDR |l|) |outfn| (CONCAT |s| " " |a|)))))))))
  
  (DEFUN XREF (|fn|)
    (PROG (|infn|)
*************** PSTOUT string==
*** 1744,1751 ****
  (DEFUN |shoeXref| (|a| |fn|)
    (PROG (|$bfClamming| |$GenVarCounter| |$bootUsed| |$bootDefined|
              |$lispWordTable| |out|)
!     (DECLARE (SPECIAL |$bootDefined| |$bootUsed| |$GenVarCounter|
!                       |$bfClamming| |$lispWordTable|))
      (RETURN
        (COND
          ((NULL |a|) (|shoeNotFound| |fn|))
--- 1833,1840 ----
  (DEFUN |shoeXref| (|a| |fn|)
    (PROG (|$bfClamming| |$GenVarCounter| |$bootUsed| |$bootDefined|
              |$lispWordTable| |out|)
!     (DECLARE (SPECIAL |$bfClamming| |$GenVarCounter| |$bootUsed|
!                       |$bootDefined| |$lispWordTable|))
      (RETURN
        (COND
          ((NULL |a|) (|shoeNotFound| |fn|))
*************** PSTOUT string==
*** 1789,1795 ****
  
  (DEFUN |shoeGeneralFC| (|f| |name| |fn|)
    (PROG (|$GenVarCounter| |$bfClamming| |filename| |a| |infn|)
!     (DECLARE (SPECIAL |$bfClamming| |$GenVarCounter|))
      (RETURN
        (PROGN
          (SETQ |$bfClamming| NIL)
--- 1878,1884 ----
  
  (DEFUN |shoeGeneralFC| (|f| |name| |fn|)
    (PROG (|$GenVarCounter| |$bfClamming| |filename| |a| |infn|)
!     (DECLARE (SPECIAL |$GenVarCounter| |$bfClamming|))
      (RETURN
        (PROGN
          (SETQ |$bfClamming| NIL)
*************** PSTOUT string==
*** 1868,1874 ****
      (RETURN
        (COND
          ((NULL |a|) (|shoeNotFound| |fn|) NIL)
!         ('T
           (SETQ |LETTMP#1|
                 (|shoePackageStartsAt| NIL (LENGTH |name|) |name|
                     (|shoeInclude|
--- 1957,1963 ----
      (RETURN
        (COND
          ((NULL |a|) (|shoeNotFound| |fn|) NIL)
!         (#0='T
           (SETQ |LETTMP#1|
                 (|shoePackageStartsAt| NIL (LENGTH |name|) |name|
                     (|shoeInclude|
*************** PSTOUT string==
*** 1878,1884 ****
           (COND
             ((|bStreamNull| |b|)
              (|shoeConsole| (CONCAT |name| " not found in " |fn|)) NIL)
!            ('T
              (COND
                ((NULL |lines|) (|shoeConsole| ")package not found")))
              (APPEND (REVERSE |lines|) (CAR |b|)))))))))
--- 1967,1973 ----
           (COND
             ((|bStreamNull| |b|)
              (|shoeConsole| (CONCAT |name| " not found in " |fn|)) NIL)
!            (#0#
              (COND
                ((NULL |lines|) (|shoeConsole| ")package not found")))
              (APPEND (REVERSE |lines|) (CAR |b|)))))))))
*************** PSTOUT string==
*** 1917,1925 ****
              (COND
                ((EQUAL (SYMBOL-PACKAGE |x|) |bt|)
                 (INTERN (PNAME |x|) |pk|))
!               ('T |x|)))
!            ('T |x|)))
!         ('T
           (CONS (|stripm| (CAR |x|) |pk| |bt|)
                 (|stripm| (CDR |x|) |pk| |bt|)))))))
  
--- 2006,2014 ----
              (COND
                ((EQUAL (SYMBOL-PACKAGE |x|) |bt|)
                 (INTERN (PNAME |x|) |pk|))
!               (#0='T |x|)))
!            (#0# |x|)))
!         (#0#
           (CONS (|stripm| (CAR |x|) |pk| |bt|)
                 (|stripm| (CDR |x|) |pk| |bt|)))))))
  
*************** PSTOUT string==
*** 1946,1952 ****
  
  (DEFUN FC (|name| |fn|)
    (PROG (|$GenVarCounter| |$bfClamming| |infn|)
!     (DECLARE (SPECIAL |$bfClamming| |$GenVarCounter|))
      (RETURN
        (PROGN
          (SETQ |$bfClamming| NIL)
--- 2035,2041 ----
  
  (DEFUN FC (|name| |fn|)
    (PROG (|$GenVarCounter| |$bfClamming| |infn|)
!     (DECLARE (SPECIAL |$GenVarCounter| |$bfClamming|))
      (RETURN
        (PROGN
          (SETQ |$bfClamming| NIL)
*************** PSTOUT string==
*** 1986,1992 ****
  
  (DEFUN PSTTOMC (|string|)
    (PROG (|$bfClamming| |$GenVarCounter|)
!     (DECLARE (SPECIAL |$GenVarCounter| |$bfClamming|))
      (RETURN
        (PROGN
          (SETQ |$GenVarCounter| 0)
--- 2075,2081 ----
  
  (DEFUN PSTTOMC (|string|)
    (PROG (|$bfClamming| |$GenVarCounter|)
!     (DECLARE (SPECIAL |$bfClamming| |$GenVarCounter|))
      (RETURN
        (PROGN
          (SETQ |$GenVarCounter| 0)
*************** PSTOUT string==
*** 2003,2009 ****
             (PROGN
               (WRITE-LINE "Boot Loop; to exit type ] ")
               (BOOTLOOP)))
!           ('T
             (PROGN
               (SETQ |b| (|shoePrefix?| ")console" |a|))
               (COND
--- 2092,2098 ----
             (PROGN
               (WRITE-LINE "Boot Loop; to exit type ] ")
               (BOOTLOOP)))
!           (#0='T
             (PROGN
               (SETQ |b| (|shoePrefix?| ")console" |a|))
               (COND
*************** PSTOUT string==
*** 2012,2018 ****
                        (PSTTOMC (|bRgen| |stream|))
                        (BOOTLOOP)))
                 ((EQUAL (ELT |a| 0) (ELT "]" 0)) NIL)
!                ('T (PROGN (PSTTOMC (LIST |a|)) (BOOTLOOP)))))))))))
  
  (DEFUN BOOTPO ()
    (PROG (|stream| |b| |a|)
--- 2101,2107 ----
                        (PSTTOMC (|bRgen| |stream|))
                        (BOOTLOOP)))
                 ((EQUAL (ELT |a| 0) (ELT "]" 0)) NIL)
!                (#0# (PROGN (PSTTOMC (LIST |a|)) (BOOTLOOP)))))))))))
  
  (DEFUN BOOTPO ()
    (PROG (|stream| |b| |a|)
*************** PSTOUT string==
*** 2022,2028 ****
          (COND
            ((EQL (LENGTH |a|) 0)
             (PROGN (WRITE-LINE "Boot Loop; to exit type ] ") (BOOTPO)))
!           ('T
             (PROGN
               (SETQ |b| (|shoePrefix?| ")console" |a|))
               (COND
--- 2111,2117 ----
          (COND
            ((EQL (LENGTH |a|) 0)
             (PROGN (WRITE-LINE "Boot Loop; to exit type ] ") (BOOTPO)))
!           (#0='T
             (PROGN
               (SETQ |b| (|shoePrefix?| ")console" |a|))
               (COND
*************** PSTOUT string==
*** 2031,2047 ****
                        (PSTOUT (|bRgen| |stream|))
                        (BOOTPO)))
                 ((EQUAL (ELT |a| 0) (ELT "]" 0)) NIL)
!                ('T (PROGN (PSTOUT (LIST |a|)) (BOOTPO)))))))))))
  
  (DEFUN PSTOUT (|string|)
!   (PROG (|$bfClamming| |$GenVarCounter|)
!     (DECLARE (SPECIAL |$GenVarCounter| |$bfClamming|))
      (RETURN
        (PROGN
          (SETQ |$GenVarCounter| 0)
          (SETQ |$bfClamming| NIL)
!         (|shoeConsoleTrees| (|shoeTransformString| |string|))))))
! 
  
  @
  \eject
--- 2120,2140 ----
                        (PSTOUT (|bRgen| |stream|))
                        (BOOTPO)))
                 ((EQUAL (ELT |a| 0) (ELT "]" 0)) NIL)
!                (#0# (PROGN (PSTOUT (LIST |a|)) (BOOTPO)))))))))))
  
  (DEFUN PSTOUT (|string|)
!   (PROG (|$bfClamming| |$GenVarCounter| |result| |callingPackage|)
!     (DECLARE (SPECIAL |$bfClamming| |$GenVarCounter|))
      (RETURN
        (PROGN
+         (SETQ |callingPackage| (PACKAGE-NAME *PACKAGE*))
+         (IN-PACKAGE 'BOOTTRAN)
          (SETQ |$GenVarCounter| 0)
          (SETQ |$bfClamming| NIL)
!         (SETQ |result|
!               (|shoeConsoleTrees| (|shoeTransformString| |string|)))
!         (IN-PACKAGE |callingPackage|)
!         |result|))))
  
  @
  \eject

\start
Date: Sat, 18 Nov 2006 12:10:45 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: branches/build-improvements/src

Gabriel Dos Reis wrote:
> False alarm -- they are built "early".  
> 
> However.
> 
> I think I have a better understanding than I had three hours ago.
> The last test I did was with revision 283.
> 
> In that revision, the whole AXIOMsys seems to be built twice:
> 
>   (1) once as usual
>       - then the testsuite is run
>   (2) and a second time
>       - this time it is not tested any more.
>       - this time, the other component are not built
>

For me that is not a new behaviour:  I have a build log from October 24
and I see this (I think I have seen this much earlier, but ATM I can not
find build logs).
 
> I think it is wrong not to test the second time AXIOMsys is built (it
> is the one that is installed).   We would need an explanation of why
> AXIOMsys needs to be built twice -- the first time it is tested, and the
> second time it is not.  
> 

The rule I added is run _before_ testing. However src/input/Makefile
contains the following (corresponging pamphlet is a mess):

TESTSYS=$(axiom_build_bindir)/interpsys

and later:

$(MID)/%.output: $(MID)/%.input
        (cd $(MID) ; \
        echo running test file $* ; \
        echo ')set message test on' > tmp.input; \
        echo ')set message auto off' >> tmp.input ; \
        echo ')read $*' >> tmp.input ; \
        echo ')lisp (bye)' >> tmp.input ; \
        echo 'systemCommand "read tmp.input"' | ${TESTSYS} | tee $*.output; \
        rm tmp.input )

So, src/input/Makefile deliberatly uses different image than the one
beeing installed (I do not think it is good idea -- just notice the
fact).


> The dependencies are wrong somewhere but I don't know yet where.
> Furthermore, I come realize that the rule
> 
>           (cd ../interp && $(ENV) $(MAKE) axiomsys)
> 
> is no good.  Because by the time the build flow reaches src/etc/ we may
> already have done lot of things on the way (and we do).  Now, it looks
> like src/etc wants to ask AXIOMsys to be rebuilt a second time,
> without necessarily "making" other things that might depend on it.
> That is no good.  We should not have the rule written that way.
> 
> I think we must take a step back and lay down what is that the patch
> is trying to achieve.  And do that in a more controlled way.
> Waldek?
>

The whole point is to cache databases into otherwise identical image.
AFAICS the way to do this it to repeat image building, but pointing
image at new databases.
 
> 
> 
> The "generic" errors from hyperdoc are  of the form:
> 
> --->/home/gdr/build/axiom/target/x86_64-suse-linux/../../src/algebra/ES.spad-->E
> xpressionSpace((odd? ((Boolean) %))): Unexpected HT command: \spad
> 
> These may actually be not related to the patch.  Sorry for that.
>

I have seen them for a long time.  The reasin is in the following
function:

buildHtMacroTable() ==
  $htMacroTable := MAKE_-HASHTABLE 'UEQUAL
  fn := CONCAT(getEnv '"AXIOM", '"/doc/hypertex/pages/util.ht")
  if PROBE_-FILE(fn) then
    instream := MAKE_-INSTREAM fn
    while not EOFP instream repeat
      line := READLINE instream
      getHtMacroItem line is [string,:numOfArgs] =>
        HPUT($htMacroTable,string,numOfArgs)
    for [s,:n] in $primitiveHtCommands repeat HPUT($htMacroTable,s,n)
  else
    sayBrightly '"Warning: macro table not found"
  $htMacroTable

This function is supposed to load macros from 'util.ht'.  But when
we do out of tree build 'util.ht' is unavailable during algebra
build (it is installed later).  Also, the path is now wrong and
I am not sure if AXIOM is set during build.

\start
Date: 18 Nov 2006 16:39:06 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: branches/build-improvements/src

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > False alarm -- they are built "early".  
| > 
| > However.
| > 
| > I think I have a better understanding than I had three hours ago.
| > The last test I did was with revision 283.
| > 
| > In that revision, the whole AXIOMsys seems to be built twice:
| > 
| >   (1) once as usual
| >       - then the testsuite is run
| >   (2) and a second time
| >       - this time it is not tested any more.
| >       - this time, the other component are not built
| >
| 
| For me that is not a new behaviour:  I have a build log from October 24
| and I see this (I think I have seen this much earlier, but ATM I can not
| find build logs).

That is not what I see from building any version before 266.

| > I think it is wrong not to test the second time AXIOMsys is built (it
| > is the one that is installed).   We would need an explanation of why
| > AXIOMsys needs to be built twice -- the first time it is tested, and the
| > second time it is not.  
| > 
| 
| The rule I added is run _before_ testing.

My build log says otherwise.
The second build happens long after the testsing, with:

   [...]
   preloading /home/gdr/build/axiom/target/i686-suse-linux/algebra/INT.o..loaded.
   preloading /home/gdr/build/axiom/target/i686-suse-linux/algebra/LIST.o..loaded.
   preloading /home/gdr/build/axiom/target/i686-suse-linux/algebra/OUTFORM.o..loaded.

Finished loading
/home/gdr/build/axiom/obj/i686-suse-linux/interp/makeint.lisp
6a /home/gdr/build/axiom/target/i686-suse-linux/bin/AXIOMsys created
make[5]: Leaving directory `/home/gdr/build/axiom/src/interp'
6 finished .
rm -f stamp
echo timestamp > stamp
[...]

After AXIOMsys is created, no test is run.


When build control reaches src/interp/ (right after it
leaves src/boot/), it goes on building the images:

   all-ax: $(MID) $(AUTO) stamp
           @echo 618 finished $(srcdir)

   stamp: $(MID) $(AUTO) remove-stamp build-images
           $(STAMP) stamp

Building images consists of building interpsys, AXIOMsys and debugsys.

    build-images: remove-stamp $(SAVESYS) $(DEBUGSYS)


Before your patch, building interpsys also builds AXIOMsys (which is a
copy of interpsys).  Why it must be a copy and not just the original
image, I don't know.  But that is what it is.  Now with your patch,
AXIOMsys is built differently from interpsys after interpsys, and
interpsys is tested but not AXIOMsys (which is installed).


| However src/input/Makefile
| contains the following (corresponging pamphlet is a mess):
| 
| TESTSYS=$(axiom_build_bindir)/interpsys
| 
| and later:
| 
| $(MID)/%.output: $(MID)/%.input
|         (cd $(MID) ; \
|         echo running test file $* ; \
|         echo ')set message test on' > tmp.input; \
|         echo ')set message auto off' >> tmp.input ; \
|         echo ')read $*' >> tmp.input ; \
|         echo ')lisp (bye)' >> tmp.input ; \
|         echo 'systemCommand "read tmp.input"' | ${TESTSYS} | tee $*.output; \
|         rm tmp.input )
| 
| So, src/input/Makefile deliberatly uses different image than the one
| beeing installed (I do not think it is good idea -- just notice the
| fact).

AXIOMsys and interpsys are supposed to be the same image -- that is
documented in src/interp/Makefile.pamphlet.  You and me may not like
it.  But when we make changes we must ensure that those invariants hold.  We
cannot just blame the existing the .  We know the existing

| > The dependencies are wrong somewhere but I don't know yet where.
| > Furthermore, I come realize that the rule
| > 
| >           (cd ../interp && $(ENV) $(MAKE) axiomsys)
| > 
| > is no good.  Because by the time the build flow reaches src/etc/ we may
| > already have done lot of things on the way (and we do).  Now, it looks
| > like src/etc wants to ask AXIOMsys to be rebuilt a second time,
| > without necessarily "making" other things that might depend on it.
| > That is no good.  We should not have the rule written that way.
| > 
| > I think we must take a step back and lay down what is that the patch
| > is trying to achieve.  And do that in a more controlled way.
| > Waldek?
| >
| 
| The whole point is to cache databases into otherwise identical image.
| AFAICS the way to do this it to repeat image building, but pointing
| image at new databases.

We must do that is a more controlled way.  Unfortunately, we can't
just do a "local" surgery with "goto" previous build.

I'll see.  Interpsys is not installed, I'll see whether its removal is OK.

| > The "generic" errors from hyperdoc are  of the form:
| > 
| > --->/home/gdr/build/axiom/target/x86_64-suse-linux/../../src/algebra/ES.spad-->E
| > xpressionSpace((odd? ((Boolean) %))): Unexpected HT command: \spad
| > 
| > These may actually be not related to the patch.  Sorry for that.
| >
| 
| I have seen them for a long time.  The reasin is in the following
| function:
| 
| buildHtMacroTable() ==
|   $htMacroTable := MAKE_-HASHTABLE 'UEQUAL
|   fn := CONCAT(getEnv '"AXIOM", '"/doc/hypertex/pages/util.ht")
|   if PROBE_-FILE(fn) then
|     instream := MAKE_-INSTREAM fn
|     while not EOFP instream repeat
|       line := READLINE instream
|       getHtMacroItem line is [string,:numOfArgs] =>
|         HPUT($htMacroTable,string,numOfArgs)
|     for [s,:n] in $primitiveHtCommands repeat HPUT($htMacroTable,s,n)
|   else
|     sayBrightly '"Warning: macro table not found"
|   $htMacroTable
| 
| This function is supposed to load macros from 'util.ht'.  But when
| we do out of tree build 'util.ht' is unavailable during algebra
| build (it is installed later).  Also, the path is now wrong and
| I am not sure if AXIOM is set during build.

Then, you have identifier (yet) another bug.  Thanks.

\start
Date: Sat, 18 Nov 2006 08:49:03 -0800 (PST)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: re: SPAD and Aldor again

--- Gabriel Dos Reis wrote:

> Cliff Yapp writes:

> OK, thanks for the explanation.
> 
> Since I'm not in the business of cloning Aldor, I'm not sure how that
> affects Axiom.

The discussions I am seeing so far seem to largely indicate that we
need to take SPAD in the direction Aldor went, at least to start with. 
This is not surprising as Aldor itself was intended to fix problems
with SPAD, as I understand the history.

> I don't see a point of cloning Aldor.  
> I see great benefits in an improved SPAD.

Certainly.  But an improved SPAD probably can't help but look something
like Aldor, since Aldor was in some sense an attempt to do a better
SPAD.
 
> | > You don't need a language to do *just* mathematics in Axiom.  You
> also
> | > need a language to communicate with the world around.  All major
> | > systems for computation mathematics have grown into that
> position.
> | > Don't get blindsighted.
> | 
> | I would prefer to let the Lisp level handle the outside world as
> | much as possible.
> 
> But you still need to specify what that does to a SPAD program.  Just
> delegating to Lisp does not solve the fundamental problem.

I guess it depends on the details of how such things are handled.  You
are proposing to have code at the SPAD level talk directly to things
like external libraries?  I guess my thought on that was to use
CFFI/other lisp tools to talk to the external libraries, and then use
the lisp level to present an API to them to SPAD.  Admittedly that's
rather vague, but hopefully we would only have to solve the SPAD<->Lisp
part of the equation and leave all the other messy details out of it.

> |  What are you referring to by communication?  Exporting
> | algorithms as Fortran code?  Interacting with C libraries?  File
> | and Data Input/Output APIs?
> 
> All of that, including interfacing with nay reasonable language used
> in the computational science community -- that list goes beyond
> Fortran and C.

Indeed.  C++, Java, Python, Haskell, CAML, ML, various proof
languages... more I'm sure that aren't leaping to mind.  You know more
about those things than I do Gaby, so perhaps the difficulties are less
severe than I am imagining, but I was under the impression that
translating from one language to another is highly non-trivial. 
Particularly if the program is written in such a way as to assume
communication only with other Java/C/ML/etc. programs.  Lisp's FFI
systems are probably among the most general solutions to such problems,
and even they have a host of issues.  And if we want to eventually
support formal verification and proof generation multiple languages
could exponentially complicate the question - in such circumstances we
would have to query libraries not just for functionality but for proof
that said functionality is correct - and how do we verify the proof
matches the implementation in an external library we may not even have
source code for?  md5 sums some kind?

I wish I knew more about such things.  I suppose at some level any
Turing complete language can express ideas expressed in other
languages, so perhaps there are techniques I'm not aware of.

\start
Date: 18 Nov 2006 18:21:00 +0100
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: SPAD and Aldor again

Cliff Yapp writes:

[...]

| I guess it depends on the details of how such things are handled.  You
| are proposing to have code at the SPAD level talk directly to things
| like external libraries?

My proposal is to formally specify a way for SPAD codes to talk to
external libraries.  I don't think such an interface must necessarily
be through Lisp first.

[...]

| > All of that, including interfacing with nay reasonable language used
| > in the computational science community -- that list goes beyond
| > Fortran and C.
| 
| Indeed.  C++, Java, Python, Haskell, CAML, ML, various proof
| languages... more I'm sure that aren't leaping to mind.  You know more
| about those things than I do Gaby, so perhaps the difficulties are less
| severe than I am imagining, but I was under the impression that
| translating from one language to another is highly non-trivial. 

I'm not saying it is trivial.  However, if we must attempt only
trivial things there is little hope to make Axiom interesting.  We must be
ambitious and approximate the ideals.

| Particularly if the program is written in such a way as to assume
| communication only with other Java/C/ML/etc. programs.  Lisp's FFI
| systems are probably among the most general solutions to such problems,
| and even they have a host of issues.

Lisp interface may be a proof-of-concept, but my belief is that it
should not be the final answer.

\start
Date: Sat, 18 Nov 2006 12:45:38 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: branches/build-improvements/src
Cc: Waldek Hebisch

On November 18, 2006 2:34 AM Gaby wrote:
> 
> Bill Page writes:
> 
> | 
> | Building Axiom twice is normal practice in order to obtain
> | optimized function calls in gcl.
> 
> Ahem, it is new -- not "normal" build process :-).  I believe the
> build system on trunk does not build twice.
>

I meant we have discussed this many times on this list (not
recently) and that others have experimented with such a build
process - in particular Camm in the Debian build of Axiom.
 
> | I did not notice this change
> | in Waldek's patch, but it is not unexpected to me. Perhaps
> | Waldek does this also because in the etc/Makefile he has just
> | re-built the databases. It is conceivable that new databases
> | could affect the code that is generated by the algebra compiles.
> 
> then the algebra files should be rebuilt, no?
> 

Yes, I think that might be necessary.

> | In fact, compiling twice also turns out to be the minimum
> | required due to some mutual dependencies that are not fully
> | resolved by the current bootstrap procedure. (See previous
> | discussion of the algebra fixed-point iteration tests that
> | I did over a year ago.) But that is a different issue.
> 
> if you're referring to the $boosttrap hack, yes, I believe that
> is a different issue.  It does not appear to me that this change
> is actually planned and intended by the patch.

No. I am referring to the fact that mutual dependencies in the
Algebra code are not fully satisfied by the current

  bootstrap (Lisp) -> rest of algeba -> bootstrap (spad)

process. It is necessary to add another iteration

        ... -> rest of algeba -> bootstrap (spad)

before the Lisp code that is generated from SPAD is the same
if the iteration is again repeated (SPAD/Lisp code generation
achieves a "fixed point").

> ...
> | 
> | I recall now that Camm Maquire did include the "compile Axiom
> | twice" optimization in the Debian build.
> 
> If we want to do that optimization, then we must build AXIOMsys
> only twice, I think.  And we must do the same step twice.  Here,
> the patch is doing something different the second time.

I agree.

> 
> | Indeed the build log shows that AXIOMsys is built twice
> | although the lisp source is not re-compiled which I believe
> | is required for the function call optimization.
> 
> Yes.
> 
> | (Full SPAD re-compile is required for the fixed-point solution.) 
> 
> that is true, but it is a different issue from the optimization.
> The full SPAD issue is there because because we have no way of
> extending domains gradually.

No. The SPAD issue is there because there are mutual dependencies.
Gradually extending domains does not solve this problem.

> ...
> | 
> | If we really want to do this optimization, then I guess you are
> | right that this patch needs to be re-evaluated.
> 
> I would suggest that we address the optimization latter -- put it
> on the list of README.build-improvements so that we don't forget 
> about it.
>

Yes. Good idea.
 
> | In order to do
> | the optimation, it is necessary to retain the *.NRLIB directories
> | and in particular the *.fn files which contain the necessary
> | "proclaim" information from the 1st build for use in the 2nd.
> | But the current build procedure deletes the NRLIBs doesn't it?
> 
> yes, it deletes the existing NRLIBs.  
> However, I'm not sure where whole SPAD needs to be recompiled, or
> only AXIOMSsys.   I believe it is AXIOMsys only.  In that case, we
> need to keep the previous .fn and .data files for latter use.  And
> it should be planned ahead.

Yes.

> 
> Given that, I would like to temporarilly revert the patch and
> work it out in fuller details.  Opinions?
> 

I believe the current patch is harmless when it comes to the
possible proclaim optimization and that it does achieve the goal
of database optimization (which is a separate issue). Personally
I don't see anything to gain by reverting it.

\start
Date: 18 Nov 2006 19:17:13 +0100
From: Francois Maltey
To: list
Subject: overwriting only few funtions in a package.

Hello, 

1/ Can I overwrite only few functions in a package ?

I want to keep exposed the built-in function 
  removeSinSq $ TranscendentalManipulations (Integer, Expression Interger)
and use my own function in my own package :
  expand $ UsualExpand (Integer, Expression Interger)

Is it possible ?

2/ I put this in my .axiom.input file, but it isn't perfect :

)cd
)cd Axiom
)library USEXPAND
)set expose add constructor UsualExpand
)set expose drop constructor TranscendentalManipulations

In this cas axiom uses the built-in expand. I can't do expand (cos (2*x)).

Then I reread the init file : )re ../.axiom.input
And then expand (cos (2*x)) uses the new package.

If I add a first line expand (cos (a+b)) in the init file, at the first line.
then it seems that axiom use the new expand.

But if I add expand (cos (a+b)) at the end of the init file,
then axiom calls the usual expand of TranscendentalManipulations.

Is it a bug ?

\start
Date: 18 Nov 2006 20:37:18 +0100
From: Martin Rubey
To: Francois Maltey
Subject: Re: overwriting only few funtions in a package.

Francois Maltey writes:

> Hello, 
> 
> 1/ Can I overwrite only few functions in a package ?
> 
> I want to keep exposed the built-in function 
>   removeSinSq $ TranscendentalManipulations (Integer, Expression Interger)
> and use my own function in my own package :
>   expand $ UsualExpand (Integer, Expression Interger)
> 
> Is it possible ?

This might be possible saying

UsualExpand(R, F) == TranscendentalManipulations(R, F) add

    expand(...) == ...

but I didn't try.

\start
Date: 18 Nov 2006 20:40:15 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: branches/build-improvements/src
Cc: Waldek Hebisch

Bill Page writes:

| On November 18, 2006 2:34 AM Gaby wrote:
| > 
| > Bill Page writes:
| > 
| > | 
| > | Building Axiom twice is normal practice in order to obtain
| > | optimized function calls in gcl.
| > 
| > Ahem, it is new -- not "normal" build process :-).  I believe the
| > build system on trunk does not build twice.
| >
| 
| I meant we have discussed this many times on this list (not
| recently) and that others have experimented with such a build
| process - in particular Camm in the Debian build of Axiom.

Aha, OK.

[...]

| > | In fact, compiling twice also turns out to be the minimum
| > | required due to some mutual dependencies that are not fully
| > | resolved by the current bootstrap procedure. (See previous
| > | discussion of the algebra fixed-point iteration tests that
| > | I did over a year ago.) But that is a different issue.
| > 
| > if you're referring to the $boosttrap hack, yes, I believe that
| > is a different issue.  It does not appear to me that this change
| > is actually planned and intended by the patch.
| 
| No. I am referring to the fact that mutual dependencies in the
| Algebra code are not fully satisfied by the current
| 
|   bootstrap (Lisp) -> rest of algeba -> bootstrap (spad)
| 
| process. It is necessary to add another iteration
| 
|         ... -> rest of algeba -> bootstrap (spad)
| 
| before the Lisp code that is generated from SPAD is the same
| if the iteration is again repeated (SPAD/Lisp code generation
| achieves a "fixed point").

If we had a way to gradually extend a domain, we would leave much of
the categories dragged in out form the bootstrapping process and add
them only for the purpose of building the installed alegbra.  No?

[...]

| > Given that, I would like to temporarilly revert the patch and
| > work it out in fuller details.  Opinions?
| > 
| 
| I believe the current patch is harmless when it comes to the
| possible proclaim optimization and that it does achieve the goal
| of database optimization (which is a separate issue). Personally
| I don't see anything to gain by reverting it.

It adds a confusion over an existing tower of confusions. 

Frankly, we all think that the current makefile is a mess.
Unfortunately, the patch adds to that mess even thought it originally
intended to do something good.

Yes, it optimizes the database build but it does not test the result.
I'm less concerned about not doing the proclaim optimization than
testing that nothing is broken by the database optimization.
My proposal is to achieve its goal in a more systematic way.  


This ultimately raised the issue of how to enforce testsuite and the
whole build process.  I don't have much time left this afternoon.  I
know of DejaGnu framework and the QMTest framework for running
testsuite.  I have far more extensive experience with DejaGnu than
with QMTest.  On the other hand, I'm pretty sure people would object
to DejaGnu for various reasons.

\start
Date: Sat, 18 Nov 2006 21:47:24 +0100
From: Gregory Vanuxem
To: Francois Maltey
Subject: Re: overwriting only few funtions in a package.

Le samedi 18 novembre 2006 =E0 19:17 +0100, Francois Maltey a =E9crit :
> Hello,
>
> 1/ Can I overwrite only few functions in a package ?
>
> I want to keep exposed the built-in function
>   removeSinSq $ TranscendentalManipulations (Integer, Expression Interg=
er)
> and use my own function in my own package :
>   expand $ UsualExpand (Integer, Expression Interger)
>
> Is it possible ?
>
> 2/ I put this in my .axiom.input file, but it isn't perfect :
>
> )cd
> )cd Axiom
> )library USEXPAND
> )set expose add constructor UsualExpand
> )set expose drop constructor TranscendentalManipulations
>
> In this cas axiom uses the built-in expand. I can't do expand (cos (2*x=
)).
>
> Then I reread the init file : )re ../.axiom.input
> And then expand (cos (2*x)) uses the new package.

I forgot how exactly Axiom behaves (my version of Axiom is modified in
some related regards), but try to play with frame. If I remember
correctly when you start Axiom via the axiom script you're working in
the frame 'frame0' (I'm sure of that). But your package is only exposed
in the first frame (via your commands in .axiom.input), try to switch to
the first frame (')frame next') for example. There are some bad
interactions between package exposition and what Axiom caches I think
(reswitch to frame0 and try to call a function from a non exposed
package but already called in the first frame for example).

> If I add a first line expand (cos (a+b)) in the init file, at the first=
 line.
> then it seems that axiom use the new expand.
>
> But if I add expand (cos (a+b)) at the end of the init file,
> then axiom calls the usual expand of TranscendentalManipulations.

Gni? This is strange, thanks for this information.

> Is it a bug ?

There are a lot...

\start
Date: Sat, 18 Nov 2006 21:50:22 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: branches/build-improvements/src
Cc: Waldek Hebisch

> This ultimately raised the issue of how to enforce testsuite and the
> whole build process.  I don't have much time left this afternoon.  I
> know of DejaGnu framework and the QMTest framework for running
> testsuite.  I have far more extensive experience with DejaGnu than
> with QMTest.  On the other hand, I'm pretty sure people would object
> to DejaGnu for various reasons.

Sorry, I don't know any of them, but for the Algebra part it might be 
possible to rewrite AldorUnit so that it could be used with Axiom and 
SPAD instead of Aldor.

http://www.risc.uni-linz.ac.at/software/aldor/

I could imagine that the rewrite should not be terribly hard.

\start
Date: Sat, 18 Nov 2006 15:54:38 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: branches/build-improvements/src
Cc: Waldek Hebisch

On November 18, 2006 2:40 PM Gaby wrote:

Bill Page wrote:
> ... 
> | No. I am referring to the fact that mutual dependencies in the
> | Algebra code are not fully satisfied by the current
> | 
> |   bootstrap (Lisp) -> rest of algeba -> bootstrap (spad)
> | 
> | process. It is necessary to add another iteration
> | 
> |         ... -> rest of algeba -> bootstrap (spad)
> | 
> | before the Lisp code that is generated from SPAD is the same
> | if the iteration is again repeated (SPAD/Lisp code generation
> | achieves a "fixed point").
> 
> If we had a way to gradually extend a domain, we would leave much
> of the categories dragged in out form the bootstrapping process
> and add them only for the purpose of building the installed
> alegbra.  No?

Yes, the bootstrap might be simpler however it would mean that we
would have to separate existing source code modules into multiple
modules, some of which extend others. But I don't think it would
solve the fundamental problem that there are some cycles of
module dependencies that are irreducibly mutually recursive. The
only way of solving this without iteration of the whole algebra
build would be if we could somehow locate all such dependencies
within a single modules and let the compiler solve the recursion.
I think that this might have been the strategy that the original
developers had in mind since Aldor is specifically able to compile
such code within a single module.

It is still not clear to me how the bootstrap mode flag might
help this situation. I think it would only permit the modules
to be pre-compiled in a more arbitrary order. They could then
be compiled "for real" in a second pass. The way Tim solved
this was to provide actual bootstrap code for selected modules
in the form of previously generated Lisp and then to compile
the rest of the modules in a carefully choosen order.

> 
> [...]
> 
> | > Given that, I would like to temporarilly revert the patch
> | > and work it out in fuller details.  Opinions?
> | > 
> | 
> | I believe the current patch is harmless when it comes to the
> | possible proclaim optimization and that it does achieve the
> | goal of database optimization (which is a separate issue).
> | Personally I don't see anything to gain by reverting it.
> 
> It adds a confusion over an existing tower of confusions. 
>

Ok. Maybe true. But as you said: documentation of what this is
doing is critical.
 
> Frankly, we all think that the current makefile is a mess.
> Unfortunately, the patch adds to that mess even thought it
> originally intended to do something good.
>

I am all for more simplicity but making something like the
Axiom build simple is likely to take a lot of time and some
more inspiration.
 
> Yes, it optimizes the database build but it does not test the
> result. I'm less concerned about not doing the proclaim
> optimization than testing that nothing is broken by the
> database optimization. My proposal is to achieve its goal
> in a more systematic way.  
>

Ok. I does make sense to me to treat optimization issues
in a different branch.
 
> 
> This ultimately raised the issue of how to enforce testsuite
> and the whole build process.  I don't have much time left this
> afternoon. I know of DejaGnu framework and the QMTest framework
> for running testsuite.  I have far more extensive experience
> with DejaGnu than with QMTest.  On the other hand, I'm pretty
> sure people would object to DejaGnu for various reasons.
> 

What reasons?

I took a quite look at DejaGnu.

http://www.gnu.org/software/dejagnu

I did not see anything to which I would immediately object.

\start
Date: 18 Nov 2006 22:53:50 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: branches/build-improvements/src
Cc: Waldek Hebisch

Ralf Hemmecke writes:

> > This ultimately raised the issue of how to enforce testsuite and the
> > whole build process.  I don't have much time left this afternoon.  I
> > know of DejaGnu framework and the QMTest framework for running
> > testsuite.  I have far more extensive experience with DejaGnu than
> > with QMTest.  On the other hand, I'm pretty sure people would object
> > to DejaGnu for various reasons.
> 
> Sorry, I don't know any of them, but for the Algebra part it might be possible
> to rewrite AldorUnit so that it could be used with Axiom and SPAD instead of
> Aldor.
> 
> http://www.risc.uni-linz.ac.at/software/aldor/
> 
> I could imagine that the rewrite should not be terribly hard.

I started to do it, no it doesn't seem to be hard. The main trouble is that we
would need to implement TextWriter, but that might be a good thing
anyway. Although I must say that I like OutputForm.

Unfortunately, the compiler segfaults over my modifications currently.

\start
Date: 18 Nov 2006 23:40:21 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: branches/build-improvements/src
Cc: Waldek Hebisch

Bill Page writes:

[...]

| > | > Given that, I would like to temporarilly revert the patch
| > | > and work it out in fuller details.  Opinions?
| > | > 
| > | 
| > | I believe the current patch is harmless when it comes to the
| > | possible proclaim optimization and that it does achieve the
| > | goal of database optimization (which is a separate issue).
| > | Personally I don't see anything to gain by reverting it.
| > 
| > It adds a confusion over an existing tower of confusions. 
| >
| 
| Ok. Maybe true. But as you said: documentation of what this is
| doing is critical.

yes.

| > Frankly, we all think that the current makefile is a mess.
| > Unfortunately, the patch adds to that mess even thought it
| > originally intended to do something good.
| >
| 
| I am all for more simplicity but making something like the
| Axiom build simple is likely to take a lot of time and some
| more inspiration.

Quite true :-)


[...]

| > This ultimately raised the issue of how to enforce testsuite
| > and the whole build process.  I don't have much time left this
| > afternoon. I know of DejaGnu framework and the QMTest framework
| > for running testsuite.  I have far more extensive experience
| > with DejaGnu than with QMTest.  On the other hand, I'm pretty
| > sure people would object to DejaGnu for various reasons.
| > 
| 
| What reasons?

I don't know -- this is Axiom ;-)

| I took a quite look at DejaGnu.
| 
| http://www.gnu.org/software/dejagnu
| 
| I did not see anything to which I would immediately object.

I'll give news on this front, later -- definitely, not today.

\start
Date: Sun, 19 Nov 2006 02:12:39 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: AxiomUnit
Cc: Waldek Hebisch

On 11/18/2006 10:53 PM, Martin Rubey wrote:
> Ralf Hemmecke writes:
> 
>>> This ultimately raised the issue of how to enforce testsuite and the
>>> whole build process.  I don't have much time left this afternoon.  I
>>> know of DejaGnu framework and the QMTest framework for running
>>> testsuite.  I have far more extensive experience with DejaGnu than
>>> with QMTest.  On the other hand, I'm pretty sure people would object
>>> to DejaGnu for various reasons.
>> Sorry, I don't know any of them, but for the Algebra part it might be possible
>> to rewrite AldorUnit so that it could be used with Axiom and SPAD instead of
>> Aldor.
>>
>> http://www.risc.uni-linz.ac.at/software/aldor/
>>
>> I could imagine that the rewrite should not be terribly hard.
> 
> I started to do it, no it doesn't seem to be hard. The main trouble is that we
> would need to implement TextWriter, but that might be a good thing
> anyway. Although I must say that I like OutputForm.
> 
> Unfortunately, the compiler segfaults over my modifications currently.

Why don't you open it then? Maybe Christian could also contribute. I 
don't see a repository.

BTW, which compiler segfaults?
Where you suggestion to use the Aldor compiler?

How would you see the big picture anyway? (How should 
AldorUnit/AxiomUnit work? How would input files look like? What would be 
generated? What would be compiled? What is a testsuite?)

\start
Date: 19 Nov 2006 05:50:50 +0100
From: Gabriel Dos Reis
To: list
Subject: Axiom on solaris 10

Hi Camm,

  I'm looking at the GCL bits of Bill's message

  http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00297.html


   bash-2.05$ diff -Naur gcl-2.6.8pre_orig gcl-2.6.8pre
   diff -Naur gcl-2.6.8pre_orig/h/solaris.defs
   gcl-2.6.8pre/h/solaris.defs
   --- gcl-2.6.8pre_orig/h/solaris.defs    2004-07-15 12:28:44.000000000
   -0400
   +++ gcl-2.6.8pre/h/solaris.defs 2006-09-12 13:15:58.280649000 -0400
   @@ -1,15 +1,18 @@

   -# notes for redhat 6.0
   -#  the configure should select the compiler
   GCC=/usr/bin/i386-glibc20-linux-gcc
   -#  However for the gcl-tk directory, you must use plain 'gcc' since
   -#  that must link with the tcl tk libs which have been compiled with
   it.
   -#  so after configure change to GCC=gcc in the gcl-tk/makefile
   +# notes for Solaris

   +# Machine dependent makefile definitions for Solaris 9, 10
   +# running a full GNU toolchain. This might not work on a
   +# pure Sun configuration.

   -# Machine dependent makefile definitions for intel 386,486 running
   linux
   +# Modified: Sept 12, 2006 Bill Page

    LBINDIR=/usr/local/bin

   +# We need these flags to get the right options for sockio.h
   +# and memalign
   +CFLAGS := ${CFLAGS} -DBSD_COMP=bsd_comp -DGNUMALLOC=gnumalloc
   +
    #OFLAG =  -g -Wall
    #OFLAG =  -g -Wall -fomit-frame-pointer -Werror
    #LIBS  = -lm

What would be your take on this? 

\start
Date: Sun, 19 Nov 2006 03:31:13 -0500
From: Tim Daly
To: list
Subject: bonn

Is there anyone on this list near Bonn, Germany? --t

\start
Date: Sun, 19 Nov 2006 16:02:14 +0600 (NOVT)
From: Andrey G. Grozin
To: Tim Daly
Subject: Re: bonn

On Sun, 19 Nov 2006, root wrote:
> Is there anyone on this list near Bonn, Germany? --t
I am in Karlsruhe, not quite near Bonn, but at least in Germany

\start
Date: 19 Nov 2006 11:19:05 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: AxiomUnit
Cc: Waldek Hebisch

Ralf Hemmecke writes:

> >> I could imagine that the rewrite should not be terribly hard.

> > I started to do it, no it doesn't seem to be hard. The main trouble is that
> > we would need to implement TextWriter, but that might be a good thing
> > anyway. Although I must say that I like OutputForm.  Unfortunately, the
> > compiler segfaults over my modifications currently.
> 
> Why don't you open it then? Maybe Christian could also contribute. I don't
> see a repository.

I can open a repository tomorrow. But I guess that my modifications were quite
stupid....
 
> BTW, which compiler segfaults?
aldor 1.0.3.

> Where you suggestion to use the Aldor compiler?

Yes. But this is governed by lack of time.

\start
Date: Mon, 20 Nov 2006 00:11:19 -0500
From: Bill Page
To: list
Subject: AxiomUnit, DejaGnu, and QMTest

The Axiom distributioin has a set of .input files that are run as
"regression tests" during the Axiom build, unfortunately there is
currently no facility for automatically checking the results of
these tests. Gaby has suggested DejaGnu and QMTest as possible
tools for automatically running these tests.

See:

http://www.gnu.org/software/dejagnu
http://www.codesourcery.com/qmtest

Ralf and Martin mentioned AldorUnit as possibly relevant and suggest
that AldorUnit could be re-implemented in SPAD for Axiom (AxiomUnit).
See:

http://www.risc.uni-linz.ac.at/software/aldor/project.php?id=AldorUnit

To better understand the issue I think we need to distinguish between
System Testing and Unit Testing:

http://en.wikipedia.org/wiki/Unit_testing
http://en.wikipedia.org/wiki/System_testing

>From my point of view the primary purpose of the Axiom .input files
and the DejaGnu and QMTest tools is System Testing. To this end,
these tools drive the complete system using a script and comparing
the computed results to the expected results.

Unit testing on the other hand is (usually) and integral part of
the development and usually consists of testing some module or
subroutine locally and in isolation from other units. AldorUnit is
an example of an application program interface (API) intended to
facilitate such tests. Typically one might write unit tests as
additional optional debugging code that tests for expected conditions
(assertions). The testing of these assertions might be enabled or
disabled at run-time or at build-time. Because the assertions are
checks only and are not needed to produce the desired results, they
are usually disabled when running the software in a "production"
mode. As far as I can see currently Axiom development does not
currently employ any unit tests in an essential way.

Unit testing and system testing are not alternatives but rather
should be used together at different stages in software development
and testing.

Regression testing is a part of both Unit and System tests:

http://en.wikipedia.org/wiki/Regression_testing

DejuGnu and QMTest support automated regression testing at the
System level.

DejuGnu also has the ability to drive unit tests through an API
for C++. It is possible to imagine that AxiomUnit could be written
in such as way that it could also be called within DejuGnu for
such tests.

As for objections to DejuGnu and QMTest, I see the following as
possibly significant:

1) DejuGnu depends on TCL this would introduce another dependency
   in the Axiom build environment.

2) Similarly QMTest is written in Python, which would also be a
   new dependency.

Personally I am not concerned about either of these issues.

As for choosing one over the other, QMTest has a nice web browser-
based graphical user interface and is said to work equally well on
Windows, MAC and Linux systems, while DejaGnu is possibly more
mature and integrates directly with the automake/autoconf tools.

Regards,
Bill Page.

On November 18, 2006 2:40 PM Gaby wrote:
> ...
> > 
> > This ultimately raised the issue of how to enforce testsuite
> > and the whole build process.  I don't have much time left this
> > afternoon. I know of DejaGnu framework and the QMTest framework
> > for running testsuite.  I have far more extensive experience
> > with DejaGnu than with QMTest.  On the other hand, I'm pretty
> > sure people would object to DejaGnu for various reasons.
> > 

On November 18, 2006 3:55 PM Bill Page wrote:
> 
> What reasons?
> 
> I took a quick look at DejaGnu.
> ... 
> I did not see anything to which I would immediately object.
> 

On November 18, 2006 3:50 PM Ralf Hemmecke wrote:
> ... 
> Sorry, I don't know any of them, but for the Algebra part it might
> be possible to rewrite AldorUnit so that it could be used with Axiom
> and SPAD instead of Aldor.
> 
> http://www.risc.uni-linz.ac.at/software/aldor/
> 
> I could imagine that the rewrite should not be terribly hard.
> 

On November 18, 2006 3:50 PM Martin Rubey wrote:
> 
> I started to do it, no it doesn't seem to be hard. The main 
> trouble is that we
> would need to implement TextWriter, but that might be a good thing
> anyway. Although I must say that I like OutputForm.
> 
> Unfortunately, the compiler segfaults over my modifications currently.
> 

\start
Date: Mon, 20 Nov 2006 09:49:43 +0100
From: Gernot Hueber
To: Gabriel Dos Reis
Subject: Re: SPAD and Aldor again

Hi there, 

With great help from Gregory, I have started to implement a wrapper library 
to access GSL (GNU scientific library) functions from Aldor/Axiom. I use the 
Lisp approach with dynamic loading of a shared library.
Yet some of the functions work fine - but there are far to many of them to 
cover them all for the moment. Furthermore, there are some unresolved 
problems (e.g. calling a Axiom/Aldor function from the library code). 

Gernot 

Gabriel Dos Reis writes: 

> Cliff Yapp writes: 
> 
> [...] 
> 
> | I guess it depends on the details of how such things are handled.  You
> | are proposing to have code at the SPAD level talk directly to things
> | like external libraries? 
> 
> My proposal is to formally specify a way for SPAD codes to talk to
> external libraries.  I don't think such an interface must necessarily
> be through Lisp first.

Pls tell me more. 

> 
> [...] 
> 
> | > All of that, including interfacing with nay reasonable language used
> | > in the computational science community -- that list goes beyond
> | > Fortran and C.
> | 
> | Indeed.  C++, Java, Python, Haskell, CAML, ML, various proof
> | languages... more I'm sure that aren't leaping to mind.  You know more
> | about those things than I do Gaby, so perhaps the difficulties are less
> | severe than I am imagining, but I was under the impression that
> | translating from one language to another is highly non-trivial.  
> 
> I'm not saying it is trivial.  However, if we must attempt only
> trivial things there is little hope to make Axiom interesting.  We must be
> ambitious and approximate the ideals.

agree, but things have to be practical, too. 

> 
> | Particularly if the program is written in such a way as to assume
> | communication only with other Java/C/ML/etc. programs.  Lisp's FFI
> | systems are probably among the most general solutions to such problems,
> | and even they have a host of issues. 
> 
> Lisp interface may be a proof-of-concept, but my belief is that it
> should not be the final answer.

\start
Date: 20 Nov 2006 02:55:31 -0600
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] espace multi-lines list in as.boot

bootsys is much pickier than depsys about multi-lines lists.  Either
they must be properly indented, or th end-of-line character must be
escaped. as.boot wasn't compliant.  Fixed.

-- Gaby

2006-11-20  Gabriel Dos Reis  Gabriel Dos Reis

	* as.boot.pamphlet (displayDatabase): Properly escape end-of-line
	in multi-line list.

*** as.boot.pamphlet	(revision 15238)
--- as.boot.pamphlet	(local)
*************** getAttributesFromCATEGORY catform ==
*** 241,257 ****
  displayDatabase x == main where
    main ==
      for y in
!      '(CONSTRUCTORFORM CONSTRUCTORKIND
!        CONSTRUCTORMODEMAP
!        ABBREVIATION
!        CONSTRUCTORCATEGORY
!        PARENTS
!        ATTRIBUTES
!        ANCESTORS
!        SOURCEFILE
!        OPERATIONALIST
!        MODEMAPS
!        SOURCEFILE
         DOCUMENTATION) repeat fn(x,y)
    fn(x,y) ==
      sayBrightly ['"----------------- ",y,'" --------------------"]
--- 241,257 ----
  displayDatabase x == main where
    main ==
      for y in
!      '(CONSTRUCTORFORM CONSTRUCTORKIND _
!        CONSTRUCTORMODEMAP _
!        ABBREVIATION _
!        CONSTRUCTORCATEGORY _
!        PARENTS _
!        ATTRIBUTES _
!        ANCESTORS _
!        SOURCEFILE _
!        OPERATIONALIST _
!        MODEMAPS _
!        SOURCEFILE _
         DOCUMENTATION) repeat fn(x,y)
    fn(x,y) ==
      sayBrightly ['"----------------- ",y,'" --------------------"]


\start
Date: 20 Nov 2006 10:11:28 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: AxiomUnit, DejaGnu, and QMTest

Bill Page writes:

> Ralf and Martin mentioned AldorUnit as possibly relevant and suggest that
> AldorUnit could be re-implemented in SPAD for Axiom (AxiomUnit).

Only I slight correction: I wouldn't reimplement AldorUnit in SPAD but rather
make it compatible with libaxiom. This would save a lot of time.

Just an idea: maybe we could offer Vladimir Bondarenko a bounty for porting
AldorUnit to libaxiom? I could explain him what is needed, and it shouldn't be
difficult at all. Maybe he can use some money? (I'd suggest 100$).

\start
Date: Mon, 20 Nov 2006 15:50:23 +0600 (NOVT)
From: Andrey G. Grozin
To: Gernot Hueber
Subject: re: SPAD and Aldor again

On Mon, 20 Nov 2006, Gernot Hueber wrote:
> With great help from Gregory, I have started to implement a wrapper library to
> access GSL (GNU scientific library) functions from Aldor/Axiom. I use the Lisp
> approach with dynamic loading of a shared library.
> Yet some of the functions work fine - but there are far to many of them to
> cover them all for the moment. Furthermore, there are some unresolved problems
> (e.g. calling a Axiom/Aldor function from the library code). 
Excellent news! Many thanks. We really need something to "replace" the NAG 
library in the free Axiom.

Just one important moment. GSL is GPL-licensed. So, Axiom wich can be 
linked with GSL (even dynamically) can only be distributed under GPL.

\start
Date: Mon, 20 Nov 2006 04:54:03 -0500
From: Tim Daly
To: Gernot Hueber
Subject: re: SPAD and Aldor again

Gernot,

> With great help from Gregory, I have started to implement a wrapper library 
> to access GSL (GNU scientific library) functions from Aldor/Axiom. I use the 
> Lisp approach with dynamic loading of a shared library.
> Yet some of the functions work fine - but there are far to many of them to 
> cover them all for the moment. Furthermore, there are some unresolved 
> problems (e.g. calling a Axiom/Aldor function from the library code). 

Could you post the patches necessary to make this work?
I have a thread of work similar to this and I'd like to see how you
are doing your version.

\start
Date: Mon, 20 Nov 2006 11:07:59 +0100
From: Gernot Hueber
To: Andrey G. Grozin
Subject: Re: SPAD and Aldor again

Hi, 

Andrey G. Grozin writes: 

> On Mon, 20 Nov 2006, Gernot Hueber wrote:
>> With great help from Gregory, I have started to implement a wrapper library to
>> access GSL (GNU scientific library) functions from Aldor/Axiom. I use the Lisp
>> approach with dynamic loading of a shared library.
>> Yet some of the functions work fine - but there are far to many of them to
>> cover them all for the moment. Furthermore, there are some unresolved problems
>> (e.g. calling a Axiom/Aldor function from the library code). 
> Excellent news! Many thanks. We really need something to "replace" the NAG 
> library in the free Axiom.
This was my intention. I missed some of the functions ... 


> 
> Just one important moment. GSL is GPL-licensed. So, Axiom wich can be 
> linked with GSL (even dynamically) can only be distributed under GPL.
Good point. The only necessary modification of Axiom is to use a 
dlopen/dlsym enhanced underlying gcl. I consider the remaining part of the 
wrapper (Lisp and Aldor code) as loadable plugin to Axiom. It is external 
and can be distributed separately. Sufficient? 

Furthermore, IMHO the key point is not the existing code (there is not much 
of it existing yet), but a strategy of how to integrate and call shared 
library C functions from Aldor/Axiom - for sure not a circumvent solution 
for any external library written in any language, but at least for some 
cases it works. 

\start
Date: Mon, 20 Nov 2006 05:42:38 -0500
From: Tim Daly
To: Gernot Hueber
Subject: re: SPAD and Aldor again

Gernot, Andrey,

Please see http://www.fsf.org/licensing/licenses/index_html

Note that Axiom is licensed under the Modified BSD and is
considered as a GPL compatible license by the Free Software Foundation.
In addition, I have had direct contact with Richard Stallman stating
that the licenses are compatible.

Please post any followup license-related discussion ONLY on the
axiom-legal mailing list. That list was established to remove any
discussion of licensing from the axiom-developer mailing list.

\start
Date: 20 Nov 2006 18:27:38 +0100
From: Francois Maltey
To: list
Subject: Can I define a function inside a function ?

Hello,

Can I have in a package a function which define an other function 
from its own parameters ? Why ?

---------------------------------------------------------------------------

I continue to search pretty expand, combine and rewrite functions over
expressions.

I have already defined a function expandONElevel for the main level
of an expression. 

It's possible to write a recursive map over Expressions 

But how can I utilize it for a recursive map ?

I want to compile, but I can't :

expand (x, MainParameters) ==
  fct1 y == expandONElevel (y, FromMainParameters)
  expandONElevel (recursiveMap (x, fct1))

---------------------------------------------------------------------------

I can compile a such example but I get internal error when I test it.

I can't write the fct1 function outside the expand function
because I need data from mainParameters.

Here is a minimal? package.

I compile it with a warning : 

; (DEFUN |ESS,mapRec;fct2| ...) is being compiled.
;; The variable |fct| is undefined.
;; The compiler will assume this variable is a global.
------------------------------------------------------------------------

In the interpreter I add 
  df (x : Expression Integer) : Expression Integer == 2*x

mapRecA... mapRecE are right, but I can't use mapRec.

this test fails : mapRec (sin (3*x)+12*cos(5*exp (y)), df)

   Internal Error
   The function mapRec with signature hashcode is missing from domain
      EssaiMapRec(Integer)(Expression (Integer))

-------------------------------------------------------------------
)abbrev package ESS EssaiMapRec

EssaiMapRec (R, F): Exports == Implementation where
  R : Join(OrderedSet, GcdDomain)
  F : Join(FunctionSpace R, TranscendentalFunctionCategory)

  K       ==> Kernel F                             
  P       ==> SparseMultivariatePolynomial (R, K)  

  Exports ==> with
    mapRecA      : F -> F 
    mapRecB      : F -> F 
    mapRecC      : F -> F 
    mapRecD      : F -> F 
    mapRecE      : F -> F 
    mapRec       : (F, F-> F) -> F 

  Implementation ==> add

    import PolynomialCategoryLifting (IndexedExponents K, K, R, P, F)
    fctB : K -> F
    fctC : K -> F
    fctD : K -> F
    fctE : K -> F

    mapRecA x == 
      map (#1::F, #1::F, numer x) / map (#1::F, #1::F, denom x) 

    mapRecB x == 
      map (fctB, #1::F, numer x) / map (fctB, #1::F, denom x) 

    fctB k == sin (2::Integer::R::F)

    mapRecC x == 
      map (fctC, #1::F, numer x) / map (fctC, #1::F, denom x) 

    fctC k ==
      nullary? (op := operator k) => k::F
      arg := first argument k
      (sin (arg))::F

    mapRecD x == 
      map (fctD, #1::F, numer x) / map (fctD, #1::F, denom x) 

    fctD k ==
      nullary? (op := operator k) => k::F
      arg := first argument k
      (sin (mapRecD arg))::F

    mapRecE x == 
      map (fctE, #1::F, numer x) / map (fctE, #1::F, denom x) 

    fctE k == 2::R::F * k::F

    mapRec (x, fct) == 
      fct2 (y:K):F == fct (y::F)
--      fct2 (y:K):F == x * fct (y::F) 
      map (fct2, #1::F, numer x) / map (fct2, #1::F, numer x) 

\start
Date: 20 Nov 2006 19:41:01 +0100
From: Gabriel Dos Reis
To: Francois Maltey
Subject: Re: Can I define a function inside a function ?

Francois Maltey writes:

| Hello,
| 
| Can I have in a package a function which define an other function 
| from its own parameters ? Why ?
| 
| ---------------------------------------------------------------------------
| 
| I continue to search pretty expand, combine and rewrite functions over
| expressions.
| 
| I have already defined a function expandONElevel for the main level
| of an expression. 
| 
| It's possible to write a recursive map over Expressions 
| 
| But how can I utilize it for a recursive map ?
| 
| I want to compile, but I can't :
| 
| expand (x, MainParameters) ==
|   fct1 y == expandONElevel (y, FromMainParameters)
|   expandONElevel (recursiveMap (x, fct1))

Did you try

   expand (x, MainParameters) ==
     expandONElevel(recursiveMap, x, ftc1) where
        fct1 y == expandONElevel(y, FromMainParameters)

\start
Date: 20 Nov 2006 13:30:38 -0600
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] extend scripts/document

Hi,

  bootsys has the property that when the input file is malformed, 
it will print out an diagnostic message, partially translate the
input file, prints out a nice message "blah PRODUCED" and return an
exit status 0, as if everything was OK.  That of course asks for 
disaster.

  There are various ways to fix that problem.  One is to modify the
lisp image to propagate back exit status.  Another is work around the
existing behavior by "watching" for the "right" diagnostic messages.
The machinery to do that in the current makefiles started getting
messier with that approach, in addition of duplication.  Consequently,
I abstracted the apparatus and moved it to document.  

  With this patch, we can now translate Boot source code as

    document --tag=boot --mode=translate bootsys foo.boot

of compile a Lisp source file as

    document --tag=lisp --mode=compile gcl foo.lisp

We could get fancier things, but I thought I should just check in the
basic functionality and refine later as needs arise.

-- Gaby

2006-11-20  Gabriel Dos Reis  Gabriel Dos Reis

	* document.in: Extend to handle --mode, and --tag for translation
	and compilation of Boot and Lisp codes.

*** document.in	(revision 16902)
--- document.in	(local)
***************
*** 1,12 ****
  #!/bin/sh
  
  # usage:
! #    document --latex file
! #    document --weave file.pamphlet
! #    document --weave --latex file.pamphlet
! #    document --tangle file.pamphlet
! #    document --tangle=chunk --output=fileout filein.pamphlet
! #   [ plus any legacy usage ]
  
  
  # set -x
--- 1,29 ----
  #!/bin/sh
  
  # usage:
! #    document [options] file
! #    [ plus any legacy usage ]
! #
! # options:
! #    --index
! #       Run makeindex on the input file
! #
! #    --latex
! #       Typeset input file assuming it a LaTeX file
! #
! #    --output=outfile
! #       Set the output filename.
! #
! #    --tangle
! #    --tangle=chunk
! #       Run notangle on the input file assumed to be a pamphlet.
! #
! #    --weave 
! #       Run noweave on the input file assumed to be a pamphlet
! #       When combined with --output, also run latex.
! #    --
! #       Anything that comes after is treated as an argument, even
! #       if it looks like an option
  
  
  # set -x
*************** export TEXINPUTS
*** 22,27 ****
--- 39,85 ----
  BIBINPUTS=.:@axiom_builddir@/share/texmf/tex:$BIBINPUTS
  export BIBINPUTS
  
+ # Issue a diagnostic message and exit with non-zero status.
+ error() {
+     echo "error: $1"
+     exit 1
+ }
+ 
+ # Issue a diagnostic if an option ($1) requires a argument
+ # and its value ($2) is empty.
+ maybe_missing_value_for() {
+     if test -z $2; then
+ 	error "missing value for $1"
+     fi
+ }
+ 
+ # Check validity of --tag.  At the moment
+ # we support only "boot" and "lisp"
+ check_tag_value() {
+     case $1 in
+ 	boot|lisp) 
+            tag=$1
+            ;;
+ 	*)
+ 	   error "invalid tag $1"
+ 	   ;;
+     esac
+ }
+ 
+ # Validate argument for --mode.  We support only
+ #  - "compile", for Lisp source file
+ #  - "translate", for Boot source file
+ check_mode_value() {
+     case $1 in
+ 	compile|translate)
+            mode=$1
+ 	   ;;
+ 	*)
+ 	   error "invalid mode $1"
+ 	   ;;
+     esac
+ }
+ 
  
  do_index=
  do_latex=
*************** do_weave=
*** 30,78 ****
  chunk=
  file=
  output=
  
! while : ; do
!     case $1 in
  	--weave)
  	   do_weave=yes
- 	   shift
  	   ;;
  
          --latex)
  	   do_latex=yes
- 	   shift
             ;;
  
          --index)
  	   do_index=yes
  	   # FIXME: --index may be used only with --latex.  Check.
- 	   shift
             ;;
  
- 	--tangle=*)
- 	   do_tangle=yes
- 	   chunk=`echo $1 | awk -F'=' '{ print $2; }'`
- 	   shift
- 	   ;;
- 
  	--tangle)
  	   do_tangle=yes
  	   # --tangle may not be combined with any other
  	   # options.  FIXME:  Check that. 
- 	   shift
  	   ;;
  
! 	--output=*)
! 	   output=`echo $1 | awk -F'=' '{ print $2; }'`
! 	   shift
  	   ;;
  
  	--*)
! 	   echo unrecognized option $1
  	   exit 1
  	   ;;
- 
-         *) break ;;
      esac
  done
  
--- 88,160 ----
  chunk=
  file=
  output=
+ tag=
+ mode=
  
! while test $# -gt 0 ; do
!     optval=$1
! 
!     case $optval in
! 	--)
! 	   break
! 	   ;;
! 	--*=*)
! 	   arg=`echo $optval | sed -e 's/^[-a-zA-Z]*=//'`
! 	   opt=`echo $optval | sed -e 's/=.*$//'`
! 	   shift;
! 	   ;;
! 	--*)
! 	   opt=$optval
! 	   arg=
! 	   shift
! 	   ;;
! 	*)
! 	   break
! 	   ;;
!     esac
! 
!     case $opt in
  	--weave)
  	   do_weave=yes
  	   ;;
  
          --latex)
  	   do_latex=yes
             ;;
  
          --index)
  	   do_index=yes
  	   # FIXME: --index may be used only with --latex.  Check.
             ;;
  
  	--tangle)
  	   do_tangle=yes
+ 	   if test -n $arg; then
+ 	       chunk=$arg
+ 	   fi
  	   # --tangle may not be combined with any other
  	   # options.  FIXME:  Check that. 
  	   ;;
  
! 	--output)
! 	   maybe_missing_value_for $opt $arg
! 	   output=$arg
! 	   ;;
! 
! 	--tag)
! 	   maybe_missing_value_for $opt $arg
! 	   check_tag_value $arg
! 	  ;;
! 	
! 	--mode)
!  	   maybe_missing_value_for $opt $arg
! 	   check_mode_value $arg
  	   ;;
  
  	--*)
! 	   echo unrecognized option $opt
  	   exit 1
  	   ;;
      esac
  done
  
*************** if test x$do_latex = xyes; then
*** 118,123 ****
--- 200,233 ----
      exit $?
  fi
  
+ # We only support translation of Boot source files, and
+ # compilation of Lisp source files
+ case $mode,$tag in
+     translate,boot)
+        cmd=$1
+        shift
+        
+        # The bootsys image is currently unable to pass up an
+        # exit status that we can hand to the shell.  When an error
+        # occurs, bootsys just prints a message and exits as if 
+        # everything went well.  To work around that, we have to 
+        # capture its output, look for specific patterns, and then
+        # return an appropriate exit status.
+        tmpfile=`mktemp document.XXXXXX` || exit 1
+        trap "rm -f $tmpfile" 1 2 15
+        echo \(boottran::boottoclc \"$1\"\) | $cmd | tee $tmpfile
+        grep 'ERROR IN' $tmpfile >/dev/null && { rm $tmpfile; exit 1; }
+        rm $tmpfile && exit 0
+        ;;
+ 
+     compile,lisp)
+        cmd=$1
+        shift
+        echo \(compile-file \"$1\" :output-file \"$output\"\) | $cmd
+        exit $?
+        ;;
+ esac
+ 
  
  if [ "$#" = "3" ]; then
   REDIRECT=$2

\start
Date: Mon, 20 Nov 2006 14:41:38 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: [build-improvements] extend scripts/document

>   bootsys has the property that when the input file is malformed, 
> it will print out an diagnostic message, partially translate the
> input file, prints out a nice message "blah PRODUCED" and return an
> exit status 0, as if everything was OK.  That of course asks for 
> disaster.

this was a known problem. the fix for it was to generate a final
comment in the output file. The build process checks used to
check each generated file for that comment line and fail if it
was not found. 

\start
Date: 20 Nov 2006 21:22:10 +0100
From: Francois Maltey
To: list
Subject: Re: Can I define a function inside a function ?

Hello, again and thanks a lot for this good advice !

> Did you try
> 
>    expand (x, MainParameters) ==
>      expandONElevel(recursiveMap, x, ftc1) where
>         fct1 y == expandONElevel(y, FromMainParameters)

I can compile this function mapRec, but the compile rejects all tries
with fct or ftest (in the definition of the mapRec) in fct2.


    mapRec (x, fct, ftest) ==
      map (fct2, #1::F, numer x) / map (fct2, #1::F, denom x) 
       where 
        fct2 (y:K):F == 
          nullary? (op := operator y) => y::F
--          fct (first argument y)
--          L := [fct z for z in argument y]$List F
          op (argument y)
          ftest y => y::F
          y::F

And I can compile it : 
The variables are local inside the mapRec, they are not parameters.
It's like Maple ;-(

    mapRec (x, fct, ftest) ==
      fct1 := fct
      ftest1 := ftest 
      map (fct2, #1::F, numer x) / map (fct2, #1::F, denom x) 
       where 
        fct2 (y:K):F == 
          nullary? (op := operator y) => y::F
          ftest1 y =>  op (map (fct1, argument y))
          y::F

But I can't with     op [fct1 z for z in argument y]. 
I must type          op (map (fct1, argument y))

And I don't understand this last difference...

\start
Date: 20 Nov 2006 23:14:11 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [build-improvements] extend scripts/document

Tim Daly writes:

| >   bootsys has the property that when the input file is malformed, 
| > it will print out an diagnostic message, partially translate the
| > input file, prints out a nice message "blah PRODUCED" and return an
| > exit status 0, as if everything was OK.  That of course asks for 
| > disaster.
| 
| this was a known problem. the fix for it was to generate a final
| comment in the output file. The build process checks used to
| check each generated file for that comment line and fail if it
| was not found. 

OK -- was that documented somewhere?
Now we have document takes care of that by looking at the output and
do the right thing.  I can testify it was quite effective.  The other
thing I'm not testing yet is when it says that a file is not found.  I
left that for later refinement.

\start
Date: Mon, 20 Nov 2006 17:23:20 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: [build-improvements] extend scripts/document

in src/interp/bootlex.lisp you'll see the comment output
  ;;;Boot translation finished for ~a

this is written out if the file is successfully translated.
if the translation fails this line will not exist.
if a grep for this line fails then the translation failed.

\start
Date: 20 Nov 2006 23:52:52 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [build-improvements] extend scripts/document

Tim Daly writes:

| in src/interp/bootlex.lisp you'll see the comment output
|   ;;;Boot translation finished for ~a

Aha, I was working with src/boot ! :-)

So, there effectively is no way to return a meaningful exit status?

\start
Date: Tue, 21 Nov 2006 01:47:15 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: SF.net SVN: axiom:

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | Gabriel Dos Reis wrote:
> | > False alarm -- they are built "early".  
> | > 
> | > However.
> | > 
> | > I think I have a better understanding than I had three hours ago.
> | > The last test I did was with revision 283.
> | > 
> | > In that revision, the whole AXIOMsys seems to be built twice:
> | > 
> | >   (1) once as usual
> | >       - then the testsuite is run
> | >   (2) and a second time
> | >       - this time it is not tested any more.
> | >       - this time, the other component are not built
> | >
> | 
> | For me that is not a new behaviour:  I have a build log from October 24
> | and I see this (I think I have seen this much earlier, but ATM I can not
> | find build logs).
> 
> That is not what I see from building any version before 266.
>

Running:

grep -n '^\(1 making a \|37 making \|4 rebuilding databases\|29 making \|.*regression-tests\|.*make axiomsys\)' mlogg

(where mlogg is caputred output from make) gives me:

5131:29 making ./algebra
8911:37 making /var/tmp/hebisch/axp19/ax-build1/int/etc
8914:4 rebuilding databases...
14399:(cd ../interp &&  make axiomsys)
16152:make DAASE=/var/tmp/hebisch/axp19/ax-build1/target/x86_64-unknown-linux regression-tests
97009:1 making a x86_64-unknown-linux system, PART=cprogs SUBPART=everything
97528:29 making ./algebra
97620:37 making /var/tmp/hebisch/axp19/ax-build1/int/etc
97622:(cd ../interp &&  make axiomsys)
97989:make DAASE=/var/tmp/hebisch/axp19/ax-build1/target/x86_64-unknown-linux regression-tests

Before version 266 I saw almost the same picture: only the 'make axiomsys'
lines were missing. As you can see the build process is run twice,
including the rule that I added.  We enter input directory twice,
each time after building AXIOMsys.  Why we do not run regression-tests
the second time?  Well, that is usual make logic: since .output files
depend only on .input and miss dependency on ${TESTSYS} make thinks
that .output files are up to date and do not regenerate them. 

AFAICS we run the build process twice because of top level Makefile
rules:

all-ax:
        @ echo 1 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
        @ echo 2 Environment ${ENV}
        @ $(MAKE) stamp-rootdirs
        @ ${ENV} $(MAKE) $(src_stamp)
        @echo 3 finished system build on `date` | tee >lastBuildDate

....

$(src_stamp): $(lsp_stamp)
        cd $(build_srcdir) && $(ENV) $(MAKE)

So we first enter src directory from the recursive part and then the
second time from $(src_stamp) rule.  If you want to avoid second
build just remove the stamp parts from 'all-ax' rule.

Another question is why anything gets rebuild during second run?
interpsys is re-build due to dependency:

$(SAVESYS): $(axiom_build_bindir)


building interpsys changes timestamp of $(axiom_build_bindir) and
triggers re-building of interpsys on the next run.  After removal
of this rule (and stamps part from 'all-ax' rule) re-running make
(with onchanged source directory) did not rebuild anything.


> Before your patch, building interpsys also builds AXIOMsys (which is a
> copy of interpsys).  Why it must be a copy and not just the original
> image, I don't know.  But that is what it is.  Now with your patch,
> AXIOMsys is built differently from interpsys after interpsys, and
> interpsys is tested but not AXIOMsys (which is installed).
> 

We can easily change input Makefile to test AXIOMsys.  We also
may add dependency on AXIOMsys, so that test are re-run when
AXIOMsys changes.  However, I think we should _not_ run the
tests after re-making AXIOMsys: tests take 15-20 minutes to
run and that IMHO is unacceptable during developement.  In other
words, during developement tests must run exactly when requested.

I think we should have a separate target to build, latex things
and run test and a sepatate target for developement.  I would
prefer to use plain 'make' as a developement target (plus
'make dvi' and 'make check') and 'make build' as a shorthand
for 'make && make dvi && make check', but other arrangements
are also acceptable.

\start
Date: Tue, 21 Nov 2006 02:19:48 -0500
From: Tim Daly
To: list
Subject: Original distribution

http://daly.axiom-developer.org/NAGcdrom.tgz

This is a copy of the original CD from NAG marked "Open Axiom Sources".
There are portions of the distribution I've not yet had time to reach.
It might also have some utilities for Waldek's hypertex work.

Gaby, you might want to put this in SVN.

\start
Date: Tue, 21 Nov 2006 02:32:54 -0800
From: Antoine Hersen
To: Gabriel Dos Reis
Subject: re: SPAD and Aldor again

Hello,

My personal experience with Aldor/Axiom Aldor/Algebra, is that
everything that is a bit complicated tend to break miserably. Not only
Aldor Axiom incomparability, but Aldor with libAlgebra.

The compiler is broken, optimization break semantic, some code will
work in O1 not in O2 and vice versa, O3 and O4 can make for some very
efficient optimization that just decide that you code is better left
un executed, faster indeed.
Also seen : incorrect biding of variable, this one was a joy to debug(
Ralf catch it thanks)

I just had a glance at the Aldor source code and no salvation will
come from having it release I guaranty, just a lot of old and lightly
documented C code.

My experience with Aldor is that it obey the principle of maximum
surprise and minimum code productivity.
But it made me happy to code in PPC assembler again, at least the
semantic is clear and debugging is a bliss.

To be honest most of my difficult come from the fact that I am used to
code in ML and I have a functional style that Axiom does not support
really well, anonymous function, and curry style function definition
are a sure way to break stuff.

I personally will not try to implement any new math in Axiom, till the
compiler is in better shape. The good news is that I do believe in the
underlying approach and that being a Comp Sci grad student I might
even be able to do something about it.

Since time to hope for Aldor release has pass, I agree that we should
concentrate on SPAD+,++,prime,#,2006.

I think that Aldor backward combability is not important, since we do
not have libAlgebra or SumIT.
LibAlgebra has tones of copyright in it, from a lot of institution and
individuals. Also merging it with axiom algebra will be quite
difficult. My exploration of the multivariate polynomials
implementation make me believe that libAlgebra is nicer but the
documentation is quite out of sync and a lot is missing.
I never seen SumIT so cant say.

I think the language need to be clearly defined, maybe not a complete
semantic a la SML but at least something precise like the Haskell
report.
We need to be able to decide if it is sound enough and co.

>From a theoretical aspect of SPAD', dependent type seem a must to
accommodate the problem of doing a descent job at representing
mathematics.
But there is dependent type and dependent type, I am in the process of
getting informed about it I got my hand on Pierce thank to inter
library loans, and I am having a look at epigram which I believe is
the only language alive that is implementing depend type.

I would like SPAD' to have a more functional flavor to it( personal taste)

Good news with depend type no need for polymorphisms or GADT !!!

Algebraic type will be great !!! but I guess we will also need pattern
matching to make good use of them.

Also some type inference( I dont mean auto coercion) will be helpful.

For the monoid problem I guess we need something like chapter 6 of
Nicolas Doye PhD thesis.

Also should coercion have a special semantic ?

What to do about Rep ? I dont like it at all, why cant I have
arbitrary number of instance variables named like I want.

I am personally worried about the current :
(that is broken in Aldor and required the horrible "pretend" aka cast)

"if xValue has someSubtype then
	ADT signature extention"

Can we do that in the SML module system with functors ? I should know this :(
( I think I have read that with dependent type we get SML module for free )

Also we have it as control flow in function definition.
"if xValue has someSubtype then"

what about :

"if someType has someSubType then" ?

What are the valuable lesson from SML module system, Haskell type
class, and C++ template  we can use ?

I know there is some effort to improve C++ template system, I guess
Gabriel is quite informed on the subject ?

Should we incorporate axioms for our far away dream of proof checking ?
Before having a proof we could use them for QuickCheck like testing
without too much work.


On a practical point of view.
For me the highest importance will be good error messages during
compilation and possibility of debugging after.
I remember to be quite frighten by SPAD error messages, this being the
reason I switched to Aldor.

I know that compiler book are more interested in advanced optimization
method than good error messages but my own experience in developing a
toy ML language to assembler compiler in Haskell is that monads make
it almost easy, I guess Ocaml error system should make it manageable
too.

I think speed is not important, modern computer are so fast and have
so much memory.( And if we are to plan for speed automatic parallelism
seem the direction of the future but SPAD heavy use of reference will
make it difficult, mabe == should be the rule and := the exception )

FOAM is dead since Axiom doest no understand it.
We still need some intermediary representation, maybe simply lisp.
(Is getting rid of boot still on the agenda ?)

Also I feel that depend type will ask a lot from the runtime system to
do some late type checking.

We do need a FFI interface in the language in someway, maybe Lisp
should provide it but it should be apparent in SPAD'. We should be
able to use http://www.swig.org/.
I dont personal feel the need for FORTRAN by I understand why it will
be important for a CAS.
Having a C interface is of course primordial.

On the syntax side, I am not very found of indentation based syntax,
it work without trouble with haskell and python because they have good
emacs mode but that alway gave me trouble in SPAS, can we have both(
indentation and bracket) like Haskell ? So no need for an holy war.

I guess language design is quite difficult and it is important to know
what kind of problems we need to solve.

My keys test problems will be multivariate polynomials, ore
polynomials, a graph library( data and algebraic), combinat and a
plotting library. I think that it has to be possible to create an
elegant implementation in SPAD' to those problems.


I am motivated, who want a PhD student ?

\start
Date: Mon, 20 Nov 2006 23:36:22 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: [build-improvements] extend scripts/document

> | in src/interp/bootlex.lisp you'll see the comment output
> |   ;;;Boot translation finished for ~a
> 
> Aha, I was working with src/boot ! :-)
> 
> So, there effectively is no way to return a meaningful exit status?

fgrep returns -1 if it fails :-)
no, we hacked up this method and it worked.

there is no documentation because (a) documentation was considered
an afterthought for "the user" and (b) such a simple change wouldn't
be worth commenting on even if it was worth changing the code.

this goes to the very heart of my diatribes on literate programming.
the lesson is painful to put into practice on a daily basis, looking
like some horrible form of overkill and time-wasting  but glaringly 
obvious from a distance of years.

\start
Date: 21 Nov 2006 13:15:40 +0100
From: Francois Maltey
To: Francois Maltey
Subject: Re: Am I buggy ? Internal error...

Here is a minimal package which recursively maps an expression.
I can compile it on the silver branch, but I can't use it.

In the interpreter I test :

EI := Expression Integer
pp (x:EI) : EI == x+1
mapRec (sin (sin x), pp)
-----------------------------------------------------------------
)abbrev package ESS EssaiMapRec

EssaiMapRec (R, F): Exports == Implementation where
  R : Join(OrderedSet, GcdDomain)
  F : Join(FunctionSpace R, TranscendentalFunctionCategory)

  K       ==> Kernel F                             
  P       ==> SparseMultivariatePolynomial (R, K)  

  Exports ==> with
    mapRec      : (F, F -> F) -> F

  Implementation ==> add

    import PolynomialCategoryLifting (IndexedExponents K, K, R, P, F)

    mapRec (x, fct) ==
-- in must use a new variable fct1 because I can't compile with fct in fct3
      fct1 := fct
      fct (map (fct2, #1::F, numer x) / map (fct2, #1::F, denom x))
       where 
        fct3 (xx:F):F == mapRec (xx, fct1)
        fct2 (y:K):F == 
          nullary? (op := operator y) => y::F
          op (map (fct3, argument y))

\start
Date: 21 Nov 2006 14:50:01 +0100
From: Gabriel Dos Reis
To: Antoine Hersen
Subject: re: SPAD and Aldor again

Antoine Hersen writes:

[...]

| 
| I would like SPAD' to have a more functional flavor to it( personal taste)
| 
| Good news with depend type no need for polymorphisms or GADT !!!

I believe there is place for both.

| Algebraic type will be great !!! but I guess we will also need pattern
| matching to make good use of them.

Algebraic types without pattern matching is close to useless.  Boot
(src/boot) has a primitive support for algebraic types and pattern
matching. Its "case expression" is what you would expect.  I've been trying
to figure out a way to get it work in SPAD without breaking the
current syntax and semantics of SPAD.  It it pity SPAD's case
expression was designed that way.

| Also some type inference( I dont mean auto coercion) will be helpful.

That one is tricky in presence of auto coercion.  I suspect that we
will be stuck with a mixture of type inference and type checking
(bidirectional typechecking a la Turner--Pierce).  I don't think that
is a bad thing.  Type systems based on Hindley-Milner inference have
evolved to a mixture anyway.

| For the monoid problem I guess we need something like chapter 6 of
| Nicolas Doye PhD thesis.
| 
| Also should coercion have a special semantic ?
| 
| What to do about Rep ? I dont like it at all, why cant I have
| arbitrary number of instance variables named like I want.

We must have something to say that "here is the representation of a
domain".  There must be a way to impose a view on an existing object.
And Rep does that does job very well.  It is something I misses in
other languages.  The development of "concepts" for C++ has uncovered
that too. 

| I am personally worried about the current :
| (that is broken in Aldor and required the horrible "pretend" aka cast)
| 
| "if xValue has someSubtype then
| 	ADT signature extention"

I too dislike this.  But I don't have (yet) a better solution.

The abstract idea being expressed is an important one.  What we need
is a better and *modular* (I don't mean module system) to express it.

| Can we do that in the SML module system with functors ? I should know this :(
| ( I think I have read that with dependent type we get SML module for free )

I don't see how SML module system solves this problem. 

| Also we have it as control flow in function definition.
| "if xValue has someSubtype then"
| 
| what about :
| 
| "if someType has someSubType then" ?
| 
| What are the valuable lesson from SML module system, Haskell type
| class, and C++ template  we can use ?

People are still working on finding better expressive ways with type
classes (predicate over types).  And there are very interesting
problems there.  My impression is that Scratchpad invented a form of
"type classes" before type classes where invented.  And this dates
back to the 70's-80's.  

Over the years people, people have found creative ways to convincing
the C++ template systems to do things it wasn't designed directly to
do. For example, people now use what is called "enable_if" to select
functions templates based on predicates. "Concepts" for C++ will
subsume that creative use of templates.

I think SPAD has to find its solution by introspection.

[...]

| On a practical point of view.
| For me the highest importance will be good error messages during
| compilation and possibility of debugging after.
| I remember to be quite frighten by SPAD error messages, this being the
| reason I switched to Aldor.

My students describe SPAD diagnostics as "spectacularly obscure"
messages.

[...]

| Also I feel that depend type will ask a lot from the runtime system to
| do some late type checking.

Yes.

[...]

| I guess language design is quite difficult and it is important to know
| what kind of problems we need to solve.

Definitely.  That is why I'm of the opinion of first nailing down what
we want, i.e. look at existing SPAD codes and see how they can be
improved, how they can be expressed better, what kind of things cannot
be expressed adequately in current SPAD.  I'm not convinced by
feature accretion from other languages.

\start
Date: Tue, 21 Nov 2006 09:20:33 -0500
From: Tim Daly
To: Gernot Hueber
Subject: GCL and elf-loader

Gernot,

I'm very interested in your work but I'm still struggling with the
details of the elf-loader so you're way ahead of me. This looks like
a very interesting direction from my point of view. 

If I can get the elf-loader to work it would be simple to lift the
library interfaces and expose them as algebra packages. The key
issue for me is figuring out the low level details of bolting elf-loader
to GCL.

\start
Date: Tue, 21 Nov 2006 15:43:31 +0100
From: Gernot Hueber
To: Tim Daly
Subject: Re: GCL and elf-loader

In the meantime I had a look to www.swig.org, which has been mention on the 
axiom-* lists recently. IMHO it should be possible to generate wrappers 
(lisp and aldor) with this tool - yet there is much black magic inside, 
especially the way to extend swig. Swig supports AllegroCL using FFI which 
is not included with GCL (at the moment) 

root writes: 

> Gernot, 
> 
> I'm very interested in your work but I'm still struggling with the
> details of the elf-loader so you're way ahead of me. This looks like
> a very interesting direction from my point of view.  
> 
> If I can get the elf-loader to work it would be simple to lift the
> library interfaces and expose them as algebra packages. The key
> issue for me is figuring out the low level details of bolting elf-loader
> to GCL. 

\start
Date: 21 Nov 2006 15:59:52 +0100
From: Gabriel Dos Reis
To: Gernot Hueber
Subject: Re: GCL and elf-loader

Gernot Hueber writes:

| In the meantime I had a look to www.swig.org, which has been mention
| on the axiom-* lists recently. IMHO it should be possible to generate
| wrappers (lisp and aldor) with this tool - yet there is much black
| magic inside, especially the way to extend swig. Swig supports
| AllegroCL using FFI which is not included with GCL (at the moment)

I was thinking that the elf-loader approach would be very fruitful for
Axiom as a long term solution.

\start
Date: Tue, 21 Nov 2006 16:21:56 +0100
From: Gernot Hueber
To: Gabriel Dos Reis
Subject: Re: GCL and elf-loader

Gabriel Dos Reis writes: 

> Gernot Hueber writes: 
> 
> | In the meantime I had a look to www.swig.org, which has been mention
> | on the axiom-* lists recently. IMHO it should be possible to generate
> | wrappers (lisp and aldor) with this tool - yet there is much black
> | magic inside, especially the way to extend swig. Swig supports
> | AllegroCL using FFI which is not included with GCL (at the moment) 
> 
> I was thinking that the elf-loader approach would be very fruitful for
> Axiom as a long term solution.

 From my point of view, integration of elf-loader in Axiom is pretty easy - 
and it opens a world. At the moment limited to my laptop ;-) 

I started this discussion to get feedback if _this_ approach with this style 
of wrappers make sense or if there are better solutions in a private queue 
(Tim and you mentioned independently ideas of an external library/language 
inferface, Gaby implemented a lisp wrapper for a lapack implementation which 
is have the way to be usable within Axiom, ...). 

\start
Date: Tue, 21 Nov 2006 20:46:14 +0000
From: Peter Broadbery
To: Antoine Hersen
Subject: re: SPAD and Aldor again

I was going to write a fairly long flame as a reply.  I'll just state
that the aldor compiler is actually  better structured than most 200K+
line pieces of code I've had to deal with.  There are one or two other
statements I'd respectfully disagree with, but I can't be bothered.

The optimiser bugs are painful, and I wish they would be dealt with.
Hell, I'd give it a shot if the code was available.  (or remove the
optimisations, and fix the bits that require optimisation, one or the
other...). 

Naturally, the language isn't to everybody's taste, but does seem to
express a significant number of data structures and algorithms in a form
that people find attractive and useful. 

Dependent types actually require very little in the way of type checking
at runtime - since to the underlying interpreter, everything has more or
less the same type - the compiler does all the complex checking.  The
expensive bit (in terms of code size) is conditionals and parameterised
types, and even there, the time overhead is small if the code does
anything significant with a fixed set of types.  There is nothing here
that isn't done by java, except that types are created by things that
look like function calls rather than comparisons.

To get into some ideas where SPAD or aldor can be improved:

Conditional exports seem to be necessary with parameterised types (it's
a fair point that overloading 'if' is evil, I'd like to see some
alternatives though).

A syntax for naming type constructors in function calls, so

GraphCat(T: HashType): HashType == ...
GraphAlgorithms(T: HashType, G: (T: HashType) -> GraphCategory T) == {
   connectedComponents: G T -> Set Set T;
   connectedGraph: G T -> G Set T;
}	

was more akin to
GraphAlgorithms(BG: (G T == GraphCat(HashType)), X: S T == SetCat(HashType))
   connectedComponents: BG -> S S T;
   connectedGraph: BG-> G G T;
}

So we are not forced to use 'Set'. Unfortunately I can't suggest a nice
looking yet consistent syntax. 

Rep and Per are good for many things, but it might be worth adding a
shorthand for 'my representation is just a record'.  Don't think of Rep
as an instance variable - it's a mapping between your type and an
underlying one.  That said, a default representation of Rep + Record
might be an interesting idea.

\start
Date: Tue, 21 Nov 2006 22:14:39 +0100
From: Ralf Hemmecke
To: Peter Broadbery
Subject: re: SPAD and Aldor again

> Rep and Per are good for many things, but it might be worth adding a
> shorthand for 'my representation is just a record'.  Don't think of Rep
> as an instance variable - it's a mapping between your type and an
> underlying one.  That said, a default representation of Rep + Record
> might be an interesting idea.

Peter, perhaps you know ...

The only thing that makes "Rep", "rep", and "per" special is:

macro {
	rep x == ((x)@%) pretend Rep;
	per r == ((r)@Rep) pretend %;
}

from include/aldor.as.

Now let us assume that everywhere in the libaldor sources we would replace

   Rep <--- Foo
   rep <--- bar
   per <--- rab

I guess the compiler would still accept the code and even produces an 
identical library (up to name changes and hash codes etc).

Or does the compiler know about a special treatment of "Rep" (in 
contrast to "Foo")?

Going a bit further... is % known to the compiler? Or could I also 
replace that (above and in everywhere.as file) by something else like 
"Bar", for example?

I'm really curious.

\start
Date: Tue, 21 Nov 2006 21:28:43 +0000
From: Peter Broadbery
To: Ralf Hemmecke
Subject: re: SPAD and Aldor again

On Tue, 2006-11-21 at 22:14 +0100, Ralf Hemmecke wrote:
> > Rep and Per are good for many things, but it might be worth adding a
> > shorthand for 'my representation is just a record'.  Don't think of Rep
> > as an instance variable - it's a mapping between your type and an
> > underlying one.  That said, a default representation of Rep + Record
> > might be an interesting idea.
> 
> Peter, perhaps you know ...
> 
> The only thing that makes "Rep", "rep", and "per" special is:
> 
> macro {
> 	rep x == ((x)@%) pretend Rep;
> 	per r == ((r)@Rep) pretend %;
> }
> 
> from include/aldor.as.
> 
> Now let us assume that everywhere in the libaldor sources we would replace
> 
>    Rep <--- Foo
>    rep <--- bar
>    per <--- rab
> 
> I guess the compiler would still accept the code and even produces an 
> identical library (up to name changes and hash codes etc).
> 

Yes, correct.  The fact that almost all domains require a representation
is an part of the language, even if the implementation of this is done
via convention.

> Or does the compiler know about a special treatment of "Rep" (in 
> contrast to "Foo")?
> 
> Going a bit further... is % known to the compiler? Or could I also 
> replace that (above and in everywhere.as file) by something else like 
> "Bar", for example?
> 

% is a different thing to the type being defined - this matters for
add-inheritance and in categories.

\start
Date: Tue, 21 Nov 2006 17:03:50 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Boot

If you plan to go ahead with the proposed documentation of
"new boot" (aka. SHOE) I would be delighted to help. Perhaps
you have said before, but could you please explain how to
call SHOE from the command line?

What I would like to do is to provide a environment in the
Axiom Wiki, e.g.

  \begin{shoe}
  ....
  \end{shoe}

where we can compile examples of SHOE code. There is already
such an environment for boot

  \begin{boot}
  ....
  \end{boot}

See

http://wiki.axiom-developer.org/BootProgramming

I am very interested in your comment about the relationship
between SHOE and Haskell.

Regards,
Bill Page.


On November 18, 2006 4:03 AM Gabriel Dos Reis wrote:

> Tim Daly writes:
>
> [...]
>
> | first, bill burge loved puns and i remember him explaining to
> | me that the latest version of boot was much better and more
> | comfortable,
>
> Indeed, the "new boot" is much more comfortable than "old boot",
> in many respects.  It has a preliminary support for (dynamic)
> type-checking, algebra datatype and pattern matching.
>
> I don't think there is much code in Axiom that takes advantage of
> the features of "new boot".
>
> I believe I understand enough of it to start documenting it
> properly. Very interestingly, it has much ressemblance with core
> Haskell.
>
> However, the "new boot" still needs some tuning, but I prefer it
> over the "old boot".

\start
Date: Tue, 21 Nov 2006 17:21:12 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire, Aurelien Chanudet

What is the current status of build-improvements and compiling Axiom
on MAC OSX? Does this work out of the box, i.e. configure && make?
Does hyperdoc and graphics work? I am not able to test this at
the SourceForge farm.

I know someone working on Sage who would very much like to run
Axiom on the MAC so I was just thinking about updating my Sage
package 'axiom4sage-0.1.spkg' to make this easier for them to
install Axiom.

On Thursday, November 16, 2006 7:37 PM Gabriel Dos Reis wrote:
>
> On Thu, 16 Nov 2006, Camm Maguire wrote:
> ...
> | The short story is I'd recommend leaving out the maxpage at least
> | on macosx.  In fact, we might make it a configure error at the
> | moment.
>
> Hello Camm,
>
>   Thanks for the extensive explanation -- I liked it.  I'll implement
> your suggestion.

\start
Date: 21 Nov 2006 17:29:51 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Aurelien Chanudet, Gabriel Dos Reis

Greetings!  Just FYI -- some email failure appears to have completely
shut off axiom traffic :-(.  I notice on the web a few outstanding
questions -- please try to mail me directly and I will do my best to
answer.   (Cannot possibly do mail outside of emacs :-)).

As for solaris, the default configure and build without

 -DBSD_COMP=bsd_comp -DGNUMALLOC=gnumalloc

should work.  AFAICR, my test machine used gcc, and solaris ld, which
seemed to be the common setup.

Take care,

Bill Page writes:

> Gaby,
> 
> What is the current status of build-improvements and compiling Axiom
> on MAC OSX? Does this work out of the box, i.e. configure && make?
> Does hyperdoc and graphics work? I am not able to test this at
> the SourceForge farm.
> 
> I know someone working on Sage who would very much like to run
> Axiom on the MAC so I was just thinking about updating my Sage
> package 'axiom4sage-0.1.spkg' to make this easier for them to
> install Axiom.
> 
> Regards,
> Bill Page.
> 
> 
> On Thursday, November 16, 2006 7:37 PM Gabriel Dos Reis wrote:
> > 
> > On Thu, 16 Nov 2006, Camm Maguire wrote:
> > ... 
> > | The short story is I'd recommend leaving out the maxpage at least
> > | on macosx.  In fact, we might make it a configure error at the
> > | moment.
> > 
> > Hello Camm,
> > 
> >   Thanks for the extensive explanation -- I liked it.  I'll implement
> > your suggestion.

\start
Date: Tue, 21 Nov 2006 17:48:49 -0500
From: Bill Page
To: Humberto Zuazaga
Subject: Ping: gcl-2.6.8pre on MAC OSX 10.2

Humberto,

Have you had a chance to test the latest version of build-improvements
on your MAC?

Anyone else done this?

Regards,
Bill Page.

On Tuesday, November 21, 2006 5:37 PM Gaby wrote:
>
> Bill Page writes:
>
> | Gaby,
> |
> | What is the current status of build-improvements and compiling Axiom
> | on MAC OSX? Does this work out of the box, i.e. configure && make?
>
> I'm waiting on Humberto's report.  I have checked in anything Humberto
> and Camm have suggested so far.
>
> | Does hyperdoc and graphics work?
>
> I would like to know what Humberto's experience is. 
>
> | I am not able to test this at the SourceForge farm.
> |
> | I know someone working on Sage who would very much like to run
> | Axiom on the MAC so I was just thinking about updating my Sage
> | package 'axiom4sage-0.1.spkg' to make this easier for them to
> | install Axiom.
>
> I too would like to have it running there. 
> Some students here tried several time (before I got all of Humberto's
> suggestions) but failed; they are now kind resistent to the idea of
> trying again.  And it is Thanksgiving soon so they have their minds
> elsewhere. :-\

\start
Date: Tue, 21 Nov 2006 17:53:45 -0500
From: Tim Daly
To: list
Subject: Axiom Video Documentation

I've started experimenting with documenting Axiom using video.
You can find the initial attempts, evolving rapidly, at:

http://daly.axiom-developer.org/literate

Please let me know which of the four video formats you prefer.

The AVI format appears to be Camtasia specific and require a
Camtasia codec which can be downloaded from the webpage.

The MOV format is Apple QuickTime

The FLASH format will probably work inline in most browsers.

The WMV format is the Windows Media Format.

\start
Date: Tue, 21 Nov 2006 18:29:26 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Axiom Video Documentation

On  Tuesday, November 21, 2006 5:54 PM Tim Daly wrote:
>
> I've started experimenting with documenting Axiom using video.
> You can find the initial attempts, evolving rapidly, at:
>
> http://daly.axiom-developer.org/literate
>
> Please let me know which of the four video formats you prefer.
>
> The AVI format appears to be Camtasia specific and require a
> Camtasia codec which can be downloaded from the webpage.
>
> The MOV format is Apple QuickTime
>
> The FLASH format will probably work inline in most browsers.
>
> The WMV format is the Windows Media Format.
>

Without installing any new codec or other software, on Windows XP
using FireFox as web browser, clicking on AVI and WMV both start
MicroSoft Media player. I get audio but no video. With AVI, at the
bottom of the window I see:

  No Video? Download the TechSmith Screen Capture Codec
  http://www.techsmith.com/codecs.asp .

With WMV I do not get any explanation of why no video.

I guess I could do that, but as a visitor to the Axiom site I might
be a bit put-off from trying this unless I thought I really needed
to do it.

The MOV and FLASH formats worked right away. No problem. Perhaps
FireFox has built-in support for Flash or else I previously installed
it. MOV takes noticably longer to download. (Is it larger?) Both look
and sound fine on this system. The FLASH version has the annoying
feature of cycling back to the beginning and playing again indefinitely.
I expected it to just stop like the others. In spite of that I
preferred the FLASH version because it was fast to load and display.

\start
Date: Tue, 21 Nov 2006 19:51:26 -0400
From: Humberto Zuazaga
To: Bill Page
Subject: re: gcl-2.6.8pre on MAC OSX 10.2
Cc: Camm Maguire, Aurelien Chanudet, Gabriel Dos Reis

Page, Bill wrote:
> Gaby,
>
> What is the current status of build-improvements and compiling Axiom
> on MAC OSX? Does this work out of the box, i.e. configure && make?
> Does hyperdoc and graphics work? I am not able to test this at
> the SourceForge farm.

Not yet.

AXIOMsys builds with the internal gcl with just ./configure && make if
you eliminate all references to fink from your path (i.e., no
/sw/bin:/sw/sbin). You may want to symlink latex and makeindex from
/sw/bin to /usr/local/bin.

Waldek posted a patch to fix some issues with openpty that isn't in
build-improvements yet (as far as I can tell, I have version control
system overload):

http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00236.htm=
l

I think that's all that's needed to build, but I want to pull a clean
source tree and try again. Maybe over the holiday weekend.

\start
Date: 22 Nov 2006 02:09:54 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: better pty patch

Waldek Hebisch writes:

| Many systems (Linux, BSD and supposedly also Mac OS X) provide 'openpty'
| function as a preferred method to open a pty (for example on Linux
| 'openpty' will use Unix 98 ptys, but if those are not available it
| will fall back to legacy ptys).  'openpty' seem to be available
| in 'libutil', so in order to use it we must link to 'libutil'.
| 
| The patch below tries to 'openpty': add configure check and auguments
| compiler and linker argument.  There are some things which probably
| should be done in different way (please comment):
| 
| 1) configure defines 'HAVE_OPENPTY' preprocessor symbol, this symbol
|    is then propagated via 'DEFS' make variable and compile command
|    line.  Alternatively we could have a common header file generated
|    by configure

Yes, configure can generate a headef file for us to included, instead
of the current hackery of XXXplatform.   
Basically,

  (1) You need to issue

        AC_CONFIG_HEADERS([config/axiom-c-macros.h])

      in configure.ac.pamphlet.  This tells Autoconf (and especially
      Autoheader) that we are going to define CPP macros to
      communicate with thwe C programs, and we want to collect all
      those macros in the file config/axiom-c-macros.h.  Every
      AC_DEFINE you'll issue will end up there.

  (2) Run autoheader.  It should create a file named axiom-c-macros.h.in
      in the config/ directory.  Add it to the repository.

  (3) Modify the INC variable (this really should be set system-wide,
      I think), to include the path to config, e.g. add

        -I$(abs_top_builddir)/config

      [ The reason why I use $(abs_top_builddir) instead of the
       "simpler" $(top_builddir) is that there is a bug in Autoconf
       2.59 that would leave the variable top_builddir undefined.
       That is fixed in later versions, but unless we require Autoconf
       2.60 I think we're better with the absolute path. ]

  (4) Have the C programs include "axiom-c-macros.h"
   

[...]

| +\section{Extra libraries}
| +
| +Axiom supporting programs [[sman]] and [[clef]] use pseudo terminals.
| +To open pseudo terminals we use [[openpty]] if available, otherwise
| +we fall back to platform specific code.
| +
| +<<extra libraries>>=
| +AC_CHECK_FUNCS(openpty,, AC_CHECK_LIB(util,openpty, [AC_DEFINE(HAVE_OPENPTY)]
| + [EXTRA_LIBS="-lutil"]))
| +AC_SUBST(EXTRA_LIBS)
| +@

It is not enough to test for the library.  You have to test for the
headers <util.h> or <pty.h> too.  Furthermore, you need to check for the
declaration of the function openpty() -- not just its presence as
symbol in a library.

    # Check for <util.h>; if inexistent, check for <pty.h>
    AC_CHECK_HEADER([util.h], 
                    [AC_DEFINE([HAVE_UTIL_H])],
                    [AC_CHECK_HEADER([pty.h])
                    ]) # HAVE_UTIL_H or HAVE_PTY_H

    AC_CHECK_DECL([openpty], [], [],
                  [#if HAVE_UTIL_H
                   # include <util.h>
                   #elif HAVE_PTY_H
                   # include <pty.h>
                   #endif
                  ]) # HAVE_OPENPTY_DECL

    AC_CHECK_LIB([util], [openpty],
                 [AC_DEFINE([HAVE_OPENPTY])
                  EXTRA_LIBS="$EXTRA_LIBS -lutil"
                 ]) # HAVE_OPENPTY


[...]

| +We should really use autotools to check for Unix 98 pty support.
| +Before this is done below we hardcode information about each platform.
| +
|  \section{License}
|  <<license>>=
|  /*
| @@ -70,6 +62,9 @@
|  #include <stropts.h>
|  #endif
|  
| +#ifdef HAVE_OPENPTY
| +#include <pty.h>
| +#endif

This should be something like

   #ifdef HAVE_OPENPTY_DECL
   #  if HAVE_UTIL_H
   #    include <util.h>
   #  elif HAVE_PTY_H
   #    include <pty.h>
   #elif HAVE_OPENPTY
   /* The symbol openpty is allegedly present but its
      declaration was not found in any of the above headers.
      So, we fake it here.  Note this is NOT a prototype
      declaration.  */
   int openpty();
   #else 
   #  define AXIOM_DONT_USE_OPENPTY 1
   #endif

   #define AXIOM_USE_OPENPTY !AXIOM_DONT_USE_OPENPTY


|  
|  #include "openpty.H1"
|  
| @@ -104,7 +99,10 @@
|  #endif
|  
|  {
| -#if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) ||defined(AIX370platform) || defined(BSDplatform)
| +#ifdef HAVE_OPENPTY

This should be

   #if AXIOM_USE_OPENPTY

\start
Date: Wed, 22 Nov 2006 12:04:58 +0100
From: Gernot Hueber
To: Bill Page
Subject: Re: Axiom Video Documentation

Hi, 

opening on a not very current FreeBSD using Mozilla fails with the request 
to download plugins.
However, direct download of the mov/avi (e.g. fetch 
http://daly.axiom-developer.org/literate/MakeAxiom_mov/MakeAxiom_mov_media/M 
akeAxiom_mov.mov) and playing in mplayer works fine - but wmv fails with no 
video (audio is ok). wmv could be supported on a more current system due to 
a special codec is required: "DirectShow codec wmsdmod.dll". 

Thanks for the good work, pls proceed with more :-) 

Page, Bill writes: 

> On  Tuesday, November 21, 2006 5:54 PM Tim Daly wrote:
>> 
>> I've started experimenting with documenting Axiom using video.
>> You can find the initial attempts, evolving rapidly, at: 
>> 
>> http://daly.axiom-developer.org/literate 
>> 
>> Please let me know which of the four video formats you prefer. 
>> 
>> The AVI format appears to be Camtasia specific and require a
>> Camtasia codec which can be downloaded from the webpage. 
>> 
>> The MOV format is Apple QuickTime 
>> 
>> The FLASH format will probably work inline in most browsers. 
>> 
>> The WMV format is the Windows Media Format. 
>> 
> 
> Without installing any new codec or other software, on Windows XP
> using FireFox as web browser, clicking on AVI and WMV both start
> MicroSoft Media player. I get audio but no video. With AVI, at the
> bottom of the window I see: 
> 
>   No Video? Download the TechSmith Screen Capture Codec
>   http://www.techsmith.com/codecs.asp . 
> 
> With WMV I do not get any explanation of why no video. 
> 
> I guess I could do that, but as a visitor to the Axiom site I might
> be a bit put-off from trying this unless I thought I really needed
> to do it. 
> 
> The MOV and FLASH formats worked right away. No problem. Perhaps
> FireFox has built-in support for Flash or else I previously installed
> it. MOV takes noticably longer to download. (Is it larger?) Both look
> and sound fine on this system. The FLASH version has the annoying
> feature of cycling back to the beginning and playing again indefinitely.
> I expected it to just stop like the others. In spite of that I
> preferred the FLASH version because it was fast to load and display. 

\start
Date: Wed, 22 Nov 2006 12:45:47 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Testing build-improvements

Recent changes broken testing build-improvements.  The typical problem
is that 'int/input/INTHEORY.input' contains sum of INTHEORY.spad and
PNTHEORY.spad.
 
\start
Date: Wed, 22 Nov 2006 06:48:48 -0500
From: Bill Page
To: Frederic Lehobey
Subject: Functors (was:  Licensing Aldor)

On Wednesday, November 22, 2006 4:35 AM Frederic Lehobey wrote:
>
> I believe I am starting to be slightly off-topic for axiom-legal
> with this message, so I think it will be my last contribution to
> this thread.

Ok. I want to reply to one technical point so I will shift to
axiom-developer.

> ...
> > > What I mean is being able to create domains in compiled code with
> > > variables in their parameters (not change the value of the
variable
> > > after instantiation). With this much of the Galois field
factorisation
> > > of Axiom would be much easier to write *and maintain* (currently,
> > > it is a kind of hack using the integers and contradicting the
> > > grounding principles of Axiom).
> >
> > I think you could expect a lot of help on this from Ralf Hemmecke
> > and Martin Rubey. I am not entirely sure what you mean by "variables
> > that do not change value after instantiation". I think this is the
> > definition of a constant. So what you want to do should be possible.
>
> Let's be specific:
>
>     PrimeField(7)
>
> and
>
>     PrimeField(p)
>
> both work in interpreted mode whereas the second one is not compiled
> by the old compiler (it has already been discussed some time -- years
> -- ago on axiom-dev).
>

Are you referring to the discussion of dependent types in Aldor function
definitions such as

  g(p:PositiveInteger,k:Integer):PrimeField(p) == k::PrimeField(p)

This looks innocent and "natural" in Aldor, and in the Axiom interpreter
but William Sit and Ralf Hemmecke showed that in fact this is not really
a function definition in the sense of category theory at all but rather
a functor (i.e. package or domain constructor). See:

http://lists.nongnu.org/archive/html/axiom-developer/2005-01/msg00207.ht
ml
http://lists.nongnu.org/archive/html/axiom-developer/2005-01/msg00310.ht
ml

In the Axiom/SPAD compiler you can write such a functor as

g(p:PositiveInteger, k:Integer):with point:()->PrimeField(p)
  == add point()==k::PrimeField(p)

The function 'point' is necessary because a functor returns something
of type category. The parameters pick out a particular function from
the category. E.g.

  point()$g(7,4)

> ...

>From my point of view this is technically more correct than Aldor's
syntax.

\start
Date: 22 Nov 2006 06:06:48 -0600
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] Remove K&R cruft from src/lib

While, I was looking at src/lib to gather unwritten assumptions made by
the C programs, my eyes were glazing over the antiquated K&R C style
declaration of functions. In 2006, we have no more reasons to write C
codes that way.  Especially, none for Axiom.  While I was there, I saw
various "broken" C codes, more on that latter.

-- Gaby

2006-11-21  Gabriel Dos Reis  Gabriel Dos Reis

	* bsdsignal.c.pamphlet: Remove K&R C style function declaration.
	* cfuns-c.c.pamphlet: Likewise.
	* cursor.c.pamphlet: Likewise.
	* edin.c.pamphlet: Likewise.
	* emupty.c.pamphlet: Likewise.
	* fnct_key.c.pamphlet: Likewise.
	* halloc.c.pamphlet: Likewise.
	* hash.c.pamphlet: Likewise.
	* openpty.c.pamphlet: Likewise.
	* pixmap.c.pamphlet: Likewise.
	* prt.c.pamphlet: Likewise.
	* sockio-c.c.pamphlet: Likewise.
	* spadcolors.c.pamphlet: Likewise.
	* util.c.pamphlet: Likewise.
	* wct.c.pamphlet: Likewise.
	* XDither.c.pamphlet: Likewise.
	* XShade.c.pamphlet: Likewise.
	* XSpadFill.c.pamphlet: Likewise.

*** src/lib/XDither.c.pamphlet	(revision 15245)
--- src/lib/XDither.c.pamphlet	(local)
*************** unsigned int DITHERINIT = 0;
*** 92,102 ****
   * high the bitmap is.
   */
  int
- #ifdef _NO_PROTO
- dither_char_bitmap()
- #else
  dither_char_bitmap(void)
- #endif
  {
      int bits_line;
      int total_chars;
--- 92,98 ----
*************** dither_char_bitmap(void)
*** 110,124 ****
  }
  
  int 
! #ifdef _NO_PROTO
! XInitDither(display, screen, gc, fg, bg)
!     Display *display;
!     int screen;
!     GC  gc;
!     unsigned long fg, bg;
! #else
! XInitDither(Display *display, int screen, GC gc, unsigned long fg, unsigned long bg)
! #endif
  {
  
      char *bits;
--- 106,113 ----
  }
  
  int 
! XInitDither(Display *display, int screen, GC gc, unsigned long fg, 
!             unsigned long bg)
  {
  
      char *bits;
*************** XInitDither(Display *display, int screen
*** 171,184 ****
  
  
  int
- #ifdef _NO_PROTO
- XChangeDither(display, gc, dither)
-     Display *display;
-     GC  gc;
-     int dither;
- #else
  XChangeDither(Display *display, GC gc, int dither)
- #endif
  {
      if (!DITHERINIT) {
          fprintf(stderr, "XChange Error: Init Not Called\n");
--- 160,166 ----
*************** XChangeDither(Display *display, GC gc, i
*** 194,209 ****
  
  
  void
! #ifdef _NO_PROTO
! XDitherRectangle(display, drawable, gc, x, y, width, height)
!     Display *display;
!     Drawable drawable;
!     GC  gc;
!     int x, y;
!     unsigned int width, height;
! #else
! XDitherRectangle(Display *display, Drawable drawable, GC gc, int x,int  y, unsigned int width, unsigned int height)
! #endif
  {
  
  
--- 176,183 ----
  
  
  void
! XDitherRectangle(Display *display, Drawable drawable, GC gc, int x,
!                  int  y, unsigned int width, unsigned int height)
  {
  
  
*************** XDitherRectangle(Display *display, Drawa
*** 217,232 ****
  
  
  void
! #ifdef _NO_PROTO
! XDitherRectangles(display, drawable, gc, rectangles, nrectangles)
!     Display *display;
!     Drawable drawable;
!     GC  gc;
!     XRectangle *rectangles;
!     int nrectangles;
! #else
! XDitherRectangles(Display *display, Drawable drawable, GC gc, XRectangle *rectangles, int nrectangles)
! #endif
  {
  
  
--- 191,198 ----
  
  
  void
! XDitherRectangles(Display *display, Drawable drawable, GC gc, 
!                   XRectangle *rectangles, int nrectangles)
  {
  
  
*************** XDitherRectangles(Display *display, Draw
*** 241,258 ****
  
  
  void 
! #ifdef _NO_PROTO
! XDitherPolygon(display, drawable, gc, points, npoints, shape, mode)
!     Display *display;
!     Drawable drawable;
!     GC  gc;
!     XPoint *points;
!     int npoints;
!     int shape;
!     int mode;
! #else
! XDitherPolygon(Display * display, Drawable drawable, GC gc, XPoint *points, int npoints, int shape, int mode)
! #endif
  {
      if (!DITHERINIT) {
          fprintf(stderr, "XDither Error: Tried to fill before INIT called\n");
--- 207,214 ----
  
  
  void 
! XDitherPolygon(Display * display, Drawable drawable, GC gc, 
!                XPoint *points, int npoints, int shape, int mode)
  {
      if (!DITHERINIT) {
          fprintf(stderr, "XDither Error: Tried to fill before INIT called\n");
*************** XDitherPolygon(Display * display, Drawab
*** 265,282 ****
  }
  
  void
- #ifdef _NO_PROTO
- XDitherArc(display, drawable, gc, x, y, width, height, angle1, angle2)
-     Display *display;
-     Drawable drawable;
-     GC  gc;
-     int x, y;
-     unsigned int width, height;
-     int angle1, angle2;
- #else
  XDitherArc(Display *display, Drawable drawable, GC gc, int x,int  y, 
! 	unsigned int width, unsigned int height, int angle1, int angle2)
! #endif
  {
  
      if (!DITHERINIT) {
--- 221,228 ----
  }
  
  void
  XDitherArc(Display *display, Drawable drawable, GC gc, int x,int  y, 
!            unsigned int width, unsigned int height, int angle1, int angle2)
  {
  
      if (!DITHERINIT) {
*************** XDitherArc(Display *display, Drawable dr
*** 289,304 ****
  
  
  void
- #ifdef _NO_PROTO
- XDitherArcs(display, drawable, gc, arcs, narcs)
-     Display *display;
-     Drawable drawable;
-     GC  gc;
-     XArc *arcs;
-     int narcs;
- #else
  XDitherArcs(Display *display,Drawable  drawable, GC gc, XArc *arcs,int narcs)
- #endif
  {
  
      if (!DITHERINIT) {
--- 235,241 ----
*** src/lib/XShade.c.pamphlet	(revision 15245)
--- src/lib/XShade.c.pamphlet	(local)
*************** unsigned int INIT = 1;
*** 99,109 ****
   * high the bitmap is.
   */
  int
- #ifdef _NO_PROTO
- char_bitmap()
- #else
  char_bitmap(void)
- #endif
  {
      int bits_line;
      int total_chars;
--- 99,105 ----
*************** char_bitmap(void)
*** 117,129 ****
  }
  
  int
- #ifdef _NO_PROTO
- XInitShades(display, screen)
-     Display *display;
-     int screen;
- #else
  XInitShades(Display *display, int screen)
- #endif
  {
      char *bits;
      int count;
--- 113,119 ----
*************** XInitShades(Display *display, int screen
*** 157,169 ****
  
  
  int
- #ifdef _NO_PROTO
- XChangeShade(display, shade)
-     Display *display;
-     int shade;
- #else
  XChangeShade(Display *display, int shade)
- #endif
  {
      if (shade >= XShadeMax || shade < 0) {
          fprintf(stderr, "Shade %d, out of range\n",shade);
--- 147,153 ----
*************** XChangeShade(Display *display, int shade
*** 174,185 ****
  }
  
  int
- #ifdef _NO_PROTO
- XQueryShades(shades)
-     unsigned int *shades;
- #else
  XQueryShades(unsigned int *shades)
- #endif
  {
      *shades = XShadeMax;
      return 1;
--- 158,164 ----
*************** XQueryShades(unsigned int *shades)
*** 187,201 ****
  
  
  void
! #ifdef _NO_PROTO
! XShadeRectangle(display, drawable, x, y, width, height)
!     Display *display;
!     Drawable drawable;
!     int x, y;
!     unsigned int width, height;
! #else
! XShadeRectangle(Display *display,Drawable drawable,int x,int  y,unsigned int width,unsigned int height)
! #endif
  {
      if (!INIT) {
          fprintf(stderr, "XShade Error: Tried to fill before INIT called\n");
--- 166,173 ----
  
  
  void
! XShadeRectangle(Display *display, Drawable drawable, int x,int y,
!                 unsigned int width, unsigned int height)
  {
      if (!INIT) {
          fprintf(stderr, "XShade Error: Tried to fill before INIT called\n");
*************** XShadeRectangle(Display *display,Drawabl
*** 206,220 ****
  
  
  void
! #ifdef _NO_PROTO
! XShadeRectangles(display, drawable, rectangles, nrectangles)
!     Display *display;
!     Drawable drawable;
!     XRectangle *rectangles;
!     int nrectangles;
! #else
! XShadeRectangles(Display *display,Drawable drawable,XRectangle *rectangles,int nrectangles)
! #endif
  {
      if (!INIT) {
          fprintf(stderr, "XShade Error: Tried to fill before INIT called\n");
--- 178,185 ----
  
  
  void
! XShadeRectangles(Display *display, Drawable drawable, 
!                  XRectangle *rectangles, int nrectangles)
  {
      if (!INIT) {
          fprintf(stderr, "XShade Error: Tried to fill before INIT called\n");
*************** XShadeRectangles(Display *display,Drawab
*** 226,242 ****
  
  
  void
! #ifdef _NO_PROTO
! XShadePolygon(display, drawable, points, npoints, shape, mode)
!     Display *display;
!     Drawable drawable;
!     XPoint *points;
!     int npoints;
!     int shape;
!     int mode;
! #else
! XShadePolygon(Display *display,Drawable drawable,XPoint * points, int npoints,int  shape, int mode)
! #endif
  {
      if (!INIT) {
          fprintf(stderr, "XShade Error: Tried to fill before INIT called\n");
--- 191,198 ----
  
  
  void
! XShadePolygon(Display *display, Drawable drawable, XPoint * points, 
!               int npoints, int  shape, int mode)
  {
      if (!INIT) {
          fprintf(stderr, "XShade Error: Tried to fill before INIT called\n");
*************** XShadePolygon(Display *display,Drawable 
*** 248,263 ****
  }
  
  void
! #ifdef _NO_PROTO
! XShadeArc(display, drawable, x, y, width, height, angle1, angle2)
!     Display *display;
!     Drawable drawable;
!     int x, y;
!     unsigned int width, height;
!     int angle1, angle2;
! #else
! XShadeArc(Display *display,Drawable drawable,int x,int y, unsigned int width,unsigned int height,int angle1,int angle2)
! #endif
  {
      if (!INIT) {
          fprintf(stderr, "XShade Error: Tried to fill before INIT called\n");
--- 204,211 ----
  }
  
  void
! XShadeArc(Display *display, Drawable drawable, int x, int y, 
!           unsigned int width, unsigned int height, int angle1, int angle2)
  {
      if (!INIT) {
          fprintf(stderr, "XShade Error: Tried to fill before INIT called\n");
*************** XShadeArc(Display *display,Drawable draw
*** 269,283 ****
  
  
  void
! #ifdef _NO_PROTO
! XShadeArcs(display, drawable, arcs, narcs)
!     Display *display;
!     Drawable drawable;
!     XArc *arcs;
!     int narcs;
! #else
! XShadeArcs(Display *display,Drawable drawable,XArc *arcs,int narcs)
! #endif
  {
      if (!INIT) {
          fprintf(stderr, "XShade Error: Tried to fill before INIT called\n");
--- 217,223 ----
  
  
  void
! XShadeArcs(Display *display, Drawable drawable, XArc *arcs, int narcs)
  {
      if (!INIT) {
          fprintf(stderr, "XShade Error: Tried to fill before INIT called\n");
*** src/lib/XSpadFill.c.pamphlet	(revision 15245)
--- src/lib/XSpadFill.c.pamphlet	(local)
*************** extern int totalColors;
*** 97,111 ****
  extern int maxGreyShade;
  
  int
! #ifdef _NO_PROTO
! XInitSpadFill(dsply, scr, mapOfColors, hues, solid, dithered, shades)
!     Display *dsply;
!     int scr;
!     Colormap *mapOfColors;
!     int *hues, *solid, *dithered, *shades;
! #else
! XInitSpadFill(Display *dsply,int scr,Colormap * mapOfColors,int * hues, int *solid,int * dithered,int * shades)
! #endif
  {
      int maxDither;
      XColor BlackColor, WhiteColor;
--- 97,104 ----
  extern int maxGreyShade;
  
  int
! XInitSpadFill(Display *dsply, int scr, Colormap * mapOfColors, int * hues,
!               int *solid, int * dithered, int * shades)
  {
      int maxDither;
      XColor BlackColor, WhiteColor;
*************** XInitSpadFill(Display *dsply,int scr,Col
*** 189,215 ****
  
  
  void 
- #ifdef _NO_PROTO
- XSpadFillSetArcMode(dsply, mode)
-     Display *dsply;
-     int mode;
- #else
  XSpadFillSetArcMode(Display *dsply, int mode)
- #endif
  {
      XSetArcMode(dsply, solidGC, mode);
      XSetArcMode(dsply, stippleGC, mode);
  }
  
  GC
- #ifdef _NO_PROTO
- SpadFillGC(dsply, hue, theshade, fill_routine)
-     Display *dsply;
-     int hue, theshade;
-     char *fill_routine;
- #else
  SpadFillGC(Display *dsply,int  hue, int theshade,char * fill_routine)
- #endif
  {
      int dither;
      int color;
--- 182,195 ----
*************** SpadFillGC(Display *dsply,int  hue, int 
*** 263,274 ****
  }
  
  unsigned long
- #ifdef _NO_PROTO
- XSolidColor(hue, theshade)
- int hue , theshade;
- #else
  XSolidColor(int hue, int theshade)
- #endif
  {
      if (hue >= totalHues)
          return -1;
--- 243,249 ----
*************** XSolidColor(int hue, int theshade)
*** 278,293 ****
  }
  
  void 
! #ifdef _NO_PROTO
! XSpadFillRectangle(dsply, drawable, x, y, width, height, hue, theshade)
!     Display *dsply;
!     Drawable drawable;
!     int x, y;
!     unsigned int width, height;
!     int hue, theshade;
! #else
! XSpadFillRectangle(Display *dsply,Drawable drawable,int x,int y,unsigned int width,unsigned int height,int hue, int theshade)
! #endif
  {
  
      XFillRectangle(dsply, drawable,
--- 253,261 ----
  }
  
  void 
! XSpadFillRectangle(Display *dsply, Drawable drawable, int x, int y, 
!                    unsigned int width, unsigned int height, 
!                    int hue, int theshade)
  {
  
      XFillRectangle(dsply, drawable,
*************** XSpadFillRectangle(Display *dsply,Drawab
*** 298,313 ****
  
  
  void
! #ifdef _NO_PROTO
! XSpadFillRectangles(dsply, drawable, rectangles, nrectangles, hue, theshade)
!     Display *dsply;
!     Drawable drawable;
!     XRectangle *rectangles;
!     int nrectangles;
!     int hue, theshade;
! #else
! XSpadFillRectangles(Display *dsply,Drawable drawable,XRectangle * rectangles,int nrectangles,int  hue,int  theshade)
! #endif
  {
  
  
--- 266,274 ----
  
  
  void
! XSpadFillRectangles(Display *dsply, Drawable drawable, 
!                     XRectangle * rectangles, int nrectangles,
!                     int hue, int theshade)
  {
  
  
*************** XSpadFillRectangles(Display *dsply,Drawa
*** 319,336 ****
  
  
  void
! #ifdef _NO_PROTO
! XSpadFillPolygon(dsply, drawable, points, npoints, shape, mode, hue, theshade)
!     Display *dsply;
!     Drawable drawable;
!     XPoint *points;
!     int npoints;
!     int shape;
!     int mode;
!     int hue, theshade;
! #else
! XSpadFillPolygon(Display *dsply, Drawable drawable,XPoint * points, int npoints,int shape, int mode,int hue,int theshade)
! #endif
  {
      XFillPolygon(dsply, drawable,
                          SpadFillGC(dsply, hue, theshade, "XSpadFillRectangle"),
--- 280,287 ----
  
  
  void
! XSpadFillPolygon(Display *dsply, Drawable drawable, XPoint * points, 
!                  int npoints, int shape, int mode, int hue, int theshade)
  {
      XFillPolygon(dsply, drawable,
                          SpadFillGC(dsply, hue, theshade, "XSpadFillRectangle"),
*************** XSpadFillPolygon(Display *dsply, Drawabl
*** 339,355 ****
  }
  
  void
! #ifdef _NO_PROTO
! XSpadFillArc(dsply, drawable, x, y, width, height, angle1, angle2, hue, theshade)
!     Display *dsply;
!     Drawable drawable;
!     int x, y;
!     unsigned int width, height;
!     int angle1, angle2;
!     int hue, theshade;
! #else
! XSpadFillArc(Display *dsply,Drawable drawable,int x,int y, unsigned int width,unsigned int height, int angle1, int angle2,int  hue,int  theshade)
! #endif
  {
  
      XFillArc(dsply, drawable,
--- 290,298 ----
  }
  
  void
! XSpadFillArc(Display *dsply, Drawable drawable, int x, int y, 
!              unsigned int width, unsigned int height, 
!              int angle1, int angle2, int hue, int  theshade)
  {
  
      XFillArc(dsply, drawable,
*************** XSpadFillArc(Display *dsply,Drawable dra
*** 359,374 ****
  
  
  void
! #ifdef _NO_PROTO
! XSpadFillArcs(dsply, drawable, arcs, narcs, hue, theshade)
!     Display *dsply;
!     Drawable drawable;
!     XArc *arcs;
!     int narcs;
!     int hue, theshade;
! #else
! XSpadFillArcs(Display *dsply,Drawable  drawable,XArc * arcs,int narcs,int hue,int theshade)
! #endif
  {
      XFillArcs(dsply, drawable,
                       SpadFillGC(dsply, hue, theshade, "XSpadFillArcs"),
--- 302,309 ----
  
  
  void
! XSpadFillArcs(Display *dsply, Drawable drawable,XArc *arcs, int narcs,
!               int hue, int theshade)
  {
      XFillArcs(dsply, drawable,
                       SpadFillGC(dsply, hue, theshade, "XSpadFillArcs"),
*** src/lib/bsdsignal.c.pamphlet	(revision 15245)
--- src/lib/bsdsignal.c.pamphlet	(local)
*************** of files are badly broken with respect t
*** 229,242 ****
  
  
  SignalHandlerFunc
! #ifdef _NO_PROTO
! bsdSignal(sig,action,restartSystemCall)
!      int sig;
!      SignalHandlerFunc action;
!      int restartSystemCall;
! #else
! bsdSignal(int sig,SignalHandlerFunc action,int restartSystemCall)
! #endif
  {
  #ifndef MSYSplatform
  
--- 229,235 ----
  
  
  SignalHandlerFunc
! bsdSignal(int sig, SignalHandlerFunc action, int restartSystemCall)
  {
  #ifndef MSYSplatform
  
*** src/lib/cfuns-c.c.pamphlet	(revision 15245)
--- src/lib/cfuns-c.c.pamphlet	(local)
*************** of files are badly broken with respect t
*** 74,95 ****
  
  
  int
- #ifdef _NO_PROTO
- CLgetpid()
- #else
  CLgetpid(void)
- #endif
  {
      return getpid();
  }
  
  int
- #ifdef _NO_PROTO
- addtopath(dir)
-     char *dir;
- #else
  addtopath(char *dir)
- #endif
  {
      char *path, *newpath;
  
--- 74,86 ----
*************** addtopath(char *dir)
*** 113,124 ****
  
  
  int
- #ifdef _NO_PROTO
- directoryp(path)
-     char *path;
- #else
  directoryp(char *path)
- #endif
  {
      struct stat buf;
      int code;
--- 104,110 ----
*************** directoryp(char *path)
*** 133,144 ****
  }
  
  int 
- #ifdef _NO_PROTO
- make_path_from_file(s, t)
-     char *s, *t;
- #else
  make_path_from_file(char *s, char *t)
- #endif
  {
      char *pos = "";
      char *c;
--- 119,125 ----
*************** make_path_from_file(char *s, char *t)
*** 159,170 ****
  }
  
  int
- #ifdef _NO_PROTO
- writeablep(path)
-     char *path;
- #else
  writeablep(char *path)
- #endif
  {
      struct stat buf;
      char newpath[100];
--- 140,146 ----
*************** writeablep(char *path)
*** 203,214 ****
  
  
  int
- #ifdef _NO_PROTO
- readablep(path)
-     char *path;
- #else
  readablep(char *path)
- #endif
  {
      struct stat buf;
      int code;
--- 179,185 ----
*************** readablep(char *path)
*** 231,242 ****
  
  
  long
- #ifdef _NO_PROTO
- findString(file, string)
-     char *file, *string;
- #else
  findString(char *file, char *string)
- #endif
  {
      int nstring, charpos;
      FILE *fn;
--- 202,208 ----
*************** findString(char *file, char *string)
*** 256,267 ****
  }
  
  int
- #ifdef _NO_PROTO
- copyEnvValue(varName, buffer)
-     char *varName, *buffer;
- #else
  copyEnvValue(char *varName, char *buffer)
- #endif
  {
      char *s;
  
--- 222,228 ----
*** src/lib/cursor.c.pamphlet	(revision 15245)
--- src/lib/cursor.c.pamphlet	(local)
*************** SOFTWARE, EVEN IF ADVISED OF THE POSSIBI
*** 67,78 ****
  #include <sys/hft.h>
  
  int
- #ifdef _NO_PROTO
- Cursor_shape(shape)
-     int shape;
- #else
  Cursor_shape(int shape)
- #endif
  {
      int hftfd;
      char hftpath[16], s[100];
--- 67,73 ----
*************** Cursor_shape(int shape)
*** 151,162 ****
  #else
  
  int
- #ifdef _NO_PROTO
- Cursor_shape(shape)
-     int shape;
- #else
  Cursor_shape(int shape)
- #endif
  {
    return shape;
  }
--- 146,152 ----
*** src/lib/edin.c.pamphlet	(revision 15245)
--- src/lib/edin.c.pamphlet	(local)
*************** int buff_pntr;                     /* pr
*** 102,112 ****
  
  
  void
- #ifdef _NO_PROTO
- init_reader()
- #else
  init_reader(void)
- #endif
  {
    char *termVal;
    
--- 102,108 ----
*************** init_reader(void)
*** 127,137 ****
  
  
  void 
- #ifdef _NO_PROTO
- do_reading()
- #else
  do_reading(void)
- #endif
  {
    int ttt_read;
    int done_completely;
--- 123,129 ----
*************** do_reading(void)
*** 506,516 ****
  
  
  void 
! #ifdef _NO_PROTO
! send_line_to_child()
! #else
! send_line_to_child(void )
! #endif
  {
    static char converted_buffer[MAXLINE];
    int converted_num;
--- 498,504 ----
  
  
  void 
! send_line_to_child(void)
  {
    static char converted_buffer[MAXLINE];
    int converted_num;
*************** send_line_to_child(void )
*** 551,564 ****
  }
  
  int
- #ifdef _NO_PROTO
- convert_buffer(target, source, source_flag, num)
-      char *target, *source;
-      int *source_flag;
-      int num;
- #else
  convert_buffer(char *target, char *source,int * source_flag, int num)
- #endif
  {
    int i, j;
    
--- 539,545 ----
*************** convert_buffer(char *target, char *sourc
*** 592,603 ****
  
  
  void
- #ifdef _NO_PROTO
- insert_buff_printing(amount)
-      int amount;
- #else
  insert_buff_printing(int amount)
- #endif
  {
    int count;
    
--- 573,579 ----
*************** insert_buff_printing(int amount)
*** 654,665 ****
  }
  
  void 
- #ifdef _NO_PROTO
- insert_buff_nonprinting(amount)
-      int amount;
- #else
  insert_buff_nonprinting(int amount)
- #endif
  {
    int count;
    
--- 630,636 ----
*************** insert_buff_nonprinting(int amount)
*** 765,775 ****
  }
  
  void
- #ifdef _NO_PROTO
- prev_buff()
- #else
  prev_buff(void)
- #endif
  {
  
    /*
--- 736,742 ----
*************** prev_buff(void)
*** 801,811 ****
  }
  
  void
- #ifdef _NO_PROTO
- next_buff()
- #else
  next_buff(void)
- #endif
  {
    
    /*
--- 768,774 ----
*************** next_buff(void)
*** 837,849 ****
  
  
  void 
- #ifdef _NO_PROTO
- forwardcopy(buff1, buff2, num)
-      char *buff1, *buff2;
-      int num;
- #else
  forwardcopy(char *buff1,char * buff2,int num)
- #endif
  {
    int count;
    
--- 800,806 ----
*************** forwardcopy(char *buff1,char * buff2,int
*** 853,865 ****
  
  
  void 
- #ifdef _NO_PROTO
- forwardflag_cpy(buff1, buff2, num)
-      int *buff1, *buff2;
-      int num;
- #else
  forwardflag_cpy(int *buff1,int * buff2,int  num)
- #endif
  {
    int count;
    
--- 810,816 ----
*************** forwardflag_cpy(int *buff1,int * buff2,i
*** 868,879 ****
  }
  
  void 
- #ifdef _NO_PROTO
- flagcpy(s, t)
-      int *s, *t;
- #else
  flagcpy(int *s,int *t)
- #endif
  {
    while (*t >= 0)
      *s++ = *t++;
--- 819,825 ----
*************** flagcpy(int *s,int *t)
*** 881,903 ****
  }
  
  void 
- #ifdef _NO_PROTO
- flagncpy(s, t, n)
-      int *s, *t, n;
- #else
  flagncpy(int *s,int *t,int n)
- #endif
  {
    while (n-- > 0)
      *s++ = *t++;
  }
  
  void 
- #ifdef _NO_PROTO
- insert_queue()
- #else
  insert_queue(void)
- #endif
  {
    QueStruct *trace;
    QueStruct *new;
--- 827,840 ----
*************** insert_queue(void)
*** 960,972 ****
  
  
  void
- #ifdef _NO_PROTO
- init_flag(flags, num)
-      int *flags;
-      int num;
- #else
  init_flag(int *flags, int num)
- #endif
  {
    int i;
    
--- 897,903 ----
*************** init_flag(int *flags, int num)
*** 975,987 ****
  }
  
  void 
- #ifdef _NO_PROTO
- init_buff(flags, num)
-      char *flags;
-      int num;
- #else
  init_buff(char *flags, int num)
- #endif
  {
    int i;
    
--- 906,912 ----
*************** init_buff(char *flags, int num)
*** 991,1001 ****
  
  
  void
- #ifdef _NO_PROTO
- send_function_to_child()
- #else
  send_function_to_child(void)
- #endif
  {
    /* Takes care of sending a line to the child, and resetting the
       buffer for new input                                */
--- 916,922 ----
*************** send_function_to_child(void)
*** 1027,1038 ****
  }
  
  void 
- #ifdef _NO_PROTO
- send_buff_to_child(chann)
-      int chann;
- #else
  send_buff_to_child(int chann)
- #endif
  {
    if (buff_pntr > 0)
      write(chann, buff, buff_pntr);
--- 948,954 ----
*** src/lib/emupty.c.pamphlet	(revision 15245)
--- src/lib/emupty.c.pamphlet	(local)
*************** SOFTWARE, EVEN IF ADVISED OF THE POSSIBI
*** 62,74 ****
  #include "sys/devinfo.h"
  #include <sys/ioctl.h>
  
! emuhft(arg, tty, ptc, len)
!     union {
!         struct hfintro *hf;
!         struct hfctlreq *re;
!         char *c;
!     }   arg;
!     int tty, ptc, len;
  {
      /* What does it do? */
      /* 1.  There are a number of ioctl's associated with the HFT terminal. */
--- 62,74 ----
  #include "sys/devinfo.h"
  #include <sys/ioctl.h>
  
! typedef union {
!    struct hfintro *hf;
!    struct hfctlreq *re;
!    char *c;
! } Argument;
! 
! emuhft(Argument arg, int tty, int ptc, int len)
  {
      /* What does it do? */
      /* 1.  There are a number of ioctl's associated with the HFT terminal. */
*************** emuhft(arg, tty, ptc, len)
*** 230,237 ****
  
  #endif
  
! static int _ThatsAll_(x) 
! int x; 
  {
  return x;
  }
--- 230,236 ----
  
  #endif
  
! static int _ThatsAll_(int x) 
  {
  return x;
  }
*** src/lib/fnct_key.c.pamphlet	(revision 15245)
--- src/lib/fnct_key.c.pamphlet	(local)
*************** char editorfilename[100];
*** 114,124 ****
   */
  
  void 
! #ifdef _NO_PROTO
! set_editor_key()
! #else
! set_editor_key(void )
! #endif
  {
      int pid;
  
--- 114,120 ----
   */
  
  void 
! set_editor_key(void)
  {
      int pid;
  
*************** set_editor_key(void )
*** 133,148 ****
  
  
  
- void
- #ifdef _NO_PROTO
- define_function_keys()
- #else
- define_function_keys(void )
- #endif
  /***  This routine id used to find the users function key mappings. It
      simply searches the users HOME directory for a file called ".clef".
      If found it gets the key bindings from within
      *****/
  {
      char *HOME, path[1024], string[1024];
      int key;
--- 129,141 ----
  
  
  
  /***  This routine id used to find the users function key mappings. It
      simply searches the users HOME directory for a file called ".clef".
      If found it gets the key bindings from within
      *****/
+ 
+ void
+ define_function_keys(void)
  {
      char *HOME, path[1024], string[1024];
      int key;
*************** define_function_keys(void )
*** 216,228 ****
  #define defof(c) ((c == 'F' || c == 'D' || c == 'E')?(1):(0))
  
  int
- #ifdef _NO_PROTO
- get_key(fd, ty)
-     int fd;
-     char *ty;
- #else
  get_key(int fd,char * ty)
- #endif
  {
  
      /*
--- 209,215 ----
*************** get_key(int fd,char * ty)
*** 248,260 ****
  }
  
  int
- #ifdef _NO_PROTO
- get_str(fd, string)
-     int fd;
-     char *string;
- #else
  get_str(int fd,char * string)
- #endif
  {
      /** Gets the key mapping being bound **/
      char c;
--- 235,241 ----
*************** get_str(int fd,char * string)
*** 275,297 ****
  }
  
  void 
- #ifdef _NO_PROTO
- null_fnct(sig)
-      int sig;
- #else
  null_fnct(int sig)
- #endif
  {
      return;
  }
  
  void 
- #ifdef _NO_PROTO
- handle_function_key(key, chann)
-     int key, chann;
- #else
  handle_function_key(int key,int  chann)
- #endif
  {
      /** this procedure simply adds the string specified by the function key
        to the buffer                                               ****/
--- 256,268 ----
*** src/lib/halloc.c.pamphlet	(revision 15245)
--- src/lib/halloc.c.pamphlet	(local)
*************** SOFTWARE, EVEN IF ADVISED OF THE POSSIBI
*** 59,71 ****
  
  /* allocate memory and bomb if none left (hyperTeX alloc) */
  char *
- #ifdef _NO_PROTO
- halloc(bytes, msg)
-     int bytes;
-     char *msg;
- #else
  halloc(int bytes,char * msg)
- #endif
  {
      static char buf[200];
      char *result;
--- 59,65 ----
*** src/lib/hash.c.pamphlet	(revision 15245)
--- src/lib/hash.c.pamphlet	(local)
*************** SOFTWARE, EVEN IF ADVISED OF THE POSSIBI
*** 62,76 ****
  /* initialize a hash table */
  
  void
! #ifndef _NO_PROTO
! hash_init(HashTable *table, int size, EqualFunction equal, HashcodeFunction hash_code)
! #else
! hash_init(table,size,equal,hash_code)
! HashTable *table;
! int size;
! EqualFunction equal;
! HashcodeFunction hash_code;
! #endif
  {
      int i;
  
--- 62,69 ----
  /* initialize a hash table */
  
  void
! hash_init(HashTable *table, int size, EqualFunction equal, 
!           HashcodeFunction hash_code)
  {
      int i;
  
*************** HashcodeFunction hash_code;
*** 85,97 ****
  }
  
  void
- #ifndef _NO_PROTO
  free_hash(HashTable *table, FreeFunction free_fun)
- #else
- free_hash(table,free_fun)
- HashTable *table;
- FreeFunction free_fun;
- #endif
  {
    if (table) {
      int i;
--- 78,84 ----
*************** FreeFunction free_fun;
*** 114,127 ****
  /* insert an entry into a hash table */
  
  void
- #ifndef _NO_PROTO
  hash_insert(HashTable *table, char *data, char *key)
- #else
- hash_insert(table,data,key)
- HashTable *table;
- char *data;
- char *key;
- #endif
  {
      HashEntry *entry = (HashEntry *) halloc(sizeof(HashEntry), "HashEntry");
      int code;
--- 101,107 ----
*************** char *key;
*** 138,150 ****
  }
  
  char *
- #ifndef _NO_PROTO
  hash_find(HashTable *table, char *key)
- #else
- hash_find(table,key)
- HashTable *table;
- char *key;
- #endif
  {
      HashEntry *entry;
      int code = table->hash_code(key, table->size) % table->size;
--- 118,124 ----
*************** char *key;
*** 156,169 ****
  }
  
  char *
- #ifndef _NO_PROTO
  hash_replace(HashTable *table, char *data, char *key)
- #else
- hash_replace(table,data,key)
- HashTable *table;
- char *data;
- char *key;
- #endif
  {
      HashEntry *entry;
      int code = table->hash_code(key, table->size) % table->size;
--- 130,136 ----
*************** char *key;
*** 177,189 ****
  }
  
  void
- #ifndef _NO_PROTO
  hash_delete(HashTable *table, char *key)
- #else
- hash_delete(table,key)
- HashTable *table;
- char *key;
- #endif
  {
      HashEntry **entry;
      int code = table->hash_code(key, table->size) % table->size;
--- 144,150 ----
*************** char *key;
*** 197,209 ****
  }
  
  void
- #ifndef _NO_PROTO
  hash_map(HashTable *table, MappableFunction func)
- #else
- hash_map(table,func)
- HashTable *table;
- MappableFunction func;
- #endif
  {
      int i;
      HashEntry *e;
--- 158,164 ----
*************** MappableFunction func;
*** 216,227 ****
  }
  
  HashEntry *
- #ifndef _NO_PROTO
  hash_copy_entry(HashEntry *e)
- #else
- hash_copy_entry(e)
- HashEntry *e;
- #endif
  {
      HashEntry *ne;
  
--- 171,177 ----
*************** HashEntry *e;
*** 236,247 ****
  
  /* copy a hash table */
  HashTable *
- #ifndef _NO_PROTO
  hash_copy_table(HashTable *table)
- #else
- hash_copy_table(table)
- HashTable *table;
- #endif
  {
      HashTable *nt = (HashTable *) halloc(sizeof(HashTable), "copy hash table");
      int i;
--- 186,192 ----
*************** HashTable *table;
*** 259,271 ****
  
  /* hash code function for strings */
  int
- #ifndef _NO_PROTO
  string_hash(char *s, int size)
- #else
- string_hash(s,size)
- char *s;
- int size;
- #endif
  {
      int c = 0;
      char *p =s;
--- 204,210 ----
*************** int size;
*** 279,302 ****
  /* test strings for equality */
  
  int
- #ifndef _NO_PROTO
  string_equal(char *s1, char *s2)
- #else
- string_equal(s1,s2)
- char *s1,*s2;
- #endif
  {
      return (strcmp(s1, s2) == 0);
  }
  
  /* make a fresh copy of the given string */
  char *
- #ifndef _NO_PROTO
  alloc_string(char *str)
- #else
- alloc_string(str)
- char *str;
- #endif
  {
      char * result;
      result = halloc(strlen(str)+1,"String");
--- 218,231 ----
*** src/lib/openpty.c.pamphlet	(revision 15245)
--- src/lib/openpty.c.pamphlet	(local)
*************** SOFTWARE, EVEN IF ADVISED OF THE POSSIBI
*** 94,108 ****
  
  
  int  
- #ifdef _NO_PROTO
- ptyopen(controller, server, controllerPath, serverPath)
-      int *controller;
-      int *server;
-      char *controllerPath, *serverPath;
- #else
  ptyopen(int *controller,int * server, char *controllerPath,char * serverPath)
- #endif
- 
  {
  #if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) ||defined(AIX370platform) || defined(BSDplatform)
    int looking = 1, i;
--- 94,100 ----
*************** extern char* ptsname(int);
*** 203,214 ****
  
  
  void 
- #ifdef _NO_PROTO
- makeNextPtyNames(cont, serv)
- char *cont, *serv;
- #else
  makeNextPtyNames(char *cont,char * serv)
- #endif
  {
  #ifdef AIX370platform
  	static int channelNo = 0;
--- 195,201 ----
*** src/lib/pixmap.c.pamphlet	(revision 15245)
--- src/lib/pixmap.c.pamphlet	(local)
*************** On the [[MAC OSX]] platform they defined
*** 14,25 ****
  is only used in this file we simply rename it to [[zzopen]].
  <<mac zopen redefinition 1>>=
  FILE *
- #ifdef _NO_PROTO
- zzopen(file, mode)
-     char *file, *mode;
- #else
  zzopen(char *file,char * mode)
- #endif
  @
  <<mac zopen redefinition 2>>=
      file = zzopen(filename, "r");
--- 14,20 ----
*************** SOFTWARE, EVEN IF ADVISED OF THE POSSIBI
*** 87,98 ****
  /* returns true if the file exists */
  
  int
- #ifdef _NO_PROTO
- file_exists(file)
-     char *file;
- #else
  file_exists(char *file)
- #endif
  {
      FILE *f;
  
--- 82,88 ----
*************** file_exists(char *file)
*** 142,156 ****
  
  ********************************************************************/
  void
! #ifdef _NO_PROTO
! write_pixmap_file(dsp, scr, fn, wid, x, y, width, height)
!     Display *dsp;
!     char *fn;
!     Window wid;                 /* this is originally a Pixmap */
!     int scr, x, y, width, height;
! #else
! write_pixmap_file(Display *dsp, int scr, char  *fn, Window wid, int x, int y, int width,int height)
! #endif
  {
      XImage *xi;
      FILE *file;
--- 132,140 ----
  
  ********************************************************************/
  void
! write_pixmap_file(Display *dsp, int scr, char  *fn, 
!                   Window wid /* the original pixmap/, 
!                   int x, int y, int width,int height)
  {
      XImage *xi;
      FILE *file;
*************** write_pixmap_file(Display *dsp, int scr,
*** 221,236 ****
  
  ********************************************************************/
  int
! #ifdef _NO_PROTO
! read_pixmap_file(display, screen, filename, xi, width, height)
!     Display *display;
!     int screen;
!     char *filename;
!     XImage **xi;
!     int *width, *height;
! #else
! read_pixmap_file(Display *display, int screen, char *filename,XImage **xi, int *width, int *height)
! #endif
  {
      FILE *file;
      int wi, h, num, num_colors, read_this_time, offset;
--- 205,212 ----
  
  ********************************************************************/
  int
! read_pixmap_file(Display *display, int screen, char *filename,
!                  XImage **xi, int *width, int *height)
  {
      FILE *file;
      int wi, h, num, num_colors, read_this_time, offset;
*************** read_pixmap_file(Display *display, int s
*** 315,330 ****
  #include "xpm.h"
  
  int
! #ifdef _NO_PROTO
! read_pixmap_file(display, screen, filename, xi, width, height)
!     Display *display;
!     int screen;
!     char *filename;
!     XImage **xi;
!     int *width, *height;
! #else
! read_pixmap_file(Display *display, int screen, char *filename,XImage **xi, int *width, int *height)
! #endif
  {
    XpmAttributes attr;
    XImage *xireturn;
--- 291,298 ----
  #include "xpm.h"
  
  int
! read_pixmap_file(Display *display, int screen, char *filename,
!                  XImage **xi, int *width, int *height)
  {
    XpmAttributes attr;
    XImage *xireturn;
*************** read_pixmap_file(Display *display, int s
*** 359,373 ****
  
  
  void
! #ifdef _NO_PROTO
! write_pixmap_file(dsp, scr, fn, wid, x, y, width, height)
!     Display *dsp;
!     char *fn;
!     Window wid;                 /* this is originally a Pixmap */
!     int scr, x, y, width, height;
! #else
! write_pixmap_file(Display *dsp, int scr, char  *fn, Window wid, int x, int y, int width,int height)
! #endif
  {
    XImage *xi;
    int status;
--- 327,335 ----
  
  
  void
! write_pixmap_file(Display *dsp, int scr, char  *fn, 
!                   Window wid /* the original pixmap/, 
!                   int x, int y, int width,int height)
  {
    XImage *xi;
    int status;
*** src/lib/prt.c.pamphlet	(revision 15245)
--- src/lib/prt.c.pamphlet	(local)
*************** SOFTWARE, EVEN IF ADVISED OF THE POSSIBI
*** 57,68 ****
  #include "edin.H1"
  
  void
- #ifdef _NO_PROTO
- myputchar(c)
-     char c;
- #else
  myputchar(char c)
- #endif
  {
      if (ECHOIT)
          putchar(c);
--- 57,63 ----
*************** myputchar(char c)
*** 70,80 ****
  }
  
  void 
- #ifdef _NO_PROTO
- clear_buff()
- #else
  clear_buff(void)
- #endif
  {
      int count;
  
--- 65,71 ----
*************** clear_buff(void)
*** 99,109 ****
  
  
  void 
- #ifdef _NO_PROTO
- move_end()
- #else
  move_end(void)
- #endif
  {
  
      /** Moves cursor to the end of the line ***/
--- 90,96 ----
*************** move_end(void)
*** 119,129 ****
  }
  
  void 
- #ifdef _NO_PROTO
- move_home()
- #else
  move_home(void)
- #endif
  {
  
      /*** Moves the cursor to the front of the line ***/
--- 106,112 ----
*************** move_home(void)
*** 141,151 ****
  }
  
  void 
- #ifdef _NO_PROTO
- move_fore_word()
- #else
  move_fore_word(void)
- #endif
  {
      /** move the cursor to the next blank space  **/
      if (curr_pntr != buff_pntr) {
--- 124,130 ----
*************** move_fore_word(void)
*** 163,173 ****
  }
  
  void 
- #ifdef _NO_PROTO
- move_back_word()
- #else
  move_back_word(void)
- #endif
  {
      /*** moves the cursor to the last blank space ***/
      if (curr_pntr > 0) {
--- 142,148 ----
*************** move_back_word(void)
*** 186,196 ****
  }
  
  void 
- #ifdef _NO_PROTO
- delete_current_char()
- #else
  delete_current_char(void)
- #endif
  {
      /**  deletes the char currently above the current_pntr, if it can be **/
      if (curr_pntr != buff_pntr) {
--- 161,167 ----
*************** delete_current_char(void)
*** 226,236 ****
  }
  
  void 
- #ifdef _NO_PROTO
- delete_to_end_of_line()
- #else
  delete_to_end_of_line(void)
- #endif
  {
      int count;
  
--- 197,203 ----
*************** delete_to_end_of_line(void)
*** 254,264 ****
  }
  
  void 
- #ifdef _NO_PROTO
- delete_line()
- #else
  delete_line(void)
- #endif
  {
      int count;
  
--- 221,227 ----
*************** delete_line(void)
*** 290,302 ****
  }
  
  void 
- #ifdef _NO_PROTO
- printbuff(start, num)
-     int start;
-     int num;
- #else
  printbuff(int start,int  num)
- #endif
  {
      int trace;
  
--- 253,259 ----
*************** printbuff(int start,int  num)
*** 307,318 ****
  }
  
  void
- #ifdef _NO_PROTO
- del_print(start, num)
-     int start, num;
- #else
  del_print(int start, int num)
- #endif
  {
      int count;
  
--- 264,270 ----
*************** del_print(int start, int num)
*** 331,343 ****
  
  
  void 
- #ifdef _NO_PROTO
- ins_print(start, num)
-     int start;
-     int num;
- #else
  ins_print(int start,int  num)
- #endif
  {
      int count;
  
--- 283,289 ----
*************** ins_print(int start,int  num)
*** 352,362 ****
  }
  
  void 
- #ifdef _NO_PROTO
- reprint(start)
- #else
  reprint(int start)
- #endif
  {
      /**  simply reprints a single character **/
      if (buff[start] == '\0')
--- 298,304 ----
*************** reprint(int start)
*** 369,380 ****
  }
  
  void 
- #ifdef _NO_PROTO
- back_up(num_chars)
-     int num_chars;
- #else
  back_up(int num_chars)
- #endif
  {
      int cnt;
  
--- 311,317 ----
*************** back_up(int num_chars)
*** 389,400 ****
  }
  
  void 
- #ifdef _NO_PROTO
- back_it_up(num_chars)
-     int num_chars;
- #else
  back_it_up(int num_chars)
- #endif
  {
      int cnt;
  
--- 326,332 ----
*************** back_it_up(int num_chars)
*** 405,415 ****
  
  
  void 
- #ifdef _NO_PROTO
- print_whole_buff()
- #else
  print_whole_buff(void)
- #endif
  {
      int trace;
  
--- 337,343 ----
*************** print_whole_buff(void)
*** 420,430 ****
  }
  
  void
- #ifdef _NO_PROTO
- move_ahead()
- #else
  move_ahead(void)
- #endif
  {
      /*** simply moves the pointer ahead a single word ***/
      if (curr_pntr == buff_pntr) {
--- 348,354 ----
*************** move_ahead(void)
*** 440,450 ****
  }
  
  void
- #ifdef _NO_PROTO
- move_back()
- #else
  move_back(void)
- #endif
  {
      /** simply moves the cursor back one position **/
      if (curr_pntr == 0) {
--- 364,370 ----
*************** move_back(void)
*** 462,472 ****
  }
  
  void
- #ifdef _NO_PROTO
- back_over_current_char()
- #else
  back_over_current_char(void)
- #endif
  {
      /*** simply backs over the character behind the cursor ***/
      if (curr_pntr == 0) {
--- 382,388 ----
*** src/lib/sockio-c.c.pamphlet	(revision 15245)
--- src/lib/sockio-c.c.pamphlet	(local)
*************** int still_reading  = 0;
*** 105,130 ****
  #include "sockio-c.H1"
  
  void  
- #ifdef _NO_PROTO 
- sigpipe_handler(sig)
-      int sig;
- #else
  sigpipe_handler(int sig)
- #endif
  {
    socket_closed = 1;
  }
  
  int 
- #ifdef _NO_PROTO 
- wait_for_client_read(sock, buf, buf_size, msg)
-      Sock *sock;
-      char *buf;
-      int buf_size;
-      char *msg;
- #else
  wait_for_client_read(Sock *sock,char *buf,int buf_size,char *msg)
- #endif
  {
    int ret_val;
    switch(sock->purpose) {
--- 105,117 ----
*************** wait_for_client_read(Sock *sock,char *bu
*** 141,155 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- wait_for_client_write(sock, buf, buf_size, msg)
-      Sock *sock;
-      char *buf;
-      int buf_size;
-      char *msg;
- #else
  wait_for_client_write(Sock *sock,char *buf,int buf_size,char *msg)
- #endif
  {
    int ret_val;
    switch(sock->purpose) {
--- 128,134 ----
*************** wait_for_client_write(Sock *sock,char *b
*** 166,180 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sread(sock, buf, buf_size, msg)
-      Sock *sock;
-      char *buf;
-      int buf_size;
-      char *msg;
- #else
  sread(Sock *sock,char *buf,int buf_size,char *msg)
- #endif
  {
    int ret_val;
    char err_msg[256];
--- 145,151 ----
*************** sread(Sock *sock,char *buf,int buf_size,
*** 199,213 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- swrite(sock, buf, buf_size, msg)
-      Sock *sock;
-      char *buf;
-      int buf_size;
-      char *msg;
- #else
  swrite(Sock *sock,char *buf,int buf_size,char *msg)
- #endif
  {
    int ret_val;
    char err_msg[256];
--- 170,176 ----
*************** swrite(Sock *sock,char *buf,int buf_size
*** 233,246 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sselect(n, rd, wr, ex, timeout)
-      int n;
-      fd_set *rd, *wr, *ex;
-      void *timeout;
- #else
  sselect(int n,fd_set  *rd, fd_set  *wr, fd_set *ex, void *timeout)
- #endif
  {
    int ret_val;
    do {
--- 196,202 ----
*************** sselect(int n,fd_set  *rd, fd_set  *wr, 
*** 250,264 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- fill_buf(sock, buf, len, msg)
-      Sock *sock;
-      char *buf;
-      int len;
-      char *msg;
- #else
  fill_buf(Sock *sock,char *buf, int len, char *msg)
- #endif
  {
    int bytes =  0, ret_val;
    while(bytes < len) {
--- 206,212 ----
*************** fill_buf(Sock *sock,char *buf, int len, 
*** 270,281 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- get_int(sock)
-      Sock *sock;
- #else
  get_int(Sock *sock)
- #endif
  {
    int val = -1, len;
    len = fill_buf(sock, (char *)&val, sizeof(int), "integer");
--- 218,224 ----
*************** get_int(Sock *sock)
*** 292,303 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_get_int(purpose)
-      int purpose;
- #else
  sock_get_int(int purpose)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return get_int(purpose_table[purpose]);
--- 235,241 ----
*************** sock_get_int(int purpose)
*** 305,317 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- get_ints(sock, vals, num)
-      Sock *sock;
-      int *vals, num;
- #else
  get_ints(Sock *sock, int *vals, int num)
- #endif
  {
    int i;
    for(i=0; i<num; i++)
--- 243,249 ----
*************** get_ints(Sock *sock, int *vals, int num)
*** 320,331 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_get_ints(purpose, vals, num)
-      int purpose, *vals, num;
- #else
  sock_get_ints(int purpose, int *vals, int num)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return get_ints(purpose_table[purpose], vals, num);
--- 252,258 ----
*************** sock_get_ints(int purpose, int *vals, in
*** 333,345 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- send_int(sock, val)
-      Sock *sock;
-      int val;
- #else
  send_int(Sock *sock,int val)
- #endif
  {
    int ret_val;
    ret_val = swrite(sock, (char *)&val, sizeof(int), NULL);
--- 260,266 ----
*************** send_int(Sock *sock,int val)
*** 350,361 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_send_int(purpose, val)
-      int purpose, val;
- #else
  sock_send_int(int purpose,int  val)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return send_int(purpose_table[purpose], val);
--- 271,277 ----
*************** sock_send_int(int purpose,int  val)
*** 363,375 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- send_ints(sock, vals, num)
-      Sock *sock;
-      int *vals, num;
- #else
  send_ints(Sock *sock, int *vals, int num)
- #endif
  {
    int i;
    for(i=0; i<num; i++)
--- 279,285 ----
*************** send_ints(Sock *sock, int *vals, int num
*** 379,390 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_send_ints(purpose, vals, num)
-      int purpose, *vals, num;
- #else
  sock_send_ints(int purpose, int *vals, int num)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return send_ints(purpose_table[purpose], vals, num);
--- 289,295 ----
*************** sock_send_ints(int purpose, int *vals, i
*** 392,405 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- send_string_len(sock, str, len)
-      Sock *sock;
-      char *str;
-      int len;
- #else
  send_string_len(Sock *sock,char *str,int len)
- #endif
  {
    int val;
    if (len > 1023) {
--- 297,303 ----
*************** send_string_len(Sock *sock,char *str,int
*** 424,436 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- send_string(sock, str)
-      Sock *sock;
-      char *str;
- #else
  send_string(Sock *sock, char *str)
- #endif
  {
    int val, len = strlen(str);
    send_int(sock, len+1);
--- 322,328 ----
*************** send_string(Sock *sock, char *str)
*** 443,455 ****
  
  
  int 
- #ifdef _NO_PROTO 
- sock_send_string(purpose, str)
-      int purpose;
-      char *str;
- #else
  sock_send_string(int purpose, char *str)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return send_string(purpose_table[purpose], str);
--- 335,341 ----
*************** sock_send_string(int purpose, char *str)
*** 457,470 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_send_string_len(purpose, str, len)
-      int purpose;
-      char *str;
-      int len;
- #else
  sock_send_string_len(int purpose, char * str, int len)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return send_string_len(purpose_table[purpose], str, len);
--- 343,349 ----
*************** sock_send_string_len(int purpose, char *
*** 472,485 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- send_strings(sock, vals, num)
-      Sock *sock;
-      char **vals;
-      int num;
- #else
  send_strings(Sock *sock, char ** vals, int num)
- #endif
  {
    int i;
    for(i=0; i<num; i++)
--- 351,357 ----
*************** send_strings(Sock *sock, char ** vals, i
*** 489,502 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_send_strings(purpose, vals, num)
-      int purpose;
-      char **vals;
-      int num;
- #else
  sock_send_strings(int purpose, char **vals, int num)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return send_strings(purpose_table[purpose], vals, num);
--- 361,367 ----
*************** sock_send_strings(int purpose, char **va
*** 504,515 ****
  }
  
  char *
- #ifdef _NO_PROTO 
- get_string(sock)
-      Sock *sock;
- #else
  get_string(Sock *sock)
- #endif
  {
    int val, len;
    char *buf;
--- 369,375 ----
*************** get_string(Sock *sock)
*** 528,539 ****
  }
  
  char *
- #ifdef _NO_PROTO 
- sock_get_string(purpose)
-      int purpose;
- #else
  sock_get_string(int purpose)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return get_string(purpose_table[purpose]);
--- 388,394 ----
*************** sock_get_string(int purpose)
*** 542,555 ****
  
  
  char *
- #ifdef _NO_PROTO 
- get_string_buf(sock, buf, buf_len)
-      Sock *sock;
-      char *buf;
-      int buf_len;
- #else
  get_string_buf(Sock *sock, char *buf, int buf_len)
- #endif
  {
    int val;
    if(!str_len) str_len = get_int(sock);
--- 397,403 ----
*************** get_string_buf(Sock *sock, char *buf, in
*** 570,583 ****
  }
  
  char *
- #ifdef _NO_PROTO 
- sock_get_string_buf(purpose, buf, buf_len)
-      int purpose;
-      char *buf;
-      int buf_len;
- #else
  sock_get_string_buf(int purpose, char * buf, int buf_len)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return get_string_buf(purpose_table[purpose], buf, buf_len);
--- 418,424 ----
*************** sock_get_string_buf(int purpose, char * 
*** 585,598 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- get_strings(sock, vals, num)
-      Sock *sock;
-      char **vals;
-      int num;
- #else
  get_strings(Sock *sock,char **vals,int num)
- #endif
  {
    int i;
    for(i=0; i<num; i++)
--- 426,432 ----
*************** get_strings(Sock *sock,char **vals,int n
*** 601,614 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_get_strings(purpose, vals, num)
-      int purpose;
-      char **vals;
-      int num;
- #else
  sock_get_strings(int purpose, char ** vals, int num)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return get_strings(purpose_table[purpose], vals, num);
--- 435,441 ----
*************** sock_get_strings(int purpose, char ** va
*** 616,628 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- send_float(sock, num)
-      Sock *sock;
-      double num;
- #else
  send_float(Sock *sock, double num)
- #endif
  {
    int val;
    val = swrite(sock, (char *)&num, sizeof(double), NULL);
--- 443,449 ----
*************** send_float(Sock *sock, double num)
*** 633,645 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_send_float(purpose, num)
-      int purpose;
-      double num;
- #else
  sock_send_float(int purpose, double num)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return send_float(purpose_table[purpose], num);
--- 454,460 ----
*************** sock_send_float(int purpose, double num)
*** 647,660 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- send_sfloats(sock, vals, num)
-      Sock *sock;
-      float *vals;
-      int num;
- #else
  send_sfloats(Sock *sock, float *vals,int  num)
- #endif
  {
    int i;
    for(i=0; i<num; i++)
--- 462,468 ----
*************** send_sfloats(Sock *sock, float *vals,int
*** 664,677 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_send_sfloats(purpose, vals, num)
-      int purpose;
-      float *vals;
-      int num;
- #else
  sock_send_sfloats(int purpose, float * vals, int num)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return send_sfloats(purpose_table[purpose], vals, num);
--- 472,478 ----
*************** sock_send_sfloats(int purpose, float * v
*** 679,692 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- send_floats(sock, vals, num)
-      Sock *sock;
-      double *vals;
-      int num;
- #else
  send_floats(Sock *sock, double *vals, int num)
- #endif
  {
    int i;
    for(i=0; i<num; i++)
--- 480,486 ----
*************** send_floats(Sock *sock, double *vals, in
*** 696,709 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_send_floats(purpose, vals, num)
-      int purpose;
-      double *vals;
-      int num;
- #else
  sock_send_floats(int purpose, double  *vals, int num)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return send_floats(purpose_table[purpose], vals, num);
--- 490,496 ----
*************** sock_send_floats(int purpose, double  *v
*** 711,722 ****
  }
  
  double 
- #ifdef _NO_PROTO 
- get_float(sock)
-      Sock *sock;
- #else
  get_float(Sock *sock)
- #endif
  {
    int val;
    double num = -1.0;
--- 498,504 ----
*************** get_float(Sock *sock)
*** 728,739 ****
  }
  
  double 
- #ifdef _NO_PROTO 
- sock_get_float(purpose)
-      int purpose;
- #else
  sock_get_float(int purpose)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return get_float(purpose_table[purpose]);
--- 510,516 ----
*************** sock_get_float(int purpose)
*** 741,754 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- get_sfloats(sock, vals, num)
-      Sock *sock;
-      float *vals;
-      int num;
- #else
  get_sfloats(Sock *sock, float *vals, int num)
- #endif
  {
    int i;
    for(i=0; i<num; i++)
--- 518,524 ----
*************** get_sfloats(Sock *sock, float *vals, int
*** 758,771 ****
  
  
  int 
- #ifdef _NO_PROTO 
- sock_get_sfloats(purpose, vals, num)
-      int purpose;
-      float *vals;
-      int num;
- #else
  sock_get_sfloats(int purpose,float * vals, int num)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return get_sfloats(purpose_table[purpose], vals, num);
--- 528,534 ----
*************** sock_get_sfloats(int purpose,float * val
*** 773,786 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- get_floats(sock, vals, num)
-      Sock *sock;
-      double *vals;
-      int num;
- #else
  get_floats(Sock *sock,double *vals,int num)
- #endif
  {
    int i;
    for(i=0; i<num; i++)
--- 536,542 ----
*************** get_floats(Sock *sock,double *vals,int n
*** 790,803 ****
  
  
  int 
- #ifdef _NO_PROTO 
- sock_get_floats(purpose, vals, num)
-      int purpose;
-      double *vals;
-      int num;
- #else
  sock_get_floats(int purpose, double *vals, int num)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return get_floats(purpose_table[purpose], vals, num);
--- 546,552 ----
*************** sock_get_floats(int purpose, double *val
*** 805,817 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- wait_for_client_kill(sock, sig)
-      Sock *sock;
-      int sig;
- #else
  wait_for_client_kill(Sock *sock, int sig)
- #endif
  {
    int ret_val;
    switch(sock->purpose) {
--- 554,560 ----
*************** wait_for_client_kill(Sock *sock, int sig
*** 829,840 ****
  
  
  int 
- #ifdef _NO_PROTO 
- sock_get_remote_fd(purpose)
-      int purpose;
- #else
  sock_get_remote_fd(int purpose)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return purpose_table[purpose]->remote_fd;
--- 572,578 ----
*************** sock_get_remote_fd(int purpose)
*** 842,854 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- send_signal(sock, sig)
-      Sock *sock;
-      int sig;
- #else
  send_signal(Sock *sock, int sig)
- #endif
  {
    int ret_val;
    ret_val = kill(sock->pid, sig);
--- 580,586 ----
*************** send_signal(Sock *sock, int sig)
*** 863,874 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_send_signal(purpose, sig)
-      int purpose, sig;
- #else
  sock_send_signal(int purpose,int  sig)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return send_signal(purpose_table[purpose], sig);
--- 595,601 ----
*************** sock_send_signal(int purpose,int  sig)
*** 876,898 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- send_wakeup(sock)
-      Sock *sock;
- #else
  send_wakeup(Sock *sock)
- #endif
  {
    return send_signal(sock, SIGUSR1);
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_send_wakeup(purpose)
-      int purpose;
- #else
  sock_send_wakeup(int purpose)
- #endif
  {
    if (accept_if_needed(purpose) != -1)
      return send_wakeup(purpose_table[purpose]);
--- 603,615 ----
*************** sock_send_wakeup(int purpose)
*** 900,913 ****
  }
  
  Sock *
- #ifdef _NO_PROTO 
- connect_to_local_server_new(server_name, purpose, time_out)
-      char *server_name;
-      int purpose;
-      int time_out;
- #else
  connect_to_local_server_new(char *server_name, int purpose, int time_out)
- #endif
  {
    int max_con=(time_out == 0 ? 1000000 : time_out), i, code=-1;
    Sock *sock;
--- 617,623 ----
*************** connect_to_local_server_new(char *server
*** 953,966 ****
  }
  
  Sock *
- #ifdef _NO_PROTO 
- connect_to_local_server(server_name, purpose, time_out)
-      char *server_name;
-      int purpose;
-      int time_out;
- #else
  connect_to_local_server(char *server_name, int purpose, int time_out)
- #endif
  {
    int max_con=(time_out == 0 ? 1000000 : time_out), i, code=-1;
    Sock *sock;
--- 663,669 ----
*************** connect_to_local_server(char *server_nam
*** 1012,1023 ****
  /* act as terminal session for sock connected to stdin and stdout of another
     process */
  void 
- #ifdef _NO_PROTO 
- remote_stdio(sock)
-      Sock *sock;
- #else
  remote_stdio(Sock *sock)
- #endif
  {
    char buf[1024];
    fd_set rd;
--- 715,721 ----
*************** remote_stdio(Sock *sock)
*** 1057,1067 ****
  
  /* initialize the table of dedicated sockets */
  void 
- #ifdef _NO_PROTO 
- init_purpose_table()
- #else
  init_purpose_table(void)
- #endif
  {
    int i;
    for(i=0; i<TotalMaxPurposes; i++) {
--- 755,761 ----
*************** init_purpose_table(void)
*** 1071,1094 ****
  
  
  int 
! #ifdef _NO_PROTO 
! make_server_number()
! #else
! make_server_number(void )
! #endif
  {
    spad_server_number = getpid();
    return spad_server_number;
  }
  
  void 
- #ifdef _NO_PROTO 
- close_socket(socket_num, name)
-      int socket_num;
-      char *name;
- #else
  close_socket(int socket_num, char *name)
- #endif
  {
    close(socket_num);
  #ifndef RTplatform
--- 765,778 ----
  
  
  int 
! make_server_number(void)
  {
    spad_server_number = getpid();
    return spad_server_number;
  }
  
  void 
  close_socket(int socket_num, char *name)
  {
    close(socket_num);
  #ifndef RTplatform
*************** close_socket(int socket_num, char *name)
*** 1097,1108 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- make_server_name(name, base)
-      char *name, *base;
- #else
  make_server_name(char *name,char * base)
- #endif
  {
    char *num;
    if (spad_server_number != -1) {
--- 781,787 ----
*************** make_server_name(char *name,char * base)
*** 1123,1134 ****
  /* client Spad server sockets.  Two sockets are created: server[0]
     is the internet server socket, and server[1] is a UNIX domain socket. */
  int 
- #ifdef _NO_PROTO 
- open_server(server_name)
-      char *server_name;
- #else
  open_server(char *server_name)
- #endif
  {
    char *s, name[256];
  
--- 802,808 ----
*************** open_server(char *server_name)
*** 1192,1203 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- accept_connection(sock)
-      Sock *sock;
- #else
  accept_connection(Sock *sock)
- #endif
  {
    int client;
    for(client=0; client<MaxClients && clients[client].socket != 0; client++);
--- 866,872 ----
*************** accept_connection(Sock *sock)
*** 1218,1229 ****
  
  /* reads a the socket purpose declaration for classification */
  void 
- #ifdef _NO_PROTO 
- get_socket_type(sock)
-      Sock *sock;
- #else
  get_socket_type(Sock *sock)
- #endif
  {
    sock->pid = get_int(sock);
    sock->purpose = get_int(sock);
--- 887,893 ----
*************** get_socket_type(Sock *sock)
*** 1245,1256 ****
  }
  
  int 
- #ifdef _NO_PROTO 
- sock_accept_connection(purpose)
-      int purpose;
- #else
  sock_accept_connection(int purpose)
- #endif
  {
    fd_set rd;
    int ret_val, i, p;
--- 909,915 ----
*************** sock_accept_connection(int purpose)
*** 1273,1284 ****
  
  /* direct stdin and stdout from the given socket */
  void 
- #ifdef _NO_PROTO 
- redirect_stdio(sock)
-      Sock *sock;
- #else
  redirect_stdio(Sock *sock)
- #endif
  {
    int fd;
  /*  setbuf(stdout, NULL);  */
--- 932,938 ----
*************** redirect_stdio(Sock *sock)
*** 1297,1307 ****
  }
  
  void
- #ifdef _NO_PROTO 
- init_socks()
- #else
  init_socks(void)
- #endif
  {
    int i;
    FD_ZERO(&socket_mask);
--- 951,957 ----
*************** init_socks(void)
*** 1314,1324 ****
  /* Socket I/O selection called from the BOOT serverLoop function */
  
  int 
- #ifdef _NO_PROTO 
- server_switch()
- #else
  server_switch(void)
- #endif
  {
    int ret_val, i, cmd = 0;
    fd_set rd, wr, ex, fds_mask;
--- 964,970 ----
*************** server_switch(void)
*** 1364,1374 ****
  }
  
  void 
- #ifdef _NO_PROTO 
- flush_stdout()
- #else
  flush_stdout(void)
- #endif
  {
    static FILE *fp = NULL;
    if (fp == NULL) {
--- 1010,1016 ----
*************** flush_stdout(void)
*** 1382,1393 ****
  }
  
  void 
- #ifdef _NO_PROTO 
- print_line(s)
-      char *s;
- #else
  print_line(char *s)
- #endif
  {
    printf("%s\n", s);
  }
--- 1024,1030 ----
*************** typedef union {
*** 1399,1409 ****
  	} DoubleFloat;
  
  double 
- #ifdef _NO_PROTO 
- plus_infinity()
- #else
  plus_infinity(void )
- #endif
  {
    static int init = 0;
    static DoubleFloat pinf;
--- 1036,1042 ----
*************** plus_infinity(void )
*** 1416,1426 ****
  }
  
  double 
- #ifdef _NO_PROTO 
- minus_infinity()
- #else
  minus_infinity(void)
- #endif
  {
    static int init = 0;
    static DoubleFloat minf;
--- 1049,1055 ----
*************** minus_infinity(void)
*** 1433,1443 ****
  }
  
  double 
- #ifdef _NO_PROTO 
- NANQ()
- #else
  NANQ(void)
- #endif
  {
    static int init = 0;
    static DoubleFloat nanq;
--- 1062,1068 ----
*** src/lib/spadcolors.c.pamphlet	(revision 15245)
--- src/lib/spadcolors.c.pamphlet	(local)
*************** static unsigned long    pixels[smoothCon
*** 77,90 ****
  
  
  
- #ifdef _NO_PROTO
- RGB
- HSVtoRGB(hsv)
-     HSV hsv;
- #else
  RGB
  HSVtoRGB(HSV hsv)
- #endif
  {
      RGB rgb;
      float h, f, p, q, t;
--- 77,84 ----
*************** HSVtoRGB(HSV hsv)
*** 143,156 ****
      }
  }
  
- #ifdef _NO_PROTO
- float
- value(n1, n2, hue)
-     float n1, n2, hue;
- #else
  float
  value(float n1, float n2, float hue)
- #endif
  {
      float v;
  
--- 137,144 ----
*************** value(float n1, float n2, float hue)
*** 177,188 ****
  
  
  RGB
- #ifdef _NO_PROTO
- HLStoRGB(hls)
-     HLS hls;
- #else
  HLStoRGB(HLS hls)
- #endif
  {
      RGB rgb;
      float m1, m2;
--- 165,171 ----
*************** HLStoRGB(HLS hls)
*** 230,246 ****
   ******************************************************/
  
  int
- #ifdef _NO_PROTO
- makeColors(dsply, scrn, colorMap, colorIndex, total_Shades)
-     Display *dsply;
-     int scrn;
-     Colormap *colorMap;
-     unsigned long **colorIndex;
-     int *total_Shades;
- #else
  makeColors(Display *dsply, int scrn, Colormap *colorMap, 
  	   unsigned long **colorIndex, int *total_Shades)
- #endif
  {
  
      int h, s;
--- 213,220 ----
*************** makeColors(Display *dsply, int scrn, Col
*** 356,369 ****
  ***********************************************************************/
  
  int
- #ifdef _NO_PROTO
- makePermVector(dsply, scrn, permIndex)
-     Display *dsply;
-     int scrn;
-     unsigned long **permIndex;
- #else
  makePermVector(Display *dsply, int scrn, unsigned long **permIndex)
- #endif
  {
      static int firstTime = yes;
      unsigned long *spadColorsToo;
--- 330,336 ----
*************** makePermVector(Display *dsply, int scrn,
*** 427,440 ****
  
  
  int
- #ifdef _NO_PROTO
- makeNewColorMap(dsply, colorMap, smoothHue)
-     Display *dsply;
-     Colormap colorMap;
-     int smoothHue;
- #else
  makeNewColorMap(Display *dsply, Colormap colorMap, int smoothHue)
- #endif
  
  {
  
--- 394,400 ----
*************** makeNewColorMap(Display *dsply, Colormap
*** 491,503 ****
   ******************************************************/
  
  unsigned long
- #ifdef _NO_PROTO
- XPixelColor(num)
-     int num;
- #else
  XPixelColor(int num)
- #endif
- 
  {
      if (num < 0)
          num = 0;
--- 451,457 ----
*************** XPixelColor(int num)
*** 520,533 ****
  
  
  void
- #ifdef _NO_PROTO
- FreePixels(dsply, colorMap, num)
-     Display *dsply;
-     Colormap colorMap;
-     int num;
- #else
  FreePixels(Display *dsply, Colormap colorMap, int num)
- #endif
  {
  
    XFreeColors(dsply, colorMap, pixels, num, 0);
--- 474,480 ----
*************** FreePixels(Display *dsply, Colormap colo
*** 557,570 ****
  
  
  int
- #ifdef _NO_PROTO
- AllocCells(dsply, colorMap, smoothHue)
-     Display *dsply;
-     Colormap colorMap;
-     int smoothHue;
- #else
  AllocCells(Display *dsply, Colormap colorMap, int smoothHue)
- #endif
  @
  This routine used to have the following code block. However this
  code block makes no sense. To see why you need to know that an
--- 504,510 ----
*** src/lib/util.c.pamphlet	(revision 15245)
--- src/lib/util.c.pamphlet	(local)
*************** of files are badly broken with respect t
*** 42,54 ****
  
  
  int
- #ifdef _NO_PROTO
- checker(code, lineNumber, errorStr)
-     int code, lineNumber;
-     char *errorStr;
- #else
  checker(int code, int lineNumber, char *errorStr)
- #endif
  {
    if (code < 0) {
      fprintf(stderr, "Error occured during %s\n", errorStr);
--- 42,48 ----
*************** checker(int code, int lineNumber, char *
*** 63,76 ****
  
  
  char *
- #ifdef _NO_PROTO
- getmemWithLine(nbytes, str, lineNum)
-     char *str;
-     int nbytes;
-     int lineNum;
- #else
  getmemWithLine(int nbytes, char *str, int lineNum)
- #endif
  {
    char *p;
  
--- 57,63 ----
*************** getmemWithLine(int nbytes, char *str, in
*** 84,98 ****
  
  
  char *
- #ifdef _NO_PROTO
- saymemWithLine(str, num, size, lineNum)
-     char *str;
-     int num, size;
-     int lineNum;
- #else
  saymemWithLine(char *str, int num, int size, int lineNum)
- #endif
- 
  {
    char *p;
  
--- 71,77 ----
*************** myfree(void *p, int size)
*** 118,130 ****
  
  
  XPoint
- #ifdef _NO_PROTO
- getWindowPositionXY(display, w)
-     Display *display;
-     Window w;
- #else
  getWindowPositionXY(Display *display, Window w)
- #endif
  {
    XPoint position;
    Window rootW, parentW, *childrenWs, tmpW;
--- 97,103 ----
*************** getWindowPositionXY(Display *display, Wi
*** 152,164 ****
  
  
  XPoint
- #ifdef _NO_PROTO
- getWindowSizeXY(display, w)
-     Display *display;
-     Window w;
- #else
  getWindowSizeXY(Display *display,Window w)
- #endif
  {
    XPoint size;
    Window rootW, parentW, *childrenWs, tmpW;
--- 125,131 ----
*** src/lib/wct.c.pamphlet	(revision 15245)
--- src/lib/wct.c.pamphlet	(local)
*************** static char curr_prefix[MAX_PREFIX];
*** 72,83 ****
  static Wct *pHeadwct;
  
  time_t
- #ifdef _NO_PROTO
- ftime(path)
-     char *path;
- #else
  ftime(char *path)
- #endif
  {
      int rc;
      struct stat stbuf;
--- 72,78 ----
*************** ftime(char *path)
*** 90,101 ****
  }
  
  off_t
- #ifdef _NO_PROTO
- fsize(path)
-     char *path;
- #else
  fsize(char *path)
- #endif
  {
      int rc;
      struct stat stbuf;
--- 85,91 ----
*************** fsize(char *path)
*** 114,126 ****
  
  
  Wix *
- #ifdef _NO_PROTO
- scanWct(pwct, prefix)
-     Wct *pwct;
-     char *prefix;
- #else
  scanWct(Wct *pwct, char *prefix)
- #endif
  {
      long fmod;
      int preflen, i, wc;
--- 104,110 ----
*************** scanWct(Wct *pwct, char *prefix)
*** 154,164 ****
  }
  
  Wix *
- #ifdef _NO_PROTO
- rescanWct()
- #else
  rescanWct(void)
- #endif
  {
    Wct *pwct, *start_pwct;
    int preflen, start_word, i, wc;
--- 138,144 ----
*************** rescanWct(void)
*** 236,247 ****
   * Summarize a table.
   */
  void
- #ifdef _NO_PROTO
- skimWct(pwct)
-     Wct *pwct;
- #else
  skimWct(Wct *pwct)
- #endif
  {
    while (pwct) {
  #ifdef PINFO
--- 216,222 ----
*************** skimWct(Wct *pwct)
*** 252,263 ****
  }
  
  void 
- #ifdef _NO_PROTO
- skim1Wct(pwct)
-     Wct *pwct;
- #else
  skim1Wct(Wct *pwct)
- #endif
  {
  #define NHEAD    13
  #define NTAIL    7
--- 227,233 ----
*************** skim1Wct(Wct *pwct)
*** 284,295 ****
  }
  
  void
- #ifdef _NO_PROTO
- printTime(clock)
-     long *clock;
- #else
  printTime(long *clock)
- #endif
  {
      struct tm *tm;
  
--- 254,260 ----
*************** printTime(long *clock)
*** 300,312 ****
  }
  
  int
- #ifdef _NO_PROTO
- skimString(s, slen, nhead, ntail)
-     char *s;
-     int slen, nhead, ntail;
- #else
  skimString(char *s, int slen,int  nhead,int  ntail)
- #endif
  {
      int spos, tlen, i, cc;
  
--- 265,271 ----
*************** skimString(char *s, int slen,int  nhead,
*** 330,341 ****
  }
  
  int
- #ifdef _NO_PROTO
- prChar(c)
-     int c;
- #else
  prChar(int c)
- #endif
  {
      if (c == '\n')
          return printf("\\n");
--- 289,295 ----
*************** prChar(int c)
*** 354,365 ****
  }
  
  Wct *
- #ifdef _NO_PROTO
- reread1Wct(pwct)
-     Wct *pwct;
- #else
  reread1Wct(Wct *pwct)
- #endif
  {
      int fd, rc;
  
--- 308,314 ----
*************** reread1Wct(Wct *pwct)
*** 387,398 ****
  }
  
  Wct *
- #ifdef _NO_PROTO
- read1Wct(fname)
-     char *fname;
- #else
  read1Wct(char *fname)
- #endif
  {
      Wct *pwct;
  
--- 336,342 ----
*************** read1Wct(char *fname)
*** 411,422 ****
  }
  
  Wct *
- #ifdef _NO_PROTO
- nconcWct(pwct, qwct)
-     Wct *pwct, *qwct;
- #else
  nconcWct(Wct *pwct,Wct * qwct)
- #endif
  {
      Wct *p0 = pwct;
  
--- 355,361 ----
*************** nconcWct(Wct *pwct,Wct * qwct)
*** 431,442 ****
  }
  
  void
- #ifdef _NO_PROTO
- sortWct(pwct)
-     Wct *pwct;
- #else
  sortWct(Wct *pwct)
- #endif
  {
      while (pwct) {
          sort1Wct(pwct);
--- 370,376 ----
*************** sortWct(Wct *pwct)
*** 445,468 ****
  }
  
  void 
- #ifdef _NO_PROTO
- sort1Wct(pwct)
-     Wct *pwct;
- #else
  sort1Wct(Wct *pwct)
- #endif
  {
      qsort((char *) pwct->wordv, pwct->wordc,
            sizeof(*(pwct->wordv)), mystrcmp);
  }
  
  int
- #ifdef _NO_PROTO
- mystrcmp(s1, s2)
-     const void *s1, *s2;
- #else
  mystrcmp(const void *s1,const void * s2)
- #endif
  {
      return strcmp(*(char **)s1, *(char **)s2);
  }
--- 379,392 ----
*************** mystrcmp(const void *s1,const void * s2)
*** 472,483 ****
   */
  
  void 
- #ifdef _NO_PROTO
- burstWct(pwct)
-     Wct *pwct;
- #else
  burstWct(Wct *pwct)
- #endif
  {
      while (pwct) {
          burst1Wct(pwct);
--- 396,402 ----
*************** burstWct(Wct *pwct)
*** 486,497 ****
  }
  
  void 
- #ifdef _NO_PROTO
- burst1Wct(pwct)
-     Wct *pwct;
- #else
  burst1Wct(Wct *pwct)
- #endif
  {
      char *s, **wv;
      int i, j, inword = 0;
--- 405,411 ----
*************** burst1Wct(Wct *pwct)
*** 527,538 ****
  }
  
  Wct *
- #ifdef _NO_PROTO
- intern1Wct(fname)
-     char *fname;
- #else
  intern1Wct(char *fname)
- #endif
  {
      Wct *pwct;
  
--- 441,447 ----
*************** intern1Wct(char *fname)
*** 542,577 ****
  }
  
  void 
- #ifdef _NO_PROTO
- reintern1Wct(pwct)
-     Wct *pwct;
- #else
  reintern1Wct(Wct *pwct)
- #endif
  {
      reread1Wct(pwct);
      burst1Wct(pwct);
  }
  
  void 
- #ifdef _NO_PROTO
- sfatal(s)
-     char *s;
- #else
  sfatal(char *s)
- #endif
  {
      fatal("%s", s);
  }
  
  void 
- #ifdef _NO_PROTO
- fatal(fmt, s)
-     char *fmt;
-     char *s;
- #else
  fatal(char *fmt,char * s)
- #endif
  {
      static char fbuf[256];
  
--- 451,470 ----
*************** fatal(char *fmt,char * s)
*** 585,606 ****
  
  /* load up the wct database */
  void 
- #ifdef _NO_PROTO
- load_wct_file(fname)
-     char *fname;
- #else
  load_wct_file(char *fname)
- #endif
  {
      pwct = nconcWct(intern1Wct(fname), pwct);
  }
  
  void
- #ifdef _NO_PROTO
- skim_wct()
- #else
  skim_wct(void)
- #endif
  {
      skimWct(pwct);
  }
--- 478,490 ----
*************** skim_wct(void)
*** 613,623 ****
  
  
  void 
- #ifdef _NO_PROTO
- rescan_wct()
- #else
  rescan_wct(void)
- #endif
  {
      int b = curr_pntr - 1;
      int old_len;
--- 497,503 ----
*************** rescan_wct(void)
*** 745,755 ****
  }
  
  void
- #ifdef _NO_PROTO
- find_wct()
- #else
  find_wct(void)
- #endif
  {
  
      char search_buff[100];
--- 625,631 ----

\start
Date: Wed, 22 Nov 2006 13:16:21 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: Re: Functors
Cc: Frederic Lehobey

Bill Page wrote:
> On Wednesday, November 22, 2006 4:35 AM Frederic Lehobey wrote:
> >     PrimeField(7)
> > 
> > and
> > 
> >     PrimeField(p)
> > 
> > both work in interpreted mode whereas the second one is not compiled
> > by the old compiler (it has already been discussed some time -- years
> > -- ago on axiom-dev).
> >
> 
> Are you referring to the discussion of dependent types in Aldor function
> definitions such as
> 
>   g(p:PositiveInteger,k:Integer):PrimeField(p) == k::PrimeField(p)
> 
> This looks innocent and "natural" in Aldor, and in the Axiom interpreter
> but William Sit and Ralf Hemmecke showed that in fact this is not really
> a function definition in the sense of category theory at all but rather
> a functor (i.e. package or domain constructor). See:
> 
> http://lists.nongnu.org/archive/html/axiom-developer/2005-01/msg00207.ht
> ml
> http://lists.nongnu.org/archive/html/axiom-developer/2005-01/msg00310.ht
> ml
> 
> In the Axiom/SPAD compiler you can write such a functor as
> 
> g(p:PositiveInteger, k:Integer):with point:()->PrimeField(p)
>   == add point()==k::PrimeField(p)
> 
> The function 'point' is necessary because a functor returns something
> of type category. The parameters pick out a particular function from
> the category. E.g.
> 
>   point()$g(7,4)
> 
> > ...
> 
> >From my point of view this is technically more correct than Aldor's
> syntax.

I must disagree here: main feature of dependent types is that they
depend on parameters -- one can say that normal types depend only
on constants.  Axiom goes half way here: it allows dependence on
parameters, but only if parameter is a "category/domain/package 
constant", that is you can only use expressions depending on constants
and constructor parameters as parameters for dependent types.

"Full support" for dependent types would require more forms (
function parameters, record fields).  From the point of view of
category theory you may be forced to introduce extra functors,
but I would say that whole point of dependent types is to hide
the extra machinery.

\start
Date: Wed, 22 Nov 2006 13:40:26 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: Re: Functors
Cc: Frederic Lehobey

>> In the Axiom/SPAD compiler you can write such a functor as
>>
>> g(p:PositiveInteger, k:Integer):with point:()->PrimeField(p)
>>   == add point()==k::PrimeField(p)

If that works with the spad compiler then why is there a belief that the 
spad compiler cannot handle dependent types?

Maybe the problem is that spad doesn't allow

g(p:PositiveInteger, k:Integer):PrimeField(p) == ...
???

Clearly the result type of g(p,k) depends on the input value of g.

>> The function 'point' is necessary because a functor returns something
>> of type category. The parameters pick out a particular function from
>> the category. E.g.
>>
>>   point()$g(7,4)
>>

>> >From my point of view this is technically more correct than Aldor's
>> syntax.

What syntax are you speaking about? I cannot see, why what Bill wrote is 
not Aldor syntax.

> I must disagree here: main feature of dependent types is that they
> depend on parameters -- one can say that normal types depend only
> on constants.

I don't understand that. But would you allow something like that in SPAD 
(not the interpreter)?

p: Integer := 5;
k: Integer := 17;
kmod5: PrimeField(p) := k :: PrimeField(p);
p := foo(p); -- results in p=7
kmod7: PrimeField(p) := k :: PrimeField(p);
kmod7 := kmod5 + kmod7

In order to type check that piece of code you need compile time 
evaluation of foo. That is the reason why Aldor requires parameters of 
types to be constant in the given context.
That has nothing to do with "dependent types" though.

 > Axiom goes half way here: it allows dependence on
> parameters, but only if parameter is a "category/domain/package 
> constant", that is you can only use expressions depending on constants
> and constructor parameters as parameters for dependent types.

Do you use "dependent type" as in

http://www.aldor.org/docs/HTML/chap7.html#4

?

> "Full support" for dependent types would require more forms (
> function parameters, record fields).  From the point of view of
> category theory you may be forced to introduce extra functors,
> but I would say that whole point of dependent types is to hide
> the extra machinery.

Could you elaborate on this?

\start
Date: Wed, 22 Nov 2006 07:44:00 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Functors
Cc: Frederic Lehobey

> In order to type check that piece of code you need compile time 
> evaluation of foo. That is the reason why Aldor requires parameters of 
> types to be constant in the given context.

In Axiom there would be no problem doing compile-time evaluation
provided the appropriate algebra is loaded.

\start
Date: 22 Nov 2006 14:37:43 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Testing build-improvements

Waldek Hebisch writes:

| Recent changes broken testing build-improvements.  The typical problem
| is that 'int/input/INTHEORY.input' contains sum of INTHEORY.spad and
| PNTHEORY.spad.

sorry, I don't understand.

\start
Date: Wed, 22 Nov 2006 14:44:19 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Building Axiom twice

The patch below eliminates the second build of Axiom and switches
tests to use AXIOMsys.  I also changed creation of target directories
to make it more logical. 

Remark1: We probably should make target directories at before starting
the proper build.  ATM we depend on previous stages to create target
directories which is error prone when we change build order -- in the
patch below I tried to create target directories when needed, but
this gets messy very quickly.

Remark2. From my point of view the stamp stuff in the main Makefile
is not doing anything usefull, Gaby may know what it was intended to
archive.

Remark3. For readability I removed diffs to generated files.

Remark4. ATM I can not test the patch properly, due to test breakage
on build-improvements that I reported earlier.


diff -ru build-improvements.bb/Makefile.pamphlet build-improvements/Makefile.pamphlet
--- build-improvements.bb/Makefile.pamphlet	2006-11-21 00:10:38.000000000 +0100
+++ build-improvements/Makefile.pamphlet	2006-11-21 02:27:34.000000000 +0100
@@ -263,10 +263,6 @@
 all-recursive: @axiom_required_build_utils@
 
 all-ax:
-	@ echo 1 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
-	@ echo 2 Environment ${ENV}
-	@ $(MAKE) stamp-rootdirs
-	@ ${ENV} $(MAKE) $(src_stamp)
 	@echo 3 finished system build on `date` | tee >lastBuildDate
 
 all-bootsys: $(lsp_stamp)
@@ -279,9 +275,6 @@
 <<noweb>>
 <<install>>
 
-$(src_stamp): $(lsp_stamp)
-	cd $(build_srcdir) && $(ENV) $(MAKE)
-
 $(lsp_stamp): $(lib_stamp)
 	cd $(build_lspdir) && $(ENV) $(MAKE)
 
diff -ru build-improvements.bb/src/etc/Makefile.pamphlet build-improvements/src/etc/Makefile.pamphlet
--- build-improvements.bb/src/etc/Makefile.pamphlet	2006-11-21 00:10:37.000000000 +0100
+++ build-improvements/src/etc/Makefile.pamphlet	2006-11-21 21:36:04.000000000 +0100
@@ -13,6 +13,7 @@
 \section{The axiom command}
 <<axiomcmd>>=
 $(axiom_target_bindir)/axiom: $(srcdir)/axiom
+	$(mkinstalldirs) $(axiom_target_bindir)
 	@echo 1 making $@ from $<
 	@ $(INSTALL_SCRIPT) $< $@
 	@chmod +x $(axiom_target_bindir)/axiom
@@ -79,6 +80,7 @@
 $(axiom_target_bindir)/asq: ${MID}/asq.c
 	@echo 4 making $(axiom_target_bindir)/asq from ${MID}/asq.c
 	@( cd ${MID} ; ${CC} ${CCF} -o asq asq.c )
+	$(mkinstalldirs) $(axiom_target_bindir)
 	@ $(INSTALL_PROGRAM) ${MID}/asq $(axiom_target_bindir)
 
 ${MID}/asq.c: $(srcdir)/asq.c.pamphlet
diff -ru build-improvements.bb/src/input/Makefile.pamphlet build-improvements/src/input/Makefile.pamphlet
--- build-improvements.bb/src/input/Makefile.pamphlet	2006-11-21 00:10:26.000000000 +0100
+++ build-improvements/src/input/Makefile.pamphlet	2006-11-21 02:34:35.000000000 +0100
@@ -97,7 +97,7 @@
 
 .SUFFIXES: .input .out
  
-TESTSYS=  ${OBJ}/${SYS}/bin/interpsys
+TESTSYS= $(axiom_target_bindir)/AXIOMsys 
  
 IN=	$(axiom_src_srcdir)/input
 
diff -ru build-improvements.bb/src/interp/Makefile.pamphlet build-improvements/src/interp/Makefile.pamphlet
--- build-improvements.bb/src/interp/Makefile.pamphlet	2006-11-21 00:10:26.000000000 +0100
+++ build-improvements/src/interp/Makefile.pamphlet	2006-11-21 19:36:29.000000000 +0100
@@ -993,7 +993,7 @@
 	@ echo 4 ${DEPSYS} created
 @
 
-\section{Building SAVESYS and AXIOMSYS}
+\section{Building SAVESYS}
 
 GCL likes to tell you when it has replaced a function call by a 
 tail-recursive call. This happens when the last form in a function
@@ -1007,8 +1007,6 @@
 Doing otherwise causes havoc.
 
 <<savesys>>=
-$(SAVESYS): $(axiom_build_bindir)
-
 ${OUT}/makeint.lisp:	${DEPSYS} ${OBJS} ${OUT}/bookvol5.$(OBJEXT) ${OUT}/util.$(OBJEXT) \
                 nocompil.lisp sys-pkg.lisp \
 	        ${OUTINTERP} ${OCOBJS} ${OPOBJS} ${BROBJS} ${OUT}/obey.$(OBJEXT) \
@@ -1051,12 +1049,12 @@
 	@ echo '#+:akcl (si::gbc-time 0)' >> ${OUT}/makeint.lisp
 
 ${SAVESYS}: ${OUT}/makeint.lisp
+	$(mkinstalldirs) $(axiom_build_bindir)
 	@echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) (user::spad-save "$@"))' | ${LISPSYS}
 	@ echo 6 ${SAVESYS} created
-	$(mkinstalldirs) $(axiom_target_bindir)
 @
 
-\section{Building SAVESYS and AXIOMSYS}
+\section{Building AXIOMSYS}
 
 We want to cache database data in the final image, so we dump it only
 after databases are build (triggered from \File{etc/Makefile.pamphlet}).
@@ -1069,6 +1067,7 @@
 axiomsys: ${AXIOMSYS}
 
 ${AXIOMSYS}: ${OUT}/makeint.lisp
+	$(mkinstalldirs) $(axiom_target_bindir)
 	@echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t)' \
 	   '(user::spad-save "$@"))' | DAASE=$(axiom_targetdir) ${LISPSYS}
 	@ echo 6a ${AXIOMSYS} created

\start
Date: Wed, 22 Nov 2006 14:56:59 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Testing build-improvements

> Waldek Hebisch writes:
> 
> | Recent changes broken testing build-improvements.  The typical problem
> | is that 'int/input/INTHEORY.input' contains sum of INTHEORY.spad and
> | PNTHEORY.spad.
> 
> sorry, I don't understand.
> 

For me multiple tests give bogus results. Examining the reasons I have
found that 'int/input/INTHEORY.input' contains the following:

--Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
--All rights reserved.
<snip>
--SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

)abbrev package INTHEORY IntegerNumberTheoryFunctions
++ Author: Michael Monagan, Martin Brock, Robert Sutor, Timothy Daly
<snip>


AFAICS input parser barfs on Spad syntax giving cascades of error
messages.  Of course, the input parser is right rejecting Spad
-- we should feed it with correct input.

Actually, it looks that three files are affected: INTHEORY.input,
TESTFR.input, VIEW2D.input.

I suspect change to the document script, but have not verified this.

\start
Date: 22 Nov 2006 15:56:00 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Testing build-improvements

Waldek Hebisch writes:

| > Waldek Hebisch writes:
| > 
| > | Recent changes broken testing build-improvements.  The typical problem
| > | is that 'int/input/INTHEORY.input' contains sum of INTHEORY.spad and
| > | PNTHEORY.spad.
| > 
| > sorry, I don't understand.
| > 
| 
| For me multiple tests give bogus results. Examining the reasons I have
| found that 'int/input/INTHEORY.input' contains the following:
| 
| --Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
| --All rights reserved.
| <snip>
| --SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
| 
| )abbrev package INTHEORY IntegerNumberTheoryFunctions
| ++ Author: Michael Monagan, Martin Brock, Robert Sutor, Timothy Daly
| <snip>
| 
| 
| AFAICS input parser barfs on Spad syntax giving cascades of error
| messages.  Of course, the input parser is right rejecting Spad
| -- we should feed it with correct input.
| 
| Actually, it looks that three files are affected: INTHEORY.input,
| TESTFR.input, VIEW2D.input.
| 
| I suspect change to the document script, but have not verified this.

It might quite be possible that a change to document script is causing
an error; but so I'm clueless about what the problem is and what the
symptoms your are describing are.  

investigating...

\start
Date: Wed, 22 Nov 2006 16:17:54 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Testing build-improvements

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | > Waldek Hebisch writes:
> | > 
> | > | Recent changes broken testing build-improvements.  The typical problem
> | > | is that 'int/input/INTHEORY.input' contains sum of INTHEORY.spad and
> | > | PNTHEORY.spad.
> | > 
> | > sorry, I don't understand.
> | > 
> | 
<snip>
> | Actually, it looks that three files are affected: INTHEORY.input,
> | TESTFR.input, VIEW2D.input.
> | 
> | I suspect change to the document script, but have not verified this.
> 
> It might quite be possible that a change to document script is causing
> an error; but so I'm clueless about what the problem is and what the
> symptoms your are describing are.  
> 

I am now testing the patch below.  The three affected files were
generated from algebra pamplets and corresponding hunks have names
containing spaces inside.

--- build-improvements.bb/src/scripts/document.in	2006-11-21 00:10:25.000000000 +0100
+++ build-improvements/src/scripts/document.in	2006-11-22 15:22:59.000000000 +0100
@@ -129,7 +129,7 @@
 
 	--tangle)
 	   do_tangle=yes
-	   if test -n $arg; then
+	   if test -n "$arg"; then
 	       chunk=$arg
 	   fi
 	   # --tangle may not be combined with any other

\start
Date: 22 Nov 2006 16:23:37 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Building Axiom twice

Waldek Hebisch writes:

| The patch below eliminates the second build of Axiom and switches
| tests to use AXIOMsys.  I also changed creation of target directories
| to make it more logical. 
| 
| Remark1: We probably should make target directories at before starting
| the proper build.  ATM we depend on previous stages to create target
| directories which is error prone when we change build order -- in the
| patch below I tried to create target directories when needed, but
| this gets messy very quickly.

Indeed.

| Remark2. From my point of view the stamp stuff in the main Makefile
| is not doing anything usefull,

Could you clarify what you mean by this?

[...]

| Remark3. For readability I removed diffs to generated files.

That is OK.

| Remark4. ATM I can not test the patch properly, due to test breakage
| on build-improvements that I reported earlier.

I'm still trying to understand what you're reporting.  The
trouble is I don't understand it enough to know what the problem and
what I should be looking for.


| diff -ru build-improvements.bb/Makefile.pamphlet build-improvements/Makefile.pamphlet
| --- build-improvements.bb/Makefile.pamphlet	2006-11-21 00:10:38.000000000 +0100
| +++ build-improvements/Makefile.pamphlet	2006-11-21 02:27:34.000000000 +0100
| @@ -263,10 +263,6 @@
|  all-recursive: @axiom_required_build_utils@
|  
|  all-ax:
| -	@ echo 1 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
| -	@ echo 2 Environment ${ENV}
| -	@ $(MAKE) stamp-rootdirs
| -	@ ${ENV} $(MAKE) $(src_stamp)
|  	@echo 3 finished system build on `date` | tee >lastBuildDate

Why?

|  all-bootsys: $(lsp_stamp)
| @@ -279,9 +275,6 @@
|  <<noweb>>
|  <<install>>
|  
| -$(src_stamp): $(lsp_stamp)
| -	cd $(build_srcdir) && $(ENV) $(MAKE)
| -

Why?

[...]

| -\section{Building SAVESYS and AXIOMSYS}
| +\section{Building SAVESYS}

If I understand the logic of the original makefile correctly, there
seems to be a distinction between the image used at compile time, and
the image installed for user consumption.  [Except that that
distinction was never actually implemented, neither in full nor
correctly. ]  Whether that distinction makes sense is something that
needs exploring before we start removing things.  I must confess that
two days ago, I did try a removal of interpsys in one of my local
tree, until I realized that there was an unfinished plan.

My understanding is this:  there is an Axiom image (interpsys) used at
compile time; think of as the image the build machine needs to drive
the compilation.  One of the purpose of such image is for example, to
build some of the algebra needed to build the installed image.  Once
that image is built, with database and all of that, a second build
should be fired up to build the "real" Axiom image.  The one that the
user really cares about.

What is wrong is that the testsuite is run with the compile time image
instead of the one user cares about.

After I saw that, I decided not to remove interpsys, but to write down
what the build flow should.  We need that chart.

\start
Date: 22 Nov 2006 16:57:39 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Testing build-improvements

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Waldek Hebisch writes:
| > 
| > | > Waldek Hebisch writes:
| > | > 
| > | > | Recent changes broken testing build-improvements.  The typical problem
| > | > | is that 'int/input/INTHEORY.input' contains sum of INTHEORY.spad and
| > | > | PNTHEORY.spad.
| > | > 
| > | > sorry, I don't understand.
| > | > 
| > | 
| <snip>
| > | Actually, it looks that three files are affected: INTHEORY.input,
| > | TESTFR.input, VIEW2D.input.
| > | 
| > | I suspect change to the document script, but have not verified this.
| > 
| > It might quite be possible that a change to document script is causing
| > an error; but so I'm clueless about what the problem is and what the
| > symptoms your are describing are.  
| > 
| 
| I am now testing the patch below.  The three affected files were
| generated from algebra pamplets and corresponding hunks have names
| containing spaces inside.

Aha!  That problem again! :-(  You probably saw the comment

    # FIXME: Ideally, we should just prepend -R to $chunk
    #        if it is non-null, and say $tangle $chunk $file > $output
    #        Alternatively, we could initialize chunk to '*' and
    #        unconditionally use -R"$chunk".

which indicates I have been there before.  I wrote "ideally" (long
time ago), because I knew it did not work because of spaces in chunk
names.  And my brain must have been GCed and I forgot about it.
Unfortunately, no amont of quotes could get it work properly under
the various circumstances I checked.

| --- build-improvements.bb/src/scripts/document.in	2006-11-21 00:10:25.000000000 +0100
| +++ build-improvements/src/scripts/document.in	2006-11-22 15:22:59.000000000 +0100
| @@ -129,7 +129,7 @@
|  
|  	--tangle)
|  	   do_tangle=yes
| -	   if test -n $arg; then
| +	   if test -n "$arg"; then
|  	       chunk=$arg

Without proper quotes, I think this would lead to garbage again (at
least that was my experience some time ago).  

Thanks!

\start
Date: Wed, 22 Nov 2006 11:01:06 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Building Axiom twice

> My understanding is this:  there is an Axiom image (interpsys) used at
> compile time; think of as the image the build machine needs to drive
> the compilation.  One of the purpose of such image is for example, to
> build some of the algebra needed to build the installed image.  Once
> that image is built, with database and all of that, a second build
> should be fired up to build the "real" Axiom image.  The one that the
> user really cares about.

The key difference between interpsys (the compile image) and AXIOMsys
(the final user image) is that "warm data" is added to AXIOMsys. A
study I did showed there was a highly skewed distribution of algebra
files which get loaded in any computation (e.g. PositiveInteger is
almost certainly loaded every time). I looked at that distribution
and collected the most frequently loaded algebra files into a list.

interpsys + (the frequent file list loaded) => AXIOMsys

which cuts down on the time it takes to perform computation. It's
one of the dozens of optimizations which make Axiom run reasonably.

\start
Date: 22 Nov 2006 17:13:18 +0100
From: Gabriel Dos Reis
To: list
Subject: ENV

The use of ENV in the Makefiles conflicts with established practice
with shells (that are POSIXilly correct).  

\start
Date: Wed, 22 Nov 2006 17:23:42 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Building Axiom twice

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | Remark2. From my point of view the stamp stuff in the main Makefile
> | is not doing anything usefull,
> 
> Could you clarify what you mean by this?
> 

> | diff -ru build-improvements.bb/Makefile.pamphlet build-improvements/Makefile.pamphlet
> | --- build-improvements.bb/Makefile.pamphlet	2006-11-21 00:10:38.000000000 +0100
> | +++ build-improvements/Makefile.pamphlet	2006-11-21 02:27:34.000000000 +0100
> | @@ -263,10 +263,6 @@
> |  all-recursive: @axiom_required_build_utils@
> |  
> |  all-ax:
> | -	@ echo 1 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
> | -	@ echo 2 Environment ${ENV}
> | -	@ $(MAKE) stamp-rootdirs
> | -	@ ${ENV} $(MAKE) $(src_stamp)
> |  	@echo 3 finished system build on `date` | tee >lastBuildDate
> 
> Why?
> 
> |  all-bootsys: $(lsp_stamp)
> | @@ -279,9 +275,6 @@
> |  <<noweb>>
> |  <<install>>
> |  
> | -$(src_stamp): $(lsp_stamp)
> | -	cd $(build_srcdir) && $(ENV) $(MAKE)
> | -
> 
> Why?
>

We have already run make in src subdirectory: the first run is
from recursive part.  So I must ask why do you want to run make
in src subdirectory twice?  My understanding was that you did not
intend that. 

You may say that the problem really is that Makefile in src
subdirectory did not create the stamp.  But in general only
Makefile in subdirectory has knowledge needed to check if targets
are up to date, so we must run make in subdirectories unconditionally.
One make in subdriectory have run extra check on stamp is redundant
(stamps are usefull when you have multiple subdirectories and you
want bulk dependency on another subdirectory, but not in the main
Makefile).

\start
Date: 22 Nov 2006 17:29:59 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Testing build-improvements

Gabriel Dos Reis writes:

[...]

| |  	--tangle)
| |  	   do_tangle=yes
| | -	   if test -n $arg; then
| | +	   if test -n "$arg"; then
| |  	       chunk=$arg
| 
| Without proper quotes, I think this would lead to garbage again (at
| least that was my experience some time ago).  

Waldek --

This patchlet works for me.  Could you test it?

*** document.in (revision 15247)
--- document.in (local)
*************** while test $# -gt 0 ; do
*** 129,136 ****
  
        --tangle)
           do_tangle=yes
!          if test -n $arg; then
!              chunk=$arg
           fi
           # --tangle may not be combined with any other
           # options.  FIXME:  Check that. 
--- 129,136 ----
  
        --tangle)
           do_tangle=yes
!          if test -n "$arg"; then
!              chunk=`echo -n $arg`
           fi
           # --tangle may not be combined with any other
           # options.  FIXME:  Check that. 

\start
Date: 22 Nov 2006 17:34:23 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Building Axiom twice

Tim Daly writes:

| > My understanding is this:  there is an Axiom image (interpsys) used at
| > compile time; think of as the image the build machine needs to drive
| > the compilation.  One of the purpose of such image is for example, to
| > build some of the algebra needed to build the installed image.  Once
| > that image is built, with database and all of that, a second build
| > should be fired up to build the "real" Axiom image.  The one that the
| > user really cares about.
| 
| The key difference between interpsys (the compile image) and AXIOMsys
| (the final user image) is that "warm data" is added to AXIOMsys. A
| study I did showed there was a highly skewed distribution of algebra
| files which get loaded in any computation (e.g. PositiveInteger is
| almost certainly loaded every time). I looked at that distribution
| and collected the most frequently loaded algebra files into a list.
| 
| interpsys + (the frequent file list loaded) => AXIOMsys
| 
| which cuts down on the time it takes to perform computation. It's
| one of the dozens of optimizations which make Axiom run reasonably.

That begs the question: why not put those warm data and files in
interpsys too, so that we only have one image to care about?

\start
Date: Wed, 22 Nov 2006 11:33:09 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: Re: Building Axiom twice

Stamp files are used for two purposes in the axiom build.

The first purpose is to prevent rebuilding external subsystems
like GCL and noweb.

The second purpose is to provide a timestamp for the database files.

\start
Date: Wed, 22 Nov 2006 11:37:08 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Building Axiom twice

> That begs the question: why not put those warm data and files in
> interpsys too, so that we only have one image to care about?

Because the "warm data" algebra has to be compiled before it can
be loaded. PositiveInteger needs to be compiled in interpsys.

AXIOMsys is a "ship system" and it preloaded the previously compiled
PositiveInteger as well as up-to-date databases. There is a check
(currently broken) that the timestamp in the database files is 
checked against the timestamp of the database files which are 
preloaded into AXIOMsys. If the time stamps of the external database
files match the preloaded databases then the external files are ignored.
If not the external databases are consulted. You can see this because
axiom currently mutters about "reloading" databases when it starts.
This SHOULD be the exception but, as I said, the timestamp mechanism
is broken.

\start
Date: 22 Nov 2006 17:44:26 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Building Axiom twice

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Waldek Hebisch writes:
| > 
| > | Remark2. From my point of view the stamp stuff in the main Makefile
| > | is not doing anything usefull,
| > 
| > Could you clarify what you mean by this?
| > 
| 
| > | diff -ru build-improvements.bb/Makefile.pamphlet build-improvements/Makefile.pamphlet
| > | --- build-improvements.bb/Makefile.pamphlet	2006-11-21 00:10:38.000000000 +0100
| > | +++ build-improvements/Makefile.pamphlet	2006-11-21 02:27:34.000000000 +0100
| > | @@ -263,10 +263,6 @@
| > |  all-recursive: @axiom_required_build_utils@
| > |  
| > |  all-ax:
| > | -	@ echo 1 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
| > | -	@ echo 2 Environment ${ENV}
| > | -	@ $(MAKE) stamp-rootdirs
| > | -	@ ${ENV} $(MAKE) $(src_stamp)
| > |  	@echo 3 finished system build on `date` | tee >lastBuildDate
| > 
| > Why?
| > 
| > |  all-bootsys: $(lsp_stamp)
| > | @@ -279,9 +275,6 @@
| > |  <<noweb>>
| > |  <<install>>
| > |  
| > | -$(src_stamp): $(lsp_stamp)
| > | -	cd $(build_srcdir) && $(ENV) $(MAKE)
| > | -
| > 
| > Why?
| >
| 
| We have already run make in src subdirectory: the first run is
| from recursive part.  So I must ask why do you want to run make
| in src subdirectory twice?  My understanding was that you did not
| intend that. 

Correct, I don't want to Make src/ twice.  However, there is a
dependency which I think is lost in the removal your suggest.

Before build-improvements was created, Axiom used to build a locally
patched version of GCL which needed objects from src/lib (sockio-c.o
and all that).  So, the very first thing the makefile did (after
building noweb) was to Make src/lib (and not any other sibling
directory). After that, GCL is made, then src is walked starting with
boot/, interp/ and so one.  But you src/ in general depends on
lsp/, which itself depends on src/lib.  

Now that we don't need to build a patched version of GCL, we do
this:
  (1) build noweb if necessary
  (2) build GCL if necessaary -- as if we build on its own; however
         install in $(axiom_builddir)
  (3) build a Lisp image that contains objects from src/lib
      (a) so, we must have built src/lib before building the Lips image.

\start
Date: Wed, 22 Nov 2006 11:54:26 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Testing build-improvements

Gaby

On Wednesday, November 22, 2006 11:30 AM you wrote:

> !              chunk=$arg
> ...
> !              chunk=`echo -n $arg`

What shell actually requires such an awkward construction?
Of if you wish why not write:

              chunk="$arg"

or even better :-)

              chunk=`echo -n "$arg"`

But I think "quotes" are only needed on argments to external
commands like 'test', not on variable assignments or echo.

\start
Date: Wed, 22 Nov 2006 13:05:09 -0400
From: Humberto Zuazaga
To: Gabriel Dos Reis
Subject: Re: ENV

Gabriel Dos Reis wrote:
> The use of ENV in the Makefiles conflicts with established practice
> with shells (that are POSIXilly correct).  

And we don't export ENV to submakes, so I don't know if it's doing anything.

\start
Date: Wed, 22 Nov 2006 18:18:30 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Building Axiom twice

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | Gabriel Dos Reis wrote:
> | > Waldek Hebisch writes:
> | > 
> | > | Remark2. From my point of view the stamp stuff in the main Makefile
> | > | is not doing anything usefull,
> | > 
> | > Could you clarify what you mean by this?
> | > 
> | 
> | > | diff -ru build-improvements.bb/Makefile.pamphlet build-improvements/Makefile.pamphlet
> | > | --- build-improvements.bb/Makefile.pamphlet	2006-11-21 00:10:38.000000000 +0100
> | > | +++ build-improvements/Makefile.pamphlet	2006-11-21 02:27:34.000000000 +0100
> | > | @@ -263,10 +263,6 @@
> | > |  all-recursive: @axiom_required_build_utils@
> | > |  
> | > |  all-ax:
> | > | -	@ echo 1 making a ${SYS} system, PART=${PART} SUBPART=${SUBPART}
> | > | -	@ echo 2 Environment ${ENV}
> | > | -	@ $(MAKE) stamp-rootdirs
> | > | -	@ ${ENV} $(MAKE) $(src_stamp)
> | > |  	@echo 3 finished system build on `date` | tee >lastBuildDate
> | > 
> | > Why?
> | > 
> | > |  all-bootsys: $(lsp_stamp)
> | > | @@ -279,9 +275,6 @@
> | > |  <<noweb>>
> | > |  <<install>>
> | > |  
> | > | -$(src_stamp): $(lsp_stamp)
> | > | -	cd $(build_srcdir) && $(ENV) $(MAKE)
> | > | -
> | > 
> | > Why?
> | >
> | 
> | We have already run make in src subdirectory: the first run is
> | from recursive part.  So I must ask why do you want to run make
> | in src subdirectory twice?  My understanding was that you did not
> | intend that. 
> 
> Correct, I don't want to Make src/ twice.  However, there is a
> dependency which I think is lost in the removal your suggest.
> 
> Before build-improvements was created, Axiom used to build a locally
> patched version of GCL which needed objects from src/lib (sockio-c.o
> and all that).  So, the very first thing the makefile did (after
> building noweb) was to Make src/lib (and not any other sibling
> directory). After that, GCL is made, then src is walked starting with
> boot/, interp/ and so one.  But you src/ in general depends on
> lsp/, which itself depends on src/lib.  
> 
> Now that we don't need to build a patched version of GCL, we do
> this:
>   (1) build noweb if necessary
>   (2) build GCL if necessaary -- as if we build on its own; however
>          install in $(axiom_builddir)
>   (3) build a Lisp image that contains objects from src/lib
>       (a) so, we must have built src/lib before building the Lips image.
> 

In the main Makefile we have:

SUBDIRS = src/lib lsp src

and the recursive part will build subdirectories in this strictly
sequential order.  So, as long as recursive logic remains sequential
stamps are redundant.

\start
Date: Wed, 22 Nov 2006 18:44:37 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: ENV

> 
> The use of ENV in the Makefiles conflicts with established practice
> with shells (that are POSIXilly correct).  
> 

I am not sure what you mean: in the main Makefile ENV is make variable
which expands to shell syntax:

VAR1=val1 VAR2=val2 ... command

Do you mean that this syntax is illegal?

In subdirectories make variable ENV is unset, so its expansion is
empty.  Current usage may (I am not sure if it does) add some whitespace
at the beggining of shell command -- I think that leading whitespace
is legal.

\start
Date: Wed, 22 Nov 2006 12:35:54 -0500
From: Tim Daly
To: Humberto Zuazaga
Subject: Re: ENV

> > The use of ENV in the Makefiles conflicts with established practice
> > with shells (that are POSIXilly correct).  
> 
> And we don't export ENV to submakes, so I don't know if it's doing anything.

The name ENV predates POSIX. Since we control everything about the build
I don't think it matters but there would be no harm in changing it everywhere.

In a shell if you write a line like:

 export FOO=bar command

the "command" can see the FOO shell variable. This is used everywhere
to collect up shell variables used in axiom and pass them down the
tree of calls to make. At each level we dynamically build up the
ENV variable list and then prepend it to the make calls which has
the effect of making the shell variables dynamically visible in the
subtree of makes.

\start
Date: 22 Nov 2006 18:50:23 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Testing build-improvements

Bill Page writes:

| Gaby
| 
| On Wednesday, November 22, 2006 11:30 AM you wrote:
| 
| > !              chunk=$arg
| > ...
| > !              chunk=`echo -n $arg`
| 
| What shell actually requires such an awkward construction?
| Of if you wish why not write:
| 
|               chunk="$arg"
| 
| or even better :-)

the trouble with this is that is does not work -- I spent a
considerable amount of time on this quote micmac. :-( 

| 
|               chunk=`echo -n "$arg"`

this one is one needed.

| 
| But I think "quotes" are only needed on argments to external
| commands like 'test', not on variable assignments or echo.

Well, my shell (Zsh) is unhappy with the form chunk="$arg", when cunk
is used later with -R.

\start
Date: 22 Nov 2006 18:56:34 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: Re: ENV

Humberto Zuazaga writes:

| Gabriel Dos Reis wrote:
| > The use of ENV in the Makefiles conflicts with established practice
| > with shells (that are POSIXilly correct).
| 
| And we don't export ENV to submakes, so I don't know if it's doing anything.

ENV is used as in:

   $(ENV) $(MAKE)

which has the logical effect of exporting ENV to Make.

Furthermore, if the login shell export ENV, then Make (and
sub-processes) sees its changed value whether or not we export it.

\start
Date: 22 Nov 2006 19:04:31 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: ENV

Waldek Hebisch writes:

| > 
| > The use of ENV in the Makefiles conflicts with established practice
| > with shells (that are POSIXilly correct).  
| > 
| 
| I am not sure what you mean: in the main Makefile ENV is make variable
| which expands to shell syntax:
| 
| VAR1=val1 VAR2=val2 ... command
| 
| Do you mean that this syntax is illegal?

No, I mean that different tools have a different idea of what ENV
means; in particular the POSIXilly correct shells want it to mean
something precisely defined.  

Furthermore this particular uses 

  $(ENV) $(MAKE)

means that if you're not at toplevel, then you get the wrong
substitution like in:


  monad[12:04]% make                              ~/build/axiom/src/input
  /etc/bash.bashrc make
  DAASE=/home/gdr/build/axiom/target/x86_64-suse-linux regression-tests
  make: execvp: /etc/bash.bashrc: Permission denied
  make: *** [regress] Error 127


| In subdirectories make variable ENV is unset, so its expansion is
| empty.

No, again you're making the assumption that ENV does not mean anything
particular.  ENV means something very precise is POSIXilly correct
shells.  In particular its value is exported, which means that if you
don't set it, you get what it is supposed to be (not empty).  The
above is an experiment you can reproduce with a POSIX-compliant shell.

The issue is very simple: avoid ENV.  Use MAKEFLAGS (which I'm working on).

\start
Date: 22 Nov 2006 19:08:05 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: ENV

Tim Daly writes:

| > > The use of ENV in the Makefiles conflicts with established practice
| > > with shells (that are POSIXilly correct).  
| > 
| > And we don't export ENV to submakes, so I don't know if it's doing anything.
| 
| The name ENV predates POSIX.

irrelevant.

| Since we control everything about the build
| I don't think it matters but there would be no harm in changing it everywhere.

It matters that we do avoid using it. Otherwise, we're setting a
timebomb and it will blow (and it did for me -- that is how it came to
my attention).

\start
Date: 22 Nov 2006 18:54:38 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Building Axiom twice

Waldek Hebisch writes:

[...]

| > Now that we don't need to build a patched version of GCL, we do
| > this:
| >   (1) build noweb if necessary
| >   (2) build GCL if necessaary -- as if we build on its own; however
| >          install in $(axiom_builddir)
| >   (3) build a Lisp image that contains objects from src/lib
| >       (a) so, we must have built src/lib before building the Lips image.
| > 
| 
| In the main Makefile we have:
| 
| SUBDIRS = src/lib lsp src
| 
| and the recursive part will build subdirectories in this strictly
| sequential order.

No, that is untrue if you say "make -jN", aka parallel build, which
build-improvements must support.

|  So, as long as recursive logic remains sequential
| stamps are redundant.

I think you're making too much of oversimplifying unspoken assumptions.
README.build-improvements reads:

   ...
   * Support parallel build.
     Notice that GCL does not support parallel build.  So we can punt
     on build of GCL.  We should work with Camm to fix GCL build
     upstream.
   ...


If you remove the dependency, you break parallel builds.
(Currently, you can do parallel builds until you hit algebra --
assumign you don't have to build GCL).

\start
Date: Wed, 22 Nov 2006 13:13:07 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: ENV

> No, again you're making the assumption that ENV does not mean anything
> particular.  ENV means something very precise is POSIXilly correct
> shells.  In particular its value is exported, which means that if you
> don't set it, you get what it is supposed to be (not empty).  The
> above is an experiment you can reproduce with a POSIX-compliant shell.
> 
> The issue is very simple: avoid ENV.  Use MAKEFLAGS (which I'm working on).

Eh? I have no idea what you're talking about. It is perfectly legal
to set and reference shell variables and this "prefix" technique
is supported as standard syntax by shells. Shell variables are a 
time-honored way of making completely opaque code, making it nearly 
impossible to understand what is going on. Why would you want to 
change that? :-)

Anyway, MAKEFLAGS assumes that the environment variables have something
to do with MAKE, which they don't. MAKE neither knows nor cares about
the environment variables as they are not intended for controlling MAKE.



One example of the shell variable (mis)use in Axiom is the handling
of the PLATFORM variable. This variable is passed on the command line
to certain C calls in a define as in -D${PLATFORM}

Another use is to pass "structural" information such as where the
INT, OBJ, and MNT directories live. You could, for instance, trivially
have done builds "out of the source tree" by simply setting these
variables to other directories. The only reason they point into the
AXIOM subdirectory (although NOT into the "src" directory) is that
the philosophy of the build process states that axiom NEVER writes
outside its toplevel directory. But, as I said, this is trivial to
change by changing the definitions of ${INT}, ${OBJ}, and ${MNT}



So the point is that there are a lot of variables collected into
ENV and they have a lot of different uses and abuses. 

\start
Date: Wed, 22 Nov 2006 13:15:04 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: ENV

> | The name ENV predates POSIX.
> 
> irrelevant.
> 
> | Since we control everything about the build
> | I don't think it matters but there would be no harm in changing it everywhere.
> 
> It matters that we do avoid using it. Otherwise, we're setting a
> timebomb and it will blow (and it did for me -- that is how it came to
> my attention).


ok. s/ENV/GABY/ everywhere.
everything will still work.
ENV is just a local name created 20 years ago.

\start
Date: Wed, 22 Nov 2006 13:28:18 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Testing build-improvements

On Wednesday, November 22, 2006 12:50 PM Gaby wrote:

> | > !              chunk=$arg

Why does this fail? What is the value of $chunk?

> | > ...
> | > !              chunk=`echo -n $arg`
> |

Is this one missing quotes or does it not matter?

> Bill Page wrote:
> | What shell actually requires such an awkward construction?
> | Of if you wish why not write:
> |
> |               chunk="$arg"
> |
> | or even better :-)
>
> the trouble with this is that is does not work -- I spent a
> considerable amount of time on this quote micmac. :-(

Does not work is too vague.

Why does it fail? What is the result value of $chunk?

>
> |
> |               chunk=`echo -n "$arg"`
>
> this one is one needed.
>

That is not what you wrote originally in your patchlet.

> |
> | But I think "quotes" are only needed on argments to external
> | commands like 'test', not on variable assignments or echo.
>
> Well, my shell (Zsh) is unhappy with the form chunk="$arg", when
> chunk is used later with -R.
>

That's very odd. $chunk is just a variable. To use it with -R
as a parameter to notangle I would recommend the following quotes:

  notangle "-R$chunk"

because notangle is an external command.

All of these forms behave identically in my tests using bash
provided that all parameters to external commands are properly
quoted.

Perhaps "3.1: Why does `$var' where `var="foo bar"' not do what
I expect?" in

 http://www.faqs.org/faqs/unix-faq/shell/zsh

might help?

I fear you are heading for "quote hell" if you do not have the
exact semantics of the shell for which you are designing the
scripts.

\start
Date: 22 Nov 2006 19:32:07 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Testing build-improvements

Bill Page writes:

| On Wednesday, November 22, 2006 12:50 PM Gaby wrote:
| 
| > | > !              chunk=$arg
| 
| Why does this fail? What is the value of $chunk?

Most of your questions can be asnwered as follows:
Uncomment the "set -x" and "set +x" instructions from the document
script and run the script for the files TESTFR.input, INTHEORY.input
and VIEW2D.input. 

   ${INPUT}/TESTFR.input: $(srcdir)/fr.spad.pamphlet
           $(axiom_build_document) --tangle='TEST FR' --output=$@ $<

   ${INPUT}/INTHEORY.input: $(srcdir)/numtheor.spad.pamphlet
           $(axiom_build_document) --tangle='TEST INTHEORY' --output=$@ $<

   ${INPUT}/VIEW2D.input: $(srcdir)/view2D.spad.pamphlet
           $(axiom_build_document) --tangle='TEST VIEW2D' --output=$@ $<

\start
Date: Wed, 22 Nov 2006 13:33:20 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Building Axiom twice

> No, that is untrue if you say "make -jN", aka parallel build, which
> build-improvements must support.

this is purely my opinion but i don't believe that parallel builds
of axiom will ever succeed. i'm willing to be proven wrong and would
find that proof a pleasant surprise.

in sub-optimal builds of axiom this would be extremely difficult.
as soon as you try to do optimization i can't figure out how to 
break the circles in parallel. and i firmly believe that all of
the optimization work inside the axiom build is very important.

axiom could be so much faster if we got the gcl_collectfn mechanism
fully re-implemented. the lisp type optimization code can eliminate
hundreds of intructions per function call and axiom lives and breathes
by function calling. however to fully take advantage of that you 
either need to do multiple passes or cache the type information
from previous builds. doing this in parallel makes my hair hurt.

parallel builds cause the make to go marginally faster but my 
feeling is that the time-to-build is not important for two reasons.

first, a properly done make tree need only rebuild changed files
and their dependent files. when builds used to take 3 weeks from
scratch i was able to build changes to the system in 1/2 hour or so
for small changes using the current makefile structure. that is the
whole reason to use make in the first place. otherwise it just makes
sense to have a linear script.

second, only developers care about build time. the end user should
never see it (or maybe see it once). i'd rather spend a whole day
doing a build and get a highly optimized algebra system than spend
1 hour and get a slow algebra system. and that's saying a lot because
all i ever do is build and rebuild the damn thing.

fast algebra is much more important than fast builds.

\start
Date: 22 Nov 2006 19:41:47 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Testing build-improvements

Bill Page writes:

[...]

| > | 
| > |               chunk=`echo -n "$arg"`
| > 
| > this one is one needed.
| >
| 
| That is not what you wrote originally in your patchlet.

I think I wrote:

!          if test -n "$arg"; then
!              chunk=`echo -n $arg`


|  
| > | 
| > | But I think "quotes" are only needed on argments to external
| > | commands like 'test', not on variable assignments or echo.
| > 
| > Well, my shell (Zsh) is unhappy with the form chunk="$arg", when
| > chunk is used later with -R.
| > 
| 
| That's very odd. $chunk is just a variable.

Yes, I know $chunkis just a variable; that the behaviour is odd,
probably.  Can I do something about it?  Yes.  Is the work-around
yucky?  Yes.

| To use it with -R
| as a parameter to notangle I would recommend the following quotes:
| 
|   notangle "-R$chunk"
| 
| because notangle is an external command.
| 
| All of these forms behave identically in my tests using bash
| provided that all parameters to external commands are properly
| quoted.
| 
| Perhaps "3.1: Why does `$var' where `var="foo bar"' not do what
| I expect?" in
| 
|  http://www.faqs.org/faqs/unix-faq/shell/zsh
| 
| might help?
| 
| I fear you are heading for "quote hell" if you do not have the
| exact semantics of the shell for which you are designing the
| scripts.

\start
Date: 22 Nov 2006 19:44:11 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: ENV

Tim Daly writes:

| > | The name ENV predates POSIX.
| > 
| > irrelevant.
| > 
| > | Since we control everything about the build
| > | I don't think it matters but there would be no harm in changing it everywhere.
| > 
| > It matters that we do avoid using it. Otherwise, we're setting a
| > timebomb and it will blow (and it did for me -- that is how it came to
| > my attention).
| 
| 
| ok. s/ENV/GABY/ everywhere.

Tim, you don't have fixate on me.  As I said, the solution is to use
MAKEFLAGS.  That variable was designed specifically for those kinds
of things.

| everything will still work.
| ENV is just a local name created 20 years ago.

Not just because it was created 20 years ago means that its usage is
correct today.  The world did not stop spining while Axiom was
hibernating.

\start
Date: 22 Nov 2006 19:50:13 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: ENV

Tim Daly writes:

| > No, again you're making the assumption that ENV does not mean anything
| > particular.  ENV means something very precise is POSIXilly correct
| > shells.  In particular its value is exported, which means that if you
| > don't set it, you get what it is supposed to be (not empty).  The
| > above is an experiment you can reproduce with a POSIX-compliant shell.
| > 
| > The issue is very simple: avoid ENV.  Use MAKEFLAGS (which I'm working on).
| 
| Eh? I have no idea what you're talking about.

That I've figured out :-)

| It is perfectly legal
| to set and reference shell variables and this "prefix" technique
| is supported as standard syntax by shells.

Nobody claims that is illegal.  We are talking of a *specific variable*
here, that happens to have a *specific meaning* for shells.

[...]

| One example of the shell variable (mis)use in Axiom is the handling
| of the PLATFORM variable. This variable is passed on the command line
| to certain C calls in a define as in -D${PLATFORM}

Oh, let's talk about that hack another day -- I have enough for today.

[...]

| So the point is that there are a lot of variables collected into
| ENV and they have a lot of different uses and abuses. 

You have completely missed the point.

\start
Date: Wed, 22 Nov 2006 15:03:24 -0400
From: Humberto Zuazaga
To: Gabriel Dos Reis
Subject: Re: ENV

Gabriel Dos Reis wrote:
> Nobody claims that is illegal.  We are talking of a *specific variable*
> here, that happens to have a *specific meaning* for shells.

It may help to state the *specific meaning* of ENV in POSIX shells. I 
looked at the man page for bash and it says:

  "When invoked as an interactive shell with the name sh, bash looks for 
the variable ENV, expands its value  if  it  is defined,  and uses the 
expanded value as the name of a file to read and execute."

So I can imagine a call to "$ENV sh something" in a makefile to explode. 
What actually happened?

\start
Date: Wed, 22 Nov 2006 20:12:50 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: ENV

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> | In subdirectories make variable ENV is unset, so its expansion is
> | empty.
> 
> No, again you're making the assumption that ENV does not mean anything
> particular.  ENV means something very precise is POSIXilly correct
> shells.  In particular its value is exported, which means that if you
> don't set it, you get what it is supposed to be (not empty).  The
> above is an experiment you can reproduce with a POSIX-compliant shell.
> 
> The issue is very simple: avoid ENV.  Use MAKEFLAGS (which I'm working on).
> 

Ok, so we pick shell ENV when we run make in subdirectories.  Yes, that
is good reason to change it to something else.  As quck fix we may just
initialize ENV to empty string (explicit initialization should take
precedence over enviroment variables), but in long term we want different
name.  I am not sure if MAKEFLAGS is really good for us.  AFAIU make
assigns magic semantic to this name, which is different that current
ENV use.  Personally I would change ENV to something like ENV_TO_PASS.

\start
Date: 22 Nov 2006 20:26:09 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: Re: ENV

Humberto Zuazaga writes:

| Gabriel Dos Reis wrote:
| > Nobody claims that is illegal.  We are talking of a *specific variable*
| > here, that happens to have a *specific meaning* for shells.
| 
| It may help to state the *specific meaning* of ENV in POSIX shells. I
| looked at the man page for bash and it says:
| 
|   "When invoked as an interactive shell with the name sh, bash looks
| for the variable ENV, expands its value  if  it  is defined,  and uses
| the expanded value as the name of a file to read and execute."

Yes.

| So I can imagine a call to "$ENV sh something" in a makefile to
| explode. What actually happened?

First of, my shell is Zsh, not bash -- but I'm running on a Linux box
so "sh" really is "bash".

Now, the story.  Make needs a shell.  The widely recommended practice
is to use sh.  More specifically, every Makefile shall have this line

    SHELL = /bin/sh

at the very start (unless you're using GNU make, in this case it is
built-in).  You're not obliged to use sh -- for example, sh on SunOS
sucks; you have to use something else, bash or ksh.

There is this line in the Makefile for regression testing:

  regress:
          ${ENV} ${MAKE} DAASE=$(axiom_targetdir) regression-tests


Notice that there is no explicit mention of sh, but Make will call it
because that is the way Make works.

In my case, I stepped into the build directory for input/ and typed
make.  At that point ENV (which is exported by my login shell) has the
value dictated by POSIX, but not overriden by toplevel Makefile.  So
it expanded to /etc/bash.bashrc.

Notice that even if ENV has been overriden by the toplevel Makefile,
that doing is still wrong (it is only a matter of time to trip over
it) because the shell will see that the variable is defined and
attempt to use its value as indicating a file to read and execute.

\start
Date: 22 Nov 2006 20:34:18 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: ENV

Waldek Hebisch writes:

[...]

| Ok, so we pick shell ENV when we run make in subdirectories.  Yes, that
| is good reason to change it to something else.  As quck fix we may just
| initialize ENV to empty string (explicit initialization should take
| precedence over enviroment variables), but in long term we want different
| name.

Yes.

|  I am not sure if MAKEFLAGS is really good for us.  AFAIU make
| assigns magic semantic to this name, which is different that current
| ENV use.  Personally I would change ENV to something like ENV_TO_PASS.

We can do that too.  Though I'm of the opinion that many of the
variables in current ENV are better defined elsewhere.

But frankly, who is afraid of MAKEFLAGS?  MAKEFLAGS does not just
control Make, it serves as a vehicle to communicate values to
sub-makes and sub-processes of Make.

Test this:

    [13:36]% cat Makefile
    all:
            echo $(MAKEFLAGS)

    [13:36]% make HELLO=BUDY
    echo HELLO=BUDY
    HELLO=BUDY


Any variable defined on the Make command line gets put in the
MAKEFLAGS variable.  This does not work if you put the variable
definition before make.  But, that is not too recommended anyway
(however old it is).

\start
Date: 22 Nov 2006 20:40:04 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Building Axiom twice

Tim Daly writes:

| > No, that is untrue if you say "make -jN", aka parallel build, which
| > build-improvements must support.
| 
| this is purely my opinion but i don't believe that parallel builds
| of axiom will ever succeed. i'm willing to be proven wrong and would
| find that proof a pleasant surprise.

Then, just be patient.

| in sub-optimal builds of axiom this would be extremely difficult.
| as soon as you try to do optimization i can't figure out how to 
| break the circles in parallel.

write down very carefully the dependencies.  That does not solve the
dependency problem itself.  But it does expose the potential for
parallel build -- and make is good at exploiting that. 

sman, hyper, documentations, don't need to have AXIOMsys built before
being made.  Many files in interp/ do not need to be compiled
sequentially.  Even in algebra/, the build is sequential only at the
layers level.

[...]

| fast algebra is much more important than fast builds.

fast algebra is not a substitute for fast builds.  Meaning, we could
and should have both.

\start
Date: 22 Nov 2006 20:44:44 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Building Axiom twice

[...]

| axiom could be so much faster if we got the gcl_collectfn mechanism
| fully re-implemented. the lisp type optimization code can eliminate
| hundreds of intructions per function call and axiom lives and breathes
| by function calling. however to fully take advantage of that you 
| either need to do multiple passes or cache the type information
| from previous builds.

Notice that bootsys could (and should) be augmented to generate the
proclaim type information at the same time as it is translating from
Boot to Lisp.

[...]

| second, only developers care about build time.

Developer time is precious.  Especially, when you have only a few of them.

| the end user should
| never see it (or maybe see it once). i'd rather spend a whole day
| doing a build and get a highly optimized algebra system than spend
| 1 hour and get a slow algebra system. and that's saying a lot because
| all i ever do is build and rebuild the damn thing.

You can chose the trade you want.

I want fast alegbra *and* fast build.  Fast build means I can try and
iterate patches and ideas several times in a day.

\start
Date: Wed, 22 Nov 2006 21:20:34 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: ENV

Gabriel Dos Reis wrote:
> But frankly, who is afraid of MAKEFLAGS?  MAKEFLAGS does not just
> control Make, it serves as a vehicle to communicate values to
> sub-makes and sub-processes of Make.
> 

I see two problems with MAKEFLAGS:

1) How portable it is to differnt favors of make?

2) IIUC in GNU make arguments passed via MAKEFLAGS take precedence
over assignments inside Makefile.  This may produce values which are
hard to predict from text of the Makefile and build log.  Values passed via
envioronment do not show in the log, but at least explicit
assignment inside Makefile takes precedence, so one has to track
envioronment only when there is no explicit assignment. Of course, if
you put `echo $(MAKEFLAGS)' before each recursive make invocation
the second problem would go away.

\start
Date: Wed, 22 Nov 2006 15:31:18 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Testing build-improvements

On Wednesday, November 22, 2006 1:32 PM Gaby wrote:
> | On Wednesday, November 22, 2006 12:50 PM Gaby wrote:
> |
> | > | > !              chunk=$arg
>
> Bill Page wrote:
>
> | Why does this fail? What is the value of $chunk?
>
> Most of your questions can be asnwered as follows:
> Uncomment the "set -x" and "set +x" instructions from the
> document script and run the script for the files TESTFR.input,
> INTHEORY.input and VIEW2D.input.
>
>    ${INPUT}/TESTFR.input: $(srcdir)/fr.spad.pamphlet
>            $(axiom_build_document) --tangle='TEST FR' --output=$@ =
$<
>
>    ${INPUT}/INTHEORY.input: $(srcdir)/numtheor.spad.pamphlet
>            $(axiom_build_document) --tangle='TEST INTHEORY'
> --output=$@ $<
>
>    ${INPUT}/VIEW2D.input: $(srcdir)/view2D.spad.pamphlet
>            $(axiom_build_document) --tangle='TEST VIEW2D'
> --output=$@ $<
>

Unfortunately what wasted a lot of time and did not tell me
anything. :-(

All of these commands executed properly on the axiom-developer.org
server without changes to document - probably because of the default
behaviour of bash. See the output attached below.

But I noticed that you have many incorrectly quoted or unquoted
parameters in the document script. Perhaps that is what is causing
your "quote micmac" with zsh. This sort of awkward and obscure
construction is not necessary:

           chunk=`echo -n $arg`

I included a patch for document below. The corrected version of
the document script generates the same output as but it is more
robust on other systems with other shells and fully supports
file names that include spaces (e.g. on Windows).

Attachment:

[page@axiom-developer scripts]$ ./document --tangle='TEST VIEW2D'
 --output=test
~/axiom.build-improvements/src/algebra/view2D.spad.pamphlet
+ latex=latex
+ index=@MAKINDEX@
+ tangle=/usr/local/bin/notangle
+ weave=/usr/local/bin/noweave
+ =
TEXINPUTS=.:/home/page/axiom.test/build/i686-pc-linux/share/texmf/tex:
+ export TEXINPUTS
+ =
BIBINPUTS=.:/home/page/axiom.test/build/i686-pc-linux/share/texmf/tex:
+ export BIBINPUTS
+ do_index=
+ do_latex=
+ do_tangle=
+ do_weave=
+ chunk=
+ file=
+ output=
+ :
+ do_tangle=yes
++ echo --tangle=TEST VIEW2D
++ awk -F= '{ print $2; }'
+ chunk=TEST VIEW2D
+ shift
+ :
++ echo --output=test3
++ awk -F= '{ print $2; }'
+ output=test3
+ shift
+ :
+ break
+ test xyes = xyes
+
file=/home/page/axiom.build-improvements/src/algebra/view2D.spad.pamphl=
e
t
+ '[' -z test3 ']'
+ '[' -z 'TEST VIEW2D' ']'
+ /usr/local/bin/notangle '-RTEST VIEW2D'
/home/page/axiom.build-improvements/src/algebra/view2D.spad.pamphlet
+ exit 0
[page@axiom-developer scripts]$ rm test3
[page@axiom-developer scripts]$ ./document --tangle='TEST VIEW2D'
--output=test
3 ~/axiom.build-improvements/src/algebra/view2D.spad.pamphlet
+ latex=latex
+ index=@MAKINDEX@
+ tangle=/usr/local/bin/notangle
+ weave=/usr/local/bin/noweave
+ =
TEXINPUTS=.:/home/page/axiom.test/build/i686-pc-linux/share/texmf/tex:
+ export TEXINPUTS
+ =
BIBINPUTS=.:/home/page/axiom.test/build/i686-pc-linux/share/texmf/tex:
+ export BIBINPUTS
+ do_index=
+ do_latex=
+ do_tangle=
+ do_weave=
+ chunk=
+ file=
+ output=
+ :
+ do_tangle=yes
++ echo --tangle=TEST VIEW2D
++ awk -F= '{ print $2; }'
+ chunk=TEST VIEW2D
+ shift
+ :
++ echo --output=test3
++ awk -F= '{ print $2; }'
+ output=test3
+ shift
+ :
+ break
+ test xyes = xyes
+
file=/home/page/axiom.build-improvements/src/algebra/view2D.spad.pamphl=
e
t
+ '[' -z test3 ']'
+ '[' -z 'TEST VIEW2D' ']'
+ /usr/local/bin/notangle '-RTEST VIEW2D'
/home/page/axiom.build-improvements/src/algebra/view2D.spad.pamphlet
+ exit 0
[page@axiom-developer scripts]$ cat test3
)clear all
a:=0.5
b:=0.5
y1:=draw(x^3*(a+b*x),x=-1..1,title=="2.2.10 explicit")
g1:=getGraph(y1,1)
pointLists g1
b:=1.0
y2:=draw(x^3*(a+b*x),x=-1..1)
g2:=getGraph(y2,1)
pointLists g2
putGraph(y1,g2,2)
b:=2.0
y3:=draw(x^3*(a+b*x),x=-1..1)
g3:=getGraph(y3,1)
pointLists g3
putGraph(y1,g3,3)
vp:=makeViewport2D(y1)
[page@axiom-developer scripts]$

--------

Patch for document:

Everywhere a variable is used in a parameter to an external
command, it must be enclosed in "quotes". Note especially
the command

  $tangle "-R$chunk"

The substitution must be made inside the quoted parameter.

Also the notation

  if test x$do_tangle = xyes; then

is old and silly. This looks better and works the same.

  if test "$do_tangle" = "yes"; then

[page@axiom-developer scripts]$ ./document --tangle='TEST VIEW2D'
--output=test
3 ~/axiom.build-improvements/src/algebra/view2D.spad.pamphlet
[page@axiom-developer scripts]$ diff -au document_old document_new
--- document_old        2006-11-22 13:18:11.000000000 -0600
+++ document_new        2006-11-22 13:49:04.000000000 -0600
@@ -76,7 +76,7 @@
     esac
 done

-if test x$do_tangle = xyes; then
+if test "$do_tangle" = "yes"; then
     # FIXME: Check that the input file name does indeed have
     # a pamphlet extension.
     file=$1
@@ -89,32 +89,32 @@
     #        Alternatively, we could initialize chunk to '*' and
     #        unconditionally use -R"$chunk".
     if [ -z "$chunk" ]; then
-       $tangle $file > $output
+       $tangle "$file" > "$output"
     else
-       $tangle -R"$chunk" $file > $output
+       $tangle "-R$chunk" "$file" > "$output"
     fi
     # FIXME: Handle errors.
     exit $?;
 fi


-if test x$do_weave = xyes; then
+if test "$do_weave" = "yes"; then
     file=`basename $1 .pamphlet`
-    $weave -delay $1 > $file.tex
-    if test x$do_latex != xyes; then
+    $weave -delay "$1" > "$file.tex"
+    if test "$do_latex" != "yes"; then
        exit 0;
     fi
 fi

-if test x$do_latex = xyes; then
+if test "$do_latex" = "yes"; then
     if [ -z $file ]; then
        file=`basename $1 .tex`
     fi
-    $latex --interaction nonstopmode $file;
-    if [ x$do_index = xyes ]; then
-       $makeindex $file.idx
+    $latex --interaction nonstopmode "$file";
+    if [ "$do_index" = "yes" ]; then
+       $makeindex "$file.idx"
     fi
-    $latex --interaction nonstopmode $file;
+    $latex --interaction nonstopmode "$file";
     exit $?
 fi

@@ -122,30 +122,30 @@
 if [ "$#" = "3" ]; then
  REDIRECT=$2
  FILE=`basename $3 .pamphlet`
- $tangle -t8 $FILE.pamphlet >$FILE
- $weave -delay $FILE.pamphlet >$FILE.tex
- $latex --interaction nonstopmode $FILE.tex >$REDIRECT
- $latex --interaction nonstopmode $FILE.tex >$REDIRECT
- rm -f $FILE~
- rm -f $FILE.pamphlet~
- rm -f $FILE.log
- rm -f $FILE.tex
- rm -f $FILE.toc
- rm -f $FILE.aux
+ $tangle -t8 "$FILE.pamphlet" >"$FILE"
+ $weave -delay "$FILE.pamphlet" >"$FILE.tex"
+ $latex --interaction nonstopmode "$FILE.tex" >"$REDIRECT"
+ $latex --interaction nonstopmode "$FILE.tex" >"$REDIRECT"
+ rm -f "$FILE~"
+ rm -f "$FILE.pamphlet~"
+ rm -f "$FILE.log"
+ rm -f "$FILE.tex"
+ rm -f "$FILE.toc"
+ rm -f "$FILE.aux"
  exit 0
 fi
 if [ "$#" = "1" ]; then
  FILE=`basename $1 .pamphlet`
- $tangle -t8 $FILE.pamphlet >$FILE
- $weave -delay $FILE.pamphlet >$FILE.tex
- $latex $FILE.tex
- $latex $FILE.tex
- rm -f $FILE~
- rm -f $FILE.pamphlet~
- rm -f $FILE.log
- rm -f $FILE.tex
- rm -f $FILE.toc
- rm -f $FILE.aux
+ $tangle -t8 "$FILE.pamphlet" >"$FILE"
+ $weave -delay "$FILE.pamphlet" >"$FILE.tex"
+ $latex "$FILE.tex"
+ $latex "$FILE.tex"
+ rm -f "$FILE~"
+ rm -f "$FILE.pamphlet~"
+ rm -f "$FILE.log"
+ rm -f "$FILE.tex"
+ rm -f "$FILE.toc"
+ rm -f "$FILE.aux"
  exit 0
 fi
 echo "document [ -o redirect ] pamphlet"

[page@axiom-developer scripts]$

\start
Date: Wed, 22 Nov 2006 21:40:43 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: ENV

>   regress:
>           ${ENV} ${MAKE} DAASE=$(axiom_targetdir) regression-tests

BTW, why isn't it

	${MAKE} ${ENV} DAASE=$(axiom_targetdir) regression-tests

?

As far as I understand that, in both cases not ENV is passed to MAKE but 
its value. So the variable ENV would not be set in a subshell unless ENV 
is already set at the beginning.

(Replace ENV by any other variable name if you don't like ENV.)

\start
Date: Wed, 22 Nov 2006 21:40:37 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Testing build-improvements

Gabriel Dos Reis wrote:
> This patchlet works for me.  Could you test it?
> 
> *** document.in (revision 15247)
> --- document.in (local)
> *************** while test $# -gt 0 ; do
> *** 129,136 ****
>   
>         --tangle)
>            do_tangle=yes
> !          if test -n $arg; then
> !              chunk=$arg
>            fi
>            # --tangle may not be combined with any other
>            # options.  FIXME:  Check that. 
> --- 129,136 ----
>   
>         --tangle)
>            do_tangle=yes
> !          if test -n "$arg"; then
> !              chunk=`echo -n $arg`
>            fi
>            # --tangle may not be combined with any other
>            # options.  FIXME:  Check that. 
> 

Works for me.  But I still do not understand this:

       chunk=`echo -n $arg`

thing (despite later messages).  Using bash I can just put

       chunk=$arg

and it works (the problem was on test line).  Zsh manual claims
that word splitting is not done on assignment (and I think
same is true for bash).

\start
Date: 22 Nov 2006 22:07:27 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Testing build-improvements

Bill Page writes:

[...]

| All of these commands executed properly on the axiom-developer.org
| server without changes to document - probably because of the default
| behaviour of bash. See the output attached below.
| 
| But I noticed that you have many incorrectly quoted or unquoted
| parameters in the document script.

Please define more precisely what you mean by incorrectly quoted
and unquoted.  My guide on portable shell scripts usually is the 
notes in Autoconf.

  Shell Substitutions
  ===================

  Contrary to a persistent urban legend, the Bourne shell does not
  systematically split variables and back-quoted expressions, in
  particular on the right-hand side of assignments and in the argument
  of
  `case'.  For instance, the following code:

       case "$given_srcdir" in
       .)  top_srcdir="`echo "$dots" | sed 's,/$,,'`"
       *)  top_srcdir="$dots$given_srcdir" ;;
       esac

  is more readable when written as:

       case $given_srcdir in
       .)  top_srcdir=`echo "$dots" | sed 's,/$,,'`
       *)  top_srcdir=$dots$given_srcdir ;;
       esac

  and in fact it is even _more_ portable: in the first case of the first
  attempt, the computation of `top_srcdir' is not portable, since not all
  shells properly understand `"`..."..."...`"'.  Worse yet, not all
  shells understand `"`...\"...\"...`"' the same way.  There is just no
  portable way to use double-quoted strings inside double-quoted
  back-quoted expressions (pfew!).


| Perhaps that is what is causing
| your "quote micmac" with zsh. 

I'm not you're testing the right script.

| This sort of awkward and obscure
| construction is not necessary:
| 
|            chunk=`echo -n $arg`
| 
| I included a patch for document below. The corrected version of
| the document script generates the same output as but it is more
| robust on other systems with other shells and fully supports
| file names that include spaces (e.g. on Windows).
| 
| Attachment:
| 
| [page@axiom-developer scripts]$ ./document --tangle='TEST VIEW2D'
|  --output=test
| ~/axiom.build-improvements/src/algebra/view2D.spad.pamphlet
| + latex=latex
| + index=@MAKINDEX@
| + tangle=/usr/local/bin/notangle
| + weave=/usr/local/bin/noweave
| + TEXINPUTS=.:/home/page/axiom.test/build/i686-pc-linux/share/texmf/tex:
| + export TEXINPUTS
| + BIBINPUTS=.:/home/page/axiom.test/build/i686-pc-linux/share/texmf/tex:
| + export BIBINPUTS
| + do_index=
| + do_latex=
| + do_tangle=
| + do_weave=
| + chunk=
| + file=
| + output=
| + :
| + do_tangle=yes
| ++ echo --tangle=TEST VIEW2D
| ++ awk -F= '{ print $2; }'

I believe you're testing a different document script from the one we
are discussing.   Therefore I'm not surprised at all that everything
is OK for you because I did ensure that it worked in the version
you're testing.
The one we're discussing does not have AWK anymore.

[...]

| Patch for document:
| 
| Everywhere a variable is used in a parameter to an external
| command, it must be enclosed in "quotes". Note especially
| the command
| 
|   $tangle "-R$chunk"
| 
| The substitution must be made inside the quoted parameter.
| 
| Also the notation
| 
|   if test x$do_tangle = xyes; then
| 
| is old and silly. This looks better and works the same.
| 
|   if test "$do_tangle" = "yes"; then

However silly it appears to you (and me) I disagree with your removal
of x.  The above has been coded on purpose to be resilient to funky
shells and inputs.


`test' (strings)
     Avoid `test "STRING"', in particular if STRING might start with a
     dash, since `test' might interpret its argument as an option
     (e.g., `STRING = "-n"').

     Contrary to a common belief, `test -n STRING' and `test -z STRING'
     *are* portable.  Nevertheless many shells (such as Solaris 2.5,
     AIX 3.2, UNICOS 10.0.0.6, Digital Unix 4 etc.) have bizarre
     precedence and may be confused if STRING looks like an operator:

          $ test -n =
          test: argument expected

     If there are risks, use `test "xSTRING" = x' or `test "xSTRING" !=
     x' instead.

\start
Date: 22 Nov 2006 22:08:58 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: ENV

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > But frankly, who is afraid of MAKEFLAGS?  MAKEFLAGS does not just
| > control Make, it serves as a vehicle to communicate values to
| > sub-makes and sub-processes of Make.
| > 
| 
| I see two problems with MAKEFLAGS:
| 
| 1) How portable it is to differnt favors of make?

Fairly, I would say.

| 
| 2) IIUC in GNU make arguments passed via MAKEFLAGS take precedence
| over assignments inside Makefile.

yes, and in the most common cases, that is what you want.

\start
Date: 22 Nov 2006 22:17:06 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: ENV

Ralf Hemmecke writes:

| >   regress:
| >           ${ENV} ${MAKE} DAASE=$(axiom_targetdir) regression-tests
| 
| BTW, why isn't it
| 
| 	${MAKE} ${ENV} DAASE=$(axiom_targetdir) regression-tests
| 
| ?

Ask Tim.

What you show is correct assuming you renamed ENV to something else.
(And the values will be part of MAKEFLAGS).

| As far as I understand that, in both cases not ENV is passed to MAKE
| but its value. So the variable ENV would not be set in a subshell
| unless ENV is already set at the beginning.

In both cases, it is the value, but the value might be incorrect if
you insist on using ENV.

| (Replace ENV by any other variable name if you don't like ENV.)

There must be a profond misunderstanding here :-(

\start
Date: Wed, 22 Nov 2006 22:27:05 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Building Axiom twice

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | In the main Makefile we have:
> | 
> | SUBDIRS = src/lib lsp src
> | 
> | and the recursive part will build subdirectories in this strictly
> | sequential order.
> 
> No, that is untrue if you say "make -jN", aka parallel build, which
> build-improvements must support.
> 
> |  So, as long as recursive logic remains sequential
> | stamps are redundant.
> 
> I think you're making too much of oversimplifying unspoken assumptions.
> README.build-improvements reads:
> 
>    ...
>    * Support parallel build.
>      Notice that GCL does not support parallel build.  So we can punt
>      on build of GCL.  We should work with Camm to fix GCL build
>      upstream.
>    ...
> 
> 
> If you remove the dependency, you break parallel builds.
> (Currently, you can do parallel builds until you hit algebra --
> assumign you don't have to build GCL).
> 

Have you tried to do parallel builds?  I tried, but it failed in boot
directory. FYI I changed lsp Makefile to pass '-j 1' to GCL because ATM
on my dual core machines build fails using system GCL (it works using
bundled GCL, also system GCL on single core machines works fine). 

My impression is that you will loose most opportunities for
parallelism: recursive logic is seqential and dependence via stamps
means that one subdirectory must finish before another starts. 
If you make dependency on stamp effective how do you want to
avoid starting two makes (in paralel) in src subdirectory -- make
logic will not prevent this. So, I think that to trurly support paralel
builds you need a single Makefile.

\start
Date: Wed, 22 Nov 2006 16:42:01 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Testing build-improvements

On Wednesday, November 22, 2006 4:07 PM Gaby wrote:
> Bill Page wrote:
> | But I noticed that you have many incorrectly quoted or unquoted
> | parameters in the document script.
>
> Please define more precisely what you mean by incorrectly quoted
> and unquoted.

I am referring to any parameter that is passed to an external
program.

> My guide on portable shell scripts usually is the notes in
> Autoconf.

I guess that's good enough for this purpose. :-)

>
>   is more readable when written as:
>
>        case $given_srcdir in
>        .)  top_srcdir=`echo "$dots" | sed 's,/$,,'`
>        *)  top_srcdir=$dots$given_srcdir ;;
>        esac
>
>   and in fact it is even _more_ portable: in the first case
>   of the first attempt, ...

I agree. I did not suggest any changes of this kind.

>
> | This sort of awkward and obscure
> | construction is not necessary:
> |
> |            chunk=`echo -n $arg`
> |

As I said and as is consistent with your quote, the above is not
necessary. See the case *) above.

> ...
> I believe you're testing a different document script from the
> one we are discussing.

Damn. I just can't keep up the pace. :-(

But I kind of suspected this because I was looking for the new:

    document --tag=boot --mode=translate bootsys foo.boot

option and didn't find it.

> |
> |   $tangle "-R$chunk"
> |
> | The substitution must be made inside the quoted parameter.
> |

I still think the above way of writing the -R parameter is imporant.

> | Also the notation
> |
> |   if test x$do_tangle = xyes; then
> |
> | is old and silly. This looks better and works the same.
> |
> |   if test "$do_tangle" = "yes"; then
>
> However silly it appears to you (and me) I disagree with your
> removal of x.  The above has been coded on purpose to be
> resilient to funky shells and inputs.
>
> ...
>      If there are risks, use `test "xSTRING" = x' or `test
>      "xSTRING" != x' instead.
>

There is absolutely no risk in the above test. We control the
value of $do_tangle. Anyway this is just a silly style issue.
(Who actually reads this stuff anyway. ;)

On to more important things...

\start
Date: 22 Nov 2006 22:13:12 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Testing build-improvements

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > This patchlet works for me.  Could you test it?
| > 
| > *** document.in (revision 15247)
| > --- document.in (local)
| > *************** while test $# -gt 0 ; do
| > *** 129,136 ****
| >   
| >         --tangle)
| >            do_tangle=yes
| > !          if test -n $arg; then
| > !              chunk=$arg
| >            fi
| >            # --tangle may not be combined with any other
| >            # options.  FIXME:  Check that. 
| > --- 129,136 ----
| >   
| >         --tangle)
| >            do_tangle=yes
| > !          if test -n "$arg"; then
| > !              chunk=`echo -n $arg`
| >            fi
| >            # --tangle may not be combined with any other
| >            # options.  FIXME:  Check that. 
| > 
| 
| Works for me. 

Thanks.

| But I still do not understand this:
| 
|        chunk=`echo -n $arg`
| 
| thing (despite later messages). 

It is trying to turn $arg that might be splitted into many strings
(because of over quoting -- despite the popular belief that quoting
should be done systematically) into a single string so that is has
only one quote at the beginning and one quote at the end.

| Using bash I can just put
| 
|        chunk=$arg
| 
| and it works (the problem was on test line).  Zsh manual claims
| that word splitting is not done on assignment (and I think
| same is true for bash).

That behaviour is controlled by options, so the simpler asssignment
which should work is brittle.  You can remove the echo, but PLEASE
don't quote $arg in the assinment.

\start
Date: 22 Nov 2006 22:48:15 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Building Axiom twice

Waldek Hebisch writes:

[...]

| >    * Support parallel build.
| >      Notice that GCL does not support parallel build.  So we can punt
| >      on build of GCL.  We should work with Camm to fix GCL build
| >      upstream.
| >    ...
| > 
| > 
| > If you remove the dependency, you break parallel builds.
| > (Currently, you can do parallel builds until you hit algebra --
| > assumign you don't have to build GCL).
| > 
| 
| Have you tried to do parallel builds?

Yes -- that is how I know which directory fails, which does not.

|  I tried, but it failed in boot directory. 

Then that is a recent bug, because it was working for me no later than
last week (and it has been working for long time now).  

Could you send the build log?  That way we may have a clue about the culprit.

| FYI I changed lsp Makefile to pass '-j 1' to GCL because ATM
| on my dual core machines build fails using system GCL (it works using
| bundled GCL, also system GCL on single core machines works fine). 

We can have the lsp Makefile say .NOTPARALLEL for the GCL targets so
that GCL is not attempted in parallel.

| My impression is that you will loose most opportunities for
| parallelism: recursive logic is seqential and dependence via stamps
| means that one subdirectory must finish before another starts. 

Which recursive logic?  
On purpose I did not write a for loop, rather, I listed the targets.
Then it is necessary that the dependencies are correct.  

| If you make dependency on stamp effective how do you want to
| avoid starting two makes (in paralel) in src subdirectory -- make
| logic will not prevent this. So, I think that to trurly support paralel
| builds you need a single Makefile.

I don't know what you mean by "trully parallel build", but we have been
doing parallel build for nearly a decade now with GCC and it does have
multiple makefiles.

\start
Date: 22 Nov 2006 22:56:13 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Testing build-improvements

Bill Page writes:

[...]

| Damn. I just can't keep up the pace. :-(

hey, it is Thanksgiving soon :-)

| But I kind of suspected this because I was looking for the new:
| 
|     document --tag=boot --mode=translate bootsys foo.boot
| 
| option and didn't find it.
| 
| > | 
| > |   $tangle "-R$chunk"
| > | 
| > | The substitution must be made inside the quoted parameter.
| > |
| 
| I still think the above way of writing the -R parameter is imporant.

I'm interested in the difference between

    $tangle -R"$chunk"

and 

    $tangle -"R$chunk"

(for true, I don't know the portability issue here; I'm just curious).

\start
Date: Wed, 22 Nov 2006 16:57:33 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: ENV

> | ok. s/ENV/GABY/ everywhere.
> 
> Tim, you don't have fixate on me.  As I said, the solution is to use
> MAKEFLAGS.  That variable was designed specifically for those kinds
> of things.

sigh. missed the point.....
s/ENV/TIM/ everywhere.



> | everything will still work.
> | ENV is just a local name created 20 years ago.
> 
> Not just because it was created 20 years ago means that its usage is
> correct today.  The world did not stop spining while Axiom was
> hibernating.

There is an interaction between the shell variable mechanism,
the way make expands and overrides variables, and the command line.
 
Axiom's makefile sets AWK=gawk for some platforms.
The AWK variable is collected up in the ENV variable thus:

ENV = .... AWK=${AWK} ...

The way axiom's makefile work you can override the make variables
on the command line thus:

make AWK=nawk

but it appears that this is not true with MAKEFLAGS

http://lists.freebsd.org/pipermail/freebsd-bugs/2004-June/007479.html

\start
Date: 22 Nov 2006 23:06:35 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Testing build-improvements

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > This patchlet works for me.  Could you test it?
| > 
| > *** document.in (revision 15247)
| > --- document.in (local)
| > *************** while test $# -gt 0 ; do
| > *** 129,136 ****
| >   
| >         --tangle)
| >            do_tangle=yes
| > !          if test -n $arg; then
| > !              chunk=$arg
| >            fi
| >            # --tangle may not be combined with any other
| >            # options.  FIXME:  Check that. 
| > --- 129,136 ----
| >   
| >         --tangle)
| >            do_tangle=yes
| > !          if test -n "$arg"; then
| > !              chunk=`echo -n $arg`
| >            fi
| >            # --tangle may not be combined with any other
| >            # options.  FIXME:  Check that. 
| > 
| 
| Works for me.  But I still do not understand this:
| 
|        chunk=`echo -n $arg`
| 
| thing (despite later messages).  Using bash I can just put
| 
|        chunk=$arg

Here is a patch to remove the yucky hack.

-- Gaby
*** ChangeLog.build-improvements	(revision 16912)
--- ChangeLog.build-improvements	(local)
***************
*** 1,5 ****
--- 1,9 ----
  2006-11-22  Gabriel Dos Reis  Gabriel Dos Reis
  
+ 	* document.in (--tangle): Remove yucky hack.
+ 
+ 2006-11-22  Gabriel Dos Reis  Gabriel Dos Reis
+ 
  	* document.in (--tangle): Go through contorsions to support
  	chunk names with embedded blank.
  
*** document.in	(revision 16912)
--- document.in	(local)
*************** while test $# -gt 0 ; do
*** 130,142 ****
  	--tangle)
  	   do_tangle=yes
  	   if test -n "$arg"; then
! 	       # Ideally we would just assign $arg to chunk, possibly
! 	       # quoted.  However, some shells have their own
! 	       # ideas about what strings with embedded blank look
! 	       # like whe they are evaluated.  This disgusting hack
! 	       # is to ensure that chunk stores ONE string, with
! 	       # possibly embedded blank.
! 	       chunk=`echo -n $arg`
  	   fi
  	   # --tangle may not be combined with any other
  	   # options.  FIXME:  Check that. 
--- 130,136 ----
  	--tangle)
  	   do_tangle=yes
  	   if test -n "$arg"; then
! 	       chunk=$arg
  	   fi
  	   # --tangle may not be combined with any other
  	   # options.  FIXME:  Check that. 



\start
Date: Wed, 22 Nov 2006 17:04:01 -0500
From: Tim Daly
To: Humberto Zuazaga
Subject: Re: ENV

> It may help to state the *specific meaning* of ENV in POSIX shells. I 
> looked at the man page for bash and it says:
> 
>   "When invoked as an interactive shell with the name sh, bash looks for 
> the variable ENV, expands its value  if  it  is defined,  and uses the 
> expanded value as the name of a file to read and execute."
> 
> So I can imagine a call to "$ENV sh something" in a makefile to explode. 
> What actually happened?

The shell never sees "$ENV". That's part of the confusion.
The ${ENV} variable is a makefile-level variable which is
expanded by make to read:

SPAD=.... SRC=... INT=... .... make src

The fact that the characters ENV is used as the name of the makefile
variable is a product of history. It would be trivial to rename the
variable from ENV to TPD and everything still works. 

Every programmer knows that the name of a variable in a local
context can be overloaded. I can't imagine why this is even a
point of discussion. There should be NO confusion between a
variable in a makefile and a variable in a shell.

\start
Date: Wed, 22 Nov 2006 17:12:24 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: ENV

> There is this line in the Makefile for regression testing:
> 
>   regress:
>           ${ENV} ${MAKE} DAASE=$(axiom_targetdir) regression-tests
> 
> 
> Notice that there is no explicit mention of sh, but Make will call it
> because that is the way Make works.
> 
> In my case, I stepped into the build directory for input/ and typed
> make.  At that point ENV (which is exported by my login shell) has the
> value dictated by POSIX, but not overriden by toplevel Makefile.  So
> it expanded to /etc/bash.bashrc.
> 
> Notice that even if ENV has been overriden by the toplevel Makefile,
> that doing is still wrong (it is only a matter of time to trip over
> it) because the shell will see that the variable is defined and
> attempt to use its value as indicating a file to read and execute.

An excellent point. Except that none of the makefiles in the axiom
tree are designed to be executed "standalone". The critical variables
are not defined, e.g. SRC, INT, OBJ, MNT, etc. The fact that ENV has
a meaning in the shell is pure coincidence. 

Executing a makefile that is not designed to be executed is 
guaranteed to fail whether the variable is named ENV or TPD or
any other random name. 

This discussion seems so strange. Can any programmer claim that we
should never use 'if' as a variable name because it has another
meaning? Can you claim that whatever name you choose (e.g. SRC,
INT, BUILD, CVS_RSH, etc) will never be assigned a future meaning
and is therefore safe to use?

\start
Date: Wed, 22 Nov 2006 17:36:17 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: ENV

| >   regress:
| >           ${ENV} ${MAKE} DAASE=$(axiom_targetdir) regression-tests
| 
| BTW, why isn't it
| 
| 	${MAKE} ${ENV} DAASE=$(axiom_targetdir) regression-tests
| 

First, for defining terms, the "current Makefile" is the makefile
that contains the above chosen line. The "current Makefile" will
try to execute the "new Makefile". So the question is, what will
be the effect in the "new Makefile" of the different order?

Hmmm, the question is one of expansion I suppose. Lets assume that
the current Makefile

SRC=/axiom/src
INT=/axiom/int

ENV = SRC=${SRC} INT=${INT}

then the first expression expands to:

SRC=/axiom/src INT=/axiom/int ${MAKE} DAASE=$(axiom_targetdir) regression-tests

which means that in the newly executing Makefile the variable values of

SRC and INT will NOT be overridden if they are set in the new Makfile
DAASE will be overridden if the are set in the new Makefile

and the second expression expands to:

${MAKE} SRC=/axiom/src INT=/axiom/int DAASE=$(axiom_targetdir) regression-tests

which means that in the newly executing Makefile the variable values of

SRC and INT WILL be overridden if they are set in the new Makfile
DAASE WILL be overridden if the are set in the new Makefile

so the issue is one of overriding the value assignments in the new Makefile.

prefix form sets the environment values but the new Makefile assignments
will be used if they are set.

postfix form sets the environment values but overrides the new Makefile
assignments if they are set.

This is used in axiom now. In the top level Makefile we have a variable
called NOISE. If we want to override that variable we simply type:

  make NOISE=

\start
Date: 22 Nov 2006 23:46:05 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: ENV

Tim Daly writes:

[...]

| > | everything will still work.
| > | ENV is just a local name created 20 years ago.
| > 
| > Not just because it was created 20 years ago means that its usage is
| > correct today.  The world did not stop spining while Axiom was
| > hibernating.
| 
| There is an interaction between the shell variable mechanism,
| the way make expands and overrides variables, and the command line.

Yes.  

[...]

| The way axiom's makefile work you can override the make variables
| on the command line thus:

so does build-improvements.

| make AWK=nawk
| 
| but it appears that this is not true with MAKEFLAGS

build-improvements sets the variable AWK in Makefiles, derived from
configure findings.  This is set in every generated Makefile.
Consequently it is overridable from the command line.  Try

   make AWK=nawk 

   Overriding Variables
   ====================

      An argument that contains `=' specifies the value of a variable:
   `V=X' sets the value of the variable V to X.  If you specify a value in
   this way, all ordinary assignments of the same variable in the makefile
   are ignored; we say they have been "overridden" by the command line
   argument.


| http://lists.freebsd.org/pipermail/freebsd-bugs/2004-June/007479.html

Notice also that I'm not talking of .MAKEFLAGS, but only values passed
down in MAKEFLAGS.

I don't see this issue affecting build-improvements.

\start
Date: 22 Nov 2006 23:49:16 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: ENV

Tim Daly writes:

| > It may help to state the *specific meaning* of ENV in POSIX shells. I 
| > looked at the man page for bash and it says:
| > 
| >   "When invoked as an interactive shell with the name sh, bash looks for 
| > the variable ENV, expands its value  if  it  is defined,  and uses the 
| > expanded value as the name of a file to read and execute."
| > 
| > So I can imagine a call to "$ENV sh something" in a makefile to explode. 
| > What actually happened?
| 
| The shell never sees "$ENV".

It does.  That is it blew up.

[...]

| Every programmer knows that the name of a variable in a local
| context can be overloaded. I can't imagine why this is even a
| point of discussion. 

Because some programmer thought that he/she can grab anything and turn
it into a Make local variables.

| There should be NO confusion between a
| variable in a makefile and a variable in a shell.

But, the author of ENV had carefully designed something that made the
confusion between the two expansion happen.

I did not send out the message out of theory.  Get serious, man.

\start
Date: 22 Nov 2006 23:51:12 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: ENV

Tim Daly writes:

| > There is this line in the Makefile for regression testing:
| > 
| >   regress:
| >           ${ENV} ${MAKE} DAASE=$(axiom_targetdir) regression-tests
| > 
| > 
| > Notice that there is no explicit mention of sh, but Make will call it
| > because that is the way Make works.
| > 
| > In my case, I stepped into the build directory for input/ and typed
| > make.  At that point ENV (which is exported by my login shell) has the
| > value dictated by POSIX, but not overriden by toplevel Makefile.  So
| > it expanded to /etc/bash.bashrc.
| > 
| > Notice that even if ENV has been overriden by the toplevel Makefile,
| > that doing is still wrong (it is only a matter of time to trip over
| > it) because the shell will see that the variable is defined and
| > attempt to use its value as indicating a file to read and execute.
| 
| An excellent point. Except that none of the makefiles in the axiom
| tree are designed to be executed "standalone". 

The old broken makefiles were designed that way.  Yes.  

\start
Date: Wed, 22 Nov 2006 18:01:28 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Testing build-improvements

On Wednesday, November 22, 2006 4:56 PM Gaby wrote:
>
> Bill Page writes:
> | Damn. I just can't keep up the pace. :-(
>
> hey, it is Thanksgiving soon :-)
>

Done that already. (I'm in Canada, eh?) Gotta work this
weekend. Have fun with the family when you still can!

> ...
> I'm interested in the difference between
>
>     $tangle -R"$chunk"
>
> and
>
>     $tangle -"R$chunk"
>
> (for true, I don't know the portability issue here; I'm just
> curious).
>

That should be:

$tangle "-R$chunk"

But in the 4 shells to which I have easy access (bash, sh, csh,
and ksh) there seems to be no difference in behaviour. And I
assume also in zsh. So apparently it is just an issue of style
or folklore. Write that one off...

\start
Date: 22 Nov 2006 23:55:19 +0100
From: Gabriel Dos Reis
To: list
Subject: Re: [build-improvements] Remove K&R cruft from	src/lib

Gabriel Dos Reis writes:

| While, I was looking at src/lib to gather unwritten assumptions made by
| the C programs, my eyes were glazing over the antiquated K&R C style
| declaration of functions. In 2006, we have no more reasons to write C
| codes that way.  Especially, none for Axiom.  While I was there, I saw
| various "broken" C codes, more on that latter.

For src/hyper.

-- Gaby

2006-11-21  Gabriel Dos Reis  Gabriel Dos Reis

	* addfile.pamphlet: Remove conditional K&R C style function
	declaration. 
	* cond.pamphlet: Likewise.
	* debug.pamphlet: Likewise.
	* dialog.pamphlet: Likewise.
	* display.pamphlet: Likewise.
	* event.pamphlet: Likewise.
	* ex2ht.pamphlet: Likewise.
	* extent1.pamphlet: Likewise.
	* extent2.pamphlet: Likewise.
	* form-ext.pamphlet: Likewise.
	* group.pamphlet: Likewise.
	* halloc.pamphlet: Likewise.
	* hash.pamphlet: Likewise.
	* htadd.pamphlet: Likewise.
	* hterror.pamphlet: Likewise.
	* hthits.pamphlet: Likewise.
	* htinp.pamphlet: Likewise.
	* hyper.pamphlet: Likewise.
	* initx.pamphlet: Likewise.
	* input.pamphlet: Likewise.
	* item.pamphlet: Likewise.
	* keyin.pamphlet: Likewise.
	* lex.pamphlet: Likewise.
	* macro.pamphlet: Likewise.
	* mem.pamphlet: Likewise.
	* parse-aux.pamphlet: Likewise.
	* parse-input.pamphlet: Likewise.
	* parse-paste.pamphlet: Likewise.
	* parse-types.pamphlet: Likewise.
	* ReadBitmap.pamphlet: Likewise.
	* scrollbar.pamphlet: Likewise.
	* show-types.pamphlet: Likewise.
	* spadbuf.pamphlet: Likewise.
	* spadint.pamphlet: Likewise.
	* titlebar.pamphlet: Likewise.

*** src/hyper/ReadBitmap.pamphlet	(revision 16913)
--- src/hyper/ReadBitmap.pamphlet	(local)
*************** been picked up by Unix so we change it g
*** 41,56 ****
   */
  
  XImage *
! #ifdef _NO_PROTO
! HTReadBitmapFile(display, screen, filename, width, height)
! 	Display * display;
! 	int screen;
! 	char *filename;
! 	int *width;
! 	int *height;
! #else
! HTReadBitmapFile(Display *display,int screen,char * filename, int *width, int *height)
! #endif
  {
      XImage *image;
      FILE *fd;
--- 41,48 ----
   */
  
  XImage *
! HTReadBitmapFile(Display *display,int screen,char * filename, 
!                  int *width, int *height)
  {
      XImage *image;
      FILE *fd;
*************** HTReadBitmapFile(Display *display,int sc
*** 162,176 ****
  }
  
  static int
- #ifdef _NO_PROTO
- read_hot(fd,Line,x_hot,y_hot)
- FILE * fd;
- char Line[];
- int *x_hot;
- int *y_hot;
- #else
  read_hot(FILE *fd,char Line[],int *x_hot,int *y_hot)
- #endif
  {
      char Buff[256];
  
--- 154,160 ----
*************** read_hot(FILE *fd,char Line[],int *x_hot
*** 193,206 ****
  }
  
  static int
- #ifdef _NO_PROTO
- read_w_and_h(fd,width,height)
- FILE * fd;
- unsigned int *width;
- unsigned int *height;
- #else
  read_w_and_h(FILE *fd,unsigned int *width,unsigned int *height)
- #endif
  {
      char Line[256], Buff[256];
  
--- 177,183 ----
*************** read_w_and_h(FILE *fd,unsigned int *widt
*** 236,247 ****
  /* read a bitmap file into memory */
  
  ImageStruct *
- #ifdef _NO_PROTO
- insert_image_struct(filename)
- char *filename;
- #else
  insert_image_struct(char *filename)
- #endif
  {
      int bm_width, bm_height;
      XImage *im;
--- 213,219 ----
*** src/hyper/addfile.pamphlet	(revision 16913)
--- src/hyper/addfile.pamphlet	(local)
*************** extern char *gDatabasePath;
*** 37,49 ****
  char *gDatabasePath = NULL;
  
  static int
- #ifndef _NO_PROTO
  strpostfix(char *s, char *t)
- #else
- strpostfix(s,t)
- char *s;
- char *t;
- #endif
  {
      int slen = strlen(s), tlen = strlen(t);
  
--- 37,43 ----
*************** char *t;
*** 58,69 ****
  /* extend_ht : just checks the name and adds a .ht if needed */
  
  void
- #ifndef _NO_PROTO
  extend_ht(char *name)
- #else
- extend_ht(name)
- char *name;
- #endif
  {
  
      if (!strpostfix(name, ".ht") && !strpostfix(name, ".pht"))
--- 52,58 ----
*************** char *name;
*** 82,93 ****
   */
  
  static int
- #ifndef _NO_PROTO
  build_ht_filename(char *fname, char *aname, char *name)
- #else
- build_ht_filename(fname,aname,name)
- char *fname,*aname,*name;
- #endif
  {
      char cdir[256];
      char *c_dir;
--- 71,77 ----
*************** char *fname,*aname,*name;
*** 186,198 ****
  }
  
  static int
- #ifndef _NO_PROTO
  pathname(char *name)
- #else
- pathname(name)
- char *name;
- #endif
- 
  {
      while (*name)
          if (*name++ == '/')
--- 170,176 ----
*************** char *name;
*** 204,215 ****
  /** This procedure opens the proper HT file **/
  
  FILE *
- #ifndef _NO_PROTO
  ht_file_open(char *fname, char *aname, char *name)
- #else
- ht_file_open(fname,aname,name)
- char *fname,*aname,*name;
- #endif
  {
      FILE *ht_fp;
      int ret_value;
--- 182,188 ----
*************** char *fname,*aname,*name;
*** 250,261 ****
  
  
  FILE *
- #ifndef _NO_PROTO
  db_file_open(char *db_file)
- #else
- db_file_open(db_file)
- char *db_file;
- #endif
  {
      static char *db_path_trace = NULL;
      char *db_file_trace;
--- 223,229 ----
*************** char *db_file;
*** 311,322 ****
  
  
  FILE *
- #ifndef _NO_PROTO
  temp_file_open(char *temp_db_file)
- #else
- temp_file_open(temp_db_file)
- char *temp_db_file;
- #endif
  {
      FILE *temp_db_fp;
  
--- 279,285 ----
*** src/hyper/cond.pamphlet	(revision 16913)
--- src/hyper/cond.pamphlet	(local)
***************
*** 39,50 ****
  
  
  void
- #ifndef _NO_PROTO
  insert_cond(char *label, char *cond)
- #else
- insert_cond(label,cond)
- char *label,*cond;
- #endif
  {
      CondNode *condnode = (CondNode *) hash_find(gWindow->fCondHashTable, label);
  
--- 39,45 ----
*************** char *label,*cond;
*** 66,77 ****
  }
  
  void
- #ifndef _NO_PROTO
  change_cond(char *label, char *newcond)
- #else
- change_cond(label,newcond)
- char *label,newcond;
- #endif
  {
      CondNode *condnode = (CondNode *) hash_find(gWindow->fCondHashTable, label);
  
--- 61,67 ----
*************** char *label,newcond;
*** 86,97 ****
  }
  
  static int
- #ifndef _NO_PROTO
  check_memostack(TextNode *node)
- #else
- check_memostack(node)
- TextNode *node;
- #endif
  {
      char *buffer;
      int stackp = gWindow->fMemoStackIndex;
--- 76,82 ----
*************** TextNode *node;
*** 114,125 ****
  }
  
  int
- #ifndef _NO_PROTO
  check_condition(TextNode *node)
- #else
- check_condition(node)
- TextNode *node;
- #endif
  {
      CondNode *cond;
      InputBox *box;
--- 99,105 ----
*** src/hyper/debug.pamphlet	(revision 16913)
--- src/hyper/debug.pamphlet	(local)
***************
*** 18,27 ****
  
  #ifdef free
  #undef free
! hfree(p)
! char *p;
  {
! free(p);
  }
  #endif
  
--- 18,26 ----
  
  #ifdef free
  #undef free
! hfree(char *p)
  {
!   free(p);
  }
  #endif
  
*** src/hyper/dialog.pamphlet	(revision 16913)
--- src/hyper/dialog.pamphlet	(local)
***************
*** 46,56 ****
  
  
  static void
- #ifdef _NO_PROTO
  redraw_win()
- #else
- redraw_win(void)
- #endif
  {
      XUnmapSubwindows(gXDisplay, gWindow->fMainWindow);
      XUnmapSubwindows(gXDisplay, gWindow->fScrollWindow);
--- 46,52 ----
*************** redraw_win(void)
*** 59,74 ****
  }
  
  static char *
- #ifndef _NO_PROTO
  mystrncpy(char *buff1, char *buff2, int n)
- #else
- mystrncpy(buff1,buff2,n)
- char *buff1;
- char *buff2;
- int n;
- #endif
- 
- 
  {
      /*
       * copies the characters from buff1 to buff2 starting at position buff2 +
--- 55,61 ----
*************** int n;
*** 83,107 ****
  }
  
  static void
- #ifndef _NO_PROTO
  inc_line_numbers(LineStruct *line)
- #else
- inc_line_numbers(line)
- LineStruct *line;
- #endif
- 
  {
      for (; line != NULL; line = line->next)
          line->line_number++;
  }
  
  static void
- #ifndef _NO_PROTO
  dec_line_numbers(LineStruct *line)
- #else
- dec_line_numbers(line)
- LineStruct *line;
- #endif
  {
      for (; line != NULL; line = line->next)
          line->line_number--;
--- 70,83 ----
*************** LineStruct *line;
*** 109,135 ****
  }
  
  static void
- #ifndef _NO_PROTO
  decrease_line_numbers(LineStruct *line, int am)
- #else
- decrease_line_numbers(line,am)
- LineStruct *line;
- int am;
- #endif
- 
  {
      for (; line != NULL; line = line->next)
          line->line_number -= am;
  }
  
  static void
- #ifndef _NO_PROTO
  overwrite_buffer(char *buffer, InputItem *item)
- #else
- overwrite_buffer(buffer,item)
- char *buffer;
- InputItem *item;
- #endif
  {
      LineStruct *newline;
      LineStruct *addline = item->curr_line;
--- 85,98 ----
*************** InputItem *item;
*** 207,222 ****
   */
  
  static int
- #ifndef _NO_PROTO
  move_sym_forward(LineStruct *line, int num, int size, InputItem *sym)
- #else
- move_sym_forward(line,num,size,sym)
- LineStruct *line;
- int num;
- int size;
- InputItem *sym;
- #endif
- 
  {
      LineStruct *newline;
      int diff;
--- 170,176 ----
*************** InputItem *sym;
*** 261,274 ****
  }
  
  static void
- #ifndef _NO_PROTO
  clear_cursorline(InputItem *sym)
- #else
- clear_cursorline(sym)
- InputItem *sym;
- #endif
- 
- 
  {
      XCharStruct extents;
      int dir, asc, des;
--- 215,221 ----
*************** InputItem *sym;
*** 287,299 ****
  }
  
  static void
- #ifndef _NO_PROTO
  insert_buffer(char *buffer, InputItem *sym)
- #else
- insert_buffer(buffer,sym)
- char *buffer;
- InputItem *sym;
- #endif
  {
      /*int num = strlen(buffer);*/
      LineStruct *line = sym->curr_line;
--- 234,240 ----
*************** InputItem *sym;
*** 387,400 ****
  }
  
  void
- #ifndef _NO_PROTO
  add_buffer_to_sym(char *buffer,InputItem *sym)
- #else
- add_buffer_to_sym(buffer,sym)
- char *buffer;
- InputItem *sym;
- #endif
- 
  {
      if (gInInsertMode)
          insert_buffer(buffer, sym);
--- 328,334 ----
*************** InputItem *sym;
*** 403,415 ****
  }
  
  void
- #ifndef _NO_PROTO
  draw_inputsymbol(InputItem *sym)
- #else
- draw_inputsymbol(sym)
- InputItem *sym;
- #endif
- 
  {
      int y_spot = start_y;
      LineStruct *cline;
--- 337,343 ----
*************** InputItem *sym;
*** 447,458 ****
  }
  
  void
- #ifndef _NO_PROTO
  update_inputsymbol(InputItem *sym)
- #else
- update_inputsymbol(sym)
- InputItem *sym;
- #endif
  {
      int y_spot = start_y;
      LineStruct *cline;
--- 375,381 ----
*************** InputItem *sym;
*** 498,509 ****
  
  
  static void
- #ifndef _NO_PROTO
  draw_cursor(InputItem *sym)
- #else
- draw_cursor(sym)
- InputItem *sym;
- #endif
  {
      int cursor_y;
      XCharStruct extents;
--- 421,427 ----
*************** InputItem *sym;
*** 539,550 ****
  }
  
  static void
- #ifndef _NO_PROTO
  move_cursor_home(InputItem *sym)
- #else
- move_cursor_home(sym)
- InputItem *sym;
- #endif
  {
      LineStruct *trace = sym->curr_line;
  
--- 457,463 ----
*************** InputItem *sym;
*** 558,569 ****
  }
  
  static void
- #ifndef _NO_PROTO
  move_cursor_end(InputItem *sym)
- #else
- move_cursor_end(sym)
- InputItem *sym;
- #endif
  {
      LineStruct *trace = sym->curr_line;
  
--- 471,477 ----
*************** InputItem *sym;
*** 577,588 ****
  }
  
  static void
- #ifndef _NO_PROTO
  move_cursor_forward(InputItem *sym)
- #else
- move_cursor_forward(sym)
- InputItem *sym;
- #endif
  {
      if (sym->curr_line->buff_pntr == sym->curr_line->len &&
          !sym->curr_line->next) {
--- 485,491 ----
*************** InputItem *sym;
*** 618,629 ****
  }
  
  static void
- #ifndef _NO_PROTO
  move_cursor_down(InputItem *sym)
- #else
- move_cursor_down(sym)
- InputItem *sym;
- #endif
  {
      int bp = sym->curr_line->buff_pntr;
      /*int size = sym->size;*/
--- 521,527 ----
*************** InputItem *sym;
*** 648,659 ****
  }
  
  static void
- #ifndef _NO_PROTO
  move_cursor_up(InputItem *sym)
- #else
- move_cursor_up(sym)
- InputItem *sym;
- #endif
  {
      int bp = sym->curr_line->buff_pntr;
      /*int size = sym->size;*/
--- 546,552 ----
*************** InputItem *sym;
*** 679,690 ****
  }
  
  static void
- #ifndef _NO_PROTO
  clear_cursor(InputItem *sym)
- #else
- clear_cursor(sym)
- InputItem *sym;
- #endif
  {
      XCharStruct extents;
      int dir, asc, des;
--- 572,578 ----
*************** InputItem *sym;
*** 705,716 ****
  }
  
  static void
- #ifndef _NO_PROTO
  move_cursor_backward(InputItem *sym)
- #else
- move_cursor_backward(sym)
- InputItem *sym;
- #endif
  {
      if (sym->curr_line->buff_pntr == 0) {
          if (sym->curr_line->prev == NULL) {
--- 593,599 ----
*************** InputItem *sym;
*** 737,749 ****
  }
  
  static char
- #ifndef _NO_PROTO
  move_rest_back(LineStruct *line, int size)
- #else
- move_rest_back(line,size)
- LineStruct *line;
- int size;
- #endif
  {
      char c = '\000';
  
--- 620,626 ----
*************** int size;
*** 778,789 ****
  }
  
  static void
- #ifndef _NO_PROTO
  delete_rest_of_line(InputItem *sym)
- #else
- delete_rest_of_line(sym)
- InputItem *sym;
- #endif
  {
      LineStruct *curr_line = sym->curr_line;
      LineStruct *line=NULL;
--- 655,661 ----
*************** InputItem *sym;
*** 852,863 ****
  }
  
  static void
- #ifndef _NO_PROTO
  back_over_eoln(InputItem *sym)
- #else
- back_over_eoln(sym)
- InputItem *sym;
- #endif
  {
      /*
       * This routine is very similar to a tough enter except it starts
--- 724,730 ----
*************** InputItem *sym;
*** 933,944 ****
  }
  
  static int
- #ifndef _NO_PROTO
  move_back_one_char(InputItem *sym)
- #else
- move_back_one_char(sym)
- InputItem *sym;
- #endif
  {
      char c = '\000', d = '\000';
      int dl = 0;
--- 800,806 ----
*************** InputItem *sym;
*** 1034,1057 ****
  }
  
  static void
- #ifndef _NO_PROTO
  back_over_char(InputItem *sym)
- #else
- back_over_char(sym)
- InputItem *sym;
- #endif
  {
      if (move_back_one_char(sym))
          update_inputsymbol(sym);
  }
  
  static void
- #ifndef _NO_PROTO
  delete_eoln(InputItem *sym)
- #else
- delete_eoln(sym)
- InputItem *sym;
- #endif
  {
      /* much the same as back_over eoln except my perspective has changed */
      char buff[1024];
--- 896,909 ----
*************** InputItem *sym;
*** 1120,1131 ****
  }
  
  static int
- #ifndef _NO_PROTO
  delete_one_char(InputItem *sym)
- #else
- delete_one_char(sym)
- InputItem *sym;
- #endif
  {
      char c = '\000';
  
--- 972,978 ----
*************** InputItem *sym;
*** 1180,1203 ****
  }
  
  static void
- #ifndef _NO_PROTO
  delete_char(InputItem *sym)
- #else
- delete_char(sym)
- InputItem *sym;
- #endif
  {
      if (delete_one_char(sym))
          update_inputsymbol(sym);
  }
  
  static void
- #ifndef _NO_PROTO
  tough_enter(InputItem *sym)
- #else
- tough_enter(sym)
- InputItem *sym;
- #endif
  {
      char buff[1024];
  
--- 1027,1040 ----
*************** InputItem *sym;
*** 1279,1290 ****
  }
  
  static void
- #ifndef _NO_PROTO
  enter_new_line(InputItem *sym)
- #else
- enter_new_line(sym)
- InputItem *sym;
- #endif
  {
      LineStruct *newline;
      LineStruct *trace;
--- 1116,1122 ----
*************** InputItem *sym;
*** 1365,1378 ****
  }
  
  void
- #ifndef _NO_PROTO
  dialog(XEvent *event, KeySym keysym, char *buffer)
- #else
- dialog(event,keysym,buffer)
- XEvent *event;
- KeySym keysym;
- char *buffer;
- #endif
  {
      InputItem *item;
  
--- 1197,1203 ----
*** src/hyper/display.pamphlet	(revision 16913)
--- src/hyper/display.pamphlet	(local)
*************** int gRegionOffset = 0;
*** 65,76 ****
  /* Display a HyperDoc page in the top-level window */
  
  void
- #ifdef _NO_PROTO
- show_page(page)
- HyperDocPage *page;
- #else
  show_page(HyperDocPage *page)
- #endif
  {
      XWindowChanges wc;
      int doShowScrollBars = 1;
--- 65,71 ----
*************** show_page(HyperDocPage *page)
*** 171,182 ****
  }
  
  void
- #ifdef _NO_PROTO
- expose_page(page)
- HyperDocPage *page;
- #else
  expose_page(HyperDocPage *page)
- #endif
  {
      int width, height, doShowScrollBars = 1;
      init_top_group();
--- 166,172 ----
*************** expose_page(HyperDocPage *page)
*** 228,239 ****
  }
  
  void
- #ifdef _NO_PROTO
- scroll_page(page)
- HyperDocPage *page;
- #else
  scroll_page(HyperDocPage *page)
- #endif
  {
      init_top_group();
      /* free the active button list */
--- 218,224 ----
*************** scroll_page(HyperDocPage *page)
*** 251,262 ****
  }
  
  void
- #ifdef _NO_PROTO
- paste_page(node)
- TextNode *node;
- #else
  paste_page(TextNode *node)
- #endif
  {
      int width, height;
      int old_off = gWindow->page->scroll_off;
--- 236,242 ----
*** src/hyper/event.pamphlet	(revision 16913)
--- src/hyper/event.pamphlet	(local)
*************** static HyperLink *gSavedInputAreaLink = 
*** 72,82 ****
   */
  
  void
- #ifndef _NO_PROTO
  mainEventLoop(void)
- #else
- mainEventLoop()
- #endif
  {
      XEvent event;
      int  Xcon;
--- 72,78 ----
*************** mainEventLoop()
*** 152,163 ****
  }
  
  static void
- #ifndef _NO_PROTO
  handle_event(XEvent * event)
- #else
- handle_event(event)
- XEvent * event;
- #endif
  {
      XWindowAttributes wa;
  /*    fprintf(stderr,"event:handle_event entered\n");*/
--- 148,154 ----
*************** XEvent * event;
*** 270,280 ****
  }
  
  static void
- #ifndef _NO_PROTO
  create_window(void)
- #else
- create_window()
- #endif
  {
      XWindowAttributes wa;
  
--- 261,267 ----
*************** create_window()
*** 299,309 ****
   */
  
  void
- #ifndef _NO_PROTO
  quitHyperDoc(void)
- #else
- quitHyperDoc()
- #endif
  {
      HyperDocPage *page;
  
--- 286,292 ----
*************** quitHyperDoc()
*** 336,347 ****
   */
  
  static HyperDocPage *
- #ifndef _NO_PROTO
  find_page(TextNode * node)
- #else
- find_page(node)
- TextNode * node;
- #endif
  {
      char *page_name;
      HyperDocPage *page;
--- 319,325 ----
*************** TextNode * node;
*** 379,389 ****
  /* pushes a page onto the down link stack */
  
  static void
- #ifndef _NO_PROTO
  downlink(void)
- #else
- downlink()
- #endif
  {
      if (gWindow->fDownLinkStackIndex == MaxDownlinkDepth)
          fprintf(stderr, "exceeded maximum link nesting level\n");
--- 357,363 ----
*************** downlink()
*** 392,402 ****
  }
  
  static void
- #ifndef _NO_PROTO
  memolink(void)
- #else
- memolink()
- #endif
  {
      if (gWindow->fMemoStackIndex == MaxMemoDepth)
          fprintf(stderr, "exceeded maximum link nesting level\n");
--- 366,372 ----
*************** memolink()
*** 407,418 ****
  }
  
  static void
- #ifndef _NO_PROTO
  killAxiomPage(HyperDocPage * page)
- #else
- killAxiomPage(page)
- HyperDocPage * page;
- #endif
  {
      char command[512];
  
--- 377,383 ----
*************** HyperDocPage * page;
*** 421,432 ****
  }
  
  static void
- #ifndef _NO_PROTO
  kill_page(HyperDocPage * page)
- #else
- kill_page(page)
- HyperDocPage * page;
- #endif
  {
      page->scroll_off = 0;
      if (page->type == SpadGen) {
--- 386,392 ----
*************** HyperDocPage * page;
*** 439,449 ****
  /* pops the memo stack */
  
  static HyperDocPage *
- #ifndef _NO_PROTO
  returnlink(void)
- #else
- returnlink()
- #endif
  {
      int i;
  
--- 399,405 ----
*************** returnlink()
*** 468,478 ****
  /* pops a page if it can from the downlink stack */
  
  static HyperDocPage *
- #ifndef _NO_PROTO
  uplink(void)
- #else
- uplink()
- #endif
  {
      if (gWindow->fDownLinkStackIndex == 0)
          return returnlink();
--- 424,430 ----
*************** uplink()
*** 483,494 ****
  }
  
  static void
- #ifndef _NO_PROTO
  windowlink_handler(TextNode * node)
- #else
- windowlink_handler(node)
- TextNode * node;
- #endif
  {
      char *page_name;
  
--- 435,441 ----
*************** TextNode * node;
*** 502,513 ****
  }
  
  void
- #ifndef _NO_PROTO
  make_window_link(char *name)
- #else
- make_window_link(name)
- char *name;
- #endif
  {
      if (init_top_window(name) != -1)
  {}/*        gWindow->fWindowHashTable = gWindow->page->fLinkHashTable; */
--- 449,455 ----
*************** char *name;
*** 515,526 ****
  
  
  static void
- #ifndef _NO_PROTO
  lispwindowlink_handler(HyperLink * link)
- #else
- lispwindowlink_handler(link)
- HyperLink * link;
- #endif
  {
  
      /*
--- 457,463 ----
*************** HyperLink * link;
*** 540,551 ****
  }
  
  static HyperDocPage *
- #ifndef _NO_PROTO
  paste_button(PasteNode * paste)
- #else
- paste_button(paste)
- PasteNode * paste;
- #endif
  {
      HyperDocPage *page = NULL;
      int pastewhere=paste->where;
--- 477,483 ----
*************** PasteNode * paste;
*** 570,580 ****
  }
  
  void
- #ifndef _NO_PROTO
  helpForHyperDoc(void)
- #else
- helpForHyperDoc()
- #endif
  {
      HyperDocPage *page = NULL;
  
--- 502,508 ----
*************** helpForHyperDoc()
*** 602,615 ****
  }
  
  static HyperLink *
- #ifndef _NO_PROTO
  findButtonInList(HDWindow * window, int x, int y)
- #else
- findButtonInList(window,x,y)
- HDWindow * window;
- int x;
- int y;
- #endif
  {
      ButtonList *bl;
  
--- 530,536 ----
*************** int y;
*** 625,636 ****
  }
  
  static HyperLink *
- #ifndef _NO_PROTO
  get_hyper_link(XButtonEvent * event)
- #else
- get_hyper_link(event)
- XButtonEvent * event;
- #endif
  {
      HyperLink *l1, *l2;
  
--- 546,552 ----
*************** XButtonEvent * event;
*** 647,659 ****
   */
  
  static void
- #ifndef _NO_PROTO
  handle_button(int button, XButtonEvent * event)
- #else
- handle_button(button,event)
- int button;
- XButtonEvent * event;
- #endif
  {
      HyperLink *link;
      HyperDocPage *page = NULL;
--- 563,569 ----
*************** XButtonEvent * event;
*** 819,829 ****
  
  
  void
- #ifndef _NO_PROTO
  exitHyperDoc(void)
- #else
- exitHyperDoc()
- #endif
  {
      XEvent event;
  
--- 729,735 ----
*************** exitHyperDoc()
*** 863,874 ****
  }
  
  static int
- #ifndef _NO_PROTO
  set_window(Window window)
- #else
- set_window(window)
- Window window;
- #endif
  {
      Window root, parent, *children, grandparent,myarg;
      HDWindow *htw;
--- 769,775 ----
*************** ERROR:
*** 925,936 ****
   * given routine
   */
  static void
- #ifndef _NO_PROTO
  clear_exposures(Window w)
- #else
- clear_exposures(w)
- Window w;
- #endif
  {
      XEvent report;
  
--- 826,832 ----
*************** Window w;
*** 938,948 ****
      while (XCheckTypedWindowEvent(gXDisplay, w, Expose, &report));
  }
  void
- #ifndef _NO_PROTO
  get_new_window(void)
- #else
- get_new_window()
- #endif
  {
  
      int val;
--- 834,840 ----
*************** get_new_window()
*** 1065,1077 ****
      }
    }
  static void
- #ifndef _NO_PROTO
  set_cursor(HDWindow *window,Cursor state)
- #else
- set_cursor(window, state)
- HDWindow *window;
- Cursor state;
- #endif
  {
      if (state == gBusyCursor)
          XDefineCursor(gXDisplay, window->fMainWindow, gBusyCursor);
--- 957,963 ----
*************** Cursor state;
*** 1083,1095 ****
  }
  
  static void
- #ifndef _NO_PROTO
  change_cursor(Cursor state, HDWindow *window)
- #else
- change_cursor(state,window)
- Cursor state;
- HDWindow *window;
- #endif
  {
      if (window->fDisplayedCursor == state)
          return;
--- 969,975 ----
*************** HDWindow *window;
*** 1098,1109 ****
  }
  
  static void
- #ifndef _NO_PROTO
  handle_motion_event(XMotionEvent *event)
- #else
- handle_motion_event(event)
- XMotionEvent *event;
- #endif
  {
      if (!gWindow)
          return;
--- 978,984 ----
*************** XMotionEvent *event;
*** 1114,1125 ****
  }
  
  static void
- #ifndef _NO_PROTO
  init_cursor_state(HDWindow *window)
- #else
- init_cursor_state(window)
- HDWindow *window;
- #endif
  {
      if (window) {
          int x, y, rx, ry, but;
--- 989,995 ----
*************** HDWindow *window;
*** 1135,1179 ****
  }
  
  static void
- #ifndef _NO_PROTO
  init_cursor_states(void)
- #else
- init_cursor_states()
- #endif
  {
      hash_map(&gSessionHashTable,(MappableFunction) init_cursor_state);
  }
  
  
  static void
- #ifndef _NO_PROTO
  make_busy_cursor(HDWindow *window)
- #else
- make_busy_cursor(window)
- HDWindow *window;
- #endif
  {
      change_cursor(gBusyCursor, window);
  }
  
  static void
- #ifndef _NO_PROTO
  make_busy_cursors(void)
- #else
- make_busy_cursors()
- #endif
  {
      hash_map(&gSessionHashTable, (MappableFunction)make_busy_cursor);
  }
  
  static int
- #ifndef _NO_PROTO
  HyperDocErrorHandler(Display *display, XErrorEvent *xe)
- #else
- HyperDocErrorHandler(display,xe)
- Display *display;
- XErrorEvent *xe;
- #endif
  {
      if (xe->request_code != 15) {
          char buf[1024];
--- 1005,1030 ----
*************** XErrorEvent *xe;
*** 1195,1205 ****
  
  
  static void
- #ifndef _NO_PROTO
  set_error_handlers(void)
- #else
- set_error_handlers()
- #endif
  {
      XSetErrorHandler(HyperDocErrorHandler);
  }
--- 1046,1052 ----
*** src/hyper/ex2ht.pamphlet	(revision 16913)
--- src/hyper/ex2ht.pamphlet	(local)
*************** struct timeval latest_date[2] ={{0,0},{0
*** 44,56 ****
  
  
  int
- #ifndef _NO_PROTO
  main(int argc, char **argv)
- #else
- main(argc,argv)
- int argc;
- char **argv;
- #endif
  {
      int i;
  
--- 44,50 ----
*************** char **argv;
*** 69,80 ****
  }
  
  char *
- #ifdef _NO_PROTO
- allocString(s)
-     char *s;
- #else
  allocString(char *s)
- #endif
  {
      char *t = (char *) malloc(strlen(s) + 1);
  
--- 63,69 ----
*************** allocString(char *s)
*** 83,94 ****
  }
  
  char *
- #ifdef _NO_PROTO
- strPrefix(prefix, s)
-     char *prefix, *s;
- #else
  strPrefix(char *prefix, char *s)
- #endif
  {
      while (*prefix != '\0' && *prefix == *s) {
          prefix++;
--- 72,78 ----
*************** strPrefix(char *prefix, char *s)
*** 100,112 ****
  }
  
  char *
- #ifdef _NO_PROTO
- getExTitle(inFile, line)
-     FILE *inFile;
-     char *line;
- #else
  getExTitle(FILE *inFile, char *line)
- #endif
  {
      char *title;
  
--- 84,90 ----
*************** getExTitle(FILE *inFile, char *line)
*** 120,131 ****
  }
  
  void 
- #ifdef _NO_PROTO
- exToHt(filename)
-     char *filename;
- #else
  exToHt(char *filename)
- #endif
  {
      char line[MaxLineLength], *line2;
      char *title, *pagename;
--- 98,104 ----
*************** exToHt(char *filename)
*** 184,221 ****
  }
  
  void 
- #ifdef _NO_PROTO
- emitHeader(outFile, pageName, pageTitle)
-     FILE *outFile;
-     char *pageName, *pageTitle;
- #else
  emitHeader(FILE *outFile, char *pageName, char *pageTitle)
- #endif
  {
      fprintf(outFile, "\\begin{page}{%s}{%s}\n", pageName, pageTitle);
      fprintf(outFile, "\\beginscroll\\beginmenu\n");
  }
  
  void 
- #ifdef _NO_PROTO
- emitFooter(outFile)
-     FILE *outFile;
- #else
  emitFooter(FILE *outFile)
- #endif
  {
      fprintf(outFile, "\\endmenu\\endscroll\\end{page}\n");
  }
  
  /* s is pageName}{title} */
  void
- #ifdef _NO_PROTO
- emitMenuEntry(line, outFile)
-     char *line;
-     FILE *outFile;
- #else
  emitMenuEntry(char *line, FILE *outFile)
- #endif
  {
      char pageName[MaxLineLength], title[MaxLineLength];
      char *p = pageName, *t = title;
--- 157,177 ----
*************** emitMenuEntry(char *line, FILE *outFile)
*** 231,243 ****
  }
  
  void
- #ifdef _NO_PROTO
- emitSpadCommand(line, prefix, outFile)
-     char *line, *prefix;
-     FILE *outFile;
- #else
  emitSpadCommand(char *line, char *prefix, FILE *outFile)
- #endif
  {
      int braceCount = 1;
      char command[MaxLineLength], *t = command;
--- 187,193 ----
*************** emitSpadCommand(char *line, char *prefix
*** 260,270 ****
  FILE *coverFile;
  
  void
- #ifdef _NO_PROTO
- openCoverPage()
- #else
  openCoverPage(void)
- #endif
  {
      coverFile = fopen("coverex.ht", "w");
      if (coverFile == NULL) {
--- 210,216 ----
*************** openCoverPage(void)
*** 277,297 ****
  }
  
  void
- #ifdef _NO_PROTO
- closeCoverPage()
- #else
  closeCoverPage(void)
- #endif
  {
      fprintf(coverFile, "}\\endscroll\\end{page}\n\n");
  }
  
  void
- #ifdef _NO_PROTO
- closeCoverFile()
- #else
  closeCoverFile(void)
- #endif
  {
      fclose(coverFile);
  #ifdef HP9platform
--- 223,235 ----
*************** closeCoverFile(void)
*** 302,324 ****
  }
  
  void
- #ifdef _NO_PROTO
- emitCoverLink(name, title)
-     char *name, *title;
- #else
  emitCoverLink(char *name, char *title)
- #endif
  {
      fprintf(coverFile, "{\\downlink{%s}{%s}}\n", title, name);
  }
  
  void
- #ifdef _NO_PROTO
- addFile(filename)
-     char *filename;
- #else
  addFile(char *filename)
- #endif
  {
      FILE *file = fopen(filename, "r");
      int c;
--- 240,252 ----
*** src/hyper/extent1.pamphlet	(revision 16913)
--- src/hyper/extent1.pamphlet	(local)
*************** TextNode *gLineNode;
*** 81,92 ****
   */
  
  static void
- #ifndef _NO_PROTO
  compute_input_extent(TextNode * node)
- #else
- compute_input_extent(node)
- TextNode * node;
- #endif
  {
      InputItem *item;
      int t_width;
--- 81,87 ----
*************** TextNode * node;
*** 125,136 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_punctuation_extent(TextNode * node)
- #else
- compute_punctuation_extent(node)
- TextNode * node;
- #endif
  {
      int twidth;
      int nextwidth;
--- 120,126 ----
*************** TextNode * node;
*** 191,202 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_word_extent(TextNode * node)
- #else
- compute_word_extent(node)
- TextNode * node;
- #endif
  {
      int twidth;
      int nextwidth;
--- 181,187 ----
*************** TextNode * node;
*** 250,261 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_verbatim_extent(TextNode *node)
- #else
- compute_verbatim_extent(node)
- TextNode * node;
- #endif
  {
      node->height = normal_text_height;
      node->width = strlen(node->data.text);
--- 235,241 ----
*************** TextNode * node;
*** 267,278 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_spadsrctxt_extent(TextNode *node)
- #else
- compute_spadsrctxt_extent(node)
- TextNode * node;
- #endif
  {
      node->height = normal_text_height;
      node->width = strlen(node->data.text);
--- 247,253 ----
*************** TextNode * node;
*** 288,300 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_dash_extent(TextNode *node)
- #else
- compute_dash_extent(node)
- TextNode * node;
- #endif
- 
  {
      int num_dashes;
      int twidth;
--- 263,269 ----
*************** TextNode * node;
*** 352,363 ****
  }
  
  void
- #ifndef _NO_PROTO
  compute_text_extent(TextNode *node)
- #else
- compute_text_extent(node)
- TextNode * node;
- #endif
  {
      for (; node != NULL; node = node->next) {
          switch (node->type) {
--- 321,327 ----
*************** TextNode * node;
*** 683,694 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_begin_items_extent(TextNode * node)
- #else
- compute_begin_items_extent(node)
- TextNode * node;
- #endif
  {
      int store_x, store_y, lh;
  
--- 647,653 ----
*************** TextNode * node;
*** 722,733 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_item_extent(TextNode * node)
- #else
- compute_item_extent(node)
- TextNode * node;
- #endif
  {
      if (gInLine)
          start_newline(present_line_height, node);
--- 681,687 ----
*************** TextNode * node;
*** 735,746 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_mitem_extent(TextNode *node)
- #else
- compute_mitem_extent(node)
- TextNode * node;
- #endif
  {
      if (gInLine) {
          start_newline(present_line_height, node);
--- 689,695 ----
*************** TextNode * node;
*** 749,760 ****
  }
  
  static void
- #ifndef _NO_PROTO
  endif_extent(TextNode *node)
- #else
- endif_extent(node)
- TextNode * node;
- #endif
  {
      /*
       * This node has the responsibilty for updating text_x and text_y so that
--- 698,704 ----
*************** TextNode * node;
*** 767,778 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_ifcond_extent(TextNode *node)
- #else
- compute_ifcond_extent(node)
- TextNode * node;
- #endif
  {
      TextNode *condnode = node->data.ifnode->cond;
      TextNode *tln = gLineNode;
--- 711,717 ----
*************** TextNode * node;
*** 838,849 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_center_extent(TextNode * node)
- #else
- compute_center_extent(node)
- TextNode * node;
- #endif
  {
      if (gInLine)
          start_newline(present_line_height, node);
--- 777,783 ----
*************** TextNode * node;
*** 859,870 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_bf_extent(TextNode *node)
- #else
- compute_bf_extent(node)
- TextNode * node;
- #endif
  {
      if (gInLine && node->space)
          text_x += inter_word_space;
--- 793,799 ----
*************** TextNode * node;
*** 874,885 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_em_extent(TextNode *node)
- #else
- compute_em_extent(node)
- TextNode * node;
- #endif
  {
      if (gInLine && node->space)
          text_x += inter_word_space;
--- 803,809 ----
*************** TextNode * node;
*** 892,903 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_it_extent(TextNode *node)
- #else
- compute_it_extent(node)
- TextNode * node;
- #endif
  {
      if (gInLine && node->space)
          text_x += inter_word_space;
--- 816,822 ----
*************** TextNode * node;
*** 906,917 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_rm_extent(TextNode *node)
- #else
- compute_rm_extent(node)
- TextNode * node;
- #endif
  {
      if (gInLine && node->space)
          text_x += inter_word_space;
--- 825,831 ----
*************** TextNode * node;
*** 921,932 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_button_extent(TextNode *node)
- #else
- compute_button_extent(node)
- TextNode * node;
- #endif
  {
      int twidth;
      /*int store_x = text_x;*/
--- 835,841 ----
*************** TextNode * node;
*** 952,963 ****
  }
  
  static void
- #ifndef _NO_PROTO
  endbutton_extent(TextNode *node)
- #else
- endbutton_extent(node)
- TextNode * node;
- #endif
  {
      int temp;
      int height;
--- 861,867 ----
*************** TextNode * node;
*** 993,1004 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_pastebutton_extent(TextNode *node)
- #else
- compute_pastebutton_extent(node)
- TextNode * node;
- #endif
  {
      int twidth;
  
--- 897,903 ----
*************** TextNode * node;
*** 1024,1035 ****
  }
  
  static void
- #ifndef _NO_PROTO
  endpastebutton_extent(TextNode *node)
- #else
- endpastebutton_extent(node)
- TextNode * node;
- #endif
  {
      int temp;
      int height;
--- 923,929 ----
*************** TextNode * node;
*** 1057,1068 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_paste_extent(TextNode *node)
- #else
- compute_paste_extent(node)
- TextNode * node;
- #endif
  {
      if (gInLine) {
          start_newline(present_line_height, node);
--- 951,957 ----
*************** TextNode * node;
*** 1076,1087 ****
  /* Compute the text extent of a spadcommand node */
  
  static void
- #ifndef _NO_PROTO
  compute_spadcommand_extent(TextNode *node)
- #else
- compute_spadcommand_extent(node)
- TextNode * node;
- #endif
  {
      /*
       * From now on if there is an example which will take over a line, then
--- 965,971 ----
*************** TextNode * node;
*** 1113,1124 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_spadsrc_extent(TextNode *node)
- #else
- compute_spadsrc_extent(node)
- TextNode * node;
- #endif
  {
      /*
       * From now on if there is an example which will take over a line, then
--- 997,1003 ----
*************** TextNode * node;
*** 1144,1155 ****
  }
  
  static void
- #ifndef _NO_PROTO
  end_spadcommand_extent(TextNode *node)
- #else
- end_spadcommand_extent(node)
- TextNode * node;
- #endif
  {
      int temp;
      int height;
--- 1023,1029 ----
*************** TextNode * node;
*** 1179,1190 ****
  }
  
  static void
- #ifndef _NO_PROTO
  end_spadsrc_extent(TextNode *node)
- #else
- end_spadsrc_extent(node)
- TextNode * node;
- #endif
  {
      int temp;
      int height;
--- 1053,1059 ----
*************** TextNode * node;
*** 1214,1225 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_mbox_extent(TextNode *node)
- #else
- compute_mbox_extent(node)
- TextNode * node;
- #endif
  {
  
      node->width = text_width(node->next, Endmbox);
--- 1083,1089 ----
*************** TextNode * node;
*** 1234,1245 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_box_extent(TextNode *node)
- #else
- compute_box_extent(node)
- TextNode * node;
- #endif
  {
      int t_width;
  
--- 1098,1104 ----
*************** TextNode * node;
*** 1268,1279 ****
  }
  
  static void
- #ifndef _NO_PROTO
  compute_ir_extent(TextNode *node)
- #else
- compute_ir_extent(node)
- TextNode * node;
- #endif
  {
      int t_width;
  
--- 1127,1133 ----
*************** TextNode * node;
*** 1308,1319 ****
  /* read a bitmap file into memory */
  
  static void
- #ifndef _NO_PROTO
  compute_image_extent(TextNode *node)
- #else
- compute_image_extent(node)
- TextNode * node;
- #endif
  {
      if (text_x + node->width > right_margin) {
          start_newline(present_line_height, node);
--- 1162,1168 ----
*************** TextNode * node;
*** 1336,1347 ****
   */
  
  static void
- #ifndef _NO_PROTO
  compute_table_extent(TextNode **node)
- #else
- compute_table_extent(node)
- TextNode ** node;
- #endif
  {
      int num_cols, num_lines;
      int max_width = 0, node_width, col_width;
--- 1185,1191 ----
*************** TextNode ** node;
*** 1400,1411 ****
  }
  
  void
- #ifndef _NO_PROTO
  compute_title_extent(HyperDocPage *page)
- #else
- compute_title_extent(page)
- HyperDocPage *page;
- #endif
  {
      right_margin_space = non_scroll_right_margin_space;
      page->title->height = twheight + gWindow->border_width;
--- 1244,1250 ----
*************** HyperDocPage *page;
*** 1419,1430 ****
  }
  
  void
- #ifndef _NO_PROTO
  compute_header_extent(HyperDocPage *page)
- #else
- compute_header_extent(page)
- HyperDocPage *page;
- #endif
  {
  
      /*
--- 1258,1264 ----
*************** HyperDocPage *page;
*** 1455,1466 ****
  }
  
  void
- #ifndef _NO_PROTO
  compute_footer_extent(HyperDocPage * page)
- #else
- compute_footer_extent(page)
- HyperDocPage * page;
- #endif
  {
      if (page->footer) {
          gExtentRegion = Footer;
--- 1289,1295 ----
*************** HyperDocPage * page;
*** 1484,1495 ****
  }
  
  void
- #ifndef _NO_PROTO
  compute_scrolling_extent(HyperDocPage *page)
- #else
- compute_scrolling_extent(page)
- HyperDocPage *page;
- #endif
  {
      /* Check to see if there is a scrolling region  */
  
--- 1313,1319 ----
*** src/hyper/extent2.pamphlet	(revision 16913)
--- src/hyper/extent2.pamphlet	(local)
*************** static int max_x_value = 0;
*** 42,54 ****
   */
  
  void
- #ifndef _NO_PROTO
  start_newline(int distance, TextNode * node)
- #else
- start_newline(distance,node)
- int distance;
- TextNode * node;
- #endif
  {
      if (gLineNode != NULL) {
          if (gTopOfGroupStack->center)
--- 42,48 ----
*************** TextNode * node;
*** 67,79 ****
   */
  
  static void
- #ifndef _NO_PROTO
  center_nodes(TextNode * begin_node, TextNode * end_node)
- #else
- center_nodes(begin_node,end_node)
- TextNode * begin_node;
- TextNode * end_node;
- #endif
  {
      int begin_x, end_x, wmid_x, offset, mid_x;
      TextNode *node;
--- 61,67 ----
*************** TextNode * end_node;
*** 94,105 ****
  }
  
  static int
- #ifndef _NO_PROTO
  punctuation_width(TextNode * node)
- #else
- punctuation_width(node)
- TextNode * node;
- #endif
  {
      int twidth, width = strlen(node->data.text);
  
--- 82,88 ----
*************** TextNode * node;
*** 126,137 ****
  }
  
  static int
- #ifndef _NO_PROTO
  input_string_width(TextNode * node)
- #else
- input_string_width(node)
- TextNode * node;
- #endif
  {
      InputItem *item;
      int t_width;
--- 109,115 ----
*************** TextNode * node;
*** 149,160 ****
  }
  
  static int
- #ifndef _NO_PROTO
  word_width(TextNode * node)
- #else
- word_width(node)
- TextNode * node;
- #endif
  {
      int twidth, len = strlen(node->data.text);
  
--- 127,133 ----
*************** TextNode * node;
*** 166,177 ****
  }
  
  static int
- #ifndef _NO_PROTO
  verbatim_width(TextNode * node)
- #else
- verbatim_width(node)
- TextNode * node;
- #endif
  {
      int twidth, len = strlen(node->data.text);
  
--- 139,145 ----
*************** TextNode * node;
*** 183,194 ****
  }
  
  static int
- #ifndef _NO_PROTO
  width_of_dash(TextNode * node)
- #else
- width_of_dash(node)
- TextNode * node;
- #endif
  {
      int num_dashes, twidth;
  
--- 151,157 ----
*************** TextNode * node;
*** 209,221 ****
   */
  
  int
- #ifndef _NO_PROTO
  text_width(TextNode * node, int Ender)
- #else
- text_width(node,Ender)
- TextNode * node;
- int Ender;
- #endif
  {
      int twidth = 0, num_words;
  
--- 172,178 ----
*************** int Ender;
*** 407,419 ****
   */
  
  int
- #ifndef _NO_PROTO
  total_width(TextNode * node, int Ender)
- #else
- total_width(node,Ender)
- TextNode * node;
- int Ender;
- #endif
  {
      int twidth = 0;
  
--- 364,370 ----
*************** int Ender;
*** 511,521 ****
   */
  
  void
- #ifndef _NO_PROTO
  init_extents(void)
- #else
- init_extents()
- #endif
  {
      present_line_height = line_height;
      gInLine = 0;
--- 462,468 ----
*************** init_extents()
*** 536,547 ****
   */
  
  void
- #ifndef _NO_PROTO
  init_title_extents(HyperDocPage * page)
- #else
- init_title_extents(page)
- HyperDocPage * page;
- #endif
  {
      present_line_height = line_height;
      gInLine = 0;
--- 483,489 ----
*************** HyperDocPage * page;
*** 562,572 ****
   */
  
  void
- #ifndef _NO_PROTO
  init_text(void)
- #else
- init_text()
- #endif
  {
      normal_text_height = gRmFont->ascent + gRmFont->descent;
      line_height = gRmFont->ascent + gRmFont->descent + inter_line_space;
--- 504,510 ----
*************** init_text()
*** 579,591 ****
   */
  
  int
- #ifndef _NO_PROTO
  text_height(TextNode * node, int Ender)
- #else
- text_height(node,Ender)
- TextNode * node;
- int Ender;
- #endif
  {
      cur_height = 0;
      return text_height1(node, Ender);
--- 517,523 ----
*************** int Ender;
*** 596,608 ****
   */
  
  static int
- #ifndef _NO_PROTO
  text_height1(TextNode * node, int Ender)
- #else
- text_height1(node,Ender)
- TextNode * node;
- int Ender;
- #endif
  {
      for (; node != NULL; node = node->next) {
          if (Ender == Endtokens) {
--- 528,534 ----
*************** int Ender;
*** 728,740 ****
   */
  
  int
- #ifndef _NO_PROTO
  max_x(TextNode * node, int Ender)
- #else
- max_x(node,Ender)
- TextNode * node;
- int Ender;
- #endif
  {
      max_x_value = 0;
      for (; node != NULL; node = node->next) {
--- 654,660 ----
*************** int Ender;
*** 811,822 ****
  }
  
  static int
- #ifndef _NO_PROTO
  x_value(TextNode * node)
- #else
- x_value(node)
- TextNode * node;
- #endif
  {
      for (; node != NULL; node = node->next) {
          switch (node->type) {
--- 731,737 ----
*************** TextNode * node;
*** 872,883 ****
   */
  
  int
- #ifndef _NO_PROTO
  trailing_space(TextNode * node)
- #else
- trailing_space(node)
- TextNode * node;
- #endif
  {
      int space = 0;
  
--- 787,793 ----
*************** TextNode * node;
*** 893,904 ****
   */
  
  void
- #ifndef _NO_PROTO
  insert_bitmap_file(TextNode * node)
- #else
- insert_bitmap_file(node)
- TextNode * node;
- #endif
  {
      char *filename = node->data.text;
      int bm_width, bm_height;
--- 803,809 ----
*************** TextNode * node;
*** 941,952 ****
   */
  
  void
- #ifndef _NO_PROTO
  insert_pixmap_file(TextNode * node)
- #else
- insert_pixmap_file(node)
- TextNode * node;
- #endif
  {
      char *filename = node->data.text;
      int bm_width, bm_height, ret_val;
--- 846,852 ----
*************** TextNode * node;
*** 994,1005 ****
   */
  
  int
- #ifndef _NO_PROTO
  plh(int height)
- #else
- plh(height)
- int height;
- #endif
  {
      int rheight = height;
  
--- 894,900 ----
*** src/hyper/form-ext.pamphlet	(revision 16913)
--- src/hyper/form-ext.pamphlet	(local)
***************
*** 28,39 ****
   */
  
  void
- #ifndef _NO_PROTO
  compute_form_page(HyperDocPage *page)
- #else
- compute_form_page(page)
- HyperDocPage *page;
- #endif
  {
  
      /*
--- 28,34 ----
*************** HyperDocPage *page;
*** 57,80 ****
   * of columns given
   */
  int
- #ifndef _NO_PROTO
  window_width(int cols)
- #else
- window_width(cols)
- int cols;
- #endif
  {
      return (left_margin + cols * space_width + non_scroll_right_margin_space);
  }
  
  
  static int
- #ifndef _NO_PROTO
  window_height(HyperDocPage *page)
- #else
- window_height(page)
- HyperDocPage *page;
- #endif
  {
      int temp;
  
--- 52,65 ----
*************** HyperDocPage *page;
*** 88,99 ****
  
  
  static void
- #ifndef _NO_PROTO
  form_header_extent(HyperDocPage *page)
- #else
- form_header_extent(page)
- HyperDocPage *page;
- #endif
  {
  
      /*
--- 73,79 ----
*************** HyperDocPage *page;
*** 112,123 ****
  }
  
  static void
- #ifndef _NO_PROTO
  form_footer_extent(HyperDocPage *page)
- #else
- form_footer_extent(page)
- HyperDocPage *page;
- #endif
  {
      if (page->footer) {
          gExtentRegion = Footer;
--- 92,98 ----
*************** HyperDocPage *page;
*** 139,150 ****
  }
  
  static void
- #ifndef _NO_PROTO
  form_scrolling_extent(HyperDocPage *page)
- #else
- form_scrolling_extent(page)
- HyperDocPage *page;
- #endif
  {
  
      /*
--- 114,120 ----
*** src/hyper/group.pamphlet	(revision 16913)
--- src/hyper/group.pamphlet	(local)
*************** GroupItem *gTopOfGroupStack = NULL;
*** 45,55 ****
  
  
  int
- #ifndef _NO_PROTO
  pop_group_stack(void)
- #else
- pop_group_stack()
- #endif
  {
      /* This routine pops the top of the current group stack */
      GroupItem *junk;
--- 45,51 ----
*************** pop_group_stack()
*** 77,87 ****
  }
  
  void
- #ifndef _NO_PROTO
  push_group_stack(void)
- #else
- push_group_stack()
- #endif
  {
      /*
       * This routine makes room by pushing a new item on the stack
--- 73,79 ----
*************** push_group_stack()
*** 98,108 ****
  }
  
  void
- #ifndef _NO_PROTO
  init_group_stack(void)
- #else
- init_group_stack()
- #endif
  {
      gTopOfGroupStack = (GroupItem *) halloc(sizeof(GroupItem), "Push Group Stack");
      gTopOfGroupStack->center = 0;
--- 90,96 ----
*************** init_group_stack()
*** 112,122 ****
  }
  
  void
- #ifndef _NO_PROTO
  em_top_group(void)
- #else
- em_top_group()
- #endif
  {
      if (! gTopOfGroupStack->next)
          push_group_stack();
--- 100,106 ----
*************** em_top_group()
*** 126,136 ****
  }
  
  void
- #ifndef _NO_PROTO
  rm_top_group(void)
- #else
- rm_top_group()
- #endif
  {
      if (! gTopOfGroupStack->next)
          push_group_stack();
--- 110,116 ----
*************** rm_top_group()
*** 141,151 ****
  }
  
  void
- #ifndef _NO_PROTO
  line_top_group(void)
- #else
- line_top_group()
- #endif
  {
      if (! gTopOfGroupStack->next)
          push_group_stack();
--- 121,127 ----
*************** line_top_group()
*** 156,166 ****
  }
  
  void
- #ifndef _NO_PROTO
  bf_top_group(void)
- #else
- bf_top_group()
- #endif
  {
      /*
       * Just in case the person is tryin a \em without a grouping
--- 132,138 ----
*************** bf_top_group()
*** 174,184 ****
  }
  
  void
- #ifndef _NO_PROTO
  tt_top_group(void)
- #else
- tt_top_group()
- #endif
  {
      if (! gTopOfGroupStack->next)
          push_group_stack();
--- 146,152 ----
*************** tt_top_group()
*** 188,198 ****
  }
  
  void
- #ifndef _NO_PROTO
  push_active_group(void)
- #else
- push_active_group()
- #endif
  {
      push_group_stack();
      gTopOfGroupStack->cur_font = gActiveFont;
--- 156,162 ----
*************** push_active_group()
*** 201,211 ****
  }
  
  void
- #ifndef _NO_PROTO
  push_spad_group(void)
- #else
- push_spad_group()
- #endif
  {
      push_group_stack();
      gTopOfGroupStack->cur_font = gAxiomFont;
--- 165,171 ----
*************** push_spad_group()
*** 214,224 ****
  }
  
  void
- #ifndef _NO_PROTO
  init_top_group(void)
- #else
- init_top_group()
- #endif
  {
      /* clear the group stack */
      while (pop_group_stack() >= 0)
--- 174,180 ----
*************** init_top_group()
*** 232,253 ****
  }
  
  void
- #ifndef _NO_PROTO
  center_top_group(void)
- #else
- center_top_group()
- #endif
  {
      push_group_stack();
      gTopOfGroupStack->center = 1;
  }
  
  GroupItem *
- #ifndef _NO_PROTO
  copy_group_stack(void)
- #else
- copy_group_stack()
- #endif
  {
      GroupItem *newgp = NULL;
      GroupItem *first = NULL;
--- 188,201 ----
*************** copy_group_stack()
*** 272,283 ****
  }
  
  void
- #ifndef _NO_PROTO
  free_group_stack(GroupItem *g)
- #else
- free_group_stack(g)
- GroupItem *g;
- #endif
  {
      GroupItem *trace = g;
  
--- 220,226 ----
*** src/hyper/halloc.pamphlet	(revision 16913)
--- src/hyper/halloc.pamphlet	(local)
*************** FILE *fp;
*** 27,39 ****
  /* allocate memory and bomb if none left (HyperDoc alloc) */
  
  char *
- #ifndef _NO_PROTO
  halloc(int bytes, char *msg)
- #else
- halloc(bytes,msg)
- int bytes;
- char *msg;
- #endif
  {
      static char buf[200];
      char *result;
--- 27,33 ----
*** src/hyper/hash.pamphlet	(revision 16913)
--- src/hyper/hash.pamphlet	(local)
***************
*** 26,40 ****
  /* initialize a hash table */
  
  void
! #ifndef _NO_PROTO
! hash_init(HashTable *table, int size, EqualFunction equal, HashcodeFunction hash_code)
! #else
! hash_init(table,size,equal,hash_code)
! HashTable *table;
! int size;
! EqualFunction equal;
! HashcodeFunction hash_code;
! #endif
  {
      int i;
  
--- 26,33 ----
  /* initialize a hash table */
  
  void
! hash_init(HashTable *table, int size, EqualFunction equal,
!           HashcodeFunction hash_code)
  {
      int i;
  
*************** HashcodeFunction hash_code;
*** 49,61 ****
  }
  
  void
- #ifndef _NO_PROTO
  free_hash(HashTable *table, FreeFunction free_fun)
- #else
- free_hash(table,free_fun)
- HashTable *table;
- FreeFunction free_fun;
- #endif
  {
    if (table) {
      int i;
--- 42,48 ----
*************** FreeFunction free_fun;
*** 78,91 ****
  /* insert an entry into a hash table */
  
  void
- #ifndef _NO_PROTO
  hash_insert(HashTable *table, char *data, char *key)
- #else
- hash_insert(table,data,key)
- HashTable *table;
- char *data;
- char *key;
- #endif
  {
      HashEntry *entry = (HashEntry *) halloc(sizeof(HashEntry), "HashEntry");
      int code;
--- 65,71 ----
*************** char *key;
*** 102,114 ****
  }
  
  char *
- #ifndef _NO_PROTO
  hash_find(HashTable *table, char *key)
- #else
- hash_find(table,key)
- HashTable *table;
- char *key;
- #endif
  {
      HashEntry *entry;
      int code = table->hash_code(key, table->size) % table->size;
--- 82,88 ----
*************** char *key;
*** 120,133 ****
  }
  
  char *
- #ifndef _NO_PROTO
  hash_replace(HashTable *table, char *data, char *key)
- #else
- hash_replace(table,data,key)
- HashTable *table;
- char *data;
- char *key;
- #endif
  {
      HashEntry *entry;
      int code = table->hash_code(key, table->size) % table->size;
--- 94,100 ----
*************** char *key;
*** 141,153 ****
  }
  
  void
- #ifndef _NO_PROTO
  hash_delete(HashTable *table, char *key)
- #else
- hash_delete(table,key)
- HashTable *table;
- char *key;
- #endif
  {
      HashEntry **entry;
      int code = table->hash_code(key, table->size) % table->size;
--- 108,114 ----
*************** char *key;
*** 161,173 ****
  }
  
  void
- #ifndef _NO_PROTO
  hash_map(HashTable *table, MappableFunction func)
- #else
- hash_map(table,func)
- HashTable *table;
- MappableFunction func;
- #endif
  {
      int i;
      HashEntry *e;
--- 122,128 ----
*************** MappableFunction func;
*** 180,191 ****
  }
  
  HashEntry *
- #ifndef _NO_PROTO
  hash_copy_entry(HashEntry *e)
- #else
- hash_copy_entry(e)
- HashEntry *e;
- #endif
  {
      HashEntry *ne;
  
--- 135,141 ----
*************** HashEntry *e;
*** 200,211 ****
  
  /* copy a hash table */
  HashTable *
- #ifndef _NO_PROTO
  hash_copy_table(HashTable *table)
- #else
- hash_copy_table(table)
- HashTable *table;
- #endif
  {
      HashTable *nt = (HashTable *) halloc(sizeof(HashTable), "copy hash table");
      int i;
--- 150,156 ----
*************** HashTable *table;
*** 223,235 ****
  
  /* hash code function for strings */
  int
- #ifndef _NO_PROTO
  string_hash(char *s, int size)
- #else
- string_hash(s,size)
- char *s;
- int size;
- #endif
  {
      int c = 0;
      char *p =s;
--- 168,174 ----
*************** int size;
*** 243,266 ****
  /* test strings for equality */
  
  int
- #ifndef _NO_PROTO
  string_equal(char *s1, char *s2)
- #else
- string_equal(s1,s2)
- char *s1,*s2;
- #endif
  {
      return (strcmp(s1, s2) == 0);
  }
  
  /* make a fresh copy of the given string */
  char *
- #ifndef _NO_PROTO
  alloc_string(char *str)
- #else
- alloc_string(str)
- char *str;
- #endif
  {
      char * result;
      result = halloc(strlen(str)+1,"String");
--- 182,195 ----
*** src/hyper/htadd.pamphlet	(revision 16913)
--- src/hyper/htadd.pamphlet	(local)
*************** int fresh = 0;
*** 82,94 ****
  
  
  int
- #ifndef _NO_PROTO
  main(int argc, char **argv)
- #else
- main(argc,argv)
- int argc;
- char **argv;
- #endif
  {
      /*int i;*/
      char db_dir[256];           /* the directory where the db file is */
--- 82,88 ----
*************** char **argv;
*** 128,142 ****
  
  
  static void
- #ifndef _NO_PROTO
  parse_args(char **argv, char *db_dir, char **filenames, short *fl)
- #else
- parse_args(argv,db_dir, filenames,fl)
- char **argv;
- char *db_dir;
- char **filenames;
- short *fl;
- #endif
  {
      *fl = 0;
  
--- 122,128 ----
*************** short *fl;
*** 178,189 ****
  
  
  static int
- #ifndef _NO_PROTO
  writable(struct stat buff)
- #else
- writable(buff)
- struct stat buff;
- #endif
  {
  #ifdef DEBUG
      unsigned short uid = geteuid(), gid = getegid();
--- 164,170 ----
*************** struct stat buff;
*** 212,225 ****
  
  
  static int
- #ifndef _NO_PROTO
  build_db_filename(short flag, char *db_dir, char *dbfilename)
- #else
- build_db_filename(flag, db_dir,dbfilename)
- short flag;
- char *db_dir;
- char *dbfilename;
- #endif
  {
      int ret_status;
      struct stat buff;
--- 193,199 ----
*************** char *dbfilename;
*** 286,299 ****
  ****/
  
  static void
- #ifndef _NO_PROTO
  add_file(char *dbname, char *name, int fresh)
- #else
- add_file(dbname, name, fresh)
- char *dbname;
- char *name;
- int fresh;
- #endif
  {
      char fullname[256];
      char temp_db_file[256];
--- 260,266 ----
*************** int fresh;
*** 341,358 ****
  }
  
  static void
- #ifndef _NO_PROTO
  update_db(FILE *db, FILE *temp_db, FILE *new_file,
            char *addname, char *fullname, int fresh)
- #else
- update_db(db,temp_db,new_file,addname,fullname, fresh)
- FILE *db;
- FILE *temp_db;
- FILE *new_file;
- char *addname;
- char *fullname;
- int fresh;
- #endif
  {
      char *fname;
      int c, file_there = 0, mtime;
--- 308,315 ----
*************** int fresh;
*** 406,420 ****
  #define ptype(c, t) (strcpy(c, t));
  
  static void
- #ifndef _NO_PROTO
  add_new_pages(FILE *temp_db, FILE *new_file, char *addname, char *fullname)
- #else
- add_new_pages(temp_db,new_file,addname,fullname)
- FILE *temp_db;
- FILE *new_file;
- char *addname;
- char *fullname;
- #endif
  {
      char type[15];
      int pos;
--- 363,369 ----
*************** char *fullname;
*** 464,475 ****
  }
  
  static void
- #ifndef _NO_PROTO
  copy_file(char *f1, char *f2)
- #else
- copy_file(f1, f2)
- char *f1,*f2;
- #endif
  {
      FILE *fp1, *fp2;
      int c;
--- 413,419 ----
*************** char *f1,*f2;
*** 491,501 ****
  
  
  static void
- #ifdef _NO_PROTO
- get_filename()
- #else
  get_filename(void)
- #endif
  {
      int c, ws;
      static char buffer[256];
--- 435,441 ----
*************** get_filename(void)
*** 529,540 ****
  }
  
  static int
- #ifndef _NO_PROTO
  delete_file(char *dbname, char *name)
- #else
- delete_file(dbname,name)
- char *dbname,*name;
- #endif
  {
      char temp_db_file[256];
      FILE *db_fp, *temp_db_fp;
--- 469,475 ----
*************** char *dbname,*name;
*** 564,577 ****
  }
  
  static void
- #ifndef _NO_PROTO
  delete_db(FILE *db, FILE *temp_db, char *name)
- #else
- delete_db(db,temp_db,name)
- FILE *db;
- FILE *temp_db; 
- char *name;
- #endif
  {
      char *fname;
      int c/*, file_there = 0*/, mtime;
--- 499,505 ----
*** src/hyper/hterror.pamphlet	(revision 16913)
--- src/hyper/hterror.pamphlet	(local)
*************** jmp_buf jmpbuf;
*** 50,61 ****
   */
  
  void
- #ifndef _NO_PROTO
  jump(void)
- #else
- jump()
- #endif
- 
  {
      if (gWindow == NULL)
          exit(-1);
--- 50,56 ----
*************** jump()
*** 65,75 ****
  }
  
  void
- #ifndef _NO_PROTO
  print_page_and_filename(void)
- #else
- print_page_and_filename()
- #endif
  {
      char obuff[128];
  
--- 60,66 ----
*************** print_page_and_filename()
*** 100,110 ****
  
  
  void
- #ifndef _NO_PROTO
  print_next_ten_tokens(void)
- #else
- print_next_ten_tokens()
- #endif
  {
      int i;
      int v;
--- 91,97 ----
*************** print_next_ten_tokens()
*** 121,131 ****
  
  /* print out a token value */
  void
- #ifndef _NO_PROTO
  print_token(void)
- #else
- print_token()
- #endif
  {
      if (token.type == Word)
          printf("%s ", token.id);
--- 108,114 ----
*************** print_token()
*** 138,149 ****
  
  
  void
- #ifndef _NO_PROTO
  token_name(int type)
- #else
- token_name(type)
-     int type;
- #endif
  {
      if (type <= NumberUserTokens)
          strcpy(ebuffer, token_table[type]);
--- 121,127 ----
*************** token_name(type)
*** 216,228 ****
      }
  }
  void
- #ifndef _NO_PROTO
  htperror(char *msg, int errno)
- #else
- htperror(msg, errno)
-     char *msg;
-     int errno;
- #endif
  {
      char obuff[256];
  
--- 194,200 ----
*** src/hyper/hthits.pamphlet	(revision 16913)
--- src/hyper/hthits.pamphlet	(local)
*************** int gverifydates=0;
*** 83,95 ****
  regex_t reg_pattern;
  
  int
- #ifdef _NO_PROTO
- main(argc, argv)
-     int argc;
-     char **argv;
- #else
  main(int argc,char ** argv)
- #endif
  {
      cmdline(argc, argv);
  
--- 83,89 ----
*************** main(int argc,char ** argv)
*** 100,112 ****
  }
  
  void
- #ifdef _NO_PROTO
- cmdline(argc, argv)
-     int argc;
-     char **argv;
- #else
  cmdline(int argc,char ** argv)
- #endif
  {
      progName = argv[0];
  
--- 94,100 ----
*************** cmdline(int argc,char ** argv)
*** 120,130 ****
  }
  
  void
- #ifdef _NO_PROTO
- handleHtdb()
- #else
  handleHtdb(void)
- #endif
  {
      FILE *htdbFile;
      int c;
--- 108,114 ----
*************** handleHtdb(void)
*** 145,156 ****
  
  
  void
- #ifdef _NO_PROTO
- handleFile(htdbFile)
-     FILE *htdbFile;
- #else
  handleFile(FILE *htdbFile)
- #endif
  {
      static PgInfo *pgInfoV = 0;
      static int pgInfoC = 0;
--- 129,135 ----
*************** handleFile(FILE *htdbFile)
*** 256,269 ****
  }
  
  void
- #ifdef _NO_PROTO
- handleFilePages(fname, pgc, pgv)
-     char *fname;
-     int pgc;
-     PgInfo *pgv;
- #else
  handleFilePages(char *fname, int pgc, PgInfo *pgv)
- #endif
  {
      FILE *infile;
      int i;
--- 235,241 ----
*************** handleFilePages(char *fname, int pgc, Pg
*** 283,295 ****
  }
  
  void
- #ifdef _NO_PROTO
- handlePage(infile, pg)
-     FILE *infile;
-     PgInfo *pg;
- #else
  handlePage(FILE *infile,PgInfo * pg)
- #endif
  {
      static char *pgBuf = 0;
      static int pgBufSize = 0;
--- 255,261 ----
*************** handlePage(FILE *infile,PgInfo * pg)
*** 327,338 ****
  }
  
  void 
- #ifdef _NO_PROTO
- searchPage(pgname, pgtitle, pgbody)
-     char *pgname, *pgtitle, *pgbody;
- #else
  searchPage(char *pgname,char * pgtitle,char * pgbody)
- #endif
  {
      char *bodyrest;
      regmatch_t match_pos;
--- 293,299 ----
*************** searchPage(char *pgname,char * pgtitle,c
*** 360,372 ****
   */
  
  void 
- #ifdef _NO_PROTO
- squirt(s, n)
-     char *s;
-     int n;
- #else
  squirt(char *s, int n)
- #endif
  {
      register char *t, *e;
      int c;
--- 321,327 ----
*************** squirt(char *s, int n)
*** 388,401 ****
   * Any newlines and separator characters in the title are changed to blanks.
   */
  void 
- #ifdef _NO_PROTO
- splitpage(buf, ptitle, pbody)
-     char *buf;
-     char **ptitle;              /* output: Title of page */
-     char **pbody;               /* output: Body of page  */
- #else
  splitpage(char *buf, char **ptitle, char **pbody)
- #endif
  {
      int n, depth, tno;
      char *s;
--- 343,349 ----
*************** splitpage(char *buf, char **ptitle, char
*** 430,441 ****
  
  
  void 
- #ifdef _NO_PROTO
- untexbuf(s)
-     register char *s;
- #else
  untexbuf(register char *s)
- #endif
  {
      register char *d = s;
  
--- 378,384 ----
*************** untexbuf(register char *s)
*** 467,489 ****
  }
  
  void 
- #ifdef _NO_PROTO
- badDB()
- #else
  badDB(void)
- #endif
  {
      fprintf(stderr, "%s:  bad database file %s\n", progName, htdbFName);
      exit(1);
  }
  
  void
- #ifdef _NO_PROTO
- regerr(code)
-     int code;
- #else
  regerr(int code)
- #endif
  {
      fprintf(stderr, "%s: regular expression error %d for \"%s\"\n",
              progName, code, pattern);
--- 410,423 ----
*** src/hyper/htinp.pamphlet	(revision 16913)
--- src/hyper/htinp.pamphlet	(local)
*************** char buf_for_record_commands[256];
*** 47,57 ****
  
  
  void
- #ifndef _NO_PROTO
  make_record(void)
- #else
- make_record()
- #endif
  {
    int i;
    for (i=0;i<input_file_count;i++){
--- 47,53 ----
*************** make_record()
*** 72,82 ****
  }
  
  void
- #ifndef _NO_PROTO
  verify_record(void)
- #else
- verify_record()
- #endif
  {
    int i;
    for (i=0;i<input_file_count;i++){
--- 68,74 ----
*************** verify_record()
*** 97,107 ****
  
  
  void
- #ifndef _NO_PROTO
  ht2_input(void)
- #else
- ht2_input()
- #endif
  {
    HashTable *table;
    HashEntry *entry;
--- 89,95 ----
*************** ht2_input()
*** 123,134 ****
  }
  
  static char *
- #ifndef _NO_PROTO
  make_input_file_name(char *buf, char *filename)
- #else
- make_input_file_name(buf, filename)
- char *buf, *filename;
- #endif
  {
      char *b, *c;
  
--- 111,117 ----
*************** char *buf, *filename;
*** 142,153 ****
  }
  
  static char *
- #ifndef _NO_PROTO
  make_paste_file_name(char *buf, char *filename)
- #else
- make_paste_file_name(buf, filename)
- char *buf, *filename;
- #endif
  {
      char *b, *c;
  
--- 125,131 ----
*************** char *buf, *filename;
*** 161,172 ****
  }
  
  static void
- #ifndef _NO_PROTO
  make_the_input_file(UnloadedPage *page)
- #else
- make_the_input_file(page)
- UnloadedPage *page;
- #endif
  {
      char buf[1024], *b;
  
--- 139,145 ----
*************** UnloadedPage *page;
*** 188,199 ****
  int example_number;
  
  static void
- #ifndef _NO_PROTO
  make_input_file_from_page(HyperDocPage *page)
- #else
- make_input_file_from_page(page)
- HyperDocPage *page;
- #endif
  {
    TextNode *node;
    int starting_file = 1,/* i,*/ /*len,*/ ret_val;
--- 161,167 ----
*************** HyperDocPage *page;
*** 276,287 ****
  }
  
  char *
- #ifndef _NO_PROTO
  strCopy(char *s)
- #else
- strCopy(s)
- char *s;
- #endif
  {
      char *b = halloc(strlen(s) + 1,"String");
  
--- 244,250 ----
*************** char *s;
*** 290,301 ****
  }
  
  static int
- #ifndef _NO_PROTO
  inListAndNewer(char *inputFile, char *htFile)
- #else
- inListAndNewer(inputFile, htFile)
- char *htFile, *inputFile;
- #endif
  {
      int ret_val, found = 0, i;
      struct stat htBuf, inputBuf;
--- 253,259 ----
*************** char *htFile, *inputFile;
*** 350,360 ****
  }
  
  static void
- #ifndef _NO_PROTO
  make_input_file_list(void)
- #else
- make_input_file_list()
- #endif
  {
      int i;
      char buf[256], *name;
--- 308,314 ----
*************** make_input_file_list()
*** 367,379 ****
  }
  
  void
- #ifndef _NO_PROTO
  print_paste_line(FILE *pfile,char *str)
- #else
- print_paste_line(pfile, str)
- FILE *pfile;
- char *str;
- #endif
  {
      char *free = "\\free", *bound = "\\bound", *f = free, *b = bound;
      int justSaw = 0;
--- 321,327 ----
*************** char *str;
*** 406,419 ****
  
  
  void
- #ifndef _NO_PROTO
  get_spad_output(FILE *pfile,char *command,int com_type)
- #else
- get_spad_output(pfile, command, com_type)
- FILE *pfile;
- char *command;
- int com_type;
- #endif
  {
      int n, i;
      char buf[1024];
--- 354,360 ----
*************** int com_type;
*** 435,447 ****
   * health of the viewport. We do this after the (|close|).
   */
  void
- #ifndef _NO_PROTO
  get_graph_output(char *command,char *pagename,int com_type)
- #else
- get_graph_output(command, pagename, com_type)
- char *command, *pagename;
- int com_type;
- #endif
  {
      int n, i;
      char buf[1024];
--- 376,382 ----
*************** int com_type;
*** 461,473 ****
      get_int(spad_socket);
  }
  static void
- #ifndef _NO_PROTO
  send_command(char *command,int com_type)
- #else
- send_command(command, com_type)
- char *command;
- int com_type;
- #endif
  {
      char buf[1024];
  
--- 396,402 ----
*************** int com_type;
*** 494,507 ****
  }
  
  static void
- #ifndef _NO_PROTO
  print_paste(FILE *pfile,char *realcom,char *command,char *pagename,int com_type)
- #else
- print_paste(pfile, realcom, command, pagename, com_type)
- FILE *pfile;
- char *realcom, *command, *pagename;
- int com_type;
- #endif
  {
      fprintf(pfile, "\\begin{patch}{%sPatch%d}\n", pagename, example_number);
      fprintf(pfile, "\\begin{paste}{%sFull%d}{%sEmpty%d}\n",
--- 423,429 ----
*************** int com_type;
*** 528,541 ****
      fflush(pfile);
  }
  static void
- #ifndef _NO_PROTO
  print_graph_paste(FILE *pfile,char *realcom,char *command,char *pagename,int com_type)
- #else
- print_graph_paste(pfile, realcom, command, pagename, com_type)
- FILE *pfile;
- char *realcom, *command, *pagename;
- int com_type;
- #endif
  {
      fprintf(pfile, "\\begin{patch}{%sPatch%d}\n", pagename, example_number);
      fprintf(pfile, "\\begin{paste}{%sFull%d}{%sEmpty%d}\n",
--- 450,456 ----
*** src/hyper/hyper.pamphlet	(revision 16913)
--- src/hyper/hyper.pamphlet	(local)
*************** int input_file_count;
*** 690,713 ****
   */
  
  void 
- #ifdef _NO_PROTO
- sigusr2_handler(sig)
-      int sig;
- #else
  sigusr2_handler(int sig)
- #endif
  {
    gIsEndOfOutput = 1;
    return ;
  }
  
  void
- #ifdef _NO_PROTO
- sigcld_handler(sig)
-      int sig;
- #else
  sigcld_handler(int sig)
- #endif
  {
  
      /* why were we waiting after the child had already died ?? 
--- 690,703 ----
*************** extern jmp_buf env;
*** 723,733 ****
  
  /* Clean up spad sockets on exit */
  void
- #ifdef _NO_PROTO
- clean_socket()
- #else
  clean_socket(void )
- #endif
  {
      char name[256];
  
--- 713,719 ----
*************** clean_socket(void )
*** 741,753 ****
   */
  
  int
- #ifndef _NO_PROTO
  main(int argc, char **argv)
- #else
- main(argc,argv)
- int argc;
- char **argv;
- #endif
  {
      int ret_status;
  
--- 727,733 ----
*************** char **argv;
*** 873,883 ****
   */
  
  static void
- #ifdef _NO_PROTO
- init_hash()
- #else
  init_hash(void)
- #endif
  {
      hash_init(&gFileHashTable, 
  	      FileHashSize,
--- 853,859 ----
*************** init_hash(void)
*** 896,907 ****
  /* initialize the HyperDoc page hierarchy data structures */
  
  void
- #ifndef _NO_PROTO
  init_page_structs(HDWindow *w)
- #else
- init_page_structs(w)
- HDWindow *w;
- #endif
  {
      int i;
  
--- 872,878 ----
*************** HDWindow *w;
*** 916,926 ****
  }
  
  static void
- #ifdef _NO_PROTO
- check_arguments()
- #else
  check_arguments(void)
- #endif
  {
    int i;
    
--- 887,893 ----
*************** check_arguments(void)
*** 970,980 ****
  }
  
  static void
- #ifdef _NO_PROTO
- make_server_connections()
- #else
  make_server_connections(void)
- #endif
  {
      int i, wait_time;
  
--- 937,943 ----
*** src/hyper/initx.pamphlet	(revision 16913)
--- src/hyper/initx.pamphlet	(local)
*************** int gBorderColor;     /* The Border Colo
*** 111,121 ****
  /* Initialize the X Window System  */
  
  void
- #ifdef _NO_PROTO
- initializeWindowSystem()
- #else
  initializeWindowSystem(void)
- #endif
  {
      char *display_name = NULL;
      XColor fg, bg;
--- 111,117 ----
*************** initializeWindowSystem(void)
*** 205,216 ****
   */
  
  int
- #ifndef _NO_PROTO
  init_top_window(char *name)
- #else
- init_top_window(name)
- char *name;
- #endif
  {
      HyperDocPage *page;
      XSetWindowAttributes wa;    /* The X attributes structure */
--- 201,207 ----
*************** char *name;
*** 260,270 ****
  /* Create and initialize a form HyperDoc window */
  
  static void
- #ifdef _NO_PROTO
- open_form_window()
- #else
  open_form_window(void)
- #endif
  {
      int x, y, width, height;
      unsigned int fwidth = 0, fheight = 0;
--- 251,257 ----
*************** open_form_window(void)
*** 336,348 ****
  
  
  int
- #ifndef _NO_PROTO
  init_form_window(char *name, int cols)
- #else
- init_form_window(name,cols)
- char *name;
- int cols;
- #endif
  {
      XSetWindowAttributes wa;    /* The X attributes structure */
  
--- 323,329 ----
*************** int cols;
*** 376,386 ****
  
  
  static void
- #ifdef _NO_PROTO
- set_name_and_icon()
- #else
  set_name_and_icon(void)
- #endif
  {
      char *icon_name = "HyperDoc";
      char *s;
--- 357,363 ----
*************** set_name_and_icon(void)
*** 413,423 ****
  }
  
  static int
- #ifdef _NO_PROTO
- get_border_properties()
- #else
  get_border_properties(void)
- #endif
  {
      char *bwidth;
      /*char *bc = NULL;*/
--- 390,396 ----
*************** get_border_properties(void)
*** 456,467 ****
  /* Create and initialize the HyperDoc window */
  
  static void
- #ifndef _NO_PROTO
  open_window(Window w)
- #else
- open_window(w)
- Window w;
- #endif
  {
      int x = 0, y = 0;
      /*int border_width = 2;*/
--- 429,435 ----
*************** Window w;
*** 521,532 ****
    ***/
  
  static void
- #ifndef _NO_PROTO
  set_size_hints(Window w)
- #else
- set_size_hints(w)
- Window w;
- #endif
  {
      int x, y;
      unsigned int width, height;
--- 489,495 ----
*************** Pixmap stipple;
*** 618,629 ****
  /* Create the graphics contexts to be used for all drawing operations */
  
  static void
- #ifndef _NO_PROTO
  get_GCs(HDWindow *window)
- #else
- get_GCs(window)
- HDWindow *window;
- #endif
  {
      /*unsigned long valuemask = 0;*/
      XGCValues values;
--- 581,587 ----
*************** HDWindow *window;
*** 670,682 ****
  /* Load a font and store the information in the font_info parameter */
  
  static void
- #ifndef _NO_PROTO
  load_font(XFontStruct **font_info, char *fontname)
- #else
- load_font(font_info,fontname)
- XFontStruct **font_info;
- char *fontname;
- #endif
  {
     if ((*font_info = XLoadQueryFont(gXDisplay, fontname)) == NULL) {
          fprintf(stderr, "(HyperDoc) Cannot load font %s ; using default.\n",
--- 628,634 ----
*************** char *fontname;
*** 708,718 ****
   */
  
  static void
- #ifdef _NO_PROTO
- ingItColors_and_fonts()
- #else
  ingItColors_and_fonts(void)
- #endif
  {
      char property[256];
      char *prop = &property[0];
--- 660,666 ----
*************** ingItColors_and_fonts(void)
*** 911,924 ****
  }
  
  void
- #ifndef _NO_PROTO
  change_text(int color, XFontStruct *font)
- #else
- change_text(color,font)
- int color;
- XFontStruct *font;
- #endif
- 
  {
      if (font) {
          XGCValues gcv;
--- 859,865 ----
*************** XFontStruct *font;
*** 940,954 ****
   */
  
  static int
- #ifndef _NO_PROTO
  get_color(char *name, char *class, int def, Colormap *map)
- #else
- get_color(name,class,def,map)
- char *name;
- char *class;
- int def;
- Colormap *map;
- #endif
  {
      char fullname[256];
      char fullclass[256];
--- 881,887 ----
*************** Colormap *map;
*** 997,1007 ****
  
  
  static void
- #ifdef _NO_PROTO
- mergeDatabases()
- #else
  mergeDatabases(void)
- #endif
  {
      XrmDatabase homeDB, serverDB, applicationDB;
      char filenamebuf[1024];
--- 930,936 ----
*************** mergeDatabases(void)
*** 1051,1062 ****
  
  
  int 
- #ifdef _NO_PROTO
- is_it_850(fontarg)
- 	XFontStruct *fontarg;
- #else
  is_it_850(XFontStruct *fontarg)
- #endif
  {
   char *s;
   int i,val;
--- 980,986 ----
*** src/hyper/input.pamphlet	(revision 16913)
--- src/hyper/input.pamphlet	(local)
***************
*** 23,35 ****
  
  
  void
- #ifndef _NO_PROTO
  fill_box(Window w,ImageStruct * image)
- #else
- fill_box(w, image)
-     Window w;
-     ImageStruct *image;
- #endif
  {
      XClearWindow(gXDisplay, w);
      XPutImage(gXDisplay, w, gWindow->fControlGC,
--- 23,29 ----
*************** fill_box(w, image)
*** 39,50 ****
  }
  
  void
- #ifndef _NO_PROTO
  toggle_input_box(HyperLink *link)
- #else
- toggle_input_box(link)
-     HyperLink *link;
- #endif
  {
      InputBox *box;
  
--- 33,39 ----
*************** toggle_input_box(link)
*** 61,72 ****
  
  }
  void
- #ifndef _NO_PROTO
  toggle_radio_box(HyperLink *link)
- #else
- toggle_radio_box(link)
-     HyperLink *link;
- #endif
  {
      InputBox *box;
  
--- 50,56 ----
*************** toggle_radio_box(link)
*** 87,98 ****
  }
  
  static void
- #ifndef _NO_PROTO
  clear_rbs(InputBox *list)
- #else
- clear_rbs(list)
-     InputBox *list;
- #endif
  {
      InputBox *trace = list;
  
--- 71,77 ----
*************** clear_rbs(list)
*** 105,116 ****
      }
  }
  void
- #ifndef _NO_PROTO
  change_input_focus(HyperLink *link)
- #else
- change_input_focus(link)
-     HyperLink *link;
- #endif
  {
      InputItem *new_item = link->reference.string;
      InputItem *old_item = gWindow->page->current_item;
--- 84,90 ----
*************** change_input_focus(link)
*** 138,148 ****
      update_inputsymbol(new_item);
  }
  void
- #ifdef _NO_PROTO
- next_input_focus()
- #else
  next_input_focus(void)
- #endif
  {
      InputItem *old_item = gWindow->page->current_item, *new_item, *trace;
  
--- 112,118 ----
*************** next_input_focus(void)
*** 169,179 ****
      draw_inputsymbol(new_item);
  }
  void
- #ifdef _NO_PROTO
- prev_input_focus()
- #else
  prev_input_focus(void)
- #endif
  {
      InputItem *old_item = gWindow->page->current_item, *new_item, *trace;
  
--- 139,145 ----
*************** prev_input_focus(void)
*** 211,222 ****
  }
  
  InputItem *
- #ifndef _NO_PROTO
  return_item(char *name)
- #else
- return_item(name)
-     char *name;
- #endif
  {
      InputItem *list;
  
--- 177,183 ----
*************** return_item(name)
*** 229,240 ****
      return NULL;
  }
  int
- #ifndef _NO_PROTO
  delete_item(char *name)
- #else
- delete_item(name)
-     char *name;
- #endif
  {
      InputItem *list;
      InputItem *prev = NULL;
--- 190,196 ----
*** src/hyper/item.pamphlet	(revision 16913)
--- src/hyper/item.pamphlet	(local)
*************** ItemStack *gTopOfItemStack = NULL;
*** 25,35 ****
  
  
  void
- #ifdef _NO_PROTO
- push_item_stack()
- #else
  push_item_stack(void)
- #endif
  {
      ItemStack *is = (ItemStack *) halloc(sizeof(ItemStack), "Item stack");
  
--- 25,31 ----
*************** push_item_stack(void)
*** 41,51 ****
      return;
  }
  void
- #ifdef _NO_PROTO
- clear_item_stack()
- #else
  clear_item_stack(void)
- #endif
  {
      ItemStack *is = gTopOfItemStack, *chuck;
  
--- 37,43 ----
*************** clear_item_stack(void)
*** 57,67 ****
      return;
  }
  void
- #ifdef _NO_PROTO
- pop_item_stack()
- #else
  pop_item_stack(void)
- #endif
  {
      ItemStack *chuck;
  
--- 49,55 ----
*************** pop_item_stack(void)
*** 78,88 ****
  }
  
  ItemStack *
- #ifdef _NO_PROTO
- copy_item_stack()
- #else
  copy_item_stack(void)
- #endif
  {
      ItemStack *new = NULL;
      ItemStack *prev = NULL;
--- 66,72 ----
*************** copy_item_stack(void)
*** 107,118 ****
  }
  
  void
- #ifdef _NO_PROTO
- free_item_stack(is)
-     ItemStack *is;
- #else
  free_item_stack(ItemStack *is)
- #endif
  {
      ItemStack *junk = NULL;
      ItemStack *trace = is;
--- 91,97 ----
*** src/hyper/keyin.pamphlet	(revision 16913)
--- src/hyper/keyin.pamphlet	(local)
*************** static char *protected_quit;
*** 93,104 ****
  HyperLink *quitLink;            /** the global link to the quit page ***/
  
  void
- #ifndef _NO_PROTO
  handle_key(XEvent *event)
- #else
- handle_key(event)
- XEvent *event;
- #endif
  {
    char key_buffer[20];
    int key_buffer_size = 20;
--- 93,99 ----
*************** XEvent *event;
*** 246,256 ****
   */
  
  void
- #ifdef _NO_PROTO
- init_keyin()
- #else
  init_keyin(void)
- #endif
  {
      char *prop;
  
--- 241,247 ----
*** src/hyper/lex.pamphlet	(revision 16913)
--- src/hyper/lex.pamphlet	(local)
*************** dumpToken("fnname",token)
*** 20,32 ****
  There is no return value.
  <<dumptoken function>>=
  void
- #ifndef _NO_PROTO
- dumpToken(caller,t)
- char *caller;
- Token t;
- #else
  dumpToken(char *caller, Token t)
- #endif
  { fprintf(stderr,"%s:dumpToken type=%s id=%s\n",
      caller,token_table[t.type],t.id);
  }
--- 20,26 ----
*************** static HashTable tokenHashTable;        
*** 128,138 ****
  
  /* initialize the parser keyword hash table */
  void
- #ifdef _NO_PROTO
- parser_init()
- #else
  parser_init(void)
- #endif
  {
      int i;
      Token *toke;
--- 122,128 ----
*************** parser_init(void)
*** 155,165 ****
  
  /* initialize the lexical scanner to read from a file */
  void
- #ifdef _NO_PROTO
- init_scanner()
- #else
  init_scanner(void)
- #endif
  {
      if (getenv("HTASCII")) {
          useAscii = (strcmp(getenv("HTASCII"), "yes") == 0);
--- 145,151 ----
*************** init_scanner(void)
*** 185,195 ****
  
  /* save the current state of the scanner */
  void
- #ifdef _NO_PROTO
- save_scanner_state()
- #else
  save_scanner_state(void)
- #endif
  {
      StateNode *new_item = (StateNode *) halloc((sizeof(StateNode)), "StateNode");
  
--- 171,177 ----
*************** save_scanner_state(void)
*** 209,219 ****
  
  /* restore the saved scanner state */
  void
- #ifdef _NO_PROTO
- restore_scanner_state()
- #else
  restore_scanner_state(void)
- #endif
  {
      StateNode *x = top_state_node;
  
--- 191,197 ----
*************** restore_scanner_state(void)
*** 240,251 ****
  
  /* return the character to the input stream. */
  void
- #ifdef _NO_PROTO
- unget_char(c)
-     int c;
- #else
  unget_char(int c)
- #endif
  {
      if (c == '\n')
          line_number--;
--- 218,224 ----
*************** unget_char(int c)
*** 253,263 ****
  }
  
  int
- #ifdef _NO_PROTO
- get_char()
- #else
  get_char(void)
- #endif
  {
      int c;
  
--- 226,232 ----
*************** char * read_again = 0;
*** 308,318 ****
  
  /* return the next character in the input stream */
  static int
- #ifdef _NO_PROTO
- get_char1()
- #else
  get_char1(void)
- #endif
  {
      int c;
      int cmd;
--- 277,283 ----
*************** Token unget_toke;
*** 391,401 ****
  
  /* return current token to the input stream */
  void
- #ifdef _NO_PROTO
- unget_token()
- #else
  unget_token(void)
- #endif
  {
      last_token = 1;
      unget_toke.type = token.type;
--- 356,362 ----
*************** unget_token(void)
*** 404,414 ****
  
  
  int
- #ifdef _NO_PROTO
- get_token()
- #else
  get_token(void)
- #endif
  {
      int c, ws;
      int nls = 0;
--- 365,371 ----
*************** BeStruct *top_be_stack;
*** 584,596 ****
  
  
  void
- #ifdef _NO_PROTO
- push_be_stack(type, id)
-     int type;
-     char *id;
- #else
  push_be_stack(int type,char * id)
- #endif
  {
      BeStruct *be = (BeStruct *) halloc(sizeof(BeStruct), "BeginENd stack");
  
--- 541,547 ----
*************** push_be_stack(int type,char * id)
*** 603,615 ****
      return;
  }
  void
- #ifdef _NO_PROTO
- check_and_pop_be_stack(type, id)
-     int type;
-     char *id;
- #else
  check_and_pop_be_stack(int type,char * id)
- #endif
  {
      BeStruct *x;
  
--- 554,560 ----
*************** check_and_pop_be_stack(int type,char * i
*** 641,651 ****
  }
  
  int
- #ifdef _NO_PROTO
- clear_be_stack()
- #else
  clear_be_stack(void)
- #endif
  {
      BeStruct *x = top_be_stack, *y;
  
--- 586,592 ----
*************** clear_be_stack(void)
*** 659,670 ****
  }
  
  int
- #ifdef _NO_PROTO
- be_type(which)
-     char *which;
- #else
  be_type(char *which)
- #endif
  {
      Token store;
  
--- 600,606 ----
*************** be_type(char *which)
*** 735,745 ****
  
  }
  int
- #ifdef _NO_PROTO
- begin_type()
- #else
  begin_type(void)
- #endif
  {
      /*Token store;*/
      int ret_val;
--- 671,677 ----
*************** begin_type(void)
*** 775,785 ****
  
  
  int
- #ifdef _NO_PROTO
- end_type()
- #else
  end_type(void)
- #endif
  {
      int ret;
  
--- 707,713 ----
*************** end_type(void)
*** 827,837 ****
  
  
  static int
- #ifdef _NO_PROTO
- keyword_type()
- #else
  keyword_type(void)
- #endif
  {
      Token *token_ent;
  
--- 755,761 ----
*************** keyword_type(void)
*** 872,883 ****
  
  /* read a token, and report a syntax error if it has the wrong type */
  void
- #ifdef _NO_PROTO
- get_expected_token(type)
-     int type;
- #else
  get_expected_token(int type)
- #endif
  {
      get_token();
      if (token.type != type) {
--- 796,802 ----
*************** get_expected_token(int type)
*** 901,912 ****
  
  
  #ifndef HTADD
- static void
- #ifdef _NO_PROTO
- spad_error_handler()
- #else
  spad_error_handler(void)
- #endif
  {
      /* fprintf(stderr, "got a spad error\n"); */
      longjmp(jmpbuf, 1);
--- 820,826 ----
*************** spad_error_handler(void)
*** 916,926 ****
  
  extern int still_reading, str_len;
  void
- #ifdef _NO_PROTO
- reset_connection()
- #else
  reset_connection(void)
- #endif
  {
      if (spad_socket) {
          FD_CLR(spad_socket->socket, &socket_mask);
--- 830,836 ----
*************** reset_connection(void)
*** 941,951 ****
  
  /* returns true if spad is currently computing */
  int
- #ifdef _NO_PROTO
- spad_busy()
- #else
  spad_busy(void)
- #endif
  {
      if (session_server == NULL)
          return 1;
--- 851,857 ----
*************** spad_busy(void)
*** 955,965 ****
  
  /* connect to AXIOM , return 0 if succesful, 1 if not */
  int
- #ifdef _NO_PROTO
- connect_spad()
- #else
  connect_spad(void)
- #endif
  {
      if (!MenuServerOpened) {
          fprintf(stderr, "(HyperDoc) Warning: Not connected to AXIOM Server!\n");
--- 861,867 ----
*** src/hyper/macro.pamphlet	(revision 16913)
--- src/hyper/macro.pamphlet	(local)
*************** extern FILE *cfile;
*** 31,41 ****
   * right brace then left brace
   */
  void
- #ifdef _NO_PROTO
- scan_HyperDoc()
- #else
  scan_HyperDoc(void)
- #endif
  {
      HDWindow *twin = gWindow;
      int ret_val;
--- 31,37 ----
*************** scan_HyperDoc(void)
*** 70,81 ****
  }
  
  int
- #ifdef _NO_PROTO
- number(str)
-     char *str;
- #else
  number(char *str)
- #endif
  {
      char *t = str;
  
--- 66,72 ----
*************** number(char *str)
*** 88,99 ****
  /* Parse a given macro given the pointer to the unlaoded macro ** */
  
  static char *
- #ifndef _NO_PROTO
  load_macro(MacroStore *macro)
- #else
- load_macro(macro)
- MacroStore *macro;
- #endif
  {
      int ret_val;
      long start_fpos;
--- 79,85 ----
*************** MacroStore *macro;
*** 168,179 ****
  ParameterList parameters = NULL;
  
  ParameterList
- #ifdef _NO_PROTO
- init_parameter_elem(number)
-     int number;
- #else
  init_parameter_elem(int number)
- #endif
  {
      ParameterList new;
      int count;
--- 154,160 ----
*************** init_parameter_elem(int number)
*** 194,205 ****
  }
  
  int
- #ifdef _NO_PROTO
- push_parameters(new)
-     ParameterList new;
- #else
  push_parameters(ParameterList new)
- #endif
  {
  
      if (new == NULL) {
--- 175,181 ----
*************** push_parameters(ParameterList new)
*** 212,222 ****
      return 1;
  }
  int
- #ifdef _NO_PROTO
- pop_parameters()
- #else
  pop_parameters(void)
- #endif
  {
      /** Simply pops the top of the parameter list, being good and freeing
        all the memory **/
--- 188,194 ----
*************** pop_parameters(void)
*** 243,253 ****
  }
  
  int
- #ifdef _NO_PROTO
- parse_macro()
- #else
  parse_macro(void)
- #endif
  {
  
      /*
--- 215,221 ----
*************** parse_macro(void)
*** 293,305 ****
  #define numeric(c) ((c >= '0' && c <= '9')?1:0)
  
  static void
- #ifdef _NO_PROTO
- get_parameter_strings(number, macro_name)
-     int number;
-     char *macro_name;
- #else
  get_parameter_strings(int number,char * macro_name)
- #endif
  {
      static char buffer[4096];
      char *buffer_pntr;
--- 261,267 ----
*************** get_parameter_strings(int number,char * 
*** 385,395 ****
      return ;
  }
  void
- #ifdef _NO_PROTO
- parse_parameters()
- #else
  parse_parameters(void)
- #endif
  {
      int value;
  
--- 347,353 ----
*** src/hyper/mem.pamphlet	(revision 16913)
--- src/hyper/mem.pamphlet	(local)
*************** extern HashTable init_patch_hash;
*** 50,61 ****
  
  
  static void
- #ifndef _NO_PROTO
  free_if_non_NULL(void *p)
- #else
- free_if_non_NULL(p)
- void *p;
- #endif
  {
    if (p){
      free(p);
--- 50,56 ----
*************** void *p;
*** 66,76 ****
  /* allocate an HDWindow Structure and initialize it */
  
  HDWindow *
- #ifdef _NO_PROTO
- alloc_hd_window()
- #else
  alloc_hd_window(void)
- #endif
  {
    HDWindow *w = (HDWindow *) halloc(sizeof(HDWindow), "HDWindow");
    /*char haslisp[10];*/
--- 61,67 ----
*************** alloc_hd_window(void)
*** 110,121 ****
  }
  
  void
- #ifndef _NO_PROTO
  free_hd_window(HDWindow *w)
- #else
- free_hd_window(w)
- HDWindow *w;
- #endif
  {
    if (w) {
      free(w->fMemoStack);
--- 101,107 ----
*************** HDWindow *w;
*** 147,157 ****
  /* Allocate an empty text node */
  
  TextNode *
- #ifdef _NO_PROTO
- alloc_node()
- #else
  alloc_node(void)
- #endif
  {
    TextNode *temp_node;
  
--- 133,139 ----
*************** alloc_node(void)
*** 170,182 ****
  }
  
  void
- #ifndef _NO_PROTO
  free_node(TextNode *node, short int des)
- #else
- free_node(node,des)
-      TextNode *node;
-      short int des;
- #endif
  {
  
    if (node == NULL)
--- 152,158 ----
*************** free_node(node,des)
*** 350,360 ****
  }
  
  IfNode *
- #ifdef _NO_PROTO
- alloc_ifnode()
- #else
  alloc_ifnode(void)
- #endif
  {
    IfNode *tempif;
  
--- 326,332 ----
*************** alloc_ifnode(void)
*** 364,374 ****
  }
  
  CondNode *
- #ifdef _NO_PROTO
- alloc_condnode()
- #else
  alloc_condnode(void)
- #endif
  {
    CondNode *temp;
  
--- 336,342 ----
*************** alloc_condnode(void)
*** 378,389 ****
  }
  
  static void
- #ifndef _NO_PROTO
  free_cond(CondNode *cond)
- #else
- free_cond(cond)
- CondNode *cond;
- #endif
  {
    if (cond) {
      free(cond->label);
--- 346,352 ----
*************** CondNode *cond;
*** 396,407 ****
  /* Allocate a new HyperDoc page */
  
  HyperDocPage *
- #ifndef _NO_PROTO
  alloc_page(char *name)
- #else
- alloc_page(name)
- char *name;
- #endif
  {
    HyperDocPage *page;
  
--- 359,365 ----
*************** char *name;
*** 423,434 ****
  }
  
  void
- #ifndef _NO_PROTO
  free_page(HyperDocPage *page)
- #else
- free_page(page)
- HyperDocPage *page;
- #endif
  {
    /*
     * This routine now checks for an environment variable NOFREE. If found
--- 381,387 ----
*************** HyperDocPage *page;
*** 484,496 ****
  }
  
  static void
- #ifndef _NO_PROTO
  free_paste(PasteNode *paste, short int des)
- #else
- free_paste(paste,des)
- PasteNode *paste;
- short int des;
- #endif
  {
    if (paste) {
      free_group_stack(paste->group);
--- 437,443 ----
*************** short int des;
*** 501,513 ****
  }
  
  static void
- #ifndef _NO_PROTO
  free_pastebutton(TextNode *node, short int des)
- #else
- free_pastebutton(node,des)
- TextNode *node;
- short int des;
- #endif
  {
    /*
     * if I am freeing from within parse patch, then I have to do some
--- 448,454 ----
*************** short int des;
*** 543,555 ****
  }
  
  static void
- #ifndef _NO_PROTO
  free_pastearea(TextNode *node, short int des)
- #else
- free_pastearea(node,des)
- TextNode *node;
- short int des;
- #endif
  {
    if (des) {
      PasteNode *paste;
--- 484,490 ----
*************** short int des;
*** 570,603 ****
  
  
  void
- #ifndef _NO_PROTO
  free_string(char *str)
- #else
- free_string(str)
- char * str;
- #endif
  {
    free_if_non_NULL(str);
  }
  
  static void
- #ifndef _NO_PROTO
  free_depend(SpadcomDepend *sd)
- #else
- free_depend(sd)
- SpadcomDepend *sd;
- #endif
  {
    free_if_non_NULL((char *) sd);
  }
  
  static void
- #ifndef _NO_PROTO
  dont_free(void  *link)
- #else
- dont_free(link)
- void  *link;
- #endif
  {
    return;
  }
--- 505,523 ----
*************** void  *link;
*** 605,616 ****
  #if 0 
  ----------- NOT USED
  static void
- #ifndef _NO_PROTO
  free_link(HyperLink *link)
- #else
- free_link(link)
- HyperLink *link;
- #endif
  {
    printf("Link type %d\n",link->type);
    free_if_non_NULL((char *) link);
--- 525,531 ----
*************** HyperLink *link;
*** 619,630 ****
  #endif
  
  static void
- #ifndef _NO_PROTO
  free_lines(LineStruct *lines)
- #else
- free_lines(lines)
- LineStruct *lines;
- #endif
  {
    if (lines->prev != NULL)
      lines->prev->next = NULL;
--- 534,540 ----
*************** LineStruct *lines;
*** 638,650 ****
  }
  
  void
- #ifndef _NO_PROTO
  free_input_item(InputItem *sym, short int des)
- #else
- free_input_item(sym,des)
- InputItem *sym;
- short int des;
- #endif
  {
    free_if_non_NULL(sym->name);
    free_lines(sym->lines);
--- 548,554 ----
*************** short int des;
*** 653,664 ****
  }
  
  void
- #ifndef _NO_PROTO
  free_input_list(InputItem *il)
- #else
- free_input_list(il)
- InputItem *il;
- #endif
  {
    while (il) {
      InputItem *trash = il;
--- 557,563 ----
*************** InputItem *il;
*** 669,680 ****
  }
  
  static void
- #ifndef _NO_PROTO
  free_input_box(InputBox *box)
- #else
- free_input_box(box)
- InputBox *box;
- #endif
  {
    if (box) {
      free_if_non_NULL(box->name);
--- 568,574 ----
*************** InputBox *box;
*** 683,694 ****
  }
  
  static void
- #ifndef _NO_PROTO
  free_radio_boxes(RadioBoxes *radio)
- #else
- free_radio_boxes(radio)
- RadioBoxes *radio;
- #endif
  {
    if (radio) {
      free_radio_boxes(radio->next);
--- 577,583 ----
*************** RadioBoxes *radio;
*** 700,711 ****
  #if 0
  --------------- NOT USED
  static void
- #ifndef _NO_PROTO
  free_image(ImageStruct *image)
- #else
- free_image(image)
- ImageStruct *image;
- #endif
  {
    free(image->image.xi->data);
    free(image->image.xi);
--- 589,595 ----
*************** ImageStruct *image;
*** 717,728 ****
  #if 0
  --------------- NOT USED
  static void
- #ifndef _NO_PROTO
  free_macro(MacroStore *macro)
- #else
- free_macro(macro)
- MacroStore *macro;
- #endif
  {
    if (macro) {
      free(macro->name);
--- 601,607 ----
*************** MacroStore *macro;
*** 737,748 ****
  
  
  LineStruct *
- #ifndef _NO_PROTO
  alloc_inputline(int size)
- #else
- alloc_inputline(size)
- int size;
- #endif
  {
    int i;
    LineStruct *line =
--- 616,622 ----
*************** int size;
*** 757,768 ****
  }
  
  PasteNode *
- #ifndef _NO_PROTO
  alloc_paste_node(char *name)
- #else
- alloc_paste_node(name)
- char *name;
- #endif
  {
    PasteNode *pastenode =
      (PasteNode *) halloc(sizeof(PasteNode), "PasteNode");
--- 631,637 ----
*************** char *name;
*** 777,787 ****
  }
  
  PatchStore *
- #ifdef _NO_PROTO
- alloc_patchstore()
- #else
  alloc_patchstore(void)
- #endif
  {
    PatchStore *p = (PatchStore *) halloc(sizeof(PatchStore), "PatchStore");
  
--- 646,652 ----
*************** alloc_patchstore(void)
*** 791,802 ****
  }
  
  void
- #ifndef _NO_PROTO
  free_patch(PatchStore *p)
- #else
- free_patch(p)
- PatchStore *p;
- #endif
  {
    if (p) {
      if (p->name)
--- 656,662 ----
*************** PatchStore *p;
*** 810,820 ****
  }
  
  InputBox *
- #ifdef _NO_PROTO
- alloc_inputbox()
- #else
  alloc_inputbox(void)
- #endif
  {
    InputBox *box = (InputBox *) halloc(sizeof(InputBox), "InputBox");
  
--- 670,676 ----
*************** alloc_inputbox(void)
*** 825,835 ****
  }
  
  RadioBoxes *
- #ifdef _NO_PROTO
- alloc_rbs()
- #else
  alloc_rbs(void)
- #endif
  {
    RadioBoxes *newrb = (RadioBoxes *) halloc(sizeof(RadioBoxes), "Radio Boxes");
  
--- 681,687 ----
*************** alloc_rbs(void)
*** 839,849 ****
  }
  
  ButtonList *
- #ifdef _NO_PROTO
- alloc_button_list()
- #else
  alloc_button_list(void)
- #endif
  {
    ButtonList *newbl = (ButtonList *) halloc(sizeof(ButtonList), "Button List");
  
--- 691,697 ----
*************** alloc_button_list(void)
*** 854,865 ****
  }
  
  void
- #ifndef _NO_PROTO
  free_button_list(ButtonList *bl)
- #else
- free_button_list(bl)
- ButtonList *bl;
- #endif
  {
    while (bl) {
      ButtonList *nbl = bl->next;
--- 702,708 ----
*************** ButtonList *bl;
*** 874,887 ****
  #define BufferSlop      0
  
  char *
- #ifndef _NO_PROTO
  resizeBuffer(int size, char *oldBuf, int *oldSize)
- #else
- resizeBuffer(size,oldBuf, oldSize)
- int size;
- char *oldBuf;
- int *oldSize;
- #endif
  {
    char *newBuf;
    int newSize;
--- 717,723 ----
*** src/hyper/parse-aux.pamphlet	(revision 16913)
--- src/hyper/parse-aux.pamphlet	(local)
*************** HashTable ht_gFileHashTable;
*** 49,60 ****
  /* Hash functions for active link windows */
  
  int
- #ifndef _NO_PROTO
  window_equal(Window *w1, Window *w2)
- #else
- window_equal(w1,w2)
- Window *w1, *w2;
- #endif
  {
      return *w1 == *w2;
  }
--- 49,55 ----
*************** Window *w1, *w2;
*** 62,85 ****
  /* hash code for a window */
  
  int
- #ifndef _NO_PROTO
  window_code(Window *w, int size)
- #else
- window_code(w, size)
- Window *w;
- int size;
- #endif
  {
      return (*w) % size;
  }
  
  char *
- #ifndef _NO_PROTO
  window_id(Window w)
- #else
- window_id(w)
- Window w;
- #endif
  {
      char *ret;
      char buff[32];
--- 57,69 ----
*************** Window w;
*** 98,109 ****
   * read the presented data base files
   */
  void
- #ifdef _NO_PROTO
- read_ht_db(page_hash, macro_hash, patch_hash)
-     HashTable *page_hash, *macro_hash, *patch_hash;
- #else
  read_ht_db(HashTable *page_hash, HashTable *macro_hash, HashTable *patch_hash)
- #endif
  {
      FILE *db_fp;
      char db_file[256];
--- 82,88 ----
*************** read_ht_db(HashTable *page_hash, HashTab
*** 157,172 ****
   */
  
  static void
! #ifndef _NO_PROTO
! read_ht_file(HashTable *page_hash, HashTable *macro_hash, HashTable *patch_hash, FILE *db_fp, char *db_file)
! #else
! read_ht_file(page_hash,macro_hash,patch_hash,db_fp,db_file)
! HashTable *page_hash;
! HashTable *macro_hash;
! HashTable *patch_hash;
! FILE *db_fp;
! char *db_file;
! #endif
  {
      char filename[256];
      char *fullname = filename;
--- 136,143 ----
   */
  
  static void
! read_ht_file(HashTable *page_hash, HashTable *macro_hash, 
!              HashTable *patch_hash, FILE *db_fp, char *db_file)
  {
      char filename[256];
      char *fullname = filename;
*************** char *db_file;
*** 332,345 ****
  /* create an unmapped input-only window for an active screen area */
  
  HyperLink *
- #ifndef _NO_PROTO
  make_link_window(TextNode *link_node, int type, int isSubWin)
- #else
- make_link_window(link_node,type,isSubWin)
- TextNode *link_node;
- int type;
- int isSubWin;
- #endif
  {
      HyperLink *link;
      XSetWindowAttributes at;
--- 303,309 ----
*************** int isSubWin;
*** 383,394 ****
  }
  
  HyperLink *
- #ifndef _NO_PROTO
  make_paste_window(PasteNode *paste)
- #else
- make_paste_window(paste)
- PasteNode *paste;
- #endif
  {
      HyperLink *link;
      XSetWindowAttributes at;
--- 347,353 ----
*************** PasteNode *paste;
*** 419,431 ****
  /* create a HyperDoc page structure with the given type and name */
  
  static HyperDocPage *
- #ifndef _NO_PROTO
  make_special_page(int type, char *name)
- #else
- make_special_page(type,name)
- int type;
- char *name;
- #endif
  {
      HyperDocPage *page = alloc_page(name);
  
--- 378,384 ----
*************** char *name;
*** 443,454 ****
  /* insert the special button page types into the page hash table */
  
  void
- #ifndef _NO_PROTO
  make_special_pages(HashTable *pageHashTable)
- #else
- make_special_pages(pageHashTable)
- HashTable *pageHashTable;
- #endif
  {
      hash_insert(pageHashTable, (char *)make_special_page(Quitbutton, "QuitPage"),
                  "QuitPage");
--- 396,402 ----
*************** HashTable *pageHashTable;
*** 464,474 ****
  /* Parse the \bound{varlist} command, and add vars to dependency table */
  
  void
- #ifndef _NO_PROTO
  add_dependencies(void)
- #else
- add_dependencies()
- #endif
  {
      TextNode *bound_node = curr_node;
      TextNode *node;
--- 412,418 ----
*************** add_dependencies()
*** 510,521 ****
  /* Returns true iff the TextNode contains a single integer */
  
  int
- #ifdef _NO_PROTO
- is_number(str)
-     char *str;
- #else
  is_number(char * str)
- #endif
  {
      char *s;
  
--- 454,460 ----
*************** is_number(char * str)
*** 526,537 ****
      return 1;
  }
  void
- #ifdef _NO_PROTO
- parser_error(str)
-     char *str;
- #else
  parser_error(char *str)
- #endif
  {
      /** this procedure is called by the parser when an error occurs. It prints
        the error message, followed by the next 10 tokens to ease finding the
--- 465,471 ----
*************** parser_error(char *str)
*** 559,569 ****
  
  /* advance token to the next token in the input stream.  */
  int
- #ifdef _NO_PROTO
- get_filename()
- #else
  get_filename(void)
- #endif
  {
      int c, ws;
      static int seen_white = 0; /*UNUSED */
--- 493,499 ----
*************** get_filename(void)
*** 606,616 ****
  }
  
  char *
- #ifndef _NO_PROTO
  get_input_string(void)
- #else
- get_input_string()
- #endif
  {
      char *string;
      TextNode *string_node,*save_node;
--- 536,542 ----
*************** get_input_string()
*** 634,644 ****
   * parsing from. If so it then tries to determine which
   */
  int
- #ifdef _NO_PROTO
- get_where()
- #else
  get_where(void)
- #endif
  {
      int tw;
  
--- 560,566 ----
*************** get_where(void)
*** 670,681 ****
  
  
  FILE *
- #ifndef _NO_PROTO
  find_fp(FilePosition fp)
- #else
- find_fp(fp)
- FilePosition fp;
- #endif
  {
      FILE *lfile;
      char fullname[256], addname[256];
--- 592,598 ----
*** src/hyper/parse-input.pamphlet	(revision 16913)
--- src/hyper/parse-input.pamphlet	(local)
***************
*** 33,44 ****
  extern int make_input_file;
  
  HyperLink *
- #ifdef _NO_PROTO
- make_input_window(item)
-     InputItem *item;
- #else
  make_input_window(InputItem * item)
- #endif
  {
    HyperLink *link;
    XSetWindowAttributes at;
--- 33,39 ----
*************** make_input_window(InputItem * item)
*** 70,82 ****
  
  /* create an unmapped input window for boxes */
  HyperLink *
- #ifdef _NO_PROTO
- make_box_window(box, type)
-     InputBox *box;
-     int type;
- #else
  make_box_window(InputBox * box, int type)
- #endif
  {
    HyperLink *link = 0;
    XSetWindowAttributes at;
--- 65,71 ----
*************** make_box_window(InputBox * box, int type
*** 106,118 ****
  }
  
  void
- #ifdef _NO_PROTO
- initialize_default(item, buff)
-     InputItem *item;
-     char *buff;
- #else
  initialize_default(InputItem *item,char * buff)
- #endif
  {
    LineStruct *newline;
    LineStruct *curr_line;
--- 95,101 ----
*************** initialize_default(InputItem *item,char 
*** 159,169 ****
  
  /* Parse the input string statement * */
  void
- #ifdef _NO_PROTO
- parse_inputstring()
- #else
  parse_inputstring(void)
- #endif
  {
    TextNode *input_node = curr_node;
    char *name;
--- 142,148 ----
*************** parse_inputstring(void)
*** 217,227 ****
  }
  
  void
- #ifdef _NO_PROTO
- parse_simplebox()
- #else
  parse_simplebox(void)
- #endif
  {
    InputBox *box;
    char *name;
--- 196,202 ----
*************** parse_simplebox(void)
*** 312,322 ****
    return;
  }
  void
- #ifdef _NO_PROTO
- parse_radiobox()
- #else
  parse_radiobox(void)
- #endif
  {
    InputBox *box;
    char *name;
--- 287,293 ----
*************** parse_radiobox(void)
*** 414,426 ****
    return;
  }
  static void
- #ifdef _NO_PROTO
- add_box_to_rb_list(name, box)
-     char *name;
-     InputBox *box;
- #else
  add_box_to_rb_list(char *name,InputBox *box)
- #endif
  {
    RadioBoxes *trace = gPageBeingParsed->radio_boxes;
    InputBox *list;
--- 385,391 ----
*************** add_box_to_rb_list(char *name,InputBox *
*** 453,464 ****
    return;
  }
  static int
- #ifdef _NO_PROTO
- check_others(list)
-     InputBox *list;
- #else
  check_others(InputBox *list)
- #endif
  {
    InputBox *trace = list;
  
--- 418,424 ----
*************** check_others(InputBox *list)
*** 474,485 ****
  
  /* inserts an item into the current input list */
  static void
- #ifdef _NO_PROTO
- insert_item(item)
-     InputItem *item;
- #else
  insert_item(InputItem *item)
- #endif
  {
    InputItem *trace = gPageBeingParsed->input_list;
  
--- 434,440 ----
*************** insert_item(InputItem *item)
*** 503,514 ****
  InputItem *save_item;
  
  void
- #ifdef _NO_PROTO
- init_paste_item(item)
-     InputItem *item;
- #else
  init_paste_item(InputItem *item)
- #endif
  {
    InputItem *trace = gPageBeingParsed->input_list;
  
--- 458,464 ----
*************** init_paste_item(InputItem *item)
*** 523,533 ****
    }
  }
  void
- #ifdef _NO_PROTO
- repaste_item()
- #else
  repaste_item(void)
- #endif
  {
    InputItem *trace;
  
--- 473,479 ----
*************** repaste_item(void)
*** 546,556 ****
  }
  
  InputItem *
- #ifdef _NO_PROTO
- current_item()
- #else
  current_item(void)
- #endif
  {
    InputItem *trace = gPageBeingParsed->input_list;
  
--- 492,498 ----
*************** current_item(void)
*** 562,573 ****
      return NULL;
  }
  int
- #ifdef _NO_PROTO
- already_there(name)
-     char *name;
- #else
  already_there(char *name)
- #endif
  {
    RadioBoxes *trace = gPageBeingParsed->radio_boxes;
  
--- 504,510 ----
*************** already_there(char *name)
*** 580,590 ****
      return 0;
  }
  void
- #ifdef _NO_PROTO
- parse_radioboxes()
- #else
  parse_radioboxes(void)
- #endif
  {
    TextNode *return_node = curr_node;
    RadioBoxes *newrb;
--- 517,523 ----
*** src/hyper/parse-paste.pamphlet	(revision 16913)
--- src/hyper/parse-paste.pamphlet	(local)
*************** short int gInPaste;
*** 49,59 ****
  
  
  void
- #ifdef _NO_PROTO
- parse_paste()
- #else
  parse_paste(void)
- #endif
  {
      TextNode *pn = curr_node;
      PasteNode *paste;
--- 49,55 ----
*************** parse_paste(void)
*** 138,148 ****
  }
  
  void
- #ifdef _NO_PROTO
- parse_pastebutton()
- #else
  parse_pastebutton(void)
- #endif
  {
      PasteNode *paste;
      TextNode *pb;
--- 134,140 ----
*************** parse_pastebutton(void)
*** 207,219 ****
   */
  
  HyperDocPage *
- #ifndef _NO_PROTO
  parse_patch(PasteNode *paste)
- #else
- parse_patch(paste)
- PasteNode *paste;
- #endif
- 
  {
      TextNode *new;
      TextNode *end_node;
--- 199,205 ----
*************** PasteNode *paste;
*** 350,361 ****
  }
  
  static void
- #ifndef _NO_PROTO
  load_patch(PatchStore *patch)
- #else
- load_patch(patch)
- PatchStore *patch;
- #endif
  {
      long start_fpos;
      int size = 0;
--- 336,342 ----
*** src/hyper/parse-types.pamphlet	(revision 16913)
--- src/hyper/parse-types.pamphlet	(local)
*************** boolean gInItems = FALSE;
*** 55,65 ****
  boolean gInOptional = FALSE;
  
  void
- #ifndef _NO_PROTO
  parse_ifcond(void)
- #else
- parse_ifcond()
- #endif
  {
      TextNode *ifnode = curr_node;
      TextNode *endif;
--- 55,61 ----
*************** parse_ifcond()
*** 130,140 ****
  }
  
  static void
- #ifndef _NO_PROTO
  parse_condnode(void)
- #else
- parse_condnode()
- #endif
  {
      get_token();
  
--- 126,132 ----
*************** parse_condnode()
*** 168,178 ****
  }
  
  static void
- #ifndef _NO_PROTO
  parse_hasreturnto(void)
- #else
- parse_hasreturnto()
- #endif
  {
      TextNode *hrt = curr_node, *arg_node = alloc_node();
  
--- 160,166 ----
*************** parse_hasreturnto()
*** 186,196 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_newcond(void)
- #else
- parse_newcond()
- #endif
  {
      char label[256];
  
--- 174,180 ----
*************** parse_newcond()
*** 203,213 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_setcond(void)
- #else
- parse_setcond()
- #endif
  {
      char label[256], cond[256];
  
--- 187,193 ----
*************** parse_setcond()
*** 224,234 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_begin_items(void)
- #else
- parse_begin_items()
- #endif
  {
      TextNode *bi = curr_node;
  
--- 204,210 ----
*************** parse_begin_items()
*** 260,270 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_item(void)
- #else
- parse_item()
- #endif
  {
      if (!gInItems) {
          fprintf(stderr, "\\item found outside an items environment\n");
--- 236,242 ----
*************** parse_item()
*** 298,308 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_mitem(void)
- #else
- parse_mitem()
- #endif
  {
      if (!gInItems) {
          fprintf(stderr, "\\mitem found outside an items environment\n");
--- 270,276 ----
*************** int vbuf_size = 0;
*** 339,350 ****
    vb = vbuf;
  
  void
- #ifndef _NO_PROTO
  parse_verbatim(int type)
- #else
- parse_verbatim(type)
- int type;
- #endif
  {
      int size = 0, c;
      char *end_string, *vb = vbuf, *es;
--- 307,313 ----
*************** int type;
*** 396,406 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_input_pix(void)
- #else
- parse_input_pix()
- #endif
  {
      TextNode *pixnode;
      char *filename;
--- 359,365 ----
*************** parse_input_pix()
*** 440,450 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_centerline(void)
- #else
- parse_centerline()
- #endif
  {
      curr_node->type = token.type;
      curr_node->space = token.id[-1];
--- 399,405 ----
*************** parse_centerline()
*** 464,474 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_command(void)
- #else
- parse_command()
- #endif
  {
      TextNode *link_node, *save_node, *arg_node;
  
--- 419,425 ----
*************** parse_command()
*** 505,515 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_button(void)
- #else
- parse_button()
- #endif
  {
      TextNode *link_node, *save_node;
  
--- 456,462 ----
*************** parse_button()
*** 554,565 ****
  extern int example_number;
  
  void
- #ifndef _NO_PROTO
  parse_spadcommand(TextNode *spad_node)
- #else
- parse_spadcommand(spad_node)
- TextNode *spad_node;
- #endif
  {
      /*TextNode *node = NULL;*/
  
--- 501,507 ----
*************** TextNode *spad_node;
*** 580,591 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_spadsrc(TextNode *spad_node)
- #else
- parse_spadsrc(spad_node)
- TextNode *spad_node;
- #endif
  {
      char buf[512], *c = buf;
      int ch, start_opts = 0;
--- 522,528 ----
*************** TextNode *spad_node;
*** 622,633 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_env(TextNode *node)
- #else
- parse_env(node)
- TextNode *node;
- #endif
  {
      char *env;
      char buff[256];
--- 559,565 ----
*************** TextNode *node;
*** 667,677 ****
   */
  
  void
- #ifndef _NO_PROTO
  parse_value1(void)
- #else
- parse_value1()
- #endif
  {
      TextNode *value_node, *ocn = curr_node;
      char *s;
--- 599,605 ----
*************** parse_value1()
*** 701,711 ****
   */
  
  void
- #ifndef _NO_PROTO
  parse_value2(void)
- #else
- parse_value2()
- #endif
  {
      TextNode *value_node, *ocn = curr_node;
      char *s;
--- 629,635 ----
*************** parse_value2()
*** 733,743 ****
  /* parse a \table sommand */
  
  void
- #ifndef _NO_PROTO
  parse_table(void)
- #else
- parse_table()
- #endif
  {
      TextNode *tn = curr_node;
  
--- 657,663 ----
*************** parse_table()
*** 783,793 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_box(void)
- #else
- parse_box()
- #endif
  {
      curr_node->type = token.type;
      curr_node->space = token.id[-1];
--- 703,709 ----
*************** parse_box()
*** 800,810 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_mbox(void)
- #else
- parse_mbox()
- #endif
  {
      curr_node->type = token.type;
      curr_node->space = token.id[-1];
--- 716,722 ----
*************** parse_mbox()
*** 817,827 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_free(void)
- #else
- parse_free()
- #endif
  {
      TextNode *free_node = curr_node;
  
--- 729,735 ----
*************** parse_free()
*** 837,847 ****
  }
  
  void
- #ifndef _NO_PROTO
  parse_help(void)
- #else
- parse_help()
- #endif
  {
      curr_node->type = Noop;
      get_token();
--- 745,751 ----
*** src/hyper/parse.pamphlet	(revision 16913)
--- src/hyper/parse.pamphlet	(local)
*************** typedef struct mr_stack {
*** 143,153 ****
  MR_Stack *top_mr_stack = NULL;  /** Declaration for the stack  **/
  
  static void
- #ifndef _NO_PROTO
  Push_MR(void)
- #else
- Push_MR()
- #endif
  {
      MR_Stack *newStackItem = (MR_Stack *) halloc(sizeof(MR_Stack), "Mode Region Stack");
  
--- 143,149 ----
*************** Push_MR()
*** 158,168 ****
  }
  
  static void
- #ifndef _NO_PROTO
  Pop_MR(void)
- #else
- Pop_MR()
- #endif
  {
      MR_Stack *old = top_mr_stack;
  
--- 154,160 ----
*************** Pop_MR()
*** 179,190 ****
  }
  
  void
- #ifndef _NO_PROTO
  load_page(HyperDocPage *page)
- #else
- load_page(page)
- HyperDocPage *page;
- #endif
  {
      if (page->type == UnloadedPageType) {
          HyperDocPage *new_page;
--- 171,177 ----
*************** HyperDocPage *formatpage;
*** 201,212 ****
  /* Display a HyperDoc page with the given name, parsing it if needed */
  
  void
- #ifndef _NO_PROTO
  display_page(HyperDocPage *page)
- #else
- display_page(page)
- HyperDocPage *page;
- #endif
  {
      HyperDocPage *new_page;
  
--- 188,194 ----
*************** HyperDocPage *page;
*** 249,260 ****
  /* Parse a given HyperDoc Page, from the top */
  
  static HyperDocPage *
- #ifndef _NO_PROTO
  format_page(UnloadedPage *ulpage)
- #else
- format_page(ulpage)
- UnloadedPage *ulpage;
- #endif
  {
      /*int ret_val;*/
      HyperDocPage *page = alloc_page(ulpage->name);
--- 231,237 ----
*************** UnloadedPage *ulpage;
*** 278,289 ****
  /* parse the HyperDoc statements in the given string */
  
  void
- #ifndef _NO_PROTO
  parse_from_string(char *str)
- #else
- parse_from_string(str)
- char *str;
- #endif
  {
      save_scanner_state();
      last_ch = NoChar;
--- 255,261 ----
*************** char *str;
*** 295,306 ****
  }
  
  static void
- #ifndef _NO_PROTO
  parse_title(HyperDocPage *page)
- #else
- parse_title(page)
- HyperDocPage *page;
- #endif
  {
      TextNode *node;
  
--- 267,273 ----
*************** HyperDocPage *page;
*** 337,348 ****
  }
  
  static void
- #ifndef _NO_PROTO
  parse_header(HyperDocPage *page)
- #else
- parse_header(page)
- HyperDocPage *page;
- #endif
  {
      TextNode *node;
  
--- 304,310 ----
*************** HyperDocPage *page;
*** 361,372 ****
   */
  
  static void
- #ifndef _NO_PROTO
  init_parse_page(HyperDocPage *page)
- #else
- init_parse_page(page)
- HyperDocPage *page;
- #endif
  {
      gEndedPage = gInDesc = gStringValueOk = gInIf =
          gInButton = gInOptional = gInVerbatim = gInPaste = gInItems =
--- 323,329 ----
*************** HyperDocPage *page;
*** 393,404 ****
  }
  
  void
- #ifndef _NO_PROTO
  init_parse_patch(HyperDocPage *page)
- #else
- init_parse_patch(page)
- HyperDocPage *page;
- #endif
  {
      gEndedPage = gInDesc = gStringValueOk = gInIf =
          gInButton = gInOptional = gInVerbatim = gInPaste = gInItems =
--- 350,356 ----
*************** HyperDocPage *page;
*** 417,428 ****
  #define end_page(t) ((t == Page || t == NewCommand ||t == Endpage)?1:0)
  
  static void
- #ifndef _NO_PROTO
  parse_page(HyperDocPage *page)
- #else
- parse_page(page)
- HyperDocPage *page;
- #endif
  {
      init_parse_page(page);
  
--- 369,375 ----
*************** char *ExpectedBeginScroll =
*** 455,465 ****
   */
  
  void
- #ifndef _NO_PROTO
  parse_HyperDoc(void)
- #else
- parse_HyperDoc()
- #endif
  {
      TextNode *node = NULL /*, *save_node = NULL, *arg_node = NULL*/ ;
  
--- 402,408 ----
*************** parse_HyperDoc()
*** 786,796 ****
  /* parse a page from a socket source */
  
  HyperDocPage *
- #ifndef _NO_PROTO
  parse_page_from_socket(void)
- #else
- parse_page_from_socket()
- #endif
  {
      HyperDocPage *page = alloc_page((char *) NULL);
      HyperDocPage *hpage;
--- 729,735 ----
*************** parse_page_from_socket()
*** 835,845 ****
  }
  
  HyperDocPage *
- #ifndef _NO_PROTO
  parse_page_from_unixfd(void)
- #else
- parse_page_from_unixfd()
- #endif
  {
      HyperDocPage *page = alloc_page((char *) NULL);
  
--- 774,780 ----
*************** parse_page_from_unixfd()
*** 869,879 ****
  }
  
  static void
- #ifndef _NO_PROTO
  start_scrolling(void)
- #else
- start_scrolling()
- #endif
  {
  
      /*
--- 804,810 ----
*************** start_scrolling()
*** 900,910 ****
  }
  
  static void
- #ifndef _NO_PROTO
  start_footer(void)
- #else
- start_footer()
- #endif
  {
      /*
       * This ends the parsing of the scrolling region, and then starts to
--- 831,837 ----
*************** start_footer()
*** 933,943 ****
  }
  
  static void
- #ifndef _NO_PROTO
  end_a_page(void)
- #else
- end_a_page()
- #endif
  {
      if (gParserRegion == Scrolling) {
          fprintf(stderr, "%s\n",
--- 860,866 ----
*************** end_a_page()
*** 964,974 ****
  }
  
  static void
- #ifndef _NO_PROTO
  parse_replacepage(void)
- #else
- parse_replacepage()
- #endif
  {
      get_expected_token(Lbrace);
      get_token();
--- 887,893 ----
*** src/hyper/scrollbar.pamphlet	(revision 16913)
--- src/hyper/scrollbar.pamphlet	(local)
*************** int gScrollbarWidth = sup_width + 2;
*** 158,168 ****
  
  
  void
- #ifndef _NO_PROTO
  makeScrollBarWindows(void)
- #else
- makeScrollBarWindows()
- #endif
  {
      XSetWindowAttributes at;
  
--- 158,164 ----
*************** makeScrollBarWindows()
*** 271,283 ****
  }
  
  static void
- #ifndef _NO_PROTO
  drawScroller3DEffects(HDWindow * hdWindow, int x1, int y1, int x2, int y2)
- #else
- drawScroller3DEffects(hdWindow,x1,y1,x2,y2)
- HDWindow * hdWindow;
- int x1,y1,x2, y2;
- #endif
  {
      XClearWindow(gXDisplay, hdWindow->scroller);
  
--- 267,273 ----
*************** int x1,y1,x2, y2;
*** 313,324 ****
  }
  
  void
- #ifndef _NO_PROTO
  showScrollBars(HDWindow * hdWindow)
- #else
- showScrollBars(hdWindow)
- HDWindow * hdWindow;
- #endif
  {
      XWindowChanges wc;
      /*int src_x = 0, src_y = 0;*/
--- 303,309 ----
*************** HDWindow * hdWindow;
*** 376,387 ****
    **************************************************************************/
  
  void
- #ifndef _NO_PROTO
  moveScroller(HDWindow * hdWindow)
- #else
- moveScroller(hdWindow)
- HDWindow * hdWindow;
- #endif
  {
      XWindowChanges wc;
  
--- 361,367 ----
*************** HDWindow * hdWindow;
*** 403,413 ****
  #define bothalf(y) (y/2)
  
  void
- #ifndef _NO_PROTO
  drawScrollLines(void)
- #else
- drawScrollLines()
- #endif
  {
      /* Checks the page_flags to see if we need a top, or a bottom line.   */
      /* These are the horizontal lines framing a scrolling region when the */
--- 383,389 ----
*************** drawScrollLines()
*** 441,451 ****
   */
  
  void
- #ifndef _NO_PROTO
  calculateScrollBarMeasures(void)
- #else
- calculateScrollBarMeasures()
- #endif
  {
      int t;
  
--- 417,423 ----
*************** calculateScrollBarMeasures()
*** 517,527 ****
  }
  
  void
- #ifndef _NO_PROTO
  linkScrollBars(void)
- #else
- linkScrollBars()
- #endif
  {
      HyperLink *uplink = (HyperLink *) halloc(sizeof(HyperLink), "HyperLink");
      HyperLink *downlink = (HyperLink *) halloc(sizeof(HyperLink), "HyperLink");
--- 489,495 ----
*************** linkScrollBars()
*** 544,554 ****
  }
  
  void
- #ifndef _NO_PROTO
  scrollUp(void)
- #else
- scrollUp()
- #endif
  {
  
      if (gWindow->page->scroll_off == 0);       /* BeepAtTheUser(); *//* The
--- 512,518 ----
*************** scrollUp()
*** 574,584 ****
  }
  
  void
- #ifndef _NO_PROTO
  scrollUpPage(void)
- #else
- scrollUpPage()
- #endif
  {
      if (gWindow->page->scroll_off == 0);       /* BeepAtTheUser(); */
      else {
--- 538,544 ----
*************** scrollUpPage()
*** 594,604 ****
  }
  
  void
- #ifndef _NO_PROTO
  scrollToFirstPage(void)
- #else
- scrollToFirstPage()
- #endif
  {
      if (gWindow->page->scroll_off == 0);       /* BeepAtTheUser(); */
      else {
--- 554,560 ----
*************** scrollToFirstPage()
*** 609,619 ****
  }
  
  void
- #ifndef _NO_PROTO
  scrollDown(void)
- #else
- scrollDown()
- #endif
  {
  
      if (-(gWindow->page->scroll_off) >=
--- 565,571 ----
*************** scrollDown()
*** 641,651 ****
  
  
  void
- #ifndef _NO_PROTO
  scrollDownPage(void)
- #else
- scrollDownPage()
- #endif
  {
      if (gWindow->page->scrolling == NULL || (-(gWindow->page->scroll_off) >=
              (gWindow->page->scrolling->height - gWindow->scrollheight))) {
--- 593,599 ----
*************** scrollDownPage()
*** 666,677 ****
  }
  
  void
- #ifndef _NO_PROTO
  scrollScroller(XButtonEvent * event)
- #else
- scrollScroller(event)
- XButtonEvent * event;
- #endif
  {
  
      /*
--- 614,620 ----
*************** XButtonEvent * event;
*** 713,724 ****
  
  
  void
- #ifndef _NO_PROTO
  hideScrollBars(HDWindow * hdWindow)
- #else
- hideScrollBars(hdWindow)
- HDWindow * hdWindow;
- #endif
  {
      XUnmapWindow(gXDisplay, hdWindow->fScrollDownWindow);
      XUnmapWindow(gXDisplay, hdWindow->fScrollUpWindow);
--- 656,662 ----
*************** HDWindow * hdWindow;
*** 727,751 ****
  }
  
  void
- #ifndef _NO_PROTO
  getScrollBarMinimumSize(int *width, int *height)
- #else
- getScrollBarMinimumSize(width,height)
- int *width;
- int *height;
- #endif
  {
      (*width)  = sup_width + 4;
      (*height) = sup_height + sdown_height + 5;
  }
  
  static int
- #ifndef _NO_PROTO
  ch(int height)
- #else
- ch(height)
- int height;
- #endif
  {
      /*int rheight;*/
      int rem = height % line_height;
--- 665,678 ----
*************** int height;
*** 756,768 ****
  }
  
  static void
- #ifndef _NO_PROTO
  changeWindowBackgroundPixmap(Window window, Pixmap pixmap)
- #else
- changeWindowBackgroundPixmap(window,pixmap)
- Window window;
- Pixmap pixmap;
- #endif
  {
      if (pixmap) {
          XSetWindowAttributes at;
--- 683,689 ----
*** src/hyper/show-types.pamphlet	(revision 16913)
--- src/hyper/show-types.pamphlet	(local)
***************
*** 50,62 ****
   */
  
  void
- #ifndef _NO_PROTO
  show_text(TextNode *node, int Ender)
- #else
- show_text(node, Ender)
- TextNode *node; 
- int Ender;
- #endif
  {
      /*int twidth, len;*/
      /*int otext_x, otext_y, t;*/
--- 50,56 ----
*************** int Ender;
*** 331,342 ****
  }
  
  static void
- #ifndef _NO_PROTO
  show_link(TextNode *node)
- #else
- show_link(node)
- TextNode *node;
- #endif
  {
      /* XFontStruct *old_font;*/
      XWindowChanges wc;
--- 325,331 ----
*************** TextNode *node;
*** 408,419 ****
  }
  
  static void
- #ifndef _NO_PROTO
  show_paste(TextNode *node)
- #else
- show_paste(node)
- TextNode *node;
- #endif
  {
      PasteNode *paste;
  
--- 397,403 ----
*************** TextNode *node;
*** 434,445 ****
  }
  
  static void
- #ifndef _NO_PROTO
  show_pastebutton(TextNode *node)
- #else
- show_pastebutton(node)
- TextNode *node;
- #endif
  {
      /*XFontStruct *old_font;*/
      XWindowChanges wc;
--- 418,424 ----
*************** TextNode *node;
*** 463,474 ****
  /* display an input string window */
  
  static void
- #ifndef _NO_PROTO
  show_input(TextNode *node)
- #else
- show_input(node)
- TextNode *node;
- #endif
  {
      /*XFontStruct *old_font;*/
      XWindowChanges wc;
--- 442,448 ----
*************** TextNode *node;
*** 497,508 ****
  }
  
  static void
- #ifndef _NO_PROTO
  show_simple_box(TextNode *node)
- #else
- show_simple_box(node)
- TextNode *node;
- #endif
  {
      XWindowChanges wc;
      InputBox *box;
--- 471,477 ----
*************** TextNode *node;
*** 528,539 ****
  /* display a spad command node */
  
  static void
- #ifndef _NO_PROTO
  show_spadcommand(TextNode *node)
- #else
- show_spadcommand(node)
- TextNode *node;
- #endif
  {
      XWindowChanges wc;
  
--- 497,503 ----
*************** TextNode *node;
*** 560,572 ****
  /* display a pixmap */
  
  static void
- #ifndef _NO_PROTO
  show_image(TextNode *node, GC gc)
- #else
- show_image(node, gc)
- TextNode *node;
- GC gc;
- #endif
  {
      int src_x, src_y, src_width, src_height, dest_x, dest_y, ret_val;
  
--- 524,530 ----
*** src/hyper/spadbuf.pamphlet	(revision 16913)
--- src/hyper/spadbuf.pamphlet	(local)
*************** char *buff_name = NULL;    /* name for t
*** 76,97 ****
   */
  
  static void
- #ifdef _NO_PROTO
- spadbuf_inter_handler(sig)
-      int sig;
- #else
  spadbuf_inter_handler(int sig)
- #endif
  {
      send_signal(session_sock, SIGUSR2);
  }
  
  static void
- #ifdef _NO_PROTO
- spadbuf_function_chars()
- #else
  spadbuf_function_chars(void)
- #endif
  {
      /** once I have that get the special characters         ****/
      _INTR = oldbuf.c_cc[VINTR];
--- 76,88 ----
*************** spadbuf_function_chars(void)
*** 106,116 ****
  /* act as terminal session for sock connected to stdin 
     and stdout of another process */
  static void
- #ifdef _NO_PROTO
- interp_io()
- #else
  interp_io(void)
- #endif
  {
      char buf[1024];
      fd_set rd;
--- 97,103 ----
*************** interp_io(void)
*** 159,169 ****
  }
  
  static void
- #ifdef _NO_PROTO
- init_parent()
- #else
  init_parent(void)
- #endif
  {
  
      /** get the original termio settings, so I never have to check again **/
--- 146,152 ----
*************** init_parent(void)
*** 205,217 ****
  }
  
  int
- #ifdef _NO_PROTO
- main(argc, argv)
-     int argc;
-     char **argv;
- #else
  main(int argc,char **  argv)
- #endif
  {
      /*int name_found;*/
      /*FILE *junk;*/
--- 188,194 ----
*** src/hyper/spadint.pamphlet	(revision 16913)
--- src/hyper/spadint.pamphlet	(local)
*************** Sock *spad_socket = (Sock *) 0; /* to_se
*** 41,55 ****
  
  /* issue a AXIOM command to the buffer associated with a page */
  void
! #ifdef _NO_PROTO
! issue_spadcommand(page, command, immediate, type)
!     HyperDocPage *page;
!     TextNode *command;
!     int immediate;
!     int type;
! #else
! issue_spadcommand(HyperDocPage *page, TextNode *command, int immediate, int type)
! #endif
  {
      char *buf;
      int ret_val;
--- 41,48 ----
  
  /* issue a AXIOM command to the buffer associated with a page */
  void
! issue_spadcommand(HyperDocPage *page, TextNode *command, int immediate,
!                   int type)
  {
      char *buf;
      int ret_val;
*************** issue_spadcommand(HyperDocPage *page, Te
*** 82,94 ****
      gIsEndOfOutput = 0;
  }
  static void
- #ifdef _NO_PROTO
- send_pile(sock, str)
-     Sock *sock;
-     char *str;
- #else
  send_pile(Sock *sock,char * str)
- #endif
  {
      FILE *f;
      char name[512], command[512];
--- 75,81 ----
*************** send_pile(Sock *sock,char * str)
*** 105,118 ****
      send_string(sock, command);
  }
  static void
- #ifdef _NO_PROTO
- issue_dependent_commands(page, command, type)
-     HyperDocPage *page;
-     TextNode *command;
-     int type;
- #else
  issue_dependent_commands(HyperDocPage *page, TextNode *command,int type)
- #endif
  {
      TextNode *node, *depend_label;
      SpadcomDepend *depend;
--- 92,98 ----
*************** issue_dependent_commands(HyperDocPage *p
*** 142,155 ****
                  }
  }
  static void
- #ifdef _NO_PROTO
- mark_as_executed(page, command, type)
-     HyperDocPage *page;
-     TextNode *command;
-     int type;
- #else
  mark_as_executed(HyperDocPage *page, TextNode *command,int type)
- #endif
  {
      TextNode *node, *depend_label;
      SpadcomDepend *depend;
--- 122,128 ----
*************** mark_as_executed(HyperDocPage *page, Tex
*** 174,185 ****
  
  /* start a spad buffer for the page associated with the give */
  static void
- #ifdef _NO_PROTO
- start_user_buffer(page)
-     HyperDocPage *page;
- #else
  start_user_buffer(HyperDocPage *page)
- #endif
  {
      char buf[1024], *title;
      char *SPAD;
--- 147,153 ----
*************** start_user_buffer(HyperDocPage *page)
*** 240,251 ****
  
  /* Clears the execution marks in a hash table when a buffer has been killed */
  static void
- #ifdef _NO_PROTO
- clear_execution_marks(depend_hash)
-     HashTable *depend_hash;
- #else
  clear_execution_marks(HashTable *depend_hash)
- #endif
  {
      int i;
      HashEntry *h;
--- 208,214 ----
*************** clear_execution_marks(HashTable *depend_
*** 261,272 ****
  }
  
  Sock *
- #ifdef _NO_PROTO
- accept_menu_connection(server_sock)
-     Sock *server_sock;
- #else
  accept_menu_connection(Sock *server_sock)
- #endif
  {
      int sock_fd /*, session, ret_code*/;
      Sock_List *pls;
--- 224,230 ----
*************** accept_menu_connection(Sock *server_sock
*** 307,318 ****
  }
  
  static void
- #ifdef _NO_PROTO
- accept_menu_server_connection(page)
-     HyperDocPage *page;
- #else
  accept_menu_server_connection(HyperDocPage *page)
- #endif
  {
  
      /*
--- 265,271 ----
*************** int p2sBufSize = 0;
*** 389,400 ****
   */
  
  char *
- #ifdef _NO_PROTO
- print_to_string(command)
-     TextNode *command;          /* The text node being translated       */
- #else
  print_to_string(TextNode *command)
- #endif
  {
      int len = 0;
  
--- 342,348 ----
*************** see the code in ht-util.boot
*** 416,428 ****
  extern int include_bf;
  
  char *
- #ifdef _NO_PROTO
- print_to_string1(command, sizeBuf)
-     TextNode *command;          /* The text node being translated       */
-     int *sizeBuf;
- #else
  print_to_string1(TextNode *command,int * sizeBuf)
- #endif
  {
      char *c = p2sBuf;
      char *s;
--- 364,370 ----
*************** print_to_string1(TextNode *command,int *
*** 669,680 ****
   */
  
  HyperDocPage *
- #ifdef _NO_PROTO
- issue_server_command(link)
-     HyperLink *link;
- #else
  issue_server_command(HyperLink *link)
- #endif
  {
      TextNode *command = (TextNode *) link->reference.node;
      int ret_val;
--- 611,617 ----
*************** issue_server_command(HyperLink *link)
*** 722,733 ****
  }
  
  int
- #ifdef _NO_PROTO
- issue_serverpaste(command)
-     TextNode *command;
- #else
  issue_serverpaste(TextNode *command)
- #endif
  {
      char *buf;
      int ret_val;
--- 659,665 ----
*************** issue_serverpaste(TextNode *command)
*** 746,757 ****
   * issue a unix command
   */
  void
- #ifdef _NO_PROTO
- issue_unixcommand(node)
-     TextNode *node;
- #else
  issue_unixcommand(TextNode *node)
- #endif
  {
      char *buf;
      char *copy;
--- 678,684 ----
*************** issue_unixcommand(TextNode *node)
*** 768,779 ****
  }
  
  HyperDocPage *
- #ifdef _NO_PROTO
- issue_unixlink(node)
-     TextNode *node;
- #else
  issue_unixlink(TextNode *node)
- #endif
  {
      HyperDocPage *page;
      char *buf;
--- 695,701 ----
*************** issue_unixlink(TextNode *node)
*** 790,801 ****
  }
  
  int
- #ifdef _NO_PROTO
- issue_unixpaste(node)
-     TextNode *node;
- #else
  issue_unixpaste(TextNode *node)
- #endif
  {
      char *buf;
  
--- 712,718 ----
*************** issue_unixpaste(TextNode *node)
*** 812,822 ****
   * called when session_server selects
   */
  void
- #ifdef _NO_PROTO
- service_session_socket()
- #else
  service_session_socket(void)
- #endif
  {
      int cmd, pid;
  
--- 729,735 ----
*************** service_session_socket(void)
*** 839,849 ****
   * let spad know which frame to issue command via
   */
  static void
- #ifdef _NO_PROTO
- switch_frames()
- #else
  switch_frames(void)
- #endif
  {
      if (session_server == NULL) {
          fprintf(stderr, "(HyperDoc) No session manager connected!\n");
--- 752,758 ----
*************** switch_frames(void)
*** 857,868 ****
      send_int(session_server, gWindow->fAxiomFrame);
  }
  void
- #ifdef _NO_PROTO
- send_lisp_command(command)
-     char *command;
- #else
  send_lisp_command(char *command)
- #endif
  {
      int ret_val;
  
--- 766,772 ----
*************** send_lisp_command(char *command)
*** 874,885 ****
      send_string(spad_socket, command);
  }
  void
- #ifdef _NO_PROTO
- escape_string(s)
-     char *s;
- #else
  escape_string(char *s)
- #endif
  {
      char *st;
  
--- 778,784 ----
*************** escape_string(char *s)
*** 887,898 ****
          *st = funnyEscape(*st);
  }
  void
- #ifdef _NO_PROTO
- unescape_string(s)
-     char *s;
- #else
  unescape_string(char *s)
- #endif
  {
      char *st;
  
--- 786,792 ----
*************** unescape_string(char *s)
*** 900,911 ****
          *st = funnyUnescape(*st);
  }
  static void
- #ifdef _NO_PROTO
- close_client(pid)
-     int pid;
- #else
  close_client(int pid)
- #endif
  {
      /*int i;*/
      Sock_List *pSock, *locSock;
--- 794,800 ----
*************** close_client(int pid)
*** 955,966 ****
  
  
  char *
- #ifdef _NO_PROTO
- print_source_to_string(command)
-     TextNode *command;          /* The text node being translated       */
- #else
  print_source_to_string(TextNode *command)
- #endif
  {
      int len = 0;
  
--- 844,850 ----
*************** print_source_to_string(TextNode *command
*** 969,981 ****
      return print_source_to_string1(command, NULL);
  }
  char *
- #ifdef _NO_PROTO
- print_source_to_string1(command, sizeBuf)
-     TextNode *command;          /* The text node being translated       */
-     int *sizeBuf;
- #else
  print_source_to_string1(TextNode *command,int * sizeBuf)
- #endif
  {
      char *c = p2sBuf;
      char *s;
--- 853,859 ----
*** src/hyper/titlebar.pamphlet	(revision 16913)
--- src/hyper/titlebar.pamphlet	(local)
*************** int twwidth, twheight;   /* the width an
*** 87,97 ****
                           /* title bar */
  
  void
- #ifdef _NO_PROTO
- makeTitleBarWindows()
- #else
  makeTitleBarWindows(void)
- #endif
  {
      XSetWindowAttributes at;
      unsigned long valuemask = 0L;
--- 87,93 ----
*************** makeTitleBarWindows(void)
*** 132,142 ****
  }
  
  void
- #ifdef _NO_PROTO
- showTitleBar()
- #else
  showTitleBar(void)
- #endif
  {
      XWindowChanges wc;
      int height, hbw = (int) gWindow->border_width / 2;
--- 128,134 ----
*************** showTitleBar(void)
*** 265,275 ****
  }
  
  void
- #ifdef _NO_PROTO
- linkTitleBarWindows()
- #else
  linkTitleBarWindows(void)
- #endif
  {
      HyperLink *tw1link = (HyperLink *) halloc(sizeof(HyperLink), "HyperLink"),
                *tw2link = (HyperLink *) halloc(sizeof(HyperLink), "HyperLink"),
--- 257,263 ----
*************** linkTitleBarWindows(void)
*** 303,313 ****
  }
  
  static void
- #ifdef _NO_PROTO
- readTitleBarImages()
- #else
  readTitleBarImages(void)
- #endif
  {
      int w, h;
      char filename[128];
--- 291,297 ----
*************** readTitleBarImages(void)
*** 356,367 ****
  }
  
  void
- #ifndef _NO_PROTO
  getTitleBarMinimumSize(int *width, int *height)
- #else
- getTitleBarMinimumSize(width, height)
- int *width,*height;
- #endif
  {
      (*width)  = 4 * twwidth + 40;
      (*height) = twheight + 2;
--- 340,346 ----



\start
Date: 23 Nov 2006 00:04:11 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: ENV

Tim Daly writes:

[...]

| prefix form sets the environment values but the new Makefile assignments
| will be used if they are set.

Which actually implies that most of the ENV should have been in the
Makefiles in the first place, eliminating the needs ot having to pass
anything prefix.

Ah, if you don't want bugs, don't create opportunity for bugs in the
first place.  Used to say a friend.

\start
Date: Wed, 22 Nov 2006 18:02:19 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: ENV

> | An excellent point. Except that none of the makefiles in the axiom
> | tree are designed to be executed "standalone". 
> 
> The old broken makefiles were designed that way.  Yes.  

So, let me get this straight....

You've redesigned the Makefiles so they can be executed standalone.
You tried to execute your new Makefile standalone.
That failed because you use a Makefile variable called ENV 
but do not define it in the new standalone Makefile.

And this is the fault of "the old broken makefiles"?

\start
Date: 23 Nov 2006 00:25:09 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: ENV

Tim Daly writes:

| > | An excellent point. Except that none of the makefiles in the axiom
| > | tree are designed to be executed "standalone". 
| > 
| > The old broken makefiles were designed that way.  Yes.  
| 
| So, let me get this straight....

OK.

[...]

ENV was not chosen by me.  I would not have left a prefix variable
definition in the Makefiles if I had redesigned everything to completion. 

| And this is the fault of "the old broken makefiles"?

I don't know whether it is their fault, but since they are already
broken, they just show another aspect of their brokenness.  I don't
know whether an attribute can be credited as a fault.

\start
Date: 23 Nov 2006 00:31:24 +0100
From: Gabriel Dos Reis
To: list
Subject: src/boot/boot-proclaims.lisp

Directory src/boot defines its symbols in package boottran.
Why is it that the proclaim files says:

    (make-package "BOOT"  :USE '("LISP"))


Then swicthes to package boot


    (IN-PACKAGE "BOOT") 

before writin out the proclaims?

\start
Date: Thu, 23 Nov 2006 01:30:39 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: sman and X libraries

in version 288 I see:

2006-11-18  Bill Page  Bill Page

       * Makefile.pamphlet (LDFLAGS): Add X11 libraries flags.
       * Makefile.in: Regenerate.

Why do we need this: AFAIK sman should not use any X libraries.
In recent build 'ldd sman' gives me:

        libXpm.so.4 => /usr/X11R6/lib64/libXpm.so.4 (0x0000002a9566c000)
        libSM.so.6 => /usr/X11R6/lib64/libSM.so.6 (0x0000002a95780000)
        libICE.so.6 => /usr/X11R6/lib64/libICE.so.6 (0x0000002a9588d000)
        libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x0000002a959af000)
        libc.so.6 => /lib/libc.so.6 (0x0000002a95bc4000)
        libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x0000002a95dea000)
        libXau.so.6 => /usr/X11R6/lib64/libXau.so.6 (0x0000002a95efe000)
        libXdmcp.so.6 => /usr/X11R6/lib64/libXdmcp.so.6 (0x0000002a96001000)
        libdl.so.2 => /lib/libdl.so.2 (0x0000002a96104000)
        /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)

so now sman will refuse to run on a machine without X libraries.

\start
Date: Wed, 22 Nov 2006 19:43:54 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Testing build-improvements

Gaby,

I updated by build-improvements testing repository on and rebuilt
Axiom with no errors. (GCL compiled separately with maxpage option).
Then I repeated your suggested tests (see below), but I got the
same results. No problems. Does revision 301 still fail on your
system?

And some good news: I was able to run your new bootsys (Shoe)
compiler script:

[page@axiom-developer axiom.test]$ cd src/interp

[page@axiom-developer interp]$ document --tag=boot --mode=translate
bootsys msg.boot

GCL (GNU Common Lisp)  2.6.8 CLtL1    Nov 15 2006 13:37:33
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

>msg.clisp PRODUCED
"msg.clisp PRODUCED"

---------

Thankyou, thankyou! (: thanksgiving :)

Regards,
Bill Page.

On Wednesday, November 22, 2006 3:31 PM I wrote:
>
> On Wednesday, November 22, 2006 1:32 PM Gaby wrote:
> > | On Wednesday, November 22, 2006 12:50 PM Gaby wrote:
> > |
> > | > | > !              chunk=$arg
> >
> > Bill Page wrote:
> >
> > | Why does this fail? What is the value of $chunk?
> >
> > Most of your questions can be asnwered as follows:
> > Uncomment the "set -x" and "set +x" instructions from the
> > document script and run the script for the files TESTFR.input,
> > INTHEORY.input and VIEW2D.input.
> >
> >    ${INPUT}/TESTFR.input: $(srcdir)/fr.spad.pamphlet
> >            $(axiom_build_document) --tangle='TEST FR' =
--output=$@ $<
> >
> >    ${INPUT}/INTHEORY.input: $(srcdir)/numtheor.spad.pamphlet
> >            $(axiom_build_document) --tangle='TEST INTHEORY'
> > --output=$@ $<
> >
> >    ${INPUT}/VIEW2D.input: $(srcdir)/view2D.spad.pamphlet
> >            $(axiom_build_document) --tangle='TEST VIEW2D'
> > --output=$@ $<
> >
>
> Unfortunately what wasted a lot of time and did not tell me
> anything. :-(
>
> All of these commands executed properly on the axiom-developer.org
> server without changes to document - probably because of the default
> behaviour of bash. See the output attached below.
>

Test repeated with build-improvements Revision: 301
Last Changed Date: 2006-11-22 12:22:44 -0600 (Wed, 22 Nov 2006)

[page@axiom-developer scripts]$ ./document --tangle='TEST FR'
--output=test1 ${srcdir}/
fr.spad.pamphlet
+ latex=latex
+ index=@MAKINDEX@
+ tangle=/usr/local/bin/notangle
+ weave=/usr/local/bin/noweave
+ =
TEXINPUTS=.:/home/page/axiom.test/build/i686-pc-linux/share/texmf/tex:
+ export TEXINPUTS
+ =
BIBINPUTS=.:/home/page/axiom.test/build/i686-pc-linux/share/texmf/tex:
+ export BIBINPUTS
+ do_index=
+ do_latex=
+ do_tangle=
+ do_weave=
+ chunk=
+ file=
+ output=
+ tag=
+ mode=
+ test 3 -gt 0
+ optval=--tangle=TEST FR
++ echo --tangle=TEST FR
++ sed -e 's/^[-a-zA-Z]*=//'
+ arg=TEST FR
++ echo --tangle=TEST FR
++ sed -e 's/=.*$//'
+ opt=--tangle
+ shift
+ do_tangle=yes
+ test -n 'TEST FR'
++ echo -n TEST FR
+ chunk=TEST FR
+ test 2 -gt 0
+ optval=--output=test1
++ echo --output=test1
++ sed -e 's/^[-a-zA-Z]*=//'
+ arg=test1
++ echo --output=test1
++ sed -e 's/=.*$//'
+ opt=--output
+ shift
+ maybe_missing_value_for --output test1
+ test -z test1
+ output=test1
+ test 1 -gt 0
+
optval=/home/page/axiom.build-improvements/src/algebra/fr.spad.pamphlet=

+ break
+ test xyes = xyes
+ =
file=/home/page/axiom.build-improvements/src/algebra/fr.spad.pamphlet
+ '[' -z test1 ']'
+ '[' -z 'TEST FR' ']'
+ /usr/local/bin/notangle '-RTEST FR'
/home/page/axiom.build-improvements/src/algebra/fr.spad.pamphlet
+ exit 0
[page@axiom-developer scripts]$ cat test1
  D(factor (-x), x)
[page@axiom-developer scripts]$

[page@axiom-developer scripts]$ ./document --tangle='TEST INTHEORY'
--output=test2 ${sr
cdir}/numtheor.spad.pamphlet
+ latex=latex
+ index=@MAKINDEX@
+ tangle=/usr/local/bin/notangle
+ weave=/usr/local/bin/noweave
+ =
TEXINPUTS=.:/home/page/axiom.test/build/i686-pc-linux/share/texmf/tex:
+ export TEXINPUTS
+ =
BIBINPUTS=.:/home/page/axiom.test/build/i686-pc-linux/share/texmf/tex:
+ export BIBINPUTS
+ do_index=
+ do_latex=
+ do_tangle=
+ do_weave=
+ chunk=
+ file=
+ output=
+ tag=
+ mode=
+ test 3 -gt 0
+ optval=--tangle=TEST INTHEORY
++ sed -e 's/^[-a-zA-Z]*=//'
++ echo --tangle=TEST INTHEORY
+ arg=TEST INTHEORY
++ echo --tangle=TEST INTHEORY
++ sed -e 's/=.*$//'
+ opt=--tangle
+ shift
+ do_tangle=yes
+ test -n 'TEST INTHEORY'
++ echo -n TEST INTHEORY
+ chunk=TEST INTHEORY
+ test 2 -gt 0
+ optval=--output=test2
++ echo --output=test2
++ sed -e 's/^[-a-zA-Z]*=//'
+ arg=test2
++ echo --output=test2
++ sed -e 's/=.*$//'
+ opt=--output
+ shift
+ maybe_missing_value_for --output test2
+ test -z test2
+ output=test2
+ test 1 -gt 0
+
optval=/home/page/axiom.build-improvements/src/algebra/numtheor.spad.pa=
m
phlet
+ break
+ test xyes = xyes
+
file=/home/page/axiom.build-improvements/src/algebra/numtheor.spad.pamp=
h
let
+ '[' -z test2 ']'
+ '[' -z 'TEST INTHEORY' ']'
+ /usr/local/bin/notangle '-RTEST INTHEORY'
/home/page/axiom.build-improvements/src/algebra/numtheor.spad.pamphlet
+ exit 0
[page@axiom-developer scripts]$ cat test2
)clear all
x1:=4
m1:=5
x2:=2
m2:=3
result:=chineseRemainder(x1,m1,x2,m2)
expected:=14
if (result-expected ~=0) then print "DALY BUG"

)clear completely

inverse:(INT,INT)->INT

inverse(a,b) ==
  borg:INT:=b
  c1:INT := 1
  d1:INT := 0
  while b ~= 0 repeat
    q := a quo b
    r := a-q*b
    print [a, "=", q, "*(", b, ")+", r]
    (a,b):=(b,r)
    (c1,d1):=(d1,c1-q*d1)
  a ~= 1 => error("moduli are not relatively prime")
  positiveRemainder(c1,borg)

if ((inverse(26,15)*26)::IntegerMod(15) ~= 1) then print "DALY BUG"
if ((inverse(15,26)*15)::IntegerMod(26) ~= 1) then print "DALY BUG"

[page@axiom-developer scripts]$

[page@axiom-developer scripts]$ ./document --tangle='TEST VIEW2D'
--output=test3 ${srcd
ir}/view2D.spad.pamphlet
+ latex=latex
+ index=@MAKINDEX@
+ tangle=/usr/local/bin/notangle
+ weave=/usr/local/bin/noweave
+ =
TEXINPUTS=.:/home/page/axiom.test/build/i686-pc-linux/share/texmf/tex:
+ export TEXINPUTS
+ =
BIBINPUTS=.:/home/page/axiom.test/build/i686-pc-linux/share/texmf/tex:
+ export BIBINPUTS
+ do_index=
+ do_latex=
+ do_tangle=
+ do_weave=
+ chunk=
+ file=
+ output=
+ tag=
+ mode=
+ test 3 -gt 0
+ optval=--tangle=TEST VIEW2D
++ echo --tangle=TEST VIEW2D
++ sed -e 's/^[-a-zA-Z]*=//'
+ arg=TEST VIEW2D
++ echo --tangle=TEST VIEW2D
++ sed -e 's/=.*$//'
+ opt=--tangle
+ shift
+ do_tangle=yes
+ test -n 'TEST VIEW2D'
++ echo -n TEST VIEW2D
+ chunk=TEST VIEW2D
+ test 2 -gt 0
+ optval=--output=test3
++ echo --output=test3
++ sed -e 's/^[-a-zA-Z]*=//'
+ arg=test3
++ echo --output=test3
++ sed -e 's/=.*$//'
+ opt=--output
+ shift
+ maybe_missing_value_for --output test3
+ test -z test3
+ output=test3
+ test 1 -gt 0
+
optval=/home/page/axiom.build-improvements/src/algebra/view2D.spad.pamp=
h
let
+ break
+ test xyes = xyes
+
file=/home/page/axiom.build-improvements/src/algebra/view2D.spad.pamphl=
e
t
+ '[' -z test3 ']'
+ '[' -z 'TEST VIEW2D' ']'
+ /usr/local/bin/notangle '-RTEST VIEW2D'
/home/page/axiom.build-improvements/src/algebra/view2D.spad.pamphlet
+ exit 0
[page@axiom-developer scripts]$ cat test3
)clear all
a:=0.5
b:=0.5
y1:=draw(x^3*(a+b*x),x=-1..1,title=="2.2.10 explicit")
g1:=getGraph(y1,1)
pointLists g1
b:=1.0
y2:=draw(x^3*(a+b*x),x=-1..1)
g2:=getGraph(y2,1)
pointLists g2
putGraph(y1,g2,2)
b:=2.0
y3:=draw(x^3*(a+b*x),x=-1..1)
g3:=getGraph(y3,1)
pointLists g3
putGraph(y1,g3,3)
vp:=makeViewport2D(y1)
[page@axiom-developer scripts]$

\start
Date: Thu, 23 Nov 2006 01:48:55 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: make patch 50 work with the guessing package

Martin Rubey wrote:
> Dear Tim,
> 
> could you explain the following diff:
> 
> diff -r /local/scratch/axiom/mnt/linux/doc/hypertex/pages/util.ht axiom49/mnt/linux/doc/hypertex/pages/util.ht
> 435,439c435,437
> < % 20030110000 tpd added a leading open paren
> < \newcommand{\spadsyscom}[1]{){\tt #1}}
> < % 20030110000 tpd these two commands are never used
> < %\newcommand{\spadcmd}[1]{\spadsyscom{#1}}
> < %\newcommand{\spadsys}[1]{\spadsyscom{#1}}
> ---
> > \newcommand{\spadsyscom}[1]{{\tt #1}}
> > \newcommand{\spadcmd}[1]{\spadsyscom{#1}}
> > \newcommand{\spadsys}[1]{\spadsyscom{#1}}
> 
> It breaks my guessing package!
> 

Hej Martin, could you explan what problem this patch causes? Macros
\spadcmd and \spadsys are used on many Hypertex pages, without them
Hypertex exits when you try to view such a page. Also, pages
alredy contain closing parentheses in system commans so 
\spadsyscom sould not add the second one.

\start
Date: 23 Nov 2006 02:17:29 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: sman and X libraries

Waldek Hebisch writes:

| in version 288 I see:
| 
| 2006-11-18  Bill Page  Bill Page
| 
|        * Makefile.pamphlet (LDFLAGS): Add X11 libraries flags.
|        * Makefile.in: Regenerate.
| 
| Why do we need this: AFAIK sman should not use any X libraries.
| In recent build 'ldd sman' gives me:
| 
|         libXpm.so.4 => /usr/X11R6/lib64/libXpm.so.4 (0x0000002a9566c000)
|         libSM.so.6 => /usr/X11R6/lib64/libSM.so.6 (0x0000002a95780000)
|         libICE.so.6 => /usr/X11R6/lib64/libICE.so.6 (0x0000002a9588d000)
|         libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x0000002a959af000)
|         libc.so.6 => /lib/libc.so.6 (0x0000002a95bc4000)
|         libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x0000002a95dea000)
|         libXau.so.6 => /usr/X11R6/lib64/libXau.so.6 (0x0000002a95efe000)
|         libXdmcp.so.6 => /usr/X11R6/lib64/libXdmcp.so.6 (0x0000002a96001000)
|         libdl.so.2 => /lib/libdl.so.2 (0x0000002a96104000)
|         /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)
| 
| so now sman will refuse to run on a machine without X libraries.

Aaarg.  :-( I don't remember. 
I'm responsible for having checked in Bill's patch.  Bill, did I
pervert your patch?

\start
Date: Wed, 22 Nov 2006 20:25:49 -0500
From: Bill Page
To: Waldek Hebisch
Subject: RE: sman and X libraries

> -----Original Message-----
> From:
> axiom-developer-bounces+bill.page1=synthesis.anikast.ca@nongnu
=synthesis.anikast.ca@nongnu.org] On Behalf Of Waldek Hebisch
> Sent: Wednesday, November 22, 2006 7:31 PM
> To: list
> Subject: sman and X libraries
>
> in version 288 I see:
>
> 2006-11-18  Bill Page  Bill Page
>
>        * Makefile.pamphlet (LDFLAGS): Add X11 libraries flags.
>        * Makefile.in: Regenerate.
>
> Why do we need this: AFAIK sman should not use any X libraries.
> In recent build 'ldd sman' gives me:
>
>         libXpm.so.4 => /usr/X11R6/lib64/libXpm.so.4
> (0x0000002a9566c000)
>         libSM.so.6 => /usr/X11R6/lib64/libSM.so.6 =
(0x0000002a95780000)
>         libICE.so.6 => /usr/X11R6/lib64/libICE.so.6
> (0x0000002a9588d000)
>         libX11.so.6 => /usr/X11R6/lib64/libX11.so.6
> (0x0000002a959af000)
>         libc.so.6 => /lib/libc.so.6 (0x0000002a95bc4000)
>         libXext.so.6 => /usr/X11R6/lib64/libXext.so.6
> (0x0000002a95dea000)
>         libXau.so.6 => /usr/X11R6/lib64/libXau.so.6
> (0x0000002a95efe000)
>         libXdmcp.so.6 => /usr/X11R6/lib64/libXdmcp.so.6
> (0x0000002a96001000)
>         libdl.so.2 => /lib/libdl.so.2 (0x0000002a96104000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)
>
> so now sman will refuse to run on a machine without X libraries.
>
> --

I think this change:

http://axiom.svn.sourceforge.net/viewvc/axiom/branches/build-improvement
s/src/sman/Makefile.in?view=diff&pathrev=288&r1=287&r2=288

is not correct. The patch I sent to Gaby is here:

http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00297.ht
ml

includes the line:

+LDFLAGS= -L${LIB} -lspad ${LDF} -lspad ${AXIOM_X11_LDFLAGS}

and

 <<sman>>=
 ${OUT}/sman: ${SMANOBJS} ${MIDOBJ}/sman.o
        @ echo 13 linking sman
-       @ ${CC} -o ${OUT}/sman ${MIDOBJ}/sman.o ${SMANOBJS}
+       @ ${CC} -o ${OUT}/sman ${MIDOBJ}/sman.o ${SMANOBJS} ${LDFLAGS}

but in fact ${AXIOM_X11_LDFLAGS} is not needed for sman.

I think we need a more "delicate" approach to providing the right
libraries in the right place, i.e. more autoconf variables.

\start
Date: 23 Nov 2006 02:49:34 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: sman and X libraries

Bill Page writes:

[...]

| http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00297.ht
| ml
| 
| includes the line:
| 
| +LDFLAGS= -L${LIB} -lspad ${LDF} -lspad ${AXIOM_X11_LDFLAGS}
| 
| and
| 
|  <<sman>>=
|  ${OUT}/sman: ${SMANOBJS} ${MIDOBJ}/sman.o
|         @ echo 13 linking sman
| -       @ ${CC} -o ${OUT}/sman ${MIDOBJ}/sman.o ${SMANOBJS}
| +       @ ${CC} -o ${OUT}/sman ${MIDOBJ}/sman.o ${SMANOBJS} ${LDFLAGS}
| 
| but in fact ${AXIOM_X11_LDFLAGS} is not needed for sman.
| 
| I think we need a more "delicate" approach to providing the right
| libraries in the right place, i.e. more autoconf variables.

In this case, would not leaving ${AXIOM_X11_LDFLAGS} out from LDFLAGS
solve the issue?  

\start
Date: Wed, 22 Nov 2006 20:58:31 -0500
From: Bill Page
To: list
Subject: RE: sman and X libraries

On Wednesday, November 22, 2006 8:26 PM I wrote:

> Waldek Hebisch wrote:
> > in version 288 I see:
> >
> > 2006-11-18  Bill Page  Bill Page
> >
> >        * Makefile.pamphlet (LDFLAGS): Add X11 libraries flags.
> >        * Makefile.in: Regenerate.
> >
> > Why do we need this: AFAIK sman should not use any X libraries.
> > In recent build 'ldd sman' gives me:
> >
> >         libXpm.so.4 => /usr/X11R6/lib64/libXpm.so.4
> > (0x0000002a9566c000)
> >         libSM.so.6 => /usr/X11R6/lib64/libSM.so.6
> (0x0000002a95780000)
> >         libICE.so.6 => /usr/X11R6/lib64/libICE.so.6
> > (0x0000002a9588d000)
> >         libX11.so.6 => /usr/X11R6/lib64/libX11.so.6
> > (0x0000002a959af000)
> >         libc.so.6 => /lib/libc.so.6 (0x0000002a95bc4000)
> >         libXext.so.6 => /usr/X11R6/lib64/libXext.so.6
> > (0x0000002a95dea000)
> >         libXau.so.6 => /usr/X11R6/lib64/libXau.so.6
> > (0x0000002a95efe000)
> >         libXdmcp.so.6 => /usr/X11R6/lib64/libXdmcp.so.6
> > (0x0000002a96001000)
> >         libdl.so.2 => /lib/libdl.so.2 (0x0000002a96104000)
> >         /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)
> >
> > so now sman will refuse to run on a machine without X libraries.
> >
> > --
>
> I think this change:
>
http://axiom.svn.sourceforge.net/viewvc/axiom/branches/build-improvement
s/src/sman/Makefile.in?view=diff&pathrev=288&r1=287&r2=288
>
> is not correct. The patch I sent to Gaby is here:
>
http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00297.ht
ml
>
> includes the line:
>
> +LDFLAGS= -L${LIB} -lspad ${LDF} -lspad ${AXIOM_X11_LDFLAGS}
>
> and
>
>  <<sman>>=
>  ${OUT}/sman: ${SMANOBJS} ${MIDOBJ}/sman.o
>         @ echo 13 linking sman
> -       @ ${CC} -o ${OUT}/sman ${MIDOBJ}/sman.o ${SMANOBJS}
> +       @ ${CC} -o ${OUT}/sman ${MIDOBJ}/sman.o ${SMANOBJS} ${LDFLAGS}
>
> but in fact ${AXIOM_X11_LDFLAGS} is not needed for sman.
>
> I think we need a more "delicate" approach to providing the right
> libraries in the right place, i.e. more autoconf variables.
>

On linux it seems to be be possible to remove LDFLAGS for sman,
sesseion and spadclient and rebuild the code in this directory
with no problems.

The patch was motivated by building Axiom on a Sun 280R (sparc,
64bit) Solaris 10 system with a GNU toolchain. My recollection
(not so clear now) is that I added LDFLAGS to the compiles
because of some missing dependencies which were satified by
this option. But a lot has changed in build-improvements since
then. I recently tried to repeat the build on the Sun with a
newer revision but failed and ran out of time.

I think the best thing is to remove the LDFLAGS like this:

[page@axiom-developer sman]$ pwd
/home/page/axiom.build-improvements/src/sman
[page@axiom-developer sman]$ svn diff *
Index: Makefile.pamphlet
==========================
==========================
=================
--- Makefile.pamphlet   (revision 301)
+++ Makefile.pamphlet   (working copy)
@@ -65,7 +65,7 @@
 \section{session}
 <<session>>=
 ${OUTLIB}/session: $(session_objects) $(session_DEPENDENCIES)
-       $(CC) $(session_objects) -o $@ $(session_LDADD) $(LDFLAGS) -o $@
+       $(CC) $(session_objects) -o $@ $(session_LDADD) -o $@
 @

 \section{nagman}
@@ -73,13 +73,13 @@
 necessary code (for instance, [[callnag]]).
 <<nagman>>=
 ${OUT}/nagman: $(nagman_objects) $(nagman_DEPENDENCIES)
-       $(CC) $(nagman_objects) -o $@ $(nagman_LDADD) $(LDFLAGS)
+       $(CC) $(nagman_objects) -o $@ $(nagman_LDADD)
 @

 \section{spadclient}
 <<spadclient>>=
 ${OUTLIB}/spadclient: $(spadclient_objects) $(spadclient_DEPENDENCIES)
-       $(CC) $(spadclient_objects) $(spadclient_LDADD) $(LDFLAGS) -o $@
+       $(CC) $(spadclient_objects) $(spadclient_LDADD) -o $@

 spadclient.o: ${INC}/useproto.h ${INC}/spadclient.H1
 @
@@ -87,7 +87,7 @@
 \section{sman}
 <<sman>>=
 ${OUT}/sman: $(sman_objects) $(sman_DEPENDENCIES)
-       $(CC) $(sman_objects) $(sman_LDADD) $(LDFLAGS) -o $@
+       $(CC) $(sman_objects) $(sman_LDADD) -o $@

 $(sman_objects): sman.h

[page@axiom-developer sman]$

-----

Then when I have more time (or Gaby) we can resolve the problem
with building on Sun a slightly different way.

\start
Date: 23 Nov 2006 09:03:19 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: make patch 50 work with the guessing package

Waldek Hebisch writes:

> Martin Rubey wrote:
> > Dear Tim,
> > 
> > could you explain the following diff:
> > 
> > diff -r /local/scratch/axiom/mnt/linux/doc/hypertex/pages/util.ht axiom49/mnt/linux/doc/hypertex/pages/util.ht
> > 435,439c435,437
> > < % 20030110000 tpd added a leading open paren
> > < \newcommand{\spadsyscom}[1]{){\tt #1}}
> > < % 20030110000 tpd these two commands are never used
> > < %\newcommand{\spadcmd}[1]{\spadsyscom{#1}}
> > < %\newcommand{\spadsys}[1]{\spadsyscom{#1}}
> > ---
> > > \newcommand{\spadsyscom}[1]{{\tt #1}}
> > > \newcommand{\spadcmd}[1]{\spadsyscom{#1}}
> > > \newcommand{\spadsys}[1]{\spadsyscom{#1}}
> > 
> > It breaks my guessing package!
> > 
> 
> Hej Martin, could you explan what problem this patch causes? 

When compiling patch 50, the rootpage cannot be displayed, at least when I add
my guessing package (i.e., building Axiom with it).

I'm not sure whether HyperDoc runs on Patch 50 unmodified, i.e., without my
guessing package, but I think it does not.

I could check tomorrow.



Martin

>  Macros \spadcmd and \spadsys are used on many Hypertex pages, without them
> Hypertex exits when you try to view such a page. Also, pages alredy contain
> closing parentheses in system commans so \spadsyscom sould not add the second
> one.

Exactly. That's why I don't understand at all why Tim commented out \spadcmd
and \spadsys and added the close parenthesis. In any case, using the unmodified
version, i.e.,

> > > \newcommand{\spadsyscom}[1]{{\tt #1}}
> > > \newcommand{\spadcmd}[1]{\spadsyscom{#1}}
> > > \newcommand{\spadsys}[1]{\spadsyscom{#1}}

works just perfect.

\start
Date: 23 Nov 2006 09:14:52 +0100
From: Martin Rubey
To: list
Subject: Debugging Boot

Dear all,

as you may have noticed, I discovered yet another bug (at least I think it's a
bug) in the output routines:

width((x**2)::OUTFORM) returns 5 instead of 2, and width((1/2)::OUTFORM)
returns (I think) also 5 instead of 1.

So I tried to debug the relevant code, which start at putWidth in
i-output.boot.

However, although I can say, for example

(1) -> putWidth((x**2)::OUTFORM)$Lisp

   (1)  ((** . 5) x 2)
                                                            Type: SExpression


I don't know how to call putWidth from within boot, i.e., after saying )fin.

I.e., how can I access, say, an Axiom variable from boot? I'd like to say
-------------------------------------------------------------------------------
p := (x**2)::OUTFORM

)fin

putWidth(p)
-------------------------------------------------------------------------------
or so.

\start
Date: Fri, 24 Nov 2006 07:05:48 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Building Axiom twice

> So, I believe we are now back to the question:  If AXIOMsys must be a
> copy of interpsys, why do we have both?

there should be a difference between obj/sys/interpsys and
mnt/bin/AXIOMsys. the difference is that interpsys is a build
image and AXIOMsys is a user image. 

the fact that they are the same is due to time pressure. 

i did not have time to polish the details like database
timestamps and the difference between interpsys and AXIOMsys.
there are still portions of the system that do not work
at all such as graphics on windows that need more attention.
it is hardly a surprise that "what is" and "what should be"
differ in the details. worse yet, there are small portions
of the system with insufficient documentation :-)

time, time, time.

\start
Date: 24 Nov 2006 16:58:17 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Building Axiom twice

Tim Daly writes:

| > So, I believe we are now back to the question:  If AXIOMsys must be a
| > copy of interpsys, why do we have both?
| 
| there should be a difference between obj/sys/interpsys and
| mnt/bin/AXIOMsys. the difference is that interpsys is a build
| image and AXIOMsys is a user image. 
| 
| the fact that they are the same is due to time pressure. 
| 
| i did not have time to polish the details like database
| timestamps and the difference between interpsys and AXIOMsys.

In my local tree, I have reorganized src/Makefile so that 

  * algebra/ uses interpsys for compilation
  * etc/ is built after algebra, then generates the database
  * AXIOMsys is built after etc/ complteted
  * input/ directly depends on AXIOMsys, and uses it for testing.

I'm testing.

\start
Date: 24 Nov 2006 16:34:08 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: make patch 50 work with the guessing package

Waldek Hebisch writes:

> You are invited to check wh-sandbox, but ultimatly you must decide which
> versions work for you...  FYI wh-sandbox now corrected this problem with
> util.ht.

great. In fact, I think I'm going to head for wh-sandbox. I love your HyperDoc
patches! (i.e. uses, users, dependents,...)

> > In any case, I think only the installed util.ht matters, since these files
> > are interpreted, aren't they?

> Well, if you want to run Axiom only installed version matters.  But I think
> that this case nicely illustrate problems with unused code -- after seemingly
> unrelated change the code may get used and produce wrong results.

I'm quite with you!

\start
Date: Fri, 24 Nov 2006 12:17:37 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: make patch 50 work with the guessing package

> Dear Waldek,
> 
> I'm a little confused now. I thought that I had no problems in patch 49, but
> only in patch 50. but looking at the patches, there doesn't seem to be a
> difference.
> 
> 
> > OK, I see:  The change that commented out the two commands has date
> > from 2003 and was applied to 'src/share/doc/hypertex/pages/util.ht'
> > long time ago. AFAICS Tim 'src/hyper/pages/util.ht' does not contain
> > this change so I thought that Tim reverted the change.  And I consequently
> > thougt that uncommenting back the commands caused problems for you.
> > 
> > ATM both build-improvements and wh-sandbox picked version were
> > the two commands are commented out, while in silver2 the two copies
> > are inconsistent.
> 
> Does this mean that there are different util.ht's around? I just looked at my
> local patch 49. The built axiom has in util.ht
>

Yes, silver2 has two versions of util.ht: one in 'src/hyper/pages/util.ht'
and the second one in 'src/share/doc/hypertex/pages/util.ht'.  As of
patch 50 silver2 installed version form 'src/share/doc/hypertex/pages/util.ht'.
I did not check, but I suspect that patch 49 intalled util.ht from
'src/hyper/pages/util.ht'. build-improvenemts and w-sandbox have only one
version, but picked the one installed by silver2...

 
> % redundant defns for system commands
> \newcommand{\syscom}[1]{\lispdownlink{)#1}{(|syscomPage| '|#1|)}}
> %
> \newcommand{\spadsyscom}[1]{{\tt #1}}
> \newcommand{\spadcmd}[1]{\spadsyscom{#1}}
> \newcommand{\spadsys}[1]{\spadsyscom{#1}}
> 
> which works for me. The other version does not.
> 
> I think the best thing would be if I check again tomorrow. Maybe you could just
> tell me which Axiom I should build together with my package. wh-sandbox? It
> would probably be better to have only one util.ht :-)
>

You are invited to check wh-sandbox, but ultimatly you must decide which
versions work for you...  FYI wh-sandbox now corrected this problem with
util.ht.
 
> In any case, I think only the installed util.ht matters, since these files are
> interpreted, aren't they?
> 

Well, if you want to run Axiom only installed version matters.  But
I think that this case nicely illustrate problems with unused code
-- after seemingly unrelated change the code may get used and
produce wrong results.

\start
Date: 24 Nov 2006 08:39:52 +0100
From: Martin Rubey
To: Gregory Vanuxem
Subject: Re: Debugging Boot

Gregory Vanuxem writes:

> Le jeudi 23 novembre 2006 =C3=A0 19:27 +0100, Vanuxem Gregory a =C3=A9cri=
t :
> > Le jeudi 23 novembre 2006 =C3=A0 09:14 +0100, Martin Rubey a =C3=A9crit=
 :
> >
> > [...]
> >
> > > I don't know how to call putWidth from within boot, i.e., after sayin=
g )fin.
> > >
> > > I.e., how can I access, say, an Axiom variable from boot? I'd like to=
 say
> > > ---------------------------------------------------------------------=
----------
> > > p := (x**2)::OUTFORM
> > >
> > > )fin
> > >
> > > putWidth(p)
> > > ---------------------------------------------------------------------=
----------
> > > or so.
>
> A more simple way (without history):
>
> (cddadr (find-if #'(lambda (a) (eql (car a) 'Q)) (caar |
> $InteractiveFrame|))))
>
> Where Q (or for example |a|) is the name of the variable. Sent even if you
> already have a response since the mailing list (my provider ?) has proble=
ms.

Thanks, that seems to do the trick. unfortunately, I seem to be unable to u=
se
boot-syntax in boot-mode :-(

For example, I'd like to interpret

  putWidth u is [[.,:n],:.] => n

but (is (|putWidth| u) [[.,:n],:.])

doesn't work...

Well, I hope still that I can find the bug now, thanks a lot!

\start
Date: 24 Nov 2006 08:34:16 +0100
From: Martin Rubey
To: list
Subject: Windows: Re: [#144 Domain abbreviation is no longer associated with filename]

Dear all,

maybe somebody here could help:


mathaction-bounces@axiom-developer.org (fhub) writes:

> Changes
> http://wiki.axiom-developer.org/144DomainAbbreviationIsNoLongerAssociated=
WithFilename/diff
>
> I=C2=B4m new to Axiom (Windows version), and I=C2=B4ve also this problem =
with ')edit
> filename.input'.  So what exactly should I do with this SPADEDIT.pamphlet
> file to solve this problem?  A few postings up I read: "Save the followin=
g as
> $AXIOM/lib/SPADEDIT and make it executable".  How can I make it executabl=
e?
>
> Sorry for my stupid questions, but as I said I=C2=B4m still a newbie in A=
xiom, and
> just want to try (and use) it like other CAS.
>
> Franz.

I have written my script for bash, and I don't know how to create an execut=
able
on windows either...

\start
Date: 24 Nov 2006 03:43:31 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Building Axiom twice

Tim Daly writes:

| > That begs the question: why not put those warm data and files in
| > interpsys too, so that we only have one image to care about?

In fact, warm data is already in interpsys, and AXIOMsys is just a
copy of interpsys.  

So, I believe we are now back to the question:  If AXIOMsys must be a
copy of interpsys, why do we have both?

I think interpsys is supposed to be just a bootstrapping system for
AXIOMsys, but currently it looks like AXIOMsys is just a copy.

| Because the "warm data" algebra has to be compiled before it can
| be loaded.

Yes, and that is what is done and it is loaded in interpsys.

[...]

| AXIOMsys is a "ship system" 

I believe "mamouth system" might be more appropriate :-) :-)

\start
Date: 24 Nov 2006 00:35:30 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Building Axiom twice

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Let me clarify this.  Assume you say "make -j 4".  Make creates a
| > jobserver and spawn sub-makes.  The sub-makes communicate with the
| > master make to ensure that at any given that, there are at most 4
| > sub-make processes running.  And that count does not include the
| > target firing recursive makes.  Furthermore, there is no
| > synchronisation in that loop that suggest that the directories will be
| > made sequentially. As a consequence, the sub-makes ae firex almost
| > simultaneously (the difference being the time it takes to initiate a
| > sub-make). 
| > 
| > That is how you see make fails in src/graph long before src/boot
| > completed. 
| >
| 
| Gaby, you are writing here about src/Makefile.  AFAICS src/Makefile
| does not use the recursive loop (it just sits unused at the end
| of the Makefile).

I spoke nonsense earlier -- there is no bug here.  Sorry.

The directories in src are not all independent, therefore the rule
cannot be

    all: all-recursive

The rule must be something like

    all: all-ax
    all-ax: <list of targets>

\start
Date: Thu, 23 Nov 2006 21:56:38 +0100
From: Gregory Vanuxem
To: Martin Rubey
Subject: Re: Debugging Boot

Le jeudi 23 novembre 2006 =E0 19:27 +0100, Vanuxem Gregory a =E9crit :
> Le jeudi 23 novembre 2006 =E0 09:14 +0100, Martin Rubey a =E9crit :
>
> [...]
>
> > I don't know how to call putWidth from within boot, i.e., after sayin=
g )fin.
> >
> > I.e., how can I access, say, an Axiom variable from boot? I'd like to=
 say
> > ---------------------------------------------------------------------=
----------
> > p := (x**2)::OUTFORM
> >
> > )fin
> >
> > putWidth(p)
> > ---------------------------------------------------------------------=
----------
> > or so.

A more simple way (without history):

(cddadr (find-if #'(lambda (a) (eql (car a) 'Q)) (caar |
$InteractiveFrame|))))

Where Q (or for example |a|) is the name of the variable. Sent even if
you already have a response since the mailing list (my provider ?) has
problems.

\start
Date: Fri, 24 Nov 2006 13:31:40 -0500
From: Andreas Kloeckner
To: list
Subject: [patch] Greek letters in TeX output

Hi all,

One small thing that always irked me about Axiom's tex output is that greek=

letters when used as variables don't get translated properly. Maxima gets
this right, and it makes the TeXmacs interface a lot more usable. This
prompted me to write the attached patch against tex.spad to fix this. I'd b=
e
happy to see this in the official version.

Andreas

--Boundary-01=_NqzZFFeYxBL2GOq
  charset="us-ascii";
  name="tex-greek.patch"
	filename="tex-greek.patch"

=2D-- /usr/share/axiom-20050901/src/algebra/tex.spad	2006-11-01 16:32:22.00=
0000000 -0500
+++ mytex.spad	2006-11-24 12:52:45.000000000 -0500
@@ -158,11 +158,27 @@
     specialStrings : L S :=
       ["cos", "cot", "csc", "log", "sec", "sin", "tan",
         "cosh", "coth", "csch", "sech", "sinh", "tanh",
=2D          "acos","asin","atan","erf","...","$","infinity"]
+          "acos","asin","atan","erf","...","$","infinity",
+            "alpha", "beta", "gamma", "delta", "epsilon",
+              "zeta", "eta", "theta", "iota", "kappa", "lambda",
+                "mu", "nu", "xi", "omikron", "pi", "rho", "sigma",
+                  "tau", "upsilon", "phi", "chi", "psi", "omega"
+                    "Alpha", "Beta", "Gamma", "Delta", "Epsilon",
+                      "Zeta", "Eta", "Theta", "Iota", "Kappa", "Lambda",
+                        "Mu", "Nu", "Xi", "Omikron", "Pi", "Rho", "Sigma",
+                          "Tau", "Upsilon", "Phi", "Chi", "Psi", "Omega"]
     specialStringsInTeX : L S :=
       ["\cos","\cot","\csc","\log","\sec","\sin","\tan",
         "\cosh","\coth","\csch","\sech","\sinh","\tanh",
=2D          "\arccos","\arcsin","\arctan","\erf","\ldots","\$","\infty"]
+          "\arccos","\arcsin","\arctan","\erf","\ldots","\$","\infty",
+            "\alpha", "\beta", "\gamma", "\delta", "\epsilon",
+              "\zeta", "\eta", "\theta", "\iota", "\kappa", "\lambda",
+                "\mu", "\nu", "\xi", "\omikron", "\pi", "\rho", "\sigma",
+                  "\tau", "\upsilon", "\phi", "\chi", "\psi", "\omega"
+                    "\Alpha", "\Beta", "\Gamma", "\Delta", "\Epsilon",
+                      "\Zeta", "\Eta", "\Theta", "\Iota", "\Kappa", "\Lamb=
da",
+                        "\Mu", "\Nu", "\Xi", "\Omikron", "\Pi", "\Rho", "\=
Sigma",
+                          "\Tau", "\Upsilon", "\Phi", "\Chi", "\Psi", "\Om=
ega"]

     -- local function signatures

\start
Date: Thu, 23 Nov 2006 19:27:05 +0100
From: Gregory Vanuxem
To: Martin Rubey
Subject: Re: Debugging Boot

Le jeudi 23 novembre 2006 =E0 09:14 +0100, Martin Rubey a =E9crit :

[...]

> I don't know how to call putWidth from within boot, i.e., after saying =
)fin.
>
> I.e., how can I access, say, an Axiom variable from boot? I'd like to s=
ay
> -----------------------------------------------------------------------=
--------
> p := (x**2)::OUTFORM
>
> )fin
>
> putWidth(p)
> -----------------------------------------------------------------------=
--------
> or so.

Here is a _dirty_ way to access them using the history mechanism
available in Axiom. If someone know how to access them easily (in a
different manner) I'm interested too.

First a quick overview of the the history, more precisely the
$internalHistoryTable boot variable and after a dirty way to work with
your interpreter variables.

Here I assume that you work with the history in memory (and not in a
file), which is the default. You can swith to it with:

)hist )mem

The $internalHistoryTable variable (|$internalHistoryTable| in Lisp)
contains all the history; if you want to print it issue in the
interpreter :

)boot $internalHistoryTable

All what I will say about this variable is approximate and represents
simple cases, I have to work on the history mechanism, but I'll do that
later. So please excuse and correct my errors if any.

It's a list of list (Lisp lists). Each list (entries in this mail) in
this list has the form:

((step_number "string"|(list_of_"string")
    (|variable-name| (|value| (Type) WRAPPED data))(+)

where

step_numer is an integer, the number displayed in
           the interpreter in front of the command and
           the result

"string"|(list_of_"string")
        is the Axiom command and if it is a list
        contains all the previous system command
        (')something foo') and commentaries ('--something')
        before it

(|variable-name| (|value| (Type) WRAPPED data))(+) is what
        you want, 'variable-name' is an interpreter variable
        name enclosed in vertical bars, '|value|' is |value|
        (can probably be different so beware). The rest is known,
        I presume, the value ('data'), its type 'Type' and
        WRAPPED. (+) means one or more times.

I hope you understand. Printing the $internalHistoryTable boot variable
will be more clear I think.

In the last item, if |variable-name| is % (not enclosed) this is the
output of your Axiom command (at step 'step_numer' of course). The list
of list is in reverse order. Now you have to know that there is an undo
mecanism in Axiom (costly in term of ressource) so at each Axiom command
all your variables are added to the entry added to the history so the (|
varia...) is repeated for each variables defined. So if you undo 5
commands, for example, with ')undo' Axiom will know their previous
values.

Ok, that's all :-)


So now with that you can "extract" what you want from this variable. For
example, in debugging context, if you DON'T define variables (the simple
case, the last item is not reapeated and it's % instead of |something|)
you can access the output value of the Axiom command at step n with :

(cdadr (third (nth (- n 1)  (reverse |$internalHistoryTable|))))

A simple defun (unwrapped output):

(defun uval (step)
  (|objValUnwrap| (cdadr
    (third (nth (- step 1)  (reverse |$internalHistoryTable|)))))))

And if you really want to define and access variables (quickly hacked,
quickly tested):

(defun var (a step)
  (|objValUnwrap| (cdadr
    (find-if #'(lambda (b) (and (listp b) (eq (car b) a)))
       (nth (- step 1)  (reverse |$internalHistoryTable|))))))

To access interpreter variable 'a' at step 3 :

(var '|a| 3)


Hope that helps,

Greg


PS : The interpreter store its variables somewhere but I don't know
where. If for example the history is kept in a file, accessing variables
(without undo) does not the involve the history file.

\start
Date: Fri, 24 Nov 2006 17:19:27 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: Debugging Boot

On November 24, 2006 2:40 AM Martin Rubey wrote:

> > > > I.e., how can I access, say, an Axiom variable from 
> > > > I'd like to say 
> -------------------------------------------------------------
> > > > p := (x**2)::OUTFORM
> > > > 
> > > > )fin
> > > > 
> > > > putWidth(p)
> > > > 
> --------------------------------------------------------------
> > 
> Gregory Vanuxem writes
> > A more simple way (without history):
> > 
> > (cddadr (find-if #'(lambda (a) (eql (car a) 'Q)) (caar |
> > $InteractiveFrame|))))
> > 
> > Where Q (or for example |a|) is the name of the variable. 
> 
> Thanks, that seems to do the trick. unfortunately, I seem to 
> be unable to use boot-syntax in boot-mode :-(

I think there might be some confusion. There is no such thing as
"boot-mode" in Axiom. When you see the BOOT> prompt you are
interacting with the Lisp intepreter. The prompt BOOT> indicates
that you are in the "BOOT" package, i.e. the BOOT namespace which
the default namespace for the Axiom interpreter. (Yes, it is a
confusing name.)

> 
> For example, I'd like to interpret
> 
>   putWidth u is [[.,:n],:.] => n
> 
> but (is (|putWidth| u) [[.,:n],:.])
> 
> doesn't work...

Keep in mind that BOOT is a *compiler*, not an interpreter. You
would first of all have to compile

  putWidth u is [[.,:n],:.] => n

into Lisp code. Then you could enter the result to be interpreted
by Lisp. But I think you would find that rather awkward.

I think what you probably want to do is keep the source code of
the entire routine that you are debugging in a file. Make changes
to it, re-compile it, and load the resulting lisp code - replacing
the previous function definintions. Then execute some test in
Axiom.

\start
Date: Thu, 23 Nov 2006 18:04:01 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Building Axiom twice

Gabriel Dos Reis wrote:
> Let me clarify this.  Assume you say "make -j 4".  Make creates a
> jobserver and spawn sub-makes.  The sub-makes communicate with the
> master make to ensure that at any given that, there are at most 4
> sub-make processes running.  And that count does not include the
> target firing recursive makes.  Furthermore, there is no
> synchronisation in that loop that suggest that the directories will be
> made sequentially. As a consequence, the sub-makes ae firex almost
> simultaneously (the difference being the time it takes to initiate a
> sub-make). 
> 
> That is how you see make fails in src/graph long before src/boot
> completed. 
>

Gaby, you are writing here about src/Makefile.  AFAICS src/Makefile
does not use the recursive loop (it just sits unused at the end
of the Makefile).  Concering make logic: my understanding is that
commands for single taget are executed as a shell script (make can
play some tricks here, but this should not affect the result).  In
particular, if you write a shell loop the loop executes sequentially.
The main makefile has such loop and uses it.
 
> | I would put this in a diffent way: you have two rules which invoke
> | make of main target in src subdirectory.  The first is the recursive
> | rule, the second one is via src stamp.  Currently the second rule
> | can only fire after the first run has finished.  But if you allow
> | both rules to run in parallel then you will get a mess in src.
> 
> Not if the dependencies are set up correctly.  
> 

The main Makefile is essentially as follows:

all : all-recursive

all-ax: src/stamp

src/stamp:
	cd src && make

all-recursive:
	cd src && make all
	make all-ax

I do not see how you can set up dependencies to correct the above
Makefile (assuming that in src "make all" and "make" give the
same effect).

Now, if you prefer stamps, you can use then, but then drop all-recursive
part.
 
\start
Date: Thu, 23 Nov 2006 14:06:38 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: Building Axiom twice

root wrote:
> axiom could be so much faster if we got the gcl_collectfn mechanism
> fully re-implemented. the lisp type optimization code can eliminate
> hundreds of intructions per function call and axiom lives and breathes
> by function calling. however to fully take advantage of that you 
> either need to do multiple passes or cache the type information
> from previous builds. doing this in parallel makes my hair hurt.
>

Will this accelerate Spad compiler or is it only usefull to algebra?
 
> parallel builds cause the make to go marginally faster but my 
> feeling is that the time-to-build is not important for two reasons.
> 
> first, a properly done make tree need only rebuild changed files
> and their dependent files. when builds used to take 3 weeks from
> scratch i was able to build changes to the system in 1/2 hour or so
> for small changes using the current makefile structure. that is the
> whole reason to use make in the first place. otherwise it just makes
> sense to have a linear script.
> 
> second, only developers care about build time. the end user should
> never see it (or maybe see it once). i'd rather spend a whole day
> doing a build and get a highly optimized algebra system than spend
> 1 hour and get a slow algebra system. and that's saying a lot because
> all i ever do is build and rebuild the damn thing.
> 
> fast algebra is much more important than fast builds.
> 

I feel that you are misallocating resources.  For most of users Axiom
is "fast enough".   OTOH if you compare polynomial factorization in
Axiom with NTL you will notice that Axiom is slower and the gap get
wider on bigger inputs.  NTL is written in C++, but this gives only
little gain.  The main reason is that NTL uses algorithm with better
asymptitic complexity.  So, Axiom also needs faster algorithms
and here build time matters very much.

I would say that if re-making takes more than 1 second then it is
worth working on shortening build time -- while you time saving
from 1 second re-make compared to say 15 seconds is negligible
longer re-make distracts developers attension, causing much bigger
indirect loss.

Also, good practice requires full build before commiting a patch,
so time of full build matters too.  And do not forget about testing
-- we should test freshly build system.

Do not get me wrong: it is nice to have fast algebra.  But you need
developers to make algebra faster, and fast build are necessary to
effectively use developers time (and to get them in the first place).

\start
Date: Thu, 23 Nov 2006 13:46:03 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: Building Axiom twice

> > That begs the question: why not put those warm data and files in
> > interpsys too, so that we only have one image to care about?
> 
> Because the "warm data" algebra has to be compiled before it can
> be loaded. PositiveInteger needs to be compiled in interpsys.
>

AFAICS currently interpsys and AXIOMsys preload the same data ("warm.data"
just preloads a bunch of entries in topics hashtable)
 
> AXIOMsys is a "ship system" and it preloaded the previously compiled
> PositiveInteger as well as up-to-date databases. There is a check
> (currently broken) that the timestamp in the database files is 
> checked against the timestamp of the database files which are 
> preloaded into AXIOMsys. If the time stamps of the external database
> files match the preloaded databases then the external files are ignored.
> If not the external databases are consulted. You can see this because
> axiom currently mutters about "reloading" databases when it starts.
> This SHOULD be the exception but, as I said, the timestamp mechanism
> is broken.
> 

AFAICS the timestamp mechanism works fine, we just need a little change
to Makefiles to preload the new databases.  If you check current
build-improvements you will see that messages about databases are gone.
And the whole tread started discussing this patch.

\start
Date: Thu, 23 Nov 2006 13:32:55 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Building Axiom twice

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
>
> | FYI I changed lsp Makefile to pass '-j 1' to GCL because ATM
> | on my dual core machines build fails using system GCL (it works using
> | bundled GCL, also system GCL on single core machines works fine). 
> 
> We can have the lsp Makefile say .NOTPARALLEL for the GCL targets so
> that GCL is not attempted in parallel.
>

Yes, that would be good for testing parallel builds
 
> | My impression is that you will loose most opportunities for
> | parallelism: recursive logic is seqential and dependence via stamps
> | means that one subdirectory must finish before another starts. 
> 
> Which recursive logic?  
> On purpose I did not write a for loop, rather, I listed the targets.
> Then it is necessary that the dependencies are correct.  
> 

Hmm, I see:

        for subdir in $$list; do \
           echo "Making $$target in $$subdir"; \
....


This is a loop over subdirectories.  So you can do main target in
parallel with dvi target, but subdirectories run sequentially.

I would put this in a diffent way: you have two rules which invoke
make of main target in src subdirectory.  The first is the recursive
rule, the second one is via src stamp.  Currently the second rule
can only fire after the first run has finished.  But if you allow
both rules to run in parallel then you will get a mess in src.

\start
Date: Thu, 23 Nov 2006 06:46:01 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: Re: make patch 50 work with the guessing package

> Exactly. That's why I don't understand at all why Tim commented out \spadcmd
> and \spadsys and added the close parenthesis. In any case, using the unmodified
> version, i.e.,
> 
> > > > \newcommand{\spadsyscom}[1]{{\tt #1}}

hmmm, i have no idea why i might have changed this;
which perfectly illustrates two important points...

1) it is important to understand the system before changing it
2) it is important to document the "why" of changes.

clearly i blew it on both points.
mea culpa.

util.ht should be a pamphlet file so we can document our understanding
of the macros and the changes to them but i haven't gotten around
to converting it yet.

\start
Date: Thu, 23 Nov 2006 11:35:11 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: make patch 50 work with the guessing package

Martin Rubey wrote:
> Waldek Hebisch writes:
> 
> > Martin Rubey wrote:
> > > Dear Tim,
> > > 
> > > could you explain the following diff:
> > > 
> > > diff -r /local/scratch/axiom/mnt/linux/doc/hypertex/pages/util.ht axiom49/mnt/linux/doc/hypertex/pages/util.ht
> > > 435,439c435,437
> > > < % 20030110000 tpd added a leading open paren
> > > < \newcommand{\spadsyscom}[1]{){\tt #1}}
> > > < % 20030110000 tpd these two commands are never used
> > > < %\newcommand{\spadcmd}[1]{\spadsyscom{#1}}
> > > < %\newcommand{\spadsys}[1]{\spadsyscom{#1}}
> > > ---
> > > > \newcommand{\spadsyscom}[1]{{\tt #1}}
> > > > \newcommand{\spadcmd}[1]{\spadsyscom{#1}}
> > > > \newcommand{\spadsys}[1]{\spadsyscom{#1}}
> > > 
> > > It breaks my guessing package!
> > > 
> > 
> > Hej Martin, could you explan what problem this patch causes? 
> 
> When compiling patch 50, the rootpage cannot be displayed, at least when I add
> my guessing package (i.e., building Axiom with it).
> 
> I'm not sure whether HyperDoc runs on Patch 50 unmodified, i.e., without my
> guessing package, but I think it does not.
> 
> I could check tomorrow.
> 
> 
> 
> Martin
> 
> >  Macros \spadcmd and \spadsys are used on many Hypertex pages, without them
> > Hypertex exits when you try to view such a page. Also, pages alredy contain
> > closing parentheses in system commans so \spadsyscom sould not add the second
> > one.
> 
> Exactly. That's why I don't understand at all why Tim commented out \spadcmd
> and \spadsys and added the close parenthesis. In any case, using the unmodified
> version, i.e.,
> 
> > > > \newcommand{\spadsyscom}[1]{{\tt #1}}
> > > > \newcommand{\spadcmd}[1]{\spadsyscom{#1}}
> > > > \newcommand{\spadsys}[1]{\spadsyscom{#1}}
> 
> works just perfect.
> 

OK, I see:  The change that commented out the two commands has date
from 2003 and was applied to 'src/share/doc/hypertex/pages/util.ht'
long time ago. AFAICS Tim 'src/hyper/pages/util.ht' does not contain
this change so I thought that Tim reverted the change.  And I consequently
thougt that uncommenting back the commands caused problems for you.

ATM both build-improvements and wh-sandbox picked version were
the two commands are commented out, while in silver2 the two copies
are inconsistent.

In fact, I would like to do the following change to build-improvements
and wh-sandbox, but your message suggested that you have problems with it.

--- silver2/src/share/doc/hypertex/pages/util.ht	2006-10-27 14:01:37.000000000 +0200
+++ silver2/src/hyper/pages/util.ht	2006-10-27 13:57:59.000000000 +0200
@@ -432,11 +432,9 @@
 % redundant defns for system commands
 \newcommand{\syscom}[1]{\lispdownlink{)#1}{(|syscomPage| '|#1|)}}
 %
-% 20030110000 tpd added a leading open paren
-\newcommand{\spadsyscom}[1]{){\tt #1}}
-% 20030110000 tpd these two commands are never used
-%\newcommand{\spadcmd}[1]{\spadsyscom{#1}}
-%\newcommand{\spadsys}[1]{\spadsyscom{#1}}
+\newcommand{\spadsyscom}[1]{{\tt #1}}
+\newcommand{\spadcmd}[1]{\spadsyscom{#1}}
+\newcommand{\spadsys}[1]{\spadsyscom{#1}}
 
 
 % Following macros should be phased out in favor of ones above:

\start
Date: 23 Nov 2006 11:56:12 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: make patch 50 work with the guessing package

Dear Waldek,

I'm a little confused now. I thought that I had no problems in patch 49, but
only in patch 50. but looking at the patches, there doesn't seem to be a
difference.


> OK, I see:  The change that commented out the two commands has date
> from 2003 and was applied to 'src/share/doc/hypertex/pages/util.ht'
> long time ago. AFAICS Tim 'src/hyper/pages/util.ht' does not contain
> this change so I thought that Tim reverted the change.  And I consequently
> thougt that uncommenting back the commands caused problems for you.
> 
> ATM both build-improvements and wh-sandbox picked version were
> the two commands are commented out, while in silver2 the two copies
> are inconsistent.

Does this mean that there are different util.ht's around? I just looked at my
local patch 49. The built axiom has in util.ht

% redundant defns for system commands
\newcommand{\syscom}[1]{\lispdownlink{)#1}{(|syscomPage| '|#1|)}}
%
\newcommand{\spadsyscom}[1]{{\tt #1}}
\newcommand{\spadcmd}[1]{\spadsyscom{#1}}
\newcommand{\spadsys}[1]{\spadsyscom{#1}}

which works for me. The other version does not.

I think the best thing would be if I check again tomorrow. Maybe you could just
tell me which Axiom I should build together with my package. wh-sandbox? It
would probably be better to have only one util.ht :-)

In any case, I think only the installed util.ht matters, since these files are
interpreted, aren't they?

\start
Date: Thu, 23 Nov 2006 05:42:56 -0500
From: Alfredo Portes
To: Martin Rubey
Subject: Re: make patch 50 work with the guessing package

Hi Martin, Waldek

> I'm not sure whether HyperDoc runs on Patch 50 unmodified, i.e., without my
> guessing package, but I think it does not.

HyperDoc in Patch 50 runs when compiled the first time. After
executing the first part of adding your guessing package, then
HyperDoc does not work.

\start
Date: Sat, 25 Nov 2006 02:03:12 +0100
From: Gregory Vanuxem
To: list
Subject: PATCH : parenthesis problem in	src/interp/nocompil.lisp.pamphlet

--- src/interp/nocompil.lisp.pamphlet.old
+++ src/interp/nocompil.lisp.pamphlet
@@ -85,9 +85,10 @@
 (defun verbos (arg))
 ;  (format t "verbos called with ~A~%" arg))
 
-(defun enable-backtrace (&rest arg))
+(defun enable-backtrace (&rest arg)
 #+:ccl
-  (format t "protected-symbol-warn called with ~A~%" arg))
+  (format t "protected-symbol-warn called with ~A~%" arg)
+ )
 
 ;; NOTE: JoinInner is defined in CATEGORY BOOT
 ;; following code needs to run interpreted to overcome arglist length
limits

\start
Date: Fri, 24 Nov 2006 13:26:54 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Wrong prototype

Gaby, your recent prototype convertion lost return type of spad_error_handler.
I do not understand why Debian gcc-4.1.2 (prerelease) did report this, but
gcc-3.3.5 complained.  The following adds the return type back:


--- wh-sandbox.bb/src/hyper/lex.pamphlet	2006-11-24 11:24:10.000000000 +0100
+++ wh-sandbox/src/hyper/lex.pamphlet	2006-11-24 13:20:57.000000000 +0100
@@ -820,6 +820,7 @@
 
 
 #ifndef HTADD
+static void
 spad_error_handler(void)
 {
     /* fprintf(stderr, "got a spad error\n"); */

\start
Date: 25 Nov 2006 04:26:50 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Wrong prototype

Waldek Hebisch writes:

| Gaby, your recent prototype convertion lost return type of spad_error_handler.
| I do not understand why Debian gcc-4.1.2 (prerelease) did report this, but
| gcc-3.3.5 complained.  The following adds the return type back:
| 

This is OK as obvious.  Please check it in.
Thanks!

\start
Date: 25 Nov 2006 09:58:21 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Building Axiom twice

Dear Waldek,

Waldek Hebisch writes:

> The main reason is that NTL uses algorithm with better asymptitic complexity.
> So, Axiom also needs faster algorithms and here build time matters very much.

I disagree here. When developing new algebra, I will not immediately integrate
it into the system, i.e., build time doesn't matter at all.

What does matter, and in fact, it is a pain currently, is time needed by the
compiler. That's why I switched to Aldor.

The compiler has the misfeature of taking an incredibly long time on certain
functions, and the amount of time needed changes when you shift the function
definition towards the end of the package, say. For an example, try to compile
my guessing package, with ord1, ord2, deg1, deg2 defined at other places (i.e.,
just before they are needed). I suspect that the reason is that SPAD (the
compiler) remembers imports (since they are mostly done implicitely in SPAD)
and has to try them all before succeeding.

I think time should be mostly spent on documenting and improving compiler, but
I must say that I'm looking forward to the point where adding algebra is
possible :-) 

(currently, it is not possible to add my guessing package, since we would need
to ship a new database as well... As you know, I think the solution would be to
start with an almost empty database and rebuild the database after each layer.)

\start
Date: 25 Nov 2006 10:05:16 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: Debugging Boot

Bill Page writes:

> I think there might be some confusion. There is no such thing as
> "boot-mode" in Axiom. When you see the BOOT> prompt you are
> interacting with the Lisp intepreter. The prompt BOOT> indicates
> that you are in the "BOOT" package, i.e. the BOOT namespace which
> the default namespace for the Axiom interpreter. (Yes, it is a
> confusing name.)

thanks for the clarification.

> I think what you probably want to do is keep the source code of the entire
> routine that you are debugging in a file. Make changes to it, re-compile it,
> and load the resulting lisp code - replacing the previous function
> definintions. Then execute some test in Axiom.

OK. Could you please send me instructions (if you know how to do it).

* I'd like to debug i-output

* how can I display debugging information in boot, i.e., something like
  output("Hi, I'm here") and output(some-variable).

\start
Date: Sat, 25 Nov 2006 11:57:27 +0100
From: Gregory Vanuxem
To: list
Subject: PATCH : parenthesis problem in	src/interp/monitor.lisp.pamphlet

--- src/interp/monitor.lisp.pamphlet.old
+++ src/interp/monitor.lisp.pamphlet
@@ -511,7 +511,7 @@
  (eval `(trace (,name :cond (progn (monitor-incr ',name) nil))))
  (setf (gethash name *monitor-table*)
   (make-monitor-data 
-     :name name :count 0 :monitorp t :sourcefile sourcefile)))))
+     :name name :count 0 :monitorp t :sourcefile sourcefile)))
 
 (defun monitor-delete (fn)
  "delete a function from the monitor table"

==================================================================

These parenthesis problems (nocompil.lisp (previously sent patch) and
this one) prevent loading of these files in, at least, SBCL, GCL-2.7.0
(CVS HEAD) and clisp. 

\start
Date: Sat, 25 Nov 2006 12:25:32 +0100
From: Gregory Vanuxem
To: Martin Rubey
Subject: Re: Debugging Boot

Le samedi 25 novembre 2006 =E0 10:05 +0100, Martin Rubey a =E9crit :

[...]


> * how can I display debugging information in boot, i.e., something like
>   output("Hi, I'm here") and output(some-variable).

This is very easy, if you use function names in uppercase, for example
FOO(x), they will be translated to a Lisp call without vertical bars
enclosing the function name so in this example translated to (FOO x):

PRINT("I'm here") or PRINT(my-variable)
Strings will be enclosed with vertical bars, to avoid this use
PRINT('"salut")

Otherwise there are some outputting functions in boot, they generally
begin with 'say' for example sayBrightly. Personally I use PRINT in your
case.

\start
Date: Sun, 26 Nov 2006 03:05:18 +0100
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: branches/wh-sandbox

Le samedi 25 novembre 2006 =E0 15:42 -0800, whebisch@users.sourceforge.ne=
t
a =E9crit :
> Revision: 317
>           http://svn.sourceforge.net/axiom/?rev=317&view=rev
> Author:   whebisch
> Date:     2006-11-25 15:42:55 -0800 (Sat, 25 Nov 2006)

> +	* src/interp/setq.lisp.pamphlet: set |$noSubsumption| to t.


Do you know the meaning of this variable ? It seems to me that some
categories/domains/packages modify it but I have to say that I know
nothing about it.

\start
Date: Sat, 25 Nov 2006 23:24:42 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: Debugging Boot

On November 25, 2006 4:05 AM Martin Rubey wrote:

>... 
> Bill Page writes:
> 
> > I think what you probably want to do is keep the source 
> > code of the entire routine that you are debugging in a file.
> > Make changes to it, re-compile it, and load the resulting
> > lisp code - replacing the previous function definintions.
> > Then execute some test in Axiom.
> 
> OK. Could you please send me instructions (if you know how to
> do it).
>

"(if you know how to do it.)" ???

:-(

Have you looked at the Axiom Wiki pages about boot?

http://wiki.axiom-developer.org/BootProgramming
 
> * I'd like to debug i-output
> 
> * how can I display debugging information in boot, i.e., 
>   something like output("Hi, I'm here") and output(some-variable).
> 

See the example at:

http://wiki.axiom-developer.org/SandBoxIOutput

The commands executed by MathAction to compile and load modified
BOOT code for i-ouput.boot are equivalent to the following:

  )lisp (boottran::boottocl "src/interp/i-output2.boot")
  )lisp (load (compile-file "int/interp/i-output2.clisp"))

Note that there is something hard coded in the old boot compiler
that insists on putting the compiler output in 'int/interp' in
the Axiom source tree.

Please let me know if this example is clear.

You should also feel obligated to add NEW and BETTER examples
to the Axiom wiki. :-)

\start
Date: Sun, 26 Nov 2006 11:20:29 +0100
From: Ralf Ralf Hemmecke
To: list
Subject: NNI to SingleInteger

Hello,

does somebody know the proper method/function to convert between

NNI, PI, SingleInteger, Integer

Complete conversion graph would be interesting.
Note that I am *not* interested in interpreter stuff. I want to know the 
explicit functions that I have to call in a .as file, i.e. the functions 
should live inside libaxiom.al. If possible I want to avoid the use of 
"pretend".

Yesterday, I have tried

coerce: % -> PrimitiveArray S;

from Tuple(S), but the Aldor compiler doesn't seem to know that this 
coercion exists. Any hints?

Furthermore, Tuple in Axiom has the function "select" for accessing the 
n-th element of the tuple. Unfortunately, "select" is a reserved keyword 
in Aldor. What should I do?

Thank you in advance.

\start
Date: Sun, 26 Nov 2006 13:41:19 +0200
From: Jurgis Pralgauskis
To: list
Subject: expression parse tree API?

Hello,

could smb point me how to access the formula parse tree.

what I really want, is to make derivative exercise tool.
which would do the differentiation of (complex) formulas step by step.
And I want to use python :)

for example  Maple has it
http://www.adeptscience.co.uk/products/mathsim/maple/whatsnew/maple_presentation.html#MapleAutoBookmark9 


ctrl+F: ShowSteps
or http://www.google.lt/search?q=Student[Calculus1]+ShowSteps

I'd like to have parse-tree structure, based on differentiation by
variable (x) ,
each next depth level would mean a step according to
http://en.wikipedia.org/wiki/Chain_rule

so terminal/final nodes should have 'x' or plain numeric expression,
and pre-terminal nodes should have simple differentiatable functions
a subset of http://en.wikipedia.org/wiki/Table_of_derivatives,
which contain x and numeric values/variables

I found sth similar what I want in java..
http://www.singularsys.com/jep/doc/html/advanced.html

I also asked in SAGE forum, but seems they don't deal with expression
parsing
http://groups.google.com/group/sage-support/browse_thread/thread/96686f9ff4ba3711
SAGE folks referenced Maxima.. but I want python, and as I know Axiom is
made with python (Maxima probably with C)..

\start
Date: 26 Nov 2006 13:07:33 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: NNI to SingleInteger

Ralf Ralf Hemmecke writes:

> Hello,
> 
> does somebody know the proper method/function to convert between
> 
> NNI, PI, SingleInteger, Integer

I guss to go from x: NNI to SingleInteger you have to say

retract(x::INT)@SingleInteger

Usually, in axiom, if a "coercion" (in the general, not Axiom sense of the
word) cannot always been done, as for example from INT to NNI or from INT to
SINT, you have to use "retract".

There are two very nice categories, namely KOERCE and RETRACT. Unfortunately,
not all domains have these categories, although they should. The reason is,
that SPADdoesn't know extend.

As soon as extend is available, this must be changed, since it makes
"categorial" programming possible.

I guess there is no "retract" in libaldor?

\start
Date: Sun, 26 Nov 2006 14:53:49 +0100 (CET)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: branches/wh-sandbox

Vanuxem Gregory wrote:
> Le samedi 25 novembre 2006 ? 15:42 -0800, Waldek Hebisch
> a =E9crit :
> > Revision: 317
> >           http://svn.sourceforge.net/axiom/?rev=317&view=rev
> > Author:   whebisch
> > Date:     2006-11-25 15:42:55 -0800 (Sat, 25 Nov 2006)
>
> > +	* src/interp/setq.lisp.pamphlet: set |$noSubsumption| to t.
>
>
> Do you know the meaning of this variable ? It seems to me that some
> categories/domains/packages modify it but I have to say that I know
> nothing about it.
>

AFAICS this variable (when set to nil) enables using members of
unions in some places where union is expected.  I suspect that it
has only effect on function signatures.  In particular, when this
variable is set to nil Axiom may choose different versions of
overloaded functions.

Note that the change I did is a no-op: |$noSubsumption| were set
to t by xrun.boot.pamphlet.

\start
Date: Sun, 26 Nov 2006 08:51:27 -0600 (CST)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: Boot

On Tue, 21 Nov 2006, Page, Bill wrote:

| Gaby,
|
| If you plan to go ahead with the proposed documentation of
| "new boot" (aka. SHOE) I would be delighted to help. Perhaps
| you have said before, but could you please explain how to
| call SHOE from the command line?

The current document script uses bootsys (the translator for
SHOE).  Currently, we do not install bootsys, nor is it
part of AXIOMsys.  Ideally, I would like to see bootsys replace
the old Boot translator.

As an intermediate solution, we could install bootsys, then
you would translate foo.boot with either

  document --tag=boot --mode=translaye bootsys foo.boot

and that will produce foo.clisp in the same directory, or
you can say directly

   echo '(boottran::boottocl "foo.boot")' | bootsys

If you say

   echo '(boottran::boottoclc "foo.boot")' | bootsys

then the Boot code is included as comment -- but this is is
wiki stuff, who cares?

| What I would like to do is to provide a environment in the
| Axiom Wiki, e.g.
|
|   \begin{shoe}
|   ....
|   \end{shoe}
|
| where we can compile examples of SHOE code. There is already
| such an environment for boot
|
|   \begin{boot}
|   ....
|   \end{boot}
|
| See
|
| http://wiki.axiom-developer.org/BootProgramming

That is very interesting.

| I am very interested in your comment about the relationship
| between SHOE and Haskell.

Basically, SHOE provides a way to define algebraic datatype and way to
deconstruct values of such type.  (There is no type-checking at the
moment, but it would not be hard to implement).  Unlike Haskell,
Shoe does not support (yet) function definition by separate
equations: you have to use a single case expression (which is morally
what Core Haskell does).

   structure BinTree ==
       Nil                         -- the null node
       Node(Val, BinTree, BinTree) -- or a value and a pair of
				   -- binary tree

   depth x ==
      case x of
	  Nil => 0
	  Node(x, l, r) => 1 + MAX(depth l, depth r)

   depth Node(Nil, Node(2, Nil, Nil), Nil)


Notice how the compilation of the body of the structure BinTree
is almost like one would have expected (from a naive translation
point of view).  If properly augmented, Shoe can serve as a good
support for a class on implementation of function languages along the
lines of the now classic "The Implementation of Functional
Proramming Languages" (out of print, but you can download it from the
website)

  http://research.microsoft.com/~simonpj/Papers/slpj-book-1987/index.htm

\start
Date: 26 Nov 2006 16:06:15 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Debugging Boot

Bill Page writes:

| On November 25, 2006 4:05 AM Martin Rubey wrote:
| 
| >... 
| > Bill Page writes:
| > 
| > > I think what you probably want to do is keep the source 
| > > code of the entire routine that you are debugging in a file.
| > > Make changes to it, re-compile it, and load the resulting
| > > lisp code - replacing the previous function definintions.
| > > Then execute some test in Axiom.
| > 
| > OK. Could you please send me instructions (if you know how to
| > do it).
| >
| 
| "(if you know how to do it.)" ???
| 
| :-(
| 
| Have you looked at the Axiom Wiki pages about boot?
| 
| http://wiki.axiom-developer.org/BootProgramming
|  
| > * I'd like to debug i-output
| > 
| > * how can I display debugging information in boot, i.e., 
| >   something like output("Hi, I'm here") and output(some-variable).
| > 
| 
| See the example at:
| 
| http://wiki.axiom-developer.org/SandBoxIOutput
| 
| The commands executed by MathAction to compile and load modified
| BOOT code for i-ouput.boot are equivalent to the following:
| 
|   )lisp (boottran::boottocl "src/interp/i-output2.boot")

What happens if you just say:

   )lisp (boottran::boot "src/interp/i-output2.boot")

?

\start
Date: Sun, 26 Nov 2006 11:01:25 +0100
From: Jean-Pierre Vial
To: list
Subject: build axiom on amd64 (= x86_64) linux Suse/Novell

since the linux binary version does not work
on my Suse/Novell 10.1 amd64 machine
I had to build from source (source from svn, silver version).
I met two problems, fortunately not too difficult:

(1)
 configure just identifies the system as linux, and this leads to
linking errors. The makefile.pamphlet must be modified
so that the variables XLIB and LDF point to 64 bits libraries
XLIB='/usr/x11R6/lib64'
LDF=' -L /usr/x11R6/lib64 -L/usr/lib64 -L/lib64'

and CCF must be supplemented with "-m64"
to make sure that everything is coherent.

(2)
in (axiomdir)/src/doc/bookvol1.pamphlet
two definitions must be erased or commented-out because they are already
in axiom.sty

%% spadgraph are the actual text that you type at the axiom prompt for draw
\newcommand{\spadgraph}[1]%
{\begin{flushleft}{\tt #1}\end{flushleft}\vskip .1cm }

% spadfunFrom records the function name and domain in the index
\newcommand{\spadfunFrom}[2]{{\bf #1}\index{#1 @\begingroup \string\bf{}
#1 \endgroup}\index{#2}}

When they are present, latex hangs, without error message since it is
run in non-interactive mode.

\start
Date: Sun, 26 Nov 2006 18:41:25 +0200
From: Jurgis Pralgauskis
To: list
Subject: expression parse tree API?

Hello,

could smb point me how to access the formula parse tree.

what I really want, is to make derivative exercise tool.
which would do the differentiation of (complex) formulas step by step.
And I want to use python :)

for example  Maple has it
http://www.adeptscience.co.uk/products/mathsim/maple/whatsnew/maple_presentation.html#MapleAutoBookmark9 



ctrl+F: ShowSteps
or http://www.google.lt/search?q=Student[Calculus1]+ShowSteps

I'd like to have parse-tree structure, based on differentiation by
variable (x) ,
each next depth level would mean a step according to
http://en.wikipedia.org/wiki/Chain_rule

so terminal/final nodes should have 'x' or plain numeric expression,
and pre-terminal nodes should have simple differentiatable functions
a subset of http://en.wikipedia.org/wiki/Table_of_derivatives,
which contain x and numeric values/variables

I found sth similar what I want in java..
http://www.singularsys.com/jep/doc/html/advanced.html

I also asked in SAGE forum, but seems they don't deal with expression
parsing
http://groups.google.com/group/sage-support/browse_thread/thread/96686f9ff4ba3711
SAGE folks referenced Maxima.. but I want python, and as I know Axiom is
made with python (Maxima probably with C)..

\start
Date: Sun, 26 Nov 2006 13:32:43 -0500
From: Bill Page
To: Jurgis Pralgauskis
Subject: RE: expression parse tree API?

On November 26, 2006 11:41 AM Jurgis Pralgauskis wrote:

> I also asked in SAGE forum, but seems they don't deal with
> expression parsing
http://groups.google.com/group/sage-support/browse_thread/thread/96686f9f=
f4b
a3711
> SAGE folks referenced Maxima.. but I want python, and as
> I know Axiom is made with python (Maxima probably with C)..

??? Both Axiom and Maxima are written in Lisp.

\start
Date: Sun, 26 Nov 2006 13:38:40 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Debugging Boot

On November 26, 2006 10:06 AM Gaby asked:

> ...
> Bill Page wrote: 
> | See the example at:
> | 
> | http://wiki.axiom-developer.org/SandBoxIOutput
> | 
> | The commands executed by MathAction to compile and load modified
> | BOOT code for i-ouput.boot are equivalent to the following:
> | 
> |   )lisp (boottran::boottocl "src/interp/i-output2.boot")
> 
> What happens if you just say:
> 
>    )lisp (boottran::boot "src/interp/i-output2.boot")
> 
> ?
>

Hmmm...
 
(1) -> )lisp (boottran::boot "src/interp/i-output2.boot")

   >> System error:
   The function BOOTTRAN::BOOT is undefined.

(1) ->

---------

What were you expecting?

\start
Date: 26 Nov 2006 19:37:22 +0100
From: Gabriel Dos Reis
To: Jean-Pierre Vial
Subject: Re: build axiom on amd64 (= x86_64) linux Suse/Novell

Salut Jean-Pierre,

Jean-Pierre Vial writes:

| since the linux binary version does not work
| on my Suse/Novell 10.1 amd64 machine
| I had to build from source (source from svn, silver version).
| I met two problems, fortunately not too difficult:

[...]

Thanks for your report.

Most of these are known issues with the current official release of
Axiom.  They are being worked on.  

Configure has been improved to detect the various bits and communicate
with the C compiler and linker.  The LaTeX issue has also been
corrected.  I build Axiom on an x86_64 running SUSE linux 10.1 on
a daily basis.  If you're adventurous you might want to test the
build-improvements branch.

\start
Date: Sun, 26 Nov 2006 20:57:55 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Debugging Boot

Le dimanche 26 novembre 2006 =E0 13:38 -0500, Bill Page a =E9crit :
> On November 26, 2006 10:06 AM Gaby asked:
>
> > ...
> > Bill Page wrote:
> > | See the example at:
> > |
> > | http://wiki.axiom-developer.org/SandBoxIOutput
> > |
> > | The commands executed by MathAction to compile and load modified
> > | BOOT code for i-ouput.boot are equivalent to the following:
> > |
> > |   )lisp (boottran::boottocl "src/interp/i-output2.boot")
> >
> > What happens if you just say:
> >
> >    )lisp (boottran::boot "src/interp/i-output2.boot")
> >
> > ?
> >
>
> Hmmm...
> 
> (1) -> )lisp (boottran::boot "src/interp/i-output2.boot")
>
>    >> System error:
>    The function BOOTTRAN::BOOT is undefined.

I think Gaby wanted to say:

 )lisp (boot "src/interp/i-output2.boot")

\start
Date: Sun, 26 Nov 2006 15:25:09 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Debugging Boot

On November 26, 2006 2:58 PM Vanuxem Gregory wrote:
> ...
> > On November 26, 2006 10:06 AM Gaby asked:
> > > 
> > > What happens if you just say:
> > > 
> > >    )lisp (boottran::boot "src/interp/i-output2.boot")
> > > 
> > > ?
> > >
> > 
> > Hmmm...
> >  
> > (1) -> )lisp (boottran::boot "src/interp/i-output2.boot")
> > 
> >    >> System error:
> >    The function BOOTTRAN::BOOT is undefined.
> 
> I think Gaby wanted to say:
> 
>  )lisp (boot "src/interp/i-output2.boot")
> 

So why not just say what it is supposed to do instead of
making me "experiment"? <sigh>

What contribution is this to documentation of Axiom? :-(

\start
Date: 26 Nov 2006 21:37:43 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Debugging Boot

Bill Page writes:

| On November 26, 2006 2:58 PM Vanuxem Gregory wrote:
| > ...
| > > On November 26, 2006 10:06 AM Gaby asked:
| > > > 
| > > > What happens if you just say:
| > > > 
| > > >    )lisp (boottran::boot "src/interp/i-output2.boot")
| > > > 
| > > > ?
| > > >
| > > 
| > > Hmmm...
| > >  
| > > (1) -> )lisp (boottran::boot "src/interp/i-output2.boot")
| > > 
| > >    >> System error:
| > >    The function BOOTTRAN::BOOT is undefined.
| > 
| > I think Gaby wanted to say:
| > 
| >  )lisp (boot "src/interp/i-output2.boot")
| > 
| 
| So why not just say what it is supposed to do instead of
| making me "experiment"? <sigh>

???

I did mean boottran::boot, as I intended boot from package boottran
which is documented (src/boot/ptyout.boot) as

   -- (boot "filename") translates the file "filename.boot" to
   -- the common lisp file "filename.clisp", compiles it and loads
   -- the bbin/o file.

For sure, when I invoke it in boostsy that way, it works for me.

| What contribution is this to documentation of Axiom? :-(

???

\start
Date: Sun, 26 Nov 2006 21:57:01 +0100
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: Debugging Boot

Le dimanche 26 novembre 2006 =E0 21:37 +0100, Gabriel Dos Reis a =E9crit =
:
> Bill Page writes:
>
> | On November 26, 2006 2:58 PM Vanuxem Gregory wrote:
> | > ...
> | > > On November 26, 2006 10:06 AM Gaby asked:
> | > > >
> | > > > What happens if you just say:
> | > > >
> | > > >    )lisp (boottran::boot "src/interp/i-output2.boot")
> | > > >
> | > > > ?
> | > > >
> | > >
> | > > Hmmm...
> | > > 
> | > > (1) -> )lisp (boottran::boot "src/interp/i-output2.boot")
> | > >
> | > >    >> System error:
> | > >    The function BOOTTRAN::BOOT is undefined.
> | >
> | > I think Gaby wanted to say:
> | >
> | >  )lisp (boot "src/interp/i-output2.boot")
> | >
> |
> | So why not just say what it is supposed to do instead of
> | making me "experiment"? <sigh>
>
> ???
>
> I did mean boottran::boot, as I intended boot from package boottran
> which is documented (src/boot/ptyout.boot) as
>
>    -- (boot "filename") translates the file "filename.boot" to
>    -- the common lisp file "filename.clisp", compiles it and loads
>    -- the bbin/o file.

Sorry. I see now.

\start
Date: 26 Nov 2006 21:59:13 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: sman and X libraries

Waldek Hebisch writes:

| in version 288 I see:
| 
| 2006-11-18  Bill Page  Bill Page
| 
|        * Makefile.pamphlet (LDFLAGS): Add X11 libraries flags.
|        * Makefile.in: Regenerate.
| 
| Why do we need this: AFAIK sman should not use any X libraries.
| In recent build 'ldd sman' gives me:
| 
|         libXpm.so.4 => /usr/X11R6/lib64/libXpm.so.4 (0x0000002a9566c000)
|         libSM.so.6 => /usr/X11R6/lib64/libSM.so.6 (0x0000002a95780000)
|         libICE.so.6 => /usr/X11R6/lib64/libICE.so.6 (0x0000002a9588d000)
|         libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x0000002a959af000)
|         libc.so.6 => /lib/libc.so.6 (0x0000002a95bc4000)
|         libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x0000002a95dea000)
|         libXau.so.6 => /usr/X11R6/lib64/libXau.so.6 (0x0000002a95efe000)
|         libXdmcp.so.6 => /usr/X11R6/lib64/libXdmcp.so.6 (0x0000002a96001000)
|         libdl.so.2 => /lib/libdl.so.2 (0x0000002a96104000)
|         /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)
| 
| so now sman will refuse to run on a machine without X libraries.

Fixed.  As of today, 'ldd sman' gives:

[15:03]% ldd sman                     ~/build/axiom/target/i686-suse-linux/bin
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/tls/libc.so.6 (0x4003c000)
        /lib/ld-linux.so.2 (0x40000000)

\start
Date: Sun, 26 Nov 2006 16:06:53 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Debugging Boot

On November 26, 2006 3:38 PM Gaby wrote:
> 
> Bill Page writes:
> 
> | On November 26, 2006 2:58 PM Vanuxem Gregory wrote:
> | > ...
> | > > On November 26, 2006 10:06 AM Gaby asked:
> | > > > 
> | > > > What happens if you just say:
> | > > > 
> | > > >    )lisp (boottran::boot "src/interp/i-output2.boot")
> | > > > 
> | > > > ?
> | > > >
> | > > 
> | > > Hmmm...
> | > >  
> | > > (1) -> )lisp (boottran::boot "src/interp/i-output2.boot")
> | > > 
> | > >    >> System error:
> | > >    The function BOOTTRAN::BOOT is undefined.
> | > 
> | > I think Gaby wanted to say:
> | > 
> | >  )lisp (boot "src/interp/i-output2.boot")
> | > 
> | 
> | So why not just say what it is supposed to do instead of
> | making me "experiment"? <sigh>
> 
> ???
> 
> I did mean boottran::boot, as I intended boot from package boottran
> which is documented (src/boot/ptyout.boot) as
> 
> -- (boot "filename") translates the file "filename.boot" to
>    -- the common lisp file "filename.clisp", compiles it and loads
>    -- the bbin/o file.
> 
> For sure, when I invoke it in boostsy that way, it works for me.
> 
> | What contribution is this to documentation of Axiom? :-(
> 
> ???
> 

I mean that your original post seemed obscure and annoying because
you did not explain why you wanted to know. Which implied that I
should already know. An explanation along with the question would
have been more courteous and useful.

Anyway, the Axiom Wiki only runs the AXIOMsys so apparently this
means that 'boottran::boot' is only defined in bootsys.

In the mean time I still don't know what 

  )lisp (boot "src/interp/i-output2.boot")

does in AXIOMsys (presumably the same thing?).

\start
Date: Sun, 26 Nov 2006 23:09:44 +0200
From: Jurgis Pralgauskis
To: Bill Page
Subject: Re: expression parse tree API?

ups.. probably I missunderstood sth.. a few years ago I stumbled upon 
Axiom, and maybe zwiki, and mentioning of python in  
http://wiki.axiom-developer.org/AxiomDevelopment made me think so...

anyway, could You point me where to look for expression parse API , if 
there is such..

Bill Page wrote:
> On November 26, 2006 11:41 AM Jurgis Pralgauskis wrote:
>
>   
>> I also asked in SAGE forum, but seems they don't deal with
>> expression parsing
>>     
> http://groups.google.com/group/sage-support/browse_thread/thread/96686f9ff4b
> a3711
>   
>> SAGE folks referenced Maxima.. but I want python, and as
>> I know Axiom is made with python (Maxima probably with C)..
>>     
>
> ??? Both Axiom and Maxima are written in Lisp.

\start
Date: 26 Nov 2006 22:14:27 +0100
From: Gabriel Dos Reis
To: list
Subject: build-improvements on cygwin

  I would like to test build-improvements on cygwin, but gcl-2.6.8pre
(and gcl-2.6.7) would not compile there.  If you know of the status of
GCL on cygwin, please tell me; otherwise, I fear Axiom on cygwin will
be delayed till I have time to work on GCL for cygwin (which will be
none this year). 

\start
Date: Sun, 26 Nov 2006 16:20:27 -0500
From: Bill Page
To: Jurgis Pralgauskis
Subject: RE: expression parse tree API?

On November 26, 2006 4:10 PM Jurgis Pralgauskis wrote:
> 
> 
> ups.. probably I missunderstood sth.. a few years ago I stumbled
> upon  Axiom, and maybe zwiki, and mentioning of python in  
> http://wiki.axiom-developer.org/AxiomDevelopment made me think
> so...
> 

The only reference to Python on the above page is a quote from
Tim Daly who wrote:

"Boot has some nice features. It was basically Python before Python
existed. The key flaw in Boot (and Python) is that programs are not
data." 

There is a general sense in which what Tim wrote it true: While
it is true that Axiom is ultimately written in Lisp, in fact
there are several layers of languages that are defined in order
write Axiom. Boot is the first of these languages. Boot is
compiled to Lisp. Boot in turn is used to implement SPAD - the
language in which the Axiom library code is written.

Take a loot at

http://wiki.axiom-developer.org/AxiomProgramming



> anyway, could You point me where to look for expression parse 
> API , if there is such..
>

Expression parsing is accessible via the InputForm domain.
See:

http://wiki.axiom-developer.org/InputForm

and related discussions in the axiom-developer archives:

http://mail.nongnu.org/archive/html/axiom-developer

 
>   
>> SAGE folks referenced Maxima.. but I want python, and as
>> I know Axiom is made with python (Maxima probably with C)..
>>     
>
> ??? Both Axiom and Maxima are written in Lisp.

\start
Date: Sun, 26 Nov 2006 16:24:08 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: build-improvements on cygwin

On November 26, 2006 4:14 PM Gabriel Dos Reis wrote:
> 
>   I would like to test build-improvements on cygwin, but gcl-2.6.8pre
> (and gcl-2.6.7) would not compile there.  If you know of the status of
> GCL on cygwin, please tell me; otherwise, I fear Axiom on cygwin will
> be delayed till I have time to work on GCL for cygwin (which will be
> none this year). 
> 

gcl-2.6.8pre compiles natively under Windows using MSYS/MinGW.
cygwin is not necessary.

\start
Date: 27 Nov 2006 00:39:44 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements on cygwin

Bill Page writes:

| On November 26, 2006 4:14 PM Gabriel Dos Reis wrote:
| > 
| >   I would like to test build-improvements on cygwin, but gcl-2.6.8pre
| > (and gcl-2.6.7) would not compile there.  If you know of the status of
| > GCL on cygwin, please tell me; otherwise, I fear Axiom on cygwin will
| > be delayed till I have time to work on GCL for cygwin (which will be
| > none this year). 
| > 
| 
| gcl-2.6.8pre compiles natively under Windows using MSYS/MinGW.
| cygwin is not necessary.

Thanks, I'll give it a shot.
I tried cygwin because it is was I'm used when I'm forced to use windows.

\start
Date: 27 Nov 2006 00:43:38 +0100
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: Debugging Boot

Gregory Vanuxem writes:

| Le dimanche 26 novembre 2006 =E0 21:37 +0100, Gabriel Dos Reis a =E9crit :
| > Bill Page writes:
| >
| > | On November 26, 2006 2:58 PM Vanuxem Gregory wrote:
| > | > ...
| > | > > On November 26, 2006 10:06 AM Gaby asked:
| > | > > >
| > | > > > What happens if you just say:
| > | > > >
| > | > > >    )lisp (boottran::boot "src/interp/i-output2.boot")
| > | > > >
| > | > > > ?
| > | > > >
| > | > >
| > | > > Hmmm...
| > | > >
| > | > > (1) -> )lisp (boottran::boot "src/interp/i-output2.boot")
| > | > >
| > | > >    >> System error:
| > | > >    The function BOOTTRAN::BOOT is undefined.
| > | >
| > | > I think Gaby wanted to say:
| > | >
| > | >  )lisp (boot "src/interp/i-output2.boot")
| > | >
| > |
| > | So why not just say what it is supposed to do instead of
| > | making me "experiment"? <sigh>
| >
| > ???
| >
| > I did mean boottran::boot, as I intended boot from package boottran
| > which is documented (src/boot/ptyout.boot) as
| >
| >    -- (boot "filename") translates the file "filename.boot" to
| >    -- the common lisp file "filename.clisp", compiles it and loads
| >    -- the bbin/o file.
|
| Sorry. I see now.

Don't be sorry.  Apparently, I made the incorrect assumption that Bill
was more knowledgeable with the system than he thinks he is.  That
exceedingly annoyed him.  Please ignore my message.

\start
Date: Mon, 27 Nov 2006 02:16:40 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: sman and X libraries

Gabriel Dos Reis wrote:
> Fixed.  As of today, 'ldd sman' gives:
> 
> [15:03]% ldd sman                     ~/build/axiom/target/i686-suse-linux/bin
>         linux-gate.so.1 =>  (0xffffe000)
>         libc.so.6 => /lib/tls/libc.so.6 (0x4003c000)
>         /lib/ld-linux.so.2 (0x40000000)

As of version 324 build fails for me.  Most things apparantly build OK,
but sman is missing.  Build fails because build_srcdir in the main
Makefile is unset, and apparently the rule:

$(AXIOM_SRC_TARGETS):
        cd $(build_srcdir) && $(ENV) $(MAKE)

is doing cd to my home directory, where no Makefile is present.

\start
Date: 27 Nov 2006 03:09:13 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: sman and X libraries

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Fixed.  As of today, 'ldd sman' gives:
| > 
| > [15:03]% ldd sman                     ~/build/axiom/target/i686-suse-linux/bin
| >         linux-gate.so.1 =>  (0xffffe000)
| >         libc.so.6 => /lib/tls/libc.so.6 (0x4003c000)
| >         /lib/ld-linux.so.2 (0x40000000)
| 
| As of version 324 build fails for me.  Most things apparantly build OK,
| but sman is missing.  Build fails because build_srcdir in the main
| Makefile is unset, and apparently the rule:
| 
| $(AXIOM_SRC_TARGETS):
|         cd $(build_srcdir) && $(ENV) $(MAKE)
| 
| is doing cd to my home directory, where no Makefile is present.

Gosh.  Everything built OK for me.  I must have fumble the commit
again.  I did a fresh check out, and I'm testing this.

-- Gaby

*** ChangeLog.build-improvements	(revision 16935)
--- ChangeLog.build-improvements	(local)
***************
*** 1,5 ****
--- 1,11 ----
  2006-11-26  Gabriel Dos Reis  Gabriel Dos Reis
  
+ 	* Makefile.pamphlet (build_srcdir): Restore from previous
+ 	accidental deletion.
+ 	* Makefile.in: Regenerate.
+ 
+ 2006-11-26  Gabriel Dos Reis  Gabriel Dos Reis
+ 
  	* Makefile.pamphlet (AXIOM_SRC_TARGETS): Fix typos.
  	* Makefile.in: Regenerate.
  
*** Makefile.in	(revision 16935)
--- Makefile.in	(local)
*************** subdir = 
*** 41,46 ****
--- 41,47 ----
  
  SUBDIRS = src/lib lsp src
  
+ build_srcdir = $(builddir)/src
  build_libdir = $(builddir)/src/lib
  lib_stamp = $(build_libdir)/stamp
  
*** Makefile.pamphlet	(revision 16935)
--- Makefile.pamphlet	(local)
*************** subdir = 
*** 314,319 ****
--- 314,320 ----
  
  SUBDIRS = src/lib lsp src
  
+ build_srcdir = $(builddir)/src
  build_libdir = $(builddir)/src/lib
  lib_stamp = $(build_libdir)/stamp
  
*** src/Makefile.in	(revision 16935)
--- src/Makefile.in	(local)
*************** all: all-ax
*** 13,19 ****
  all-ax all-src: stamp
  	@echo finished $(builddir)
  
! stamp: @axiom_src_all@ all-book 
  	-rm -f stamp
  	$(STAMP) stamp
  
--- 13,19 ----
  all-ax all-src: stamp
  	@echo finished $(builddir)
  
! stamp: @axiom_src_all@ all-sman all-book 
  	-rm -f stamp
  	$(STAMP) stamp
  
\start
Date: Sun, 26 Nov 2006 21:45:36 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Debugging Boot

Gaby,

On November 26, 2006 6:44 PM you wrote:

> 
> Don't be sorry.  Apparently, I made the incorrect assumption
> that Bill was more knowledgeable with the system than he thinks
> he is.  That exceedingly annoyed him.  Please ignore my message.
> 

I think you misunderstand. Both your message and Gregory's message
were very useful and should not be ignored. What annoyed me was
how poorly written they were as documentation for how to use boot.
It would have been better to simply point out that what I wrote as
two commands to compile Boot source code to Lisp code and then to
compile and load the Lisp code, can actually be written as one
simple command:

 )lisp (boot "src/interp/i-output2.boot")

The example of 

  )lisp (boottran::boot "src/interp/i-output2.boot")

in your original question, apparently concerning bootsys, was out
of context or perhaps you were not aware that 'boottran' is not
the package name used in AXIOMsys. In AXIOMsys the name of this
function is 'boot::boot'. 'boot' is the default package, so we can
call the function by just the name 'boot'.

The state of the documentation about Boot and how to use it is so
poor that I think we need to do everything we can to improve it.
Writing clear emails containing as much information as possible is
one way to help do this. Eventually the content might be collected
in a more usable format on the web or in a Boot Users Guide.

My level of frustration was heightened by Martin Rubey's recent
request for a "recipe" for how to debug code written in Boot and
which started this thread, since we still have no specific
documentation to which I could point even though this is quite
fundamental to Axiom debugging and development.

\start
Date: 27 Nov 2006 04:12:58 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Debugging Boot

Bill Page writes:

| Gaby,
| 
| On November 26, 2006 6:44 PM you wrote:
| 
| > 
| > Don't be sorry.  Apparently, I made the incorrect assumption
| > that Bill was more knowledgeable with the system than he thinks
| > he is.  That exceedingly annoyed him.  Please ignore my message.
| > 
| 
| I think you misunderstand. Both your message and Gregory's message
| were very useful and should not be ignored. What annoyed me was
| how poorly written they were as documentation for how to use boot.

If my orginal message appeared as a poor documentation, it was because
it was a genuine question, not a documentation.

| It would have been better to simply point out that what I wrote as
| two commands to compile Boot source code to Lisp code and then to
| compile and load the Lisp code, can actually be written as one
| simple command:
| 
|  )lisp (boot "src/interp/i-output2.boot")
| 
| The example of 
| 
|   )lisp (boottran::boot "src/interp/i-output2.boot")
| 
| in your original question, apparently concerning bootsys, was out
| of context or perhaps you were not aware that 'boottran' is not
| the package name used in AXIOMsys.

I've seen the package boottran used in many places in src/interp,
therefore I (incorrectly) assumed that its interface (e.g. as old Boot
translator) is almost the same as in src/boot (e.g. as the new Boot
translator).  Your second message, seems to indicate it is not.
That information was not available to me when I sent my original
message (which was a genuine question), therefore I could not gave
suggested that the single command does the same thing as the two
commands (I knew it was the same for bootsys, I wasn't sure for old
boot).  Which is why I did ask.  But, apparently, I should have not.  

\start
Date: 27 Nov 2006 06:30:53 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements on cygwin

Bill Page writes:

| On November 26, 2006 4:14 PM Gabriel Dos Reis wrote:
| > 
| >   I would like to test build-improvements on cygwin, but gcl-2.6.8pre
| > (and gcl-2.6.7) would not compile there.  If you know of the status of
| > GCL on cygwin, please tell me; otherwise, I fear Axiom on cygwin will
| > be delayed till I have time to work on GCL for cygwin (which will be
| > none this year). 
| > 
| 
| gcl-2.6.8pre compiles natively under Windows using MSYS/MinGW.
| cygwin is not necessary.

Well, I installed all I would find on mingw website.  The configure for
GCL-2.6.8pre failed because it could not find some of the basic
standard headers.  Meanwhile, I learnt what -mno-cygwin can trick GCC
to do.  I'm falling back to that.  It's late, I'm going to bed.

\start
Date: Mon, 27 Nov 2006 12:21:58 +0100
From: Ralf Ralf Hemmecke
To: list
Subject: Aldor extend usable in Axiom???

Hello,

I am quite a bit frustrated.

It is clearly not a problem (up to something I have not yet looked into) 
to extend existing Axiom domains from libaxiom.al via some .as files. 
The question now is: How do I use them?

Try

#include "axiom"
extend Integer: with {foo: % ->%} == add {foo(x:%):%==x}

compilation with )compile is no problem, but when I then type

1

I run into a foam error.

Does somebody know how to make "extend"s work in Axiom? Note, I don't 
need the SPAD compiler to deal with "extend" since the Aldor compiler is 
taking care of it. I just want to know a method to let the Axiom 
interpreter know that it now should use the extended Integers and not 
the one from LibAxiom.

Any chance that there is a quick solution?

Thank you in advance
Ralf

PS: If that is too imprecise, I could detail, but at the moment I work 
under Linux and only get a dialup connection with Windows, so it is a 
pain to switch all the time. :-(

\start
Date: Mon, 27 Nov 2006 13:17:02 +0000
From: Peter Broadbery
To: Ralf Hemmecke
Subject: Re: Aldor extend usable in Axiom???

On Mon, 2006-11-27 at 12:21 +0100, Ralf wrote:
> Hello,
> 
> I am quite a bit frustrated.
> 
> It is clearly not a problem (up to something I have not yet looked into) 
> to extend existing Axiom domains from libaxiom.al via some .as files. 
> The question now is: How do I use them?
> 
> Try
> 
> #include "axiom"
> extend Integer: with {foo: % ->%} == add {foo(x:%):%==x}
> 
> compilation with )compile is no problem, but when I then type
> 
> 1
> 
> I run into a foam error.
> 

I've been looking at this on and off, and haven't come to a good
solution, so this mail is as much to see if anyone else wants to look at
the problem as it is do describe what axiom is doing.

The foam error is 'Circular get encountered' or similar, followed by a
lack of exception raising machinery.  Defining 'fiRaiseException' to
simply throw its argument will do the job here, I expect.

The underlying problem here is that aldor is expecting that the axiom
domain 'Integer' will not be replaced by the new aldor one - however, in
an interpreted environment that is exactly what happens.  As an aside,
in compiled code aldor assigns a hashcode to each extended and
non-extended domain, so they are all kept seperately, and in theory one
can do extends with lexical as opposed to global scope).

In more detail (only the really enthusiastic should keep reading), when
the axiom domain is imported into the aldor runtime (daase.lisp,
process-import-entry), the aldor name is assigned to a domain which is
lazily expanded to the axiom definition of a domain - the lazy expansion
is in interop.boot.  Of course, the load process changes the axiom
definition of the extended domain to be the new aldor one, and a rather
nasty circularity ensues.

There seem to be two ways of fixing this - either 'rescue' the original
domain, and make sure that aldor code can only reference it, or rewrite
the lookup routines to use the underlying axiom style function lookup
vectors (of which I have no real knowledge).

In either case, the 'extend' case needs to be handled seperately,
because in the normal course of events, one expects 'Integer' to be the
latest one loaded into the system.

\start
Date: Mon, 27 Nov 2006 10:56:45 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: build-improvements on cygwin

On November 27, 2006 10:11 AM Gaby wrote:
> ... 
> | > 
> | > Well, I installed all I would find on mingw website.  The 
> | > configure for GCL-2.6.8pre failed because it could not find
> | > some of the basic standard headers.
> | 
> | I built GCL and AXIOMsys on Windows recently (last month). It
> | should still work. How to setup MSYS/MinGW to compile GCL and
> | Axiom is described here:
> | 
> | http://wiki.axiom-developer.org/BuildAxiom
> 
> As I said, installed all I could find on mingw webite labelled as
> current.

I have no idea if installing the packages marked current on the
mingw site will work, however I did test the following recipe on
the BuildAxiom page:

  [Install] In the following order:
 
    1. MinGW-5.0.3.exe
 
       This package will install mingw-runtime, w32api, GCC, binutils
       and mingw32-make. See the instructions for Getting Started
 
    2. MSYS-1.0.11-2004.04.30-1.exe
 
       This installation file contains basic Unix-style commands plus
       a commandline shell. See How to install MSYS
 
    3. msysDTK-1.0.1.exe

       This package provides common packages that are needed by
       developers.

> Configuring Axiom fails from the outset becaure there is no
> <regex.h> under mingw (there is one with cygwin).

If you are trying to build Axiom from build-improvements I am
sure that will fail because there are patches specfic to Windows
in the axiom--windows--1 branch that were never incorporated
into the axiom--main--1 branch from which build-improvements was
derived.

And of course under native windows you will not be able to build
all of the non-lisp components because some depend on X11 and
some require pty support neither of which is available on native
Windows.

But you can probably get at least some of the missing libraries
required by build-improvements from

http://sourceforge.net/projects/mingwrep

In particular regex is here:

http://sourceforge.net/project/showfiles.php?group_id=7382&package_id=12650

> Attemping to configure GCL only also fails because some fundamental
> headrs are missing.  I can't copy-n-patse the error because: (1) the
> windows machine is separate from the one I'm using, (2) the windows
> machine is at home and there is no access to it from the outside.

I built gcl-2.6.8pre and Axiom (from axiom--windows--1) in September
as described here:

http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00625.html
http://lists.nongnu.org/archive/html/axiom-developer/2006-09/msg00617.html

If you are serious about building Axiom on Windows, I would be glad to
repeat this to verify that it still works. I would really like to work
with someone to create a new release of Axiom for Windows. The Windows
version is extremely popular if you believe the download statistics but
there seem to be very few people willing to work on Axiom development
on Windows. :-(

> 
> I've a long day ahead of me, so I'll not return to Axiom matters
> before tonight.
> 
> | Once built, GCL call be called from cygwin if you wish. This
> 
> yes, I know.
> 
> | would be necessary for example to build the parts of Axiom that
> | depend on pty (like sman) since there is no pty under native
> | windows.
> | 
> | > Meanwhile, I learnt what -mno-cygwin can trick GCC to do.
> | > I'm falling back to that.
> | 
> | Yes, I think it should be possible to cross-compile from cygwin
> | but that seems like a lot of trouble. If you get this to work
> | then please let me know.
> 
> It is not much of cross-compilation.  Recent versions of cygwin
> include package for mingw.
> 

If you can make this work, great! Please keep me informed.

\start
Date: 27 Nov 2006 15:54:29 +0100
From: Francois Maltey
To: list
Subject: The Gosper algorithm for sum of hypergeometric	functions.

Hello,

Today I can't obtain sum as sum (1 / factorial n, n) with axiom silver.

Is there someone who has already make a such package ?
Is there someone who is working on ?

This algorithm uses hypergeometric functions and a recursive relation
over polynoms as a(n)p(n+1)-b(n-1)p(n)=c(n) where we are looking for
one polynom p(n) from a(n), b(n) et c(n).

I ask the same question :
Are there such packages already done ?
Who is working for such packages ?

\start
Date: 27 Nov 2006 17:25:19 +0100
From: Martin Rubey
To: Francois Maltey
Subject: Re: The Gosper algorithm for sum of hypergeometric functions.

Francois Maltey writes:

> Hello, 
> 
> Today I can't obtain sum as sum (1 / factorial n, n) with axiom silver.

As far as I know, this sum is not "Gosperable". It is doable by Zeilberger's
algorithm.

Zeilberger is not implemented in Axiom. However, you can use my guessing
package to guess a recurrence. Unfortunately, you have no way to know how many
terms you have to plug in.

Sample session: (PRec is for Polynomially RECursive)

(7) -> guessPRec([reduce(+, [factorial i for i in 1..n]) for n in 1..8])

   (7)  []
    Type: List Record(function: Expression Integer,order: NonNegativeInteger)

(8) -> guessPRec([reduce(+, [factorial i for i in 1..n]) for n in 1..9])

   (8)
   [
     [
       function =
         [f(n): - f(n + 2) + (n + 4)f(n + 1) + (- n - 3)f(n)= 0,f(0)= 1,f(1)= 3]
       ,
      order= 0]
     ]
    Type: List Record(function: Expression Integer,order: NonNegativeInteger)


To obtain the guessing package, send me a note. The version on MathAction is
OK, but contains one or two bugs (irrelevant for most things)

\start
Date: Mon, 27 Nov 2006 09:01:37 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: build-improvements on cygwin

On November 27, 2006 12:31 AM Gaby wrote:
> 
> 
> Bill Page writes:
> 
> | On November 26, 2006 4:14 PM Gabriel Dos Reis wrote:
> | > 
> | > I would like to test build-improvements on cygwin, but 
> | > gcl-2.6.8pre (and gcl-2.6.7) would not compile there. If
> | > you know of the status of GCL on cygwin, please tell me;
> | > otherwise, I fear Axiom on cygwin will be delayed till I have
> | > time to work on GCL for cygwin (which will be none this year). 
> | > 
> | 
> | gcl-2.6.8pre compiles natively under Windows using MSYS/MinGW.
> | cygwin is not necessary.
> 
> Well, I installed all I would find on mingw website.  The 
> configure for GCL-2.6.8pre failed because it could not find
> some of the basic standard headers.

I built GCL and AXIOMsys on Windows recently (last month). It
should still work. How to setup MSYS/MinGW to compile GCL and
Axiom is described here:

http://wiki.axiom-developer.org/BuildAxiom

Once built, GCL call be called from cygwin if you wish. This
would be necessary for example to build the parts of Axiom that
depend on pty (like sman) since there is no pty under native
windows.

> Meanwhile, I learnt what -mno-cygwin can trick GCC to do.
> I'm falling back to that.

Yes, I think it should be possible to cross-compile from cygwin
but that seems like a lot of trouble. If you get this to work
then please let me know.

\start
Date: Mon, 27 Nov 2006 08:53:00 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Debugging Boot

On November 26, 2006 10:13 PM Gaby wrote:
> ... 
> I've seen the package boottran used in many places in src/interp,
> therefore I (incorrectly) assumed that its interface (e.g. as old
> Boot translator) is almost the same as in src/boot (e.g. as the
> new Boot translator).  Your second message, seems to indicate it
> is not. That information was not available to me when I sent my
> original message (which was a genuine question), therefore I could
> not gave suggested that the single command does the same thing as
> the two commands (I knew it was the same for bootsys, I wasn't sure
> for old boot).  Which is why I did ask.  But, apparently, I should
> have not.  
> 

Of course you should ask! You did, and I answered. But I did
not understand the intention of your question so I could not
explain in such a way that would be helpful to anyone. Greg's
reply was also useful since eventually you explained what you
had in mind. But we can do all this more efficiently I think...

I think the interface is the same - only the package name is
different (but I have not checked all the details).

Anyway, let me just say: Thank you for the question. :-)

\start
Date: Mon, 27 Nov 2006 17:37:33 +0100 (CET)
From: Waldek Hebisch
To: Francois Maltey
Subject: Re: The Gosper algorithm for sum of hypergeometric functions.

> Today I can't obtain sum as sum (1 / factorial n, n) with axiom silver.
> 
> Is there someone who has already make a such package ?
> Is there someone who is working on ?
> 
> This algorithm uses hypergeometric functions and a recursive relation
> over polynoms as a(n)p(n+1)-b(n-1)p(n)=c(n) where we are looking for
> one polynom p(n) from a(n), b(n) et c(n).
> 
> I ask the same question : 
> Are there such packages already done ?
> Who is working for such packages ?
> 

Axiom has implementation of Gosper algorithm -- look at package
GosperSummationMethod.  Unfortunatly, normally Axiom uses Gosper
method only for rational functions.  I played a bit with using
Gosper method for other functions but there are two problems here:

1) Gosper methods is applicable to hypergeometric terms. However, many
expression which "obviously" are hypergeometric terms does not look
like hypergeometric when you take their Axiom representation.
2) Many examples do not work because Axiom can not do needed algebraic
simplifications (famous sqrt(2)*sqrt(3)-sqrt(6) problem).

P.S.  I do not remember if there is a trick to use GospersMethod
from command line -- I probably had to modify and recompile some
algebra files.

\start
Date: 27 Nov 2006 19:24:18 +0100
From: Francois Maltey
To: Francois Maltey
Subject: Re: The Gosper algorithm for sum of hypergeometric functions.

Thanks a lot Martin and Waldek,

In fact I'm looking for testing with axiom the sum that my students do.
I hope that axiom computes right (as the two M....) the most possible ser=
ies.
By example students search the series bellow.

Are they all hypergeometrics ?
this means that u(n+1) / u(n) is an alg=E9braic fraction
as (n-...)(n-...) - - - (n-...)/(n-...) - - - (n-...)

I believe yes but the cos/cosh/sin/sinh.
In this case the standard way with complex, combine and expand is right.
The very last one can be find by expand sum ... + sum ...
The only real problem is about the malicious sum ((2^((-1)^n), n)
for n even and n odd.

Am I right ?

Theses exercices have a closed form so the Gosper algorithm gives the
solution as a hypergeometric serie.

Am I right (again) ?

How can I use the GosperPackage :
I don't know how to use the signature for the command

    GosperMethod (Q, V, ()-> V) -> Union (Q, "failed")
            ++ GospersMethod(b, n, new) returns a rational function
            ++ \spad{rf(n)} such that \spad{a(n) * rf(n)} is the indefini=
te
            ++ sum of \spad{a(n)}
            ++ with respect to upward difference on \spad{n}, i.e.
            ++ \spad{a(n+1) * rf(n+1) - a(n) * rf(n) = a(n)},

The package is :

GosperSummationMethod(E, V, R, P, Q): Exports == Impl where
    E: OrderedAbelianMonoidSup
    V: OrderedSet
    R: IntegralDomain
    P: PolynomialCategory(R, E, V)
    Q: Join(RetractableTo Fraction Integer, Field with
              (coerce: P -> %; numer : % -> P; denom : % -> P))

Then can I recognize << with my eyes >> the hypergeometric serie ?

The easiest hypergeometric serie are 0F0 (x)=exp x and 1F0 (a, x)=(1-=
x)^(-a).

For others functions must I cut the hypergeometric serie in order to reco=
gnize
atan, exp and so. Is it possible ?

The main problem is perhaps to simplify (n+1)!/n!,
but an expand/rewrite function can do it, no ?

Martin, I'm sorry but I don't understand what your package do,
And I don't find your package on my silver axiom.

My aim is to force axiom to compute theses exercices about series.

Thanks a lot if you accept to drive me inside theses algorithms.

sum (n^2 * x^n,                         n=0..%plusInfinity) -- YES
sum (n^3 * x^n,                         n=0..%plusInfinity) -- YES

sum (x^n / (2*n-1),                     n=1..%plusInfinity) -- no

sum (1 / (n+1) / (n+3),                 n=0..%plusInfinity) -- YES
sum (x^n / (n+1) / (n+3),               n=0..%plusInfinity) -- no

sum (1 / (4*n^2-1),                     n=0..%plusInfinity) -- YES
sum ((-1)^n * x^(2*n+1) / (4*n^2-1),    n=0..%plusInfinity) -- no
sum ((-1)^n * x^(2*n+1) / (4*n^2-1),    n=0..%plusInfinity) -- no

sum (x^n / (4*n-1),                     n=1..%plusInfinity) -- no
sum ((n+3) * x^n / (2*n+1),             n=0..%plusInfinity) -- no

sum (x^n * exp (n*a),                   n=0..%plusInfinity) -- YES
sum (x^n * cosh (n*a),                  n=0..%plusInfinity) -- no
sum (x^n * exp (n*a) / n,               n=0..%plusInfinity) -- no
sum (x^n * cosh (n*a) / n,              n=0..%plusInfinity) -- no

sum (x^n * sin (n*a)^2 / 2^n,           n=0..%plusInfinity) -- YES with=
 exp %i
sum (x^n * (n^2+1) / (n+1),             n=0..%plusInfinity) -- no

sum (x^n / factorial n,                 n=0..%plusInfinity) -- no
sum (x^n / factorial (2*n),             n=0..%plusInfinity) -- no
sum (x^n * sin (n*a)^2 / factorial (n), n=0..%plusInfinity) -- no
sum (x^n * n^5 / factorial n,           n=0..%plusInfinity) -- no
sum (x^(3*n) / factorial (3*n),         n=0..%plusInfinity) -- no
sum (x^n * binomial (n+1, 2*n),         n=0..%plusInfinity) -- no
sum ((-1)^n * binomial (n, 2*n) / 4^n,  n=0..%plusInfinity) -- no

sum (1 / (n^2-1),                       n=0..%plusInfinity) -- YES
sum (x^n / (n^2-1),                     n=0..%plusInfinity) -- no
sum (1 / (3*n+1) / (6*n+5),             n=0..%plusInfinity) -- no

sum (1 / n / (n-1),                     n=0..%plusInfinity) -- YES
sum (x^n / n / (n-1),                   n=0..%plusInfinity) -- no

sum ((4*n+1) / (2*n^2+n-1),             n=0..%plusInfinity) -- no
sum ((4*n+1) * x^n / (2*n^2+n-1),       n=0..%plusInfinity) -- no

sum ((2^((-1)^n),                       n=0..%plusInfinity) -- no
sum (a^n * (1+b^n) / n,                 n=0..%plusInfinity) -- no

\start
Date: Tue, 28 Nov 2006 01:53:54 +0100 (CET)
From: Bertfried Fauser
To: Francois Maltey
Subject: Re: The Gosper algorithm for sum of hypergeometric functions.

On 27 Nov 2006, Francois Maltey wrote:

I am not aware of the packages for AXIOM, so others might comment on that,
but there is a pretty strong package called sigma by Carsten Schneider
(RISC, University of Linz, Austria).
www.risc.uni-linz.ac.at/publications/download/risc_203/dm060212.ps
This is the most advanced summation package I ever saw, and it handles
rather difficult cases. Downside is that it is written for mathematica and
has a about 10^4 lines of code (as Schneider told me). Furthoermore, its
not literate codes and the algorithms are sparcely documented in research
papers only (if at all)....

\start
Date: 27 Nov 2006 21:16:45 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements on cygwin

Bill Page writes:

| On November 27, 2006 1:02 PM Gaby wrote:
| > ... 
| > I've changed build-improvements to separate X11 stuff from
| > non-X11 stuff.  
| >
| 
| Is that separation of X11 stuff in the current build-improvements
| branch? (I could use that on some of the SourceForge compile farm
| machines.)

Yes, it is. (As part of my largest commit this week-end).

Configure detects (or can be told through --without-x) that X11 is not
available.   Consequently we don't build the X11 parts in src/
(e.g. graph, hyper).
However, I just discover that I did not commit the corresponding
part for src/lib.  Before you waste your time trying, let me correct
that part first.

| > The purpose of the exercise of building build-improvements on
| > cygwin (or mingw) is to see how effective the separation is,
| > and what remains to have an effective build.
| 
| I would think that that main reason for using cygwin would be
| because you want X11 and pseudo terminals. No? But under native
| Windows this separation is necessary.

the reason I chosed to use cygwin for the host and build machine is
that it provides some POSIX/Unix functionalities that I'm not sure I
have under mingw, and on the other hand I can convince GCC to generate
mingw binaries from cygwin.  It was not for the X11 stuff.

\start
Date: Mon, 27 Nov 2006 21:00:37 -0500
From: Tim Daly
To: list
Subject: gold/src/hyper/search.pamphlet

in gold/src/hyper/search.pamphlet
{
	a[n] = $0;
	n=n+1;
        j=split($0,b,"{");
        m=m+substr(b[j],1,length(b[j])-1);
}

but in sandbox it reads: 
{
	a[n] = $0;
	n=n+1;
        j=split($0,b,"{");
        if (j >= 2)
          m=m+substr(b[2],1,length(b[2])-1);
}

i don't understand this change. 
can someone explain it?
 
\start
Date: Mon, 27 Nov 2006 21:29:14 -0500
From: Bill Page
To: Tim Daly
Subject: RE: gold/src/hyper/search.pamphlet

On November 27, 2006 9:01 PM Tim Daly wrote:
> 
> in gold/src/hyper/search.pamphlet
> {
> 	a[n] = $0;
> 	n=n+1;
>         j=split($0,b,"{");
>         m=m+substr(b[j],1,length(b[j])-1);
> }
> 
> but in sandbox it reads: 
> {
> 	a[n] = $0;
> 	n=n+1;
>         j=split($0,b,"{");
>         if (j >= 2)
>           m=m+substr(b[2],1,length(b[2])-1);
> }
> 
> i don't understand this change. 
> can someone explain it?
>  

What is "sandbox"? Where can I find this code?

\start
Date: Mon, 27 Nov 2006 21:27:44 -0500
From: Tim Daly
To: Bill Page
Subject: Re: gold/src/hyper/search.pamphlet

> What is "sandbox"? Where can I find this code?

sorry, "sandbox" is wh-sandbox in svn on sourceforge.
as near as i can determine it is a branch off build-improvements.

\start
Date: Tue, 28 Nov 2006 03:58:11 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: gold/src/hyper/search.pamphlet

> in gold/src/hyper/search.pamphlet
> {
> 	a[n] = $0;
> 	n=n+1;
>         j=split($0,b,"{");
>         m=m+substr(b[j],1,length(b[j])-1);
> }
> 
> but in sandbox it reads: 
> {
> 	a[n] = $0;
> 	n=n+1;
>         j=split($0,b,"{");
>         if (j >= 2)
>           m=m+substr(b[2],1,length(b[2])-1);
> }
> 
> i don't understand this change. 
> can someone explain it?
>  

Gold code is wrong.  This is part of 'presea' which is is run on output
of 'hthits'.  'hthits' outputs looks like:

\newsearchresultentry{1}{Asp24 Example Code}{Asp24ExampleCode}
\newsearchresultentry{1}{Asp27 Example Code}{Asp27ExampleCode}
....


after splitting on "{" the first field is '\newsearchresultentry' and
the second is number of occurences of search term in the page.  The
test for 'j >= 2' is just to tolerate garbage.  'presea' is supposed
to count the number of matches and put it in the header for search
results.  Gold version reported no matches in the header.

You may need other fixes to actually see search results (and notice
the problem).

\start
Date: Mon, 27 Nov 2006 22:02:50 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: Re: gold/src/hyper/search.pamphlet

> > in gold/src/hyper/search.pamphlet
> > {
> > 	a[n] = $0;
> > 	n=n+1;
> >         j=split($0,b,"{");
> >         m=m+substr(b[j],1,length(b[j])-1);
> > }
> > 
> > but in sandbox it reads: 
> > {
> > 	a[n] = $0;
> > 	n=n+1;
> >         j=split($0,b,"{");
> >         if (j >= 2)
> >           m=m+substr(b[2],1,length(b[2])-1);
> > }
> > 
> > i don't understand this change. 
> > can someone explain it?
> >  
> 
> Gold code is wrong.  This is part of 'presea' which is is run on output
> of 'hthits'.  'hthits' outputs looks like:
> 
> \newsearchresultentry{1}{Asp24 Example Code}{Asp24ExampleCode}
> \newsearchresultentry{1}{Asp27 Example Code}{Asp27ExampleCode}
> ....
> 
> 
> after splitting on "{" the first field is '\newsearchresultentry' and
> the second is number of occurences of search term in the page.  The
> test for 'j >= 2' is just to tolerate garbage.  'presea' is supposed
> to count the number of matches and put it in the header for search
> results.  Gold version reported no matches in the header.
> 
> You may need other fixes to actually see search results (and notice
> the problem).

ah. perhaps it might be worthwhile adding this bit of wisdom to the
documentation for the change.

quite curious that this code never worked and nobody noticed.

\start
Date: Mon, 27 Nov 2006 23:22:57 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: sman and X libraries

Gabriel Dos Reis wrote:
> Gosh.  Everything built OK for me.  I must have fumble the commit
> again.  I did a fresh check out, and I'm testing this.
> 

OK, 325 works for me. And sman uses now no X libraries.

\start
Date: Mon, 27 Nov 2006 13:54:24 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: build-improvements on cygwin

On November 27, 2006 1:02 PM Gaby wrote:
> ... 
> I've changed build-improvements to separate X11 stuff from
> non-X11 stuff.  
>

Is that separation of X11 stuff in the current build-improvements
branch? (I could use that on some of the SourceForge compile farm
machines.)
 
> The purpose of the exercise of building build-improvements on
> cygwin (or mingw) is to see how effective the separation is,
> and what remains to have an effective build.

I would think that that main reason for using cygwin would be
because you want X11 and pseudo terminals. No? But under native
Windows this separation is necessary.

> Bill Page wrote:
> | If you are serious about building Axiom on Windows, I would
> | be glad to repeat this to verify that it still works.
>
> If you believe I was not or am not serious, we can terminate
> this conversation. 

Ok, lets lighten-up. I know I probably deserved that considering
my other thread. Peace. :-)

I am very happy that you are serious about building Axiom on
Windows and I will help however I can. A new version for Windows
is badly needed. Later today I will re-verify the my build of
gcl-2.6.8pre under Windows and let you know.

Building on cygwin is definitely an option if we want to get the
full functionality of Axiom as it exists on Linux, but it is
important to keep in mind that *most* Windows users are very
resistant to installing cygwin and even more negative about using
X11 applications under Windows because the look and feel is so
different. So I think we want at least AXIOMsys to run natively
without cygwin or the cygwin libraries.

\start
Date: 28 Nov 2006 08:48:11 +0100
From: Martin Rubey
To: Francois Maltey
Subject: Re: The Gosper algorithm for sum of hypergeometric functions.

Dear Francois,

unfortunately, I currently don't have the time to answer all your
questions. I'll try to answer at least the quickies:

Francois Maltey writes:

> Are they all hypergeometrics ?
> this means that u(n+1) / u(n) is an alg=C3=A9braic fraction

No. If we are talking about

sum(u(n), n = 1.. m),

it means that u(n+1) / u(n) is rational (i.e., a fraction of two polynomial=
s)
in n.

> Then can I recognize << with my eyes >> the hypergeometric series ?

You "only" need to check whether u(n+1) / u(n) is rational. As Waldek pointed
out, this is not always possible. You have to stay in "computable" domains,
i.e., domains where you can test for zero. For example, the domain of
arithmetic expressions is not computable: there cannot be an algorithm that
decides whether some expression is zero. Algebraic numbers, Polynomials over a
computable domain, polynomially recursive sequences over a computable domain
are examples of computable domains.

> Martin, I'm sorry but I don't understand what your package do,

It "guesses" an expression / recurrence for the n-th term of a sequence, given
the first few terms. For example,

guess([0,1,2,3,4,5]) will answer "n".

If you happen to know that your sequence is generated by a polynomial, and you
have a bound for the degree, you are done: just plug in the first degree+1
values and you'll get it. In principle we can mimick Zeilbergers algorithm
(although not very efficiently) this way: compute a bound for order and degree
of your recurrence and supply enough values to guess the sequence.

> And I don't find your package on my silver axiom.

No, you have to download the packages as indicated on
MathAction/GuessingFormulas and compile them. You'll get documentation in
HyperDoc then.

> My aim is to force axiom to compute theses exercices about series.
>
> Thanks a lot if you accept to drive me inside theses algorithms.
>
> sum (n^2 * x^n,                         n=0..%plusInfinity) -- YES

at least my Axiom doesn't know to sum to infinity. I have to say

(4) -> sum (n^2 * x^n,n=0..m)

          2 3        2           2     2             m    2
        (m x  + (- 2m  - 2m + 1)x  + (m  + 2m + 1)x)x  - x  - x
   (4)  -------------------------------------------------------
                            3     2
                           x  - 3x  + 3x - 1
                                                     Type: Expression Integer

and then I would like to say limit(%, m=%plusInfinity). Axiom responds with
"failed", of course, since it doesn't know that x < 1...

> sum (x^n / (n+1) / (n+3),               n=0..%plusInfinity) -- no

(28) -> l := [sum (x^n / (n+1) / (n+3), n=0..m)::FRAC POLY INT for m in 0..15];

                                       Type: List Fraction Polynomial Integer
(29) -> guessPRec l

   (29)
   [
     [
       function =
         BRACKET
            f(n):
                    2
                  (n  + 8n + 15)f(n + 2)
                +
                     2               2                        2
                ((- n  - 6n - 8)x - n  - 8n - 15)f(n + 1) + (n  + 6n + 8)x f(n)
                  =
                  0
             ,
                      1       3x + 8
                f(0)= -,f(1)= ------
                      3         24
       ,
      order= 0]
     ]

You can now, of course, "automatically" check whether this recurrence is
correct: just replacs f(n) with sum (x^n / (n+1) / (n+3), n=0..m) and do the
calculation. However, Axiom cannot do the necessary simplifications yet:

(31) -> g m == sum (x^n / (n+1) / (n+3), n=0..m)
                                                                   Type: Void
(32) -> (n^2+8*n+15)*g(n+2) + _
           ((-n^2-6*n-8)*x-n^2-8*n-15)*g(n+1)+(n^2+6*n+8)*x*g(n)

   (32)
                    n          n
       2           --+        x
     (n  + 6n + 8)x>     -----------
                   --+    2
                   n= 0  n  + 4n + 3
   +
                                      n + 1        n
          2               2            --+        x
     ((- n  - 6n - 8)x - n  - 8n - 15) >     -----------
                                       --+    2
                                      n= 0   n  + 4n + 3
   +
                   n + 2        n
       2            --+        x
     (n  + 8n + 15) >     -----------
                    --+    2
                   n= 0   n  + 4n + 3
                                                     Type: Expression Integer


\start
Date: Tue, 28 Nov 2006 10:01:01 +0100
From: Gernot Hueber
To: Ralf Ralf Hemmecke
Subject: Re: [Axiom-mail] NNI to SingleInteger

Hi Ralf, 

Ralf writes: 

> Hello, 
> 
> does somebody know the proper method/function to convert between 
> 
> NNI, PI, SingleInteger, Integer 
> 
> Complete conversion graph would be interesting.
> Note that I am *not* interested in interpreter stuff. I want to know the 
> explicit functions that I have to call in a .as file, i.e. the functions 
> should live inside libaxiom.al. If possible I want to avoid the use of 
> "pretend".

Sorry no graph, no explanation, only the practical approach. 

BR Gernot 


<----- begin code ------->
#include "axiom.as"
#pile 

INT ==> Integer;
NNI ==> NonNegativeInteger;
SI ==> SingleInteger;
PI ==> PositiveInteger; 

test(i: INT):INT == {
 import from INT, SI, PI, NNI; 

 -- INT -> all
 si1:SI := i::SI;
 pi1:PI := i::PI;
 nni1:NNI := i::NNI; 

 -- SI -> all
 int2:INT := si1::INT;
 pi2:PI := si1::PI;
 nni2:NNI := si1::NNI; 

 --> NNI -> all
 int3:INT := nni1::INT;
 pi3:PI := nni1::PI;
 si2:SI := nni1::SI; 

 i;
}
<----- end code -------> 


> 
> Yesterday, I have tried 
> 
> coerce: % -> PrimitiveArray S; 
> 
> from Tuple(S), but the Aldor compiler doesn't seem to know that this 
> coercion exists. Any hints? 
> 
> Furthermore, Tuple in Axiom has the function "select" for accessing the 
> n-th element of the tuple. Unfortunately, "select" is a reserved keyword 
> in Aldor. What should I do? 

\start
Date: 28 Nov 2006 11:01:18 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: sman and X libraries

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Gosh.  Everything built OK for me.  I must have fumble the commit
| > again.  I did a fresh check out, and I'm testing this.
| > 
| 
| OK, 325 works for me. And sman uses now no X libraries.

Thanks for the update!

-- gaby



\start
Date: 28 Nov 2006 11:16:31 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements on cygwin

Bill Page writes:

[...]

| I built gcl-2.6.8pre and Axiom (from axiom--windows--1) in September

I installed mingw on yet another machine, restarted everything from
scratch, and now I can report that I was able to build GCL-2.6.8pre
on mingw and preliminary tests I made were working.

However, I was unable to build a working gcl on cygwin using the mingw
package.  The generated executable does not use cygwin dll, but
raw_pre_gcl generated a stack overflow (my mingw/cygwin-fu is not
adequate to tackle a debug yet).  Consequently, the link for saved_gcl
with for unresolved symbols (which are present in libgcl.a!).

Then I decided to try build-improvements on mingw to get a feeling.
That led to to rethink some configure test.  Pristine noweb cannot be
compiled  on mingw because the archive contains symlinks.  So untarred
noweb using cygwin, modified the makefile using cygwin, then invoked
make [all install] under mingw.  I had a functional noweb installed.
Next, the modified build-improvement's configure completed (under
mingw).  Make stopped on bsdsignal.c.  Which prompted me to look into,
and get out horrified: Axiom has a tendency of checking for platforms,
when in fact it is interested in functionalities most of the time.
I changed bsdsignal.c to test for availability of sigaction(),
SA_RESTART, SA_INTERRUPT, etc.  The build proceeded till func_key.c
which has some calls to fork() and wait().  At that point, I decided
that I had enough experience for tonight and tackle daytime job
things.

I'll install a cross-compiling environment linux-x-mingw and use that
for further investigation.  And I'll tackle the mingw/cygwin issue
much later when time permits.

\start
Date: Tue, 28 Nov 2006 10:37:32 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: build-improvements on cygwin

On November 28, 2006 5:17 AM Gaby wrote:
> 
> I installed mingw on yet another machine, restarted everything
> from scratch, and now I can report that I was able to build
> GCL-2.6.8pre on mingw and preliminary tests I made were working.
>

Great.

I did not complete my testing of a new MSYS/MinGW configuration
because I got bitten by another repository bug. I still can not
use svn (TortioseSVN) on Windows because the SourceForge site dies
with the well known read error and irrevocably locks the repository.
And I can not obtain build-improvements from Google Code because we
long ago exceeded the maximum allowed capacity of that site and it
is no longer being updated. So I opted for darcs only to discover
that at patch 150 the 'get' it dies because it says it cannot apply
the rename of SEGBIND.ps. And I haven't figured out how to stop
darcs from applying this patch. This is a new failure sense it used
to work *before* we decided to normalize the duplicate file names
to lower case. I wonder whether 'darcs get' of build-improvements
still works on MAC OSX?

Right now I am trying again using Mercurial.

> However, I was unable to build a working gcl on cygwin using the
> mingw package.  The generated executable does not use cygwin dll,
> but raw_pre_gcl generated a stack overflow (my mingw/cygwin-fu is
> not adequate to tackle a debug yet).  Consequently, the link for
> saved_gcl with for unresolved symbols (which are present in
> libgcl.a!).

Adapting gcl memory management to windows is a big problem. Mike
Thomas did most of the work to make gcl run on Windows but he
specifically did not want to work with cygwin. I am not sure that
Mike is still here on this email list... but with Camm's help we
might be able to solve this problem for cygwin.

> 
> Then I decided to try build-improvements on mingw to get a feeling.
> That led to rethink some configure test.  Pristine noweb cannot
> be compiled on mingw because the archive contains symlinks.

The MSYS tools (including tar, I think) simulate symlinks via copy.
This works in most cases. In particular I am able to compile noweb
without changes.

> So untarred noweb using cygwin, modified the makefile using cygwin,
> then invoked make [all install] under mingw.

Usually mixing cygwin and MSYS/MinGW tools is a *bad* idea because
they use quite different conventions when it comes to solving
compatibility problems with Windows.

> I had a functional noweb installed.
> Next, the modified build-improvement's configure completed (under
> mingw).  Make stopped on bsdsignal.c.  Which prompted me to look
> into, and get out horrified: Axiom has a tendency of checking for
> platforms, when in fact it is interested in functionalities most
> of the time. I changed bsdsignal.c to test for availability of
> sigaction(), SA_RESTART, SA_INTERRUPT, etc.  The build proceeded
> till func_key.c which has some calls to fork() and wait().  At
> that point, I decided that I had enough experience for tonight
> and tackle daytime job things.

I am surprised that bsdsignal.c compiled. I think Windows has fewer
and different signals than unix.

There is no fork() or wait() under native Windows so that was a
good place to suspend your testing. :-)

> 
> I'll install a cross-compiling environment linux-x-mingw and
> use that for further investigation.

I suspect that you will find this even less likely to succeed
but I am interested in seeing how far you get.

> And I'll tackle the mingw/cygwin issue much later when time
> permits.
> 

I keep hoping that some day the Axiom project will attract
a really experienced Windows Developer...

\start
Date: 28 Nov 2006 17:06:01 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements on cygwin

Bill Page writes:

[...]

| > So untarred noweb using cygwin, modified the makefile using cygwin,
| > then invoked make [all install] under mingw.
| 
| Usually mixing cygwin and MSYS/MinGW tools is a *bad* idea because

I'm not so sure.  The combination let me move through the
shortcomings of both individual systems that popped up.  Of course,
you have to know the conventions.

| > I had a functional noweb installed.
| > Next, the modified build-improvement's configure completed (under
| > mingw).  Make stopped on bsdsignal.c.  Which prompted me to look
| > into, and get out horrified: Axiom has a tendency of checking for
| > platforms, when in fact it is interested in functionalities most
| > of the time. I changed bsdsignal.c to test for availability of
| > sigaction(), SA_RESTART, SA_INTERRUPT, etc.  The build proceeded
| > till func_key.c which has some calls to fork() and wait().  At
         ^^^^^^^^^^

sorry, this should read fnct_key.c.

| > that point, I decided that I had enough experience for tonight
| > and tackle daytime job things.
| 
| I am surprised that bsdsignal.c compiled. I think Windows has fewer
| and different signals than unix.

Well, onece you understand what bsdSignal was supposed to implement, it
is not hard to rewrite it in a way that it "works".  As a matter of
fact, it is a straightforward variation on an example in the classical
"Advanced Programming in the Unix Environment" book by Stevens.

In particular for MSYS, bsdSinal was not (originally) supposed to do
anything terribly useful, except to systematically report an error.
Note however that MSYS has a minimal <signal.h> (old style) that could
be used. Again, this requires to abstract over the irritating testing
for platforms, when one is interested in functionbality.

| There is no fork() or wait() under native Windows so that was a
| good place to suspend your testing. :-)

A few other filess compile.  bsdsignal.c does not use fork and wait.
it is fnct_key.c.

| > I'll install a cross-compiling environment linux-x-mingw and
| > use that for further investigation.
| 
| I suspect that you will find this even less likely to succeed
| but I am interested in seeing how far you get.

Most definitely, I don't want to have to switch to
windows while I'm testing ideas on both linux (pirmary) and
mingw/cygwin (secondary).

| > And I'll tackle the mingw/cygwin issue much later when time
| > permits.
| > 
| 
| I keep hoping that some day the Axiom project will attract
| a really experienced Windows Developer...

I too hope -- because I have no intention to become an experienced
Windows developer (I don't have the time).

\start
Date: 28 Nov 2006 17:23:48 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements on cygwin

[...]

| And I can not obtain build-improvements from Google Code because we
| long ago exceeded the maximum allowed capacity of that site

That was predictable.

\start
Date: Tue, 28 Nov 2006 11:30:25 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: build-improvements on cygwin

> | And I can not obtain build-improvements from Google Code because we
> | long ago exceeded the maximum allowed capacity of that site
> 
> That was predictable.

I can see how you feel that way but I'm a bit puzzled.

Didn't google give us a full gig of disk space?

I thought SVN only copies files when they are changed
so branches should not be expensive since they store 
only changes. I know that GIT only copies files when the
checksums differ so several copies of Axiom occupy almost
no additional space (or time, since GIT will not rsync
files that are duplicates). Surely Axiom will fit in a
gig of disk space.

\start
Date: Tue, 28 Nov 2006 12:47:23 -0400
From: Humberto Zuazaga
To: Bill Page
Subject: Re: build-improvements version control on MacOS

Bill Page wrote:

> I did not complete my testing of a new MSYS/MinGW configuration
> because I got bitten by another repository bug. I still can not
> use svn (TortioseSVN) on Windows because the SourceForge site dies
> with the well known read error and irrevocably locks the repository.
> And I can not obtain build-improvements from Google Code because we
> long ago exceeded the maximum allowed capacity of that site and it
> is no longer being updated. So I opted for darcs only to discover
> that at patch 150 the 'get' it dies because it says it cannot apply
> the rename of SEGBIND.ps. And I haven't figured out how to stop
> darcs from applying this patch. This is a new failure sense it used
> to work *before* we decided to normalize the duplicate file names
> to lower case. I wonder whether 'darcs get' of build-improvements
> still works on MAC OSX?

I haven't checked darcs today but I checked out a copy of 
build-improvements today with svk on MacOS X 10.4.

svk sync mirrors the whole svn repository, but it's files are named 
after the revision numbers. I guess it will work if you don't try to 
check out a version with the name conflicts.

\start
Date: Tue, 28 Nov 2006 12:55:39 -0400
From: Humberto Zuazaga
To: Tim Daly
Subject: Re: build-improvements on cygwin

root wrote:

> I thought SVN only copies files when they are changed
> so branches should not be expensive since they store 
> only changes. I know that GIT only copies files when the
> checksums differ so several copies of Axiom occupy almost
> no additional space (or time, since GIT will not rsync
> files that are duplicates). Surely Axiom will fit in a
> gig of disk space.

I think I pulled the whole axiom tree with svk:

$ svk list /mirror/axiom
branches/
silver/
tags/
trunk/

$ du -sh ~/.svk/remote
364M    /Users/humberto/.svk/remote

\start
Date: Tue, 28 Nov 2006 12:05:43 -0500
From: Alfredo Portes
To: Bill Page
Subject: Re: build-improvements on cygwin

Hi Bill,

> $ svk list /mirror/axiom
> branches/
> silver/
> tags/
> trunk/

In google, what is trunk and what is silver??? Isn't one of them redundant?
Sorry I lost track of the new schema for the repos.

\start
Date: Tue, 28 Nov 2006 11:57:44 -0500
From: Tim Daly
To: Humberto Zuazaga
Subject: Re: build-improvements on cygwin

> > I thought SVN only copies files when they are changed
> > so branches should not be expensive since they store 
> > only changes. I know that GIT only copies files when the
> > checksums differ so several copies of Axiom occupy almost
> > no additional space (or time, since GIT will not rsync
> > files that are duplicates). Surely Axiom will fit in a
> > gig of disk space.
> 
> I think I pulled the whole axiom tree with svk:
> 
> $ svk list /mirror/axiom
> branches/
> silver/
> tags/
> trunk/
> 
> $ du -sh ~/.svk/remote
> 364M    /Users/humberto/.svk/remote

That seems about right.
Arch axiom--main--1--patch-50 reports 305M
GIT for the same tree reports 135M

\start
Date: Tue, 28 Nov 2006 12:16:19 -0500
From: Bill Page
To: Tim Daly
Subject: RE: build-improvements on cygwin

On November 28, 2006 11:30 AM Tim Daly wrote:
> 
> 
> > | And I can not obtain build-improvements from Google Code 
> > | because we long ago exceeded the maximum allowed capacity
> > | of that site
> > 
> > That was predictable.
> 
> I can see how you feel that way but I'm a bit puzzled.
> 
> Didn't google give us a full gig of disk space?
>

No. They eventually grudgingly "compromised" at 750MBMbytes.
See email from Ben Collins-Sussman below.

> I thought SVN only copies files when they are changed
> so branches should not be expensive since they store 
> only changes.

Yes, in theory. However when creating a mirror it seems that this
may or may not be the case. If the file systems are the same then
one can just rsync the files and the result is identical but
according to Ben, the version of SVN at Google Code uses some
new and different file system so simply copying the underlying
repository files is not an option. The last email I have from him
on this issue mentioned a possible problem with space allocation
or maybe a disk usage accounting error.

Also since then we have two new branches in the SourceForge SVN
repository. Apparently creating branches via the SVK mirror and
smerge commands does *not* conserve disk space.

And another thing is that since this is a repository and all
history is kept, everything we do takes more space. For example
each new version of gcl-2.6.8pre.tgz that we commit to the SVN
repository adds another 50 Mbytes since no attempt is made to do
binary diffs. (I think there are already 4 versions of gcl in the
build-improvements branch.)

> I know that GIT only copies files when the checksums differ so
> several copies of Axiom occupy almost no additional space (or
> time, since GIT will not rsync files that are duplicates).
> Surely Axiom will fit in a gig of disk space.
> 

"GIT only copies files when the checksums differ". Are you sure?
Are checksums that reliable? Can you give me a reference? But I
agree that GIT uses significantly less space than SVN (and Mercurial
uses even less). 

Regards,
Bill Page.

> -----Original Message-----
> From: Ben Collins-Sussman [mailto:Ben Collins-Sussman] 
> Sent: October 9, 2006 2:14 PM
> To: Bill Page
> Cc: Gabriel Dos Reis; list
> Subject: re: [M#73697383] Re: Disk-quota Request
> 
> 
> On 10/6/06, Bill Page
> Bill Page wrote:
> > Gabriel Dos Reis wrote:
> > > ...
> > > Can we get the 1G and be done with it?
> > >
> >
> > .. but then how would help debug the Google, svnsync, svk, and svn
> > programs? ;)
> >
> 
> Enough is enough.  You guys have been more than patient as 
> our guinea pigs!
> 
> I just rsync'd your sourceforge svn repository down to my local box
> (165MB), made a dumpfile from that, then did an 'svnadmin load' in our
> datacenter.  Disturbingly, it still took two hours to load the history
> and used up 381MB of space.  I don't know whether our size-counting
> code is buggy, or if our Bigtable storage schema is just really that
> bad, I'll be investigating.  It's not your problem.  :-)
> 
> You're now live... all 176 revisions are up and happy.  You're only
> using 381 of 750MB of quota, so you should be fine for a good while.
> 
> Let me know if you have any more problems.
> 
> (Remember, do an https:// checkout if you intend to commit changes;
> http:// checkouts produce read-only working copies.)

\start
Date: Tue, 28 Nov 2006 12:25:28 -0500
From: Bill Page
To: Alfredo Portes
Subject: RE: build-improvements on cygwin

On November 28, 2006 12:06 PM Alfredo Portes wrote:
> 
> > $ svk list /mirror/axiom
> > branches/
> > silver/
> > tags/
> > trunk/
> 
> In google, what is trunk and what is silver??? Isn't one of them
> redundant? Sorry I lost track of the new schema for the repos.
> 

'silver' is supposed to be an exact mirror of Tim's axiom--silver--1
repository.

'trunk' is the original trunk from the SourceForge SVN which was
copied from patch-50 with a few updates that were applied directly
to SVN but not backported to axiom--silver--1.

After the recent dispute over managing these repositories, I am
not certain of the status of these on SourceForge. The last
comment I recall from Tim was that he was bringing axiom-silver--1
up-to-date (and thus also 'silver' SVN at SourceForge because
there is a robot process that mirrors his changes) and that he
now considered 'silver' also up-to-date, so yes probably 'trunk'
is now redundant.

But because of the space problems on Google I am not certain that
the Google versions of these are identical to the SourceForge
versions.

In short the Google repository is a mess. We should probably
wipe it and try to start again. If you are inclined to help with
this, probably the best thing would be to contact Ben and discuss
it with him. Maybe he would be willing to manually re-populate
the Google repository again.

\start
Date: Tue, 28 Nov 2006 12:26:56 -0500
From: Tim Daly
To: Bill Page
Subject: Re: build-improvements on cygwin

> "GIT only copies files when the checksums differ". Are you sure?
> Are checksums that reliable? Can you give me a reference? But I
> agree that GIT uses significantly less space than SVN (and Mercurial
> uses even less). 

GIT computes the MD5SUM of each file and each subdirectory and of the
whole tree. Only subtrees or files which have different MD5SUMs are
every stored, copied or transmitted. Thus creating a copy and checking
it in does almost nothing and takes almost no time to upload.

I know this works because I have switched to GIT for all of my 
personal work. Multiple copies of gcl-2.6.8pre.tgz take no additional
space or time to transmit.

Arch seems to want to trade disk space for file transfer time.
If you check out an arch repository it makes a "pristine copy"
which it caches locally, thus taking twice the disk space. The
advantage is that you don't do any network traffic for some
operations because you have a local, unchanged copy. The disadvantage
is the huge disk space cost. GIT does not store a local copy but only
has to transmit the MD5SUM of the tree root or subdirectory to decide
if changes occur. I'm not sure what SVN does.

You can see it in the numbers I just sent. Arch takes 305M, GIT takes 135M
for the same copy of Axiom.

\start
Date: 28 Nov 2006 19:18:13 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: build-improvements on cygwin

Tim Daly writes:

| > | And I can not obtain build-improvements from Google Code because we
| > | long ago exceeded the maximum allowed capacity of that site
| > 
| > That was predictable.
| 
| I can see how you feel that way but I'm a bit puzzled.
| 
| Didn't google give us a full gig of disk space?

I don'think they did. 

| I thought SVN only copies files when they are changed
| so branches should not be expensive since they store 
| only changes.

well, we have had  many branches, some of them actually share nothing
in common (I think they must have 3 distinct copies of Axiom in the
repo), and there were lots of property changes on almost every 
file.

\start
Date: 28 Nov 2006 19:22:20 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements on cygwin

Bill Page writes:

[...]

| And another thing is that since this is a repository and all
| history is kept, everything we do takes more space. For example
| each new version of gcl-2.6.8pre.tgz that we commit to the SVN
| repository adds another 50 Mbytes since no attempt is made to do
| binary diffs. (I think there are already 4 versions of gcl in the
| build-improvements branch.)

Indeed.  I'm of the opinion that keeping GCL as a tarball in the repo
is a mistake.

\start
Date: Tue, 28 Nov 2006 20:56:14 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: Re: build-improvements on cygwin

Bill Page wrote:
> On November 28, 2006 12:06 PM Alfredo Portes wrote:
> > 
> > > $ svk list /mirror/axiom
> > > branches/
> > > silver/
> > > tags/
> > > trunk/
> > 
> > In google, what is trunk and what is silver??? Isn't one of them
> > redundant? Sorry I lost track of the new schema for the repos.
> > 
> 
> 'silver' is supposed to be an exact mirror of Tim's axiom--silver--1
> repository.
> 
> 'trunk' is the original trunk from the SourceForge SVN which was
> copied from patch-50 with a few updates that were applied directly
> to SVN but not backported to axiom--silver--1.
> 
> After the recent dispute over managing these repositories, I am
> not certain of the status of these on SourceForge. The last
> comment I recall from Tim was that he was bringing axiom-silver--1
> up-to-date (and thus also 'silver' SVN at SourceForge because
> there is a robot process that mirrors his changes) and that he
> now considered 'silver' also up-to-date, so yes probably 'trunk'
> is now redundant.
> 
> But because of the space problems on Google I am not certain that
> the Google versions of these are identical to the SourceForge
> versions.
> 

Google shows revision 214. It looks that we exceeded Google quota by
creating 'silver'.

\start
Date: Tue, 28 Nov 2006 16:44:01 -0500
From: Bill Page
To: Ben Collins-Sussman
Subject: RE: build-improvements on cygwin

Ben,

We are having some problems again with our Axiom repository on
Google Code. I am copying you on the email below as background.
To make a long story short: I think we need to ask you to delete
the current repository and rebuild it again via 'svnadmin load'
as you did back on October 9 (see copy of your email below).

Since that time the size of the Axiom repository on SourceForge
has grown from 165MB to about 364M due to the creation of two
new branches. Even accounting for the larger storage factor at
Google (roughly double), I think this should still fit within
our current 750MB quota.

If you have any questions about this please ask. Also if you can
give us an update on the status of the problem which you mentioned
in October 9 message, that would be great.

Regards,
Bill Page.

On Tuesday, November 28, 2006 2:56 PM Waldek Hebisch wrote:
>
> Bill Page wrote:
> ...
> > But because of the space problems on Google I am not certain
> > that the Google versions of these are identical to the
> > SourceForge versions.
> >
>
> Google shows revision 214. It looks that we exceeded Google quota
> by creating 'silver'.
>

Yes, I think that is correct. Here is my attempt at post mortem:

Up to revision 199 (October 26), the 'svk smerge' transactions from
the axiom-developer.org server that are intended to synchronize the
Google repository with the SourceForge repository were properly
processed by Google. For reasons that I don't understand, the svk
smerge process did not automatically create the correct branch
structure at Google when we created 'silver' on SVN SourceForge.

Revision 214 on Google was the last of several transactions starting
with Revision 200 (including some errors) which I submitted to try
to create /silver with has the same structure as on SourceForge.
I ran a separate svk smerge job to try to transfer the contents
of 'silver' from SourceForge to Google. Revisions 200-210 appeared
to work but still resulted in wrong name and structure due to my
errors. Revision 210 was dated Sat Oct 28 03:44:24 2006.

After that I received notices each day from my svk smerge job on
the axiom-developer.org server showing that the storage quota was
exceeded on Google.

On November 15 I submitted 4 more revisons 211 to 214 which corrected
my errors by renaming and deleting unused branches. But this did not
have any positive effect at Google. Update transactions are still
not be processed.

Now I no longer even get any commit messages from Google at all
although the svk smerge job is still running each night and shows
that the local Google mirror on axiom-developer.org is being updated
successfully. It is not clear to me why I no longer seeing commit
attempts - either Google is not processing them or 'svk sync' is no
longer sending them. I have even recreated the svk google mirror
repository on axiom-developer in an attempt to re-synch. This worked
as expected but still no commit transactions seem to be attempted
at Google.

------

So I think the problems definitely were caused by the creation of
'silver'. But because we only have svn commit access to Google and
no svnadmin privileges, it seems impossible to be to correct this
problem without the intervention of people at Google.

Regards,
Bill Page.


> -----Original Message-----
> From: codesite-noreply@google.com
> [mailto:codesite-noreply@google.com]
> Sent: Wednesday, November 15, 2006 2:27 PM
> To: Bill Page
> Subject: [axiom commit] r214 - silver_old
>
> Author: synthesis.anikast.ca
> Date: Wed Nov 15 10:40:08 2006
> New Revision: 214
>
> Removed:
>    silver_old/
>
> Log:
> not needed
>

...

> -----Original Message-----
> From: codesite-noreply@google.com
> [mailto:codesite-noreply@google.com]
> Sent: Friday, October 27, 2006 4:26 AM
> To: Bill Page
> Subject: [axiom commit] r200 - trunk2
>
> Author: synthesis.anikast.ca
> Date: Fri Oct 27 01:25:47 2006
> New Revision: 200
>
> Added:
>    trunk2/
> Modified:
>    /   (props changed)
>
> Log:
> Create /trunk2
>



> -----Original Message-----
> From: codesite-noreply@google.com
> [mailto:codesite-noreply@google.com]
> Sent: Thursday, October 26, 2006 4:29 AM
> To: Bill Page
> Subject: [axiom commit] r199 - branches/build-improvements/src/interp
>
> Author: synthesis.anikast.ca
> Date: Thu Oct 26 01:28:07 2006
> New Revision: 199
>
> Modified:
>    /   (props changed)
>    branches/build-improvements/src/interp/ChangeLog.build-improvements
>    branches/build-improvements/src/interp/Makefile.in
>    branches/build-improvements/src/interp/Makefile.pamphlet
>    branches/build-improvements/src/interp/debugsys.lisp.pamphlet
>
> Log:
>
>         * debugsys.lisp.pamphlet (build-interpsys): Adjust pathname to
>         files that are local to the current build directory.
>
>         * Makefile.pamphlet: Remove individual rules for making object
>         codes out of Boot pamphlet using bootsys.
>         (BOOT_TO_LISP, COMPILE_LISP): New.
>         (AXIOMsys_boot_sources): Likewise.  List core Boot files here.
>         (<<extract source codes>>): New chunk.  Abstract over special
>         individual rules to translate Boot to object code, using
>         bootsys.
>         * Makefile.in: Regenerate.


> -----Original Message-----
> From: Ben Collins-Sussman [mailto:Ben Collins-Sussman]
> Sent: October 9, 2006 2:14 PM
> To: Bill Page
> Cc: Gabriel Dos Reis; list
> Subject: re: [M#73697383] Re: Disk-quota Request
>
>
> On 10/6/06, Bill Page
> Bill Page wrote:
> > Gabriel Dos Reis wrote:
> > > ...
> > > Can we get the 1G and be done with it?
> > >
> >
> > .. but then how would help debug the Google, svnsync, svk, and svn
> > programs? ;)
> >
>
> Enough is enough.  You guys have been more than patient as
> our guinea pigs!
>
> I just rsync'd your sourceforge svn repository down to my local box
> (165MB), made a dumpfile from that, then did an 'svnadmin load' in our
> datacenter.  Disturbingly, it still took two hours to load the history
> and used up 381MB of space.  I don't know whether our size-counting
> code is buggy, or if our Bigtable storage schema is just really that
> bad, I'll be investigating.  It's not your problem.  :-)
>
> You're now live... all 176 revisions are up and happy.  You're only
> using 381 of 750MB of quota, so you should be fine for a good while.
>
> Let me know if you have any more problems.
>
> (Remember, do an https:// checkout if you intend to commit changes;
> http:// checkouts produce read-only working copies.)

\start
Date: 28 Nov 2006 23:16:38 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements on cygwin

Bill Page writes:

[...]

| Up to revision 199 (October 26), the 'svk smerge' transactions from
| the axiom-developer.org server that are intended to synchronize the
| Google repository with the SourceForge repository were properly
| processed by Google. For reasons that I don't understand, the svk
| smerge process did not automatically create the correct branch
| structure at Google when we created 'silver' on SVN SourceForge.

I believe 'silver' was created from "scratch", so has not ancestry in
common with any other branch in the repository -- if my understand of
your famous picture is correct.  It effectively is a
"repository" within the repository  -- essentially, files are
_duplicated_ as opposed to being shared.  For me, that explains the
sudden surge.

\start
Date: Tue, 28 Nov 2006 16:29:46 -0600
From: Ben Collins-Sussman
To: Gabriel Dos Reis
Subject: Re: build-improvements on cygwin

On 28 Nov 2006 23:16:38 +0100, Gabriel Dos Reis
Gabriel Dos Reis wrote:
> Bill Page writes:
>
> [...]
>
> | Up to revision 199 (October 26), the 'svk smerge' transactions from
> | the axiom-developer.org server that are intended to synchronize the
> | Google repository with the SourceForge repository were properly
> | processed by Google. For reasons that I don't understand, the svk
> | smerge process did not automatically create the correct branch
> | structure at Google when we created 'silver' on SVN SourceForge.
>
> I believe 'silver' was created from "scratch", so has not ancestry in
> common with any other branch in the repository -- if my understand of
> your famous picture is correct.  It effectively is a
> "repository" within the repository  -- essentially, files are
> _duplicated_ as opposed to being shared.  For me, that explains the
> sudden surge.
>

Yep, that would explain it.  Branches are supposed to be cheap copies;
 they're just a hardlink within the repository, so they're nearly
instantaneous to create and take essentially zero space when they're
first made.  I don't know what you did on sourceforge, but it sure
wasn't a normal subversion branch!

I can reset the google repository to revision 0 if you'd like.

\start
Date: 29 Nov 2006 00:00:13 +0100
From: Gabriel Dos Reis
To: Ben Collins-Sussman
Subject: Re: build-improvements on cygwin

Ben Collins-Sussman writes:

| On 28 Nov 2006 23:16:38 +0100, Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| > Bill Page writes:
| >
| > [...]
| >
| > | Up to revision 199 (October 26), the 'svk smerge' transactions from
| > | the axiom-developer.org server that are intended to synchronize the
| > | Google repository with the SourceForge repository were properly
| > | processed by Google. For reasons that I don't understand, the svk
| > | smerge process did not automatically create the correct branch
| > | structure at Google when we created 'silver' on SVN SourceForge.
| >
| > I believe 'silver' was created from "scratch", so has not ancestry in
| > common with any other branch in the repository -- if my understand of
| > your famous picture is correct.  It effectively is a
| > "repository" within the repository  -- essentially, files are
| > _duplicated_ as opposed to being shared.  For me, that explains the
| > sudden surge.
| >
| 
| Yep, that would explain it.  Branches are supposed to be cheap copies;
|  they're just a hardlink within the repository, so they're nearly
| instantaneous to create and take essentially zero space when they're
| first made.  I don't know what you did on sourceforge, but it sure
| wasn't a normal subversion branch!
| 
| I can reset the google repository to revision 0 if you'd like.

That would be very much appreciated.

Bill, before your mirror to the next new repo, please let me make sure
that we don't store gcl and noweb as .tar.gz anymore.

\start
Date: Tue, 28 Nov 2006 18:14:57 -0500
From: Bill Page
To: Ben Collins-Sussman, Gabriel Dos Reis
Subject: RE: build-improvements on cygwin

On Tuesday, November 28, 2006 5:30 PM Ben Collins-Sussman wrote:
>
> On 28 Nov 2006 23:16:38 +0100, Gabriel Dos Reis
> Gabriel Dos Reis wrote:
> > Bill Page writes:
> >
> > [...]
> >
> > | Up to revision 199 (October 26), the 'svk smerge'
> > | transactions from the axiom-developer.org server that are
> > | intended to synchronize the Google repository with the
> > | SourceForge repository were properly processed by Google.
> > | For reasons that I don't understand, the svk smerge process
> > | did not automatically create the correct branch structure
> > at Google when we created 'silver' on SVN SourceForge.
> >
> > I believe 'silver' was created from "scratch", so has not
> > ancestry in common with any other branch in the repository --
> > if my understand of your famous picture is correct.  It
> > effectively is a "repository" within the repository  --
> > essentially, files are _duplicated_ as opposed to being shared.
> > For me, that explains the sudden surge.
> >

I don't understand "repository within repository" comment but
yes I agree that the large increase in size in not unexpected.
In fact we discussed exactly this before the creation of 'silver'
back in October. Do you recall our discuss of the consequences
of having two roots in the repository?

For me, the mystery is why 'svk smerge' did not successfully
mirror our creation of this new branch.

>
> Yep, that would explain it.  Branches are supposed to be cheap
> copies; they're just a hardlink within the repository, so they're
> nearly instantaneous to create and take essentially zero space
> when they're first made.  I don't know what you did on
> sourceforge, but it sure wasn't a normal subversion branch!
>

No it was not a normal subversion branch. Our problem has a long
history connected with different major Axiom developers using
different source code repository systems (arch, cvs and svn).
The original trunk in svn at SourceForge was created by the
SourceForge tool for converting cvs to svn. The contents of cvs
at SourceForge was obtained from a series of snapshots from the
arch master repository. Because of improperly flagged binary
files, the resulting svn repository was a bit of mess but that
was eventually corrected.

Meanwhile for a variety of reasons development continued on both
arch and svn independently with commits to both svn trunk and to
several svn branches as well as the original arch "silver". In
October we decided to try to merge the changes to svn trunk and
arch silver. My proposal was to automatically mirror the arch
silver repository as a new "trunk" on svn so that both sets of
developers could continue using their own repository systems.
This resulted in the duplication of files mentioned by Gaby.

To understand my motivation it is important to note that the svn
mirror of the silver repository contains the history of the
development in arch. While the existing trunk contains only the
snapshot history from cvs.

In mean time, we also implemented an automatic mirror process
that is supposed to keep the Axiom Google Code repository in
sync with the SourceForge repository. I guess in retrospect
creating 'silver' at SourceForge after implemented the automatic
mirror was a bad idea given that we are so severely limited in
disk quota at Google.

What I would really like to be able to do is "re-base" all of
the existing branches on svn on this new 'silver' so that they
are deltas of it instead of trunk. Then commits to the arch
silver master would still be properly reflected at SourceForge
and Google. But maybe this is a vane hope. And maybe the long
term continued use of arch is in doubt anyway.

To move forward, I think what we probably need to do is to replace
the trunk at SourceForge with the current contents of 'silver' at
SourceForge. I.e. compute the minimum delta from trunk to silver
and then apply it to trunk. And then scrap all of the history
related to 'silver' even though 'silver' actually has the more
complete history. I think we *might* be able to do this via
svnadmin at SourceForge... but I really need the help of someone
more knowledgeable than me in order to avoid yet another disk
space catastrophe.

> I can reset the google repository to revision 0 if you'd like.
>

You may recall that more than this was necessary since the way
the svk smerge mirror synchronization process works it seems to
result in much greater disk space ussage then just 'svnadmin load'.
So just reseting it to 0 may not be enough. We went around this
problem several times before until you decided to use svnadmin.

\start
Date: Tue, 28 Nov 2006 18:28:00 -0500
From: Bill Page
To: Gabriel Dos Reis, Ben Collins-Sussman
Subject: RE: build-improvements on cygwin

On Tuesday, November 28, 2006 6:00 PM Gaby wrote:

> Ben Collins-Sussman writes:
> ...
> | I can reset the google repository to revision 0 if you'd like.
>
> That would be very much appreciated.
>
> Bill, before your mirror to the next new repo, please let me
> make sure that we don't store gcl and noweb as .tar.gz anymore.
>

Yes, we discussed this previously and I had agreed to commit a
change so that both gcl and noweb appear as source in a new 'tools'
directory. I am sorry that I have not yet had time to do this.
I now think we should do this at the same time as merging silver
and trunk so that we can completely get rid of the zips directory.

But of course this is not the real cause of the disk space problems
which is really the duplication that you identified in your previous
message - it just makes it a bit worse.

So as a first step I will temporarily disable the cron job that runs
the 'svk smerge' to Google. Ok?

But I am still concerned that even after we get things cleaned up
in the SourceForge SVN, then we should not depend on 'svk smerge'
to initially re-populate the repository at Google since that is
likely to cause excessive disk space utilization again. However
I think that once populated via 'svnadmin load', using svk smerge
is probably ok provided I don't decide to do something stupid again...

\start
Date: 29 Nov 2006 00:45:01 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements on cygwin
Cc: Ben Collins-Sussman

Bill Page writes:

| On Tuesday, November 28, 2006 6:00 PM Gaby wrote:
| 
| > Ben Collins-Sussman writes:
| > ... 
| > | I can reset the google repository to revision 0 if you'd like.
| > 
| > That would be very much appreciated.
| > 
| > Bill, before your mirror to the next new repo, please let me
| > make sure that we don't store gcl and noweb as .tar.gz anymore.
| > 
| 
| Yes, we discussed this previously and I had agreed to commit a
| change so that both gcl and noweb appear as source in a new 'tools'
| directory. I am sorry that I have not yet had time to do this.
| I now think we should do this at the same time as merging silver
| and trunk so that we can completely get rid of the zips directory.
| 
| But of course this is not the real cause of the disk space problems
| which is really the duplication that you identified in your previous
| message - it just makes it a bit worse.

Yes.

| So as a first step I will temporarily disable the cron job that runs
| the 'svk smerge' to Google. Ok?

I agree.

| But I am still concerned that even after we get things cleaned up
| in the SourceForge SVN, then we should not depend on 'svk smerge'
| to initially re-populate the repository at Google since that is
| likely to cause excessive disk space utilization again. However
| I think that once populated via 'svnadmin load', using svk smerge
| is probably ok provided I don't decide to do something stupid again...

I would think so; but I would very much welcome Ben's input here about
the best way to avoid the duplicate trees (maybe keep history only
after the repopulation?)

\start
Date: Tue, 28 Nov 2006 19:33:05 -0600
From: Ben Collins-Sussman
To: Gabriel Dos Reis
Subject: Re: build-improvements on cygwin

On 29 Nov 2006 00:45:01 +0100, Gabriel Dos Reis
Gabriel Dos Reis wrote:

> I would think so; but I would very much welcome Ben's input here about
> the best way to avoid the duplicate trees (maybe keep history only
> after the repopulation?)

After reading the history of your project.... cvs, svn, svk, arch....
my head is truly spinning!

I hate to say this, but I think it's time to stop trying to use
multiple version control systems and multiple hosting services.  If I
were running your project, I'd just 'stop the madness' and start
fresh.   Completely start over.   By that, I mean:

  1. choose ONE hosting service
  2. choose ONE version control system
  3. import just the LATEST trunk code into that system (no history!)

Start coding against your latest codebase.   If for some reason you
need to access history (look at an old branch or tag, or diff against
an old file), then dig out the older version control system and peer
into it.

Shocking statement:  you really don't need your code history as much
as you think you do.  In the scenario I'm advocating, your history
isn't even gone, it's just not super-convenient to access.  Weigh that
slight inconvenience against the *monstrous* headaches you guys have
been going through trying to get svn/svk/arch to work together and
sync around.  Your version control tool is supposed to be helpful for
collaboration and stay out of the way of your work.  From where I'm
sitting, it seems like your project is spending 80% of its energy just
trying to battle various SCM tools.  Enough is enough!  Choose one,
start fresh, move on!

(Case study:  Subversion itself was initially developed in CVS for
more than a year.  When it came time to become 'self-hosting', we
hadn't yet developed the cvs2svn history-conversion tool, and we
started freaking out about not taking our code history with us into
the new system.  In the end, we just didn't bother.  It turns out it
just didn't matter;  we never *once* had to go back and grab anything
from the old CVS repository... thought it was nice to know it was
there if we needed to look something up.)

\start
Date: Wed, 29 Nov 2006 03:11:55 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: Re: build-improvements on cygwin
Cc: Ben Collins-Sussman

Bill Page wrote:
> To understand my motivation it is important to note that the svn
> mirror of the silver repository contains the history of the
> development in arch. While the existing trunk contains only the
> snapshot history from cvs.
>

AFAICS the current 'silver' was created as a big hunk in revision
208.  Revisions 209 and 210 added a few changes (there are a few
other patches, but they reflect changes after cloning form arch)
-- I would not call this "history".  Certainly 'trunk' contains
more information.
 
> In mean time, we also implemented an automatic mirror process
> that is supposed to keep the Axiom Google Code repository in
> sync with the SourceForge repository. I guess in retrospect
> creating 'silver' at SourceForge after implemented the automatic
> mirror was a bad idea given that we are so severely limited in
> disk quota at Google.
> 
> What I would really like to be able to do is "re-base" all of
> the existing branches on svn on this new 'silver' so that they
> are deltas of it instead of trunk. Then commits to the arch
> silver master would still be properly reflected at SourceForge
> and Google. But maybe this is a vane hope. And maybe the long
> term continued use of arch is in doubt anyway.
> 
> To move forward, I think what we probably need to do is to replace
> the trunk at SourceForge with the current contents of 'silver' at
> SourceForge. I.e. compute the minimum delta from trunk to silver
> and then apply it to trunk. And then scrap all of the history
> related to 'silver' even though 'silver' actually has the more
> complete history. I think we *might* be able to do this via
> svnadmin at SourceForge... but I really need the help of someone
> more knowledgeable than me in order to avoid yet another disk
> space catastrophe.
> 

I tried to check where disk space go.  After looking at rsynced copy
of SF repository I see that most space is taken due to following
revisions:

201   80 Mb  failed arcs clone ???
208   80 Mb  current 'silver'
252
219
143
115
102
31    each 20Mb -- snapshots of gcl-2.6.8

\start
Date: Tue, 28 Nov 2006 22:19:17 -0500
From: Bill Page
To: Waldek Hebisch, Bill Page
Subject: the repository story (was: build-improvements on cygwin)

I've changed the subject to better reflect the subject and
omitted Ben from the Cc: list for now since he is probably
not interested in our detailed discussions on this subject.

On Tuesday, November 28, 2006 9:12 PM Waldek Hebisch wrote:
>
> Bill Page wrote:
> > To understand my motivation it is important to note that the
> > svn mirror of the silver repository contains the history of
> > the development in arch. While the existing trunk contains
> > only the snapshot history from cvs.
> >
>
> AFAICS the current 'silver' was created as a big hunk in revision
> 208.  Revisions 209 and 210 added a few changes (there are a few
> other patches, but they reflect changes after cloning form arch)
> -- I would not call this "history".  Certainly 'trunk' contains
> more information.

What I see from the commit emails are my failed attempts to
create 'silver' from revisions 205 to 215, then the real 'silver'
starting from revision 216, 217, and 218. But you are right no
history! :-( I suppose this must be because of the way that Tim
created axiom--silver--1 branch in arch. I had incorrectly assumed
that axiom--silver--1 had the same history as axiom--main--1 (gold)
but never checked until now. That is another mistake I made. Of
course if we had the real history from axiom--main--1 it would
contain at least 50 entrys - one for each patch set.

Now I am inclined to agree with Ben's recommendations in his last
email. I guess we can forget this history. Tim obviously didn't
think it was important anyway. But if we do move entirely from
SourceForge to Google Code are we really prepared to forget our
current history in SVN?

>From my point of view the move to Google Code is motivated because
of extreme problems I continue to have trying to use SVN at
SourceForge. I am still optimistic that things might be easier
at Google Code. Tim had a similar experience. Are we the only
exceptions or do other people have similar problems?

How can we agree on a single host and a single repository system?

> ...
> I tried to check where disk space go.  After looking at rsynced copy
> of SF repository I see that most space is taken due to following
> revisions:
>
> 201   80 Mb  failed arcs clone ???
> 208   80 Mb  current 'silver'
> 252
> 219
> 143
> 115
> 102
> 31    each 20Mb -- snapshots of gcl-2.6.8
>

200-201 and 205-212 where both failed attempts. (I kept getting the
name wrong in the Tailor configuration file.) I finally got it right
in 213-218. Perhaps there are in fact 3 copies of the arch clone?
Or did I somehow manage to rename one and re-use it?

How can I clean-up such mistakes without leaving this mess in the
repository?

Do you know the best way of merging 'silver' into 'trunk'? I think
you once compared these versions and said there was really very
little difference. Right?

Are we prepared to cut the automatic connection with Tim's original
axiom--silver--1? I believe Tim stated that he was no longer prepared
to maintain this branch anyway. So I assume "yes".

By 252 to 31 do you mean there are 6 copies of the gcl-2.6.8pre
tarball? I.e. 6 x 20 Mb = 120 Mb.

\start
Date: 29 Nov 2006 04:35:12 +0100
From: Gabriel Dos Reis
To: Ben Collins-Sussman
Subject: Re: build-improvements on cygwin

Ben Collins-Sussman writes:

| On 29 Nov 2006 00:45:01 +0100, Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| 
| > I would think so; but I would very much welcome Ben's input here about
| > the best way to avoid the duplicate trees (maybe keep history only
| > after the repopulation?)
| 
| After reading the history of your project.... cvs, svn, svk, arch....
| my head is truly spinning!

I can understand that.  Axiom is probably the only project I've worked on
that has more SCM than active developers :-/ 
(But, hey, I was the one who cannot work with arch; and we needed
something that can handle changeset, so CVS was no option).

\start
Date: 29 Nov 2006 04:45:37 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: the repository story (was: build-improvements on cygwin)

Bill Page writes:

[...]

| >From my point of view the move to Google Code is motivated because
| of extreme problems I continue to have trying to use SVN at
| SourceForge. I am still optimistic that things might be easier
| at Google Code. Tim had a similar experience. Are we the only
| exceptions or do other people have similar problems?

A student reported today at 12:30pm -05 that checkout of SVN/SF failed
for him and he believed that it was because SF's server crashed.  I
did not have time to test because I had to rush to class.

| How can we agree on a single host and a single repository system?
| 
| > ... 
| > I tried to check where disk space go.  After looking at rsynced copy
| > of SF repository I see that most space is taken due to following
| > revisions:
| > 
| > 201   80 Mb  failed arcs clone ???
| > 208   80 Mb  current 'silver'
| > 252
| > 219
| > 143
| > 115
| > 102
| > 31    each 20Mb -- snapshots of gcl-2.6.8
| > 
| 
| 200-201 and 205-212 where both failed attempts. (I kept getting the
| name wrong in the Tailor configuration file.) I finally got it right
| in 213-218. Perhaps there are in fact 3 copies of the arch clone?
| Or did I somehow manage to rename one and re-use it?
| 
| How can I clean-up such mistakes without leaving this mess in the
| repository?
| 
| Do you know the best way of merging 'silver' into 'trunk'? I think
| you once compared these versions and said there was really very
| little difference. Right?

diff compares files, not history or ancestry. 
merge likes to have ancestry, so if you're doing star-merge and the
branches don't have common ancestry, typically SVK/SVK will first
delete then add (which you may think is silly but without ancestry,
that is a reasonable thing to do).  That has the effect of
"duplicating" files.

| Are we prepared to cut the automatic connection with Tim's original
| axiom--silver--1? I believe Tim stated that he was no longer prepared
| to maintain this branch anyway. So I assume "yes".
| 
| By 252 to 31 do you mean there are 6 copies of the gcl-2.6.8pre
| tarball? I.e. 6 x 20 Mb = 120 Mb.

Do we do that before or after my changes I'm testing?  My changes
means we now have gcl/ and noweb/ toplevel subdirectories, and the
corresponding tarballs are gone; lsp/ is renamed to src/lisp.

\start
Date: Wed, 29 Nov 2006 05:21:25 -0500
From: Alfredo Portes
To: Bill Page
Subject: AxiomBinaries

Hi Bill,

I wonder if the content of
http://wiki.axiom-developer.org/SandBoxDoyen is good enough to
substitute http://wiki.axiom-developer.org/AxiomBinaries after you
created the table similar to what Tim proposed. Maybe also keep the
current AxiomBinaries as AxiomBinariesOld for the user comments it
contains.

\start
Date: Wed, 29 Nov 2006 12:02:58 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: the repository story (was: build-improvements on cygwin)

Gabriel Dos Reis wrote:
> Bill Page writes:
> | How can we agree on a single host and a single repository system?
> | 
> | > ... 
> | > I tried to check where disk space go.  After looking at rsynced copy
> | > of SF repository I see that most space is taken due to following
> | > revisions:
> | > 
> | > 201   80 Mb  failed arcs clone ???
> | > 208   80 Mb  current 'silver'
> | > 252
> | > 219
> | > 143
> | > 115
> | > 102
> | > 31    each 20Mb -- snapshots of gcl-2.6.8
> | > 
> | 
> | 200-201 and 205-212 where both failed attempts. (I kept getting the
> | name wrong in the Tailor configuration file.) I finally got it right
> | in 213-218. Perhaps there are in fact 3 copies of the arch clone?
> | Or did I somehow manage to rename one and re-use it?
> |

AFAICS 208 was renamed two times: the final rename is 213.
 
> | How can I clean-up such mistakes without leaving this mess in the
> | repository?
> | 

I do not know how to clean SourceForge: it seems that their policy
forbids really deleting thing, so cleanup maybe impossible without
staff help.  OTOH svn allow you to retrive changesets, so it should
be possible just to "replay" reasonable changes and create a new
somewhat clean repository -- but still containing all gcl madness
(and a lot of other trash).

I am affraid that the best thing we can do on SourceForge is to
update 'trunk' and delete 'silver'.

> | Do you know the best way of merging 'silver' into 'trunk'? I think
> | you once compared these versions and said there was really very
> | little difference. Right?
> 

Yes. I would retrive changesets from 'silver' and apply them to 'trunk'.
Then I would delete 'silver'.  If you guys think that this is a good idea
I can do this. 

> diff compares files, not history or ancestry. 
> merge likes to have ancestry, so if you're doing star-merge and the
> branches don't have common ancestry, typically SVK/SVK will first
> delete then add (which you may think is silly but without ancestry,
> that is a reasonable thing to do).  That has the effect of
> "duplicating" files.
> 

Reasonable thing to do?  I am not sure (GITs pack command factors files
into deltas even if they do not have common ancestry).  But what you
wrote seem to explain part of disk usage.

> | Are we prepared to cut the automatic connection with Tim's original
> | axiom--silver--1? I believe Tim stated that he was no longer prepared
> | to maintain this branch anyway. So I assume "yes".
> | 

IIRC Tim statement was about SourceForge.  My understanding was that
he will put things in axiom--silver--1 when they are ready.

> | By 252 to 31 do you mean there are 6 copies of the gcl-2.6.8pre
> | tarball? I.e. 6 x 20 Mb = 120 Mb.
> 

Yes.  In fact, I think that we have 10 copies (giving us 5 or 6 versions)
of the gcl-2.6.8pre: the two copies of arch (201 and 208) probably
contain 2 copies (2 different versions) of gcl-2.6.8pre each.

> Do we do that before or after my changes I'm testing?  My changes
> means we now have gcl/ and noweb/ toplevel subdirectories, and the
> corresponding tarballs are gone; lsp/ is renamed to src/lisp.
> 

It seems that you did not commit your changes.  I belive that in
current sitation we should drop gcl from our repository and just
provide a script to fetch desired version form gcl repository.

I think it is time to start working on a 'dist' target for make.
I would imagine that such target should fetch dependencies and
build some files which may be problematic for users and that
pack everthing into a tarball. 

FYI I recently succesfully recreated 142 viewports (all used in
HyperDoc) and almost all .pht files.  ATM recreating graphic files
requires acccess to running X server.  Also, the whole process is
somewhat fleaky, depending on little details it works or fails
-- it looks like random memory corruptions.  

Also, I have a script that recreated many of book images.

\start
Date: Wed, 29 Nov 2006 12:29:44 +0100 (CET)
From: Waldek Hebisch
To: Alfredo Portes
Subject: Re: AxiomBinaries

> I wonder if the content of
> http://wiki.axiom-developer.org/SandBoxDoyen is good enough to
> substitute http://wiki.axiom-developer.org/AxiomBinaries after you
> created the table similar to what Tim proposed. Maybe also keep the
> current AxiomBinaries as AxiomBinariesOld for the user comments it
> contains.
> 

Some comments:

1) The table looks really bad in Lynx (all tables look bad in Lynx,
but this one is worse then average).

2) The page seen to equate "Linux" with "i386 Linux".  I think we
should make clear an which architecture given tarball works. Significant
fraction of Linux users are on 64-bit systems and may prefer 64-bit
binaries.  Also, it seems that Debian (and only Debian) has binaries for
architectures different than i386 and amd64, but the page completly
missess such information.

3) The page mention setting multiple enviroment variables.  IMHO such
settings should be part of wrapper script (automatically updated at
installation time).  Of course, this is really fault of given tarball...

\start
Date: Wed, 29 Nov 2006 07:28:38 -0500
From: Bill Page
To: Tim Daly
Subject: RE: build-improvements on cygwin

On Tuesday, November 28, 2006 12:27 PM Tim Daly wrote:

> Bill Page asked:
> > "GIT only copies files when the checksums differ". Are you sure?
> > Are checksums that reliable? Can you give me a reference? But I
> > agree that GIT uses significantly less space than SVN (and
> > Mercurial uses even less).
>

Here is a reference:

http://en.wikipedia.org/wiki/Git_(software)

Mercurial is very similar:

http://www.selenic.com/mercurial/wiki/index.cgi/Design

except it also uses checksums to encode the object history.

> GIT computes the MD5SUM of each file and each subdirectory and of
> the whole tree. Only subtrees or files which have different MD5SUMs
> are every stored, copied or transmitted. Thus creating a copy and
> checking it in does almost nothing and takes almost no time to
> upload.
>

Actually SHA-1 hashes, not MD5, but the same principle applies.

> I know this works because I have switched to GIT for all of my
> personal work. Multiple copies of gcl-2.6.8pre.tgz take no additional
> space or time to transmit.
>

The multiple copies of gcl-2.6.8pre that we have been talking
about are nearly all slightly different pre-release versions. The
hash algorithm will ensure that each of these is treated as a new
and separate file, except for the extent to which GIT and Mercurial
can compute an efficient binary diff.

>...
> GIT does not store a local copy but only has to transmit the
> MD5SUM of the tree root or subdirectory to decide if changes
> occur.

???

I don't think that is correct in most cases. Check the contents of
the .git directory in your local repository. Most of the space is
in .git/objects where the files and deltas are stored based on their
hash keys (as you said earlier).

GIT and Mercurial are distributed source code control systems so
they must necessarily distribute the data. In contrast SVN and CVS
require a centralized repository.

> I'm not sure what SVN does.

SVN also stores a local copy of the repository. SVK uses this to
allow distributed source code control.

>
> You can see it in the numbers I just sent. Arch takes 305M,
> GIT takes 135M for the same copy of Axiom.
>

You are right that GIT and Mercurial repositories take about 1/2
the space of equivalent Arch and SVN repositories. Darcs is usually
intermediate between these two extremes.

\start
Date: 29 Nov 2006 15:14:16 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: the repository story (was: build-improvements on cygwin)

Waldek Hebisch writes:

[...]

| > diff compares files, not history or ancestry. 
| > merge likes to have ancestry, so if you're doing star-merge and the
| > branches don't have common ancestry, typically SVK/SVK will first
| > delete then add (which you may think is silly but without ancestry,
| > that is a reasonable thing to do).  That has the effect of
| > "duplicating" files.
| > 
| 
| Reasonable thing to do?

In the context of a system based on file ancestry, yes.

[...]

| > Do we do that before or after my changes I'm testing?  My changes
| > means we now have gcl/ and noweb/ toplevel subdirectories, and the
| > corresponding tarballs are gone; lsp/ is renamed to src/lisp.
| > 
| 
| It seems that you did not commit your changes.

no, but after an hour, SVN said:

Commit into mirrored path: merging back directly.
Waiting for editor...
Merging back to mirror source https://svn.sourceforge.net/svnroot/axiom.
RA layer request failed: MERGE request failed on
'/svnroot/axiom/branches/build-improvements': MERGE of
'/svnroot/axiom/branches/build-improvements': 500 Internal Server
Error (https://svn.sourceforge.net)
Please sync mirrored path /axiom/branches/build-improvements first.

when in fact my tree is up-to-date.  I'll merge bits and pieces.

\start
Date: Wed, 29 Nov 2006 17:32:22 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: gold/src/hyper/search.pamphlet

root wrote:
> quite curious that this code never worked and nobody noticed.
> 

Nothing strange.  Axiom contains a lot of unfinished code (or even
pure junk) and this is one more such piece.  I would not say that
nobody noticed -- my experience tells me that most users do not
bother reporting bugs.  Typical reaction is "X is junk" or "if I do
this in a such way then X works" (where "X" is a program).  Only
rare folks report bugs but it is easy to discourage them. In particular
you lose reporters when there is no reaction to bug reports or if bug
are not fixed for long time.  I must say that IssueTracker paints
a very bad picture of Axiom: numerous old unfixed bugs, many without
any usefull comment. 

\start
Date: Wed, 29 Nov 2006 12:01:48 -0500
From: Alfredo Portes
To: Waldek Hebisch
Subject: Re: AxiomBinaries

Thanks for the comments.

> Some comments:
>
> 1) The table looks really bad in Lynx (all tables look bad in Lynx,
> but this one is worse then average).

:-) . I need input from Bill, maybe is the DHTML.

> 2) The page seen to equate "Linux" with "i386 Linux".  I think we
> should make clear an which architecture given tarball works. Significant
> fraction of Linux users are on 64-bit systems and may prefer 64-bit
> binaries.

I forgot to add this, maybe because I did not see 64bit binaries in the old
page, but I will make the distinction.

> Also, it seems that Debian (and only Debian) has binaries for
> architectures different than i386 and amd64, but the page completly
> missess such information.

Do you mean by using apt-get?

> 3) The page mention setting multiple enviroment variables.  IMHO such
> settings should be part of wrapper script (automatically updated at
> installation time).  Of course, this is really fault of given tarball...

Would this be corrected when the new build procedure is done?

\start
Date: 29 Nov 2006 18:18:03 +0100
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: [Gcl-devel] Segmentation violation: c stack ok:signalling error with GCL-2.7.0 (cvs head)

Camm Maguire writes:

| Greetings!  You are missing the dsetq macro definition, found in
| vmlisp.lisp, and used here for example in your file:
| 
| (DEFUN |centerNoHighlight| (&REST #1=#:G4770 &AUX |argList| |text|) 
|        (DSETQ (|text| . |argList|) #1#) (|sayBrightly| (|center| |text| |argList|)))
| 
| If dsetq is assumed a function, as is the default, this will not
| compile.  With the definition, it compiles fine.
| 
| In general, the lisp produced by axiom will need some work to conform
| to ansi package semantics, if this is ever desired.  In particular,
| one needs to insure that the symbol vmlisp::dsetq and boot::dsetq are
| the same.  Here is one way:
| 
| (make-package "VMLISP" :use '(lisp))
| (make-package "BOOT" :use '(lisp vmlisp))
| (load "vmlisp.lisp")
| (in-package 'vmlisp)
| (export '(dsetq))
| (in-package 'user)
| (compile-file "msgdb.lsp")
| 
| 
| With the cltl1 semantics, one can skip the extra make-package and do
| similar with only in-package.
| 
| There are also many references to global variables.  If these are
| defvar'ed elsewhere, including this file too before compilation will
| reduce the warnings.

Dear Camm, thank you very much for looking into this.
vmlisp.lisp has become a kind of black hole attracting all kinds of
macros. 

We will make sure that that black hole stops growing, and in
particular there is only one symbol, dsetq and it is defined.

Yes, many people have suggested that it would be a good idea for Axiom
to move to ANSI semantics.

\start
Date: Wed, 29 Nov 2006 12:42:16 -0500
From: Bill Page
To: Alfredo Portes, Waldek Hebisch
Subject: RE: AxiomBinaries

> -----Original Message-----
> From:
> axiom-developer-bounces+bill.page1=synthesis.anikast.ca@nongnu
=synthesis.anikast.ca@nongnu.org] On Behalf Of Alfredo Portes
> Sent: Wednesday, November 29, 2006 12:02 PM
> To: Waldek Hebisch
> Cc: axiom-dev
> Subject: Re: AxiomBinaries
>
> Thanks for the comments.
>
> > Some comments:
> >
> > 1) The table looks really bad in Lynx (all tables look bad in Lynx,
> > but this one is worse then average).
>

If you must use Lynx, then you should probably be reading the
source format of the wiki pages rather than the rendered form.
Try

http://wiki.axiom-developer.org/SandBoxDoyen/src

But I think it is unrealistic to design a web site to support
a text-only browser.

> :-) . I need input from Bill, maybe is the DHTML.

No, I am sure that Lynx would just ignore the javascript, but there
is nothing like that in these tables. The reStructuredText source
format of the tables is rendered as common HTML.

> > 2) The page seen to equate "Linux" with "i386 Linux".  I think we
> > should make clear an which architecture given tarball
> > works. Significant
> > fraction of Linux users are on 64-bit systems and may prefer 64-bit
> > binaries.
>
> I forgot to add this, maybe because I did not see 64bit
> binaries in the old page, but I will make the distinction.
>

You need to think carefully about how to layout the information.
I would suggest replacing the Gold and Silver heading with a
hardware heading. Then put the Gold and Silver versions in two
separate tables. But maybe we are being a little two ambitious?
Who is going to generate all of these binaries and from what
version of the source? How will they be kept reasonably current?

> > Also, it seems that Debian (and only Debian) has binaries for
> > architectures different than i386 and amd64, but the page
> > completly missess such information.
>

I know people have built Axiom on both IA64 and amd64 (x86)
platforms. We were hoping that many some of them might contribute
a binary tarball for inclusion on the web site. So far, as far
as I know only Tim and I have actually uploaded binaries.

> Do you mean by using apt-get?

Debian has a large compile farm which can be configured to
automatically post new binary versions from updated sources.

There of course (or soon will be) also versions of Axiom for
Solaris/sparc and OSX/PPC.

>
> > 3) The page mention setting multiple enviroment variables. 
> >    IMHO such settings should be part of wrapper script
> >    (automatically updated at installation time).  Of course,
> >    this is really fault of given tarball...
>
> Would this be corrected when the new build procedure is done?
>

All of the binaries available now (except for Debian) have been
created by an adhoc manual process.

In a separate thread Waldek mentioned the need for a

 # make dist

script that would automatically build a complete Axiom distribution
with proper wrapper scripts and possibly also automatic installation
programs (such as the one included now with the Axiom on Windows
binary distribution.

\start
Date: Wed, 29 Nov 2006 12:22:11 -0500
From: Bill Page
To: Waldek Hebisch
Subject: RE: gold/src/hyper/search.pamphlet

On Wednesday, November 29, 2006 11:32 AM Waldek Hebisch wrote:
>
> root wrote:
> > quite curious that this code never worked and nobody noticed.
> >
>
> Nothing strange.  Axiom contains a lot of unfinished code (or even
> pure junk) and this is one more such piece.  I would not say that
> nobody noticed -- my experience tells me that most users do not
> bother reporting bugs.

I agree.

> Typical reaction is "X is junk" or "if I do this in a such way
> then X works" (where "X" is a program).  Only rare folks report
> bugs but it is easy to discourage them. In particular you lose
> reporters when there is no reaction to bug reports or if bug
> are not fixed for long time.

True.

> I must say that IssueTracker paints a very bad picture of Axiom:
> numerous old unfixed bugs, many without any usefull comment.
>

On the contrary, I think it represents the true state of Axiom.
I am sure that it even understates the case. There are many more
bugs of course that have been found by someone but not entered in
the tracking system. I think it would not be usual for a system as
complex as Axiom to have many 1000s of reported bugs. This is
certainly the case with both Maple and Mathematica - the only
difference is that for commercial strategic reasons they do not
make this information public. But Axiom is an open source project.

The true situation is that the Axiom project is critically short
of developers. It is also short of people willing to volunteer for
testing and updating bug reports. But some bugs have been fixed
and some bugs are continuing to be reported. And we have more
Axiom developers this year than last year, so it is not as bad
as it could be.

What suggestions do you have for improving the situation?

\start
Date: Wed, 29 Nov 2006 19:13:52 +0100 (CET)
From: Waldek Hebisch
To: Alfredo Portes
Subject: Re: AxiomBinaries

Alfredo Portes wrote:
> > Also, it seems that Debian (and only Debian) has binaries for
> > architectures different than i386 and amd64, but the page completly
> > missess such information.
> 
> Do you mean by using apt-get?
>

I think so.  I can not really check this (because I do not have such
a machine) but debian mirror shows packages for alpha, amd64, arm, hppa,
i386, ia64, m68k, mips, mipsel, powerpc, s390 and sparc. Some may
be considered 'unstable' (or work with different Debian version), but
at the first glance it looks like "full coverage" (Camm probably can
give an official statement about availability).

\start
Date: 29 Nov 2006 19:47:11 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: AxiomBinaries

Bill Page writes:

[...]

| In a separate thread Waldek mentioned the need for a
| 
|  # make dist
| 
| script that would automatically build a complete Axiom distribution
| with proper wrapper scripts and possibly also automatic installation
| programs (such as the one included now with the Axiom on Windows
| binary distribution.

In an old conversion with Tim (where we were tlaking about keeping GCL
source in or not), I mentioned that idealy we must have a Make target
dist and dist-check that build a distribution tarball (as opposed to
binary) and check that the tarball will actually build properly
(necessary on the platform being test).  Those Make targets come for
free when one uses Automake, but they need substantial work to
implement *correctly* if done by hand.  It is on my TODO list, but it
has lower priority.  The priority is first to bring the system to a
state where we can test on more plaforms without having to duplicate
information or work.  We are getting closer and closer to the goal.
More the moment, I'm happing to have GCL ncluded as source code.

\start
Date: Wed, 29 Nov 2006 14:31:11 -0500
From: Alfredo Portes
To: Bill Page
Subject: Re: AxiomBinaries

> You need to think carefully about how to layout the information.
> I would suggest replacing the Gold and Silver heading with a
> hardware heading. Then put the Gold and Silver versions in two
> separate tables. But maybe we are being a little two ambitious?
> Who is going to generate all of these binaries and from what
> version of the source? How will they be kept reasonably current?

I was thinking that maybe there should be only binaries using Gold.
What is the release time frame for Axiom? I mean with this that if it is every
6 months then at the point we create Binaries from Gold. Of course this
assumes that the work done in Silver(gold to be) and its branches will be
included in Gold.

\start
Date: Wed, 29 Nov 2006 20:38:27 +0100
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: re: [Gcl-devel] Segmentation violation: c
Cc: Camm Maguire

Le mercredi 29 novembre 2006 =E0 18:18 +0100, Gabriel Dos Reis a =E9crit =
:

[...]

>
> Dear Camm, thank you very much for looking into this.
> vmlisp.lisp has become a kind of black hole attracting all kinds of
> macros.
>
> We will make sure that that black hole stops growing, and in
> particular there is only one symbol, dsetq and it is defined.

Since you speak about this, the 'asec' function in vmlisp.lisp is
defined two times for gcl and cmucl. Kai Kaminski "literated" this file
some times ago, he probably fixed this issue.

\start
Date: 29 Nov 2006 21:07:32 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements on cygwin

Bill Page writes:

| On Tuesday, November 28, 2006 6:00 PM Gaby wrote:
| 
| > Ben Collins-Sussman writes:
| > ... 
| > | I can reset the google repository to revision 0 if you'd like.
| > 
| > That would be very much appreciated.
| > 
| > Bill, before your mirror to the next new repo, please let me
| > make sure that we don't store gcl and noweb as .tar.gz anymore.
| > 
| 
| Yes, we discussed this previously and I had agreed to commit a
| change so that both gcl and noweb appear as source in a new 'tools'
| directory. 

It should be done by now.

If SF/SVN server keeps its promises, you should experiment some
failures during  the next update.  You just have be patient ans start over
again until the update is finished.  I would still appreciate if you
could wait more before starting the mirror to Google again.

\start
Date: Wed, 29 Nov 2006 15:25:02 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: re: [Gcl-devel] Segmentation violation: cstack ok:signalling error with GCL-2.7.0 (cvs head)
Cc: Camm Maguire

On Wednesday, November 29, 2006 2:38 PM Vanuxem Gregory wrote:
>
> Le mercredi 29 novembre 2006 =E0 18:18 +0100, Gabriel Dos Reis a =
=E9crit :
> [...]
>
> > vmlisp.lisp has become a kind of black hole attracting all
> > kinds of macros.
> >
> > We will make sure that that black hole stops growing, and in
> > particular there is only one symbol, dsetq and it is defined.
>
> Since you speak about this, the 'asec' function in vmlisp.lisp is
> defined two times for gcl and cmucl. Kai Kaminski "literated"
> this file some times ago, he probably fixed this issue.
>

You should pull the updated source from the src link here:

http://wiki.axiom-developer.org/axiom--test--1/src/interp/VmlispLisp

\start
Date: Thu, 30 Nov 2006 02:28:18 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: re: [Gcl-devel] Segmentation violation: cstack ok:signalling error with GCL-2.7.0 (cvs head)
Cc: Camm Maguire

Le mercredi 29 novembre 2006 =E0 15:25 -0500, Page, Bill a =E9crit :
> On Wednesday, November 29, 2006 2:38 PM Vanuxem Gregory wrote:
> >
> > Le mercredi 29 novembre 2006 =E0 18:18 +0100, Gabriel Dos Reis a =E9c=
rit :
> > [...]
> >
> > > vmlisp.lisp has become a kind of black hole attracting all
> > > kinds of macros.
> > >
> > > We will make sure that that black hole stops growing, and in
> > > particular there is only one symbol, dsetq and it is defined.
> >
> > Since you speak about this, the 'asec' function in vmlisp.lisp is
> > defined two times for gcl and cmucl. Kai Kaminski "literated"
> > this file some times ago, he probably fixed this issue.
> >
>
> You should pull the updated source from the src link here:
>
> http://wiki.axiom-developer.org/axiom--test--1/src/interp/VmlispLisp
>

I'm going to suppress the Juergen Weiss's asec definition.

And just for the fun, here is its definition :

#+:(or :cmu :akcl :gcl)
(defun asec (a)
  (if (and (a > -1.0) (a < 1.0))
    0.0
    (acos (/ 1.0 a))))

And no one sees the errors :-)

\start
Date: Wed, 29 Nov 2006 20:46:06 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: Re: [Axiom-commit] flush
Cc: Waldek Hebisch

in fact, this is a known bug (see src/input/Makefile.pamphlet)
and search for FLUSH.

the package, attached below, makes no reference to how it is used
but it is intended to print lines which do not contain line-feeds
thus requiring the call to flush.

the correct fix would be to add the line:

(defun flush () (force-output))

in vmlisp.lisp


====================================================================

)abbrev package IPRNTPK InternalPrintPackage
++ Author: Themos Tsikas
++ Date Created: 09/09/1998
++ Date Last Updated: 09/09/1998
++ Basic Functions:
++ Related Constructors:
++ Also See: 
++ AMS Classifications:
++ Keywords:
++ References:
++ Description: A package to print strings without line-feed 
++ nor carriage-return.

InternalPrintPackage(): Exports == Implementation where

  Exports ==  with
     iprint: String -> Void
       ++ \axiom{iprint(s)} prints \axiom{s} at the current position 
       ++ of the cursor.

  Implementation == add
     iprint(s:String) == 
          PRINC(coerce(s)@Symbol)$Lisp
          FLUSH()$Lisp

\start
Date: Wed, 29 Nov 2006 21:20:51 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: re: [Gcl-devel] Segmentation violation:cstack ok:signalling error with GCL-2.7.0 (cvs head)
Cc: Camm Maguire

On Wednesday, November 29, 2006 8:28 PM Vanuxem Gregory wrote:
>
> Le mercredi 29 novembre 2006 =E0 15:25 -0500, Page, Bill a =E9crit :
> > On Wednesday, November 29, 2006 2:38 PM Vanuxem Gregory wrote:
> > >
> > > Le mercredi 29 novembre 2006 =E0 18:18 +0100, Gabriel Dos
> Reis a =E9crit :
> > > [...]
> > >
> > > > vmlisp.lisp has become a kind of black hole attracting all
> > > > kinds of macros.
> > > >
> > > > We will make sure that that black hole stops growing, and in
> > > > particular there is only one symbol, dsetq and it is defined.
> > >
> > > Since you speak about this, the 'asec' function in vmlisp.lisp is
> > > defined two times for gcl and cmucl. Kai Kaminski "literated"
> > > this file some times ago, he probably fixed this issue.
> > >
> >
> > You should pull the updated source from the src link here:
> >
> > http://wiki.axiom-developer.org/axiom--test--1/src/interp/VmlispLisp
> >
>
> I'm going to suppress the Juergen Weiss's asec definition.
>
> And just for the fun, here is its definition :
>
> #+:(or :cmu :akcl :gcl)
> (defun asec (a)
>   (if (and (a > -1.0) (a < 1.0))
>     0.0
>     (acos (/ 1.0 a))))
>
> And no one sees the errors :-)
>

I think this may be "reasonable" compromize definition for a
function with signature

  Float -> Float

Juergen recognized this pecularity.

On 29 Oct 2003 14:35:25 +0100 Juergen Weiss wrote:

> Here the lisp version of the C versions in csl
> One problem: the formula may work for real arguments
> only.
>
>
> ;; stolen from csl
> #+(or :cmu :akcl)
> (defun cot (a)
>   (if (or (> a 1000.0) (< a -1000.0))
>       (/ (cos a) (sin a))
>     (/ 1.0 (tan a))))
>
> ;; stolen from csl
> #+(or :cmu :akcl)
> (defun asec (a)
>   (if (and (a > -1.0) (a < 1.0))
>      0.0
>     (acos (/ 1.0 a))))
>

Perhaps a better argument checking would be a good idea, but
obviously Axiom does not try to call this asec function for
real values between -1 and 1.

(1) -> )cl all
   All user variables and function definitions have been cleared.
(1) -> asec(1.9)$Float

   (1)  1.0165344923 4256851184
                                                     Type: Float
(2) -> asec(0.9)$Float

   >> Error detected within library code:
   acos: argument > 1 in magnitude

protected-symbol-warn called with (NIL)
(2) -> asec(0.9)$Complex(Float)

   (2)  3.1415926535 8979323846 + 0.4671453081 0326201812 8 %i
                                              Type: Complex Float

\start
Date: Thu, 30 Nov 2006 03:34:54 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: [Axiom-commit] flush

root wrote:
> 
> in fact, this is a known bug (see src/input/Makefile.pamphlet)
> and search for FLUSH.
> 
> the package, attached below, makes no reference to how it is used
> but it is intended to print lines which do not contain line-feeds
> thus requiring the call to flush.
> 
> the correct fix would be to add the line:
> 
> (defun flush () (force-output))
> 
> in vmlisp.lisp
> 

Well, I think that this very well illustrates problems with Axiom:
there is a known bug which hampers usage of an important package
(the REGSET package). When the bug is fixed you fuss over edge cases
in underspecified internal package.

Note that flushing output should be done when the outupt is complete,
while iprint clearly is used to compose bigger units from small parts.
But if you insist I may add a FORCE_-OUTPUT call to iprint (there is
no reason to have extra flush function).

\start
Date: 30 Nov 2006 03:41:25 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] flush

Waldek Hebisch writes:

| root wrote:
| > 
| > in fact, this is a known bug (see src/input/Makefile.pamphlet)
| > and search for FLUSH.
| > 
| > the package, attached below, makes no reference to how it is used
| > but it is intended to print lines which do not contain line-feeds
| > thus requiring the call to flush.
| > 
| > the correct fix would be to add the line:
| > 
| > (defun flush () (force-output))
| > 
| > in vmlisp.lisp
| > 
| 
| Well, I think that this very well illustrates problems with Axiom:
| there is a known bug which hampers usage of an important package
| (the REGSET package). When the bug is fixed you fuss over edge cases
| in underspecified internal package.

I must confess, however, that I get very nervous when codes are deleted.
(And I do confess I delete codes too).  It is good you've looked into
that problem.  Edge cases are also part of fixing bugs, so I believe I
feel like Tim on this particular topic.

| Note that flushing output should be done when the outupt is complete,
| while iprint clearly is used to compose bigger units from small parts.
| But if you insist I may add a FORCE_-OUTPUT call to iprint (there is
| no reason to have extra flush function).

Could you write up this kind of insight in the pamphlets?  It would be
useful for some of us in the future.

\start
Date: Wed, 29 Nov 2006 21:51:25 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: Re: [Axiom-commit] flush
Cc: list

sigh.

> Well, I think that this very well illustrates problems with Axiom:
> there is a known bug which hampers usage of an important package
> (the REGSET package). When the bug is fixed you fuss over edge cases
> in underspecified internal package.
> 
> Note that flushing output should be done when the outupt is complete,
> while iprint clearly is used to compose bigger units from small parts.
> But if you insist I may add a FORCE_-OUTPUT call to iprint (there is
> no reason to have extra flush function).

Deleting the call to flush breaks the existing semantics of the package.
You are welcome to define that as "fussing over edge cases".

FLUSH was probably a function defined in CCL.

Calling FORCE_-OUTPUT is a correct change.

Alternatively you could call the function StreamFlush()$LISP
which is already defined in interp/unlisp.lisp.

\start
Date: Thu, 30 Nov 2006 13:17:10 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: [vmlisp.lisp] Remove the asec chunk and its documentation
Cc: Camm Maguire

Greg,

Did you verify that you can successfully build Axiom with this
modification to vmlisp.lisp.pamphlet?

Regards,
Bill Page.

On November 30, 2006 1:02 PM greg write:
> To: MathAction
> Subject: [vmlisp.lisp] Remove the asec chunk and its documentation
>
>
> Changes
> http://wiki.axiom-developer.org/axiom--test--1/src/interp/Vmli
> spLisp/diff
> --
>
> ??changed:
> 
> -\subsection{The arc cotangent function}
> +\subsection{The cotangent function}
>  Contributed by Juergen Weiss from Arthur Norman's CCL.
>
> --removed:
> 
> -\subsection{The arc cotangent function}
> -Contributed by Juergen Weiss from Arthur Norman's CCL.
> -<<asec>>=
> -#+:(or :cmu :akcl :gcl)
> -(defun asec (a)
> -  (if (and (a > -1.0) (a < 1.0))
> -    0.0
> -    (acos (/ 1.0 a))))
> -@
> 
>
> --removed:
>  <<cot>>
> -<<asec>>
>  <<getCD>>
>
> --
> forwarded from
>
http://wiki.axiom-developer.org/axiom--test--1/src/interp/VmlispLisp#msg2=
006
1130120139-0600@wiki.axiom-developer.org


On November 29, 2006 8:28 PM Vanuxem Gregory wrote:
>
> Le mercredi 29 novembre 2006 =E0 15:25 -0500, Page, Bill a =E9crit :
> > On Wednesday, November 29, 2006 2:38 PM Vanuxem Gregory wrote:
> > >
> > > Le mercredi 29 novembre 2006 =E0 18:18 +0100, Gabriel Dos
> Reis a =E9crit :
> > > [...]
> > >
> > > > vmlisp.lisp has become a kind of black hole attracting all
> > > > kinds of macros.
> > > >
> > > > We will make sure that that black hole stops growing, and in
> > > > particular there is only one symbol, dsetq and it is defined.
> > >
> > > Since you speak about this, the 'asec' function in vmlisp.lisp is
> > > defined two times for gcl and cmucl. Kai Kaminski "literated"
> > > this file some times ago, he probably fixed this issue.
> > >
> >
> > You should pull the updated source from the src link here:
> >
> > http://wiki.axiom-developer.org/axiom--test--1/src/interp/VmlispLisp
> >
>
> I'm going to suppress the Juergen Weiss's asec definition.
>
> And just for the fun, here is its definition :
>
> #+:(or :cmu :akcl :gcl)
> (defun asec (a)
>   (if (and (a > -1.0) (a < 1.0))
>     0.0
>     (acos (/ 1.0 a))))
>
> And no one sees the errors :-)

\start
Date: Thu, 30 Nov 2006 19:27:11 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: re: [Gcl-devel] Segmentation violation:cstack ok:signalling error with GCL-2.7.0 (cvs head)

Le mercredi 29 novembre 2006 =E0 21:20 -0500, Page, Bill a =E9crit :

[...]

> I think this may be "reasonable" compromize definition for a
> function with signature
>
>   Float -> Float
>
> Juergen recognized this pecularity.
>
> On 29 Oct 2003 14:35:25 +0100 Juergen Weiss wrote:
>
> > Here the lisp version of the C versions in csl
> > One problem: the formula may work for real arguments
> > only.
> >
> >
> > ;; stolen from csl
> > #+(or :cmu :akcl)
> > (defun cot (a)
> >   (if (or (> a 1000.0) (< a -1000.0))
> >       (/ (cos a) (sin a))
> >     (/ 1.0 (tan a))))
> >
> > ;; stolen from csl
> > #+(or :cmu :akcl)
> > (defun asec (a)
> >   (if (and (a > -1.0) (a < 1.0))
> >      0.0
> >     (acos (/ 1.0 a))))
> >
>
> Perhaps a better argument checking would be a good idea, but
> obviously Axiom does not try to call this asec function for
> real values between -1 and 1.

It seems that you did not notice the errors, as me at first glance:

(and (a > -1.0) (a < 1.0))

This is not Lisp code :-)

This function is meant to be used only with DoubleFloat and effectively
it is called. The avantage, for me, of the other definition is that,
combined with C-TO-R, it throws a library error : "Result is not real"
and do not return 0. Of course it can be easily implemented in Spad.

> (1) -> )cl all
>    All user variables and function definitions have been cleared.
> (1) -> asec(1.9)$Float
>
>    (1)  1.0165344923 4256851184
>                                                      Type: Float
> (2) -> asec(0.9)$Float
>
>    >> Error detected within library code:
>    acos: argument > 1 in magnitude
>
> protected-symbol-warn called with (NIL)
> (2) -> asec(0.9)$Complex(Float)
>
>    (2)  3.1415926535 8979323846 + 0.4671453081 0326201812 8 %i
>                                               Type: Complex Float

For Float, Complex(Float) and Complex(DoubleFloat) the Lisp asec
function is not used. I haven't looked at this recently but I think in
these cases, the definition comes from the
ArcTrigonometricFunctionCategory category.

\start
Date: Thu, 30 Nov 2006 19:40:28 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: Re: [vmlisp.lisp] Remove the asec chunk and its documentation
Cc: Camm Maguire

Le jeudi 30 novembre 2006 =E0 13:17 -0500, Bill Page a =E9crit :
> Greg,
>
> Did you verify that you can successfully build Axiom with this
> modification to vmlisp.lisp.pamphlet?

I have only tested a recompilation of this file, not a complete build of
Axiom. If a full recompilation of Axiom is necessary I prefer to revert
this change (I don't want to recompile Axiom just for this simple
modification).

\start
Date: Thu, 30 Nov 2006 19:56:31 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: Re: [vmlisp.lisp] Remove the asec chunk and its documentation
Cc: Camm Maguire

Le jeudi 30 novembre 2006 =E0 19:40 +0100, Vanuxem Gregory a =E9crit :
> Le jeudi 30 novembre 2006 =E0 13:17 -0500, Bill Page a =E9crit :
> > Greg,
> >
> > Did you verify that you can successfully build Axiom with this
> > modification to vmlisp.lisp.pamphlet?
>
> I have only tested a recompilation of this file, not a complete build o=
f
> Axiom. If a full recompilation of Axiom is necessary I prefer to revert
> this change (I don't want to recompile Axiom just for this simple
> modification).

I forgot to say that what I have removed is ununsed code since the
"missing DFLOAT functions" overwrite it. But I have to admit that I did
not test my change (recompiling vmlisp.lisp). Checked after reading your
mail.

\start
Date: Thu, 30 Nov 2006 15:16:19 -0400
From: Humberto Zuazaga
To: list
Subject: File name conflicts on brain dead filesystems

In the build-improvements branch there still is one filename conflict on 
Mac OS X:

CHANGELOG - ChangeLog

svk didn't choke when I checked out the source, it just overwrites 
CHANGELOG with ChangeLog and then claims I modified the file.

\start
Date: Thu, 30 Nov 2006 14:43:02 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: re: [Gcl-devel] Segmentationviolation:cstack ok:signalling error with GCL-2.7.0 (cvs head)

On November 30, 2006 1:27 PM Vanuxem Gregory wrote:
> ... 
> > On 29 Oct 2003 14:35:25 +0100 Juergen Weiss wrote:
> > 
> > > Here the lisp version of the C versions in csl
> > > One problem: the formula may work for real arguments
> > > only.
> > >
> > >
> > > ;; stolen from csl
> > > #+(or :cmu :akcl)
> > > (defun cot (a)
> > >   (if (or (> a 1000.0) (< a -1000.0))
> > >       (/ (cos a) (sin a))
> > >     (/ 1.0 (tan a))))
> > >
> > > ;; stolen from csl
> > > #+(or :cmu :akcl)
> > > (defun asec (a)

-       (if (and (a > -1.0) (a < 1.0))
+       (if (and (> a -1.0) (< a 1.0))

> > >      0.0
> > >     (acos (/ 1.0 a))))
> > >
> > 
> > Perhaps a better argument checking would be a good idea, but
> > obviously Axiom does not try to call this asec function for
> > real values between -1 and 1.
> 
> It seems that you did not notice the errors, as me at first glance:
> 
> (and (a > -1.0) (a < 1.0))
> 
> This is not Lisp code :-)
>

Oh! Duh, <embarrassment> ...

So this doesn't cause an error when compiling Axiom with GCL?
Does  #+(or :cmu :akcl cause it to be excluded?

But maybe for the sake of other lisp targets rather than deleting
it, maybe re-writing it to correct the error would be better?

Anyway. No problem. You decide.

\start
Date: 30 Nov 2006 22:02:54 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: Re: File name conflicts on brain dead filesystems

Humberto Zuazaga writes:

| In the build-improvements branch there still is one filename conflict
| on Mac OS X:
| 
| CHANGELOG - ChangeLog
| 
| svk didn't choke when I checked out the source, it just overwrites
| CHANGELOG with ChangeLog and then claims I modified the file.

shrug.  I'll rename it.

\start
Date: Thu, 30 Nov 2006 19:40:32 -0400
From: Humberto Zuazaga
To: list
Subject: openpty patch again

I'm resubmitting a shorter version of a 300K patch I sent this
morning. This time I generated the patch without the diffs for configure
and a couple of Makefile.in files. I guess my version of configure is
different from Gaby's, it basically changed every line in configure.

I think I got a working build of axiom on Mac OS X 10.4 again.

http://www.hpcf.upr.edu/~humberto/axiom-macos-ppc-20061130.tar.gz

untar this somewhere, then point AXIOM at the
target/powerpc-apple-darwin8.8.0 directory:

$ tar zxf axiom-macos-ppc-20061130.tar.gz
$ export AXIOM=`pwd`/target/powerpc-apple-darwin8.8.0
$ PATH=$AXIOM/bin:$PATH
$ axiom

Success!

This was built from the svk mirror:

$ svk info
Checkout Path: /Users/humberto/src/axiom/build-improvements
Depot Path: /mirror/axiom/branches/build-improvements
Revision: 328
Last Changed Rev.: 327
Mirrored From: https://svn.sourceforge.net/svnroot/axiom, Rev. 327
Copied From: /axiom/trunk/axiom, Rev. 32
Merged From: /axiom/trunk/axiom, Rev. 32

that I checked out on Tuesday. That revision builds on Mac OS X, but
axiom won't work because sman and clef build without working pty support
(AXIOMsys does work).

I reworked Waldek's better pty patch to work with the new
config/axiom-c-macro.h file, and to check for the proper include file
for openpty, at least on Mac and linux. I don't know if ptys work on MS
Windows.

The original openpty patch is:

http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00236.html

My version is below.

The procedure to build this version of axiom is not too bad. Fink still
seems to cause problems if the build machinery can see it, so I delete
it from the path. One caveat is that you need latex, makeindex, and
maybe tex for the axiom build to succeed, so I install them from fink,
and link them to /usr/local/bin.


$ PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin
$ ./configure
$ make

The darn build takes like 6 hours on my dual G5 2.5 GHz Mac.

I have some doubts about the patch, since I'm not really sure how to
build configure, I'm not certain I did it right.

I don't have commit priviledges on the code base, and I don't want them
until I'm more familiar with svn/svk, so could someone else please check
in the patch?

Finally, this patch is against revision 326, because svk complains my
axiom tree isn't local when I try to revise the patch against the
current build-improvements head. I followed the svk instructions at:

http://wiki.axiom-developer.org/AxiomSilverBranch

but svk patch complains:
  
$ svk patch --view pty-again
Target not local nor mirrored, unable to view patch.

Anyway, here's the patch:

==== Patch <pty-again> level 1
Source: [No source]
Target: 54bea96e-1511-0410-8851-aaeae44645fa:/branches/build-improvements:326
        (https://svn.sourceforge.net/svnroot/axiom)
Log:

=== ChangeLog.build-improvements
==================================================================
--- ChangeLog.build-improvements	(revision 326)
+++ ChangeLog.build-improvements	(patch pty-again level 1)
@@ -1,3 +1,8 @@
+2006-11-29  Humberto Zuazaga
+
+	* configure.ac.pamphlet: added tests for openpty, pty.h,
+	util.h and libutil
+
 2006-11-26  Gabriel Dos Reis  Gabriel Dos Reis
 
 	* Makefile.pamphlet (build_srcdir): Restore from previous
=== config/axiom-c-macros.h.in
==================================================================
--- config/axiom-c-macros.h.in	(revision 326)
+++ config/axiom-c-macros.h.in	(patch pty-again level 1)
@@ -9,6 +9,12 @@
 /* Define to 1 if you have the <memory.h> header file. */
 #undef HAVE_MEMORY_H
 
+/* Define to 1 if you have the `openpty' function. */
+#undef HAVE_OPENPTY
+
+/* Define to 1 if you have the <pty.h> header file. */
+#undef HAVE_PTY_H
+
 /* Define to 1 if you have the <stdint.h> header file. */
 #undef HAVE_STDINT_H
 
@@ -30,6 +36,9 @@
 /* Define to 1 if you have the <unistd.h> header file. */
 #undef HAVE_UNISTD_H
 
+/* Define to 1 if you have the <util.h> header file. */
+#undef HAVE_UTIL_H
+
 /* Linux flavour */
 #undef LINUXplatform
 
=== config/var-def.mk
==================================================================
--- config/var-def.mk	(revision 326)
+++ config/var-def.mk	(patch pty-again level 1)
@@ -118,6 +118,7 @@
 
 AXIOM_X11_CFLAGS = @X_CFLAGS@ 
 AXIOM_X11_LDFLAGS = @X_LIBS@ @X_PRE_LIBS@ -lX11 @X_EXTRA_LIBS@
+EXTRA_LIBS = @EXTRA_LIBS@
 
 axiom_includes = -I$(axiom_src_srcdir)/include -I$(axiom_configdir)
 
=== configure.ac.pamphlet
==================================================================
--- configure.ac.pamphlet	(revision 326)
+++ configure.ac.pamphlet	(patch pty-again level 1)
@@ -676,8 +676,28 @@
 AC_CHECK_HEADER([regex.h], [], [AC_MSG_ERROR([Axiom needs <regex.h>])])
 @
 
+\subsubsection{openpty}
 
+[[clef]] and [[sman]] use ptys to communicate with [[AXIOMsys]]. The
+existing code in silver doesn't work on MacOS X. We will try to build
+with the Unix98 standard [[openpty]] function. We need to detect two
+headers and a library. Linux has openpty defined in [[pty.h]], MacOS X
+define it in [[util.h]]. FreeBSD is supposed to have a definition in
+[[libutil.h]].
 
+<<headers>>=
+AC_CHECK_HEADERS([pty.h util.h])
+@
+
+On linux the openpty function is in [[libutil]]. We need to add that to
+the list of libraries, at least for [[sman]] and [[clef]].
+
+<<extra libraries>>=
+AC_CHECK_FUNCS(openpty,, AC_CHECK_LIB(util,
+			openpty,[AC_DEFINE(HAVE_OPENPTY)] [EXTRA_LIBS="$EXTRA_LIBS -lutil"]))
+AC_SUBST(EXTRA_LIBS)
+@
+
 \section{A note about comments}
 \label{sec:comment}
 
@@ -718,6 +738,8 @@
 
 <<headers>>
 
+<<extra libraries>>
+
 <<locate X11>>
 
 <<define AXIOM>>
=== src/clef/ChangeLog.build-improvements
==================================================================
--- src/clef/ChangeLog.build-improvements	(revision 326)
+++ src/clef/ChangeLog.build-improvements	(patch pty-again level 1)
@@ -1,3 +1,7 @@
+2006-11-29  Humberto Zuazaga
+
+	* Makefile.pamphlet: add -lutil to clef link flags if needed
+
 2006-11-26  Gabriel Dos Reis  Gabriel Dos Reis
 
 	* edible.c.pamphlet: Include "axiom-c-macros.h"
=== src/clef/Makefile.pamphlet
==================================================================
--- src/clef/Makefile.pamphlet	(revision 326)
+++ src/clef/Makefile.pamphlet	(patch pty-again level 1)
@@ -23,7 +23,7 @@
 
 clef_objects = $(clef_sources:.c=.$(OBJEXT)) 
 
-clef_LDADD = -L$(abs_top_builddir)/src/lib -lspad
+clef_LDADD = -L$(abs_top_builddir)/src/lib -lspad $(EXTRA_LIBS)
 clef_DEPENDENCIES =
 @
 
=== src/lib/ChangeLog.build-improvements
==================================================================
--- src/lib/ChangeLog.build-improvements	(revision 326)
+++ src/lib/ChangeLog.build-improvements	(patch pty-again level 1)
@@ -1,3 +1,7 @@
+2006-11-29  Humberto Zuazaga
+
+	* openpty.c.pamphlet: use openpty if available
+
 2006-11-26  Gabriel Dos Reis  Gabriel Dos Reis
 
 	* XDither.c.pamphlet: Include axiom-c-macros.h
=== src/lib/openpty.c.pamphlet
==================================================================
--- src/lib/openpty.c.pamphlet	(revision 326)
+++ src/lib/openpty.c.pamphlet	(patch pty-again level 1)
@@ -10,17 +10,9 @@
 \tableofcontents
 \eject
 \section{MAC OSX and BSD platform changes}
-Since we have no other information we are adding the [[MACOSXplatform]] variable
-to the list everywhere we find [[LINUXplatform]]. This may not be correct but
-we have no way to know yet. We have also added the [[BSDplatform]] variable.
-MAC OSX is some variant of BSD. These should probably be merged but we
-cannot yet prove that.
-<<mac osx platform change 1>>=
-#if defined(SUN4OS5platform) ||defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(MACOSXplatform) || defined(BSDplatform)
-@
-<<mac osx platform change 2>>=
-#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(MACOSXplatform) || defined(BSDplatform)
-@
+We should really use autotools to check for Unix 98 pty support.
+Before this is done below we hardcode information about each platform.
+
 \section{License}
 <<license>>=
 /*
@@ -71,6 +63,11 @@
 #include <stropts.h>
 #endif
 
+#ifdef HAVE_PTY_H
+#include <pty.h>
+#elifdef HAVE_UTIL_H
+#include <util.h>
+#endif
 
 #include "openpty.H1"
 
@@ -97,6 +94,9 @@
 int  
 ptyopen(int *controller,int * server, char *controllerPath,char * serverPath)
 {
+#ifdef HAVE_OPENPTY
+  return openpty(controller, server, serverPath, 0, 0);
+#else
 #if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) ||defined(AIX370platform) || defined(BSDplatform)
   int looking = 1, i;
   int oflag = O_RDWR;                  /* flag for opening the pty */
@@ -140,7 +140,8 @@
   return(fdm);
 #endif
 
-<<mac osx platform change 1>>
+/* MAC OS X 10.3 does not support Unix 98 pty's */
+#if defined(SUN4OS5platform) ||defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(BSDplatform)
 extern int grantpt(int);
 extern int unlockpt(int);
 extern char* ptsname(int);
@@ -192,6 +193,7 @@
   return (*controller);
 
 #endif
+#endif
 }
 
 
@@ -204,7 +206,7 @@
 	sprintf(serv, "/dev/ttyp%02x", channelNo);
 	channelNo++;
 #endif
-<<mac osx platform change 2>>
+#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(MACOSXplatform) || defined(BSDplatform)
 	static int channelNo = 0;
 	static char group[] = "pqrstuvwxyzPQRST";
 	static int groupNo = 0;
=== src/sman/ChangeLog.build-improvements
==================================================================
--- src/sman/ChangeLog.build-improvements	(revision 326)
+++ src/sman/ChangeLog.build-improvements	(patch pty-again level 1)
@@ -1,3 +1,7 @@
+2006-11-29  Humberto Zuazaga
+
+	* Makefile.pamphlet: add -lutil to sman link flags if needed
+
 2006-11-26  Gabriel Dos Reis  Gabriel Dos Reis
 
 	* nagman.c.pamphlet: Include axiom-c-macros.h.
=== src/sman/Makefile.pamphlet
==================================================================
--- src/sman/Makefile.pamphlet	(revision 326)
+++ src/sman/Makefile.pamphlet	(patch pty-again level 1)
@@ -47,7 +47,7 @@
 sman_sources = sman.c
 sman_SOURCES = $(addsuffix .pamphlet, $(sman_sources))
 sman_objects = $(sman_sources:.c=.$(OBJEXT))
-sman_LDADD = -L$(build_libdir) -lspad
+sman_LDADD = -L$(build_libdir) -lspad $(EXTRA_LIBS)
 sman_DEPENDENCIES =
 
 

==== BEGIN SVK PATCH BLOCK ====
Version: svk 1.08 (darwin)

eJy1WOtvG8cRP6BAEJ+DJg0cpN+6jRlYNkTq9nZv706xBcmyDBvxK5Kc2lYFZW93T7z6eMfeQ4+Y
LSTXdus8nH5JgSBBCwTo5xYBWiCf+q91dklKlE3RBooChERyZ2bn8Zv5zfFysfrBPO7NzTm9BnZ6
Kx9/ODt7i1ei/T58arCekkmVFw2vl6otlTZIL803G7SX8Y6C04oXm6qam8OgHPSVl4zC0AjVNiJe
5VnZCI2xjapQquH2MJvHfm/e7c0TUO5hOM67Ktso8ryCa4gbwNmG9kmkeak2tO6814MXSLtD6ThJ
wVjQW2zzbFNdyzdbUZ2kspl0ukW+pToqq0pjvW/RKJMGpn1tmRRKgLe74KTIszjZfF6WHb0ID8Tq
QrW4aHV5p9tOVfW8lj/mBtIrCzEiSHRw3iC4QzEQ0Dnx+qe82013Nyq1U0mVVtxETtxeoAQLAzfG
ocCYhyEJ4pBiJV3p4SD2nQZmGKpxw7L2//qL/b+de33/5N7+Sf3Bch2HNTFuuiFCV+pOpIoqRzeL
Kvm0ea/mn/JNjs63B9/Pt7sibtXdoqVkPWfbJ86hseHPIi6lkqhSZVWiOC+Qjr1b7U4j+NNqT9sn
6ipJW23EM4nSJNKfbHuejtbXJHgQH4mpIqFgUQThuKHPIuk7wpUuj4UXRh4kr59oerQ8wyrO8J0k
7zRFs8NFkZetdivJTOFHauQdUQUoDlS3eNGUKm517o9oHFssMrFYVAfDuYxdFgSSeY7rMUeoyJE8
FCIKo4gGDqDK7RfrC/rsnbf3mfUwtPZ+az269PCdvSXrcfRk+ZNBPs+guM5EleRZC52bsU/XGXiK
rix8vLRx89bSjVurd2175hy6pOIkUwgKi1ESo928Rm2+BV+0FTpvKjKH2opLVSAd/Au2bq1OtNCv
5WQTt1evXhtbX5MShWPuM8UDHxLi+j5XlAYscF0vErHEamJSPW3BZTIICMDCx8Tj3I9DwqkHiY2U
IA6Hunn9nH5/6vuW/VPruzesZ9aTU99ZS3dWlxc2rl29uIIuoPmxLpoLMI6JTz2O/cAhUjGPShZK
7jIiIsVZMNFFpi34JI7dCGyo0NUv7lOAMMGKQsEVww3fDwZN+mOx/x9+6nHb2v/HSWvv8T3raQ/e
PbOK/R+tX5d1pF/K1P3BAAm/s+21NZGqeH3dNNXaWtnhGXyoS6WbrtS1E3mnU2eJ4JVC20nVBqmF
O1dvXi93y/X1FlptK1vtJGWVZJsgKxVKMlQm6RYUVeaqzM5UaDsv7qM8Q9e5uLmC7rTQr7SpNEVV
sauvMNPWNsY1Nm5nyU4YoLICn3ih3Rr4C54dQhdsZErPixxJVUFgqNrO7T6cShMO11Oi4MVuC11L
snoH0FcOhwroaHBK7e3amoHz+vr00EO7f4qSqn/eB6sO9zLwzsWVSygpUVl3u1Bw44HBNe8bTbR/
oAe5HUwpo2rb588PvJubu2AvLG4sXlla/HDjytLCpaXllam+E2ggf9aet+2bGUSgHddZGTo+zIB2
wTg3uER7N5ITGKagxiErua3VUygRyuNBShJVTiM4TBWHr/WwPah9Hwh9VBinAZIFP9Q74vzl2zcW
V6aGg3oaHRxAb0xpr2BqnzgxPF+D40tLl6/eWJoaHTdn19HaYUddeK8x0l7NVFt5b/3sWX3pyu2L
K6tTh8eQpaPejW1F00ixCj1oa86IF4aMxZT4BChBuCJkWBIPNPsjPRhDu4Gm3RmdE8PLBwSgO3yM
uG/EwacXpOmxxnX2R8SP5Qr/gLbCI9xD/AMfZ16yxwRHXHKeZ78DM9f5fWXm8siGErzMv8kzLdSl
YNyJYUZHXuhxyalDcBiFIXcc4sJ8jBnkyOnPtK9+9uc3Xnuw9wDe/K87xwvBmH1jgC8z5yBk3W73
UZzyzVIzlu4lJY/ZMUwosEK5fiyiIAJ8AYNgCuwTccWkz7iL4wnJMKnXa1gsfKwIkaBDPUED2L2w
G8eBCiXGHjsgoS9PfPkukNCju0BCf3Ie3UWN0U4Y4+PwBkICL4i8GPtCciViFjsBF6HvOzzEXiAG
iALxoxsxYUMcT0aU6YJRSJFxkNJmBoOgNbL0jigfgyktMTmPZt3DroQWZ1ADEQkaRpj7wOs+AdxI
z/Gh88ARk8ivd/6iXuvsdeDNBFShV0HViwHNGvIcDmsAEd/iScqjVI3F0dD7kLhRSHweU5dDjagb
uzIisMhwQlUQT+oqk3BtwguIyyOPCO4QFQVBpLCndxkWEBlJ0aA47Cfg32/+623yUFr7v7H29l+3
ni398c29W9aTn3y9snfDejr17fIPVv1o+Qvr87f+/q61f++fyPr9k7esP2z/8HMgmLKd16lEheJp
umuC5XWVV3me9teFthL3DaNoGkfA4zoPhiuLqmVfVHCkV0DNXiVsCMCykUrzbbStgEULOVghQKrD
Dc3xKK8rpLhoo27KK33Qsk8n8ciieXfjCnyTibSWB7upfVqlI0J6lTwiNdg/QSyTI3LDDRhBgFVd
ZMNKTsFiXxV5mqpiGpWq2Dr8D8+o7WnkwOvsB/rWUsH2fH1hEelNAmGnRcwihLK8GuZhNDdnSlh7
YaUYBndMJ5sSe0BXKgwpjSKPUlheQyyo70YwQwPp0OCwk71x5KA55qWtTI+0MhvXysbOi+wwonx8
K9PJSDZrMzCDpMxTgWJh5EexjGIv8FgoAMVUhfSQID776PNrhiA+++j/ThA66lcniGEsWHkBcxhz
ZRDB3k5j6kgWOQrGlQutKSenw6wuEshBBb5gmFAPy5DAA0sofeAZ6cODbXjAEN/88psZYIinC8AQ
X33ydOFVGMLcwF39hAzPGIxjT/qBcoTExJUOU5IqRc0vDk4PsACAbUImk2xuzgWAuP2fa1bNLziz
swBraIiSp++zXoP2utAZAIhCbcGHuk6k/pFlBja1DKZEOTMGfxo9TBOPR+EBKWSqiT0oqUOx0wwC
DzdhOOrnPEa9mP8XOZj4sA==
==== END SVK PATCH BLOCK ====

\start
Date: Thu, 30 Nov 2006 19:01:36 -0500
From: Tim Daly
To: Humberto Zuazaga
Subject: Re: openpty patch again

on my machine:

$ uname -a

Darwin dalys-Computer.local 8.4.0 
Darwin Kernel Version 8.4.0: 
Tue Jan  3 18:22:10 PST 2006; 
root:xnu-792.6.56.obj~1/RELEASE_PPC Power Macintosh powerpc

I get:

$ tar zxf axiom-macos-ppc-20061130.tar.gz
$ export AXIOM=`pwd`/target/powerpc-apple-darwin8.8.0
$ PATH=$AXIOM/bin:$PATH
$ axiom
dyld: Library not loaded: /usr/X11R6/lib/libXpm.4.dylib
  Referenced from: /home/daly/target/powerpc-apple-darwin8.8.0/bin/hypertex
  Reason: image not found
dyld: Library not loaded: /usr/X11R6/lib/libXpm.4.dylib
  Referenced from: /home/daly/target/powerpc-apple-darwin8.8.0/lib/viewman
  Reason: image not found
GCL (GNU Common Lisp)  2.6.8 CLtL1    Nov 29 2006 15:29:11
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
dyld: Library not loaded: /usr/X11R6/lib/libXpm.4.dylib
  Referenced from: /home/daly/target/powerpc-apple-darwin8.8.0/lib/viewman
  Reason: image not found

above message continued infinitely.

\start
Date: Fri, 1 Dec 2006 01:12:56 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: alql and shoe

Gaby, it seems that your change:

2006-11-19  Gabriel Dos Reis  Gabriel Dos Reis

        * Makefile.pamphlet (alql.boot): Translate with bootsys.
        * Makefile.in: Regenerate.

broke examples in Chapter 13 of Axiom book.  The patch below (applied
as version 345 in wh-sandbox) fixed the problem for me.  Some remarks:

1) AFAICS shoe requres package declaration (otherwise we end up in
default lisp package). Unfortunatly, old boot can not handle such
declaration...
2) shoe insist on rewriting 'member' to 'MEMBER'.  One can prevent
rewriting using devious construct like:

  FUNCALL(INTERN '"member",kind,'("o" "k" "c" "d" "p"))

but what I did below is simpler.  OTOH 'member' has many uses in
interpreter, so for quick translation we may need the above.

Index: src/interp/alql.boot.pamphlet
===================================================================
--- src/interp/alql.boot.pamphlet	(wersja 344)
+++ src/interp/alql.boot.pamphlet	(kopia robocza)
@@ -46,10 +46,14 @@
 <<*>>=
 <<license>>
 
+)package "BOOT"
+
 getBrowseDatabase(kind) ==
   $includeUnexposed? : local := true
-  not MEMBER(kind,'("o" "k" "c" "d" "p")) => nil
-  grepConstruct('"*",INTERN kind)
+  k1 := INTERN kind
+  not member(k1,["o", "k", "c", "d", "p"]) => nil
+  grepConstruct('"*", k1)
+
 stringMatches?(pattern,subject) ==
   FIXP basicMatch?(pattern,subject) => true
   false

\start
Date: 01 Dec 2006 01:09:31 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [345] branches/wh-sandbox

Waldek Hebisch writes:

[...]

|  getBrowseDatabase(kind) ==
|    $includeUnexposed? : local := true
| -  not MEMBER(kind,'("o" "k" "c" "d" "p")) => nil
| -  grepConstruct('"*",INTERN kind)
| +  k1 := INTERN kind
| +  not member(k1,["o", "k", "c", "d", "p"]) => nil
| +  grepConstruct('"*", k1)

I don't understand the fine point of this modification:

The original code is tranlated as

   ; getBrowseDatabase(kind) ==
   ;    $includeUnexposed? : local := true
   ;    not MEMBER(kind,'("o" "k" "c" "d" "p")) => nil
   ;    grepConstruct('"*",INTERN kind)

   (DEFUN |getBrowseDatabase| (|kind|)
     (PROG (|$includeUnexposed?|)
       (DECLARE (SPECIAL |$includeUnexposed?|))
       (RETURN
         (PROGN
           (SETQ |$includeUnexposed?| T)
           (COND
             ((NULL (MEMBER |kind| '("o" "k" "c" "d" "p"))) NIL)
             ('T (|grepConstruct| "*" (INTERN |kind|))))))))

using a list literal of strings.

The new code is translated as

   ; getBrowseDatabase(kind) ==
   ;    $includeUnexposed? : local := true
   ;    k1 := INTERN kind
   ;    not member(k1,["o", "k", "c", "d", "p"]) => nil
   ;    grepConstruct('"*", k1)

   (DEFUN |getBrowseDatabase| (|kind|)
     (PROG (|$includeUnexposed?| |k1|)
       (DECLARE (SPECIAL |$includeUnexposed?|))
       (RETURN
         (PROGN
           (SETQ |$includeUnexposed?| T)
           (SETQ |k1| (INTERN |kind|))
           (COND
             ((NULL (MEMBER |k1| (LIST '|o| '|k| '|c| '|d| '|p|))) NIL)
             ('T (|grepConstruct| "*" |k1|)))))))

using more indirections and a list of symbols with different meaning.
Could you expand on what the root problems was? 

\start
Date: Fri, 1 Dec 2006 01:25:29 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [345] branches/wh-sandbox

> Waldek Hebisch writes:
> 
> [...]
> 
> |  getBrowseDatabase(kind) ==
> |    $includeUnexposed? : local := true
> | -  not MEMBER(kind,'("o" "k" "c" "d" "p")) => nil
> | -  grepConstruct('"*",INTERN kind)
> | +  k1 := INTERN kind
> | +  not member(k1,["o", "k", "c", "d", "p"]) => nil
> | +  grepConstruct('"*", k1)
> 
> I don't understand the fine point of this modification:
> 
> using more indirections and a list of symbols with different meaning.
> Could you expand on what the root problems was? 
> 

Boot rewrites 'MEMBER' to 'member'.  Shoe is rewrites 'member' to
'MEMBER'.  I wrote in other message how to call 'member' in shoe, but
that is a devious construct.

'member' user 'EQUAL' on strings.  'MEMBER' uses 'EQ', which does not
give expected effect for strings.

\start
Date: Thu, 30 Nov 2006 20:27:58 -0400
From: Humberto Zuazaga
To: Tim Daly
Subject: Re: openpty patch again

root wrote:
> on my machine:

> I get:

> dyld: Library not loaded: /usr/X11R6/lib/libXpm.4.dylib
>   Referenced from: /home/daly/target/powerpc-apple-darwin8.8.0/bin/hype=
rtex
>   Reason: image not found

Tim, I just posted my build instructions on
http://wiki.axiom-developer.org/BuildAxiom

I don't know enough Mac OS to make an axiom binary that will work on
multiple OS revisions, I'm running:

$ uname -a
Darwin humberto-ortiz-zuazagas-power-mac-g5.local 8.8.0 Darwin Kernel
Version 8.8.0: Fri Sep  8 17:18:57 PDT 2006;
root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc

\start
Date: Fri, 1 Dec 2006 01:27:42 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: openpty patch again

> on my machine:
> 
> $ uname -a
> 
> Darwin dalys-Computer.local 8.4.0 
> Darwin Kernel Version 8.4.0: 
> Tue Jan  3 18:22:10 PST 2006; 
> root:xnu-792.6.56.obj~1/RELEASE_PPC Power Macintosh powerpc
> 
> I get:
> 
> $ tar zxf axiom-macos-ppc-20061130.tar.gz
> $ export AXIOM=`pwd`/target/powerpc-apple-darwin8.8.0
> $ PATH=$AXIOM/bin:$PATH
> $ axiom
> dyld: Library not loaded: /usr/X11R6/lib/libXpm.4.dylib
>   Referenced from: /home/daly/target/powerpc-apple-darwin8.8.0/bin/hypertex
>   Reason: image not found
<snip>
> dyld: Library not loaded: /usr/X11R6/lib/libXpm.4.dylib
>   Referenced from: /home/daly/target/powerpc-apple-darwin8.8.0/lib/viewman
>   Reason: image not found
> 
> above message continued infinitely.
> 

Could you try 'axiom -nogr'.  Normally when viewman dies sman re-spawns
a new copy...

\start
Date: 01 Dec 2006 01:36:15 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: Re: openpty patch again

Humberto Zuazaga writes:

| I'm resubmitting a shorter version of a 300K patch I sent this
| morning.

I did not receive that patch...

| This time I generated the patch without the diffs for configure
| and a couple of Makefile.in files. I guess my version of configure is
| different from Gaby's, it basically changed every line in configure.

I'm using Autoconf 2.59; what is yours?

| I think I got a working build of axiom on Mac OS X 10.4 again.

Yay!

| http://www.hpcf.upr.edu/~humberto/axiom-macos-ppc-20061130.tar.gz
| 
| untar this somewhere, then point AXIOM at the
| target/powerpc-apple-darwin8.8.0 directory:
| 
| $ tar zxf axiom-macos-ppc-20061130.tar.gz
| $ export AXIOM=`pwd`/target/powerpc-apple-darwin8.8.0
| $ PATH=$AXIOM/bin:$PATH
| $ axiom
| 
| Success!
| 
| This was built from the svk mirror:
| 
| $ svk info
| Checkout Path: /Users/humberto/src/axiom/build-improvements
| Depot Path: /mirror/axiom/branches/build-improvements
| Revision: 328
| Last Changed Rev.: 327
| Mirrored From: https://svn.sourceforge.net/svnroot/axiom, Rev. 327
| Copied From: /axiom/trunk/axiom, Rev. 32
| Merged From: /axiom/trunk/axiom, Rev. 32
| 
| that I checked out on Tuesday. That revision builds on Mac OS X, but
| axiom won't work because sman and clef build without working pty support
| (AXIOMsys does work).
| 
| I reworked Waldek's better pty patch to work with the new
| config/axiom-c-macro.h file, and to check for the proper include file
| for openpty, at least on Mac and linux. I don't know if ptys work on MS
| Windows.

I don't think they, but I may be wrong -- I'm not a Windows developer
and I approach this whole stuff with a very engrained unix mind.

In my locat tree, I've divided the C runtime support (libspad.a) into 
five components:

   \begin{itemize}
   \item Core runtime support,
   \item interface with the operating system (filesystem, etc.),
   \item communication through sockets,
   \item user-interface through terminals, and
   \item graphics components.
   \end{itemize}

Core runtime support is hash.c and halloc.
interface with OS is anything havind to do with files, directories and
the like.
sockets is sockio-c.c
terminal-based ui is clef and sman
graphics is hyperdoc and, wel, graphics.

In my local tree it is possible to enable each individual component,
so your patch fits nicely.

| The original openpty patch is:
| 
| http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00236.html
| 
| My version is below.

you would have gotten brownie points if you integrated


| The procedure to build this version of axiom is not too bad. Fink still
| seems to cause problems if the build machinery can see it, so I delete
| it from the path.

we can configure-detect that and set PATH accordingly.

| One caveat is that you need latex, makeindex, and

we can ask configure to return the absolute path so that there would
be no need to symlink from somewhere else.

| maybe tex for the axiom build to succeed, so I install them from fink,
| and link them to /usr/local/bin.
| 
| 
| $ PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin
| $ ./configure
| $ make
| 
| The darn build takes like 6 hours on my dual G5 2.5 GHz Mac.

:-(

| I have some doubts about the patch, since I'm not really sure how to
| build configure, I'm not certain I did it right.

I very much appreciate your effort and patience with this.

| I don't have commit priviledges on the code base, and I don't want them
| until I'm more familiar with svn/svk, so could someone else please check
| in the patch?

Yes, I would like to work a little bit on it with you.

| Finally, this patch is against revision 326, because svk complains my
| axiom tree isn't local when I try to revise the patch against the
| current build-improvements head. I followed the svk instructions at:
| 
| http://wiki.axiom-developer.org/AxiomSilverBranch
| 
| but svk patch complains:
|   
| $ svk patch --view pty-again
| Target not local nor mirrored, unable to view patch.

>From the top my head, I don't see what that means.  I'll have to go back.


[...]

| === configure.ac.pamphlet
| ==================================================================
| --- configure.ac.pamphlet	(revision 326)
| +++ configure.ac.pamphlet	(patch pty-again level 1)
| @@ -676,8 +676,28 @@
|  AC_CHECK_HEADER([regex.h], [], [AC_MSG_ERROR([Axiom needs <regex.h>])])
|  @
|  
| +\subsubsection{openpty}
|  
| +[[clef]] and [[sman]] use ptys to communicate with [[AXIOMsys]]. The
| +existing code in silver doesn't work on MacOS X. We will try to build
| +with the Unix98 standard [[openpty]] function. We need to detect two
| +headers and a library. Linux has openpty defined in [[pty.h]], MacOS X
| +define it in [[util.h]]. FreeBSD is supposed to have a definition in
| +[[libutil.h]].

I like this.

| +<<headers>>=
| +AC_CHECK_HEADERS([pty.h util.h])
| +@
| +
| +On linux the openpty function is in [[libutil]]. We need to add that to
| +the list of libraries, at least for [[sman]] and [[clef]].

It would be good if you could integrate the suggestions here:

  http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00687.html

In particular, we want to distinguish between the symbol openpty
(HAVE_OPENPTY) and its declaration (HAVE_OPENPTY_DECL).

[...]

| === src/lib/openpty.c.pamphlet
| ==================================================================
| --- src/lib/openpty.c.pamphlet	(revision 326)
| +++ src/lib/openpty.c.pamphlet	(patch pty-again level 1)
| @@ -10,17 +10,9 @@
|  \tableofcontents
|  \eject
|  \section{MAC OSX and BSD platform changes}
| -Since we have no other information we are adding the [[MACOSXplatform]] variable
| -to the list everywhere we find [[LINUXplatform]]. This may not be correct but
| -we have no way to know yet. We have also added the [[BSDplatform]] variable.
| -MAC OSX is some variant of BSD. These should probably be merged but we
| -cannot yet prove that.
| -<<mac osx platform change 1>>=
| -#if defined(SUN4OS5platform) ||defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(MACOSXplatform) || defined(BSDplatform)
| -@
| -<<mac osx platform change 2>>=
| -#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(MACOSXplatform) || defined(BSDplatform)
| -@
| +We should really use autotools to check for Unix 98 pty support.
| +Before this is done below we hardcode information about each platform.

Yes.

| +
|  \section{License}
|  <<license>>=
|  /*
| @@ -71,6 +63,11 @@
|  #include <stropts.h>
|  #endif
|  
| +#ifdef HAVE_PTY_H
| +#include <pty.h>
| +#elifdef HAVE_UTIL_H

There is no standard C preprocessor directive #elifdef.  I believe you
wanted to say

    #elif defined(HAVE_UTIL_H)

Again, many thanks for your work and patience with this patch.

\start
Date: Thu, 30 Nov 2006 19:39:31 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: Re: openpty patch again

The first attempt using axiom -nogr failed and hung forever.
I had to kill -9 the process

======================================================================

$ export AXIOM=`pwd`/target/powerpc-apple-darwin8.8.0
$ export PATH=$AXIOM/bin:$PATH
$ axiom -nogr
dyld: Library not loaded: /usr/X11R6/lib/libXpm.4.dylib
  Referenced from: /home/daly/target/powerpc-apple-darwin8.8.0/bin/hypertex
  Reason: image not found
GCL (GNU Common Lisp)  2.6.8 CLtL1    Nov 29 2006 15:29:11
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by SYSTEM:TOP-LEVEL.
Broken at APPLY.  Type :H for Help.
BOOT>>(bye)

Killed


======================================================================

The second attempt also dies but the (bye) exits lisp.

======================================================================



$ which AXIOMsys
/home/daly/target/powerpc-apple-darwin8.8.0/bin/AXIOMsys
$ AXIOMsys
GCL (GNU Common Lisp)  2.6.8 CLtL1    Nov 29 2006 15:29:11
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by SYSTEM:TOP-LEVEL.
Broken at APPLY.  Type :H for Help.
BOOT>>(bye)
dalys-Computer:/home/daly daly$ 

\start
Date: 01 Dec 2006 02:01:22 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: alql and shoe

Waldek Hebisch writes:

| Gaby, it seems that your change:
| 
| 2006-11-19  Gabriel Dos Reis  Gabriel Dos Reis
| 
|         * Makefile.pamphlet (alql.boot): Translate with bootsys.
|         * Makefile.in: Regenerate.
| 
| broke examples in Chapter 13 of Axiom book.  The patch below (applied
| as version 345 in wh-sandbox) fixed the problem for me.  Some remarks:
| 
| 1) AFAICS shoe requres package declaration (otherwise we end up in
| default lisp package). 

Yes.

| Unfortunatly, old boot can not handle such  declaration...

ah, yes.

| 2) shoe insist on rewriting 'member' to 'MEMBER'.

Yes, member is a kind of library function in new Boot. Every symbol
goes through bfReName (boot/tytree1.boot).  However, you can pretend
that you have a function member that is not a library function if you
write its name as a string literal

  "member"(kind, '("o" "k" "c" "d" "p"))

which translates to

        ('|member| |kind| '("o" "k" "c" "d" "p"))

as opposed to

  "member"(kind, '("o" "k" "c" "d" "p"))

which translates to

        (MEMBER |kind| '("o" "k" "c" "d" "p")) 

\start
Date: Fri, 1 Dec 2006 02:07:08 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [345] branches/wh-sandbox

Gabriel Dos Reis wrote:

> OK, I have not gotten that message yet.  But, the parts
> 
>              ((NULL (MEMBER |kind| '("o" "k" "c" "d" "p"))) NIL)
> 
> versus
> 
>              ((NULL (MEMBER |k1| (LIST '|o| '|k| '|c| '|d| '|p|))) NIL)
> 
> are still not explained to me.
> 
> | 'member' user 'EQUAL' on strings.  'MEMBER' uses 'EQ', which does not
> | give expected effect for strings.
> 

Boot translation is:

             ((NULL (|member| |kind| '("o" "k" "c" "d" "p"))) NIL)

My change essentially replaces '(EQUAL str1 str2)' by 
'(EQ (INTERN str1) (INTERN str2))', the second form is (probably) less
efficient but for our purpose equivalent.  In more detail: |member| uses
'EQUAL', to get equivalent effect using 'MEMBER' we replace strings
by symbols.  We need explicitly intern 'kind', but for the literal
list it is enough to change notation.

\start
Date: Fri, 1 Dec 2006 02:17:36 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: alql and shoe

> Waldek Hebisch writes:
> 
> | Gaby, it seems that your change:
> | 
> | 2006-11-19  Gabriel Dos Reis  Gabriel Dos Reis
> | 
> |         * Makefile.pamphlet (alql.boot): Translate with bootsys.
> |         * Makefile.in: Regenerate.
> | 
> | broke examples in Chapter 13 of Axiom book.  The patch below (applied
> | as version 345 in wh-sandbox) fixed the problem for me.  Some remarks:
> | 
> | 1) AFAICS shoe requres package declaration (otherwise we end up in
> | default lisp package). 
> 
> Yes.
> 
> | Unfortunatly, old boot can not handle such  declaration...
> 
> ah, yes.
> 
> | 2) shoe insist on rewriting 'member' to 'MEMBER'.
> 
> Yes, member is a kind of library function in new Boot. Every symbol
> goes through bfReName (boot/tytree1.boot).  However, you can pretend
> that you have a function member that is not a library function if you
> write its name as a string literal
> 
>   "member"(kind, '("o" "k" "c" "d" "p"))
> 
> which translates to
> 
>         ('|member| |kind| '("o" "k" "c" "d" "p"))
> 

Indeed.  I have tried some other variation and did not work. So the
following should be enough:

--- wh-sandbox.bb/src/interp/alql.boot.pamphlet	2006-11-30 01:00:42.000000000 +0100
+++ wh-sandbox/src/interp/alql.boot.pamphlet	2006-12-01 02:14:24.000000000 +0100
@@ -46,10 +46,13 @@
 <<*>>=
 <<license>>
 
+)package "BOOT"
+
 getBrowseDatabase(kind) ==
   $includeUnexposed? : local := true
-  not MEMBER(kind,'("o" "k" "c" "d" "p")) => nil
+  not "member"(kind,'("o" "k" "c" "d" "p")) => nil
   grepConstruct('"*",INTERN kind)
+
 stringMatches?(pattern,subject) ==
   FIXP basicMatch?(pattern,subject) => true
   false

\start
Date: 01 Dec 2006 02:19:43 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [345] branches/wh-sandbox

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| 
| > OK, I have not gotten that message yet.  But, the parts
| > 
| >              ((NULL (MEMBER |kind| '("o" "k" "c" "d" "p"))) NIL)
| > 
| > versus
| > 
| >              ((NULL (MEMBER |k1| (LIST '|o| '|k| '|c| '|d| '|p|))) NIL)
| > 
| > are still not explained to me.
| > 
| > | 'member' user 'EQUAL' on strings.  'MEMBER' uses 'EQ', which does not
| > | give expected effect for strings.
| > 
| 
| Boot translation is:
| 
|              ((NULL (|member| |kind| '("o" "k" "c" "d" "p"))) NIL)

OK, thanks.  I would prefer we bring |member| back using the
"quotation" notation -- yes, I really need to write that primer to new
Boot -- and retain the list literal.

\start
Date: 01 Dec 2006 02:22:52 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: alql and shoe

Waldek Hebisch writes:

[...]

| Indeed.  I have tried some other variation and did not work. So the
| following should be enough:

Yes, please check it on build-improvements too.  Many thanks!

I have so many things to do on Axiom, but I'll try to write a primer
to new Boot.

\start
Date: 01 Dec 2006 01:46:42 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [345] branches/wh-sandbox

Waldek Hebisch writes:

| > Waldek Hebisch writes:
| > 
| > [...]
| > 
| > |  getBrowseDatabase(kind) ==
| > |    $includeUnexposed? : local := true
| > | -  not MEMBER(kind,'("o" "k" "c" "d" "p")) => nil
| > | -  grepConstruct('"*",INTERN kind)
| > | +  k1 := INTERN kind
| > | +  not member(k1,["o", "k", "c", "d", "p"]) => nil
| > | +  grepConstruct('"*", k1)
| > 
| > I don't understand the fine point of this modification:
| > 
| > using more indirections and a list of symbols with different meaning.
| > Could you expand on what the root problems was? 
| > 
| 
| Boot rewrites 'MEMBER' to 'member'.  Shoe is rewrites 'member' to
| 'MEMBER'.  I wrote in other message how to call 'member' in shoe, but
| that is a devious construct.

OK, I have not gotten that message yet.  But, the parts

             ((NULL (MEMBER |kind| '("o" "k" "c" "d" "p"))) NIL)

versus

             ((NULL (MEMBER |k1| (LIST '|o| '|k| '|c| '|d| '|p|))) NIL)

are still not explained to me.

| 'member' user 'EQUAL' on strings.  'MEMBER' uses 'EQ', which does not
| give expected effect for strings.

Indeed.

\start
Date: Thu, 30 Nov 2006 22:05:24 -0400
From: Humberto Zuazaga
To: Gabriel Dos Reis
Subject: Re: openpty patch again

Gabriel Dos Reis wrote:

> | The procedure to build this version of axiom is not too bad. Fink sti=
ll
> | seems to cause problems if the build machinery can see it, so I delet=
e
> | it from the path.
>
> we can configure-detect that and set PATH accordingly.
>
> | One caveat is that you need latex, makeindex, and
>
> we can ask configure to return the absolute path so that there would
> be no need to symlink from somewhere else.

Can you reccomend a reference on configure tricks like that? I've looked
at the info pages, but can't figure out how to do that.

> | but svk patch complains:
> |  
> | $ svk patch --view pty-again
> | Target not local nor mirrored, unable to view patch.
>
> From the top my head, I don't see what that means.  I'll have to go bac=
k.

The help for svk patch says:

    Suppose you mirror project foo to //mirror/foo, create a local copy o=
n
    //local/foo, and check out to ~/dev/foo. After you've done some work,=

    you type:

        svk commit -m "Add my new feature"

    to commit changes from ~/dev/foo to //local/foo. If you have commit
    access to the upstream repository, you can submit your changes direct=
ly
    like this:

        svk push //local/foo

    Sometimes, it's useful to send a patch, rather than submit changes
    directly, either because you don't have permission to commit to the
    upstream repository or because you don't think your changes are ready=

    to be committed.

    To create a patch containing the differences between //local/foo and
    //mirror/foo, use this command:

        svk push -P Foo //local/foo

But I don't have and don't know how to make the "local copy //local/foo"
corresponding to my upstream repository stored in //mirror/axiom

> It would be good if you could integrate the suggestions here:
>
>   http://lists.nongnu.org/archive/html/axiom-developer/2006-11/msg00687=
=2Ehtml
>
> In particular, we want to distinguish between the symbol openpty
> (HAVE_OPENPTY) and its declaration (HAVE_OPENPTY_DECL).

I forgot about that email. I'll try to incorporate your suggestions.

> There is no standard C preprocessor directive #elifdef.  I believe you
> wanted to say
>
>     #elif defined(HAVE_UTIL_H)

I stole the snippet from a python mailing list, I guess they use gcc too
:-).

\start
Date: Thu, 30 Nov 2006 22:35:04 -0400
From: Humberto Zuazaga
To: list
Subject: Re: patch and autoconf (was openpty patch again)

Gabriel Dos Reis wrote:
> Humberto Zuazaga writes:
>
> | I'm resubmitting a shorter version of a 300K patch I sent this
> | morning.
>
> I did not receive that patch...

It's probably stuck in the mailman admindb queue. At 300K it's better to
delete it than let it through. I didn't realize how big it was.

>
> | This time I generated the patch without the diffs for configure
> | and a couple of Makefile.in files. I guess my version of configure is=

> | different from Gaby's, it basically changed every line in configure.
>
> I'm using Autoconf 2.59; what is yours?

$ autoconf --version
autoconf (GNU Autoconf) 2.60


\start
Date: 01 Dec 2006 03:42:17 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: Re: openpty patch again

Humberto Zuazaga writes:

| Gabriel Dos Reis wrote:
| 
| > | The procedure to build this version of axiom is not too bad. Fink still
| > | seems to cause problems if the build machinery can see it, so I delete
| > | it from the path.
| > 
| > we can configure-detect that and set PATH accordingly.
| > 
| > | One caveat is that you need latex, makeindex, and
| > 
| > we can ask configure to return the absolute path so that there would
| > be no need to symlink from somewhere else.
| 
| Can you reccomend a reference on configure tricks like that? I've looked
| at the info pages, but can't figure out how to do that.

I was thinking of AC_PATH_PROG (which we use for notangle and noweave
for example).

The online reference I liked (a long time ago) was the Autotools book,

        http://sources.redhat.com/autobook/

but it is quite out of date now.  But I seem to remember that one of
the co-authors (Ian, now at Google) said recently that he no longer
quite recommend it.  It is still useful though.
Otherwise I find the info pages quite well written.

| > | but svk patch complains:
| > |   
| > | $ svk patch --view pty-again
| > | Target not local nor mirrored, unable to view patch.
| > 
| > From the top my head, I don't see what that means.  I'll have to go back.
| 
| The help for svk patch says:
| 
|     Suppose you mirror project foo to //mirror/foo, create a local copy on
|     //local/foo, and check out to ~/dev/foo. After you've done some work,
|     you type:
| 
|         svk commit -m "Add my new feature"
| 
|     to commit changes from ~/dev/foo to //local/foo. If you have commit
|     access to the upstream repository, you can submit your changes directly
|     like this:
| 
|         svk push //local/foo
| 
|     Sometimes, it's useful to send a patch, rather than submit changes
|     directly, either because you don't have permission to commit to the
|     upstream repository or because you don't think your changes are ready
|     to be committed.
| 
|     To create a patch containing the differences between //local/foo and
|     //mirror/foo, use this command:
| 
|         svk push -P Foo //local/foo
| 
| But I don't have and don't know how to make the "local copy //local/foo"
| corresponding to my upstream repository stored in //mirror/axiom

OK, now I get it.  Thanks.  

You need to create a depotmap; call it whatever you want.  
Personally, I have several depots, one of them is /mirror
for mirroring several repos of projects I work on (GCC has a distinct
dedicated depot). Chose a directory where you want your depot to
reside.  It could be ~/.svk

   svk depotmap /mirror ~/.svk

(enter the editor, make whatever change you think is appropriate;
save; exit)

Next, you need to mirror axiom repo

   svk mirror https://svn.sourceforge.net/svnroot/axiom /mirror/axiom

Then, you need to synchronize that mirror

   svk sync /mirror/axiom

(that can take a while -- it mirrors the repo on your local disk.
Therefore, it is like if you were doing a checkout and SF/SVN would
give you headach; your would need to be patient).

/mirror/axiom is now your local repo.  You can check out as

  svk co /mirror/axiom/branches/build-improvements axiom.bi
  
and once you're in the working directory (axiom.bi), you can update at
any time

   svk update -s

\start
Date: 01 Dec 2006 03:44:30 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: Re: patch and autoconf (was openpty patch again)

Humberto Zuazaga writes:

[...]

| > | This time I generated the patch without the diffs for configure
| > | and a couple of Makefile.in files. I guess my version of configure is
| > | different from Gaby's, it basically changed every line in configure.
| > 
| > I'm using Autoconf 2.59; what is yours?
| 
| $ autoconf --version
| autoconf (GNU Autoconf) 2.60

Ah OK; there are lot of changed in Autoconf 2.60.   I did not upgrade,
partly because of GCC which is still stuck with Autoconf < 2.60.

Autoconf 2.60 is supposed to be fancier.

\start
Date: 01 Dec 2006 03:45:39 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: CLgetpid

Tim Daly writes:

| >   CLgetpid() is defined in src/lib/cfuns-c.c but it does not appear
| > to be used anywhere.  I would like to remove it, but I would like to
| > know its history if you happen to remember.
| 
| It does seem to be unused.
| Be sure to also remove the prototype from src/include/cfuns-c.H1

Thanks.

(sorry for having mistyped the list name).

\start
Date: Thu, 30 Nov 2006 23:24:58 -0400
From: Humberto Zuazaga
To: Gabriel Dos Reis
Subject: Re: openpty patch again

Gabriel Dos Reis wrote:

> You need to create a depotmap; call it whatever you want. 
> Personally, I have several depots, one of them is /mirror
> for mirroring several repos of projects I work on (GCC has a distinct
> dedicated depot). Chose a directory where you want your depot to
> reside.  It could be ~/.svk
>
>    svk depotmap /mirror ~/.svk
>
> (enter the editor, make whatever change you think is appropriate;
> save; exit)
>
> Next, you need to mirror axiom repo
>
>    svk mirror https://svn.sourceforge.net/svnroot/axiom /mirror/axiom
>
> Then, you need to synchronize that mirror
>
>    svk sync /mirror/axiom
>
> (that can take a while -- it mirrors the repo on your local disk.
> Therefore, it is like if you were doing a checkout and SF/SVN would
> give you headach; your would need to be patient).
>
> /mirror/axiom is now your local repo.  You can check out as
>
>   svk co /mirror/axiom/branches/build-improvements axiom.bi

No, that won't work, or rather it works to check out the source, but I
can't svk patch that working directory. Those are the instructions I had
followed from the AxiomSilverBranch page on MathAction.

The svk help intro page suggests a procedure like:

    svk mirror

      First, you'll need to mirror a remote repository. This sets up a
      local copy of that repository for you to branch from, merge to and
      otherwise poke at. The local path is sometimes called a "depot path=
=2E"

          # This command sets up the mirror directory for your local
          # mirrors of remote repositories
          svk mkdir //mirror

          svk mirror svn://svn.example.com/project_x //mirror/project_x

    svk sync

      When you've set up a new mirror or want to get some work done witho=
ut
      a network connection, sync your local repository with upstream
      repositories.

          svk sync //mirror/project_x

    svk copy

      After that, it's easy to copy remote branches to create local
      branches. (svk branches are simply directories, just like Subversio=
n
      branches.)

          # This command sets up a directory for your local branches.
          # Local branches can't live inside mirrored paths
          svk mkdir //local

          svk copy //mirror/project_x //local/project_x

    svk checkout

      When you want to get some work done, you can checkout a working cop=
y
      to make local changes.

          cd ~/svk-checkouts
          svk co //local/project_x

Thus, I'd end up with //mirror/axiom and //local/axiom. Presumably then
svk will allow me to patch.

What I'm trying now is to make a svk copy of
/mirror/axiom/branches/build-improvements to /mirror/local to see if the
patch commands work. Stay tuned.

\start
Date: 01 Dec 2006 04:21:51 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: openpty patch again

Waldek Hebisch writes:

| Normally when viewman dies sman re-spawns  a new copy...

This is a design flaw in sman and friends -- I came across it yesterday
and thought "wait, this is an unbounded replication; nobody wants
that!".  

\start
Date: 01 Dec 2006 05:24:50 +0100
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: Re: openpty patch again

Humberto Zuazaga writes:

| Gabriel Dos Reis wrote:
| 
| > You need to create a depotmap; call it whatever you want.  
| > Personally, I have several depots, one of them is /mirror
| > for mirroring several repos of projects I work on (GCC has a distinct
| > dedicated depot). Chose a directory where you want your depot to
| > reside.  It could be ~/.svk
| > 
| >    svk depotmap /mirror ~/.svk
| > 
| > (enter the editor, make whatever change you think is appropriate;
| > save; exit)
| > 
| > Next, you need to mirror axiom repo
| > 
| >    svk mirror https://svn.sourceforge.net/svnroot/axiom /mirror/axiom
| > 
| > Then, you need to synchronize that mirror
| > 
| >    svk sync /mirror/axiom
| > 
| > (that can take a while -- it mirrors the repo on your local disk.
| > Therefore, it is like if you were doing a checkout and SF/SVN would
| > give you headach; your would need to be patient).
| > 
| > /mirror/axiom is now your local repo.  You can check out as
| > 
| >   svk co /mirror/axiom/branches/build-improvements axiom.bi
| 
| No, that won't work, or rather it works to check out the source, but I
| can't svk patch that working directory.

?

The above is what *I* _use_ to set up a repo directly "connected" to 
the master repo, in particular one for Axiom.

| Those are the instructions I had
| followed from the AxiomSilverBranch page on MathAction.
| 
| The svk help intro page suggests a procedure like:
| 
|     svk mirror
| 
|       First, you'll need to mirror a remote repository. This sets up a
|       local copy of that repository for you to branch from, merge to and
|       otherwise poke at. The local path is sometimes called a "depot path."
| 
|           # This command sets up the mirror directory for your local
|           # mirrors of remote repositories
|           svk mkdir //mirror

This creates a local branch in your default depot, so it effectively
is "deconnected" from the Axiom repo.  Is that what you want?

\start
Date: 01 Dec 2006 05:31:22 +0100
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: alql and shoe

Waldek Hebisch writes:

[...]

| > which translates to
| > 
| >         ('|member| |kind| '("o" "k" "c" "d" "p"))
| > 
| 
| Indeed.  I have tried some other variation and did not work. So the
| following should be enough:

Did you test it?

My build says fails with:

   Compiling alql.clisp.
   ; (DEFUN |getBrowseDatabase| ...) is being compiled.
   ;;; The function '|member| is illegal.
   No FASL generated.
   NIL

I'll look into this later.

\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
