Re: [Python-Dev] [Python-checkins] cpython: Enhance Py_ARRAY_LENGTH(): fail at build time if the argument is not an array
On Thu, Sep 29, 2011 at 2:45 AM, Victor Stinner wrote: > I would like to suggest the opposite: move platform independdant macros from > pyport.h to pymacro.h :-) Suggestions: > - Py_ARITHMETIC_RIGHT_SHIFT > - Py_FORCE_EXPANSION > - Py_SAFE_DOWNCAST Not sure about the other two, but Py_ARITHMETIC_RIGHT_SHIFT is definitely platform dependent, which is why it's in pyport.h in the first place. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg tips
Am 29.09.2011 17:11, schrieb Barry Warsaw: > On Sep 29, 2011, at 12:07 PM, Victor Stinner wrote: > >> I disabled the merge GUI: I lose a lot of work because I'm unable to use a >> GUI to do merge, I don't understand what are the 3 versions of the same file >> (which one is the merged version!?) > > Emacs users should look at smerge-mode. It has some nice keybindings and > colorizing that usually makes resolving conflicts fairly straightforward. It > also will automatically `$vcs resolve` the file when you've handled all the > conflicts. > > Caveat: I use it primarily for bzr, but I think it works with most vcs's. Yes, this is what I do as well for hg. (I had to write the "hg resolve -m" support myself, but that was a year or two ago. I assume it's out-of-the-box now.) Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg tips
Am 29.09.2011 12:50, schrieb Victor Stinner: > Le 29/09/2011 12:34, Xavier Morel a écrit : >> Generally none. By default, mercurial (and most similar tools) sets up >> LOCAL, BASE and OTHER. BASE is the... > > Sorry, but I'm unable to remember the meaning of LOCAL, BASE and OTHER. > In meld, I have to scroll to the end of the filename so see the filename > suffix. Anyway, my real problem was different: hg opened meld with the 3 > versions, but the BASE was already merged. I mean that hg chose for me > what is the right version, without letting me choose myself what is the > good version, because if I just close meld, I lose my local changes. > > Because a merge is a new commit, I suppose that I can do something to > get my local changes back. But, well, I just prefer the "legacy" (?) > merge flavor: > > local > ... > === > ... > >>> other > > It's easier for my brain because I just have 2 versions of the same > code, not 3! I prefer this as well, since I also find most merge tools unbearable. (At some point I should probably learn emacs' ediff.) But in some cases, you really lose information when you don't see the base version, since in the case of contradicting changes it is very useful to see where both came from. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg tips
On Sep 29, 2011, at 12:07 PM, Victor Stinner wrote: > I disabled the merge GUI: I lose a lot of work because I'm unable to use a > GUI to do merge, I don't understand what are the 3 versions of the same file > (which one is the merged version!?) Emacs users should look at smerge-mode. It has some nice keybindings and colorizing that usually makes resolving conflicts fairly straightforward. It also will automatically `$vcs resolve` the file when you've handled all the conflicts. Caveat: I use it primarily for bzr, but I think it works with most vcs's. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Enhance Py_ARRAY_LENGTH(): fail at build time if the argument is not an array
On Wed, Sep 28, 2011 at 8:07 PM, Benjamin Peterson wrote: > 2011/9/28 victor.stinner : >> http://hg.python.org/cpython/rev/36fc514de7f0 >> changeset: 72512:36fc514de7f0 ... >> Thanks Rusty Russell for having written these amazing C macros! > Do we really need a new file? Why not pyport.h where other compiler stuff > goes? I would expect pyport to contain only system-specific macros. These seem more universal. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg tips
On 2011-09-29, at 12:50 , Victor Stinner wrote: > Le 29/09/2011 12:34, Xavier Morel a écrit : >> Generally none. By default, mercurial (and most similar tools) sets up >> LOCAL, BASE and OTHER. BASE is the... > > Sorry, but I'm unable to remember the meaning of LOCAL, BASE and OTHER. In > meld, I have to scroll to the end of the filename so see the filename suffix. > Anyway, my real problem was different: hg opened meld with the 3 versions, > but the BASE was already merged. I mean that hg chose for me what is the > right version, without letting me choose myself what is the good version, > because if I just close meld, I lose my local changes. I'd bet it's Meld doing that, though I have not checked (Araxis Merge does something similar, it has its own merge-algorithm which it tries to apply in case of 3-ways merge, trying to merge LOCAL and OTHER into base on its own). Look into Meld's configuration, it might be possible to disable that. (an other possibility would be that the wrong file pointers are send to Meld, so it gets e.g. twice the same file) > Because a merge is a new commit, I suppose that I can do something to get my > local changes back. But, well, I just prefer the "legacy" (?) merge flavor: > > local > ... > === > ... > >>> other > > It's easier for my brain because I just have 2 versions of the same code, not > 3! > > But it looks like some people are more confortable with 3 versions in a GUI, > because it is the default Mercurial behaviour (to open a GUI to solve > conflicts). > I'd be part of that camp, yes (though I'll use either depending on the exact situation, there are cases where seeing what both branches diverged from is very useful). I find having all three version makes it easier to correctly mix the two diverging versions, with /usr/bin/merge-style conflict markers it's harder to understand what both branches diverged from and hence how their changes fit into one another. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg tips
Victor Stinner wrote: > Because a merge is a new commit, I suppose that I can do something to > get my local changes back. But, well, I just prefer the "legacy" (?) > merge flavor: > > local > ... > === > ... > >>> other > > It's easier for my brain because I just have 2 versions of the same > code, not 3! I also prefer /usr/bin/merge and I've never quite figured out the GUI. Not that I spent a lot of time on it, since the "legacy" merge works well (and is self-explanatory). Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg tips
Le 29/09/2011 12:34, Xavier Morel a écrit : Generally none. By default, mercurial (and most similar tools) sets up LOCAL, BASE and OTHER. BASE is the... Sorry, but I'm unable to remember the meaning of LOCAL, BASE and OTHER. In meld, I have to scroll to the end of the filename so see the filename suffix. Anyway, my real problem was different: hg opened meld with the 3 versions, but the BASE was already merged. I mean that hg chose for me what is the right version, without letting me choose myself what is the good version, because if I just close meld, I lose my local changes. Because a merge is a new commit, I suppose that I can do something to get my local changes back. But, well, I just prefer the "legacy" (?) merge flavor: local ... === ... >>> other It's easier for my brain because I just have 2 versions of the same code, not 3! But it looks like some people are more confortable with 3 versions in a GUI, because it is the default Mercurial behaviour (to open a GUI to solve conflicts). Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg tips
On 2011-09-29, at 12:07 , Victor Stinner wrote: > > * I disabled the merge GUI: I lose a lot of work because I'm unable to use a > GUI to do merge, I don't understand what are the 3 versions of the same file > (which one is the merged version!?) Generally none. By default, mercurial (and most similar tools) sets up LOCAL, BASE and OTHER. BASE is the last "common" state, LOCAL is the locally modified file and OTHER is the remotely modified file (which you're trying to merge). The behavior after that depends, mercurial has an OUTPUT pointer (for the result file), many tools just write the non-postfixed file with the merge result. And depending on your precise tool it can attempt to perform its own merge resolution before showing you the files, or just show you the three files provided and you set up your changes into BASE from LOCAL and OTHER. If you reach that state, it's becaused mercurial could not automatically process the merge so there's no merged version to display. Maybe thinking of it as a file with conflict markers split into three (one without the conflicting sections, one with only the first part of the sections and one with only the second part) would make it clearer? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg tips
Le 29/09/2011 09:54, Ezio Melotti a écrit : Tip 1 -- merging heads: A while ago Éric suggested a nice tip to make merges easier and since I haven't seen many people using it and now I got a chance to use it again, I think it might be worth showing it once more: # so assume you just committed some changes: $ hg ci Doc/whatsnew/3.3.rst -m 'Update and reorganize the whatsnew entry for PEP 393.' # you push them, but someone else pushed something in the meanwhile, so the push fails $ hg push pushing to ssh://h...@hg.python.org/cpython searching for changes abort: push creates new remote heads on branch 'default'! (you should pull and merge or use push -f to force) # so you pull the other changes $ hg pull -u pulling from ssh://h...@hg.python.org/cpython searching for changes adding changesets adding manifests adding file changes added 4 changesets with 5 changes to 5 files (+1 heads) not updating, since new heads added (run 'hg heads' to see heads, 'hg merge' to merge) # and use "hg heads ." to see the two heads (yours and the one you pulled) in the current branch $ hg heads . changeset: 72521:e6a2b54c1d16 tag: tip user:Victor Stinner date:Thu Sep 29 04:02:13 2011 +0200 summary: Fix hex_digit_to_int() prototype: expect Py_UCS4, not Py_UNICODE changeset: 72517:ba6ee5cc9ed6 user:Ezio Melotti date:Thu Sep 29 08:34:36 2011 +0300 summary: Update and reorganize the whatsnew entry for PEP 393. # here comes the tip: before merging you switch to the other head (i.e. the one pushed by Victor), # if you don't switch, you'll be merging Victor changeset and in case of conflicts you will have to review # and modify his code (e.g. put a Misc/NEWS entry in the right section or something more complicated) $ hg up e6a2b54c1d16 6 files updated, 0 files merged, 0 files removed, 0 files unresolved # after the switch you will merge the changeset you just committed, so in case of conflicts # reviewing and merging is much easier because you know the changes already $ hg merge 1 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) # here everything went fine and there were no conflicts, and in the diff I can see my last changeset $ hg di diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst [...] # everything looks fine, so I can commit the merge and push $ hg ci -m 'Merge heads.' $ hg push pushing to ssh://h...@hg.python.org/cpython searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 1 changes to 1 files remote: buildbot: 2 changes sent successfully remote: notified python-check...@python.org of incoming changeset ba6ee5cc9ed6 remote: notified python-check...@python.org of incoming changeset e7672fe3cd35 This tip is not only useful while merging, but it's also useful for python-checkins reviews, because the "merge" mail has the same diff of the previous mail rather than having 15 unrelated changesets from the last week because the committer didn't pull in a while. I prefer "hg pull --rebase && hg push": it's just one command (ok, two), there is nothing to do (it's fast)... if the new changes are not in conflict with my local changes, and it keeps a nice linear history. hg rebase is more dangerous: you may lose work if you misuse it. hg rebase is maybe more complex when you have a conflict (I don't really know, I never use hg merge). hg rebase doesn't work at all if you have local changes in different branches. If hg push fails, I prefer to *remove* my changes using hg strip (!), update and redo the commits on the new tip. I should sometimes fix hg rebase instead :-) Tip 2 -- extended diffs: If you haven't already, enable git diffs, adding to your ~/.hgrc the following two lines: [diff] git = True (this is already in the devguide, even if 'git = on' is used there. The mercurial website uses git = True too.) More info: http://hgtip.com/tips/beginner/2009-10-22-always-use-git-diffs/ For diff, "showfunc = on" is also a cool feature. See my full ~/.hgrc: https://bitbucket.org/haypo/misc/src/tip/conf/hgrc * I disabled the merge GUI: I lose a lot of work because I'm unable to use a GUI to do merge, I don't understand what are the 3 versions of the same file (which one is the merged version!?) * pager extension is just a must have * hgeditor is also a must have to write the changelog: in vim, it opens a second buffer with the diff I also use "hg record" (like "git add -i") to do partial commit: after hacking during 3 hours, I do atomic commits. Then I use hg histedit (like "git rebase -i") to merge and reorganize local commits. It's useful to hide "oops, typo in my last commit". If you find operations like pulling, updating or cloning too slow, you might also want to look at the 'progress' extension, which displays a progress bar during these operations: [extensions] progress = Yeah, I like it too :-) Vi
[Python-Dev] Hg tips (was Re: [Python-checkins] cpython (merge default -> default): Merge heads.)
Tip 1 -- merging heads: A while ago Éric suggested a nice tip to make merges easier and since I haven't seen many people using it and now I got a chance to use it again, I think it might be worth showing it once more: # so assume you just committed some changes: $ hg ci Doc/whatsnew/3.3.rst -m 'Update and reorganize the whatsnew entry for PEP 393.' # you push them, but someone else pushed something in the meanwhile, so the push fails $ hg push pushing to ssh://h...@hg.python.org/cpython searching for changes abort: push creates new remote heads on branch 'default'! (you should pull and merge or use push -f to force) # so you pull the other changes $ hg pull -u pulling from ssh://h...@hg.python.org/cpython searching for changes adding changesets adding manifests adding file changes added 4 changesets with 5 changes to 5 files (+1 heads) not updating, since new heads added (run 'hg heads' to see heads, 'hg merge' to merge) # and use "hg heads ." to see the two heads (yours and the one you pulled) in the current branch $ hg heads . changeset: 72521:e6a2b54c1d16 tag: tip user:Victor Stinner date:Thu Sep 29 04:02:13 2011 +0200 summary: Fix hex_digit_to_int() prototype: expect Py_UCS4, not Py_UNICODE changeset: 72517:ba6ee5cc9ed6 user:Ezio Melotti date:Thu Sep 29 08:34:36 2011 +0300 summary: Update and reorganize the whatsnew entry for PEP 393. # here comes the tip: before merging you switch to the other head (i.e. the one pushed by Victor), # if you don't switch, you'll be merging Victor changeset and in case of conflicts you will have to review # and modify his code (e.g. put a Misc/NEWS entry in the right section or something more complicated) $ hg up e6a2b54c1d16 6 files updated, 0 files merged, 0 files removed, 0 files unresolved # after the switch you will merge the changeset you just committed, so in case of conflicts # reviewing and merging is much easier because you know the changes already $ hg merge 1 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) # here everything went fine and there were no conflicts, and in the diff I can see my last changeset $ hg di diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst [...] # everything looks fine, so I can commit the merge and push $ hg ci -m 'Merge heads.' $ hg push pushing to ssh://h...@hg.python.org/cpython searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 2 changesets with 1 changes to 1 files remote: buildbot: 2 changes sent successfully remote: notified python-check...@python.org of incoming changeset ba6ee5cc9ed6 remote: notified python-check...@python.org of incoming changeset e7672fe3cd35 This tip is not only useful while merging, but it's also useful for python-checkins reviews, because the "merge" mail has the same diff of the previous mail rather than having 15 unrelated changesets from the last week because the committer didn't pull in a while. Tip 2 -- extended diffs: If you haven't already, enable git diffs, adding to your ~/.hgrc the following two lines: > [diff] > git = True > (this is already in the devguide, even if 'git = on' is used there. The mercurial website uses git = True too.) More info: http://hgtip.com/tips/beginner/2009-10-22-always-use-git-diffs/ Tip 3 -- extensions: I personally like the 'color' extension, it makes the output of commands like 'hg diff' and 'hg stat' more readable (e.g. it shows removed lines in red and added ones in green). If you want to give it a try, add to your ~/.hgrc the following two lines: > [extensions] > color = > If you find operations like pulling, updating or cloning too slow, you might also want to look at the 'progress' extension, which displays a progress bar during these operations: > [extensions] > progress = > Tip 4 -- porting from 2.7 to 3.2: The devguide suggests: > > hg export a7df1a869e4a | hg import --no-commit - > but it's not always necessary to copy the changeset number manually. If you are porting your last commit you can just use 'hg export 2.7' (or any other branch name): * using the one-dir-per-branch setup: wolf@hp:~/dev/py/2.7$ hg ci -m 'Fix some bug.' wolf@hp:~/dev/py/2.7$ cd ../3.2 wolf@hp:~/dev/py/3.2$ hg pull -u ../2.7 wolf@hp:~/dev/py/3.2$ hg export 2.7 | hg import --no-commit - * using the single-dir setup: wolf@hp:~/dev/python$ hg branch 2.7 wolf@hp:~/dev/python$ hg ci -m 'Fix some bug.' wolf@hp:~/dev/python$ hg up 3.2 # here you might enjoy the progress extension wolf@hp:~/dev/python$ hg export 2.7 | hg import --no-commit - And then you can check that everything is fine, and commit on 3.2 too. Of course it works the other way around (from 3.2 to 2.7) too. I hope you'll find these tips useful. Best Regards, Ezio Melotti On Thu, Sep 29, 2011 at 8:36 AM, ezio.melotti wrote: > http://hg.python.org/cpython/rev/e7672fe3cd35 > changeset: 72522:e7672fe3cd35
