[sage-devel] Re: Adding JSON capabilities to SAGE
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. That was entirely my point. If I cannot ssh to a machine any more and run some computation there in Sage then I'd disappointed. If there is another (graphical) interface to achieve the same (or better looking) then I have no objection. Another point: One of my main applications of Sage is writing programs in Sage, i.e. I use the Sage library as a library. AFAIK a Java applet won't benefit me there and thus I couldn't use that functionality in my code. For me Sage is definitely not a scientific calculator, though I often fire up Sage instead of e.g. 'bc' to to divide two floating point numbers :-) Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
William wrote: If further testing is successful, I would like to have simpleJSON included in SAGE. What procedure do I need to follow in order to make an official software addition request? (1) Convince us it's a good idea. You basically just did that. (2) Create a trac ticket and then to attach some code that we can try it out. A simpleJSON spkg has now been created and more information about it can be found in its trac ticket: http://www.sagetrac.org/sage_trac/ticket/1510 William has added the following comment to this ticket which requests that the spkg be discussed on sage-devel before deciding on whether or not to include it in Sage: I think some sort of general voting and discussion should occur before including any new packages standard in Sage, especially ones that don't cover some very clear mathematical area that is completely unconvered by Sage (e.g., R and PolyBori? did address a clear mathematical area). In particular, it is _critical_ that there be more than one person who really wants the package to go in before we even consider putting it in. I suggest that: 1. simplejson be made an optional package, 2. there be a post to sage-devel to start some discussion about whether this actually belongs in Sage. That it is is easy to put in Sage (it's pure python) is a plus, but is definitely not enough of an argument (to put it mildly). Remember, every package that goes into Sage will cause Michael Abshoff, and me, and others headaches at some point, and will add to the horrendous problem we already have with packages getting out of date with upstream. Also, perhaps there should be somebody -- probably Ted in this case -- who very clear volunteers to keep the package up to date for the next year, and find somebody to take over if they can't continue. The above was quick brainstorming. It is not meant to be some well thought out procedure, which is something I don't think we have yet. -- William The purpose for adding simpleJSON to Sage is to give clients an object-based, language-neutral method for communicating with the Sage server. This package is not about adding mathematical capabilities to Sage, but rather, it is for allowing clients to more easily access the mathematical functionality it already has. I am specifically using simpleJSON to allow applets, which are loaded from a separate server into a worksheet, to pull data out of Sage. Allowing applets to be loaded from a separate server removes the need for them to be included with Sage itself which I think is a good route to follow. I have estimated that there are probably hundreds of math, science, and engineering-oriented Java applets in existence that are capable of adding value to Sage. My goal with these applets is to not only make them available in the notebook, but to also attract a significant number of their developers to the Sage project so that they can add even more value to it. If there is no easy way for these applets to communicate with the Sage server, however, there is not much point in embedding them in a worksheet. As for the idea of making simpleJSON an optional package, my thought is that there is little point in this. If a newbie Windows user wants to use a calculator applet in a worksheet because this is the level of technology they are comfortable with, they are probably not going to be very successful installing an optional package. Anyway, I researched a number of alternatives before choosing a JSON-based solution to this client communications problem. It is relatively clean and it seems to work fairly well. If people have alternative ways to solve this problem, however, I would like to hear them :-) Ted --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
On Jan 22, 2008 5:05 AM, Ted Kosan [EMAIL PROTECTED] wrote: William wrote: If further testing is successful, I would like to have simpleJSON included in SAGE. What procedure do I need to follow in order to make an official software addition request? (1) Convince us it's a good idea. You basically just did that. (2) Create a trac ticket and then to attach some code that we can try it out. A simpleJSON spkg has now been created and more information about it can be found in its trac ticket: http://www.sagetrac.org/sage_trac/ticket/1510 William has added the following comment to this ticket which requests that the spkg be discussed on sage-devel before deciding on whether or not to include it in Sage: I think some sort of general voting and discussion should occur before including any new packages standard in Sage, especially ones that don't cover some very clear mathematical area that is completely unconvered by Sage (e.g., R and PolyBori? did address a clear mathematical area). In particular, it is _critical_ that there be more than one person who really wants the package to go in before we even consider putting it in. I suggest that: 1. simplejson be made an optional package, 2. there be a post to sage-devel to start some discussion about whether this actually belongs in Sage. That it is is easy to put in Sage (it's pure python) is a plus, but is definitely not enough of an argument (to put it mildly). Remember, every package that goes into Sage will cause Michael Abshoff, and me, and others headaches at some point, and will add to the horrendous problem we already have with packages getting out of date with upstream. Also, perhaps there should be somebody -- probably Ted in this case -- who very clear volunteers to keep the package up to date for the next year, and find somebody to take over if they can't continue. The above was quick brainstorming. It is not meant to be some well thought out procedure, which is something I don't think we have yet. -- William The purpose for adding simpleJSON to Sage is to give clients an object-based, language-neutral method for communicating with the Sage server. This package is not about adding mathematical capabilities to Sage, but rather, it is for allowing clients to more easily access the mathematical functionality it already has. I am specifically using simpleJSON to allow applets, which are loaded from a separate server into a worksheet, to pull data out of Sage. Allowing applets to be loaded from a separate server removes the need for them to be included with Sage itself which I think is a good route to follow. I have estimated that there are probably hundreds of math, science, and engineering-oriented Java applets in existence that are capable of adding value to Sage. My goal with these applets is to not only make them available in the notebook, but to also attract a significant number of their developers to the Sage project so that they can add even more value to it. If there is no easy way for these applets to communicate with the Sage server, however, there is not much point in embedding them in a worksheet. As for the idea of making simpleJSON an optional package, my thought is that there is little point in this. If a newbie Windows user wants to use a calculator applet in a worksheet because this is the level of technology they are comfortable with, they are probably not going to be very successful installing an optional package. I can see you don't like the idea of making JSON merely an optional package but one possibly way to hopefully help your proposal would be to first make an optional package and then see how that goes. I think for William and Michael, the effort required to change an optional package to a standard package isn't great. On the other hand, it does make it easier for people to test (and even for you to create bug fixes) for optional packages. You could also add some details about it to the wiki at http://wiki.sagemath.org/optional_packages_available_for_SAGE So, I agree with William. Anyway, I researched a number of alternatives before choosing a JSON-based solution to this client communications problem. It is relatively clean and it seems to work fairly well. If people have alternative ways to solve this problem, however, I would like to hear them :-) Ted --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
I agree - an optional package makes more sense for the moment. The spkg is less than a mb, fortunately, so adding it to the standard packages eventually wouldn't inflate the total size that much. There are several optional packages that I use a lot and I hope to eventually have in sage as standard (biopython, polymake, phcpack) but I am waiting to make my final case (for different reasons for each package, but that's another thread I guess). 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. Cheers, Marshall Hampton On Jan 22, 6:23 am, David Joyner [EMAIL PROTECTED] wrote: On Jan 22, 2008 5:05 AM, Ted Kosan [EMAIL PROTECTED] wrote: William wrote: If further testing is successful, I would like to have simpleJSON included in SAGE. What procedure do I need to follow in order to make an official software addition request? (1) Convince us it's a good idea. You basically just did that. (2) Create a trac ticket and then to attach some code that we can try it out. A simpleJSON spkg has now been created and more information about it can be found in its trac ticket: http://www.sagetrac.org/sage_trac/ticket/1510 William has added the following comment to this ticket which requests that the spkg be discussed on sage-devel before deciding on whether or not to include it in Sage: I think some sort of general voting and discussion should occur before including any new packages standard in Sage, especially ones that don't cover some very clear mathematical area that is completely unconvered by Sage (e.g., R and PolyBori? did address a clear mathematical area). In particular, it is _critical_ that there be more than one person who really wants the package to go in before we even consider putting it in. I suggest that: 1. simplejson be made an optional package, 2. there be a post to sage-devel to start some discussion about whether this actually belongs in Sage. That it is is easy to put in Sage (it's pure python) is a plus, but is definitely not enough of an argument (to put it mildly). Remember, every package that goes into Sage will cause Michael Abshoff, and me, and others headaches at some point, and will add to the horrendous problem we already have with packages getting out of date with upstream. Also, perhaps there should be somebody -- probably Ted in this case -- who very clear volunteers to keep the package up to date for the next year, and find somebody to take over if they can't continue. The above was quick brainstorming. It is not meant to be some well thought out procedure, which is something I don't think we have yet. -- William The purpose for adding simpleJSON to Sage is to give clients an object-based, language-neutral method for communicating with the Sage server. This package is not about adding mathematical capabilities to Sage, but rather, it is for allowing clients to more easily access the mathematical functionality it already has. I am specifically using simpleJSON to allow applets, which are loaded from a separate server into a worksheet, to pull data out of Sage. Allowing applets to be loaded from a separate server removes the need for them to be included with Sage itself which I think is a good route to follow. I have estimated that there are probably hundreds of math, science, and engineering-oriented Java applets in existence that are capable of adding value to Sage. My goal with these applets is to not only make them available in the notebook, but to also attract a significant number of their developers to the Sage project so that they can add even more value to it. If there is no easy way for these applets to communicate with the Sage server, however, there is not much point in embedding them in a worksheet. As for the idea of making simpleJSON an optional package, my thought is that there is little point in this. If a newbie Windows user wants to use a calculator applet in a worksheet because this is the level of technology they are comfortable with, they are probably not going to be very successful installing an optional package. I can see you don't like the idea of making JSON merely an optional package but one possibly way to hopefully help your proposal would be to first make an optional package and then see how that goes. I think for William and Michael, the effort required to change an optional package to a standard package isn't great. On the other hand, it does make it easier for people to test (and even for you to create bug fixes) for optional packages. You could also add some details about it to the wiki athttp://wiki.sagemath.org/optional_packages_available_for_SAGE So, I agree with William. Anyway, I researched a number of alternatives before
[sage-devel] Re: Adding JSON capabilities to SAGE
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. 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? Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
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. 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? Martin No, that makes no sense at all. First off, I don't see this as a danger. Second, interactive widgets are pretty frikkin' sweet -- you should have seen the stuff high school kids were doing with Manipulate in Mathematica at the joint math meeting. The notebook already has a number of features that the commandline doesn't. Why do you feel the need to freeze the interface of Sage so it can never grow past the commandline? That's Matlab's approach, and I think their interface sucks. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
On 22-Jan-08, at 9:08 AM, [EMAIL PROTECTED] 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. 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? Martin No, that makes no sense at all. 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. Nick --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
On Tue, 22 Jan 2008, Nick Alexander wrote: On 22-Jan-08, at 9:08 AM, [EMAIL PROTECTED] 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. 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? Martin No, that makes no sense at all. 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. Nick The interface itself might be tricky -- however, the communication protocol isn't hard to test, whatever computations go on behind the scenes aren't hard to test, and Java has some *great* unit-testing capabilities, so that side isn't hard to test either. In short, there is very little that we wouldn't be able to test in an automated way. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
On Tue, 22 Jan 2008, Nick Alexander wrote: 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? Martin There is something I don't get: it seems like JSON is going to be used by clients to simply send or receive data from SAGE. What the client does with the result of the computation is its problem. Why do we have to worry about testing this at all? The interface itself might be tricky -- however, the communication protocol isn't hard to test, whatever computations go on behind the scenes aren't hard to test, and Java has some *great* unit-testing capabilities, so that side isn't hard to test either. In short, there is very little that we wouldn't be able to test in an automated way. And what is there to test? That the data is well-formed? didier --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
On Jan 22, 2008 5:41 AM, mhampton [EMAIL PROTECTED] wrote: I agree - an optional package makes more sense for the moment. The spkg is less than a mb, fortunately, so adding it to the standard packages eventually wouldn't inflate the total size that much. I propose the following: (1) Json support is made an optional package (2) Once there are some actual interesting uses of it, then we seriously consider making it a standard package. (This could be a week from now, etc.) Regarding 2, I never remember being convinced to put anything into Sage unless there was a really cool application that _used_ it. E.g., I didn't want to put libgd in sage and wouldn't until Tom Boothby showed off a bunch of very high resolution fractal images he could render very quickly using libgd, which matplotlib sucked at. That was pretty convincing. There are several optional packages that I use a lot and I hope to eventually have in sage as standard (biopython, polymake, phcpack) but I am waiting to make my final case (for different reasons for each package, but that's another thread I guess). 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. Cheers, Marshall Hampton On Jan 22, 6:23 am, David Joyner [EMAIL PROTECTED] wrote: On Jan 22, 2008 5:05 AM, Ted Kosan [EMAIL PROTECTED] wrote: William wrote: If further testing is successful, I would like to have simpleJSON included in SAGE. What procedure do I need to follow in order to make an official software addition request? (1) Convince us it's a good idea. You basically just did that. (2) Create a trac ticket and then to attach some code that we can try it out. A simpleJSON spkg has now been created and more information about it can be found in its trac ticket: http://www.sagetrac.org/sage_trac/ticket/1510 William has added the following comment to this ticket which requests that the spkg be discussed on sage-devel before deciding on whether or not to include it in Sage: I think some sort of general voting and discussion should occur before including any new packages standard in Sage, especially ones that don't cover some very clear mathematical area that is completely unconvered by Sage (e.g., R and PolyBori? did address a clear mathematical area). In particular, it is _critical_ that there be more than one person who really wants the package to go in before we even consider putting it in. I suggest that: 1. simplejson be made an optional package, 2. there be a post to sage-devel to start some discussion about whether this actually belongs in Sage. That it is is easy to put in Sage (it's pure python) is a plus, but is definitely not enough of an argument (to put it mildly). Remember, every package that goes into Sage will cause Michael Abshoff, and me, and others headaches at some point, and will add to the horrendous problem we already have with packages getting out of date with upstream. Also, perhaps there should be somebody -- probably Ted in this case -- who very clear volunteers to keep the package up to date for the next year, and find somebody to take over if they can't continue. The above was quick brainstorming. It is not meant to be some well thought out procedure, which is something I don't think we have yet. -- William The purpose for adding simpleJSON to Sage is to give clients an object-based, language-neutral method for communicating with the Sage server. This package is not about adding mathematical capabilities to Sage, but rather, it is for allowing clients to more easily access the mathematical functionality it already has. I am specifically using simpleJSON to allow applets, which are loaded from a separate server into a worksheet, to pull data out of Sage. Allowing applets to be loaded from a separate server removes the need for them to be included with Sage itself which I think is a good route to follow. I have estimated that there are probably hundreds of math, science, and engineering-oriented Java applets in existence that are capable of adding value to Sage. My goal with these applets is to not only make them available in the notebook, but to also attract a significant number of their developers to the Sage project so that they can add even more value to it. If there is no easy way for these applets to communicate with the Sage server, however, there is not much point in embedding them in a worksheet. As for the idea of making simpleJSON an optional package, my thought is that there is little point in this. If a newbie Windows user wants to use a calculator applet in a worksheet because this is the level of technology
[sage-devel] Re: Adding JSON capabilities to SAGE
William wrote: I propose the following: (1) Json support is made an optional package (2) Once there are some actual interesting uses of it, then we seriously consider making it a standard package. (This could be a week from now, etc.) +1 Ted --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
On Jan 22, 2008, at 5:54 AM, Martin Albrecht 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. 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? Independent of the specific issue of JSON, I agree with this. I hardly ever use the notebook functionality, so anything I can't get at from the command-line is of no use to me. Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Enhancement of the Director's Income Experience is what you get when you don't get what you want. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
On Jan 22, 2008, at 9:51 AM, Nick Alexander wrote: On 22-Jan-08, at 9:08 AM, [EMAIL PROTECTED] 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. 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? Martin No, that makes no sense at all. 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. It's not true that testing GUIs is in any way impossible (I believe several companies make such products, and make a pretty good living at it). However, I don't think there is a freely-available way to do it, and in this aspect, your point is well-taken, and reinforces to my being against splitting the functionality of Sage. Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds Some people have a mental horizon of radius zero, and call it their point of view. -- David Hilbert --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
On Jan 22, 2008, at 9:08 AM, [EMAIL PROTECTED] 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. 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? Martin No, that makes no sense at all. First off, I don't see this as a danger. Second, interactive widgets are pretty frikkin' sweet -- you should have seen the stuff high school kids were doing with Manipulate in Mathematica at the joint math meeting. The notebook already has a number of features that the commandline doesn't. Why do you feel the need to freeze the interface of Sage so it can never grow past the commandline? That's Matlab's approach, and I think their interface sucks. I am not at all sure what JSON is all about, but if it pertains mostly to the user interface, rather than the mathematics capability of Sage, then I think that - it should be non standard; - perhaps it is time to take seriously the split between the front end and kernel of Sage itself. Doing this runs the danger of fragmenting the development effort, but it does let those interested in the notebook aspects of Sage focus on that, while those interested in the mathematics can focus on their piece(s). This will prove to be way too simplistic a view, I think, and I can foresee some significant issues arising from such a split, but it may be time to discuss it, so that it doesn't just happen. Forewarned is forearmed (although most of us have only two :-}). Justin -- Justin C. Walker, Curmudgeon-at-Large () The ASCII Ribbon Campaign /\ Help Cure HTML Email --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
Justin wrote: It's not true that testing GUIs is in any way impossible (I believe several companies make such products, and make a pretty good living at it). However, I don't think there is a freely-available way to do it, and in this aspect, your point is well-taken, and reinforces to my being against splitting the functionality of Sage. Here are 3 open source Java GUI testers that may be useful: http://abbot.sourceforge.net/doc/overview.shtml http://www.uispec4j.org/ http://pounder.sourceforge.net/ Ted --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
On 22-Jan-08, at 6:03 PM, Ted Kosan wrote: Justin wrote: It's not true that testing GUIs is in any way impossible (I believe several companies make such products, and make a pretty good living at it). However, I don't think there is a freely-available way to do it, and in this aspect, your point is well-taken, and reinforces to my being against splitting the functionality of Sage. Here are 3 open source Java GUI testers that may be useful: http://abbot.sourceforge.net/doc/overview.shtml Does this look anything like our existing doctests? Did you like the looks of the tutorial? I certainly did not -- I'd beat my head into the ground trying to remember the names of my components, etc. http://www.uispec4j.org/ This looks the most promising, but it's not exactly sage: factor(20) 2^2 * 5 http://pounder.sourceforge.net/ Pounder seems to have the best concept (record actions, check conditions) but is, of course, no longer developed. Nick --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
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. 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? Martin 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. 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
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-devel] Re: Adding JSON capabilities to SAGE
William wrote If further testing is successful, I would like to have simpleJSON included in SAGE. What procedure do I need to follow in order to make an official software addition request? (1) Convince us it's a good idea. You basically just did that. (2) Create a trac ticket and then to attach some code that we can try it out. I have created the following trac ticket which contains an enhancement request for adding SimpleJSON to SAGE: http://www.sagetrac.org/sage_trac/ticket/1510 The ticket includes instructions which describe how to send JSON-based 2D graphics information to a notebook applet for interactive viewing. Ted --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Adding JSON capabilities to SAGE
On Dec 10, 2007 8:50 AM, Ted Kosan [EMAIL PROTECTED] wrote: I have been experimenting with techniques for allowing Java applets to communicate with the SAGE server and the technique I like the best so far is to use JSON objects (http://json.org). I am currently using simpleJSON (http://undefined.org/python/#simplejson) on the SAGE server and I have it successfully communicating with an applet. What I like about JSON is that it is a language-neutral way to send data through a network that does not have as high an overhead as XML. Also, most popular computer languages have at least one open source JSON implementation available which makes the creation of SAGE clients in these languages fairly easy. If further testing is successful, I would like to have simpleJSON included in SAGE. What procedure do I need to follow in order to make an official software addition request? (1) Convince us it's a good idea. You basically just did that. (2) Create a trac ticket and then to attach some code that we can try it out. -- William --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
