gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Camm Maguire
Subject: Re: [Axiom-developer] RE: [Gcl-devel] Re: axiom porting
Date: 02 May 2005 11:36:58 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Bill Page <address@hidden> 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.

Take care,

> Regards,
> Bill Page.
> 
> 
> 
> 

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]