axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] axiom porting


From: daly
Subject: [Axiom-developer] axiom porting
Date: Thu, 28 Apr 2005 12:37:54 -0500

Lots of discussion and interest on this subject I see...

My current thinking on the matter is that the first priority will
be to just get it working the way it was. This has several dimensions.

The code is now in C/X11, neither of which is very portable. C has
more ifdefs than code and X11 won't work on windows. 

The cygwin path could potentially allow a direct port but is not of
interest for other reasons. I've tried cygwin before as the initial
porting platform and it was painful. Plus, having both cygwin and msys
would be a bit much. So this rules out the X11-on-windows version.

Which implies a rewrite to use a different code base and a
different windowing scheme.

With respect to a code rewrite I've decided to rebuild the code in
common lisp for several reasons. First, it is easier to port. Second,
it is a language I know well. Third, it will allow us to "lift" the
windowing functions up into the axiom system proper so other people
can create windows in their code. Fourth, it will allow the unification
of windowing/graphing data structures and spad data structures.

With respect to the windowing scheme we are confronted with a large
variety of front-end mechanisms. In any of the proposed mechanisms
we need a working example of, for instance, the first page of the
hyperdoc browser. That will ground the proposals in reality. For example,
http://daly.axiom-developer.org/TimothyDaly_files/pamphlets/jman.pamphlet

The current plan is to have some sort of dumb front-end that implements
some low-level graphics API and move the rest of the code into lisp.
The graphics API needs to cover both the browser and graphics abilities.

As I've mentioned I've tried various paths. Camm, Bill, and I had a 
discussion about these during the sprint day. Camm pointed me at the
sources for TK. I've already written a piece of a TK replacement in Java.

TK might work. I'm going to the bookstore today to get educated about
the details. Since both TK and my Java code use sockets it would seem
that we could use a common syntax. Such an approach would make it easy
to shift between the two front ends. I'm not sure how feasible this is.

I've looked at GNUPLOT but their license does not seem to allow me to
modify and distribute. And their code has more ifdefs than C code which
is a sure sign of a porting headache.

I've looked at McClim which is a path I'd dearly love to take but so
far I've not gotten it to work. If someone could reproduce the first
page of the browser (a few buttons, an image) in McClim that might be
enough to get me over the hurdle. A pure lisp solution is preferred.

The graphics and browser run in separate threads using sockets to
communicate to the algebra. Due to the run-process issue in GCL the
front end is being done using CLISP but nothing in the code cares
which lisp is used.

I've spoken to Tim Daly Jr. about the lisp-gtk work and he believes
it is not ready for production use.

The SVG, VRML, CSG, and Flash enhancements would be nice but are
definitely in the future development categories. There is still a
huge amount of algebra work to be done before any work gets applied
to enhancing the graphics.

Of course, it's all open to discussion.

Tim





reply via email to

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