On Tue, Nov 9, 2010 at 12:05 PM, Jason Grout <jason-s...@creativetrax.com> wrote: > On 11/9/10 1:14 PM, Pablo Angulo wrote: >> >> I see there are some trac tickets for moving interacts from the wiki >> into the Sage library (at least 9623, ). However, none of them have unit >> tests. I though that automated checking of the code was the main reason >> for moving the interacts into the library. Availability is fine, sure, >> but that could be fixed addnig a link to the wiki in a visible place of >> the notebook. If we move some interacts into the library, we won't >> notice if they stop working after an upgrade, except in the case that >> some function name completely dissappears, which is unlikely. >> Checking some of the interacts is not trivial: >> * Should we write tests for the underying function as if it were a >> regular function? Most of the functions just show an image, some write >> some text, but also show some extra stuff, maybe using the "html" function >> * Should we split the funcionality into a testable inner function and >> the part strictly corresponding to the interact, and add tests only for >> the inner function? > > > Good point. I just tried changing one of the interacts to be invalid, and > the test associated with the interact (just calling the function) still > executed. I don't think they actually did anything with the code; they just > seemed to spit out the boiler-plate html without any actual content. So it > seems that the tests currently there are useless in testing that the > function still works. > > The more I think about it, the less I'm convinced that it is a good idea to > add a database of interacts to the Sage library:
Since I strongly disagree, I'll read this and make some remarks about your reasons below. > 1. It's a fairly tedious process to add interacts to the library, as every > function has to be imported to be used. I suppose we could get around this > by import sage.all (so that we had, in effect, the full command line of > Sage) Something being tedious is not a reason not to do it! > 2. It's pretty tedious and time-consuming to update the interacts. In > short, the barrier to include code is *way* too high to get the kind of > volume we need. Something being tedious is not a reason not to do it. > 3. Lots of times it's good to separate interacts into an initialization > phase and a running phase (where some heavy work or long graphics > computations are done initially, but not on every update). This is unwieldy > to do in the library while still separating interacts Says who? I see no reason why this should be impossible or unwieldy to do in Python code, but not in code in the notebook. It just requires caching (probably a module-scope variable). It's just a programming challenge. > 4. You now point out that the tests currently there are pretty useless. But he also suggested a solution to that, which is to break up the interacts into more testable bits. > Instead, I'm thinking something like a snippet system on a website would be > better. We could even include the database in Sage (just not in the > library). People could easily upload and change interacts without having to > deal with the library. A short description could accompany each interact > describing it and how it is used and interpreted. > > We'd still have to figure out the testing, of course. Maybe we could set up > an automated test suite that would just flag an interact saying which > versions of Sage it gives errors on and which versions it appears to work > on. The testing system wouldn't check for correctness of content, but would > just check to see if there were errors in different inputs. In other words, your proposal doesn't solve the problem which is producing a library of high quality interacts that work, and continue to work. > Examples of such snippet web systems include > > 1. Github Gist system [1]--this is really nice because it allows people to > fork and modify contributions, and it keeps track of the revision history of > contributions. > > 2. Wolfram Demonstrations--this system makes it easy for people to see what > an interact looks like and also has a nice tagging system. How do they ensure quality? Is it just labor intensive or is it crowd-sourced? > 3. Pastebin--a simple system that lets people just post/edit snippets of > code. > > 4. The scipy dev team is currently having a thread about setting up a > snippet web database for scipy. It's just in the planning stages now; maybe > we could work together with them on a system we both could use. Your two options are sort of orthogonal. Personally I think we should have: (a) a library of high quality stable tested working interacts that are included in the Sage library, (b) many interacts that are of varying quality that users post somewhere. Regarding (b), we currently have that on a wiki. Instead it could be at some other site where the interacts are rated and ranked by users. When they don't work, they get low rankings and there could be a "report this broken interact" button. If an interact gets uniformly high rankings, they could get migrated into the library (a), and the code on the site replaced by a 1-line call into the library. In fact, most code that involves Sage could benefit from an (a)/(b) model like above. Tons of code out there of the form (b) not in Sage, of varying quality. There very best longterm *stable* more widely useful code then moves into Sage itself (a). This is sort of like how Python itself is developed. > > Thanks, > > Jason > > > [1] https://gist.github.com/ > > [2] http://demonstrations.wolfram.com/ > > [3] http://pastebin.com/ > > [4] See this thread: > http://thread.gmane.org/gmane.comp.python.scientific.user/26627/focus=26750 > > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
