[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] RE: [Axiom-developer] Possible GCL 2.6.7 for axiom
Re: [Gcl-devel] RE: [Axiom-developer] Possible GCL 2.6.7 for axiom
27 Apr 2005 11:09:23 -0400
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
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?
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
c) wide user base -- this effectively means a huge C user base
with a smaller user base of tight lisp bindings
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
> 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
> 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
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
> > 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?
> 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.
> > 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.
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> Gcl-devel mailing list
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah