On Jun 11, 2010, at 2:42 AM, Minh Nguyen wrote:
Hi Florent,
On Fri, Jun 11, 2010 at 7:33 PM, Florent Hivert
florent.hiv...@univ-rouen.fr wrote:
SNIP
I like this way of seeing. However, I was speaking about module or
functions
which are not tested nor deprecated and nowhere used into
Is there still a wiki page for people to sign up to deal with one or
more of these? Or a standard for trac ticket titles to ensure that
effort is not duplicated?
I intend to deal with interfaces/mwrank.py (2/10) and
databases/cremona.py (17/40) (at least to start with!).
John
On 12 June 2010
Hi John,
I don't have an answer to your questions, but...
On Sat, 12 Jun 2010 14:38:52 +0100, John Cremona john.crem...@gmail.com wrote:
I intend to deal with interfaces/mwrank.py (2/10) and
databases/cremona.py (17/40) (at least to start with!).
... have a look at #9223, I have just posted
Hi David,
On Fri, Jun 11, 2010 at 7:21 AM, Dr. David Kirkby
david.kir...@onetel.net wrote:
SNIP
I think their test procedures are a bit over the top, but it certainly
brings in to perspective how some developers feel about testing.
More testing is good. The SQLite team certainly has a good
Hi David,
On Fri, Jun 11, 2010 at 8:32 AM, Dr. David Kirkby
david.kir...@onetel.net wrote:
SNIP
Consider two areas
# interfaces/tachyon.py: 0% (0 of 4)
# graphs/generic_graph.py: 99% (200 of 201)
Where would it be most useful to add one doc test?
At least from my very little
Hi Florent,
On Fri, Jun 11, 2010 at 10:07 AM, Florent Hivert
florent.hiv...@univ-rouen.fr wrote:
SNIP
They all looks like they should be deprecated and removed... If it's true I
rather improving the doctest coverage by removing them than adding
doctests... However I'd like to have the
Hi Minh,
They all looks like they should be deprecated and removed... If it's true I
rather improving the doctest coverage by removing them than adding
doctests... However I'd like to have the confirmation that they are indeed
obsolete...
We are aiming for a Sage 5.0 release. The
Hi Florent,
On Fri, Jun 11, 2010 at 7:33 PM, Florent Hivert
florent.hiv...@univ-rouen.fr wrote:
SNIP
I like this way of seeing. However, I was speaking about module or functions
which are not tested nor deprecated and nowhere used into sage (easy to check
using grep). Does it make sens
Hi Robert,
On Fri, Jun 11, 2010 at 12:34 PM, Robert Miller r...@rlmiller.org wrote:
Minh,
Can you make a report which lists the files which, if brought up to
100% coverage, would benefit overall coverage the most?
Here is my understanding of what you want. Let's say the Sage
community has
Hi,
I like this way of seeing. However, I was speaking about module or functions
which are not tested nor deprecated and nowhere used into sage (easy to
check
using grep). Does it make sens to remove them without a deprecation warning
?
Many code seems to had been put here, just
Minh,
On Fri, Jun 11, 2010 at 2:49 AM, Minh Nguyen nguyenmi...@gmail.com wrote:
Here is my understanding of what you want. Let's say the Sage
community has enough time to write tests for 20 modules. Which 20
modules could we choose to write tests for such that it results in the
greatest
Hi Florent,
On Fri, Jun 11, 2010 at 9:32 PM, Florent Hivert
florent.hiv...@univ-rouen.fr wrote:
SNIP
sage/monoids/monoid.py
I think this module should stay put. Here is a dependency chart based
on that module:
monoids.monoid.Monoid_class -- monoids.free_monoid.FreeMonoid_class
--
Hi Minh,
Thanks for carefully investigating those:
sage/monoids/monoid.py
I think this module should stay put. Here is a dependency chart based
on that module:
monoids.monoid.Monoid_class -- monoids.free_monoid.FreeMonoid_class
-- monoids.string_monoid.StringMonoid_class
where
On Jun 11, 2010, at 2:33 AM, Florent Hivert wrote:
Hi Minh,
They all looks like they should be deprecated and removed... If
it's true I
rather improving the doctest coverage by removing them than adding
doctests... However I'd like to have the confirmation that they
are indeed
Hi Robert,
On Fri, Jun 11, 2010 at 9:47 PM, Robert Miller r...@rlmiller.org wrote:
SNIP
Yes, exactly. Or 5 modules, or 100. I want to go down the list and
start writing doctests for the first module I see there which I feel
relatively comfortable working on.
See the updated coverage report
On Thu, Jun 10, 2010 at 2:21 PM, Dr. David Kirkby
david.kir...@onetel.net wrote:
On 06/10/10 09:25 PM, Minh Nguyen wrote:
Hi folks,
One of the main goals of the upcoming Sage 5.0 release is to get
doctest coverage of the Sage library up to at least 90%. As of Sage
4.4.4.alpha0, the overall
On 06/10/10 09:25 PM, Minh Nguyen wrote:
Hi folks,
One of the main goals of the upcoming Sage 5.0 release is to get
doctest coverage of the Sage library up to at least 90%. As of Sage
4.4.4.alpha0, the overall weighted coverage is 82.7%.
Seems we are a long way off.
It seems to me, rather
On 06/10/10 10:27 PM, William Stein wrote:
On Thu, Jun 10, 2010 at 2:21 PM, Dr. David Kirkby
david.kir...@onetel.net wrote:
On 06/10/10 09:25 PM, Minh Nguyen wrote:
Hi folks,
One of the main goals of the upcoming Sage 5.0 release is to get
doctest coverage of the Sage library up to at least
Hi Minh,
And you're done. Here [2] is a report generated by the script. The
idea is to provide an overview of which modules need work. I'd be
interested to know what other types of doctest coverage reports people
would like to see. Comments, suggestions, critiques, etc. are welcome.
Minh,
Can you make a report which lists the files which, if brought up to
100% coverage, would benefit overall coverage the most?
On Thu, Jun 10, 2010 at 1:25 PM, Minh Nguyen nguyenmi...@gmail.com wrote:
Hi folks,
One of the main goals of the upcoming Sage 5.0 release is to get
doctest
On Jun 10, 2010, at 2:21 PM, Dr. David Kirkby wrote:
On 06/10/10 09:25 PM, Minh Nguyen wrote:
Hi folks,
One of the main goals of the upcoming Sage 5.0 release is to get
doctest coverage of the Sage library up to at least 90%. As of Sage
4.4.4.alpha0, the overall weighted coverage is 82.7%.
21 matches
Mail list logo
