[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] RE: [Gcl-devel] Re: axiom porting
Re: [Axiom-developer] RE: [Gcl-devel] Re: axiom porting
02 May 2005 11:36:58 -0400
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
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
> 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.
> Bill Page.
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah