achieving 90% coverage

79 views
Skip to first unread message

John H Palmieri

unread,
Nov 10, 2012, 3:22:40 PM11/10/12
to sage-...@googlegroups.com
With sage-5.4.rc4, I see

  Overall weighted coverage score:  88.9%

If we change the coverage script to ignore directories containing 'nodoctest.py', then we get

  Overall weighted coverage score:  90.5%

It's a simple patch, just adding two lines to sage-coverage. Should we apply it or is it cheating?

--
John

David Kirkby

unread,
Nov 10, 2012, 4:11:35 PM11/10/12
to sage-...@googlegroups.com
I feel it is cheating, and it will make comparing old figures with new
figures impossible.

Dave

John H Palmieri

unread,
Nov 10, 2012, 4:35:23 PM11/10/12
to sage-...@googlegroups.com

By the way, to clarify: this will only affect the 'server' directory. which consists of unused code (old notebook code, superseded by sagenb), since that's the only place there are files called 'nodoctest.py'.

--
John

Nils Bruin

unread,
Nov 10, 2012, 4:40:59 PM11/10/12
to sage-devel
On Nov 10, 1:35 pm, John H Palmieri <jhpalmier...@gmail.com> wrote:

> By the way, to clarify: this will only affect the 'server' directory. which
> consists of unused code (old notebook code, superseded by sagenb), since
> that's the only place there are files called 'nodoctest.py'.

Do we have a good reason to carry around unused code? Can't we just
delete it?

John H Palmieri

unread,
Nov 10, 2012, 4:49:14 PM11/10/12
to sage-...@googlegroups.com

If we want to maintain backwards compatibility, it's messy. See http://trac.sagemath.org/sage_trac/ticket/11409.

--
John

David Kirkby

unread,
Nov 10, 2012, 6:17:06 PM11/10/12
to sage-...@googlegroups.com
I struggle to see what the patch will do other than change a
percentage value to be more attractive.

I assume as some point the backwards compatibiltiy will be dropped, in
which case the "unused" server code can be removed, and the doctest
figures will improve.

I'm guessing nobody is going to write any doctests for code which is
only there to maintain backward compatibility. So if it remains
untested, why should it be removed from the test figures?

Perhaps I'm missing something.

Dave

Volker Braun

unread,
Nov 10, 2012, 7:36:43 PM11/10/12
to sage-...@googlegroups.com
I don't really care about whether the coverage is a percent more or less. But if you want to have the nodoctest.py functionality then the marked directories should not be counted.

Incidentally, about the legacy code for loading old notebooks: here is one lesson to be learned about long-term support of data files. The only sane way to handle this imho is:

* The current code can read/write the current data format
* Whenever you upgrade from format version N to N+1, you write a self-contained updater.
* Old files are sent through the chain of updaters until they are current.

Invariably, any project will start out with the old-version-tolerant loader approach. Its a nice quick solution in the beginning, but as time progresses it'll get more and more difficult to support.


kcrisman

unread,
Nov 10, 2012, 10:15:45 PM11/10/12
to sage-...@googlegroups.com


On Saturday, November 10, 2012 7:36:43 PM UTC-5, Volker Braun wrote:
I don't really care about whether the coverage is a percent more or less. But if you want to have the nodoctest.py functionality then the marked directories should not be counted.

Incidentally, about the legacy code for loading old notebooks: here is one lesson to be learned about long-term support of data files. The only sane way to handle this imho is:



Interestingly, we just got a question on ask.sagemath which turned out to be someone who really wanted to read some very old (2007!) notebook's of William's on the BSD conjecture; so the issue is at least not totally theoretical... 

Jeroen Demeyer

unread,
Nov 11, 2012, 4:28:34 AM11/11/12
to sage-...@googlegroups.com
On 2012-11-11 00:17, David Kirkby wrote:
> I'm guessing nobody is going to write any doctests for code which is
> only there to maintain backward compatibility. So if it remains
> untested, why should it be removed from the test figures?
+1 on this.
This is code which is apparently still used (if only for backwards
compatibility) but untested. So it's genuinely missing doctest coverage.

William Stein

unread,
Nov 11, 2012, 10:02:06 AM11/11/12
to sage-...@googlegroups.com
Hi,

We should remove that code for loading old notebook server installs.
We established a 1-year deprecation policy for the Sage project long
ago, and that applies here. The functionality being deprecated is
"read a notebook server install in a certain format", and it has been
deprecated for about 3 years now. So it is time to delete it.

Anybody can still read old notebook installs, but it will be more work
for them -- they would have to install sage <= 5.4, then start the
notebook (to cause format migration), then switch back to using their
new version of Sage.

Congrats on reaching 90%!!

William

Keshav Kini

unread,
Nov 17, 2012, 2:38:30 PM11/17/12
to sage-...@googlegroups.com
Volker Braun <vbrau...@gmail.com> writes:
> Incidentally, about the legacy code for loading old notebooks: here
> is one lesson to be learned about long-term support of data files.
> The only sane way to handle this imho is:
>
> * The current code can read/write the current data format
> * Whenever you upgrade from format version N to N+1, you write a
> self-contained updater.
> * Old files are sent through the chain of updaters until they are
> current.

+1, that makes a lot of sense. Who says Sage devs don't know about
software engineering? :P

-Keshav

Reply all
Reply to author
Forward
0 new messages