> 1) being able to mark tests as "expected to fail"
>>
>
> You can mark a doctest as
>
> sage: 2+2 # known bug
> 5
>
> Then it won't get run ordinarily, but you can do "sage -t
> -only-optional=bug FILE.py" to run doctests marked this way. It doesn't
> quite do what you want, since
"Nicolas M. Thiery" writes:
> On Sun, Jul 22, 2012 at 10:44:36AM +0200, Martin Rubey wrote:
>> I am not completely sure I see your point: do you mean, that it is often
>> the case that a doctest fails because of a *different* patch? And once
>> that one is fixed, the patch owner would modify his
On Sun, Jul 22, 2012 at 10:44:36AM +0200, Martin Rubey wrote:
> I am not completely sure I see your point: do you mean, that it is often
> the case that a doctest fails because of a *different* patch? And once
> that one is fixed, the patch owner would modify his own?
My typical use case: I work
Andrew Mathas writes:
> Thanks for posting the errors showing up in partition.py. It seems
> that you have an older version of the patch (which should have still
> passed the doc tests), or possibly a misapplied one. It should go away
> when you merge, but Anne says that my patch is not applying
"Nicolas M. Thiery" writes:
> On Thu, Jul 19, 2012 at 11:45:09PM +0200, Martin Rubey wrote:
>> two things turned out to be very useful:
>>
>> 1) being able to mark tests as "expected to fail"
>
> That's certainly a nice too, but I would not advocate this in our
> situation, or at least not for
Hi Martin!
On Thu, Jul 19, 2012 at 11:45:09PM +0200, Martin Rubey wrote:
> Although I am now relieved that I didn't break anything, let me add one
> other idea: in the unittesting package for fricas, two things turned out
> to be very useful:
>
> 1) being able to mark tests as "expected t
Hi Martin,
>
> Also, what's the right way to correct the qt_catalan doctest?
>
> sage: q_analogues.qt_catalan_number(1)
> Expected:
> 1
> Got:
> doctest:178: DeprecationWarning: a_statistic is deprecated, use area
> instead!
> doctest:178: DeprecationWarning: b_statistic is
Anne Schilling writes:
> For me with all patches applied on sage-5.1, the tests for
> partition.py also pass!
> On 7/19/12 6:58 PM, Andrew Mathas wrote:
>> I am curious as to exactly what you did to get these doc test
>> errors. Am I right in thinking that you applied all of the patches
>> curr
Hi Andrew and Martin,
For me with all patches applied on sage-5.1, the tests for partition.py also
pass!
Anne
On 7/19/12 6:58 PM, Andrew Mathas wrote:
> Hi Martin,
>
> I am curious as to exactly what you did to get these doc test errors. Am I
> right in thinking that you applied all of the pat
Hi Martin,
I am curious as to exactly what you did to get these doc test errors. Am I
right in thinking that you applied all of the patches currently in the
queue (hg qpush -a) and then ran all of the doc tests to get these
failures? Which version of sage are you using?
The reason that I am as
On Thursday, July 19, 2012 2:45:09 PM UTC-7, Martin wrote:
>
> Anne Schilling writes:
>
> > Here are several *ideas*:
> >
> > * We should run daily tests on the "needs review" section and pop
> patches
> > off that section if the tests do not pass (or people are not actively
> working
>
Anne Schilling writes:
> Here are several *ideas*:
>
> * We should run daily tests on the "needs review" section and pop patches
> off that section if the tests do not pass (or people are not actively
> working
> on making them pass).
>
> * Everyone should try to get their patches into main-
Dear All!
Given Martin's questions about the doc test failures on the queue and also
some discussions I had last week at the Sage Days and by e-mail with Franco,
perhaps we need to discuss some issues about the sage-combinat queue.
First of all, the queue is meant for active development of code i
Anne Schilling writes:
> Hi Martin,
>
> If you want to run tests on your own patch, I suggest to apply it to a clean
> version of sage-5.2.rc0. All tests in a clean version of sage-5.2.rc0 should
> pass! The ones that fail would then be due to your patch.
Well, what I was doing depends on most o
Hi Martin,
If you want to run tests on your own patch, I suggest to apply it to a clean
version of sage-5.2.rc0. All tests in a clean version of sage-5.2.rc0 should
pass! The ones that fail would then be due to your patch.
If you run sage -t on the sage-combinat queue, it is not guaranteed that
t
I just wanted to test whether some experimental changes wouldn't break
anything and ran
sage -t devel/sage-combinat/sage/combinat/
I get quite a few failures, ugly errors, etc.
Which of these should I expect?
eg.
File
"/groups/comb/rubey/sage-5.1/devel/sage-combinat/sage/combinat/subsets_pai
Hi!
Actually, I think the easiest to install gap3 for Sage is using
sage -f http://sage.math.washington.edu/home/nthiery/gap3-jm2.spkg
Best,
Anne
On 3/15/12 10:59 AM, Christian Stump wrote:
> Dear Marc,
>
>> /coxeter_group.py", line 256, in CoxeterGroup
>>assert is_chevie_available()
Never mind, I had named the shellscript
"gap" instead of "gap3".
--Mark
> Can you reconfirm that you can run gap3 from the command line within
> the Sage folder. I wouldn't know anything else necessary, do you
> Nicolas? Next, what happens if you run "gap3.console()" from within
> Sage?
>
> --
>
> I already installed the J-M distro of gap3 and
> it works from the command line,
> but how do I tell sage of its existence?
Can you reconfirm that you can run gap3 from the command line within
the Sage folder. I wouldn't know anything else necessary, do you
Nicolas? Next, what happens if you run
Cristian and Nicolas,
I already installed the J-M distro of gap3 and
it works from the command line,
but how do I tell sage of its existence?
I see that the ticket has a line
sage -i gap3-jm2.spkg
based on an older version.
--Mark
> I have just updated the GAP3 interface ticket description on
Hi,
I have just updated the GAP3 interface ticket description on
http://trac.sagemath.org/sage_trac/ticket/8380
to describe how to install GAP3 (including a link to the spkg based on
Jean-Michel's distribution). Please check!
On Thu, Mar 15, 2012 at 06:59:03PM +0100, Christian S
Dear Marc,
> /coxeter_group.py", line 256, in CoxeterGroup
> assert is_chevie_available()
To use the coxeter groups implementation, you must have gap3 installed
(i.e., typing "gap3" in the command line starts gap3), and the chevie
package available (i.e., typing RequirePackage("chevie") wi
Arrgh, I had my google account settings wrong and several of my email
posts went to the
bit bucket before I noticed.
I have been encountering doctest errors involving the availability of
chevie:
/coxeter_group.py", line 256, in CoxeterGroup
assert is_chevie_available()
What is the workar
23 matches
Mail list logo
