Plans for release
Andy Ray Terrel
to release my library, which only works on dev.
-- Andy
Vinzent Steinberg
> Are there any plans for releasing soon? It been a year and I'd like
> to release my library, which only works on dev.
we probably could also do a release before this.
Vinzent
Ronan Lamy
I don't think we can do a release before the end of GSoC proposals
review, but we should probably do it as soon as possible afterwards -
hopefully with polys, but without it if it's not ready yet. Some time in
the first half of May seems reasonable, and would be a good "community
bonding" exercise for the GSoC students. What do you think, Aaron?
Mateusz Paprocki
Le vendredi 01 avril 2011 à 06:56 -0700, Vinzent Steinberg a écrit :
> On Apr 1, 10:44 am, Andy Ray Terrel <andy.ter...@gmail.com> wrote:
> > Are there any plans for releasing soon? It been a year and I'd like
> > to release my library, which only works on dev.
>
> I think we wanted to get the new polys in before the next release. ButI don't think we can do a release before the end of GSoC proposals
> we probably could also do a release before this.
review, but we should probably do it as soon as possible afterwards -
hopefully with polys, but without it if it's not ready yet. Some time in
the first half of May seems reasonable, and would be a good "community
bonding" exercise for the GSoC students. What do you think, Aaron?
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Ronan Lamy
> �crit :
> > On Apr 1, 10:44 am, Andy Ray Terrel <andy.ter...@gmail.com>
> wrote:
> > > Are there any plans for releasing soon? It been a year
> and I'd like
> > > to release my library, which only works on dev.
> >
>
>
>
> We should have released ages ago and it would be great to do it at
> some point.
>
> > I think we wanted to get the new polys in before the next
> release. But
> > we probably could also do a release before this.
>
>
> I don't think we can do a release before the end of GSoC
> proposals
> review, but we should probably do it as soon as possible
> afterwards -
> hopefully with polys, but without it if it's not ready yet.
> Some time in
> the first half of May seems reasonable, and would be a good
> "community
> bonding" exercise for the GSoC students. What do you think,
> Aaron?
>
>
> polys have been ready for three months now.
>
Aaron S. Meurer
On Apr 1, 2011, at 1:59 PM, Ronan Lamy wrote:
> Le vendredi 01 avril 2011 à 12:12 -0700, Mateusz Paprocki a écrit :
>> Hi,
>>
>> On 1 April 2011 11:26, Ronan Lamy <ronan...@gmail.com> wrote:
>> Le vendredi 01 avril 2011 à 06:56 -0700, Vinzent Steinberg a
>> écrit :
>>> On Apr 1, 10:44 am, Andy Ray Terrel <andy.ter...@gmail.com>
>> wrote:
>>>> Are there any plans for releasing soon? It been a year
>> and I'd like
>>>> to release my library, which only works on dev.
>>>
>>
>>
>>
>> We should have released ages ago and it would be great to do it at
>> some point.
>>
>>> I think we wanted to get the new polys in before the next
>> release. But
>>> we probably could also do a release before this.
>>
>>
>> I don't think we can do a release before the end of GSoC
>> proposals
>> review, but we should probably do it as soon as possible
>> afterwards -
>> hopefully with polys, but without it if it's not ready yet.
>> Some time in
>> the first half of May seems reasonable, and would be a good
>> "community
>> bonding" exercise for the GSoC students. What do you think,
>> Aaron?
Yes, absolutely. The GSoC stuff has pushed the release (and everything else) to the back burner, but after we accept students, things should cool down a little bit. At that point, releasing will be the top priority. And I think it would be great if we could get some of the GSoC students to help. Tt should make a good community bonding exercise. We just need help with a few critical patches, but mostly with reviewing stuff, which is something that they will need to learn to do.
By the way, we still have a few issues blocking the release. See all the Release0.7.0 issues at http://code.google.com/p/sympy/issues/list (they are sorted at the top of the list by default). Most of those are part of polys12, but a handful are not.
>>
>>
>> polys have been ready for three months now.
>>
> Well, no. They've never been through review.
Well, clearly we have a misunderstanding here. There are definitely a few things in polys12 that are blocking merging (like the sum() thing). But there have also been some other comments (mainly by Ronan) throughout your branch. For example, some people have had some problems with Pure. I think these comments are all on GitHub (correct me if I am wrong).
We have make several attempts to fix these on our own, with various success. For example, https://github.com/sympy/sympy/pull/120. It would probably be best if you could fix these things yourself, since for example, you will know best how to manage the conflicts when merging/rebasing over master. But in the absence of work from you, we have attepted to do it ourselves, so we can still release with the branch merged in at some point.
Aaron Meurer
Mateusz Paprocki
But there have also been some other comments (mainly by Ronan) throughout your branch. For example, some people have had some problems with Pure. I think these comments are all on GitHub (correct me if I am wrong).
We have make several attempts to fix these on our own, with various success. For example, https://github.com/sympy/sympy/pull/120. It would probably be best if you could fix these things yourself, since for example, you will know best how to manage the conflicts when merging/rebasing over master. But in the absence of work from you, we have attepted to do it ourselves, so we can still release with the branch merged in at some point.
Aaron Meurer
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Aaron S. Meurer
But there have also been some other comments (mainly by Ronan) throughout your branch. For example, some people have had some problems with Pure. I think these comments are all on GitHub (correct me if I am wrong).
This looked to me more like a wish list. Anyway, no patches followed.
We have make several attempts to fix these on our own, with various success. For example, https://github.com/sympy/sympy/pull/120. It would probably be best if you could fix these things yourself, since for example, you will know best how to manage the conflicts when merging/rebasing over master. But in the absence of work from you, we have attepted to do it ourselves, so we can still release with the branch merged in at some point.
I rebased my branch twice already for a release that never happened and it seems I only wasted my time for this. Do you expect that three months after last rebase it will still work out of the box with the most recent master? I'm sure that if this branch was merged, all the tiny details would have been fixed by now. This branch is not 10 patches or something that should be supposed to work perfectly upon merge. This is a branch consists of 500+ commits touching most significant areas of SymPy and it will require time, effort and support of the community to settle in. How do you expect to have support of the community (!= two or three people) in some branch. I don't need theoretical discussions about it, I need people who will use it on daily basis and report issues and inconveniences (like you did Aaron when working on implementation of Risch algorithm, which was valuable and helpful and resulted in significant improvements to my implementation of polynomial manipulation module).
Ronan Lamy
>
> On Apr 1, 2011, at 3:36 PM, Mateusz Paprocki wrote:
>
> > Hi,
> >
> > On 1 April 2011 13:36, Aaron S. Meurer <asme...@gmail.com> wrote:
> >
> >
> > On Apr 1, 2011, at 1:59 PM, Ronan Lamy wrote:
> >
> > a �crit :> > >> Le vendredi 01 avril 2011 � 06:56 -0700, Vinzent
> > Steinberg a
> > >> �crit :
Standard procedure is that the submitter of the pull request fixes
things, not the reviewer. You never actually sent any pull request for
this, which is part of the problem, but you did say you wanted your
branch to be merged, so I supposed it was the same thing.
>
> Well, I do have to agree that Ronan was not the clearest about what he
> wanted to be done (in fact, I am not not entirely sure what needs to
> be done).
I am not entirely sure what needs to be done either, because the branch
is way too big to be reviewed in one go and because it has never been
possible to discuss it in a forum convenient for review (i.e. a pull
request initiated by Mateusz).
I don't understand why you never agreed to do anything that would make
the branch smaller, even though the problem is precisely that it's too
big. There are commits that could go in today.
Issue 2241 is nearly fixed. After that, it's just a matter of editing a
bunch of doctests.
> - How do you feel about Chris's p12 branch (see the pull request
> linked to in my previous reply)? He has basically done this all
> (rebased over master, rebased out the sum commit, and added some
> commits fixing test failures and changing Pure to be a dummy). I
> think there are still some test failures there, and the commit
> messages need to be cleaned up, but if you are fine with it, we can
> finish that and get it in.
>
>
> What other concrete problems do others (Ronan) have with the branch?
> I really want to get this in already, because I am tired of referring
> people to polys12 for some functionality, and I also really want to
> get a release out.
Everybody is tired of this situation, I guess. Basically, the meta-issue
is that I think that every significant change outside sympy/polys should
be discussed on its own (i.e. as a separate pull request).
Anyway, here's an incomplete list off the top of my head:
* The RootOf constructor is too complicated (cf. issue 51 and other
discussions I can't find ATM)
* Lambda.is_identity shouldn't be implemented (cf issue 2178)
* .find() and .replace() need to be discussed. The proposed interface of
the latter is too complex.
* symbols('xyz') should be deprecated, but not removed outright (I don't
think I ever mentioned that one before)
* exprtools adds an additional mess to a messy situation in Add and Mul
* Most additions to sympy.utilities.iterables reimplement functions in
itertools.
Aaron S. Meurer
On Apr 1, 2011, at 7:03 PM, Ronan Lamy wrote:
> Le vendredi 01 avril 2011 à 16:29 -0600, Aaron S. Meurer a écrit :
>>
>> On Apr 1, 2011, at 3:36 PM, Mateusz Paprocki wrote:
>>
>>> Hi,
>>>
>>> On 1 April 2011 13:36, Aaron S. Meurer <asme...@gmail.com> wrote:
>>>
>>>
>>> On Apr 1, 2011, at 1:59 PM, Ronan Lamy wrote:
>>>
>>>> Le vendredi 01 avril 2011 à 12:12 -0700, Mateusz Paprocki
>>> a écrit :
>>>>> Hi,
>>>>>
>>>>> On 1 April 2011 11:26, Ronan Lamy <ronan...@gmail.com>
>>> wrote:
>>>>> Le vendredi 01 avril 2011 à 06:56 -0700, Vinzent
>>> Steinberg a
>>>>> écrit :
I agree with this. Mateusz should create a pull request for polys12.
If Mateusz is willing to do something like this, I am fine. The problem is that jumbling around a huge branch like that can get messy fast, and also we need to take care not to lose any commits.
I agree, although actually I am thinking of different things than Ronan (my main issue is the use of None to get the real roots, when RootOf(real=True) would be better imo).
> * Lambda.is_identity shouldn't be implemented (cf issue 2178)
> * .find() and .replace() need to be discussed. The proposed interface of
> the latter is too complex.
What is wrong with this? I though it was just expr.replace(old, new), where it uses .match() so that it is smart if it uses Wilds. Anyway, if you don't like something, you have to be specific about what is wrong with it.
> * symbols('xyz') should be deprecated, but not removed outright (I don't
> think I ever mentioned that one before)
I don't think this will work. symbols('xyz') should create one symbol (Symbol('xyz')). Trying to deprecate this would just keep the bad interface problem there (see the discussion in issue 1977).
> * exprtools adds an additional mess to a messy situation in Add and Mul
Is this actually used anywhere? If not, we could just hold out on it pretty easily. Or we could add it as a (currently unused) prototype.
> * Most additions to sympy.utilities.iterables reimplement functions in
> itertools.
Maybe this one is being picky. I don't care either way with it.
Aaron Meurer
Mateusz Paprocki
What is wrong with this? I though it was just expr.replace(old, new), where it uses .match() so that it is smart if it uses Wilds. Anyway, if you don't like something, you have to be specific about what is wrong with it.
> * Lambda.is_identity shouldn't be implemented (cf issue 2178)
> * .find() and .replace() need to be discussed. The proposed interface of
> the latter is too complex.
I don't think this will work. symbols('xyz') should create one symbol (Symbol('xyz')). Trying to deprecate this would just keep the bad interface problem there (see the discussion in issue 1977).
> * symbols('xyz') should be deprecated, but not removed outright (I don't
> think I ever mentioned that one before)
Is this actually used anywhere? If not, we could just hold out on it pretty easily. Or we could add it as a (currently unused) prototype.
> * exprtools adds an additional mess to a messy situation in Add and Mul
Maybe this one is being picky. I don't care either way with it.
> * Most additions to sympy.utilities.iterables reimplement functions in
> itertools.
Aaron Meurer
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Andy Ray Terrel
that meet a minimum standard are pushed in. In the interest of not
going 1.5 years between releases, I suggest we create issues for what
needs to be done and push Mateusz's code.
-- Andy
Vinzent Steinberg
> * The RootOf constructor is too complicated (cf. issue 51 and other
> discussions I can't find ATM)
> * Lambda.is_identity shouldn't be implemented (cf issue 2178)
S.Identity'?
> * .find() and .replace() need to be discussed. The proposed interface of
the latter is too complex.
see your point. Achieving replace()'s functionality in current sympy
is counter-intuitive IMHO.
> * symbols('xyz') should be deprecated, but not removed outright (I don't
> think I ever mentioned that one before)
docstring. There was no DeprecationWarning, this was maybe a mistake.
In any case, 0.7 is intended to break compatibility. So I'm +1 on
fixing this.
> * exprtools adds an additional mess to a messy situation in Add and Mul
> * Most additions to sympy.utilities.iterables reimplement functions in
itertools.
I'm fine with this, especially if we still support Python 2.4. This
can be easily fixed later.
Mateusz wrote:
> "A" isn't a very informative commit message
accident.
However, I would agree that code review nowadays is pickier than in
the past, looking at some code in sympy.
> Do you expect that three months after
> last rebase it will still work out of the box with the most recent master?
merge my commit trivially fixing failures), so this is currently not
really an issue.
Let's summarize anything that needs to be done - as specific as
possible - and do it.
Vinzent
[1] https://github.com/sympy/sympy/pull/120
smichr
get it in place so the things that are good can get exercised and
those that are not can get excised without causing a big headache. I
also believe it will be best to get this in before the GSoC gets to
work because every bit of work that interferes with p12 makes for more
work in doing the rebase.
I've already spent about 30 hours rebasing and going over commits and
feel pretty good about the integrity of p12 as a whole. Given Ondrej's
reminder that bisection can use the --skip option which results in a
range of commits being returned as the faulty range I am less stressed
about smoothing everything out in p12. Though tests will not all pass
in each commit, all commits allow `from sympy import *` to be
executed.
I'm heartily in favor of pushing this asap and am willing to help "get
it done" as Vinzent suggests.
Chris
smichr
to get uncovered lines covered. I can repost those if there is
interest. I'm talking about lines that were modified or added by
polys12 that are uncovered, not sympy lines in general.
Chris
smichr
or git-widget?
Here's the first issue that I would raise:
TODO:
1) as_coeff_Mul is very similar to as_coeff_mul - should we name that
method .mul0() and add another named .add0()? - this isn't a show
stopper, but if we could get it cleared up before adding it I think it
would be good. There will be lag time between when we push and when
people start using things...but if this is going in for 0.7 it would
be nice to not break compatibility soon after by changing as_coeff_Mul
to something else after 0.7.
Ronan Lamy
> Hi,
>
> On 1 April 2011 18:51, Aaron S. Meurer <asme...@gmail.com> wrote:
>
>
> On Apr 1, 2011, at 7:03 PM, Ronan Lamy wrote:
>
> �crit :
> >>
> >> On Apr 1, 2011, at 3:36 PM, Mateusz Paprocki wrote:
> >>
> >>> Hi,
> >>>
> >>> On 1 April 2011 13:36, Aaron S. Meurer
> <asme...@gmail.com> wrote:
> >>>
> >>>
> >>> But there have also been some other comments
> (mainly by
> >>> Ronan) throughout your branch. For example, some
> people have
> >>> had some problems with Pure. I think these
> comments are all
> >>> on GitHub (correct me if I am wrong).
> >>>
> >>>
> >>> This looked to me more like a wish list. Anyway, no
> patches
> >>> followed.
> >
> > Standard procedure is that the submitter of the pull request
> fixes
> > things, not the reviewer. You never actually sent any pull
> request for
> > this, which is part of the problem, but you did say you
> wanted your
> > branch to be merged, so I supposed it was the same thing.
>
>
> I agree with this. Mateusz should create a pull request for
> polys12.
>
only for the reason that the GitHub interface can't deal with pull
request with more than 250 commits.
> >>
> >> I can definitely understand your pain here. polys12 is a
> very large
> >> branch, and it is very difficult to maintain separate from
> master.
> >>
> > I don't understand why you never agreed to do anything that
> would make
> > the branch smaller, even though the problem is precisely
> that it's too
> > big. There are commits that could go in today.
>
>
> If Mateusz is willing to do something like this, I am fine.
> The problem is that jumbling around a huge branch like that
> can get messy fast, and also we need to take care not to lose
> any commits.
>
>
> And this is my point. The more we will cut and slice this branch, the
> more extra work we will have.
If we push a prefix of the branch in, it won't create more work.
No, breaking APIs all the time wouldn't be convenient for our users. And
it's actually harder to explain one's choices and to make compromises
than to work on one's own. Experimenting is fine, and more than that,
it's often the best way of making progress on a difficult problem, but
it shouldn't be done in master - because we try to keep in a
quasi-releasable state, and because, as a consequence of that and of the
excessive interval since our last release, quite a few people appear to
rely on it.
What we could do is to have "official" development branches on the main
repo. These branches would be meant to be merged back into master at
some point so they would be subjected to most of the same review
requirements as master - clean commits, cleanly formatted code, (nearly)
all tests pass on (nearly) all commits for all supported platforms - but
considerations of backwards compatibility and interface design could be
relaxed.
>
>
> > * Lambda.is_identity shouldn't be implemented (cf issue
> 2178)
> > * .find() and .replace() need to be discussed. The proposed
> interface of
> > the latter is too complex.
>
>
> What is wrong with this? I though it was just
> expr.replace(old, new), where it uses .match() so that it is
> smart if it uses Wilds. Anyway, if you don't like something,
> you have to be specific about what is wrong with it.
>
>
> We agreed on this in an issue. If there are better ideas (I'm sure
> there are), why don't allow this to go in, and start from there?
>
>
> > * symbols('xyz') should be deprecated, but not removed
> outright (I don't
> > think I ever mentioned that one before)
>
>
> I don't think this will work. symbols('xyz') should create
> one symbol (Symbol('xyz')). Trying to deprecate this would
> just keep the bad interface problem there (see the discussion
> in issue 1977).
>
>
> Now I'm confused. Was 0.7.0 supposed to be this great release where
> backwards incompatible changes to the API should have been made? I'm
> pretty sure this was the purpose of this release. Anyway, deprecating
> this and keeping old syntax is a very bad idea.
>
Let's discuss it in http://code.google.com/p/sympy/issues/detail?id=1977
>
> > * exprtools adds an additional mess to a messy situation in
> Add and Mul
>
>
> Is this actually used anywhere? If not, we could just hold
> out on it pretty easily. Or we could add it as a (currently
> unused) prototype.
>
>
> Actually it's a very important part of this branch and is used in
> together(), factor(), etc., to provide generalized and fast approach
> to manipulation of commutative expressions. This has nothing to do
> (directly) with Add and Mul, and if you don't understand this, please
> don't call this messy. I placed it in the core, because I'm sure this
> will be a significant part of the future core.
>
If you discussed it and explained your plans, maybe I would understand.
For now, I don't understand and I can only disagree. In particular, I
fail to understand how handling commutative expressions can be unrelated
to Add and Mul. Aren't Add and, in the common case, Mul commutative
expressions?
>
> > * Most additions to sympy.utilities.iterables reimplement
> functions in
> > itertools.
>
>
> Maybe this one is being picky. I don't care either way with
> it.
>
>
> Exactly. Doesn't this work? It does, tests pass. Is it redundant? At
> least partially, but when implementing those functions I didn't have
> any clue about this. Does this interfere with the merge? I don't
> think so and if we merged this three months ago, this could have been
> easily refined before the release.
>
Users don't care about your state of mind. They do care about having to
learn new interfaces only for sympy. They do care when stuff added in
one release is broken in the next. But if this had been the only
problem, I probably wouldn't have minded doing the merge three months
ago, even though we already wanted to release ASAP.
>
> So, the only real issue might be to pass the whole test suite after
> the merge. I will point this out again: three months ago *all* tests,
> doctests and documentation tests passed for most important
> configurations. Now they obviously won't (although Chris' branch may
> help here).
>
>
> btw. Going through recent commits I found this:
>
>
> https://github.com/sympy/sympy/commit/7a9c9b1144306245dd65d41f1e2883c760321594
>
>
> It seems that our review machinery doesn't work that good anyway ("A"
> isn't a very informative commit message, unless I miss a very
> important point here). I pointed this out just to show that sometimes
> we are very picky about commits and sometimes we push this kind of
> stuff (I'm referring only to commit message right now, not the commit
> it self). Maybe average of those two extremes would be a working
> approach? (i.e. don't scare developers or potential developers, but
> also don't allow to incorrect/misleading stuff to go in).
>
>
> Aaron Meurer
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>
>
> Mateusz
>
> --
> You received this message because you are subscribed to the Google
> Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy
Aaron S. Meurer
What is wrong with this? I though it was just expr.replace(old, new), where it uses .match() so that it is smart if it uses Wilds. Anyway, if you don't like something, you have to be specific about what is wrong with it.
> * Lambda.is_identity shouldn't be implemented (cf issue 2178)
> * .find() and .replace() need to be discussed. The proposed interface of
> the latter is too complex.
We agreed on this in an issue. If there are better ideas (I'm sure there are), why don't allow this to go in, and start from there?I don't think this will work. symbols('xyz') should create one symbol (Symbol('xyz')). Trying to deprecate this would just keep the bad interface problem there (see the discussion in issue 1977).
> * symbols('xyz') should be deprecated, but not removed outright (I don't
> think I ever mentioned that one before)
Now I'm confused. Was 0.7.0 supposed to be this great release where backwards incompatible changes to the API should have been made? I'm pretty sure this was the purpose of this release. Anyway, deprecating this and keeping old syntax is a very bad idea.
Is this actually used anywhere? If not, we could just hold out on it pretty easily. Or we could add it as a (currently unused) prototype.
> * exprtools adds an additional mess to a messy situation in Add and Mul
Actually it's a very important part of this branch and is used in together(), factor(), etc., to provide generalized and fast approach to manipulation of commutative expressions. This has nothing to do (directly) with Add and Mul, and if you don't understand this, please don't call this messy. I placed it in the core, because I'm sure this will be a significant part of the future core.Maybe this one is being picky. I don't care either way with it.
> * Most additions to sympy.utilities.iterables reimplement functions in
> itertools.
Exactly. Doesn't this work? It does, tests pass. Is it redundant? At least partially, but when implementing those functions I didn't have any clue about this. Does this interfere with the merge? I don't think so and if we merged this three months ago, this could have been easily refined before the release.So, the only real issue might be to pass the whole test suite after the merge. I will point this out again: three months ago *all* tests, doctests and documentation tests passed for most important configurations. Now they obviously won't (although Chris' branch may help here).btw. Going through recent commits I found this:It seems that our review machinery doesn't work that good anyway ("A" isn't a very informative commit message, unless I miss a very important point here). I pointed this out just to show that sometimes we are very picky about commits and sometimes we push this kind of stuff (I'm referring only to commit message right now, not the commit it self). Maybe average of those two extremes would be a working approach? (i.e. don't scare developers or potential developers, but also don't allow to incorrect/misleading stuff to go in).
Tim Lahey
>
> Regarding my branch, my plan was to not merge integration3 until I finished
> the algorithm, so that you could have a complete implementation of the
> transcendental algorithm in integrate(), but I now see that this is wrong.
> It is better to merge it in with the NotImplementedErrors and then improve
> it. That way, people will try it out. I am more hesitant to merge
> integration3 because I am constantly finding bugs in it. It needs to be
> tested more. N so much that it needs more tests, though this is true in some
> cases, but it just needs more people to try it out. But I now see that the
> best way to do this is to push it out to the official repo, where everyone
> will be using it.
> Unfortunately, integration3 is blocked pretty heavily on issue 2026 (exact
> or atomic substitution). I had to completely disable algebraic substitution
> in exp to make the preparser algorithm work, but this makes some limit tests
> break. There is no easy workaround, it just needs to be implemented.
Where can I find your branch? I have the work I started on doing an
integration test suite for Sage that I stopped when I stopped being
interested in it (because of certain changes). If I can find some
time, I can look at converting what I've done to Sympy and finishing
it. It's the Axiom test suite.
Cheers,
Tim.
--
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
http://about.me/tjlahey
Aaron S. Meurer
The function is risch_integrate() (integrate() is the same as in master; you can use it for comparison). If it returns an unevaluated Integral, it means that the integral has been proven to be non-elementary (it will raise NotImplementedError when it hasn't been implemented yet).
Only the transcendental algorithm for exponentials and logarithms has been implemented so far, so no algebraic integrands (like with square roots) or trigonometric integrands will work. This will probably reduce to about a tenth of your test suite.
By the way, in case you didn't know, the answer from any integration function is correct up to an arbitrary constant, so you shouldn't compare the output with some standard answer. Rather, to test for correctness, you should differentiate the result, subtract it from the original, and pass it to cancel() (cancel is sufficient for the simplifications involved here) and see if that goes to 0 (i.e., cancel(expr - risch_integrate(expr, x).diff(x))).
Also, any exception that is not NotImplementedError is a bug.
Aaron Meurer
Tim Lahey
>
> By the way, in case you didn't know, the answer from any integration function is correct up to an arbitrary constant, so you shouldn't compare the output with some standard answer. Rather, to test for correctness, you should differentiate the result, subtract it from the original, and pass it to cancel() (cancel is sufficient for the simplifications involved here) and see if that goes to 0 (i.e., cancel(expr - risch_integrate(expr, x).diff(x))).
I know. I've seen various ways that integrals are equivalent so I've
tested different ways. If one fails, I'll move on to the next one. So,
working with a standard answer is fine. Also, a standard answer allows
one to check themselves that the answer is correct since you could
display Sympy's answer and the standard one. It's also useful for
comparing timings across CAS.
Mateusz Paprocki
On 2 Apr., 03:03, Ronan Lamy <ronan.l...@gmail.com> wrote:This is easy I guess. Are you thinking of something like 'mylambda is
> * The RootOf constructor is too complicated (cf. issue 51 and other
> discussions I can't find ATM)
> * Lambda.is_identity shouldn't be implemented (cf issue 2178)
S.Identity'?
Maybe. I think polys could work without this. But to be honest I don't
> * .find() and .replace() need to be discussed. The proposed interface of
the latter is too complex.
see your point. Achieving replace()'s functionality in current sympy
is counter-intuitive IMHO.
I disagree. It has been deprecated for a very long time in the
> * symbols('xyz') should be deprecated, but not removed outright (I don't
> think I ever mentioned that one before)
docstring. There was no DeprecationWarning, this was maybe a mistake.
In any case, 0.7 is intended to break compatibility. So I'm +1 on
fixing this.
Please be specific.
> * exprtools adds an additional mess to a messy situation in Add and Mul
itertools depends AFAIK a lot on the specific version of Python, so
> * Most additions to sympy.utilities.iterables reimplement functions in
itertools.
I'm fine with this, especially if we still support Python 2.4. This
can be easily fixed later.
This was not intended, I think Aaron pushed the wrong branch by
Mateusz wrote:
> "A" isn't a very informative commit message
accident.
However, I would agree that code review nowadays is pickier than in
the past, looking at some code in sympy.
Please note that the p12 [1] branch has only one failing test (if you
> Do you expect that three months after
> last rebase it will still work out of the box with the most recent master?
merge my commit trivially fixing failures), so this is currently not
really an issue.
Let's summarize anything that needs to be done - as specific as
possible - and do it.
Vinzent
[1] https://github.com/sympy/sympy/pull/120
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Mateusz Paprocki
Though p12 might have some kinks to work out I think it's better to
get it in place so the things that are good can get exercised and
those that are not can get excised without causing a big headache. I
also believe it will be best to get this in before the GSoC gets to
work because every bit of work that interferes with p12 makes for more
work in doing the rebase.
I've already spent about 30 hours rebasing and going over commits and
feel pretty good about the integrity of p12 as a whole. Given Ondrej's
reminder that bisection can use the --skip option which results in a
range of commits being returned as the faulty range I am less stressed
about smoothing everything out in p12. Though tests will not all pass
in each commit, all commits allow `from sympy import *` to be
executed.
I'm heartily in favor of pushing this asap and am willing to help "get
it done" as Vinzent suggests.
Chris
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Mateusz Paprocki
Chris
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Mateusz Paprocki
I am becoming convinced that the slowness this is just the nature of the algorithm, because it produces candidate integrals that are very large even for relatively small integrands.
To me, there are three things that come to mind that should always be done right the first time (i.e., before any merge). The first is the user interface, since changing this in the future breaks backward compatibility, especially if there is a release in the meanwhile. The second thing is something that is not an issue in polys12, which is that no branch should be pushed in with a known wrong result. You have been really good at fixing any wrong result that I have reported (like when you worked on RootSum.diff), but have not
been so open on considering suggestions regarding the interface for already existing functions (like the RootOf issue).
The third thing is of course test failures, which have already been talked about here.Regarding my branch, my plan was to not merge integration3 until I finished the algorithm, so that you could have a complete implementation of the transcendental algorithm in integrate(), but I now see that this is wrong. It is better to merge it in with the NotImplementedErrors and then improve it. That way, people will try it out. I am more hesitant to merge integration3 because I am constantly finding bugs in it. It needs to be tested more. N so much that it needs more tests, though this is true in some cases, but it just needs more people to try it out. But I now see that the best way to do this is to push it out to the official repo, where everyone will be using it.
Unfortunately, integration3 is blocked pretty heavily on issue 2026 (exact or atomic substitution). I had to completely disable algebraic substitution in exp to make the preparser algorithm work, but this makes some limit tests break. There is no easy workaround, it just needs to be implemented.
I agree 100% here.What is wrong with this? I though it was just expr.replace(old, new), where it uses .match() so that it is smart if it uses Wilds. Anyway, if you don't like something, you have to be specific about what is wrong with it.
> * Lambda.is_identity shouldn't be implemented (cf issue 2178)
> * .find() and .replace() need to be discussed. The proposed interface of
> the latter is too complex.
We agreed on this in an issue. If there are better ideas (I'm sure there are), why don't allow this to go in, and start from there?I don't think this will work. symbols('xyz') should create one symbol (Symbol('xyz')). Trying to deprecate this would just keep the bad interface problem there (see the discussion in issue 1977).
> * symbols('xyz') should be deprecated, but not removed outright (I don't
> think I ever mentioned that one before)
Now I'm confused. Was 0.7.0 supposed to be this great release where backwards incompatible changes to the API should have been made? I'm pretty sure this was the purpose of this release. Anyway, deprecating this and keeping old syntax is a very bad idea.OK, so the "A" commit was my fault, and I take 100% blame for it. I basically forgot to do a "git fetch" before "git push" (he had fixed it in his branch, but I merged the wrong revision). So I think this is a bad example (because it was completely accidental).Is this actually used anywhere? If not, we could just hold out on it pretty easily. Or we could add it as a (currently unused) prototype.
> * exprtools adds an additional mess to a messy situation in Add and Mul
Actually it's a very important part of this branch and is used in together(), factor(), etc., to provide generalized and fast approach to manipulation of commutative expressions. This has nothing to do (directly) with Add and Mul, and if you don't understand this, please don't call this messy. I placed it in the core, because I'm sure this will be a significant part of the future core.Maybe this one is being picky. I don't care either way with it.
> * Most additions to sympy.utilities.iterables reimplement functions in
> itertools.
Exactly. Doesn't this work? It does, tests pass. Is it redundant? At least partially, but when implementing those functions I didn't have any clue about this. Does this interfere with the merge? I don't think so and if we merged this three months ago, this could have been easily refined before the release.So, the only real issue might be to pass the whole test suite after the merge. I will point this out again: three months ago *all* tests, doctests and documentation tests passed for most important configurations. Now they obviously won't (although Chris' branch may help here).btw. Going through recent commits I found this:It seems that our review machinery doesn't work that good anyway ("A" isn't a very informative commit message, unless I miss a very important point here). I pointed this out just to show that sometimes we are very picky about commits and sometimes we push this kind of stuff (I'm referring only to commit message right now, not the commit it self). Maybe average of those two extremes would be a working approach? (i.e. don't scare developers or potential developers, but also don't allow to incorrect/misleading stuff to go in).
But I do agree that we let things slide from time to time. For example, we often do not keep a commit from going in if it has some spacing errors (like a==b+c instead of a == b + c), especially for new contributors. But like I said above, the user level interface is important to get right the first time, and we do (or at least I do) block commits from going in if I see a problem there, even with the new contributors.There are only a few outstanding of these issues in polys12 (RootOf, Pure, Lambda). The remainder aren't as important, because they are internal (and it seems like you are constantly rewriting the internals anyway).
--Aaron Meurer--
Aaron Meurer
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
MateuszYou received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Ondrej Certik
> For better or for worse, SymPy has always been a place where patches
> that meet a minimum standard are pushed in. In the interest of not
> going 1.5 years between releases, I suggest we create issues for what
> needs to be done and push Mateusz's code.
Given the scope of Mateusz code and the improvements that it brings, I
also vote for pushing in Mateusz branch, in the best state that we
can, and improve upon it.
As to the release, I think we can release even without the merge, in
fact, I would highly recommend it. As the merge should be tested for
some time.
Ondrej
smichr
The XFAIL test still has to be added for the failing ode.
Brian Granger
I haven't followed this discussion too closely, but I think there is a
lesson to learn (which we all probably know already, but it is
relevant for the GSoC students). I am guilty as anyone on this, but
*large* branches that have many commits with complex and far reaching
changes are extremely difficult to review and merge, no matter how the
process in managed (I think sympy does a pretty good job of it...).
The solution is to not allow such branches in the first place. I know
this is completely counter to how we typically write code, but I think
it is the only real solution. Large efforts and their related
branches should be broken up into reasonably sized sub-tasks that can
be reviewed and merged on a shorter time scale. Saving it all up in
one big branch may seem easier at the time, but in the long run, it is
too painful for everyone and so much time passes, everyone has
forgotten many of the important details.
For students writing GSoC proposals, I *highly* recommend identifying
points during the summer where you will submit your code for review
and merging before continuing.
Cheers,
Brian
On Sat, Apr 2, 2011 at 8:52 PM, smichr <smi...@gmail.com> wrote:
> The additional commits in p12 have been cleaned up (and need review).
> The XFAIL test still has to be added for the failing ode.
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgra...@calpoly.edu and elli...@gmail.com
Mateusz Paprocki
Mateusz Paprocki
Hi,
I haven't followed this discussion too closely, but I think there is a
lesson to learn (which we all probably know already, but it is
relevant for the GSoC students). I am guilty as anyone on this, but
*large* branches that have many commits with complex and far reaching
changes are extremely difficult to review and merge, no matter how the
process in managed (I think sympy does a pretty good job of it...).
The solution is to not allow such branches in the first place. I know
this is completely counter to how we typically write code, but I think
it is the only real solution. Large efforts and their related
branches should be broken up into reasonably sized sub-tasks that can
be reviewed and merged on a shorter time scale. Saving it all up in
one big branch may seem easier at the time, but in the long run, it is
too painful for everyone and so much time passes, everyone has
forgotten many of the important details.
For students writing GSoC proposals, I *highly* recommend identifying
points during the summer where you will submit your code for review
and merging before continuing.
Cheers,
Brian
--
On Sat, Apr 2, 2011 at 8:52 PM, smichr <smi...@gmail.com> wrote:
> The additional commits in p12 have been cleaned up (and need review).
> The XFAIL test still has to be added for the failing ode.
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgra...@calpoly.edu and elli...@gmail.com
--
You received this message because you are subscribed to the Google Groups "sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Ondrej Certik
Well, last 2 weeks, you can also use this feature of github pull requests:
https://github.com/blog/821-mention-somebody-they-re-notified
to get the attention of a particular developer. Previously, you would
need to write an email, saying for example "Ondrej, please review
this, I need to get this in.". I don't think I got such an email (if I
did, I apologize).
In general, in my experience I would say that none of the sympy
developers wanted to "discuss things to death" (rather just provide
useful feedback), but for large branches like this one, it requires
quite a bit of work from the original author (e.g. you in this case)
to push the review forward. And it is not easy, we all know that. But
I think, given the feedback in this thread, that we all want to get
this in.
So if you would be ok to give us one last chance to get this in (so to
say:), I think that everybody will be very open to help get this in,
as I think everybody agrees we want all the features that you have
implemented.
Let us know if you have time to push this forward, or whether you
would like somebody else to do it. And then let's get it done.
Ondrej
Aaron S. Meurer
I am becoming convinced that the slowness this is just the nature of the algorithm, because it produces candidate integrals that are very large even for relatively small integrands.If I remember correctly this algorithm has exponential complexity in the number of "functional" components of an integrand and the degree of the candidate solution. The main reason why this algorithm is only a heuristic is that currently it is only possible to get an estimate of this degree. If we take a small degree, the algorithm runs fast but it may fail to find an antiderivate. We can take a higher degree and cover more classes of integrands, but in this case the algorithm will be very slow. Currently we use original Bronstein's algorithm for this, with some tiny improvements of my own based on empirical cases (those small improvements don't change the overall behaviour of the algorithm in general). I think we can't do much about purely algorithmic issues of heurisch() (at least not me), but on the implementation level, to improve speed of this algorithm, it would be great at least to have fast matrices, possibly implemented using similar approach I took in polys (I mean multiple level structure, etc.).
To me, there are three things that come to mind that should always be done right the first time (i.e., before any merge). The first is the user interface, since changing this in the future breaks backward compatibility, especially if there is a release in the meanwhile. The second thing is something that is not an issue in polys12, which is that no branch should be pushed in with a known wrong result. You have been really good at fixing any wrong result that I have reported (like when you worked on RootSum.diff), but have notImplementation of RootSum.diff (well RootSum itself) was a specific experience. A few years ago I discovered RootSum in Mathematica's documentation, but didn't have any idea how this work and how I could implement such a thing. When you pointed out that you need such functionality, I had already enough knowledge to figure this out and implement this. Moreover, it was great fun to work on this because at some point I realized that with new advancements in polys, we can go quite far with this, reaching almost Mathematica's level (not speaking here about speed, which isn't bad as for pure Python but could be better). After many tiring months of writing low-level code, this was finally a beautiful application of several things I implemented before (I like especially this example with exponential functions).
been so open on considering suggestions regarding the interface for already existing functions (like the RootOf issue).The issue with RootOf was that I had enough work to make it actually work and that's one of reasons I wasn't very supportive in discussions about the API. Another thing is that any such discussions have to account the fact that RootOf should be a result from roots() and solve(), which is not the case right now. The API is a little over complicated to provide a way to accommodate for this issue with roots() and solve(). So, if we want to improve RootOf we should also improve those two functions. I didn't want to do it on my own, because I think this is a big thing, because solve() is used in so many places in SymPy and it is not that trivial to fix as it was with symbols(). I don't say we can make of this two separate issues and solve them separately (at least as much as it can be done), but at least you should see that there was actually a reason.
The third thing is of course test failures, which have already been talked about here.Regarding my branch, my plan was to not merge integration3 until I finished the algorithm, so that you could have a complete implementation of the transcendental algorithm in integrate(), but I now see that this is wrong. It is better to merge it in with the NotImplementedErrors and then improve it. That way, people will try it out. I am more hesitant to merge integration3 because I am constantly finding bugs in it. It needs to be tested more. N so much that it needs more tests, though this is true in some cases, but it just needs more people to try it out. But I now see that the best way to do this is to push it out to the official repo, where everyone will be using it.It's great you see the point. The community support is one of reasons I left at some point the discrete/concrete stuff and moved integration, because there was almost no one to help me testing the former and the later have been used and tested as a side effect all the time. I hope that at some point I will finish what I started in sympy.concrete.There are two ways to proceed with risch_integrate(). Either use it in parallel with integrate() and advertise that there is another algorithm implemented, which is fast and can prove that antiderivatives exist, but not yet complete. Or, we can add try: risch_integrate() except NotImplementedError: (...) to integrate() and in (...) fall back to heurisch().
Unfortunately, integration3 is blocked pretty heavily on issue 2026 (exact or atomic substitution). I had to completely disable algebraic substitution in exp to make the preparser algorithm work, but this makes some limit tests break. There is no easy workaround, it just needs to be implemented.Any efforts regarding this will pay off, because Risch algorithm is one of landmarks of computer algebra, so having it (among other important algorithms) shows that we are serious, and it's just better than what we have now. However, I would not forget completely about heurisch(). I think that this algorithm (when improved) will serve together with risch_integrate(), at least until we will have a reasonable implementation of G-functions approach.
Aaron S. Meurer
Nice. I was thinking one of the biggest deficiencies to GitHub was the lack of a CC field.
Now I wonder if it is possible to automatically subscribe myself to all SymPy pull request comments, even if I do not participate in that pull request…
Aaron Meurer
>
> In general, in my experience I would say that none of the sympy
> developers wanted to "discuss things to death" (rather just provide
> useful feedback), but for large branches like this one, it requires
> quite a bit of work from the original author (e.g. you in this case)
> to push the review forward. And it is not easy, we all know that. But
> I think, given the feedback in this thread, that we all want to get
> this in.
>
> So if you would be ok to give us one last chance to get this in (so to
> say:), I think that everybody will be very open to help get this in,
> as I think everybody agrees we want all the features that you have
> implemented.
>
> Let us know if you have time to push this forward, or whether you
> would like somebody else to do it. And then let's get it done.
>
> Ondrej
>
Aaron S. Meurer
Hi,On 3 April 2011 06:58, Brian Granger <elli...@gmail.com> wrote:Hi,
I haven't followed this discussion too closely, but I think there is a
lesson to learn (which we all probably know already, but it is
relevant for the GSoC students). I am guilty as anyone on this, but
*large* branches that have many commits with complex and far reaching
changes are extremely difficult to review and merge, no matter how the
process in managed (I think sympy does a pretty good job of it...).
The solution is to not allow such branches in the first place. I know
this is completely counter to how we typically write code, but I think
it is the only real solution. Large efforts and their related
branches should be broken up into reasonably sized sub-tasks that can
be reviewed and merged on a shorter time scale. Saving it all up in
one big branch may seem easier at the time, but in the long run, it is
too painful for everyone and so much time passes, everyone has
forgotten many of the important details.
I think sometimes large branches are unavoidable, especially when you know what's the big goal (in this case it was making polynomials manipulation algorithms fast), but you don't know exactly how to achieve it at the very beginning and you figure out a solution when gradually fixing certain issues (i.e. implementing things, committing). I don't say that we shouldn't make any plans at all, actually we should plan as much as it is in our power. However, sometimes we make a breakthrough that opens many new possibilities that we wouldn't expect to have (for me one of such breakthroughs was implementation of Wang's algorithm (multivariate factorization), which allowed me to use polynomial factorization for practical purpose especially in simplification algorithms). Enthusiasm after such event can lead additional important work, so this social aspect shouldn't overlooked (actually is should be exploited).Another problem is that in our community certain issues require ages of discussion before any action is taken. Does it mean I have to stop development for that time, before an issue is resolved (especially if something is important to my work)? No, I implement stuff, taking into consideration what was already discussed. Advantage is that an implementation finally is available (possibly suboptimal) and can be used as a starting point for the final implementation.The most important thing, however, is that big branches are doable when the review process gradually follows development of a branch (this is my personal opinion). And this is how it worked with polys branch. There were two developers Aaron and Chris (lexicographic order) who reviewed this branch on regular basis and simply speaking made this branch better (I already pointed this out but it seems this is overlooked in this discussion). Forgive me if I forgot someone's else contribution. Where were other developers then? I don't want to make any accusations, I was enough happy that there was at least someone interested in my work and willing to help and I perfectly understand that SymPy is not our major concern, but school/work is (my self I can't count how many nights I spent working on SymPy). Also, there was an issue open for very long time specifically for the purpose of merging my work, where we discussed things that remained to be done, test failures, etc.
I think that the real issue is how to separate work is directly related to the problem you try to solve and what isn't that important and can be factored out to separate branches which can be developed/reviewed in parallel, but without loosing the momentum of your work. I have to admit that I failed to recognize this in a couple of places in my branch. A good example is the new syntax for symbols()/var() which could have been developed in another branch. On the other hand, the new syntax is so appealing that it was handy to have it when experimenting with polynomials in interactive sessions.
Brian Granger
I don't know enough about the state of your integration3 branch to
really know what is best in this situation. But, if parts of it are
complete, I don't think there is any harm in merging the completed
parts and going from there.
> Also, as I mentioned before, risch_integrate() cannot work without this hack
> (https://github.com/asmeurer/sympy/commit/62f3b670963ea2fc687120fadc808cb8dbc1c532)
> to exp._eval_subs, which breaks the limit code (this is the commit
> immediately before the one above in my branch). There are two ways I could
> have made this work to a mergable state. One would have been to implement
> atomic or exact substitution, something that would have taken away from my
> time working on integration, and is something that I feel that others who
> have worked more in subs (like Chris or Ronan) would do a better job of
> implementing. The other would have been to do a serious hack to the code to
> make that one case of substitution (exp) work in either case.
>
>
> I think sometimes large branches are unavoidable, especially when you know
> what's the big goal (in this case it was making polynomials manipulation
> algorithms fast), but you don't know exactly how to achieve it at the very
> beginning and you figure out a solution when gradually fixing certain issues
> (i.e. implementing things, committing). I don't say that we shouldn't make
> any plans at all, actually we should plan as much as it is in our power.
I agree that at times large branches are unavoidable. But for every
one that is unavoidable, there are numerous large branches that could
have been split into smaller pieces without much difficulty (I am not
just thinking of sympy here). With this in mind, I do think it is a
good idea to encourage GSoC students to plan on merging multiple times
during the summer, rather than waiting until the very end.
> However, sometimes we make a breakthrough that opens many new possibilities
> that we wouldn't expect to have (for me one of such breakthroughs was
> implementation of Wang's algorithm (multivariate factorization), which
> allowed me to use polynomial factorization for practical purpose especially
> in simplification algorithms). Enthusiasm after such event can lead
> additional important work, so this social aspect shouldn't overlooked
> (actually is should be exploited).
Yes.
> Another problem is that in our community certain issues require ages of
> discussion before any action is taken. Does it mean I have to stop
> development for that time, before an issue is resolved (especially if
> something is important to my work)? No, I implement stuff, taking into
> consideration what was already discussed. Advantage is that an
> implementation finally is available (possibly suboptimal) and can be used as
> a starting point for the final implementation.
I have struggled with this as well during review of the quantum stuff.
While I deeply appreciated the review comments, I had external
deadlines that I wasn't about to miss while the community discussed
things (even though those discussions were important as well).
> The most important thing, however, is that big branches are doable when the
> review process gradually follows development of a branch (this is my
> personal opinion).
+10
We use this approach with IPython and it *really* helps.
Ronan Lamy
> Basically, it is great to work on top of polys-n instead of master for
> my integration stuff, because I get the latest and greatest of the
> polys (and I don't duplicate any fixes that you make). But there
> needs to be a better way to manage us both making fixes to the polys
> in our dev branches.
Which is why I suggested to put the dev branch on the main repo. Once
it's there, it's frozen (no rebases) and everybody can work on it, send
pull requests, open issues against it, etc. It might force us to do a
lot of merges but that can't be worse than rebasing hundreds of commits
over and over again.
Aaron S. Meurer
How would this dev branch in the official repo thing work? Who would get branches there? Who can push to them? Does the review process change with any of this? And is it really better than me just sending a pull request to Mateusz (for example)?
Aaron Meurer
Ronan Lamy
> Well, I am convinced that large branches should be frozen anyway. The
> larger branches have too high of a chance of rebases screwing up
> commits so that they don't do what the did originally. That is why I
> have been exclusively merging integration3 since some point in the
> middle of last summer (and I wish I was more enlightened at the
> beginning of the summer).
>
> How would this dev branch in the official repo thing work? Who would
> get branches there? Who can push to them? Does the review process
> change with any of this? And is it really better than me just sending
> a pull request to Mateusz (for example)?
>
many of them - we don't want to have dozens of stale branches in the
official repo.
Pushing to them should be just like pushing to 'master': send a pull
request (to sympy:branch instead of sympy:master), get it reviewed. The
review criteria would be different, though not that much since every
commit in a dev branch is supposed to appear in master's tree in the
end.
As for it being better than sending a request to Mateusz, well, if you
had followed the latest discussions on GitHub, you would know that you
should really send it to Chris, except that Vinzent has the most recent
version so you could try with him, unless, of course, he has already
sent it back to Chris... I think it's easier to have a stable branch in
a stable location.
Ondrej Certik
My suggestion would be not to introduce any more "official" branches,
than the "master". It will create more confusion than benefits.
One should work hard to get the branch in, rather than keeping it
(indefinitely) alongside master. Github provides enough tools for
collaborating on such branches, e.g. sending pull requests to Mateusz,
or Chris, or the one who opened the latest pull request with the
branch.
Ondrej
Brian Granger
+1
> Ondrej
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
--
Vinzent Steinberg
anyone can access. Now, if you want to work on p12, you have to figure
out which version is the most recent. And more importantly, anyone can
push to it.
So you suggest we don't rebase p12 anymore?
Ondrej wrote:
> Github provides enough tools for
> collaborating on such branches, e.g. sending pull requests to Mateusz,
> or Chris, or the one who opened the latest pull request with the
> branch.
bottlenecks (only one person can push).
Vinzent