Re: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers.
Am 07.02.2011 00:21, schrieb Nick Coghlan: > On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote: >> I would rather not have new hg users have to install an extension just >> to get a simple workflow going. > > I may still keep my Rdiff-based FAQ entry around as an example of how > to get a collapsed diff regardless of personal workflow, though. > > Installing Rdiff was actually pretty easy, and I get the impression > that becoming comfortable with adding the extensions that suit your > personal workflow is a key part in getting Mercurial to really work > for you. We won't do people any favours if we try to pretend that > isn't the case. This is quite true. (And after a while, the same goes for creating your own extensions, BTW.) 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] devguide: Basic instructions on how to generate a patch with hg for non-committers.
Am 06.02.2011 21:13, schrieb Brett Cannon: >>> To undo a patch, you can revert **all** changes made in your checkout:: >>> >>> -svn revert -R . >>> +hg revert --all >>> + >> >> Or "hg revert -a", which is nicer to type. > > I prefer being explicit over implicit in the tutorial. BTW, the exact equivalent of "svn revert -R ." is "hg revert ."; the two differ if you're not in the working dir root. However, considering the preceding text, the SVN command was faulty in the first place. 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] devguide: Basic instructions on how to generate a patch with hg for non-committers.
On 07/02/2011 12:25, Georg Brandl wrote: Am 07.02.2011 00:21, schrieb Nick Coghlan: On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote: I would rather not have new hg users have to install an extension just to get a simple workflow going. I may still keep my Rdiff-based FAQ entry around as an example of how to get a collapsed diff regardless of personal workflow, though. Installing Rdiff was actually pretty easy, and I get the impression that becoming comfortable with adding the extensions that suit your personal workflow is a key part in getting Mercurial to really work for you. We won't do people any favours if we try to pretend that isn't the case. This is quite true. (And after a while, the same goes for creating your own extensions, BTW.) And from the description it sounds like rdiff will be very useful for our usecase. Michael 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] devguide: Basic instructions on how to generate a patch with hg for non-committers.
On Mon, 07 Feb 2011 13:26:28 +0100 Georg Brandl wrote: > Am 06.02.2011 21:13, schrieb Brett Cannon: > > >>> To undo a patch, you can revert **all** changes made in your checkout:: > >>> > >>> -svn revert -R . > >>> +hg revert --all > >>> + > >> > >> Or "hg revert -a", which is nicer to type. > > > > I prefer being explicit over implicit in the tutorial. > > BTW, the exact equivalent of "svn revert -R ." is "hg revert ."; the two > differ if you're not in the working dir root. Using hg commands from somewhere else that the dir root is too confusing. Sometimes they display WC-relative paths, sometimes they display current dir-relative paths. I would not recommend it. Regards Antoine. ___ 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] devguide: Basic instructions on how to generate a patch with hg for non-committers.
On Mon, 07 Feb 2011 13:27:31 + Michael Foord wrote: > On 07/02/2011 12:25, Georg Brandl wrote: > > Am 07.02.2011 00:21, schrieb Nick Coghlan: > >> On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote: > >>> I would rather not have new hg users have to install an extension just > >>> to get a simple workflow going. > >> I may still keep my Rdiff-based FAQ entry around as an example of how > >> to get a collapsed diff regardless of personal workflow, though. > >> > >> Installing Rdiff was actually pretty easy, and I get the impression > >> that becoming comfortable with adding the extensions that suit your > >> personal workflow is a key part in getting Mercurial to really work > >> for you. We won't do people any favours if we try to pretend that > >> isn't the case. > > This is quite true. (And after a while, the same goes for creating your > > own extensions, BTW.) > > > > And from the description it sounds like rdiff will be very useful for > our usecase. I'm not sure it is really. When you commit multiple changesets locally you really want to use something like named branches or mq to track them. Advocating rdiff is advocating something SVN-like, it's not very helpful IMO. Regards Antoine. ___ 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] devguide: Basic instructions on how to generate a patch with hg for non-committers.
On 07/02/2011 14:28, Antoine Pitrou wrote: On Mon, 07 Feb 2011 13:27:31 + Michael Foord wrote: On 07/02/2011 12:25, Georg Brandl wrote: Am 07.02.2011 00:21, schrieb Nick Coghlan: On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote: I would rather not have new hg users have to install an extension just to get a simple workflow going. I may still keep my Rdiff-based FAQ entry around as an example of how to get a collapsed diff regardless of personal workflow, though. Installing Rdiff was actually pretty easy, and I get the impression that becoming comfortable with adding the extensions that suit your personal workflow is a key part in getting Mercurial to really work for you. We won't do people any favours if we try to pretend that isn't the case. This is quite true. (And after a while, the same goes for creating your own extensions, BTW.) And from the description it sounds like rdiff will be very useful for our usecase. I'm not sure it is really. When you commit multiple changesets locally you really want to use something like named branches or mq to track them. Advocating rdiff is advocating something SVN-like, it's not very helpful IMO. Although often you want to merge in a single commit and erase the commit history of the branch you worked in (as discussed previously). So are you advocating rebasing before merge as the alternative? Michael Regards Antoine. ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] devguide: Basic instructions on how to generate a patch with hg for non-committers.
On Mon, 07 Feb 2011 14:34:35 + Michael Foord wrote: > >>> > >> And from the description it sounds like rdiff will be very useful for > >> our usecase. > > I'm not sure it is really. When you commit multiple changesets > > locally you really want to use something like named branches or mq to > > track them. Advocating rdiff is advocating something SVN-like, it's not > > very helpful IMO. > > > > Although often you want to merge in a single commit and erase the commit > history of the branch you worked in (as discussed previously). Yes, but apparently rdiff compares the *working copy* rather than the local repository. Also, AFAIU rdiff will compare against the tip of the remote, which is probably not what you based your work on. And if you have to specify revisions by hand, it kind of defeats the point (you want hg to track changes by itself, which is why you want to use one of named branches / bookmarks / mq / etc.). > So are > you advocating rebasing before merge as the alternative? I'm not advocating anything in particular really. I think creating a named branch "foo" (or a bookmark? I've never used them but it sounds like they might do the trick) and then using "hg di -r py3k" to get the diff against upstream is very reasonable. That's without any hg extension activated. Throwaway clones are good too, since they avoid the issues with "rebasing" or "erasing commit history". But if we suggest people use some extension, I'd rather see us advocate mq (or shelve or any equivalent) rather than something low-level such as rdiff. Regards Antoine. ___ 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] devguide: Basic instructions on how to generate a patch with hg for non-committers.
On Mon, Feb 7, 2011 at 15:46, Antoine Pitrou wrote: > I'm not advocating anything in particular really. I think creating a > named branch "foo" (or a bookmark? I've never used them but it sounds > like they might do the trick) and then using "hg di -r py3k" to get the > diff against upstream is very reasonable. That's without any hg > extension activated. Yeah, I don't think we need rdiff. IIRC it isn't really maintained, either, just the basics to keep it working with new versions of hg. Cheers, Dirkjan ___ 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] devguide: Basic instructions on how to generate a patch with hg for non-committers.
On Monday, 07 February 2011 at 15:46, Antoine Pitrou wrote: > On Mon, 07 Feb 2011 14:34:35 + > Michael Foord wrote: > > >>> > > >> And from the description it sounds like rdiff will be very useful for > > >> our usecase. > > > I'm not sure it is really. When you commit multiple changesets > > > locally you really want to use something like named branches or mq to > > > track them. Advocating rdiff is advocating something SVN-like, it's not > > > very helpful IMO. > > > > > > > Although often you want to merge in a single commit and erase the commit > > history of the branch you worked in (as discussed previously). > > Yes, but apparently rdiff compares the *working copy* rather than the > local repository. Also, AFAIU rdiff will compare against the tip of the Rdiff is meant to make diff work against remote repositories the way it already does on local ones. So it *can* produce a diff between the working directory and a remote revision, just as regular diff can do for a local revision. But it can also produce diffs between any local revision and any remote revision. > remote, which is probably not what you based your work on. And if you If you're talking about named branches, I think I agree (rdiff predates a lot of the work done in hg to support named branches). I assume you think the right target is the most recent remote revision on the named branch you're working against? (rdiff does accept symbolic names for remote revisions, including branch names) > have to specify revisions by hand, it kind of defeats the point (you > want hg to track changes by itself, which is why you want to use one > of named branches / bookmarks / mq / etc.). rdiff is somewhat orthogonal to bookmarks/mq/etc. It's really just a convenient wrapper for outgoing. ___ 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] Finally fix installer to add Python to %PATH% on Windows
Chris Withers wrote: On 06/02/2011 15:25, Brian Curtin wrote: So put the new path before the old path, or replace it? The current patch appends to the end. I believe the last path wins in Windows land, so that would be fine. Actually, first one wins, as Windows starts at the beginning and stops looking once it finds a match. ~Ethan~ ___ 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
[Python-Dev] Python Unit Tests
Hi all, I starting to explore python 3k core development environment. So, sorry in advance for any mistakes, but I really don't know what is the best list to post this, since it not a "use of python" issue, and probably is not a dev issue, it is more like a "dev env" question. I have ran the test suit, and got the messages below. ~/python_dev/python$ make testall ./python -Wd -E -bb ./Lib/test/regrtest.py -uall -l == CPython 3.2rc2+ (py3k:88376, Feb 7 2011, 18:31:28) [GCC 4.4.5] == Linux-2.6.35-24-generic-x86_64-with-debian-squeeze-sid little-endian == /home/wesley/python_dev/python/build/test_python_3387 Testing with flags: sys.flags(debug=0, division_warning=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=2, quiet=0) [...] [198/349] test_ossaudiodev test_ossaudiodev skipped -- [Errno 2] No such file or directory: '/dev/dsp' [...] [200/349] test_parser Expecting 's_push: parser stack overflow' in next line s_push: parser stack overflow [...] [321/349] test_urllib2net /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed self._sock = None /home/wesley/python_dev/python/Lib/urllib/request.py:2134: ResourceWarning: unclosed sys.exc_info()[2]) /home/wesley/python_dev/python/Lib/urllib/request.py:2134: ResourceWarning: unclosed sys.exc_info()[2]) /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed self._sock = None /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed self._sock = None /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed self._sock = None /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed self._sock = None [323/349] test_urllibnet /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed self._sock = None 24 tests skipped: test_bz2 test_curses test_dbm_gnu test_dbm_ndbm test_gdb test_kqueue test_ossaudiodev test_readline test_smtpnet test_socketserver test_sqlite test_ssl test_startfile test_tcl test_timeout test_tk test_ttk_guionly test_ttk_textonly test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 9 skips unexpected on linux2: test_bz2 test_dbm_gnu test_dbm_ndbm test_readline test_ssl test_tcl test_tk test_ttk_guionly test_ttk_textonly sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='a' encoding='UTF-8'> But running each of them individually: :~/python_dev/python$ ./python Lib/test/regrtest.py test_ossaudiodev [1/1] test_ossaudiodev test_ossaudiodev skipped -- Use of the `audio' resource not enabled 1 test skipped: test_ossaudiodev Those skips are all expected on linux2. ./python Lib/test/regrtest.py test_parser [1/1] test_parser Expecting 's_push: parser stack overflow' in next line s_push: parser stack overflow 1 test OK. ./python Lib/test/regrtest.py test_urllib2net[1/1] test_urllib2net test_urllib2net skipped -- Use of the `network' resource not enabled 1 test skipped: test_urllib2net Those skips are all expected on linux2. Is there any reason for the different results? Regards, Wesley -- Wesley Mesquita Computer Engineer http://www.wesleymesquita.com Mobile: +55 11 95249272 ___ 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 Unit Tests
On Mon, 07 Feb 2011 20:38:28 -0200, Wesley Mesquita wrote: > [198/349] test_ossaudiodev > test_ossaudiodev skipped -- [Errno 2] No such file or directory: '/dev/dsp' This is normal since you don't have a /dev/dsp. That's what the skip message means. > [200/349] test_parser > Expecting 's_push: parser stack overflow' in next line > s_push: parser stack overflow "Expecting" means the next message is expected. Someone should probably check to see if this test can (in Python3) be rewritten so that message isn't generated, but for now it is Expected and completely normal. > [321/349] test_urllib2net > /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed > > self._sock = None There are some ResourceWarnings we haven't cured yet (the ResourceWarning is a fairly new innovation). I'm not sure why they don't show up when you run the tests individually. > 9 skips unexpected on linux2: > test_bz2 test_dbm_gnu test_dbm_ndbm test_readline test_ssl > test_tcl test_tk test_ttk_guionly test_ttk_textonly These would be because you don't have the correct system/development libraries installed for bz2, gnudbm, ndbm, readline, openssl, tcl, and tk when you compiled your Python. So, these skips are actually expected if you don't have those libraries, but if you want a complete development/test environment you should install the necessary packages and recompile. I imagine at least some of this is already covered in the dev guide (I haven't made time to review it yet). If any of it is unclear to you, please provide feedback so we can improve the guide (which is new). -- R. David Murray www.bitdance.com ___ 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
