[Gcl-devel] Re: axiom porting

[Camm Maguire]

Hi Tim!

address@hidden writes:

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

I think this is great!

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

But here we're doing something new upfront, no?  Would a small initial
stage project of rewriting the xlib calls to MS equivalents in the
hypertex C code give us a little more time to evaluate different lisp
options?  After all, this only need be done on one port, Windows.

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

This is a terrific goal.  Might take some time, but as you say -- we
have thirty years!  

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

Are you primarily aiming at the graphics, or the hypertex, or both?
What do you think of Bill Page's idea using a system browser for the
latter, as I assume it could not handle the former?

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

Well, run-process will talk to any external windowing program.  The
trick is in abstracting all the options to one lisp api, and this
would appear hopeless.  My opinion is that we need to choose one that
will last us at least ten of the next thiry years, and make it work
well.  

Let me just briefly bring up the issue of performance, which is likely
of little concern to us.  Talking down a pipe to an external program
will never be as fast as making the windowing calls directly from the
image, which is also possible.  Unless we're contemplating animation,
I don't think we'll ever see the difference.

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

gnuplot is completely free software -- it passes the widely accepted
definitions found in the Debian Free Software Guidelines, and is thus
in Debian's main (not non-free or contrib) archive.  You can
distribute any modifications you wish in the form of patches.

As to portability, this is perhaps the most widely portable option at
the present moment.  It might not have been an easy job, but someone
else already has done it, and is continuing to do so, which appears to
me highly attractive from axiom's vantage point.

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

Did you get my fix for this posted yesterday?


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

Perhaps, but all the solutions will require work, alas, and what one
gets with gtk is glade.  Please take a moment and play with the
program.  The entire interface is generated graphically, with no
coding in any language, and dumped as a purely portable xml file.
There is cl-glade which loads this interface into acl.  I've
downloaded it, and it can be made to work in GCL, but I'll refrain
from spending time here unless we are sure this is the way we'd like
to go. 

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

Agreed!

> Of course, it's all open to discussion.
> 

Thank you so much for your work here and everywhere, Tim!

Take care,

> Tim
> 
> 
> 
> 

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