\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: Tue, 1 May 2007 22:32:45 -0500
From: Tim Daly
To: Cliff Yapp
Subject: gclweb.lisp

Cliff,

I started simulating the ANSI machinery in order to get a 
working version of your code (e.g. coding read-sequence) in
GCL. Eventually I gave up and created a simple version to 
substitute until we have an Axiom under ANSI lisp. I also
wanted to experiment with latex chunk syntax. We can work
that into your code eventually.

Attached is a block of code to implement the tangle function in GCL.
It can be adjusted to either accept latex or noweb syntax by 
changing one function name (ischunk-latex to ischunk-noweb).

I'm looking into the use of pure latex pamphlet files and the use of

\begin{chunk}{chunkname}
...
\end{chunk}

and

\chunk{chunkname}

in place of the noweb syntax. The chunk environment latex macro is
being worked on now. That will allow us to completely skip the noweave
function and just use straight latex. I'll send them to you once they
are working.

In a short while, due to the work by you, Waldek, and Kai we
can make Axiom understand literate files everywhere and remove
the need for noweb completely.

t

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; gclweb.lisp
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


;;; This program will extract the source code from a literate file

;;; The *chunkhash* variable will hold the hash table of chunks.

(defvar *chunkhash* nil)

;  (tangle "clweb.pamphlet" "<<*>>")  <== noweb syntax
;  (tangle "clweb.pamphlet "*")       <== latex syntax (default)

;;; tangle takes the name of a file and the chunk to expand
;;; 
(defun tangle (filename topchunk)
  (setq *chunkhash* (make-hash-table :test #'equal))
  (hashchunks (gcl-read-file filename))
  (expand topchunk))

;;; gcl-read-file
;;;
;;; This would be read-sequence in ansi common lisp. Here we read
;;; a line, push it onto a stack and then reverse the stack. The
;;; net effect is a list of strings, one per line of the file.

(defun gcl-read-file (streamname)
 (let (result)
  (with-open-file (stream (open streamname))
   (do (line eof)
      ((eq line 'done) (nreverse result))
    (multiple-value-setq (line eof) (read-line stream nil 'done)) 
    (unless (eq line 'done) (push line result))))))

;;; hashchunks gathers the chunks and puts them in the hash table
;;;
;;; if we find the chunk syntax and it is a
;;;   define ==> parse the chunkname and start gathering lines onto a stack
;;;   end    ==> push the completed list of lines into a stack of chunks
;;;              already in the hash table
;;;   otherwise ==> if we are gathering, push the line onto the stack

;;; a hash table entry is a list of lists such as
;;; (("6" "5") ("4" "3") ("2" "1"))
;;; each of the sublists is a set of lines in reverse (stack) order
;;; each sublist is a single chunk of lines. 
;;; there is a new sublist for each reuse of the same chunkname

(defun hashchunks (lines)
 (let (type name chunkname oldchunks chunk gather)
  (dolist (line lines)
   (multiple-value-setq (type name) (ischunk-latex line))
   (cond
    ((eq type 'define)
      (setq chunkname name)
      (setq gather t))
    ((eq type 'end)
      ;(format t "name= ~a chunk=~s~%" chunkname chunk)
      (setq oldchunks (gethash chunkname *chunkhash*))
      (setf (gethash chunkname *chunkhash*) (push chunk oldchunks))
      (setq gather nil)
      (setq chunk nil))
     (gather 
      (push line chunk))))))

;;; expand will recursively expand chunks in the hash table
;;; 
;;; latex chunk names are just the chunkname itself e.g. chunkname
;;; noweb chunk names include the delimiters, e.g: <<chunkname>>

;;; a hash table entry is a list of lists such as
;;; (("6" "5") ("4" "3") ("2" "1"))
;;; so to process the chunk we reverse the main list and
;;; for each sublist we reverse the sublist and process the lines

;;; if a chunk name reference is encountered in a line we call expand
;;; recursively to expand the inner chunkname

(defun expand (chunk)
 (let ((chunklist (gethash chunk *chunkhash*)) type name)
  (dolist (chunk (reverse chunklist))
   (dolist (line (reverse chunk))
    (multiple-value-setq (type name) (ischunk-latex line))
    (if (eq type 'refer) 
      (expand name)
      (format t "~a~%" line))))))

;;; There is a built-in assumption (in the ischunk-* functions)
;;; that the chunks occur on separate lines and that the indentation
;;; of the chunk reference has no meaning.
;;;
;;; ischunk-latex  recognizes chunk names in latex convention
;;;
;;; There are 3 cases to recognize:
;;;  \begin{chunk}{thechunkname}  ==> 'define thechunkname
;;;  \end{chunk}                  ==> 'end nil
;;;  \chunk{thechunkname}         ==> 'refer thechunkname

(defun ischunk-latex (line)
 (let ((len (length line)) 
       (mark (search "chunk" line))
       (point 0)
       name preline postline)
  (when mark
   (cond
    ((setq mark (search "\\begin{chunk}{" line)) ; recognize define
      (setq point (position #\} line :start (+ mark 14)))
      (cond
       ((null point) (values nil nil))
       ((= point 0)  (values nil nil))
       (t
         (setq name (subseq line (+ mark 14) point)) 
         ;(print (list 'define name))
         (values 'define name))))
    ((setq mark (search "\end{chunk}" line))     ; recognize end
       ;(print (list 'end nil))
       (values 'end nil))
    ((setq mark (search "\chunk{" line))         ; recognize reference
      (setq point (position #\} line :start (+ mark 6)))
      (cond
       ((null point) (values nil nil))
       ((= point 0)  (values nil nil))
       (t
         (setq name (subseq line (+ mark 6) point)) 
         ;(print (list 'refer name))
         (values 'refer name))))
    (t (values nil nil))))))
  
;;; ischunk-noweb recognizes chunk names using the noweb convention
;;;
;;; There are 3 cases to recognize:
;;;  <<thechunkname>>=  ==> 'define thechunkname
;;;  @                  ==> 'end nil
;;;  <<thechunkname>>   ==> 'refer thechunkname

(defun ischunk-noweb (line)
 (let ((len (length line)) (mark (position #\> line)) (point 0))
  (cond
   ((and mark                    ; recognize define
         (> len (+ mark 2))
         (char= #\< (schar line 0))
         (char= #\< (schar line 1))
         (char= #\> (schar line (+ mark 1)))
         (char= #\= (schar line (+ mark 2))))
     ;(print (list 'define (subseq line 0 (+ mark 2))))
     (values 'define (subseq line 0 (+ mark 2))))
   ((and mark                    ; recognize reference
         (> len (+ mark 1))
         (char= #\> (schar line (+ mark 1))))
     (setq point (position #\< line))
     (if
      (and point
           (< point (- mark 2))
           (char= #\< (schar line (+ point 1))))
        (values 'refer (subseq line point (+ mark 2)))
        (values 'noise nil)))
    ((and (> len 0)                ; end chunk
          (char= #\@ (schar line 0)))
      (values 'end nil))
    (t (values nil nil)))))

\start
Date: Tue, 1 May 2007 21:00:43 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: gclweb.lisp

--- Tim Daly wrote:

> Cliff,
> 
> I started simulating the ANSI machinery in order to get a 
> working version of your code (e.g. coding read-sequence) in
> GCL. Eventually I gave up and created a simple version to 
> substitute until we have an Axiom under ANSI lisp.

OK.  Any chance Camm could support on this by implementing
read-sequence  in GCL?  Perhaps it isn't so critical if we're close to
running on SBCL in any case.

> I also
> wanted to experiment with latex chunk syntax. We can work
> that into your code eventually.

If everything works as it should, changing cl-web to LaTeX chunk style
should be as simple as changing this:

<<tangle-delimiter-variables>>=
(eval-when (:compile-toplevel :load-toplevel :execute)
  (progn
    (defvar chunk-start-delimiter "<<")
    (defvar chunk-name-end-delimiter ">>=")
    (defvar chunk-ref-start-delimiter "<<")
    (defvar chunk-ref-end-delimiter ">>")
    (defvar chunk-end-delimiter "@")))

@

to this:

<<tangle-delimiter-variables>>=
(eval-when (:compile-toplevel :load-toplevel :execute)
  (progn
    (defvar chunk-start-delimiter "\begin{chunk}{")
    (defvar chunk-name-end-delimiter "}")
    (defvar chunk-ref-start-delimiter "\chunk{")
    (defvar chunk-ref-end-delimiter "}")
    (defvar chunk-end-delimiter "\end{chunk}")))

@

and recompiling the cl-web file.

> Attached is a block of code to implement the tangle function in GCL.
> It can be adjusted to either accept latex or noweb syntax by 
> changing one function name (ischunk-latex to ischunk-noweb).

Did you want to incorporate that into the cl-web file?  How serious is
the breakage?  If we can shoe-horn together some kind of read function
that outputs what cl-web needs (even if it's slower) would the rest of
it work?

> I'm looking into the use of pure latex pamphlet files [snip] in
> place of the noweb syntax. The chunk environment latex macro is
> being worked on now.

Nice!

> That will allow us to completely skip the noweave
> function and just use straight latex. I'll send them to you once they
> are working.

That would be great.  In that case, should we bother with implementing
the conversion to LaTeX or just wait for the new style to roll out?

> In a short while, due to the work by you, Waldek, and Kai we
> can make Axiom understand literate files everywhere and remove
> the need for noweb completely.

I'm interested in some of the possibilities having a (fast) tangle in
lisp opens up on the editor side, perhaps using Climacs or Able.  Emacs
seems to be showing its age when it comes to this type of editing, so
perhaps the better direction would be to focus on creating the exact
tool we need.  For the future, but interesting.

Cheers,
CY

P.S.  I sent cl-web-v0.5 to the list, but it hit the filesize limit -
anybody know who the list admin is?

\start
Date: 02 May 2007 08:21:18 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: differences wh-sandbox andbuild-improvements

Bill Page writes:

[...]

| 2) Different version of make?

Make was definitely corrupted.  
In the end I erase all install of msys/mingw, and reinstalled
everything, NOT downloading from www.mingw.org, but from
the SF download site.

Reading

  http://sbcl-internals.cliki.net/Build%20on%20Windows

was definitely useful to get back on track.  I was able to install
Autoconf-2.60 in /usr/local/

I can now build Axiom on windows, again.

\start
Date: Wed, 02 May 2007 16:32:50 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: gclweb.lisp
Cc: Eitan Gurari

I know that you want to do everything in LISP, but there are LaTeX-only 
solutions already around.

http://www.cse.ohio-state.edu/~gurari/tpf/html/LitProg.html

I haven't evaluated how good that is and whether is as powerful as 
noweb. I also don't like the syntax and output, but it would be a way to 
avoid LISP. ;-) Note that TeX is a programming language and can write 
files. (I have no idea how fast that would be, though.)
LaTeX is a prerequisite anyway. (Or are there ideas to remove dependency 
on LaTeX?)

The part that I don't like with the

\begin{chunk}{chunkname}
...
\end{chunk}

syntax is that there would then be no support for highlighting the code 
part (emacs font-lock) according to the type of code that is inside the 
chunk. mmm-mode does that already and it works fine for me. If then some 
of the LISP programmers on this list convince mmm-mode to treat

\begin{chunk}{chunkname} ... \end{chunk}

like

<<chunkname>>= ... @

then I would have nothing against such a LaTeX-like syntax (except that 
using \chunk{chunkname} seems a bit longish to me and one should allow a 
(configurable) shortcut (see section 2.1 of
http://citeseer.ist.psu.edu/rd/77532545%2C192192%2C1%2C0.25%2CDownload/http://citeseer.ist.psu.edu/cache/papers/cs/1105/ftp:zSzzSzftp.cs.yale.eduzSzWWWzSzHTMLzSzYALEzSzCSzSzHyPlanszSzcsuros-mikloszSzsourcezSzdoc.pdf/mittelbach97doc.pdf 
).

And another "except" would be that a non-noweb solution should be as 
powerful as noweb. In particular, your solution should allow that 
identifiers inside code chunks are automatically tagged with hyperlinks. 
  Anyway extensive use of hyperlinks is a *must*. Nobody is going to 
print a 1000+ pages document. One finds information quicker if the 
document is online and properly hyperlinked.

Look for example at ALLPROSE generated output (ALLPROSE builds on noweb 
features):

http://www.risc.uni-linz.ac.at/people/hemmecke/AldorCombinat/combinatsu29.html#noweb.NW4LNGwX-49LjXS-1

Ralf


On 05/02/2007 05:32 AM, Tim Daly wrote:
> Cliff,
> 
> I started simulating the ANSI machinery in order to get a 
> working version of your code (e.g. coding read-sequence) in
> GCL. Eventually I gave up and created a simple version to 
> substitute until we have an Axiom under ANSI lisp. I also
> wanted to experiment with latex chunk syntax. We can work
> that into your code eventually.
> 
> Attached is a block of code to implement the tangle function in GCL.
> It can be adjusted to either accept latex or noweb syntax by 
> changing one function name (ischunk-latex to ischunk-noweb).
> 
> I'm looking into the use of pure latex pamphlet files and the use of
> 
> \begin{chunk}{chunkname}
> ...
> \end{chunk}
> 
> and
> 
> \chunk{chunkname}
> 
> in place of the noweb syntax. The chunk environment latex macro is
> being worked on now. That will allow us to completely skip the noweave
> function and just use straight latex. I'll send them to you once they
> are working.
> 
> In a short while, due to the work by you, Waldek, and Kai we
> can make Axiom understand literate files everywhere and remove
> the need for noweb completely.
> 
> t
> 
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;; gclweb.lisp
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> 
> 
> ;;; This program will extract the source code from a literate file
> 
> ;;; The *chunkhash* variable will hold the hash table of chunks.
> 
> (defvar *chunkhash* nil)
> 
> ;  (tangle "clweb.pamphlet" "<<*>>")  <== noweb syntax
> ;  (tangle "clweb.pamphlet "*")       <== latex syntax (default)
> 
> ;;; tangle takes the name of a file and the chunk to expand
> ;;; 
> (defun tangle (filename topchunk)
>   (setq *chunkhash* (make-hash-table :test #'equal))
>   (hashchunks (gcl-read-file filename))
>   (expand topchunk))
> 
> ;;; gcl-read-file
> ;;;
> ;;; This would be read-sequence in ansi common lisp. Here we read
> ;;; a line, push it onto a stack and then reverse the stack. The
> ;;; net effect is a list of strings, one per line of the file.
> 
> (defun gcl-read-file (streamname)
>  (let (result)
>   (with-open-file (stream (open streamname))
>    (do (line eof)
>       ((eq line 'done) (nreverse result))
>     (multiple-value-setq (line eof) (read-line stream nil 'done)) 
>     (unless (eq line 'done) (push line result))))))
> 
> ;;; hashchunks gathers the chunks and puts them in the hash table
> ;;;
> ;;; if we find the chunk syntax and it is a
> ;;;   define ==> parse the chunkname and start gathering lines onto a stack
> ;;;   end    ==> push the completed list of lines into a stack of chunks
> ;;;              already in the hash table
> ;;;   otherwise ==> if we are gathering, push the line onto the stack
> 
> ;;; a hash table entry is a list of lists such as
> ;;; (("6" "5") ("4" "3") ("2" "1"))
> ;;; each of the sublists is a set of lines in reverse (stack) order
> ;;; each sublist is a single chunk of lines. 
> ;;; there is a new sublist for each reuse of the same chunkname
> 
> (defun hashchunks (lines)
>  (let (type name chunkname oldchunks chunk gather)
>   (dolist (line lines)
>    (multiple-value-setq (type name) (ischunk-latex line))
>    (cond
>     ((eq type 'define)
>       (setq chunkname name)
>       (setq gather t))
>     ((eq type 'end)
>       ;(format t "name= ~a chunk=~s~%" chunkname chunk)
>       (setq oldchunks (gethash chunkname *chunkhash*))
>       (setf (gethash chunkname *chunkhash*) (push chunk oldchunks))
>       (setq gather nil)
>       (setq chunk nil))
>      (gather 
>       (push line chunk))))))
> 
> ;;; expand will recursively expand chunks in the hash table
> ;;; 
> ;;; latex chunk names are just the chunkname itself e.g. chunkname
> ;;; noweb chunk names include the delimiters, e.g: <<chunkname>>
> 
> ;;; a hash table entry is a list of lists such as
> ;;; (("6" "5") ("4" "3") ("2" "1"))
> ;;; so to process the chunk we reverse the main list and
> ;;; for each sublist we reverse the sublist and process the lines
> 
> ;;; if a chunk name reference is encountered in a line we call expand
> ;;; recursively to expand the inner chunkname
> 
> (defun expand (chunk)
>  (let ((chunklist (gethash chunk *chunkhash*)) type name)
>   (dolist (chunk (reverse chunklist))
>    (dolist (line (reverse chunk))
>     (multiple-value-setq (type name) (ischunk-latex line))
>     (if (eq type 'refer) 
>       (expand name)
>       (format t "~a~%" line))))))
> 
> ;;; There is a built-in assumption (in the ischunk-* functions)
> ;;; that the chunks occur on separate lines and that the indentation
> ;;; of the chunk reference has no meaning.
> ;;;
> ;;; ischunk-latex  recognizes chunk names in latex convention
> ;;;
> ;;; There are 3 cases to recognize:
> ;;;  \begin{chunk}{thechunkname}  ==> 'define thechunkname
> ;;;  \end{chunk}                  ==> 'end nil
> ;;;  \chunk{thechunkname}         ==> 'refer thechunkname
> 
> (defun ischunk-latex (line)
>  (let ((len (length line)) 
>        (mark (search "chunk" line))
>        (point 0)
>        name preline postline)
>   (when mark
>    (cond
>     ((setq mark (search "\\begin{chunk}{" line)) ; recognize define
>       (setq point (position #\} line :start (+ mark 14)))
>       (cond
>        ((null point) (values nil nil))
>        ((= point 0)  (values nil nil))
>        (t
>          (setq name (subseq line (+ mark 14) point)) 
>          ;(print (list 'define name))
>          (values 'define name))))
>     ((setq mark (search "\end{chunk}" line))     ; recognize end
>        ;(print (list 'end nil))
>        (values 'end nil))
>     ((setq mark (search "\chunk{" line))         ; recognize reference
>       (setq point (position #\} line :start (+ mark 6)))
>       (cond
>        ((null point) (values nil nil))
>        ((= point 0)  (values nil nil))
>        (t
>          (setq name (subseq line (+ mark 6) point)) 
>          ;(print (list 'refer name))
>          (values 'refer name))))
>     (t (values nil nil))))))
>   
> ;;; ischunk-noweb recognizes chunk names using the noweb convention
> ;;;
> ;;; There are 3 cases to recognize:
> ;;;  <<thechunkname>>=  ==> 'define thechunkname
> ;;;  @                  ==> 'end nil
> ;;;  <<thechunkname>>   ==> 'refer thechunkname
> 
> (defun ischunk-noweb (line)
>  (let ((len (length line)) (mark (position #\> line)) (point 0))
>   (cond
>    ((and mark                    ; recognize define
>          (> len (+ mark 2))
>          (char= #\< (schar line 0))
>          (char= #\< (schar line 1))
>          (char= #\> (schar line (+ mark 1)))
>          (char= #\= (schar line (+ mark 2))))
>      ;(print (list 'define (subseq line 0 (+ mark 2))))
>      (values 'define (subseq line 0 (+ mark 2))))
>    ((and mark                    ; recognize reference
>          (> len (+ mark 1))
>          (char= #\> (schar line (+ mark 1))))
>      (setq point (position #\< line))
>      (if
>       (and point
>            (< point (- mark 2))
>            (char= #\< (schar line (+ point 1))))
>         (values 'refer (subseq line point (+ mark 2)))
>         (values 'noise nil)))
>     ((and (> len 0)                ; end chunk
>           (char= #\@ (schar line 0)))
>       (values 'end nil))
>     (t (values nil nil)))))

\start
Date: 02 May 2007 17:19:20 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: gclweb.lisp

How would 

> \begin{chunk}{chunkname}
> ...
> \end{chunk}

deal with characters like "%" in chunkname?

Martin

\start
Date: Wed, 2 May 2007 08:34:58 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke, Tim Daly
Subject: Re: gclweb.lisp

--- Ralf Hemmecke wrote:

> I know that you want to do everything in LISP, but there are
> LaTeX-only solutions already around.
> 
> http://www.cse.ohio-state.edu/~gurari/tpf/html/LitProg.html

I'm sure there are a variety of solutions available, and in theory any
system capable of supporting the syntax we use can be applied.  Doing
it in lisp will (hopefully) allow deep integration of pamphlet handling
into Axiom.

> I haven't evaluated how good that is and whether is as powerful as 
> noweb. I also don't like the syntax and output, but it would be a way
> to avoid LISP. ;-)

You are suggesting having both the latex processing and the tangle
operation performed by TeX code?  Eeek.

> Note that TeX is a programming language and can write 
> files. (I have no idea how fast that would be, though.)
> LaTeX is a prerequisite anyway. (Or are there ideas to remove
> dependency on LaTeX?)

Actually removing the dependency on LaTeX is not theoretically
impossible and is a direction I find interesting.  (I think I got a lot
of rolled eyeballs last time I mentioned that...)  cl-typesetting has
taken a few steps towards native lisp typesetting, although it's
license is a bit of a problem for what we need and it seems to be
almost completely undocumented :-(.  Deep integration of a typesetting
engine with Axiom may have some interesting consequences.

> The part that I don't like with the
> 
> \begin{chunk}{chunkname}
> ...
> \end{chunk}
> 
> syntax is that there would then be no support for highlighting the
> code part (emacs font-lock) according to the type of code that is 
> inside the chunk. mmm-mode does that already and it works fine for
> me.

Is mmm-mode not configurable where delimiters are concerned?

> If then some of the LISP programmers on this list convince mmm-mode
> to treat
> 
> \begin{chunk}{chunkname} ... \end{chunk}
> 
> like
> 
> <<chunkname>>= ... @
>
> then I would have nothing against such a LaTeX-like syntax (except
> that using \chunk{chunkname} seems a bit longish to me and one
> should allow a (configurable) shortcut

We'll have to look at editor support - it's a good point.  I'm
commencing to think Emacs may not be the best long term approach, but
it's probably too early to say yet.

> (see section 2.1 of
>
http://citeseer.ist.psu.edu/rd/77532545%2C192192%2C1%2C0.25%2CDownload/http://citeseer.ist.psu.edu/cache/papers/cs/1105/ftp:zSzzSzftp.cs.yale.eduzSzWWWzSzHTMLzSzYALEzSzCSzSzHyPlanszSzcsuros-mikloszSzsourcezSzdoc.pdf/mittelbach97doc.pdf
> 
> ).
> 
> And another "except" would be that a non-noweb solution should be as 
> powerful as noweb.
> In particular, your solution should allow that 
> identifiers inside code chunks are automatically tagged with
> hyperlinks. 

In general, we currently don't need the full power of the noweb system
to build Axiom.  I think the automatic tagging with hyperlinks takes
place at the LaTeX level and is probably most of the work Tim is
dealing with in creating a style file for this particular LaTeX syntax.
 We can teach Lisp to output noweb-style LaTeX files but the final
hyperlinking work is actually done by LaTeX, if I understand the system
correctly.  We still need the noweb LaTeX style file, and will  need
something of the sort regardless - it is basic to that style of
typesetting.

>   Anyway extensive use of hyperlinks is a *must*. Nobody is going to 
> print a 1000+ pages document. One finds information quicker if the 
> document is online and properly hyperlinked.

Agreed, except I might be dumb enough to print it - sort of like having
a mathematical Oxford Unabridged Dictionary on the shelves ;-).  I am
certainly not proposing degrading the LaTeX options for the purpose of
simplifying things, and I don't think that's Tim's goal either.  The
hard work of making pretty noweb-type documents is done in LaTeX style
files, unless I'm mistaken.  Any noweb experts around who know for
sure?

> Look for example at ALLPROSE generated output (ALLPROSE builds on
> noweb features):
> 
>
http://www.risc.uni-linz.ac.at/people/hemmecke/AldorCombinat/combinatsu29.html#noweb.NW4LNGwX-49LjXS-1

Ah.  OK, support for everything ALLPROSE needs is a different ballgame
- I don't know how close we are to that yet.  I would like to see how
much of the ALLPROSE system I can implement in Lisp, for similar close
integration with Axiom - I know it has a number of requirements and
it's main implementation language and license are different.  The last
time I took a run at ALLPROSE I never got it fully working, but I think
that might have been due to some problems getting Aldor working (it's
been a while.)  I'll take another stab at it.

I just now got the basic tangle working again, so there is a ways to go
to get full functionality.  Tangle was the first target because it is
the basic requirement to extract the machine code for building.  With
any luck, the working scan function will also mean that most other
problems are simple to solve.  I suppose we should go ahead and handle
the noweb syntax -> LaTeX conversion, and then look at the features
ALLPROSE needs.

\start
Date: Wed, 02 May 2007 17:47:45 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: gclweb.lisp

Probably in a similar way as \begin{verbatim} ... \end{verbatim} or 
\verb do it. Otherwise I would say one can restrict chunk names to 
ordinary LaTeX text similar to what noweb provides. Note one can have

<<$e^{i\pi}=-1$>>=
  ...
@

as a chunk in noweb.

Ralf

On 05/02/2007 05:19 PM, Martin Rubey wrote:
> How would 
> 
>> \begin{chunk}{chunkname}
>> ...
>> \end{chunk}
> 
> deal with characters like "%" in chunkname?

\start
Date: Wed, 02 May 2007 18:38:30 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: gclweb.lisp

>> I know that you want to do everything in LISP, but there are
>> LaTeX-only solutions already around.

>> http://www.cse.ohio-state.edu/~gurari/tpf/html/LitProg.html
> 
> I'm sure there are a variety of solutions available, and in theory any
> system capable of supporting the syntax we use can be applied.  Doing
> it in lisp will (hopefully) allow deep integration of pamphlet handling
> into Axiom.
> 
>> I haven't evaluated how good that is and whether is as powerful as 
>> noweb. I also don't like the syntax and output, but it would be a way
>> to avoid LISP. ;-)

> You are suggesting having both the latex processing and the tangle
> operation performed by TeX code?  Eeek.

Hmm, the whole LaTeX3 project uses that approach. But I would say, the 
tangle (docstrip) is quite weak.

> Actually removing the dependency on LaTeX is not theoretically
> impossible and is a direction I find interesting.

OK, so why does nobody think of TeXmacs? That is a Wysiwyg-editor 
written in Scheme (as far as I know). One can already embed interactive 
code. Despite all dislikings ... isn't TeXmacs quite appropriate not 
only as an interface to Axiom but also as the way do write literate 
programs for Axiom? I don't know why I am suggesting this, I am not even 
using TeXmacs and always run into problems with it, but in some way I 
feel that it would be an appropriate tool for the pamphlets.

There is just one problem. As far as I can tell, there is no support for 
literate programs in TeXmacs. But isn't Lisp similar to Scheme and 
aren't you just writing a clweb?

Unfortunately, I cannot look into it since I LISP is not the language 
that I speak very fluently.

Is there someone who is interested and can look into evaluating TeXmacs 
for Axiom? Maybe we should ask someone on the TeXmacs list to give us 
some motivation to follow this direction.

\start
Date: Wed, 2 May 2007 10:12:13 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: gclweb.lisp
 
> > Actually removing the dependency on LaTeX is not theoretically
> > impossible and is a direction I find interesting.
> 
> OK, so why does nobody think of TeXmacs? That is a Wysiwyg-editor 
> written in Scheme (as far as I know).

My understanding is that it can use Scheme for extensions but the core
editor is written in C++.  There was work on a native Windows port but
I think this has stopped now.

> One can already embed interactive code. Despite all dislikings ...
> isn't TeXmacs quite appropriate not only as an interface to Axiom
> but also as the way do write literate programs for Axiom? I don't
> know why I am suggesting this, I am not even using TeXmacs and
> always run into problems with it, but in some way I 
> feel that it would be an appropriate tool for the pamphlets.

I know what you mean - its feature set maps well to the problems we
need to solve.  I guess I'm part of the "let's do everything we can in
Lisp to reduce external requirments" crowd, but learning (really
learning) how to use and extend TeXmacs should definitely be on my todo
list.  The design considerations will be similar, and TeXmacs has
realtime interaction whereas TeX is a batch processor.

> There is just one problem. As far as I can tell, there is no support
> for literate programs in TeXmacs. But isn't Lisp similar to Scheme
> and aren't you just writing a clweb?

The languages are similar, but I don't know if TeXmacs could make use
of it in that fashion - I don't know the details of the scheme
integration.

> Unfortunately, I cannot look into it since I LISP is not the language
> that I speak very fluently.

Regrettably I don't have the time it would take to dig into that right
now, but I agree it is a useful direction to pursue.

\start
Date: Wed, 02 May 2007 12:12:41 -0500
From: Jay Belanger
To: list
Subject: Re: gclweb.lisp

Ralf Hemmecke writes:

>> You are suggesting having both the latex processing and the tangle
>> operation performed by TeX code?  Eeek.
>
> Hmm, the whole LaTeX3 project uses that approach. But I would say, the
> tangle (docstrip) is quite weak.

I thought that Tim was working on having latex do both tangling and
weaving.  Am I misremembering, or did that direction die off?

> OK, so why does nobody think of TeXmacs? 
...
> There is just one problem. As far as I can tell, there is no support for
> literate programs in TeXmacs.

There was some work done in that direction 
(see http://thread.gmane.org/gmane.editors.texmacs.devel/2653), but I
don't know if anything came of it.

But is tying down Axiom development to one editor a good idea?  (If it
is a good idea, TeXmacs seems like a reasonable choice.)

\start
Date: Wed, 2 May 2007 12:14:45 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: gclweb.lisp

Ralf,

The string contained within the chunkname field of 
\begin{chunk}{chunkname}
is unparsed in the current code and can contain anything
at all. It is purely used as a key to the hash table.

David Mentre did some other work (see src/doc/booklet)
which gives meaning to the chunkname if the chunkname
follows URL syntax as in:
  file:///home/daly/foo
  http://daly.axiom-developer.org/pgm.tex
etc. This will probably become more interesting once 
firefox replaces hyperdoc.

\start
Date: Wed, 2 May 2007 12:26:39 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: gclweb.lisp

Ralf,

I've been using the chunk mechanism for including several groups
of information in files. I've had stanzas for regression test
code and stanzas for user example code. In a latex world it is
probably better to define their own tags so they can be processed
in a different form. In the book we have

\spadcommand{a = 1 + 1}

rather than chunks. Such tagging allows a program to extract
and process this information based on semantics rather than
syntax.

\start
Date: Wed, 2 May 2007 12:34:35 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: gclweb.lisp

Ralf,

Lisp integration is certainly an important subgoal for me, anyway.

Once I have the tangle machinery native to lisp I can make Axiom
do many more things in more natural ways. For example, it becomes
trivial to be able to do
  )compile foo.pamphlet
since I can now extract the code directly.
 
I can post-process the code (for example, highlight or 
hyperlink it) because Axiom knows everything about the symbols.
I can tell if FunctionName is a function, what it is bound to,
what file it lives in, what database attributes it has, what
domain it comes from, etc.

Using latex syntax also means that I can integrate the chunking
into the Axiom )set output latex machinery. Thus Axiom could be
made to read and write pamphlets.

\start
Date: Wed, 02 May 2007 22:37:29 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: gclweb.lisp

Of course. See also the aldordoc part of ALLPROSE.

http://www.hemmecke.de/aldor/allprose/myalpsse25.html

Ralf

On 05/02/2007 07:26 PM, Tim Daly wrote:
> Ralf,
> 
> I've been using the chunk mechanism for including several groups
> of information in files. I've had stanzas for regression test
> code and stanzas for user example code. In a latex world it is
> probably better to define their own tags so they can be processed
> in a different form. In the book we have
> 
> \spadcommand{a = 1 + 1}
> 
> rather than chunks. Such tagging allows a program to extract
> and process this information based on semantics rather than
> syntax.

\start
Date: Wed, 2 May 2007 14:10:54 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: cl-web 0.5

Looks like the other one got stuck on the file size limit, so I'll just
post the essential files and link to the bib file:

http://www.math.utah.edu/pub/tex/bib/litprog.bib

The rest should be in the attached tarball.

Cliff

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-1894466935-1178140254=:41406

H4sICFP9OEYAA2NsLXdlYi50YXIA7Fttc9s4kp6vx1+Byn4YKyMrdmInF8/u
1iiyJlGtY3sleTyp8VUFIiELa4rkEKQcjcv/fZ9uACQlvyS+TXIvG1UlFkmw
u9Hd6H66ARUyOY/Vk+++5GcLnxe7u/R3+8XuVvOv/3y3vfV8+/n2i+c7L559
t7W9/QzDxe4Xlcp9SlPIXIjvwqXMsnvGfez5/9FPYe2fl0msTWavOvT1M/Ig
Az/f2bnL/s+fPtth++/u7O5u776A/Xe3d7a+E1ufUYY7P//m9t/QU7GRpIXY
mOok2sxkeCHPldiTH3Q67xhVlFmrFWxEauofNZ4Egj4be6XBG2FM/zYv1aTl
76sPWZoX4lEmi1ki52qzSDdNkevk/JF4BJfbVB+KzSxPz3M5f9QCn2BDJ7fL
ELAMZSJu0iLRYwWmf/rBTCDFhpkQ4b1EFnqhNmmwG+jGCVGTW5MCL9uhMj83
Ii2Lm2TpDT+6OXhPJ1lZiERDD3iRvuOP2LuUuhDFGttMzrNZrAo/E5KMvldz
gfpMOTHqd7Fxy4x5kNgSVtH2s5GlRhc6TcSfzjr3vLU3zdP5pkoiCEUq//HH
x/4TxkomZeYvg/8AWTwXkxQO4kVmMoZmkiJOFFZisRHpXIVFmi/Fo07nCb3x
5HGH/sCwPJ11TT96Upr8yUQnT/L5I7Fhad0ldYv0yg7yCVzjxyb7vFytC3wK
76k0seNtrfJ5BIARdFKoPLthhk8Qzb755YT7NOZf2Rcqvp/fG2AMGZ+rSS6d
EWiZfIId3EtfzBDifo3U7E0mo8+rEtLJ4/pDObUQZcJ4AqMbj2C2Qs9VsEEM
k09f0B3v+F5wi1XuCXQbdwZZK/snRhP680WYQ2WDRBQzJUKJBJpOOc626U6O
NIt/JlOhljHSjMqMuJzpcCYSpRC5UzFRopAXKkFcEGkeqZxvggDEkBmTjSFk
iUzaIVavVChLy6aYSctG8OSsExOdYqaNqJUgY5OKMIUV8YwwIS4i1XaCXOo4
JilIIBV1Aq+TSnVZsUQCXNPfjcdEF3fdVWgvWzepTQqdhPHTO8n5546ev7QE
b6FXLOGAmbmTnn/u6PnLO+lNigxqvE8++7ySz17eQ8+EMrmPnn1e0bOX981X
5vdOlx7Xs6Wryho/3kIOQSOX99CzzyuC9vIe8Ypcqe176NnnFT176ek9IBd8
/UCykgK/DPuGOh038LpYpPHumjLXnzp9Dvh2rvD/R7W5mke+yHwCQf//T9dG
/w6fuv5HEfhFqv+P1v8vnu08s/U/iv/nW89R/+8839r9Vv9/jc+3+v9b/f+t
/v9W/3+r/x9QZn9rANzkXHcAbi3+SUN3h5LP0xG4eyYe23zCfL5k1+BrCfj/
rbPw6Xp7tDlc7STc341o3d6OaD2Q5Wqz4WM9i9YdTYuHcl1tSXyss9G6o7Xx
8Lk2Gxcf63+07miAPJxrs73xsS5J6442yX9Dw402yP2tlNbtvRTqnTyQZ7NT
8rGGS+uOjsvDZ9rsp3ysLdO6oy9zL1D5Fzo0/ysC+/1dnK8m4oPM2mzr3N8c
at3dHWqJW7Y8/qUW0ddRluAm0rc20r0f1/+xhfvmYqtjjV6Z7HPwuLf/s737
dGt3157/2dp6uvN0h85/vNh6/q3/8zU+Z1EalnOVFGEsjbkCctdhrK5FcAZI
5zoxV9yIuV65da7SuSry5erd2TJTea6muOsHXC1UPkmNasOZKLhIjGgXc5mf
6+Qv2zppTxrf48b3vP6+xhooFDjR4C4CyEJHKkznc5lEV2eFnJSxzBN1icJD
XV+dnWHQRIHMlZ8nbhS6iBUGIwQVxVXvYPO0/+pakO+LTXGgIaUslDi2wWlO
IWecprERg3kWK6IBnAzc2j0cDUQPrNMEb5mMlCbLYpbmV71YT6fAzuIdnKYt
TmUcqQvxRk20CWdt8Tep8Q+UzYWGPHOgbZbJyyonBLVDyCrE4RGkE0DPDOfJ
SDqs8LeQ50lqYDJA9DQWUFIkwBeQ2k0iqycBWtoWBaZYxgzX/5ZA3O8NUL4G
W5QDYNURYkxgnQlqP2MjpIA5ZynNHJQYsxMnxhxhQUpi0mmZh4rRvKA+Uy2J
17/pBGcKtqrneKb+gdQRkPFilU6pLKBx/n5wZvBHp8nVSRaBEuwenCWpTiKM
EmfkXj9tPH2yvftk60XrJ1hwkOiCahsYdFvkKlaogaKzs1tfeu5fgokgqDeR
cI5lBPkR4gMVqKAlo02dbIazMrm4g+ALT/CtTqCecAZLKSqgwpkKL1hlP9Fd
mjoWAjSVLaH9GcGkD7fR3Hny9KWniRnt4E9lFbyDuZJBScMYb6j9hwW25nEw
MeaizxMYd3SpC0wQEkVqChOUYdG5ne+zrQZfWhq5Ta8GC9vVazKKhFpIJI+Z
Skyb5iAm5Tk5GqIAis0EzgAVRNQHaIt5itKTlh1xrO3aq3SAkVhKIWgpWNk6
ogcJ+CoXUsfkJaJMuC6Fx71NIz3V8PtXo31Yi99lH1biEiuQHZ8rU4sLxKU0
ziqRMDFxjZeYiHHFMbgkKRbEuUz0H5LbqVhyKYplrPoApWkxsysRzsBPmTbe
IuJtTL4QelrTkslS/F4qw0O5crYSBvSQ0Bbm4Yvu5kw6QfDnP1e+8de//oUQ
WK2njbAlnm5tvWiLB0QaItFFZc0kDAxkVL6g+jr4ibg5yRyvoYo04S1MiHUA
w1CND8O6JU53gNgkEB/4z2F81g38m/6ilCYqc55SyJpqc+MBzjnXBUVQt8Qi
bhpY+6RxnF5SKEEMiLiXbeglpqSKPfylr/hsrslnyAzN2DNHWscMub9ApOUk
Xah6sTkyArZG8FRta0JGnCDU5E5t8hXRwBZRGOEg79wnD/g2tOPlwZyjEjJ+
KZEoOHs6NMYHXemN+AT2Sck7xRwOnSNMmtoQ3rkrEs0prcyWVhfvq/ilRUGb
R6a5AeklzYJ8mjMS3Bt+jieK3APs5mlRM7E6KShE5XpBCYzyBs/epNPikrzG
uZRtW8Gh8JImT8vJleops3MZU0s7fjMYidHRz+PT7rAv8P14ePTLYL+/L169
E+M3fdE7On43HLx+MxZvjg72+8MRsvo+7h6Oh4NXJ+Mj3HjUHYHSYPSIH3UP
34n+r8fD/mgkjoZi8Pb4YAByoD/sHo4H/VFbDA57Byf7g8PXbQESSOBjcTB4
Oxj390miozYzvvmiOPpZvO0Pe29w2X01OBiM3zHHnwfjQ+L2M9h1QeG4OxwP
eicH3aE4PhkeH436gia3Pxj1DrqDt/39DiQAV9H/pX84FqM33YODtbkenR72
hyAFiitTfdWHpN1XB33LDFPdHwz7vTHNqf7WgwIh4kFbjI77vQG+gFT/1z5m
1B2+awtLddT/+wmG4bHY777tvsYEN+7WjIBeaG7Do97JsP+WBIc6RievRuPB
+GTcF6+PjvZZ46P+8JdBrz/6URwcjVhpJ6N+GzzGXWJtiUBnGIDRr05GA9be
4HDcHw5PjseDo8MWjH0K7UDOLl7eZzUfHfKEoaij4TuQBSHSBdsBcfVNH0+G
pFnWWJdUMYLmemPRGAaOUOS4MVOQOey/Phi87h/2+vT8iOicDkb9Fsw2gHSv
iSixPu2C7wlPnMwFyezXAfmfd+I2m1UMfhbd/V8GJLwbDkcYDZzbsOp6b5zi
KcCjhPcwy2fdAVYsrzwKDZsOZ9oEfBMBE+aixK2Lq1sfE74IEQAUAcUG6GSC
kVqoOM0YsVgQmcbp+dIG/ilClFGGA0aaBM0gjhW+GsAou9KaZ8LCC4Q0f0Fx
yEHNMkf54nrLNHCCeNfmXHtOYkcskkvwSOkI1IC2MkkYT0Ag7oFcKrlQZiWl
+Lg7QRlynqdAIFUMtS9mJYKYJgIBY9gPBcM9KWYl6DN6RNKAJca5tMEcb67o
KsOVBFAkbaD8ieMlTcS4HFDNnFUKmHVO4KYpYgUoiO8clABemUI5z1wKZql1
pRwpqK5ic7Iam5BEfchinz/N0hQKUTkNNCYJg+WmaVpc+rohxFQZHCmCWXGs
gLQ4HRpdlNKmsEuGR4QjUwho8xFUaFlVxYitpQKXYZrzpI0BqlAsvlhC6R7B
rTkM2M5RH/E2iCHIlSbQaZymBn9QGrA/gM4ag8CqaUkZjNIORKDKA1McJOQr
S0cQk1+T2ZuToP1Uho2kaiWfqSeGkGmODAjRkmJG1ZdYosYwAYmD9xxjeJSE
qMY0bWFhPP6E2lRoAOlUL5xqrcdlXMdTKSwyrUJlIUSkvJEywHVoP5HtoB4K
ldBuDKpuXnooqlFmfPBTAsAj06KaYo1JkZTzCewGygTGjc4ZmNdWdiDccLVC
HpwoC3rJOwALAq6pkNGb7izSOLKasj5ikbqFFB48lUnlpQa4RajpFCGN+L2l
+gK+qdOSYQ0EmhOC1EAe1j8CNytdLGvowivHSmUQCasCAVbAcFXJDPmgI3jc
lBRWiKjkyg7FYJJeJk+gBud8JJmNssZrvh3YMJXAeS/FVHGcsqvlPNeJ0+lM
gi4m0ifH0q6yiFIXHmcIEAqLuJKADcalECrAJPJFOKZnCguj4cu8mxbrubYg
uzZbllKdTeFrBb2xIFAeZQukjlv7IbySVBWw+J1FqlmCDfLAghwFRsdocP4D
91vEnSoIY1APYY7dG10KK6rPJB5XhiorjN1UvFBLvwIsGRvQbACBn6U51EAB
mDC3L95cPebCCdd/LpIGkosgmVPBT30pcnuAdJDhpR4hzFjG9iYByImiOTrg
6eq9hOpge/TGxRI3vnYvX7ETV7oLv5XGLYe4JFcmsVQc+xU6VzIxNq8g3pCy
OZCYkkyvKZM28hA7ofcCXv48GY5NgSknZEphgKCxuCiy0ELFO1n5xx+xjXAk
k7NCuxIFmYrmou3e7m2OcBbi5hW3kfa2X/7ns72D47aoLndweS2oywMHJnGJ
6T6lvcgOage1YXycH6tfRbHMYJeCfdhmHht6m2q2hsBcca2sQzccBinBqHjq
hKn1j7ADmHND7NPR6NpqpFilktBNbnCFqnM2TdMCC1FddWOqR85njR31UOWU
VAP3akmb63B9hFOIrHhZcXc01skFzF21w9pVF871+WilSxHGbGQ4JFfpOQd2
WKhIQ6rZuK5yufk0zaHQUwqFp2qCQMOb6JJDDzUJquahbVXaPR6Stu5f2F6J
eP/+Uk2+/94T9iiGQ9gcuqE0f23Dus94pE6PDmhprfU0WE723GNpIPnagrVG
kb7ST43iedrnvsmJYEEcg16D1WTpLMuAVS2WwtqUvpJJX8D1em1RX552e+3A
W/zls73eaFQ9fkl+27uGe8mMYjfxgfg9Jt774Qc43yEFlEQMkQcVIQcZE3h0
gBGg1C+tDPla2+UVOBSE11ZnSvqUt7ZoK0XaYxBQ541Gr1UgDIRZvQRHwFgP
wii2MIq3qrCy0uxf7p0eDNrV9cttTHcs26K+Qyt1dN1x3Wb44kLnRamMPStC
4iPoIN0Q70ok6hdS9qYmX8dyFkAptNiR8I1F9hSF3r+nLUg6daA5AsLDmsc9
uFNofOj0q40dsxEHXJpGBCTnBrgyM+gyYAtQXqjEqnIrCds4qIlKp3RrVc2z
GdI5LIgpH7GzWc0jIZemSOfWuJQIq45DRR8pO6DzMTY4yDBECC5cX90zuQWz
Uod0ZUK+5DJlRsnC2GRPk1+Qqheat1ppzdk042FAULd/4XmSCq6QcA+va8Kg
TgE2fBvFnXyMijnPI5RQY6a4VOvQtXJIJ7XNoaTFwH41jSTDKQSLUGnWnrwl
ZIuN0pRcwyCktwTjUgojOqYqyB8aogxlDxndojO9JqIPmg4iS97oKGKGq0nK
yXw+gaFC5bzJkQYd62pEzddFVRFhlCJN8m7GQsal61biFnftJspvcvjeVNAs
NDo2X1MHuMxZGQwxqemJ8ZOlRWTW4UyjTEVAa658CsyMCfCoKodYCZEOKW44
bFfpSjZqDSxYhpfwZvKoKrfgjdKuYVtdM8Kn6jblwoViOy2ShsqtqwW8w1Fh
V1Y3mCNaxFQV+4NbVYuf1WiD9tqbzoK1siiU29Z44N0DKIzOivGbzk4ujDBS
Aq5d6IjyKZcyps5OOR05sBppi4AEVwRGbcVDMtPIMm/uRVghHSEGS1gW1vPm
lbkDqusKK1xmAV6ToVG/l8r5mKQe7IpbFSlX+kyxKrfyFPxMQA1dOUltfULc
VZ7btE61EYpM+guXoR2TNsyyvrvmVep5ESNeidxjdqDcrSME27nMl8E/0om5
J+NQcOgQtuJgZNFuFfPcvqpNcxx/OEaBpOBKH9V9JKrfjdTwKHC5GeWKtJE9
R6LKo1sWeOWNtk5ml7SGdwdIbTdj3qzW2lUvhgscdgALh1xyuJTLelfBK6sO
XsYFTnr6/r3jgqREfLzJtPGtF4o3VRFfRaBQUckUBguNcq5SuU025IlU2E0Y
Qk1LYxXdWLAU522msXnGt3YcgI/TxO+h8gHKTd8Tp5OXtIsOnKETBmbEP7ht
IqvlrZ0slxG8/hqGoGJDf4AcZXZjuV4HwYDn4tr5yPXaw55b3Ukni5RjBG/1
ccnLkYwxxLKaZ9MulUUDbQM74SQdWwqKNrcKS6P5gvih2bqifhT1ZbBkvf28
CprCRYq82aDso4KD8ftq8VzbkToHrsQwNCEAhUEjBcfUtLAlBhs2TXPfq7O+
+P7976VGwcM9MmCpJawCQnZzqGpWcXVczqtZpr5zVi9WnyRqzTZKQOo7wOLn
al1y2t31nkr3ZwhSJMrljNse1MPz0nSCU0Im3jK+27MC5GMq5flcQUpDqMES
2a0fOrfNO4Gqaiv6Iwi3DKXYxu0z6mBQRC441Bm32UVrjsQIOfJW9TyZFEUh
gSNxnqaImh8kQSBq1Tis4WoeYzVE06NzEueJ3WZklSCaUlHLDVpXP0XAILTH
L6e0pOitGmnULWvgKHcGo3kYAjhqKc5VAiOhqJlSS4nbX75a7dKRme+ZkY2+
/AJLEKkpa8kfsQpq3OirfpszuGzf8OdU7BGt6xZiKXyLAC4ndKiAfifEwcCj
dznRMVedvgdnAdlaB2DDdhRoN58Waov9D7E4D3jpucn53unUHcemYMRw67Lt
2uFGhxZkqITWVKexs78mOxW54ER+1uNsP/Izp0CT1PqUFg00Cu6q288Prq03
IKs0StgbR02auwArGMeUOTdOGKAFSJMXiH3WhTSdgaBteE4SvjVsrXrtW7MU
dG3LZiYXPp7V+7GVPfcCf6KHzlQAxM2vg8cP+zx4/G/bWKuR4oafyv/rMeuL
fwT3+Len3Gr1j4LNh31o/G/P8iaJClj9tgNXqu9X4x9E/7fdFSJfXFV8Dqm2
DHe7oL22eErwi8LaikBYcEjauV121OXhkzasXy5lY5tWSUP0LjQS8IkHKksS
V19IX+8ygHT+6VokHmbyynCnoHw682d74OoUirhRGrhAwG+tSCrsT3AcwanO
aQsE8X5erRW7O8Und2XnoiMR3ABF6JALhRSKh8iS7hhdq7mi/eGqfcVnjyid
Oc1ZNvSDEoYbqYtztuqjxhOfGfM/7myUZFw6JaHdEEPpa9vA0Jr2UM/YM0tc
cNutNkel5mJ/LFnaVU8bHQP7o5OAfwHDudG9w2eY1gJT9ZMTygsUvQsrFyct
Ottnf7FSlYyUeF3O8aJbQL+QuabgagPiWjNsoW1vKC0L3rhoSOUCNYTiGj7w
yNsXS2wzxnd1TPTRvvrtDYHAJAXSgMvRSSxqIG1QgyKPHAKlMTaZ/dz9e8tu
E1GyDdwWUl2xIv3Eekrx1Lld1f+oqgPnk8Y75SakJa92QkCvLIHkhzZnNDam
guo3REIMGzWvjNKssFbmdkViq/FLZW3kgCTN2SPef7b3pd1tW9ei/Wr8ilNn
MJWSFDFw0rW9Yjt26nddxytS2r4V5TUgCUqISYIFSNmqrvLb3x7OCIKURFLu
vXeZbUwRwxn32fMAfcHUJOK+9JSqUwsuUogqbKZX89OG1VUv1ZlV0A2ySVca
Vkitj045ZMAABmpCuhq5655FcPD5MpQ5IIiWHckJ0C4T04QWQJxcU7+r3euQ
+rxPCq9ARoG5GPU+TBKt3AwlCLKwI8At52Q3BI5CGkKI+1CsZ0ZaAbQyszCh
5GpvksUjyQmi0KowEEm6hdHhmDXOlGQM+0L9sWyGi4JyLg2EbL4zj9/VFBOa
IUc3uS4NmA+6n9nR5rx0GOisw8wPPCu2/IsjBoKV4HEViu7V9ArCW3LwjUUG
vByweOIIp2v9TD4mw+UCs1TAIGAKCMbz92e6vQPylnuFC4DSN7k1nqMuEv8w
uu1FMjyfpej5p12gjNrOBg0e/bVAGzqdNY3VlWotz+PLQpqgYzIIUBgEG+pA
IoJxwxp/JEECziZxaHJojDxRfJNL7hHKR9Q0QJMs6RvQfDXjbihS8HKB1prl
Qk1LEiR290JGseCXmXvkseBpKNictpws6lLRSHBHJ013QHMw/C6rWDmso3QL
LSEc/yc8tVjUhokEua7DUXyPFt8L4lR56TVCrjthhgUp4mfcgWWqUypJD1VY
8wVaKxPrRsnJU7ZNh5UWWyJuVH+yGy7tsHbENiO/9izWstS3RC6ApLghic3T
GTzA+QVw7aS6Ck8hGUl4sMp4svDUwUQM0BQ/zNjPEE0qhP1w10HiAdSbjOqw
VxiaZUbMqKQgl4MhOk9LlEZdEXedzM7Qv1MaU/WICCnpXfRkEKgoEMXxO7BE
rxjdIuVGXFPnvVho8nIh14CbHWbzNFE2K+kMrl2mkUCZH5IlSGT3RjMkgSpF
P1fUAZKf6+PHJQhS2GYp4dNOKhHnHJ5dk4smaho8anzOQiuAm6O4afdq7PLQ
4MnUljOWRBt4skQPMMs3BwfQnXy5BvvwjajB1wz7xEGMYAMl0s5Fy+0E81OI
Gi66Gii8eOA8UxtlCAJA+1O66Y4Rm0gWY+wrGeMyiRSGhDxTA5dVXo/xstss
PCqxHykMFIoB9CF1voRsFlkucQ0akgmHCHLsV1I3WnIXbPkmTpJMLZ7U1ZGw
NKONLFIEYEtaX5yTyqZkrUbMMxOeMf5L6wceMeSSLA4qlkydNSbyPGPGCbBu
PAFWwnPOOF1FEr9IyKVC2awIOyF5lB6+rGUxDaNOD5VfnoUl0UyFmPKFhU/J
vsY4lGE3xpOIXiB2a8hXjNOzZa69mognJYaIzMVDslaTyhmhHF+lNw01haXC
KEAh5UF8okGPfCOhyVwRRzhZ8YjmLrf8RNu5Fx8IpaLObIEsBWvNCdNKVryh
BIeG9psrgCzLnw3BW8EizECbpVmZXooa5dgB5kpLzNQRTpRkjoYejpquuuAO
xG8duHetUdUQ9vnPL06FnLQWer4zIiB6eg+zsxn5tMDfZ1ICojOBYb+KueFs
MBwVQMyOMktavCo5tysVAbSPyOXaO8W/pOKG5DjSHxk5k8GPVnxhP8OOJ6QR
KfGhCGvKv4LaadqdoC5T3iTG1H7QCcmnLvXYV/oeZKPL9b1YUzECMKpeyGJm
OSSauwgSM8usVDXqfbfGzA5ORU1dMRFw/hfLhcQX1pqpxlCZoPdQml4tcVDJ
j1IWNKEs8WKFVycKjvDN3GFDC/YN3SCB+lacLXLPnGlDUjdicxkt0CaZ7sTD
x48fHlQ8RyG3MGH7URhR5bOwA7duF59dabbyydJT33L6qG9Jjcg2UvKEnKFu
XWrL1em0o4F4M4ZAd9GuAbSlLnkmS+sjEdyEkZVW8SN5FmvYElKKAqr/c/YB
edO6WM7IJcJwJii8YaQHn9Ai8awOEc2eo7kM8dHIyKoWdXTQmGLiCstSIz3U
0Bk5Hl2gSRw51Yy1UTmIDKyyJvkVCTURFIZDS7C0Dj+5PKA4n59p47I1alsq
UX4/K76oWsghosDa3gVz2yOtTzIuvgl5HrDSTK+tZWY8AerwnnqcLMn4KU6/
0IGJc+gIholGp3hCKudpongIsoegL7MlkqVSUm2KF//3Gs+eGl6D0coqleHV
WvuYqCHc/spnjTN11b+tTbKMx5fyvvoOdzbmkEFYNpSZizWncphNJujKb7/5
q0PZ6jX2BhE16cWBWckeHp88+/Gk8eLPP739T/j32Y+N3589RDZPlDhEixjW
8U/FB245/Apkse0MXr79rvH22V9eOsO/39FXoa/dNuDHl68+8fj3t/ifduz7
G/cq0N88cklQ3pKDB3KsiJUvEo0cs2VukwklecowafT3JOZVYQgZ1yiRg0Lq
07r3ISFXCmUUB5yyyFzkCIhvSW7aI0Wx8uWMGGBi3Sk8v4Sf1qKlEmvLwgip
aYkEGIuc8DzLSYt87GzHakbYxGNJzx2SRgyHg6Ige2XYYiBqHhz9zzl6/MvA
G9O6pf1RmnwyRNZZQOIWLErlmZYcl7aZdniXKlxHvnAdw3gapk12Sog5BhMb
V+y0SrRYsOKzmGczpWDHVeJ21CS1flVqilIVnR5PlklBFiK03sK7/0ryjGXA
GTqMgdApFc0nTB/lpJXelVny5SLDJWOTuYq7gR+F0ZrxWVKalGvqwr1HMhKs
0zXrFIeaVZlkWi9s7VqDPOCKxLGasAC3kIoc2ZvNU2fkho7yOnpxo60HA6/V
QAiQ2bbL9h/tCYHxEikBr3QKpchQNRjbKZu0pBSrzuZgs/lKKZAWHvJHl8mC
HS2TJpF6RWZlm4rAqwXHu8g1q2USLWKi1YqKRzWFK0wU/Ymt/tdLjwuKEGac
cOTRXnEd1cDIx0hCAR8Qj72/C2NeRm+kJL/2arUajM/HaQcHaIgB0us/eiTw
aohXI3U1kFfbeLVz0Gw2YQokw6i2rMmY4fJ6FhTKzGZNcxhUqLXU4TkSKOud
AfBY7aFf93T8AyuRyNSIpjzGTm9h718Y7RJCDvoOSOBCH226CYNlPKaj8jks
ygSfs8Q80foEaW+NBQX1JFqxW7eUzSOUnhql08P4SKfFU/kdLFWlI64b+6u3
OJc4YkQsNueDSO3dprgdwBOv0UOHnI1mjxhY6U5dasP4ZLCR2SO7j+5a0SAb
9hHDwFwYleqWVZO0Y6ORjEaUDaGjIr9COtOqhbA1p1X3AbjiqcEDX2dz2QWd
IhjawS20q0ZDKmq14TLnPgQQtwVRFOpiVaPl6C11gmP9/gHltdVS8AP1IKlF
rV5YTXpTX94D+HADBofhCHS782Whtwj5DHeZbjEXd4Q1F2ffogXhLrlZml1H
ptGedWR/lHrhd5LQFqyjpwQ5FPo6K8ZJzmmTGS0QK0QuaYDq0HaHFgi2C8yk
XhWdTtLivci0DKndzL1pMsW0Y7oXwV707L47jtPc9iUzhhugYqQwo3walrkO
pX1PR66cSy/5cVyQUlTHd5CPr5FnDb+CxsFcnSytS1ZIZcwqGrYNXMujXBj7
GKmLESvBOSD9q3JkZ3ZFqk2xc23qmLEWm5LT2K7Jo4zDJBZy9o7eA1fL09ha
UhdHW6q43CTOJynyT5ZPnbS5WEowbQ/yWAuJZkBjubKsMMr+zI/oMal1Qtal
yZpda6EsZONcBz7fNaIMGmRGoYekwWpcsp8MluOxPKqyDU409yfBL/srokHp
c5SwzqBBxp5HJfuO6Dlmk5q7LdT52LptmWLoHo3hwNkJ8zQ+sU4okVvtGC94
320STH4UJGykaKSUh1C+Ix1aAKhnhYGUMcVE0pmmOCgpkown8VlhhICFsoEq
OzXx4dASA67iWQGCllNyaGYGkpxk9NmUYEUTKZ0vhhr0Hl0Mzw3gikTpb7Bv
FRRXfdgIrGg7lAxAGQMt2Fq9yVRMwhiezQbOSd4aM2a8GR4sYuSC75iLXdjy
2DvLhKBQqCB3g4Z4Q3hROU8ytWe+50cdiXHNsPGBFii9IPUy4dDE0tSvdT6Q
SFEypcpgrbDxmONCLF0dj2FDHIj2a8sKW8dXqEAQkn9i0pMnMiTboGJ2AmJH
eiViwEjJtZukAD1uDlsZsLiqbBB2fPNK0DdNhDIAOEl1FDCyqMGEgjxXRhjy
h5G/iKA5Rh7jGSu8TmWssp4HNiTzdClpLZsRHveseaGXhtSCSD7YJasnXFWF
BPVX3NoxZf36C3vFX3uvVvpIC1ZEyyibIaKZ5UTrsLVrQ0K+yTqkgIQ96TTi
SS+gusz2II87+SqgapVM/ZRDWjoXc4w6nkJS2+p0AOgEQAP03AFqRbHjGr2I
i/fu/kuvMxQUaDPRUZEHpXZ9M2Cn0v3JtCNjRVSGJf0oadG9gaaASNGlgbdA
HTjChY6IrGvnE0Jtc52zCjCVCn9CW7cTAMpBi1aWJPVsZVysEv1IijC9KJu2
R4F9bLVS9gGOLUKQRiTNYTi38gatA4flaXsDGkxgPOjtzMCx4iQqtJOopaBn
c1+CKavc8YLs7ToTpRyTSMFkFS3haMyyYISyytLGIW3eFLmMhnxJt9u0zdV+
l+0jKsk5rjq78Y6WuVboMJBL41DsKolWpWz5UyabvL76ryH8Dy6f00i879KY
IjbexINk8rX3HeUzoDUo5aeUb+gXj4uvPemSRxrn6sfhuZl6bu0Tw2Lxtadc
M6TtFYBh/fMz63FcxQ1PJvSoZP6IBK5tmR6HkWBhEV7tPGb/P7K9q9CL23Q7
sAaI5tmNU0GdET+KF9c/mluNGkvxLZYrn1W+uXkKubt0lml6Y1fjr4GJQtEZ
uURSko8xeGH9G0n6tfd6xrlRuCse58ZukhT36Rzj9XhTbvvqyyVszUsKZFzO
ko+AX8mNeIkRPtjI2vfOZuq9szgfUJA7dbxpEV9msBoveWTIFa07UajIUuez
pNY60bkZZf5HoVKRSt8aNkfqQ0sIn1EIBhwt8iXG5MacsETSPGLAOQvnqsWS
VeBnKcXcxmc0PxkCFi+Uc7cneS7p/TlVEQPSaO3akhfpZEXlRHic0D1wVe8p
PAflawpmkghJJpdQMiy2mUgvQdeJPKWBojOUnjjz60btF8Nj0wToND4ATyLe
JEKkJi3flKHmniE9nEMAaZB+lpAu9ChJXSwd6nUVCvanwVxbqAAYe/ZctU0F
mBLyglLeWFbgsOkpPkNX0IXR+nskaFh7VRCDQU6STGzGlLSUXKBtOAGOJx7r
hEoemYEsVWOR6cAPHT5M3k9xYaeEWjHhe5QWsk45ydAUpGKSFZ/o2IV4e7WD
rxb+MDiF/eDVvFwQIYAdYAYAw+MYkkmDd3ly1Noo47xORKm5GIyQn1EahIR9
S3GRpXjJ5DW5QFdw4Bqm7M+PegBrMc3Y9DYXpGj1LMMPpvtC/mshfcvl2CZI
ZWW8KciY0PeA+BgM0mFFQzzyFESt2GscJyblsY7joHwGtBxL4uKhNY+6snNG
mIxmykpmzapATTsyVnoT4JighuTXX3nf7OsUyGLlPTIrTm7MJtsMPIbRsQUK
OcR9G9DVh7MoNSEZLVZVc84OTjngyekv0NvoEzE5b4dfe2+ZybGHDoew9mxm
+9CYtHDlFr/2WJ5URWws/FoWAGQKm+bBmlG9hbG/LfOdNJw1L7w09GesggDW
8j4w1R9d9FIJgIQXVyfp4EcHUDVNbq7tOpn9+/rO77Vrh23aMIhkv6Nw2KHb
jSHZ1/6r8CN7CMgDb+r97eJ2va/26yItrTFZ5hSwvblLOB2vCLkhDnUP1Nq3
QOo5RmngdgdwE2vn/Y0pa0nZRPK1VH3q5JSSfpr06Sq9gOLtFB9RRilSWDwF
GLgap2dH3Ai14aN5sPZMjLIl2giGaT5kx3ePACaXVnLW97PPNmPfA6yOJjEu
OXon1z+fL+a/eEKc8uw4gf+pNJeqEghX3HmDWmnIEdJLMeHiK0dVpHC2yrT2
7O33b17qOC98T5wSjVudFy+0HBrHe1pcJXuuzGU6POndb+UpQP0W6V0urXwr
2iNaRTwpIzerwhQvIzNnYxCj43yhT0KhlcPI+ZLtyORGY6/EklX5mXKakOvy
vXTQgUafY2ZKtDtpl2/0iEHHxmvLtdT49oDgkgKhzS/FiidkXWjqanNNc84T
xwfQsyi6WhanIXYKKDQbiMqzhuIBRzqdDvIpYyCAHrMtqITXjkl1FkdqWh06
uTxQdibLo3SajkYTGW+bzJSNZ9q0Xf/P8ySR+QCkNkUOy/DaE1oJGR1mZCEM
wiUhwrP8wPUYeal4BOS7paKNnorgwMT04LDcu/5BU3paqyhDNo+NeZOI2VUO
Hyh4f6R8LkM5lksZE8U6R469JGUvdqbSH7jQ6MSnSR9bdGnRUF0kVkSwWh7G
RcnI0/ZEZu7tdChuP2gxW87qMqLWRkNWPOiHHFV7wN1yFkhaaeCtFbQbgMeU
AKzZPzarz5aDtyCMOgHcK4ifLxuoPMfj9iEzplDF7jqcZfk4mFiw12O1f2mh
FckwbJVpc5idKU9gxQCQj4Zn0zFWARfmFfcN07uJB5OpaoYqhlsJf5ZLuNFD
KR7/Q1rIgZWootYTqI6USwc7LStUtpzPJ6hs1uF0tfTAysNhUFQpvs5qd6YL
SDQthzyqOJFL1Khnj4pNwr0pBd4wC81Tp7SBOrukXEC+51nO1yn7znCSGMqg
mZq8N0b6pGQpH2aybVoxNK8BoNH5vmt0woEywXH8sGoGV8uTLhxPhC9SZUr7
lS4l/5Q+keyfK/0X0I/Tt0ysJtbBtrnyKwDDaPnFL9fuWzvLhKr0Qg7Mxqh7
l77PMseFG/AR3MamZKzCeIVsWGfjjBgVGRavDkhuvO5i1iQaxbv3Z7hd16I0
qWYVCtI0gzLiSj8CPrFKEFwHgQ2MXkil5K3cF21eTQOgzuPjlUEMcSRqBepS
fJ8srcPBXsEbToVXHpMCNhj97qBGZMUA2lMYi95Dcg5Q+/lrtX8x+xazb/fJ
s+/JwbjWoFYOZPi4BolH0MIQUy8X1iV2PKIwNOMJgI/oZ0owdyf3fjUE9COy
XJ42HIMHmw8ATsIejeus8IBeZfMEg739or7lnoJV8DPxuyFageRZsHiqQiv6
JN9g6brIh4fUWDbkl1yJVVOzkQq1kb4O6Kgi5SNljVEatpRPiqqqS1HMKi2g
RThzbcuyMjzrrF/uyVByR37pGc0lhnqtqFJtHtCalDwKvAq7nwbFhbkHIjAH
Qvnx/8aOWwGukwR3MjXORo7/jHOC5KU7nKLfqk7R2rN0+xO167n6TQ1KrPoL
IZTfHlX8Zk7o6gQ3nTPTWem0Pag6bOq0lVhDTAnFrOFLFQJpGENiBZ5rqzLc
5XvSARf4xmeWNtsJBnWyUNUd0lHBr+EoLJZxQTkFKAkoMyRlRkYzJBRvUMWM
lOpfa0dfy7i8bkw6WeLk0tOCm8p+hqIsiIqFDIAtx4Eq5tHJ4a6qDixc6dV9
CbulOgImuaVBANJ/rJxfRr1nO+bFmte08hix+T4ul4/wdAZTC3liflGyq5v+
K6P8FH7VFqFC5o2V1n3i7vFmwfHbMlUaty3Ru8RsjHMVU+6QHbmpdlZciZSV
UxriP4CfffCdqpnb8p0Yn0TRbYrxe2AIrMRBZiI1TlHFuMiiuw2iuzVJ/tYE
bR1IP2A802QlvQ1rWjE8zZDqoLwKntSixuvYUAly08S4DFmgzFUzSKA+ktuz
O6fGjdyKU9vIqFH8IMaE3cCrrZKXW9CVWxGUqihGw6VpKlItuNwMUcoj/Q6Q
5dKu9QC2mSKtZfweVXGTCuDQucogGB5sCepQ3UALKd2PFN4gNyDCywrM9sIF
6XZ244IeGLCUAQJ3A0qX9VFE3QClurIBKB/sApQOi2OzG3c6XQ578+AWUHQr
vmYFmNawN5iMsbGq9dL+sqTVJW1JKWonT5Rpe4N3q1NvK50VSS51KFKzSzaa
kv2E00Uoh3uVQoaSpFgK87h4bzLXuEk3vJUkHZpjsLkLMxwZ6IDhC6nJqELY
maUHWKR9UE/VzN20NoiQyuSzjPPuoqyB9m7Q1dg92k2Yu2WaSEu0OwXjRnbS
NZgI8n+/pqEUC74HPYOzd7dRM1jKtZKWQbVZ3sW9EAjdzqcgEJVb/mlpQ8V+
35E4rE5iF7rgbnsFWdhAETBRcaMs7Nr04KTapFDKEITSTVEogxrLvyQxF+rl
f6mci8Ytm3MhchCLTvdPshnaG9DSQ6E5bhw8CYV1B78rfahxQ1A+ZjaRWcmF
J4mIriYhncbxt25pRBEZKnuMdFBYiYC3gtvt0SoFljsM1UM8Yg01O+GROqzK
sYElCHL5sqRSroSWk1M6kfKSjFrOn2PqTDtuzQWJiwAD+yB4qpm7iIuVxMcI
jRSRyRFptuFACorWjxuZeuUcemC1u5LjcKNI6tPJfOC0Y4kg61B66RzebilI
dlAXV8kvrPTu5Jcb2Yn8qhQo/07iW5GGpYL0Gu7ofoBqtf0ScHkPCF5uArDq
Fm8CM/vZSnDbD/MgGRIHDvfCQOh2PgUDUQG0n1603IV5KE/gXlkHtedr2Id2
BfsgmYYVXbBO9LGOqnOoFDrDe0TaKUFC6cESKdYu/5xKxCH7rH59ZGVHETVS
/5Kx10nciH/mmgVAMRULfGSWsOt9SHK7QgF0hWWWM+UVIda0LDNQWgWLCjkw
NxdjlfaciHN7P8S5vQVx3uhBcAN5Nhmr8HyICqqp8izkGMZR6K2UVHNNFo0y
yba0HqznW98RnJ1KnTFu90bC7C6DJs18eZU4t/dBnNv7Ic6shPp3k+fb2OBv
JtBiE1itUsv14GU/uy2Y3aJngrcSZV4Pd/cg3rf3RJ3b+6HOwl6LW1rBK2H4
v4ENvAKqt7OAr05wS/t3RY+V4LIGaBTUOI7B35tMfUiYj9El85V0yVQ5nq1s
frFTy1BXneLAp5LbeN2kMscYfCqJSPWiqf7WaiE3KelLs3uiCo+VK6JSCQ3p
BYyBap4MPVxaGeic5KrnlEGAfFO0tliV4R2qCGtT3ZmdWEqp8zI7a55yc6GY
1Irq5cq3lbIJcDVR9GN5nyRzKg3+HueH+VipMJzcY3JRw6EWCfnXWrW/dWFW
TxWcI/u/noxT/F1mpOfshSZTmcmzoL3VSV8vXeEp4lMO2aoHiZV0MO6/OFc1
rX/99WySDShtvMn0zCkvPM2sfXSSKqis0pwdgWzbxEMt5yMOw3qeA2bC3AbG
Tbgc9rca8CeTJOh6MIWsRlaQXQyf17huTfZaeka3J1PXMlLkW5lE4wWn0Ll1
9q56jdEhHEEkfCbZ7OPHugIA7dbTp+aObfhZvW5fsdwv7cuOfci+gZQ0G69c
pgD1BgelN5holR/RTSIdcwaVfGiYnFwVna2MrkwV10wIRZHKEZSuG+bMvoEb
8C3V7+QEFCbJDqbToOyb6nwa51B23Rgk6BNiO8fL2kDK101V2SkXJ6zrjBeo
wDsQsj6Q6lAVB7GcB7BV7Rwt6UlqiuYAQaZEG5NLHUEikxFKi/CsNIHicjrI
JuU8gq8dSCOjn33B1IhR2Tx+/RXI53KOVTspu4mVIRwr62Y5p5O/NHgCRcBL
VaUTDdpDznigsI5VU6WwCgW51VYKzCfCRbTt8i5eNjeIC+dLec5U9ZhSbhZy
/1VhIFQZ3e2CMmpgGIvx/lFeiVyLJuPQ0YlEN1NdiZWNk5NLjhYW82U+z0zY
uO7gaF1JAwUs8NY1CNEnlqaYoh8sHC4jD4i4vbYKhcDgGr6egYQtYIE4Yp4f
wDyqduZFGVnPKZdUH3WT2436pmNXNEsjxZOF2E4N122jOpqvFNvuzqXUvhYf
uQM0z2aTkcoTH3PyLt0dhdOk0hHKcbgpl0/xLEuFRfyzlRfTmX7OSOc1O5LD
ip6wyFjzoDQTpOx6U02gBm/v5FIaAaz0+bLOHDZWbkojbtXgqsW73DAdQ4xj
L4+KHRVlOyrXjxmg4Qni2chJTuOcp1Kn3uZOXc2A6tzaTyvRUslUQnUnuCKj
AeBZNmPSRH+tpMnRqXgmyVk8sSZRPTApS+KwtPrJwNhA5TtYE25qjw4fWHFo
5LLeur6h6/ZQrpKxygM8sfj2R7VaDWVgWxmDTIc6lSgbrZRMohutgxU1sd4P
9/KKMFGzRV/3yTVibmm/q24q+d25pTJ4YpLWliP8wMQ1Y6VKSpmUcmFwQKoB
vQxWQ1W5C29RlUqXpeIUgwflpJ4yYJ/8aCjDnElSRFnGMtsF2MA4FYCgGkWS
c6Fkzszgq1yRFa/YZXRk3ksMRXISYZk6o55G/64PTE3VlMai18Y/Ge4r1WrD
p6wS8yV7yXoqoCqmioq6oRaclFSWL61GzBwKoHJdei1yTfYPYMBv7AzkMi+I
Ra6sJJ6xygjM4cq4EJ6mTtJ3NkcVBROAQXKJ+bWYESnpUhXdHEspqm4akulN
yBeZy01J31tOConrVSxNigsOf1Ml5IE18ZQa2iCfhXPO1Zpw/8wKktCHNu+k
MFjNk5jCdR3X2QVMZvCz7NrmCH9bTudGGT6SwWvSB4tLzEm+pMYRnYojVfL5
AQ/NyjeGrSgJtu44ncnV0QX73AxrzDNw9TomlBw7j62qoFDpLqbt2LEpu6lZ
ZSklEiiA4H2W8M5jHVV8EJjQATBkw3PJdykf7CHGuUujOwa6UnaUWNdWH1rp
7U3SGsqp4yWYK0PVQ4NpnCVqv9Z6C1hxu8q64clKyDY4UNl3wC6yqhcGhKtA
0QO5+VbMvYq1V0lmObEelUiUB0NWgjS1k0xZVtshNKNUU8j5OIkH2NzvSpNP
VlDko5r9xMrtdSo2fWsj/mXl4RMHY1dnmK0xsDVIoVgSuiuS0m5Q8FU8zElu
y+GVjsG3VOWkqhkgTLdXyXHHa4PBKh6pSCctSY3MKo1Z6SVa4DeuVbQGw5PG
c0qTQ7odYvVRsJPaHsDObj5P7fg5yyoyEFZj1xOiGEphogNSsF3ZKJywQb6c
LyRkcnAGp45Nm9AEATXntlhBp6X+DlSWS1f7R6RKp+9lPQuqf1ZTKZpUI5xE
FCNAY0I9sCxSblIkDEVZ9PtfwrtwxiTSXi/WqOJwH7BO7SAx3ZtpqcReJhsk
0Th17FkpMJk4DDhiSolVyzkrY81H2JpGyi4JJJQ0Y5zmm9IDEXLUCbo9STkN
e13KQyaxt1apGp0GwVidOyPUR2harTVVN6jkzzljglUaRWdIsNDTJsR0J5R0
W72/kLjpHg9z6SwfK8ZJud3hkv0Z/ZHx4jOdSuMEUPgbjgO41gEp7rnn/q9N
Yg1hVde1y7KprJ/EfXhrNp1UJvGZnajMUqXiXd16rnQwXpkgmjwV2NT6+Jly
CBqyDJ5hZy0CJ+kxZ1JdOXqULa0oZ5ljDsTiwugsm00wmErnyDe1DSt4MU8x
40r1VI6jk656lPllxuldmOeJubYq8+DmFEtEzVWMUAtO2edej+05cfK2D5nN
OCFjUVduBTqkTS2gbFb2pOol3T6dg4qtlSkccLa8n0XmSc1LXLCJQubILMrr
xvkL7VL251SmJ6eszDpBiKeqOI0ymkidcxBbxfcqU/2ZUAF8H1ZM1XcWpWRy
xKjPs8VCJjBco3ewVCqe9lYx8YcV2f61llZLuoS9HAX8CgqrrcQVb2Y51r9P
3gE3vPxtWeur1RBOspNnCwufUxmvzE7cvJSWrYLydMqskrZem7OrY52KDImN
jts2mMW4+FrEXKXKfVRYTzLf/QHNh1jsBTYT41m9VTWMtrXZRreFKgWDSE+K
FZJ+vdZuy4or5pSn5viSUCuLJKTMoqBpDcQZEJZS1PPjKVwhqmgiqXu2H1Bi
RFe1FPp4WdiqyfoexzCzAjBo0Lae2BPlu4EhNnGfDoCtFi6saOneWOJSiNMK
Z/zyo0keVArZvi1NLYfdWb7u2m7VUGC7Qst8WSvVMwmPiBPkNeWCLBJZlexu
5V2vrcTd3bgPa1tYxROVr5cW89lFltIJOOa81M9IpepgDTakLWcYQ52rIt8y
uQNhiaJQWa1NqnE7PlpqaQ1VqnsqIwSrl3UVp5zfWk4Vx3iW6mI4tobhxGCx
4n06B4EchRw5CIBK2bVUeKB5fbMm2XQNb9Ut2qADzQewyJnki9LZBchQo1KK
JUtjwkBO27/WvlrF9JbjT//bsL8rnlurHd/KZ9l+rey3ctMwTdHy9dhlNYD3
Tnz6Ct18no0uTaSkWySbkDvG52oLsx21kYGYCZSQGag8KZFJjtywdEraBlWX
2km5KVR5RjKWyJVQURK3K2xdRd6AlJfqPAHSGUbbab0VU74Fg4b8mGtV0HYr
MLs1fG0CAodQmRDLFVf9TdoboFGO+9OK45Ous0cKa9TwOwn0C5WWnAk9k3ll
KudYbNR3SjZAFd7GEpaGt5T5MxparFHaeJ10ww351ryLiXrSdTF1o1xPaLQS
AGuV4KAqWjQ6he5IZYCN6XIWxPQoPrckGThacvnIIps75kipOFSZrphSyIrv
im1XjJRMMmTljy10zkVbAV54JbXDYLmQRFunixxlZIbMpKsGqX9mC0UpVrJ2
cN1IlmrcklvWeskpVojChszjFAAUPWwKHeJN7BUrNEoOMRVMnr1sK6jJwqTS
cCajEh5IT8zNvtce1+OraqZsqlun0V2j7L21JncAoPxePLTqISQmZ/TDuylz
t1Y635ElvYkK7QEPVTVl/PSdpm5iuytx2jr2WIZrMIZDTvhWTLJMWGefNysJ
pnzZ1updAq2V1ZaMQxKhSp0o3jOlVJ0D7+SRRFVHpcIIq0KVvcrWidyWE/Om
hV3/9iojXfFqedW/dyp5uFK3XfjA8MBSJ68wufJJM/kXXNZactEzr3r5WHGr
KsudzTKq44Co8xbsLxceliY4ImFUnSSRkKRDWsgBhiqjrvjxVaC68kP/bbjZ
W4ihO3Ge7O+/2qh0B1+IhzCRI/H7M7Yw41+/f/2Qox4qO1Fo1S0X4wACVzt/
uIoOGBR1nLfQuugTJMBvrBPnA9hianHvWOUGLJFKWzVnpSK0aYuh71ZYMh9r
r/JYV/h9rkpGtZXsAzdj3w2NrB7w6haqpYMNqVQquHkyW6FW97dsIPXcqD3T
+iJLyWXWjvhIzyKi6sTWtJs4m9MX0vUpnZVqMRWYWf2ZU4wFlWCes6Mrulad
0VFqao0Is26orlRRvX2WZgse+DSKraiauFaF9u7J1rshBkNUZfu46Zy+ZBkA
TykA2KuVkyjzsBsCteHoqfPtHryS9/TaYxetIagVi7mhiepDV6mdWg1KQZgr
B6XotBEx2jtNLSgyg5v6hyslf0yaQVmEyKit3idiOXdFCD5pXFZKtW7HBLjp
+ktZV1UAhUo9lHJGL7QXG0U1O3oV2lGUvJFHVLXhg/Rbx4iuJR/S1OqyKjzC
GZtye5VtKgv+32SpI2o+pR7QwSodG/1+rDNe0PDIrUWOC3kKUtuLtz+c3K4N
ZwDaol9DqHyvXYx02NqBqe07QUP/JZoIEkEOZEKWxixwHsdWFRHzusSytJvS
278iybwekmbNuAyk1umx8ZHbGizTyYj4tbHxpNBKRjxL1eEkN4bjHWCx8ao3
4Sjo+u218QAdtObi0YpvzIbX7ZP0w3JBvn4ZlY5TZ2e8XI3Oji+A5Scdb2Zq
KMpoKuJYYfMox6FOgr/IpKUPIwR+w0NAy0fxYWTysyu42c4ctCWjdERrycFM
yWSsqpTImCg04FLV4QJQCTsAYppOrnyONdFmXqzLp6NSYzk94DTvU95JWUhV
depMVxVZLwAAlF7bPVAc5SZPqCcLnctsygkMoS7YMMocGHHtMAmm2VLF/euv
sNkN2u1Hj+SjpCjCnKSA3GQCGQ18ReaZ8SvbP60w7zo5/khURkFO1j2rpLN1
VZb+ZsPnkus7yygmDGqr1eRTN5e91+i9NsqY2hYJMJE68lZqN7Q+X0qoLlmw
3xX4/hr2G9HzHB9YQ3N5hm6FcTU9cSSp/wwOd2t9I5s+R0SxsAGfGtg4DKkY
pmwfMC29zBxxaZ9FdAc6AYh4Q+G4L3ijj8pRk9dWpfOSFTyex4N0ApJZUlHP
js5onkwppoe9CTLJ650nU09X5GM+j2JJAJ6f52kynlya+JVkBjIpHgMVwfIC
zRil4yJvUaklXasQ8QztgOVXJR8kAm6eYq9hLqNNRW6kctOcUPne3wi9SIrt
lH1E5SwcokS969TkHqlIR1XtThdAzhgdEjVkx3xrvuwDhvAsHZzLZZBspy80
OzH2A2LQoCorJDAjwkJCe44r8faHv718zq9xz6ZyccFxKHz6ZVn6glDDOF5O
FmqkbIksqQ+IF1gt+8aIg6psy7d1RUCrlDR3TipetmzJ9SzQZvZO4XZj8Rsk
6ImN1ap1rQLkH/KZx1ptWShHtrucwVpQOUCESPaFx0BXzFw1nyTWxuhLjOOl
U6K01bO64fVYOOWT2c9DzoSZslPYhsG333zrOoNozQqWGAQik0jOrsCSS0rf
jJF2NFIi47yMFhrlCyijMF7Bg02D+Jo9J0D2YqRHFx9+o1ScteEkp5NSgUdt
1MvRHMjlNFSUMXckO3TTPTI+ta9wOlzkdVR8A+FW/w7o7kjGWDcoWuLRaoDE
HZqSQS0N2SSOOM5JcBJfnH6jczmTWMfpztTaObMqM7JlhbOl4b4F2bJfVDzV
ykrSXalmeYvco8qe5iqtawihDZAuJDzUNMXRkHHELiSIPY7keb/18o0ZhxRA
v5ZzJKmjVRvwupdv2saV2a5QLpdDONCuF5JyfZcMlmdnKgbgpwUSoUstkRWc
DMgpA6WUFKxtm1wqW9i6CnNaapOayzyRaQNk/aj8UroTo/v8DEMd5nkGmzwt
mqfjLFvgIb865nIqsJXYYzxClgrrwaBb0a+/joHUgTB2iZHrqTLX6DBTRGRN
Cs/Cm9CAhQrocbiko8EpQ8Y0nhP0ffGoNomng1Esau/FxYGt7Ps9Fk+eit/j
3796KPDeQTWUcioP7KXMy5mBWsiGeq/uxCAkfTjMpWrGropFEcyioMiAteBY
CLAZEyRj8zQZSnWUZkG017Tl3CnDVjGqtooJIZBQhQiluEuFn2BJvsGlePx4
mM0vcyxb/fQp/Jqkw2RWJPS3DMpujCgI/PHjUk4XuobzpenSLxIZG1oBQNcY
CI02oqHjeum2FrRY01p6mTHwxzSblm4otZBcPh5fVSoaOS4SDhmX05VV0kCX
Tb0pqx6QWw/FqQ5g5aJ384U7WZCtfL9u0lgndaSVltDNDOfksLLyI7kZalbz
MmyQn8vyjUWj7UPqHhzvW+GhnR/kxznABXK1wM6kGRWPvLwCtIX+LNfu5WJx
OUmu5hNA/BhsgVyhCpy69v7w+fO/7cNgdJgn6L3TXHxc3EMfLfh0ogi//W67
ZX/jp9sKW3/wWx2/3QnDVrv7h5YfRkH0B9G6h7GsfJZ4UIX4w/Ayns83PHfT
/f+hH4wWFI1cND6IxnORTUaH8eQsGeTxIchQA8RAzWIek+ml+o7nd8O6342G
8O09JpZqtJxOL8WTJ/hS7eDL45fi6Ei8kjez+RjEDGDUnkg+J8trD/FSBmRm
8vDo6JgyeBx8+YIiCH+QzxReo9Hwnm5of6fGo26rHnX9YdQJ5DiBt36XYyOL
y1o2HwGqBJJ+/O7li9fP3nz3+tWruhhd0NVva7U3KGzAleOXB42nrw5QCiZ/
9bfZDBiUqvZAJKvDRd3e8TtoDy5+K9sSjafih3JDZgX2Nrg9jWw9FM1i+GsV
hMxlz29F7Tr80xniX3K18HMB/L/4qzjG3QT+sjae1S/ygy//muB2an47qP1Y
Pz6wXsvj2XuAimc/iif672PkCgHHsaq6qF0UeNFa0Lv2t0Vn69cIc1WvLpG+
6vk9OGE9OGE9dcJ+BIYSh/lX8UYcy2uNhvTBZM8w1n2hiCL5QvsEOe/f7uUo
CutRFA2jyLcWe5gl+TB5lyfpFJ96Tf+Kn2Hu9GedLv8iXwCp85iyesmq1MgX
lfbgdu2tbSyKejDIPgyyve0ghRinH5PROwyWAelGzMUBohqOmidpHp0F1f35
1uO/az/rwSenSOj5KgTZNzzfr/vB0Lc3j29nGCZf+4gKk7q45C9AAe9xONbD
+PmCnhL/74n4gh4EQC/N/+Ymb2rPB2QAqCAqdY0fdsd5+CHHGHOZVCEbc1xT
8bD0wiKZzi+S4ZGQaAug/WdflhoF0ctvNmvTP73/k3/wS2kKt+tty66Cdj1s
DYOwHrQrJlj6cH5J2QK9f1B6CVCM7JWxFHc+W04mFMdQq1EmJ8qGAAJynn7E
IFpc6QPxj5v7dz5HR3/hFl6VBwEn8QsYyO9PfDqEUltbe/i3mOpoHonlLF5g
ei1SofL6/fHhbQdwdMRmu1cg4x98yX+/Y6S0uhg4Nbkg9M+7bHI5y6YYBUwr
8481e136VCx8qaPtV/3Gzkuz16tuX956yW/V+4YlLy3DzesdBvUwHAbdtZv9
cw3aafoHzVr6p+mfgoNvah8/Hh3ZDR18801qTlOr2Xz/yy9iZe9HS1z5f/zp
oC7HBW0eVl0ODjYCwZbj2X4wpxjaoIPIF7ancAXSZwR7OMiy9xfZpN2k0FFE
+lU3FNJvwWqhEu0CJJ3/+pJlvZ9mo+y/OCfrQkbRf0DTBzEB7KCPie+WM4xT
xXqcDw+sVr5E3e9xkl8k+evxSb5MUPmm2lnklybqlL1QZsBl4sMP1eLvYTh7
GMva9R2hkre4LFbW17nhBREg8mGAxIqDg0gn/0+xSKcJ9Dqdi9oSOjs6ghnM
48W5eHhY5MNDffsh+i5cJnH+IUnQh/mxfP8bcrVoSPPbN+IhdWsWbw993dDR
v1su/fz5NB+p/+GsPA1yZ23wteYo25My6Ab9T9ANI9L/dODvVuj/oeW3u77/
Wf/zKT6jlPS+Mi3TPwgA/qEsEFfeAxRqR2n+5OT5f3gPivRfyZOHnWa73nuI
t0AgfuI3e96DGZo2fy7O43kCgvAoWwLbMUzz4ST55T/EcSGOZ+J4OPiP8oPq
Ee8BPPPzJB4kkycPj4vTGWfrO3gobzWeipdAEn8W9Ai8+PDl+KEwN4+HwHtY
d4+HQ+d2Yd98O3HuzZx76r3ZhvdmG97DgVQM6O2i/EB10+ruDY3PSm2rxRjO
qu4Py3cTd62SmfvAmqHBa6XXn9C8Snetm6V7hXWrotWF06yZUrKoeqIo3X95
Vt2zfHlQ1fdg9Z56cbA6m4l7Kze34Ie8l69vMV95zSxeXtWbcN+blZZH3p1V
3NYbru5WjqcMK9YUTaslUMkT/URS2XHpbnXjyUrrzmLo++PqKY83TGq8vl85
pyR1ppSoV+G6vu+cW/f2wL5bvjmzb05WGl64LY/1AwvriVUIl/erIVy9vHq4
bmeu20D/58WeaMxm+t9tR+2gTP/b7c/2n0/y+eqP744bz0bZIGkEzZb31Vcv
0PE4y4/E98gXXKT/0k6AQdMPRO3kfCleJQMRBMIPj9qto7Avfjp5IQLYyQN4
/xW+W6PVOhDw+yRdTJKjSv4C7r5D/Sg8H6MxAV9/jj7eIKs9zz7al1/ORmiy
QX26V8QX+OpzdNF8l2eT7Mw7/C5bfJcOFzgKMcI/QDb01EVy5vS8Q0rp/gZD
KXxgbdCBwTt8ORtm2J/U5ATtjvTIxAZE6W7L814f/8AtqFuiBS+1xVmyIAnx
Ip5gQln1t1dqIWqLw/PLOeps0CPK+0ocA4lazgW0K6hhOz5FJPJtGDtAKVAz
fOxKezCN4EX8D9P3jLPZgn7I4JKRmbl6/ArLX81GyUdx+Or1dwIZPJymuL4S
82xO/12LdJxMCuNudY2ajnhiUtDpFSsvzsgKapLZYGkMiUpOn+AQvWt68PAE
xdLGj9lU5l6Xc7PuvV7Ek3S45uZzkNU33Frz7p+TyQXs0zBef6fxw2CS/nOZ
bHiism/39rpGXmTLnPKcVl9f27m6X9m1fXNNA5R+ZZERyF+LQcpb4qlT9GPC
Lv5HlDcTjok4U4e/BUB/OMyyfNTA7WuM42k6uRTO/tEopK/uDU9RSwSqq21q
KO6hy+skYYjGYR6+nl0c46VXZMoVfrPFzcFQ/0HPmkOBR8DHoGE8Ahei/Crf
MKBKb7trIsgHpoDWM0xvcyV+/oWc5xcjdCGzHj3ECwk90RelfqbLCQ1l7auU
oQ1f9ate7VRcXNdUOrtIC3EFNHwyEVfk7bM4p2MmAG3k2ftk5SrW27nC825f
t9scIKBdiQA7RMXkh3S0cHvF3mgC9sXlrPJyjkh95Sp6L6LrcOFehw04zzKd
ZISrYQwBzefCO0T5kf++wnvnxYB/2e1iHaWbniH4vumhWTaXjyj0CP/ZIz0k
/IrOVeLqwVciFb8J+lV4Dw75DwNvDw5/s3+k9g/YJeG3VOZluiZf98XZAsXw
B2dE9R5gOV51gtD7FzEqXIRTSubCRYa/aqe1A0F7nGKbYnhR8M9aXV7/rXT9
9IBvYEfo/Y6VpB4gLXBOBh036hpGpE8rzsN7YE6sGta12s1RHn8QgI8pmSAz
wEDmBpLQwx8f9V2M0tCJxIGGeofyDiXIvoK5fSUYFOPRbwIvwurRPWs18Zb1
k583F9RK8vWWWuAHC04jiVvAt3DDsS08jy2R6/WldXnwwMYKnnqd1lAv4bUC
k+zjPE+nNAGYwcdhBsg5F5fy+yPqVcQl/gsNRXDqgKuZwJ+6y0Cg2yf8QdOA
weCZpDstnpm5wKf6zHloOMkK0gm725lMJum8SP5B2mJYg8P80l64/KP9y7ll
31EmLt43/gXwy4jFe/BRXJp6Mt4DaDS/lFiXwNaH/8JOC7iuIUBRohpwBzob
8SGjBaY/7XOqLyIe4Tcm8WWS0+Etkn96D36GVadLEpHocKmGGKEfa0FRgRN0
q02wmO6Dn3ForV/wr2Ygmj34P/+I7B8d+0dP//jFswYB7JhwRqMZNHWkeGBX
h9P4I/+p1lYcwqK6l7wHblv6AR9DBIXucZqNkCX1HsQYgEqgbGE5RE8GkSo0
dy0318Kf5Vs22nTvOfuVzeSczPiQ2SRChadHb5N8sCDom14u53NnrnBpkn1w
LukG1a3JwrnITZzBRZym6VKfRf1sS7FAIFsoBoh/SaFCMkfHKDV4fqSikRye
RWFED4PjFuQwTX7TgPYOQY7Aqn602T73pq4ygmkrDGmCdOejMTJpHC2dTyeY
+QTpIAhpbIBCtytYr8xkmf0Oo62A6ObeoXqbk8xcEbW6QqMQMeL69qHFDgqG
j+VCc/5yOI8eP35EHkCPnj59JIp4TLGw746lO7wPY79IsU4wgPnsbAnHjytr
mr6Fc+P6ytddBLBrkmPTo6s9fnwAFGkmaj/ztxpY6bGnT9c8RrvMG8hbZol7
UtI8gmGrvx1BM+zg/6N+W3T8QD7wA4ZILMj//ki8y3JAYrCvTD2c54VC70NA
p4qj8hi3aQbBazXbYSvsdYX+wzCvgKszSp7Y9Zu9blt9GbTZarZAsOV/ffrX
nERP9igaEf5f0gz4y2/1AiFpQK8TrPyGR+QvTR/Q6jzx7BFq5u/TjYF5VhSN
C7ncNw+I/9VIzUM53m+FfRFGzX7U6elvh+bJnnZpvieb721qfn1DfgQXXDlJ
oxTuJArkcgo/bAZBF9YMxitqx8WBsJijHXsJ2qqXMGxGQaB6OWVLDPKHdmea
w8FNajy980ZpEqMBJ4CX/FYnVLATtnz83RahH8If7a78A9YcMDg/QhcCOIot
nILfE0EfG/Hb+pG1O1AxAH7Xb6qV8HhI0JqEUPlEr9m+07khKfITDOEWc90E
B6Hfx+UNLWjr9zW0vZ2sB4DZ1qfUB9jrAWUN/Ga30+no7/0cUt16W7be3tT6
dqeH+mj19KJFzW4PIFIe0dnmU3PXhauAGAB62DQt/Pl0mAFewp7oA6aFv/pR
Tx+HlugHXRAv+nhy2qLXD8xh6oleOxQwiF4I7wW+6AXhNufIDwJAINBM0AF0
1dEjC7HFlgJbP2g1Ix/3p99sQ2f3c6D2NJYdTxasY9+PNIh0mmHg63M1XAsi
L7Px1gcL8GY/QMV0E33q8bvT2jPkYxdmVrCEgR+qWcHQN0L+3adWBfp9xv5q
U/tIDWAb/TbiSCQfQZ8OgQJiH4aLGA1uin4b4B1uR51tYLwPKBre7Edhs93X
I4Cu+kCeNHeD9wI8f/Tw/UD4XkayI3z7iGw6PZtNsUBhAyQMi8X2DF4UMYh3
mz045vp7rwwY9mHBeNgMwyBSyH2I/ryb0Pvdp1cB5VGfgVkxBIDN+32gaVEX
YLsnvw2MBwgMXbwP30jz4PQjrG/DECG40Mu6b6YmiheJfHn/nrih7fvfFWED
BrEAmnAbEFq17+tR9vFsL7yw3wH6FBmiDvvY6wBS68KwgHL4sP82VQ9aAe81
4rce7D0w8z62vM2mA8UkDBk0DcyFyIq3zMLjWQMo7Db797X1u45iVwBACmGR
7Nuzwnvh6nyQ/ZELU/sP57wXdsm23YNVoG8Yndl/+N1iuOj2Ye97bfiOtmLe
elHTB8La7beAY+jqEaBOoq8pB3TQjIB37MLiR917Y972M5adQaHnMPi35d6O
h4PtuTegaxHAG3CtiArk136EItV22KJG5ddeGUPsodOxsKd1eGBZNi0ZUs27
rtsq5HSiUCBMSIjptFFV1xEdQOkRMH303TU0k353WnA9EBHIQB34L2r725yf
TjsAWIVmoi6IEmYEOKC2VnxBB82g34dLUTPq3Rf93NNYdjw/nW7HhoY7nJ/t
1QpRp8+C/y3Oz3YwTj20eutgfIPczzC+O43otPEca0VRB/B+1PNFF5e7j9MP
RbttaEAPWJoOCvX43QU5v9UR3dAIP104A13gI9tAO3qtSLRb8O1vdQbarYjg
rtdy4A6V5cChKwCDDgjuYJ/u8QzsaSw7noEeIJOOo8e9JTsxzLc/AwCdIcjo
AY6LBIFmu7VnBTX10e7refWanXbX8Mn5TafgrrOr2N8+IjM1Aq8NkB2BxIRS
bgTQ3Q7gd2BOQQRcUdQCZIeUD18NUXO/FZRHYb8ZRdBMt9sE3kNDVtCHS5o7
gUE0UYMf9mDP/ftSAuxpLDtCeTsEFOS3toGGYrEfG0IbNTra/BSgzqON+J/F
xKDTJTlJ882AxElWxu9eCN8oT2wFDUEHjhcglD7wql1LWu9IVZSSWbo+MKnU
SzPs35vgvKfB7Mo5w9K6aqHbYj0Chz0oxwOQm/tGfQBL0uuxmNQDSPF7IDZF
wXZiEsinIJr04OAFgW9EEyCsobZo+t1OE+GvF4VNlNvuS0zay1h23Wxc3E5r
CzaPNnsvqjI85qGmBQGCNvC6QR9keZSe8TswShH6DQQs6AGYwqkIgJnqb6k0
6Uouo9+xuQwakH3emMvot8J75Hj2NJZdjYmuAsXVoL1d3AwPezj9iNU1i+6F
QJl6MNOwj0ywT+xBL+hvR/q7zaCHxwtOnta5RxHwlEHbUFvgJSO80ux1wnsj
/HsYya5bDfyTdfKBz+x1tZIco5w2iXh7IftRJ7LVpRGIOD0Ug9AsgfxOv+eo
yEM2AXVEGKKeNEAlCDqqbAcMYStoItuJLhTNrua9gj42GWoRA7potnt8rRnd
1+Hf12B2BImoHW2nPiWA2MPZj0hjqpFfGxAfKlDbfkgKVPq2FKj0G3Bmu9Ul
BWoEELOlAjXqd6uUljggS2kJHXwCBeqexrKrWIBah60UqLNka+m3C4e522qj
erPVBuQH3xhSuFfpF/vo9LX0G3RdKxEm17sBzu86v6otDkldowA9RC1OW3QA
2LvA+3SA2HWD7TSZ/bCJjiTdAE5vR/eA8kTX72rtYR9dJ9BhEYCnczd/wjto
Mvczll01mXiU2p11+51sUvol6dagjGI1gjKau9pwToNeM2yDKLdPUMY+bFCO
mkBBjKE7SW8C5TvPrwpnM/LVKroIQBlwNm5yt8+4uduycDagrA7icrgO/Byi
mW60ncIS50snBqin5qLawEF1Dc2Efpog0HZByrJgbt/qyn2MZGd8HTpg7hq/
k80Iey/8XBe31vi0dVuhQWaovga53YEEoGWo1ka1dx8QILpyOfwePE/m8DBU
znHM723lJmqxWP4KixX0VlksOK+fgt/baTC7gkyv7wj/d+D3kv0wfF00ZwTG
GoIsTtgni1633WN66IAMWspboh21JOPXJh5lS2sHMlk9sjQYJossDNrFEC0M
yGT1fP8eGb49jWVXOommpPZWFr9kT2xRtx3Y4NDtIO8A1BuOSDcI+Ltljj/+
Bh4DrvuAXQCSAGw6va34fyBJpH4BJGWrX3BAnZ4WyaEDUr90et17VAXtaSw7
ggMScZu3uIMqCAayvQQAlKCN+p6g2WvB3oZhM2x19iwBUB/arhf6LtsEw78F
sO+u+OyCSNsxpmBkFQjxhUAzIzTzRoAAt9Jzd0OGiU7IMKJ7AHYx0AxJN2T4
6oQMb/cEzfsZy67QHLVtU+7dtF3JYj/+LV0g7W3DH4JYJFDI7QLjA00CagO2
2dJ0d/psz0cYQba600Y/mK0cnzvtPjKmUS8gXaJ2KenjJeNS0iHONOr1USt5
X94texjJrsCACx9sY9eXoLCX0w+z7/iGW0Za5gMtQ0cn5IrgG/GgpnX4G13o
0Nmjg2wRzKGzFTDwq0HTorPcljqLdL9/b+FSO/S/68aDyGEhfr/dbLcNi1Os
D+k4296pCZg75RQI/Aw5vAed1n4dOqgPy3UP1rato5lg8DdB9N3nV8XKA3Lr
mhMNNLuN8n0PNhPWuB3Scd6KVQ975CYR9dq2m0Q7QHSo9UXtsE1uElHfv0eX
jT2NZVdWHdq2EdjtWfV8P5QMnXPCntbooVEuhNVAA0LkI7y7/jttaATNOm0f
vwOS3yLLhI8q3ghYHjj15OOIQIPmoG2Apeej1SzqtEgjo/YH5CZ0HlL704vI
/ha1Q1TJ3BOo7GMku1p0epHj23NHQNmDRQc6D3ua6yPgQH8jAA7CCAA4yAVq
Ry/UF6ENsN0mRUCE/HB3KwE/avdImIbXm72e9q9ADXPXiEtRp03CNJDfZrt1
XxLdnsayKzAg1uht5c64H6+/CGO+e8abk7z4EGu0yJuPvjtGvKffhBkA2UQM
LOF2gX8Ac6RhCaPA0bDggIxiDT3tUMMSRv37NO/tZyy7AkOnZfuA3kW8z7dn
htB5M0CXvl6z30amCCbXhi3fJzPEfRhRr13yZ9zEDTGg7wHtoQ0zMge9FYoQ
WYSWL0IfXRv6MPXt0ForaNIMpZFYuckA9Q0MKgn7wNoG1AlB0T1B8n7Gsisk
44JaPv13Ee3z2Z74IYxa6GqnJSRfIUr1SP/hhXbfJyy2FT8Dq8bsUTOyLMYA
PRjrotiIfkh3gTWlp++Lo9nLWHa1WkQO5roLT7MnN5Ww16a8Jwree+iKFKAb
N5xy/MbD33Icl8IOXgcsAKI73e9b93sIKW3ik9pID4HxsWM8EHK6GDYC/3U7
XWaOtvR+b/tkg0Tf015owJWcTTTpAW6FrJlddE+/N5ZoDyPZ1QWuv60eiCFp
H4TCbzuII0DaiLFfLXJspW8rDJx+U5AE4BvkjwN4PdxKUAIWnDStQRg6ITY4
oNCwIQE7nAZR6x4tHnsay878cc9mHO6EWLZ3eQqDUPjo7hg2e+1WX3/vlSXC
PkKtHwp9m0TS8G8B67ub90LgYwPj6Y04MQgRmQMLEbSIxw98Cy/CqmCMfAgg
4JMpiGOkt7H+hz1KJOP3wqalpAoxZU5X6xlDWBj0R8HY5HbvvjDfnsayK+7D
SIp+p5prwoIRm8F9T4QUo987xvUfs2ahqxRcwmQI9G1hP/xNLlWlb+c+aqa6
aDOO2Fe8tVVogHK+boW28oY8tFuRkdHYjbvb79yfGmkvI9k5JKjtBAPfhVAm
e6KUKBv7HW0zCDFjFjFUiBRCwi2+5fuLTBYhD4AFkGxJ7xAEW8FC2O3hogaB
b7MqyLUFgc5hATwh7U/g9+6PadrLSHaOG+jYiONuVHJvlATT6xiP0rAD9E1y
1j4qNvA7ChxgwKxSYadHKdII+W0JDPgqTNoAYsRtqdWnpsN7M57t0P/OG9+2
mYg7aYy2z4iGrAsyxd1mr4V/yu99c0dGCsBsUX7PooSb9QcM0runRSMWzQp7
wuRzEV3ttehrO1tvGCCoaNRN7ba1QSrEzHmic1/Gsm073xVQ0fN6DWdzkz5o
vB99UNgGJGPkGOge/U8CDFylLxs54W+kYuVv5z46Y2F+FqBk9L2dX1CHEEdk
RkZtRcbvghBHFN6XwnCH/ne1mAZby3bjPcU19ruY3VPHdfqijRyKj+kM8csG
CfxNDG7p277fQ11yq0+u1ahX7lrOIqgS7aKhMYgoZOgzI7y3rFJdx556e0Y4
SfeDWVBR2DEKozbmP8IQOdQdopN9q0NW9m2QQwvwcUivNzGdjDqi0Bra79UR
heVv4VOtbrPfuy8uZ09j2VXTXHIXuj3S4N3eHWlghCN6q+mAyIi8RinIBv1L
MPbGyhaELnQYXIPpIdBvPgIyuK35vBuQ/gGN0RiZoY5bN3RM1t0+6TJIQRvc
V3jNnsayq3qw7wTY3Pns7yHWCp1HLf/4Nuk70GjgE5TQt0Um8HcHyAD6DaLn
OPrYbekf3+60q3zScUCWTzp08An84/c0lp2Rg7+tf3ySbu8fH0m/UHJaR4OT
/N5rfijqw0hEgF0B9k1U4Sb3eAXruzvIYvicTel8jAtCZ0KfEgUiLuwEWwlF
SC8CdDyKyMtYI1cgpSYwD36Sh3IHpt++N3fCfYxk58DB7tau8bDPe0oF0bGd
ocktDM28KC6hEwx824gNf/cDvm9/O/c7HbIc9OGMclEKfyvvU8Ah5MuJOcqb
RkAP+ngp0CwmhvShYyhcwxy49wMuexrLzmbTlpMZ4C6EcE/OxkiLkd21IuXa
5G/bJbSBIaVoQ9sKNwRELuB1O1yFPFj7WscakU8LBiD27jF0Zk9j2RU/YFrJ
rZyNGTvshxhAjyAU2KHVHR99SHsCfejaMmpMcz74u4v3fYqWoPXZToMGjCct
K0UsWNyGz3EYCkcHHN2EcQv3yPnsZyw7O+C0t4iikLUAPVX0zwIVKtt1kscp
FkPjSm5c9AvLUOvLsuS0Xy427dYAg2480/DLH17dqpr6/7yPrP+eJ4NlOhmN
smGzON93HwASrW67vab+e6sVhZGp/x75f2j5EVz8XP/9U3y++OPhIJ0dFude
PhXfNOPlR/h3MJjgv5Mz+Hd0kcK/kwz/XmRDb5QtRONkXohGJou6N6ioe4Mh
qQl3qi7Da94s+5AMxHDSgK/GBRzz5iQt5s15PJ2fT5KFh6XuPq7eh4veIB1U
3dv0yoZbMCeshSgaWC19gYXWVx6DR/6Xnnj3I88/rO8sBhzdLBaXe+8Dz3gn
itacf99vWec/7HTg/MO/wefz/yk+Xx0uD4vLw0GSDBKspIyQ4EBDXZwsE/F/
lhOsYepHR37/CAss9fst76uXo3QhBpfibTIpspn4c/NVUzzHlsRjavDb+SRb
dPvNKXALzeUiPm8mo+VToKdf4X/iyT4+e2uJGhLfvolPkr83qAR8A5it5Iqv
wydeLs6zXOjPE/FQT1yomT+s6+cvkrxI4a71vA9il/XECGt+CqdFP4S1niW4
wIH15AIYqPKTvSO/dRSF4i/fnVhP4phx86wn7e20noxHoxzry1pPvkiwyCxV
nD0eYvnTdJwOxYtsOl9iGXb9asXnO+AJ88UUS3dnY/EX2PEEtj0dFpteOs5g
TcW788sCHhTPkQW5oZufZimt6+ISu/kJYGpj+/FkId5gOdsXKYLyTyeiF/lU
4nV9D8fP7IVPJsn8PJup9YRFqvVa/gEqSRsgPtjb+erZ352WnGcjP+pZzw7P
k+H7Yjm1ng1b3T7a7zqUyT/qhB3reVjMdOK2zUfMOVui9ho3EDNP2H1lo2QR
DybWHF4f/3D47PjF69fWY++Tyw9ZPirsLtLBJM2ozisiguTv1uPFcj7P8kUy
Mo9fJoUN3dlQVrTXD5ycpwVBqJjn2UU6SgoQIuLZKM6pdDTyDXBiCtjaTTsE
72KRZ4JpMUuSEYwhneHwGnmCZH+06W1rTimcCSFOzhOn83h5hmC8qQ1ABEWC
fQLGtDDlh/N0eI61m9MZHBiBlZA3tTJO82LR1OhwzefZ7FJM42GeYbnnBbY+
z5OLNFsWk0seN0z/A4qFmyadAKczXojlbHgOFD8Z1UWBDbozxwHXNzWDez5J
cHXqYgAzHGViBvwgCHB5DrtZF8lHrEa9+QjDYSpunPXrmSBMXMfSzzBQBTcx
7A9C1vKmLcrmVLl50yOnqh3C9j8rNPnLVbPZvL7FAN9NYga7uvgN2AgY1sbe
GChsZHxTHwiZGlGM02QyEvEAFhtO9GwBfeNavPjxRcPvbGpFtwBrhztOYCcu
4skSNmycTbCO+gjJONzc1E7yz2UKb0kMjy3ps/vT29d/Fx+GooYIZONYQOJe
HAigJhNC4csFrgk0h8qFAk4QIqA61h3fPKM4j4dYCJ2OLx44PBXZaDnkmfyY
DZJ8I3gcZ5PsIr58VJjlkYNqKhR2vUfWwjtNp9NklAJyOv2Qg3Tkd67UwF1u
66+Sa0BWQTy22YGn1wAs3lf7GBCNicDLQpq4goAWpxKxEraJ84ROuMIz8SRP
4tEloj46njgg8UOenqWzeKI5nsHlEd34McWdGolXyxwoFFxwmQTmKxLJawxR
2eeS97/E+eWEYAGenUySs0S8i/P3dWB5hAha3SigbsbU/LfTdFpcNpfTEVJC
uFwkaTHN/ricDueNYfHHsRwEDni4QAARQVCHle116vJMwEIkcZHQM8/mORBc
nx7oHgkxzUbADDF4/Q2wbQoL9SZ5lQwuAGfiTBNr8B7C3dvsA6zTcLJEMmej
WWSvnqcDWD4EdHH8JiUcwsfzUoCckYBIgtQFDyS0REst3mRDWOOfiiQHqP1+
Cfi2aY+0RUPtHzkjffvnV8+PkNODn4hIYVFP0/FypvYTiAB2C4gLqQo0Dcgl
BoKj8Lg9bu4NpIDjZL5IpriAAJb+kfiL1eF/xvkEOOE8v6S5cf+4EgROPGto
ZRjPkCbBkJB2IQ+ocCkMJqsLplICOdA8Ycy/yGgGpzAiaACQ3wIgkSY0Sz4M
s+kU+pNDtA6NOzoeDiNim3TTlkyzggAdOFbsLL7IUuBKlvNJOozVAuzt8Hmn
q6OgwcMSDLIMYHzexHDUIw8nbO/ZF/7VafJxjph3DIcHbn08HRbYyBf+aTIb
8d+neKg/XnuEMmB1Ea6Bw0vmCFSFS/Zh4ePJ/DweJMCvA4gBDk7yIxqj6fbq
xV9+BASEuJNGBD+v9AGGNQauE26fjtOV9/728rnzIvy+ujpdLATdqX4pmY7i
4tx+ja9cnc5BupksLmEJzi/n58lM/m40GutuVffwqjSsV3pYr9YPa1Ye1eyG
Qd1tTLMsmxfAUzs9yGuw7dUvvXvzw4n9Av6+Oj0fZB+vTvM4LZJmkHzk318+
/vL69D3sVKPZ6iRTvojPd/teiT7Kx0L11EpTT7+8xk/1kH44Pjl+8ePrd3pg
qPA/LYYgAwynw2Lot6zx6odh+eGRd3AMTxvHwzydL9a1f6zanSSL03fH0KzV
TNUbRYpqLlb22YtlX4cV/sKv7nCxHKRFsUzsV9W1L/wvgqvTk5+e//4FUItZ
1vz9i6C6FXjGbgB+wozThTj56fvTxiCLF6eHayZcglUNqhak4tEnlOLdyLT8
jIT/5Wz0yw1I6t+tm/r8+fz5/Pn8+fz5/Pn8+fz5/Pn8+fzZ7+f/A3lBrb8A
uAEA

--0-1894466935-1178140254=:41406--

\start
Date: Wed, 02 May 2007 23:57:29 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: gclweb.lisp

On 05/02/2007 07:14 PM, Tim Daly wrote:
 > Ralf,
 >
 > The string contained within the chunkname field of
 > \begin{chunk}{chunkname}
 > is unparsed in the current code and can contain anything
 > at all. It is purely used as a key to the hash table.

Really? The idea of LP actually says (at least to me) that chunkname 
should be considered like a \section command, so it should have a very 
meaningful name. And

<<*>>=
<<chunk1>>
<<chunk2>>
<<chunk3>>
@

(or the LaTeX-syntax equivalent)
should read like a table of contents. If you allow any character 
(including % and $) to lose their usual TeX meaning then you forbid

\begin{chunk}{The first 10% of implementation of $a^2+b^2=c^2$}
...
\end{chunk}

to print nicely. (I could have escaped %, of course.)
Anyway, retaining TeX meaning of the characters is probably the better 
way to go.

\start
Date: Wed, 2 May 2007 17:50:09 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: gclweb.lisp

Ralf,

When I said that the chunkname is unparsed I meant that
it was unparsed by gclweb.lisp which just uses the raw character
string as a key into the hash table. The chunkname follows the
rules of latex so special characters would have to be escaped.

If you look at the TEX book by Knuth, a literate document,
he uses the chunkname as a description of the meaning of the chunk.
Thus we find things like:

<Initialize the output routines>
<Print the banner line, including the data and time>
<Report that the font won't be loaded>

so a procedure description could be read in sentences:

Procedure foo {
<Initialize the output routines>
<Print the banner line, including the data and time>
<Report that the font won't be loaded>
...
}
 
This would be most beneficial in documenting the algebra algorithms.

I like Knuth's use of the chunknames as an additional means
of documentation although I've been rather lax in following
his example. Of course, this is a matter of style and taste
which means that it is an invitation to a flame war.

Suffice it to say that the only gclweb program use is as a hash key
which places no restriction on the contents.

\start
Date: Wed, 2 May 2007 18:36:47 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: gclweb.lisp

Ralf,

gclweb is only intended as an interim hack until we move to ANSI,
at which point I expect that the CWK algorithms will be used.

We should, however, debate the question of what FUNCTION we want
out of the pamphlets, as opposed to style and form. Do we want
hyperlinking, biblographic references, unit and regression 
testing, URL parsing, )compile compatibility, hyperdoc/html
processing, drag-and-drop processing, user examples, etc.

Since you've been pioneering the implementation of these ideas
using ALLPROSE perhaps you can put together an initial proposal
which we could maintain as "the pamphlet proposal". An initial
version would be an outline of the ALLPROSE current function.

Style and form questions are much harder to debate because we
have so many options. I feel we have to distinguish these from
their intended function so we don't get hung up in the details.

CWK's clweb is the better place to experiment since
it is more forward-looking and the long term strategy.

\start
Date: Wed, 2 May 2007 19:49:17 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Ralf Hemmecke
Subject: Re: gclweb.lisp

--- Tim Daly wrote:

> Ralf,
> 
> gclweb is only intended as an interim hack until we move to ANSI,
> at which point I expect that the CWK algorithms will be used.

Hmm.  Tim, looking at the TeX output from the noweb command it's a tad
more involved than I originally expected.  It should be possible to
handle it, but in order to cover the general cases needed it will
probably require some deeper digging into the why of various commands
to check for corner case behavior specs.  I have a couple quick
orientation questions if you happen to know the answers:

1.  The generated names such as NWcl*P-cop9-1 clearly are not assigned
at random, but are based on the chunk name combined with some other
strings.  Is this merely for readability when assigning unique labels
or does the structure of that name/label have a functional significance
to the style file?

2.  The list of chunks at the end of the file appears to be sorted in
alphabetical order by the first non-numeric character in the chunk name
- is that sort order necessary?

The function of things like nwbegincode, nwendcode, nwbegindocs and
nwenddocs is readily apparent, and for whatever reason each chunk and
documentation region is assigned a number, bumped each time a new
region is defined (all chunks have odd numbers, all doc regions even
ones). The ones I'm not quite following yet are nwdocspar,
nwixlogsorted, nwixd, are nwixu.

One design question I'll ask now, because it will impact how work goes
forward - should the initial scan of the buffer do all the work needed
and place it in the structure, or should the extra steps only be taken
if a separate scan function is called?  I would not expect a drastic
increase in scan time but most likely there would be some, if for no
other reason than the extra assignment work to be done.  Do we want to
have a "pure" tangle that does only what is needed for the machine
code, or should we have one scan function that records all info needed?

> We should, however, debate the question of what FUNCTION we want
> out of the pamphlets, as opposed to style and form. Do we want
> hyperlinking,

Absolutely.

> biblographic references,

My vote is a very definite yes, obviously.  Better to have the key
information in the pamphlet as opposed to buried in an obscure research
paper someone would have to see $30 to see, and in that case we need to
cite sources.  Anyway, I would think references would be needed for
algorithms in any case?

> unit and regression testing,

I'm sort of torn here.  Certainly I think we need these tools and full
documentation of the tests (why they've been selected, references,
etc), but I'm not sure how they relate to pamphlets.  I take it you are
thinking of a specific chunk structure for unit tests?  Hmm.

> URL parsing, 

Doesn't the hyperref latex package already handle URLs?  What
functionality did you have in mind?

> )compile compatibility,

I certainly think this would be desirable.


> hyperdoc/html processing, drag-and-drop processing, user examples,
etc.

Not sure what you mean by html processing - output of latex to html
files?  Reading html formatted commands/files?  HTML output from LaTeX
is a non-trivial problem and most solutions are imperfect.  Not sure
about other issues yet.

> Since you've been pioneering the implementation of these ideas
> using ALLPROSE perhaps you can put together an initial proposal
> which we could maintain as "the pamphlet proposal". An initial
> version would be an outline of the ALLPROSE current function.

Agreed - such a document would be very useful.

> Style and form questions are much harder to debate because we
> have so many options. I feel we have to distinguish these from
> their intended function so we don't get hung up in the details.

Yes.  Style ultimately should be configurable anyway - the thing to
check there is that LaTeX packages used are compatible with each other.

\start
Date: 03 May 2007 12:41:46 +0200
From: Martin Rubey
To: list
Subject: PFE, Complex and INT

Dear all,

regarding Issue #352 and possibly #351, I experimented a little.  The starting
point is the documentation of PFECAT, in catdef.spad:

)abbrev category PFECAT PolynomialFactorizationExplicit
++ Author: James Davenport
++ Description:
++ This is the category of domains that know "enough" about
++ themselves in order to factor univariate polynomials over themselves.
++ This will be used in future releases for supporting factorization
++ over finitely generated coefficient fields, it is not yet available
++ in the current release of axiom.

Many domain constructors like, for example, Complex export PFECAT, with the
condition that their arguments has PFECAT and possibly satisfies some other
conditions, too.  However, at the moment, not even Integer exports PFECAT, so,
in effect, it is not yet used.  Curiously, it implements most of the operations
needed, so I'd think we could simply make Integer or rather IntegerNumberSystem
export PFECAT.

A related category is UniqueFactorizationDomain, also defined in catdef:

)abbrev category UFD UniqueFactorizationDomain
++ A constructive unique factorization domain, i.e. where
++ we can constructively factor members into a product of
++ a finite number of irreducible elements.

What I really wanted is to be able to say

(5) -> 2::FR COMPLEX INT

                     2
   (5)  - %i (1 + %i)
                                               Type: Factored Complex Integer

So, I modified COMPCAT as follows, i.e., since I don't know about square free
factorization, I just used factor.

I'd be very interested in comments.

Martin

diff -c /home/martin/lib/axiom/target/i686-pc-linux/src/algebra/gaussian.spad
/home/martin/gaussian.spad
*** /home/martin/lib/axiom/target/i686-pc-linux/src/algebra/gaussian.spad
2007-05-02 20:39:25.000000000 +0200
--- /home/martin/gaussian.spad  2007-05-03 09:30:12.000000000 +0200
***************
*** 91,96 ****
--- 91,97 ----
           ++ "failed" if x is not a rational number.
       if R has PolynomialFactorizationExplicit and R has EuclideanDomain then
          PolynomialFactorizationExplicit
+      if R has UniqueFactorizationDomain then UniqueFactorizationDomain
   add
         import MatrixCategoryFunctions2(%, Vector %, Vector %, Matrix %,
                                         R, Vector R, Vector R, Matrix R)
***************
*** 116,121 ****
--- 117,130 ----
               --!gcdPolynomial(pp,qq) == modularGcd(pp,qq)$TT
               solveLinearPolynomialEquation(lp:List Sup,p:Sup) ==
                 solveLinearPolynomialEquation(lp,p)$ComplexIntegerSolveLinearPolynomialEquation(R,%)
+ 
+              squareFree x == 
+                y: Complex Integer := complex(convert(real x)@Integer, 
+                                              convert(imag x)@Integer)
+                z: Factored Complex Integer :=
factor(y)$GaussianFactorizationPackage
+                mf: Complex Integer -> % := complex(real(#1)::R, imag(#1)::R)
+                map(mf #1, z)$FactoredFunctions2(Complex Integer, %)
+ 
            normPolynomial: Sup -> SupR
            normPolynomial pp ==
                map(retract(#1@%)::R,pp * map(conjugate,pp))

\start
Date: 03 May 2007 07:18:11 -0500
From: Gabriel Dos Reis
To: list
Subject: [Juho Snellman] Re: [Sbcl-devel] Version Control Systems

FYI.
This is not a Call For Debate.


--=-=-=

From: Juho Snellman

James Y Knight <foom@fuhm.net> writes:
> I'd like to propose switching to sf.net SVN hosting. Now, for all you  
> svn naysayers out there, before you say your nays, I'd like to first  
> point out that svn repositories can be used directly by bzr (http:// 
> bazaar-vcs.org/BzrForeignBranches/Subversion) and git (http:// 
> www.kernel.org/pub/software/scm/git/docs/git-svn.html). And of course  
> there's also svk (http://svk.bestpractical.com/view/HomePage). So  
> that's 3 distributed-VCS tools, and svn itself, that you can use  
> directly with an upstream svn repository, without requiring a  
> conversion step. 4 VCS systems for the price of 1, and don't have to  
> move to an alternate hosting provider. It sounds like a pretty good  
> deal to me.

I second the proposal.

Whether we use cvs or svn doesn't matter horribly much to my workflow
since my only interaction with cvs is running a script that commits
stuff from my git repository to the official cvs one. Getting rid of
the git gateway sync delay would be just a minor improvement, nothing
critical. But there are a lot of minor things that would be improved
by switching, and at some point they start adding up. As another
example, it'd be nice if people without commit access could send
properly formatted patches that add new files (hard to do with cvs,
since "cvs add" requires commit rights).

\start
Date: Thu, 3 May 2007 07:54:20 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: gclweb.lisp

Gaby,

In fact I tried the git-svn tool checkout last night on the daly branch.
I need to see if the change/commit cycle works.
Since I've moved to git this would be very convenient if it works.
I'll let you know the result of my trials.

\start
Date: Thu, 3 May 2007 08:18:54 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: gclweb.lisp

On Thu, 3 May 2007, Tim Daly wrote:

> Gaby,
> 
> In fact I tried the git-svn tool checkout last night on the daly branch.
> I need to see if the change/commit cycle works.
> Since I've moved to git this would be very convenient if it works.

Indeed.

> I'll let you know the result of my trials.

Great!

\start
Date: Thu, 3 May 2007 16:04:05 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: git-svn

Well checkout works and I can make changes.
I just cannot commit changes. I get

Authorization failed:
MKACTIVITY of '/svnroot/axiom/!svn/act/.....: 
authorization failed (https://axiom.svn.sourceforget.net) at
/usr/bin/git-svn line 875

I'm open to suggestion about why I cannot commit to SVN.

\start
Date: Thu, 3 May 2007 17:56:06 -0400
From: Bill Page
To: list
Subject: MathMLFormat and serv.c

Axiom Developers;

Without much fanfare, Arthur Ralfs has contributed the following
important package for Axiom:

http://wiki.axiom-developer.org/MathMLFormat

See also the email thread:

http://lists.nongnu.org/archive/html/axiom-developer/2007-02/msg00149.html

The package includes several patchs which integrates MathML
into Axiom so that it can be invoked with just a one command:

  )set output mathml on

I think we should consider including this in the next release
of Axiom.

I was also very interested to see a small C program which Ralf
provides with this package to enable access to Axiom from a
browser. He says:

> I have written a few files to enable automatic viewing in
> Firefox. The file serv.c is a wrapper for starting and
> communicating with Axiom.

...

The initial comments of 'serv.c' include:

/*
 * This software is to enable displaying Axiom output on the
 * Firefox web browser.  I got started on it by looking at
 * tm_axiom.c by Andrey Grozin.
 * As such it falls under the GNU general public license and
 * comes WITHOUT ANY WARRANTY WHATSOEVER.
 * COPYRIGHT : (C) 2006 Arthur C. Ralfs
*/
/*
 * The purpose of this program is to start up axiom and connect
 * to it with a pair of pipes, axcom.axin and axcom.axout, and
 * then setup a socket to listen for commands.
*/

The reason this seems especially interesting is because of the
recent work by Martin to implement a simple web server inside
Axiom itself with no extermal process.

http://wiki.axiom-developer.org/SandBoxHyperDocReplacement

I think it might be a simple matter to use this approach with
Ralf's example code without having to use PHP and Apache.

Alternately, 'serv.c' might be of some interest for other
applications that interface with Axiom.

Is there anyone else on this list who is interested in
applications of MathML in Axiom?

\start
Date: Thu, 3 May 2007 17:20:13 -0500
From: Tim Daly
To: Bill Page
Subject: next release

Bill,

The items you mentioned are very interesting but they will
certainly not make the next release. I'm nearly finished 
collecting the non-algebra changes from myself, Gaby, and Waldek.
I plan to release this version and then start on the algebra
changes which require much more verification work.

\start
Date: Thu, 3 May 2007 17:48:06 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Desired functionality from noweb

As I'm getting deeper into learning what noweb is capable of, I would
like to ask the list if anyone is familiar with the various options
noweb provides on the LaTeX side of the equation and how many of them
people like to use.

The noweb style file defines many elaborate output options, but coming
at it from a "need to generate LaTeX" standpoint I can't help wondering
if something a little less elaborate would meet our needs - dhmatrix
doesn't appear to use too many of the fancier noweb options and with
hyperlinking to link chunks together I'm not sure if some of the
features (e.g. the labels identifying page number and a,b,c etc.) add
enough to be worth supporting them.  Does anyone have any opinions
about this?

My thought at this time is with hyperref to link chunks to their
definitions (e.g. treat them like normal LaTeX hyperrefs) and perhaps
automatically generating index entries for chunks that should be enough
to cover what we would require.  (perhaps an automatically inserted
"used by" note would be handy to identify the higher level chunk into
which a sub-chunk is inserted.)  I am not particularly concerned about
having the web routine try to deduce from the code in the chunk what
other chunks have code that uses the functionality defined there -
indeed with Lisp macros any such listing would almost have to be
incomplete if generated automatically.  In my opinion the surrounding
text should describe such relationships if they are non-obvious (e.g.
something a utility like xref couldn't deduce.)

My impulse is to see how much functionality can be achieved by
straightforward, standard LaTeX generation, but that may be a waste of
time if the features provided by noweb.sty are essential.  What is the
general opinion on this, particularly from more experienced literate
programmers out there?

\start
Date: Thu, 3 May 2007 20:05:52 -0500
From: Tim Daly
To: Cliff Yapp
Subject: latex and noweb

Cliff,

The only two noweb tools I've used are the chunking mechanism and the
[[]] quoting mechanism. And I've started rewriting the [[]] quoting
mechanism out of material, both new and old.

I debated, coded and removed other facilities in gclweb (you can still
see remnants of code in the preline and postline unused variables, etc).
Automatic indexing might be nice but I can generate my own index info.
Except for David's booklet URL syntax there is nothing I need.

\start
Date: Thu, 3 May 2007 18:50:30 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: latex and noweb


--- Tim Daly wrote:

> Cliff,
> 
> The only two noweb tools I've used are the chunking mechanism and the
> [[]] quoting mechanism. And I've started rewriting the [[]] quoting
> mechanism out of material, both new and old.

OK.

> I debated, coded and removed other facilities in gclweb (you can
> still see remnants of code in the preline and postline unused
> variables, etc).
> Automatic indexing might be nice but I can generate my own index
> info. Except for David's booklet URL syntax there is nothing I need.

That's this functionality here?
http://wiki.axiom-developer.org/images/axiom--test--1/src/doc/booklet.c.pamphlet

I see in the appendix you state that this is to be built even before
common lisp - does that mean you want to keep it in C?  We must assume
SOME working compiler on the system, and I guess I was thinking we
would include a binary lisp (sbcl, perhaps) for bootstrapping - is it
your preference to rely on gcc being available or bundle a binary lisp?

I think the same basic techniques that worked on tangle would work here
(probably with some minor variations) so if we want to move this to
lisp we can.

\start
Date: Thu, 3 May 2007 21:24:01 -0500
From: Tim Daly
To: Cliff Yapp
Subject: latex and noweb

Cliff,

I expect that if we use the booklet URL syntax that it would
be within the clweb machinery, not in C. If Axiom serves pages
to a firefox front end it would be easy to turn the embedded
URLs into web pages.

\start
Date: Thu, 3 May 2007 19:34:16 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: latex and noweb

Is there any reason not to do this in LaTeX using the hyperref package?
 If we include a link to a pamphlet file as a hyperref link, and
Firefox submits that link to the Axiom server as a filename, wouldn't
Axiom then be able to deal with it as just another pamphlet request? 
We're going to have to translate pamphlet latex to html to do what
you're suggesting in any case, and IIRC hyperref is actually one of the
better supported features of the html converters.  As a bonus, pdflatex
and latex would also be able to understand the link when generating pdf
and dvi files.

Sorry if that's a silly suggestion - I may not be understanding the
usage scenario correctly.


> Cliff,
> 
> I expect that if we use the booklet URL syntax that it would
> be within the clweb machinery, not in C. If Axiom serves pages
> to a firefox front end it would be easy to turn the embedded
> URLs into web pages.

\start
Date: Thu, 3 May 2007 21:51:40 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Test of a WEB style

I have created a sample file of a format for pamphlets that can be
generated without needing the noweb style file (obviously without many
of the major features.)  

http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.5-hyperreftest.pdf/download

This file makes use of the hyperref and listings packages in LaTeX (I
believe both are included standard with teTeX).  It has hyperlinks from
chunk references to chunks.  To generate it, the commands were:

latex cl-web-v0.5-hyperreftest.tex
bibtex cl-web-v0.5-hyperreftest
latex cl-web-v0.5-hyperreftest.tex
latex cl-web-v0.5-hyperreftest.tex
latex cl-web-v0.5-hyperreftest.tex
dvips cl-web-v0.5-hyperreftest.dvi -o cl-web-v0.5-hyperreftest.ps
ps2pdf cl-web-v0.5-hyperreftest.ps

(thanks again to Bill for figuring out these steps and the hyperref
options for endpamphlet).

If it is of interest the "Included in ..." tail can be added to
identify chunks containing the current chunk, although I didn't do that
here because I'm generating this one by hand as a test case.  Feedback
appreciated - is this something people think would be good to have?  If
so, I believe it can be autogenerated from cl-web requiring only
packages already present in teTeX.

\start
Date: Fri, 4 May 2007 01:28:27 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Test of a WEB style

On May 4, 2007 12:52 AM C Y wrote:
>
> I have created a sample file of a format for pamphlets that can
> be generated without needing the noweb style file (obviously
> without many of the major features.) 
>
http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.5-hyperref=
tes
t.pdf/download

Cliff, I do really like the "look and feel" of this example!
It looks pretty and it seems to work.

>
> This file makes use of the hyperref and listings packages in
> LaTeX (I believe both are included standard with teTeX).  It
> has hyperlinks from chunk references to chunks.  To generate
> it, the commands were:
>
> latex cl-web-v0.5-hyperreftest.tex
> bibtex cl-web-v0.5-hyperreftest
> latex cl-web-v0.5-hyperreftest.tex
> latex cl-web-v0.5-hyperreftest.tex
> latex cl-web-v0.5-hyperreftest.tex
> dvips cl-web-v0.5-hyperreftest.dvi -o cl-web-v0.5-hyperreftest.ps
> ps2pdf cl-web-v0.5-hyperreftest.ps
>
> (thanks again to Bill for figuring out these steps and the
> hyperref options for endpamphlet).

I presume the above steps (because there are so many) include
the processing for the embedded graphviz commands used to
generate the finite-state diagram? If so, very nice.

What does the actual pamphlet source file look like? Specifically,
how are chunks delimited? Can you give us a link to the source
.pamphlet file?

>
> If it is of interest the "Included in ..." tail can be added
> to identify chunks containing the current chunk, although I
> didn't do that here because I'm generating this one by hand
> as a test case.

Ah. By "generating this one by hand" do you mean that this is
not (yet) generated by some operation equivalent to 'noweave'?
So you do not (yet) have the source that would produce the above
result? Or are you just talking about the "Included in ..."?

> Feedback appreciated - is this something people think would
> be good to have?  If so, I believe it can be autogenerated
> from cl-web requiring only packages already present in teTeX.
>

How much work remains to be done to do this autogeneration?
(autogeneration == noweave?)

\start
Date: Fri, 04 May 2007 10:11:22 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Desired functionality from noweb

Hi Cliff,

On 05/04/2007 02:48 AM, C Y wrote:
> As I'm getting deeper into learning what noweb is capable of, I would
> like to ask the list if anyone is familiar with the various options
> noweb provides on the LaTeX side of the equation and how many of them
> people like to use.

First, here look at
http://www.hemmecke.de/aldor/
or
http://www.hemmecke.de/aldor/allprose/
for some features I use in ALLPROSE.

At
http://www.hemmecke.de/aldor/allprose/myalpssu54.html#x104-12000028.1
you find that I my basic command is

noweave -n -index

-n      does not produce a latex wrapper (ALLPROSE provides a wrapper.)
-index  produces index information of identifiers

Although deprecated by Norman Ramsey, I use the

<<chunkname>>=
...
@ %def Identifier1 Identifier2 ...

a lot to get hyperlinks inside code chunks. (For .as files, this %def
information is autogenerated by ALLPROSE scripts.)

You also see

NOTANGLE, used in chunks 362, 363, 376, 435, 437, 468b, and 548.

I find this information sometimes quite useful to find out where some
identifiers are used. And look a bit closer at the last link (548).
NOTANGLE is defined in Makefile.nw. The link leads to a place that is in
test/Makefile.nw (see top of .html page).

My way to use noweave is:

   1. concatenate all .nw files
   2. run noweave -n -index on the concatenated file
   3. split the output into .tex files corresponding to the
      original .nw files
   4. Use a wrapper (which looks approximately like)
      \documentclass{article}
      \usepackage{allprose}
      \begin{document}
      \inputAllTexFiles
      \end{document}
   5. latex/pdflatex/htlatex that wrapper.

You find the full story on the website
http://www.hemmecke.de/aldor/allprose/myalpssu62.html#noweb.NWGFlOZ-RntG3-1

Note that I don't think that everything should go into one big pamphlet 
file. I rather like to edit several files which finally produce ONE 
document. Using "inverse search" 
(http://en.wikipedia.org/wiki/Inverse_search), the file boundaries are 
pretty much blurred. I never type filenames for loading files. I simply 
click into the .dvi file.

Of course, I have added a number of TeX commands to make use of
identifiers defined via the %def syntax. They can be used via

   \useterm{identifier}

inside ordinary non-chunk text and link to the defining code chunk.

I don't use the [[..]] syntax at all and would actually suggest not to
use it. [[...]] is no proper tagging, but rather like \verb.
Inside my text I rather use something like

\usemaketarget{...}
\definetexcommand
\usetexcommand
\defineterm
\useterm
...

See also
http://www.hemmecke.de/aldor/allprose/myalpsse11.html

I think also the little arrows at the top of each code junk are nice, in
particular if a code junk continues at some other place. You then see a

   +\equiv

at the top of the code junk and can click through the code chunks that 
belong together.

And if you look at the index you will find red and blue entries. I have
added a TeX command to modify the noweb.sty so that definitions are
shown in red in the index. (Style of course adjustable)


What I don't like at all with noweb is that one gets a \par after the
end of a code chunk if the @ is not followed by a space and %. In noweb
the Text can be continued immediately after the ending @\space, but for 
me that looks terrible. I want to see in the latex source were a code 
junk ends. A single @ doesn't catch the eye so quickly.

> The noweb style file defines many elaborate output options, but coming
> at it from a "need to generate LaTeX" standpoint I can't help wondering
> if something a little less elaborate would meet our needs

Don't worry too much about the .sty file. If you generate LaTeX by a 
program, you can pretty much rewrite the text into simple TeX commands 
so that .sty file programming would be an easy task. I have chosen that 
option for \adname 
(http://www.hemmecke.de/aldor/allprose/myalpssu33.html#x78-8400025.2.8). 
It is translates into \adinternalusename 
(http://www.hemmecke.de/aldor/allprose/myalpssu35.html#x82-9200025.4) by 
the script tools/aldordoc2tex.pl.nw 
(http://www.hemmecke.de/aldor/allprose/myalpsse26.html). Otherwise I 
would have had hard times to deal with \catcode and such to allow % and 
friend to appear inside the argument of \adname. That command would be 
used as

   \adname{-: % -> %}
   \adname{-: (%, %) -> %}

and lead to different hyperlinks. And if such a function is also defined 
in another type than the current one, it is also possible to say

   \adname[AdditiveGroup]{-: (%, %) -> %}

in order to specify exactly where the link should point to. (OK, but 
that is something not really connected to noweb.

> dhmatrix
> doesn't appear to use too many of the fancier noweb options and with
> hyperlinking to link chunks together I'm not sure if some of the
> features (e.g. the labels identifying page number and a,b,c etc.) add
> enough to be worth supporting them.  Does anyone have any opinions
> about this?

dhmatrix is a paper in traditional form. Nowadays, I would additionally 
like to see hyperlinks. Time is a precious thing so help the reader to 
quickly find the thing s/he is looking for. Going back and forth to the 
index manually (like in printed form) is old technology.

> My thought at this time is with hyperref to link chunks to their
> definitions (e.g. treat them like normal LaTeX hyperrefs) and perhaps
> automatically generating index entries for chunks that should be enough
> to cover what we would require.  (perhaps an automatically inserted
> "used by" note would be handy to identify the higher level chunk into
> which a sub-chunk is inserted.)

Eventually, (in particular for the Algebra) I would like to see links to 
where an identifier is exactly used. In order to generated the correct 
hyperlink, it would be necessary to actually compile the spad/aldor 
program so that it becomes clear what an identifier like "foo" actually 
means in a certain context. Note that I could locally have defined

macro foo(x, y) == a + b;

so "foo" should better point to the corresponding + in the source (or at 
least to its macro definition.

 > I am not particularly concerned about
> having the web routine try to deduce from the code in the chunk what
> other chunks have code that uses the functionality defined there -
> indeed with Lisp macros any such listing would almost have to be
> incomplete if generated automatically.  In my opinion the surrounding
> text should describe such relationships if they are non-obvious (e.g.
> something a utility like xref couldn't deduce.)

As I said a big wish is semantic hyperlinks. (As I understood correctly, 
Tim already referred to that option when he said that in lisp all the 
information about symbols is available.)

> My impulse is to see how much functionality can be achieved by
> straightforward, standard LaTeX generation, but that may be a waste of
> time if the features provided by noweb.sty are essential.

I don't think that anything from noweb.sty is essential. You simply have 
to put the logic into cl-web, then you don't need a style file at all.

\start
Date: Fri, 04 May 2007 12:57:56 +0200
From: Ralf Hemmecke
To: Bill Page, Cliff Yapp
Subject: Re: Test of a WEB style

On 05/04/2007 07:28 AM, Bill Page wrote:
> On May 4, 2007 12:52 AM C Y wrote:
>> I have created a sample file of a format for pamphlets that can
>> be generated without needing the noweb style file (obviously
>> without many of the major features.)  
>>
> http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.5-hyperreftes
> t.pdf/download
> 
> Cliff, I do really like the "look and feel" of this example!
> It looks pretty and it seems to work.

I appreciate very much the literate work. That is a very good example 
how literate documents should look like.

For your convenience I have embellished it a bit.

http://portal.axiom-developer.org/Members/hemmecke/document.pdf/download

(unfortunately the graph has to be adjusted---I am too lazy)

The sources are here.

http://portal.axiom-developer.org/Members/hemmecke/cl-web.tar.gz/download

Simply type

make pdf

or just

make

for the .ps file.

Look also at the generated .dvi file, adjust your dvi viewer and click 
on it. I have incorporated the inverse search facility.

\start
Date: Fri, 4 May 2007 04:17:58 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Test of a WEB style

--- Bill Page wrote:

> On May 4, 2007 12:52 AM C Y wrote:
> > 
> > I have created a sample file of a format for pamphlets that can
> > be generated without needing the noweb style file (obviously
> > without many of the major features.)  
> > 
>
http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.5-hyperreftes
> t.pdf/download
> 
> Cliff, I do really like the "look and feel" of this example!
> It looks pretty and it seems to work.

Thanks!

> > This file makes use of the hyperref and listings packages in
> > LaTeX (I believe both are included standard with teTeX).  It
> > has hyperlinks from chunk references to chunks.  To generate
> > it, the commands were:
> > 
> > latex cl-web-v0.5-hyperreftest.tex
> > bibtex cl-web-v0.5-hyperreftest
> > latex cl-web-v0.5-hyperreftest.tex
> > latex cl-web-v0.5-hyperreftest.tex
> > latex cl-web-v0.5-hyperreftest.tex
> > dvips cl-web-v0.5-hyperreftest.dvi -o cl-web-v0.5-hyperreftest.ps
> > ps2pdf cl-web-v0.5-hyperreftest.ps
> > 
> > (thanks again to Bill for figuring out these steps and the
> > hyperref options for endpamphlet).
> 
> I presume the above steps (because there are so many) include
> the processing for the embedded graphviz commands used to
> generate the finite-state diagram? If so, very nice.

No, not yet actually - I didn't want to introduce the build requirement
of graphviz into the Axiom source distribution yet (where this is
hopefully headed eventually).  I added an extra latex or two to make
sure all the references got resolved, but two after the bibtex file
might be enough.  The dvips and ps2pdf option works better for the
tangle diagram (pdflatex doesn't like it, even after I convert it -
probably need to play with bounding boxes or something...)

I think that probably CAN be done without too much trouble, but it
would mean graphviz would be needed to build it.  What do we want to do
about that?  Implementing the graphviz algorithms in Lisp is going to
be a bit more involved than noweb...

> What does the actual pamphlet source file look like? Specifically,
> how are chunks delimited? Can you give us a link to the source
> .pamphlet file?

Right now, they would be delimited just like a noweb pamphlet.  Chunk
delimiters aren't so critical actually, unless we want NO
pre-processing steps before latexing a pamphlet file.  There isn't a
pamphlet source file that gets translated to this form yet, but once
weave is written in Lisp existing pamphlets should be translatable to
this without major (or any, for that matter) adjustment.

> > If it is of interest the "Included in ..." tail can be added
> > to identify chunks containing the current chunk, although I 
> > didn't do that here because I'm generating this one by hand
> > as a test case.
> 
> Ah. By "generating this one by hand" do you mean that this is
> not (yet) generated by some operation equivalent to 'noweave'?

Right.  I want to know what I need to generate before I start on the
machinery to do so.

> So you do not (yet) have the source that would produce the above
> result? Or are you just talking about the "Included in ..."?

The regular pamphlet source should produce this result - what I don't
have yet is the routines that will build the LaTeX from the pamphlet
structure.  The TeX file I did is here, FWIW:

http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.5-hyperreftest.tex/download

> > Feedback appreciated - is this something people think would
> > be good to have?  If so, I believe it can be autogenerated
> > from cl-web requiring only packages already present in teTeX.
> 
> How much work remains to be done to do this autogeneration?
> (autogeneration == noweave?)

It SHOULD be a case of adding some information recording to the chunk
structure and scan-for-chunks function, creating a utility to convert
strings and chars to the correct output stream format, and writing the
weave function to make the correct calls.  There may be a couple other
gotchas to deal with once I actually start but that's the core of what
needs to be done.

\start
Date: Fri, 4 May 2007 04:33:17 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke, Bill Page
Subject: Re: Test of a WEB style

--- Ralf Hemmecke wrote:

> I appreciate very much the literate work. That is a very good
> example how literate documents should look like.

Thanks!

> For your convenience I have embellished it a bit.
>
http://portal.axiom-developer.org/Members/hemmecke/document.pdf/download
> 
> (unfortunately the graph has to be adjusted---I am too lazy)

Wow.  That's really impressive!  Can you tell me which parts of the
graph are off?  I've been staring at it too long and I'm sure there's
probably something off but I'm not catching it at the moment :-(.

> The sources are here.
>
http://portal.axiom-developer.org/Members/hemmecke/cl-web.tar.gz/download
> 

Works - thanks!

> Look also at the generated .dvi file, adjust your dvi viewer and
> click on it. I have incorporated the inverse search facility.

Very nice!  This functionality Ralf might need to be incorporated as a
second stage - it needs a lot more of noweb's full strength.  I'm
shooting for a first cut at a weave functionality entirely defined in
Lisp - understanding all of the requirements to handle the extra
features is a bigger bite than I have time to chew right now.  Or we
could go with this if noweb is present on the system but fall back on
the plain Lisp version otherwise.

\start
Date: Fri, 04 May 2007 14:18:32 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Test of a WEB style

> http://portal.axiom-developer.org/Members/hemmecke/document.pdf/download
>> (unfortunately the graph has to be adjusted---I am too lazy)
> 
> Wow.  That's really impressive!  Can you tell me which parts of the
> graph are off?  I've been staring at it too long and I'm sure there's
> probably something off but I'm not catching it at the moment :-(.

Oh, if you don't see it then for you probably it is looks OK. In my 
acroread it cuts off below the Scrn node.

>> The sources are here.
>>
> http://portal.axiom-developer.org/Members/hemmecke/cl-web.tar.gz/download
> 
> Works - thanks!

>> Look also at the generated .dvi file, adjust your dvi viewer and
>> click on it. I have incorporated the inverse search facility.

> Very nice!  This functionality Ralf might need to be incorporated as a
> second stage - it needs a lot more of noweb's full strength.  I'm
> shooting for a first cut at a weave functionality entirely defined in
> Lisp - understanding all of the requirements to handle the extra
> features is a bigger bite than I have time to chew right now.  Or we
> could go with this if noweb is present on the system but fall back on
> the plain Lisp version otherwise.

Oh that would be good. I somehow don't really like to change the noweb 
syntax. Note that some day we might look closer to LEO. I don't want to 
reprogram their ideas only because we then use

   \begin{chunk} .. \end{chunk}

\start
Date: Fri, 4 May 2007 05:23:04 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Desired functionality from noweb


--- Ralf Hemmecke wrote:

> Hi Cliff,
> 
> On 05/04/2007 02:48 AM, C Y wrote:
> > As I'm getting deeper into learning what noweb is capable of, I
> > would like to ask the list if anyone is familiar with the various
> > options noweb provides on the LaTeX side of the equation and how
> > many of them people like to use.

> noweave -n -index
> 
> -n      does not produce a latex wrapper (ALLPROSE provides a
> wrapper.)

OK.  That should be doable by locating the \begin{document} tag,
although we lose any special \usepackage commands if we do...

> -index  produces index information of identifiers

OK.

> Although deprecated by Norman Ramsey, I use the
> 
> <<chunkname>>=
> ...
> @ %def Identifier1 Identifier2 ...
> 
> a lot to get hyperlinks inside code chunks. (For .as files, this %def
> information is autogenerated by ALLPROSE scripts.)

In the case of Lisp, I"m not quite sure how to do this in general. 
MOST of that information can probably be generated, but Lisp macros
would cause some difficulties in that department.

> You also see
> 
> NOTANGLE, used in chunks 362, 363, 376, 435, 437, 468b, and 548.
> 
> I find this information sometimes quite useful to find out where some
> identifiers are used. And look a bit closer at the last link (548).
> NOTANGLE is defined in Makefile.nw. The link leads to a place that is
> in test/Makefile.nw (see top of .html page).

You are piping the notangle information into a script that searches for
the strings of the identifiers you are wanting to get information on?

A lot of this aspect of noweb reminds me of the XREF utility in Lisp -
specifically the "who-calls" option, IIRC.  I think doing all of this
in Lisp could prove a bit non-trivial, at least to do it in a robust
fashion.

> My way to use noweave is:
> 
>    1. concatenate all .nw files
>    2. run noweave -n -index on the concatenated file
>    3. split the output into .tex files corresponding to the
>       original .nw files
>    4. Use a wrapper (which looks approximately like)
>       \documentclass{article}
>       \usepackage{allprose}
>       \begin{document}
>       \inputAllTexFiles
>       \end{document}
>    5. latex/pdflatex/htlatex that wrapper.


OK.  So when you write .nw files originally they contain no header
information at all.  I think this gets back to the original discussion
on how to handle different pamphlets needing different style files
(sistyle for units, for example.)  I'll need to ponder this one some
more and see if I can find the package or two designed to handle such
situations...

> You find the full story on the website
>
http://www.hemmecke.de/aldor/allprose/myalpssu62.html#noweb.NWGFlOZ-RntG3-1

Out of curiosity Ralf, have you ever benchmarked ALLPROSE?  How long
would it take do you think to process something really large?

> Note that I don't think that everything should go into one big
> pamphlet file. I rather like to edit several files which finally
> produce ONE document.

I tend to think of it as one pamphlet = 1 "concept", and then pamphlets
would be bundled like conference proceedings to make larger volumes. 
It's the combining that makes it interesting.

> Using "inverse search" 
> (http://en.wikipedia.org/wiki/Inverse_search), the file boundaries
> are pretty much blurred. I never type filenames for loading files. I
> simply click into the .dvi file.
> 
> Of course, I have added a number of TeX commands to make use of
> identifiers defined via the %def syntax. They can be used via
> 
>    \useterm{identifier}
> 
> inside ordinary non-chunk text and link to the defining code chunk.

OK.

> I don't use the [[..]] syntax at all and would actually suggest not
> to use it. [[...]] is no proper tagging, but rather like \verb.
> Inside my text I rather use something like
> 
> \usemaketarget{...}
> \definetexcommand
> \usetexcommand
> \defineterm
> \useterm
> ...
> 
> See also
> http://www.hemmecke.de/aldor/allprose/myalpsse11.html

I'll need to study that one some more.

> I think also the little arrows at the top of each code junk are nice,
> in particular if a code junk continues at some other place. You then
> see a
> 
>    +\equiv
> 
> at the top of the code junk and can click through the code chunks
> that belong together.

In essence, links that move the reader through the document in the
order in which the machine would see the code?  That's not a bad idea. 
Hmm...

> And if you look at the index you will find red and blue entries. I
> have added a TeX command to modify the noweb.sty so that definitions
> are shown in red in the index. (Style of course adjustable)

I'm still a bit unsure of the viability of the language aware part of
the noweave process when it comes to Lisp, and done right it will
greatly increase the challenge of programming all of this.  I think the
right approach here will be to start small and scale up. 

> What I don't like at all with noweb is that one gets a \par after the
> end of a code chunk if the @ is not followed by a space and %. In
> noweb the Text can be continued immediately after the ending @\space,

> but for me that looks terrible. I want to see in the latex source
> were a code junk ends. A single @ doesn't catch the eye so quickly.

I always assumed that the working literate programming style wouldn't
have code actually inline with text - are you saying you DO want to use
that style and don't want the \par command?

> Don't worry too much about the .sty file. If you generate LaTeX by a 
> program, you can pretty much rewrite the text into simple TeX
> commands so that .sty file programming would be an easy task.

OK.

> I have chosen that option for \adname 
>
(http://www.hemmecke.de/aldor/allprose/myalpssu33.html#x78-8400025.2.8).
> 
> It is translates into \adinternalusename 
> (http://www.hemmecke.de/aldor/allprose/myalpssu35.html#x82-9200025.4)
> by 
> the script tools/aldordoc2tex.pl.nw 
> (http://www.hemmecke.de/aldor/allprose/myalpsse26.html). Otherwise I 
> would have had hard times to deal with \catcode and such to allow %
> and 
> friend to appear inside the argument of \adname. That command would
> be 
> used as
> 
>    \adname{-: % -> %}
>    \adname{-: (%, %) -> %}
> 
> and lead to different hyperlinks. And if such a function is also
> defined 
> in another type than the current one, it is also possible to say
> 
>    \adname[AdditiveGroup]{-: (%, %) -> %}
> 
> in order to specify exactly where the link should point to. (OK, but 
> that is something not really connected to noweb.

Makes sense, I think - I'll stare at it some more.

> > dhmatrix doesn't appear to use too many of the fancier noweb
> > options and with hyperlinking to link chunks together I'm not
> > sure if some of the features (e.g. the labels identifying page
> > number and a,b,c etc.) add enough to be worth supporting them.
> > Does anyone have any opinions
> > about this?
> 
> dhmatrix is a paper in traditional form. Nowadays, I would
> additionally like to see hyperlinks. 

Maybe we need to define the term hyperlinks - some are simple (like the
ones in my original example, and adding chunk names to an index
shouldn't be TOO hard) and some are dependent on very advanced code
recognition abilities (like identifying where functions are defined and
used, and indexing them.)  I would prefer to start simple and not mess
with understanding the code at first, perhaps working up to that later.

> Time is a precious thing so help the reader to 
> quickly find the thing s/he is looking for. Going back and forth to
> the index manually (like in printed form) is old technology.

Absolutely agree, but there are degrees which will result in rapidly
increasing complexity.  Hyperlinks for chunks and chunk references are
simple, hyperlinks WITHIN code inside chunks are not.

> > My thought at this time is with hyperref to link chunks to their
> > definitions (e.g. treat them like normal LaTeX hyperrefs) and
> perhaps
> > automatically generating index entries for chunks that should be
> enough
> > to cover what we would require.  (perhaps an automatically inserted
> > "used by" note would be handy to identify the higher level chunk
> into
> > which a sub-chunk is inserted.)
> 
> Eventually, (in particular for the Algebra) I would like to see links
> to  where an identifier is exactly used. In order to generated the
> correct hyperlink, it would be necessary to actually compile the
> spad/aldor  program so that it becomes clear what an identifier like
> "foo" actually means in a certain context.

OK.  That's FAR beyond where I'm at right now - I'm basically looking
to generate some valid LaTeX that may have a couple of useful features.
 Code awareness is a big step beyond that, and what you're talking
about here may need compiler support to retain the information.

> Note that I could locally have defined
> 
> macro foo(x, y) == a + b;
> 
> so "foo" should better point to the corresponding + in the source (or
> at least to its macro definition.

Very useful, I agree - also very difficult.  I would be interested to
know how Tim was planning to deal with these issues - perhaps there are
features in Lisp I don't know about that would make this possible.  I'm
sure heuristics could get fairly close to the correct answer,
especially with simple code, but I'm wary of that for more complex
Lisp.

> As I said a big wish is semantic hyperlinks. (As I understood
> correctly, Tim already referred to that option when he said that
> in lisp all the information about symbols is available.)

Ah, by semantic hyperlinks you mean hyperlink generation based on
source code structure and contents?  OK, that's way beyond where I am
right now - I'm still dealing only with chunk structure.  I like what
you are suggesting, and perhaps it should be the default, but putting
THAT level of machinery into Lisp is more than I'll be able to tackle
right now.  I was figuring to achieve the dhmatrix level + hyperlinks
for chunk references and other standard hyperref features, and as we
get more basic features defined we can build on them.

Just as a point of possible interest, there does exist this system:
http://albert.sourceforge.net/ which may have some features worth
studying when it comes to dealing with lisp code.  Unfortunately it's
GPL, so we probably wouldn't want to use it directly.  (I don't think
we could anyway, probably, but I believe it has some "who-calls"
scanning abilities that would at least be a useful starting point.)

Perhaps we could approach it in this fashion - have the scrips needed
to generate your advanced output be the default, and if testing for
needed machinery fails fall back onto the simpler Lisp+vanilla LaTeX
solution.  Over time, we could migrate features into the Lisp solution
until we can reproduce everything we need.

\start
Date: Fri, 4 May 2007 05:37:08 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Test of a WEB style

--- Ralf Hemmecke wrote:

> >
>
http://portal.axiom-developer.org/Members/hemmecke/document.pdf/download
> >> (unfortunately the graph has to be adjusted---I am too lazy)
> > 
> > Wow.  That's really impressive!  Can you tell me which parts of the
> > graph are off?  I've been staring at it too long and I'm sure
> there's
> > probably something off but I'm not catching it at the moment :-(.
> 
> Oh, if you don't see it then for you probably it is looks OK. In my 
> acroread it cuts off below the Scrn node.

Ah.  Yes, the ps file doesn't translate quite right for inclusion in
pdflatex - that's another reason I go the dvips -> pstopdf route.  I
may track that down someday but IIRC Bill's experience on endpamphlet
was that the dvips route was more robust anyway.  I think that's
probably true, particularly if we ever want to use pstricks in Axiom to
autogenerate plots for figures in pamphlets and external documents:

http://www.ctan.org/tex-archive/graphics/pstricks/contrib/pst-3dplot/doc/pst-3dplot-doc.pdf

> Oh that would be good. I somehow don't really like to change the
> noweb  syntax. Note that some day we might look closer to LEO. I
> don't want to reprogram their ideas only because we then use
> 
>    \begin{chunk} .. \end{chunk}

Delimiters should be trivial.  That was the whole point of the mess I
went through with Lisp macros - <<name>>=...@ and
\begin{chunk}{name}...\end{chunk} are different ONLY in syntax.  If I
did it right we can now generate at compile time a tangle for any
delimiter structure we want.  If necessary, we can probably implement a
function "switch-delimiter-style" to talk to systems that expect noweb
delimiters.

I'm not sure it's worth the trouble to switch the syntax anymore (sorry
Tim), since if I can successfully implement weave in Lisp the extra
processing step will become trivial (indeed, it will happen anyway
either in Lisp or in LaTeX style file processing) and to anybody else
who wants it to it will still look like a regular noweb file (plus,
less typing for delimiters...)

\start
Date: Fri, 4 May 2007 05:42:11 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Re: Desired functionality from noweb

Sorry to reply to myself, but I want to record this idea before I head
for work:

Worth trying would be to make the "<<" and ">>" references I originally
removed from the chunk definition names into active links to the
previous and next chunk as the machine would see it.  Not in chunk
references in code (which should link to the defined chunk) but in the
chunk name in the Listing:  entry.  Wonder if that's legal?  I'll have
to try tonight.

I'll take a stab at a lisp weave function tonight as well.

\start
Date: Fri, 4 May 2007 06:51:28 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Interesting test coverage tool:

http://jsnell.iki.fi/blog/archive/2007-05-03-code-coverage-tool-for-sbcl.html

Perhaps this could be useful someday developing a test framework for
Axiom.

\start
Date: Fri, 4 May 2007 09:47:55 -0500
From: Tim Daly
To: Cliff Yapp, Ralf Hemmecke
Subject: latex and noweb

Cliff, Ralf,

I'd suggest we think about pamphlets as a domain and think about what
operations make sense in the domain.

I'd suggest we move up a level in the design. We need a couple tools
with crisp definitions. This would allow us to decompose and recompose
a pamphlet file. Then we can use these functions to define lisp, spad,
or aldor code that plays with pamphlet files in the same way.

Then we could write "algorithms" to do the various processing.  For
instance, Ralf could write a code-decoration algorithm that
post-processes the nodes that represent code and adds font, color.  In
general, every user could have their own use for pamphlets.

We could run who-calls on the lisp code and add that information as a
special section.

We could write an index node that gets added to the document with
information we preprocess. Thus we could cross-reference with links.

We could decorate code nodes with "next code block" hyperlinks.
Thus you could walk the nodes in "code" order.

We could hyperlink bibliographic entries to other pamphlets or
to outside sources.

We could use these functions interactively either behind the
scenes in a web-serving axiom or directly in user )help requests

Pamphlets() == 
  parse(pamphlet) -> graph

    take a pamphlet structure and generate a graph of that structure.
    the graph would allow us to identify parts of the pamphlet as nodes.
    each node would contain the text and some start/end/type information.
    for example, the preamble, the body, the postamble.
    within these other nodes could be recognized as needed and made
    reachable. this is similar to the document format idea in javascript.

  nodetype(pamphlet, point, list recognizer) -> nodetype

    each node would have a predicate that recognizes the node type
    the nodetype function applies each recognizer and returns the
    type of the next block. the nodetype contains position and
    extent information.

    nodetypes might be both straight latex and axiom nodes, e.g.
      \body node
      \preamble node
      \tableofcontents node
      \section node
      \usepackage node
      \bibliography node
      \chunk node
      \spadcommand node
      etc

  recognize?(typename, pamphlet, point) -> boolean

    we could have recognizers for the whole document, a \usepackage line,
    the \printindex line, the \section line, the \begin{chunk} line, etc.

  hash(pamphlet) -> hashtable

    take a pamphlet structure and develop a hash table of all of the
    code segments. this already exists in gclweb.lisp

  tangle(hashtable, chunkname) -> code

    take a hash of the chunks and a primary name and return the 
    tangled code

  decorate(hashtable, chunkname) -> decoratedcode

    take a chunkname and return the code in latex form with \hyper
    \index, \font, and other decorations in latex form 

  addnode(graph, node) -> graph
  
    take a graph at any node and rewrite the graph at that node.

  deletenode(graph, node) -> graph
  
    take a graph at any node and rewrite the graph at that node.

  replacenode(graph, node, node) -> graph
  
    take a graph at any node and rewrite the graph at that node.
  
  createnode() -> node

    make a new, blank node

  eval(commandnode) -> latex-result

   run a command in a \spadcommand and return the latex result

  eval(graphicscmd) -> ps-result

   run a graphics command and return the \includegraphics and ps

  regress(command,result) -> boolean

   run a command and compare it against the result

\start
Date: Fri, 4 May 2007 11:22:18 -0400
From: Bill Page
To: Ralf Hemmecke, Cliff Yapp
Subject: RE: Test of a WEB style

On May 4, 2007 6:58 AM Ralf Hemmecke wrote:
>
> On 05/04/2007 07:28 AM, Bill Page wrote:
> > On May 4, 2007 12:52 AM C Y wrote:
> >> I have created a sample file of a format for pamphlets
> >> that can be generated without needing the noweb style
> >> file (obviously without many of the major features.) 
> >>
> >

http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.5-hyperref=
tes
t.pdf/download

> >
> > Cliff, I do really like the "look and feel" of this example!
> > It looks pretty and it seems to work.
>
> I appreciate very much the literate work. That is a very good
> example how literate documents should look like.
>
> For your convenience I have embellished it a bit.
>
> =
http://portal.axiom-developer.org/Members/hemmecke/document.pdf/download
>

The first thing I noticed about this is that when viewing it
in Acrobat reader the PDF does not fit the document margins to
the width of the window. Also the default red boxes around the
links look horrible. There is a hyperref option to control that.
See the following line from Cliff's source:

\usepackage[dvips,final,colorlinks=true,linkcolor=blue,pdfstartview==
FitH]{hy
perref}

Also as a matter of personal style I find that I do not like see
large blocks of text with colored backgrounds in PDF and dvi
files. In general I expect these to look more like traditional,
i.e. conservatively-styled, scientific literature. In contrast,
the use of colored background block text in HTML files on the
web seems both more natural and more common. But I freely admit
that this is a style and fashion issue that is subject to
change over time as the format of scientific literature evolves.

But I *do* like the hyper-linking of the identifiers in the
code that you also use extensively in Allprose. I think that
this feature is very important and should not be omitted
simply because some people are motivated to replace noweb
with something written in Lisp.

> (unfortunately the graph has to be adjusted---I am too lazy)
>
> The sources are here.
>
> =
http://portal.axiom-developer.org/Members/hemmecke/cl-web.tar.gz/download=


> Simply type
>
> make pdf
>
> or just
>
> make
>
> for the .ps file.
>
> Look also at the generated .dvi file, adjust your dvi viewer
> and click  on it. I have incorporated the inverse search
> facility.

Perhaps this document looks better in dvi format than it does
in a PDF reader? Unfortunately in other respects most dvi
viewers seem rather deficient compared to PDF. I wonder if
there is any way to incorporate inverse search into a PDF
document generated from LaTeX literate program sources?

On May 4, 2007 8:19 AM Ralf Hemmecke wrote:
> ...
>> C Y wrote:
>> Very nice!  This functionality Ralf might need to be
>> incorporated as a second stage - it needs a lot more of
>> noweb's full strength. I'm shooting for a first cut at a
>> weave functionality entirely defined in Lisp - understanding
>> all of the requirements to handle the extra features is a
>> bigger bite than I have time to chew right now.  Or we
>> could go with this if noweb is present on the system but
>> fall back on the plain Lisp version otherwise.
>
> Oh that would be good. I somehow don't really like to change
> the noweb syntax. Note that some day we might look closer to
> LEO. I don't want to reprogram their ideas only because we
> then use
>
>   \begin{chunk} .. \end{chunk}
>

I agree completely with Ralf on this. While I think the
document you are creating as an example of the kind of target
we want to create from literate program "pamphlet" source is
great, I still do not really understand why you (Cliff and Tim)
want to spend so much time re-inventing noweb in Lisp. noweb
works and it's open source. That is good enough for me to
justify it's use in Axiom. Why not just use it as is - even
internally in Axiom? A commands such as

(1)->  )compile mytest.pamphlet
(1)->  )compile mytest.pamphlet )chunk 'NamedCode'

could be easily made to first use SI::SYSTEM to call notangle
to extract the root or the named code chunk from the pamphlet.
There is no need to write a new Lisp program for this.

I think it would be better incorporate as much of Ralf's
Allprose methods as possible now without changing the
underlying programs.

In the longer term the current approach of web-style markup
in LaTeX documents seems to primitive to me. Rather than
spending resource on re-writing things in Lisp, we should be
looking at more advanced literature programming tools like
Leo. Of course this is an open source project and how you
are motived to spend your time is up to you, but I thought
I would just re-state (once again) more clearly my personal
opinion on this.

\start
Date: Fri, 04 May 2007 11:41:31 -0400
From: Humberto Zuazaga
To: Bill Page
Subject: Re: Test of a WEB style

Bill Page wrote:
>> Look also at the generated .dvi file, adjust your dvi viewer
>> and click  on it. I have incorporated the inverse search
>> facility.
> 
> Perhaps this document looks better in dvi format than it does
> in a PDF reader? Unfortunately in other respects most dvi
> viewers seem rather deficient compared to PDF. I wonder if
> there is any way to incorporate inverse search into a PDF
> document generated from LaTeX literate program sources?

Pdflatex of a document with hyperref should result in clickable internal 
links. I think dvi -> pdf translation mangles these, although ps2pdf may 
be able to preserve hyperrefs if invoked with the -z flag.

See http://arxiv.org/hypertex/

\start
Date: Fri, 4 May 2007 11:41:34 -0400
From: Bill Page
To: Tim Daly
Subject: RE: latex and noweb

On May 4, 2007 10:48 AM Tim Daly wrote:
> 
> I'd suggest we think about pamphlets as a domain and think
> about what operations make sense in the domain.
> 
> I'd suggest we move up a level in the design. We need a
> couple tools with crisp definitions. This would allow us
> to decompose and recompose a pamphlet file. Then we can
> use these functions to define lisp, spad, or aldor code
> that plays with pamphlet files in the same way.

Now, in spite of how I concluded my previous email, I do
very much agree with this approach suggested by Tim! Pamphlet
files (or more generally perhaps literate programs) should
be accessible as objects in Spad and even the Axiom interpreter
even though this creates a potentially complicated bootstrap
problem. The amount of Lisp required to implement this should
be little or even none. As Axiom developers I think we should
first of all begin coding at as high a level as possible,
meaning Spad/Aldor and not always starting from the ground
up.

Keeping the noweb for now and working at this higher level
makes very good sense to me. Eventually we may get to the
situation where something like this could be implemented in
a more integrated manner.

> 
> Then we could write "algorithms" to do the various processing.
> For instance, Ralf could write a code-decoration algorithm
> that post-processes the nodes that represent code and adds
> font, color.  In general, every user could have their own
> use for pamphlets.
>

This is not so different than what is called the "document
object model (dom)" in HTML processing. Dom is what makes it
possible to use Javascript for all the neat things that people
do so easily in dynamic web pages - as Tim suggests in his
pseudo-code below.
 
> We could run who-calls on the lisp code and add that information
> as a special section.
> 
> We could write an index node that gets added to the document
> with information we preprocess. Thus we could cross-reference
> with links.
>

This makes good sense as a kind of evolution of the "database"
concept that underlies the Axiom library.
 
> We could decorate code nodes with "next code block"
> hyperlinks. Thus you could walk the nodes in "code" order.
> 
> We could hyperlink bibliographic entries to other pamphlets
> or to outside sources.
> 
> We could use these functions interactively either behind the
> scenes in a web-serving axiom or directly in user )help
> requests
>

+1 Yes.
 
> 
> 
> Pamphlets() == 
>   parse(pamphlet) -> graph
> 
>     take a pamphlet structure and generate a graph of that
>     structure. the graph would allow us to identify parts of
>     the pamphlet as nodes. each node would contain the text
>     and some start/end/type information.
>     for example, the preamble, the body, the postamble.
>     within these other nodes could be recognized as needed
>     and made reachable. this is similar to the document
>     format idea in javascript.
> ...

I like that.

\start
Date: Fri, 4 May 2007 12:24:03 -0500
From: Tim Daly
To: Cliff Yapp, Ralf Hemmecke, Bill Page
Subject: latex and noweb

Bill, Cliff, Ralf,

I wasn't suggesting that the domain and functions be only implemented
in spad. I was suggesting that the interface be well specified so it
could be implemented in a compatible way in lisp/spad/aldor/perl/whatever.
That would mean that the access and algorithms would be independent of
the machinery. Which means we can think and debate at a much higher level.

\start
Date: Fri, 4 May 2007 10:41:51 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Ralf Hemmecke
Subject: RE: Test of a WEB style

--- Bill Page wrote:

> But I *do* like the hyper-linking of the identifiers in the
> code that you also use extensively in Allprose. I think that
> this feature is very important and should not be omitted
> simply because some people are motivated to replace noweb
> with something written in Lisp.

As I mentioned to Ralf, this can be done incrementally - use the full
power now with noweb, but fall back on simpler output if the tools are
not available.  I am not convinced of the workability of this approach
in general for lisp code - code may generate calls to other code chunks
and that won't be visible until expansion time or possibly even
runtime.  CMUCL's xref might be better in this respect, I'm not sure. 
The SIMPLE approach - string matching inside chunks and looking for def
statements - can also be done inside Lisp.  If there is interest in
that feature it can be explored but it could not be safely concluded
that such a scan coming up negative is proof of no dependency.
 
> > I don't want to reprogram their ideas only because we
> > then use
> >
> >   \begin{chunk} .. \end{chunk}
> >
> 
> I agree completely with Ralf on this. While I think the
> document you are creating as an example of the kind of target
> we want to create from literate program "pamphlet" source is
> great, I still do not really understand why you (Cliff and Tim)
> want to spend so much time re-inventing noweb in Lisp.

Because it reduces the dependency graph of Axiom, and also because it
is much simpler to implement deep integration of pamphlet handling if
that functionality is in Lisp.  I am not reprogramming simply to change
chunk style - I expect if that was all we wanted noweb would be able to
deal with it.  I want to be able to easily handle pamphlets from and in
the Lisp environment without requiring extra external programs, because
each external program means extra demands on system requirements
(compilers, etc.).  

> noweb works and it's open source. That is good enough for me to
> justify it's use in Axiom.

Certainly.  Axiom wouldn't be where it is now without noweb, and I
don't oppose its use as long as it provides us unique benefits.  I want
to implement cl-web for the same reason I am interested in
cl-typesetting - the flexibility and ease of portability of the feature
stack being present in one language space and with one compiler
requirement.  Lisp is a great language for exploring.

> Why not just use it as is - even
> internally in Axiom? A commands such as
> 
> (1)->  )compile mytest.pamphlet
> (1)->  )compile mytest.pamphlet )chunk 'NamedCode'
> 
> could be easily made to first use SI::SYSTEM to call notangle
> to extract the root or the named code chunk from the pamphlet.

To me it's a matter of reducing the dependency tree.  I have no problem
with defining this as the "front line option" if it provides more
important features, but ultimately the more compilers we have to rely
on the more potential problems we introduce.  This may not be an
immediate practical problem but many years down the road who's to say
what we will have available on a wide cross-platform basis?  In the
VERY long term, having everything in one language is simpler and Lisp
has a very long history of being good for very interesting work.  

> There is no need to write a new Lisp program for this.

It's a matter of convenience, and maybe a little bit of speed too - Tim
mentioned wanting to be able to quickly process pamphlets as part of
his writing/debugging cycle.  

> I think it would be better incorporate as much of Ralf's
> Allprose methods as possible now without changing the
> underlying programs.

That's a fine place to start, and doesn't conflict with what is being
done here as far as I can tell.  My code for running notangle for
comparison purposes already does what you suggest in terms of calling
notangle, so that direction is certainly valid.  Getting that working
in GCL would actually be a lot simpler, in all probability.

ALLPROSE would also introduce the requirement of a working Perl
environment though - again, I would like to depend on as few external
tools as possible in order to keep portability as simple as possible. 
For a Windows port using ALLPROSE we would need to get Lisp, C, and
Perl working on any Windows box we wanted to build on.

> In the longer term the current approach of web-style markup
> in LaTeX documents seems to primitive to me. Rather than
> spending resource on re-writing things in Lisp, we should be
> looking at more advanced literature programming tools like
> Leo. Of course this is an open source project and how you
> are motived to spend your time is up to you, but I thought
> I would just re-state (once again) more clearly my personal
> opinion on this.

I have yet to fully resolve the style of academic paper writing and
Leo's model, so I may just not be thinking about it clearly.  Anyway, I
see no reason that we can't use Ralf's markup style for Axiom right now
- we have pamphlets and we can simply treat all of the pamphlets in the
Axiom tree in the same fashion as he treated cl-web, with the addition
of a script to chop off the beginning and end blocks.

Personally, I would like to be able to deal with Axiom as a "typical"
Lisp program, which is one reason for pursuing cl-web.  SLIME,
sb-profile, hunchentoot, McCLIM, etc. are tools I would like to have
available for working with Axiom.  I can understand how this looks
silly to other people, but it is my preference.

\start
Date: Fri, 4 May 2007 14:56:27 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Test of a WEB style

On May 4, 2007 1:42 PM C Y wrote:
> ... 
> Personally, I would like to be able to deal with Axiom as a
> "typical" Lisp program, which is one reason for pursuing
> cl-web.  SLIME, sb-profile, hunchentoot, McCLIM, etc. are
> tools I would like to have available for working with Axiom.
> I can understand how this looks silly to other people, but
> it is my preference.
> 

I am convinced that viewing Axiom as a "Lisp program" has
been very greatly to it's disadvantage given the priorities
of the current generation of programmers.

\start
Date: 04 May 2007 14:06:52 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Test of a WEB style

Bill Page writes:

| On May 4, 2007 1:42 PM C Y wrote:
| > ... 
| > Personally, I would like to be able to deal with Axiom as a
| > "typical" Lisp program, which is one reason for pursuing
| > cl-web.  SLIME, sb-profile, hunchentoot, McCLIM, etc. are
| > tools I would like to have available for working with Axiom.
| > I can understand how this looks silly to other people, but
| > it is my preference.
| > 
| 
| I am convinced that viewing Axiom as a "Lisp program" has
| been very greatly to it's disadvantage given the priorities
| of the current generation of programmers.

I strongly second that.

I would encourage Axiomatizers to view Lisp as just one of the many
possible assembly languages which Axiom can be translated to.
Nothing more.  Axiom will be  better served that way.  

\start
Date: Fri, 4 May 2007 13:56:48 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis, Bill Page
Subject: Re: Test of a WEB style

--- Gabriel Dos Reis wrote:

> Bill Page writes:
> | I am convinced that viewing Axiom as a "Lisp program" has
> | been very greatly to it's disadvantage given the priorities
> | of the current generation of programmers.
> 
> I strongly second that.
> 
> I would encourage Axiomatizers to view Lisp as just one of the many
> possible assembly languages which Axiom can be translated to.
> Nothing more.  Axiom will be better served that way.  

I don't think it's too big of a deal - the main Axiom group is free to
stay with noweb.  The really important part of Axiom is the Algebra
pamphlet files - the rest exists to provide an environment in which to
work with them.  How that environment is provided is less important -
the only problem with that part of the system comes when it breaks.  So
we want the most robust supporting environment we can make.

In the long run, non-Algebra issues should be the minority of the work
on Axiom.  Right now they loom large because a certain minimum
functionality is needed to work at all, but once that functionality is
established we should be able to build on it and look ahead.  Really,
we should have to worry as little as possible about what's below the
Algebra.  (That's another reason I like Lisp, but such discussions have
been had in the past and I doubt anything new will come of them now.)

>From a practical standpoint, I would like to use asdf in a lisp
environment to load parts of Axiom.  I would like to be able to load
and evaluate pamphlets without having to bother about tangling them by
hand, from Lisp.  That's really all I was after.  I will still find it
handy, even if it isn't incorporated into Axiom.

I like Ralf's output - my suggestion would be to integrate that
technique for pamphlet building into the Axiom build machinery. Ralf,
is there a script in ALLPROSE somewhere that will remove everything
upto and including the \begin{document} and also the \end{document}
from pamphlets?  If we have that, we should be able to use your system
with the existing pamphlets.  Alternately, there may be a package for
LaTeX that provides an include command which will do that automatically
- I'll look around tonight.

\start
Date: 04 May 2007 17:34:52 -0500
From: Gabriel Dos Reis
To: list
Subject: Nud and Led properties

  The old parser (and unparser) encodes operator precedence as Nud and
Led properties.  Those properties are set only for symbols.

  The Nud and Led properties are queried through  GET.  There is a
snag: depsys (but not bootsys) renames GET to GETL (which supposedly
works only on list).  In the preparation to conversion to bootsys,
I systematically made appearant the renaming by manually turn all GET
to GETL.  That manual renaming implies no semantics change.

  Now, while investigating some runtime error (that manifests itself
when checking is enabled), it appears that Axiom is querying Nud and
Led properties for things that are lists, in getUserIdentifiersIn.
That is wrong.  Fixed thusly. In addition, this patch uses GET for Nud
and Led queries -- they might bogusly get rewritten by depsys, but
eventually that will go away when we convert to bootsys.


2007-05-04  Gabriel Dos Reis  Gabriel Dos Reis

	* c-doc.boot.pamphlet (checkRecordHash): Use GET instead of GETL.
	(checkTransformFirsts): Likewise.
	* format.boot.pamphlet (formatOpSymbol): Likewise.
	* i-output.boot.pamphlet (exptNeedsPren): Likewise.
	(charyTrouble1): Likewise.
	* postpar.boot.pamphlet (postForm): Likewise.
	* pspad1.boot.pamphlet (format, getOp, formatSelectionOp,
	formatPrefixOp):  Likewise.
	* pspad2.boot.pamphlet (isNewspadOperator): Likewise.
	* i-map.boot.pamphlet (getUserIdentifiersIn): Likewise.
	Non-atomic objects don't have Nud or Led properties.
 
*** c-doc.boot.pamphlet	(revision 19762)
--- c-doc.boot.pamphlet	(local)
*************** checkRecordHash u ==
*** 395,401 ****
            checkDocError ['"Wrong number of arguments: ",form2HtString key]
        else if member(x,'("\spadop" "\keyword")) and (u := checkLookForLeftBrace IFCDR u) and (u := IFCDR u) then
            x := intern checkGetStringBeforeRightBrace u
!           not (GETL(x,'Led) or GETL(x,'Nud)) =>
              checkDocError ['"Unknown \spadop: ",x]
      u := rest u
    'done
--- 395,401 ----
            checkDocError ['"Wrong number of arguments: ",form2HtString key]
        else if member(x,'("\spadop" "\keyword")) and (u := checkLookForLeftBrace IFCDR u) and (u := IFCDR u) then
            x := intern checkGetStringBeforeRightBrace u
!           not (GET(x,'Led) or GET(x,'Nud)) =>
              checkDocError ['"Unknown \spadop: ",x]
      u := rest u
    'done
*************** checkTransformFirsts(opname,u,margin) ==
*** 1125,1131 ****
        STRCONC('"\spad{",SUBSTRING(u,0,k + 1),'"}",SUBSTRING(u,k + 1,nil))
      k := checkSkipToken(u,j,m) or return u
      infixOp := INTERN SUBSTRING(u,j,k - j)
!     not GETL(infixOp,'Led) =>                                     --case 3
        namestring ^= (firstWord := SUBSTRING(u,0,i)) =>
          checkDocError ['"Improper first word in comments: ",firstWord]
          u
--- 1125,1131 ----
        STRCONC('"\spad{",SUBSTRING(u,0,k + 1),'"}",SUBSTRING(u,k + 1,nil))
      k := checkSkipToken(u,j,m) or return u
      infixOp := INTERN SUBSTRING(u,j,k - j)
!     not GET(infixOp,'Led) =>                                     --case 3
        namestring ^= (firstWord := SUBSTRING(u,0,i)) =>
          checkDocError ['"Improper first word in comments: ",firstWord]
          u
*************** checkTransformFirsts(opname,u,margin) ==
*** 1147,1153 ****
        checkDocError ['"Improper first word in comments: ",firstWord]
        u
      prefixOp := INTERN SUBSTRING(u,0,i)
!     not GETL(prefixOp,'Nud) =>
        u ---what could this be?
      j := checkSkipBlanks(u,i,m) or return u
      u.j = char '_( =>                                            --case 4
--- 1147,1153 ----
        checkDocError ['"Improper first word in comments: ",firstWord]
        u
      prefixOp := INTERN SUBSTRING(u,0,i)
!     not GET(prefixOp,'Nud) =>
        u ---what could this be?
      j := checkSkipBlanks(u,i,m) or return u
      u.j = char '_( =>                                            --case 4
*** format.boot.pamphlet	(revision 19762)
--- format.boot.pamphlet	(local)
*************** formatOpSymbol(op,sig) ==
*** 252,258 ****
          [quad,".",sel]
        [quad,".",quad]
      op
!   STRINGP op or GETL(op,"Led") or GETL(op,"Nud") =>
      n = 3 =>
        if op = 'SEGMENT then op := '".."
        op = 'in => [quad,'" ",op,'" ",quad]
--- 252,258 ----
          [quad,".",sel]
        [quad,".",quad]
      op
!   STRINGP op or GET(op,"Led") or GET(op,"Nud") =>
      n = 3 =>
        if op = 'SEGMENT then op := '".."
        op = 'in => [quad,'" ",op,'" ",quad]
*************** formatOpSymbol(op,sig) ==
*** 261,267 ****
        op = 'exquo => op
        [quad,op,quad]
      n = 2 =>
!       not GETL(op,"Nud") => [quad,op]
        [op,quad]
      op
    op
--- 261,267 ----
        op = 'exquo => op
        [quad,op,quad]
      n = 2 =>
!       not GET(op,"Nud") => [quad,op]
        [op,quad]
      op
    op
*** i-map.boot.pamphlet	(revision 19762)
--- i-map.boot.pamphlet	(local)
*************** getUserIdentifiersIn body ==
*** 244,250 ****
    body is [op,:l] =>
      argIdList:= "append"/[getUserIdentifiersIn y for y in l]
      bodyIdList :=
!       not (GETL(op,'Nud) or GETL(op,'Led) or GETL(op,'up))=>
          NCONC(getUserIdentifiersIn op, argIdList)
        argIdList
      REMDUP bodyIdList
--- 244,250 ----
    body is [op,:l] =>
      argIdList:= "append"/[getUserIdentifiersIn y for y in l]
      bodyIdList :=
!       CONSP op or not (GET(op,'Nud) or GET(op,'Led) or GET(op,'up))=>
          NCONC(getUserIdentifiersIn op, argIdList)
        argIdList
      REMDUP bodyIdList
*** i-output.boot.pamphlet	(revision 19762)
--- i-output.boot.pamphlet	(local)
*************** exptNeedsPren a ==
*** 710,716 ****
    atom a and null (INTEGERP a and a < 0)  => false
    key:= keyp a
    key = "OVER" => true  -- added JHD 2/Aug/90
!   (key="SUB") or (null GETL(key,"Nud") and null GETL(key,"Led")) => false
    true
  
  exptSub u == subspan CADR u
--- 710,716 ----
    atom a and null (INTEGERP a and a < 0)  => false
    key:= keyp a
    key = "OVER" => true  -- added JHD 2/Aug/90
!   (key="SUB") or (null GET(key,"Nud") and null GET(key,"Led")) => false
    true
  
  exptSub u == subspan CADR u
*************** charyTrouble1(u,v,start,linelength) ==
*** 1578,1585 ****
    d := GETL(x,'INFIXOP) => charyBinary(d,u,v,start,linelength)
    x = 'OVER  =>
      charyBinary(GETL("/",'INFIXOP),u,v,start,linelength)
!   EQ(3,LENGTH u) and GETL(x,'Led) =>
!     d:= PNAME first GETL(x,'Led)
      charyBinary(d,u,v,start,linelength)
    EQ(x,'CONCAT) =>
      concatTrouble(rest v,d,start,linelength,nil)
--- 1578,1585 ----
    d := GETL(x,'INFIXOP) => charyBinary(d,u,v,start,linelength)
    x = 'OVER  =>
      charyBinary(GETL("/",'INFIXOP),u,v,start,linelength)
!   EQ(3,LENGTH u) and GET(x,'Led) =>
!     d:= PNAME first GET(x,'Led)
      charyBinary(d,u,v,start,linelength)
    EQ(x,'CONCAT) =>
      concatTrouble(rest v,d,start,linelength,nil)
*** postpar.boot.pamphlet	(revision 19762)
--- postpar.boot.pamphlet	(local)
*************** postForm (u is [op,:argl]) ==
*** 266,272 ****
        op':=
          true=> op
          $BOOT => op
!         GETL(op,'Led) or GETL(op,'Nud) or op = 'IN => op
          numOfArgs:= (argl' is [["Tuple",:l]] => #l; 1)
          INTERNL("*",STRINGIMAGE numOfArgs,PNAME op)
        [op',:argl']
--- 266,272 ----
        op':=
          true=> op
          $BOOT => op
!         GET(op,'Led) or GET(op,'Nud) or op = 'IN => op
          numOfArgs:= (argl' is [["Tuple",:l]] => #l; 1)
          INTERNL("*",STRINGIMAGE numOfArgs,PNAME op)
        [op',:argl']
*** pspad1.boot.pamphlet	(revision 19762)
--- pspad1.boot.pamphlet	(local)
*************** format(x,:options) ==
*** 298,305 ****
  getOp(op,kind) ==
    kind = 'Led =>
      MEMQ(op,'(_div _exquo)) => nil
!     GETL(op,'Led)
!   GETL(op,'Nud)
  
  formatDollar(name,p,argl) ==
    name := markMacroTran name
--- 298,305 ----
  getOp(op,kind) ==
    kind = 'Led =>
      MEMQ(op,'(_div _exquo)) => nil
!     GET(op,'Led)
!   GET(op,'Nud)
  
  formatDollar(name,p,argl) ==
    name := markMacroTran name
*************** formatSelection1 [f,x] == formatSelectio
*** 460,466 ****
      formatPren x
   
  formatSelectionOp op ==
!   op is [f,.] and not GETL(f,'Nud) or 
      1000 < pspadBindingPowerOf("right",op) => formatSelectionOp1 op
    formatPren1("formatSelectionOp1",op)
   
--- 460,466 ----
      formatPren x
   
  formatSelectionOp op ==
!   op is [f,.] and not GET(f,'Nud) or 
      1000 < pspadBindingPowerOf("right",op) => formatSelectionOp1 op
    formatPren1("formatSelectionOp1",op)
   
*************** formatPrefix(op,arg,lbp,rbp,:options) ==
*** 512,518 ****
  formatPrefixOp(op,:options) ==
    qualification := IFCAR options
    op=char '" " => format " ="
!   qualification or GETL(op,"Nud") and ^MEMQ(op,$spadTightList) => 
      formatQual(op,qualification) and format " "
    format op
  
--- 512,518 ----
  formatPrefixOp(op,:options) ==
    qualification := IFCAR options
    op=char '" " => format " ="
!   qualification or GET(op,"Nud") and ^MEMQ(op,$spadTightList) => 
      formatQual(op,qualification) and format " "
    format op
  
*** pspad2.boot.pamphlet	(revision 19762)
--- pspad2.boot.pamphlet	(local)
*************** formatPileLine($m,x,newLineIfTrue) ==
*** 561,567 ****
  --======================================================================
  nBlanks m == "STRCONC"/[char('_  ) for i in 1..m]
   
! isNewspadOperator op == GETL(op,"Led") or GETL(op,"Nud")
   
  isTrue x == x="true" or x is '(QUOTE T)
   
--- 561,567 ----
  --======================================================================
  nBlanks m == "STRCONC"/[char('_  ) for i in 1..m]
   
! isNewspadOperator op == GET(op,"Led") or GET(op,"Nud")
   
  isTrue x == x="true" or x is '(QUOTE T)
   
\start
Date: Fri, 04 May 2007 21:57:54 -0400
From: Cliff Yapp
To: list
Subject: Re: Test of a WEB style

C Y wrote:
> Alternately, there may be a package for
> LaTeX that provides an include command which will do that automatically
> - I'll look around tonight.

Not sure if it will fit the bill, but this is what I was thinking of:

ftp://carroll.aset.psu.edu/pub/CTAN/macros/latex/contrib/combine/combine.pdf

\start
Date: Fri, 4 May 2007 22:00:22 -0400
From: Bill Page
To: Tim Daly
Subject: RE: latex and noweb

On May 4, 2007 1:24 PM Tim Daly wrote:

> 
> I wasn't suggesting that the domain and functions be only
> implemented in spad. I was suggesting that the interface be
> well specified so it could be implemented in a compatible
> way in lisp/spad/aldor/perl/whatever. That would mean that
> the access and algorithms would be independent of the
> machinery. Which means we can think and debate at a much 
> higher level.
>

Yes I agree with that approach. However since this is Axiom we
are talking about it makes good sense to me to use Axiom/Spad
concept of "domain" as the underlying model - a domain being
a collection of objects of the same type with a common set of
methods (interface). Whether this is implemented in Spad, Aldor,
Lisp, Boot or some other language for reasons of efficiency or
convenience is of lesser importance.

With respect to possible implementations of an HTML Document
Object Model in Axiom, the following Aldor package by William
Naylor should be of some interest:

http://www.aldor.org/mediawiki/index.php/MathML_library
http://www.cs.bath.ac.uk/~wn/AldorXML/

and Yannis Chicha's work on representing Aldor code in XML form:

http://www.aldor.org/mediawiki/index.php/Aldor_to_XML

Given the work that Arthur Ralfs has recently done on MathML
in Axiom:

http://wiki.axiom-developer.org/MathMLFormat

and the work that Martin Rubey has done with access to the
Axiom database and displaying the information as a browser
web page:

http://wiki.axiom-developer.org/SandBoxHyperDocReplacement

I think it makes good sense to abstract HTML/XML documents as
a domain in Axiom.

Now, extending that to something a little more ambitious -
a document model for literate programs also seems like a
reasonable goal.  A literate program has some structures
(e.g. the chunk structure, and possibly a structure over the
definition and use of identifiers, etc.) over and above the
structure of a conventional documment. As a domain in Axiom,
LiterateProgram (or Pamphlet) objects might provide for example,
the tools necessary to render the content as an XHTML document
with MathML encoding for display in a browser or as a LaTeX
document for printing (weave functionality), as well as tools
to extract code (tangle functionality), plus a number of other
things such Tim has already suggested earlier in this thread.

That might also be useful to define a structure that groups
LiteratePrograms(Pamphlets) together into larger and more
general objects, e.g. "Booklet" as Tim has described elsewhere.

I think a more abstract approach like this would put Axiom in
a good position to eventually exploit higher level literate
programmer tools than just noweb.

Regards,
Bill Page.

PS. Different subject: I found it interesting to read that
Naylor observed the following relation between Axiom (Spad)
and Aldor:

"Factorisation code

Axiom factorisation code (spad code) has been converted into
aldor code. On a small test (38 decimal digits, 5 factors)
the aldor code returns the solution in roughly 1/2 of the time
taken by Axiom."

\start
Date: Fri, 4 May 2007 23:20:21 -0500
From: Tim Daly
To: list
Subject: second life

Is anyone here on second life?

\start
Date: Sun, 6 May 2007 12:22:39 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: cl-web v0.6

For those who are interested, I've uploaded cl-web v0.6 here:

http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.6.tar.gz/download

And the example pdf here:

http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.6.lisp.pdf/download

I've added come style fixes from Kai, and have switched over to using
trivial-utf-8 for the array-to-string and string-to-array operations. 
Testing indicates no appreciable speed loss.

More interestingly, this version has a rudimentary weave ability as
well.  It's not well documented yet but it works well enough to be able
to weave itself, and the pdf above is not a hand made example but the
actual result of weaving cl-web-v0.6.lisp.pamphlet.

The kicker, that I haven't fully solved yet, is the escape character
needed by the listings package to insert tex into code.  This is needed
for the chunk reference links, but the character chosen for escape
can't be used in the code itself.  That's a problem.

I'm using "!" right now, but in order to avoid that being a problem for
weaving this file (after all, for ! to be defined in the code it has to
be in the code, which means it can't be used for that code, etc.) I had
to use code-char in a couple of places.  The more general solution I'm
afraid will have to check proposed escape characters against chunk
contents on the fly to find one that can work for that particular
chunk, but that's a likely killer for speed.  Fortunately I was able to
work around it here, but the more general solution isn't there yet. 
Anyone know of a good way to address this problem?  

\start
Date: Sun, 6 May 2007 12:42:11 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: syntax-highlighting algorithms?

Does anyone know of a good overview of techniques used for keyword
identification and other structural information identification when
doing syntax highlighting?

I know many editors do it but I am not aware of any good description of
the algorithms used.  Recognizing %def operations inside chunks has
some similarities, but I'm hoping there are very fast ways this can be
done.

It finally hit me that escape character identification can and should
be done during the initial chunk scan, where every char needs to be
examined anyway, and stored as part of the chunk structure information.
 Definitions are somewhat more involved, both in recognizing when they
are initially defined and when they are called, and I'm curious as to
what the best techniques are.

\start
Date: Sun, 6 May 2007 17:48:50 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: cl-web v0.6

On May 6, 2007 3:23 PM C Y wrote:
>
> For those who are interested, I've uploaded cl-web v0.6 here:
>
http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.6.tar.gz/d=
own
load
>
> And the example pdf here:
>
http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.6.lisp.pdf=
/do
wnload

It still look good to me. :-)

>
> I've added come style fixes from Kai, and have switched over to
> using trivial-utf-8 for the array-to-string and string-to-array
> operations. Testing indicates no appreciable speed loss.
>
> More interestingly, this version has a rudimentary weave ability
> as well.  It's not well documented yet but it works well enough
> to be able to weave itself, and the pdf above is not a hand made
> example but the actual result of weaving cl-web-v0.6.lisp.pamphlet.

Excellent!

>
> The kicker, that I haven't fully solved yet, is the escape
> character needed by the listings package to insert tex into code.
> This is needed for the chunk reference links, but the character
> chosen for escape can't be used in the code itself.  That's a
> problem.
>

Can I assume that you have read the listings documentation at:

ftp://tug.ctan.org/pub/tex-archive/macros/latex/contrib/listings/listings=
.pd
f

The documentation describes a large number of options for
defining suitable escape characters.

\start
Date: Sun, 6 May 2007 16:29:12 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: cl-web v0.6

--- Bill Page wrote:

> > The kicker, that I haven't fully solved yet, is the escape
> > character needed by the listings package to insert tex into code.
> > This is needed for the chunk reference links, but the character
> > chosen for escape can't be used in the code itself.  That's a
> > problem.
> >
> 
> Can I assume that you have read the listings documentation at:
> 
>
ftp://tug.ctan.org/pub/tex-archive/macros/latex/contrib/listings/listings.pd
> f

That's how I learned about the escapchar option.  I am looking at it
again but I do not see a simple way to specify a multiple character
delimiter for tex mode entrance and exit. escapeinside seems to allow
different characters to start and end but does not (as far as I can
tell) allow multiple characters.

> The documentation describes a large number of options for
> defining suitable escape characters.

It does, but apparently my TeX foo isn't strong enough to spot where
they allow strings instead of single characters.  I'll keep digging...

\start
Date: Sun, 6 May 2007 16:44:20 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: listings oddness

--- Bill Page wrote:

Well, this is weird:

escapeinside={starttex}{endtex}

didn't seem to work, but

escapeinside={(*@}{@*)}

does.

Oh, well.  As long as something works...

\start
Date: Mon, 7 May 2007 03:28:49 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Compiler speed

Using sbcl profiler on Maitin's guessing package I identified
some time sinks:
1) extendLocalLibdb function (which is called at the end of each
   compilation).  This function looks generally bogus -- it tries
   to update libdb.text but is producing garbage (correct libdb.text
   is built later, when databases are rebuild).  Together with
   addPatchesToLongLines this function caused sbcl to run out of
   memory on 512 MB machine (extendLocalLibdb is responsible
   for producing some long lines while memory usage of
   addPatchesToLongLines on sbcl is quadratic with respect to
   its argument).  What matters for time usage is quadratic
   union algorithm which extendLocalLibdb calls on old
   content of libdb.text and new lines.

2) profileRecord function -- conses a lot and takes a lot of time.
   AFAICS the information collected by profileRecord is unused.

3) searchCurrentEnv function -- apparanetly this function implements
   the main compiler symbol table using linear search.

After eliminating the first two problems profiler indicates that
about 60% of execution time goes into linear searches done by
searchCurrentEnv.  I found some possibility for improvement
here: some searches can be easily eliminated.  But ATM I do not see
how to get major improvement without a compiler rewrite: the symbol
table is shared with interpreter and both compiler and interpreter
in many places have dependency on current form of symbol table.
Also, compiler uses symbol table is such a way that it is not
clear if different form of symbol table would be more 
efficient.

\start
Date: Mon, 7 May 2007 03:42:35 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Weird errors

FYI I am now seeing really weird errors: on gentoo machine wh-sandbox
revision 526 gives me multiple build failures -- compile fails
because gcl gets some system errors.  Restarting make gives the
same error.  But when I try to investigate problem and run compile
by hand it works with no error...

Strangly, revision 525 builds with no error on this machine.

BTW: I use here ANSI gcl build from sources included in
build-improvements.  Gentoo provides gcl-2.6.7 but this one fails
quite early trying to link the first Lisp image.

\start
Date: 06 May 2007 21:13:12 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Weird errors

Waldek Hebisch writes:

| FYI I am now seeing really weird errors: on gentoo machine wh-sandbox
| revision 526 gives me multiple build failures -- compile fails
| because gcl gets some system errors.  Restarting make gives the
| same error.  But when I try to investigate problem and run compile
| by hand it works with no error...
| 
| Strangly, revision 525 builds with no error on this machine.
| 
| BTW: I use here ANSI gcl build from sources included in
| build-improvements.  Gentoo provides gcl-2.6.7 but this one fails
| quite early trying to link the first Lisp image.

Try build with --enable-checking -- yes, I know it takes hours.
You'll see many runtime type errors.
The checking is too fined-grained, but it get you somewhere.

\start
Date: 06 May 2007 21:14:15 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Compiler speed

Waldek Hebisch writes:

| Using sbcl profiler on Maitin's guessing package I identified
| some time sinks:
| 1) extendLocalLibdb function (which is called at the end of each
|    compilation).  This function looks generally bogus -- it tries
|    to update libdb.text but is producing garbage (correct libdb.text
|    is built later, when databases are rebuild).  Together with
|    addPatchesToLongLines this function caused sbcl to run out of
|    memory on 512 MB machine (extendLocalLibdb is responsible
|    for producing some long lines while memory usage of
|    addPatchesToLongLines on sbcl is quadratic with respect to
|    its argument).  What matters for time usage is quadratic
|    union algorithm which extendLocalLibdb calls on old
|    content of libdb.text and new lines.
| 
| 2) profileRecord function -- conses a lot and takes a lot of time.
|    AFAICS the information collected by profileRecord is unused.
| 
| 3) searchCurrentEnv function -- apparanetly this function implements
|    the main compiler symbol table using linear search.
| 
| After eliminating the first two problems profiler indicates that
| about 60% of execution time goes into linear searches done by
| searchCurrentEnv.  I found some possibility for improvement
| here: some searches can be easily eliminated.  But ATM I do not see
| how to get major improvement without a compiler rewrite: the symbol
| table is shared with interpreter and both compiler and interpreter
| in many places have dependency on current form of symbol table.
| Also, compiler uses symbol table is such a way that it is not
| clear if different form of symbol table would be more 
| efficient.

Yes.

I'm rewriting part of the compiler in Spad -- it will take some
time before it gets fully functional, but I do hope to make
progress by the summer.

\start
Date: Sun, 6 May 2007 23:27:40 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: listings oddness

Cliff,

On  6, 2007 7:44 PM you wrote:
> 
> Well, this is weird:
> 
> escapeinside={starttex}{endtex}
> 
> didn't seem to work, but
> 
> escapeinside={(*@}{@*)}
> 
> does.
>

I am not sure what you are saying didn't work since in
what you wrote I see the following equivalences:

  starttex == (*@
  endtex ==   @*)

and as you say, that works. If you wanted (for some reason
I don't understand) to use literally `starttex' and `endtex`
as delimiters, I don't see why that wouldn't work. It would
just be weird. Normally it is expected that you would use
something that would be interpreted as a comment in whatever
programming language you are using. If you where writing
Spad or Aldor code than I suppose you might use:

 escapeinside={--}{\^^M}

Ref. the example before "How to gobble characters" on page
53. (But I haven't actually tried this.)
 
> Oh, well.  As long as something works...
> 

Right. :-)

\start
Date: Sun, 6 May 2007 21:00:21 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: listings oddness

--- Bill Page wrote:

> I am not sure what you are saying didn't work since in
> what you wrote I see the following equivalences:
> 
>   starttex == (*@
>   endtex ==   @*)

Correct.
 
> and as you say, that works. If you wanted (for some reason
> I don't understand) to use literally `starttex' and `endtex`
> as delimiters, I don't see why that wouldn't work. It would
> just be weird.

My sentiments exactly :-).

> Normally it is expected that you would use
> something that would be interpreted as a comment in whatever
> programming language you are using.

In this case it doesn't matter - I just need a string that won't show
up in any code we will ever write, because it is used only by the
listings package when processing the LaTeX. In theory it will never
need to be seen by human eyes.

> If you where writing
> Spad or Aldor code than I suppose you might use:
> 
>  escapeinside={--}{\^^M}
> 
> Ref. the example before "How to gobble characters" on page
> 53. (But I haven't actually tried this.)
>  
> > Oh, well.  As long as something works...
> > 
> 
> Right. :-)

What I've got now is functional in testing, and weird enough to be an
unlikely match to any source code, (i.e. low chance of false positive
for marker) so that's probably good enough.

Now to do Tim's cleanups...

\start
Date: Mon, 7 May 2007 00:25:49 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: listings oddness

Cliff,

On May 7, 2007 12:00 AM you wrote:
> ...
> Bill Page wrote: 
> > Normally it is expected that you would use something
> > that would be interpreted as a comment in whatever
> > programming language you are using.
> 
> In this case it doesn't matter - I just need a string that
> won't show up in any code we will ever write, because it is
> used only by the listings package when processing the LaTeX.
> In theory it will never need to be seen by human eyes.

I guess I still don't understand, could you please explain why
you need this again? Is it to create hyperlinked identifies?
have you considered using fancyvrb as described in section
4.15 Interface to fancyvrb, page 39  of the listings.pdf? See
especially morefvcmdparams for how to include hyperref commands.
Of course this is just "in theory", I haven't tried it yet... :-)

> ...

\start
Date: Sun, 6 May 2007 21:38:28 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: listings oddness


--- Bill Page wrote:

> Cliff,
> 
> On May 7, 2007 12:00 AM you wrote:
> > ...
> > Bill Page wrote: 
> > > Normally it is expected that you would use something
> > > that would be interpreted as a comment in whatever
> > > programming language you are using.
> > 
> > In this case it doesn't matter - I just need a string that
> > won't show up in any code we will ever write, because it is
> > used only by the listings package when processing the LaTeX.
> > In theory it will never need to be seen by human eyes.
> 
> I guess I still don't understand, could you please explain why
> you need this again? Is it to create hyperlinked identifies?

Yes, like those in the root note *.  What I'm doing is taking chunk
references in code blocks and converting them into hyperlinks to the
chunk in question.  In order to do this, I need a TeX hyperlink INSIDE
the code listing, which normally doesn't process TeX commands.  To get
it into TeX mode I need to escape temporarily from the code environment
to the TeX environment, which means I need a unique escape string that
won't coincidently appear in the code and cause confusion.

> have you considered using fancyvrb as described in section
> 4.15 Interface to fancyvrb, page 39  of the listings.pdf? See
> especially morefvcmdparams for how to include hyperref commands.
> Of course this is just "in theory", I haven't tried it yet... :-)

I'm not terribly familiar with fancyvrb, so I went with what looked
like the simplest solution that would work ;-).  fancyvrb might indeed
be a better way to go in the long haul - right now escapeinside is
working so I'll leave it be and go for more pressing things.  I'm
certainly open to better proposals.  (Note to self, get linenumber info
working for tangle output...)

\start
Date: 07 May 2007 08:34:14 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Compiler speed

Waldek Hebisch writes:

> Using sbcl profiler on Martin's guessing package I identified
> some time sinks:
> 1) extendLocalLibdb function (which is called at the end of each
>    compilation).  This function looks generally bogus -- it tries
>    to update libdb.text but is producing garbage (correct libdb.text
>    is built later, when databases are rebuild).

I guess you know, but to build libdb.text it is sufficient to say

)lib MYPACKAGE

I don't know at what point which databases are rebuild, but the functionality
of having libdb.text up to date after loading a library is quite important to
me.

Of course, I'm not saying that extendLocalLibdb does anything useful.  I only
noticed that libdb.text is rebuild dynamically, and that's a great feature.

BTW: did anybody try my code from SandBoxHyperDocReplacement ?

\start
Date: Mon, 07 May 2007 10:44:38 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Desired functionality from noweb

>> -n      does not produce a latex wrapper (ALLPROSE provides a
>> wrapper.)
> 
> OK.  That should be doable by locating the \begin{document} tag,
> although we lose any special \usepackage commands if we do...

In ALLPROSE I follow the idea that there are projects. A project is 
roughly something that you put together into a library. The project is 
considered as a whole (although it might consist of several files). A 
library should cover some area of mathematics. It is perhaps that what 
Tim had in mind when he wanted to put everything into just one pamphlet. 
I simply like the approach more if there are several files possible.
Each project allows a .sty file where you can put any additional packages.

Sure, there might be problems with incompatible latex packages when one 
wants to produce a document that contains every such project. The 
combine latex package does not really do what you think. After reading 
the first document it redefines \usepackage to do nothing. So one cannot 
load packages later.

I rather think that it still would be possible to produce crosslinks 
over .dvi file boundaries. (Although I haven't yet produced any proof of 
concept.) That would be enough for me. If there is need to produce a 
5000 pages book that should certainly be doable somehow, but I will not 
invest much time into that idea.

>> -index  produces index information of identifiers
> 
> OK.
> 
>> Although deprecated by Norman Ramsey, I use the
>>
>> <<chunkname>>=
>> ...
>> @ %def Identifier1 Identifier2 ...
>>
>> a lot to get hyperlinks inside code chunks. (For .as files, this %def
>> information is autogenerated by ALLPROSE scripts.)

> In the case of Lisp, I"m not quite sure how to do this in general. 
> MOST of that information can probably be generated, but Lisp macros
> would cause some difficulties in that department.

Also in Aldor it is not easy. If one wants to generate hyperlinks 
without compiling the code, one has to follow some simple conventions so 
that a simple parser could find the relevant parts that should be turned 
into hyperlinks.

>> My way to use noweave is:
>>
>>    1. concatenate all .nw files
>>    2. run noweave -n -index on the concatenated file
>>    3. split the output into .tex files corresponding to the
>>       original .nw files
>>    4. Use a wrapper (which looks approximately like)
>>       \documentclass{article}
>>       \usepackage{allprose}
>>       \begin{document}
>>       \inputAllTexFiles
>>       \end{document}
>>    5. latex/pdflatex/htlatex that wrapper.

> OK.  So when you write .nw files originally they contain no header
> information at all.  I think this gets back to the original discussion
> on how to handle different pamphlets needing different style files
> (sistyle for units, for example.)  I'll need to ponder this one some
> more and see if I can find the package or two designed to handle such
> situations...

But the "units" stuff would form a project in the above mentioned sense. 
So you are free to add any package you like.

>> You find the full story on the website
>>
> http://www.hemmecke.de/aldor/allprose/myalpssu62.html#noweb.NWGFlOZ-RntG3-1
> 
> Out of curiosity Ralf, have you ever benchmarked ALLPROSE?  How long
> would it take do you think to process something really large?

Why should I care? The only thing one has to translate is *one* project 
which should have reasonable size. If it works as I think, then there 
would be some kind of .aux files (of other project) with all the 
information in them to produce hyperlinks into earlier projects in the 
hierarchy. If it takes one day to produce a 5000 pages book, why would 
that be a problem? How often do you think such a compilation is started?

You probably find ALLPROSE slow (I haven't really invested much time 
optimizing it anyway), but for me functionality was/is more important 
than speed. I want to develop code+documentation and don't need to 
produce a .dvi file every minute. Every 15 min should do. You know 
yourself when you have modified big junks of text so that it would be 
wise to recompile. It is a bad idea to re-latex in the middle of writing 
since there are good chances that you get errors, because you have an 
unfinished environment.

>> Note that I don't think that everything should go into one big
>> pamphlet file. I rather like to edit several files which finally
>> produce ONE document.
> 
> I tend to think of it as one pamphlet = 1 "concept", and then pamphlets
> would be bundled like conference proceedings to make larger volumes. 
> It's the combining that makes it interesting.

But why do you think a "proceedings" form is the first thing we should 
think of. If everything is put into html form on a website what 
disadvantage would that have?

>> I think also the little arrows at the top of each code junk are nice,
>> in particular if a code junk continues at some other place. You then
>> see a
>>
>>    +\equiv
>>
>> at the top of the code junk and can click through the code chunks
>> that belong together.
> 
> In essence, links that move the reader through the document in the
> order in which the machine would see the code?  That's not a bad idea. 
> Hmm...

But that is only for chunks that have the same name. They are combined 
together in the order they apper in a .pamphlet. The rest appears as a 
hierarchy. You can click on the chunk names which leads you to the first 
part of its definition.

>> And if you look at the index you will find red and blue entries. I
>> have added a TeX command to modify the noweb.sty so that definitions
>> are shown in red in the index. (Style of course adjustable)
> 
> I'm still a bit unsure of the viability of the language aware part of
> the noweave process when it comes to Lisp, and done right it will
> greatly increase the challenge of programming all of this.  I think the
> right approach here will be to start small and scale up. 

I don't use language awareness in ALLPROSE. Aldor is not build-in into 
noweb anyway and I did not know how to write an appropriate noweb filter
to add language support for Aldor, so my filters start before noweave 
sees the file. Anyway, if we start putting several different languages 
into one pamphlet, it will be difficult to guess the language if there 
is no explicit tag.


>> What I don't like at all with noweb is that one gets a \par after the
>> end of a code chunk if the @ is not followed by a space and %. In
>> noweb the Text can be continued immediately after the ending @\space,
> 
>> but for me that looks terrible. I want to see in the latex source
>> were a code junk ends. A single @ doesn't catch the eye so quickly.
> 
> I always assumed that the working literate programming style wouldn't
> have code actually inline with text - are you saying you DO want to use
> that style and don't want the \par command?

Well, let's not discuss it here. That is not a big issue. It simply says 
that after a code chunk there always starts a new paragraph unless you 
end the code chunk via

@ %
New text starts here and is not indented

or

@ New text starts here and is not indented

> Just as a point of possible interest, there does exist this system:
> http://albert.sourceforge.net/ which may have some features worth
> studying when it comes to dealing with lisp code.  Unfortunately it's
> GPL, so we probably wouldn't want to use it directly.  (I don't think
> we could anyway, probably, but I believe it has some "who-calls"
> scanning abilities that would at least be a useful starting point.)

I don't care much about LISP. I want to be language independent. And 
perhaps add some features to support programming in Aldor. LISP is an 
assembly language for me.

> Perhaps we could approach it in this fashion - have the scrips needed
> to generate your advanced output be the default, and if testing for
> needed machinery fails fall back onto the simpler Lisp+vanilla LaTeX
> solution.  Over time, we could migrate features into the Lisp solution
> until we can reproduce everything we need.

Note that TeX can already do a lot with respect to hyperlinks. On just 
has to put appropriate tags into the source. Look at what I have done in 
your cl-web pamphlet.

Very important for me is that the pamphlet -> latex routine respects 
line numbers as noweave does. Every documentation chunk should be 
wrapped by something like \begin{docchunk} ... \end{docchunk} and every 
code chunk by \begin{codechunk}{name} ... \end{codechunk} (or something 
similar. If LaTeX sees that and has an appropriate .sty file (like 
noweb.sty) then pretty much can be done by TeX itself. Appropriate tags 
are important.

\start
Date: Mon, 07 May 2007 12:00:29 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Test of a WEB style

On 05/04/2007 02:37 PM, C Y wrote:
> --- Ralf Hemmecke wrote:
> 
> http://portal.axiom-developer.org/Members/hemmecke/document.pdf/download
>>>> (unfortunately the graph has to be adjusted---I am too lazy)
>>> Wow.  That's really impressive!  Can you tell me which parts of the
>>> graph are off?  I've been staring at it too long and I'm sure
>> there's
>>> probably something off but I'm not catching it at the moment :-(.
>> Oh, if you don't see it then for you probably it is looks OK. In my 
>> acroread it cuts off below the Scrn node.
> 
> Ah.  Yes, the ps file doesn't translate quite right for inclusion in
> pdflatex - that's another reason I go the dvips -> pstopdf route.

Wrong. The .ps file has no hyperlinks so they don't make it into the .pdf.

   I
> may track that down someday but IIRC Bill's experience on endpamphlet
> was that the dvips route was more robust anyway.  I think that's
> probably true, particularly if we ever want to use pstricks in Axiom to
> autogenerate plots for figures in pamphlets and external documents:

If you know how to convert the pstricks stuff into .html ... Note, that 
I finally would like to have a graph with links. Everything that is not 
able to easily produce such links is out of the game.

I know that there is a package that comes with the beamer style
http://latex-beamer.sourceforge.net/
It seems quite powerful and can produce .pdf.
I haven't, however, experimented with that very much.

\start
Date: 07 May 2007 12:14:35 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Test of a WEB style

Ralf Hemmecke writes:

> If you know how to convert the pstricks stuff into .html ... Note, that I
> finally would like to have a graph with links. Everything that is not able to
> easily produce such links is out of the game.

I use xy by Kris Rose and Ross Moore and I am very happy with it.  There is no
problem at all with pdf or ps generation (including hyperlinks), that's the
reason why I dropped pstricks.  However, I must admit that the language used by
xy is a bit obscure.

Another thing: contrary to Ralf's opinion, I do think that there is a (minor)
problem with usepackages.  The most important thing to me is the HyperDoc idea,
thus it is very likely wise to use only certain packages within the
addescription environment.  (Of course, one could usepackage the appropriate
when generating the latex source from the addescription chunk, but I guess that
this will be a little painful.)  On the other hand, I do believe that we should
give the documentation authors as much freedom as possible, thus it's probably
worth going through a bit of pain.

\start
Date: Mon, 07 May 2007 12:49:58 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: latex and noweb

On 05/05/2007 04:00 AM, Bill Page wrote:
> On May 4, 2007 1:24 PM Tim Daly wrote:
> 
>> I wasn't suggesting that the domain and functions be only
>> implemented in spad. I was suggesting that the interface be
>> well specified so it could be implemented in a compatible
>> way in lisp/spad/aldor/perl/whatever. That would mean that
>> the access and algorithms would be independent of the
>> machinery. Which means we can think and debate at a much 
>> higher level.
>>
> 
> Yes I agree with that approach. However since this is Axiom we
> are talking about it makes good sense to me to use Axiom/Spad
> concept of "domain" as the underlying model - a domain being
> a collection of objects of the same type with a common set of
> methods (interface). Whether this is implemented in Spad, Aldor,
> Lisp, Boot or some other language for reasons of efficiency or
> convenience is of lesser importance.

Oh, I like that. I just somehow fear that the current input does not 
have enough structure. LaTeX code comes with too few tags. For example, 
we write

\section{...}

instead of

\begin{section}{...}

\end{section}

Maybe these are little details, but eventually we must think about a 
more structured input format.

> With respect to possible implementations of an HTML Document
> Object Model in Axiom,

[snip] ...

Maybe, also tex4ht helps a lot to produce reasonable XHTML+MathML out of 
a latex document.

> Now, extending that to something a little more ambitious -
> a document model for literate programs also seems like a
> reasonable goal.

Yes. Would it be so hard to define a XML schema for literate programs? 
(I have no idea.)

Anyway, most of us don't want to edit XML, but rather LaTeX, so what 
exacly should become the input format? XML has more structure, LaTex is 
a bit more common for us. We surely want to restrict a bit. For example, 
removing all stuff outside \begin{document}...\end{document} to make 
pamphlets combinable.

\start
Date: Mon, 07 May 2007 13:09:32 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Test of a WEB style

>> http://portal.axiom-developer.org/Members/hemmecke/document.pdf/download

> Also as a matter of personal style I find that I do not like see
> large blocks of text with colored backgrounds in PDF and dvi
> files.

No problem. The coloring is completely optional. Look into the sources

http://portal.axiom-developer.org/Members/hemmecke/cl-web.tar.gz/download

there is a section in the preample that says "optional".
Similarly, you can adjust in ALLPROSE. If you don't say "make colored" 
you won't get the colors (No colors is the default).

>> Look also at the generated .dvi file, adjust your dvi viewer
>> and click  on it. I have incorporated the inverse search
>> facility.
> 
> Perhaps this document looks better in dvi format than it does
> in a PDF reader? Unfortunately in other respects most dvi
> viewers seem rather deficient compared to PDF.

I use xdvik http://xdvi.sourceforge.net/ .

> I wonder if
> there is any way to incorporate inverse search into a PDF
> document generated from LaTeX literate program sources?

I've never heard about that being possible. Would be nice, but if you 
then use acroread, that is a pain, since acroread does not automatically 
reload a file that changed on disk. (Only my experience?)

\start
Date: Mon, 7 May 2007 13:54:45 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Compiler speed

Martin Rubey wrote:
> Waldek Hebisch writes:
> 
> > Using sbcl profiler on Martin's guessing package I identified
> > some time sinks:
> > 1) extendLocalLibdb function (which is called at the end of each
> >    compilation).  This function looks generally bogus -- it tries
> >    to update libdb.text but is producing garbage (correct libdb.text
> >    is built later, when databases are rebuild).
> 
> I guess you know, but to build libdb.text it is sufficient to say
> 
> )lib MYPACKAGE
> 
> I don't know at what point which databases are rebuild, but the functionality
> of having libdb.text up to date after loading a library is quite important to
> me.
> 
> Of course, I'm not saying that extendLocalLibdb does anything useful.  I only
> noticed that libdb.text is rebuild dynamically, and that's a great feature.
> 

extendLocalLibdb is called by )lib command.  However I wonder if it
extendLocalLibdb is really working for you: IIRC correctly you had
problem with addPatchesToLongLines and to correct extendLocalLibdb
we first have to correct addPatchesToLongLines (probably remove, but
I have to check consequences).  Moreover, extendLocalLibdb tries to
remove old information but my impression is that this works only
partially (I expect that after multiple recompilations you may
accumulate out of date information).

One more thing: extendLocalLibdb is called at the end of compilation,
so libdb.text should be rebuild even if you do not issue )lib command.

I have just commited speedup patch: it disables libdb.text updates
during build (as I wrote this is useless because we generate up to
date libdb.text later), but the installed compiler should work as
before.

\start
Date: Mon, 07 May 2007 13:58:56 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Test of a WEB style
Cc: Gabriel Dos Reis

 > I like Ralf's output - my suggestion would be to integrate that
 > technique for pamphlet building into the Axiom build machinery. Ralf,
 > is there a script in ALLPROSE somewhere that will remove everything
 > upto and including the \begin{document} and also the \end{document}
 > from pamphlets?  If we have that, we should be able to use your system
 > with the existing pamphlets.

If you can still wait a month or two I might be doing it myself.
Although that stuff is pretty much independent of the current building 
machinery, I don't quite know from which branch I should branch 
build-improvements or wh-sandbox? Suggestions?

\start
Date: Mon, 7 May 2007 05:12:02 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Desired functionality from noweb

--- Ralf Hemmecke wrote:

> >> -n      does not produce a latex wrapper (ALLPROSE provides a
> >> wrapper.)
> > 
> > OK.  That should be doable by locating the \begin{document} tag,
> > although we lose any special \usepackage commands if we do...
> 
> In ALLPROSE I follow the idea that there are projects. A project is 
> roughly something that you put together into a library. The project
> is  considered as a whole (although it might consist of several 
> files). A library should cover some area of mathematics. It is
> perhaps that what Tim had in mind when he wanted to put everything
> into just one pamphlet. 

I think we need to firm up what we want to do about such structuring as
a project before we commit to one particular style - this will have a
major impact on how people write documents for Axiom and as such is not
something to be decided lightly.

> I simply like the approach more if there are several files possible.
> Each project allows a .sty file where you can put any additional
> packages.

I'm trying to reconcile that idea with an "Axiom Journal" style of
writing where people may do shorter papers on a single topic.  Perhaps
if we pre-define projects for specific topics and have the style file
prepared for each topic, people could write for that "project" or
"topic".  In such a case MSC2000 might make a lot of sense as a
framework within which to define "projects".

> Sure, there might be problems with incompatible latex packages when
> one wants to produce a document that contains every such project. The

> combine latex package does not really do what you think. After
> reading the first document it redefines \usepackage to do nothing. So
> one cannot load packages later.

Perhaps the thing to do then is meet these issues as they arise.  If
we're going to break new ground in this respect we may have to upgrade
the tools on the LaTeX side as well.  If someone is writing for a
project and wants to use a particular package not already in the
project's style file we can resolve it on a case by case basis.

> I rather think that it still would be possible to produce crosslinks 
> over .dvi file boundaries. (Although I haven't yet produced any proof
> of concept.) That would be enough for me. If there is need to produce
> a 5000 pages book that should certainly be doable somehow, but I will
> not invest much time into that idea.

Fair enough.  I envisioned it more as volumes corresponding to toplevel
MSC categories - kind of the "Encyclopedia of Mechanized Mathematics"
or some such.

> > In the case of Lisp, I"m not quite sure how to do this in general. 
> > MOST of that information can probably be generated, but Lisp macros
> > would cause some difficulties in that department.
> 
> Also in Aldor it is not easy. If one wants to generate hyperlinks 
> without compiling the code, one has to follow some simple conventions
> so that a simple parser could find the relevant parts that should be
> turned into hyperlinks.

Ugh.  I wonder how much work it would be to get the SPAD compiler to
support what would be needed to properly support that automatically.
 
> But the "units" stuff would form a project in the above mentioned
> sense. So you are free to add any package you like.

That does make sense, but if we set up "projects" I would like to see
it done in such a way that naturally leads authors to finding the
"correct" project for a particular topic - otherwise, we may wind up
with several very similar "projects" that really should be part of the
same project but are still incompatible.  That's a fuzzy definition of
the problem, I'll have to think about how to state it better.

> > Out of curiosity Ralf, have you ever benchmarked ALLPROSE?  How
> > long would it take do you think to process something really large?
> 
> Why should I care? The only thing one has to translate is *one*
> project which should have reasonable size. If it works as I think,
> then there would be some kind of .aux files (of other project) with
> all the information in them to produce hyperlinks into earlier
> projects in the hierarchy. 

I am thinking about build times for Axiom.  Tim has stated that the
goal is to treat building documentation on an equal footing with
building machine binaries, so build time is impacted by documentation
decisions.  That's the whole reason Waldek proposed and implemented the
finite-state approach to tangle, and when I asked the list if it was
really necessary the consensus was yes.  

> If it takes one day to produce a 5000 pages book, why
> would that be a problem? How often do you think such a compilation is
> started?

Every time someone builds all of Axiom from source.  That happens
fairly frequently, and IMHO it should.

> You probably find ALLPROSE slow (I haven't really invested much time 
> optimizing it anyway), but for me functionality was/is more important
> than speed.

I haven't benchmarked it - I was just curious.  After spending all the
time generalizing and writing up the optimized tangle operation such
things come to mind ;-).

> I want to develop code+documentation and don't need to 
> produce a .dvi file every minute. Every 15 min should do. You know 
> yourself when you have modified big junks of text so that it would be
> wise to recompile. It is a bad idea to re-latex in the middle of
> writing since there are good chances that you get errors, because you
> have an unfinished environment.

Tim, that's a good question to direct your way - how often do you
re-latex your document?

> > I tend to think of it as one pamphlet = 1 "concept", and then
> > pamphlets would be bundled like conference proceedings to make
> > larger volumes.  It's the combining that makes it interesting.
> 
> But why do you think a "proceedings" form is the first thing we
> should think of.

Well, a journal then.  There has been serious talk of an Axiom Journal
and presumably the idea would be that such papers would end up as part
of the core system.  I don't know what the state of that idea is at the
moment (I expect it's on hold until Axiom is a reasonable platform for
such an effort) but I think in the long term it has merit.

> If everything is put into html form on a website what 
> disadvantage would that have?

Compared to LaTeX+pdf html is (at the moment) not as convenient for
mathematical output.  Since Axiom is intended to support advanced
mathematical research robust mathematical typesetting/output is a must.

> > In essence, links that move the reader through the document in the
> > order in which the machine would see the code?  That's not a bad
> > idea.  Hmm...
> 
> But that is only for chunks that have the same name. They are
> combined together in the order they apper in a .pamphlet. The rest
> appears as a hierarchy.

?  I'm a bit confused.  I thought chunk names had to be unique within a
pamphlet.

> I don't use language awareness in ALLPROSE. Aldor is not build-in
> into noweb anyway and I did not know how to write an appropriate
> noweb filter to add language support for Aldor, so my filters start
> before noweave sees the file. Anyway, if we start putting several
> different languages into one pamphlet, it will be difficult to guess
> the language if there is no explicit tag.

Agreed - I think it would be a bad idea to have more than one language
per pamphlet.  If we must do so an explicit tag for language is needed.

> I don't care much about LISP. I want to be language independent. And 
> perhaps add some features to support programming in Aldor. LISP is an

> assembly language for me.

Code highlighting and definition searching is inherently language
dependent.  The rest, I agree, has no need to be aware of any
particular language.

> Very important for me is that the pamphlet -> latex routine respects
> line numbers as noweave does. Every documentation chunk should be 
> wrapped by something like \begin{docchunk} ... \end{docchunk} and
> every code chunk by \begin{codechunk}{name} ... \end{codechunk} (or
> something similar.

Code chunks I've got wrapped in listing environments, but why do you
want the documentation chunks identified?  I always viewed pamphlet
files as a latex document with chunks embedded in it - what is the
advantage of chunking up the documentation as well?

\start
Date: 07 May 2007 14:14:28 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Compiler speed

Waldek Hebisch writes:

> extendLocalLibdb is called by )lib command.  However I wonder if it
> extendLocalLibdb is really working for you: IIRC correctly you had
> problem with addPatchesToLongLines and to correct extendLocalLibdb
> we first have to correct addPatchesToLongLines (probably remove, but
> I have to check consequences).  Moreover, extendLocalLibdb tries to
> remove old information but my impression is that this works only
> partially (I expect that after multiple recompilations you may
> accumulate out of date information).

The point is not so much that libdb.text is (re)built after (re)compilation.
Rather, far example with our species (combinat) project, I compile everything
with aldor (without ever starting axiom), but when I start axiom and say )lib
MYLIB, libdb.text contains all the necessary information.  And that's in my
opinion something extremely powerful.

> I have just commited speedup patch: it disables libdb.text updates during
> build (as I wrote this is useless because we generate up to date libdb.text
> later), but the installed compiler should work as before.

Unfortunately, I do not have the time to check this now.  Maybe you could
compile some mini domain or package, quit axiom, delete libdb.text, start
axiom, )lib MINIDOMAIN, and check whether HyperDoc finds MINIDOMAIN, or,
hopefully equivalently, libdb.text contains the necessary information.

\start
Date: 07 May 2007 07:49:58 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Test of a WEB style
Cc: Ralf Hemmecke

Martin Rubey writes:

| Ralf Hemmecke writes:
| 
| > If you know how to convert the pstricks stuff into .html ... Note, that I
| > finally would like to have a graph with links. Everything that is not able to
| > easily produce such links is out of the game.
| 
| I use xy by Kris Rose and Ross Moore and I am very happy with it.

If possible, please go with Xypic.

\start
Date: 07 May 2007 07:51:01 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Test of a WEB style

Ralf Hemmecke writes:

|  > I like Ralf's output - my suggestion would be to integrate that
|  > technique for pamphlet building into the Axiom build machinery. Ralf,
|  > is there a script in ALLPROSE somewhere that will remove everything
|  > upto and including the \begin{document} and also the \end{document}
|  > from pamphlets?  If we have that, we should be able to use your system
|  > with the existing pamphlets.
| 
| If you can still wait a month or two I might be doing it myself.
| Although that stuff is pretty much independent of the current building
| machinery, I don't quite know from which branch I should branch
| build-improvements or wh-sandbox? Suggestions?

Unless you want the new algebra boostrap right now, I would suggest
you branch from build-improvements.

\start
Date: Mon, 7 May 2007 05:57:37 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis, Martin Rubey
Subject: Re: Test of a WEB style
Cc: Ralf Hemmecke


--- Gabriel Dos Reis wrote:

> Martin Rubey writes:
> | I use xy by Kris Rose and Ross Moore and I am very happy with it.
> 
> If possible, please go with Xypic.

I tried making a hyperlinked plot with Xypic a long while back for the
units work.  It succeeded, but the rendering in pdf form was hideously
slow.  Not sure how it would do with 3d plotting - perhaps it does
better without hyperlinks.

In theory, it doesn't have to be an either/or situation - both could be
"rendering" targets for the plotting routines.

\start
Date: Mon, 7 May 2007 10:07:22 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Desired functionality from noweb

Cliff,

re: stripping headers

It should be reasonably straightforward (except that there is no such
thing as a simple job) to write the function

 latex(pamphlet,recognizers) -> graph

provided we follow the latex style for chunks. 

Foreach '\' in pamphlet
 Do
  if recognize()
   then updategraph()
 until recognized

where recognize() returns true if it finds tag to handle
and updategraph adds the tagged info to the graph.

I already do that structurally in gclweb so let me take a crack
at generalizing it to parse the latex to a graph.

Once that happens it would be straightforward to remove the headers.

\start
Date: Mon, 7 May 2007 10:26:33 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Desired functionality from noweb

Cliff,

I'm not sure I'm the best example of concerns about build times
as my use of literate programming isn't typical.

re: build times

My normal way of working is to have 2 windows open. 
The left window is emacs split into 2 buffer panes (file and shell)
The right window is xdvi pointing at my current .dvi output.

I make a change in one of the emacs panes which is editing my
pamphlet file. I switch to the emacs shell pane, type 

make -f Makefile.whatever

and then switch back to continue editing.

The Makefile.whatever runs notangle to rebuild the source,
compile the source, and run the test cases. It also runs
latex and rebuilds the .dvi file. Note that xdvi will
automatically reread the .dvi file if it gets the focus.

Thus, I compile/test/document about once every 10 lines or so.
Breakage in either the program or the latex is immediate.

re: build times, axiom system builds

I am constantly rebuilding axiom. I have rebuilt axiom about
20 times this past weekend, slowly trying to creep up on a
bug that is causing the build to fail as well as merging and
checking build changes. Every build is a full build because
I need to make sure that it all works. 

One example of this kind of breakage is that you can no longer
build axiom from the repository. There is a time bomb in the
diagrams.sty package I used to document clifford.spad which
will stop the build and request that you fetch a new copy of
the diagrams.sty file. This broke and was fixed back in the
first week of this year. I'm surprised that no-one complained.

\start
Date: Mon, 7 May 2007 10:59:58 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Desired functionality from noweb

Cliff,

Another concern is the ability to drag-and-drop a pamphlet
onto axiom and have it "just work".

We need to have an "adaptive" rather than "restrictive" approach,
I think. That is, we need to be able to adapt to xy vs xypic
as long as it doesn't break things. We need to be able to handle
single vs multiple pamphlets. 

All of this can evolve with time, as the requirements arise.

But it will be most helpful if we can rise up out of the dust
of particular syntax and define the algorithms in terms of
functions as I mentioned earlier. Then the algorithms can be
expressed as graph-to-graph transforms and the low level details
can be handled by the pamphlet->graph and graph->pamphlet functions.

Graph-to-graph transformations occur naturally in lisp.
Any graph can be easily expressed in lisp list notation
so any algorithm is just a manipulation of that list.

Better still the lisp list graph can executed as well as manipulated.

Thus, given the latex-to-lisp tranformation

  \section -> (SECTION

and a definition of a SECTION function means that the graph
can have both structural and execution semantics.

\start
Date: Mon, 7 May 2007 09:24:28 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Desired functionality from noweb


--- Tim Daly wrote:

> Cliff,
> 
> Another concern is the ability to drag-and-drop a pamphlet
> onto axiom and have it "just work".

That will be heavily involved with the details of what platform, what
tools are needed by the pamphlet, etc.  Abilities that would be nice
for pamphlets but aren't supported by the existing tools are going to
be problematic.  (Compiler support for pamphlet locations in Lisp as a
replacement for the %def hack, for example.  I suppose in theory there
could be some kind of language independent mechanism implemented by all
compilers to store that information automatically in a universal
format...)

> We need to have an "adaptive" rather than "restrictive" approach,
> I think. That is, we need to be able to adapt to xy vs xypic
> as long as it doesn't break things. We need to be able to handle
> single vs multiple pamphlets. 

Perhaps I should take a step back and make some "use cases" of things
so I have a better sense of how this is supposed to work.  I have a
feeling I might be making some fairly fundamental assumptions that are
not particularly valid.

> All of this can evolve with time, as the requirements arise.
> 
> But it will be most helpful if we can rise up out of the dust
> of particular syntax and define the algorithms in terms of
> functions as I mentioned earlier. Then the algorithms can be
> expressed as graph-to-graph transforms and the low level details
> can be handled by the pamphlet->graph and graph->pamphlet functions.

That sounds good but I'll need to think about it some more to
understand what it really implies.

> Graph-to-graph transformations occur naturally in lisp.
> Any graph can be easily expressed in lisp list notation
> so any algorithm is just a manipulation of that list.
> 
> Better still the lisp list graph can executed as well as manipulated.
> 
> Thus, given the latex-to-lisp tranformation
> 
>   \section -> (SECTION
> 
> and a definition of a SECTION function means that the graph
> can have both structural and execution semantics.

Sorry for being dense, but can you illustrate what the possible
consequences of that would be?

\start
Date: Mon, 7 May 2007 21:01:53 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Bootstrap documentation.

I want to include some documentation of current algebra bootstrap
used in wh-sandbox.  Below is what I have now.  Any comment
(or things that need better explanation)?


\section{Bootstrap problem}

Current Axiom compiler compiles each constructor (category, domain
or package) separately.  In order to perform type check Axiom
needs type information from other constructors.  To collect
type information about constructor Axiom must compile it.
This creates bootstrap problem: in order to compile a constructor
one must first compile many other constructors.

In principle bootstrap problem could be avoided organizing algebra
into layers, so that layer $0$ is independent of other layers and
each higher layer depends only on lower layers.  However current
Axiom algebra contains a lot of cyclic dependencies: substantial
part of algebra depends on [[Integer]] and [[Integer]] has rich structure
and depends on many categories which in turn depend on Integer.

ATM this bootstrap problem has no proper resolution: Axiom
avoids it simply using type information collected in the past
and stored in databases ([[interp.daase]] and [[category.daase]]).
This solution means that attempt to change signature of any exported
operation is likely to cause build failure.

Using type information stored in databases solve only part of
bootstrap problem: internally Axiom types are represented by
executable code and sometimes Axiom needs to load actual compiled
code.  The exact rules telling when Axiom needs compiled code
and when it is enough to have info in databases are unknown.
Axiom needs to load categories given as argument to [[Join]]
(because [[Join]] is implemented as runtime operation).  It
seems that Axiom also needs to load a category given as argument
to contructors if this category itself has arguments.

During normal compilation Axiom tries to optimize (expand inline)
calls to operation from core domains (listed in
[$optimizableConstructorNames]] variable).  To do this Axiom
has to load those domains.  This optimization in the past required
keeping compiled Lisp corresponding to core domains (in fact, what
was stored was a cut breaking cycles involving core domains).
Currently Axiom has special flag [[$bootstrapDomains]] domains to
disables this optimization.

Even after using [[$bootstrapDomains]] flag there are still
cyclic load dependencies caused by constructor arguments, but
those problem are resolved using [[$bootStrapMode]] flag
which causes relaxed type checking and skips executable parts
of categories.

The final process looks as follows. First, categories are
topologicaly sorted with respect to [[Join]] (arguments to
[Join]] must be compiled before category using [[Join]]).
This order is slightly tweaked to avoid problems due to
constructor parameters.  In the first pass categories
are compiled using [[$bootStrapMode]] set to [[t]].  This
makes compiled code of categories available to second pass.
In the second pass categories and core domains are
compiled setting [[$bootstrapDomains]] to [[t]].  We have
to compile categories because categories may have associated
default domain which also may be loaded.  We also compile
few domains which we are needed for unknown reasons (if we
skip them the build will fail).  In the third pass we
compile categories and core domains in normal mode.
Finally, we compile the rest of algebra in alphabetical order
(in fact, we let make choose the order, but the list we give is
sorted alphabetically, and make processes it in order).

\section{Adding new constructor}

Adding a new constructor is different than the above process.  It is
easier because new constructor can freely use function provided
by standard algebra.  OTOH information about new constructors
is absent from Axiom databases, so cyclic dependencies between new
constructors have no easy solution.  However if one is adding
mutually dependent constructors without cyclic dependencies
the solution is easy: compile all dependent constructors in
a single Axiom image, using apropriate order.  The [[guess-pkg]]
target ilustrates this method.OA  

\start
Date: 07 May 2007 21:49:18 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Bootstrap documentation.

Dear Waldek,

Waldek Hebisch writes:

> I want to include some documentation of current algebra bootstrap used
> in wh-sandbox.  Below is what I have now.  Any comment (or things that
> need better explanation)?

This is GREAT!

I just read your overview, and believe that I understood.  I threw in
some articles and spelled out OTOH and ATM, since when I first read them
they gave me a headache.  Furthermore, I removed some parentheses, since
I dislike them.  I tried not to change linebreaks, so emacs ediff or
similar should make cherry picking easy.

I'm not English native, so please correct me if where I'm wrong.

I guess the whole bootstrap problem would go away with "extend"...  What
a pity!

Martin

\section{The bootstrap problem\dots}

The current Axiom compiler compiles each constructor (category, domain
or package) separately.  In order to perform type checking Axiom
needs type information from other constructors.  To collect
type information about a constructor Axiom must compile it.
This creates a bootstrap problem: in order to compile a constructor
one must first compile many other constructors.

In principle the bootstrap problem could be avoided by organizing algebra
into layers, so that layer $0$ is independent of other layers and
each higher layer depends only on lower layers.  However, the current
Axiom algebra contains a lot of cyclic dependencies: for example, a substantial
part of algebra depends on [[Integer]], but [[Integer]] has a rich structure
and depends on many categories which in turn depend on [[Integer]].

\section{\dots and its solution}

At the moment this bootstrap problem has no proper resolution: Axiom
avoids it simply using type information collected in the past
and stored in databases [[interp.daase]] and [[category.daase]].
This solution means that any attempt to change the signature of an exported
operation is likely to cause build failure.

Using the type information stored in databases solves only part of
the bootstrap problem: internally, Axiom types are represented by
executable code and sometimes Axiom needs to load actual compiled
code.  The exact rules telling when Axiom needs compiled code
and when it is enough to have info in databases are unknown.
Axiom needs to load categories given as argument to [[Join]],
because [[Join]] is implemented as a runtime operation.  It
seems that Axiom also needs to load a category given as an argument
to a contructor if this category itself has arguments.

During normal compilation Axiom tries to optimize (i.e., expand inline)
calls to operations from core domains, which are listed in the
[$optimizableConstructorNames]] variable.  To do this, Axiom
has to load these domains.  In the past, this optimization required
keeping compiled Lisp corresponding to core domains.  In fact, what
% I don't understand the following half-sentence. Furthermore, it is not
% clear to me what is past and what cis current behaviour.
was stored was a cut breaking cycles involving core domains.
Currently Axiom has a special flag [[$bootstrapDomains]] to
disable this optimization.

Even after using the [[$bootstrapDomains]] flag there are still
cyclic load dependencies caused by constructor arguments, but
those problem are resolved using the [[$bootStrapMode]] flag,
which causes relaxed type checking and skips executable parts
of categories.

The final process looks as follows: first, categories are
topologicaly sorted with respect to [[Join]] --  recall that arguments to
[Join]] must be compiled before a category using [[Join]].
This order is slightly tweaked to avoid problems due to
constructor parameters.  In the first pass categories
are compiled using [[$bootStrapMode]] set to [[t]].  This
makes compiled code of categories available to second pass.
In the second pass categories and core domains are
compiled setting [[$bootstrapDomains]] to [[t]].  We have
to compile categories because categories may have associated
default domains which also may be loaded.  We also compile a
few domains which are needed for unknown reasons - if we
skip them, the build will fail.  In the third pass we
compile categories and core domains in normal mode.
Finally, we compile the rest of algebra in alphabetical order.
More precisely, we let make choose the order, but the list we give is
sorted alphabetically, and make processes it in order.

\section{Adding new constructors}

Adding a new constructor is different from the above process.  It is
easier because a new constructor can freely use functions provided
by standard algebra.  On the other hand, information about new constructors
is absent from Axiom databases, so cyclic dependencies between new
constructors have no easy solution.  However if one is adding
mutually dependent constructors without cyclic dependencies
the solution is easy:  compile all dependent constructors in
a single Axiom image, using apropriate order.  The [[guess-pkg]]
target ilustrates this method.

\start
Date: Mon, 7 May 2007 20:52:12 -0400
From: Bill Page
To: Martin Rubey, Waldek Hebisch
Subject: RE: Bootstrap documentation.

Martin,

On May 7, 2007 3:49 PM you wrote:
> ...
> I guess the whole bootstrap problem would go away with 
> "extend"...  What a pity!
> 

Could you explain why you think the bootstrap problem would
go away this extend?

> \section{The bootstrap problem\dots}
> 
> The current Axiom compiler compiles each constructor (category,
> domain or package) separately.  In order to perform type checking
> Axiom needs type information from other constructors. ...

Excellent documentation, Waldek. Thanks!

\start
Date: 07 May 2007 19:56:38 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Bootstrap documentation.

Bill Page writes:

| Martin,
| 
| On May 7, 2007 3:49 PM you wrote:
| > ...
| > I guess the whole bootstrap problem would go away with 
| > "extend"...  What a pity!
| > 
| 
| Could you explain why you think the bootstrap problem would
| go away this extend?

Many of the categories and friends dragged in by Integer do not seem
to be of necessity at the lowest level.  So, you could start with
just the simple data structure Integer with few operations and
extend it as you go.

\start
Date: Mon, 7 May 2007 22:05:39 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Bootstrap documentation.

On May 7, 2007 8:57 PM Gaby wrote:
> Bill Page writes:
> 
> | On May 7, 2007 3:49 PM Martin wrote:
> | > ...
> | > I guess the whole bootstrap problem would go away with 
> | > "extend"...  What a pity!
> | > 
> | 
> | Could you explain why you think the bootstrap problem would
> | go away this extend?
> 
> Many of the categories and friends dragged in by Integer do
> not seem to be of necessity at the lowest level.  So, you
> could start with just the simple data structure Integer with
> few operations and extend it as you go.
> 

But for this to be sucessful for the entire Axiom library
wouldn't that require that there be no essential mutual
recursion between source modules? I do not see how extend
helps in this case. Sure it is possible even to have
mutual recursion between extensions, not?

In particular, I do not see how the bootstrap mechanism
described by Waldek (or the original approach implemented
by Tim Daly) would be obivated by extend.

\start
Date: 08 May 2007 08:15:14 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: Bootstrap documentation.
Cc: Gabriel Dos Reis

Bill Page writes:

> > Many of the categories and friends dragged in by Integer do
> > not seem to be of necessity at the lowest level.  So, you
> > could start with just the simple data structure Integer with
> > few operations and extend it as you go.
> 
> But for this to be sucessful for the entire Axiom library
> wouldn't that require that there be no essential mutual
> recursion between source modules? I do not see how extend
> helps in this case. Sure it is possible even to have
> mutual recursion between extensions, not?

At least in Aldor you can have more or less arbitrary mutual dependencies.  We
use that (heavily) in the species project ("aldor-combinat").

However, I don't think that the current Axiom algebra uses it.  In any case,
"extend" would make life a lot easier, although my top priority still is to
make types first class objects and to allow domain constructors like

SPECIES ==> (L: LabelType) -> CombinatorialSpecies L;

Plus(
    F: SPECIES,
    G: SPECIES
)(L: LabelType): CombinatorialSpecies(L) == add {
        Rep == Union(left: F L, right: G L);
        import from Rep;
        <<implementation: Plus>>
}

\start
Date: 08 May 2007 02:25:49 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Bootstrap documentation.

Bill Page writes:

| On May 7, 2007 8:57 PM Gaby wrote:
| > Bill Page writes:
| > 
| > | On May 7, 2007 3:49 PM Martin wrote:
| > | > ...
| > | > I guess the whole bootstrap problem would go away with 
| > | > "extend"...  What a pity!
| > | > 
| > | 
| > | Could you explain why you think the bootstrap problem would
| > | go away this extend?
| > 
| > Many of the categories and friends dragged in by Integer do
| > not seem to be of necessity at the lowest level.  So, you
| > could start with just the simple data structure Integer with
| > few operations and extend it as you go.
| > 
| 
| But for this to be sucessful for the entire Axiom library
| wouldn't that require that there be no essential mutual
| recursion between source modules?

Spad needs to move to mutual recursion (with appropriate restrictions)
anyway.

| I do not see how extend
| helps in this case. Sure it is possible even to have
| mutual recursion between extensions, not?

I don't know what a mutual recursion between extensions mean, but
definitely mutual recursion between domains is needed for natural
expressions of domains.

\start
Date: Tue, 08 May 2007 09:54:42 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Bootstrap documentation.

On 05/08/2007 09:25 AM, Gabriel Dos Reis wrote:
> Bill Page writes:

> | > Many of the categories and friends dragged in by Integer do
> | > not seem to be of necessity at the lowest level.  So, you
> | > could start with just the simple data structure Integer with
> | > few operations and extend it as you go.
> | 
> | But for this to be sucessful for the entire Axiom library
> | wouldn't that require that there be no essential mutual
> | recursion between source modules?

An example for Integer...

Suppose you have Integer just defined by

Integer: with == add;

Then you can say

define Ring: with {
    ...
    *: (Integer, %) -> %;
}

extend Integer: Ring == add {...}

No mutual recursion is needed in this case. But I'm sure you knew that 
already.

> Spad needs to move to mutual recursion (with appropriate restrictions)
> anyway.

Does someone know of an instance of mutual recursion in the Axiom 
library that cannot be cured with "extend"? (I am not saying that I 
don't want mutual recursion, but rather whether it is needed for the 
current Axiom library.)

> | I do not see how extend
> | helps in this case. Sure it is possible even to have
> | mutual recursion between extensions, not?

> I don't know what a mutual recursion between extensions mean, but
> definitely mutual recursion between domains is needed for natural
> expressions of domains.

I also don't understand how mutual recursion and extend should work 
together. Surely, it should be possible to extend any domain, no matter 
how it is defined. Bill, can you give an example of what you mean?

\start
Date: Tue, 08 May 2007 10:45:40 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Desired functionality from noweb

> I'm trying to reconcile that idea with an "Axiom Journal" style of
> writing where people may do shorter papers on a single topic.

Oh, I am fully aware of the Axiom Journal idea. And I completely support 
that. But besides the LaTeX issue, there is also the code issue. The 
Axiom Journal is basically Axiom itself (or rather the part that deals 
with Mathematics). In general there might be different "papers" that 
extend Axiom in different an incompatible ways. An "official" Axiom 
could then be seen as a compatible selection of the Journal papers. 
Though, of course, everyone is free to build is own Axiom. I guess, we 
will soon end up with different branches.

So the whole Journal idea needs a lot more of thought than just the 
LaTeX issue. For me the time is not yet ripe, but I am always thinking 
in the journal direction.

> I am thinking about build times for Axiom.  Tim has stated that the
> goal is to treat building documentation on an equal footing with
> building machine binaries, so build time is impacted by documentation
> decisions.  That's the whole reason Waldek proposed and implemented the
> finite-state approach to tangle, and when I asked the list if it was
> really necessary the consensus was yes.  

I am not building Axiom 10 times a day, but rather a (relatively small) 
library. If there is something faster available than noweb with the same 
functionality, I could probably switch easily.

>>> I tend to think of it as one pamphlet = 1 "concept", and then
>>> pamphlets would be bundled like conference proceedings to make
>>> larger volumes.

OK. For me then a "concept" is like a collection of files (call it 
pamphlet or not). I simply want to have reasonable file sizes and 
different languages in different files.

>> If everything is put into html form on a website what 
>> disadvantage would that have?
> 
> Compared to LaTeX+pdf html is (at the moment) not as convenient for
> mathematical output.  Since Axiom is intended to support advanced
> mathematical research robust mathematical typesetting/output is a must.

OK. But there are also ways to link different .dvi and .pdf files 
together. (That was shown by Tim.) That still means one can keep the 
projects/libraries/concepts separate documents and still interlink.

>>> In essence, links that move the reader through the document in the
>>> order in which the machine would see the code?  That's not a bad
>>> idea.  Hmm...
>> But that is only for chunks that have the same name. They are
>> combined together in the order they apper in a .pamphlet. The rest
>> appears as a hierarchy.
> 
> ?  I'm a bit confused.  I thought chunk names had to be unique within a
> pamphlet.

Try
%---BEGIN aaa.pamphlet
<<*>>=
<<X>>
A
@
<<X>>=
EFG
@
<<*>>=
B
@
<<C>>=
UVW
@
%---END aaa.pamphlet

notangle aaa.pamphlet
EFG
A
UVW
B

>> I don't use language awareness in ALLPROSE. Aldor is not build-in
>> into noweb anyway and I did not know how to write an appropriate
>> noweb filter to add language support for Aldor, so my filters start
>> before noweave sees the file. Anyway, if we start putting several
>> different languages into one pamphlet, it will be difficult to guess
>> the language if there is no explicit tag.
> 
> Agreed - I think it would be a bad idea to have more than one language
> per pamphlet.  If we must do so an explicit tag for language is needed.

In fact, I am not 100% sure whether it is a bad idea to have several 
languages in one file. The reason is that sometimes one describes a 
target in a Makefile, for example, and that would use some perl script.
If the perl script is only used for that target then it might be a good 
idea to place the script+documentation right next to the description of 
the make target. I simply have not enough experience in LP to decide 
what is better. And there may be different tastes.

>> Very important for me is that the pamphlet -> latex routine respects
>> line numbers as noweave does. Every documentation chunk should be 
>> wrapped by something like \begin{docchunk} ... \end{docchunk} and
>> every code chunk by \begin{codechunk}{name} ... \end{codechunk} (or
>> something similar.
> 
> Code chunks I've got wrapped in listing environments, but why do you
> want the documentation chunks identified?  I always viewed pamphlet
> files as a latex document with chunks embedded in it - what is the
> advantage of chunking up the documentation as well?

That line numbering in the .tex is *identical* to the .pamphlet file is 
needed for the inverse search feature.

What is the disadvantage of \begin{docchunk} ... \end{docchunk}? You can 
define it as

\newenvironment{docchunk}{}{}

but without any need to re-weave, you could also compile against another 
style file which has

\usepackage{verbatim}
\newenvironment{docchunk}{\comment}{\endcomment}

and you would only see code in the .dvi file. (It's just an example.)
Try to look at the output of

noweave aaa.pamphlet

it also produces something like

\documentclass{article}\usepackage{noweb}\pagestyle{noweb}\noweboptions{}\begin{document}\nwfilename{aaa.pamphlet}\nwbegindocs{0}%---BEGIN 
aaa.pamphlet% ===> this file was generated automatically by noweave --- 
better not edit it
\nwenddocs{}\nwbegincode{1}\moddef{*}\endmoddef\nwstartdeflinemarkup\nwenddeflinemarkup
\LA{}X\RA{}
A
\nwendcode{}\nwbegindocs{2}\nwdocspar
\nwenddocs{}\nwbegincode{3}\moddef{X}\endmoddef\nwstartdeflinemarkup\nwenddeflinemarkup
EFG
\nwendcode{}\nwbegindocs{4}\nwdocspar
\nwenddocs{}\nwbegincode{5}\moddef{*}\plusendmoddef\nwstartdeflinemarkup\nwenddeflinemarkup
\LA{}C\RA{}
B
\nwendcode{}\nwbegindocs{6}\nwdocspar
\nwenddocs{}\nwbegincode{7}\moddef{C}\endmoddef\nwstartdeflinemarkup\nwenddeflinemarkup
UVW
\nwendcode{}\nwbegindocs{8}\nwdocspar
%---END aaa.pamphlet
\nwenddocs{}\end{document}

So noweave even adds chunk numbers which one can ignore in the .sty file.

\start
Date: Tue, 8 May 2007 04:00:23 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Bootstrap documentation.

On Tue, 8 May 2007, Ralf Hemmecke wrote:

[...]

| > Spad needs to move to mutual recursion (with appropriate restrictions)
| > anyway.
| 
| Does someone know of an instance of mutual recursion in the Axiom library that
| cannot be cured with "extend"? (I am not saying that I don't want mutual
| recursion, but rather whether it is needed for the current Axiom library.)

This is not from the Axiom library, but I do run into it very often.

Assume I want to represent a typed abstract syntax tree for the
C language.  In C, I have the following (simplifying a bit)
  
   * literals
   * declarations
   * types
   * expressions
   * ...

A type can be:
    - an identifier
    - a structure, with components that are are fields (declarations
         involving names, types, and expressions)
    - an array, with components that are a type and an expression
    - ...

An expression among other things, contains:

    - sizeof (type)

I want distinct domains for literals, fields, types, expressions, etc. 


In Haskell (or Boot), I could write:

   type Symbol = String

   data Type = Identifier Symbol
             | Structure (Maybe Symbol) [Field]
             | Array Type Expression
             -- and more

   data Field = Bitfield (Maybe Symbol) Expression Type
              | NonBitfield Symbol Type

   data Expression = StringLiteral String
                   | SizeofExpr Expression
                   | SizeofType Type
                   -- and more

What would be a "natural" and concise expression of that in Spad?

\start
Date: Tue, 08 May 2007 11:08:55 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Bootstrap documentation.

> I want distinct domains for literals, fields, types, expressions, etc. 

Do you insist on domains or would something like the ExpressionTree and 
friends in LibAlgebra 
http://www-sop.inria.fr/cafe/Manuel.Bronstein/algebra/ do?

I guess you'd need domains for mutual recursion in the grammar, right?

\start
Date: Tue, 8 May 2007 04:14:36 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Bootstrap documentation.

On Tue, 8 May 2007, Ralf Hemmecke wrote:

| > I want distinct domains for literals, fields, types, expressions, etc. 
| 
| Do you insist on domains or would something like the ExpressionTree and
| friends in LibAlgebra http://www-sop.inria.fr/cafe/Manuel.Bronstein/algebra/
| do?

I insist on distinct domains for distinct notions present in the C language.

| I guess you'd need domains for mutual recursion in the grammar, right?

yes.

\start
Date: Tue, 8 May 2007 12:50:44 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Weird errors

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | FYI I am now seeing really weird errors: on gentoo machine wh-sandbox
> | revision 526 gives me multiple build failures -- compile fails
> | because gcl gets some system errors.  Restarting make gives the
> | same error.  But when I try to investigate problem and run compile
> | by hand it works with no error...
> | 
> | Strangly, revision 525 builds with no error on this machine.
> | 
> | BTW: I use here ANSI gcl build from sources included in
> | build-improvements.  Gentoo provides gcl-2.6.7 but this one fails
> | quite early trying to link the first Lisp image.
> 
> Try build with --enable-checking -- yes, I know it takes hours.
> You'll see many runtime type errors.
> The checking is too fined-grained, but it get you somewhere.
> 

wh-sandbox have no --enable-checking but I did equivalent (set
safety to 3) by hand.  The build now finished.  After looking
at testsuite results and generated .pht pages the only errors I
see are expected ones: few triangular set examples and stream
of primes.  I saw them before -- it looks that safety 3 disables
tail call optimization and some inputs may run out of memory
or stack space.

The problem I saw looks like memory management problem and I am
not surprized that changing safey to 3 makes it go away...

BTW: in revison 513 I have fixed all errors that showed during
build with safety 3 (except for above mentioned running out of
memory).

\start
Date: Tue, 8 May 2007 06:23:08 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Weird errors

On Tue, 8 May 2007, Waldek Hebisch wrote:

| The problem I saw looks like memory management problem and I am
| not surprized that changing safey to 3 makes it go away...

That is weird indeed.  
I'm out of idea for now.
:-(

\start
Date: Tue, 8 May 2007 04:38:05 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Desired functionality from noweb

--- Ralf Hemmecke wrote:

> > I'm trying to reconcile that idea with an "Axiom Journal" style of
> > writing where people may do shorter papers on a single topic.
> 
> Oh, I am fully aware of the Axiom Journal idea. And I completely
> support that. But besides the LaTeX issue, there is also the code
> issue. The Axiom Journal is basically Axiom itself (or rather the
> part that deals with Mathematics). In general there might be
> different "papers" that  extend Axiom in different an incompatible
> ways.

Hmm.  Definitely a point.

> An "official" Axiom could then be seen as a compatible selection of
> the Journal papers. Though, of course, everyone is free to build is
> own Axiom. I guess, we will soon end up with different branches.

Hopefully doing work in Axiom would be one way to keep things more
compatible, but I guess that still doesn't solve the problem of
competing research teams working on the same task.

> So the whole Journal idea needs a lot more of thought than just the 
> LaTeX issue. For me the time is not yet ripe, but I am always
> thinking in the journal direction.

Agreed, but I still think it is worthwhile to bear it in mind when
thinking about the LaTeX machinery, since with luck it will eventually
be needed.

> > I am thinking about build times for Axiom.  Tim has stated that the
> > goal is to treat building documentation on an equal footing with
> > building machine binaries, so build time is impacted by
> > documentation decisions.  That's the whole reason Waldek proposed
> > and implemented the finite-state approach to tangle, and when I
> > asked the list if it was really necessary the consensus was yes.  
> 
> I am not building Axiom 10 times a day, but rather a (relatively
> small) library. If there is something faster available than noweb
> with the same functionality, I could probably switch easily.

Of course, there is also the option of giving people the choice - use
noweb and get more features, or cl-web and get (slightly) faster build
times.

I still think the most promising direction for the "read the source
code and find definitions and where they are used" is to use the
compiler to find that information - anything else just seems too
fragile.  sbcl has xref functionality now (since Dec. 2006 actually,
although I didn't see it at the time) and also a contrib module called
sb-introspection developed for SLIME.  These tools or extensions of
them might make for some VERY interesting possibilities.  (Of course
that would tie that functionality to sbcl...)

> >>> I tend to think of it as one pamphlet = 1 "concept", and then
> >>> pamphlets would be bundled like conference proceedings to make
> >>> larger volumes.
> 
> OK. For me then a "concept" is like a collection of files (call it 
> pamphlet or not). I simply want to have reasonable file sizes and 
> different languages in different files.

Makes sense.

> >> If everything is put into html form on a website what 
> >> disadvantage would that have?
> > 
> > Compared to LaTeX+pdf html is (at the moment) not as convenient for
> > mathematical output.  Since Axiom is intended to support advanced
> > mathematical research robust mathematical typesetting/output is a
> > must.
> 
> OK. But there are also ways to link different .dvi and .pdf files 
> together. (That was shown by Tim.) That still means one can keep the 
> projects/libraries/concepts separate documents and still interlink.

Yes.  I guess my next question is do you want to be able to have the
def feature work across multiple files?

> >> But that is only for chunks that have the same name. They are
> >> combined together in the order they apper in a .pamphlet. The rest
> >> appears as a hierarchy.
> > 
> > ?  I'm a bit confused.  I thought chunk names had to be unique
> within a
> > pamphlet.
> 
> Try
> %---BEGIN aaa.pamphlet
> <<*>>=
> <<X>>
> A
> @
> <<X>>=
> EFG
> @
> <<*>>=
> B
> @
> <<C>>=
> UVW
> @
> %---END aaa.pamphlet
> 
> notangle aaa.pamphlet
> EFG
> A
> UVW
> B

Ugh.  I don't think this is a style of LP we should use.  My preference
in the above situation would be to throw an error that chunk "X" is
already defined.  For multiple "root" nodes in a file tangle the
requested node but print a note that chunks "foo" and "bar" in this
file are also root nodes.  I suppose a tangle with no specified root
node could untangle all root nodes but I don't really regard that as a
good way to work - at least the way I write if a chunk isn't inside a
root node it's a mistake and what I want is a message warning me, not
an unwanted file (or sometimes several of them) dumped into the source
dire 

 
> >> I don't use language awareness in ALLPROSE. Aldor is not build-in
> >> into noweb anyway and I did not know how to write an appropriate
> >> noweb filter to add language support for Aldor, so my filters
> start
> >> before noweave sees the file. Anyway, if we start putting several
> >> different languages into one pamphlet, it will be difficult to
> guess
> >> the language if there is no explicit tag.
> > 
> > Agreed - I think it would be a bad idea to have more than one
> language
> > per pamphlet.  If we must do so an explicit tag for language is
> needed.
> 
> In fact, I am not 100% sure whether it is a bad idea to have several 
> languages in one file. The reason is that sometimes one describes a 
> target in a Makefile, for example, and that would use some perl
> script. If the perl script is only used for that target then it might
> be a good idea to place the script+documentation right next to the
> description of the make target. I simply have not enough experience
> in LP to decide  what is better. And there may be different tastes.

 Oh, OK.  Now I see why you want tangle to export all root nodes by
default.  My personal preference would still be to call tangle for each
node but it would be faster and easier in that situation to just tangle
all root nodes once.  Hmm.  I guess a behavior flag is in order, plus I
need to flag root nodes.

> If the perl script is only used for that target then it might be a
> good idea to place the script+documentation right next to the
> description of the make target. I simply have not enough experience
> in LP to decide  what is better. And there may be different tastes.

Probably.  I personally prefer not to have "hidden" root nodes in files
that the pamphlet name doesn't suggest, but I can see your above case
as a reasonable exception to that.  (It's unfortunate that multiple
languages are needed but that's another post.)

> That line numbering in the .tex is *identical* to the .pamphlet file
> is needed for the inverse search feature.

OK.  I need to take a look at the inverse search feature in more
detail.

> What is the disadvantage of \begin{docchunk} ... \end{docchunk}? You
> can define it as
> 
> \newenvironment{docchunk}{}{}
> 
> but without any need to re-weave, you could also compile against
> another style file which has
> 
> \usepackage{verbatim}
> \newenvironment{docchunk}{\comment}{\endcomment}
> 
> and you would only see code in the .dvi file. (It's just an example.)

I guess my instinct was to add only what was absolutely necessary to
the TeX file for simplicity, but I guess I have to admit it wouldn't
make too much difference.  I didn't want to require any style files not
already in teTeX but I guess that's unrealistic.
 
> So noweave even adds chunk numbers which one can ignore in the .sty
> file.

I guess I need to think about this one some more, and dig into inverse
search.

\start
Date: Tue, 8 May 2007 09:31:59 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Bootstrap documentation.
Cc: Gabriel Dos Reis

On May 8, 2007 2:15 AM Martin Rubey wrote:
> 
> Bill Page writes:
> 
> > Gaby wrote:
> > > Many of the categories and friends dragged in by Integer
> > > do not seem to be of necessity at the lowest level.  So,
> > > you could start with just the simple data structure Integer
> > > with few operations and extend it as you go.
> > 
> > But for this to be sucessful for the entire Axiom library
> > wouldn't that require that there be no essential mutual
> > recursion between source modules? I do not see how extend
> > helps in this case. Sure it is possible even to have
> > mutual recursion between extensions, not?
> 
> At least in Aldor you can have more or less arbitrary mutual 
> dependencies.

So far as I understand it, Aldor can solve mutual dependencies
only when they occur within the same source module. Some types
of mutual dependencies between source modules (the trivial ones)
can be handled by extend.

> We use that (heavily) in the species project ("aldor-combinat").
>

Could you give an example?
 
> However, I don't think that the current Axiom algebra uses 
> it.

??? You don't think the Axiom algebra uses mutual recursion?
I would like to be shown that I am wrong, but I think that
it does, in fact that it is used extensively.

> In any case, "extend" would make life a lot easier, although
> my top priority still is to make types first class objects
> and to allow domain constructors like
> 
> SPECIES ==> (L: LabelType) -> CombinatorialSpecies L;
> 
> Plus(
>     F: SPECIES,
>     G: SPECIES
> )(L: LabelType): CombinatorialSpecies(L) == add {
>         Rep == Union(left: F L, right: G L);
>         import from Rep;
>         <<implementation: Plus>>
> }
> 

I don't understand this construction. What is the signature
of the function 'Plus'? I think this goes beyond what would
normally call "dependent types" since L would appear to be
a free parameter of some kind. Isn't there a way to write
this that does not use such an exotic definition?

\start
Date: 08 May 2007 08:49:12 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Bootstrap documentation.

Bill Page writes:

| On May 8, 2007 2:15 AM Martin Rubey wrote:
| > 
| > Bill Page writes:
| > 
| > > Gaby wrote:
| > > > Many of the categories and friends dragged in by Integer
| > > > do not seem to be of necessity at the lowest level.  So,
| > > > you could start with just the simple data structure Integer
| > > > with few operations and extend it as you go.
| > > 
| > > But for this to be sucessful for the entire Axiom library
| > > wouldn't that require that there be no essential mutual
| > > recursion between source modules? I do not see how extend
| > > helps in this case. Sure it is possible even to have
| > > mutual recursion between extensions, not?
| > 
| > At least in Aldor you can have more or less arbitrary mutual 
| > dependencies.
| 
| So far as I understand it, Aldor can solve mutual dependencies
| only when they occur within the same source module.

For the majority of the cases where I need mutual recursion between
domains, that is sufficient.

| Some types
| of mutual dependencies between source modules (the trivial ones)
| can be handled by extend.

I'm not sure I would qualify those of "trivial".

[...]

| > In any case, "extend" would make life a lot easier, although
| > my top priority still is to make types first class objects
| > and to allow domain constructors like
| > 
| > SPECIES ==> (L: LabelType) -> CombinatorialSpecies L;
| > 
| > Plus(
| >     F: SPECIES,
| >     G: SPECIES
| > )(L: LabelType): CombinatorialSpecies(L) == add {
| >         Rep == Union(left: F L, right: G L);
| >         import from Rep;
| >         <<implementation: Plus>>
| > }
| > 
| 
| I don't understand this construction. What is the signature
| of the function 'Plus'? I think this goes beyond what would
| normally call "dependent types"

Huh?  What is "normally calle 'dependent types'"?

\start
Date: Tue, 08 May 2007 15:51:31 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Desired functionality from noweb

> I still think the most promising direction for the "read the source
> code and find definitions and where they are used" is to use the
> compiler to find that information - anything else just seems too
> fragile.

Of course. But starting the compiler to get hyperlinks in the 
documentation should be optional, because it would basically mean to 
compile the code and add the symbol information to the documentation to 
get nice hyperlinks. The bad thing is if you want to document what you 
currently have, but the code does not yet compile.

>> OK. But there are also ways to link different .dvi and .pdf files 
>> together. (That was shown by Tim.) That still means one can keep the 
>> projects/libraries/concepts separate documents and still interlink.
> 
> Yes.  I guess my next question is do you want to be able to have the
> def feature work across multiple files?

Hmm, in ALLPROSE a file is not the same as a "concept". But this %def 
stuff works across file bounderies. The trick is that noweave basically 
sees only one file. I split noweave's output later into separate files 
again. That is easy, because each file begins with something like

\nwfilename{Makefile.nw}\nwbegindocs{0}

The only problem is that with %def one can only do identifiers, but not 
semantic links. So I restrict that %def thing to type names. They are 
more or less unique in a project.

>> Try
>> %---BEGIN aaa.pamphlet
>> <<*>>=
>> <<X>>
>> A
>> @
>> <<X>>=
>> EFG
>> @
>> <<*>>=
>> B
>> @
>> <<C>>=
>> UVW
>> @
>> %---END aaa.pamphlet
>>
>> notangle aaa.pamphlet
>> EFG
>> A
>> UVW
>> B
> 
> Ugh.  I don't think this is a style of LP we should use.

Why not? Well, it was just an example, but I don't think that a 
continued code junk is a terribly bad idea. I would only require that 
braces are paired within each chunk.

You don't need to use this option of noweb. And again. I have not enough 
experience that I could already suggest a good LP style.

 > My preference
> in the above situation would be to throw an error that chunk "X" is
> already defined.

What? There is only one definition of X.

> For multiple "root" nodes in a file tangle the
> requested node but print a note that chunks "foo" and "bar" in this
> file are also root nodes.

There is always only one "root" node. And that is started by the first 
<<*>>= in a file.

> I suppose a tangle with no specified root
> node could untangle all root nodes but I don't really regard that as a
> good way to work - at least the way I write if a chunk isn't inside a
> root node it's a mistake and what I want is a message warning me, not
> an unwanted file (or sometimes several of them) dumped into the source
> dire 

Hmm, seems that you confuse the way noweb (the program) treats a file 
with the way notangle/noweave treats the same file when giving no 
additional command line switches.

> Probably.  I personally prefer not to have "hidden" root nodes in files
> that the pamphlet name doesn't suggest,

I don't understand, what i "hidden root node" is.

Personally I sometimes use

<<OLD: foo>>=
some code
@

<<foo>>=
same code with a little modification
@

I particularly find that useful to test some slight variations of the 
code I have without the need to remove the old code. Maybe that I will 
finally remove <<OLD: foo>>, since it is never used, but think about

<<ALTERNATIVE: foo>>=
...
@

and a corresponding description when that should be used or what idea 
behind that alternative is.

>> That line numbering in the .tex is *identical* to the .pamphlet file
>> is needed for the inverse search feature.

LaTeX (or better srcltx.sty) only sees the .tex file. So it can only 
write line numbers of the .tex file as \special into the .dvi file. If 
the line numbers differ from the .pamplet source, inverse search would 
jump to the wrong place.

>> What is the disadvantage of \begin{docchunk} ... \end{docchunk}? You
>> can define it as
>>
>> \newenvironment{docchunk}{}{}
>>
>> but without any need to re-weave, you could also compile against
>> another style file which has
>>
>> \usepackage{verbatim}
>> \newenvironment{docchunk}{\comment}{\endcomment}
>>
>> and you would only see code in the .dvi file. (It's just an example.)
> 
> I guess my instinct was to add only what was absolutely necessary to
> the TeX file for simplicity, but I guess I have to admit it wouldn't
> make too much difference.  I didn't want to require any style files not
> already in teTeX but I guess that's unrealistic.

So you don't want to require something like axiom.sty? But then you put 
all the style information into your weave program. That doesn't sound 
like the right way to do.

\start
Date: Tue, 08 May 2007 16:47:56 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Bootstrap documentation.

On 05/08/2007 03:49 PM, Gabriel Dos Reis wrote:
> Bill Page writes:

> | > In any case, "extend" would make life a lot easier, although
> | > my top priority still is to make types first class objects
> | > and to allow domain constructors like
> | > 
> | > SPECIES ==> (L: LabelType) -> CombinatorialSpecies L;
> | > 
> | > Plus(
> | >     F: SPECIES,
> | >     G: SPECIES
> | > )(L: LabelType): CombinatorialSpecies(L) == add {
> | >         Rep == Union(left: F L, right: G L);
> | >         import from Rep;
> | >         <<implementation: Plus>>
> | > }
> | > 
> | 
> | I don't understand this construction. What is the signature
> | of the function 'Plus'? I think this goes beyond what would
> | normally call "dependent types"
> 
> Huh?  What is "normally calle 'dependent types'"?

Bill, yes, the L looks like being a parameter. Let me try another 
definition.

Plus1(
     F: SPECIES,
     G: SPECIES
): SPECIES == (L: LabelType): CombinatorialSpecies(L) +-> add {
         Rep == Union(left: F L, right: G L);
         import from Rep;
         <<implementation: Plus>>
}

So
    Plus: (SPECIES, SPECIES) -> SPECIES
as an addition of species.

Does that look simpler? Of course you can go on and define something like

Plus2: (F: SPECIES, G: SPECIES) -> ... ==
        (F: SPECIES, G: SPECIES): ... +-> ((L: LabelType): ... +-> ...)

But that is probably not what you meant.

Yes, CombinatorialSpecies is itself a function.
http://www.risc.uni-linz.ac.at/people/hemmecke/AldorCombinat/combinatsu16.html#dt:CombinatorialSpecies

CombinatorialSpecies: (L: LabelType) -> Category

The following does (of course) not work.

Plus3(
     F: SPECIES,
     G: SPECIES
): CombinatorialSpecies ==
(L: LabelType): CombinatorialSpecies(L) +-> add {
         Rep == Union(left: F L, right: G L);
         import from Rep;
         <<implementation: Plus>>
}

And I somehow need the L, because it is used inside the "add".

Ralf



\start
Date: Tue, 8 May 2007 10:18:18 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Bootstrap documentation.

On Tue, 8 May 2007, Ralf Hemmecke wrote:

| On 05/08/2007 03:49 PM, Gabriel Dos Reis wrote:
| > Bill Page writes:
| 
| > | > In any case, "extend" would make life a lot easier, although
| > | > my top priority still is to make types first class objects
| > | > and to allow domain constructors like
| > | > 
| > | > SPECIES ==> (L: LabelType) -> CombinatorialSpecies L;
| > | > 
| > | > Plus(
| > | >     F: SPECIES,
| > | >     G: SPECIES
| > | > )(L: LabelType): CombinatorialSpecies(L) == add {
| > | >         Rep == Union(left: F L, right: G L);
| > | >         import from Rep;
| > | >         <<implementation: Plus>>
| > | > }
| > | > 
| > | 
| > | I don't understand this construction. What is the signature
| > | of the function 'Plus'? I think this goes beyond what would
| > | normally call "dependent types"
| > 
| > Huh?  What is "normally calle 'dependent types'"?
| 
| Bill, yes, the L looks like being a parameter. Let me try another definition.
| 
| Plus1(
|     F: SPECIES,
|     G: SPECIES
| ): SPECIES == (L: LabelType): CombinatorialSpecies(L) +-> add {
|         Rep == Union(left: F L, right: G L);
|         import from Rep;
|         <<implementation: Plus>>
| }
| 
| So
|    Plus: (SPECIES, SPECIES) -> SPECIES
| as an addition of species.
| 
| Does that look simpler? Of course you can go on and define something like
| 
| Plus2: (F: SPECIES, G: SPECIES) -> ... ==
|        (F: SPECIES, G: SPECIES): ... +-> ((L: LabelType): ... +-> ...)
| 
| But that is probably not what you meant.
| 
| Yes, CombinatorialSpecies is itself a function.
| http://www.risc.uni-linz.ac.at/people/hemmecke/AldorCombinat/combinatsu16.html#dt:CombinatorialSpecies
| 
| CombinatorialSpecies: (L: LabelType) -> Category
| 
| The following does (of course) not work.
| 
| Plus3(
|     F: SPECIES,
|     G: SPECIES
| ): CombinatorialSpecies ==
| (L: LabelType): CombinatorialSpecies(L) +-> add {
|         Rep == Union(left: F L, right: G L);
|         import from Rep;
|         <<implementation: Plus>>
| }
| 
| And I somehow need the L, because it is used inside the "add".

I'm not aware of a definition of "dependent types" that would
disallow the use of "L" above in the definition of Plus.

One of the reason I asked my question is that, I wanted to arrive at
the most "natural" way of expressing simple concepts (found in many
different programming languages today), that very simply written, and very
simply stated.  This is both necessary for teaching (I was writing up 
something about programming with Spad) and basis for improvement.

I'm looking for ways to express simple and elegantly simple notions.

\start
Date: Tue, 8 May 2007 11:25:11 -0400
From: Bill Page
To: Ralf Hemmecke, Gabriel Dos Reis
Subject: RE: Bootstrap documentation.

On May 8, 2007 10:48 AM Ralf Hemmecke wrote:
>
> On 05/08/2007 03:49 PM, Gabriel Dos Reis wrote:
> > Bill Page writes:
>
> > | > In any case, "extend" would make life a lot easier,
> > | > although my top priority still is to make types first
> > | > class objects and to allow domain constructors like
> > | >
> > | > SPECIES ==> (L: LabelType) -> CombinatorialSpecies L;
> > | >
> > | > Plus(
> > | >     F: SPECIES,
> > | >     G: SPECIES
> > | > )(L: LabelType): CombinatorialSpecies(L) == add {
> > | >         Rep == Union(left: F L, right: G L);
> > | >         import from Rep;
> > | >         <<implementation: Plus>>
> > | > }
> > | >
> > |
> > | I don't understand this construction. What is the signature
> > | of the function 'Plus'? I think this goes beyond what would
> > | normally call "dependent types"
> >
> > Huh?  What is "normally called 'dependent types'"?
>

Perhaps I should have said: "goes beyond what **I** would normally
call a dependent type". How other people classify this, I cannot
say. Now you might ask: How do I define dependent type? But I
prefer to punt (en Fran=E7ais "ponter") on that question for now.

> Bill, yes, the L looks like being a parameter. Let me try
> another definition.
>
> Plus1(
>      F: SPECIES,
>      G: SPECIES
> ): SPECIES == (L: LabelType): CombinatorialSpecies(L) +-> add {
>          Rep == Union(left: F L, right: G L);
>          import from Rep;
>          <<implementation: Plus>>
> }
>
> So
>     Plus: (SPECIES, SPECIES) -> SPECIES
> as an addition of species.
>
> Does that look simpler?

Yes, excellent. That is much better. Now L only appears explicity
in the body of the function. Is it equivalent to what Martin wrote?

> Of course you can go on and define something like
>
> Plus2: (F: SPECIES, G: SPECIES) -> ... ==
>         (F: SPECIES, G: SPECIES): ... +-> ((L: LabelType):
> ... +-> ...)
>
> But that is probably not what you meant.
>
> Yes, CombinatorialSpecies is itself a function.
http://www.risc.uni-linz.ac.at/people/hemmecke/AldorCombinat/combinatsu16=
.ht
ml#dt:CombinatorialSpecies
>
> CombinatorialSpecies: (L: LabelType) -> Category
>
> The following does (of course) not work.
>
> Plus3(
>      F: SPECIES,
>      G: SPECIES
> ): CombinatorialSpecies ==
> (L: LabelType): CombinatorialSpecies(L) +-> add {
>          Rep == Union(left: F L, right: G L);
>          import from Rep;
>          <<implementation: Plus>>
> }
>
> And I somehow need the L, because it is used inside the "add".
>

\start
Date: Tue, 08 May 2007 17:30:48 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Axiom-developer] Bootstrap documentation.
Cc: Gabriel Dos Reis

>> So
>>     Plus: (SPECIES, SPECIES) -> SPECIES
>> as an addition of species.
>>
>> Does that look simpler?
> 
> Yes, excellent. That is much better. Now L only appears explicity
> in the body of the function. Is it equivalent to what Martin wrote?

Yes that compiles and "make check" does not report an error.

\start
Date: Tue, 8 May 2007 10:51:51 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: Bootstrap documentation.

On Tue, 8 May 2007, Bill Page wrote:

| On May 8, 2007 10:48 AM Ralf Hemmecke wrote:
| > 
| > On 05/08/2007 03:49 PM, Gabriel Dos Reis wrote:
| > > Bill Page writes:
| > 
| > > | > In any case, "extend" would make life a lot easier,
| > > | > although my top priority still is to make types first
| > > | > class objects and to allow domain constructors like
| > > | > 
| > > | > SPECIES ==> (L: LabelType) -> CombinatorialSpecies L;
| > > | > 
| > > | > Plus(
| > > | >     F: SPECIES,
| > > | >     G: SPECIES
| > > | > )(L: LabelType): CombinatorialSpecies(L) == add {
| > > | >         Rep == Union(left: F L, right: G L);
| > > | >         import from Rep;
| > > | >         <<implementation: Plus>>
| > > | > }
| > > | > 
| > > | 
| > > | I don't understand this construction. What is the signature
| > > | of the function 'Plus'? I think this goes beyond what would
| > > | normally call "dependent types"
| > > 
| > > Huh?  What is "normally called 'dependent types'"?
| > 
| 
| Perhaps I should have said: "goes beyond what **I** would normally
| call a dependent type". How other people classify this, I cannot
| say. Now you might ask: How do I define dependent type?

I think this is a standard reference

  ftp://ftp.cs.ru.nl/pub/CompMath.Found/HBK.ps

Look from page 82 onwards.

\start
Date: Tue, 8 May 2007 10:20:20 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Desired functionality from noweb

--- Ralf Hemmecke wrote:

> > I still think the most promising direction for the "read the source
> > code and find definitions and where they are used" is to use the
> > compiler to find that information - anything else just seems too
> > fragile.
> 
> Of course. But starting the compiler to get hyperlinks in the 
> documentation should be optional, because it would basically mean to 
> compile the code and add the symbol information to the documentation
> to get nice hyperlinks. The bad thing is if you want to document 
> what you currently have, but the code does not yet compile.

A good point.  Perhaps in default mode it could try to compile, and if
that fails fall back on basic tangle w/o the usage processing.


> The only problem is that with %def one can only do identifiers, but
> not semantic links. So I restrict that %def thing to type names.
> They are more or less unique in a project.

OK.

> >> Try
> >> %---BEGIN aaa.pamphlet
> >> <<*>>=
> >> <<X>>
> >> A
> >> @
> >> <<X>>=
> >> EFG
> >> @
> >> <<*>>=
> >> B
> >> @
> >> <<C>>=
> >> UVW
> >> @
> >> %---END aaa.pamphlet
> >>
> >> notangle aaa.pamphlet
> >> EFG
> >> A
> >> UVW
> >> B
> > 
> > Ugh.  I don't think this is a style of LP we should use.
> 
> Why not? Well, it was just an example, but I don't think that a 
> continued code junk is a terribly bad idea. I would only require that
> braces are paired within each chunk.

Non-unique root node definitions in a file will increase complexity. 
Ideally all code chunks in a program would have unique chunk names - at
the very least, anything part of a particular tangle operation should
have a unique name.  I expect to run tangle once per <<*>> defined, and
I expect one <<*>> per file (or "project" if you prefer.)  Perhaps
there are reasons not to do that but I'm not seeing it right now.

> You don't need to use this option of noweb. And again. I have not
> enough experience that I could already suggest a good LP style.

Neither do I.  I guess we can wait and see - nothing is set in stone.

>  > My preference
> > in the above situation would be to throw an error that chunk "X" is
> > already defined.
> 
> What? There is only one definition of X.

I beg your pardon - "*" not X.  I read it too fast.

> > For multiple "root" nodes in a file tangle the
> > requested node but print a note that chunks "foo" and "bar" in this
> > file are also root nodes.
> 
> There is always only one "root" node. And that is started by the
> first <<*>>= in a file.

So any other node being called <<*>> is just going to confuse the
issue, in my opinion.

> Hmm, seems that you confuse the way noweb (the program) treats a file
> with the way notangle/noweave treats the same file when giving no 
> additional command line switches.

That could be.

> > Probably.  I personally prefer not to have "hidden" root nodes in
> > files that the pamphlet name doesn't suggest,
> 
> I don't understand, what i "hidden root node" is.

Sorry - by that I mean a root node in a file that isn't intended to be
included in the tangled file implied by the pamphlet name.  An example
would be the lisp code included in the pamphlets for boot - if you look
at my runlisptangle file you'll see some examples where I have to
explicitly select the node.

> Personally I sometimes use
> 
> <<OLD: foo>>=
> some code
> @
> 
> <<foo>>=
> same code with a little modification
> @
> 
> I particularly find that useful to test some slight variations of the
> code I have without the need to remove the old code. Maybe that I
> will finally remove <<OLD: foo>>, since it is never used, but think
> about
> 
> <<ALTERNATIVE: foo>>=
> ...
> @
> 
> and a corresponding description when that should be used or what 
> idea behind that alternative is.

Maybe.  I guess I can see that, but my preference is to keep all code
in a program "live" in the sense of it's being intended for use.  I
think that's a stylistic difference.

It's less of an issue if it is never intended to be translated and
compiled.

> >> That line numbering in the .tex is *identical* to the .pamphlet
> >> file is needed for the inverse search feature.
> 
> LaTeX (or better srcltx.sty) only sees the .tex file. So it can only 
> write line numbers of the .tex file as \special into the .dvi file.
> If the line numbers differ from the .pamplet source, inverse search
> would jump to the wrong place.

OK.  Perhaps a way around that would be to pass the pamphlet line
number to the tex code for use in srcltx.sty (or some variation
thereof.)  Right now I don't see it being a problem.

> So you don't want to require something like axiom.sty? But then you
> put all the style information into your weave program. That doesn't
> sound like the right way to do.

I had sort of assumed we would settle on a particular style as the
"official" Axiom style, but maybe that's not a good assumption.

\start
Date: Wed, 9 May 2007 02:02:56 +0200 (CEST)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: git-svn

> Well checkout works and I can make changes.
> I just cannot commit changes. I get
> 
> Authorization failed:
> MKACTIVITY of '/svnroot/axiom/!svn/act/.....: 
> authorization failed (https://axiom.svn.sourceforget.net) at
> /usr/bin/git-svn line 875
> 
> I'm open to suggestion about why I cannot commit to SVN.
> 

Are you sure you can not commit: I see a commit to daly branch
which created a 'test' file.  It happened to me multiple times that
svn told me that a commit failed when in fact it worked.  To avoid
confusion in such a case I was doing update (the update proved
that commit worked).

\start
Date: 08 May 2007 22:47:44 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] Axiom and Superman

  As of revision 536, if you build Axiom build-improvements with
Superman disabled, e.g. currently on Windows, you can still install
the "axiom" script (through the usual "make install") and invoke it as
normal (you'd need msys/mingw though).  Of course, at the moment, you
won't  get HyperDoc and friends.

built and tested on Windows with msys/mingw.

\start
Date: Wed, 9 May 2007 00:43:56 -0500
From: Tim Daly
To: list
Subject: JavaFX

This might be interesting as a way to get a portable 
browser-based/Java enabled Axiom front end:

http://www.internetnews.com/dev-news/article.php/3676226

Java would significantly improve our ability to do system
independent graphics within a web page. I've been looking
into the new <canvas> tag in more detail but this might
make it a dead path.

In general, after 2 years of professional use, I've grown
to hate Java. However, javascript is also painful. The
devil will certainly be in the details. There is, as usual, 
a lack of detail. 

At the moment the plan is to re-use the current design
as much as possible as a target design.

We could use the current hyperdoc and graphics interfaces
as API definitions which would mean that sman could talk
directly to web-based code or use hyperdoc/view2D/view3D.
This would significantly lower the redesign costs.

In order to use the same algorithms it would be sufficient
to create a set of java classes that mimic the subset of X11
calls we currently use. This might be easier with the Java
graphics API than with the javascript/canvas tag combo.

There is no such thing as a simple job.

\start
Date: Wed, 9 May 2007 09:27:32 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: git-svn

>Are you sure you can't commit. 
>I see a commit to the daly branch

Yes, the commit to the daly branch was a test to make sure that
I had the correct permissions. It used the svn client directly.
The git-svn connection does everything except commit. I'm still
puzzled about it.

\start
Date: Wed, 09 May 2007 10:53:21 -0400
From: Bill Page
To: Tim Daly
Subject: Re: git-svn

Quoting Tim Daly:

>> Are you sure you can't commit. 
>> I see a commit to the daly branch
>
> Yes, the commit to the daly branch was a test to make sure that
> I had the correct permissions. It used the svn client directly. 
> The git-svn connection does everything except commit. I'm still
> puzzled about it. 
>

Tim, what version of git are you using? I see the following change
log comment for GIT v1.5.0-rc2:

http://www.gossamer-threads.com/lists/engine?do=post_view_printable;post=724880;list=linux

   Eric Wong (2):
   ... 
   git-svn: print and flush authentication prompts to STDERR

which might relate to the symptoms you described. See also:

http://www.gelato.unsw.edu.au/archives/git/0611/32475.html

If your version is older you might try to upgrade. The current verison
is v1.5.1.4. 

\start
Date: Wed, 9 May 2007 23:32:17 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Issue 351

I wonder what shall we do with issue 351.  One "solution" is to
say that this is just user error: COMPLEX PF 5 is not a field
(has zero divisors) so by GIGO principle the result is
correct (one could say that crashing prevents producing wrong
answers...).

But we probably want do better.  One possibility is to prevent
creation of fake fields: when creating COMPLEX F we may try
to check if x^2 - 1 is irreducible over F.  In general this
may be hard to check, but just looking at characteristic we
can reject PF 5 cheaply.

Another possibility is to look at the reason of crash.  In
Factored we have:
...
        if R has UniqueFactorizationDomain
          then
            coerce(r:R):% ==
              zero? r => 0
              unit? r => mkFF(r, empty())
              unitNormalize(squareFree(r) pretend %)
...

and in Field we have:

  squareFree x == x::Factored(%)

Every element of true field is a unit, so the third line of coerce
should be never executed for fields.  But 1 + 2*%i is a zero
divisor in COMPLEX PF 5, and the test in the second line of coerce
fails.  So we could change coerce so that it signals error if
R is claimed to be field, but test for unit fails:

...
        if R has UniqueFactorizationDomain
          then
            coerce(r:R):% ==
              zero? r => 0
              unit? r => mkFF(r, empty())
              if R has Field => error "zero divisor in a field"
              unitNormalize(squareFree(r) pretend %)
...

\start
Date: Wed, 09 May 2007 19:29:48 -0400
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Desired functionality from noweb

>>>> Try
>>>> %---BEGIN aaa.pamphlet
>>>> <<*>>=
>>>> <<X>>
>>>> A
>>>> @
>>>> <<X>>=
>>>> EFG
>>>> @
>>>> <<*>>=
>>>> B
>>>> @
>>>> <<C>>=
>>>> UVW
>>>> @
>>>> %---END aaa.pamphlet
>>>>
>>>> notangle aaa.pamphlet
>>>> EFG
>>>> A
>>>> UVW
>>>> B
>>> Ugh.  I don't think this is a style of LP we should use.
>> Why not? Well, it was just an example, but I don't think that a 
>> continued code junk is a terribly bad idea. I would only require that
>> braces are paired within each chunk.
> 
> Non-unique root node definitions in a file will increase complexity. 
> Ideally all code chunks in a program would have unique chunk names - at
> the very least, anything part of a particular tangle operation should
> have a unique name.  I expect to run tangle once per <<*>> defined, and
> I expect one <<*>> per file (or "project" if you prefer.)  Perhaps
> there are reasons not to do that but I'm not seeing it right now.

Well, amusingly enough, I tried it in cl-web and the code seems to
already exhibits the behavior above ;-).  So if anyone wants to do that
they can.

I think I understand better now what you were saying - as opposed to
breaking a chunk definition down into sub chunks which are included in a
toplevel chunk, you simply have a single chunk with its definition
spread through the file, with the scan identifying where the pieces are
and putting them together.

\start
Date: Thu, 10 May 2007 02:55:50 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Compiler speed

Martin Rubey wrote:
> Unfortunately, I do not have the time to check this now.  Maybe you could
> compile some mini domain or package, quit axiom, delete libdb.text, start
> axiom, )lib MINIDOMAIN, and check whether HyperDoc finds MINIDOMAIN, or,
> hopefully equivalently, libdb.text contains the necessary information.
> 

I have checked this now using a trivial category.  Both before appling a
patch and after:

1) compailing a file updated local libdb.text
2) )lib command _do not_ update libdb.text
3) Even if local libdb.text is absent after issuing )lib command HyperDoc
   finds new constructors.

AFAICS libdb.text is only needed for installed files -- because we
do not install .NRLIB directories.  )lib can find documentation in
index.KAF file, so it does not need local libdb.text.  Given that
I think that we may just skip generating local libdb.text.  More
precisely extendLocalLibdb function looks at $createLocalLibDb
flag.  We can set this flag to nil -- extendLocalLibdb will then
return immediately without doing anything.  Users needing libdb.text
can still set $createLocalLibDb to true get old behaviour.

\start
Date: Wed, 9 May 2007 18:39:02 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: cl-web v0.7

I'm not sure this really deserves a release, but I may not be able to
work on this for a week so I'll go ahead and put it out there.

Tim sent me some corrections and stylistic suggestions - I've tried to
incorporated some of that here.  Major difference is quoting in macros
is now saner.

I added some code for indexing chunks (just chunks, not defs in chunks)
and that seems to work OK.  It's pretty trivial at this stage.  At some
point we might want to look at the multiple-index LaTeX packages so we
can do chunks, regular (if we have pamphlets big enough to need it),
and code definitions if we get that working.

At this point, there are a couple of things to do.  The obvious one is
to get line number output working in tangle and that's just a matter of
going back and turning all the right stuff on in various states.  Less
obvious is the possibility of listing at the bottom of a chunk which
chunk(s) include it - is that of interest to us?  It is a bit of work
but not terribly difficult.

I know the one we really want is code based documentation - i.e.
awareness of what's inside the code chunks.  I noticed that sbcl got
xref support Dec. 2006, and there is also an experimental package
called sb-introspection developed for SLIME.  I'm not completely sure
what these are capable of, but they might be usable for generating the
kind of information we are looking for.  That's a longer term effort at
best - sb-introspection is not really documented or aimed at general
use yet, so there is some exploring to do.  SLIME is worth a look to
see how it supports the sb-introspection features in other lisps. 
CMUCL might be workable as well.

\start
Date: Wed, 9 May 2007 18:40:27 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Re: cl-web v0.7

> I'm not sure this really deserves a release, but I may not be able to
> work on this for a week so I'll go ahead and put it out there.

Oh, here are the links:

http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.7.lisp.pdf
http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.7.tar.gz

\start
Date: Thu, 10 May 2007 05:05:46 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: PFE, Complex and INT

Martin Rubey wrote:
> Dear all,
> 
> regarding Issue #352 and possibly #351, I experimented a little.  The starting
> point is the documentation of PFECAT, in catdef.spad:
> 
> )abbrev category PFECAT PolynomialFactorizationExplicit
> ++ Author: James Davenport
> ++ Description:
> ++ This is the category of domains that know "enough" about
> ++ themselves in order to factor univariate polynomials over themselves.
> ++ This will be used in future releases for supporting factorization
> ++ over finitely generated coefficient fields, it is not yet available
> ++ in the current release of axiom.
> 
> Many domain constructors like, for example, Complex export PFECAT, with the
> condition that their arguments has PFECAT and possibly satisfies some other
> conditions, too.  However, at the moment, not even Integer exports PFECAT, so,
> in effect, it is not yet used.  Curiously, it implements most of the operations
> needed, so I'd think we could simply make Integer or rather IntegerNumberSystem
> export PFECAT.
>

I think that this requres deeper investigation.  Namely, gcd and
factorization is currently provided by different packages using somewhat
different method.  We have to check which method is better and turn it
on.  Also, it looks that in the meantime better algorithms appeared,
so we may prefer to implement them and forget abot old ones.

> A related category is UniqueFactorizationDomain, also defined in catdef:
> 
> )abbrev category UFD UniqueFactorizationDomain
> ++ A constructive unique factorization domain, i.e. where
> ++ we can constructively factor members into a product of
> ++ a finite number of irreducible elements.
> 
> What I really wanted is to be able to say
> 
> (5) -> 2::FR COMPLEX INT
> 
>                      2
>    (5)  - %i (1 + %i)
>                                                Type: Factored Complex Integer
> 
> So, I modified COMPCAT as follows, i.e., since I don't know about square free
> factorization, I just used factor.
> 
> I'd be very interested in comments.
> 
> Martin
> 
> diff -c /home/martin/lib/axiom/target/i686-pc-linux/src/algebra/gaussian.spad
> /home/martin/gaussian.spad
> *** /home/martin/lib/axiom/target/i686-pc-linux/src/algebra/gaussian.spad
> 2007-05-02 20:39:25.000000000 +0200
> --- /home/martin/gaussian.spad  2007-05-03 09:30:12.000000000 +0200
> ***************
> *** 91,96 ****
> --- 91,97 ----
>            ++ "failed" if x is not a rational number.
>        if R has PolynomialFactorizationExplicit and R has EuclideanDomain then
>           PolynomialFactorizationExplicit
> +      if R has UniqueFactorizationDomain then UniqueFactorizationDomain

                  ^^^^^^^^^^^^^^^^^^^^^^^^^

That looks like overgeneralization.  First, Complex R may have zero
divisors (so we will hit bug 351).  Even if Complex R is an integral
domain, it is not clear if it has unique factorization (do you know
about any theorem asserting this?).  Finally, even if Complex R
has unique factorization AFAICS we do not have any factorization
algorithm working in Complex R.  So I would just write:

        if R is Integer then UniqueFactorizationDomain
  
which seem to agree with implementation.

>    add
>          import MatrixCategoryFunctions2(%, Vector %, Vector %, Matrix %,
>                                          R, Vector R, Vector R, Matrix R)
> ***************
> *** 116,121 ****
> --- 117,130 ----
>                --!gcdPolynomial(pp,qq) == modularGcd(pp,qq)$TT
>                solveLinearPolynomialEquation(lp:List Sup,p:Sup) ==
>                  solveLinearPolynomialEquation(lp,p)$ComplexIntegerSolveLinearPolynomialEquation(R,%)
> + 
> +              squareFree x == 
> +                y: Complex Integer := complex(convert(real x)@Integer, 
> +                                              convert(imag x)@Integer)
> +                z: Factored Complex Integer :=
> factor(y)$GaussianFactorizationPackage
> +                mf: Complex Integer -> % := complex(real(#1)::R, imag(#1)::R)
> +                map(mf #1, z)$FactoredFunctions2(Complex Integer, %)
> + 
>             normPolynomial: Sup -> SupR
>             normPolynomial pp ==
>                 map(retract(#1@%)::R,pp * map(conjugate,pp))

\start
Date: 10 May 2007 08:28:40 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Compiler speed

Waldek Hebisch writes:

> Martin Rubey wrote:
> > Unfortunately, I do not have the time to check this now.  Maybe you could
> > compile some mini domain or package, quit axiom, delete libdb.text, start
> > axiom, )lib MINIDOMAIN, and check whether HyperDoc finds MINIDOMAIN, or,
> > hopefully equivalently, libdb.text contains the necessary information.
> > 
> 
> I have checked this now using a trivial category.  Both before appling a
> patch and after:
> 
> 1) compailing a file updated local libdb.text
> 2) )lib command _do not_ update libdb.text

but, it seems to me, if there is no libdb.text and I issue )lib, then
libdb.text will be created.  Do you observe different behaviour?

Note that I do not care about *updating* libdb.text, but only about
creation. The idea is: I contribute a package, the user compiles it -- either
from within axiom, but more likely using aldor, and he's got a libdb.text.

> 3) Even if local libdb.text is absent after issuing )lib command HyperDoc
>    finds new constructors.

I thought that issuing )lib would create libdb.text. At least, that's what I
observed until now.
 
> AFAICS libdb.text is only needed for installed files -- because we
> do not install .NRLIB directories.  )lib can find documentation in
> index.KAF file, 

Hm, but if I generate my library using the aldor compiler (externally),
index.KAF is *not* created, but HyperDoc (and getDatabase) still finds the
docstrings.

\start
Date: 10 May 2007 08:53:56 +0200
From: Martin Rubey
To: Bill Page
Subject: indentation on MathAction

Dear Bill,

since some time (I don't know when), MathAction doesn't respect blanks in
verbatim text anymore.  I.e.,

test::

  asdasd  asdasdsadasd
      asd     asda

is the same as

test::

 asdasd asdasdsadasd
 asd asda

Do you think you could correct this?  It's quite a pain to quote source code
this way.

In fact, maybe the better version would be to introduce a new enviroment

\begin{source}...\end{source}

that causes text to be typeset verbatim.  But, contrary to the verbatim
environment, it should not cause the text to be rendered as a picture...

\start
Date: 10 May 2007 09:02:34 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: PFE, Complex and INT

many thanks for looking into this.  Unfortunately, I'm an absolute beginner
concerning factorization and number theory, as you probably noticed...

Waldek Hebisch writes:

> Martin Rubey wrote:
> > Dear all,
> > 
> > regarding Issue #352 and possibly #351, I experimented a little.  The starting
> > point is the documentation of PFECAT, in catdef.spad:

[...]

> I think that this requres deeper investigation.  Namely, gcd and
> factorization is currently provided by different packages using somewhat
> different method.  We have to check which method is better and turn it on.
> Also, it looks that in the meantime better algorithms appeared, so we may
> prefer to implement them and forget abot old ones.

Definitively.  But, lacking somebody who knows about these things (or do you?),
what can we do?  For myself, it's also a matter of time.

By the way, a collegue (Dietrich Burde, a number theorist) experimented a
little with various packages like pari, maple, mathematica, reduce, etc., what
algorithms they use for factoring integers.  It turned out that pari is by far
the most intelligent package.  I believe we should interface to pari,
therefore...

> > diff -c /home/martin/lib/axiom/target/i686-pc-linux/src/algebra/gaussian.spad
> > /home/martin/gaussian.spad
> > *** /home/martin/lib/axiom/target/i686-pc-linux/src/algebra/gaussian.spad
> > 2007-05-02 20:39:25.000000000 +0200
> > --- /home/martin/gaussian.spad  2007-05-03 09:30:12.000000000 +0200
> > ***************
> > *** 91,96 ****
> > --- 91,97 ----
> >            ++ "failed" if x is not a rational number.
> >        if R has PolynomialFactorizationExplicit and R has EuclideanDomain then
> >           PolynomialFactorizationExplicit
> > +      if R has UniqueFactorizationDomain then UniqueFactorizationDomain
> 
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> That looks like overgeneralization.  First, Complex R may have zero
> divisors (so we will hit bug 351).  Even if Complex R is an integral
> domain, it is not clear if it has unique factorization (do you know
> about any theorem asserting this?).  Finally, even if Complex R
> has unique factorization AFAICS we do not have any factorization
> algorithm working in Complex R.  So I would just write:
> 
>         if R is Integer then UniqueFactorizationDomain
>   
> which seem to agree with implementation. 

Yes.  Maybe, IntegerNumberSystem, though.  (I think we want to support
factorization in Complex SingleInteger, too.

\start
Date: Thu, 10 May 2007 23:22:19 +0200
From: Frederic Lehobey
To: list
Subject: Axiom at LSM 2007?
Cc: Frederic Lehobey

Dear Axiom developers and users,

Would any of you be interested in giving a lecture on Axiom or Axiom
use cases at the following free software conference (in France, this
summer).

We have put this year some emphasis on numerical simulations (finite
elements, CFD, etc.) but, as every year, the session is open to every
scientific fields.

We expect some high profile users of scientific computing as
speakers. Preliminary programme should be available in the coming days
(actually we are late: it should already have been published) :-) but
we are still open to new submissions.

Last talk about Axiom in this conference goes back to 2003 when Tim
gave a lecture in Metz. Many things have happened in the Axiom
community since then.

I have already sent this call to people from SAGE and intend doing the
same with Maxima people, but if you see people or projects that you
feel would be interested in, please forward this call to them.

Best regards,
Fr=E9d=E9ric Lehobey -- for the 2007 team of volunteers of topic 'Science=
,
Research and Medicine' of the LSM.

[Fran=E7ais plus bas -- French below]

-----------------------------------------------------------------------
Call for contributions to the 'Science, Research and Medicine=B9' topic
of the 8th libre software meeting (in Amiens, France, July 2007 10th
to 14th). http://www.rmll.info/article28.html
-----------------------------------------------------------------------
The Libre Software Meeting is a yearly free software event that takes
place in summer in France since 2000 (originating from Bordeaux, this
event is driven by volunteers from the free software community). The
LSM 2007 takes place this year in Amiens, from July 10th to 14th:

  http://www.rmll.info/

This message is a call for contributions to the 'Science, Research and
Medicine=B9' topic of the LSM.

The goal of this topic is to highlight free software that is currently
used in scientific research or that, by its quality, deserves a wider
adoption. We aim to establish contacts between people from the
different communities -- free software developers, researchers,
scientists, engineers and users -- to discuss recent projects and
their place in the future free software community, in research and in
technology. We also invite interested people who don't feel scientific
experts to join us.

We put some focus this year on numerical simulation in physics and
engineering but any experience related to free software and science is
welcomed in this topic (including mathematics, chemistry, biology,
etc.)

English is the expected language for the lectures of the 'Science'
topic though (if nobody objects in the audience) some talks might be
in French with at least the slides in English.

Talks are expected to last 25 minutes (+ 15 minutes of questions).
Printable version of the lecture are not mandatory but would be very
appreciated.

If you are considering coming and submitting a talk, please send us as
soon as possible an email at the following address:

  Frederic Lehobey

with an English summary of your talk (and a French one if you can, but
if not, we will translate the English one). Feel free to send this
announcement wherever or to whom you feel it is relevant (but beware
of spamming people). We apologise for this late notice less than 3
months before the event.

We have very limited funding for the travels (only for speakers that
cannot be refunded by the institution they belong to) but there are no
registration fees for the conference and usually very low cost housing
(in students houses) is organised on the site (please take care of
registering early enough for your room).

The RMLL 2007 team of volunteers organising this 'Science' topic:
Jean-Marie Favreau, Ursula Teubert, Fr=E9d=E9ric Lehobey, Isabelle Ramade=
,
Alain Coulais, Val=E9rie-Emma Leroux, Jean-Philippe Gaulier, Jean
Thi=E9ry, Nicolas Limare and Simion Pruna (Medicine)

1. Please notice that a specific call for the Medicine sub-topic has
already been issued by Simion Pruna in charge of this part. See
http://atlas.ici.ro/ehto/LSM.htm

\start
Date: 12 May 2007 01:16:57 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Issue 351

Dear Waldek,

Waldek Hebisch writes:

> I wonder what shall we do with issue 351.

[...]

> One possibility is to prevent creation of fake fields: when creating COMPLEX
> F we may try to check if x^2 - 1 is irreducible over F.  In general this may
> be hard to check, but just looking at characteristic we can reject PF 5
> cheaply.

I just tried to find out when x^2+1 factors in a finite field, but it seems
that the characteristic is not enough to determine this.  

It seems that

* For prime fields with characteristic p, x^2+1 factors if and only if 
  p mod 4 = 1

* More generally, for finite fields with p^m elements and m odd, x^2+1 factors
  if p mod 4 = 1, if m is even, x^2+1 always factors.

Maybe for infinite fields we just try to factor(x^2+1) and check the number of
factors.

However, there is a problem: currently, SPAD does not allow conditional exports
being triggered by functions, but only by "has" and "is" statements, it seems.
At least, I couldn't find an example, nor could I make up one.

:-(

\start
Date: Sat, 12 May 2007 01:58:56 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: a little category theory and inductive types
Cc: Gabriel Dos Reis

Ralf,

I have updated my example of one way to write an inductive type (as
per our recent discussion with Gaby) so that I hope the structure
of the definition is more clear. See:

http://wiki.axiom-developer.org/SandBoxAldorInductiveTypes

In particular I found it convenient to first implement an extension
of Aldor's Union type to make it more "categorical", i.e. as a
true co-product in the sense of category theory. See

http://wiki.axiom-developer.org/SandBoxLimitsAndColimits

This exercise makes me think that there may be a potential for
developing a new library in Aldor and domains in Spad that would
provide these and similar categorical constructs.

I would be most interested in your comments on this approach.

\start
Date: Sat, 12 May 2007 10:57:12 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: a little category theory and inductive types
Cc: Gabriel Dos Reis

Hi Bill,

I somehow don't know where to start with my comments. But let me first 
say something about

http://wiki.axiom-developer.org/SandBoxLimitsAndColimits

What you have actually done is a restricted implementation of Record 
with the addition of the (unique) arrow from (A, f:A->X, g:A->Y)  into 
the product X \times Y.

I like that implementation of this arrow, but I am not so sure about 
where I would use it. (But that is another question.)
Ah... now I see it. It's a way to contruct an element of a product.

You probably see yourself, that your Product implementation has a number 
of limitations in contrast to Record.

1) Suppose you have A=X=Y=Integer and
    f(a: A): X == a,
    g(a: A): X == a+1,
    Then construct for P ==> Product(Integer, Integer)
      h: A -> P := product(Integer, f, g)
    What result do you expect for project(h 0)?

    For Record(a:A,b:B,...) the projection functions are basically
    apply: (%, 'a') -> A
    apply: (%, 'b') -> B
    ...
    and thus all have different names.

2) You have to implement a domain "Product" for each arity. Record
    allows arbitrary arities.

In fact, (2) for me is a limitation of the Aldor language. One could, 
perhaps define

Product(T: Tuple Type): with {...} == add {...}

but I have no good way to express the projection functions. If someone 
knows, please tell me.

Let me also add a warning to the code on

http://wiki.axiom-developer.org/SandBoxAldorInductiveTypes

In your "extend" code you use a definiton of "Rep" again.

extend MkAdd(X:ExprCat,Y:ExprCat): with
     +: (X,Y) -> %
   == add
     Rep==Record(left:X,right:Y)
     import from Rep
     ((x:X) + (y:Y)):% == per [x,y]

That is dangerous! An initial domain definition might live in quite 
another (let's say third party) library. How would you "extend" if you 
don't have the sources of the original definition. But even with the 
sources it is a bad idea to mention "Rep" in an "extend". If this is 
necessary, then the original (unextended) definition does not have 
enough functionality.

On 05/12/2007 07:58 AM, Bill Page wrote:
> Ralf,
> 
> I have updated my example of one way to write an inductive type (as
> per our recent discussion with Gaby) so that I hope the structure
> of the definition is more clear. See:
> 
> http://wiki.axiom-developer.org/SandBoxAldorInductiveTypes
> 
> In particular I found it convenient to first implement an extension
> of Aldor's Union type to make it more "categorical", i.e. as a
> true co-product in the sense of category theory. See
> 
> http://wiki.axiom-developer.org/SandBoxLimitsAndColimits
> 
> This exercise makes me think that there may be a potential for
> developing a new library in Aldor and domains in Spad that would
> provide these and similar categorical constructs.
> 
> I would be most interested in your comments on this approach.

\start
Date: Sat, 12 May 2007 11:35:04 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: categorial rep and per?

On

http://wiki.axiom-developer.org/SandBoxLimitsAndColimits

you write

 > I am especially interested in how the duality between rep and per
 > is involved in these constructions.

My answer is: I don't know.
And I also don't know why you think that per and rep is something 
categorial.

Suppose I have a domain R with some exports CatR. And I define for some 
other exports CatD a domain

D: CatD == add {
   Rep == R;
   ...
}

rep and per relate R with D (basically saying that they are the same 
things as data structures with no features). But their exports have no 
relation at all. Mathematically seen, they are objects of different 
categories. So rep and per would be functors (if anything). But how can 
such a construction be made functorial. I don't see that.

\start
Date: Sat, 12 May 2007 11:29:09 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: a little category theory and inductive types
Cc: Gabriel Dos Reis

Ralf,

On May 12, 2007 4:57 AM you wrote:
> 
> I somehow don't know where to start with my comments. But let
> me first say something about
> 
> http://wiki.axiom-developer.org/SandBoxLimitsAndColimits
> 

Thank you for taking the time to reply.

> What you have actually done is a restricted implementation
> of Record with the addition of the (unique) arrow from
> (A, f:A->X, g:A->Y)  into the product X \times Y.

A categorical "arrow" is just a function. Formally I want to
view Aldor and Spad as working in the category Set or at the
very least the associate Cartesian Closed Category.

You are speaking here about the limit called Product. Of
course similar (dual) comments also follow concerning the
co-limit Sum. Duality is one of the fundamental properties
of this categorical approach - you always get two
constructions for the price of one. In any given situation
you are often in a position of wondering about the meaning
and use of the dual construction.

Concerning Product. Yes, you are right. Product is just an
implementation of Record, or actually I would wish to reverse
that: Record should be an implementation of Product. In fact
from the point of view of category theory (or perhaps I should
say "categorical semantics") it is the existence of this unique
definition for the function 'product(A, f:A->X, g:A->Y)' that
defines what we mean by the domain Product and it's projections.

Really these are just different names for the same things,
respectively. The only real problem is that Record and Union
do not provide the naturally associated universal function.

> 
> I like that implementation of this arrow, but I am not so
> sure about where I would use it. (But that is another
> question.) Ah... now I see it. It's a way to construct an
> element of a product.

Think of the function return by 'product(A,f,g)' as a way to
evaluate both f and g in *parallel* over A. Similarly, the
dual construct 'sum(A,f,g)' is a way to evaluate both f and
g in *series* into A.

> 
> You probably see yourself, that your Product implementation 
> has a number of limitations in contrast to Record.
> 
> 1) Suppose you have A=X=Y=Integer and
>     f(a: A): X == a,
>     g(a: A): X == a+1,
>     Then construct for P ==> Product(Integer, Integer)
>       h: A -> P := product(Integer, f, g)
>     What result do you expect for project(h 0)?
>

Yes that is easily remedied by defining the projections as
'project1', 'project2', ... similarly 'inject1', 'inject2'.
I should have done it this way.
 
>     For Record(a:A,b:B,...) the projection functions are
>     basically
>       apply: (%, 'a') -> A
>       apply: (%, 'b') -> B
>     ...
>     and thus all have different names.
> 

This use of enumerators seem awkward to me when what I really
want is a cross product and disjoint union. I don't really
want to have to specify these sort of "tags". But if the
definition of Record(a:A,b:B, ... ) actually defined a, b,
... as the projections:

  a: Record(a:A,b:B, ...) -> A
  b: Record(a:A,b:B, ...) -> A

then I would have much less complaint. Similarly

  a: A -> Union(a:A,b:B ...)
  b: A -> Union(a:A,b:B ...)

would be the injections (union function) into the Union.
But this would be a substantial change to the syntax and
semantics of Aldor and Spad.

> 2) You have to implement a domain "Product" for each
>    arity. Record allows arbitrary arities.
> 
> In fact, (2) for me is a limitation of the Aldor language.
> One could, perhaps define
> 
> Product(T: Tuple Type): with {...} == add {...}
> 
> but I have no good way to express the projection functions. 
> If someone knows, please tell me.

Yes, I also tried this. Perhaps it can be defined in a
recursive manner, but I got stuck in the details and ran
out of mental energy before seeing the best way to do it.

At least in Aldor it is possible to overload domain
constructors. Spad on the other hand complains if I give
two definitions for 'Product', so I am forced to define
'Product2', 'Product3', etc.

But this would not be a problem for the Spad and Aldor
compilers since they already do this for Record and Union.
Like I said, all that is missing is the associated universal
functions.

> 
> Let me also add a warning to the code on
> 
> http://wiki.axiom-developer.org/SandBoxAldorInductiveTypes
> 
> In your "extend" code you use a definition of "Rep" again.
> 
> extend MkAdd(X:ExprCat,Y:ExprCat): with
>      +: (X,Y) -> %
>    == add
>      Rep==Record(left:X,right:Y)
>      import from Rep
>      ((x:X) + (y:Y)):% == per [x,y]
> 
> That is dangerous! An initial domain definition might live
> in quite another (let's say third party) library. How would
> you "extend" if you don't have the sources of the original
> definition. But even with the sources it is a bad idea to
> mention "Rep" in an "extend". If this is necessary, then
> the original (unextended) definition does not have enough
> functionality.
>

You are absolutely right. My example of the use of extend
is deficient. I like correct this as soon as I get another
hour to spare.
 
> 
> On 05/12/2007 07:58 AM, Bill Page wrote:
> > Ralf,
> > 
> > I have updated my example of one way to write an inductive
> > type (as per our recent discussion with Gaby) so that I hope
> > the structure of the definition is more clear. See:
> > 
> > http://wiki.axiom-developer.org/SandBoxAldorInductiveTypes
> > 
> > In particular I found it convenient to first implement an
> > extension of Aldor's Union type to make it more "categorical",
> > i.e. as a true co-product in the sense of category theory.
> > See
> > 
> > http://wiki.axiom-developer.org/SandBoxLimitsAndColimits
> > 
> > This exercise makes me think that there may be a potential
> > for developing a new library in Aldor and domains in Spad
> > that would provide these and similar categorical constructs.
> > 
> > I would be most interested in your comments on this approach.
> > 

\start
Date: Sat, 12 May 2007 12:13:36 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: categorial rep and per?

On May 12, 2007 5:35 AM Ralf Hemmecke wrote:
> 
> On
> 
> http://wiki.axiom-developer.org/SandBoxLimitsAndColimits
> 
> you write
> 
> > I am especially interested in how the duality between rep
> > and per is involved in these constructions.
> 
> My answer is: I don't know.

What I mean specifically is:

    project1(x:%):X == rep(x).a
    project2(x:%):Y == rep(x).b
    product(A:Type,f:A->X,g:A->Y):(A->%) ==
       (x:A):% +-> per [f(x),g(x)]

versus

    inject1(x:X):% == per [a==x]
    inject2(y:Y):% == per [b==y]
    sum(A:Type,f:X->A,g:Y->A):(%->A) ==
       (x:%):A +->
         rep(x) case a => f(rep(x).a)
         rep(x) case b => g(rep(x).b)
         never

Do you see how rep is used in the definition of 'project' but
per is used in the definition of 'inject'? And opposite in the
definitions of 'product' and 'sum'? I just thought that was a
little unexpected (to me) by-product of the duality.

> And I also don't know why you think that per and rep is
> something categorial.

Categorical in the sense of category theory - not necessarily
in the sense of category used in Axiom/Aldor. I guess I could
put it this way: I *want* to find a categorical definition of
rep and per because I do not fully understand why they appear
in Spad and Aldor but not in any other "object-oriented"
language with which I am familiar. I think (perhaps) that Spad
has made something explicit that is in fact implicit in these
other programming languages. Making this explicit is a good
thing, but I am not completely confident that the current
implementation - as a distinguished name 'Rep' and macros
'rep' and 'per'. I would like (perhaps) an appropriate
categorical semantics for rep and per and maybe some other
syntax in the Spad/Aldor language that properly distinguishes
this construct -- after all, this notion is central to the
implementation of abstract algebra in Axiom.

I tried to do something like this a while ago in

http://wiki.axiom-developer.org/RepAndPer

Perhaps it needs a little updating since I wrote it.

> 
> Suppose I have a domain R with some exports CatR. And I 
> define for some other exports CatD a domain
> 
> D: CatD == add {
>    Rep == R;
>    ...
> }
> 
> rep and per relate R with D (basically saying that they
> are the same things as data structures with no features).
> But their exports have no relation at all.

Their exports are in fact related by the logic that is
implemented in ...

Exports are arrows.

> Mathematically seen, they are objects of different 
> categories. So rep and per would be functors (if
> anything). But how can such a construction be made
> functorial. I don't see that.
> 

It is necessary to define more clearly I think what
*mathematical* category we are talking about. I was arguing
in RepAndPer that yes rep and per are adjoint functors in
a categorical sense. I still think that might be a fruitful
point of view.

\start
Date: 12 May 2007 11:15:00 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] Char and DFlo types

  The attached patch make depsys buildable with CLISP.

string-char is a cltl1 ttype, it is not part of ANSI Lisp.
In ANSI Lisp, we have the "character" type, which is further
divided into the subtypes "base-char" and "extended-char".
Here, I've replaced "string-char" with the general "character"
types.

I have already raised the issue about the use of long-float as the
underlying type of DFlo.  I believe that is wrong, from portability
point of view, and that the underlying type should be double-float.
However, this patch just changes 0.0d0 (which is of type double-float)
to 0.0l0 (of type long-float) to match the existing underlying type
of DFlo.  We should revisit the definition of DFlo and Float
in separate thread.

compiler-let is a cltl thingy.  It is not ANSI Lisp.  We should
try to avoid it where we can.  This patch just import the symbol 
from EXT when using CLISP and base Lisp runtime.


build and tested on an i686-pc-linux-gnu.
Applied to build-improvements.

-- Gaby



2007-05-12  Gabriel Dos Reis  Gabriel Dos Reis

	* bootfuns.lisp.pamphlet: Work around non-portable codes.
	* foam_l.lisp.pamphlet: Replace type "string-char" with type
	"character".
	Replace "0.0d0" with "0.0l0" because DFlo is actually long-float,
	not double-float.


*** README.build-improvements	(revision 20987)
--- README.build-improvements	(local)
*************** Gabriel Dos Reis
*** 71,76 ****
--- 71,79 ----
  === TODO ===
  ============
  
+ * Revisit the underlying definition of the types DFlo in foam
+   interface, and Float in Axiom.
+ 
  * Audit all codes that manipulate sockets.
  
  * Automate the process of "optimized" Axiom: this requires a two-pass
*************** Gabriel Dos Reis
*** 159,164 ****
--- 162,174 ----
  * Build on Windows platforms, more specifically MSYS/MinGW, is
    supported.
  
+ * Components known to build with various Lisp implementations:
+    + bootsys: GCL, SBCL, CLISP
+    + depsys: GCL, CLISP
+    + interpsys: GCL
+    + AXIOMsys: GCL
+ 
+ 
  ================================================
  === New Boot vs. Old Boot compatibility notes ==
  ================================================

*** src/interp/bootfuns.lisp.pamphlet	(revision 20987)
--- src/interp/bootfuns.lisp.pamphlet	(local)
***************
*** 1,16 ****
  \documentclass{article}
  \usepackage{axiom}
! \begin{document}
! \title{\$SPAD/src/interp bootfuns.lisp}
  \author{Timothy Daly}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
  \section{Constants}
  \subsection{\$EmptyMode}
  [[$EmptyMode]] is a contant whose value is [[$EmptyMode]].
  It is used by [[isPartialMode]] (in [[i-funsel.boot]]) to
  decide if a modemap is partially constructed. If the [[$EmptyMode]]
--- 1,23 ----
+ %% Oh Emacs, this is a -*- Lisp -*- file despite apperance.
  \documentclass{article}
  \usepackage{axiom}
! 
! \title{\File{src/interp/bootfuns.lisp} Pamphlet}
  \author{Timothy Daly}
+ 
+ \begin{document}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
+ 
+ 
  \section{Constants}
+ 
  \subsection{\$EmptyMode}
+ 
  [[$EmptyMode]] is a contant whose value is [[$EmptyMode]].
  It is used by [[isPartialMode]] (in [[i-funsel.boot]]) to
  decide if a modemap is partially constructed. If the [[$EmptyMode]]
*************** which will walk the structure $Y$ lookin
*** 22,27 ****
--- 29,51 ----
  (def-boot-val |$EmptyMode| '|$EmptyMode|    "compiler constant")
  @
  
+ 
+ \section{Portability issues}
+ 
+ This section discusses some portability issues known to affect
+ this module.
+ 
+ \subsection{[[compiler-let]]}
+ 
+ The construct [[compiler-let]] is not part of ANSI Lisp, although
+ it had been described in CLTL.  Therefore some Lisp implementations
+ offer it as extensions.
+ 
+ <<non-portable-codes>>=
+ #+:clisp (import 'ext:compiler-let)
+ @
+ 
+ 
  \section{License}
  <<license>>=
  ;; Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
*************** which will walk the structure $Y$ lookin
*** 66,71 ****
--- 90,97 ----
  
  (in-package "BOOT")
  
+ <<non-portable-codes>>
+ 
  (defmacro def-boot-fun (f args where)
    `(compiler-let nil
       (defun ,f ,args ,where (print (list ',f . ,args)))
*** src/interp/foam_l.lisp.pamphlet	(revision 20987)
--- src/interp/foam_l.lisp.pamphlet	(local)
***************
*** 168,174 ****
  
  
  ;; type defs for Foam types
! (deftype |Char| () 'string-char)
  (deftype |Clos| () 'list)
  (deftype |Bool| () '(member t nil))
  (deftype |Byte| () 'unsigned-byte)
--- 168,174 ----
  
  
  ;; type defs for Foam types
! (deftype |Char| () 'character)
  (deftype |Clos| () 'list)
  (deftype |Bool| () '(member t nil))
  (deftype |Byte| () 'unsigned-byte)
***************
*** 206,212 ****
  (defconstant |SIntInit| (the |SInt| 0))
  (defconstant |BIntInit| (the |BInt|  0))
  (defconstant |SFloInit| (the |SFlo| 0.0s0))
! (defconstant |DFloInit| (the |DFlo| 0.0d0))
  (defconstant |PtrInit|  (the |Ptr|  nil))
  (defconstant |ArrInit|  (the |Arr|  nil))
  (defconstant |RecordInit|  (the |Record|  nil))
--- 206,213 ----
  (defconstant |SIntInit| (the |SInt| 0))
  (defconstant |BIntInit| (the |BInt|  0))
  (defconstant |SFloInit| (the |SFlo| 0.0s0))
! ;; FIXME: Revisit the definition of DFlo as long-double.
! (defconstant |DFloInit| (the |DFlo| 0.0l0))
  (defconstant |PtrInit|  (the |Ptr|  nil))
  (defconstant |ArrInit|  (the |Arr|  nil))
  (defconstant |RecordInit|  (the |Record|  nil))

\start
Date: Sat, 12 May 2007 20:14:27 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: a little category theory and inductive types
Cc: Gabriel Dos Reis

Hi Bill,

>> http://wiki.axiom-developer.org/SandBoxLimitsAndColimits

>> What you have actually done is a restricted implementation
>> of Record with the addition of the (unique) arrow from
>> (A, f:A->X, g:A->Y)  into the product X \times Y.

OK, let me give the following definition.

extend Record(T: Tuple Type): with {
	product(A: Type, f: MAP(A -> ?)(T)) -> (A -> %);
} == add {
	product(...): A -> % ==
}

Maybe you can guess what I wanted.

You have
     product: (A:Type, A->X,A->Y) -> (A->%)
for the bivariate case.

I wanted to put (A->X, A->Y) into a generic tuple. (Which would be 
constructed by this MAP constructor (wishful thinking) which maps the 
function U -> (A->U) over the tuple T.

So if T=(X,Y) then MAP(A -> ?)(T) should be the same as (A->X,A->Y).

Unfortunately, Aldor doesn't allow such a constructor. (Or if somebody 
happens to know how to define MAP, then let me know.) Hence, I cannot 
extend Record in the above fashion. That is clearly a limitation of Aldor.

> You are speaking here about the limit called Product. Of
> course similar (dual) comments also follow concerning the
> co-limit Sum. Duality is one of the fundamental properties
> of this categorical approach - you always get two
> constructions for the price of one. In any given situation
> you are often in a position of wondering about the meaning
> and use of the dual construction.

That is an interesting thought. I wonder if it could be build into a 
programming language. Then one would could simply say

Sum == Dual(Product).

I guess it's a bit problematic since the projection functions are called 
"project" and the injection functions "inject". How would "Dual" know 
how to rename?

>> You probably see yourself, that your Product implementation 
>> has a number of limitations in contrast to Record.
>>
>> 1) Suppose you have A=X=Y=Integer and
>>     f(a: A): X == a,
>>     g(a: A): X == a+1,
>>     Then construct for P ==> Product(Integer, Integer)
>>       h: A -> P := product(Integer, f, g)
>>     What result do you expect for project(h 0)?
>>
> 
> Yes that is easily remedied by defining the projections as
> 'project1', 'project2', ... similarly 'inject1', 'inject2'.
> I should have done it this way.
>  
>>     For Record(a:A,b:B,...) the projection functions are
>>     basically
>>       apply: (%, 'a') -> A
>>       apply: (%, 'b') -> B
>>     ...
>>     and thus all have different names.

> This use of enumerators seem awkward to me when what I really
> want is a cross product and disjoint union. I don't really
> want to have to specify these sort of "tags". But if the
> definition of Record(a:A,b:B, ... ) actually defined a, b,
> ... as the projections:
> 
>   a: Record(a:A,b:B, ...) -> A
>   b: Record(a:A,b:B, ...) -> A
> 
> then I would have much less complaint. Similarly
> 
>   a: A -> Union(a:A,b:B ...)
>   b: A -> Union(a:A,b:B ...)
> 
> would be the injections (union function) into the Union.
> But this would be a substantial change to the syntax and
> semantics of Aldor and Spad.

Unfortunately, Aldor exports

   apply: (%, 'a') -> A

by default. If that were

   apply: ('a', %) -> A

instead, one should be able to write x: A := a(p) where p is an element 
of Record(a: A, b: B, ...);


\start
Date: 13 May 2007 07:53:37 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] more character stuff

  The previous patch that used the ANSI Lisp character type, in lieu
of the non-standard but cltl conformant string-char, misses a few
places.  Fixed thusly.

-- Gaby

2007-05-12  Gabriel Dos Reis  Gabriel Dos Reis

	* metalex.lisp.pamphlet (make-adjustable-string): Use character as
	string element type, not string-char.
	* parsing.lisp.pamphlet (underscore, make-string-adjustable):
	Likewise. 
	* unlisp.lisp.pamphlet (c-to-lisp-string, |ByteFileReadLine|,
	|FullString|): Likewise.
	* vmlisp.lisp.pamphlet (make-cvec): Likewise.
 
*** src/interp/metalex.lisp.pamphlet	(revision 15487)
--- src/interp/metalex.lisp.pamphlet	(local)
***************
*** 1,15 ****
  \documentclass{article}
  \usepackage{axiom}
! \begin{document}
  \title{\$SPAD/src/interp metalex.lisp}
  \author{Timothy Daly}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
  \section{License}
  <<license>>=
  ;; Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
  ;; All rights reserved.
--- 1,20 ----
+ %% Oh Emacs, this is a -*- Lisp -*- file, despite appearance.
  \documentclass{article}
  \usepackage{axiom}
! 
  \title{\$SPAD/src/interp metalex.lisp}
  \author{Timothy Daly}
+ 
+ \begin{document}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
+ 
  \section{License}
+ 
  <<license>>=
  ;; Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
  ;; All rights reserved.
*************** empty (if File-Closed (return nil))
*** 194,200 ****
          (t                                                      'special-char)))
   
  (defun make-adjustable-string (n)
!   (make-array (list n) :element-type 'string-char :adjustable t))
  
  (defun get-identifier-token (token)
    "Take an identifier off the input stream."
--- 199,205 ----
          (t                                                      'special-char)))
   
  (defun make-adjustable-string (n)
!   (make-array (list n) :element-type 'character :adjustable t))
  
  (defun get-identifier-token (token)
    "Take an identifier off the input stream."
*** src/interp/parsing.lisp.pamphlet	(revision 15487)
--- src/interp/parsing.lisp.pamphlet	(local)
***************
*** 1,15 ****
  \documentclass{article}
  \usepackage{axiom}
! \begin{document}
! \title{\$SPAD/src/interp parsing.lisp}
  \author{Timothy Daly}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
  \section{License}
  <<license>>=
  ;; Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
  ;; All rights reserved.
--- 1,20 ----
+ %% Oh Emacs, this is a -*- Lisp -*- file, despite appearance.
  \documentclass{article}
  \usepackage{axiom}
! 
! \title{\File{src/interp/parsing.lisp} Pamphlet}
  \author{Timothy Daly}
+ 
+ \begin{document}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
+ 
  \section{License}
+ 
  <<license>>=
  ;; Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
  ;; All rights reserved.
*************** the stack, then stack a NIL. Return the 
*** 556,562 ****
    (if (every #'alpha-char-p string) string
      (let* ((size (length string))
  	   (out-string (make-array (* 2 size)
! 				   :element-type 'string-char
  				   :fill-pointer 0))
  	   next-char)
        (dotimes (i size)
--- 561,567 ----
    (if (every #'alpha-char-p string) string
      (let* ((size (length string))
  	   (out-string (make-array (* 2 size)
! 				   :element-type 'character
  				   :fill-pointer 0))
  	   next-char)
        (dotimes (i size)
*************** is a token separator, which blank is equ
*** 689,695 ****
  
  (defun make-string-adjustable (s)
    (cond ((adjustable-array-p s) s)
!         (t (make-array (array-dimensions s) :element-type 'string-char
                         :adjustable t :initial-contents s))))
  
  (defun get-a-line (stream)
--- 694,700 ----
  
  (defun make-string-adjustable (s)
    (cond ((adjustable-array-p s) s)
!         (t (make-array (array-dimensions s) :element-type 'character
                         :adjustable t :initial-contents s))))
  
  (defun get-a-line (stream)
*** src/interp/unlisp.lisp.pamphlet	(revision 15487)
--- src/interp/unlisp.lisp.pamphlet	(local)
***************
*** 1,14 ****
  \documentclass{article}
  \usepackage{axiom}
! \begin{document}
! \title{\$SPAD/src/interp unlisp.lisp}
  \author{Stephen M. Watt, Timothy Daly}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
  \begin{verbatim}
  Uncommon 1.6
  This package is a Boot interface for Common Lisp.
--- 1,18 ----
+ %% Oh Emacs, this is a -*- Lisp -*- file, despite appearance.
  \documentclass{article}
  \usepackage{axiom}
! 
! \title{\File{src/interp/unlisp.lisp} Pamphlet}
  \author{Stephen M. Watt, Timothy Daly}
+ 
+ \begin{document}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
+ 
  \begin{verbatim}
  Uncommon 1.6
  This package is a Boot interface for Common Lisp.
*************** The following functions are provided:
*** 140,146 ****
  (defun c-to-lisp-string (ptr)
    (let (str len)
         (setq len (strlen ptr))
!        (setq str (make-array (list len) :element-type 'string-char))
         (sprintf str "%s" ptr)  ; Cannot use strcpy because it stops in a \0.
         str ))
  )
--- 144,150 ----
  (defun c-to-lisp-string (ptr)
    (let (str len)
         (setq len (strlen ptr))
!        (setq str (make-array (list len) :element-type 'character))
         (sprintf str "%s" ptr)  ; Cannot use strcpy because it stops in a \0.
         str ))
  )
*************** The following functions are provided:
*** 224,249 ****
  ;;
  ;;(defun |TextFileOpenIn| (path)
  ;;  (open path 
! ;;        :element-type 'string-char
  ;;        :direction :input ))
  ;;
  ;;(defun |TextFileOpenOut| (path)
  ;;  (open path 
! ;;        :element-type 'string-char
  ;;        :direction :output 
  ;;        :if-exists :supersede 
  ;;        :if-does-not-exist :create ))
  ;;
  ;;(defun |TextFileOpenIO| (path)
  ;;  (open path
! ;;        :element-type 'string-char
  ;;        :direction :io
  ;;        :if-exists :overwrite        ; open at beginning
  ;;        :if-does-not-exist :create ))
  ;;
  ;;(defun |TextFileOpenAppend| (path)
  ;;  (open path 
! ;;        :element-type 'string-char
  ;;        :direction :output 
  ;;        :if-exists :append 
  ;;        :if-does-not-exist :create ))
--- 228,253 ----
  ;;
  ;;(defun |TextFileOpenIn| (path)
  ;;  (open path 
! ;;        :element-type 'character
  ;;        :direction :input ))
  ;;
  ;;(defun |TextFileOpenOut| (path)
  ;;  (open path 
! ;;        :element-type 'character
  ;;        :direction :output 
  ;;        :if-exists :supersede 
  ;;        :if-does-not-exist :create ))
  ;;
  ;;(defun |TextFileOpenIO| (path)
  ;;  (open path
! ;;        :element-type 'character
  ;;        :direction :io
  ;;        :if-exists :overwrite        ; open at beginning
  ;;        :if-does-not-exist :create ))
  ;;
  ;;(defun |TextFileOpenAppend| (path)
  ;;  (open path 
! ;;        :element-type 'character
  ;;        :direction :output 
  ;;        :if-exists :append 
  ;;        :if-does-not-exist :create ))
*************** The following functions are provided:
*** 476,482 ****
  
  (defun |ByteFileReadLine| (instream)
    (do ((buf (make-array '(80) 
!                 :element-type 'string-char 
                  :fill-pointer 0
                  :adjustable 't ))
         (b (read-byte instream nil nil) (read-byte instream nil nil))
--- 480,486 ----
  
  (defun |ByteFileReadLine| (instream)
    (do ((buf (make-array '(80) 
!                 :element-type 'character 
                  :fill-pointer 0
                  :adjustable 't ))
         (b (read-byte instream nil nil) (read-byte instream nil nil))
*************** The following functions are provided:
*** 886,892 ****
  (defun |FullString| (size &optional (init #\Space))
    (make-array
     (list size)
!    :element-type 'string-char
     :initial-element init ))
  
  (defun |ToString| (ob)
--- 890,896 ----
  (defun |FullString| (size &optional (init #\Space))
    (make-array
     (list size)
!    :element-type 'character
     :initial-element init ))
  
  (defun |ToString| (ob)
*** src/interp/vmlisp.lisp.pamphlet	(revision 15487)
--- src/interp/vmlisp.lisp.pamphlet	(local)
*************** Contributed by Juergen Weiss.
*** 1176,1182 ****
  
  (define-function 'strconc #'concat)
  
! (defun make-cvec (sint) (make-array sint :fill-pointer 0 :element-type 'string-char))
  
  ;(define-function 'CVECP #'stringp)
  
--- 1176,1182 ----
  
  (define-function 'strconc #'concat)
  
! (defun make-cvec (sint) (make-array sint :fill-pointer 0 :element-type 'character))
  
  ;(define-function 'CVECP #'stringp)
  
\start
Date: Sun, 13 May 2007 15:26:00 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: [build-improvements] more character stuff
Cc: Camm Maguire

> 
> Hi,
> 
>   The previous patch that used the ANSI Lisp character type, in lieu
> of the non-standard but cltl conformant string-char, misses a few
> places.  Fixed thusly.
> 

Gaby, it looks like you are re-doing ANSI stuff from scratch.
Did you notice that string-char issues were already handled
in Jurgen Weiss version?  Greg Vanuxem sbcl port picked them.
In private tree I have merged sbcl changes into wh-sandbox.
There are some questionable parts in the code (notably using
eq on functions) and some tests still fail, so I did not
commit the code, but I can make it available.

BTW. Jurgen Weiss made choce between character and string-char
conditional.  It is not clear for me if GCL supports ANSI
enough to work well using character -- we probably should ask
Camm if there are any issues making string-char preferable
for GCL.

\start
Date: Sun, 13 May 2007 08:39:10 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: [build-improvements] more character stuff
Cc: Camm Maguire

On Sun, 13 May 2007, Waldek Hebisch wrote:

| > 
| > Hi,
| > 
| >   The previous patch that used the ANSI Lisp character type, in lieu
| > of the non-standard but cltl conformant string-char, misses a few
| > places.  Fixed thusly.
| > 
| 
| Gaby, it looks like you are re-doing ANSI stuff from scratch.

Well, as you know, I've been working on and off on support for SBCL and 
CLISP (ECL is secondary).  So, it is more in that line...

| Did you notice that string-char issues were already handled
| in Jurgen Weiss version?

No, I did not.

|  Greg Vanuxem sbcl port picked them.

OK.

| In private tree I have merged sbcl changes into wh-sandbox.
| There are some questionable parts in the code (notably using
| eq on functions) and some tests still fail, so I did not
| commit the code, but I can make it available.

Well, if you did part of the work, we can always debate the
questionable part.  Here is my work flow:

  (1) identify troublesome parts
  (2) identify the root causes
  (3) implement minimal changes to solve the issue
  (4) discuss the fundamental problem and the bigger changes
      later.

| BTW. Jurgen Weiss made choce between character and string-char
| conditional.  It is not clear for me if GCL supports ANSI
| enough to work well using character -- we probably should ask
| Camm if there are any issues making string-char preferable
| for GCL.

That sounds reasonable.

\start
Date: 13 May 2007 08:44:30 -0500
From: Gabriel Dos Reis
To: list
Subject: vmlisp

  I understand the historical need for vmlisp.lisp -- which has now
grown out of its original purpose.

  In 2007 where we are working towards ANSI Lisp based, is there a
fundamental reason why we should still have the package VMLISP
separate from the BOOT package?

  More specifically, I would like to move most of the content of
VMLISP into BOOT, and minimize the size of the current web.  

Comments?

\start
Date: Sun, 13 May 2007 09:01:11 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: [build-improvements] more character stuff
Cc: Camm Maguire

On Sun, 13 May 2007, Waldek Hebisch wrote:

| BTW. Jurgen Weiss made choce between character and string-char
| conditional.  It is not clear for me if GCL supports ANSI
| enough to work well using character

I forgot to mention that I looked at the GCL info file and I did
not spot anything obvious that made the use of character type
inappropriate.

| -- we probably should ask
| Camm if there are any issues making string-char preferable
| for GCL.

Camm, do we have good enough support for the ANSI Lisp
character type so that we can use it in lie of string-char?

\start
Date: Sun, 13 May 2007 17:05:09 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: vmlisp
Cc: list

>   I understand the historical need for vmlisp.lisp -- which has now
> grown out of its original purpose.
> 
>   In 2007 where we are working towards ANSI Lisp based, is there a
> fundamental reason why we should still have the package VMLISP
> separate from the BOOT package?
> 
>   More specifically, I would like to move most of the content of
> VMLISP into BOOT, and minimize the size of the current web.  
> 

I think that Lisp code in Axiom needs substantial cleanup.  There
is a lot of duplication (even more than in .boot files).  It is
likely that 50% or more of Lisp code is unused or duplicated.
OTOH packages are main Lisp tool to organize code and we should
make better use of them.  From my point of view just moving
symbols from VMLISP into BOOT gains us nothing -- intead of two
closely tied piles of code we get one pile which is as closly
tied as before.

I would like to see Lisp code reorganized along the following lines:

1) Portability wrappers and general purpose utilities.  This should
   abstract away most differences between Lisp implementations.
   File access and image dumping are prime examples of thing needed
   there.  This should be a file (possibly multiple files) in 
   src/lisp subdirectory and should be loaded into very first image
   that we dump (so that we can use the exported functionality
   during the whole build).  I think that this code deserves it
   own package (possibly multiple packages).
 
  I noticed that you load inital-env.lisp from src/boot into the
  first image.  I do not think it is a goog idea: inital-env.lisp
  contains a lot of Shoe specific code and misses many functions
  that are needed later (some of them could benefit Shoe).

2) Axiom virtual machine: Lisp code needed to support output of
   Spad compiler.  This part should depend weakly on host Lisp.
   Large parts of macros.lisp and vmlisp.lisp should go there.

3) Part of "normal" code which are written in Lisp, those should
   live in src/interp and src/boot as apropriate.

I planned to start implementing part 1, but I have noticed that
you are doing similar but different things in build-improvements.

I should say stress one point here: simultaneously with moving
code around or implementing new functionality we should remove
old code.

\start
Date: Sun, 13 May 2007 10:23:39 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: vmlisp

On Sun, 13 May 2007, Waldek Hebisch wrote:

| >   I understand the historical need for vmlisp.lisp -- which has now
| > grown out of its original purpose.
| > 
| >   In 2007 where we are working towards ANSI Lisp based, is there a
| > fundamental reason why we should still have the package VMLISP
| > separate from the BOOT package?
| > 
| >   More specifically, I would like to move most of the content of
| > VMLISP into BOOT, and minimize the size of the current web.  
| > 
| 
| I think that Lisp code in Axiom needs substantial cleanup.  There
| is a lot of duplication (even more than in .boot files).  It is
| likely that 50% or more of Lisp code is unused or duplicated.
| OTOH packages are main Lisp tool to organize code and we should
| make better use of them.  From my point of view just moving
| symbols from VMLISP into BOOT gains us nothing -- intead of two
| closely tied piles of code we get one pile which is as closly
| tied as before.

The motivation of moving VMLISP to BOOT is not that we have too many
packages. This has nothing to do with Lisp package mehcanism.
The motivation for merging both is that we end up with codes that
do not know where to pick their symbols from, duplicate definitions in 
both packages, and more confusion.  Codes that are so tied should be in one
logical unit.

| I would like to see Lisp code reorganized along the following lines:
| 
| 1) Portability wrappers and general purpose utilities.  This should
|    abstract away most differences between Lisp implementations.
|    File access and image dumping are prime examples of thing needed
|    there.  This should be a file (possibly multiple files) in 
|    src/lisp subdirectory and should be loaded into very first image
|    that we dump (so that we can use the exported functionality
|    during the whole build).  I think that this code deserves it
|    own package (possibly multiple packages).
|  
|   I noticed that you load inital-env.lisp from src/boot into the
|   first image.  I do not think it is a goog idea: inital-env.lisp
|   contains a lot of Shoe specific code and misses many functions
|   that are needed later (some of them could benefit Shoe).

some observations:

   (1) the problem is not that initial-env.lisp is a bad idea.  The 
       problem is that is contains some codes that may be of use only
       to bootsys, and not the rest of the compiler.

       However, it is a good idea to have initial-env.lisp as a central
       place to put things that we use over again and again --
       the interface to the build machinery.  Note also tha initial-env.lisp
       was a quick setup that had me started on another front of Axiom code
       reorganization.

       I started last night moving bits and pieces that are only bootsys
       specific to Boot codes.

   (2) In the long run, bootsys should be integrated to the final
       AXIOMsys image


| 2) Axiom virtual machine: Lisp code needed to support output of
|    Spad compiler.  This part should depend weakly on host Lisp.
|    Large parts of macros.lisp and vmlisp.lisp should go there.

vmlisp.lisp and macro.lisp contains lot of things that have nothing to do with
the Axiom VM proper.  But, I agree that we should have a logical unit
for the Axiom VM.

| 3) Part of "normal" code which are written in Lisp, those should
|    live in src/interp and src/boot as apropriate.
| 
| I planned to start implementing part 1, but I have noticed that
| you are doing similar but different things in build-improvements.
| 
| I should say stress one point here: simultaneously with moving
| code around or implementing new functionality we should remove
| old code.

I have nothing against that, as long as we understand what the old code is
doing and we can prove/convince each other that removing the old code is
the good way forward.  I would propose that code removal be subject to 
discussion so that we have a public record of each others' understanding.

\start
Date: Sun, 13 May 2007 08:34:06 -0700 (PDT)
From: Cliff Yapp
To: Waldek Hebisch, Gabriel Dos Reis
Subject: Re: vmlisp

--- Waldek Hebisch wrote:

> I think that Lisp code in Axiom needs substantial cleanup.  There
> is a lot of duplication (even more than in .boot files).  It is
> likely that 50% or more of Lisp code is unused or duplicated.

I wonder if there are Lisp utilities somewhere that could identify
unused code for us.  Hmm...

> OTOH packages are main Lisp tool to organize code and we should
> make better use of them.

DEFINITELY agree.

> From my point of view just moving
> symbols from VMLISP into BOOT gains us nothing -- intead of two
> closely tied piles of code we get one pile which is as closly
> tied as before.

Agreed.
 
> I would like to see Lisp code reorganized along the following lines:
> 
> 1) Portability wrappers and general purpose utilities.  This should
>    abstract away most differences between Lisp implementations.

YES.  This is a must for all large Lisp projects.  I suggest we also
make use of widely used libraries already out there so we don't wind up
duplicating work already done in this department (if the license is
compatible with Axiom, we can include it in the tarball and
conditionally load it based on the capabilities of the target build
Lisp system - if it already has it great, if not we've got it in the
tarball.)  We might also (eventually) convert them into literate files
- dunno if the upstream projects would accept that, but we could
incorporate them.

Tools I would like to check out:
CL-FAD   http://weitz.de/cl-fad/      (portable pathnames)
usocket  http://www.cliki.net/usocket (portable sockets)

if we want to use threads, http://www.cliki.net/Portable-Threads
if we need FFI access, http://common-lisp.net/project/cffi/

>    File access and image dumping are prime examples of thing needed
>    there.  This should be a file (possibly multiple files) in 
>    src/lisp subdirectory and should be loaded into very first image
>    that we dump (so that we can use the exported functionality
>    during the whole build).  I think that this code deserves it
>    own package (possibly multiple packages).

Absolutely agree.  One question - why do we want to dump Lisp images
during the build again?  I think this was explained a long while back,
but I'm not recalling - it still seems odd to me :-(.
  
>   I noticed that you load inital-env.lisp from src/boot into the
>   first image.  I do not think it is a goog idea: inital-env.lisp
>   contains a lot of Shoe specific code and misses many functions
>   that are needed later (some of them could benefit Shoe).
> 
> 2) Axiom virtual machine: Lisp code needed to support output of
>    Spad compiler.  This part should depend weakly on host Lisp.
>    Large parts of macros.lisp and vmlisp.lisp should go there.

Sounds good.

> 3) Part of "normal" code which are written in Lisp, those should
>    live in src/interp and src/boot as apropriate.
> 
> I planned to start implementing part 1, but I have noticed that
> you are doing similar but different things in build-improvements.

Waldek, would it be possible for you to upload your "almost working on
sbcl" tree?  I'm working with sbcl mostly and it would be very handy,
even if it's not 100% correct yet.  Most of the tools of interest for
portability haven't worked their way around to GCL yet so that also
makes things difficult.

> I should say stress one point here: simultaneously with moving
> code around or implementing new functionality we should remove
> old code.

Agreed.  We want to avoid "dead" code and prune it out - it only makes
the system harder to understand.  Perhaps some of it can be made "live"
again but I'll bet a lot of it is dead for good.

\start
Date: Sun, 13 May 2007 12:22:33 -0500
From: Tim Daly
To: list
Subject: lisp dead code

I've been using the method of finding the root of the code tree and
walking the branches. At each branch node, the code is collected and
documented, the variables it depends on are collected and documented
and the code is reorganized.  The data structures used in the code are
documented. When this process is completed for a root node it will end
up in a package with only the exposed API functions exported.

The interpreter is gradually moving into bookvol5 and the compiler
will eventually move into bookvol6. Hyperdoc is bookvol7 and graphics
is bookvol8. What remains after the tree is walked must either contain
a new root or dead code.

\start
Date: 13 May 2007 16:31:36 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: lisp dead code

Tim Daly writes:

| I've been using the method of finding the root of the code tree and
| walking the branches. At each branch node, the code is collected and
| documented, the variables it depends on are collected and documented
| and the code is reorganized.  The data structures used in the code are
| documented. When this process is completed for a root node it will end
| up in a package with only the exposed API functions exported.
| 
| The interpreter is gradually moving into bookvol5

What I've found very disturbing, is that the bookvol5 documentation
does *not document* the interpreter.  It only plagiarize, in English,
what was written in Boot or Lisp.  I can read from the codes that,
e.g. *eof* is set to nil in ncTopLevel.  When I'm reading a
documentation, I'm more interested in *why* the code is doing what it
is doing, not what it is literally doing -- because, that, I can read
from the code.  

I was also wondering what was gained by translated what was in Boot to
Lisp. 

I would encourage people to preserve and improve working Boot codes,
and document *why* they are doing what they are doing.

\start
Date: Mon, 14 May 2007 01:08:56 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: sbcl port

At:

http://www.math.uni.wroc.pl/~hebisch/prog/sbcl4c.diff.gz

you may find my current patch allowing compilation with sbcl.
The patch shoul apply to current (revision 534) wh-sandbox.

Currently build requires some manual intervention:

1) I ommited diff to interp-proclaims.lisp, one has to replace it
   by safety declaration:

(eval-when (:execute :compile-toplevel :load-toplevel)
  (proclaim
    '(optimize (safety 3))))

Alternativly, one can use empty file.

2) Build dies during tests due to lack writablep function.

3) The reclos test do not finish, it looks that 

relativeApprox(squareDiff8,10**(-3))::Float

line goes into infinite loop.

Also, currently sbcl spends a lot of time (more than 1 hour)
compiling the function jordanAdmissible? from
AlgebraGivenByStructuralConstants.

Things that do not work:

1) I fake sockets, so that graphics tests can go on, but you
   get no output.

2) Output that should go to standard output goes to the terminal
   so redirection does not work (I use the script program to
   capture build logs).

3) Due to 2 I do not know if tests work: with the exceptions mentioned
   tests go forward but I did not check results.
 
There is some quick and dirty code:

- I hacked src/lisp/Makefile.pamphlet so it works for me, but as
  I wrote in other message we should load support code here.
- sockets are fake
- not-a-number constant is fake (Axiom usage looks bogus and we
  probably should remove not-a-number constant, but ATM I just
  fake it)
- almost empty interp-proclaims.lisp (we should have real
  proclaims)
- I had to define posix-chdir in the first image because later
  images were unable to load posix package

and probably more.

Following Juregen Weiss in few places I test functions for equality
like:

f = FUNCTION newGoGet => SUBST('_$,domname,devaluate CAR r)

This code may fail because Lisp may produce fresh function each
time we execute the test.

The is also some clisp code: it is probably not working yet (and
it uses paths corresponding to locations on my hard drive...).

\start
Date: Mon, 14 May 2007 01:33:35 +0200 (CEST)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: lisp dead code

> I've been using the method of finding the root of the code tree and
> walking the branches. At each branch node, the code is collected and
> documented, the variables it depends on are collected and documented
> and the code is reorganized.  The data structures used in the code are
> documented. When this process is completed for a root node it will end
> up in a package with only the exposed API functions exported.
> 
> The interpreter is gradually moving into bookvol5 and the compiler
> will eventually move into bookvol6. Hyperdoc is bookvol7 and graphics
> is bookvol8. What remains after the tree is walked must either contain
> a new root or dead code.
> 

IIRC bookvol5 also contains dead code.  And frankly, concerning
readability I find bookvol5 worse than rest of the interpreter.

\start
Date: 13 May 2007 19:04:43 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: lisp dead code

Waldek Hebisch writes:

| IIRC bookvol5 also contains dead code.  And frankly, concerning
| readability I find bookvol5 worse than rest of the interpreter.

I have to agree.

\start
Date: 13 May 2007 19:17:26 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: sbcl port

Waldek Hebisch writes:

| At:
| 
| http://www.math.uni.wroc.pl/~hebisch/prog/sbcl4c.diff.gz
| 
| you may find my current patch allowing compilation with sbcl.
| The patch shoul apply to current (revision 534) wh-sandbox.

Thanks.

| Currently build requires some manual intervention:
| 
| 1) I ommited diff to interp-proclaims.lisp, one has to replace it
|    by safety declaration:


At the moment, build-improvements just omit that file.  I'm working on
a way to automate that -- bootsys has enough machinery to produce a
conservative approximation of each definition function type; so it
could ideally produce the information.  I've not gotten enought time
to finalize the bits.  

For those interested, this more than 25-year old paper by Jones and
Muchnick may be of interest. 

   http://portal.acm.org/citation.cfm?id=567752.567776

\start
Date: Sun, 13 May 2007 23:43:42 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: lisp dead code
Cc: Gabriel Dos Reis

On May 13, 2007 7:34 PM Waldek Hebisch wrote:
>  
> Tim Daly wrote: 
> > ... 
> > The interpreter is gradually moving into bookvol5 and the
> > compiler will eventually move into bookvol6. Hyperdoc is
> > bookvol7 and graphics is bookvol8. What remains after the
> > tree is walked must either contain a new root or dead code.
> > 
> 
> IIRC bookvol5 also contains dead code.  And frankly, concerning
> readability I find bookvol5 worse than rest of the interpreter.
> 

I agree.

Tim's "bookvol5" looked like a bad idea to me 18 months ago

http://lists.nongnu.org/archive/html/axiom-developer/2005-11/msg00104.html
http://lists.nongnu.org/archive/html/axiom-developer/2005-10/msg00397.html

and it looks even worse now. The concept of grouping code and
documentation into "book-sized" volumes does not make any sense.
A monolithic linear presentation of the code does not aid an
overall understanding of the system. On the contrary it makes
several things harder to manage and moves the system further
away from the tools that have been developed specifically to
deal with large complicated projects. I am all in favour of
adding more documentation to Axiom and doing it in a literate
style, but I am quite sure that this is not the way to do it.

I am very encouraged however by the work of both Waldek and
Gaby to improve the build process and to improve the long term
maintainability of the Axiom code in it's current form without
the kind re-writing and restructuring in which Tim has been
indulging. And I must repeat again that I am even happier that
they have a strong interest in Boot and have already taken some
steps in the direction that seemed to be the intention of the
original developers - integrating the new boot compiler (shoe).

I would like to see the retrogressive code changes from Boot
to Lisp that Tim introduced in bookvol5 reversed. With the
prospect that Boot can now be fully documented and properly
maintained, if there is any re-writing to be done, then I think
it is in the opposite direction - from Lisp to Boot.

\start
Date: Sun, 13 May 2007 23:11:56 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Waldek Hebisch
Subject: RE: lisp dead code
Cc: Gabriel Dos Reis

--- Bill Page wrote:

> The concept of grouping code and documentation into "book-sized"
> volumes does not make any sense.

This is why I like the idea of the "conference proceeding" style of
volume building - collect many papers (pamphlets) that pertain to a
particular subject into one volume, but each paper is its own
self-contained sub-unit.

The paper/pamphlet authors don't need to worry about the volumes in
that case, except possibly when it comes to compatibility of LaTeX
packages.

> A monolithic linear presentation of the code does not aid an
> overall understanding of the system. On the contrary it makes
> several things harder to manage and moves the system further
> away from the tools that have been developed specifically to
> deal with large complicated projects. I am all in favour of
> adding more documentation to Axiom and doing it in a literate
> style, but I am quite sure that this is not the way to do it.

I expect there are as many visions for how to handle this as there are
developers for Axiom.  Some time it might be interesting to have
everyone write out a "global design vision for Axiom" and see how they
all differ.

> I am very encouraged however by the work of both Waldek and
> Gaby to improve the build process and to improve the long term
> maintainability of the Axiom code in it's current form without
> the kind re-writing and restructuring in which Tim has been
> indulging.

My take on this is that we need re-writing and restructuring, but until
we have a better handle on what the system is doing now such efforts
are premature.

My take on Axiom in its current form is we have no fundamental reason
to trust its correctness, and it is more important to work towards a
foundation that we can trust first, and THEN re-implement the existing
logic on top of the solid foundation.  Hopefully it would be a fairly
painless migration at the Algebra level, but without a rigorous
definition of SPAD/Aldor I don't see how we can make any strong
correctness claims.

> And I must repeat again that I am even happier that
> they have a strong interest in Boot and have already taken some
> steps in the direction that seemed to be the intention of the
> original developers - integrating the new boot compiler (shoe).

I too am glad to see this, primarily because it looks like the shortest
route to an Axiom that works well on multiple (and more modern)
targets.  I have no particular attachment to Boot or Shoe but
translation of their implementation logic into Lisp in a "good" way is
not simple.  In the meantime Boot/Shoe being runnable elsewhere is a
good thing.

> I would like to see the retrogressive code changes from Boot
> to Lisp that Tim introduced in bookvol5 reversed. With the
> prospect that Boot can now be fully documented and properly
> maintained, if there is any re-writing to be done, then I think
> it is in the opposite direction - from Lisp to Boot.

Not sure I agree here, but it might be more because I'm still at the
starting gate as far as awareness of the guts of Axiom is concerned. 
Also I'm an Admitted Lisp Fan so that's a likely source of bias.

Fortunately, many of the improvements people are making are not
mutually exclusive.  I have my own opinions about how I would like to
see Axiom evolve, but as they say everyone has opinions and mine don't
count for much until I show code to back them.

Those who do have code, regardless of direction, I wish to say thank
you for helping to make Axiom what it is today and what it may become.

\start
Date: 14 May 2007 02:05:36 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: vmlisp

Gabriel Dos Reis writes:

[...]

| The motivation of moving VMLISP to BOOT is not that we have too many
| packages. This has nothing to do with Lisp package mehcanism.
| The motivation for merging both is that we end up with codes that
| do not know where to pick their symbols from, duplicate definitions in 
| both packages, and more confusion.  Codes that are so tied should be in one
| logical unit.

I realize the above statements may sound very abstract to many.  So,
let me give an example.

Take the following fragment, at the scope of package BOOT, from
src/interp/setq.lisp: 

    (SETQ ERRORINSTREAM (DEFIOSTREAM
       '((DEVICE . CONSOLE) (MODE . INPUT) (QUAL . T)) 133 1))

    (SETQ ERROROUTSTREAM
     (DEFIOSTREAM '((DEVICE . CONSOLE)(MODE . OUTPUT)) 80 0) )

    (SETQ |$algebraOutputStream|
     (DEFIOSTREAM '((DEVICE . CONSOLE)(MODE . OUTPUT)) 255 0) )


First let me observe that, in reality they are not needed, and I don't
think they actually work as expected.

In the above fragment, DEFIOSTREAM is a helper function defined in
package VMLISP (from src/interp/vmlisp.lisp):

   (defun DEFIOSTREAM (stream-alist buffer-size char-position)
    (declare (ignore buffer-size))
      (let ((mode (or (cdr (assoc 'MODE stream-alist)) 'INPUT))
            (filename (cdr (assoc 'FILE stream-alist)))
            (dev (cdr (assoc 'DEVICE stream-alist))))
         (if (EQ dev 'CONSOLE) (make-synonym-stream '*terminal-io*)
           (let ((strm (case mode
                             ((OUTPUT O) (open (make-filename filename)
                                               :direction :output))
                             ((INPUT I) (open (make-input-filename filename)
                                              :direction :input)))))
             (if (and (numberp char-position) (> char-position 0))
                 (file-position strm char-position))
             strm))))


*If* everything goes well the variables ERRORINSTREAM, ERROROUTSTREAM,
and |$algebraOutputStream| should be alias for *terminal-io*.  For
that to work, there ought to be that the symbols CONSOLE from packages
VMLISP (where the function DEFIOSTREAM is defined) and package BOOT
(where DEFIOSTREAM is called from) are EQ.  They not EQ.

\start
Date: Mon, 14 May 2007 15:19:44 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: vmlisp

Gabriel Dos Reis wrote:
> Gabriel Dos Reis writes:
> 
> [...]
> 
> | The motivation of moving VMLISP to BOOT is not that we have too many
> | packages. This has nothing to do with Lisp package mehcanism.
> | The motivation for merging both is that we end up with codes that
> | do not know where to pick their symbols from, duplicate definitions in 
> | both packages, and more confusion.  Codes that are so tied should be in one
> | logical unit.
> 
> I realize the above statements may sound very abstract to many.  So,
> let me give an example.
> 
> Take the following fragment, at the scope of package BOOT, from
> src/interp/setq.lisp: 
> 
>     (SETQ ERRORINSTREAM (DEFIOSTREAM
>        '((DEVICE . CONSOLE) (MODE . INPUT) (QUAL . T)) 133 1))
> 
>     (SETQ ERROROUTSTREAM
>      (DEFIOSTREAM '((DEVICE . CONSOLE)(MODE . OUTPUT)) 80 0) )
> 
>     (SETQ |$algebraOutputStream|
>      (DEFIOSTREAM '((DEVICE . CONSOLE)(MODE . OUTPUT)) 255 0) )
> 
> 
> First let me observe that, in reality they are not needed, and I don't
> think they actually work as expected.
> 
> In the above fragment, DEFIOSTREAM is a helper function defined in
> package VMLISP (from src/interp/vmlisp.lisp):
> 
>    (defun DEFIOSTREAM (stream-alist buffer-size char-position)
>     (declare (ignore buffer-size))
>       (let ((mode (or (cdr (assoc 'MODE stream-alist)) 'INPUT))
>             (filename (cdr (assoc 'FILE stream-alist)))
>             (dev (cdr (assoc 'DEVICE stream-alist))))
>          (if (EQ dev 'CONSOLE) (make-synonym-stream '*terminal-io*)
>            (let ((strm (case mode
>                              ((OUTPUT O) (open (make-filename filename)
>                                                :direction :output))
>                              ((INPUT I) (open (make-input-filename filename)
>                                               :direction :input)))))
>              (if (and (numberp char-position) (> char-position 0))
>                  (file-position strm char-position))
>              strm))))
> 
> 
> *If* everything goes well the variables ERRORINSTREAM, ERROROUTSTREAM,
> and |$algebraOutputStream| should be alias for *terminal-io*.  For
> that to work, there ought to be that the symbols CONSOLE from packages
> VMLISP (where the function DEFIOSTREAM is defined) and package BOOT
> (where DEFIOSTREAM is called from) are EQ.  They not EQ.
> 
> 

I am not sure abot last part of the analysis, freshly build
interpsys tells me:

(1) -> )lisp |$algebraOutputStream|

Value = #<synonym stream to *TERMINAL-IO*>
(1) -> )lisp (eq 'VMLISP::CONSOLE 'BOOT::CONSOLE)

Value = T
(1) ->

so IMHO the code _may_ work.  AFAICS ERRORINSTREAM, ERROROUTSTREAM are
unused.  |$algebraOutputStream| is also initialized in other places
and it looks that initialization in patches.lisp wins.

So I think that the snippet above is a prime candidate for removal.
Once we get rid of all uses we will be able to remove DEFIOSTREAM.
We should also simplify RDEFIOSTREAM (it looks that RDEFIOSTREAM uses
the same funky argument format as DEFIOSTREAM).

Let me mention other candidates for removal.  compDefineCapsuleFunction
is defined in two places: in define.boot.pamphlet and in
br-saturn.boot.pamphlet.  I checked that copy in br-saturn is
used during algebra build.  Copy in define.boot.pamphlet is slightly
different.  So IMHO copy in br-saturn should be removed and copy in
define.boot.pamphlet should be changed to match version from br-saturn.

In general, when we multiple versions of code which are doing the
same thing (for example initializing |$algebraOutputStream|) we
should check which copy is used and remove the other ones (this may
require moving/changing code to account for load order).

Another candidate is the following:

--- pp2/wh-20070421/src/interp/postpar.boot.pamphlet    Sun Apr 22 00:24:35 2007+++ wh-20070421/src/interp/postpar.boot.pamphlet        Sat May  5 21:30:02 2007@@ -259,15 +259,7 @@

 postForm (u is [op,:argl]) ==
   x:=
-    atom op =>
-      argl':= postTranList argl
-      op':=
-        true=> op
-        $BOOT => op
-        GETL(op,'Led) or GETL(op,'Nud) or op = 'IN => op
-        numOfArgs:= (argl' is [['Tuple,:l]] => #l; 1)
-        INTERNL("*",STRINGIMAGE numOfArgs,PNAME op)
-      [op',:argl']
+    atom op => [op,:postTranList argl]
     op is ['Scripts,:.] => [:postTran op,:postTranList argl]
     u:= postTranList u
     if u is [['Tuple,:.],:.] then


The true branch means that other parts are never executed.  Once
such dead branches in conditionals are removed it may became
apparent that some other code is never referenced.

In general I remove code when I reasonably convinced that the
code is useless:

1) duplicates
2) dead conditional branches (I spare them if I feel that the
   code may be usefull in the furture)
3) unreferenced code

Concerning conditional branches: I sometimes do flow analysis or
track variables to determine if branch is dead -- usually I do
this when the code looks very wrong (say references non existent
functions).

\start
Date: Mon, 14 May 2007 08:49:59 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: vmlisp

On Mon, 14 May 2007, Waldek Hebisch wrote:

| I am not sure abot last part of the analysis, freshly build
| interpsys tells me:
| 
| (1) -> )lisp |$algebraOutputStream|
| 
| Value = #<synonym stream to *TERMINAL-IO*>

As you know the variable |$algebraOutputStream| is set at toplevel in many
places (macros.lisp, obey.lisp setq.lisp), and the one in setq.lisp is not the
latest in effect.  At non-toplevel, you have macros.lisp, setvars.boot.

Although, the multiplicity should be removed (and that is what I did in my
local trees), I don't think my issues are just solved by removing codes. 

\start
Date: Mon, 14 May 2007 08:53:13 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: vmlisp

On Mon, 14 May 2007, Waldek Hebisch wrote:

| Another candidate is the following:
| 
| --- pp2/wh-20070421/src/interp/postpar.boot.pamphlet    Sun Apr 22 00:24:35 2007+++ wh-20070421/src/interp/postpar.boot.pamphlet        Sat May  5 21:30:02 2007@@ -259,15 +259,7 @@
| 
|  postForm (u is [op,:argl]) ==
|    x:=
| -    atom op =>
| -      argl':= postTranList argl
| -      op':=
| -        true=> op
| -        $BOOT => op
| -        GETL(op,'Led) or GETL(op,'Nud) or op = 'IN => op
| -        numOfArgs:= (argl' is [['Tuple,:l]] => #l; 1)
| -        INTERNL("*",STRINGIMAGE numOfArgs,PNAME op)
| -      [op',:argl']
| +    atom op => [op,:postTranList argl]
|      op is ['Scripts,:.] => [:postTran op,:postTranList argl]
|      u:= postTranList u
|      if u is [['Tuple,:.],:.] then
| 
| 
| The true branch means that other parts are never executed.

Yes.  Clearly, it has always looked to me as a temporary hack.
(Otherwise, it would have been entirely removed or commented out).
Before, removing the dead code, we should understand what was originally
intented and why it was not working and prompted the hack.

\start
Date: Mon, 14 May 2007 09:57:44 -0500
From: Tim Daly
To: list
Subject: common lisp in firefox

You can now use standard common lisp to write scripts in firefox:

<http://www.cs.stevens.edu/~dlong/software/kamen/fib.html>

the page won't work because you don't have the plugin, but do a
view page source and you can see the scripting language.

The home page for the work is at
<http://www.cs.stevens.edu/~dlong/software/kamen/index.php>

\start
Date: Mon, 14 May 2007 19:07:50 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Axiom on clisp

I can now report succesful build on clisp.  You can find a patch at:

http://www.math.uni.wroc.pl/~hebisch/prog/sbcl-clisp2.diff

Apply on top of sbcl patch.  Like in sbcl case replace
interp-proclaims.lips by safty declaration or empty file.

Clisp handles files and directories in rather strange way, to
make things sane I use cl-fad library from:

http://weitz.de/files/cl-fad.tar.gz

ATM one has to manually edit src/lisp/Makefile.pamphlet and
put there correct path to cl-fad.  

Another problem: in default C locale clisp rejects any non-ASCII
charaters.  Martin's guessing package contains some comments in
German and clisp chokes on them.  So, for succesfull build one
has to set charset to something allowing all 8-bit codes.
For example:

LC_CTYPE=ISO-8859-1 make

should work.

Like in sbcl case sockets are fake.  There is extra issue: some
test fail when printing long numbers.  Backtrace indicate floating
point overflow when computing log10 (needed to find width of a
number).  I am not sure what is the exact reason, but this points
out to another problem: clisp has "arbitrary precision" floats
and MOST-POSITIVE-LONG-FLOAT is really large:

> MOST-POSITIVE-LONG-FLOAT
8.8080652584198167656L646456992

In some places Axiom code seem to assume that long-float is the
same as double-float and allowing numbers comparable to
MOST-POSITIVE-LONG-FLOAT may lead to overflow in double-float
computations.

\start
Date: 14 May 2007 12:13:13 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Axiom on clisp

Waldek Hebisch writes:

| In some places Axiom code seem to assume that long-float is the
| same as double-float and allowing numbers comparable to
| MOST-POSITIVE-LONG-FLOAT may lead to overflow in double-float
| computations.

That is a bug in Axiom.  The fix is to use double-float everywhere.
See my previous postings on the subject.  This affect both the
interpreter/compile codes, as well as Algebra codes.

\start
Date: Mon, 14 May 2007 19:24:56 +0200
From: Gregory Vanuxem
To: Waldek Hebisch
Subject: Re: sbcl port

Le lundi 14 mai 2007 =E0 01:08 +0200, Waldek Hebisch a =E9crit

[...]

> 3) The reclos test do not finish, it looks that
>
> relativeApprox(squareDiff8,10**(-3))::Float
>
> line goes into infinite loop.

Does

)lis (gcd 8 most-negative-fixnum)

return the gcd ?

If not it's a bug in SBCL (x86_64). I reported it some
times ago and didn't receive any response. Maybe another
report with an example will help (I patch sb-kernel::two-arg-gcd each
time I upgrade SBCL).

>
> Also, currently sbcl spends a lot of time (more than 1 hour)
> compiling the function jordanAdmissible? from
> AlgebraGivenByStructuralConstants.

Same thing happens on CMUCL. Compilation time of this function depends
greatly on the optimize qualities.

\start
Date: 14 May 2007 19:48:00 +0200
From: Martin Rubey
To: Frederic Lehobey
Subject: Re: Axiom at LSM 2007?

Dear Frederic,

Frederic Lehobey writes:

> Dear Axiom developers and users,
> 
> Would any of you be interested in giving a lecture on Axiom or Axiom
> use cases at the following free software conference (in France, this
> summer).

Many thanks for the invitation.  Unfortunately, I cannot come, although I think
it would be quite important for the Axiom project to do some advertising.

Please keep us informed, I hope that next year I will be able to come!

\start
Date: Mon, 14 May 2007 13:10:58 -0500
From: Tim Daly
To: list
Subject: Knuth's literate style

An interesting reference worth purchasing, checking out from a library,
or stealing from a friend... In any case, it helps to have looked at it
carefully at least once as there are many features here:

Knuth, Donald E. "TEX, The Program" Addison Wesley, 1986
ISBN 0-201-13437-3

It will help set the baseline for a discussion of literate documenation.
This is my current target, modulo using latex-compatible chunk syntax to
eliminate the WEAVE step. 

The stated plan is to have a literate version of the interpreter, the
compiler, the hyperdoc, the graphics and the algebra.



Knuth clearly intended that this be a readable document for someone
interested in TEX. Note that the program has survived and is widely
used despite a thousand other ways to typeset.

The fact that TEX lives is interesting. I used another competing program
call SCRIPT, which was the IBM-sponsored markup language. There have been
many, many others which haven't survived. I believe that the documentation
(and the side benefits of cleaning up the program to publish) is vital.

We've all stated our "positions" on this so I'm not looking for more
restatements. I'm asking for concrete examples of other existing
documentation for other programs so we can "compare and constrast".
Does anyone know of another example of literate programming?
Can we build a biblography of these references?

\start
Date: Mon, 14 May 2007 15:33:31 -0400
From: Bill Page
To: Tim Daly
Subject: RE: Knuth's literate style

On May 14, 2007 2:11 PM Tim Daly wrote:
>
> An interesting reference worth purchasing, checking out from
> a library, or stealing from a friend... In any case, it helps
> to have looked at it carefully at least once as there are many
> features here:
>
> Knuth, Donald E. "TEX, The Program" Addison Wesley, 1986
> ISBN 0-201-13437-3
>
> It will help set the baseline for a discussion of literate
> documentation. This is my current target, modulo using latex-
> compatible chunk syntax to eliminate the WEAVE step.
>
> The stated plan is to have a literate version of the interpreter,
> the compiler, the hyperdoc, the graphics and the algebra.
>
> Knuth clearly intended that this be a readable document for
> someone interested in TEX. Note that the program has survived
> and is widely used despite a thousand other ways to typeset.
>
> The fact that TEX lives is interesting. I used another
> competing program call SCRIPT, which was the IBM-sponsored
> mark-up language. There have been many, many others which
> haven't survived. I believe that the documentation (and the
> side benefits of cleaning up the program to publish) is vital.
>

I agree with all that but I think it is relevant to point out
that TeX has not really survived the development of the World
Wide Web - and interesting irony considering the coincidence
of names. The current generation of web developers clear view
TeX and LaTeX as anachronisms.

> We've all stated our "positions" on this so I'm not looking
> for more restatements. I'm asking for concrete examples of
> other existing documentation for other programs so we can
> "compare and contrast". Does anyone know of another example
> of literate programming?  Can we build a bibliography of these
> references?

Are already several very good (and I think well balanced)
introductions to literate programming on the web. For example:

http://en.wikipedia.org/wiki/Literate_programming

http://www.literateprogramming.com/links.html

One of the links at the site above is to a fairly recent project
that publishes the source code of the project as a literate
program in book form:

http://www.pbrt.org

I don't know how successful (or not) "Physically Based Rendering"
is because (or in spite of) it's use of this "book-style"
literate programming.

Personally I am much more in tune with the review of literate
programming by Kurt N=F8rmark given here:

Literate Programming - Issues and Problems

http://www.cs.auc.dk/~normark/litpro/issues-and-problems.html

In particular I like the following point:

"Paper is not the main program medium.

In Knuth's work, beautiful literate programs were woven from
ugly mixes of markups in combined program and documentation
files. The literate program was directly targeted towards paper
and books. Of obvious reasons, programmers do not very often
print their programs on paper.
...
The development of the Internet in more recent years makes it
attractive to provide for presentation of 'literate programs'
on the Internet. We can think of a World Wide Web browser as
a new attractive program medium for program presentation. This
is already a fact within the Java culture (although the Javadoc
approach has only little to do with the ideals of literate
programming). We can even imagine 'World Wide program development
efforts' via Internet browsers."

Of course I also need to mention (again) Leo:

http://webpages.charter.net/edreamleo/front.html

Leo, of course is written using Leo as the literate programming
environment.

Leo organizes code and documentation in web-like structure that
permits easy navigation and bundles this with an outlining editor
that allows one to focus on one area of code or documentation in
the larger context of the whole project. It also allows one to
define multiple views of the same documentation and code. This
helps people to collaborate more easily in spite of having
different goals and different a emphasis, e.g. Axiom system
developer versus Axiom library developer or Axiom user versus
Axiom developer etc.

Leo allows users to have an integrated view of the whole project
while permitting them to edit and manipulate individual files
that are compatible with conventional build tools, e.g. make,
and source code control systems like CVS. Edits to these files
are automatically "untangled" back into the literate programming
environment.

Here are a few supporting quotes from the Leo website:

"Leo extends, completes and simplifies literate programming

"I've tried Literate Programming tools off and on for more than
10 years, mainly because the promise was so great. I've abandoned
them every time because working with the various Cweb-like tools
was so awkward. Leo changes all that. The most important benefits
promised by Literate Programming are realized by using Leo, without
the awkwardness of the other tools." -- Dave Hein

"[Leo] has enabled me to use Literate Programming in production
for the first time. When I figured out I could do it in plain text
and export to DocBook for automated typesetting, I was on my way.
Because I only do business and utility software, I don't need the
sophistication of LaTeX markup. Writing the documentation and the
code in the same outline at the same time improves the whole product.
Being able to automatically export both with just two key presses
(tangle and export-to-DocBook) is a real luxury." -- Michael Dawson

I wanted to thank you for the effort you've put into Leo. It looks
fantastic. I've always though that Literate Programming was a good
idea, but the tools were completely un-workable. -- Bob Hustead

\start
Date: 14 May 2007 21:54:52 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: Knuth's literate style

Bill Page writes:

> I agree with all that but I think it is relevant to point out that TeX has
> not really survived the development of the World Wide Web - and interesting
> irony considering the coincidence of names. The current generation of web
> developers clear view TeX and LaTeX as anachronisms.

That may well be, but note that in the mathematical world, there is *only*
LaTeX, or among more conservative people, TeX or AmsTeX.

For example, the arXiv accepts other formats then TeX only very reluctantly.
All the large (math-) publishers use TeX for typesetting.  I have not yet been
to any conference which would accept something other than LaTeX source.  Even
wikipedia uses LaTeX style markup for math related entries.

What may be true is that TeX has not been successful in establishing itself as
a markup language for the WWW.  However, you have to keep in mind that only a
tiny fraction of the internet is made for math, and that's where TeX has its
main strength.

Since we are dealing with math, I guess there is no way around LaTeX for us.
Just keep in mind that, at least in the long run, our target audience are
mostly mathematicians, and those will also be our main contributors.  They all
know LaTeX, and I think that using some other markup language instead will
unnecessarily make the entry barrier higher.

Finally, I'd like to state that more important than talking about literate
programming is providing documentation, or, if you like, literate programming.
I think it's quite sad that so little documentation has been provided to the
algebra sources yet.  I think, one especially worthwhile project would be the
integration world.  Another one, maybe a lower hangig fruit, the factorization
routines.  There are excellent sources on the web (especially wikipedia), and
certainly documenting the factorization setup (especially the design of the
categories) will ease cleaning up those terrible bugs.

\start
Date: Mon, 14 May 2007 16:49:58 -0500
From: Tim Daly
To: Martin Rubey
Subject: Algebra documentation

Martin,

When I wasn't working on trying to merge the various version I
was working on the algebra documentation, in particular, quaternions.
See daly.axiom-developer.org/quat.spad.pdf

\start
Date: Mon, 14 May 2007 16:52:16 -0500
From: Tim Daly
To: Bill Page
Subject: Literate documentation

Bill,

Thanks for the pointers.

The key reason Leo does not attract me is that I live in emacs.
However, I will download it and try it.

\start
Date: Mon, 14 May 2007 15:00:06 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Bill Page
Subject: Re: Literate documentation

Does anyone know of something like this movie introducing the SLIME
Lisp environment, but for Leo?

http://common-lisp.net/movies/slime.mov

or

http://common-lisp.net/movies/slime.torrent for the bittorrent aware.

So far I can't really get my brain around Leo :-(.

--- Tim Daly wrote:

> Bill,
> 
> Thanks for the pointers.
> 
> The key reason Leo does not attract me is that I live in emacs.
> However, I will download it and try it.

\start
Date: Mon, 14 May 2007 18:03:52 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Knuth's literate style

On May 14, 2007 3:55 PM Martin Rubey wrote:
> 
> Bill Page writes:
> 
> > I agree with all that but I think it is relevant to point 
> > out that TeX has not really survived the development of
> > the World Wide Web - 
> ... 
> That may well be, but note that in the mathematical world, 
> there is *only* LaTeX, or among more conservative people,
> TeX or AmsTeX.

Of course this actually has very little to do with literate
programming...

But yes, of course I agree with you. However there are also
a lot of mathematicians involved in the MathML and OpenMath
projects which both involve defining XML name spaces for
mathematics. There seems to be a strong desire - at least on
their part - to replace the current "hacks" that allow one to
produce mathematical documents and computer algebra system
output for the web from LaTeX as a source or as an intermediate
language, which is what we do right now on the Axiom wiki.

But my point in mentioning this is not TeX versus HTML.  TeX
is the basis for the Axiom hyperdoc browser and it was also
the basis for the Techexplorer browser which was part of NAG's
commercial release of Axiom for Windows:

http://www.integretechpub.com/techexplorer

(Unfortunately techexplorer was never released as open source.)

What I was thinking was that in spite of Knuth's extensive and
detailed literate documentation of TeX and even it's fairly wide
spread use, Tex was not the mark-up language used in the prototype
implementation of the WWW, so it is not (normally) the language
we use today to write documents for the web. So just documenting
Axiom may not be such a big factor in it's longevity. There are a
lot of other factors, including some over which we have no control,
that may determine whether Axiom lives another 30 years or whether
future computer algebra developers will be writing in Python.

> 
> For example, the arXiv accepts other formats then TeX only 
> very reluctantly. All the large (math-) publishers use TeX
> for typesetting.  I have not yet been to any conference which
> would accept something other than LaTeX source.

You might be surprised how many people I work with who want so
badly to write their scientific and technical documents in
Microsoft WORD. I would say that the number of authors who are
LaTeX users in our environment is currently less than 50% and
it is falling. :-(

> Even wikipedia uses LaTeX style mark-up for math related
> entries.

Yes! The fact that wikipedia is a wiki makes this a very logical
choice, just as it was for us in the Axiom wiki.

> .. 
> Since we are dealing with math, I guess there is no way 
> around LaTeX for us.

I agree fully.

> Just keep in mind that, at least in the long run, our target 
> audience are mostly mathematicians, and those will also be
> our main contributors.  They all know LaTeX, and I think that
> using some other mark-up language instead will unnecessarily
> make the entry barrier higher.

I agree fully.

> 
> Finally, I'd like to state that more important than talking 
> about literate programming is providing documentation, or,
> if you like, literate programming. I think it's quite sad
> that so little documentation has been provided to the
> algebra sources yet.

Yes I agree. We should discuss why this is the case.

Surely one reason is that analyzing an existing program is still
much more difficult than writing a new program. Witness for
example how happily SymPy and Sage developers are to re-write
existing code in their own favourite language.

Another is the issue of "ownership". People are often very
reluctant to change something someone else has written - even
when invited explicitly to do so.

> I think, one especially worthwhile project would be the
> integration world.  Another one, maybe a lower hanging fruit, 
> the factorization routines.  There are excellent sources on
> the web (especially wikipedia), and certainly documenting the
> factorization setup (especially the design of the categories)
> will ease cleaning up those terrible bugs.
> 

How can we make doing this attractive to other people? (This
is especially biting since neither you nor I have done much
in this area - although your guess package for Axiom does
provide a good example for newly written code.)

How will they obtain appropriate "credit" and peer recognition
for this work? What other motivation can we offer them?

\start
Date: Mon, 14 May 2007 18:17:30 -0400
From: Bill Page
To: Cliff Yapp, Tim Daly
Subject: RE: Literate documentation

On May 14, 2007 6:00 PM C Y wrote:
> 
> Does anyone know of something like this movie introducing the
> SLIME Lisp environment, but for Leo?
> 
> http://common-lisp.net/movies/slime.mov
> 
> or
> 
> http://common-lisp.net/movies/slime.torrent for the bittorrent
> aware.
> 
> So far I can't really get my brain around Leo :-(.
> 

It's not a movie but you might want to try:

http://www.3dtree.com/ev/e/sbooks/leo/sbframetoc_ie.htm

\start
Date: 14 May 2007 17:31:50 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Knuth's literate style

If TeX is your gold standard for Axiom, I'm not surprised that
Research funding agencies are no longer interested in spending money
on Axiom.  That is very detrimental to attracting researchers and
research funds to Axiom.

I use TeX or LaTeX, just like I use Windows these days, only because
it is a necessary evil for the immediate constraints.  

\start
Date: Mon, 14 May 2007 15:35:43 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Martin Rubey
Subject: RE: Knuth's literate style

--- Bill Page wrote:

> There seems to be a strong desire - at least on
> their part - to replace the current "hacks" that allow one to
> produce mathematical documents and computer algebra system
> output for the web from LaTeX as a source or as an intermediate
> language, which is what we do right now on the Axiom wiki.

I share that desire, and if the STIX fonts ever see the light of day
there may be real progress in that direction.  However, I would regard
MathML and OpenMath as computer-computer and program-program
interaction methods, not human-computer (except as rendered output, of
course.)

> What I was thinking was that in spite of Knuth's extensive and
> detailed literate documentation of TeX and even it's fairly wide
> spread use, Tex was not the mark-up language used in the prototype
> implementation of the WWW, so it is not (normally) the language
> we use today to write documents for the web. So just documenting
> Axiom may not be such a big factor in it's longevity. There are a
> lot of other factors, including some over which we have no control,
> that may determine whether Axiom lives another 30 years or whether
> future computer algebra developers will be writing in Python.

I rather doubt there will be agreement on the best language to write
CASs in, ever.  My hope is that at some point most writing for computer
algebra systems will take place in languages designed to be close to
the mathematics (SPAD/Aldor) and have a solid framework which only
needs a little tweaking now and then.

> > For example, the arXiv accepts other formats then TeX only 
> > very reluctantly. All the large (math-) publishers use TeX
> > for typesetting.  I have not yet been to any conference which
> > would accept something other than LaTeX source.
> 
> You might be surprised how many people I work with who want so
> badly to write their scientific and technical documents in
> Microsoft WORD. I would say that the number of authors who are
> LaTeX users in our environment is currently less than 50% and
> it is falling. :-(

Gah.  Why is that, do you think?  My experiences with Word have seldom
been positive.  Sheer mass action and familiarity?

> > Finally, I'd like to state that more important than talking 
> > about literate programming is providing documentation, or,
> > if you like, literate programming. I think it's quite sad
> > that so little documentation has been provided to the
> > algebra sources yet.
> 
> Yes I agree. We should discuss why this is the case.

I see two immediate reasons.  One is the difficulty of understanding
the code.  The second is the inherent difficulty of the subjects
themselves. 

There are other more "fuzzy" possibilities, such as people waiting to
see if Axiom will emerge as a major player again in the CAS world.  It
cannot be denied that Mathematica has very flashy graphics, marketing
and polish - it's only human nature to be impressed by these things.  
 
> Surely one reason is that analyzing an existing program is still
> much more difficult than writing a new program. Witness for
> example how happily SymPy and Sage developers are to re-write
> existing code in their own favourite language.

That will remain true until the benefits gained by understanding the
environment in which the original code was written outweigh porting the
ideas into your own.  This is HARD.  I believe Axiom can achieve a
sufficiently strong environment that NOT learning it is a bigger
inconvenience than learning it, but the benefits provided must be
major.  We aren't close yet.

> Another is the issue of "ownership". People are often very
> reluctant to change something someone else has written - even
> when invited explicitly to do so.

I can only speak for myself, but I think this is much less of a problem
for me than simply getting up to speed enough to feel I can do
something worthwhile.  Axiom is a large territory to learn.

Also, Tim's warnings of very subtle breakages and complex code in Axiom
are somewhat intimidating.  As the territory gets mapped I think this
problem will ease somewhat. (An undocumented codebase in that state is
broken by definition, in my book - the only thing to do is get busy
breaking stuff until everything that can be broken is broken and fixed
to be more robust ;-)

> How can we make doing this attractive to other people? (This
> is especially biting since neither you nor I have done much
> in this area - although your guess package for Axiom does
> provide a good example for newly written code.)

I really think a framework within which to work would help this
problem.  I have seen references to something called Mathematical
Knowledge Management which may be a good place to look for ideas.  As I
look over the 2001 MKM proceedings
http://www0.risc.uni-linz.ac.at/institute/conferences/MKM2001/Proceedings/
I am seeing names I recognize ;-).  Pity the rest are not available
online, oh well...
 
> How will they obtain appropriate "credit" and peer recognition
> for this work? What other motivation can we offer them?

That's a point, actually - has anyone published any papers recently
showcasing work done in/for Axiom?  That seems like the most logical
pathway to me, although it would mean writing at least two papers - one
for the Axiom codebase and one for publishing, since those journals
generally take copyright...

\start
Date: Mon, 14 May 2007 15:46:00 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis, Bill Page
Subject: Re: Knuth's literate style

--- Gabriel Dos Reis wrote:

> 
> If TeX is your gold standard for Axiom, I'm not surprised that
> Research funding agencies are no longer interested in spending money
> on Axiom.  That is very detrimental to attracting researchers and
> research funds to Axiom.

If you don't mind my asking, why do you say this Gaby?

\start
Date: Mon, 14 May 2007 18:07:08 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Knuth's literate style

On Mon, 14 May 2007, C Y wrote:

| 
| --- Gabriel Dos Reis wrote:
| 
| > 
| > If TeX is your gold standard for Axiom, I'm not surprised that
| > Research funding agencies are no longer interested in spending money
| > on Axiom.  That is very detrimental to attracting researchers and
| > research funds to Axiom.
| 
| If you don't mind my asking, why do you say this Gaby?


Is your research funding agency interested in funding a research project that
sets TeX as a Gold standard? 

\start
Date: 14 May 2007 19:37:55 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: [build-improvements] more character stuff

Greetings!

Gabriel Dos Reis writes:

> On Sun, 13 May 2007, Waldek Hebisch wrote:
> 
> | BTW. Jurgen Weiss made choce between character and string-char
> | conditional.  It is not clear for me if GCL supports ANSI
> | enough to work well using character
> 
> I forgot to mention that I looked at the GCL info file and I did
> not spot anything obvious that made the use of character type
> inappropriate.
> 
> | -- we probably should ask
> | Camm if there are any issues making string-char preferable
> | for GCL.
> 
> Camm, do we have good enough support for the ANSI Lisp
> character type so that we can use it in lie of string-char?
> 

'character and 'string-char are aliases in most instances.  After
poking around a bit in 2.6.x, the only possible gotcha I found was

(array-element-type (make-array 10 :element-type 'character)) -> 'string-char

string-char is currently out of 2.7, but I'll probably put it in as
deftyped to character for cltl1 compliance before release.  2.7
appears fully ansi compliant in this regard as far as I can tell. 

\start
Date: Mon, 14 May 2007 18:42:30 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Literate documentation

Gaby,

I've had extensive discussion with 3 different funding groups at the NSF
and one at NIST. 

The problem isn't latex. The problems appear to be:

1) They won't fund work being done by commercial companies

     As long as Mathematica and Maple exist they will not fund Axiom.
     Of course, if Mathematica and Maple disappear it will be way too
     late to consider funding Axiom as the whole of computational
     mathematics will likely disappear down the wasted effort hole.

     When the Symbolics company folded it "captured" Macsyma, a major
     effort from MIT, and effectively killed it. The GPLed version,
     Maxima, only exists due to the effort of Bill Schelter and was
     several years out of date.

     When (not if, since there are very few companies that exist for
     50 years) Wolfram and Maplesoft die there is the likely possibility
     that the code will be lost to the world, as in the Macsyma case.
     The code represents a large pile of "intellectual property" and
     will not be freely released, and will likely not be available at all.


2) They won't fund work that is done by individuals

     Funded work needs an existing funding source that can handle the
     finances. A university has a provost to take 55% or more of the
     cash as "overhead". Open source does not have the financial
     machinery in place to accept grant money or manage the required
     reporting requirements.

     Funding an open source project with grant money has also
     raised the question about how to distribute and use the funds.
     Do we pay individuals? How do we judge the work? How is the
     work to be reported? Who manages the money?

     I've pointed out that open source could use the funding in at
     least four "group" related ways. One to fund a developer
     conference covering travel, etc. A second is to fund a
     "compile farm" setup at a data center which contains a wide
     range of machines and operating systems. Such a farm could
     be used by many open source projects. A third would be to fund
     the purchase of property rights in Macysyma (the last quoted
     figure I got was $250K for the source code).

     The fourth idea is by far the most interesting and ambitious.
     The idea is to follow Bruno Buchbergers lead and create a U.S.
     version (or branch) of the RISC (Research in Symbolic Computation)
     institute. RISC funded both research and industry work.

3) They won't fund developers outside the country

     The NSF and NIST are federal agencies and are not much interested
     in funding people who live and work overseas. They might fund a
     "visiting scientist" position for someone working at a university
     but that would not apply to an individual developer.

     I have not had any contact with INRIA or other European funding
     agencies but I suspect they might have the same objection. Since
     open source is worldwide there is no funding agency with the 
     span of control to handle funding. 


My conclusion is that the NSF and NIST are irrelevant to open source.

For a while Gilbert Baumslag funded Axiom development as part of the
CAISS project at City College of New York. Gilbert, however, is rather
more enlightened and sensitive to the long term value of computational
mathematics than the NSF or NIST management.

Thus, the funding issue is WAY above the latex question.

\start
Date: Mon, 14 May 2007 18:59:33 -0500 (CDT)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: [build-improvements] more character stuff

On Mon, 14 May 2007, Camm Maguire wrote:

| 'character and 'string-char are aliases in most instances.  After
| poking around a bit in 2.6.x, the only possible gotcha I found was
| 
| (array-element-type (make-array 10 :element-type 'character)) -> 'string-char
| 
| string-char is currently out of 2.7, but I'll probably put it in as
| deftyped to character for cltl1 compliance before release.  2.7
| appears fully ansi compliant in this regard as far as I can tell. 

That is pretty neat!

\start
Date: Mon, 14 May 2007 17:01:14 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Knuth's literate style

--- Gabriel Dos Reis wrote:

> On Mon, 14 May 2007, C Y wrote:
>
> | If you don't mind my asking, why do you say this Gaby?
> 
> Is your research funding agency interested in funding a research
> project that sets TeX as a Gold standard? 

At the moment, I have no research funding agency.  I'm just a hobbiest
with a day job.

Whether any agency is willing to fund any of the sort of work we are
doing here is an open question - a couple of comments I heard at ECCAD
hinted at some shifts in the funding landscape that aren't especially
encouraging.

I hadn't heard of association with TeX as being a detrimental factor to
a project.

\start
Date: Mon, 14 May 2007 19:19:18 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Literate documentation

On Mon, 14 May 2007, Tim Daly wrote:

| Gaby,
| 
| I've had extensive discussion with 3 different funding groups at the NSF
| and one at NIST. 
| 
| The problem isn't latex.

I do hope that the problem isn't latex.


However, I do believe that the problem is with *how the Axiom is presented*
to funding agencies.


That was the original point of my message.

[ don't look at my finger; I'm pointing at the moon. ]


| The problems appear to be:
| 
| 1) They won't fund work being done by commercial companies

People get federal money for work on Sage.

[...]

| 2) They won't fund work that is done by individuals
| 
|      Funded work needs an existing funding source that can handle the
|      finances. A university has a provost to take 55% or more of the
|      cash as "overhead". Open source does not have the financial
|      machinery in place to accept grant money or manage the required
|      reporting requirements.
| 
|      Funding an open source project with grant money has also
|      raised the question about how to distribute and use the funds.
|      Do we pay individuals? How do we judge the work? How is the
|      work to be reported? Who manages the money?

Federal money supports several open source projects -- just google
around.

[...]

| 3) They won't fund developers outside the country
| 
|      The NSF and NIST are federal agencies and are not much interested
|      in funding people who live and work overseas. They might fund a
|      "visiting scientist" position for someone working at a university
|      but that would not apply to an individual developer.

I'm would not ask NSF or NIST to fund "developers" outside the country.
(If I were NSF or NIST, I would not give the money).

However, NSF and NIST are interested in funding *innovative research*
projects.  The question is how do you get to present Axiom as a research
project that supports innovation?  Don't tell me by building something like
TeX or the TeX book.

|      I have not had any contact with INRIA or other European funding
|      agencies but I suspect they might have the same objection. Since
|      open source is worldwide there is no funding agency with the 
|      span of control to handle funding. 

Notice that European agencies are funding open source (research) projects.
A recent example I'm aware of to some degree:

    http://gcc.gnu.org/ml/gcc/2006-10/msg00676.html

and for more information:

    http://www.itea-office.org/

| My conclusion is that the NSF and NIST are irrelevant to open source.

I believe your conclusions are at odd with facts.

\start
Date: Mon, 14 May 2007 19:21:40 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Knuth's literate style

On Mon, 14 May 2007, C Y wrote:

| --- Gabriel Dos Reis wrote:
| 
| > On Mon, 14 May 2007, C Y wrote:
| >
| > | If you don't mind my asking, why do you say this Gaby?
| > 
| > Is your research funding agency interested in funding a research
| > project that sets TeX as a Gold standard? 
| 
| At the moment, I have no research funding agency.  I'm just a hobbiest
| with a day job.
| 
| Whether any agency is willing to fund any of the sort of work we are
| doing here is an open question - a couple of comments I heard at ECCAD
| hinted at some shifts in the funding landscape that aren't especially
| encouraging.
| 
| I hadn't heard of association with TeX as being a detrimental factor to
| a project.

I'm pointing at the moon, don't look at my finger.

The detrimental factor is not the association with TeX per se.
But setting TeX as the gold standard: to be blunt, that lacks ambition and
vision; I don't see how a research funding agency would be excited funding
something like that in 2007.

\start
Date: Mon, 14 May 2007 20:01:40 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Literate documentation

Gaby,

http://www.ggcc.info appears to be a consortium of companies,
not an open source project in the "axiom" sense. 

Sage appears to be a research project at the University of Washington,
again not an open source project in the "axiom" sense.

Both of these projects have a grant-managing offices.

Granting agencies can handle government-to-organization funding
but not government-to-individuals.

The point of my post is that open source projects like Axiom, 
Rosetta, or Doyen cannot be funded under today's machinery as
stand-alone projects. At least that's the statement of NSF and
NIST program managers.

\start
Date: Mon, 14 May 2007 21:02:59 -0400
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Knuth's literate style

Gabriel Dos Reis wrote:
> On Mon, 14 May 2007, C Y wrote:
>
> | I hadn't heard of association with TeX as being a detrimental factor to
> | a project.
> 
> I'm pointing at the moon, don't look at my finger.
> 
> The detrimental factor is not the association with TeX per se.
> But setting TeX as the gold standard: to be blunt, that lacks ambition and
> vision; I don't see how a research funding agency would be excited funding
> something like that in 2007.

The vision, as I understand it, is to incorporate the vast body of
mathematical knowledge that exists today in a form readily
understandable and usable both by human and computer.  How do we encode
mathematical knowledge in such a fashion that there will be no major
incentive to re-code it in the future?  What is a system design that
will scale as far as necessary?

Some related questions:

1.  How do we avoid duplicating research accidentally due to
students/researchers not having the resources to do comprehensive
literature searches?  As the body of literature keeps growing the
ability of one person to be aware of everything they could use
decreases.  How do we solve this problem?

2.  Formal correctness proofs of mathematical statements in both science
and mathematics as a default inclusion would be a considerable help in
preventing certain types of errors.  What kind of system do we need to
merge formal proof systems and computer algebra systems?  How should it
be done?  What features are needed?  What kind of system is necessary to
produce answers reliable enough for scientists to depend on them?

TeX as such is only one small part of the puzzle.  It (or something like
it) is necessary but not sufficient.  Literate programming or
developments there-of are a tool, a means to an end.  However, because
literate programming has not seen a whole lot of development we need to
implement the basic functionality before we scale beyond it.  TeX is the
"gold standard" in that it is probably the most widely known, widely
used example of literate programming in action.  It also does its job
well enough to be a standard many years after the core work was
completed.  That makes it an interesting case study as well as a tool -
its success over the long term is something to pay attention to.

To my mind, funding development on Axiom at this stage should be
properly viewed as doing groundwork for the future.  The problems we are
grappling with now are secondary - what we really want is the framework
within which mathematical research via computer can scale.

If Axiom proper is the space shuttle, right now we're working on the
platform that moves it from the warehouse to the launch pad.  Doesn't
have much to do with mathematics per say, but it's absolutely essential
infrastructure.  The exciting part comes later.

Whether this is something that should be funded, I don't know.  I would
think that a publicly available resource of this sort would be a logical
thing for a government to support - it's a type of project that
commercial organizations won't be interested in, and ideally it would
provide the same benefits for mathematical research that the highway
system does for national travel.  That's just my opinion though - I have
no detailed knowledge of the NSF/NIST funding mandates.

\start
Date: Mon, 14 May 2007 20:22:24 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Literate documentation

On Mon, 14 May 2007, Tim Daly wrote:

| Gaby,
| 
| http://www.ggcc.info appears to be a consortium of companies,
| not an open source project in the "axiom" sense. 

Global GCC is a project *within* the ITEA 2 framework (which I pointed to in
an earlier message). 

>From the web site above, you can read:
  
  The GGCC project will last 30 months and is partly funded (around 30%-40%)
  by French, Spanish and Swedish public authorities.


I think 30% is not negligible, when compared to zero :-)

| Sage appears to be a research project at the University of Washington,
| again not an open source project in the "axiom" sense.


    http://modular.math.washington.edu/sage/
    SAGE: Free Open Source Mathematics Software 

    http://modular.math.washington.edu/sage/ack.html

Financial and Infrastructure Support:

    * University of Washington, Department of Mathematics (startup money)
    * University of Washington / NSF, five undergraduates have been funded via
       the NSF VIGRE grant.
    * University of Washington, Dept. of Computer Science, for providing the
        SAGE lab (Sieg Hall 312).
    * University of Washington, Yi Qiang received a Mary Gates Scholarship.
    * The National Science Foundation under Grant No. 0555776.
    * MSRI -- two major workshops
    * IPAM -- hosted and funded SAGE Days 3 

| Both of these projects have a grant-managing offices.


But it remains a fact that NSF (and funding federal agencies) does support
open source (research) projects.  Now, it may be that Axiom, in particular,
has problems getting funds; that is a whole different story that tracing that
federal agencies refusing to put money in mathematical computational open
source projects because there are commercial companies.

[...]

| The point of my post is that open source projects like Axiom, 
| Rosetta, or Doyen cannot be funded under today's machinery as
| stand-alone projects. At least that's the statement of NSF and
| NIST program managers.

I'm not questioning what NSF and NIST program managers said.

I'm just pointing out at some facts and trying to match those with your
statements/conclusions.

\start
Date: Mon, 14 May 2007 20:27:37 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Knuth's literate style

On Mon, 14 May 2007, C Y wrote:

| If Axiom proper is the space shuttle, right now we're working on the
| platform that moves it from the warehouse to the launch pad. 

Then ask money for the space shuttle.  That is what drives you.  Not the
launch pad -- as necessary means as it might be. 

\start
Date: Mon, 14 May 2007 21:35:53 -0400
From: Bill Page
To: Tim Daly
Subject: RE: Literate documentation
Cc: Gabriel Dos Reis

On May 14, 2007 7:43 PM Tim Daly wrote:
> ... 
> 2) They won't fund work that is done by individuals
> 
>      Funded work needs an existing funding source that can handle
>      the finances. A university has a provost to take 55% or more
>      of the cash as "overhead". Open source does not have the
>      financial machinery in place to accept grant money or manage
>      the required reporting requirements.
> 
>      Funding an open source project with grant money has also
>      raised the question about how to distribute and use the
>      funds. Do we pay individuals? How do we judge the work? How
>      is the work to be reported? Who manages the money?
>
>      I've pointed out that open source could use the funding in at
>      least four "group" related ways. One to fund a developer
>      conference covering travel, etc. A second is to fund a
>      "compile farm" setup at a data center which contains a wide
>      range of machines and operating systems. Such a farm could
>      be used by many open source projects. A third would be to
>      fund
> ... 
> 
> My conclusion is that the NSF and NIST are irrelevant to open
> source.
> ...

It might be interesting to note that the initial development of the
Sage project was funded by NSF and involved both your first and
second examples of "group" related ways of spending the money as
well as funding the work of some graduate students. It is true
however that William Stein was (and is still) working in the context
of a university with a provost. I do not know however what the long
term prospects are for the continuation of this kind of support for
Sage.

http://sage.math.washington.edu/sage/ack.html
http://sage.math.washington.edu

\start
Date: 14 May 2007 20:37:18 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Knuth's literate style

Cliff Yapp writes:

[...]

| > How will they obtain appropriate "credit" and peer recognition
| > for this work? What other motivation can we offer them?
|
| That's a point, actually - has anyone published any papers recently
| showcasing work done in/for Axiom?

Jacob Smith, a student of a colleague (Jaakko J=E4rvi), took my class on
symbolic computations last fall. For his class project, he choosed
Algorithmic Differentiation in Axiom.  We were able to implement both
forward and backward modes in Axiom.  As a by product, that led me to
implement a small Axiom library for representing Spad programs (both
interpreted and compiled) as typed abstract syntax tree -- which I'm
now using in my "toy" Spad compiler written in Spad.  That also
pressed me to start (earlier than planned) a formal definition of Spad
(not easy).  The work will be presented at ISSAC'07.

\start
Date: Mon, 14 May 2007 22:47:14 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Knuth's literate style

On May 14, 2007 6:36 PM C Y wrote:
> ... 
> I rather doubt there will be agreement on the best language to
> write CASs in, ever.  My hope is that at some point most writing
> for computer algebra systems will take place in languages designed
> to be close to the mathematics (SPAD/Aldor) and have a solid
> framework which only needs a little tweaking now and then.

Although I am irrevocably committed to promoting Axiom and Aldor
as the appropriate tools for computer algebra, I found Ondrej
Certik remarks on this list concerning his reasons for choosing
Python for SymPy rather compelling. The reasoning is simple: 1)
Python is familiar to millions of current generation programmers,
2) Python is adequate (while admittedly not perfect) for developing
a computer algebra system, 3) To move any open source project
forward it is necessary to attract the interest of a significant
number of potential contributors, 4) There is a considerable
resistance on the part of most people to learn a new programming
language just in order to participate in a volunteer effort.
Therefore SymPy (and Sage).

Perhaps Voltaire said it better: "Le mieux est l'ennemi du bien."
(The best is the enemy of the good.)

In other words: trying too hard can get you no where. I think
that to some extent both Axiom and Lisp suffer from this sort
of syndrome. But I do not know what if anything should be done
about it.

> ...
> Bill Page wrote:
> > 
> > You might be surprised how many people I work with who want so
> > badly to write their scientific and technical documents in
> > Microsoft WORD. I would say that the number of authors who are
> > LaTeX users in our environment is currently less than 50% and
> > it is falling. :-(
> 
> Gah.  Why is that, do you think?  My experiences with Word have
> seldom been positive.  Sheer mass action and familiarity?

I might be rather biased but I think the main reason is
institutional. Microsoft offers their customers the usual
"security blank": you pay us money, we provide you with some
level of support. There is no equivalent arrangement possible
concerning LaTeX. In contrast it is possible (but still difficult)
to promote OpenOffice to corporate instructions just because you
can pay Sun for exactly the same thing that you get for free in
OpenOffice. It is this corporate "mindset" that keeps a lot of
open source software out of the major instutions (outside the
university environment).

A secondary issue of course is that LaTeX (at least in part by
deliberate design) is not normally written in a WYSIWYG style.
This leads to a steeper learning curve which one might have to
climb more than once depending on how frequently you author
publications of this type. I think it is hard to convince most
people that this effort is "worth it" (although I personally
believe that it is).

Finally a third issue is merely a matter of fashion. It is not
currently fashionable to use "legacy" tools of this kind. Most
people are looking for something new and sexy and easy... even
if the result is not necessarily as good as that produced by
the "pioneers" (like Knuth).

> > Martin Rubey wrote: 
> > > ...
> > > I think it's quite sad that so little documentation has
> > > been provided to the algebra sources yet.
> > 
> > Yes I agree. We should discuss why this is the case.
> 
> ...
> I believe Axiom can achieve a sufficiently strong environment
> that NOT learning it is a bigger inconvenience than learning
> it, but the benefits provided must be major.  We aren't close
> yet.

I have serious doubts that we can ever get "there". I can not
see any real possibility of making the user interface so
seamless, the programming language so "natural", or of obtaining
some new  mathematical result using Axiom so astounding that a
significant number of people will see "MOT learning Axiom" as an
inconvenience.

> ... 
> > How can we make doing this attractive to other people?
> ...  
> > How will they obtain appropriate "credit" and peer recognition
> > for this work? What other motivation can we offer them?
> 
> That's a point, actually - has anyone published any papers
> recently showcasing work done in/for Axiom?  That seems like
> the most logical pathway to me, although it would mean writing
> at least two papers - one for the Axiom codebase and one for
> publishing, since those journals generally take copyright...
> 

I find that the Sage developers generally have a very good handle
on how to organize this sort of work. First and foremost I think
was the original decision to "assimilate" other open source computer
algebra projects rather than competing directly with them. (Yes I
do mean assimilate in the Star Trek sense: "Resistance is futile".
:-) But seriously, I think they have done a number of other things
right. See for example

"Submission of Refereed Code to SAGE"

http://sage.math.washington.edu/sage/jsage

Tim Daly has suggested (more or less) this sort of approach for
Axiom. I believe something similar is in place for GAP and that
was probably the model that Sage is following. If it were somehow
(someday) possible to establish this sort of peer review
"publication" process for Axiom, I think it might go a long way
toward providing a means to "credit" people for their work in a
way that means something to both the average university supported
researcher and the dedicated open source hobbyist.

\start
Date: Mon, 14 May 2007 22:57:35 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Knuth's literate style

> ...
> Jacob Smith, a student of a colleague (Jaakko J=E4rvi), took my
> class on symbolic computations last fall. For his class project,
> he choosed Algorithmic Differentiation in Axiom.  We were able
> to implement both forward and backward modes in Axiom.  As a by
> product, that led me to implement a small Axiom library for
> representing Spad programs (both interpreted and compiled) as
> typed abstract syntax tree -- which I'm now using in my "toy"
> Spad compiler written in Spad.  That also pressed me to start
> (earlier than planned) a formal definition of Spad (not easy).
> The work will be presented at ISSAC'07.
>

Excellent! I will be very interested in your publication. Also
I am hoping that you and Jacob will be motivated to contribute
this work to the Axiom Library and to discuss the work via the
axiom-math email list and/or the Axiom wiki.

\start
Date: Mon, 14 May 2007 20:51:11 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Knuth's literate style

--- Bill Page wrote:

> On May 14, 2007 6:36 PM C Y wrote:
> > ... 
> > I rather doubt there will be agreement on the best language to
> > write CASs in, ever.  My hope is that at some point most writing
> > for computer algebra systems will take place in languages designed
> > to be close to the mathematics (SPAD/Aldor) and have a solid
> > framework which only needs a little tweaking now and then.
> 
> Although I am irrevocably committed to promoting Axiom and Aldor
> as the appropriate tools for computer algebra, I found Ondrej
> Certik remarks on this list concerning his reasons for choosing
> Python for SymPy rather compelling. The reasoning is simple: 1)
> Python is familiar to millions of current generation programmers,
> 2) Python is adequate (while admittedly not perfect) for developing
> a computer algebra system, 3) To move any open source project
> forward it is necessary to attract the interest of a significant
> number of potential contributors, 4) There is a considerable
> resistance on the part of most people to learn a new programming
> language just in order to participate in a volunteer effort.
> Therefore SymPy (and Sage).

Rather than get into the dangerous ground of trying to compare Sage to
other systems, I merely remark that Sage by virtue of its incorporation
of a large number of diverse components can be said to be using a large
number of programming languages.  Python happens to be the "glue" but
their core functionality is scattered over a wide range of programs.

> Perhaps Voltaire said it better: "Le mieux est l'ennemi du bien."
> (The best is the enemy of the good.)

Arguably.  But sometimes only the best will do ;-).

> In other words: trying too hard can get you no where. I think
> that to some extent both Axiom and Lisp suffer from this sort
> of syndrome. But I do not know what if anything should be done
> about it.

I would say the existence of Sage and Maxima relieves us of some roles
we might otherwise be pressured to fill.  For most immediate uses, Sage
and Maxima are focused on  "getting the job done".  (Whatever that
phrase means.)  That has obvious practical benefits and there is a need
for such systems.  Because that need is being filled, Axiom can go
after the comparatively new territory of "getting the job done Right." 
As Tim likes to observe, when that becomes the goal there is no such
thing as a simple job.  That's why I don't expect any major commercial
system to ever pursue such a goal - the marginal gains from "almost
always correct" to "breaking new ground in correctness assurance"
aren't really all that high.  Mathematica isn't correct 100% of the
time, but it cannot be denied it is close enough for major commercial
success.  However, I personally think pursuit of the goal of "computer
algebra done Right" is a benefit to mathematics and science (or will be
once it does finally start achieving results.)  Again, that's one
person's opinion.

> > ...
> > Bill Page wrote:
> > > 
> > > You might be surprised how many people I work with who want so
> > > badly to write their scientific and technical documents in
> > > Microsoft WORD. I would say that the number of authors who are
> > > LaTeX users in our environment is currently less than 50% and
> > > it is falling. :-(
> > 
> > Gah.  Why is that, do you think?  My experiences with Word have
> > seldom been positive.  Sheer mass action and familiarity?
> 
> I might be rather biased but I think the main reason is
> institutional. Microsoft offers their customers the usual
> "security blank": you pay us money, we provide you with some
> level of support. There is no equivalent arrangement possible
> concerning LaTeX. In contrast it is possible (but still difficult)
> to promote OpenOffice to corporate instructions just because you
> can pay Sun for exactly the same thing that you get for free in
> OpenOffice. It is this corporate "mindset" that keeps a lot of
> open source software out of the major instutions (outside the
> university environment).

Yes, that's true enough - open source is a very foreign mindset to many
for-profit institutions.

> A secondary issue of course is that LaTeX (at least in part by
> deliberate design) is not normally written in a WYSIWYG style.
> This leads to a steeper learning curve which one might have to
> climb more than once depending on how frequently you author
> publications of this type. I think it is hard to convince most
> people that this effort is "worth it" (although I personally
> believe that it is).

Agreed.  Learning powerful tools almost always pays back the effort
many times over, but the up front investment must be made.  Just like
capital investments by corporations, in fact...

> Finally a third issue is merely a matter of fashion. It is not
> currently fashionable to use "legacy" tools of this kind. Most
> people are looking for something new and sexy and easy... even
> if the result is not necessarily as good as that produced by
> the "pioneers" (like Knuth).

Yes, I've noticed that and I regard it as a sign of immaturity in the
software world.  We should be writing in such a fashion that "legacy"
is no longer a word for old software that doesn't work in new
environments - we have enough hardware power and experience with
abstraction now that there is no excuse for this.  This is actually a
benefit of the sometimes frustrating "set in stone" quality of the ANSI
Common Lisp language specification - it makes for a very stable
platform.  

TeX proved that it is possible to write software so good people keep
using it for decades.  I think it's probably questionable whether TeX
can really be regarded as "done" (many of its most useful extensions
are actually very important in making it useful today) but it is
probably closer to it than any other software program I am aware of.

> I have serious doubts that we can ever get "there". I can not
> see any real possibility of making the user interface so
> seamless, the programming language so "natural", or of obtaining
> some new  mathematical result using Axiom so astounding that a
> significant number of people will see "MOT learning Axiom" as an
> inconvenience.

If we have a significant fraction of all mathematical research
implemented in a readily accessible fashion that allows rapid
experimentation and development of new algorithms, researchers who
don't use it may find themselves at a disadvantage.  That's the goal
anyway - who knows if it can be achieved?  Only one way to find out -
build the best system we can and keep making it better :-).
 
> I find that the Sage developers generally have a very good handle
> on how to organize this sort of work. First and foremost I think
> was the original decision to "assimilate" other open source computer
> algebra projects rather than competing directly with them.

For the goals of Sage this works, but I think the aggregation of so
many different systems may prove too fragile for some of the formal
proof dreams some of the Axiom developers harbor :-).

One of the more interesting sessions at ECCAD was the question and
answer session.  I guess none of us have summarized ECCAD yet but one
of the most interesting points for me was when (in response to a
question from Tim, IIRC) at least one of the panel said they saw some
merit in a "collection" of formally proven mathematics being
universally available.  (that's a rough paraphrase.)  I have always
thought this was a good niche for Axiom to fill - take the mathematical
work out there, fit it into the overall picture, write it up, and
implement it.  Then, prove it correct ;-).

> (Yes I do mean assimilate in the Star Trek sense: "Resistance is
> futile". :-) But seriously, I think they have done a number of other
> things right. See for example
> 
> "Submission of Refereed Code to SAGE"
> 
> http://sage.math.washington.edu/sage/jsage
> 
> Tim Daly has suggested (more or less) this sort of approach for
> Axiom. I believe something similar is in place for GAP and that
> was probably the model that Sage is following. If it were somehow
> (someday) possible to establish this sort of peer review
> "publication" process for Axiom, I think it might go a long way
> toward providing a means to "credit" people for their work in a
> way that means something to both the average university supported
> researcher and the dedicated open source hobbyist.

Agreed.  As our foundation gets more stable and well documented this
will become possible, and I think it will be important to the future of
Axiom.  After all, the best way to get new research into the system is
to have people do the research using it and contribute it back ;-).

\start
Date: Mon, 14 May 2007 20:53:06 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Gabriel Dos Reis
Subject: RE: Knuth's literate style

--- Bill Page wrote:

> On May 14, 2007 9:37 PM Gaby wrote:
> > ... 
> > Jacob Smith, a student of a colleague (Jaakko Jrvi), took my
> > class on symbolic computations last fall. For his class project,
> > he choosed Algorithmic Differentiation in Axiom.  We were able
> > to implement both forward and backward modes in Axiom.  As a by
> > product, that led me to implement a small Axiom library for
> > representing Spad programs (both interpreted and compiled) as
> > typed abstract syntax tree -- which I'm now using in my "toy"
> > Spad compiler written in Spad.  That also pressed me to start
> > (earlier than planned) a formal definition of Spad (not easy).
> > The work will be presented at ISSAC'07. 
> > 
> 
> Excellent! I will be very interested in your publication. Also
> I am hoping that you and Jacob will be motivated to contribute
> this work to the Axiom Library and to discuss the work via the
> axiom-math email list and/or the Axiom wiki.

Indeed, very good news!  Darn it, now I'm going to have to figure out
some way to get up to ISSAC07...

\start
Date: 15 May 2007 08:42:50 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: Knuth's literate style

Bill Page writes:

> > For example, the arXiv accepts other formats then TeX only 
> > very reluctantly. All the large (math-) publishers use TeX
> > for typesetting.  I have not yet been to any conference which
> > would accept something other than LaTeX source.
> 
> You might be surprised how many people I work with who want so
> badly to write their scientific and technical documents in
> Microsoft WORD. I would say that the number of authors who are
> LaTeX users in our environment is currently less than 50% and
> it is falling. :-(

No, I'm not surprised.  I never said that TeX would be perfect - although I
find it bloody good.  I'd also expect that there are some differences between
different communities: I'd guess that LaTeX is OK but not necessary in the
Computer Science world, for example. Within mathematics it's indispensible.  As
I said, I don't think you'll find a serious math conference or a serious
publisher that accepts anything but LaTeX source.

> > I think, one especially worthwhile project would be the
> > integration world.  Another one, maybe a lower hanging fruit, 
> > the factorization routines.  There are excellent sources on
> > the web (especially wikipedia), and certainly documenting the
> > factorization setup (especially the design of the categories)
> > will ease cleaning up those terrible bugs.

> How can we make doing this attractive to other people? 

By writing interesting packages others want to use.  And, most important: why
should "somebody else" do it?  You (= not necessarily you, but you or you or
you...) should do it.

People will start contributing to Axiom as soon as they believe that Axiom is a
project which will survive.  Currently, it is not quite convincing, as Waldek
pointed out some time ago.  Too many bugs unfixed.  If you like to do something
useful, pick a topic, stick to it, become an "expert", not necessarily a
"creative expert" (meaning: somebody who invents new algorithms like
Zeilberger), but an expert who knows what the code is doing and why.  If you're
lucky, you'll even become a "creative expert".

As an example, Andrew Rechnitzer wrote me an email out of the blue saying
"thank you" for my guessing package, and asking in the next sentence how he'd
get the results into Maple.  I asked for the reason.  Answer: Axiom cannot do
the conversion

  Polynomial Recurrence Relation <-> Linear Ordinary Differential Equation

yet.  So, here is another project, and a bloody interesting, too.  Furthermore,
it's not even so difficult stuff, what concerns maths.  Most important step
would be to write down the categories.  The implementation is, mostly, not that
difficult.

> How will they obtain appropriate "credit" and peer recognition
> for this work? What other motivation can we offer them?

I guess, for documentation you can only get interested students that are
currently studying the relevant subjects, i.e., Algebra, Number Theory,
Cryptography for the example concerning factorization.

For math researchers, it is usually a very bad idea to work on documentation or
even programming.  Most of the time, you cannot even get interesting programs
published, unless they contain substantially new ideas.

Bounties may help, especially in countries where income is low in comparison
with the US or Austria.  I think, Russia, Poland, Czech Republic, Slovakia are
prime candidates.  I'll advertise Axiom in China this summer.

\start
Date: 15 May 2007 08:59:09 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Funding

Dear all,

I think you are all right, but you are all missing the others message -- and I
like to do that too :-)

* The world does not only consist of the US, i.e., there is not only the NSF.

* The Austrian fund FWF, and I believe the same holds for the NSF and EU funds,
  does not support "implementation of known things", not even if they are
  implemented more intelligently or something.

* all funds support "research".

So, you have to ask for money for doing research, i.e., creating something new.
Of course, that's not easy, especially if you are not as well known as William
Stein.  In any case, I'd be surprised if William got money for implementing
things in SAGE, at least not initially. (Now he's famous, so he might get money
for anything.)  I'd rather believe that he got money for exploring some
mathematical structures.

In any case, documentation will not get funded.  Research including
documentation will.

Research could be: implement Joris van der Hoevens zero-test for differentially
algebraic functions and some others, benchmark and conclude that Joris was
right.

\start
Date: Tue, 15 May 2007 08:11:13 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: Knuth's literate style


On Mon, 14 May 2007, Bill Page wrote:

| On May 14, 2007 9:37 PM Gaby wrote:
| > ...
| > Jacob Smith, a student of a colleague (Jaakko J=E4rvi), took my
| > class on symbolic computations last fall. For his class project,
| > he choosed Algorithmic Differentiation in Axiom.  We were able
| > to implement both forward and backward modes in Axiom.  As a by
| > product, that led me to implement a small Axiom library for
| > representing Spad programs (both interpreted and compiled) as
| > typed abstract syntax tree -- which I'm now using in my "toy"
| > Spad compiler written in Spad.  That also pressed me to start
| > (earlier than planned) a formal definition of Spad (not easy).
| > The work will be presented at ISSAC'07.
| >
|
| Excellent! I will be very interested in your publication. Also
| I am hoping that you and Jacob will be motivated to contribute
| this work to the Axiom Library and to discuss the work via the
| axiom-math email list and/or the Axiom wiki.

It is my hope that the library will become part of regular Axiom
distribution.  Jacob will be at ISSAC.

\start
Date: Tue, 15 May 2007 15:47:52 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Literate documentation

> It's not a movie but you might want to try:
> 
> http://www.3dtree.com/ev/e/sbooks/leo/sbframetoc_ie.htm

Thank you. However, what I read there looked more like reading something 
about outlines. That looks (at first glance) like a better noweb that 
doesn't put much emphasis on the documentation part. :-(

When I want to read a literate program, I want to read something like 
Clifford has done in his cl-web.

OK, then I thought, well, it seems that one can use LEO on top of noweb 
files, ie, use LEO to see outlines of my noweb files. Well, so I tried.

Downloaded and installed LEO (not into /usr/local, since I don't easily 
let programs run as root, but into $HOME/LEO). I started it and had to 
get the debian package python-tk. Restart.

Then the first thing I tried was to import a noweb file. I used 
leo-4-4-3-alpha-2 on the following file (dont put the %--- line into the 
file but keep the final empty line.

%---BEGIN asfiles.pl.nw
<<*>>=
Here is the code
@

%---END asfile.pl.nw

LEO hangs itself up. I seem to be unlucky. Unfortunately, I am not a 
python programmer myself so that I could dig into the problem.

I now give up for the second time. The empty line at the end seems not 
the only problem.

I know that LEO has some good ideas, especially I like the cloning 
stuff, but I cannot appreciate LEO not only for the reason that it 
doesn't let me import my files.

1) In contrast to mmm-mode+font-lock in emacs, it doesn't highlight the 
code appropriately, (in particular Aldor and LaTeX is not supported and 
I don't know how to fix that).

2) The section names in the lower window are no hyperllinks. (OK, I 
don't have that in Emacs, but since in my current working style, I view 
a hyperlinked .dvi file with inverse search enabled, I would lose that 
if I switch to LEO.

3) I am not sure whether this is really true, but I have the impression 
that LEO likes *one* documentation + *one* code chunk per section. I 
felt like I am documenting code chunks.
The idea of writing for human beings is (personal opinion) a bit 
blurred. (Don't criticize me. I have not long enough tested LEO and I 
believe the "clone" idea is a good one.---So anyone who says something 
else is probably right.)



I don't think that I will change too quickly to LEO.

Sorry Bill, what are your experiences with LEO? Have you used it for a 
small project?

\start
Date: Tue, 15 May 2007 09:11:15 -0500
From: Tim Daly
To: Martin Rubey
Subject: Funding
Cc: Gabriel Dos Reis

Martin,

> the world does not only consist of the U.S.

True. But I believe you'll find the same response from FWF or INRIA.

I'd hope to be proven wrong. Do you have a counter-example that shows
that an open source project that is not government, company, or
university based has been funded? Can you tell me how they set up
their project to handle the grant?

Can I, as a U.S. national, propose research questions to FWF or INRIA?
The NSF requires that you have a social security number in order to
apply. Indeed, your social security number IS your userid.

Actually, I'd be delighted to see anyone in any country get research
funded that used Axiom. Axiom has nothing to do with the U.S. But I
naturally come in contact with my own country's funding organizations.
My only direct contact with INRIA was years ago while Axiom was still
"in the box" and I was still claiming that it would be freely released.



> all funds support "research"

I've discussed funding to support "provisos", to explore its application
to such ideas as:

  * an interval-based "such that" facility that would replace the
    global "assume" (my PhD thesis topic)
  * a means of naturally-parallel computation to take advantage of
    multicore architectures (passed on the SUN Microsystems)
  * a means of handling multiple branch-cut computations
  * a means of handling variable-precision variables based on
    stream-based provisos

I've asked for funding to support "indefinites" to answer the question

  * if M is a matrix and n is an unknown, what is the symbolic matrix
    entry M_{i,j} of the matrix M^n
  
I've discussed funding to support the application of ACL2 to 
proving the algorithms in the Axiom algebraic hierarchy correct.

I've asked for NIST funding to support the Computer Algebra Test Suite
(CATS), which is a symbolic form of the numeric standards. Indeed, at
this time the CATS effort most naturally fits into the SAGE framework.




These are some of the topics that have not gotten any traction
in an open source framework. I was one of the principle investigators
on an NSF grant for the "indefinites" idea but that was funded thru
the university, not thru open source Axiom. So I'm intimately familiar
with the grant requirements.

Any one of these topics would represent fundamental research.

I still maintain that no governmental funding organization in any
country will accept a grant proposal from a project that is not
connected to a "funding source", that is, not connected to a company
or a university. SAGE is embedded in a university as is (was?) MuPad.
The 100-ish open source algebra projects I collected for the Rosetta
project were all university based.

It is not the lack of fundamental research questions which limits
funding. Provisos, Indefinites, ACL2-Axiom proofs, etc are fundamental
research questions.



There is the hope that some company might fund an open source project
with a grant. IBM, the company that fathered Axiom might be a natural
source. I have not explored this funding idea.

Alternatively RISC might be able to handle the money for grant funding
and use it to "subgrant" to Axiom. I have not explored this funding idea.


\start
Date: Tue, 15 May 2007 16:25:04 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Funding
Cc: Gabriel Dos Reis

> Alternatively RISC might be able to handle the money for grant funding
> and use it to "subgrant" to Axiom. I have not explored this funding idea.

I am not sure that I understand this. Organisational, RISC is an 
ordinary university institute.

\start
Date: Tue, 15 May 2007 09:28:07 -0500
From: Tim Daly
To: Dustin Long
Subject: canvas tag

(note: copied to the axiom mailing list)

Dustin,

>>Dustin,
>>
>> Can you write into a <canvas> tag?
>>
>> The Axiom project <wiki.axiom-developer.org> is planning to replace the
>> help browser and graphics with a standard firefox front end. Axiom is
>> written in common lisp.
>
> Hello Tim,
>
> At the moment, Kamen Lisp has an artificial limit on dom function calls:
> only functionss of one argument are allowed. Removing this restriction
> shouldn't be difficult; I just haven't been able to get around to doing
> it. Once that's complete, I don't see why using <canvas> wouldn't be
> possible. I'll be sure to add it to my list of things to test out.
>
> Dustin

Kamen Lisp is of great interest to me as I could dynamically create
lisp code and force it out to web pages. This would be useful for 
creating all kinds of ideas in an Axiom front end.

Is your project open source? How is it licensed?  Axiom uses the
Modified BSD license which basically allows anyone to do whatever they
wish with the code.

\start
Date: Tue, 15 May 2007 09:43:02 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Funding
Cc: Gabriel Dos Reis

>> Alternatively RISC might be able to handle the money for grant funding
> and use it to "subgrant" to Axiom. I have not explored this funding idea.
>
> I am not sure that i understand this. Organisational, RISC is an 
> ordinary university institute

Years ago I got together with Bruno Buchberger and he gave me a tour
of the facilities. My understanding was that RISC was a separate
institute set up as a consortium arrangement based on industry
funding. I don't recall the details. Clearly I misunderstood and
clearly I'm wrong. Thanks for the correction.

\start
Date: Tue, 15 May 2007 12:14:02 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Literate documentation

On May 15, 2007 9:48 AM Ralf Hemmecke wrote:
> 
> > It's not a movie but you might want to try:
> > 
> > http://www.3dtree.com/ev/e/sbooks/leo/sbframetoc_ie.htm
> 
> Thank you. However, what I read there looked more like 
> reading something about outlines. That looks (at first glance)
> like a better noweb that doesn't put much emphasis on the
> documentation part. :-(

Yes, there are other documents at the main Leo web site that
cover other topics in more detail. See "Beginners Guide" and
"Users Guide" at

http://webpages.charter.net/edreamleo/front.html

> ...
> Downloaded and installed LEO (not into /usr/local, since I 
> don't easily let programs run as root, but into $HOME/LEO).
> I started it and had to get the debian package python-tk.
> Restart.

Good.

> 
> Then the first thing I tried was to import a noweb file.
> I used leo-4-4-3-alpha-2 on the following file (dont put the
> %--- line into the file but keep the final empty line.
> 
> %---BEGIN asfiles.pl.nw
> <<*>>=
> Here is the code
> @
> 
> %---END asfile.pl.nw
> 
> LEO hangs itself up. I seem to be unlucky. Unfortunately, I am
> not a python programmer myself so that I could dig into the
> problem.
> 

You must have been feeling "lucky" when you tried this but I am
not too surprised by the result.

When you download something you should keep in mind that "alpha"
usually means that it is a new test version that is likely to
have problems. If it was your intention to test this pre-release
then I suppose that you should send a bug report to the Leo
developers. I had an older version of Leo on my system from about
a year ago and it worked fine. But just for "fun" I downloaded
the current alpha release and tried you example again. I can
confirm that it does indeed hang Leo. In fact this test version
of Leo is not even able to read it's own exported noweb files.

So then I removed leo-4-4-3-alpha-2 and installed leo-4-4-2-1-
final Your example works fine for me using this last stable
release of Leo.

> I now give up for the second time. The empty line at the end 
> seems not the only problem.

If you like I can send the bug report to to th leo-developers
email list.

> 
> I know that LEO has some good ideas, especially I like the
> cloning stuff, but I cannot appreciate LEO not only for the
> reason that it doesn't let me import my files.

Let's not give up so easily. :-) If you are sufficiently
motivated to give Leo a serious try with Axiom, I am willing
to work with you (and anyone else) to see how far we can get.

> 
> 1) In contrast to mmm-mode+font-lock in emacs, it doesn't 
> highlight the code appropriately, (in particular Aldor and
> LaTeX is not supported and I don't know how to fix that).

I believe that the language awareness is configurable.

> 
> 2) The section names in the lower window are no hyperllinks.
> (OK, I don't have that in Emacs, but since in my current
> working style, I view a hyperlinked .dvi file with inverse
> search enabled, I would lose that if I switch to LEO.

That might be a nice feature to request.

> 
> 3) I am not sure whether this is really true, but I have the
> impression that LEO likes *one* documentation + *one* code
> chunk per section. I felt like I am documenting code chunks.

No, I don't think that is true.

> The idea of writing for human beings is (personal opinion)
> a bit blurred. (Don't criticize me. I have not long enough
> tested LEO and I believe the "clone" idea is a good one.---
> So anyone who says something else is probably right.)
> 

No problem. I think "first impressions" are very important.

> 
> I don't think that I will change too quickly to LEO.
> 

I have to admit that most users of Leo admit that learning to
use Leo effectively required some additional effort, but they
almost all agree that the effort is worth it.

> Sorry Bill, what are your experiences with LEO? Have you
> used it for a small project?
> 

I little more than a year ago I did try importing some Axiom
pamphlet files into Leo. I confirmed what I could do easily
based on the tutorials but I have not actually completed any
project using Leo yet.

What do you say? Are you willing to give it a try with Axiom?

\start
Date: Tue, 15 May 2007 19:49:30 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Literate documentation

>> I used leo-4-4-3-alpha-2

>> LEO hangs itself up. I seem to be unlucky.

> You must have been feeling "lucky" when you tried this but I am
> not too surprised by the result.

> When you download something you should keep in mind that "alpha"
> usually means that it is a new test version that is likely to
> have problems.

Yes, of course. But it seemed a bit odd that developers don't have a 
good test bed to cover such simple cases. (How many developers are 
there, by the way?)

>> I now give up for the second time. The empty line at the end 
>> seems not the only problem.

> If you like I can send the bug report to to th leo-developers
> email list.

Please do. Thanks.

>> I know that LEO has some good ideas, especially I like the
>> cloning stuff, but I cannot appreciate LEO not only for the
>> reason that it doesn't let me import my files.

> Let's not give up so easily. :-) If you are sufficiently
> motivated to give Leo a serious try with Axiom, I am willing
> to work with you (and anyone else) to see how far we can get.

All this bad experience today doesn't turn me completely away from LEO.
I am still in the evaluation phase and reading on without starting LEO.
At the moment I trie to find out whether I can put LEO on top of my 
current ALLPROSE machinery.

What I actually want to have is something as flexible as emacs and an 
IDE as eclipse and an outline (LP) support as LEO and good in 
typesetting as TeX or TeXmacs.
Unfortunately there are too many different languages involved to join 
all the efforts.

Why is nobody investigating how to make a eclipse plugin that supports 
LP and outlining etc? It seem the industry is not much interested in
LP.

>> 1) In contrast to mmm-mode+font-lock in emacs, it doesn't 
>> highlight the code appropriately, (in particular Aldor and
>> LaTeX is not supported and I don't know how to fix that).

> I believe that the language awareness is configurable.

Of course. But until I am able to program something reasonable in 
python, I tend to keep the good stuff I have.
Oh, I've seen that there is an (x)emacs plugin. I haven't yet figured 
out how to start it. Maybe I should download the last stable version.

>> The idea of writing for human beings is (personal opinion)
>> a bit blurred. (Don't criticize me. I have not long enough
>> tested LEO and I believe the "clone" idea is a good one.---
>> So anyone who says something else is probably right.)

> No problem. I think "first impressions" are very important.

Yes. And for psychology tells that it is hard to change the "first 
impression".

>> I don't think that I will change too quickly to LEO.

> What do you say? Are you willing to give it a try with Axiom?

Surely, yes. But what I am looking for is an IDE that supports writing 
libraries for axiom. I actually want to implement mathematics myself 
rather than spending my time on evaluation/implementing the right tools.
But excuse if I will not find much time for LEO in the next weeks.

 > I little more than a year ago I did try importing some Axiom
 > pamphlet files into Leo. I confirmed what I could do easily
 > based on the tutorials but I have not actually completed any
 > project using Leo yet.

Ah perhaps you still can help me with a few things.
LEO's file format is .leo. From that it can tangle code files.
I have the impression noweb is not involved in this process, since also 
the input language and semantics as small differences.
What is LEO's actual realtion to noweb? Can I weave to a .nw file or 
tangle to get a .nw file. I still haven't come across that information.

\start
Date: Tue, 15 May 2007 15:13:25 -0400
From: Bill Page
To: Tim Daly
Subject: RE: Literate documentation

Tim,

On May 14, 2007 5:52 PM you wrote:
> 
> Thanks for the pointers.
> 

Here is another literate progamming project published in the
form of a book:

The Haskell Road to Logic, Maths and Programming

by Kees Doets and Jan van Eijck

"The programs in this book have all been tested with Hugs98,
the version of Hugs that implements the Haskell 98 standard.
The full source code of all programs is integrated in the book;
in fact, each chapter can be viewed as a literate program
[Knu92] in Haskell. The source code of all programs discussed
in the text can be found on the website devoted to this book,
at address http://www.cwi.nl/~jve/HR

> The key reason Leo does not attract me is that I live in
> emacs.  However, I will download it and try it.
> 

Great. Xemacs is integrated into Leo as an external editor
plug-in. Let me know if you think I can help.

\start
Date: Tue, 15 May 2007 15:32:57 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Literate documentation

Ralf,

On May 15, 2007 1:50 PM you wrote:
> 
> Yes, of course. But it seemed a bit odd that developers don't
> have a good test bed to cover such simple cases. (How many
> developers are there, by the way?)

This is open source development, remember. It is not always
organized in the optimal way.

At http://sourceforge.net/projects/leo it shows 15 registered
developers.

> 
> What I actually want to have is something as flexible as emacs
> and an IDE as eclipse and an outline (LP) support as LEO and
> good in typesetting as TeX or TeXmacs. Unfortunately there are
> too many different languages involved to join all the efforts.

I think it is possible. For example Leo has a plug-in to allow
Xemacs as an external editor and I have seen examples of the use
of LaTeX code in Leo.

> 
> Why is nobody investigating how to make a eclipse plugin that 
> supports LP and outlining etc? It seem the industry is not
> much interested in LP.


I think there is some interest in this. See:

Literate Formal Software Development with Eclipse
http://www.informatik.uni-bremen.de/~cxl/eig/index.html
also
http://www.soe.ucsc.edu/~charlie/projects/litprog/ibmEclipse.txt

> 
> >> 1) In contrast to mmm-mode+font-lock in emacs, it doesn't 
> >> highlight the code appropriately, (in particular Aldor and
> >> LaTeX is not supported and I don't know how to fix that).
> 
> > I believe that the language awareness is configurable.
> 
> Of course. But until I am able to program something reasonable
> in python, I tend to keep the good stuff I have.

Python is a very easy language to learn.

> Oh, I've seen that there is an (x)emacs plugin. I haven't yet
> figured out how to start it. Maybe I should download the last
> stable version.
> 

Well, ya... ;-)

Please let me know if you have any problems.

> 
> > No problem. I think "first impressions" are very important.
> 
> Yes. And for psychology tells that it is hard to change the
> "first impression".
> 

True. I expect many people have such "first impressions" of
Axiom and Aldor too...

> ... 
> Ah perhaps you still can help me with a few things. LEO's
> file format is .leo. From that it can tangle code files.
> I have the impression noweb is not involved in this process, 
> since also the input language and semantics as small
> differences. What is LEO's actual realtion to noweb? Can
> I weave to a .nw file or tangle to get a .nw file. I still
> haven't come across that information.
> 

I believe noweb is first of all an external format for Leo.
To get a noweb file from Leo you use export. Leo does however
implement some things that seem motivated by noweb.

\start
Date: Tue, 15 May 2007 21:40:04 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: Literate documentation

>> The key reason Leo does not attract me is that I live in
>> emacs.  However, I will download it and try it.

> Great. Xemacs is integrated into Leo as an external editor
> plug-in. Let me know if you think I can help.

Hi Bill, hi Tim,

please open LeoPy.leo in LEO. That is supposed to be the sources of LEO 
itself.  When I first read documentation about LEO several months ago I 
had that impression and what I see in LeoPy.leo is just what I feared.

Leo supports outlining, but not literate programming (at least not as I 
want to understand it).

I cannot simply take LeoPy.leo, start at the first section and read my 
way through the code, ehm documentation.

Just look at the top-level outline:

+ Buttons, commands & scripts
+ Notes
+ Projects
+ To do
+ Code

That doesn't make an article nor a book.

The thing I want to see first is documentation. LP is description of 
ideas and backgrounds, proofs, etc. that is supported by running code. 
LEO seems to focus the other way round (program text with comments). 
((Oh, I still haven't read enough. You can convince me otherwise.))

But if Axiom code ends looking like that what LeoPy.leo presents, then 
LEO gets a clear *no* from me.

\start
Date: Tue, 15 May 2007 21:59:58 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Literate documentation

>>> No problem. I think "first impressions" are very important.
>> Yes. And for psychology tells that it is hard to change the
>> "first impression".

> True. I expect many people have such "first impressions" of
> Axiom and Aldor too...

How true. That is why I try to tell people not to take psychological 
laws to serious. ;-) (I hope my wife isn't reading this. *smile*)

> I believe noweb is first of all an external format for Leo.
> To get a noweb file from Leo you use export.

That probably explains a lot of my previous mail.
Leo (Literate Editor with Outlines) should better be called "eo". That 
wouldn't confuse me so much.

 > Leo does however implement some things that seem motivated by noweb.

Yes, yes. Maybe I should further explore LEO's usefulness.

\start
Date: Tue, 15 May 2007 13:57:56 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke, Bill Page
Subject: re: Literate documentation

--- Ralf Hemmecke wrote:

> Leo supports outlining, but not literate programming (at least not as
> I want to understand it).

That was also my impression, that the "fuzzy" aspects of writing for
human comprehension didn't map well to the leo paradigm.  I had assumed
that I simply wasn't "getting" it...

> The thing I want to see first is documentation. LP is description of 
> ideas and backgrounds, proofs, etc. that is supported by running
> code. 

I agree - that's a natural consequence of focusing on writing for human
comprehension.

> LEO seems to focus the other way round (program text with comments). 
> ((Oh, I still haven't read enough. You can convince me otherwise.))

I also had that impression.  That's why I was hoping for a "paper in
Leo" example somewhere.
 
I am curious about a small, new lisp editor called Able
http://phil.nullable.eu/ and whether it could be taught to do what we
need for Axiom.  Unfortunately it's GPL which can be tricky in Lisp...

\start
Date: Tue, 15 May 2007 23:21:12 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: re: Literate documentation

> I am curious about a small, new lisp editor called Able
> http://phil.nullable.eu/ and whether it could be taught to do what we
> need for Axiom.  Unfortunately it's GPL which can be tricky in Lisp...

I don't know why you fear GPL all the time.

Suppose somebody combines Axiom with GPL code so that the Axiom license 
has to become GPL (not a bad idea anyway). What would that change for 
you? Don't you then have access to the sources anymore, can't you 
redistribute it. What is the problem? The problem would only be for 
those people who want to earn money with Axiom. Our goal is to keep 
Axiom free and openly accessible. I don't see why GPL would contradict that.

I know that mail should not live in axiom-developer, so if somebody 
feels need to reply just remove the developer mailing list.

Another question is why do you believe that I would consider a LISP IDE 
if I want to program in Axiom? If you had written Aldor or SPAD++ IDE 
that would count, but still only half interesting, since we need a 
LP-aware IDE.

\start
Date: Tue, 15 May 2007 14:45:17 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: re: Literate documentation

> Another question is why do you believe that I would consider a LISP
> IDE if I want to program in Axiom? If you had written Aldor or
> SPAD++ IDE that would count, but still only half interesting, since
> we need a LP-aware IDE.

ABLE is currently a Lisp editor, true.  I am interested not in what it
can do now but what it might be able to do.  Emacs has a huge amount of
code that we have no direct use for and a limitation with syntax
highlighting that makes a robust literate programming a bit tricky.  I
would like to experiment with some ideas concerning literate
programming editors and ABLE could be a flexible environment in which
to experiment.

So no, I don't expect you to consider a LISP IDE or even a SPAD++ IDE
for Axiom programming.  I want to explore the possibility of creating
the editor that we would want for Axiom, which would likely combine a
Lisp IDE, a SPAD++ IDE, and literate programming.

\start
Date: Tue, 15 May 2007 22:18:05 -0500
From: Tim Daly
To: list
Subject: lispdoc

for those of you who like to use emacs there is a facility 
available to look up online lisp documentation. it searches
the common lisp hyperspec (the ansi docs) and several key
common lisp books. it presents the definition and example
code from the books Practical Common Lisp, PAIP, ANSI Common
Lisp and some ASDF installable libraries.

the key binding is "C-c l" (Control-C l)

since all it really does is create an http URL it would
be possible to do the same with axiom documentation.

see <http://planet.lisp.org>

\start
Date: Wed, 16 May 2007 11:04:29 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: lispdoc

see <http://planet.lisp.org>

I think that won't help me much. But could someone tell me about a few 
conventions used in naming identifiers.

I already know that |blah| keeps blah from being capitalized, but are 
the bars part of the identifier?

When do people use identifiers that are surrounded by *, for example
*default-pathname-defaults*.

What about a colon in front of an identifier? For example,
(array-element-type (make-array 10 :element-type 'character))

If you have a link to such a conventions page that would help me a bit 
being able to understand 0.1% more of the lisp code that is floating 
around here.

\start
Date: 16 May 2007 11:20:08 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: lispdoc

Ralf Hemmecke writes:

> see <http://planet.lisp.org>
> 
> I think that won't help me much. But could someone tell me about a few
> conventions used in naming identifiers.
> 
> I already know that |blah| keeps blah from being capitalized, but are the bars
> part of the identifier?

no.

> When do people use identifiers that are surrounded by *, for example
> *default-pathname-defaults*.

*this-is-a-special-variable*

The stars are only a convention, as you noticed already.

A special variable is dynamically scoped - as opposed to the usual lexical
scoping in lisp.  It is introduced via (defvar *this-is-a-special-variable*)

Think of a special variable as a global variable.

> What about a colon in front of an identifier? For example,
> (array-element-type (make-array 10 :element-type 'character))

As far as I know this is also a convention, namely for keyword arguments.

\start
Date: Wed, 16 May 2007 12:18:44 +0200
From: Kai Kaminski
To: Martin Rubey
Subject: Re: lispdoc
Cc: Ralf Hemmecke

On May 16, 2007, at 11:20 AM, Martin Rubey wrote:

> Ralf Hemmecke writes:
>
>> see <http://planet.lisp.org>
>>
>> I think that won't help me much. But could someone tell me about a  
>> few
>> conventions used in naming identifiers.
A quick overview of the common conventions (and some not so common  
ones) can be found at http://www.cliki.net/Naming%20conventions.

>> I already know that |blah| keeps blah from being capitalized, but  
>> are the bars
>> part of the identifier?
>
> no.
>
>> When do people use identifiers that are surrounded by *, for example
>> *default-pathname-defaults*.
>
> *this-is-a-special-variable*
>
> The stars are only a convention, as you noticed already.
>
> A special variable is dynamically scoped - as opposed to the usual  
> lexical
> scoping in lisp.  It is introduced via (defvar *this-is-a-special- 
> variable*)
Or (defparameter *foo* ...). There is a subtle difference, which you  
probably don't care for, unless you develop your Lisp in an  
interactive way, which is somewhat difficult with the Axiom sources.

> Think of a special variable as a global variable.
>
>> What about a colon in front of an identifier? For example,
>> (array-element-type (make-array 10 :element-type 'character))
>
> As far as I know this is also a convention, namely for keyword  
> arguments.
This isn't quite correct. A symbol that starts with a colon is always  
interned in the KEYWORD package, rather than the current package.  
Keyword symbols are used for keyword arguments in functions:

(defun foo (bar &key baz (bam 3))
   ...)

(foo 3 :bam 7 :baz 9)

You couldn't write (foo 3 bam 7 baz 9) instead, hence it is not a  
convention in this case.

Keyword symbols are also often used (this is by convention) for  
things like

(defun find-extremum (list max-or-min)
   ...)

(find-extremum '(1 2 3 4 5) :max)

Finally keyword symbols are often used in DSLs, like this example  
from cl-who (http://weitz.de/cl-who/):

(with-html-output (*http-stream*)
   (:html
     (:head (:title "My Homepage"))
     (:body (:h1 "hello world"))))

\start
Date: Wed, 16 May 2007 10:09:05 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: lispdoc

Ralf,

The vertical bars are escape characters and are not part of the identifier,
thus |foo| is the identifier foo. The lisp reader capitalizes all input
by default so there is no difference between foo, Foo, or FOO.
This is rarely used (except that boot wants to be dual-cased).



The * around identifiers is purely a convention. They indicate (but
do not require) that the symbol is globally visible rather than 
something locally defined. That way you can tell if you're 
manipulating something globally without checking the locally
defined variables. Thus *asdf* is "global" by convention, not by
definition. Axiom used a "$asdf" convention.



The : in front of the identifier means that this symbol is in 
a special "package". Packages are collections of names and every
name in lisp is in a package. Thus most names in Axiom are in the
boot package and the full name of an identifier foo is boot::foo.
There is a special package called the "keyword" package which
can be seen everywhere. The notation for a symbol in the keyword
package is :foo



Think of a symbol in common lisp as a C struct. It has 5 parts:
  { package   ; the package containing this symbol
    name      ; a string that is the print name
    value     ; the meaning of foo in a value position (myfunc foo)
    function  ; the meaning of foo in the function position (foo....)
    plist     ; a list of (key value key value .....)
  }

You can see this by:
(setq foo 5)                 <== set the symbol-value, name, and package
(defun foo () "hello world") <== set the symbol-function
(setf (get 'foo 'barry) 7)   <== add (barry 7) to the property list

(symbol-package 'foo)  ==> #<PACKAGE COMMON-LISP-USER>
(symbol-value 'foo)    ==> 5
(symbol-function 'foo) ==> #<FUNCTION FOO NIL (defun foo () "hello world")>
(symbol-name 'foo)     ==> "FOO"
(symbol-plist 'foo)    ==> (barry 7 ..... )

Every symbol has these 5 parts. If the current package is the same
as the package field of the symbol then you just use the symbol name.

\start
Date: Wed, 16 May 2007 21:01:23 +0200
From: Ralf Hemmecke
To: list
Subject: ProofGeneral

Could someone have a look at
http://proofgeneral.inf.ed.ac.uk/kit

Eclipse-Plugin at:
http://proofgeneral.inf.ed.ac.uk/eclipse

Bill, that is from the answer of Christoph L=FCth whom I asked about the =

project http://www.informatik.uni-bremen.de/~cxl/eig/index.html.
You sent me that that link recently in connection with literate
programming in eclipse.

I currently have no time. Is there some stuff in this plugin that is
connected with literate programming?

\start
Date: Wed, 16 May 2007 17:40:08 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re: ProofGeneral

Quoting Ralf Hemmecke:

> Could someone have a look at
> http://proofgeneral.inf.ed.ac.uk/kit
>
> Eclipse-Plugin at:
> http://proofgeneral.inf.ed.ac.uk/eclipse
>
> Bill, that is from the answer of Christoph L=C3=BCth whom I asked about
> the project http://www.informatik.uni-bremen.de/~cxl/eig/index.html. 
> You sent me that that link recently in connection with literate
> programming in eclipse. 
>
> I currently have no time. Is there some stuff in this plugin that is
> connected with literate programming?
>

Short answer: Yes. But my ultimate conclusion is that this is not
something new for us. 

As a starting point I read the document:

   Assisted Proof Document Authoring. 
   by David Aspinall, Christoph L=C3=BCth  and Burkhart Wolff. 

at http://proofgeneral.inf.ed.ac.uk/Kit/docs/pgauthor.pdf

I think it is clear that the "document-centric" approach advocated by
the authors of this paper for creating human-readable large-scale proofs
using automated theorem provers (e.g. the famous proof of the 4-color
theorem) is very similar to the type of interaction that we have envisaged
for the interaction of mathematicians with computer algebra systems. 
It is essentially the same problem. This does have some things in
common with what is conventionally known as literate programming,
hence "literate theorem proving" and "literate computer algebra", etc. 
but this is not a new paradigm for literate programming. 

I found the discussion of "backflow" also very relevant to the way we
hope to use computer algebra. Backflow is the substitution of output
generated by an external system back into the actual literate document. 
The result is then woven (in the sense of literate programming) into a
LaTeX file and rendered as PDF.  Exactly this is possible now on the
Axiom Wiki when using the interface to Sage. See for example:

http://wiki.axiom-developer.org/SandBoxSageAxiomInterface
http://wiki.axiom-developer.org/SandBoxSagePamphlet

Something very similar to this also an integral part of the Axiom Wiki
website at a deeper level since it directly supports "backflow" from the
Axiom Interpreter, the Aldor, Spad, Boot and Lisp compilers (in the
context of Axiom) as well as Reduce and Maxima into a the contents
of a wiki page. In MathAction such code chunks are delimited by
LaTeX pseudo-environment markers like:

   \begin{axiom}
   integrate(sin(x)*cos(x),x)
   \end{axiom}

Thus the Axiom Wiki (or more generally, the MathAction extension
of ZWiki) is already a "literate" environment for the use of computer
algebra in this sense. 

In principle I think it would be quite easy to develop plug-ins for both
emacs and eclipse based on the example of Proof General. 

\start
Date: Thu, 17 May 2007 10:01:05 +1000
From: Alasdair McAndrew
To: list
Subject: Learning Axiom (Literate programming, LaTeX etc)

------=_Part_51722_4445466.1179360065292

I have been following the discussions with some interest, as I am slowly and
tentatively dipping my toes into Axiom.

First, I believe strongly that LaTeX is the best tool for the publication of
mathematics.  In fact, the best documentation for any CAS that I've seen was
the Hyperdvi material which accompanied MuPAD (before it went commercial).
This had the advantages of being lovely to look at, as well as being
cross-platform.  As well there was plenty of ASCII documentation to use from
a terminal.  HyperDoc is good, but there is a lot missing, in particular
examples for every command.  And it's not cross-platform.

One of the problems in learning Axiom is that it seems more "difficult" than
other CAS's, and there's no elementary beginners guide.  There are the
books, yes, and wonderful they are, but nobody seems to have produced a
smaller "getting started" document, such as exists for every other CAS.  I
have programmed in Maple, Mathematica, MuPAD, Maxima, as well as with Matlab
and Scilab, and to a certain degree they are all very similar.   So it's
just a matter of minor syntactical differences moving from one to the
other.  Axiom gives the impression of being the domain of the few, rather
than a workhorse for the many.   This impression is not lessened by reading
that Axiom aims to be the "best" CAS in terms of its algorithms and
implementation.  This seems to imply that plonkers like me, who are happy if
a program just works, should keep away from trying to write code in Axiom.

There also doesn't seem to be a repository of programs developed by other
users, a "share" directory, if you like, both for seeing examples of Axiom
programs, and also to see what's also been developed.

\start
Date: 16 May 2007 19:09:51 -0500
From: Gabriel Dos Reis
To: Alasdair McAndrew
Subject: Re: Learning Axiom (Literate programming, LaTeX etc)

Alasdair McAndrew writes:

[...]

| There also doesn't seem to be a repository of programs developed by other
| users, a "share" directory, if you like, both for seeing examples of Axiom
| programs, and also to see what's also been developed.

I would think that the directory src/algebra is such a "share" directory.

\start
Date: Wed, 16 May 2007 21:06:48 -0400
From: Bill Page
To: Alasdair McAndrew
Subject: Re: Learning Axiom (Literate programming, LaTeX etc)

Quoting Alasdair McAndrew:

> ... 
> One of the problems in learning Axiom is that it seems more
> "difficult" than other CAS's, and there's no elementary beginners
> guide.  There are the books, yes, and wonderful they are, but
> nobody seems to have produced a smaller "getting started"
> document, such as exists for every other CAS. 

I presume that you have visited:

http://wiki.axiom-developer.org/AxiomTutorial

Have you read the introduction to Axiom by Martin N. Dunstan at:

http://www.dcs.st-andrews.ac.uk/~mnd/documentation/axiom_tutorial

I believe that it starts at a fairly basic level. 

> I have programmed in Maple, Mathematica, MuPAD, Maxima, as
> well as with Matlab and Scilab, and to a certain degree they are
> all very similar.   So it's just a matter of minor syntactical differences
> moving from one to the other. 

Well, Axiom *is* different. It is certainly not "just a matter of minor
syntactical differences". In some respects Axiom is most like MuPad
(depending on how you use MuPad). Some of the internal design of
MuPad was influenced directly by Axiom, specifically it's concept of
domains (types) and categories. 

> Axiom gives the impression of being the domain of the few,
> rather than a workhorse for the many. 

At this point in time I believe that that is a fairly accurate impression. 
:-( But there once was a time ... back in the early days at IBM and
largely before Maple, Mathematica and MuPad, when Axiom was
definitely in a lead position. I believe that the reasons things are
different now has more to do with how personalities, politics and
business decisions affect scientific research than any inherent
deficiency in Axiom's design. 

> This impression is not lessened by reading that Axiom aims to be
> the "best" CAS in terms of its algorithms and implementation.  This
> seems to imply that plonkers like me, who are happy if a program
> just works, should keep away from trying to write code in Axiom. 

Don't worry, that is just a "motherhood" statement of goals. :-) The truth
is rather different. Certainly Axiom does aim to provide the foundation
on which to build a truly comprehensive mathematical library based on
rigorous and often abstract mathematical concepts. The extent to which
it does this might still be considered very close to the "state of the art"
in spite of it's age. I think this says more about the difficulty of obtaining
this goal than it does about Axiom. 

> There also doesn't seem to be a repository of programs developed
> by other users, a "share" directory, if you like, both for seeing
> examples of Axiom programs, and also to see what's also been
> developed. 

There are some listed at:

http://wiki.axiom-developer.org/AxiomContributions

but it is not complete nor is it necessarily representative of the way most
people use Axiom. 

We are looking for people like you with experience in other CAS who are
willing to explore Axiom and compare and contrast it to other systems. 
Your input is important to the process of creating the documentation for
Axiom that you feel is currently missing as well as identifying things that
are unclear or incompletely described. I hope it will be possible for you
to contribute to this effort while you learn Axiom. 

If you have questions about Axiom, there a many people on this list
who are willing to help. 

\start
Date: Wed, 16 May 2007 18:14:46 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: cl-web v0.8

I believe I have gotten line number output working, although perhaps
not quite in the format needed for some uses.

Compare the two outputs from the following:

* (use-package :cl-web)

T
* (tangle "./cl-web-v0.8.lisp.pamphlet" "test1.lisp")

NIL
* (setf *cl-web-print-linenum* t)

T
* (tangle "./cl-web-v0.8.lisp.pamphlet" "test2.lisp")

Other output strings can easily be generated with minor tweaking.

Tarball here:

http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.8.tar.gz

PDF here:

http://portal.axiom-developer.org/Members/starseeker/cl-web-v0.8.lisp.pdf

\start
Date: 17 May 2007 10:22:41 +0200
From: Martin Rubey
To: Alasdair McAndrew
Subject: Re: Learning Axiom (Literate programming, LaTeX etc)
Cc: 

Bill Page writes:

> Some of the internal design of MuPad was influenced directly by Axiom,
> specifically it's concept of domains (types) and categories.

"influenced" should be replaced by "copied".

> > This impression is not lessened by reading that Axiom aims to be the "best"
> > CAS in terms of its algorithms and implementation.  This seems to imply
> > that plonkers like me, who are happy if a program just works, should keep
> > away from trying to write code in Axiom.

Definitively *not*!  Everybody with some math knowledge can contribute to
axiom.  And writing code in Axiom occurs in several layers:

Tutorials

  HyperDoc has the concept of "examples" for a group of packages or domains.
  Unfortunately, this is not done currently for all of them.  You can get a
  list of domains for which Tutorials exist by clicking on Examples and then
  Domains in HyperDoc.  You can get a list of all domains by clicking on Browse
  and then Domains. (without typing anything into the field).

  Examples per operation should be added to the docstrings of the individual
  operations.

  Currently only a tiny subset of LaTeX works, but as I have shown on
  SandBoxHyperDocReplacement, prospects are very good for having a HyperDoc
  replacement soon.


Documentation

  most of Axioms code is only very lightly documented, if at all.  It could be
  very useful, if well done, if you would start with catdef.spad.pamphlet and
  attreg.spad.pamphlet.  Only general mathematical knowledge is needed here,
  but I'm sure (in fact, I know) that you would discover some bugs and
  inconsistencies.

Design of categories 

  note that the concept of Category in Axiom has very little to do with
  mathematical category theory, rather, it is similar to a class in object
  oriented paradigm.

  To play this game, it is helpful to have a broad understanding of some
  mathematical domain.  My favorite project is to design (or in fact, write
  down) some categories capturing the hierarchies of solutions of recurrences
  and differential equations.  Another one would be the world of factoring,
  some number theory knowledge is needed here.  Yet another one, very pressing
  in fact, is to think about which categories support definite summation and
  products.

Implementation of domains and packages

  Code in the usual sense.  See the WishList for what's missing.  I do not know
  enough about your interests to give advice here.


> There also doesn't seem to be a repository of programs developed by other
> users, a "share" directory, if you like, both for seeing examples of Axiom
> programs, and also to see what's also been developed.

Take the union of Gabriel dos Reis' and Bill Page's answers:

the "share" directory is src/algebra

and the stuff in AxiomContributions some day might be integrated into
src/algebra.  For example, my guessing package moved already.

\start
Date: 17 May 2007 10:29:55 +0200
From: Martin Rubey
To: list
Subject: HyperDoc replacement

Dear all,

a while ago I implemented a rudimentary HyperDoc replacement.  To make it
better, I need some help:

* does anybody know how I can get the lists of attributes, uses, users,
  dependents, parents, children, descendents, etc. of constructors?

* did anybody try my stuff on MS Windows?  Success, failure?

\start
Date: Thu, 17 May 2007 17:02:58 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: FW: [leo - Help] RE: Importing noweb project

I recently posted some messages concerning Leo and Axiom to the
Leo developer forums at SourceForge:

https://sourceforge.net/forum/message.php?msg_id=4315078
https://sourceforge.net/forum/message.php?msg_id=4315027

Attached is a reply from Edward Ream, the developer of Leo. I am
planning to setup the kind of example that he requested, but I
would be glad for some help and discussion about this form the
Axiom developers.

Regards,
Bill Page.

-----Original Message-----
From: Nobody [mailto:nobody@projects.sourceforge.net]
      On Behalf Of SourceForge.net
Sent: May 17, 2007 4:19 PM
To: noreply@sourceforge.net
Subject: [leo - Help] RE: Importing noweb project


Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4318266
By: edream

> I have repeatedly advocated the use of Leo as an alternative to
> this traditional approach. Now some of the other Axiom developers
> might finally be listening...

Many thanks, Bill, for this letter.  Leo's noweb support could be a
lot better--Leo needs someone like you who is actually using both noweb
and Leo.  The present code is just 'made up': it kinda does the job,
but I would be happy to change any part of it to suit your needs.
Please do not assume that deep thought has gone into the present code
:-)

> When I try to import the Axiom noweb files into Leo I get "odd"
> results.
[snip]
> I do not see any @ignore directive in the root node following
> import of the noweb file. Nor do I see any generated @file,
> @root or other directives.

I don't remember why this is so, or even if there is a reason. Again,
I have no problem changing how this works.

I would like to suggest the following.  Please send me (or post on
Leo's wiki) a mockup of how you would like Leo to work with respect
to noweb.  Something like this:

- Example noweb source file (it can be as simple or detailed as
  you like)
- The proposed result of the import to noweb command.
- Any other proposals for how Leo could treat noweb more smoothly.

For example there are probably glitches in how Leo writes @file or
@thin trees containing 'real' noweb files.  It may be necessary for
Leo's write logic (in leoAtFile.py) to treat real noweb files a bit
differently from Leo's other noweb markup.  I don't propose such a
change lightly, but it may be worth doing. The designation of a 'real'
noweb file could be done on the basis of file extension or as the
result of something like an @noweb directive.

> Is it correct to assume that you use almost exclusively the
> SourceForge forums (such as this one) and not the email lists?

Correct.  Leo's wiki pages are also sometimes useful, especially for
large hunks of code.  I like to give people a heads up on the SF
forums when I do something on the wiki.

> I have other questions as well concerning customization of Leo's
> parsing and generation of comments in target source languages other
> than Java and C which I have not found answered in the Leo users
> guide or tutorials. But I will save that for another time.

Such questions are welcome.  Please start a new thread for them.

\start
Date: Thu, 17 May 2007 23:23:17 -0400
From: Cliff Yapp
To: list
Subject: MathEdit?

Has anyone looked at this?

MathEdit, A Browser-based Visual Mathematics Expression Editor
http://wme.cs.kent.edu/mathEdit_final.pdf
http://wme.cs.kent.edu/mathedit/

I wonder if this work would be of interest to Axiom?

\start
Date: Thu, 17 May 2007 23:57:54 -0500
From: Tim Daly
To: Cliff Yapp
Subject: mathEdit

I cannot reach that website or file.
Has anyone been successful?

\start
Date: Fri, 18 May 2007 15:58:07 +0200 (CEST)
From: Waldek Hebisch
To: Gregory Vanuxem
Subject: Re: sbcl port

Gregory Vanuxem wrote:
> Le lundi 14 mai 2007 ? 01:08 +0200, Waldek Hebisch a =E9crit
>
> [...]
>
> > 3) The reclos test do not finish, it looks that
> >
> > relativeApprox(squareDiff8,10**(-3))::Float
> >
> > line goes into infinite loop.
>
> Does
>
> )lis (gcd 8 most-negative-fixnum)
>
> return the gcd ?
>
> If not it's a bug in SBCL (x86_64). I reported it some
> times ago and didn't receive any response. Maybe another
> report with an example will help (I patch sb-kernel::two-arg-gcd each
> time I upgrade SBCL).
>

Thanks for info.  Yes, as of 1.0.4 declarations in two-arg-gcd are
blatantly wrong.  I must say that it is strange that the code works
at all (C compiler would immediatly punish them with non-working
code).  I also looked at SBCL CVS repository and the wrong code is
still there...

I remeber that you wrote about SBCL bug, but I supected that you
mean that SBCL miscompiles some parts of AXIOM -- build log suggests
that some routines are miscompiled.

After patching two-arg-gcd it seems that my private version passes
all tests (modulo missing writablep function and fake sockets).

\start
Date: Fri, 18 May 2007 09:27:40 -0700 (PDT)
From: Cliff Yapp
To: Waldek Hebisch, Gregory Vanuxem
Subject: Re: sbcl port

--- Waldek Hebisch wrote:

> Thanks for info.  Yes, as of 1.0.4 declarations in two-arg-gcd are
> blatantly wrong.  I must say that it is strange that the code works
> at all (C compiler would immediatly punish them with non-working
> code).  I also looked at SBCL CVS repository and the wrong code is
> still there...

Waldek, could you submit your patch to the sbcl devs?  An actual
working patch will be likely to catch their attention.
 
> I remeber that you wrote about SBCL bug, but I supected that you
> mean that SBCL miscompiles some parts of AXIOM -- build log suggests
> that some routines are miscompiled. 

Hmm.  Do you suspect more sbcl bugs?

\start
Date: Fri, 18 May 2007 19:49:46 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Literate documentation

> I believe noweb is first of all an external format for Leo.
> To get a noweb file from Leo you use export. Leo does however
> implement some things that seem motivated by noweb.

Hi Bill,

I've just stumbled over the following section in LEO's User Guide.

How Leo Changes the Notion of Literate Programming
==================================================
Leo changes the theory and practice of literate programming as follows:

1. *Leo reduces the need for comments.* In particular, bridge or 
transition phrases are almost always unnecessary in a Leo outline. One 
never needs to say something like, "having just finished with topic x, 
we turn now to topic y." Leo's outlines tend to be far less chatty than 
flat literate programs.

2. *Leo reduces the need for printed listings.* Experience with the 
Weave command shows that an outline can easily become unintelligible 
when printed, no matter how "beautiful" the typeset printout is. No 
printed listing can be as clear as Leo's outline view.

3. *Leo reduces the need for indices and tables of contents.* You could 
say the entire outline is a table of contents. Moreover, sections must 
always be defined in a descendant of the node containing the section 
reference, so there is very little need for an index.

4. *Leo shows that outline structure is more powerful than narrative.* 
Indeed, narrative style creates severe maintenance problems. The 
narrative is soon forgotten, and when that happens it becomes difficult 
to find anything. The few times I have tried narrative organization I 
soon regretted it: things just weren't where I expected them to be.

5. *Leo shows that traditional literate programming encourages a too 
creative approach to programming.* A dictionary is a better model for 
programs than a novel. Leo's outlines provide a more regular 
organization, while providing space for the most lengthy discussions 
when those discussions are required.



In particular, if I read (4) I come to the conclusion that using LEO 
might rather be counterproductive to our pamphlet idea.

The declared goal in Axiom is to write documentation that is readable by 
humans. I am not an experienced LEO user, but all I see does convince me 
to use LEO in order to produce an article+code about some mathematical idea.

LEO is, in my eyes, very code focused. Am I wrong?

\start
Date: Fri, 18 May 2007 18:12:43 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Literate documentation

Ralf,

On May 18, 2007 1:50 PM you wrote:
> 
> I've just stumbled over the following section in LEO's User
> Guide.

Yes, I was going to specifically recommend that you read this
section.

> 
> How Leo Changes the Notion of Literate Programming
> ==================================================
> Leo changes the theory and practice of literate programming 
> as follows:
> 
> 1. *Leo reduces the need for comments.* In particular, bridge
> or transition phrases are almost always unnecessary in a Leo 
> outline. One never needs to say something like, "having just
> finished with topic x, we turn now to topic y." Leo's outlines
> tend to be far less chatty than flat literate programs.
> 
> 2. *Leo reduces the need for printed listings.* Experience with
> the Weave command shows that an outline can easily become
> unintelligible when printed, no matter how "beautiful" the
> typeset printout is. No printed listing can be as clear as
> Leo's outline view.
> 
> 3. *Leo reduces the need for indices and tables of contents.* 
> You could say the entire outline is a table of contents.
> Moreover, sections must always be defined in a descendant
> of the node containing the section reference, so there is
> very little need for an index.
> 
> 4. *Leo shows that outline structure is more powerful than 
> narrative.* Indeed, narrative style creates severe maintenance
> problems. The narrative is soon forgotten, and when that happens
> it becomes difficult to find anything. The few times I have
> tried narrative organization I soon regretted it: things just
> weren't where I expected them to be.
> 
> 5. *Leo shows that traditional literate programming encourages
> a too creative approach to programming.* A dictionary is a
> better model for programs than a novel. Leo's outlines provide
> a more regular organization, while providing space for the most
> lengthy discussions when those discussions are required.
> 
> ---
> 
> In particular, if I read (4) I come to the conclusion that
> using LEO might rather be counterproductive to our pamphlet
> idea.
> 

As far as I recall, our current exchange about Leo originated
in my reply to Tim's post concerning "Knuth's literate style":

http://lists.nongnu.org/archive/html/axiom-developer/2007-05/msg00158.html

I mentioned Leo as an example of a literate programming style
that specifically does *not* aim simply to product a single
linear monolithic document (or book). As your quote above from
the Leo user's guide shows, this is not what the developers of
Leo have in mind. This is not to say that Leo cannot be used to
produce such a thing if it is actually desirable. Leo has both
a "weave" command which should in principle (but currently does
not) produce from an imported noweb format file, exactly the same
result as running noweave on that file. But the point of view
Leo is that that the outline view is more powerful and more
flexible than that and so the woven result is of considerable
lesser importance.

In particular this was a follow-up to comments from Waldek,
Gaby, and me that were critical of the creation of
'bookvol5.pamphlet' as literate documentation of the Axiom
interpreter. We all expressed the opinion that 'bookvol5' was
more difficult to appreciate even than the original code.

Of course this is from a "programmers point of view" which
might not be the same as someone new just starting to use
Axiom and trying to understand how it works. But I think
programmers still need literate documentation, the question
is just what form this should take. I am saying that the
Knuth-style "book" is not a particularly good form of
documentation for a programmer.

> The declared goal in Axiom is to write documentation that
> is readable by humans. I am not an experienced LEO user, but
> all I see does convince me to use LEO in order to produce an
> article+code about some mathematical idea.
> 

I presume you meant to write: "does *not* convince me to use
LEO ..."?

But of course Leo is intended to be a tool used by humans.
Tools that allow one to navigate online using a web browser
through svn revisions and change logs is another such tool
intended to be used by humans.

The question is: given current (web) technology and current
programming practices, what form should a "literate program"
take?

> LEO is, in my eyes, very code focused. Am I wrong?
> 

I think you are right. It is apparently viewed by many people
who use it as a kind of high level integrated development
environment (IDE) that supports literature programming.

\start
Date: Sat, 19 May 2007 01:46:57 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Literate documentation

Hi Bill,

>> In particular, if I read (4) I come to the conclusion that using
>> LEO might rather be counterproductive to our pamphlet idea.

> As far as I recall, our current exchange about Leo originated in my
> reply to Tim's post concerning "Knuth's literate style":
> 
> http://lists.nongnu.org/archive/html/axiom-developer/2007-05/msg00158.html
> 
> 
> I mentioned Leo as an example of a literate programming style that
> specifically does *not* aim simply to product a single linear
> monolithic document (or book). As your quote above from the Leo
> user's guide shows, this is not what the developers of Leo have in
> mind.
[snip]
> But the point of view Leo is that that the outline view is more
> powerful and more flexible than that and so the woven result is of
> considerable lesser importance.

Oh, maybe I made a big mistake. By "pamphlet idea" I did *not* refer to 
the production of a monolithic 1000 pages book, but rather on the view 
that documentation is more important than code.

I know that the "clone" idea is powerful. Without clones LEO is just a 
fancy way of showing the table of contents and clicking there to get to 
the corresponding section. Plus, LEO can extract code from the sections. 
Minus, there is no real weave command.

And yes, I agree, "weave" is *not* necessary, if the documentation can 
nicely be read inside LEO. Well, and that is exactly, what I am missing.
I would have to convince LEO to write out a .nw file than noweave and 
latex and view the .dvi. But what happens if I see an typo in the .dvi? 
How do I find the place in the .leo file?

For my working style, LEO just adds overhead.

And the clones, I feel that they are a good thing, that viewing the code 
and documentation from different perspectives is desirable. However, I 
did not yet feel the need for "clones" in my own documentation efforts.
I am totally content with hyperlinks.

> In particular this was a follow-up to comments from Waldek, Gaby, and
> me that were critical of the creation of 'bookvol5.pamphlet' as
> literate documentation of the Axiom interpreter. We all expressed the
> opinion that 'bookvol5' was more difficult to appreciate even than
> the original code.

Sorry, I haven't even looked at bookvol5. But if it is recognised as 
worse than the actual pure code, then this is not a problem of whether 
using LEO or not, but rather a problem that there is no general 
guideline of how to write good literate programs, i.e. easily 
understandable documentation.

My effort in documenting my own code is probably not really literal 
programming. The best thing I've seen up to now is Cliff's description 
of cl-web.

In general, I think, understandable documentation results by 
constructive criticism of other people's works (+ enough time to 
actually rewrite the documentation).

> Of course this is from a "programmers point of view" which might not
> be the same as someone new just starting to use Axiom and trying to
> understand how it works. But I think programmers still need literate
> documentation, the question is just what form this should take. I am
> saying that the Knuth-style "book" is not a particularly good form of
> documentation for a programmer.

What we need is not programmer, but people who understand their area 
(mathematics, physics, etc.) and who are able to put their knowledge 
into code. A traditional programmer is a slave. (That is overstated.) Of 
course, programming is a creative task sometimes, but I would rather 
like to support the "paper-writing people" to aquire some programming 
knowledge.


>> The declared goal in Axiom is to write documentation that is
>> readable by humans. I am not an experienced LEO user, but all I see
>> does convince me to use LEO in order to produce an article+code
>> about some mathematical idea.

> I presume you meant to write: "does *not* convince me to use LEO
> ..."?

Oh, sorry. Of course.

> But of course Leo is intended to be a tool used by humans. Tools that
> allow one to navigate online using a web browser through svn
> revisions and change logs is another such tool intended to be used by
> humans.

I don't want to throw those tools away, but what I am saying is just 
that LEO does not meet my needs. I want some powerful editor that helps 
me in coding the ideas and can extract the code from the text.

> The question is: given current (web) technology and current 
> programming practices, what form should a "literate program" take?

>> LEO is, in my eyes, very code focused. Am I wrong?

> I think you are right. It is apparently viewed by many people who use
> it as a kind of high level integrated development environment (IDE)
> that supports literature programming.

For me LEO is not enough. Let me give a wish list for my dream IDE 
(whose purpose is to write extensions of Axiom's algebra code):

o  Code and Documentation should belong together.
o  The IDE should hide extra markup for the doc/code and code/doc
    borders.
o  Wysiwyg style. (I am not quite sure about that, but it would
    avoid the weave step. And graphics and math formulae inside the
    documentation should not be a rare thing.)
o  Hyperlinks already inside the editor.
o  Semantic code hyperlinks from symbol information of
    integrated Aldor/Spad compiler.
o  Support of (formal) API documenation.
o  File format is revision control friendly.
o  Automatic dependency recognition of files and code(library)
    compilaton.
o  Integration of test suite generation and execution.
o  Aldor/Spad Debugger support.
o  ... maybe some more properties ...

As I said in one of my previous mails. I somehow want an IDE that is as 
powerful as Eclipse+TeXmacs+LEO+(Emacs).

I think one of my next tasks is to investigate what TeXmacs misses.

\start
Date: Fri, 18 May 2007 18:15:25 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Ralf Hemmecke
Subject: RE: Literate documentation

--- Bill Page wrote:

> But the point of view
> Leo is that that the outline view is more powerful and more
> flexible than that and so the woven result is of considerable
> lesser importance.

I think this might come down to how much "domain knowledge" is expected
of the person who is to work with the code.  There is a limit to how
"plug and play" a document can be made if it is intended to be a good
background and introduction to an entire topic - my original thought
when I examined Leo was "how do I write a document that flows and can
still have pieces broken up and viewed elsewhere?"  To me it seems a
little like trying to paint/view the Mona Lisa in small chunks with no
awareness of what is next to each individual chunk.  You need to be
aware of the whole design to paint/appreciate it.

My take on Axiom is that we should try to assume as little as
functionally workable.  This is why I included an introduction to
literate programming as a concept in CL-WEB, for example - someone
needing to maintain that someday has to look no further than the
pamphlet itself for a basic introduction and references to the major
works.  For heavily mathematical subjects it would be even more
important.  Dhmatrix is one example - I find it hard to envision how
that would fit into Leo.
 
> In particular this was a follow-up to comments from Waldek,
> Gaby, and me that were critical of the creation of
> 'bookvol5.pamphlet' as literate documentation of the Axiom
> interpreter. We all expressed the opinion that 'bookvol5' was
> more difficult to appreciate even than the original code.

IIRC, the major objection to bookvol5 in its current form was that it
is "restating" the code in English rather than putting it in context.

> Of course this is from a "programmers point of view" which
> might not be the same as someone new just starting to use
> Axiom and trying to understand how it works. But I think
> programmers still need literate documentation, the question
> is just what form this should take. I am saying that the
> Knuth-style "book" is not a particularly good form of
> documentation for a programmer.

One possible approach to this would be to use the "document strings" in
code for experienced programmer information.  Lisp has document
strings, and IIRC SPAD/Aldor have multiple LEVELS of document strings. 
There are utilities to generate reference manuals using these comments,
at least for Lisp.  I have discussed this at one point with the main
CFFI author.  His code is very well commented.  I like that a lot, but
I wonder if he has in his code any background on what is an FFI, why is
it necessary, etc.  For a programmer this would be more or less useless
- if you are seeking out CFFI you probably have a pretty good idea of
what you are after.  But if someone using a program says "I wonder how
this library is talking to that one" and starts to research that
question in the code, an explanation of what an FFI is would be a big
help.

I think eventually we can re-visit the code and add
"convenience/reference manual" notes to the source code itself, but I
think such steps are secondary compared to documenting the domain
knowledge behind the code.  Most people who are likely to encounter
Axiom are beginners, and people who deal with the mathematical code may
view themselves as mathematicians rather than programmers.  The number
of experts in the world on these subjects is small, and I think
research paper style communication will be appropriate for a large part
of the audience.  I am hopeful that Axiom may some day serve as an
excellent source of advanced mathematical knowledge not locked away
behind subscription journal access controls - sort of an "online or
on-computer mathematical encyclopedia" which also happens to be
integrated with a powerful CAS.

> The question is: given current (web) technology and current
> programming practices, what form should a "literate program"
> take?

My opinion is "hyperlinked research paper".  But that's one opinion.

\start
Date: Fri, 18 May 2007 20:33:47 -0400
From: Dustin Long
To: Tim Daly
Subject: Re: canvas tag

Tim Daly wrote:
> (note: copied to the axiom mailing list)
>
> Dustin,
>
>   
>>> Dustin,
>>>
>>> Can you write into a <canvas> tag?
>>>
>>> The Axiom project <wiki.axiom-developer.org> is planning to replace the
>>> help browser and graphics with a standard firefox front end. Axiom is
>>> written in common lisp.
>>>       
>> Hello Tim,
>>
>> At the moment, Kamen Lisp has an artificial limit on dom function calls:
>> only functionss of one argument are allowed. Removing this restriction
>> shouldn't be difficult; I just haven't been able to get around to doing
>> it. Once that's complete, I don't see why using <canvas> wouldn't be
>> possible. I'll be sure to add it to my list of things to test out.
>>
>> Dustin
>>     
>
> Kamen Lisp is of great interest to me as I could dynamically create
> lisp code and force it out to web pages. This would be useful for 
> creating all kinds of ideas in an Axiom front end.
>
> Is your project open source? How is it licensed?  Axiom uses the
> Modified BSD license which basically allows anyone to do whatever they
> wish with the code.
>
> Tim
>   
Kamen Lisp is currently offered under the MPL/GPL/LGPL tri-license. I'm 
not too familiar with the Modified BSD, but I believe using the MPL will 
allow the two to be combined.

\start
Date: Sat, 19 May 2007 03:58:30 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: boot notes

NAG cdrom contains file called boot.notes describing Shoe.  Another
copy of this text was buried in the ccl sources and removed when ccl
was removed.  This text is both about language and translator.  The test
is shot and lacks many details, some things there may be out of date,
some explanations duplicate what Gaby wrote, but it seems that overall
it is the best Boot/Shoe documentation we have.  I consider putting it
back it repository.

NAG copy is plain text, the copy distributed with ccl in Axiom tarball
was mechanically wrapped inside a pamphlet like source code. 

I must say that IMHO this file would loose much of its utility if
somebody tried to chunkify it with corresponding code, so probably
the best place for it is doc subdirectory.

\start
Date: Fri, 18 May 2007 19:16:06 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Re: MathEdit?

Sorry about yesterday, these links work for me now.

CY

--- Cliff Yapp wrote:

> Has anyone looked at this?
> 
> MathEdit, A Browser-based Visual Mathematics Expression Editor
> http://wme.cs.kent.edu/mathEdit_final.pdf
> http://wme.cs.kent.edu/mathedit/
> 
> I wonder if this work would be of interest to Axiom?

\start
Date: 18 May 2007 21:25:40 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: boot notes

Waldek Hebisch writes:

| NAG cdrom contains file called boot.notes describing Shoe.  Another
| copy of this text was buried in the ccl sources and removed when ccl
| was removed.  This text is both about language and translator.  The test
| is shot and lacks many details, some things there may be out of date,
| some explanations duplicate what Gaby wrote, but it seems that overall
| it is the best Boot/Shoe documentation we have.  I consider putting it
| back it repository.
| 
| NAG copy is plain text, the copy distributed with ccl in Axiom tarball
| was mechanically wrapped inside a pamphlet like source code. 
| 
| I must say that IMHO this file would loose much of its utility if
| somebody tried to chunkify it with corresponding code, so probably
| the best place for it is doc subdirectory.

Please could you put it on the build-improvement branches too?

I've very short and outdated material about Shoe on the web, and I
would be interested to complete it.

\start
Date: Sat, 19 May 2007 00:24:06 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Literate documentation
Cc: Edward Ream

Ralf,

On May 18, 2007 7:47 PM you wrote:
> ... 
> Oh, maybe I made a big mistake. By "pamphlet idea" I did *not*
> refer to the production of a monolithic 1000 pages book, but
> rather on the view that documentation is more important than
> code.

Ok. I understand that.

> 
> I know that the "clone" idea is powerful. Without clones LEO
> is just a fancy way of showing the table of contents and
> clicking there to get to the corresponding section. Plus,
> LEO can extract code from the sections. Minus, there is no
> real weave command.

Oddly enough - at least from our point of view - this is a
standard but apparently undeveloped part of Leo. Ed Ream, the
developer of Leo, says that basically he was waiting for someone
to come along (like us?) who really wanted to use both Leo and
noweb together. He has invited us to prepare an example of how
we think the interaction between Leo and noweb should work.
I find that a little surprising because it would seem that Leo
already has a large number of users. It seems strange to me
that I was only able to find one posting by another user who
seemed to have concerns similar to ours.

Anyway I am thinking that we should start with something like
this:

  1) It should be possible to import a noweb file into and run
     Leo's weave command to produce an output file identical
     to that produced by applying noweave to the original file.

  2) After adding the necessary @root attribute, it should be
     possible to run Leo's tangle command to produce an output
     file identical to that produced by applying notangle to
     the original file.

  3) After importing a noweb file into Leo, saving it in Leo
     format and after opening it at a later time it should be
     possible to edit the file in Leo and then export the file
     to noweb. From the exported noweb file it should be
     possible to generate the same weave and tange outputs
     using noweb noweave and notangle.

In other words, this would make Leo a kind of interactive
replacement for noweb.

But then things get a little more complicated and interesting.
Of course Leo has some features that go beyond that supported
by the noweb file format so it would be possible and presumably
very desirable to explore the use of these features but doing
so will make it impossible to export such a Leo file to noweb
format and retain these features. At that point we would have
to make a decision if we really wanted to maintain the Axiom
source files in Leo format.

Because of Leo's untangle command, it is possible for programmers
to edit generated source files and have Leo automatically update
the associated Leo files from which they are (normally) generated.
So if we adopted Leo format as the Axiom source format, this does
*not* mean that all changes to the source would necessarily have
to be done via Leo. But the literate documentation part of the
Leo files would presumably not be updatable in this manner. On
the other hand, if Leo's weave command were to always generate
LaTeX format with the same sort of source markers that it uses
for the tangled files, then perhaps there would be some way for
an author to edit the generated LaTeX file and expect that Leo
could automatically "unweave" these changes and update the Leo
file. Maybe this would be the best of both worlds.

If we can agree that this might be very interesting to us, then
I can try to write this up as Ed Ream suggested as a guideline
for what we hope Leo might be able to do in the (near) future.

> 
> And yes, I agree, "weave" is *not* necessary, if the
> documentation can nicely be read inside LEO. Well, and that
> is exactly, what I am missing. I would have to convince LEO
> to write out a .nw file than noweave and latex and view the
> .dvi. But what happens if I see an typo in the .dvi? 
> How do I find the place in the .leo file?

I think my suggestion above is a possible answer to that
question - it would mean that you just go ahead and use the
usual dvi - LaTeX file linkage to edit the Leo-generated LaTeX
file (being careful not to distrub any of the weave-anchor
comments in the LaTeX code that where inserted by Leo). Then
you would expect Leo just to unweave these changes back into
the associated Leo source file the next time you openit in
Leo.

> 
> For my working style, LEO just adds overhead.
>

(Maybe) it is possible to use Leo in a fairly transparent manner
via untangle and unweave. Then would would use Leo to view the
integrated code and documentation in the full outline form. And
of course edit it in an integrated manner only when it seems
desirable.
 
> And the clones, I feel that they are a good thing, that
> viewing the code and documentation from different perspectives
> is desirable. However, I did not yet feel the need for
> "clones" in my own documentation efforts. I am totally
> content with hyperlinks.

One difficulty with new tools is that it is often very difficult
to imagine how their use will ultimately affect the way you
work. I think Leo's outlines and the ability to view the same
code and documentation from different points of view (via clones)
is one of those type of things.

> 
> > In particular this was a follow-up to comments from
> > Waldek, Gaby, and me that were critical of the creation
> > of 'bookvol5.pamphlet' as literate documentation of the
> > Axiom interpreter. We all expressed the opinion that
> > 'bookvol5' was more difficult to appreciate even than
> > the original code.
> 
> Sorry, I haven't even looked at bookvol5. But if it is
> recognised as worse than the actual pure code, then this
> is not a problem of whether using LEO or not, but rather a
> problem that there is no general guideline of how to write
> good literate programs, i.e. easily understandable
> documentation.

Yes, perhaps. But maybe the issue is deeper. I think Waldek
said it best in a recent email when he coined the new verb:
to "chunkify". He used this is a somewhat derogatory manner,
suggesting that to re-arrange code into chunks in order to
produce a pamphlet (noweb) style documentation of the Shoe
(new boot) compiler would be very undesirable. Clearly he
would prefer (at least in this case) that the code and the
documentation remain separate. I am sure that this view is
drive at least in part by reluctance to be reading and editing
a cumbersome and large pamphlet file every time one wants to
make a small change to the source code. Maybe Leo's untangle
and unweave features would help prevent this sort of fear of
using this literate format.

> 
> My effort in documenting my own code is probably not really
> literal programming. The best thing I've seen up to now is
> Cliff's description of cl-web.
> 

I agree that would Cliff wrote is a good example. One trouble
(and this has always been a problem with literate programming)
is that most programmers are poor or even terrible technical
writers. Thus by it's very nature I think literate programming
has to normally be a collaborative effort between the highly
technical and specialized programmers and other people who are
willing to contribute to the end result via their writing skills.
I am hopeful that Leo might be an appropriate tool for this sort
of thing.

> In general, I think, understandable documentation results by 
> constructive criticism of other people's works (+ enough time
> to actually rewrite the documentation).

I fully agree.

> 
> > Of course this is from a "programmers point of view" which
> > might not be the same as someone new just starting to use
> > Axiom and trying to understand how it works. But I think
> > programmers still need literate documentation, the question
> > is just what form this should take. I am saying that the
> > Knuth-style "book" is not a particularly good form of
> > documentation for a programmer.
> 
> What we need is not programmer, but people who understand
> their area (mathematics, physics, etc.) and who are able to
> put their knowledge into code. A traditional programmer is
> a slave. (That is overstated.) Of course, programming is a
> creative task sometimes, but I would rather like to support
> the "paper-writing people" to aquire some programming
> knowledge.
> 

I sort of agree with this however I doubt that any of the
people who have programmed fundamental parts of Axiom ever
felt like they were "slaves" even admitting that as an over
statement. These were not traditional programmers in the
conventionally structured software engineering (if these
even exist), but rather researchers who were experimenting
with ways to implement new designs for supporting abstract
mathematics (algebra) in a computer system. I expect it was
much more like what is not called "extreme programming"

http://en.wikipedia.org/wiki/Extreme_Programming

where the software specification evolves almost as rapidly
as the program code.

Another point you are making is really that there are several
different types of programming that one can expect in a system
like Axiom. Programming can occur at several different levels.
There is programming involving the "internals" and there is
"Axiom library" programming that involves the implementation
of mathematical algorithms and techniques. Perhaps the sort
of support needed for these different types of programming
is different... but in the Axiom open source project so far
we are trying to use the same tools (i.e. noweb) for both.

> 
> >> The declared goal in Axiom is to write documentation
> >> that is readable by humans. I am not an experienced LEO
> >> user, but all I see does not convince me to use LEO in
> >> order to produce an article+code about some mathematical
> >> idea.
> 
> > But of course Leo is intended to be a tool used by humans. 
> > Tools that allow one to navigate online using a web browser
> > through svn revisions and change logs is another such tool
> > intended to be used by humans.
> 
> I don't want to throw those tools away, but what I am saying
> is just that LEO does not meet my needs. I want some powerful
> editor that helps me in coding the ideas and can extract the
> code from the text.
> 
> > The question is: given current (web) technology and current 
> > programming practices, what form should a "literate program"
> > take?
> 
> >> LEO is, in my eyes, very code focused. Am I wrong?
> 
> > I think you are right. It is apparently viewed by many 
> > people who use it as a kind of high level integrated
> > development environment (IDE) that supports literature
> > programming.
> 
> For me LEO is not enough. Let me give a wish list for my dream
> IDE (whose purpose is to write extensions of Axiom's algebra
> code):
> 
> o  Code and Documentation should belong together.
> o  The IDE should hide extra markup for the doc/code and
     code/doc borders.
> o  Wysiwyg style. (I am not quite sure about that, but it
>    would avoid the weave step. And graphics and math formulae
>    inside the documentation should not be a rare thing.)
> o  Hyperlinks already inside the editor.
> o  Semantic code hyperlinks from symbol information of
>     integrated Aldor/Spad compiler.
> o  Support of (formal) API documenation.
> o  File format is revision control friendly.
> o  Automatic dependency recognition of files and code
>    (library) compilaton.
> o  Integration of test suite generation and execution.
> o  Aldor/Spad Debugger support.
> o  ... maybe some more properties ...
> 
> As I said in one of my previous mails. I somehow want an IDE
> that is as powerful as Eclipse+TeXmacs+LEO+(Emacs).
> 

Well, that seems like an excellent "wish list" to me. Maybe we
can pass some of these ideas on to the Leo developers to see
what they thing about it. In fact I have Cc'd this message to
Ed Ream and perhaps he will have time to comment on some of this.

> I think one of my next tasks is to investigate what TeXmacs
> misses.
> 

I think the biggest thing that TeXmacs lacks from out point
of view is some form of literate programming or interface to
noweb.

Have you already looked at Lyx?

http://www.lyx.org

Lyx provides WYSIWYG editing of LaTeX-like documents, import
and export of LaTeX documents and has built-in support for
noweb.

http://www.lyx.org/about/features.php

Here is an example of using Lyx and noweb to do some of the
things we are talking about in Axiom:

http://wiki.lyx.org/LyX/LyxWithRThroughSweave

Maybe what you want is something like Leo+Lyx?

\start
Date: Fri, 18 May 2007 23:52:27 -0500
From: Tim Daly
To: list
Subject: Linus on Git

http://www.youtube.com/watch?v=4XpnKHJAok8

Linux Torvalds talks about Git at Google.

\start
Date: Sat, 19 May 2007 01:28:55 -0500
From: Tim Daly
To: list
Subject: Leo

Well, I've looked at and tried Leo.

I'm afraid that my opinions are rather worthless with respect to Leo
for two reasons. 

First, I'm a "primitivist" (that is, someone who thinks that people
should be able to send email using a bare CAT5 cable and a battery) so
IDE-like tools are not considered useful. I find typing raw latex to
be a perfectly reasonable way to create a document. How the documents
are created should be up to the author. How they are viewed is the
more interesting concern from my point of view.

Second, I find that editors are like spouses and after twenty years
with the emacs editor (spouse), my fingers cannot adjust.

Leo may be useful, and it may be worth exploring Ralf's list of
features by making modifications to Leo. At this point, though,
we are not even in agreement about the features and form of our
literate documents. I'm following Knuth. Gaby, Waldek, and Bill
have different ideas. Ralf has created code around ALLPROSE.
Cliff has created code around noweb-style/latex-style.

So far I am most attracted to Cliff's content/level/structuring
style of cl-web. I think he's done an excellent job. And I like
Ralf's pressure toward stronger hyperlinking. My attempts at
literate documents can be seen in either dhmatrix.spad.pamphlet 
or <http://daly.axiom-developer.org/quat.spad.pdf>. The bookvol5
is still many, many hundreds of man-hours away from where I'd
like it to be and is not a good example yet.

But I leave the debate about Leo to everyone else. 

\start
Date: 19 May 2007 12:44:45 +0200
From: Martin Rubey
To: Waldek Hebisch, Gabriel Dos Reis
Subject: fixing SPAD

Dear Gaby & Waldek,

as you may know, there is a problem fixing bug #354, Complex R is not
necessarily a field when R is a field.

It would be quite straightforward to fix it, if we could conditionally export
Field, depending on a Boolean valued function, like

if R has Field and R has Finite and size()$R rem 4 = 1 then Field

Currently, spad seems to accept statements of the form

   D has C

and

   D1 is d2

only.  (Please check this, I'm not entirely sure.)  Do you think it would be
difficult to fix this?  I do not see a workaround, unfortunately.

\start
Date: Sat, 19 May 2007 14:34:47 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Literate documentation
Cc: Edward Ream

>> I know that the "clone" idea is powerful. Without clones LEO
>> is just a fancy way of showing the table of contents and
>> clicking there to get to the corresponding section. Plus,
>> LEO can extract code from the sections. Minus, there is no
>> real weave command.

> Oddly enough - at least from our point of view - this is a
> standard but apparently undeveloped part of Leo. Ed Ream, the
> developer of Leo, says that basically he was waiting for someone
> to come along (like us?) who really wanted to use both Leo and
> noweb together. He has invited us to prepare an example of how
> we think the interaction between Leo and noweb should work.

OK. But I am not convinced anymore that switching to LEO is such a big 
step forward. If the Axiom code ends up by something that looks like 
LeoPy.leo and this is understood as a literate program, then I would say 
I don't understand the code and the ideas behind it. LeoPy.leo is *not* 
a literate program, rather it is a program whose reading order is 
perhaps a bit different than the compilation order, but otherwise I miss 
  a lot that drives people to write understandable code. And 
understandable code is, to a great deal, independent of the underlying 
programming language.

In fact, a literate program should make it very easy to translate a 
program written in one language into another language.

Maybe that is not the only guiding sentence behind LP, but when one 
documents and thinks about that, then one probably adds more 
documentation explaining the tricks needed for the particular language 
and also the goal that this or that piece of code actually serves. In 
the end a literate program might survive even a change in the underlying 
programming language.

> I find that a little surprising because it would seem that Leo
> already has a large number of users. It seems strange to me
> that I was only able to find one posting by another user who
> seemed to have concerns similar to ours.
> 
> Anyway I am thinking that we should start with something like
> this:
> 
>   1) It should be possible to import a noweb file into and run
>      Leo's weave command to produce an output file identical
>      to that produced by applying noweave to the original file.
> 
>   2) After adding the necessary @root attribute, it should be
>      possible to run Leo's tangle command to produce an output
>      file identical to that produced by applying notangle to
>      the original file.
> 
>   3) After importing a noweb file into Leo, saving it in Leo
>      format and after opening it at a later time it should be
>      possible to edit the file in Leo and then export the file
>      to noweb. From the exported noweb file it should be
>      possible to generate the same weave and tange outputs
>      using noweb noweave and notangle.
> 
> In other words, this would make Leo a kind of interactive
> replacement for noweb.

My way of connecting noweb with something like LEO are a bit different.
I don't want to see myself exporting from .leo to .nw then call 
noweave+latex to get .dvi. (The tangle part can probably be done from 
within LEO.) Rather I would like to have leo work directly on the .nw 
files. A .leo file or rather a kind of index file file would keep meta 
information about the outline. Let that have the extension .meta.

Forgetting for a moment that a .nw file contains LaTeX, then there are

<<blah>>=

lines that start a code chunk and

@

or

@ %def ...

lines that start a documentation chunk. If I am not completely wrong, 
that is enough information to split the file into nodes where each node 
contains the documentation that comes right before it. (Maybe there is 
need for a little thought, since there might be code chunks that 
_continue_ previous code chunks.)
If LEO reads a .meta file, then if finds there lots of references to .nw 
files together with a precomputed outline from the previous save time of 
the file. LEO checks that the outline is not in conflict with the .nw 
files and reads the nodes into its memory. Then work is done as usual in 
leo. Saving any modification, saves the .mete file and all the various 
.nw files. (If the outline changed, then that might result in reordering 
the chunks inside the .nw file.---Maybe there should be a special 
nwfile-outline.)

Now if the .meta file is lost or if someone makes drastic changes to .nw 
files without using LEO, then most of or even all the cloned information 
is lost. Well, that is sad, but one has just lost the views on the code 
from different perspectives.

Before I started to look into LEO, I thought something like this 
scenario can be achieved with LEO. That would probably make most of the 
current Axiom developers happy. Everyone can work on .nw (.pamphlet) 
files as before, and there are people who could maintain different 
perspectives on the code+doc base.

Basically, I see LEO as a help to organise the code from a higher level, 
but I don't want it to mix with the pamphlet/noweb structure.

> But then things get a little more complicated and interesting.
> Of course Leo has some features that go beyond that supported
> by the noweb file format

What exact features do you like most.

[snip]

> Because of Leo's untangle command, it is possible for programmers
> to edit generated source files and have Leo automatically update
> the associated Leo files from which they are (normally) generated.

I wonder if we should make "untangle" a desireable feature. It basically 
means that you update code and forget about the documentation.
I tend to say, that hasn't my support.

My experience with developing code for Aldor-Combinat with the help of 
ALLPROSE is that I never felt the need to edit the generated .as files 
directly. One can easily find oneself around in the corresponding .as.nw 
file. Having need to look at code files directly just says that you 
haven't changed your view to programming.

With LP-aware debuggers I don't think that the .as or any other 
generated code file is anything else than some generated thing. You can 
generate any additional information into such a file to help a debugger 
or any other tool to find its way back into the actual .as.nw source, 
but I don't want to look at .as files. That is as uninteresting (and 
only rarely needed) as the .c file that can be generated from Aldor sources.

> Maybe this would be the best of both worlds.

Bill, can you state a few items why exactly you think LEO would help Axiom?

[snip]

> I think my suggestion above is a possible answer to that
> question - it would mean that you just go ahead and use the
> usual dvi - LaTeX file linkage to edit the Leo-generated LaTeX
> file (being careful not to distrub any of the weave-anchor
> comments in the LaTeX code that where inserted by Leo). Then
> you would expect Leo just to unweave these changes back into
> the associated Leo source file the next time you openit in
> Leo.

But I don't want my texts be stored inside .nw and inside .leo. There 
will be a point when nobody knows anymore what the actual sources are.

>>> In particular this was a follow-up to comments from
>>> Waldek, Gaby, and me that were critical of the creation
>>> of 'bookvol5.pamphlet' as literate documentation of the
>>> Axiom interpreter. We all expressed the opinion that
>>> 'bookvol5' was more difficult to appreciate even than
>>> the original code.
>> Sorry, I haven't even looked at bookvol5. But if it is
>> recognised as worse than the actual pure code, then this
>> is not a problem of whether using LEO or not, but rather a
>> problem that there is no general guideline of how to write
>> good literate programs, i.e. easily understandable
>> documentation.
> 
> Yes, perhaps. But maybe the issue is deeper. I think Waldek
> said it best in a recent email when he coined the new verb:
> to "chunkify". He used this is a somewhat derogatory manner,
> suggesting that to re-arrange code into chunks in order to
> produce a pamphlet (noweb) style documentation of the Shoe
> (new boot) compiler would be very undesirable. Clearly he
> would prefer (at least in this case) that the code and the
> documentation remain separate. I am sure that this view is
> drive at least in part by reluctance to be reading and editing
> a cumbersome and large pamphlet file every time one wants to
> make a small change to the source code. Maybe Leo's untangle
> and unweave features would help prevent this sort of fear of
> using this literate format.

I can understand Waldek. Unfortunately, I have never read code in 
wh-sandbox, so I actually cannot judge. But suppose Waldek likes having 
documentation here and code there. That does not mean that in the future 
somebody else could rearrange that to make the code even more 
understandable. Everyone has his coding style and for Axiom it is 
currently probably the best to let everyone work as they please. We need 
something working, eventually. And if Waldek does this and puts the 
documentation different from where I would put it, I don't care. I 
cannot do Waldek's work so I am rather satisfied that Waldek writes 
documentation at all even if it lived in another place.

All my LP efforts currently mainly concern the Algebra code.

>> My effort in documenting my own code is probably not really
>> literal programming. The best thing I've seen up to now is
>> Cliff's description of cl-web.

> I agree that would Cliff wrote is a good example. One trouble
> (and this has always been a problem with literate programming)
> is that most programmers are poor or even terrible technical
> writers.

Hmmm, I really think that this is very much due to the fact that LP is 
not normally thought in university courses. Everyone wants to have code 
quickly. Nobody pays for good documentation. If a customer gets a 
sparsely documented product, one can get even more money out of that 
customer since somebody has to be paid for the maintenance (which might 
even be another company).

 > Thus by it's very nature I think literate programming
> has to normally be a collaborative effort between the highly
> technical and specialized programmers and other people who are
> willing to contribute to the end result via their writing skills.

Let's see how this works out in our Axiom experiment. ;-)

>> I think one of my next tasks is to investigate what TeXmacs
>> misses.

> I think the biggest thing that TeXmacs lacks from out point
> of view is some form of literate programming or interface to
> noweb.
> 
> Have you already looked at Lyx?

Oh thanks for that hint and yet another evaluation work. ;-)

\start
Date: Sat, 19 May 2007 16:01:17 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: fixing SPAD
Cc: Gabriel Dos Reis

Martin Rubey wrote:
> Dear Gaby & Waldek,
> 
> as you may know, there is a problem fixing bug #354, Complex R is not
> necessarily a field when R is a field.
> 
> It would be quite straightforward to fix it, if we could conditionally export
> Field, depending on a Boolean valued function, like
> 
> if R has Field and R has Finite and size()$R rem 4 = 1 then Field
> 
> Currently, spad seems to accept statements of the form
> 
>    D has C
> 
> and
> 
>    D1 is d2
> 
> only.  (Please check this, I'm not entirely sure.)  Do you think it would be
> difficult to fix this?  I do not see a workaround, unfortunately.
> 

For issue 354 I belive that there is reasonable workaround: just export
Field unconditionally (as we do know), but throw error when sombody
tries to create a fake field.  For example PrimeField is doing this --
it exports Field for any value of p, but complains if you give it
non-prime p.

I belive that we should add to Complex something like the snippet below
(untested, ATM I am busy with other things)

   == add
      if R has Field then
         if R has complex or _
            ((characteristic()$R) mod 5 = 1) or _
            (R has Finite and _
               ((size()$R) mod 5 = 1) then
           error "Field given to Complex already contains square root of -1"


\start
Date: 19 May 2007 16:19:58 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: fixing SPAD
Cc: Gabriel Dos Reis

Waldek Hebisch writes:

> For issue 354 I belive that there is reasonable workaround: just export
> Field unconditionally (as we do know), but throw error when sombody
> tries to create a fake field.  For example PrimeField is doing this --
> it exports Field for any value of p, but complains if you give it
> non-prime p.

I don't think that's that way to go about it, since I think that Complex PF 5
is a perfectly reasonable domain, only, it's not a field.  I know that one
could, in this special case, switch to Complex ZMOD 5, but that's another
story. Hm, are there Fields (easily created in Axiom) where it is more
difficult to create the corresponding Ring?

In any case, I thought that Complex R is intended to be the ring of formal
linear combinations of 1 and %i, where %i^2 = 1.  (That's also roughly what the
doc says.)  Do you see a different interpretation for the 'Complex'
constructor?

\start
Date: Sat, 19 May 2007 09:31:05 -0500 (CDT)
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: fixing SPAD
Cc: Waldek Hebisch

On Sat, 19 May 2007, Martin Rubey wrote:

| Dear Gaby & Waldek,
| 
| as you may know, there is a problem fixing bug #354, Complex R is not
| necessarily a field when R is a field.
| 
| It would be quite straightforward to fix it, if we could conditionally export
| Field, depending on a Boolean valued function, like
| 
| if R has Field and R has Finite and size()$R rem 4 = 1 then Field
| 
| Currently, spad seems to accept statements of the form
| 
|    D has C
| 
| and
| 
|    D1 is d2
| 
| only.  (Please check this, I'm not entirely sure.)  Do you think it would be
| difficult to fix this?  I do not see a workaround, unfortunately.


Martin --

   I believe you raise a fundamental problem, which is that Spad
should allow combination of predicate through usual logical operators.

For a given specific case, one might look for a workaround that
simulates type checking at runtime. However, I don't believe that is 
a good way forward:

   (1) that usually leads to unnatual, unmaintainable code in the long run;
   (2) we fail to express directly what our ideas;
   (3) it is not clear we have a coherent systematic approach.

Therefore, I believe this is an issue that should be given thought.

\start
Date: 19 May 2007 16:47:52 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: fixing SPAD
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

>    I believe you raise a fundamental problem, which is that Spad
> should allow combination of predicate through usual logical operators.

"combinations of predicates through usual logical operators." *are* allowed.
Only, in the context of conditional exports, predicates are limited to "is" and
"has".

Aldor, in contrast, makes no (or maybe, not much) difference to other parts of
the code here.

Thus, my question is, would it be easy, or at least, doable for you, to make
SPAD behave like Aldor here, i.e. drop the restriction on the predicates
allowed?

> For a given specific case, one might look for a workaround that simulates
> type checking at runtime.

I doubt this.  Of course, using Waldek's idea we could say that 'Complex F' is
only allowed if either F is not a field or x^2+1 is irreducible in F.  But I'm
not sure if that's what we want.  And I doubt that you can achieve what I first
proposed in current SPAD, namely, make 'Complex F' export 'Field' only if x^2+1
is irreducible in F.

I guess, your answer (whether it would be "easy"), is "no"...

\start
Date: Sat, 19 May 2007 10:09:10 -0500 (CDT)
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: fixing SPAD
Cc: Waldek Hebisch

On Sat, 19 May 2007, Martin Rubey wrote:

| Gabriel Dos Reis writes:
| 
| >    I believe you raise a fundamental problem, which is that Spad
| > should allow combination of predicate through usual logical operators.
| 
| "combinations of predicates through usual logical operators." *are* allowed.
| Only, in the context of conditional exports, predicates are limited to "is" and
| "has".

I meant in the context of conditional exports.
Sorry, if that wasn't clear -- as I assumed you were talking of exports.

\start
Date: Sat, 19 May 2007 11:11:18 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: Linus on Git

Very interesting the part of git feature for merging compared to svn,
especially with the current situation in Axiom Silver.

On 5/19/07, Tim Daly wrote:
> http://www.youtube.com/watch?v=4XpnKHJAok8
>
> Linux Torvalds talks about Git at Google.

\start
Date: 19 May 2007 17:19:31 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: fixing SPAD
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

> On Sat, 19 May 2007, Martin Rubey wrote:
> 
> | Gabriel Dos Reis writes:
> | 
> | >    I believe you raise a fundamental problem, which is that Spad
> | > should allow combination of predicate through usual logical operators.
> | 
> | "combinations of predicates through usual logical operators." *are* allowed.
> | Only, in the context of conditional exports, predicates are limited to "is" and
> | "has".
> 
> I meant in the context of conditional exports.
> Sorry, if that wasn't clear -- as I assumed you were talking of exports.

Sorry, but this reply of you makes your initial statement "unclearer".  You
write

> | > Spad should allow combination of predicate through usual logical
> | > operators.

This sounds as though combination of predicates (in conditional exports) would
not be allowed.

But currently, Spad does allow combination of predicates through usual logical
operators, no matter where.  However, *predicates* in the context of
conditional exports are limited to "is" and "has", it seems to me.  So,
combination works, but arbitrary predicates don't.

Do we agree?

\start
Date: Sat, 19 May 2007 10:21:20 -0500 (CDT)
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: fixing SPAD
Cc: Waldek Hebisch

On Sat, 19 May 2007, Martin Rubey wrote:

| > For a given specific case, one might look for a workaround that simulates
| > type checking at runtime.
| 
| I doubt this.

Please don't.  Moving all type checking to runtime will not intrisincally
execute more non-sensical codes; it just makes it inconvenient to write
solid, well structured codes.

My original statement was an observation about why I believe removing
the restriction is something that should be considered.

\start
Date: Sat, 19 May 2007 10:23:34 -0500 (CDT)
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: fixing SPAD
Cc: Waldek Hebisch

On Sat, 19 May 2007, Martin Rubey wrote:

| Gabriel Dos Reis writes:
| 
| > On Sat, 19 May 2007, Martin Rubey wrote:
| > 
| > | Gabriel Dos Reis writes:
| > | 
| > | >    I believe you raise a fundamental problem, which is that Spad
| > | > should allow combination of predicate through usual logical operators.
| > | 
| > | "combinations of predicates through usual logical operators." *are* allowed.
| > | Only, in the context of conditional exports, predicates are limited to "is" and
| > | "has".
| > 
| > I meant in the context of conditional exports.
| > Sorry, if that wasn't clear -- as I assumed you were talking of exports.
| 
| Sorry, but this reply of you makes your initial statement "unclearer".  You
| write
| 
| > | > Spad should allow combination of predicate through usual logical
| > | > operators.
| 
| This sounds as though combination of predicates (in conditional exports) would
| not be allowed.
| 
| But currently, Spad does allow combination of predicates through usual logical
| operators, no matter where.  However, *predicates* in the context of
| conditional exports are limited to "is" and "has", it seems to me.  So,
| combination works, but arbitrary predicates don't.

Martin -- 

   If you cannot correctly parse what I wrote, then I drop the ball.

\start
Date: 19 May 2007 17:59:30 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: fixing SPAD
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

>    If you cannot correctly parse what I wrote, then I drop the ball.

Please bear with me, I'm not english native.  Could you just tell me which
sentence I misparsed and maybe rephrase it, so that I can understand?  I read
your mail several times now, I just do not understand it.

Are you saying:

  if A and B or C then ...

should be, but currently isn't allowed in the context of conditional exports?
(I think it is allowed already now.)

On Sat, 19 May 2007, Martin Rubey wrote:

> | > For a given specific case, one might look for a workaround that simulates
> | > type checking at runtime.
> | 
> | I doubt this.
> 
> Please don't. 

I'm still curious how you would do it. I.e., Do you think you can write a
domain constructor Foo(R) that exports Cat1 if R has 2 elements but Cat2 if R
has 3 elements?

> My original statement was an observation about why I believe removing the
> restriction is something that should be considered.

I agree that removing the restriction is important.  But since I have no idea
how long I'll have to wait for it, I wonder whether a workaround exists.
(apart from switching to Aldor)

\start
Date: Sat, 19 May 2007 11:19:52 -0500 (CDT)
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: fixing SPAD
Cc: Waldek Hebisch

On Sat, 19 May 2007, Martin Rubey wrote:

| Gabriel Dos Reis writes:
| 
| >    If you cannot correctly parse what I wrote, then I drop the ball.
| 
| Please bear with me, I'm not english native.  Could you just tell me which
| sentence I misparsed and maybe rephrase it, so that I can understand?  I read
| your mail several times now, I just do not understand it.
| 
| Are you saying:
| 
|   if A and B or C then ...
| 
| should be, but currently isn't allowed in the context of conditional exports?
| (I think it is allowed already now.)

I'm saying that we seriously consider the above when A, B or C
happen to be patterns (`is form') or attribute queries (`has form').
Note that from Spad point of view, they are just predicates.

\start
Date: Sat, 19 May 2007 18:46:10 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: fixing SPAD

Gabriel Dos Reis wrote:
> On Sat, 19 May 2007, Martin Rubey wrote:
> | Are you saying:
> | 
> |   if A and B or C then ...
> | 
> | should be, but currently isn't allowed in the context of conditional exports?
> | (I think it is allowed already now.)
> 
> I'm saying that we seriously consider the above when A, B or C
> happen to be patterns (`is form') or attribute queries (`has form').
> Note that from Spad point of view, they are just predicates.
> 

>From aggcat.spad.pamphlet:

   if Entry has SetCategory and % has finiteAggregate then
      entry?: (Entry,%) -> Boolean
        ++ entry?(x,u) tests if x equals \axiom{u . i} for some index i.

Form aggcat2.spad.pamphlet:

      if B has ListAggregate(R) or not(B has shallowlyMutable) then
        -- A is a list-oid, and B is either list-oids or not mutable
        map(f, l) == construct [f s for s in entries l]

So, as Martin wrote simple boolean operators already work.  I belive
that there are restrictions, namely that more complicated expressions
do not work.  I agree that also complicated expressions should be
allowed, but support (or lack of it) does not cause conceptual or
practical difficulties: complicated expressions are just syntatic
sugar for combinations of simple expressions.

\start
Date: Sat, 19 May 2007 12:09:22 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: fixing SPAD

On Sat, 19 May 2007, Waldek Hebisch wrote:

| Gabriel Dos Reis wrote:
| > On Sat, 19 May 2007, Martin Rubey wrote:
| > | Are you saying:
| > | 
| > |   if A and B or C then ...
| > | 
| > | should be, but currently isn't allowed in the context of conditional exports?
| > | (I think it is allowed already now.)
| > 
| > I'm saying that we seriously consider the above when A, B or C
| > happen to be patterns (`is form') or attribute queries (`has form').
| > Note that from Spad point of view, they are just predicates.
| > 
| 
| From aggcat.spad.pamphlet:
| 
|    if Entry has SetCategory and % has finiteAggregate then
|       entry?: (Entry,%) -> Boolean
|         ++ entry?(x,u) tests if x equals \axiom{u . i} for some index i.
| 
| Form aggcat2.spad.pamphlet:
| 
|       if B has ListAggregate(R) or not(B has shallowlyMutable) then
|         -- A is a list-oid, and B is either list-oids or not mutable
|         map(f, l) == construct [f s for s in entries l]
| 
| So, as Martin wrote simple boolean operators already work.  I belive
| that there are restrictions, namely that more complicated expressions
| do not work.  I agree that also complicated expressions should be
| allowed, but support (or lack of it) does not cause conceptual or
| practical difficulties: complicated expressions are just syntatic
| sugar for combinations of simple expressions.

I don't see what you guys are trying to make as a point.

    )abbrev domain FOO Foo
    Foo(T: Type): Public == Private where
      Public ==> with
	if T has Ring or T is Double then
	   bar: % -> Boolean

      Private ==> add
	if T has Ring or T is Double then
	   bar x == false


I'm out of this discussion.

\start
Date: Sat, 19 May 2007 19:09:45 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: fixing SPAD
Cc: Waldek Hebisch

> Martin -- 
> 
>    If you cannot correctly parse what I wrote, then I drop the ball.
> 
> -- Gaby

Did this mail help anybody?

Gaby, could you please avoid such statements on the list. Just imagine 
that somebody replied to you with that sentence; how would you feel?

\start
Date: Sat, 19 May 2007 12:13:19 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: fixing SPAD
Cc: Waldek Hebisch

On Sat, 19 May 2007, Ralf Hemmecke wrote:

| > Martin -- 
| >    If you cannot correctly parse what I wrote, then I drop the ball.
| > 
| > -- Gaby
| 
| Did this mail help anybody?
| 
| Gaby, could you please avoid such statements on the list. Just imagine that
| somebody replied to you with that sentence; how would you feel?

I'll go back re-read the messages carefully.  Would not you?

This discussion is silly.  

\start
Date: Sat, 19 May 2007 19:15:09 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: fixing SPAD
Cc: Gabriel Dos Reis

Martin Rubey wrote:
> Waldek Hebisch writes:
> 
> > For issue 354 I belive that there is reasonable workaround: just export
> > Field unconditionally (as we do know), but throw error when sombody
> > tries to create a fake field.  For example PrimeField is doing this --
> > it exports Field for any value of p, but complains if you give it
> > non-prime p.
> 
> I don't think that's that way to go about it, since I think that Complex PF 5
> is a perfectly reasonable domain, only, it's not a field.  I know that one
> could, in this special case, switch to Complex ZMOD 5, but that's another
> story. Hm, are there Fields (easily created in Axiom) where it is more
> difficult to create the corresponding Ring?
> 
> In any case, I thought that Complex R is intended to be the ring of formal
> linear combinations of 1 and %i, where %i^2 = 1.  (That's also roughly what the
> doc says.)  Do you see a different interpretation for the 'Complex'
> constructor?
> 

I view Complex as a special purpose constructor: square root of -1
has distinguished role for subsets of complex numbers.  But in general
one wants arbitrary algebraic extensions, and SimpleAlgebraicExtension
provide them (well, as long as R is commutative), without special
assumptions hardwired into Complex.

Note also that you need to be _very_ carefull when you work with
rings having zero divisors.  More precisely, when zero divisors
are present Expression domain may give you incorrect results.
Since untyped input is frequently converted to Expression, one
should carefully consider types to avoid such convertions.

Also, IIRC Expression or related domains refer back to Complex,
so I prefer to trap zero divisors in Complex.

\start
Date: Sat, 19 May 2007 19:16:07 +0200
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: re: fixing SPAD
Cc: Gabriel Dos Reis

>>From aggcat.spad.pamphlet:
> 
>    if Entry has SetCategory and % has finiteAggregate then
>       entry?: (Entry,%) -> Boolean
>         ++ entry?(x,u) tests if x equals \axiom{u . i} for some index i.
> 
> Form aggcat2.spad.pamphlet:
> 
>       if B has ListAggregate(R) or not(B has shallowlyMutable) then
>         -- A is a list-oid, and B is either list-oids or not mutable
>         map(f, l) == construct [f s for s in entries l]
> 
> So, as Martin wrote simple boolean operators already work.  I belive
> that there are restrictions, namely that more complicated expressions
> do not work.

Martin, correct me if I am wrong...  But I guess Martin meant that 
something like

define ResidueClassRing(R: CommutativeRing, p: R): Category == with {
     Ring;
     if prime? p then Field;
     ...
}

which would be perfectly fine in Aldor does not work in SPAD.

In contrast to "has", "is", "and", etc. the function "prime?" is not 
defined by the language and thus cannot be evaluated at compile time.
In Aldor that is delayed until the time that category is first used (at 
runtime). Only then the actual exports are computed.

\start
Date: Sat, 19 May 2007 19:28:35 +0200 (CEST)
From: Waldek Hebisch
To: Ralf Hemmecke
Subject: re: fixing SPAD
Cc: Gabriel Dos Reis


> Martin, correct me if I am wrong...  But I guess Martin meant that 
> something like
> 
> define ResidueClassRing(R: CommutativeRing, p: R): Category == with {
>      Ring;
>      if prime? p then Field;
>      ...
> }
> 
> which would be perfectly fine in Aldor does not work in SPAD.
>

Sure, I am going to replay to his message where he gave more details.
 
> In contrast to "has", "is", "and", etc. the function "prime?" is not 
> defined by the language and thus cannot be evaluated at compile time.
> In Aldor that is delayed until the time that category is first used (at 
> runtime). Only then the actual exports are computed.
> 

To avoid confusion:  Axiom also computes exports at runtime.  Namely,
each function signature has associated predicate which is evaluated
when domain is constructed at runtime.  But the compiler can only only
handle simple predicates ("has" and "is").  AFAIK predicates may
contain arbitrary boolean expressions built from simple predicates,
so restrictions on boolean expressions are just parser thing (in
other word syntactic sugar).  The restriction on base predicates
is deeper.

\start
Date: 19 May 2007 19:38:17 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: fixing SPAD
Cc: Gabriel Dos Reis

Ralf Hemmecke writes:

> Martin, correct me if I am wrong...  But I guess Martin meant that something
> like
> 
> define ResidueClassRing(R: CommutativeRing, p: R): Category == with {
>      Ring;
>      if prime? p then Field;
>      ...
> }
> 
> which would be perfectly fine in Aldor does not work in SPAD.

Yes, that's exactly what I meant.

\start
Date: Sat, 19 May 2007 19:43:59 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: fixing SPAD

Gabriel Dos Reis wrote:
> I don't see what you guys are trying to make as a point.
> 
>     )abbrev domain FOO Foo
>     Foo(T: Type): Public == Private where
>       Public ==> with
> 	if T has Ring or T is Double then
> 	   bar: % -> Boolean
> 
>       Private ==> add
> 	if T has Ring or T is Double then
> 	   bar x == false
> 
> 

I am not sure is this is a bug or deliberate restriction.  But to
put things stright: Spad compiler does not grook T is Double here,
'or' is handled fine.  If you change 'T is Double' to 'T has Double'
then your example compile fine.  If you replace 'T has Ring or T is Double'
by 'T is Double' it fails.

\start
Date: 19 May 2007 19:53:12 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: fixing SPAD

Waldek Hebisch writes:

> > In any case, I thought that Complex R is intended to be the ring of formal
> > linear combinations of 1 and %i, where %i^2 = 1.  (That's also roughly what the
> > doc says.)  Do you see a different interpretation for the 'Complex'
> > constructor?

> I view Complex as a special purpose constructor: square root of -1
> has distinguished role for subsets of complex numbers.  

But I wouldn't consider Complex PF 3 as a subset of the complex numbers, since
the arithmetic is different. 

> But in general one wants arbitrary algebraic extensions, and
> SimpleAlgebraicExtension provide them (well, as long as R is commutative),
> without special assumptions hardwired into Complex.

Looking at SAE, I see that it exports Field if its underlying ring is a Field.
I guess we have a problem there, too?

> Note also that you need to be _very_ carefull when you work with rings having
> zero divisors.

I would like to trap zero divisors with the predicate 

  if R has Field then ...

\start
Date: Sat, 19 May 2007 12:56:16 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: fixing SPAD

On Sat, 19 May 2007, Waldek Hebisch wrote:

| Gabriel Dos Reis wrote:
| > I don't see what you guys are trying to make as a point.
| > 
| >     )abbrev domain FOO Foo
| >     Foo(T: Type): Public == Private where
| >       Public ==> with
| > 	if T has Ring or T is Double then
| > 	   bar: % -> Boolean
| > 
| >       Private ==> add
| > 	if T has Ring or T is Double then
| > 	   bar x == false
| > 
| > 
| 
| I am not sure is this is a bug or deliberate restriction.  But to
| put things stright: Spad compiler does not grook T is Double here,

My point so far is: I don't see the point of the restriction, whether is 
"is" or prime?.  We should seriously consider allowing all of them, as long as
they are predicates.

\start
Date: Sat, 19 May 2007 11:11:20 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke, Bill Page
Subject: Re: Literate documentation
Cc: Edward Ream


--- Ralf Hemmecke wrote:

> In fact, a literate program should make it very easy to translate a 
> program written in one language into another language.

YES.  My take on a literate program is that if the tasks it is
performing are explained well enough, the only question is how to
perform those tasks in the target language.  (Of course, some
explanation has to be language specific but the task should be clear.)
 
> Maybe that is not the only guiding sentence behind LP, but when one 
> documents and thinks about that, then one probably adds more 
> documentation explaining the tricks needed for the particular
> language and also the goal that this or that piece of code actually
> serves. In the end a literate program might survive even a change in
> the underlying programming language.

That is my hope.  My "guiding principles" for Literate Programming at
this stage can probably be expressed as:

1.  A Literate Program should document the background of a task, the
particulars of the task, and "tough spots" with implementing the task. 
Ideally, only the last item is language specific.

2.  A Literate Program should contain enough background material on a
topic to allow understanding and application of an idea without having
to refer to non-included sources.  (For example, key algorithms
published in journal articles should be explained in the pamphlet, on
the assumption that some readers may not have access to/be able to
afford said articles.)  This has the side benefit of forcing the author
to greater awareness/knowledge of the subject in question - writing a
"proper" literate program on a topic should be a demonstration of
knowledge sufficient to solve the problem in a reasonable fashion.  I
can't claim to be there yet, but that's the eventual goal.

More on the wishlist side of things:

3.  "Turtles all the way down." My dream would be to have Axiom built
on only literate programs, down possibly even to the hardware design. 
This is one of the reasons I prefer working in Lisp, as every language
added to the support stack (except perhaps those implemented inside
Lisp like SPAD) makes that goal more remote.  In some specific cases
(for example the ANSI lisp specification) it is not possible to
incorporate the literature and the code directly, and we must state
that we rely on a "working ANSI Lisp environment as defined in ANSI
standard *whatever-the-ref-is*".  I dislike this even in those cases,
but clarification of the dpANS3 documents is impractical at this time
and converting sbcl into a complete literate program  without them
would be a monumental project requiring much in-depth knowledge of
compilers and low level issues that I don't have :-(.  Maybe someday. 
For the 30 year horizon (maybe beyond even that length of time) I think
it is relevant, but for now - assume Lisp and work from there.

> I wonder if we should make "untangle" a desireable feature. It
> basically means that you update code and forget about the
> documentation. I tend to say, that hasn't my support.

I agree.  It might be possible to support the idea of editing the code
in code view and having that update appear in the pamphlet view, but I
would tend to be wary of it.  There may be some nifty tricks for
viewing a chunk in code context or pamphlet context which can be
implemented, and I think a sufficiently smart literate programming
editor would be able to maintain code formatting and syntax
highlighting from the tangled file point of view inside the chunks, but
changing the code outside of the pamphlet context is something to be
wary of.

In cases where programmers simply don't want to work with pamphlet
editing and update the code only, I would propose a "chunkified diff"
utility where the edited code file is diffed against the current tangle
output, and the diffs are propagated back to chunks for incorporation
in the pamphlet context by the pamphlet author.  Each chunk would have
the diff highlighted until the pamphlet author identifies the merge as
complete.

None of these features require the "outline" approach and should be
possible with normal pamphlet files, given the correct tool and editor
support.

> Having need to look at code files directly just says that you 
> haven't changed your view to programming.

Bingo.  My take on this is pamphlet files should be maintained as
pamphlets, with tools to help merge non-pamphlet based updates.  That
process can't be automatic - some minor changes may not need
documentation changes, but many (most?) probably will.

> With LP-aware debuggers I don't think that the .as or any other 
> generated code file is anything else than some generated thing. You
> can generate any additional information into such a file to help a
> debugger or any other tool to find its way back into the actual
> .as.nw source,

Right.
 
> but I don't want to look at .as files. That is as uninteresting (and 
> only rarely needed) as the .c file that can be generated from Aldor
> sources.

Off topic, but a question about Aldor - if you compile Aldor routines
into c and build that c code, can other Aldor routines compiled into
Lisp still interact with the compiled c based modules?  Does Aldor
enforce compatibility?

>> Yes, perhaps. But maybe the issue is deeper. I think Waldek
>> said it best in a recent email when he coined the new verb:
>> to "chunkify". He used this is a somewhat derogatory manner,
>> suggesting that to re-arrange code into chunks in order to
>> produce a pamphlet (noweb) style documentation of the Shoe
>> (new boot) compiler would be very undesirable. Clearly he
>> would prefer (at least in this case) that the code and the
>> documentation remain separate. I am sure that this view is
>> drive at least in part by reluctance to be reading and editing
>> a cumbersome and large pamphlet file every time one wants to
>> make a small change to the source code. Maybe Leo's untangle
>> and unweave features would help prevent this sort of fear of
>> using this literate format.

That's of course in the eye of the beholder.  I can understand that
view - Waldek is a skilled coder and to him it would feel like a lot of
overhead.  I think that's where less skilled but learning coders can be
a big help to Axiom.  Dr. Sit and I discussed this a bit at ECCAD -
someone who needs to learn the basics behind a program can take working
code, dissect it, research the background, and write a pamphlet.  In
the process they may clean up the code or introduce some new features,
but they are building off of very skilled work by someone who may not
feel the need for literate programming.  In essence, this is what
happened with cl-web - Waldek provided the original finite-state based
code, and I expanded it into a literate document while in the process
of learning.

Similarly, I think someone having very little knowledge of languages,
compilers, BNF notation, etc. could look at boot or spad and start from
the beginning.  People capable of making boot and spad work may not
feel any particular interest in writing an introduction to compiler
theory as the first chapter of the pamphlet, but someone who is
learning will need to find this out anyway and in the process can write
it up.  This a) forces them to learn the ideas well enough to express
them coherently and b) means the next person coming behind them will be
able to start with the pamphlet and do a lot less "grunt research work"
to get up to speed.

> I can understand Waldek. Unfortunately, I have never read code in 
> wh-sandbox, so I actually cannot judge. But suppose Waldek likes 
> having documentation here and code there. That does not mean that
> in the future somebody else could rearrange that to make the code
> even more understandable.

I think you mean "couldn't rearrange"?  If so, I agree.  Waldek is
doing very good and very important work, and even if someone comes in
to write a literate version they will be building off of his efforts. 
Studying the solution to a hard problem is usually simpler and less
time consuming than trying to solve it for the first time (or second or
third if the previous solutions were lost...)

> Everyone has his coding style and for Axiom it is currently probably
> the best to let everyone work as they please. We need
> something working, eventually. And if Waldek does this and puts the 
> documentation different from where I would put it, I don't care. I 
> cannot do Waldek's work so I am rather satisfied that Waldek writes 
> documentation at all even if it lived in another place.

Exactly.  Right now, most of Axiom is not literate except in the
technical sense of being inside a pamphlet file.  I have no particular
qualms about Waldek's work being done in a non-literate fashion.  My
take on it is that when we DO start to make the files literate for
posterity we probably want tools that allow non-pamphlet edits to be
intelligently and interactively merged back into the pamphlet.  When we
get there, understanding Waldek's updated code won't be significantly
harder than the current code, and may be easier.

Pretty much any work I do in a serious way for Axiom (the Emacs mode
and cl-web, so far) has to be literate because I am learning from a
basic level as I go.  This has the advantage that I know what questions
a non-skilled programmer will want to have answered, since they are the
ones I'm asking :-).

Alasdair McAndrew asked recently on the list about learning Axiom and
writing code for Axiom.  Since I'm in a similar position, I can supply
my take on it - you don't want to go in with the mindset of writing
code that "just works" but being a beginner is not necessarily a minus
and can in some situations be a plus.  Fortunately for beginners, Axiom
is currently in a state where many hard problems are solved but the
solutions need cleanup, documentation, etc.  Selecting a particular
problem and exploring it is a GREAT way to learn and will also
contribute to Axiom.  Beginner questions are sometimes the most useful,
since experts in a subject may be so accustomed to what they are doing
they forget the unstated axioms.

Nor does a solution always have to be the "final word" on solving a
particular problem.  Ideally, if there is more work to be done
(theoretical or practical) a pamphlet can indicate this and the next
person knows where to start.

As for Axiom being a workhorse - it isn't now, true.  That doesn't mean
it will always be a "specialists only" game.  Most "user level"
mathematics has its foundations in more rigorous theory, and being able
to supply user expected behaviors while retaining the rigor behind them
is a major future selling point for Axiom.  We are doing the ground
work now, but the future is bright.

\start
Date: Sat, 19 May 2007 20:18:41 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: re: fixing SPAD

Martin Rubey wrote:
> "combinations of predicates through usual logical operators." *are* allowed.
> Only, in the context of conditional exports, predicates are limited to "is" and
> "has".
> 
> Aldor, in contrast, makes no (or maybe, not much) difference to other parts of
> the code here.
> 
> Thus, my question is, would it be easy, or at least, doable for you, to make
> SPAD behave like Aldor here, i.e. drop the restriction on the predicates
> allowed?
>

There is a fundamental difficulty: theory of integers is undecidable, so
if you just add integer predicates to a dependent type system in style
of Barendregt book "Lambda calculi with types" you are likely to get
undecidable typesystem.

So, to get practical compiler you need to compromise.  I see some
possibilities here:

1) Defer typechecking to runtime
2) Reject some programs that are allowed by Barendregt style typesystem
3) Change point of view: instead of talking about types talk about 
   predicates (properties) satisfied by values in your program.
   Claiming that property holds is a mathematical theorem, so it
   requires a proof.  And programmer should write the proof together
   with the program.

I belive that Aldor goes for 1) (probably combined with unsoundness
in type system).  

In can imagine reasonable version of 2).  It should check each constructor
separately, and replace each predicate by combination of boolean
variables.  For each combination of values of boolean variables
the compiler should check if given variant is type-safe.  If all
variants are type safe the compiler should accept the program,
otherwise fail it.  Note that for various reasons values of predicates
may be dependent and some combinations of values may be excluded.
IIUC Barendregt style typesystem may notice some dependencies,
so it effectively will skip some impossibel combinations.  If possible
combinations type-check fine, but an impossible one fails then
Barendregt will accept the program but our rule will reject it.

Checking all variants may be expensive (if checking single variant
is linear the whole thing is co-NP), but we can hope that hard
cases will rarely occur.  BTW: It seems that Spad is already
doing similar thing with conditionals.

 
> > For a given specific case, one might look for a workaround that simulates
> > type checking at runtime.
> 
> I doubt this.  Of course, using Waldek's idea we could say that 'Complex F' is
> only allowed if either F is not a field or x^2+1 is irreducible in F.  But I'm
> not sure if that's what we want.  And I doubt that you can achieve what I first
> proposed in current SPAD, namely, make 'Complex F' export 'Field' only if x^2+1
> is irreducible in F.
>

I think that runtime checking idea is to allow Complex F, but when one
uses it as a Field check at runtime if it is ineded a Field (and signal
error if not).  I suspect that Spad is doing this already, but only
with conditions which it allows.
 
> I guess, your answer (whether it would be "easy"), is "no"...
> 

Doing thins Aldor way should be moderatly hard, say like implementing
extend.  It requires some real work and will not happen overnight.

Doing Barenrdregt style typesystem with arbitrary predicates?  Well,
this is a research problem.

\start
Date: 19 May 2007 20:59:29 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: re: fixing SPAD

Waldek Hebisch writes:

> So, to get practical compiler you need to compromise.  I see some
> possibilities here:
> 
> 1) Defer typechecking to runtime
> 2) Reject some programs that are allowed by Barendregt style typesystem
> 3) Change point of view: instead of talking about types talk about 
>    predicates (properties) satisfied by values in your program.
>    Claiming that property holds is a mathematical theorem, so it
>    requires a proof.  And programmer should write the proof together
>    with the program.

> Doing thins Aldor way should be moderatly hard, say like implementing
> extend.  It requires some real work and will not happen overnight.

OK, so I'll probably have to wait for a reasonably free Aldor compiler... :-(

> Doing Barenrdregt style typesystem with arbitrary predicates?  Well,
> this is a research problem.

I guess we should forget about that one for the moment :-)

> I think that runtime checking idea is to allow Complex F, but when one uses
> it as a Field check at runtime if it is ineded a Field (and signal error if
> not).  I suspect that Spad is doing this already, but only with conditions
> which it allows.

Quite right, this is nearly a workaround: in every function in Complex
depending on Complex F being a field we could check whether it really is.  This
doesn't trap usage outside of Complex F, though - unless one uses one of the
"Field" functions.  It's good enough, given that we do not have a free Aldor,
I'd say.

\start
Date: Sat, 19 May 2007 21:17:40 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Aldor -> Lisp/C	was: Re: Literate documentation

> Off topic, but a question about Aldor - if you compile Aldor routines
> into c and build that c code, can other Aldor routines compiled into
> Lisp still interact with the compiled c based modules?  Does Aldor
> enforce compatibility?

First. I have never tried, so I don't know.
Second. The important thing are Aldor's .ao files (platform independent 
object files). From them you can generate .c or .lisp.
Third. I believe since GCL translates to C, then there should be a way 
to call libraries that just go the .as -> .ao -> .c -> .o compilation way.

Maybe somebody more knowledgable from the aldor-l mailing list (I've 
CC'ed) can answer that question more accurately.

\start
Date: 19 May 2007 14:58:53 -0500
From: Gabriel Dos Reis
To: list
Subject: parenthesis

Currently, Boot (new or old) supports '(|' and '|)' as alternate
spellings for round parenthesis '(' and ')'.  I think we should
drop support for such digraphs -- no Boot fundamental code is
affected.

\start
Date: Sat, 19 May 2007 20:25:04 -0500
From: Tim Daly
To: list
Subject: Silver

SILVER

The latest, merged version will momentarily be available as
a silver version. 

It contains my attempt to merge the various versions. It is a couple
months behind "the leading edge" so not everything got picked up. It
does not contain the new GNU autoconf mechanism yet because (a) I don't
understand it and (b) it isn't documented to a level that a new
developer could begin to change it.

I picked up all of the changes I understood and left others alone.



REGRESSION TESTING

Silver contains 2 new tools for regression testing the system. 

First, I've written a regression program for the input files so we can
easily spot input file failures automatically (the results are stored
in "regress" files in the int/input directory). I've rewritten many of
the src/input files into the new format. Basically these files store
the expected result of a computation in a specially constructed comment.
The code and its associated documentation is in src/interp/regress.lisp
The new input files contains lines that read:

--S n of m                       <== this starts a test
(some axiom command)             <== the command to test
--R                              <== the expected results
--R the axiom output
--E n                            <== the end of the test

As each input file is run the actual results are compared with
the expected results and the pass/fail information is written
to a regress file. So

foo.input.pamphlet -> foo.input -> foo.output -> foo.regress

Also, removing the int/input subdir and rerunning make will now
rerun all of the input files.



Second, I've written a global regression check that uses md5 hashing
to find changed files. This is automated in the src/regress/REGRESS
script. This script rebuilds axiom and then computes the md5 hash
for each file and compares it to the stored md5 hash. Thus any change
in a file will generate a different hash code. This allows us to see
what effect each change has on every file in the system. So

src/regress/REGRESS is a shell script to clean the system, remake
the system, and then compute the md5 hash into allnew.md5 with one
hash line per file. Finally we compre allnew.md5 with src/regress/all.md5
and any differences mean that the file was changed. This simple system
is useful to see what a change potentially breaks.

It also sends mail when the build completes so you might want to
change the last line to send the mail to your own userid. This
is useful if you kick off a build and go to work.



ALGEBRA

Silver does not contain all of the algebra changes. I have been pondering
ways to ensure that the algebra does not break. We don't want to fix
one thing and break others so I'm taking a very conservative approach.

I think we might need an algebra-change review board of some sort.
I know I'm not competent to judge all of the algebra changes. 

I also believe that changing an algebra file should be accompanied by
a larger effort at documenting that particular file. After all, if
we've spent the time to isolate a problem we can profit by writing
down the things that we know about the algebra despite the time and
overhead it might take.  We also need associated unit-tests for each
function and regression tests for expected output.

One new algebra file was documented (quat.spad) and more work will
go into the documentation. I hope to have the spad input lines
automatically executed as part of an automated test suite generated
directly from the pamphlet files. This is not yet published but is
a work in progress.




LOCATION

The silver version is in two places, SVN and git, and I'll be continuing 
development against both places in parallel. It is not yet ready to 
become Gold.

THE SVN VERSION

I put the silver version into daly/axiom on sourceforge. It will
be changed regularly from now on. Please look at it and propose
changes (with diff-Naur). 

THE GIT VERSION

I've put up a git repository of the current "silver" version
of Axiom. In order to use this you need either an ssh-key or
you can use git's password (linus). If you already have an ssh-key
register on axiom-developer.org you should be able to clone.
If you don't want to use the password you can send me an ssh-key. Do:
   ssh-key -t dsa
and send me the generated file (your .ssh/id_dsa.pub)

Everyone has read/write access to this repository.


WHY?

If you watched the video link I sent you know that git is a fully
distributed development system, unlike arch, cvs, or svn. Thus
every copy is a "root" copy and no copy is special, except by
convention. This differs considerably from the "star"-network,
master-repository view. Thus you all have THE silver version.

See <http://git.or.cz>

The seed repository is on axiom-developer.org under the user 'git'.
You can get your own repository with:

git-clone ssh://git@axiom-developer.org/home/git/silver silver

Once you do this you can make modifications to this tree.




YEAH, BUT WHY?

Well, git is fast. And git allows you to do work quite easily in
multiple branches simultaneously. So each branch can be a separate
idea.  Branches are dirt-cheap (a few bytes). And git is blindingly
fast. And git does not store a duplicate copy, nor does it copy files
so it uses less than half the space. Did I mention git is unbelievable
fast? etc., etc., etc... all the usual religious noise.




YEAH, BUT SERIOUSLY, WHY?

Because git eliminates me from being "special" in the world
of development. CVS and SVN put the repository in the center 
of the world and everyone has to play. With git the whole idea
of a "silver" version becomes a non-issue. So I'm no longer
the single point of failure. In a fully distributed system there
is no single point of failure.

Now all I need to do to get a changeset is to "pull" from your
repository and the merge is done automatically. Now you have
the master copy and I just bring my copy up to date. Sweet, no?

Git will change the way you work to something much better.




HOW?

1) get the code
  git-clone ssh://git@axiom-developer.org/home/git/silver silver

  the clone is a full, independent git repository. people can clone
  your whole repository, pull changes from your repository, or push
  changes to your repository. thus you are the center of the world.

2) branch the code
  git-branch mybranch

  if you work on a single problem (eg an algebra bug) in a single
  branch you will naturally accumulate a changeset. since git will
  not copy files the branch is only a few bytes big. you can have
  as many branches as you wish so each branch can be a single idea
  or problem.

3) list the branches
  git-branch

  you can see all of the branches you have created

4) change to the new branch
  git-checkout mybranch

  if mybranch is related to one single change then you can work
  on that change locally independent of all other work.

5) change something
  echo "it works" >>FAQ

  here we modify the FAQ file

6) remember the change
  git-add test

  NOTE: git does not know about files, it knows about changes.
  If you change something you need to tell git you want to add that
  change to the set of changes to keep. So "git-add" means ADD THE
  CHANGE, NOT ADD THE FILE. git only cares about content. it does
  not track files. This is different from other source code control.

7) commit the change on this branch
  git-commit -a -m"mybranch test"

  All of the changes we have made (and have selected with git-add)
  will be collected into a commit. The -a says to take them all and
  the -m is an inline comment.

  Notice that commit does NOT use the network since you ARE
  the master copy and this is a local branch.

8) change to the master branch
  git-checkout master

  Now that we've made our glorious change in isolation it is time to
  merge it back onto the main tree. So first we switch to the master
  tree (or whatever tree we want)

8) merge the branch
  git-merge mybranch

  And we merge the master and mybranch trees

9) see what changed
  git-log

  We can see what changed. The commit log tag can tell you a lot of
  detail. Notice that there are lines that read something like:

  commit 1e6bb35c9089a197513decd4e988381205120260
  ...
  commit 731bed1e6bb35c9089a197513decd4e988381205
  ...

10) see the details of a change
  git-show 731bed

  This shows you the change 731bed1e6bb35c9089a197513decd4e988381205

  Notice that you can abbreviate the long md5 hash numbers as long as
  they are unique. The md5 hash algorithm is even and almost always unique
  so very short numbers suffice. You can also make up your own names
  (say v3.2) and use them instead. RTFM.

11) see the change in a range of changes
  git-diff 1e6bb3--731

  This will show you a diff -Naur difference within this range

12) commit the change
  git-commit -a

  We commit the changes locally so they will be remembered. 
  Notice that commit does NOT use the network since you ARE
  the master copy.

13) delete the branch
  git-branch -d mybranch

  We've solved the problem so clean up the pile.

14) push the change back to axiom-developer.org
  git-push

  If you wish you can reach out and change the repository on 
  axiom-developer.org with our changeset. You can also "push" to
  someone else's repository. Or they can "pull" from yours. So
  all you need to do is skip this step, post a message on 
  axiom-developer, and let me pull your changeset.

\start
Date: Sat, 19 May 2007 20:26:03 -0500
From: Tim Daly
To: list
Subject: Community

COMMUNITY

Having just spend the last 3.5 months trying to construct a merger of
Waldek's version, Gaby's version, my work, and the Gold version I find
this whole process very tedious.  The SVN versions have diverged
wildly in structure from the Arch/CVS versions and the time has come
to restructure the way we work.

Its fine to have your own branch and its fine to experiment with new
ideas. But we don't seem to be acting as a "community".  The primary
evidence is the frequent reference to "Waldek's Version" or "Gaby's
Version" or the "Gold Version", as if in competition.

This isn't the way that "community-based" projects work. I don't ever
recall anyone suggesting "Bob's GCC" or "Jane's Mozilla" or "Bill's
Apache". If you want a change to GCC you need to work as part of a
community and get the change accepted into the savannah sources.

There are "versions" in Linux. You can get a copy of Andrew Morton's
version of the kernel. You can build your own kernel.  You can get
specialized kernels for special machines. But, in general, when
referring to "the kernel" you are referring to the one maintained by
linus at kernel.org. Linus is not going to reach out to your special
version and try to merge it.

The Axiom Gold version lives in Arch on axiom-developer.org and is
also publicly mirrored into CVS at sourceforge and CVS at savannah.

Following the linux model some portion of your time needs to be spent
"packaging" your changes so they can fit into Axiom. Without this
effort you are fragmenting the very small community we have.

The process for "packaging" changes has been well documented for a
number of years. This involves collecting up a group of changes, such
as the elimination of prototypes, into a changeset that can be applied
against Gold. These are published as a set of diff -Naur changes.

So far I have seen no changesets against Gold, no "packaging" effort,
no community-directed effort.

Please give some thought to community-directed effort.

\start
Date: Sat, 19 May 2007 21:36:24 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: Silver

I think it will be nice to have gitweb on axiom-developer similar to this:

http://git.kernel.org/

On 5/19/07, Tim Daly wrote:
> SILVER
>
> The latest, merged version will momentarily be available as
> a silver version.
>
> It contains my attempt to merge the various versions. It is a couple
> months behind "the leading edge" so not everything got picked up. It
> does not contain the new GNU autoconf mechanism yet because (a) I don't
> understand it and (b) it isn't documented to a level that a new
> developer could begin to change it.
>
> I picked up all of the changes I understood and left others alone.
>
>
>
> REGRESSION TESTING
>
> Silver contains 2 new tools for regression testing the system.
>
> First, I've written a regression program for the input files so we can
> easily spot input file failures automatically (the results are stored
> in "regress" files in the int/input directory). I've rewritten many of
> the src/input files into the new format. Basically these files store
> the expected result of a computation in a specially constructed comment.
> The code and its associated documentation is in src/interp/regress.lisp
> The new input files contains lines that read:
>
> --S n of m                       <== this starts a test
> (some axiom command)             <== the command to test
> --R                              <== the expected results
> --R the axiom output
> --E n                            <== the end of the test
>
> As each input file is run the actual results are compared with
> the expected results and the pass/fail information is written
> to a regress file. So
>
> foo.input.pamphlet -> foo.input -> foo.output -> foo.regress
>
> Also, removing the int/input subdir and rerunning make will now
> rerun all of the input files.
>
>
>
> Second, I've written a global regression check that uses md5 hashing
> to find changed files. This is automated in the src/regress/REGRESS
> script. This script rebuilds axiom and then computes the md5 hash
> for each file and compares it to the stored md5 hash. Thus any change
> in a file will generate a different hash code. This allows us to see
> what effect each change has on every file in the system. So
>
> src/regress/REGRESS is a shell script to clean the system, remake
> the system, and then compute the md5 hash into allnew.md5 with one
> hash line per file. Finally we compre allnew.md5 with src/regress/all.md5
> and any differences mean that the file was changed. This simple system
> is useful to see what a change potentially breaks.
>
> It also sends mail when the build completes so you might want to
> change the last line to send the mail to your own userid. This
> is useful if you kick off a build and go to work.
>
>
>
> ALGEBRA
>
> Silver does not contain all of the algebra changes. I have been pondering
> ways to ensure that the algebra does not break. We don't want to fix
> one thing and break others so I'm taking a very conservative approach.
>
> I think we might need an algebra-change review board of some sort.
> I know I'm not competent to judge all of the algebra changes.
>
> I also believe that changing an algebra file should be accompanied by
> a larger effort at documenting that particular file. After all, if
> we've spent the time to isolate a problem we can profit by writing
> down the things that we know about the algebra despite the time and
> overhead it might take.  We also need associated unit-tests for each
> function and regression tests for expected output.
>
> One new algebra file was documented (quat.spad) and more work will
> go into the documentation. I hope to have the spad input lines
> automatically executed as part of an automated test suite generated
> directly from the pamphlet files. This is not yet published but is
> a work in progress.
>
>
>
>
> LOCATION
>
> The silver version is in two places, SVN and git, and I'll be continuing
> development against both places in parallel. It is not yet ready to
> become Gold.
>
> THE SVN VERSION
>
> I put the silver version into daly/axiom on sourceforge. It will
> be changed regularly from now on. Please look at it and propose
> changes (with diff-Naur).
>
> THE GIT VERSION
>
> I've put up a git repository of the current "silver" version
> of Axiom. In order to use this you need either an ssh-key or
> you can use git's password (linus). If you already have an ssh-key
> register on axiom-developer.org you should be able to clone.
> If you don't want to use the password you can send me an ssh-key. Do:
>    ssh-key -t dsa
> and send me the generated file (your .ssh/id_dsa.pub)
>
> Everyone has read/write access to this repository.
>
>
> WHY?
>
> If you watched the video link I sent you know that git is a fully
> distributed development system, unlike arch, cvs, or svn. Thus
> every copy is a "root" copy and no copy is special, except by
> convention. This differs considerably from the "star"-network,
> master-repository view. Thus you all have THE silver version.
>
> See <http://git.or.cz>
>
> The seed repository is on axiom-developer.org under the user 'git'.
> You can get your own repository with:
>
> git-clone ssh://git@axiom-developer.org/home/git/silver silver
>
> Once you do this you can make modifications to this tree.
>
>
>
>
> YEAH, BUT WHY?
>
> Well, git is fast. And git allows you to do work quite easily in
> multiple branches simultaneously. So each branch can be a separate
> idea.  Branches are dirt-cheap (a few bytes). And git is blindingly
> fast. And git does not store a duplicate copy, nor does it copy files
> so it uses less than half the space. Did I mention git is unbelievable
> fast? etc., etc., etc... all the usual religious noise.
>
>
>
>
> YEAH, BUT SERIOUSLY, WHY?
>
> Because git eliminates me from being "special" in the world
> of development. CVS and SVN put the repository in the center
> of the world and everyone has to play. With git the whole idea
> of a "silver" version becomes a non-issue. So I'm no longer
> the single point of failure. In a fully distributed system there
> is no single point of failure.
>
> Now all I need to do to get a changeset is to "pull" from your
> repository and the merge is done automatically. Now you have
> the master copy and I just bring my copy up to date. Sweet, no?
>
> Git will change the way you work to something much better.
>
>
>
>
> HOW?
>
> 1) get the code
>   git-clone ssh://git@axiom-developer.org/home/git/silver silver
>
>   the clone is a full, independent git repository. people can clone
>   your whole repository, pull changes from your repository, or push
>   changes to your repository. thus you are the center of the world.
>
> 2) branch the code
>   git-branch mybranch
>
>   if you work on a single problem (eg an algebra bug) in a single
>   branch you will naturally accumulate a changeset. since git will
>   not copy files the branch is only a few bytes big. you can have
>   as many branches as you wish so each branch can be a single idea
>   or problem.
>
> 3) list the branches
>   git-branch
>
>   you can see all of the branches you have created
>
> 4) change to the new branch
>   git-checkout mybranch
>
>   if mybranch is related to one single change then you can work
>   on that change locally independent of all other work.
>
> 5) change something
>   echo "it works" >>FAQ
>
>   here we modify the FAQ file
>
> 6) remember the change
>   git-add test
>
>   NOTE: git does not know about files, it knows about changes.
>   If you change something you need to tell git you want to add that
>   change to the set of changes to keep. So "git-add" means ADD THE
>   CHANGE, NOT ADD THE FILE. git only cares about content. it does
>   not track files. This is different from other source code control.
>
> 7) commit the change on this branch
>   git-commit -a -m"mybranch test"
>
>   All of the changes we have made (and have selected with git-add)
>   will be collected into a commit. The -a says to take them all and
>   the -m is an inline comment.
>
>   Notice that commit does NOT use the network since you ARE
>   the master copy and this is a local branch.
>
> 8) change to the master branch
>   git-checkout master
>
>   Now that we've made our glorious change in isolation it is time to
>   merge it back onto the main tree. So first we switch to the master
>   tree (or whatever tree we want)
>
> 8) merge the branch
>   git-merge mybranch
>
>   And we merge the master and mybranch trees
>
> 9) see what changed
>   git-log
>
>   We can see what changed. The commit log tag can tell you a lot of
>   detail. Notice that there are lines that read something like:
>
>   commit 1e6bb35c9089a197513decd4e988381205120260
>   ...
>   commit 731bed1e6bb35c9089a197513decd4e988381205
>   ...
>
> 10) see the details of a change
>   git-show 731bed
>
>   This shows you the change 731bed1e6bb35c9089a197513decd4e988381205
>
>   Notice that you can abbreviate the long md5 hash numbers as long as
>   they are unique. The md5 hash algorithm is even and almost always unique
>   so very short numbers suffice. You can also make up your own names
>   (say v3.2) and use them instead. RTFM.
>
> 11) see the change in a range of changes
>   git-diff 1e6bb3--731
>
>   This will show you a diff -Naur difference within this range
>
> 12) commit the change
>   git-commit -a
>
>   We commit the changes locally so they will be remembered.
>   Notice that commit does NOT use the network since you ARE
>   the master copy.
>
> 13) delete the branch
>   git-branch -d mybranch
>
>   We've solved the problem so clean up the pile.
>
> 14) push the change back to axiom-developer.org
>   git-push
>
>   If you wish you can reach out and change the repository on
>   axiom-developer.org with our changeset. You can also "push" to
>   someone else's repository. Or they can "pull" from yours. So
>   all you need to do is skip this step, post a message on
>   axiom-developer, and let me pull your changeset.

\start
Date: 19 May 2007 20:51:08 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Community

Tim Daly writes:

| COMMUNITY

It is good to see you're back to community effort.

By far my largest beef about this Axiom project is that it is 
*unfocused*.  It is probably the only unfocused open source
project I've ever worked on.

The patient archeologist might go back a year ago and traces activity,
discussions, around the Axiom project since then and see why and how
we get to the place we're contemplating today.

WRT to GCC, yes there are many versions of GCC floating around: FSF
GCC, Red Hat GCC, SuSE GCC, CodeSourcery GCC, Apple GCC, etc.  
However, all of them co-operate to get FSF GCC move forward.  Because,
they all agree what the mainstream GCC should be.

Don't try to blame the current active branches as fragmenting the
small, unfocused community. 

I can't speak for Waldek, but it certainly is not my intent to have 
a Gaby Axiom.  Such an extreme situation would happen only if we
cannot agree on working on a community project.  I've always
considered Axiom.build-improvements as a community effort, and I'm
glad to see it served others, e.g. Waldek's branch of Gregory's
private work.

Please, update our website and document what branch of Axiom is now
considered Silver.

[...]

| The Axiom Gold version lives in Arch on axiom-developer.org and is
| also publicly mirrored into CVS at sourceforge and CVS at savannah.

If you want community, focused, project you really want to limit the
number of official "sources".  In particular, you really want to
mirror Axiom Gold at sourceforce SVN.

And you don't want to release Axiom once in a while, if you want a
focused community.  You want to release early, you want to release
often. 

\start
Date: 19 May 2007 21:06:47 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Community

Tim Daly writes:

[...]

| The process for "packaging" changes has been well documented for a
| number of years. This involves collecting up a group of changes, such
| as the elimination of prototypes, into a changeset that can be applied
| against Gold. These are published as a set of diff -Naur changes.

You would need to make room for incremental changes. 

For example, moving to Autoconf-base build machinery involves so many
changes that it would be impratical to present everything at once and
review it in full scale.  You'd need to make room for incremental
changesets, where at any given stage we have moved forward, the
system is still stable; and at the end of the series of changesets we
have completed the switch.

\start
Date: Sat, 19 May 2007 20:15:00 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Community

Tim, I think part of the difficulty here is that there is no universal
consensus about direction yet, so the community is still testing
various possibilities.

For example, I am currently looking into ASDF with the idea of teaching
it how to load pamphlet files.  (A tad harder than I had hoped, but I
think it can be made to work.)  If that is possible, and cl-web grows
all the necessary features, it should be possible to have a lisp-only
asdf based build mechanism for all parts of Axiom defined in Lisp, Boot
or SPAD. E.g. the boot/shoe compiler could be described by something
like (I suppose the files are wrong):

(defsystem #:boot
  :name "BOOT Language Compiler"
  :author "The Axiom Team"
  :version "1.0"
  :components
  ((:module "BOOT-BOOTSTRAP"
            :pathname #.(make-pathname :directory '(:relative "src"
"boot"))
            :components
            ((:cl-pamphlet "ptyout" :chunk "ptyout.clisp")
             (:cl-pamphlet "btincl2" :chunk "btincl2.clisp")
             (:cl-pamphlet "typrops" :chunk "typrops.clisp")
             (:cl-pamphlet "btpile2" :chunk "btpile2.clisp")
             (:cl-pamphlet "btscan2" :chunk "btscan2.clisp")
             (:cl-pamphlet "typars" :chunk "typars.clisp")
             (:cl-pamphlet "tytree1" :chunk "tytree1.clisp")))
    (:module "BOOT"
            :pathname #.(make-pathname :directory '(:relative "src"
"boot"))
            :components
            ((:boot-pamphlet "ptyout" :chunk "*")
             (:boot-pamphlet "btincl2" :chunk "*")
             (:boot-pamphlet "typrops" :chunk "*")
             (:boot-pamphlet "btpile2" :chunk "*")
             (:boot-pamphlet "btscan2" :chunk "*")
             (:boot-pamphlet "typars" :chunk "*")
             (:boot-pamphlet "tytree1" :chunk "*"))))

And so on for the rest of Axiom.  This would mean traditional asdf
commands could be used to build parts or all of Axiom.  (Maxima uses
defsystem in a similar fashion, although of course they don't have to
worry about pamphlets.)

Even if I do get this working however, the community may not care for
it.  Gaby has put a great deal of work into autoconf (which IS in
essence a competing solution, and has the considerable merit of already
working), and the above system would almost certainly require a
properly working ANSI lisp.  It would replace those parts of the
current build systems that use Makefiles to build lisp, boot or spad. 
The dumping of images is another sticky point I haven't gotten to yet. 
Some folks seem inclined to avoid Lisp as much as possible.

So you see the difficulty.  Even if I succeed preparing cl-web+asdf
extensions as a working alternative, the community may decide against
it.  But it is part of where I personally would like to see Axiom head,
so I'm doing what I can to make it work.

There are other issues.  bookvol5 style code grouping vs. "conference
proceeding" style volumes on topics vs. *other-favorite-method*, for
example.  We have had very interesting discussions on these issues but
I don't really see a consensus forming yet.  Personally I want to try
out some mechanisms to see how well they work.

Bibliography issues need to be resolved, and I'm still working on how
best to handle that issue.

\start
Date: 19 May 2007 22:30:35 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Community

Cliff Yapp writes:

[...]

| Even if I do get this working however, the community may not care for
| it.  Gaby has put a great deal of work into autoconf (which IS in
| essence a competing solution, and has the considerable merit of already
| working), and the above system would almost certainly require a
| properly working ANSI lisp.

I don't care replacing the Autoconf-based build system with something
better; and if your system is better I'll lobby to use it.

I however have fundamental objections to any move to burry Axiom
deeper into a second class build system, and second class galaxy.

If we ever want to attract more people to Axiom, the least thing we
want is to paint ourselves into an exoteric ghetto. 

Please give a thought to why we don't seem to attract new blood to
Axiom.  It is not that it is that difficult.  I've seen new blood in
the more challenging and difficult GCC system. 

\start
Date: 19 May 2007 22:38:39 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] eval-when and package call syntax

Boot (old or new) uses the syntax

   (eval-when(load eval) ....)

for translation of variable definitions at file scope.  
ANSI Lisp says that the situations 'load' and 'eval' are deprecated,
and one should use :load-toplevel and :execute instead.
So I changed new Boot to use that syntax.

To make the Boot implementation self-contained, I added support for
the syntax `package::name' where the symbol `name' is to be found
(therefore interned) in `package'.  Note that this syntax and
semantics already exist in old Boot.  This is one more place where
Boot syntax differs from Spad syntax.  

The new syntax is available at revision 552.

\start
Date: Sat, 19 May 2007 23:53:24 -0500
From: Tim Daly
To: Alfredo Portes
Subject: gitweb

Jose,

For gitweb try: <http://git.axiom-developer.org>

Would you care to be the first person to try to clone the git repo?

\start
Date: Sat, 19 May 2007 21:54:57 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Community

--- Gabriel Dos Reis wrote:

> I don't care replacing the Autoconf-based build system with something
> better; and if your system is better I'll lobby to use it.

My guess is the optimal system would be something similar to what
Maxima does - let the lisp asdf system handle the parts that can be
done in lisp, and the autotools system handle the parts outside of
lisp.  This is particularly true if we want to include and build gcl. 
Maxima's core parts (i.e. the lisp based code) can be built using only
lisp, and this is very useful in some development situations, but the
normal method is ./configure --enable-*lisp*, make, make install.  I
THINK this triggers the lisp system for that part of the build, which
must be done to bootstrap in any case.  Lisp build systems with
external triggers appropriate to the environment allow an encapsulation
of large parts of the build logic in a system that is insensitive to
system changes.

Maxima does this; I'm not sure about other applications of the
technique.
 
> I however have fundamental objections to any move to burry Axiom
> deeper into a second class build system, and second class galaxy.

I may be alone in this, but I don't view Lisp as "second class."  It is
a language with a long usage history, particularly in the domain of
problem we happen to be working on.  Someone on the list described it
as "assembly code" - that's actually not a bad thing in some
situations, and for others (like SPAD for mathematics) Lisp is
excellent for implementing languages to meet specific problem domains
(I believe Paradigms of AI Programming, one of the major lisp
references, illustrates that.)

As for ASDF, it is far and away the most widely used build system in
the Lisp world today - most modern libraries come with an asdf build
definition file.  Conceptually it inherits a lot from defsystem, but it
modernizes some of the design decisions and doesn't try to support
non-ANSI lisps.  The whole of the ASDF source code is 19 pages. 
Extensions needed for pamphlet files I'm not sure of yet, but those
will be part of Axiom and documented in literate fashion.

> If we ever want to attract more people to Axiom, the least thing we
> want is to paint ourselves into an exoteric ghetto. 

Of course, but I don't think Lisp qualifies as a ghetto.  It has a very
long track record and has stood the test of time quite well, in my
opinion.

> Please give a thought to why we don't seem to attract new blood to
> Axiom.  It is not that it is that difficult.  I've seen new blood in
> the more challenging and difficult GCC system. 

GCC is very general purpose (and widely depended upon), and equally
important perhaps it is very widely known.  Without GCC free software
as we know it wouldn't exist.  That attracts attention.

Right now, Axiom runs by default on non-ANSI lisp.  THAT version of
lisp is a ghetto, and is why I view moving to ANSI common lisp as a
step of major importance.  Dealing with non-ANSI lisp issues is not
going to attract many people.  Any old, non-standard source code has
similar issues.  Maxima gets slightly more activity than we do, but
they had a few years head start and are more portable at the present
time.  Even there, I think most of the active Maxima developers are
familiar names.  It would be interesting to look at number of new
developers acquired by more specialized open source projects over time,
to see what a common acquisition rate is.  (BRL-CAD might be a good
comparative example.)

SAGE is attracting a lot of attention, but if I understand it correctly
it's a meta-system that combines other systems to get a more powerful
environment.  That approach is quick (relatively speaking) and you get
a lot of bang for the buck programming wise.  That combination attracts
people.  Axiom's goals are somewhat different, which is one of the
things that attracts me to the project.

Shaking our reputation as "the hard CAS" would probably do the most
good as far as attracting people, but I'm not sure how practical that
is.

\start
Date: Sun, 20 May 2007 00:06:42 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Literate ASDF

> For example, I am currently looking into ASDF with the idea of teaching
> it how to load pamphlet files.  (A tad harder than I had hoped, but I
> think it can be made to work.)  If that is possible, and cl-web grows
> all the necessary features, it should be possible to have a lisp-only
> asdf based build mechanism for all parts of Axiom defined in Lisp, Boot
> or SPAD. E.g. the boot/shoe compiler could be described by something
> like (I suppose the files are wrong):

Literate supporting ASDF loads.... what a truly awesome idea.

That would mean that the literate idea could be spread to the
rest of the lisp community. Then literate files could be remotely
hosted ASDF files and drag-and-drop becomes so much easier.

That idea collapses whole layers of complexity out of the build tower.
The build would amount to ASDF-loading the interpreter, the compiler,
and the algebra. Very, very sweet.

Even if we can't make it work I'm impressed with the idea.

\start
Date: Sun, 20 May 2007 01:21:13 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: gitweb

Sure. Really nice. Thank you.

On 5/20/07, Tim Daly wrote:
> Jose,
>
> For gitweb try: <http://git.axiom-developer.org>
>
> Would you care to be the first person to try to clone the git repo?

\start
Date: Sun, 20 May 2007 15:44:27 +1000
From: Alasdair McAndrew
To: list
Subject: New blood in Axiom (was: Community)

Well, I can tell you why I have hesitated about joining the Axiom effort:

1)  Axiom gives the impression of being more difficult and abstruse than
other systems; the moment you get started you are inundated with information
about categories, domains and operations.  This has enormous strength, but
nonetheless makes Axiom appear bewilderingly complicated.

2)  The online documentation is very poor.  HyperDoc (which is itself
incomplete) under unix, and some confusing system commands such as ")d op
differentiate", ")wh th int" which produce output meaningless to the
beginning user.  There are the books, but they are no substitute for good
online help.

3)  There is not much in the way of a decent user interface.  I think
TeXmacs and console is about it?  And HyperDoc isn't obtainable from
TeXmacs.

4)  It doesn't seem to be particularly cross-platform.

5)  There seems to be some lack of cohesion amongst the Axiom developers as
to the direction in which Axiom should go.

I must admit that my main interest is in mathematics education, in which I
think a GPL CAS has enormous potential.  But at the moment I think Maxima is
ahead of Axiom on all the points I have mentioned.

-Alasdair

\start
Date: Sun, 20 May 2007 01:45:07 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Literate documentation

BTW. I am omitting Ed Ream's email address for now since his
inclusion in the Cc was uninvited and he has not replied so
far. I do not wish to appear to be "spamming" him with this
debate. I can always communicate the results to him later if
it seems relevant.

On May 19, 2007 8:35 AM Ralf Hemmecke wrote:
> ... 
> OK. But I am not convinced anymore that switching to LEO
> is such a big step forward. If the Axiom code ends up by
> something that looks like LeoPy.leo and this is understood
> as a literate program, then I would say I don't understand
> the code and the ideas behind it.
>

I did not say that Leo is a big step forward. What I said was
that it was an alternative to the monolithic book (Knuth)
style of literate programming. I personally would have not
problem at all if Axiom code looked something like this and
I certainly would consider it much more literate than Axiom
is now.

> LeoPy.leo is *not* a literate program, rather it is a program
> whose reading order is perhaps a bit different than the
> compilation order, but otherwise I miss a lot that drives
> people to write understandable code.

I *strongly* disagree. What do you think "Diary", "Notes",
"To do" and "(Project Views)" have to do with a conventional
non-literate program?

"Diary" is essentially a detailed change log. Axiom has a file
devoted to this (oddly perhaps Axiom's ChangeLog is not a
pamphlet format file). Leo's Diary nodes are considerably more
detailed than Axiom's change log.

"Notes" includes sub-nodes like: "About packages", "Announcements",
"Distribution checklist", "Leo and CVS", etc.

"To do" includes a section on "Known Bugs" and plans for "Later
versions" of Leo.

"(Project Views)" shows views of the outline related to specific
projects or tasks. It also contains some new or experimental
code that is not part of the current version of Leo.

All of these nodes contain extensive documentation and often
references active code in Leo via the clone mechanism.

Finally there is the "Code" section that contains the actual
source code of Leo. It begins with a section heading "Overview
of the code", there is also a section titled "Customizing Leo",
etc.

As far as I can see everything "that drives people to write
understandable code" is here, and more!

> And understandable code is, to a great deal, independent of
> the underlying programming language.

Yes of course.
 
> In fact, a literate program should make it very easy to
> translate a program written in one language into another
> language.

At least possible, yes but "very easy" might be an exaggeration.
I don't see anything missing in LeoPy.leo in this regard.

> 
> Maybe that is not the only guiding sentence behind LP, but
> when one documents and thinks about that, then one probably
> adds more documentation explaining the tricks needed for the
> particular language and also the goal that this or that piece
> of code actually serves. In the end a literate program might
> survive even a change in the underlying programming language.
> 

Ok. Actually as I understand it the first version of Leo was
actually written in C++ and later re-written in Python.

> ... 
> > Anyway I am thinking that we should start with something like
> > this:
> > 
> >   1) It should be possible to import a noweb file into and run
> >      Leo's weave command to produce an output file identical
> >      to that produced by applying noweave to the original file.
> > 
> >   2) After adding the necessary @root attribute, it should be
> >      possible to run Leo's tangle command to produce an output
> >      file identical to that produced by applying notangle to
> >      the original file.
> > 
> >   3) After importing a noweb file into Leo, saving it in Leo
> >      format and after opening it at a later time it should be
> >      possible to edit the file in Leo and then export the file
> >      to noweb. From the exported noweb file it should be
> >      possible to generate the same weave and tangle outputs
> >      using noweb noweave and notangle.
> > 
> > In other words, this would make Leo a kind of interactive
> > replacement for noweb.
> 
> My way of connecting noweb with something like LEO are a bit 
> different. I don't want to see myself exporting from .leo to
> .nw then call noweave+latex to get .dvi. (The tangle part can
> probably be done from within LEO.)

I did not mean to give the impression that this would be the
normal way of interacting with Leo. What I was trying to do
was to set the standard for what noweb functionality should be
available in Leo by referring directly to equivalent operations
in noweb. Once Leo has this functionality importing and exporting
to and from noweb files becomes irrelevant.

> Rather I would like to have leo work directly on the .nw files.
> A .leo file or rather a kind of index file would keep meta
> information about the outline. Let that have the extension .meta.

What you are editing in Leo *is* the contents of the noweb file.
There is no need to retain the .nw file anymore. If for some
reason you wanted it, you could export the outline (or part of
an outline) to that form.

In other respects, Leo can already operate in an mode in which
generated files are automatically updated when changes are
made in Leo (and vice versa).

> 
> Forgetting for a moment that a .nw file contains LaTeX, then
> there are
> 
> <<blah>>=
> 
> lines that start a code chunk and
> 
> @
> 
> or
> 
> @ %def ...
> 
> lines that start a documentation chunk. If I am not completely
> wrong, that is enough information to split the file into nodes
> where each node contains the documentation that comes right
> before it. (Maybe there is need for a little thought, since
> there might be code chunks that _continue_ previous code
> chunks.)

I think you are right. In fact I think that is more or less
exactly what import from noweb tries to do right now.

> If LEO reads a .meta file, then if finds there lots of 
> references to .nw files together with a precomputed outline
> from the previous save time of the file. LEO checks that the
> outline is not in conflict with the .nw files and reads the
> nodes into its memory. Then work is done as usual in leo.
> Saving any modification, saves the .mete file and all the
> various .nw files. (If the outline changed, then that might
> result in reordering the chunks inside the .nw file.---Maybe
> there should be a special nwfile-outline.)

I don't understand your invention of a ".meta" file. As far as
I can see what you describe is already implemented in Leo but
with somewhat different terminology and omitting the .nw files.

> 
> Now if the .meta file is lost or if someone makes drastic 
> changes to .nw files without using LEO, then most of or
> even all the cloned information is lost. Well, that is sad,
> but one has just lost the views on the code from different
> perspectives.

Again I don't understand .meta files, but the scenario that you
suggest is perhaps possible in Leo. If somehow you were to "lose"
the .leo file but still had all of the associated generated files
it seems clear that what you might not be able to reconstruct from
these generated files might be missing some of the information
which was not presented in any of the generated forms. If Leo
could be extended to support both weave and unweave in the manner
that I suggested in my previous email then I think the missing
information would be very small.

> 
> Before I started to look into LEO, I thought something like
> this scenario can be achieved with LEO. That would probably
> make most of the current Axiom developers happy. Everyone
> can work on .nw (.pamphlet) files as before, and there are
> people who could maintain different perspectives on the
> code+doc base.

It might be possible to build this sort of thing directly on
top of noweb but that is not what Leo does. Still, if we were
to adopt Leo it would be possible for most developers to
effectively continue to work the way they are now since the
contents of the noweb files would be in Leo. Of course there
may always be people like Tim Daly who proclaim that they are
"primitivist" who might reject anything more advanced than a
keypunch machine, but at some point Axiom has to begin to adopt
a 21st century approach if it is to have any longevity at all.
So I don't think this is really relevant.

> 
> Basically, I see LEO as a help to organise the code from a 
> higher level, but I don't want it to mix with the pamphlet
> / noweb structure.

I think trying to make pamphlet files the focus of this sort
of meta tool is wrong. It prevents one from creating the kind
of flexible outline-oriented integrated development environment
that Leo intends to provide.

> 
> > But then things get a little more complicated and interesting.
> > Of course Leo has some features that go beyond that supported
> > by the noweb file format
> 
> What exact features do you like most.
>

1) The detailed outline capability right down to the chunk
level makes the linear monolithic noweb file format obsolete and
allows one to integrate the development of new code together with
day-to-day notes and project plans as they evolve. This is
possible because of node cloning. (As illustrated by LeoPy.leo.)

2) Making it possible to work equally well from the generated
files that are actually used during the test-debug cycle seems
very desirable to me. I think applying the same principle to
the generated documentation (weave) would also make sense.
 
> [snip]
> 
> > Because of Leo's untangle command, it is possible for
> > programmers to edit generated source files and have Leo
> > automatically update the associated Leo files from which
> > they are (normally) generated.
> 
> I wonder if we should make "untangle" a desirable feature. 
> It basically means that you update code and forget about the
> documentation. I tend to say, that hasn't my support.

Of course it is possible to do that now. In fact if you look at
the changes committed to both build-improvements and wh-sandbox,
it is often the case that updating the documentation part of the
pamphlet files lags considerably behind the changes made in the
code chunks. In this case I think the tools should adapt to the
way people really work rather than trying to enforce a specific
discipline by deliberately making certain things harder to do.

> 
> My experience with developing code for Aldor-Combinat with 
> the help of ALLPROSE is that I never felt the need to edit
> the generated .as files  directly. One can easily find oneself
> around in the corresponding .as.nw file. Having need to look
> at code files directly just says that you haven't changed your
> view to programming.

I think there are many reasons why one might want to work
directly with the generated files. For example the error messages
from most compilers (even Aldor) refer to line and character
positions in the code files, not the files (or system) from
which they were generated. Most editing tools (e.g. emacs)
directly support the edit-test-debug cycle this way. Why not
make this as easy and fast as possible. It is usually not
necessary to re-build all the source files with each change.

> 
> With LP-aware debuggers I don't think that the .as or any
> other generated code file is anything else than some generated 
> thing. You can generate any additional information into such
> a file to help a debugger or any other tool to find its way
> back into the actual .as.nw source, but I don't want to look
> at .as files. That is as uninteresting (and only rarely needed)
> as the .c file that can be generated from Aldor sources.
> 

That doesn't make any sense to me. First, I do not know of any
such "LP-aware debuggers" and even if I did, I am not sure that
that would be the only way in which I would test and debug a
program. Second the comparison with .c files generated by Aldor
and GCL is wrong. The code that is being debugged is exactly
the same code that is present in the .nw file (or in the Leo
outline). When one is working intimately with the code to fix
a problem or to implement some new function this code is *all*
that the programming is focusing on. Everything else is retained
in her immediate memory. As a programmer I am quite sure that
this intimate relationship to the code is essential to that
rather mystical sense of "flow" that one feels when things are
going well in a programming session. It makes good sense to
me not to interfere with this but rather let the system take
automatically care of capturing the results.

> > Maybe this would be the best of both worlds.
> 
> Bill, can you state a few items why exactly you think LEO 
> would help Axiom?
> 

I am proposing Leo because it is available now, off-the-shelf
so as to speak. I think it is possible that using outlines in
Leo would help potential new developers understand more quickly
the parts of the code that are of immediate interest to them.
In saying this I am focusing attention on those developers who
want to get into the internals of Axiom.

But Leo outlines can also capture in exact detail the structure
of the Axiom library that is currently displayed only by a tool
like hypedoc. So it seems to me that they also make a perfect
match for someone wishing to write new library code. One of
the things that makes writing good Spad code in Axiom rather
difficult is first of all getting a good understanding of the
detailed structure of the appropriate parts of the existing
library. So I kind of thing of Leo as providing hyperdoc
functionality right in the development environment itself.

> ... 
> But I don't want my texts be stored inside .nw and inside
> .leo. There will be a point when nobody knows anymore what
> the actual sources are.

I just heard another Axiom developer say: "I don't want the boot
source code chunkified and made part of the documentation".
I think you are taking the same point of view.

But really I think most of us would agree that we want the
"actual" source code to be at as high a level as possible.
This seems to be implicit in what one means by literate
programming in the most inclusive sense. So if Leo becomes
the tool to support literate programming in Axiom then obviously
the .leo files are the sources (of both documentation and code).

> ...
> > 
> >  maybe the issue is deeper. I think Waldek said it best in
> > a recent email when he coined the new verb: to "chunkify".
> > He used this is a somewhat derogatory manner, suggesting
> > that to re-arrange code into chunks in order to produce a
> > pamphlet (noweb) style documentation of the Shoe (new boot)
> > compiler would be very undesirable. Clearly he would prefer
> > (at least in this case) that the code and the documentation
> > remain separate. I am sure that this view is driven at least
> > in part by reluctance to be reading and editing a cumbersome
> > and large pamphlet file every time one wants to make a small
> > change to the source code. Maybe Leo's untangle and unweave
> > features would help prevent this sort of fear of using this
> > literate format.
> 
> I can understand Waldek. Unfortunately, I have never read
> code in wh-sandbox, so I actually cannot judge.

??? wh-sandbox is just a branch of build-improvements which is
a branch of (old) Axiom silver. The style of the code and
documentation remains (largely) the same.

> But suppose Waldek likes having documentation here and code
> there. That does not mean that in the future somebody else
> could rearrange that to make the code even more understandable.
> Everyone has his coding style and for Axiom it is currently
> probably the best to let everyone work as they please. We need 
> something working, eventually. And if Waldek does this and puts
> the documentation different from where I would put it, I don't
> care. I cannot do Waldek's work so I am rather satisfied that
> Waldek writes documentation at all even if it lived in another
> place.

The thing I am MOST interested in is *collaboration*. I want it
to be possible for many people to work together effectively to
complete a complex task. And maintaining and improving Axiom is
certainly a complex task. I have serious doubts that it will be
possible to make substantial improvements in Axiom unless we can
find some way to solve this problem. I believe that Axiom is
currently constrained largely by the limitations of normal
individual human beings and the fact that it has gotten as far
as it has is at least in part because the people involved in
the project have often been somewhat extraordinary. But it is
not a good strategy for us to simply wait for such people to
come along and hope they become interested in Axiom. We need
proper (21st century) tools that permit the abilities of several
people to be effectively combined. 

> 
> All my LP efforts currently mainly concern the Algebra code.
> 
> >> My effort in documenting my own code is probably not really
> >> literal programming. The best thing I've seen up to now is
> >> Cliff's description of cl-web.
> 
> > I agree that would Cliff wrote is a good example. One trouble
> > (and this has always been a problem with literate programming)
> > is that most programmers are poor or even terrible technical
> > writers.
> 
> Hmmm, I really think that this is very much due to the fact
> that LP is not normally thought in university courses. Everyone
> wants to have code quickly. Nobody pays for good documentation.
> If a customer gets a sparsely documented product, one can get
> even more money out of that customer since somebody has to be
> paid for the maintenance (which might even be another company).

I disagree. I am convinced that writing prose and programming
a computer are two very different human capabilities that depend
on aptitudes which can not be easily taught. That is the reason
why many computer and other high tech companies specifically
employ technical writers to work directly with their programmers
and technical staff.

> 
> > Thus by it's very nature I think literate programming
> > has to normally be a collaborative effort between the highly
> > technical and specialized programmers and other people who
> > are willing to contribute to the end result via their writing
> > skills.
> 
> Let's see how this works out in our Axiom experiment. ;-)
> 

Well, this experiment is nearly 5 year old and I am getting a
little impatient and a little older myself. :-) I very much agree
with Martin Rubey who commented in a related thread that he was
very disappointed that so little effort (so far) has been directed
to writing literate documents for Axiom library code. If Axiom is
going to survive, I think we have to do better and we have to do
it soon.

\start
Date: Sun, 20 May 2007 02:38:43 -0400
From: Alfredo Portes
To: Waldek Hebisch
Subject: Update noweb info

Hi Waldek

The information on:

http://axiom.svn.sourceforge.net/viewvc/%2Acheckout%2A/axiom/branches/wh-sandbox/README.wh

Regarding the installation of noweb needs to be updated. (Not in
build-improvements
anymore).

I think Bill's info on this page should be enough:

http://wiki.axiom-developer.org/AxiomSilverBranch

\start
Date: 20 May 2007 09:03:39 +0200
From: Martin Rubey
To: Alasdair McAndrew
Subject: Re: New blood in Axiom (was: Community)

Alasdair McAndrew writes:

> 1)  Axiom gives the impression of being more difficult and abstruse than
> other systems; the moment you get started you are inundated with information
> about categories, domains and operations.  This has enormous strength, but
> nonetheless makes Axiom appear bewilderingly complicated.

As you noticed, Axiom contains many many more algorithms and concepts than
Maxima.  Not sure, but I guess that in Maxima skew polynomial rings are just
not there.  And very likely, it is difficult to consider matrices of symmetric
functions.  If you implement all these things in Maxima, things will become
quite complicated, I'm sure.

> 2)  The online documentation is very poor.  HyperDoc (which is itself
> incomplete) under unix, and some confusing system commands such as ")d op
> differentiate", ")wh th int" which produce output meaningless to the
> beginning user.  There are the books, but they are no substitute for good
> online help.

> 3)  There is not much in the way of a decent user interface.  I think
> TeXmacs and console is about it?  And HyperDoc isn't obtainable from
> TeXmacs.

I agree about )d op differentiate, but I disagree about )wh th int.  In any
case, I'd advice you to use HyperDoc (from wh-sandbox), and forget about )di op
and )wh th.  

Do you think you could fix TeXmacs to fire up HyperDoc?  The only thing that
needs to be changed is the call to "AXIOMsys" (Bill said that TeXmacs calls
AXIOMsys rather than axiom) Maybe it's sufficient to replace "AXIOMsys" with
"axiom".  A colleague said a few days ago that he believes that TeXmacs is by
far superiour to the native interface of Mathematica or Maple.  I cannot judge
this, but it might be a hint that one could tweak this or that.

Very unfortunately there is some disagreement about HyperDoc in the axiom
community.  I believe it's great, once you are used to it, especially after
Waldek fixed most of it's bugs.  Apart from that, I implemented a rudimentary
replacement, but I didn't get any feedback yet from the Windows folks, whether
my approach works.  If you are on Windows, maybe you could try it?

> 4)  It doesn't seem to be particularly cross-platform.

That's quite true.  It's a shame that graphics and HyperDoc doesn't work on
windows.  Help is needed here.  The algebra runs on all major platforms now, I
think.  (i.e., Linux, Mac, Solaris, Windows)

> 5) There seems to be some lack of cohesion amongst the Axiom developers as to
> the direction in which Axiom should go.

I think there are two and a half streams:

+ Improvement of the Axiom system per se, i.e., excluding the algebra.  Gaby,
  Tim and Waldek do a great job there, in my opinion.  Axiom is much larger
  than Maxima, I guess that's the main reason that things develop slowly.

+ Improvement of the Algebra.  Apart from Ralf (species project), Waldek, Greg,
  William Sit, and many other's I may have forgotten (sorry!) that's mainly my
  interest.

- Improvement of the Documentation and the Documentation tools.  This
  intertwines with the other two efforts.  I'd count Alfredo, Bill and Cliff
  here.

> I must admit that my main interest is in mathematics education, in which I
> think a GPL CAS has enormous potential.  But at the moment I think Maxima is
> ahead of Axiom on all the points I have mentioned.

Yes.  But as soon as you want to do something more complicated (like
combinatorial species or symmetric functions for example), you are out of luck
with Maxima (or Maple, Mathematica).

Finally, note that I was somewhat active in the Maxima project before I
switched to Axiom.  At that time I had the impression that the project was
badly organized, unfocused and followes - in my opinion - silly ideas, like
rendering output in postscript.

It takes a few years to develop a good community.  I hope that Axiom will soon
flourish.

And, as I said before, I highly appreciate you and all the others being around.
It's only us that can help ourselves to become "focused".

\start
Date: Sun, 20 May 2007 10:58:54 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: TeXmacs+Axiom	was: Re: New blood in Axiom
	
> I agree about )d op differentiate, but I disagree about )wh th int.  In any
> case, I'd advice you to use HyperDoc (from wh-sandbox), and forget about )di op
> and )wh th.  

> Do you think you could fix TeXmacs to fire up HyperDoc?  The only thing that
> needs to be changed is the call to "AXIOMsys" (Bill said that TeXmacs calls
> AXIOMsys rather than axiom) Maybe it's sufficient to replace "AXIOMsys" with
> "axiom".

Strange, but I installed the debian etch package of texmacs. And under

/usr/share/texmacs/TeXmacs/plugins/axiom/progs/init-axiom.scm

it says

(define (axiom-initialize)
   (import-from (utils plugins plugin-convert))
   (lazy-input-converter (axiom-input) axiom))

(plugin-configure axiom
   (:require (url-exists-in-path? "/usr/bin/axiom"))
   (:initialize (axiom-initialize))
   (:launch "tm_axiom")
   (:session "Axiom"))

So I would assume that texmacs calls the right thing.

Unfortunately, I've compiled my own Axiom Gold (patch--50) and I don't 
know exactly how to call that Axiom.

Currently, I've created ~/.TeXmacs/plugins/axiom/progs/init-axiom.scm 
and modified the path to point to my Axiom. An Axiom session starts, but 
the first thing I get is

   Unexpected End5

(everythinng in read except a black 5).

And there is an "axiom]" prompt. Unfortunately, the cursor then is right 
in the middle of this prompt.

So I believe Axiom Gold does not work together with TeXmacs.
Other experiences? Any cure?

\start
Date: Sun, 20 May 2007 06:42:56 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Community

On Sat, 19 May 2007, C Y wrote:

| > I however have fundamental objections to any move to burry Axiom
| > deeper into a second class build system, and second class galaxy.
| 
| I may be alone in this, but I don't view Lisp as "second class."  It is
| a language with a long usage history, particularly in the domain of
| problem we happen to be working on.  Someone on the list described it
| as "assembly code" - that's actually not a bad thing in some
| situations, and for others (like SPAD for mathematics) Lisp is
| excellent for implementing languages to meet specific problem domains
| (I believe Paradigms of AI Programming, one of the major lisp
| references, illustrates that.)

I think I can claim the assembly language characterization and I stand
by it.  For lot of people, it has become a marginal language.

Colleagues I have high estimes for recently asked me "why are you
buring your time and work in an antique language no light came from for 
over half a century?".  
I don't think they are ignorant; on the contrary, they have unmatched
understanding of programming languages, academic and industrial needs and
issues, educations.

Think about it: Lisp and derivatives have "own" academic institutions for over
half a century, yet...

[...]

| > Please give a thought to why we don't seem to attract new blood to
| > Axiom.  It is not that it is that difficult.  I've seen new blood in
| > the more challenging and difficult GCC system. 
| 
| GCC is very general purpose (and widely depended upon), and equally
| important perhaps it is very widely known.  Without GCC free software
| as we know it wouldn't exist.  That attracts attention.

I don't believe that suffices to explain it.

[...]

| Shaking our reputation as "the hard CAS" would probably do the most
| good as far as attracting people, but I'm not sure how practical that
| is.

Currently, I would think we are closer to the guys who constantly rewrite the
old stuff without making progress; that hardly attracts new blood, research
funds. 

\start
Date: 20 May 2007 07:15:22 -0500
From: Gabriel Dos Reis
To: Alasdair McAndrew
Subject: Re: New blood in Axiom (was: Community)

Alasdair McAndrew writes:

| Well, I can tell you why I have hesitated about joining the Axiom effort:
| 
| 1)  Axiom gives the impression of being more difficult and abstruse than
| other systems; the moment you get started you are inundated with information
| about categories, domains and operations.  This has enormous strength, but
| nonetheless makes Axiom appear bewilderingly complicated.
| 
| 2)  The online documentation is very poor.  HyperDoc (which is itself
| incomplete) under unix, and some confusing system commands such as ")d op
| differentiate", ")wh th int" which produce output meaningless to the
| beginning user.  There are the books, but they are no substitute for good
| online help.
| 
| 3)  There is not much in the way of a decent user interface.  I think
| TeXmacs and console is about it?  And HyperDoc isn't obtainable from
| TeXmacs.
| 
| 4)  It doesn't seem to be particularly cross-platform.
| 
| 5)  There seems to be some lack of cohesion amongst the Axiom developers as
| to the direction in which Axiom should go.
| 
| I must admit that my main interest is in mathematics education, in which I
| think a GPL CAS has enormous potential.  But at the moment I think Maxima is
| ahead of Axiom on all the points I have mentioned.


* The fact that Axiom is unfocused as project is definitely a factor.
  I do hope that as time passes, it will get better.

* I've used Axiom as my primary system last fall in my symbolic
  computations class.  overall, it went well.  The main difficulty was
  for students to get Axiom on various platforms.  Linux was OK,
  windows was almost OK but ancient version, Mac OS was a disaster.

  So, I've focused on getting recent Axiom work on Windows; it was not
  terribly hard, but resource consuming.  Now, it is done.  And I
  think we can compile on more platforms.

  I had very positive feedback from students, some of them indicated
  that working on an open source project was attractive to them --
  they had the feeling of contributing something.

* My last class on run-time systems listed some projects related to
  Axiom run time systems and Lisp; they attracted far less people and
  appeared less exciting than projects with JVM and its proof of
  correction using Isabelle/HOL.

* There is some perception that because Axiom lets you do advanced
  things (thanks to its type system), beginners must know about every
  concepts right from the start, to do everything Right.

  I don't agree with that.  And I believe the original designers of
  Axiom realized that too, and in later development of Axiom proposed
  the notion of "B natural", which has been discussed to death on this
  list.   Nothing seems to be moving on that front probably because of
  lack of resource.

* Documentation is a very important aspect to attract new blood.  I
  believe it would be helpful if new people like you could record what
  they have learnt so far somewhere either in the Axiom pamphlet or on
  the wiki somewhere.

  There are some issues as to why documentation is not making
  progress.  First, it is a time consuming job.  Second, researchers
  are paid to do research and not document already known material.
  Consequently, they are unlikely to get funded for doing *just* that,
  or tenured for doing *just* that. 
  [ in the US at least, tenure committees "measure" the length of
    publications -- publish or perish. ] 

  Documentation may come of out research work as a by-product of the
  research done, but it is unlikely to be the primary focus.

  Third, if documentation must be done Right, then I fear we will be
  spending more time debating how it must be done than actually doing
  something.  We must be tolerant of incremental improvements.


Overall, I do hope that I actively join us, even if you think you do
not contribute much.  It will come.  We all started somewhere.

\start
Date: 20 May 2007 07:30:14 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Silver

Tim Daly writes:

| SILVER
| 
| The latest, merged version will momentarily be available as
| a silver version. 

Tim --
  
  You recently committed changes to axiom/branches/daly; it is good?

\start
Date: Sun, 20 May 2007 12:08:50 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: branches/daly/axiom

> You recently committed changes to the axiom/branches/daly; it is good?

Well, I'll leave the judgement of "good" to you :-)

The latest commit to branches/daly/axiom is the end result of a merge
of BI, wh-sandbox, my work, and gold. This is what has been referred
to as "silver". Once the algebra has been brought up to speed,
the community has a chance to fix obvious breakage, and new code
gets added it will certainly become "gold".

It contains changes in the interpreter that everyone has made, such as
removing xrun and xruncomp and other dead code. It contains a
gcl-based prototype of cliff's common lisp web idea which will be
replace by cliff's work once we move to ansi. There are no ansi-based
changes yet because that work happened after I made "the cut" from the
BI and wh-sandbox code bases in March. The same is true of all of the
most recent work.

It contains changes to the graphics (dead code elimination). 

I tried to merge the hyperdoc changes but did not understand how .pht
handling works.

Some of the algebra is changed (e.g. quat.spad) as well as some 
initial structure for unit testing the algebra. Most of the algebra
changes were not yet merged. I'm working on trying to merge Martin's
work at the moment. There are two concerns here:

First, I think we need to be very conservative about algebra
changes. We need good documentation applied to any algebra we change
including unit tests of the algebra showing what used to be broken vs
what is now fixed. I have a prototype mechanism in place in a couple
algebra files.

Second, I think we need to concentrate on having a comprehensive
test mechanism for the algebra that will alert us to things we
break. I'm concerned that "obvious" fixes in one domain end up
introducing "non-obvious" breakage in another. It is not obvious
how to do this. I've been pondering attacking the "algebra graph"
Bill discussed years ago as a basis but there is no code to support
this in the last release.

The input files have been rewritten to automate checking for errors.
In addition a new file (regress.lisp.pamphlet) was added to automate
that checking.

The build procedure now automatically checks every file in the build
tree for changes. This allows us to make one change, build the system,
and see what other files have changed. The advantage is that you can
tell when changes to the interpreter actually end up changing the
algebra in unintended ways. This lives in src/regress/REGRESS.

Not everything was merged, mostly because I couldn't understand the
details of the changes. So things like the autoconf build mechanism,
the .pht file handling, the build-from-scratch algebra, etc. still
remain to be merged. 

The fact that they are not yet merged does NOT mean that they won't be
in the future. It does mean that the changes are not documented enough
and the dependencies are not clear. It would help a LOT if you would
"box up" a changeset against this latest version that added a new
feature and was well tested. This takes a long time (I know because
I've been at it for months).

I'd encourage everyone to try to build it and report bugs (to the
list and to bugzilla).

Future plans are to look at updating the algebra, do a review of
the outstanding bugs, and a review of the complaints and comments
posted to the mailing list archives. It would be useful if other
people did the same and, hopefully, create a diff-Naur patch.

Now that I've got a version that works I spent some time "opening
up" the silver code. It lives in parallel on SVN and in a git
repository. 

I know there are a lot of religious debates over the source code
control mechanism. I'm not trying to open the debate again. However,
during the big SVN-storm back in January I ended up trying git and my
eyes were opened. I've been using it ever since for all of my
work. (The big hurdle is that git tracks "changes" whereas everyone
else tracks "files".) Git has the potential to eliminate my special
position as "the point of failure" and to make everyone "the central
repository". This eliminates the need for sourceforge, automates the
construction of complex "changesets", and makes the whole social
network much more flexible. Linus really did "get it right".

I'm also using SVN just to avoid opening up the big debate again.
If you don't like git, don't use it. Changes will appear in both
places.

The "gold" version will still live in Arch and be mirrored to CVS
at sourceforge and CVS at savannah so that ordinary mortals can
get the code in the form they expect.

I put together a table of binary files on a web pages someplace 
(can't remember where). This time around I think we need to give
some thought to providing a range of binary files.

\start
Date: 20 May 2007 12:30:22 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: branches/daly/axiom

Tim Daly writes:

| > You recently committed changes to the axiom/branches/daly; it is good?
| 
| Well, I'll leave the judgement of "good" to you :-)
| 
| The latest commit to branches/daly/axiom is the end result of a merge
| of BI, wh-sandbox, my work, and gold. This is what has been referred
| to as "silver".

Thanks, that is the piece of information I was looking for.

I got daly branch but there were no indication of what was picked from
where and what was left out.  I looked at CHANGELOG but it seems stuck
at --patch-49. 

\start
Date: 20 May 2007 12:38:46 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: branches/daly/axiom

Tim Daly writes:

[...]

| It contains changes in the interpreter that everyone has made, such as
| removing xrun and xruncomp 

Except Axiom.build-improvements branch.

| and other dead code. 

Which ones?

You said you did not pick everything because you did not
understand the changes.  How do you expect us to understand the
changes you've picked when you do not document them?

[...]

| Not everything was merged, mostly because I couldn't understand the
| details of the changes. So things like the autoconf build mechanism,

I have not brought the Autoconf build machinery forward because I did
not know what "silver" is.  Now, I know what it is; but as you picked
some changes and I cannot find documentation about which changes you
picked from build-improvements, it makes the task harder.

[...]

| and the dependencies are not clear. It would help a LOT if you would
| "box up" a changeset against this latest version that added a new
| feature and was well tested.

Please could you give an overview of which changes you pick from which
branch?  I the mail I'm replying to contains some material, but they
are no near anything you would call documentation of changes.

[...]

| Now that I've got a version that works I spent some time "opening
| up" the silver code. It lives in parallel on SVN and in a git
| repository. 

\start
Date: 20 May 2007 19:42:10 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: branches/daly/axiom

Dear Tim,

Tim Daly writes:

> Second, I think we need to concentrate on having a comprehensive
> test mechanism for the algebra that will alert us to things we
> break. I'm concerned that "obvious" fixes in one domain end up
> introducing "non-obvious" breakage in another. It is not obvious
> how to do this. 

Yes it is: make Christian Aistleitners AldorUnit available.  Please, do not try
to invent the wheel yet another time.  I'm not going to do it on my own, but I
can help, if someone starts it.  I'm sure Christian will help, too.

> Future plans are to look at updating the algebra, do a review of
> the outstanding bugs, and a review of the complaints and comments
> posted to the mailing list archives. It would be useful if other
> people did the same and, hopefully, create a diff-Naur patch.

Those bugs on issue tracker I know how to fix are fixed.  The others are
difficult, i.e., need better organization of the categories, or need a better
compiler, i.e., Aldor.

Apart from that, don't believe that the algebra code of Axiom would be
especially good.  I'm not saying it's bad, but it is *far* behind MuPAD's, for
example.

The way to fix this is

* reorganize old categories (for example, implement the missing bits of PFE)

* implement new, "good" domains.  I believe, for many many mathematicians,
  domains for algebraic differential equations and a related class of
  recurrence relations would be very helpful.

  Implementing provisos for the EXPR domain would also be very good, but
  perhaps not as easy.

* implement algorithms which are known to be very effective, like Gruntz's for
  limits, work of Bernhard Gittenberger et al. for asymptotic expansions, work
  of Carsten Schneider for summation, etc.

I think the first two items are easier, and will assist in work on the third
item.

\start
Date: Sun, 20 May 2007 12:52:10 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: branches/daly/axiom

> I looked at the CHANGELOG and it seems stuck at --patch-49

Odd. I checked in the SVN version from the same source tree
as the git version and I checked them in at the same time.
Very, very odd. 

\start
Date: Sun, 20 May 2007 12:54:27 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: branches/daly/axiom

I'll create a document to show what the main goal of the change was
and what files where involved in the change.

>From this point onward I hope to work only with changesets.

\start
Date: Sun, 20 May 2007 13:06:01 -0500
From: Tim Daly
To: list
Subject: mathpages

Does anyone know who is behind this website?

<http://www.mathpages.com>

\start
Date: Sun, 20 May 2007 13:12:45 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: branches/daly/axiom

On Sun, 20 May 2007, Tim Daly wrote:

| > I looked at the CHANGELOG and it seems stuck at --patch-49
| 
| Odd. I checked in the SVN version from the same source tree
| as the git version and I checked them in at the same time.
| Very, very odd. 


This is what I have:

   soliton[13:10]% svk log CHANGELOG
   ~/src/Axiom/daly/axiom
   ----------------------------------------------------------------------
   r21127 (orig r547):  daly | 2007-05-18 20:19:54 -0500

   silver baseline
   ----------------------------------------------------------------------
   r7 (orig r6):  (no author) | 2005-01-04 17:59:09 -0600

   This commit was manufactured by cvs2svn to create branch 'daly'.
   ----------------------------------------------------------------------
   soliton[13:10]% svk cat CHANGELOG | head 
   20060417 tpd --patch-49
   20060417 tpd zips/gcl-2.6.8pre.tgz updated
   20060417 tpd zips/gcl-2.6.8pre.unixport.init_gcl.lsp.in.patch changed
   20060417 tpd lsp/Makefile gcl-2.6.8pre.configure.patch reverted
   20060417 tpd lsp/Makefile gcl-2.6.8pre.configure.in.patch reverted
   20060417 rhx Ralf Hemmecke changed globally
   20060417 tpd src/input/wester.input add )clear properties p
   20060417 tpd src/input/Makefile fix dropt.input
   20060417 tpd src/input/Makefile add zimmer.input
   20060417 tpd src/input/zimmer.input fixed. 
   soliton[13:10]%


\start
Date: Sun, 20 May 2007 13:13:17 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: branches/daly/axiom

On Sun, 20 May 2007, Tim Daly wrote:

| I'll create a document to show what the main goal of the change was
| and what files where involved in the change.

\start
Date: Sun, 20 May 2007 13:24:47 -0500
From: Tim Daly
To: Cliff Yapp, list
Subject: git repository

the password for the git repository is 'linus'.

\start
Date: Sun, 20 May 2007 20:36:34 +0200
From: Daniel Duparc
To: list
Subject: Re: mathpages

> Does anyone know who is behind this website?
> 
> <http://www.mathpages.com>

maybe Kevin Brown?
please see
http://home.att.net/~numericana/fame/

\start
Date: Sun, 20 May 2007 13:38:50 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: CHANGELOG

It appears that I stepped on CHANGELOG while testing.
It is now up to date on git and SVN.

(btw, just to complain... it took 4 tries to get the SVN update to work.
each of the first 3 tries gave "500 Internal Server Error". Am I the
only person this happens to?)

\start
Date: Sun, 20 May 2007 13:42:03 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: CHANGELOG

On Sun, 20 May 2007, Tim Daly wrote:

| It appears that I stepped on CHANGELOG while testing.
| It is now up to date on git and SVN.

Yes, I just saw the commit message.  Thanks.

| (btw, just to complain... it took 4 tries to get the SVN update to work.
| each of the first 3 tries gave "500 Internal Server Error". Am I the
| only person this happens to?)

I just updated my local tree to your changes.  I did not see
that behaviour.

Just to check, what URI are you using to access the SVN repo?

\start
Date: Sun, 20 May 2007 14:41:27 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: CHANGELOG
Cc: Gabriel Dos Reis

> (btw, just to complain... it took 4 tries to get the SVN update to work.
> each of the first 3 tries gave "500 Internal Server Error". Am I the
> only person this happens to?)

I think svn has a computational vendetta against you :-).

\start
Date: Sun, 20 May 2007 13:43:21 -0500 (CDT)
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: CHANGELOG

On Sun, 20 May 2007, Alfredo Portes wrote:

| > (btw, just to complain... it took 4 tries to get the SVN update to work.
| > each of the first 3 tries gave "500 Internal Server Error". Am I the
| > only person this happens to?)
| 
| I think svn has a computational vendetta against you :-).

bouhahaha :-)

\start
Date: 20 May 2007 20:46:50 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: mathpages

Tim Daly writes:

> Does anyone know who is behind this website?
> 
> <http://www.mathpages.com>

http://theassayer.org/cgi-bin/asbook.cgi?book=948

\start
Date: Sun, 20 May 2007 14:53:56 -0400
From: Bill Page
To: Tim Daly
Subject: RE: CHANGELOG

Tim Daly wrote:
> ...
> (btw, just to complain... it took 4 tries to get the SVN 
> update to work. each of the first 3 tries gave
> "500 Internal Server Error". Am I the only person this
> happens to?)
> 

It used to happen to me all the time until I started using
the new url.

\start
Date: Sun, 20 May 2007 12:36:49 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, list
Subject: Re: Silver

> HOW?
> 
> 1) get the code
>   git-clone ssh://git@axiom-developer.org/home/git/silver silver
> 
>   the clone is a full, independent git repository. people can clone
>   your whole repository, pull changes from your repository, or push
>   changes to your repository. thus you are the center of the world.

Works.
 
> 2) branch the code
>   git-branch mybranch
> 
>   if you work on a single problem (eg an algebra bug) in a single
>   branch you will naturally accumulate a changeset. since git will
>   not copy files the branch is only a few bytes big. you can have
>   as many branches as you wish so each branch can be a single idea
>   or problem.

OK, that command appears to succeed.
 
> 3) list the branches
>   git-branch
> 
>   you can see all of the branches you have created

Works:

$ git-branch
* master
  mybranch

> 4) change to the new branch
>   git-checkout mybranch
> 
>   if mybranch is related to one single change then you can work
>   on that change locally independent of all other work.

$ git-checkout mybranch
Switched to branch "mybranch"
$ git-branch 
  master
* mybranch

> 5) change something
>   echo "it works" >>FAQ
>
>  here we modify the FAQ file

Done:

...
developer mailing lists. 
it works

> 6) remember the change
>  git-add test
>
>  NOTE: git does not know about files, it knows about changes.
>  If you change something you need to tell git you want to add that
>  change to the set of changes to keep. So "git-add" means ADD THE
>  CHANGE, NOT ADD THE FILE. git only cares about content. it does
>  not track files. This is different from other source code control.

This is where I run into trouble:  
$ git-add test
fatal: pathspec 'test' did not match any files

> 8) change to the master branch
>  git-checkout master
>
>  Now that we've made our glorious change in isolation it is time to
>  merge it back onto the main tree. So first we switch to the master
>  tree (or whatever tree we want)
>
>8) merge the branch
>  git-merge mybranch
>
>  And we merge the master and mybranch trees

Two questions - since the FAQ file is modified, switching back to the
master branch doesn't expose a view of the FAQ change without the "it
works" line added, at least when I tried it.  If I have multiple
branches going at once, and I want to check how one builds vs. another,
wouldn't this be a problem?  Also, since a build test might produce
files that cleanup wouldn't get rid of, wouldn't those build files get
sucked into the changeset?

Also, would deleting an un-merged branch that made changes to the files
result in "rolling back" the changes in the tree?  When I tried this
the change to FAQ survived the delete of the branch, despite never
adding the change successfully.

Sorry if these are silly questions.

\start
Date: Sun, 20 May 2007 15:48:33 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: TeXmacs+Axiom was: Re: New blood in Axiom

Ralf,

On May 20, 2007 4:59 AM you wrote:
> ... 
> > Do you think you could fix TeXmacs to fire up HyperDoc?  
> > The only thing that needs to be changed is the call to
> > "AXIOMsys" (Bill said that TeXmacs calls AXIOMsys rather
> > than axiom) Maybe it's sufficient to replace "AXIOMsys"
> > with "axiom".

No, that is not sufficient. You also have to modify the tm_axiom
program to handle the double Axiom prompt. This is described on
the Axiom wiki.

BTW, I think having TeXmacs start hyperdoc in this way is rather
awkward, since the interaction takes place outside of the TeXmacs
window but at least by calling axiom you can also get Axiom
graphics (which also are presented only outside of TeXmacs).
The TeXmacs interface for many of the TeXmacs plug-ins are more
sophisticated these days, see for example how TeXmacs works with
Maxima. The TeXmacs - Axiom interface is due for a major upgrage.
There was some discussion of this on the Axiom-developer list
about a year ago or so but I don't recall any mention of more
recent work.

> 
> Strange, but I installed the debian etch package of texmacs.

Is that version 1.0.6 of TeXmacs?

> And under
> 
> /usr/share/texmacs/TeXmacs/plugins/axiom/progs/init-axiom.scm
> 
> it says
> 
> (define (axiom-initialize)
>    (import-from (utils plugins plugin-convert))
>    (lazy-input-converter (axiom-input) axiom))
> 
> (plugin-configure axiom
>    (:require (url-exists-in-path? "/usr/bin/axiom"))
>    (:initialize (axiom-initialize))
>    (:launch "tm_axiom")
>    (:session "Axiom"))
> 
> So I would assume that texmacs calls the right thing.

No.  The (:require above is just checking that the file
/usr/bin/axiom exists. This controls whether you see Axiom
listed under the Session memu. It is actually the interface
program tm_axiom that starts Axiom. As far as I know the
version of tm_axiom distributed with TeXmacs starts AXIOMsys.

Note: There is a separate version of tm_axiom for Windows.
Check the TeXmacs pages on the Axiom wiki.

> 
> Unfortunately, I've compiled my own Axiom Gold (patch--50) 
> and I don't know exactly how to call that Axiom.
> 

To use Axiom from TeXmacs AXIOMsys must be in the PATH or
you have to modify tm_axiom.

> Currently, I've created
> ~/.TeXmacs/plugins/axiom/progs/init-axiom.scm 
> and modified the path to point to my Axiom. An Axiom session 
> starts, but the first thing I get is
> 
>    Unexpected End5
> 
> (everythinng in read except a black 5).
> 
> And there is an "axiom]" prompt. Unfortunately, the cursor 
> then is right in the middle of this prompt.
> 
> So I believe Axiom Gold does not work together with TeXmacs.
> Other experiences? Any cure?
> 

That the kind of symptom that I recall when tm_axiom starts
the 'axiom' script which starts sman and creates the double
prompt but tm_axiom has not been modified to accept two
prompts.

\start
Date: Sun, 20 May 2007 13:27:31 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Literate ASDF

--- Tim Daly wrote:

> Literate supporting ASDF loads.... what a truly awesome idea.
> 
> That would mean that the literate idea could be spread to the
> rest of the lisp community. Then literate files could be remotely
> hosted ASDF files and drag-and-drop becomes so much easier.

Actually, I think the Lisp community as a whole (or at least #lisp) is
rather skeptical that literate programming is a good match to
traditional lisp programming styles.  Still, that's the beauty of open
source - there's nothing stopping us from converting existing lisp code
to literate lisp code. :-)
 
> That idea collapses whole layers of complexity out of the build
> tower.
> The build would amount to ASDF-loading the interpreter, the compiler,
> and the algebra. Very, very sweet.
> 
> Even if we can't make it work I'm impressed with the idea.

Thanks - I think it's come up briefly in the past but the whole web
system in lisp issue had to come first.  (Or minimally a way to invoke
noweb from lisp that asdf could use, and since we wanted a faster
tangle operation anyway cl-web seemed the logical starting point.)

The next step looks like it will have to be converting ASDF into a
literate program - I need to make sure I understand it well enough to
map pamphlet file concepts to it :-/.  So far it LOOKS like making a
subclass of source-file for pamphlets, making a second for cl-pamphlet,
 a method for source-file-type, a perform method (most of the hard
work), and some modifications to the component parser to handle the
chunk option.  There are probably a couple of additional changes that
will be needed, and the ins and outs of the input and output file
handling and error handling I'm not sure about yet.

I rather doubt the asdf devs would accept a pamphlet file, so my plan
at the moment is to include the literate asdf in Axiom in case it can
be of help to others.  We can track the latest changes and document
them as they occur.  Whether it should diverge much is another question
(there are apparently a few suggestions for improvements floating
around out there) but my preference would be to make any additional
changes as extensions.  asdf-literate.lisp.pamphlet would extend the
functionality in asdf.  We could have the bootstrap lisp script check
for asdf in the target lisp system, and load the one in Axiom if a
system asdf can't be loaded.  I wish lisp vendors would build with asdf
in the default image always, which would reduce the bootstrap script to
setting up the asdf search path and invoking asdf on the axiom system,
but at this time I'm not sure they do.

Anyway, I'll start in on asdf and see how that goes.

\start
Date: Sun, 20 May 2007 23:46:43 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: TeXmacs+Axiom was: Re: New blood in Axiom

>> Strange, but I installed the debian etch package of texmacs.
> 
> Is that version 1.0.6 of TeXmacs?

http://packages.debian.org/stable/editors/ ... look for texmacs

woodpecker:~/scratch/spreadsheet0/examples>texmacs --version

TeXmacs version 1.0.6
(c) 1999-2003 by Joris van der Hoeven

> No.  The (:require above is just checking that the file
> /usr/bin/axiom exists. This controls whether you see Axiom
> listed under the Session memu. It is actually the interface
> program tm_axiom that starts Axiom. As far as I know the
> version of tm_axiom distributed with TeXmacs starts AXIOMsys.

Oho from
http://wiki.axiom-developer.org/TeXmacs
I see that you have (re)written tm_axiom. Cool.
How come that this is *not* a literate program?

I don't understand C very well, so it would take me ages until I get an 
idea what the program does, except that I know that it establishes the 
texmacs <---> axiom connection. That sources are not very helpful for 
me. :-(

I only see that TeXmacs' tm_axiom and the one of Bill Page start AXIOMsys.

>>
>>    Unexpected End5
>>
>> (everythinng in read except a black 5).
>>
>> And there is an "axiom]" prompt. Unfortunately, the cursor 
>> then is right in the middle of this prompt.
>>
>> So I believe Axiom Gold does not work together with TeXmacs.
>> Other experiences? Any cure?

> That the kind of symptom that I recall when tm_axiom starts
> the 'axiom' script which starts sman and creates the double
> prompt but tm_axiom has not been modified to accept two
> prompts.

Oh, since I haven't changed tm_axiom, it should still call AXIOMsys, so 
there would be another reason for the "Unexpected End".

Anywaym, I feel unable to correct that myself. :-(

\start
Date: Sun, 20 May 2007 16:36:42 -0700
From: Simon Michael
To: list
Subject: revision control chaos

Greetings Tim, all!

this is just an outsider's comment. I've been following the list for a while.

I am amazed that the Axiom project is still fiddling around with so many 
revision control systems (arch, cvs, svn, git at last count). No successful 
free software project does this. Chaos is the practically inevitable result.

I think adopting Git was a great move - bravo! All you need do now is pull 
the plug on all arch, cvs and svn repos and go forward.

"Ordinary mortals" are using the modern distributed revision control 
systems by now. (And if they're not, they are a drag on the project you 
can't afford.)

Thanks for listening, and thank you for Axiom!

\start
Date: Sun, 20 May 2007 19:43:14 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: TeXmacs+Axiom

On May 20, 2007 5:47 PM Ralf Hemmecke wrote:
> ... 
> Oh from
> http://wiki.axiom-developer.org/TeXmacs
> I see that you have (re)written tm_axiom. Cool.
> How come that this is *not* a literate program?
> 

Well technically tm_axiom was originally part of TeXmacs
although arguably it could/should be part of Axiom. If we
agree to make it part of Axiom I would be happy to take
the time to make it at least a little bit literate.

> I don't understand C very well,

Every time someone on this list says "I don't understand X"
but they already program in Aldor/Spad/Lisp or whatever, it
makes me wonder about their motivations as opposed to their
skill ... :-) "C" is a particularly simple language.

> so it would take me ages until I get an idea what the
> program does, except that I know that it establishes the
> texmacs <---> axiom connection. That sources are not very
> helpful for me. :-(

Right, tm_axiom is very simple. The original version (still
used in the Linux version of TeXmacs) was written by Andrey
Grozin. I believe that he is still a member of this email list.
tm_axiom is just a two-way filter. It passes comands generated
by a TeXmacs Axiom "session" (part of a TeXmacs document)
directly on to Axiom console input and it accepts output from
Axiom and parses it for it's LaTeX and type contents, formats
that for TeXmacs and sends it on to TeXmacs. That's all.

My version for Windows makes use of Windows native threads to
implement the filters (many thanks due to Mike Thomas for the
hints required to do this). This just makes the coding a little
simpler and faster under Windows. tm_axiom could also be written
this way under Linux but it would require a slightly different
thread interface.

The only other complication is that currently TeXmacs does
not do a very good job of folding the LaTeX code that is
output by Axiom, therefore in my version ot tm_axiom I
incorporated Robert Sutor's LaTeX line folding code that
is also used to produce the LaTeX in the Axiom book from
Axiom output.

> 
> I only see that TeXmacs' tm_axiom and the one of
> Bill Page start AXIOMsys.
> 
> >>
> >>    Unexpected End5
> >>
> >> (everythinng in read except a black 5).
> >>
> >> And there is an "axiom]" prompt. Unfortunately, the cursor 
> >> then is right in the middle of this prompt.
> >>
> >> So I believe Axiom Gold does not work together with
> >> TeXmacs. Other experiences? Any cure?
> 

I am sure that Axiom Gold works fine with TeXmacs.

> > That the kind of symptom that I recall when tm_axiom
> > starts the 'axiom' script which starts sman and creates
> > the double prompt but tm_axiom has not been modified to
> > accept two prompts.
> 
> Oh, since I haven't changed tm_axiom, it should still
> call AXIOMsys, so there would be another reason for the
> "Unexpected End".
> 
> Anywaym, I feel unable to correct that myself. :-(
> 

In that case the problem is probably just that AxiomSYS
is not executable from your PATH. For this to work you
must set *both* the AXIOM environment variable to the
root of your Axiom Gold installation and set the PATH
like this:

  export PATH=$AXIOM/bin:$PATH

Then exit TeXmacs and try it again.

\start
Date: Sun, 20 May 2007 17:44:29 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: GIT and Axiom

I went ahead and started looking at the GIT tutorials.  First, my
original assertion was incorrect - if handled correctly, FAQ DID change
based on which branch was active.

Based on this tutorial
(http://www.kernel.org/pub/software/scm/git/docs/tutorial.html), here
is what worked for me:

git branch experimental
git branch
git checkout experimental
edit FAQ
git commit -a (adds any modified files, but not new files)

At this point, looking in the FAQ file will still show changes, because
we are in the experimental branch.  If we then switch back:

git checkout master

and look at FAQ again, it is in its original form.  (SWEEEET!) No
directory changing, nothing - the same tree on the file system is now
in its original state.  That's NICE. The merge command can bring the
FAQ changes from the branch to the original.

If files are added in a branch and left untracked, they will remain
present when switching to another branch.  However, if they ARE tracked
switching branches will hide them.  (Makes sense, I guess - until git
knows better untracked files are just random junk in the tree.)  git
status lets you know what is present and untracked, and looks like it
might be a very handy way to look for mistakes in a "make clean" type
script :-).  Also, different build systems could be tested with the
same "base" code simply by turning one branch on or off, and clearing
out any untracked files.  Wow!

I'm impressed.  I can also see where this would get tough with very
large diffs, but that's a problem no revision control system can solve
because the differences ARE intrinsically major and must be resolved by
human beings.

Clearly there are details to learn, and perhaps a page detailing common
scenarios for Axiom developers would be helpful (say, for example,
pulling Waldek's change set into my git repository as "wh-sandbox"
branch without accidentally stomping on anything in mine) but I have to
say I find this very appealing.  The lack of duplication of file
storage is VERY impressive (my hard disk is not sufficiently large that
storing many trees of Axiom is a trivial matter) and the tools look
easy enough to use.

I'm convinced Tim - I'll sign up for Git as the way to go.

\start
Date: 20 May 2007 20:40:50 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: TeXmacs+Axiom

Bill Page writes:

[...]

| > I don't understand C very well,
| 
| Every time someone on this list says "I don't understand X"
| but they already program in Aldor/Spad/Lisp or whatever, it
| makes me wonder about their motivations as opposed to their
| skill ... :-) "C" is a particularly simple language.

Fully agreed.

\start
Date: Sun, 20 May 2007 20:51:47 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: CHANGELOG

The choice of person marked for changes was made based on which branch
I diff-ed first. The first merge was done using Waldek's branch so most
of the changes have his name attached. I'll fix the ones you mention.

\start
Date: Sun, 20 May 2007 22:34:52 -0400
From: Bill Page
To: Simon Michael
Subject: RE: revision control chaos

On May 20, 2007 7:37 PM Simon Michael wrote:
> 
> this is just an outsider's comment. I've been following the 
> list for a while.
> 
> I am amazed that the Axiom project is still fiddling around 
> with so many revision control systems (arch, cvs, svn, git at
> last count).

Actually Simon, you forgot both darcs and mercurial. We have had
mirrors of the SVN build-improvements branch in these formats
for more than a year and the first windows version of Axiom was
distributed that way since no one seemed to be able to get tla
to work reliably on Windows.

> No successful free software project does this. Chaos is the
> practically inevitable result.

I agree that it would be chaos if Axiom had a reasonable number
of committers but as it stands it is really only rather pathetic.
:-(

> 
> I think adopting Git was a great move - bravo! All you need 
> do now is pull the plug on all arch, cvs and svn repos and go
> forward.

I agree and also I should say: "Well said!" considering that the
ZWiki project choose darcs a couple of years ago. In my opinion
darcs is still superior to Git, Hg and the other distributed
archive systems and I have long been very disappointed that none
of the other Axiom developers saw it this way. But at least Git
is better late rather than never.

> 
> "Ordinary mortals" are using the modern distributed revision
> control systems by now. (And if they're not, they are a drag
> on the project you can't afford.)

Actually I think we can afford a little drag. Axiom is more like
a big old steam engine than a new fangled airplane, since it just
keeps on going and is starting to look pretty good these days since
it uses only renewable resources ... For some reason this image
always seems to come to my mind when Tim Daly makes reference to
Axiom's "30 year horizon" :-)

> 
> Thanks for listening, and thank you for Axiom!
> 

I'll second that!

\start
Date: 20 May 2007 21:47:59 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: Literate ASDF

Assume you have linguistic support in Boot to state unambigously what
your module [1] defines (`exports') and what it needs (`imports'), then
your Boot program structures states what are the depedencies, and
those statement can be mechanically checked -- it therefore avoids
external definitions that may get out of sync, pretty much the same
way you don't want your documentation to get out of sync with actual
implementation.  You may use bootsys to extracts the exports and the
imports, if you need to.  Or you can just rely on bootsys to resolve
the depedencies for you. 

To test the idea, I've implemented a rudimentary extension to Boot.

  * you can say:

       module '"boot-tokens"

    which means that the definitions in the current file are part of
    the module "boot-tokens".  A module can span several files.
    How this is resolved should be Lisp system independent.
    Currently, I just map it to Lisp as:

        (provide "boot-tokens")

    but my plans are less simple.

  * you can also say:

       module '"boot-lexer"         
       import '"boot-tokens"         -- we need tokens interface
       import '"boot-includer"       -- idem for the includer

    which means that the module "boot-lexer" depends on both
    "boot-tokens" and "boot-includer".  How this depedency is resolved
    should be Lisp system independent.
    At the moment, I just map it to Lisp as:
     
       (require "boot-tokens")
       (require "boot-includer")

    Every Lisp system has its own idea of what ANSI Lisp module should be.
    However, the above simple mapping works well with GCL and CLISP.
    SBCL needs more help, but that is doable.

    I emphasize that the notion of `module' I have for Boot is not
    just a replicate of ANSI Lisp module.

    I'm still playing with that rudimentary translation.  I'm able to
    eliminate many irritating warnings from Lisp compilers to the
    effect that some variables are not defined, or some functions are
    not.  

    With the above rudimentary translation, I was able to restructure
    the depedencies in src/boot/ in a more logical manner.  It is nice
    to see how it plays so well, so far.
 


[1] By module here, I don't necessarily mean ANSI Lisp module.

Once I've finished bootstrapping of the whole system, I'll commit the
experiment to gdr-sandbox.

\start
Date: 20 May 2007 21:50:29 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: revision control chaos
Cc: Simon Michael

Bill Page writes:

[...]

| > No successful free software project does this. Chaos is the
| > practically inevitable result.
| 
| I agree that it would be chaos if Axiom had a reasonable number
| of committers but as it stands it is really only rather pathetic.
| :-(

You haven't found way to clone Axiomatizers yet? 
;-)

\start
Date: Sun, 20 May 2007 23:19:42 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: revision control chaos
Cc: Simon Michael

On May 20, 2007 10:50 PM Gaby wrote:
> 
> You haven't found way to clone Axiomatizers yet? 
> ;-)
> 

No, none at all. All Axiomatizers I know where born that way.
This is in contrast to other species like Pythonistas:

http://python.net/crew/mwh/hacks/objectthink.html

"> Who is wrong here: my intuition or Python (2.2)? If it's
 > my intuition, how can I train my thinking about Python's
 > execution model, so that my intuition get's better ;-)

 Your intuition, which led you astray here (Python does just
 what it should do), can be trained in several ways.
 ..."

:-)

Now if we could only somehow teach "ordinary people" to think
Axiomatically, maybe we would get somewhere... ;)

\start
Date: Sun, 20 May 2007 22:30:54 -0500
From: Tim Daly
To: list
Subject: SVN URL

svn co https://svn.sourceforge.net/svnroot/axiom/branches/daly axiom

is this the right URL?

\start
Date: Sun, 20 May 2007 23:34:21 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: SVN URL

I think it should be:

svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/daly axiom

Gaby and Bill can confirm it.

On 5/20/07, Tim Daly wrote:
> svn co https://svn.sourceforge.net/svnroot/axiom/branches/daly axiom
>
> is this the right URL?

\start
Date: Sun, 20 May 2007 22:45:25 -0500
From: Tim Daly
To: list
Subject: eh?

svn co https://svn.sourceforge.net/svnroot/axiom/branches/daly axiom
   ..... download the whole repo

change src/regress/REGRESS (under .svn control)

svn commit -m"fix src/regress/REGRESS"
   ..... does nothing. just returns to the prompt.

svn update
   At revision 554.

svn commit -m"fix src/regress/REGRESS"
   ..... does nothing. just returns to the prompt.


Any idea what went wrong? I can't seem to commit to SVN.

\start
Date: 20 May 2007 22:56:03 -0500
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: Re: SVN URL

Alfredo Portes writes:

| I think it should be:
| 
| svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/daly axiom

Alfredo is exactly right.

\start
Date: 20 May 2007 23:05:02 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: SVN

Tim --

  Why do you donwload SVN repo all the time?
You know you can switch from one branch to another without having to
download all the time.

Alos, please use the URL that has axiom.svn.sf.net in it.

\start
Date: Sun, 20 May 2007 23:20:31 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: eh?

> Why do you download SVN repo all the time?

Because once I do the first commit no more commits work 
no matter what I change.

So the "fix" is to wipe out the local copy, checkout a new version,
make the change, and then do a commit, which works. Until now. Now,
for some not-very-obvious reason this no longer works. 

Now I do a checkout, change a file, and do a commit. But the commit does
nothing and returns immediately. I'm unable to commit to SVN anymore.

\start
Date: Sun, 20 May 2007 23:25:15 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: eh?

> please use the URL that has axiom.svn.sf.net in it.

Ok. I'll try that. The previous URL "sort of" worked because I was
able to check in the project using it (modulo several tries). I
remember that there was some comment about a new URL so I'll try this.

\start
Date: Sun, 20 May 2007 23:28:23 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: eh?

On Sun, 20 May 2007, Tim Daly wrote:

| > Why do you download SVN repo all the time?
| 
| Because once I do the first commit no more commits work 
| no matter what I change.
| 
| So the "fix" is to wipe out the local copy, checkout a new version,
| make the change, and then do a commit, which works. Until now. Now,
| for some not-very-obvious reason this no longer works. 
| 
| Now I do a checkout, change a file, and do a commit. But the commit does
| nothing and returns immediately. I'm unable to commit to SVN anymore.

Just to check the obvious: do you do "in source" build?
I seem to remember that in the old Gold, there was issues of recursive 
copies of directories -- which is bogus.  If that is still the case
(which I've not checked yet), then it might be that you're just overwriting
SVN data.  Just a theory.

\start
Date: Sun, 20 May 2007 23:41:50 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: eh?

I tried the checkout/change/commit with the new URL. That worked.

The "in source" build isn't the problem. I'm not doing a build at all.
I'm just did a fresh checkout/change/commit and it did nothing.
Truly the SVN daemon has put a curse on me. It must be jealous of
me fooling around with git behind its back :-)

Hopefully the new URL will continue to work.

\start
Date: Sun, 20 May 2007 23:48:32 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: eh?

On Sun, 20 May 2007, Tim Daly wrote:

| I tried the checkout/change/commit with the new URL. That worked.

Great!

| The "in source" build isn't the problem. I'm not doing a build at all.

Ah, OK.
[ As I saied, it was a theory :-)]

| I'm just did a fresh checkout/change/commit and it did nothing.
| Truly the SVN daemon has put a curse on me. It must be jealous of
| me fooling around with git behind its back :-)

:-)

I truly wish I understood what was going wrong with your working copy :-(

\start
Date: Mon, 21 May 2007 01:57:48 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: changes

Gaby,

Per your request I've gone thru the differences and tried to classify
what the reason was for changing a file. A large number of these changes
are actually either changes by yourself or Waldek. I've tried to pick up
all the code I understood. The merge failed several times, breaking the
algebra builds, so I went back to the beginning and built some machinery
to detect this. Anything that broke the build or changed the algebra by
side-effect was rejected.

As I mentioned before these changes are from the march timeframe so
most of the SVN changes after that date are not yet included. There
are no changes for autoconf, for ansi, for your new-new-new boot, for
paste-file creation, or other efforts along those lines.

There are minimal algebra changes. I intend to spend time reviewing
the bug list to see what fixes we can incorporate. However I'm also
interested in documenting algebra files that we "open up" to change so
this could go rather slowly.

The best way to help in the effort is to create changesets that only
change one feature such as documenting one algebra file, or enabling
paste file generation. These need to be diff-Naur-ed against the
recently posted tree. Things will go much faster if people actually
help merge features and bug fixes. Please make sure your changes
actually build when applied to the recently posted tree.

My changes fall into five basic areas. 

* A fair bit of time was spent documenting quat.spad so that change
  is limited to that file plus a few .ps images.
  (src/algebra/quat.spad.pamphlet)

* The second set of changes involved writing machinery for regression
  testing which involved rewriting some 200+ input files and lisp code
  to check the results. (src/interp/regress.lisp.pamphlet)

* The third change involved interaction with Cliff about the cl-web and
  gclweb efforts. This is temporary until we move to an ansi-based lisp.
  (src/interp/gclweb.lisp)

* The fourth change involved writing a shell script to compute global
  md5 hashes so we can detect the global effect of local changes.
  This is basically to prevent interpreter changes from changing the
  compiled algebra. (src/regress/REGRESS)

* The fifth change involved prototyping a unit test mechanism for
  function level unit testing of algebra code. (src/algebra/Makefile)

The global sets of changes fall into these 22 categories (with some
overlap if files had mulitple reasons for changes). Each of these is
basically a changeset.

1) add regression testing so we can control checking for changes
  the basic idea is that we run the system, capture the output,
  put the output into the input files in a special form and then
  write code to check for changed behavior.

  src/interp/regress.lisp added, contains code
  src/interp/Makefile     add regress.lisp to build
  src/input/Makefile      add REGRES list
  src/input/algaggr.input.pamphlet 
  src/input/algbrbf.input.pamphlet 
  src/input/algfacob.input.pamphlet 
  src/input/alist.input.pamphlet 
  src/input/allfact.input.pamphlet 
  src/input/antoine.input.pamphlet 
  src/input/arith.input.pamphlet 
  src/input/array1.input.pamphlet 
  src/input/array2.input.pamphlet 
  src/input/arrows.input.pamphlet 
  src/input/assign.input.pamphlet 
  src/input/atansqrt.input.pamphlet 
  src/input/bags.input.pamphlet 
  src/input/bbtree.input.pamphlet 
  src/input/binary.input.pamphlet 
  src/input/bop.input.pamphlet 
  src/input/bouquet.input.pamphlet 
  src/input/bstree.input.pamphlet 
  src/input/bug10069.input.pamphlet 
  src/input/bug10312.input.pamphlet 
  src/input/bug6357.input.pamphlet 
  src/input/bug9057.input.pamphlet 
  src/input/bugs.input.pamphlet 
  src/input/calculus2.input.pamphlet 
  src/input/calculus.input.pamphlet 
  src/input/cardinal.input.pamphlet 
  src/input/card.input.pamphlet 
  src/input/carten.input.pamphlet 
  src/input/cclass.input.pamphlet 
  src/input/char.input.pamphlet 
  src/input/ch.input.pamphlet 
  src/input/clifford.input.pamphlet 
  src/input/clif.input.pamphlet 
  src/input/coercels.input.pamphlet 
  src/input/collect.input.pamphlet 
  src/input/complex.input.pamphlet 
  src/input/conformal.input.pamphlet 
  src/input/constant.input.pamphlet 
  src/input/contfrac.input.pamphlet 
  src/input/contfrc.input.pamphlet 
  src/input/curl.input.pamphlet 
  src/input/cycles1.input.pamphlet 
  src/input/cycles.input.pamphlet 
  src/input/cyfactor.input.pamphlet 
  src/input/danzwill.input.pamphlet 
  src/input/decimal.input.pamphlet 
  src/input/defintef.input.pamphlet 
  src/input/defintrf.input.pamphlet 
  src/input/derham.input.pamphlet 
  src/input/dfloat.input.pamphlet 
  src/input/dhtri.input.pamphlet 
  src/input/divisor.input.pamphlet 
  src/input/dmp.input.pamphlet 
  src/input/dpol.input.pamphlet 
  src/input/easter.input.pamphlet 
  src/input/efi.input.pamphlet 
  src/input/eigen.input.pamphlet 
  src/input/elemfun.input.pamphlet 
  src/input/elemnum.input.pamphlet 
  src/input/elfuts.input.pamphlet 
  src/input/elt.input.pamphlet 
  src/input/eq.input.pamphlet 
  src/input/eqtbl.input.pamphlet 
  src/input/equation2.input.pamphlet 
  src/input/equation.input.pamphlet 
  src/input/evalex.input.pamphlet 
  src/input/eval.input.pamphlet 
  src/input/exdiff.input.pamphlet 
  src/input/exint.input.pamphlet 
  src/input/exit.input.pamphlet 
  src/input/exlap.input.pamphlet 
  src/input/exlimit.input.pamphlet 
  src/input/expexpan.input.pamphlet 
  src/input/explim.input.pamphlet 
  src/input/expr1.input.pamphlet 
  src/input/expr.input.pamphlet 
  src/input/exprode.input.pamphlet 
  src/input/exprpoly.input.pamphlet 
  src/input/exseries.input.pamphlet 
  src/input/exsum.input.pamphlet 
  src/input/farray.input.pamphlet 
  src/input/ffdemo.input.pamphlet 
  src/input/fferr.input.pamphlet 
  src/input/ffx72.input.pamphlet 
  src/input/fib.input.pamphlet 
  src/input/file.input.pamphlet 
  src/input/float1.input.pamphlet 
  src/input/float2.input.pamphlet 
  src/input/float.input.pamphlet 
  src/input/fname1.input.pamphlet 
  src/input/fname.input.pamphlet 
  src/input/fnla.input.pamphlet 
  src/input/fns.input.pamphlet 
  src/input/fparfrac.input.pamphlet 
  src/input/fparfrc.input.pamphlet 
  src/input/fr1.input.pamphlet 
  src/input/fr2.input.pamphlet 
  src/input/frac.input.pamphlet 
  src/input/fr.input.pamphlet 
  src/input/galois.input.pamphlet 
  src/input/gbf.input.pamphlet 
  src/input/genups.input.pamphlet 
  src/input/gonshor.input.pamphlet 
  src/input/grpthry.input.pamphlet 
  src/input/gstbl.input.pamphlet 
  src/input/heap.input.pamphlet 
  src/input/heat.input.pamphlet 
  src/input/help.input.pamphlet 
  src/input/herm.input.pamphlet 
  src/input/hexadec.input.pamphlet 
  src/input/ico.input.pamphlet 
  src/input/ideal.input.pamphlet 
  src/input/ifact.input.pamphlet 
  src/input/infprod.input.pamphlet 
  src/input/intaf.input.pamphlet 
  src/input/intdeq.input.pamphlet 
  src/input/intef2.input.pamphlet 
  src/input/intef.input.pamphlet 
  src/input/intg0.input.pamphlet 
  src/input/intheory.input.pamphlet 
  src/input/int.input.pamphlet 
  src/input/intlf.input.pamphlet 
  src/input/intmix2.input.pamphlet 
  src/input/intmix.input.pamphlet 
  src/input/intrf.input.pamphlet 
  src/input/ipftest.input.pamphlet 
  src/input/is.input.pamphlet 
  src/input/isprime.input.pamphlet 
  src/input/kafile.input.pamphlet 
  src/input/kernel.input.pamphlet 
  src/input/knot2.input.pamphlet 
  src/input/kovacic.input.pamphlet 
  src/input/kuipers.input.pamphlet 
  src/input/laplace.input.pamphlet 
  src/input/leg.input.pamphlet 
  src/input/limit.input.pamphlet 
  src/input/lindep.input.pamphlet 
  src/input/list.input.pamphlet 
  src/input/lode.input.pamphlet 
  src/input/lodesys.input.pamphlet 
  src/input/lodo1.input.pamphlet 
  src/input/lodo2.input.pamphlet 
  src/input/lodo3.input.pamphlet 
  src/input/lodof.input.pamphlet 
  src/input/lodo.input.pamphlet 
  src/input/lpoly.input.pamphlet 
  src/input/lupfact.input.pamphlet 
  src/input/lword.input.pamphlet 
  src/input/macbug.input.pamphlet 
  src/input/macros.input.pamphlet 
  src/input/magma.input.pamphlet 
  src/input/mapleok.input.pamphlet 
  src/input/knownbugs.input.pamphlet 
  src/input/Makefile use grep to filter Timestamp
  src/input/mappkg1.input.pamphlet 
  src/input/matbug.input.pamphlet 
  src/input/matrix1.input.pamphlet 
  src/input/matrix22.input.pamphlet 
  src/input/matrix.input.pamphlet 
  src/input/mfinfact.input.pamphlet 
  src/input/mkfunc.input.pamphlet 
  src/input/mpoly.input.pamphlet 
  src/input/mset2.input.pamphlet 
  src/input/mset.input.pamphlet 
  src/input/multfact.input.pamphlet 
  src/input/multiple.input.pamphlet 
  src/input/ndftip.input.pamphlet 
  src/input/negfloats.input.pamphlet 
  src/input/nepip.input.pamphlet 
  src/input/newlodo.input.pamphlet 
  src/input/newton.input.pamphlet 
  src/input/nlode.input.pamphlet 
  src/input/none.input.pamphlet 
  src/input/noonburg.input.pamphlet 
  src/input/noptip.input.pamphlet 
  src/input/nqip.input.pamphlet 
  src/input/nsfip.input.pamphlet 
  src/input/numbers.input.pamphlet 
  src/input/oct.input.pamphlet 
  src/input/octonion.input.pamphlet 
  src/input/ode.input.pamphlet 
  src/input/odpol.input.pamphlet 
  src/input/op1.input.pamphlet 
  src/input/opalg.input.pamphlet 
  src/input/operator.input.pamphlet 
  src/input/op.input.pamphlet 
  src/input/ovar.input.pamphlet 
  src/input/padic.input.pamphlet 
  src/input/page.input.pamphlet
  src/input/parabola.input.pamphlet 
  src/input/pascal1.input.pamphlet 
  src/input/pascal.input.pamphlet 
  src/input/pat.input.pamphlet 
  src/input/patmatch.input.pamphlet 
  src/input/perman.input.pamphlet 
  src/input/perm.input.pamphlet 
  src/input/pfr1.input.pamphlet 
  src/input/pfr.input.pamphlet 
  src/input/pmint.input.pamphlet 
  src/input/poly1.input.pamphlet 
  src/input/polycoer.input.pamphlet 
  src/input/poly.input.pamphlet 
  src/input/psgenfcn.input.pamphlet 
  src/input/quat1.input.pamphlet 
  src/input/quat.input.pamphlet 
  src/input/r20abugs.input.pamphlet 
  src/input/r20bugs.input.pamphlet 
  src/input/r21bugsbig.input.pamphlet 
  src/input/r21bugs.input.pamphlet 
  src/input/radff.input.pamphlet 
  src/input/radix.input.pamphlet 
  src/input/realclos.input.pamphlet 
  src/input/reclos.input.pamphlet 
  src/input/reductio.input.pamphlet 
  src/input/repa6.input.pamphlet 
  src/input/robidoux.input.pamphlet 
  src/input/roman.input.pamphlet 
  src/input/roots.input.pamphlet 
  src/input/ruleset.input.pamphlet 
  src/input/rules.input.pamphlet 
  src/input/scherk.input.pamphlet 
  src/input/scope.input.pamphlet 
  src/input/segbind.input.pamphlet 
  src/input/seg.input.pamphlet 
  src/input/series2.input.pamphlet 
  src/input/series.input.pamphlet 
  src/input/sersolve.input.pamphlet 
  src/input/set.input.pamphlet 
  src/input/sinCosEx.input.pamphlet 
  src/input/sint.input.pamphlet 
  src/input/skew.input.pamphlet 
  src/input/slowint.input.pamphlet 
  src/input/solvetra.input.pamphlet 
  src/input/space3.input.pamphlet 
  src/input/sqmatrix.input.pamphlet 
  src/input/sregset.input.pamphlet 
  src/input/stbl.input.pamphlet 
  src/input/stream2.input.pamphlet 
  src/input/stream.input.pamphlet 
  src/input/streams.input.pamphlet 
  src/input/string.input.pamphlet 
  src/input/strtbl.input.pamphlet 
  src/input/symbol.input.pamphlet 
  src/input/t111293.input.pamphlet 
  src/input/table.input.pamphlet 
  src/input/tanatan.input.pamphlet 
  src/input/textfile.input.pamphlet 
  src/input/torus.input.pamphlet 
  src/input/tree.input.pamphlet 
  src/input/triglim.input.pamphlet 
  src/input/tsetcatvermeer.input.pamphlet 
  src/input/tutchap1.input.pamphlet 
  src/input/uniseg.input.pamphlet 
  src/input/void.input.pamphlet 

2) We need to be able to wipe out the int/input subdir so we
   can rerun all of the test cases. The current stanza set
   assumed we were doing a full build. A stanza was added to
   the Makefile to cover this case
   src/input/Makefile

3) Newly created documentation added or fixed
   src/algebra/quat.spad
   src/algebra/Makefile
   src/doc/ps/quat*.ps
   src/boot/ptyout.boot
   src/boot/typars.boot
   src/doc/book.pamphlet
   src/doc/Rosetta.pamphlet
   FAQ

4) src/scripts/document and axiom.sty everywhere
     The document command assumed that it was working only during the
     build phase so it often could not find axiom.sty. This has been
     fixed. Now all of the following files only usepackage axiom
     without a path.
   src/Makefile.pamphlet
   src/algebra/Makefile.pamphlet
   src/doc/Makefile.pamphlet
   src/doc/Rosetta.booklet
   src/doc/Sorting.booklet
   src/boot/Makefile.pamphlet
   src/clef/Makefile.pamphlet
   src/doc/Makefile.pamphlet
   src/doc/axiom.bib.pamphlet
   src/doc/booklet.c.pamphlet
   src/doc/endpaper.pamphlet
   src/doc/primesp.spad.pamphlet
   src/etc/Makefile.pamphlet
   src/etc/asq.c.pamphlet
   src/graph/Gdraws/Makefile.pamphlet
   src/graph/Makefile.pamphlet
   src/graph/view2D/Makefile.pamphlet
   src/graph/view3D/Makefile.pamphlet
   src/graph/viewAlone/Makefile.pamphlet
   src/graph/viewman/Makefile.pamphlet
   src/hyper/Makefile.pamphlet
   src/input/Makefile.pamphlet
   src/interp/Makefile.pamphlet
   src/lib/Makefile.pamphlet
   src/scripts/Makefile.pamphlet
   src/scripts/boxhead
   src/share/Makefile.pamphlet
   src/sman/Makefile.pamphlet
   lsp/Makefile.pamphlet 

5) Removed a time-bomb in the code that stalls the axiom build.
   src/algebra/clifford.spad.pamphlet
   src/doc/diagrams.tex
   src/doc/Makefile.pamphlet
   
6) use \providecmd to prevent conflicting cmd names
     latex will not allow duplicate definitions of commands unless
     you use \providecmd. In order to keep axiom.sty from conflicting
     with other packages it was rewritten to use \providecmd.
   src/doc/axiom.sty.pamphlet
   src/scripts/tex/axiom.sty
   src/doc/bookvol1.pamphlet
   src/algebra/clifford.pamphlet
   
7) removed axiom.sty stanza and their dependencies. 
     the changes to the document command remove the need and this
     stanza forces many unnecessary rebuilds.
   src/algebra/Makefile
   src/boot/Makefile
   src/clef/Makefile
   src/graph/Gdraws/Makefile.pamphlet
   src/graph/Makefile.pamphlet
   src/graph/view2D/Makefile.pamphlet
   src/graph/view3D/Makefile.pamphlet
   src/graph/viewAlone/Makefile.pamphlet
   src/graph/viewman/Makefile.pamphlet
   src/hyper/Makefile.pamphlet
   src/input/Makefile.pamphlet
   src/interp/Makefile.pamphlet
   src/lib/Makefile.pamphlet
   src/sman/Makefile.pamphlet

8) bring the FAQ up to date
   FAQ 41: How can I work in lisp from Axiom?
   FAQ 42: How can I output equations as lisp s-expressions?
   FAQ 43: Is Axiom's License compatible with the GPL?

9) bring the list of credits up to date
   README add credits
   src/interp/setq.lisp add credits

10) fix random typos, add documentation
    src/algebra/attreg.spad imples -> implies
    src/etc/asq.c add documentation
    src/interp/bookvol5 add documentation
    src/sman/spadclient.c fix title
    src/sman/sman.c add docs
    src/doc/book.pamphlet fix typos
    src/doc/DeveloperNotes fix typo
    src/doc/endpaper fix usepackage
    src/doc/primesp.spad fix usepackage
    src/doc/axiom.bib underscore renaming
    src/hyper/show-types.pamphlet underscore renaming
    src/hyper/form-ext.pamphlet fix underscores
    src/hyper/token.pamphlet fix chunk name
    src/interp/compiler.boot.pamphlet add docs
    src/interp/i-eval.boot.pamphlet move doc to latex format
    src/lib/bsdsignal.c.pamphlet update docs

11) regress from GCLVERSION=gcl.2.6.8pre2 to GCLVERSION=gcl.2.6.8pre
    Makefile.pamphlet
    Makefile

12) prototype unit-test machinery
    acplot.spad.pamphlet 

13) remove dead files
    src/algebra/Lattice.pamphlet old attempt to define the algebra lattice.
    src/hyper/bitmaps/ht_icon  this is dynamically generated
    src/include/useproto.h   no longer used due to PROTO removal
    src/interp/anna.boot
    src/interp/construc.lisp
    src/interp/domain.lisp
    src/interp/guess.boot
    src/interp/interp-fix.boot
    src/interp/pf2atree.boot
    src/interp/redefs.boot
    src/interp/word.boot
    src/interp/ccl-depsys.lsp

14) file renames due to windows/mac underscore/dash issues
      apparently windows and mac file systems are character sensitive
    src/graph/include/all_2d.H1 -> all-2d.H1
    src/graph/include/all_3d.H1 -> all-3d.H1
    src/graph/include/all_alone.H1 -> all-alone.H1
    src/hyper/bitmaps/Im.bitmap -> im-cap.bitmap
    src/hyper/bitmaps/Re.bitmap -> re-cap.bitmap
    src/include/all_hyper_proto.H1 -> all-hyper-proto.H1 
    src/include/fnct_key.H1 -> fnct-key.H1
    src/include/form_ext.H1 -> form-ext.H1
    src/include/parse_aux.H1 -> parse-aux.H1
    src/include/parse_input.H1 -> parse-input.H1
    src/include/parse_paste.H1 -> parse-paste.H1
    src/include/parse_types.H1 -> parse-types.H1
    src/include/show_types.H1 -> show-types.H1
    src/lib/fnct_key.c -> fnct-key.c
    src/graph/view2D/buttons2d.c fix internal names
    src/graph/view2D/control2d.c fix internal names
    src/graph/view2D/graph2d.c fix internal names
    src/graph/view2D/main2d.c fix internal names
    src/graph/view2D/pot2d.c fix internal names
    src/graph/view2D/process2d.c fix internal names
    src/graph/view2D/spadAction2d.c fix internal names
    src/graph/view2D/stuff2d.c fix internal names
    src/graph/view2D/viewport2D.c fix internal names
    src/graph/view2D/write2d.c fix internal names
    src/graph/view3D/buttons3d.c fix internal names
    src/graph/view3D/closeView3d.c fix internal names
    src/graph/view3D/component3d.c fix internal names
    src/graph/view3D/control3d.c fix internal names
    src/graph/view3D/illuminate3d.c fix internal names
    src/graph/view3D/lightbut3d.c fix internal names
    src/graph/view3D/lighting3d.c fix internal names
    src/graph/view3D/main3d.c fix internal names
    src/graph/view3D/mesh3d.c fix internal names
    src/graph/view3D/msort3d.c fix internal names
    src/graph/view3D/pot3d.c fix internal names
    src/graph/view3D/process3d.c fix internal names
    src/graph/view3D/project3d.c fix internal names
    src/graph/view3D/quit3d.c fix internal names
    src/graph/view3D/quitbut3d.c fix internal names
    src/graph/view3D/save3d.c fix internal names
    src/graph/view3D/savebut3d.c fix internal names
    src/graph/view3D/smoothShade3d.c fix internal names
    src/graph/view3D/spadAction3d.c fix internal names
    src/graph/view3D/stuff3d.c fix internal names
    src/graph/view3D/surface3d.c fix internal names
    src/graph/view3D/testcol.c fix internal names
    src/graph/view3D/transform3d.c fix internal names
    src/graph/view3D/viewport3d.c fix internal names
    src/graph/view3D/volume3d.c fix internal names
    src/graph/view3D/write3d.c fix internal names
    src/graph/viewAlone/spoon2D.c fix internal names
    src/graph/viewAlone/spoonComp.c fix internal names
    src/graph/viewAlone/viewAlone.c fix internal names
    src/hyper/initx.pamphlet fix internal names
    src/hyper/input.pamphlet fix internal names
    src/hyper/item.pamphlet fix internal names
    src/hyper/keyin.pamphlet fix internal names
    src/hyper/lex.pamphlet fix internal names
    src/hyper/macro.pamphlet fix internal names
    src/hyper/mem.pamphlet fix internal names
    src/hyper/parse-aux.pamphlet fix internal names
    src/hyper/parse-input.pamphlet fix internal names
    src/hyper/parse.pamphlet fix internal names
    src/hyper/parse-paste.pamphlet fix internal names
    src/hyper/parse-types.pamphlet fix internal names
    src/hyper/ReadBitmap.pamphlet fix internal names
    src/hyper/scrollbar.pamphlet fix internal names
    src/hyper/show-types.pamphlet fix internal names
    src/hyper/spadbuf.pamphlet fix internal names
    src/hyper/spadint.pamphlet fix internal names
    src/hyper/titlebar.pamphlet fix internal names
    src/lib/edin.c.pamphlet fix internal names

15) fix c warnings
    src/sman/sman.c fix type casts
    src/include/cfuns-c.H1 comment out unused code

16) fix latex warnings about line lengths
    src/sman/session.c.pamphlet 
    src/graph/Gdraws/Gfun.c 
    src/graph/include/fun2D.H1 
    src/graph/include/make2D.H1 
    src/graph/include/make3D.H1 
    src/graph/include/mesh3d.H1 
    src/graph/include/project3d.H1 
    src/graph/include/sselect.H1 
    src/graph/view3D/mesh3d.c 
    src/graph/viewAlone/spoon2D.c 
    src/graph/viewman/fun2D.c 
    src/graph/viewman/makeGraph.c 
    src/hyper/htinp.pamphlet 
    src/hyper/macro.pamphlet 
    src/hyper/spadint.pamphlet 
    src/include/dialog.H1
    src/include/hash.H1
    src/include/htadd.H1
    src/include/htinp.H1
    src/include/pixmap.H1
    src/include/ReadBitmap.H1
    src/include/scrollbar.H1
    src/include/spadint.H1
    src/include/XDither.H1
    src/include/XShade.H1
    src/include/XSpadFill.H1
    src/interp/br-op1.boot.pamphlet
    src/interp/br-op2.boot.pamphlet

17) change merged code
    src/sman/session.c.pamphlet don't make out-of-sync fatal

18) remove PROTO
    src/sman/nagman.c.pamphlet
    src/clef/edible.c.pamphlet
    src/graph/view2D/buttons2d.c
    src/graph/view2D/control2d.c
    src/graph/view2D/graph2d.c
    src/graph/view2D/main2d.c
    src/graph/view2D/pot2d.c
    src/graph/view2D/process2d.c
    src/graph/view2D/spadAction2d.c
    src/graph/view2D/stuff2d.c
    src/graph/view2D/viewport2D.c
    src/graph/view2D/write2d.c
    src/graph/view3D/buttons3d.c
    src/graph/view3D/closeView3d.c
    src/graph/view3D/component3d.c
    src/graph/view3D/control3d.c
    src/graph/view3D/illuminate3d.c
    src/graph/view3D/lightbut3d.c
    src/graph/view3D/lighting3d.c
    src/graph/view3D/main3d.c
    src/graph/view3D/msort3d.c
    src/graph/view3D/pot3d.c
    src/graph/view3D/process3d.c
    src/graph/view3D/project3d.c
    src/graph/view3D/quit3d.c
    src/graph/view3D/quitbut3d.c
    src/graph/view3D/save3d.c
    src/graph/view3D/savebut3d.c
    src/graph/view3D/smoothShade3d.c
    src/graph/view3D/spadAction3d.c
    src/graph/view3D/stuff3d.c
    src/graph/view3D/surface3d.c
    src/graph/view3D/testcol.c
    src/graph/view3D/transform3d.c
    src/graph/view3D/viewport3d.c
    src/graph/view3D/volume3d.c
    src/graph/view3D/write3d.c
    src/graph/viewAlone/spoon2D.c
    src/graph/viewAlone/spoonComp.c
    src/graph/viewAlone/viewAlone.c
    src/graph/viewman/fun3D.c
    src/graph/viewman/make2D.c
    src/graph/viewman/make3D.c
    src/graph/viewman/makeGraph.c
    src/graph/viewman/readView.c
    src/graph/viewman/sselect.c
    src/graph/viewman/viewman.c
    src/hyper/addfile.pamphlet
    src/hyper/cond.pamphlet
    src/hyper/debug.pamphlet
    src/hyper/dialog.pamphlet
    src/hyper/display.pamphlet
    src/hyper/event.pamphlet
    src/hyper/ex2ht.pamphlet
    src/hyper/extent1.pamphlet
    src/hyper/extent2.pamphlet
    src/hyper/group.pamphlet
    src/hyper/halloc.pamphlet
    src/hyper/hash.pamphlet
    src/hyper/htadd.pamphlet
    src/hyper/hterror.pamphlet
    src/hyper/htinp.pamphlet
    src/hyper/hyper.pamphlet
    src/hyper/initx.pamphlet
    src/hyper/input.pamphlet
    src/hyper/item.pamphlet 
    src/hyper/keyin.pamphlet
    src/hyper/lex.pamphlet
    src/hyper/mem.pamphlet
    src/hyper/scrollbar.pamphlet
    src/include/view.h

19) prettyprint lisp code
    src/interp/clam.boot.pamphlet
    src/interp/c-util.boot.pamphlet

20) cliff's clweb prototype for GCL
    src/interp/gclweb.lisp

21) new regression testing code
    src/interp/regress.lisp.pamphlet  implements (regress "foo.output")

22) modify lisp code
    src/interp/database.boot.pamphlet remove lisp code
    src/interp/debugsys.lisp.pamphlet modify loads 
    src/interp/define.boot.pamphlet local nil
    src/interp/interp-proclaims.lisp modify exports
    src/interp/bookvol5 fix misspelling of clearCmdparts 

\start
Date: Mon, 21 May 2007 02:19:17 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: changes

On Mon, 21 May 2007, Tim Daly wrote:

| Gaby,
| 
| Per your request I've gone thru the differences and tried to classify
| what the reason was for changing a file.

Many thanks; this will help me understand the new tree, and bringing
build-improvements in line as much as can.

[...]

| 14) file renames due to windows/mac underscore/dash issues
|       apparently windows and mac file systems are character sensitive

They are case preserving, but case INSENSITIVE.
yeah, a concept of its own.

\start
Date: Mon, 21 May 2007 10:39:15 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: TeXmacs+Axiom

On 05/21/2007 03:40 AM, Gabriel Dos Reis wrote:
> Bill Page writes:
> 
> [...]
> 
> | > I don't understand C very well,
> | 
> | Every time someone on this list says "I don't understand X"
> | but they already program in Aldor/Spad/Lisp or whatever, it
> | makes me wonder about their motivations as opposed to their
> | skill ... :-)

I did not say that I cannot read C at all, but it is one of the 
languages that I had never much need to learn by heart.

And my motivations are "programming mathematics". C is an assembly 
language for me.

> | "C" is a particularly simple language.
> 
> Fully agreed.

Of course, every one (also those not knowledgable in C) know how to parse

    int *x[5]

I find

   (int *)[5] x

or

   (int[5]) * x

easier to understand.

Of course I could learn C and do a project to become fully acquaint with 
it. But that would probably cost me several months.

If, however programs were literate, I could perhaps even improve them 
without being an every day C programmer.

I hope you understand that this was my point and not whether someone can 
program in this or that language.

Programming a Turing machine is also a very simple, but not very 
practical if you your motivations lie in the implementation of mathematics.

\start
Date: Mon, 21 May 2007 11:56:22 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: changes
Cc: Gabriel Dos Reis

> 6) use \providecmd to prevent conflicting cmd names
>      latex will not allow duplicate definitions of commands unless
>      you use \providecmd. In order to keep axiom.sty from conflicting
>      with other packages it was rewritten to use \providecmd.
>    src/doc/axiom.sty.pamphlet
>    src/scripts/tex/axiom.sty
>    src/doc/bookvol1.pamphlet
>    src/algebra/clifford.pamphlet

You probably mean \providecommand.

http://www-h.eng.cam.ac.uk/help/tpl/textprocessing/teTeX/latex/latex2e-html/ltx-18.html

But I wonder about the following things:

1. Why is src/scripts/tex/axiom.sty under revision control? Wouln't
src/doc/axiom.sty.pamphlet be enough?

2. src/doc/bookvol1.pamphlet: Given the meaning of \providecommand (and 
even without it), why would there be need to define commands in bookvol1 
if there is axiom.sty?

3. src/algebra/clifford.pamphlet or any other algebra file: I would be 
happy if *no* pamphlet had to specify additional styles. But for the 
moment I am quiet.

\start
Date: Mon, 21 May 2007 12:20:21 +0200 (CEST)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: Silver

> SILVER
> 
> The latest, merged version will momentarily be available as
> a silver version. 
>

AFAICS the version in daly branch misses hyper subdirectory.
 
\start
Date: 21 May 2007 08:00:57 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] Definition of global variables

  This patchlet fixes translation of Boot definition of global variables.

Currently, an assignment to a Boot global variable (which actually is a
definition) is translated to Lisp in terms of SETQ.  That elicites
irritating warnings from Lisp compilers to the effect that the
variable is undefined. The resulting share noise obscures the rest of
other useful warnings.  The fix is a one-liner.  The rest of the patch
consists of the mechnical update of the cached Lisp translation.  One
day, the latter will go away.

Applid to build-improvements.

-- Gaby

2007-05-21  Gabriel Dos Reis  Gabriel Dos Reis

	Translate definitions of global variables as defparameters.
	* ast.boot.pamphlet: Update Lisp translation.
	* includer.boot.pamphlet: Likwise.
	* tokens.boot.pamphlet: Likewise.
	* translator.boot.pamphlet (bpOutItem): Use DEFPARAMETER for
	assignment at global scope.
	Update Lisp translation.

*** ast.boot.pamphlet	(revision 15502)
--- ast.boot.pamphlet	(local)
*************** bfDs n== if n=0 then '"" else CONCAT('"D
*** 1001,1007 ****
  <<ast.clisp>>=
  (IN-PACKAGE "BOOTTRAN")
  
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) (SETQ |$inDefIS| NIL))
  
  (DEFUN |bfGenSymbol| ()
    (PROG ()
--- 1001,1007 ----
  <<ast.clisp>>=
  (IN-PACKAGE "BOOTTRAN")
  
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) (DEFPARAMETER |$inDefIS| NIL))
  
  (DEFUN |bfGenSymbol| ()
    (PROG ()
*** includer.boot.pamphlet	(revision 15502)
--- includer.boot.pamphlet	(local)
*************** bPremStreamNull(s)==
*** 519,525 ****
  <<includer.clisp>>=
  (IN-PACKAGE "BOOTTRAN")
  
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) (SETQ |bStreamNil| (LIST '|nullstream|)))
  
  (DEFUN |char| (|x|) (PROG () (RETURN (CHAR (PNAME |x|) 0))))
  
--- 519,526 ----
  <<includer.clisp>>=
  (IN-PACKAGE "BOOTTRAN")
  
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (DEFPARAMETER |bStreamNil| (LIST '|nullstream|)))
  
  (DEFUN |char| (|x|) (PROG () (RETURN (CHAR (PNAME |x|) 0))))
  
*** scanner.boot.pamphlet	(revision 15502)
--- scanner.boot.pamphlet	(local)
*************** shoePunCons()==
*** 580,586 ****
    (PROG () (RETURN (AND (CONSP |x|) (EQ (CAR |x|) |y|)))))
    
  (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (SETQ *READ-DEFAULT-FLOAT-FORMAT* 'DOUBLE-FLOAT))
  
  (DEFUN DOUBLE (|x|) (PROG () (RETURN (FLOAT |x| 1.0))))
  
--- 580,586 ----
    (PROG () (RETURN (AND (CONSP |x|) (EQ (CAR |x|) |y|)))))
    
  (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER *READ-DEFAULT-FLOAT-FORMAT* 'DOUBLE-FLOAT))
  
  (DEFUN DOUBLE (|x|) (PROG () (RETURN (FLOAT |x| 1.0))))
  
*** tokens.boot.pamphlet	(revision 15502)
--- tokens.boot.pamphlet	(local)
*************** for i in [ _
*** 400,466 ****
  (IN-PACKAGE "BOOTTRAN")
  
  (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (SETQ |shoeKeyWords|
!         (LIST (LIST "and" 'AND) (LIST "by" 'BY) (LIST "case" 'CASE)
!               (LIST "cross" 'CROSS) (LIST "else" 'ELSE)
!               (LIST "for" 'FOR) (LIST "if" 'IF) (LIST "in" 'IN)
!               (LIST "is" 'IS) (LIST "isnt" 'ISNT) (LIST "of" 'OF)
!               (LIST "or" 'OR) (LIST "repeat" 'REPEAT)
!               (LIST "return" 'RETURN) (LIST "structure" 'STRUCTURE)
!               (LIST "then" 'THEN) (LIST "until" 'UNTIL)
!               (LIST "where" 'WHERE) (LIST "while" 'WHILE)
!               (LIST "." 'DOT) (LIST ":" 'COLON) 
!               (LIST "::" 'COLON-COLON) (LIST "," 'COMMA) 
!               (LIST ";" 'SEMICOLON) (LIST "*" 'TIMES)
!               (LIST "**" 'POWER) (LIST "/" 'SLASH) (LIST "+" 'PLUS)
!               (LIST "-" 'MINUS) (LIST "<" 'LT) (LIST ">" 'GT)
!               (LIST "<=" 'LE) (LIST ">=" 'GE) (LIST "=" 'SHOEEQ)
!               (LIST "^" 'NOT) (LIST "^=" 'NE) (LIST ".." 'SEG)
!               (LIST "#" 'LENGTH) (LIST "=>" 'EXIT) (LIST ":=" 'BEC)
!               (LIST "==" 'DEF) (LIST "==>" 'MDEF) (LIST "(" 'OPAREN)
!               (LIST ")" 'CPAREN) (LIST "(|" 'OBRACK)
!               (LIST "|)" 'CBRACK) (LIST "[" 'OBRACK) (LIST "]" 'CBRACK)
!               (LIST "suchthat" 'BAR) (LIST "'" 'QUOTE) (LIST "|" 'BAR))))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (SETQ |shoeKeyTable| (|shoeKeyTableCons|)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (SETQ |shoeSPACE| (QENUM "    " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (SETQ |shoeESCAPE| (QENUM "_  " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (SETQ |shoeLispESCAPE| (QENUM "!  " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (SETQ |shoeSTRINGCHAR| (QENUM "\"  " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (SETQ |shoePLUSCOMMENT| (QENUM "+   " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (SETQ |shoeMINUSCOMMENT| (QENUM "-   " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (SETQ |shoeDOT| (QENUM ".   " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (SETQ |shoeEXPONENT1| (QENUM "E   " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (SETQ |shoeEXPONENT2| (QENUM "e   " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (SETQ |shoeCLOSEPAREN| (QENUM ")   " 0)))
  
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) (SETQ |shoeTAB| 9))
  
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) 
!   (SETQ |shoeDict| (|shoeDictCons|)))
  
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) (SETQ |shoePun| (|shoePunCons|)))
  
  (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
    (PROG ()
--- 400,466 ----
  (IN-PACKAGE "BOOTTRAN")
  
  (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoeKeyWords|
!       (LIST (LIST "and" 'AND) (LIST "by" 'BY) (LIST "case" 'CASE)
!             (LIST "cross" 'CROSS) (LIST "else" 'ELSE) (LIST "for" 'FOR)
!             (LIST "if" 'IF) (LIST "in" 'IN) (LIST "is" 'IS)
!             (LIST "isnt" 'ISNT) (LIST "of" 'OF) (LIST "or" 'OR)
!             (LIST "repeat" 'REPEAT) (LIST "return" 'RETURN)
!             (LIST "structure" 'STRUCTURE) (LIST "then" 'THEN)
!             (LIST "until" 'UNTIL) (LIST "where" 'WHERE)
!             (LIST "while" 'WHILE) (LIST "." 'DOT) (LIST ":" 'COLON)
!             (LIST "::" 'COLON-COLON) (LIST "," 'COMMA)
!             (LIST ";" 'SEMICOLON) (LIST "*" 'TIMES) (LIST "**" 'POWER)
!             (LIST "/" 'SLASH) (LIST "+" 'PLUS) (LIST "-" 'MINUS)
!             (LIST "<" 'LT) (LIST ">" 'GT) (LIST "<=" 'LE)
!             (LIST ">=" 'GE) (LIST "=" 'SHOEEQ) (LIST "^" 'NOT)
!             (LIST "^=" 'NE) (LIST ".." 'SEG) (LIST "#" 'LENGTH)
!             (LIST "=>" 'EXIT) (LIST ":=" 'BEC) (LIST "==" 'DEF)
!             (LIST "==>" 'MDEF) (LIST "(" 'OPAREN) (LIST ")" 'CPAREN)
!             (LIST "(|" 'OBRACK) (LIST "|)" 'CBRACK) (LIST "[" 'OBRACK)
!             (LIST "]" 'CBRACK) (LIST "suchthat" 'BAR) (LIST "'" 'QUOTE)
!             (LIST "|" 'BAR))))
  
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoeKeyTable| (|shoeKeyTableCons|)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoeSPACE| (QENUM "    " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoeESCAPE| (QENUM "_  " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoeLispESCAPE| (QENUM "!  " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoeSTRINGCHAR| (QENUM "\"  " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoePLUSCOMMENT| (QENUM "+   " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoeMINUSCOMMENT| (QENUM "-   " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoeDOT| (QENUM ".   " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoeEXPONENT1| (QENUM "E   " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoeEXPONENT2| (QENUM "e   " 0)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoeCLOSEPAREN| (QENUM ")   " 0)))
  
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) (DEFPARAMETER |shoeTAB| 9))
  
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoeDict| (|shoeDictCons|)))
! 
! (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
!   (DEFPARAMETER |shoePun| (|shoePunCons|)))
  
  (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
    (PROG ()
*** translator.boot.pamphlet	(revision 15502)
--- translator.boot.pamphlet	(local)
*************** bpOutItem()==
*** 419,425 ****
      EQCAR(b,"TUPLE")=> bpPush cdr b
      EQCAR(b,"+LINE")=> bpPush [ b ]
      b is ["L%T",l,r] and IDENTP l =>
!                  bpPush [shoeEVALANDFILEACTQ ["SETQ",l,r]]
      b:=shoeCompTran ["LAMBDA",["x"],b]
      bpPush [shoeEVALANDFILEACTQ CADDR b]
   
--- 419,425 ----
      EQCAR(b,"TUPLE")=> bpPush cdr b
      EQCAR(b,"+LINE")=> bpPush [ b ]
      b is ["L%T",l,r] and IDENTP l =>
!                  bpPush [shoeEVALANDFILEACTQ ["DEFPARAMETER",l,r]]
      b:=shoeCompTran ["LAMBDA",["x"],b]
      bpPush [shoeEVALANDFILEACTQ CADDR b]
   
*************** PSTOUT string==
*** 1369,1375 ****
                                (PROGN (SETQ |r| (CAR |ISTMP#2|)) 'T)))))
                  (IDENTP |l|))
             (|bpPush|
!                (LIST (|shoeEVALANDFILEACTQ| (LIST 'SETQ |l| |r|)))))
            ('T
             (PROGN
               (SETQ |b| (|shoeCompTran| (LIST 'LAMBDA (LIST '|x|) |b|)))
--- 1369,1376 ----
                                (PROGN (SETQ |r| (CAR |ISTMP#2|)) 'T)))))
                  (IDENTP |l|))
             (|bpPush|
!                (LIST (|shoeEVALANDFILEACTQ| 
!                          (LIST 'DEFPARAMETER |l| |r|)))))
            ('T
             (PROGN
               (SETQ |b| (|shoeCompTran| (LIST 'LAMBDA (LIST '|x|) |b|)))

\start
Date: Mon, 21 May 2007 23:06:01 +1000
From: Alasdair McAndrew
To: list
Subject: Two emacs questions

------=_Part_69104_31849202.1179752761488

1)  In using the axiommode.el file by Jay Belanger, Cliff Yapp, and Francois
Maltey, it hangs on "M-x run-axiom" when trying to parse my ".axiom.input"
file.  From a console, both axiom and AXIOMsys start with no problems - how
can I debug my input file?  What might be causing it to hang?

2)  Is there an emacs mode which includes the usual niceties: syntax
highlighting, automatic indentation etc, for writing .input files?

\start
Date: 21 May 2007 08:13:18 -0500
From: Gabriel Dos Reis
To: Alasdair McAndrew
Subject: Re: Two emacs questions

Alasdair McAndrew writes:

| 
| 2)  Is there an emacs mode which includes the usual niceties: syntax
| highlighting, automatic indentation etc, for writing .input files?

I don't know of any.

Spad and its input dialect are so relatively close to Haskell, so you
might srating steeling the Haskell mode for Emacs... (I haven' tried
it).  I'm sure it can be worked out.

   http://haskell.org/haskell-mode/

\start
Date: Mon, 21 May 2007 08:55:59 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: changes

1) The axiom.sty is under revision control because it is needed early
   in the process, as are most of the things in the scripts directory.
   Perhaps the need has gone away over time but i doubt it.

2) bookvol1 was published "standalone" so it did not depend on 
   .sty files which are not in the standard latex distro. The
   axiom.sty file is not standard so the commands were put into the file.

3) I don't like the idea of additional .sty files either. Some of the
   commands I've needed from other .sty files have migrated into 
   axiom.sty. This will allow us to have all of the functionality for
   our "standard" files. Using \providecmd allows people to use other
   .sty files without errors.

   However, in some files I've been documenting I need to do things 
   like draw diagrams using special purpose packages. For instance,
   I'm documenting the octonions now and there is a "standard"
   octonion triangle that I'm drawing with xypic. Eventually I'll
   make it into a .ps file and we can remove the include.

\start
Date: Mon, 21 May 2007 08:58:33 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: changes

re: hyper missing

yes, i saw that early this morning. thanks. 
i'll update the checking as soon as i can.

\start
Date: Mon, 21 May 2007 09:04:38 -0500 (CDT)
From: Gabriel Dos Reis
To: Alasdair McAndrew
Subject: Re: Two emacs questions

On Mon, 21 May 2007, Alasdair McAndrew wrote:

| Thanks, Gabriel.
| 
| I've had a brief look at haskell-mode.el, and I *suppose* it could be
| re-fashioned to work as a spad mode, but that may require somebody with more
| time than me.  I'm having enough trouble trying to get comfortable with
| Axiom, never mind supporting stuff!

That is understandable.

| What do you use yourself for your own Axiom development?

Two terminals and an Emacs in either text mode or Lisp mode.
Pretty primitive, right?

\start
Date: 21 May 2007 16:10:52 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: changes

Tim Daly writes:

> 3) I don't like the idea of additional .sty files either. Some of the
>    commands I've needed from other .sty files have migrated into 
>    axiom.sty. This will allow us to have all of the functionality for
>    our "standard" files. Using \providecmd allows people to use other
>    .sty files without errors.
> 
>    However, in some files I've been documenting I need to do things 
>    like draw diagrams using special purpose packages. For instance,
>    I'm documenting the octonions now and there is a "standard"
>    octonion triangle that I'm drawing with xypic. Eventually I'll
>    make it into a .ps file and we can remove the include.

Please don't. Include xy instead, I'm using it too.  The postscript is
absolutely useless for documentation purposes, because it is difficult to
modify.

I think quite on the contrary, the possibility of including packages lowers the
barrier to write documentation, even if only a bit.

I.e., also include amsmath and amsfonts, please!

\start
Date: Mon, 21 May 2007 10:01:54 -0500 (CDT)
From: Gabriel Dos Reis
To: Alasdair McAndrew
Subject: Re: Two emacs questions

On Tue, 22 May 2007, Alasdair McAndrew wrote:

| >
| >
| > Two terminals and an Emacs in either text mode or Lisp mode.
| > Pretty primitive, right?
| >
| > -- Gaby
| >
| 
| Well, whatever works.... but my feeling is that most of Axiom's support
| (online help, interfaces, and the like) are pretty primitive.  Maybe I've
| just been spoiled by the support available for other systems.

Axiom, no doubt, needs more resources to compensate in those areas.
I was hoping that as you're discovering those things, and hopefully get them
sorted out, you might consider contribute your findings, etc.

\start
Date: Mon, 21 May 2007 17:16:31 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: changes

On 05/21/2007 03:55 PM, Tim Daly wrote:
> 1) The axiom.sty is under revision control because it is needed early
>    in the process, as are most of the things in the scripts directory.
>    Perhaps the need has gone away over time but i doubt it.

Gaby, can you give a better guess than me?

> 2) bookvol1 was published "standalone" so it did not depend on 
>    .sty files which are not in the standard latex distro. The
>    axiom.sty file is not standard so the commands were put into the file.

Hmmm, the first two lines of

branches/daly/axiom/src/doc/bookvol1.pamphlet

read

\documentclass{book}
\usepackage{axiom}

you certainly mean another file.


> 3) I don't like the idea of additional .sty files either. Some of the
>    commands I've needed from other .sty files have migrated into 
>    axiom.sty. This will allow us to have all of the functionality for
>    our "standard" files. Using \providecmd allows people to use other
>    .sty files without errors.

Sorry, I did not say that I don't like additional .sty files. I said, I 
don't like commands defined in .pamphlet files.
Well \providecommand does not change the definition of a command that 
has been defined in a previous package. So that might lead to unexpected 
output for the author. It's just my warning. I cannot do anything about 
it at th moment.

>    However, in some files I've been documenting I need to do things 
>    like draw diagrams using special purpose packages. For instance,
>    I'm documenting the octonions now and there is a "standard"
>    octonion triangle that I'm drawing with xypic. Eventually I'll
>    make it into a .ps file and we can remove the include.

No problem. For now you can use whatever you like. But there will be 
times when we should give out some better guidelines that can be 
maintained easily.

\start
Date: Mon, 21 May 2007 08:43:27 -0700 (PDT)
From: Cliff Yapp
To: Alasdair McAndrew
Subject: Re: Two emacs questions

--- Alasdair McAndrew wrote:

> 1)  In using the axiommode.el file by Jay Belanger, Cliff Yapp, and
> Francois Maltey, it hangs on "M-x run-axiom" when trying to parse my
> ".axiom.input" file.  From a console, both axiom and AXIOMsys start
> with no problems - how can I debug my input file?  What might be
> causing it to hang?

At a guess, the hack that avoids the double prompt effect may be
gagging if your .axiom.input file adds any extra output it's not
expecting to see at that stage (not sure when .axiom.input gets
evaluated relative to the second prompt generation.)

I guess if you disable the cleanup hack you would avoid the problem. I
was/am very annoyed by it so I cleaned it up, but it looks like
(surprise) the hack broke down.

> 2)  Is there an emacs mode which includes the usual niceties: syntax
> highlighting, automatic indentation etc, for writing .input files?

Sorry, none that I know of.  I'm personally less interested in Emacs
these days, but the code that does exist is at least somewhat literate
(IIRC the pamphlet file is in the sandbox somewhere) so please feel
free to fix it up/build on it.

\start
Date: Mon, 21 May 2007 10:59:36 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: changes

re: hyper missing

ok. i've fixed the missing hyper directory on svn. it's rather curious
because the git and svn versions came from the same source tree. the
git version properly checked in the hyper directory but svn did
not. most everything else got checked in.... how very curious.

\start
Date: Mon, 21 May 2007 12:58:36 -0400
From: Bill Page
To: Alasdair McAndrew
Subject: RE: New blood in Axiom (was: Community)

On May 20, 2007 1:44 AM Alasdair McAndrew wrote:

> Well, I can tell you why I have hesitated about joining the
> Axiom effort:
>
> 1)  Axiom gives the impression of being more difficult and
> abstruse than other systems;

The words abstruse and recondite often used to refer to the
calculations performed by mathematicians and has a connotation
of being somehow at the same time "deep", "unfathomable" and
maybe profound. So I suppose as a first impression of Axiom
this is not so bad.

> the moment you get started you are inundated with information
> about categories, domains and operations.  This has enormous
> strength, but nonetheless makes Axiom appear bewilderingly
> complicated.

Axiom was developed as an advanced research project by people
working at was then (circa 1985) the leading edge of the
application of computer systems to mathematics (as opposed to
the numerical applications of computers which until then had
been the main focus). This legacy still shows in spite of the
fact that a somewhat more advanced version of Axiom was briefly
marketed as a commercial product by Numerical Algorithms Group.
The version of Axiom that became available as open source is
more closely related to the original IBM research project.

Maybe these rough edges that have the potential to bewilder new
users of Axiom can be reduced over time if the Axiom project
ever attracts some developers with a strong interest and ability
in user interface design. It would be nice to recover at least
what Axiom once had in it's commercial incarnation.

> 2)  The online documentation is very poor.  HyperDoc (which is
> itself incomplete) under unix, and some confusing system commands
> such as ")d op differentiate", ")wh th int" which produce output
> meaningless to the beginning user.

Perhaps these commands a little less confusing if you spell them
out in full? ;)

  )display operation differentiate

But your point about the readability of the output for new users
is well taken. It obviously assumes some level of understanding
of how the interpreter disambiguates the often highly overloaded
operation names in Axiom. Of course understanding this is a
prerequisite for using Axiom in the first place so I am not so
sure that greatly simplifying the output of these commands would
be such a good thing for the average Axiom user.

Still, you are right. A better way to get started in Axiom is
required.

> There are the books, but they are no substitute for good online
> help.

I would like to hear more about your ideas for good online help
for Axiom. There is supposed to be a )help command in Axiom but
at the moment it provides nothing very helpful:

(1) -> )help
   If the system command or synonym  exists, help information is not
      available for it. Issue )what commands or )what synonyms to
      determine is  is a valid name.

Perhaps this could give at least some kind of basic introduction
for Axiom console users. If so, what would you suggest?

The last commercial version of Axiom included a very nice tutorial
that could be run from with the techexplorer browser interface.
Several years ago I spent some time to convert this tutorial to a
TeXmacs document. I think that is still around somewhere. If you
are interested I could help you resurrect it.

> 3)  There is not much in the way of a decent user interface.
>  I think TeXmacs and console is about it?  And HyperDoc isn't
> obtainable from TeXmacs.

The Axiom wiki includes some information at

http://wiki.axiom-developer.org/TeXmacs#msg20051012034957-0500@www.axiom-=
dev
eloper.org

from Andrey Grozin about how to start hyperdoc from TeXmacs.
Of course to do this you need to have the source code for
TeXmacs or more specifically the code for 'tm_axiom.c'. It
isn't necessary to recompile all of TeXmacs from source, but
just this interface program. If you have trouble locating it
please let me know.

> 4)  It doesn't seem to be particularly cross-platform.

The new 'build-improvements' branch of the Axiom source is
considerably more cross-platform than the older versions.

> 5)  There seems to be some lack of cohesion amongst the Axiom
> developers as to the direction in which Axiom should go.

Basically I think there are just too few developers for any
pressure for consensus to exist. This comment from you as an
"outsider" is certainly a push in the right direction.

> I must admit that my main interest is in mathematics education,
> in which I think a GPL CAS has enormous potential.  But at the
> moment I think Maxima is ahead of Axiom on all the points I
> have mentioned.

I would probably choose Sage rather than Maxima since it includes
Maxima plus several other open source packages (including Axiom),
but I agree with you completely. Of course the right choice of CAS
for mathematics education depends greatly on what you mean by
"mathematics education". If you are talking about high school and
the first few years of university education then I think this
comment is right on track.

But if you are talking about graduate education and research in
the use of computers for abstract or advanced applied mathematics
then I think you have come to the right place. Axiom was really
designed for this purpose. I would say that this also applies
specifically to research into new computer languages specifically
for use in mathematics and it might also apply also to the advanced
use of abstract mathematics in physics.

\start
Date: 21 May 2007 19:51:45 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: New blood in Axiom (was: Community)

Bill Page writes:

> > 2)  The online documentation is very poor.  HyperDoc (which is
> > itself incomplete) under unix, and some confusing system commands
> > such as ")d op differentiate", ")wh th int" which produce output
> > meaningless to the beginning user.
> 
> Perhaps these commands a little less confusing if you spell them
> out in full? ;)
> 
>   )display operation differentiate

I think one (perhaps easy) way to make the output more intelligible would be to
display the description string as well, even without special (LaTeX or html)
rendering.

\start
Date: 21 May 2007 20:38:34 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: TeXmacs+Axiom

Dear Bill, *

I just installed TeXmacs (version 1.0.6 on kubuntu), but I also have trouble
getting it to work with axiom.  Additionally, it seems extremely slow, but
maybe that's due to my laptop showing its age.

Since I'm not going to use TeXmacs myself, speed is not that much an issue.
I'd just like to know how to get it work in order to be able to help others.

After starting texmacs, and finding out that I have to click on insert-session,
there was no Axiom entry in the menu.  After a little hacking, I found that
init-axiom-scm expects axiom to reside in /usr/bin/axiom, which isn't the case
on my machine, and probably not on many others, since many people will not be
root, I guess.

Thus I changed /usr/bin/axiom to $AXIOM/bin/axiom:

 (:require (url-exists-in-path? "$AXIOM/bin/axiom"))

and indeed, Axiom now shows up as a supported session.  However, I get the same
error as Ralf, although AXIOMsys and axiom certainly are in the path.  (and I
didn't modify tm_axiom either) Note however, that I'm using wh-sandbox, which
has a slightly different banner. Maybe that's the problem?

On the console I get:

martin@rubey-laptop:~$ texmacs --debug-io
TeXmacs] With linked TrueType support
TeXmacs] Launching 'tm_axiom'
[BEGIN]verbatim:

Martin

Bill Page writes:

> > I only see that TeXmacs' tm_axiom and the one of
> > Bill Page start AXIOMsys.
> > 
> > >>
> > >>    Unexpected End5
> > >>
> > >> (everythinng in read except a black 5).
> > >>
> > >> And there is an "axiom]" prompt. Unfortunately, the cursor 
> > >> then is right in the middle of this prompt.

> > > That the kind of symptom that I recall when tm_axiom
> > > starts the 'axiom' script which starts sman and creates
> > > the double prompt but tm_axiom has not been modified to
> > > accept two prompts.
> > 
> > Oh, since I haven't changed tm_axiom, it should still
> > call AXIOMsys, so there would be another reason for the
> > "Unexpected End".
> > 
> > Anywaym, I feel unable to correct that myself. :-(
> > 
> 
> In that case the problem is probably just that AxiomSYS
> is not executable from your PATH. For this to work you
> must set *both* the AXIOM environment variable to the
> root of your Axiom Gold installation and set the PATH
> like this:
> 
>   export PATH=$AXIOM/bin:$PATH
> 
> Then exit TeXmacs and try it again.

\start
Date: Mon, 21 May 2007 15:08:26 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: New blood in Axiom (was: Community)

On May 21, 2007 1:52 PM Martin Rubey wrote:
> > 
> >   )display operation differentiate
> 
> I think one (perhaps easy) way to make the output more 
> intelligible would be to display the description string
> as well, even without special (LaTeX or html) rendering.
> 

+1 Yes.

\start
Date: Mon, 21 May 2007 15:46:35 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: TeXmacs+Axiom

Martin,

On May 21, 2007 2:39 PM you wrote:
> 
> I just installed TeXmacs (version 1.0.6 on kubuntu), but I 
> also have trouble getting it to work with axiom.  Additionally,
> it seems extremely slow, but maybe that's due to my laptop
> showing its age.

Probably both. Even on a reasonably fast dual processor
AMD 4300+ X2, I find TeXmacs rather slow compared to most
other apps.

Note: TeXmacs does things like build a lot of fonts when
it is first used. This can give the appearance of being
very slow at first, but this happens only once as the font
cache is built as needed.

> 
> Since I'm not going to use TeXmacs myself, speed is not that 
> much an issue. I'd just like to know how to get it work in
> order to be able to help others.

Ok. I think one can get used to the slow speed if you learn
to like TeXmacs' features.

> 
> After starting texmacs, and finding out that I have to click 
> on insert-session, there was no Axiom entry in the menu.
> After a little hacking, I found that init-axiom-scm expects
> axiom to reside in /usr/bin/axiom, which isn't the case
> on my machine, and probably not on many others, since many 
> people will not be root, I guess.
> 
> Thus I changed /usr/bin/axiom to $AXIOM/bin/axiom:
> 
>  (:require (url-exists-in-path? "$AXIOM/bin/axiom"))
> 
> and indeed, Axiom now shows up as a supported session.  

Good.

> However, I get the same error as Ralf, although AXIOMsys
> and axiom certainly are in the path.  (and I didn't modify
> tm_axiom either) Note however, that I'm using wh-sandbox,
> which has a slightly different banner. Maybe that's the
> problem?

Maybe.

> 
> On the console I get:
> 
> martin@rubey-laptop:~$ texmacs --debug-io
> TeXmacs] With linked TrueType support
> TeXmacs] Launching 'tm_axiom'
> [BEGIN]verbatim:
> 

Can you tell me what you get if you just start tm_axiom
on the console? E.g.

  $ /usr/lib/TeXmacs/bin/tm_axiom

Reply to the weird looking prompt with an Axiom command,
e.g. 1+1

  <verbatim:<channel:prompt<latex:\red$\rightarrow$\ verbatim:1+1

you should see a coded response from Axiom like:

  <latex:$\displaystyle
  2 \leqno(1)$
  <latex:]axiomtype{PositiveIntegeer
  }<channel:prompt<lastex:\red$\rightarrow$\ <verbatim:

This is the kind of protocol that tm_axiom normally sends to
TeXmacs.

There a few control characters embedded in this output so it
might not look exactly as I keyed above, but it should be
obvious that tm_axiom is communicating with Axiom. Hitting
control-D should end the session normally.

Let me know if this works for you or what error message
you get.

\start
Date: Mon, 21 May 2007 22:40:00 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: TeXmacs+Axiom

>> I just installed TeXmacs (version 1.0.6 on kubuntu), but I 
>> also have trouble getting it to work with axiom.  Additionally,
>> it seems extremely slow, but maybe that's due to my laptop
>> showing its age.
> 
> Probably both. Even on a reasonably fast dual processor
> AMD 4300+ X2, I find TeXmacs rather slow compared to most
> other apps.

Oh that is a big issue. I haven't yet used TeXmacs again extensively, 
but this slowness in keyboard response was one of the reasons I turned 
away about one or two years ago.

Hi, TeXmacs developers, is there a trick to delay expensive computations 
until I press a button "re-beautify"? I don't need the screen output 
looking overly correct after every keystroke. After one sentence, or 
even a paragraph is completely enough for me. If I feel like working on 
a 8086 1MHz (not GHz) processor, then TeXmacs will not be of further 
consideration, no matter what features it has.

Hi Bill,

> Can you tell me what you get if you just start tm_axiom
> on the console? E.g.
> 
>   $ /usr/lib/TeXmacs/bin/tm_axiom
> 
> Reply to the weird looking prompt with an Axiom command,
> e.g. 1+1
> 

Eh? To what prompt?


woodpecker:~>type axiom
axiom is hashed (/home/hemmecke/software/Axiom/mnt/linux/bin/axiom)
woodpecker:~>type AXIOMsys
AXIOMsys is /home/hemmecke/software/Axiom/mnt/linux/bin/AXIOMsys
woodpecker:~>/usr/lib/texmacs/TeXmacs/bin/tm_axiom
verbatim:
latex:\red Unexpected end\black5woodpecker:~> 


I am getting back to the command line prompt. No axiom session started.

\start
Date: 21 May 2007 22:57:45 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: TeXmacs+Axiom

Ralf Hemmecke writes:

> Eh? To what prompt?
> 
> 
> woodpecker:~>type axiom
> axiom is hashed (/home/hemmecke/software/Axiom/mnt/linux/bin/axiom)
> woodpecker:~>type AXIOMsys
> AXIOMsys is /home/hemmecke/software/Axiom/mnt/linux/bin/AXIOMsys
> woodpecker:~>/usr/lib/texmacs/TeXmacs/bin/tm_axiom
> verbatim:
> latex:\red Unexpected end\black5woodpecker:~> I am getting back to the command
> line prompt. No axiom session started.
> 
> Ralf

I get exactly the same behaviour.

\start
Date: Mon, 21 May 2007 16:58:57 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: TeXmacs+Axiom

Ralf,

On May 21, 2007 4:40 PM you wrote:
> ... 
> > Can you tell me what you get if you just start tm_axiom
> > on the console? E.g.
> > 
> >   $ /usr/lib/TeXmacs/bin/tm_axiom
> > 
> > Reply to the weird looking prompt with an Axiom command,
> > e.g. 1+1
> > 
> 
> Eh? To what prompt?
> 

There should be something like:

  ... $\rightarrow$ <verbatim:

> 
> woodpecker:~>type axiom
> axiom is hashed (/home/hemmecke/software/Axiom/mnt/linux/bin/axiom)
> woodpecker:~>type AXIOMsys
> AXIOMsys is /home/hemmecke/software/Axiom/mnt/linux/bin/AXIOMsys

I whould have said

  ~> which axiom
  ~> which AXIOMsys

but that's ok.

> woodpecker:~>/usr/lib/texmacs/TeXmacs/bin/tm_axiom
> verbatim:
> latex:\red Unexpected end\black5woodpecker:~> 
> 
> 
> I am getting back to the command line prompt. No axiom 
> session started.
> 

Well, there's the problem ... This is not the fault of
TeXmacs but something wrong with the way tm_axiom is trying
to start AXIOMsys. We have to find out why.

What happens when you just type?

  ~> AXIOMsys

\start
Date: 21 May 2007 23:48:29 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: TeXmacs+Axiom
Cc: Alasdair McAndrew

I've finally got it working.  I did the following:

save the code below (it is a modified tm_axiom.c following the instructions of
Andrey Grozin on MathAction) into a file tm_axiom.c and say

  gcc tm_axiom

as root, modify line 20 of /usr/share/texmacs/TeXmacs/plugins/axiom/progs to
read

  (:require (url-exists-in-path? "$AXIOM/bin/axiom"))

and copy tm_axiom to the place where it belongs:

  sudo mv a.out /usr/lib/texmacs/TeXmacs/bin/tm_axiom

Most likely you will have to modify paths according to your situation. If you
are not root, I guess you can place the files into your .TeXmacs directory (try
cd .TeXmacs at a shell prompt).

When inserting an Axiom session in TeXmacs, be patient and wait until HyperDoc
appears (maybe a second or so).  If you type something into the prompt before
that, texmacs will hang.

Personally, I prefer emacs, since I use it for reading mail and svn.  But I
guess many will prefer texmacs.

Please let me know whether this works for you.

Martin


--=-=-=

H4sICFwSUkYAA3RtX2F4aW9tLmMAxDz5d9s20j9/+isQNaklW7Yl5WqsKF0ndhK/9bW2s22f7c2j
KMhiTJEqQUZ2Hf/vOzM4CFDU4Wz7VS+HCAwGg7kxALW5+qd+Kqvs4Gjn0/4uw88WS0efvZsgHm34
0LOze/ruZO/4bO/ocIt9CDPOejydcB6xM/7ryPMF86I+20Z4gH53dPzbyd6Hj2eIp/auzlqvXr1i
bDvqJ/yWfUjiP4Ko8udSj+SfDQPBRDxIJ17C2cALQ8GyqM8Tlg45+3D4iV3xiCdeyMZZLwx8Bn95
JDjR7scjLtgve2cfjz6dAbLtw9/YL9snJ9uHZ/Dl4/bZ6dHuv3dPNtgp54RvEIScPT7b/fVg+93p
5+Pts4+b+3vvdg9Pd9kgTtgoBhr6PPWCUGwAvr0Bu40z1o+jlZQNva+IBMhFLA02SYIUGmJC/D6B
GU71Mt7HsAQvDeKowfYif6MBuJ6/AraPxjD/cej5nK2z0wwRPH3abLC3sUgR+GCbNdutVmu99bT5
ssE+nW5v/Mk8ryDTgaYw6wfRFWoC2wnEOPRu2YGXDtlB3OdsP4g4e5tw7xphjpP4KvFGNHI7S4dx
ssVO4h5PUnYKrM3SOKG+HS/lW6g2LXp8N/SiK84+BrC05HaL2pqvNputzVdtdnJ6ClxKRl5KghwE
N6y7viEh2gD0lP1yeox0xsk4TgBxHwQf8R7SBLoRRMh3pewwyvmc8DFx+CKJ4/QuumcX8YDd3dyz
SQALvBC/J+l5dAkNRNLRGLQLRSUpPANh8ptxwoWANgEzsb7izwj5M0L+oIx7SXwNpiRQ/rAKUIJb
WEYKKOKIeWzsXZG9pUBtDUlnPcXP+oaZyEsSwCvSbDBgoFc9juz24+gr8BZWDGvMhFRcCRnh5Ont
mEsUJ1ykSeAj8UJS39qQBgV/RtyLUkTR52A8tPQ4S8dZygZJPCKk27/uHR2gEUErkOmFV8Bgj4lb
kfIRCuNTBIzowwxeD/QWeJKFKWAGSmLfz0AMAySwL7GDuPvr0liReNQsH+lF7cifcoAeYAEqEjaW
+oUWt1mpVH4ISDs5ey3SfhBvDN+4TWHQK7YlwDe3zScuOU1ZBJrYx7bKD30+QJEcHp0cbO+zpmnY
Pzr8ABrUMg27hzuoUm3TcHxydHB8xp6ahgNwIgDxzDSc/XaM7vh5Ps3+7iFrP39R2Vxl+UQfWHUz
HY03jcsO46sqQw7YmN9+eo+j8dN6sfpT61Xb6v4VIc6O/kkAPzXtnncft09O9w739w532Yu85/32
2c7u/t7Bwaf9M1oW8GcA3nYAQr0xUPC95jV6dVar1bw6e8NqvXqd/czwYYseKj/wqB8M8tEQG8zo
ILJHv549OmfZyaddi+nvt/fBITfz/tOzk3cfT3b/VQNRN/yhlwBy+HrevGTdLqOGCnAX9QzEDhrv
h540aqVUPMpGZD3YL9hdhR1+Pjza2W3gFwgHZ/QFI8dvlftOpYLag+uCSTI/Bdcj0kMYfSofYTh8
yvtWI36T7qu2zjxAMK2vLmCBSv1NdoYx+IZJ0E+H1jO4lPCXvA1UHJyPJA8/yBm2mgJFHdM2i2xD
hQVEXseGogYJdg9/IcZ5nQp+C81Cirwr4pDUgQMHfxAKtRY1Gie4EjlD8nYegZFz0WFgQ+BNryke
iJSBZ0fKRYNxzx+ycQyI0YmC3/PMaoqfVZbEEzQ1pNzQ1yEVgs4PYdwDl/lvLwnQ74EKkVkSM9GT
n7ea7WeXHdnQC73oWpyDIrLqrPkWfqoKWeiJ9BicGbrHLlu5aK50KsipAIwM/uuypgLEUPQWogZP
znMvcdmg9jOMS+e2d7iUWJD2fR41rNGFx2MwrxwHdHYsEWA76qtEhmSIoyxtQM6W7vAwGEEyk8g+
8B+YQZBiAtHPnjebJLhnG89hKf4QdBtCVbPZRL5aA07DeEyLJKbAgOZGs3wAzn6GwjkHv6qW5329
gpQjUeaALWIMaQA9i/PnwB2wg8Q7guBqwZD4d/iYKIVMjJ4PvBvd9DRf7gFEv8Ns1DAPOzyKR2qq
ICKk0BkL9S31dBtPBmpKslqIw7hcwIVz7neUbvWywfl+Li0QDUbMBuaZoNLdZmPiBelnNC/4PsJE
pCv5OvEE01AtZBGhg7A6Gqfnl93q+hujYShEbHr8+CLSbehjsA3/30LI93uwoViFqBQ14F+gtkNx
Ao0a4pbqhnAlCVX5MtBSqXyNAzBMVLQafq1X7piA5AAss4ZrqYNJ3jHfEzr0brEB5B6iVpWP1QZg
rXdkqiRdAAFjWN6CBwUso/QsYAjZCKuBZQSfBSzDuSFDPs4CRoOyyJCRfxYwpgEWsMwKpoDvKwiB
Jj+oQVejyp487W8hHI/qnYoeDqohR0ILJF014ma3K8mtf/umnpEiiLVqSpCwGTQYhJkY1uTjvQnA
UrWNrEgdfISfDHGnVGspiXWveOrXSBdgvKUL5MuBIKUEdWq4c5f0pNm+qTb8ug4vCO+/6a6wlXph
7edP/Esb0umF5QDnnIVQHNKLMagfdVcuEsCd8DRLIrmee1i01E6k0yyY1l+2XmCKwk8ou93do/d1
7EE+g0ppEZIAIXKHIHEFSZMrPtiIlkRVRBatIDA+KhOvw044RUnVqHP28Cl437BsGbicZYFj0BSQ
wAN9gb/XjeW4p3zRl8u6xYov3W7bMEKqcr4YSd6XtbWOIVbrFmzUa9fgbq5ff+nUyWsGa2uXeo5r
+K4Z/gWdUj5h8Abc6/ozMyf6kbnc/x5JGXqwoSPHSu9WPtzA+7lw8C+1IxZIAjAYdANt/PjQfflT
XT0i4MuXl4oCksCXbksis3j18kUHWFM3Q64vwU7WiWRkk0sbiacuiUfPJfXBsXvp5dEbaPMjRth+
SVmgptvoWe7TYEMmXYo9GsVSl3Za6AEZyAUaD3fRDmEzebN1cQEbVdivwtad+5g+AVEXF5Cc+dfP
L55X7YmA7zdBCsqq/W9xZltkxgbichsgC1B5NiWzjrxzS7AVyqhTpaBB60Xx2XY1051M2dbDrcuy
rwdaGLPjnvYsWoWdxT3+rsVRvjJ3aRjz/teF0SyFZRXMsrg2FWlIoC7sovhsnlCbJU/KbL0QZKfN
jVnmdT/lhHN/157n76Y9mJ3HfFcYdLkxy5Ut4Us2V03Cy378EfJaxTdpXfV8neQQW7a7AW7kuXK+
AMtzGnUQXXREUimgf/1lR6ytNYyrrK2K+iOZqziabqnSi7IRlFRfXxZGYf91t/uiblQS0nftwCV/
IH3/v5z4Vq6RKheq5i6P6kYIdvdE3JOXq+fgNjMc5TXuWE9SL0EN3vQx/BtcDVPYEcWTx8qZXlww
mMi4NNqF1POCiO+ltXw72YCVSS8rNUOClXp/Q9WiEDDHRY8ykX7u8c/STdWkUx5xIchjaxXLkT3S
9kmKVMoD9s6LojhlkP6q/RR7IjQrKLAQ/pKwooniwL1E0yKuGipWBJHgSQqEVfKNCkKyGsxNKlPH
XQDwtA8YrJ0A4ZhqleimOnxKEa3mfLYnbNZ8WiTufG6rNZ/dYc2nmw1TgCF5LYFFfKJrX7Vi2Uux
JYcGLQYzUYRbI3GDo6eCbWgvu0LrYSyCbXUtH16HXW8Yxn5NBH/weGB66kRgtP7GLtnBUGixa3PQ
cvhpf1/DKjoRLlVtE1XoWG+pBlOWM42oc1jB6arCo3QAAIoltI3IncY4ZT0CK5TuCKzpFUfcORDy
xAAYYQpc05wwXXWlws7g9Te6GmfNNAWjKnPzQLDQJ4tX0gWpjVlESoGpFArgQJedaij+CsNaHCjK
KacTB9W3wU5orGAtZFB83WBN/BLF8uwuRSAs2FHFThVA/SzBwhCWYejLefvSVShrcjSCMpXSQ1uX
pjDHrGpbs7R5n0dy2WY1/wzCkHnRrSob5oSq4F1zanHstVuqq2MYtEDOHWiqhWOgkpri9GE+ZIjY
GzAvxQS5QdbJhHeLJVMR5+SQb3dIedMt0GJlIHKJFjtsDkAmAExQMmA2lvMCiZcdPbWBRqZerOgA
syQSikW66iSHGAxYmUE5bWHglVzAGnKPEEhRa+bNWgqwWEfVqxjP1+KId2zsFytb1iNznh45Tz84
T4+dpyfO04/OU8N52nKeOs7Tf5ynz87TnfN0r56WkuMMBuSbx0B44Xjo5fz/9s0V6z9AT81JxQNm
1IayWBcu0VzUqOXoqVtHJw8gqcTWikmX46Fzb9IswVbqaVQHZBJVyLLoXB1dm+fjue0gBp8+QRO+
uKAgrlBY1R5nNxaIfnAFUVnzoo62QE2CTrYDyMG/Bv3MC5U/1XbRcbG4HNXM+x4BTSP7Lt0oFcP0
ZtSSepXqH7B8PLwGsuVRslnwd61FAz+S+P/clSxwTVWlLSXjIdSioW7NdNTr67nG5eE3HkFUBY0T
oT5PZZI7yMomMhHT/tG4ZlA1WPXiQoyrZuXFMPkfi0jZXtD1QgBtdYoinDNvb/a8n79vXpMp5DNN
5cPV8lQ0z3Va+TallwVh/0AdpllpKovDPuVihewXVAO/NNhqOhrLg8o8eXGQzcqHFQYrRVOKXci7
NON09M+Z18X4oDet1o62FPJuJdd5RTJmy1bGr3Jgre0uR9SQ6Vr1IpyUJXdcIDddBpXpZ5bKOHMo
3yBRS1bl61CycfN1I4/5hE5tJ9QsmlT1OLUPKUGfS9LqvM/NNeR4SU1e9ok4PH7lIZ2Rc4GlVwgN
G1cbDXZ3d3dzf3/P1tff4MUok/blnJ1er6U2Bg7TUbPIfGdkNjnSJ1ogzgI1jzWX5/G4QAjYXcJ5
QVUWUX9f2INKZ9/GJ1I8VcVtMHuf6mxG3geJwCPjq2yE5/F4c5Fw4HWDnrkSlo1hB8z9GFJLgPBo
a6s3LoTmq4eXMaEPz/tZkPIRXjPDWfMM3M2+1eYJXd741q6wMFl8cFJzqeghWLTsdM1LKn0k97ll
0i1siFE6hgGCp/IOCq64uaUucA0yyBEmuLWRdyRjgsMKGW6EdcBwtsqqKKfIKN6ZQY0sAjubRktC
shRxSnLYHkA+tIQcE7WJJB3zcJBCw/tKoproHMUkTq6VH0axqRsjwDXVPtvFaXApF0flgEg9XlZn
CsyYch351DnesgJGkaPTVQ49b1EJppuniIhkIQkt0KLeiKicrrlyS996/vUSgqM7qWB1YGPyDqhn
rgGpVBVvk3rjMezrBN5xHIEfVFd01VYvIhsDzcNyIVptFEfr6Ihy2/t/FfqfL5tp0UzLZr403ifA
tb9YHAOcAyClNDYsgSiP+XeJY55ZOeKI5snBNtRCmW+GdJcUmr6NRPVFKSNfpowKumbdVQLW5lel
ajC07sNOZbN4g0mnpuoqMM4l0Rclz+yjTjoE7TgCghBMhNM1J4VNYqqb4o5x7I+wOEqbzzgKb6lU
SjeKo3ES+1zgxWIVOPRZRmWqutq00boZCKWD+mjCEl9+HRKHCZ21WnUm3dNWPc0VuzKgS0sCtg92
u1vukR8riNmX0ZrWQWPhBLVY4pmLp7UYz6Nl8LQX49laBs/TxXg6y+B5Ng9Pnw88UN0ZaNxbgBrg
vmKB2vqjR7olG2ur6ew1Be0x1fsAIr0NOe42v31Tg0pge4NFEGIhRJougkhGiyCGvfhmEcxoCZj4
K0/wJG0hzWBkSzFI+EkwfhCoM8A2wOn0skSe02jDfpyKar1ehuepcqDSh61srJj95TyEfJBWHcrA
LZanZfKDaADEcmCP3FMfNaUsAGZRJkxtzin+0cRAQtU6Bp6h73gwRFMal6j9IKyR/cya1rxbFgum
xlhTUd+UBJhzQViXVZaUDaqbZKXJOWiL4YWwqP4t8/p9iBKweZLTYnoHW7PEw1eSWF7OZ9ORrbjL
mckx99IwW6O3IwpHhGrZjen0ndpd5JNcFPk868VTx4JfKtkZLOa0/bbHA5hOp/5/iwLLmZfWYGe5
q2ZAbb5mL9Dnv1ah8ZU0l7WLNZOueA8DyDlwtK3VUzoxS0MQBb4FZ40tFem8p85skgGXJJMIdOeZ
LT6LvWusZgduyFDbdbZmcNALSVb/coa20FzK5buEFPEVwodKcTFDLEtxmFHOnBkrfAgHlljpH97V
dy90EejDOVTki3LFJctsPMhGHqg3S5vd/+SYS6RBh2QLU06eLoQZB9O50xIsf4iJBBHlVOAUxDDO
wr58lZVeJA3j+DobsyFP+HKeQr9ds0Ty5cfFXG4GTv2ezhI4Uy9aDqd+42cJnDwZLIczf3dIZ0BU
dJ0EeM8VKybKzPBi5ZXMgWRglXXNCzsPck4nyhNmdbMxoLjGAvbaqiWzYG3Njudm/FrXCqniPLhc
bMyuKhUuowo6mVNbbwWYb7ub1rbbveVQvOeAnwWpS3ksm5GvTUeuxcmCs3ud3rvOUVCLoybPLjll
KpOikWFzvgyXkOBc+TmH65KgeRZn1YPsmlh+ZXK6bjRdgZIvwprajz61oJTTOrNzSk1dWWoyWjMV
mcxyJ8iK6UXOPapQhbcJFdLkO6SqRnA6DoP0QFyBwKl5Wx0dCd0gIBv19ClSn+PmtkcHSkPOrgNZ
sc5/joBN5G8PpMmtOnUSOMGGQhZfA7bJkNOhDID6XiQBGPyp0UvWoBf0dnVdDsFR6kbdFovAsdDR
h+55n0X04wJb+ici8DQLL7zibxsANfJaKfN6cZaaefGnD5I08LMQXzeEtrhPVV56bzf/FQR5XtTj
TGQ+FvsGWajes6VKZIF/eS0ai47xNWoCHYLLS7uSEPCrT8Q7s+YnsKQnAs/E1W27BoM/wKOfWRV5
UQVmVYkZ+F4Zvg2s5qZbi2dxvMP5uKav6E5NtP5mW/4mgzxaBWHgTy3w8SNrxrqlEbRwfQo3Ux8i
/BGXIV5EQSYCWnlElaoNgJZ/jCpAp46IVY0NzTu3EgdkR8EoG+V7Y49ASiTvqEYDloEFe5wdVU7J
NXV+GIPeOZXnnWX6ckZXQr96SRBnQmmBMPQWcenTgxG4xmAccr0YgUZcgA0EcboXXCl1QYVweOu4
jIZ0F4Y1dHxhhrxPPP84iftYnc4b1SqcRkJsNxxmox5PnKbjg923bgPIitBY9zVsSmfc15CvLqMK
d6VErPs4O/RTNP0YL5GStSKLdDUEEq0ErzTG2dXQvctpHOHrrs0L47qK04AVrWgi1J2oBv7UCSUc
cszUBCXV95IJ9Avz8pV26z6lescdvG+7UwrmXkz6BfxjFE/QImRFiCyFiBScg9aizUgX2M8vtprl
Qbhqoecdg/QzPwWDabELlradRdW0FFxlQaXSPKRcDu/cVRUm+CodrErurBuS7vRtcvz894xHPrdO
zAQfe+YHUtYabB0NszuHLlI7m6aFUz/FqQd4exAtCqfmyUhIHmDF7Xv5QNU6+PZ7FqcBiA2+o2dZ
SM+zLfvgEGmBmTz/misuUGHznM4SZYnoUl5x8TCQj7w5tMobDw/hzXObFnkpssHGMTifXnib36yp
blTnTKucw4MmfrElQyfwbcjxfn7fdns1eXEHxAZSi5P6PH0gr/OguV+SQii/h+e1YeDTdb95aqDd
5KKZ9K3DBYa/vsjwtSshKoqBVSvl3x9Y8S6Oj5A8oLip7QLNmHyFRur1eGiBGaMhQO1NFDDpBaaK
/X6uIxAfFyd1f1FoN6EcYrfHNO22B8FJjX/V7hWsmbJeFCFJAW3aUnqd+poqPgJsxpLEPh5WBxE2
F2O/8UnzYr9+94oEpB9IDDKtJDrk/QbrSBtLmoU7B3gVs4X/tPUxeEw7PLkziZNrmq7VyL+3S4+p
H7lvA02FSj21uXIDyatJCRjytEvbEg1XvJ9QvmMhKuxd0qyjc32h2S5e2IfoDanqdiEJJDxzr02H
BG26M4j7NESatgs1wHxnSktF5bU3mvBPcWOg5AdbAsNi+K4OjGgfrFRQoPJjcMFdSIIpkrRfQUCo
X+kkVu5VWF7PXr2azFinWfl0FaGldpTTPW3VkysKs5IyiPfWgSNbkctSb2zmIzZZm70BDbA227kU
crVTt03UoHV3QKcIjoSUQBR/LmKKivZ8KlpTVLTnUYFEl0DkVMzFX1jyJmtbDJQW7tzycNYLi8nH
5ro4eyXP0DXav6nmHBfX8uNiqfwzpmqXTNV2F7X0VE5FBizAiiv6pYZZfKNeWxFl1FldZurcmSBD
XW+irwLPZbblQ1pWoc3VRouZ7pYv/W97x/7exHH8uforDoVEUn1yJBnzsCNaQ0hCC4YG0jwQ8SdL
J1tFuhPSCUMd/e/dmdm9fc2d7gyhX1r48hG0t4/Z3dnZ2XmaxLaLg+m9/lKZt+EpR2ayacqdDdsw
zgxOavSbgpvFU633iiRPvL2YKSc1BsizjfSgRD63ZYLJGEwqZW1LwKZ6zlBOSVaNrekVbE0+cprk
3diaXsmt6Zn34O+3Nb0/6tbIa1/ddYZAUd70mxojnNgm5LCs8gw+xZQpVGZIfKvxvOd/QSeebsvm
KTLdESmwimuStqdMTdLhlKkJcTjL1RwuR+W7JYVPLsOgJNAW38NyPHX1UKtzbA8d03xDWDrEpjkq
y65BJc6ymLNWJvSSoPuH37xRTOVAK5uhRBFgou1X3f+PqFSJ8sV7x2yKoYWnueIQ6ElJRJoCKPwy
uDQkJYONDJQdp8Mp2GNDYEHwOgEhBkpP3KdUKRFqzgNJeuCwTyX4a0/ToZBG959N8Kp4q7RHvHlv
5XfTtpcSgiI+M+SR4WeM15F15KGmQ0qkJaB0g+q6njV8edF43oB2Q3P4FzxhKm40GFwClaIHVCBX
jgHQuyFJmHQejV7he2oo0DkaTYcz1MgeBKtkHqVTiNYOh+PiPBHX82kyfocSP1GCErfpCntRHlPf
zIZpGsUYcz2EzZBiOMM1YCvPSS/YCitccbWUrRzn8Qht/SC/kjy7HWcf9+RHx9/N8CZ0ye+ebusR
bcuHMOOLoCLPEdHwe3mw5dJ+9sbQkJG3XjdjgAituAmpV0zNBNdZK+Ahr+nrrsxBZTfW3Mqw3jKk
D4ogaAGEaZjzfiMZBpa6QSUMrUYHXuYbA23D7g1ith41k9sUEgTLsAhJakbquSPCYdrGwhO2Uq5E
qA60JJc3gl9GzN+7fTvirwbd1gIrwOy7RqGqIn/i/kxVrP4ofjMVjxRgWQxytf1BcxqdTeNL7GNz
+dfLzWzjeByE2S0modLTUZEC+PeIYFRkv/BeylxnM/CPkwsp1B2CH5YgyJRHgdSKglAjd7QbPAOG
S5oXCdqNbY3ZBjgD6fqlKsm3nbESce6Tq+RlI9k6YpsouQd455q64onSFRvjGt7jHFr5D1hbv+GL
txijptilvPnCK6+1wf1klQ4tcsg46BpksFiY65KO2KeCObTCe9AcOMRBTynPNjW4y66kNWcw6VQ/
DcGBaZLlnh10+lVkdTcYDCBIHf1lHhzpILErkD9uFeERQL4VjUqgUiV02oZSLFqZpNJCr229WQac
GgRjCxnTcAeeHPWC7l7JNzKeW4mOdIlhKebUNTwr/WbGR7cHhTsuaWy3D3PELZy8xXiDki439xWa
vTX+tx6j8h7wH6PZSxJ9NlXUINDiSR15DTn4sWD+55C0CRIyuE9MqR43Hpn6Dcm9NTPJldo03VKc
JkhKIZ+ay+RC/muUzBRClnpeatyqJAzLeU9mNomCUbVZj226NpPKmkawRqQkCt4UO24rGNCqsduA
Fu43g8zkHlrvhrJ1jTynFeNGflxeK+AYHokCntgLM7q0rDp50Qsl7hRJztgeZHDDbkEVI4xibt+u
V3qdeL96WNylEnoXIGPgGN628vkM76aQi2ILDOXZKpqNrOIIGg8zUD0UtPgbz1BXQ25wOg6/4XMY
VRkMzRFM5xTFhBhdmCashHP7ew57ztNYh8Nkanvfi+/+bB/ckAT5QZUCA6PZ5kzvFXd5207bfAbP
Zfjc7F/yuMeDTpAhQAEdy2Mkgr46SodOle18SXYGVdWswLR1/zC8B9ogizs3SrGzFWMCb5lwGBb2
7W4mo3eCJKhDU6CoCaxBPft877PnvLVxOCc0RPskvnfF96Tk1CJ6sNry7PtclomM+iop/TJZvIop
cjUlIJryrYbvTuarMxKmm68eSxUoyecokwLjg6tm2RBmrZW3BkmoC6OIKSH2NS248qK7mfJ2HnAP
ukazkcFmiKR4qeT7wy+Ggxn4oCOLVgQy2DnPkzdZstEIND8VAVf1HC8ZJWHl2iqysHWInEqu7HvD
ogiegY+II5nEviSStD4ukrQqI4n5NKrJ8gOOW88zLmb5d418IAjUShvx9JuOUQ4eR+C3M1y+C4Pp
biSIV4oOnZB6FENxnwtamMQkHgS7uyz7MHRGBFCbU9RsjQ6LQw4Hda2v7jpDHFAglbYkd9tZGyZK
k0PyyjjLl60f6LBQnr4nfw0Kec4ya+iPqqftqv9zZ+I35QNZ8towk6uw4nARd2nw/85X23zGEbKV
XHZyEzctFLbaunlmC6zUCJwyPrE+trAInFlC0LILqh8MV+ixuCAz79Uu5kOmjjC38MrQHahaHlME
ni/beSIjZFlJqwXTTCFZ/C42CrleWRTWQKXDxPBokLPhAjc2TSFINaTJNJ3ntxhAWCybx7Y5JkeY
gVP3lC/JyhFkKSLLR1yjpjqdbxg0dhoou7LK2kxZv1Ec0iCwFLg4DV57mx+wqTDEltLZbouOZdWx
ZhA2fM2oIdyCPznJtKwdLJCiUG3sWPz1BeIuxwk0d8J22A+DVnsLF6B27JPG9CNoTE2zlnzt6CcN
aIEGdJYki5M0WagAC+U0otkptXWcHmlyPrcb3El3KuWTLU+hGuQqVO8GvRtoOQ2XAcqH0Ct0J8CL
Npoug+QiJv/6zCr5KvrYjA7huukOvjKupy+DPQPIwMMVh8GymCstbXU0n7lRd9pGAjSmGiPloj8V
whTJF5VCHVOzmp20QTCPhoKPkR7q0jtyN/hhBZ7Hg9E4SeEkzoevIjRXC0azSPBwy5otMnb9iVgU
MOebp+rGAfMU3VLBrTpx1MK5fZbqrKIg/ZNq3W/yh1WtfyjlOhIwsAhkIzbkyDHLxHrJl2xbozGi
bZ1xLS+OgerFOrNm68uioXyt3fbKUjVp1bXrWDGBtpwYaq3SvNnYvtF52C7g4fFwcqxkO01MRS8Y
kR+Hq2P6qlUQ1+wPlFNJPLZWT9apuFs62RnkUwMKTnWdQsPj9VzxYVlzP10cIZWEFOOx3Mdk1UYE
bLy2DAgeH/10/7uj7589PH708FjZAysNOgD/FLqJxni3ZmmRPgjYNdl8ZLU1xgQV22FNN7VStBFT
STFQiG3UYTKzxE+rmiU1LZw33jjngs7vtIPw5FdB1T/ENN0J6VQ6ZZ2acB/pIlIxfvRWmqG+EN8w
5Lb9rtCIYETJsg8kRl5ZOZMzJrPj5MvQTpT5IOcEm8k7LZxahjVWmarXQBicLZP1wowdYw2cl+un
OonUzLN9mvvG2kJOn8PCaix1Dd3FKO6Dhto0LLqWT5rJuCMffIaaVQJHoqXzwqxXXQiH9ldcEw2E
HXY8t1WZWasjpE1e2KsHQ7qibBLNuGTIMXpkirb6rSGRTvZnhwtVVgS+kYFh/EDtZWWbc6NsvTNf
gCwzt2H2z1RCJSqu57Hpmrl9ZYMvgrr1HHgvVNKIWwpJfPOJXPywlzNryDPHGgSybmPsP1rG6mEi
ImtLS6wbvBbqptftey1bSWuVTa3kcTFkN+93WPRybuESbTvswneeDANtYroDPoQYfqEhL44O6/Wf
TIp6f2n1m8VVxwyIr6J34qmC2VqGaTAHqScmcBlCiiTMMxVAzm/ruVYKqNN3pW3LpwUpEZyq4lEZ
l64McOoHtrk8WzEd8idcWnSisAnzSCgxzCYwN8bdGQz3JvdFhtQ9BX2s4Ws3SSzRacmdSZfrgtwL
TuXJkBax5PZAvN/StY9m0eL8ihsEySsuIRPG77xJ9h5VWOV7D4+fPH549Ojjza9+OoWAScNZ+RaV
MXA4u4CwoKeRL4qsjoh0oZSWlzp5WAqXs8pN9EGQpvyA/jovzpfDVeQddW+Fd6+yxMjLVlhlcY/+
txcXQQ76vHX8KWZ1QOX2gaG4pD+cII3S/cKKpvCwzhKOOckRGLOHbbPwnkpb2b/sNVhxvYyXksXo
4UpZ5jsQHhS4oJAaohRWJbC08Uf1YTmIcjZU2F/dEbBefa0rrWeJNS31AC25uLqqZqg3lQ4CBebL
P+vRm2gpI7nCARbbNMTYzuj6TuEY0cZCh3XG1pIqTOPRbA22I5CjeTqDhhg/kaEMerNQsCBFOGJ/
ztYC1Kx/lNADBwiGXBDJmWxKUmB1zYg3GA+SpCbWqQVdla0fahw1wMDBc1ix6vzSAMWy57hioZiC
21IJbXsGnNO9OXw7TebAr1+al2HBVpYgS7AGCJMN5pYbdjAINvZ709wPD7CSihDXHwhJ44mpe3Sd
i2SdX0vU2S1Rp+nUKQ6x4xpcbGvgW19sa/E5XFq2Esyygy1IXYyPOV8I0cz1vbJw2fDRyrHitGYB
Drll+22E6N6V063TK1uL/MkajfKVTyrU/bVC3d0KdVuNlnVgHG1cMR0PGsyBN01rtgf2t7t3nDTu
y1Saq6ZOjfpnUgJj9uclqIrB7p+M+6TdXzweChI7mE9NBk9pl6MxUPyzKK2pbB/4sluFFLcSfSyB
uJuJPvt2Tk8ikwrQlIXyA4KJXUXBIE0RUgNQDtIuUHAP3I6GdxpPEWLMW0oh+GWy0ZqdAqgf3NmX
+bHAHq7b6XSgK7gXz2lkO+2m+LjfpWxYeJvZyTTF1x51Nwi9z5AMNGir79e873vwfe8WfT7wPt+A
zzd69PmQYIvs1HKi+R5+x3JqDe/7LFL3KehHcFIyHw7M9fZNWgBl/wnR03B0leAGZtWBSCwqOw0U
dO+IApVaBrvZh8V184b09m/qjCE6k+wUJmMnBqoZnxvXGnK2VmkdS2/dtEs/x9JuzyluYvH+Hbu0
xZbuUBcwBbM4ZKFo85V32cpfsiB32NIuW9pjS/fY0hts6T5bepMtvcWW3mZL77ClB+w6HLKlX2Fp
r+MU9/niu3zxEe1H94ZdfE+ixZ5dfF/WdjDgayre69jFD2QnXbv4G76Tb/ni72Tft+3ih7R8TuW/
Yekdp/Tv1MUNB7xHVNxx5viYim86K3LMw/FEztHp+6mcjFP7H3zt72VtBxmeSQCdLXsuazud/MD3
/U9Z7HTyIz/Ln+Qsb9nFP/Od/MIjzwsWXV+ypUMsve0AfYqlNx0iMaJSZ5XGLCZEVOqg3oTwwyk9
o7rOXp0TZM5KTIkEOrP4FzvaK+rBWZ0ZrYMz2lwuvIOMMQtwQsM5dRcsRXnN1l2ypSt2GilN2dmM
Nbs8b9jNuJB44gz3lu3iHYsR/6aOnbqX7JR/YzFtk9XN+LLo7UmanMyG4h9N01lhkS67YTCLXsfJ
i5uQLVxbAZhtthgBNKGbvrT8ANXNvfVkEi1DsPVAkR6+nhbvsF4If+10RUebQ+nJokQUr9do7hhQ
uIcajYFPIjWA+M8cAJ94AvamITmUQ2E5jiXZcpxroG1HNqa4wmoks8Jm4N0jIxnl8bEibxeywEYN
22W8waynl283lLmDtGrxS1EgZ6GBfhTFfSnQ0IU4IJfu1TCIlw/3uZQ/KTGQ71V2up7OxpmYStXH
T+5LAsos3yertm31qD6Fym9EB0xy7XVsQZlqaMnLMGELzto0TbOGJ0SkPclsahRKr8iyswk/BEYj
3z4Kx7B+qz4CQTY0YnIpFnw2nYyjSfDoybc1sN8+60+ShdgD8TusX8COfwZuSpNazX0VoOhTnIsf
l2Jj8COowMhmar2Ap0nzVEwd1NskJpvGZ1L1QhEnxUsRsUJbzhNYNZkxUR64QU9w6KfiBMwP9GnT
hwzjxIt5Qn/K64FsFsZRv//856dgYUOnZWeH1qHV7/dawYWAW4Ak1sBVL1PTp98/efz0udFYLhq1
Jk8R2RLeDHxjWQ3ns6H1Ejz+KGpPogidv8yZtgQSqvxuK7kY4NEwjYHQDN9OY0EdJpPZenXepF/2
7slunj04fh4U9yX2WXeFP9Q2i4O0XqUnp9EJtWnWO3UD6xwYh+s0mSVDyDA3eV8Y3b6qwNj1YXy9
Fo/mdSxqpNEojcZXBI/rpgpkPR8ygcDiF1w+QXLVnfX6qALTXi5Mw9lZdCrevlffTr6jKtDdIOjE
SXkssFWibhsyrLUvkNSAp4B1z0oSkNELQXbjOJodUNPB/qCHt/XBYLCMxtelNFPcIMnFdbC33x/s
W4QlUIDaZcXUyAYGwBn1z6IUbgDti0V2ov3+gyfftH77Df5FrIDtdybtVuVya0EZUhdqnO0doKfe
KU3GtE2p8cXeRyiZgy1Jv8NPIDFJqgLepG4wBfz94PhrdxKaFD4+ev6dKc2FLziuNCAbJfEbiO3/
PPoJLo1Hw+cCqcXK7cIeZ3yXwd1kHJfJcqk/2TbRll+31dQmw1b7U+AwgFikliS4GE7TE9C79C2F
hxzgukCb2MEA8edPG1fbY/I4T9Nl4DjKWAxQ/keSnRGPlgHZNYalf208fMn2R2/PpuYtE54MdAEW
p3IwOBU83CvnXGSOA4JXmUlbYaDdwGQY6TlF5dDp9r44jQnkA7U6xrYATvR2mja7rcy+dy5OfVOx
Lovui97LcNETfx9KpncxXUTNRbf1VaclgamPyI0RvhDx0PV6hfVUUmNxJ79qtoiMYArjdvdANYJv
SmGE3zoHgLZHoNHSuDdeL3oCqhfdlyHw8KNZsorot/mro/P6UoOeKAo7ukoPq+hfXd0gehuNZotm
HVVp9TD7fztORrNoUoduZFUJObQIqJr8pPIfwwQoHIWeAQtyzwQZCEd/Mkb+EGEjDlGUi13PPsAs
w/pS69gUS9pSyCfF+ihw/g/9vdpZkbsAAA==
--=-=-=--




\start
Date: Tue, 22 May 2007 00:09:55 +0200 (CEST)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: changes

> re: hyper missing
>
> ok. i've fixed the missing hyper directory on svn. it's rather curious
> because the git and svn versions came from the same source tree. the
> git version properly checked in the hyper directory but svn did
> not. most everything else got checked in.... how very curious.
>

I updated the svn and tried to build it.  Note that I am working on
the copy of the SVN tree.  The machine is 64-bit Debian.

I run configure first:

hebisch@iduo7:~/ax-daly/axiom$ ./configure
Linux


==========================
==========================
=
You must set your AXIOM and PATH variables. Type:

To build the rest of the system type:

export AXIOM=/h/ax-daly/axiom/mnt/linux
export PATH=$AXIOM/bin:$PATH
make

configure finished.


Ok, so I proceed as instructed:

hebisch@iduo7:~/ax-daly/axiom$ (export AXIOM=/h/ax-daly/axiom/mnt/linux; =
export
 PATH=$AXIOM/bin:$PATH; make)
13 making noweb

a lot of noise which looks OK.  But then the build stops:

make[1]: Wej=B6cie do katalogu `/h/ax-daly/axiom'
11 checking directory structure
12 Environment: PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D=
_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF= -L/usr/X11R6/lib /usr=
/X11R6/lib/libXpm.a  CC=gcc AWK=gawk RANLIB=ranlib TOUCH=touch TAR=
=tar AXIOMXLROOT=/h/ax-daly/axiom/mnt/linux/=
compiler O=o BYE=bye LISP=lsp DAASE=/h/ax-daly/axiom/src/share XLIB=
=/usr/X11R6/lib GCLOPTS=--enable-vssize=65536*2 --enable-locbfd --dis=
able-dynsysbfd --disable-statsysbfd --enable-maxpage=256*1024 --disable-x=
gcl --disable-tkconfig SRCDIRS=bootdir interp=
dir sharedir algebradir etcdir clefdir docdir graphdir smandir hyperdir inp=
utdir  PATCH=patch
cp: nie mo=BFna utworzy=E6 zwyk=B3ego pliku `/h/ax-daly/axiom/mnt/linux/bin=
/tex/.svn/README.txt': Brak dost=EApu
cp: nie mo=BFna utworzy=E6 zwyk=B3ego pliku `/h/ax-daly/axiom/mnt/linux/bin=
/tex/.svn/wcprops/axiom.sty.svn-work': Brak dost=EApu
cp: nie mo=BFna utworzy=E6 zwyk=B3ego pliku `/h/ax-daly/axiom/mnt/linux/bin=
/tex/.svn/format': Brak dost=EApu


The error message is in Polish, translated says: cannot create ordinary
file ...: Permission denied

This problem should be very easy to fix, but do you think it makes sense
to work solving already solved (by Gaby) problem?

\start
Date: Tue, 22 May 2007 00:30:00 +0200 (CEST)
From: Waldek Hebisch
To: Waldek Hebisch
Subject: re: changes

I wrote:
> > re: hyper missing
> >
> > ok. i've fixed the missing hyper directory on svn. it's rather curious
> > because the git and svn versions came from the same source tree. the
> > git version properly checked in the hyper directory but svn did
> > not. most everything else got checked in.... how very curious.
> >
>
> I updated the svn and tried to build it.  Note that I am working on
> the copy of the SVN tree.  The machine is 64-bit Debian.
>
> I run configure first:
>
...

> cp: nie mo=BFna utworzy=E6 zwyk=B3ego pliku `/h/ax-daly/axiom/mnt/linux/b=
in/tex/.svn/format': Brak dost=EApu
>
>
> The error message is in Polish, translated says: cannot create ordinary
> file ...: Permission denied
>

I tried again, this time I removed all .svn subdirectories from the tree.
The build went further, but failed building gcl:

>
Loading cmpnew/gcl_collectfn.lsp
Finished loading cmpnew/gcl_collectfn.lsp

Error: The variable |
| is unbound.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by PROGN.
Broken at PROGN.  Type :H for Help.
>>make[2]: *** [gcldir] B=B3=B1d 255
make[2]: Opuszczenie katalogu `/h/ax-daly/axiom/lsp'
make[1]: *** [lspdir] B=B3=B1d 2
make[1]: Opuszczenie katalogu `/h/ax-daly/axiom'
make: *** [all] B=B3=B1d 2

\start
Date: Tue, 22 May 2007 00:35:45 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: TeXmacs+Axiom

>> woodpecker:~>type axiom
>> axiom is hashed (/home/hemmecke/software/Axiom/mnt/linux/bin/axiom)
>> woodpecker:~>type AXIOMsys
>> AXIOMsys is /home/hemmecke/software/Axiom/mnt/linux/bin/AXIOMsys
> 
> I whould have said
> 
>   ~> which axiom
>   ~> which AXIOMsys
> 
> but that's ok.

Oh, but I am using bash, and I remember that I once had the problem that 
I brought a program "foo" to be visible via "which" as

/some/path/foo

but simply calling "foo" on the command line would lead me to the "foo" 
whose path was stored in the bash hash. Of course that is usually the 
same except that your PATH variable starts with $HOME/bin, and you move 
a program there.

You probably know what the second call to AXIOMsys returns

woodpecker:~>AXIOMsys
                         AXIOM Computer Algebra System
                        Version: Axiom (September 2006)
               Timestamp: Friday September 29, 2006 at 14:21:21
-----------------------------------------------------------------------------
    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) -> )quit
    Please enter y or yes if you really want to leave the interactive
       environment and return to the operating system:
y
woodpecker:~>type AXIOMsys
AXIOMsys is hashed (/home/hemmecke/local/bin/Linux/AXIOMsys)
woodpecker:~>which AXIOMsys
/home/hemmecke/local/bin/Linux/AXIOMsys
woodpecker:~>echo "echo MyAxiomSys" > bin/AXIOMsys; chmod +x bin/AXIOMsys
woodpecker:~>type AXIOMsys
AXIOMsys is hashed (/home/hemmecke/local/bin/Linux/AXIOMsys)
woodpecker:~>which AXIOMsys
/home/hemmecke/bin/AXIOMsys
woodpecker:~>AXIOMsys
                         AXIOM Computer Algebra System
                        Version: Axiom (September 2006)
               Timestamp: Friday September 29, 2006 at 14:21:21
-----------------------------------------------------------------------------
    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) ->

> What happens when you just type?
> 
>   ~> AXIOMsys

See the first call of AXIOMsys above.

\start
Date: Tue, 22 May 2007 01:03:06 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: [Axiom-developer] Re: TeXmacs+Axiom
Cc: Alasdair McAndrew
	
On 05/21/2007 11:48 PM, Martin Rubey wrote:
> Dear all,
> 
> I've finally got it working.  I did the following:
> 
> save the code below (it is a modified tm_axiom.c following the instructions of
> Andrey Grozin on MathAction)

I like that when you give such a clear reference. :-( Is it so hard to 
paste the URL into a mail?

> into a file tm_axiom.c and say
> 
>   gcc tm_axiom
> 
> as root, modify line 20 of /usr/share/texmacs/TeXmacs/plugins/axiom/progs to
> read
> 
>   (:require (url-exists-in-path? "$AXIOM/bin/axiom"))
> 
> and copy tm_axiom to the place where it belongs:
> 
>   sudo mv a.out /usr/lib/texmacs/TeXmacs/bin/tm_axiom

> Most likely you will have to modify paths according to your situation. If you
> are not root, I guess you can place the files into your .TeXmacs directory (try
> cd .TeXmacs at a shell prompt).

I tried to put it at /usr/lib/texmacs/TeXmacs/bin/tm_axiom .

Well, at least I don't see strange output. I can enter Axiom commands 
and I see... *nothing*. No output at all, only the input that I type is 
all that I see.

woodpecker:~>cat axiom.input
)set output tex on
)set output algebra off
)set compiler args -Fasy -Fao -flsp -laxiom -DAxiom -Y 
$AXIOM/../../share/algebra -v -O

and I started texmacs from my HOME and even said
)set output tex on
)set output algebra off
inside the TeXmacs-Axiom session.

No output.

\start
Date: Tue, 22 May 2007 01:18:04 +0200
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: re: changes

I use Axiom via SVK, but you see the corresponding "orig" svn revisions
below.

woodpecker:~>svk log -v /mirror/axiom/branches -r74:73
----------------------------------------------------------------------
r74 (orig r75):  hemmecke | 2006-08-01 16:45:56 +0200
Changed paths:
   M  /axiom/branches/build-improvements/ChangeLog
   M  /axiom/branches/build-improvements/Makefile.pamphlet
   M  /axiom/branches/build-improvements/src/doc/Makefile.pamphlet
   M  /axiom/branches/build-improvements/src/scripts/Makefile.pamphlet

Fix: After checking out the trunk of Axiom Silver, a 'make' did not
succeed because the src/script and src/doc/ps directories were copied
twice. Since the .svn directory inside contains write-protected files,
it caused problems.

----------------------------------------------------------------------
r73 (orig r74):  hemmecke | 2006-08-01 16:17:28 +0200
Changed paths:
   M  /axiom/branches/build-improvements/ChangeLog
   M  /axiom/branches/build-improvements/src/doc/bookvol1.pamphlet

* src/doc/bookvol1.pamphlet: Removed conflicting explicit
definitions of \spadgraph and \spadfunFrom since they are already
defined in exactly the same way in src/doc/axiom.sty.pamplet.

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

As you see, Tim, I have also corrected bookvol1.pamphlet long time ago.

Ralf

On 05/22/2007 12:09 AM, Waldek Hebisch wrote:
>> re: hyper missing
>>
>> ok. i've fixed the missing hyper directory on svn. it's rather curious=

>> because the git and svn versions came from the same source tree. the
>> git version properly checked in the hyper directory but svn did
>> not. most everything else got checked in.... how very curious.
>>
>
> I updated the svn and tried to build it.  Note that I am working on
> the copy of the SVN tree.  The machine is 64-bit Debian.
>
> I run configure first:
>
> hebisch@iduo7:~/ax-daly/axiom$ ./configure
> Linux
>
>
> =========================
==========================
==
> You must set your AXIOM and PATH variables. Type:
>
> To build the rest of the system type:
>
> export AXIOM=/h/ax-daly/axiom/mnt/linux
> export PATH=$AXIOM/bin:$PATH
> make
>
> configure finished.
>
>
> Ok, so I proceed as instructed:
>
> hebisch@iduo7:~/ax-daly/axiom$ (export AXIOM=/h/ax-daly/axiom/mnt/lin=
ux; export
>  PATH=$AXIOM/bin:$PATH; make)
> 13 making noweb
>
> a lot of noise which looks OK.  But then the build stops:
>
> make[1]: Wej=B6cie do katalogu `/h/ax-daly/axiom'
> 11 checking directory structure
> 12 Environment: PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wal=
l -D_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF= -L/usr/X11R6/li=
b /usr/X11R6/lib/libXpm.a  CC=gcc AWK=gawk RANLIB=ranlib TOUCH=to=
uch TAR=tar AXIOMXLROOT=/h/ax-daly/axiom/mnt/linux/compiler O=o BYE=
=bye LISP=lsp DAASE=/h/ax-daly/axiom/src/share XLIB=/usr/X11R6/li=
b GCLOPTS=--enable-vssize=65536*2 --enable-locbfd --disable-dynsysbfd=
 --disable-statsysbfd --enable-maxpage=256*1024 --disable-xgcl --disabl=
e-tkconfig SRCDIRS=bootdir interpdir sharedir algebradir etcdir clefdir=
 docdir graphdir smandir hyperdir inputdir  PATCH=patch
> cp: nie mo=BFna utworzy=E6 zwyk=B3ego pliku `/h/ax-daly/axiom/mnt/linux=
/bin/tex/.svn/README.txt': Brak dost=EApu
> cp: nie mo=BFna utworzy=E6 zwyk=B3ego pliku `/h/ax-daly/axiom/mnt/linux=
/bin/tex/.svn/wcprops/axiom.sty.svn-work': Brak dost=EApu
> cp: nie mo=BFna utworzy=E6 zwyk=B3ego pliku `/h/ax-daly/axiom/mnt/linux=
/bin/tex/.svn/format': Brak dost=EApu
>
>
> The error message is in Polish, translated says: cannot create ordinary=

> file ...: Permission denied
>
> This problem should be very easy to fix, but do you think it makes sens=
e
> to work solving already solved (by Gaby) problem?

\start
Date: Mon, 21 May 2007 18:40:21 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: .svn copy problem

sigh. SVN bites me again.

Waldek said:
> This problem should be very easy to fix, but do you think it makes sense
> to work solving already solved (by Gaby) problem?

Please point me to the diff -Naur postings on axiom-developer.org

The fact that the problem is solved in a branch does not mean that the
problem is "solved". I merged every change I understood from Gaby's
branch and from your branch. Cleary I did not see this change.

This goes back to the question of "community". It takes much more
effort to make your changes available to everyone than it does to
solve it for yourself. I can't do everything and clearly this isn't
a problem that happens to me so I can't even test it.

Please make a diff-Naur change against gold --patch-50 or
svn...branches/daly/axiom so we can get it into the next release.

\start
Date: Mon, 21 May 2007 18:41:30 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: bookvol1

Ralf said:
> As you see, Tim, I have also corrected bookvol1.pamphlet long time ago

Please point me to the diff -Naur postings on axiom-developer.org

\start
Date: Tue, 22 May 2007 02:21:55 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: .svn copy problem

svn log -v 
https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements 
-r74:75

svn diff 
https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements 
-r74:75

everything on *one line*.

That is not a diff-Naur against Gold (which I don't know exactly how to 
do), but these differences show the minimum of what I have actually 
modified.

Ralf

On 05/22/2007 01:40 AM, Tim Daly wrote:
> sigh. SVN bites me again.
> 
> Waldek said:
>> This problem should be very easy to fix, but do you think it makes sense
>> to work solving already solved (by Gaby) problem?
> 
> Please point me to the diff -Naur postings on axiom-developer.org
> 
> The fact that the problem is solved in a branch does not mean that the
> problem is "solved". I merged every change I understood from Gaby's
> branch and from your branch. Cleary I did not see this change.
> 
> This goes back to the question of "community". It takes much more
> effort to make your changes available to everyone than it does to
> solve it for yourself. I can't do everything and clearly this isn't
> a problem that happens to me so I can't even test it.

But the svn archive is open? Nobody hides anything? The problem is more 
that we have too many revision control systems. If we just agreed on SVN 
than a simple "svn merge" would do.

> Please make a diff-Naur change against gold --patch-50 or
> svn...branches/daly/axiom so we can get it into the next release.

\start
Date: Tue, 22 May 2007 02:23:02 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: bookvol1

I probably make some errors but let me try.

On 05/22/2007 01:41 AM, Tim Daly wrote:
> Ralf said:
>> As you see, Tim, I have also corrected bookvol1.pamphlet long time ago
> 
> Please point me to the diff -Naur postings on axiom-developer.org
> 
> t

I think you can easily get this from svn yourself. Why must I spam the 
list with that?

svn log -v 
https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements 
-r73:74
------------------------------------------------------------------------
r74 | hemmecke | 2006-08-01 16:17:28 +0200 (Tue, 01 Aug 2006) | 4 lines
Changed paths:
    M /branches/build-improvements/ChangeLog
    M /branches/build-improvements/src/doc/bookvol1.pamphlet

* src/doc/bookvol1.pamphlet: Removed conflicting explicit
definitions of \spadgraph and \spadfunFrom since they are already
defined in exactly the same way in src/doc/axiom.sty.pamplet.

svn diff 
https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements 
-r73:74
Index: ChangeLog
===================================================================
--- ChangeLog   (revision 73)
+++ ChangeLog   (revision 74)
@@ -1,3 +1,9 @@
+2006-08-01  Ralf Hemmecke  Ralf Hemmecke
+
+       * src/doc/bookvol1.pamphlet: Removed conflicting explicit
+       definitions of \spadgraph and \spadfunFrom since they are already
+       defined in exactly the same way in src/doc/axiom.sty.pamplet.
+
  2006-07-15  Gabriel Dos Reis  Gabriel Dos Reis

         * Makefile.pamphlet (VERSION): Update.
Index: src/doc/bookvol1.pamphlet
===================================================================
--- src/doc/bookvol1.pamphlet   (revision 73)
+++ src/doc/bookvol1.pamphlet   (revision 74)
@@ -13,13 +13,6 @@
  \setcounter{bottomnumber}{50}


-%% 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}}
-
  %% spadsig gives the standard -> notation for signatures
  \newcommand{\spadsig}[2]{{\sf #1 $\rightarrow$ #2}}

\start
Date: Mon, 21 May 2007 22:12:36 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: TeXmacs+Axiom
Cc: Alasdair McAndrew

On May 21, 2007 2:39 PM Martin Rubey wrote:
> ..
> I get the same error as Ralf, although AXIOMsys
> and axiom certainly are in the path.  (and I didn't
> modify tm_axiom either) Note however, that I'm using
> wh-sandbox, which has a slightly different banner.
> Maybe that's the problem?
>
> On the console I get:
>
> martin@rubey-laptop:~$ texmacs --debug-io
> TeXmacs] With linked TrueType support
> TeXmacs] Launching 'tm_axiom'
> [BEGIN]verbatim:
>

On May 21, 2007 5:48 PM Martin Rubey wrote:
>
> I've finally got it working.

Besides the stuff that you describe below to make tm_axiom
call axiom instead of AXIOMsys, could you say what you did
first just to get it to work as it should "out of the box"?
Of course just to use Axiom in TeXmacs it should not be
necessary to do any of this. If *both* axiom and AXIOMsys
are in the PATH, it should just work. I would like to know
why this did not work initially for either Ralf or for you.

> I did the following:
>
> save the code below (it is a modified tm_axiom.c following
> the instructions of Andrey Grozin on MathAction) into a
> file tm_axiom.c and say
>
>   gcc tm_axiom
>

Ralf, I gave this link to Andrey Grozin post on the Axiom
Wiki in an email earlier today:

http://wiki.axiom-developer.org/TeXmacs#msg20051012034957-0500@www.axiom-=
dev
eloper.org

> as root, modify line 20 of
> /usr/share/texmacs/TeXmacs/plugins/axiom/progs to
> read
>
>   (:require (url-exists-in-path? "$AXIOM/bin/axiom"))
>
> and copy tm_axiom to the place where it belongs:
>
>   sudo mv a.out /usr/lib/texmacs/TeXmacs/bin/tm_axiom
>
> Most likely you will have to modify paths according to
> your situation.

Yes, the path to tm_axiom is a little different under
Debian and Kubuntu then for other installations of TeXmacs -
something to do with Debian conventions.

> If you are not root, I guess you can place the files
> into your .TeXmacs directory (try cd .TeXmacs at a shell
> prompt).
>

Does that work for tm_axiom? If so, then maybe that is
a good way to vary the behaviour of the Axiom in TeXmacs
rather than changing /usr/lib/texmacs/TeXmacs/bin/tm_axiom
in the standard distribution.

> When inserting an Axiom session in TeXmacs, be patient
> and wait until HyperDoc appears (maybe a second or so).
> If you type something into the prompt before that,
> texmacs will hang.
>

There are other problems concerning using hyperdoc in
TeXmacs, for example running examples and even browsing
the database can (sometimes) interferes with TeXmacs and
communications between TeXmacs and Axiom can be disrupted.
For that reason if I want to access hyperdoc (which for
me is actually very seldom) I just start a separate Axiom
process. That way there is no possibility for problems
since hyperdoc runs in a different process tree and talks
to it's own copy of AXIOMsys.

However it makes sense to me to make the modification
suggested by Andrey if the main goal is to have access
to Axiom graphics. In that case it would be best to run
Axiom via the command 'axiom -noht -noclef' in tm_axiom
to reduce the number of extra processes started. Axiom
graphics still starts a new windows outside of TeXmacs
but at least there are commands one can enter in the
TeXmacs Axiom session that will operate the graphics
windows remotely and do things like create a postscript
format output file which can then be included in TeXmacs.
Since the usual goal of using TeXmacs is to produce a
document as a repeatable final product, I think it is
generally a good idea to use Axiom graphics this way
from within TeXmacs rather than in the usual interactive
mode.

> Personally, I prefer emacs, since I use it for reading
> mail and svn.  But I guess many will prefer texmacs.

I do not think emacs and TeXmacs are really comparable
as an interface to Axiom. TeXmacs is a mathematical
document processor which allows one to directly prepare a
publication quality document containing mathematics and
the output of various computer algebra systems. To do
something similar in emacs is a manual process involving
cut-and-paste from buffers and running LaTeX.

>
> Please let me know whether this works for you.
>

It works for me. :-)

\start
Date: Tue, 22 May 2007 04:54:38 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Lisp portability

In my private tree Axiom is nicely working on top of sbcl and clisp.
The remaining known problems are sockets and writeablep function.
Also, currently for clisp I need cl-fad library, which I consider
problematic.  Namely, cl-fad does not work with gcl, so for gcl
we need separate code.  We need only few functions from cl-fad,
to work around clisp weirdness (clisp makes strong distinction
between paths to files and paths to directories and refuses
to perform file operations on directories).  So my current plan
is to eliminate use of cl-fad and provide the needed functions
directly.  Related problem is performing operations on
directories -- to gain portability between Unix and Windows
I tried to use Lisp code.  But each Lisp is doing them
differently (and apparently some operations sometimes are missing).
So I got a maze of conditionals over Lisp implementations.
Looking at resulting code I feel that it is better to
call operationg system utilities and have just use 
conditionals to choose between Unix and Windows versions
of file utilities.

Concerning sockets, we need Unix domain sockets and select.  It
seems that clisp provide both, but to get Unix domain sockets
one needs version including rawsock module, which is not included
in default clisp configuration.  

sbcl offers sb-bsd-sockets which seem to have basic functions,
but I do not see select.

gcl documentation suggest that Unix domain sockets are unsupported.
Also, I see no traces of select.

There is "portable" cl-sockets library but the manual says it supports
Allegro CL, sbcl and cmucl.  The manual does not say anything about
Unix domain sockets or select.  The manual says that cl-sockets requires
UFFI, so presumably cl-sockets works on top of "portable" C library.

In short my finding is that portable Lisp sockets are a myth: all
implementations provide different interface and frequently miss
some essential services.  People who want portablity between Lisp
implementations interface to C. 

Given that it seems that most reasonable way for Axiom is to use
existiong C code.  There is are drawbacks: we need to interface to
C and typical Lisp implementation can only interface to shared
libraries via dlopen.  So we need to handle issues related to making
shared library.

But AFAICS we will need C interface anyway, so we need to resolve
problems of C interface and shared libraries.

\start
Date: Tue, 22 May 2007 13:06:44 +1000
From: Alasdair McAndrew
To: list
Subject: re: TeXmacs+Axiom

I will give this new tm_axiom a go.  Although, with Martin, I prefer emacs -
I always have an emacs window running (I use LaTeX with the emacs auctex
mode for all my document preparation), and my ideal interface for axiom
would be an emacs mode which produces output as a TeX'ed graphic - such as
imaxima does for maxima.  I find TeXmacs slow and a bit clumsy.

Also, which of emacs or TeXmacs provides better support for spad/aldor
programming (syntax highlighting, automatic indentation, parentheses
matching and so on)?

-Alasdair

On 5/22/07, Bill Page wrote:
>
> On May 21, 2007 2:39 PM Martin Rubey wrote:
> > ..
> > I get the same error as Ralf, although AXIOMsys
> > and axiom certainly are in the path.  (and I didn't
> > modify tm_axiom either) Note however, that I'm using
> > wh-sandbox, which has a slightly different banner.
> > Maybe that's the problem?
> >
> > On the console I get:
> >
> > martin@rubey-laptop:~$ texmacs --debug-io
> > TeXmacs] With linked TrueType support
> > TeXmacs] Launching 'tm_axiom'
> > [BEGIN]verbatim:
> >
>
> On May 21, 2007 5:48 PM Martin Rubey wrote:
> >
> > I've finally got it working.
>
> Besides the stuff that you describe below to make tm_axiom
> call axiom instead of AXIOMsys, could you say what you did
> first just to get it to work as it should "out of the box"?
> Of course just to use Axiom in TeXmacs it should not be
> necessary to do any of this. If *both* axiom and AXIOMsys
> are in the PATH, it should just work. I would like to know
> why this did not work initially for either Ralf or for you.
>
> > I did the following:
> >
> > save the code below (it is a modified tm_axiom.c following
> > the instructions of Andrey Grozin on MathAction) into a
> > file tm_axiom.c and say
> >
> >   gcc tm_axiom
> >
>
> Ralf, I gave this link to Andrey Grozin post on the Axiom
> Wiki in an email earlier today:
>
>
> http://wiki.axiom-developer.org/TeXmacs#msg20051012034957-0500@www.axiom-dev
> eloper.org
>
> > as root, modify line 20 of
> > /usr/share/texmacs/TeXmacs/plugins/axiom/progs to
> > read
> >
> >   (:require (url-exists-in-path? "$AXIOM/bin/axiom"))
> >
> > and copy tm_axiom to the place where it belongs:
> >
> >   sudo mv a.out /usr/lib/texmacs/TeXmacs/bin/tm_axiom
> >
> > Most likely you will have to modify paths according to
> > your situation.
>
> Yes, the path to tm_axiom is a little different under
> Debian and Kubuntu then for other installations of TeXmacs -
> something to do with Debian conventions.
>
> > If you are not root, I guess you can place the files
> > into your .TeXmacs directory (try cd .TeXmacs at a shell
> > prompt).
> >
>
> Does that work for tm_axiom? If so, then maybe that is
> a good way to vary the behaviour of the Axiom in TeXmacs
> rather than changing /usr/lib/texmacs/TeXmacs/bin/tm_axiom
> in the standard distribution.
>
> > When inserting an Axiom session in TeXmacs, be patient
> > and wait until HyperDoc appears (maybe a second or so).
> > If you type something into the prompt before that,
> > texmacs will hang.
> >
>
> There are other problems concerning using hyperdoc in
> TeXmacs, for example running examples and even browsing
> the database can (sometimes) interferes with TeXmacs and
> communications between TeXmacs and Axiom can be disrupted.
> For that reason if I want to access hyperdoc (which for
> me is actually very seldom) I just start a separate Axiom
> process. That way there is no possibility for problems
> since hyperdoc runs in a different process tree and talks
> to it's own copy of AXIOMsys.
>
> However it makes sense to me to make the modification
> suggested by Andrey if the main goal is to have access
> to Axiom graphics. In that case it would be best to run
> Axiom via the command 'axiom -noht -noclef' in tm_axiom
> to reduce the number of extra processes started. Axiom
> graphics still starts a new windows outside of TeXmacs
> but at least there are commands one can enter in the
> TeXmacs Axiom session that will operate the graphics
> windows remotely and do things like create a postscript
> format output file which can then be included in TeXmacs.
> Since the usual goal of using TeXmacs is to produce a
> document as a repeatable final product, I think it is
> generally a good idea to use Axiom graphics this way
> from within TeXmacs rather than in the usual interactive
> mode.
>
> > Personally, I prefer emacs, since I use it for reading
> > mail and svn.  But I guess many will prefer texmacs.
>
> I do not think emacs and TeXmacs are really comparable
> as an interface to Axiom. TeXmacs is a mathematical
> document processor which allows one to directly prepare a
> publication quality document containing mathematics and
> the output of various computer algebra systems. To do
> something similar in emacs is a manual process involving
> cut-and-paste from buffers and running LaTeX.
>
> >
> > Please let me know whether this works for you.
> >
>
> It works for me. :-)

\start
Date: Mon, 21 May 2007 23:19:03 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: Lisp portability
Cc: Camm Maguire

On May 21, 2007 10:55 PM Waldek Hebisch wrote:
> ...
> currently for clisp I need cl-fad library, which I consider
> problematic.  Namely, cl-fad does not work with gcl, so for
> gcl we need separate code.

In general Camm Maguire (the primary developer go GCL) has
expressed strong interest in improving GCL's support for
ANSI common Lisp. If solving the problems of cl-fad on GCL
would further this goal, I expect that we could count on
his help (time available of course not withstanding).

> We need only few functions from cl-fad, to work around clisp
> weirdness (clisp makes strong distinction between paths to
> files and paths to directories and refuses to perform file
> operations on directories).  So my current plan is to eliminate
> use of cl-fad and provide the needed functions directly.

Using a "standard" common lisp package seems preferrable to me
even if has more functionaly than is currently required.

> Related problem is performing operations on directories --
> to gain portability between Unix and Windows I tried to use
> Lisp code.  But each Lisp is doing them differently (and
> apparently some operations sometimes are missing). So I got
> a maze of conditionals over Lisp implementations. Looking at
> resulting code I feel that it is better to call operationg
> system utilities and have just use conditionals to choose
> between Unix and Windows versions of file utilities.

I hope you mean calling the operating system routines directly
(e.g. SI:: in GCL) and not resorting to spawning a new process
to run shell commands (e.g. as is done one in Axiom's OBEY).

> 
> Concerning sockets, we need Unix domain sockets and select.
> It seems that clisp provide both, but to get Unix domain
> sockets one needs version including rawsock module, which
> is not included in default clisp configuration.  
> 
> sbcl offers sb-bsd-sockets which seem to have basic
> functions, but I do not see select.
> 
> gcl documentation suggest that Unix domain sockets are
> unsupported. Also, I see no traces of select.
> 
> There is "portable" cl-sockets library but the manual says
> it supports Allegro CL, sbcl and cmucl.  The manual does not
> say anything about Unix domain sockets or select.  The manual
> says that cl-sockets requires UFFI, so presumably cl-sockets
> works on top of "portable" C library.
>

Again I believe both cl-sockets and UFFI have been discussed
as possible targets for GCL. I am not sure how close to reality
such support might be. Camm?
 
> In short my finding is that portable Lisp sockets are a myth:
> all implementations provide different interface and frequently
> miss some essential services.  People who want portablity
> between Lisp implementations interface to C. 
> 
> Given that it seems that most reasonable way for Axiom is to
> use existiong C code.  There is are drawbacks: we need to
> interface to C and typical Lisp implementation can only
> interface to shared libraries via dlopen.  So we need to
> handle issues related to making shared library.
> 
> But AFAICS we will need C interface anyway, so we need to
> resolve problems of C interface and shared libraries.
> 

+1 Yes, this is very important.

\start
Date: Mon, 21 May 2007 23:23:12 -0400
From: Alfredo Portes
To: Martin Rubey
Subject: Live CD + Guess Package + Vmware

Hi Martin,

I created a live cd of Waldek branch with your guess package in case you need
to demonstrate your program. You can get it from:

http://alfredo.axiom-developer.org/axiom.zip

Actually the zip contains the vmware file to run it with vmware
player. Like Bill pointed
out in a previous email, this is a good way to have hyperdoc on
windows, until a
replacement/portable version is created.

\start
Date: Mon, 21 May 2007 23:34:43 -0400
From: Bill Page
To: Alasdair McAndrew
Subject: re: TeXmacs+Axiom

On May 21, 2007 11:07 PM Alasdair McAndrew wrote:

> I will give this new tm_axiom a go.  Although, with Martin,
> I prefer emacs - I always have an emacs window running (I use
> LaTeX with the emacs auctex mode for all my document preparation),
> and my ideal interface for axiom would be an emacs mode which
> produces output as a TeX'ed graphic - such as imaxima does for
> maxima.  I find TeXmacs slow and a bit clumsy. 

I agree however I think the use of TeX'ed graphics is rather
clumsy. Have you used imaxima extensively for this purpose?

One thing that I think would make using Axiom in LaTeX more
straight forward would be a the kind of LaTeX package that
was implemented for Sage. This permits one to write:

  \begin{sageblock}
  sage commands
  \end{sageblock}

to execute arbitrary commands and \sage{ sage expression }
to automatically include the results of calculations in
your LaTeX document.

There is an example of this on the Axiom Wiki. I think to
modify the 'sage.tex' file to work with directly with Axiom
would not be a difficult task for someone moderately familiar
with TeX macros.

> Also, which of emacs or TeXmacs provides better support for
> spad/aldor programming (syntax highlighting, automatic
> indentation, parentheses matching and so on)?

So far as I know that answer is neither. :-( Although there
do obviously exist some some similar emacs modes for other
languages and packages that might be fairly easily adapted to
this purpose.

\start
Date: Mon, 21 May 2007 23:58:09 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Live CD + Guess Package + Vmware

On May 21, 2007 11:23 PM Alfredo Portes wrote:
> 
> I created a live cd of Waldek branch with your guess package 
> in case you need to demonstrate your program.

Let's avoid the use of personal names in reference to branches
in SVN unless the original author of the branch specifically
requests it. Actually I like to think of wh-sandbox as the best
version of Axiom that we have available right now even though
it is still under development.

> You can get it from:
> 
> http://alfredo.axiom-developer.org/axiom.zip
>

Great! Thank you very much Alfredo.
 
> Actually the zip contains the vmware file to run it with
> vmware player. Like Bill pointed out in a previous email,
> this is a good way to have hyperdoc on windows, until a
> replacement/portable version is created.
> 

My favorite mode of running hyperdoc on windows is via putty
X11 forwarding and Xming.

putty http://www.chiark.greenend.org.uk/~sgtatham/putty
      http://en.wikipedia.org/wiki/PuTTY

is an execellent Telnet and SSH client that runs on Windows.
I use it all the time as a direct replacement for ssh.

Xming http://sourceforge.net/projects/xming

is an amazing free implementation of X Windows server for
Windows. It allows X windows to co-exist peacefully and
artistically along with other windows on the Windows Desktop.

These two work together very well.

You need to configure vmware player so that it will allow
"remote" login to the linux running virtually on your machine.
Then after starting the virtual machine, you log in as if it
was a remote computer (putty can be configured to make this
quite seemless) and then start axiom at the first prompt.

Actually I use the free Microsoft Virtual PC program rather
than vmware player since I found it integrates better with
Windows in most cases and appears to do less drastic things
to my machine's configuration. Unfortunately when I tried
the last version of the DoyenCD I had a problem with booting
the version of linux contained on that CD.

Alfredo, are you using the same version of linux on this new
Live CD? Have you tried it with Virtual PC?

http://www.microsoft.com/windows/products/winfamily/virtualpc/default.mspx
http://en.wikipedia.org/wiki/Virtual_PC

\start
Date: Tue, 22 May 2007 00:16:54 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Live CD + Guess Package + Vmware

> Let's avoid the use of personal names in reference to branches
> in SVN unless the original author of the branch specifically
> requests it. Actually I like to think of wh-sandbox as the best
> version of Axiom that we have available right now even though
> it is still under development.

I apologize for that. The actual name of the branch did not
come to me while writing the email.

> My favorite mode of running hyperdoc on windows is via putty
> X11 forwarding and Xming.

I think martin has had problems when trying to demonstrate his
guess package. Maybe this helps people try it easily. That was my
intention with the iso, not Doyen related (at least until the summer).

> Actually I use the free Microsoft Virtual PC program rather
> than vmware player since I found it integrates better with
> Windows in most cases and appears to do less drastic things
> to my machine's configuration. Unfortunately when I tried
> the last version of the DoyenCD I had a problem with booting
> the version of linux contained on that CD.

-1 for Virtual PC :-). The latest version has worked fine also
qemu.

> Alfredo, are you using the same version of linux on this new
> Live CD? Have you tried it with Virtual PC?

Yes I am still using the same linux version (Fedora Core 3). I tried
to get zope/zwiki/latexwiki/... in other distros but it was not as simple
as the current configuration. I would like to have the live cd based
on Ubuntu Live CD, so I dont have to care that much about hardware
support and just focus on Axiom/LatexWiki/interfaces....

I will try Virtual PC.

\start
Date: Tue, 22 May 2007 00:52:50 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Live CD + Guess Package + Vmware

I tried Virtual PC. I still like Vmware better, but that is maybe
because I am bias :-).

> Unfortunately when I tried
> the last version of the DoyenCD I had a problem with booting
> the version of linux contained on that CD.

With VPC 2007, Doyen boots fine. The only problem is the video
card the virtual machine emulates. The CD finds that is S3 and it
uses the S3 driver which apparently is not a good friend of VPC. :-).

Opening a terminal, changing in /etc/X11/xorg.conf from "s3" to "vesa"
and restaring X, fixes the problem.

\start
Date: Mon, 21 May 2007 22:53:56 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Waldek Hebisch
Subject: RE: Lisp portability
Cc: Camm Maguire, list

--- Bill Page wrote:

> On May 21, 2007 10:55 PM Waldek Hebisch wrote:
> > ...
> > currently for clisp I need cl-fad library, which I consider
> > problematic.  Namely, cl-fad does not work with gcl, so for
> > gcl we need separate code.
> 
> In general Camm Maguire (the primary developer go GCL) has
> expressed strong interest in improving GCL's support for
> ANSI common Lisp. If solving the problems of cl-fad on GCL
> would further this goal, I expect that we could count on
> his help (time available of course not withstanding).

I think we need to worry first about ANSI Lisp support and second about
continuing to work on GCL.  GCL is targeting ANSI, so eventually it
should be a moot point anyway, and in the meantime I would suggest we
target the final platform rather than worry about working on
intermediate or outdated Lisp environments.
 
> > We need only few functions from cl-fad, to work around clisp
> > weirdness (clisp makes strong distinction between paths to
> > files and paths to directories and refuses to perform file
> > operations on directories).  So my current plan is to eliminate
> > use of cl-fad and provide the needed functions directly.
> 
> Using a "standard" common lisp package seems preferrable to me
> even if has more functionaly than is currently required.

I would tend to agree.  As we expand Axiom's capabilities we may find
ourselves needing more of the functionality of these libraries.

> > Related problem is performing operations on directories --
> > to gain portability between Unix and Windows I tried to use
> > Lisp code.  But each Lisp is doing them differently (and
> > apparently some operations sometimes are missing). So I got
> > a maze of conditionals over Lisp implementations. Looking at
> > resulting code I feel that it is better to call operationg
> > system utilities and have just use conditionals to choose
> > between Unix and Windows versions of file utilities.
> 
> I hope you mean calling the operating system routines directly
> (e.g. SI:: in GCL) and not resorting to spawning a new process
> to run shell commands (e.g. as is done one in Axiom's OBEY).

Waldek, could you release the conditionalized Lisp code in question
even if we decide not to use it?  It would make an EXCELLENT argument
and case study for making some of these interfaces more uniform between
implementations.
 
> > Concerning sockets, we need Unix domain sockets and select.
> > It seems that clisp provide both, but to get Unix domain
> > sockets one needs version including rawsock module, which
> > is not included in default clisp configuration.  
> > 
> > sbcl offers sb-bsd-sockets which seem to have basic
> > functions, but I do not see select.
> > 
> > gcl documentation suggest that Unix domain sockets are
> > unsupported. Also, I see no traces of select.
> > 
> > There is "portable" cl-sockets library but the manual says
> > it supports Allegro CL, sbcl and cmucl.  The manual does not
> > say anything about Unix domain sockets or select.  The manual
> > says that cl-sockets requires UFFI, so presumably cl-sockets
> > works on top of "portable" C library.

Does http://common-lisp.net/project/usocket/ address this problem at
all?  I don't expect any of these solutions will support GCL at this
time, but hopefully that will come.

I wish we could pull together a meeting of the major implementers of
the Free lisp distributions and the major application developers (ACL2,
Maxima, Axiom...).  Perhaps we could hammer out some common ground on
these issues.  Even an IRC chat could be helpful.

I know I have advocated Lisp implementation independence in the past
and it is still an idea I favor, but if we start to rely on modern
technologies like CFFI, sockets, unicode, telent-clx, cl-pdf, etc. we
run into the problem of simple lack of support for these features in
some of the target platforms.  Looking at the ASDF source code, for
example, one or two of the features of ASDF are not operational on
Clisp due to implementation limitations (apparently.)  I would prefer
to do things the Right Way and ask the implementation if they could
provide support for the missing functionality, as that makes things
much simpler in the long run.

Perhaps we could publish some kind of "missing feature requirements"
report on potential targets for Lisp-Implementation+Operating-System
combinations, once we get a good handle on our requirements.  As people
try to port to various platforms, perhaps we could help guide the
implementers on what features are needed.

CY

P.S. - Waldek, is there a trick to building with sbcl?  I get 
make[2]: *** No rule to make target `sbcl', needed by `do_it.sbcl'. 
Stop.
Sorry if I'm missing something obvious.

\start
Date: Mon, 21 May 2007 23:01:31 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Alasdair McAndrew
Subject: re: TeXmacs+Axiom

--- Bill Page wrote:

> One thing that I think would make using Axiom in LaTeX more
> straight forward would be a the kind of LaTeX package that
> was implemented for Sage. This permits one to write:
> 
>   \begin{sageblock}
>   sage commands
>   \end{sageblock}
> 
> to execute arbitrary commands and \sage{ sage expression }
> to automatically include the results of calculations in
> your LaTeX document.

If people want to pursue this direction, I STRONGLY recommend checking
out EMaxima by Jay Belanger.  It was originally my intent to adapt this
system to Axiom (EAxiom) and Jay did some initial work along those
lines, but the frustration of syntax highlighting problems with
pamphlets and odd Windows quirks resulted in my pursuing other goals
(e.g. cl-web).  EMaxima for Axiom would still be a Very Good Thing,
based on my experiences with EMaxima - Jay has done a magnificent job.
 
\start
Date: 22 May 2007 08:38:55 +0200
From: Martin Rubey
To: Alfredo Portes
Subject: Re: Live CD + Guess Package + Vmware

Alfredo Portes writes:

> Hi Martin,
> 
> I created a live cd of Waldek branch with your guess package in case you need
> to demonstrate your program. You can get it from:
> 
> http://alfredo.axiom-developer.org/axiom.zip

THIS IS WONDERFUL!  I'll download it today! elunch is on thursday, so if it
works I can give it away!

\start
Date: 22 May 2007 11:09:00 +0200
From: Martin Rubey
To: Alasdair McAndrew, Cliff Yapp
Subject: re: TeXmacs+Axiom

Dear Alasdair,

Alasdair McAndrew writes:

> I will give this new tm_axiom a go.  Although, with Martin, I prefer emacs -
> I always have an emacs window running (I use LaTeX with the emacs auctex
> mode for all my document preparation), and my ideal interface for axiom
> would be an emacs mode which produces output as a TeX'ed graphic - such as
> imaxima does for maxima.  I find TeXmacs slow and a bit clumsy.

Oh, I thought you'd prefer TeXmacs for some reason... Well, what concerns emacs
+ axiom, I did not get round to try the axiom mode by Jay Belanger, Cliff Yapp
et al. Unfortunately, I guess that a good emacs mode for .input files would be
the most important thing for axiom *users*.  In particular, it would be good to
have a possibility to send a function definition to a running axiom, via shift
return or something.  But that's probably not so easy.

Cliff, I found the emacs mode documentation very hard to read.  Is there a
small tutorial, and a summary of the available emacs commands?

What concerns programming, since I prefer Aldor to SPAD, I am quite happy with
Ralf's (? I think) aldor.el mode, which comes bundled with ALLPROSE.

For spad.pamphlet (i.e., LaTeX) editing, mmm mode is a wonderful thing.  If you
install ALLPROSE, you'll have all these things automatically set up, I think
that's the easiest way to do it.

\start
Date: 22 May 2007 11:14:49 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: TeXmacs+Axiom
Cc: Alasdair McAndrew

Ralf Hemmecke writes:

> I tried to put it at /usr/lib/texmacs/TeXmacs/bin/tm_axiom .
> 
> Well, at least I don't see strange output. I can enter Axiom commands and I
> see... *nothing*. No output at all, only the input that I type is all that I
> see.

When you start the gcc'd (modified) tm_axiom.c directly, does it start
HyperDoc?

Try also to start it in a directory that does not contain an ".axiom.input".
 
> woodpecker:~>cat axiom.input
> )set output tex on
> )set output algebra off
> )set compiler args -Fasy -Fao -flsp -laxiom -DAxiom -Y
> $AXIOM/../../share/algebra -v -O

does your version of axiom read axiom.input or .axiom.input at startup?  (Mine
reads .axiom.input)

Note that I did not use any )set output commands in texmacs.

\start
Date: Tue, 22 May 2007 11:44:58 +0200 (CEST)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: Lisp portability
Cc: Camm Maguire

CY wrote:
> --- Bill Page wrote:
> 
> > On May 21, 2007 10:55 PM Waldek Hebisch wrote:
> > > ...
> > > currently for clisp I need cl-fad library, which I consider
> > > problematic.  Namely, cl-fad does not work with gcl, so for
> > > gcl we need separate code.
> > 
> > In general Camm Maguire (the primary developer go GCL) has
> > expressed strong interest in improving GCL's support for
> > ANSI common Lisp. If solving the problems of cl-fad on GCL
> > would further this goal, I expect that we could count on
> > his help (time available of course not withstanding).
> 
> I think we need to worry first about ANSI Lisp support and second about
> continuing to work on GCL.  GCL is targeting ANSI, so eventually it
> should be a moot point anyway, and in the meantime I would suggest we
> target the final platform rather than worry about working on
> intermediate or outdated Lisp environments.
>  

1) I need GCL support for regression testing.
2) I hope that Aldor lesson should be clear: avoid waiting on third
   party, this may take long time.  In GCL case we may count on
   goodwill of Camm, but still I do not think taht we should
   cut off our life support and hope that it will be restored 
   on time.
3) ATM core of Axiom is written in a very small subset of Lisp,
   sitting in the intersection of Cltl and Ansi.  We need conditionals
   for things going beyond Ansi or Ansi violations.  Directly
   here GCL is just one more implementation.  Indirectly, we can
   not use some Ansi features.  IMHO _that_ can wait for Ansi
   GCL.

Back to cl-fad: its use of packages is incompatible with Cltl.  If
IIRC Ansi GCL misses one or two odd functions.  But beyond that
we would have to add to cl-fad a bunch of conditionals to
cover GCL case.  That is, we would have to use forked version
of cl-fad.

> > > We need only few functions from cl-fad, to work around clisp
> > > weirdness (clisp makes strong distinction between paths to
> > > files and paths to directories and refuses to perform file
> > > operations on directories).  So my current plan is to eliminate
> > > use of cl-fad and provide the needed functions directly.
> > 
> > Using a "standard" common lisp package seems preferrable to me
> > even if has more functionaly than is currently required.
> 
> I would tend to agree.  As we expand Axiom's capabilities we may find
> ourselves needing more of the functionality of these libraries.
> 

cl-fad really provides very little functionality: the only nifty
feature is ability to recursively walk directory tree.

> > > Related problem is performing operations on directories --
> > > to gain portability between Unix and Windows I tried to use
> > > Lisp code.  But each Lisp is doing them differently (and
> > > apparently some operations sometimes are missing). So I got
> > > a maze of conditionals over Lisp implementations. Looking at
> > > resulting code I feel that it is better to call operationg
> > > system utilities and have just use conditionals to choose
> > > between Unix and Windows versions of file utilities.
> > 
> > I hope you mean calling the operating system routines directly
> > (e.g. SI:: in GCL) and not resorting to spawning a new process
> > to run shell commands (e.g. as is done one in Axiom's OBEY).
> 

I mean spawning processes.  I know that Windows does not like this,
but is it really that bad?  As alternative I consider rolling
our own C library -- it seems that _no_ Lisp implementation
give direct access to system calls.

<rant>  People frequently wonder why Perl is more popular than Lisp.
Already 15 years ago Perl allowed you to call the 'syscall' system
call -- which means that if Perl missed some OS function (it supported
a _lot_ of them out of the box) one could roll Perl code to
work around the problem.
</rant>

> Waldek, could you release the conditionalized Lisp code in question
> even if we decide not to use it?  It would make an EXCELLENT argument
> and case study for making some of these interfaces more uniform between
> implementations.
>  
> > > Concerning sockets, we need Unix domain sockets and select.
> > > It seems that clisp provide both, but to get Unix domain
> > > sockets one needs version including rawsock module, which
> > > is not included in default clisp configuration.  
> > > 
> > > sbcl offers sb-bsd-sockets which seem to have basic
> > > functions, but I do not see select.
> > > 
> > > gcl documentation suggest that Unix domain sockets are
> > > unsupported. Also, I see no traces of select.
> > > 
> > > There is "portable" cl-sockets library but the manual says
> > > it supports Allegro CL, sbcl and cmucl.  The manual does not
> > > say anything about Unix domain sockets or select.  The manual
> > > says that cl-sockets requires UFFI, so presumably cl-sockets
> > > works on top of "portable" C library.
> 
> Does http://common-lisp.net/project/usocket/ address this problem at
> all?  I don't expect any of these solutions will support GCL at this
> time, but hopefully that will come.
>

I did not investigate deeply, but the web page does not mention
Unix domain sockects or select...  They clearly say that UDP is
is not ready, and mention a lot of little details about things
alredy done, so they probably even have no plans for Unix domain.
 
> P.S. - Waldek, is there a trick to building with sbcl?  I get 
> make[2]: *** No rule to make target `sbcl', needed by `do_it.sbcl'. 
> Stop.
> Sorry if I'm missing something obvious.
> 

configure --with-lisp=/full/path/to/sbcl

Current SVN should not require this.  There is good chance that
sbcl from current SVN will bootstrap algebra, but I still have to
commit many fixes.

\start
Date: Tue, 22 May 2007 04:24:10 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey, Alasdair McAndrew
Subject: re: TeXmacs+Axiom

--- Martin Rubey wrote:

> Unfortunately, I guess that a good emacs mode for .input files
> would be the most important thing for axiom *users*.  In particular,
> it would be good to have a possibility to send a function definition
> to a running axiom, via shift return or something.  But that's
> probably not so easy.

I think it's doable - EMaxima has something similar, IIRC.  My original
focus was a pseudo-notebook environment, so I don't think I got to any
of the .input stuff.
 
> Cliff, I found the emacs mode documentation very hard to read.  Is
> there a small tutorial, and a summary of the available emacs
> commands?

Hmm.  Sorry about that.  There is a flash movie of an example editing
session here, although without audio or commands shown:

http://wiki.axiom-developer.org/axiomemacsswf.html

Here's the two cent tour:

You can start the mode with M-x axiom-mode or (my favorite because I
can stick it in a fluxbox menu) emacs -f axiom-mode.  This should start
up something like the following:

GCL (GNU Common Lisp)  2.6.8 ANSI    Apr 23 2007 08:44:17
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL 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 wh-sandbox branch 2006-03-28
                Timestamp: Monday April 23, 2007 at 08:54:19 
-----------------------------------------------------------------------------
   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) ->

Once you have that input prompt, it should act pretty much like the
command line:

(1) -> sin(x) 

   (1)  sin(x)
                                                     Type: Expression
Integer
(2) -> cos(x) 

   (2)  cos(x)
                                                     Type: Expression
Integer
(3) -> tan(x) 

   (3)  tan(x)
                                                     Type: Expression
Integer
(4) ->
 
The only benefits at the moment are:

* Navigation with arrow keys and input status reporting.  Let's say we
want to go back and change cox(x) above to an integral.  Pressing the
up arrow twice from (4) will jump the input cursor straight to (2).  As
we begin to edit the line (which, once edited, no longer corresponds to
the output displayed below it) it turns red.  (Can't show that in an
email.)  Once the new expression is complete and we evaluate it, the
Emacs mode will handle putting the new output in place of the old one. 
The standard input prompt at the end is also updated to reflect the
current status.  This is handy if you want your commands to show a
progression, say in working a problem.

(1) -> sin(x) 

   (1)  sin(x)
                                                     Type: Expression
Integer
(4) -> integrate(1/(1+x^5),x) 

   (4)
            +------------------------------------------------------+
            |        2                               2
           \|- 75%%F1  + (- 50%%F0 - 10)%%F1 - 75%%F0  - 10%%F0 - 3  -
5%%F1
         + 
           - 5%%F0 - 1
      *
         log
               +------------------------------------------------------+
               |        2                               2
              \|- 75%%F1  + (- 50%%F0 - 10)%%F1 - 75%%F0  - 10%%F0 - 3 
- 5%%F1
            + 
              - 5%%F0 + 2x - 1
     + 
              +------------------------------------------------------+
              |        2                               2
           - \|- 75%%F1  + (- 50%%F0 - 10)%%F1 - 75%%F0  - 10%%F0 - 3 
- 5%%F1
         + 
           - 5%%F0 - 1
      *
         log
                
+------------------------------------------------------+
                 |        2                               2
              - \|- 75%%F1  + (- 50%%F0 - 10)%%F1 - 75%%F0  - 10%%F0 -
3
            + 
              - 5%%F1 - 5%%F0 + 2x - 1
     + 
       10%%F1 log(5%%F1 + x) + 10%%F0 log(5%%F0 + x) + 2log(x + 1)
  /
     10
                                          Type: Union(Expression
Integer,...)
(3) -> tan(x) 

   (3)  tan(x)
                                                     Type: Expression
Integer
(5) -> 

Copying Input-Output Cell combinations

Because Axiom mode in Emacs write protects it's output cells to avoid
accidental deletion, (you can override the auto-line positioning of the
up and down arrow keys with Alt-Up and Alt-Down, but it's awkward)
there's a convenience key binding C-a c to copy the input-output
combination where the cursor is positioned, or the previous complete
cell if the cursor is on the input-only line at the bottom.

Command History

Thanks to Emacs terminal mode, at each input line you can cycle through
previous commands with Alt-p and forward with Alt-n (Ctrl-Up and
Ctrl-Down also work for me here).

Right now, that's pretty much it.

It's pretty incomplete, unfortunately :-(.

\start
Date: Tue, 22 May 2007 07:44:10 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Live CD + Guess Package + Vmware

On May 22, 2007 12:53 AM Alfredo Portes wrote:
> ... 
> With VPC 2007, Doyen boots fine. The only problem is the video
> card the virtual machine emulates. The CD finds that is S3 and
> it uses the S3 driver which apparently is not a good friend of
> VPC. :-).
> 
> Opening a terminal, changing in /etc/X11/xorg.conf from "s3" to
> "vesa" and restaring X, fixes the problem.
> 

Great. I'll try that. Thank you!

\start
Date: 22 May 2007 13:45:46 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: axiom-mode

Cliff Yapp writes:

> Here's the two cent tour:

Oh, that was great!  It's not really what I'm used to, but maybe it could
accomodate the behaviour I like, to.Currently, I use emacs shell mode.  Here
goes:

* at times, I like to edit output.  For example, I like to mark some parts of
  the output with a different font, so that I can more easily focus my
  attention.  Sometimes I also rearange things a little.  Is this possible with
  your mode?  You write:

> Copying Input-Output Cell combinations
> 
> Because Axiom mode in Emacs write protects it's output cells to avoid
> accidental deletion, (you can override the auto-line positioning of the up
> and down arrow keys with Alt-Up and Alt-Down, but it's awkward) there's a
> convenience key binding C-a c to copy the input-output combination where the
> cursor is positioned, or the previous complete cell if the cursor is on the
> input-only line at the bottom.

  so it sounds as though the answer is rather "no".  But I must admit I do not
  understand what C-a c does, neither M-up and M-down.  Does C-a c copy the
  input-output combination into the kill ring?  Maybe it would be possible to
  have a simple "magic-key-combination" that allows editing of output?  Or,
  maybe even better: that turns the cursor into a brush and marks the character
  under point blue if I hit space?  (That would be really useful for me!)  To
  actually edit output, copying it into a separate buffer may be the wiser
  choice anyway.

* I'd really like to have an easy way to send definitions etc. from one buffer
  (containing a .input file) to an axiom process.  There are two (small)
  problems with that:

  1) I think it's difficult to detect where a function definition starts and
     where it ends.  The MuPAD people told me that the would simple mark the
     definition boundaries themselves with some special characters.  I think,
     that's quite wise.  Maybe -- << and -- @ would make sense?  (They should
     be acceptable as comments, since I will often want to )read the input
     file, too.  Another shortcut that sends only the current line, and
     possible a third shortcut that sends the current region would also be
     good.

  2) When you try to yank a definition into the axiom buffer, you'll be
     disappointed, because the axiom interpreter doesn't seem to like multiline
     input, does he?  So, maybe you would need to save the input which should
     be sent to axiom into a temporary file and )read it.

In any case, I'll give it a try.  Many thanks,

\start
Date: Tue, 22 May 2007 13:49:35 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: TeXmacs+Axiom

> What concerns programming, since I prefer Aldor to SPAD, I am quite
> happy with Ralf's (? I think) aldor.el mode, which comes bundled
> with ALLPROSE.

The aldor mode can also be used without ALLPROSE. Just download the 
literate program from

http://www.risc.uni-linz.ac.at/people/hemmecke/aldor/allprose

and improve if you find something that you don't like.

Note that I have switched off the filladapt mode for two reasons. It did 
not always work as I wanted and I don't need it in ALLPROSE because 
there one writes

\begin{+++}
Documentation of the API in LaTeX.
\end{+++}

instead of the +++ in front of every line.

Ralf

> For spad.pamphlet (i.e., LaTeX) editing, mmm mode is a wonderful
> thing.  If you install ALLPROSE, you'll have all these things
> automatically set up, I think that's the easiest way to do it.
> Martin

Thank you Martin for advertisment. ;-)

\start
Date: Tue, 22 May 2007 13:56:24 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: TeXmacs+Axiom
Cc: Alasdair McAndrew

On 05/22/2007 11:14 AM, Martin Rubey wrote:
> Ralf Hemmecke writes:
> 
>> I tried to put it at /usr/lib/texmacs/TeXmacs/bin/tm_axiom .
>>
>> Well, at least I don't see strange output. I can enter Axiom commands and I
>> see... *nothing*. No output at all, only the input that I type is all that I
>> see.

> When you start the gcc'd (modified) tm_axiom.c directly, does it start
> HyperDoc?

I took your tm_axiom.c, compiled it and moved the result to
/usr/lib/texmacs/TeXmacs/bin/tm_axiom .

Hyperdoc pops up, but if I type 1+2 and press ENTER, I get no output on 
the console.

> Try also to start it in a directory that does not contain an ".axiom.input".
>  
>> woodpecker:~>cat axiom.input
>> )set output tex on
>> )set output algebra off
>> )set compiler args -Fasy -Fao -flsp -laxiom -DAxiom -Y
>> $AXIOM/../../share/algebra -v -O
> 
> does your version of axiom read axiom.input or .axiom.input at startup?  (Mine
> reads .axiom.input)

I don't actually know whether Axiom reads the file with our without 
initial dot. I only know that it was changed from one to the other 
sometime. If have to look it up. But anyway, I tried both options and 
none gives console output, except

woodpecker:~>/usr/lib/texmacs/TeXmacs/bin/tm_axiom
verbatim:channel:promptlatex:\red$\rightarrow$\ verbatim:1+2
channel:promptlatex:\red$\rightarrow$\ verbatim:4
channel:promptlatex:\red$\rightarrow$\ verbatim:

\start
Date: 22 May 2007 13:58:12 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: re: axiom-mode

OK, I tried it.  I really love C-a c. That's superb!

Some minor problems:

1. after evaluation, point is positioned within the prompt, like indicated with
the arrow:

(6) -> asdasd 

   (6)  asdasd
                                                        Type: Variable asdasd
(7) -> 
  ^
  |
i.e., at the closing parenthesis, instead after the -> sign, also if the input
number has two digits.

2. C-h m only shows the comint mode help page.

3. how can I start a second axiom process?

Still, it looks like great stuff!  Do you think you could add that painting
idea and/or sending input to the axiom process?

\start
Date: 22 May 2007 14:07:57 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: TeXmacs+Axiom
Cc: Alasdair McAndrew

Ralf Hemmecke writes:

> On 05/22/2007 11:14 AM, Martin Rubey wrote:
> I took your tm_axiom.c, compiled it and moved the result to
> /usr/lib/texmacs/TeXmacs/bin/tm_axiom .
> 
> Hyperdoc pops up, but if I type 1+2 and press ENTER, I get no output on the
> console.

I'm sorry, but I don't have any idea anymore.

\start
Date: 22 May 2007 07:45:16 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Lisp portability

Waldek Hebisch writes:

[...]

| In short my finding is that portable Lisp sockets are a myth: all
| implementations provide different interface and frequently miss
| some essential services.  People who want portablity between Lisp
| implementations interface to C. 

You know what they say: Lisp is the only language that does not have a
plural :-)

| 
| Given that it seems that most reasonable way for Axiom is to use
| existiong C code.  There is are drawbacks: we need to interface to
| C and typical Lisp implementation can only interface to shared
| libraries via dlopen.  So we need to handle issues related to making
| shared library.

We need this anyway because we want people to interface their C
libraries with Axiom.

| But AFAICS we will need C interface anyway, so we need to resolve
| problems of C interface and shared libraries.

Yes, I fully agree.

\start
Date: 22 May 2007 07:54:17 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Lisp portability
Cc: Camm Maguire

Waldek Hebisch writes:

| CY wrote:
| > --- Bill Page wrote:
| > 
| > > On May 21, 2007 10:55 PM Waldek Hebisch wrote:
| > > > ...
| > > > currently for clisp I need cl-fad library, which I consider
| > > > problematic.  Namely, cl-fad does not work with gcl, so for
| > > > gcl we need separate code.
| > > 
| > > In general Camm Maguire (the primary developer go GCL) has
| > > expressed strong interest in improving GCL's support for
| > > ANSI common Lisp. If solving the problems of cl-fad on GCL
| > > would further this goal, I expect that we could count on
| > > his help (time available of course not withstanding).
| > 
| > I think we need to worry first about ANSI Lisp support and second about
| > continuing to work on GCL.  GCL is targeting ANSI, so eventually it
| > should be a moot point anyway, and in the meantime I would suggest we
| > target the final platform rather than worry about working on
| > intermediate or outdated Lisp environments.
| >  
| 
| 1) I need GCL support for regression testing.

It would be foolish to drop support for GCL, because of supposed ANSI
Lisp stuff.  In the end, Axim users don't care about ANSI Lisp stuff.
For them, Axiom is useless if it is beautifully ANSI Lisp compliant
but cannot run.  ANSI Lisp is primarily a relief for us implementers.
Lisp is no more than an assembly language for Axiom.  

| 2) I hope that Aldor lesson should be clear: avoid waiting on third
|    party, this may take long time.  In GCL case we may count on
|    goodwill of Camm, but still I do not think taht we should
|    cut off our life support and hope that it will be restored 
|    on time.

I tend to agree.  We must be careful in not loading too much the
boat.  You have continuous complain from "beniners" the entry barrier
to Axiom.  We must be careful.  Set a long term goal, and work a
smooth path way to it.  Don't foolishly believe that the world will
change overnight.

| 3) ATM core of Axiom is written in a very small subset of Lisp,
|    sitting in the intersection of Cltl and Ansi.  We need conditionals
|    for things going beyond Ansi or Ansi violations.  Directly
|    here GCL is just one more implementation.  Indirectly, we can
|    not use some Ansi features.  IMHO _that_ can wait for Ansi
|    GCL.

Agreed.

[...]

| <rant>  People frequently wonder why Perl is more popular than Lisp.

Oh, I thought it was Python :-) :-)

\start
Date: Tue, 22 May 2007 09:26:16 -0400
From: Bill Page
To: Gabriel Dos Reis, Waldek Hebisch
Subject: RE: Lisp portability
Cc: Camm Maguire

On May 22, 2007 8:54 AM Gabriel Dos Reis wrote:
> ...
> Waldek wrote: 
> | <rant>  People frequently wonder why Perl is more popular
> | than Lisp.
> 
> Oh, I thought it was Python :-) :-)
> 

People (ambiguous third parties...) often wonder why Python
is more popular than Perl ... ;)

More seriously, this issue of Lisp (non)portability is a
major problem. I can not believe that there are/were people
on this email list that touted the portablity of Lisp as
a reason for downgrading Axiom code to that level!

\start
Date: Tue, 22 May 2007 06:34:16 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey
Subject: Re: axiom-mode
Cc: list

--- Martin Rubey wrote:

> Cliff Yapp writes:
> 
> > Here's the two cent tour:
> 
> Oh, that was great!  It's not really what I'm used to, but maybe it
> could accomodate the behaviour I like, to.Currently, I use emacs
> shell mode.  Here goes:

It was sort of a "notebook in textmode" as far as concept went.
 
> * at times, I like to edit output.  For example, I like to mark some
> parts of
>   the output with a different font, so that I can more easily focus
> my
>   attention.  Sometimes I also rearange things a little.  Is this
> possible with
>   your mode?  You write:

No, editing output in-notebook isn't possible currently. If one wants
to do that the output can be copied to another buffer, but in the Axiom
session itself I wanted to ensure the integrity of the output as much
as I could (and prevent stupid accidental deleting if I stuck the
cursor in the wrong place with the mouse...)

> so it sounds as though the answer is rather "no".  But I must admit
> I do not understand what C-a c does, neither M-up and M-down.  Does
> C-a c copy the input-output combination into the kill ring?

I think that's right - I'm not sure where it stuck it but that rings a
bell.

> Maybe it would be possible to have a simple "magic-key-combination"
> that allows editing of output?  Or, maybe even better: that turns
> the cursor into a brush and marks the character under point blue if
> I hit space?  (That would be really useful for me!)

It's a good idea, but I'm not quite sure what Emacs lets you get away
with for things like that.  Certain it can be looked into.

>  To actually edit output, copying it into a separate buffer may be
> the wiser choice anyway.

That was my feeling, but selective color changing/highlighting doesn't
change the output and still lets you direct the eye - I like it.

> * I'd really like to have an easy way to send definitions etc. from
> one buffer (containing a .input file) to an axiom process.  There
> are two (small) problems with that:
> 
>   1) I think it's difficult to detect where a function definition
> starts and where it ends.  The MuPAD people told me that the would
> simple mark the definition boundaries themselves with some special
> characters.  I think, that's quite wise.  Maybe -- << and -- @ would
> make sense? (They should be acceptable as comments, since I will
> often want to )read the input file, too.  Another shortcut that
> sends only the current line, and possible a third shortcut that
> sends the current region would also be good.

The line and region I like, but as you note trying to automatically
identify the function is tough.  Lisp can get away with it thanks to
the parenthesis, IIRC, but for other languages it's a problem.  I'm not
real keen on the special characters but if there's great demand for it
I suppose it could be done.
 
>   2) When you try to yank a definition into the axiom buffer, you'll
> be disappointed, because the axiom interpreter doesn't seem to like
> multiline input, does he?  So, maybe you would need to save the input
> which should be sent to axiom into a temporary file and )read it.

I think that came up last time, and the only workable solution was
something like that.  (Yuck.)

I'm not really that crazy about Emacs based on my experiences to date
with it, but I will admit I don't know of anything better for this kind
of work.

The pamphlet file is in pretty sad shape, so I guess that needs to be
fixed, but I was under the impression there was very little interest in
going further with this work and it did what I needed ;-).  That can be
revisited if we want to do more with it.

\start
Date: Tue, 22 May 2007 06:39:43 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey
Subject: re: axiom-mode

--- Martin Rubey wrote:

> OK, I tried it.  I really love C-a c. That's superb!

Thanks :-).
 
> Some minor problems:
> 
> 1. after evaluation, point is positioned within the prompt, like
> indicated with
> the arrow:
> 
> (6) -> asdasd 
> 
>    (6)  asdasd
>                                                         Type:
> Variable asdasd
> (7) -> 
>   ^
>   |
> i.e., at the closing parenthesis, instead after the -> sign, also if
> the input number has two digits.

Darn it, I thought I had that working.  Just so I know, what platform
and version of emacs are you using?
 
> 2. C-h m only shows the comint mode help page.

Right - at the moment there is no help mode for this.  (I'm not even
sure how to create one.)  Worth adding though.

> 3. how can I start a second axiom process?

I'm not sure if I added support for multiple instances of Axiom - that
may have a few twists to it.

> Still, it looks like great stuff!  Do you think you could add that
> painting idea and/or sending input to the axiom process?

I'll take a look at it, but it's been quite a while and I'm going to be
a little short on time. Plus, I am not really very good at Emacs so
it's likely I'm doing a lot of this the Wrong Way :-(.  Are there any
Emacs gurus on the list who would be interested enough to take over the
project?

\start
Date: Tue, 22 May 2007 08:43:49 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: Lisp portability
Cc: Camm Maguire

On Tue, 22 May 2007, Bill Page wrote:

| On May 22, 2007 8:54 AM Gabriel Dos Reis wrote:
| > ...
| > Waldek wrote: 
| > | <rant>  People frequently wonder why Perl is more popular
| > | than Lisp.
| > 
| > Oh, I thought it was Python :-) :-)
| > 
| 
| People (ambiguous third parties...) often wonder why Python
| is more popular than Perl ... ;)

:-) [ Gaby a long term JAPH]


| More seriously, this issue of Lisp (non)portability is a
| major problem. I can not believe that there are/were people
| on this email list that touted the portablity of Lisp as
| a reason for downgrading Axiom code to that level!

I've spent a significant amount of time/resources on the Lisp portability
issues in Axiom; I'm glad and sad to see Waldek had similar conclusions.
If you restrict your world sufficiently enough and you don't care about the
structure of the code you're working on, its maintainability, and the general 
question of Axiom users, Lisp is not a problem.

\start
Date: Tue, 22 May 2007 08:44:46 -0500
From: Jay Belanger
To: list
Subject: Re: Lisp portability

Bill Page writes:
> On May 22, 2007 8:54 AM Gabriel Dos Reis wrote:
>> ...
>> Waldek wrote:
>> | <rant>  People frequently wonder why Perl is more popular
>> | than Lisp.
>>
>> Oh, I thought it was Python :-) :-)
>>
>
> People (ambiguous third parties...) often wonder why Python
> is more popular than Perl ... ;)
>
> More seriously, this issue of Lisp (non)portability is a
> major problem.

As far as I can tell, this is an odd place to mention portability of
Lisp.  The rant above was about Lisp's non-ability to use system
calls, while Perl has that ability.  Wouldn't systems calls in a piece
of code tend to make it non-portable?  

\start
Date: 22 May 2007 08:51:35 -0500
From: Gabriel Dos Reis
To: Jay Belanger
Subject: Re: Lisp portability

Jay Belanger writes:

| Bill Page writes:
| > On May 22, 2007 8:54 AM Gabriel Dos Reis wrote:
| >> ...
| >> Waldek wrote:
| >> | <rant>  People frequently wonder why Perl is more popular
| >> | than Lisp.
| >>
| >> Oh, I thought it was Python :-) :-)
| >>
| >
| > People (ambiguous third parties...) often wonder why Python
| > is more popular than Perl ... ;)
| >
| > More seriously, this issue of Lisp (non)portability is a
| > major problem.
| 
| As far as I can tell, this is an odd place to mention portability of
| Lisp.  The rant above was about Lisp's non-ability to use system
| calls, while Perl has that ability.  Wouldn't systems calls in a piece
| of code tend to make it non-portable?  

The point was more subttle than that.

\start
Date: Tue, 22 May 2007 07:41:27 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Gabriel Dos Reis, Waldek Hebisch
Subject: RE: Lisp portability
Cc: Camm Maguire

--- Bill Page wrote:

> More seriously, this issue of Lisp (non)portability is a
> major problem. I can not believe that there are/were people
> on this email list that touted the portablity of Lisp as
> a reason for downgrading Axiom code to that level!

As I understand it, sockets of various types are the major problem
currently? Unix domain sockets and select are not something I know much
about, so I have some background reading to do.

writeablep functions I'm also not familiar with.

Waldek, do I understand correctly that these socket connections are
used for the axiom terminal interface, the graphics, and the hyperdoc
system?  My (limited) understanding of how Maxima handled communication
with interfaces like xmaxima was that it used tcp sockets, sort of a
pseudo-webserver/web-browser type connection.  (Many use more primative
means, unfortunately...)  Can you recommend a good introduction into
the various types of sockets/select?

\start
Date: Tue, 22 May 2007 09:51:53 -0500
From: Jay Belanger
To: list
Subject: Re: Lisp portability

Gabriel Dos Reis writes:
...
> The point was more subttle than that.

Thanks; that's helpful.

\start
Date: Tue, 22 May 2007 08:26:06 -0700 (PDT)
From: Cliff Yapp
To: Jay Belanger
Subject: Re: Lisp portability

If I understand correctly, the issue is that various Lisp
implementations do not provide either a common interface to operating
system functionality, or a good way to provide those features if not
already present.

This is pretty hard to argue against, but unfortunately getting free
lisp implementations to agree to do something all the same way is
usually an uphill battle.  Sometimes this actually is because they have
different ideas about how to do things, but the INTERFACE level (api,
exported function names, whatever) I think can and should be much more
uniform.

An additional difficulty is that lisp programmers tend to solve
problems for themselves, and often times view these solutions in much
the same way most programmers might view a shell script written to do
some mundane job - "that was easy enough for anyone to do that it's not
worth turning into a library".  This leads to situations where many
individual developers have their own preferred solutions to problems
and (understandably) are not interested in standardizing on a different
way.  ASDF seems to run into this sometimes, with the instructions
being to customize ASDF for a particular situation rather than adding
the solution to the problem to ASDF proper.  Personally I doubt most
such problems are sufficiently unique to justify a one-off not being
folded back into the main asdf system, but apparently it's up for
debate.

My long term thought on this (I'll go ahead and admit I'm nuts to save
everyone the trouble of pointing it out) is to slowly convert the best
of the tools we use into literate documents and create the supporting
platform we need.  I'm slowly attempting to turn asdf.lisp into a
pamphlet file (figuring it out will be a learning experience) and even
if the asdf devs want nothing to do with it improvements can be added,
documented, etc. by us as work is done.  Eventually I would like to do
this with sbcl itself, cl-pdf, cl-typesetting, McCLIM, CLX, etc.  I
know that's probably an impossible goal, but it's proving (for me at
least) to be a good way to learn about a particular subject and may tie
in with Tim's long term vision.

Cheers,
CY

P.S.  Jay, would you be interested in pushing EAxiom forward some more?
 I never did get as far as the LaTeX parts of the original code you
developed but if there is more interest again it could motivate me to
push ahead.  Did EAxiom match how you were wanting to interact with
Axiom or are existing solutions sufficient?

--- Jay Belanger wrote:

> 
> Gabriel Dos Reis writes:
> ...
> > The point was more subttle than that.
> 
> Thanks; that's helpful.

\start
Date: Tue, 22 May 2007 10:32:23 -0500
From: Tim Daly
To: list
Subject: lisp portability

This code has moved from MAClisp and VMLisp to several "evolving"
lisps and eventually to several "iterations" of CLtL1 common lisp
as it was evolving. Even when the lisps changed from single to
dual function namespaces (a deep semantic difference) it was not
unreasonably hard. 

Certainly the task is much easier than moving from linux to windows.

The distance from CLtL1 to ANSI is trivially small.
The actual estimated lisp work effort is about a man-week, maybe two.
It is a classroom exercise, not worth a "summer of code" project.

The only difficult part is a minor extension to GCL for sockets.
But since there are websites that are run from lisp this must work.

For a 35 year old program in a 50 year old language that seems 
reasonably portable to me.

If the task seems hard to you then I suspect the issue has more
to do with your understanding of lisp than a language flaw.

t
"A poor workman blames his tools"

\start
Date: Tue, 22 May 2007 10:33:40 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: RE: Lisp portability
Cc: Camm Maguire

On Tue, 22 May 2007, C Y wrote:

| writeablep functions I'm also not familiar with.

This is a function Axiom implements as a C library function
(src/lib/cfuns-c.c) to determine the write access property of a file.  
I think I've documented that.

[...]

| Waldek, do I understand correctly that these socket connections are
| used for the axiom terminal interface, the graphics, and the hyperdoc
| system?  My (limited) understanding of how Maxima handled communication
| with interfaces like xmaxima was that it used tcp sockets, sort of a
| pseudo-webserver/web-browser type connection.  (Many use more primative
| means, unfortunately...)  Can you recommend a good introduction into
| the various types of sockets/select?

In the file cfuns-c.c I mentioned above, I've put a reference material on the
topic.  See the comment above the axiom_has_write_access function.

\start
Date: 22 May 2007 10:36:41 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: CHANGELOG

Tim Daly writes:

| The choice of person marked for changes was made based on which branch
| I diff-ed first.

the order in which you diff-ed should have nothing to do with that.

\start
Date: Tue, 22 May 2007 10:57:48 -0500
From: Tim Daly
To: list
Subject: CHANGELOG

> the order in which you diff-ed should have nothing to do with that.

true. but it did. when i get a chance i'll fix it, per your request.

\start
Date: 22 May 2007 11:20:31 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: lisp portability

Tim Daly writes:

| This code has moved from MAClisp and VMLisp to several "evolving"
| lisps and eventually to several "iterations" of CLtL1 common lisp
| as it was evolving. Even when the lisps changed from single to
| dual function namespaces (a deep semantic difference) it was not
| unreasonably hard. 
| 
| Certainly the task is much easier than moving from linux to windows.


The actual problem several of us have been running into and are
pointing out are not that we are moving a pre-ANSI Lisp program to an
ANIS Lisp program.  The the problem is that of the *variabilities* of
existing ANSI Lisp implementations, the insufficient portability made
by ANSI Lisp, etc.

FWIW I've  helped converted large non-trivial programs (e.g.) from K&R C
(actually dialects of K&R C) to ISO C.  I've also been helping 
the existing GCC's ISO C soure base to be *compilable* with ISO C++.
The task is non-trivial, but OK.  Because there are *usefully usable*
C and C++ standards.

[...]

| "A poor workman blames his tools"

How do you qualify the one who refuses to listen and understand what
people are reporting as the problem?

\start
Date: 22 May 2007 18:45:53 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: re: axiom-mode

Cliff Yapp writes:

> > Variable asdasd
> > (7) -> 
> >   ^
> >   |
> > i.e., at the closing parenthesis, instead after the -> sign, also if
> > the input number has two digits.
> 
> Darn it, I thought I had that working.  Just so I know, what platform
> and version of emacs are you using?

I have Kubuntu Dapper (i.e., a debian variant), emacs 21.4.1, axiom wh-sandbox
(very recent)

> Are there any Emacs gurus on the list who would be interested enough to take
> over the project?

Cliff, I think it would be best if you start hacking!  Most likely, emacs
people will be able to help, but there are simply too few axiom people around!

> > Maybe it would be possible to have a simple "magic-key-combination"
> > that allows editing of output?  Or, maybe even better: that turns
> > the cursor into a brush and marks the character under point blue if
> > I hit space?  (That would be really useful for me!)
> 
> It's a good idea, but I'm not quite sure what Emacs lets you get away
> with for things like that.  Certain it can be looked into.

> >  To actually edit output, copying it into a separate buffer may be the
> > wiser choice anyway.
> 
> That was my feeling, but selective color changing/highlighting doesn't change
> the output and still lets you direct the eye - I like it.

Just another idea: M-up could get you into output "mode", and in that "mode",
some ordinary keys have a different meaning: b for blue foreground, B for blue
background, g for green, r for red, space for black, etc.  That would really be
a killer app!  None of the current interfaces for maple, mathematica, mupad,
etc. is able to do that!  I beg you to look at it!

> It was sort of a "notebook in textmode" as far as concept went.

I think you shouldn't go further with the notebook idea.  It's cute that
invalid input turns red (unfortunately undo (M-_) doesn't turn it black
anymore), but I'd really leave it at that.

> > * I'd really like to have an easy way to send definitions etc. from one
> > buffer (containing a .input file) to an axiom process.  [...]
> > 
> >   1) I think it's difficult to detect where a function definition starts
> > and where it ends.  The MuPAD people told me that the would simple mark the
> > definition boundaries themselves with some special characters.  [...]

> > Another shortcut that sends only the current line, and possible a third
> > shortcut that sends the current region would also be good.
> 
> The line and region I like, but as you note trying to automatically identify
> the function is tough.

Forget about automatically determining boundaries.  And for the moment, region
and line would be just wonderful.
  
> > [...]  maybe you would need to save the input which should be sent to axiom
> > into a temporary file and )read it.
> 
> I think that came up last time, and the only workable solution was something
> like that.  (Yuck.)

Well, just get over it :-) Don't try to make it perfect! Yes it should work,
but for the moment, it's more important to make life with axiom more comfy.

> I'm not really that crazy about Emacs based on my experiences to date
> with it, 

but I am!  Only, I think my abilities would be rather badly employed by trying
to mess with emacs modes.

\start
Date: Tue, 22 May 2007 18:57:03 +0200 (CEST)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: lisp portability

> The distance from CLtL1 to ANSI is trivially small.
> The actual estimated lisp work effort is about a man-week, maybe two.
> It is a classroom exercise, not worth a "summer of code" project.
> 
> The only difficult part is a minor extension to GCL for sockets.
> But since there are websites that are run from lisp this must work.
>

Tim, did you read what I wrote: core Axiom works with Ansi Lisps.
It took me probably slightly more than two man-weeks and you should
add to that time spent by Jurgen Weiss, Greg Vanuxiem, Gaby and
possibly others.  What I am talking about is "minor extension for
sockets" and file operations.  There were proposals to do this
in pure Lisp.  My conclusion is that the way to go (at least in
short term) is to keep C parts.
 
> If the task seems hard to you then I suspect the issue has more
> to do with your understanding of lisp than a language flaw.
> 
> t
> "A poor workman blames his tools"
> 

Good workman knows which tool to use to solve problem.

\start
Date: 22 May 2007 19:10:28 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: re: axiom-mode

just another detail: C-a c is a really bad choice for putting input and output
to the kill ring, since it conflicts with C-a (beginning of line).

I suggest to use M-k:

M-k runs the command kill-sentence
   which is an interactive compiled Lisp function in `textmodes/paragraphs'.
(kill-sentence &optional ARG)

Kill from point to end of sentence.
With arg, repeat; negative arg -N means kill back to Nth start of sentence.

(an input output block could be seen as a "sentence", don't you think?)

\start
Date: Tue, 22 May 2007 10:20:50 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey
Subject: re: axiom-mode

--- Martin Rubey wrote:

> > Are there any Emacs gurus on the list who would be interested
> > enough to take over the project?
> 
> Cliff, I think it would be best if you start hacking!  Most likely,
> emacs people will be able to help, but there are simply too few
> axiom people around!

Ugh.  OK, I'll take a look at it.  (Hurry up Climacs...)

> Just another idea: M-up could get you into output "mode", and in that
> "mode", some ordinary keys have a different meaning: b for blue 
> foreground, B for blue background, g for green, r for red, space for
> black, etc.  That would really be a killer app!  None of the current
> interfaces for maple, mathematica, mupad, etc. is able to do that! 
> I beg you to look at it!

I'll check - Jay, does Emacs allow that kind of dynamic, context
sensitive key binding?  I MIGHT be able to put together some sort of
hack but an Emacs supplied mechanism would be better.
 
> > It was sort of a "notebook in textmode" as far as concept went.
> 
> I think you shouldn't go further with the notebook idea.  It's cute
> that invalid input turns red (unfortunately undo (M-_) doesn't turn
> it black anymore), but I'd really leave it at that.

Actually, I might get the undo binding to turn it black.  Good point. 
I don't view the turning red on alteration of input as trivial - it
avoids the situation where someone was going to make a change, forgets
to evaluate it, and then prints something that appears to show
incorrect output.  As for the "notebook", I have always been frustrated
with accidental "wiping out" of input prompts and other structures that
users shouldn't be editing.  I think, give or take the bugs, I am
content to leave it pretty much where it is (your output marking
feature I can take a stab at) and move on to the more advanced LaTeX
based features.

> Forget about automatically determining boundaries.  And for the
> moment, region and line would be just wonderful.

OK, I think EMaxima provides an example of that.
   
> Well, just get over it :-) Don't try to make it perfect! Yes it
> should work, but for the moment, it's more important to make life
> with axiom more comfy.

I suppose.  Since my idea for Doing It Right doesn't involve Emacs
anyway I suppose being pragmatic wouldn't hurt...

> > I'm not really that crazy about Emacs based on my experiences to
> > date with it, 
> 
> but I am!  Only, I think my abilities would be rather badly employed
> by trying to mess with emacs modes.

OK, if there is interest I'll take a stab at it.  I take it you are
interested mainly in being able to send lines and highlight output, and
not so much the LaTeX session integration of EMaxima?

\start
Date: Tue, 22 May 2007 10:24:26 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey
Subject: re: axiom-mode

--- Martin Rubey wrote:

> Dear CY,
> 
> just another detail: C-a c is a really bad choice for putting input
> and output to the kill ring, since it conflicts with C-a (beginning
> of line).

The abbreviation was ment to be Control-Axiom, but I should have
guessed that would conflict with something.
 
> I suggest to use M-k:
> 
> M-k runs the command kill-sentence
>    which is an interactive compiled Lisp function in
> `textmodes/paragraphs'.
> (kill-sentence &optional ARG)
> 
> Kill from point to end of sentence.
> With arg, repeat; negative arg -N means kill back to Nth start of
> sentence.
> 
> (an input output block could be seen as a "sentence", don't you
> think?)

Hmm, but if M-k is associated with kill that's probably not a good idea
either, since the operation is a copy and not a removal.  What about
Ctrl-Shift-a to get into Axiom commands?  Does that conflict with
anything?

\start
Date: 22 May 2007 19:47:52 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: re: axiom-mode

Cliff Yapp writes:

> > Just another idea: M-up could get you into output "mode", and in that
> > "mode", some ordinary keys have a different meaning: b for blue 
> > foreground, B for blue background, g for green, r for red, space for
> > black, etc.  That would really be a killer app!  None of the current
> > interfaces for maple, mathematica, mupad, etc. is able to do that! 
> > I beg you to look at it!
> 
> I'll check - Jay, does Emacs allow that kind of dynamic, context
> sensitive key binding?  I MIGHT be able to put together some sort of
> hack but an Emacs supplied mechanism would be better.

Maybe mmm-mode + picture mode is the right thing for that?  I just added the
following to my axiom.el:

(defface axiom-blue-output '((t (:background "red")))
  :group 'axiom)

(defun make-blue ()
  (interactive)
  (let ((over (make-overlay (point) (+ (point) 1) nil nil t)))
    (overlay-put over 'face 'axiom-blue-output)))


* it is awkward to get into the output region. I'd prefer up to move one line
  up, as usual, and M-up to move to the previous input.

* within the output region, only coloring should be possible, but moving around
  and painting should be extremly simple.  The main question is: where does the
  cursor go after a letter has been colored.  I think there are two sensible
  options:

  1) it stays where it is - that's the current setting
  2) we use picture mode

  In any case, I think single-letter keybindings would be wonderful.

* the behaviour of undo should be reconsidered.  I think it shouldn't undo
  anything but editing.  Currently, if I hit undo often enough, it will delete
  the prompt, and output, etc.

> I don't view the turning red on alteration of input as trivial 

No, don't get me wrong: I wanted to say: that's a nice feature, but don't try
to implement cells and stuff like that.


> I think, give or take the bugs, I am content to leave it pretty much where it
> is (your output marking feature I can take a stab at) and move on to the more
> advanced LaTeX based features.

What are "more advanced LaTeX based features"?  Displaying output as typeset
LaTeX?  To be honest, that's completely uninteresting for me.  On the other
hand, I know of others who would like it. (Alasdair mentioned it, a colleague
of mine, too.)

> OK, if there is interest I'll take a stab at it.  I take it you are
> interested mainly in being able to send lines and highlight output, and not
> so much the LaTeX session integration of EMaxima?

\start
Date: Tue, 22 May 2007 12:48:55 -0500
From: Tim Daly
To: Gabriel Dos Reis, Bill Page
Subject: lisp portability

Gaby,

> the *variabilities* of existing lisp implementations

My largest and most painful C++ effort involved moving a program in
"standard" C++ under Microsoft Visual C++ to GCC. The template issue
alone nearly made me insane. Memory leaks, general protection faults,
float-to-double conversions, random APIs, pointer-conversion warnings,
include-file randomness, named pipes, std:: namespace breakage,
library linkage problems, IDE-hooks, "Microsoft standard extensions", 
typedefs of typedefs of typedefs of (void *), object cleanup, argument
initial-value list processing,....

Compared to that effort the CLtL1 and ANSI lisp compliance for various
implementations is hardly a problem. But I admit to being more fluent
in lisp than C++ so it was mostly me. One of my projects (Magnus,
<http://sourceforge.net/projects/magnus>, infinite group theory)
is in C++ and it is no more or less portable than lisp.

The claim that C++ is "standard" is as weak or strong as the claim
that ANSI is standard. No vendor complies 100% because opinions
vary. If you look at the ANSI lisp standard you'll see "comments" and
"unresolved" issues.  I haven't looked at the C++ standard but I'd bet
that the same things exist there.

I authored a fair amount of the axiom common lisp code and I tend to
use a very small subset of the lisp language so most of the code
should move from CLtL1 to ANSI trivially. I suspect that
package-defining issues and file-system issues are the likely
"breakage" points. Most of the likely problem areas already have #+
and #- conditionals due to past portings.

My point is that, yes, the various "ANSI lisps" have variabilities
but these are generally confined to areas where everybody suffers.
SBCL is struggling with raw sockets on Windows because Windows does
sockets different from Unix. Language standards never cover that.

We most likely will need C code for sockets that is platform specific
if we continue to use the current sman code.  An alternative is to use
a portable lisp socket package and recode the graphics/hyperdoc/sman
to use more portable code.

Personally, I'd go with platform-specific C code for now and then think
about a redesign.

> How do you qualify the one who refuses to listen and understand what
> people are reporting as the problem?

Well, I wasn't trying to be personal about it and "qualify the one".
I don't know but you can choose your own labels, I suppose. Did you
see Bill's comment about "the problem"? He said:

  > More seriously, this issue of Lisp (non)portability is a 
  > major problem.

so I'm not sure that you listened to that. 

and Bill,

>    ...I can not believe that there are/were people 
> on this email list that touted the portability of Lisp as
> a reason for downgrading Axiom code to that level!

Clearly insanity and irrationality reigns over some people.
Since GCL generates C code and C is known to be highly portable
(which is why the graphics and hyperdoc were moved to windows first),
we should simply compile the lisp to C, throw away the lisp, and
we're done. :-)

Bill, exactly how much common lisp have you written?
Do you have a significant common lisp program I could look at?
Are you speaking from experience?

Or are you simply trying to make the point that boot is portable
and lisp is not? If this is your point, please try to state it 
without attacking lisp. And please try to explain why file system
handling and socket handling is any more portable in boot.

\start
Date: 22 May 2007 20:12:56 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: re: axiom-mode

Cliff Yapp writes:

> Hmm, but if M-k is associated with kill that's probably not a good idea
> either, since the operation is a copy and not a removal.  What about
> Ctrl-Shift-a to get into Axiom commands?  Does that conflict with anything?

C-A is recognised as C-a on my system, i.e., Ctrl doesn't allow uppercase keys,
same for Meta (i.e., Alt).

If you want to have several "axiom-mode-specific" keybindings, then the usual
prefix is C-c, I think.  But if we only have a very few, I'd suggest to have
simpler keybindings.

As far as I know there is only one emacs command that does copy only, namely
M-w: 

-------------------------------------------------------------------------------
copy-region-as-kill-nomark is an interactive compiled Lisp function in
`pc-select'.  (copy-region-as-kill-nomark BEG END)

Save the region as if killed; but don't kill it; deactivate mark.  If
`interprogram-cut-function' is non-nil, also save the text for a window system
cut and paste.

Deactivating mark is to avoid confusion with delete-selection-mode and
transient-mark-mode.
-------------------------------------------------------------------------------

but since M-w is remains useful, I wouldn't redefine it.

\start
Date: Tue, 22 May 2007 13:49:58 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: lisp portability

On Tue, 22 May 2007, Tim Daly wrote:

| My point is that, yes, the various "ANSI lisps" have variabilities
| but these are generally confined to areas where everybody suffers.

everybody where?

\start
Date: 22 May 2007 20:51:38 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: re: axiom-mode

Martin Rubey writes:

> Cliff Yapp writes:
> 
> > > Just another idea: M-up could get you into output "mode", and in that
> > > "mode", some ordinary keys have a different meaning: b for blue 
> > > foreground, B for blue background, g for green, r for red, space for
> > > black, etc.  That would really be a killer app!  None of the current
> > > interfaces for maple, mathematica, mupad, etc. is able to do that! 
> > > I beg you to look at it!
> > 
> > I'll check - Jay, does Emacs allow that kind of dynamic, context
> > sensitive key binding?  I MIGHT be able to put together some sort of
> > hack but an Emacs supplied mechanism would be better.
> 
> Maybe mmm-mode + picture mode is the right thing for that?  I just added the
> following to my axiom.el:
> 
> (defface axiom-blue-output '((t (:background "red")))
>   :group 'axiom)
> 
> (defun make-blue ()
>   (interactive)
>   (let ((over (make-overlay (point) (+ (point) 1) nil nil t)))
>     (overlay-put over 'face 'axiom-blue-output)))

Another, maybe simpler idea: have a command axiom-set-face which allows the
user to specify a face and make within the output region the up, down, right
and left paint.  Or maybe M-up, M-down, M-right and M-left. Or the same with
C-prefix.  This would render the implementation trivial, probably, and may even
be more useable.

We need cursor combinations for:

* move to previous input line       
* get previous input                C-up / C-down
* move within the input region      left / right
* move within the output region     
* paint within the output region

Thus, maybe:

left/right/up/down:        move ordinarily (i.e., one line)
Shift-left/right/up/down:  paint within output region
Ctrl-up/down               fetch previous/next input
M-up/down                  move to previous / next input.

What do you think?

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

Apart from this, I seem to have a problem with overlays:

(defface axiom-blue-output '((t (:background "blue")))
  ""
  :group 'axiom)
(defface axiom-red-output '((t (:background "red")))
  ""
  :group 'axiom)


(defun make-blue ()
  (interactive)
  (let ((over (make-overlay (point) (+ (point) 1) nil nil t)))
    (overlay-put over 'face 'axiom-blue-output)))

(defun make-red ()
  (interactive)
  (let ((over (make-overlay (point) (+ (point) 1) nil nil t)))
    (overlay-put over 'face 'axiom-red-output)))

It seems that I cannot color something blue that was previously red?

\start
Date: Tue, 22 May 2007 13:52:50 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: lisp portability

On Tue, 22 May 2007, Tim Daly wrote:

| Bill, exactly how much common lisp have you written?

The amount of written Lisp has nothing to do with the porability of ANSI Lisp
features and its usability.

\start
Date: Tue, 22 May 2007 20:52:30 +0200 (CEST)
From: Waldek Hebisch
To: Jay Belanger
Subject: Re: Lisp portability

> 
> Bill Page writes:
> > On May 22, 2007 8:54 AM Gabriel Dos Reis wrote:
> >> ...
> >> Waldek wrote:
> >> | <rant>  People frequently wonder why Perl is more popular
> >> | than Lisp.
> >>
> >> Oh, I thought it was Python :-) :-)
> >>
> >
> > People (ambiguous third parties...) often wonder why Python
> > is more popular than Perl ... ;)
> >
> > More seriously, this issue of Lisp (non)portability is a
> > major problem.
> 
> As far as I can tell, this is an odd place to mention portability of
> Lisp.  The rant above was about Lisp's non-ability to use system
> calls, while Perl has that ability.  Wouldn't systems calls in a piece
> of code tend to make it non-portable?  
> 

The rant is just part of the original post.  Let me re-state
my point more clearly:
1) there is no Lisp socket library which is really portable
   between implementations
2) existing libraries have limited functionality
3) there is little support for writing portable libraries
4) in some implementations there is no way (neither portable
   nor nonportable) to write needed routines in Lisp.
5) differences between operating systems are smaller than
   differences between Lisp implementations

Lack of syscalls is particulary relevant to 3 and 4.  Using
syscalls and sytem dependent conditionals/parametrs you can write
portable library.  Similary ordinary Lisp programs could work
around lack of interface libraries.

Note also context: there were proposals to replace C code 
supporting sockets and called via gcl FFI by pure Lisp solution...

\start
Date: Tue, 22 May 2007 13:55:32 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: lisp portability

On Tue, 22 May 2007, Tim Daly wrote:

| SBCL is struggling with raw sockets on Windows because Windows does
| sockets different from Unix. Language standards never cover that.

You're missing the point.  Even on Unix Lisp implementations fail to agree on
the same set of interface.  The variability there is far greater than what you
get in the C world.  Check out on POSIX.

\start
Date: Tue, 22 May 2007 13:58:14 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: lisp portability

On Tue, 22 May 2007, Tim Daly wrote:

| The claim that C++ is "standard" is as weak or strong as the claim
| that ANSI is standard. No vendor complies 100% because opinions
| vary.

You don't need to have it 100%.  More over, you just don't need a standard;
you need a useful standard.  Those were the points.

| If you look at the ANSI lisp standard you'll see "comments" and
| "unresolved" issues.  I haven't looked at the C++ standard but I'd bet
| that the same things exist there.

There are many; but none that poses similar issues as those encountered with
the various Lisp implementations.

\start
Date: Tue, 22 May 2007 14:01:54 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: lisp portability

On Tue, 22 May 2007, Tim Daly wrote:

| I authored a fair amount of the axiom common lisp code and I tend to
| use a very small subset of the lisp language so most of the code
| should move from CLtL1 to ANSI trivially. 

Again, you are missing the point.  The issue isn't that conversion to ANSI
Lisp is hard per see.  The point is that to make the whole useful -- as
opposed to sticking with on Lisp implementation and deeply depend on all its
extensions and implementation defined aspects -- the common subset of
the various ANSI Lisp is reduced to something essentially trivial that does
not help solve the most interesting problems.  We migh just as well abandon
it.  

| I suspect that
| package-defining issues and file-system issues are the likely
| "breakage" points. Most of the likely problem areas already have #+
| and #- conditionals due to past portings.

Some have the conditionals; most don't.  

\start
Date: Tue, 22 May 2007 14:04:17 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: lisp portability

On Tue, 22 May 2007, Tim Daly wrote:

| Gaby,
| 
| > the *variabilities* of existing lisp implementations
| 
| My largest and most painful C++ effort involved moving a program in
| "standard" C++ under Microsoft Visual C++ to GCC.

Over a decade, I've seen people believe that they write "standard" C++ under
Microsoft Visual C++.  Until they actually get to write standard C++.

\start
Date: Tue, 22 May 2007 12:11:59 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis, Tim Daly
Subject: re: lisp portability

--- Gabriel Dos Reis wrote:

> Again, you are missing the point.  The issue isn't that conversion to
> ANSI Lisp is hard per see.  The point is that to make the whole
> useful -- as opposed to sticking with on Lisp implementation and
> deeply depend on all its extensions and implementation defined
> aspects -- the common subset of the various ANSI Lisp is reduced to
> something essentially trivial that does not help solve the most
> interesting problems.  We migh just as well abandon it.  

Gaby, are you advocating a complete abandonment of Lisp in favor of
implementing Boot and SPAD in another language?  Or abandoning the
attempt to make sockets work through Lisp?

\start
Date: Tue, 22 May 2007 14:21:58 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: lisp portability

On Tue, 22 May 2007, C Y wrote:

| --- Gabriel Dos Reis wrote:
| 
| > Again, you are missing the point.  The issue isn't that conversion to
| > ANSI Lisp is hard per see.  The point is that to make the whole
| > useful -- as opposed to sticking with on Lisp implementation and
| > deeply depend on all its extensions and implementation defined
| > aspects -- the common subset of the various ANSI Lisp is reduced to
| > something essentially trivial that does not help solve the most
| > interesting problems.  We migh just as well abandon it.  
| 
| Gaby, are you advocating a complete abandonment of Lisp in favor of
| implementing Boot and SPAD in another language?  Or abandoning the
| attempt to make sockets work through Lisp?

Here is what I'm suggesting:

  * Abandon the idea that Axiom should be rewritten completely in Lisp.
    That is both pointless, resource waste.

  * Write as little as possible in Lisp.  Just the bare minimum 
    necessary to boot Boot.

  * Write the code of the compiler in Boot (when we cannot write it in Spad). 
   
  * Improve Boot -- I already have enough to get rid of most of
    Lisp forms.

    In particular, pay attention to resist the temptation of letting 
    Lisp variabilities enshrine into the Boot interface.

    Rely on the mechanimsation at the Boot translator level to achieve things
    that are painful to do directly at the bar Lisp level.

  * For Axiom runtime system: Think of Lisp as just on assembly language Axiom
    can be compile to.  Define a Virtual Machine for Axiom (yes, I klnow of
    FOAM).  In particular, have the algebra files depend only on the Axiom
    Virtual Machine instruction set.

\start
Date: 22 May 2007 14:22:51 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Lisp portability

Waldek Hebisch writes:

[...]

| Note also context: there were proposals to replace C code 
| supporting sockets and called via gcl FFI by pure Lisp solution...

Which is a backward move.

\start
Date: Tue, 22 May 2007 21:23:04 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: axiom-mode

I don't know whether this is relevant, but in my aldor-mode I define a 
separate key binding.

(defvar aldor-mode-map
  (let ((aldor-mode-map (make-keymap)))
   (define-key aldor-mode-map [return]           'aldor-newline)
   (define-key aldor-mode-map [(shift return)]   'aldor-send-to-loop)
   (define-key aldor-mode-map [(control return)] 'aldor-loop)
   aldor-mode-map)
  "Keymap for Aldor major mode.")

Don't ask me how that works. All I know is documented on

http://www.risc.uni-linz.ac.at/people/hemmecke/aldor/emacs.html

Maybe that helps you a bit further.

\start
Date: Tue, 22 May 2007 21:32:36 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: lisp portability

>   * For Axiom runtime system: Think of Lisp as just on assembly language Axiom
>     can be compile to.  Define a Virtual Machine for Axiom (yes, I klnow of
>     FOAM).  In particular, have the algebra files depend only on the Axiom
>     Virtual Machine instruction set.

I support especially this point.

\start
Date: 22 May 2007 14:48:02 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: lisp portability

Gabriel Dos Reis writes:

[...]

|   * Improve Boot -- I already have enough to get rid of most of
|     Lisp forms.

To expand on this.  

As I reported earlier, there is an experimental support for "modules"
in Boot (gdr-sandbox) that allows one to specify how one file
depends on other modules.  In particular, with CLISP, it is possible
to reuse on the fly information the CLISP compiler unconditionaly
generates. 

As of today, it is possible to define simple type specifiers at the
Boot level (gdr-sandbox).  For example, for

    Float <=> DOUBLe_-FLOAT
    Boolean <=> MEMBER(false, true)

I have the translations:

   (DEFTYPE |Float| () 'DOUBLE-FLOAT)
   (DEFTYPE |Boolean| () '(MEMBER NIL T))

Next step is to make it possible to specifiy return type and types on
function parameters, and have bootsys automatically save those
information as part of the information generated for modules.  That
will complete the long term goal of automatically generating
proclamation information to be used by those Lisp compilers that care
-- CLISP does not care, SBCL check type declarations and use them for
optimization; GCL use them for optimization; etc.

\start
Date: Tue, 22 May 2007 14:51:19 -0500
From: Jay Belanger
To: Cliff Yapp
Subject: re: axiom-mode

Cliff Yapp writes:

> --- Martin Rubey wrote:
...
>> Just another idea: M-up could get you into output "mode", and in that
>> "mode", some ordinary keys have a different meaning: b for blue
>> foreground, B for blue background, g for green, r for red, space for
>> black, etc.  That would really be a killer app!  None of the current
>> interfaces for maple, mathematica, mupad, etc. is able to do that!
>> I beg you to look at it!
>
> I'll check - Jay, does Emacs allow that kind of dynamic, context
> sensitive key binding?  I MIGHT be able to put together some sort of
> hack but an Emacs supplied mechanism would be better.

Well, you could have a key to change the keymap: M-up changes from
axiom-mode-map to axiom-paint-map, for example.  Or bind keys to
functions that behave like (if in-some-region (action-1) (action-2)).
I was looking through previous messages, and I don't know what the
`paint' is supposed to do.  Is `b' supposed to change the character
after point to blue, for example?  Why?

\start
Date: Tue, 22 May 2007 14:56:27 -0500
From: Jay Belanger
To: Cliff Yapp
Subject: Re: Lisp portability

Cliff Yapp writes:
...
> P.S.  Jay, would you be interested in pushing EAxiom forward some more?

I would, but I don't see myself having the time in the near future.

> I never did get as far as the LaTeX parts of the original code you
> developed but if there is more interest again it could motivate me to
> push ahead.  Did EAxiom match how you were wanting to interact with
> Axiom or are existing solutions sufficient?

Right now, I just use your axiom-mode to run Axiom in a buffer; I
haven't done anything fancier than that in a while.

\start
Date: 22 May 2007 22:24:28 +0200
From: Martin Rubey
To: Jay Belanger
Subject: re: axiom-mode

Jay Belanger writes:

> Well, you could have a key to change the keymap: M-up changes from
> axiom-mode-map to axiom-paint-map, for example.  Or bind keys to functions
> that behave like (if in-some-region (action-1) (action-2)).

OK, thanks!

> I was looking through previous messages, and I don't know what the `paint' is
> supposed to do.  Is `b' supposed to change the character after point to blue,
> for example?  Why?

Exactly.  The reason is that I frequently get output that is a bit hard to
digest, or that I would like to be able to point out some things to other
people watching.  In both cases, this paint functionality might help.

I'm currently trying to find out whether I could do without special keymaps, as
detailed in my previous mail.

\start
Date: Tue, 22 May 2007 15:55:35 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Boot, Virtual Machine

On Tue, 22 May 2007, Tim Daly wrote:

| Using Boot means that we lose the macro capability of lisp,

No, you don't.  You can define macros at Boot level.  They get 
translated as macros at Lisp level.  It looks to me that most of your
objections stem from insufficient familairity with Boot than informed
assessment. 

| a facility
| I use heavily and refuse to give up. If you don't understand the full
| power of lisp macros you can't understand the implications of that loss.

It looks to me that you don't understand the full power of Boot.

| And then there is the efficiency issue. Have you looked at the "lisp
| machine language" code generated by boot?

I'm amazed you have to ask, but since you asked, yes.  I've looked at it.

[...]

| When you look into how the algebra actually works you'll find that it
| depends intimately on lisp features like property lists, cons-cell
| modification, etc.

But it does NOT NEED to.  What you believe to be intimate dependency is just 
implementation details you've focused on too much to the point of losing 
sight of thr forest.

| Good luck on defining a virtual machine that isn't
| the full lisp specification. Lisp already is a virtual machine.

yes, but the Axiom run time system does not need full Lisp.  
In fact, the algebra can be compiled to something more efficient that
the use of Lisp as done.

\start
Date: Tue, 22 May 2007 16:11:20 -0500
From: Jay Belanger
To: Martin Rubey
Subject: re: axiom-mode

Martin Rubey writes:
...
> Another, maybe simpler idea: have a command axiom-set-face which allows the
> user to specify a face and make within the output region the up, down, right
> and left paint.  

Is there any reason the paint would be disabled outside the output
region?

> Or maybe M-up, M-down, M-right and M-left. Or the same with
> C-prefix.  This would render the implementation trivial, probably,
> and may even be more useable.

,,,

> We need cursor combinations for:
>
> * move to previous input line
> * get previous input                C-up / C-down
> * move within the input region      left / right
> * move within the output region
> * paint within the output region

Why are "move within the input region" and "move within the output
region" separate?

> Thus, maybe:
>
> left/right/up/down:        move ordinarily (i.e., one line)
> Shift-left/right/up/down:  paint within output region
> Ctrl-up/down               fetch previous/next input
> M-up/down                  move to previous / next input.
>
> What do you think?

It looks pretty slick.  You might want different paint commands,
though, since I think "shift-arrow" is the same as "arrow" in a
terminal. 

> -------------------------------------------------------------------------------
>
> Apart from this, I seem to have a problem with overlays:
>
> (defface axiom-blue-output '((t (:background "blue")))
>   ""
>   :group 'axiom)
> (defface axiom-red-output '((t (:background "red")))
>   ""
>   :group 'axiom)
>
>
> (defun make-blue ()
>   (interactive)
>   (let ((over (make-overlay (point) (+ (point) 1) nil nil t)))
>     (overlay-put over 'face 'axiom-blue-output)))
>
> (defun make-red ()
>   (interactive)
>   (let ((over (make-overlay (point) (+ (point) 1) nil nil t)))
>     (overlay-put over 'face 'axiom-red-output)))
>
> It seems that I cannot color something blue that was previously red?

I guess the older overlays have higher precedence than newer ones, but
the manual doesn't seem to mention that.  I suppose you could give the
overlays a special property to test for, and then remove older
overlays with that property before putting on a new one; something like:

 (defun make-blue ()
   (interactive)
   (let* ((beg (point))
          (end (1+ beg))
          (over (make-overlay beg end nil nil t)))
     (remove-overlays beg end 'axiom-face t)
     (overlay-put over 'face 'axiom-blue-output)
     (overlay-put over 'axiom-face t)))

 (defun make-red ()
   (interactive)
   (let* ((beg (point))
          (end (1+ beg))
          (over (make-overlay beg end nil nil t)))
     (remove-overlays beg end 'axiom-face t)
     (overlay-put over 'face 'axiom-red-output)
     (overlay-put over 'axiom-face t)))

I noticed that overlays can be used to give different regions of text
different keymaps, by the way.

\start
Date: Tue, 22 May 2007 14:44:28 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: re: lisp portability

--- Gabriel Dos Reis wrote:
> Here is what I'm suggesting:
> 
>   * Abandon the idea that Axiom should be rewritten completely in
>     Lisp. That is both pointless, resource waste.

As far as I know, the only parts of Axiom anyone was advocating doing
this for were up to and including the SPAD compiler - after that point,
Algebra would be done in SPAD (or Aldor, depending on how things work
out.)  I assume this is what you are referring to?

>   * Write as little as possible in Lisp.  Just the bare minimum 
>     necessary to boot Boot.

You mean, write a bootstrap only Boot in Lisp, and then use that to
handle the "full" Boot?

>   * Write the code of the compiler in Boot (when we cannot write it
> in Spad). 
>    
>   * Improve Boot -- I already have enough to get rid of most of
>     Lisp forms.
> 
>     In particular, pay attention to resist the temptation of letting 
>     Lisp variabilities enshrine into the Boot interface.
> 
>     Rely on the mechanimsation at the Boot translator level to
>     achieve things that are painful to do directly at the bar Lisp
>     level.

Um - "enshrining Lisp variabilities" - you mean basing any part of Boot
on anything that may vary between Lisp implementations?

>   * For Axiom runtime system: Think of Lisp as just on assembly
>     language Axiom can be compile to.  Define a Virtual Machine for
>     Axiom (yes, I klnow of FOAM).  In particular, have the algebra
>     files depend only on the Axiom Virtual Machine instruction set.

I think that is a separate issue from Lisp, and one I think is a good
idea - particularly from a theoretical standpoint.  That way, a formal
verification in Axiom can take place in terms of the Axiom Virtual
Machine, and it is up to the implementation to correctly implement the
Virtual Machine behavior.

I know I'm not really qualified to have an opinion on this issue, but I
personally like working in the Lisp language and would like to continue
with it.  I realize this is an opposing opinion (or at least
preference) to some very smart people on the list, but if we have a
proper Axiom Virtual Machine definition it should be a moot point
anyway - we can have multiple Virtual Machines in the same way Java
code can run on different implementations of the JVM.

I concede the point that making one or more Lisp distributions work
"ideally" may be, from a feature standpoint, redundant work.  For
myself, however, I would like to be able to work in Lisp and create a
completely literate toolchain from the ground up.  Since this doesn't
exist today in any form, Lisp is as good a starting point as any other
and the language has (to me at least) a lot of very nice points.  This
goal is at right angles to what most people are probably looking for in
the Axiom system, so I can accept that it may never be a "main goal" of
the project.

This may be one of the root reasons the project appears "unfocused" to
many people, as fundamental differences like this will lead to efforts
in different directions.  With any luck, the core of the system (the
Algebra knowledge) will be independent of all of this.

Regardless, I look forward to a fully functional Axiom platform that
will let the mathematical people work in comfort - however it is
achieved.

\start
Date: Tue, 22 May 2007 17:06:05 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: lisp portability

On Tue, 22 May 2007, C Y wrote:

| --- Gabriel Dos Reis wrote:
| > Here is what I'm suggesting:
| > 
| >   * Abandon the idea that Axiom should be rewritten completely in
| >     Lisp. That is both pointless, resource waste.
| 
| As far as I know, the only parts of Axiom anyone was advocating doing
| this for were up to and including the SPAD compiler - after that point,
| Algebra would be done in SPAD (or Aldor, depending on how things work
| out.)  I assume this is what you are referring to?

Yes.

| >   * Write as little as possible in Lisp.  Just the bare minimum 
| >     necessary to boot Boot.
| 
| You mean, write a bootstrap only Boot in Lisp, and then use that to
| handle the "full" Boot?

Not Boot in Lisp.  Just the tiny bits that are need in Lisp.
See src/boot/initial-end.lisp for something that is close to what
I would consider the minimal bits needed.


| 
| >   * Write the code of the compiler in Boot (when we cannot write it
| > in Spad). 
| >    
| >   * Improve Boot -- I already have enough to get rid of most of
| >     Lisp forms.
| > 
| >     In particular, pay attention to resist the temptation of letting 
| >     Lisp variabilities enshrine into the Boot interface.
| > 
| >     Rely on the mechanimsation at the Boot translator level to
| >     achieve things that are painful to do directly at the bar Lisp
| >     level.
| 
| Um - "enshrining Lisp variabilities" - you mean basing any part of Boot
| on anything that may vary between Lisp implementations?

I would like Boot to completely shield us from those Lisp details that vary
from implementations to implementations.  Some people consider that 
long list of #+ and #- are good way to write good codes.  I don't.

| >   * For Axiom runtime system: Think of Lisp as just on assembly
| >     language Axiom can be compile to.  Define a Virtual Machine for
| >     Axiom (yes, I klnow of FOAM).  In particular, have the algebra
| >     files depend only on the Axiom Virtual Machine instruction set.
| 
| I think that is a separate issue from Lisp, and one I think is a good
| idea - particularly from a theoretical standpoint.  That way, a formal
| verification in Axiom can take place in terms of the Axiom Virtual
| Machine, and it is up to the implementation to correctly implement the
| Virtual Machine behavior.

Indeed.

| I know I'm not really qualified to have an opinion on this issue, but I
| personally like working in the Lisp language and would like to continue
| with it.  I realize this is an opposing opinion (or at least
| preference) to some very smart people on the list, but if we have a
| proper Axiom Virtual Machine definition it should be a moot point
| anyway - we can have multiple Virtual Machines in the same way Java
| code can run on different implementations of the JVM.

When I say "Axiom Virtual Machine", I'm referring to the specification, not
the implementation.  JVM is the specification; it has many implementations 
[I note also that sometimes people uses JVM to refer to an implementation of
 the specification, instead of the specification itself.]
I do hope that we would have a single Axiom Virtual Machine, and many
implementations around.

\start
Date: 23 May 2007 00:41:11 +0200
From: Martin Rubey
To: Jay Belanger
Subject: re: axiom-mode

Dear Jay,

Jay Belanger writes:

> Martin Rubey writes:
> ...
> > Another, maybe simpler idea: have a command axiom-set-face which allows the
> > user to specify a face and make within the output region the up, down, right
> > and left paint.  
> 
> Is there any reason the paint would be disabled outside the output
> region?

Not really.  Accordingly, I drop this specification.

> > left/right/up/down:        move ordinarily (i.e., one line)
> > Shift-left/right/up/down:  paint within output region
> > Ctrl-up/down               fetch previous/next input
> > M-up/down                  move to previous / next input.
> >
> > What do you think?
> 
> It looks pretty slick.  You might want different paint commands, though,
> since I think "shift-arrow" is the same as "arrow" in a terminal.

Well, I think I'll hack together a prototype that works in gnu emacs under X,
and leave the more difficult part of making it run under xemacs and in a
terminal for others.  I'm really not an elisp expert.

> I noticed that overlays can be used to give different regions of text
> different keymaps, by the way.

Oh, that sounds extremely useful, since we could easily give all of the output
region some overlay property.  Very nice idea!

Below is what I have so far.  One thing I'm stuck with: how can I allow the
user to change the face, or at least the color?

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defface axiom-output-paint '((t (:background "lightblue")))
  "Face to use for painting."
  :group 'axiom)

(defun make-space-if-necessary-and-paint ()
;; The following is to make sure that a line does not end with a painted
;; character.  This would have the unwanted effect, that spaces appended by
;; either axiom-paint-previous-line or axiom-paint-next-line inherit the face
;; of the last character.
    (when (eolp)
      (insert-char 32 2)
      (backward-char 2))
    (forward-char 1)
    (when (eolp)
      (insert-char 32 1)
      (backward-char 1))
    (backward-char 1)

    (let* ((beg (point))
           (end (1+ beg))
           (overlays (overlays-at beg))
           (over nil))
      (while (and overlays (not over))
        (setq over (car overlays))
        (unless (overlay-get over 'face)
          (setq over nil))
        (setq overlays (cdr overlays)))

      (unless over (setq over (make-overlay beg end nil nil t)))
      
      (overlay-put over 'face 'axiom-output-paint)))

(defun axiom-paint-previous-line ()
  (interactive)
  (let ((inhibit-read-only t)
        (old-column (current-column)))
    (make-space-if-necessary-and-paint)
    (previous-line 1)
    (if (> old-column (current-column))
        (insert-char 32 (- old-column (current-column))))))

(defun axiom-paint-next-line ()
  (interactive)
  (let ((inhibit-read-only t)
        (old-column (current-column)))
    (make-space-if-necessary-and-paint)
    (next-line 1)
    (if (> old-column (current-column))
        (insert-char 32 (- old-column (current-column))))))

(defun axiom-paint-previous-char ()
  (interactive)
  (let ((inhibit-read-only t))
    (make-space-if-necessary-and-paint)
    (backward-char 1)))

(defun axiom-paint-next-char ()
  (interactive)
  (let ((inhibit-read-only t))
    (make-space-if-necessary-and-paint)
    (forward-char 1)))

(define-key axiom-mode-map [\S-up] 'axiom-paint-previous-line)
(define-key axiom-mode-map [\S-down] 'axiom-paint-next-line)
(define-key axiom-mode-map [\S-left] 'axiom-paint-previous-char)
(define-key axiom-mode-map [\S-right] 'axiom-paint-next-char)

\start
Date: 22 May 2007 19:01:08 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: re: Boot, Virtual Machine

Greetings all,

Its been a while since I posted to the list, The following has me
curious.

Gabriel Dos Reis writes:

> On Tue, 22 May 2007, Tim Daly wrote:
> 
> | Using Boot means that we lose the macro capability of lisp,
> 
> No, you don't.  You can define macros at Boot level.  They get 
> translated as macros at Lisp level.  It looks to me that most of your
> objections stem from insufficient familairity with Boot than informed
> assessment. 

Gaby. Could you, please, give an informative example of how Boot
macros translate into Lisp?  Perhaps an interesting example of how a
Lisp macro could be translated into Boot?  Unfortunately, I do not
understand Boot particularly well.  In my readings of the extant Boot
code I have not noticed heavy use of macros.  However, I do understand
Lisp.

> | a facility
> | I use heavily and refuse to give up. If you don't understand the full
> | power of lisp macros you can't understand the implications of that loss.
> 
> It looks to me that you don't understand the full power of Boot.

My hope is that this means the equivalence of the two macro systems
is easy to demonstrate.

\start
Date: Sat, 19 May 2007 17:00:03 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Unnamed repository

	edit this file to name it for gitweb.: Changes to 'master'

 test |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

New commits:
commit e0c4666ae210f955db9ac506135f0e31ed5fdecd
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 04:05:39 2007 -0400

    test remote deletion with git

\start
Date: Sat, 19 May 2007 16:54:25 -0500
From: git@axiom-developer.org
To: list, Tim Daly
Subject: Unnamed repository

	edit this file to name it for gitweb.: Changes to 'master'

 test |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

New commits:
commit bed025c200b10534393ced238bd08f0552a5b929
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 03:59:44 2007 -0400

    test remote push

\start
Date: Sat, 19 May 2007 17:00:03 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Unnamed repository;

	edit this file to name it for gitweb.: Changes to
	'refs/remotes/origin/master'

 test |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

New commits:
commit bed025c200b10534393ced238bd08f0552a5b929
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 03:59:44 2007 -0400

    test remote push

\start
Date: Sat, 19 May 2007 17:27:47 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Axiom silver branch: Changes to 'master'

 test |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

New commits:
commit 7f39cab333a3143736ba23d6ee28e650f9045b8f
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 04:30:33 2007 -0400

    try xinetd

\start
Date: Sat, 19 May 2007 17:00:03 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Unnamed repository;

	edit this file to name it for gitweb.: Changes to
	'refs/remotes/origin/HEAD'

 test |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

New commits:
commit bed025c200b10534393ced238bd08f0552a5b929
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 03:59:44 2007 -0400

    test remote push

\start
Date: Sat, 19 May 2007 17:27:47 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Axiom silver branch: Changes to

	'refs/remotes/origin/HEAD'

 test |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

New commits:
commit e0c4666ae210f955db9ac506135f0e31ed5fdecd
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 04:05:39 2007 -0400

    test remote deletion with git

\start
Date: Sat, 19 May 2007 17:27:48 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Axiom silver branch: Changes to

	'refs/remotes/origin/master'

 test |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

New commits:
commit e0c4666ae210f955db9ac506135f0e31ed5fdecd
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 04:05:39 2007 -0400

    test remote deletion with git

\start
Date: Sat, 19 May 2007 23:34:52 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Axiom silver branch: Changes to

	'refs/remotes/origin/HEAD'

 test |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

New commits:
commit 7f39cab333a3143736ba23d6ee28e650f9045b8f
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 04:30:33 2007 -0400

    try xinetd

\start
Date: Sat, 19 May 2007 23:34:52 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Axiom silver branch: Changes to 'master'

 test |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

New commits:
commit 389cf2af0a6578c276092b6f8c71bc12847a2e09
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 09:37:49 2007 -0400

    remove test

commit d9e550d080236d187279efcf41449791f4da1a46
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 06:09:15 2007 -0400

    mybranch test

\start
Date: Sun, 20 May 2007 22:50:37 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Axiom silver branch: Changes to 'master'

 CHANGELOG                    |    3 +
 src/algebra/Lattice.pamphlet |45354 ------------------------------------------
 src/regress/REGRESS          |18029 +-----------------
 3 files changed, 6 insertions(+), 63380 deletions(-)

New commits:
commit 957b24ee741bb4a90e64c2fd4af24d62b8e36660
Author: Tim Daly <root@localhost.localdomain>
Date:   Sat Apr 28 06:24:27 2007 -0400

    fix src/regress/REGRESS. file was corrupt

commit cd9a3e68bd7dd29335a6220471017147936dfab9
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 23:32:19 2007 -0400

    remove Lattice.pamphlet, unused

commit f70b37cc1b0c1b6069edb3ba870b41340919ddfc
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 23:21:45 2007 -0400

    fix the REGRESS to be a script

\start
Date: Sun, 20 May 2007 13:12:29 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Axiom silver branch: Changes to 'master'

 CHANGELOG | 1192 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 1192 insertions(+), 0 deletions(-)

New commits:
commit ce3ce708865b3661f1c33d904637f967587a0dc1
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 22:25:16 2007 -0400

    fix CHANGELOG

\start
Date: Sat, 19 May 2007 23:34:52 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Axiom silver branch: Changes to 'refs/remotes/origin/master'

 test |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

New commits:
commit 7f39cab333a3143736ba23d6ee28e650f9045b8f
Author: Tim Daly <root@localhost.localdomain>
Date:   Fri Apr 27 04:30:33 2007 -0400

    try xinetd

\start
Date: Mon, 21 May 2007 23:57:40 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Axiom silver branch: Changes to 'master'

 CHANGELOG             |    1 +
 src/doc/book.pamphlet |   14 +++++++-------
 2 files changed, 8 insertions(+), 7 deletions(-)

New commits:
commit 800f402b8b850ff8f21544795181043aa2cedf8d
Author: Tim Daly <root@localhost.localdomain>
Date:   Sat Apr 28 17:44:23 2007 -0400

    src/doc/book.pamphlet fix typos (but #89)

\start
Date: Tue, 22 May 2007 15:38:12 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Axiom silver branch: Changes to 'master'

 CHANGELOG |  833 +++++++++++++++++++++++++++++++------------------------------
 1 files changed, 417 insertions(+), 416 deletions(-)

New commits:
commit a234de385deb3ebc24f5e8fe00d7311a7bc255ef
Author: Tim Daly <root@localhost.localdomain>
Date:   Sun Apr 29 09:04:36 2007 -0400

    CHANGELOG move wxh entries to gdr where requested

\start
Date: 22 May 2007 20:21:56 -0500
From: Gabriel Dos Reis
To: git@axiom-developer.org
Subject: Re: Unnamed repository;

git@axiom-developer.org writes:

|  test |    1 +
|  1 files changed, 1 insertions(+), 0 deletions(-)
| 
| New commits:
| commit bed025c200b10534393ced238bd08f0552a5b929
| Author: Tim Daly <root@localhost.localdomain>
| Date:   Fri Apr 27 03:59:44 2007 -0400
| 
|     test remote push

Tim, please could you set up the commit message so that they go to
axiom-commit@sf.net?  That would be greatly helfpul in linking with
other commit messages.

\start
Date: Tue, 22 May 2007 20:23:11 -0500
From: Jay Belanger
To: Martin Rubey
Subject: re: axiom-mode

Martin Rubey writes:
...
> Below is what I have so far.  One thing I'm stuck with: how can I allow the
> user to change the face, or at least the color?
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> (defface axiom-output-paint '((t (:background "lightblue")))
>   "Face to use for painting."
>   :group 'axiom)

Perhaps you could make axiom-output-paint a variable; something like:

(defface axiom-output-blue '((t (:background "blue")))
   "Blue face to use for painting."
   :group 'axiom)

(defface axiom-output-lightblue '((t (:background "lightblue")))
   "Light blue face to use for painting."
   :group 'axiom)

(defface axiom-output-red '((t (:background "red")))
   "Red face to use for painting."
   :group 'axiom)

etc.  (which are automatically customizable)

(defvar axiom-output-face-alist
  '(("blue" . axiom-output-blue)
    ("lightblue" . axiom-output-lightblue)
    ("red"  . axiom-output-red)
    ...))

(defvar axiom-output-paint 'axiom-output-lightblue)

(defun axiom-output-change-paint ()
  (interactive)
  (let ((newpaint (completing-read "New paint: " 
                                   axiom-output-face-alist
                                   nil t)))
    (setq axiom-output-paint (cdr (assoc newpaint axiom-output-face-alist)))))

and then the end of 

> (defun make-space-if-necessary-and-paint ()

could be

>     (overlay-put over 'face 
>                       (get axiom-output-paint 'face-defface-spec))))

\start
Date: 22 May 2007 20:42:33 -0500
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: re: Boot, Virtual Machine

Stephen Wilson writes:

| Greetings all,
| 
| Its been a while since I posted to the list, The following has me
| curious.
| 
| Gabriel Dos Reis writes:
| 
| > On Tue, 22 May 2007, Tim Daly wrote:
| > 
| > | Using Boot means that we lose the macro capability of lisp,
| > 
| > No, you don't.  You can define macros at Boot level.  They get 
| > translated as macros at Lisp level.  It looks to me that most of your
| > objections stem from insufficient familairity with Boot than informed
| > assessment. 
| 
| Gaby. Could you, please, give an informative example of how Boot
| macros translate into Lisp?  Perhaps an interesting example of how a
| Lisp macro could be translated into Boot?  Unfortunately, I do not
| understand Boot particularly well.  In my readings of the extant Boot
| code I have not noticed heavy use of macros.  However, I do understand
| Lisp.

Hi Stephen,

   The Boot macro system was there before I got interested in Boot.
Basically you define Boot macros the same way you define Boot
functions except that you replace the "==" token with "==>"
For example, if you can write the memeq macro as:

   memeq(e,l) ==>
     MEMBER(a,l, KEYWORD::TEST, function EQ)

that gets translated as:


   ; memeq(e,l) ==>
   ;   MEMBER(e,l, KEYWORD::TEST, function EQ)

   (DEFMACRO |memeq| (|bfVar#2| |bfVar#1|)
     (PROG ()
       (RETURN
         (SUBLIS (LIST (CONS '|bfVar#2| |bfVar#2|)
                       (CONS '|bfVar#1| |bfVar#1|))
                 '(MEMBER |bfVar#2| |bfVar#1| :TEST #'EQ)))))


At some point, I had a patch to clean up the translation but:
  (1) there seems to be no use of macros in Boot codes
  (2) Given (1), it did not seem to be a pressing issue
  (3) Nobody raised the issue of not knowing how to write macros
      int Boot.

Note also that one always have the escape character (!) to 
insert raw Lisp code if one really wants to.

Is there any contrived used of macros in Axiom that is not covered by
the above scheme?

Eventually, I'll document Boot from user perspective and improve the
Boot translator in a way that helps people use it with confidence.

\start
Date: Tue, 22 May 2007 22:00:04 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: Boot, Virtual Machine

Quoting Gabriel Dos Reis:

> ... 
> Eventually, I'll document Boot from user perspective and improve the
> Boot translator in a way that helps people use it with confidence. 
>

I would be forever grateful for such an large contribution to Axiom!
(-: And the sooner, the more grateful I will be... :-)

\start
Date: Wed, 23 May 2007 04:24:01 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: Boot, Virtual Machine

Gabriel Dos Reis wrote:
> Stephen Wilson writes:
> 
> | Greetings all,
> | 
> | Its been a while since I posted to the list, The following has me
> | curious.
> | 
> | Gabriel Dos Reis writes:
> | 
> | > On Tue, 22 May 2007, Tim Daly wrote:
> | > 
> | > | Using Boot means that we lose the macro capability of lisp,
> | > 
> | > No, you don't.  You can define macros at Boot level.  They get 
> | > translated as macros at Lisp level.  It looks to me that most of your
> | > objections stem from insufficient familairity with Boot than informed
> | > assessment. 
> | 
> | Gaby. Could you, please, give an informative example of how Boot
> | macros translate into Lisp?  Perhaps an interesting example of how a
> | Lisp macro could be translated into Boot?  Unfortunately, I do not
> | understand Boot particularly well.  In my readings of the extant Boot
> | code I have not noticed heavy use of macros.  However, I do understand
> | Lisp.
> 
> Hi Stephen,
> 
>    The Boot macro system was there before I got interested in Boot.
> Basically you define Boot macros the same way you define Boot
> functions except that you replace the "==" token with "==>"
> For example, if you can write the memeq macro as:
> 
>    memeq(e,l) ==>
>      MEMBER(a,l, KEYWORD::TEST, function EQ)
> 
> that gets translated as:
> 
> 
>    ; memeq(e,l) ==>
>    ;   MEMBER(e,l, KEYWORD::TEST, function EQ)
> 
>    (DEFMACRO |memeq| (|bfVar#2| |bfVar#1|)
>      (PROG ()
>        (RETURN
>          (SUBLIS (LIST (CONS '|bfVar#2| |bfVar#2|)
>                        (CONS '|bfVar#1| |bfVar#1|))
>                  '(MEMBER |bfVar#2| |bfVar#1| :TEST #'EQ)))))
> 
> 
> At some point, I had a patch to clean up the translation but:
>   (1) there seems to be no use of macros in Boot codes
>   (2) Given (1), it did not seem to be a pressing issue
>   (3) Nobody raised the issue of not knowing how to write macros
>       int Boot.
> 
> Note also that one always have the escape character (!) to 
> insert raw Lisp code if one really wants to.
> 
> Is there any contrived used of macros in Axiom that is not covered by
> the above scheme?
>

One of the simplest macros is SPADCALL, and it already looks beyond
the scheme above.  More interesting example involve optimizing
macros like qeqcar which generate specialized code for constants.
Or pattern maching like setqp.

I think that main point is that macros allows you to easily
perform local code transformations which otherwise require 
changes to the compiler.  Even if you can change compiler
working at one level is easier.

\start
Date: 22 May 2007 22:51:18 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: re: Boot, Virtual Machine

Gaby,

Thanks for responding.

Gabriel Dos Reis writes:
>    The Boot macro system was there before I got interested in Boot.

Do your have plans to expand on its current facilities?

> Basically you define Boot macros the same way you define Boot
> functions except that you replace the "==" token with "==>"
> For example, if you can write the memeq macro as:
> 
>    memeq(e,l) ==>
>      MEMBER(a,l, KEYWORD::TEST, function EQ)

OK.  My curiosity was aroused since you claimed that Boot macros would
suffice in place of Lisp macros.  I was hoping for something more
substantial than this.

I have not been involved in this community for a long time, so I did
not want to patronize you with a definition of `interesting'.

In Lisp, the correspondence between data and code is fundamental.

[snip]

> At some point, I had a patch to clean up the translation but:
>   (1) there seems to be no use of macros in Boot codes

I don't code boot, so OK.  Thus, no sense in trying to define a Lisp
equivalent macro system.

>   (2) Given (1), it did not seem to be a pressing issue

I would agree, given (1).

>   (3) Nobody raised the issue of not knowing how to write macros
>       int Boot.

Whenever I read Boot, I just macroexpand it mentally into Lisp
anyways.

> Note also that one always have the escape character (!) to 
> insert raw Lisp code if one really wants to.

I vaguely recall this facility, but the memory does not jive with my
concept of Lisp macros at any level.

> Is there any contrived used of macros in Axiom that is not covered by
> the above scheme?

Well, there may very well be a few examples in the *.lisp.pamplet
files.

\start
Date: Tue, 22 May 2007 22:54:27 -0400
From: Bill Page
To: Alasdair McAndrew
Subject: Re: Axiom tutorial

Quoting Alasdair McAndrew:

> In a recent email to me, Bill Page claimed:
>> The last commercial version of Axiom included a very nice tutorial
>> that could be run from with the techexplorer browser interface. 
>> Several years ago I spent some time to convert this tutorial to a
>> TeXmacs document. I think that is still around somewhere. If you
>> are interested I could help you resurrect it. 
> I would be very interested in getting hold of this - if you still
> have it.  Even turning it into a text-based tutorial would be better
> than nothing!

Mike Dewar sent me the original NAG version of the tutorial by email that
I first mentioned here:

http://lists.nongnu.org/archive/html/axiom-developer/2003-10/msg00071.html

I produced a TeXmacs version of this tutorial and the most recent version
I can find is here on Savannah:

http://download.savannah.gnu.org/releases/axiom

:(It's odd that we don't seem to have any links to things here any more. 
I guess I had assumed that we moved everything after establishing
axiom-developer.org ):

You might like to take a look a the pdf generated by TeXmacs first:

http://download.savannah.gnu.org/releases/axiom/tutorial.pdf

The file extension of the tgz archive was mangled for some reason,
but I have just transferred to the Axiom Wiki and you can find a link
to it on this page:

http://wiki.axiom-developer.org/TeXmacs

under the heading "Examples"

http://wiki.axiom-developer.org/uploads/tutorial.tgz

See also:

http://download.savannah.gnu.org/releases/axiom/book-axiom-intro.tm
http://download.savannah.gnu.org/releases/axiom/book-axiom-intro.pdf

\start
Date: Wed, 23 May 2007 05:15:18 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: clisp and sbcl

I commited next batch of fixes.  As of revision 563 algebra in
wh-sandbox should bootstrap using clisp or sbcl.  Note that
to build with clisp or sbcl you stil need to replace 
interp-proclaims.lisp by empty file (or, if you prefer safety
declaration).  ATM sockets and writablep are not supported,
so some tests fail.  If you configure Hyperdoc build
may hang trying to generate .pht pages (this is due to
missing sockets).

\start
Date: Tue, 22 May 2007 22:47:08 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: re: Boot, Virtual Machine

On Tue, 22 May 2007, Stephen Wilson wrote:

| 
| Gaby,
| 
| Thanks for responding.
| 
| Gabriel Dos Reis writes:
| >    The Boot macro system was there before I got interested in Boot.
| 
| Do your have plans to expand on its current facilities?

If people think it is something they really want, then I can give it higher
priority. 
So until today, nobody raised this issue -- it was only on my todo list. 

| > Basically you define Boot macros the same way you define Boot
| > functions except that you replace the "==" token with "==>"
| > For example, if you can write the memeq macro as:
| > 
| >    memeq(e,l) ==>
| >      MEMBER(a,l, KEYWORD::TEST, function EQ)
| 
| OK.  My curiosity was aroused since you claimed that Boot macros would
| suffice in place of Lisp macros.  I was hoping for something more
| substantial than this.

Well, it would be much easier to tell me what *you* than me telling you 
want.  My statement is based on the part of Axiom that was manually converted
from Boot to Lisp.

| I have not been involved in this community for a long time, so I did
| not want to patronize you with a definition of `interesting'.
| 
| In Lisp, the correspondence between data and code is fundamental.

You have the same thing in Boot.  
But, it is not that fundamental for building an Axiom system than
people actually sometimes  want to make it.

| [snip]
| 
| > At some point, I had a patch to clean up the translation but:
| >   (1) there seems to be no use of macros in Boot codes
| 
| I don't code boot, so OK.  Thus, no sense in trying to define a Lisp
| equivalent macro system.

Well, when I look at src/interp, I see more Boot codes than Lisp codes.  So,
my statement is based on the actual things in that directory.

[...]

| > Note also that one always have the escape character (!) to 
| > insert raw Lisp code if one really wants to.
| 
| I vaguely recall this facility, but the memory does not jive with my
| concept of Lisp macros at any level.
| 
| > Is there any contrived used of macros in Axiom that is not covered by
| > the above scheme?
| 
| Well, there may very well be a few examples in the *.lisp.pamplet
| files.

Yes.

\start
Date: Wed, 23 May 2007 13:50:26 +1000
From: Alasdair McAndrew
To: list
Subject: HyperDoc appearance?

Is there any easy way of changing the HyperDoc appearance: size and position
of windows and fonts, widgets used, etc?  I can change some things by
modifying X resources, but not all.

\start
Date: Tue, 22 May 2007 22:52:19 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: Boot, Virtual Machine

On Wed, 23 May 2007, Waldek Hebisch wrote:

| Gabriel Dos Reis wrote:
| > Stephen Wilson writes:
| > 
| > | Greetings all,
| > | 
| > | Its been a while since I posted to the list, The following has me
| > | curious.
| > | 
| > | Gabriel Dos Reis writes:
| > | 
| > | > On Tue, 22 May 2007, Tim Daly wrote:
| > | > 
| > | > | Using Boot means that we lose the macro capability of lisp,
| > | > 
| > | > No, you don't.  You can define macros at Boot level.  They get 
| > | > translated as macros at Lisp level.  It looks to me that most of your
| > | > objections stem from insufficient familairity with Boot than informed
| > | > assessment. 
| > | 
| > | Gaby. Could you, please, give an informative example of how Boot
| > | macros translate into Lisp?  Perhaps an interesting example of how a
| > | Lisp macro could be translated into Boot?  Unfortunately, I do not
| > | understand Boot particularly well.  In my readings of the extant Boot
| > | code I have not noticed heavy use of macros.  However, I do understand
| > | Lisp.
| > 
| > Hi Stephen,
| > 
| >    The Boot macro system was there before I got interested in Boot.
| > Basically you define Boot macros the same way you define Boot
| > functions except that you replace the "==" token with "==>"
| > For example, if you can write the memeq macro as:
| > 
| >    memeq(e,l) ==>
| >      MEMBER(a,l, KEYWORD::TEST, function EQ)
| > 
| > that gets translated as:
| > 
| > 
| >    ; memeq(e,l) ==>
| >    ;   MEMBER(e,l, KEYWORD::TEST, function EQ)
| > 
| >    (DEFMACRO |memeq| (|bfVar#2| |bfVar#1|)
| >      (PROG ()
| >        (RETURN
| >          (SUBLIS (LIST (CONS '|bfVar#2| |bfVar#2|)
| >                        (CONS '|bfVar#1| |bfVar#1|))
| >                  '(MEMBER |bfVar#2| |bfVar#1| :TEST #'EQ)))))
| > 
| > 
| > At some point, I had a patch to clean up the translation but:
| >   (1) there seems to be no use of macros in Boot codes
| >   (2) Given (1), it did not seem to be a pressing issue
| >   (3) Nobody raised the issue of not knowing how to write macros
| >       int Boot.
| > 
| > Note also that one always have the escape character (!) to 
| > insert raw Lisp code if one really wants to.
| > 
| > Is there any contrived used of macros in Axiom that is not covered by
| > the above scheme?
| >
| 
| One of the simplest macros is SPADCALL,

I doubt SPADCALL is simpler than the MEMEQ macro.

| and it already looks beyond the scheme above.

Which part of it?  Optional arguments?
For optional arguments in Boot, you prepend  a colong to the name of the
variable. 

| More interesting example involve optimizing
| macros like qeqcar which generate specialized code for constants.
| Or pattern maching like setqp.

That does not need speciaal handling in the compiler.

| I think that main point is that macros allows you to easily
| perform local code transformations which otherwise require 
| changes to the compiler.  Even if you can change compiler
| working at one level is easier.

You seem to imply that I was proposing to ditch macros.  I'm not.
I'm just pointing out that macros were not kept out of Boot.  They are 
there for those who think they need them.  So, I don't think I would put
special optimization in the compiler.  When I said "clean up", it is in
term of the readability.

\start
Date: Tue, 22 May 2007 20:52:08 -0700 (PDT)
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: clisp and sbcl

--- Waldek Hebisch wrote:

> I commited next batch of fixes.  As of revision 563 algebra in
> wh-sandbox should bootstrap using clisp or sbcl.  Note that
> to build with clisp or sbcl you stil need to replace 
> interp-proclaims.lisp by empty file (or, if you prefer safety
> declaration).  ATM sockets and writablep are not supported,
> so some tests fail.  If you configure Hyperdoc build
> may hang trying to generate .pht pages (this is due to
> missing sockets).

Sweeeeet!  Thank you, Waldek!  I did a fresh checkout of wh-sandbox,
and tried a build as follows:

cyapp@localhost ~/mathtoplevel/axiomtoplevel/testwork/wh-sandbox $ svn
update
At revision 563.
cyapp@localhost ~/mathtoplevel/axiomtoplevel/testwork/wh-sandbox $
./configure --disable-x --with-lisp=sbcl
[stuff]
cyapp@localhost ~/mathtoplevel/axiomtoplevel/testwork/wh-sandbox $ make
[stuff]
/usr/bin/install -c -m 644
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbo
x/src/doc/msgs/s2-us.msgs \
                
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/target/i
686-pc-linux/share/msgs
3 making
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-li
nux/bin/depsys
for A in postpar.clisp parse.clisp parsing.lisp metalex.lisp \
                 bootlex.lisp newaux.lisp preparse.lisp def.lisp \
                 metameta.lisp fnewmeta.lisp clam.clisp slam.clisp \
                 g-boot.clisp g-util.clisp; do \
           B=${A%.*} ; \
           echo '(unless (probe-file "'$B'.fasl")' \
                '(compile-file "'$A'" :output-file "'$B'.fasl"))' \
                  >> makedep.lisp ; \
          echo '(load "'$B'")' >> makedep.lisp ; \
        done
echo '(load "makedep.lisp") (BOOT::spad-save
"/home/cyapp/mathtoplevel/axiomtoplevel
/testwork/wh-sandbox/build/i686-pc-linux/bin/depsys" nil)' |
/home/cyapp/mathtopleve
l/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-linux/bin/lisp
* 
debugger invoked on a SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread #<THREAD
"initial thr
ead" {A7BDDD9}>:
  The name "USER" does not designate any package.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-INT:%FIND-PACKAGE-OR-LOSE "USER")
0] 
* 4
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-linux/b
in/depsys created
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/src/interp/../.././build/
scripts/document --tag=lisp --mode=compile --output=vmlisp.fasl
--use=/home/cyapp/ma
thtoplevel/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-linux/bin/depsys
vmlisp.l
isp >>
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-linu
x/trace
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/src/interp/../.././build/
scripts/document: line 124:
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandb
ox/build/i686-pc-linux/bin/depsys: No such file or directory
make[3]: *** [vmlisp.fasl] Error 127
make[3]: Leaving directory
`/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandb
ox/src/interp'
make[2]: *** [all-interpsys] Error 2
make[2]: Leaving directory
`/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandb
ox/src/interp'
make[1]: *** [all-interpsys] Error 2
make[1]: Leaving directory
`/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandb
ox/src'
make: *** [all-src] Error 2

On clisp:

cyapp@localhost ~/mathtoplevel/axiomtoplevel/testwork/wh-sandbox $
./configure --disable-x --with-lisp=clisp
cyapp@localhost ~/mathtoplevel/axiomtoplevel/testwork/wh-sandbox $ make
echo '(load "makedep.lisp") (BOOT::spad-save
"/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-linux/bin/depsys"
nil)' |
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-linux/bin/lisp
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006

[1]> 
;; Loading file makedep.lisp ...
;;  Loading file sys-pkg.lisp ...
;;  Loaded file sys-pkg.lisp
;;  Loading file ./interp-proclaims.lisp ...
** - Continuable Error
INTERN("GAZONK-NAME"): #<PACKAGE SYSTEM> is locked
If you continue (by typing 'continue'): Ignore the lock and proceed
The following restarts are also available:
SKIP           :R1      skip (PROGN # #)
STOP           :R2      stop loading file
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/src/interp/makedep.lisp
ABORT          :R3      ABORT

*** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER
#P"./interp-proclaims.lisp" @2383>: #<PACKAGE SYSTEM> has no
      external symbol with name "PNAME"
The following restarts are available:
SKIP           :R1      skip (PROGN # #)
STOP           :R2      stop loading file
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/src/interp/makedep.lisp
ABORT          :R3      ABORT
Bye.
4
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-linux/bin/depsys
created
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/src/interp/../.././build/scripts/document
--tag=lisp --mode=compile --output=vmlisp.fas
--use=/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-linux/bin/depsys
vmlisp.lisp >>
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-linux/trace
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/src/interp/../.././build/scripts/document:
line 124:
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-linux/bin/depsys:
No such file or directory
make[3]: *** [vmlisp.fas] Error 127
make[3]: Leaving directory
`/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/src/interp'
make[2]: *** [all-interpsys] Error 2
make[2]: Leaving directory
`/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/src/interp'
make[1]: *** [all-interpsys] Error 2
make[1]: Leaving directory
`/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/src'
make: *** [all-src] Error 2

\start
Date: Tue, 22 May 2007 21:05:06 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Should we update the AxiomSources page?

Tim, in the interests of simplicity can we reorganize the AxiomSources
page to highlight instructions for cvs/svn of Axiom Gold, git for Axiom
Silver, and svn for the axiom.build-improvements and wh-sandbox
branches?  Do any of the other branches contain work not already
incorporated into one or more of the above?  Are the arch branches now
present in Git?  If we're moving off of arch to Git, we might want to
make this page reflect that.

We can put the Darcs and Mercurial links under "alternative
distribution methods" or some such, but arch should probably go away
unless there is a compelling reason I'm not aware of to keep it.  Can
the differences in the arch branches be expressed as git branches (or
are they already so expressed in your system, if you've moved to Git?)

Cheers,
CY

(Incidently, is the 2005 tarball also the latest Gold release?  If not,
we should probably fix that...)

\start
Date: Wed, 23 May 2007 06:06:18 +0200 (CEST)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: clisp and sbcl

> --- Waldek Hebisch wrote:
> 
> > I commited next batch of fixes.  As of revision 563 algebra in
> > wh-sandbox should bootstrap using clisp or sbcl.  Note that
> > to build with clisp or sbcl you stil need to replace 
                                                 ^^^^^^^
> > interp-proclaims.lisp by empty file (or, if you prefer safety
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

> > declaration).  ATM sockets and writablep are not supported,
> > so some tests fail.  If you configure Hyperdoc build
> > may hang trying to generate .pht pages (this is due to
> > missing sockets).
> 
> Sweeeeet!  Thank you, Waldek!  I did a fresh checkout of wh-sandbox,
> and tried a build as follows:
> 
> l/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-linux/bin/lisp
> * 
> debugger invoked on a SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread #<THREAD
> "initial thr
> ead" {A7BDDD9}>:
>   The name "USER" does not designate any package.
>

this comes from interp-proclaims.lisp
 
> On clisp:
> 
> 
> *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER
> #P"./interp-proclaims.lisp" @2383>: #<PACKAGE SYSTEM> has no
>       external symbol with name "PNAME"
> The following restarts are available:

Again the same. 

\start
Date: Tue, 22 May 2007 21:10:39 -0700 (PDT)
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: clisp and sbcl

Whoops, note to self - read directions.  Sorry.  <turns red>

Retrying now.

--- Waldek Hebisch wrote:

> 
> > --- Waldek Hebisch wrote:
> > 
> > > I commited next batch of fixes.  As of revision 563 algebra in
> > > wh-sandbox should bootstrap using clisp or sbcl.  Note that
> > > to build with clisp or sbcl you stil need to replace 
>                                                  ^^^^^^^
> > > interp-proclaims.lisp by empty file (or, if you prefer safety
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> 
> > > declaration).  ATM sockets and writablep are not supported,
> > > so some tests fail.  If you configure Hyperdoc build
> > > may hang trying to generate .pht pages (this is due to
> > > missing sockets).
> > 
> > Sweeeeet!  Thank you, Waldek!  I did a fresh checkout of
> wh-sandbox,
> > and tried a build as follows:
> > 
> > l/axiomtoplevel/testwork/wh-sandbox/build/i686-pc-linux/bin/lisp
> > * 
> > debugger invoked on a SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread
> #<THREAD
> > "initial thr
> > ead" {A7BDDD9}>:
> >   The name "USER" does not designate any package.
> >
> 
> this comes from interp-proclaims.lisp
>  
> > On clisp:
> > 
> > 
> > *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER
> > #P"./interp-proclaims.lisp" @2383>: #<PACKAGE SYSTEM> has no
> >       external symbol with name "PNAME"
> > The following restarts are available:
> 
> Again the same. 

\start
Date: Wed, 23 May 2007 00:24:50 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: clisp and sbcl

Cliff,

Just a quick note: I would strongly recommend that you do an
out-of-source build - especially if you are building multiple targets. 

E.g. 

First make sure the download is clean:

   cd ~/mathtoplevel/axiomtoplevel/testwork
   svn co ... new-wh-sandbox

Then make a new directory for the sbcl build:

   mkdir sbcl-test
   cd sbcl-test
   ../new-wh-sandbox/configure ... 
   make
   ... 

And another new directory for the clisp build:

   cd .. 
   mkdir clisp-test
   cd clisp-test
   ../new-wh-sandbox/configure ... 
   make

If these fail, then all you need to do to start fresh is:

   rm -rf *
   ../new-wh-sandbox/configure ... 

At least that way you wont be stepping on the toes of the
deterious of a previous build. I am always suspicious about
how well 'make clean' might or might not work. 

Regards,
Bill Page. 

Quoting Cliff Yapp:

> ... 
> I did a fresh checkout of wh-sandbox, and tried a build as follows:
>
> cyapp@localhost ~/mathtoplevel/axiomtoplevel/testwork/wh-sandbox $ svn update
> At revision 563. 
> cyapp@localhost ~/mathtoplevel/axiomtoplevel/testwork/wh-sandbox $
> ./configure --disable-x --with-lisp=sbcl
> [stuff]
> cyapp@localhost ~/mathtoplevel/axiomtoplevel/testwork/wh-sandbox $ make
> [stuff]
.. 

\start
Date: 23 May 2007 00:38:03 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: re: Boot, Virtual Machine

Gabriel Dos Reis writes:
> On Tue, 22 May 2007, Stephen Wilson wrote:
> 
> | 
> | Gaby,
> | 
> | Thanks for responding.
> | 
> | Gabriel Dos Reis writes:
> | >    The Boot macro system was there before I got interested in Boot.
> | 
> | Do your have plans to expand on its current facilities?
> 
> If people think it is something they really want, then I can give it higher
> priority. 
> So until today, nobody raised this issue -- it was only on my todo list. 

This is perfectly understandable.  

> | > Basically you define Boot macros the same way you define Boot
> | > functions except that you replace the "==" token with "==>"
> | > For example, if you can write the memeq macro as:
> | > 
> | >    memeq(e,l) ==>
> | >      MEMBER(a,l, KEYWORD::TEST, function EQ)
> | 
> | OK.  My curiosity was aroused since you claimed that Boot macros would
> | suffice in place of Lisp macros.  I was hoping for something more
> | substantial than this.
> 
> Well, it would be much easier to tell me what *you* than me telling you 
> want.  My statement is based on the part of Axiom that was manually converted
> from Boot to Lisp.

I thought of that too.  I was being optimistic.  I was going off on
your comment to Tim that "It looks to me that you don't understand the
full power of Boot".

I figured that since you are deeply involved in developing Boot that
an `interesting' example would roll off the tip of your tongue. Sorry.

> You have the same thing in Boot.

Well, I would argue that till pigs fly. But I wont.

> But, it is not that fundamental for building an Axiom system than
> people actually sometimes  want to make it.

Of course. Its not fundamental.

I have a bias.  Im fluent in Lisp.  I see Boot as being a weak syntax
for Lisp.  But thats just me.

Given my bias, I trust you can understand why someone like myself
could view Axiom as a Lisp program.
 
> | [snip]
> | 
> | > At some point, I had a patch to clean up the translation but:
> | >   (1) there seems to be no use of macros in Boot codes
> | 
> | I don't code boot, so OK.  Thus, no sense in trying to define a Lisp
> | equivalent macro system.
> 
> Well, when I look at src/interp, I see more Boot codes than Lisp codes.  So,
> my statement is based on the actual things in that directory.

I understand that the majority of code is not explicitly Lisp.  I
thought your statements were based on subtle points which I missed.

\start
Date: Wed, 23 May 2007 00:41:20 -0400
From: Cliff Yapp
To: Jay Belanger
Subject: re: axiom-mode

Jay Belanger wrote:

> I guess the older overlays have higher precedence than newer ones, but
> the manual doesn't seem to mention that.

I have a vague recollection of running into something like that, but
I'll have to check the code for painting the input red upon change.
This sort of thing was what drove me batty about getting things working
in Emacs.  I can't escape the nagging feeling that a Better Emacs could
be created, but I guess until someone does we're sorta stuck...

Between the day job and personal commitments it's going to be a little
while before I can devote any serious time to EAxiom work, but
I will try to revisit it.

I just tried a basic session on my machine and I didn't seen any
problems with cursor placement - can anyone confirm this behavior?  I'm
using GNU Emacs 21.4.2 on gentoo linux.

As for key bindings for movement, I may try to make this configurable.
Personally I prefer having the basic up and down arrow keys take me to
the input lines, but I can see where other people would want other
options so the logical thing I think is to provide some default key
binding profiles based on user settable variables.  (One more thing to
figure out how to do...)

Does anyone have a nice complex axiom startup input file I can try in
order to see if the crash due to processing it is repeatable?  I've
never used one myself.

\start
Date: Tue, 22 May 2007 21:53:33 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: clisp and sbcl

--- Bill Page wrote:

> Cliff,
> 
> Just a quick note: I would strongly recommend that you do an
> out-of-source build - especially if you are building multiple
> targets. 

Heh - whoops.  Good idea, but I'm already a ways into the sbcl build
after doing several attempts at sbcl, clisp, and gcl in the same tree. 
Something to try if something goes wrong though, thanks!

> At least that way you wont be stepping on the toes of the
> deterious of a previous build. I am always suspicious about
> how well 'make clean' might or might not work. 

Actually, if wh-sandbox is put into git it should be able to spot any
un-cleaned-up files for us.  It would mean a manual cleanup until make
clean does work properly, but from that standpoint it's a very handy
way to debug make clean :-).

>From what I understand thus far about git we wouldn't want to stick all
of wh-sandbox's changes into a git branch and try to merge whole hog
with silver, as we couldn't "pick and choose" from such a merge.  I
think this is one reason Tim is advocating more "community" development
- with smaller, compartmentalized divergences from the "silver" or
"gold" trees we could use git branches to very, very efficiently manage
this process.  I know at this early stage it's not really workable
since some of the changes simply can't be minor and leave the build in
a workable state (e.g. autoconf), but I hope later on we can make use
of this, especially for Algebra development.  It really is a very, very
interesting way of doing work and I can see why Linus (who, IIRC,
advocates small changes that are easily understood as opposed to sudden
large scale changes) would want it like this.

Tim, as an aside, how would you suggest handling the ANSI changes?  1st
merge enough make changes to be able to try building on sbcl (even
though we know it will flop) and then the source code changes that make
it work?

\start
Date: Wed, 23 May 2007 01:07:00 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: clisp and sbcl

Quoting Cliff Yapp:

> ... 
> Actually, if wh-sandbox is put into git it should be able to spot any
> un-cleaned-up files for us.  It would mean a manual cleanup until make
> clean does work properly, but from that standpoint it's a very handy
> way to debug make clean :-). 
>

I wouldn't hold my breath for any mass source transfer from svn git :-)

And I certainly wouldn't do it that way, but most source code packages
have similar commands. Consider

   svn status
   svn revert ... 

\start
Date: 23 May 2007 08:10:13 +0200
From: Martin Rubey
To: Alasdair McAndrew
Subject: Re: HyperDoc appearance?

Alasdair McAndrew writes:

> Is there any easy way of changing the HyperDoc appearance: size and position
> of windows and fonts, widgets used, etc?

i'm afraid you'll have to modify the sources for that.  If you do, I'd be
particularly interested in having a cursor that has the hotspot where I expect
it to be.  And better scrollbars would also be nice...

> I can change some things by modifying X resources, but not all.

Oh, so what can you do?

\start
Date: Wed, 23 May 2007 10:16:23 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Should we update the AxiomSources page?

Cliff,

http://wiki.axiom-developer.org/AxiomSources

that page seems out of date anyway. So why don't you just follow what is 
written at its bottom?

http://wiki.axiom-developer.org/BeBold

Ralf

On 05/23/2007 06:05 AM, C Y wrote:
> Tim, in the interests of simplicity can we reorganize the AxiomSources
> page to highlight instructions for cvs/svn of Axiom Gold, git for Axiom
> Silver, and svn for the axiom.build-improvements and wh-sandbox
> branches?  Do any of the other branches contain work not already
> incorporated into one or more of the above?  Are the arch branches now
> present in Git?  If we're moving off of arch to Git, we might want to
> make this page reflect that.
> 
> We can put the Darcs and Mercurial links under "alternative
> distribution methods" or some such, but arch should probably go away
> unless there is a compelling reason I'm not aware of to keep it.  Can
> the differences in the arch branches be expressed as git branches (or
> are they already so expressed in your system, if you've moved to Git?)
> 
> Cheers,
> CY
> 
> (Incidently, is the 2005 tarball also the latest Gold release?  If not,
> we should probably fix that...)

\start
Date: Wed, 23 May 2007 05:50:36 -0500
From: Tim Daly
To: list
Subject: business trip

I'll be away for the rest of the week with the usual spotty connectivity.

\start
Date: Wed, 23 May 2007 04:41:30 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Should we update the AxiomSources page?

I tried, but I think the links in the cvs/svn/etc. commands are
triggering the security system.  No good way around that, as those
commands cannot be distorted - they MUST appear in correct form.  Maybe
I'm doing something else wrong though - I never did get the hang of the
anti-spam measures properly...

CY

--- Ralf Hemmecke wrote:

> Cliff,
> 
> http://wiki.axiom-developer.org/AxiomSources
> 
> that page seems out of date anyway. So why don't you just follow what
> is 
> written at its bottom?
> 
> http://wiki.axiom-developer.org/BeBold
> 
> Ralf
> 
> On 05/23/2007 06:05 AM, C Y wrote:
> > Tim, in the interests of simplicity can we reorganize the
> AxiomSources
> > page to highlight instructions for cvs/svn of Axiom Gold, git for
> Axiom
> > Silver, and svn for the axiom.build-improvements and wh-sandbox
> > branches?  Do any of the other branches contain work not already
> > incorporated into one or more of the above?  Are the arch branches
> now
> > present in Git?  If we're moving off of arch to Git, we might want
> to
> > make this page reflect that.
> > 
> > We can put the Darcs and Mercurial links under "alternative
> > distribution methods" or some such, but arch should probably go
> away
> > unless there is a compelling reason I'm not aware of to keep it. 
> Can
> > the differences in the arch branches be expressed as git branches
> (or
> > are they already so expressed in your system, if you've moved to
> Git?)
> > 
> > Cheers,
> > CY
> > 
> > (Incidently, is the 2005 tarball also the latest Gold release?  If
> not,
> > we should probably fix that...)

\start
Date: Wed, 23 May 2007 08:14:02 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: re: Boot, Virtual Machine

On Tue, 23 May 2007, Stephen Wilson wrote:

| > You have the same thing in Boot.
| 
| Well, I would argue that till pigs fly. But I wont.

What would make you believe that you don't have the same equivalence in Boot?

\start
Date: Wed, 23 May 2007 09:34:20 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Should we update the AxiomSources page?

Quoting Cliff Yapp:

>
> I tried, but I think the links in the cvs/svn/etc. commands are
> triggering the security system.  No good way around that, as those
> commands cannot be distorted - they MUST appear in correct form. 
> Maybe I'm doing something else wrong though - I never did get the
> hang of the anti-spam measures properly... 
>

Great. If you are willing to do this then I am sure that Tim would have
no objection if I assigned you an admin account on the Axiom Wiki. 
After you log-in, then there are no more spam restrictions and you
can edit the page however you wish. 

Please send me by private email your preferred user id and an initial
password (change it later if you wish) and I can create your account. 

\start
Date: 23 May 2007 15:35:26 +0200
From: Martin Rubey
To: list
Subject: [ANN] new version of axiom mode for emacs.
Cc: Alasdair McAndrew

--=-=-=

Dear all,

after a day of hacking and with some help from Cliff and Jay (many thanks!) I
have a new version of axiom.el, which you find attached.  I'd be extremely
grateful for feedback!  Alasdair, is this usable for you?

To use it, put it into a directory where emacs can find it, gunzip it, say

  document axiom.el.pamphlet

to obtain documentation and source or

  notangle axiom.el.pamphlet > axiom.el

to obtain source only.  Then start (gnu) emacs and type

  M-x load-file

press return and type 
  
  axiom.el

possibly including the complete path.  To start a fresh axiom session type

  M-x axiom

Most things should come natural, here is a very short description of it's
functionality:

-------------------------------------------------------------------------------
M-x axiom 
  starts an axiom session or returns to an already started one.  We really
  should provide functionality to have several sessions in parallel, but I
  don't know how to do this.

M-up, M-down 
  moves the cursor to the previous or next input.

C-up/M-p, C-down/M-n 
  fetches the previous or next input.

M-k 
  copies the current input-output combination into the kill-ring.

S-up, S-down, S-left, S-right
  turns the cursor into a paint-brush.

M-x axiom-paint-face 
  changes the face of the paint-brush.

return 
  evaluates input.  If point is on a previous input, it overwrites old output
  ``nicely''.
-------------------------------------------------------------------------------

Changes:

  * I modified some keybindings and instead of axiom-mode one calls axiom now.

  * I provided support for painting.

  * by default, HyperDoc is started now.

  * I fixed bugs that positioned point incorrectly and screwed up overwriting
    old output.  Cliff: you said you fixed that already once.  Could you see
    whether you had a different axiom.el.pamphlet than provided on MathAction?

-------------------------------------------------------------------------------
ToDo:

* Testing: does it work with xemacs? does it work under MSwindows?

* the way we deal with system commands like )quit is unsatisfactory for two
  reasons:

  - we do not allow user interaction: )quit will quit without asking, but
    worse, )di op 1 will make emacs appear to hang. C-g get's everything back
    to normal.  Reason: )di op 1 will make axiom ask whether we really want a
    long list of operations.

  - (1+x)q will be parsed as )quit.  We do not check yet whether the first
    non-white space character is the open parenthesis.

* the underscore character does not work.  It should...

* the way we wait for output looks extremely dangerous to me:

(defun axiom-wait-for-output ()
  "Wait for output from the Axiom process.  Point is set at the end of the
  line."
  (while (and 
          axiom-waiting-for-output
          (not (search-backward ") -> " (- (point) 5) t)))
    (accept-process-output axiom-process))
  (sit-for 0 axiom-after-output-wait)
  (end-of-line))

  what if output contains ") -> " and we are unlucky?  Not sure whether this is
  a problem though.  In all other places, instead of ") -> " the regular
  expression axiom-prompt is used.  Shouldn't we do this here, too?  Isn't
  there a simpler way to look for output?

  In fact, it might make sense to keep the current output number in a variable
  -- that way we could also detect errors.

* It would be nice to give the output a different face, as in mmm-mode, but I'm
  a bit lazy.  Maybe today evening.

* S-return should overwrite old output while return should copy the input line
  at point and evaluate it at the bottom of the buffer.

* it would be important to have the possibility of deleting part or all of the
  buffer.  (Personally, I often have a buffer with a 100000 lines, which is a
  burden for emacs, it seems). By contrast, it is not necessary to provide
  functionality as stated in the section "Restarting and Re-evaluating - Kill
  and Restart Axiom without Erasing the Document" since such functionality is
  provided by axiom itself.

* it would be extremely nice to have command tab-completion, as when starting
  axiom in a shell.  (The polymake team would like to have this, for example.)
  Anybody knows how to go about this?

* undo should have sane behaviour, whatever that is.  Possibly, it should be
  restricted to the current input, but that might be too restrictive. (For
  example, if one has overwritten some important output by accident.)

* sending definitions from input files is still not possible.

* cleanup is certainly necessary.  I don't know elisp well enough.  I have no
  idea, for example, why   

   (end-of-line))

  in axiom-wait-for-output is necessary.  Really, every function should state
  in the docstring where point is supposed to be before and after execution.

  It is extremely important that this mode works reliably, and as it is
  currently, I wouldn't be surprised if it would screw up in weird
  circumstances.

Martin


--=-=-=

H4sICLo6VEYAA2F4aW9tLmVsLnBhbXBobGV0ANV9+XPkxpXmz4O/AsGdGZLjKkpth3fDku2YVqsl
cbevbba25XDLS1RVFgkTBZQAFNm0Qv/7vu8deQAoHpLXM9MxY3UXgDxeZr7zey8/rJrlbuPqflkV
Xfdj0fblsnI/5dmHXee2xfKquHA/Fh/LZvNT9i/Zv+T5q6Z3eVnn27ZZuq4r64u8vyy73NrJ53nf
4Olqt3T0yOWuKrttvi4rN8vbXY1G8PO6qarmBt8vm82mqFefSQd10xf1ReVy7vXEVSfbYrO9rFyf
/9H/Jq++Cx0V+YvinfvOD0O7kgZv3GLcmjy8uSyXl/lNWVWhKXuzdx/ppQ8Ld1HWP1rDP2Uf+rKv
3I8f/vnszdMvP+na5SduUyw7+W7TrBx9CwIWu/6yaX/8n8Vt/oWraE6uneXPqnK9zv9UbLez3PUn
eVGd5Eedc/mydauy746p/U1x5bgP67tYdH1bLKnvPH/OfRHBm9rlzZpJuWm6Pt82211VtLmrr8u2
qTHWjojc5it37apmC0oTlfMd1owa6pp1f1O07iTPn24aeki957QOt3mxKKuyLx110+fLoqbl7l27
Log2N2V/mbuP9M+6YIpdtMWmo9bQMv3zulw5fr2qygvshu627ouP+WV5cUm/XPYYBQZVUFP06nXR
lq6/xURAoR3ttu6EmnuHLXXTtFeYKY2g6Hu32fbYWqAOTYInX8QNGAGEQrp3bWwrty6JYNSUPI6o
lPe72q3ybuuW5bpcFlV1i37oOJRE1qdYVfTXYiArNMfrSsP84OpVtDYf3F/dsqftUSwq16yXDZGB
1sB+zz509J+yqX981mxvWxCDR/aiXLq6c7S22bd1VV7JobkuqO9N8demLWV2PI6Z7lciSiWf0XrW
K9fyNy+bFU2Afvri7MtMn8/kdMqksTn3fPv1mxcnSnb6v21bboiwRIjVjsbTZDwk197SKrUXtFnp
7MpkeBVWtHPp77QjQj8dNVvQDFterJVfOQwni6lfUHd0Qtv1rsLfacuVRNvs979fGpn++Mc/ZJ9/
ngeyHT07zp/87ne/neW//vTT/54vbvO9hwwfftUW9bKhab0sqt7d5ln272hfqaCt89R1Q4ME65YO
pZ2Rz/PbZsdHAaeUFrxc7MAGeQU/aVo0sAH1b/FboCqdk01np/TrV9/mX7vatUSnN7sFdW9rT/NG
C1v82F0SsWhG+OIrjOFMx5B/1VDDBQj9ee7oHFIftCQdFuHX1AdawEcvbOHplB3RCtDI27zZ4rvj
HMe7Kvrw6Qk+83+mCBHmuwLfRxeXzdbJ8tJsmXcuHD6lhaZVnOX0cv7+9N03r799lz999af8/dO3
b5++evenz5l/NPSUWJI0VW62FW1ZfE2TpIWS3f7y+dtn39AnT784fXH67k+Yy1en7149PzvLv3r9
Nn+av3n69t3ps29fPH2LT998+/bN67PntIPPnLuP2GA/m4YIunJ9UVbdmAR/osXuaJzVKr8srh0t
+tKV1zT/Isem3L+g+NivaQWmygyzj0j6eV6uIePoKNPRxuHyS42vJ1Z7lp/Wy5NZ/tvf5e+ICZJk
fFMRL57lZzs08JvffDrLvyAJQG+ihZdP809//eTJk/mT33z6P/Jvz57Sdqctb9zJmNBp3bO840M8
14MLfvRUhH32jjaY4/M75tXxMS+uiYhgeSSReCrvm5YI9x6fvHcLZVmZCYdCWBvWmptau6LftU5E
FXGFfscMGBu1Lzri/5uCRCDaN0FFzKjpZGQd7SNQX7gizueCHmx5Sxlll5fUoCPGwAcRMqW0deGp
fpaZmCVqbsq/ESf+gL/lH0j+94v1j5vNZo6p/kRk4sPBbLSA9tJxDyqM6PiviWTE0pg8JCnOz5mD
89fd4SGOT5FD/FZgDR97VopoWl8UncidGbMUaVloLLoUKEftYbvSxl1NyHjfd0tTaWqe65LZfdSn
6TAngxk+3S1Jd8L85G849phY1xOrsN1OqqHqWFBURIeI+TiGkepg3bCf5y9JR9oUnpCQ7aIa3BKr
3dJPpH0WYDQjIU2dkYbEz9ARiztuDNrjdgeOVlQXbtHSZG876lTFs1/TeD9XXUP9bUg1/YguaTvE
Gxrtq7QV0rPmlNe7zYJ6IUYb9KNIeyQF4RqMXHVbO7xCvUg/JtH2oml4DxL/pJc7ZweJDh8+rp1b
dbHId7yzV21xk++2NBI9MiTG6SCl4yENjdmW6BE0Syc7oFY9JswzbHtHM6NT1PuN/4z2T0PbRT7p
oOVjR0k70sJih/2GE5kvsHlVZ7wV3l/kF00DVWlNe3lBihiGwpwUtO1KOuM9Nyn0WzX1oW57foHk
+KLBgPCvDal+RCzbSukOs60YHef89HUYctFZE7RvtrSDTRjT2PyCkE6tW0lPWicrtt7VS1FroIJh
YPKaDeU0UnMvafEqDMSO3eCE0nYA/XRFy3pZ7XhblTWNZMtWF+uuL8hUIsZOhsVMmHG1on7RovV6
tttum7YXbd6LIiLYtZ51by0VLEeigUQdU6/3aekNN+ba+fKSCHHF62xKb7RlgkR5t+tJWy0q+u20
FhLqI+xLIuuS1AhVIxckStZ06i9pyWlvgIOKkBStnVVRlwUTUSwsNRQ7PsW6WGQ2TrLvP7M59j14
GJYdNkS8naFRtI6OUc08Fo8r4i+rW/mAtgvZVzSM99gq9AAySVUCk2Tp/rAdbiIpPja0wJBBohlR
e6e65a/INDUSrBqmgC7zn1/Od7QRXs5XzU39PR3YayecZblrO/A/kW3b1l2Xza7DbGoIlLImXmht
PKM2Pnk5p3aecTv0d2pr7frlpbZ29/cv51ffQ+EpQ98sYvilOalx9B+syYLkMy8zbSkZ1xVxxHkb
ju2fz3g6ZzwM/Ldy6x7/ZX3++1zXIcyPWyr4bNBf54t2112exAs7lwcwSr+HiGf5zqwXZqqeiomP
Zc2/JwW0qIgLwcblKdOiwIIsMb1O974Rh99g0UzL0LLaBune0F5QIpyf16T1VbeHhyOxc9orS6at
j5ewdBekTPIA9fMikt9rVu0K3jemeZxEp+ysb0lp27XieCE9kVSIn2DO/BsMmcRqim0c+nvrftiV
pGnxP5gTnWGr77b/hxQ7KFjy5NueOfnkj1/plpcf+XMaB7fFv7wje4c2Q0WWqPT5nJ/5f75R3qQ/
QC8NM9M+8i9hqrNB2YnYVsauHiczOODgEY4nwkgcGyKfDplX0GJmR8oz5uzDoCWl/z3OlagxTf6Q
Hek/8kP59pjtxKcq+G5NgZ+lXodroxPza+MJwqLE6SAaC4vJDNKxdphGQVzwr82io533Vdl2Pct5
npq6KlgVKDZB/zIisGEGV4RoZReia2FfLWKuuH+R2d71/xbz/OaSDLJOF1QInh3RSGh60vNcCZkf
HBznOduJ0KdYhbNZMx8DhTcyAXqIY+ZEKyh7UW2yfP8f2LA8DyPdwq1hqi0chtU54k02qqohlXlb
9JfdMT77NszCFe3y0s6HaIM5XhxMiEjX5QfzulkSN9JJnV7UrGBzQ0+/O339kr7HJEGkk0EDRGv4
pA7+cvThw9GfP53/7vtfffhwfJzP/5gfHA/exY6e0/hB3i4/YtXt4Jh+yDfYDBcObqWmagriKWsa
jWy+d6we+s9s5+/qEuY7SZkaXpUe2q+oUmyayHGBfl2LICU7g3ZYVmFV9uwuW12iPs6VKir4lo5n
U0OjrF2sILlMfAq88VZlxxYgWqLtSZo8rU3kNkTLoHKidFiXaDnbyeE/4S5p57TaY7dja054+9vn
Xz//7o1pK9QvjaXu4XXpjUtksiidTZxUpcvB2IswWbgwPFE7FvpyCEjP7pssnhZpO/C4iP/ruqno
1LEyqcvXKdWhqV+wT4DUV95FWFNoXFVJxgmxDTi33qsRgvPA8wC/Iz3ib07sksBUwDrEYUPj40M9
5s98no17+k8HGxA7Y35JlgdJoWq4O5WDTjwxpjvxSNQAknbDBzcFK+VzGrtpCf3wnWJNc9Kn/EH+
5NNPp3tQw+vg0+hQCYeeV0XXh3HIIEkEXrrlFXX+kbVGkjM4SpETmPbztatLVy+DEtfFtI3EXEJb
/zKPY1en1Ds6Js528JYVDN4y+juJDzmc/UiU0Rml01YTsWYYfJ412GQ3ZecOqK0jjPlI392mC3Ls
H1j36WMwkGSQSup1WWEzHXV9y8OFLaoO+drdiKqTyxk6yc9cL046/hWj0eWUJel4kLzJ0R6WnJgR
TTRhj9pTjjBH/8PUyh7xV3NpIn/CX4w/mdhVWO/RRPFe/JIsy3tsMcxTf13T4MYLQlzjjemA4M1i
oefYW8onwUpOdN6keckaRRJt31ijV47qpsfMIKXmsI7JTiOxKnIjP5rTymIMx/lvj+ncGCWK5dJt
e1tfm9xg0TGuTqaff7rvpPFbNKV5s55jOhEFy24uH+muVOI9w4Hy7oT1nRv55N6da6Q4cj+ETQxX
064b7vFDapRX+Pe/VxYpm+qSqMYKpaomlSvq3RYnXSdC53zFRobuwiOlYuvmQ8InmxWHsI8Iwu2w
Om1vPK6l4bu0MHd0at53r09VdDo77/ACt2N3F2nQTg+pKUhs7mDbsA9Yo3E9adb8hATZtipuxU0C
M3fe1IhykcmHQZCVT6IXH57CMOboRaMOmZLMh5YHwxspGshlgbgX4i3QBuhj5sb+Z2+EyTixQ4gG
pG7V8PJdSX/pdEnEkaC/aUS3i6RgGQ/ruik5XtC6rTgEhbYnftHYQpvr/JN1O4Jf5Oio32x5czx8
P/izi081CPWwVdVvj3D6EnrjpPuBPDm2f0rj9O9DYlEk4oRYtpXuaMd/GP5xmFL8AY3YYNI2bLsk
zBayhEw94yysY8nhEH7RgVMIl7gsOr9vsVw1+75MNWgiYQnmkR/Rh8JBHsokE5NC+Csxl2klQT88
DqvqmTPLkz3byKSJiTMZ5AQRrFnda2V9WS6IJSdkDOOdWIo9ww5Tntgcef7Lm5waoVIECtS3NZTp
XU1HrhKFm8hU7Ko+URrEIKQJs2J8K15Msmw3O2IZFoTPVJletrvIj4adwJxcLMfd9rM9fP8PtkL8
9ny3nTrjU3QPx5inzQwNNDETjPXH9B1hr+r52hTtlarJytkvmr5hlqevz4nOQXdJmMPB0RPs3oP0
adjaw8ek+EyP0nriwewfSPHxeL+oOlB71YzVQZ9Ts57sFofAjtv0aPe1Fw4BLSYYw1wiVz+vmT3z
p6e0c8d6wh9SlVF/V/YVK52J+TN4FhlNxxJjDSEmCDGO/YkQE0O5sejJnEPH8vej6CQd82n5jh+c
ZF+4ZQHHOCMi4D8vW7FG2UFifxWQTJ0vyHSwoL6HHCA80rRwLWUbEv9mbuo5lI488EUCF1B5S6K6
N6ADSmslDqoMLh5SLGjtv/NoJHHQsA2NOQA8c1GLgQ0vd+VWFzzcwkt1wXgMTLU/eAtP1cm5PMmP
NOi1zQ/lF1nayC0au65+yrJgji+c9+mLi1DBE6ARLZMPKszz83Ne2cNDw9m4WkxpYqZtMXD4c4hN
nB0w3zDr83NzGR0eBqROoSEy8U/4+AOxJKLx6zp/TzomAr5HBa/bbz/5zSeAtRzzK4kTyofaZ3nX
YFFvirof7Ae4kcieUhxTt6XDmQTcsENvnLTNAQvr4CRjaJ/4RJxGKGzHcKSCd9RHUu7YmyZOPX4z
fa1cZ56QCCwkVCnNUckONYbwcY8kj2YSJvLuKb/1MiM8C4QL188Tj2R0nEfPTCM5Y/6nbiTRLtUx
+Obpu2/8nvSqtjhbEdhobw/CwQ8+RyKEW87xV+ELYg2G5565gUMizD/HBzvGhs2J0yybeknTPloO
PJkHn3DXB7GOwFbSRT0eQyKvwtsRj/JOW2s1aXbY3tFylYxG34ZdsOYwNHxTxCcBxSPRbvKfFtRW
eCQVdkTpPUPJ7hywtchjNu6qsA+GVtHRvXKRT0Ziywkb4PidOPiIIbmN+vI2CLuqabIFI2DTAifj
M8GdQWCKF3C+jl1BqdAQnQreUvX80N/evH399dunLyUuIW+YG0hC1G+/PmNW0dE/4RJqiL2LySxq
C/tkD57GJDqSd+ck4LQpIuw10fWo2G5Zj2Nv8iHgdToqI3JK1Lsc76rrUWfbCp5q8cUER7nXlyMF
maYupy3MX13PISojc2NPMDGO8prVY9pQX6trKfI7E0fAu6MzrF+geWYV9klKRkFO3Gi37IMYLJO2
86q5IfbZi9FcGpRh6GidFPVHqnrov4+1RQwk8USb1lAAkVFVw9bsMU9Vmgq/DbvQPthQFubYcchY
F5o3N+lExB/gPQ7eOlWJ53hIokBaMeZO3LAqXeujLInhKkJSxbAfutJR3oGu5j5uk+90oE9Xq0FE
SJcZoxXvI4uAyhyPsmXk43jo0EDew7fIAOTUwmgWDLdZzWRG8vGGlLgOXgvTftRkg/XJ3vaF4+gQ
MDjYHqsVjpScHZ1d4iQNZz8/nPCh6nzfC2AHx51MHJoJO7MRMuEQppcoHIIhfQTITCLwUjgYT0wa
0lkDvkbLI7EDO8YagBJYskGzOEqhh+HE9rZJ8Chcwl+WgK4OzQAlegc8IhvopCWARzKruoCyBYcp
K0t901RQkUQZ9SqjLK+0s3CkT5RN6wGCmYqCu6RAFss3damy6Jg0WthEyv/8l/x7tZZGDpr8oa5S
cZbuHV4QPz9nhL94XPc7cSVAmKq9tpQ4AxZNNhWR8SXN7uKSFvFGw08D9THT4F+A2SS6ZNHbrhO5
6pmHAdEUzWafZ8plgK3oDTyzUFPOcSxBGRIT1ffKivX5OYKjpDBCu2z6TCAeEsnT6IO4FjDH/nJn
EzcXpekmXiGIvpxlwiaX1a4T2Iq69mUWiPVv4KDQqZOqt20NzcP9lXRSSAvmwKUOhq0ZUxpsKiOd
YfjCwGOBDIyJcLH3Id5h5NvW5EaCZiXeW1Ez+dFI7ZJeWfObfmEQ7PP+s8nXpkN//k1ls/AASovR
s7sml3txPojuHHvt8D14VsGbgbZYCYyF7VA2LFIFcM0YI90ArPUNwCx/mLY07lAPJ9dfoNceIafw
GGRqKCRVcnfEQOTgfSNBctaWVHxgQz57emaoXONRIjDI8jy5Oimy3tpmbEtQfJdCE4Mtq2XG4WA6
XVB6vTwSSG6G8ycpMAsX0ovQa1MnY+MGMUCSamChJGgAphRoP7OaUbIHpgCcGU1Y10XAUV2PsRpq
NWDFGaefQIOzIeZYEdj4C2kKHRIKGKp3YwgQYY3c7elr0U1v2OQ+ySTxicWzwdBHENoeEX/rqhyC
ZweY8ff2NXGMtcQr2NKWWEoK4AOoD/8lVb5ceU1g23SCfbJ0nFXDmAUPP8YoiCnMmOEx33KFMC7v
cQByTTDT2DqrgiH0F6YWMSU6hZE5dUMFFASTLaxBhNig9mqS8BcC9sMWJHraeCOM7vk59JAFKXi0
w7r+lg6dwu0UEM1zhTYhOSQ0F6KF9htwd4xRBQepJHNr5eF3trJA4NG4Wg1sSQgbeXHzgPOWnBRg
kRHxLfLrkvfqGutB57VeMbMJmF7NvmoD8i8syWywOwBehyUh6WeDYZujI3LaqKHDbhdFuCsM0czS
fIvUjhOfAEddMf60Ez97QgGG/1awg7ob2f4kSkU9bJ1Hk3eX5dpeR9bfjlTnH3aceMXfwdEONQ/I
TFMuoaXmcBguXEwYS2bqimtBY4lMHFLFZhgSQwShzBgKZDE0aEGw8rQVZ4LpFuoQqTtSQekAO04w
A6C2APa12wFX0Blp2XsGJO1KoLnsnMAIeM2le+mFmZTi9IXV6EP1w61FajJp0AWR8JaHZgHQHf+9
dcDxzKBE25rJiEmyYv1rVo/gH2EjEvhy+u8IDfqB6S/SgPnSXEXBK2YPYp3BacmiRFkXd0Psd1cz
C5TNXgpi0DxvxJIlcUZkXoakL9li736WYBCRINo+NPxITPmk05WyywBanIEKwo/0uDFnjoRGFp85
7+IGar7oXOSfvCk7NuuFDuKOMw2HCCJGidjIMxlmBn645W6gtFm+YZgVg7yZTDTalvO5NpYhIwAP
Un9ctRbUdwzFjOxZ2Umk8fC5iUzbWCxF2Qjqxmb4kTcRr9ztpthy9oSi65ZqtipGPfFqbIrSwOvq
U8kseyZ9LLNcS04XK6Qy/vBwqJCae/St/4HFo9cloklN+XHgxRSv0tFR5F/6uwE/VLMd+b+OYq+M
R8j09jtD3UgUzMemVSa+zD5gVw3p4uG17IaJV6DsEuorTILlj0QxwS0lcGlQLNHOuKUUH4yPdUuz
sPL4mVp/sBVO7YbpGan1IACsu2huETbvl5p4hSH70/QdQbHiqJi6QRTDTN0cdnDDK8mQr0TTNmwQ
u5O829AcctBHbgTPDbalEV8Pew2+vKF+PXDBYLVIV1G+p3kVsjA0jlJc2FWjuSbqtJAZz3OPvIO0
NaOR01/XayTn9J+Z04hBlIcRvfSXJJbo3Xaulm51FAERw06oQQR7PCGyPatyWfaQcZwvGsN6xKdk
doCxbO/VIROpgwrHrlGkQVWDNphfsHuIfedeNZAWxML6jNdsClJznIf1Y1nEwEcgaCEG4ZtflIz0
6BR41/IOF/0ZO4p6nnO0gUy9bbzT6Z8abaUh9WW/o76pvfnKZwZ4j51pXWJOGgpC16Jbtg2t0uCd
n9cR0mPu6iR6Pu4AflEIgNVKRSdxnwvNHE6WZK/LVCj2KJ/lFH5FB/MaOwWJSrdsTPA+byC+2WA3
KFnOqXsiksvIgyNj2RNxzwQtEis6L0W5t/w3s35NEbGtjnPXlkszai5QYMI0bw9T99ZTMA26k+yN
iX2k0IpOw87gJIwovbFuqJr5kkFJnHK/16J7m45qLThYLd/QtsRkaMN0Ys/x8i1cf+M0u11w91xl
pHfdlqHwHkV3fj7/IycF857hpkxph1IJ1INkK6Uw1CwPQNQ8P8NZk1BmpwrrhphViTRxtpukeU3N
HroOJB2N4e108luX5DMTwzo/V+grmqKxBnCfzxQX+xS6l8RvlPr9ZbMSx18J7FeNBHq1BVAVok4y
AaBye32bG1iq5bNwjDtYcax5V1eQOl54rxxPhn05lkpblRv4s8T12bRXJ1PLqFJJTJ7BGvJWZeW1
8dRjQnpXd838DhlzYsOLYwNJ/aR7tawSaKRC0QcaGyqRQSKjeSMGugDf6JDp1mCIOoM7vYOQR9I6
HZciF7yvQEMG7IKJd0wXfDogihn34hgV7Y4hHbacEIacpIQTUFulGF17ywmcsGTCGTf64tuXShRR
eb7EjDSZKznysU8jsC2IbE70FuvVAg0WXOj4Wz6v72SjKCplGIHT3D0LSNoyfmZgILBnWvVFU7Qr
4tJeSPCrkZ48EB6mMMvBFDapvCkQzyNf4wRC7n6WZw1DhhRGLRu5bqbeldApzNW5+wjGB/NJNehH
oI81yvGoL0LII40ZPwzzOvhm6C/OPW7/3+9exJCRqrQrum63EedP0VsuO3I86f/FTI1jUAp6llzm
6pbPMzYk+80s9uaDjdm+jYFRDDdFJOwfsyFGE6KBZhObYfDeXRshXdqHLcrEyj5gkbwJ7NlZ5CwS
JSGS0DCa+kkqZEmOyX6yNxcNxG1Mdf1pQPPeUhIUtKD6E79pJ5GXhdNMaNQSorubpj8Dedw/knhs
t6Uk44VXJyivncptngt0+f306q7Kra+WpATzv/1SimWRGnAH5fZtx4O/CNyUyPcrT77fPIx8A/p5
P9dUSvwwZ1tOz16S2SmJGfwoZDfF/w9equt+D5efBL1olA8w5bTNkCNguKltHBczBOzBq8bjNmLl
9yCGLEuUOqjm2yE3joNwIRQNLO3xcYS0iknOjFmCFaMCBMKpvH6TkP1OqgcOOqL4kLkm1J5kjfsp
Hdq6m8qpW4jLkcRdgaC5t3IeHrP8e6xH8JICRu+XQaxD88TgA18pRt3fFpsQA5VtOTqpiBqg/kAd
UzHPv2luYA/OYmeB9mHtBFRTx8mvRbaoivrKa8fi15JIDJc7Qei5Y5ufQ05W+2siigOP5q5LHdpw
5MM90qanTEfDpk/8viqN7EXLYvgRnBDcxMv5NvZKMHiavblb16JKTCcYaq+K3sc41PCf3sTTroef
uZ8frLs9WBU4mnafPImPDzb0k5Au43l89PjXk9z+5J8PBtlPsXiQMA+3LW2MT8REQoB/+Xic8Tn2
wPznoHMeEToa3H8ZIk+IXymUCgOyn4pmQ8UOPgJmOSXCKt5JkIVQZvS5wzqI1Zk/TDtUB7WuEvPW
0RFMnsZbQvQcmAQlgpnr+6WIKp73SOqkw+Np/S8mYBHZ/iu1knNxDAjVxFambmhcneM6UZk4Zh5L
Je5kkkLSvVDnS3E+/H3pEzLTbMulC/NkD6WESAjRqE9kkjJhPxXq+8jCBqRfOU8uHxNNE1bYswK/
zN0klBGM6KcDS4gn+vZjqOe19Hu2l1LvTqI96nwqa0xGnEWHNZ88rBeNOHM7Qeh4nLEPoMxsgTLM
LC8uXeGLMSoHbpaFj1HeQXZldtPHO34Yn+7/fwsQ9xj9fLcs8AuVxbnVUvAMvjmvbsw0LByiJpwz
uUjLCLHT47OQ0mZRhjh1Kn0CEbS9nWvjKo58cAKn80ASYqAb4ZUAyk4wZVp9g0aCtoad/PkDKpZ9
b0GRgYVz35dS5exwqP/f/R04jv8o5b13fqc1xw7H2+ju7zy3TDrlX+7+UA6u/0r+yelrtCUGuAfg
lqAgt1J2UlXwOJgmaMYtCQNih1WU1IcqzXC7+ABDGl8zpLhii9jntqDHV4o4D18WfWaBAj36yUbI
Q3TsZLwRSaEQUmBH/pwQ3iNjd48L3T04ZocD63OHYIoYHo6Dm+fnUn19fXgYQeKIPmGRSlnaCGoA
om4R82C5U3RinnA5A+UFFgHz9WgGpBW7bG5BB65O85Az6Yko+en3faOnkakjX7BX4NSkpY4W/NpP
V8INp1wwQ8Bsy2YHjovCa7uSkVwa3bolQtTrCsEYNha5Sh/DB5Oo4ZkgwIhY77hULnElVACnH35K
gEOs3cdrwCEgzXcsN9uGc1JRH1OBQpqfbhp+32Rc1Bk+jNalxQ1paG3nDdcoNiZRXObijY9SsndT
pKRkNtraFn2AEdzOJKihDNczexz8TbHyKYjZdtdi7FJRlOftdZh4eNKTmrASPENSm1aOZuA6N3fw
rEHF5+qAl+Hg44HFvC4ctigb/sgRAXpL4YgSKdQG8iU+UO6RpQqHhqWYjKop3Fkocmb+RyFWVgqN
LWlO6puMZsruct9H6naL38uSxrWcY8BdeNAwm4Sh6NGROANq4IDZw4i8obrJtOVb158c5x/WTdOT
YuB+lFSbhvlo232mWwv7re05rQKrLnUHLoOUJ4blPZgLrgprFTPdbVpKs8sjhYWhsoY3srYcAqSI
eVvBeOowXRdfiIzkCUJnRBjmZSu3rIqW3XW+i5OfAsPh4hGKwGzqicxH0ifg0arKLWtsnkv7AiBY
Jf/j/iWV1FrRxBqSyyxjxrEIVCtSO/XRFVtQsYPspkd+LqgQs6TjFvxQFBYViOCLns4ZYjr90ahc
gU177NYYk9nOVUxl++3vSmT1W/6MaN/AyfAYcv/XW6571iusE3PeIYjUV8q0OtjM2wQ6IcEgBLpP
tCROar3sXc+oLsejVm/sqvYzHSzw0T278/ghbcoLD23ZOIn5pe7QXw5If7k68GC8YVMjh3pIzJAc
kkacUYF5xclfDMSWRDQISK6roVAGhbBIdgEx93VVoGi8vL2aL+hI7mpDjq/Ui61VMnFQrcJV5lVC
OOqhKHGKklTj8PcxBOCEAuad5TUsd3bzioBPMg/vs0so2Icv8iSWVuoRj5z4jLCRLXrBaMobRUVz
lQeOXhbi/Of6TjLTmTwoJe2WM279rAUwL7jMjCumO3G5hwIVpAPq9T2hWicHD0IpIxF4fNtKKW4E
xl/aIQr3MqAUKGrlbmRdBWINtV2v/wiYE8QVgZ6LKvYjeE39mr7ju0+qhcI6umni+hrzHFAntaSK
Os57oSGcn2NbHB5m3hmV1ErxBQnkWTzv0nVCveICcO9ShyhAoNJTP8JwcnWRU0uZ57Tjgi+5QthW
bz2AoVkVt6J8qnKvSHUM9CJ6h/XmFZBYyChfyeCWTYXqMlyz/2MB+UPrN13NGOjPUM1f09qE6hY2
jCweOzaabb6OnJdSTzZ5S027IyDAP0OFoIuWVasDalpLXhx8VUjpbVXZfaV7pTVv2nO1F/1DaflQ
UBn1nDgmc+PP0P5WeYwaRwZi9mGoqSKjhkdupXa4Uj+6dwlgFk69y4QH7Go6nOWy3DLTMLOp8xjD
uBnBtkgCVBS7YkBym9QDK91ENQt+y7dlkqsSxwAyRdLdGApoiqQ8ELmj+dFINz2yxuaoczIMcAR/
pm2wOz4KSZ7CdJQHe026WULXn2kpZNnO/iGu58JimhDk9Oe/7jqfU8z6eVQ1fng8TEUH77gJ3jiN
xfOxzOTwWF6M50y5cCZJtdFcgngzaKJezkWtutShYrvb3h87QOmIzovOXvS0E+6jPwv8hqF8/yoF
m2EhO1GHDr5hJoxUFtxWovHYtNhCnRM76aICkEZ+WXFEzp8FOnJVhyjPUN2pOrL5VsO/GOUh0/xw
4igf+5YBmvakjWnnd98EtYGOvqvfCdFxeKRbzP/JsojIofAEd+kKD5PxbHLjMIWy2wjo1Vy3Iq0y
LdJpqUJBKEjd1IDd1xKYIcDv2w3nnLjD+bm4gsq/AZWLKIksWrijT0zFKLWUC837HFbfKjVmRDX3
SKhPD12Ey3lIkEjPgWKBXIFk04CPnatRn/ltKHf2daJUcXkJdSWk9UMZW+6AX4ZvTTSRYqEOl2xM
s56UyAuuIuLXHxoVLaSV7fLlq6LiB4xGI0lOCo7dL+IvrrPVlGkSCUQ5WaUFEEQAy41oy13X8bpW
SCPOngZgorUSCTuvCWmzs8FmTgF1mUKYdUzxaZQRCPLJQjkec9w3YG92rwdvWGREyy0BkvaWqpoB
ci3Z8L7O6x7cHt8GpTfmvCivnMR6+FW+7gi1zeVmlh2raBghh4AjUTEI0I3rK+tdG35ouvx9E0HA
assXB9CF52dbLmwzcNxk1qzNZdlrRUVTw2StcBEHpjZjZniRfNGA2G+TXyAmZqVKjTJZskZa5N4E
Ziyb+UIPRqeR4dGLPn/ai8tNNAb4h1l460w0D3vA4ZRdBWYT/FFiHrDsglJKDHD0YfiOE86sFiHW
iQ2EKX1TH1JzkbrynqW88fhIrcg3rFMht6LvzXdVihKK3IDB23GyblLQ1NTt2eDuz525JmVIA14m
4UrRy284zYADGxIeWTiTstfClqOdnft1Rk4mDWoWHYebQoKhrpaSBo0xIFGtRwIon1N7ZZ/rbSIr
H9qntr903bYU9ZBahyaPiqZIdUUNGr1GKNrQGa5prXaeOwubTA6D+AlreAp+UkUyUMTyVItgwJj3
M3Z3y9LzFpWIEPNyMkCFGdv1OuqjLftZxhfDVlXHer3Zyj77eJUoOR7TXXIf3lDUcECtylPHFq9x
M2m9b1K3pvLtBEKNA+3bJAYfoRELzRvf0Q9VnLq9kgso1VHMlj9iL41lwChVmowZsflY5Do8q4FU
c2VFvo/RMtoVzRZLRS6PAZ7Ulh2j71b6+bpQMzQywsH0UK7FD8oi74XPyCmWS55gUZn6KpYUsUmt
K7ke2J2sYUZ6ZaTRTKuUSaHzg2c+TVwtfnCpqHlmhnwTAIMoba2xL3wapYCJOVfHwHgTQm6mbUAq
S7qYcGBUDiXFpg/JH2ONIuJd1e2Ef2wuQxjXrvEArKHH84FZEon/av5QYNiT49EYfr3n8wjolX6G
InrNSCTl0yIpkUZT0IUHTfeRDuGjKdMymcBLztDPY8FXRHmSQwtnUFUubmlCSgY7INoP13LfxFWw
OxPkG09hElY3Nib2WBKTxtm4tbFTdO5t5EH+5DO4WULF9J/UDl4R26xh3fIZI4aJKwR9EpUYAFvX
gEE1Wk+ub2/Vz7duSIXN4CpwFfPeHpdVm49ChdMiOqLSN0shVAaRUqBcWwV8EpCjohZAArDIudzR
igbMDZVeB2jh9Ha3KqFTwtzo5GrDEwTeVdJL+RKOjhWdKfuCXLJbVpIb49Ir37Jn4pKG7q6FarlG
hFYXQp0vSRNt7PZm7wvgQ4VWpMUug/AL2kEfNJ2kMHPUjKYi7fxFCNIcBFLGQs3i3jJP1P00XBSX
J+G6ECjFbHcI60s8PBOZ7OZEO3yNWO3vkLWafpWWEpTNYB0mPCKuLR2JCX55wummgSX2tln+v3jX
vKdZXpl0lQ0ak9ViX9ui2jnz4YEZmQ/PPzRP3gv/9jry6aFfDyR4cM9Qzyb6jPyGbzGnX9yP1v1I
ifZMfnx069HlTP4OxHmh3I66iEg2TWaNEfE08yE97KEMefBcfrRXZJ39K74i2/5henjYcECDnJvw
gZS4mMbukdjgNxlkjeAngnmo958fvEJtDX6GVj7LD+6KUtqfvUS9908iMZJKGdFMlsUKpTW6rlnm
fujTfaYodxZX7FWYl+u5d8/Mca2hEuBYLlOJs92l0jbXwOl2rSVei1bqEZ6OSyhy7SxuSW5i9wZ6
UohKU+ehm9ZwrECLXq+JpWsVVh6h1C+tOWX7Fm0pNiSeZwJHYv01euhRR8Se6EPFsYI0aM1uYUoc
SCfme0YdFNdU25D4ylaciNnf/Dr3KPgUqk2/68olmNInxw9t98medp9Yu8Ofs8x0kn+jfUzKW9BM
/ymXUHx+9ORXUOvsp+Caj13kgxeiqyny5Iaq8DVWHf/CZ7JTRSeC993raHim2fZe7UFRF1F71ox4
/Cfb6VHHUYvSG8pKhlZ13ij9IY1L19EoEs0MdNFr3YY6WbgiZt/wBidUq7w+9HX7yleySZgYH1Tl
83OguQZ11ceaYsz8QiWOu19/ROcj7MjUQbuLld59WwoZD/MlrjysQ31q+bfneffyKH0vHZIdMazm
H/O7uqGtNTh0ZC7dOa59RAkM5j8FQcJw/iOI4ZcjoOgfQZBHTnWc97F/gf4R4xlwexvOXmTsWYJw
H5+we2DuZynMfbAb7/04gbtPrN69DaS49wGtR0bn6yhL8zUJ/+fB5fMFfIRWzmNc95EDDlLtkR01
VuLSQy0lVO3fFbdt5u/WZndWxa7nmVbtkrszfObrRjzTcb63pLF+0TZXrs7klnGp51j7sdhdz6JQ
eD2p692221v+xxxaVhOFYTtqs52f6znzVXykGKlWmY7K6tJ+M+AI0ERcu94cXOxP4+/mnMM0j2ul
1kaM4FK0tiRBx+zk8I707jU37VaSds0T7q0/akyxRNBLpcJusDdZzUrCwYakLS6cD7YJRP5GHEu+
yoyU3/bQ6AR0y02O6RsFjUPhJ3reeCt55OYK0xYSyvRsK/WuhlPRqip581o/fvX8u3dxiNTn08nQ
OKxtPXPoLur4/Pw52BIqZTLeRmw4KchmGRCRkR1VH5f6UQEv4LeweVjeffP8FYay2qkfgt1jYlOb
A8J+HniaPYWFGlqxq3VcVdYTjAuhjCJvWFOb+pduKfknWtcjxbiby2W8prg/tW0WxUJgzxyE6pDv
dcFQNxnG/tIgUUtyuxCHD8NQEVjpfPVPgb7JtdHD6kQS27IYupa5Q3xDLzNTFFmcby9gbkFqyua/
5Wz1dTa6/pZOblQsVpBYvV7WqXFFO3/+ZiG5UTZTY8t7MnUge2oAnExVSQOmN4YImLosoYZt6ay+
l0cWhUhzl2mHhuU4ui3qq+NZXNeUieETiNU1AT9fVAe5azIZiFfWYVLGN0aJn5iL/FuZqoBCRFwA
3so2K3C99zAbcJ62DS+Uv3Mm7VVvY4WfRq50CXURmF0FBI/AlE7UEbDfHXzEtRcGdyPu8wrv1fRH
SDKfDDhVYcOu95g4lIrXlPJ4emeOvykkHIzoDKtzvGwNTchhKwk4Y3E6FboJHZOrzcYLoT1OLISN
xReYkZSZ8RBtRqtmueOKaQKUDCWtpUi4lIsTKPtJjFyHx0QaZYTqz8gD8C2wdf3AO3nD53df5IkL
igJP19KuaIgP0o4ZhAr8K76yB/AB37Zg0QV8PphoPOqku/fO36EBBQkX1NG7EhQt16JniF84wDND
WhqHCePmOEUkch2H70/zix3XqO1V21uAc/eaQSyXAY5a6pCSQufcwxiikoPUYuUKj+lC6dFm4xbN
6jZ3VedOAl3E9QL9dK72O/+dmRcdzE/FCzFIjJ6OkEVbECW/Qx/31HChRjw8MyCjFoogl6NkG4Jz
h1xAFYQW7Dwo4I/Oi5d9/hpuwclclNdyk2LyvXLgshZYkYXCZVg+eXQtEQCuv9uWq6SFSGHSnXkT
ueyDpgJkZIBsp/Ez+o+kZwjFLVD86KP4sCMl76RlKiZ6B+1wMcncxNMgSHoqV6DYsTxQnf3AK8Da
EQvC+EMmb980EddMxUocF425acrl/a0dbUhXTEPoLZ1iPrYihC8VlMmqk+4lYyZti3AiF1dUoCHJ
ri7OSvTqJJDpE7Vs5p7fzk9fs60xQgGEN7S2rNw2J5GeNIfFxhqBzBR9suykdiTDaGA88axxYQSS
FqMb7/anJP099hpcqftaeBDjP5Lf+wa5JCp7Rnktk5xjz5/H50QlQ/g5wmv/QYtu4gsyS693YgQl
C6tSsClkJxlHL7XKM2evM8OWKgNyTBH45g/HtBtMxQ+isRp0Axst8CvuJJB8tDesKa3DMfHxfaxk
sFWswWcCoGAT4DZNoGDYifd2zw2eYhwV1NFGQoFEDuL60KuVIYmgSQqkZdaBJdAWND9jNlQw0AhK
aOWoYFY3eVDIIccvObE6V7fifoj94+D4OqQ3u+HW0ZIrm7GiE/grV4v/OMFPteRG7CDBR7Oo2oHk
vg3YrTb6DrXfDS+aiMYg3ex2JdfxlRGyb6fLr9nq44biYSTN3x6ghXtHWm7IGlOooty+GHKQFTce
KbiMiHrCFRIfhgJ6BHon3Mg60XROTWvnE8l7d45lwOvsurGD/GD06Gchqx7I6PyGfMVZagxCXilA
2lw4ZedVULm2pZYcPb83tML6EAfntyy0aNWclQvOpC5g4sVQD92UfpfyJ3bEsHid4E337IC/W37u
Y5ZmWN8qzelJiQ85A3/mSnVvr+vwXB9yX9yeq+Komyh5U1zIfJ+Y86XDeVRJKUG+kTMAU6J1Ht4m
Z5xkxGG7frfka9a9b1RHO5fCSiIhg5vK8yhV/IOcE58W1x5Urd0uJ5/rlUt8DVRkLaHMOCc2cdam
8DXOX1KuEjnndl3qlJNlHUjOJLE3sZGiInlWC4arJ4hJ9vDtFomGuECln7rJjKGX+OROhmxa9StO
fQHQScvZYn3k2jdfUmG0e/TG9NiXBr+8pER5olleDUrd61mP9HRl8/CKfyJ34sV1LrJhNTYr1zKp
Y0fPzHcy7RPi5MrRGA4ZLn+odZqkZ3NtPew6xr13Me67aHFs0oyL8iYlLXR1EI1izPQKTmVLds/G
9k/IeZfrAX3x44FKmNQtPe31koUl5HTY/lZjxZbxh13JyTj0yf/Wv2rgiXMhkN7JN1PhVtzYXxl8
vyz1OY2L1bau91lCi9vYHRvQ91o3hjNUQv2X1CwSt5AEeejAkX3ECHwDTUbYb56CL8xEj+pZzIhK
u7TI2QLUE/Gb9CaJ2B8nSj9nZBjf5AsyVy73OhT78fXGR06gmEqSGw5bi8naKbRrCfL4BPAN1eZB
tku36lu9kyvHPQ3SNz7kC9ruMFTRzgnKFZFQKN21Ip/AaCUcworcGXClc92iwQUZpLKoCfJCxiaT
+XuSU69ZCODTehu7XevrKR1xBIxvrkGGEUuIecE/smRE7CJtMAgJVnkkkSo/4jnjS6xx1BIJu5jS
gTUr8IkE2yNjeT7ltAlgqcny6//3YOCSh0LCnC4ac5+OOEnB1hmw5t+svUII8TKzK7kmolKmz+1T
6KK7r5gsexnQwTHO70F+xgeA/6Hy3popFgv4btgGJJZy/IMUdI5aLXrhC8iGmEU7Wmol40VryyC/
vF+rhm12saEuXRdxcF5PMD++oUZAE7jEq7fEZmvP94Xa0fwtJ6hIMvBSU2BuqSmEAF17WWynHMbW
HF/BgESqYqukKPjW6rTMBWYlob5mSWTkcLBoTejb2vKmNNlcbknEO0k93gfHqzJvtvmTA3WW8WnL
i+7KT2M2JJt4dfliyaKWDNbOOUnrs+JaVmaj4esnZM1Ris579qm9gycHCk5UwFvYrKO97hX94x9G
5pUp/Cqz+SyNjNVEpx/YE3puppylo0/NiJMNO3qOSEehm6tAFgLusPIXHh6amcXQCr6XKNSCWMjV
VxMtrkpOxuTkDyuIN5KZys74JifVwhO5PW7WVLLhFB/mubvTNTBF7e3++/XScWkFRmJPqJCOiYgi
Z5eSSipDxfuKi98ByLkWC/Q2dyvW6kajuA8YNfxzJC6lYW0IT5OyPo7pkx8eRaGOCGj6S1tNUj/1
6ofJlierS5T1vqbv8MXe4+26q819g0urbZrg5pqUqCiZxiTWZimDE5puOmMmU/pnXjGMnJhRC7fI
0VUL26RNamnby697X5qXN6WkRooCNhUIG5d++ln3zDyiqBS/fYdSlxJdTfRIbROdS3TJRu8DUs1x
8GGkw0JgWjEaDmB4ZVb8eoMvU6V9rcqWuZMkoXikDw/agJ7ItW9MLeYhR5oUrSdqJ7mUS/7i9MR7
HYD7YnR7ur/fFzjsP3gGJ3t53B6J/XPyYP+7kZ1xbEhY9VaxAB9cg2jZ//7aiDaYsUir01ssed18
Vcc7yw3z9x53yeMQWzrBW74Nt46K4eFxgPTLPP9fjLLjB6KsqsSw2qTP28KH2r9Uk+4nmOuutau8
JVgz81dpiwIIS2ALZ1VrqWdb0mB6xixxSVEYcZkKplm4DTJOG4suah6q0HO7TjXcZZ1F0Q4pLWRG
fRejDjRnEISceb9XZHIj/pQZ3wu1vHC6ohtcuddB9bRls+OkyHUu7h9/62GbSVafXT4Ni0/qI5QR
BMdPRIzspEZIHMnJMDcDvKaFRNhuZx1q3DBYhMEjjC5ZXDtOstm9Cr4panG+2Bs8Hcz5C9RWw5Qh
YJwvFTejgWHTXIgK5Yc2qEsD+t5IhQOWRddNJZXyx5eY52d2Td9LV++ADLZ7HzcbVPKX2zmdwEXW
BlYs9B4auZubrNh6l6jUXb7r5c74dHXtOy3vFl1pTswTXj6vjI4G23Vus6jsnLwpgeeg0X7jLx1H
zFI9lwkkyhc24ELCkmxa8n5liBXXU+H6ZXbb+ku9bfvzz//b+E+4kx2v5RNv8J8HXlX4gIvr7r9k
7QHXij3uGq2HX//0mFt2HnUfyIOvxXjY5Q+Puatgoj7/A8p57y3AO8zKvbtQ3n2l3+4oMTZdJWIv
LnMvTvAutMm0f3yPj2zyEnu5TwFnWw/2cz7uwP3yX2aSkPD8JX20KWahmGQoMNWKCQsT07E3T6LW
cZ37Wcaud6k4x64kLZ+2wbfKzaHAu0XTiMeWzN2C/V9I/WbQC/ulSFqxyZ986O3ZRh25WvFDbs06
P3/mqqrjzAK2Bl8U79x33lubRcUuw8cQw7sF7v6Iq5by51F6s48ZiK3KAnmpjlK4XbsbFNci4wMd
Ct6MJveSpEBjN4R14T0u+CRtiVwmZaG/rQRl59mm3eNahQI0fdFdzWQGTKpEjFrhCjI1M62k5Wzk
CRUHE+XoGXutV+pTwDUgtdEvi7zdp1oLHvkfvnjWi7KXitlvtHYom2WluNzia9IKxI6ktrzdA1hs
tpcwwVmeed3FKnnXBgyxIfC1vbqBgZXKwoMYtdCzq7kzl1mom1DXrHoJTeQ2h51cwmyOGI1v+MJv
otAx+h2mIIxN/EiasFuIJLLqO9AARP8KFDNlUnQotFSueAShGK2pU+qbltuP49tLmCr97dYJrN4f
gP8AQS2c4m4xLe/cI6T/PeJDU9uHNMg3tjX05vN/9Fyt/7tnm4zyzvmGCZ/dkqr2Mf/GcO6YxZf+
Bg5AooSE34I9vaCjUxGXlBomHNaTMM+6dQ6H/rooK95SODii7L0soKqDHbwMx56ahWqO8k6q52fs
oekUBGUw3Rm/VglYi16WwV7Gg213lRR2W+xKxH7Wa2zNh08QIzutOYmJl/pF2W1pclDnVful7reT
Xcv9KvqpF1JMEOGgQPtm5mXgypq8xMxsQu4LDt7Zi9OXzyU/7QZXMv4qMlJwzKHHZ5ccoOpOfsHs
zt48/ZJmJ5goHszTasX1lFcu6SwvpQD1qjlJBPXZuz+xYMDOEIl2hqnKWnsp7l//lm1a/3tyJC4E
6qaV3iKjLgriP0/cql0IR0A/IDsoVJYTcQbGhmQru+ADkN2FwGmtCqrWxSP2KLcrVGHhsnVbEp+H
gYdr7XkFe87jssI6PlC+iyaGB4zYZk96014xdmlwG8qLplhFn8zZAXbiOM3pKyIoqIYUKGPXP/0/
lIEXzdnFAAA=
--=-=-=--

\start
Date: Wed, 23 May 2007 23:39:42 +1000
From: Alasdair McAndrew
To: list
Subject: Summing over a list

------=_Part_3986_10453830.1179927582971

Given two lists,for example:

z:=[1,2,3,4,5,6]
w:=[1,0,0,1,1,1]

it seems that the sum of the pairwise product is obtained by

reduce(+,[z.i*w.i for i in 1..6])

which is all very well.  But why doesn't

sum(z.i*w.i,i=1..6)

work?  I mean, sum(i^2,i=1..6) is fine.

\start
Date: Wed, 23 May 2007 23:50:52 +1000
From: Alasdair McAndrew
To: list
Subject: Changing a variable type?

In experimenting with the Chor-Rivest knapsack cryptosystem, I have the
problem of adding two polynomials: one is the defining polynomial of the
field, and the other is a field element.

But the command

definingPolynomial()$F+u

produces the error

 >> Error detected within library code:
   coerce: element doesn't belong to smaller field

which I don't understand.  What I need to do is to force u to be treated as
an "ordinary" polynomial, rather than as a field element...

\start
Date: 23 May 2007 09:54:59 -0500
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: re: Boot, Virtual Machine

Stephen Wilson writes:

[...]

| I figured that since you are deeply involved in developing Boot that
| an `interesting' example would roll off the tip of your tongue. Sorry.

I'm driven by application:  I've seen code converted from Boot to Lisp
on the ground that Lisp was more powerful.  Yet, in the code
converted, no additional strength of Lisp was used.  

Now, if the contest is show me the more powerful language, then I
believe we are alking of something else.

\start
Date: Wed, 23 May 2007 17:15:58 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: Boot, Virtual Machine

> Stephen Wilson writes:
> 
> [...]
> 
> | I figured that since you are deeply involved in developing Boot that
> | an `interesting' example would roll off the tip of your tongue. Sorry.
> 
> I'm driven by application:  I've seen code converted from Boot to Lisp
> on the ground that Lisp was more powerful.  Yet, in the code
> converted, no additional strength of Lisp was used.  
>

Most of "converted" code is simply output of the Boot translator.
It is clear that such code can not use features absent in Boot.

There is a few snippets which were really converted to work around
limitations of Boot.  In fact I yesterday commited one such
snippet:  I needed double precision numeric constants, but both
old Boot and Shoe were mangling them.

Most of limitations affecting practical code is rather silly and
we should simply remove them.

\start
Date: Wed, 23 May 2007 08:20:12 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey
Subject: Re: [ANN] new version of axiom mode for emacs.
Cc: Alasdair McAndrew

--- Martin Rubey wrote:

> Dear all,
> 
> after a day of hacking and with some help from Cliff and Jay (many
> thanks!) I have a new version of axiom.el, which you find attached. 

SWEEET!  Thanks Martin!

> I'd be extremely grateful for feedback! 

I'll test it on my home machine tonight.
 
> M-x axiom 
> starts an axiom session or returns to an already started one.  We
> really should provide functionality to have several sessions in 
> parallel, but I don't know how to do this.

I didn't either, when I worked on it :-(.  I think it involves tracking
number of buffers and process IDs of various Axioms or some such...

>   * I fixed bugs that positioned point incorrectly and screwed up
> overwriting old output.  Cliff: you said you fixed that already 
> once.  Could you see whether you had a different axiom.el.pamphlet
> than provided on MathAction?

Sure.  Your solution may be more robust than mine, or perhaps the
version I have on my machine doesn't match the latest on the wiki...

> ToDo:
> 
> * Testing: does it work with xemacs? does it work under MSwindows?

It used to work under Windows (with AXIOMsys), at least the one time I
was able to test it (except for the overlay mechanism used to turn
input red - that worked partially but only was completely correct in
the latest cvs development version of Emacs for Windows...)
 
> * the way we deal with system commands like )quit is unsatisfactory
> for two reasons:
> 
>   - we do not allow user interaction: )quit will quit without asking,
> but worse, )di op 1 will make emacs appear to hang. C-g get's
> everything back to normal.  Reason: )di op 1 will make axiom ask
> whether we really want a long list of operations.

I forced quit to avoid having to hack up a way to handle it cleanly if
someone typed )quit somewhere other than the final input line, IIRC.  I
have no idea how to deal cleanly with ) style commands - the current
mode uses string matching, which is quite simply a hack.

>   - (1+x)q will be parsed as )quit.  We do not check yet whether the
> first non-white space character is the open parenthesis.

Opps.

> * the underscore character does not work.  It should...
> 
> * the way we wait for output looks extremely dangerous to me:

Absolutely agree, I would very much appreciate a better way if anyone
knows one.

>   what if output contains ") -> " and we are unlucky?  Not sure
> whether this is a problem though.  In all other places, instead
> of ") -> " the regular expression axiom-prompt is used.  Shouldn't
> we do this here, too? 

That should be OK, but it wouldn't solve the "output contains ) -> "
problem.  That is not solvable in any reasonable way unless you want to
track column position in the regexp, and I'm not sure how to do that in
Elisp - maybe search for #\Newline(****) -> somehow?  Ironically, the
cl-web style buffer processing would actually be useful here. The best
way would be a communications protocol and buffer behavior that doesn't
rely on these kind of regexp hacks at all.

> Isn't there a simpler way to look for output?

Probably, but as you are no doubt gathering I don't know enough about
Emacs to be able to say :-(.
 
>   In fact, it might make sense to keep the current output number in a
> variable -- that way we could also detect errors.

That would also be nice, but at the time I couldn't figure out how to
store buffer contents in variables.  (Silly, I know.)  I think Jay may
have pointed out how to do that at some point...

> * It would be nice to give the output a different face, as in
> mmm-mode, but I'm a bit lazy.  Maybe today evening.

That would be nice.

> * S-return should overwrite old output while return should copy the
> input line at point and evaluate it at the bottom of the buffer.

Heh - I guess I have opposite expectations for behavior - I expect
basic arrow keys to move me to inputs and return to overwrite ;-).  No
problem, key bindings are easy to change if documented.

> * it would be extremely nice to have command tab-completion, as when
> starting axiom in a shell.  (The polymake team would like to have
> this, for example.) Anybody knows how to go about this?

Erm.  SLIME does it for Lisp, but I have no idea how.

> * undo should have sane behaviour, whatever that is.  Possibly, it
> should be restricted to the current input, but that might be too
> restrictive. (For example, if one has overwritten some important 
> output by accident.)

That's a point. Hmm.

> * cleanup is certainly necessary.  I don't know elisp well enough.

Neither do I :-(.

>   It is extremely important that this mode works reliably, and as it
>   is currently, I wouldn't be surprised if it would screw up in weird
>   circumstances.

Indeed.  However, it's original ambitions were rather modest :-).  I
don't expect most of the current design to scale, but I have no idea
how to make the Emacs behavior more robust.  Personally I'd be more
interested in using LTK or McCLIM to make exactly what we need, but
that's a ways off - for now, it's Emacs or nothing :-/.

\start
Date: Wed, 23 May 2007 10:40:17 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: Boot, Virtual Machine
Cc: list

On Wed, 23 May 2007, Waldek Hebisch wrote:

| There is a few snippets which were really converted to work around
| limitations of Boot.  In fact I yesterday commited one such
| snippet:  I needed double precision numeric constants, but both
| old Boot and Shoe were mangling them.

Please, be more specific. Show the codes so that we know how to deal 
with them.  I've have lots of emails coming in (over thousand) per day
I don't necessary go into great depth into every program generated emails.

| Most of limitations affecting practical code is rather silly and
| we should simply remove them.

Please, explicitly list those you know of, with examples when appropriate.

\start
Date: 23 May 2007 17:44:37 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: [ANN] new version of axiom mode for emacs.
Cc: Alasdair McAndrew

--=-=-=

Below is the next version.  It colors output green.

After having done this, it occurred to me that it might make more sense to
color *input* green, but I don't know.

Cliff Yapp writes:

> --- Martin Rubey wrote:

> Sure.  Your solution may be more robust than mine, or perhaps the
> version I have on my machine doesn't match the latest on the wiki...

Please send me your version, so I can do a diff.

> >   what if output contains ") -> " and we are unlucky?  Not sure
> > whether this is a problem though.  In all other places, instead
> > of ") -> " the regular expression axiom-prompt is used.  Shouldn't
> > we do this here, too? 
> 
> That should be OK, but it wouldn't solve the "output contains ) -> "
> problem.  That is not solvable in any reasonable way unless you want to
> track column position in the regexp, 

That wouldn't solve it, since something looking like an axiom prompt could
accidentally occur also in the first column.  I think we should keep the
current input number in a variable n and look for "(n) -> " and "(n+1) -> " in
the first column.  That shouldn't be hard?

> I don't expect most of the current design to scale, but I have no idea how to
> make the Emacs behavior more robust.  

In principle, it's not so hard: I believe the main problem with the current
version is that point is jumping around like insane (start the elisp source
debugger and hit t), and it's not clear at all what each function expects, and
what it has as result.

A particularly curious bug (at least in the new version) is as follows:

  enter 7 at the prompt move two lines up and two columns right, i.e., position
  the cursor right next to the 7 in the output.  Hold shift and move the cursor
  down right right right up.

In my emacs, a line is inserted, which vanishes if I go on painting or enter
something at the prompt.  Maybe it's a redisplay problem, but I was unable to
fix it.

> Personally I'd be more interested in using LTK or McCLIM to make exactly what
> we need, but that's a ways off - for now, it's Emacs or nothing :-/.

But you see, I want to copy output from axiom into gnus, using M-w and C-y.

Martin

--=-=-=

H4sICDhcVEYAA2F4aW9tLmVsLnBhbXBobGV0ANV9+3PbRrbmz4O/AqW9dyXdIZU4qdmtSSapcRwn
0a5faznrpOLMCiSbEkYgwACgZE0q//ue7zz6AYKUlGRn57rundgE0I/T3ef5ndPvFs18s3J1P6+K
rvu5aPtyXrlf8uzdpnPrYn5VXLifi/dls/ol+/fs3/P8RdO7vKzzddvMXdeV9UXeX5Zdbu3k07xv
8HSxmTt65HJXld06X5aVm+TtpkYj+HnZVFVzg+/nzWpV1ItPpIO66Yv6onI593riqpN1sVpfVq7P
P/e/yatvQkdF/qx4477zw9CupMEbN9tuTR7eXJbzy/ymrKrQlL3Zu/f00ruZuyjrn63hX7J3fdlX
7ud3/3b26vGXH3Tt/AO3KuadfLdqFo6+BQGLTX/ZtD//j+I2/8JVNCfXTvKv2qKeN0Sv50XVu9sJ
/ZdIXuevNzN3mxMV8idVuVzm3xfrNXW1Kq4cd2fDKGZd3xZzGkaeP+Vuqa2mdnmzZKqumq7P1816
UxVt7urrsm1qDLsjerf5wl27qlmD6Ohqg+Wjhrpm2d8UrTvJ88erhh6W9D4tCQ1oVlZlXzrqps/n
RU0r37t2WRCZbsr+Mnfv6Z91wcS7aItVR62hZfrndblw/HpVlRfYGN1t3Rfv88vy4pJ+uewxCgyq
oKbo1euiLV1/i4mAWBvaeN0JNfcGu+umaa8wUxpB0fdute6xy0AdmgRPvogbMAIIhXQb29gWblkS
wagpeRxRKe83tVvk3drNy2U5L6rqFv3QySiJrI+xwOivxUAWaI6XmIb5ztWLaG3eub+7eU87pZhV
rlnOGyIDrYH9nr3r6D9lU//8pFnftiAGj+xZOXd152hts2/rqryS83NdUN+r4u9NW8rseBwT3bpE
lEo+o/WsF67lb543C5oA/fTF2ZeZPp/IQZVJY5/u+PbrV89OlOz0f+u2XBFhiRCLDY2nyXhIrr2l
VWovHB3eqpLJ8CosFiX+Tjsi9NNRswXNsOXFWviVw3CymPoFdUeHtV1uKvydtlxJtM3+8pe5kenz
zz/LPv00D2Q7enKcP/rzn/80yT/68MP/xv/73/PZbX6vU4emxg5e9ld0qqTRLpkeustBl2XrnD84
n+a3zYbPR+sWtFXacrYBm+Rl/aBp0cAKS3KL3wKp6fCsOju6X7/4Nv/a1a4l4r3azKh72xBEDLSw
xo/dJVGQJogvvsIYznQM+VcNNVyA+p/mjg4n9UHr1GFlPqI+0AI+ema7gY7eES0LjbzNmzW+O85x
5quiD5+e4DP/Z4wQYb4LyAV0cdmsnaw5zZZ568zhU1p9WtpJTi/nb0/ffPPy2zf54xff528fv379
+MWb7z9lptLQU+JT0lS5Wle0j/E1TZKWUY7A86evn3xDnzz+4vTZ6ZvvMZevTt+8eHp2ln/18nX+
OH/1+PWb0yffPnv8Gp+++vb1q5dnT2lbnzl3F7HBk1YNEXTh+qKsum0SfE+L3dE4q0V+WVw7WvS5
K69p/kWOnbp7QfGxX9MKnJa5aB+R9NO8XEIG0vmm844T55caX4+s9iQ/recnk/xPf87fEGckyfmq
IgY9yc82aODjjz+c5F+QWKA30cLzx/mHHz169Gj66GM6Kt+ePc6yv+aZZ1nGmU7rnuUhn+ypnmYc
k8eiDGRvaIM5PtTbDDw++8U1ERF8kMQUT+Vt0xLh3uKTt26mfCwziVEIv8Nac1NLV/Sb1on8IlbR
b5grY6P2RUdCYVWQXET7Jr2IQzWdjKyjfQTqC6vE+ZzRgzVvKaPs/JIadMQn+CBC0JS2LjzVTzKT
vUTNVfkPYs/v8Lf8HekH/Wz582q1mmKqvxCZ+HAwby2g3XTcg0ooOv5LIhnxOSYPiY/zc2br/HV3
eIjjU+SQyRVYw/uelSaa1hdFJ8JowixFWhYai64FylF72K60cRcjgt/33dJUmprnOmcZEPVpOs7J
YIaPN3PSrTA/+RuOPSbW9cQqbLcTR1UdzEEGsGIRM3cMI9XRumE/T5+TDrUqPCEh8EVfuCVWu6af
SDstwGi2JDd1Nm8dP0NHLAO5MWiX6w04WlFduFlLk73tqFOV2X5N4/1cdQ31tyLV9T26pO0Qb2i0
ryJYSM/qVF5vVjPqhRhtUJoi7ZK0hmswctV97fAK9SL9meTds6bhPUj8k17unB0kOnz4uHZu0cV6
gOOdvWiLm3yzppHokSHZTgcpHQ+pbcy2RLmgWTrZAbUqN2GeYds7mhmdot5v/Ce0fxraLvJJBysA
O0rakRZmG+w3nMh8hs2riuSt8P4iv2ga6E9L2ssz0s4wFOakoG1X0hnvuUmh36KpD3Xb8wsk1mcN
BoR/rUgfJGLZVkp3mG3F6Djnpy/DkIvOmqB9s6YdbMKYxuYXhBRt3Up60jpZseWmnouuA70MA5PX
bCinke57SYtXYSB27AYnlLYD6KcrWtbzasPbinSUnAdWzlmhfUamFDF2MjwmwoyrBfWLFq3Xs816
3bS9qPheFBHBrvWse2uqYDkSDSTqmHq9S3VvuDHXTueXRIgrXmfThKMtEyTKm01PKmxR0W+ntZBQ
H2FfElnnpEaobjkjUbKkU39JS057AxxUhKSo8qyfuiyYkGKBqSHZ8SnWxSKzcpR9/8Dm2o/gYVh2
GBbxdoZG0To6RjXzWDyuiL8sbuUD2i5kdNEw3mKr0APIJFUJTJKl+8N2uImk+NjQAkMGiWZE7Z3q
lr8i09VIsGiYArrMPzyfbmgjPJ8umpv6Rzqw1044y3zTduB/ItvWrbsum02H2dQQKGVNvNDaeEJt
fPB8Su084Xbo79TW0vXzS21t//fPp1c/QuEpQ98sYvilKalx9B+syYzkMy8zbSkZ1xVxxGkbju0P
ZzydMx4G/lu5ZY//spL/Y67rEObHLRV8Nuiv01m76S5P4oWdygNYqj9CxLN8Z9YL21VPxcjHsuY/
kgJaVMSFYPjylGlRYFaWmF6ne9+Iw2+waKZlaFltg3RvaC8oEc7Pa9L6qtvDwy2xc9orS6atj5ew
dBekTPIA9fMikt9LVu0K3jemeZxEp+ysb0lp27TimCE9kVSIX2DO/AcMmcSUim0c+nvrftqUpGnx
P5gTnWGrb9b/mxQ7KFjy5NueOfnoj1/plpcf+XMaB7fFv7whe4c2Q0XmqfT5lJ/5f75S3qQ/QC8N
M9M+8i9hv7OV2YnYVsauHikzOOAAEo4nwki8HSKfDplX0GJmR8ozpuzYoCWl/z3OlagxTT7LjvQf
+aF8e5zBTnysgu/WFPhJ6oq4NjoxvzaeICxKPBGisbCYzCAda4dpFMQF/97MOtp5X5Vt17Oc56mp
/4JVgWIV9C8jAhtm8E+IVnYhuhb21SzmirsXme1d/2+x2W8uySDrdEGF4NkRjYSmJz1PlZD5wcFx
nrOdCH2KVTibNfMxUHglE6CHOGZOtIKyF9Umy3f/gQ3L8zDSzdwSptrMYVidI95ko6oaUpnXRX/Z
HeOzb8MsXNHOL+18iDaY48XBhIh0XX4wrZs5cSOd1OlFzQo2N/T4u9OXz+l7TBJEOhk0QLSGo+rg
b0fv3h398OH0zz/+8d274+N8+nl+cDx4Fzt6SuMHebv8iFW3g2P6IV9hM1w4+JqaqimIpyxpNLL5
3rB66D+znb+pS5jvJGVquFp6aL+iSrFpIscF+nUtgpTsDNphWYVV2bG7bHWJ+jhXqqjgWzqeTQ2N
snaxguQy8SnwxluUHVuAaIm2J2nytDaRLxEtg8qJ0mFdouVsI4f/hLukndNqj92GrTnh7a+ffv30
u1emrVC/NJa6h9elNy6RyaJ0NnFSlS4HYy/CZOHC8ETtWOjLISA9u2+yeFqk7cDjIk6x66aiU8fK
pC5fp1SHpn7BPgFSX3kXYU2hcVUlGSfENuDxeqtGCM4DzwP8jvSIfzixSwJTAesQhw2Njw/1Nn/m
82zc03862IDYGdNLsjxIClXD3akcdOSJMd2RR6IGkLQbPrgpWCmf0thNS+iH7xRLmpM+5Q/yRx9+
ON6DGl4HH0aHSjj0tCq6PoxDBkki8NLNr6jz96w1kpzBUYo8w7Sfr11dunoelLgupm0k5hLa+pd5
HJs6pd7RMXG2g9esYPCW0d9JfMjh7LdEGZ1ROm01EWuCwedZg012U3bugNo6wpiP9N11uiDH/oF1
nz4GA0kGqaRelhU201HXtzxc2KLqpa/djag6uZyhk/zM9eKk418xGl1OWZKOB8mbHO1hyYkZ0UQT
9qg90ZvEx34aW9kj/moqTeSP+IvtT0Z2FdZ7a6J4L35JluUtthjmqb8uaXDbCwKDFhuTLKdFNwn6
IPi0WOtkT8GwNbYJznKiZCBFTJZs13izP4iQO6qbHlODmJrCPEZ3JA1YcORHU1padHyc/+mYDo6R
opjP3bq3BbbZDVYdI+lk/vmHu45aRLKym8pLug2VWk9wgrz/YLl3557cuVVN4B+5n8KuhW9p0w03
9SE1ykv6l78oT5RddElUYg1SdZHKFfVmjaOtE6GDvWCrQrfdkVKtddMhoZPdiVMXE4TbYf3Z3nhY
S8N3aSH2dGrudq9AVXQcO+/hAntj/xapzE5PpWlEbN9gm7DTV2NyPanS/IQk17oqbsUvArt22tSI
dZGNh0GQWU+yFh+ewhLmcEWjHpiS7IWWB8MbJxrIZYHoF+ItEP/0MbNf/7O3umSc2CFEA9Kvarj1
rqS/dLok00iy3zSizEVir4yHdd2UHCBo3Vo8gELbE79obJJNdf7Juh3BEXJ01K/WvDnuvx9MIeVP
NRR1v1XVb49w2hJ642T7gTw6tn9K4/TvQ+JJJNOEWLaV9rTjPwz/OEwpfo9GbDBpG7ZdEu4K4UG2
nXESVqrkcAi/6MAphEtcFp3ft1iump1dpgs0kXQE81DucV+GmP1BGChxk3E1QN8+jkefbhETDSqb
jmjgR2Pzs32g26isL8sZcdeEQmGrsBsKLHHaLJPPRxdg79i3NkOe07Qf3giU78NYAQD16JUwwge0
GtYBu3WbCCyOWdn6tobivanptFainNMqFJuqTxQMMR6JoKxE34rHk6zg1Ya4jUXxM1W85+0m8rlh
E7EQECtzs/5kh8j4zDYAvz3drMfYw9i6RkuHOTMvBEHMXGNdM31HOLN6yVZFe6UqtQqFi6ZvmFvq
61MictBzEr5ycPQIm/8gfRpOxvAxKUnjo7SeeDC7B1K8P94t5Q7UtjXDdtDn2KxHu8Uhs4M7Ptpd
7YVDRosJnjKVKNeva2bH/Okp7dxtFeOzVL3U35XzxQpqYioNnkUG1rHEY0M4CvKP44Qi/8SobizS
MuUws/z9KDpJx3xavuMHJ9kXbl7Aic6QCvjay1YsV3am2F8FZVPnMzIzDADg4QkIpTQt3FDZijQH
M031HEpHHjkjQQ6oxCVR3RvbAfG1EGdWBncQ6SS09t95OJM4c9jeZnW568qLWoxxeMQrt7jg4RZe
IRCQyMCs+8xbg6qJTuVJfqQBsnV+KL/I0kYu1NjN9UuWBdN95rz/X9yJCrQAjWiZfABimp+f88oe
HhpQx9VidhMnbYtBcIDDceIYgamHWZ+fm3vp8DBAfQoNp4kvw8cqiCURjV/W+VtSTxEcPip43f70
wccfABdzzK8kDisflp/kXYNFvSnqfrAf4HIi20uBUN2aDmcSnMMOvXHSNgc3rIOTjGGC4j9xGs2w
HcNRDd5R70kvZM+bOAD5zfS1cpl5QiIIkVClNKcmO98YDsg9kjCaSEjJu7L81suM8CwQLlw/TbyX
0XHeembKzBnzP3U5iWKqTsRXj9984/ek19LFMYsgSHt7EA5+8E8SIdx8ir8KXxBTMTz3zA0cEpCA
KT7YMLhsSpxm3tRzmvbRfOD1PPiAuz6IdJCcDayLensMibwKb0c8yjt4rdWk2WF7R/NFMhp9GybF
kkPW8GMRnwSWj0S7yX9aUFvhLamwIUrvGEq2d8DWIo/ZuKtCRBiGRUf3ykX+G4lDJ2yAY33iDCSG
5Fbq91shRKtWzRqMgK0SnIxPBLgGgSkew+kydhulQkMUKnhW1UtEf3v1+uXXrx8/lxiGvGEuIwln
v/76jFlFR/+E+6gh9i7Wtqgt7L89eByT6EjenZKA06aIsNdE16NivWYljj3Ph8Dn6aiMyClR9znp
VdWjztYVvNritwlO9WPbDJH+TVOX0xbmr27qEMGRubHXmBhHec36M22or9UNFfmoiSPg3a0zrF+g
eWYV9klKRkFZ3Gi37L4YLJO286K5IfbZi71dGuxh6JQdFfVHqnrov4+1RQwk8Vqb1lAAvVFVw9bs
MU9Vmgq/DbvQPtjGFubYcXhZF5o3N+lExB/gaQ6ePVWJp3hIokBaMeZO3LAqXesjMonNK0JSxbAf
utJR3oGu5t6vk+90oI8Xi0H0SJcZoxVPJYuAypyUsmXk43jo0EDewg/JCObUwmhmDM1ZTGRG8vGK
lLgODg/TftQihOHKnvmZ40gS8DrYHosFjpScHZ1d4lANZz81t/SxzvetgHtw3MnEoZmw4xvhFQ53
eonC4RrSR4DiJALPhYPxxKQhnTWgbrQ8EmewY6zBKsE1G4yLIxp6GE5sb5sEj0Ir/GUJmOvQDFCi
d8Ausm1PWgJ4JLOqCyhbcK6ystQ3TQUVSZRRrzLK8ko7M0f6RNm0HkxoVvg+KZDF8k39rSw6Ro0W
NpHyH/6W/6jW0pZvJ7+vV/X4eO/wgvj5NSP8zeO6l7+X9N9U7bWlxBmwyLOpiIxFaTYXl7SINxqq
GqiPmQYKAyQn0SWL3nadyFXPPAy0psg3+zxTLgMcRm9Am5maco7jDsqQmKi+V1asz88RSCWFEdpl
02cCB5Gon0YqxLWAOfaXG5u4eTdNN/EKQfTlJBM2Oa82nUBc1O8vswAuYAUHhU6dVL11a8gf7q+k
k0JaMAc5dTBszZjSYFPZ0hmGLww8FkjhGAkte/fjHiPftiY3EjQrcfyKmsmPttQu6ZU1v/EXBoFB
74kbfW08TOjfVDYL56G0GD3bN7nci/NBJOjYa4dvwbMK3gy0xUrgMWyHsmGRKoBLxiPpBmCtbwB8
+Wzc0tijHo6uv8C0PZpOoTRI9VD4qiT/iIHIgf5GAuqsLan4wIZ88vjMELzGo0RgkOV5cnVSZL21
zTiYoPjOhSYGcVbLjEPHdLqg9Hp5JPDdDOdPcmhmLuQnodemTsbGDWKAJNXAQknQAHgpaQDMaray
RTAFYNJowrouAqTqeozVEK4BV86Y/gRGnA3xyYrWxl9IU+iQfMCwvhtDiwhr5G5PX4puesMm90km
mVMsng2yvgW37YEOsK7KIdB2gC9/a18Tx1hKqIMtbQnDpGA/AADxX1Lly4XXBNZNJzgpy+dZNIxv
8FBljIKYwoQZHvMtVwjj8h4HoNwEX42tsygYbn9hahFTolPImVM3VEBMMNnCGkToDmqvJgl/IcBA
bEGip403wvOen0MPmZGCRzus62/p0Ck0T8HTPFdoE5JvQnMhWmi/AaPHeFZwkEpSvxYeqmcrC7Qe
javVmJiEu5FYNw2YcMlfAW4Z0eEivy55ry6xHnRe6wUzm4D/1fStNqAEw5JMBrsDQHdYEpK/Nhi2
OToip40aOux2UTS8QhbNLM3XSAM58Rl01BVjVTvxsycUYKhwBTuou5HtT6JU1MPWeeR5d1ku7XWk
DW5Idf5pw5lb/B0c7VDzgOI05RJaag6H4czFhLHEp664FuSWyMQhVWyGIYlE0MyMt0DGQ4MWBFdP
W3Ei+G+hDpG6IxWUDrDjDDWAbwvgZLsNMAidkZa9Z0DdLgTGy84JjIDXXLqXXphJKaZfWI0+VD/c
UqQmkwZdEAlveWgWO93w31sHzM8ESrStmYyYJCvWv2b1CP4RNiKBRaf/biFH3zH9RRowX5qqKHjB
7EGsMzgtWZQo6+JuiP1uamaBstlLQRea541YsiTZiMzLkCAmW+zNrxIMIhJE24eGH4kpn7W6UHYZ
AI4TUEH4kR435syR0MjiM+dd3EDYF52L/JM3ZcdmvdBB3HGm4RBBxCgRG3kiw8zAD9fcDZQ2S1gM
s2JAOJOJRtty7tfKsmnAXJZIoXXVUhDiMWwzsmdlJ5HGw+cmMm1jsRRlLqgbm6FK3kS8crerYs2Z
ForEm6vZqnj2xKuxKkoDuqtPJbNMm/SxzHIp+V+skMr4w8OhQmru0df+BxaPXpeIJjXmx4EXU7xK
R0eRf+l3w4yoZrvl/zqKvTIeTNPb7wyLI1Ew3TatMvFl9gHnaiAZD8VlN0y8AmWXUF8RFix/JIoJ
bimBS4NtiXbGLaVYYnysW5qFlYfe1PqDrXBqN4zPSK0HAWvto7lF2LxfauQVhveP03cLthVHxdQN
onhn6uawgxteSYbcJpq2wYrYneTdhuaQgz5yI9hvsC2N+HqIbPDlDfXrgQsGq0W6ivI9zcGQhaFx
lOLCrhrNS1Gnhcx4mnuUHqStGY2cKrtcIpGn/8ScRgy4PIzopb8ksUTvtnO1dKujCGAadkINItjb
EyLbsyrnZQ8Zx7mlMSJIfEpmBxjL9l4dMpE6qHDsGkXKVDVog/kFu4fYd+5VA2lBLKxPeM3G0DjH
eVg/lkUMkgTaFmIQvvlZySCRTkF6Le9w0Z+xo6jnKUcbyNRbxzud/qnRVhpSX/Yb6pvamy58FoH3
2JnWJeZkrixG16Kbtw2t0uCdX9cRUmn2dRI93+4AflEIgMVCRSdxnwvNMk6WZKfLVCj2IJ/lGDxG
B/MSOwVJTbdsTPA+byC+2WA3FFrOaX4iksvIgyNj2RFxz7JMArNB0Xkuyr3lypn1a4qIbXWcu7ac
m1FzgQoVpnl7SLu3noJp0J1kr0zsI91WdBp2BidhROmNdUPVzOeMZ+L0/J0W3et0VEvBzGr9h7Yl
JkMbphN7jpdv5vobp5nwgtHniiW969YMm/cAvPPz6eecQMx7hpsypR1KJVAPktkUwVSRGpoHlGqe
n+GsSSizU4V1RcyqREo5203SvKZxD10HkrrGUHg6+a1Lcp+JYZ2fS5/cFI014AJ9VrnYp9C9JH6j
1O8vm4U4/krAxmok26stgLISdZI1AJXb69vcwFwtn5lj3MGCY82buoLU8cJ74Xgy7MuxtNuqXMGf
Ja7Ppr06GVtGlUpi8gzWkLcqK6+Npx4T0ru6a+Z3yK4TG14cGygAQLpXyyqBRioUfaCxoRLZJjKa
V2KgC2aODpluDYazMy7UOwh5JK3TcSlywfsKNGTALph4x3TBpwOimHEvjlHR7hjSYcsJYcgJTYZ2
47Ho2lv+4IglE8640RffPleiiMrzJWakiV/JkY99GoFtQWRzUrhYrxZosOBCx9/yeX0jG0VRKcMI
nOb5WUDSlvETAwOBPdOqz5qiXRCX9kKCX4305IHwMIVZDqawSeVNgXgeNBsnG3L3kzxrGDKkCGzZ
yHUz9q6ETmGuTt17MD6YT6pBPwC4rFGOB30RQh5pzPh+cNnBN0N/ce4x/n/dv4ghe1VpV3TdZiXO
n6K3vHfkg9L/i5kax6AULy15z9Utn2dsSPabWezNBxuzXRsDoxhuikjYP2RDbE2IBpqNbIbBe/s2
Qrq091uUkZW9xyJ5E9izs8hZJEpCJKFhNPWjVMiSfJTdZG8uGojbmOr604DmvWUzKGhB9Sd+004i
LwunpNCoJUS3n6b3Bi4HgvUPJB7bbSnJeOHVCcprp3Kb5wJdfje9uqty7cstKcH8b7+VYlmkBuyh
3K7tePA3gZsS+f7oyffx/cg3oJ/3c42lzw/zu+X07CSZnZKYwW+F7Mb4/8Fzdd3v4PKjoBeN8gGm
nLYZ0gsMN7WO42KGgD140XjcRqz8HsSQZYlSB9V8PeTGcRAuhKKBpT0+jpBWMcmZMUuwYqtYgXAq
r98kZN9L9cBBtyg+ZK4JtUdZ425Kh7b2Uzl1C3HpkrgrEDT3Vs79Y5a/x3oELylg9H4ZxDo0Tww+
8FVl1P1tsQkxUNmWo5OKqAFqFdQxFfP8m+YG9uAkdhZoH9ZOQDV1nChbZLOqqK+8dix+LYnEcGkU
hJ47tvk55GR1wkaiOPBobrrUoQ1HPtwjbXrKdDRs+sTvq9LIXrQshh/BCcFNPJ+uY68Eg6fZm7t2
LSrKdIKh9qroXYxDDf/xTTzueviV+/neutu9VYGjcffJo/j4YEM/Cok3nsdHjz8a5fYn/3YwSJyK
xYOEebhtaWP7RIwkBPiXkwygXR6Yfw065xGho8H9pyHyiPiVoqswIPuxaDZU7OAjYJZTIqzinQRZ
CGVGnzusg1id+f20Q3VQ6yoxb906gsnTeEuIngOToEQwc3m3FFHF8w5JnXR4PK7/xQQsItt/oVZy
Lo4BoZrYytQNjatzXFMqE8fMQ6nEnYxSSLoX6nwpzofflz55Ntxy6cI82kEpIRJCNOoTGaVM2E+F
+j6ysAHpV065y7eJpgkr7FmBX2Y/CWUEW/TTgSXEE337IdTzWvod20upt5doDzqfyhqTEWfRYc1H
D+tFI87cThA6HmfsAygTW6AMM8uLS1f4wo3KgZt54WOUe8iuzG78eMcP49P9/24B4h6jn/fLAr9Q
WZyWLcXR4Jvz6sZEw8IhasI5k7O05BA7PT4JKW0WZYhTp9InEEHr26k2ruLIBydwOg8kIQa6EV4J
oOwEU6aVOmgkaGvYyQ/vUN3sRwuKDCycu76UimiHQ/1//3fgOP6jlPfu/U7rkx1ub6P933lumXTK
v+z/UA6u/0r+yelrtCUGuAfglqAgt1KiUlXwOJgmaMY1CQNih1WU1Icyz3C7+ABDGl8zpLhii9jn
NqPHV4o4D18WfWaBAj36yUbIQ3TsZHsjkkIhpMCO/DUhvAfG7h4Wurt3zA4H1ucOwRQxPBwHN8/P
pXz78vAwgsQRfcIilbK0EdQARF0j5sFyp+jEPOFKCMoLLALma9cMSCt22dSCDlzJ5j5n0hNR0sPv
+kZPI1NHvmCvwKlJSx0t+LWfroQbTrnWhoDZ5s0GHBdF2jYlI7k0unVLhKiXFYIxbCxyRT+GDyZR
wzNBgBGx3nBZXeJKKCFOP/ySAIdYu4/XgENAmu9YrtYN56SilqYChTQ/3TT8vsm4ADR8GK1LCyHS
0NrOG65RbEyiuMzFGx+lZO+mSEnJbLS1LfoAI7idSFBDGa5n9jj4q2LhUxCz9abF2KX6KM/b6zDx
8KQnNWEleIakNq0yzcB1bu7gSYPq0NUBL8PB+wOLeV04bFE2/JEjAvSWwhElUqgN5HN8oNwjSxUO
DUsxGVVT2FtUcmL+RyFWVgqNLWlOSqNszZTd5b6P1O0Wv5cljWvpx4C78KBhNglDgaQjcQbUwAGz
hxF5Q3WTacu3rj85zt8tm6YnxcD9LKk2DfPRtvtEtxb2W9tzWgVWXeoOXAYpTwzLezBnXEHWqmu6
27TsZpdHCgtDZQ1vZG05BEgR87bi8tRhui6+aBnJE4TOiDDMyxZuXhUtu+t8Fye/BIbDlSMUgdnU
I5mPpE/Ao1WVa9bYPJf2tUOwSv7H3UsqqbWiiTUkl1nGbMciUN1C7dQHF3tBQRCymx74uaBCzJKO
W/BDUVhUIIIvkDpliOn4R1vlCmza226NbTLbuYqpbL/9rkRWv+WviPYNnAwPIfd/vuW6Y73COjHn
HYJIfVVNq5nNvE2gExIMQqD7RJZvYL3sXM+oLseDVm/bVe1nOljgozt25/F92pQX7tuycRLzS+3R
Xw5If7k68GC8YVNbDvWQmCE5JI04owLzipO/GIgtiWgQkFxXQ6EMCmGR7AJi7suqQIF5eXsxndGR
3NSGHF+oF1srauKgWnGszKuEcNRDUeIUJanG4e9uCMAJBcw7y2uYb+zqFgGfZB7eZxdWsA9f5Eks
rdQjHjnxGWEjW/SC0ZQ3iormKg8cvSzE+c+loWSmE3lQStotZ9z6WQtgXnCZGVdXd+JyDwUqSAfU
+39CZU8OHoQ6RiLw+GaWUtwIjL+0QxTucEDZUNTVXcm6CsQaarteFRIwJ4grAj0XVfdH8Jr6NX3H
d59UFoV1dNPE9TWmOaBOakkVdZz3QkM4P8e2ODzMvDMqqZXiCxLIs3jepeuEesUF4N6lDlGAQKWn
foTh5Ooip5Yyz2nHBV+YhbCt3pAAQ7MqbkX5VOVekeoY6EX0DuvNCyCxkFG+kMHNmwrVZbi+//sC
8ofWb7zyMdCfofK/prUJ1S1sGFk8dmw023wZOS+l9mzylpp2R0CAf4IKQRctq1YH1LSWvDj4qpAy
3aqy+6r4SmvetOdqL/qH0vKhoDLqKXFM5safoP218hg1jgzE7MNQYwVJDY/cSp1xpX50cRPALJx6
lwkP2NR0OMt5uWamYWZT5zGGcTOCbZEEqCh2xYDkNikGVrqRahb8lm/LJFcljgFkiqS7MRTbFEl5
IHJH86ORbnpkjU1R52QY4Aj+TNtgez4KSZ7CdJQHe026mUPXn2jZZNnO/iHu98JimhDk9Oe/bzqf
U8z6eVRhfng8TEUH77gJ3jiNxfOxzOTwWF6M50y5cCZJtdFcgngzaKJezkWtutShYrvb3t92gNIR
nRadvehpJ9xHfxb4DUP5/qsUd4aF7EQdOviGmTBSWXCzicZj02ILdU7spItqRxr5ZcUROX8S6MhV
HaI8Q3Wn6simaw3/YpRJIbvkKB/7lgGa9qSNaed33wi1gY7e1++I6Dg80i3m/2RZRORQeIK7dIWH
yXg2uXKYQtmtBPRqrluRVpnW97RUoSAUpORqwO5r9cwQ4PfthnNO3OH8XFxB5T+AykWURBYtXPIn
pmKUWspF6X0Oq2+VGjOimnsk1LKHLsLlPCRIpOdAsUCuQLJpwMdO1ajP/DaUS/86Uaq4vIS6EtLS
o4wtd8Avw7cmmkgxU4dLtk2znpTIC64i4tcfGhUtpJXt8uWrouIHjEYjSU4Kjt1F4m++s9WUaRIJ
RDlZpAUQRADL7WnzTdfxulZII84eB2CitRIJO68JabOTwWZOAXWZQph1TPFplBEI8slCOR5z3Ddc
4Tj2dCAjWm4UkLS3VNUMkGvJhvclYnfg9vjmKL1d51l55STWw6/y1Uiogy63uGxYRcMIOQQciYpB
gC4BtofpTsLQdPn7JoKA1ZYvDqALz8+2XNhm4LjJrFmby7KXioqmhsla4SIOTG3GzPAi+aIBsd8m
v0BMzKqcGmWyZI20IL4JzFg28+UfjE4jw6MXff60F5ebaAzwD7Pw1ploHvaAwym7Cswm+KPEPGDZ
BaWUGODWh+E7TjizWoRYJzYQxvRNfUjNRerKW5byxuMjtSJfsU6F3Iq+N99VKUoocgMGb8fJuklt
VFO3J4PLQzfmmpQhDXiZhCtFL7/hNAMObEh4ZOZMyl4LW452du7XGTmZNKhJdBxuCgmGulpKGjTG
gES13hJA+ZTaK/tcbx5Z+NA+tf2l69alqIfUOjR5VDRFqitq0OiVQ9GGznDPa7Xx3FnYZHIYxE9Y
w1PwiyqSgSKWp1oEA8a8n7G7W5aet6hEhJiXkwEqzNiu4lEfbdlPMr5Ztqo61uvNVvbZx4tEyfGY
7pL78IaihgNqVZ46tniNm0nrfZO6NZVvJxBqHGjfJjH4CI1YaN74hn6o4tTthVxWqY5itvwRe2ks
A0ap0mTMiM3HIlfnWQ2kmisr8t2NltGuaLZYKnJ5DPCktuwYfbfQz5eFmqGREQ6mh3ItflAWeS98
Rk4xn/MEi8rUV7GkiE1qXcnlwO5kDTPSKyONZlylTGqkHzzxaeJq8YNLRc0zM+RbAxhEaWuNfeHT
KAVMzLk6BsYbEXITbQNSWdLFhAOjcigpNn1I/tjWKCLeVd2O+MemMoTt2jUegDX0eN4zSyLxX03v
Cwx7dLw1ho92fB4BvdLPUESv2RJJ+bhISqTRGHThXtN9oEP4aMy0TCbwnDP081jwFVGe5NDCGVSV
i1sakZLBDoj2w7XcTXEV7M4E+cZTGIXVbRsTOyyJUeNsu7Vtp+jU28iD/MkncLOEYuu/qB28ILZZ
w7rlM0YME9cN+iQqMQDWrgGDarSeXN/eqp9v2ZAKm8FV4CrmvT1uuzYfhQqnWXREpW+WQqgMIqVA
ubYK+CQgR0UtgARgkXO5zxUNmBsqvTrQwuntZlFCp4S50ck1iCcIvKukl/IlHB0rOlP2BblkN7Ik
t8ul18NlT8QlDd1dC9VyjQitLoQ6X5Im2thNz94XwIcKrUiLXQbhF7SDPmg6SWHmqBlNRdr4OxSk
OQikjIWaxb1lnqj7abgoLk/CdSFQitnuG9aXeHgmMtnNiXb4yrHa3zdrNf0qLSUom8E6THhEXFs6
EhP88ojTTQNL6m0D2zBv20VL6nPib/O+Z/lo1Hk2aF7Wj71vs2rjxvrxD62vZ/7tZeTlQ78eWnDv
nqGwjfQZeRJfY06/uR+tBMJdWRmFgyfy44Nbj6528jcoTgvlf9RFRLJxMmvUiKeZD+lhD2XIg+fy
o70i6+xf8TXadg/TA8aGAxpk4YQPpOjFOJqPBAm/ybBrhEMR3sMNAPnBC1Tb4Gdo5ZP8YF/c0v7s
JOqdfxIZktTOiGYyLxYottF1zTz3Qx/vM8W9swBjP8O0XE69w2aKSxGVAMdyM0uc/y61t7kqTrdp
LRVb9FSP+XRcVJGraXFLco+7N9mT0lSaTA9ttYarBXr1cklMXuuy8gilomnNSdy3aEvRIvE8E4AS
a7TRQ49DIoZFHyqyFaRBa3ZpU+JSOjFvNCqjuKZah1RYtutE8H78Uf5RlCWbwpI/srVLcKaPju/b
8qOdLT+yloc/Z5lpKv9Be5lUuqCv4papI66++OiPUPbsp+Cwjx3ngxeiCyvy5FKr8DVWHv/CZ7Jb
RVOCT95rbnimOfheGUKpF1GGloyD/IPt9qjjqEXpDcUmQ6s6bxQEkcal62gUib4GuujFcENNzSMA
dg5vcEq19ut9X7evfH2bhJHxYVVePwXGa1BtfVt/HLvK5a7XH9D5FqJk7LDtY6f771Ahk2I6x6WJ
dahaLf/2fO9OPqXvpUOyQyaDsGt0MfdpvrfTaI/jeH6eR99+iH04OKPR4343vQL/+ZegVRjOvxid
/CIGRP4DaPVAKmznkOxeu3/GeAZSwoazE2V7lqDlt8/lHZD5sxQyP9iod36cQOdHVu/OBlIM/YDW
Wwbsyyjj8yWpDU+D++gL+ButNMh2DUkOXkjlSHb6WLlMD9uUsLd/V1zAmb/Tm11jFbuxJ1oBTO7h
8Fm0K/Fyx7njkhL7RdtcuTqT282lNmTtx2J3TIsq4jWsrnfrbmcpIXOOWX0VhgCp/Xd+rqfUVwSS
wqZasToq0Uv7zUAoQCZxHXxzlrFvjr+bcj7UNK67WhsxgnvS2pJkH7O5wzvSu9f5tFtJADavurck
qTHFJUGjlWq9wXZlBS0JLRsqt7hwPnAncPsbcVL5ijVSytvDrBMALze5Td8oAB2KSNHzxlvcWy6z
MG0hoUzPtlLvajgorUKTN9X14xdPv3sTh1t9bp4MjUPk1jOHAaOOz8+fgi2h6iZjd8T6k+Julk2h
/q7Is2y0jkPkESza/DVvvnn6AoNZbNSrgfzo3Cxyc2jY5hl4rj2VhSJaAax1XKXWiIbWajcSy8PK
GgG+dHPJaNFKISlq3pw42ytLI3zVNrNiJkBqDmt1yCC7YPCcDGR3sZGoJbmviAOSybWv+FjriQqY
Ti6tHtY7kmiZReW1cB4iJno9muLS4gx+gYcL9lOOwC3nvy+zrct36fxG5WcF29XrzaEaqbRT6O8q
kjtsMzXWvG9UB7KjqsDJWN01oIRj0IGp2hK8WJfOKoZ5rFKIXXeZdmjokKPbor46nsSVUpkYPiVZ
XRvwHEaVlbsmk4F4RR8maXwHlXie+doAK3wVcI2INMD/2WYFLhcf5hdO07bh1/K32KS96tWw8PPI
JTGh0gIzrYAJEuDTiToSdjuYj7iaw+CqxV1+5p1WwhY2zacXjtXssAtDRg6lIkCl4J7ewuPvHgkH
IzrD6m4vW8MnciBMQthYnE5Fb0LH5LK07YXQHkcWwsbiS9ZIEs72EG1Gi2a+4RpsAr0MRbKl7LgU
oBNw/EmMhYfHRRplzOuvyCzwLbBlfs8LgsPn+68exZVHga9rsVg0xAdpwwxCxf4VXwIEQIJvW9Dt
AmcfTDQeddLdW+dv5YCahCvv6F0Js5ZL0TbE0xwAnyHRjQOPcXOcdBI5o8P3p/nFhqve9qrzzcC5
e81JlusFt1rqkORC59wDI6IihtRi5QqPEkMx02blZs3iNndV504CXcTigZY6Vduf/87Miw7mh+LB
GKRaj8fcoi2IIuKhjzuqwlAjHvAZsFYzxaTLUbINwdlILuAUQgt2HhRC2I1dVSvIm4vyWu5mTL5X
DlzWAlSy4LoMy6ejLiWmwBV923KRtBCpTbozbyKXfwgwAGsZQOBpRI7+IwkfQnELPT/4KN7vSMk7
aeGLkd5BO1x1MjXxNAi7nsqlKnYsD1RzP/BqsHbEgjD+kMnbN03ENVOxEkdaY26acnl/D0gbEiDT
oHxLp5iPrQjhS4V5suqke8mYSdsiQMnlGhW6SLKri/McvUoJrPtIdZyp57fT05dscWzhCsIbWq1W
7q+TSFGaFWNjjWBrimeZd1KNkoE5MKF41riCAmmQ0R16u5Ocfo+9BjfsrhbuxfiP5Pe+QXaKyp6t
TJlRzrHjz8OzrJIh/BrhtfugRXf7BZmlF0YxJpOFVSloF7KWjKOXWjea8+GZYUvdAjmmCKXzh9u0
G0zFD6KxqnYDSy3wK+4kkHxrb1hTWtlj5OO7WMlgq1iDTwSSwSbAbZqSwUAW7ymfGuDFOCqoo42E
koscFvbBXCtsEoGdFJrLrANLoC1oxsdkqGCgERTlylETrW7yoJBDjl9yqnau3vbdoP2HAfx1SK82
w62jRVxW24pO4K9cf/79CD/VIh6xmwQfTaL6CZJNN2C32ugbVJM3BGoiGoN0s/uaXMeXUMi+HS/o
ZquPO4+HkTh/H4GWAt7SckMemoIf5T7HkNWsSPRIwWWM1SOuuXg/XNED8EDhjteRpnNqWjsfSQfc
O5YBr7MLzA7yg61HvwqrdU9G5zfkC857Y1jzQiHX5sgpO6+CykUwtWT9+b2hNduHyDq/ZaFFq+as
XHAilQYTL4b66cb0u5Q/sZ+TxesIb7pjB/xuGb8PWZphxaw0SyglPuQMvJoL1b29rsNzvc8NdDsu
n6NuonRQcSTzDWXOFyPnUSXFCfmOzwBsidZ5eD+dcZItDtv1mzlf3O49pDraqZRqEgkZ3FSeR6ni
H+Sc+LS4mqFq7Xbd+VQvceKLpSJrCYXLOVWK80CFr3FGlHKVyDm36VKnnCzrQHImqcKJjRSV3bPq
MlyPQUyy+2+3SDTEJS/91E1mDH3FJ3sZsmnVLziZBtApLZCL9ZGL5HyRhq3do3ewx740eOclycoT
zTJ1UDxfz3qkpyubh2/8A7llL66ckQ3ru1kBmFEdO3pmvpNxnxCna26N4ZAB+Ida+Ul6NtfW/S54
3Hm7466rG7dNmu0yv0mRDF0dxKQYhb2AU9nS57Nt+ydk0cuFg76c8kAlTCqhnvZ6bcMccjpsf6va
Ysv406bk9B765H/pXzX8xNkVSBjlu65wz27srwy+X5b6nBjGalvX+7yj2W3sjg14fq1EwzkvoaJM
ahaJW0hCPXTgyD5iTL/BMCM0OU/Bl3qiR/UkZkSlXYPkbAHqkShOejdF7I8TpZ9zPIxv8pWbC5d7
HYr9+HqHJKdkjKXdDYet5WntFNpFB3l8AvjOa/Mg2zVe9a3e8pXj5gfpGx/ylW97DFW0c4ICSCQU
SnetyCkwWgmIsCJ3BqTqVLdocEEGqSxqgryQsclk/p7k1GteA/i03u9uFwV7SkccAeObapBhiyXE
vOCfWYQidpE2GIQErDwKSZUf8Zzxtdg4aomEnY3pwJpn+EhC7pGxPB1z2gSg1WhB9/9zMHDJQyFh
TheNuU9HnCR16wxY82+WXiGEeJnYJV8jUSnT53YpdNFtWkyWnQzo4Bjn9yA/4wPA/1B5b80Usxl8
N2wDEks5/klKREetFr3wBeRXTKIdLdWX8aK1ZSBi3q9Vwza72FCXros4OK8nmB/feSPQCVwL1luq
tLXn+0I1av6WU14kvXiuSTW31BRCgK69LNZjDmNrji91QGpWsVZSFHwPdlo4A7OSUF8zJzJyUFi0
JvRtbXlTmmwuNyfinaQe74PjRZk36/zRgTrL+LTlRXflpzEZkk28unxVZVFLTmznnCQKWrkuK9zR
8IUWsuYobuc9+9TewaMDBTcqWC5s1q297hX945+2zCtT+FVm81naMlYTnX5gT+i5GXOWbn1qRpxs
2K3niHQUurkK5DXgVix/heKhmVkMsOCbjkJ1iZlcpjXS4qLk9E5OJ7ESe1syU9kZ3w2lWngit7eb
NZVsOMX7ee72ugbGqL3efWNfOi6t6UjsCTXXMRFR5OyaU0mOqHhfcTk9gECXYoHe5m7BWt3WKO6C
Rw3/HIlLaVhtwtOkrI9j+uSHR1GoIwKp/tZWk2RSvUxitOXRehVlvavpPb7YO7xd+9rcNbi0fqcJ
bq5yiRqVaUxiaZYyOKHpphNmMqV/5hXDyIkZtXCLrF+1sE3apJa2vfyy98V+eVNKsqUoYGOBsO1i
Ur/q5poHlKnit/codSnR1USP1DbRuUSXbPSGIdUcBx9GOiwEppW34QCGV2bFrzf4MlXal6psmTtJ
UpS39OFBG9ATuZqOqcU85EiTovVENSaXcsnfnPB4pwNwV4xuR/d3+wKH/QfP4GgvD9sjsX9OHux+
N7Izjq06jXqrWIAPLla0egL+Ioo2mLFI1NN7MXndfJ3IvQWM+XuPvuRxiC2doC5fh3tMxfDwaED6
ZZr/T8ba8YP4smkzMfP8aVv4WPuXatP9AnvdtXY7uERrJv52btEAYQqs4a1qLZttTSpMz6AlrlIK
Ky5TyTQJF0zGmWjR3c9DHXpqN7SG67GzKNwh1YrMqu9i2IGmIYKSE+/4imxuBKAyY3yhPBiOV3Qp
LPc6KMg2bzacZ7nMxf/jL1JsM0kUtPusYfJJyYUywuD4iYiVnZQdiUM5GeZmuNe0Ngkb7qxEbTcM
HmH4CKNLFpejkwR5r4Ovilq8L/YGTwdz/gLl2jBlSBjnq89NaGDYNheiQ/mhDUrdgL43UjSBhdF1
U0nx/e170fMzu/nvuas3AAjbVZKrFS4HkAs/neBFloZXLPRqG7num8zYepPo1F2+6eUa+nR17Tut
GBfdkk7cE24+r41uDbbr3GpW2Tl5VQLQQaP9xt9jjqClui4TTJSvlcC1iSV/teT9yhgrLtHCJdHs
AvfneoH3p5/+l+0/4Zp3vJaPvMF/7nn74T3uwrv73rZ73FT2sJu57n+j1EMu7nnQFSP3vmnjfvdJ
POT6g5GS//eoEL6zpu8w0Xd/7b27qsntqVo2XnhiJzBzJ1BwH9xk3EG+w0lGP8vRC7SjH7niO862
HuynfNwB/OW/TCQv4elz+mhVTEJ9ylCzqhUb1pJleg1bx6XzJxn73qWIHfuStCLbCt8qN4cG72ZN
Iy5bsncLdoAhm5xRL+yYImnFNn/yoTdoG/XkahERuYjr/PyJq6qOEwzYHHxWvHHfeXdtFtXPDB9D
DG9muE4kLoTKn0f50T5oIMYqC+S5ekrhd+1uUK+LrA90KIAzmtxzkgKNXTrWhfe4hpS0JXKZlIX+
thKYnWebdjVsFWra9EV3NZEZMKkSMWq1MMjWzLQ4l7ORJ1QcTJTDZ+y2XqhTATeL1Ea/LHJ3n2p5
eaSB+Hpcz8peinC/0nKkbJeV4nOLb14rEDyScvV2tWCxWl/CBmd55nUXKw5eGzLEhsA3AesGBlgq
Cw9i2ELPvubOfGahFENds+olNJELIjZyr7N5YjTA4WvJiULH8HfYgrA28SOpwm4mksgK+kADEP0r
UMyUSdGh0FK54BGE+ramTqlzWi5Uji9EYar0t2snuHp/AP4/CGrhFPvFtLxzh5D+a8SHxrYPaZCv
bGvoZer/7Lla//tnm4xy73zDhM9uSVV7n39jQHfM4kt/qQcwUULCb8GentHRqYhLSlkUjutJnGfZ
OodDf12UFW8pHBxR9p4XUNXBDp6HY0/NQjVHxSjV8zN20XSKgjKc7oRfqwStRS/LYC/jwbabSmrF
zTYlgj/LJbbm/SeIkZ3WnMvES/2s7NY0Oajzqv1S9+vRruXKFv3UCykmiHBQwH0zczNwsU5eYmY2
IfkFB+/s2enzp5KmdoNbHv8YGSk45tDjs0uOUHUnv2F2Z68ef0mzE1AUD+ZxteASzQuXdJaXUtN6
0ZwkgvrszfcsGLAzRKKdYaqy1l6K+9e/ZZvW/54ciQvBumnxuMioi6L4TxO/ahfiEdAPyA4KxepE
nIGxobyR3RkCzO5M8LRWWFVL7RF7lAsbqrBw2bItic/DwLsAXI2PJCdzWa0eHynfRBPDA4Zssyu9
aa8YvDS4YOVZUyyiT6bsATtxnOf0FREUVEMOlLHrX/4v3Kv+L3jGAAA=
--=-=-=--

\start
Date: Wed, 23 May 2007 18:47:21 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: [ANN] new version of axiom mode for emacs.
Cc: Alasdair McAndrew

On 05/23/2007 05:44 PM, Martin Rubey wrote:
> Below is the next version.  It colors output green.

What about putting the version of axiom.el.pamphlet on the wiki and 
announce a link?
Or even put it into the Axiom SVN archive at sourceforge?

\start
Date: Wed, 23 May 2007 12:59:40 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: [ANN] new version of axiom mode for emacs.
Cc: Alasdair McAndrew

Quoting Ralf Hemmecke:

> What about putting the version of axiom.el.paphlet on the
> wiki and announce a link?
> Or even put it into the Axiom SVN archive at sourceforge?
>

+1 for the archive. I think there should be a sub-directory in
the Axiom source distribution that contains User Interface
code, e.g. also the customized 'tm_axiom.c' program and
the associated Windows version for TeXmacs. And/or perhaps
also a section devoted to User Contributions (maybe in
'src/share' ?). Keeping it in the source archive allows the
changes to be easily tracked and merged. 

Of course the pamphlet file can also be saved as a pamphlet
on the Axiom Wiki. This allows the literate program to be
in both presented in pdf/dvi and in src format with just one
link. 

\start
Date: Wed, 23 May 2007 13:18:16 -0400
From: Camm Maguire
To: Waldek Hebisch,list
Subject: gcl, shared libraries, was Lisp portability

Greetings, and thanks for including me in this thread.  Unfortunately,
axiom-developer mail is still not getting through my ISP for some
reason. 


> In my private tree Axiom is nicely working on top of sbcl and clisp.
> The remaining known problems are sockets and writeablep function.

Great!  It is always nice to have more options.  But I do have a
general question here.  Work in this direction obviously makes sense
if 1) GCL is currently deficient for axiom use in some regard and 2)
we have difficulties addressing said deficiencies via changes to GCL.
If both of these are true, I would greatly appreciate you and/or
others letting me know the details, as it is and has been a goal of
mine to ensure that gcl remains optimal for axiom use.  As in the
past, I pledge that if axiom needs anything from GCL which is
currently unavailable, I will make sure said functionality works in
GCL.  What I would like to avoid is chasing every random package which
no one has any serious intention of deploying in a real shipped
program. 

If either 1) or 2) above are not true, may I suggest that significant
work in this regard is a distraction from the real goals of the axiom
project -- to deliver the best symbolic algebra package in the open
source world.  In our company, we manage approx. $70 billion dollars
using open source software and code we've written on top of it.  We
would get nowhere if we spent any time at all making sure our code
works both on gcc and icc, etc.  Rather we pick a platform that
appears flexible, stick to it, and get the results we want out of it
quickly.  We do almost everything using gcc, gdb and emacs, not
because they are the slickest or hottest or even fastest, but because
they have good portable performance, they can be changed at the source
level if necessary, and they will be available forever, making our
payoff period for the learning curve essentially last a whole
lifetime.

I'd really love to help the axiom project by offering a similar setup
for use by the developers.  Even one better -- axiom has its own
personal compiler developer to tailor the compiler to its needs if
necessary.  This only pays off if my work on GCL frees axiom developer
hours for work on the core system.

> Also, currently for clisp I need cl-fad library, which I consider
> problematic.  Namely, cl-fad does not work with gcl, so for gcl
> we need separate code.  We need only few functions from cl-fad,
> to work around clisp weirdness (clisp makes strong distinction
> between paths to files and paths to directories and refuses
> to perform file operations on directories).  So my current plan
> is to eliminate use of cl-fad and provide the needed functions
> directly.  Related problem is performing operations on

I think this is a wise choice, but needless to say, if you need
cl-fad, I'll make sure it works.

I must say I'm less than enamored with the cl-foo library development
model. Its source level as opposed to binary, and there is no shared
library memory savings.  Beyond which, there really doesn't appear to
be much of anything available which is not provided elsewhere in
faster, smaller, shareable C libraries, though I haven't made any
exhaustive study here.  

I love lisp, obviously, and primarily for the magnitude and quality of
AI-type code which has been developed and has recently entered into
the open source world.  But lisp is not going to compete with perl,
python, java, or C, IMHO.  The primary goal should be in fulfilling
the ansi-standard and supporting applications from the past, while
offering non-standard interfaces to newer functionality in external
shared C libraries.  Do we really think cl-fad has a thirty year
lifetime ahead of it?  How will we coordinate with all these cl-
library developers external to the axiom project when they move on to
other things in life?   Will we read all their source and maintain it
ourselves? 

Thankfully, the ansi-standard is written down, and with all its warts,
will last > 30 years, IMHO.  If we need items outside the standard, we
should rely on implementations in C shared libraries, as these will
have a longer lifetime and in general will be technically superior.
We should then pick one again non-standard glue between lisp and C,
and stick to it, and call all the shared library routines from within
lisp.  These of course are just my opinions.

It is good you brought this up, as gclcvs has followed clisp-style
directory usage, at least at present.  We can undo this if required.
Pathnames with spaces are also fully supported in gclcvs.  These can
be backported to 2.6.8pre if necessary.

> directories -- to gain portability between Unix and Windows
> I tried to use Lisp code.  But each Lisp is doing them
> differently (and apparently some operations sometimes are missing).
> So I got a maze of conditionals over Lisp implementations.
> Looking at resulting code I feel that it is better to
> call operationg system utilities and have just use 
> conditionals to choose between Unix and Windows versions
> of file utilities.

In C, we call this #ifdef hell.  There is no good reason for it, in my
experience. 


> Concerning sockets, we need Unix domain sockets and select.  It
> seems that clisp provide both, but to get Unix domain sockets
> one needs version including rawsock module, which is not included
> in default clisp configuration.  

> sbcl offers sb-bsd-sockets which seem to have basic functions,
> but I do not see select.

> gcl documentation suggest that Unix domain sockets are unsupported.
> Also, I see no traces of select.

gclcvs has a select/fork based parallel processing system:

SYSTEM>(walker::macroexpand-all '(p-let ((x (foo)) (y (bar))) (+ x y)))

(LET* (X Y)
  (LET* ((#:G2306 3)
         (#:G2301 (LIST (LET ((#:G2310 (FORK)))
                          (IF (EQL 0 (CAR #:G2310))
                              (PROGN
                                (WRITE-POINTER-OBJECT (FOO) #:G2310)
                                (BYE))
                              #:G2310))
                        (LET ((#:G2311 (FORK)))
                          (IF (EQL 0 (CAR #:G2311))
                              (PROGN
                                (WRITE-POINTER-OBJECT (BAR) #:G2311)
                                (BYE))
                              #:G2311)))))
    (DECLARE ((INTEGER 0 3) #:G2306))
    (UNWIND-PROTECT
      (DO () ((= #:G2306 0))
        (LET ((#:G2309 (SELECT-READ #:G2301 -1)))
          (DECLARE ((INTEGER 0 3) #:G2309))
          (DO ((#:G2299 0 (1+ #:G2299)) (#:G2307 1 (ASH #:G2307 1))
               (#:G2308 #:G2301 (CDR #:G2308)))
              ((= #:G2299 2) (SETQ #:G2306 (LOGANDC2 #:G2306 #:G2309)))
            (DECLARE ((INTEGER 0 2) #:G2299) ((INTEGER 1 4) #:G2307))
            (IF (/= 0 (LOGAND #:G2307 #:G2309))
                (PROGN
                  (LET ((#:G2300 (READ-POINTER-OBJECT (CAR #:G2308))))
                    (LET ((#:G2313 #:G2299))
                      (IF (EQL #:G2313 '0) (PROGN (SETQ X #:G2300))
                          (IF (EQL #:G2313 '1) (PROGN (SETQ Y #:G2300))
                              NIL)))))))))
      (DO* ((#:G2314 #:G2301 (CDR #:G2314)))
           ((ENDP #:G2314) (CDR #:G2301))
        (LET ((#:G2301 (CAR #:G2314))) (KILL #:G2301 0)))))
  (+ X Y))


This can be adapted to whatever other interface one may desire.

Do you mean dgram (UDP) sockets?  If you specify the interface, we'll
put them in.


> There is "portable" cl-sockets library but the manual says it supports
> Allegro CL, sbcl and cmucl.  The manual does not say anything about
> Unix domain sockets or select.  The manual says that cl-sockets requires
> UFFI, so presumably cl-sockets works on top of "portable" C library.

> In short my finding is that portable Lisp sockets are a myth: all
> implementations provide different interface and frequently miss
> some essential services.  People who want portablity between Lisp
> implementations interface to C. 

Agreed!

I've been working on a better interface to external shared C
libraries for GCL.  The issue, as you may recall, is that GCL-compiled
code referring to external shared function addresses are statically
relocated to the value of said address at the time the .o file is
loaded. If one then saves the image and re-executes, the function is
likely in a different place.  

I've figured out a persistent solution using dlopen.  Still working on
the precise interface, but you can see the idea here.  Comments are
marked with ***:

=============================================================================
GCL (GNU Common Lisp)  2.7.0 CLtL1    May 22 2007 16:39:58
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL 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/

>(in-package 'si)

#<"SYSTEM" package>

SYSTEM>(show-lib-syms)

NIL

SYSTEM>(mdlsym "cosf" "libm.so")

|libm|:|cosf| ;;*** package autmatically created, lib automatically dlopened

SYSTEM>(mdlsym "dgemv_" "libblas.so")

|libblas|:|dgemv_|

SYSTEM>(show-lib-syms)

(LIB:|libblas| 6730696 #<"libblas" package>) ;;*** value of package
                                                   symbol is dlopen handle
(|libblas|:|dgemv_| 1080730284 NIL)          ;;*** value of C symbol
                                                   is current address,
                                                   reset on system startup
(LIB:|libm| 1074174504 #<"libm" package>) 
(|libm|:|cosf| 1094172320 NIL) 
NIL

SYSTEM>(dladdr |libblas|:|dgemv_| ;;*** exact path resolution
)

#P"/usr/lib/atlas/sse2/libblas.so"

SYSTEM>(system "cat /tmp/dl2.l")
(in-package "libm")

(eval-when
 (compile eval)
 (defmacro defdl (sym)
   (let* ((sym  (si::mdlsym (string-downcase sym) "libm.so"))
	  (fsym (si::mdlsym (concatenate 'string (string sym) "f") "libm.so")))
   `(progn
      (defun ,sym  (x) (si::dl-double-to-double ',sym x))
      (defun ,fsym (x) (si::dl-float-to-float   ',fsym x))))))

(defdl exp)
(defdl log)
(defdl sin)
(defdl cos)
(defdl tan)
(defdl asin)
(defdl acos)
(defdl atan)
(defdl sinh)
(defdl cosh)
(defdl tanh)
(defdl asinh)
(defdl acosh)
(defdl atanh)

SYSTEM>(load "/tmp/dl2.l")

;; Loading /tmp/dl2.l
;; Finished loading /tmp/dl2.l
T

SYSTEM>(show-lib-syms)

(LIB:|libblas| 6730696 #<"libblas" package>) 
(|libblas|:|dgemv_| 1080730284 NIL) 
(LIB:|libm| 1074174504 #<"libm" package>) 
(|libm|:|atan| 1094141472
    #<interpreted-function (LAMBDA-BLOCK |libm|:|atan| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|atan| ;;***
								   standard call to address denoted 
								   by symbol value, one double arg, returning one double
                                 |libm|::X))>) 
(|libm|:|acosh| 1094146080
    #<interpreted-function (LAMBDA-BLOCK |libm|:|acosh| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|acosh|
                                 |libm|::X))>) 
(|libm|:|expf| 1094176432
    #<interpreted-function (LAMBDA-BLOCK |libm|:|expf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|expf|
                                 |libm|::X))>) 
(|libm|:|atanhf| 1094176064
    #<interpreted-function (LAMBDA-BLOCK |libm|:|atanhf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|atanhf|
                                 |libm|::X))>) 
(|libm|:|acosf| 1094175504
    #<interpreted-function (LAMBDA-BLOCK |libm|:|acosf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|acosf|
                                 |libm|::X))>) 
(|libm|:|exp| 1094146864
    #<interpreted-function (LAMBDA-BLOCK |libm|:|exp| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|exp|
                                 |libm|::X))>) 
(|libm|:|atanh| 1094146512
    #<interpreted-function (LAMBDA-BLOCK |libm|:|atanh| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|atanh|
                                 |libm|::X))>) 
(|libm|:|cosh| 1094146672
    #<interpreted-function (LAMBDA-BLOCK |libm|:|cosh| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|cosh|
                                 |libm|::X))>) 
(|libm|:|cosf| 1094172320
    #<interpreted-function (LAMBDA-BLOCK |libm|:|cosf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|cosf|
                                 |libm|::X))>) 
(|libm|:|atanf| 1094172032
    #<interpreted-function (LAMBDA-BLOCK |libm|:|atanf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|atanf|
                                 |libm|::X))>) 
(|libm|:|cos| 1094141792
    #<interpreted-function (LAMBDA-BLOCK |libm|:|cos| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|cos|
                                 |libm|::X))>) 
(|libm|:|tanh| 1094145584
    #<interpreted-function (LAMBDA-BLOCK |libm|:|tanh| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|tanh|
                                 |libm|::X))>) 
(|libm|:|tanf| 1094175168
    #<interpreted-function (LAMBDA-BLOCK |libm|:|tanf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|tanf|
                                 |libm|::X))>) 
(|libm|:|tan| 1094145536
    #<interpreted-function (LAMBDA-BLOCK |libm|:|tan| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|tan|
                                 |libm|::X))>) 
(|libm|:|sinh| 1094150832
    #<interpreted-function (LAMBDA-BLOCK |libm|:|sinh| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|sinh|
                                 |libm|::X))>) 
(|libm|:|asin| 1094146208
    #<interpreted-function (LAMBDA-BLOCK |libm|:|asin| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|asin|
                                 |libm|::X))>) 
(|libm|:|sinf| 1094175120
    #<interpreted-function (LAMBDA-BLOCK |libm|:|sinf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|sinf|
                                 |libm|::X))>) 
(|libm|:|sin| 1094145488
    #<interpreted-function (LAMBDA-BLOCK |libm|:|sin| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|sin|
                                 |libm|::X))>) 
(|libm|:|coshf| 1094176224
    #<interpreted-function (LAMBDA-BLOCK |libm|:|coshf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|coshf|
                                 |libm|::X))>) 
(|libm|:|tanhf| 1094175216
    #<interpreted-function (LAMBDA-BLOCK |libm|:|tanhf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|tanhf|
                                 |libm|::X))>) 
(|libm|:|acoshf| 1094175632
    #<interpreted-function (LAMBDA-BLOCK |libm|:|acoshf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|acoshf|
                                 |libm|::X))>) 
(|libm|:|asinh| 1094141232
    #<interpreted-function (LAMBDA-BLOCK |libm|:|asinh| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|asinh|
                                 |libm|::X))>) 
(|libm|:|asinhf| 1094171792
    #<interpreted-function (LAMBDA-BLOCK |libm|:|asinhf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|asinhf|
                                 |libm|::X))>) 
(|libm|:|sinhf| 1094180368
    #<interpreted-function (LAMBDA-BLOCK |libm|:|sinhf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|sinhf|
                                 |libm|::X))>) 
(|libm|:|asinf| 1094175760
    #<interpreted-function (LAMBDA-BLOCK |libm|:|asinf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|asinf|
                                 |libm|::X))>) 
(|libm|:|logf| 1094179104
    #<interpreted-function (LAMBDA-BLOCK |libm|:|logf| (|libm|::X)
                             (DL-FLOAT-TO-FLOAT '|libm|:|logf|
                                 |libm|::X))>) 
(|libm|:|log| 1094149536
    #<interpreted-function (LAMBDA-BLOCK |libm|:|log| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|log|
                                 |libm|::X))>) 
(|libm|:|acos| 1094145952
    #<interpreted-function (LAMBDA-BLOCK |libm|:|acos| (|libm|::X)
                             (DL-DOUBLE-TO-DOUBLE '|libm|:|acos|
                                 |libm|::X))>) 
NIL

SYSTEM>(compile-file "/tmp/dl2.l")

;; Compiling /tmp/dl2.l.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/dl2.o.
#P"/tmp/dl2.o"
NIL
NIL

SYSTEM>(load *)

;; Loading /tmp/dl2.o
 ;; start address -T 0x66f480 ;; Finished loading /tmp/dl2.o
1460

SYSTEM>(show-lib-syms)

(LIB:|libblas| 6730696 #<"libblas" package>) 
(|libblas|:|dgemv_| 1080730284 NIL) 
(LIB:|libm| 1074174504 #<"libm" package>) 
(|libm|:|atan| 1094141472 #<compiled-function |libm|:|atan|>) 
(|libm|:|acosh| 1094146080 #<compiled-function |libm|:|acosh|>) 
(|libm|:|expf| 1094176432 #<compiled-function |libm|:|expf|>) 
(|libm|:|atanhf| 1094176064 #<compiled-function |libm|:|atanhf|>) 
(|libm|:|acosf| 1094175504 #<compiled-function |libm|:|acosf|>) 
(|libm|:|exp| 1094146864 #<compiled-function |libm|:|exp|>) 
(|libm|:|atanh| 1094146512 #<compiled-function |libm|:|atanh|>) 
(|libm|:|cosh| 1094146672 #<compiled-function |libm|:|cosh|>) 
(|libm|:|cosf| 1094172320 #<compiled-function |libm|:|cosf|>) 
(|libm|:|atanf| 1094172032 #<compiled-function |libm|:|atanf|>) 
(|libm|:|cos| 1094141792 #<compiled-function |libm|:|cos|>) 
(|libm|:|tanh| 1094145584 #<compiled-function |libm|:|tanh|>) 
(|libm|:|tanf| 1094175168 #<compiled-function |libm|:|tanf|>) 
(|libm|:|tan| 1094145536 #<compiled-function |libm|:|tan|>) 
(|libm|:|sinh| 1094150832 #<compiled-function |libm|:|sinh|>) 
(|libm|:|asin| 1094146208 #<compiled-function |libm|:|asin|>) 
(|libm|:|sinf| 1094175120 #<compiled-function |libm|:|sinf|>) 
(|libm|:|sin| 1094145488 #<compiled-function |libm|:|sin|>) 
(|libm|:|coshf| 1094176224 #<compiled-function |libm|:|coshf|>) 
(|libm|:|tanhf| 1094175216 #<compiled-function |libm|:|tanhf|>) 
(|libm|:|acoshf| 1094175632 #<compiled-function |libm|:|acoshf|>) 
(|libm|:|asinh| 1094141232 #<compiled-function |libm|:|asinh|>) 
(|libm|:|asinhf| 1094171792 #<compiled-function |libm|:|asinhf|>) 
(|libm|:|sinhf| 1094180368 #<compiled-function |libm|:|sinhf|>) 
(|libm|:|asinf| 1094175760 #<compiled-function |libm|:|asinf|>) 
(|libm|:|logf| 1094179104 #<compiled-function |libm|:|logf|>) 
(|libm|:|log| 1094149536 #<compiled-function |libm|:|log|>) 
(|libm|:|acos| 1094145952 #<compiled-function |libm|:|acos|>) 
NIL

SYSTEM>(disassemble '|libm|:|log|)

;; Compiling /tmp/gazonk_27499_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_27499_0.o.

#include "gazonk_27499_0.h"
void init_code(){do_init((void *)VV);}
/*	local entry for function CMP-ANON	*/

static object LI1(V2)

object V2;
{	 VMB1 VMS1 VMV1
	goto TTL;
TTL:;    ;;**** fast link C call to generic interface
	{object V3 = (/* DL-DOUBLE-TO-DOUBLE */(*LnkLI1)(((object)VV[0]),(V2)));VMR1
	(V3);}
	return Cnil;
}
static object  LnkTLI1(object first,...){object V1;va_list ap;va_start(ap,first);V1=(object )call_proc_new(((object)VV[1]),0,0,(void **)(void *)&LnkLI1,2,first,ap);va_end(ap);return V1;} /* DL-DOUBLE-TO-DOUBLE */
#(#(log DL-DOUBLE-TO-DOUBLE
    (%INIT
     . #((LET ((*DISABLE-RECOMPILE* T))
           (MFSFUN 'CMP-ANON 0 1 0)
           (ADD-HASH 'CMP-ANON '((T) T)
               '((DL-DOUBLE-TO-DOUBLE (T T) T))
SYSTEMCOMPILERCMP-ANON	/!.log	DL-DOUBLE-TO-DOUBL,QUOTE1-
               '/tmp/gazonk_27499_0.lsp))
         (DO-RECOMPILE)))))
static object LI1();
#define VMB1
#define VMS1
#define VMV1
#define VMR1(VMT1) return(VMT1);
#define VM1 0
static void * VVi[3]={
#define Cdata VV[2]
(void *)(LI1)
};
#define VV (VVi)
static object  LnkTLI1(object,...);
static object  (*LnkLI1)() = (object (*)()) LnkTLI1;

/tmp/gazonk_27499_0.o:     file format elf32-i386

Disassembly of section .text:

00000000 <init_code>:
object
macro_def_int(object);

#include "gazonk_27499_0.h"
void init_code(){do_init((void *)VV);}
   0:	55                   	push   %ebp
   1:	89 e5                	mov    %esp,%ebp
   3:	83 ec 08             	sub    $0x8,%esp
   6:	b8 00 00 00 00       	mov    $0x0,%eax
   b:	89 04 24             	mov    %eax,(%esp)
   e:	e8 fc ff ff ff       	call   f <init_code+0xf>
  13:	c9                   	leave  
  14:	c3                   	ret    

00000015 <LI1>:
/*	local entry for function CMP-ANON	*/

static object LI1(V2)

object V2;
{	 VMB1 VMS1 VMV1
  15:	55                   	push   %ebp
  16:	89 e5                	mov    %esp,%ebp
  18:	83 ec 18             	sub    $0x18,%esp
	goto TTL;
TTL:;
	{object V3 = (/* DL-DOUBLE-TO-DOUBLE */(*LnkLI1)(((object)VV[0]),(V2)));VMR1
  1b:	8b 0d 0c 00 00 00    	mov    0xc,%ecx
  21:	a1 00 00 00 00       	mov    0x0,%eax
  26:	89 c2                	mov    %eax,%edx
  28:	8b 45 08             	mov    0x8(%ebp),%eax
  2b:	89 44 24 04          	mov    %eax,0x4(%esp)
  2f:	89 14 24             	mov    %edx,(%esp)
  32:	ff d1                	call   *%ecx
  34:	89 45 fc             	mov    %eax,0xfffffffc(%ebp)
  37:	8b 45 fc             	mov    0xfffffffc(%ebp),%eax
	(V3);}
	return Cnil;
}
  3a:	c9                   	leave  
  3b:	c3                   	ret    

0000003c <LnkTLI1>:
static object  LnkTLI1(object first,...){object V1;va_list ap;va_start(ap,first);V1=(object )call_proc_new(((object)VV[1]),0,0,(void **)(void *)&LnkLI1,2,first,ap);va_end(ap);return V1;} /* DL-DOUBLE-TO-DOUBLE */
  3c:	55                   	push   %ebp
  3d:	89 e5                	mov    %esp,%ebp
  3f:	53                   	push   %ebx
  40:	83 ec 34             	sub    $0x34,%esp
  43:	8d 45 0c             	lea    0xc(%ebp),%eax
  46:	89 45 f4             	mov    %eax,0xfffffff4(%ebp)
  49:	8b 55 f4             	mov    0xfffffff4(%ebp),%edx
  4c:	b9 0c 00 00 00       	mov    $0xc,%ecx
  51:	a1 04 00 00 00       	mov    0x4,%eax
  56:	89 c3                	mov    %eax,%ebx
  58:	89 54 24 18          	mov    %edx,0x18(%esp)
  5c:	8b 45 08             	mov    0x8(%ebp),%eax
  5f:	89 44 24 14          	mov    %eax,0x14(%esp)
  63:	c7 44 24 10 02 00 00 	movl   $0x2,0x10(%esp)
  6a:	00 
  6b:	89 4c 24 0c          	mov    %ecx,0xc(%esp)
  6f:	c7 44 24 08 00 00 00 	movl   $0x0,0x8(%esp)
  76:	00 
  77:	c7 44 24 04 00 00 00 	movl   $0x0,0x4(%esp)
  7e:	00 
  7f:	89 1c 24             	mov    %ebx,(%esp)
  82:	e8 fc ff ff ff       	call   83 <LnkTLI1+0x47>
  87:	89 45 f8             	mov    %eax,0xfffffff8(%ebp)
  8a:	8b 45 f8             	mov    0xfffffff8(%ebp),%eax
  8d:	83 c4 34             	add    $0x34,%esp
  90:	5b                   	pop    %ebx
  91:	5d                   	pop    %ebp
  92:	c3                   	ret    
NIL

SYSTEM>(defun foo (x) (declare (long-float x)) (|libm|:|log| x))

FOO

SYSTEM>(disassemble 'foo)

;; Compiling /tmp/gazonk_27499_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_27499_0.o.

#include "gazonk_27499_0.h"
void init_code(){do_init((void *)VV);}
/*	local entry for function FOO	*/

static double LI1(V2)

double V2;
{	 VMB1 VMS1 VMV1
	goto TTL;
TTL:;
	/*(log X)*/
	{double V3;
	V3= V2;      ;;*** Automatic inlining through function pointer
	{double V4 = ((double (*)(double))DLlog)(V3);VMR1
	(V4);}}
	/* END (log X)*/
}
/*	global entry for the function FOO	*/

static void L1()
{	register object *base=vs_base;
	base[0]=make_longfloat(LI1(lf(base[0])));
	vs_top=(vs_base=base)+1;
}
#(#(log
    (%INIT
     . #((LET ((*DISABLE-RECOMPILE* T))
           (MF 'FOO 0)
           (ADD-HASH 'FOO '((LONG-FLOAT) LONG-FLOAT) '((log (T) T))
LISPLAMBDA!!,DECLAR,OPTIMIZ,SAFETY
libmlog-
               '/tmp/gazonk_27499_0.lsp)
           (MDL 'log 'libm 1))  ;;*** function pointer set on load,
				      and reset on image startup
         (DO-RECOMPILE)))))
static void L1();
static double LI1();
static void *DLlog;
#define VMB1
#define VMS1
#define VMV1
#define VMR1(VMT1) return(VMT1);
#define VM1 0
static void * VVi[2]={
#define Cdata VV[1]
(void *)(L1),
(void *)(&DLlog)
};
#define VV (VVi)

/tmp/gazonk_27499_0.o:     file format elf32-i386

Disassembly of section .text:

00000000 <init_code>:
object
macro_def_int(object);

#include "gazonk_27499_0.h"
void init_code(){do_init((void *)VV);}
   0:	55                   	push   %ebp
   1:	89 e5                	mov    %esp,%ebp
   3:	83 ec 08             	sub    $0x8,%esp
   6:	b8 00 00 00 00       	mov    $0x0,%eax
   b:	89 04 24             	mov    %eax,(%esp)
   e:	e8 fc ff ff ff       	call   f <init_code+0xf>
  13:	c9                   	leave  
  14:	c3                   	ret    

00000015 <LI1>:
/*	local entry for function FOO	*/

static double LI1(V2)

double V2;
{	 VMB1 VMS1 VMV1
  15:	55                   	push   %ebp
  16:	89 e5                	mov    %esp,%ebp
  18:	83 ec 28             	sub    $0x28,%esp
  1b:	8b 45 08             	mov    0x8(%ebp),%eax
  1e:	89 45 e8             	mov    %eax,0xffffffe8(%ebp)
  21:	8b 45 0c             	mov    0xc(%ebp),%eax
  24:	89 45 ec             	mov    %eax,0xffffffec(%ebp)
	goto TTL;
TTL:;
	/*(log X)*/
	{double V3;
	V3= V2;
  27:	dd 45 e8             	fldl   0xffffffe8(%ebp)
  2a:	dd 5d f0             	fstpl  0xfffffff0(%ebp)
	{double V4 = ((double (*)(double))DLlog)(V3);VMR1    ;;***
								minimal call overhead possible
  2d:	a1 00 00 00 00       	mov    0x0,%eax
  32:	dd 45 f0             	fldl   0xfffffff0(%ebp)
  35:	dd 1c 24             	fstpl  (%esp)
  38:	ff d0                	call   *%eax
  3a:	dd 5d f8             	fstpl  0xfffffff8(%ebp)
  3d:	dd 45 f8             	fldl   0xfffffff8(%ebp)
	(V4);}}
	/* END (log X)*/
}
  40:	c9                   	leave  
  41:	c3                   	ret    

00000042 <L1>:
/*	global entry for the function FOO	*/

static void L1()
{	register object *base=vs_base;
  42:	55                   	push   %ebp
  43:	89 e5                	mov    %esp,%ebp
  45:	53                   	push   %ebx
  46:	83 ec 14             	sub    $0x14,%esp
  49:	8b 1d 00 00 00 00    	mov    0x0,%ebx
	base[0]=make_longfloat(LI1(lf(base[0])));
  4f:	8b 03                	mov    (%ebx),%eax
  51:	dd 40 04             	fldl   0x4(%eax)
  54:	dd 1c 24             	fstpl  (%esp)
  57:	e8 b9 ff ff ff       	call   15 <LI1>
  5c:	dd 1c 24             	fstpl  (%esp)
  5f:	e8 fc ff ff ff       	call   60 <L1+0x1e>
  64:	89 03                	mov    %eax,(%ebx)
	vs_top=(vs_base=base)+1;
  66:	89 1d 00 00 00 00    	mov    %ebx,0x0
  6c:	a1 00 00 00 00       	mov    0x0,%eax
  71:	83 c0 04             	add    $0x4,%eax
  74:	a3 00 00 00 00       	mov    %eax,0x0
}
  79:	83 c4 14             	add    $0x14,%esp
  7c:	5b                   	pop    %ebx
  7d:	5d                   	pop    %ebp
  7e:	c3                   	ret    
NIL

SYSTEM>
=============================================================================

Each code block stores a list of its dlsym function pointers and the
symbol denoting the address to which they must be relocated on each
image startup:

=============================================================================
GCL (GNU Common Lisp)  2.7.0 CLtL1    May 22 2007 16:39:58
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL 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/

>(in-package 'si)

#<"SYSTEM" package>

SYSTEM>(mdlsym "dgemv_" "libblas.so")

|libblas|:|dgemv_|

SYSTEM>(show-lib-syms)

(LIB:|libblas| 6603144 #<"libblas" package>) 
(|libblas|:|dgemv_| 1080730284 NIL) 
NIL

SYSTEM>(si::save-system "ff")
camm@intech19:/fix/t1/camm/debian/gcl/tmp/tmp/foo1/unixport$ ldd saved_pre_gcl
	libSM.so.6 => /usr/lib/libSM.so.6 (0x41443000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0x413d9000)
	libXmu.so.6 => /usr/lib/libXmu.so.6 (0x413f3000)
	libXt.so.6 => /usr/lib/libXt.so.6 (0x412d7000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0x41433000)
	libXaw.so.7 => /usr/lib/libXaw.so.7 (0x4000f000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x41136000)
	libgmp.so.3 => /usr/lib/libgmp.so.3 (0x4006a000)
	libreadline.so.5 => /lib/libreadline.so.5 (0x400ad000)
	libncurses.so.5 => /lib/libncurses.so.5 (0x41329000)
	libm.so.6 => /lib/libm.so.6 (0x4136c000)
	libdl.so.2 => /lib/libdl.so.2 (0x4145f000)
	libc.so.6 => /lib/libc.so.6 (0x41019000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x41465000)
	libXpm.so.4 => /usr/lib/libXpm.so.4 (0x41421000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x41458000)
	/lib/ld-linux.so.2 (0x41000000)
camm@intech19:/fix/t1/camm/debian/gcl/tmp/tmp/foo1/unixport$ ldd ff
	libSM.so.6 => /usr/lib/libSM.so.6 (0x41443000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0x413d9000)
	libXmu.so.6 => /usr/lib/libXmu.so.6 (0x413f3000)
	libXt.so.6 => /usr/lib/libXt.so.6 (0x412d7000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0x41433000)
	libXaw.so.7 => /usr/lib/libXaw.so.7 (0x4000f000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x41136000)
	libgmp.so.3 => /usr/lib/libgmp.so.3 (0x4006a000)
	libreadline.so.5 => /lib/libreadline.so.5 (0x400ad000)
	libncurses.so.5 => /lib/libncurses.so.5 (0x41329000)
	libm.so.6 => /lib/libm.so.6 (0x4136c000)
	libdl.so.2 => /lib/libdl.so.2 (0x4145f000)
	libc.so.6 => /lib/libc.so.6 (0x41019000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x41465000)
	libXpm.so.4 => /usr/lib/libXpm.so.4 (0x41421000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x41458000)
	/lib/ld-linux.so.2 (0x41000000)
./ff
GCL (GNU Common Lisp)  2.7.0 CLtL1    May 22 2007 16:39:58
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL 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/

>(in-package 'si)

#<"SYSTEM" package>

SYSTEM>(show-lib-syms)

(LIB:|libblas| 6800592 #<"libblas" package>) 
(|libblas|:|dgemv_| 1080730284 NIL) 
NIL

SYSTEM>
=============================================================================

Suggestions most welcome.  One thing I'm not planning at the moment is
"deregistering" dlopened libraries, but this is open to consultation.

> Given that it seems that most reasonable way for Axiom is to use
> existiong C code.  There is are drawbacks: we need to interface to
> C and typical Lisp implementation can only interface to shared
> libraries via dlopen.  So we need to handle issues related to making
> shared library.

Hopefully, the above will be useful.  It appears that libdl is quite
portable, but may require cygwin.


> But AFAICS we will need C interface anyway, so we need to resolve
> problems of C interface and shared libraries.
> 

Thoughts most appreciated.  The above was primarily motivated to
obsolete the plt.c mechanism, which appears fragile and is currently
broken on mips for example.  But the implications for lisp extensions
appear quite attractive.

\start
Date: Wed, 23 May 2007 20:05:09 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: [ANN] new version of axiom mode for emacs.
Cc: Alasdair McAndrew

On 05/23/2007 06:59 PM, Bill Page wrote:
> Quoting Ralf Hemmecke:

>> What about putting the version of axiom.el.paphlet on the
>> wiki and announce a link?
>> Or even put it into the Axiom SVN archive at sourceforge?
>>
> 
> +1 for the archive. I think there should be a sub-directory in
> the Axiom source distribution that contains User Interface
> code, e.g. also the customized 'tm_axiom.c' program and
> the associated Windows version for TeXmacs.

Oh, Bill, your tm_axiom.c cannot go into the archive. It's not a 
.pamphlet file. ;-)
But honestly, tm_axiom.c maybe better live with the TeXmacs people, 
although we then probably lose a pamphlet style of it... and I would 
really like to see that file documented.

 > And/or perhaps
> also a section devoted to User Contributions (maybe in
> 'src/share' ?).

I think the name is not so utterly important, since it can be renamed 
later if some day we agree on another naming of directories.

\start
Date: Wed, 23 May 2007 20:08:31 +0200
From: Gernot Hueber
To: Camm Maguire
Subject: Re: gcl, shared libraries, was Lisp portability

Dear Camm, 

Great! Many thanks for working on the issue of calling shared lib functions 
from gcl. I have struggled some time ago with this issue, with moderate 
success.
Actually, I tried to call a shared lib function from Aldor/Axiom via gcl. 

My trails were based und the gcl-loader package, which looks quite similar 
to your way of importing and calling C libs. 

How can I use your functions (BTW I am FreeBSD user - unfortunately the 
ports tree offers only 2.6.7). Yet I had no luck (and little time) to use a 
more current version of gcl. 

Actually the main problem of calling external C functions was to pass 
variables from and to gcl. As of gsl (gnu scientific library), there are 
numerous variations - int, float, double, pointers to any of them, arrays, 
multi dimensional array, ...
Can you assist me with defining how to use all of these types properly? 

Camm Maguire writes: 

> Greetings, and thanks for including me in this thread.  Unfortunately,
> axiom-developer mail is still not getting through my ISP for some
> reason.  
> 
> 
>> In my private tree Axiom is nicely working on top of sbcl and clisp.
>> The remaining known problems are sockets and writeablep function.
> 
> Great!  It is always nice to have more options.  But I do have a
> general question here.  Work in this direction obviously makes sense
> if 1) GCL is currently deficient for axiom use in some regard and 2)
> we have difficulties addressing said deficiencies via changes to GCL.
> If both of these are true, I would greatly appreciate you and/or
> others letting me know the details, as it is and has been a goal of
> mine to ensure that gcl remains optimal for axiom use.  As in the
> past, I pledge that if axiom needs anything from GCL which is
> currently unavailable, I will make sure said functionality works in
> GCL.  What I would like to avoid is chasing every random package which
> no one has any serious intention of deploying in a real shipped
> program.  
> 
> If either 1) or 2) above are not true, may I suggest that significant
> work in this regard is a distraction from the real goals of the axiom
> project -- to deliver the best symbolic algebra package in the open
> source world.  In our company, we manage approx. $70 billion dollars
> using open source software and code we've written on top of it.  We
> would get nowhere if we spent any time at all making sure our code
> works both on gcc and icc, etc.  Rather we pick a platform that
> appears flexible, stick to it, and get the results we want out of it
> quickly.  We do almost everything using gcc, gdb and emacs, not
> because they are the slickest or hottest or even fastest, but because
> they have good portable performance, they can be changed at the source
> level if necessary, and they will be available forever, making our
> payoff period for the learning curve essentially last a whole
> lifetime. 
> 
> I'd really love to help the axiom project by offering a similar setup
> for use by the developers.  Even one better -- axiom has its own
> personal compiler developer to tailor the compiler to its needs if
> necessary.  This only pays off if my work on GCL frees axiom developer
> hours for work on the core system. 
> 
>> Also, currently for clisp I need cl-fad library, which I consider
>> problematic.  Namely, cl-fad does not work with gcl, so for gcl
>> we need separate code.  We need only few functions from cl-fad,
>> to work around clisp weirdness (clisp makes strong distinction
>> between paths to files and paths to directories and refuses
>> to perform file operations on directories).  So my current plan
>> is to eliminate use of cl-fad and provide the needed functions
>> directly.  Related problem is performing operations on
> 
> I think this is a wise choice, but needless to say, if you need
> cl-fad, I'll make sure it works. 
> 
> I must say I'm less than enamored with the cl-foo library development
> model. Its source level as opposed to binary, and there is no shared
> library memory savings.  Beyond which, there really doesn't appear to
> be much of anything available which is not provided elsewhere in
> faster, smaller, shareable C libraries, though I haven't made any
> exhaustive study here.   
> 
> I love lisp, obviously, and primarily for the magnitude and quality of
> AI-type code which has been developed and has recently entered into
> the open source world.  But lisp is not going to compete with perl,
> python, java, or C, IMHO.  The primary goal should be in fulfilling
> the ansi-standard and supporting applications from the past, while
> offering non-standard interfaces to newer functionality in external
> shared C libraries.  Do we really think cl-fad has a thirty year
> lifetime ahead of it?  How will we coordinate with all these cl-
> library developers external to the axiom project when they move on to
> other things in life?   Will we read all their source and maintain it
> ourselves?  
> 
> Thankfully, the ansi-standard is written down, and with all its warts,
> will last > 30 years, IMHO.  If we need items outside the standard, we
> should rely on implementations in C shared libraries, as these will
> have a longer lifetime and in general will be technically superior.
> We should then pick one again non-standard glue between lisp and C,
> and stick to it, and call all the shared library routines from within
> lisp.  These of course are just my opinions. 
> 
> It is good you brought this up, as gclcvs has followed clisp-style
> directory usage, at least at present.  We can undo this if required.
> Pathnames with spaces are also fully supported in gclcvs.  These can
> be backported to 2.6.8pre if necessary. 
> 
>> directories -- to gain portability between Unix and Windows
>> I tried to use Lisp code.  But each Lisp is doing them
>> differently (and apparently some operations sometimes are missing).
>> So I got a maze of conditionals over Lisp implementations.
>> Looking at resulting code I feel that it is better to
>> call operationg system utilities and have just use 
>> conditionals to choose between Unix and Windows versions
>> of file utilities.
> 
> In C, we call this #ifdef hell.  There is no good reason for it, in my
> experience.  
> 
> 
>> Concerning sockets, we need Unix domain sockets and select.  It
>> seems that clisp provide both, but to get Unix domain sockets
>> one needs version including rawsock module, which is not included
>> in default clisp configuration.  
> 
>> sbcl offers sb-bsd-sockets which seem to have basic functions,
>> but I do not see select.
> 
>> gcl documentation suggest that Unix domain sockets are unsupported.
>> Also, I see no traces of select.
> 
> gclcvs has a select/fork based parallel processing system: 
> 
> SYSTEM>(walker::macroexpand-all '(p-let ((x (foo)) (y (bar))) (+ x y)))=
 
> 
> (LET* (X Y)
>   (LET* ((#:G2306 3)
>          (#:G2301 (LIST (LET ((#:G2310 (FORK)))
>                           (IF (EQL 0 (CAR #:G2310))
>                               (PROGN
>                                 (WRITE-POINTER-OBJECT (FOO) #:G2310)
>                                 (BYE))
>                               #:G2310))
>                         (LET ((#:G2311 (FORK)))
>                           (IF (EQL 0 (CAR #:G2311))
>                               (PROGN
>                                 (WRITE-POINTER-OBJECT (BAR) #:G2311)
>                                 (BYE))
>                               #:G2311)))))
>     (DECLARE ((INTEGER 0 3) #:G2306))
>     (UNWIND-PROTECT
>       (DO () ((= #:G2306 0))
>         (LET ((#:G2309 (SELECT-READ #:G2301 -1)))
>           (DECLARE ((INTEGER 0 3) #:G2309))
>           (DO ((#:G2299 0 (1+ #:G2299)) (#:G2307 1 (ASH #:G2307 1))
>                (#:G2308 #:G2301 (CDR #:G2308)))
>               ((= #:G2299 2) (SETQ #:G2306 (LOGANDC2 #:G2306 #:G2309)=
))
>             (DECLARE ((INTEGER 0 2) #:G2299) ((INTEGER 1 4) #:G2307))
>             (IF (/= 0 (LOGAND #:G2307 #:G2309))
>                 (PROGN
>                   (LET ((#:G2300 (READ-POINTER-OBJECT (CAR #:G2308))))
>                     (LET ((#:G2313 #:G2299))
>                       (IF (EQL #:G2313 '0) (PROGN (SETQ X #:G2300))
>                           (IF (EQL #:G2313 '1) (PROGN (SETQ Y #:G2300))
>                               NIL)))))))))
>       (DO* ((#:G2314 #:G2301 (CDR #:G2314)))
>            ((ENDP #:G2314) (CDR #:G2301))
>         (LET ((#:G2301 (CAR #:G2314))) (KILL #:G2301 0)))))
>   (+ X Y)) 
> 
> 
> This can be adapted to whatever other interface one may desire. 
> 
> Do you mean dgram (UDP) sockets?  If you specify the interface, we'll
> put them in. 
> 
> 
>> There is "portable" cl-sockets library but the manual says it supports
>> Allegro CL, sbcl and cmucl.  The manual does not say anything about
>> Unix domain sockets or select.  The manual says that cl-sockets requir=
es
>> UFFI, so presumably cl-sockets works on top of "portable" C library.
> 
>> In short my finding is that portable Lisp sockets are a myth: all
>> implementations provide different interface and frequently miss
>> some essential services.  People who want portablity between Lisp
>> implementations interface to C. 
> 
> Agreed! 
> 
> I've been working on a better interface to external shared C
> libraries for GCL.  The issue, as you may recall, is that GCL-compiled
> code referring to external shared function addresses are statically
> relocated to the value of said address at the time the .o file is
> loaded. If one then saves the image and re-executes, the function is
> likely in a different place.   
> 
> I've figured out a persistent solution using dlopen.  Still working on
> the precise interface, but you can see the idea here.  Comments are
> marked with ***: 
> 
> =========================
==========================
==========================
===
> GCL (GNU Common Lisp)  2.7.0 CLtL1    May 22 2007 16:39:58
> Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXE=
C)
> 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/ 
> 
>>(in-package 'si)
> 
> #<"SYSTEM" package> 
> 
> SYSTEM>(show-lib-syms) 
> 
> NIL 
> 
> SYSTEM>(mdlsym "cosf" "libm.so") 
> 
> |libm|:|cosf| ;;*** package autmatically created, lib automatically dlo=
pened 
> 
> SYSTEM>(mdlsym "dgemv_" "libblas.so") 
> 
> |libblas|:|dgemv_| 
> 
> SYSTEM>(show-lib-syms) 
> 
> (LIB:|libblas| 6730696 #<"libblas" package>) ;;*** value of package
>                                                    symbol is dlopen han=
dle
> (|libblas|:|dgemv_| 1080730284 NIL)          ;;*** value of C symbol
>                                                    is current address,
>                                                    reset on system star=
tup
> (LIB:|libm| 1074174504 #<"libm" package>) 
> (|libm|:|cosf| 1094172320 NIL) 
> NIL 
> 
> SYSTEM>(dladdr |libblas|:|dgemv_| ;;*** exact path resolution
> ) 
> 
> #P"/usr/lib/atlas/sse2/libblas.so" 
> 
> SYSTEM>(system "cat /tmp/dl2.l")
> (in-package "libm") 
> 
> (eval-when
>  (compile eval)
>  (defmacro defdl (sym)
>    (let* ((sym  (si::mdlsym (string-downcase sym) "libm.so"))
> =09  (fsym (si::mdlsym (concatenate 'string (string sym) "f") "libm.so"=
)))
>    `(progn
>       (defun ,sym  (x) (si::dl-double-to-double ',sym x))
>       (defun ,fsym (x) (si::dl-float-to-float   ',fsym x)))))) 
> 
> (defdl exp)
> (defdl log)
> (defdl sin)
> (defdl cos)
> (defdl tan)
> (defdl asin)
> (defdl acos)
> (defdl atan)
> (defdl sinh)
> (defdl cosh)
> (defdl tanh)
> (defdl asinh)
> (defdl acosh)
> (defdl atanh) 
> 
> SYSTEM>(load "/tmp/dl2.l") 
> 
> ;; Loading /tmp/dl2.l
> ;; Finished loading /tmp/dl2.l
> T 
> 
> SYSTEM>(show-lib-syms) 
> 
> (LIB:|libblas| 6730696 #<"libblas" package>) 
> (|libblas|:|dgemv_| 1080730284 NIL) 
> (LIB:|libm| 1074174504 #<"libm" package>) 
> (|libm|:|atan| 1094141472
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|atan| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|atan| ;;***
> =09=09=09=09=09=09=09=09   standard call to address denoted 
> =09=09=09=09=09=09=09=09   by symbol value, one double arg, returning o=
ne double
>                                  |libm|::X))>) 
> (|libm|:|acosh| 1094146080
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|acosh| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|acosh|
>                                  |libm|::X))>) 
> (|libm|:|expf| 1094176432
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|expf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|expf|
>                                  |libm|::X))>) 
> (|libm|:|atanhf| 1094176064
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|atanhf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|atanhf|
>                                  |libm|::X))>) 
> (|libm|:|acosf| 1094175504
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|acosf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|acosf|
>                                  |libm|::X))>) 
> (|libm|:|exp| 1094146864
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|exp| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|exp|
>                                  |libm|::X))>) 
> (|libm|:|atanh| 1094146512
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|atanh| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|atanh|
>                                  |libm|::X))>) 
> (|libm|:|cosh| 1094146672
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|cosh| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|cosh|
>                                  |libm|::X))>) 
> (|libm|:|cosf| 1094172320
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|cosf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|cosf|
>                                  |libm|::X))>) 
> (|libm|:|atanf| 1094172032
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|atanf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|atanf|
>                                  |libm|::X))>) 
> (|libm|:|cos| 1094141792
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|cos| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|cos|
>                                  |libm|::X))>) 
> (|libm|:|tanh| 1094145584
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|tanh| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|tanh|
>                                  |libm|::X))>) 
> (|libm|:|tanf| 1094175168
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|tanf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|tanf|
>                                  |libm|::X))>) 
> (|libm|:|tan| 1094145536
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|tan| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|tan|
>                                  |libm|::X))>) 
> (|libm|:|sinh| 1094150832
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|sinh| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|sinh|
>                                  |libm|::X))>) 
> (|libm|:|asin| 1094146208
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|asin| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|asin|
>                                  |libm|::X))>) 
> (|libm|:|sinf| 1094175120
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|sinf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|sinf|
>                                  |libm|::X))>) 
> (|libm|:|sin| 1094145488
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|sin| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|sin|
>                                  |libm|::X))>) 
> (|libm|:|coshf| 1094176224
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|coshf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|coshf|
>                                  |libm|::X))>) 
> (|libm|:|tanhf| 1094175216
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|tanhf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|tanhf|
>                                  |libm|::X))>) 
> (|libm|:|acoshf| 1094175632
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|acoshf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|acoshf|
>                                  |libm|::X))>) 
> (|libm|:|asinh| 1094141232
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|asinh| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|asinh|
>                                  |libm|::X))>) 
> (|libm|:|asinhf| 1094171792
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|asinhf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|asinhf|
>                                  |libm|::X))>) 
> (|libm|:|sinhf| 1094180368
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|sinhf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|sinhf|
>                                  |libm|::X))>) 
> (|libm|:|asinf| 1094175760
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|asinf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|asinf|
>                                  |libm|::X))>) 
> (|libm|:|logf| 1094179104
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|logf| (|libm|::X)
>                              (DL-FLOAT-TO-FLOAT '|libm|:|logf|
>                                  |libm|::X))>) 
> (|libm|:|log| 1094149536
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|log| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|log|
>                                  |libm|::X))>) 
> (|libm|:|acos| 1094145952
>     #<interpreted-function (LAMBDA-BLOCK |libm|:|acos| (|libm|::X)
>                              (DL-DOUBLE-TO-DOUBLE '|libm|:|acos|
>                                  |libm|::X))>) 
> NIL 
> 
> SYSTEM>(compile-file "/tmp/dl2.l") 
> 
> ;; Compiling /tmp/dl2.l.
> ;; End of Pass 1.  
> ;; End of Pass 2.  
> ;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, =
Speed=3, (Debug quality ignored)
> ;; Finished compiling /tmp/dl2.o.
> #P"/tmp/dl2.o"
> NIL
> NIL 
> 
> SYSTEM>(load *) 
> 
> ;; Loading /tmp/dl2.o
>  ;; start address -T 0x66f480 ;; Finished loading /tmp/dl2.o
> 1460 
> 
> SYSTEM>(show-lib-syms) 
> 
> (LIB:|libblas| 6730696 #<"libblas" package>) 
> (|libblas|:|dgemv_| 1080730284 NIL) 
> (LIB:|libm| 1074174504 #<"libm" package>) 
> (|libm|:|atan| 1094141472 #<compiled-function |libm|:|atan|>) 
> (|libm|:|acosh| 1094146080 #<compiled-function |libm|:|acosh|>) 
> (|libm|:|expf| 1094176432 #<compiled-function |libm|:|expf|>) 
> (|libm|:|atanhf| 1094176064 #<compiled-function |libm|:|atanhf|>) 
> (|libm|:|acosf| 1094175504 #<compiled-function |libm|:|acosf|>) 
> (|libm|:|exp| 1094146864 #<compiled-function |libm|:|exp|>) 
> (|libm|:|atanh| 1094146512 #<compiled-function |libm|:|atanh|>) 
> (|libm|:|cosh| 1094146672 #<compiled-function |libm|:|cosh|>) 
> (|libm|:|cosf| 1094172320 #<compiled-function |libm|:|cosf|>) 
> (|libm|:|atanf| 1094172032 #<compiled-function |libm|:|atanf|>) 
> (|libm|:|cos| 1094141792 #<compiled-function |libm|:|cos|>) 
> (|libm|:|tanh| 1094145584 #<compiled-function |libm|:|tanh|>) 
> (|libm|:|tanf| 1094175168 #<compiled-function |libm|:|tanf|>) 
> (|libm|:|tan| 1094145536 #<compiled-function |libm|:|tan|>) 
> (|libm|:|sinh| 1094150832 #<compiled-function |libm|:|sinh|>) 
> (|libm|:|asin| 1094146208 #<compiled-function |libm|:|asin|>) 
> (|libm|:|sinf| 1094175120 #<compiled-function |libm|:|sinf|>) 
> (|libm|:|sin| 1094145488 #<compiled-function |libm|:|sin|>) 
> (|libm|:|coshf| 1094176224 #<compiled-function |libm|:|coshf|>) 
> (|libm|:|tanhf| 1094175216 #<compiled-function |libm|:|tanhf|>) 
> (|libm|:|acoshf| 1094175632 #<compiled-function |libm|:|acoshf|>) 
> (|libm|:|asinh| 1094141232 #<compiled-function |libm|:|asinh|>) 
> (|libm|:|asinhf| 1094171792 #<compiled-function |libm|:|asinhf|>) 
> (|libm|:|sinhf| 1094180368 #<compiled-function |libm|:|sinhf|>) 
> (|libm|:|asinf| 1094175760 #<compiled-function |libm|:|asinf|>) 
> (|libm|:|logf| 1094179104 #<compiled-function |libm|:|logf|>) 
> (|libm|:|log| 1094149536 #<compiled-function |libm|:|log|>) 
> (|libm|:|acos| 1094145952 #<compiled-function |libm|:|acos|>) 
> NIL 
> 
> SYSTEM>(disassemble '|libm|:|log|) 
> 
> ;; Compiling /tmp/gazonk_27499_0.lsp.
> ;; End of Pass 1.  
> ;; End of Pass 2.  
> ;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, =
Speed=3, (Debug quality ignored)
> ;; Finished compiling /tmp/gazonk_27499_0.o. 
> 
> #include "gazonk_27499_0.h"
> void init_code(){do_init((void *)VV);}
> /*=09local entry for function CMP-ANON=09*/ 
> 
> static object LI1(V2) 
> 
> object V2;
> {=09 VMB1 VMS1 VMV1
> =09goto TTL;
> TTL:;    ;;**** fast link C call to generic interface
> =09{object V3 = (/* DL-DOUBLE-TO-DOUBLE */(*LnkLI1)(((object)VV[0]),(=
V2)));VMR1
> =09(V3);}
> =09return Cnil;
> }
> static object  LnkTLI1(object first,...){object V1;va_list ap;va_start(=
ap,first);V1=(object )call_proc_new(((object)VV[1]),0,0,(void **)(void =
*)&LnkLI1,2,first,ap);va_end(ap);return V1;} /* DL-DOUBLE-TO-DOUBLE */
> #(#(log DL-DOUBLE-TO-DOUBLE
>     (%INIT
>      . #((LET ((*DISABLE-RECOMPILE* T))
>            (MFSFUN 'CMP-ANON 0 1 0)
>            (ADD-HASH 'CMP-ANON '((T) T)
>                '((DL-DOUBLE-TO-DOUBLE (T T) T))
> =06SYSTEMCOMPILERCMP-ANON=09/!=03.log=09=0C=13DL-DOUBLE-TO-DOUBL=05,QUO=
TE1-=18
>                '/tmp/gazonk_27499_0.lsp))
>          (DO-RECOMPILE)))))
> static object LI1();
> #define VMB1
> #define VMS1
> #define VMV1
> #define VMR1(VMT1) return(VMT1);
> #define VM1 0
> static void * VVi[3]={
> #define Cdata VV[2]
> (void *)(LI1)
> };
> #define VV (VVi)
> static object  LnkTLI1(object,...);
> static object  (*LnkLI1)() = (object (*)()) LnkTLI1; 
> 
> /tmp/gazonk_27499_0.o:     file format elf32-i386 
> 
> Disassembly of section .text: 
> 
> 00000000 <init_code>:
> object
> macro_def_int(object); 
> 
> #include "gazonk_27499_0.h"
> void init_code(){do_init((void *)VV);}
>    0:=0955                   =09push   %ebp
>    1:=0989 e5                =09mov    %esp,%ebp
>    3:=0983 ec 08             =09sub    $0x8,%esp
>    6:=09b8 00 00 00 00       =09mov    $0x0,%eax
>    b:=0989 04 24             =09mov    %eax,(%esp)
>    e:=09e8 fc ff ff ff       =09call   f <init_code+0xf>
>   13:=09c9                   =09leave  
>   14:=09c3                   =09ret     
> 
> 00000015 <LI1>:
> /*=09local entry for function CMP-ANON=09*/ 
> 
> static object LI1(V2) 
> 
> object V2;
> {=09 VMB1 VMS1 VMV1
>   15:=0955                   =09push   %ebp
>   16:=0989 e5                =09mov    %esp,%ebp
>   18:=0983 ec 18             =09sub    $0x18,%esp
> =09goto TTL;
> TTL:;
> =09{object V3 = (/* DL-DOUBLE-TO-DOUBLE */(*LnkLI1)(((object)VV[0]),(=
V2)));VMR1
>   1b:=098b 0d 0c 00 00 00    =09mov    0xc,%ecx
>   21:=09a1 00 00 00 00       =09mov    0x0,%eax
>   26:=0989 c2                =09mov    %eax,%edx
>   28:=098b 45 08             =09mov    0x8(%ebp),%eax
>   2b:=0989 44 24 04          =09mov    %eax,0x4(%esp)
>   2f:=0989 14 24             =09mov    %edx,(%esp)
>   32:=09ff d1                =09call   *%ecx
>   34:=0989 45 fc             =09mov    %eax,0xfffffffc(%ebp)
>   37:=098b 45 fc             =09mov    0xfffffffc(%ebp),%eax
> =09(V3);}
> =09return Cnil;
> }
>   3a:=09c9                   =09leave  
>   3b:=09c3                   =09ret     
> 
> 0000003c <LnkTLI1>:
> static object  LnkTLI1(object first,...){object V1;va_list ap;va_start(=
ap,first);V1=(object )call_proc_new(((object)VV[1]),0,0,(void **)(void =
*)&LnkLI1,2,first,ap);va_end(ap);return V1;} /* DL-DOUBLE-TO-DOUBLE */
>   3c:=0955                   =09push   %ebp
>   3d:=0989 e5                =09mov    %esp,%ebp
>   3f:=0953                   =09push   %ebx
>   40:=0983 ec 34             =09sub    $0x34,%esp
>   43:=098d 45 0c             =09lea    0xc(%ebp),%eax
>   46:=0989 45 f4             =09mov    %eax,0xfffffff4(%ebp)
>   49:=098b 55 f4             =09mov    0xfffffff4(%ebp),%edx
>   4c:=09b9 0c 00 00 00       =09mov    $0xc,%ecx
>   51:=09a1 04 00 00 00       =09mov    0x4,%eax
>   56:=0989 c3                =09mov    %eax,%ebx
>   58:=0989 54 24 18          =09mov    %edx,0x18(%esp)
>   5c:=098b 45 08             =09mov    0x8(%ebp),%eax
>   5f:=0989 44 24 14          =09mov    %eax,0x14(%esp)
>   63:=09c7 44 24 10 02 00 00 =09movl   $0x2,0x10(%esp)
>   6a:=0900 
>   6b:=0989 4c 24 0c          =09mov    %ecx,0xc(%esp)
>   6f:=09c7 44 24 08 00 00 00 =09movl   $0x0,0x8(%esp)
>   76:=0900 
>   77:=09c7 44 24 04 00 00 00 =09movl   $0x0,0x4(%esp)
>   7e:=0900 
>   7f:=0989 1c 24             =09mov    %ebx,(%esp)
>   82:=09e8 fc ff ff ff       =09call   83 <LnkTLI1+0x47>
>   87:=0989 45 f8             =09mov    %eax,0xfffffff8(%ebp)
>   8a:=098b 45 f8             =09mov    0xfffffff8(%ebp),%eax
>   8d:=0983 c4 34             =09add    $0x34,%esp
>   90:=095b                   =09pop    %ebx
>   91:=095d                   =09pop    %ebp
>   92:=09c3                   =09ret    
> NIL 
> 
> SYSTEM>(defun foo (x) (declare (long-float x)) (|libm|:|log| x)) 
> 
> FOO 
> 
> SYSTEM>(disassemble 'foo) 
> 
> ;; Compiling /tmp/gazonk_27499_0.lsp.
> ;; End of Pass 1.  
> ;; End of Pass 2.  
> ;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, =
Speed=3, (Debug quality ignored)
> ;; Finished compiling /tmp/gazonk_27499_0.o. 
> 
> #include "gazonk_27499_0.h"
> void init_code(){do_init((void *)VV);}
> /*=09local entry for function FOO=09*/ 
> 
> static double LI1(V2) 
> 
> double V2;
> {=09 VMB1 VMS1 VMV1
> =09goto TTL;
> TTL:;
> =09/*(log X)*/
> =09{double V3;
> =09V3= V2;      ;;*** Automatic inlining through function pointer
> =09{double V4 = ((double (*)(double))DLlog)(V3);VMR1
> =09(V4);}}
> =09/* END (log X)*/
> }
> /*=09global entry for the function FOO=09*/ 
> 
> static void L1()
> {=09register object *base=vs_base;
> =09base[0]=make_longfloat(LI1(lf(base[0])));
> =09vs_top=(vs_base=base)+1;
> }
> #(#(log
>     (%INIT
>      . #((LET ((*DISABLE-RECOMPILE* T))
>            (MF 'FOO 0)
>            (ADD-HASH 'FOO '((LONG-FLOAT) LONG-FLOAT) '((log (T) T))
> =04LISPLAMBDA=07!=0C=01!=07,DECLAR,OPTIMIZ=06,SAFETY
> =04libmlog-=02=18
>                '/tmp/gazonk_27499_0.lsp)
>            (MDL 'log 'libm 1))  ;;*** function pointer set on load,
> =09=09=09=09      and reset on image startup
>          (DO-RECOMPILE)))))
> static void L1();
> static double LI1();
> static void *DLlog;
> #define VMB1
> #define VMS1
> #define VMV1
> #define VMR1(VMT1) return(VMT1);
> #define VM1 0
> static void * VVi[2]={
> #define Cdata VV[1]
> (void *)(L1),
> (void *)(&DLlog)
> };
> #define VV (VVi) 
> 
> /tmp/gazonk_27499_0.o:     file format elf32-i386 
> 
> Disassembly of section .text: 
> 
> 00000000 <init_code>:
> object
> macro_def_int(object); 
> 
> #include "gazonk_27499_0.h"
> void init_code(){do_init((void *)VV);}
>    0:=0955                   =09push   %ebp
>    1:=0989 e5                =09mov    %esp,%ebp
>    3:=0983 ec 08             =09sub    $0x8,%esp
>    6:=09b8 00 00 00 00       =09mov    $0x0,%eax
>    b:=0989 04 24             =09mov    %eax,(%esp)
>    e:=09e8 fc ff ff ff       =09call   f <init_code+0xf>
>   13:=09c9                   =09leave  
>   14:=09c3                   =09ret     
> 
> 00000015 <LI1>:
> /*=09local entry for function FOO=09*/ 
> 
> static double LI1(V2) 
> 
> double V2;
> {=09 VMB1 VMS1 VMV1
>   15:=0955                   =09push   %ebp
>   16:=0989 e5                =09mov    %esp,%ebp
>   18:=0983 ec 28             =09sub    $0x28,%esp
>   1b:=098b 45 08             =09mov    0x8(%ebp),%eax
>   1e:=0989 45 e8             =09mov    %eax,0xffffffe8(%ebp)
>   21:=098b 45 0c             =09mov    0xc(%ebp),%eax
>   24:=0989 45 ec             =09mov    %eax,0xffffffec(%ebp)
> =09goto TTL;
> TTL:;
> =09/*(log X)*/
> =09{double V3;
> =09V3= V2;
>   27:=09dd 45 e8             =09fldl   0xffffffe8(%ebp)
>   2a:=09dd 5d f0             =09fstpl  0xfffffff0(%ebp)
> =09{double V4 = ((double (*)(double))DLlog)(V3);VMR1    ;;***
> =09=09=09=09=09=09=09=09minimal call overhead possible
>   2d:=09a1 00 00 00 00       =09mov    0x0,%eax
>   32:=09dd 45 f0             =09fldl   0xfffffff0(%ebp)
>   35:=09dd 1c 24             =09fstpl  (%esp)
>   38:=09ff d0                =09call   *%eax
>   3a:=09dd 5d f8             =09fstpl  0xfffffff8(%ebp)
>   3d:=09dd 45 f8             =09fldl   0xfffffff8(%ebp)
> =09(V4);}}
> =09/* END (log X)*/
> }
>   40:=09c9                   =09leave  
>   41:=09c3                   =09ret     
> 
> 00000042 <L1>:
> /*=09global entry for the function FOO=09*/ 
> 
> static void L1()
> {=09register object *base=vs_base;
>   42:=0955                   =09push   %ebp
>   43:=0989 e5                =09mov    %esp,%ebp
>   45:=0953                   =09push   %ebx
>   46:=0983 ec 14             =09sub    $0x14,%esp
>   49:=098b 1d 00 00 00 00    =09mov    0x0,%ebx
> =09base[0]=make_longfloat(LI1(lf(base[0])));
>   4f:=098b 03                =09mov    (%ebx),%eax
>   51:=09dd 40 04             =09fldl   0x4(%eax)
>   54:=09dd 1c 24             =09fstpl  (%esp)
>   57:=09e8 b9 ff ff ff       =09call   15 <LI1>
>   5c:=09dd 1c 24             =09fstpl  (%esp)
>   5f:=09e8 fc ff ff ff       =09call   60 <L1+0x1e>
>   64:=0989 03                =09mov    %eax,(%ebx)
> =09vs_top=(vs_base=base)+1;
>   66:=0989 1d 00 00 00 00    =09mov    %ebx,0x0
>   6c:=09a1 00 00 00 00       =09mov    0x0,%eax
>   71:=0983 c0 04             =09add    $0x4,%eax
>   74:=09a3 00 00 00 00       =09mov    %eax,0x0
> }
>   79:=0983 c4 14             =09add    $0x14,%esp
>   7c:=095b                   =09pop    %ebx
>   7d:=095d                   =09pop    %ebp
>   7e:=09c3                   =09ret    
> NIL 
> 
> SYSTEM>
> =========================
==========================
==========================
=== 
> 
> Each code block stores a list of its dlsym function pointers and the
> symbol denoting the address to which they must be relocated on each
> image startup: 
> 
> =========================
==========================
==========================
===
> GCL (GNU Common Lisp)  2.7.0 CLtL1    May 22 2007 16:39:58
> Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXE=
C)
> 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/ 
> 
>>(in-package 'si)
> 
> #<"SYSTEM" package> 
> 
> SYSTEM>(mdlsym "dgemv_" "libblas.so") 
> 
> |libblas|:|dgemv_| 
> 
> SYSTEM>(show-lib-syms) 
> 
> (LIB:|libblas| 6603144 #<"libblas" package>) 
> (|libblas|:|dgemv_| 1080730284 NIL) 
> NIL 
> 
> SYSTEM>(si::save-system "ff")
> camm@intech19:/fix/t1/camm/debian/gcl/tmp/tmp/foo1/unixport$ ldd saved_=
pre_gcl
> =09libSM.so.6 => /usr/lib/libSM.so.6 (0x41443000)
> =09libICE.so.6 => /usr/lib/libICE.so.6 (0x413d9000)
> =09libXmu.so.6 => /usr/lib/libXmu.so.6 (0x413f3000)
> =09libXt.so.6 => /usr/lib/libXt.so.6 (0x412d7000)
> =09libXext.so.6 => /usr/lib/libXext.so.6 (0x41433000)
> =09libXaw.so.7 => /usr/lib/libXaw.so.7 (0x4000f000)
> =09libX11.so.6 => /usr/lib/libX11.so.6 (0x41136000)
> =09libgmp.so.3 => /usr/lib/libgmp.so.3 (0x4006a000)
> =09libreadline.so.5 => /lib/libreadline.so.5 (0x400ad000)
> =09libncurses.so.5 => /lib/libncurses.so.5 (0x41329000)
> =09libm.so.6 => /lib/libm.so.6 (0x4136c000)
> =09libdl.so.2 => /lib/libdl.so.2 (0x4145f000)
> =09libc.so.6 => /lib/libc.so.6 (0x41019000)
> =09libXau.so.6 => /usr/lib/libXau.so.6 (0x41465000)
> =09libXpm.so.4 => /usr/lib/libXpm.so.4 (0x41421000)
> =09libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x41458000)
> =09/lib/ld-linux.so.2 (0x41000000)
> camm@intech19:/fix/t1/camm/debian/gcl/tmp/tmp/foo1/unixport$ ldd ff
> =09libSM.so.6 => /usr/lib/libSM.so.6 (0x41443000)
> =09libICE.so.6 => /usr/lib/libICE.so.6 (0x413d9000)
> =09libXmu.so.6 => /usr/lib/libXmu.so.6 (0x413f3000)
> =09libXt.so.6 => /usr/lib/libXt.so.6 (0x412d7000)
> =09libXext.so.6 => /usr/lib/libXext.so.6 (0x41433000)
> =09libXaw.so.7 => /usr/lib/libXaw.so.7 (0x4000f000)
> =09libX11.so.6 => /usr/lib/libX11.so.6 (0x41136000)
> =09libgmp.so.3 => /usr/lib/libgmp.so.3 (0x4006a000)
> =09libreadline.so.5 => /lib/libreadline.so.5 (0x400ad000)
> =09libncurses.so.5 => /lib/libncurses.so.5 (0x41329000)
> =09libm.so.6 => /lib/libm.so.6 (0x4136c000)
> =09libdl.so.2 => /lib/libdl.so.2 (0x4145f000)
> =09libc.so.6 => /lib/libc.so.6 (0x41019000)
> =09libXau.so.6 => /usr/lib/libXau.so.6 (0x41465000)
> =09libXpm.so.4 => /usr/lib/libXpm.so.4 (0x41421000)
> =09libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x41458000)
> =09/lib/ld-linux.so.2 (0x41000000)
> ./ff
> GCL (GNU Common Lisp)  2.7.0 CLtL1    May 22 2007 16:39:58
> Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXE=
C)
> 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/ 
> 
>>(in-package 'si)
> 
> #<"SYSTEM" package> 
> 
> SYSTEM>(show-lib-syms) 
> 
> (LIB:|libblas| 6800592 #<"libblas" package>) 
> (|libblas|:|dgemv_| 1080730284 NIL) 
> NIL 
> 
> SYSTEM>
> =========================
==========================
==========================
=== 
> 
> Suggestions most welcome.  One thing I'm not planning at the moment is
> "deregistering" dlopened libraries, but this is open to consultation. 
> 
>> Given that it seems that most reasonable way for Axiom is to use
>> existiong C code.  There is are drawbacks: we need to interface to
>> C and typical Lisp implementation can only interface to shared
>> libraries via dlopen.  So we need to handle issues related to making
>> shared library.
> 
> Hopefully, the above will be useful.  It appears that libdl is quite
> portable, but may require cygwin. 
> 
> 
>> But AFAICS we will need C interface anyway, so we need to resolve
>> problems of C interface and shared libraries. 
>> 
> 
> Thoughts most appreciated.  The above was primarily motivated to
> obsolete the plt.c mechanism, which appears fragile and is currently
> broken on mips for example.  But the implications for lisp extensions
> appear quite attractive. 

\start
Date: Wed, 23 May 2007 11:14:18 -0700 (PDT)
From: Cliff Yapp
To: Camm Maguire, Waldek Hebisch
Subject: Re: gcl, shared libraries

--- Camm Maguire wrote:

> if 1) GCL is currently deficient for axiom use in some regard and 2)
> we have difficulties addressing said deficiencies via changes to GCL.
> If both of these are true, I would greatly appreciate you and/or
> others letting me know the details, as it is and has been a goal of
> mine to ensure that gcl remains optimal for axiom use.

Camm, while it cannot (yet) be said to be part of Axiom, the cl-web
code does not work on GCL at the moment.  There are two obvious things
I know of and probably others I don't (yet):  1)  read-sequence doesn't
seem to be present in GCL 2) I'm using trivial-utf-8 for string->array
and array->string functionality, and I don't know how or if that would
work on GCL.

> I must say I'm less than enamored with the cl-foo library development
> model. Its source level as opposed to binary, and there is no shared
> library memory savings.  Beyond which, there really doesn't appear to
> be much of anything available which is not provided elsewhere in
> faster, smaller, shareable C libraries, though I haven't made any
> exhaustive study here. 

I'm sure there are a lot of opinions on this one.  I'm not quite clear
as to why the source level is objectionable (don't we simply compile it
at build time anyway?).  I like the all-lisp solution for the simple
reason that it avoids any reliance on the behavior of the C language or
compilers, but that's just me.

> The primary goal should be in fulfilling the ansi-standard and 
> supporting applications from the past, while offering non-standard
> interfaces to newer functionality in external shared C libraries.
> Do we really think cl-fad has a thirty year lifetime ahead of it?

Is there any reason to suppose it does not?  If it does not, why not? 
Can it be improved to the point where it DOES have that lifetime ahead
of it?  Will the problem it solves go away as Lisp implementations
improve?

> How will we coordinate with all these cl-library developers external
> to the axiom project when they move on to other things in life?  
> Will we read all their source and maintain it ourselves? 

If that source is literate (in the true literate programming sense)
this should actually be possible.  Also, if the solutions developed are
good enought that not many changes NEED to be made, it becomes even
more viable.

The core of TeX has not changed in any major way for a LONG time, and
it is STILL the best tool for the problem it solves.  This is the kind
of development I would like to see Axiom pursue - the solution of
problems in such a fashion that there is no need or incentive to solve
them again.

There should be NO dark corners or black magic anywhere in the software
chain.  We should be able to look up the code for any point in the
process, and read the explanations for purpose and method wherever we
need to.  I know this is not possible at the moment, and maybe not for
decades, but it is still a goal I would like to work towards.

Anyway.  Thank you for the work you have been putting into GCL to help
support Axiom!  My only concrete question at the moment really relates
to read-sequence - is this something GCL plans to add?

\start
Date: Wed, 23 May 2007 14:52:11 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: [ANN] new version of axiom mode for emacs.

Quoting Ralf Hemmecke:

> On 05/23/2007 06:59 PM, Bill Page wrote:
> ... 
>> I think there should be a sub-directory in
>> the Axiom source distribution that contains User Interface
>> code, e.g. also the customized 'tm_axiom.c' program and
>> the associated Windows version for TeXmacs. 
>
> Oh, Bill, your tm_axiom.c cannot go into the archive. It's not
> a .pamphlet file. ;-)

You are right, I am looking for some motivation here. :-)

> But honestly, tm_axiom.c maybe better live with the TeXmacs
> people, although we then probably lose a pamphlet style of it... 
> and I would really like to see that file documented. 

I disagree. I think we should do what Andrey Grozin first
suggested and actually implemented for Maxima - that is
to eliminate the interface program altogether. The protocol
required by TeXmacs is actually pretty simple (unfortunately
it not as well suited as say something based on XML) but
still easy to produce and parse in spite of the odd control
characters choosen as delimiters. In the case of Maxima
what was done was to provide a small set of customizable
delimiters that are added to the usual text-based user
interface. This is enough to allow Maxima to interact
directly with TeXmacs when started with the right options. 

At one point Andrey stated his intentions on this email
list to produce such an extension for Axiom so that it
too could interact directly with TeXmacs. 

Of course it is tempting to try to address the more
general question of how to define a proper application
program interface (API) that would permit almost any
program to interact directly with Axiom. This was done
for example by MapleSoft for recent versions of Maple. 
The Maple API library is published and is in fact used
for their (infamous) new Java-based GUI. Maple users
are also encouraged to use this interface (in Java, C,
or whatever language binding they like) to write their
own customized interfaces for special purposes. 
In spite of the difficulties of calling Lisp programs as
an external library, something like this could also be
provided for Axiom. (That was one possible aim the
original AxiomUI Google Summer of Code project that
unfortunately did not materialize.)

But for now I would be quite happy just to follow Maxima's
lead and get rid the 'tm_axiom' program by making just
simple extensions of the Axiom text-oriented user interface
so that it is more friendly to external programs that wish
to send commands and parse it's output. 

\start
Date: Wed, 23 May 2007 22:19:23 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: [ANN] new version of axiom mode for emacs.

> But for now I would be quite happy just to follow Maxima's
> lead and get rid the 'tm_axiom' program by making just
> simple extensions of the Axiom text-oriented user interface
> so that it is more friendly to external programs that wish
> to send commands and parse it's output.

Sorry, I cannot help, I don't know enough (yet). I don't even know where 
the Axiom prompt is defined.

\start
Date: Wed, 23 May 2007 22:47:58 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: Axiom API

Bill Page wrote:
> Quoting Ralf Hemmecke:
> > But honestly, tm_axiom.c maybe better live with the TeXmacs
> > people, although we then probably lose a pamphlet style of it... 
> > and I would really like to see that file documented. 
> 
> I disagree. I think we should do what Andrey Grozin first
> suggested and actually implemented for Maxima - that is
> to eliminate the interface program altogether. The protocol
> required by TeXmacs is actually pretty simple (unfortunately
> it not as well suited as say something based on XML) but
> still easy to produce and parse in spite of the odd control
> characters choosen as delimiters. In the case of Maxima
> what was done was to provide a small set of customizable
> delimiters that are added to the usual text-based user
> interface. This is enough to allow Maxima to interact
> directly with TeXmacs when started with the right options. 
> 

I do not know what TeXmacs expect, but I know what Axiom was
designed to do:  external program are supposed to connect to
a socket and send command trough it.  Terminal is really meant
only for direct user interface (possibly also for debugging).

I belive that if TeXmacs does not want to use HyperDoc 
protocol (which gives _full_ access to Axiom capabilities)
we can add extra protocol.

\start
Date: 23 May 2007 17:27:39 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: re: Boot, Virtual Machine

Gabriel Dos Reis writes:

> On Tue, 23 May 2007, Stephen Wilson wrote:
> 
> | > You have the same thing in Boot.
> | 
> | Well, I would argue that till pigs fly. But I wont.
> 
> What would make you believe that you don't have the same equivalence in Boot?

As I said, Im not interested in persuing this point.  I would simply
suggest that you read a book on Lisp, or read some code.  It is self
evident to anyone competent with Lisp what its macrosytem represents.

\start
Date: Wed, 23 May 2007 16:30:00 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: re: Boot, Virtual Machine

On Wed, 23 May 2007, Stephen Wilson wrote:

| Gabriel Dos Reis writes:
| 
| > On Tue, 23 May 2007, Stephen Wilson wrote:
| > 
| > | > You have the same thing in Boot.
| > | 
| > | Well, I would argue that till pigs fly. But I wont.
| > 
| > What would make you believe that you don't have the same equivalence in Boot?
| 
| As I said, Im not interested in persuing this point.

So you did not have a factual basis for your statement.  That is OK.
Thanks for your time.

\start
Date: Wed, 23 May 2007 17:29:50 -0400
From: Bill Page
To: Waldek Hebisch
Subject: Re: Axiom API

Quoting Waldek Hebisch:

> ... 
> I do not know what TeXmacs expect,

TeXmacs expects exchange of information via pipes (most
external programs communicate with TeXmacs this way) or
by calls to a dynamically linked library. 

http://www.texmacs.org/tmweb/manual/webman-write-itf.en.html

> but I know what Axiom was designed to do:  external program
> are supposed to connect to a socket and send command through
> it.  Terminal is really meant only for direct user interface (possibly
> also for debugging). 

I understand, however I am stopped by an almost complete lack
of any documentation. There is not even a very simple example
of "send one command, get the result and display it". Of course
this is embedded somewhere in the hyperdoc code but it is not
sufficiently accessible for me to motivate me to devote enough
time to understand it and extract such an example. 

Your reply gives me hope that such documentation may soon
be available! :-)

>
> I belive that if TeXmacs does not want to use HyperDoc
> protocol (which gives _full_ access to Axiom capabilities)
> we can add extra protocol. 
>

First we need to write down what is the HyperDoc protocol!

I understand that there may also be some currently unused
interface that is part of the br-saturn module (previously used
with the techexplore browser interface). I am sure that every
thing required by the TeXmacs interface is available here --
somewhere. 

I small complication is that desire to be able to present
graphics generated by Axiom inside the TeXmacs document
(as figures). As you know these graphics are generated by
another program external to AXIOMsys that requires the
the format of a postscript file. 

In any case, it seems clear that an API library could be
developed that would interface with Axiom (and graphics?)
via sockets and talk to TeXmacs (and other external programs,
e.g. the Axiom Wiki webserver and even emacs) via a
convenient and efficient dynamic library. 

All of these  possibilities are lying dormant because of the
simple lack of documentation and time. 

\start
Date: Wed, 23 May 2007 18:23:08 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: Boot, Virtual Machine

Gabriel Dos Reis wrote:
> | ... 
> | > What would make you believe that you don't have the
> | > same  equivalence in Boot?

> | > On Tue, 23 May 2007, Stephen Wilson wrote:
> | >
> | > As I said, Im not interested in pursuing this point. 
>
> So you did not have a factual basis for your statement. 
> That is OK. Thanks for your time. 
>

It is a pity that Stephen is not willing to engage on this
subject. I think it is quite important for people like me,
who are skeptical of some claims made for Lisp and who are
sometimes inclined to be excessively vocal, to understand
these issues in enough detail in order to make statements
more resembling facts. :~)

Personally, I have found the following pages by Marty Hall
especially useful:

http://www.apl.jhu.edu/~hall/lisp.html

On this occassion Marty Hall has a brief tutorial on macros in
Lisp that I think is clearly written and easy to understand but
which seems to me to cover the major issues related to Lisp
macros in comparison to macros in some other languages
and to functions in Lisp:

http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html

Most of the points made by Hall have to do with the sometimes
counter-intuitive but extremely useful properties of evaluation
in macros relative to functions in Lisp. The need for and
importance of delaying evaluation (which can be achieved by
macros in Lisp) is something that should be quite familiar to
most computer algebra developers. One of the most common
mistakes made by beginning programmers in Maple is sometimes
known by the suggestive title of "premature evaluation". 

In fact an issue of exactly this type was raised by Alasdair
McAndrew in an email earlier today in "Summing over a list". 

One of the distinquishing features of Lisp is that it allows one
to freely mix both macro and function modes evaluation in
the same program. As Hall explains, this is possible in Lisp
because in contrast to most other languages (which do macro
processing strictly during the "compilation" phase, one has
potentially the full power of the language available to you
during the compilation of Lisp macros. 

Perhaps this is also to what Steven Wilson was referring
when it talked about Lisp macros operation on "data" or
rather emphasising again that there is not clear distinction
between code and data in Lisp. 

Hall also explains why there are good reasons to avoid
using Lisp macros when a Lisp function will do the same
job. To obtain the same effects and control over the evaluation
time of expressions in other languages it is often necessary
to resort to considerably more complex manipulations. 
Arguably perhaps, this makes these languages "safer"
but at the same time somewhat less "expressive". 

Gaby, does this point of view make sense to you? Can
you give some simple examples in Boot that are similar
to those given by Marty Hall in his tutorial that would
illustrate how to achieve similar effects (or to avoid some
of the negative effects) in these cases?

(Yes, I am impatient for the Boot documentation that you
hinted at earlier ... :-) but of course I understand if you have
other priorities than responding to emails like this right
now. 

\start
Date: 23 May 2007 18:37:15 -0400
From: Camm Maguire
To: Cliff Yapp
Subject: Re: gcl, shared libraries

Greetings!

Cliff Yapp writes:

> --- Camm Maguire wrote:
> 
> > if 1) GCL is currently deficient for axiom use in some regard and 2)
> > we have difficulties addressing said deficiencies via changes to GCL.
> > If both of these are true, I would greatly appreciate you and/or
> > others letting me know the details, as it is and has been a goal of
> > mine to ensure that gcl remains optimal for axiom use.
> 
> Camm, while it cannot (yet) be said to be part of Axiom, the cl-web
> code does not work on GCL at the moment.  There are two obvious things
> I know of and probably others I don't (yet):  1)  read-sequence doesn't
> seem to be present in GCL 2) I'm using trivial-utf-8 for string->array
> and array->string functionality, and I don't know how or if that would
> work on GCL.
> 

OK, these functions are in 2.6.8pre now.  Please let me know if 2)
presents any problem.

> > I must say I'm less than enamored with the cl-foo library development
> > model. Its source level as opposed to binary, and there is no shared
> > library memory savings.  Beyond which, there really doesn't appear to
> > be much of anything available which is not provided elsewhere in
> > faster, smaller, shareable C libraries, though I haven't made any
> > exhaustive study here. 
> 
> I'm sure there are a lot of opinions on this one.  I'm not quite clear

Yes -- by no means do I suppose mine is correct :-)

> as to why the source level is objectionable (don't we simply compile it
> at build time anyway?).  I like the all-lisp solution for the simple

source is not shareable (system memory)
source pushes on the user all compilation problems and time
source presumes more user expertise, particularly rare in lisp
source leaves more work for the user and less for the provider
source consumes more total system resources
source is less well separated from user code
source is easier to provide, and tends to therefore be more changeable
       and less 'hardened'

These issues are reminiscent of gentoo vs. Debian, bash scripting
vs. C code, and even axiom's decision to ship binaries and not just
source. 

> reason that it avoids any reliance on the behavior of the C language or
> compilers, but that's just me.
> 

All that is taken care of once a binary is loaded, in principle at
least.  With source distributions, we depend on the behavior of lisp
*and* C compilers on said code before it can be used (efficiently).
And, sad as it may be, if rely we must, C is a much stabler target
than any lisp, alas.

> > The primary goal should be in fulfilling the ansi-standard and 
> > supporting applications from the past, while offering non-standard
> > interfaces to newer functionality in external shared C libraries.
> > Do we really think cl-fad has a thirty year lifetime ahead of it?
> 
> Is there any reason to suppose it does not?  If it does not, why not? 
> Can it be improved to the point where it DOES have that lifetime ahead
> of it?  Will the problem it solves go away as Lisp implementations
> improve?
> 

I think of this akin to the lifetime of my scripts, vs. the lifetime
of my portfolio optimization code.  Or Joe's sawfish code to change the
color of icons consistently on kde and gnome, vs. the Linux kernel.
In general the quicker and easier the solution, and the more possible
implementors there are, the shorter the lifetime.  It is a question of
weight.  No one will ever rewrite axiom in a similar time frame.  


> > How will we coordinate with all these cl-library developers external
> > to the axiom project when they move on to other things in life?  
> > Will we read all their source and maintain it ourselves? 
> 
> If that source is literate (in the true literate programming sense)
> this should actually be possible.  Also, if the solutions developed are
> good enought that not many changes NEED to be made, it becomes even
> more viable.
> 
> The core of TeX has not changed in any major way for a LONG time, and
> it is STILL the best tool for the problem it solves.  This is the kind
> of development I would like to see Axiom pursue - the solution of
> problems in such a fashion that there is no need or incentive to solve
> them again.

Could not agree more here.  So we should not rewrite TeX in lisp, but
rather find a way to use this excellent tool from within lisp.

> 
> There should be NO dark corners or black magic anywhere in the software
> chain.  We should be able to look up the code for any point in the
> process, and read the explanations for purpose and method wherever we
> need to.  I know this is not possible at the moment, and maybe not for
> decades, but it is still a goal I would like to work towards.
> 

Agreed.

> Anyway.  Thank you for the work you have been putting into GCL to help
> support Axiom!  My only concrete question at the moment really relates

My pleasure.  And thank you so much for your tremendous contributions
as well!  Axiom owes so much to dedicated developers like yourself.

Take care,

> to read-sequence - is this something GCL plans to add?

\start
Date: Wed, 23 May 2007 18:10:34 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Boot, Virtual Machine

On Wed, 23 May 2007, Bill Page wrote:

| (Yes, I am impatient for the Boot documentation that you
| hinted at earlier ... :-) but of course I understand if you have
| other priorities than responding to emails like this right
| now. 

(1) Boot is *essentially* a syntactic convenience and other 
    administrative stuff over Lisp.  The translation is pretty
    straightforward.  So a claim that the equivalence between data 
    and program is lost for the prupose of Axiom needs some evidence --
    otherwise, yes one could just as well argue that pigs can fly.

(2) Yes, unfortunately I've gotten some other more pressing issues
    to sort out today (and probably the next few weeks, but I hope they
    won't keep me busy all the time).  
    [ They affect millions of people, far more than Axiom and Boot ?-) ]
    
\start
Date: 23 May 2007 18:42:37 -0500
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: gcl, shared libraries, was Lisp portability

Camm Maguire writes:

[...]

| > directories -- to gain portability between Unix and Windows
| > I tried to use Lisp code.  But each Lisp is doing them
| > differently (and apparently some operations sometimes are missing).
| > So I got a maze of conditionals over Lisp implementations.
| > Looking at resulting code I feel that it is better to
| > call operationg system utilities and have just use 
| > conditionals to choose between Unix and Windows versions
| > of file utilities.
| 
| In C, we call this #ifdef hell.  There is no good reason for it, in my
| experience. 

Fully agreed.  

Some of us would like to see Cpp disappear, but after spending time
and resources thinking of it, I don't see how to make it disappear in
the immediate future.  The best I can offer is to avoid it as much as
possible.  

If that can be of any consolation, I would like to offer this message
from Doug McIlroy on Cpp and similar stone-age constructs (when some
people suggested its inclusion in Haskell).  

        http://www.cs.dartmouth.edu/~doug/

For those who don't know Doug McIlroy, suffice it to say he knows what
he is talking about :-)

  http://osdir.com/ml/lang.haskell.hugs.user/2006-01/msg00006.html

     A recent posting that expressed a desire for #ifdef struck
     me as perverse.  A prime reason for using Haskell is its
     elegance and clarity.  To adopt the most inelegant and
     turgid feature from C would be like encouraging graffiti
     in a museum.

     Most #ifdef's and #if's memorialize failures of imagination
     or care, often in the name of "portability".  Code is
     NOT portable if it has to be rewritten according to the
     conventions of each environment.  Ifdef expresses just such
     rewriting, and in an egregious style: it inverts the
     logical structure of a program, bringing the tweaks to
     the top while fragmenting the real architecture.

     To make code portable, one should first get rid of system
     dependencies to the greatest extent possible.  Then treat
     the recalcitrant residue with the same sense of style as
     any other programming task.

     Some standard methods that apply everywhere in programming
     are equally helpful for portability:

        Modularization (sweeping systemisms into a corner)
        Generalization (rising above the systemisms)

     For dealing with the recalcitrant residue, a method that
     Haskellites should find specially sympathetic is

         Specialization (freezing certain parameter values)

     Ifdef, if course, is a specialization technique, but from
     another era.  If there really is a need for specialization,
     it would be far better to employ a Ershovian specializer
     that creates Haskell from Haskell rather than from
     stone-age idioms.  Is one available?

     Doug McIlroy

What Doug says holds for Axiom word for word.  An Ershovian
specializer exists for Lisp as used by Axiom: It is the Boot
translator. 

It strikes as very disturbing that Axiomatizers would like to convert
people into thinking mathematically about software and yet would fail
to apply those same systematic thinkings to the programs they write;
and in particular would consider that long list of #+ and #- is a good
way to structure programs.

\start
Date: Thu, 24 May 2007 10:11:19 +1000
From: Alasdair McAndrew
To: Martin Rubey
Subject: Re: [Axiom-mail] [ANN] new version of axiom mode for emacs.

Lovely stuff!  Well done, Martin!

I found the green output a bit garish for my tastes, so I changed the output
foreground to blue, and the background to white.  I have discovered one
problem, though:

)read newton )quiet

The axiom mode interprets the initial )q from )quiet as a signal to quit!
So your idea of not trapping )quit, I think, is a good one.  Though from a
brief look through the code, it seems that )quit is supposed to be
abbreviated as )q only at the beginning of a line - which is well and good.

But at the moment, my line above doesn't cause axiom to ask me whether I
want to quit - it just kills the axiom process.

-Alasdair

On 23 May 2007 15:35:26 +0200, Martin Rubey
wrote:
>
> Dear all,
>
> after a day of hacking and with some help from Cliff and Jay (many
> thanks!) I
> have a new version of axiom.el, which you find attached.  I'd be extremely
> grateful for feedback!  Alasdair, is this usable for you?
>
> To use it, put it into a directory where emacs can find it, gunzip it, say
>
>   document axiom.el.pamphlet
>
> to obtain documentation and source or
>
>   notangle axiom.el.pamphlet > axiom.el
>
> to obtain source only.  Then start (gnu) emacs and type
>
>   M-x load-file
>
> press return and type
>
>   axiom.el
>
> possibly including the complete path.  To start a fresh axiom session type
>
>   M-x axiom
>
> Most things should come natural, here is a very short description of it's
> functionality:
>
>
> -------------------------------------------------------------------------------
> M-x axiom
>   starts an axiom session or returns to an already started one.  We really
>   should provide functionality to have several sessions in parallel, but I
>   don't know how to do this.
>
> M-up, M-down
>   moves the cursor to the previous or next input.
>
> C-up/M-p, C-down/M-n
>   fetches the previous or next input.
>
> M-k
>   copies the current input-output combination into the kill-ring.
>
> S-up, S-down, S-left, S-right
>   turns the cursor into a paint-brush.
>
> M-x axiom-paint-face
>   changes the face of the paint-brush.
>
> return
>   evaluates input.  If point is on a previous input, it overwrites old
> output
>   ``nicely''.
>
> -------------------------------------------------------------------------------
>
> Changes:
>
>   * I modified some keybindings and instead of axiom-mode one calls axiom
> now.
>
>   * I provided support for painting.
>
>   * by default, HyperDoc is started now.
>
>   * I fixed bugs that positioned point incorrectly and screwed up
> overwriting
>     old output.  Cliff: you said you fixed that already once.  Could you
> see
>     whether you had a different axiom.el.pamphlet than provided on
> MathAction?
>
>
> -------------------------------------------------------------------------------
> ToDo:
>
> * Testing: does it work with xemacs? does it work under MSwindows?
>
> * the way we deal with system commands like )quit is unsatisfactory for
> two
>   reasons:
>
>   - we do not allow user interaction: )quit will quit without asking, but
>     worse, )di op 1 will make emacs appear to hang. C-g get's everything
> back
>     to normal.  Reason: )di op 1 will make axiom ask whether we really
> want a
>     long list of operations.
>
>   - (1+x)q will be parsed as )quit.  We do not check yet whether the first
>     non-white space character is the open parenthesis.
>
> * the underscore character does not work.  It should...
>
> * the way we wait for output looks extremely dangerous to me:
>
> (defun axiom-wait-for-output ()
>   "Wait for output from the Axiom process.  Point is set at the end of the
>   line."
>   (while (and
>           axiom-waiting-for-output
>           (not (search-backward ") -> " (- (point) 5) t)))
>     (accept-process-output axiom-process))
>   (sit-for 0 axiom-after-output-wait)
>   (end-of-line))
>
>   what if output contains ") -> " and we are unlucky?  Not sure whether
> this is
>   a problem though.  In all other places, instead of ") -> " the regular
>   expression axiom-prompt is used.  Shouldn't we do this here, too?  Isn't
>   there a simpler way to look for output?
>
>   In fact, it might make sense to keep the current output number in a
> variable
>   -- that way we could also detect errors.
>
> * It would be nice to give the output a different face, as in mmm-mode,
> but I'm
>   a bit lazy.  Maybe today evening.
>
> * S-return should overwrite old output while return should copy the input
> line
>   at point and evaluate it at the bottom of the buffer.
>
> * it would be important to have the possibility of deleting part or all of
> the
>   buffer.  (Personally, I often have a buffer with a 100000 lines, which
> is a
>   burden for emacs, it seems). By contrast, it is not necessary to provide
>   functionality as stated in the section "Restarting and Re-evaluating -
> Kill
>   and Restart Axiom without Erasing the Document" since such functionality
> is
>   provided by axiom itself.
>
> * it would be extremely nice to have command tab-completion, as when
> starting
>   axiom in a shell.  (The polymake team would like to have this, for
> example.)
>   Anybody knows how to go about this?
>
> * undo should have sane behaviour, whatever that is.  Possibly, it should
> be
>   restricted to the current input, but that might be too restrictive. (For
>   example, if one has overwritten some important output by accident.)
>
> * sending definitions from input files is still not possible.
>
> * cleanup is certainly necessary.  I don't know elisp well enough.  I have
> no
>   idea, for example, why
>
>    (end-of-line))
>
>   in axiom-wait-for-output is necessary.  Really, every function should
> state
>   in the docstring where point is supposed to be before and after
> execution.
>
>   It is extremely important that this mode works reliably, and as it is
>   currently, I wouldn't be surprised if it would screw up in weird
>   circumstances.

\start
Date: 23 May 2007 19:13:00 -0500
From: Gabriel Dos Reis
To: Camm Maguire
Subject: re: gcl, shared libraries

Camm Maguire writes:

[...]

| source is not shareable (system memory)
| source pushes on the user all compilation problems and time
| source presumes more user expertise, particularly rare in lisp
| source leaves more work for the user and less for the provider
| source consumes more total system resources
| source is less well separated from user code
| source is easier to provide, and tends to therefore be more changeable
|        and less 'hardened'

\start
Date: Wed, 23 May 2007 17:38:18 -0700 (PDT)
From: Cliff Yapp
To: Camm Maguire
Subject: Re: gcl, shared libraries

--- Camm Maguire wrote:

> OK, these functions are in 2.6.8pre now.  Please let me know if 2)
> presents any problem.

Wow!  Thanks!  I'll let you know how it goes - I made a mistake and
started building cvs HEAD (2.7.0pre) so it'll be a bit longer...  is it
in the ANSI version of 2.6.8pre?  (so I know which one to build...)
 
> source is not shareable (system memory)

Erm.  I'm not sure I follow you - do you mean functionality defined in
a source file takes up space it would not need to once compiled and is
not accessible in that form by other routines?

> source pushes on the user all compilation problems and time

Heh - I guess as a Gentoo user I'm no longer even remotely bothered by
that, but it is a point.  I view it as the continuing reaffirmation of
ability to bootstrap.

> source presumes more user expertise, particularly rare in lisp

Well, knowing how to compile and load it I guess is a point.  I'll
admit my first run-ins with Lisp were a bit confused...

> source leaves more work for the user and less for the provider

True.

> source consumes more total system resources

Only until it's compiled ;-).  And disk space is cheap.

> source is less well separated from user code

Um.  Not sure what you mean here?  You mean there is less temptation to
"look inside" the guts of a library and violate library boundaries if
the provided file is a binary?

> source is easier to provide, and tends to therefore be more
> changeable and less 'hardened'

But that's a key advantage!  The trick is to make it so there is no
need or desire to change it, and I admit that's a doozie.

> These issues are reminiscent of gentoo vs. Debian, bash scripting
> vs. C code, and even axiom's decision to ship binaries and not just
> source. 

I'm a Gentoo user and fan :-).

> > reason that it avoids any reliance on the behavior of the C
> > language or compilers, but that's just me.
> 
> All that is taken care of once a binary is loaded, in principle at
> least.  With source distributions, we depend on the behavior of lisp
> *and* C compilers on said code before it can be used (efficiently).
> And, sad as it may be, if rely we must, C is a much stabler target
> than any lisp, alas.

My understanding is that sbcl and cmucl use a working lisp binary to
bootstrap themselves - I know GCL uses other means.  Of course SOME
binary is necessary, and at some point in the distant past someone must
have written the first compilers in machine and assembly code.  There
are discussions from time to time on what could constitute a minimum
bootstrap compiler for Lisp, and I confess to being interested in that
question.  Hopefully we will never again have to bootstrap from bare
metal, but if we do it would be nice to know how to do it.

> I think of this akin to the lifetime of my scripts, vs. the lifetime
> of my portfolio optimization code.  Or Joe's sawfish code to change
> the color of icons consistently on kde and gnome, vs. the Linux 
> kernel. In general the quicker and easier the solution, and the more 
> possible implementors there are, the shorter the lifetime.  It is a 
> question of weight.  No one will ever rewrite axiom in a similar
> time frame.  

True, but no one SHOULD need to rewrite either one.  Rewriting is, by
definition, a duplication of effort.  The less rewriting, the more
original work and the faster we can attack new and interesting
problems.  (Of course, that means any new and useful code has to attack
the HARD problems, but still...)
 
If Freespec had been able to get off the ground, I would have liked to
see it follow up on some of the directions the ANSI committee pointed
out but never implemented, that would have solved a lot of the problems
we see today.  Unfortunately, some less direct means than building off
of dpANS3 must be found and that will take a LOT longer :-(.

> > This is the kind of development I would like to see Axiom pursue -
> > the solution of problems in such a fashion that there is no need
> > or incentive to solve them again.
> 
> Could not agree more here.  So we should not rewrite TeX in lisp, but
> rather find a way to use this excellent tool from within lisp.

That's a point, and I think LaTeX will be by far the last non-lisp
dependency to go, if it ever does.  I would be very happy to see such
an interface - was there a project somewhere working to expose more of
TeX for non-traditional uses?  While I am in awe of the algorithms and
how well they work, I have always been a little puzzled by the software
"stack" of TeX.  As I understand it, TeX is written in Pascal which is
then translated to C which is compiled.  So it relies on the language
behavior definitions of Pascal AND C, or more specifically that the
translation routines of the behavior specified in the Pascal language
of the original author are faithfully translated into C code that is
interpreted by a modern compiler in the same way the original author of
the translation routine assumed it would.  I am not all that familiar
with C and Pascal so perhaps this is reasonable, but it always struck
me as a little... odd.  I admit it has been effective.  I guess the
copyright restriction of no copying at all of the core TeX file unless
it is kept identical helps provide stability, even if the open source
advocate in me gets the jitters seeing it...

Actually, as I understand it cl-typesetting has already implemented
large bits of TeX's algorithms in Lisp, although not yet the
mathematical routines (darn it...)  Of course, it's almost completely
undocumented, which is frustrating and ironic as all get out
considering its conceptual ancestor and the fact it's a typesetting
system...  but at least its license is now compatible :-).

Whether it is worth bringing cl-typesetting up to the level of a true
TeX replacement I don't know (although I am sure everyone else would
quickly answer no, with good reasons behind it) but TeX does its job
well enough (and that job is hard enough) that I am content to leave
pondering that task for another day - there are enough low hanging
fruit to pluck.

\start
Date: 24 May 2007 04:43:39 +0200
From: Martin Rubey
To: Alasdair McAndrew
Subject: Re: [Axiom-mail] [ANN] new version of axiom mode for emacs.

Alasdair McAndrew writes:

> Lovely stuff!  Well done, Martin!

Thanks.
> 
> I found the green output a bit garish for my tastes, so I changed the output
> foreground to blue, and the background to white.  I have discovered one
> problem, though:
> 
> )read newton )quiet

This should be fixed with the version below.  Unfortunately, pamphlet
documentation and code are a little out of sync now, since I did a bit of
cleaning.

The main source of bugs is recognising when axiom has finished a calculation.
We really should switch to keep track of the input line.

I hope you like it,

Martin


--=-=-=

H4sICOL5VEYAA2F4aW9tLmVsLnBhbXBobGV0ANV9+3fcxpXmz8JfgcPNDMmkm7bsk50TOfaElmWb
u3qtKK/sYzlLdHc1CRMNdAA0KcbH//ve7z7qgUbz4czJZnVmYqkB1ONW1X1+99b7RTPfrFzdz6ui
634p2r6cV+7XPHu/6dy6mF8W5+6X4kPZrH7N/i37tzx/2fQuL+t83TZz13VlfZ73F2WXWzv5NO8b
PF1s5o4eudxVZbfOl2XlJnm7qdEIfl42VdVc4/t5s1oV9eKJdFA3fVGfVy7nXo9cdbQuVuuLyvX5
F/43efVt6KjInxdv3fd+GNqVNHjtZtutycPri3J+kV+XVRWasjd794Feej9z52X9izX8a/a+L/vK
/fL+d6evj7/6qGvnH7lVMe/ku1WzcPQtCFhs+oum/eV/FDf5l66iObl2kn/dFvW8IXq9KKre3Uzo
v0TyOn+zmbmbnKiQP63K5TL/oVivqatVcem4OxtGMev6tpjTMPL8GXdLbTW1y5slU3XVdH2+btab
qmhzV1+VbVNj2B3Ru80X7spVzRpER1cbLB811DXL/rpo3VGeH68aeljS+7QkNKBZWZV96aibPp8X
Na1879plQWS6LvuL3H2gf9YFE++8LVYdtYaW6Z9X5cLx61VVnmNjdDd1X3zIL8rzC/rloscoMKiC
mqJXr4q2dP0NJgJibWjjdUfU3FvsruumvcRMaQRF37vVuscuA3VoEjz5Im7ACCAU0m1sY1u4ZUkE
o6bkcUSlvN/UbpF3azcvl+W8qKob9EMnoySyHmOB0V+LgSzQHC8xDfO9qxfR2rx3P7t5TzulmFWu
Wc4bIgOtgf2eve/oP2VT//K0Wd+0IAaP7Hk5d3XnaG2z7+qqvJTzc1VQ36vi56YtZXY8joluXSJK
JZ/RetYL1/I3L5oFTYB++vL0q0yfT+SgyqSxT3d8+83r50dKdvq/dVuuiLBEiMWGxtNkPCTX3tAq
teeODm9VyWR4FRaLEn+nHRH66ajZgmbY8mIt/MphOFlM/YK6o8PaLjcV/k5briTaZn/+89zI9MUX
n2effZYHsh08Pcwf/+lPf5zkn3z88X/n//2PfHaT3+vUoamxg5f9BZ0qabRLpofuctBl2TrnD85n
+U2z4fPRugVtlbacbcAmeVk/alo0sMKS3OC3QGo6PKvOju43L7/Lv3G1a4l4rzcz6t42BBEDLazx
Y3dBFKQJ4ouvMYZTHUP+dUMNF6D+Z7mjw0l90Dp1WJlPqA+0gI+e226go3dAy0Ijb/Nmje8Oc5z5
qujDp0f4zP8ZI0SY7wJyAV1cNGsna06zZd46c/iUVp+WdpLTy/m7k7ffvvrubX788of83fGbN8cv
3/7wGTOVhp4Sn5KmytW6on2Mr2mStIxyBF48e/P0W/rk+MuT5ydvf8Bcvj55+/LZ6Wn+9as3+XH+
+vjN25On3z0/foNPX3/35vWr02e0rU+du4vY4Emrhgi6cH1RVt02CX6gxe5onNUivyiuHC363JVX
NP8ix07dvaD42K9pBU7LXLSPSPpZXi4hA+l803nHifNLja9HVnuSn9Tzo0n+xz/lb4kzkuR8XRGD
nuSnGzTw6acfT/IvSSzQm2jhxXH+8SePHz+ePv6Ujsp3p8dZ9pc88yzLONNJ3bM85JM91dOMY3Is
ykD2ljaY40O9zcDjs19cERHBB0lM8VTeNS0R7h0+eedmyscykxiF8DusNTe1dEW/aZ3IL2IV/Ya5
MjZqX3QkFFYFyUW0b9KLOFTTycg62kegvrBKnM8ZPVjzljLKzi+oQUd8gg8iBE1p68JTfZKZ7CVq
rsq/E3t+j7/l70k/6GfLX1ar1RRT/ZXIxIeDeWsB7abjHlRC0fFfEsmIzzF5SHycnTFb56+7/X0c
nyKHTK7AGj70rDTRtL4sOhFGE2Yp0rLQWHQtUI7aw3aljbsYEfy+75am0tQ81znLgKhP03GOBjM8
3sxJt8L85G849phY1xOrsN1OHFV1MAcZwIpFzNwxjFRH64b9PHtBOtSq8ISEwBd94YZY7Zp+Iu20
AKPZktzU2bx1/AwdsQzkxqBdrjfgaEV17mYtTfamo05VZvs1jfdz1TXU34pU1w/okrZDvKHRvopg
IT2rU3m9Wc2oF2K0QWmKtEvSGq7AyFX3tcMr1Iv0Z5J3z5uG9yDxT3q5c3aQ6PDh49q5RRfrAY53
9qItrvPNmkaiR4ZkOx2kdDyktjHbEuWCZulkB9Sq3IR5hm3vaGZ0inq/8Z/S/mlou8gnHawA7Chp
R1qYbbDfcCLzGTavKpI3wvuL/LxpoD8taS/PSDvDUJiTgrZdSWe85yaFfoum3tdtzy+QWJ81GBD+
tSJ9kIhlWyndYbYVo+Ocn7wKQy46a4L2zZp2sAljGptfEFK0dSvpSetkxZabei66DvQyDExes6Gc
RLrvBS1ehYHYsRucUNoOoJ+uaFnPqw1vK9JRch5YOWeF9jmZUsTYyfCYCDOuFtQvWrReTzfrddP2
ouJ7UUQEu9Kz7q2pguVINJCoY+r1LtW94cZcO51fECEueZ1NE462TJAobzc9qbBFRb+d1EJCfYR9
SWSdkxqhuuWMRMmSTv0FLTntDXBQEZKiyrN+6rJgQooFpoZkx6dYF4vMSrPguAdWdHQn/8gm20/g
Y1h6GBfxloZW0To6SjXzWTyuiMcsbuQD2jJkeNFQ3mG70APIJVULTJqle8R2uYml+OjQIkMOiXZE
7Z3otr8k89XIsGiYCrrUP76YbmgzvJgumuv6Jzq0V064y3zTduCBIt/Wrbsqm02H2dQQKmVN/NDa
eEptfPRiSu085Xbo79TW0vXzC23t9u9fTC9/gtJThr5ZzPBLU1Ll6D9YlxnJaF5q2lYyrkviitM2
HN0fT3k6pzwM/Ldyyx7/ZUX/p1zXIcyPWyr4fNBfp7N2010cxQs7lQewVn+CmGcZz+wX9quejJGP
Zc1/IiW0qIgTwfjlKdOiwLQsMb1O978Rh99g8UzL0LLqBgnf0F5QIpyd1aT5VTf7+3pIkv2YnfTK
mukI4EUs3zkplTxIbaKI5PiSVbyC945pIEfRaTvtW1LeNq04aEhfJFXiV5g1v4dBk5hUsa1Df2/d
3zYlaVz8D+ZIp9jum/X/JgUPipY8+a5njj7649e67eVH/pzGwW3xL2/J7qENUZGZKn0+42f+n6+V
R+kP0E/DzLSP/CvY8WxtdiK+lcGrZ8oMDziChPOJUBKvh8ipfeYZtKDZgfKOKTs4aFnpfw9zJWpM
k8+zA/1Hvi/fHmawF49VAN6YIj9JXRJXRifm28YXhFWJR0I0FxaXGaRk7TCNgrjhz82so933ddl2
Pct7npr6MVglKFZBDzMisIEGP4VoZ+eic2FfzWLuuHuR2e71/xbb/fqCDLNOF1QInh3QSGh60vNU
CZnv7R3mOduL0KtYlbNZMy8DhVcyAXqIo+ZEOyh7UXGyfPcf2LI8DyPdzC1hss0chtU54k82qqoh
1Xld9BfdIT77LszCFe38ws6HaIU5XhxMiEjX5XvTupkTR9JJnZzXrGhzQ8ffn7x6Qd9jkiDS0aAB
ojUcVnt/PXj//uDHj6d/+ukP798fHubTL/K9w8G72NFTGj/I2+UHrMLtHdIP+Qqb4dzB59RUTUF8
ZUmjkc33ltVE/5nt/E1dwownSVPD5dJDCxaVik0UOS7Qs2sRqGRv0A7LKqzKjt1lq0vUx7lShQXf
0vFsamiWtYsVJZeJb4E33qLs2BJES7Q9SaOntYl8imgZVE6UD+sSLWcbOfxH3CXtnFZ77DZs1Ql/
f/Psm2ffvzathfqlsdQ9vC+9cYlMFqWziZPKdDEYexEmC1eGJ2rHgl8OAenbfZPF0yKtB54XcY5d
NRWdOlYqdfk6pTo09nP2DZAay7sIawrNqyrJSCG2Ac/XOzVGcB54HuB3pEv83Yl9EpgKWIc4bmh8
fKi3+TOfZ+Oe/tPBBsTOmF6QBUJSqBruTuWgI0+M6Y48ElWAJN7wwXXByvmUxm6aQj98R46lZyoj
zRdLmrV+z03mjz/+eHwMaqLtfRwdO+Hh06ro+jBS6YeE5IWbX9LwPrB+SZIIhy3yIdOOv3J16ep5
UPW6mPqRIEyo71/mcWzqlL4Hh8T79t6wGsKbSn8nASPHt98SdnSK6TzWRM4JBp9nDbbhddm5PWrr
AGM+0HfX6ZId+gfWffoYLCYZpJJ6WVbYbgdd3/JwYbWqP79216IQ5XLKjvJT14s7j3/FaHTBZUk6
HiQfA7SHTUHsiiaaMFDtid4kTve3sZU94K+m0kT+mL/Y/mRk32G9tyaK9+KXZFneYYthnvrrkga3
vSAwfbExycZadJOgNYKTi11PlhdMYGOs4D1HTIZyObr3VRweFPO5W/e2PDa2dM1kyrRXiCnx2u+a
ePbo0UHd9CAPhOEUxjiGTDKHxVN+MKXtgcEf5n88pOOp5LznOPjtg07ImH+868RGlC+7qbyku1mJ
/hQH0TsslrcegKM7d7xpFgfub2Hzw5m16YZnY58a5Z3x5z8r85XNeEGEYlVVlZ7KFfVmDQ6hEyH+
sGATRnfvgS5K66ZDWiebHIc3Jgi3w4q6vfGwlobv0kLc3SnCM747tp5z5t+0Ei/okUhZ8SSyESSH
PD+pI18FG0PnrleTq3RiFq9dCzcQFAOJ4KghAwcIgo4LNFwspk1d3fBCYpPAPzi1j3MZEO1McOrH
tEasO6g2PvVOCp3A4W2NoIV9GdvtL8a9tQ11A1fk5c3Or8L73AVNqSUNsr7jq2hQngjJwhTgu2Q4
2elhjUU2hJyRDqdDTsZFwdbNmuwoxDSpVXbbqKBtIsECOuuJuS8fyJRv0Akal6D69mHMVtksxmx7
MuU8V1W2rux/bIa6ieG0Ojgo64tyRhwlJZAeaCYgmMC0WUafjhL71nFvLXOe//aWeHvGwtOPit77
7SMNS4JtmdBD7YLvaii2m5oUw0qUX1qIYlP1iXgW44xoykrqjRxGsjJXGzI+LFqeqWI7bzeRXwv7
iHmfWHGb9ZMdnPJz2wP89nSzTrjZLUvrrUCZK8sOEMLMIdbU0nfEFlRP1KpoL1Vl1W103vTNdH5B
up+8PiXiBi0hYZJ7B4+x//fSp+FwDB+TijE+SuuJB7N7IMWHw93MfU9tRzMcB32OzXq0W2IQ/uyO
j3ZXe4dBci4c2MpUZcBvambH/Okp7dxtyfp5qpzp78r8YvUuMUUGzyID5lDiniHs0183ArMQ20iM
1sYiGlMO58rfD6KTdMin5Xt+cJR96eYFnNUMXYBPu2zFMmRnhf1V0Cx1PiMl3QLtHgaAkEXTws2T
rYobb/rpOZSOPEJFgglQKEuiujdmA7JqIc6iDO6WeQ/h8L2HDYmzhO1Z1hG7rjyvxdiF17lyi3Me
buGNRQFjDIyiz70tpQrYVJ7kBxqIWuf78ossbeSijN1Iv2ZZMI1nzvvYxV2ngAbQiJbJO/qn+dkZ
r+z+vgFiXC1mLXHQthg44DnsJY4HGEqY9dmZuW/29wOkptCwlfgKfDyAWBLR+FWdvyOtDEHYg4LX
7Y8fffoR8CeH/EriEPLh7wmZ7FjU66LuB/sBLh2yXBRw1K3pcCZBMOzQaydtcwDBOjjKGI4n/gmn
EQPbMRw54B31oaClh2dLHGz8Zvpaucw8IeHoT6hSmtOQnVsMu+MeSQhNJHTjXUV+62VGeBYIpAZO
E+9gdJy3npk+c8r8T5VN9uKZk+718dtv/Z708V5xfCLQ0N7shYMf/H9ECDef4q/CF8Q+Cs+Fuake
gtD7FB9sGMQ1JU5D1v6cpn0wH3gV9z7irvci9jjsOZZSMT/yztK0ha3vD+aLpE95EY7IJcd/4Qwi
ZghgHMlvE/K0araMPOFNXYExEuPfEDHHR5DtHqO1tac8WryOzDovhH1eusi1IcHc5IxzsEw8acRt
3EqdZivEOSXWBI2HNiAAUtj2TwT9BWko7rbpMvaopBJBtCS4JdWBQn97/ebVN2+OX0gAQN4wb4rE
hN98c8p8oKN/wrPSEO8WC1J0EnZ+7h3Hy3Mg705JemlTRNIrouhBsV6zZsZu2322orRPJW9KUrK+
6Q+1iO1Bza4rOH/FeRF8z4epEk3zk/MSJqmO3BDjUEcC/Kp09MsrVi5pt3yjbpjIi0tnGu9unUL9
As3zYbdPUloJHuFau2W7e7AW2s7L5poYYN+06u9Xwg3clqPC+kCVB/33obbIFmPs1zW5XwDnUFXD
1uwxT1WaCr8Nu9A+GIUi7K3jIKyuJu9g0mqa8xq+2ODZUqV2iofEzKUVY8/Ez6rStT5mkZjgIuZU
kPqhKx3lHWhb7sM6+U4HerxYDOIruswYrXjqmIlX5qSTLSMfx0OHDvEODJCxvqmN0MwYxLKYyIzk
4xWpYR3AGaa/qFkH65N91zPHsRYgW7A9FgucGzkgOrvEoRgOeGoy6WOd7zuBweBMk5FCM2HHLwIQ
HBD0MoEDGqRRAO9IBJ4Lm+KJSUM6a4DCaHnEE29nVcM5ggA2wBP7/PUwHNneNhkcBR/4yxKA0KEi
r0TvgPJjA53kPBgh86NzqEtwLrK60zdNBSVH1Emv9MnySjszRxpB2bQedhdM6TvZvHkI2RoYtTjY
vsl//Gv+k5o63lX0YC/gLWMKguVBw/oHBnMvlySJuFRFtUXDbrcorKlzjM1oNucXtFzXGrYZqHqZ
Bs0CTCXR+4re9peISc8mDMilaDD7PFN+Asdbb8CTmZpdjj3synqYnL5XVoLPzhBUJOUOmmDTZwKP
kAiY+uTFDYA59hcbm3ivyGVTMbx8j76cZMIQ59WmE8iHerhlFoiRr+BM0KmTWrZuDQnD/ZV0Jkhj
5YCfDoYtD9MBbCpbKsDwhYF3AWkNI2FWr3XdYpDbpuRGgr+hrIklqkrIj4IOqBxcemX9bfyFQZDM
O85GXxsPmfk3laHC1yctRs9um1zuBfcg5qGeJLKT34E7FbwZaIuVwCbYDmUjINXnlozP0Q3AStwA
BPL5uFVwi7Y3uv4CXfYIM4WVIP1BIZ2SECPGHAe9Gwkus16kggIb8unxqaFajS2JaCAr8ejyqMh6
a5sxIUGPnQtNDParVhSHUel0QYf1kkcgrRnOn+SVzFzI2UGvTZ2MjRvEAEl+gWuSSAEYUaDxzGq2
MigwBWC0aMK6LgIq6nqM1VCfAWvNOPcEWpsNMbuKYMZfSCfoAMhnmNu1ISeENXK3J69EC71m8/go
k2wiFsQG496CoPaIlFtX5RB8OsBcv7OviWMsWUCKVSzg0BT8BkAc/kuaebnwMn/ddIIZshyXRcOx
fg/fxSiIKUyY4THfcoUwLu8dAOpLMMfYOouCIejnpgAxJTqFXzl1GQX0AJMtrEGEdKD2apLl5wKU
wxYketp4I4zr2Rk0jhmpcrTDuv6GDp1C1RRQzHOF3iA5GDQXooX2GzBrjPEEB6kkHWrhoWu2skCv
0bjaG9FNJLCLZLNpwElLTgewvIiDFvlVyXt1ifWg81ovmNkETKymNLUBNReWZDLYHQB/w2aQnK7B
sM0pETlY1KRhF4kixBXCZ1ZmvkZqxJHPKqOuGLvZiU88oQDDZytYPN21bH8SpaIIts6jsbuLcmmv
I5VuQ0ry3zaczcTfwSkOhQ6oRlMjoY/mcO7NXEwYSwbqiitBMYlMHFLFZhgSKwThy8gCZAE0aEGw
5rQVJ4KJFuoQqTtSNukAO87aAhi1AG602yDa3hlp2dMFFOpCYK3sY8AIeM2le+mFmZTi3IXV6EP1
mS1FajJp0AWR8IaH1uih3fDfWwf8ywTqsq2ZjJgkK9a/ZvUIbg42F4HPpv9ugfjfM/1FGjBfmqoo
eMnsQewwOBhZlCjr4m6I/W5qZoGy2UtB2pmXjFiyJJ6IzMuQNCVb7O1vEgwiEkSvhy4fiSmfyblQ
dhnAfhNQQfiRHjfmzJHQyOIz593RQJ3Tnot8iddlxwa80EFcZ6bhEEHE/BBreCLDzMAP19wNlDZL
4guzYoA0k4lG23I+1MoyTMBclkgrddVSENMxhDGyXGUndQgbA1sVjNhYLEVofnU5MyjHG4OX7mZV
rDn7QFFpczVQFd+d+C9WRWnAb/WeZJZ9kj6WWS4lJ4oVUhl/eDhUSM2V+cb/wOLR6xLRpMY8Nhyq
uRXIAOfRvVEMZiZtua8OYn+LObkiOBix/ek2KEi8j32AdxpkwyNQ2bcSE7vsEkJzEyIRZMMxY5R4
omGRRBHjllIILT7W3ctyyQNBav3BFjM1EcYnpIaC2Ki3oUYs8OWdTSOvMLL9NtLuCFapb0NhvtTN
fgfvuJIMqT00bQO5sI/I+wLNywbV41ogz+BQGoj1yNDgoBuq0gO/ClaL1BJlcZp+IAtD4yjF6Vw1
mpahngiZ8TT30DMIVrMPOVN0uQQ2pH9iniDGGe5H9NJfkhCf98W5WrrVUajPD9ATtDcILG9PiMzM
qpyXPcQZp1YqECFyFJnKb9zZu2rIGuqgrbG/ExlD1aANZg3s82Gvt9cCpAUxpp7wmiXYmhDC/4/D
2PLTtWQRxChAAE4h/eBhn5UM5egUhdbybhe1mb38nZtyqIAsvHW86+mfGhCl4fVlv6F9TO1NFx5I
711ypmyJFWnQB12Xbt42tGKDd35bR8goua2T6Pl2B3B8gu8vFioxiROda8Jtsjw7faJCsQc5JcdA
LDqYV9g1yO25YRuC93wDqc12+oW6ZnLOeBNJXEaOGxnLjqB4lmUSOw36zQvR6S1tzIxe0z9s2+MM
tuXcbJlzFGswhdujur3RFCyC7ih7bdK+utHiAeLtTSJ90hurhKqQzxl1xJnqOw25N+molgIK1VII
bUsMhzZMJ2YcL9/M9ddOk8IFps7FO3rXrRk5vjTP1I8/Tr/46SdDmnJTpqtDlyyBTJAMnwiIiTTJ
POAw8/wUh03CjZ0qqiviXCXSq9lekvY1pXnoMpAULqaYZY6YHS0eMFIHpVdujPRBrDgRWyWeLChb
ptC6JEajC0Cm/0JcfiXwXTVSz9UKQJGFOsHOQ9n2mjY3MFebZ+YYHbDgiLAGBr0sXzieDntxLAm1
KlfwZInTs2kvj8ZWUoWUGDuDZeTdympr4+nHpPTu7JpZHvLMxHoXlwbS4UnrallDUMapGAGN/5TI
uZDRvBbTXMBtdM50dzBkG4I7uEF5JK3TcSm+wHsJNCzAzpe2DXumC94cEMXMenGJil7HwAtbTshG
TusxYBqPRdfeMulGbJhwzI2++PaFEkU0oK8wI01/Sk597M0InAsSnFOkxW61YIIFEDr+lo/sW9ko
ih0ZRtk0482CjraMTwyyAw5Nqz5rinZBjNrLCX410pAH8sNUZTmawimVPQXiWdJeknbH3U/yrGFg
j8KDZSPXzdi7Eh6FoTp1H8D7YDixZvYQTK0oiw/44r44XA8ENASl5vjsXpSQl6m0KLpusxI3TtFb
VjcyHen/xeCM40aLsltXxY1k9VY3fD452wIeMIuX+QBhtmuhMYrhIkfy+yELvDUhGmg2sriD944U
97G9stvLdfcCjK6At1Q974l8OiLUI4kKg6cfnWKWJEjspmlz3kA8xiTVnwZpIgaLV/yAqjv8op0a
JjmnSNCgJYS2fRAelAtwK1mY4ikxeL3UC8kEVwHKw4SGvZsS3WW59jWAlBT+N6XFy6aehl1yb1Jk
kSweJ8n2ttn7q8AxiSx/8GT5dCdZvP9oLE17mEcse3knJWzHxuxzKxQ2xl33XqhLfAcPHYWNaPQM
1krapuWCwEux7rNHsJvP61iDhRX2aCs2FQK0gIMGt4TBRmkVPVQiVkf3QjAqpS3zQ/H2b2W/C4Pw
akJC31vJGxjXFmmHPC0h6xhHuoWkoa3/anLuQtfK7rx17mp7jc9+3Pr7jYS4t/S8N+M+GLdgH8d0
BzkeB+4uZI+efTJ64I9+5wEHnsias8CedW5Uvkd6xAhC2j9OAF277N1/DZLmEU2jwf3T6akv3E1V
gMdH+MMaunk/FiKEthPMLzbOS/iqvf2VhfhQ9LkD3UWhz+8ny9UVqKvCZ3PrdCVP4y0g0gvaWYkI
0XLH6hvE05SEw/wgaXJcOsUUKiK7aaEWRi5GlZBF7AxSDanjznHGVyZG7UPJwJ2MkkC6l+l/JYbb
byeA7pmUtI/HKSFEgDdb7cXRmYcNUahdmIUdRL9y7lC+TRSF3LPVCZv1dhLJCLboowNLiCNK0P2p
4xWnQJ7bqPKgE6TMKhlSFh2nfPQ4nTfizOoEmOCBlN6ZPLEVyDD4vLhwha/hpjyxmRc+NHMLXZUD
jR/A+GF8/u5LYYRsAnXvZ/cpx4y7Voj1Sa1gaF8ECV4Hb9NPNNQVXMKcszVLS4qw+fckpNSYCzVO
3UifgOOvb6bauHJ/73mFSNgTQD7c0XglQEoTnIzm2dNI0Nawkx/fo4LRT+bxHWiXd30pVY/2hyrZ
7d+BI/iPUsZ463dag2h/e4/c/p3nZUmn/MvtH8qh9F/JP21LDGK5wGIAuNBKKTr1cMeRAkForYlV
EzOroqQilHOFjeq9p2nwwHCuipdg78OMHl8qXjZ8WfSZOUH1XCcbIQ+u/6PtjUjiXEiBHflb4hMP
DEw8LC5x74AENA+f3gCchGF8OHJzdiZlmpf7+xHMh+gTFqmUpY1iqiDqGt5clhpFJ3GM4qopF8oL
zL3vK08MSCvRqqm5U7kOxX3OpCei5Kbe9Y2eRqaOfMGG2onJOh0tmLGfrjhSTzjFXQA682YDdooi
TJuS0Snqur8hQtTLCm5mDv5z1S6GRCUhkVNBtRCx3nL5TOJKKBVMP/yagCFYmY7XgJ3bmm9VrtYN
58ShZp6CHzQ/1hTqvsm40CvMytalxc5oaG3nC9lGXn8JUTEXb3wIhl1BIgIls8rWtuhDvPRmIu5a
Zbie2ePgc8a84vSy9abF2KXKIM/bayDx8KQnkucofihhAeTdaDVZBuNyc3tPG1SBrfZ4GfY+7Jk3
/9xhi3IWPxDuQKQoxEqiINpAPscHyj2yVJtQhzuTUdWAWwvHTcypI8TKSqGx5fVwlvv2TNlx6PtI
XR7xe1nSuJZ3CwFmD4RkCyyUNzkQuEoNbCN7d5D1UDeZtnzj+qPD/P2yaXrSe9wvkijQMB9tuye6
tbDf2p6h4lh1yXu+CFIeMEPzHs24UqRV0HM3aWm9Lo+0EYb/GbDC2nII/SCgZ0WkqcN0XXxRIpIn
CAqgGgl42cLNq6JlD4rv4ujXwHA4Y11RZU09kpxF+gQcElW5ZnXMc2lfvgCr5H/cvaTi4hXrsiG5
zDJmCzTNqfVqJd675kb4mGELD/w8AMXNho1b8cMJ3uVAC18LccroufHvtlHqNv1tb8I2ue18xdS2
3/5Lia1uqwc52sf+PJDs/78u2x3rFtaLOfEQKOer6FmtXOZ1EiQWfztCehoWGZgqO9fVRgxT5n7L
+Cjf9lb6WaLG0B27Msqc3d2OvDDYMjtbNk6iXqHblO090l8u9zzqaNiUGMSmPVy7CGwuuPhGfEGB
ecUJLQwuleQaCEjO69cgrQbnBTFNzH1ZFSgkLW8vpjM6ipva0LALxUJrxTwc0FKNw8yrhIAsQ1Hi
tAupBuBrtIeQsIKAnWG15xu7okHC6pnHMVlheoaoiTyJpZUGVwSFJ6jZzm/Jc4aNXSvSk7PM+YgV
Embh6jQy04k8KCVpkPMF/awFBCwAtIyrKDspmxAS5EkH1Hs+QuU+xuCH+iki8PgGhlJ8BAw0s0MT
arVnWjdzJesqsFGo7XolQIimI6YDaFBUxRuRPurX9B3ffVI5ENbRdRPn909zgDjUkirqGMtPQzg7
w7bY38+8Kymp1eBzpuVZPO/SdUK94hwQ1lKHKBCH0lM/AqtxdYMTS/jlpMmCL8ZBLEwrocPQrIob
UT5VuVf0LQZ6Hr3DevMCGBPkwy5kcPOmQnULruP9oYDcofUbr2wKaFuo8K2pOkJ1i+REFo8dG82V
XUauRaktmbylpt3BAXHAJ6hQct6yarVHTe8JC9z7upAyvKqy+8JSSmvetGdbVaf44b7Epzkaydz3
CdpfK49R48jQmorKKEbLCRrwspVawkr96IIWhPU5nSgTHrCp6XCW83LNTMPMps4DqOJmJMovSR1R
YJ+Rl21ShKh0Iwn3/JZvyyRVJY4BoN/T3YhQOIsYEUea5WnfT1FaIdEszDNp24mz7Ebfj9LUhMUo
x/V6czOHZj/RIqiyef1D3NqDpTMJxwmcP286nxXJ2nhUM3p4GEwhB6e4Dr43DWLyIczkqBiy3/Oh
XPiQJAsoRDpeek01yrmETpe6T2wv2/vb/jxLa5cNu6fuuODrpAM7LTpryNNWeJH+HBUl+3cp5Qp7
2bFCtPctc2Rg9XGdgaYNpXnjdU68pZMguLA4XR3JlWCkisuY5fgqibZXpWtFTCVVGdy1RckUOMwu
HY7HhHp1UUQ1nlH2KPjB+ZPPR8nl++DoE24dCruB8+ijfC+8YdSbMjBQKZkU/0qYj7UKBKvfHPHq
+8KSI/sFUNXdfY4Iuv2DKMoWF/fYMWU9UP5PlkVbJpQE4OG5wuMqvAhYOUy27FYCVTS3tEjiTKs1
W2pHEHhSxTEAsMF7fVYmQzas3cDDiPOdnYmbq/w7sJSI38h8wkVlYgZHqYBcUNvnHPpWqTFbAHP9
hDrc0LO40IKEp/TUK3jEFUgODKjGqTosMn+o5OKyThRGTvxXNwmKZkUBFICCHXCn8BuKllXM1JmU
bdOMtvD5Odd38HsF2iItu5VE8qWBomR1hiWRlkLKm92n4G/vstWUaRIJRPFapAnrvmjjouzmm67j
da2Q9pkdB/iZtRIJcq/labOTwcZPkVWZAk91TDFzkREIosZiUB4p2jdcezX24iCDVaqhS5pSqkYH
oKxkLyOzu2zqnQAuvv1Gbwh5Xl46CVLxq3y9S8siDzdRbFj9xAg5uuwP9lboMAEkh+lOwtB0+fsm
ghbVlt8LEDbPz7Zc2GaQL8msWVPNsleKZaWGiRFw0j1Tm/HcvEg+yTv2SeXnCOZZEUmjTJaskRbz
NmUg1jv44gJGPZFR1YutctKLO1G0Ifi+WTHRmWje7IAbKnMLzCb42sT0YUkNhZtY39aH4TvOGrI6
b1gnNn7GdGl9SM1Fqtg71mRMFkQqU75ifRGg+L43v1wpCjYQ3YO34+TKpPxkqJuaXoC4MberDGnA
yyTOKjbHNYPDOWgjoZ+ZM53iSthytLNzv87IoaNBTaLjcF1IFNfVkoLeGAMSs2FLWOVTaq/sDQi/
8KACavsr161LUX2pdVgpqBaJ1ESUCdErU6INneGuymrjubOwyeQwiA+0htfjV1WSA0Usr7AIxpl5
dmNXviw9b1GJdjEvJ+NamLFdJaL+57KfZHw7ZlV1bLOYH8Bniy4Slc4jd0vuwxvBGuqoVVXs2Jo3
biat903qslW+nQBlcaB9m8TgI/BboXm+G/qhilNtF3LhnjrB2auBuFJjeQtKlSZjRmz+Irn+y6rT
1Fy1ju+fswzkXnPII6nI5QzAk9qya2o2HOXzZaEmduRgANNDeQ0/KIMMFD6PopjPeYJFZcq6WInE
JrVm33JgU7M+HWnRkUazDQbAsxiN9dQn9aovAzwqapxZIbEEFGSx0sdj6tj2/lOe6QOx5psNxZW1
SVGSI0lhXDeJoES6sjh1xUmz7Z29FSQm1ckY+Hs/sNjjQ6907yjFa2ZfJZecwYrbO/r9/8l//7u9
Q19i14cRBWe2oz1tcKuGLi455NTkPJYgRZQpNjR8BoWzrJWRhWPFO3Y8JjZwAn3Dj5ru5x0iyVII
ZhiUG8Lghlr9DpV+1IoLMLg4MvoUbpdQ//lXtZQXxGpq2L+smBGTQeluny4iSvPaNTjUjVbH6tsb
9fstG1L7MrgOXMX8qsctt+azUIY+i3Q36Zs5N6ofSNVCrh8B3gJ8UVELQAFQ1lzucUQD5pZKrwyz
8Hq7WZTQw6Cid3L92REC8SodpUQDR8uKzhRkgSnZ/QrJjVLplVDZUzlW0He1cCbnwWsFFdQykpy4
xm549d4C1o3QirTYZRAYQaL2QTtICsVGzWiSxqb1iRLcHJi4WswaB5d5olShgaC4BAPnvqM0rN0z
qi/x8EzMsNsT7fAVQ7W/Z9IqlFVaGE02g3WYqHpxrduItfLLI044DTCp9w0cyLxv5y2pnIn/zfui
5aNRZ9qgeVk/9sbNqo0b68c/tL6e+7eXkdcP/Xqowb17hpIz0mfkWXyDOf3D/Wi1A+7K8sf3nsqP
D249usrF35o2LZTdURcRycbJrLyPp5kP6WEPZciD5/KjvSLr7F/xdah2D9MDyIYDGmREhA8k238c
lU8yg99k1DPCohA5qEie771EmQF+hlaecKrInX92EvXOP4lUSIoGRDOZFwtUGei6Zp77oY/3mcLO
WTCxbT4tl1Pv5JjiEjQlwKHc9xwn+0otYK780W1aSzoV3c4DPB0XjuOKQdyS3N/szdyk/I5mDkPD
q+GegC66XBKT1yqTPEKpz1hzuuoN2lL0SDzPBLDEWmD0MCgUZU0fKowVpEFrdgVL4oY5irP8XFOt
vXQWW0iik59+kn8SpeylGONPbO0SUOnjw/u2/Hhny4+9ljX4OfMayO9pL+vdFeZVf6TqUn7w+A+i
qtqPwYkfu9e3XonK6OfJ/TLhe6w//oXPZM+KHgTfvVeTDiMXrOk6qHQhus6S0ZGPbM9HHUctSm8o
qxda1dkHnLN0HY0i0caCY3tMB/O1V3YNcHBatbTlfV+3r3yBj4Sh8aFVnj8F9ivBOYwpiLsvmdj9
+gM630KYjB2629jq7Xc7kJU4neOytDrU4pV/e/53J7/S99IhPU5Ucrs+E3Of5rd2OkhJ+SKPvv0Y
O3FwVqPH/W56BT70L0GrLTvrX4VOfhEDDP8BtHogFcYSQ3at3T9jPANpYcPZib49TVD02+fyDij9
aQqlH2zUOz9OIPUjq3dnAym2fkDrw6Eh+yqq0PeK1IdnwfnyJXx1Vgxhu14eO/6lSh6HYKw0oIdz
Sjjcvyvu08zf58tupYpdwBMtgST3A5gDXeDv6b3AUk7ky7a5dHUmNxtLHbzajyWpEBI0ra53625n
/ZQTdSJaRQmGBqkdeHampxSxMLbPpIijVueNypHSfjNwChBLXN3bnGzs2eLvppzlNI1rTNZGjODa
s7Ykw8ds7/CO9O51P+1Wwr/mkfYWJTWmeCVotlKZNNiwrKglUWZD6xbnzge9BIZ/XfDlB75Gh5Qt
9vDrBNjLTW7T1wd5o+qh1BJN1J5u1S8I0xYSyvRsK/WungDVq2VpvMmuH7989v3bOFTpM+pkaByG
tp7ji+Vl7Z+BLaHCIGN6xAqU6laWZaEursgra7SOQ9Hxzd/qt3n77bOXGMxio94N2iOIhIhlbo4N
2zwDr6+nslBEyx61jityGtHQWu1G4mBYWSPAV24umS5abiFF05szZ3tlaYSv22ZWzARgzSGhDmlj
5wyqk4HsrtgQtST3qHAwL7nMER9r7UQB2clltcMKL8/stnqOaGvlMEQb9NomxavFed0CGxcMqByB
G0SEm2W2daUmnd+o1KZgvnpGLHQW5bNT6O9QkZspMzXavDtUB7Ij1/xoq/aDFswfWT7FEEo9Kr2F
wtfeDySMVlt9sWVrCDcON0TeJdo6RdmqAzpGJ6UPfJkMSczY7tTGuGjmfEW2wvFCMVgpr4tYigGl
sZMMq+I+kIbcexam7WpFQglSe6c+My49LplvwZcCu+bAOKARuyvUqGUHpIYi3dSdfF+Q+yNR/Pzn
bA/e837Iwbcj4JutcaU9WRu3XeKHW0cCEwqElNwSuSBcZdQl38OByLMqoWl6+F2DCR2+c75gPqQ6
bo6idyWiVi5FOIqDNOAWQ74Wx5hCY5w5EXlQw9cn+fmGa1T2qqDMwGZ6zZqVO7oG7XTI01gXrY9/
RzXGqL3KFR44hMKDzcrNmsVN7qrOHaWqOdSpqRqp/Hfel4f544+jcgWJd0HujGkGQBdWU8jyt9Zv
LSxPDXikYgDSzBRMLWqWbQFOo3EhCG3f25FVLFw3FgsSUMV5eSVXmkVfa4ChrAWBYlFTGZLPoVyK
45vrbbblIvo+kui6D68jr3TwgQMwGHDLRhwNBVWL33ZatwtJbDeF+WM7T00KHgazK9rx+DGuPbnd
0BaYMi6Di7L8QRAmQc+WDg6fFFG8LhQTyMJVF9NOcNsiRsUlzBQYxtfJRhlyXukAStrDrSO277ny
9OQV66RbUdvwhhZxlMuZJKaQ5k/YWCNQkKIF5p1UaGPYA5RsnjUKsksC3UmfCee3iKyw/7hMoQVk
Tc+rFVACXS7EZ/mCoGR/EcV/Frzcsmnj24WAj9bAuG201C3w2yTCWBMPkgo6hYhVBy0K1TBjzqGV
fx/dLkYyCTyPpIMkPMbi0/eWfdrq/SYWUWa3vKK5aw2GdBWzEXm0tUQpwX2DTwXvzWrdTQq/Z2SK
939ONcHHsyKII2slFCPjmJ+P1FkNigj9oVhFPu3ACVoTiu+fjCzvjMaOY8DVGc2jKtHRC07MHciG
4dwP74qiU/evN0NlSotrrEak/xjHC26Xu5ievLqrqJIN6CVntDCob6GAQzPFyi7oe1xwvJZ8Hn96
n8QTDsCSQwEaXAU43RD9p+GftCJZEFC6+9gzIXe6j+pCUZWyx4fD43XPLK8Hnbbcvx+q6G2TEQcK
HoaFzt1Lla2g1+6rb3Zde7PzShtNv2DIMILdWkIPRpBcb+LTbLda1ls84xK78KMIMN4fQ8Mjo7Cr
KoiRvFTOCGPgI7n7JUbuZMP6OZbCPyrromeWgDFuk3HCzdYY5Jbrfa3dIT3rbeBb+5T/ZPddlR2L
smtNthWO7dJ5SfKzrhl8ioxAW8ApYGmQ2bZ2ErIh5XIcX3lw4HyJymuxgiK1hudyt7qtr2Xj2+L+
bVMytJk++V/6V3UfMrIUiUB8LwNufzNtVkDGZrvDZyDinjl013vM9ezG3Isp/l0rDDDeN1QKSJUW
sZTEVUc2BmkvjGc0OE2EpOMp+BIegCFOIsgOHw2u4+9sAeoRL1xaTzm2qTXXA/hWqz3C10MtXO6l
FPth9L4jhqOOpRwMh63F2O1sWmnePD4XfBMjgtMQbXblRH2jN1LkqFUsfeNDvp7kFjUS7RyhsMXM
VaW7CpfvqkOLQ+OnQBxNdYsGN0Lg0SIk5IWM9QkzhxJeoJhOmHp6tajdaecpHfEJjG+qTqItRhHp
wP94LvFY1SOtksIls/3Vfoiue07frRsuXCElL/Uu3+gqxUgiWaR3tFG+TPfRGIN5tIO9ZPTkIfVf
H90t5eyl2NU0/PCuLnbWcNRAttw9AKAYSo+HsuP/eTvCEpHrMXil1ZTkvhPU5CNx6yiqMugW0vtw
rf4zvGB3bLGLfOjyI3OflztSiO9D1633dpfM2k2Eu5S5VIoNNlhCvfz3h+Fm5xgccP91vh/olrWy
g1t4zwiGwKMoGN06MhdTwkApIE1U9dveuI/upnnQA28j72E4hhETVq+CKn9yfXh6UYKlmcy0GpAV
6YeEBxZV77lgPuZLo9xas4u/94FFoSCrGUlA8U24o0R4sg900S/T/H9yGIkfxHdGmfTN82dt4X1z
X6m4k7sHW7vkSwp2TfwlW+JBA4R+jXVoDbC5JmOmtzvNVyzg7O75SfASx2DL6AqnYdBiarevhFuu
ssjo83c5augzclIq0haUnJhVGKsjcDJmpgKl131HF75wr4MaBPNmw1DiZS4Ks78Voc0EC2vXUkEa
SiZOGQUN/EREAUmvT43mlmFuFtJNU9ZYp+EAzXbDELPmTzW6ZHEFBsmbsCHT4taimNobPB3M+UtU
KMCUoVU5X3BhQgPzNze6MLRBBiToey25NJyRctVUUi1y+3qz/NTK+L9w9Qaxb7sXgm+T1Ou6nHiX
lxaKK+AodXrBZEEivt7kesm3Vojf9HKbXLq69p0WSYguOyPzDXaRv5dra7ByO6idk9d8fyiN9lt/
HRnqDKi5b51KBpC/BhfluASiXfJ+DVfFcxUAu4fthd7D9dln/237T7itDa/lI2/wn3teZXCPQvh3
13W/R73zhxUCv39d64dUgX5QUdt7l369XwHUh5TzHKlyeY+ieDvLWA2x7LeXm7irgMItqfvj+Ug7
g523ucPHHQc7zITRW+ykinJ0s+4zPtUIXfNfJoKsefaCPloVk1B5JWQstwVzWYN76YWFSVHIScY+
CSnYwKUvtLpAcjt0rXedsmQi1aZgDfNC7shU5DEJJYagJB+W4VbESWDaYhx3+dnZU1dVHUNk2B7h
WzK9wZpFlWHCx5C2mxmq4MYlfvjzCOnvnSlyQxzL3bnais5fC0qmLDqUqBRN7gUxeywmj7UL73EG
sbQl4pd0Ar7zlW/WNO5o17lUIaOsL7rLicyASZVeNq7JuWR6Zpqa7WzkOy/nlhCHGu4LWltgCVAQ
tzb6ZZHBf6KFEwFk8tnYz8teysu91kI7NDQOpNIBwkffNteOiVDAqSaFGO3CgmK1vkDIhMVWuFmz
DCmfPHcbAt/eoxsYwZwsPAiucf7SR2qje3lxzx5rWEITKX26kbuY+Kf9zlw8vpKA6G16j+EE2amC
56E5zUTgWDqn3YpedoFipjOKqoSWygWPIFRuMq1J7XO5BCku9ctU6W/WTpAh/gD8P5DHwilul8by
zh2y+C8RHxrbPqQovratoXeg/bPnav3fPttklLfON0z49IY0sg/5t1ZeCLP4yperRQRISPgd2NNz
OjoVcUlJ8GPPpni6lq3DlePhxmC5XBY75kUBjRzs4EU49tQsNHDkC6s6n7ETv9OIjwXyJ/xaJbEp
elkGexEPtt1UEtqYbUq4v5ZLbM37T5Cvwa4ZjcdL/bzs1jQ5aO2q5FL369GupRixfuqFFBNEOCgw
AZm4tSZS0oWXmJlNgG/h4J0+P3nxTICW10V9mf8hskVwzKGuZxfso+uO/oHZnb4+/opm9xTuZhnM
cbXg4mMLl3SWl1KtbdEcJYL69O0PLBiwM0SinWKqstZeivvXv2PT1f+eHIlzietp6YDIdouiG3qA
7arqgGqBfkDmTihVoLdoE2NDTq5VwwWmYCbxfqsSpIUWiD3aVY5+4bJlWxKfhx2H2+14BXuGI1rW
qY8VbKKJ4QHjOlwhV9dx8G5QOvh5UyyiT6ac93TkGKn3NREUVAOKz9j1r/8XPULEUTq1AAA=
--=-=-=--

\start
Date: Thu, 24 May 2007 05:18:38 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: re: [Axiom-mail] [ANN] new version of axiom mode for emacs.

Martin Rubey wrote:
> Alasdair McAndrew writes:
> 
> > Lovely stuff!  Well done, Martin!
> 
> Thanks.
> > 
> > I found the green output a bit garish for my tastes, so I changed the output
> > foreground to blue, and the background to white.  I have discovered one
> > problem, though:
> > 
> > )read newton )quiet
> 
> This should be fixed with the version below.  Unfortunately, pamphlet
> documentation and code are a little out of sync now, since I did a bit of
> cleaning.
> 
> The main source of bugs is recognising when axiom has finished a calculation.
> We really should switch to keep track of the input line.
> 

Just a little observation, after doing:

)set output tex on

I get the output below.  Note that all normal Axiom output is 
indented, while TeX output begins just at the begining of
the line.  So if you just scan for dolar as first char you
know that algebra output has ended.  Skipping over TeX
output should be very easy.

BTW.  Looking at 'output' routine in i-output.boot.pamphlet it
seem quite easy to add any markers that you need (just print
them before and/or after call to 'mathprintWithNumber').



(2) -> (x^20 - 1)/(x -1)

   (2)
      19    18    17    16    15    14    13    12    11    10    9    8    7
     x   + x   + x   + x   + x   + x   + x   + x   + x   + x   + x  + x  + x
   +
      6    5    4    3    2
     x  + x  + x  + x  + x  + x + 1
$$
{x \sp {19}}+{x \sp {18}}+{x \sp {17}}+{x \sp {16}}+{x \sp {15}}+{x \sp
{14}}+{x \sp {13}}+{x \sp {12}}+{x \sp {11}}+{x \sp {10}}+{x \sp 9}+{x \sp
8}+{x \sp 7}+{x \sp 6}+{x \sp 5}+{x \sp 4}+{x \sp 3}+{x \sp 2}+x+1
\leqno(2)
$$

                                            Type: Fraction Polynomial Integer
(3) ->

\start
Date: 23 May 2007 22:58:29 -0500
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: gcl, shared libraries, was Lisp portability

Camm --

  I believe GCL-2.6.8pre is missing the ANSI Lisp function 

      ensure-directories-exist

As a subsidiary question, how do you delete a directory in ANSI Lisp?

\start
Date: Thu, 24 May 2007 11:27:40 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Lisp/TeX/TeXmacs was: re: gcl,	shared libraries

>> Could not agree more here.  So we should not rewrite TeX in lisp, but
>> rather find a way to use this excellent tool from within lisp.
> 
> That's a point, and I think LaTeX will be by far the last non-lisp
> dependency to go, if it ever does.  I would be very happy to see such
> an interface - was there a project somewhere working to expose more of
> TeX for non-traditional uses?  While I am in awe of the algorithms and
> how well they work, I have always been a little puzzled by the software
> "stack" of TeX.  As I understand it, TeX is written in Pascal which is
> then translated to C which is compiled.  So it relies on the language
> behavior definitions of Pascal AND C, or more specifically that the
> translation routines of the behavior specified in the Pascal language
> of the original author are faithfully translated into C code that is
> interpreted by a modern compiler in the same way the original author of
> the translation routine assumed it would.  I am not all that familiar
> with C and Pascal so perhaps this is reasonable, but it always struck
> me as a little... odd.

Just yesterday, I've read the first few pages of "TeX: The Program". 
There you can read that TeX is written in WEB and that is translated to 
Pascal-H, some variant of Pascal that Knuth used. You furthermore read 
that Knuth deliberately avoided to use any fancy extensions of Pascal-H 
and even of Pascal (Wirth) itself, since he wanted to make TeX "easily" 
(i.e. with some minimal effort) translatable to other Pascal variants. 
For example, he did not use definitions of procedures inside procedures. 
There are a few other things mentioned, but the important thing is that 
he mentions this at all. If you have to read that from the Pascal 
sources that come out of WEB, good luck.

TeX is admittedly a strange language, but I don't think that that 
TeXmacs is any easier. I've browsed through the documentation yesterday, 
and I was a little surprised to find out that the style language of 
TeXmacs is not Scheme (basically it is, but with a few differences). Yet 
another reason why TeXmacs is not well accepted by the community. It is 
simply too hard to have your old knowledge in your head (by which you 
can do things in LaTeX (maybe not the Wysiwyg/m way)) and you would have 
to find the appropriate commands in the TeXmacs manual. Often guessing 
just works, but if not, you are stuck and that is more than frustrating.
(Just my recent experiences with TeXmacs.)

To be more precise. I wanted to define some TeXmacs macros as they are 
described in the manual (Help->Manual->Writing your own style files).

Entering

<assign|hello|<macro|name|Hello <person|<arg|name>>!>>

as it is described there nearly drove me crazy. I did not get the 
"person" macro entered as it was described just below that box.
(Even if I am to stupid to read clearly and follow the manual, I find it 
quite hard to learn the "new" way. And that is frustrating. :-(  )

So in some sense, TeXmacs fits perfectly well to Axiom in its steep 
learning curve. ;-)

Hello TeXmacs, developers. I am certainly not the most usual user, so 
you probably can ignore my comments. But I actually intended to add (or 
help to add) some literate programming support to TeXmacs. My experience 
from yesterday night really let's me think twice about whether I should 
invest my time into TeXmacs. There is so many things to do (LP support, 
syntax highlighting, indentation support, (automatic hyperlinking 
between source files, I haven't yet seen a "back" button so that I could 
use TeXmacs as a source code browser) and I find it overly hard to 
achieve something myself in a reasonable amount of time.

\start
Date: 24 May 2007 11:42:50 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: re: [Axiom-mail] [ANN] new version of axiom mode for emacs.

Dear Waldek,

Waldek Hebisch writes:

> Just a little observation, after doing:
> 
> )set output tex on
> 
> I get the output below.  Note that all normal Axiom output is indented, while
> TeX output begins just at the begining of the line.  So if you just scan for
> dollar as first char you know that algebra output has ended.  Skipping over
> TeX output should be very easy.

Well, I think it would be better not to rely on )set output tex on or some
such, since the user is (and should be) able to turn it off and on as he
wishes.  I want to give full access to the interpreter, and I also do not want
to rely on output not being in the first line, that may change.  I must admit
that )fin is already broken, but that might not be so difficult to catch.

> Btw.  Looking at 'output' routine in i-output.boot.pamphlet it seem quite
> easy to add any markers that you need (just print them before and/or after
> call to 'mathprintWithNumber').

Yes, that may make sense.  Still, I'll leave it for the moment.  I haven't
found a possibility to produce a bug yet (apart from )fin which won't work),
after all. (Please try, though!)

\start
Date: Thu, 24 May 2007 12:54:02 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: [Axiom-mail] [ANN] new version of axiom mode for emacs.
Cc: Alasdair McAndrew

Unfortunately, axiom.el is not usable in XEmacs. Here is a translation 
of the offending key definition. The definitions given below are 
compatible between Emacs and XEmacs.

(define-key axiom-mode-map [(meta up)] 'axiom-previous-input)
(define-key axiom-mode-map [(meta down)] 'axiom-next-input)

(define-key axiom-mode-map [(shift up)] 'axiom-paint-previous-line)
(define-key axiom-mode-map [(shift down)] 'axiom-paint-next-line)
(define-key axiom-mode-map [(shift left)] 'axiom-paint-previous-char)
(define-key axiom-mode-map [(shift right)] 'axiom-paint-next-char)

But there is more...

When I start M-x axiom from within XEmacs, I see

(1) ->  ^M(1) ->

And if I type the famous 1+1 then my cursor jumps right on the ^ of the 
above given line and my status line says:

cannot support overlay 'modification-hooks property under XEmacs

So XEmacs users are left out with your mode. :-(

On 05/23/2007 03:35 PM, Martin Rubey wrote:
> * it would be extremely nice to have command tab-completion, as when starting
>   axiom in a shell.  (The polymake team would like to have this, for example.)
>   Anybody knows how to go about this?

A simple and stupid way is, to extract (by hand) all relevant Axiom 
identifiers and put them into axiom.el then write a routine to use this 
list. Of course that is not good if somebody changes the axiom library, 
but until then it might serve quite well.

\start
Date: Thu, 24 May 2007 06:12:03 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: axiom identifiers

Ralf,

The list of axiom identifiers existed as some point in the past.
It was used for command completion in clef. I can look around for
it when I get back.

\start
Date: 24 May 2007 15:07:35 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: axiom identifiers

Tim Daly writes:

> The list of axiom identifiers existed as some point in the past.  It was used
> for command completion in clef. I can look around for it when I get back.

Would be great if this information could at least be extracted automatically at
build time.  But I do not even know about the necessary format.

\start
Date: 24 May 2007 15:21:08 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: emacs mode
Cc: Alasdair McAndrew

Ralf Hemmecke writes:

> Unfortunately, axiom.el is not usable in XEmacs. Here is a translation of the
> offending key definition. The definitions given below are compatible between
> Emacs and XEmacs.
> 
> (define-key axiom-mode-map [(meta up)] 'axiom-previous-input)
> (define-key axiom-mode-map [(meta down)] 'axiom-next-input)
> 
> (define-key axiom-mode-map [(shift up)] 'axiom-paint-previous-line)
> (define-key axiom-mode-map [(shift down)] 'axiom-paint-next-line)
> (define-key axiom-mode-map [(shift left)] 'axiom-paint-previous-char)
> (define-key axiom-mode-map [(shift right)] 'axiom-paint-next-char)

OK, thanks a lot.  I'll look into making it usable under xemacs, especially in
the hope of making it more robust.

Cliff, Jay: is the axiom-wait-for-output function and that sort of
communication really needed?  I guess the only functionality it provides is
that input is not accepted during calculations, is that right?

Cliff, if I may ask you a favor, and in case you are going to work on that
project too, could you please concentrate on one (or both) of the following two
desirable features: (just to make sure that we don't waste our time)

* sending input from an input buffer to the axiom process

* displaying the output LaTeXed.

I will, when I work on that, try to implement the following:

+ S-return copying the current line to the end.

+ make colored output persistent, i.e., when you copy it into another buffer,
  it should keep it's color.  At least in gnu emacs that should be doable.

Help for porting the whole thing to xemacs would be highly appreciated.  And of
course, I need input on desirable functionality, key-bindings, etc.

\start
Date: Thu, 24 May 2007 08:35:26 -0500
From: Jay Belanger
To: Martin Rubey
Subject: Re: emacs mode

Martin Rubey writes:
...
> Cliff, Jay: is the axiom-wait-for-output function and that sort of
> communication really needed?  I guess the only functionality it provides is
> that input is not accepted during calculations, is that right?

It's useful for getting output in case, say, you want to send input
from a different buffer and copy the output to that buffer.

> I will, when I work on that, try to implement the following:

You should also eventually give the functions and variables a common
prefix.

> + make colored output persistent, i.e., when you copy it into another buffer,
>   it should keep it's color.  At least in gnu emacs that should be doable.

For this, you should use text properties instead of overlays.  (In Gnu
Emacs, that is.)

\start
Date: 24 May 2007 09:51:15 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: gcl, shared libraries, was Lisp portability
Cc: Paul F. Dietz

Greetings!

Gabriel Dos Reis writes:

> Camm --
> 
>   I believe GCL-2.6.8pre is missing the ANSI Lisp function 
> 
>       ensure-directories-exist
> 

among many others, but is in 2.7.0.  Do you need a backport?  It is
simple. 

> 
> As a subsidiary question, how do you delete a directory in ANSI Lisp?

I see no such function in the standard, but am cc'ing Paul Dietz.

I therefore would suggest (system (format nil "rm -rf ~s" x))

Just to repeat, 2.7.0 is moving to the following usage of 'directory
akin to clisp unless someone objects:
=============================================================================
COMPILER>>(directory "/tmp")

NIL
COMPILER>>(directory "/tmp/")

(#P"/tmp/")
COMPILER>>(directory "/tmp/*")

(#P"/tmp/#gazonk_27762_21.c#" #P"/tmp/#ii#" #P"/tmp/#q.h#")
=============================================================================

This is what 2.6 has:

=============================================================================
>(directory "/tmp")

(#p"/tmp")

>(directory "/tmp/")

(#p"/tmp/#gazonk_27762_21.c#" #p"/tmp/#ii#" #p"/tmp/#q.h#")

>(directory "/tmp/*")

(#p"/tmp/#gazonk_27762_21.c#" #p"/tmp/#ii#" #p"/tmp/#q.h#")

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

\start
Date: 24 May 2007 16:31:30 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: axiom.el for xemacs

Ralf et al.,

when I start axiom.el in xemacs I additionally get the message
No such face: comint-highlight-prompt

Do you get this message too, or do I have something wrong?

\start
Date: Thu, 24 May 2007 10:40:39 -0400
From: Bill Page
To: Camm Maguire
Subject: Re: [Gcl-devel] Re: gcl, shared libraries
Cc: Paul F. Dietz, Gabriel Dos Reis

Quoting Camm Maguire:
> ... 
> I see no such function in the standard, but am cc'ing Paul Dietz. 
>
> I therefore would suggest (system (format nil "rm -rf ~s" x))
> ... 

I am really surprised that Lispers do not find this sort of
suggestion really revolting! Surely the point of an operating
system is to provide such services to programs at low level
without resorting to command line interpretation to pass
parameters and access such functions. 

.. there's got to, there's got to be a better way ... 

\start
Date: Thu, 24 May 2007 07:50:41 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Camm Maguire
Subject: Re: [Gcl-devel] Re: gcl, shared libraries
Cc: Paul F. Dietz

--- Bill Page wrote:

> Quoting Camm Maguire:
> > ... 
> > I see no such function in the standard, but am cc'ing Paul Dietz. 
> >
> > I therefore would suggest (system (format nil "rm -rf ~s" x))
> > ... 
> 
> I am really surprised that Lispers do not find this sort of
> suggestion really revolting! 

I do (well, frustrating anyway).  But apparently it's harder than it
seems to deal with across all possible cases.  Cross platform issues
can really be a royal pain in the neck, regardless of language - the
CONCEPTS seem to be different in some cases.  Sigh.

> Surely the point of an operating
> system is to provide such services to programs at low level
> without resorting to command line interpretation to pass
> parameters and access such functions. 
> 
> .. there's got to, there's got to be a better way ... 

I would tend to agree, but looking at comp.lang.lisp suggests that
handling directories over all possible situations is not as simple as
it seems - if you take into account a wide variety of file system
concepts, at least.

\start
Date: Thu, 24 May 2007 18:30:02 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: Re: gcl, shared libraries, was Lisp portability

Camm Maguire wrote:
> Greetings, and thanks for including me in this thread.  Unfortunately,
> axiom-developer mail is still not getting through my ISP for some
> reason. 
> 
> 
> > In my private tree Axiom is nicely working on top of sbcl and clisp.
> > The remaining known problems are sockets and writeablep function.
> 
> Great!  It is always nice to have more options.  But I do have a
> general question here.  Work in this direction obviously makes sense
> if 1) GCL is currently deficient for axiom use in some regard and 2)
> we have difficulties addressing said deficiencies via changes to GCL.
> If both of these are true, I would greatly appreciate you and/or
> others letting me know the details, as it is and has been a goal of
> mine to ensure that gcl remains optimal for axiom use.  As in the
> past, I pledge that if axiom needs anything from GCL which is
> currently unavailable, I will make sure said functionality works in
> GCL.  What I would like to avoid is chasing every random package which
> no one has any serious intention of deploying in a real shipped
> program. 
> 
> If either 1) or 2) above are not true, may I suggest that significant
> work in this regard is a distraction from the real goals of the axiom
> project -- to deliver the best symbolic algebra package in the open
> source world.  In our company, we manage approx. $70 billion dollars
> using open source software and code we've written on top of it.  We
> would get nowhere if we spent any time at all making sure our code
> works both on gcc and icc, etc.  Rather we pick a platform that
> appears flexible, stick to it, and get the results we want out of it
> quickly.  We do almost everything using gcc, gdb and emacs, not
> because they are the slickest or hottest or even fastest, but because
> they have good portable performance, they can be changed at the source
> level if necessary, and they will be available forever, making our
> payoff period for the learning curve essentially last a whole
> lifetime.
> 
> I'd really love to help the axiom project by offering a similar setup
> for use by the developers.  Even one better -- axiom has its own
> personal compiler developer to tailor the compiler to its needs if
> necessary.  This only pays off if my work on GCL frees axiom developer
> hours for work on the core system.
> 

That is very generous offer and I appreciate it.  But I must disagree
with some of your assuptions.  Namely, sticking to a single
platform/toolchain is perfectly good business decision.  But,
especially for open source project, there are good reasons to
to seek portablity to other Lisps.  Let me mention few reasons:

1)  Code readability: for Ansi constructs it is reasonable to say
    that behaviour is described by HyperSpec.  But if we use non
    Ansi things or depend on GCL specific aspects then this is
    no longer the case.  So it is good to separate Ansi part from
    GCL specific ones.

    Some people belive that such separation should be done via
    extensive audit/review.  I take pragmatic position here:
    compiling with other Lisp implementations identifies 
    various dubious constructs much more cheaply than audit.

2)  Sbcl port helped to make Axiom compatible with Ansi GCL.  Together
    with clisp port it significantly reduced chance for future
    Ansi changes in GCL to break Axiom.  

3)  I have some personal intrest in other Lisp implementations.  

4)  Lisp developers seem to be attached to the implementation they
    use.  There is good chance that little effort spent on keeping
    Axiom portable will be offset by extra contibutions possible
    thanks to portability.

5)  Ability to use already installed Lisp for Axiom development/
    testing.

There are also some problems that I had with GCL based Axiom:

- Axiom is slow.  To identify reasons I need a profiler.  But I was
  unable to use GCL profiler.  I tried to follow sparse instruction
  given in doc/profile, but I got no output.

- From time to time Axiom signals more or less random errors or
  crashes.  The exact reasons are hard to determine because 
  by default Axiom is build with safety 0 and error messages
  are rather uninformative.
  I have (few times) build Axiom using safety 3, but the build than
  took more than 16 hours.  Also, in one case error was reproducible
  in safety 0 build, but went away with safety 1 (or safety 3)
  
  I would appreciate some hint how to debug safety 0 programs and
  how to find a good compromise between debug abilities and build
  time.  Let me remark that at safety 3 sbcl build took me about
  3.5 hours compared to 2.5 hours building with gcl at safety 0
  (or more than 16 building with gcl at safety 3).

Let me also mention that Axiom currently have only old Windows binaries
and no Mac binaries (we have reports of successfull builds, but the
resulting binaries did not work on other machines).  For Windows I
seriously consider cross-compilation (creating binaries on Linux).
Another possibility is to build Axiom using Wine -- I do not know
if gcl works in Wine.  Yet another posibility is dosemu, in the
past dosemu run djgpp programs very well, but it seems that now
djgpp is deteriorating.

> > Also, currently for clisp I need cl-fad library, which I consider
> > problematic.  Namely, cl-fad does not work with gcl, so for gcl
> > we need separate code.  We need only few functions from cl-fad,
> > to work around clisp weirdness (clisp makes strong distinction
> > between paths to files and paths to directories and refuses
> > to perform file operations on directories).  So my current plan
> > is to eliminate use of cl-fad and provide the needed functions
> > directly.  Related problem is performing operations on
> 
> I think this is a wise choice, but needless to say, if you need
> cl-fad, I'll make sure it works.
> 

Currently I eliminated use of cl-fad.

> I love lisp, obviously, and primarily for the magnitude and quality of
> AI-type code which has been developed and has recently entered into
> the open source world.  But lisp is not going to compete with perl,
> python, java, or C, IMHO.  The primary goal should be in fulfilling

I belive that currently choosing language/implementation one is faced
with choice between speed, safety and convenience.  Native perl
(and probably also python, ruby, tcl etc.) is convenient but slow
and in many cases unsafe (due to reliance on parsing and various
"magic" convertions).  I belive that it is possible to create
a language that makes better balace.  In fact, I belive that
already just as a language Lisp is better (but current implementations
lack many real life qualities).  OTOH I am not sure if Lisp is
the best option.  And of course real life survival is much
more complex than "language quality".


> Thankfully, the ansi-standard is written down, and with all its warts,
> will last > 30 years, IMHO.  If we need items outside the standard, we
> should rely on implementations in C shared libraries, as these will
> have a longer lifetime and in general will be technically superior.
> We should then pick one again non-standard glue between lisp and C,
> and stick to it, and call all the shared library routines from within
> lisp.  These of course are just my opinions.
> 
> It is good you brought this up, as gclcvs has followed clisp-style
> directory usage, at least at present.  We can undo this if required.
> Pathnames with spaces are also fully supported in gclcvs.  These can
> be backported to 2.6.8pre if necessary.
>

I personaly think that clisp choices are misguided.  But for Axiom
I have a workaround so this is no longer a problem.
 
> 
> > Concerning sockets, we need Unix domain sockets and select.  It
> > seems that clisp provide both, but to get Unix domain sockets
> > one needs version including rawsock module, which is not included
> > in default clisp configuration.  
> 
> > sbcl offers sb-bsd-sockets which seem to have basic functions,
> > but I do not see select.
> 
> > gcl documentation suggest that Unix domain sockets are unsupported.
> > Also, I see no traces of select.
> 
> gclcvs has a select/fork based parallel processing system:
> 
> SYSTEM>(walker::macroexpand-all '(p-let ((x (foo)) (y (bar))) (+ x y)))
> 

I do not understand details of macroexpansion, but I belive that it
is doing something different.

> This can be adapted to whatever other interface one may desire.
> 
> Do you mean dgram (UDP) sockets?  If you specify the interface, we'll
> put them in.
> 

Unix domain sockets have interface very similar to network sockets,
but use filenames as address.  In effect Unix domain sockets are
very similar to named pipes, but have some extra capabilities

Concerning select:  conceptually you have a list of possible events
and want to check if some of them happened.  Select allows blocking
wait on multiple events.  It is important that select is _not_
limited to some "structured" constructs, users of select should be
able to specify exactly the set of "interesting" events.  On
Unix it is currently only possible to associate events with file
descriptors, Windows has more general WaitForMultipleObject system
call.

An interesting variation of select system call is given by Linux epoll
system call: you register a set of descriptors with kernel and than
you ask if something changed.  One advantage of epoll interface is
that it avoid repeatedly copying and scanning potentially long
list.  epoll is important for high performance web servers.

For Axiom use any non-crippled version of select will do.  Currently
Axiom selects between two Unix domain sockets and terminal, so
select must allow mixing sockets with other file descriptors,
but performance requirements are quite modest.

> 
> > There is "portable" cl-sockets library but the manual says it supports
> > Allegro CL, sbcl and cmucl.  The manual does not say anything about
> > Unix domain sockets or select.  The manual says that cl-sockets requires
> > UFFI, so presumably cl-sockets works on top of "portable" C library.
> 
> > In short my finding is that portable Lisp sockets are a myth: all
> > implementations provide different interface and frequently miss
> > some essential services.  People who want portablity between Lisp
> > implementations interface to C. 
> 
> Agreed!
> 
> I've been working on a better interface to external shared C
> libraries for GCL.  The issue, as you may recall, is that GCL-compiled
> code referring to external shared function addresses are statically
> relocated to the value of said address at the time the .o file is
> loaded. If one then saves the image and re-executes, the function is
> likely in a different place.  
> 
> I've figured out a persistent solution using dlopen.  Still working on
> the precise interface, but you can see the idea here.  Comments are
> marked with ***:
> 

That looks very interesting.  I notice that you automatically use
C library names and C functions names.  I hope that this is only
a default, because otherwise it would be very hard to resolve name
clashes.



> > Given that it seems that most reasonable way for Axiom is to use
> > existiong C code.  There is are drawbacks: we need to interface to
> > C and typical Lisp implementation can only interface to shared
> > libraries via dlopen.  So we need to handle issues related to making
> > shared library.
> 
> Hopefully, the above will be useful.  It appears that libdl is quite
> portable, but may require cygwin.
>

I do not know about libdl, but native Windows interface is reasonably
simple.  I think that main complication on Windows is supporting
multiple calling conventions.
 
\start
Date: Thu, 24 May 2007 20:38:07 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: openmcl port

I have now succesfully built Axiom with openmcl (using 
"OpenMCL Version 1.1-pre-070512 (LinuxX8664)").  However it looks
that openmcl (at least on Linux) is buggy: when I created an
executable with new toplevel it crashed on startup.  Second bug
is that symbol | | (name consisting of single space) may be
printed as backlash at the end of line, effectivly changing
name from space to newline (normally openmcl prints | | as
'\ ', that is backlash followed by space, but at the end of
line the space may vanish...).

There is also third bug (probably related to the first one):
given '--version' option openmcl crashes.  In itself this
bug does only little harm, but because '--help' option does
not print any string giving out identity of openmcl this
makes autodetection complicated.

Concerning creating executables: I implemented a workaround
that creates a shell script which in turn starts openmcl
with '--eval' argument to get new to new toplevel.

I do not plan to spent more time on openmcl, but since openmcl
is reported to work well on MacOSX Mac folks may wish to try
it.  I can provide a patch (which probably will need a little
adjustment due to different file name).

\start
Date: 24 May 2007 20:39:28 +0200
From: Francois Maltey
To: Martin Rubey
Subject: Re: [Axiom-mail] [ANN] new version of axiom mode for emacs.

Hello Martin,

I think I correct a little bug in axiom.el.

Try :

[M-x] emacs [return]
1+3 [return]
[backspace]

All but the first prompt allows [backspace] and the last space is destroy=
.

After this the axiom term is locked.

The problem is in write-protect-output,
which I understand as a write-protect-output-and-prompt.
So I propose the change bellow. What do you think about ?

Why the first output isn't green ?
It seems it's an output as others ?

;; As in write-protect-prompt, the last-character of the prompt
;; is rear-nonsticky in order to allow insertion after the last character=
.

(defun write-protect-output (str)
  (if (at-final-output-line)
      (let ((inhibit-read-only t))
        (beginning-of-line)
        (put-text-property comint-last-input-end (point) 'front-sticky t)=
 
        (put-text-property comint-last-input-end (point) 'face 'axiom-out=
put)
        (end-of-line)
        (put-text-property (- (point) 1) (point) 'rear-nonsticky t)
        (put-text-property comint-last-input-end (point) 'read-only t))
    nil))

---------------------------------------------------------
Are you interessed by a submode which allow *.input file syntax
with few lines ? Are you working about it ?

\start
Date: 24 May 2007 21:08:57 +0200
From: Martin Rubey
To: Francois Maltey
Subject: Re: axiom mode for emacs.
Cc: Ralf Hemmecke

Dear Francois,

Francois Maltey writes:

> I think I correct a little bug in axiom.el.
> 
> Try : 
> 
> [M-x] emacs [return]
> 1+3 [return]
> [backspace]
> 
> All but the first prompt allows [backspace] and the last space is destroy.

Thanks for your report, but I cannot reproduce it.  From the snippet below it
seems that you are not using the latest version, which I posted 

Date: 24 May 2007 04:43:39 +0200

to axiom-developer.  If this is not the case, could you please still
(privately) send me the axiom.el, and which flavour of axiom and emacs you are
using?

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

By the way, any xemacs experts out there?  I tried to port it today, but failed
miserably.  I was able to fix the problem reported by Ralf concerning ^M as
below, but could not, for example, find a replacement for
comint-set-process-mark.

On the other hand, I now use nearly no overlays anymore, and saving the buffer
keeping the paint works.


Many thanks,

Martin

;; due to Ed Avis, 12 Okt. 2003
;; Deal with annoying programs that print ^M without checking the 
; terminal type first.  Based on comint-strip-ctrl-m from comint.el. 
; 
(require 'comint) 
(defun comint-convert-ctrl-m-to-newline (&optional string) 
   "Turn `^M' characters in the current output group into newlines. 
 This function could be on `comint-output-filter-functions' or bound to 
 a key." 
   (interactive) 
   (let ((pmark (process-mark (get-buffer-process (current-buffer)))) 
         (pos (if (interactive-p) 
                   comint-last-input-end 
                 comint-last-output-start))) 
     (if (marker-position pos) 
         (save-excursion 
           (goto-char pos) 
           (while (re-search-forward "\r+" pmark t) 
             (replace-match "\n" t t)))))) 
 
(add-to-list 'comint-output-filter-functions 
              'comint-convert-ctrl-m-to-newline)


\start
Date: Thu, 24 May 2007 15:00:03 -0500 (CDT)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: gcl, shared libraries, was Lisp portability
Cc: Paul F. Dietz

On Thu, 24 May 2007, Camm Maguire wrote:

| Greetings!
| 
| Gabriel Dos Reis writes:
| 
| > Camm --
| > 
| >   I believe GCL-2.6.8pre is missing the ANSI Lisp function 
| > 
| >       ensure-directories-exist
| > 
| 
| among many others, but is in 2.7.0.  Do you need a backport?  It is
| simple. 

Yes, I would need a backport to 2.6.8pre.
For the moment, Axiom.build-improvements (and the next official release
of Axiom) is still using that version of GCL.

Mant thanks!

| > 
| > As a subsidiary question, how do you delete a directory in ANSI Lisp?
| 
| I see no such function in the standard, but am cc'ing Paul Dietz.
| 
| I therefore would suggest (system (format nil "rm -rf ~s" x))

Thanks!

| Just to repeat, 2.7.0 is moving to the following usage of 'directory
| akin to clisp unless someone objects:
| =============================================================================
| COMPILER>>(directory "/tmp")
| 
| NIL
| COMPILER>>(directory "/tmp/")
| 
| (#P"/tmp/")
| COMPILER>>(directory "/tmp/*")
| 
| (#P"/tmp/#gazonk_27762_21.c#" #P"/tmp/#ii#" #P"/tmp/#q.h#")
| =============================================================================

This will be helpful.

\start
Date: Fri, 25 May 2007 09:44:32 +1000
From: Alasdair McAndrew
To: Martin Rubey
Subject: Re: [Axiom-mail] [ANN] new version of axiom mode for emacs.

------=_Part_15710_31998779.1180050272331

The newest emacs mode is very nice indeed - a splendid job!  Fancy being an
expert in both axiom and emacs lisp... I'm impressed.  I can tie my own
shoelaces and cross the road by myself...

The thing now would be to jiggle the mode so that the output can be
displayed as a TeX'ed graphic - like imaxima.  This provides much the same
effect as TeXmacs, in (as far as I can tell) a much leaner, faster and more
robust environment.

And of course it would be nice to fix up HyperDoc, so that the widget set
was more up-to-date, and responded to such things as scroll wheels.

cheers,
Alasdair

On 23 May 2007 15:35:26 +0200, Martin Rubey
wrote:
>
> Dear all,
>
> after a day of hacking and with some help from Cliff and Jay (many
> thanks!) I
> have a new version of axiom.el, which you find attached.  I'd be extremely
> grateful for feedback!  Alasdair, is this usable for you?
>
> To use it, put it into a directory where emacs can find it, gunzip it, say
>
>   document axiom.el.pamphlet
>
> to obtain documentation and source or
>
>   notangle axiom.el.pamphlet > axiom.el
>
> to obtain source only.  Then start (gnu) emacs and type
>
>   M-x load-file
>
> press return and type
>
>   axiom.el
>
> possibly including the complete path.  To start a fresh axiom session type
>
>   M-x axiom
>
> Most things should come natural, here is a very short description of it's
> functionality:
>
>
> -------------------------------------------------------------------------------
> M-x axiom
>   starts an axiom session or returns to an already started one.  We really
>   should provide functionality to have several sessions in parallel, but I
>   don't know how to do this.
>
> M-up, M-down
>   moves the cursor to the previous or next input.
>
> C-up/M-p, C-down/M-n
>   fetches the previous or next input.
>
> M-k
>   copies the current input-output combination into the kill-ring.
>
> S-up, S-down, S-left, S-right
>   turns the cursor into a paint-brush.
>
> M-x axiom-paint-face
>   changes the face of the paint-brush.
>
> return
>   evaluates input.  If point is on a previous input, it overwrites old
> output
>   ``nicely''.
>
> -------------------------------------------------------------------------------
>
> Changes:
>
>   * I modified some keybindings and instead of axiom-mode one calls axiom
> now.
>
>   * I provided support for painting.
>
>   * by default, HyperDoc is started now.
>
>   * I fixed bugs that positioned point incorrectly and screwed up
> overwriting
>     old output.  Cliff: you said you fixed that already once.  Could you
> see
>     whether you had a different axiom.el.pamphlet than provided on
> MathAction?
>
>
> -------------------------------------------------------------------------------
> ToDo:
>
> * Testing: does it work with xemacs? does it work under MSwindows?
>
> * the way we deal with system commands like )quit is unsatisfactory for
> two
>   reasons:
>
>   - we do not allow user interaction: )quit will quit without asking, but
>     worse, )di op 1 will make emacs appear to hang. C-g get's everything
> back
>     to normal.  Reason: )di op 1 will make axiom ask whether we really
> want a
>     long list of operations.
>
>   - (1+x)q will be parsed as )quit.  We do not check yet whether the first
>     non-white space character is the open parenthesis.
>
> * the underscore character does not work.  It should...
>
> * the way we wait for output looks extremely dangerous to me:
>
> (defun axiom-wait-for-output ()
>   "Wait for output from the Axiom process.  Point is set at the end of the
>   line."
>   (while (and
>           axiom-waiting-for-output
>           (not (search-backward ") -> " (- (point) 5) t)))
>     (accept-process-output axiom-process))
>   (sit-for 0 axiom-after-output-wait)
>   (end-of-line))
>
>   what if output contains ") -> " and we are unlucky?  Not sure whether
> this is
>   a problem though.  In all other places, instead of ") -> " the regular
>   expression axiom-prompt is used.  Shouldn't we do this here, too?  Isn't
>   there a simpler way to look for output?
>
>   In fact, it might make sense to keep the current output number in a
> variable
>   -- that way we could also detect errors.
>
> * It would be nice to give the output a different face, as in mmm-mode,
> but I'm
>   a bit lazy.  Maybe today evening.
>
> * S-return should overwrite old output while return should copy the input
> line
>   at point and evaluate it at the bottom of the buffer.
>
> * it would be important to have the possibility of deleting part or all of
> the
>   buffer.  (Personally, I often have a buffer with a 100000 lines, which
> is a
>   burden for emacs, it seems). By contrast, it is not necessary to provide
>   functionality as stated in the section "Restarting and Re-evaluating -
> Kill
>   and Restart Axiom without Erasing the Document" since such functionality
> is
>   provided by axiom itself.
>
> * it would be extremely nice to have command tab-completion, as when
> starting
>   axiom in a shell.  (The polymake team would like to have this, for
> example.)
>   Anybody knows how to go about this?
>
> * undo should have sane behaviour, whatever that is.  Possibly, it should
> be
>   restricted to the current input, but that might be too restrictive. (For
>   example, if one has overwritten some important output by accident.)
>
> * sending definitions from input files is still not possible.
>
> * cleanup is certainly necessary.  I don't know elisp well enough.  I have
> no
>   idea, for example, why
>
>    (end-of-line))
>
>   in axiom-wait-for-output is necessary.  Really, every function should
> state
>   in the docstring where point is supposed to be before and after
> execution.
>
>   It is extremely important that this mode works reliably, and as it is
>   currently, I wouldn't be surprised if it would screw up in weird
>   circumstances.
>

\start
Date: Thu, 24 May 2007 17:58:31 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Nifty anti-spam idea for making use of captchas

I thought I'd mention a really nifty idea for making captchas (images
that humans convert to text in order to gain access to a site) useful. 
They're annoying and time consuming (relatively speaking) and automatic
image analysis can solve less well designed systems.  Well, someone
came up with the idea of using words that OCR systems have trouble with
in conjunction with another (more easily understood) image, and using
the results not only for authentication but for distributed OCR
assistance on converting texts to electronic form.  This means that
while captchas may still be annoying, they have a potential to be
useful as well :-).

http://recaptcha.net/

Maybe we could take classic mathematical works in the public domain,
scan them, and use this technique to convert them into TeX documents
:-).  If regular OCR text is hard, a mathematical formula -> TeX
translator will be WAY beyond most of these systems. :-)  And we could
use the results to make literate documents for Axiom, since it would be
public domain content being translated.  

The University of Michigan has apparently scanned the 1910 version of
the Principia Mathematica and put it online as scanned pages of pdfs:

http://quod.lib.umich.edu/cgi/t/text/text-idx?c=umhistmath;idno=AAT3201.0001.001
http://quod.lib.umich.edu/cgi/t/text/text-idx?c=umhistmath;idno=AAT3201.0002.001
http://quod.lib.umich.edu/cgi/t/text/text-idx?c=umhistmath;idno=AAT3201.0003.001

Based on their site it looks like we would need permission to do
anything with these images:

"These pages may be freely searched and displayed. Permission must be
received for subsequent distribution in print or electronically. Please
go to http://www.umdl.umich.edu/ for more information."

However, if they were interested enough to give us permission to use
the images for the effort, perhaps we could turn the anti-spam measures
for the Axiom wiki into a simultaneous effort to produce a public
domain TeX version of the Principia Mathematica, making the wiki itself
serve (if indirectly) the idea of literate programming :-).  I doubt
the translations would be perfect, since TeX commands may require
context, but I wonder if it could be made useful none the less?

Bill, as our resident wiki guru do you know anything about this idea of
captcha utilization?

Cheers,
CY

P.S. - I didn't know there was so much cool stuff out there of this
sort - archive.org also has a version of Newton's Philosophi naturalis
principia mathematica - http://www.archive.org/details/philonatrualprin04newtrich

\start
Date: 24 May 2007 21:27:36 -0400
From: Stephen Wilson
To: list
Subject: Back again.

Greetings All,

I participated in this community for a while in 2004-2005.  Simply
put, I became discouraged due to my own lack of decisiveness, and in
part due to a lack of `direction' I sensed in the community as a
whole.  I have followed this list virtually every day since that time.

I am compelled to rejoin and contribute once again.

I have set up a Git repo on axiom-developer.  Anyone with an account
should be able to pull from there via:

 git-clone ssh://<your-login>@axiom-developer.org/home/swilson/axisp

As of this moment, this is simply a clone of silver.

My intention is to begin converting Axiom's compiler and interpreter
into Common Lisp.  I see two primary stages:

   1) Semantic translation: Converting from Boot to Lisp is not hard.
       The intention is that `connected components' of the system will
       be converted into Lisp and documented.  The documented Lisp
       will live in the Axisp repository.  I will push information I
       can glean into Boot pamphlet files and submit them for
       inclusion in Silver.

   2) Design translation: Converting from Boot to Lisp is not pretty.
      Once a `connected component' has been resolved, translated, and
      documented, I will consider the options for redesign.  My hope,
      in time, is to arrive at a clean, maintainable, and flexible
      implementation.
     
I realize that the goal of a Lisp translation runs contrary to many
opinions on this list.  My hope is that having more Boot code
documented will be seen as beneficial.  As for the Lisp rewrite, I
would love to hear from anyone who shares an interest in this
direction.

\start
Date: Fri, 25 May 2007 03:56:12 +0200 (CEST)
From: Waldek Hebisch
To: Alasdair McAndrew
Subject: re: [Axiom-mail] [ANN] new version of axiom mode for emacs.

Alasdair McAndrew wrote:
> And of course it would be nice to fix up HyperDoc, so that the widget set
> was more up-to-date, and responded to such things as scroll wheels.
> 

Scroll wheel just works for me -- I guess it depends on X configuraton.
You may try patch by Greg Vanuxem:

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

\start
Date: Thu, 24 May 2007 22:39:16 -0400
From: Alfredo Portes
To: Stephen Wilson
Subject: Re: Back again.

Hi Stephen,

Even when I am not a contributor to Axiom and fairly new in the list,
I would like to say welcome back. I also feel that the list is more
active now than in the past year. There is a greater sense of direction.
(Thanks to everyone that is making this possible. You know who you are :-)).
I hope that this is the beginning of the creation of a much stronger community.

Regards,

On 24 May 2007 21:27:36 -0400, Stephen Wilson wrote:
>
> Greetings All,
>
> I participated in this community for a while in 2004-2005.  Simply
> put, I became discouraged due to my own lack of decisiveness, and in
> part due to a lack of `direction' I sensed in the community as a
> whole.  I have followed this list virtually every day since that time.
>
> I am compelled to rejoin and contribute once again.
>
> I have set up a Git repo on axiom-developer.  Anyone with an account
> should be able to pull from there via:
>
>  git-clone ssh://<your-login>@axiom-developer.org/home/swilson/axisp
>
> As of this moment, this is simply a clone of silver.
>
> My intention is to begin converting Axiom's compiler and interpreter
> into Common Lisp.  I see two primary stages:
>
>    1) Semantic translation: Converting from Boot to Lisp is not hard.
>        The intention is that `connected components' of the system will
>        be converted into Lisp and documented.  The documented Lisp
>        will live in the Axisp repository.  I will push information I
>        can glean into Boot pamphlet files and submit them for
>        inclusion in Silver.
>
>    2) Design translation: Converting from Boot to Lisp is not pretty.
>       Once a `connected component' has been resolved, translated, and
>       documented, I will consider the options for redesign.  My hope,
>       in time, is to arrive at a clean, maintainable, and flexible
>       implementation.
>
> I realize that the goal of a Lisp translation runs contrary to many
> opinions on this list.  My hope is that having more Boot code
> documented will be seen as beneficial.  As for the Lisp rewrite, I
> would love to hear from anyone who shares an interest in this
> direction.

\start
Date: 25 May 2007 04:39:58 +0200
From: Martin Rubey
To: Alasdair McAndrew, Jay Belanger
Subject: [ANN] yet a better version of the axiom mode for emacs.

--=-=-=

Dear all,

below the result of today.  Although I really would like to stop now, there is
some rather important things missing.  If somebody (Jay?) could help with the
first item on the todo list, that would be wonderful.  Progress is as follows:

+ Parts of the code are a little cleaner now, I hope.  This concerns mainly
  moving around and looking for the prompt.

+ M-return now sends the current input to axiom and appends it instead of
  overwriting the old input.  Cursor movements modified.  Feedback appreciated.

+ )lisp (format t "(1) -> ") doesn't confuse the mode anymore.  Neither does

  abc_
(1) -> 

  Multiline input is supported, by the way.

+ painting is now (more or less) confined to the output region, and copying
  output into another buffer preserves it. In particular, using enriched-mode,
  one can save the painted stuff to a file.  (Don't forget to switch off
  font-lock-mode!)

+ the banner is read only now, and can be copied to the kill-ring using M-k, if
  point is before the first prompt.


* I removed 

  (defvar axiom-init-settings (list ")set message autoload off")) 

  and related functionality, since it is provided by axiom via .axiom.input
  anyway.

Todo:

* For me, the following is *very* severe. Try:

    for i in 1..10 repeat ([j for j in 1..2000]; output "hi")

  in a usual shell buffer and in axiom mode.  Very unfortunately, the axiom
  mode currently accumulates all output and then displays it at once.  Since I
  use such constructs often to be able to check how far a computation got
  already, it makes the mode unusable for me.

  In fact, all of this waiting-for-output stuff should be rewritten, but I
  don't understand it enough.

* All the initialization code needs cleaning up.  I cannot really do it, since
  I have no idea what it does.

* Xemacs is not supported.  Anybody knows comint mode for xemacs?  It seems
  that they differ, it seems that comint-set-process-mark is not there?

* Still no way to send stuff from input files to the buffer.

* Still no LaTeX display.  Best thing would be if this could be switched on
  alternatively.


Still, I think it is time to put it into the distribution.  Waldek, would you do
this for me? 

Many thanks,


Martin


--=-=-=

H4sICNFKVkYAA2F4aW9tLmVsLnBhbXBobGV0AN19+3PbRrbmz8FfgdLeu6IyhGInm52KM8mMYjuJ
dv1ay7lOyvZdg2RTxBgEGACUrEnlf9/znUd3AwQl2bm7s3VdUxObAPpxuvs8v3P69aKeb9eu6uZl
3ra/5U1XzEv3e5q83rZuk8/f5efut/x9Ua9/T/41+dc0fVJ3Li2qdNPUc9e2RXWedquiTa2dNEu7
Gk8X27mjRy51ZdFu0mVRumnabCs0gp+XdVnWl/h+Xq/XebW4Jx1UdZdX56VLuddjVx5v8vVmVbou
/db/Jq++CB3l6aP8hfvZD0O7kgYv3Wy3NXl4uSrmq/SyKMvQlL3Zuff00uuZOy+q36zh35PXXdGV
7rfX/3L27OTBZ20z/8yt83n7GX+3rheOvn39+t9c0xZ1lX7+ZXbny+zzO3f+DKLm225VN7/9j/wq
/c6VNE/XTNPvm7ya10TDx3nZuasp/ZeWoUqfb2fuKiXKpPfLYrlMf8k3G+p+nb9zPAQbWj5ruyaf
09DS9CGGklJbdeXSesmUXtdtl27qzbbMm9RVF0VTV5hKS2vQpAt34cp6g4VAV1ssKTXU1svuMm/c
cZqerGt6WND7tEw0oFlRFl3hqJsunecV7YbONcucSHdZdKvUvad/VjkT9LzJ1y21hpbpnxfFwvHr
ZVmcY7O0V1WXv09XxfmKfll1GAUGlVNT9OpF3hSuu8JEQKwtbcb2mJp7gR13WTfvMFMaQd51br3p
sPNAHZoETz6PGzACCIV0a9vYFm5ZEMGoKXkcUSnttpVbpO3GzYtlMc/L8gr90GkpiKwnWHT012Ag
CzTHS0zDfO2qRbQ2r93f3byj3ZPPSlcv5zWRgdbAfk9et/Qf2jG/3a83Vw2IwSN7VMxd1Tpa2+Sn
qizeyZm6yKnvdf73uilkdjyOqW5nIkopn9F6VgvX8DeP6wVNgH767uxBos+ncnhl0ti7e7794dmj
YyU7/W/TFGsiLBFisaXx1AkPyTVXtErNuaMDXZYyGV6FxaLA32lHhH5aajanGTa8WAu/chhOElM/
p+7oADfLbYm/05YriLbJX/4yNzJ9++03yddfp4Fsk/tH6d2vvvpymtKx++/8/39OZ1fprU4dmho7
eMnf0KmSRrtkeuguB12WjXP+4HydXtVbPh+NW9BWaYrZFqyTl/WzukEDayzJFX4LpKbDs27t6P7w
5Kf0B1e5hoj3bDuj7m1DEDHQwgY/tiuiIE0QX3yPMZzpGNLva2o4B/W/Th0dTurjwhgT9YEW8NEj
2w109Ca0LDTyJq03+O4oxZkv8y58eozP/J8xQoT5LiAr0MWq3jhZc5ot89uZw6e0+rS005ReTl+e
vvjx6U8v0pMnv6QvT54/P3ny4pevmanU9JT4lDRVrDcl7WN8TZOkZZQj8Pjh8/s/0icn350+On3x
C+by/emLJw/PztLvnz5PT9JnJ89fnN7/6dHJc3z67Kfnz56ePaRtfebcTcQGT1rXRNCF6/KibHdJ
8AstdkvjLBfpKr9wtOhzV1zQ/PMUO3X/guJjv6YlOC1z0S4i6ddpsYRcpPNN5x0nzi81vh5Z7Wl6
Ws2Pp+mXX6UviDOSNH1WEoOepmdbNPDFF3em6XckFuhNtPD4JL3z+d27d7O7X9BR+ensJEn+liae
ZRlnOq06lpF8sjM9zTgmJ6IgJC9ogzk+1LsMPD77+QUREXyQxBRP5WXdEOFe4pOXbqZ8LDGJkQu/
w1pzU0uXd9vGifwiVtFtmStjo3Z5S0JhnZNcRPsmvYhD1a2MrKV9BOoLq8T5nNGDDW8po+x8RQ06
4hN8ECFoClsXnuq9xGQvUXNd/IPY82v8LX1NOkM3W/62Xq8zTPV3IhMfDuatOTSelntQCUXHf0kk
Iz7H5CHx8fYts3X+uj08xPHJU8jkEqzhfceKFE3ru7wVYTRlliItC41F/wLlqD1sV9q4ixHB7/tu
aCp1xXOdswyI+jS953gww5PtnPQtzE/+hmOPibUdsQrb7cRRVS9zkAGsWMTMHcPo623tsJ+Hj0mv
WueekBD4oi9cEavd0E+kseZgNDuSmzqbN46foSOWgdwYNM7NFhwtL8/drKHJXrXUqcpsv6bxfi7b
mvpbkzr7Hl3Sdog3NNpXESykZ3UqrbbrGfVCjDYoTZHGSVrDBRi56sN2eIV6kU5N8u5RXfMeJP5J
L7fODhIdPnxcObdoYz3A8c5eNPllut3QSPTIkGyng9QfD6ltzLZEuaBZOtkBlSo3YZ5h2zuaGZ2i
zm/8+7R/atou8kkLywA7StqRFmZb7DecyHSGzauK5JXw/jw9r2voT0vayzPSzjAU5qSgbVvQGe+4
SaHfoq4OddvzCyTWZzUGhH+tSR8kYtlW6u8w24rRcU5Pn4Yh5601QftmQzvYhDGNzS8IKdq6lfSk
tbJiy201F10HehkGJq/ZUE4j3XdFi1diIHbsBieUtgPopytaVPNyy9uKdJSUB1bMWaF9ROYVMXYy
RqbCjMsF9YsWrdez7WZTN52o+F4UEcEu9Kx7CytnORINJOqYer1Jda+5Mddk8xUR4h2vs2nC0ZYJ
EuXFtiMVNi/pt9NKSKiPsC+JrHNSI1S3nJEoWdKpX9GS094ABxUhKao866cuCWYlW2VmXLZ8inWx
yNQ0q457YEVHd/IrNuPegI9h6WFcxFsaWkXj6ChVzGfxuCQes7iSD2jLkOFFQ3mJ7UIPIJdULTBp
1t8jtstNLMVHhxYZcki0I2rvVLf9OzJpjQyLmqmgS/3qcbalzfA4W9SX1Rs6tBdOuMt827TggSLf
No27KOpti9lUECpFRfzQ2rhPbXz2OKN27nM79Hdqa+m6+Upbu/77x9m7N1B6itA3ixl+KSNVjv6D
dZmRjOalpm0l43pHXDFrwtF9dcbTOeNh4L+lW3b4Lyv6b1JdhzA/binn80F/zWbNtl0dxwubyQNY
q28g5lnGM/uF/aonY+RjWfM3pITmJXEiGL88ZVoUmJYFptfq/jfi8BssnmkZGlbdIOFr2gtKhLdv
K9L8yqvDQz0kvf2YnHbKmukI4EUs3zkplTxIbSKP5PiSVbyc945pIMfRaTvrGlLeto04bUhfJFXi
d5g1n8Kg6ZlUsa1Df2/cr9uCNC7+B3OkM2z37ebfSMGDoiVPfuqYo4/++L1ue/mRP6dxcFv8ywuy
e2hDlGSmSp8P+Zn/5zPlUfoD9NMwM+0jfQA7nq3NVsS3Mnj1VpnhAeeQcD4RSuL1EDl1yDyDFjSZ
KO/I2MFBy0r/f5QqUWOafJNM9B/poXx7lMBePFEBeGWK/LTvkrgwOjHfNr4grEo8EqK5sLhMICUr
h2nkxA3/Xs9a2n3fF03bsbznqakfg1WCfB30MCMCG2jwU4h2di46F/bVLOaO+xeZ7V7/b7HdL1dk
mLW6oELwZEIjoelJz5kSMj04OEpTthehV7EqZ7NmXgYKr2UC9BBHzYl2UHSi4iTp/j+wZXkeRrqZ
W8JkmzkMq3XEn2xUZU2q8ybvVu0RPvspzMLlzXxl50O0whQvDiZEpGvTg6yq58SRdFKn5xUr2tzQ
yc+nTx/T95gkiHQ8aIBoDYfVwb9PXr+evLqTffXmT69fHx2l2bfpgWyeF6zm0bBB1bBzt1UBM5wk
RQWXSQctVlQiNjFku0NPrkQgkr1AOyQpQdU9u8NWh6iHc6EKB76l41VX0AwrFys6LhHfAG8csvXZ
kkNLtL1IIyfaRj5BtAwq9ZQH6xItJ1s5vMfcJa18oz22W7bKhD8/f/jDw5+fmdZB/dJYqg7ek85O
eSJEbW3ipPKsBmPPw2ThivBEbVlwyyYmfbmrk3hapLXAcyLOrYu6pFPDSuEaZxECRKgOjfucbXtS
Q3kXlHXOmlNZkJFBxx6eq5dqTGA/8zzAr0gX+IcT+yIwBRx9cbzQ+PhQ7vJXPo/G/fyng82GnZGt
yIIgKVIeDR4qBxx5Ykxz5JGIcpJYwweXOSvXGY3dJH03fEeOlWcKI83nS5q1fs9Npnfv3Bkfg5pY
B3cOwnPhwVmZt10YqfRDQm7l5u9oeO9ZPyRJgsMW+YBpx1+4qnDVPKhqbUz9SJCB+uICTV/SViqI
uf5wnD7Yzra/0q93v/rqv/GYttgJbL9lsGxIx15ktPtIaJy795v0v8ppolMzg9J/lBKXm0Abn0xE
s5D/HB3xE3rWksKYkeTpmkJ4p7LFSZU3TX2ZdXUmJn06gfRgS0LayIgw1Iy0Z5/B4+ngS5BD8foQ
fIV1PZCN9rluERaYMubj6NsX9aK+R++c39OHbF6TatGQckqNVHUH/wpxVtAJc4V1LSz+kjhC1NSE
bM91q5YozS+duHq2OWKXIgIavC9Sl4PbYYg0JNpKOQ8yr+armlWb0B7Nhho4mtLJYnshV2Lg2K3B
FMjWWS6LOVb7ys9pAkF5F8uTiTzwq5aSSlDN884mevD69SFxf23UE1T/TM5rWglSMpvUFhBLGJ9Y
v8Fsn/TO5OSIGjx4zqonM6KwEMLyux0FhyhFPLwiMkyx4dOkBuu6LFp3gF2V806Qdzf9Y37kH1j3
/cdHJJZ6g9TjuSxKLMqEdiMPF54KjeFU7lKU4FQ483F65jpx4fKvGI0yCTnGLQ+SWSfaw4GRde4J
Te0JB8F1v45xgwl/lUkT6V3+YveTEV4FHrEzUbwXvyTL8hJsCfPUX5c0uN0FgbsDmxa7p50GS6GF
sS20cBw2MmEMeXXMZCiWo/zSNmk+n7tNZ8tjY+uvmUyZ9goJMl77fRNPPvlkgnM6GW74A1FJ0klm
XCj98ijFVv6QcfDbk1bImN7Zx+UjyhdtJi/pblai3wfz9k6q5bUH4PjGHW/HdeJ+DZsfDkwy3gZn
45Aa5Z3xl7+owJbNuCJCsXmiim7p8mq7gVQZOSt/BQ1bNk94Nk/qKsMhLWBCyu+iusUGnnBy2RFQ
qnJiGBeOCXruugxuUgxz4xriJ76Zw7jfnR0tY/+w4ejh+0PDkTZoOH9jPUhcOOLXto+g7716Fb/+
5g0zCvtRpkQ/csiweacDSwIzOd4nrJUGCDQaL5mwHyhlTYZI8Jgeib6pAjT3rCs9rSKvG5v1NGF1
HhROHDw87SmryBKLVJMcrjyEzxdoOF9kdVVeHQQxX1SrYkanwz/DCZPDi7PRJ6ofcXrICraanJn3
xBmZb9FATFJRkG77jdLvVr0IeW56lVgM3r5Lh414KU0Inv13V9d8F77gboh6DZlk1Y3fRUPrUTwc
E94ixu5V3ky2VQkOM/lmj4Jpapp0e9PKjo7s2oYHy9V9fDsD+qbp/pYmd7Px1o74kc25T8mPHxhv
6D7vOhJ7+KcKBt22IoOoFKOPlirfll1PxRCnAlGcjbMrOXqXLl1vSZs0lEeiBt282Ub+WDAU5t+i
mm439/Zwe89I+O1su/HM5Oj6I+3VQ1XGRQAyLdSUDGcwek38GJm6UTMwPTXYdKsFPTPW8k3fYYFO
LYg8n9yFRD/oPw3ifviYlKW9Y7XOeDz7x5K/t2cjCvWBOj/M8zHsdnzuoz2T2BIdxl0z5mtaPQr6
wMLRIjozov5AY3vIIRJwV2v4pi+m9XfZVz3VtWeaD55FBv2RxPFDGLO7rAU2JL4CceLUFqHLGJ4g
f59EJ+yIT9HP/OA4+Y5sRUhuhuIgRlM04ilh55v9VdBZFdlG3cqAIx7WghBc3cBtmazzK+8K0fMp
HXnElQTHoCwXRHjv3AnowYU4PxO4D+cd1JefPQxOnH/s32H9t22L80rsXERRSrc45+Hm3nki4KKB
k+Ab71tQ5TKTJ+lEA6ub9FB+kaWNXO6xW/T3JAmuopnzMSNxPytABzSiZfKBqyx9+5ZX9vDQAF6u
EjcPsdYmHwSU2HgWRxyMQMz67VtzRx4eBohYrmFY8Z35+BaxKqLx0yp9WVQLgAomOa/bl5998Rnw
VEf8Ss/B6eEcbGjTol7mVTfYD/m2q8kqUwBdu6GD2gvqYodeOmmbA2LWwXHCkFPx1zmNgNmO4UgY
76j3pIiyp1Ycxvxm/7VimXhCInDVo0phTnB21jK0lHsk6TSVUKR3nfqtlxjhWVBA++15u6PjvPNM
j/TBGbNDVTnZK21O52cnL370e9LjF8SRj8BZw/qjHvzgzyZCuHmGvwpfENsvPBcWpyY2oCQZPtgy
KDHbeP/GZD7wkh8IvPUgYpLDnmPRFfMj7/zvt7Dz/WS+6PUpL8KxvmQ8A5yjxAwB9CS5bsKfVs2W
kSdsSpr7dUvEHB9Bsn+M1taB8mjxwjPrXAn7fOcit42AE3pnnIO/4lkmbuPW6kReI26vdtQGp7wB
4A/b/p6gGSEcxf2cLUeMFj9OCBG46dU5RH979vzpD89PHot/Tt4wT5FgHJ7/cMZ8oKV/wmtUE+8+
jswPDgYcnMTLM5F34UrUpoikF0TRCVx52MCMJDlkRVn7VPL2SZp8gj/UIrYHNbshJmWOmRBLYddY
UL9pfnJewiQ1sBFidsdjNijtlh/UxRRFNehMm33aG5t+geb5sNsnfVoJvuZSu2WfwmAttJ0n9SUx
wK5u1LmphBu48UeF9cS0B/n3kbbIdmMc5zC5n4vrdNiaPeapSlPht2EX2gejqoS9tQwq0NXkHdy4
eX1eibvW9RXtDA+JmUsrxp6Jn5UFPL8ag+sZiyLmVJD6oSsd5Z1MPas9f4F0cbJYDOKFuswYrXgh
mYmX5oCULSMfx0OHDvESDJCx633boZ4xKGsxlRnJx2tSw1qAjUx/UQtslbcSy5k5jh0CqYXtsVjg
3MgB0dn1nKXhgPdtHX2s830psC6caTJeaCYcCEFATnwqJhM4wEcaBfC7ROC5sCmemDSkszYnPPN+
O6sanhREuwH4OAamh+HY9rbJ4CgYx18WADgP9Xolujj/EQ4gOQ9GyPzoHOoSHKes7nR1XULJEXXS
K32yvNLOzJFGUNSNh5EGL/GNbN68n2wZjBogbPGkr/49faPGDzvOu4/xcF4zpiBYPmhYf2AwH7QN
I4fH7X218OJhQSV0RNypADzBzj7rTX0RuGSIzrzctqY1DXAg34wrUtcISAEqezyZgkiQ7KAATkl/
EVWXQ+S1hKJZaugxAkTj/smZYVht0eTgkA59/O44TzprmxEgQcpr5MxAvqpjctCVFEtIeH8uBcCa
QEWXLJKZCxk66LWuemPjBjFAOt3YU3TgAD0UIHy9PV/t5ktgCkBk0YR1CQRC1HYYq2E8A7KaUe09
IG0yROgqXhl/IY7ZAn7PoLZLw0kIo+VuT5+KjL5k4+E4kdwhZlMG2t4BnHaIq1tXxRBqOkBYv7Sv
N41bOgkpwmYQKGgf6gb4G/5Lekux8BzRnNKtZbRwlDIC62IU1Xk7ZebFirnLGTUbbCdgvARhjK2z
yBlwfm7igSnRKtjKqUEdsAZMtrAGES6C2quI050LLA5bkOhp440QrW/fgh/PSNDRDmu7KzpfCkxT
+DDPFVxVMi5oLkQL7Tcg1BjRCfZRSvLTwgPVbGWBVaNxNVfCuSWkh0hsFlDRksEB5C4iYGRIF7xX
l1gPOrDVgh0fAQGrCUxNwMiFJZkOdgeg3tCoJINrMGwz2SLzUxU+NiAVD66APdPB0w0SIY59Dhl1
xUjNVjyJPQowWLaEPtheyvYnHUfEZOM89rpdFUt7nZpqt6RC/Lrl3CX+Dq5EiDtgGE3IQlqncH3M
XEwYS/1p8wvBLAkWdEgVm2FIoxA8L0c8gPmv0YIgy2krTgUBLdQhUrckiukAO87RAvQ0B0q03SLO
2hpp2Q8AzOlCQKxsgWEEvObSvfTCTEpR7cJq9KF6FGBlCmhZuiASXvHQaj20W/5744CWmUKZsDWT
EZMpivVHlp8gZFiZBhqb/rsD2X/N9BdpwHwpU1HwhNmDaKlwv7AsUdbF3RD73VbMAmWzF4KrMx8C
sWRJMxHxliBFSrbYi48SDCISROuBphOJKZ+3uVB2GaB9U1BB+JEeN+bMkdBI4jPnnXXAmNOeizwt
l0XL5o3QQRwLopQwZlGUM7EVpjLMBPxww93AUWEpe2FWDIdmMtFoG85+Wls+iSBJio623VLw0TFg
MdLrZSe1CK0BiRVU/FgsRdh9dchx/M+rymSkr/MN5xoohm2u6ruiuXvW3TovDOattmViuSb9xzLL
pWRAsaNQxh8eDi12c/Q89z+wePS6RDSp0ZgqnNrXhrA/+ZD4tSmRO8b9JLZGzQUQgceI7We7cBDx
zXQBzGnBeo83ZcszJnbR9gjNTWi4W0IyYIwShTEUiihi3FIfMIuPdfeyXPIQgEp/sMXs+1DGJ6TB
G9Hgr8MLWHDAm+IjrzCO/TrS7nHlq+WnoF7q5rCF71BJhkQemrbBG9iC9p4S/RShLj6U4NIMGcqr
Co4goM/RF1zkDiJvJDh3d2+E8Mb3B2GuyHzFsgPlJbxSsxZkhWlChfj2ylqzOdTgE9JlqUcvQUKb
m40TTAHbIpF9zywdhjceRoTXX3qRFO/ycJV0q6MI+AY24Adxvd0JufebspgXHeQiZ2QqYSN73GwH
Y/PeIiYbqoXax24lJBqVgzaYx7Bpzc5Fr05IC2KC3ePF7wEZAkDnz0dxKBrGOysBNGEGkgHnCjEK
R+aM1HSGFwuQqeFjI/o3fKmty9ghmxEzjU8P/VOsRBpcV3Rb2lrUWrbw6HtvcJrOJsHeAUBu+EcX
q503NS3j4NOP6h7JKR/RdfTZbrdE0KdYUyTsXLGpYPjEacpx+ZVGBlNOYxOBSwJU04BmQts9gcFE
okdBh3kserslgplhazqG7UhDg6q9co7yC6ZUe5y3N4yC1t8eJ89MopdXWg5A/F29WIf0xmqfKt1z
uHUk93yvsfa8P6qlQP60uAGgqtiErZhqvG4z1106TfMW4DqX6Ohcu2EsOeM/8fDVq+zbN28MR8hN
mT4OfbFAeFZydiKYHRIf04CyS9MznAMJuLSqjK6JqRRImGabSNrXJOWhW0CSsphilgtitrIAUknl
UwQtGiOdD+tNxFapJgvqMbLipdYFIPMeYahTVg8RlHHFhWr6KJtQ9dD0UKi9Ns0NzNWumTmOjy44
JqahES+vF46nw04ZSystizUKffBqI4R7PLaSKojEoBksI+9WVk1rTz8mpXfoVcyNkDkmFrq4LZDg
TppVw1qA8jSNkqoHvEAWhYzmmZjfKuDm73R3MIgbwjkET3kkjdNxaYTVewLUMcoOlqYJe6YNHhsQ
xUx3CYmL7sahZ1tOiC1O1MEhqKyUiq695caN2CnhmBt98e1jJYpoOQ8wI01o4v06h+W9ys367UgI
sDecmN/CsvPmjlNFlY4hS/i9SaQpxpu49zkXB3j16oiL9Ewk8zXtgv/xiE6ZVsZpze/Ne1Ax4skQ
rHeciPLsFXpvOI1lIw7T5eRkemgE+C7trVmdNwtiv15liyVDpHKDBOFpjMo5eMZuBnDlvwMKFDiJ
7z8iVmOQa7h6lI1yql/iD09VD780dC/pKVdtYPuFwOgvPT8iRW80dqXBOE78/etR303MJgArjfJ4
1Gfci7X03cbhj3icd2CgBk+3Xl1lPZnNQJPI6mWG9Qn4LvtuB1/aE92yAqc4CpYUyT6GPevB49fk
rT0rlIyvkHQhu5RZTB6rZGGD7fSf7N0Px+lT00Gnwm8kGEG6EmInlTq7b7+isOhqbxZEwOCAHfRr
tWeZAkBsbMP71Yn3zu22y4iOdJv98n9jn96657F9Ge/f+BNFQ8XciXm7OIp30qQltdlLnw/gUEGB
3AnhR7ql50x7jgL3fxu2JDI9EbYUffXPYkmGNvx4jhRBS/1i+2H02H2lJmmP1fcIGrGSfz5FxcEw
3ApHtz4oYiF87zpN/+mLz5v2pdo3o3JTD9KerdnTokWHzns8NaKnFvfyBNWsnrBtohUfMkCihOXK
URMHx5/+7/TTf/GoFKYY93ZXf/Eql2cCTOYBV/DstX8Wxy1NmfteEo8uq8GOruHq1zDriZqrdJx8
ZBc40v7TwTCVAmSOqtIraQtsM+1gWM03MNlZ6hHxvWsFC0keazwt8MbAEP9pVIlG+R9KEQB0R0TF
Btp/NxZohL0TDDy2/Qt4vL2Fl4QoU/S5A83EZOgny91wlH0mKfrckTK9p/HysRXOjjpxvYGR2Yik
e6HP+IKyO3o/p+7J38mYLjjUXfp01yMdj93W4g8she5YcTvo1JNoXdLRdTmvxe/SSpzco57qoA5q
JbukfVeQRbxCIqr2pQejnuc+UnDNUqq4HF/J+GG8kL3ppG2+3HMGOfoxiZnqEFtlC3K9/I7Vzpu5
+EDKD1+7+6fYeBi+FsnFqNOOzdN4YzBC87RSLKWvCQST3SNEphoLCq7OtegEvQob7Jy+FxD55u+L
kd/9JyDs5irTxpUXeTchrKYDwfPCzYpXAiKtByQ5UOZLQ0Fjw15eTdauy9Pt5uhNyLzqH6ibv4aj
JnwfUffab8Ep/Ef9M3ntd1qb53B3+9p6DSKR8Gcg7N5I2TQN98XuaYESbTY5AIxllDCA0qMIKXmV
ue+yNgybRvs5VWBGj98pFi58mXeJufeUDfRWKQ2+5ePdXUIiRejB2+WDneIf5Pb+MKf3rd3aA6/z
mYADaDVecM1B2ruor0o/KKgqOIaj2hqCLSh87bO5fGJcdbcI1CYvmmSk+lMa4Q3ndVk3irkxbKaI
rqu8esfKtxR9quoqe/VqibgVlpgn9+ZNKDv3EwNvXr1yVVPMV25hLygegMuLMnQBMqVOcqm0OCp5
uKLn3llFpa2mlqRs9anaBKFrQ2pvWEvZIQm7LrgPtl92OtJG2RFF0za33BVK3KBolEYavOOt44hg
5Qv+TBVmyYuDiBzXdUbPbYhSJFzBaxFtdw7+KWykrkaw6cQPEdQoiw0LOIt9378ttcYKgUmWw0Co
aQkM9x5kBeZBJARR81MSTgxPh4tlaB8eDWItPQmlSaj4DvUfquudK/v+/AF/B/+5G41r4imZeXpk
vEND0rJX3q+XAO8C+99ZJtGvDChy6SIonaD+atFRgx3k3uMsarlEYCu4jhojrDinS2HLGpYQPBht
w2WZoyimvL3IZrQHtpVhfRaK9NLqQbzLVbInON4XdbFgQBbpM0vGj0ommK83G+B7CnFyhkSbb63c
tAQUEh9ctSK7HIDPRHNbo1Qi5y+tFDAnGAPBBLU+ACAn51JxLJxhxGpvLtYwHPQ606k8KAQwzlhx
P2uBOElUPOGKkE5S5kJyFJ1ArVkeOG2nHglNqkWVwIVUky5E5eTotxXLDHVnUSIJNcDWsq4CikGl
eC1vHBDBcNwDJBxVJIULgPpVaZr47ntVlCA9L+s4t4tU5srH7vIqRirSEN6+xbY4PEy8+dPL0/P5
MvIsnnfhWqFefg6ATqFDlOBO4akfRdA5s+3Ukj0YMJ9z4X+wEq3qCkWkhG8Hu4oDR26h2CIM9Dx6
hzEvC0TXkAuxkMGxuJpKTVKJrtD6jVdpgw85VCtVILJQ3ZyNkUpqx0bzJJApbSxY6mz13lLxP4HW
fA/ur/OGi9QcUNMHwmMOvs+lpCBrzXWo5Km05k37dqe4AD88lBAI14tgFn0P7W+Ux6ijFbADlq5c
hJcl3m5pJUODNFIXUakfFZsH+orB0onwgG1Fh7OYFxtmGuAGZTHvWh86jpvh7aGQ1fa4n3DbZIOy
E6Ppt03m2zJpVoriCGxffzemuYaYRGapw8u+54pPPS+/OSRsO3HS3ej7wXkteSvGcb2Er+eQhFMt
CCeb1z/EDQRYOrPqMiwKRz0C4+7VvxweBrNqwSkug+GkuT5TDch4J3rMh1LhQwKFVABYvPQKpEYu
0VaLy+/seHt/1xizlCbZsAdaAiyYznRgs7y1hjxthRfpz1E1iFCIq3RSEuVH5shAIqI0s6qy/Zyh
KiXe0kqkU1icro4gQYmTkc6VqENUq//YXpWuNVbcy8hzl+Z5UzQTq/3sJ4qFvw8pxTNKPvGON/nk
m1Fy+T4YRIgbFMJu4ByqCM2ON4x6GUMilJK9ig095mOtnrBbWDdHvPq+YNLIfkHSyv4+RwTd4SRy
P8WJnXumrAfK/0mSaMuEdDAeHnEvo4UXAWuHyRbtWkAa5lMQSZxoxMGAq0HgSXWigAoD7/U5J3jX
txt4GHG+t28FKVb8AygSADRkPuHSFUFPRokOXBzUZ1T4VqkxWwBF9UY1RaFncZKd4Cn01KvLn6uu
Re7+TK2QxB8quYSlFYWRk77aNkQKgj8OWCiu8wYYmmhZ+awW5FSySzPawufnnNvn9wq0RVp2S4f3
aeGWd76oJV5BWgopb1Yb2t9EYqsp0yQSiOK16Cep+7I9i6Kdb9uW17VEUktygkPtq4RyK5Eg91qe
NjsdbHwfURSVTCE3OqaYucgIBDZhLk2PkelqrikWx8yRnyOVXQWE3VejA0RI0rBaSK3a46MCdkXL
nXMlf612/qh456IQOJeqb1jkoar2ltVPjJC93v5gSzQoiVBPO0EkhQP4oenyA87i8SOVZS8Bfsbz
sy0XthnkS2/WrKkmyVNF8VDDxAjmnQGcVmJG0SL5bDU+39bpOXzDegA8ZZLeGmlhU1MGYr2DizAz
tIWMKosp8twr1YZaOCygmOhMNCtowA2VuQVm83pZ111Vd+43MX1YUkPhJta382H4jjHRVuMD68TG
z5gurQ+puUgVe8majMmCuFLXmvVFwAG7Tu1z8Z/lDI0bvB2njvQAxqFyVv8yJ/XnrnVIA14mbnux
OS4ZFsdOPXENzpzpFBfClqOdnfp1RoYADWoaHQck+MCz7SpJsKuNASnsaSis0ozaKzqDACoETdp+
4NpNIaovtQ4rBRWEkHiBFFEt/x5t6AT3bpVbz52FTfYOQ8vIv4qsjuPfVUkOFLGsiTwYZ5bAB5bT
uNiM4i0q3lDm5WRcCzO2sujqqSq6acI3fZVlyzaL+QF8Lsyip9L5hPWC+/BGsKLQKlUVW7bmjZtJ
651W3YiW58UqRhFOxZb0bRKDj/AZuWYxbemHMk4kWoh3T31x7NVAWLA2xKZSpU6YEdNys+NXrjKx
zOSKK5YwXM7yqzrNkIukorg9iSc1RVtXbDjK58tcTezIwQCmR4sUBmURqNwjSPP5nCeYl6asi5VI
bFLrtSwHNjXr05EWHWk0u7ElPIsjvPd9ypL6MsCjosaZFRJLgJPRit+NqWO7+095pnfUmy8wlNfT
JnfgBkmALwfv4Wioa8xsi2As+ElB897kQvRy1M93vaNvJHjJnj0P0uCXhsrrHs111FjxQejYLX8f
zgVmZOw7/V3twQUdqApWHqsfdJRQotAX6BbVcONqbN1a8/+75kq9W8ualJsEBrIr+VR2uJfOLHNl
W7NIQzF4HWqs5Vdal4VzQHGCEJTNKwnTcHlGuXkJDZjzpX/Jh6XBNttFAW0DimgrF5Ycx0UiOc2S
o0J5a2qgxHatOm7vDoj+JQ7Jfdk80Oq0NBDnsmkWNDEixbzXdiebt4lZA0Ar0qI48IPc6IIM7JXC
ipoJiEGloDQHVqV2IRr26iSKsVjkmNMoOYKL4ld2M5i+xMMzZsrOPbTDlwJU/mYoq8FQaukH2QzW
YU+hiat5RQyEXx5xNan/Xn1M0PzMx3TekGLV8zJ5j6tW6BxzGQ2al/Vjn9Os3LqxfvxD6+uRf3sZ
+bbQr8349j1DlI/0GfnPnmNOf7gfzVjkriwH7OC+/PjBrUfF2/09J1nO1nSKLiKSjZNZORdPMx3S
wx7KkAfP5Ud7RdbZv+JrOe4fpg9vDwc0gBaHDyRjbxyySHKL32SYEMJsiJ0gSS09eIJUQX6GVu6l
BzeEdPjPXqLe+KcvEuLEv2gm83wBSHDb1vPUD328z36lJJZmbIFmxTLzpnyGa0uUACHpLYraSr0z
ThVst42llYgO43ExDGmUvH9uy2ldF2/Q9dLoNTsIukwFQxxa13JJjF5r6fAopQpNxSkpV9KaJmXE
s/XCmMdT9x8GDGBR0YeKAAKBpL0YnhhGGrCXri435jhjrV+gNV98nn7ua8b24VOfC6awh8S5e3Sb
Fu/uafGutDj8MeFKrIyykiIyIzWVe7VSB1rKcMd4j1jAbV0DOB+r/moguQiwM1qlNcB0RCANnevj
LUkRsYk0KLXXlVwfNJSdae8mJIxsq3H2EUPXxgGLt6jvCt2vpFXFVSFVqLwl/z7aeW9TtzLpAYzu
xsMdEjF6M7v7gesuM7J7pMCPsvS68Q9D50Kzb9OohTs7CLDByYje7ac0hMRIJU2f4Y1zgv9Ma7mD
cf5Pv45+9waM43/oWn7EIox2NwJ1HePs127X/3+mOBBnNyNJxALrQRF32eoNeERpow9IHBzmW7UA
cOLecdyMUdRWGKo4OhBpYmh/P42KAz0ljedh8Ix8B0daq5nZu6V6ulCgh+MjVpXIX5EisWr/rvg2
E39xIPt8SvbPGvxNCread1uwi/0LCCXL+bumfueqRK5QlBI8lR9LL3E5qIdt5zbt3rTuU/XwWaIr
43bUfH37VrkM310MA1HqRwk8J66ERvvQkCMe2mceMHY78XcZ3zmUxeWtKiNG8LtZW4LmNpdBeEd6
9+qqdiuxWXMXe0OYGlMwERRyvV3Ym95R2ouGXTQ9fJOfu2l8vW9eXuZcldanDkvJWn8rhvnGQi7F
Ln19BDYqXEYt0UTt6TBwE01bSCjTs63UuWqapD4n2Hsa9OMnD39+EccRfTaC3vML75T1HN9gK2v/
ECwNxY0YcCPGqyRfGkRWHfCRy9RoHceJ4ytG1d304seHTywT2fYIwhTiUDB/jG2egUvWU1kooiDH
xnExMCMaWqvcSJAKK2sEeODmAlMW+DIgDLackQ9qd2VphM+aepbP5PICjte0SBE4Z8SbDKRo90Xj
opakwDVH2no3COFjLdsUAXF3Es8f2rW4HG7WWiMIBWhtfQWTxQk37Amscfl7qUfgCuHaepns3ONE
5zeq8iWArI7hBK2F4OwU+uLWch1SopamDyXoQPYkAe0Ac62S6cjyKcBPymRoeWBfFDWQMFptjcsU
jcHPOBYQOcVo6+RFo87iGDrUf+Cv8BJw7W6nNkZ/O7Vg5UIdOqnsh0CH4YWxkwxI4t5vuJ6PFeXo
/AHwEWTvcWfGZTfkjF5K5dMZLzmCDQyDgFJG0LYGtgWkQiFpgpO8NQL2E1F2/eeun6d8bQ7p4NsR
lMzOuPo9WRvX6VJ8L55nSIGoUpJKbiVVefWOiyXLJdlMnX6u2U2DCR2+BHRWsRCplPendyX0VSxF
UIqPNwAMEb2MYkahMdc0UttDncDh69P0fMulsqIbhmeu02wpuUhh0A7tCGDEGx+ojsqgUHulyz3C
B2WL6rWb1Yur1JWtO+5r1dCtMvVv8N95jx6ld8nY+MQoF7lJdBQ/1ANECvNJK8o9sDl2Lh/hJjyo
MGBeZop7FqXLNkHFtUpDvNi+twOssLV2LP9U8A/nxYXcPBF9rVGSohKwiAU4ZUg+HWYp3nsu/NUU
i+j7SL7rTryMXOvBkc9ZAz72acTRIFi5+LjzGq2N7urdpjB/jor5e8XwlViM0Z7Hj3Htqt2GdnCP
cT0+lAIOYrEXn2zo6PBZETVspfA9FrW6mHaGmwZxNq6zohguvvtLi/f0VBAAmj0yOhICnkdnp09Z
Q90JsIY3tHSy1NCXwEi/4qGNNcLvaGB/3koZGUYoQOXmWaMyLAkVHnsicsCCpyIM4lpKFjuNK8GY
ZmewQ+LmXMi9t8GI5MMcekUHO4+2sp0WPAXxLmO2flOI9eO3ZWhDBx/x6aBOoVTXXrZxoyzZ4+a3
PJFruc6eP38wT+SWcjKm8H5JR4R7EPKlw+KLnL/hzPdX2jd4XyDdrBxe9RH2DD7x6MaMk/kiFgZB
Zq2ojm0BTx+mlFt9egAPhSMylwAU0JpQCP90ZG/MaOxS7AE5VIoIkNDwiost8/wHfqxo7uqU2Yc6
4O6fbYcqmZTC9Y60Hlvk32/FGeXVaxPk5UYKS7BcKIDQrLcilC2SIruV5Of4E34vnl0AivCF6Rpy
3pHGZj7vqIw7yffeh4/b+3YTtY7GpoCdC4fAQvv1bH8ntDZ+C3WfZJXHKUfzHFz16sXPE4bfIqSu
t/HCZpFC6P5G4Z2W9TakuFAf3B4CMvf73bC9KA+nOlwk0JR/QXf/TKrExyiYZFgqIJO2xoVR9MyS
GcZNKE5e2RmD1AQ9DPetMm5nR/jQeZdjO7A8Imkztqv4T3LbddyzjPtWcVeH2K1O5tcRj3WV4Tpk
/NcCVr/TfKpkV+EQnZL5GBfeN5/Q0LsSFcxgnUNqHPJtY63fEZycibw13Q6/bgsGFtMn/0v/qv5B
xnUiDYdrPuPeDVNQBeJrxjmcAiLAmXm2nUc8z67Mf9hHn8MYp6kx2tYXW73q6yFi/ogvjlaaFBJG
ExrMJ8Kx8RR8gjVAgNMISsSHiWsEO1uAasTN1q/jGBvNmmkBdKllhvMtEwuXegHCjha9S4HBoGOA
/+GwtT6rnWYrCZjGJ4nvwEHIHFLHyllXV1rtOkWNROkbH3Lp82s0Q7SDHF5apLJwF+HaM/VYccD+
DL7rTLdo8BOwe1idZSCzvJCwqDcLp59GLGYl7De91MluE/GUjjgLxpepF2iHtURq7cOo4P6gP8mu
Z6kX4YDGioxo2nrv4uvoXncvENpNzRUCpJSgXp0W3VwTqWlkc0ScZdA03132yRhX+WQPT/GaFQyc
5S0Vsn64TdXHGzTBURVw0ncz7XvnQ4dkX+7TK0aijfHFt4P59coT307fTSNviLYS9C+f76y7IKrE
cumvQeILwg3ndukkosJFXUNBV9Xsdk13VcyW4zWoaKV1yUZqzoUBq7/GBpqawmSyZcc72a/W6cNz
15X2u1bxs0rTwF8PzsRfrYH9R6E39fTTo3DlX2i8X/VdV9Cg3BJoiup6WMSs5mtoyLjyJxOU3tH9
OO9LCX0NrxzZuZj20npGQrZOJWVsk6m7+lyhrXD21CNALr59Ddd3iMXtc/w2dStik4d2vPuhOrmM
ij46vL/wTvTtTRyKfZa3Ofu9HSqf7T3UgclFci0KcH/4hG6aR/TmP4uL2AUG/lqQQTlvywqaWVXd
JqiEAFVrrXQWfKZMXl8Wh7/3sWah8a4Uzex+xdsI057Y3lvB8VPGDIwnk46zmfGiaJEzwemVFB/q
/hgUfRpaheOD8at5Q0E4VS12rTqm9e0KZcgqHfWWSZdErYgeIOB5uJVAVC4fqKZfsvR/chiYH8TX
zZhynaYPm9z70x+oNvu7Xdgs9wNJtaSpv5+HrRfOT9mAETSGE9/QenZ2Weya9Ve71HfaK1TZg6nr
/RnDoGNm9y2EC3KSyN3ib3xT6EIUWFCAP+g6NX9MbG0gMJCYhdO/RzW64oF7HRT4mNdbzmBYpmJB
+2LrTSIQfLvRBsqupLkVUdDPT0Tsi/59xNHcEszNIBn9fFA2WVjG7TYMLdpiIEaXJC5vIklJNmSU
3BG7097g6WDO36H8B6YMo8n5aiZTGpi/9M2FoQ3Si0HfS0lU43Svi7q84Co+uzcjpWd22eJjV22B
XbFy83wRnd7046KbublEBUIbTu+my8lkrLapFmqqIFDbdNvJRVT91bXvtAJJdE/SomZHib/SZ2ew
coegnZNnfMsgjfZHf5MRinioo61/Gba/hnRWc2YiX33b9u7g5RIbdoXTY73C5+uv/8vun3DRE15L
R97gPx9Wu/z2dYQ/pLLrB5WO/JDihCMV8vbWhxpmkFxfyuSm4hzXlIUYz3XbG6u/Ln4z7kjbYwSP
3v8klUOjOykf8qYG8oL/MhVg2MPH9NE6n4aqPiEbnng6K9IKrdSrvnoF6aYJ++ikGAiXVdHKFWt8
qzwLmi3fEsiMmdSwnK2Oldwup2j/2ZUgqHofFuE+sWngWSJg2/Tt2/uuLPnadMm14vvlvDsmiaoO
hY8hbLYzFOyMy0fx51F+jXcuyt1KLHbm6glx/kK9okrRoYRRaXKPiddhMXmsbXiPs9OlLVXaE7kt
ke+kM+Zgd86WIVuxy9t3U5kBk6onLCzxm2yHRNP+nY28R8XBRHGVhbilFrS2gMKUV3JZFdMvidxZ
wohzxuH5TP9HBddjcgAScREnGhrH/ukA4aMf60vHRMjhZBZDRW3OTb7erKBqM9cOd9IVIZ2Y525D
4DsxdAMj+piEByEmw196cEF0oyVuqGIFQ2giZRe3csMJ/3TYmgPTV6kQtUVvAJsi81ngaDSnmfBb
sy+5Tpy40j3FTGUSTQEtFQseQagKZkqDbE69WiSuAcpU6a42ToBN/gD8E8SRcIrrhZG8c4Mo+lvE
h8a2D+lJz2xr6M1C/6/nav1fP9veKK+db5jw2RUpJO/TH610FWbxwJfLROhRSPgT2NMjOjolcUlJ
q2W/vfhxl43DZb3hrk25lhE75nEOhRTs4HE49tQsFFDkoqs2m7DR02qo0ZAnU36tlKAovSyDXcWD
bbalhNlm2wLO3eUSW/P2E+QLZCsGk/JSPyraDU0OSqvqeHzry1jX4qrVT72QYoIIBwWIJZGQx1TK
BfnijXEZUDp4Z49OHz8UnPAlKnb+KVLFccyhrSYrtrHg+/7o2Z09O3lAs7vPHkAezEm54MJ2C9fr
LC2kEuCiPu4J6rMXv7BgwM4QiXaGqcpaeynuX5d6ov733pE4l4CylqWITJco2qcH2C55DUAs6Aek
7YcyGHr/LDE2VAyxy0HhXZsJQMW8U1rEg9jjuavosJdh4ZJlUxCfhxmDO6N4BTtG01qut4+EbaOJ
4QEDkVwuF0JxIPm4zyUe1fki+iTjXMNjx0DT74mgoBpAqAtv4f4fvcZG1XewAAA=
--=-=-=--

\start
Date: Thu, 24 May 2007 19:45:06 -0700 (PDT)
From: Cliff Yapp
To: Stephen Wilson
Subject: Re: Back again.

--- Stephen Wilson wrote:

> Greetings All,
> 
> I participated in this community for a while in 2004-2005.  Simply
> put, I became discouraged due to my own lack of decisiveness, and in
> part due to a lack of `direction' I sensed in the community as a
> whole.  I have followed this list virtually every day since that
> time.
> 
> I am compelled to rejoin and contribute once again.

Welcome back :-).

> I realize that the goal of a Lisp translation runs contrary to many
> opinions on this list.  My hope is that having more Boot code
> documented will be seen as beneficial.  As for the Lisp rewrite, I
> would love to hear from anyone who shares an interest in this
> direction.

I also share that interest, although not the needed expertise (as yet,
anyway - that's what learning is all about :-)

I have two concentrations at this stage that look achievable - one is
to provide the primary web functionality in Lisp (this one is fairly
close to working, and can handle at least basic files) and teach the
Lisp asdf system to load pamphlet files directly using the lisp based
web package.

Once those components are in working order, I hope we can begin to
provide logical asdf packages of components of Axiom, and load them
like normal lisp libraries.

At the moment, I'm focusing on asdf.lisp itself - converting it into a
pamphlet file looks like the best way to understand it well enough to
map pamphlet ideas to asdf ideas.

I know less about the mechanics of converting boot to lisp and what
good ideas would be, although I would be curious about using existing
work in Lisp to make life easier.  Making linedit work on the targeted
Lisp platforms might let us avoid the need for clef, for example.

The SPAD compiler itself I would like to see at least separated out,
although I suspect any substantial improvements to it would be a major
task.  I am very much interested in Gaby's work on the definition of
the SPAD language and what can be done using that as a foundation. 
Perhaps work like META http://www.cliki.net/meta could be used to
advantage, although I don't know enough about this type of programming
to properly evaluate it.

Anyway, this is a direction I at least find interesting.

\start
Date: 24 May 2007 21:52:30 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Back again.

Cliff Yapp writes:

[...]

| task.  I am very much interested in Gaby's work on the definition of
| the SPAD language and what can be done using that as a foundation. 

The grammar for SPAD based on the new parser is relatively
straightforward to extracr -- see src/interp/cparse.boot.
The semantics is entangled with the many post-parser transformers, but
is not too hard to get out.

\start
Date: Thu, 24 May 2007 22:55:06 -0400
From: Bill Page
To: Stephen Wilson
Subject: Re: Back again.

Quoting Stephen Wilson:

>
> I am compelled to rejoin and contribute once again. 
>

That's great, Stephen! Your continued input will no doubt be invaluable. 

> ... 
> My intention is to begin converting Axiom's compiler and interpreter
> into Common Lisp. 
> ... 
> I realize that the goal of a Lisp translation runs contrary to many
> opinions on this list. 

I although I have argued for increasing rather than decreasing the use
of intermediate bootstrap languages in the Axiom build system, I am
very glad that you are motivated to apply your convictions to Axiom. 
The Axiom project needs more developers - even if - or perhaps
especially if - they are working is somewhat different directions. 

> My hope is that having more Boot code documented will be seen
> as beneficial. 

Most certainly! :-)

> As for the Lisp rewrite, I would love to hear from anyone who shares
> an interest in this direction. 
>

I do share an interest in the results of this exercise although of
course I cannot offer any direct help. 

\start
Date: 24 May 2007 22:56:36 -0400
From: Stephen Wilson
To: Alfredo Portes
Subject: Re: Back again.

Alfredo Portes writes:
> Hi Stephen,
> 
> Even when I am not a contributor to Axiom and fairly new in the list,
> I would like to say welcome back. 

Thanks!

> I also feel that the list is more active now than in the past
> year. There is a greater sense of direction.  (Thanks to everyone
> that is making this possible. You know who you are :-)).  I hope
> that this is the beginning of the creation of a much stronger
> community.

Indeed.  I have been extremely impressed with the work produced over
the past year.  I have high hopes for the project.  I too would like
to thank everyone for their dedication and work.

\start
Date: Thu, 24 May 2007 19:57:11 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey, Alasdair McAndrew, Jay Belanger
Subject: Re: [ANN] yet a better version of the axiom mode for emacs.

--- Martin Rubey wrote:

> Dear all,
> 
> below the result of today.  Although I really would like to stop now,
> there is some rather important things missing.  If somebody (Jay?)
> could help with the first item on the todo list, that would be
> wonderful.  Progress is as follows:

Very nice work Martin!  Thank you for pushing this mode forward :-). 
If I get a chance I will try it on Windows this weekend.

Unfortunately you appear to have stepped beyond my rudimentary
understanding of Elisp, so I'm not sure how much use I can be.  My only
suggestion is that the depths of comint mode might offer some help for
interaction with terminal programs - I was never able to grasp that
aspect of it properly.  (I suppose the functions with every single line
commented indicate that - those should probably be trimmed down...)

\start
Date: Thu, 24 May 2007 20:18:30 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Which source distributions should we list?

Looking at the AxiomSources pages, a couple of questions come to mind.

1.  What are the "approved" sources for AxiomGold?  I am assuming CVS
on Savannah and Sourceforge?

2.  Is the most current tarball still from 2005?

3.  Silver is moving from arch to Git (the primary motivation for
updating the sources page).  Is Google still a valid mirror of
AxiomSilver via the git-svn link?  Which svn mirrors (if any) can be
assumed to be in sync with what I assume is the master branch of git
silver?

4.  About the testing branches listed for GNU Arch - are those now
replaced with branches in Git Silver?  Are they still active at all? 
Is there any work in them that has not been folded in to other
branches?

5.  The subversion branches I assume are all still active, or should
the daly branch be removed now that Git is coming online?  Also, is
hersen-algebra-improvements still in use?  Does it contain any work not
present in other branches?

6.  Darcs and Mercurial obviously will stay.  (I hadn't noticed the
Dspace work - is that an actual Dspace mirror or code for working with
it?)

I know "BeBold" is the policy but on a page that reflects project wide
direction information like this I want to be sure I have the state of
things correct before I (say) delete all the old arch references. 
Adding the Git references and instructions is obvious, but I also feel
this page should only point the readers to the active branches, perhaps
with links in an Archive section to no-longer-actively-developed
branches that have improvements not folded back in.  Because this is a
"representative" page of the Axiom project, I would like to get
feedback on what is needed.

\start
Date: 24 May 2007 23:27:19 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: Re: Back again.

Cliff Yapp writes:

> --- Stephen Wilson wrote:
> 
> > Greetings All,
> > 
> > I participated in this community for a while in 2004-2005.  Simply
> > put, I became discouraged due to my own lack of decisiveness, and in
> > part due to a lack of `direction' I sensed in the community as a
> > whole.  I have followed this list virtually every day since that
> > time.
> > 
> > I am compelled to rejoin and contribute once again.
> 
> Welcome back :-).

Thank-you, Cliff.

> > I realize that the goal of a Lisp translation runs contrary to many
> > opinions on this list.  My hope is that having more Boot code
> > documented will be seen as beneficial.  As for the Lisp rewrite, I
> > would love to hear from anyone who shares an interest in this
> > direction.
> 
> I also share that interest, although not the needed expertise (as yet,
> anyway - that's what learning is all about :-)
> 
> I have two concentrations at this stage that look achievable - one is
> to provide the primary web functionality in Lisp (this one is fairly
> close to working, and can handle at least basic files) and teach the
> Lisp asdf system to load pamphlet files directly using the lisp based
> web package.

I have looked at your work and must say I am impressed and
optimistic.  The potential benefits are enormous.

> Once those components are in working order, I hope we can begin to
> provide logical asdf packages of components of Axiom, and load them
> like normal lisp libraries.

I see ASDF as the right target.  The problem is getting the system
into a state which is `Lispy' enough for the full benefits to be
realized.

> At the moment, I'm focusing on asdf.lisp itself - converting it into a
> pamphlet file looks like the best way to understand it well enough to
> map pamphlet ideas to asdf ideas.

Oh yes.  Absolutely.  A large portion of my time will be devoted to
documenting the existing Axiom system for the sole purpose of
improving my understanding.

> I know less about the mechanics of converting boot to lisp and what
> good ideas would be, although I would be curious about using existing
> work in Lisp to make life easier. 

Existing libraries are always an option.  Unfortunately (or
fortunately, depending on your perspective :), there is a lot of code
we must write.  My main focus is on the core of Axiom.  My hope is to
engineer a system which is extensible, and thus amenable to the
incorporation of well established libraries.

> Making linedit work on the targeted Lisp platforms might let us
> avoid the need for clef, for example.

Yep. The new axiom.el might fulfill that role too for a large number
of users.

> The SPAD compiler itself I would like to see at least separated out,
> although I suspect any substantial improvements to it would be a major
> task. 

Yes, it is a major task.  But not impossible.  As I mentioned before,
I see a two stage process. A simple Boot->Lisp which yields as
byproduct documentation for both representations.  Then a Lisp->Lisp
which is much more involved and requires a global view of the system
as it stands (aquired via step 1), and a global view of where we would
like it to go.  For example, it would be in this latter stage that the
mechanics be implemented to support Aldor-style dependent types.

> I am very much interested in Gaby's work on the definition of the
> SPAD language and what can be done using that as a foundation.

I am too.  I have spent a lot of time privately thinking about SPAD
and Aldor semantics over the past year or two and do not doubt that it
is a hard problem.  Gaby's results will no doubt be of great value.

> Perhaps work like META http://www.cliki.net/meta could be used to
> advantage, although I don't know enough about this type of
> programming to properly evaluate it.

I am partial to hand written parsers myself, but am not in a position
to evaluate META.

> Anyway, this is a direction I at least find interesting.

I am glad to hear this!

\start
Date: Thu, 24 May 2007 22:30:40 -0500
From: Jay Belanger
To: Martin Rubey
Subject: Re: [ANN] yet a better version of the axiom mode for emacs.

Let me echo the praise you're getting; this is very nice.

>   In fact, all of this waiting-for-output stuff should be rewritten, but I
>   don't understand it enough.

It's a pain; is it causing problems?  I think it should be kept in,
but for the time being (until someone needs it for EAxiom or
something) it could be made to do nothing by commenting out
`axiom-wait-for-output' and replace it by a function with the same
name which does nothing.  Or even make it configurable:
make a variable `axiom-output-wait' or something, and 
  (defun axiom-wait-for-output ()
     (if axiom-output-wait
          previous definition
       nil))


> * For me, the following is *very* severe. Try:
>
>     for i in 1..10 repeat ([j for j in 1..2000]; output "hi")
>
>   in a usual shell buffer and in axiom mode.  Very unfortunately, the axiom
>   mode currently accumulates all output and then displays it at once.  Since I
>   use such constructs often to be able to check how far a computation got
>   already, it makes the mode unusable for me.

This has nothing to do with waiting for output, or even Emacs.  Axiom
will do that when called with the -noclef option; I have no idea why.

\start
Date: 24 May 2007 23:36:26 -0400
From: Stephen Wilson
To: Bill Page
Subject: Re: Back again.

Bill Page writes:
> Quoting Stephen Wilson:
> 
> >
> > I am compelled to rejoin and contribute once again.
> 
> That's great, Stephen! Your continued input will no doubt be
> invaluable.

Invaluable? We will see:)  I did enjoy are past discussions and look
forward to more.  Thanks Bill.

> > ... My intention is to begin converting Axiom's compiler and
> > interpreter
> > into Common Lisp. ... I realize that the goal of a Lisp translation
> > runs contrary to many
> > opinions on this list.
> 
> I although I have argued for increasing rather than decreasing the use
> of intermediate bootstrap languages in the Axiom build system, I am
> very glad that you are motivated to apply your convictions to
> Axiom. 

Yep, I understand you sit on the other side of the fence, but thats
OK.  Im not out to convert anyone.

> The Axiom project needs more developers - even if - or perhaps
> especially if - they are working is somewhat different directions.

Absolutely.  

> > My hope is that having more Boot code documented will be seen
> > as beneficial.
> 
> Most certainly! :-)
> 
> > As for the Lisp rewrite, I would love to hear from anyone who shares
> > an interest in this direction.
> 
> I do share an interest in the results of this exercise although of
> course I cannot offer any direct help. Sincerely,
> Bill Page.

\start
Date: Thu, 24 May 2007 23:40:36 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Which source distributions should we list?

Quoting Cliff Yapp:

> ... 
> 5.  The subversion branches I assume are all still active, or should
> the daly branch be removed now that Git is coming online?

Tim is currently mirror his new git-based "Axiom Silver" in the "daly"
SVN branch on SourceForge for those people not motivated to
access the git repository. 

> Also, is hersen-algebra-improvements still in use?  Does it contain
> any work not present in other branches?

As far as I know Anthony Hersen is not longer working on the the
algebra code improvement project. Martin, do you know for sure?

>
> 6.  Darcs and Mercurial obviously will stay.  (I hadn't noticed the
> Dspace work - is that an actual Dspace mirror or code for working
> with it?)

The DSpace repository is a direct mirror of the DSpace project
CVS repository up to the time that they moved to SVN at about
release 1.4. Currently I did not check-in any modifications with
which I have been experimenting. Originally I had in mind that
it might be of some use to create a document repository for Axiom
reference material. But so far I think the 'references' section that
we have on the Axiom portal (plone) site is sufficient - especially
when taken together with the bibliography. I am also working on
DSpace in another project completely unrelated to Axiom, so
I do have some experience with it. 

>
> I know "BeBold" is the policy but on a page that reflects project
> wide direction information like this I want to be sure I have the
> state of things correct before I (say) delete all the old arch
> references. 

Go ahead, be bold. It necessary we can always revert or bring
forward old material from the history maintained in the Zope
database (currently the revision history is maintained for at
least one month). 

> Adding the Git references and instructions is obvious, but I also
> feel this page should only point the readers to the active branches,
> perhaps with links in an Archive section to no-longer-actively-
> developed branches that have improvements not folded back in. 

Feel free to create a "Development Archive" page of you wish. 

>  Because this is a "representative" page of the Axiom project,
> I would like to get feedback on what is needed. 
>

\start
Date: Thu, 24 May 2007 23:40:37 -0400
From: Alfredo Portes
To: Cliff Yapp
Subject: Re: Which source distributions should we list?

Hi Cliff,

I think I can answer some of these questions.

> 2.  Is the most current tarball still from 2005?

This needs to updated with a new tarball.

> 3.  Silver is moving from arch to Git (the primary motivation for
> updating the sources page).  Is Google still a valid mirror of
> AxiomSilver via the git-svn link?  Which svn mirrors (if any) can be
> assumed to be in sync with what I assume is the master branch of git
> silver?

The primary question is what is Silver???  Assuming Git == Silver now,
then trunk and silver directories in Sourceforge need to be removed and
create a new trunk with the Git version. Then wh-sandbox and
build-improvements can be merged back to the trunk in svn when necessary.
Having that, then I think we can ask Ben to recreate the repo from Sourceforge
and Bill can put the update script back. If not then it is better just
to remove
the project from google, which currently is very far behind.

I can help you with the reorganization of the page if need to. This page
also needs to be improved: http://wiki.axiom-developer.org/AxiomBinaries

\start
Date: Thu, 24 May 2007 23:45:52 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Back again.

Quoting Cliff Yapp:

> ... 
> Making linedit work on the targeted Lisp platforms might let us avoid
> the need for clef, for example. 

Since gnu readline (or it's equivalent) are available on all the likely
Axiom targets, I don't see any point to clef (or linedit). clef does
provide some command completions for Axiom, but these also
could be provided by readline. As far as I know, other than that
clef is just legacy code that can disappear. 

\start
Date: 25 May 2007 05:49:07 +0200
From: Martin Rubey
To: Jay Belanger
Subject: Re: [ANN] yet a better version of the axiom mode for emacs.

Jay Belanger writes:

> Let me echo the praise you're getting; this is very nice.
> 
> >   In fact, all of this waiting-for-output stuff should be rewritten, but I
> >   don't understand it enough.
> 
> It's a pain; is it causing problems?  

Mainly in so far as I do not understand really what it is doing.  And the
initialization code is a mess.  For example, why are there two functions hooked
to comint-output-filter-functions, namely:

  axiom-output-filter (str)
  make-output (str)

(The latter had a different name in an earlier version.)

Why is (sit-for 0 axiom-after-output-wait) necessary?

Is (setq comint-prompt-regexp axiom-prompt) still useful?  I am now marking
prompts as 'field, since (beginning-of-line) didn't work otherwise.  (sometimes
it jumped over the prompt, sometimes it didn't).

> I think it should be kept in, but for the time being (until someone needs it
> for EAxiom or something) it could be made to do nothing by commenting out
> `axiom-wait-for-output' and replace it by a function with the same name which
> does nothing.

Well, that doesn't work either, see below.

> Or even make it configurable:
> make a variable `axiom-output-wait' or something, and 
>   (defun axiom-wait-for-output ()
>      (if axiom-output-wait
>           previous definition
>        nil))
> 
> 
> > * For me, the following is *very* severe. Try:
> >
> >     for i in 1..10 repeat ([j for j in 1..2000]; output "hi")
> >
> >   in a usual shell buffer and in axiom mode.  Very unfortunately, the axiom
> >   mode currently accumulates all output and then displays it at once.  Since I
> >   use such constructs often to be able to check how far a computation got
> >   already, it makes the mode unusable for me.
> 
> This has nothing to do with waiting for output, or even Emacs.  Axiom
> will do that when called with the -noclef option; I have no idea why.

Well, at least in wh-sandbox, this is *not* the case.  And if I remove all
these accept-process-output stuff, it works, too.  However, I have then some
problems deciding when to decide that a prompt arrived, since it seems that
emacs continues execution of my elisp code, even if output is still arriving.

\start
Date: Fri, 25 May 2007 00:00:31 -0400
From: Bill Page
To: Alfredo Portes
Subject: Re: Which source distributions should we list?

Quoting Alfredo Portes:

> ... 
> The primary question is what is Silver???  Assuming Git == Silver
> now, then trunk and silver directories in Sourceforge need to be
> removed and create a new trunk with the Git version. 

Yes, certainly the directory named "silver" on SourceForge can
be deleted. It is now obsolete following Tim's move to git. 

> Then wh-sandbox and build-improvements can be merged back
> to the trunk in svn when necessary. 

I fear that since build-improvements is cloned from the current
trunk and wh-sandbox is cloned from build-improvements, there
might be some considerable loss in "mergibility" if we were to
just "pull the rug out from under them" so as to speak and
wholesale replace trunk with the contents of the current git
repository. Perhaps those more  familiar with the details of
SVN could comment?

Frankly I am not sure at all how we should manage the
integration of the SVN-based repositories with Tim's new
git version of Silver. I was especially disappointed to see
that in the creation of the new git repository Tim has
removed all of the prior revision history. :-(

Anyway as I understand it, right now Tim is manually updating
both the git repository on axiom-developer and the "daly" branch
on SVN in parallel. That does not sound like a particularly
enlightened approach to me. :-( There's got to be a better way,
right?

> Having that, then I think we can ask Ben to recreate the repo
> from Sourceforge and Bill can put the update script back. If not
> then it is better just to remove the project from google, which
> currently is very far behind. 

You are right that there is some urgency to do this. Unfortunately
I do not know how easy it actually is to really delete things from
the SVN repository at SourceForge. Normally to do so I think
one would require 'svnadmin' access to the site - which I do not
think is available to us except perhaps by special request. 

It is the same situation at Google Code, except made more
severe by the size restrictions place on the repositories there. 

\start
Date: Thu, 24 May 2007 21:20:13 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Alfredo Portes
Subject: Re: Which source distributions should we list?

--- Bill Page wrote:

> Frankly I am not sure at all how we should manage the
> integration of the SVN-based repositories with Tim's new
> git version of Silver. I was especially disappointed to see
> that in the creation of the new git repository Tim has
> removed all of the prior revision history. :-(

If I'm not mistaken, Tim has already suggested the only workable
approach - isolate smaller changes which can be incrementally merged
into the master branch.  This makes for understandable changes which
allow incremental testing for breakage (and thus making it easier to
locate what broke).  IIRC this is a direct result of Torvald's own
philosophy of kernel development.  It makes some sense, but does imply
overhead (in the form of breaking a large change down into small parts)
when big changes are being considered.  I can think of a couple cases
in the past where large changes had a hard time getting merged.

At the current state of divergence, I don't think it's going to matter
if the old silver is preserved - the deltas are going to be large and
will need to be sorted out by hand anyway.
 
> Anyway as I understand it, right now Tim is manually updating
> both the git repository on axiom-developer and the "daly" branch
> on SVN in parallel. That does not sound like a particularly
> enlightened approach to me. :-( There's got to be a better way,
> right?

I thought git-svn worked with the new url?

The Git philosophy, as I understand it, is people work on a main trunk,
branching off to test individual ideas when are then folded back into
the master branch as they reach a viable point.  What we have, by
contrast, is a lot of large divergences by many people.  I don't think
this is necessarily the end of the world, although I do understand
Tim's frustration with it.  When there are major differences of
opinion, one tends to get major deltas.  But I would much rather see
this work go forward for later resolution than have it not happen at
all.

Perhaps Git could be used as follows - those who are working in similar
directions (Gaby and Waldek with wh-sandbox and build-improvements, for
example) could pick a common master and branch off of that.  Their
master will look rather different from silver, but they can at least
share code between those two trees and fold back into the common master
when one or the other solves a particular problem.  Once the main
points of divergence are resolved between the autoconf system and
silver by the silver maintainer (Tim) the silver master will look more
like the build-improvements and wh-sandbox work.  Thus, the main master
between those two trees can collapse gradually back into silver, and
work can then proceed from that master.

Those are interesting scenarios, but the most important thing is the
work gets done.  We can wade through diffs by hand if we need to - the
key is getting the problems solved.

\start
Date: Thu, 24 May 2007 21:22:47 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Back again.

--- Bill Page wrote:

> Quoting Cliff Yapp:
> 
> > ... 
> > Making linedit work on the targeted Lisp platforms might let us
> > avoid the need for clef, for example. 
> 
> Since gnu readline (or it's equivalent) are available on all the
> likely Axiom targets, I don't see any point to clef (or linedit).

For GCL and Clisp, I believe that is true.  For sbcl and cmucl, I don't
think there is readline support available - I use rlwrap for those if
I'm on the command line.

Linedit would be part of the "everything we need in Lisp" approach :-).
 For GCL with readline I agree it is pretty much redundant.

\start
Date: Fri, 25 May 2007 00:23:07 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: Which source distributions should we list?

Hi Bill,

> Anyway as I understand it, right now Tim is manually updating
> both the git repository on axiom-developer and the "daly" branch
> on SVN in parallel. That does not sound like a particularly
> enlightened approach to me. :-( There's got to be a better way,
> right?

Maybe daly can be trunk now, and Tim update to trunk. Same for
the other branches. If some history is lost, well I think is the price
to pay. But I least a simple scheme that works for people contributing
specially now that it looks like there is more contributors than version
control systems :-). But like you said, there must be a better way.

\start
Date: Thu, 24 May 2007 23:32:43 -0500
From: Jay Belanger
To: Martin Rubey
Subject: Re: [ANN] yet a better version of the axiom mode for emacs.

Martin Rubey writes:
...
> And the initialization code is a mess.  For example, why are there
> two functions hooked to comint-output-filter-functions, namely:
>
>   axiom-output-filter (str)
>   make-output (str)

They were probably added at different times; I don't think there's any
reason why they can't be combined into one function.

> Why is (sit-for 0 axiom-after-output-wait) necessary?

That's an artifact from maxima.el, where waiting for the output was
causing problems.  There were some cases when the output was being
yanked into a different buffer but the output was truncated, and this
was a tweak to wait a bit longer for output if necessary
(`axiom-after-output-wait' was customizable and could be increased). 

> Is (setq comint-prompt-regexp axiom-prompt) still useful?  I am now marking
> prompts as 'field,

In that case, `(setq comint-prompt-regexp axiom-prompt)' shouldn't be
necessary. 

>> > * For me, the following is *very* severe. Try:
>> >
>> >     for i in 1..10 repeat ([j for j in 1..2000]; output "hi")
>> >
>> >   in a usual shell buffer and in axiom mode.  Very unfortunately, the axiom
>> >   mode currently accumulates all output and then displays it at once.  Since I
>> >   use such constructs often to be able to check how far a computation got
>> >   already, it makes the mode unusable for me.
>>
>> This has nothing to do with waiting for output, or even Emacs.  Axiom
>> will do that when called with the -noclef option; I have no idea why.
>
> Well, at least in wh-sandbox, this is *not* the case.

I'm surprised.
When I changed the value of `axiom-args' from "-noclef" to "", axiom
mode no longer accumulated all output and displayed it at once, and
when I started Axiom in an xterm with "axiom -noclef", it then did
accumulate all output and displayed it at once.  I don't have
wh-sandbox, though.

> And if I remove all these accept-process-output stuff, it works,
> too.

What works?  Axiom mode will display the output incrementally, rather
than all at once?

> However, I have then some problems deciding when to decide that a
> prompt arrived, since it seems that emacs continues execution of my
> elisp code, even if output is still arriving.

What code is being run while Axiom output it arriving?

\start
Date: Fri, 25 May 2007 08:33:42 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: axiom mode for emacs.

> By the way, any xemacs experts out there?  I tried to port it today, but failed
> miserably.  I was able to fix the problem reported by Ralf concerning ^M as
> below, but could not, for example, find a replacement for
> comint-set-process-mark.

For emacs, I found /usr/share/emacs/21.4/lisp/comint.el . Since you use 
ubuntu (right?) it should be in the same place. Maybe you just 
reimplement that function. I have no idea why the emacs and xemacs 
people cannot agree to get closer to each other.

Ralf

(defun comint-set-process-mark ()
   "Set the process mark at point."
   (interactive)
   (let ((proc (or (get-buffer-process (current-buffer))
		  (error "Current buffer has no process"))))
     (set-marker (process-mark proc) (point))
     (message "Process mark set")))

\start
Date: Fri, 25 May 2007 08:56:36 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Which source distributions should we list?

>> Also, is hersen-algebra-improvements still in use?  Does it contain
>> any work not present in other branches?
> 
> As far as I know Anthony Hersen is not longer working on the the
> algebra code improvement project. Martin, do you know for sure?

Antoine, could you say something about the state of your branch?

\start
Date: Fri, 25 May 2007 13:24:48 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: Boot, Virtual Machine

Gabriel Dos Reis wrote:
> On Wed, 23 May 2007, Waldek Hebisch wrote:
> 
> | There is a few snippets which were really converted to work around
> | limitations of Boot.  In fact I yesterday commited one such
> | snippet:  I needed double precision numeric constants, but both
> | old Boot and Shoe were mangling them.
> 
> Please, be more specific. Show the codes so that we know how to deal 
> with them.  I've have lots of emails coming in (over thousand) per day
> I don't necessary go into great depth into every program generated emails.
> 

That is a Lisp function I added.  In comment you may find Boot version.
My problem is that old boot read '1.0d0' as '1.0' followed by
identifier 'd0'.  Shoe is doing slightly different thing: it reads
the number as is (maybe using Lisp read) but then reads extra 
identifier 'd0'.

BTW: The Lisp formatting may shock Lispers, but my objective was
to have line-by-line correspondence between Boot and Lisp code
and formating follows Boot version.


(defun |axiom_log_10| (u)
    ;;; k := INTEGER_-LENGTH(u)
    (let
    ((k (INTEGER-LENGTH u)))
    ;;; k > MOST_-POSITIVE_-DOUBLE_-FLOAT =>
    ;;;    SAY("Number too big")
    ;;;    THROW('outputFailure,'outputFailure)
    (if (> k MOST-POSITIVE-DOUBLE-FLOAT)
        (progn
        (SAY '|Number too big|)
        (THROW '|outputFailure| '|outputFailure|)))

    (let ((l10 0.0d0))
    (declare (double-float l10))

    ;;; if (k < 61) then
    (if (< k 61)
    ;;;    l10 := LOG10 (FLOAT (u, 1.0d0))
       (setf l10 (LOG10 (FLOAT u 1.0d0)))
    ;;; else
    ;;;    su := ASH(u, - (k - 54))
    ;;;    l10 := LOG10 (FLOAT (su, 1.0d0))
    ;;;          -- we want full double precision here because the second
    ;;;          -- term may be much bigger than the first one, so we use
    ;;;          -- very precise estimate of log(2)/log(10)
    ;;;          + 0.301029995663981195213738894724d0 * FLOAT ((k - 54), 1.0d0)
       (progn
       (let ((su (ASH u (- (- k 54)))))
       (setf l10 (+ (LOG10 (FLOAT su 1.0d0))
                    (* 0.301029995663981195213738894724d0
                       (FLOAT (- k 54) 1.0d0)))))))
    ;;; -- Add bias to l10 to have only one-sided error
    ;;; l10i := FLOOR(l10 + 1.0d-9)
    (let ((l10i (FLOOR (+ l10 1.0d-9))))
    ;;; l10i < 10000 =>
    (if (< l10i 10000)
          (progn
    ;;;   -- Check if sure
    ;;;   l10 - 1.0d-9 > l10i => l10i
          (if (> (- l10 1.0d-9) l10i)
              (return-from |axiom_log_10| l10i))
    ;;;   u < EXPT(10, l10i) => l10i - 1
          (if (< u (EXPT 10 l10i))
              (return-from |axiom_log_10| (- l10i 1)))
    ;;;   l10i
          (return-from |axiom_log_10| l10i)))
    ;;; -- width is very large, it would be expensive to compute it
    ;;; -- accuratly, so we just make sure that we overestimate.
    ;;; -- l10 should have about 14 digits of accuracy
    ;;; FLOOR(l10 * (1.0d0 + 1.0d-12))
    (FLOOR (* l10 (+ 1.0d0 1.0d-12)))))))


\start
Date: Fri, 25 May 2007 07:31:14 -0400
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: clisp and sbcl

Confirmed - builds on sbcl and clisp.  Wow!  Thanks Waldek!

I don't know if it's important, but I am getting a lisp readout when
using the integration package:

(2) -> integrate(sin(x),x)
[loading messages]
/home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/target/i686-pc-
linux/algebra/COMPLEX.fasl
      for domain Complex


; in: LAMBDA NIL
;     (VMLISP:QCAR BOOT::|#1|)
; --> CAR
; ==>
;   (THE CONS BOOT::|#1|)
;
; caught WARNING:
;   undefined variable: |#1|

;
; caught WARNING:
;   This variable is undefined:
;     |#1|
;
; compilation unit finished
;   caught 2 WARNING conditions
   (2)  - cos(x)

; in: LAMBDA NIL
;     (VMLISP:QCAR BOOT::|#1|)
; --> CAR
; ==>
;   (THE CONS BOOT::|#1|)
;
; caught WARNING:
;   undefined variable: |#1|

;
; caught WARNING:
;   This variable is undefined:
;     |#1|
;
; compilation unit finished
;   caught 2 WARNING conditions
                                          Type: Union(Expression
Integer,...)
(3) ->

\start
Date: 25 May 2007 13:38:07 +0200
From: Martin Rubey
To: axiom-dev <list>
Subject: Re: [Axiom-mail] comparison operators and %pi

Dear Alasdair, Francois,

(didn't get through, did it?)

Alasdair McAndrew writes:

(I move this to developer)

> I also notice that pi is defined as an operator, so that pi() returns the
> result %pi.  I wonder how hard it would be to include useful constants in
> Axiom, and to be able to enter (for example)
> 
> solve(integrate(1/x,x=1..t)=1,t)
> 
> and obtain the answer %e.

(6) -> solve(integrate(1/x,x=1..t, "noPole")::EXPR INT = 1, t)

               +---+     +---+
               |  2      |  2
   (6)  [t= - \|%e  ,t= \|%e  ]
                                       Type: List Equation Expression Integer

Yes, we should teach Axiom that %e is positive.  In fact, I don't think that's
too difficult in a hackish way.  In expr.spad, you find

  CF  ==> CombinatorialFunction(R, %)

      x:% ** y:%                == x **$CF y

In our case, x is %e^2 and y is 1/2.  The case of integer y is dealt with
seperately in expr.spad, although maybe this should be changed.  (Note that
algorithms in CF need to hold in greater generality, namely for all
"FunctionSpace"s.  But at the moment I do not see whether the special
definitions can be moved to CF or not, see below for them.

In CF (combfunc.spad) you find

    x ** y               == 
      -- Do some basic simplifications
      is?(x,POWER) =>
        args : List F := argument first kernels x
        not(#args = 2) => error "Too many arguments to **"
        number?(first args) and number?(y) =>
          oppow [first(args)**y, second args]
        oppow [first args, (second args)* y]
      -- Generic case
      exp : Union(Record(val:F,exponent:Z),"failed") := isPower x
      exp case Record(val:F,exponent:Z) =>
        expr := exp::Record(val:F,exponent:Z)
        oppow [expr.val, (expr.exponent)*y]
      oppow [x, y]

Of course, you cannot simply check whether x is positive, since the ordering is
not the mathematical one.  So we can only deal with special cases for the
moment (unless we get provisos).  I think there is only one special case that
will somewhat work: check whether x is numerical, convert it to float and check
whether this float is positive.

Note that x**y might be of the form sqrt(-1)^2.  Thus, even if x is a square,
it is not necessarily positive.

Francois, you have already some expertise.  Maybe you can help here.  Although,
in reality, we need a redesign.

Martin


Here are the special cases from EXPR.  

      algkernels l     == select_!(has?(operator #1, ALGOP), l)

      simplifyPower(x:%,n:Integer):% ==
        k : List K := kernels x
        is?(x,POWER) =>
          -- Look for a power of a number in case we can do a simplification
          args : List % := argument first k
          not(#args = 2) => error "Too many arguments to **"
          number?(args.1) =>
             reduc((args.1) **$Rep n, algkernels kernels (args.1))**(args.2)
          (first args)**(n*second(args))
        reduc(x **$Rep n, algkernels k)

Hm, no idea what reduc does.

      reduc(x, l) ==
        for k in l repeat
          p := minPoly k
          x := evl(numer x, k, p) /$Rep evl(denom x, k, p)
        x

      evl0(p, k) ==
        numer univariate(p::Fraction(MP),
                     k)$PolynomialCategoryQuotientFunctions(IndexedExponents K,
                                                            K,R,MP,Fraction MP)

      -- uses some operations from Rep instead of % in order not to
      -- reduce recursively during those operations.
      evl(p, k, m) ==
        degree(p, k) < degree m => p::Fraction(MP)
        (((evl0(p, k) pretend SparseUnivariatePolynomial($)) rem m)
           pretend SparseUnivariatePolynomial Fraction MP)
      -- (k::MP::Fraction(MP))

In any case, we cannot simply copy-paste it to CF, since we are using special
features from EXPR here...  Some documentation would be good, though.

      x:% ** n:NonNegativeInteger ==
        n = 0 => 1$%
        n = 1 => x
        simplifyPower(numerator x,n pretend Integer) /
        simplifyPower(denominator x,n pretend Integer)

      x:% ** n:Integer ==
        n = 0 => 1$%
        n = 1 => x
        n = -1 => 1/x
        simplifyPower(numerator x,n) / simplifyPower(denominator x,n)

      x:% ** n:PositiveInteger == 
        n = 1 => x
        simplifyPower(numerator x,n pretend Integer) /
        simplifyPower(denominator x,n pretend Integer)


\start
Date: 25 May 2007 08:01:18 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Which source distributions should we list?

Bill Page writes:

[...]

| I fear that since build-improvements is cloned from the current
| trunk and wh-sandbox is cloned from build-improvements, there
| might be some considerable loss in "mergibility" if we were to
| just "pull the rug out from under them" so as to speak and
| wholesale replace trunk with the contents of the current git
| repository. Perhaps those more  familiar with the details of
| SVN could comment?

Tim does not seem to trust automation, so he wants to apply
patches by hand himself -- leading him to forget to apply changes, but
that is OK I guess. 

As for the active branches, the current chaos implies that people
working on the branches have to come up with manual creation of
patches (instead of getting them automated, or at least partially).
That is what will happen, so I don't see much option.  The old Gold,
Silver branches can be safely deleted.  There does not seem to be much
history in them to preserve -- except how we got into this mess.

Axiom.build-improvements and Axiom.wh-sandbox will deal with the
manufaturing of necessary patches as they can.

That will leave us with an interesting structure of the SVN repository
at SF, which is a good summary of the current state of the Axiom
project.  I hope archeologists and historians in open source will
learn something. 

| Frankly I am not sure at all how we should manage the
| integration of the SVN-based repositories with Tim's new
| git version of Silver. I was especially disappointed to see
| that in the creation of the new git repository Tim has
| removed all of the prior revision history. :-(

I think Tim has been doing regular commit to his branch.  So, I don't
think we should mess with it. 

For Google mirror, I don't know whether we want to preserve the
history there as opposed to regularly putting a snapshot there.
This is not a serious suggestion.

\start
Date: Fri, 25 May 2007 08:09:48 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: Boot, Virtual Machine

On Fri, 25 May 2007, Waldek Hebisch wrote:

| Gabriel Dos Reis wrote:
| > On Wed, 23 May 2007, Waldek Hebisch wrote:
| > 
| > | There is a few snippets which were really converted to work around
| > | limitations of Boot.  In fact I yesterday commited one such
| > | snippet:  I needed double precision numeric constants, but both
| > | old Boot and Shoe were mangling them.
| > 
| > Please, be more specific. Show the codes so that we know how to deal 
| > with them.  I've have lots of emails coming in (over thousand) per day
| > I don't necessary go into great depth into every program generated emails.
| > 
| 
| That is a Lisp function I added.  In comment you may find Boot version.
| My problem is that old boot read '1.0d0' as '1.0' followed by
| identifier 'd0'.

Thanks for the example.  A few remarks:

  (1) the float format in new Boot is double-float, so you don't need to
      say anything special to read double-float
  (2) new Boot uses the Lisp read to read constants, so reading the 
      Lisp formatted float should be straightforward to get in.  I'll look
      into that.
      
  (3) you can declare variable typs in Boot by specifying their types:
         var : type 

\start
Date: Fri, 25 May 2007 15:44:11 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Which source distributions should we list?

> Axiom.build-improvements and Axiom.wh-sandbox will deal with the
> manufaturing of necessary patches as they can.

What do we have on Sourceforge?

trunk this was some snapshot of the
build-improvements   branched from trunk
wh-sandbox           branched from build-improvements (r263)
gdr-sandbox          branched from build-improvements (r335)
daly                 branched from trunk (r6)

woodpecker:~>svn log -v https://axiom.svn.sourceforge.net/svnroot/axiom -r6
------------------------------------------------------------------------
r6 | (no author) | 2005-01-05 00:59:09 +0100 (Wed, 05 Jan 2005) | 1 line
Changed paths:
    A /branches/daly (from /trunk:5)
    D /branches/daly/CVSROOT

This commit was manufactured by cvs2svn to create branch 'daly'.
------------------------------------------------------------------------

So to automate things, it would be best if Tim gets his branch in sync 
with trunk and trunk will become the main line.

The first (automated) merge of build-improvement back to trunk will 
probably be terribly hard, because Tim did not track which (svn) 
revisions he took from Gaby's and Waldek's branch to apply them to the 
daly branch.

Since silver is just a copy of the tla archive axiom--main--1--patch-50, 
I think it can be completely removed. Tim is now trying to make daly to 
the silver branch.

I still don't see a good structure. And I actually will not open up any 
new branch until I finally know what the mainline is and how the 
development goes.

I somehow don't like to create and sent patches. Why do we have version 
control systems then? Even if SVN is controversial, what is so hard to 
let the trunk as sourceforge play the role of the Axiom mainline?
(Gaby and Waldek are currently doing almost all of the commits.)

Yes, it's the old non-distributed development. But the Axiom team has no 
Linus. In fact, kernel development centers around Linus, right? So there 
is no very big difference at the moment for the 3 or 4 active Axiom 
developers (who actually commit) to work centralized or distributed.

We can change that later if we have thousands of contributors. But until 
then we should do more to attract developers.

\start
Date: Fri, 25 May 2007 22:41:54 +0700 (NOVST)
From: Andrey G. Grozin
To: Bill Page
Subject: Re: Back again.

On Thu, 24 May 2007, Bill Page wrote:
> Since gnu readline (or it's equivalent) are available on all the likely
> Axiom targets, I don't see any point to clef (or linedit). clef does
> provide some command completions for Axiom, but these also
> could be provided by readline. As far as I know, other than that
> clef is just legacy code that can disappear. 
I agree that it would be much better to replace clef by the de-facto 
standard, readline. But... readline is GPL (not LGPL, and on purpose). 
This will make axiom+readline to be distributable only under GPL. 
(Absolutely OK for me, but some people may not like this).

If there will be any responces, please, switch to axiom-legal.

\start
Date: 25 May 2007 21:00:36 +0200
From: Francois Maltey
To: Martin Rubey
Subject: Re: comparison operators and %pi

Hello everybody !

> (6) -> solve(integrate(1/x,x=1..t, "noPole")::EXPR INT = 1, t)
> 
>                +---+     +---+
>                |  2      |  2
>    (6)  [t= - \|%e  ,t= \|%e  ]
>                                        Type: List Equation Expression Integer
> 
> Yes, we should teach Axiom that %e is positive.  
> In fact, I don't think that's too difficult in a hackish way.

When I played with expr.spad for theses questions I understood,
that Expressions aren't naive expressions over real numbers but 
a field with a local point of view.

So it's normal that asin (sin a) = a in the domain Expression of axiom.
But I explain to my students that 
asin (sin a) = a only for %pi/2 <= a <= -%pi/2 (for real a)

Someone, perhaps Waldek but I can't find the mail, explains me that
exp a * exp b isn't always exp (a+b)... it's impossible for complex number.

An other problem is that Expression and AlgebraicNumber are very close,
and it seems that sqrt 5 (almost)= - sqrt 5 in axiom because they are 
the root of the same polynom x^2-5. 
For my use I prefer the RealClosure domain, 
but in this domain there is no %i... How play around 1 + %i*sqrt 2 ?

So Expression isn't for me the good domain for calculus in analysis.
Is it a good idea to improve it for calculus ?
We risk to break it for others computations, Risch integrate I believe.

A better way is to duplicate Expression (with it's own algebraic point of 
view) in a Calculus domain (in analysis),
change simplifications (from an algebraic to an analysis way), 
and correct others problems in order to have expressions as others CAS 
maple, mupad or maxima. But this is a really big work, too long for me...

For this purpose axiom might have operations over intervals,
sin (1..real..10) = -1..real..1, and so. With this domain 
numeric tests might be sure but equal test remains indecidable.

provisos domain with the assume command (as mupad and maple) 
is also necessary. I remember that mupad takes about 3 years from 
the first buggy function assume to its last powerful abilities.

> Francois, you have already some expertise.  
> Maybe you can help here.  Although, in reality, we need a redesign.

I have kept main files of my previous tests : 
  1/ the list of false simplifications (for complex variables),
  2/ the simplifications we can add, 
  3/ tries about expand, rewrite and combine functions.

In the 2/ point it's almost easy to get right results for
sqrt (exp (2)) = sqrt (%e^2) = %e, 
but I fear it's "impossible" to simplify sqrt ((1+%e)^2)
because axiom expands sqrt((1+%e)^2) in sqrt(1+2*%e+%e^2).

The aim of 3/ is to have only theses 3 functions with parameters
and avoid removeSinSqr, sincos2tan, tan2exp and so... 

But this work is useless for me (I teach to first year students) 
until I can't do more analysis calculus.

I don't finish it because I spend much more time (about 5 times) 
to write a *.spad file than a *.input file or a command file for 
maple and mupad, and after write a pamphlet file was too much, sorry...

I hope I answer to your questions.

\start
Date: Sat, 26 May 2007 03:37:07 +0200 (CEST)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: clisp and sbcl

CY wrote:
> Confirmed - builds on sbcl and clisp.  Wow!  Thanks Waldek!
> 
> I don't know if it's important, but I am getting a lisp readout when
> using the integration package:
> 
> (2) -> integrate(sin(x),x)
> [loading messages]
> /home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/target/i686-pc-
> linux/algebra/COMPLEX.fasl
>       for domain Complex
> 
> 
> ; in: LAMBDA NIL
> ;     (VMLISP:QCAR BOOT::|#1|)
> ; --> CAR
> ; ==>
> ;   (THE CONS BOOT::|#1|)
> ;
> ; caught WARNING:
> ;   undefined variable: |#1|
> 

AFAICS this comes because Axiom uses eval and sbcl by default
compiles all evals.  I am investigating whether the warning
indicate some real problem.  One can silence warning switching
to interpreted eval (which will be done for different reasons
in next revision):

)lisp (setf sb-ext:*evaluator-mode* :interpret)

\start
Date: 25 May 2007 20:57:32 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: clisp and sbcl

Waldek Hebisch writes:

| CY wrote:
| > Confirmed - builds on sbcl and clisp.  Wow!  Thanks Waldek!
| > 
| > I don't know if it's important, but I am getting a lisp readout when
| > using the integration package:
| > 
| > (2) -> integrate(sin(x),x)
| > [loading messages]
| > /home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/target/i686-pc-
| > linux/algebra/COMPLEX.fasl
| >       for domain Complex
| > 
| > 
| > ; in: LAMBDA NIL
| > ;     (VMLISP:QCAR BOOT::|#1|)
| > ; --> CAR
| > ; ==>
| > ;   (THE CONS BOOT::|#1|)
| > ;
| > ; caught WARNING:
| > ;   undefined variable: |#1|
| > 
| 
| AFAICS this comes because Axiom uses eval and sbcl by default
| compiles all evals.  I am investigating whether the warning
| indicate some real problem.  One can silence warning switching
| to interpreted eval (which will be done for different reasons
| in next revision):

There is a questionable habit in the Axiom core source code of
defining variables through SETQ -- that tends to trigger warnings
from several Lisp implementations.  Is it possible that the above
is such a warning? (the |#1| are names for synthetized lambdas).

\start
Date: Sat, 26 May 2007 04:50:09 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Packages and compilation

I am somewhat puzzled by error message given by gcl compiling
a file containing following snippet:

(eval-when (:execute :compile-toplevel :load-toplevel)
  (if (not (find-package "AXIOM-LISP"))
       (make-package "AXIOM-LISP"
                          :use (list (or (find-package "COMMON-LISP")
                                                             "LISP")))))

(in-package "AXIOM-LISP")


when I store it in file "axl.lisp" and give the command 

(compile-file "axl.lisp")

to gcl-2.6.8pre I get:

GCL (GNU Common Lisp)  2.6.8 ANSI    Apr 22 2007 12:00:35
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL 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/

>(compile-file "axl.lisp")

Compiling axl.lisp.
; (IN-PACKAGE "AXIOM-LISP") is being compiled.
;; Warning: The package operation (IN-PACKAGE "AXIOM-LISP") was in a bad place.
Error in IN-PACKAGE [or a callee]: A package error occurred on "AXIOM-LISP": "No such package".

Fast links are on: do (use-fast-links nil) for debugging
Broken at IN-PACKAGE.  Type :H for Help.
 1 (Continue)
 2 (SYSTEM:ERROR-SET '(EVAL '(IN-PACKAGE "AXIOM-LISP")))
 3 (Abort) Return to top level.
dbl:>>

The file compiles fine in CLtL1, more precisely I get warnings, but
the file works as expected.  It also works interpreted, but I want
to put inside calls to C functions (defentry form) and for that IIUC
I have to compile it.

\start
Date: 26 May 2007 12:42:48 -0400
From: Stephen Wilson
To: Waldek Hebisch
Subject: Re: Packages and compilation

Waldek Hebisch writes:
> I am somewhat puzzled by error message given by gcl compiling
> a file containing following snippet:
> 
> (eval-when (:execute :compile-toplevel :load-toplevel)
>   (if (not (find-package "AXIOM-LISP"))
>        (make-package "AXIOM-LISP"
>                           :use (list (or (find-package "COMMON-LISP")
>                                                              "LISP")))))
> 
> (in-package "AXIOM-LISP")

Puzzled here too.  Its a bug, for sure. Stranger still, using the
deprecated symbol COMPILE in-place of :COMPILE-TOPLEVEL seems to
result in correct behavior.  Seems to be a viable workaround for the
moment, and perhaps a clue as to the cause.

\start
Date: 26 May 2007 19:25:25 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: [ANN] yet a better version of the axiom mode for emacs.

Hmm, yet another glitch.  When using HyperDoc or my SPADEDIT script, axiom
produces output, which is sent to the buffer.  Unfortunately, this confuses my
output filter, which expects output to be produced only after [return] or
similar was hit.  Is there a way to turn off these messages?

More precisely, I get autoloading messages from HyperDoc:

   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/bc-matrix.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/bc-misc.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/bc-solve.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/bc-util.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/ht-util.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/htsetvar.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/ht-root.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/br-con.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/br-data.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/showimp.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/br-op1.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/br-op2.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/br-search.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/br-util.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/topics.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/br-prof.
   Loading /home/martin/lib/axiom/target/i686-pc-linux/autoload/br-saturn.

and the message from SPADEDIT, which in turn calls emacsclient:

   Waiting for Emacs...Done


The HyperDoc messages can be turned off with )se me au of, but this turns off
more than I'd like.  The other one I don't know at all how to switch off.

\start
Date: 26 May 2007 13:06:48 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: [ANN] yet a better version of the axiom mode for emacs.

Martin Rubey writes:

| Hmm, yet another glitch.  When using HyperDoc or my SPADEDIT script, axiom
| produces output, which is sent to the buffer.  Unfortunately, this confuses my
| output filter, which expects output to be produced only after [return] or
| similar was hit.  Is there a way to turn off these messages?
| 
| More precisely, I get autoloading messages from HyperDoc:

I agree that for "normal" users, those "loading" messages are more
of annoyance than anything.

\start
Date: Sat, 26 May 2007 21:51:36 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Axiom-mail] Enumeration
Cc: Gabriel Dos Reis

On 05/26/2007 09:42 PM, Bill Page wrote:
> On May 26, 2007 3:35 PM Ralf Hemmecke wrote:
>>> Enumeration is an important built-in type in Aldor, but I
>>> Axiom I get mixed (strange) results...
>> Maybe, Enumeration is also not very well implemented in the
>> current Aldor compiler. Some years ago I tried to use it
>> heavily and got some strange segfaults after which I was
>> told better not to use Enumeration.

> Don't believe everything you are told about Aldor... ;)

I don't. Part of it an experience of time that I wasted.

> Seriously, the Enumeration type is used in an integral
> manner in both the Record and Union types, so I think
> it is pretty important.

Sure. I was speaking about the compiler, not the language.

>> But that is just a side remark of no relevance for the
>> SPAD development.

> Au contraire, I think properly implementing Enumeration
> as a built-in type in Spad is potentially quite important.

I meant that whether Enumeration is implemented well or not in the Aldor 
compiler should have no relevance to a proper implementation in SPAD.
Sorry, if I was unclear.

Ralf

PS: Shouldn't that thread just be in axiom-developer?

\start
Date: Sun, 27 May 2007 04:10:46 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Cleaning issues

I have looked at older issues in Issue Tracker and it seems that
there are significant number of issues which are just users not
understanding what Axiom is doing and expecting different result.

For example issue 165 the user clearly do not understand that
that Axiom blindly performs specified computations and that

  [j for j in 4.. | j < 10 ]

simply is an infinite loop.  Correct stream computation work
because they eventually produce some output and compuation
is aborted when sufficently many elements are produced, but
this one just loops without producing any output.

BTW, my impression is that this issue is a duplicate.


Simiarly 335 sort! drops list elements is just example of
linked list.  Something like:

(1) -> bb := [3, 4, 1, 2]

   (1)  [3,4,1,2]
                                                   Type: List PositiveInteger
(2) -> bs := sort! bb

   (2)  [1,2,3,4]
                                                   Type: List PositiveInteger
(3) -> bb

   (3)  [3,4]
                                                   Type: List PositiveInteger
(4) -> bs

   (4)  [1,2,3,4]
                                                   Type: List PositiveInteger
(5) -> bb.1 := 7

   (5)  7
                                                        Type: PositiveInteger
(6) -> bs

   (6)  [1,2,7,4]
                                                   Type: List PositiveInteger
(7) ->

should be, or maybe already is in the tutoral, as an ilustration
that what was a first element of the list after reorganization
may point inside.

Those are just two examples, I would be good if somebody would
filter out other non-issues.

\start
Date: 26 May 2007 21:34:14 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Cleaning issues

Waldek Hebisch writes:

| I have looked at older issues in Issue Tracker and it seems that
| there are significant number of issues which are just users not
| understanding what Axiom is doing and expecting different result.
| 
| For example issue 165 the user clearly do not understand that
| that Axiom blindly performs specified computations and that
| 
|   [j for j in 4.. | j < 10 ]
| 
| simply is an infinite loop.

This one is indeed "paradoxical" at first sight, but is indeed
an infinite computation.  What can we do about it? 
Fo course we can tell user that he/she does not understand.
Can we help with warnings from the interpreter or compiler?  Maybe we
should. 

|  Correct stream computation work
| because they eventually produce some output and compuation
| is aborted when sufficently many elements are produced, but
| this one just loops without producing any output.

That is not what I call "work" :-)

| 
| BTW, my impression is that this issue is a duplicate.
| 
| 
| Simiarly 335 sort! drops list elements is just example of
| linked list.  Something like:
| 
| (1) -> bb := [3, 4, 1, 2]
| 
|    (1)  [3,4,1,2]
|                                                    Type: List PositiveInteger
| (2) -> bs := sort! bb
| 
|    (2)  [1,2,3,4]
|                                                    Type: List PositiveInteger
| (3) -> bb
| 
|    (3)  [3,4]
|                                                    Type: List PositiveInteger
| (4) -> bs
| 
|    (4)  [1,2,3,4]
|                                                    Type: List PositiveInteger
| (5) -> bb.1 := 7
| 
|    (5)  7
|                                                         Type: PositiveInteger
| (6) -> bs
| 
|    (6)  [1,2,7,4]
|                                                    Type: List PositiveInteger
| (7) ->
| 
| should be, or maybe already is in the tutoral, as an ilustration
| that what was a first element of the list after reorganization
| may point inside.

reference semantics and non referential transparent computations are
not things people usually grasp from first reading.  I don't know what
can be done apart from an FAQ entry under the heading
"reference semantics" and "referential transparent computations".

\start
Date: Sat, 26 May 2007 23:43:31 -0400
From: Bill Page
To: Gabriel Dos Reis, Waldek Hebisch
Subject: RE: Cleaning issues

On May 26, 2007 10:34 PM Gabriel Dos Reis
> 
> Waldek Hebisch writes:
> 
> | I have looked at older issues in Issue Tracker and it seems
> | that there are significant number of issues which are just
> | users not understanding what Axiom is doing and expecting
> | different result.
> | 
...
> | Those are just two examples, I would be good if somebody
> | would filter out other non-issues.

The proper thing for *you* to do is to reply directly to
the issue in IssueTracker. Please provide your explanation
there and change the status appropriately.

> I don't know what can be done apart from an FAQ entry
> under the heading "reference semantics" and "referential
> transparent computations".
> 

An FAQ entry might be nice but the first place people
(usually) go when they think they have found an error to
report is the Axiom IssueTracker. We should have answers
such as Waldek's there. In fact we already have several
such issues ansered in this way.

\start
Date: 27 May 2007 09:05:18 +0200
From: Martin Rubey
To: Cliff Yapp, Jay Belanger
Subject: Re: [Axiom-mail] Re: [ANN] yet a better version of the axiom mode for emacs.

Cliff Yapp writes:

> I have uploaded this latest version to
> http://wiki.axiom-developer.org/SandBoxAxiomEmacsMode for convenience (pdf,
> tangled version, what have you.)

great!

> A light trial on Windows XP using the old Windows binary works!

good. Which emacs?  Maybe you could add a section stating where it runs and
where it doesn't, using a tabular, for example.

By the way, I love your idea of copying an input output pair.  Used it twenty
times already!

A port to xemacs and vi would be superb.  I believe Ralf is using xemacs,
Thomas and Christian from my department are using vi and TeXmacs.  Thomas said
he'd switch to emacs if emacs would display output as LaTeX, though.

Another thing:  I have to put back in the initial command 

  )se me au of

since otherwise HyperDoc interferes.  Furthermore, my SPADEDIT needs to be
modified to read

 emacsclient $1 > /dev/null

and

 emacsclient +$number $spadname > /dev/null

for the same reason.  Don't know how to do this on windows, though. issue

  )edit

\start
Date: Sun, 27 May 2007 09:21:05 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: [Axiom-mail] Re: [ANN] yet a better version of the axiom mode for emacs.

> A port to xemacs and vi would be superb.  I believe Ralf is using xemacs,
> Thomas and Christian from my department are using vi and TeXmacs.  Thomas said
> he'd switch to emacs if emacs would display output as LaTeX, though.

Have you looked at preview-latex? Maybe you can convince it to work 
together with axiommode. It is compiling (latexing) to gifs and displays 
them in the emacs buffer.

\start
Date: Sun, 27 May 2007 09:35:14 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Cleaning issues

On 05/27/2007 04:34 AM, Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | I have looked at older issues in Issue Tracker and it seems that
> | there are significant number of issues which are just users not
> | understanding what Axiom is doing and expecting different result.
> | 
> | For example issue 165 the user clearly do not understand that
> | that Axiom blindly performs specified computations and that
> | 
> |   [j for j in 4.. | j < 10 ]
> | 
> | simply is an infinite loop.
> 
> This one is indeed "paradoxical" at first sight, but is indeed
> an infinite computation.  What can we do about it? 
> Fo course we can tell user that he/she does not understand.
> Can we help with warnings from the interpreter or compiler?  Maybe we
> should. 

If an (optional) warning can be issued that would certainly be helpful. 
But one might run into that problem als in a .spad file.

Waldek, I wouldn't close that issue. The Axiom book should clearly state 
that a user might fall into this trap and at least give an example that 
the user probably meant.

   [j for j in 4.. while j < 10]

or

   [j for j in 4..9]

> | Simiarly 335 sort! drops list elements is just example of
> | linked list.  Something like:
> | 
> | (1) -> bb := [3, 4, 1, 2]
> | 
> |    (1)  [3,4,1,2]
> |                                                    Type: List PositiveInteger
> | (2) -> bs := sort! bb
> | 
> |    (2)  [1,2,3,4]
> |                                                    Type: List PositiveInteger
> | (3) -> bb

In Aldor one is told that if you use bang functions (i.e. functions that 
end in ! which are meant to be destructive on one of their arguments) 
you should be very very careful. In fact, you should never use the 
argument that you just destroyed. If a user still uses bb, it is *his* 
fault.

I know that that sounds a little too much for a beginner, but it is a 
simple rule. "Take care when you are using bang functions, you might 
introduce an explosion."

\start
Date: 27 May 2007 09:58:11 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: [Axiom-mail] Re: [ANN] yet a better version of the axiom mode for emacs.

Ralf Hemmecke writes:

> > A port to xemacs and vi would be superb.  I believe Ralf is using xemacs,
> > Thomas and Christian from my department are using vi and TeXmacs.  Thomas said
> > he'd switch to emacs if emacs would display output as LaTeX, though.
> 
> Have you looked at preview-latex? 

No.

> Maybe you can convince it to work together with axiommode.

No.  I have invested too much time already, sorry.

\start
Date: Sun, 27 May 2007 07:38:04 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey, Jay Belanger
Subject: Re: yet a better version of the axiom mode for emacs.

--- Martin Rubey wrote:

> > A light trial on Windows XP using the old Windows binary works!
> 
> good. Which emacs?  Maybe you could add a section stating where it
> runs and where it doesn't, using a tabular, for example.

That's not a bad idea, but for now it's pretty simple:

Linux:  Gnu Emacs + Axiom (any version should work, newer is better)
Windows:  I used Axiom Windows version 0.1.4 and GNU Emacs 21.3.1
(i386-mingw-nt5.1.2600) on Windows XP.  Other versions may work, but
untested.

Other platforms untested.

> By the way, I love your idea of copying an input output pair.  Used
> it twenty times already!

Cool!  Thanks :-).

> A port to xemacs and vi would be superb.  I believe Ralf is using
> xemacs, Thomas and Christian from my department are using vi and
> TeXmacs.  Thomas said he'd switch to emacs if emacs would display
> output as LaTeX, though.

Imaxima (http://members3.jcom.home.ne.jp/imaxima/Site/Welcome.html) is
capable of things like that.  From my standpoint the return isn't worth
the effort it would probably take to get it running, but I imagine
anyone who wanted to could get IMaxima to be IAxiom ;-).

Cheers, and thanks Martin for all the effort you have put in!

\start
Date: 27 May 2007 11:45:20 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [571] branches/wh-sandbox

Waldek Hebisch writes:

[...]

| +	* configure.ac.pamphlet: add --with-lisp-flavor option

Why would you want to have this specified on command line?

\start
Date: Sun, 27 May 2007 18:51:42 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [571] branches/wh-sandbox

> Waldek Hebisch writes:
> 
> [...]
> 
> | +	* configure.ac.pamphlet: add --with-lisp-flavor option
> 
> Why would you want to have this specified on command line?
> 

This option is needed for openmcl: running openmcl with --help
option give no identifing info.  I tried also --version but
openmcl just crashes.  In general if somebody want to try with
another Lisp we can not expect that --help / --version will
work, so giving flavor may be necessary.

\start
Date: Sun, 27 May 2007 12:26:19 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [571] branches/wh-sandbox

On Sun, 27 May 2007, Waldek Hebisch wrote:

| > Waldek Hebisch writes:
| > 
| > [...]
| > 
| > | +	* configure.ac.pamphlet: add --with-lisp-flavor option
| > 
| > Why would you want to have this specified on command line?
| > 
| 
| This option is needed for openmcl: running openmcl with --help
| option give no identifing info.  I tried also --version but
| openmcl just crashes.  In general if somebody want to try with
| another Lisp we can not expect that --help / --version will
| work, so giving flavor may be necessary.

I believe we should push such implementations to provide the identification
through either --help or --version.  That is standard practice, and any
implementation that has any sense does that.  The fact that openmcl crashes on 
--version is a symptom of bug in that implementation, and its developers might
want to know about it.

\start
Date: Sun, 27 May 2007 14:41:45 -0400
From: Bill Page
To: Markus Cozowicz
Subject: RE: Axiom on MediaWiki (was: Axiom)

Markus,

Thank you very much for this initial work! I think it is very
promising.

On May 27, 2007 12:19 PM Markus Cozowicz wrote:
> 
> I found some time on the weekend to work on it.
> 
> Have a look at http://www.eisber.net/StatWiki/index.php/Temp
> 
> I'm actually reusing <math>-tag from MediaWiki, which has 
> limited Latex support. Thus I have to do some conversions and
> stripping. I don't think full support of all Latex outputted
> by Axiom is possible, but to get a reasonable amount, I'd have
> to go through some more samples.
> 
> Some questions:
> 
> - Do you have list of functions that impose security problems?

There are at least two classes of operations that potentially
pose security threats when running Axiom pubicly online. One
is the

  )system ...

command which permits the user to open access to all system
commands. The 2nd entry point is via Lisp which can be
invoked either as a commands such as

  )lisp

and

  )fin

of via a function call like this

  (SI_:_:SYSTEM "...")$Lisp

Both of these leave the system wide open. Unfortunately both
of them also have potentially quite valid uses. I think it
fair to say that the developers of Axiom have given almost
no thought at all to the need for security since the standard
model is to have Axiom running only locally on you desktop.

If you are concerned about security (I don't it take for
granted that you necessarily need to be, given our experience
over the last three years at axiom-developer.org), then I
would highly recommend that first of all you should run Axiom
in a chroot environment.

> - Do you have testcases for Latex output?
>

No, I am sorry that we do not have such official test cases.
I would be glad to develop these with you.

We have however documented some problem cases on the Axiom
Wiki. E.g.

http://wiki.axiom-developer.org/VeryLongLaTeX
 
> I saw that you support graphics too with postscript output.

Axiom can generate graphics with postscript output if it
is run in an X-windows environment. This is possible even
on a headless server by installing the virtual framebuffer
driver Xfbdev and the xvfb-run, although I have had some
trouble interacting with this configuration via a pipe. I
think to do this successfully requires pty support and
something like pexpect.

Right now we do cannot automatically generate graphics for
inclusion in the Axiom Wiki.

See some sparse notes here:

http://wiki.axiom-developer.org/SummerOfCode
http://wiki.axiom-developer.org/GraphicsOnMathAction

> The R-plugin for media wiki already does postscript to png
> conversion for R graphics...
> It shouldn't be too hard to adapt that for Axiom.
> 

Great!

Regards,
Bill Page.

> 
> -----Original Message-----
> From: Bill Page [mailto:Bill Page] 
> Sent: Dienstag, 10. April 2007 03:08
> To: Markus Cozowicz
> Cc: 'Axiom-Developer'
> Subject: Axiom on MediaWiki (was: Axiom)
> 
> Markus,
> 
> I hope you do not mind that I am copying this to the Axiom
> developer mailing list. I think there may be some other
> people here who are interested in this subject.
> 
> On April 9, 2007 6:43 PM Markus Cozowicz wrote:
> 
> > I'm actually trying to integrate Axiom into MediaWiki. I'm
> > using it to write my statistics homework (www.eisber.net/StatWiki).
> 
> Well, I thinks that's a pretty ambitious project just to do
> your homework! :-) But I think this is interesting for much
> more than that.
> 
> > MediaWiki is written in PHP.
> 
> Yes. Very famous. It is the wiki software behind Wikipedia.
> I think it is a very good choice (except for PHP, but that's
> a different story).
> 
> > I'm not sure if I actually want to properly interface with
> > Axiom, as I'm only interested in the generated latex, that
> > needs to be piped into texvc (yet another binary - the latex
> > interface used in MediaWiki).
> 
> I don't know what you mean exactly by "properly interface with
> Axiom". Axiom can generate LaTeX output for the results that it
> calculates. I assume that if you are interested in Axiom, you
> are also interested in symbolic computer algebra in some form
> or other - otherwise I don't see much point in using Axiom just
> to generate LaTeX output. I think you would find it rather
> awkward if that was all you wanted it to do.
> 
> I suppose that you are familiar with the Axiom Wiki web site:
> http://wiki.axiom-developer.org
> If you are using Axiom for statistics - even if it is just for
> a course - then you are certainly welcome to use this web site
> (which is publically available) or it's sister portal site:
> http://portal.axiom-developer.org
> where you can log-in and control who gets access to the pages
> you prepare. We are always interested in more examples of
> applications where Axiom can be used. Your exercises might
> help other people realize how Axiom can be used in their
> own situation.
> 
> As you can discover from the wiki site, these web sites are
> based on Zwiki, Zope and Python - quite different from most
> PHP applications although they accomplish mostly the same
> thing in the end.
> 
> If you are more interested in continuing the development of
> a general purpose MediaWiki plug-in that allows MediaWiki to
> send commands to Axiom and display the results on a wiki page
> in nicely LaTeX typeset form, then as an Axiom developer I am
> very interested in that. I would very much like to be able to
> offer such an interface for Axiom to other MediaWiki users.
> So I would be glad to help you with this.
> 
> > Can I disabled shell execution in Axiom? Because for security
> > reason, I probably don't want anybody to execute arbitrary
> > code on my server.
> 
> Axiom is not designed with this kind of security in mind, but
> in the PHP interface to Axiom, it would be possible to intercept
> commands which might execute arbitrary code and still leave a
> significant subset of Axiom available to the user. If malicous
> code is a serious risk, I think the best option would be to run
> Axiom in a chroot environment or perhaps on a separate virtual
> machine using Xen or other VM tool.

\start
Date: 27 May 2007 21:20:53 +0200
From: Martin Rubey
To: Markus Cozowicz
Subject: re: Axiom on MediaWiki (was: Axiom)

Bill Page writes:

> Markus,
> 
> Thank you very much for this initial work! I think it is very
> promising.
> 
> On May 27, 2007 12:19 PM Markus Cozowicz wrote:
> > 
> > I found some time on the weekend to work on it.
> > 
> > Have a look at http://www.eisber.net/StatWiki/index.php/Temp

Ui das freut mich sehr!

Alles Gute und viel Glueck,

Martin

PS: I was thinking of starting an axiom-tutorial blog, but maybe a Stammtisch
would be better?

\start
Date: 27 May 2007 16:18:29 -0400
From: Stephen Wilson
To: list
Subject: backslash-newline in Makefiles.

--=-=-=


Now on the Axisp branch:
   swilson@axiomdeveloper.org:/home/swilson/axisp

   commit 68ee822219e707ea366fa877e0a99ae8b45c4dc1

Remove backslash-newline sequences from single-quoted strings in
makefiles.
    
The makefiles broke with GNU Make 3.81. From make-3.81/Changelog:
    
  * WARNING: Backward-incompatibility!
    In order to comply with POSIX, the way in which GNU make processes
    backslash-newline sequences in command strings has changed.  If your
    makefiles use backslash-newline sequences inside of single-quoted
    strings in command scripts you will be impacted by this change.  See
    the GNU make manual subsection "Splitting Command Lines" (node
    "Splitting Lines"), in section "Command Syntax", chapter "Writing the
    Commands in Rules", for details.


This fixes the issue reported by Waldek here:
   http://lists.gnu.org/archive/html/axiom-developer/2007-05/msg00346.html

For convinience, attached is a patch against current Silver.


Sincerley,
Steve


--=-=-=
	filename=0001-Remove-backslash-newline-sequences-from-single-quoted-strings-in.patch.gz

H4sICOflWUYAAzAwMDEtUmVtb3ZlLWJhY2tzbGFzaC1uZXdsaW5lLXNlcXVlbmNlcy1mcm9tLXNp
bmdsZS1xdW90ZWQtc3RyaW5ncy1pbi5wYXRjaADlfWtzGzmS7efWr6ir8Ybltinz/dCd29Fut6dX
d/0Kyz2zE9MTEyWyKPGaZLFZJT/W7f3ttx5AITNRlBIgIFbEOmZaEMQEDk/mwbtQf9nGq2A4jqJx
t9vtTKJRexSFveFwHo5Ho6gdTiZhNL7sD6b92bQTvIrXwUW0CTqjoN0+K/4XdNvtztFfsmLOgos0
2lxH6+Bvi2WSffLPn4qfyY+rm2W6uIzD7ex0Gq9+OPo5TKPs0zfrJ0F3FLwKv+SFjIJO/6w9OOsM
g1a7324fXdxc/r9omp4F/3j77P3zf/9n8C5axR+j4DKcfkiWYXLdWkeflot1FCTR7zfReholwTz/
OslifbWMWr/fxGk0C5J0m/2eBIv10Sr8EM0Xyyg5PTp6fx0F1e/B5Tb+EAWfFul18MvrXzNI2W+9
03HnNMi/WfHBVv770+fX4foqWsZXZ0dH3wd/e/bu9fnrX86CnzJMn7Lv11qss2+4CbOvu1gu0i//
6ygIztdBvJ1F2yCNg/yPyy9lRW/fXJz/55MgzYB8yihYrINP14tpCSCvMNhs4+w7JVGSFXLbl84s
s3JX4Vp92eswCaYF1NlphmAefIlvtlkx6hvfJLczuVgni1kUxHNMZ1aGIlRVO90uNmmS15J9t+Uy
uIyCRUbDNHfA5ZfsOy4kngzORRRlxeTfu/qqWSk34TJIbi6TzOWLLHiOLzYZgWlWU/Bc1PIyQ5gc
ByfreJYXAD5R/uXRkxxTVYA0u/iyTsPPx09yAJs088Px37aLwiyDkJUjPld8oXc3GTfZR+fxNphF
aZgF8OlRq9U6Cp7/+7PXv7x4+eaXoObfH/l/OsHjo2CZbJ6+EiSfbsLV5noZpehjw+BxVlyynT69
jOO09sPZ5zq9bvD4cUt8crHOcNcV/EfQGfbG2Sdr/rXq/h0F/aAMABEeT4LxeJJ7O9rmtCUnjx/l
WePs62cVFDmtR0dHs8V8HrRaV4s0CJ8qLi5V+mixnkWfg8mgM+r1Oqenl91BdzAbBp12e9jv5yRC
y6MMILL+8ceg1XnSCx53nvSDH388epw3Ce1B1j4knz8Ff1l8ronW3NsgOKvoliF6ehSIUrpBupkB
HxYNyafP10G0zj6asZFp82q2zRQYbaNgm6sgKaJd2HcK+9wVs7hw3Aflg3mGLf2yiZPg5PImDf40
njyqsQuXV9HlNnz6MsxCdprXkWOYYWLro+eyPl8QPhx0e7N5dHraD7uz3vwSE15vWZJf/7fcEYNJ
/8kkeFz+yDI+httFeJkRm+up4C6Tziq42eS85UJO402wjD5Gy6Aq8Cj47seT6Sx48PWX5y//+uLd
xfmb19+C/x38lv3h9Ok0Xs8XVzcZ2cXf37x9fyH/+ODri9d//Zblv3r2Hy/KzNZ30fQ6Dh6eZE3i
1To4WcbhLDierjZZJDy9mi7/NY2Xy0z38/Vp9qWOH+UmlTjFp/Nvm3xJWnmrugwXq9PlovjoSd4m
Z4C3Z2fRapG25usgJQVkZmm0OjtLwo9Rq/wlOH7w9c2v7789LUt59DCT4s168XkTb9On+edm/8pw
BY+OHhtCf5hV/biq+qENeFrEPvCDH4+CzD9B93Rw2hVtRhKEmd9mN7nbg5/Dj4tZ8CrXURSczPLf
TlfFbz9+CtfhLI5P59tHWTTkHe6H6Eveq2WRtMptk3iZhVLWNaTXYSqqyPqlpAipvG/JmvEcYPan
dqbpLPjyIQSWzC0N6eUtfxTiGffb/fCyfXo6HUSXl/1xLp7RYCDEc4t5qaBbPlC0Z91R/0knb9NE
IssUvOdW17Ptafbrt7M81s9/Vpn5d87lExSh08nbtby7qjEtBzy7zE+CQn/5H4W2gmAxD/4RtP4r
D4DXb84vXnw7Dv6Z/THNx2250LKIQQH74Ovbd2+ev3x2/ioTKFRFLgwRfa2i0T2G9R8HZ/FNurlJ
xd9qsBOZ5uU9+PrT3198K8PxwdeX5xdvL/4u2oXHtyLDIV9E/Z7Yakq8BV3ObLTMhlSHpnAnhz88
+Pr+1dtvT9NtmPU+zWZUx5rzO1/k7VGQN0mFuHqdYSkukQDiykZ302WXiEtkYnH1qbiAKRYXNXcu
rgdff37x9u4IATh20Q6+g0uRSYR3h4YpRl9iOzClppprAsFM7Y16QntlAmovx6lpr8zE2htr2lOm
RHvE/GDaUzh20q6+w4G0Z4jx0NrzRKlH7XkjmKe9fq9dak8koPaSabjWtFdmkkFlVxOfsiXiI/YH
E5/CsZN39R0OJD5DjIcWnydKPYrPG8FM8Y27QnxlQokvKibPCRafzCTiGxLxQVskPs3+nqd0sP4d
fEPsBvMRBzMQY3CHmdPtzeG9Tek8EspT16ArujaRUOpab6LPmS2RV5VL9DUh+kLWSGB6CV4VRghH
te9gHGGnS5v+xGUB7T7kdU8EOpeWVzqZ4hqKOZtIKHFt0i8ZHiwtkYeF1aWjRmCJZEWtDzRmBDB2
cA6+wEFGjIYIDzte9ESnt9GiN3J5ght2JqXgREIJLv1SKB0rTmYSydGxIrRFmtPsDyQ6iGMH7fA7
HER2xhgPKzxvlHqTnkeCmeIbid0BkYDi24TbhGqvyMPS67U16VWWRHnY+mDCq2DspLz6AgeSnRHC
Q4vOC50eJeeJXJ7gRj2xMiISSHDbeKMrrsgkkqP7cdCWag7bH050FY7dtFff4VCyM8N4cOH5odSn
9HwRzBTfWAw1RQKKL91GUYeKr8wk4qMbctCWiI/YH0x8CsdO3tV3OJD4DDEeWnyeKPUoPm8E3yk+
7SjazpO6l7f+WRxHC3vt6WTUPT3tT+aT6bSvH0fbWYA6kLbzI8XJzuHoyTh4XP7IMt4XJ7PjWZQf
vJvlh/K2UTg7Owp+u4yuFuuvH6PtZZguVt+Ogj//OT8YGMyiTfIlCRar8Cr64Yf/U8q/VP/rjOoH
X3Pmnl4u1uLkJvWxONEoPJMf2c1KFOcZ6eZBEU/JJpy1iqqPy5DIyj+mrnpUE0231aTFQBkHzLry
U5G/ResZpKegd9TpPMmmDY/FzyxrsV6ki3C5+K+wOJUuD9iLA5H/+IfG6T//GXwKkyC52Wziu1wS
SOrf/PR/deopH4LdkyRKfw+SxdnZ9+LsaSszCbdfWqt4lp9//x4cgL2Nw+oz6hDqcrH+UDUIJ+UZ
59bsZrNcTMM0SspaaW11Xhf/zjKjNDgpj3dn1IXLR6rBOX5wUrro0bGqcx5vV2EarBfL4DgPP/a3
/e4kl+nJSfHR/Fu3NmF6/X3+7dZJ8N8XAfnDozxav/sOfD7r4vPi/vtC/qnucO6jsqqc1d+yL5DR
+gjR+ttx+Ymry2n26SL5Ke8xdzGXVRNtt/G29gOitoqCXQzkbGleqK0x+2Q9vpP5ZXyznm2ks3Lr
5GraiteZx07UbxUFBSjF0PezaB7eLFNxQLm1+b4sXoA5LuGIP84W2+xrxNsv38vqTjLu0uC4PEP9
CBoeg2+Woy/FfCLE/OhR0QxAnVRNw0NW7ICPc9qbh0QtoCF6yBRMbdtVtWF1koGVANWgupVwHpZ9
88Nj/vf/rvj6hvqRlqD5rdOS/Nh3mDwgKQDhNl2pj5XBq37fqbAd3cRtilOlcmRXX8FO6d3xFUxE
SHDeocRjDPShkRofKtOHx6ikh7WK1PvWcpySTK+jVdZbxpkw1nEafIq3H06D8zSY5w9qBbOb/Kmf
II+B/GfxkF3x6OEmGwquoiTJetek7KaHwyejbtZNlz+L2ZLo7c++K5Lf5ByoeOriw9Vp2f1X2eu4
JKzK/03No0hDkD8t9DFeDvIA/OGHoKZ52Gl6ky6WPLPFOlPV9EP2DYPjn968eX+LVUtZXd4slrOW
GH1I3z04yfSZP4mXBv/2JDj+t+MnJTvZ8JgM9jOYF2+f/ZxN7I6Lp3h+Pn9Xpi/ePS8T59mQsEjk
A5Qi8arIwZ3NcTly4WG+WWdqyNDmz5FEeJifDZjSTVh/NJ5MGjSLwosUWP2eEaplN+bHe/BMmoWH
1kzXFXQ71Y8tqKa18MimVnuxvUtCwn7/2Aq3SWQSWeLzBnEFatjbPaAspnMQXp5rWIB3Oia3duKW
rLE3dExpYeYaVYsL56jS+O6BqNkO4sC+zUWZ/d5OWkVpuIw+GzhJWfCdhGvZ10m4NJ6TKGqWk7iw
dzlJ2O/tpPxhLTMnKQu+k3At+zoJl8ZzEkXNchIX9i1jwNSFk9bRp/DGxEeVAd9FqI59PYQK4zmI
QGb5h4l5l3tK8/07o21kPExQJgbdEa5n7/4IF8fskChwXo/ERb6zSxIFuJkrbOON6WShNDGcLah6
nIy7VXEGA28InD/y5iC/deidFbC3r2bR3MBN5af5HlKl7+scVRLPLxApyyUcqLu8kdk6Gcjl/zcc
yQkTs6EcqMfFWA4Uxx/MIeDs0RwL+W3Dufz/e/tqnnVqhr4CJnxfkXr29RUpjucrDTjLV2zku3wl
C9jbV9NluDLwk/g430eg/H39A4ri+QaBZfmFhXaXT3Ljvf2RmPkjMfVH4s4fiak/EmN/sNDu8kfi
wh9XrXwCZeCRyoDvE1THvl5BhfH8QiCzPMPEvMs3pfn+rVcr36cwab+kgUELBuvYuw2DhTFbMQyZ
147xMO9syVp3bP9wtWPonStz71y59M6VuXeuLLzDxLxbO3dtztWel4I3D1V7jsF0G4X5dYP53uQ4
vypsHDwWP4u9yYtnf30BNicLmwf5Ts9FtSEpdxnLw5ois/qGeHvy7s3CxRo8vJfGN9Pr7K/vz1+9
uHj/7NXbb6CwB1///uLZu7+9ePEf33YWou04lkfUis2wcLOJ1jMSl7ftkBXfWtuKvNXk2cXzN69q
9i9vNTp/LWsysXrz1gLfm+cWRj+9szB6/+7Zawuz189+saru2cWzX9+/uW3jOE++LJoZfTOTmpA9
5J1bmVXcaTuwWtxpzQsn8h4GJlYq+MzsQPyZoXxrh1MFoZmdCgwzOxiKZpYoGk2dIQNSs2PFZM12
unFU7miIL56/y6+5ziC08oA5f/ni3W2F/EmV8kdyHUfneWiv/5L1cH9IMPJAaH5l7Sq5Sp5O41a0
vjrN02XPGvwpIP92VJd3TJN2Jz86XP7w0C396fFZ+GG6hOdT9QNG0kv5Kden4kvwvoI6p1x7WPY7
eni4PGBVcwBWllhz2Un+rzK8SfLTVOhEsSRMO1IclOeXjRHUHwV8aIuhcsYQeLcaneR/nW7gXzJB
/ef5m1d5GtiGMB+NbSad4vR5+SPLyO953WS+jdezRXHXdJDfv3x6VAyNfvr1lyK45EMns+jy5iqL
CKKiUVC07fmJL/mJvX2t17fL2TUEV8jtvFxX9y43m9YOrt4Dn1QOls8TTXqjJ51O5qjyp3qaKOs1
l1/ws0Rl1pTcwEIfnVWG6EEianyy/2NE+qyG1kSnNDsmNQpyftEyfkJEtnb1j7EwIOgerZ+lcEHc
+hjQvVLSAEJon3DbYzxlvI8mZbyXP8GNegt6o1eRQ4K9R+/SW9Td5YUtXTwxt4PWqiLdqzsOZSzU
3VMuAl0BqGm4dhyw4EGwCXMfdBycDG3Yc1uMi4dE2/1BEeUygW8jl8db0G3keSa5j4S27NBWu44c
2fsMeVAXsy0j552cxD1EwW3Q+Disgt8XMc2gxaSlzxJCB+Oh0EGZUDqYzm/WpL0vs4gG6C0Fyg4p
gNh6jH9VE7eRU5AdBT+AwG7ouCBsIt8PJQ0gxKjpLyO+k1+nmEe8SICIz5CTgM9zSLyPaLxLKxzu
yNJntMuKmC1aBXc3qYaxXgHgNmdcCFaR7p6OQ3NhPILvdAa9fGlB/Cyf6HrzHMA7nX1cnBXrqjCz
ejhehfY6Sbc3UyoKkXvHDVHImoiDlkAFYuBvUJTm8x2UA1y3hGDdY/QsFPqdCnviKNYigj//GVUT
nGRVl7Sev36U3z5Q+n7cE81bmVDN2ywMxWFTtYxUZBE/0hmcskNOJLYemzhVE8/BCrCj7hwAYPqW
C8GmifNBx8HJII3c3W1ct1Muy8kEiPN8vZDEeZFF4pxeJqnscJxjW59xXtXEdGwF2FWcKwBc1zIh
WMW5BzoOToZ5nE/EcFUkYJzPaZTPSYz36R3F0oZE+Pye4ntuMjQDJ93dBPfcbGjGq98ush0TcVga
rBYeer1OGdcioeJ6vg5XZJxSZpHYpu23skPRTWw9xreqiddgKcCOQhwAYDZZXAg2Ue6DjoOTYdx+
90YyzkdanIMj9yDURS6O9gGdXSFrEvC0BK8xDyrj+hk/jOEm8iEMtr/ZQOzi3xc1DSHGQAtVs9/v
iH0XkQByiLfpNFwuiRxkLtlUH9BlZ2SO9aAX4W9rHVfG9DqETum2VgQGwvW8ARQrTXikpzHkGPcR
/cFYiKJMKFFcXRXHUci7katcogm6NI2skSb0Ejz2Eagyns8Rckd9BIbB9LkBEBs9+KOmIcSYa2Ei
1i9FQmnhOkyusQ6KHKyBIR0nVVYo/rGlx9ivKmLO9Sq4joJe1c+d7zER2ES7BzIOTYX55sygKxYu
RUIF+CqcbmOy5S7ySJDTJXpgicKcWnsMdFAV07sAtKNghxi4PmajsAl4T6Q0gRKLwB/KwB/SwAfX
PqnIF5kk9OkYB9ri2Kf2PoMf1MV1NL4HzEn4QxRsZ7NxWAnAFzHNoMVq5XPY6Zc6EAmsA31FqMol
Z/3p2j6y1qRwbytCqDLekJZepeJKDMYLHwZAbNXgh5qGEGOzIjQciBUhkQByiNeLNCZzX5lJxEA3
A6At1gK19ykFUBe39QO4XSkBomC3f2wcVkLwRUwzaDEfGw3lLu+Q7vKC2/zUq57LPCIB7UXPyhK/
5plYexQAqIrpZnypo4vwhxi4bmajsAl+T6Q0gRLzwB/1ROCLBAj85eKShH2eg4N+TGfClRUOeWTp
M+BlRVzPSriugr2qn+1XHgKrQHdPxqGpsAjwiZj1igQI8PxZVb1tl7k40Cd0XRNZ42DXSvAZ8LAy
rp8hdFeBj3CwPc5HYiUAf+Q0hRqrGfC4L2bAIqE0AW9pryQhM4kiBkQR0BYJQrP3qAdYF9Pj5Np+
F2pAKLge5+Ow0YI3YppBi50OxmLqKxJQB+n0OkqoDspMogM67oe2RAfE3qsOVF1sdyvcznQAUPAd
zsVhpwNPxDSDFvMB0mQoDsiJBBABvCBdqUDmYhl02nRnAJljIWhF+FQCrIy36EfvznciBQSDuexn
AMRKC96oaQgxFuuh3bY4DCQTSg9JPP2wiLEaRB7RQodqAZgiJVBzjzoAVTHbPQDakQggBm67x0Zh
owBPpDSBEuOeoNuedEXklwkQ+dlchMR9nkOiXruOozLDMY9MfUa8rIjrWgnXVbRX9bMdy0NgFenu
yTg0FeYR3umWt23IBI7w4k2qepiX2TTW6cInLkALeFKI56hXtRl4W6F3GP8AiYnnuVhsleCNoObQ
Y6GO8USoY0yuHrtZL+I1VkaZRVVB58LKECmCGHtUg6qJ6WiF2JEKAAKui7kYbKLfCyGHp8M82rvd
8qCzTIBol1fCqmDPc0is9+j5H3WTLAp1ZOoz0mVFXL+Cm/idxHlVP9uvPARWUe6ejENTYRHhQxnh
QxLhH1c5OhzjIo9GOT3YA0xRnFNzj5EOqmK6F4B2FO0QA9fJbBQ2Ee+JlCZQYhH5YtNXJsClwcvf
Sdte5NArg3t0IFPZ4SuDsa3HG4Oriri340q8ru4LVgDYt+PyIFjdFuyBjoOTYR7mvZ4YsIsEuEQ1
v4Y8XuFIl5k02LVbSqA1vkZVK8FfyKO6uNeFAuCu7lFFMNg3hrKBWF2k6o2ahhBjLoV+W6zsiAS4
VbKlj+dFniYE7W7JVv2gXrP3JwNYFfdOxZbrsT0Cwb5akQvD6p5JT7Q0ghSL8B/0RfgPyImedXjV
mra75JCbyKQCGHToKTdgjQ+5aSWYSwB8Q9Y5Klgl9zQXwH+HFvZCwz7VxcYDRdEYoppFk4VMhmLA
JBKFTHSc8mpWmVm82FLdzlof7Fnlz17/8vLFt9uMgx9gtklfgdk+yc3PzrbRNi/mWL4uSn8xTPHB
jJD12VmRiqfL4BhiYPQQvKprfLtn5bRfuH8KDkgAO7hlcrsKUGw9KkN+0BY9g0jQnmFQ1zMM9J6B
nvaE1jU9w+BeBkeoLt4BFojb1dlnhIJ5goWPw+rksy9imkGL6a0m3UFHNPwiQRv+QV3DP9in4R/U
N/yD+2r4b2v2Br5b/ltbPk7tjpr+fUg4JAW08Tdo/Qe49ZfzgkH9vGBY1/oP9dZfe7YRWNe0/sN7
bP2HFuPcofvmf2g1xOUAsW//fVDTEGLMx/4DOfYf1I/9h3VdwHCfLmBY3wUMm9AFDA/aBXBqv4cu
4C4Yh6Rgjy5giLqAoZwADOsmALN2R+8C8kzaBWh3XkFrrQvAJfjtAqq6DNo5CdxhF6BgmLR0PCC2
XYAfahpCjHkXMJSzgGHdLKDCCbuAPNO6C9CMyy5AZh+0C5AgDtMF8Gr33gXcDeOQFFh3AVWAyS5A
zgKGdbOAWd3uwKxmd0C7+w1a13QB9747MLNY9J552x2YWS178/DsuTvgh6hm0WTRPcgZwrBuhjCr
2x2Y7bM7oBnL7uHedgduaxm9bw/c2jbe4/7APiQckoI9uge8RTCSM4RR/QyhV9c99LTuYVS3eSyt
a7qH3v13Dz2LVq/nrXvoWbV7HDx7dw8+iGoWTebdw0jOHkb1s4deXffQ26d76NV3D70mdA+9g3YP
nNrvoXu4C8YhKdije+jh7kHOHkZ1s4eobgEpqllAGtXtIEe7FpCie1xAiixWSSL3C0iR1ToJD4jt
ApIfahpCjEUXIGcIo7oZQlS3gBTts4CkGZddQNSEBaTooAtIvNq9dwF3wzgkBdZdQEQWkMZyhjCu
myFEdQtIUc0Ckn5bKLCu6QL2W0Aya2LMF0Qi3sqRHQyzls50yejw1DSEGPMuYCxnAeO6WUBUt0gU
7bNIpBnLLqABi0TRQReJeLXfQxdwuEUiTt24LIMuAC8SjeUsYFw/C+jXdQF9vQuo20OQ1jVdQP++
F4mqKo2au76nRSKFxqzd4+DZc5HID1HNosmie5AzhHH9DKFf1z309+ke+vXdQ78J3UP/oN0Dp/Z7
6B7ugnFICvboHvqoe5jIGcKkboYwr1skmtcsEk3q9hDmuxaJ5nsuElm0NHOLBZE5b61oLzQm7R4P
z57dgx+imkWTefcwkbOHSd3sYV63gDTfZwFJMy67h3kTFpDmB11A4tXuvXu4G8YhKbDuHuZkAWki
Zw+TutnDvG4BaV6zgKS9cwBa13QP934CaW6xWDLnrSPthcas3buHE0h+iGoWTRbdg5w9TOpmD/O6
xaX5PotLmrHsHhqwuDQ/6OISr/Z76B4Ot7jEqRuXZdA9oMWlXlvMHmSCdg81i0vzmsUl7VUc0Lqm
e9hvcclk/XpusVgy560q2cEwa+lMl5MOT01DiDHuAnptMUOQCdoF1CwgzfdZQNKMZRfQgAWk+UEX
kHi130MXcLgFJE7duCyDLqCPu4CB7ALqZwijui5gRLuAbrtui1la13QBo/ufIYwsmruRtxnCyKrd
4+DZe4bgg6hm0WTRPQxl91A/QxjVdQ+jfbqHUX33MGpC9zA6aPfAqf0euoe7YBySgj26hxHqHjpy
htCpmyEkeueQ6F1D3dZzzWv6qLXfmUFi3Mg5fUMfhGDStvl6PZ8fShpAiHlT35EzgU7dTCDRG/rE
vplP6hr55PBNfHLABp5Tt/fm/S4Qh/v61k17ghv2QU9E+YC8pGAaptFVvP1Cru6VubR579CtY2SP
r+/Vy/B4gS+qjHtXLcTuqKknQNg31vKh2DT4PulpDDkWjb94g4FMIFmk4eUy0mRR5mqy6OuyUPZU
FrQMr7IAlfH9rrC7kwUEYuB5LhRLWXijpzHkmMui2xeyEAl4zfssntJb3vMsTRBj7ZJ3aUnueMfW
Pq94r2piX2UuIbsSAYDAv8qcB8Iq/L1Q0gBCzEO+J95sIBMg5JchecNHkUMDvktf71HZ4XjHth7D
vaqI61qJ11WwKwBs1/IgWIW6BzoOToZFmPfHIsz7Yz3MV9FMj/Q8Uwt2ekIIWmvxjkvwG/JVXQZu
lsAdBr6CYeJuHhDb8PdDTUOIsZDCpCOkUCaAFDLwYUqUUOZpQtCGOcoW64Dae5QBqIrraoXalQgg
CLaruTCsJOCJlkaQYh7+ffFWM5nA4Z8B2OoCKHKpBLQ3tCJ7TQSkDL8yUJUZeLzC7lAKAIiJ35lQ
QFk2qvDFUmM4slDHWKqDvqQ7+xo5BCwOmalpg77XFVojaegl+FMGqovpcgjckS4wDK7L+UBsOgl/
1DSEGHMpDHrdUgoigTuKbZQkekdR5GpioOdGkb3WUZAy/HYUqjKDJrDC7rCjAEBMGkEmFNtxky96
GkOOhSxGYsFIJJQsZmEaXoYJ6SKqXCoL7b2wyB7JoqYMf7LAlTH9jrA7kgUBwvW8ARQbWfikpzHk
mMti2BWyEAkgi2i+WFNRlHmaJOiwCdhiQVB7j3IAVXG9rVC7kgIEwfY1F4aVDDzR0ghSLMJ/KNZX
RUKF/zzeruiiksjTwp8OlIAtCn/N3l/4w6qYfgaoHYU/AsH1NBuGTfj7oqURpJiH/6gjWn+RAOF/
s56mMVlTkplUAAP6eAG0xgrQSvAoAVgX19kAuCsRIBhsh7OBWMnAGzUNIcZCCnJ+MKLzg6tWcQoU
KUHkaUKgh6mBLdKBZu9PBrAqpqsBakciQCC4rmbDsJGAL1oaQYp5+I87YiAkEjD8p+t8+kEFIHKp
BIZtTQLAnohAK8OnDGBlbI8D7M6kgIDw/c6GYicHf/Q0hhwLWQzFYqpIQFlE2y0dIMlMTRR0gASt
iSZoCT4lAepiu1wBdyYICIPvci4QOzn4oqYhxJhLYdIelFIQCSiFeKONj/IsTQZ0nUhZEhFga58S
qGpie1lCdhb+CgLfxzwQdqHvg5IGEGIR8vJc9YSeq75qpYsVPXIhM7Wwp+tD0JoEPi3BZ+iDutie
VsCdhT+Ewfc3F4idBHxR0xBijKXQb7dLKcgElMJNulhSJRR5VAgjfRhU2RIdEHufMlBVsV1doXYm
AgCC72omDDsJ+KGlEaRYhH9/IsK/T84XXU2Xn6JLEv5lHo7+nvaiWGCKo5+YnwT+ol9VxfWyAu0q
+AEGtpu5KKxi3w8pTaDEIvJHbRH5ZUJF/vWXTbRNo8849qtcrfGng39kjwRQU4a/DgBXxnQ4wu5I
BwQI1+8GUGzE4JOexpBjLotOp7x5RSaULBatcB0uyfP5MlMTBZ0aQGukCb0Ef5JAdTFdDoE7EgSG
wXU5H4iNHPxR0xBiLKQwEFMDkYBSmMaziCqhyKNCGNNTdcCW6IDY+5SBqort6gq1MxEAEHxXM2HY
ScAPLY0gxSL8J2JqIBI4/KPttEYARa4mAfqQJrLXREDK8CsDVZmBxyvsDqUAgJj4nQnFVg6+6GkM
Oeay6PbLG4xkgspivq6TRZaryYI+sonsa2SByvAtC1mZkd8FdqeyqICYeZ4FxV4WfuhpDDkWshiL
wZJIQFlEH8MlFUWRRyWhvQ8K2BJBEHufclBVsb1doXYmBQCC72smDDsZ+KGlEaSYh3+vKwZLIgHD
f36zTiJNACJXkwC9wAvZExFoZfiUAayM7XGA3ZkUEBC+39lQ7OTgj57GkGMhi5EYLImEksVlHH/4
GC8HWBYg9+X5xdtvUBh0lwGVgIRRW4o/adDqmN5H+B2JQ4PCjQADMDby8EtRgwgyl0i/KwZOIgF7
jsU6jbbafELkkp6j16YHVJE96Tm0Mnz2HLAydtMIsDvrORAQfuPIhmLXc/ijpzHksGSBVDHqCFWM
OlQVq3BDJZFnaXqghzKUJREDtvaphKomtp8lZGcaUBD4PuaBsIt+H5Q0gBDzjmDQEWMlkYAhX6Kg
US9ytcCnG9LInsS+VobP8IeVsd0NsDsTAQLCdzsbip0U/NHTGHIsZCF34Qb6Ltw2SuLlRyoLkavJ
Qt+SBvZEFloZPmUBK2P7HWB3JgsEhO95NhQ7WfijpzHkmMti2BYDJJGAskg20bRDVVFmUlF09O1p
ZU00QUvwKQlQF9vlCrgzQUAYfJdzgdjJwRc1DSHGQgp9cWRJJKgUunVS0N423uvo29TKukYK+71t
3Ixqs7dnQ+BOpWD64mw+EHsp+KCmIcRYSEHuwg31XbjkSzJdzTQtlLmaGPTNaWBP1UDL8CoHUBnf
6Qq7O0FAIAaO50KxlIQ3ehpDjrksRj0xWBIJKIs03iwjbQ4hcqksuvoGNbAnstDK8CkLWBnb7wC7
M1kgIHzPs6HYycIfPY0hhyEL9Q+pYzQQ6hgNqDr0R+AWtY/A9br6vnX9I3CavU9VGD/rtXD+CNzC
5mkvNgw7NfihpRGkWKtg3BXLryIBVLCex0QDeY6mAG3IJO1w/GNbj9FfVcR1ssTrKvIVALaLeRCs
ot4DHQcnw3woNJYba2NtYy2NtqF2NV6VS8Nde90Csschr5fhMexRZVxfQ+yuwh8DYXudD8VKBh7p
aQw55rKYdMQYSCSULHJ8ywV5EFpmaqKga0jQGmlCL8GfJFBdTJdD4I4EgWFwXc4HYiMHf9Q0hBgL
KQzGQgoDcmPeKkyn11gIZZYmAzoUUpZIBNTanwRATUwvK8iOwh9C4PqYC8Im9P1Q0gBCjEN+0BYv
3ZQJEPLxLNLOG8lMGvbaGxSgNQ58rQSPoQ/r4noaAHcV/ggG299sIFYS8EZNQ4ixkMKgLaQwINdi
rJKrGRkGlVmaDOggSFliERBrjxJQNXG9XEF2Ff4AAtvHTBBWoe+FkgYQYhHyk64I+Qm5C3UdfZrH
W3LuTmZqYU8HPdAaBb5egr/QR3UxPQ2BOwp/DIPrbz4QGwn4o6YhxJhLodMvV4dkAkhhe7POvwDR
gsylYhjQoRCyx2rQy/AoB1QZ1+kQO6XbWhEYCdvzBlisROGToObQYyGN8UBIYzzQpTEPE9pNyFxN
GnR4hOw1aZAy/EpDVWbg+Qq7S2kAJCa+52KxlYY3gppDj7k0uuLhZ5nA0riKdWFc6dtnA234pGw1
UVzdzxYarMrA31f12zb7yOHKdPOIj8NWCl6IaQYtFhIQ22oygSWQX12si6DIpTIY0hNGyF4TAinD
rxRUZQY+r7C7lANAYuJ5LhZbSXgjqDn0mEujJ7bWZAJLQ3vDgszUhEEPGEFrTRf39Z4FVJeB03fd
6r+PKMzfLmCAxFYSnshpCjUWchDbazKh5BBfRuR2VZFDrsLQL9yuLJEONGuP923DupierkA7WmJC
ELhuZoKwiX4/lDSAEIuYn8iYn5CY34TTD+EVGRzJTNoFjOjYCFqj0NdL8NcFoLqYjobAXXUBGAfX
3wZIbETgkZymUGMuh/6gPGoqE1AO20QTwzapkQJdRFKWRAjY2qcMtoYvoVeQ3Ulga/wGejYKu/D3
QkoTKDEP+0FH7LOJBAz79Hod0jlylasFP32SH9mT+NfK8CkBWBnb4QC7OyEgJHzH87HYycEjQc2h
x0Ia4rlNmQDSiJM00yNRhsikwhjTOTK0xrrQSvAoC1gX1+kAuDNRIBxsp/ORWEnCKTkHZIMGPWLn
bgUM+6JzEAmlgG10tY2SBCtAZd45OYb2SAN1ZXicIpPqmL6G6B1NlCkQru/5UGyE4JOexpBj3jMM
R2LqLBJAFzfLKIlSKgyZq/UNmi6gPRaGXoa/3gFXxnU7xO6qfyBI2J43wGIlDJ8ENYcec2mMuqLL
EAkljSTafqQvsRV5VBYTemsqsEWi0Oz9SQJWxfQ3QO1KDggF19t8HDZS8EZMM2ixkMBYrCSJBJRA
+jGbxlMNlJmaCOi8AVoTFdASfMoA1MV2twLuTggQB9/lbCR2UvBGTlOoMZfDuCue4xEJKoe0Tg76
VrN21Ty0rpHD/Ww1o7qMPO52qxnjMPO5t61mj+Q0hRoLOQwnTzrdXA5lAshhsdpcxjG52qXKJYLo
a1fLI3usCL0Mj5JAlXHdDrFbL5+Qqtm+vq1y7F83uvgfw9DdcpiIW8BkAshhGa6IFPIcTQbaMEna
YQlgW4/hX1XEdazE62glCQBgu5cHwSrWPdBxcDLMW/2JeOeOTKgwT6PVZhmmZJutytXCnQ6DkD0K
+Zoy/IU9rozpa4Td1VCIIOG63QSLjRBcE3RQRvZr9IftTrmzJhNQDdvV9hPVQpFHldCh4x9gS3RA
7H2qQFXFdnGF2p0CAAq+t7k47KLfEzHNoMW4Qxi2BxMhgQF5PKewIQoosjQB0HfpKEsc/8TaY/ir
mrhOriA7C36Age1kLgqr0PdDShMoMQ/7jnhDgkyosA/JsmiorYj2O/QdOmHNYmh4P+ugodkqX+h2
9TM0Xd3j1W8T3s6JOCwNFiHdFy25SIDXaU5bqzDdLj7jyFbZNMC7tEXHJeD3adaU4vF1mrg27qsi
EXxXwU+xsN8WaYLGRgqeSWoSRRYymUiZTGpkskimukjyTE0i2htngbUmEFyCX3lUdRn4XQJ3KQ2F
w8TrTCS2svBETlOoMZdDt18eIZIJJIf85VSRpocylwqiR5+/QfZUEbQMr5IAlfHdrrA7FAVEYuB6
NhZLWfgjqDn0WEhjIqVBH0zL6tTffSAzNWHQp3GgNdXFvb3+ANXFd7rrFyBgGAY+9/gKBH/UNIQY
cyn0+mKhVCSUFK7TGinITE0K9NkcaI2koJfgTwqoLqa/IXBX/QPGwXW5ARIbMXgkpynUWMhhMhRy
mAypHMoDG1QPIpcKok8n2sieKEIrw6ckYGWa23ewDaC70wQConl+l+P5UOxE4Y+expBDZHG3Kvr9
8nZgmYBP6UzjLXm7oMjTFEHXVoEteUCH2Ht8CgFUxX70pELt7AkEiIL/5AkXh91jOZ6IaQYt5h1D
fywWl0QCjZO2cZxq46Qik4pgQLeUoTUdJ5ESvI6TVF38oUAF3OE4CeAwGAxwkViOk3yR0xRqzOUw
6IkZtEhAOUyvo+kHKocyU5MDPVoHrYkcaAk+5QDqYntcAXcnB4iD73M2Ejs5eCOnKdRYyEE8yD/U
HuQPydZcqO/JDeml2WHNZlx4P7twodnOUuh23y003U3i1W+16eyaiMPSYB7Sw155f6NMgDXSbWsa
r8kSaZmnhTYd8wNbvEBK7T2uj4KquGuACrWzLQOIgr0IyMZhtTrqi5hm0GIhgXFfSKBMIAkkUbil
r0VT2VQIIzruxyVQLWileJUDrI3veADfoSgQFoMA4KOxlIZPkppEkblMRj0hE5FAMok3HU0jeZ4m
EDoTALZUHdjeqzSqqvgul6gdikKhMHA3E4elHPwQ0wxaLCQw7goJjLs1EujWSKCrS4C+CgHY6hLo
3p8Euuae7rqXQNfG1ywc1hLwQUwzaDGXwLgn9ghEAklgFqahpoEik4pgTCfD0JqqgJTgVQaqLr67
K+AOhQBwGLici8RSCr7IaQo1FnIYif0CkUByqDlitK0/VzGumUDvOGKkleBVDubnaLbuz1VgHAY+
93muwiM5TaHGXA6TrtgvEAk8lQ7Tm62+oCSyqSS0q7twCdpUmpbidyoNajOYJSr4LqfSEIvJPJGN
xnYq7ZGkJlFkIZOR2EcQCfDMZrxZTMkDbCJPEwidSgNb/Ngmtff43CaoivuMokLt7MlNiIL9nCIb
h9Wzm76IaQYtxhIYtbvlvoNMoJ4i+xpzrZ8oMjUR1EymK2vaR5ASvPYQqi5+01cBd9g7ABwGDR8X
iWXP4IucplBjIYfhWMhhqAZOP795rqq8zA94zD4uckmcvyb5m3C1uV5G6ZGUwc06/15YQyIv/0+g
JDRo0+d+gC1SELAvzDlqwb6odwUoVw+H+ngAEBnPMZiC0KNhRziwYQRFWAKhHJKXRrBCJbJDI7lI
pEbkI/8j+Mh/oREAE0oEZmsKWaynZHJe5Ew1edBhVmWIxKGMnWpDFcsNgQqeI2EABOwIYGKwUoUX
Rg7PB18PlRzEOxVkQsmhqI72FypTk0IyDcm0vMghY62BdmNYZYcvyMO2pkOqHdevVYVyb3+T2Eyf
c7uzfvb1bzwEtw6h7o+MQ1PBHTJV0S/uxpYJFf1FZTT6VaYW/fk3xNFf5GgdgXZNWGWI371TGTvt
CFSx3GavgueoIwAI2A0fE4NVR+CFkcPzYd4RdLvlwQyZUFIoqqNSUJmaFKY1byic1r6icKDdGTbd
8Y5Czd5NhzA1f/nedPeb7xT9Rr3C1Ob9e3wYFl2DL1qawIlpF9EdiiUmkVC6ENVRZcBsTRurrBJy
yLvM0pRB9/KUJRIGtXajC1Aq0/8KnpuhEkTA9T8Xg4Ui/BByeDpM1dBrl488y4RSQ1kbFQPI1YdM
6TaKyC6FyNOHTdrrPJUxHjiBAhwKAhbLfQOfQuioo0Ag2G/jY8OwkIUvWprAibE0xOUYI3g5RjmA
KqvThlAgu04c8UbTRpalSaNLD0EpU6oMae5WGLJUfgDE7EVXQwQGAcDCYCcJD4Qcng5jOYzFXoRI
IDlktdWoQeZqYpj9jpWQ/a7LgN6vJIyQBqShQwHIIpnOFqjchH5VN9fRrNotgt41CYekwDTQ+93y
8J5MqEDPqqJRLrP0SXOS9Qb0DSMyUw92umENzfHEGRbhcuYMy+XOEQFINwLAKNjzRDYOm7mzN2Ka
QYuxPEZiv00kwPxZ1KdNoGG+JpQw+yt5SjrP0SSiXURZGZL7udOtc3GoQtnXUKf1F/HYyQLUz7+K
moXAQhA+yDg0FaYiGHTELptIKBEUlVEFqEx9ASm5IstHWYYe/HS7WZrhtSNp6nLlSJbJXSYRwByt
GlW1sxdJWPXbrBg5J+KwNBiH/EBsrYkEWCnK6tLWiWSevq0cbbex/p7mPE8Pe/2lnJUxfVFzVYDL
/WVQLP/dwxKhoz1miMHg3cM8FDb7zJ5IaQIlxqKYiE02kQD7zWV12o4zyNbXiOJkQa4SK7M0YfS1
XefKFK8RKXOXa0SqVO6SSAXP1dIpgMBeFeGCsFkl8kLJ4fkwFYS8OGYEL44pV4mK2rRVIpWrT6Hn
8XYVEkHITF0S2tYzMMdTaFiEyyk0LJc7UwQgHU2hEQr2XJGNw2YK7Y2YZtBiLBLxoI9MgCm0qE+b
QsN8TSgfw+1ivcA6EXm6TOg+NDBGKoEFOBQJLJYZCgChG4kgDNxQYKOwEIgvUppAiak4Rh2xzyAS
ShyiOqoNmK0PqWqksdklDW1Peoc0Nn6ksTGPgo1raWxs4oCNwmZg5YmUJlBiLA3xUk+ZAIOremls
bpPGYp3mkOnTDmWmJo4B3ZWG5uSZB1CEQ3mgcpmhAEG6EQhGwQ0HPg4Lifgjphm0mMpk3BaLsyKR
ZabXiyTI/peFXDCNZ1GWCNNguVh/KPPW0aegOOa3DdK4yMmgRdvNNsr+CxWT/U8TTJ5HTvsN6OY1
MKViQebOpCJL5ceDxOdMJxUEg3DggbATiQ9KGkCIsTzkFH1Mp+gAIn5GSGVrvch6SkZXeQZVA93d
lkZICsjQjQ5kkbxXeUhUbgRQ1c18fwevdovId03CISlgvrykCnX5/PSYPj8tocE4r/L0PYt5Mr9Z
t8iToVUuCfch3alG5njfQivC0cYFLJe7SA9ROtq7QDDYK/V8IDbbF/6oaQgxph3CpC129kQCbGJA
mGgbA/2hbmrRSulxV5mpTS2G+rPUypyOllQRbsdLqlz+8KAC6WzIBFAYjBGYOOxGTZ6IaQYtxlLp
i7GTSKCxU1Gf/oA1yNeEEidfkumKvEJLZpZCQUqh++HQHikFleFQKahcZkBAkG6UglFwQ4KPw0Ip
/ohpBi3GShEvRZEJpRRZH1UKyq9ZyJ1+yOoiNxJUubpWtEv3UQlkPReW4nRFFxbMXr4EOF2t6iIc
/EVMNhKrlV1/5DSFGkPVjNviHmWZgCu8okJ9jRf+QdfNvJvQJ1RFnjYQG9EtdGCMBQMKcCkXUCw3
HhRCR1KBGNjRwEVhIxNPpDSBEmN5iLPnMgHkUVaniQNk75jV183pa6RBt82Bcc2M3v1JRFCs0aTV
+Wze9NgdF4X1VN49KU2gxFQana7oOURC3ZyZXMefFisyGZeZ9JqCMR01QWsc6FoJ/m7ORHVxPQ2A
m8Y/Cwbb3WwgNvdm+qOmIcQY35o57ogbPmQCvJ40TK7z7T+shSpXE4P2Gndoj99Qqpfh8RWlqDLu
azghdkeCIEDYb+LkQ7F6SalHehpDjrksuu3y9IhMKFkUe901y7URvmBAiIKOhKA1Xa0lJfiTBKqL
v1AZ2V5dwIJhsFbJBGIjB3/UNIQYCymIZ5lkopDCs1/fv/n29NOCvLIuz6AamIDDUNgMCQCb+gv+
qp67vYvROop6VT/DsSYIbMLdAxmHpsIiwCdiCCQSKMC7NMC1t9ENJgM9wGveRYdNfQY4+2VrGK2z
ADd40ZoJArsAd07GoakwD/Ber9xekAkQ4JtkE85IIy7ytDAf0zAHxnjFkxbgL9hhVVwXA9iOQh6h
YLuajcMm8L0R0wxaLEQgXjMnE1QE3RoRaG39EL7pQTPWRXA/LT6sysjXTtt9hMLM275af2/ENIMW
cxH0u2JPQCSACFbh9gOWQJGjCaBPBVAZkqtZkbG/4FcVcT1cAXYU+AAB279MDDZB74WQw9NhEexy
abNPlzbDz9Hn9F/khKrMpAFPjxFBY3ybEi3AX9DDqrgXCwHYjgIfoWBfMMTGYRP83ohpBi3mIhiI
N/7IhBLBPA5XVAMij0hAe20DMEUKoOYeBACqYPoXgN037mHlXMeyqzcKd080HJQEi+Ae9Z50unlw
l4kiuF+9zip88DUv8mm4vIout+HT6PMmTiJx9LOKdpm7TDZZ1svziwIHDHywfH9nsdpbJ4p/UB6g
PqvTDjvaG1Ds3bFw19fA7jFo9SAKRliY4sCs/gH8Zd1X/E/n7ZZTEq1WcNQ5HZy2j47+PxuAGwCG
hgIA
--=-=-=--

\start
Date: Sun, 27 May 2007 22:32:12 +0200
From: Ralf Hemmecke
To: Stephen Wilson
Subject: Re: backslash-newline in Makefiles.

> For convinience, attached is a patch against current Silver.

What is the "current Silver"??? Where is it? On Sourceforge?

\start
Date: 27 May 2007 17:08:56 -0400
From: Stephen Wilson
To: Ralf Hemmecke
Subject: Re: backslash-newline in Makefiles.

Hi Ralf,

Ralf Hemmecke writes:
> > For convinience, attached is a patch against current Silver.
> 
> What is the "current Silver"??? Where is it? On Sourceforge?

The current Silver is a git repo on axiom-developer, and an svn repo
on Sourceforge.  Tim gave the details here:

  http://lists.gnu.org/archive/html/axiom-developer/2007-05/msg00260.html

\start
Date: 27 May 2007 16:34:20 -0500
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: backslash-newline in Makefiles.

Stephen Wilson writes:

| Now on the Axisp branch:
|    swilson@axiomdeveloper.org:/home/swilson/axisp
| 
|    commit 68ee822219e707ea366fa877e0a99ae8b45c4dc1
| 
| Remove backslash-newline sequences from single-quoted strings in
| makefiles.

I may be wrong but believe those are solved problems in
Axiom.build-improvements, Axiom.wh-sandbox, and Axiom.gdr-sandbox.  

It is nice to see them solved again.

\start
Date: 27 May 2007 17:41:57 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: backslash-newline in Makefiles.

Gabriel Dos Reis writes:
> Stephen Wilson writes:
> 
> | Now on the Axisp branch:
> |    swilson@axiomdeveloper.org:/home/swilson/axisp
> | 
> |    commit 68ee822219e707ea366fa877e0a99ae8b45c4dc1
> | 
> | Remove backslash-newline sequences from single-quoted strings in
> | makefiles.
> 
> I may be wrong but believe those are solved problems in
> Axiom.build-improvements, Axiom.wh-sandbox, and Axiom.gdr-sandbox.  
> 
> It is nice to see them solved again.

I know that.

The issue is simple.  I am not interested in building off of
build-improvments or wh-sandbox.  I am basing my work off of silver.
When I have an improvment to silver, I'll post it and hope that it
gets included.  If not, I'll discover why and do my best to make the
patch acceptable.

I looked first at wh-sandbox and build-improvments to see if I could
cherry-pick the changes which were required.  This appeared to be more
work than the rout I took.

It is not one of my priorities to merge build-improvments or
wh-sandbox with silver.

\start
Date: Sun, 27 May 2007 14:43:04 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: ISSAC papers/presentations?

Gaby, after checking the ISSAC 2007 page and seeing the registration
fees, I fear non-student, non-ACM/SIG, un-funded me will not be
attending after all :-(.

I don't know what the copyright restrictions are on ISSAC submitted
papers and presentations, but will you be able to make your work
available outside of ISSAC proper for those of us in the peanut
gallery?  Can anyone videotape the talk for online use?

\start
Date: Sun, 27 May 2007 16:48:49 -0500
From: Tim Daly
To: list
Subject: back

my, my, my, it has been a busy week here. --Tim

\start
Date: Sun, 27 May 2007 16:50:34 -0500
From: Tim Daly
To: Stephen Wilson
Subject: back

Steve,

Thanks for the patch. 

I see from the mail that you've put up a git.
Is your patch there? Can I pull from it?

\start
Date: 27 May 2007 17:56:05 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: back

Tim Daly writes:

> Steve,
> 
> Thanks for the patch. 
> 
> I see from the mail that you've put up a git.
> Is your patch there? Can I pull from it?
> 
> Tim

Yes, the patch is there. git-pull should give you the posted patch and
that alone. Please let me know if it works out.

\start
Date: Sun, 27 May 2007 18:11:20 -0400
From: Bill Page
To: Stephen Wilson
Subject: RE: backslash-newline in Makefiles.
Cc: Gabriel Dos Reis

Stephen,

On May 27, 2007 5:42 PM you wrote:
> 
> Gabriel Dos Reis writes:
> > Stephen Wilson writes:
> > 
> > | Now on the Axisp branch:
> > |    swilson@axiomdeveloper.org:/home/swilson/axisp
> > | 
> > |    commit 68ee822219e707ea366fa877e0a99ae8b45c4dc1
> > | 
> > | Remove backslash-newline sequences from single-quoted
> > | strings in makefiles.
> > 
> > I may be wrong but believe those are solved problems in
> > Axiom.build-improvements, Axiom.wh-sandbox, and
> > Axiom.gdr-sandbox.  
> > 
> > It is nice to see them solved again.
> 
> I know that.
> ... 

Of course this is a rather trivial instance and I don't think
anyone means to overly sensitive to the issue but I do think
it would be most curteous to make such remarks at the time of
posting a patch and to refer to such earlier work if at all
possible. It is often unpleasant to see work being re-done
without any attribution.

> 
> I looked first at wh-sandbox and build-improvments to see if
> I could cherry-pick the changes which were required.  This
> appeared to be more work than the rout I took.
>

What problems did you encounter when trying to cherry-pick?

> It is not one of my priorities to merge build-improvments or
> wh-sandbox with silver.
> 

Given the current fractious sitation, I think we need to guard
against making it worse. It is Tim's stated intention to continue
to merge build-improvements into Silver.

\start
Date: 27 May 2007 18:28:55 -0400
From: Stephen Wilson
To: Bill Page
Subject: Re: backslash-newline in Makefiles.
Cc: Gabriel Dos Reis

Bill Page writes:

> Stephen,
> 
> On May 27, 2007 5:42 PM you wrote:
> > 
> > Gabriel Dos Reis writes:
> > > Stephen Wilson writes:
> > > 
> > > | Now on the Axisp branch:
> > > |    swilson@axiomdeveloper.org:/home/swilson/axisp
> > > | 
> > > |    commit 68ee822219e707ea366fa877e0a99ae8b45c4dc1
> > > | 
> > > | Remove backslash-newline sequences from single-quoted
> > > | strings in makefiles.
> > > 
> > > I may be wrong but believe those are solved problems in
> > > Axiom.build-improvements, Axiom.wh-sandbox, and
> > > Axiom.gdr-sandbox.  
> > > 
> > > It is nice to see them solved again.
> > 
> > I know that.
> > ... 
> 
> Of course this is a rather trivial instance and I don't think
> anyone means to overly sensitive to the issue but I do think
> it would be most curteous to make such remarks at the time of
> posting a patch and to refer to such earlier work if at all
> possible. It is often unpleasant to see work being re-done
> without any attribution.

The issue of attribution did not strike me.  I upgraded my tool-chain
last night, built silver, and noticed the build failed.  I figured out
what was wrong and explored possibilities.  I ended up just making the
required changes myself.

To be honest, Im not interested in trying to keep track of
build-improvments and wh-sandbox and ....

I am interested in silver, since if one thing is clear silver is the
`staging ground' for inclusion in gold.  As silver evolves I will most
happily pull and incorperate said changes in my working tree.


> 
> > 
> > I looked first at wh-sandbox and build-improvments to see if I
> > could cherry-pick the changes which were required.  This appeared
> > to be more work than the rout I took.
> >
> 
> What problems did you encounter when trying to cherry-pick?

I have not invested any real time into understanding the other
branches.  The _specific_ issue which my patch resolves did not appear
to be (from my perspective) handled by even a small handfull of
commits to those branches.  There is a lot of new machinery and
restructuring to the build system there.

It was far simpler for me to post a patch against silver then to
destructure the history of wh-sandbox and build-improvments in the
hopes of obtaining a clean patch.

> 
> > It is not one of my priorities to merge build-improvments or
> > wh-sandbox with silver.
> > 
> 
> Given the current fractious sitation, I think we need to guard
> against making it worse. It is Tim's stated intention to continue
> to merge build-improvements into Silver.

This does not make anything worse.  Im just posting a patch against
silver.  Whats the big deal?

\start
Date: Sun, 27 May 2007 17:33:47 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: backslash-newline in Makefiles.

On Sun, 27 May 2007, Stephen Wilson wrote:

| The issue is simple.  I am not interested in building off of
| build-improvments or wh-sandbox. 

By no means I intended to imply you should do otherwise.

[...]

| It is not one of my priorities to merge build-improvments or
| wh-sandbox with silver.

I would have been surprised if it were different.

\start
Date: Sun, 27 May 2007 17:36:08 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: backslash-newline in Makefiles.

On Sun, 27 May 2007, Bill Page wrote:

[...]

|           It is often unpleasant to see work being re-done
| without any attribution.

I'm not unpleasantly surprised at all.  This is Axiom.

\start
Date: Sun, 27 May 2007 17:39:51 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: backslash-newline in Makefiles.

On Sun, 27 May 2007, Stephen Wilson wrote:

[...]

| This does not make anything worse.  Im just posting a patch against
| silver.  Whats the big deal?

I don't think there is a big.  Your patches are most welcome, and I do hope
they eventually get included.

This is Axiom.  The goal is to redo everything, especially known and solved
problems. We have about 25 years left for that.

\start
Date: 27 May 2007 18:42:36 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: backslash-newline in Makefiles.

Gabriel Dos Reis writes:

> On Sun, 27 May 2007, Stephen Wilson wrote:
> 
> [...]
> 
> | This does not make anything worse.  Im just posting a patch against
> | silver.  Whats the big deal?
> 
> I don't think there is a big.  Your patches are most welcome, and I do hope
> they eventually get included.

Thanks.

> 
> This is Axiom.  The goal is to redo everything, especially known and solved
> problems. We have about 25 years left for that.

If this problem is solved, why does silver not reflect that?

My hope is that it will any minute now.

\start
Date: Sun, 27 May 2007 17:43:30 -0500
From: Tim Daly
To: list
Subject: bachslash-newline in Makefiles

Ah, controvery. Sigh.

I did a diff -r --brief axiom-gold-50 build-improvements and
the same with wh-sandbox. For each file that differed I tried
to (a) decide why the change was made, (b) how it was related
to other changes in the branch, (c) how it was related to the
original gold version, and (d) how it could be merged so that
the silver version files and the branch version files differed
as little as possible.

Those changes that I understood I picked up and merged into 
the new "silver" branch. 

Those changes I did not understand (e.g. algebra changes), or those
changes which I am not capable of merging (e.g. the new Makefile
structure) were left unmerged.

The silver version would not build so I worked out two mechanisms to
try to discover what was missing and/or wrong. These two new
mechanisms, regression testing (regress.lisp) and the md5sum hashing
(src/regress/REGRESS) were added to silver. These were used to debug
the build.

Once that completed I added changes of my own, mostly documentation,
to the silver branch (quat.spad.pamphlet).

Once that completed I extracted the git build, made an SVN copy,
and posted both copies as "silver", along with a commitment to
maintain these two copies in parallel.

Future updates to "silver" will be complete changesets. 
The philosophy will be to try to "box up" a change so that it
can be added or removed as a whole, which as far as I can tell
is the whole reason for changesets.

When the silver version is "ready" (for some random notion of
ready) I will post it to Arch on axiom-developer, CVS on sourceforge,
and CVS on savannah as --patch-51.

I am currently working a few different branches in parallel (very
easy with git) and as these are tested and complete I will post them
as full changesets. People using git should be able to do a git-pull.
SVN users should be able to apply the change as a single changeset.

Mostly I'm trying to fix outstanding bug reports (e.g. I'm working
on downcasing filenames everywhere).

\start
Date: Sun, 27 May 2007 17:45:15 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: backslash-newline in Makefiles.

On Sun, 27 May 2007, Stephen Wilson wrote:

| > This is Axiom.  The goal is to redo everything, especially known and solved
| > problems. We have about 25 years left for that.
| 
| If this problem is solved, why does silver not reflect that?

This is Axiom.

\start
Date: Sun, 27 May 2007 17:49:39 -0500
From: Tim Daly
To: list
Subject: bachslash-newline in Makefiles

re: Stephen's patch

A moment's thought will convince you that Stephen's patch is NOT
a rework of an existing patch since the Makefiles are nowhere the same.
Thus, since the idea was not previously posted as a diff-Naur to Gold
it is NOT rework or cherry-picking.

\start
Date: Sun, 27 May 2007 16:00:37 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis, Stephen Wilson
Subject: Re: backslash-newline in Makefiles.

--- Gabriel Dos Reis wrote:
> 
> This is Axiom.  The goal is to redo everything, especially known and
> solved problems. We have about 25 years left for that.

I would rather phrase it as the goal is to implement the solutions to
problems (known or unknown) in a fashion such that the need to
re-implement them again is not foreseeable.  Hence literate
programming, for example.

That does involve a lot of already-trampled ground.  The framework
isn't firm enough yet to result in a consensus direction, but this
doesn't bother me - we will sort it out and move forward.

I, at least, appreciate and thank everyone doing work on the codebase. 
Even if it is duplicate work at times, at least people are learning the
codebase!  Disinterest is more fatal to a project than any
disorganization could ever be - apathy is by far the most fatal disease
we could catch.

\start
Date: 27 May 2007 19:29:03 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: bachslash-newline in Makefiles

Tim Daly writes:
> Future updates to "silver" will be complete changesets. 
> The philosophy will be to try to "box up" a change so that it
> can be added or removed as a whole, which as far as I can tell
> is the whole reason for changesets.

I am curious about this point.

Does the patch I resently posted qualify as a complete changeset?

Changesets are tough to define with foresight.  I posted when I knew
the specific problem I was trying to solve was finalized.  This
qualifies in my mind as a changeset. I hope it is sufficient (modulo
any problems others discover) for inclusion in silver.

\start
Date: Sun, 27 May 2007 18:32:57 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: backslash-newline in Makefiles.

On Sun, 27 May 2007, C Y wrote:

|         !  Disinterest is more fatal to a project than any
| disorganization could ever be

Indeed.  

And disinterest is lurking around when no forward move or progress is being
made. 

\start
Date: 27 May 2007 18:44:54 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: bachslash-newline in Makefiles

Tim Daly writes:

[...]

| Those changes that I understood I picked up and merged into 
| the new "silver" branch. 

One aspect of a VCS such as SVN or GIT is that when someone
picks a change, it will pick it from a version number that controls
the whole branch.  In a community effort, it helps people identify
which changes have been picked; in particular, change logs also help
speed up the archeology exercise.  

In the particular instance of new silver, the said branch has
been carefully engineered to make both revision numbers (to help track
down the actual changes) and the ChangeLogs have been side-stepped, to
make the whole exercise more interesting.  In the interest of
community effort. 

[...]

| I am currently working a few different branches in parallel (very
| easy with git)

branching is easy with SVN too, but I suspect that was not the point.

| and as these are tested and complete I will post them
| as full changesets. People using git should be able to do a git-pull.
| SVN users should be able to apply the change as a single changeset.

\start
Date: 27 May 2007 18:49:37 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: ISSAC papers/presentations?

Cliff Yapp writes:

| Gaby, after checking the ISSAC 2007 page and seeing the registration
| fees, I fear non-student, non-ACM/SIG, un-funded me will not be
| attending after all :-(.

:-(

| I don't know what the copyright restrictions are on ISSAC submitted
| papers and presentations, but will you be able to make your work
| available outside of ISSAC proper for those of us in the peanut
| gallery?  

The ACM copyright gives an outlet for authors to have a copy of their
work (under the appropriate copright notice) on their websites.  

It is also our intent to make the library available to the Axiom
community -- it will be up to the powers be to decide whether they
want it in the Axiom standard distribution or not.  

\start
Date: 27 May 2007 18:53:09 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: bachslash-newline in Makefiles

Tim Daly writes:

| re: Stephen's patch
| 
| A moment's thought will convince you that Stephen's patch is NOT
| a rework of an existing patch since the Makefiles are nowhere the same.
| Thus, since the idea was not previously posted as a diff-Naur to Gold
| it is NOT rework or cherry-picking.

Indeed.  diff-Naur against Gold is the certificate of idea ownership.

Now, to make this completely clear, I don't think I own any idea
here.  This problem was noticed a long time ago and was solved
collaboratively by various people including Ralf, Bill, Waldek, Jacob,
and me.  

\start
Date: Thu, 24 May 2007 13:15:51 +0200
From: Henri Lesourd
To: list
Subject: Re: [Texmacs-dev] Lisp/TeX/TeXmacs was: re: gcl, shared libraries

Ralf Hemmecke wrote:

> TeX is admittedly a strange language, but I don't think that that 
> TeXmacs is any easier.

Honestly, TeX is an horror, you don't even have the possibility to
name local variables, you have only a fixed number of registers,
like in assembly language ! By the way, exactly what TeX is is
an assembly language.

As far as TeXmacs macro language is concerned, I don't know
if it is easier, but at least is a much cleaner and high level language,
which is meant to be as functional as possible (although functional
programming doesn't solves all the problems, but it is another debate).


> I've browsed through the documentation yesterday, and I was a little 
> surprised to find out that the style language of TeXmacs is not Scheme 
> (basically it is, but with a few differences). Yet another reason why 
> TeXmacs is not well accepted by the community. It is simply too hard 
> to have your old knowledge in your head (by which you can do things in 
> LaTeX (maybe not the Wysiwyg/m way)) and you would have to find the 
> appropriate commands in the TeXmacs manual. Often guessing just works, 
> but if not, you are stuck and that is more than frustrating.
> (Just my recent experiences with TeXmacs.)
>
> To be more precise. I wanted to define some TeXmacs macros as they are 
> described in the manual (Help->Manual->Writing your own style files).
>
> Entering
>
> <assign|hello|<macro|name|Hello <person|<arg|name>>!>>
>
> as it is described there nearly drove me crazy. I did not get the 
> "person" macro entered as it was described just below that box.
> (Even if I am to stupid to read clearly and follow the manual, I find 
> it quite hard to learn the "new" way. And that is frustrating. :-(  )
>
What you need is perhaps a more focussed and user-friendly kind
of documentation. You should at least try:
http://www.ags.uni-sb.de/~henri/texmacs/aTeXmacsTutorial.pdf

, all the people who used this as an introduction to TeXmacs programming
learned very quickly what needs to be known (the point is : the number
of things to know is *small*).


> Hello TeXmacs, developers. I am certainly not the most usual user, so 
> you probably can ignore my comments. But I actually intended to add 
> (or help to add) some literate programming support to TeXmacs. My 
> experience from yesterday night really let's me think twice about 
> whether I should invest my time into TeXmacs. There is so many things 
> to do (LP support, syntax highlighting, indentation support, 
> (automatic hyperlinking between source files, I haven't yet seen a 
> "back" button so that I could use TeXmacs as a source code browser) 
> and I find it overly hard to achieve something myself in a reasonable 
> amount of time.
>
You should first give a try to the tutorial above : although
it remains incomplete, it has exactly been written for solving
the kinds of learning problem you are describing now.

\start
Date: Mon, 28 May 2007 01:28:19 +0200
From: Markus Cozowicz
To: Bill Page
Subject: RE: Axiom on MediaWiki - Graphics

I couldn't find anything on how to set the PostScript output file
interactively (=w/o the ui).

Any hints? It doesn't have to be returned through the pipe, as I need to
run convert anyway.

\start
Date: Mon, 28 May 2007 01:04:19 +0200
From: Markus Cozowicz
To: Bill Page
Subject: RE: Axiom on MediaWiki (was: Axiom)

I'm filtering the commands you provided to improve security. I don't
perform chroot and still use the apache user (too much work).
I improved the Latex a little.

For installation or linking please use
http://www.mediawiki.org/wiki/Extension:Axiom .

I tested http://wiki.axiom-developer.org/VeryLongLaTeX and all of them
work.
I'm not really sure how to do formula line breaking - is there a latex
option I could insert at the beginning?

If you want to provide any Latex tests please edit
http://www.eisber.net/StatWiki/index.php/Axiom - it would be nice if you
register, so I know you added it.

I'll try graphics right now.

-----Original Message-----

Markus,

Thank you very much for this initial work! I think it is very
promising.

On May 27, 2007 12:19 PM Markus Cozowicz wrote:
>
> I found some time on the weekend to work on it.
>
> Have a look at http://www.eisber.net/StatWiki/index.php/Temp
>
> I'm actually reusing <math>-tag from MediaWiki, which has
> limited Latex support. Thus I have to do some conversions and
> stripping. I don't think full support of all Latex outputted
> by Axiom is possible, but to get a reasonable amount, I'd have
> to go through some more samples.
>
> Some questions:
>
> - Do you have list of functions that impose security problems?

There are at least two classes of operations that potentially
pose security threats when running Axiom pubicly online. One
is the

  )system ...

command which permits the user to open access to all system
commands. The 2nd entry point is via Lisp which can be
invoked either as a commands such as

  )lisp

and

  )fin

of via a function call like this

  (SI_:_:SYSTEM "...")$Lisp

Both of these leave the system wide open. Unfortunately both
of them also have potentially quite valid uses. I think it
fair to say that the developers of Axiom have given almost
no thought at all to the need for security since the standard
model is to have Axiom running only locally on you desktop.

If you are concerned about security (I don't it take for
granted that you necessarily need to be, given our experience
over the last three years at axiom-developer.org), then I
would highly recommend that first of all you should run Axiom
in a chroot environment.

> - Do you have testcases for Latex output?
>

No, I am sorry that we do not have such official test cases.
I would be glad to develop these with you.

We have however documented some problem cases on the Axiom
Wiki. E.g.

http://wiki.axiom-developer.org/VeryLongLaTeX

> I saw that you support graphics too with postscript output.

Axiom can generate graphics with postscript output if it
is run in an X-windows environment. This is possible even
on a headless server by installing the virtual framebuffer
driver Xfbdev and the xvfb-run, although I have had some
trouble interacting with this configuration via a pipe. I
think to do this successfully requires pty support and
something like pexpect.

Right now we do cannot automatically generate graphics for
inclusion in the Axiom Wiki.

See some sparse notes here:

http://wiki.axiom-developer.org/SummerOfCode
http://wiki.axiom-developer.org/GraphicsOnMathAction

> The R-plugin for media wiki already does postscript to png
> conversion for R graphics...
> It shouldn't be too hard to adapt that for Axiom.
>

Great!

Regards,
Bill Page.

>
> -----Original Message-----
> From: Bill Page [mailto:Bill Page]
> Sent: Dienstag, 10. April 2007 03:08
> To: Markus Cozowicz
> Cc: 'Axiom-Developer'
> Subject: Axiom on MediaWiki (was: Axiom)
>
> Markus,
>
> I hope you do not mind that I am copying this to the Axiom
> developer mailing list. I think there may be some other
> people here who are interested in this subject.
>
> On April 9, 2007 6:43 PM Markus Cozowicz wrote:
>
> > I'm actually trying to integrate Axiom into MediaWiki. I'm
> > using it to write my statistics homework (www.eisber.net/StatWiki).
>
> Well, I thinks that's a pretty ambitious project just to do
> your homework! :-) But I think this is interesting for much
> more than that.
>
> > MediaWiki is written in PHP.
>
> Yes. Very famous. It is the wiki software behind Wikipedia.
> I think it is a very good choice (except for PHP, but that's
> a different story).
>
> > I'm not sure if I actually want to properly interface with
> > Axiom, as I'm only interested in the generated latex, that
> > needs to be piped into texvc (yet another binary - the latex
> > interface used in MediaWiki).
>
> I don't know what you mean exactly by "properly interface with
> Axiom". Axiom can generate LaTeX output for the results that it
> calculates. I assume that if you are interested in Axiom, you
> are also interested in symbolic computer algebra in some form
> or other - otherwise I don't see much point in using Axiom just
> to generate LaTeX output. I think you would find it rather
> awkward if that was all you wanted it to do.
>
> I suppose that you are familiar with the Axiom Wiki web site:
> http://wiki.axiom-developer.org
> If you are using Axiom for statistics - even if it is just for
> a course - then you are certainly welcome to use this web site
> (which is publically available) or it's sister portal site:
> http://portal.axiom-developer.org
> where you can log-in and control who gets access to the pages
> you prepare. We are always interested in more examples of
> applications where Axiom can be used. Your exercises might
> help other people realize how Axiom can be used in their
> own situation.
>
> As you can discover from the wiki site, these web sites are
> based on Zwiki, Zope and Python - quite different from most
> PHP applications although they accomplish mostly the same
> thing in the end.
>
> If you are more interested in continuing the development of
> a general purpose MediaWiki plug-in that allows MediaWiki to
> send commands to Axiom and display the results on a wiki page
> in nicely LaTeX typeset form, then as an Axiom developer I am
> very interested in that. I would very much like to be able to
> offer such an interface for Axiom to other MediaWiki users.
> So I would be glad to help you with this.
>
> > Can I disabled shell execution in Axiom? Because for security
> > reason, I probably don't want anybody to execute arbitrary
> > code on my server.
>
> Axiom is not designed with this kind of security in mind, but
> in the PHP interface to Axiom, it would be possible to intercept
> commands which might execute arbitrary code and still leave a
> significant subset of Axiom available to the user. If malicous
> code is a serious risk, I think the best option would be to run
> Axiom in a chroot environment or perhaps on a separate virtual
> machine using Xen or other VM tool.

\start
Date: Sun, 27 May 2007 20:28:46 -0500
From: Tim Daly
To: Stephen Wilson
Subject: backslash-newline in Makefiles

Stephen,

The git-pull isn't answering the page so I suspect something is 
misconfigured as I can git-pull silver. I'll have to look into that.

In the meantime I'll use your posted diff.

re: your changes

Yes, they are what I'd consider a changeset. They address one 
particular problem that affects several files as one distinct
conceptual change.

\start
Date: 27 May 2007 21:44:15 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: backslash-newline in Makefiles

Tim Daly writes:

> Stephen,
>
> The git-pull isn't answering the page so I suspect something is
> misconfigured as I can git-pull silver. I'll have to look into that.

Strange.  I coppied a local tree of silver and, logging in as user git to
assure myself that others have access:

  steve:silver> git-pull ssh://git@axiom-developer.org/home/swilson/axisp
  git@axiom-developer.org's password:
  git@axiom-developer.org's password:
  remote: Generating pack...
  remote: Done counting 17 objects.
  remote: Result has 10 objects.
  remote: Deltifying 10 objects.
  remote:  100% (10/10) done
  Unpacking 10 objects
  remote: Total 10, written 10 (delta 6), reused 0 (delta 0)

  Updating a234de3..68ee822
  Fast forward
   CHANGELOG                    |    1 +
   lsp/Makefile.pamphlet        |    6 +-
   src/boot/Makefile.pamphlet   |  132 ++--
   src/interp/Makefile.pamphlet | 1638 +++++++++++++++++++++---------------------
   4 files changed, 889 insertions(+), 888 deletions(-)

So from my end it looks like eveything is OK.

Please let me know if there is anything I can do.  Pulling a patch
should be painless.

> In the meantime I'll use your posted diff.

Ok.

>
> re: your changes
>
> Yes, they are what I'd consider a changeset. They address one
> particular problem that affects several files as one distinct
> conceptual change.

\start
Date: Sun, 27 May 2007 21:23:32 -0500
From: git@axiom-developer.org
To: Tim Daly
Subject: Axiom silver branch: Changes to 'master'

 CHANGELOG                    |    1 +
 lsp/Makefile.pamphlet        |    6 +-
 src/boot/Makefile.pamphlet   |  132 ++--
 src/interp/Makefile.pamphlet | 1638 +++++++++++++++++++++---------------------
 4 files changed, 889 insertions(+), 888 deletions(-)

New commits:
commit 09566b0d7471489e2c12063f99867d250097dcab
Author: Stephen Wilson
Date:   Sun May 27 14:05:16 2007 -0400

    Remove backslash-newline sequences from single-quoted strings in
    
    makefiles.
    
    The makefiles broke with GNU Make 3.81. From make-3.81/Changelog:
    
    * WARNING: Backward-incompatibility!
      In order to comply with POSIX, the way in which GNU make processes
      backslash-newline sequences in command strings has changed.  If your
      makefiles use backslash-newline sequences inside of single-quoted
      strings in command scripts you will be impacted by this change.  See
      the GNU make manual subsection "Splitting Command Lines" (node
      "Splitting Lines"), in section "Command Syntax", chapter "Writing the
      Commands in Rules", for details.
\start
Date: Sun, 27 May 2007 21:24:55 -0500
From: Tim Daly
To: Stephen Wilson
Subject: backslash-newline in Makefiles

Stephen,

I used your posted diff for the Make newline problem.

The changeset has been applied.
The commit is done to git and SVN.

\start
Date: 27 May 2007 21:33:04 -0500
From: Gabriel Dos Reis
To: git@axiom-developer.org
Subject: Re: Axiom silver branch: Changes to 'master'

git@axiom-developer.org writes:

|  CHANGELOG                    |    1 +
|  lsp/Makefile.pamphlet        |    6 +-
|  src/boot/Makefile.pamphlet   |  132 ++--
|  src/interp/Makefile.pamphlet | 1638 +++++++++++++++++++++---------------------

Tim --
  Please could set up the git commit message so that it goes to
axiom-commit@sf.net?  

\start
Date: Sun, 27 May 2007 21:42:52 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Axiom silver branch: Changes to 'master'

> Please could you set up the git commit message so that it goes to
>axiom-commit@sf.net

done --t

\start
Date: Sun, 27 May 2007 21:47:39 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom silver branch: Changes to 'master'

On Sun, 27 May 2007, Tim Daly wrote:

| > Please could you set up the git commit message so that it goes to
| >axiom-commit@sf.net
| 
| done --t

Thanks!

\start
Date: Sun, 27 May 2007 21:48:29 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Re: backslash-newline in Makefiles

Stephen,

The git-pull worked fine as you typed it.
I had a typo in my command line.

We should be able to do git-pulls from now on which will greatly
simplify the task.

\start
Date: 27 May 2007 21:49:24 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom silver branch: Changes to 'master'

Tim Daly writes:

| > Please could you set up the git commit message so that it goes to
| >axiom-commit@sf.net
                ^

Oops: I should have said:

  axiom-commit@lists.sf.net
               ^^^^^
\start
Date: 27 May 2007 23:03:26 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: backslash-newline in Makefiles

Tim Daly writes:

> Stephen,
> 
> I used your posted diff for the Make newline problem.
> 
> The changeset has been applied.
> The commit is done to git and SVN.

This is great news.  Many thanks.

> 
> Thanks,
> Tim

\start
Date: Sun, 27 May 2007 23:14:18 -0400
From: Bill Page
To: Stephen Wilson
Subject: RE: wiki AxiomSources page

Steve,

On May 27, 2007 9:04 PM you wrote:
> 
> I was interested in updating the AxiomSources page on the wiki
> following Cliff's recent concerns:
>   

http://lists.gnu.org/archive/html/axiom-developer/2007-05/msg00449.html

As a result of this email I suggested that Cliff might be interested
in making these changes himself. He agreed, so I assigned him a user
id and password that allows him complete access to the Axiom Wiki
website and in particular allows him to bypass the restrictions in
place to help prevent spam (a limit on the number of links allowed
by posters). But so far he has not made these changes.

> I wanted to remove the reference to the TLA branch axiom-language-1
> but it would seem that administrative privliges are required.  

You need a user id and password assigned that allows you to bypass
the spam restrictions. I would be very glad to assign such a user
id and password for you. Please send me the user id and initial
password that you would like me to assign by private email.

> Could you delete the reference to axiom-language-1?

I would be very pleased if either you or Cliff or anyone else with
full access to the wiki would make these changes. If for some reason
you cannot, please let me know and I will do it for you.

> I would also be interested in populating a page outlining some
> of the goals of my new Axisp branch.  IIRC (I am a newbie when
> it comes to the wiki), one can create a page by embedding a
> reference in an extant page.

On a wiki anyone can create a new page simply by inserting a new
wiki page name, i.e. a word containing more than one capital letter,
or a phrase enclosed in brackets [like this], while editing an
existing page or when entering a comment.  If a page with that
name already exists, a link to that page will be created. Otherwise
the name will be displayed on the page with a blue question mark.
Clicking on the blue quesition mark allows you to create a new
page with that name.

> Would you be so kind as to make a link to an Axisp page from
> AxiomSources?

Yes I would be glad to do this if absolutely necessary but I
would much prefer for you to be able to do it yourself.

\start
Date: 27 May 2007 23:26:07 -0400
From: Stephen Wilson
To: Bill Page
Subject: Re: wiki AxiomSources page

Bill Page writes:
> You need a user id and password assigned that allows you to bypass
> the spam restrictions. I would be very glad to assign such a user
> id and password for you. Please send me the user id and initial
> password that you would like me to assign by private email.

Ok absolutely.

> > Would you be so kind as to make a link to an Axisp page from
> > AxiomSources?
> 
> Yes I would be glad to do this if absolutely necessary but I
> would much prefer for you to be able to do it yourself.

Yes, I would be glad to do it myself.  Thanks for offering the access!

\start
Date: Sun, 27 May 2007 22:28:59 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Axiom silver branch: Changes to 'master'

Gaby,

> axiom-commit@lists.sf.net
>              ^^^^^

fixed. --t

\start
Date: Sun, 27 May 2007 22:45:57 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Axiom silver branch: Changes to 'master'

Gaby,

I made a commit that simply adds some explicit lines to the
CHANGELOG to document the particular files touched so we can
see if the new changes are showing up on the sourceforge list.

\start
Date: Sun, 27 May 2007 22:51:28 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom silver branch: Changes to 'master'

On Sun, 27 May 2007, Tim Daly wrote:

| Gaby,
| 
| I made a commit that simply adds some explicit lines to the
| CHANGELOG to document the particular files touched so we can
| see if the new changes are showing up on the sourceforge list.

It looks to me as if they are showing up.

soliton[22:47]% svk update -s                                 ~/src/Axiom/daly
Syncing https://axiom.svn.sourceforge.net/svnroot/axiom
Retrieving log information from 574 to 575
Committed revision 21169 from revision 574.
Committed revision 21170 from revision 575.
Syncing /mirror/axiom/branches/daly(/axiom/branches/daly) in /home/gdr/src/Axiom/daly to 21170.
U   axiom/CHANGELOG
U   axiom/src/interp/Makefile.pamphlet
U   axiom/src/boot/Makefile.pamphlet
U   axiom/lsp/Makefile.pamphlet
soliton[22:47]% head axiom/CHANGELOG                          ~/src/Axiom/daly
20070527 sxw lsp/Makefile Fix backslash-newline
20070527 sxw src/boot/Makefile Fix backslash-newline
20070527 sxw src/interp/Makefile Fix backslash-newline
20070527 sxw Fix backslash-newline in single-quote makefile strings.
20070522 tpd CHANGELOG move wxh entries to gdr where requested
20070521 tpd src/doc/book.pamphlet fix typos (but #89)
20070521 tpd src/algebra/Lattice removed
20070521 tpd src/regress/REGRESS recover correct script
20070521 tpd -- git/svn silver alpha
20070518 tpd src/interp/sys-pkg.lisp import VMLISP::AXIOM-PROBE-FILE
You have new mail.                                                       

\start
Date: Sun, 27 May 2007 23:41:16 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Which source distributions should we list?

Ralf,

> Which source distributions should we list?

I believe we should list them all. Each developer has a choice of the
source code control mechanism that fits his needs and interests.  Gaby
and Waldek seem to like SVN. Bill likes Darcs. The silver version uses
SVN/git. The main gold version will continue using the ARCH/CVS tools.

The only "end-user visible" systems should be the ARCH/CVS versions.

> I still don't see a good structure. 

A good structure is related to your style of code development.  Which
system do you use to maintain ALLPROSE? I haven't seen a branch off
any of the existing systems but I'm assuming you chose one.

Having used half a dozen systems (SCCS, SourceSafe, RCS, Arch, CVS,
SVN) in the past I can safely say that git is my choice. 

I won't even bother to list the many reasons except to say that it
has completely changed the way I work and the way I think about how
to develop. Only Lisp and Emacs have had a similar profound impact.

I know these things border on religion and we really don't need
any more debate about it. Choose your system. Use it. As long as
the changes get diffed against Gold it doesn't really matter.



re: PATCHES

> I somehow don't like to create and sent patches.

The stated practice of the project at the moment is to post
diff -Naur patch files which are accepted by all the systems
and easily manipulated. It's not hard; given a change type:

diff -Naur originalFile changedFile >originalFile.patch

and post the resulting originalFile.patch.

Just be sure that the originalFile is the one from Gold or
silver so that everyone has a baseline from which to start.
Otherwise you run the risk of changes that not everyone can
apply to their system. This is precisely the problem that 
touched off the Makefile newline debate.

Linux lived and grew using this method despite having hundreds
of developers using many different systems. It is suboptimal
but it works everywhere.

\start
Date: Sun, 27 May 2007 21:41:04 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Stephen Wilson
Subject: RE: wiki AxiomSources page

--- Bill Page wrote:

> But so far he has not made these changes.

I apologize for this - I am traveling this weekend and have not had the
chance to do it.  I will take care of it when I get back.

\start
Date: Sun, 27 May 2007 21:50:12 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Ralf Hemmecke
Subject: re: Which source distributions should we list?

--- Tim Daly wrote:
> 
> I believe we should list them all. Each developer has a choice of the
> source code control mechanism that fits his needs and interests. 
> Gaby and Waldek seem to like SVN. Bill likes Darcs. The silver
version
> uses SVN/git. The main gold version will continue using the ARCH/CVS
> tools.
> 
> The only "end-user visible" systems should be the ARCH/CVS versions.

Erm.  It may be a good thing I didn't change AxiomSources.  I was under
the impression we were going to the following for "official" use:

Silver:  GIT/svn
Gold:  CVS

ARCH, as I understand it, is not really undergoing active development
any more.  I think in such a case we should not encourage active work
in that tool.  If we want an alternative to CVS for Gold and we want to
keep SVN for development only, I would suggest adding a GIT repository
for Gold as well.  (Maybe a branch?)

Darcs and Mercurial can stay put as alternatives - Bill is syncing them
to something and they are actively developed tools.  ARCH, however,
seems to have become a bit of a dead end unless I am behind the times. 
Can we at least make a tiered structure:

Tier1:  As above.  The default "public face" for Axiom sources.
Tier2:  "Alternative" methods.  Darcs, Mercurial, etc.
Tier3:  The "archive" page, listing all branches and systems tried with
Axiom.  If anyone gets that far, presumably they know what they are
doing.

\start
Date: Mon, 28 May 2007 00:31:43 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Which source distributions should we list?

Bill,

> I fear that since build-improvements is cloned from the current
> trunk and wh-sandbox is cloned from build-improvements, there
> might be some considerable loss in "mergibility" if we were to
> just "pull the rug out from under them" so as to speak and
> wholesale replace trunk with the contents of the current git
> repository.

Eh? I don't see any reason to change trunk.  Perhaps Waldek can do a
merge back to Gaby's branch.  Then Gaby can do a merge back to trunk.
At that point trunk can be diff-Naur-ed against silver and the changes
ported. Although they are maintained publicly the build-improvements
and wh-sandbox branches are private code branches.

Since both build-improvements and wh-sandbox have large changes from
the original trunk the effort involved can only be done by them. 

I don't understand the fundamental change that was made to the
build system (autoconf). I really need to understand it because
I build it and modify it on a regular basis. The only viable path
will be for Gaby to extract, document, test, and export the
changeset necessary to make this happen. Right now it lives on 
his private branch.

> Anyway as I understand it, right now Tim is manually updating 
> both the git repository on axiom-developer and the "daly" branch
> on SVN in parallel. That does not sound like a particularly
> enlightened approach to me :-( 

No, it's not a particularly enlightened approach. However it is
the "most accommodating" to the needs of the various people. It
does not force any decision (which is not possible anyway). I'm
open to different choices and try to take the middle way. We
started on CVS, expanded onto Arch. We added SVN last year and
I've added git this year. 

It really matters much less than we think since all of these
systems work perfectly well with diff and patch.

> There's got to be a better way, right?

Why? Even Linus has to deal with multiple systems. I understand
that not all of his "lieutenants" use git and that some still
send him tgz files.

\start
Date: Mon, 28 May 2007 00:49:45 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Which source distributions should we list?

Cliff,

> 1. What are the "approved" sources for AxiomGold? I am assuming CVS
> on Savannah and Sourceforge?

The "master" copy lives in Arch on axiom-developer.org.
It is mirrored to CVS on Sourceforge and CVS on Savannah.
The outside, non-developer world seems mostly to be CVS.



> 2. Is the most current tarball still from 2005?

Depends. Where are you looking? We discussed a webpage that had
a matrix of tarballs per platform. I put together such a page but
I don't believe anyone contributed. When this version goes Gold
perhaps we need to concentrate on that.


> 3. Silver is moving from arch to Git ....

There is no need to be concerned because silver is also available
in SVN format on sourceforge.


> 4. About the testing branches listed for GNU Arch....

As far as I know there was no work on those branches that did not
get merged into Gold. Those branches are dead.


> 5. The subversion branches I assume are all still active ....

Build-improvements and wh-sandbox are clearly active. 
Hersen-algebra-improvements might or might not be.

> Does it contain any work not prsent in other branches?

I presume there is an SVN command that can compare them but I'm
not familiar enough with SVN to know. My use of SVN in work goes
thru some windows (tortoise?) tool so I don't know any command
line incantations.

> 6. Darcs and Mercurial obviously will stay.....

Bill likes these tools so clearly they won't go away. 



There is no need to agonize over the various choices. The choice
of source code control depends on your style of working. Choose
one, work with it. Post your diff-Naur changesets. Since this is
a common format that works with everything we can all apply the
changes to our own repositories.

\start
Date: Mon, 28 May 2007 01:11:51 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Which source distributions should we list?

Cliff,

> I was under the impression we were going to the following for
> "official" use:

> Silver: GIT/svn
> Gold: CVS

That's not incorrect, just incomplete.  I'm not sure we need to
mention silver outside the mailing list but that's up to you.




> ARCH .... is not undergoing active development any more.

So? It works. It does what we need it to do, which is not much.
I'm not sure what active development has to do with the issue.

If you don't want to use Arch the exact same sources are available
from CVS on savannah and sourceforge.





> I would suggest adding a GIT repository for Gold as well.

I'm not sure that would be useful. Gold is intended to be very
stable. I'm currently the only person who updates it. There
is no need to move it to git as any "new" work would go into
silver first and go thru a testing cycle.

If you really want to use git (which I encourage) and you want a
git copy of Gold there is a git-arch or git-cvs command to clone it.

\start
Date: Mon, 28 May 2007 11:25:47 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: re: Which source distributions should we list?

>> 3. Silver is moving from arch to Git ....
> 
> There is no need to be concerned because silver is also available
> in SVN format on sourceforge.

And as I understand correctly,

Silver (or silver mirror) = Sourceforge:branches/daly

On sourceforge we have now

branches/
silver/
tags/
trunk/

In order to reduce confusion shouldn't we just remove 
sourceforge:silver? It was created by Bill as a mirror of the tla 
archive axiom--silver--1 at axiom-developer.org. Since Tim now maintains 
Silver on git, the tla archive and the sf:silver directory should go 
away. Bill, could you do this?

>> 4. About the testing branches listed for GNU Arch....

> As far as I know there was no work on those branches that did not
> get merged into Gold. Those branches are dead.

What about removing them from the AxiomSources page?

>> 5. The subversion branches I assume are all still active ....

> Build-improvements and wh-sandbox are clearly active. 
> Hersen-algebra-improvements might or might not be.

Cliff, just update AxiomSources. If I think it is not the way I like it, 
I will modify it. And if it clashes with your opinion we will certainly 
agree on something.

>> 6. Darcs and Mercurial obviously will stay.....
> 
> Bill likes these tools so clearly they won't go away. 

> There is no need to agonize over the various choices. The choice
> of source code control depends on your style of working. Choose
> one, work with it. Post your diff-Naur changesets. Since this is
> a common format that works with everything we can all apply the
> changes to our own repositories.

To be honest, I don't like diff-Naur, if I have a SCM at hand. It sounds 
like washing the dishes by hand though you have a dishwasher.

\start
Date: Mon, 28 May 2007 13:37:54 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: clisp and sbcl

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | CY wrote:
> | > Confirmed - builds on sbcl and clisp.  Wow!  Thanks Waldek!
> | > 
> | > I don't know if it's important, but I am getting a lisp readout when
> | > using the integration package:
> | > 
> | > (2) -> integrate(sin(x),x)
> | > [loading messages]
> | > /home/cyapp/mathtoplevel/axiomtoplevel/testwork/wh-sandbox/target/i686-pc-
> | > linux/algebra/COMPLEX.fasl
> | >       for domain Complex
> | > 
> | > 
> | > ; in: LAMBDA NIL
> | > ;     (VMLISP:QCAR BOOT::|#1|)
> | > ; --> CAR
> | > ; ==>
> | > ;   (THE CONS BOOT::|#1|)
> | > ;
> | > ; caught WARNING:
> | > ;   undefined variable: |#1|
> | > 
> | 
> | AFAICS this comes because Axiom uses eval and sbcl by default
> | compiles all evals.  I am investigating whether the warning
> | indicate some real problem.  One can silence warning switching
> | to interpreted eval (which will be done for different reasons
> | in next revision):
> 
> There is a questionable habit in the Axiom core source code of
> defining variables through SETQ -- that tends to trigger warnings
> from several Lisp implementations.  Is it possible that the above
> is such a warning? (the |#1| are names for synthetized lambdas).
> 

The problem is more subtle: the code above (printed by sbcl)
references |#1|.  Apparently sbcl complier does not see that
|#1| is defined, but it is.  

In more detail, Axiom uses Lisp eval to replace |#1| by aproproate
value.  Relevant part of backtrace is:

17: (SB-INT:SIMPLE-EVAL-IN-LEXENV (EQCAR |#1| 0) #<NULL-LEXENV>)
18: (|evalSharpOne|
     (EQCAR |#1| 0)
     (0 (1 #(#(|cos| 1 (#)) ((# 0 . 1)) 2 4864) (1 0 . -1)) 0 . 1))
19: (|coerceUnion2Branch|
     ((|Union| (|Expression| (|Integer|)) (|List| (|Expression| (|Integer|))))
      WRAPPED 0 (1 #(#(|cos| 1 (#)) ((# 0 . 1)) 2 4864) (1 0 . -1)) 0 . 1))


|evalSharpOne| is defined as:

(defun |evalSharpOne| (x \#1) (declare (special \#1)) (EVAL x))

so at the time of eval |#1| has special binding.  My understanding is
that such bindings are visible to eval.  The '#<NULL-LEXENV>' part
made me suspicious, but testing indicate that in sbcl code works
as expected.  

\start
Date: Mon, 28 May 2007 07:51:36 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: clisp and sbcl

On Mon, 28 May 2007, Waldek Hebisch wrote:

[...]

| The problem is more subtle: the code above (printed by sbcl)
| references |#1|.  Apparently sbcl complier does not see that
| |#1| is defined, but it is.  
| 
| In more detail, Axiom uses Lisp eval to replace |#1| by aproproate
| value.  Relevant part of backtrace is:
| 
| 17: (SB-INT:SIMPLE-EVAL-IN-LEXENV (EQCAR |#1| 0) #<NULL-LEXENV>)
| 18: (|evalSharpOne|
|      (EQCAR |#1| 0)
|      (0 (1 #(#(|cos| 1 (#)) ((# 0 . 1)) 2 4864) (1 0 . -1)) 0 . 1))
| 19: (|coerceUnion2Branch|
|      ((|Union| (|Expression| (|Integer|)) (|List| (|Expression| (|Integer|))))
|       WRAPPED 0 (1 #(#(|cos| 1 (#)) ((# 0 . 1)) 2 4864) (1 0 . -1)) 0 . 1))
| 
| 
| |evalSharpOne| is defined as:
| 
| (defun |evalSharpOne| (x \#1) (declare (special \#1)) (EVAL x))
| 
| so at the time of eval |#1| has special binding.  My understanding is
| that such bindings are visible to eval.

The above shows that |#1| is *declared*.  But whereis it defined?

\start
Date: 28 May 2007 08:10:19 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Which source distributions should we list?
Cc: list

Tim Daly writes:

[...]

| I don't understand the fundamental change that was made to the
| build system (autoconf). I really need to understand it because
| I build it and modify it on a regular basis. The only viable path
| will be for Gaby to extract, document, test, and export the
| changeset necessary to make this happen.

I will.  However, your merges to silver have made the tasks even less
trivial because the changes you picked were not properly tagged.
I tried this week-end, but gave up for when I have more time.

| Right now it lives on his private branch.

It is a community effort branch.  A look at the ChangeLogs will
suffice to convince you that many active people here contribute to it.

\start
Date: Mon, 28 May 2007 15:30:16 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: clisp and sbcl

> On Mon, 28 May 2007, Waldek Hebisch wrote:
> 
> [...]
> 
> | The problem is more subtle: the code above (printed by sbcl)
> | references |#1|.  Apparently sbcl complier does not see that
> | |#1| is defined, but it is.  
> | 
> | In more detail, Axiom uses Lisp eval to replace |#1| by aproproate
> | value.  Relevant part of backtrace is:
> | 
> | 17: (SB-INT:SIMPLE-EVAL-IN-LEXENV (EQCAR |#1| 0) #<NULL-LEXENV>)
> | 18: (|evalSharpOne|
> |      (EQCAR |#1| 0)
> |      (0 (1 #(#(|cos| 1 (#)) ((# 0 . 1)) 2 4864) (1 0 . -1)) 0 . 1))
> | 19: (|coerceUnion2Branch|
> |      ((|Union| (|Expression| (|Integer|)) (|List| (|Expression| (|Integer|))))
> |       WRAPPED 0 (1 #(#(|cos| 1 (#)) ((# 0 . 1)) 2 4864) (1 0 . -1)) 0 . 1))
> | 
> | 
> | |evalSharpOne| is defined as:
> | 
> | (defun |evalSharpOne| (x \#1) (declare (special \#1)) (EVAL x))
> |
                              ^                      ^
                              |                      |
                        definition              declaration

> | so at the time of eval |#1| has special binding.  My understanding is
> | that such bindings are visible to eval.
> 
> The above shows that |#1| is *declared*.  But whereis it defined?
> 

Using parameters to establish special binding is very frequent idiom
in Axiom code.  I guess that from Ansi point of view '(EQCAR |#1| 0)'
may be incorrect, because it lacks special declaration.  Ansi would
like something like:

(defun |evalSharpOne| (x |#1|) (declare (special |#1|))
   (EVAL `(let () (declare (special |#1|) ,x))))

Or maybe:

(defun |evalSharpOne| (x y)
   (EVAL `(let ((|#1| ,y)) ,x)))

The second one does not create special binding, which would be more
tidy if x does not call functions referencing special binding of |#1|.

BTW.  This remaind me of your change replacing global SETQ by DEFPARAMETER.
IIUC 

(defparameter x y)

is equivalent to

(defvar x)
(setf x y)

It looks for me that replacing SETQ by DEFPARAMETER defeats much of the
purpose of DEFPARAMETER/DEFVAR: we silence _all_ warnings about assignments
to undefined variables, loosing them also when variable name is
spelled incorrectly.  I would prefer to have in a _single_ place explicit
DEFVAR/DEFPARAMETER declaration and in all other places use SETQ.

\start
Date: Mon, 28 May 2007 08:32:35 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: clisp and sbcl

On Mon, 28 May 2007, Waldek Hebisch wrote:

| > | |evalSharpOne| is defined as:
| > | 
| > | (defun |evalSharpOne| (x \#1) (declare (special \#1)) (EVAL x))
| > |
|                               ^                      ^
|                               |                      |
|                         definition              declaration

\start
Date: Mon, 28 May 2007 08:46:41 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: clisp and sbcl
Cc: list

On Mon, 28 May 2007, Waldek Hebisch wrote:

| It looks for me that replacing SETQ by DEFPARAMETER defeats much of the
| purpose of DEFPARAMETER/DEFVAR: we silence _all_ warnings about assignments
| to undefined variables, loosing them also when variable name is
| spelled incorrectly.

The replacement was for variable definitions at top level, NOT every use
of SETQ.  All of those should have been DEFPARAMETERs in the first place.
If you see multiple SETQ at toplevel for the same variable, that is a 
logical bug, and is independent of whether you use SETQ or DEFPARAMTER.

I don't see why that defeats the purpose of DEFPARAMETER.

|  I would prefer to have in a _single_ place explicit
| DEFVAR/DEFPARAMETER declaration and in all other places use SETQ.

I don't think it makes much sense from logical code locality and organization
to put all definitions in one files as is done in setq.lisp or varini.boot.
Doing that put unrelated things together, remove the variable definition from
where it is logically confined to some unrelated place.

For example, you organize the current code base to make appearant the logical
units, then you'll find out that variables are defined in the wrong place.
Putting them with the codes they belong to is more logical.
$nopos, for example, should not be defined in varini.boot.  It belongs to
posit.boot. 

We don't have a file "call.boot" for all function calls we make, for
"eq-comparison.boot" for all "eq compare" we do.  Let's organize the codes
logically.

\start
Date: Mon, 28 May 2007 16:24:17 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: clisp and sbcl

> On Mon, 28 May 2007, Waldek Hebisch wrote:
> 
> | It looks for me that replacing SETQ by DEFPARAMETER defeats much of the
> | purpose of DEFPARAMETER/DEFVAR: we silence _all_ warnings about assignments
> | to undefined variables, loosing them also when variable name is
> | spelled incorrectly.
> 
> The replacement was for variable definitions at top level, NOT every use
> of SETQ.  All of those should have been DEFPARAMETERs in the first place.
> If you see multiple SETQ at toplevel for the same variable, that is a 
> logical bug, and is independent of whether you use SETQ or DEFPARAMTER.
> 

OK, for each variable used in multiple file we should have one
unintialized DEFVAR in some "header" file and SETQ at place of
definition.  The first DEFVAR will silence warnings about uses
in other files while SETQ will catch misspeled names.  
 
 
> |  I would prefer to have in a _single_ place explicit
> | DEFVAR/DEFPARAMETER declaration and in all other places use SETQ.
> 
> I don't think it makes much sense from logical code locality and organization
> to put all definitions in one files as is done in setq.lisp or varini.boot.
> Doing that put unrelated things together, remove the variable definition from
> where it is logically confined to some unrelated place.
> 
> For example, you organize the current code base to make appearant the logical
> units, then you'll find out that variables are defined in the wrong place.
> Putting them with the codes they belong to is more logical.
> $nopos, for example, should not be defined in varini.boot.  It belongs to
> posit.boot. 
> 

Yes, you have good point here.  But I am affraid that due to Lisp
limited (rather low-level) support for modularity we need DEFVAR is
separate place.  I fully agree that SETQ should go in logical
place, but it is not clear for me what is the best way to do it.
One possibility is to use noweb to extract "init chunks" and put
them in separate file (from my point of view it is one of rare
cases when noweb chunks may improve readability).  Another
possibility is to maintain a separate file with uninitialised
DEFVARs (something like C file with extern declarations).

> We don't have a file "call.boot" for all function calls we make, for
> "eq-comparison.boot" for all "eq compare" we do.  Let's organize the codes
> logically.
> 

For calls we have (unfortunatly GCL specific) interp-proclaims.lisp.
Special forms are predefined.  Most of macros is expanded during compilation
(and the ones which are not are not visible to the compiler anyway).
So call and variable access are only "interesting" cases where we
reference global values bound to symbols.  "Interesting" here means
that the Lisp compiler can issue sensible diagnostics about
undefined values.

\start
Date: Mon, 28 May 2007 09:48:27 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: clisp and sbcl
Cc: list

On Mon, 28 May 2007, Waldek Hebisch wrote:

| 
| > On Mon, 28 May 2007, Waldek Hebisch wrote:
| > 
| > | It looks for me that replacing SETQ by DEFPARAMETER defeats much of the
| > | purpose of DEFPARAMETER/DEFVAR: we silence _all_ warnings about assignments
| > | to undefined variables, loosing them also when variable name is
| > | spelled incorrectly.
| > 
| > The replacement was for variable definitions at top level, NOT every use
| > of SETQ.  All of those should have been DEFPARAMETERs in the first place.
| > If you see multiple SETQ at toplevel for the same variable, that is a 
| > logical bug, and is independent of whether you use SETQ or DEFPARAMTER.
| > 
| 
| OK, for each variable used in multiple file we should have one
| unintialized DEFVAR in some "header" file and SETQ at place of
| definition.

We should be able to generate the equivalent of "header" file, in
form of declarations to be loaded in other files.  
We know that in Boot we can put types as part of the variable definition,
e.g. 

   $sawParenthesizedParams : Boolean := false

then, we should be able to convince bootsys to generate a "header" file
to be included by others in the form SPECIAL and TYPE declarations.

I have also convinced bootsys to accept function definitions with
specification of the parameter types and return types.  We should also be able
to convince it to generate the corresponding proclamation information.
That is part of the module experiment I'm conducting on gdr-sandbox.

For the moment, I translate "import"s as REQUIREs.

[...]

| cases when noweb chunks may improve readability).  Another
| possibility is to maintain a separate file with uninitialised
| DEFVARs (something like C file with extern declarations).

Yes; I would rather automate that process through bootsys for example.
The automation will also takes care of the differences between CLISP, SBCL 
and GCL, etc.

\start
Date: Mon, 28 May 2007 20:19:41 -0400
From: Bill Page
To: list
Subject: RE: Leo, LP and Axiom

At:

https://sourceforge.net/forum/message.php?msg_id=4334017

I am continuing the discussion of the use of Leo in Axiom with
the developer of Leo, Edward Ream on the Leo SourceForge
forum. Ed is reluctant to participate directly in this email list. 
He would prefer to work one-on-one to develop some ideas about
how best to use Leo with noweb and Axiom. But I also want to
pass some of this discussion along here since you may not find
it especially convenient or find sufficient motivation to participate
directly in the Leo forum where this is being discussed. 

If anyone has any objection to this arrangement, please let me
know. 

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

RE: Leo, LP and Axiom
By: Bill Page (billpage) - 2007-05-28 20:09

Edward, thank you for continuing this thread on Leo and Axiom. 

Aside: Has anyone ever expressed to you an opinion that
interacting this way via a web forum is rather awkward?
It seems archaic to me compared to the email lists where
I interact with all of the other projects. How did Leo
end up doing things this way?

You said:

"Discussion of Leo by those who don't use it is distasteful."

You wrote "by" so I presume that you mean that you find what
people say about Leo who don't really know anything about Leo
distasteful? Well I can certainly understand that point of view
after reading through almost all of the Leo thread on slashdot!
But I do not have very high expectations for such wide open
forums. 

Of course discussing Leo *with* people who don't use it is a
normal part of promoting the idea. I think very few ideas
actually sell themselves. 

"There are so many misconceptions about Leo that I despair of
knowing where to begin."

I think the obvious place to begin is always with examples. But
I must admit that I was a little taken-a-back by the comment by
Ralf Hemmecke (an Axiom developer whom I otherwise greatly respect)
that he did not think that 'LeoPy.leo' qualified as a literate
program at all. I think he was looking for something "pretty"
and "publishable quality" (not his words) such as the LaTeX that
one might see as output from Knuth's web or from noweb, but did
not find it. Of course there is a section of the Leo documentation
that specifically addresses this in reference to "weave", but I
am sure that he did not find that convincing. 

"The attitude on the list seems to be that using traditional LP
is some kind of major advance in programming."

Well, the Axiom developers are acutely aware that no other
computer algebra project has ever committed all of it's source
code to a literate format. This is also underlined by the fact
that a large part of Axiom is actually written in Lisp and the
Lisp community has been one of the most resistant to the idea
of literate programming from the very beginning. 

If there is any really argument to be made here, then it is
that traditional LP would be or should be a major advance over
the way computer algebra systems have been built and tested in
the past. I have not heard any serious attempts on the Axiom
developer list to apply this assessment to programming in general. 

The problems that LP is supposed to solve in Axiom arises from
Axiom's long history and origin as a very active research project. 
A lot of the code in Axiom is over 30 years old and most of it
was never documented properly. Tim Daly - a lead Axiom developer -
was one of the people involved in programming Axiom during these
early days and it is at least in part his experience of revisiting
now code that he wrote then, and realizaton that if only some
additional effort had been placed on documenting the original code
*during* it's development, then we would not be in the situation
we are today with Axiom. 

Another thing that makes the application of LP to Axiom a little
unique is that a large part of the Axiom code (the Axiom library)
is actually meant to directly encode concepts and theorems of
mathematics. Mathematicians are quite used to communicating new
algorithms and proving new theories in the form of research papers. 
It is the desire of the Axiom developers that the approach to LP
used in Axiom should directly support this mode of documentation
of Axiom code. 

"Bill, I suggest that you abandon, at least temporarily, the effort
to convert your colleagues to Leo."

I have no idea if or when one or more of the other Axiom developers
will take an active interest in Leo however I would like to reserve
the right to continue this discussion in parallel on the Axiom developer
email list even without your direct participation and in spite of an
apparent disinterest on the part of other Axiom developers. The main
reason for this is that I would like to include a record of these
discussions in the Axiom email archives. I have come to rely on these
archives as the main means of help to maintain some long term continuity
in my input to the Axiom project. 

"Instead, I would be happy to help make Leo a friendlier host (for you). 
This will involve some discussion about the best work flow for using
noweb. There are several alternatives that we can discuss at leisure."

This approach is acceptable to me. I am very interested on your views
about how best to use noweb in conjunction with Leo. I don't have much
"leisure" these days :-) but I would like to set as an objective the
actual creation of a trial Leo-based source repository for Axiom. Of
course this might take some time if I cannot attract anyone else from
the Axiom project to help. 

In any case, could you please outline how you would like to go about
this? For instance, do you see us as continuing to interact via this
forum? Do you think it would it be useful to setup a new branch of
the Axiom repository to support and share this work? Do you anticipate
that there will be modifications to Leo as well as to the structure
of the Axiom source code? If so, should these changes be maintained
in a separate branch of Leo development?

Thanks again for offering to work with me on using Leo with Axiom. 

\start
Date: Mon, 28 May 2007 22:43:12 -0400
From: Cliff Yapp
To: Bill Page, Stephen Wilson
Subject: AxiomSources

OK, I have made an initial stab at an updated AxiomSources page.  I
think I missed a number of child pages that need updating, and there are
doubtless many things still to be improved.

One thing that is clear - we really need to straighten out the tarball
situation.  I would suggest someone tar up the latest Gold and put it up
in the Sourceforge files area (maybe Savannah's as well for a mirror, if
it's active).  I think this makes more sense than having it on the
Axiom server itself, although that could be another mirror.

Someone with admin access to the sf and savannah projects will need to
put out the files, and we need to make a new one as well - (unless sept
2005 still corresponds to the latest Gold, I haven't checked yet).

When making a tarball release, it is customary to strip out all the
.cvs/.svn/etc directories - is there a better way to do that than manually?

Anyway, I invite any and all to revert/edit/update what I've put up.
Any mistakes in maintainer identifications are unintentional and I
apologize in advance for any errors.

\start
Date: 28 May 2007 21:55:10 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: AxiomSources

Cliff Yapp writes:

| OK, I have made an initial stab at an updated AxiomSources page.  I
| think I missed a number of child pages that need updating, and there are
| doubtless many things still to be improved.
| 
| One thing that is clear - we really need to straighten out the tarball
| situation.  I would suggest someone tar up the latest Gold and put it up
| in the Sourceforge files area (maybe Savannah's as well for a mirror, if
| it's active).  I think this makes more sense than having it on the
| Axiom server itself, although that could be another mirror.

SF offers space for tarballs.
And despite Tim's opinion last time this came up, we do need
tarballs.  Yes.

| Someone with admin access to the sf and savannah projects will need to
| put out the files, and we need to make a new one as well - (unless sept
| 2005 still corresponds to the latest Gold, I haven't checked yet).
| 
| When making a tarball release, it is customary to strip out all the
| .cvs/.svn/etc directories - is there a better way to do that than manually?

Agree on all account.

For CVS, use export -Dtoday -- you don't need manual stripping.
for SVN, use export.
For Git, read the manual.

| Anyway, I invite any and all to revert/edit/update what I've put up.
| Any mistakes in maintainer identifications are unintentional and I
| apologize in advance for any errors.

Thansk for doing this, Cliff!

\start
Date: Mon, 28 May 2007 22:56:07 -0400
From: Bill Page
To: list
Subject: Fwd: [sage-devel] NSF white paper draft - call	for comments

Axiom Developers;

The following draft white paper by David Joyner and William Stein
(Sage developers) potentially affects NSF funding of other open source
computer algebra projects including Axiom, I think Axiom developers
might also care to comment to the authors. 

We probably all agree that more NSF funding for open source computer
algebra would be a good thing, although we might (strongly?) disagree
on the priorities, e.g. Axiom versus Sage versus Maxima. Yet I think
it is important that we somehow manage to present a united front to
potential the funding authorities. Do you think that this white paper
accomplishes that?

The authors being Sage developers, naturally present Sage in more
detail than the other open source systems mentioned in the paper. 
Should other projects be asking for "equal time" in such a document
or should each project submit a white paper of it's own?

----- Forwarded message from David Joyner -----
    Date: Mon, 28 May 2007 21:39:23 -0400
    From: David Joyner
 Subject: [sage-devel] NSF white paper draft - call for comments
      To: Emil Volcheck, sage-devel@googlegroups.com


Hello Emil, SAGE developers:

Following a suggestion of Emil Volcheck of ACM/SIGSAM and Bob Grafton
of NSF, and William and I have drafted a "white paper" on NFS funding
of mathematical software. It is at

http://sage.math.washington.edu/home/wdj/research/oscas-nsf-white-paper2.pdf

Comments would be greatly appreciated. Please be as critical as you like. 

\start
Date: 28 May 2007 23:08:36 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: Re: AxiomSources

Thanks Cliff!

I'll be editing the page to include a reference to the Axisp branch.

Unfortunately I cannot help with the tarball issue.

\start
Date: 28 May 2007 23:12:48 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: AxiomSources

Gabriel Dos Reis writes:
> | When making a tarball release, it is customary to strip out all the
> | .cvs/.svn/etc directories - is there a better way to do that than manually?
> 
> Agree on all account.
> 
> For CVS, use export -Dtoday -- you don't need manual stripping.
> for SVN, use export.
> For Git, read the manual.

For Git, do:
   git archive --format=tar --prefix=FOO HEAD | gzip > FOO.tar.gz

\start
Date: Mon, 28 May 2007 20:45:01 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Fwd: [sage-devel] NSF white paper draft - call for comments

--- Bill Page wrote:

> Axiom Developers;
> 
> The following draft white paper by David Joyner and William Stein
> (Sage developers) potentially affects NSF funding of other open
> source computer algebra projects including Axiom, I think Axiom
> developers might also care to comment to the authors. 

Bill, thanks for posting this - if there is any chance of having a real
discussion with the NSF on this issue I think it is a very important
topic.

> We probably all agree that more NSF funding for open source computer
> algebra would be a good thing, although we might (strongly?) disagree
> on the priorities, e.g. Axiom versus Sage versus Maxima. Yet I think
> it is important that we somehow manage to present a united front to
> potential the funding authorities. Do you think that this white paper
> accomplishes that?

It does fairly well at being "united", I think.  They seem to stress
open source as a means of verifiability, which in my opinion is
correct.  I'll re-read it after some sleep, but I at least am not in a
real position to critique as they know the audience (the NSF) and I do
not.  You guys out there who have done NSF work in the past, would this
appeal?

> The authors being Sage developers, naturally present Sage in more
> detail than the other open source systems mentioned in the paper. 
> Should other projects be asking for "equal time" in such a document
> or should each project submit a white paper of it's own?

Is there any chance they will actually be read?  Those who have dealt
with the NSF in the past - are they more likely to pay attention if we
present a united front in a community wide position paper that include
a list of signatures?

I would suggest that a good way to approach this might be not as direct
competition for commercial software but as creating work they too could
use to increase the reliability of their results.  Just a thought but
perhaps an approach can be found.  I would be curious if most of
Mathematica and Maple's revenue comes from academia (who would probably
use a free CAS even w/o commercial support) or industry (who are
probably more likely to take the commercially supported solution.)

\start
Date: 29 May 2007 00:09:28 -0400
From: Stephen Wilson
To: list
Subject: Axisp News

I have introduced a new wiki page giving a minimal overview of the
axisp branch:

        http://wiki.axiom-developer.org/AxispBranch


After giving some more thought to how I expect my work to progress, I
have modified the layout of the axisp repo on axiom-developer.  For
anyone who has cloned this repository, I suggest one does a fresh
git-clone to ensure the new remote refs are available.  See the wiki
page for a brief overview of the new layout, or keep reading.


There are four primary branches in the axisp repo, after a git-clone
you should see the following remote branches (see them with
`git-branch -r').

   origin/axisp:  This is the tip of my experimental code.  In general,
   this is unstable and possibly broken.

   origin/master: This is stable code merged from origin/axisp.  Here,
   one will (eventually) find a working, evolving, version of axiom
   which is being rewritten in Lisp and improved along the way.
   
   origin/axisp-silver-testing: Staging ground for code looking for
   public review and promotion into axisp-silver-release.  In other
   words, this branch is for beta-testing and pier review of code
   destined for silver.

   origin/axisp-silver-release: This branch holds changes which I am
   publishing for inclusion in Silver by sending Tim a git-pull
   request.  In general, this branch should be a mirror of Silver.


This setup allows me to pursue my own line of development in the axisp
and master branches, while also giving me the opportunity to
contribute back to Silver in a gracious manner without concern of
merge conflicts.


\start
Date: Tue, 29 May 2007 02:16:57 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: clisp and sbcl

On Mon, 28 May 2007, Waldek Hebisch wrote:

| (defun |evalSharpOne| (x |#1|) (declare (special |#1|))
|    (EVAL `(let () (declare (special |#1|) ,x))))

Have you tried this variant?  It looks "reasonable" to me.

\start
Date: Tue, 29 May 2007 14:07:56 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: clisp and sbcl

> On Mon, 28 May 2007, Waldek Hebisch wrote:
> 
> | (defun |evalSharpOne| (x |#1|) (declare (special |#1|))
> |    (EVAL `(let () (declare (special |#1|) ,x))))
> 
> Have you tried this variant?  It looks "reasonable" to me.
> 

There is a little problem with parentheses, it should be:

(defun |evalSharpOne| (x |#1|)
   (declare (special |#1|))
   (EVAL `(let () (declare (special |#1|)) ,x)))

Using version above compiler warnings go away.  But I did not
put it trough full test cycle.

\start
Date: 29 May 2007 15:06:20 +0200
From: Martin Rubey
To: Igor Khavkine
Subject: Re: [Axiom-math] BasicOperator's %eval property

Igor Khavkine writes:

> Greetings Axiom gurus! Here's some more weirdness that I'd like to
> understand better. I snipped all the "Loading ..." messages. Any
> hints?

Yes. It's not a weirdness, it's a bug.

Here are the relevant bits:


> (3) -> feval1(x:INT):INT == x^2

> (10) -> evaluate(f,feval1)
> (10) ->
>    (10)  f
>                                                           Type: BasicOperator
> (11) -> f(10)
>  11) ->
>    >> System error:
>    ((0 . 10) 0 . 1) is not of type NUMBER.

If you say )se me bo on, you'll see that axiom applies elt(f, 10) from
Expression Integer: it coerces 10 to EXPR INT and succeeds.

The function elt is in fact implemented in ExpressionSpace:

    elt(op:OP, args:List %) ==
      not belong? op => error "Unknown operator"
      ((u := arity op) case N) and (#args ^= u::N)
                                    => error "Wrong number of arguments"
      (v := evaluate(op,args)$BasicOperatorFunctions1(%)) case % => v::%
      okkernel(op, args)

Here comes, what I believe is a bug: belong? is defined in EXPR to give true
always.  It really should check whether the %eval property is from EXPR to
EXPR, if it is set.  Well, there are other possibilities, too, for example, we
could leave the operator unevaluated if the %eval property does not match.  In
any case, currently evaluate(op,args)$BasicOperatorFunctions1(%) blows op.

Could you add it to IssueTracker, please?

\start
Date: Tue, 29 May 2007 07:15:40 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Interesting project - Common Lisp in Common Lisp

I don't know if this would interest anyone but me, but there is a
project out there where someone started implementing Common Lisp in
Common Lisp (how's that for recursive ;-)  If someday a literate
implementation of Lisp is considered it might be interesting to define
"bootstrap" code in assembly for various platforms and then have the
bulk of Common Lisp expressed in itself.  I'm not sure how much of a
bootstrap problem this would present - it would be interesting to
study.  Sort of the ultimate "future proofing" - anything capable of
supporting the lisp standard and supplying the needed IO capabilities
would be able to run Axiom, once the needed abilities were defined on
the machine (either in assembly for that platform or some other
compiler if one happened to be available.)

Sacla - A partical Common Lisp implementation written in Common Lisp.
License:  2-clause BSD
http://homepage1.nifty.com/bmonkey/lisp/sacla/index-en.html

\start
Date: Tue, 29 May 2007 12:08:05 -0400
From: Bill Page
To: Martin Rubey
Subject: Re: Going mad with pattern matching

Quoting Martin Rubey (transferred from axiom-mail):

> Bill Page writes:
>
>> Martin, could you please say two words (or a little more?) about
>> where you found information and examples of how to use suchThat
>> and ruleset?
>
> HyperDoc.  I didn't find examples, but I read the documentation. 
>

Thanks. 

I think it is strange that there is documentation about this in hyperdoc
but not in the Axiom book. According to the original IBM/NAG build
scripts both the book and hyperdoc were supposed to be derived from
the same "hyper" source (htex) files. I wonder if this could be revived
so that we had a complete and up to date printed form of the
documentation?

At the very least perhaps we could probably extract these missing
sections from hyperdoc and copy them into a chapter in the Axiom
book or tutorial. 

>> ... 
>> How can one decide on the proper package call to Ruleset?
>
> Look at the documentation of Ruleset and at the type of a ruleset 
> generated by a "rule" in pile-syntax. 
>

Ok. 

Do you think we should generate an bug report for the use
of the | "suchthat" notation in patterns? Given that what you
wrote works, I am more confident that really this is intended
to work using the | notation. 

\start
Date: 29 May 2007 18:46:43 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: Going mad with pattern matching

Bill Page writes:

> Ok. Do you think we should generate an bug report for the use of the |
> "suchthat" notation in patterns? Given that what you wrote works, I am more
> confident that really this is intended to work using the | notation.

Yes, it certainly should work.  I do not know, unfortunately, how this kind of
definition works.  Note that there is another place where "==" is "abused",
namely for optional arguments.  I'm afraid that it's built into the parser.

\start
Date: 29 May 2007 17:10:16 -0400
From: Stephen Wilson
To: list
Subject: CCL maintenance.

*,

Are any of the current maintainers working with CCL at all?  Is
maintaining compatability with this Lisp of importance to anyone?

\start
Date: Tue, 29 May 2007 19:47:29 -0400
From: Bill Page
To: list
Subject: RE: Leo, LP and Axiom

Here is another installment of my continuing discussion with
the developers of Leo about the possible use of Leo in the
Axiom project. 

https://sourceforge.net/forum/message.php?msg_id=4335631

I would like to encourage you to also read the replies from
the Leo developers at the above link. 

--------

By: Bill Page (billpage) - 2007-05-29 19:42
In the wiki environment - which in some ways might not be
such a bad model for Leo - LaTeX encoding is often used
for "snippets" embedded in reST, MediaWiki, and even HTML. 
The "carrier language" takes care over the large-scale
formatting of the document or web page while LaTeX takes on
the role of a special sub-language for writing mathematical
formula and very rich sets of symbols. 

In Axiom another type of "snippet" contain computer algebra
input commands or even complete mathematical subroutines in
the Axiom programming language. 

The goal of "weave" is to produce a LaTeX script (or a script
in some other language, e.g. XSLT) that when later processed
by 'latex' (or other scriptable engine) will actually run
Axiom to compile these subroutines and execute the commands
producing additional output (often LaTeX-encoded) that is
merged with the LaTeX embedded snippets before finally being
rendered as a document (dvi, HTML, pdf, or whatever). 

Compare this to tangle whose specific purpose is to collect
source code and possibly commands into compilable units. 

Really these processes look nearly the same. They just operate
over differently rooted sub-trees of the Leo outline and
produce a different type of script on output while sharing
many cloned nodes. In both cases the "script package" may
consist of multiple files that are involved in producing a
final target product (or products) using standard system-
provided tools. 

So I am thinking that one should clearly distinguish between
the metadata, comments and notes that are part of the Leo
literate environment but not part of the final tangled
code (which will be run to produce a program), nor is it
part of the woven script that will be run to produce the
final documentation. These latter two are really just two
different kinds of "code" - one producing a program and
the other producing the documentation. 

Of course it is true that some of what starts out as metadata
comments might migrate to document or program content as
the  project matures. 

I think one thing that might be confusing Axiom developers
about Leo is that Leo really supports all three kinds of
content - metadata, documentation and code. But Axiom does
not have any means to systematically collect and manage the
metadata. The Axiom noweb files contain everthing (the possible
exception being comments contained in both the LaTeX and
program source code). 

The kind of model of have in mind for Leo is something like
you might see now in programs like PowerPoint, Microsoft WORD
and OpenOffice. The document consists of both the main content
which becomes part of the slides or paragraphs in the final
document *plus* other material such as collected comments,
change history, scope notes and briefing notes, statistics,
and other metadata that may or may not be printed along with
the product depending on ones final purpose. 

For literate programming I think there is a danger that not
everything that should be polished and presented will make
it into the final form. But from my point of view Leo has the
very great advantage of collecting and managing this working
information very early in the process. 

----

So having outlined all this, I would be very glad to hear  your
criticism and references to documentation about Leo that
might already address this points. 

Thanks for listening/reading to yet another overly long  post
on this subject. :-)

\start
Date: Tue, 29 May 2007 19:01:40 -0500
From: Tim Daly
To: list
Subject: Axiom and common lisp tools

1) A web server to front Axiom in common lisp (Sman)

This is a web server written in common lisp.
It appears to be useful in SBCL, one of the port targets for ANSI.
<http://weitz.de/hunchentoot>


In addition, this is a simple hack using naming conventions
that allows requests for page names (e.g. /foo) to be magically
mapped onto a lisp function call:
<http://planet.lisp.org>


The combination of these two things makes it somewhat easier to 
achieve the goal of a fully portable hyperdoc with a running
axiom in the background.

2) A common lisp that runs as the browser scripting language (Hyperdoc)

And it appears that the previous link I sent about Kamen Lisp
which lets you use common lisp instead of javascript means that
we can dynamically define functions that sit behind web pages
which are dynamically generated. Thus the documentation could
be generated with "live examples" showing the result of input
from the user, just as Hyperdoc does now.
<http://www.cs.stevens.edu/~dlong/software/kamen/index.php>

3) A live version of graphs (Graphics)

The author, Dustin Long, is looking into the ability to write
into the new <canvas> tag which means that we would be able to 
draw directly onto the web page.

4) Axiom talking to a web server process or running in a web server (Doyen)

and it appears that all of the pieces should be in place in the near
term to have a fully functional common-lisp-only based portable Axiom.

The end result is cross-platform and both locally (Doyen) or remotely
accessible.

\start
Date: Tue, 29 May 2007 19:34:55 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Axiom and common lisp tools


--- Tim Daly wrote:

> 
> 1) A web server to front Axiom in common lisp (Sman)
> 
> This is a web server written in common lisp.
> It appears to be useful in SBCL, one of the port targets for ANSI.
> <http://weitz.de/hunchentoot>

Hunchentoot has been on my radar for a while as a possible tool for
Axiom - glad to see interest in it :-).

> The combination of these two things makes it somewhat easier to 
> achieve the goal of a fully portable hyperdoc with a running
> axiom in the background.

Would the inclusion of hunchentoot in Axiom make it possible/desirable
to simply make use of hunchentoot's communication channels for all
front ends (except maybe the terminal?)  Perhaps TeXmacs could be
taught to communicate through such a channel, for example.  Could that
avoid the need to use types of sockets not supported by the various
Lisps in favor of only TCP/IP style communications?  Are there local
performance penalties that would make such a mechanism problematic?

> 3) A live version of graphs (Graphics)
> 
> The author, Dustin Long, is looking into the ability to write
> into the new <canvas> tag which means that we would be able to 
> draw directly onto the web page.

How portable would the <canvas> tag be across browsers/platforms?  Just
curious - I know we may not be able to rest on existing technology and
achieve what we are after.
 
> 4) Axiom talking to a web server process or running in a web server
> (Doyen)
> 
> and it appears that all of the pieces should be in place in the near
> term to have a fully functional common-lisp-only based portable
> Axiom.

\start
Date: 30 May 2007 09:13:25 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: Axiom and common lisp tools

Tim Daly writes:

> 1) A web server to front Axiom in common lisp (Sman)
> 
> This is a web server written in common lisp.
> It appears to be useful in SBCL, one of the port targets for ANSI.
> <http://weitz.de/hunchentoot>
> 
> 
> In addition, this is a simple hack using naming conventions
> that allows requests for page names (e.g. /foo) to be magically
> mapped onto a lisp function call:
> <http://planet.lisp.org>

Did you care to look at SandboxHyperDocReplacement?  Your mail makes me a
little angry, I must confess.

By the way, if you start replacing LaTeX by something else, you are going to
loose me.

\start
Date: Wed, 30 May 2007 14:13:58 +0200 (CEST)
From: Waldek Hebisch
To: Stephen Wilson
Subject: Re: CCL maintenance.

> 
> *,
> 
> Are any of the current maintainers working with CCL at all?  Is
> maintaining compatability with this Lisp of importance to anyone?
> 

I checked that CCL from Nag Cdrom builds OK.  ATM I do not intend
to do any serious work on CCL, but I intend to check if current
Axiom is still compatible with CCL.  IMHO we should choose one
of possible directions:

1) Make sure that CCL really works for building Axiom
2) Drop CCL support completly

Current state, that is having a lot of code to support CCL, but
no testing of this code gives us the combined disadvantages of
the possibilities above: we are spending time on CCL support code,
but CCL does not work out of the box.

>From my point of view main advantage of CCL is that it is quite
portable.  Also, it looks that CCL can be cross-compiled with
basically the same effort as for native build.  There is also
licencing issue: IIUC CCL licence is pretty liberal when somebody
wants to deliver closed source program on top of CCL, but is
GPL incompatible.  Big disadvantage is lack of Ansi compatibility.

Clisp is also quite portable, so it is possible that CCL offers
no advantages over clisp (but this requires more analysis).

\start
Date: Wed, 30 May 2007 06:01:16 -0700 (PDT)
From: Cliff Yapp
To: Waldek Hebisch, Stephen Wilson
Subject: Re: CCL maintenance.

--- Waldek Hebisch wrote:

 >From my point of view main advantage of CCL is that it is quite
> portable.  Also, it looks that CCL can be cross-compiled with
> basically the same effort as for native build.  There is also
> licencing issue: IIUC CCL licence is pretty liberal when somebody
> wants to deliver closed source program on top of CCL, but is
> GPL incompatible.  Big disadvantage is lack of Ansi compatibility.

Lack of ANSI compatibility is a killer, IMHO.  Any sense of how far
from ANSI it is?  CMUCL and SBCL are both very liberal about licensing
IIRC, so they can serve as a deployment platform for that type of
thing.  Also, if someone wants to go closed source they are probably
well advised to take a look at Allegro.

> Clisp is also quite portable, so it is possible that CCL offers
> no advantages over clisp (but this requires more analysis).

I think the main issue there is the performance of Clisp, which IIRC is
quite slow compared to CMUCL et. al.

\start
Date: Wed, 30 May 2007 15:20:17 +0200 (CEST)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: CCL maintenance.

C Y wrote:
> > Clisp is also quite portable, so it is possible that CCL offers
> > no advantages over clisp (but this requires more analysis).
> 
> I think the main issue there is the performance of Clisp, which IIRC is
> quite slow compared to CMUCL et. al.
> 

Well, slow program gets answers faster than program which does not
work at all.  CCL/Clisp are good solutions is situations when
gcl/sbcl/cmucl do not work.

Both Clisp and CCL are bytecode interpreters, so for can not be very
fast, but are faster than many folks would think hearing "interpreter".
ATM I can not say which one is faster CCL or clisp.

\start
Date: Wed, 30 May 2007 06:55:47 -0700 (PDT)
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: CCL maintenance.

--- Waldek Hebisch wrote:
 
> Well, slow program gets answers faster than program which does not
> work at all.

Agreed :-).

> CCL/Clisp are good solutions is situations when
> gcl/sbcl/cmucl do not work.

Yes.

> Both Clisp and CCL are bytecode interpreters, so for can not be very
> fast, but are faster than many folks would think hearing
> "interpreter".

Ah.  If CCL is also bytecode, I would expect that any performance gains
over Clisp would be sufficiently marginal that Clisp's support of ANSI
makes it the winner, but that's just me.  Of course Clisp is GPL, so if
someone wants to do a closed bytecode based Axiom they would need to
either revive CCL or look elsewhere.  Personally I am fine with Clisp -
if someone wants to go commercial closed source with Axiom they are
allowed to, but we don't have to do all the work to make it easy for
them.  Just MHO.

\start
Date: 30 May 2007 11:37:40 -0400
From: Stephen Wilson
To: Waldek Hebisch
Subject: Re: CCL maintenance.

Hello Waldek,

Waldek Hebisch writes:
> > 
> > *,
> > 
> > Are any of the current maintainers working with CCL at all?  Is
> > maintaining compatability with this Lisp of importance to anyone?
> > 
> 
> I checked that CCL from Nag Cdrom builds OK.  ATM I do not intend
> to do any serious work on CCL, but I intend to check if current
> Axiom is still compatible with CCL.  IMHO we should choose one
> of possible directions:
> 
> 1) Make sure that CCL really works for building Axiom
> 2) Drop CCL support completly

It was in thinking about these two options exactly which promoted my
email.

> Current state, that is having a lot of code to support CCL, but
> no testing of this code gives us the combined disadvantages of
> the possibilities above: we are spending time on CCL support code,
> but CCL does not work out of the box.
> 
> >From my point of view main advantage of CCL is that it is quite
> portable.  Also, it looks that CCL can be cross-compiled with
> basically the same effort as for native build.  There is also
> licencing issue: IIUC CCL licence is pretty liberal when somebody
> wants to deliver closed source program on top of CCL, but is
> GPL incompatible.  

I am not a fan of the license myself.  I doubt Codemist Ltd would let
it go under three-clause BSD.  Im not interested in improving software
under a license like this.

> Big disadvantage is lack of Ansi compatibility.

Yes, a big disadvantage indeed.  In addition, if CCL were to be
supported by axiom, it would be us who would need to maintain and
improve it.  I personally have little interest in enhancing CCL into a
full Common Lisp, there are plenty of other lisps out there which do
that for me already.

> 
> Clisp is also quite portable, so it is possible that CCL offers
> no advantages over clisp (but this requires more analysis).

Clisp is portable, and has most ANSI issues ironed out.  I dont have
the need myself to analyze CCL to figure Clisp has all the advantages.

At this time, I am all for dropping CLL support.

\start
Date: 30 May 2007 11:41:25 -0400
From: Stephen Wilson
To: Waldek Hebisch
Subject: Re: CCL maintenance.

Waldek Hebisch writes:

> C Y wrote:
> > > Clisp is also quite portable, so it is possible that CCL offers
> > > no advantages over clisp (but this requires more analysis).
> > 
> > I think the main issue there is the performance of Clisp, which IIRC is
> > quite slow compared to CMUCL et. al.
> > 
> 
> Well, slow program gets answers faster than program which does not
> work at all.  CCL/Clisp are good solutions is situations when
> gcl/sbcl/cmucl do not work.
> 
> Both Clisp and CCL are bytecode interpreters, so for can not be very
> fast, but are faster than many folks would think hearing "interpreter".
> ATM I can not say which one is faster CCL or clisp.

The speed issue is not much of a direct concern for me.  Note that for
some applications Clisp is actually faster than SBCL, but this is
limmited to that class of programs which do on the fly compilation as
their main computation.  Clisp has an simple, non-optimizing,
blindingly-fast bytecode compiler.

\start
Date: Wed, 30 May 2007 12:15:53 -0400
From: Bill Page
To: Stephen Wilson, Waldek Hebisch
Subject: RE: CCL maintenance.

On May 30, 2007 11:38 AM Stephen Wilson
> 
> Waldek Hebisch writes:
> > Stephen Wilson wrote:
> > > Are any of the current maintainers working with CCL at all?
> > > Is maintaining compatability with this Lisp of importance to
> > > anyone?
> > > 
> > 
> > I checked that CCL from Nag Cdrom builds OK.  ATM I do not intend
> > to do any serious work on CCL, but I intend to check if current
> > Axiom is still compatible with CCL.

As part of the open source release NAG (Mike Dewar) claimed that
they had delivered Axiom to Tim Daly in a form that would compile
using CCL on Linux. I have never tested this and I think it would
be good to know since it at least gives us a standard benchmark
for comparison.

CCL was the Lisp that was used to implement the commercial version
of Axiom on Windows. As such it might be a good source to mine for
Windows compatibility issues. For example CCL was extended with a
lisp-callable GREP command specifically for Windows compatibility
since grep is not available on native Windows. Other things that
might be for some use in CCL relate to the "saturn" browser interface
for Windows which unfortunately was not part of the open source
release but might be important for future attempts to rivive this
kind of interface on Windows and Linux.

> > IMHO we should choose one of possible directions:
> > 
> > 1) Make sure that CCL really works for building Axiom
> > 2) Drop CCL support completly
> 
> It was in thinking about these two options exactly which promoted
> my email.

If resources permitted, I would opt for 1) but I cannot offer more
than just some support for testing such a configuration.

> 
> > Current state, that is having a lot of code to support CCL, but
> > no testing of this code gives us the combined disadvantages of
> > the possibilities above: we are spending time on CCL support code,
> > but CCL does not work out of the box.
> > 
> > From my point of view main advantage of CCL is that it is quite
> > portable.  Also, it looks that CCL can be cross-compiled with
> > basically the same effort as for native build.  There is also
> > licencing issue: IIUC CCL licence is pretty liberal when somebody
> > wants to deliver closed source program on top of CCL, but is
> > GPL incompatible.  
> 
> I am not a fan of the license myself.  I doubt Codemist Ltd would
> let it go under three-clause BSD.  Im not interested in improving
> software under a license like this.

As far as I know, Arthur Norman, the author of CCL is still a
member of this email list. *If* we were to choose to continue some
support for Axiom in CCL I think he might be interested and may
be quite flexible about license issues.

\start
Date: Wed, 30 May 2007 11:44:46 -0500
From: Tim Daly
To: Martin Rubey
Subject: Axiom and common lisp tools

Martin,

> Did you care to look at SandboxHyperDocReplacement? Your mail makes me a
> little angry, I must confess.

I'm sorry that you have an emotional reaction to my exploration of the
space of possible solutions. I didn't set out to anger you.

Your code is not the first attempt at making web pages from Axiom
and it certainly won't be the last. You wrote some lisp and spad
and then suggested that SOMEONE should write it up as a pamphlet.

The only available someone is you. Ideas come up all the time but
in order to make them live you have to champion them by writing them
up (ala Cliff's cl-web), implement them, test them, sell them to others,
integrate them, and push them out as a useable patch to Axiom. Kai
worked on a solution during one summer. Unfortunately I was switching
jobs that summer so I couldn't participate and no-one else carried
it to fruition.

We've have various "handwaving" attempts at this in the past and 
will have more in the future until one of us or someone new does the
required work to make their idea the standard because they implemented
it, etc. Then we will all have something that we can all complain about. 

I've been looking at this issue since Bill Page joined this effort
years ago. He insisted that the only reasonable path for Hyperdoc
replacement was a web browser. It took him a while to convince me.
Now I'm convinced. I have a simple version running locally but its
not ready to be introduced to the world.



But my view of a "solution" involves more issues than your code
addresses. A good solution to the browser front end should eventually
remove all of the cross-platform issues we have and make the user
interface more useful. So I see a lot of constraints on the browser
issue that are not addressed by the current proposed solutions such
as yours. 

We need to think about the 30 year horizon. The solution needs vision.
It needs to go well beyond what exists today.

Given a browser front end:

  how do we communicate without hanging axiom?

  how do we communicate without running many axioms?
  how do we handle multiple sessions?
    (axiom can handle multiple workspaces)

    (are axiom pages related to tabs? is each tab a workspace?)

    (can tabs communicate? can tabs work in parallel?)

    (can multiple browsers connect to the same session? 
     this would allow two people to communicate results, 
     which might be interesting in a classroom setting)

  how do we handle requests for dynamic content?
    (axiom knows the libraries but the documentation connection
     is weak. someone recently suggested output of the function
     comments should be added to the )d op ... command)

    (axiom uses pamphlets. there needs to be an architecture for
     displaying links to and for displaying the contents of pamphlets)

    (axiom documentation needs structure that gets generated dynamically.
     how is this going to be done?)

    (axiom needs the ability to show examples of each domain. 
     these examples should be able to be changed, similar to the way
     hyperdoc does now with the "DO IT" button)

    (axiom needs a fast, structured search that includes concepts as
     well as text strings so we can find ideas as well as known functions.
     this requires some idea like enhancing the pamphlets with \concept
     tags and constructing index pages during build)

  how do we handle graphics?
    (axiom pre-generates some graphic content in hyperdoc so it can be
     shown inline in static pages. these inline images contain enough
     information to launch the graphics as a live image)
   
    (axiom generates live images on request and these live images can
     be manipulated with a control panel. HTML has a <canvas> tag that
     allows dynamic drawing on the screen. the graphics piece can write
     into a <canvas> area)

    (axiom can handle the graphics as "expressions" if the interface
     is done right. the easiest case would be to allow a user to
     click a bounding box and then redraw the graphics with the new
     bounds. this is different from the current purely-graphical
     manipulations we do)

    (once axiom can draw into a <canvas> tag we could begin to develop
     other kinds of graphics such as graphing the algebra hierarchy or
     the spad data structures or piecharts, etc)

  how do we handle output?
    (axiom generates latex now. 
     should it generate html? 
     should the translation occur inside the interface?
     do we make output as images or as live text?)

    (if the toolchain is common lisp we could dynamically construct
     s-expressions that could be evaluated anywhere along the chain
     (in spad, in the interpreter, in the web interface, in the browser)
     this would allow us to construct domain calls in the browser,
     evaluate them in axiom, and send them back to the front end)

  how do we handle input?
    (is input still 1D or do we consider 2D?
     how would we linearize 2D input?
     how do we handle piles with variable-sized fonts?
     can the user select subexpressions?
     can the user click on the type output and see something interesting?)

    (this is the web so it should be possible to visit other pages and
     communicate equations back to axiom. how can this work?)

  how can we handle drag-and-drop?
    (axiom pamphlets are the basis of an ongoing discussion for a
     live journal. we'd like to be able to just drag-and-drop new
     pamphlets onto axiom and have it "just work". how does this
     work? how does it interact with the build?)

  how do we minimize the tool requirements?
     (axiom should "just work". we don't want to get into the business
      of requiring java, perl, javascript, XML, flash, mysql, and the
      half-a-hundred other extensions)

     (axiom uses common lisp (as an assembly language :-) ). it appears
      that this toolchain i proposed is all-lisp, all-the-time) 

  how do we integrate this into axiom?
    (axiom does most of its graphics work at the spad level. can we
     figure out how to make the input/compute/output occur and be
     controlled by spad domains?)

    (can the axiom interpreter be raised to the spad level so it
     can by controlled by a spad domain?)

  how do we integrate this into the build?
    (your web page shows spad-level code which would make for a very
     interesting way to "raise the level" of handling the interaction)

    (the one web page shows ASDF code that would fit easily into the
     ANSI build sequence)


To do this "right" is a much harder problem than it seems.

I'm interested in the toolchain I posted because it gives us an
end-to-end common lisp solution. Thus we can dynamically construct
content at either the browser end or the axiom end. It eliminates
javascript/html/php/etc. and makes it possible to push functionality
to the best possible place in the pipe at runtime. We could push
expressions that contain particular domains in either direction.

And the hack on the web page I pointed to shows a way to make URL
page names turn into common lisp function calls. That means that
some of the pages can be completely dynamic.

     




> By the way, if you start replacing LaTeX by something else, you are going to
> loose me.

Me? Replace latex? Surely you jest. Or misread. I'm the guy pushing latex
all the time, everywhere. Latex, common lisp, and spad make up my list of
tools. All else is overhead.

Latex is the only documentation standard I feel we should pursue.
I'm hoping to find someone who has built a browser that speaks latex
rather than html. 

I'm the guy trying to rewrite the pamphlets to eliminate noweb and
just make everything into latex.

I can't imagine why you think i might start replacing latex.

\start
Date: 30 May 2007 12:47:55 -0400
From: Stephen Wilson
To: Bill Page
Subject: Re: CCL maintenance.

Bill Page writes:

> On May 30, 2007 11:38 AM Stephen Wilson
> > 
> > Waldek Hebisch writes:
> > > Stephen Wilson wrote:
> > > > Are any of the current maintainers working with CCL at all?
> > > > Is maintaining compatability with this Lisp of importance to
> > > > anyone?
> > > > 
> > > 
> > > I checked that CCL from Nag Cdrom builds OK.  ATM I do not intend
> > > to do any serious work on CCL, but I intend to check if current
> > > Axiom is still compatible with CCL.
> 
> As part of the open source release NAG (Mike Dewar) claimed that
> they had delivered Axiom to Tim Daly in a form that would compile
> using CCL on Linux. I have never tested this and I think it would
> be good to know since it at least gives us a standard benchmark
> for comparison.

I assume you mean comparison against other Lisp hosts?   Im curious
about the benefit in that.  

It would be one thing if Axiom was targeting one Lisp implementation
in an attempt to exploit all of the extensions and non-standard
features that particular Lisp provides.  But in this case it would
most assuredly not be CCL.

On the other hand, targeting multiple Lisps is of main benefit to the
user (and a non-negligible burdon on the Axiom developers).  IFAIK,
there are effectively no users of CCL, and no user we cant reach via
one of the `standard' open source lisp systems.

In either case, we get the support of the development teams.  We do
not have that, AFAICT, with CCL.

> CCL was the Lisp that was used to implement the commercial version
> of Axiom on Windows. As such it might be a good source to mine for
> Windows compatibility issues. For example CCL was extended with a
> lisp-callable GREP command specifically for Windows compatibility
> since grep is not available on native Windows. 

Unfortunately I cant really comment on this aspect.  I have not used
windows for many, many years.

I assume what your saying is that CCL provided a means to emulate the
missing unix functionality on windows without the need for a
compatibility layer like msys or cigwin?  I could see how that would
be an advantage for the average windows user as they are only
interested in a binary blob that works for them.  We would need to
figure out how to effectively cross-compile axiom into a native
windows app.  I dont see any of that happening myself so I would
simply rely on my clouded perspective that all the world is unix, and
let msys/cigwin take care of the rest.

> Other things that might be for some use in CCL relate to the
> "saturn" browser interface for Windows which unfortunately was not
> part of the open source release but might be important for future
> attempts to rivive this kind of interface on Windows and Linux.

I never saw "saturn", so i dont really know what it is. I have no way
to resurect it or test it.  I doubt I will spend time
reverse-engineering something like that.

Besides, I thought the whole Axiom-in-a-browser was the preferred route
towards a cross-platform interface?

> > > IMHO we should choose one of possible directions:
> > > 
> > > 1) Make sure that CCL really works for building Axiom
> > > 2) Drop CCL support completly
> > 
> > It was in thinking about these two options exactly which promoted
> > my email.
> 
> If resources permitted, I would opt for 1) but I cannot offer more
> than just some support for testing such a configuration.

Initially, supporting CCL would not be terribly expensive.  I belive
the build amchinery is present in all the branches to support it.  Its
the long term cost of having to maintain both Axiom _and_ CCL that is
convincing me the resources are not available. Esp. since Axiom wants
to be Ansi compliant and CCL is certanly not.

> > > Current state, that is having a lot of code to support CCL, but
> > > no testing of this code gives us the combined disadvantages of
> > > the possibilities above: we are spending time on CCL support code,
> > > but CCL does not work out of the box.
> > > 
> > > From my point of view main advantage of CCL is that it is quite
> > > portable.  Also, it looks that CCL can be cross-compiled with
> > > basically the same effort as for native build.  There is also
> > > licencing issue: IIUC CCL licence is pretty liberal when somebody
> > > wants to deliver closed source program on top of CCL, but is
> > > GPL incompatible.  
> > 
> > I am not a fan of the license myself.  I doubt Codemist Ltd would
> > let it go under three-clause BSD.  Im not interested in improving
> > software under a license like this.
> 
> As far as I know, Arthur Norman, the author of CCL is still a
> member of this email list. *If* we were to choose to continue some
> support for Axiom in CCL I think he might be interested and may
> be quite flexible about license issues.

I probably should not have made a satement about the licence anyways.

But any input from Arthur would certainly be appreciated.

\start
Date: Wed, 30 May 2007 12:10:47 -0500
From: Tim Daly
To: Stephen Wilson
Subject: CCL maintenance

Stephen,

> Are any of the current maintainers working with CCL at all? Is
> maintaining compatibility with this Lisp of importance to anyone?

When Axiom was first released Arthur Norman released a version of CCL.
I tried to build Axiom on it but failed, mostly due to my lack of
understanding of how CCL-based Axioms were built. 

When Axiom was released to NAG it was on Bill Schelter's AKCL (now GCL). 
I worked with Bill on AKCL so I was intimately familiar with the details. 
Thus, after a few months of effort I gave up on the CCL path and restored
the build on GCL.

While CCL gave portability it isn't a full common lisp. Indeed GCL is
no longer a "full" common lisp. The direction is clearly ANSI in the 
long term. So I'd have to conclude that CCL is unlikely to be of
importance in the future of Axiom.

\start
Date: Wed, 30 May 2007 19:22:13 +0200 (CEST)
From: Waldek Hebisch
To: Stephen Wilson
Subject: Re: CCL maintenance.

> Bill Page writes:
> > As part of the open source release NAG (Mike Dewar) claimed that
> > they had delivered Axiom to Tim Daly in a form that would compile
> > using CCL on Linux. I have never tested this and I think it would
> > be good to know since it at least gives us a standard benchmark
> > for comparison.
> 

I have build CCL based Axiom using NAG cdrom.  You need a few tweaks
but they are rather obvious.  64-bit version that I build have a
little display glitch (prints some garbage charaters).  32-bit
version does not have this problem.  

To make things clear: version on NAG cdrom builds algebra from
Lisp files.  To rebuild algebra from spad soureces would require
extra effort.

\start
Date: Wed, 30 May 2007 17:07:03 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: CCL maintenance.

On May 30, 2007 1:22 PM Waldek Hebisch wrote:
> ... 
> I have build CCL based Axiom using NAG cdrom.  You need a few
> tweaks but they are rather obvious.  64-bit version that I
> build have a little display glitch (prints some garbage
> charaters). 32-bit version does not have this problem.  

Great. Thanks for checking this.

> 
> To make things clear: version on NAG cdrom builds algebra
> from Lisp files.  To rebuild algebra from spad soureces
> would require extra effort.
> 

I think this the normal way that Axiom was bootstrapped.
Once you have a working version of Axiom, then the Spad
sources are compiled in the normal way. Do you mean that
the NAG open source release cdrom does not contain the
makefile logic necessary to compile the spad sources?

\start
Date: Wed, 30 May 2007 17:12:05 -0400
From: Bill Page
To: Tim Daly
Subject: RE: CCL maintenance
Cc: Gabriel Dos Reis

On May 30, 2007 1:11 PM Tim Daly wrote:
> ...
> While CCL gave portability it isn't a full common lisp. Indeed
> GCL is no longer a "full" common lisp. The direction is clearly
> ANSI in the long term. So I'd have to conclude that CCL is
> unlikely to be of importance in the future of Axiom.
> 

As Gaby has pointed out, one could take an entirely different
point of view. There is no reason to so strongly associated
Axiom with Lisp. In fact Axiom only uses a small part of the
Lisp runtime environment. So it might be possible to take CCL
as the basis for an Axiom-specific runtime optimized especially
to efficiently support Axiom. From this point of view ANSI
compatibility is completely irrelevant.

\start
Date: Wed, 30 May 2007 17:29:49 -0400
From: Bill Page
To: Stephen Wilson
Subject: RE: CCL maintenance.

On May 30, 2007 12:48 PM Stephen Wilson wrote:
> ...
> Bill Page wrote: 
> > As part of the open source release NAG (Mike Dewar) claimed that
> > they had delivered Axiom to Tim Daly in a form that would compile
> > using CCL on Linux. I have never tested this and I think it would
> > be good to know since it at least gives us a standard benchmark
> > for comparison.
> 
> I assume you mean comparison against other Lisp hosts? Im curious
> about the benefit in that.

I meant "benchmark" against which to compare the mathematical output
of Axiom. I think it is important to be able to test to make sure
that the changes we make to the open source version do not lead to
any feature reversions compared to the commercial version of Axiom.
As I understand it there still are a few people and places that
have this version. Otherwise I don't think there is much value in
just comparing a CCL-based version of Axiom to implementations in
other Lisps.

> 
> It would be one thing if Axiom was targeting one Lisp implementation
> in an attempt to exploit all of the extensions and non-standard
> features that particular Lisp provides.  But in this case it would
> most assuredly not be CCL.
> 
> On the other hand, targeting multiple Lisps is of main benefit to
> the user (and a non-negligible burdon on the Axiom developers).

I don't see what benefit targeting multiple Lisps has for end users
of Axiom. To me this seems of benefit only to the developers.

> ... 
> Unfortunately I cant really comment on this aspect.  I have not
> used windows for many, many years.

I am sorry that you are so isolated from the mainstream... ;-)

> 
> I assume what your saying is that CCL provided a means to emulate
> the missing unix functionality on windows without the need for
> a compatibility layer like msys or cigwin?  I could see how that
> would be an advantage for the average windows user as they are
> only interested in a binary blob that works for them.

Yes.

> We would need to figure out how to effectively cross-compile axiom
> into a native windows app.  I dont see any of that happening myself
> so I would simply rely on my clouded perspective that all the world
> is unix, and let msys/cigwin take care of the rest.

??? There is no version of Axiom (or GCL) for cygwin yet. But
Axiom already compiles as a native Windows app user MSYS/MinGW.

> 
> > Other things that might be for some use in CCL relate to the
> > "saturn" browser interface for Windows which unfortunately was
> > not part of the open source release but might be important for
> > future attempts to rivive this kind of interface on Windows
> > and Linux.
> 
> I never saw "saturn", so i dont really know what it is. I have
> no way to resurect it or test it.  I doubt I will spend time
> reverse-engineering something like that.

Too bad. I think it was a thing of great beauty that was lost
to the world due to the proprietary software development model.

> 
> Besides, I thought the whole Axiom-in-a-browser was the 
> preferred route towards a cross-platform interface?

Yes. That is precisely what I am talking about. That is what
"Saturn" was. Please refer to the Axiom developer email
archives.

> ... 
> Initially, supporting CCL would not be terribly expensive.
> I belive the build amchinery is present in all the branches to
> support it.  Its the long term cost of having to maintain both
> Axiom _and_ CCL that is convincing me the resources are not
> available. Esp. since Axiom wants to be Ansi compliant and CCL
> is certanly not.
>

It is a major assumption to say that "Axiom wants to be Ansi
compliant". Obviously this depends on how you view the relationship
between Axiom and Lisp.

> ... 
> > As far as I know, Arthur Norman, the author of CCL is still a
> > member of this email list. *If* we were to choose to continue some
> > support for Axiom in CCL I think he might be interested and may
> > be quite flexible about license issues.
> 
> I probably should not have made a satement about the licence anyways.
> 
> But any input from Arthur would certainly be appreciated.
> 

Yes indeed. I did have several very fruit discussions with him
about CCL just prior to when we got the first version of Axiom
based on GCL working on Windows. For a while it seemed that CCL
was going to be a faster way to that goal until Mike Thomas
solved the last remaining problems with Axiom and GCL in that
environment.

\start
Date: Wed, 30 May 2007 16:45:31 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: CCL maintenance

On Wed, 30 May 2007, Bill Page wrote:

| On May 30, 2007 1:11 PM Tim Daly wrote:
| > ...
| > While CCL gave portability it isn't a full common lisp. Indeed
| > GCL is no longer a "full" common lisp. The direction is clearly
| > ANSI in the long term. So I'd have to conclude that CCL is
| > unlikely to be of importance in the future of Axiom.
| > 
| 
| As Gaby has pointed out, one could take an entirely different
| point of view. There is no reason to so strongly associated
| Axiom with Lisp. In fact Axiom only uses a small part of the
| Lisp runtime environment. So it might be possible to take CCL
| as the basis for an Axiom-specific runtime optimized especially
| to efficiently support Axiom. From this point of view ANSI
| compatibility is completely irrelevant.

Indeed.

I would strongly encourage Axiomatizers to apply the process of abstraction,
dear to working mathematicians, to the Axiom system.  I conjecture that only
that way you can expect quite and full control over Axiom.

\start
Date: Wed, 30 May 2007 16:52:50 -0500
From: Tim Daly
To: Bill Page
Subject: CCL maintenance

Bill,

> I meant "benchmark" against which to compare the mathematical output
> of Axiom. I think it is important to be able to test to make sure
> that the changes we make to the open source version do not lead to
> any feature reversions compared to the commercial version of Axiom.

I check each release against the results obtained with the commercial
version as part of the quality-control process. Some of the test results
in the *.input.pamphlet files reflect the values from the commercial
version. More work will go into this once I move further in trying to
merge the algebra changes.

\start
Date: Wed, 30 May 2007 18:30:06 -0400
From: Stephen Wilson
To: Bill Page
Subject: Re: CCL maintenance.

--text follows this line--
Bill Page writes:

> On May 30, 2007 12:48 PM Stephen Wilson wrote:
> > ...
> > Bill Page wrote: 
> > > As part of the open source release NAG (Mike Dewar) claimed that
> > > they had delivered Axiom to Tim Daly in a form that would compile
> > > using CCL on Linux. I have never tested this and I think it would
> > > be good to know since it at least gives us a standard benchmark
> > > for comparison.
> > 
> > I assume you mean comparison against other Lisp hosts? Im curious
> > about the benefit in that.
> 
> I meant "benchmark" against which to compare the mathematical output
> of Axiom. I think it is important to be able to test to make sure
> that the changes we make to the open source version do not lead to
> any feature reversions compared to the commercial version of Axiom.
> As I understand it there still are a few people and places that
> have this version. Otherwise I don't think there is much value in
> just comparing a CCL-based version of Axiom to implementations in
> other Lisps.

Ok, thanks for explaining.  As Tim pointed out though there are
currently better ways of doing this.

> > It would be one thing if Axiom was targeting one Lisp implementation
> > in an attempt to exploit all of the extensions and non-standard
> > features that particular Lisp provides.  But in this case it would
> > most assuredly not be CCL.
> > 
> > On the other hand, targeting multiple Lisps is of main benefit to
> > the user (and a non-negligible burdon on the Axiom developers).
> 
> I don't see what benefit targeting multiple Lisps has for end users
> of Axiom. To me this seems of benefit only to the developers.

The basic issues in my mind is portability, performance, and to be
capable of distributing axiom without a lisp attached (as we do with
GCL).  If i were new to axiom I would love to go to the website,
download the source, compile it with the sbcl I have installed, and
have a working system.  

But of course, there are some benifits for developers.  Notably being
able to choose the host lisp with which to work.

> > ... 
> > Unfortunately I cant really comment on this aspect.  I have not
> > used windows for many, many years.
> 
> I am sorry that you are so isolated from the mainstream... ;-)

Im leaving for a fishing trip to the back country in a few hours, so
Im going be isolated even further :)

> > I assume what your saying is that CCL provided a means to emulate
> > the missing unix functionality on windows without the need for
> > a compatibility layer like msys or cigwin?  I could see how that
> > would be an advantage for the average windows user as they are
> > only interested in a binary blob that works for them.
> 
> Yes.
> 
> > We would need to figure out how to effectively cross-compile axiom
> > into a native windows app.  I dont see any of that happening myself
> > so I would simply rely on my clouded perspective that all the world
> > is unix, and let msys/cigwin take care of the rest.
> 
> ??? There is no version of Axiom (or GCL) for cygwin yet. But
> Axiom already compiles as a native Windows app user MSYS/MinGW.

Ok, forgive my ignorance on this.  I thought those environments gave
access to something approximating a full POSIX system (which defines
utilities) even during runtime.

> > > Other things that might be for some use in CCL relate to the
> > > "saturn" browser interface for Windows which unfortunately was
> > > not part of the open source release but might be important for
> > > future attempts to rivive this kind of interface on Windows
> > > and Linux.
> > 
> > I never saw "saturn", so i dont really know what it is. I have
> > no way to resurect it or test it.  I doubt I will spend time
> > reverse-engineering something like that.
> 
> Too bad. I think it was a thing of great beauty that was lost
> to the world due to the proprietary software development model.
> 
> > 
> > Besides, I thought the whole Axiom-in-a-browser was the 
> > preferred route towards a cross-platform interface?
> 
> Yes. That is precisely what I am talking about. That is what
> "Saturn" was. Please refer to the Axiom developer email
> archives.

Ok. Ill have a look.  There has been a lot of discussion about the
browser UI on the list the last few years so I must have missed the
saturn connection.

> > ... 
> > Initially, supporting CCL would not be terribly expensive.
> > I belive the build amchinery is present in all the branches to
> > support it.  Its the long term cost of having to maintain both
> > Axiom _and_ CCL that is convincing me the resources are not
> > available. Esp. since Axiom wants to be Ansi compliant and CCL
> > is certanly not.
> >
> 
> It is a major assumption to say that "Axiom wants to be Ansi
> compliant". Obviously this depends on how you view the relationship
> between Axiom and Lisp.

I view axiom as a Lisp program.  As soon as you start tracking a deep
bug in Axiom, this fact is overwhelmingly obvious.

ANSI defines the basic shape shape of the language for me, as for most
Lisp developers and compiler writers.  Its only natural that we move
to converge on this standard.

\start
Date: 30 May 2007 18:34:48 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: CCL maintenance

Gabriel Dos Reis writes:
> I would strongly encourage Axiomatizers to apply the process of abstraction,
> dear to working mathematicians, to the Axiom system.  I conjecture that only
> that way you can expect quite and full control over Axiom.

I couldn't agree more.

\start
Date: 30 May 2007 18:36:47 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Axiom and common lisp tools

Martin Rubey writes:

| Tim Daly writes:
| 
| > 1) A web server to front Axiom in common lisp (Sman)
| > 
| > This is a web server written in common lisp.
| > It appears to be useful in SBCL, one of the port targets for ANSI.
| > <http://weitz.de/hunchentoot>
| > 
| > 
| > In addition, this is a simple hack using naming conventions
| > that allows requests for page names (e.g. /foo) to be magically
| > mapped onto a lisp function call:
| > <http://planet.lisp.org>
| 
| Did you care to look at SandboxHyperDocReplacement?  Your mail makes me a
| little angry, I must confess.

Martin --
  
  Thou shalt say "Hallowed is Lisp".

| By the way, if you start replacing LaTeX by something else, you are going to
| loose me.

This is Axiom; it does not matter what Axiom users think.  

\start
Date: 30 May 2007 18:50:09 -0500
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: CCL maintenance.

Stephen Wilson writes:

[...]

|                          Clisp has an simple, non-optimizing,
| blindingly-fast bytecode compiler.

Indeed.  And I think people should not underestimate that aspect.

The slowness of GCL is another irritating aspect of working on current
Axiom code base.

Please, don't tell me you're not concerned about wasting developer's time.

\start
Date: 30 May 2007 18:51:25 -0500
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: CCL maintenance.

Stephen Wilson writes:

[...]

| At this time, I am all for dropping CLL support.

That would not bother me.  I never built Axiom with CCL and I'm not
going to start soon.

\start
Date: 30 May 2007 20:09:21 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: CCL maintenance.

Gabriel Dos Reis writes:
> The slowness of GCL is another irritating aspect of working on current
> Axiom code base.
> 
> Please, don't tell me you're not concerned about wasting developer's time.

Oh no. Though GCL may not be super-duper-fast when it comes to compile
times, there are may opportunities for speeding up the build which at
the same time have other benefits.  For example, eliminating dead
code.  I looked at the email archives w.r.t saturn and the majority of
the posts were discussing how to remove the connection to the system so
that a windows build was possible.  Though not dead strictly speaking,
Im looking at removing the nag fortran library support, which appears
quite straight forward to do.  

Im sure you could aticipate this, but I suspect that getting Boot out
of the picture and eliminating (understand, this is just my
perspective) a significant layer of indirection would _significantly_
reduce compile times.  I would not be surprised if a lisp rewrite saw
the SPAD compiler build time drop to 15-20 minutes (I think this is a
conservative estimate).  If done properly, the algebra build could
drop significantly as well.

In short, I dont blame GCL for axioms long build times.

\start
Date: 30 May 2007 20:12:04 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: CCL maintenance.

Gabriel Dos Reis writes:
> That would not bother me.  I never built Axiom with CCL and I'm not
> going to start soon.

Any hesitation I had on this point is gone as well.

I will be removing CCL support incrementally as I work, and post a
changeset against silver down the road.  Assuming comparable work is
not being done in parallel.

\start
Date: Wed, 30 May 2007 19:17:52 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: CCL maintenance.

On Wed, 30 May 2007, Stephen Wilson wrote:

| Gabriel Dos Reis writes:
| > The slowness of GCL is another irritating aspect of working on current
| > Axiom code base.
| > 
| > Please, don't tell me you're not concerned about wasting developer's time.
| 
| Oh no. Though GCL may not be super-duper-fast when it comes to compile
| times, there are may opportunities for speeding up the build which at
| the same time have other benefits.  For example, eliminating dead
| code.  I looked at the email archives w.r.t saturn and the majority of
| the posts were discussing how to remove the connection to the system so
| that a windows build was possible.

I don't know if that is of any help but Axiom.build-improvements builds and
works with $saturn set to the same value as for Unix systems.

| Though not dead strictly speaking,
| Im looking at removing the nag fortran library support, which appears
| quite straight forward to do.  

I would not mind if they went away.

| Im sure you could aticipate this, but I suspect that getting Boot out
| of the picture and eliminating (understand, this is just my
| perspective) a significant layer of indirection would _significantly_
| reduce compile times.  I would not be surprised if a lisp rewrite saw
| the SPAD compiler build time drop to 15-20 minutes (I think this is a
| conservative estimate).  If done properly, the algebra build could
| drop significantly as well.
| 
| In short, I dont blame GCL for axioms long build times.

In all my measurements, the Boot-to-Lisp translation takes up non-significant
part of the build.  All the measurements I've done show the compilation of
Lisp codes  take major proportion.  I don't think it is because of the quality
of Lisp generated.

As you know I don't believe in clean, easy modifiable, and maintainable Axiom
written in Lisp.  Lisp is just too low level.  For one thing, the verbosity
(I'm not talking of parenthesis) obscures the main ideas; its primitivity
drags further down.  But, I've said enough on the subject already.

\start
Date: 30 May 2007 20:36:38 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: CCL maintenance.

Gabriel Dos Reis writes:

> On Wed, 30 May 2007, Stephen Wilson wrote:
> 
> | Gabriel Dos Reis writes:
> | > The slowness of GCL is another irritating aspect of working on current
> | > Axiom code base.
> | > 
> | > Please, don't tell me you're not concerned about wasting developer's time.
> | 
> | Oh no. Though GCL may not be super-duper-fast when it comes to compile
> | times, there are may opportunities for speeding up the build which at
> | the same time have other benefits.  For example, eliminating dead
> | code.  I looked at the email archives w.r.t saturn and the majority of
> | the posts were discussing how to remove the connection to the system so
> | that a windows build was possible.
> 
> I don't know if that is of any help but Axiom.build-improvements builds and
> works with $saturn set to the same value as for Unix systems.

Ok, noted.  Thanks for the insight.

> ...
> 
> | Im sure you could aticipate this, but I suspect that getting Boot out
> | of the picture and eliminating (understand, this is just my
> | perspective) a significant layer of indirection would _significantly_
> | reduce compile times.  I would not be surprised if a lisp rewrite saw
> | the SPAD compiler build time drop to 15-20 minutes (I think this is a
> | conservative estimate).  If done properly, the algebra build could
> | drop significantly as well.
> | 
> | In short, I dont blame GCL for axioms long build times.
> 
> In all my measurements, the Boot-to-Lisp translation takes up non-significant
> part of the build.  All the measurements I've done show the compilation of
> Lisp codes  take major proportion.  I don't think it is because of the quality
> of Lisp generated.

I have looked at a lot of the boot generated lisp and I too do not see
significant problems with the code produced from the perspective of
lisp being an assembly language (of course, there is always room for
mechanical optimization) However, I am confident that the manner in
which things are expressed is far from optimal.  Im quite convinced
that human lispers could do a better job of expressing the system in
lisp than the boot compiler ever will.  

Of course, I might be wrong.  Well just have to wait and see :)

> As you know I don't believe in clean, easy modifiable, and maintainable Axiom
> written in Lisp.  Lisp is just too low level.  For one thing, the verbosity
> (I'm not talking of parenthesis) obscures the main ideas; its primitivity
> drags further down.  But, I've said enough on the subject already.

I believe we are polar opposites in the way we see Lisp. 

Im not out to convert anyone.

\start
Date: 30 May 2007 23:32:33 -0400
From: Stephen Wilson
To: list
Subject: Gone Fishing

*,

Im going for an all-too-short vacation without a computer in sight for
miles around.  I'll be back the beginning of next week.

I would like to extend a big Thank-You to everyone for allowing me to
dive back into the foray.  Despite the divergent opinions, the
debates, the `unfocused' traits some (including myself) have noticed
-- I must say: There is a real spirit to the Axiom community and there
always has been since I started reading this list a few years ago.  I
have no doubt whatsoever that it will persist.  And I have no doubt
that it will see the project thru the next 30 years.  

Thanks to everyone for making this outstanding effort live!

For me, Axiom is more philosophy than program.

\start
Date: 31 May 2007 06:39:53 +0200
From: Martin Rubey
To: Stephen Wilson
Subject: Re: NAG libraries
Cc: Gabriel Dos Reis

Stephen Wilson writes:

> Though not dead strictly speaking, Im looking at removing the nag fortran
> library support, which appears quite straight forward to do.

PLEASE do the opposite!  My faculty has the libraries, and I would love to be
able to use them, just, I do not know how.  is nagman available?

It does not make sense to drop support for such a great product, even if
commercial and available only to few. 

Thus, if anybody knows, PLEASE show me how to activate the NAG link!

\start
Date: 31 May 2007 08:26:05 +0200
From: Martin Rubey
To: Mike Dewar
Subject: Re: NAG libraries

Dear Mike,

at my faculty (University of Vienna, Faculty for Mathematics), there is some
interest in using the NAG libraries from within axiom.  Unfortunately, I'm an
absolute looser concerning Fortran and I haven't used the libraries myself at
all and will probably not use them in future either.  However, I'd love to set
things up, so that NAGlink works again.  I guess that this may also be fruitful
for NAG, if you look at the ongoing debate which software to buy and where to
save a little money.

Thus, do you think you could give me some help there?

Many thanks,

Martin

Martin Rubey writes:

> Stephen Wilson writes:
> 
> > Though not dead strictly speaking, Im looking at removing the nag fortran
> > library support, which appears quite straight forward to do.
> 
> PLEASE do the opposite!  My faculty has the libraries, and I would love to be
> able to use them, just, I do not know how.  is nagman available?
> 
> It does not make sense to drop support for such a great product, even if
> commercial and available only to few. 
> 
> Thus, if anybody knows, PLEASE show me how to activate the NAG link!

\start
Date: Thu, 31 May 2007 10:53:45 +0200
From: Gernot Hueber
To: Martin Rubey
Subject: Re: NAG libraries
Cc: Gabriel Dos Reis

Dear Martin, 

I agree with you, but from a somewhat different point of view.
There are several highly interesting and important libraries in addition to 
NAGlib (e.g. atlas, lapack, gnu scientific library, ...) which are very nice 
to have being accessible from within Axiom. Some of these are Fortran, 
others C, or C++.
Anyway, the naglink provides many routines providing utilities and showing 
how to call external library functions. IMHO this interface packages should 
be extended to a more general solution of accessing _any_ external math 
libraries. 

Regarding the NAGlib link, I expect this interface could attract more users 
 - e.g. NAGlib users to use Axiom as interface option and thus help to gain 
publicity. 

Martin Rubey writes: 

> Stephen Wilson writes: 
> 
>> Though not dead strictly speaking, Im looking at removing the nag fortran
>> library support, which appears quite straight forward to do.
> 
> PLEASE do the opposite!  My faculty has the libraries, and I would love to be
> able to use them, just, I do not know how.  is nagman available? 
> 
> It does not make sense to drop support for such a great product, even if
> commercial and available only to few.  
> 
> Thus, if anybody knows, PLEASE show me how to activate the NAG link! 

\start
Date: 31 May 2007 12:05:02 +0200
From: Martin Rubey
To: Gernot Hueber
Subject: Re: NAG libraries

Gernot Hueber writes:

> Dear Martin, I agree with you, but from a somewhat different point of view.
> There are several highly interesting and important libraries in addition to
> NAGlib (e.g. atlas, lapack, gnu scientific library, ...) which are very nice to
> have being accessible from within Axiom. Some of these are Fortran, others C,
> or C++.
> Anyway, the naglink provides many routines providing utilities and showing how
> to call external library functions. IMHO this interface packages should be
> extended to a more general solution of accessing _any_ external math
> libraries. Regarding the NAGlib link, I expect this interface could attract
> more users - e.g. NAGlib users to use Axiom as interface option and thus help
> to gain publicity. Best regards, Gernot Martin Rubey writes:

Have you been able to use the NAGlink?

\start
Date: Thu, 31 May 2007 12:06:01 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: NAG libraries

Martin Rubey wrote:
> Stephen Wilson writes:
> 
> > Though not dead strictly speaking, Im looking at removing the nag fortran
> > library support, which appears quite straight forward to do.
> 
> PLEASE do the opposite!  My faculty has the libraries, and I would love to be
> able to use them, just, I do not know how.  is nagman available?
> 
> It does not make sense to drop support for such a great product, even if
> commercial and available only to few. 
> 
> Thus, if anybody knows, PLEASE show me how to activate the NAG link!
> 

As I wrote in:

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

we have sources to nag demon on NAG cdrom.  However, replay from
Mike Dewar was slightly discouraging:

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

\start
Date: 31 May 2007 12:20:01 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: Axiom and common lisp tools

Tim Daly writes:

> Martin,
> 
> > Did you care to look at SandboxHyperDocReplacement? Your mail makes me a
> > little angry, I must confess.
> 
> I'm sorry that you have an emotional reaction to my exploration of the space
> of possible solutions. I didn't set out to anger you.
> 
> Your code is not the first attempt at making web pages from Axiom 

It seems that you did not try my code.  It shows something that has not been
tried so far, namely accessing the databases using SPAD, and integrating tex4ht
to get html (or mathml or whatever) output.

> and it certainly won't be the last. You wrote some lisp and spad and then
> suggested that SOMEONE should write it up as a pamphlet.

That was not my intention.  I said that I would put more work into it, provided
somebody would try it and succeed on MS-windows.

I did not get any feedback at all.

> I've been looking at this issue since Bill Page joined this effort
> years ago. He insisted that the only reasonable path for Hyperdoc
> replacement was a web browser. It took him a while to convince me.
> Now I'm convinced. I have a simple version running locally but its
> not ready to be introduced to the world.

You know that I share this belief.  With the additional requirement that *any*
webbrowser should do.

> Given a browser front end:

I don't want a browser front end.  I want a working HyperDoc for MS-Windows,
that is good enough to support documentation as written for ALLPROSE.

>   how do we communicate without hanging axiom?

Did my hack hang you axiom?  That would be interesting feedback, really.

>   how do we communicate without running many axioms?

Why would you care?

>   how do we handle requests for dynamic content?
>     (axiom knows the libraries but the documentation connection
>      is weak. someone recently suggested output of the function
>      comments should be added to the )d op ... command)

I did, since there is still no HyperDoc on Windows.  I thought that this might
be an easy way to help windows people.

>     (axiom uses pamphlets. there needs to be an architecture for displaying
>     links to and for displaying the contents of pamphlets)

Did you try my code?

>     (axiom documentation needs structure that gets generated dynamically.
>      how is this going to be done?)

Did you try my code?

>   how do we handle graphics?

As an aside, I should say that during my demonstration of axiom at the faculty
of maths, people were quite impressed by the quality of 3d graphics in axiom.
I don't know gnuplot, but some said that gnuplot would be quite inferiour.
Mathematica's and Maple's graphics definitively are.

>   how do we handle output?
>     (axiom generates latex now. 
>      should it generate html? 

no.  It should generate high quality latex.  tex4ht should generate html.  Ahm,
did you try my code, by the way?

>     (if the toolchain is common lisp we could dynamically construct
>     s-expressions that could be evaluated anywhere along the chain (in spad,
>     in the interpreter, in the web interface, in the browser) this would
>     allow us to construct domain calls in the browser, evaluate them in
>     axiom, and send them back to the front end)

So, what is an s-expression for a polytope?  (It is currently represented by a
file managed by polymake.  Very likely this interface will change some day.)

It seems to me that you are thinking of EXPR INT only.

\start
Date: 31 May 2007 12:22:24 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: NAG libraries

Dear Waldek,

Waldek Hebisch writes:

> As I wrote in:
> 
> http://lists.nongnu.org/archive/html/axiom-developer/2006-12/msg00075.html
> 
> we have sources to nag demon on NAG cdrom.  However, replay from
> Mike Dewar was slightly discouraging:
> 
> http://lists.nongnu.org/archive/html/axiom-developer/2006-12/msg00092.html

Hm, but maybe a proof of concept would be worthwhile. If it's not too much
work, that is.

Do you have access to the NAG libraries?

\start
Date: Thu, 31 May 2007 13:16:47 +0200
From: Gernot Hueber
To: Martin Rubey
Subject: Re: NAG libraries

No, I don't have the library. 

Gernot 

Martin Rubey writes: 

> Gernot Hueber writes: 
 
>> Dear Martin, I agree with you, but from a somewhat different point
>> of view.  There are several highly interesting and important
>> libraries in addition to NAGlib (e.g. atlas, lapack, gnu scientific
>> library, ...) which are very nice to have being accessible from
>> within Axiom. Some of these are Fortran, others C, or C++.  Anyway,
>> the naglink provides many routines providing utilities and showing
>> how to call external library functions. IMHO this interface
>> packages should be extended to a more general solution of accessing
>> _any_ external math libraries. Regarding the NAGlib link, I expect
>> this interface could attract more users - e.g. NAGlib users to use
>> Axiom as interface option and thus help to gain publicity. Best
>> regards, Gernot Martin Rubey writes:
 
> Have you been able to use the NAGlink? 

\start
Date: Thu, 31 May 2007 13:28:24 +0200
From: Gernot Hueber
To: Martin Rubey
Subject: Re: NAG libraries

Martin Rubey writes: 

> Dear Waldek, 
> 
> Waldek Hebisch writes: 
> 
>> As I wrote in: 
>> 
>> http://lists.nongnu.org/archive/html/axiom-developer/2006-12/msg00075.html 
>> 
>> we have sources to nag demon on NAG cdrom.  However, replay from
>> Mike Dewar was slightly discouraging: 
>> 
>> http://lists.nongnu.org/archive/html/axiom-developer/2006-12/msg00092.html
> 
> Hm, but maybe a proof of concept would be worthwhile. If it's not too much
> work, that is.

I'd like to say strongly demanded. There are to much libraries out there 
valuable to use in Axiom. 

I did some trials loading shared libraries in underlying gcl, wrapping C lib 
calls in lisp, and wrapping the lisp functions in Aldor.
Well, it worked for functions with simple parameters lists, yet I got lost 
in Lisp wrapping due to a deeper understanding of how to convert between 
more complex Aldor/Axiom, Lisp, and C data types like lists, vectors, 
matrices.
Furthermore, this approach depends on gcl (on the other hand, gcl does not 
yet support the lisp foreign function interface) 

\start
Date: Thu, 31 May 2007 13:33:57 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Going mad with pattern matching

Sorry Martin, I haven't followed this thread, but when you say "abused", 
does that have something to do with the use of default arguments?

http://www.aldor.org/docs/HTML/chap6.html#4

       line(x: Float, m: Float == 1, b: Float == 0) : Float == m*x + b;
       x: Float := 3.2;
       print << line(x, 8.0) << newline;       -- 8.0 * x + 0
       print << line(x) << newline;            -- 1   * x + 0
       print << line(x, b == 5.0) << newline;  -- 1   * x + 5.0

Ralf

On 05/29/2007 06:46 PM, Martin Rubey wrote:
> Bill Page writes:
> 
>> Ok. Do you think we should generate an bug report for the use of the |
>> "suchthat" notation in patterns? Given that what you wrote works, I am more
>> confident that really this is intended to work using the | notation.
> 
> Yes, it certainly should work.  I do not know, unfortunately, how this kind of
> definition works.  Note that there is another place where "==" is "abused",
> namely for optional arguments.  I'm afraid that it's built into the parser.

\start
Date: 31 May 2007 06:55:31 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] NOISE

I removed uses of NOISE from the makefiles.  It is a terrible way of
implementing verbosity/non-verbosity.  It has proven many times to be
confusing to people -- we had had report of users waiting for 48
hours, where the interactive message was captured and hidden from
user's sight.

People who want to suppress the verbosity of the build can always
redirect to null.

If there is a popular demand, I can look into implementing some
configure-time verbosity switch, but NOISE is a terrible way of doing
things. 

\start
Date: 31 May 2007 14:47:49 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: Going mad with pattern matching

Ralf Hemmecke writes:

> Sorry Martin, I haven't followed this thread, but when you say "abused", does
> that have something to do with the use of default arguments?
> 
> http://www.aldor.org/docs/HTML/chap6.html#4
> 
>        line(x: Float, m: Float == 1, b: Float == 0) : Float == m*x + b;
>        x: Float := 3.2;
>        print << line(x, 8.0) << newline;       -- 8.0 * x + 0
>        print << line(x) << newline;            -- 1   * x + 0
>        print << line(x, b == 5.0) << newline;  -- 1   * x + 5.0

well, I should have been more careful.  The "optional" arguments as in "draw"
or "guess" I meant are quite in line with Aldor semantics of default arguments
-- from a users perspective.  (Some things do not work.  Try
guessRat(q)([1,q,q^2,q^3,q^4]) for example.  Furthermore, the implementation in
SPAD is not nearly as convenient as in Aldor.) So, "abuse" was far too strong a
word.  I should have said: "==" is not only used for constant assignment (in
SPAD: function definition).  So far I know of two exceptions: rules and
optional (or rather, default) arguments.

\start
Date: Thu, 31 May 2007 13:59:29 +0100
From: Mike Dewar
To: Martin Rubey
Subject: Re: NAG libraries

I think you have the code but - as somebody already pointed out - I
wouldn't advise resurrecting it.  Back when it was written we were
thinking along the lines of what are now called service oriented
architectures or web services.  With modern machines the extra overhead
of generating code, compiling it, and sending data down a socket just
isn't worth it.  A lot of Axiom's design decisions were made 15 or 25
years ago and don't make sense in the modern world.  I think that this
one falls into that category.

I would advise going down the dynamic linking route.  We did it for some
NAG routines in the old Windows version of Axiom and more recently we've
done it for Maple and MATLAB.  The performance is much better and from a
user's view its much more flexible and natural.

Kind regards,
	Mike.


On Thu, May 31, 2007 at 08:26:05AM +0200, Martin Rubey wrote:
> Dear Mike,
> 
> at my faculty (University of Vienna, Faculty for Mathematics), there is some
> interest in using the NAG libraries from within axiom.  Unfortunately, I'm an
> absolute looser concerning Fortran and I haven't used the libraries myself at
> all and will probably not use them in future either.  However, I'd love to set
> things up, so that NAGlink works again.  I guess that this may also be fruitful
> for NAG, if you look at the ongoing debate which software to buy and where to
> save a little money.
> 
> Thus, do you think you could give me some help there?
> 
> Many thanks,
> 
> Martin
> 
> Martin Rubey writes:
> 
> > Stephen Wilson writes:
> > 
> > > Though not dead strictly speaking, Im looking at removing the nag fortran
> > > library support, which appears quite straight forward to do.
> > 
> > PLEASE do the opposite!  My faculty has the libraries, and I would love to be
> > able to use them, just, I do not know how.  is nagman available?
> > 
> > It does not make sense to drop support for such a great product, even if
> > commercial and available only to few. 
> > 
> > Thus, if anybody knows, PLEASE show me how to activate the NAG link!

\start
Date: Thu, 31 May 2007 19:26:03 +0200 (CEST)
From: Franz Lehner
To: list
Subject: wh-sandbox and aldor

Hello

since apparently there is no amd64 binary package I tried to
compile one myself and started with wh-sandbox.
It finished after 12 hours (with --enable-checking).

Then I tried to follow the instructions on
http://wiki.axiom-developer.org/AldorForAxiom:

fetched and installed
http://wiki.axiom-developer.org/public/aldor-linux-x86_64-v1.0.2.bin

fetched
http://wiki.axiom-developer.org/src_aldor2.tgz

$ make --version
GNU Make 3.80

$ javac -version
javac 1.5.0_10

unpacked src_aldor2.tgz into
wh-sandbox/src/aldor

document Makefile.pamphlet
apparently is not enough, as the other pamphlets are not unpacked.

what does
"set AXIOM environment variables"
mean?
Should it point to the source or to the target?

So far I tried
export AXIOM=/usr/local/src/axiom/wh-sandbox/build/x86_64-unknown-linux
because it makes most sense with the other variables in the Makefile.


Make.rules:365, 399, 412:
No file found for "include"


Make.rules:204: 
wh-sandbox/int/aldor/sax0/spadset.mk: File not found

indeed the only file there is spadset_check.mk
and then it complains about plenty of missing *.dep files:
wh-sandbox/int/aldor/gendeps/AF.dep: File not found

should I try another branch? If yes, which one?

\start
Date: 31 May 2007 19:32:53 +0200
From: Martin Rubey
To: Franz Lehner
Subject: Re: wh-sandbox and aldor

Dear Franz,

Franz Lehner writes:

> since apparently there is no amd64 binary package I tried to compile one
> myself and started with wh-sandbox.  It finished after 12 hours (with
> --enable-checking).

Great!

> Then I tried to follow the instructions on
> http://wiki.axiom-developer.org/AldorForAxiom:
> 
> fetched and installed
> http://wiki.axiom-developer.org/public/aldor-linux-x86_64-v1.0.2.bin


> 
> fetched
> http://wiki.axiom-developer.org/src_aldor2.tgz
> 
> $ make --version
> GNU Make 3.80
> 
> $ javac -version
> javac 1.5.0_10
> 
> unpacked src_aldor2.tgz into
> wh-sandbox/src/aldor

I believe it's better to do an out of source build of wh-sandbox.  Below are
some notes I took for myself.



> document Makefile.pamphlet
> apparently is not enough, as the other pamphlets are not unpacked.

Hm
> 
> what does
> "set AXIOM environment variables"
> mean?
> Should it point to the source or to the target?

I believe it should be "target", see below.

> should I try another branch? If yes, which one?

no, wh-sandbox should be fine.

Please let me know if this worked, in which case I'll update AldorForAxiom.

Martin

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

out of source build in ax-build:

!!! check version of make (3.81 beta 4 does not work !!!

put or link document into ax-build/target/i686-pc-linux/bin

extract src_aldor2.tar into ax-build/src/aldor

cd ax-build/src/aldor
document Makefile.pamphlet

export AXIOM=~/ax-build/target/i686-pc-linux/
make
## make stops with
# 
# SPADSET MK: all_spadsets.mk
# make[1]: *** No rule to make target
`/home/martin/ax-build/int/aldor/all_spad_cats.mk'.  Stop.
# make[1]: Leaving directory `/home/martin/ax-build/src/aldor'
# make: *** [all] Error 2

touch ../../int/aldor/dep_spad.stamp
document Make.functions.pamphlet
make

# if build stops complaining that "no rule to make target ... axlit ", check
  version of make again

\start
Date: Thu, 31 May 2007 14:03:05 -0400
From: Alfredo Portes
To: list
Subject: HyperDocReplacement

Has anyone been able to run Martin's code in

http://wiki.axiom-developer.org/SandBoxHyperDocReplacement

While trying to test this on the latest wh-sandbox and
build-improvements I got into some issues:

1. In wh-sandbox I need to give a full path to the hyper.spad file and
hyper.lisp. With build improvements it works like in the example above
(the loading of the files).

2. In wh-sandbox doing )co \...\hyper.spad in  I get:
   >> System error:
   Cannot create the file HYPER.erlib/index.KAF

I assume that this line in the docs is not correct:

start a WebBrowser? and enter the url http://localhost/|?binomial `
`OutputForm|.

given that it doesnt have the port number.

I have a rookie question if one does: )co hyper.spad twice is the
first one overwritten by the first one, or does it damage the first
one? I say this because I did this by mistake, and the first one
loaded fine, but the second time I got:

>> System error:
Cannot rename the file "p "HYPER.erlib" to #p"HYPER.NRLIB"

If anybody ran the code without problem, please let me know to see what
I am doing wrong.

\start
Date: Thu, 31 May 2007 14:02:30 -0500
From: Tim Daly
To: list
Subject: Hyperdoc on windows

The following question was raised about hyperdoc on windows.
I did some work on this years ago and got it running.

> Hae?  You have a HyperDoc port for windows? Where can I get  it?

I uploaded hyperwin.tgz. You can get it at 
<http://daly.axiom-developer.org/hyperwin.tgz>

For instructions see:
<http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00438.html>

Tim




\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
