[ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0
Bugs item #1105699, was opened at 2005-01-20 00:52 Message generated for change (Comment added) made by rjk1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings in Python.h with gcc 4.0.0 Initial Comment: (this happens for every file that includes Python.h) In file included from ../Include/Python.h:55, from ../Objects/intobject.c:4: ../Include/pyport.h:396: warning: 'struct winsize' declared inside parameter list ../Include/pyport.h:397: warning: 'struct winsize' declared inside parameter list The source lines look like this: extern int openpty(int *, int *, char *, struct termios *, struct winsize *); extern int forkpty(int *, char *, struct termios *, struct winsize *); -- Comment By: Richard Kettlewell (rjk1002) Date: 2005-01-31 15:43 Message: Logged In: YES user_id=217390 C does guarantee that all struct pointers share the same *representation* (section 6.2.5 of C99). That's not what the compiler is complaining about here. Rather, a struct declared inside a parameter list is restricted in scope to that parameter list, and so is not the same structure as one declared outside it, even if the tag is the same. The solution is to forward-declare the struct (as an incomplete type, i.e. just "struct winsize;") before any of the declarations that use it. Then the struct tag will mean the same thing in every scope. -- Comment By: Tim Peters (tim_one) Date: 2005-01-20 23:13 Message: Logged In: YES user_id=31435 The warning almost certainly means that there's no declaration of struct winsize in scope when these externs are declared. That's bad, because C doesn't guarantee that all pointers are the same size (although they are on all Python platforms I'm aware of). Some quality time with Google suggested that other projects wormed around this by #include'ing instead of , because the former but not the latter #include's where the winsize struct was defined. Beats me -- ain't a Windows problem . -- Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 22:49 Message: Logged In: YES user_id=139309 Beats me, it's probably just "bad style". It's a problem because it shows up a lot in the output, so we should at least figure out how to disable this warning so that it doesn't become annoying. -- Comment By: Michael Hudson (mwh) Date: 2005-01-20 15:18 Message: Logged In: YES user_id=6656 Why is this a problem? Is it not valid C or something? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1113244 ] Please add do-while guard to Py_DECREF etc.
Bugs item #1113244, was opened at 2005-01-31 16:01 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=1113244&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Kettlewell (rjk1002) Assigned to: Nobody/Anonymous (nobody) Summary: Please add do-while guard to Py_DECREF etc. Initial Comment: Py_DECREF() is missing do-while macro guards (as found e.g. in Py_CLEAR), instead relying on being an if-else to avoid the usual problems associated with such macros. However if it is used as e.g. "if (newref) Py_DECREF(obj);" then gcc -Wall still complains about an ambiguous else clause. (gcc version is 3.3.5) Granted it is only a warning but like many people we build with -Werror, and the code in question is in SWIG output rather than our own code, so this is quite painful for us. At least Py_DECREF, Py_XDECREF and Py_XINCREF need fixing; I've not checked beyond this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1108992 ] idle freezes when run over ssh
Bugs item #1108992, was opened at 2005-01-25 10:44 Message generated for change (Comment added) made by mgpoolman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark -- >Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 16:27 Message: Logged In: YES user_id=993923 1 - OK It's not ssh it's ubuntu. 2 - I'll try this with ububtu. ...And by frozen, I assume ... All Idle windows are unresponsive to screen and kbd events. -- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 06:26 Message: Logged In: YES user_id=149084 Please try two things: 1. Run IDLE directly on the ubuntu machine long enough to assure there is no problem standalone. 2. Run IDLE on the xclient but start it with the -n switch so it runs without the subprocess. When IDLE freezes, walk over to the server and kill the subprocess. It should restart itself. Is the system still frozen? And by frozen, I assume you mean all screen and keyboard events are unresponsive. -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 20:06 Message: Logged In: YES user_id=993923 Yes, I've used Idle on that (although only ~ 1 hour) and not seen the problem there. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-30 19:43 Message: Logged In: YES user_id=341410 Do you have physical access to the ubuntu warty machine, and if so, does Idle run very well locally on that machine, not X forwarded? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 17:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 20:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 09:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1108992 ] idle freezes when run over ssh
Bugs item #1108992, was opened at 2005-01-25 10:44 Message generated for change (Comment added) made by mgpoolman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark -- >Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 16:46 Message: Logged In: YES user_id=993923 2 - erm forgive me for sounding stupid, but with the -n switch I see no sub-process, only the Idle process. It still freezes though, and killing it just kills it. -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 16:27 Message: Logged In: YES user_id=993923 1 - OK It's not ssh it's ubuntu. 2 - I'll try this with ububtu. ...And by frozen, I assume ... All Idle windows are unresponsive to screen and kbd events. -- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 06:26 Message: Logged In: YES user_id=149084 Please try two things: 1. Run IDLE directly on the ubuntu machine long enough to assure there is no problem standalone. 2. Run IDLE on the xclient but start it with the -n switch so it runs without the subprocess. When IDLE freezes, walk over to the server and kill the subprocess. It should restart itself. Is the system still frozen? And by frozen, I assume you mean all screen and keyboard events are unresponsive. -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 20:06 Message: Logged In: YES user_id=993923 Yes, I've used Idle on that (although only ~ 1 hour) and not seen the problem there. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-30 19:43 Message: Logged In: YES user_id=341410 Do you have physical access to the ubuntu warty machine, and if so, does Idle run very well locally on that machine, not X forwarded? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 17:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 20:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 09:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault
Bugs item #1077106, was opened at 2004-12-01 21:40 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Michael Hudson (mwh) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault [EMAIL PROTECTED]:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. -- >Comment By: Michael Hudson (mwh) Date: 2005-01-31 17:12 Message: Logged In: YES user_id=6656 Finally fixed this (odd definition of "tomorrow", I know...) Misc/NEWS revision 1.1236 Objects/stringobject.py revision 2.227 Modules/posixmodule.c revision 2.333 Sorry for the wait... -- Comment By: Michael Hudson (mwh) Date: 2004-12-05 10:30 Message: Logged In: YES user_id=6656 I'm waiting until I'm not behind a modem at my parents' house :) Tomorrow. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-05 00:39 Message: Logged In: YES user_id=80475 No, I simply tried the OP's example and reported its behavior on my system. If you don't want to create a new test file, try adding this on to test_subprocess. Yes, I read the patch. Yes, I forgot you added the assertion already. So are you going commit or wait for an engraved invitation? -- Comment By: Michael Hudson (mwh) Date: 2004-12-04 21:11 Message: Logged In: YES user_id=6656 Hmm. Did you try a debug build and/or a range of arguments? Is os.read actually tested anywhere? I can't find any... > Also, you could prevent/detect future errors by adding an > assertion (checking for negative arguments) to > PyString_FromStringAndSize(). Did you read the patch? -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 20:58 Message: Logged In: YES user_id=80475 No doubt it is a clear bug. My note was just a data point. Had I been able to reproduce the error on my machine, I would have been able to make a test_case and checkin a fix. So, please, if you can demonstrate the error, go ahead and check-in a fix with a testcase. The OSError is probably fine though there is an alternative of having a ValueError raised immediately after the args are parsed in the read() method. Also, you could prevent/detect future errors by adding an assertion (checking for negative arguments) to PyString_FromStringAndSize(). -- Comment By: Michael Hudson (mwh) Date: 2004-12-04 20:38 Message: Logged In: YES user_id=6656 I'm surprised at all this discussion. It's a clear bug. The only question is what the error message should be. The attached makes it OSError: [Errno 22] Invalid argument which seems most faithful to what the read() syscall does. -- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 20:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. -- Comment By: George Yoshida (quiver) Date: 2004-12-04 11:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. Th
[ python-Bugs-1113328 ] OSATerminology still semi-broken
Bugs item #1113328, was opened at 2005-01-31 17:53 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=1113328&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: has (hhas) Assigned to: Jack Jansen (jackjansen) Summary: OSATerminology still semi-broken Initial Comment: OSATerminology.GetSysTerminology() is broken as it calls OSAGetAppTerminology instead of OSAGetSysTerminology. Attached diff fixes this bug, and additionally patches both functions to ignore any modeFlags arguments passed by user as this value should always be kOSAModeNull. Some minor additions and improvements to commenting and docstrings too. Tested and working on Python 2.3.3, OS 10.2.8. See also bug #884085, patch #979784. (Note that this patch supercedes #979784.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113328&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1113484 ] document {m} regex matcher wrt empty matches
Bugs item #1113484, was opened at 2005-01-31 22:46
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=1113484&group_id=5470
Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Wummel (calvin)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: document {m} regex matcher wrt empty matches
Initial Comment:
The {m} matcher seems not to be applicable to (some)
empty matches. For example this will raise a regex
compile error:
>>> re.compile("(a*){4}")
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/sre.py", line 179, in compile
return _compile(pattern, flags)
File "/usr/lib/python2.3/sre.py", line 230, in _compile
raise error, v # invalid expression
sre_constants.error: nothing to repeat
However this matcher is compiled without error:
>>> re.compile("(\ba*){4}")
<_sre.SRE_Pattern object at 0xb7f86c58>
I don't know why the first example gives an error, but
it should perhaps be mentioned in the documentation
about the {} regex operator.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113484&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1108992 ] idle freezes when run over ssh
Bugs item #1108992, was opened at 2005-01-25 05:44 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Poolman (mgpoolman) Assigned to: Nobody/Anonymous (nobody) Summary: idle freezes when run over ssh Initial Comment: Python 2.3.4 (#2, Aug 13 2004, 00:36:58) [GCC 3.3.4 (Debian 1:3.3.4-5ubuntu2)] on linux2 IDLE 1.0.3 When running idle over an ssh link, idle freezes after an unpredictable length of time. Over 3 days the longest it has stayed allive for is ~4hrs, but a few minutes before freezing is the norm. Niether idle nor python are consuming cpu time once frozen. I can find no definete recipie to bring about the freeze, although (I think) there has always been at least one editor window open when it happens. There is no output on stderr, or other diagnostics that I can see. ssh server(ubuntu warty): OpenSSH_3.8.1p1 Debian 1:3.8.1p1-11ubuntu3.1, OpenSSL 0.9.7d 17 Mar 2004 ssh client (RH9): OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f /best/* Mark -- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 21:01 Message: Logged In: YES user_id=149084 Right, there is no subprocess when you use the -n switch. It causes IDLE to run like IDLE 0.8. So if I follow correctly, IDLE -n freezes on your ubuntu box without using ssh tunneling. I suspect a hardware problem with that system. Are you starting IDLE on the ubuntu box from the command line? If so, are there any messages left in the command line window? How much memory does the ubuntu box have? Does 'top' show increasing memory requirement for the IDLE -n process? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 11:46 Message: Logged In: YES user_id=993923 2 - erm forgive me for sounding stupid, but with the -n switch I see no sub-process, only the Idle process. It still freezes though, and killing it just kills it. -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-31 11:27 Message: Logged In: YES user_id=993923 1 - OK It's not ssh it's ubuntu. 2 - I'll try this with ububtu. ...And by frozen, I assume ... All Idle windows are unresponsive to screen and kbd events. -- Comment By: Kurt B. Kaiser (kbk) Date: 2005-01-31 01:26 Message: Logged In: YES user_id=149084 Please try two things: 1. Run IDLE directly on the ubuntu machine long enough to assure there is no problem standalone. 2. Run IDLE on the xclient but start it with the -n switch so it runs without the subprocess. When IDLE freezes, walk over to the server and kill the subprocess. It should restart itself. Is the system still frozen? And by frozen, I assume you mean all screen and keyboard events are unresponsive. -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 15:06 Message: Logged In: YES user_id=993923 Yes, I've used Idle on that (although only ~ 1 hour) and not seen the problem there. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-30 14:43 Message: Logged In: YES user_id=341410 Do you have physical access to the ubuntu warty machine, and if so, does Idle run very well locally on that machine, not X forwarded? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-30 12:02 Message: Logged In: YES user_id=993923 Yes, exactly. I'm pretty sure it's not an X/ssh/network problem, everything else works fine (including Idle 0.8). Mark -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-01-29 15:23 Message: Logged In: YES user_id=341410 It has been a while since I ran Idle, but I am curious as to what you mean by "run over ssh". Do you mean that you have an SSH tunnel to a remote machine, which forwards X-Windows sessions, and when running Idle over this, it locks up? -- Comment By: Mark Poolman (mgpoolman) Date: 2005-01-26 04:15 Message: Logged In: YES user_id=993923 PS - You don't need an editor window open to get the freeze. M -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108992&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-arc
[ python-Bugs-1113244 ] Please add do-while guard to Py_DECREF etc.
Bugs item #1113244, was opened at 2005-01-31 11:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Kettlewell (rjk1002) >Assigned to: Tim Peters (tim_one) Summary: Please add do-while guard to Py_DECREF etc. Initial Comment: Py_DECREF() is missing do-while macro guards (as found e.g. in Py_CLEAR), instead relying on being an if-else to avoid the usual problems associated with such macros. However if it is used as e.g. "if (newref) Py_DECREF(obj);" then gcc -Wall still complains about an ambiguous else clause. (gcc version is 3.3.5) Granted it is only a warning but like many people we build with -Werror, and the code in question is in SWIG output rather than our own code, so this is quite painful for us. At least Py_DECREF, Py_XDECREF and Py_XINCREF need fixing; I've not checked beyond this. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-31 21:53 Message: Logged In: YES user_id=80475 Tim, what you think about doing this with a conditional compile to only redefine for GCC? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1113244&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1100368 ] Wrong "type()" syntax in docs
Bugs item #1100368, was opened at 2005-01-11 14:03 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) >Assigned to: Raymond Hettinger (rhettinger) Summary: Wrong "type()" syntax in docs Initial Comment: >From the current docs: type(object): Return the type of an object. The return value is a type object. >From the interpreter: >>> help(type) Help on class type in module __builtin__: class type(object) | type(object) -> the object's type | type(name, bases, dict) -> a new type In the documentation is missing the second syntax form. -- Comment By: Michael Chermside (mcherm) Date: 2005-01-25 16:31 Message: Logged In: YES user_id=99874 cjwhrh's comment doesn't seem relevent. It is generally true of ALL builtins that they can be shadowed by local variables. Facundo is probably right that the newer use of type() should be documented. -- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-18 17:03 Message: Logged In: YES user_id=285587 The accuracy of the above depends partly on the context. Within a function or method which has "type" as a parameter the type function described above is no longer accessible. Colin W. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1100368&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1109523 ] Time module missing from latest module index
Bugs item #1109523, was opened at 2005-01-25 20:20 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109523&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Time module missing from latest module index Initial Comment: There is no time module listed here: http://www.python.org/dev/doc/devel/modindex.html and fabricating a likely URL 404s. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-31 22:03 Message: Logged In: YES user_id=80475 Hmm, I see a time module (just after threading) and it successfully points to http://www.python.org/dev/doc/devel/lib/module-time.html . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109523&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1109523 ] Time module missing from latest module index
Bugs item #1109523, was opened at 2005-01-25 19:20 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109523&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Time module missing from latest module index Initial Comment: There is no time module listed here: http://www.python.org/dev/doc/devel/modindex.html and fabricating a likely URL 404s. -- >Comment By: Skip Montanaro (montanaro) Date: 2005-01-31 21:36 Message: Logged In: YES user_id=44345 I sent a message to the doc sig about it a couple weeks ago. After not getting a response for awhile I submitted this report. Fred fixed the problem but probably never noticed the bug report. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-31 21:03 Message: Logged In: YES user_id=80475 Hmm, I see a time module (just after threading) and it successfully points to http://www.python.org/dev/doc/devel/lib/module-time.html . -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1109523&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI
Bugs item #1075984, was opened at 2004-11-30 05:13
Message generated for change (Comment added) made by bos
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory fault pyexpat.so on SGI
Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m
cc -version
MIPSpro Compilers: Version 7.3.1.3m
- make tests passes test_pyexpat without error
- running this code leads to a core dump
-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)
<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)
- running this code from an interactive session leads
not to a coredump
I need some assistance howto provide further debug
information.
--maik./
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-01-31 23:53
Message:
Logged In: YES
user_id=28380
I've been bitten by the same bug. In my case, the problem was with Qt, not GTK.
It's not actually necessary to check the expat version; just see if
XML_ErrorString actually returns anything.
Here's the patch I use for this problem:
--- python/Modules/pyexpat.c2005-01-06 16:26:13 -08:00
+++ python/Modules/pyexpat.c 2005-01-31 23:46:36 -08:00
@@ -1936,9 +1936,12 @@
}
#endif
-#define MYCONST(name) -PyModule_AddStringConstant(errors_module, #name, -
(char*)XML_ErrorString(name))
+#define MYCONST(name) +{ +char *_v =
(char*)XML_ErrorString(name); +if (_v) +
PyModule_AddStringConstant(errors_module, #name, _v); +}
MYCONST(XML_ERROR_NO_MEMORY);
MYCONST(XML_ERROR_SYNTAX);
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 05:46
Message:
Logged In: YES
user_id=471223
pyexpat initializes using its internal copy of expat.
libexpat.so is still mapped in (after pyexpat has
initilized), but gdb finds the python copy of
XML_ErrorString and other functions.
I suspect that this will be a problem if the system version
of expat is newer than Python's.
--
Comment By: Michael Hudson (mwh)
Date: 2004-12-13 05:01
Message:
Logged In: YES
user_id=6656
1) Good sleuthing.
2) Argh!
3) What happens if you import pyexpat before pygtk?
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 01:29
Message:
Logged In: YES
user_id=471223
I've looked at the program that was dumping core and the
sequence is this:
1) Program imports pygtk, which links in the GTK libraries
2) Program loads SVG image which links in librsvg.so which
in turn links in /usr/local/lib/libexpat.so
3) Program imports pyexpat.
4) pyexpat calls XML_ErrorString, but as ld.so has already
linked in XML_ErrorString from /usr/local/lib/libexpat.so it
calls that version, not the one in pyexpat.so.
5) pyexpat looks up an error defined by the later version of
expat it is expecting and gets a NULL pointer from the
earlier version it has. It attempts to use it without
checking (strlen) and dumps core.
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 09:01
Message:
Logged In: YES
user_id=471223
Maybe it compiled against its own copy of expat, but pulled
in the system's copy when run?
--
Comment By: Michael Hudson (mwh)
Date: 2004-12-10 08:52
Message:
Logged In: YES
user_id=6656
Uh, Python includes its own copy of expat, and I really
thought we were supposed to prefer our own version over
anything found on the system...
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-10 08:46
Message:
Logged In: YES
user_id=471223
I also got a core dump imp
