Re: [Axiom-developer] Windows front end

[Mike Dewar]

On Thu, Nov 28, 2002 at 10:35:20AM -0500, Tim Daly wrote:
<snip> 
> > 1. Graphics: On Unix this is done with a combination of bespoke Axiom
> > data structures and some pretty convoluted X-Windows code.  On Windows
> > we added facilities to create OpenInventor data structures (OpenInventor
> > is the basis for VRML - the virtual reality markup language).  The
> > Inventor geometries were then exported to a little application we wrote
> > based on the standard SceneViewer application you get with many
> > OpenInventor toolkits.  The results were definitely superior to the Unix
> > version.
> 
> Is the "little application" in the code we have? If not, would NAG
> be willing to share it?
No and no :-(  As I said its based on something which was part of the
Inventor toolkit we were using and that is a commercial product which we
were licensing.  However it shouldn't be too difficult to find a free VRML
viewer and adapt that.  

> 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.

> The graphics facility is useful and necessary but the expertise needed
> to do it right is a whole other field of research. Scott Morrison did
> the graphics and he's no longer following computer algebra.
Don't underestimate the importance of visualisation and computer
algebra.  Over the years I've met a number of users who chose Axiom
primarily because of its graphics.
 
> If you happen to have some useful web and/or book references I'd
> appreciate it if you mention them to the group.
http://www.web3d.org/vrml/vrml.htm seems to be agood place to start
investigating VRML.
 
> I hope to define the input and output formats of the interpreter so
> that others can use it. Ideally there would be 3 "pairs" of connections:
> 
> Stdin, Stdout for the interpreter/console
> Stdin, Stdout for ethernet ports so you can reach the interpreter
>   from network based code (and even the browser/graphics applications)
> Stdin, Stdout "covers" for linked programs on the same system
> 
> If we do that cleanly then all of the other things will just be
> stand-alone applications that can communicate with the Axiom interpreter.
> That way we can also leverage them for Aldor.
A lot of this works already (its how sman communicates with the
interpreter) and we've experimented with reading and writing OpenMath as
well.  The biggest difficulty might be replacing InputForm which looks simple
enough but has some quite complicated parsing rules.   

> > I wouldn't try porting the X-based graphics to Windows but would either
> > use the OpenInventor stuff and one of the free VRML viewers or use the
> > same approach with a different standard format.  For 3D graphics the OI
> > stuff worked pretty-much out-of-the-box, we just added menus for axes,
> > scales etc.  For 2D plots we had to add some extra code but that wasn't
> > too hard.
> 
> I'll take that advice. Do you happen to know of compatible VRML viewers
> that work on both Windows and Unix?
Well the SceneViewer application which came with our toolkit works on
both (as does our Iris Explorer product which also uses it).  I think
that there are some Java applications for VRML which presumably work on
both, although they might depend on other things such as OpenGL libraries
being available.
  
> The browser was a piece of the system that was leading edge
> for its time (the web and browsers didn't exist yet). The stated
> plan is to "give away" the browser. In this case what that implies
> is rewriting the system so it uses a real browser instead of our
> home-grown one.
> 
> Surely you didn't write lisp that runs on only one platform?! Sigh.
Certainly not, what a disgraceful slur (although I have been known to
write lisp that runs on no platforms at all) :-)  When I said that we
changed the underlying lisp I meant that we added C code to CCL and
exposed it as lisp functions (i.e. the grep commands in CCL aren't part
of Common Lisp). 

You should bear in mind that when we started the porting exercise to CCL
it didn't exist as such, and was in fact CSL (as in the inaptly-named
standard lisp used by Reduce).  I don't think CCL is a complete common
lisp implementation and I'm sure that we used some of the standard lisp
feautures/behaviours somewhere, even though we tried to avoid doing so.

> In this world the docs are supposed to be in noweb pamphlets from
> which we can generate LaTeX. Hopefully the front-end will handle the
> cross-platform issues so we don't have to.
Sounds good :-) 

> As I said earlier, Axiom is likely to make its first appearance as
> a command-line interpreter (no doubt causing us to take some flak).
> Rebuilding the rest of the tools is going to be an exercise in
> creativity. It will have the unfortunate side-effect that I'll
> have to learn Windows :-)
Tell me about it ...

Cheers, Mike.

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.