\start
Date: 01 May 2005 01:09:39 -0400
From: Camm Maguire
To: Bill Page
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas, Bill Page, Tim Daly Jr

Greetings!  I've created the 2.6.7pre branch.  Everything is basically
there minus a few gcl-tk demos fixes and possibly a stdin read
multiplexer option (using select) for server sockets.  Please test.

I've added a :daemon keyword to the si::socket function which
backgrounds a process to handle incoming connections via the specified
function automatically.  If :daemon is set to :persistent, then the
backgrounded process will survive when the parent exists. This appears
to work in my preliminary testing.  It should be #ifdef'ed so as not
to interfere with windows, as I imagine it will take some considerable
work to achieve the same there.  Mike it would be nice to get your
opinions on how some windows compatibility code might be put together
at some point.  For now, the option should simply be ignored on non
BSD based systems.  It would of coure also be nice if someone could
kindly give a quick sanity check on windows to make sure the build
hasn't been accidentally ruined :-).

Here is the changelog thus far vis a vis 2.6.6:

gcl (2.6.6-2) unstable; urgency=low

  * Fix (listen) with readline on
  * fix control-d with readline
  * libreadline5 support for Debian
  * Support for pre-compiled regexps and new texinfo format
  * Reenable run-process
  * Push function 'accept  into lisp, use select for 'listen on socket
    streams
  * New Upstream release version
  * Native-reloc feature
  * Add daemon capabilities to server sockets, document socket and
    accept

 -- Camm Maguire  Sun,  1 May 2005 04:12:16 +0000

\start
Date: Sat, 30 Apr 2005 14:42:55 -0500
From: Tim Daly
To: list
Subject: axiom patch-34

20050430 --patch-34
20050430 tpd axiomicon.png added
20050430 tpd axiom30yr.jpg added
20050430 tpd axiomlogo.jpg added
20050430 tpd axiomsml.jpg added
20050429 tpd src/hyper/hthits back out failing changes
20050428 tpd src/interp/Makefile back out failing <<save depsys image>> chunk
20050428 tpd src/boot/Makefile back out failing CMD0 change
20050428 cxm,mxm,tpd src/interp/Makefile <<save depsys image>> chunk
20050428 tpd src/interp/util.lisp document commented code
20050428 mxm src/sman/Makefile use DOCUMENT variable
20050428 mxm src/lib/Makefile use DOCUMENT variable, clean Makefile
20050428 mxm src/interp/Makefile use DOCUMENT variable
20050428 mxm src/input/Makefile use DOCUMENT, TANGLE variable
20050428 mxm src/hyper/Makefile use DOCUMENT, HTADD variable
20050428 mxm src/graph/viewAlone/Makefile use DOCUMENT variable
20050428 mxm src/graph/view3D/Makefile use DOCUMENT variable
20050428 mxm src/graph/view2D/Makefile use DOCUMENT variable
20050428 mxm src/graph/Makefile use DOCUMENT variable
20050428 mxm src/graph/Gdraws/Makefile use DOCUMENT variable
20050428 mxm src/etc/Makefile use DOCUMENT variable
20050428 mxm src/doc/Makefile use DOCUMENT variable
20050428 mxm src/clef/Makefile use DOCUMENT variable
20050428 mxm src/boot/Makefile use a new CMD0 string for loading
20050428 mxm lsp/Makefile add <<gcl-system>> chunk
20050428 mxm src/algebra/Makefile use TANGLE variable
20050428 mxm configure add make GCLVERSION=gcl-system
20050428 mxm Makefile add .freebsd stanza
20050427 mxm Makefile install separates the shell variables and export 
20050427 mxm Makefile lspclean removes the proper files
20050427 mxm Makefile libspadclean removes the proper files
20050427 tpd configure try to handle freebsd and noweb
20050427 tpd Makefile modify VERSION to Axiom 3.5 (May 2005)
20050427 mxm Makefile add DOCUMENT variable to environment
20050419 tpd sprint userid testing
20050401 tpd src/algebra/clifford.spad document CLIF
20050401 tpd src/doc/endpaper.pamphlet added
20050401 tpd src/doc/diagrams.tex added
20050321 mxm Makefile clean Makefile.${SYS}
20050321 mxm src/algebra/Makefile use test -z for NOISE check
20050321 mxm src/booklets/Makefile clean Makefile, Makefile.dvi
20050321 mxm src/doc/axiom.bib linux -> ${SYS}
20050321 mxm src/etc/Makefile clean Makefile, Makefile.dvi
20050321 mxm src/graph/viewman/cleanup.c no malloc.h for BSDplatform
20050321 mxm src/graph/viewman/sselect.c use SIGCHLD for BSDplatform
20050321 mxm src/graph/viewman/viewman.c use SIGCHLD for BSDplatform
20050321 mxm src/hyper/halloc.c no malloc.h for BSDplatform
20050321 mxm src/hyper/hthits replace regex matching routine
20050321 mxm src/hyper/hyper add BSDplatform, use SIGCHLD
20050321 mxm src/include/useproto.h add BSDplatform
20050321 mxm src/input/Makefile clean Makefile, Makefile.dvi
20050321 mxm src/interp/debugsys.lisp linux -> ${SYS} (not general solution)
20050321 mxm src/interp/nlib.lisp GCL code.lsp file rename
20050321 mxm src/interp/util.lisp linux -> ${SYS}
20050321 mxm src/lib/bsdsignal.c add BSDplatform
20050321 mxm src/lib/cfuns-c.c no malloc.h for BSDplatform
20050321 mxm src/lib/fnct_key.c add BSDplatform
20050321 mxm src/lib/openpty.c add BSDplatform
20050321 mxm src/lib/wct.c use long vs int for pwct->fsize
20050321 mxm src/lib/XDither.c no malloc.h for BSDplatform
20050321 mxm src/lib/XShade.c no malloc.h for BSDplatform
20050321 mxm Mark Murray

\start
Date: 30 Apr 2005 17:55:08 -0400
From: Camm Maguire
To: Bill Page
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas, Bill Page, Tim Daly Jr

Greetings!

Bill Page writes:

> Camm Maguire wrote:
> 
> >...
> >Here are my summary opinions at this point -- feedback most
> >appreciated!  (Just a note of clarification -- tcl/tk, which exists in
> >GCL now and is a portable scripting language, is *not the same* as
> >GTK+, an extremely widely used C library with multi-language bindings
> >running 'in-process')
> >
> >=========================================================================
> >Goal: generic GCL gui  -- short term
> >=========================================================================
> >
> >1) get the somewhat clunky but serviceable gcl-tk (i.e. tcl/tk)
> >   working on all platforms as quickly as possible (Need feedback from
> >   Mike and/or Bill)
> >
> For axiom's purposes on Windows I am not fond of this idea until and
> unless we already had a gcl-tk frontend for Axiom working under Linux.
> So I wouldn't push the "all platforms" requirement until we see how far
> this can go on a platform where this would (in principle) be easier (Linux).
> 
> But as I said before, perhaps there are good reasons to pursue this
> in GCL other than Axiom.
> 

Am happy to report that the top page of the hyperdoc browser can
already be implemented within axiom as currently distributed (at least
on Linux) using gcl-tk!

Just edit the 'gcl and 'gif variables at the top of the following to
point to your built or installed gcl directory and to the path of the
distributed axiom gif logo respectively, save it to e.g. "foo.lisp"
and within axiom do ')lisp (load "foo.lisp")':

=============================================================================
(in-package 'tk)
(let ((gcl "/usr/lib/gcl-2.6.6/")
      (gif "/usr/lib/axiom-20050201/doc/axiom_tutorialu/images/axiom_logo.gif"))
  (reset-sys-paths gcl)
  (tkconnect)
  (unless (fboundp '|image create photo|)
    (def-widget |image create photo|))
  (defun ahtll ( gif &optional (w '.ahtll))
    (if (winfo :exists w :return 'boolean)
	(destroy w))
    (if (winfo :exists w :return 'boolean) (destroy w))
    (toplevel w)
    (wm :title w "AXIOM HyperDoc")
    (wm :iconname w "HyperDoc")
    (let ((f1 (conc w '.frame1))
	  (f2 (conc w '.frame2))
	  (f3 (conc w '.frame3)))
      
      (frame f1 :relief "raised" :bd 2)
      (frame f2 :relief "raised" :bd 2)
      (frame f3 :relief "raised" :bd 2)
      
      (let ((b1 (conc f1 '.exit))
	    (b2 (conc f1 '.help))
	    (m1 (conc f1 '.msg))
	    (b3 (conc f1 '.blank1))
	    (b4 (conc f1 '.blank2)))
	
	(button b1 :text "Exit" :command (tk-conc "destroy " w))
	(button b2 :text "Help")
	(button b3 :text "")
	(button b4 :text "")
	(message m1 :font :Adobe-Times-Medium-R-Normal--*-180-* :width "13c" :bd 2 :relief "flat" 
		 :text "AXIOM HyperDoc TopLevel" :justify "center")
	
	(pack b1 :side "left" :pady 5)
	(pack b2 :side "left" :pady 5)
	(pack m1 :side "left" :pady 5 :fill "x" :expand "yes")
	(pack b3 :side "right" :pady 5)
	(pack b4 :side "right" :pady 5)
	
	(pack f1 :side "top" :fill "both" :expand "yes"))
      
      (let ((c (conc f2 '.c)))
	
	(canvas c :scrollregion "0c 0c 30c 24c" :width "15c" :height "10c"
		:relief "flat" :borderwidth 2)
	(let ((l (conc c '.logo))
	      (i (conc c '.img)))
	  (|image create photo| i :format "gif" 
	   :file gif)
	  (label l :image i :relief "flat" :borderwidth 2)
	  (pack l :side "top" :anchor "center"))
	(pack c :side "top" :anchor "center")
	(pack f2 :side "top" :fill "both" :expand "yes"))
      (let ((m (conc f3 '.msg)))
	(message m :text "What do you want to do?" :width "13c" :bd 2 :justify "left")
	(pack m :side "top" :anchor "w"))
      (let ((f4 (conc f3 '.frame4)))
	(frame f4 :relief "flat" :bd 2)
	(let ((l '(|Basic Commands| |Reference| |Topics| |Browse|
		   |Examples| |Settings| |NAG Link| |About AXIOM| |What's New|))
	      (i 0))
	  (dolist (s l)
	    (let ((f (conc f4 (intern (format nil ".f~a" i)))))
	      (let ((b (conc f (intern (format nil ".b~a" i))))
		    (m (conc f (intern (format nil ".m~a" i)))))
		(frame f :relief "flat" :bd 2)
		(button b :command s)
		(message m :text (string s) :width "13c" :bd 2 :justify "left")
		(pack b :side "left")
		(pack m :side "left")
		(pack f :side "top" :fill "both" :expand "yes")))
	    (incf i)))
	(pack f4 :side "left" :fill "both" :expand "yes"))
      (let ((f5 (conc f3 '.frame5)))
	(frame f5 :relief "raised" :bd 2)
	(let ((l '("Solve problems by filling in templates."
		   "Scan on-line documentation for AXIOM."
		   "Learn how to use AXIOM, by topic."
		   "Browse through the AXIOM library."
		   "See examples of use of the libarry."
		   "Display and change the system environment."
		   "Link to NAG Numerical Library."
		   "See some basic information about AXIOM."
		   "Enhancements in this version of AXIOM."))
	      (i 0))
	  (dolist (s l)
	    (let ((m (conc f5 (intern (format nil "m~a" i)))))
	      (message m :text s :width "13c" :bd 2 :justify "left")
	      (pack m :side "top" :fill "y" :anchor "w" :expand "yes")
	      (incf i))))
	(pack f5 :side "left" :fill "both" :expand "yes"))
      (pack f3 :side "top" :fill "both" :expand "yes")
      ))
  (ahtll gif))
=============================================================================

The only functional button is the exit button, for the purposes of
demonstration.  Other buttons are connected to symbols naming
functions yet to be written to generate subpages.

The interface is quite powerful in its closeness to lisp, IMHO, which
I think should be attractive to Tim.  Plus, the multiprocessing issues
have already been worked out, at least on Linux, via signalling with
SIGUSR1.  More on this later, but this effectively means that one can
direct the process from the GUI and the command line simultaneously.
Plus, Dr. Schelter put together some great documentation which is
found in the gcl distribution under the name gcl-tk.{texi,info}.

Of course, some 'wish', e.g. some tcl and some tk, need to be
installed to do this.  On Debian, just 'apt-get -q install tk8.4'.

More examples can be seen by firing up a built or installed gcl, doing
(tk::tkconnect), and loading the "...gcl-tk/demos/widget.lisp" file.
There are a few typos in the examples which I am cleaning up now.
Also, there is an older occasional difficulty in which a 'write
timeout' occurs between the gcl and gcltksrv process.  This is simply
due to the buffer settings in sheader.h being fractional page sizes in
some cases, which I've also fixed here locally and will push into
2.6.7.  Perhaps someone might dig up the old post to gcl-devel on this
issue and tell the submitter that the problem is apparently solved.

Mike, my guess now is that gcl-tk bombs on windows because of
sigusr1.  I agree with your earlier statement that signals are a
mistake for portability to windows.  However, I've just recently
recognized how much existing gcl functionality already exists using
signals.  I agree that we should not build anything new in this
regard, at least without some clear portability breakthrough, but I'm
wondering if we can find a passable solution to get this stuff working
on Windows.  sgc uses sigsegv processing, profil uses sigprof
processing, gcl-tk uses sigusr1 processing, and sockets can optionally
use sigio processing.  You have previously written about gtk+ mapping
its signal mechanism onto windows' 'event loop' processing.  I take it
that this is less than elegant, and gtk+ might have done same buggily,
but would this be a possibility for gcl on mingw, at least for these
four signals?  It would be a real coup, IMHO, if we could discover a
serviceable way of doing this.

\start
Date: Fri, 29 Apr 2005 12:52:02 -0700 (PDT)
From: Cliff Yapp
To: Camm Maguire
Subject: Re: [Gcl-devel] RE: Possible GCL 2.6.7 for axiom
Cc: Mike Thomas

--- Camm Maguire wrote:

> Agreed on the complementarity, and the desirability of a common gui.
> Isn't this exactly what texmacs was designed to be?  What advantages
> over texmacs might accrue from implementing similiar natively in
> lisp? 

Well, off the top of my head the ones that come to mind are interactive
plots in mathematical documents and a much greater focus on CAS
specific GUI interaction mechanisms.  Then there is also being able to
extend Maxima's line breaking code to graphical displays, which is a
non-trivial ability for a math GUI to have.

In once sense, I suppose TeXmacs could in theory do all of this (and
I'd be cheering it on) but it seems like the greatest flexibility would
come from writing an interface, plotting library, etc designed
specifically to be an interface for Maxima and Axiom, rather than
embedding a math environment in TeXmacs.  It's possible the tradeoff
isn't worth it, but the nice thing about open source is that its not a
tradeoff :-).  We can have our cake and eat it too if we are so
inclined.
 
[snip]

> Agreed that no precise prediction can be made, but surely the likely
> contributers are a subset of dedicated lisp users, which, alas, are
> in short supply at present.  This is not to argue against the
> possibility for possible future renewed interest in lisp, but it 
> does, in my mind, argue for a tight lisp binding to a widely used C 
> library at the base, with mcclim as a higher level lisp option on 
> top.  Then we can lever both sets of users.

Agreed.  Save the Lisp Machines themselves all lisp graphics I'm aware
of are ultimately written on top of some other library (X, OpenGL, tk,
java, what have you.)  Since at the moment some intermediate library is
going to exist anyway, I agree a widely used one is a good idea,
although in theory McCLIM would allow us to have multiple backends if I
understand it correctly.  I don't see how we leverage both sets of
users except in the sense the underlying library is well tested - is
this what you mean?

> > With the exception of Garnet, which was used in some special
> > purpose apps long ago, McCLIM is the only of these toolkits 
> > where I do know of a program written using it - Gsharp.  There 
> > was also the Closure web > browser, although I don't know if that
> > has been maintained.  
> 
> This is encouraging!  But I think we will agree that these few apps
> pale in numerical comparison to those directly exercising both the
> gtk+ and qt libraries.

Of course.  But the same could be said for Lisp in general.  And the
situation will never change if we all keep writing in bare gtk+ and qt
libraries - someone has to break the ice :-).  McCLIM is maturing, and
Axiom/Maxima might be just the applications to use to develop and
introduce to the world cross platform Lisp graphics.

> Mike has also mentioned the wxwidgets backend, which would appear
> attractive. 

My main concern with wxWidgets is that we are in effect introducing an
extra layer between the lisp GUI toolkit (if we decide to go that
route) and gtk/X/(Whatever windows uses)/Carbon/the other API on Mac. 
The main argument for wxWidgets is write once, run anywhere - I'm
hoping McCLIM+QT could be capable of the same thing, and perhaps
eventually McCLIM+native.  wxWidgets are effective though - wxMaxima is
an excellent tool for Maxima which is being written with this toolkit.
 
> Indeed.  By whom?  We will never match the testing that goes into
> gnome or kde.   So perhaps one option should be as close to these as
> possible, (with perhaps wxwidgets in between for windows), and then
> build mcclim for the power users on top of this.

That might work, but I would still prefer to write in McCLIM and treat
gtk/qt/wxWidgets as backend libraries rather than the primary coding
language.  But I think things get rather tricky at this level.  Time to
make a flowchart.
 
> This is well taken, but we should keep in mind that even any lisp
> solution will involve learning a completely new set of functions,
> which few people currently know.  If there were a large body of
> existing knowledge distributed among the contributors, this would
> be quite important, IMHO.

True.  But my hope would be that using McCLIM for this purpose and
extending its reach across platforms will help make knowing McCLIM a
very useful skill :-).  That's not the purpose of Axiom of course, and
not relevant to the decision.  But it's a nice dream.

> Here is the tradeoff between 'native look' and gpl'ed windows apps,
> which can in turn be resolved with wxwidgets at the expense of the
> massive user base.  Getting consensus on the priorities is the
> hardest part, but if you are doing the work, your priorities are 
> the ones thatcount :-).

Well, if we have both QT and wxWidget backends for McCLIM, and both
worked well, the user could in effect choose based on license.  I still
think writing a wxWidget backend for McCLIM is like writing a QT
interface for GTK, but perhaps I have that wrong.

Despite your kind words, my opinion is worth very little until I
actually produce useful code, so once I get the Maxima units package in
reasonable shape I'll start digging into McCLIM and backends and see
just what I'm actually proposing so glibly ;-).

\start
Date: 29 Apr 2005 11:52:46 -0400
From: Camm Maguire
To: Cliff Yapp
Subject: Re: [Gcl-devel] RE: Possible GCL 2.6.7 for axiom
Cc: Mike Thomas

Greetings!  And thank you so much for your valuable input!

Cliff Yapp writes:

> --- Camm Maguire wrote:
> >
> >  If not, will these users turn against the project
> >    when their desires are not immediately gratified and the latest
> >    alternative toy becomes available?
> 
> Possibly.  But what alternative toys are you thinking of?  I doubt
> Axiom and Maxima have any serious free competition at the moment -
> there is too much work involved building up systems to their current
> levels of ability.  I hope Maxima and Axiom can someday both make use
> of the same lisp UI code - this will help both projects and enable end
> users to use both systems more easily, since they will be using the
> same basic GUI and only need to adjust to quirks associated with each
> system's unique features and syntax.  I always viewed Maxima as the
> "free Mathematica but better" project, and Axiom as something new
> focused on theoretical purity and correctness above all else.  I think
> these tools are complimentary more than they are competitive, and it
> never hurts to have another system to check results in :-).
> 

Agreed on the complementarity, and the desirability of a common gui.
Isn't this exactly what texmacs was designed to be?  What advantages
over texmacs might accrue from implementing similiar natively in lisp? 

> > 4) To the extent that we adopt this perspective, the only critical
> >    need for graphics in these systems is the ability to plot and
> >    print mathematical functions, IMHO.  At this early stage in its 
> >    open source life, I would recommend axiom adopt the simplest and 
> >    most portable system with a sizable user base, preferably 
> >    maintained and developed externally, and to then move on to the
> >    algorithms.
> 
> I'll agree here, with the hope that expedience can be substituted for
> "the right way" at some point in the future when the math is robust
> enough.
> 
> >    Maxima has adopted gnuplot, which I think is a wonderful and
> >    powerful choice.  We have a working alternative system now and
> >    there is no need to throw this away, but if we ever feel the need
> >    to do something new in this area (for example, because our
> >    existing graphics does not yet work on Windows), this is the 
> >    direction I would recommend for now.
> 
> Probably a decent idea.  I'm not sure how "wonderful" I'd say gnuplot
> is (ask Jim what he thinks about it sometime :-), but it does get the
> job done reasonably well and it's clearly the best current free
> solution.
>  
> > 5) In the longer term, lisp graphics is certainly very interesting,
> >    and some beautiful work from a programming point of view has been
> >    done, notably the McCLIM to which you refer.  The only problem
> >    here which is nonetheless quite serious is the lack of unity or
> >    consensus.  No one can afford to invest the time in putting
> >    something together if they run the extremely high risk that it
> >    will be abandoned later due to the extraordinary degree of
> >    fractiousness in this area.  People need to see the payback 
> >    measured in terms of user contributions in the future -- in this 
> >    way they lever their own efforts.  Ask the question, "If I do 
> >    this, what new user contributions will I likely trigger?"
> 
> Unknown, and unknowable currently, for whichever system you might
> consider.  :-/.  This has been the primary reason I've not discussed
> this more on the Maxima list - I've been waiting to see where the
> various toolkits go and what the possibilities are.  We don't need to
> make a final choice for quite a while since, as you noted earlier,
> there are much more urgent matters to attend to.

Agreed that no precise prediction can be made, but surely the likely
contributers are a subset of dedicated lisp users, which, alas, are in
short supply at present.  This is not to argue against the possibility
for possible future renewed interest in lisp, but it does, in my mind,
argue for a tight lisp binding to a widely used C library at the base,
with mcclim as a higher level lisp option on top.  Then we can lever
both sets of users.

> >         f) clx, clue, clio, clim, mcclim
> 
> McCLIM to my mind is the best choice right now, for the following
> reasons:
> 
> 1)  Active development team (we wouldn't have to maintain toolkit and
> CAS.)
> 2)  CLIM is as close to a GUI "standard" as the lisp world gets.
> 3)  With different backends we might be able to get native look and
> feel on a wide variety of platforms - for instance, gtk and QT backends
> might let us fit nicely on both Gnome and KDE desktops with one set of
> code.
> 
> With the exception of Garnet, which was used in some special purpose
> apps long ago, McCLIM is the only of these toolkits where I do know of
> a program written using it - Gsharp.  There was also the Closure web
> browser, although I don't know if that has been maintained.  

This is encouraging!  But I think we will agree that these few apps
pale in numerical comparison to those directly exercising both the
gtk+ and qt libraries.

> >    b) cross-platform
> 
> There is no simple solution here, particularly from a lisp based
> standpoint - my favorite idea is to wait for QT4, which will have GPL
> versions both on Windows and Linux, and create an McCLIM backend for
> that.

Mike has also mentioned the wxwidgets backend, which would appear
attractive. 

> 
> >    c) wide user base -- this effectively means a huge C user
> >       base with a smaller user base of tight lisp bindings
> 
> Um.  You mean lisp bindings to a popular toolkit?
> 

Yes, at least as a low level layer which is just 'guaranteed to work
virtually forever'.

> >    d) robust
> 
> This will probably come only with time and extensive testing.
>  

Indeed.  By whom?  We will never match the testing that goes into
gnome or kde.   So perhaps one option should be as close to these as
possible, (with perhaps wxwidgets in between for windows), and then
build mcclim for the power users on top of this.

> >    e) actively developed elsewhere
> 
> This puts McCLIM at the front of the class in the Lisp GUI department,
> as far as I know.
>  

Agreed, but it is again a question of the unfortunate dearth of lisp
users as a body.

> >    f) comes with a graphical interface builder -- as attractive
> >       as graphical programming in lisp might be, even though it is
> >       lisp, it is still much less efficient IMHO than using a tool
> >       like glade.  I've used this myself in C, and I haven't had to
> >       write a single gtk call.
> 
> Garnet I know had an interface builder, but I was never able to get it
> to work reliably.  Not sure if McCLIM has one, but it is a VERY good
> idea.  
> 
> >         g) LGPL is preferable to GPL if we're doing a general
> >         interface, but I have no problems with GPL myself.
> 
> Maxima is LGPL, and Garnet is public domain - not sure about the
> others.

What I meant to point out here is that all apps using qt4 on Windows
will be gpl instead of lgpl, which is not an issue for me, but might
be for others.

> > This is well founded, I think.  tk is quick and portable, not
> > necessarily 'robust and polished'.  The importance of the latter for
> > these considerations is questionable.  Can you describe the maxima
> > experience?  
> 
> Essentially the problems stem from us having to fix problems in the
> Xmaxima code.  The "included" openmath plots was an odd affair that
> never behaved reasonably when scrolled, and getting things working on
> Windows was always a challenge for any given release.  I never was able
> to figure out the TCL/TK code myself - I know Jim (our project leader)
> really didn't want to mess with it.  We did finally get someone who was
> knowledgeable to clean it up, but given Maxima is a lisp project we
> were of the general opinion it was annoying to have to maintain a UI in
> another language.  I'm only one (biased) source though, so I recommend
> checking the list archvies for Xmaxima issues.  My memory may be making
> it sound worse than it was. 
>  

This is well taken, but we should keep in mind that even any lisp
solution will involve learning a completely new set of functions,
which few people currently know.  If there were a large body of
existing knowledge distributed among the contributors, this would be
quite important, IMHO.

> My GTK on Windows misgivings stem mainly from my own experiences with
> it - GTK doesn't really "feel" like a native Windows interface.  QT I
> know Trolltech supports on Windows as one of their most significant
> platforms, and I'm guessing they will do their best to ensure QT apps
> look and behave like normal Windows programs.  GTK is workable too, and
> I wouldn't be at all opposed to seeing McCLIM+GTK, but my personal
> preference would be QT to try and avoid the "this doesn't act like a
> regular Windows program" phenomena.  This might have been fixed over
> time though, so my reaction could be quite dated.  I haven't used
> Windows in a significant way in quite a while, so I have no recent
> experience.
> 

Here is the tradeoff between 'native look' and gpl'ed windows apps,
which can in turn be resolved with wxwidgets at the expense of the
massive user base.  Getting consensus on the priorities is the hardest
part, but if you are doing the work, your priorities are the ones that
count :-).

\start
Date: Fri, 29 Apr 2005 23:18:25 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: axiom porting
Cc: Mike Thomas, Camm Maguire, Bill Page

Tim Daly writes:
 > 
 > Then I need to look at the GUESS domain and see what it will take to
 > merge that.

A prerequesite for that is consensus about the (Rational)Interpolation
package. William Sit posted quite a few very good comments (see MathAction) and
I think it would be sensible to consider them. Since these comments concern the
current PolynomialInterpolation packages as well, it might be wise to make this
a priority. I guess that we cannot change the interface of these packages
without upsetting users, once we have some...

\start
Date: Sun, 01 May 2005 12:01:39 -0500
From: MathAction (Thierry Dumont)
To: MathAction
Subject: [Axiom-mail] Good news: Axiom at French "Agregation".

 The French "Agregation" is a competitive entry examination for high
school (high level) teachers. About 400 teachers are recruited each
year, for mathematics.

 At one of the examination, the candidates can use software:

-numerical software (matlab, scilab);
- statistical software (R);
-computer algebra software:
   Maple, Mupad, Mathematica AND... (this is new!)
   Axiom and Maxima (since year 2004/2005).

This means that now, in the cursus of Mathematics, we are not bind to
Maple, and we can try to use Axiom in place of commercial software,
which tends to be more and more expensive.

But if we want to use Axiom with undergraduate students, improvements of
the interactivity of Axiom need certainly to be done. Some years ago to
replace Matlab with Scilab (a product of French Inria), a group of
developpers teams whas build, and some public money whas given to it to
improve Scilab... May be we can dream to such possiblity for Axiom...

\start
Date: Sun, 1 May 2005 11:53:20 -0500
From: Tim Daly
To: Camm@enhanced.com, Bill Page
Subject: axiom porting

Camm, Bill,

Great job. I've bought the book "Practical Programming in Tcl and TK"
and am about 1/2 way thru it. It appears that Tcl is similar to lisp
in that every line starts with a command and returns a value. It also
appears that it is possible to link C code to Tcl/TK which might be
a short term path to getting the graphics working. Tcl/TK also has a
browser plugin so it might be possible to meet Bill's goal of getting
the whole pile integrated in a browser.

In light of your work and my reading I'm stepping away from the Java
development path for the moment and restarting the TK path. 

I need to also recover the windows build procedure and try to get
that working so I can bring windows up to date. Since this work is
supposed to be cross-platform it might help if I actually used both
platforms. I see the purchase of a windows box in my future.

I'm still in the midst of the freebsd merge and the month-end push to
publish so about all I'm doing is reading during compiles. The freebsd
working version will probably have to wait until gcl-2.6.7 because the
magic-loading code does not seem to be useful under 2.6.6 but it's
close. I plan to set up freebsd on one of my local machines.

\start
Date: Fri, 29 Apr 2005 20:04:30 +0100
From: Mark Murray
To: Tim Daly
Subject: Re: axiom freebsd changes 
Cc: Camm Maguire

Tim Daly writes:
> Mark,
> 
> The regex changes to hthits failed to compile.
> We need to discuss how to resolve this.

Sure. What is the error?

\start
Date: Fri, 29 Apr 2005 09:20:21 -0700 (PDT)
From: Cliff Yapp
To: Camm Maguire, Mike Thomas
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Bill Page, Tim Daly Jr

--- Camm Maguire wrote:
 
> > If someone was planning (I'm certainly not) to write a cross
> > platform backend to McClim I personally would be telling them 
> > to use WxWidgets, which has been connected up very nicely in both 
> > the Scheme and Haskell worlds and is much lighter weight than GTK 
> > while retaining good cros-platform performance and appearance.
> 
> The scheme hooks you mention argue strongly in wxwidgets' favor, of
> course.

Would scheme bindings to wxWidgets translate well to lisp?

> ===============================================================
> Goal: generic GCL gui  -- short term
> ===============================================================
> 
> 1) get the somewhat clunky but serviceable gcl-tk (i.e. tcl/tk)
>    working on all platforms as quickly as possible (Need feedback
>    from Mike and/or Bill)

Agreed.

> 2) make sure gcl-tk can display bitmaps (I'll take care of this)

Cool :-).

> ===============================================================
> Goal: generic GCL gui  -- long term
> ===============================================================
> 
> Choose an in-process gui option according to the following ranked
> priorities:
> 
>  1) open source

  Agreed.

>  2) massively exercised in the open source world, which for
>     all intents and purposes means the core C libraries used 
>     by the open source desktops with a thin lisp binding 
>     option

  Well, QT is actually C++, but if you mean GTK and QT are 
  the two most attractive "back end" toolkits I agree.

>  3) universally portable

  There are two ways this can work:
  a)  Back end toolkit is ported to all platforms.
  b)  Interface logic written in Lisp toolkit which has working
      bindings to different toolkits on different platforms.

>  4) easy to use, preferrably with a graphical gui builder.

 For GTK there is glade, for QT there is QT Designer.  AFAIK
 both are quite good.

 Interestingly, Craig Lanning mentioned yesterday on the McCLIM
 list that he had written a CLIM interface builder some years
 ago.  If it still works and he is willing to contribute it that
 might help make McCLIM more attractive on the lisp level. Garnet
 did have a UI builder but IIRC it had bugs and I never really 
 got the hang of it.
 
>   5) native 'look and feel'

  This is a major drawback for GTK on Windows.

>   6) supports the option of a higher level lisp layer like
>   mcclim.  This to my understanding can just be layered on
>   top of a thin lisp binding layer. 

That's the theory I guess, although current McCLIM and Garnet bindings
seem to be below toolkit level if I understand correctly.  (clx, and
the experimental MacOSX Beagle backend for McCLIM).

>   7) lgpl better than gpl.  Just to be clear here, if qt4 is
>      selected, all apps using this will be GPL when distributed
>      in binary form -- Mike Thomas has voiced reservations
>      about this in the past, but it doesn't particularly bother 
>      me.

Mike?  Would that matter?  If the source code to Axiom+Interface itself
is more liberal, does the binary version being GPL when using QT matter
particularly?  

>  We should not do any work on this, IMHO, unless we have a
>  confirmed user of such a system.  As I state below, axiom and the
>  other systems currently using gcl might be more easily serviced
>  in other ways.  

Uh - you mean we should wait until someone develops a working GUI to
build on?

>  My feeling is that depending on wxglade functionality, this would
>  result in wxwidgets > gtk+ > qt4

I guess I would disagree - my take on it would be (McCLIM+qt4) >
(McCLIM+wxwidgets) > (McCLIM+gtk+) > qt4 > wxwidgets > gtk+, based on
the following assumptions:

QT4 is more likely to be robust on Windows than either wxWidgets or
gtk, since one of trolltech's major revenue focuses is to sell
commercial licenses to Windows developers - they will be able to bring
more resources to the problem.  On Linux this wouldn't tend to worry me
as much, but in the case of Windows I'm more inclined to trust QT to be
robust, and behave as Windows users expect in the look and feel
department.  (That's just my personal opinion, not experience, and as
such deserves little weight.)  QT works on Windows, Linux, and Mac.

wxWidgets is itself a layer on top of other toolkits, at least on
Linux.  I'm not sure what it does on Windows, although presumably it
uses the "standard" Microsoft APIs.  I almost view wxWidgets as a C++
McCLIM from the standpoint of how it relates to other GUI libraries. 
My take on it is that bugs would be easier to track going from McCLIM
to QT or Gtk+ directly than McCLIM->wxWidgets->Gtk+ on Linux, although
that might not be true in practice.

gtk+ won't have a native look and feel on Windows, and I'm not sure
about its status on the Mac (anybody know?)  There are stability and
robustness concerns on Windows.  

Overall, (McCLIM+anything) or (Garnet+anything) is better than not
writing the UI in Lisp, IMO.  Having all user interface code in one of
these toolkits allows flexibility in toolkit choice, based on what
backends are available or are created in the future.  If available, one
could bypass the extra toolkit and do McCLIM+Win32GPI, or
McCLIM+Beagle, and get a totally native behavior without requiring QT. 
QT would essentially be written as a backend to be used until all
platforms of interest have solid McCLIM backends.  (On linux, of
course, in KDE you would want McCLIM+QT to fit with the desktop, and
McCLIM+Gtk for Gnome.)

But as always, proof is in the pudding.  I'll try playing around with
McCLIM when I get the chance and see if I can recreate the axiom
hypertex start page (I got it to run last night, and I had forgotten
how basic it is.  I'm going to be embarassed if I can't figure this out
eventually :-)

\start
Date: Fri, 29 Apr 2005 12:10:38 -0500
From: Tim Daly
To: Mark Murray, Camm Maguire
Subject: axiom freebsd changes

Mark,

The regex changes to hthits failed to compile.
We need to discuss how to resolve this.

I've backed out this change.

\start
Date: 29 Apr 2005 11:15:21 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: axiom porting
Cc: Mike Thomas, Bill Page

Greetings!

Tim Daly writes:

> I'm a bit overwhelmed by the volume of suggestions.
> 
> The browser idea has promise except that I don't see how to handle
> the graphics. I also don't see how to "command" a browser
> through a socket to do things like open a new tab. 
> 

Just a suggestion here -- use the browser for hyperdoc, and something
else (like gnuplot) for graphics.

> But it does give us the advantage of an already portable front
> end. The dynamic content doesn't seem to be much of an issue.
> There is an asq command that can compute answers to database queries.
> And if Axiom could handle server requests it would be easy to
> serve up algebra (might even be a reason to send Bill to China).
> 

Remote access should be straightforward if you can get around your
local firewall.  Is this useful?

> I've been clinging to reproducing the prior work as it gives me a
> fixed target to achieve. Otherwise it becomes an open-ended design
> problem and it will never be finished. Perhaps this is misguided.
> 
> I actually have no idea what gtk is despite the fact that my son was
> involved in developing it. And I'm not sure what glade is.
> 

gtk+ it the core C grapics toolkit use by the desktop you are using at
the present moment, virtually every application on it.  (You use
redhat/gnome, if memory serves).  The comparable alternate is kde
which is analogously built atop the qt library.  The Linux world is
roughly evenly divided between the two, by my estimation.

glade is a program whereby you can create any gui without writing a
line of code, but rather by selecting and placing widgets with a mouse
alone.  A *massive* productivity saver, IMHO.

> I did try to "rewrite the xlib calls to MS equivalents" but the model
> for graphics is wildly different. I suppose this is why no one has 
> taken this path.
> 
> I did get the run-process patch you sent but have not yet applied it.
> I'm still working on merging the BSD patches which have been hanging-fire
> behind the axiom conference work. Hopefully I'll complete that tonight.
> 
> Then I need to look at the GUESS domain and see what it will take to
> merge that.
> 
> THEN I'll look at the G/B (graphics/browser) issue. Since I'm not
> actively coding this is a good time to debate the issue.
> 

\start
Date: Fri, 29 Apr 2005 15:22:14 -0400
From: Bill Page
To: Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas, Tim Daly Jr

Camm Maguire wrote:

>...
>Here are my summary opinions at this point -- feedback most
>appreciated!  (Just a note of clarification -- tcl/tk, which exists in
>GCL now and is a portable scripting language, is *not the same* as
>GTK+, an extremely widely used C library with multi-language bindings
>running 'in-process')
>
>=========================================================================
>Goal: generic GCL gui  -- short term
>=========================================================================
>
>1) get the somewhat clunky but serviceable gcl-tk (i.e. tcl/tk)
>   working on all platforms as quickly as possible (Need feedback from
>   Mike and/or Bill)
>  
>
For axiom's purposes on Windows I am not fond of this idea until and
unless we already had a gcl-tk frontend for Axiom working under Linux.
So I wouldn't push the "all platforms" requirement until we see how far
this can go on a platform where this would (in principle) be easier (Linux).

But as I said before, perhaps there are good reasons to pursue this
in GCL other than Axiom.

>========================================================================
>
>Goal: portable axiom hypertex
>
>========================================================================
>
>This would appear best served by Bill Page's browser idea with GCL
>server sockets.  For now, I will work on providing
>fork()/CreateProcess() options, and select/stdio multiplexing options,
>to the si::socket function call. ...
>  
>
I would like to understand how this "stdio multiplexing" thing will
work. Will it allow Axiom to simultaneously answer both command
line input and input/output via HTTP in a manner similar to Axiom's
current HyperTex browser?

Or do we only have to modify the read-process-output loop in
Axiom so that it accepts HTTP input instead of Axiom's native
HyperTex session input?

Of course besides the HyperTex documentation, tutorial and Axiom
library navigation, there is still the issue of mathematical notation 
support
in the browser. NAG also did a lot of work on OpenMath which in
principle could be salvaged to provide math output in MathML
format which is now becoming quite mature in the newer browsers.
Techexplorer provided inline LaTeX rendering in the browser and
that would be hard to duplicate on the desktop without adding
much more overhead with things like LaTeX and dvipng (the way
we work now on the MathAction server).

>=============================================================================
>
>Goal: portable axiom graphics
>
>=============================================================================
>
>This is unlikely to be well serviced by a web browser, and only
>modestly well-serviced by a standard gui, as axiom's demands on plot
>manipulation are likely to require such detail as canned 'widgets' are
>unlikely to be available.
>
As I currently understand in theory Axiom graphics can be served using
NAG's OpenInventor extensions of to the Axiom graphics program together
with either OpenInventor itself (now open source) or a compatible VRML
plug-in for a standard browser.

>I really feel gnuplot is the best tool here
>in the medium term, which can be fully accessed cross-platform under
>GCL at the present time via run-process.  Please check out the maxima
>webpages for soem very pretty pictures (aka dazzling eye candy :-))!
>  
>
I have nothing against gnuplot per se, and I think it would be great
to have it as an add-on to Axiom (as is currently done in Maxima
and Reduce).. But I do not think that it in any way replaces Axiom's
native graphics capabilities - especially when it comes to 3-d graphics.

\start
Date: 29 Apr 2005 11:24:27 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: axiom graphics and porting

Greetings!

Bill Page writes:

> In the context of this discussion let me recall a much earlier
> email from Mike Dewar:
> 
> http://lists.gnu.org/archive/html/axiom-developer/2002-11/msg00151.html
> 
> Re: Windows front end
> Subject: 	Re: Windows front end
> Date: 	Fri, 29 Nov 2002 10:24:19 +0000
> 
> On Thu, Nov 28, 2002 at 10:35:20AM -0500, Tim Daly wrote:
> <snip> 
> > Mike Dewar wrote:
> > I'm happy to hear that work was done to make the graphics more open.
> > One of the stated goals on the homepage is to "give away" the graphics.
> > I was planning to enhance the abilities of some other open source
> > product (like GNUPlot) with the facilities available in Axiom. That
> > way they gain with new function and we gain because we don't have to
> > support the graphics any more.
> 
> I think we looked at GNUPlot and decided it wasn't good enough because
> it lacked many of the features for manipulating 3D images that were in
> the Unix version.  Using Open Inventor/VRML means you can export images
> to industrial-strength visualisation packages which was important to us.
> After we released Axiom under Windows, Maple moved their graphics onto
> OpenGL (the toolkit Open Inventor is built on) so we're not the only
> people who think that this is a good approach :-) Of course GNUplot has
> probably come a long way since we looked at it and may be suitable for
> your needs, but I doubt its as good as Mathematica and Maple's
> offerings.
> 

This is the concrete issue that needs to be worked out at this point,
IMHO.  It would be a great service if someone could detail exactly
what graphics manipulations axiom relies on, and compares this list
with the most recent gnuplot's (version 4 if I recall) abilities.
Then we can see which is more 'industrial-strength' in the open source
world, an important consideration, IMHO.  Needless to say, this term
is not synonymous with commercial.

\start
Date: 29 Apr 2005 11:08:37 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: axiom freebsd changes
Cc: Mike Thomas, Mark Murray

Greetings!

Tim Daly writes:

> Mark, Camm,
> 
> I completed the merge of axiom--main--1 and axiom--BSD--1.
> 
> The build fails using the new loading scheme (in particular the
> change to CMD0 in src/boot/Makefile.pamphlet). Each generated .o
> file, when loaded, gives the following failure:
> 
> /home/axiom--main--1--patch-33/obj/linux/boot/tyextra.o(.text+0xab4): In function `init_code':
> :multiple definition of `init_code'
> /home/axiom--main--1--patch-33/obj/linux/boot/boothdr.o(.text+0x0): first defined here
> 
> I've backed out this change.
> 

Somewhere, I think you have omitted a (setq si::*default-system-p* t)

Here is my suggestion:

   Shortly (perhaps this weekend), I'll put out a 2.6.7 for axiom.
   I'd like to hold off until gcl-tk can be fixed on Windows, but if
   this proves involved, it will wait for 2.6.8.  Included will be all
   the patches on the errata file, the server sockets patch I posted
   in preliminary form yesterday, and a backport from 2.7.0 of the
   :native-reloc entry in *features*.  Please let me know asap if I am
   forgetting anything.

   I suggest you conditionalize the new compiler::link stuff with
   #-native-reloc and treat bsd and linux identically.  Then, the more
   complicated and limited image building steps will only be triggered
   on mips,alpha.ia64 and hppa for GCL 2.6.x, and hopefully no
   platforms for 2.7.0 when it comes out.  Right now, 2.7.0 has
   :native-reloc implemented for mips and alpha. 

   The first call to compiler::link in making the 'lisp' image should
   remain across the board, as this will enable you to dispense with
   the EXTRAS manipulation and load in libspad.a from within gcl, as
   we discussed at the conference.  The other calls, generating
   bootsys, depsys, and interpsys respectively, are only required
   where :native-reloc is not provided and should be ommitted when not
   necessary.

   Once GCL is built, there is no difference between bsd and Linux as
   far as these considerations go.

   Once this is done, I'll be happy to put this together explicitly if
   needed. 

\start
Date: 01 May 2005 16:22:41 -0400
From: Camm Maguire
To: rlbk@melix.net
Subject: What is unexec and why does it fail ?
Cc: Robert Boyer, Aurelien Chanudet, Warren Hunt

Greetings!

Aurelien Chanudet writes:

> > Beyond the axiom issue discussed below, some acl2
> > users at the
> > University of Texas are running into difficulties
> > with the mac code
> > when making very large images.  Would you have a
> > chance to try to
> > build ACL2 with maxpages doubled, quadrupled, and
> > even multiplied by 8
> > if you OS allows?  Please let me know if you have
> > some time to
> > investigate this.  I can send you more information
> > if so.
>
> What version of ACL2 and gcl are these people using ?
> Will try to give this a look as time permits. By the
> way, what's the status of SGC on the Mac now ? There
> have been some recent issues as far as I remember.
>

Aurelien, I know life is likely very hectic at the moment, but if by
chance you happen to be able to look into this with the newly created
branch Versin_2_6_7pre in the next few days, that would be fantastic!
Trying to move this out before my own schedule closes in ....


Take care,


> > What dedication!  Is this a known issue on the Mac?
> > Any help from the
> > gdb developers?
>
> This is a known issue on the Mac, albeit one that
> interests no one but me (for understandable reasons, I
> feel it way more confortable to debug SGC in GCL using
> gdb than using printf debugging). Basically, attaching
> gdb to a process, say GCL, which handles segfaults on
> its own, makes it impossible for the signal handler to
> be called. Gdb will simply refuse to pass the
> exception to the program. This is due to the way
> traditionnal Unix signals are handled in MacOSX's Mach
> kernel. Traditionnal signals are handled by a BSD
> layer which gdb bypasses...
>
> > I'm not sure what you mean here.  Its in the CVS
> > head tree (aka 2.7.0)
> > to my understanding.  Should I post it to the
> > website on the errata
> > page?
>
> It must be fine then. I must confess I'm not "CVS
> savvy". I just wanted to make sure that the file can
> be retrieved when using the basic "cvs login / cvs co"
> sequence.
>
> > 1) Add reloc records for any symbols relocated to a
> > dlopened library
> >    in a given session, together with whatever
> > section is also needed
> >    to indicate that the image is (now permanently)
> > dynamically linked
> >    against the lib.
> >
> > 2) Merge gprof section info from any loaded .o files
> > into the final
> >    saved image so that profiling will work without
> > having to generate
> >    a fresh image with ld.
>
> Under what form are gprof information stored ?
>
>

\start
Date: Sun, 1 May 2005 17:10:21 -0500
From: Tim Daly
To: list
Subject: axiom porting

*,

We're developing Axiom, a large, general purpose computer algebra
system similar in power to Mathematica and Maple.

Axiom consists of 3 pieces, the algebra, the browser, and the graphics.
The algebra is written on top of common lisp.

The graphics and browser (G/B) are written in C using X11.

The algebra portion of Axiom runs under Windows.
The G/B portion does not. 

We have been discussing porting strategies and one of the possible
strategies is to use McClim. 

Does McClim run on Windows under any common lisp?

\start
Date: Sun, 1 May 2005 17:32:36 -0500
From: Tim Daly
To: Ken Anderson, Jeffrey Morrill
Subject: axiom porting

Ken, Jeffrey, 

We're developing Axiom, a large, general purpose computer algebra
system similar in power to Mathematica and Maple.

Axiom consists of 3 pieces, the algebra, the browser, and the graphics.
The algebra is written on top of common lisp.

The graphics and browser (G/B) are written in C using X11.

The algebra portion of Axiom runs under Windows.
The G/B portion does not. 

We have been discussing porting strategies and one of the possible
strategies is to use McClim. 

I've seen the site http://openmap.bbn.com/~kanderso/lisp/scigraph
as well as some screenshots of the scigraph application. Is this
code free and open source? If so, where can I get this code? I'd
like to use it as a basis for experimenting.

The McClim site (http://mcclim.cliki.net/Examples) seems to think
scigraph will run on McClim. Do you know if this is still true?

\start
Date: Sun, 1 May 2005 17:45:57 -0500
From: Tim Daly
To: list
Subject: axiom porting

*,

Ok, somebody must be listen....

check out the article on slashdot. "Firefox 1.1 Plans Native SVG Support".
don't all look at once, though, as i don't want to slashdot the slashdot
site :-)

SVG built into the browser would be a win. It would be portable, it
would interact with our browser pages coded in html, it would allow
opening a separate browser window with control (maybe). 

\start
Date: Sun, 01 May 2005 20:15:18 -0400
From: Bill Page
To: Tim Daly
Subject: Re: axiom porting

Tim Daly wrote:

>SVG built into the browser would be a win. It would be portable, it
>would interact with our browser pages coded in html, it would allow
>opening a separate browser window with control (maybe). 
>  
>
Yes, I agree that SVG would be a neat addition to Axiom HyperTex and also
to MathAction. There are some very good plug-ins available that work in most
browsers and now both FireFox and Opera are planning to implement it as a
native capability.

How easily could SVG be integrate with Axiom graphics? Should we think of
SVG as being a new output format the what postscript generation works now?

I believe that SVG is primarily a static 2-d graphics format, right? So 
I think
we would still need something like the OpenInventor plug-in to provide
Axiom's "control panel" like scaling, rotation and other 3-d graph 
manipulations.

\start
Date: 02 May 2005 11:36:58 -0400
From: Camm Maguire
To: Bill Page
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas, Bill Page, Tim Daly Jr

Greetings!

Bill Page writes:

> Camm Maguire wrote:
> 
> >...
> >Here are my summary opinions at this point -- feedback most
> >appreciated!  (Just a note of clarification -- tcl/tk, which exists in
> >GCL now and is a portable scripting language, is *not the same* as
> >GTK+, an extremely widely used C library with multi-language bindings
> >running 'in-process')
> >
> >=========================================================================
> >Goal: generic GCL gui  -- short term
> >=========================================================================
> >
> >1) get the somewhat clunky but serviceable gcl-tk (i.e. tcl/tk)
> >   working on all platforms as quickly as possible (Need feedback from
> >   Mike and/or Bill)
> >
> For axiom's purposes on Windows I am not fond of this idea until and
> unless we already had a gcl-tk frontend for Axiom working under Linux.
> So I wouldn't push the "all platforms" requirement until we see how far
> this can go on a platform where this would (in principle) be easier (Linux).
> 
> But as I said before, perhaps there are good reasons to pursue this
> in GCL other than Axiom.
> 

The gcl-tk stuff I posted earlier is at least an option which works
with axiom as currently distributed on Linux.  My feeling is that it
is likely also a low hanging fruit on Windows.  In the longer term,
one might supplement or replace with lisp functions outputting html to
a browser over a server socket.  This will be supported without
patches in 2.6.7.  Anyone can experiment with cvs branch
Version_2_6_7pre should they desire.

> >========================================================================
> >
> >Goal: portable axiom hypertex
> >
> >========================================================================
> >
> >This would appear best served by Bill Page's browser idea with GCL
> >server sockets.  For now, I will work on providing
> >fork()/CreateProcess() options, and select/stdio multiplexing options,
> >to the si::socket function call. ...
> >
> I would like to understand how this "stdio multiplexing" thing will
> work. Will it allow Axiom to simultaneously answer both command
> line input and input/output via HTTP in a manner similar to Axiom's
> current HyperTex browser?
> 

My thought was to provide a system variable naming a list of socket
streams to watch, and have the GCL call to read on stdin be preceded
by a call to select, effectively having GCL process stdin and any
socket connections one at a time in the order in which data presents
itself thereon.  This serialization might bog things down if big jobs
are running on a given socket.  I was not planning any transparent
interrupt facility, though this could also work, as is apparently the
mechanism in gcl-tk.

In cvs branch Version_2_6_7pre, I've already implemented the other
option of having GCL fork a background process to serve a socket,
effectively letting the OS do the multitasking.  This will need a bit
more magic on windows.  The final option of having the user call the
socket serving function should be available on all platforms now.

> Or do we only have to modify the read-process-output loop in
> Axiom so that it accepts HTTP input instead of Axiom's native
> HyperTex session input?

I was thinking more low level than this, though axiom would have to
instruct gcl to multiplex any given socket, by pushing the stream to
a special list.  The currently implemented fork option will be cleaner
if we can get similar working on Windows.

> 
> Of course besides the HyperTex documentation, tutorial and Axiom
> library navigation, there is still the issue of mathematical notation
> support
> in the browser. NAG also did a lot of work on OpenMath which in
> principle could be salvaged to provide math output in MathML
> format which is now becoming quite mature in the newer browsers.
> Techexplorer provided inline LaTeX rendering in the browser and
> that would be hard to duplicate on the desktop without adding
> much more overhead with things like LaTeX and dvipng (the way
> we work now on the MathAction server).

We could also either inline some of the source from these projects for
these purposes into GCL (quite easy with compiler::link), or fork two
sockets to keep latex and/or dvipng processes running and waiting for
incremental input for performance reasons using run-process.

> 
> >=============================================================================
> >
> >Goal: portable axiom graphics
> >
> >=============================================================================
> >
> >This is unlikely to be well serviced by a web browser, and only
> >modestly well-serviced by a standard gui, as axiom's demands on plot
> >manipulation are likely to require such detail as canned 'widgets' are
> >unlikely to be available.
> >
> As I currently understand in theory Axiom graphics can be served using
> NAG's OpenInventor extensions of to the Axiom graphics program together
> with either OpenInventor itself (now open source) or a compatible VRML
> plug-in for a standard browser.
> 

Sounds like another forked process.  The complication here will be
working out the interprocess communication.  client/server in either
direction is not a problem, but current gcl-tk style gui/terminal
process sharing will take some work.


> >I really feel gnuplot is the best tool here
> >in the medium term, which can be fully accessed cross-platform under
> >GCL at the present time via run-process.  Please check out the maxima
> >webpages for soem very pretty pictures (aka dazzling eye candy :-))!
> >
> I have nothing against gnuplot per se, and I think it would be great
> to have it as an add-on to Axiom (as is currently done in Maxima
> and Reduce).. But I do not think that it in any way replaces Axiom's
> native graphics capabilities - especially when it comes to 3-d graphics.
> 

Perhaps not for interactive rotations and the like, but gnuplot's
static 3d capabilities are impressive, at least to me.  And those new
coloring extensions in version 4 and greater as illustrated on the
maxima page are outstanding in my opinion.

\start
Date: Sun, 1 May 2005 18:40:37 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: axiom porting

--- Tim Daly wrote:

[snip]

> I've seen the site http://openmap.bbn.com/~kanderso/lisp/scigraph
> as well as some screenshots of the scigraph application. Is this
> code free and open source? If so, where can I get this code? I'd
> like to use it as a basis for experimenting.

Sorry if I'm jumping in:

Scigraph is included in the McCLIM release in the Apps directory:
http://common-lisp.net/cgi-bin/viewcvs.cgi/mcclim/Apps/Scigraph/?cvsroot=mcclim

> The McClim site (http://mcclim.cliki.net/Examples) seems to think
> scigraph will run on McClim. Do you know if this is still true?

Some fixes were checked in a while back and I tested it out - it did
work, except I think for pop-up menus.  Haven't tried it recently -
I'll start building and see if it still does.

\start
Date: Mon, 02 May 2005 19:41:32 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [MathActionRepository] axiom--main--1 updated to patch 34

The darcs repository for the Axiom source distribution has been
updated to axiom--main--1--patch-34 from the arch repository of
Saturday, April 30, 2005 3:43 PM as posted by Tim Daly.

\start
Date: Tue, 3 May 2005 11:47:39 +1000
From: Mike Thomas
To: Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Bill Page, Tim Daly Jr

Hi Camm.


EXCUSES

'Twas a long weekend here and I made full use of it for non-programming
purposes.  It looks from the CVS log and the Axiom/GCL 2.6.7 related email
that there's a lot to catch up with.

Random thoughts follow.


2.6.7PRE

I just checked that 2.6.7pre builds on Windows.  Will likewise test Maxima
etc as the week progresses.

What I need is some Lisp test code and simple instructions to check whatever
network functionality you've added which you hope will work straight off
under Windows.

Please also tell me your time frame for getting 2.6.7 finalised and I'll try
without promises to address GCL-TK within those limits.


SIGNALS AND WINDOWS

Are you implying (in some other email over the past few days) that SIGUSR1
is used in the handshaking between the TK server and GCL?

I take it SIGUSR1 is a user definable signal?

The signal question you raise there is a can of worms partly because I'm not
au fait with their use, but also in the sense that although GCL already has
a mechanism for attempting to emulate the receipt within GCL of fake signals
passed by another process (or from withing GCL), that mechanism requires the
other process (or GCL) to implement it's own special code to actually send
the fake signal in the first place.  That system (shared memory) is used by
XMaxima to fake up SIGKILL.  Once you have reached this stage you have to
ask yourself whether it would have been better to just use a Windows
mechanism in the first place.  The other signals you mention are completely
different in terms of the relevant Windows system functionality if such even
exists (I'm thinking here of the profiling, memory fault handling and
sigio).


FORK() VS THREADS

If you go too far in the emulation direction, you also then have to ask
yourself whether you shouldn't be using Cygwin in the first place,
particularly with respect to fork().  When last I heard (several years ago)
Cygwin fork() had problems with sockets after the clone is done. (GRASS used
this mechanism for it's display server on Unix and Cygwin and never really
resolved the issues.  My memory is that the MLton compiler gave up on Cygwin
fork() just a few months ago.)  Lets face it, forked socket servers are one
of the main reasons people fork() in the first place.  Furthermore, Cygwin
fork() is not efficient in terms of either space or time.  If you choose to
use Cygwin you then close the circle and have an application which is
problematic to distribute and support which means you might as well tell
your users to use Linux (I admire Linux/*BSD/Cygwin and even X by the way,
don't get me wrong).

Ultimately, threads are the way to go in respect of this kind of
functionality on Windows but of course, we have to find the time and
know-how.


GUI BACKENDS

Time and know-how again whatever the path - I originally chose JAPI
precisely because I could implement a GUI library in a couple of hours;
hopefully GCL-TK can be salvaged on Windows in a similarly short time frame.
Other compiler projects I am aware of farm library work (especially large
open ended GUI library projects such as GTK, OpenGL, WXWidgets bindings) out
to helpers.  The GCL project is short staffed as it is, with you (Camm) the
only seriously committed developer we have.

\start
Date: Mon, 2 May 2005 22:57:34 -0500
From: Tim Daly
To: Camm Maguire
Subject: tkconnect

Camm,

re: your TK example.

tkconnect fails.
it appears to be looking for gcltksrv which does not exist on my system.
i presume this is because i failed to set a configure option.
suggestions?

shelter seems to have done a very nice job on this effort.
i like the way he structured the lisp/tk bindings.

\start
Date: Mon, 02 May 2005 23:24:19 -0500
From: MathAction (loli)
To: MathAction
Subject: [#151 Environment variable AXIOM] (new) 

I build axiom on a Suse 9.2 and the first time I run axiom I got many error messages similar to the reported ones of issue 147.

I "fixed it" by changing the first line os axiom script::
    AXIOM=/usr/local/axiom/mnt/linux
with::
    export AXIOM=/usr/local/axiom/mnt/linux

\start
Date: Mon, 02 May 2005 23:38:37 -0500
From: MathAction (loli)
To: MathAction
Subject: [#152 Symbolic link SPADEDIT] (new) 

It seems that if one wants the command::

    )edit

to work, a symbolic link to the preferred editor
has to be created in (for linux..)  ::

   /usr/local/axiom/mnt/linux/lib/@SPADEDIT

\start
Date: Mon, 02 May 2005 23:57:16 -0500
From: MathAction (loli)
To: MathAction
Subject: [#153 make install does not install a needed libdb.text for HyperDoc] (new) 

HyperDoc->Browse->Complete needs a file::

    /usr/local/axiom/mnt/linux/int/algebra/libdb.te

xt

Searching for files with that name I found 4. I think the appropiate one was created during "make"::

 ...../axiom/int/algebra/libdb.text

I copied it and it seems to work.

\start
Date: Tue, 3 May 2005 06:26:49 -0400 
From: Bill Page
To: Mike Thomas, Camm Maguire
Subject: Re: [Gcl-devel] Simple web server code for GCLfor Windows

On Thursday, April 28, 2005 7:38 PM Mike Thomas wrote:

> Camm wrote:
>
> > Greetings!  Here's a quick way to get started:
> > ==================================================================
> > camm@intech19:/fix/t1/camm/debian/gcl/gcl-2.6.6$ diff -u
> > ../gcl-2.6.5/o/file.d o/file.d
> > --- ../gcl-2.6.5/o/file.d	2004-05-07 21:48:58.000000000 +0000
> > +++ o/file.d	2005-04-28 16:21:33.000000000 +0000
> >
> ...
>
> > >(bar 8080 #'foo)
> > ==================================================================
> > Then point your browser to localhost:8080.  You should be able to get
> > directory listings and files.
>
> I modified the test program to print stuff out and using port 8085
> to get around IIS I was able to get a web page back with the following
> text:
>
>  /TMP /win32app /WINDOWS
>
>from the following input into my browser:
>
>  http://localhost:8085/dir
>
> So it looks like your patch works on Windows Camm to a first
> approximation - you truly are a wunderkind Camm!

Using Version_2_6_7pre compiled on Windows I am not able
to reproduce this success. I tried:

---------

bpage@PAGE ~/axiom--windows--1/gcl/unixport
$ saved_gcl
GCL (GNU Common Lisp)  2.6.7 CLtL1    May  3 2005 03:46:01
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

(defun foo (s) 
  (let* ((get (read s nil 'eof)) 
         (fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
         (fn (when (probe-file fn) fn)))
    (format s "HTTP/1.1 ~S~%~%" (if fn 404 500))
    (when fn
      (if (pathname-name (pathname fn))
          (with-open-file (q fn) (si::copy-stream q s))
        (dolist (l (directory fn)) (format s "~a~%" (namestring l)))))
    (close s))

)

(defun bar (p fn) 
  (let ((s (si::socket p :server fn))) 
        (tagbody l 
                (when (si::listen s) 
                        (let ((w (si::accept s))) 
                                (foo w))) 
                (sleep 3) 
                (go l))))

(bar 8085 #'foo)

---------

Sits there and spins. If I go to my browser (FireFox 1.0.3) and
enter the url

http://localhost:8085/dir

after a short pause the browser returns with no error
but the page is empty.

Any ideas? Mike, could you send me your "modified test program
that prints stuff out"?

Regards,
Bill Page.


\start
Date: Tue, 3 May 2005 07:08:47 -0400 
From: Bill Page
To: Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas, Tim Daly Jr

On Monday, May 02, 2005 11:37 AM Camm Maguire wrote:

> The gcl-tk stuff I posted earlier is at least an option which works
> with axiom as currently distributed on Linux.  My feeling is that
> it is likely also a low hanging fruit on Windows.  In the longer
> term, one might supplement or replace with lisp functions outputting
> html to a browser over a server socket.  This will be supported
> without patches in 2.6.7.  Anyone can experiment with cvs branch
> Version_2_6_7pre should they desire.

This sounds like a good plan to me.

> Bill Page wrote:
> >
> > I would like to understand how this "stdio multiplexing" thing
> > will work. Will it allow Axiom to simultaneously answer both
> > command line input and input/output via HTTP in a manner similar
> > to Axiom's current HyperTex browser?
> 
>
> My thought was to provide a system variable naming a list of
> socket streams to watch, and have the GCL call to read on stdin
> be preceded by a call to select, effectively having GCL process
> stdin and any socket connections one at a time in the order in
> which data presents itself thereon.
> ...

Perhaps in the general case we might need to "multiplex" both
stdin and stdout in pairs. One process like the HyperTeX
browser might send commands to Axiom, then receive the output
(or a copy of the output) and format it for inline display in
the browser. Meanwhile, a user might also type input commands
directly to the Axiom windows.

> In cvs branch Version_2_6_7pre, I've already implemented the
> other option of having GCL fork a background process to serve
> a socket, effectively letting the OS do the multitasking.
> This will need a bit more magic on windows.  The final option
> of having the user call the socket serving function should be
> available on all platforms now.

Hmmm... perhaps that explains why I don't seem to be able to
get Version_2_6_7pre to run the web server program properly
under windows?

I guess I should revert to applying your patches to gcl 2.6.6
and see if I can at least get that to work on Windows...

> ...
> We could also either inline some of the source from these projects
> for these purposes into GCL (quite easy with compiler::link), or
> fork two sockets to keep latex and/or dvipng processes running and
> waiting for incremental input for performance reasons using run-process.

I like that idea. Right now on MathAction new processes are started
by the Python latexwiki module (a Zope extension) for each call to
latex and ghostscript (used instead of dvipng in earlier versions
of latexwiki). This does represent a considerable overhead when
saving a page. And if we were to use latex and dvipng on the desktop
this would certainly be even more noticable.

> >
> > As I currently understand in theory Axiom graphics can be served
> > using NAG's OpenInventor extensions of to the Axiom graphics
> > program together with either OpenInventor itself (now open source)
> > or a compatible VRML plug-in for a standard browser.
> 
>
> Sounds like another forked process.  The complication here will be
> working out the interprocess communication.  client/server in either
> direction is not a problem, but current gcl-tk style gui/terminal
> process sharing will take some work.

OpenInventor can run as a browser plug-in. In that case the browser
would handle the interprocess communication via HTTP. If we chose
to run OpenInventor as a stand alone viewer, then it would of
course have to do handle this itself. I presume that NAG has
already addressed this issue in their extension of Axiom graphics
for Windows.

> [Bill Page claimed: Axiom graphics is superiou]

> > Perhaps not for interactive rotations and the like, but
> > gnuplot's static 3d capabilities are impressive, at least
> > to me.  And those new coloring extensions in version 4
> > and greater as illustrated on the maxima page are outstanding
> > in my opinion.

Have you seen the graphics examples in the Axiom book? :)

\start
Date: 03 May 2005 10:04:03 -0400
From: Camm Maguire
To: Bill Page
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas, Tim Daly Jr

Greetings!

Bill Page writes:

> On Monday, May 02, 2005 11:37 AM Camm Maguire wrote:
> 
> > The gcl-tk stuff I posted earlier is at least an option which works
> > with axiom as currently distributed on Linux.  My feeling is that
> > it is likely also a low hanging fruit on Windows.  In the longer
> > term, one might supplement or replace with lisp functions outputting
> > html to a browser over a server socket.  This will be supported
> > without patches in 2.6.7.  Anyone can experiment with cvs branch
> > Version_2_6_7pre should they desire.
> 
> This sounds like a good plan to me.
> 
> > Bill Page wrote:
> > >
> > > I would like to understand how this "stdio multiplexing" thing
> > > will work. Will it allow Axiom to simultaneously answer both
> > > command line input and input/output via HTTP in a manner similar
> > > to Axiom's current HyperTex browser?
> > 
> >
> > My thought was to provide a system variable naming a list of
> > socket streams to watch, and have the GCL call to read on stdin
> > be preceded by a call to select, effectively having GCL process
> > stdin and any socket connections one at a time in the order in
> > which data presents itself thereon.
> > ...
> 
> Perhaps in the general case we might need to "multiplex" both
> stdin and stdout in pairs. One process like the HyperTeX
> browser might send commands to Axiom, then receive the output
> (or a copy of the output) and format it for inline display in
> the browser. Meanwhile, a user might also type input commands
> directly to the Axiom windows.
> 

lisp has a rich stream structure for such purposes.  input streams,
output streams, two-way streams, synonym streams, concatenated streams
... 


> > In cvs branch Version_2_6_7pre, I've already implemented the
> > other option of having GCL fork a background process to serve
> > a socket, effectively letting the OS do the multitasking.
> > This will need a bit more magic on windows.  The final option
> > of having the user call the socket serving function should be
> > available on all platforms now.
> 
> Hmmm... perhaps that explains why I don't seem to be able to
> get Version_2_6_7pre to run the web server program properly
> under windows?
> 

If you are referring to the separately posted example, I am hoping
that the GCL code is working but your empty page results for a missing
system directory or file.

> I guess I should revert to applying your patches to gcl 2.6.6
> and see if I can at least get that to work on Windows...
> 

Unless I really erred, which is quite possible, the patch to 2.6.6 is
already in 2.6.7pre.

> > ...
> > We could also either inline some of the source from these projects
> > for these purposes into GCL (quite easy with compiler::link), or
> > fork two sockets to keep latex and/or dvipng processes running and
> > waiting for incremental input for performance reasons using run-process.
> 
> I like that idea. Right now on MathAction new processes are started
> by the Python latexwiki module (a Zope extension) for each call to
> latex and ghostscript (used instead of dvipng in earlier versions
> of latexwiki). This does represent a considerable overhead when
> saving a page. And if we were to use latex and dvipng on the desktop
> this would certainly be even more noticable.
> 
> > >
> > > As I currently understand in theory Axiom graphics can be served
> > > using NAG's OpenInventor extensions of to the Axiom graphics
> > > program together with either OpenInventor itself (now open source)
> > > or a compatible VRML plug-in for a standard browser.
> > 
> >
> > Sounds like another forked process.  The complication here will be
> > working out the interprocess communication.  client/server in either
> > direction is not a problem, but current gcl-tk style gui/terminal
> > process sharing will take some work.
> 
> OpenInventor can run as a browser plug-in. In that case the browser
> would handle the interprocess communication via HTTP. If we chose
> to run OpenInventor as a stand alone viewer, then it would of
> course have to do handle this itself. I presume that NAG has
> already addressed this issue in their extension of Axiom graphics
> for Windows.
> 
> > [Bill Page claimed: Axiom graphics is superiou]
> 
> > > Perhaps not for interactive rotations and the like, but
> > > gnuplot's static 3d capabilities are impressive, at least
> > > to me.  And those new coloring extensions in version 4
> > > and greater as illustrated on the maxima page are outstanding
> > > in my opinion.
> 
> Have you seen the graphics examples in the Axiom book? :)
> 

Perhaps I should take a second look :-).  Can those pictures be
generated with our current C/X11 graphics on Linux?

\start
Date: Tue, 3 May 2005 16:21:03 -0400 
From: Bill Page
To: Camm Maguire
Subject: RE: Simple web server code for GCLfor Windows
Cc: Mike Thomas

Camm,

You are right. The simple GCL web server program that you
wrote is working on both linux and Windows. Great!

On Tuesday, May 03, 2005 9:56 AM Camm Maguire wrote:

>...
> What this will send to the gcl function 'foo' is 'get /dir'
> #'foo must find a file or directory by that name to produce
> output, which I'm guessing does not exist on your system.
> You can add a diagnostic like: 

(defun foo (s) 
  (let* ((get (read s nil 'eof)) 
         (fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
         (fn (when (probe-file fn) fn)))
    (format s "HTTP/1.1 ~S~%" (if fn 404 500))
    (format s "Content-type: text/html~%~%")
    (format t "get ~a fn ~a~%" get fn)
    (when fn
      (if (pathname-name (pathname fn))
          (with-open-file (q fn) (si::copy-stream q s))
        (dolist (l (directory fn)) (format s "~a~%" (namestring l)))))
    (close s))
)

> You can also do 'telnet localhost 8085' and type 'get /dir'
> to see the output, which I think is likely '404' in my pseudo
> html error code example. 

Thanks. This works exactly as you claim. For example on my system

  http://localhost:8085/msys/1.0/home/bpage/

produces a list of files and

  http://localhost:8085/msys/1.0/home/bpage/repository.html

displays the web page in a browser (See Content-type above).

Just to play a little (although I know almost knowing about
lisp :) I also changed the file list to HTML format like this:

 (format s "<a href=\"~a\">~a</a> <a href=\"~a/\"> /... </a><br>~%"
   (namestring l) (namestring l) (namestring l)))

It would be nicer to make the result and the content type depend
on whether something was a directory or on the type of the file
etc instead of the syntax of the name, but I could not easily
discover how to do that in GCL. Specifically how can I tell a
directory from a file? Can anyone suggest a suitable "Getting
started in GCL" tutorial?

Anyway, it seems clear that we could use this approach to develop
a portable HyperTex browser for Axiom if we decide to go that
root.

\start
Date: Tue, 3 May 2005 20:00:25 -0400 
From: Bill Page
To: Mike Thomas
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Camm Maguire

Mike,

On Tuesday, May 03, 2005 7:01 PM you wrote:

> Bill Page wrote:
> |
> | Hmmm... perhaps that explains why I don't seem to be able to
> | get Version_2_6_7pre to run the web server program properly
> | under windows?
>
> Looks like it Bill:
>
> $ ./unixport/saved_ansi_gcl.exe
> GCL (GNU Common Lisp)  2.6.7 ANSI    May  3 2005 09:54:15
> ...
> >(load "c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.lsp")
>
> Loading c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.lsp
> Error in LET [or a callee]: Error "No such file or directory"
> on accepting connction to #<two-way stream 104d45c4>
> ...

No it turns out that I was wrong. The attached file does run as
expected on my windows Version_2_6_7pre gcl. But notice two
things:

1) I am not using the ANSI build.
2) The input from the browser is very picky and the server
   code does *no* error checking.

The url path coincides with the root. To display a directory
the url must end in / So on my system

  http://localhost:8085/msys/1.0/home/

displays the directory `c:\msys\1.0\home'. If the url does
not end in / then it is assumed to be a file (html format in
my version, or plain text by default). If the directory or
file does not exist then the server program stops. It works
but there is a lot of room for improvement.

> |
> | I guess I should revert to applying your patches to gcl 2.6.6
> | and see if I can at least get that to work on Windows...

I did not have to do this.

> Interestingly, today I can't get that to work properly either
> insofar as getting the directory listsing you obtain.

I think you must have one too many simultaneous variables that
are affecting your results ... :)

Here are a few links to other people doing http and html in lisp:

http://claws.sourceforge.net/

"The CLAWS is aimed to provide a complete framework for developing
Web applications in Common Lisp. The project is in very early
stage, so no actual code is released (though something can be found
in CVS)."

http://www.franz.com/support/tutorials/
http://www.franz.com/support/tutorials/aserve-tutorial.htm
http://www.franz.com/support/documentation/7.0/doc/aserve/aserve.html
http://opensource.franz.com/aserve/aserve-dist/doc/aserve.html

"AllegroServe is an HTTP server and HTML generator for Lisp. As
with other HTTP servers, such as Apache (Unix) or the Internet
Information Services (Windows), AllegroServe can be used to deliver
web pages and other data over a TCP/IP network (such as the Internet)
to internet browsers such as Firefox, Mozilla, and the Internet
Explorer."

http://sourceforge.net/projects/portableaserve

"A free and portable Common Lisp Webserver. Portable AllegroServe
is a variant of AllegroServe(tm) with an explicit emphasis on
portability between Lispsystems and Operating Systems."

http://www.ai.mit.edu/projects/iiip/doc/cl-http/server.html
http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
http://www.ai.mit.edu/projects/iiip/conferences/luv95/tutorial.html

"Major components include a mature HTTP 1.1 server, a robust
caching proxy server, a programmatic client, a constraint-guided
Web Walker, a full-text indexation & retrieval, along with a
variety of Web-related tools and contributions."

------_=_NextPart_000_01C5503C.4632EE90
	name="test-http.lsp"
	filename="test-http.lsp"

(defun foo (s) 
  (let* ((get (read s nil 'eof)) 
         (fn (and (eq get 'get) (string-downcase (read s nil =
'eof))))
         (fn (when (probe-file fn) fn)))
    (format s "HTTP/1.1 ~S~%" (if fn 404 500))
    (format s "Content-type: text/html~%~%")
    (format t "get ~a fn ~a~%" get fn)
    (when fn
      (if (pathname-name (pathname fn))
          (with-open-file (q fn) (si::copy-stream q s))
        (dolist (l (directory fn))
          (format s "<a href=\"~a\">~a</a> <a href=\"~a/\"> /... =
</a><br>~%"
	    (namestring l) (namestring l) (namestring l)))
	    ))
    (close s))
)

(defun bar (p fn) 
  (let ((s (si::socket p :server fn))) 
        (tagbody l 
                (when (si::listen s) 
                        (let ((w (si::accept s))) 
                                (foo w))) 
                (sleep 3) 
                (go l))))

(bar 8085 #'foo)


------_=_NextPart_000_01C5503C.4632EE90--

\start
Date: Wed, 4 May 2005 09:00:56 +1000
From: Mike Thomas
To: Bill Page, Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Tim Daly Jr

Hi Bill/Camm.

| > In cvs branch Version_2_6_7pre, I've already implemented the
| > other option of having GCL fork a background process to serve
| > a socket, effectively letting the OS do the multitasking.
| > This will need a bit more magic on windows.  The final option
| > of having the user call the socket serving function should be
| > available on all platforms now.
|
| Hmmm... perhaps that explains why I don't seem to be able to
| get Version_2_6_7pre to run the web server program properly
| under windows?

Looks like it Bill:

$ ./unixport/saved_ansi_gcl.exe
GCL (GNU Common Lisp)  2.6.7 ANSI    May  3 2005 09:54:15
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

>(load "c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.lsp")

Loading c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.lsp
Error in LET [or a callee]: Error "No such file or directory" on accepting
conn
ction to #<two-way stream 104d45c4>


Fast links are on: do (use-fast-links nil) for debugging
Broken at SYSTEM:ACCEPT.  Type :H for Help.
 1 (Continue) Retry loading file
"c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.l
p".
 2 (Abort) Return to top level.
dbl:>>:bt

#0   ACCEPT {loc0=#<two-way stream 104d45c4>} [ihs=13]
#1   BAR {lambda-block=foo,} [ihs=8]
#2   CLCS-LOAD {file=nil,args=nil,g2549=nil,loc3=(lambda-block bar (p fn)
...),
oc4=8085,loc5=(...} [ihs=7]
#3   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function
conditions::clcs
load>,loc4...} [ihs=6]
#4   TOP-LEVEL
{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7
"c:/cvs/stable/...} [ihs=5]
#5   FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
NIL

|
| I guess I should revert to applying your patches to gcl 2.6.6
| and see if I can at least get that to work on Windows...

Interestingly, today I can't get that to work properly either insofar as
getting the directory listsing you obtain.

\start
Date: 03 May 2005 09:49:36 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: tkconnect

Greetings!

Tim Daly writes:

> Camm,
> 
> re: your TK example.
> 
> tkconnect fails.
> it appears to be looking for gcltksrv which does not exist on my system.
> i presume this is because i failed to set a configure option.
> suggestions?
> 

GCL's configure should autodetect the presence of tk development files
at build time.  In other words, you need tk8.4-dev and dependencies
installed before configuring and building GCL, otherwise you get the
string "gcl-tk not made" in the build output.  

If you are on Debian and want a quick test, you should be able to
'apt-get install gcl', which will pull in tk automatically, and point
tkconnect to the gcltksrv therein.  tkconnect can take arguments
specifying the path to gcltksrv:

     tkconnect &key host display can-rsh gcltksrv

I prefer (reset-sys-paths....) as in my posted example, as this sets
the load-path and related variables as needed as well.

Take care,

> shelter seems to have done a very nice job on this effort.
> i like the way he structured the lisp/tk bindings.
> 

\start
Date: 03 May 2005 09:55:42 -0400
From: Camm Maguire
To: Bill Page
Subject: re: [Gcl-devel] Simple web server code for GCLfor Windows
Cc: Mike Thomas

Greetings!

Bill Page writes:

> On Thursday, April 28, 2005 7:38 PM Mike Thomas wrote:
> 
> > Camm wrote:
> >
> > > Greetings!  Here's a quick way to get started:
> > > ==================================================================
> > > camm@intech19:/fix/t1/camm/debian/gcl/gcl-2.6.6$ diff -u
> > > ../gcl-2.6.5/o/file.d o/file.d
> > > --- ../gcl-2.6.5/o/file.d	2004-05-07 21:48:58.000000000 +0000
> > > +++ o/file.d	2005-04-28 16:21:33.000000000 +0000
> > >
> > ...
> >
> > > >(bar 8080 #'foo)
> > > ==================================================================
> > > Then point your browser to localhost:8080.  You should be able to get
> > > directory listings and files.
> >
> > I modified the test program to print stuff out and using port 8085
> > to get around IIS I was able to get a web page back with the following
> > text:
> >
> >  /TMP /win32app /WINDOWS
> >
> >from the following input into my browser:
> >
> >  http://localhost:8085/dir
> >
> > So it looks like your patch works on Windows Camm to a first
> > approximation - you truly are a wunderkind Camm!
> 
> Using Version_2_6_7pre compiled on Windows I am not able
> to reproduce this success. I tried:
> 
> ---------
> 
> bpage@PAGE ~/axiom--windows--1/gcl/unixport
> $ saved_gcl
> GCL (GNU Common Lisp)  2.6.7 CLtL1    May  3 2005 03:46:01
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> Binary License:  GPL due to GPL'ed components: (UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> 
> (defun foo (s) 
>   (let* ((get (read s nil 'eof)) 
>          (fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
>          (fn (when (probe-file fn) fn)))
>     (format s "HTTP/1.1 ~S~%~%" (if fn 404 500))
>     (when fn
>       (if (pathname-name (pathname fn))
>           (with-open-file (q fn) (si::copy-stream q s))
>         (dolist (l (directory fn)) (format s "~a~%" (namestring l)))))
>     (close s))
> 
> )
> 
> (defun bar (p fn) 
>   (let ((s (si::socket p :server fn))) 
>         (tagbody l 
>                 (when (si::listen s) 
>                         (let ((w (si::accept s))) 
>                                 (foo w))) 
>                 (sleep 3) 
>                 (go l))))
> 
> (bar 8085 #'foo)
> 
> ---------
> 
> Sits there and spins. If I go to my browser (FireFox 1.0.3) and
> enter the url
> 
> http://localhost:8085/dir
> 
> after a short pause the browser returns with no error
> but the page is empty.
> 
> Any ideas? Mike, could you send me your "modified test program
> that prints stuff out"?
> 

What this will send to the gcl function 'foo' is 'get /dir'  #'foo
must find a file or directory by that name to produce output, which
I'm guessing does not exist on your system.  You can add a diagnostic
like: 

(defun foo (s) 
  (let* ((get (read s nil 'eof)) 
         (fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
         (fn (when (probe-file fn) fn)))
    (format s "HTTP/1.1 ~S~%~%" (if fn 404 500))
    (format t "get ~a fn ~a~%" get fn)
    (when fn
      (if (pathname-name (pathname fn))
          (with-open-file (q fn) (si::copy-stream q s))
        (dolist (l (directory fn)) (format s "~a~%" (namestring l)))))
    (close s))

)

You can also do 'telnet localhost 8085' and type 'get /dir' to see the
output, which I think is likely '404' in my pseudo html error code
example. 

\start
Date: 04 May 2005 13:41:02 -0400
From: Camm Maguire
To: Bill Page
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas, Paul F. Dietz

Greetings!

Bill Page writes:

> Mike,
> 
> On Tuesday, May 03, 2005 7:01 PM you wrote:
> 
> > Bill Page wrote:
> > |
> > | Hmmm... perhaps that explains why I don't seem to be able to
> > | get Version_2_6_7pre to run the web server program properly
> > | under windows?
> >
> > Looks like it Bill:
> >
> > $ ./unixport/saved_ansi_gcl.exe
> > GCL (GNU Common Lisp)  2.6.7 ANSI    May  3 2005 09:54:15
> > ...
> > >(load "c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.lsp")
> >
> > Loading c:/lang/source/gcl/gcl-2.6.6-ansi/http-test.lsp
> > Error in LET [or a callee]: Error "No such file or directory"
> > on accepting connction to #<two-way stream 104d45c4>
> > ...
> 
> No it turns out that I was wrong. The attached file does run as
> expected on my windows Version_2_6_7pre gcl. But notice two
> things:
> 
> 1) I am not using the ANSI build.

OK, I've just tested on Linux under ANSI, and it works the same for
me (as it should).  If this is not the case on Windows, please someone
let me know asap.

> 2) The input from the browser is very picky and the server
>    code does *no* error checking.
> 
> The url path coincides with the root. To display a directory
> the url must end in / So on my system
> 
>   http://localhost:8085/msys/1.0/home/
> 
> displays the directory `c:\msys\1.0\home'. If the url does
> not end in / then it is assumed to be a file (html format in
> my version, or plain text by default). If the directory or
> file does not exist then the server program stops. It works
> but there is a lot of room for improvement.
> 

OK, I think I finally understand your earlier comment about
directory/filename distinction.  I've quickly scanned the hyperspec on
this and can't find the relevant section, so am referring this to our
resident expert Paul Dietz/  

Paul -- Can a compliant lisp implementation return some discernibly
special type of stream yielding directory entries on read, perhaps in
list form, when a path like /mydir or /mydir/ is supplied to open?
What is the best way to do this?

As for bombing when the file is not there, this would appear to be an
error in probe-file on Windows.  The 'server' example is supposed to
return a blank page and continue in this case.  Please let me know if
there is a bug here.  (si::use-fast-links nil) and :bt if thrown into
the debugger.  (I do get an error on Linux when the file exists but
cannot be opened due to permissions, for example.)

Looking at this has made me notice a bug -- one can apparently open
streams with directory pathnames, but reading of course fails.  I am
committing changes designed to fix this simply for now, by ensuring
that open_stream and probe-file (and file-write-length, file-author
...) fail (i.e. return nil) on directories.  Eventually we might want
to allow open to succeed, returning a 'user-defined' stream, and have
read thereon return stat structures for the files therein.  The only
standardized interface to directories under lisp I can find is
(directory ...), not surprisingly, so with this set of changes, this
will be the only thing you can do with a pathname that refers to a
directory, trailing slash or not.  I.e.

=============================================================================
>(open "/etc" :if-does-not-exist nil)

NIL

>(open "/etc/" :if-does-not-exist nil)

NIL

>(open "/etc/passwd" :if-does-not-exist nil)

#<input stream "/etc/passwd">

>(directory "/etc")

(#p"/etc")

>(directory "/etc/")

(#p"/etc/R" #p"/etc/X11" #p"/etc/adduser.conf" #p"/etc/adjtime"
 #p"/etc/aliases" #p"/etc/aliases.O" #p"/etc/alternatives" #p"/etc/apm"
 #p"/etc/apt" #p"/etc/at.deny" #p"/etc/autoconf2.13"
 #p"/etc/bash.bashrc" #p"/etc/bash_completion"
 #p"/etc/bash_completion.d" #p"/etc/bonobo-activation"
 #p"/etc/calendar" #p"/etc/chatscripts" #p"/etc/common-lisp"
 #p"/etc/console" #p"/etc/console-tools" #p"/etc/cron.d"
 #p"/etc/cron.daily" #p"/etc/cron.hourly" #p"/etc/cron.monthly"
 #p"/etc/cron.weekly" #p"/etc/crontab" #p"/etc/cups"
 #p"/etc/cvs-cron.conf" #p"/etc/cxref" #p"/etc/debconf.conf"
 #p"/etc/debian_version" #p"/etc/default" #p"/etc/defoma"
 #p"/etc/deluser.conf" #p"/etc/devscripts.conf"
 #p"/etc/dhclient-script" #p"/etc/dhclient.conf" #p"/etc/dhelp"
 #p"/etc/dictionaries-common" #p"/etc/dpkg" #p"/etc/dupload.conf"
 #p"/etc/emacs" #p"/etc/emacs21" #p"/etc/email-addresses"
 #p"/etc/esound" #p"/etc/exim" #p"/etc/exim4" #p"/etc/fdmount.conf"
 #p"/etc/fonts" #p"/etc/fstab" #p"/etc/gconf" #p"/etc/gnome-vfs-2.0"
 #p"/etc/gnome-vfs-mime-magic" #p"/etc/groff" #p"/etc/group"
 #p"/etc/group-" #p"/etc/gs-gpl" #p"/etc/gtk" #p"/etc/gtk-2.0"
 #p"/etc/host.conf" #p"/etc/hostname" #p"/etc/hosts.allow"
 #p"/etc/hosts.deny" #p"/etc/inetd.conf" #p"/etc/init.d"
 #p"/etc/inittab" #p"/etc/inputrc" #p"/etc/issue" #p"/etc/issue.net"
 #p"/etc/kernel-pkg.conf" #p"/etc/lam" #p"/etc/ld.so.cache"
 #p"/etc/ld.so.conf" #p"/etc/ldap" #p"/etc/lintianrc"
 #p"/etc/lisp-config.lisp" #p"/etc/locale.alias" #p"/etc/locale.gen"
 #p"/etc/localtime" #p"/etc/login.defs" #p"/etc/logrotate.conf"
 #p"/etc/logrotate.d" #p"/etc/lprng" #p"/etc/magic" #p"/etc/mail.rc"
 #p"/etc/mailcap" #p"/etc/mailcap.order" #p"/etc/mailname"
 #p"/etc/mailname.O" #p"/etc/manpath.config" #p"/etc/mediaprm"
 #p"/etc/mime.types" #p"/etc/mkinitrd" #p"/etc/modules"
 #p"/etc/modules.conf" #p"/etc/modutils" #p"/etc/motd"
 #p"/etc/mozilla-firefox" #p"/etc/mpich" #p"/etc/mtab" #p"/etc/nanorc"
 #p"/etc/network" #p"/etc/nsswitch.conf" #p"/etc/openoffice"
 #p"/etc/opt" #p"/etc/pam.conf" #p"/etc/pam.d" #p"/etc/pango"
 #p"/etc/papersize" #p"/etc/passwd" #p"/etc/passwd-" #p"/etc/perl"
 #p"/etc/ppp" #p"/etc/prelink.cache" #p"/etc/prelink.conf"
 #p"/etc/printcap" #p"/etc/profile" #p"/etc/protocols"
 #p"/etc/python2.3" #p"/etc/rc0.d" #p"/etc/rc1.d" #p"/etc/rc2.d"
 #p"/etc/rc3.d" #p"/etc/rc4.d" #p"/etc/rc5.d" #p"/etc/rc6.d"
 #p"/etc/rcS.d" #p"/etc/reportbug.conf" #p"/etc/resolv.conf"
 #p"/etc/rmt" #p"/etc/rpc" #p"/etc/securetty" #p"/etc/security"
 #p"/etc/services" #p"/etc/sgml" #p"/etc/shells" #p"/etc/skel"
 #p"/etc/sound" #p"/etc/ssh" #p"/etc/sysctl.conf" #p"/etc/syslog.conf"
 #p"/etc/terminfo" #p"/etc/texdoctk" #p"/etc/texmf" #p"/etc/ucf.conf"
 #p"/etc/updatedb.conf" #p"/etc/vga" #p"/etc/wgetrc" #p"/etc/xemacs21"
 #p"/etc/xml" #p"/etc/xpdf")

>(directory "/etc/passwd")

(#p"/etc/passwd" #p"/etc/passwd-")

(directory "/etc/passwd/")

NIL

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

Here is a little modification to the server example:

(defun foo (s) 
  (let* ((get (read s nil 'eof)) 
         (fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
	 (dn (if (eql (aref fn (1- (length fn))) #\/) fn (si::string-concatenate fn "/")))
	 (dir (directory dn))
         (file (unless dir (when (probe-file fn) fn))))
    (format s "HTTP/1.1 ~S~%" (if fn 404 500))
    (format s "Content-type: text/html~%~%")
    (format t "get ~a fn ~a dn ~a~%" get fn dn)
    (cond (file (with-open-file (q file) (si::copy-stream q s)))
	  (dir  (dolist (l dir)
		  (let ((n (namestring l)))
		    (format s "<a href=\"~a\">~a</a> <a href=\"~a/\"> /... </a><br>~%" n n n)))))
    (close s)))

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

These are just toys of course, just meant to illustrate my limited
understanding of how one can distinguish files from directories in
*standard* lisp.  We can add anything non-standard we might need, of
course. 




> > |
> > | I guess I should revert to applying your patches to gcl 2.6.6
> > | and see if I can at least get that to work on Windows...
> 
> I did not have to do this.
> 
> > Interestingly, today I can't get that to work properly either
> > insofar as getting the directory listsing you obtain.
> 
> I think you must have one too many simultaneous variables that
> are affecting your results ... :)
> 
> Here are a few links to other people doing http and html in lisp:
> 
> http://claws.sourceforge.net/
> 
> "The CLAWS is aimed to provide a complete framework for developing
> Web applications in Common Lisp. The project is in very early
> stage, so no actual code is released (though something can be found
> in CVS)."
> 
> http://www.franz.com/support/tutorials/
> http://www.franz.com/support/tutorials/aserve-tutorial.htm
> http://www.franz.com/support/documentation/7.0/doc/aserve/aserve.html
> http://opensource.franz.com/aserve/aserve-dist/doc/aserve.html
> 
> "AllegroServe is an HTTP server and HTML generator for Lisp. As
> with other HTTP servers, such as Apache (Unix) or the Internet
> Information Services (Windows), AllegroServe can be used to deliver
> web pages and other data over a TCP/IP network (such as the Internet)
> to internet browsers such as Firefox, Mozilla, and the Internet
> Explorer."
> 
> http://sourceforge.net/projects/portableaserve
> 
> "A free and portable Common Lisp Webserver. Portable AllegroServe
> is a variant of AllegroServe(tm) with an explicit emphasis on
> portability between Lispsystems and Operating Systems."
> 
> http://www.ai.mit.edu/projects/iiip/doc/cl-http/server.html
> http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
> http://www.ai.mit.edu/projects/iiip/conferences/luv95/tutorial.html
> 
> "Major components include a mature HTTP 1.1 server, a robust
> caching proxy server, a programmatic client, a constraint-guided
> Web Walker, a full-text indexation & retrieval, along with a
> variety of Web-related tools and contributions."
> 

People have asked about allegro serve before, and it should work, but
I haven't had time to look at it.  It is likely overkill for the
purpose at hand.

\start
Date: Wed, 04 May 2005 13:18:51 -0400
From: Bill Page
To: Camm Maguire
Subject: Re: Simple web server code for GCL for Windows
Cc: Mike Thomas

Camm Maguire wrote:

>>      (if (pathname-name (pathname fn))
>>          (with-open-file (q fn) (si::copy-stream q s))
>>        (dolist (l (directory fn)) (format s "~a~%" (namestring l)))))
>>
>>It would be nicer to make the result and the content type depend
>>on whether something was a directory or on the type of the file
>>etc instead of the syntax of the name, but I could not easily
>>discover how to do that in GCL. Specifically how can I tell a
>>directory from a file? Can anyone suggest a suitable "Getting
>>started in GCL" tutorial?
>>    
>>
>
>In lisp, the file system is accessed via a 'pathname' abstraction.
>Think of this a sa structure with several components, name, directory,
>type (e.g. suffix), device, even host and version if I recall.
>Directories have nil in the name and type fields.  The sample code
>uses this to distinguish between them.
>
I guess the lisp code in the previous paragraph is intended to 
distinquish between
directories and files, as you say but on Windows at least, all this code 
succeeds
in doing is distinguishing syntactically between `/msys/home/' (which it 
treats as a
directory because the "name" part is missing and '/msys/home' (which it 
treats as a
file) apparently without asking the operating system. Does this work 
properly
on linux?

Inside the (dolist (l (directory fn)) ... ) I would like to treat 
sub-directories
and files differently, i.e. different color, different type of links, 
etc. How can
I do that in GCL? I could not seem to get

  (if (pathname-name (pathname l)) ...

to work. Is that right approach?

>As for content-type analysis on files, you have the following options
>in order of simplicity to performace:
>
>1) Use an external utility via run-process:
>  
>
I think that for content type I would be happy to try to interpret the file
extension as is done in most web servers, e.g. name.html is of
content-type: text/html and name.txt is of content-type: text/plaintext
etc.

>As for tutorials, I'd suggest:
>
>1)  Practical Common Lisp:
>
>        http://www.gigamonkeys.com/book/
>
>2)  The Common Lisp Hyperspec:
>
>        http://www.lisp.org/HyperSpec/FrontMatter/index.html
>
>  
>
Thanks!

>>Anyway, it seems clear that we could use this approach to develop
>>a portable HyperTex browser for Axiom if we decide to go that
>>root.
>>
>If I can delay the stdin/socket multiplexing, this might be
>preferrable at this point.  I need to know if blocking the axiom
>process while serving the hyperdoc on Windows is a showstopper.
>  
>
For most applications I think it would be fine to run only one Axiom 
process,
so that if a user executes a long running command from the command window,
hypertex would have to wait (and vice versa).

\start
Date: 04 May 2005 14:01:06 -0400
From: Camm Maguire
To: Mike Thomas
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Bill Page, Tim Daly Jr

Greetings!

Mike Thomas writes:

> Hi Camm.
> 
> 
> EXCUSES
> 
> 'Twas a long weekend here and I made full use of it for non-programming
> purposes.  It looks from the CVS log and the Axiom/GCL 2.6.7 related email
> that there's a lot to catch up with.
> 

No problem!  Life takes precedence!

> Random thoughts follow.
> 
> 
> 2.6.7PRE
> 
> I just checked that 2.6.7pre builds on Windows.  Will likewise test Maxima
> etc as the week progresses.
> 
> What I need is some Lisp test code and simple instructions to check whatever
> network functionality you've added which you hope will work straight off
> under Windows.
> 

Really just the little server code Bill is playing with.  Please let
me know if your results ever differ from his.  Should not break in
ANSI.  It would also be nice to confirm that the new :daemon keyword
to socket does nothing on Windows.  Lastly, perhaps try reading and
writing a client socket, i.e. with :host instead of :server set in
#'socket.

> Please also tell me your time frame for getting 2.6.7 finalised and I'll try
> without promises to address GCL-TK within those limits.
> 

Thank you so much!  I think it looks like a good short term option on
axiom.  No extreme rush, but I was hoping this weekend.  An assessment
of the time requirements for gcl-tk and any technical obstacles also
most welcome.


> 
> SIGNALS AND WINDOWS
> 
> Are you implying (in some other email over the past few days) that SIGUSR1
> is used in the handshaking between the TK server and GCL?
> 

Yes.  Currently ifdefed out of gcltkaux for mingw -- the cause of the
errors I'm assuming.  Please note that you can set (debugging t) in
package 'tk and get lots of diagnostics.  Shelter's info page is
pretty good here.

> I take it SIGUSR1 is a user definable signal?

Yes.

> 
> The signal question you raise there is a can of worms partly because I'm not
> au fait with their use, but also in the sense that although GCL already has
> a mechanism for attempting to emulate the receipt within GCL of fake signals
> passed by another process (or from withing GCL), that mechanism requires the
> other process (or GCL) to implement it's own special code to actually send
> the fake signal in the first place.  That system (shared memory) is used by
> XMaxima to fake up SIGKILL.  Once you have reached this stage you have to
> ask yourself whether it would have been better to just use a Windows
> mechanism in the first place.  The other signals you mention are completely
> different in terms of the relevant Windows system functionality if such even
> exists (I'm thinking here of the profiling, memory fault handling and
> sigio).

OK I see it now.  Am a little confused how the receiving process gets
interrupted when another writes to shared memory  -- is this a windows
thing, or is there a periodic check on the shared mem contents
somewhere?  I think we need the former.

Thankfully, all our signal needs except for the maxima one you refer
to above are within GCL shipped programs, hence under our control. 

At some point, the 'windows mechanism' you refer to might be better,
but for now, and since we already have a template with SIGKILL, I
suggest we just extend it for SIGUSR1 in gcl-tk/tkMain.c and the
like.  Perhaps you might explain it to me if time permits.  The other
signals might be nice, but I don't know of any pressing need for them
on Windows, at least not that anyone has expressed.

> 
> 
> FORK() VS THREADS
> 
> If you go too far in the emulation direction, you also then have to ask
> yourself whether you shouldn't be using Cygwin in the first place,
> particularly with respect to fork().  When last I heard (several years ago)
> Cygwin fork() had problems with sockets after the clone is done. (GRASS used
> this mechanism for it's display server on Unix and Cygwin and never really
> resolved the issues.  My memory is that the MLton compiler gave up on Cygwin
> fork() just a few months ago.)  Lets face it, forked socket servers are one
> of the main reasons people fork() in the first place.  Furthermore, Cygwin
> fork() is not efficient in terms of either space or time.  If you choose to
> use Cygwin you then close the circle and have an application which is
> problematic to distribute and support which means you might as well tell
> your users to use Linux (I admire Linux/*BSD/Cygwin and even X by the way,
> don't get me wrong).

I'm hoping we don't have to go to cygwin, though the option might be
nice, only if someone else steps up to do the lion's share of work.
We're not that far away on mingw, I think, thanks to your outstanding
efforts.  Working mind share is the most valuable commodity here.  We
have three short term options

1) No socket multiutasking on windows, -- need to hear from axiom how
   onerous this would be

2) run-process the commands to an entirely separate AXIOMsys  (easiest
   and most serviceable, I'd think) Or even (system ...)

3) multiplex stin with select, which should be portable.

> 
> Ultimately, threads are the way to go in respect of this kind of
> functionality on Windows but of course, we have to find the time and
> know-how.
> 

Yep to both.  Maybe someone explains in detail reentrancy to me
someday, as I've never found the need for threads, with such a great
tool like fork.

> 
> GUI BACKENDS
> 
> Time and know-how again whatever the path - I originally chose JAPI
> precisely because I could implement a GUI library in a couple of hours;
> hopefully GCL-TK can be salvaged on Windows in a similarly short time frame.
> Other compiler projects I am aware of farm library work (especially large
> open ended GUI library projects such as GTK, OpenGL, WXWidgets bindings) out
> to helpers.  The GCL project is short staffed as it is, with you (Camm) the
> only seriously committed developer we have.
> 

Agreed.  It would be great to farm out completely here, but there are
not enough users.  Thankfully it looks as though we have two working
options (presuming windows gcl-tk), so we can table the rest
indefinitely until more resources arise, if ever.

\start
Date: Wed, 04 May 2005 13:05:49 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [InstallingMathAction] (new) 

On 01/10/2004 4:05 PM Hans Peter Wuermli wrote:

This evening I set-up afresh AxiomWiki on my local system
(which I describe as far as I find it useful at the end).

This was done on 2004-10-1:

1) Download  ZWiki-0.35.0.tgz from http://www.zwiki.org/FrontPage.

2) I would have downloaded LatexWiki-0.35, if it had been
   available as Bob McElrath tries to keep LatexWiki and
   ZWiki in sync. Instead I did the following::

     cd /home/LatexW
     darcs get http://bob.mcelrath.org/darcs/latexwiki

     cd /home/AaxiomW
     darcs get http://page.axiom-developer.org/repository/latexwiki

     cd $ZOPEHOME/lib/python/Products

     cp -r /home/LatexW/latexwiki/LatexWiki .
     cp -r /home/LatexW/latexwiki/ZWiki .

     cp /home/AxiomW/latexwiki/LatexWiki/ReplaceInline* .
     cp /home/AxiomW/latexwiki/LatexWiki/*Wrapper.py .
     cp /home/AxiomW/latexwiki/LatexWiki/texbreaker* .

   I had to delete ReplaceInlineReduce.py and comment out any
   line refering to Reduce in ReplaceInlineLatex.py as I don't
   have reduce and it does produce an error if you leave it.

3) If necessary, comment out line 24 and 58 in ReplaceInlineLatex.py,
   both referring to Reduce.

4) Edit axiomWrapper.py: on line 85 the string "cmdLine" exports
   AXIOM. Edit it such that it reflects your local Axiom home.
   In my case::

     cd /usr/local/lib/
     darcs get http://page.axiom-developer.org/repository/axiom

     .... make ....
     In axiomWrapper.py:
        cmdLine = 'export AXIOM=/usr/local/lib/axiom/mnt/linux;\\
        export PATH=\$AXIOM/bin:\$PATH;\\
        AXIOMsys < %s' %(axiomFileName)

5) Run the commands you find in texbreaker.mak. (I had the change
   the include file in the gcc command::

     -I/usr/include/python2.3 to -I/usr/include/python2.2)

6) Restart zope: /etc/init.d/zope restart

Now it should all be set up and work.


My system:

I run Debian testing (Sarge) with a kernel-image-2.6.7-1-686
(with mostly the latest library versions of everything, i.e.
not a totally robust system, but perfectly fine for me).

Versions::

  Zope Version (Zope 2.6.4 (source release, python 2.1, linux2), python 2.2.3, linux2)
  Python Version 2.2.3+ (#1, Jun 20 2004, 13:32:48) [GCC 3.3.4 (Debian)]
  System Platform linux2
  SOFTWARE_HOME /usr/lib/zope/lib/python
  ZOPE_HOME /usr/lib/zope
  INSTANCE_HOME /var/lib/zope/instance/default
  CLIENT_HOME /var/lib/zope/instance/default/var

\start
Date: 04 May 2005 10:11:47 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Simple web server code for  GCLfor Windows
Cc: Mike Thomas

Greetings!

Bill Page writes:

> Camm,
> 
> You are right. The simple GCL web server program that you
> wrote is working on both linux and Windows. Great!
> 

Wonderful.  Thanks!

> On Tuesday, May 03, 2005 9:56 AM Camm Maguire wrote:
> 
> >...
> > What this will send to the gcl function 'foo' is 'get /dir'
> > #'foo must find a file or directory by that name to produce
> > output, which I'm guessing does not exist on your system.
> > You can add a diagnostic like: 
> 
> (defun foo (s) 
>   (let* ((get (read s nil 'eof)) 
>          (fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
>          (fn (when (probe-file fn) fn)))
>     (format s "HTTP/1.1 ~S~%" (if fn 404 500))
>     (format s "Content-type: text/html~%~%")
>     (format t "get ~a fn ~a~%" get fn)
>     (when fn
>       (if (pathname-name (pathname fn))
>           (with-open-file (q fn) (si::copy-stream q s))
>         (dolist (l (directory fn)) (format s "~a~%" (namestring l)))))
>     (close s))
> )
> 
> > You can also do 'telnet localhost 8085' and type 'get /dir'
> > to see the output, which I think is likely '404' in my pseudo
> > html error code example. 
> 
> Thanks. This works exactly as you claim. For example on my system
> 
>   http://localhost:8085/msys/1.0/home/bpage/
> 
> produces a list of files and
> 
>   http://localhost:8085/msys/1.0/home/bpage/repository.html
> 
> displays the web page in a browser (See Content-type above).
> 
> Just to play a little (although I know almost knowing about
> lisp :) I also changed the file list to HTML format like this:
> 
>  (format s "<a href=\"~a\">~a</a> <a href=\"~a/\"> /... </a><br>~%"
>    (namestring l) (namestring l) (namestring l)))
> 

This is exactly the idea.  You can also call other functions from foo,
and compile them.  With both the user invocation model currently in
place on Linux and Windows, and the fork() background model currently
in place on Linux, such changes will have to precede the actual call
to #'bar/#'socket respectively.  (Just to be a bit more clear, on
Linux you should have the option '(si::socket 8085 :server #'foo
:daemon t)' and '(si::socket 8085 :server #'foo :daemon :persist)',
both of which will fork and invoke backgrounded running servers, the
latter example of which will allow the forked server to survive when
the current image is terminated.)  If/when the stdio multiplexing gets
done, then one can modify #'foo while the server is running, changes
to which will be available on the next connection.  This feature seems
less important to us at this juncture.

> It would be nicer to make the result and the content type depend
> on whether something was a directory or on the type of the file
> etc instead of the syntax of the name, but I could not easily
> discover how to do that in GCL. Specifically how can I tell a
> directory from a file? Can anyone suggest a suitable "Getting
> started in GCL" tutorial?

In lisp, the file system is accessed via a 'pathname' abstraction.
Think of this a sa structure with several components, name, directory,
type (e.g. suffix), device, even host and version if I recall.
Directories have nil in the name and type fields.  The sample code
uses this to distinguish between them. 

As for content-type analysis on files, you have the following options
in order of simplicity to performace:

1) Use an external utility via run-process:

(let ((s (si::run-process "file" (list "/etc/passwd")))) (read-line s nil 'eof))

***** Spawning process file 
"/etc/passwd: ASCII text"
NIL

2) Open the file and implement the 'magic' used by file in lisp -- see
   /usr/share/misc/magic on Linux, a copy of which is appended below.

As for tutorials, I'd suggest:

1)  Practical Common Lisp:

        http://www.gigamonkeys.com/book/

2)  The Common Lisp Hyperspec:

        http://www.lisp.org/HyperSpec/FrontMatter/index.html


> 
> Anyway, it seems clear that we could use this approach to develop
> a portable HyperTex browser for Axiom if we decide to go that
> root.
> 

If I can delay the stdin/socket multiplexing, this might be
preferrable at this point.  I need to know if blocking the axiom
process while serving the hyperdoc on Windows is a showstopper.

\start
Date: Wed, 04 May 2005 16:17:20 -0400
From: Bill Page
To: Camm Maguire
Subject: lisp files and directorys (was: axiom porting)
Cc: Mike Thomas, Paul F. Dietz

Camm Maguire wrote:

>OK, I think I finally understand your earlier comment about
>directory/filename distinction.  I've quickly scanned the hyperspec on
>this and can't find the relevant section, so am referring this to our
>resident expert Paul Dietz/  
>...
>Looking at this has made me notice a bug -- one can apparently open
>streams with directory pathnames, but reading of course fails.  I am
>committing changes** designed to fix this simply for now, by ensuring
>that open_stream and probe-file (and file-write-length, file-author
>...) fail (i.e. return nil) on directories.  Eventually we might want
>to allow open to succeed, returning a 'user-defined' stream, and have
>read thereon return stat structures for the files therein.  The only
>standardized interface to directories under lisp I can find is
>(directory ...), not surprisingly, so with this set of changes, this
>will be the only thing you can do with a pathname that refers to a
>directory, trailing slash or not.
>
Camm,

Are these changes ** in cvs -r Version_2_6_7pre? If not can you send me
the patches?

\start
Date: Thu, 5 May 2005 10:36:34 +1000
From: Mike Thomas
To: Camm Maguire, Bill Page
Subject: re: [Gcl-devel] Re: axiom porting

Hi Camm/Bill.

A bunch of Windows probe-file, directory and server output below.  Basically
the server program is failing because accept won't deal with the "socket"
it's being passed and on first glance I suspect that this is because it is
not the right Winsock type.  I'll look further later but I'm suspicious that
there may be a lot of work ahead here for me.

Cheers

Mike Thomas

| As for bombing when the file is not there, this would appear to be an
| error in probe-file on Windows.  The 'server' example is supposed to
| return a blank page and continue in this case.  Please let me know if
| there is a bug here.  (si::use-fast-links nil) and :bt if thrown into
| the debugger.  (I do get an error on Linux when the file exists but
| cannot be opened due to permissions, for example.)

>(probe-file "/msys/1.0")

#p"c:/msys/1.0"

>(probe-file "/msys/1.0/")

#p"c:/msys/1.0/"

>(probe-file "c:/msys/1.0/")

#p"c:/msys/1.0/"

>(probe-file "c:/msys/1.0")

#p"c:/msys/1.0"

>(directory "c:/msys/1.0")

(#p"c:/msys/1.0")

>(directory "c:/msys/1.0/")

(#p"c:/msys/1.0/bin" #p"c:/msys/1.0/doc" #p"c:/msys/1.0/etc"
 #p"c:/msys/1.0/home" #p"c:/msys/1.0/include" #p"c:/msys/1.0/lib"
 #p"c:/msys/1.0/local" #p"c:/msys/1.0/m.ico" #p"c:/msys/1.0/mingw"
 #p"c:/msys/1.0/msys.bat" #p"c:/msys/1.0/msys.bat~"
 #p"c:/msys/1.0/msys.ico" #p"c:/msys/1.0/share" #p"c:/msys/1.0/ssl"
 #p"c:/msys/1.0/uninstall")

>(open "/etc" :if-does-not-exist nil)

NIL

>(open "c:/msys/1.0" :if-does-not-exist nil)

NIL

>(open "c:/msys/1.0/" :if-does-not-exist nil)

NIL

>(open "c:/msys/1.0/msys.bat" :if-does-not-exist nil)

#<input stream "c:/msys/1.0/msys.bat">


>(bar 8085 #'foo)

Error in LET [or a callee]: Error "No such file or directory" on accepting
conne
ction to #<two-way stream 104c969c>


Broken at INVOKE-DEBUGGER.  Type :H for Help.
 1 (Abort) Return to top level.
dbl:>>:bt

#0   INVOKE-DEBUGGER
{datum=#<conditions::internal-simple-stream-error.0>,argume
nts=nil,loc2=#<condit...} [ihs=15]
#1   ERROR
{datum=conditions::internal-simple-stream-error,arguments=(:function-
name let :f...} [ihs=14]
#2   CLCS-UNIVERSAL-ERROR-HANDLER
{error-name=:error,correctable=nil,function-na
me=let,continue-format-string=("")...} [ihs=13]
#3   ACCEPT {loc0=#<two-way stream 104c969c>} [ihs=12]
#4   BAR {lambda-block=foo,} [ihs=7]
#5   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=(lambda-block bar (p fn)
...),loc4=80
87,loc5=(l...} [ihs=6]
#6   TOP-LEVEL
{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7=
"c:/cvs/stable/...} [ihs=5]
#7   FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
NIL
dbl:>>:h

\start
Date: Wed, 4 May 2005 21:01:35 -0500
From: Tim Daly
To: Mike Thomas, Camm Maguire, Bill Page
Subject: graphics/browser

*,

The current architecture has the graphics in one process, the browser
in a second process, and axiom in a third. All of this is managed
thru sockets by sman (superman), a hidden top-level process.

Thus for communication purposes the G/B processes can use stdin and
stdout for communication, it seems. It might require an sman rewrite
but it shouldn't be overly challenging (but clearly not a simple job :-))

\start
Date: Wed, 04 May 2005 22:02:46 -0400
From: Bill Page
To: Mike Thomas
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Camm Maguire

Mike Thomas wrote:

>Hi Camm/Bill.
>
>A bunch of Windows probe-file, directory and server output below.  Basically
>the server program is failing because accept won't deal with the "socket"
>it's being passed and on first glance I suspect that this is because it is
>not the right Winsock type.  I'll look further later but I'm suspicious that
>there may be a lot of work ahead here for me.
>
That is quite strange. I just re-build gcl Version_2_6_7pre (non-ansi) 
from cvs on
another Windows XP/sp2 machine. Camm's web server program (latest version,
see Camm's email) continues to work fine for me.

What version of Windows are you using?

\start
Date: Thu, 5 May 2005 12:49:57 +1000
From: Mike Thomas
To: Bill Page
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Camm Maguire

Hi Bill.

| That is quite strange. I just re-build gcl Version_2_6_7pre (non-ansi)
| from cvs on
| another Windows XP/sp2 machine. Camm's web server program (latest version,
| see Camm's email) continues to work fine for me.

XP SP2 CVS 2.6.7pre and both of gcc versions 3.3.1 and 3.4.2, using Camm's
email version (and other versions at that).

\start
Date: Wed, 04 May 2005 22:53:23 -0400
From: Bill Page
To: Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas, Paul F. Dietz

Camm Maguire wrote:

>OK, I've just tested on Linux under ANSI, and it works the same for
>me (as it should).  If this is not the case on Windows, please someone
>let me know asap.
>  
>
Perhaps Mike's test demonstrates that this is not working on the
Windows ANSI version, but it works fine for me on Windows XP
with the non-ANSI version.

>As for bombing when the file is not there, this would appear to be an
>error in probe-file on Windows.  The 'server' example is supposed to
>return a blank page and continue in this case.  Please let me know if
>there is a bug here.
>  
>
This works properly now with the most recent Version_2_6_7pre
from cvs *and* your revised `foo' routine below. Note that with
the new behaviour of (probe-file "xxx") which returns NIL if xxx
is a directory, the old version of `foo' no longer worked.

>=============================================================================
>  
>
>>(open "/etc" :if-does-not-exist nil)
>>    
>>
>
>NIL
>  
>
On Windows XP/sp2 with latest Version_2_6_7pre compiled non-ansi
I get (using /msys/ instead of /etc/ for windows compatibility):

 >  (open "/msys" :if-does-not-exist nil)

NIL

>>(open "/etc/" :if-does-not-exist nil)
>>    
>>
>
>NIL
>  
>
 > (open "/msys/" :if-does-not-exist nil)

NIL

>>(open "/etc/passwd" :if-does-not-exist nil)
>>    
>>
>
>#<input stream "/etc/passwd">
>  
>
 > (open "/msys/1.0/msys.bat" :if-does-not-exist nil)

#<input stream "/msys/1.0/msys.bat">

>>(directory "/etc")
>>    
>>
>
>(#p"/etc")
>  
>
 > (directory "/msys/1.0")

(#p"/msys/1.0")

>>(directory "/etc/")
>>    
>>
>
>(#p"/etc/R" #p"/etc/X11" #p"/etc/adduser.conf" #p"/etc/adjtime"
> ...
> #p"/etc/xml" #p"/etc/xpdf")
>  
>
 > (directory "/msys/1.0/")

(#p"/msys/1.0/.bash_history" #p"/msys/1.0/bin" #p"/msys/1.0/doc"
 #p"/msys/1.0/etc" #p"/msys/1.0/home" #p"/msys/1.0/lib"
 #p"/msys/1.0/m.ico" #p"/msys/1.0/mingw" #p"/msys/1.0/msys.bat"
 #p"/msys/1.0/msys.ico" #p"/msys/1.0/share" #p"/msys/1.0/uninstall")

>>(directory "/etc/passwd")
>>    
>>
>
>(#p"/etc/passwd" #p"/etc/passwd-")
>  
>
 > (directory "/msys/1.0/msys.bat")

(#p"/msys/1.0/msys.bat")

Perhaps this last one is a little strange since `msys.bat' is a file?

>=============================================================================
>
>Here is a little modification to the server example:
>
>(defun foo (s) 
>  (let* ((get (read s nil 'eof)) 
>         (fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
>	 (dn (if (eql (aref fn (1- (length fn))) #\/) fn (si::string-concatenate fn "/")))
>	 (dir (directory dn))
>         (file (unless dir (when (probe-file fn) fn))))
>    (format s "HTTP/1.1 ~S~%" (if fn 404 500))
>    (format s "Content-type: text/html~%~%")
>    (format t "get ~a fn ~a dn ~a~%" get fn dn)
>    (cond (file (with-open-file (q file) (si::copy-stream q s)))
>	  (dir  (dolist (l dir)
>		  (let ((n (namestring l)))
>		    (format s "<a href=\"~a\">~a</a> <a href=\"~a/\"> /... </a><br>~%" n n n)))))
>    (close s)))
>
>=============================================================================
>
>These are just toys of course, just meant to illustrate my limited
>understanding of how one can distinguish files from directories in
>*standard* lisp.  We can add anything non-standard we might need, of
>course. 
>  
>
I like it. As I said, it works for me with the non-ansi gcl Version_2_6_7pre
on Windows XP/sp2. No aborts this time.

And I am learning a little lisp too :) Thanks.

\start
Date: Thu, 5 May 2005 14:32:18 +1000
From: Mike Thomas
To: Bill Page, Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Paul F. Dietz

Hi Bill/Camm.

| >OK, I've just tested on Linux under ANSI, and it works the same for
| >me (as it should).  If this is not the case on Windows, please someone
| >let me know asap.
| >
| >
| Perhaps Mike's test demonstrates that this is not working on the
| Windows ANSI version, but it works fine for me on Windows XP
| with the non-ANSI version.

I just tried the CLtL1 build - no joy.

There are definite problems with the new code as socket variables should be
defined with SOCKET (an unsigned int) rather than int and the error return
values on Windows are not the same as on BSD systems however I just tried to
eliminate those problems and still have the same trouble.

I'm using Internet Explorer.  I'll keep looking perhaps tomorrow.  Hopefully
this is due to a stupid mistake on my part.

\start
Date: 05 May 2005 09:59:12 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Simple web server code for GCL for Windows
Cc: Mike Thomas, Paul F. Dietz

Greetings!

Bill Page writes:

> Camm Maguire wrote:
> 
> >>      (if (pathname-name (pathname fn))
> >>          (with-open-file (q fn) (si::copy-stream q s))
> >>        (dolist (l (directory fn)) (format s "~a~%" (namestring l)))))
> >>
> >>It would be nicer to make the result and the content type depend
> >>on whether something was a directory or on the type of the file
> >>etc instead of the syntax of the name, but I could not easily
> >>discover how to do that in GCL. Specifically how can I tell a
> >>directory from a file? Can anyone suggest a suitable "Getting
> >>started in GCL" tutorial?
> >>
> >
> >In lisp, the file system is accessed via a 'pathname' abstraction.
> >Think of this a sa structure with several components, name, directory,
> >type (e.g. suffix), device, even host and version if I recall.
> >Directories have nil in the name and type fields.  The sample code
> >uses this to distinguish between them.
> >
> I guess the lisp code in the previous paragraph is intended to
> distinquish between
> directories and files, as you say but on Windows at least, all this
> code succeeds
> in doing is distinguishing syntactically between `/msys/home/' (which
> it treats as a
> directory because the "name" part is missing and '/msys/home' (which
> it treats as a
> file) apparently without asking the operating system. Does this work
> properly
> on linux?
> 

Yes, please see my second post on this.  Common lisp seems to have
been designed to handle systems without directories, like mainframes,
is my guess for why the standard works this way.  In sum, my
understanding for detecting files and directories in standard cl is:

(probe-file "filename") -> pathname         iff filename is a file
(directory "filename/") -> non-nil list     iff filename is a non-empty directory

This behavior should now be exhibited by 2.6.7pre (and CVS head).


> Inside the (dolist (l (directory fn)) ... ) I would like to treat
> sub-directories
> and files differently, i.e. different color, different type of links,
> etc. How can
> I do that in GCL? I could not seem to get
> 
>   (if (pathname-name (pathname l)) ...
> 
> to work. Is that right approach?
> 

I'd first probe-file -> file, else ensure a trailing slash and do a
directory -> non-empty directory, else non-existent or empty
directory.


> >As for content-type analysis on files, you have the following options
> >in order of simplicity to performace:
> >
> >1) Use an external utility via run-process:
> >
> I think that for content type I would be happy to try to interpret the file
> extension as is done in most web servers, e.g. name.html is of
> content-type: text/html and name.txt is of content-type: text/plaintext
> etc.
> 
> >As for tutorials, I'd suggest:
> >
> >1)  Practical Common Lisp:
> >
> >        http://www.gigamonkeys.com/book/
> >
> >2)  The Common Lisp Hyperspec:
> >
> >        http://www.lisp.org/HyperSpec/FrontMatter/index.html
> >
> >
> Thanks!
> 
> >>Anyway, it seems clear that we could use this approach to develop
> >>a portable HyperTex browser for Axiom if we decide to go that
> >>root.
> >>
> >If I can delay the stdin/socket multiplexing, this might be
> >preferrable at this point.  I need to know if blocking the axiom
> >process while serving the hyperdoc on Windows is a showstopper.
> >
> For most applications I think it would be fine to run only one Axiom
> process,
> so that if a user executes a long running command from the command window,
> hypertex would have to wait (and vice versa).
> 

Well, at this burning moment (given your results, not Mike's for the
sake of argument), a Windows user would have to do '-> hyperdoc'; at
the terminal to get the web served pages served to a separate browser,
thereby locking the terminal.  One link on the pages might serve
instruct the server process to quit, releasing the terminal for
further use.  (i.e. just like (bar ...) behaves in the example, but
with a quit mechanism implemented).  On Linux, the process could be
backgrounded freeing the terminal for simultaneous work.  Is this a
problem?

In all the web models, to my understanding, axiom via the server
process will be unable to push a page to the browser, unless one makes
use of the 'refresh' mechanism in html to ensure a call back at some
point.  The gcl-tk model, in contrast, allows the user to interact
with the process from both gui -> command line and command line -> gui
at the same time.  Don't know how critical this might be.  gcl-tk, at
least on Linux, already has an effective stdin multiplexer, which I
might provide to generic sockets as described earlier if it is really
important.  Would prefer to delay, of course.

Sounds to me like the existing options, presuming they work
cross-platform as described above, are sufficient enough for axiom's
purpose as to not delay 2.6.7.  Please correct me if I'm mistaken.

\start
Date: Thu, 05 May 2005 09:41:30 -0400
From: Bill Page
To: Mike Thomas
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Camm Maguire

Mike Thomas wrote:

>I just tried the CLtL1 build - no joy.
>
>There are definite problems with the new code as socket variables should be
>defined with SOCKET (an unsigned int) rather than int and the error return
>values on Windows are not the same as on BSD systems however I just tried to
>eliminate those problems and still have the same trouble.
>
>I'm using Internet Explorer.
>
Ah, yes now I can confirm there are definite problems accessing the
"gcl simple web server" using IE 6. I have been testing using Firefox 1.0.3
and oddly exactly the same url works fine with no aborts.

>I'll keep looking perhaps tomorrow.  Hopefully
>this is due to a stupid mistake on my part.
>
No I think you are right (we are both right :). There is a problem
when using Internet Explorer. IE must be making rather different
socket calls than FireFox. That seems quite odd to me.

Using IE, the problem seems to intermittant. It works for a while
with some urls and not others.

Here is a typical failed test using IE.

---------
$ saved_gcl
GCL (GNU Common Lisp)  2.6.7 CLtL1    May  4 2005 16:56:38
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

 >(load "test-http2.lsp")

Loading test-http2.lsp

----------

Then using Microsoft Explorer 6 sp2 and url
  http://localhost:8085/msys/1.0/
I get the following error:

----------

get GET fn /msys/1.0/ dn /msys/1.0/

Error: error writing to socket: errno= 22
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by FORMAT.
Broken at FORMAT.  Type :H for Help.
 >>(si::use-fast-links nil)

NIL
 >>:bt

#0   FORMAT {loc0=#<two-way stream 1022ad14>,loc1="<a href=\"~a\">~a</a> 
<a href=\"~a/\"> /....} [ihs=19]
#1   FORMAT {loc0=#<two-way stream 1022ad14>,loc1="<a href=\"~a\">~a</a> 
<a href=\"~a/\"> /....} [ihs=18]
#2   FOO {} [ihs=13]
#3   BAR {lambda-block=foo,} [ihs=8]
#4   LOAD {loc0=nil,loc1=nil,loc2=nil,loc3=(lambda-block bar (p fn) 
...),loc4=8085,loc5=(l...} [ihs=7]
#5   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function 
load>,loc4=#p"test-http2.ls...} [ihs=6]
#6   TOP-LEVEL 
{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7="C:/msys/1.0/ho...} 
[ihs=5]
#7   FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
NIL
 >>

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

Does this back trace help to see what's going wrong?

If I start again and do the same thing using FireFox I get:

$ saved_gcl
GCL (GNU Common Lisp)  2.6.7 CLtL1    May  4 2005 16:56:38
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

 >(load "test-http2.lsp")

Loading test-http2.lsp
get GET fn /msys/1.0/ dn /msys/1.0/
get GET fn /favicon.ico dn /favicon.ico/

--------

And the list directories appears in the browser.

Let me know what I can try next.

\start
Date: 05 May 2005 10:25:45 -0400
From: Camm Maguire
To: Mike Thomas
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Paul F. Dietz

Greetings!

Mike Thomas writes:

> Hi Bill/Camm.
> 
> | >OK, I've just tested on Linux under ANSI, and it works the same for
> | >me (as it should).  If this is not the case on Windows, please someone
> | >let me know asap.
> | >
> | >
> | Perhaps Mike's test demonstrates that this is not working on the
> | Windows ANSI version, but it works fine for me on Windows XP
> | with the non-ANSI version.
> 
> I just tried the CLtL1 build - no joy.
> 

OK, at least we have some consistency.

> There are definite problems with the new code as socket variables should be
> defined with SOCKET (an unsigned int) rather than int and the error return
> values on Windows are not the same as on BSD systems however I just tried to
> eliminate those problems and still have the same trouble.
> 

This could be the problem, but I'd be skeptical, as you had success
earlier.  The accept error message reports the C strerror string,
which was "No such file ..."  I think this is the first of the
following errors, whatever mingw's numbering system could be:

ERRORS
       EAGAIN or EWOULDBLOCK
              The  socket  is  marked non-blocking and no connec-
              tions are present to be accepted.

       EBADF  The descriptor is invalid.

       ENOTSOCK
              The descriptor references a file, not a socket.

       EOPNOTSUPP
              The referenced socket is not of type SOCK_STREAM.

       EFAULT The addr parameter is not in a writable part of the
              user address space.

       EPERM  Firewall rules forbid connection.

       ENOBUFS, ENOMEM
              Not  enough free memory.  This often means that the
              memory allocation is limited by the  socket  buffer
              limits, not by the system memory.



Sounds to me that #'listen is returning T before a connection is
present, i.e. the select code we've added there might not be working
for you.  Just an idea.  

> I'm using Internet Explorer.  I'll keep looking perhaps tomorrow.  Hopefully
> this is due to a stupid mistake on my part.
> 

Might want to start with telnet for simplicity.  Might want to break
in gdb at the select in #'listen, and see if it is working, and if so,
whether it is accept that fails for some other reason.

\start
Date: 05 May 2005 10:07:05 -0400
From: Camm Maguire
To: Mike Thomas
Subject: re: [Gcl-devel] Re: axiom porting

Greetings, and thanks as always Mike for your heroic efforts!

Mike Thomas writes:

> Hi Camm/Bill.
> 
> A bunch of Windows probe-file, directory and server output below.  Basically
> the server program is failing because accept won't deal with the "socket"
> it's being passed and on first glance I suspect that this is because it is
> not the right Winsock type.  I'll look further later but I'm suspicious that
> there may be a lot of work ahead here for me.
> 

Your the expert here, but I'm confused as to how you found success
earlier on if this is the case.


> Cheers
> 
> Mike Thomas
> 
> | As for bombing when the file is not there, this would appear to be an
> | error in probe-file on Windows.  The 'server' example is supposed to
> | return a blank page and continue in this case.  Please let me know if
> | there is a bug here.  (si::use-fast-links nil) and :bt if thrown into
> | the debugger.  (I do get an error on Linux when the file exists but
> | cannot be opened due to permissions, for example.)
> 
> >(probe-file "/msys/1.0")
> 
> #p"c:/msys/1.0"
> 
> >(probe-file "/msys/1.0/")
> 
> #p"c:/msys/1.0/"
> 
> >(probe-file "c:/msys/1.0/")
> 
> #p"c:/msys/1.0/"
> 
> >(probe-file "c:/msys/1.0")
> 
> #p"c:/msys/1.0"
> 

With the commits to 2.6.7pre I made yesterday, all these probe-files
to directories should return nil.  Please let me know asap if this is
not the case (still), and preferably why if you can discern the reason
easily.


> >(directory "c:/msys/1.0")
> 
> (#p"c:/msys/1.0")
> 
> >(directory "c:/msys/1.0/")
> 
> (#p"c:/msys/1.0/bin" #p"c:/msys/1.0/doc" #p"c:/msys/1.0/etc"
>  #p"c:/msys/1.0/home" #p"c:/msys/1.0/include" #p"c:/msys/1.0/lib"
>  #p"c:/msys/1.0/local" #p"c:/msys/1.0/m.ico" #p"c:/msys/1.0/mingw"
>  #p"c:/msys/1.0/msys.bat" #p"c:/msys/1.0/msys.bat~"
>  #p"c:/msys/1.0/msys.ico" #p"c:/msys/1.0/share" #p"c:/msys/1.0/ssl"
>  #p"c:/msys/1.0/uninstall")
> 
> >(open "/etc" :if-does-not-exist nil)
> 
> NIL
> 
> >(open "c:/msys/1.0" :if-does-not-exist nil)
> 
> NIL
> 
> >(open "c:/msys/1.0/" :if-does-not-exist nil)
> 
> NIL
> 
> >(open "c:/msys/1.0/msys.bat" :if-does-not-exist nil)
> 
> #<input stream "c:/msys/1.0/msys.bat">
> 

All of this is right.

> 
> >(bar 8085 #'foo)
> 
> Error in LET [or a callee]: Error "No such file or directory" on accepting
> conne
> ction to #<two-way stream 104c969c>
> 

At least on Linux, accept might fail with a EAGAIN or similar if no
connections are pending.  It is critical to this example that the call
to #'listen in #'bar correctly return t iff a connection has been
made.  You can test this with telnet from a separate shell window.
I.e.

(setq s (si::socket 8085 :server #'foo))
(listen s) -> nil (no telnet localhost 8085)
(listen s) -> t (after telnet localhost 8085)

Also, if you get a chance, perhaps you could share your opinion on
whether I may have broken what was working, or whether you feel the
initial reports of success were invalid, unstable, or premature.

Take care,


> 
> Broken at INVOKE-DEBUGGER.  Type :H for Help.
>  1 (Abort) Return to top level.
> dbl:>>:bt
> 
> #0   INVOKE-DEBUGGER
> {datum=#<conditions::internal-simple-stream-error.0>,argume
> nts=nil,loc2=#<condit...} [ihs=15]
> #1   ERROR
> {datum=conditions::internal-simple-stream-error,arguments=(:function-
> name let :f...} [ihs=14]
> #2   CLCS-UNIVERSAL-ERROR-HANDLER
> {error-name=:error,correctable=nil,function-na
> me=let,continue-format-string=("")...} [ihs=13]
> #3   ACCEPT {loc0=#<two-way stream 104c969c>} [ihs=12]
> #4   BAR {lambda-block=foo,} [ihs=7]
> #5   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=(lambda-block bar (p fn)
> ...),loc4=80
> 87,loc5=(l...} [ihs=6]
> #6   TOP-LEVEL
> {loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7=
> "c:/cvs/stable/...} [ihs=5]
> #7   FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
> NIL
> dbl:>>:h

\start
Date: 05 May 2005 10:19:14 -0400
From: Camm Maguire
To: Bill Page
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas, Paul F. Dietz

Greetings!

Bill Page writes:

> Camm Maguire wrote:
> 
> >OK, I've just tested on Linux under ANSI, and it works the same for
> >me (as it should).  If this is not the case on Windows, please someone
> >let me know asap.
> >
> Perhaps Mike's test demonstrates that this is not working on the
> Windows ANSI version, but it works fine for me on Windows XP
> with the non-ANSI version.
> 

OK, if someone can verify that it is ansi which breaks, please let me
know. 

> >As for bombing when the file is not there, this would appear to be an
> >error in probe-file on Windows.  The 'server' example is supposed to
> >return a blank page and continue in this case.  Please let me know if
> >there is a bug here.
> >
> This works properly now with the most recent Version_2_6_7pre
> from cvs *and* your revised `foo' routine below. Note that with
> the new behaviour of (probe-file "xxx") which returns NIL if xxx
> is a directory, the old version of `foo' no longer worked.
> 

Yes.

> >=============================================================================
> >
> >>(open "/etc" :if-does-not-exist nil)
> >>
> >
> >NIL
> >
> On Windows XP/sp2 with latest Version_2_6_7pre compiled non-ansi
> I get (using /msys/ instead of /etc/ for windows compatibility):
> 
>  >  (open "/msys" :if-does-not-exist nil)
> 
> NIL
> 
> >>(open "/etc/" :if-does-not-exist nil)
> >>
> >
> >NIL
> >
>  > (open "/msys/" :if-does-not-exist nil)
> 
> NIL
> 
> >>(open "/etc/passwd" :if-does-not-exist nil)
> >>
> >
> >#<input stream "/etc/passwd">
> >
>  > (open "/msys/1.0/msys.bat" :if-does-not-exist nil)
> 
> #<input stream "/msys/1.0/msys.bat">
> 
> >>(directory "/etc")
> >>
> >
> >(#p"/etc")
> >
>  > (directory "/msys/1.0")
> 
> (#p"/msys/1.0")
> 
> >>(directory "/etc/")
> >>
> >
> >(#p"/etc/R" #p"/etc/X11" #p"/etc/adduser.conf" #p"/etc/adjtime"
> > ...
> > #p"/etc/xml" #p"/etc/xpdf")
> >
>  > (directory "/msys/1.0/")
> 
> (#p"/msys/1.0/.bash_history" #p"/msys/1.0/bin" #p"/msys/1.0/doc"
>  #p"/msys/1.0/etc" #p"/msys/1.0/home" #p"/msys/1.0/lib"
>  #p"/msys/1.0/m.ico" #p"/msys/1.0/mingw" #p"/msys/1.0/msys.bat"
>  #p"/msys/1.0/msys.ico" #p"/msys/1.0/share" #p"/msys/1.0/uninstall")
> 
> >>(directory "/etc/passwd")
> >>
> >
> >(#p"/etc/passwd" #p"/etc/passwd-")
> >
>  > (directory "/msys/1.0/msys.bat")
> 
> (#p"/msys/1.0/msys.bat")
> 
> Perhaps this last one is a little strange since `msys.bat' is a file?
> 

This is all correct.  #'directory is a wildcard matching function for
the filesystem (perhaps misleadingly named), so should return the
file path if supplied a file namestring.


> >=============================================================================
> >
> >Here is a little modification to the server example:
> >
> > (defun foo (s)  (let* ((get (read s nil 'eof))         (fn (and (eq
> > get 'get) (string-downcase (read s nil 'eof))))
> >	 (dn (if (eql (aref fn (1- (length fn))) #\/) fn (si::string-concatenate fn "/")))
> >	 (dir (directory dn))
> >         (file (unless dir (when (probe-file fn) fn))))

This last line should likely read

(file (or (probe-file fn) dir))

just to ensure that probe-file takes precedence.

> >    (format s "HTTP/1.1 ~S~%" (if fn 404 500))
> >    (format s "Content-type: text/html~%~%")
> >    (format t "get ~a fn ~a dn ~a~%" get fn dn)
> >    (cond (file (with-open-file (q file) (si::copy-stream q s)))
> >	  (dir  (dolist (l dir)
> >		  (let ((n (namestring l)))
> >		    (format s "<a href=\"~a\">~a</a> <a href=\"~a/\"> /... </a><br>~%" n n n)))))
> >    (close s)))
> >
> >=============================================================================
> >
> >These are just toys of course, just meant to illustrate my limited
> >understanding of how one can distinguish files from directories in
> >*standard* lisp.  We can add anything non-standard we might need, of
> > course.
> I like it. As I said, it works for me with the non-ansi gcl Version_2_6_7pre
> on Windows XP/sp2. No aborts this time.
> 
> And I am learning a little lisp too :) Thanks.

\start
Date: 05 May 2005 10:08:35 -0400
From: Camm Maguire
To: Mike Thomas
Subject: re: [Gcl-devel] Re: axiom porting

Greetings!

Would it be helpful for us to try to enlist the testing assistance of
other windows users/developers to lighten the load, e.g. Vadim and
David Billinghurst?

Take care,

Mike Thomas writes:

> Hi Bill.
> 
> | That is quite strange. I just re-build gcl Version_2_6_7pre (non-ansi)
> | from cvs on
> | another Windows XP/sp2 machine. Camm's web server program (latest version,
> | see Camm's email) continues to work fine for me.
> 
> XP SP2 CVS 2.6.7pre and both of gcc versions 3.3.1 and 3.4.2, using Camm's
> email version (and other versions at that).

\start
Date: Thu, 05 May 2005 10:14:03 -0400
From: Bill Page
To: Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas

Camm Maguire wrote:

>>>(probe-file "/msys/1.0")
>>>      
>>>
>>#p"c:/msys/1.0"
>>
>>    
>>
>>>(probe-file "/msys/1.0/")
>>>      
>>>
>>#p"c:/msys/1.0/"
>>
>>    
>>
>>>(probe-file "c:/msys/1.0/")
>>>      
>>>
>>#p"c:/msys/1.0/"
>>
>>    
>>
>>>(probe-file "c:/msys/1.0")
>>>      
>>>
>>#p"c:/msys/1.0"
>>
>>    
>>
>
>With the commits to 2.6.7pre I made yesterday, all these probe-files
>to directories should return nil.  Please let me know asap if this is
>not the case (still), and preferably why if you can discern the reason
>easily.
>
>  
>

I can confirm that these all do return nil on the build of gcl 
Version_2_6_7pre
that I did last night.

\start
Date: 05 May 2005 13:14:41 -0400
From: Camm Maguire
To: Bill Page
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas

Greetings!

Bill Page writes:

> Mike Thomas wrote:
> 
> >I just tried the CLtL1 build - no joy.
> >
> >There are definite problems with the new code as socket variables should be
> >defined with SOCKET (an unsigned int) rather than int and the error return
> >values on Windows are not the same as on BSD systems however I just tried to
> >eliminate those problems and still have the same trouble.
> >
> >I'm using Internet Explorer.
> >
> Ah, yes now I can confirm there are definite problems accessing the
> "gcl simple web server" using IE 6. I have been testing using Firefox 1.0.3
> and oddly exactly the same url works fine with no aborts.
> 
> >I'll keep looking perhaps tomorrow.  Hopefully
> >this is due to a stupid mistake on my part.
> >
> No I think you are right (we are both right :). There is a problem
> when using Internet Explorer. IE must be making rather different
> socket calls than FireFox. That seems quite odd to me.
> 
> Using IE, the problem seems to intermittant. It works for a while
> with some urls and not others.

Does this mean that there are some errors that are 100% reproducible?
If so, start with those.

> 
> Here is a typical failed test using IE.
> 
> ---------
> $ saved_gcl
> GCL (GNU Common Lisp)  2.6.7 CLtL1    May  4 2005 16:56:38
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> Binary License:  GPL due to GPL'ed components: (UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> 
>  >(load "test-http2.lsp")
> 
> Loading test-http2.lsp
> 
> ----------
> 
> Then using Microsoft Explorer 6 sp2 and url
>   http://localhost:8085/msys/1.0/
> I get the following error:
> 
> ----------
> 
> get GET fn /msys/1.0/ dn /msys/1.0/
> 
> Error: error writing to socket: errno= 22
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by FORMAT.
> Broken at FORMAT.  Type :H for Help.
>  >>(si::use-fast-links nil)
> 
> NIL
>  >>:bt

IE appears to be closing the socket before your write completes.  The
odd thing is that you report that it is intermittent.  There are two
possibiities that come to mind -- either ie insists on a complete set
of html headers from the server, or there is a timeout issue.  You
need to do (si::use-fast-links nil) before the error, btw.  There may
also be a carriage return/line feed problem, i.e. ie could insist that
all newlines be preceeded by carriage returns.  Forget the lisp
sequence for cr's, but the docs should reveal it.  Does ie appear to
still be waiting for input when the error triggers?  Lastly, you could
try reproducing the error with the little utility 'netcat' listening
on the port, and typing the same text in once the connection is made.
I suppose if we cannot reproduce with this, then there must be some
other incompatible socket type/protocol (i.e. 'embrace and extend')
that ie is expecting in this case.  Another idea is to fire up the
server on a Linux box on the same net and try to reproduce.  IE might
treat foreign sockets in the standard way, but local sockets
proprietarily.

Of course, we could just use firefox for axiom, which would avoid
any other browser incompatibilities too.

> 
> #0   FORMAT {loc0=#<two-way stream 1022ad14>,loc1="<a
> href=\"~a\">~a</a> <a href=\"~a/\"> /....} [ihs=19]
> #1   FORMAT {loc0=#<two-way stream 1022ad14>,loc1="<a
> href=\"~a\">~a</a> <a href=\"~a/\"> /....} [ihs=18]
> #2   FOO {} [ihs=13]
> #3   BAR {lambda-block=foo,} [ihs=8]
> #4   LOAD {loc0=nil,loc1=nil,loc2=nil,loc3=(lambda-block bar (p fn)
> ...),loc4=8085,loc5=(l...} [ihs=7]
> #5   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function
> load>,loc4=#p"test-http2.ls...} [ihs=6]
> #6   TOP-LEVEL
> {loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7="C:/msys/1.0/ho...}
> [ihs=5]
> #7   FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
> NIL
>  >>
> 
> --------------
> 
> Does this back trace help to see what's going wrong?
> 
> If I start again and do the same thing using FireFox I get:
> 
> $ saved_gcl
> GCL (GNU Common Lisp)  2.6.7 CLtL1    May  4 2005 16:56:38
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> Binary License:  GPL due to GPL'ed components: (UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> 
>  >(load "test-http2.lsp")
> 
> Loading test-http2.lsp
> get GET fn /msys/1.0/ dn /msys/1.0/
> get GET fn /favicon.ico dn /favicon.ico/
> 
> --------
> 
> And the list directories appears in the browser.
> 
> Let me know what I can try next.
> 

\start
Date: Thu, 05 May 2005 13:43:55 -0400
From: Bill Page
To: Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas

Camm Maguire wrote:

>>Using IE, the problem seems to intermittant. It works for a while
>>with some urls and not others.
>>    
>>
>
>Does this mean that there are some errors that are 100% reproducible?
>If so, start with those.
>  
>
Yes.

>IE appears to be closing the socket before your write completes.  The
>odd thing is that you report that it is intermittent.  There are two
>possibiities that come to mind -- either ie insists on a complete set
>of html headers from the server, or there is a timeout issue.
>
Ok, problem solved (I think). It turned out not to be so exotic an issue.
I modified the web server program as follows:

-    (format s "HTTP/1.1 ~S~%" (if fn 404 500))
+    (format s "HTTP/1.1 ~S~%" (if fn 200 404 ))

If I understand HTTP correctly "404" in the header means "file not found".
"200" means "ok". "500" means server error. So we were both saying
"file not found" but then delivering the file anyway. If that's the case
then it is surprizing that FireFox worked and not surprizing that IE closes
the socket connection before we can send the file.

With this change both FireFox and IE now seem to work reliable
and identically for me.

Anyway, I will take a closer look at the HTTP standard to make sure
that our headers are correct and complete.

\start
Date: 05 May 2005 14:35:54 -0400
From: Camm Maguire
To: Bill Page
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas

Greetings!

Bill Page writes:

> Camm Maguire wrote:
> 
> >>Using IE, the problem seems to intermittant. It works for a while
> >>with some urls and not others.
> >>
> >
> >Does this mean that there are some errors that are 100% reproducible?
> >If so, start with those.
> >
> Yes.
> 
> >IE appears to be closing the socket before your write completes.  The
> >odd thing is that you report that it is intermittent.  There are two
> >possibiities that come to mind -- either ie insists on a complete set
> >of html headers from the server, or there is a timeout issue.
> >
> Ok, problem solved (I think). It turned out not to be so exotic an issue.
> I modified the web server program as follows:
> 
> -    (format s "HTTP/1.1 ~S~%" (if fn 404 500))
> +    (format s "HTTP/1.1 ~S~%" (if fn 200 404 ))
> 

Thanks!  This is just what we need -- an html guy!

BTW, misspoke earlier re: suggested edit to #"foo.  What I meant was:

(defun foo (s)  
  (let* ((get (read s nil 'eof))
         (fn (and (eq get 'get) (string-downcase (read s nil 'eof))))
	 (file (probe-file fn)))
    
    (format s "HTTP/1.1 ~S~%" (if fn 200 404))
    (format s "Content-type: text/html~%~%")
    
    (if file 
	(with-open-file (q file) (si::copy-stream q s))
      (let ((dir (directory (if (eql (aref fn (1- (length fn))) #\/) fn (si::string-concatenate fn "/")))))
	(dolist (l dir)
	  (let ((n (namestring l)))
	    (format s "<a href=\"~a\">~a</a> <a href=\"~a/\"> /... </a><br>~%" n n n)))))
   (close s)))

which should function the same as what you have but express the
precedence better.  This counts on probe-file returning nil for
directories. 

Take care,

> If I understand HTTP correctly "404" in the header means "file not found".
> "200" means "ok". "500" means server error. So we were both saying
> "file not found" but then delivering the file anyway. If that's the case
> then it is surprizing that FireFox worked and not surprizing that IE closes
> the socket connection before we can send the file.
> 
> With this change both FireFox and IE now seem to work reliable
> and identically for me.
> 
> Anyway, I will take a closer look at the HTTP standard to make sure
> that our headers are correct and complete.

\start
Date: Fri, 6 May 2005 08:53:58 +1000
From: Mike Thomas
To: Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting

Hi Camm/Bill.

Positive results on some basic tests per Cam's directory fix yesterday.

| > >(probe-file "/msys/1.0")
| >
| > #p"c:/msys/1.0"
| >
| > >(probe-file "/msys/1.0/")
| >
| > #p"c:/msys/1.0/"
| >
| > >(probe-file "c:/msys/1.0/")
| >
| > #p"c:/msys/1.0/"
| >
| > >(probe-file "c:/msys/1.0")
| >
| > #p"c:/msys/1.0"
| >
|
| With the commits to 2.6.7pre I made yesterday, all these probe-files
| to directories should return nil.

Positive result on those changes thanks:

>(probe-file "/msys/1.0")

NIL

>(probe-file "c:/msys/1.0")

NIL

>(probe-file "c:/msys/1.0/msys.bat")

#p"c:/msys/1.0/msys.bat"

>(probe-file "c:/msys/1.0/")

NIL



| > >(bar 8085 #'foo)
| >
| > Error in LET [or a callee]: Error "No such file or directory"
| on accepting
| > conne
| > ction to #<two-way stream 104c969c>
| >
|
| At least on Linux, accept might fail with a EAGAIN or similar if no
| connections are pending.  It is critical to this example that the call
| to #'listen in #'bar correctly return t iff a connection has been
| made.  You can test this with telnet from a separate shell window.
| I.e.
|
| (setq s (si::socket 8085 :server #'foo))
| (listen s) -> nil (no telnet localhost 8085)
| (listen s) -> t (after telnet localhost 8085)

Using the local current state of the Windows socket code as I have no time
to revert to the original state (ie these tests after I fixed the winsock
return values and types; day of meetings ahead) these two tests work OK.

I probably won't have time to insert these patches (below) into CVS today
but hopefully over the weekend although I'm looking rather tight there too
at present.


cvs diff: Diffing o
Index: o/file.d
===================================================================
RCS file: /cvsroot/gcl/gcl/o/file.d,v
retrieving revision 1.21.4.1.2.8.10.5
diff -r1.21.4.1.2.8.10.5 file.d
2245a2246,2248
> #ifdef _WIN32
> SOCKET fd;
> #else
2246a2250
> #endif
2254c2258,2262
<   if (fd < 0 )
---
> #ifdef _WIN32
>   if ( INVALID_SOCKET == fd )
> #else
>   if ( fd < 0 )
> #endif
2290c2298,2303
<   int fd,n;
---
> #ifdef _WIN32
>   SOCKET fd;
> #else
>   int fd;
> #endif
>   int n;
2299c2312,2316
<   if (fd <0) {
---
> #ifdef _WIN32
>   if ( INVALID_SOCKET == fd ) {
> #else
>   if ( fd < 0 ) {
> #endif
2338a2356,2358
> #ifdef _WIN32
> SOCKET fd;
> #else
2339a2360
> #endif
2470c2491,2495
<
---
> #ifdef _WIN32
>     if ( INVALID_SOCKET == fd ) {
>          FEerror("CreateSocket returned an invalid socket", 0);
>     }
> #endif
Index: o/mingwin.c
===================================================================
RCS file: /cvsroot/gcl/gcl/o/mingwin.c,v
retrieving revision 1.8.6.3.2.1
diff -r1.8.6.3.2.1 mingwin.c
406c406
< int
---
> SOCKET
432c432
<       return -1;
---
>       return INVALID_SOCKET;
562c562
<     return -1;
---
>     return INVALID_SOCKET;

miketh@WATER /c/cvs/stable/gcl-2.6.7pre
$ export CVS_RSH=ssh; cvs diff h
Enter passphrase for key '/home/miketh/.ssh/id_dsa':
? h/cmpinclude.h
? h/config.h
? h/gclincl.h
? h/new_decl.h
cvs diff: Diffing h
Index: h/protoize.h
===================================================================
RCS file: /cvsroot/gcl/gcl/h/protoize.h,v
retrieving revision 1.26.4.1.2.1.2.11.6.1.6.1.2.3
diff -r1.26.4.1.2.1.2.11.6.1.6.1.2.3 protoize.h
319a320,322
> #ifdef _WIN32
> /* mingwin.c:190:OF */ extern unsigned int CreateSocket (int port, char
*hos
 int server, char *myaddr, int myport, int async); /* (port, host, server,
mya
r, myport, async) int port; char *host; int server; char *myaddr; int
myport;
t async; */
> #else
320a324
> #endif

\start
Date: Fri, 6 May 2005 04:45:38 +0200
From: Vanuxem Gregory
To: Mike Thomas, Camm Maguire
Subject: RE: [Gcl-devel] Re: Dynamic Library Linking (arbitray float)

Serious question about GCL,

I've lost your mail about (arbitrary float),
But how do yo think peopole can implement arbitrary float in gcl; whith MPFR
?
With class or directly in num_arith... ?

Camm... one Idea....?

Actually AXIOM doesn't compile with ANSI version ...
I know that you work on tcl/tk, documentation and graphics , doesn't forget
the concept of 'notebook'
(literate programming and other things...).


Generally I work on UNIX* (linux and BSD*) but actually ((numerical stuff to
implemenent: transcendental function for matrix (see Higham
(http://www.ma.man.ac.uk/~higham/ and gang) with linear algebra (atlas, blas
and lapack ...))
I' am on Windows(R) (thanks M.Thomas ...).
I think in AXIOM five things has to be seriously be enhanced (for future
library use...):

1) 'Integer' in arbitrary integer:							'GMP (realized)'
2) 'Floating number' in arbitrary float (cf: Monagan, Michael (1990)):	'ADD
MPFR'
3) 'Fraction Integer' with gmp (GMP)						'GMP (realized)'
	(cf:
(http://page.axiom-developer.org/zope/mathaction/EnhancedFractionDomain),
      I will update and explain this when time permits.
4) C (or fortran) Dynamic library linkink in GCL. '...' Idea Maguire ?
5) Documentation about what I say.

-----Message d'origine-----

Greetings!

Mike Thomas writes:

> Hi Camm.
>
> | This is indeed the short answer -- you can link in any new symbols you
> | want that are not present in the original image via compiler::link.
> | See the documentation for this function in gcl-si.{texi,info}.  What
> | this essentially does is build a new gcl image using a fresh call to
> | the system linker ld to modify the image symbol table with whatever
> | new code or libraries you specify.  It has the disadvantage that the
> | image is 'fresh' -- i.e. any work you may have done in the running
> | image before compiling compiler::link is lost.  Such work can be
> | respecified to run by hand in the fresh new image through one of
> | compiler::link's arguments, but this is a bit awkward to use.
> |7
> | What I'd like to do in 2.7.0 is to allow the user to link in new
> | dynamic libraries at runtime, modify the running image's symbol table,
> | and allow this work to be preserved across image saves via
> | si::save-system.  What this essentially means is that unexec needs to
> | add a little section to the end of the dumped image containing
> | relocation records for the new symbols for use by the system's dynamic
> | linker (ld.so on Linux), i.e. a GOT (Global Access Table).
>
> If I understand you correctly, on Windows one could store the name of the
> symbol and the name of the DLL from whence it came, then while resolving
> references at ru(i)ntime to call LoadLibrary() and GetProcAddress() for
each
> pair as shown here:
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/
> base/using_run_time_dynamic_linking.asp
>
> I believe that PE-COFF executables actually have a section for external
> library references (ie references to DLL's) into which unexec might put
this
> kind of information so that the OS could automatically do the external
> relocation work at image load time (though probably only for those
> relocation records in the text sections I guess) .  This is all pretty
hairy
> though, especially as Windows moves towards 64 bits and whatever system
> changes might come with that.
>

This is exactly the idea.  When we have time :-).

Take care,


> | A kludgy way of doing this without any special executable format
> | knowledge might be to expand the explicit C plt table (mplt in plt.c)
> | with a bunch of dummy entries referring to unused symbols in external
> | shared libs, one of which we might provide for this purpose.  Then
> | when new symbols are needed, these symbols could be changed.  This
> | would still require us to be able to find the symbol in the image's
> | symbol table, but at least we would not have to add any new sections,
> | etc.  Of course this approach is rather awkward and limited too.
>
> It all sounds awkward to me as I'm pretty vague on all of this.

\start
Date: Fri, 06 May 2005 09:28:47 -0400
From: Bill Page
To: Camm Maguire
Subject: re: [Gcl-devel] Re: axiom porting
Cc: Mike Thomas

Camm Maguire wrote:

>Bill Page writes:
>  
>
>>Ok, problem solved (I think). It turned out not to be so exotic an issue.
>>I modified the web server program as follows:
>>
>>-    (format s "HTTP/1.1 ~S~%" (if fn 404 500))
>>+    (format s "HTTP/1.1 ~S~%" (if fn 200 404 ))
>>
>Thanks!  This is just what we need -- an html guy!
>  
>
Well, ah ...

>>If I understand HTTP correctly "404" in the header means "file not found".
>>"200" means "ok". "500" means server error. So we were both saying
>>"file not found" but then delivering the file anyway. If that's the case
>>then it is surprizing that FireFox worked and not surprizing that IE closes
>>the socket connection before we can send the file.
>>
>>With this change both FireFox and IE now seem to work reliable
>>and identically for me.
>>
>>Anyway, I will take a closer look at the HTTP standard to make sure
>>that our headers are correct and complete.
>>
For quick reference here is a very easy introdution to HTTP:

  http://www.jmarshall.com/easy/http


  HTTP Made Really Easy


    A Practical Guide to Writing Clients and Servers

\start
Date: 06 May 2005 10:00:00 -0400
From: Camm Maguire
To: Vanuxem Gregory
Subject: Re: [Gcl-devel] Re: Dynamic Library Linking (arbitray float)
Cc: Mike Thomas

Greetings!

Gregory Vanuxem writes:

> Serious question about GCL,
> 
> I've lost your mail about (arbitrary float),
> But how do yo think peopole can implement arbitrary float in gcl; whith MPFR
> ?
> With class or directly in num_arith... ?
> 
> Camm... one Idea....?
> 

For lack of a better idea, I was thinking of something along the lines
of what clisp does -- have a system parameter which sets the 'big
float' precision, and then define a 'big float' type with coercion
rules identical to that between the existing short float and long
float types.  This would all be in num_arith, just as the 'bignum'
integers are now.  I was not envisioning any compiler support, thought
this could be added at some point.  I.e. array's of bigfloats would be
array's of objects, as opposed to array's of 16byte float numbers, for
example.  

I don't see a reason to do this, however, unless there is a benefit to
an existing application.  Axiom does its own bigfloat stuff already,
as does maxima.  Now if we can demonstrate that performance gains along
the lines of what you are seeing with the gcd stuff in gmp can be had,
that is a good reason, and should motivate us to get this in quickly
provided that axiom and/or maxima expresses their intention to use it.
There is just so much to do, I don't want to work on stuff which won't
be used, at least not right now.

> Actually AXIOM doesn't compile with ANSI version ...

IMHO, a strength of GCL is that we support both CLtL1 and (work in
progress) ANSI dialects to allow existing applications to decide if
and when to migrate to ANSI.  maxima has migrated to ANSI, largely
because they have a sizeable staff of lisp volunteers who are used to
ANSI, which is a good reason.  ACL2 and AXIOM have not yet, as their
lisp teams are familiar with and find what they need in CLtL1.  In my
opinion, they should have the option of choosing if and when to migrate
in the context of their other development considerations.

If memory serves, plenty of lisp 'heavy-weights' don't use ansi
features, e.g. CLOS, presumably because they don't want the overhead.
If memory serves, Paul Graham said he's never used it, but double
check that before relying upon it.

I'm missing the connection of this statement to the one above ...

> I know that you work on tcl/tk, documentation and graphics , doesn't forget
> the concept of 'notebook'
> (literate programming and other things...).
> 

I'm afraid I don't follow.

> 
> Generally I work on UNIX* (linux and BSD*) but actually ((numerical stuff to
> implemenent: transcendental function for matrix (see Higham
> (http://www.ma.man.ac.uk/~higham/ and gang) with linear algebra (atlas, blas
> and lapack ...))
> I' am on Windows(R) (thanks M.Thomas ...).
> I think in AXIOM five things has to be seriously be enhanced (for future
> library use...):
> 
> 1) 'Integer' in arbitrary integer:							'GMP (realized)'

Is this not already the case???

> 2) 'Floating number' in arbitrary float (cf: Monagan, Michael (1990)):	'ADD
> MPFR'

Is this not already the case???  Or are we talking performance here?

> 3) 'Fraction Integer' with gmp (GMP)						'GMP (realized)'
> 	(cf:
> (http://page.axiom-developer.org/zope/mathaction/EnhancedFractionDomain),
>       I will update and explain this when time permits.

I agree presuming we can test exhaustively.  If there is interest in
axiom for this, I'll move the rational arithmetic accelerations into
soon to be released 2.6.7, otherwise it will wait for 2.7.0.

> 4) C (or fortran) Dynamic library linkink in GCL. '...' Idea Maguire ?

There is a recent thread on gcl-devel expressing my ideas on this.
All we really need is a little enhancement to unexec to store dynamic
relocation records in a dumped image.  Perhaps an unexecbfd might help
here. 

But even now this is far more serviceable than it used to be.  See the
example on linking in ddot from libblas recently posted to
gcl-devel@gnu.org using compiler::link.

> 5) Documentation about what I say.
> 

Yes, please!

Take care,

> Cheers,
> 
> Greg
> 
> -----Message d'origine-----
> De : gcl-devel-bounces+g.vanuxem=wanadoo.fr@gnu.org
> [mailto:gcl-devel-bounces+g.vanuxem=wanadoo.fr@gnu.org]De la part de
> Camm Maguire
> Envoye : jeudi 5 mai 2005 21:02
> A : Mike Thomas
> Cc : gcl-devel@gnu.org
> Objet : [Gcl-devel] Re: Dynamic Library Linking
> 
> 
> Greetings!
> 
> Mike Thomas writes:
> 
> > Hi Camm.
> >
> > | This is indeed the short answer -- you can link in any new symbols you
> > | want that are not present in the original image via compiler::link.
> > | See the documentation for this function in gcl-si.{texi,info}.  What
> > | this essentially does is build a new gcl image using a fresh call to
> > | the system linker ld to modify the image symbol table with whatever
> > | new code or libraries you specify.  It has the disadvantage that the
> > | image is 'fresh' -- i.e. any work you may have done in the running
> > | image before compiling compiler::link is lost.  Such work can be
> > | respecified to run by hand in the fresh new image through one of
> > | compiler::link's arguments, but this is a bit awkward to use.
> > |7
> > | What I'd like to do in 2.7.0 is to allow the user to link in new
> > | dynamic libraries at runtime, modify the running image's symbol table,
> > | and allow this work to be preserved across image saves via
> > | si::save-system.  What this essentially means is that unexec needs to
> > | add a little section to the end of the dumped image containing
> > | relocation records for the new symbols for use by the system's dynamic
> > | linker (ld.so on Linux), i.e. a GOT (Global Access Table).
> >
> > If I understand you correctly, on Windows one could store the name of the
> > symbol and the name of the DLL from whence it came, then while resolving
> > references at ru(i)ntime to call LoadLibrary() and GetProcAddress() for
> each
> > pair as shown here:
> >
> >
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/
> > base/using_run_time_dynamic_linking.asp
> >
> > I believe that PE-COFF executables actually have a section for external
> > library references (ie references to DLL's) into which unexec might put
> this
> > kind of information so that the OS could automatically do the external
> > relocation work at image load time (though probably only for those
> > relocation records in the text sections I guess) .  This is all pretty
> hairy
> > though, especially as Windows moves towards 64 bits and whatever system
> > changes might come with that.
> >
> 
> This is exactly the idea.  When we have time :-).
> 
> Take care,
> 
> 
> > | A kludgy way of doing this without any special executable format
> > | knowledge might be to expand the explicit C plt table (mplt in plt.c)
> > | with a bunch of dummy entries referring to unused symbols in external
> > | shared libs, one of which we might provide for this purpose.  Then
> > | when new symbols are needed, these symbols could be changed.  This
> > | would still require us to be able to find the symbol in the image's
> > | symbol table, but at least we would not have to add any new sections,
> > | etc.  Of course this approach is rather awkward and limited too.
> >
> > It all sounds awkward to me as I'm pretty vague on all of this.

\start
Date: Fri, 6 May 2005 19:14:23 +0200
From: Vanuxem Gregory
To: Camm Maguire
Subject: RE: [Gcl-devel] Re: Dynamic Library Linking (arbitray float)
Cc: Mike Thomas

Hi,

Some correction about this incomprehensible e-mail.

>
>
> Greetings!
>
> Gregory Vanuxem writes:
>
> > Serious question about GCL,

One question about GCL and multiple-precision
floating-point computations.

> > I've lost your mail about (arbitrary float),
> > But how do yo think peopole can implement arbitrary float in
> gcl; whith MPFR

How do you think someone can implement arbitrary float (MPFR)
in gcl ?

> > ?
> > With class or directly in num_arith... ?
> >
> > Camm... one Idea....?
> >
>
> For lack of a better idea, I was thinking of something along the lines
> of what clisp does -- have a system parameter which sets the 'big
> float' precision, and then define a 'big float' type with coercion
> rules identical to that between the existing short float and long
> float types.  This would all be in num_arith, just as the 'bignum'
> integers are now.

With a new 'switch ... case' ?

>I was not envisioning any compiler support, thought
> this could be added at some point.  I.e. array's of bigfloats would be
> array's of objects, as opposed to array's of 16byte float numbers, for
> example.
>
> I don't see a reason to do this, however, unless there is a benefit to
> an existing application.  Axiom does its own bigfloat stuff already,
> as does maxima.  Now if we can demonstrate that performance gains along
> the lines of what you are seeing with the gcd stuff in gmp can be had,
> that is a good reason, and should motivate us to get this in quickly
> provided that axiom and/or maxima expresses their intention to use it.
> There is just so much to do, I don't want to work on stuff which won't
> be used, at least not right now.

Just for information.


Here begins Post-Scriptum:

>
> > Actually AXIOM doesn't compile with ANSI version ...

Sometimes I think about multiple-precision floating-point
computations in GCL and connection with other CAS.
CLOS require ANSI dialect isn't it?

>
> IMHO, a strength of GCL is that we support both CLtL1 and (work in
> progress) ANSI dialects to allow existing applications to decide if
> and when to migrate to ANSI.  maxima has migrated to ANSI, largely
> because they have a sizeable staff of lisp volunteers who are used to
> ANSI, which is a good reason.  ACL2 and AXIOM have not yet, as their
> lisp teams are familiar with and find what they need in CLtL1.  In my
> opinion, they should have the option of choosing if and when to migrate
> in the context of their other development considerations.
>
> If memory serves, plenty of lisp 'heavy-weights' don't use ansi
> features, e.g. CLOS, presumably because they don't want the overhead.
> If memory serves, Paul Graham said he's never used it, but double
> check that before relying upon it.
>

Thanks for this information.

> I'm missing the connection of this statement to the one above ...
>
> > I know that you work on tcl/tk, documentation and graphics ,
> >doesn't forget the concept of 'notebook'
> > (literate programming and other things...).
> >
>
> I'm afraid I don't follow.

Translation:

In some recent discussion, the notion of portable graphic library
has been evoked and its utilization with graphic and documentation.
I always think about a colossal work: notebook and
interaction with literate programming. The graphic library
has may be (for me) to be choosen such that:

i)  works under different OS
ii) it is compliant with other projects


> > Generally I work on UNIX* (linux and BSD*) but actually
> ((numerical stuff to
> > implemenent: transcendental function for matrix (see Higham
> > (http://www.ma.man.ac.uk/~higham/ and gang) with linear algebra
> (atlas, blas
> > and lapack ...))
> > I' am on Windows(R) (thanks M.Thomas ...).


> > I think in AXIOM five things has to be seriously be enhanced (for future
> > library use...):

My branch of AXIOM has to be enhanced in four directions.
Three types seem important (not for performance):
Integer, Real and Rational.

> >
> > 1) 'Integer' in arbitrary integer:
> 		'GMP (realized)'
>
> Is this not already the case???
>
> > 2) 'Floating number' in arbitrary float (cf: Monagan, Michael
> (1990)):	'ADD
> > MPFR'
>
> Is this not already the case???  Or are we talking performance here?
>
> > 3) 'Fraction Integer' with gmp (GMP)
> 		'GMP (realized)'
> > 	(cf:
> >
> (http://page.axiom-developer.org/zope/mathaction/EnhancedFractionDomain),
> >       I will update and explain this when time permits.
>
> I agree presuming we can test exhaustively.  If there is interest in
> axiom for this, I'll move the rational arithmetic accelerations into
> soon to be released 2.6.7, otherwise it will wait for 2.7.0.

This work is not destined to be included in axiom.

>
> > 4) C (or fortran) Dynamic library linkink in GCL. '...' Idea Maguire ?
>
> There is a recent thread on gcl-devel expressing my ideas on this.
> All we really need is a little enhancement to unexec to store dynamic
> relocation records in a dumped image.  Perhaps an unexecbfd might help
> here.
>
> But even now this is far more serviceable than it used to be.  See the
> example on linking in ddot from libblas recently posted to
> gcl-devel@gnu.org using compiler::link.

Is there some specification about foreign language call in Common Lisp ?

> > 5) Documentation about what I say.
> >
>
> Yes, please!

>
> Take care,
>

Cheers,

Greg


> >
> > -----Message d'origine-----
> > De : gcl-devel-bounces+g.vanuxem=wanadoo.fr@gnu.org
> > [mailto:gcl-devel-bounces+g.vanuxem=wanadoo.fr@gnu.org]De la part de
> > Camm Maguire
> > Envoye : jeudi 5 mai 2005 21:02
> > A : Mike Thomas
> > Cc : gcl-devel@gnu.org
> > Objet : [Gcl-devel] Re: Dynamic Library Linking
> >
> >
> > Greetings!
> >
> > Mike Thomas writes:
> >
> > > Hi Camm.
> > >
> > > | This is indeed the short answer -- you can link in any new
> symbols you
> > > | want that are not present in the original image via compiler::link.
> > > | See the documentation for this function in gcl-si.{texi,info}.  What
> > > | this essentially does is build a new gcl image using a fresh call to
> > > | the system linker ld to modify the image symbol table with whatever
> > > | new code or libraries you specify.  It has the disadvantage that the
> > > | image is 'fresh' -- i.e. any work you may have done in the running
> > > | image before compiling compiler::link is lost.  Such work can be
> > > | respecified to run by hand in the fresh new image through one of
> > > | compiler::link's arguments, but this is a bit awkward to use.
> > > |7
> > > | What I'd like to do in 2.7.0 is to allow the user to link in new
> > > | dynamic libraries at runtime, modify the running image's
> symbol table,
> > > | and allow this work to be preserved across image saves via
> > > | si::save-system.  What this essentially means is that
> unexec needs to
> > > | add a little section to the end of the dumped image containing
> > > | relocation records for the new symbols for use by the
> system's dynamic
> > > | linker (ld.so on Linux), i.e. a GOT (Global Access Table).
> > >
> > > If I understand you correctly, on Windows one could store the
> name of the
> > > symbol and the name of the DLL from whence it came, then
> while resolving
> > > references at ru(i)ntime to call LoadLibrary() and
> GetProcAddress() for
> > each
> > > pair as shown here:
> > >
> > >
> >
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/
> > > base/using_run_time_dynamic_linking.asp
> > >
> > > I believe that PE-COFF executables actually have a section
> for external
> > > library references (ie references to DLL's) into which unexec
> might put
> > this
> > > kind of information so that the OS could automatically do the external
> > > relocation work at image load time (though probably only for those
> > > relocation records in the text sections I guess) .  This is all pretty
> > hairy
> > > though, especially as Windows moves towards 64 bits and
> whatever system
> > > changes might come with that.
> > >
> >
> > This is exactly the idea.  When we have time :-).
> >
> > Take care,
> >
> >
> > > | A kludgy way of doing this without any special executable format
> > > | knowledge might be to expand the explicit C plt table (mplt
> in plt.c)
> > > | with a bunch of dummy entries referring to unused symbols
> in external
> > > | shared libs, one of which we might provide for this purpose.  Then
> > > | when new symbols are needed, these symbols could be changed.  This
> > > | would still require us to be able to find the symbol in the image's
> > > | symbol table, but at least we would not have to add any new
> sections,
> > > | etc.  Of course this approach is rather awkward and limited too.
> > >
> > > It all sounds awkward to me as I'm pretty vague on all of this.

\start
Date: 06 May 2005 17:26:38 -0400
From: Camm Maguire
To: rlbk@melix.net
Subject: [MACOSX] What is unexec and why does it fail ?
Cc: Robert Boyer, Aurelien Chanudet, Warren Hunt

Greetings!

Aurelien, Darwin appears to be missing on_exit, which I've been using
in the new socket code to destroy forked children when the parent
quits.  Is there similar on Darwin, or does this happen automatically
anyway?

Have just tested 2.6.7 on macosx successfully.  I take it you are too
busy to look at the large memory image issue, yes?

Take care,

Aurelien Chanudet writes:

> > Beyond the axiom issue discussed below, some acl2
> > users at the
> > University of Texas are running into difficulties
> > with the mac code
> > when making very large images.  Would you have a
> > chance to try to
> > build ACL2 with maxpages doubled, quadrupled, and
> > even multiplied by 8
> > if you OS allows?  Please let me know if you have
> > some time to
> > investigate this.  I can send you more information
> > if so.
>
> What version of ACL2 and gcl are these people using ?
> Will try to give this a look as time permits. By the
> way, what's the status of SGC on the Mac now ? There
> have been some recent issues as far as I remember.
>
> > What dedication!  Is this a known issue on the Mac?
> > Any help from the
> > gdb developers?
>
> This is a known issue on the Mac, albeit one that
> interests no one but me (for understandable reasons, I
> feel it way more confortable to debug SGC in GCL using
> gdb than using printf debugging). Basically, attaching
> gdb to a process, say GCL, which handles segfaults on
> its own, makes it impossible for the signal handler to
> be called. Gdb will simply refuse to pass the
> exception to the program. This is due to the way
> traditionnal Unix signals are handled in MacOSX's Mach
> kernel. Traditionnal signals are handled by a BSD
> layer which gdb bypasses...
>
> > I'm not sure what you mean here.  Its in the CVS
> > head tree (aka 2.7.0)
> > to my understanding.  Should I post it to the
> > website on the errata
> > page?
>
> It must be fine then. I must confess I'm not "CVS
> savvy". I just wanted to make sure that the file can
> be retrieved when using the basic "cvs login / cvs co"
> sequence.
>
> > 1) Add reloc records for any symbols relocated to a
> > dlopened library
> >    in a given session, together with whatever
> > section is also needed
> >    to indicate that the image is (now permanently)
> > dynamically linked
> >    against the lib.
> >
> > 2) Merge gprof section info from any loaded .o files
> > into the final
> >    saved image so that profiling will work without
> > having to generate
> >    a fresh image with ld.
>
> Under what form are gprof information stored ?

\start
Date: 06 May 2005 18:42:11 -0400
From: Camm Maguire
To: Vanuxem Gregory
Subject: Re: [Gcl-devel] Re: Dynamic Library Linking (arbitray float)
Cc: Mike Thomas

Greetings!

Gregory Vanuxem writes:

> Hi,
> 
> Some correction about this incomprehensible e-mail.
> 
> >
> >
> > Greetings!
> >
> > Gregory Vanuxem writes:
> >
> > > Serious question about GCL,
> 
> One question about GCL and multiple-precision
> floating-point computations.
> 
> > > I've lost your mail about (arbitrary float),
> > > But how do yo think peopole can implement arbitrary float in
> > gcl; whith MPFR
> 
> How do you think someone can implement arbitrary float (MPFR)
> in gcl ?
> 
> > > ?
> > > With class or directly in num_arith... ?
> > >
> > > Camm... one Idea....?
> > >
> >
> > For lack of a better idea, I was thinking of something along the lines
> > of what clisp does -- have a system parameter which sets the 'big
> > float' precision, and then define a 'big float' type with coercion
> > rules identical to that between the existing short float and long
> > float types.  This would all be in num_arith, just as the 'bignum'
> > integers are now.
> 
> With a new 'switch ... case' ?
> 

Basically, yes.

> >I was not envisioning any compiler support, thought
> > this could be added at some point.  I.e. array's of bigfloats would be
> > array's of objects, as opposed to array's of 16byte float numbers, for
> > example.
> >
> > I don't see a reason to do this, however, unless there is a benefit to
> > an existing application.  Axiom does its own bigfloat stuff already,
> > as does maxima.  Now if we can demonstrate that performance gains along
> > the lines of what you are seeing with the gcd stuff in gmp can be had,
> > that is a good reason, and should motivate us to get this in quickly
> > provided that axiom and/or maxima expresses their intention to use it.
> > There is just so much to do, I don't want to work on stuff which won't
> > be used, at least not right now.
> 
> Just for information.
> 
> 
> Here begins Post-Scriptum:
> 
> >
> > > Actually AXIOM doesn't compile with ANSI version ...
> 
> Sometimes I think about multiple-precision floating-point
> computations in GCL and connection with other CAS.

OK.

> CLOS require ANSI dialect isn't it?

Rather ANSI requires CLOS, but what has this to do with mfpr?

> 
> >
> > IMHO, a strength of GCL is that we support both CLtL1 and (work in
> > progress) ANSI dialects to allow existing applications to decide if
> > and when to migrate to ANSI.  maxima has migrated to ANSI, largely
> > because they have a sizeable staff of lisp volunteers who are used to
> > ANSI, which is a good reason.  ACL2 and AXIOM have not yet, as their
> > lisp teams are familiar with and find what they need in CLtL1.  In my
> > opinion, they should have the option of choosing if and when to migrate
> > in the context of their other development considerations.
> >
> > If memory serves, plenty of lisp 'heavy-weights' don't use ansi
> > features, e.g. CLOS, presumably because they don't want the overhead.
> > If memory serves, Paul Graham said he's never used it, but double
> > check that before relying upon it.
> >
> 
> Thanks for this information.
> 
> > I'm missing the connection of this statement to the one above ...
> >
> > > I know that you work on tcl/tk, documentation and graphics ,
> > >doesn't forget the concept of 'notebook'
> > > (literate programming and other things...).
> > >
> >
> > I'm afraid I don't follow.
> 
> Translation:
> 
> In some recent discussion, the notion of portable graphic library
> has been evoked and its utilization with graphic and documentation.
> I always think about a colossal work: notebook and
> interaction with literate programming. The graphic library
> has may be (for me) to be choosen such that:
> 
> i)  works under different OS
> ii) it is compliant with other projects
> 
> 
> > > Generally I work on UNIX* (linux and BSD*) but actually
> > ((numerical stuff to
> > > implemenent: transcendental function for matrix (see Higham
> > > (http://www.ma.man.ac.uk/~higham/ and gang) with linear algebra
> > (atlas, blas
> > > and lapack ...))
> > > I' am on Windows(R) (thanks M.Thomas ...).
> 
> 
> > > I think in AXIOM five things has to be seriously be enhanced (for future
> > > library use...):
> 
> My branch of AXIOM has to be enhanced in four directions.
> Three types seem important (not for performance):
> Integer, Real and Rational.
> 

I don't understand what might be missing except for performance.
Please explain if you have the time.

> > >
> > > 1) 'Integer' in arbitrary integer:
> > 		'GMP (realized)'
> >
> > Is this not already the case???
> >
> > > 2) 'Floating number' in arbitrary float (cf: Monagan, Michael
> > (1990)):	'ADD
> > > MPFR'
> >
> > Is this not already the case???  Or are we talking performance here?
> >
> > > 3) 'Fraction Integer' with gmp (GMP)
> > 		'GMP (realized)'
> > > 	(cf:
> > >
> > (http://page.axiom-developer.org/zope/mathaction/EnhancedFractionDomain),
> > >       I will update and explain this when time permits.
> >
> > I agree presuming we can test exhaustively.  If there is interest in
> > axiom for this, I'll move the rational arithmetic accelerations into
> > soon to be released 2.6.7, otherwise it will wait for 2.7.0.
> 
> This work is not destined to be included in axiom.
> 

Why not?

> >
> > > 4) C (or fortran) Dynamic library linkink in GCL. '...' Idea Maguire ?
> >
> > There is a recent thread on gcl-devel expressing my ideas on this.
> > All we really need is a little enhancement to unexec to store dynamic
> > relocation records in a dumped image.  Perhaps an unexecbfd might help
> > here.
> >
> > But even now this is far more serviceable than it used to be.  See the
> > example on linking in ddot from libblas recently posted to
> > gcl-devel@gnu.org using compiler::link.
> 
> Is there some specification about foreign language call in Common Lisp ?
> 

Not in the standard.  Each implementation does its own.  GCL's is
pretty flexible IMHO.

> > > 5) Documentation about what I say.
> > >
> >
> > Yes, please!
> 
> >
> > Take care,
> >
> 
> Cheers,
> 

Take care,

> Greg
> 
> 
> > >
> > > -----Message d'origine-----
> > > De : gcl-devel-bounces+g.vanuxem=wanadoo.fr@gnu.org
> > > [mailto:gcl-devel-bounces+g.vanuxem=wanadoo.fr@gnu.org]De la part de
> > > Camm Maguire
> > > Envoye : jeudi 5 mai 2005 21:02
> > > A : Mike Thomas
> > > Cc : gcl-devel@gnu.org
> > > Objet : [Gcl-devel] Re: Dynamic Library Linking
> > >
> > >
> > > Greetings!
> > >
> > > Mike Thomas writes:
> > >
> > > > Hi Camm.
> > > >
> > > > | This is indeed the short answer -- you can link in any new
> > symbols you
> > > > | want that are not present in the original image via compiler::link.
> > > > | See the documentation for this function in gcl-si.{texi,info}.  What
> > > > | this essentially does is build a new gcl image using a fresh call to
> > > > | the system linker ld to modify the image symbol table with whatever
> > > > | new code or libraries you specify.  It has the disadvantage that the
> > > > | image is 'fresh' -- i.e. any work you may have done in the running
> > > > | image before compiling compiler::link is lost.  Such work can be
> > > > | respecified to run by hand in the fresh new image through one of
> > > > | compiler::link's arguments, but this is a bit awkward to use.
> > > > |7
> > > > | What I'd like to do in 2.7.0 is to allow the user to link in new
> > > > | dynamic libraries at runtime, modify the running image's
> > symbol table,
> > > > | and allow this work to be preserved across image saves via
> > > > | si::save-system.  What this essentially means is that
> > unexec needs to
> > > > | add a little section to the end of the dumped image containing
> > > > | relocation records for the new symbols for use by the
> > system's dynamic
> > > > | linker (ld.so on Linux), i.e. a GOT (Global Access Table).
> > > >
> > > > If I understand you correctly, on Windows one could store the
> > name of the
> > > > symbol and the name of the DLL from whence it came, then
> > while resolving
> > > > references at ru(i)ntime to call LoadLibrary() and
> > GetProcAddress() for
> > > each
> > > > pair as shown here:
> > > >
> > > >
> > >
> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/
> > > > base/using_run_time_dynamic_linking.asp
> > > >
> > > > I believe that PE-COFF executables actually have a section
> > for external
> > > > library references (ie references to DLL's) into which unexec
> > might put
> > > this
> > > > kind of information so that the OS could automatically do the external
> > > > relocation work at image load time (though probably only for those
> > > > relocation records in the text sections I guess) .  This is all pretty
> > > hairy
> > > > though, especially as Windows moves towards 64 bits and
> > whatever system
> > > > changes might come with that.
> > > >
> > >
> > > This is exactly the idea.  When we have time :-).
> > >
> > > Take care,
> > >
> > >
> > > > | A kludgy way of doing this without any special executable format
> > > > | knowledge might be to expand the explicit C plt table (mplt
> > in plt.c)
> > > > | with a bunch of dummy entries referring to unused symbols
> > in external
> > > > | shared libs, one of which we might provide for this purpose.  Then
> > > > | when new symbols are needed, these symbols could be changed.  This
> > > > | would still require us to be able to find the symbol in the image's
> > > > | symbol table, but at least we would not have to add any new
> > sections,
> > > > | etc.  Of course this approach is rather awkward and limited too.
> > > >
> > > > It all sounds awkward to me as I'm pretty vague on all of this.

\start
Date: Sat, 7 May 2005 04:24:12 +0200
From: Gregory Vanuxem
To: Camm Maguire
Subject: RE: [Gcl-devel] Re: Dynamic Library Linking (arbitray float)
Cc: Mike Thomas

Hi,


> -----Message d'origine-----
> De : Camm Maguire [mailto:Camm Maguire]
> Envoye : samedi 7 mai 2005 00:42
> A : Vanuxem Gregory
> Cc : Mike Thomas; list; Gcl-Devel
> Objet : Re: [Gcl-devel] Re: Dynamic Library Linking (arbitray float)
>
>
> Greetings!
>
> Gregory Vanuxem writes:
>
> > Hi,
> >
> > Some correction about this incomprehensible e-mail.
> >
> > >
> > >
> > > Greetings!
> > >
> > > Gregory Vanuxem writes:
> > >
> > > > Serious question about GCL,
> >
> > One question about GCL and multiple-precision
> > floating-point computations.
> >
> > > > I've lost your mail about (arbitrary float),
> > > > But how do yo think peopole can implement arbitrary float in
> > > gcl; whith MPFR
> >
> > How do you think someone can implement arbitrary float (MPFR)
> > in gcl ?
> >
> > > > ?
> > > > With class or directly in num_arith... ?
> > > >
> > > > Camm... one Idea....?
> > > >
> > >
> > > For lack of a better idea, I was thinking of something along the lines
> > > of what clisp does -- have a system parameter which sets the 'big
> > > float' precision, and then define a 'big float' type with coercion
> > > rules identical to that between the existing short float and long
> > > float types.  This would all be in num_arith, just as the 'bignum'
> > > integers are now.
> >
> > With a new 'switch ... case' ?
> >
>
> Basically, yes.
>
> > >I was not envisioning any compiler support, thought
> > > this could be added at some point.  I.e. array's of bigfloats would be
> > > array's of objects, as opposed to array's of 16byte float numbers, for
> > > example.
> > >
> > > I don't see a reason to do this, however, unless there is a benefit to
> > > an existing application.  Axiom does its own bigfloat stuff already,
> > > as does maxima.  Now if we can demonstrate that performance
> gains along
> > > the lines of what you are seeing with the gcd stuff in gmp can be had,
> > > that is a good reason, and should motivate us to get this in quickly
> > > provided that axiom and/or maxima expresses their intention to use it.
> > > There is just so much to do, I don't want to work on stuff which won't
> > > be used, at least not right now.
> >
> > Just for information.
> >
> >
> > Here begins Post-Scriptum:
> >
> > >
> > > > Actually AXIOM doesn't compile with ANSI version ...
> >
> > Sometimes I think about multiple-precision floating-point
> > computations in GCL and connection with other CAS.
>
> OK.
>
> > CLOS require ANSI dialect isn't it?
>
> Rather ANSI requires CLOS, but what has this to do with mfpr?

A new multiple-precision floating-point class.


>
> >
> > >
> > > IMHO, a strength of GCL is that we support both CLtL1 and (work in
> > > progress) ANSI dialects to allow existing applications to decide if
> > > and when to migrate to ANSI.  maxima has migrated to ANSI, largely
> > > because they have a sizeable staff of lisp volunteers who are used to
> > > ANSI, which is a good reason.  ACL2 and AXIOM have not yet, as their
> > > lisp teams are familiar with and find what they need in CLtL1.  In my
> > > opinion, they should have the option of choosing if and when
> to migrate
> > > in the context of their other development considerations.
> > >
> > > If memory serves, plenty of lisp 'heavy-weights' don't use ansi
> > > features, e.g. CLOS, presumably because they don't want the overhead.
> > > If memory serves, Paul Graham said he's never used it, but double
> > > check that before relying upon it.
> > >
> >
> > Thanks for this information.
> >
> > > I'm missing the connection of this statement to the one above ...
> > >
> > > > I know that you work on tcl/tk, documentation and graphics ,
> > > >doesn't forget the concept of 'notebook'
> > > > (literate programming and other things...).
> > > >
> > >
> > > I'm afraid I don't follow.
> >
> > Translation:
> >
> > In some recent discussion, the notion of portable graphic library
> > has been evoked and its utilization with graphic and documentation.
> > I always think about a colossal work: notebook and
> > interaction with literate programming. The graphic library
> > has may be (for me) to be choosen such that:
> >
> > i)  works under different OS
> > ii) it is compliant with other projects
> >
> >
> > > > Generally I work on UNIX* (linux and BSD*) but actually
> > > ((numerical stuff to
> > > > implemenent: transcendental function for matrix (see Higham
> > > > (http://www.ma.man.ac.uk/~higham/ and gang) with linear algebra
> > > (atlas, blas
> > > > and lapack ...))
> > > > I' am on Windows(R) (thanks M.Thomas ...).
> >
> >
> > > > I think in AXIOM five things has to be seriously be
> enhanced (for future
> > > > library use...):
> >
> > My branch of AXIOM has to be enhanced in four directions.
> > Three types seem important (not for performance):
> > Integer, Real and Rational.
> >
>
> I don't understand what might be missing except for performance.
> Please explain if you have the time.

The set of integers is implemented in GCL.
The set of rationals is formally implemented i.e. Fraction over Integer.
The set of reals is computationally implemented i.e. floating point number.

These three types are frequently used and therefore
can be implemented in GCL.

This allow:

performance and memory (probably) enhancement
 (for example integer * real).
simpler interface if someone want to use some library.


Finally, these types are well known and the implementation
can be hidden.

>
> > > >
> > > > 1) 'Integer' in arbitrary integer:
> > > 		'GMP (realized)'
> > >
> > > Is this not already the case???
> > >
> > > > 2) 'Floating number' in arbitrary float (cf: Monagan, Michael
> > > (1990)):	'ADD
> > > > MPFR'
> > >
> > > Is this not already the case???  Or are we talking performance here?
> > >
> > > > 3) 'Fraction Integer' with gmp (GMP)
> > > 		'GMP (realized)'
> > > > 	(cf:
> > > >
> > >
> (http://page.axiom-developer.org/zope/mathaction/EnhancedFractionDomain),
> > > >       I will update and explain this when time permits.
> > >
> > > I agree presuming we can test exhaustively.  If there is interest in
> > > axiom for this, I'll move the rational arithmetic accelerations into
> > > soon to be released 2.6.7, otherwise it will wait for 2.7.0.
> >
> > This work is not destined to be included in axiom.
> >
>
> Why not?

Can be.


Cheers,

Greg

>
> > >
> > > > 4) C (or fortran) Dynamic library linkink in GCL. '...'
> Idea Maguire ?
> > >
> > > There is a recent thread on gcl-devel expressing my ideas on this.
> > > All we really need is a little enhancement to unexec to store dynamic
> > > relocation records in a dumped image.  Perhaps an unexecbfd might help
> > > here.
> > >
> > > But even now this is far more serviceable than it used to be.  See the
> > > example on linking in ddot from libblas recently posted to
> > > gcl-devel@gnu.org using compiler::link.
> >
> > Is there some specification about foreign language call in Common Lisp ?
> >
>
> Not in the standard.  Each implementation does its own.  GCL's is
> pretty flexible IMHO.
>
> > > > 5) Documentation about what I say.
> > > >
> > >
> > > Yes, please!
> >
> > >
> > > Take care,
> > >
> >
> > Cheers,
> >
>
> Take care,
>
> > Greg
> >
> >
> > > >
> > > > -----Message d'origine-----
> > > > De : gcl-devel-bounces+g.vanuxem=wanadoo.fr@gnu.org
> > > > [mailto:gcl-devel-bounces+g.vanuxem=wanadoo.fr@gnu.org]De la part de
> > > > Camm Maguire
> > > > Envoye : jeudi 5 mai 2005 21:02
> > > > A : Mike Thomas
> > > > Cc : gcl-devel@gnu.org
> > > > Objet : [Gcl-devel] Re: Dynamic Library Linking
> > > >
> > > >
> > > > Greetings!
> > > >
> > > > Mike Thomas writes:
> > > >
> > > > > Hi Camm.
> > > > >
> > > > > | This is indeed the short answer -- you can link in any new
> > > symbols you
> > > > > | want that are not present in the original image via
> compiler::link.
> > > > > | See the documentation for this function in
> gcl-si.{texi,info}.  What
> > > > > | this essentially does is build a new gcl image using a
> fresh call to
> > > > > | the system linker ld to modify the image symbol table
> with whatever
> > > > > | new code or libraries you specify.  It has the
> disadvantage that the
> > > > > | image is 'fresh' -- i.e. any work you may have done in
> the running
> > > > > | image before compiling compiler::link is lost.  Such work can be
> > > > > | respecified to run by hand in the fresh new image through one of
> > > > > | compiler::link's arguments, but this is a bit awkward to use.
> > > > > |7
> > > > > | What I'd like to do in 2.7.0 is to allow the user to link in new
> > > > > | dynamic libraries at runtime, modify the running image's
> > > symbol table,
> > > > > | and allow this work to be preserved across image saves via
> > > > > | si::save-system.  What this essentially means is that
> > > unexec needs to
> > > > > | add a little section to the end of the dumped image containing
> > > > > | relocation records for the new symbols for use by the
> > > system's dynamic
> > > > > | linker (ld.so on Linux), i.e. a GOT (Global Access Table).
> > > > >
> > > > > If I understand you correctly, on Windows one could store the
> > > name of the
> > > > > symbol and the name of the DLL from whence it came, then
> > > while resolving
> > > > > references at ru(i)ntime to call LoadLibrary() and
> > > GetProcAddress() for
> > > > each
> > > > > pair as shown here:
> > > > >
> > > > >
> > > >
> > >
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/
> > > > > base/using_run_time_dynamic_linking.asp
> > > > >
> > > > > I believe that PE-COFF executables actually have a section
> > > for external
> > > > > library references (ie references to DLL's) into which unexec
> > > might put
> > > > this
> > > > > kind of information so that the OS could automatically do
> the external
> > > > > relocation work at image load time (though probably only for those
> > > > > relocation records in the text sections I guess) .  This
> is all pretty
> > > > hairy
> > > > > though, especially as Windows moves towards 64 bits and
> > > whatever system
> > > > > changes might come with that.
> > > > >
> > > >
> > > > This is exactly the idea.  When we have time :-).
> > > >
> > > > Take care,
> > > >
> > > >
> > > > > | A kludgy way of doing this without any special executable format
> > > > > | knowledge might be to expand the explicit C plt table (mplt
> > > in plt.c)
> > > > > | with a bunch of dummy entries referring to unused symbols
> > > in external
> > > > > | shared libs, one of which we might provide for this
> purpose.  Then
> > > > > | when new symbols are needed, these symbols could be
> changed.  This
> > > > > | would still require us to be able to find the symbol in
> the image's
> > > > > | symbol table, but at least we would not have to add any new
> > > sections,
> > > > > | etc.  Of course this approach is rather awkward and limited too.
> > > > >
> > > > > It all sounds awkward to me as I'm pretty vague on all of this.

\start
Date: Mon, 09 May 2005 17:16:15 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#154 integrate does not produce asinh] (new) 

Why doesn't Axiom express antiderivatives in terms of hyperbolic
trig functions? For example:
\begin{axiom}
integrate(1/sqrt(1+x^2),x)
differentiate(%,x)
differential(asinh(x),x)
\end{axiom}

\start
Date: Mon, 09 May 2005 18:25:56 -0500
From: MathAction (billpage)
To: MathAction
Subject: [#155 failed coercion between Expression Fraction Integer and Expression Float in exponents] (new) 

This fails
\begin{axiom}
exp(-0.02*t)
% :: Expression Fraction Integer
% :: Expression Float
\end{axiom}

But this works
\begin{axiom}
exp(-1*(1/50)*t)
% :: Expression Float
\end{axiom}

Why are these expressions treated differently?

How can convert the first one to the second?

\start
Date: Thu, 12 May 2005 09:26:08 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#156 Axiom crashes when compiling simple Taylor code] (new) 

When trying this code (that is probably buggy on some level), axiom simply crashes on me without any comment. I'm using the Debian (Ubuntu) build of 20050201.

u := operator 'u;
multidiff(op, variable, count) == 
  if count > 0 then
    D(multidiff(op, variable, count-1), variable)
  else
    op
  
maketaylor(op) ==
  series( n +-> multidiff(op, x, n), x=0)

make_taylor(u(x))

\start
Date: Thu, 12 May 2005 09:59:07 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#156 Axiom crashes when compiling simple Taylor code] 

When trying this code (that is probably buggy on some level), axiom
simply crashes on me without any comment. I'm using the Debian
(Ubuntu) build of 20050201::

  u := operator 'u;
  multidiff(op, variable, count) == 
    if count > 0 then
      D(multidiff(op, variable, count-1), variable)
    else
      op
  
  maketaylor(op) ==
    series( n +-> multidiff(op, x, n), x=0)

  make_taylor(u(x))

Can't runn this one::

  !\begin{axiom}
  make_taylor(u(x))
  \end{axiom}

\start
Date: Thu, 12 May 2005 11:42:56 -0500
From: MathAction (Francois Maltey)
To: MathAction
Subject: [Axiom-mail] about axiom documentation

Hello, 

I install axiom on my linux-box : the 2005-02 distribution with plots.

So I'll try to see how to use the free software axiom in order to 
replace mupad.

In mupad there is a big lib.tar file with all librairies for mathmatical
computation in the mupad language.
I untar it and I can read and trace almost every program. 

I try to find the axiom librairy for mathematical computation, in 
axiom language, but I can't. 
I test a lot of /usr/[share]/axiom/???
I use a debian testing ditribution.

The first book I browse is the << 30 year horizon >> with 1142 pages.

Is it a good idea ?
Is there a french tutorial ?
My aim is to see if I can translate my exercices from maple/mupad to axiom ?
Is there an axiom for window ? (for my classrooom)

\start
Date: Fri, 13 May 2005 02:32:02 -0500
From: MathAction (Martin Rubey)
To: MathAction
Subject: [Axiom-mail] about axiom documentation

Dear Francois,

Francois Maltey writes:
 > Hello, 
 > 
 > I install axiom on my linux-box : the 2005-02 distribution with plots.

great!

 > So I'll try to see how to use the free software axiom in order to replace
 > mupad.
 > 
 > In mupad there is a big lib.tar file with all librairies for mathmatical
 > computation in the mupad language.
 > I untar it and I can read and trace almost every program. 

In axiom the corresponding directory is 

axiom/mnt/linux/src/algebra/

where you find all the .spad files, i.e., the source code.

In the long run, these will be documented using LaTeX, the corresponding dvi
files are in

axiom/mnt/linux/doc/src/algebra

 > The first book I browse is the << 30 year horizon >> with 1142 pages.
 > 
 > Is it a good idea ?

yes.

 > Is there a french tutorial ?

yes: see the link to 

http://www-rocq.inria.fr/codes/Daniel.Augot/axiom_intro.pdf

at

http://page.axiom-developer.org/zope/mathaction/AxiomDocumentation

 > My aim is to see if I can translate my exercices from maple/mupad to axiom ?

It would be very nice to hear of your experiences. Maybe you could even share
the sources?

 > Is there an axiom for window ? (for my classrooom)

\start
Date: Fri, 13 May 2005 05:43:01 -0500
From: MathAction (Frederic Lehobey)
To: MathAction
Subject: [Axiom-mail] about axiom documentation

Hi,

On Thu, May 12, 2005 at 06:15:49PM +0200, Francois Maltey wrote:

> I install axiom on my linux-box : the 2005-02 distribution with plots.
> 
> So I'll try to see how to use the free software axiom in order to 
> replace mupad.

> Is there a french tutorial ?
> My aim is to see if I can translate my exercices from maple/mupad to axiom ?
> Is there an axiom for window ? (for my classrooom)

  A very nice document has been produced in french by students Quentin
Carpent and Christophe Conil under the supervision of professor Eric
Bachard (all in 'Cc:' of this message).

  I saw it at LSM/RMLL 2004. Unfortunately, I have never found it
available on an Internet site.

\start
Date: Fri, 13 May 2005 08:22:21 -0500
From: MathAction (Christophe)
To: MathAction
Subject: [Axiom-mail] about axiom documentation

Bonjour,

Vous trouverez en pices jointes les diffrents manuels "tel quel" que
nous avons raliss avec Quentin Carpent, en version pdf. Si vous
dsirez rcuprer les version texmacs ( utilisable avec axiom ),
veuillez nous renvoyer un mail. A l'poque, la version d'axiom dont vous
parlez n'tait pas encore disponible, mais nous esprons que vous
trouverez quelques lments de rponse dans ces documents. Le document
ac20.pdf est un "manuel" gnral, comprenant une multitude d'exercices
raliss avec axiom et GNUplot. manuel1.pdf est un court rappel sur
l'utilisation de GNUplot, manuel2.pdf est un manuel en frnaais
expliquant l'utilisation d'axiom. Vous retrouverez nos sources dans
bibli.pdf.

Cordialement,

Christophe CONIL

On ven, 2005-05-13 at 12:07 +0200, Frederic Lehobey wrote:
> Hi,
> 
> On Thu, May 12, 2005 at 06:15:49PM +0200, Francois Maltey wrote:
> 
> > I install axiom on my linux-box : the 2005-02 distribution with plots.
> > 
> > So I'll try to see how to use the free software axiom in order to 
> > replace mupad.
> 
> > Is there a french tutorial ?
> > My aim is to see if I can translate my exercices from maple/mupad to axiom ?
> > Is there an axiom for window ? (for my classrooom)
> 
>   A very nice document has been produced in french by students Quentin
> Carpent and Christophe Conil under the supervision of professor Eric
> Bachard (all in 'Cc:' of this message).
> 
>   I saw it at LSM/RMLL 2004. Unfortunately, I have never found it
> available on an Internet site.
> 
> Best regards,

\start
Date: Fri, 13 May 2005 08:40:35 -0500
From: MathAction (Frederic Lehobey)
To: MathAction
Subject: [Axiom-mail] about axiom documentation

Hi,

  For non-french readers, Christophe's message included the (french)
document introducing to Axiom for classroom exercises I have mentioned
in my previous message. (Christophe says there is also a TeXmacs
version available on request to him by mail.)

  Thanks a lot Christophe both for your work and for sending it to
us.  Could you say a bit more about our rights to redistribute it?  Do
we have any?

On Fri, May 13, 2005 at 12:34:34PM +0200, Christophe wrote:
> Bonjour,
> 
> Vous trouverez en pices jointes les differents manuels "tel quel" que
> nous avons raliss avec Quentin Carpent, en version pdf. Si vous
> dsirez rcuprer les version texmacs ( utilisable avec axiom ),
> veuillez nous renvoyer un mail. A l'poque, la version d'axiom dont vous
> parlez n'tait pas encore disponible, mais nous esprons que vous
> trouverez quelques lments de rponse dans ces documents. Le document
> ac20.pdf est un "manuel" gnral, comprenant une multitude d'exercices
> raliss avec axiom et GNUplot. manuel1.pdf est un court rappel sur
> l'utilisation de GNUplot, manuel2.pdf est un manuel en frnaais
> expliquant l'utilisation d'axiom. Vous retrouverez nos sources dans
> bibli.pdf.
> 
> 
> On ven, 2005-05-13 at 12:07 +0200, Frederic Lehobey wrote:
> > Hi,
> > 
> > On Thu, May 12, 2005 at 06:15:49PM +0200, Francois Maltey wrote:
> > 
> > > I install axiom on my linux-box : the 2005-02 distribution with plots.
> > > 
> > > So I'll try to see how to use the free software axiom in order to 
> > > replace mupad.
> > 
> > > Is there a french tutorial ?
> > > My aim is to see if I can translate my exercices from maple/mupad to axiom ?
> > > Is there an axiom for window ? (for my classrooom)
> > 
> >   A very nice document has been produced in french by students Quentin
> > Carpent and Christophe Conil under the supervision of professor Eric
> > Bachard (all in 'Cc:' of this message).
> > 
> >   I saw it at LSM/RMLL 2004. Unfortunately, I have never found it
> > available on an Internet site.
> > 

\start
Date: Fri, 13 May 2005 09:38:39 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom-mail] 

----- Warning: Translated via Google Language Tools -----

Hello,

You will find in enclosures the various handbooks
"just as it is" which we carried out with Quentin Carpent,
in version pdf.  If you wish to recover the version texmacs
(usable with axiom), want to return us a mall.  At the time,
the version of axiom about which you speak was not yet available,
but we hope that you will find some brief replies in these
documents.  The document ac20.pdf is a general "handbook",
including/understanding a multitude of exercises carried out
with axiom and GNUplot. manuel1.pdf is a short recall on the
use of GNUplot, manuel2.pdf is a handbook frnaais some explaining
the use of axiom.  You will find our sources in bibli.pdf.

Cordially,
Christophe CONIL

\start
Date: Fri, 13 May 2005 10:24:18 -0500
From: MathAction (Mark Stephen)
To: MathAction
Subject: [Axiom-mail] April 2005 source

I recently downloaded and compiled the April 2005 sources; color me 
gob-smacked.

I haven't had a usable version of Axiom since I switched from RH9 to 
Fedora some years ago. The improvement is amazing - far more extensive 
documentation, really nice graphics, excellent on-line help, and, most 
importantly, the program seems to be pretty bullet-proof. Some minor 
problems still with the TeXmacs interface (Graphics, probably the known 
axiom/AXIOMsys bug. I think I just need to modify and recompile 
axiom_tm.c, haven't got around to it yet), and bad input can put the 
interpreter into a mode which requires an extra carriage return after 
each line - I don't understand this at all, but I can live with it.

I'm the guy who who was whining about Axiom's response to cos(2) a few 
months ago. My current attitude is -- Yeaaah! Way to go, guys!

Mark Stephen

\start
Date: Fri, 13 May 2005 12:26:39 -0500
From: MathAction (Christophe)
To: MathAction
Subject: [Axiom-mail] about axiom documentation

Hi, 

Sorry for writing my previous mail in French, i will try to write my
next mails in English. The docs will be under CC BY-SA license. You have
rights to use, modify, improve and redistribute them as long as we have
credits for it.

Best regards,

Christophe

On ven, 2005-05-13 at 15:34 +0200, Frederic Lehobey wrote:
> Hi,
> 
>   For non-french readers, Christophe's message included the (french)
> document introducing to Axiom for classroom exercises I have mentioned
> in my previous message. (Christophe says there is also a TeXmacs
> version available on request to him by mail.)
> 
>   Thanks a lot Christophe both for your work and for sending it to
> us.  Could you say a bit more about our rights to redistribute it?  Do
> we have any?
> 
> > 
> > On ven, 2005-05-13 at 12:07 +0200, Frederic Lehobey wrote:
> > > Hi,
> > > 
> > > On Thu, May 12, 2005 at 06:15:49PM +0200, Francois Maltey wrote:
> > > 
> > > > I install axiom on my linux-box : the 2005-02 distribution with plots.
> > > > 
> > > > So I'll try to see how to use the free software axiom in order to 
> > > > replace mupad.
> > > 
> > > > Is there a french tutorial ?
> > > > My aim is to see if I can translate my exercices from maple/mupad to axiom ?
> > > > Is there an axiom for window ? (for my classrooom)
> > > 
> > >   A very nice document has been produced in french by students Quentin
> > > Carpent and Christophe Conil under the supervision of professor Eric
> > > Bachard (all in 'Cc:' of this message).
> > > 
> > >   I saw it at LSM/RMLL 2004. Unfortunately, I have never found it
> > > available on an Internet site.
> > > 

\start
Date: Fri, 13 May 2005 12:58:51 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom-mail] about axiom documentation

Christophe,

On May 13, 2005 1:19 PM you wrote:

> Sorry for writing my previous mail in French,
> i will try to write my next mails in English.

I think you should feel free to write in the language you
prefer. Sometimes this might be influenced by your intended
audience but readers who are serious can easily make use of
free online translation services which in my opinion are
now quite good.

I notice however that some of our systems still have problems
dealing with accented characters :( The web site displays
them properly but the email notification seems to mangle them.
I will look into this problem a little more.

> The docs will be under CC BY-SA license. You have rights
> to use, modify, improve and redistribute them as long as
> we have credits for it.

Great! Thank you for this work. I will upload the files to
the MathAction web site and make the appropriate links so
that they will be more easily accessible.

\start
Date: Fri, 13 May 2005 16:40:33 -0500
From: Tim Daly
To: Christophe Conil
Subject: about axiom documentation

Christophe,

Thanks for the info on the french documentation. Can you 
give me a URL for the docs?

I don't know what an "CC BY-SA" license means. Is it possible to 
integrate a copy of the documentation with the Axiom build? 
Axiom is license under the Modified BSD which means that people
are pretty much free to do what they please with the source. 

I'm interested in making Axiom more international ( though even
the little paragraph you wrote strained my french language skills )
I've ported Axiom to Red Flag Linux for China and, though it works 
I can't read the menus.

I'd like to get more involved with the French community anyway.
I plan to give 2 talks at the LSM conference in July. One of the
topics of interest will be trying to get a local base of support 
for the French community.

There was a discussion a couple years ago within INRIA about 
creating a computer algebra system from scratch. At the time I
raised the point that I was going to get the Axiom source code
as open source and that, while it would take a while to rewrite
(2.5 years it turned out), it made more sense to start from a
large set of working algorithms than trying to build them. Axiom
has 30 years of work and it is unlikely that there will be funding
for a new project of the same size.

\start
Date: Fri, 13 May 2005 16:41:52 -0500
From: Tim Daly
To: list
Subject: quiet time

*,

I've been rather quiet on this list for the last couple weeks
due to a high workload. I'm in the process of switching jobs
and it has taken up a large amount of my time and attention.
My apologies.

\start
Date: Sat, 14 May 2005 12:18:40 +0200
From: Christophe Conil
To: Tim Daly
Subject: Re: about axiom documentation
Cc: Francois Maltey, Frederic Lehobey, Quentin Carpent, Eric Bachard

Tim, 


> Thanks for the info on the french documentation. Can you 
> give me a URL for the docs?

I just created a small page with all docs and infos about our work. You
can find them under:

http://la.riverotte.free.fr/axiom/


> I'm interested in making Axiom more international ( though even
> the little paragraph you wrote strained my french language skills )
> I've ported Axiom to Red Flag Linux for China and, though it works 
> I can't read the menus.
> 
> I'd like to get more involved with the French community anyway.
> I plan to give 2 talks at the LSM conference in July. One of the
> topics of interest will be trying to get a local base of support 
> for the French community.

I forward you message to all french people i know, who are interested in
axiom. Hope it can helps! If you need any help for translating, i would
be happy to help you, and even my writing of English isn't perfect, i
think i can easily read English and write French.

> I don't know what an "CC BY-SA" license means. Is it possible to 
> integrate a copy of the documentation with the Axiom build? 
> Axiom is license under the Modified BSD which means that people
> are pretty much free to do what they please with the source. 

Yes, you can (of course!) integrate a copy with the axiom build :) I put
some references to the CC BY-SA license on the page too.

Best regards,

Christophe

\start
Date: Sat, 14 May 2005 05:37:43 -0500
From: MathAction (Christophe)
To: MathAction
Subject: [Axiom-mail] Re: about axiom documentation

Tim, 


> Thanks for the info on the french documentation. Can you 
> give me a URL for the docs?

I just created a small page with all docs and infos about our work. You
can find them under:

http://la.riverotte.free.fr/axiom/


> I'm interested in making Axiom more international ( though even
> the little paragraph you wrote strained my french language skills )
> I've ported Axiom to Red Flag Linux for China and, though it works 
> I can't read the menus.
> 
> I'd like to get more involved with the French community anyway.
> I plan to give 2 talks at the LSM conference in July. One of the
> topics of interest will be trying to get a local base of support 
> for the French community.

I forward you message to all french people i know, who are interested in
axiom. Hope it can helps! If you need any help for translating, i would
be happy to help you, and even my writing of English isn't perfect, i
think i can easily read English and write French.

> I don't know what an "CC BY-SA" license means. Is it possible to 
> integrate a copy of the documentation with the Axiom build? 
> Axiom is license under the Modified BSD which means that people
> are pretty much free to do what they please with the source. 

Yes, you can (of course!) integrate a copy with the axiom build :) I put
some references to the CC BY-SA license on the page too.

Best regards,

Christophe

\start
Date: Sat, 14 May 2005 14:27:14 -0500
From: Tim Daly
To: support@dessci.com
Subject: Your products and Axiom

Gentlemen,

I'm Tim Daly, the lead developer on Axiom. Axiom is a general purpose
computer algebra system similar to Mathematica and Maple. Up until a
few years ago it was a commercial competitor but was withdrawn from
the market and released as open source. The website
http://page.axiom-developer.org has additional information.

A google search lead me to your reference page
(http://www.dessci.com/en/reference). You mention some NSF grants
that involve making math more accessible.

Perhaps a joint effort between your company, our wiki site mentioned
above, and the axiom developers can be useful in achieving this goal.

Please let me know if you have any interest in connecting your math
front-end tools to Axiom.

Tim Daly
Axiom Lead Developer

\start
Date: Sat, 14 May 2005 15:29:52 -0500
From: MathAction (Francois Maltey)
To: MathAction
Subject: [Axiom-mail] axiom and emacs ?

Hello !

Thanks for all your advices about axiom-documentation !

Is there a emacs mode for axiom ?

What is the easiest way to use axiom for little functions :
make an input file in emacs ? or use the other sytax ?
Is it a silly idea to exchange data between emacs and axiom only with
)read command ? 

I'm not very sure to use the beautiful texmacs because 
I use emacs for everything I do.

The mupad mode for emacs use specials caracters in order to know if 
mupad run or wait a command ? how do axiom in texmacs ?
can I do the same with emacs ?

Thanks a lot for your reponses.

Francois Maltey

\start
Date: Sun, 15 May 2005 10:50:31 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom Documentation] 

??changed:
- There is a good introduction to Axiom by Martin N. Dunstan (in English) at
-http://www.dcs.st-and.ac.uk/~mnd/documentation/axiom_tutorial . An even more
-complete introduction by Daniel Augot (in French) is available at
-http://www-rocq.inria.fr/codes/Daniel.Augot/axiom_intro.pdf .
-  
  There is a good introduction to Axiom in English by Martin N. Dunstan
at http://www.dcs.st-and.ac.uk/~mnd/documentation/axiom_tutorial.

  In French, a complete introduction to Axiom by Daniel Augot is
available at http://www-rocq.inria.fr/codes/Daniel.Augot/axiom_intro.pdf

  And an Axiom tutorial and a collection of exercises by Christophe Conil
and Quentin Carpent at http://la.riverotte.free.fr/axiom.

\start
Date: Sun, 15 May 2005 12:01:26 -0400
From: Bill Page
To: Christophe Conil
Subject: re: about axiom documentation
Cc: Francois Maltey, Frederic Lehobey, Quentin Carpent, Eric Bachard

Christophe,

On May 14, 2005 6:19 AM you wrote:

> Tim asked:
> > Thanks for the info on the french documentation. Can you
> > give me a URL for the docs?
>
> I just created a small page with all docs and infos about our work.
> You can find them under:

http://la.riverotte.free.fr/axiom

Thank you very much for preparing this webpage!

> Tim wrote:
>> I'm interested in making Axiom more international ...

I also think in would be great to have more Axiom material
that would be easily accessible to non-English readers on
the MathAction/Axiom web site. I would be very pleased if
you or your colleagues were interested in helping to develop
and maintaining some French language web pages on MathAction.
Since MathAction is a wiki, these pages can be created and
updated directly by you through your browser.

If you (or anyone else reading this list) would like some
help getting started, please let me know.

Regards,
Bill Page.

PS. I added a link to your new web page here:

http://page.axiom-developer.org/zope/mathaction/AxiomDocumentation





\start
Date: Mon, 16 May 2005 11:13:02 -0400
From: Tim Daly
To: list
Subject: [sw-office@wolfram.com: 2005 Wolfram Technology Conference]

Last year we held our first-ever Wolfram Technology Conference,
covering the complete spectrum of applications of Mathematica
and our other technologies.

I'm happy to say that the conference was a great success. Many
attendees told us how much they got out of it, and encouraged us
to let everyone know well in advance about the next conference.

So I'm writing today to tell you that registration is now open
for the 2005 Wolfram Technology Conference, to be held October
6-8 at our company headquarters in Illinois. You can sign up at
the conference website:
http://www.wolfram.com/techconf2005

Almost all of our senior R&D staff from around the world will be
participating in this year's Technology Conference--so this is a
perfect opportunity to learn first-hand about Mathematica from
the people who build it, give your compliments or complaints,
and lobby for new features!

The Technology Conference will be an intense 3-day event, packed
with sessions from early morning to late evening. There will be
multiple tracks, with something for everyone--from novice users
to 17-year power veterans.

At last year's event it was great to see so many people learning
so much so quickly. "I had no idea Mathematica could do *that*"
was something I overheard many times at the conference--not only
from attendees but also our own staff!

It seemed like everyone had a very good time at the Technology
Conference. Laptops were swinging. Everyone was interacting.
Semiconductor designers could be seen in rapt conversation with
math educators, financial engineers with geologists, energetic
students with senior managers.

There's a lot of excitement around Mathematica right now--and I
think some of the things we'll be announcing in the next few
months will add even more.

We're going to have a terrific Technology Conference this
year--and I hope you'll be able to join us.

- --Stephen Wolfram


\start
Date: Mon, 16 May 2005 11:36:17 -0400
From: Barry Trager
To: Tim Daly
Subject: fix for occasional failure in pgcd.spad

I have discovered and fixed a bug in pgcd.spad which occasionally 
(depending on choices of random substitutions)
could return the wrong gcd. The fix is simply to comment out one line in 
gcdPrimitive which was causing the
division tests to be skipped.
I attach a fixed version of pgcd.spad

--=_mixed 0055B7F3C1257003_=

LS1Db3B5cmlnaHQgVGhlIE51bWVyaWNhbCBBbGdvcml0aG1zIEdyb3VwIExpbWl0ZWQgMTk5MS4K
IAopYWJiIHBhY2thZ2UgUEdDRCBQb2x5bm9taWFsR2NkUGFja2FnZQogCkkgICAgICAgID09PiBJ
bnRlZ2VyCk5OSSAgICAgID09PiBOb25OZWdhdGl2ZUludGVnZXIKUEkgICAgICAgPT0+IFBvc2l0
aXZlSW50ZWdlcgogCi0tJSBQb2x5bm9taWFsR2NkUGFja2FnZQogCisrIEF1dGhvcjogTWljaGFl
bCBMdWNrcywgUC4gR2lhbm5pCisrIERhdGUgQ3JlYXRlZDoKKysgRGF0ZSBMYXN0IFVwZGF0ZWQ6
IDE3IEp1bmUgMTk5NgorKyBGaXggSGlzdG9yeTogTW92ZWQgdW5pdENhbm9uaWNhbHMgZm9yIHBl
cmZvcm1hbmNlIChCTVQpOworKyAgICAgICAgICAgICAgRml4ZWQgYSBwcm9ibGVtIHdpdGggZ2Nk
KHgsMCkgKEZyZWRlcmljIExlaG9iZXkpCisrIEJhc2ljIEZ1bmN0aW9uczogZ2NkLCBjb250ZW50
CisrIFJlbGF0ZWQgQ29uc3RydWN0b3JzOiBQb2x5bm9taWFsCisrIEFsc28gU2VlOgorKyBBTVMg
Q2xhc3NpZmljYXRpb25zOgorKyBLZXl3b3JkczoKKysgUmVmZXJlbmNlczoKKysgRGVzY3JpcHRp
b246CisrICAgVGhpcyBwYWNrYWdlIGNvbXB1dGVzIG11bHRpdmFyaWF0ZSBwb2x5bm9taWFsIGdj
ZCdzIHVzaW5nCisrIGEgaGVuc2VsIGxpZnRpbmcgc3RyYXRlZ3kuIFRoZSBjb250cmFpbnQgb24g
dGhlIGNvZWZmaWNpZW50CisrIGRvbWFpbiBpcyBpbXBvc2VkIGJ5IHRoZSBsaWZ0aW5nIHN0cmF0
ZWd5LiBJdCBpcyBhc3N1bWVkIHRoYXQKKysgdGhlIGNvZWZmaWNpZW50IGRvbWFpbiBoYXMgdGhl
IHByb3BlcnR5IHRoYXQgYWxtb3N0IGFsbCBzcGVjaWFsaXphdGlvbnMKKysgcHJlc2VydmUgdGhl
IGRlZ3JlZSBvZiB0aGUgZ2NkLgogClBvbHlub21pYWxHY2RQYWNrYWdlKEUsT1YsUixQKTpDID09
IFQgd2hlcmUKICAgIFIgICAgIDogIEV1Y2xpZGVhbkRvbWFpbgogICAgUCAgICAgOiAgUG9seW5v
bWlhbENhdGVnb3J5KFIsRSxPVikKICAgIE9WICAgIDogIE9yZGVyZWRTZXQKICAgIEUgICAgIDog
IE9yZGVyZWRBYmVsaWFuTW9ub2lkU3VwCiAKICAgIFNVUFAgICAgICA9PT4gU3BhcnNlVW5pdmFy
aWF0ZVBvbHlub21pYWwgUAogCiAgICBDID09IHdpdGgKICAgICAgZ2NkICAgICAgICAgICAgICAg
OiAgIChQLFApICAgIC0+IFAKICAgICAgICArKyBnY2QocCxxKSBjb21wdXRlcyB0aGUgZ2NkIG9m
IHRoZSB0d28gcG9seW5vbWlhbHMgcCBhbmQgcS4KICAgICAgZ2NkICAgICAgICAgICAgICAgOiAg
IExpc3QgUCAgIC0+IFAKICAgICAgICArKyBnY2QobHApIGNvbXB1dGVzIHRoZSBnY2Qgb2YgdGhl
IGxpc3Qgb2YgcG9seW5vbWlhbHMgbHAuCiAgICAgIGdjZCAgICAgICAgICAgICAgIDogICAoU1VQ
UCxTVVBQKSAgICAtPiBTVVBQCiAgICAgICAgKysgZ2NkKHAscSkgY29tcHV0ZXMgdGhlIGdjZCBv
ZiB0aGUgdHdvIHBvbHlub21pYWxzIHAgYW5kIHEuCiAgICAgIGdjZCAgICAgICAgICAgICAgIDog
ICBMaXN0IFNVUFAgICAtPiBTVVBQCiAgICAgICAgKysgZ2NkKGxwKSBjb21wdXRlcyB0aGUgZ2Nk
IG9mIHRoZSBsaXN0IG9mIHBvbHlub21pYWxzIGxwLgogICAgICBnY2RQcmltaXRpdmUgICAgICA6
ICAgKFAsUCkgICAgLT4gUAogICAgICAgICsrIGdjZFByaW1pdGl2ZShwLHEpIGNvbXB1dGVzIHRo
ZSBnY2Qgb2YgdGhlIHByaW1pdGl2ZSBwb2x5bm9taWFscwogICAgICAgICsrIHAgYW5kIHEuCiAg
ICAgIGdjZFByaW1pdGl2ZSAgICAgIDogICAoU1VQUCxTVVBQKSAgICAtPiBTVVBQCiAgICAgICAg
KysgZ2NkUHJpbWl0aXZlKHAscSkgY29tcHV0ZXMgdGhlIGdjZCBvZiB0aGUgcHJpbWl0aXZlIHBv
bHlub21pYWxzCiAgICAgICAgKysgcCBhbmQgcS4KICAgICAgZ2NkUHJpbWl0aXZlICAgICAgOiAg
IExpc3QgUCAgIC0+IFAKICAgICAgICArKyBnY2RQcmltaXRpdmUgbHAgY29tcHV0ZXMgdGhlIGdj
ZCBvZiB0aGUgbGlzdCBvZiBwcmltaXRpdmUKICAgICAgICArKyBwb2x5bm9taWFscyBscC4KCiAg
ICBUID09IGFkZAogCiAgICAgIFNVUCAgICAgID09PiBTcGFyc2VVbml2YXJpYXRlUG9seW5vbWlh
bCBSCiAKICAgICAgTEdjZCAgICAgPT0+IFJlY29yZChsb2NnY2Q6U1VQUCxnb29kaW50Okxpc3Qg
TGlzdCBSKQogICAgICBVVGVybSAgICA9PT4gUmVjb3JkKGxwb2w6TGlzdCBTVVAsbGludDpMaXN0
IExpc3QgUixtcG9sOlNVUFApCiAgICAgIHBtb2Q6UiAgIDo9ICAocHJldlByaW1lKDIqKjI2KSRJ
bnRlZ2VyUHJpbWVzUGFja2FnZShJbnRlZ2VyKSk6OlIKIAogICAgICBpbXBvcnQgTXVsdGl2YXJp
YXRlTGlmdGluZyhFLE9WLFIsUCkKICAgICAgaW1wb3J0IEZhY3RvcmluZ1V0aWxpdGllcyhFLE9W
LFIsUCkKIAogICAgICAgICAgICAgICAgIC0tLS0tLS0tICBMb2NhbCAgRnVuY3Rpb25zICAtLS0t
LS0tLQogCiAgICAgIG15cmFuICAgICAgICAgICA6ICAgIEludGVnZXIgICAtPiBVbmlvbihSLCJm
YWlsZWQiKQogICAgICBiZXR0ZXIgICAgICAgICAgOiAgICAoUCxQKSAgICAgLT4gQm9vbGVhbgog
ICAgICBmYWlsdGVzdCAgICAgICAgOiAgIChTVVBQLFNVUFAsU1VQUCkgICAgLT4gQm9vbGVhbgog
ICAgICBtb25vbUNvbnRlbnQgICAgOiAgIChTVVBQKSAgIC0+IFNVUFAKICAgICAgZ2NkTW9ub20g
ICAgICAgIDogIChTVVBQLFNVUFApICAgIC0+IFNVUFAKICAgICAgZ2NkVGVybUxpc3QgICAgIDog
ICAgKFAsUCkgICAgIC0+IFAKICAgICAgZ29vZCAgICAgICAgICAgIDogIChTVVBQLExpc3QgT1Ys
TGlzdCBMaXN0IFIpIC0+IFJlY29yZCh1cG9sOlNVUCxpbnZhbDpMaXN0IExpc3QgUikKIAogICAg
ICBjaG9vc2VWYWwgICAgICAgOiAgKFNVUFAsU1VQUCxMaXN0IE9WLExpc3QgTGlzdCBSKSAtPiBV
bmlvbihVVGVybSwiZmFpbGVkIikKICAgICAgbG9jYWxnY2QgICAgICAgIDogIChTVVBQLFNVUFAs
TGlzdCBPVixMaXN0IExpc3QgUikgLT4gTEdjZAogICAgICBub3RDb3ByaW1lICAgICAgOiAgKFNV
UFAsU1VQUCwgTGlzdCBOTkksTGlzdCBPVixMaXN0IExpc3QgUikgICAtPiBTVVBQCiAgICAgIGlt
cG9zZWxjICAgICAgICA6IChMaXN0IFNVUCxMaXN0IE9WLExpc3QgUixMaXN0IFApIC0+IExpc3Qg
U1VQCiAKICAgICAgbGlmdD8gOihTVVBQLFNVUFAsVVRlcm0sTGlzdCBOTkksTGlzdCBPVikgLT4g
VW5pb24oczpTVVBQLGZhaWxlZDoiZmFpbGVkIixub3RDb3ByaW1lOiJub3RDb3ByaW1lIikKICAg
ICAgbGlmdCAgOihTVVBQLFNVUCxTVVAsUCxMaXN0IE9WLExpc3QgTk5JLExpc3QgUikgLT4gVW5p
b24oU1VQUCwiZmFpbGVkIikKIAogICAgICAgICAgICAgICAgICAgICAtLS0tIExvY2FsICBmdW5j
dGlvbnMgLS0tLQogICAgLS0gdGVzdCBpZiBzb21ldGhpbmcgd3JvbmcgaGFwcGVuZWQgaW4gdGhl
IGdjZAogICAgICBmYWlsdGVzdChmOlNVUFAscDE6U1VQUCxwMjpTVVBQKSA6IEJvb2xlYW4gPT0K
ICAgICAgICAocDEgZXhxdW8gZikgY2FzZSAiZmFpbGVkIiBvciAocDIgZXhxdW8gZikgY2FzZSAi
ZmFpbGVkIgogCiAgICAtLSBDaG9vc2UgdGhlIGludGVnZXJzCiAgICAgIGNob29zZVZhbChwMTpT
VVBQLHAyOlNVUFAsbHZyOkxpc3QgT1YsbHRyeTpMaXN0IExpc3QgUik6VW5pb24oVVRlcm0sImZh
aWxlZCIpID09CiAgICAgICAgZDE6PWRlZ3JlZShwMSkKICAgICAgICBkMjo9ZGVncmVlKHAyKQog
ICAgICAgIGRkOk5OSTo9MCROTkkKICAgICAgICBudnI6Tk5JOj0jbHZyCiAgICAgICAgbHZhbDpM
aXN0IFIgOj1bXQogICAgICAgIHJhbmdlOkk6PTgKICAgICAgICByZXBlYXQKICAgICAgICAgIHJh
bmdlOj0yKnJhbmdlCiAgICAgICAgICBsdmFsOj1bcmFuKHJhbmdlKSBmb3IgaSBpbiAxLi5udnJd
CiAgICAgICAgICBtZW1iZXI/KGx2YWwsbHRyeSkgPT4gIm5ldyBwb2ludCIKICAgICAgICAgIGx0
cnk6PWNvbnMobHZhbCxsdHJ5KQogICAgICAgICAgdWYxOlNVUDo9Y29tcGxldGVFdmFsKHAxLGx2
cixsdmFsKQogICAgICAgICAgZGVncmVlIHVmMSBePSBkMSA9PiAibmV3IHBvaW50IgogICAgICAg
ICAgdWYyOlNVUDo9IGNvbXBsZXRlRXZhbChwMixsdnIsbHZhbCkKICAgICAgICAgIGRlZ3JlZSB1
ZjIgXj0gZDIgPT4gIm5ldyBwb2ludCIKICAgICAgICAgIHU6PWdjZCh1ZjEsdWYyKQogICAgICAg
ICAgZHU6PWRlZ3JlZSB1CiAgICAgICAgIC0tdGhlIHVuaXZhcmlhdGUgZ2NkIGlzIDEKICAgICAg
ICAgIGlmIGR1PTAgdGhlbiByZXR1cm4gW1sxJFNVUF0sbHRyeSwwJFNVUFBdJFVUZXJtCiAKICAg
ICAgICAgIHVnY2Q6TGlzdCBTVVA6PVt1LCh1ZjEgZXhxdW8gdSk6OlNVUCwodWYyIGV4cXVvIHUp
OjpTVVBdCiAgICAgICAgICB1dGVybTo9W3VnY2QsbHRyeSwwJFNVUFBdJFVUZXJtCiAgICAgICAg
ICBkZD0wID0+IGRkOj1kdQogCiAgICAgICAgLS10aGUgZGVncmVlIGlzIG5vdCBjaGFuZ2VkCiAg
ICAgICAgICBkdT1kZCA9PgogCiAgICAgICAgICAgLS10ZXN0IGlmIG9uZSBvZiB0aGUgcG9seW5v
bWlhbHMgaXMgdGhlIGdjZAogICAgICAgICAgICBkZD1kMSA9PgogICAgICAgICAgICAgIGlmIF4o
KGY6PXAyIGV4cXVvIHAxKSBjYXNlICJmYWlsZWQiKSB0aGVuCiAgICAgICAgICAgICAgICByZXR1
cm4gW1t1XSxsdHJ5LHAxXSRVVGVybQogICAgICAgICAgICAgIGlmIGRkXj1kMiB0aGVuIGRkOj0o
ZGQtMSk6Ok5OSQogCiAgICAgICAgICAgIGRkPWQyID0+CiAgICAgICAgICAgICAgaWYgXigoZjo9
cDEgZXhxdW8gcDIpIGNhc2UgImZhaWxlZCIpIHRoZW4KICAgICAgICAgICAgICAgIHJldHVybiBb
W3VdLGx0cnkscDJdJFVUZXJtCiAgICAgICAgICAgICAgZGQ6PShkZC0xKTo6Tk5JCiAgICAgICAg
ICAgIHJldHVybiB1dGVybQogCiAgICAgICAgIC0tdGhlIG5ldyBnY2QgaGFzIGRlZ3JlZSBsZXNz
CiAgICAgICAgICBkdTxkZCA9PiBkZDo9ZHUKIAogICAgICBnb29kKGY6U1VQUCxsdnI6TGlzdCBP
VixsdHJ5Okxpc3QgTGlzdCBSKTpSZWNvcmQodXBvbDpTVVAsaW52YWw6TGlzdCBMaXN0IFIpID09
CiAgICAgICAgbnZyOk5OSTo9I2x2cgogICAgICAgIHJhbmdlOkk6PTEKICAgICAgICB3aGlsZSB0
cnVlIHJlcGVhdAogICAgICAgICAgcmFuZ2U6PTIqcmFuZ2UKICAgICAgICAgIGx2YWw6PVtyYW4o
cmFuZ2UpIGZvciBpIGluIDEuLm52cl0KICAgICAgICAgIG1lbWJlcj8obHZhbCxsdHJ5KSA9PiAi
bmV3IHBvaW50IgogICAgICAgICAgbHRyeTo9Y29ucyhsdmFsLGx0cnkpCiAgICAgICAgICB1Zjo9
Y29tcGxldGVFdmFsKGYsbHZyLGx2YWwpCiAgICAgICAgICBpZiBkZWdyZWUgZ2NkKHVmLGRpZmZl
cmVudGlhdGUgdWYpPTAgdGhlbiByZXR1cm4gW3VmLGx0cnldCiAKICAgICAgLS0gaW1wb3NlIHRo
ZSByaWdodCBsYwogICAgICBpbXBvc2VsYyhsaXBvbDpMaXN0IFNVUCwKICAgICAgICAgICAgICAg
bHZhcjpMaXN0IE9WLGx2YWw6TGlzdCBSLGxlYWRjOkxpc3QgUCk6TGlzdCBTVVAgPT0KICAgICAg
ICByZXN1bHQ6TGlzdCBTVVAgOj1bXQogICAgICAgIGZvciBwb2wgaW4gbGlwb2wgZm9yIGxlYWRw
b2wgaW4gbGVhZGMgcmVwZWF0CiAgICAgICAgICAgcDE6PSB1bml2YXJpYXRlIGV2YWwobGVhZHBv
bCxsdmFyLGx2YWwpICogcG9sCiAgICAgICAgICAgcmVzdWx0Oj0gY29ucygocDEgZXhxdW8gbGVh
ZGluZ0NvZWZmaWNpZW50IHBvbCk6OlNVUCxyZXN1bHQpCiAgICAgICAgcmV2ZXJzZSByZXN1bHQK
IAogICAgLS1Db21wdXRlIHRoZSBnY2QgYmV0d2VlbiBub3QgY29wcmltZSBwb2x5bm9taWFscwog
ICAgICBub3RDb3ByaW1lKGc6U1VQUCxwMjpTVVBQLGxkZWc6TGlzdCBOTkksbHZhcjE6TGlzdCBP
VixsdHJ5Okxpc3QgTGlzdCBSKSA6IFNVUFAgPT0KICAgICAgICBnMTo9Z2NkKGcsZGlmZmVyZW50
aWF0ZSBnKQogICAgICAgIGwxIDo9IChnIGV4cXVvIGcxKTo6U1VQUAogICAgICAgIGxnOkxHY2Q6
PWxvY2FsZ2NkKGwxLHAyLGx2YXIxLGx0cnkpCiAgICAgICAgKGwsbHRyeSk6PShsZy5sb2NnY2Qs
bGcuZ29vZGludCkKICAgICAgICBsdmFsOj1sdHJ5LmZpcnN0CiAgICAgICAgcDJsOj0ocDIgZXhx
dW8gbCk6OlNVUFAKICAgICAgICAoZ2QxLGdkMik6PShsLGwpCiAgICAgICAgdWw6PWNvbXBsZXRl
RXZhbChsLGx2YXIxLGx2YWwpCiAgICAgICAgZGw6PWRlZ3JlZSB1bAogICAgICAgIGlmIGRlZ3Jl
ZSBnY2QodWwsZGlmZmVyZW50aWF0ZSB1bCkgXj0wIHRoZW4KICAgICAgICAgIG5ld2Nob2ljZTo9
Z29vZChsLGx2YXIxLGx0cnkpCiAgICAgICAgICB1bDo9bmV3Y2hvaWNlLnVwb2wKICAgICAgICAg
IGx0cnk6PW5ld2Nob2ljZS5pbnZhbAogICAgICAgICAgbHZhbDo9bHRyeS5maXJzdAogICAgICAg
IHVnMTo9Y29tcGxldGVFdmFsKGcxLGx2YXIxLGx2YWwpCiAgICAgICAgdWxpc3Q6PVt1ZzEsY29t
cGxldGVFdmFsKHAybCxsdmFyMSxsdmFsKV0KICAgICAgICBsY3BvbDpMaXN0IFA6PVtsZWFkaW5n
Q29lZmZpY2llbnQgZzEsIGxlYWRpbmdDb2VmZmljaWVudCBwMl0KICAgICAgICB3aGlsZSB0cnVl
IHJlcGVhdAogICAgICAgICAgZDpTVVA6PWdjZChjb25zKHVsLHVsaXN0KSkKICAgICAgICAgIGlm
IGRlZ3JlZSBkID0wIHRoZW4gcmV0dXJuIGdkMQogICAgICAgICAgbHF1bzo9KHVsIGV4cXVvIGQp
OjpTVVAKICAgICAgICAgIGlmIGRlZ3JlZSBscXVvIF49MCB0aGVuCiAgICAgICAgICAgIGxnY2Q6
PWdjZChjb25zKGxlYWRpbmdDb2VmZmljaWVudCBsLGxjcG9sKSkKICAgICAgICAgICAgKGdkbDo9
bGlmdChsLGQsbHF1byxsZ2NkLGx2YXIxLGxkZWcsbHZhbCkpIGNhc2UgImZhaWxlZCIgPT4KICAg
ICAgICAgICAgICAgcmV0dXJuIG5vdENvcHJpbWUoZyxwMixsZGVnLGx2YXIxLGx0cnkpCiAgICAg
ICAgICAgIGw6PWdkMjo9Z2RsOjpTVVBQCiAgICAgICAgICAgIHVsOj1jb21wbGV0ZUV2YWwobCxs
dmFyMSxsdmFsKQogICAgICAgICAgICBkbDo9ZGVncmVlIHVsCiAgICAgICAgICBnZDE6PWdkMSpn
ZDIKICAgICAgICAgIHVsaXN0Oj1bKHVmIGV4cXVvIGQpOjpTVVAgZm9yIHVmIGluIHVsaXN0XQog
CiAgICAgIGdjZFByaW1pdGl2ZShwMTpTVVBQLHAyOlNVUFApIDogU1VQUCA9PQogICAgICAgIGlm
IChkMTo9ZGVncmVlKHAxKSkgPiAoZDI6PWRlZ3JlZShwMikpIHRoZW4KICAgICAgICAgICAgKHAx
LHAyKTo9IChwMixwMSkKICAgICAgICAgICAgKGQxLGQyKTo9IChkMixkMSkKICAgICAgICBkZWdy
ZWUgcDEgPSAwID0+CiAgICAgICAgICAgIHAxID0gMCA9PiB1bml0Q2Fub25pY2FsIHAyCiAgICAg
ICAgICAgIHVuaXRDYW5vbmljYWwgcDEKICAgICAgICBsdmFyOkxpc3QgT1Y6PXNvcnQoIzE+IzIs
c2V0VW5pb24odmFyaWFibGVzIHAxLHZhcmlhYmxlcyBwMikpCiAgICAgICAgZW1wdHk/IGx2YXIg
PT4KICAgICAgICAgICByYWlzZVBvbHlub21pYWwoZ2NkKGxvd2VyUG9seW5vbWlhbCBwMSxsb3dl
clBvbHlub21pYWwgcDIpKQogICAgICAgIChwMiBleHF1byBwMSkgY2FzZSBTVVBQID0+IHVuaXRD
YW5vbmljYWwgcDEKICAgICAgICBsdHJ5Okxpc3QgTGlzdCBSOj1lbXB0eSgpCiAgICAgICAgdG90
UmVzdWx0Oj1sb2NhbGdjZChwMSxwMixsdmFyLGx0cnkpCiAgICAgICAgcmVzdWx0OiBTVVBQOj10
b3RSZXN1bHQubG9jZ2NkCiAgICAgICAgLS0gc3BlY2lhbCBjYXNlcwogICAgICAgIHJlc3VsdD0x
ID0+IDEkU1VQUAogICAgICAtLSBmb2xsb3dpbmcgdGVzdCBjYXVzZXMgcHJvYmxlbXMKICAgICAg
LS0gIGRlZ3JlZSByZXN1bHQ9ZDEgPT4gcmVzdWx0CiAgICAgICAgd2hpbGUgZmFpbHRlc3QocmVz
dWx0LHAxLHAyKSByZXBlYXQKLS0gICAgICAgIFNBWSRMaXNwICAicmV0cnlpbmcgZ2NkIgogICAg
ICAgICAgbHRyeTo9dG90UmVzdWx0Lmdvb2RpbnQKICAgICAgICAgIHRvdFJlc3VsdDo9bG9jYWxn
Y2QocDEscDIsbHZhcixsdHJ5KQogICAgICAgICAgcmVzdWx0Oj10b3RSZXN1bHQubG9jZ2NkCiAg
ICAgICAgcmVzdWx0CiAKICAgIC0tbG9jYWwgZnVuY3Rpb24gZm9yIHRoZSBnY2QgOiBpdCByZXR1
cm5zIHRoZSBldmFsdWF0aW9uIHBvaW50IHRvbwogICAgICBsb2NhbGdjZChwMTpTVVBQLHAyOlNV
UFAsbHZhcjpMaXN0KE9WKSxsdHJ5Okxpc3QgTGlzdCBSKSA6IExHY2QgPT0KICAgICAgICB1dGVy
bTo9Y2hvb3NlVmFsKHAxLHAyLGx2YXIsbHRyeSk6OlVUZXJtCiAgICAgICAgbHRyeTo9dXRlcm0u
bGludAogICAgICAgIGxpc3Rwb2w6PSB1dGVybS5scG9sCiAgICAgICAgdWQ6PWxpc3Rwb2wuZmly
c3QKICAgICAgICBkZDo9IGRlZ3JlZSB1ZAogCiAgICAgICAgLS10aGUgdW5pdmFyaWF0ZSBnY2Qg
aXMgMQogICAgICAgIGRkPTAgPT4gWzEkU1VQUCxsdHJ5XSRMR2NkCiAKICAgICAgICAtLW9uZSBv
ZiB0aGUgcG9seW5vbWlhbHMgaXMgdGhlIGdjZAogICAgICAgIGRkPWRlZ3JlZShwMSkgb3IgZGQ9
ZGVncmVlKHAyKSA9PgogICAgICAgICAgICAgICAgICAgICAgICAgW3V0ZXJtLm1wb2wsbHRyeV0k
TEdjZAogICAgICAgIGxkZWc6TGlzdCBOTkk6PW1hcChtaW4sZGVncmVlKHAxLGx2YXIpLGRlZ3Jl
ZShwMixsdmFyKSkKIAogICAgICAgLS0gaWYgdGhlcmUgaXMgYSBwb2x5bm9taWFsIGcgcy50LiBn
L2djZCBhbmQgZ2NkIGFyZSBjb3ByaW1lIC4uLgogICAgICAgIC0tIEkgY2FuIGxpZnQKICAgICAg
ICAoaDo9bGlmdD8ocDEscDIsdXRlcm0sbGRlZyxsdmFyKSkgY2FzZSBub3RDb3ByaW1lID0+CiAg
ICAgICAgICBbbm90Q29wcmltZShwMSxwMixsZGVnLGx2YXIsbHRyeSksbHRyeV0kTEdjZAogICAg
ICAgIGggY2FzZSBmYWlsZWQgPT4gbG9jYWxnY2QocDEscDIsbHZhcixsdHJ5KSAtLSBza2lwIGJh
ZCB2YWx1ZXM/CiAgICAgICAgW2gucyxsdHJ5XSRMR2NkCiAKIAogIC0tIGNvbnRlbnQsIGludGVy
bmFsIGZ1bmN0aW9ucyByZXR1cm4gdGhlIHBvbHkgaWYgaXQgaXMgYSBtb25vbWlhbAogICAgICBt
b25vbUNvbnRlbnQocDpTVVBQKTpTVVBQID09CiAgICAgICAgZGVncmVlKHApPTAgPT4gMQogICAg
ICAgIG1kOj0gbWluaW11bURlZ3JlZShwKQogICAgICAgIG1vbm9taWFsKGdjZCBzb3J0KGJldHRl
cixjb2VmZmljaWVudHMgcCksbWQpCiAKICAtLSBPcmRlcmluZyBmb3IgZ2NkIHB1cnBvc2VzCiAg
ICAgIGJldHRlcihwMTpQLHAyOlApOkJvb2xlYW4gPT0KICAgICAgICBncm91bmQ/IHAxID0+IHRy
dWUKICAgICAgICBncm91bmQ/IHAyID0+IGZhbHNlCiAgICAgICAgZGVncmVlKHAxLG1haW5WYXJp
YWJsZShwMSk6Ok9WKSA8IGRlZ3JlZShwMixtYWluVmFyaWFibGUocDIpOjpPVikKIAogIC0tIEdj
ZCBiZXR3ZWVuIHBvbHlub21pYWwgcDEgYW5kIHAyIHdpdGgKICAtLSBtYWluVmFyaWFibGUgcDEg
PCB4PW1haW5WYXJpYWJsZSBwMgogICAgICBnY2RUZXJtTGlzdChwMTpQLHAyOlApIDogUCA9PQog
ICAgICAgIHRlcm1MaXN0Oj1zb3J0KGJldHRlciwKICAgICAgICAgICBjb25zKHAxLGNvZWZmaWNp
ZW50cyB1bml2YXJpYXRlKHAyLChtYWluVmFyaWFibGUgcDIpOjpPVikpKQogICAgICAgIHE6UDo9
dGVybUxpc3QuZmlyc3QKICAgICAgICBmb3IgdGVybSBpbiB0ZXJtTGlzdC5yZXN0IHVudGlsIHEg
PSAxJFAgcmVwZWF0IHE6PSBnY2QocSx0ZXJtKQogICAgICAgIHEKIAogIC0tIEdjZCBiZXR3ZWVu
IHBvbHlub21pYWxzIHdpdGggdGhlIHNhbWUgbWFpblZhcmlhYmxlCiAgICAgIGdjZChwMTpTVVBQ
LHAyOlNVUFApOiBTVVBQID09CiAgICAgICAgaWYgZGVncmVlKHAxKSA+IGRlZ3JlZShwMikgdGhl
biAocDEscDIpOj0gKHAyLHAxKQogICAgICAgIGRlZ3JlZSBwMSA9IDAgPT4KICAgICAgICAgICBw
MSA9IDAgPT4gdW5pdENhbm9uaWNhbCBwMgogICAgICAgICAgIHAxID0gMSA9PiB1bml0Q2Fub25p
Y2FsIHAxCiAgICAgICAgICAgZ2NkKGxlYWRpbmdDb2VmZmljaWVudCBwMSwgY29udGVudCBwMik6
OlNVUFAKICAgICAgICByZWR1Y3R1bShwMSk9MCA9PiBnY2RNb25vbShwMSxtb25vbUNvbnRlbnQg
cDIpCiAgICAgICAgYzE6PSBtb25vbUNvbnRlbnQocDEpCiAgICAgICAgcmVkdWN0dW0ocDIpPTAg
PT4gZ2NkTW9ub20oYzEscDIpCiAgICAgICAgYzI6PSBtb25vbUNvbnRlbnQocDIpCiAgICAgICAg
cDE6PSAocDEgZXhxdW8gYzEpOjpTVVBQCiAgICAgICAgcDI6PSAocDIgZXhxdW8gYzIpOjpTVVBQ
CiAgICAgICAgZ2NkUHJpbWl0aXZlKHAxLHAyKSAqIGdjZE1vbm9tKGMxLGMyKQogCiAgIC0tIGdj
ZCBiZXR3ZWVuIDIgbW9ub21pYWxzCiAgICAgIGdjZE1vbm9tKG0xOlNVUFAsbTI6U1VQUCk6U1VQ
UCA9PQogICAgICAgIG1vbm9taWFsKGdjZChsZWFkaW5nQ29lZmZpY2llbnQobTEpLGxlYWRpbmdD
b2VmZmljaWVudChtMikpLAogICAgICAgICAgICAgICAgIG1pbihkZWdyZWUobTEpLGRlZ3JlZSht
MikpKQoKIAogICAgLS1JZiB0aGVyZSBpcyBhIHBvbCBzLnQuIHBvbC9nY2QgYW5kIGdjZCBhcmUg
Y29wcmltZSBJIGNhbiBsaWZ0CiAgICAgIGxpZnQ/KHAxOlNVUFAscDI6U1VQUCx1dGVybTpVVGVy
bSxsZGVnOkxpc3QgTk5JLAogICAgICAgICAgICAgICAgICAgICBsdmFyOkxpc3QgT1YpIDogVW5p
b24oczpTVVBQLGZhaWxlZDoiZmFpbGVkIixub3RDb3ByaW1lOiJub3RDb3ByaW1lIikgPT0KICAg
ICAgICBsZWFkcG9sOkJvb2xlYW46PWZhbHNlCiAgICAgICAgKGxpc3Rwb2wsbHZhbCk6PSh1dGVy
bS5scG9sLHV0ZXJtLmxpbnQuZmlyc3QpCiAgICAgICAgZDo9bGlzdHBvbC5maXJzdAogICAgICAg
IGxpc3Rwb2w6PWxpc3Rwb2wucmVzdAogICAgICAgIG5vbGlmdDpCb29sZWFuOj10cnVlCiAgICAg
ICAgZm9yIHVmIGluIGxpc3Rwb2wgcmVwZWF0CiAgICAgICAgICAgICAgLS1ub3RlIHVmIGFuZCBk
IG5vdCBuZWNlc3NhcmlseSBwcmltaXRpdmUKICAgICAgICAgIGRlZ3JlZSBnY2QodWYsZCkgPTAg
PT4gbm9saWZ0Oj1mYWxzZQogICAgICAgIG5vbGlmdCA9PiBbIm5vdENvcHJpbWUiXQogICAgICAg
IGY6U1VQUDo9KFtwMSxwMl0kTGlzdChTVVBQKSkuKHBvc2l0aW9uKHVmLGxpc3Rwb2wpKQogICAg
ICAgIGxnY2Q6PWdjZChsZWFkaW5nQ29lZmZpY2llbnQgcDEsIGxlYWRpbmdDb2VmZmljaWVudCBw
MikKICAgICAgICAobDo9bGlmdChmLGQsdWYsbGdjZCxsdmFyLGxkZWcsbHZhbCkpIGNhc2UgImZh
aWxlZCIgPT4gWyJmYWlsZWQiXQogICAgICAgIFtsIDo6IFNVUFBdCiAKICAgLS0gaW50ZXJmYWNl
IHdpdGggdGhlIGdlbmVyYWwgImxpZnRpbmciIGZ1bmN0aW9uCiAgICAgIGxpZnQoZjpTVVBQLGQ6
U1VQLHVmOlNVUCxsZ2NkOlAsbHZhcjpMaXN0IE9WLAogICAgICAgICAgICAgICAgICAgICAgICBs
ZGVnOkxpc3QgTk5JLGx2YWw6TGlzdCBSKTpVbmlvbihTVVBQLCJmYWlsZWQiKSA9PQogICAgICAg
IGxlYWRwb2w6Qm9vbGVhbjo9ZmFsc2UKICAgICAgICBsY2Y6UAogICAgICAgIGxjZjo9bGVhZGlu
Z0NvZWZmaWNpZW50IGYKICAgICAgICBkZjo9ZGVncmVlIGYKICAgICAgICBsZWFkbGlzdDpMaXN0
KFApOj1bXQogCiAgICAgICAgaWYgbGdjZF49MSB0aGVuCiAgICAgICAgICBsZWFkcG9sOj10cnVl
CiAgICAgICAgICBmOj1sZ2NkKmYKICAgICAgICAgIGxkZWc6PVtuMCtuMSBmb3IgbjAgaW4gbGRl
ZyBmb3IgbjEgaW4gZGVncmVlKGxnY2QsbHZhcildCiAgICAgICAgICBsY2Q6Ujo9bGVhZGluZ0Nv
ZWZmaWNpZW50IGQKICAgICAgICAgIGlmIGRlZ3JlZShsZ2NkKT0wIHRoZW4gZDo9KChyZXRyYWN0
IGxnY2QpICpkIGV4cXVvIGxjZCk6OlNVUAogICAgICAgICAgZWxzZSBkOj0ocmV0cmFjdChldmFs
KGxnY2QsbHZhcixsdmFsKSkgKiBkIGV4cXVvIGxjZCk6OlNVUAogICAgICAgICAgdWY6PWxjZCp1
ZgogICAgICAgIGxlYWRsaXN0Oj1bbGdjZCxsY2ZdCiAgICAgICAgbGc6PWltcG9zZWxjKFtkLHVm
XSxsdmFyLGx2YWwsbGVhZGxpc3QpCiAgICAgICAgKHBsOj1saWZ0aW5nKGYsbHZhcixsZyxsdmFs
LGxlYWRsaXN0LGxkZWcscG1vZCkpIGNhc2UgImZhaWxlZCIgPT4KICAgICAgICAgICAgICAgImZh
aWxlZCIKICAgICAgICBwbGlzdCA6PSBwbCA6OiBMaXN0IFNVUFAKICAgICAgICAocDA6U1VQUCxw
MTpTVVBQKTo9KHBsaXN0LmZpcnN0LHBsaXN0LjIpCiAgICAgICAgaWYgY29tcGxldGVFdmFsKHAw
LGx2YXIsbHZhbCkgXj0gbGcuZmlyc3QgdGhlbgogICAgICAgICAgIChwMCxwMSk6PShwMSxwMCkK
ICAgICAgICBebGVhZHBvbCA9PiBwMAogICAgICAgIHAwIGV4cXVvIGNvbnRlbnQocDApCiAKICAt
LSBHY2QgZm9yIHR3byBtdWx0aXZhcmlhdGUgcG9seW5vbWlhbHMKICAgICAgZ2NkKHAxOlAscDI6
UCkgOiBQID09CiAgICAgICAgZ3JvdW5kPyBwMSA9PgogICAgICAgICAgcDEgOj0gdW5pdENhbm9u
aWNhbCBwMQogICAgICAgICAgcDEgPSAxJFAgPT4gcDEKICAgICAgICAgIHAxID0gMCRQID0+IHVu
aXRDYW5vbmljYWwgcDIKICAgICAgICAgIGdyb3VuZD8gcDIgPT4gZ2NkKChyZXRyYWN0IHAxKUBS
LChyZXRyYWN0IHAyKUBSKTo6UAogICAgICAgICAgZ2NkVGVybUxpc3QocDEscDIpCiAgICAgICAg
Z3JvdW5kPyBwMiA9PgogICAgICAgICAgcDIgOj0gdW5pdENhbm9uaWNhbCBwMgogICAgICAgICAg
cDIgPSAxJFAgPT4gcDIKICAgICAgICAgIHAyID0gMCRQID0+IHVuaXRDYW5vbmljYWwgcDEKICAg
ICAgICAgIGdjZFRlcm1MaXN0KHAyLHAxKQogICAgICAgIChwMTo9IHVuaXRDYW5vbmljYWwocDEp
KSA9IChwMjo9IHVuaXRDYW5vbmljYWwocDIpKSA9PiBwMQogICAgICAgIG12MTo9IG1haW5WYXJp
YWJsZShwMSk6Ok9WCiAgICAgICAgbXYyOj0gbWFpblZhcmlhYmxlKHAyKTo6T1YKICAgICAgICBt
djEgPSBtdjIgPT4gbXVsdGl2YXJpYXRlKGdjZCh1bml2YXJpYXRlKHAxLG12MSksCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5pdmFyaWF0ZShwMixtdjEpKSxtdjEpCiAg
ICAgICAgbXYxIDwgbXYyID0+IGdjZFRlcm1MaXN0KHAxLHAyKQogICAgICAgIGdjZFRlcm1MaXN0
KHAyLHAxKQogCiAgLS0gR2NkIGZvciBhIGxpc3Qgb2YgbXVsdGl2YXJpYXRlIHBvbHlub21pYWxz
CiAgICAgIGdjZChsaXN0cDpMaXN0IFApIDogUCA9PQogICAgICAgIGxmOj1zb3J0KGJldHRlcixs
aXN0cCkKICAgICAgICBmOj1sZi5maXJzdAogICAgICAgIGZvciBnIGluIGxmLnJlc3QgcmVwZWF0
CiAgICAgICAgICBmOj1nY2QoZixnKQogICAgICAgICAgaWYgZj0xJFAgdGhlbiByZXR1cm4gZgog
ICAgICAgIGYKCiAgICAgIGdjZChsaXN0cDpMaXN0IFNVUFApIDogU1VQUCA9PQogICAgICAgIGxm
Oj1zb3J0KGRlZ3JlZSgjMSk8ZGVncmVlKCMyKSxsaXN0cCkKICAgICAgICBmOj1sZi5maXJzdAog
ICAgICAgIGZvciBnIGluIGxmLnJlc3QgcmVwZWF0CiAgICAgICAgICBmOj1nY2QoZixnKQogICAg
ICAgICAgaWYgZj0xIHRoZW4gcmV0dXJuIGYKICAgICAgICBmCgogCiAgIC0tIEdjZCBmb3IgcHJp
bWl0aXZlIHBvbHlub21pYWxzCiAgICAgIGdjZFByaW1pdGl2ZShwMTpQLHAyOlApOlAgPT0KICAg
ICAgICAocDE6PSB1bml0Q2Fub25pY2FsKHAxKSkgPSAocDI6PSB1bml0Q2Fub25pY2FsKHAyKSkg
PT4gcDEKICAgICAgICBncm91bmQ/IHAxID0+CiAgICAgICAgICBncm91bmQ/IHAyID0+IGdjZCgo
cmV0cmFjdCBwMSlAUiwocmV0cmFjdCBwMilAUik6OlAKICAgICAgICAgIHAxID0gMCRQID0+IHAy
CiAgICAgICAgICAxJFAKICAgICAgICBncm91bmQ/IHAyID0+CiAgICAgICAgICBwMiA9IDAkUCA9
PiBwMQogICAgICAgICAgMSRQCiAgICAgICAgbXYxOj0gbWFpblZhcmlhYmxlKHAxKTo6T1YKICAg
ICAgICBtdjI6PSBtYWluVmFyaWFibGUocDIpOjpPVgogICAgICAgIG12MSA9IG12MiA9PgogICAg
ICAgICAgbWQ6PW1pbihtaW5pbXVtRGVncmVlKHAxLG12MSksbWluaW11bURlZ3JlZShwMixtdjIp
KQogICAgICAgICAgbXA6PTEkUAogICAgICAgICAgaWYgbWQ+MSB0aGVuCiAgICAgICAgICAgIG1w
Oj0obXYxOjpQKSoqbWQKICAgICAgICAgICAgcDE6PShwMSBleHF1byBtcCk6OlAKICAgICAgICAg
ICAgcDI6PShwMiBleHF1byBtcCk6OlAKICAgICAgICAgIHVwMSA6PSB1bml2YXJpYXRlKHAxLG12
MSkKICAgICAgICAgIHVwMiA6PSB1bml2YXJpYXRlKHAyLG12MikKICAgICAgICAgIG1wKm11bHRp
dmFyaWF0ZShnY2RQcmltaXRpdmUodXAxLHVwMiksbXYxKQogICAgICAgIDEkUAogCiAgLS0gR2Nk
IGZvciBhIGxpc3Qgb2YgcHJpbWl0aXZlIG11bHRpdmFyaWF0ZSBwb2x5bm9taWFscwogICAgICBn
Y2RQcmltaXRpdmUobGlzdHA6TGlzdCBQKSA6IFAgPT0KICAgICAgICBsZjo9c29ydChiZXR0ZXIs
bGlzdHApCiAgICAgICAgZjo9bGYuZmlyc3QKICAgICAgICBmb3IgZyBpbiBsZi5yZXN0IHJlcGVh
dAogICAgICAgICAgZjo9Z2NkUHJpbWl0aXZlKGYsZykKICAgICAgICAgIGlmIGY9MSRQIHRoZW4g
cmV0dXJuIGYKICAgICAgICBmCiAKIAoK

\start
Date: Mon, 16 May 2005 21:15:07 -0500
From: Tim Daly
To: list
Subject: --patch-36
Cc: Christophe.Conil, Barry Trager

patch-36 is up at arch.axiom-developer.org. 
These will be available in the June 1 push. 
The changes are:

Summary: add french docs, Creative Commons License, and gcdPrimitive fix
Keywords: Conil, Trager

20050516 bmt src/algebra/pgcd.spad fix failure in gcdPrimitive
20050516 bmt Barry Trager (Barry Trager)
20050515 cxc license/LICENSE.CC Creative Commons License added
20050515 cxc src/doc/french/manuel2.tm added
20050515 cxc src/doc/french/manuel2.pdf added
20050515 cxc src/doc/french/manuel1.tm added
20050515 cxc src/doc/french/manuel1.pdf added
20050515 cxc src/doc/french/ac20.tm added
20050515 cxc src/doc/french/ac20.pdf added
20050515 cxc Christophe Conil Christophe.Conil@UTBM.fr
20050515 tpd src/doc/french created
20050515 tpd src/interp/setq.lisp add Christophe Conil, Quentin Carpent
20050515 tpd README add Christophe Conil, Quentin Carpent

\start
Date: Mon, 16 May 2005 12:32:33 -0400
From: Tim Daly
To: Barry Trager
Subject: Re: fix for occasional failure in pgcd.spad

The pgcd.spad patch has been applied.
It will be available in the July 1 release at both
http://savannah.nongnu.org/projects/axiom and
http://sourceforge.net/projects/axiom

\start
Date: Mon, 16 May 2005 15:30:57 -0500
From: MathAction (Martin Rubey)
To: MathAction
Subject: [Axiom-mail] axiom and emacs ?

I'm using shell mode, which is quite suboptimal, of course. Hence, if somebody
gets around to write a proper emacs mode along the lines of maxima mode maybe,
I'd be interested, too.

Francois Maltey writes:
 > Hello !
 > 
 > Thanks for all your advices about axiom-documentation !
 > 
 > Is there a emacs mode for axiom ?

\start
Date: Sun, 15 May 2005 16:07:59 -0400
From: Bill Page
To: list
Subject: building Axiom with GCL Version_2_6_7pre fails
Cc: Camm Maguire

Camm,

Previously I had successfully built Axiom on Windows
using Version_2_6_7pre in place of gcl-2.6.6. But I just
tried again after cvs update today and I get the following
error message. This occurs a long way into the build process
after all the algebra has been compiled, when Axiom is
trying to build the databases in (make-databases "" nil).

Can you imagine what recent change (last week?) might lead
to this failure? Perhaps the change to probe-file or related
routine?

The etc/Makefile stanza where the failure occurs is

${MNT}/${SYS}/algebra/*.daase: ${INT}/algebra/*.NRLIB/code.o
        @ echo 4 rebuilding databases...
        @ cp ${SRC}/doc/gloss.text ${INT}/algebra
        @ cp ${SRC}/doc/gloss.text ${INT}/algebra
        @ cp ${SRC}/doc/topics.data ${INT}/algebra
        @ cp ${SRC}/doc/topics.data ${INT}/algebra
        @ (cd ${INT}/algebra ; echo ')lisp (make-databases "" nil)' |
${INTERPSY
S} )
        @ cp ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra


Regards,
Bill Page.

-----------
4302 finished
C:/msys/1.0/home/Administrator/axiom--windows--1/src/algebra
make[3]: Leaving directory
`/home/Administrator/axiom--windows--1/src/algebra'
37 making C:/msys/1.0/home/Administrator/axiom--windows--1/src/etc
make[3]: Entering directory
`/home/Administrator/axiom--windows--1/src/etc'
4 rebuilding databases...
                        AXIOM Computer Algebra System 
                 Version of Sunday May 15, 2005 at 13:05:30 
------------------------------------------------------------------------
-----
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
------------------------------------------------------------------------
-----
 
   Using local database
C:/msys/1.0/home/Administrator/axiom--windows--1/src/share/algebra/compr
ess.daase..   Using local database
C:/msys/1.0/home/Administrator/axiom--windows--1/src/share/algebra/inter
p.daase..
   Using local database
C:/msys/1.0/home/Administrator/axiom--windows--1/src/share/algebra/opera
tion.daase..
   Using local database
C:/msys/1.0/home/Administrator/axiom--windows--1/src/share/algebra/categ
ory.daase..
   Using local database
C:/msys/1.0/home/Administrator/axiom--windows--1/src/share/algebra/brows
e.daase..
(1) ->  
   >> System error:
   Can't change the current directory to "NIL".

protected-symbol-warn called with (NIL)
(1) -> cp: cannot stat
`C:/msys/1.0/home/Administrator/axiom--windows--1/int/algebra/*.daase':
No such file or directory
make[3]: ***
[C:/msys/1.0/home/Administrator/axiom--windows--1/mnt/windows/algebra/*.
daase] Error 1
make[3]: Leaving directory
`/home/Administrator/axiom--windows--1/src/etc'
make[2]: *** [etcdir] Error 2
make[2]: Leaving directory `/home/Administrator/axiom--windows--1/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/Administrator/axiom--windows--1'
make: *** [all] Error 2

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

\start
Date: Mon, 16 May 2005 18:24:58 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [TeXmacs] 

   A new version of the Axiom stylesheet 'axiom.ts' is available in
Axiom for Windows which improves the formatting of Axiom output.
To obtain this stylesheet, use Windows file manager to replace the
existing file in TeXmacs::
 
     c:\Program Files\wintexmacs\TeXmacs\plugins\axiom\packages\session\axiom.ts
 
with the file of the same name found in Axiom for Windows::
 
     c:\Program Files\axiom\mnt\windows\axiom.ts

On cygwin the file 'axiom.ts' is located in the directory::

Overwrite existing stylesheet with the new stylesheet file::

\start
Date: Mon, 16 May 2005 20:05:58 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: re: about axiom documentation

Christophe,

On May 14, 2005 6:19 AM you wrote:

> Tim asked:
> > Thanks for the info on the french documentation. Can you
> > give me a URL for the docs?
>
> I just created a small page with all docs and infos about our work.
> You can find them under:

http://la.riverotte.free.fr/axiom

Thank you very much for preparing this webpage!

> Tim wrote:
>> I'm interested in making Axiom more international ...

I also think in would be great to have more Axiom material
that would be easily accessible to non-English readers on
the MathAction/Axiom web site. I would be very pleased if
you or your colleagues were interested in helping to develop
and maintaining some French language web pages on MathAction.
Since MathAction is a wiki, these pages can be created and
updated directly by you through your browser.

If you (or anyone else reading this list) would like some
help getting started, please let me know.

Regards,
Bill Page.

PS. I added a link to your new web page here:

http://page.axiom-developer.org/zope/mathaction/AxiomDocumentation

\start
Date: Sun, 15 May 2005 15:08:36 -0500
From: Tim Daly
To: Christophe Conil, Quentin Carpent
Subject: french documentation

Christophe, Quentin,

I've added the 6 documents and the Creative Commons license to Axiom.

\start
Date: Tue, 17 May 2005 11:37:05 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#157 bad call to getdatabase] (new) 

)lisp (setq *miss* t) will cause messages to be output that show the 
arguments to the getdatabase function. The first argument is the
constructor and the second argument is the key.

There is a bug somewhere. Given the sequence:
)lisp (setq *miss* t)
1
1
x
x <--- getdatabase gets called with constructor=CONSTRUCTORMODEMAP key=Variable
which is incorrect.

\start
Date: Tue, 17 May 2005 16:02:28 -0500
From: MathAction (pacheco)
To: MathAction
Subject: [#158 Result  with partial display] (new) 

With Texmacs in Windows XP the  result  of 
 (sqrt(x)+sqrt(y)+sqrt(z))**4
is only partialy displaied .In command mode all is OK.

\start
Date: Wed, 18 May 2005 07:44:07 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#158 Result with partial display] work-a-round for TeXmacs

This seems to be a problem in the TeXmacs conversion of
LaTeX output. The output is correct if you set a shorter
Axiom output width as follows::

  )set output texmacs width 3.5

This command is one of several new commands in the
new TexMacs interface in Axiom for Windows. In TeXmacs
the command::

  )set output texmacs

displays::

  --------------------------- The texmacs Option ----------------------------

  Description: options for display of AXIOM output in TeXmacs

  )set output texmacs is used to control the TeXmacs-AXIOM interface
  The default values are controlled by environment variable TM_AXIOM
  and may be overriden by command line options.

  Syntax:    )set output texmacs <arg>
      where arg can be one or more of
    break <on>|<off>              line-break algorithm
    over <on>|\<off>              convert 2-d \over to 1-d
    cdot <on>|<off>               convert \cdot to \ (space)
    space <on>|<off>              convert \ (space) to \,
    big( <on>|<off>               convert \left( \right( to ( )
    width <9.99>                  line width in inches

      <on> may be on, yes, 1
      <off> may be off, no , 0

   The current settings are:
     break 1, over 1, cdot 1, space 0, big( 1, width 4.500


\start
Date: Wed, 18 May 2005 10:23:08 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#159 build directory captured in scripts] (new) 

The noweb code is capturing the build directory name in scripts.
in $AXIOM/bin/lib noweb, notangle, noweave, nountangle, nodefs, noroots,
nuweb2noweb, noroff, pipedocs, unmarkup, and the whole man1 directory
all have the name of the build directory. 


\start
Date: Wed, 18 May 2005 13:23:14 -0500
From: MathAction (unknown)
To: MathAction
Subject: [#157 bad call to getdatabase] Explicitation

\begin{axiom}
)lisp (setq *miss* t)
1
1
x
x
)lisp (setq *miss* nil)
\end{axiom}

\start
Date: Wed, 18 May 2005 13:44:54 -0500
From: MathAction (unknown)
To: MathAction
Subject: [#141 atan(tan(3)) => 3] We can document this

\begin{axiom}
atan(cot(4))
atan(cot(4.0))
\end{axiom}
What about (temporary) document the domain of each function, for this package ?

\start
Date: Wed, 18 May 2005 20:18:52 -0500
From: Tim Daly
To: list
Subject: --patch-37

Summary: make noweb respect $AXIOM, documentation
Keywords: daly, documentation

20050518 tpd --patch-37
20050518 tpd zips/noweb.src.Makefile.patch make noweb respect $AXIOM
20050517 tpd src/interp/interp-proclaims.lisp |NRTgetOperationAlistFromLisplib|
20050517 tpd src/interp/i-coerce.boot document getConstantFromDomain function
20050517 tpd src/interp/i-funsel.boot document isPartialMode function
20050517 tpd src/interp/macros.lisp document DEFUN CONTAINED
20050517 tpd src/interp/bootfuns.lisp document |$EmptyMode| constant

\start
Date: Thu, 19 May 2005 09:37:32 +1000
From: Mike Thomas
To: Bill Page
Subject: RE: building Axiom with GCL Version_2_6_7pre fails
Cc: Camm Maguire

Hi Bill.

| Previously I had successfully built Axiom on Windows
| using Version_2_6_7pre in place of gcl-2.6.6. But I just
| tried again after cvs update today and I get the following
| error message. This occurs a long way into the build process
| after all the algebra has been compiled, when Axiom is
| trying to build the databases in (make-databases "" nil).
|
| Can you imagine what recent change (last week?) might lead
| to this failure? Perhaps the change to probe-file or related
| routine?

Before I dive in on this one, am I right in thinking that the windows darcs
repository has not changed since that patch I sent you in March?

\start
Date: Thu, 19 May 2005 09:28:15 -0400
From: Bill Page
To: Mike Thomas
Subject: RE: building Axiom with GCL Version_2_6_7pre fails
Cc: Camm Maguire

On May 18, 2005 7:38 PM Mike Thomas wrote:

> Before I dive in on this one, am I right in thinking
> that the windows darcs repository has not changed since
> that patch I sent you in March?

Do you mean the patch which replaces unix system commands
such as `cat' and `rm' with lisp functions? Although I have
been testing with your patch on my local system, I believe
that I have not (yet) updated the Axiom on Windows darcs
repository at axiom-developer.org In fact, I think the
version in the repository is still also using the GCL-2.6.5w
patches.

Would you like me to update the repository now?

\start
Date: Thu, 19 May 2005 14:38:48 -0500
From: MathAction (Francois Maltey)
To: MathAction
Subject: [Axiom-mail] axiom and emacs ?

Hello, 

I try to write an axiom mode for emacs and xemacs.

When I use emacs (not xemacs) I can send data to axiom and read the result.
When I use xemacs (v. 21.5 beta 18) I read data BUT it seems that axiom
(the program) doesn't receive any data. 

Why axiom doesn't read xemacs process-send-string ?

Do you have any idea ?

(defvar axiomRun-process nil)
(defun axiomRun-filter (proc str) (insert str))

(defun send-str-to-axiom ()
  (interactive)
  (beginning-of-line)
  (process-send-string axiomRun-process 
    (concat (buffer-substring (point) (point-max)) "\n")))

(defun axiom-run nil (interactive)(axiomRun-this-axiom-run "*Axiom*"))

(defun axiomRun-this-axiom-run (str)
  (switch-to-buffer str)
; I try the 3 cases, without let, with a t-variable, and a nil-variable.
  (let 
    ((process-connection-type nil))
    (setq axiomRun-process 
      (start-process "axiom" (current-buffer) "sh" "-e" "axiom"))
; I also try the direct call, not the sh -e call.
    (set-process-filter axiomRun-process (function axiomRun-filter))))

During no-one case I can't send data with xemacs.
With emacs only the t-variable process-connection-type fails.

Do you have any idea ?

\start
Date: Thu, 19 May 2005 15:45:34 -0500
From: MathAction (Francois Maltey)
To: MathAction
Subject: [Axiom-mail] axiom and emacs ?

Hello Martin !

> I'm using shell mode, which is quite suboptimal, of course. Hence,
> if somebody gets around to write a proper emacs mode along the lines
> of maxima mode maybe, I'd be interested, too.

I'll try, 
Do you find very pretty the picture output by imaxima for maxima ?

The result of factorial (100) is over ONE line and is too long.
I can't read the middle of expand ((1+x)^40) because emacs refuse
to show the middle of the image. 

Before axiom I use mupad in an emacs windows without latex output.
I find very pretty the latex output for little data, not when 
we are trying an heavy computation.

And you, what do you prefer ?

\start
Date: Thu, 19 May 2005 16:59:55 -0500
From: Tim Daly
To: Francois Maltey
Subject: axiom and emacs

Francois,

Be aware that the 'axiom' shell script does not start the axiom
interpreter directly. It starts sman (superman), which is a process
that starts AXIOMsys (the interpreter), the browser, the graphics,
and clef (command line edit function, a readline workalike).

Try starting 'AXIOMsys' rather than 'axiom'.

\start
Date: 19 May 2005 18:41:08 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: building Axiom with GCL Version_2_6_7pre fails

Greetings!

My last commit to 2.6.7pre was on 5/7.  If it broke after that point,
perhaps it was one of these?:

   [  23: Mike Thomas         ] [Gcl-commits] gcl/gcl-tk makefile
       <  23: Mike Thomas         > 
   [  25: Mike Thomas         ] [Gcl-commits] gcl configure.in configure makedefc.in
       <  25: Mike Thomas         > 
   [  27: Mike Thomas         ] [Gcl-commits] gcl/gcl-tk makefile winkill.c tclwinkill.c
       <  27: Mike Thomas         > 
   [  25: Mike Thomas         ] [Gcl-commits] gcl/gcl-tk makefile tkl.lisp tkMain.c
       <  25: Mike Thomas         > 

In any case, you can give a -D command to get 2.6.7pre as of a certain
point.  It would help me if you can confirm that it worked just after
this point:

 -- Camm Maguire  Sat,  7 May 2005 14:40:00 +0000


Bill Page writes:

> Camm,
> 
> Previously I had successfully built Axiom on Windows
> using Version_2_6_7pre in place of gcl-2.6.6. But I just
> tried again after cvs update today and I get the following
> error message. This occurs a long way into the build process
> after all the algebra has been compiled, when Axiom is
> trying to build the databases in (make-databases "" nil).
> 
> Can you imagine what recent change (last week?) might lead
> to this failure? Perhaps the change to probe-file or related
> routine?
> 
> The etc/Makefile stanza where the failure occurs is
> 
> ${MNT}/${SYS}/algebra/*.daase: ${INT}/algebra/*.NRLIB/code.o
>         @ echo 4 rebuilding databases...
>         @ cp ${SRC}/doc/gloss.text ${INT}/algebra
>         @ cp ${SRC}/doc/gloss.text ${INT}/algebra
>         @ cp ${SRC}/doc/topics.data ${INT}/algebra
>         @ cp ${SRC}/doc/topics.data ${INT}/algebra
>         @ (cd ${INT}/algebra ; echo ')lisp (make-databases "" nil)' |
> ${INTERPSY
> S} )
>         @ cp ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra
> 
> 
> Regards,
> Bill Page.
> 
> -----------
> 4302 finished
> C:/msys/1.0/home/Administrator/axiom--windows--1/src/algebra
> make[3]: Leaving directory
> `/home/Administrator/axiom--windows--1/src/algebra'
> 37 making C:/msys/1.0/home/Administrator/axiom--windows--1/src/etc
> make[3]: Entering directory
> `/home/Administrator/axiom--windows--1/src/etc'
> 4 rebuilding databases...
>                         AXIOM Computer Algebra System 
>                  Version of Sunday May 15, 2005 at 13:05:30 
> ------------------------------------------------------------------------
> -----
>    Issue )copyright to view copyright notices.
>    Issue )summary for a summary of useful system commands.
>    Issue )quit to leave AXIOM and return to shell.
> ------------------------------------------------------------------------
> -----
>  
>    Using local database
> C:/msys/1.0/home/Administrator/axiom--windows--1/src/share/algebra/compr
> ess.daase..   Using local database
> C:/msys/1.0/home/Administrator/axiom--windows--1/src/share/algebra/inter
> p.daase..
>    Using local database
> C:/msys/1.0/home/Administrator/axiom--windows--1/src/share/algebra/opera
> tion.daase..
>    Using local database
> C:/msys/1.0/home/Administrator/axiom--windows--1/src/share/algebra/categ
> ory.daase..
>    Using local database
> C:/msys/1.0/home/Administrator/axiom--windows--1/src/share/algebra/brows
> e.daase..
> (1) ->  
>    >> System error:
>    Can't change the current directory to "NIL".
> 
> protected-symbol-warn called with (NIL)
> (1) -> cp: cannot stat
> `C:/msys/1.0/home/Administrator/axiom--windows--1/int/algebra/*.daase':
> No such file or directory
> make[3]: ***
> [C:/msys/1.0/home/Administrator/axiom--windows--1/mnt/windows/algebra/*.
> daase] Error 1
> make[3]: Leaving directory
> `/home/Administrator/axiom--windows--1/src/etc'
> make[2]: *** [etcdir] Error 2
> make[2]: Leaving directory `/home/Administrator/axiom--windows--1/src'
> make[1]: *** [srcdir] Error 2
> make[1]: Leaving directory `/home/Administrator/axiom--windows--1'
> make: *** [all] Error 2

\start
Date: Fri, 20 May 2005 09:14:25 +1000
From: Mike Thomas
To: Bill Page
Subject: RE: building Axiom with GCL Version_2_6_7pre fails
Cc: Camm Maguire

Hi Bill.

| Do you mean the patch which replaces unix system commands
| such as `cat' and `rm' with lisp functions?

Yes.

| Although I have
| been testing with your patch on my local system, I believe
| that I have not (yet) updated the Axiom on Windows darcs
| repository at axiom-developer.org In fact, I think the
| version in the repository is still also using the GCL-2.6.5w
| patches.
|
| Would you like me to update the repository now?

Only if convernient for you.  It would be better if we were running the same
Axiom code into which I can plug GCL 2.6.7pre to catch that problem.

\start
Date: Fri, 20 May 2005 09:14:26 +1000
From: Mike Thomas
To: Camm Maguire, Bill Page
Subject: RE: [Gcl-devel] Re: building Axiom with GCL Version_2_6_7pre fails

Hi Camm.

| My last commit to 2.6.7pre was on 5/7.  If it broke after that point,
| perhaps it was one of these?:
|
|    [  23: Mike Thomas         ] [Gcl-commits] gcl/gcl-tk makefile
|        <  23: Mike Thomas         >
|    [  25: Mike Thomas         ] [Gcl-commits] gcl configure.in
| configure makedefc.in
|        <  25: Mike Thomas         >
|    [  27: Mike Thomas         ] [Gcl-commits] gcl/gcl-tk makefile
| winkill.c tclwinkill.c
|        <  27: Mike Thomas         >
|    [  25: Mike Thomas         ] [Gcl-commits] gcl/gcl-tk makefile
| tkl.lisp tkMain.c
|        <  25: Mike Thomas         >


These ones have nought to do with the directory issue Bill reported, so I'm
expecting that it was some difference in Unix/Windows C runtimes with
respect to those new changes we tried recently re directories and files.
I'll look into it once I know what Bill intends re the Darcs repo.

\start
Date: Fri, 20 May 2005 00:36:40 +0200
From: Francois Maltey
To: xemacs-beta@xemacs.org,list
Subject: xemacs in GNOME can't send data to process, xemacs in xterm can

Hello (ter)

xemacs calls the program axiom :

When I call emacs or xemacs -nw in a xterm I can send data to axiom
and read the result.

When I call emacs or xemacs from a xterm in an other X11 windows,
I can send data to axiom and read the result.

When I call emacs or xemacs (v. 21.5 beta 18) from the gnome tool-bar
I read data BUT it seems that axiom (the program) doesn't receive any
data after

When I call emacs or xemacs from the gnome tool-bar with the option
"to run in an xterm" then the the icon opens an xterm and
I can send data to axiom and read the result.

My tool-bar properties runs : xemacs21_5.2005_03 or emacs.

Every time I do :
(start-process "axiom" (current-buffer) "axiom")
(process-send-string "axiom" "123\r")

Is it a bug^H^H^H feature of xemacs ? of axiom  ? of gnome ?

Where is the virtual input (keyboard) in all theses cases ?
What does axiom read ?

Thanks a lot Adrian, Daly and others !

\start
Date: Thu, 19 May 2005 22:45:35 -0500
From: Tim Daly
To: Mark Pleszkoch
Subject: provisos and indeterminates

The proviso work is all in paper form in a pile and now in a
packed box. I'll see if I can guess which one it is but I'd
rather not unpack the world until after the move. I really should
keyboard this stuff. I did it before the net was all the rage and
the paper is just rotting away now.

  the proviso idea is fundamental to math but ignored or treated badly
  by all computer algebra systems. provisos arise in things like:

    1
   ---   provided x != 0
    x

  it turns out that a deep investigation of the subject yields a
  few insights. 

  1) provisos have two different forms of mathematics
     a) computing WITH provisios (e.g what is (1/x)*(1/y))
     b) computing IN provisos (e.g. what is (provided a>0)*(provided a<0))

  2) provisos contain general branching
     it is possible to have a computation (such as the above)
     break into parts (e.g. x<0, x=0, x>0) at every stage of
     the computation. this necessitates general control structures
     such as backtracking, stacking, early cutoff, etc. I have
     identified 8 different possible forms.

  3) most proviso forms can be reduced to intervals (an unpublished result)

  4) provisos are a poorly studied area of math but vital for understanding
     computational mathematics.

As for the indeterminates (now called indefinites) this is a currently
funded NSF project at CCNY. There are no papers available yet. The basic
idea is to examine questions like:

  if p and q are polynomials 
  we know what the third term of p^3 * q^4 is 
  but what is third term of p^n * q^m?

  if M is a matrix and n is an indefinite integer
  what is the general term for M_{i,j} in M^n

  normally in a computer algebra system, 
  given n+1
  we presume n is of type 'variable' and 1 is of type 'integer'
  we promote both n and 1 to type 'polynomial(integer)'
  we choose '+' from polynomial(integer)
  and the result is that n+1 is of type polynomial(integer).

  but suppose 'n' is an "indefinite integer"
  then we can construct n+1 where '+' comes from indefinite(integer)
  and the result is that n+1 is of type indefinite(integer)
  so we can use this new thing where integer is expected 
  and construct things like polynomial(indefinite(integer))
  
  does the 'indefinite' type propagate? do we get
  indefinite(polynomial(indefinite(integer)))?

The two subjects are deeply related and very poorly studied.
They are both fundamental to computational mathematics.

Axiom is the perfect platform for doing this kind of research.
It has a 'suchthat' type which was my first attempt at this
but I've come to understand that the issue is more fundamental.

\start
Date: Fri, 20 May 2005 00:22:48 -0400
From: Bill Page
To: Mike Thomas
Subject: RE: building Axiom with GCL Version_2_6_7pre fails
Cc: Camm Maguire

Mike,

On May 19, 2005 7:14 PM you wrote:

> I wrote:
> |
> | Would you like me to update the repository now?
>
> Only if convernient for you.  It would be better if we were
> running the same Axiom code into which I can plug GCL 2.6.7pre
> to catch that problem.

If you have a version of the Axiom source that builds with
gcl-2.6.6, then I think you should go ahead and try your source
with 2.6.7pre. I took a quick look at the make-databases lisp
code and there are several places where it calls probe-file etc.
I think a call that unexpectedly returns NIL seems most likely
to me to be the source of problem. But I don't have a lot of
confidence in my abilities in lisp and haven't had enough time
yet to play.

I am having some trouble updating the darcs repository since
I am still recovering from the loss of the motherboard on my
main Windows system about a month ago. I opted to replace my
Intel 2.4 GHz chip with an AMD Athalon 3500+. I really like
the new AMD chip, but that necessitated completely rebuilding
my Windows environment and it hasn't been easy. (: As Tim
Daly says: There is no such thing as an easy job. :) And now
most recently, having just reinstalled darcs 1.0.2 on my Windows
XP system, I find that I can run it successfully under the
Windows command shell but not under MSYS. Nuts. Another thing
to fix. :(

Anyway in my test, all I did was to pull Version_2_6_7pre from
cvs and create a tarball to replace the gcl-2.6.6.tgz in the
Axiom zips directory. And then rebuild Axiom. It worked the
first time I tried it about 2 weeks but then failed last week
after a cvs update.

My objective in doing this was to set up a version of Axiom
in which I could run the HTTP server code that Camm created.
I want to be able to pass commands to Axiom via an HTTP form
with a textfield and get the results back at least as simple
plain text. So my next lisp question is going to be: How do
I call Axiom from within a lisp function to evaluate a string
as a command and return the result as a string? I presume
that this already happens somewhere already Axiom when it
talks to the hyperdoc front-end. Any idea where I should look?

BTW, the same approach of replacing gcl-2.6.6 with
Version_2_6_7pre works fine when running x86-64 Fedora Core 3
Linux on the new AMD. With the most recent axiom--main--1
sources I just had to remove the run-process patch that Tim
added since it is now included in Version_2_6_7pre. And man!
Does the build ever fly under on this platform! I still can't
believe that GCL builds in under 2 minutes flat and the whole
Axiom build is done in about 45 minutes, including running
the tests. Amazing.

I REALLY like this 64-bit stuff and I can't wait to have this
on Windows. Apparently there is a 64-bit Windows XP version
that will be available soon. I wonder how easy it is to build
64-bit apps with MSYS/MinGW?

\start
Date: Fri, 20 May 2005 07:27:30 -0500
From: Tim Daly
To: Bill Page
Subject: provisos and indeterminates

Off hand I'm not sure how to do string input but I'm sure it is possible.
I'll have to read some code and let you know. Why can't you just feed the
string to stdin?

Check out FAQ 19 to figure out how to get the output in a single line.

Oh, yeah, and remember to use AXIOMsys rather than axiom as the command.

\start
Date: Fri, 20 May 2005 11:19:32 -0400
From: Bill Page
To: Tim Daly
Subject: Axiom interface via HTTP

On  May 20, 2005 8:28 AM Tim Daly wrote:

> Off hand I'm not sure how to do string input but I'm
> sure it is possible. I'll have to read some code and let
> you know. Why can't you just feed the string to stdin?

What I am talking about is using the socket code that Camm
wrote as an HTTP interface to Axiom. The idea is that the
input loop of AXIOMsys operates a dedicated special purpose
web server and the user connects to Axiom using a standard
browser. There is only one AXIOMsys process running as a
server that talks directly to the browser. It might be
invoked by starting AXIOMsys and giving a command like:

  )set httpmode

In addition to the HTTP port, as part of the HTTP protocol
with HTML <form ... method="put"> stdin is involved in
receiving the contents of the web form. This new "httpmode"
code in AXIOMsys would parse this input from the web browser,
format it as an Axiom command and process it as if it was
normal keyboard input. (This is where I need help to
understand how to call the Axiom input evaluation from
within lisp and return the result of the calculation back
to the httpmode list function. Which in turn gets formatted
as HTTP and sent back to the browser. All of this is done
entirely within AXIOMsys without any auxillary processes.

One simple web page layout that might work would have two
parts like this:

  -------------------------------------------------------
  | Axiom commands ...                                  |
  |  ______________________________________________     |
  | | ) -> integrate(sin x, x)                     |^|  |
  | | ) -> D(%, x)                                 | |  |
  | |______________________________________________|v|  |
  |                                        [execute]    |
  |=====================================================|
  | Axiom output ...                                    |
  |                                                     |
  |  (1)  -cos(x)                                       |
  |                Type: Union(Expression Integer ... ) |
  |                                                     |
  |  (2)  sin (x)                                       |
  |                            Type: Expression Integer |
  |                                                     |
  -------------------------------------------------------

The first part is an HTML form with a text input field and
a button labelled [Execute]. The second part contains the
output generated by AXIOIMsys.

More complicated page layouts are possible but limitations
in the way HTTP/HTML works does constrain the design to
essentially "simplex" (one-way at a time) kind of
interactions.

> Check out FAQ 19 to figure out how to get the output in
> a single line.

Thanks but I am not sure if this is relevant.

> Oh, yeah, and remember to use AXIOMsys rather than axiom
> as the command.

Yes. Graphics is another issue. I would like to be able
to have Axiom graphics generate VRML (OpenInventor) output
for display in the browser.

\start
Date: Fri, 20 May 2005 17:14:04 -0500
From: Tim Daly
To: Bill Page
Subject: lisp talk

Bill,

There is an embedded command server within AXIOMsys. Look at:
http://daly.axiom-developer.org/TimothyDaly_files/lisptalk/pages/lisp35.html

Also, there is some way to do input because the axiom browser already
feeds expressions to AXIOMsys thru a socket. 

The string output function mentioned in FAQ 19 is a linear form of
the output. However Axiom's native output machinery is called
CHARYBDIS which was a research project from the 60s with the goal
of printing mathematics on typewriters. Axiom still uses that code.

\start
Date: Fri, 20 May 2005 22:38:49 -0400
From: Bill Page
To: Tim Daly
Subject: RE: lisp talk

On May 20, 2005 6:14 PM Tim Daly wrote:

> There is an embedded command server within AXIOMsys.
> Look at:
>
http://daly.axiom-developer.org/TimothyDaly_files/lisptalk/pages/lisp35.
html
>

Thanks, Tim. I believe that 

  parseAndInterpret stringBuf

is what I was looking for.

Now, this is boot language code, right? So in lisp I have
to tack on the | | onto the function name and then I can
call it like this:

  (1) -> )lisp (|parseAndInterpret| "integrate(sin x,x)")

   (1)  - cos(x)
                          Type: Union(Expression Integer,...)

  Value = ((|Union| (|Expression| (|Integer|)) (|List| (|Expression|
(|Integer|)))
  ) WRAPPED 0 (1 #<vector 10ccde54> (1 0 . -1)) 0 . 1)

  (2) ->

and sure enough! Axiom parses and interprets the string.
Great.

I presume that there is no reason why this would not work
when called directly from a lisp function, right? In my
scheme this string would be passed to Axiom by the http
webserver code.

But the result appears as stdout and the value returned
seems to contain the type information. (What is this WRAPPED
stuff?)

> Also, there is some way to do input because the axiom browser
> already feeds expressions to AXIOMsys thru a socket. 

Yes, input seems to be no problem.

> The string output function mentioned in FAQ 19 is a linear
> form of the output. However Axiom's native output machinery
> is called CHARYBDIS which was a research project from the
> 60s with the goal of printing mathematics on typewriters.
> Axiom still uses that code.

What I really would like is to see the result also returned
in the value. I would like to see the output in the form
of say, a list of strings. So the returned value in the
example above would be something like this

  Value = (("- cos(x)" "Type: Union(Expression Integer,...)")
   ((|Union| (|Expression| (|Integer|)) (|List| (|Expression|
(|Integer|)))
   ) WRAPPED 0 (1 #<vector 10ccde54> (1 0 . -1)) 0 . 1)
  )

In other words I guess I need the ouput of CHARYBDIS in the
form of a list of strings instead of in the output stream
(and later the LaTeX output and the openmath output). Can
you think of anywhere in Axiom where something like this is
already done?

\start
Date: Sat, 21 May 2005 09:03:20 -0500
From: Tim Daly
To: Bill Page
Subject: string input

Bill,

The WRAPPED output is the lisp data structure. 
It's too complex to explain here.

>I presume that there is no reason why this would not work
>when called directly from a lisp function, right?

Well, )lisp is actually just a lisp call. Nothing gets in the way.
That's why you get the "VALUE" output. You called a lisp function.
You could write:

)lisp (progn (|parseAndInterpret| "1+1") nil)

and get a NIL return value.

>What I really would like is to see the result also returned 
>in the value.

The result is returned in the value. The question is interpretation.
The lisp-level algebra is all data structures and embedded function
references. #<vector 10ccde54> is likely the "Union" infovec.

If you look at, say, int/algebra/CYCLES.NRLIB/code.lsp you'll see
the actual lisp code for the algebra. At the bottom of the file is
a very large data structure, called the "infovec", which is used
to look up references. This data structure is used throughout the
lisp code in the CYCLES domain. In the lisp code you'll see a lot
of "(QREFELT $ 73)" function calls. These are domain lookups in
the infovec. When it is read into memory the infovec is a vector
and looks like "#<vector a3b4c5d6>" in lisp output (where a3b4c5d6
is the hex address of the vector). "$" is the name of the vector
(and the name of the domain, a reference to "self") in the lisp code.
So (QREFELT $ 73) is a "quick vector reference" (actually, an 
optimized macro call I wrote. See src/interp/vmlisp.lisp.pamphlet)
to "self" for element 73 of the vector, that is, (elt "self" 73)

Since the infovec vector does not have a lisp name there is no
possible way to print it other than as hex. The CYCLES domain knows
what it is using, of couse, so the algebra print routine knows what to
print but lisp does not.

The best I can suggest is to  use the latex output. Since the
output isn't really a linear object there is no linear syntax.
You could invent a linear syntax but Knuth already did.

\start
Date: Sat, 21 May 2005 12:56:51 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#136 cercion of power series] some correction

-I will give some hint to understand this. First here is the actions that you have to do for a better understanding of this bug.
-Here the interpreter has to coerce the series (EXPR (INT OR OTHER)), the variable  and the expansion point in type.
  - This process of coercion involves probably some invalid type.

I will give some hint to understand this.
Here the interpreter has to coerce the series (EXPR (INT OR OTHER)), the variable  and the expansion point.

??changed:
-Now you can create power series integer::
Now you can create power series:

??changed:
-You will see that axiom in this process do not coerce all type (for example sometimes 0.0 (expansion point) remain Integer but of type EXPR FLOAT).
You will see that axiom in this process does not coerce all types (for example sometimes 0 (expansion point) remain Integer but of type EXPR FLOAT).

??changed:
-  x in type is of type Symbol
-  0.0 (expansion point is of type Expression (type of internal representation of the power series). For example: EXPR FLOAT.
  x in displayed type is of type Symbol
  0.0 (expansion point) has  the same type as the coefficients of the power series. For example: EXPR FLOAT.

??changed:
-Second, I add two other tests: I check the equality of the Symbol(s) and the two expansion points.
-Test it, check it, enhance it.
Second, I add two other tests: I check the equality of the Symbol(s) and the two expansion points (two different symbols crash axiom for example). 

\start
Date: Sat, 21 May 2005 17:12:14 -0400
From: Bill Page
To: Tim Daly
Subject: RE: string input

On May 21, 2005 10:03 AM Tim Daly wrote:

> Well, )lisp is actually just a lisp call. Nothing gets in
> the way. That's why you get the "VALUE" output. You called
> a lisp function. You could write:
>
> )lisp (progn (|parseAndInterpret| "1+1") nil)
>
> and get a NIL return value.

Yes, that is clear. But what I want is the CHARYBDIS
output returned as a list of strings, i.e. literally and
exactly what the print routines display. But instead I want
it as a series of strings representing the separate lines
of output.

> >What I really would like is to see the result also
> >returned in the value.
>
> The result is returned in the value. The question is
> interpretation. The lisp-level algebra is all data
> structures and embedded function references. #<vector 10ccde54>
> is likely the "Union" infovec.

What I see is only the type of the result. I don't
see anything that looks like it encodes

  "- cos(x)"

in my original example. But again, I am not really
interested in the encoding of the algebra. I only want
the text presentation of the result as I presume is
created by what you called CHARYBDIS.

> ...
> The best I can suggest is to  use the latex output.
> Since the output isn't really a linear object there
> is no linear syntax. You could invent a linear syntax
> but Knuth already did.

I am not really interested in a linear syntax. (Although
latex output is interesting for a different purpose, later
on.) All I want right now is a line-by-line list of strings
of the text representation. If I took this list of strings
and print them in sequence, the result should look exactly
what I see as a result of Axioms's command

  )set output algebra

But I want this a a set of strings because I need to send
it back down the http session stream in response to http
input.

\start
Date: Sat, 21 May 2005 20:12:59 -0400
From: William Sit
To: Bill Page
Subject: re: string input

Bill:

Try:

(8) -> )lisp (|parseAndInterpret| "integrate(sin(x),x)::OutputForm")

   (8)  - cos(x)
                                                             Type: OutputForm
Value = ((|OutputForm|) WRAPPED "-" (|cos| |x|))


\start
Date: Sat, 21 May 2005 20:39:32 -0400
From: William Sit
To: Bill Page, Tim Daly
Subject: re: string input

Bill:

And you can get LaTex output string:

(16) -> )lisp (|parseAndInterpret| "integrate(sin(x),x)::TexFormat::OutputForm")


   (16)  ["$$","-{\cos ","\left(","{x} ","\right)}","$$"]
                                                             Type: OutputForm
Value = ((|OutputForm|) WRAPPED BRACKET (AGGLST "\"$$\"" "\"-{\\cos \""
"\"\\left(\"" "\"{x} \"" "\"\\right)}\"" "\"$$\""))

\start
Date: Sat, 21 May 2005 21:23:39 -0400
From: William Sit
To: Bill Page, Tim Daly
Subject: re: string input

William Sit wrote:
> 
> Bill:
> 
> And you can get LaTex output string:
> 
> (16) -> )lisp (|parseAndInterpret| "integrate(sin(x),x)::TexFormat::OutputForm")
> 
>    (16)  ["$$","-{\cos ","\left(","{x} ","\right)}","$$"]
>                                                              Type: OutputForm
> Value = ((|OutputForm|) WRAPPED BRACKET (AGGLST "\"$$\"" "\"-{\\cos \""
> "\"\\left(\"" "\"{x} \"" "\"\\right)}\"" "\"$$\""))

A better way for TeX output:

(18) -> )lisp (|parseAndInterpret| "tex(integrate(sin(x),x)::TexFormat)")

   (18)  ["-{\cos \left( {x} \right)}"]
                                                            Type: List String
Value = ((|List| (|String|)) WRAPPED "-{\\cos \\left( {x} \\right)}")

\start
Date: Sat, 21 May 2005 22:00:16 -0400
From: William Sit
To: Bill Page
Subject: re: string input

Hi Bill:

You wrote:
> I am not really interested in a linear syntax. (Although
> latex output is interesting for a different purpose, later
> on.) All I want right now is a line-by-line list of strings
> of the text representation. If I took this list of strings
> and print them in sequence, the result should look exactly
> what I see as a result of Axioms's command
> 
>   )set output algebra

and I wrote:

> Try:
> 
> (8) -> )lisp (|parseAndInterpret| "integrate(sin(x),x)::OutputForm")
> 
>    (8)  - cos(x)
>                                                              Type: OutputForm
> Value = ((|OutputForm|) WRAPPED "-" (|cos| |x|))

I now realize that does not do what you want, for multiline output. For example:

(26) -> )lisp (|parseAndInterpret| "expand((1+x)^10)::OutputForm")

   (26)
    10      9      8       7       6       5       4       3      2
   x   + 10x  + 45x  + 120x  + 210x  + 252x  + 210x  + 120x  + 45x  + 10x + 1
                                                             Type: OutputForm
Value = ((|OutputForm|) WRAPPED "+" ("+" ("+" ("+" ("+" ("+" ("+" ("+" ("+" ("+"
 ("**" |x| 10) ("*" 10 ("**" |x| 9))) ("*" 45 ("**" |x| 8))) ("*" 120 ("**" |x|
7))) ("*" 210 ("**" |x| 6))) ("*" 252 ("**" |x| 5))) ("*" 210 ("**" |x| 4))) ("*
" 120 ("**" |x| 3))) ("*" 45 ("**" |x| 2))) ("*" 10 |x|)) 1)

You want two lines:

    10      9      8       7       6       5       4       3      2

and 

   x   + 10x  + 45x  + 120x  + 210x  + 252x  + 210x  + 120x  + 45x  + 10x + 1

Back to the drawing board.

The print command in Axiom always returns void. Wouldn't that mean one has to
intercept the side-effect of printing? But that can happen anywhere in the code.
Right?
 
Would it be easy to write a Java script to parse the prefix lisp output string
in Value? This can then take care of the window width as well.

\start
Date: Sat, 21 May 2005 23:04:57 -0500
From: Tim Daly
To: Bill Page
Subject: output capture

Perhaps you could rebind the output stream?
I'm not sure if *standard-output* is used. But the idea is:

)lisp 
  (progn 
    ; we need a new output stream
    (setq tmpout (make-string-output-stream))
    ; we hold on to the regular output stream
    (setq save *standard-output*)
    ; we capture the regular output stream in our string-stream
    (setq *standard-output* tmpout)
    ; we generate output
    (|parseAndInterpret| "(x+1)^9")
    ; we get the output strings
    (setq result (get-output-stream-string tmpout))
    ; restore the regular output stream
    (setq *standard-output* save)
    ; and return the strings
    result)

There should be several lines written to tmpout and returned in result.
I'm not sure that axiom uses *standard-output* but the output stream
must exist somewhere. I'll look at the code tomorrow. Gotta get back
to packing.


\start
Date: Sun, 22 May 2005 00:44:28 -0400
From: Bill Page
To: Tim Daly
Subject: RE: capturing output strings

On May 22, 2005 12:35 AM Tim Daly wrote:

> ok, so who needs to pack? :-)

Ah, I thought so! :)

> Axiom's algebra gets output to a stream called
> |$algebraOutputStream| Thus you can get the output
> you want by:
>
> )set message autoload off
> )lisp (progn
>        (setq tmpout (make-string-output-stream))
>        (setq save |$algebraOutputStream|)
>        (setq |$algebraOutputStream| tmpout)
>        (|parseAndInterpret| "(x+1)^9")
>        (setq result (get-output-stream-string |$algebraOutputStream|))
>        (setq |$algebraOutputStream| save)
>        result)
>
>)lisp result
>
>result contains the output from axiom that you want.

Yes, excellent! It works also on Windows. That's exactly what
I wanted.

Now, I can sleep and you can pack... :)


\start
Date: Sun, 22 May 2005 00:39:18 -0400
From: Bill Page
To: Tim Daly
Subject: RE: output capture

On May 22, 2005 12:05 AM Tim Daly wrote:

> Perhaps you could rebind the output stream?
> I'm not sure if *standard-output* is used. But the idea
> is:
>
>)lisp 
>  (progn 
>    ; we need a new output stream
>    (setq tmpout (make-string-output-stream))
>    ; we hold on to the regular output stream
>    (setq save *standard-output*)
>    ; we capture the regular output stream in our string-stream
>    (setq *standard-output* tmpout)
>    ; we generate output
>    (|parseAndInterpret| "(x+1)^9")
>    ; we get the output strings
>    (setq result (get-output-stream-string tmpout))
>    ; restore the regular output stream
>    (setq *standard-output* save)
>    ; and return the strings
>    result)

Yes, that seems like a very good approach.

> There should be several lines written to tmpout and returned
> in result. I'm not sure that axiom uses *standard-output* but
> the output stream must exist somewhere.

Apparently it does not use *standard-output* as the following
example shows :(

(1) -> )lisp (progn (setq tmpout (make-string-output-stream)) (setq save
*standa
rd-output*) (setq *standard-output* tmpout) (|parseAndInterpret|
"(x+1)^9") (set
q result (get-output-stream-string tmpout)) (setq *standard-output*
save) result
)
   Loading c:/Program Files/axiom/mnt/windows/algebra/UPMP.o for
      package UnivariatePolynomialMultiplicationPackage

         9     8      7      6       5       4      3      2
   (1)  x  + 9x  + 36x  + 84x  + 126x  + 126x  + 84x  + 36x  + 9x + 1
                                              Type: Polynomial Integer

Value = ""

(2) ->

But it was certainly a good try!

> I'll look at the code tomorrow. Gotta get back to packing.

Thanks. If you are like me, I am sure that almost any excuse
could distract you from that sort of job! :) I hate packing...

\start
Date: Sat, 21 May 2005 23:43:33 -0500
From: Tim Daly
To: Bill Page
Subject: capturing output strings

In fact, I'll write a "string i/o function" that takes a string as
input and returns the string as output. You aren't the first person
to need this. I'll try to get it into the next patch (patch-38).

\start
Date: Sat, 21 May 2005 23:34:53 -0500
From: Tim Daly
To: Bill Page
Subject: capturing output strings

ok, so who needs to pack? :-)

Axiom's algebra gets output to a stream called |$algebraOutputStream|
Thus you can get the output you want by:

)set message autoload off
)lisp (progn
        (setq tmpout (make-string-output-stream))
        (setq save |$algebraOutputStream|)
        (setq |$algebraOutputStream| tmpout)
        (|parseAndInterpret| "(x+1)^9")
        (setq result (get-output-stream-string |$algebraOutputStream|))
        (setq |$algebraOutputStream| save)
        result)

)lisp result

result contains the output from axiom that you want.


\start
Date: Sun, 22 May 2005 00:25:19 -0400
From: Bill Page
To: William Sit
Subject: re: string input

On May 21, 2005 10:00 PM William Sit wrote:

> ...
> For example:
>
>(26) -> )lisp (|parseAndInterpret| "expand((1+x)^10)::OutputForm")
>
>   (26)
>    10      9      8       7       6       5       4       3      2
>   x   + 10x  + 45x  + 120x  + 210x  + 252x  + 210x  + 120x  + 45x  +
10x + 1
>                                                             Type:
OutputForm
> ...
> You want two lines:
>
>    10      9      8       7       6       5       4       3      2
>
> and 
>
>   x   + 10x  + 45x  + 120x  + 210x  + 252x  + 210x  + 120x  + 45x  +
10x + 1

Yes, that's it exactly.

> Back to the drawing board.
>
> The print command in Axiom always returns void. Wouldn't that
> mean one has to intercept the side-effect of printing? But that
> can happen anywhere in the code. Right?

Well I am assuming (without checking deeply in the code) that
although creating the OutputForm is distributed throughout
the algebra code, rendering of the OutputForm as 2-dimensional
text by this thing called CHARYBDIS, is likely done in only one
place. My hope is that the 2-d array of characters is available
internally in it's entirety, before it is sent to stdout, line-
by-line. This is what I need to send to the http stream, along
with other things required by the hypertext protocol.
 
> Would it be easy to write a Java script to parse the prefix
> lisp output string in Value? This can then take care of the
> window width as well.

Well yes, I like your approach to returning latex output.

> A better way for TeX output:
>
>(18) -> )lisp (|parseAndInterpret|
"tex(integrate(sin(x),x)::TexFormat)")
>
>   (18)  ["-{\cos \left( {x} \right)}"]
>                                               Type: List String
> Value = ((|List| (|String|)) WRAPPED "-{\\cos \\left( {x} \\right)}")

I think I can use that in at least a limited way, although it
would be nicer if I did not have to wrap the command in
  tex( ... ::TexFormat)
and even better if this would work for multi-line input
of the sort one can process by

  )read file.input

But I don't think that using Java script in the browser to
parse the "prefix lisp output string" would be that practical.
As I understand it that would amount to re-implementing
CHARYBDIS on the browser side in java which is beyond the
level of effort that I was hoping for. If one was to attempt
something on this scale, I think it would be better to go
directly to MathML based on the prior NAG work on openmath.
Or as an interim approach, via LaTeX code, calling latex and
dvipng as external program to obtain a graphic result.

\start
Date: Sun, 22 May 2005 00:04:34 -0500
From: Tim Daly
To: Camm Maguire
Subject: capturing output strings

this seems to fail:

axiom

-> )lisp (setq result (make-array '(0) :element-type 'base-char :fill-pointer 0 :adjustable t))

Value = #<vector 0894bde4>

-> )lisp (with-output-to-string (|$algebraOutputStream| result) (|parseAndInterpret| "(x+1)^9"))

  >> System error:
  #<vector 0894bde4> is not a string with a fill-pointer

This appears to be a bug as result certainly has a fill pointer.


This is an attempt to capture the output sent to the 
stream |$algebraOutputStream| in some more elegant form 
(instead of this kludge):

)lisp (progn
          ; we need a new output stream backed by a string
        (setq tmpout (make-string-output-stream))
          ; we hold on to the regular algebra output stream
        (setq save |$algebraOutputStream|)
          ; we capture the regular output into our string stream
        (setq |$algebraOutputStream| tmpout)
          ; we generate output
        (|parseAndInterpret| "(x+1)^9")
          ; we get the results from the algebra output stream
        (setq result (get-output-stream-string |$algebraOutputStream|))
          ; we restore the regular algebra output stream
        (setq |$algebraOutputStream| save)
          ; and return the result
        result)

\start
Date: Sun, 22 May 2005 00:47:32 -0500
From: Tim Daly
To: list
Subject: MATLAB programming wiki

MATLAB appears to have a wiki which sponsors programming contests:

http://www.mathworks.com/contest/ants/home.html

The most interesting property seems to be that they get better 
algorithms if everyone collaborates on the wiki.

Perhaps we should borrow this idea and highlight the algorithm
of the month on the axiom wiki.

\start
Date: Sun, 22 May 2005 09:22:04 -0500
From: MathAction (unknown)
To: MathAction
Subject: [#136 cercion of power series] Crash with this	patch

This patch doesn't check the equality of the expansion points and the symbols for different power series.
</br>
Example::

  a:=series(sin(x))
  b:=taylor(sin(x),x=2)
  a*b

\start
Date: Sun, 22 May 2005 09:51:09 -0500
From: Tim Daly
To: Francois Maltey
Subject: provisos

Francois,

In mupad it appears that solve returns a piecewise result which is impressive.
What happens if you continue to compute with this result? If you save the
piecewise result in a variable can you multiply it by another piecewise
result? Do they give all nine possible branches? Do they combine branches?

Axiom simply returns

           1
     [x= -----]
         a - 1

which ignores the issue entirely (a bad pun on "entire functions").

\start
Date: Sun, 22 May 2005 10:52:38 -0400
From: Bill Page
To: Tim Daly
Subject: RE: MATLAB programming wiki

On May 22, 2005 1:48 AM Tim Daly wrote:

> MATLAB appears to have a wiki which sponsors programming
> contests:
>
> http://www.mathworks.com/contest/ants/home.html
>
> The most interesting property seems to be that they get better 
> algorithms if everyone collaborates on the wiki.
>
> Perhaps we should borrow this idea and highlight the algorithm
> of the month on the axiom wiki.

I like this idea, but can we really make it fly? Certainly we
can advertise the winners and make some nice looking web pages
with photographs and all, but what can we offer as "prizes".
This is one of the delemma's of free open source software.
And that reminds me ...

I have been wondering whether it might be worthwhile to arrange
for some Axiom promotional "stuff":

  1) Axiom t-shirts
  2) Axiom hats
  3) Axiom coffee mugs

etc. like http://www.mozillastore.com

There are several web.coms that offer this sort of product but
typically the project only receives a small portion of the
profit. Of course a small portion is a lot more than nothing,
and given that donations to the Axiom Foundation have not
progressed at all beyond those of the initial "dedicated few",
I don't see any alternative when it comes to raising some funds
to promote Axiom.

\start
Date: Sun, 22 May 2005 10:20:14 -0500
From: Tim Daly
To: Bill Page
Subject: trinkets

Bill,

Actually I was not suggesting a contest as such but pointing out
that making code available thru the wiki leads to the "many eyes"
improvement. 

re: trinkets. When I joined CAISS I ordered mugs for the group
(mostly grad students who missed the dot.com trinket fad) from
giftmugs.com. They did a nice job on them. Not sure if they can
handle a picture like the 30-year horizon picture on my webpage
(daly.axiom-developer.org) but they can certainly handle the
the double-dotted AXIOM logo.

I'm not sure we could sell axiom trinkets. Who could possibly
want one?


\start
Date: Sun, 22 May 2005 18:01:38 +0200
From: Francois Maltey
To: Tim Daly
Subject: Re: provisos
Cc: Francois Maltey

Tim, 

> In mupad it appears that solve returns a piecewise result 
> which is impressive.

> What happens if you continue to compute with this result? 
The piecewise is distributive : 

>> res := solve (a^2*x+a=x+1, x)
           / { - a + 1 }                                                \
  piecewise| { ------- } if not a in {-1, 1}, C_ if a = 1, {} if a = -1 |
           | {   2     }                                                |
           \ {  a  - 1 }                                                /
>> solve (a^2*x+a=x+1, x) + 2
         / { - a + 1     }                                                \
piecewise| { ------- + 2 } if not a in {-1, 1}, C_ if a = 1, {} if a = -1 |
         | {   2         }                                                |
         \ {  a  - 1     }                                                /
>> normal (solve (a^2*x+a=x+1, x) + 2)
           / { 2 a + 1 }                                                \
  piecewise| { ------- } if not a in {-1, 1}, C_ if a = 1, {} if a = -1 |
           \ {  a + 1  }                                                /


> If you save the piecewise result in a variable can you multiply 
> it by another piecewise result? Yes

res * res ; res^2  // the previous calculus.

         / { / - a + 1     \2 }
piecewise| { | ------- + 2 |  } if a in C_ minus {-1, 1}, C_ if a = 1,
         | { |   2         |  }
         \ { \  a  - 1     /  }

                \
   {} if a = -1 |
                |
                /

>> res2 := (solve (b^2*x+b=x+1, x)) ; 
>> res+res2
         / { - a + 1   - b + 1     }
piecewise| { ------- + ------- + 2 } if
         | {   2         2         }
         \ {  a  - 1    b  - 1     }

   a <> -1 and a <> 1 and b <> -1 and b <> 1,

   C_ if b = 1 and a in C_ minus {-1, 1},

   {} if b = -1 and a in C_ minus {-1, 1},

   C_ if a = 1 and b in C_ minus {-1, 1}, C_ if a = 1 and b = 1,

   {} if a = 1 and b = -1, {} if a = -1 and b in C_ minus {-1, 1},

                                                   \
   {} if a = -1 and b = 1, {} if a = -1 and b = -1 |
                                                   |
                                                   /
res2 := (solve (b^2*x+b=x+1, x))
res * 0 isn't quite pretty :

>> 0*res
    piecewise({0} if a in C_ minus {-1, 1}, {0} if a = 1, {} if a = -1)

>> simplify (0*res)
     piecewise({0} if (a = 1 or a in C_ minus {-1, 1}), {} if a = -1)

> Do they give all nine possible branches? Do they combine branches?
Almost every time, but not pretty with the union of the same result.

In mupad and maple there is a set domain in order to compute over intervals.
(C_ minus {-1, 1}) union {1} is too hard, but some others are possibles :

If you want to test, the best way is to download mupad at www.mupad.de,

The linux version is free : 
you can do tests before register, 
and uses much more memory after free registration : 
a web-script with some questions.

there is a on-line version, an xmupad version.
you can also download mupacs on source-forge, a emacs mode for mupad, 
and I believe that texmacs can also run mupad. 

The source-code is in the lib.tar file, write in mupad language
(a pretty pascal language, but it's a functional language with domains)

The windows-light and the windows-pro version have the same algorithms.
The interface is stupid for the free windows-light : the easiest way is
to use an other editor and to cut/past between the mupad-window 
and the editor-window.

There are silly games with theses assume :
with numerical real values

\start
Date: Sun, 22 May 2005 18:11:31 +0200
From: Francois Maltey
To: Tim Daly
Subject: Re: axiom and emacs
Cc: Francois Maltey

I couldn't send data to axiom in emacs :

I find my error : axiom uses the TERM environment variable and in one
case this environment variable doesn't exist.

I add TERM=xterm in environment-process and now it's right.

BUT I have others questions :

Is it possible to enlarge the axiom output ?

Even in an very wide emacs and a environment variable to COLUMNS=130
the axiom output is 80 characters wide.

I don't fine very pretty the int output in ascii-art.
Can I change only the int output to int (exp(x^2), x), and remains
power in ascii art ?

\start
Date: Sun, 22 May 2005 11:25:16 -0500
From: Tim Daly
To: Francois Maltey
Subject: axiom and emacs

Francois,

Yes, the TERM variable is used in cursor.c and edin.c.

I'm not sure what you mean by "enlarge" the axiom output. This and
the comment about ascii art are related. Axiom uses CHARYBDIS-like
output which is output intended for a typewriter. Thus it uses the
current font and trivial characters in the font. You can choose to
output tex but you have to interpret the result using something 
that understands tex.

The column issue is easy to fix:

)set output length 130 

The range is from 10 to 245 inclusive. You can find the current
output length with:

)set output length

\start
Date: Sun, 22 May 2005 18:39:00 -0500
From: Tim Daly
To: Bill Page, Camm Maguire
Subject: ntxlib.zip

Bill, Camm,

It appears that there is a library ntxlib which is a dll that
translates x11 calls to the windows api. Here is the link:
http://paramvir_likhari.tripod.com/mcse/unix/unix2nt.htm

\start
Date: Mon, 23 May 2005 10:55:36 +1000
From: Mike Thomas
To: Tim Daly, Bill Page, Camm Maguire
Subject: RE: ntxlib.zip

Hi all.

Tim wrote:

| Bill, Camm,
|
| It appears that there is a library ntxlib which is a dll that
| translates x11 calls to the windows api. Here is the link:
| http://paramvir_likhari.tripod.com/mcse/unix/unix2nt.htm
|

This library has reared it's head on this forum more than once now - I have
studiously ignored those mentions for personal strategic reasons.  There are
at least three different versions available on the web as far as I know.

At risk of being a wet blanket I can say that this path (which I, Malcolm
Blue, Glynn Clements and others took to build a graphics server for GRASS
several years ago) is not as easy as it sounds.

We tweaked and poked and prodded and added new bits and the server based on
that library worked quite well, up to a point, but the library offered
incomplete Xlib coverage and was a continual source of problems whenever
anyone added something new to the server; that is, there was always more
work to be done.

This path would be profitable if someone knowledgable in both Xlib and Win32
GDI choose to take the library under their wing and run with it as their
personal pet project (as we originally planned), but in reality we all
preferred to work on other stuff and ultimately (in the case of GRASS) I
think it would have been easier to write from scratch a special Win32 API
version of the GRASS graphics server.

And yes, I did try to use the improved version of that library with the GCL
Xlib binding a couple of years ago (and several very simple Xlib C examples)
and gave up for half forgotten reasons - crashes, incomplete semantics and
available functions etc.

For that special someone willing to take on that library, here is the
improved GRASS source tree version:

  http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/display/devices/windows/

\start
Date: Sun, 22 May 2005 21:44:48 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [mirrors] please provide details

I can not reproduce any problem with kongueror and Fedora 3.
Please tell me the exact sequence of steps that causes the
failure.

\start
Date: Mon, 23 May 2005 01:21:13 -0400
From: Bill Page
To: list
Subject: using jsMath on MathAction and Axiom browser

jsMath might be a good alternative to graphics for the
display of LaTeX, Axiom and Reduce output on the
MathAction wiki.

This might also be a good alternative to use with a
stand-alone browser interface to Axiom.

http://www.math.union.edu/~dpvc/jsMath

The jsMath package provides a method of including mathematics
in HTML pages that works across multiple browsers for both
Windows and the Macintosh. It overcomes a number of the
shortcomings of the traditional method of using images to
represent mathematics: jsMath uses native fonts, so they
resize when you change the size of the text in your browser,
they print at the full resolution of your printer, and you don't
have to wait for dozens of images to be downloaded in order to
see the mathematics in a web page. There are also advantages
for web-page authors, as there is no need to preprocess your
web pages to generate any images, and the mathematics is
entered in TeX form, so it is easy to create and maintain your
web pages.

For example:

http://moodle.org/ Moodle (course management software) uses jsMath

http://webwork.math.rochester.edu/ WebWork (Twiki-based) uses jsMath

\start
Date: Mon, 23 May 2005 13:37:55 -0500
From: MathAction (billpage)
To: MathAction
Subject: [LaTeX] 


++added:

jsMath

  http://www.math.union.edu/~dpvc/jsMath

jsMath might be a good alternative to graphics for the
display of LaTeX, Axiom and Reduce output on the MathAction
wiki.

See for example
"jsMathExperiment":http://page.axiom-developer.org/zope/mathaction/jsMathExperiment
which contains some output generated by Axiom.

This might also be a good alternative to use with a
stand-alone browser interface to Axiom.

The jsMath package provides a method of including mathematics
in HTML pages that works across multiple browsers for both
Windows and the Macintosh. It overcomes a number of the
shortcomings of the traditional method of using images to
represent mathematics: jsMath uses native fonts, so they
resize when you change the size of the text in your browser,
they print at the full resolution of your printer, and you don't
have to wait for dozens of images to be downloaded in order to
see the mathematics in a web page. There are also advantages
for web-page authors, as there is no need to preprocess your
web pages to generate any images, and the mathematics is
entered in TeX form, so it is easy to create and maintain your
web pages.

For example:

http://moodle.org/ Moodle (course management software) uses jsMath

http://webwork.math.rochester.edu/ WebWork (Twiki-based) uses jsMath

\start
Date: 23 May 2005 14:35:18 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: capturing output strings

Greetings!

This is an ANSI issue -- traditionally, GCL has used element-type
'string-char for strings, but this type was dropped by the ansi
committee.  We'll clear it up soon hopefully, but for now you can just
replace 'base-char with 'string-char and it will work.

Take care,

Tim Daly writes:

> this seems to fail:
> 
> axiom
> 
> -> )lisp (setq result (make-array '(0) :element-type 'base-char :fill-pointer 0 :adjustable t))
> 
> Value = #<vector 0894bde4>
> 
> -> )lisp (with-output-to-string (|$algebraOutputStream| result) (|parseAndInterpret| "(x+1)^9"))
> 
>   >> System error:
>   #<vector 0894bde4> is not a string with a fill-pointer
> 
> This appears to be a bug as result certainly has a fill pointer.
> 
> 
> This is an attempt to capture the output sent to the 
> stream |$algebraOutputStream| in some more elegant form 
> (instead of this kludge):
> 
> )lisp (progn
>           ; we need a new output stream backed by a string
>         (setq tmpout (make-string-output-stream))
>           ; we hold on to the regular algebra output stream
>         (setq save |$algebraOutputStream|)
>           ; we capture the regular output into our string stream
>         (setq |$algebraOutputStream| tmpout)
>           ; we generate output
>         (|parseAndInterpret| "(x+1)^9")
>           ; we get the results from the algebra output stream
>         (setq result (get-output-stream-string |$algebraOutputStream|))
>           ; we restore the regular algebra output stream
>         (setq |$algebraOutputStream| save)
>           ; and return the result
>         result)
> 

\start
Date: Tue, 24 May 2005 11:08:47 -0400
From: Kostas Oikonomou
To: list
Subject: opinion


In reading this list, I am impressed by the amount of volunteer effort
that is going into making a *free* system like Axiom work on a closed
(and, in my opinion, closed-minded) system like Windows.

I know of two instances of commercial companies that make their
products essentially free on more-or-less free platforms, but charge
for Windows: Trolltech with Qt, and SciFace with MuPad.

\start
Date: Tue, 24 May 2005 12:55:09 -0500
From: MathAction (unknown)
To: MathAction
Subject: [LaTeX] Konqueror 3.3.1-4.8.FC3

On up-to-date Fedora Core 3 (x86-64) with the ttf math fonts
installed, Konqueror 3.3.1-4.3.FC3 displays the in-line
(&lt;span&gt;...&lt;/span&gt;) overlapped with the text. The display
of the axiom output in (&lt;div&gt;...&lt;div&gt;) is ok, but it is not
centered as it is with FireFox. Firefox 1.0.4 on both Windows
XP and linux displays this correctly. IE 6 sp2 on Windows XP
also works fine.

\start
Date: Tue, 24 May 2005 13:56:31 -0500
From: MathAction (Bob McElrath)
To: MathAction
Subject: [LaTeX] jsMath

This guy is way better at javascript and tex than me...

Couple comments on jsMath: http://www.math.union.edu/~dpvc/jsMath/

You are correct it doesn't work in Konqueror.

I gotta say I like this solution.  Putting the tex font metrics into the
javascript is very clever.  However he has the same problem I had in
identifying the font from javascript (i.e. you can't).  He looks at the
cmex10 font and checks if it is much taller than it is wide.  (This font
contains large parenthesis, for example)  Not 100% reliable, but
workable.  However using tex fonts one really needs to crank the font
size up so that the characters come out correctly.  For instance, $f(z)$
looks like $f(\approx)$ using their default font size.  Of course this
is easy to do on one's site.

Also since the rendering is done in javascript it is slow compared to
the native mozilla rendering speed.  I wonder if there is a way to get
it to render everything first, to prevent excessive reflows of the
document as it renders piece-by-piece.

The only drawback I can see other than speed is that it is not "true"
latex...for example he's got a \color extension, but no \usepackage...
or preamble of any kind.  So it's not appropriate for en masse
translation of an existing tex document.

But maybe very appropriate for a wiki...

\start
Date: Tue, 24 May 2005 14:06:07 -0500
From: MathAction (Bob McElrath)
To: MathAction
Subject: [LaTeX] Konqueror 3.3.1-4.8.FC3

With jsMath & Konqueror 3.3.2 (debian):

1. equations are not centered horizontally

2. certain characters are not appearing correctly (e.g. $x$ and the
    large left square bracket).  Both appear as a dot above the center
    line.

Other than that the output is almost correct.

\start
Date: Tue, 24 May 2005 21:47:59 +0200
From: Francois Maltey
To: list, axiom-mail@nongnu.org
Subject: empty line in an axiom pipe.

Hello,

I try to write a emacs-mode for running axiom.

I can start axiom, read the output and send ONE commandline.

This is the minimal 3 lines to put in a new buffer as *Axiom* buffer :

(setenv "TERM" "xterm")
(setq axiomRun-process
  (start-process "axiom" (current-buffer) "axiom" "-noht"))

Then eval this command in emacs, with ^X^E

(process-send-string axiomRun-process "123+456\n")

it's right.

You can send a lot of computation of one line,
but wait the end of the axiom-computation !

If you add a "-noclef" after "-noht", the display is cleaner,
but it isnot the problem.

I get a problem when I send 2 or more \n.

When I send one empty-line with this command,
axiom doesn't seem to understand.

(process-send-string axiomRun-process "123+456\n\n")
(process-send-string axiomRun-process "123*456\n")

After this error, I must send two commands if I want to get one reponse.
And the reponse is the reponse of the previous command, not the reponse
of this command.
The error is the same with the underscore _ end-line.

What is the normal use of axiom command-line ?

Thanks a lot for your help !


My log-file is this one, I replace ^H and ^M to ascii 2 chars.
----------------------------------------------------------------
(setenv "TERM" "xterm")
(setq axiomRun-process
  (start-process "axiom" (current-buffer) "axiom" "-noht"))
; I evaluate this two lines buffer with M-x eval-buffer
;
;
GCL (GNU Common Lisp)  2.6.6 CLtL1    Jan 18 2005 00:13:38
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
                        AXIOM Computer Algebra System
                   Version: Axiom 3.0 Beta (February 2005)
              Timestamp: Monday February 21, 2005 at 20:01:15
---------------------------------------------------------------------------=
--
   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) ->
;
;
; then run this with C-x C-e at the end of the next line
;
(process-send-string axiomRun-process "123+456\n")
;
; the result appears before this lisp-line, I move it after.

(1) -> 123+456^H^H^H^H^H^H^H^M(1) -> ^M
   (1)  579
                                                        Type: PositiveInteg=
er
;
; I can do a lot of calculs so.
; But when I send a 2 lines command axiom become silly :
;
(process-send-string axiomRun-process "123+456\n\n")
;
(2) -> 123+456^H^H^H^H^H^H^H^M(2) -> ^M
   (2)  579
                                                        Type: PositiveInteg=
er

(process-send-string axiomRun-process "12+56\n")
(process-send-string axiomRun-process "12+56\n")
(process-send-string axiomRun-process "12+56\n")
(process-send-string axiomRun-process "12+5\n")

;
; The command line redisplayed isn't the result : so 12+5=68.
;

(3) -> 12+56^H^H^H^H^H^M(3) -> ^M(3) -> 12+56^H^H^H^H^H^M(3) -> ^M
   (3)  68
                                                        Type: PositiveInteg=
er
(4) -> 12+56^H^H^H^H^H^M(4) -> ^M
   (4)  68
                                                        Type: PositiveInteg=
er
(5) -> 12+5^H^H^H^H^M(5) -> ^M
   (5)  68
                                                        Type: PositiveInte
\start
Date: Tue, 24 May 2005 15:58:01 -0500
From: MathAction (Francois Maltey)
To: MathAction
Subject: [Axiom-mail] empty line in an axiom pipe.

Hello, 

I try to write a emacs-mode for running axiom.

I can start axiom, read the output and send ONE commandline.

This is the minimal 3 lines to put in a new buffer as *Axiom* buffer :

(setenv "TERM" "xterm")
(setq axiomRun-process 
  (start-process "axiom" (current-buffer) "axiom" "-noht"))

Then eval this command in emacs, with ^X^E

(process-send-string axiomRun-process "123+456\n")

it's right.

You can send a lot of computation of one line, 
but wait the end of the axiom-computation !

If you add a "-noclef" after "-noht", the display is cleaner,  
but it isnot the problem.

I get a problem when I send 2 or more \n.

When I send one empty-line with this command, 
axiom doesn't seem to understand.

(process-send-string axiomRun-process "123+456\n\n")
(process-send-string axiomRun-process "123*456\n")

After this error, I must send two commands if I want to get one reponse.
And the reponse is the reponse of the previous command, not the reponse 
of this command.
The error is the same with the underscore _ end-line.

What is the normal use of axiom command-line ?

Thanks a lot for your help !

Franois

My log-file is this one, I replace ^H and ^M to ascii 2 chars.
----------------------------------------------------------------
(setenv "TERM" "xterm") 
(setq axiomRun-process 
  (start-process "axiom" (current-buffer) "axiom" "-noht"))
; I evaluate this two lines buffer with M-x eval-buffer
;
;
GCL (GNU Common Lisp)  2.6.6 CLtL1    Jan 18 2005 00:13:38
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
                        AXIOM Computer Algebra System 
                   Version: Axiom 3.0 Beta (February 2005)
              Timestamp: Monday February 21, 2005 at 20:01:15 
-----------------------------------------------------------------------------
   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) -> 
;
; 
; then run this with C-x C-e at the end of the next line
;
(process-send-string axiomRun-process "123+456\n")
;
; the result appears before this lisp-line, I move it after.

(1) -> 123+456^H^H^H^H^H^H^H^M(1) -> ^M
   (1)  579
                                                        Type: PositiveInteger
;
; I can do a lot of calculs so.
; But when I send a 2 lines command axiom become silly :
;  
(process-send-string axiomRun-process "123+456\n\n")
;
(2) -> 123+456^H^H^H^H^H^H^H^M(2) -> ^M
   (2)  579
                                                        Type: PositiveInteger

(process-send-string axiomRun-process "12+56\n")
(process-send-string axiomRun-process "12+56\n")
(process-send-string axiomRun-process "12+56\n")
(process-send-string axiomRun-process "12+5\n")

;
; The command line redisplayed isn't the result : so 12+5=68.
;

(3) -> 12+56^H^H^H^H^H^M(3) -> ^M(3) -> 12+56^H^H^H^H^H^M(3) -> ^M
   (3)  68
                                                        Type: PositiveInteger
(4) -> 12+56^H^H^H^H^H^M(4) -> ^M
   (4)  68
                                                        Type: PositiveInteger
(5) -> 12+5^H^H^H^H^M(5) -> ^M
   (5)  68
                                                        Type: PositiveInte
\start
Date: Wed, 25 May 2005 00:59:46 +0200
From: Gregory Vanuxem
To: list
Subject: RE: [Axiom-mail] empty line in an axiom pipe.

Hi

Here is the output on windows and xemacs (3 times):

;;(setenv "TERM" "xterm")
(setq axiomRun-process
  (start-process "axiom" (current-buffer) "axiomsys"))                   =
      AXIOM Computer Algebra System
                 Version of Monday May 16, 2005 at 01:42:46
-------------------------------------------------------------------------=
----
   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) ->
   (1)  579
                                                        Type: =
PositiveInteger
(2) ->
   (2)  579
                                                        Type: =
PositiveInteger
(3) -> (3) ->
   (3)  56088
                                                        Type: =
PositiveInteger
(4) ->
   (4)  579
                                                        Type: =
PositiveInteger
(5) ->
   (5)  579
                                                        Type: =
PositiveInteger
(6) -> (6) ->
   (6)  56088
                                                        Type: =
PositiveInteger
(7) ->
   (7)  579
                                                        Type: =
PositiveInteger
(8) ->
   (8)  579
                                                        Type: =
PositiveInteger
(9) -> (9) ->
   (9)  56088
                                                        Type: =
PositiveInteger


I use AXIOMSys and no axiom,
May be this can help.

> -----Message d'origine-----
> De : axiom-developer-bounces+g.vanuxem=wanadoo.fr@nongnu.org
la
> part de Francois Maltey
> Envoy=C3=A9 : mardi 24 mai 2005 22:58
> =C3=80 : MathAction
> Objet : [Axiom-mail] empty line in an axiom pipe.
>
>
> Hello,
>
> I try to write a emacs-mode for running axiom.
>
> I can start axiom, read the output and send ONE commandline.
>
> This is the minimal 3 lines to put in a new buffer as *Axiom* buffer :
>
> (setenv "TERM" "xterm")
> (setq axiomRun-process
>   (start-process "axiom" (current-buffer) "axiom" "-noht"))
>
> Then eval this command in emacs, with ^X^E
>
> (process-send-string axiomRun-process "123+456\n")
>
> it's right.
>
> You can send a lot of computation of one line,
> but wait the end of the axiom-computation !
>
> If you add a "-noclef" after "-noht", the display is cleaner, 
> but it isnot the problem.
>
> I get a problem when I send 2 or more \n.
>
> When I send one empty-line with this command,
> axiom doesn't seem to understand.
>
> (process-send-string axiomRun-process "123+456\n\n")
> (process-send-string axiomRun-process "123*456\n")
>
> After this error, I must send two commands if I want to get one =
reponse.
> And the reponse is the reponse of the previous command, not the =
reponse
> of this command.
> The error is the same with the underscore _ end-line.
>
> What is the normal use of axiom command-line ?
>
> Thanks a lot for your help !
>
> Franois
>
> My log-file is this one, I replace ^H and ^M to ascii 2 chars.
> ----------------------------------------------------------------
> (setenv "TERM" "xterm")
> (setq axiomRun-process
>   (start-process "axiom" (current-buffer) "axiom" "-noht"))
> ; I evaluate this two lines buffer with M-x eval-buffer
> ;
> ;
> GCL (GNU Common Lisp)  2.6.6 CLtL1    Jan 18 2005 00:13:38
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible =
license
> Dedicated to the memory of W. Schelter
>
> Use (help) to get some basic information on how to use GCL.
>                         AXIOM Computer Algebra System
>                    Version: Axiom 3.0 Beta (February 2005)
>               Timestamp: Monday February 21, 2005 at 20:01:15
> ------------------------------------------------------------------
> -----------
>    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) ->
> ;
> ;
> ; then run this with C-x C-e at the end of the next line
> ;
> (process-send-string axiomRun-process "123+456\n")
> ;
> ; the result appears before this lisp-line, I move it after.
>
> (1) -> 123+456^H^H^H^H^H^H^H^M(1) -> ^M
>    (1)  579
>                                                         Type:
> PositiveInteger
> ;
> ; I can do a lot of calculs so.
> ; But when I send a 2 lines command axiom become silly :
> ; 
> (process-send-string axiomRun-process "123+456\n\n")
> ;
> (2) -> 123+456^H^H^H^H^H^H^H^M(2) -> ^M
>    (2)  579
>                                                         Type:
> PositiveInteger
>
> (process-send-string axiomRun-process "12+56\n")
> (process-send-string axiomRun-process "12+56\n")
> (process-send-string axiomRun-process "12+56\n")
> (process-send-string axiomRun-process "12+5\n")
>
> ;
> ; The command line redisplayed isn't the result : so 12+5=68.
> ;
>
> (3) -> 12+56^H^H^H^H^H^M(3) -> ^M(3) -> 12+56^H^H^H^H^H^M(3) -> ^M
>    (3)  68
>                                                         Type:
> PositiveInteger
> (4) -> 12+56^H^H^H^H^H^M(4) -> ^M
>    (4)  68
>                                                         Type:
> PositiveInteger
> (5) -> 12+5^H^H^H^H^M(5) -> ^M
>    (5)  68
>                                                         Type: =
PositiveInte
>

\start
Date: Tue, 24 May 2005 18:25:31 -0500
From: MathAction
To: MathAction
Subject: [Axiom-mail] [Axiom-mail] empty line in an axiom pipe.

Hi

Here is the output on windows and xemacs (3 times):

;;(setenv "TERM" "xterm")
(setq axiomRun-process 
  (start-process "axiom" (current-buffer) "axiomsys"))                         AXIOM Computer Algebra System 
                 Version of Monday May 16, 2005 at 01:42:46 
-----------------------------------------------------------------------------
   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) -> 
   (1)  579
                                                        Type: PositiveInteger
(2) -> 
   (2)  579
                                                        Type: PositiveInteger
(3) -> (3) -> 
   (3)  56088
                                                        Type: PositiveInteger
(4) -> 
   (4)  579
                                                        Type: PositiveInteger
(5) -> 
   (5)  579
                                                        Type: PositiveInteger
(6) -> (6) -> 
   (6)  56088
                                                        Type: PositiveInteger
(7) -> 
   (7)  579
                                                        Type: PositiveInteger
(8) -> 
   (8)  579
                                                        Type: PositiveInteger
(9) -> (9) -> 
   (9)  56088
                                                        Type: PositiveInteger


I use AXIOMSys and no axiom,
May be this can help.

> -----Message d'origine-----
> De : axiom-developer-bounces+g.vanuxem=wanadoo.fr@nongnu.org
> part de Francois Maltey
> Envoy : mardi 24 mai 2005 22:58
>  : MathAction
> Objet : [Axiom-mail] empty line in an axiom pipe.
> 
> 
> Hello, 
> 
> I try to write a emacs-mode for running axiom.
> 
> I can start axiom, read the output and send ONE commandline.
> 
> This is the minimal 3 lines to put in a new buffer as *Axiom* buffer :
> 
> (setenv "TERM" "xterm")
> (setq axiomRun-process 
>   (start-process "axiom" (current-buffer) "axiom" "-noht"))
> 
> Then eval this command in emacs, with ^X^E
> 
> (process-send-string axiomRun-process "123+456\n")
> 
> it's right.
> 
> You can send a lot of computation of one line, 
> but wait the end of the axiom-computation !
> 
> If you add a "-noclef" after "-noht", the display is cleaner,  
> but it isnot the problem.
> 
> I get a problem when I send 2 or more \n.
> 
> When I send one empty-line with this command, 
> axiom doesn't seem to understand.
> 
> (process-send-string axiomRun-process "123+456\n\n")
> (process-send-string axiomRun-process "123*456\n")
> 
> After this error, I must send two commands if I want to get one reponse.
> And the reponse is the reponse of the previous command, not the reponse 
> of this command.
> The error is the same with the underscore _ end-line.
> 
> What is the normal use of axiom command-line ?
> 
> Thanks a lot for your help !
> 
> Franois
> 
> My log-file is this one, I replace ^H and ^M to ascii 2 chars.
> ----------------------------------------------------------------
> (setenv "TERM" "xterm") 
> (setq axiomRun-process 
>   (start-process "axiom" (current-buffer) "axiom" "-noht"))
> ; I evaluate this two lines buffer with M-x eval-buffer
> ;
> ;
> GCL (GNU Common Lisp)  2.6.6 CLtL1    Jan 18 2005 00:13:38
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
>                         AXIOM Computer Algebra System 
>                    Version: Axiom 3.0 Beta (February 2005)
>               Timestamp: Monday February 21, 2005 at 20:01:15 
> ------------------------------------------------------------------
> -----------
>    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) -> 
> ;
> ; 
> ; then run this with C-x C-e at the end of the next line
> ;
> (process-send-string axiomRun-process "123+456\n")
> ;
> ; the result appears before this lisp-line, I move it after.
> 
> (1) -> 123+456^H^H^H^H^H^H^H^M(1) -> ^M
>    (1)  579
>                                                         Type: 
> PositiveInteger
> ;
> ; I can do a lot of calculs so.
> ; But when I send a 2 lines command axiom become silly :
> ;  
> (process-send-string axiomRun-process "123+456\n\n")
> ;
> (2) -> 123+456^H^H^H^H^H^H^H^M(2) -> ^M
>    (2)  579
>                                                         Type: 
> PositiveInteger
> 
> (process-send-string axiomRun-process "12+56\n")
> (process-send-string axiomRun-process "12+56\n")
> (process-send-string axiomRun-process "12+56\n")
> (process-send-string axiomRun-process "12+5\n")
> 
> ;
> ; The command line redisplayed isn't the result : so 12+5=68.
> ;
> 
> (3) -> 12+56^H^H^H^H^H^M(3) -> ^M(3) -> 12+56^H^H^H^H^H^M(3) -> ^M
>    (3)  68
>                                                         Type: 
> PositiveInteger
> (4) -> 12+56^H^H^H^H^H^M(4) -> ^M
>    (4)  68
>                                                         Type: 
> PositiveInteger
> (5) -> 12+5^H^H^H^H^M(5) -> ^M
>    (5)  68

\start
Date: Tue, 24 May 2005 18:09:34 -0400
From: Stephen Wilson
To: Francois Maltey
Subject: Re: empty line in an axiom pipe.

Francois,

About two yeas ago I wrote an emacs mode for aldor, its interpreter
and debugger.  I have thought it might serve as a basis for an axiom
mode at some point in the future.  I can send you the code if you are
interested.

Have you looked at the comint elisp library?  Briefly, It serves as
the glue for many modes which need to interact with a process in a
buffer.  For example, `M-x comint-run <ret> AXIOMsys' should give you
and axiom session in its own buffer with a command line history.
Since a `raw' comint session happily cooperates with axiom, I would
expect one would find it a good starting point in programming a
full-fledged axiom mode.  Take a look at comint.el in the emacs
sources.

On Tue, May 24, 2005 at 09:47:59PM +0200, Francois Maltey wrote:
> Hello,
>
> I try to write a emacs-mode for running axiom.
>
> I can start axiom, read the output and send ONE commandline.
>
> This is the minimal 3 lines to put in a new buffer as *Axiom* buffer :
>
> (setenv "TERM" "xterm")
> (setq axiomRun-process
>   (start-process "axiom" (current-buffer) "axiom" "-noht"))
>
> Then eval this command in emacs, with ^X^E
>
> (process-send-string axiomRun-process "123+456\n")
>
> it's right.
>
> You can send a lot of computation of one line,
> but wait the end of the axiom-computation !
>
> If you add a "-noclef" after "-noht", the display is cleaner, 
> but it isnot the problem.
>
> I get a problem when I send 2 or more \n.
>
> When I send one empty-line with this command,
> axiom doesn't seem to understand.
>
> (process-send-string axiomRun-process "123+456\n\n")
> (process-send-string axiomRun-process "123*456\n")
>
> After this error, I must send two commands if I want to get one reponse.
> And the reponse is the reponse of the previous command, not the reponse=

> of this command.
> The error is the same with the underscore _ end-line.
>
> What is the normal use of axiom command-line ?
>
> Thanks a lot for your help !
>
> Fran=E7ois
>
> My log-file is this one, I replace ^H and ^M to ascii 2 chars.
> ----------------------------------------------------------------
> (setenv "TERM" "xterm")
> (setq axiomRun-process
>   (start-process "axiom" (current-buffer) "axiom" "-noht"))
> ; I evaluate this two lines buffer with M-x eval-buffer
> ;
> ;
> GCL (GNU Common Lisp)  2.6.6 CLtL1    Jan 18 2005 00:13:38
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
>
> Use (help) to get some basic information on how to use GCL.
>                         AXIOM Computer Algebra System
>                    Version: Axiom 3.0 Beta (February 2005)
>               Timestamp: Monday February 21, 2005 at 20:01:15
> -----------------------------------------------------------------------=
------
>    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) ->
> ;
> ;
> ; then run this with C-x C-e at the end of the next line
> ;
> (process-send-string axiomRun-process "123+456\n")
> ;
> ; the result appears before this lisp-line, I move it after.
>
> (1) -> 123+456^H^H^H^H^H^H^H^M(1) -> ^M
>    (1)  579
>                                                         Type: PositiveI=
nteger
> ;
> ; I can do a lot of calculs so.
> ; But when I send a 2 lines command axiom become silly :
> ; 
> (process-send-string axiomRun-process "123+456\n\n")
> ;
> (2) -> 123+456^H^H^H^H^H^H^H^M(2) -> ^M
>    (2)  579
>                                                         Type: PositiveI=
nteger
>
> (process-send-string axiomRun-process "12+56\n")
> (process-send-string axiomRun-process "12+56\n")
> (process-send-string axiomRun-process "12+56\n")
> (process-send-string axiomRun-process "12+5\n")
>
> ;
> ; The command line redisplayed isn't the result : so 12+5=68.
> ;
>
> (3) -> 12+56^H^H^H^H^H^M(3) -> ^M(3) -> 12+56^H^H^H^H^H^M(3) -> ^M
>    (3)  68
>                                                         Type: PositiveI=
nteger
> (4) -> 12+56^H^H^H^H^H^M(4) -> ^M
>    (4)  68
>                                                         Type: PositiveI=
nteger
> (5) -> 12+5^H^H^H^H^M(5) -> ^M
>    (5)  68
>                                                         Type: PositiveI=
nte
>

\start
Date: Tue, 24 May 2005 19:59:44 -0500
From: MathAction (Stephen Wilson)
To: MathAction
Subject: Re: empty line in an axiom pipe.

Francois,

About two yeas ago I wrote an emacs mode for aldor, its interpreter
and debugger.  I have thought it might serve as a basis for an axiom
mode at some point in the future.  I can send you the code if you are
interested.

Have you looked at the comint elisp library?  Briefly, It serves as
the glue for many modes which need to interact with a process in a
buffer.  For example, `M-x comint-run <ret> AXIOMsys' should give you
and axiom session in its own buffer with a command line history.
Since a `raw' comint session happily cooperates with axiom, I would
expect one would find it a good starting point in programming a
full-fledged axiom mode.  Take a look at comint.el in the emacs
sources.

On Tue, May 24, 2005 at 09:47:59PM +0200, Francois Maltey wrote:
> Hello, 
> 
> I try to write a emacs-mode for running axiom.
> 
> I can start axiom, read the output and send ONE commandline.
> 
> This is the minimal 3 lines to put in a new buffer as *Axiom* buffer :
> 
> (setenv "TERM" "xterm")
> (setq axiomRun-process 
>   (start-process "axiom" (current-buffer) "axiom" "-noht"))
> 
> Then eval this command in emacs, with ^X^E
> 
> (process-send-string axiomRun-process "123+456\n")
> 
> it's right.
> 
> You can send a lot of computation of one line, 
> but wait the end of the axiom-computation !
> 
> If you add a "-noclef" after "-noht", the display is cleaner,  
> but it isnot the problem.
> 
> I get a problem when I send 2 or more \n.
> 
> When I send one empty-line with this command, 
> axiom doesn't seem to understand.
> 
> (process-send-string axiomRun-process "123+456\n\n")
> (process-send-string axiomRun-process "123*456\n")
> 
> After this error, I must send two commands if I want to get one reponse.
> And the reponse is the reponse of the previous command, not the reponse 
> of this command.
> The error is the same with the underscore _ end-line.
> 
> What is the normal use of axiom command-line ?
> 
> Thanks a lot for your help !
> 
> Franois
> 
> My log-file is this one, I replace ^H and ^M to ascii 2 chars.
> ----------------------------------------------------------------
> (setenv "TERM" "xterm") 
> (setq axiomRun-process 
>   (start-process "axiom" (current-buffer) "axiom" "-noht"))
> ; I evaluate this two lines buffer with M-x eval-buffer
> ;
> ;
> GCL (GNU Common Lisp)  2.6.6 CLtL1    Jan 18 2005 00:13:38
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
>                         AXIOM Computer Algebra System 
>                    Version: Axiom 3.0 Beta (February 2005)
>               Timestamp: Monday February 21, 2005 at 20:01:15 
> -----------------------------------------------------------------------------
>    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) -> 
> ;
> ; 
> ; then run this with C-x C-e at the end of the next line
> ;
> (process-send-string axiomRun-process "123+456\n")
> ;
> ; the result appears before this lisp-line, I move it after.
> 
> (1) -> 123+456^H^H^H^H^H^H^H^M(1) -> ^M
>    (1)  579
>                                                         Type: PositiveInteger
> ;
> ; I can do a lot of calculs so.
> ; But when I send a 2 lines command axiom become silly :
> ;  
> (process-send-string axiomRun-process "123+456\n\n")
> ;
> (2) -> 123+456^H^H^H^H^H^H^H^M(2) -> ^M
>    (2)  579
>                                                         Type: PositiveInteger
> 
> (process-send-string axiomRun-process "12+56\n")
> (process-send-string axiomRun-process "12+56\n")
> (process-send-string axiomRun-process "12+56\n")
> (process-send-string axiomRun-process "12+5\n")
> 
> ;
> ; The command line redisplayed isn't the result : so 12+5=68.
> ;
> 
> (3) -> 12+56^H^H^H^H^H^M(3) -> ^M(3) -> 12+56^H^H^H^H^H^M(3) -> ^M
>    (3)  68
>                                                         Type: PositiveInteger
> (4) -> 12+56^H^H^H^H^H^M(4) -> ^M
>    (4)  68
>                                                         Type: PositiveInteger
> (5) -> 12+5^H^H^H^H^M(5) -> ^M
>    (5)  68

\start
Date: Tue, 24 May 2005 21:30:48 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [LaTeX] way to get it to render everything first

http://www.math.union.edu/~dpvc/jsMath/authors/welcome.html says to use:

    &lt;disabled SCRIPT&gt; jsMath.ProcessBeforeShowing() &lt;disabled /SCRIPT&gt; 

which will prevent the page from being displayed until all
the mathematics has been processed. One reason to use this
is when the "flickering" involved in processing the mathematics
would be a distraction.

\start
Date: Wed, 25 May 2005 15:43:27 +0200
From: Gregory Vanuxem
To: list
Subject: Possible gcl bug with axiom--windows--1

Hi,

With saved_gcl (gcl-2.6.5w) from axiom--windows--1 (downloaded two weeks
ago):


c:\MinGW\msys\home\greg\axiom--windows--1\lsp\gcl-2.6.5w\unixport\saved_gcl.
exe
>(compile-file "Bureau/mfop.lisp")

Compiling Bureau/mflop.lisp.
Warning: The OPTIMIZE quality DEBUG is unknown.
Warning: The OPTIMIZE quality DEBUG is unknown.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling Bureau/mflop.lisp.
#p"Bureau/mflop.o"

>(load "Bureau/mflop.o")

Loading Bureau/mflop.o
DDOT-long: 326.20 MFLOPS
DDOT-short: 530.24 MFLOPS

Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at MFLOP-TEST.  Type :H for Help.
>>(quit)

c:\MinGW\msys\home\greg\axiom--windows--1\lsp\gcl-2.6.5w\unixport\saved_gcl.
exe
>(load "Bureau/mflop.lisp")

Loading Bureau/mflop.lisp
DDOT-long: 0.93 MFLOPS
DDOT-short: 0.90 MFLOPS
DAXPY-long: 0.28 MFLOPS
DAXPY-short: 0.27 MFLOPS
Finished loading Bureau/mflop.lisp
T


The same works on linux.
I'm not sure if it's bug since first I use a
realease candidate MinGW and second gcl from axiom--linux is compiled
on AMD64 (64 bits arch).

PS : Original gcl-devel mailing message
(mflop.lisp from Nicolas Neuss (Nicolas Neuss)):
http://lists.gnu.org/archive/html/gcl-devel/2004-07/msg00080.html

------=_NextPart_000_0000_01C56140.7E374600
	name="mflop.lisp"
	filename="mflop.lisp"

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;  mflop.lisp
;;;;  (C) Nicolas Neuss (Nicolas Neuss)
;;;;  mflop.lisp is in the public domain.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defconstant +N-long+ #x100000)  ; does not fit in secondary cache
(defconstant +N-short+ #x100)    ; fits in primary cache

(defparameter *mflop-delta* 5.0
  "Time interval in seconds over which we measure performance.")

(defun make-double-float-array (size &optional (initial 0.0d0))
   (make-array size :element-type 'double-float :initial-element =
initial))

(defun ddot (x y n)
  (declare (type fixnum n)
	   (type (simple-array double-float (*)) x y))
  (declare (optimize (safety 0) (space 0) (debug 0) (speed 3)))
  (loop for i of-type fixnum from 0 below n
	summing (* (aref x i) (aref y i)) double-float))

(defun daxpy (x y n)
  (declare (type fixnum n)
	   (type (simple-array double-float (*)) x y))
  (declare (optimize (safety 0) (space 0) (debug 0) (speed 3)))
  (loop with s of-type double-float = 0.3d0
	for i of-type fixnum from 0 below n do
	(incf (aref y i) (* s (aref x i)))))

(defun test (fn name size)
  (let ((x (make-double-float-array +N-long+))
	(y (make-double-float-array +N-long+)))
    (format
     t "~A-~A: ~$ MFLOPS~%"
     name
     (if (= size +N-long+) "long" "short")
     (loop with after = 0
	   for before = (get-internal-run-time) then after
	   and count = 1 then (* count 2)
	   do
	   (loop repeat count do (funcall fn x y size))
	   (setq after (get-internal-run-time))
	   (when (> (/ (- after before) internal-time-units-per-second)
		    *mflop-delta*)
	     (return (/ (* 2 size count internal-time-units-per-second)
			(* 1e6 (- after before)))))))))

(defun mflop-test ()
  "Returns several numbers characteristic for the efficiency with which
your CL implementation will process numeric code written in a C/Fortran
style.  This results should be significant also for other code using =
arrays
for achieving good data locality.  Please compare these numbers to those
obtained by the C version in mflop.c."
  (test #'ddot 'ddot +N-long+)
  (test #'ddot 'ddot +N-short+)
  (test #'daxpy 'daxpy +N-long+)
  (test #'daxpy 'daxpy +N-short+))

(mflop-test)

\start
Date: Wed, 25 May 2005 11:29:26 -0400
From: Bill Page
To: Kostas Oikonomou
Subject: RE: opinion

On May 24, 2005 11:09 AM Kostas Oikonomou wrote:

> In reading this list, I am impressed by the amount of
> volunteer effort that is going into making a *free* system
> like Axiom work on a closed (and, in my opinion, closed-
> minded) system like Windows.

Does it really seem like a lot of effort to you? As far as
I know there are only three people (me, Mike Thomas and Tim
Daly) who have spent any time on Axiom for Windows, and then
only on a very part-time irregular basis. Right now I might
be spending about an hour or two each week on Axiom for Windows,
about the same amount or maybe a little more on linux versions,
and then there is the MathAction web site... But *if* I had
more "spare" time, then I would probably be spending it mostly
on the Windows version since that is the version that needs the
most work and seems to be of interest to the most people (based
on the statistics from the MathAction website).

> I know of two instances of commercial companies that make
> their products essentially free on more-or-less free
> platforms, but charge for Windows: Trolltech with Qt, and
> SciFace with MuPad.

If there was a commercial company that was interested in
Axiom, then I don't see any impediment to their packaging and
marketing Axiom in this way. But are you suggesting that we,
as volunteer open source developers, could somehow charge a
fee for downloading the Windows version of Axiom? I don't see
how this could work.

\start
Date: Wed, 25 May 2005 12:20:19 -0400
From: Bill Page
To: Kostas Oikonomou
Subject: RE: opinion

On May 25, 2005 11:52 AM Kostas Oikonomou wrote:

> ...
> Bill Page wrote:
>> on the Windows version since that is the version that needs
>> the most work and seems to be of interest to the most people
>> (based on the statistics from the MathAction website).
>
> I wasn't aware of these statistics.

See http://page.axiom-developer.org/usage

and in particular, take a look at the current stats for May

http://page.axiom-developer.org/usage/usage_200505.html#TOPURLS

look for the number of downloads of axiom-windows-0.1.4 at
line 19. Now look for downloads of the Linux versions :(
unfortunately none are listed in this "top 30" list ):


>
>> But are you suggesting that we, as volunteer open source
>> developers, could somehow charge a fee for downloading the
>> Windows version of Axiom? I don't see how this could work.
>
> No, I'm not suggesting that at all.

Good.

> I am expressing frustration with "trying to be compatible
> with Windows" or "trying to get something to work on Windows",
> when the mentality of Windows is to not recognize the existence
> of anything else.

Of course that is true. But the number of people who use
Windows far out numbers the number of people who use Linux.
And more and more people are using open source software on
Windows. Perhaps it is a dilemma for open source software
developers, but one of the main ideas of open source concerns
freedom of choice. The very existence of open source projects
such as Axiom often depends on somehow attracting potential
volunteer developers from the pool of actual users of the
software. Anything that one can do to increase this pool of
potential contributors surely benefits all users, on both
Linux and windows.

> For example, I experience this frustration as an OpenOffice
> user, when M$ makes sure that there is always some
> incompatibility between PowerPoint and the version in
> OpenOffice (called Impress).

I strongly promote the use OpenOffice over the Microsoft office
products and so far compatibility hasn't been a problem for me.
OpenOffice runs equally well on both Windows and Linux so I
think OpenOffice is an excellent example of the potential for
collaboration between open source software and a commercial
company (Sun's Star Office product), even though admittedly
Microsoft is not such a "team player".

\start
Date: Wed, 25 May 2005 19:31:20 +0200
From: Francois Maltey
To: Bill Page, Kostas Oikonomou
Subject: Re: opinion

I add my advice :

> look for the number of downloads of axiom-windows-0.1.4 at
> line 19. Now look for downloads of the Linux versions :(
> unfortunately none are listed in this "top 30" list ):

I don't dowload axiom, I choose axiom because I can install it from my
favorite debian testing.

>> I know of two instances of commercial companies that make
>> their products essentially free on more-or-less free
>> platforms, but charge for Windows: Trolltech with Qt, and
>> SciFace with MuPad.

Even if the mupad language is very fine and the system powerfull,
I think I'll use less and less mupad because

1/ there is no free kernel of the language (it's like a black box)
2/ the library is easy to read, but it's a REAL copyrighted program,
   (even if some developper was benevols)

So I don't know if next year or in 10 years, mupad will continue to exist.
The fact that the program is free without money isn't enough.
It's only less worse than the too expensive maple !

With emacs, latex or openoffice I'm sure that I can re-use my work.

Now there is a cooperation between microsoft and sciface,
I don't know if I'll find the next mupad for my next linux or not.
I want to be sure to find my favorite programs for my computer
when I'll change.

A developer of caml (a french ML language as sheme) tell me that caml is
really use only since everybody can freely download it.
Money came from really industrial project, not from people nor from school.
The idea to sell a language (some years ago there was le-lisp) wasn't a
good idea.

\start
Date: Thu, 26 May 2005 07:47:37 +1000
From: Mike Thomas
To: Gregory Vanuxem
Subject: RE: Possible gcl bug with axiom--windows--1

Hi Greg.

Thanks for the bug report.

The Windows binary relase of GCL 2.6.6  works correctly on that file with a
PIV 512 Megabyte XP machine.

I've got my Axiom source tree set up to test gcl 2.6.7 at the moment and I
won't go further with your bug until that job is finished.

What version of gcc are you using? Likewise what is your CPU and memory?

Cheers

Mike Thomas.

>(compile-file "c:/junk/mflop.lisp")

Compiling c:/junk/mflop.lisp.
Warning: The OPTIMIZE quality DEBUG is unknown.
Warning: The OPTIMIZE quality DEBUG is unknown.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling c:/junk/mflop.lisp.
#p"c:/junk/mflop.o"

>(load "c:/junk/mflop.o")

Loading c:/junk/mflop.o
DDOT-long: 190.38 MFLOPS
DDOT-short: 510.09 MFLOPS
DAXPY-long: 10.84 MFLOPS
DAXPY-short: 12.76 MFLOPS
start address -T 10254878 Finished loading c:/junk/mflop.o
1712

\start
Date: Thu, 26 May 2005 00:19:43 +0200
From: Gregory Vanuxem
To: Mike Thomas
Subject: RE: Possible gcl bug with axiom--windows--1

Hi Mike.

> -----Message d'origine-----
> De : Mike Thomas [mailto:Mike Thomas]
> Envoy=E9 : mercredi 25 mai 2005 23:48
> =C0 : Vanuxem Gr=E9gory; Axiom-Developer
> Objet : RE: Possible gcl bug with axiom--windows--1
>
>
> Hi Greg.
>
> Thanks for the bug report.
>
> The Windows binary relase of GCL 2.6.6  works correctly on that
> file with a
> PIV 512 Megabyte XP machine.
>
> I've got my Axiom source tree set up to test gcl 2.6.7 at the moment an=
d I
> won't go further with your bug until that job is finished.
>
> What version of gcc are you using? Likewise what is your CPU and memory=
?

gcc.exe (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is N=
O
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOS=
E

MinGW-RC probably 2 (2005-02-03-*)
binutils-2.15.94-20050118-1

I have used 'gcc -march=k8' without -m64.

Windows XP (R) 32bits
CPU: AMD 3000+
RAM: 1GB

Cheers,

Greg

PS: If somebody with a more classic build configuration can reproduct
this...

>
> Cheers
>
> Mike Thomas.
>
> >(compile-file "c:/junk/mflop.lisp")
>
> Compiling c:/junk/mflop.lisp.
> Warning: The OPTIMIZE quality DEBUG is unknown.
> Warning: The OPTIMIZE quality DEBUG is unknown.
> End of Pass 1.
> End of Pass 2.
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Spe=
ed=3
> Finished compiling c:/junk/mflop.lisp.
> #p"c:/junk/mflop.o"
>
> >(load "c:/junk/mflop.o")
>
> Loading c:/junk/mflop.o
> DDOT-long: 190.38 MFLOPS
> DDOT-short: 510.09 MFLOPS
> DAXPY-long: 10.84 MFLOPS
> DAXPY-short: 12.76 MFLOPS
> start address -T 10254878 Finished loading c:/junk/mflop.o
> 1712

\start
Date: Thu, 26 May 2005 10:02:40 +0900
From: Renaud Bechade
To: Francois Maltey, Bill Page, Kostas Oikonomou
Subject: RE: opinion

=EF=BC=9EA developer of caml (a french ML language as sheme) tell me =
that caml is
=EF=BC=9Ereally use only since everybody can freely download it.
=EF=BC=9EMoney came from really industrial project, not from people nor =
from school.
=EF=BC=9EThe idea to sell a language (some years ago there was le-lisp) =
wasn't a
=EF=BC=9Egood idea.

If you want to make money with this project, I guess that providing =
consultancy services is much better anyway (custom devel, training, math =
consulting, etc).

-----Original Message-----

I add my advice :

> look for the number of downloads of axiom-windows-0.1.4 at
> line 19. Now look for downloads of the Linux versions :(
> unfortunately none are listed in this "top 30" list ):

I don't dowload axiom, I choose axiom because I can install it from my
favorite debian testing.

>> I know of two instances of commercial companies that make
>> their products essentially free on more-or-less free
>> platforms, but charge for Windows: Trolltech with Qt, and
>> SciFace with MuPad.

Even if the mupad language is very fine and the system powerfull,
I think I'll use less and less mupad because

1/ there is no free kernel of the language (it's like a black box)
2/ the library is easy to read, but it's a REAL copyrighted program,
   (even if some developper was benevols)

So I don't know if next year or in 10 years, mupad will continue to =
exist.
The fact that the program is free without money isn't enough.
It's only less worse than the too expensive maple !

With emacs, latex or openoffice I'm sure that I can re-use my work.

Now there is a cooperation between microsoft and sciface,
I don't know if I'll find the next mupad for my next linux or not.
I want to be sure to find my favorite programs for my computer
when I'll change.

A developer of caml (a french ML language as sheme) tell me that caml is
really use only since everybody can freely download it.
Money came from really industrial project, not from people nor from =
school.
The idea to sell a language (some years ago there was le-lisp) wasn't a
good idea.

\start
Date: Thu, 26 May 2005 19:09:42 +0200
From: Frederic Lehobey
To: list
Subject: Re: opinion

Dear all,

On Wed, May 25, 2005 at 07:31:20PM +0200, Francois Maltey wrote:
> 
> > look for the number of downloads of axiom-windows-0.1.4 at
> > line 19. Now look for downloads of the Linux versions :(
> > unfortunately none are listed in this "top 30" list ):
> 
> I don't dowload axiom, I choose axiom because I can install it from my
> favorite debian testing. 

And according to this link:

  http://popcon.debian.org/main/by_inst

you are not alone as at the time of reading there were at least 66
people who declared to Debian (through popularity-contest package)
having installed it (it is _not_ the number of download of the Debian
packages).  Never forget there are lies, damn lies and statistics.  Do
not misinterpret this: I do not mind the Windows porting efforts and
even appreciate them, but if the Windows figures are more relevant as
the axiom-developers site is almost the only source for axiom
download, nothing such may be said for the GNU/Linux (or Bsd) versions
that have alternative distribution schemes.  Only compare things that
are comparable.  The only figure that matters is the number of
involved developpers: if many people have the goal and skills to
improve the Windows port, then the power is to them, that is the way
free software works.

By the way, an (other) example of people who charge the Windows build
(and only it, the source being GPL) is the gcompris software:
http://gcompris.free.fr/rubrique.php3?id_rubrique=19
http://gcompris.free.fr/rubrique.php3?id_rubrique=21

\start
Date: Thu, 26 May 2005 13:14:08 -0400
From: Bill Page
To: Renaud Bechade
Subject: RE: opinion

On Wednesday, May 25, 2005 9:03 PM  Renaud BECHADE wrote:

> If you want to make money with this project, I guess that providing
> consultancy services is much better anyway (custom devel, training,
> math consulting, etc).

Do you know anyone who is looking for an Axiom Consultant? :)

\start
Date: Thu, 26 May 2005 18:40:32 -0400
From: Bill Page
To: Frederic Lehobey
Subject: RE: opinion

> Bill Page wrote: 
>
>> look for the number of downloads of axiom-windows-0.1.4 at
>> line 19. Now look for downloads of the Linux versions :(
>> unfortunately none are listed in this "top 30" list ):
> 
> On Wed, May 25, 2005 at 07:31:20PM +0200, Francois Maltey wrote:
>
>> I don't dowload axiom, I choose axiom because I can install it
>> from my favorite debian testing. 
>

On Thursday, May 26, 2005 1:10 PM Frederic Lehobey wrote:
>
> And according to this link:
>
>   http://popcon.debian.org/main/by_inst
> 
> you are not alone as at the time of reading there were at least 66
> people who declared to Debian (through popularity-contest package)
> having installed it (it is _not_ the number of download of the Debian
> packages).

This graph shows that the number of Debian users who reported
installing Axiom via popularity-contest has increased by about
150% (from 40 to 60) over the last year

http://people.debian.org/~igloo/popcon-graphs/index.php?packages=axiom&show_
installed=on&show_vote=on&beenhere=1

About 10 people report using Axiom "regularly" and this hasn't
changed much over the year.

The total number of Maxima users reporting is about 5 times the
number number of Axiom users and also seems to have increased
by about the same percentage in the same time period

http://people.debian.org/~igloo/popcon-graphs/index.php?packages=maxima&show
_installed=on&show_vote=on&beenhere=1

with about 50 people who report using Maxima "regularly" and this
also hasn't changed.

For a baseline one can compare this to the overall increase in
the number of debian users reporting by this system

http://people.debian.org/~igloo/popcon-graphs/index.php?packages=base-files&
show_installed=on&show_vote=on&beenhere=1

which is approaching 7,000. So according to this about 1% of Debian
users have installed Axiom and about 5% have installed Maxima with
the number of "regular users" very much less than 1%.

>  Never forget there are lies, damn lies and statistics.

Yes, that is something that I used to do as a profession. :)

> Do not misinterpret this: I do not mind the Windows porting efforts
> and even appreciate them, but if the Windows figures are more relevant
> as the axiom-developers site is almost the only source for axiom
> download, nothing such may be said for the GNU/Linux (or Bsd) versions
> that have alternative distribution schemes.  Only compare things that
> are comparable.

I agree. However if we do attempt to compare the debian Axiom
popcon numbers with the Axiom for Windows downloads from the
axiom-developer.org site, then the number Linux users is still so
small as to be "off the map".

> The only figure that matters is the number of involved developpers:
> if many people have the goal and skills to improve the Windows port,
> then the power is to them, that is the way free software works.

I agree but I think that this is an interesting question: Does
the increase in the number of Axiom for Windows users translate
into an increase in the number of involved Axiom *developers*?

So far postings to the axiom-developer web site and to this email
list suggest that the answer to this quesiton is "no", at least
not within the time period that the Windows version has been
available (since December 2004). :(

\start
Date: Thu, 26 May 2005 16:14:48 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Frederic Lehobey
Subject: RE: opinion

> This graph shows that the number of Debian users who reported
> installing Axiom via popularity-contest has increased by about
> 150% (from 40 to 60) over the last year
> 
>
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=axiom&show_
> installed=on&show_vote=on&beenhere=1
> 
> About 10 people report using Axiom "regularly" and this hasn't
> changed much over the year.
> 
> The total number of Maxima users reporting is about 5 times the
> number number of Axiom users and also seems to have increased
> by about the same percentage in the same time period
> 
>
http://people.debian.org/~igloo/popcon-graphs/index.php?packages=maxima&show
> _installed=on&show_vote=on&beenhere=1
> 
> with about 50 people who report using Maxima "regularly" and this
> also hasn't changed.

This is not surprising.  Please keep in mind that a)  a large number of
people will try out this type of program upon hearing about it and b) 
a large percentage of those people will drop it like a hot potato when
they discover it does not have a friendly GUI, or that it is designed
for work too complicated for them.  I'm guilty of this for other
projects - brlcad and blender come readily to mind as programs I
download and install, but don't (yet) have the skill to use for
anything serious.  I keep them installed and updated because I know how
powerful they are, and I like having that power available on my machine
if I should need to take the time to use it :-).  Silly, I know, and
probably a bit exasperating to the developers, but when it's free...
:-).  The ones who keep using it without a friendly GUI are the serious
users, and that will always tend to be a smaller crowd since the kind
of work that demands regular use of a CAS is not for the faint of
heart.  Now that I think about it I would be curious as to what
Mathematica and Maple's install bases are - I'm betting even there it
can't be over a few tens or hundreds of thousands, even counting
student editions, universities, and industry.  And they both have
polished GUIs, many packages, inertia, and commercial marketing
budgets.  Maxima and Axiom both have a lot of history behind them, but
not as widely used standards.
 
> I agree. However if we do attempt to compare the debian Axiom
> popcon numbers with the Axiom for Windows downloads from the
> axiom-developer.org site, then the number Linux users is still so
> small as to be "off the map".

I would expect this to be the case - most people use Windows, and if an
easy install of Axiom is available they'll go for it.  Maxima's
download stats show a considerable bias towards the Windows side of
things.
 
> I agree but I think that this is an interesting question: Does
> the increase in the number of Axiom for Windows users translate
> into an increase in the number of involved Axiom *developers*?
> 
> So far postings to the axiom-developer web site and to this email
> list suggest that the answer to this quesiton is "no", at least
> not within the time period that the Windows version has been
> available (since December 2004). :(

Developing free software on Windows is a) very difficult and b) very
frustrating.  People like Mike and David have a very special skill set
that is difficult to duplicate and takes a special kind of devotion. 
>From the Maxima experience, getting things working on Windows is always
the most exasperating part of any release.  The bugs are easy to find
but hard to fix - they vary between different versions of Windows, and
even between different installs of the same version of Windows.  The
port of the gnu toolset to Windows (mingw and friends?) is the only way
to generate a stand alone binary for Windows using only free software,
and I think it is fair to say those tools are still evolving.  When you
add all this up, plus the average profile of your Linux/*BSD users (on
a statistical basis) vs. your Windows users, the odds that a Linux/*BSD
user will be up on at least the basics of software development, and
have a well integrated toolset for developing already on his/her
machine, are MUCH higher.  So Windows developers are rare as a
percentage of all Windows users, free software Windows developers are
rarer still, and the intersecting set of Windows free software
developers interested in CAS work is downright tiny.  

Eeep.  Now that I thought that out, I'll take this moment to say -
THANK YOU, Windows developers!  And thank you Tim Daly (and Bill
Schelter) for making all this possible in the first place.

\start
Date: Thu, 26 May 2005 18:23:51 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [the Axiom Community] 

++added:
  The Debian "popularity-contest" package
  "graph for Axiom":http://people.debian.org/~igloo/popcon-graphs/index.php?packages=axiom&show_installed=on&show_vote=on&beenhere=1
  shows that the number of Debian users who reported
  installing Axiom. (Note that this is *not* the actual number of
  downloads of the Axiom on Debian package.) The graph also shows
  the number of Debian users who apparently use Axiom regularly.
  Here is a "ranking":http://popcon.debian.org/main/by_inst
  of Debian packages which shows the popularity of Axiom compared
  to other Debian packages (as reported through popularity-contest
  package).

\start
Date: Fri, 27 May 2005 10:19:53 +1000
From: Mike Thomas
To: Cliff Yapp, Bill Page, Frederic Lehobey
Subject: RE: opinion

Hi all.

I would like to butt in here as I believe that there is an attitude barrier
which needs to be overcome - not an attack on Cliff's hard working and
enthusiastic attitude, but rather on a misapprehension shared by Unix
oriented programmers in general, I think.

Here is the misapprehension:

| Developing free software on Windows is a) very difficult

My personal opinion is that there is nothing inherently difficult about
Windows programming compared with Unix.

For projects like Axiom, Maxima, GRASS, GCL, CMUCL etc in which the software
has roots in the Unix/X11 world, it is the conversion of those projects onto
the different Windows (or the old MacOS) model which is tricky.

Catching up with many person years of (often formerly publicly or
commercially funded) development on Unix written with older software
engineering practices is a major contributing factor, not to mention the
esoteric world of Common Lisp in those cases we are discussing here.  (I
personally reckon that the GCL C and Maxima Lisp source trees are the most
unreadable I have ever seen. Axiom source (not the Latex pamphlets which are
horrible for programming purposes) I find very readable on the other hand.)

An excellent example of the difficulty of crossing the programming paradigm
boundary in the opposite direction is the trend of bringing music production
software into the Linux/*BSD arena - a slow and difficult process on those
platforms in a field traditionally dominated by MacOS, Windows and Atari
TOS.  The Agnula/DeMuDi people are doing a great job with great progress but
lag behind the software offered on Windows/Mac.


| and b) very
| frustrating.  People like Mike and David have a very special skill set
| that is difficult to duplicate and takes a special kind of devotion.

(We're actually "on a mission from God" - note the quotes before taking this
seriously.)

| >From the Maxima experience, getting things working on Windows is always
| the most exasperating part of any release.  The bugs are easy to find
| but hard to fix - they vary between different versions of Windows, and
| even between different installs of the same version of Windows.

This variety is similar to Linux/*BSD/Solaris/IRIX/GNU library and tool
versions I believe.

| The
| port of the gnu toolset to Windows (mingw and friends?) is the only way
| to generate a stand alone binary for Windows using only free software,
| and I think it is fair to say those tools are still evolving.  When you
| add all this up, plus the average profile of your Linux/*BSD users (on
| a statistical basis) vs. your Windows users, the odds that a Linux/*BSD
| user will be up on at least the basics of software development, and
| have a well integrated toolset for developing already on his/her
| machine, are MUCH higher.  So Windows developers are rare as a
| percentage of all Windows users, free software Windows developers are
| rarer still, and the intersecting set of Windows free software
| developers interested in CAS work is downright tiny.

Agreed.

There is also a strangely branched attitude around on both sides of the
software divide which says "You Windows free software developers are [in
some sad way ethically unclean (this from the Linux world) | stupid for
doing free work (from the Windows/Solaris/IRIX side where _all_ programmers
I meet are commercial programmers)]."

I encountered the first attitude in person face to face from one of the
leading lights in the free software community (the only open source
developer I ever met in person) and the latter from almost every programning
colleague I have ever worked with.

| Eeep.  Now that I thought that out, I'll take this moment to say -
| THANK YOU, Windows developers!  And thank you Tim Daly (and Bill
| Schelter) for making all this possible in the first place.

\start
Date: Fri, 27 May 2005 10:34:16 +1000
From: Mike Thomas
To: Bill Page
Subject: RE: building Axiom with GCL Version_2_6_7pre fails
Cc: Camm Maguire

Bill.

A quick note to say that I have reproduced that directory change bug but
have yet to find time to track it down; hopefully next week.

\start
Date: Thu, 26 May 2005 17:52:33 -0700 (PDT)
From: Cliff Yapp
To: Mike Thomas, Bill Page, Frederic Lehobey
Subject: RE: opinion

> My personal opinion is that there is nothing inherently difficult
> about Windows programming compared with Unix.
> 
> For projects like Axiom, Maxima, GRASS, GCL, CMUCL etc in which the
> software has roots in the Unix/X11 world, it is the conversion of 
> those projects onto the different Windows (or the old MacOS) model 
> which is tricky.

That's true, of course.  I hadn't considered it, but I guess going from
Windows to *nix is just as tough.  (More so, if you consider the
multitude of toolkits to choose from.)  I know CMUCL ports have been
tried and it tends to make developers back away slowly looking rather
pale.

> Catching up with many person years of (often formerly publicly or
> commercially funded) development on Unix written with older software
> engineering practices is a major contributing factor, not to mention
> the esoteric world of Common Lisp in those cases we are discussing 
> here.  (I personally reckon that the GCL C and Maxima Lisp source 
> trees are the most unreadable I have ever seen. Axiom source (not 
> the Latex pamphlets which are horrible for programming purposes) I 
> find very readable on the other hand.)

Heh - I doubt you are alone in your opinion of Maxima's code base.  I
think one of our major efforts in the future will have to be a
reorganization and documentation of our lisp code - probably we will
never achieve literate programming the way Axiom is, but since Maxima
has a different focus it is somewhat less essential that we do.  I
always thought of this as Maxima being the "quick implimentation"
platform, looking for practical results, and Axiom as the "take your
time and do it right" platform.  Both are helped by well documented
code, but in Axiom's case it is more than a help - it is absolutely
essential to the project goals.  (I know it's off topic, but I still
hope at some point to break Maxima up into packages, use Albert to
create some programmer documentation, and generally de-mysterify the
lisp code.  Not quite up to Axiom's level, but certainly better than
where we are now.)

> An excellent example of the difficulty of crossing the programming
> paradigm boundary in the opposite direction is the trend of bringing
> music production software into the Linux/*BSD arena - a slow and 
> difficult process on those platforms in a field traditionally 
> dominated by MacOS, Windows and Atari TOS.  The Agnula/DeMuDi people 
> are doing a great job with great progress but lag behind the 
> software offered on Windows/Mac.

Come to think of it, even Virtualdub has not (as far as I know) been
ported to Linux, despite being useful, popular and open source. 
 
> | and b) very
> | frustrating.  People like Mike and David have a very special 
> skill set
> | that is difficult to duplicate and takes a special kind of
> devotion.
> 
> (We're actually "on a mission from God" - note the quotes before
> taking this seriously.)

Another Jake and Elwood fan? :-)

> This variety is similar to Linux/*BSD/Solaris/IRIX/GNU library and
> tool versions I believe.

Good point.  I guess usually only Linux and occasionally *BSD get
attention, realistically.

> | So Windows developers are rare as a
> | percentage of all Windows users, free software Windows developers
> | are rarer still, and the intersecting set of Windows free software
> | developers interested in CAS work is downright tiny.
> 
> Agreed.
> 
> There is also a strangely branched attitude around on both sides 
> of the software divide which says "You Windows free software 
> developers are [in some sad way ethically unclean (this from the 
> Linux world) | stupid for doing free work (from the 
> Windows/Solaris/IRIX side where _all_ programmers
> I meet are commercial programmers)]."

Yep.  Slashdot resonates with this divide, unfortunately.

> I encountered the first attitude in person face to face from one of
> the leading lights in the free software community (the only open
> source developer I ever met in person) and the latter from almost
> every programning colleague I have ever worked with.

Sorry you had to run into that :-/.  I tend to take a "live and let
live" approach to such things.  If people want to develop commercial
software, great.  I only get annoyed when they complain about people
developing competing tools for free.  I do have the opinion that if you
can't produce a product commercially that is enough better than a free
option to inspire people to pay you then have no inherant "right" to
make a profit or (by whatever method) eliminate the free competition,
but that's another debate altogether.
 
> | Eeep.  Now that I thought that out, I'll take this moment to say -
> | THANK YOU, Windows developers!  And thank you Tim Daly (and Bill
> | Schelter) for making all this possible in the first place.
> 

\start
Date: Fri, 27 May 2005 14:20:21 +1000
From: Mike Thomas
To: Bill Page
Subject: RE: building Axiom with GCL Version_2_6_7pre fails
Cc: Camm Maguire, Paul F. Dietz

Hi Bill.

| Can you imagine what recent change (last week?) might lead
| to this failure? Perhaps the change to probe-file or related
| routine?

You are right; the probe-file change.

(probe-file "./") returns nil on Windows with the latest changes.

In daase.lisp.pamphlet the "./" is hard wired:

  (localdatabase nil
     (list (list '|dir| (namestring (probe-file "./")) ))
     'make-database)



Lispworks gives:

CL-USER 1 > (probe-file "./")
#P"C:/Documents and Settings/miketh/"

CL-USER 2 > (truename "./")
#P"C:/Documents and Settings/miketh/"



Corman Lisp gives:

(probe-file "./")
NIL
(truename "./")
#P"C:/Documents and Settings/miketh/"

CLISP:

[1]> (truename "./")
#P"C:\\Documents and Settings\\miketh\\Desktop\\"
[2]> (probe-file "./")

*** - no file name given: #P"C:\\Documents and Settings\\miketh\\Desktop\\"
1. Break [3]> :C 1


Windows GCL currently follows Corman on this one and the Hyperspec says
this:

http://www.lisp.org/HyperSpec/Body/fun_probe-file.html


Common Lisp experts:

1. Which behaviour is correct on Windows?  (I believe that "." and ".." are
actual entities on Unix, but not Windows.  Convenience argues for following
LW rather than Corman.)

2. What is the system independent way to get the name of the current
directory in Common Lisp?


\start
Date: Fri, 27 May 2005 01:18:03 -0400
From: Bill Page
To: Mike Thomas
Subject: RE: building Axiom with GCL Version_2_6_7pre fa ils
Cc: Camm Maguire, Paul F. Dietz

On Friday, May 27, 2005 12:20 AM Mike Thomas wrote:

> ...
> Lispworks gives:
>
> CL-USER 1 > (probe-file "./")
> #P"C:/Documents and Settings/miketh/"
>
> CL-USER 2 > (truename "./")
> #P"C:/Documents and Settings/miketh/"
>
> Corman Lisp gives:
>
> (probe-file "./")
> NIL
> (truename "./")
> #P"C:/Documents and Settings/miketh/"

> ...
> 1. Which behaviour is correct on Windows?  (I believe that "." and
> ".." are actual entities on Unix, but not Windows.  Convenience
> argues for following LW rather than Corman.)

Recall that originally Camm changed the behaviour of probe-file
in GCL Version_2_6_7pre in order to be able to distringuish
between a "file" and a "directory". For doing things like
recursively traversing a directory tree, this distinction is
necessary. I believe whether they are actual entities or not,
"." and ".." are (indirect) references to directories - not
files. So to me the Corman behaviour makes the most sense.

\start
Date: Fri, 27 May 2005 10:28:29 +0200
From: Frederic Lehobey
To: list
Subject: Re: opinion

Hi,

Sorry to feed this somewhat off-topic thread, I'll refrain from doing
it after this message.

On Thu, May 26, 2005 at 06:40:32PM -0400, Page, Bill wrote:

> For a baseline one can compare this to the overall increase in
> the number of debian users reporting by this system
> 
> http://people.debian.org/~igloo/popcon-graphs/index.php?packages=base-files&
> show_installed=on&show_vote=on&beenhere=1
> 
> which is approaching 7,000. So according to this about 1% of Debian
> users have installed Axiom and about 5% have installed Maxima with
> the number of "regular users" very much less than 1%.

> > Do not misinterpret this: I do not mind the Windows porting efforts
> > and even appreciate them, but if the Windows figures are more relevant
> > as the axiom-developers site is almost the only source for axiom
> > download, nothing such may be said for the GNU/Linux (or Bsd) versions
> > that have alternative distribution schemes.  Only compare things that
> > are comparable.
> 
> I agree. However if we do attempt to compare the debian Axiom
> popcon numbers with the Axiom for Windows downloads from the
> axiom-developer.org site, then the number Linux users is still so
> small as to be "off the map".

Well, I do not know.  Do you have any idea of the percentage of
Windows users who are regular users of Axiom?  I expect it to be much
much smaller than 1%.

> > The only figure that matters is the number of involved developpers:
> > if many people have the goal and skills to improve the Windows port,
> > then the power is to them, that is the way free software works.
> 
> I agree but I think that this is an interesting question: Does
> the increase in the number of Axiom for Windows users translate
> into an increase in the number of involved Axiom *developers*?
> 
> So far postings to the axiom-developer web site and to this email
> list suggest that the answer to this quesiton is "no", at least
> not within the time period that the Windows version has been
> available (since December 2004). :(

Unfortunately, up to now.  But I praise your efforts and hope to see
them soon rewarded by a much wider Windows user (and hopefully
developer) base.

Personally, I have interest (and some skills) in working on the
GNU/Linux version but have not yet found the time to do it (other more
urgent but not always more important matters).  I feel ashamed and
frustrated compared to your work but hope I will not not stay too long
like this.

\start
Date: 27 May 2005 10:06:19 -0400
From: Camm Maguire
To: Mike Thomas
Subject: Re: [Gcl-devel] RE: building Axiom with GCL Version_2_6_7pre fails
Cc: Paul F. Dietz

Greetings!

The spec is still a little ambiguous, but these lines indicate to me
that GCL, clisp, and corman have it right (don't know why clisp throws
an error, but in general I use clisp all the time to test ansi
compliance issues.)

probe-file tests whether a file exists.

probe-file returns false if there is no file named pathspec, and otherwise returns the truename of pathspec.

A file here should be sopentheing that could be opened with (open...)
-- we have no such ability currently for directories.

Is this a problem to follow in mingw?

Take care,


Mike Thomas writes:

> Hi Bill.
> 
> | Can you imagine what recent change (last week?) might lead
> | to this failure? Perhaps the change to probe-file or related
> | routine?
> 
> You are right; the probe-file change.
> 
> (probe-file "./") returns nil on Windows with the latest changes.
> 
> In daase.lisp.pamphlet the "./" is hard wired:
> 
>   (localdatabase nil
>      (list (list '|dir| (namestring (probe-file "./")) ))
>      'make-database)
> 
> 
> 
> Lispworks gives:
> 
> CL-USER 1 > (probe-file "./")
> #P"C:/Documents and Settings/miketh/"
> 
> CL-USER 2 > (truename "./")
> #P"C:/Documents and Settings/miketh/"
> 
> 
> 
> Corman Lisp gives:
> 
> (probe-file "./")
> NIL
> (truename "./")
> #P"C:/Documents and Settings/miketh/"
> 
> CLISP:
> 
> [1]> (truename "./")
> #P"C:\\Documents and Settings\\miketh\\Desktop\\"
> [2]> (probe-file "./")
> 
> *** - no file name given: #P"C:\\Documents and Settings\\miketh\\Desktop\\"
> 1. Break [3]> :C 1
> 
> 
> Windows GCL currently follows Corman on this one and the Hyperspec says
> this:
> 
> http://www.lisp.org/HyperSpec/Body/fun_probe-file.html
> 
> 
> Common Lisp experts:
> 
> 1. Which behaviour is correct on Windows?  (I believe that "." and ".." are
> actual entities on Unix, but not Windows.  Convenience argues for following
> LW rather than Corman.)
> 
> 2. What is the system independent way to get the name of the current
> directory in Common Lisp?

\start
Date: Fri, 27 May 2005 10:42:01 -0400
From: Bill Page
To: Camm Maguire, Mike Thomas
Subject: RE: [Gcl-devel] RE: building Axiom with GCL Version_2_6_7pre fails
Cc: Paul F. Dietz

On Friday, May 27, 2005 10:06 AM Camm Maguire wrote:

> ...
> probe-file tests whether a file exists.
>
> probe-file returns false if there is no file named
> pathspec, and otherwise returns the truename of pathspec.
>
> A file here should be sopentheing that could be opened with
> (open...) -- we have no such ability currently for directories.
>
> Is this a problem to follow in mingw?

No it is not a problem. In fact that is exactly what GCL
Version_2_6_7pre on Windows does now.

> 
> (probe-file "./") returns nil on Windows with the latest changes.
> 

The problem is in the Axiom source for daase.lisp.pamphlet.

> In daase.lisp.pamphlet the "./" is hard wired:
> 
>   (localdatabase nil
>      (list (list '|dir| (namestring (probe-file "./")) ))
>      'make-database)
> 

Here Axiom is trying to find the name of the "current"
directory which it passes to |dir|. It should probably just
call (truename "./"). Or better, perhaps there should be a
standard lisp mechanism to do what Axiom's |dir| does.

The fact that this code used to work on Axiom is a bit
troubling since it makes one wonder where else in Axiom
(and maybe other packages like Maxima and ACL) probe-file
is used in this now obsolete manner?

\start
Date: Sat, 28 May 2005 09:03:40 +0200
From: Martin Rubey
To: list
Subject: Drawing several functions in one plot

Dear all,

I'd like to have axiom draw two functions in the same viewport, for example 

x^2*y^3 and it's tangential plane in the point (1,-1).

I tried merge and composite with no success. Any ideas? (best thing would be an
example! 

\start
Date: Sat, 28 May 2005 10:13:37 -0500
From: Tim Daly
To: Martin Rubey
Subject: multiple graphcs

)clear all
)set break resume
a:=0.5
b:=0.5
y1:=draw(x^3*(a+b*x),x=-1..1,title=="2.2.10 explicit")
g1:=getGraph(y1,1)
pointLists g1
b:=1.0
y2:=draw(x^3*(a+b*x),x=-1..1)
g2:=getGraph(y2,1)
pointLists g2
putGraph(y1,g2,2)
b:=2.0
y3:=draw(x^3*(a+b*x),x=-1..1)
g3:=getGraph(y3,1)
pointLists g3
putGraph(y1,g3,3)
vp:=makeViewport2D(y1)

\start
Date: Sat, 28 May 2005 10:45:46 -0500
From: Tim Daly
To: Martin Rubey
Subject: multiple graphcs

More explicitly we want to graph x^3*(a+b*x) on the interval x=-1..1
)clear all
)set break resume

We assign values to the constants
a:=0.5
b:=0.5

draw the first case of the graph
y1:=draw(x^3*(a+b*x),x=-1..1,title=="2.2.10 explicit")

fetch the graph object
g1:=getGraph(y1,1)

and get the points that make up the graph
pointLists g1

Now we vary a parameter
b:=1.0

draw the new graph
y2:=draw(x^3*(a+b*x),x=-1..1)

fetch the object
g2:=getGraph(y2,1)

extract the points
pointLists g2

and add them to the first graph we drew (y1) as the "second graph" (2)
putGraph(y1,g2,2)

And we vary the parameter
b:=2.0

draw the new graph
y3:=draw(x^3*(a+b*x),x=-1..1)

fetch the object
g3:=getGraph(y3,1)

extract the points
pointLists g3

add the points to the first graph (y1) as the "third graph" (3)
putGraph(y1,g3,3)

and display the results.
vp:=makeViewport2D(y1)

You can have up to 9 graphs in one image. You can toggle the
display (on-off) of the individual graphs in the graphics control
panel.

You can also construct multi-graph images by displaying individual
graphs each in their own window (say windowA and windowB). You can
"pick" a graph from windowA and "drop" it into windowB using the
control panels.

\start
Date: Fri, 27 May 2005 19:24:04 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: Future of LatexWiki
Cc: Steve Sekula, Kyle Cranmer,	R. Sean Bowman, frat.frat@laposte.net, Sigbert Klinke, Drew Moore

Bob,

On Friday, May 27, 2005 4:46 PM you wrote:

> I'm writing to inform you that I intend to abandon the
> LatexWiki codebase shortly.  I will release 0.42 shortly,
> to coincide with ZWiki 0.42, but that will be the last
> release from me.  Shortly after that I will move away from
> Zope/ZWiki for my own wiki.

I certainly understand your reasons for making this decision,
but I just have to say that your work on LatexWiki has been
of the greatest importance to me. I think the unique features
of LatexWiki have made a very large contribution to the support
of the Axiom project. And I expect it will continue to do so
for a long while yet, even as we start to look at other options
and new ways of doing things.

> I hope that one of you would be willing to pick up the slack
> and maintain LatexWiki.

Well, like you, for me programming wiki's to display mathematics
is not an end in itself. There are certainly many other things
(particularly with respect to mathematics and Axiom) to which
I would prefer to devote my time. But I certainly intend to
continue to support LatexWiki as the primarily tool for the
MathAction web site.

> ...
>
> To put it all another way, continuing with ZWiki and Zope is
> not "fun" for me any longer.

For me, that's the absolute best reason there is in this
business. :)

>...
> The release of the "STIX fonts":http://www.stix.org later this
> year will be a boon to math on the web, and will hopefully
> obviate the need for images.

Unfortunately about this, I have some doubts...

Best wishes in your next project! Let's keep continue to keep
in touch with each other, as and when time permits.

\start
Date: Sat, 28 May 2005 21:42:35 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: multiple graphcs

Thanks for the rapid response -- this works only for two dimensional graphs
though?

Martin

Tim Daly writes:
 > You can have up to 9 graphs in one image. You can toggle the
 > display (on-off) of the individual graphs in the graphics control
 > panel.
 > 
 > You can also construct multi-graph images by displaying individual
 > graphs each in their own window (say windowA and windowB). You can
 > "pick" a graph from windowA and "drop" it into windowB using the
 > control panels.
 > 
 > Tim

\start
Date: Sat, 28 May 2005 16:41:52 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#162 nested cross products for Vector Polynomial Integer probelm] (new) 

I'm trying to produce a vector by several cross products
All variables and elements of the vectors are polynomial integers
All vectors are Vector Polynomial Integer

X := cross(A0, A1)
Y := cross(A2, A3)
B0 := A0 + a0*X + a0*Y
B1 := A1 + a1*X + a1*Y
B2 := A2 + a2*X + a2*Y
B3 := A3 + a3*X + a3*Y
C0 = cross(B0, B1)
C1 = cross(B2, B3)
D=cross(C0, C1)

On the last command Axiom stop working and hang.
Is there any workaround for this problem ?

\start
Date: Sat, 28 May 2005 21:27:27 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#162 nested cross products for Vector Polynomial Integer probelm] can't reproduce this problem

Why do you use = is the last 3 lines?

I can't reproduce this problem. The following works for me:
\begin{axiom}
  )clear completely
  (a0,a1,a2,a3):Polynomial Integer
  (a00,a01,a02):Polynomial Integer
  A0:=vector [a00,a01,a02]
  (a10,a11,a12):Polynomial Integer
  A1:=vector [a10,a11,a12]
  X:=cross(A0,A1)
  (a20,a21,a22):Polynomial Integer
  A2:=vector [a20,a21,a22]
  (a30,a31,a32):Polynomial Integer
  A3:=vector [a30,a31,a32]
  Y:=cross(A2,A3)
  B0 := A0 + a0*X + a0*Y
  B1 := A1 + a1*X + a1*Y
  B2 := A2 + a2*X + a2*Y
  B3 := A3 + a3*X + a3*Y
  C0 := cross(B0,B1)
  C1 := cross(B2,B3)
  D := cross(C0,C1);
\end{axiom}

But the last expression if vary large and is too large
to display on here on MathAction.

Please post the actual Axiom commands that will cause
Axiom to hang.

\start
Date: Sat, 28 May 2005 21:28:28 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#162 nested cross products for Vector Polynomial Integer probelm] can't reproduce this problem

)clear completely
(a0,a1,a2,a3):Polynomial Integer
(a00,a01,a02):Polynomial Integer
A0:=vector [a00,a01,a02]
(a10,a11,a12):Polynomial Integer
A1:=vector [a10,a11,a12]
X:=cross(A0,A1)
(a20,a21,a22):Polynomial Integer
A2:=vector [a20,a21,a22]
(a30,a31,a32):Polynomial Integer
A3:=vector [a30,a31,a32]
Y:=cross(A2,A3)
B0 := A0 + a0*X + a0*Y
B1 := A1 + a1*X + a1*Y
B2 := A2 + a2*X + a2*Y
B3 := A3 + a3*X + a3*Y
C0 := cross(B0,B1)
C1 := cross(B2,B3)
D := cross(C0,C1);

\start
Date: Sun, 29 May 2005 01:58:37 -0500
From: MathAction (unknown)
To: MathAction
Subject: [#162 nested cross products for Vector Polynomial Integer probelm] 

(a0x, a1x, a2x, a3x, a0y, a1y, a2y, a3y) : Polynomial Integer

(PR0, PR1, PR2, PR3, PRN0, PRN1, PRN2, PRN3, X, Y, Z, XN, YN, ZN): Vector Polynomial  Integer

PR0 := vector[PR0x, PR0y, PR0z]

PR1 := vector[PR1x, PR1y, PR1z]

PR2 := vector[PR2x, PR2y, PR2z]

PR3 := vector[PR3x, PR3y, PR3z]

X := cross(PR0, PR3)

Y := cross(PR1, PR2)

PRN0 := PR0 + a0x*X + a0y*Y

PRN3 := PR3 + a3x*X + a3y*Y

XN := cross(PRN0, PRN3)

PRN1 := PR1 + a1x*X + a1y*Y

PRN2 := PR2 + a2x*X + a2y*Y

YN := cross(PRN1, PRN2)

ZN := cross(XN, YN)

\start
Date: Sun, 29 May 2005 02:10:22 -0500
From: MathAction (unknown)
To: MathAction
Subject: [#162 nested cross products for Vector Polynomial Integer probelm] yor sample

You code is not working for me too - hang on the last command

D := cross(C0,C1)

\start
Date: Sun, 29 May 2005 02:22:27 -0500
From: MathAction (unknown)
To: MathAction
Subject: [#162 nested cross products for Vector Polynomial Integer probelm] update : it's WInTexMAcs problem

I've launched your test in axiom console without WinTexMacs and it's working.
Any advices how to fix WinTexMacs ?  

\start
Date: Sun, 29 May 2005 08:51:55 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#163 axiom output isn't right with _] (new) 

I use an axiom xterm (with or without clef) 

123_[return]456 has a right result but a wrong display before.
I only see 123_, not 123_[newline]456

123_[return]+456 has a right display and a right result.
I read 123_[newline]+456

The display is also wrong when I make a little file with 123_[return]456, 
and I read it.

I use the Axiom 3.0 Beta (February 2005) in a linux box.

\start
Date: Sun, 29 May 2005 13:27:38 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#162 nested cross products for Vector Polynomial Integer probelm] 

Example code::

  (a0x, a1x, a2x, a3x, a0y, a1y, a2y, a3y) : Polynomial Integer
  (PR0, PR1, PR2, PR3, PRN0, PRN1, PRN2, PRN3, X, Y, Z, XN, YN, ZN): Vector Polynomial  Integer
  PR0 := vector[PR0x, PR0y, PR0z]
  PR1 := vector[PR1x, PR1y, PR1z]
  PR2 := vector[PR2x, PR2y, PR2z]
  PR3 := vector[PR3x, PR3y, PR3z]
  X := cross(PR0, PR3)
  Y := cross(PR1, PR2)
  PRN0 := PR0 + a0x*X + a0y*Y
  PRN3 := PR3 + a3x*X + a3y*Y
  XN := cross(PRN0, PRN3)
  PRN1 := PR1 + a1x*X + a1y*Y
  PRN2 := PR2 + a2x*X + a2y*Y
  YN := cross(PRN1, PRN2)
  ZN := cross(XN, YN)

\start
Date: Sun, 29 May 2005 13:57:54 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#163 axiom output isn't right with _] 

I use an axiom xterm (with or without clef) ::

  123_[return]456 has a right result but a wrong display before.
  I only see 123_, not 123_[newline]456

  123_[return]+456 has a right display and a right result.
  I read 123_[newline]+456

  The display is also wrong when I make a little file with
  123_[return]456, and I read it.

++added:
This also seems to happen on MathAction
\begin{axiom}
123_
456
\end{axiom}
\begin{axiom}
123_
+456
\end{axiom}

But the display and results are correct in the Windows
version.

\start
Date: Mon, 30 May 2005 11:19:52 +1000
From: Mike Thomas
To: Bill Page, Camm Maguire
Subject: RE: [Gcl-devel] RE: building Axiom with GCL Version_2_6_7pre fails

Thanks Bill and Camm.

Bill wrote:

| On Friday, May 27, 2005 10:06 AM Camm Maguire wrote:
|
| > ...
| > probe-file tests whether a file exists.
| >
| > probe-file returns false if there is no file named
| > pathspec, and otherwise returns the truename of pathspec.
| >
| > A file here should be sopentheing that could be opened with
| > (open...) -- we have no such ability currently for directories.
| >
| > Is this a problem to follow in mingw?
|
| No it is not a problem. In fact that is exactly what GCL
| Version_2_6_7pre on Windows does now.
|
| >
| > (probe-file "./") returns nil on Windows with the latest changes.
| >
|
| The problem is in the Axiom source for daase.lisp.pamphlet.
|
| > In daase.lisp.pamphlet the "./" is hard wired:
| >
| >   (localdatabase nil
| >      (list (list '|dir| (namestring (probe-file "./")) ))
| >      'make-database)
| >
|
| Here Axiom is trying to find the name of the "current"
| directory which it passes to |dir|. It should probably just
| call (truename "./"). Or better, perhaps there should be a
| standard lisp mechanism to do what Axiom's |dir| does.



The fix then is as follows:

diff -rN old-axiom--windows--1/src/interp/daase.lisp.pamphlet
new-axiom--windows
--1/src/interp/daase.lisp.pamphlet
843c843
<   (setq thisdir (namestring (probe-file ".")))
---
>   (setq thisdir (namestring (truename ".")))
1109c1109
<      (list (list '|dir| (namestring (probe-file "./")) ))
---
>      (list (list '|dir| (namestring (truename "./")) ))


\start
Date: Sun, 29 May 2005 21:35:39 -0400
From: Bill Page
To: Mike Thomas
Subject: RE: [Gcl-devel] RE: building Axiom with GCL Version_2_6_7pre fails
Cc: Camm Maguire

Mike,

On May 29, 2005 9:20 PM you wrote:

> ...
>The fix then is as follows:
>
> diff -rN old-axiom--windows--1/src/interp/daase.lisp.pamphlet
new-axiom--windows
> --1/src/interp/daase.lisp.pamphlet
> 843c843
> <   (setq thisdir (namestring (probe-file ".")))
> ---
> >   (setq thisdir (namestring (truename ".")))
> 1109c1109
> <      (list (list '|dir| (namestring (probe-file "./")) ))
> ---
> >      (list (list '|dir| (namestring (truename "./")) ))

I think that there is one more place in daase.lisp.pamphlet
near you last patch where probe-file should be changed to
truename:

  (dolist (dir dirlist)
          (localdatabase nil
                         (list (list '|dir|
                                     (namestring (probe-file
                                                  (format nil "./~a"
                                                          dir)))))
                         'make-database))

---------

Right?

With these three changes, my version of Axiom for Windows
builds with gcl Version_2_6_7pre.

\start
Date: Mon, 30 May 2005 11:44:05 +1000
From: Mike Thomas
To: Camm Maguire, Bill Page
Subject: re: [Gcl-devel] Possible GCL 2.6.7 for axiom

Hi Camm.

|   6) On Windows (at least) GCL 2.6.6 Axiom (not 2.6.5) has a problem with
| equation system solutions:
| ===========================================
| (1) -> solve([3*x**3+y+1,y**2-4],[x,y])
|    Loading C:/Program Files/axiom/mnt/windows/algebra/UPMP.o for
|       package UnivariatePolynomialMultiplicationPackage
|
|    >> System error:
|    The function SYSTEM::DEBUGGER is undefined.
|
| protected-symbol-warn called with (NIL)
| (1) -> solve([3*x**3+y+1,y**2-4],[x,y])
|
|    >> System error:
|    Arg or result mismatch in call to  |devaluateList|
|
| protected-symbol-warn called with (NIL)
|
| ===========================================


On the subject of AXIOM, Windows and surrent directories I just got to the
bottom of the above bug too.

The problem occurs when the AXIOM environment variable is set globally to
one particular AXIOM system while running an AXIOMsys.exe from a separate
AXIOM system (eg in my case, my development source tree).

This causes the second system to load object files from the first Axiom
system causing objections about missing functions (in my particular case the
function SYSTEM::DEBUGGER which is relatively new).

I would suggest removal of the the AXIOM environment variable at least on
the global level, or better, completely.

I also suggest avoiding a wrapper batch file as that will be fraught with
other difficulties - notably the absence of a simple way to get the working
directory in batch files on all versions of Windows, but also because it
usually poor programming practice on Windows to use application-specific
environment variables.  Nor would it be appropriate in this instance to use
the Windows registry.

The right thing to do I think is to add a new crossplatform GCL system
package function "get-current-directory" - a relatively simple task for the
platforms upon which GCL currently runs.

\start
Date: Mon, 30 May 2005 11:53:03 +1000
From: Mike Thomas
To: Bill Page
Subject: RE: [Gcl-devel] RE: building Axiom with GCL Version_2_6_7pre fails
Cc: Camm Maguire

Hi Bill.

| I think that there is one more place in daase.lisp.pamphlet
| near you last patch where probe-file should be changed to
| truename:
|
|   (dolist (dir dirlist)
|           (localdatabase nil
|                          (list (list '|dir|
|                                      (namestring (probe-file
|                                                   (format nil "./~a"
|                                                           dir)))))
|                          'make-database))

I ignored that as it didn't break the build, so I'll leave you to decide and
prepare the official patch modding the above or otherwise.

\start
Date: Mon, 30 May 2005 15:43:11 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: multiple graphcs

I just realized: extensive documentation how to have multiple graphs in one
viewport, no matter what its dimension, is in the axiom book, Section 7.2...

Thanks again,

Martin

Martin Rubey writes:
 > Thanks for the rapid response -- this works only for two dimensional graphs
 > though?
 > 
 > Martin
 > 
 > Tim Daly writes:
 >  > You can have up to 9 graphs in one image. You can toggle the
 >  > display (on-off) of the individual graphs in the graphics control
 >  > panel.
 >  > 
 >  > You can also construct multi-graph images by displaying individual
 >  > graphs each in their own window (say windowA and windowB). You can
 >  > "pick" a graph from windowA and "drop" it into windowB using the
 >  > control panels.
 >  > 
 >  > Tim
 > 

\start
Date: Mon, 30 May 2005 09:37:23 -0500
From: MathAction (Sergey Ten)
To: MathAction
Subject: [Axiom-mail] Is it possible to make calculations in vector form, like in  Maxima ?

I mean I want to input   cross( a0*A + b0*B, C)
and get the answer a0*(A X C) + b0*(B X C) or something like it, without 
actual evalution of each component.
Thanks.

\start
Date: Mon, 30 May 2005 14:42:16 -0500
From: MathAction (Francois Maltey)
To: MathAction
Subject: [Axiom-mail] a very little emacs mode for axiom.

Hello, 

I send here my very first axiom-mode for emacs. 
It isn't a finish program.

It's like the maxima mode for emacs, but without latex. 
I translate and clear my mupad-run-mode.el file.

You can tell me what you want. 
I don't know how to use axiom debogger, 
so I don't what emacs-key will be fine.

It's work with xemacs on a linux box.

--------------------------------------------------------------------------
;
; axiomacs-smallest.el - 5/2005 version - smallest version
; by Franois Maltey in 2005, from the mupad-run.el.

; axiomacs allows to use axiom as an editor for a session of axiom.
; 
; You can load this file from your .emacs, by example.
; 
; The commands are :
;
; axiom-run in starts an axiom session in a *Axiom* buffer.
; axiom-run-bis starts an axiom session in an other buffer.
; there are also axiom-batch and axiom-batch-bis for next hidden sessions.
;
; emacs build little *.input axiom files.
;
; [C-return] sends one or many lines to axiom
; [C-c C-c] sends a break to axiom.
;
; update axiomRun-command-line and axiomRun-base-directory before use.
; and erase sometimes axiomacs*.input files after you use axiomacs.
; 
; This version is as smaller as possible.
;
; The axiom commands must be at the end of the buffer.
; It's very dangerous to change the buffer before last prompt.
;
; Today there is no history and no save-file, 
; but you can use emacs abilities.
;
; It will be possible to use a debugger, if someone explains me what he want.
; 
; Later custom, colors and read-only area in this mode will perhaps come.
;
 
(provide 'axiom-run)
(defconst axiom-run-mode-version "pre-2005-05" "Version of `axiom-run.el'.")
   
(defvar axiomRun-before-axiom-start-hook nil)
(add-hook 'axiomRun-before-axiom-start-hook 'axiomRun-configure-term-var)

(defun axiomRun-configure-term-var nil
  (if (not (getenv "TERM")) (setenv "TERM" "xterm")))

(defvar axiomRun-commandline "axiom -noht -noclef")

(defvar axiomRun-buffer-name "*Axiom*")

(defvar axiomRun-base-directory "/tmp/")

(defvar axiom-run-mode-map nil "Keyboard for axiom-run-mode.")
(when (not axiom-run-mode-map)
  (let ((map (make-sparse-keymap)))
    (define-key map [(control return)] (function axiomRun-from-edit-to-todo))
    (define-key map [(control c)(control c)] (function axiomRun-send-break))
    (setq axiom-run-mode-map map)))

;
; (almost) all variables are local. 
; 
; There is three area in the buffer 
; 1/ axiom writes results between the first char to axiomRun-marker-todo.
; 2/ After a [C-return] commands are in the todo area, 
;    from axiomRun-marker-todo to axiomRun-marker-edit.
; 3/ The user types his command at the end of the buffer, after
;    axiomRun-marker-edit.
; 
; This edit area begins at the first empty-line, not 
; on the prompt-line. So there are not problems for indent.
;

(defvar axiomRun-process nil)
(defvar axiomRun-buffer-name-history (list axiomRun-buffer-name))

(defun axiom-run-mode ()
  "Major mode version `axiom-run-mode-version' for running Axiom code.
\\<axiom-run-mode-map>
The main work is to run axiom in an emacs buffer.

Available special keys:
\\{axiom-run-mode-map}"
  (interactive)
  (when (mupad-run-mode-control)
    (unless mupad-run-less-questions (mupad-run-commandline-ask))
    (mupad-run-mode-intern)))

(defun axiomRun-axiom-run-p nil
  (cond
    ((and
        (eq major-mode 'axiom-run-mode)
        (boundp 'axiomRun-process)
        (processp axiomRun-process))
      t)
    ((and (boundp 'axiomRun-process) (processp axiomRun-process))
        "Incomplete or missing axiom-run-mode initialisation")
    ((eq major-mode 'axiom-run-mode) "Axiom doesn't run in the buffer")
    (t nil)))

(defun axiom-run nil 
  (interactive)
  (switch-to-buffer axiomRun-buffer-name)
  (axiomRun-before-axiom-start-in-buffer))

(defun axiom-batch nil 
  (interactive)
  (let ((oldbuf (current-buffer)))
    (save-excursion
      (get-buffer-create axiomRun-buffer-name)
      (axiomRun-before-axiom-start-in-buffer))))

(defun axiom-run-bis nil  
  (interactive)
  (switch-to-buffer 
    (axiomRun-read-buffer-name 
      "Name of the axiom-buffer : "
      (if (get-buffer "*Axiom*") "*Axiom<2>*" "*Axiom*")))
  (axiomRun-before-axiom-start-in-buffer))

(defun axiom-batch-bis nil 
  (interactive)
  (let ((oldbuf (current-buffer)))
    (save-excursion
      (get-buffer-create 
        (axiomRun-read-buffer-name 
          "Name of the axiom-buffer : "
          (if (get-buffer "*Axiom*") "*Axiom<2>*" "*Axiom*")))
      (axiomRun-before-axiom-start-in-buffer))))

(add-hook 'kill-buffer-hook 'axiomRun-kill-axiom)
(defun axiomRun-kill-axiom nil 
  (and 
     (eq major-mode 'axiom-run-mode)
     (boundp 'axiomRun-processss) 
     (processp axiomRun-process)
     (delete-process axiomRun-process)))

(defun axiomRun-read-buffer-name (prompt &optional initial-input)
  (completing-read prompt
    (mapcar #'(lambda (buf) (list (buffer-name buf))) (buffer-list))
    ;; don't take buffers that start with a blank
    #'(lambda (list) (not (eq (aref (car list) 0) ? )))
    nil
    initial-input))

(defun axiomRun-before-axiom-start-in-buffer nil
  (let ((tmp (axiomRun-axiom-run-p)))
    (cond 
      ( (eq tmp nil) (axiomRun-axiom-start-in-buffer))
      ( (eq tmp t) nil)
      ( t (error tmp)))))  

(defun axiomRun-axiom-start-in-buffer nil
  (run-hooks 'axiomRun-before-axiom-start-hook)
  (kill-all-local-variables)
  (use-local-map axiom-run-mode-map)
  (mapcar (lambda (var) (make-local-variable var))
    '(axiomRun-process axiomRun-output-str axiomRun-kernel-state
      axiomRun-marker-begin-last-output 
      axiomRun-marker-todo axiomRun-marker-edit 
      axiomRun-item-results axiomRun-item-todo))
  (setenv "COLUMNS" (format "%d" (frame-width)))
  (setq major-mode 'axiom-run-mode)
  (setq mode-name "axiom-run")
  (setq axiomRun-marker-begin-last-output (make-marker))
  (setq axiomRun-marker-todo (make-marker))
  (set-marker axiomRun-marker-todo (point))
  (setq axiomRun-marker-edit (make-marker))
  (set-marker axiomRun-marker-edit (point))
  (setq axiomRun-item-results 1)
  (setq axiomRun-item-todo 1)
  (setq axiomRun-output-str "")
  (setq axiomRun-kernel-state 'run)
  (setq axiomRun-process 
    (apply 
      (function start-process)
      (buffer-name)
      (current-buffer) 
      (split-string axiomRun-commandline)))
  (set-process-filter axiomRun-process 'axiomRun-filter))

(defun axiomRun-filter (proc str)
  (let ((oldbuf (current-buffer)))
    (axiomRun-debug "in filter" "START : in-filter")
    (set-buffer (process-buffer proc))
    (save-excursion
      (goto-char axiomRun-marker-todo)
      (setq tmp-pos (point))
      (insert-before-markers str)
      (axiomRun-kernel-state))
    (axiomRun-debug "in filter" "END   : in filter")
    (set-buffer oldbuf)))

(defun axiomRun-kernel-state nil
  (when 
    (and 
      (eq axiomRun-kernel-state 'begin)
      (goto-char (1+ axiomRun-marker-begin-last-output))
      (looking-at "\\(\015(.*) -> \015\\)"))
    (delete-region (point) (match-end 1))
    (setq axiomRun-kernel-state 'run))
  (when 
    (and 
      (eq axiomRun-kernel-state 'after-quit)
      (goto-char (1+ axiomRun-marker-begin-last-output))
      (looking-at "\015"))
    (delete-region (point) (1+ (point)))
    (setq axiomRun-kernel-state 'run))
 (goto-char axiomRun-marker-todo)
 (beginning-of-line)
 (when 
   (and 
     (posix-looking-at "\\(^(.*) -> \\)")  
     (= (match-end 1) (marker-position axiomRun-marker-todo)))
   (goto-char axiomRun-marker-todo)
   (insert-before-markers "\n")
   (setq axiomRun-kernel-state 'wait)
   (axiomRun-from-todo-to-axiom))
 (when (and (eq axiomRun-kernel-state 'run) (posix-looking-at "^\015"))
   (delete-char 1)
   (setq axiomRun-kernel-state 'quit)))
     
(defun axiomRun-from-edit-to-todo nil
  (interactive)
  (axiomRun-debug "in from-edit-to-todo" "START : from-edit-to-todo")
  (let (tmp-pos tmp-block)
    (cond 
      ( (and
          (<
            (marker-position axiomRun-marker-todo)
            (marker-position axiomRun-marker-edit))
          (memq axiomRun-kernel-state '(wait quit)))
        (axiomRun-from-todo-to-axiom)
        (axiomRun-from-edit-to-todo))
      ( (eq (marker-position axiomRun-marker-edit) (point-max))
        (goto-char (point-max)))
      ( t 
       (axiomRun-from-edit-to-todo-aux)
       (axiomRun-from-edit-to-todo)
  (axiomRun-debug "in from-edit-to-todo" "END : from-edit-to-todo")))))

(defun axiomRun-from-edit-to-todo-aux nil
  (axiomRun-debug "in from-edit-to-todo-aux" "START : from-edit-to-todo-aux")
  (goto-char axiomRun-marker-edit)
  (unless (posix-search-forward "^ *$" nil t)(goto-char (point-max)))
  ; the current point is now at the end of the first empty line
  (if (< (point) (point-max)) (forward-char 1)) 
  ; the current point is now at the beginning of a new line
  ; this loop jumps over all the empty-line, 
  ; and goes at the beginning of the first new block
  (while (and (< (point) (point-max))(posix-looking-at "\\(^ *$\\)"))
    (goto-char (match-end 1))
    (if (< (point) (point-max)) (forward-char 1)))
  ;  insert a new line at the end of the buffer without new-line
  (if (< (point-at-bol) (point)) (insert "\n"))
  (setq tmp-block (buffer-substring axiomRun-marker-edit (point)))
  (delete-region axiomRun-marker-edit (point))
  (goto-char axiomRun-marker-edit)
  (setq tmp-pos (point))
  ; the command is now in the todo area
  (insert-before-markers tmp-block)
  ; the at the beginning of the todo area must go back in this case
  (if 
    (= 
      (marker-position axiomRun-marker-edit)
      (marker-position axiomRun-marker-todo))
    (set-marker axiomRun-marker-todo tmp-pos))
    (put-text-property tmp-pos (point) 'axiomRun-todo axiomRun-item-todo)
    (setq axiomRun-item-todo (1+ axiomRun-item-todo))
  (axiomRun-debug "in from-edit-to-todo-aux" "END   : from-edit-to-todo-aux"))

(defun axiomRun-from-string-to-input-file (str)
  (let 
    ( (tmp-file-name
       (concat 
         axiomRun-base-directory 
         (format "axiomacs-%d-%03d.input" 
           (process-id axiomRun-process) axiomRun-item-results))))
    (with-temp-buffer (insert str) (write-file tmp-file-name))
  tmp-file-name))

(defun axiomRun-from-todo-to-axiom nil
  (interactive)
  (if 
    (/= 
      (marker-position axiomRun-marker-todo)
      (marker-position axiomRun-marker-edit))
    (axiomRun-from-todo-to-axiom-aux)))

(defun axiomRun-from-todo-to-axiom-aux nil
  (axiomRun-debug "in from-todo-to-axiom-aux" "START : from-todo-to-axiom-aux")
  (cond 
    ( (eq axiomRun-kernel-state 'wait) 
      (axiomRun-from-todo-to-axiom-file))
    ( t (axiomRun-from-todo-to-axiom-line)))
  (axiomRun-debug "in from-todo-to-axiom-aux" "END : from-todo-to-axiom-aux"))

(defun axiomRun-from-todo-to-axiom-file nil
  (axiomRun-debug 
    "in from-todo-to-axiom-file" 
    "START : from-todo-to-axiom-file")
  (let ((tmp-pos (marker-position axiomRun-marker-todo))
        tmp-pos2 tmp-str tmp-file)
    (goto-char axiomRun-marker-todo)
    (setq tmp-pos2 
      (or 
        (next-single-property-change (point) 'axiomRun-todo) 
        axiomRun-marker-edit))
    (setq tmp-str (buffer-substring tmp-pos tmp-pos2))
    (delete-region tmp-pos tmp-pos2)
    (setq tmp-file (axiomRun-from-string-to-input-file tmp-str))
    (goto-char axiomRun-marker-todo)
    (setq axiomRun-item-results (1+ axiomRun-item-results))
    (setq axiomRun-kernel-state 'begin)
    (backward-char 1)
    (set-marker axiomRun-marker-begin-last-output (point))
    (process-send-string axiomRun-process (concat ")read " tmp-file "\n"))
  (axiomRun-debug "in from-todo-to-axiom" "END : from-todo-to-axiom")))

(defun axiomRun-from-todo-to-axiom-line nil
  (axiomRun-debug 
    "in from-todo-to-axiom-line" 
    "START : from-todo-to-axiom-line")
  (let ((tmp-pos (marker-position axiomRun-marker-todo))
        tmp-pos2 tmp-str tmp-file)
    (goto-char axiomRun-marker-todo)
    (end-of-line)
    (setq tmp-pos2 (1+ (point)))
    (setq tmp-str (buffer-substring axiomRun-marker-todo tmp-pos2))
    (delete-region axiomRun-marker-todo tmp-pos2)
    (goto-char axiomRun-marker-todo)
    (setq axiomRun-item-results (1+ axiomRun-item-results))
    (setq axiomRun-kernel-state 'after-quit)
    (backward-char 1)
    (set-marker axiomRun-marker-begin-last-output (point))
    (process-send-string axiomRun-process tmp-str)
  (axiomRun-debug 
     "in from-todo-to-axiom-line" 
     "END : from-todo-to-axiom-line")))

(defun axiomRun-send-edit-to-axiom nil 
  (interactive)
  (let ((tmp (buffer-substring axiomRun-marker-edit (point-max))))
    (save-excursion
      (delete-region axiomRun-marker-edit (point-max))
      (process-send-string axiomRun-process (concat tmp "\n")))))

(defun axiomRun-send-break nil 
  (interactive)
  (process-send-string axiomRun-process "\003"))

; (defun axiomRun-from-todo-to-result nil)

(defun axiomRun-get-prop nil 
  (interactive)
  (let ((tmp (get-text-property (point) 'axiomRun-todo)))
    (if (not tmp) (message "NIL") (message (format "numero : %d" tmp)))))

(defun axiomRun-next-change nil
  (interactive)
  (goto-char 
    (or (next-single-property-change (point) 'axiomRun-todo) (point-max))))

(defvar axiomRun-debug-list '())
; (defun axiomRun-debug (name message) (message name))
 (defun axiomRun-debug (name message) nil)

\start
Date: Mon, 30 May 2005 19:02:16 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom In Emacs] (new) 

On May 30, 2005 3:38 PM Francois Maltey wrote:

a very little emacs mode for axiom.

  I send here my very first axiom-mode for emacs. 
  It isn't a finish program.

  It's like the maxima mode for emacs, but without latex. 
  I translate and clear my mupad-run-mode.el file.

  You can tell me what you want.

  I don't know how to use axiom debugger, 
  so I don't what emacs-key will be fine.

  It's work with xemacs on a linux box.

<hr>
Download it here: 

<a href="axiomacs-smallest.el">axiomacs-smallest.el</a>

\start
Date: Tue, 31 May 2005 04:13:08 -0500
From: MathAction (Francois Maltey)
To: MathAction
Subject: [Axiom-mail] a very little emacs mode for axiom.

Dear Martin,

> I tried to use that mode -- I guess I need to say M-x axiom-run-mode --
> however, emacs was complaining about

No, you start the axiom-run mode by 


***************************************************************************
*                                                                         *
*                               axiom-run                                 *
*                                                                         *
***************************************************************************

You can also use axiom-run-bis, axiom-batch or axiom-batch-bis.

The -bis allows many axiom at the same time.
The -batch- functions don't display this buffer.

axiom-run-mode is the name of the mode.
I copy it from mupad-run-mode, and I don't understand everything
with custom and keyboard.

So I hope you can start axiom. 

Please tell me what you want. I'll try to do it first.

Perhaps a function whith copy the current paragraph of your axiom source-file
and send-it to the *Axiom* buffer.

I don't know how to select the axiom current function, 
but I can select the text between to empty line around the cursor.
So it's an easy method if

1/ There are no empty-line in the function definition.
2/ You let an empty line between functions.

Do you have an other idea ?
Do you use )?? ?? ?? commands ? for debugging ?

\start
Date: Tue, 31 May 2005 11:33:59 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom In Emacs] 

++added:
<hr>
You start the axiom-run mode by::

  axiom-run

You can also use 'axiom-run-bis', 'axiom-batch' or 'axiom-batch-bis'.

The '-bis' allows many axiom at the same time.
The '-batch-' functions don't display this buffer.

*axiom-run-mode* is the name of the mode.
I copy it from mupad-run-mode, and I don't understand everything
with custom and keyboard.

So I hope you can start axiom. 

Wish List

  Perhaps a function which copy the current paragraph of your
axiom source-file and send-it to the *Axiom* buffer.

I don't know how to select the axiom current function, 
but I can select the text between to empty line around the cursor.
So it's an easy method if

1 There are no empty-line in the function definition.

2 You let an empty line between functions.

Do you have an other idea ?

Do you use ) commands ? for debugging ?

\start
Date: Tue, 31 May 2005 11:51:42 -0500
From: MathAction (Sergey Ten)
To: MathAction
Subject: [Axiom-mail] How to work with vectors without giving them a value ?

I want to work with vetors in the symbolic form

(X, Y, Z ) : Vector Polynomial Integer

but whenver I'm doing something like

X  := Y + Z

I'm getting

X is declared as being in Vector Polynomial Integer but has not been  
given a value.

So is it possible at all to work with vector in the symbolic form, 
without specifing components ?
