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

[Camm Maguire]

Greetings!

"Page, Bill" <address@hidden> 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?

Take care,

> Regards,
> Bill Page.
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah