[ python-Bugs-1643369 ] function breakpoints in pdb
Bugs item #1643369, was opened at 2007-01-24 10:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643369&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: decitre (decitre) Assigned to: Nobody/Anonymous (nobody) Summary: function breakpoints in pdb Initial Comment: pdb.Pdb.find_function method is not able to recognize class methods, since the regular expression it uses only looks for "def" at beginning of lines. Please replace r'def\s+%s\s*[(]' % funcname with r'\s*def\s+%s\s*[(]' % funcname test file in attachment. this file shows that pdb can set a breakpoint on foo but not on readline function. Regards, Emmanuel www.e-rsatz.info -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643369&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1643370 ] recursive urlparse
Feature Requests item #1643370, was opened at 2007-01-24 10:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1643370&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: anatoly techtonik (techtonik) Assigned to: Nobody/Anonymous (nobody) Summary: recursive urlparse Initial Comment: urlparse module is incomplete. there is no convenient high-level function to parse url down into atomic chunks, urldecode query and bring it to array (or dictionary for that case), so that you can modify that dictionary and reassemble it into query again using nothing more than simple array manipulations. This kind of function is universal and flexible in the same way that low-level API, but in comparison it allows to considerably speed up development process if the speech is about urls I propose urlparseex(urlstring) function that will dissect the URL into dictionary of appropriate dictionaries or strings and decode all % entities scheme 0 string netloc 1 dictionary username 1.1 string or whatever password 1.2 string or whatever server 1.3 hostname string port1.4 port integer path2 string params 3 ordered dictionary of path components for the sake of reassembling them later (sorry, I have little pythons in my head to replace "ordered dictionary" with something more appropriate) where respective path part entry is also dictionary of parameters query 4 dictionary fragment5 string there must be also counterpart urlunparseex(dictionary) to reassemble url and reencode entities Reasons behind the decision: - 90% of time you need to decode % entities - this must be made by default (whoever need to let them encoded are in minor and may use other functions) - atomic recursion format is needed to be able to easily change any url component and reassemble it back - get simple swiss-army knife for high-level (read - logical) url operations in one module http://docs.python.org/lib/module-urlparse.html There is also this proposal below. It is a little bit different, but shows that after four years url handling problems are still actual. http://sourceforge.net/tracker/index.php?func=detail&aid=600362&group_id=5470&atid=355470 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1643370&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1643369 ] function breakpoints in pdb
Bugs item #1643369, was opened at 2007-01-24 10:22 Message generated for change (Settings changed) made by decitre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643369&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Private: No Submitted By: decitre (decitre) Assigned to: Nobody/Anonymous (nobody) Summary: function breakpoints in pdb Initial Comment: pdb.Pdb.find_function method is not able to recognize class methods, since the regular expression it uses only looks for "def" at beginning of lines. Please replace r'def\s+%s\s*[(]' % funcname with r'\s*def\s+%s\s*[(]' % funcname test file in attachment. this file shows that pdb can set a breakpoint on foo but not on readline function. Regards, Emmanuel www.e-rsatz.info -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643369&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1362475 ] Text.edit_modified() doesn't work
Bugs item #1362475, was opened at 2005-11-21 03:13 Message generated for change (Comment added) made by mkiever You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362475&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ron Provost ([EMAIL PROTECTED]) Assigned to: Martin v. Löwis (loewis) Summary: Text.edit_modified() doesn't work Initial Comment: Tkinter's Text widget has a method edit_modified() which should return True if the modified flag of the widget has been set, False otherwise. It should also be possible to pass True or False into the method to set the flag to a desired state. The implementation retrieves the correct value, but then calls self._getints( result ). This causes an exception to be thrown. In my build, I found that changing the implementation to the following appears to fix the function. return self.tk.call( self._w, 'edit', 'modified', arg ) -- Comment By: Matthias Kievernagel (mkiever) Date: 2007-01-24 15:53 Message: Logged In: YES user_id=1477880 Originator: NO Posted patch 1643641. The patch removes the offending _getints call. Greetings, Matthias Kievernagel -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362475&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1643712 ] Emphasize buffering issues when sys.stdin is used
Bugs item #1643712, was opened at 2007-01-24 12:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raghuram Devarakonda (draghuram) Assigned to: Nobody/Anonymous (nobody) Summary: Emphasize buffering issues when sys.stdin is used Initial Comment: Hi, Please look at the bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1633941&group_id=5470&atid=105470 As I commented there, I don't think any fix is needed but it appears to me that mentioning this case in docs wouldn't hurt. Something like this can be added to next() description at: http://docs.python.org/lib/bltin-file-objects.html "Please consider buffering issues while using ``for line in sys.stdin`` when the input is being interactively entered". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643712&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633941 ] for line in sys.stdin: doesn't notice EOF the first time
Bugs item #1633941, was opened at 2007-01-12 05:34 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: for line in sys.stdin: doesn't notice EOF the first time Initial Comment: [forwarded from http://bugs.debian.org/315888] for line in sys.stdin: doesn't notice EOF the first time when reading from tty. The test program: import sys for line in sys.stdin: print line, print "eof" A sample session: [EMAIL PROTECTED] python foo.py foo <--- I pressed Enter and then Ctrl-D foo <--- then this appeared, but not more eof <--- this only came when I pressed Ctrl-D a second time [EMAIL PROTECTED] Seems to me that there is some buffering issue where Python needs to read end-of-file twice to notice it on all levels. Once should be enough. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-24 12:20 Message: Logged In: YES user_id=984087 Originator: NO I tested two kinds of inputs with iter and noiter verisons. I posted "noter" code and OP's code is the iter version. 1) For input without newline at all (line1) behaves same with both versions. 2) The noiter version prints "eof" with "line1\n" while the iter version requires an additional CTRL-D. This is because iter version uses read ahead which is implemented using fread() . A simple C program using fread() behaves exactly same way. I tested on Linux but am sure windows behaviour (as posted by gagenellina) will have same reasons. Since the issue is with platform's stdio library, I don't think python should fix anything here. However, it may be worthwhile to mention something about this in documentation. I will open a bug for this purpose. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 12:45 Message: Logged In: YES user_id=984087 Originator: NO Ok. This may sound stupid but I couldn't find a way to attach a file to this bug report. So I am copying the code here: import sys line = sys.stdin.readline() while (line): print line, line = sys.stdin.readline() print "eof" * -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 12:37 Message: Logged In: YES user_id=984087 Originator: NO Sorry for my duplicate comment. It was a mistake. On closer examination, the OP's description does seem to indicate some issue. Please look at (attached) stdin_noiter.py which uses readline() directly and it does not have the problem described here. It properly detects EOF on first CTRL-D. This points to some problem with the iterator function fileobject.c:file_iternext(). I think that the first CTRL-D might be getting lost somewhere in the read ahead code (which only comes into picture with iterator). -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 11:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 11:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-01-13 23:20 Message: Logged In: YES user_id=479790 Originator: NO Same thing occurs on Windows. Even worse, if the line does not end with CR, Ctrl-Z (EOF in Windows, equivalent to Ctrl-D) has to be pressed 3 times: D:\Temp>python foo.py foo <--- I pressed Enter ^Z <--- I pressed Ctrl-Z and then Enter again foo <--- this appeared ^Z <--- I pressed Ctrl-Z and then Enter again D:\Temp>python foo.py foo^Z <--- I
[ python-Bugs-1643738 ] Problem with signals in a single-threaded application
Bugs item #1643738, was opened at 2007-01-24 16:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ulisses Furquim (ulissesf) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with signals in a single-threaded application Initial Comment: I'm aware of the problems with signals in a multithreaded application, but I was using signals in a single-threaded application and noticed something that seemed wrong. Some signals were apparently being lost, but when another signal came in the python handler for that "lost" signal was being called. The problem seems to be inside the signal module. The global variable is_tripped is incremented every time a signal arrives. Then, inside PyErr_CheckSignals() (the pending call that calls all python handlers for signals that arrived) we can return immediately if is_tripped is zero. If is_tripped is different than zero, we loop through all signals calling the registered python handlers and after that we zero is_tripped. This seems to be ok, but what happens if a signal arrives after we've returned from its handler (or even after we've checked if that signal arrived) and before we zero is_tripped? I guess we can have a situation where is_tripped is zero but some Handlers[i].tripped are not. In fact, I've inserted some debugging output and could see that this actually happens and then I've written the attached test program to reproduce the problem. When we run this program, the handler for the SIGALRM isn't called after we return from the SIGIO handler. We return to our main loop and print 'Loop!' every 3 seconds aprox. and the SIGALRM handler is called only when another signal arrives (like when we hit Ctrl-C). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643738&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1643738 ] Problem with signals in a single-threaded application
Bugs item #1643738, was opened at 2007-01-24 16:14 Message generated for change (Comment added) made by ulissesf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ulisses Furquim (ulissesf) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with signals in a single-threaded application Initial Comment: I'm aware of the problems with signals in a multithreaded application, but I was using signals in a single-threaded application and noticed something that seemed wrong. Some signals were apparently being lost, but when another signal came in the python handler for that "lost" signal was being called. The problem seems to be inside the signal module. The global variable is_tripped is incremented every time a signal arrives. Then, inside PyErr_CheckSignals() (the pending call that calls all python handlers for signals that arrived) we can return immediately if is_tripped is zero. If is_tripped is different than zero, we loop through all signals calling the registered python handlers and after that we zero is_tripped. This seems to be ok, but what happens if a signal arrives after we've returned from its handler (or even after we've checked if that signal arrived) and before we zero is_tripped? I guess we can have a situation where is_tripped is zero but some Handlers[i].tripped are not. In fact, I've inserted some debugging output and could see that this actually happens and then I've written the attached test program to reproduce the problem. When we run this program, the handler for the SIGALRM isn't called after we return from the SIGIO handler. We return to our main loop and print 'Loop!' every 3 seconds aprox. and the SIGALRM handler is called only when another signal arrives (like when we hit Ctrl-C). -- >Comment By: Ulisses Furquim (ulissesf) Date: 2007-01-24 17:46 Message: Logged In: YES user_id=1578960 Originator: YES This patch is very simple. We didn't want to remove the is_tripped variable because PyErr_CheckSignals() is called several times directly so it would be nice if we could return immediately if no signals arrived. We also didn't want to run the registered handlers with any set of signals blocked. Thus, we thought of zeroing is_tripped as soon as we know there are signals to be handled (after we test is_tripped). This way most of the times we can return immediately because is_tripped is zero and we also don't need to block any signals. However, with this approach we can have a situation where is_tripped isn't zero but we have no signals to handle, so we'll loop through all signals and no registered handler will be called. This happens when we receive a signal after we zero is_tripped and before we check Handlers[i].tripped for that signal. Any comments? File Added: signals-v0.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643738&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1643738 ] Problem with signals in a single-threaded application
Bugs item #1643738, was opened at 2007-01-24 13:14 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ulisses Furquim (ulissesf) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with signals in a single-threaded application Initial Comment: I'm aware of the problems with signals in a multithreaded application, but I was using signals in a single-threaded application and noticed something that seemed wrong. Some signals were apparently being lost, but when another signal came in the python handler for that "lost" signal was being called. The problem seems to be inside the signal module. The global variable is_tripped is incremented every time a signal arrives. Then, inside PyErr_CheckSignals() (the pending call that calls all python handlers for signals that arrived) we can return immediately if is_tripped is zero. If is_tripped is different than zero, we loop through all signals calling the registered python handlers and after that we zero is_tripped. This seems to be ok, but what happens if a signal arrives after we've returned from its handler (or even after we've checked if that signal arrived) and before we zero is_tripped? I guess we can have a situation where is_tripped is zero but some Handlers[i].tripped are not. In fact, I've inserted some debugging output and could see that this actually happens and then I've written the attached test program to reproduce the problem. When we run this program, the handler for the SIGALRM isn't called after we return from the SIGIO handler. We return to our main loop and print 'Loop!' every 3 seconds aprox. and the SIGALRM handler is called only when another signal arrives (like when we hit Ctrl-C). -- >Comment By: Tim Peters (tim_one) Date: 2007-01-24 15:19 Message: Logged In: YES user_id=31435 Originator: NO Very nice! I'd add a description of the minor pathology remaining you described here as a code comment, at the point is_tripped is set to 0. If this stuff were screamingly obvious, the bug you fixed wouldn't have persisted for 15 years ;-) -- Comment By: Ulisses Furquim (ulissesf) Date: 2007-01-24 14:46 Message: Logged In: YES user_id=1578960 Originator: YES This patch is very simple. We didn't want to remove the is_tripped variable because PyErr_CheckSignals() is called several times directly so it would be nice if we could return immediately if no signals arrived. We also didn't want to run the registered handlers with any set of signals blocked. Thus, we thought of zeroing is_tripped as soon as we know there are signals to be handled (after we test is_tripped). This way most of the times we can return immediately because is_tripped is zero and we also don't need to block any signals. However, with this approach we can have a situation where is_tripped isn't zero but we have no signals to handle, so we'll loop through all signals and no registered handler will be called. This happens when we receive a signal after we zero is_tripped and before we check Handlers[i].tripped for that signal. Any comments? File Added: signals-v0.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643738&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1635363 ] Add command line help to windows unistall binary
Bugs item #1635363, was opened at 2007-01-14 15:58 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: anatoly techtonik (techtonik) >Assigned to: Thomas Heller (theller) Summary: Add command line help to windows unistall binary Initial Comment: It is impossible to remove package installed with uninstall binary created with Distutils unless you know that you need to specify -u switch. "E:\ENV\Python24\Removescons.exe" -u "E:\ENV\Python24\scons-wininst.log" If there are any additional switches - they could be displayed in MsgBox instead of/along with error message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1635363&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1642054 ] Python 2.5 gets curses.h warning on HPUX
Bugs item #1642054, was opened at 2007-01-22 19:27 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1642054&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 gets curses.h warning on HPUX Initial Comment: I downloaded http://www.python.org/ftp/python/2.5/Python-2.5.tgz and tried to build it on "HP-UX glade B.11.11 U 9000/800 unknown". When I ran "./configure", I got warnings that "curses.h: present but cannot be compiled". See attached log file. -- >Comment By: A.M. Kuchling (akuchling) Date: 2007-01-24 15:20 Message: Logged In: YES user_id=11375 Originator: NO You'll have to help us some more. This is apparently happening because HP-UX's curses.h file needs some other header file to be included first; not having an HP-UX machine, I have no way to figure out which other header file is needed. Could you please try to figure out which file is necessary? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1642054&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1643738 ] Problem with signals in a single-threaded application
Bugs item #1643738, was opened at 2007-01-24 13:14 Message generated for change (Comment added) made by tony_nelson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ulisses Furquim (ulissesf) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with signals in a single-threaded application Initial Comment: I'm aware of the problems with signals in a multithreaded application, but I was using signals in a single-threaded application and noticed something that seemed wrong. Some signals were apparently being lost, but when another signal came in the python handler for that "lost" signal was being called. The problem seems to be inside the signal module. The global variable is_tripped is incremented every time a signal arrives. Then, inside PyErr_CheckSignals() (the pending call that calls all python handlers for signals that arrived) we can return immediately if is_tripped is zero. If is_tripped is different than zero, we loop through all signals calling the registered python handlers and after that we zero is_tripped. This seems to be ok, but what happens if a signal arrives after we've returned from its handler (or even after we've checked if that signal arrived) and before we zero is_tripped? I guess we can have a situation where is_tripped is zero but some Handlers[i].tripped are not. In fact, I've inserted some debugging output and could see that this actually happens and then I've written the attached test program to reproduce the problem. When we run this program, the handler for the SIGALRM isn't called after we return from the SIGIO handler. We return to our main loop and print 'Loop!' every 3 seconds aprox. and the SIGALRM handler is called only when another signal arrives (like when we hit Ctrl-C). -- Comment By: Tony Nelson (tony_nelson) Date: 2007-01-24 15:24 Message: Logged In: YES user_id=1356214 Originator: NO ISTM that is_tripped should be zeroed after the test for threading, so that signals will finally get handled when the proper thread is running. -- Comment By: Tim Peters (tim_one) Date: 2007-01-24 15:19 Message: Logged In: YES user_id=31435 Originator: NO Very nice! I'd add a description of the minor pathology remaining you described here as a code comment, at the point is_tripped is set to 0. If this stuff were screamingly obvious, the bug you fixed wouldn't have persisted for 15 years ;-) -- Comment By: Ulisses Furquim (ulissesf) Date: 2007-01-24 14:46 Message: Logged In: YES user_id=1578960 Originator: YES This patch is very simple. We didn't want to remove the is_tripped variable because PyErr_CheckSignals() is called several times directly so it would be nice if we could return immediately if no signals arrived. We also didn't want to run the registered handlers with any set of signals blocked. Thus, we thought of zeroing is_tripped as soon as we know there are signals to be handled (after we test is_tripped). This way most of the times we can return immediately because is_tripped is zero and we also don't need to block any signals. However, with this approach we can have a situation where is_tripped isn't zero but we have no signals to handle, so we'll loop through all signals and no registered handler will be called. This happens when we receive a signal after we zero is_tripped and before we check Handlers[i].tripped for that signal. Any comments? File Added: signals-v0.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643738&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1635363 ] Add command line help to windows unistall binary
Feature Requests item #1635363, was opened at 2007-01-14 21:58 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1635363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Distutils >Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: anatoly techtonik (techtonik) Assigned to: Thomas Heller (theller) Summary: Add command line help to windows unistall binary Initial Comment: It is impossible to remove package installed with uninstall binary created with Distutils unless you know that you need to specify -u switch. "E:\ENV\Python24\Removescons.exe" -u "E:\ENV\Python24\scons-wininst.log" If there are any additional switches - they could be displayed in MsgBox instead of/along with error message. -- >Comment By: Thomas Heller (theller) Date: 2007-01-24 21:35 Message: Logged In: YES user_id=11105 Originator: NO I do not remember what my original intention was to not document the usage of the bdist_wininst uninstaller. However, this is the first time that this request has come up, so it seems there is no pressing need to run the uninstaller manually. You could (and probably should) use the control panel app to remove packages. Now, you have discovered the magic that is needed so you can use it. I would prefer not to 'fix' this - especially since there are other problems with bdist_wininst, I guess it will be superseeded by bdist_msi sooner or later. Changing this to 'feature request'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1635363&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-901727 ] extra_path kwarg to setup() undocumented
Bugs item #901727, was opened at 2004-02-21 16:04
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901727&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bob Ippolito (etrepum)
>Assigned to: Nobody/Anonymous (nobody)
Summary: extra_path kwarg to setup() undocumented
Initial Comment:
I can't find documentation for extra_path anywhere.. but this is the
documentation I found by searching google ( http://
mail.python.org/pipermail/distutils-sig/2000-March/000803.html ),
from an old USAGE.txt that sits in the CVS attic now:
extra_path:
information about extra intervening directories to put between
'install_lib' and 'install_sitelib', along with a .pth file to
ensure that those directories wind up in sys.path. Can be a 1-
or
2-tuple, or a comma-delimited string with 1 or 2 parts. The
1-element case is simpler: the .pth file and directory have the
same
name (except for ".pth"). Eg. if extra_path is "foo" or ("foo",),
then Distutils sets 'install_site_lib' to 'install_lib' +
"site-packages/foo", and puts foo.path in the "site-packages"
directory; it contains just "foo". The 2-element case allows the
.pth file and intervening directories to be named differently;
eg.
if 'extra_path' is ("foo","foo/bar/baz") (or "foo,foo/bar/baz"),
then Distutils will set 'install_site_lib' to 'install_lib' +
"site-packages/foo/bar/baz", and put "foo.pth" containing
"foo/bar/baz" in the "site-packages" directory.
--
>Comment By: Thomas Heller (theller)
Date: 2007-01-24 21:36
Message:
Logged In: YES
user_id=11105
Originator: NO
Unassign, I won't work on this.
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2005-05-17 18:16
Message:
Logged In: YES
user_id=580910
extra_path also doesn't have a command-line equivalent.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901727&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-914375 ] modulefinder is not documented
Bugs item #914375, was opened at 2004-03-11 20:33 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Thomas Heller (theller) Summary: modulefinder is not documented Initial Comment: The "modulefinder" module has not been documented. Now that it is a module, it needs to be documented. -- Comment By: Georg Brandl (gbrandl) Date: 2006-06-14 08:42 Message: Logged In: YES user_id=849994 There seems to be a libmodulefinder.tex, but it is not very thorough. -- Comment By: Thomas Heller (theller) Date: 2005-06-16 20:51 Message: Logged In: YES user_id=11105 If Just doesn't appear ;-) please assign to me. I should at least describe the api that is actually *used* in py2exe. -- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-16 20:21 Message: Logged In: YES user_id=11375 Just, it looks like you're responsible for modulefinder, so I'm reassigning this to you. It would be helpful if you could take a look at the docs and see if anything is documented that should be private. Please unassign (or close?) this bug if you're not connected to modulefinder. -- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 22:14 Message: Logged In: YES user_id=11375 I've written a crude first cut at this, but the module's code is very hard to read and it's not clear which bits are public and which aren't. The module's author should do this task (and use some docstrings in the code, too) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1635335 ] Add registry functions to windows postinstall
Feature Requests item #1635335, was opened at 2007-01-14 21:00 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1635335&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: anatoly techtonik (techtonik) Assigned to: Thomas Heller (theller) Summary: Add registry functions to windows postinstall Initial Comment: It would be useful to add regkey_created() or regkey_modified() to windows postinstall scripts along with directory_created() and file_created(). Useful for adding installed package to App Paths. -- >Comment By: Thomas Heller (theller) Date: 2007-01-24 21:47 Message: Logged In: YES user_id=11105 Originator: NO General comments: There are some problems with bdist_wininst that I assume will get worse in the future, especially with the postinstall script, because of different versions of the MS C runtime library. The installers that bdist_wininst creates are linked against a certain version which must be the same version that the Python runtime uses. If they do not match, the output of the postinstall script will not be displayed in the gui, or, in the worst case it could crash. The second problem is that bdist_wininst will not work with 64-bit Pythons. All this *could* probably be fixed, of course, but since bdist_msi does *not* have these problems IMO bdist_msi will superseed bdist_wininst sooner or later. About the concrete problem: Originally, when bdist_wininst was first implemented, Python did not have the _winreg module, so it was not possible to create or remove registry entries in the install script or postinstall script anyway and these function would not have made any sense at all. They could probably make sense now, but it is equally possible to modify the registry in the postinstall-script at installation time, and revert these changes in the postinstall-script at uninstallation time. I would prefer not to make these changes, since a workaround is possible. -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-20 19:07 Message: Logged In: YES user_id=21627 Originator: NO Thomas, what do you think? -- Comment By: anatoly techtonik (techtonik) Date: 2007-01-20 15:26 Message: Logged In: YES user_id=669020 Originator: YES Windows postinstall script is bundled with installation, launched after installation and just before uninstall. It is described here. http://docs.python.org/dist/postinstallation-script.html#SECTION00531 Where these should be defined? I do not know - there are already some functions that are said to be "available as additional built-in functions in the installation script." on the page above. The purpose is to be able to create/delete registry keys during installation. This should also be reflected in installation log file with appropriate status code so that users could be aware of what's going on. I think the functions needed are already defined in http://docs.python.org/lib/module--winreg.html but the module is very low-level. I'd rather use Autoit like API - http://www.autoitscript.com/autoit3/docs/functions/RegRead.htm http://www.autoitscript.com/autoit3/docs/functions/RegWrite.htm http://www.autoitscript.com/autoit3/docs/functions/RegDelete.htm -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-20 11:55 Message: Logged In: YES user_id=21627 Originator: NO Can you please elaborate? Where should these functions be defined, what should they do, and when should they be invoked (by what code)? Also, what is a "windows postinstall script"? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1635335&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 7 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: A.M. Kuchling (akuchling) Date: 2007-01-24 15:48 Message: Logged In: YES user_id=11375 Originator: NO I've strengthened the warning again. The MH bug in unified2 is straightforward: MH.remove() opens a file object, locks it, closes the file object, and then tries to unlock it. Presumably the MH test case never bothered locking the mailbox before making changes before. -- Comment By: David Watson (baikie) Date: 2007-01-22 15:24 Message: Logged In: YES user_id=1504904 Originator: YES So what you propose to commit for 2.5 is basically mailbox-unified2 (your mailbox-unified-patch, minus the _toc clearing)? -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-22 10:46 Message: Logged In: YES user_id=11375 Originator: NO This would be an API change, and therefore out-of-bounds for 2.5. I suggest giving up on this for 2.5.1 and only fixing it in 2.6. I'll add another warning to the docs, and maybe to the module as well. -- Comment By: David Watson (baikie) Date: 2007-01-21 17:10 Message: Logged In: YES user_id=1504904 Originator: YES Hold on, I have a plan. If _toc is only regenerated on locking, or at the end of a flush(), then the only way self._pending can be set at that time is if the application has made modifications before calling lock(). If we make that an exception-raising offence, then we can assume that self._toc is a faithful representation of the last known contents of the file. That means we can preserve the existing message keys on a reread without any of that _user_toc nonsense. Diff attached, to apply on top of mailbox-unified2. It's probably had even less review and testing than the previous version, but it appears to pass all the regression tests and doesn't change any existing semantics. File Added: mailbox-update-toc-new.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-20 22:16 Message: Logged In: YES user_id=11375 Originator: NO I'm starting to lose track of all the variations on the bug. Maybe we should just add more warnings to the documentation about locking the mailbox when modifying it and not try to fix this at all. -- Comment By: David Watson (baikie) Date: 2007-01-20 13:20 Message: Logged In: YES user_id=1504904 Originator: YES Hang on. If a message's key changes after recreating _toc, that does not mean that another process has modified the mailbox. If the application removes a message and then (inadvertently) causes _toc to be regenerated, the keys of all subsequent messages will be decremented by one, due only to the application's own actions. That's what happens in the "br
[ python-Bugs-1544339 ] _ctypes fails to build on Solaris x86 32-bit (Sun compiler)
Bugs item #1544339, was opened at 2006-08-22 06:28 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Case Van Horsen (casevh) Assigned to: Thomas Heller (theller) Summary: _ctypes fails to build on Solaris x86 32-bit (Sun compiler) Initial Comment: The _ctypes modules fails to compile on Solaris 10 x86 32-bit using the Sun Studio 11 compiler. _ctypes does compile successfully using gcc. The error messages are attached. If needed, I can provide access to the machine. -- >Comment By: Thomas Heller (theller) Date: 2007-01-24 21:53 Message: Logged In: YES user_id=11105 Originator: NO You can at least see which test(s) crashes when you run the ctypes tests in this way: ./python Lib/ctypes/test/runtests.py -v -- Comment By: Case Van Horsen (casevh) Date: 2006-10-13 04:57 Message: Logged In: YES user_id=1212585 I have tracked down two issues. First Sun's cc compiler does defines __386 instead of __386__. This causes problems in ffitarget.h Second, Sun's cc compiler fails on the following line in ffi.h: } ffi_closure __attribute__((aligned (8))); This is a problem in Sun's cc compiler. It is fixed in the Sun Studio Express August 2006 release. I don't think there is a patch for the "official" Sun Studio 11 compiler. With these two changes, ctypes does compile but "make test" still fails. I am still researching the "make test" failure. test_crypt test_csv test_ctypes sh: objdump: not found *** Signal 11 - core dumped make: Fatal error: Command failed for target `test' bash-3.00$ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1637120 ] Python 2.5 fails to build on AIX 5.3 (xlc_r compiler)
Bugs item #1637120, was opened at 2007-01-16 22:06
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637120&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Orlando Irrazabal (oirraza)
Assigned to: Thomas Heller (theller)
Summary: Python 2.5 fails to build on AIX 5.3 (xlc_r compiler)
Initial Comment:
Initial Comment:
Build of Python 2.5 on AIX 5.3 with xlc_r fails with the below error message.
The configure line is:
./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" --disable-ipv6
AR="ar -X64"
[...]
building '_ctypes' extension
xlc_r -q64 -DNDEBUG -O -I. -I/sw_install/python-2.5/./Include
-Ibuild/temp.aix-5.3-2.5/libffi/include -Ibuild/temp.aix-5.3-2.5/libffi
-I/sw_install/python-2.5/Modules/_ctypes/libffi/src -I./Include -I.
-I/sw_install/python-2.5/Include -I/sw_install/python-2.5 -c
/sw_install/python-2.5/Modules/_ctypes/_ctypes.c -o
build/temp.aix-5.3-2.5/sw_install/python-2.5/Modules/_ctypes/_ctypes.o
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 221.3: 1506-166 (S)
Definition of function ffi_closure requires parentheses.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 221.15: 1506-276 (S) Syntax
error: possible missing '{'?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 248.3: 1506-273 (E) Missing
type in declaration of ffi_raw_closure.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.38: 1506-275 (S)
Unexpected text '*' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 252.23: 1506-276 (S) Syntax
error: possible missing identifier?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.1: 1506-033 (S)
Function ffi_prep_raw_closure is not valid. Function cannot return a function.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.1: 1506-282 (S) The
type of the parameters must be specified in a prototype.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 254.23: 1506-275 (S)
Unexpected text 'void' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 254.38: 1506-275 (S)
Unexpected text ')' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.43: 1506-275 (S)
Unexpected text '*' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 258.28: 1506-276 (S) Syntax
error: possible missing identifier?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.1: 1506-033 (S)
Function ffi_prep_java_raw_closure is not valid. Function cannot return a
function.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.1: 1506-282 (S) The
type of the parameters must be specified in a prototype.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 260.28: 1506-275 (S)
Unexpected text 'void' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 260.43: 1506-275 (S)
Unexpected text ')' encountered.
"/sw_install/python-2.5/Modules/_ctypes/ctypes.h", line 71.9: 1506-046 (S)
Syntax error.
"/sw_install/python-2.5/Modules/_ctypes/ctypes.h", line 77.26: 1506-195 (S)
Integral constant expression with a value greater than zero is required.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 2804.31: 1506-068 (E)
Operation between types "void*" and "int(*)(void)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 3357.28: 1506-280 (E)
Function argument assignment between types "int(*)(void)" and "void*" is not
allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 3417.42: 1506-022 (S)
"pcl" is not a member of "struct {...}".
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4749.67: 1506-280 (E)
Function argument assignment between types "void*" and "void*(*)(void*,const
void*,unsigned long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4750.66: 1506-280 (E)
Function argument assignment between types "void*" and
"void*(*)(void*,int,unsigned long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4751.69: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(const char*,long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4752.64: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(void*,struct _object*,struct _object*)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4754.70: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(const unsigned int*,int)" is not allowed.
building '_ctypes_test' extension
xlc_r -q64 -DNDEBUG -O -I. -I/sw_install/python-2.5/./Include -I./Include -I.
-I/sw_install/python-2.5/Include -I/sw_install/python-2.5 -c
/sw_install/python-2.5/Modules/_ctypes/_ctypes_test.c -o
build/temp.a
[ python-Bugs-1643738 ] Problem with signals in a single-threaded application
Bugs item #1643738, was opened at 2007-01-24 16:14 Message generated for change (Comment added) made by ulissesf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ulisses Furquim (ulissesf) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with signals in a single-threaded application Initial Comment: I'm aware of the problems with signals in a multithreaded application, but I was using signals in a single-threaded application and noticed something that seemed wrong. Some signals were apparently being lost, but when another signal came in the python handler for that "lost" signal was being called. The problem seems to be inside the signal module. The global variable is_tripped is incremented every time a signal arrives. Then, inside PyErr_CheckSignals() (the pending call that calls all python handlers for signals that arrived) we can return immediately if is_tripped is zero. If is_tripped is different than zero, we loop through all signals calling the registered python handlers and after that we zero is_tripped. This seems to be ok, but what happens if a signal arrives after we've returned from its handler (or even after we've checked if that signal arrived) and before we zero is_tripped? I guess we can have a situation where is_tripped is zero but some Handlers[i].tripped are not. In fact, I've inserted some debugging output and could see that this actually happens and then I've written the attached test program to reproduce the problem. When we run this program, the handler for the SIGALRM isn't called after we return from the SIGIO handler. We return to our main loop and print 'Loop!' every 3 seconds aprox. and the SIGALRM handler is called only when another signal arrives (like when we hit Ctrl-C). -- >Comment By: Ulisses Furquim (ulissesf) Date: 2007-01-24 19:09 Message: Logged In: YES user_id=1578960 Originator: YES Yep, you're right, Tony Nelson. We overlooked this case but we can zero is_tripped after the test for threading as you've already said. The patch was updated and it also includes the code comment Tim Peters suggested. Please, I don't know if the wording is right so feel free to comment on it. I still plan to write a test case for the problem being solved (as soon as I understand how test_signals.py work :-). File Added: signals-v1.patch -- Comment By: Tony Nelson (tony_nelson) Date: 2007-01-24 18:24 Message: Logged In: YES user_id=1356214 Originator: NO ISTM that is_tripped should be zeroed after the test for threading, so that signals will finally get handled when the proper thread is running. -- Comment By: Tim Peters (tim_one) Date: 2007-01-24 18:19 Message: Logged In: YES user_id=31435 Originator: NO Very nice! I'd add a description of the minor pathology remaining you described here as a code comment, at the point is_tripped is set to 0. If this stuff were screamingly obvious, the bug you fixed wouldn't have persisted for 15 years ;-) -- Comment By: Ulisses Furquim (ulissesf) Date: 2007-01-24 17:46 Message: Logged In: YES user_id=1578960 Originator: YES This patch is very simple. We didn't want to remove the is_tripped variable because PyErr_CheckSignals() is called several times directly so it would be nice if we could return immediately if no signals arrived. We also didn't want to run the registered handlers with any set of signals blocked. Thus, we thought of zeroing is_tripped as soon as we know there are signals to be handled (after we test is_tripped). This way most of the times we can return immediately because is_tripped is zero and we also don't need to block any signals. However, with this approach we can have a situation where is_tripped isn't zero but we have no signals to handle, so we'll loop through all signals and no registered handler will be called. This happens when we receive a signal after we zero is_tripped and before we check Handlers[i].tripped for that signal. Any comments? File Added: signals-v0.patch -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643738&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1635335 ] Add registry functions to windows postinstall
Feature Requests item #1635335, was opened at 2007-01-14 21:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1635335&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: anatoly techtonik (techtonik) Assigned to: Thomas Heller (theller) Summary: Add registry functions to windows postinstall Initial Comment: It would be useful to add regkey_created() or regkey_modified() to windows postinstall scripts along with directory_created() and file_created(). Useful for adding installed package to App Paths. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-24 22:48 Message: Logged In: YES user_id=21627 Originator: NO Closing this as "won't fix", then. techtonik, if you think this is an important feature, please contribute a patch. -- Comment By: Thomas Heller (theller) Date: 2007-01-24 21:47 Message: Logged In: YES user_id=11105 Originator: NO General comments: There are some problems with bdist_wininst that I assume will get worse in the future, especially with the postinstall script, because of different versions of the MS C runtime library. The installers that bdist_wininst creates are linked against a certain version which must be the same version that the Python runtime uses. If they do not match, the output of the postinstall script will not be displayed in the gui, or, in the worst case it could crash. The second problem is that bdist_wininst will not work with 64-bit Pythons. All this *could* probably be fixed, of course, but since bdist_msi does *not* have these problems IMO bdist_msi will superseed bdist_wininst sooner or later. About the concrete problem: Originally, when bdist_wininst was first implemented, Python did not have the _winreg module, so it was not possible to create or remove registry entries in the install script or postinstall script anyway and these function would not have made any sense at all. They could probably make sense now, but it is equally possible to modify the registry in the postinstall-script at installation time, and revert these changes in the postinstall-script at uninstallation time. I would prefer not to make these changes, since a workaround is possible. -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-20 19:07 Message: Logged In: YES user_id=21627 Originator: NO Thomas, what do you think? -- Comment By: anatoly techtonik (techtonik) Date: 2007-01-20 15:26 Message: Logged In: YES user_id=669020 Originator: YES Windows postinstall script is bundled with installation, launched after installation and just before uninstall. It is described here. http://docs.python.org/dist/postinstallation-script.html#SECTION00531 Where these should be defined? I do not know - there are already some functions that are said to be "available as additional built-in functions in the installation script." on the page above. The purpose is to be able to create/delete registry keys during installation. This should also be reflected in installation log file with appropriate status code so that users could be aware of what's going on. I think the functions needed are already defined in http://docs.python.org/lib/module--winreg.html but the module is very low-level. I'd rather use Autoit like API - http://www.autoitscript.com/autoit3/docs/functions/RegRead.htm http://www.autoitscript.com/autoit3/docs/functions/RegWrite.htm http://www.autoitscript.com/autoit3/docs/functions/RegDelete.htm -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-20 11:55 Message: Logged In: YES user_id=21627 Originator: NO Can you please elaborate? Where should these functions be defined, what should they do, and when should they be invoked (by what code)? Also, what is a "windows postinstall script"? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1635335&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1642054 ] Python 2.5 gets curses.h warning on HPUX
Bugs item #1642054, was opened at 2007-01-22 19:27 Message generated for change (Comment added) made by roysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1642054&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 gets curses.h warning on HPUX Initial Comment: I downloaded http://www.python.org/ftp/python/2.5/Python-2.5.tgz and tried to build it on "HP-UX glade B.11.11 U 9000/800 unknown". When I ran "./configure", I got warnings that "curses.h: present but cannot be compiled". See attached log file. -- >Comment By: Roy Smith (roysmith) Date: 2007-01-24 16:54 Message: Logged In: YES user_id=390499 Originator: YES OK, looking a bit deeper, the actual error in config.log is: configure:4739: result: no configure:4774: checking for conio.h configure:4781: result: no configure:4658: checking curses.h usability configure:4670: gcc -c -g -O2 conftest.c >&5 In file included from conftest.c:54: /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.2.3/include/curses.h:755: syntax error before "va_list" /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.2.3/include/curses.h:756: syntax error before "va_list" /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.2.3/include/curses.h:757: syntax error before "va_list" /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.2.3/include/curses.h:758: syntax error before "va_list" Adding "#include " appears to solve the problem. I'm pretty weak (major understatement) on building configure scripts, but if you create a new one with varargs.h, I'll be happy to test it on my box for you. -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-24 15:20 Message: Logged In: YES user_id=11375 Originator: NO You'll have to help us some more. This is apparently happening because HP-UX's curses.h file needs some other header file to be included first; not having an HP-UX machine, I have no way to figure out which other header file is needed. Could you please try to figure out which file is necessary? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1642054&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1643943 ] strptime %U broken
Bugs item #1643943, was opened at 2007-01-24 23:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643943&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brian Nahas (bnahas)
Assigned to: Nobody/Anonymous (nobody)
Summary: strptime %U broken
Initial Comment:
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from time import strptime
>>> strptime('2006-53-0', '%Y-%U-%w')
(2006, 12, 31, 0, 0, 0, 6, 365, -1)
>>> strptime('2007-00-0', '%Y-%U-%w')
(2006, 12, 24, 0, 0, 0, 6, -7, -1)
>>> strptime('2007-01-0', '%Y-%U-%w')
(2007, 1, 7, 0, 0, 0, 6, 7, -1)
>>> strptime('2007-02-0', '%Y-%U-%w')
(2007, 1, 7, 0, 0, 0, 6, 7, -1)
>>> strptime('2007-03-0', '%Y-%U-%w')
(2007, 1, 14, 0, 0, 0, 6, 14, -1)
>>>
Note that in the above test, Sunday of week 1 and week 2 for 2007 reported the
date as 2007-01-07 and Sunday of week 0 was reported as 2006-12-24, not
2006-12-31. I'm not sure exactly what is correct, but the inconsistencies are
bothersome.
Same results on:
Python 2.4.4c1 (#70, Oct 11 2006, 10:59:14) [MSC v.1310 32 bit (Intel)] on win32
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1643943&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1637120 ] Python 2.5 fails to build on AIX 5.3 (xlc_r compiler)
Bugs item #1637120, was opened at 2007-01-16 18:06
Message generated for change (Comment added) made by oirraza
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637120&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Orlando Irrazabal (oirraza)
Assigned to: Thomas Heller (theller)
Summary: Python 2.5 fails to build on AIX 5.3 (xlc_r compiler)
Initial Comment:
Initial Comment:
Build of Python 2.5 on AIX 5.3 with xlc_r fails with the below error message.
The configure line is:
./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" --disable-ipv6
AR="ar -X64"
[...]
building '_ctypes' extension
xlc_r -q64 -DNDEBUG -O -I. -I/sw_install/python-2.5/./Include
-Ibuild/temp.aix-5.3-2.5/libffi/include -Ibuild/temp.aix-5.3-2.5/libffi
-I/sw_install/python-2.5/Modules/_ctypes/libffi/src -I./Include -I.
-I/sw_install/python-2.5/Include -I/sw_install/python-2.5 -c
/sw_install/python-2.5/Modules/_ctypes/_ctypes.c -o
build/temp.aix-5.3-2.5/sw_install/python-2.5/Modules/_ctypes/_ctypes.o
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 221.3: 1506-166 (S)
Definition of function ffi_closure requires parentheses.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 221.15: 1506-276 (S) Syntax
error: possible missing '{'?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 248.3: 1506-273 (E) Missing
type in declaration of ffi_raw_closure.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.38: 1506-275 (S)
Unexpected text '*' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 252.23: 1506-276 (S) Syntax
error: possible missing identifier?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.1: 1506-033 (S)
Function ffi_prep_raw_closure is not valid. Function cannot return a function.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.1: 1506-282 (S) The
type of the parameters must be specified in a prototype.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 254.23: 1506-275 (S)
Unexpected text 'void' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 254.38: 1506-275 (S)
Unexpected text ')' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.43: 1506-275 (S)
Unexpected text '*' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 258.28: 1506-276 (S) Syntax
error: possible missing identifier?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.1: 1506-033 (S)
Function ffi_prep_java_raw_closure is not valid. Function cannot return a
function.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.1: 1506-282 (S) The
type of the parameters must be specified in a prototype.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 260.28: 1506-275 (S)
Unexpected text 'void' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 260.43: 1506-275 (S)
Unexpected text ')' encountered.
"/sw_install/python-2.5/Modules/_ctypes/ctypes.h", line 71.9: 1506-046 (S)
Syntax error.
"/sw_install/python-2.5/Modules/_ctypes/ctypes.h", line 77.26: 1506-195 (S)
Integral constant expression with a value greater than zero is required.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 2804.31: 1506-068 (E)
Operation between types "void*" and "int(*)(void)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 3357.28: 1506-280 (E)
Function argument assignment between types "int(*)(void)" and "void*" is not
allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 3417.42: 1506-022 (S)
"pcl" is not a member of "struct {...}".
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4749.67: 1506-280 (E)
Function argument assignment between types "void*" and "void*(*)(void*,const
void*,unsigned long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4750.66: 1506-280 (E)
Function argument assignment between types "void*" and
"void*(*)(void*,int,unsigned long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4751.69: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(const char*,long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4752.64: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(void*,struct _object*,struct _object*)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4754.70: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(const unsigned int*,int)" is not allowed.
building '_ctypes_test' extension
xlc_r -q64 -DNDEBUG -O -I. -I/sw_install/python-2.5/./Include -I./Include -I.
-I/sw_install/python-2.5/Include -I/sw_install/python-2.5 -c
/sw_install/python-2.5/Modules/_ctypes/_ctypes_test.c -o
build/temp.a
[ python-Bugs-1637120 ] Python 2.5 fails to build on AIX 5.3 (xlc_r compiler)
Bugs item #1637120, was opened at 2007-01-16 22:06
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637120&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Orlando Irrazabal (oirraza)
Assigned to: Thomas Heller (theller)
Summary: Python 2.5 fails to build on AIX 5.3 (xlc_r compiler)
Initial Comment:
Initial Comment:
Build of Python 2.5 on AIX 5.3 with xlc_r fails with the below error message.
The configure line is:
./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" --disable-ipv6
AR="ar -X64"
[...]
building '_ctypes' extension
xlc_r -q64 -DNDEBUG -O -I. -I/sw_install/python-2.5/./Include
-Ibuild/temp.aix-5.3-2.5/libffi/include -Ibuild/temp.aix-5.3-2.5/libffi
-I/sw_install/python-2.5/Modules/_ctypes/libffi/src -I./Include -I.
-I/sw_install/python-2.5/Include -I/sw_install/python-2.5 -c
/sw_install/python-2.5/Modules/_ctypes/_ctypes.c -o
build/temp.aix-5.3-2.5/sw_install/python-2.5/Modules/_ctypes/_ctypes.o
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 221.3: 1506-166 (S)
Definition of function ffi_closure requires parentheses.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 221.15: 1506-276 (S) Syntax
error: possible missing '{'?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 248.3: 1506-273 (E) Missing
type in declaration of ffi_raw_closure.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.38: 1506-275 (S)
Unexpected text '*' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 252.23: 1506-276 (S) Syntax
error: possible missing identifier?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.1: 1506-033 (S)
Function ffi_prep_raw_closure is not valid. Function cannot return a function.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 251.1: 1506-282 (S) The
type of the parameters must be specified in a prototype.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 254.23: 1506-275 (S)
Unexpected text 'void' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 254.38: 1506-275 (S)
Unexpected text ')' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.43: 1506-275 (S)
Unexpected text '*' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 258.28: 1506-276 (S) Syntax
error: possible missing identifier?
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.1: 1506-033 (S)
Function ffi_prep_java_raw_closure is not valid. Function cannot return a
function.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 257.1: 1506-282 (S) The
type of the parameters must be specified in a prototype.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 260.28: 1506-275 (S)
Unexpected text 'void' encountered.
"build/temp.aix-5.3-2.5/libffi/include/ffi.h", line 260.43: 1506-275 (S)
Unexpected text ')' encountered.
"/sw_install/python-2.5/Modules/_ctypes/ctypes.h", line 71.9: 1506-046 (S)
Syntax error.
"/sw_install/python-2.5/Modules/_ctypes/ctypes.h", line 77.26: 1506-195 (S)
Integral constant expression with a value greater than zero is required.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 2804.31: 1506-068 (E)
Operation between types "void*" and "int(*)(void)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 3357.28: 1506-280 (E)
Function argument assignment between types "int(*)(void)" and "void*" is not
allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 3417.42: 1506-022 (S)
"pcl" is not a member of "struct {...}".
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4749.67: 1506-280 (E)
Function argument assignment between types "void*" and "void*(*)(void*,const
void*,unsigned long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4750.66: 1506-280 (E)
Function argument assignment between types "void*" and
"void*(*)(void*,int,unsigned long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4751.69: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(const char*,long)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4752.64: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(void*,struct _object*,struct _object*)" is not allowed.
"/sw_install/python-2.5/Modules/_ctypes/_ctypes.c", line 4754.70: 1506-280 (E)
Function argument assignment between types "void*" and "struct
_object*(*)(const unsigned int*,int)" is not allowed.
building '_ctypes_test' extension
xlc_r -q64 -DNDEBUG -O -I. -I/sw_install/python-2.5/./Include -I./Include -I.
-I/sw_install/python-2.5/Include -I/sw_install/python-2.5 -c
/sw_install/python-2.5/Modules/_ctypes/_ctypes_test.c -o
build/temp.ai
