[ python-Bugs-1498051 ] MSVC compiler problems with .NET v2.0
Bugs item #1498051, was opened at 2006-05-31 11:15
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=1498051&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Retief Gerber (hrgerber)
Assigned to: Nobody/Anonymous (nobody)
Summary: MSVC compiler problems with .NET v2.0
Initial Comment:
There is a problem with msvccompiler.py that does not
allow it to work with MS Visual Studio 2005 and .NET
v2.0
msvccompiler.py
__revision__ = "$Id: msvccompiler.py,v 1.64.2.4
2005/08/07 20:50:37 loewis Exp $"
from line 128
if version > 7.0:
self.set_macro("FrameworkSDKDir",
net, "sdkinstallrootv1.1")
else:
self.set_macro("FrameworkSDKDir",
net, "sdkinstallroot")
should be replaced with
if version == 7.1:
self.set_macro("FrameworkSDKDir",
net, "sdkinstallrootv2.0")
elif version > 7.0:
self.set_macro("FrameworkSDKDir",
net, "sdkinstallrootv1.1")
else:
self.set_macro("FrameworkSDKDir",
net, "sdkinstallroot")
I dont have must dev experience on distutils, so this
might not be the best solution
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498051&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1498146 ] optparse does not hande unicode help strings
Bugs item #1498146, was opened at 2006-05-31 13:52 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=1498146&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Cato Amundsen (tomcato) Assigned to: M.-A. Lemburg (lemburg) Summary: optparse does not hande unicode help strings Initial Comment: Unicode strings with non-ascii chars in generate a UnicodeEncodeError File "/usr/lib/python2.3/optparse.py", line 1370, in print_help file.write(self.format_help()) UnicodeEncodeError: 'ascii' codec can't encode characters in position 200-202: +ordinal not in range(128) I'm subclassing OptionParser and adds the following method to get it to work. Should something like this be done for python 2.5? def print_help(self, file=None): if file is None: file = sys.stdout file.write(self.format_help().encode(file.encoding, 'replace')) Tom Cato -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1498146 ] optparse does not hande unicode help strings
Bugs item #1498146, was opened at 2006-05-31 13:52 Message generated for change (Settings changed) made by tomcato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tom Cato Amundsen (tomcato) >Assigned to: Nobody/Anonymous (nobody) Summary: optparse does not hande unicode help strings Initial Comment: Unicode strings with non-ascii chars in generate a UnicodeEncodeError File "/usr/lib/python2.3/optparse.py", line 1370, in print_help file.write(self.format_help()) UnicodeEncodeError: 'ascii' codec can't encode characters in position 200-202: +ordinal not in range(128) I'm subclassing OptionParser and adds the following method to get it to work. Should something like this be done for python 2.5? def print_help(self, file=None): if file is None: file = sys.stdout file.write(self.format_help().encode(file.encoding, 'replace')) Tom Cato -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498146&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1473048 ] SimpleXMLRPCServer responds to any path
Bugs item #1473048, was opened at 2006-04-19 11:45 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473048&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: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: A.M. Kuchling (akuchling) >Assigned to: A.M. Kuchling (akuchling) Summary: SimpleXMLRPCServer responds to any path Initial Comment: SimpleXMLRPCServer and DocXMLRPCServer don't look at the path of the HTTP request at all; you can POST or GET from / or /RPC2 or /blahblahblah with the same results. One minor problem with this liberality is that a security scanner that looks for vulnerable scripts such as /cgi-bin/phf will report the server as vulnerable. Nessus, for example, reports dozens of security holes on a SimpleXMLRPCServer for this reason. Fix: add a check that only allows '/' or '/RPC2' (maybe just /RPC2?). -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 10:13 Message: Logged In: YES user_id=11375 I've applied this patch in rev. 46578. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-04-26 08:42 Message: Logged In: YES user_id=11375 The attached patch adds a .rpc_paths attribute that's a tuple of legal paths, and a .is_rpc_path_valid() method that returns True if a path is OK. A .report_404() method generates a 404 error message, and SimpleXMLRPCServer and DocXMLRPCServer are modified to check for legal paths. (Perhaps it should be ._report_404?) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473048&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1484556 ] Output of KlocWork on Python2.4.3 sources
Bugs item #1484556, was opened at 2006-05-09 06:14 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&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 Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Output of KlocWork on Python2.4.3 sources Initial Comment: We're evaluating KlocWork (http://www.klocwork.com), I've ran it on the source of Python 2.4.3 and the output is attached (1562 warnings). -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 10:26 Message: Logged In: YES user_id=11375 The Coverity scans also probably report some of the same bugs, so many of these problems may be fixed in the 2.5 trunk. If you're still evaluating, you could try running the tool on the 2.5 trunk (snapshot available from http://svn.python.org/snapshots/) and see if the results are shorter. -- Comment By: Martin v. Löwis (loewis) Date: 2006-05-10 00:45 Message: Logged In: YES user_id=21627 Thanks for these results. Unfortunately, they seem to contain many false positives, so it is unclear how one should proceed with them. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484556&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Bugs item #1494314, was opened at 2006-05-24 09:51 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Smith (mlrsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 14:39 Message: Logged In: YES user_id=11375 I expect such a patch would be acceptable. The largest issue is probably whether poll() is available everywhere, or if we'd be stuck maintaining both select() and poll() based versions of internal_select(). Does Windows support poll() at all? -- Comment By: Michael Smith (mlrsmith) Date: 2006-05-29 10:13 Message: Logged In: YES user_id=1488997 Yes, I had my ulimit set appropriately. There's no problem with _opening_ many sockets (at least, I don't think there is) - the problem is with trying to do something (like call socket.recv()) with them. The code in socketmodule.c is pretty clear - and having upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this. For now, we're having to keep all our production machines on 2.4.2. -- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 10:11 Message: Logged In: YES user_id=956757 Please disregard my comments completely- just opening more than 1024 files does not trigger this bug, but doing a socket.send() on the 1025th socket does. -- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 10:00 Message: Logged In: YES user_id=956757 Never mind- you already tried ulimit. It still works for me though, 2.4.3 from Ubuntu Dapper. -- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 09:57 Message: Logged In: YES user_id=956757 Try "ulimit -n 8096" (only permitted in a root shell) to set your max socket usage to something larger. Opening more than 1024 sockets works for me in python 2.4.3 after changing the limit for the terminal in question and restarting the interpreter. Just ulimit -n will show you your current limit. Ulimits are enforced by the Linux kernel and can likely be configured system-wide in /etc/sysctl.cfg. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Bugs item #1494314, was opened at 2006-05-24 15:51 Message generated for change (Comment added) made by mlrsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Smith (mlrsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike -- >Comment By: Michael Smith (mlrsmith) Date: 2006-05-31 23:39 Message: Logged In: YES user_id=1488997 That, of course, is the problem - select() is available more or less universally, but poll() is not. However, it's not terribly difficult to write a poll() wrapper using select(), though doing so in general would have serious performance issues (the specific uses in socketmodule.c do not hit this problem), and retains the limitations of select. It's not clear that the complexity of doing this is worthwhile compared to just implementing the simple API needed internally to socketmodule.c using both APIs (i.e. just adding a poll() option). Regardless, it'd be nice if at least the basic fix I wrote up went in - it solves the immediate problem, at least. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 20:39 Message: Logged In: YES user_id=11375 I expect such a patch would be acceptable. The largest issue is probably whether poll() is available everywhere, or if we'd be stuck maintaining both select() and poll() based versions of internal_select(). Does Windows support poll() at all? -- Comment By: Michael Smith (mlrsmith) Date: 2006-05-29 16:13 Message: Logged In: YES user_id=1488997 Yes, I had my ulimit set appropriately. There's no problem with _opening_ many sockets (at least, I don't think there is) - the problem is with trying to do something (like call socket.recv()) with them. The code in socketmodule.c is pretty clear - and having upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this. For now, we're having to keep all our production machines on 2.4.2. -- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 16:11 Message: Logged In: YES user_id=956757 Please disregard my comments completely- just opening more than 1024 files does not trigger this bug, but doing a socket.send() on the 1025th socket does. -- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 16:00 Message: Logged In: YES user_id=956757 Never mind- you already tried ulimit. It still works for me though, 2.4.3 from Ubuntu Dapper. -- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 15:57 Message: Logged In: YES user_id=956757 Try "ulimit -n 8096" (only permitted in a root shell) to set your max socket usage to something larger. Opening more than 1024 sockets works for me in python 2.4.3 after changing the limit for the terminal in question and restarting the interpreter. Just ulimit -n will show you your current limit. Ulimits are enforced by the Linux kernel and can likely be configured system-wide in /etc/sysctl.cfg. -- You can respond by visiting: https://source
[ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Bugs item #1494314, was opened at 2006-05-24 09:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Smith (mlrsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike -- >Comment By: Tim Peters (tim_one) Date: 2006-05-31 18:27 Message: Logged In: YES user_id=31435 akuchling: No, poll() is not part of the Windows socket API. -- Comment By: Michael Smith (mlrsmith) Date: 2006-05-31 17:39 Message: Logged In: YES user_id=1488997 That, of course, is the problem - select() is available more or less universally, but poll() is not. However, it's not terribly difficult to write a poll() wrapper using select(), though doing so in general would have serious performance issues (the specific uses in socketmodule.c do not hit this problem), and retains the limitations of select. It's not clear that the complexity of doing this is worthwhile compared to just implementing the simple API needed internally to socketmodule.c using both APIs (i.e. just adding a poll() option). Regardless, it'd be nice if at least the basic fix I wrote up went in - it solves the immediate problem, at least. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 14:39 Message: Logged In: YES user_id=11375 I expect such a patch would be acceptable. The largest issue is probably whether poll() is available everywhere, or if we'd be stuck maintaining both select() and poll() based versions of internal_select(). Does Windows support poll() at all? -- Comment By: Michael Smith (mlrsmith) Date: 2006-05-29 10:13 Message: Logged In: YES user_id=1488997 Yes, I had my ulimit set appropriately. There's no problem with _opening_ many sockets (at least, I don't think there is) - the problem is with trying to do something (like call socket.recv()) with them. The code in socketmodule.c is pretty clear - and having upgraded to 2.4.3 with ubuntu dapper, I _am_ running into this. For now, we're having to keep all our production machines on 2.4.2. -- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 10:11 Message: Logged In: YES user_id=956757 Please disregard my comments completely- just opening more than 1024 files does not trigger this bug, but doing a socket.send() on the 1025th socket does. -- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 10:00 Message: Logged In: YES user_id=956757 Never mind- you already tried ulimit. It still works for me though, 2.4.3 from Ubuntu Dapper. -- Comment By: Gabriel Wicke (gabrielwicke) Date: 2006-05-29 09:57 Message: Logged In: YES user_id=956757 Try "ulimit -n 8096" (only permitted in a root shell) to set your max socket usage to something larger. Opening more than 1024 sockets works for me in python 2.4.3 after changing the limit for the terminal in question and restarting the interpreter. Just ulimit -n will show you your cur
[ python-Bugs-1498638 ] tp_alloc for subtypes of PyComplex_Type is not called
Bugs item #1498638, was opened at 2006-05-31 22:24
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=1498638&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 Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Travis Oliphant (teoliphant)
Assigned to: Nobody/Anonymous (nobody)
Summary: tp_alloc for subtypes of PyComplex_Type is not called
Initial Comment:
In the function complex_subtype_from_c_complex in the
file complexobject.c, the allocation routine for the
subtype is not called. This causes memory management
problems if the sub-type does not use the Python memory
manager.
The fix is to make the following change:
{
PyObject *op;
- op = PyType_GenericAlloc(type, 0);
+ op = type->tp_alloc(type, 0);
if (op != NULL)
((PyComplexObject *)op)->cval = cval;
return op;
Attched is an example module and script illustrating
what can go wrong along with a patch.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1498638&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1496032 ] test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha
Bugs item #1496032, was opened at 2006-05-27 08:21
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496032&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 Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha
Initial Comment:
Program received signal SIGFPE, Arithmetic exception.
0x000160418568 in bu_double (p=0x12049d29c "", f=0x0) at /
house/etrepum/src/python-46462/Modules/_struct.c:219
(this is actually due to _PyFloat_Unpack8)
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-31 23:02
Message:
Logged In: YES
user_id=33168
Try adding the -mieee flag when compiling. That should fix
the problem. It looks like we only set this for OSF
platforms. It should probably be set for all Alpha platforms.
See:
http://mail.python.org/pipermail/python-dev/2006-March/063219.html
--
Comment By: Bob Ippolito (etrepum)
Date: 2006-05-27 09:12
Message:
Logged In: YES
user_id=139309
More fun in test_long
Program received signal SIGFPE, Arithmetic exception.
0x00012003972c in float_richcompare (v=0x120397080,
w=0x1203e7a00, op=2) at ../Objects/floatobject.c:387
387 else if (!Py_IS_FINITE(i)) {
--
Comment By: Bob Ippolito (etrepum)
Date: 2006-05-27 09:12
Message:
Logged In: YES
user_id=139309
More fun in test_long
Program received signal SIGFPE, Arithmetic exception.
0x00012003972c in float_richcompare (v=0x120397080,
w=0x1203e7a00, op=2) at ../Objects/floatobject.c:387
387 else if (!Py_IS_FINITE(i)) {
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496032&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
