It seems harmless as a short term strategy to use the 130 modules that have been identified to get Sage to 90% coverage. Once that is met, I imagine the next goal would be 95% then 100% coverage. And from what Ive seen of the Sage developer community there would then be a revisiting and addition of these threads to decide which metrics/strategies to next adopt (be they branch testing or something else) to meet the next new testing milestones. Its unlikely that someone will sometime declare "we dont need any more tests for existing code" so are we just debating over the order that the tests will be incorporated?
On Mon, Jun 14, 2010 at 9:47 PM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > On 06/14/10 12:18 PM, Tim Joseph Dumol wrote: >> >> On Mon, Jun 14, 2010 at 7:09 PM, Dr. David Kirkby >> <david.kir...@onetel.net> wrote: >>> >>> On 06/14/10 11:41 AM, Tim Joseph Dumol wrote: >>>> >>>> Doctests are used to prevent regressions and (unwanted) backward >>>> incompatibilities. Since the code used in these modules are not ever >>>> going to be modified, it does not seem necessary to provide doctests, >>>> IMHO. >>> >>> Personally I'd beg to differ. A change in gcc's behavior could easily >>> result >>> in the code acting differently, as could any number of other system >>> changes. >>> >>> Here are a few tickets for issues that result of just changing compiler >>> versions. >>> >>> * segfault in Sage-4.4 built using GCC-4.5.0 >>> http://trac.sagemath.org/sage_trac/ticket/8788 >>> >>> * frobby optional spkg doesn't build with newer GCC's >>> http://trac.sagemath.org/sage_trac/ticket/8783 >>> >>> * GCC-4.5.0 breaks GAP -- the workspace is broken, hence gap('2+2') >>> fails. >>> http://trac.sagemath.org/sage_trac/ticket/8773 >>> >>> * http://trac.sagemath.org/sage_trac/ticket/8767 >>> http://trac.sagemath.org/sage_trac/ticket/8767 >>> >>> As far as I can see, all those bugs were a result of changing just >>> compiler >>> versions. >>> >>> Add to the mix the possibility of different versions of cython behaving >>> differently, and it seems a bad idea to me. >>> >>> It's certainly not unknown for a doc test to fail on one machine but pass >>> on >>> another. So having the same code never guarantees you get the same >>> result. >>> >>> Over the years, I've come across a lot of code which runs ok on fast >>> computers, but not on slow ones, or visa versa. One case I recall was >>> someone being rather stupid and seeing the random number generator from >>> the >>> time of day multiple times in a loop. On a slow computer, the seed was >>> effectively random each time so they got a different pseudo random >>> number. >>> On a fast computer, the code executed in less than a second, and so the >>> RNG >>> was seeded twice with hte same value. >>> >>> Mathematica on Solaris had a bug when Solaris 10 was updated only on slow >>> computers. >>> >>> http://www.g8wrb.org/mathematica/ >>> >>> So I've known all these to cause bugs, while the source code remains >>> unchanged. >>> >>> * Changes in compiler version >>> * Changes in the speed of the computer >>> * Upgrade of the operating system. >>> >>> As one more final point, there are ports in progress to >>> >>> * FreeBSD >>> * OpenSolaris >>> * 64-bit on Solaris SPARC >>> >>> All of them have the potential to create problems on one platform, not >>> seen >>> on another. >>> >>> Can you dismiss all the above possibilities? If not, why should the code >>> be >>> exempt from testing? >>> >>> Dave >>> >> >> As for Cython and gcc, the Sage notebook uses pure Python. I do >> acknowledge that there's a minuscule chance that a Python update could >> change runtime behaviour. > > But what is used to build python? - gcc of course! So we have *at least* the > following possibilities which could result in a problem. > > * gcc update > * python update > * someone patching python (it is already at patch level 8 or so in Sage) > * operating system update > * port to another platform (Cygwin, OpenSolaris and FreeBSD are all being > worked on.) > * someone's computer may be mis-configured. > > Less likely, but still not impossibe, would be the speed of someone's > computer (BSD.py was such an example), or any of numerous other things I can > think of. > >> It is worthwhile to note that the code under sage/server/* is only >> used to be able to load old pickles of Sage notebooks, and the only >> reasonable way I could think a Python update could mess this up is by >> a change in pickle format (which is guaranteed against in Python >> documentation). The code is not used for any other purpose aside from >> that. > > Maybe, but it seems a poor idea to remove it to me the fact the code is > still used - even if only rarely used. > > What do we gain this from removing this code from doctesting. > > * Faster doctesting. > * Better looking statistics. > > I know what I'd rather have. > > Is there *any* other motivation for removing this from the testing, apart > from increasing the percentage of doctest coverage? If not, it boils down to > sacrificing quality for better looking statistics. > > > > 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 > -- 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
