Re: [Gcl-devel] RE: [Axiom-developer] Possible GCL 2.6.7 for axiom

[Camm Maguire]

Greetings!

C Y <address@hidden> writes:

> --- "Page, Bill" <address@hidden> wrote:
> > But we should be clear I think, that this is not necessarily
> > the shortest path to a fully functioning version of Axiom on
> > Windows. The linux version of Axiom does not now use tcl/tk
> > for Graphics and Hypertex, i.e. those parts of Axiom that are
> > not already ported to Microsoft Windows. Instead these currently
> > depend directly on the X windows libraries. These should perhaps
> > be re-implemented in tcl/tk linux first before attempting the
> > port to Windows.
> 
> I wasn't able to attend the conference :-(, and in discussing this
> possibility I'm admittedly skating on vapor trails and assuming skills
> I don't currently have, but if at some point in the future a QT4
> backend was written for McCLIM and somebody (me for the sake of
> discussion anyway) implimented a GUI CAS interface in it, would that be
> of interest to Axiom?  

Wonderful initiative!

These are just my simple thoughts on these broader questions:

1) I worry a lot that concern over graphics, as valuable as it is,
   detracts seriously from developer attention to the core math
   abilities of these systems.

2) In keeping with the above, there seems to be a well-intentioned
   desire to try to attract mass market users with dazzling eye candy.
   My only quibble is one of priority -- what are these attracted
   users going to contribute back to the community?  If we did attract
   them now, are we ready to respond to a deluge of feature requests
   and complaints?  If not, will these users turn against the project
   when their desires are not immediately gratified and the latest
   alternative toy becomes available?

3) I also worry that we are not mass marketing specialists, and that
   we cannot design a system based on what we imagine 'those users out
   there' want.  What we can do is develop the system so that it
   presents real value to the work *we actually do*, fix the bugs that
   bother us, add what we think is imperative for us to be able to
   rely on the system ourselves, etc.  If we do this, others like us
   are bound to see the value too, and some of them will join us.  If
   and when we get a large enough team intimately familiar with the
   system, we can then try to reach out little by little to the mass
   market, who are most likely to be 'takers' rather than 'givers' by
   simple necessity of the overwhelming complexity of these systems. 

4) To the extent that we adopt this perspective, the only critical
   need for graphics in these systems is the ability to plot and print
   mathematical functions, IMHO.  At this early stage in its open
   source life, I would recommend axiom adopt the simplest and most
   portable system with a sizable user base, preferably maintained and
   developed externally, and to then move on to the algorithms.
   Maxima has adopted gnuplot, which I think is a wonderful and
   powerful choice.  We have a working alternative system now and
   there is no need to throw this away, but if we ever feel the need
   to do something new in this area (for example, because our existing
   graphics does not yet work on Windows), this is the direction I
   would recommend for now.

5) In the longer term, lisp graphics is certainly very interesting,
   and some beautiful work from a programming point of view has been
   done, notably the McCLIM to which you refer.  The only problem here
   which is nonetheless quite serious is the lack of unity or
   consensus.  No one can afford to invest the time in putting
   something together if they run the extremely high risk that it will
   be abandoned later due to the extraordinary degree of fractiousness
   in this area.  People need to see the payback measured in terms of
   user contributions in the future -- in this way they lever their
   own efforts.  Ask the question, "If I do this, what new user
   contributions will I likely trigger?"

6) Here is a list of lisp graphics options of which I am aware, all of
   which are workable with possible modest effort within GCL, but none
   of which appear to have any serious use by any existing
   applications.  (Please correct me if I am mistaken:)

        a) xgcl -- http://www.cs.utexas.edu/users/novak/cgi/xgcldemo.cgi
        b) gcl-tk -- (tk::connect)(load "...gcl-tk/demos/widget.lsp")
        c) ltk  -- another tk binding
        d) gtk-based -- cl-gtk, lgtk, http://www.cliki.net/Gtk
        e) garnet -- http://garnetlisp.sourceforge.net/
        f) clx, clue, clio, clim, mcclim
        g) cells/cello -- comp.lang.lisp
        h) Java based japi -- lsp/gcl_japi.lsp

7) In deciding among these longer term options, please let me
   emphasize that any are likely workable, but it is very important
   IMHO that we pick at most one if we are to avoid wasting our
   lives.  I also think it important that we

        a) choose a purely open source option

        b) cross-platform

        c) wide user base -- this effectively means a huge C user base
        with a smaller user base of tight lisp bindings

        d) robust

        e) actively developed elsewhere

        f) comes with a graphical interface builder -- as attractive as
        graphical programming in lisp might be, even though it is lisp,
        it is still much less efficient IMHO than using a tool like
        glade.  I've used this myself in C, and I haven't had to write
        a single gtk call.

        g) LGPL is preferable to GPL if we're doing a general
        interface, but I have no problems with GPL myself.

   All of this would appear to argue in favor of cl-gtk or the like.
   Tim Daly Jr. has worked on it, and he indicates it would probably
   take a week's work to get running under GCL.  We need to know how
   good the Windows and MacOSX ports are.  *If we all agree* that this
   is the way forward, I'll be happy to donate a few cycles to moving
   it along.

> QT4 will be available as GPL for both Windows
> and Linux, which will make it an attractive target for an McCLIM
> backend.  (GTK is available but I find myself drawn more toward QT.  Of
> course, this doesn't rule out a GTK backend either.  Hehe - maybe one
> could write one program with a native look on BOTH KDE and Gnome :-D.) 
> I am pondering undertaking a backend attempt once QT4 comes out for the
> sake of creating a Maxima GUI which is a) lisp based and b) cross
> platform.  If Scigraph can be made to work and be extended as needed,
> this would also provide lisp based graphics in a cross platform manner.
>  The half-mythical Stix fonts may also be out by then (at long last
> their site was updated - drool.) Logically much of this should
> translate relatively easily to Axiom - in fact it should mainly be an
> issue of translating between McCLIM constructs and Axiom syntax, with
> the added non-trivial wrinkle of line breaking.  (Who knows -
> McCLIM+QT4 might just become the best thing for cross platform native
> GUI programming since Java, if the planets align right :-).  Lisp will
> rise once more!)

I think this is wonderful!  If you have the time to take this ball and
lead with it, I'll be happy to support.  As stated above, I think gtk
is a slightly better choice than QT, but *whatever draws consensus* is
the best!


> 
> I suppose I'm biased against tcl/tk but the Maxima experience with it
> has not been terribly positive, and it's not what I tend to think of
> when I think robust graphics.  Perhaps this is just my lack of
> knowledge.
>  

This is well founded, I think.  tk is quick and portable, not
necessarily 'robust and polished'.  The importance of the latter for
these considerations is questionable.  Can you describe the maxima
experience?  


> > Because of this X windows dependency the shortest path,
> > though admittedly not necessarily the best path, for fully
> > implementing Axiom on Windows would probably be to use Cygwin.
> > Currently GCL on windows uses MinGW instead of Cygwin to
> > compile to native Windows but unlike Cygwin MinGW does not
> > provided an X windows compatible environment.
> 
> True.  MinGW is the best available free solution for stand alone
> Windows binaries though, at least to my knowledge.  And Windows users +
> X applications, in my experience, does not a happy mix make.
> 
> > I think using native Windows applications on Windows is a
> > wothwhile target but it is sometimes hard for applications
> > that originate on linux/Unix.
> 
> Amen.  To both.
> 
> [snip partial cygwin solution]
> 
> > Of course there are drawbacks. Using *both* MSYS/MinGW and
> > Cygwin under Windows would further complicate the Windows
> > build environment for Axiom. Currently there is no Cygwin
> > version of GCL. Further, the X windows user interface under
> > Cygwin might seem a little awkward for some Microsoft
> > Windows users. But it should still be possible to prepare an
> > auto-installation binary distribution that would make much
> > of this transparent for users who are not interested in
> > building Axiom from source.
>  
> It will be HUGE, but yes, that might be workable.  I can't imagine how
> Windows users would react to an Xlib base GUI - GTK is bad enough. 

Here too -- what are your misgivings concerning gtk on Windows?

Take care,

> Still, it's a case of any GUI being much better than none, and recent
> versions of Cygwin X can at least operate on a per-window basis rathern
> than desktop only, so in theory it should work.
> 
> [snip]
> 
> > Yes! I think that would be a great step forward. I think
> > Axiom should conform more closely to the de facto norm
> > for building open source software.
> 
> I'll second that!  The make install process still goes wonky for me on
> Gentoo, and I have seen a second report of the same behavior so it's
> probably not just my screwed up system.
>  
> CY
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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