On Mon, Oct 15, 2012 at 9:23 AM, John Cremona <john.crem...@gmail.com> wrote:
> On 15 October 2012 17:15, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>> On Mon, Oct 15, 2012 at 4:22 AM, John Cremona <john.crem...@gmail.com> wrote:
>>> 1. In the Developers' Guide
>>> http://www.sagemath.org/doc/developer/conventions.html regarding
>>> optional doctests it says
>>>
>>> "Mark a doctest as optional if it requires optional packages; even
>>> better, mark it as optional - PKG_NAME if it requires the package
>>> PKG_NAME."
>>>
>>> I think this is not strong enough, and should be changed to
>>>
>>> "If a doctest requires the package PKG_NAME to run, mark it as
>>> optional using "optional - PKG_NAME". THE PKG_NAME should be the
>>> basename for the optional package, not the full name which includes a
>>> release date."
>>>
>>> The main point here is to make it compusory to have the spkg name as
>>> well as the tag "optional". Do you agree? If so, the Guide needs
>>> editing.
>>
>> Makes sense to me. Perhaps one could even require "optional package
>> FOO" which would make detecting them automatically
>> (http://trac.sagemath.org/sage_trac/ticket/13540) even easier for
>> these optional tests.
>>
>>> 2. I would find it useful to have a flag which does the reverse of
>>> "optional", say "not-if-optional" to tag a doctest which gets run if
>>> the optional spkg is not installed but not if it is. In case this
>>> seems odd, the optional spkg I have in mind is
>>> database_cremona_ellcurve which consists entirely of data, not code,
>>> and we are always running into situations where tests behave
>>> differently depending on whether or not the optional databse is
>>> installed. It would be good to have both. In my own testing I keep
>>> on having to uninstall the optional database, which is tedious as it
>>> is automatic (though it only involves deleting two files in this
>>> case).
>>>
>>> Does anyone else think this would a useful additional feature?
>>
>> Perhaps "optional not XXX" could be a useful construct for any XXX.
>> However, I think the tests might be worth re-writing if they fail due
>> to additional data. (Changing == into >= may be perfectly fine
>> depending on what we are actually trying to verify; who cares that
>> there are *only* a given number of curves in the base Sage install?)
>>
>
> Thanks, Robert -- I think you are the author of the doctest (line 6454
> in heegner.py) which currently fails when the optional large elliptic
> curve database is installed!
How about that...
> ("Fails" in the sense that something
> does work whil the doctest is written with the assumtption that it
> will not). Is it possible that you can change that example to an
> equivalent one with a curve of conductor much greater then 300000?
Yep, that certainly makes sense.
>> - Robert
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-devel" group.
>> To post to this group, send email to sage-devel@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sage-devel+unsubscr...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To post to this group, send email to sage-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> sage-devel+unsubscr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
