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:
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)
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.
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
4. You now point out that the tests currently there are pretty useless.
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.
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.
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.
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
