RE: [Axiom-developer] RE: [Gcl-devel] Re: axiom porting

[Page, Bill]

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? :)

Regards,
Bill Page.