On Tue, Jun 15, 2010 at 3:56 AM, daveloeffler wrote:
> (I'm working on a couple of tickets but I can't remember my Sage wiki
> account password -- can someone with admin rights reset it for me?)
As far as I know, nobody knows how to reset Sage wiki passwords.
Just make a new account with a slight
(I'm working on a couple of tickets but I can't remember my Sage wiki
account password -- can someone with admin rights reset it for me?)
On Jun 15, 10:14 am, Alex Ghitza wrote:
> On Tue, 15 Jun 2010 01:02:56 -0700 (PDT), Simon King
> wrote:
> > On Jun 12, 2:38 pm, John Cremona wrote:
> > > Is
On Tue, 15 Jun 2010 01:02:56 -0700 (PDT), Simon King
wrote:
> On Jun 12, 2:38 pm, John Cremona wrote:
> > 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?
>
> This would be
Hi all!
On Jun 12, 2:38 pm, John Cremona wrote:
> 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?
This would be good to have.
For the record:
I took care of sage.categories.hom
On Fri, Jun 11, 2010 at 7:30 PM, Minh Nguyen wrote:
> The Developer's
> Guide lacks a list of general areas against which testing should be
> performed and test code written.
This is now ticket #9241:
http://trac.sagemath.org/sage_trac/ticket/9241
--
Regards
Minh Van Nguyen
--
To post to
Hi Andrey,
> > >> They can go in separate files, files which, for example, are not
> > >> included in the reference manual. The file sage/homology/tests.py is
> > >> an example. Each function should have doctests (so the goal is still
> > >> 100% coverage), but it's not a big deal to releg
On Jun 11, 2010, at 7:57 AM, Andrey Novoseltsev wrote:
On Jun 11, 2:46 am, Florent Hivert
wrote:
They can go in separate files, files which, for example, are not
included in the reference manual. The file sage/homology/
tests.py is
an example. Each function should have doctests (so the goal
On Jun 11, 2:46 am, Florent Hivert
wrote:
> >> They can go in separate files, files which, for example, are not
> >> included in the reference manual. The file sage/homology/tests.py is
> >> an example. Each function should have doctests (so the goal is still
> >> 100% coverage), but it's not a
Hi,
> > Where should such tests go? I am not sure that it is desirable to show
> > 50 sophisticated examples for a single function in the interactive or
> > compiled help. On the other hand, I really like when all the tests are
> > right next to the body of the function. Is it possible to, s
Hi Andrey,
On Fri, Jun 11, 2010 at 2:47 PM, Andrey Novoseltsev wrote:
> Where should such tests go? I am not sure that it is desirable to show
> 50 sophisticated examples for a single function in the interactive or
> compiled help. On the other hand, I really like when all the tests are
> righ
Hi Jason,
On Fri, Jun 11, 2010 at 7:30 PM, Jason Grout
wrote:
> 60 months old?? How about 6-12 months?
It's >= 6 months old. You know what I mean :-)
--
Regards
Minh Van Nguyen
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an
Hi kcrisman,
On Fri, Jun 11, 2010 at 11:19 AM, kcrisman wrote:
> But we do want doctests to test a fairly large number of the options,
> so just adding doctest coverage isn't enough. The doctests need to
> really test, as you say. Getting in more of the framework tests in
> (which I don't qu
On 6/11/10 4:19 AM, Minh Nguyen wrote:
Hi Florent,
On Fri, Jun 11, 2010 at 10:07 AM, Florent Hivert
wrote:
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 Simon,
On Fri, Jun 11, 2010 at 9:38 AM, Simon King wrote:
> Anyway, I am +1 to trying and getting a 90% overall doc test coverage;
> it is a valuable aim.
> IMO it is *always* worth it to write doc tests since it is very likely
> to uncover flaws (in particular if the person who writes the
Hi There,
>>> We don't even ensure that every statement of code
>>> gets executed at least once.
>>
>> Mike Hansen posted some code to use a tool to check that (a long time
>> ago). I imagine that after doctest coverage is up to 100% function
>> coverage that there will be a new push to t
>> They can go in separate files, files which, for example, are not
>> included in the reference manual. The file sage/homology/tests.py is
>> an example. Each function should have doctests (so the goal is still
>> 100% coverage), but it's not a big deal to relegate lots of technical
>> test to l
On Jun 10, 2010, at 8:41 PM, Jason Grout wrote:
On 6/10/10 7:20 PM, Dr. David Kirkby wrote:
We don't even ensure that every statement of code
gets executed at least once.
Mike Hansen posted some code to use a tool to check that (a long
time ago). I imagine that after doctest coverage is u
On Jun 10, 2010, at 10:34 PM, John H Palmieri wrote:
On Jun 10, 9:47 pm, Andrey Novoseltsev wrote:
On Jun 10, 9:41 pm, Jason Grout wrote:
I imagine that after doctest coverage is up to 100% function
coverage that there will be a new push to then get the statement
coverage up to 100%. It wo
On Jun 10, 9:47 pm, Andrey Novoseltsev wrote:
> On Jun 10, 9:41 pm, Jason Grout wrote:
>
> > I imagine that after doctest coverage is up to 100% function
> > coverage that there will be a new push to then get the statement
> > coverage up to 100%. It would be interesting even now to see how much
On Jun 10, 9:41 pm, Jason Grout wrote:
> I imagine that after doctest coverage is up to 100% function
> coverage that there will be a new push to then get the statement
> coverage up to 100%. It would be interesting even now to see how much
> statement coverage lagged behind function coverage.
W
On 6/10/10 7:20 PM, Dr. David Kirkby wrote:
We don't even ensure that every statement of code
gets executed at least once.
Mike Hansen posted some code to use a tool to check that (a long time
ago). I imagine that after doctest coverage is up to 100% function
coverage that there will be a n
> That was exactly what I meant. In the case of the interface to tachyon, it
> would
> appear there is absolutely no testing of this whatsoever
>
> # interfaces/tachyon.py: 0% (0 of 4)
Though there is some testing of it in the plot files. The point is
good, just not for that example.
> In cont
On 06/11/10 12:38 AM, Simon King wrote:
Hi David,
On 11 Jun., 00:32, "Dr. David Kirkby" wrote:
At least from my very little understanding of this, Having 89% coverage would be
better than 90% coverage, if those 89% were well targeted.
It is not clear to me why one module should be considered
Hi David,
On 11 Jun., 00:32, "Dr. David Kirkby" wrote:
> At least from my very little understanding of this, Having 89% coverage would
> be
> better than 90% coverage, if those 89% were well targeted.
It is not clear to me why one module should be considered being more
important than another. I
24 matches
Mail list logo
