On 06/12/10 01:07 AM, Robert Bradshaw wrote:
On Jun 11, 2010, at 11:22 AM, Dr. David Kirkby wrote:
On 06/11/10 06:54 PM, kcrisman wrote:
Testing every single installed package could be
quite tricky, as likely the packages change in various spkgs over
time, but sometimes in subtle ways that an updater of an spkg wouldn't
be aware of.
Well, it might be tricky, but at least the person updating the
package would be
aware of it, and would address that on the ticket. It might mean
some doctest
needs changing. But better to do that, then find several bits of a
package not
working - or worst still, giving the wrong answers.
But this assumes that only someone with intimate knowledge of an spkg
can update it. If a new package is added to an spkg, often that is
buried deep in release notes - often of some intermediate version that
Sage didn't update to in the meantime. I understand the concern, but
keep in mind that in this case it is quite likely that fewer people
will update spkgs for mere bugfixes; only people who really know the
spkgs will update them, which could lead to much slower bugfixing.
Maybe that's ok.
I think sage/interfaces or sage/libs/x would be a fine place to put
specific tests like that,
Any help with writing a test to go in the sage/interface or sage/libs/x that can
do this would be appreciated.
I don't mind researching this if the tests will get added, but if people say "we
wont add it to the testsuite, only to spkg-install", then I wont bother.
and spkg-installs should make sure the package
installed correctly and (if relevant) at least starts up and seems to
function.
I think in this case, it would be wise this could be tested after building Sage,
for three main reasons.
1) Most of the standard R packages are building ok, and R is at least
functional. I don't know how many doc tests related to R that there are, but
none are failing.
2) Adding this at spkg-install would mean an immediate build failure, which
might be a bit of an excessive reaction to a non-fatal problem. A lot of people
might not even use R, so it is doubtful if its sensible to terminate the build
in this case. Clearly the R developers do not think so, as the build does not
stop in the way it would with many types of failures.
This may be a bug, and the build should terminate, or it may be the developers
are happy to let it pass, in much the same way that not all python modules build.
3) Given the nature of the problem.
ld.so.1: R: fatal: libgcc_s.so.1: open failed: No such file or directory
I suspect this could occur if Sage is moved, and the library not found, so it
would make sense that the could be tested once Sage is moved. (It so happens one
does not need to move Sage for this to show up, but in principle a failure to
set LD_LIBRARY_PATH on moving Sage could show this up)
I must admit, I find it very odd that R can't find this library, when loads of
other parts of Sage link to it OK.
But testing something that takes a fraction of a second does not seem much of an
ordeal.
Anyway, enough virtual ink spilled/spilt on this. The real issue is
that one needs massive amounts of time to write the right kind of
doctests and documentation, and since the incentive to add it is not
so high in a volunteer project for many people (though thanks to those
for whom it is!), getting to that point will take a long, long time.
IMHO, if Sage as any hope of being a viable alternative to Maple,
Mathematica or MATLAB, then writing decent documentation and test
procedures is a must.
Perhaps the incentive should be simple.
1) If you want to make the functions available for your own use, you
don't need to test them or document them.
2) If you want them incorporated into Sage, you must document them
well and test them extensively. If you don't know how to do that, ask
for help, but don't expect others to do all the legwork for you.
Isn't that already the policy?
- Robert
Well, kcrisman's comment seemed to imply that there was little incentive in a
volunteer project for people to write documentation or doctests.
Dave
--
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
