Interesting set of replies. Ralf is concerned that we would not have API documentation, which is quite reasonable. We extract the existing documentation automatically so I don't believe there is any difference caused by displaying this documentation in a standard browser rather than hyperdoc. The documentation strings are extracted by the compiler and should be available from the database files or the running image if we so desire.
I agree that we ought to carefully study the API documentation issue. Possibly we could adopt a new syntax similar to javadoc that allows us to use existing tools. Failing that we could probably dynamically generate API documentation at compile time that would be properly hyperlinked and easy to display. Waldek says: "X11 problem should be easy to solve..." except that it is not. I have experimented with making the graphics and hyperdoc run on windows, freebsd, and the mac. Each one has had its own problems, windows being the hardest. I did succeed in getting hyperdoc running on windows but there is no chance the average user wants to put up with the pain of installing and using it. And it won't talk to sman so it has limited functionality. "... use portable drawing library"... which is exactly the plan. The graphics needs to be split into two parts, the drawing algorithms and the drawing technology. The algorithms need to be placed where they can be manipulated, rewritten, and extended by spad code. The drawing technology needs to be more portable. The most portable drawing technology I've found uses <canvas> tags in a browser window. Write once, draw anywhere, locally or over a network, windows, linux, freebsd, or mac. "...multithreading is available only in some lisps..." depends on the granularity of the processes. I've looked into this and SBCL multithreads on all platforms. I have yet to try this with web connections but it does work otherwise. And this assumes that you use threading rather than tasks. It is possible to create a separate, generated lisp object to handle each display task and start each one as a standalone task in a separate image, dedicate to the single graph. "Hyperdoc uses essentially _the same_ TeX notation as the book..." It does? The book contains nothing about pages or buttons. It says nothing about the requirements for free references to prior values. Certain portions of the information are derived from certain portions of the book and there is every reason for this to continue. But I have seen no effort to create whole new subtrees of hyperdoc pages. Trying to embed flash, sound, movies, jpgs, pdfs, and links to external movies cannot happen. Hyperdoc does not support pamphlet files. All of this would require extensive programming. But everyone has a free viewer on every desktop that supports all of this functionality called a browser. I agree that the graphics needs to be more portable, easier to manipulate from spad, threaded or tasked in such a way that it is responsive to zoom/translate/rotate/shade, etc. I'm not sure that I agree about the exact syntax of the hyperdoc files, however. The hyperdoc language was invented before URLs, html, ajax, etc. and really limits what you can put on a page. Plus it is a one-of-a-kind language which limits the number of likely authors. Since writing documentation is vital this is a huge limitation. Andrey suggests that TeXmacs "...is a better alternative than using a browser as a front-end...". I agree with this in theory but I'm not sure it holds up in practice. TeXmacs has limitations (e.g. displaying graphics) but that's only a minor issue. TeXmacs has been available for at least 6 years and attached to Axiom for about 4 years. Yet I know of no-one who actively uses it as a front end for Axiom. I don't even see it show up when people demo TeXmacs at conferences. "...the current graphics has a good feature that I can interact with a plot...", "...this is not possible in a browser." In fact, it is possible in a browser (as of Firefox 1.5) which is the piece I've been waiting for. I've done some experiments to convince myself that it works. I've even see MS paint in a browser (http://canvaspaint.org). "...a close coupling between graphics and computations is very valuable...". I want to be able to have a continuously varying stream of information displayed as a computation proceeds. Or I want to have a graph data structure drawn in real time as the program manipulates the graph data structure (the krops network at the center of the crystal) "...but why a browser? Its connection to Axiom computation engine is very week". Well, everyone has a browser, they know how to use it and they would know immediately how to interact with Axiom. It is possible to do things like "folding" (similar to mathematica notebooks) without having special programs. It is possible to connect locally or remotely with no visible difference. "...if you are prepared to wait as long as for getting some responce from google earth..". Actually I suspect that Axiom will be running on the same machine as the browser in most instances. In that case bandwidth is not an issue. As for CPU resources I can't seem to buy a machine these days that has a single CPU, the very latest machines are quad-core machines and I saw today that the next Intel/AMD machines are 8-way processors. Multiprocess machines will be common in the near future. "...Javascript is 100-1000 times less efficient than C..." This way lies a religious war. Believe me, I dislike Javascript as much as everyone else but it works and it does what I need to do. I've rewritten portions of Hyperdoc into Javascript functions and it provides the machinery I need. C does not, so it doesn't matter. "...TeXmacs can do everything hyperdoc does"? Really? Not that I'm aware of. Hyperdoc embeds images and can communicate commands to Axiom and then display the resulting images inline (and start up a separate process if you click on the image). I have no doubt that TeXmacs COULD do this but I do doubt that it is on anyone's desk to make this happen in the next year. "Also, re-coding hyperdoc pages to LaTeX should be easier than to html..." If we ignore handling text, LaTeX and html are worlds apart. Html handles user interaction for input and output. LaTeX formats text and equations and the occasional picture. They are not "either-or" choices and both can exist together. "...It is easy to output Axiom expressions as s-expressions, and to send them to TeXmacs, without losing any information about their internal structure and semantics...". This can't be done. The semantics of the parts of the expressions have machine-level pointers to domain data structures which point to other domain data structure which index into other domain data structures, etc. Once the pointer leaves the Axiom image it is meaningless and all of Axiom's meaning comes from the domain where the expression lives. Thus it is not possible to export an s-expression with all of its semantics intact. "...but I'm against browsers...". See the Axiom mailing list archives. I agreed with you two years ago. Bill Page convinced me otherwise and I've been looking at a way to use browsers for a long time. With the introduction of the <canvas> tag the last piece of the puzzle has fallen into place for me. I'm still undecided about mathml but I've seen some very pretty formula work in it so my opinion may change as I learn more. "...TeXmacs is free and available for all platforms..." but so is Firefox. Gaby writes "Qt is available under windows". There are several approaches I've looked at in terms of portable graphics code. The most promising approach was to use Tcl/TK. We had a bit of discussion about this with Camm on the mailing list sometime last year. I built a small Tcl/TK version of hyperdoc but could not get it to run properly from GCL. I looked at Glade this past summer and built a few hyperdoc pages. Glade can generate windows for any platform from description files. But it also didn't work well with lisp. I got a copy of Visual C++ and tried to build a few native windows on Windows XP. That way lies madness. I used an X11 emulation program on the MS window for X11. I've been experimenting with different systems for the past year and none of them have been sufficient, although it was a great learning experience. Martin writes: "...Ralf has written an excellent environment for literate programs...". Yes, he showed it to me in France and I'm really quite impressed. I'm not sure what this has to do with the front-end issues to Axiom, however. "Some time ago I asked you whether asq could be used to fetch the documentation information also dynamically...I faintly remember you answered but I never heard any further response." I put up a web page that used asq to provide access to database information from the web and I believe I passed it on to Bill Page for inclusion on the wiki. The details are likely in the mailing list somewhere. The web page I built for you is at: http://daly.axiom-developer.org/asq.php "...I cannot find any sane reason to give up these concepts from ALLPROSE and Hyperdoc..."? Somehow you see using a browser to access information from a back end as implying that we have to give up our programming tools. I'm not sure why these two things seem to be related. The fact that Axiom uses a different front end should have no effect on what tools you use to write programs. "...Dynamic api-documentation is a must for me..." and is clearly a requirement for any front end. Given that the browser front end would be speaking directly to an Axiom image why do you believe that we wouldn't have dynamic information? You show libdb.text information and then claim that hyperdoc will not display it. Is tex4ht the right tool? I have no idea as I have not tried it. Supposedly noweb will also generate html. There are many migration paths to think about and explore. If I knew the answers I'd be writing production code rather than these many throw-away experiments. Bill Page writes "...I think you should not be overly concerned about Tim's proposal since it seems to me that there is near zero likelihood that any of this work will be completed...". ummm, ok. I'll accept that insult and move on. "... as Tim should continue to so badly miss-direct his efforts..." Before the first release of the Axiom source code I decided that documentation, both of the existing code and the new code, the way to interact with documentation, documenting the algebra hierarchy and documenting the algebra theory were vitally important. Since that time most of my efforts have been directed toward documentation. Several years ago I recreated the original book and about 13 months ago I completed and published the first volume of axiom documentation. Most recently, and soon to be released, is a several chapter booklet documenting the quaterion domain. I'm not sure what you think my efforts are directed toward but I've been pursuing this goal for years and plan to continue. "..I am very much in favour of Andrey's recommendation to re-consider the use of TeXmacs...". Axiom has been available for 5 years or so. TeXmacs has also been available for that time. Both have been connected for several years. Name 3 people worldwide who develop Axiom code on TeXmacs. I'd bet you do not. "...Sage supports browser-based worksheets...which allow Axiom... to be used both "natively"..." and from this you conclude that having a browser front end to Axiom is mis-directed? Anyway, thank you all for the feedback. Tim _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
