Issue2146

classification
Title: Optimize xrange iterator
Type: behaviour Severity: normal
Components: Core Versions: Jython 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: santa4nt, zyasoft
Priority: Keywords: patch

Created on 2014-05-16.00:08:05 by santa4nt, last changed 2014-07-01.04:04:47 by zyasoft.

Files
File name Uploaded Description Edit Remove
optimize_xrange_iter.diff santa4nt, 2014-05-16.00:08:04
unnamed santa4nt, 2014-06-23.15:47:08
Messages
msg8415 (view) Author: Santoso Wijaya (santa4nt) Date: 2014-05-16.00:08:04
This patch is to bring xrange's iterator to par with CPython's implementation and to pass a previously failing test in lib-python/2.7/test/test_enumerate.py re: xrange iterator.
msg8417 (view) Author: Jim Baker (zyasoft) Date: 2014-05-16.13:57:51
Will review for beta 4
msg8783 (view) Author: Jim Baker (zyasoft) Date: 2014-06-22.06:05:01
Fixed as of http://hg.python.org/jython/rev/33ab610967ec
msg8785 (view) Author: Santoso Wijaya (santa4nt) Date: 2014-06-22.17:11:29
@zyasoft You forgot to also merge/check in `PyXRangeIter.java` here. Won't compile without it.
msg8787 (view) Author: Jim Baker (zyasoft) Date: 2014-06-22.19:24:37
Just pushed the missing file.

I am not able to extract out usable changesets due to how the history in your santa4nt fork is interacting with what is hg.python.org/jython

You may want to switch to a feature fork process so we can merge Mercurial changesets instead of diffs. Changesets do have the advantage they retain changes to file layout, such as adding/removing files, so at least we wouldn't see this missing file in a commit issue.

Such forks are much more heavyweight, but they seem to work. If you do switch to this process, do not use a named branch/bookmark in such forks, this will cause issues at merge into hg.python.org/jython, and perhaps even more opportunities for painful merging, something I saw when I tried to merge my socket-reboot fork (although I know how to fix this issue if it comes up) ;)
msg8791 (view) Author: Santoso Wijaya (santa4nt) Date: 2014-06-23.01:39:37
@zyasoft, so, just nameless heads?
msg8792 (view) Author: Santoso Wijaya (santa4nt) Date: 2014-06-23.02:10:30
@zyasoft Oh, are you saying I should fork a clone for each fix/feature I'm  issuing a PR for?
msg8795 (view) Author: Jim Baker (zyasoft) Date: 2014-06-23.15:40:44
That would be easier to work with on my end, but just marginally so. It's up to you -  a missing committed file is rare and easy to spot with any level of testing. However, it should mean we could merge in the changesets of the PRs, and bitbucket should be able to detect this and mark the PR as merged. Should. I have seen bitbucket in fact not do this. But after all, https://bitbucket.org/jython/jython is a mirror, so that it even sort of works is perhaps the real thing we should appreciate! ;)

The lack of any CI on PRs is a bigger issue; that we are running PRs on bitbucket means it requires more integration work.

I think we need to revisit this whole process post 2.7.0, possibly using github and travis CI to frontend hg.python.org/jython, given that it's just a final push anyway and we are not using any of the branch support at hg.python.org other than for 2.7 vs 2.5 - it's just too heavyweight/error prone. Even better workflows as seen in OpenStack would be fantastic.

CPython is looking at a completely revamped workflow, but it's very early in the planning process: https://mail.python.org/pipermail/core-workflow/
msg8796 (view) Author: Santoso Wijaya (santa4nt) Date: 2014-06-23.15:47:09
I see. I'm not privy to how pull requests are handled on that side. I was
under the impression that Bitbucket could detect __only__ the changes
between the head of https://bitbucket.org/jython/jython and the head of
whatever branch I sent a pull request for, as I took care that said branch
is always isolated to the feature/issue at hand. The bookmarks are there
for me to keep track of different heads in one repo, but they are all their
own feature "branches" per se.

~/santoso

On Mon, Jun 23, 2014 at 8:40 AM, Jim Baker <report@bugs.jython.org> wrote:

>
> Jim Baker added the comment:
>
> That would be easier to work with on my end, but just marginally so. It's
> up to you -  a missing committed file is rare and easy to spot with any
> level of testing. However, it should mean we could merge in the changesets
> of the PRs, and bitbucket should be able to detect this and mark the PR as
> merged. Should. I have seen bitbucket in fact not do this. But after all,
> https://bitbucket.org/jython/jython is a mirror, so that it even sort of
> works is perhaps the real thing we should appreciate! ;)
>
> The lack of any CI on PRs is a bigger issue; that we are running PRs on
> bitbucket means it requires more integration work.
>
> I think we need to revisit this whole process post 2.7.0, possibly using
> github and travis CI to frontend hg.python.org/jython, given that it's
> just a final push anyway and we are not using any of the branch support at
> hg.python.org other than for 2.7 vs 2.5 - it's just too heavyweight/error
> prone. Even better workflows as seen in OpenStack would be fantastic.
>
> CPython is looking at a completely revamped workflow, but it's very early
> in the planning process: https://mail.python.org/pipermail/core-workflow/
>
> _______________________________________
> Jython tracker <report@bugs.jython.org>
> <http://bugs.jython.org/issue2146>
> _______________________________________
>
msg8797 (view) Author: Santoso Wijaya (santa4nt) Date: 2014-06-23.15:47:29
I see. I'm not privy to how pull requests are handled on that side. I was under the impression that Bitbucket could detect __only__ the changes between the head of https://bitbucket.org/jython/jython and the head of whatever branch I sent a pull request for, as I took care that said branch is always isolated to the feature/issue at hand. The bookmarks are there for me to keep track of different heads in one repo, but they are all their own feature "branches" per se.
msg8798 (view) Author: Santoso Wijaya (santa4nt) Date: 2014-06-23.15:47:55
Oops, doublepost.
msg8800 (view) Author: Jim Baker (zyasoft) Date: 2014-06-23.16:12:16
Feel free to choose the method of your choice, but this is just the limitation I have identified with our bitbucket setup.

At the end of the day, I have found this API to be sufficiently robust to get the necessary diff, regardless of how the PR has been built:
https://bitbucket.org/api/2.0/repositories/jython/jython/pullrequests/38/diff

Simply vary the PR number as necessary
History
Date User Action Args
2014-07-01 04:04:47zyasoftsetstatus: pending -> closed
2014-06-23 16:12:16zyasoftsetmessages: + msg8800
2014-06-23 15:47:55santa4ntsetmessages: + msg8798
2014-06-23 15:47:29santa4ntsetmessages: + msg8797
2014-06-23 15:47:09santa4ntsetfiles: + unnamed
messages: + msg8796
2014-06-23 15:40:45zyasoftsetmessages: + msg8795
2014-06-23 02:10:30santa4ntsetmessages: + msg8792
2014-06-23 01:39:37santa4ntsetmessages: + msg8791
2014-06-22 19:24:37zyasoftsetmessages: + msg8787
2014-06-22 17:11:29santa4ntsetmessages: + msg8785
2014-06-22 06:05:01zyasoftsetstatus: open -> pending
resolution: remind -> fixed
messages: + msg8783
2014-05-16 13:57:51zyasoftsetnosy: + zyasoft
resolution: remind
messages: + msg8417
2014-05-16 00:08:05santa4ntcreate