Am 10.06.2015 um 00:37 schrieb Ondřej Čertík:
It's really about who's turn it is. So that both reviewers as well as
authors can see if they need to do anything.
Another potential approach is "what needs to be done next"?
The label set that came out of this thought was this:
Needs Evaluation:
On Tue, Jun 9, 2015 at 7:33 PM, Aaron Meurer wrote:
> On Tue, Jun 9, 2015 at 7:09 PM, Ondřej Čertík wrote:
>> Hi,
>>
>> I would like to evaluate to higher accuracy (quadruple precision is
>> enough) an inverse Fermi-Dirac integral of order 1/2. The direct
>> function is the following integral (an
On Tue, Jun 9, 2015 at 7:09 PM, Ondřej Čertík wrote:
> Hi,
>
> I would like to evaluate to higher accuracy (quadruple precision is
> enough) an inverse Fermi-Dirac integral of order 1/2. The direct
> function is the following integral (and it can also be written as a
> polylogarithm):
>
> I_{1/2}(
Hi,
I would like to evaluate to higher accuracy (quadruple precision is
enough) an inverse Fermi-Dirac integral of order 1/2. The direct
function is the following integral (and it can also be written as a
polylogarithm):
I_{1/2}(x) = Integral(sqrt(t) / (1+exp(t-x)), (t, 0, oo))
= -gamma(S(3)/2)
On Tue, Jun 9, 2015 at 4:27 PM, Joachim Durchholz wrote:
> Am 10.06.2015 um 00:22 schrieb Ondřej Čertík:
>>>
>>> That way, each PR is in one (and only one) of the following stages:
>>>
>>> * tests are in progress (the yellow status)
>>> * labelled "PR: needs more work (author's turn)"
>>> * labell
On Tue, Jun 9, 2015 at 4:25 PM, Joachim Durchholz wrote:
> Am 09.06.2015 um 23:55 schrieb Jason Moore:
>>
>> I don't think Github cares how we manage our projects.
>
>
> Sort of. There is a "GitHub workflow", and not all git workflows are easily
> mappable to it (git-flow, for example, won't - not
Am 10.06.2015 um 00:22 schrieb Ondřej Čertík:
That way, each PR is in one (and only one) of the following stages:
* tests are in progress (the yellow status)
* labelled "PR: needs more work (author's turn)"
* labelled "PR: in review"
How about calling these:
PR: author's turn
PR: sympy's turn
Am 09.06.2015 um 23:55 schrieb Jason Moore:
I don't think Github cares how we manage our projects.
Sort of. There is a "GitHub workflow", and not all git workflows are
easily mappable to it (git-flow, for example, won't - not easily anyway).
Though I agree that they probably don't care about
> How about calling these:
>
> PR: author's turn
> PR: sympy's turn
Another idea is:
PR: author's turn
PR: author is done
Let's find some good names for the labels.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and
On Tue, Jun 9, 2015 at 4:20 PM, Ondřej Čertík wrote:
>
>
> On Tue, Jun 9, 2015 at 3:14 PM, Aaron Meurer wrote:
>>
>> FYI you can sort pull requests by Travis CI status
>> https://github.com/blog/2014-filter-pull-requests-by-status.
>
>
>
> That's where I got the idea to filter by passing tests. C
On Tue, Jun 9, 2015 at 3:14 PM, Aaron Meurer wrote:
> FYI you can sort pull requests by Travis CI status
> https://github.com/blog/2014-filter-pull-requests-by-status.
>
That's where I got the idea to filter by passing tests. Coming to think
about it, the label "PR: waiting for Travis to finish
I don't think Github cares how we manage our projects. This is only about
enabling us to manage it how we want/need. If they have a checkbox in the
repo's settings that allows/disallows PR authors to modify labels then we
can decide how much freedom we want to give an author.
Jason
moorepants.inf
Am 09.06.2015 um 23:39 schrieb Jason Moore:
Ondrej and I thought that we should ask Github to enable PR authors'
ability to modify labels on their own PRs. We should all put in a request
for that.
Labels such as "ready to merge if Travis is okay with it" should not be
settable by the PR author
Ondrej and I thought that we should ask Github to enable PR authors'
ability to modify labels on their own PRs. We should all put in a request
for that.
Jason
moorepants.info
+01 530-601-9791
On Tue, Jun 9, 2015 at 2:22 PM, Joachim Durchholz wrote:
> I've added few labels related to PR:
>>
>>
I've added few labels related to PR:
PR: needs more work (author's turn)
PR: waiting for Travis to finish
and then we can use them in a query.
Only contributors (i.e. people with repository write access) can set or
remove these labels. I.e. most authors can't remove "needs more work"
when th
FYI you can sort pull requests by Travis CI status
https://github.com/blog/2014-filter-pull-requests-by-status.
Aaron Meurer
On Tue, Jun 9, 2015 at 3:44 PM, Sudhanshu Mishra wrote:
> I am pretty sure that builds that time out eventually turn into the
>
> red or gray cross, don't they?
>
>
>
>
>
> I am pretty sure that builds that time out eventually turn into the
red or gray cross, don't they?
They show "Errored" instead of "Failed".
Sudhanshu Mishra
On Wed, Jun 10, 2015 at 2:10 AM, Ondřej Čertík
wrote:
> On Tue, Jun 9, 2015 at 2:31 PM, Sartaj Singh
> wrote:
> > I think it's
On Tue, Jun 9, 2015 at 2:31 PM, Sartaj Singh wrote:
> I think it's a good idea. +1
>
> Just a note. Reviewer should be careful with the 'waiting for Travis to
> finish' Label. Sometimes it's just a timeout Error. So, errored build should
> be kept in mind while assigning the labels.
I am pretty s
I think it's a good idea. +1
Just a note. Reviewer should be careful with the 'waiting for Travis to
finish' Label. Sometimes it's just a timeout Error. So, errored build
should be kept in mind while assigning the labels.
On 10 June 2015 at 01:27, Ondřej Čertík wrote:
> Hi,
>
> I've added few l
Hi,
I've added few labels related to PR:
PR: needs more work (author's turn)
PR: waiting for Travis to finish
and then we can use them in a query. In particular, to only see PRs that
* are open
* pass all tests
* do not have the "PR: needs more work (author's turn)" label
* sort by recently upd
Thank you for your answer.
Will use limit.
On Tuesday, June 9, 2015 at 10:15:17 PM UTC+3, Aaron Meurer wrote:
>
> I don't think there's an easy way to do it without changing the code.
>
> Note that having 1/0 give oo instead of zoo can lead to subtle errors.
> See for instance https://github.co
I don't think there's an easy way to do it without changing the code.
Note that having 1/0 give oo instead of zoo can lead to subtle errors.
See for instance https://github.com/sympy/sympy/issues/5910. This was
one of the main reasons we changed it to return zoo.
In general, it's better to use li
Yes. I already started a PR https://github.com/sympy/sympy/pull/9489
Sudhanshu Mishra
On Tue, Jun 9, 2015 at 10:36 PM, Aaron Meurer wrote:
> Oh I didn't realize it's already the slow tests. In that case, we should
> either split them or lower the test timeout.
>
> Aaron Meurer
>
> On Tue, Jun 9
Oh I didn't realize it's already the slow tests. In that case, we should
either split them or lower the test timeout.
Aaron Meurer
On Tue, Jun 9, 2015 at 12:04 PM, Aaron Meurer wrote:
> Is there a specific test that's being slow? If so, we should just mark it
> as @slow until we can improve the
Is there a specific test that's being slow? If so, we should just mark it
as @slow until we can improve the performance.
Aaron Meurer
On Tue, Jun 9, 2015 at 12:32 AM, Sudhanshu Mishra wrote:
> Hi all,
>
> Slow tests are getting errored very frequently because of timeout. I think
> this is happe
SystemError: Parent module 'sympy.core' not loaded, cannot perform relative
import
When I try to run the following:
expr=sqrt(pi)*(sqrt(2)*(1 - I)*erf(sqrt(-I)) + sqrt(2)*(-1 +
I)*erf(sqrt(2)*(-1/2 + I/2)) + sqrt(2)*(1 + I)*erf((-1)**(1/4)) +
sqrt(2)*(1 + I)*erf(sqrt(2)*(1/2 + I/2)))/16
expr.ro
Is it possible to make sympy to return oo instead of zoo for expressions
like 1/0 and tan(pi/2).
What I need is real field.
-1/0 is -oo, not zoo.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails
Same here.
Sudhanshu Mishra
On Tue, Jun 9, 2015 at 7:14 PM, Joachim Durchholz wrote:
> I'm getting a failure for matplotlib when running the test suite locally,
> but not on Travis. I'm not sure whether that's a bug in implicit_plot, or
> in the test suite, or whether I'm just missing an instal
I'm getting a failure for matplotlib when running the test suite
locally, but not on Travis. I'm not sure whether that's a bug in
implicit_plot, or in the test suite, or whether I'm just missing an
installation dependency.
Here's the trace:
$ bin/test test_plot_implicit -k test_matplotlib
===
Hi,
Any normal profiler should work in views as mostly logic stays there.
Sudhanshu Mishra
On Wednesday, June 3, 2015 at 1:52:52 AM UTC+5:30, Paul Royik wrote:
>
> Is there anyway I can profile django app?
> Because sympy code is used from django app.
>
> On Tuesday, June 2, 2015 at 8:11:20 PM U
30 matches
Mail list logo
