[Axiom-developer] browser front end, statement of plans and progress

[daly]

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