C Y <[EMAIL PROTECTED]> writes: > ... >>>> 1. I think a default GUI for Axiom would be a Very Good Thing >> >>Kai Kaminski wrote: >>> As I said, I'm not convinced.
I am convinced that trying to build a graphical user interface that works only with Axiom would *not* be a good thing. > > > > No worries. There is plenty of room here for differing > > opinions :-). > On September 8, 2006 9:56 AM Kai Kaminski wrote: > Don't kid yourself. There's barely enough room for mine. ;-) > I do appreciate the sentiment in Kai's remark, which he indicates we should take as humour. But I am worried that some people who are potential contributors to this discussion might well perceive it as fact. If so, I think that is very unfortunate. Axiom is a very small project in terms of the number of active and vocal developers so it is easy to give the wrong impression. My opinions about Axiom development differ from other people on this list on a number of points and I don't feel shy about saying so. Is that setting an example or reinforcing the feeling that there is no more room for other opinions? :( Perhaps we need to do more to make sure that people feel like there is room here for differing opinions and that we would really like to hear them. >>>> 2. The project is not yet at a point where this should be a >>>> major focus for the project as a whole. >>> >>> That depends on what you mean. I believe the most important thing >>> is to make it developer friendly. Yes! >>> In particular we must be able to use all the open source Lisp >>> libraries that are available. Also, writing tools (especially >>> GUIs) for Axiom should be easy. While I would welcome anyone interesting in working on Axiom at the level of the Lisp code, I seriously doubt whether compatibility of Axiom with other open source Lisp libraries would make Axiom more "friendly" to such developers. Or did you have some specific libraries in mind that would have immediate application and mass appeal? >> >> Right. What I meant was we shouldn't be (as a project) worrying >> about GUI design when we can't run on ANSI lisp yet. > > Exactly. By making GUI development easy other people who can't or > don't want to work on the more pressing problems (ANSIfication, > Spad/Aldor, elimination of BOOT [that one's for you, Bill ;-)] etc) > can start working on GUIs... Thanks Kai :-). Yes, I am glad that only one Axiom developer seems to be actively wasting his time on the idea of eliminating higher level languages from Axiom... ;) About ANSI lisp and licensing Aldor as open source, I agree that indeed these are pressing problems - even "mission critical" problems! If we don't solve these soon, I have little hope for the immediate future of Axiom let alone the next 30 years. > Later, when the more imminent problems have been solved, we can > look at the existing GUIs and figure out where to go from there. > Why should GUI development have to wait until everything else has > been taken care of? It should not and it isn't. > >>>> 4. Code counts more than opinions, so I'll be quiet until I >>>> have more of the former ;-). >> >>> I'm not so sure about that. How can anyone start coding if there is >>> no consent of what the core of Axiom is and what features it should >>> offer to GUIs? >> >> Well, that's a bit different. What we should expose to GUIs and how >> is probably somewhat separate from how the GUIs use that information. >> The latter is usually where most of the trouble comes in :-). > > It is indeed very different. Of course, the former should be guided > by the latter. Since we don't really know what a great GUI should > look like, we'll have to take some educated guesses and then wait for > feedback. Having already implemented several user interfaces for Axiom, e.g. TeXmacs, MathAction, AxiomUI and (soon) Sage, we do know very well the kind of information and communications protocols that would make these systems easier to program and more robust. > ... >> >> Well, if what I have heard about Lisp holds true in GUI programming >> it should be fairly hard for anybody to create a feature we can't >> incorporate one way or another ;-). The idea of a literate GUI >> program ... > > That doesn't imply that it's a good idea. Besides you have to consider > library issues. Despite Lisp's greatness as a language, there isn't > good support for native Cocoa (Mac) user interfaces. In fact it's not > even clear that there ever will be. On Windows there is an effort for > a native GUI library, but it's still in alpha as far as I know (google > for 'graphics-forms'). Even if that succeeds you might be better off > with Visual Basic (as sad as that is). > ... I am afraid that I have to agree with Kai. We should not be tempted to try to use Axiom as a fulcrum on which to lever renewed interest in Lisp. To do so would almost certainly crush Axiom. In contrast to the situation when most of Axiom was designed and implemented, there are many other programming languages available today that are capable of supporting Axiom and this is especially true when it comes to GUI development. >> 2. 2 and 3-D plotting, interactive manipulation, etc. IZIC has >> done some work that I like, and VTK is also very nice - adapting >> those ideas and some work that has been done on how to do high >> quality mathematical plotting is probably the second hardest part, >> or even hardest if we also cover the core algorithms for graphical >> display and manipulation ourselves. > > That's been done for other languages already. It would be cool to > have a flexible plotting library in Lisp. But it's a waste of time > write now. There are good offerings in other languages, so just use > them. The Python Matplotlib source is about 30,000 lines, if I recall > correctly. Do you really want to recreate that effort for the sake > of purity? I don't. On September 8, 2006 12:24 PM C Y wrote: > > Eventually, yes I do. Existing work should be used as a guide, > but I think the eventual goal should be a plotting library so > good/robust/capable that it makes no sense to use anything else. No! This is open source and it's the 21st century. We should *never* be thinking about re-writing other people's code. We need to be able to collaborate with other projects and make direct use of other people's work whenever we can. This is a philosophy that is deeply embedded in the Sage project and I think it is largely responsible for why it has become a major new computer algebra project is less than two years - about the same amount of time we have been discussing this GUI issue... The sooner we understand this philosophy the more likely it is that we can save Axiom from the ghetto. > ... > Earlier C Y wrote: >> GUI and Axiom core also fall in here. Here's an interesting one - >> if we need to run the Axiom core without a multi-threaded lisp, >> how do we stop a job that is running too long? Killing it is a bit >> drastic, since that also loses us any other computations done before, >> but what alternatives are there? > For starters we could just use a multi-threaded Lisp. If that fails > we might be able to use Unix signals (or an equivalent mechanism) > and several processes. In the beginning we might have to live with an > Axiom that doesn't behave very well. > The critical thing here is to design an asynchronous communications protocol that allows the GUI process and the calculation engine to work independently but in a co-operative manner. I think we should pay close attention to the Twisted library currently implemented in Python http://twistedmatrix.com/trac Twisted will very likely be used in the next version of Sage to improve the Sage NoteBook GUI interface. It is especially suitable for use with AJAX methods for web browser interface design. If there is any similar kind of "event-driven networking framework" that has already been implemented in multi-threaded lisp then that might be of immediate interest. But even without such a library, as Kai says it would possible to implement this as, say a Python process running Twisted that communicates with the Axiom core is a more primitive way. > ... >>> Since a single GUI might support several system at once (see >>> Bill's work), why not turn the whole thing upside-down? People >>> download bundles consisting of a single GUI and several cores >>> (Axiom, GAP, whatever). Yes indeed. There has already been some interest expressed on the part of the Sage Notebook developers to extend the Notebook interface to work with Axiom. This is quite different than providing a direct Sage interface to Axiom itself, for example the way Sage interfaces with Maxima now. >> >> Because those systems, fundamentally, are not designed to work >> together. I admire the SAGE effort and I think it will be very >> useful, but GAP (for example) doesn't share Axiom's type system >> and so there is an impedance mismatch between the two systems. This mismatch exists and is (largely) solved right now in Sage between GAP, Singular and Maxima. >> What assumptions is GAP making that Axiom doesn't know about when >> it solves a problem, and are those assumptions ones that are >> compatible with the ones we would make? Does a function name or >> even a property name mean the same thing between the two systems? In principle this sounds like a really hard problem and it has even given rise to a really big attempt at a general solution in the form of OpenMath, but Sage ignores almost all of this and is a successful demonstration that in practice this is not such a big problem. Sage provides it's own dynamic strongly-typed object-oriented language (actually just Python!) that serves as an interlingua between otherwise quite different systems. It is interesting to note that this is the same method that Martin Rubey used in Axiom to encapsulate Polymake. > If we evolve towards proving algorithms, how do we prove an algorithm > used in GAP without doing enough work to go ahead and implement it > in Axiom anyway? ??? GAP already provides some tools for proving algorithms written in GAP. Obviously the thing to do is to make use of these tools where they exist. > Just because you use two CASs from the same GUI doesn't imply that > they'll have to work together. In my Emacs I use Common Lisp and > Haskell, which don't understand each other either. On the other hand > this whole point isn't that important, so let's ignore it for now. > ... I disagree that it is not important. To me, helping to provide a high quality Axiom interface for Sage should be one of our highest priority tasks at this time. The sooner we do this, the less we risk being further marginalized by the success of this new open source project. And because in contrast to those systems which already have an interface with Sage, Axiom was built with an object-oriented philosophy very similar to (in fact I would say, much more advanced than) Sage, I think Axiom has a lot to offer the Sage project. > > I have the impression that there are quite a few things that we just > won't agree on. Since my arguments are often based on speculation I'm > not really willing to push them much harder. Maybe we could instead > try to find a common ground. How about the following: > > 1) In the Axiom core we create one or more additional Lisp packages > (in the DEFPACKAGE sense) that provide an API for all the services > that a GUI needs/wants/whatever. > > The most important feature would probably be to get the output from > textual chatter to something with more structure. > Yes! > 2) We add a *small* and *simple* piece of code that exports that API > over a socket interface. We also add a commandline option to enable > this feature/configure the port/etc. > Yes, yes! > > Kai Kaminski writes: > > > > | PS: I don't mean to say that there shouldn't be a nice, > > | downloadable package on Axiom's website featuring a specific > > | GUI. What I'm after is independence. Axiom's main branch > > | should contain no GUI-related code other than the > > | implementation of the Axiom<->GUI protocol. > > > Gabriel Dos Reis writes: > > I agree with that. If you can sell it to the powers, I would be > > happy to lend a helping hand. > > On September 8, 2006 7:14 AM Kai Kaminski wrote: > Thanks. Maybe we can just agree that having an API/protocol to the > Axiom core is useful anyway and then implement that. That way we > avoid the discussion about whether we need a canonical GUI or not. The > existence of a well-designed API seems to be a good idea anyway. > > I'll try to put up a wiki page for collecting design proposals, use > cases, etc. Furthermore I'll try to document those parts of Axiom that > are directly related to this effort (plotting code, database access, > documentation access, access to the interpreter/compiler etc). > Kai, it you need any help or further incentive to start such a wiki page please let me know. :) On September 8, 2006 10:26 AM Martin Rubey wrote: > ... > For display only I think there are three possibilities: > > * use OutputForm directly > * use TEX > * create a domain like TEX that takes something in OutputFrom > and converts it to whatever you want > > For input and reusing output you should probably extend INFORM. > If the type of a result of a computation doesn't have INFORM, you > should complain to the author of the domain, or realize that it > would be very very hard to come up with an INFORM. > I think Martin's point is very important: that input and output in Axiom are "designed in" to Axiom domains at a very fundamental level. Therefore it is probably not practical nor desirable to try to achieve a situation where the "Axiom main branch contain no GUI-related code other than the implementation of the Axiom<->GUI protocol". But if by GUI-related you mean hyperdoc and Axiom graphics as opposed to AXIOMsys itself, then I agree that these should not be considered part of the core. Only AXIOMsys needs to be instrumented for an external API. As a bare minimum we need the kind of interface designed by James Amundson for Maxima and used by A. G. Grozin in the TeXmacs interface for Maxima. See http://wiki.axiom-developer.org/SandBoxMaxima But I think that for Axiom we can do even better than that and accommodate many other kinds of information such as Axiom types, graphics data, and Axiom database (daase) queries. Regards, Bill Page. _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
