On Jan 22, 2008 4:51 PM, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > On Jan 22, 2008, at 5:41 AM, mhampton wrote: > > > I think this could be an exciting way to get all the java applet > > makers out there interested in sage, although I don't completely > > understand the architecture of what this is supposed to do. > > The way I understand it, JASON is a simple format to serialize > hierarchal data structures, and writers/parsers are simple and > available in many languages (e.g. Python, javascript, and Java). Kind > of like a text pickle. It's what XML was supposed to be, without the > insane amount of extra baggage.
In fact JSON (not JASON) *is* javascript. More precisely it's a subset of the javascript language that basically serves a similar purpose for transmitting serialized objects. > >> On Jan 22, 2008, at 5:54 AM, Martin Albrecht wrote: > >> > >> Wouldn't a Java applet imply that the functionality it provides > >> could only be > >> accessed via Sage's web interface? > >> > >> I would like to establish some (roughly) like this: If a > >> computation cannot be > >> expressed from the command line (in pure Python) then it cannot be > >> a standard > >> part of Sage. E.g. if you cannot compute $sin(x)$ for some $x$ > >> from the > >> command line but you can do it by clicking some Java buttons, then > >> this > >> functionality would not be considered a part of (standard) Sage. > >> > >> Would that make sense? I might be completely misunderstanding your suggestion, so if so, please clarify. The core goal of Sage is to provide a viable alternative to Magma, Maple, Mathematica, and MATLAB. Maple, Mathematica, and MATLAB all provide sophisticated graphical interfaces, some of which is clearly of great value to a huge number of people. There is no way Sage can be a viable alternative to those systems if it eschews all non-command line functionality. Also, your suggestion doesn't help at all with this discussion about JSON, since JSON has nothing to do with graphics / GUI's, etc. It's just an object serialization protocol (that happens to be useful in writing some GUI's). Regarding testing the notebook, say, there is no technical reason that it can't be done. Dsage is in a sense very similar, in that it is a complicated network application -- the reason DSage has good automatic unit tests and the Sage notebook doesn't, is that Yi Qiang who wrote DSage is just that Yi put in the extra effort to do the testing right, and with the notebook we didn't. That said, I think that we've made over a 100 releases of Sage and the notebook has very rarely had any serious bugs in it (that we didn't already know about); I think that is because we very rarely change the notebook, and when we do change it a lot then thoroughly test it (there is actually a checklist for testing the notebook by hand). So the world isn't going to end because the Sage notebook doesn't have tons of automated tests. > This is one of the huge advantages that Java has over javascript-- > from the command line one can pop up an applet just as well as > showing it in a browser (its easier in fact). Think of how jmol 3d > works now (and though they provided a separate "application" > interface, this is not a requirement to being able to pop it up). > > I would imagine that most applets would not provide new functionality > so much as a alternative interface to the functionality already > there. For example, a virtual scientific calculator would allow one > to do arithmetic, or even algebra by pushing buttons, but it would > just be an interface to the real work that gets done (via some > command) in Sage (otherwise one ends up re-inventing the wheel and > looses advantage of bundling with Sage). Another example is an applet > for creating and laying out graphs via drag-and-drop. Now one can > always specify vertex positions manually from the command line, but > this interface is so cumbersome that few use it. > > I do agree that it's important any (computational) functionality > should be available from the command line. That I definitely agree with. I would be very disturbed if we had a java app that implemented important computational functionality that is not available from the command line. There was actually a numerical analysis java applet that is GPL'd that was discussed here a while ago that would have been exactly this. That discussion died though. Including it in sage would be a big mistake. > > On Jan 22, 2008, at 9:51 AM, Nick Alexander wrote: > > > One reason to do this is because automated testing graphical > > interfaces (including, but not limited to, the notebook) tends to be > > nigh on impossible. If it can't be done from the command line, it's > > pretty hard to test; if it's not tested, I'd like it to not be widely > > accepted. > > The testing concern is a valid one. However, I would see JASON used > more as an easy interface to 3rd party applets that want to be able > to interact with Sage. If some of those applets are really useful/ > powerful eventually materialize we would consider including them with > Sage on a case-by-case basis at that time. > > That being said, I think the best route is to make it an optional > package and see where it goes from there. > > - Robert > > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
