Re: [Python-Dev] PEP 385: Formatting of Hg checkin notifications
On Mon, Nov 15, 2010 at 4:27 AM, Martin v. Löwis mar...@v.loewis.de wrote: I suspect my hg-fu is inadequate to at this point - I get an 'access to repository hg.python.org/hooks not permitted' error when I try to push the modified file to ssh://h...@hg.python.org/hooks. Try ssh://h...@hg.python.org/repos/hooks And done :) Hopefully I didn't break anything in the process... Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] r86467 - in python/branches/py3k: Doc/library/logging.rst Lib/logging/__init__.py Misc/NEWS
On Mon, Nov 15, 2010 at 7:33 AM, vinay.sajip python-check...@python.org wrote: + .. attribute:: stack_info + + Stack frame information (where available) from the bottom of the stack + in the current thread, up to and including the stack frame of the + logging call which resulted in the creation of this record. + Interesting - my mental model of the call stack is that the outermost frame is the top of the stack and the stack grows downwards as calls are executed (there are a few idioms like recursive descent, the intuitive parallel with inner functions being lower in the stack than outer functions as well as the order in which Python prints stack traces that reinforce this view). According to the sys.getframe documentation, my mental model is wrong though :) (I'll note that the documentation of frame objects in the language reference itself appears a little confused on the matter - either that or I'm completely misunderstanding when writing to f_lineno will work) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] r86467 - in python/branches/py3k: Doc/library/logging.rst Lib/logging/__init__.py Misc/NEWS
On Mon, Nov 15, 2010 at 8:24 AM, Nick Coghlan ncogh...@gmail.com wrote: On Mon, Nov 15, 2010 at 7:33 AM, vinay.sajip python-check...@python.org wrote: + .. attribute:: stack_info + + Stack frame information (where available) from the bottom of the stack + in the current thread, up to and including the stack frame of the + logging call which resulted in the creation of this record. + Interesting - my mental model of the call stack is that the outermost frame is the top of the stack and the stack grows downwards as calls are executed (there are a few idioms like recursive descent, the intuitive parallel with inner functions being lower in the stack than outer functions as well as the order in which Python prints stack traces that reinforce this view). Probably because the C stack tends to grow down for most architectures, but most stack data structures are implemented over arrays and hence, grow upwards from 0. Depending on the author's background, they probably use one mental model or the other. Reid ___ 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] PEP 385: Formatting of Hg checkin notifications
On Sun, Nov 14, 2010 at 5:10 AM, Terry Reedy tjre...@udel.edu wrote: On 11/13/2010 8:28 PM, Nick Coghlan wrote: Following the python-checkins list, I get to see both the current SVN notifications and the Hg notifications from Tarek's pushes into the distutils repository. I realised today that there is one key reason as to why the latter strikes me as a big wall of unintelligible text, while I find the SVN notification quite easy to read: vertical whitespace. The SVN notification uses vertical whitespace to separate out the log message and the list of files affected clearly from the rest of the header fields. It makes it *really* easy to see at a glance what the checkin was about and which files were affected. For the Hg notification, both of these fields are embedded in a big header block along with all the other fields, so it is quite difficult to make out the same information. It would be really nice if the formatting could be improved for the email notifications on the Hg side when we adopt it for the main CPython repository. The changes would be to: - add a blank line before and after the summary field - add a carriage return between the header and content for the summary field and the files field - indent the list of files by two spaces and use a carriage return rather than a comma to separate named files I've included an example below based on one of Tarek's recent pushes: Current Hg notification header and start of first diff: tarek.ziade pushed 7ebf14ab2840 to distutils2: http://hg.python.org/distutils2/rev/7ebf14ab2840 changeset: 816:7ebf14ab2840 tag: tip user: Tarek Ziadeta...@ziade.org date: Sat Nov 13 12:40:33 2010 +0100 summary: compiler_type - name files: distutils2/compiler/__init__.py, distutils2/compiler/bcppcompiler.py, distutils2/compiler/ccompiler.py, distutils2/compiler/cygwinccompiler.py, distutils2/compiler/msvc9compiler.py, distutils2/compiler/msvccompiler.py, distutils2/compiler/unixccompiler.py, distutils2/tests/test_config.py diff --git a/distutils2/compiler/__init__.py b/distutils2/compiler/__init__.py --- a/distutils2/compiler/__init__.py +++ b/distutils2/compiler/__init__.py @@ -13,7 +13,7 @@ Proposed change to separate out summary and files fields: tarek.ziade pushed 7ebf14ab2840 to distutils2: http://hg.python.org/distutils2/rev/7ebf14ab2840 changeset: 816:7ebf14ab2840 tag: tip user: Tarek Ziadeta...@ziade.org date: Sat Nov 13 12:40:33 2010 +0100 summary: compiler_type - name files: distutils2/compiler/__init__.py distutils2/compiler/bcppcompiler.py distutils2/compiler/ccompiler.py distutils2/compiler/cygwinccompiler.py distutils2/compiler/msvc9compiler.py distutils2/compiler/msvccompiler.py distutils2/compiler/unixccompiler.py distutils2/tests/test_config.py diff --git a/distutils2/compiler/__init__.py b/distutils2/compiler/__init__.py --- a/distutils2/compiler/__init__.py +++ b/distutils2/compiler/__init__.py @@ -13,7 +13,7 @@ Much better except possible for \n after 'summary:' Why not to drop summary label at all? The purpose of the text delimited with newlines is quite obvious. -- anatoly t. ___ 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] Stable buildbots
On Sun, Nov 14, 2010 at 02:48, David Bolen db3l@gmail.com wrote: Nick Coghlan ncogh...@gmail.com writes: Do we have any idea why the workaround to avoid the popup windows stopped working? (assuming it ever worked reliably - I thought it did, but that impression may have been incorrect) Oh, the pop-up handling for the RTL dialogs still seems to be working fine (at least I haven't seen any since I put it in place). That, plus the original buildbot tweaks to block any OS popups still looks solid for avoiding any dialogs that block a test process. This is a completely separate issue, though probably around just as long, and like the popup problem its frequency changes over time. By hung here I'm referring to cases where something must go wrong with a test and/or its cleanup such that a python_d process remains running, usually several of them at the same time. So I end up with a bunch of python_d processes in the background (but not with any dialogs pending), which eventually cause errors during attempts the next time the same builder is used since the file remains in use. I expect some of this may be the lack of a good process group cleanup under Windows, though the root cause may not be unique to Windows. I see something very similar reasonable frequency on my OSX Tiger buildbot as well. But since the filesystem there can let the build tree get cleaned and rebuilt even with a stranded executable, the impact is minimal on subsequent tests than on Windows, though the OSX processes do burn a ton of CPU. I run a script on OSX to kill them off, but that was quick to whip up since in those cases the stranded processes all end up getting owned by init so it's a simple ps grep and kill. In the Windows case I'll probably just set a time limit so if the processes have been around more than a few hours I figure they're safe to kill. -- David Is the dialog closer script available somewhere? I'm guessing this is the same script that closes the window which pops up during test_capi's crash? I just setup a Windows Server 2008 R2 x64 build slave and noticed it hanging due to the popup. ___ 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] Stable buildbots
Brian Curtin brian.cur...@gmail.com writes: Is the dialog closer script available somewhere? I'm guessing this is the same script that closes the window which pops up during test_capi's crash? Not sure about that specific test, as I won't normally see the windows. If the failure is causing a C RTL pop-up, then yes, the script will be closing it. If the test is generating an OS level pop-up (process error dialog from the OS, not RTL) then that is instead suppressed for any of the child processes run on my slave, so it never shows up at all. The RTL script is trivial enough that I'll just include it inline: - - - - - - - - - - - - - - - - - - - - - - - - - ; buildbot.au3 ; Forceably acknowledge any RTL pop-ups that may occur during testing $MSVCRT = Microsoft Visual C++ Runtime Library while 1 ; Wait for any RTL pop-up and then acknowledge WinWait($MSVCRT) ControlClick($MSVCRT, , [CLASS:Button; TEXT:OK]) ; Safety check to avoid spinning if it doesn't go away Sleep(1000) WEnd - - - - - - - - - - - - - - - - - - - - - - - - - Execute with AutoIt3 (http://www.autoitscript.com/autoit3/). I just use the plain autoit3.exe against this script from the Startup folder. The error mode buildbot patch was discussed in the past on this list (or it might have been the python-3000-devel list at the time). Originally it just used pywin32, but I added a fallback to ctypes if available. When first done, we were still building pre-2.5 builds - I suppose at this point it could just assume the presence of ctypes. The patch below is from 0.7.11p3: - - - - - - - - - - - - - - - - - - - - - - - - - --- commands.py 2009-08-13 11:53:17.0 -0400 +++ /cygdrive/d/python/2.6/lib/site-packages/buildbot/slave/commands.py 2009-11-08 02:09:38.0 -0500 @@ -489,6 +489,23 @@ if not self.keepStdinOpen: self.pp.closeStdin() +# [db3l] Under Win32, try to control error mode +win32_SetErrorMode = None +if runtime.platformType == 'win32': +try: +import win32api +win32_SetErrorMode = win32api.SetErrorMode +except: +try: +import ctypes +win32_SetErrorMode = ctypes.windll.kernel32.SetErrorMode +except: +pass + +if win32_SetErrorMode: +log.msg( Setting Windows error mode) +old_err_mode = win32_SetErrorMode(7) + # win32eventreactor's spawnProcess (under twisted = 2.0.1) returns # None, as opposed to all the posixbase-derived reactors (which # return the new Process object). This is a nuisance. We can make up @@ -509,6 +526,10 @@ if not self.process: self.process = p +# [db3l] +if win32_SetErrorMode: +win32_SetErrorMode(old_err_mode) + # connectionMade also closes stdin as long as we're not using a PTY. # This is intended to kill off inappropriately interactive commands # better than the (long) hung-command timeout. ProcessPTY should be - - - - - - - - - - - - - - - - - - - - - - - - - -- David ___ 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] Stable buildbots
Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line.
Looking at the changes since the last success, I can't see anything
which would obviously affect that... Any suspects?
Here's what's failing:
==
ERROR: test_run_code (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent call last):
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py,
line 95, in test_run_code
assert_python_failure('-c')
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py,
line 55, in assert_python_failure
return _assert_python(False, *args, **env_vars)
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py,
line 29, in _assert_python
env=env)
File /Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py,
line 683, in __init__
self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor
==
ERROR: test_run_module (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent call last):
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py,
line 72, in test_run_module
assert_python_failure('-m')
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py,
line 55, in assert_python_failure
return _assert_python(False, *args, **env_vars)
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py,
line 29, in _assert_python
env=env)
File /Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py,
line 683, in __init__
self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor
==
ERROR: test_version (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent call last):
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py,
line 48, in test_version
rc, out, err = assert_python_ok('-V')
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py,
line 48, in assert_python_ok
return _assert_python(True, *args, **env_vars)
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py,
line 29, in _assert_python
env=env)
File /Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py,
line 683, in __init__
self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor
Bill
___
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
