[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes
Bugs item #1311784, was opened at 2005-10-03 12:18 Message generated for change (Comment added) made by pete_icoserve You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter Klotz (pete_icoserve) Assigned to: Nobody/Anonymous (nobody) Summary: python.exe 2.4.2 compiled with VS2005 crashes Initial Comment: The C runtime library shipped with Visual Studio 2005 performs strict checking of parameters. In function initsignal() in file Modules\signalmodule.c, an iteration over all signals from 1 to NSIG is performed. The function PyOS_getsig() is called with each of these integer values. PyOS_getsig() then calls signal() with the given value which leads to the crash. According to signal.h from VS2005 only these signals are allowed: #define SIGINT 2 #define SIGILL 4 #define SIGABRT_COMPAT 6 #define SIGFPE 8 #define SIGSEGV 11 #define SIGTERM 15 #define SIGBREAK21 #define SIGABRT 22 A solution would be to restrict the loop in initsignal() to the above values under Windows. -- >Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-10 07:05 Message: Logged In: YES user_id=299547 Do you really think ignoring/skipping VS2005 is a proper solution? I am currently porting our software to 64Bit Windows (AMD64/EM64T) and the only compiler supporting this is the one included in VS2005. If Python does not support VS2005 everyone needing a 64Bit version of Python is forced to locate and fix this problem on his own. -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-08 09:56 Message: Logged In: YES user_id=21627 Can somebody please study the source of the C runtime of VS2005 (probably needs to be requested specifically during installation), to find out whether more generic solutions are available. Possible solutions include: - don't call signal, but call an alternative function instead which won't cause a crash - set some magic variable, disabling the error checking - fetch the list of supported signals from somewhere (at compile time or at run time), and iterate over that list. Anyway, I don't see the official Python 2.5 release built with VS 2005, so this is a minor issue - I rather expect Python to skip VS 2005, and go right to the version that succeeds it. -- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-04 08:02 Message: Logged In: YES user_id=299547 I would leave the code for pre-VS2005 compilers as is and introduce a specific workaround for VS2005 and all following compilers. Something like this comes to my mind: #if defined (_WIN32) && _MSC_VER >= 1400 ... #endif This works for 32 and 64 bit platforms since _WIN32 is defined in both cases. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 19:54 Message: Logged In: YES user_id=33168 Do you suggest this be special cased for VS2005 specifically or Windows in general (ie, any version/compiler)? -- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-03 18:10 Message: Logged In: YES user_id=299547 VS2005 is still not released. It is scheduled for November 7th 2005. I tested with CTP (Community Technology Preview) August 2005. However I doubt they will change the behavior of their C library at this point of development. -- Comment By: Michael Hudson (mwh) Date: 2005-10-03 13:05 Message: Logged In: YES user_id=6656 Is VS2005 actually out now then? This behaviour violates the C standard, as far as we can tell, so we when VS2005 was in beta we hoped that they would fix it for the final release. If it is released, though, I guess we need to do something like you suggest (along with some colourful comments, I guess). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1175396 ] codecs.readline sometimes removes newline chars
Bugs item #1175396, was opened at 2005-04-02 17:14 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175396&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: Closed Resolution: Fixed Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: codecs.readline sometimes removes newline chars Initial Comment: In Python 2.4.1 i observed a new bug in codecs.readline, it seems that with certain inputs it removes newline characters from the end of the line Probably related to bug #1076985 (Incorrect behaviour of StreamReader.readline leads to crash) and bug #1098990 codec readline() splits lines apart (both with status closed) so I'm assigning this to Walter. See the attached files that demonstrate the problem. Reproduced with Python 2.4.1 on windows XP and on Linux. The problem does not occur with Python 2.4. (btw, it seems bug #1076985 was fixed in python 2.4.1, but the other one (#1098990) not? ) -- Comment By: Irmen de Jong (irmen) Date: 2005-10-10 01:25 Message: Logged In: YES user_id=129426 Confirmed fixed with Python 2.4.2 on mac os x. But the status is still 'open' although resolution is 'fixed'... -- Comment By: Walter Dörwald (doerwalter) Date: 2005-10-09 21:45 Message: Logged In: YES user_id=89016 2.4.2 is out the door, so I'm closing this bug as fixed. -- Comment By: Greg Chapman (glchapman) Date: 2005-07-12 21:53 Message: Logged In: YES user_id=86307 Build 204 of pywin32 has a workaround for bug 1163244 which should also avoid this bug: it leaves out the encoding notation in generated COM wrapper files (so loading will not involve the codecs module). If your wrapper files don't need extended characters (I don't think ADO does), you might want to give that a shot. -- Comment By: Alan Meyer (vrmeyer) Date: 2005-07-12 20:07 Message: Logged In: YES user_id=338015 Hello doerwalter, Our thanks to you and to glchapman for working on this bug. I think the project I am working on may have run into this bug while attempting to use the python COM client wrappers for ADO on Win32. We saw the problem in Python 2.4.1, but not 2.4 or 2.3.5. Do you have any projection for when the fix will make it into the stable distribution? Our production is running on 2.3.5. If it looks like a long while before the fix is distributed, we may upgrade to 2.4.0. Otherwise we'll stick with 2.3.5 and wait. Thanks again. Alan -- Comment By: Walter Dörwald (doerwalter) Date: 2005-05-16 16:20 Message: Logged In: YES user_id=89016 > > 1) How do we handle the problem of a truncated line, if the > > data comes from the charbuffer instead of being read from > > > the stream? > > > > My suggestion is to make the top of the loop look like: > > > > while True: > > havecharbuffer = bool(self.charbuffer) > > > > And then the break condition (when no line break found) > > should be: > > > > # we didn't get anything or this was our only try > > if not data or (size is not None and not havecharbuffer): > > > > (too many negatives in that). Anyway, the idea is that, if > > size specified, there will be at most one read of the > > underlying stream (using the size). So if you enter the > > loop with a charbuffer, and that charbuffer does not have a > > line break, then you redo the loop once (the second time it > > will break, because havecharbuffer will be False). This makes sense. However, with the current state of the tokenizer this might be to dangerous, because the resulting line might be twice as long. So fixing the tokenizer should be the first step. BTW, your patch fixes the problems with the fix for #1178484, so I think I'm going to apply the patch in the next days, if there are no objections. > > Also, not sure about this, but should the size parameter > > default to -1 (to keep it in sync with read)? None seems to be a better default from an API viewpoint, but -1 is better for "C compatibility". > > As to issue 2, it looks like it should be possible to get > > the line number right, because the UnicodeDecodeError > > exception object has all the necessary information in it > > (including the original string). I think this should be > > done by fp_readl (in tokenizer.c). The patch for #1178484 fixes this. Combined with this patch I think we're in good shape. > > By the way, using a findlinebreak function
[ python-Feature Requests-1322308 ] itemgetter built-in?
Feature Requests item #1322308, was opened at 2005-10-10 04:56 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=1322308&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: capnSTABN (capnstabn) Assigned to: Nobody/Anonymous (nobody) Summary: itemgetter built-in? Initial Comment: uhm... operator.itemgetter() is useful and all, but fairly retarded looking for how simple it is basically what i am wrestling with at the moment is doing some regular expressions without completely ganking the crap out of the code to make it work, since every freakin thing in re returns None all over the bloody place like regular expressions were hitting a ragging pinata with a chainsaw after a LOT of muckymuck, basically six hours straight, the simplest non-conditional form i could come up with was this: http://42.vg/81691"; target="_new">http://42.vg/81691 http://42.vg/81691 any comments would be leet! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1322308&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1315961 ] inspect.getsourcelines() broken
Bugs item #1315961, was opened at 2005-10-07 18:33 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1315961&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: Closed >Resolution: Duplicate Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getsourcelines() broken Initial Comment: inspect.getsourcelines() in Python 2.4.2 breaks when parsing the attached buggy.py although the indentation level are OK: >>> import inspect, buggy >>> inspect.getsourcelines(buggy.title) This gives a "IndentationError: unindent does not match any outer indentation level" -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-10-10 14:28 Message: Logged In: YES user_id=89016 Closing this bug report as it is a duplicate of #1224621. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1315961&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1321736 ] Missing Library Modules
Bugs item #1321736, was opened at 2005-10-09 21:17 Message generated for change (Comment added) made by georgel377 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1321736&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: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George LeCompte (georgel377) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Library Modules Initial Comment: downloaded python-2.4.2 under redhat Linux 9 python >>> import time Traceback (most recent call last): File "", line 1, in ? ImportError: No module named time >>> import math Traceback (most recent call last): File "", line 1, in ? ImportError: No module named math >>> Haven't checked many more modules didn't notice any errors in ./config, make, or make install. -- >Comment By: George LeCompte (georgel377) Date: 2005-10-10 09:05 Message: Logged In: YES user_id=1187496 Attached a file with edited log showing problem. george -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-09 22:16 Message: Logged In: YES user_id=33168 Can you re-run make and see if there are errors? Is there anything in your PYTHONPATH environment variable? We will need more information in order to attempt to debug this. Do the .so files exist under build/lib*2.4/ ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1321736&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-1322308 ] itemgetter built-in?
Feature Requests item #1322308, was opened at 2005-10-10 11:56 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1322308&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: capnSTABN (capnstabn) Assigned to: Nobody/Anonymous (nobody) Summary: itemgetter built-in? Initial Comment: uhm... operator.itemgetter() is useful and all, but fairly retarded looking for how simple it is basically what i am wrestling with at the moment is doing some regular expressions without completely ganking the crap out of the code to make it work, since every freakin thing in re returns None all over the bloody place like regular expressions were hitting a ragging pinata with a chainsaw after a LOT of muckymuck, basically six hours straight, the simplest non-conditional form i could come up with was this: http://42.vg/81691"; target="_new">http://42.vg/81691 http://42.vg/81691 any comments would be leet! -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-10 18:57 Message: Logged In: YES user_id=1188172 Please tell us what your request for enhancement is or I'm going to close this as Invalid. Sorry I'm not showing more respect for your writing abilities :-), but if you want to show code around, do it on comp.lang.python please. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1322308&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1311579 ] 2.4.2 make problems
Bugs item #1311579, was opened at 2005-10-03 07:58 Message generated for change (Comment added) made by nlhas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311579&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Mothersdill (nlhas) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.2 make problems Initial Comment: Recommended to post this as a bug in comp.lang. python: Reply from Reinhold Birkenfeld > I have a standard Debian x86 system with Python 2.4.1 (compiled from > source). Attempts to compile 2.4.2 fail with references to Unicode -- > is there a basic system library that's missing? > Can you post a bug report to SourceForge and include the full output from make there? Also, have there been any unusual configure warnings? Reinhold + No: nothing unusual that I can see in configure output -- I can post config.log if necessary. -- >Comment By: Paul Mothersdill (nlhas) Date: 2005-10-10 18:17 Message: Logged In: YES user_id=424542 There is no output from nm unicodeobject.o -- the file is there (441 bytes, no permissions problems). See script.txt. -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-08 10:03 Message: Logged In: YES user_id=21627 Do you have an Objects/unicodeobject.o in your build tree? If yes, can you please do nm Objects/unicodeobject.o > unicodesyms.txt and attach the resulting file, as well as ar tv libpython2.4.a|grep unicode and report the output of this command? TIA. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311579&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1311579 ] 2.4.2 make problems
Bugs item #1311579, was opened at 2005-10-03 07:58 Message generated for change (Comment added) made by nlhas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311579&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Mothersdill (nlhas) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.2 make problems Initial Comment: Recommended to post this as a bug in comp.lang. python: Reply from Reinhold Birkenfeld > I have a standard Debian x86 system with Python 2.4.1 (compiled from > source). Attempts to compile 2.4.2 fail with references to Unicode -- > is there a basic system library that's missing? > Can you post a bug report to SourceForge and include the full output from make there? Also, have there been any unusual configure warnings? Reinhold + No: nothing unusual that I can see in configure output -- I can post config.log if necessary. -- >Comment By: Paul Mothersdill (nlhas) Date: 2005-10-10 18:57 Message: Logged In: YES user_id=424542 The previous stuff was based on the bz2 source file. On a hunch I downloaded the tgz source, which compiled like a dream. I can only assume that there must be a difference between the two source files (at least as downloaded a couple of weeks ago immediately after release for bz2 and now for tgz). Unfortunately the original bz2 file has been deleted. Anyway: the problem has "gone away". -- Comment By: Paul Mothersdill (nlhas) Date: 2005-10-10 18:17 Message: Logged In: YES user_id=424542 There is no output from nm unicodeobject.o -- the file is there (441 bytes, no permissions problems). See script.txt. -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-08 10:03 Message: Logged In: YES user_id=21627 Do you have an Objects/unicodeobject.o in your build tree? If yes, can you please do nm Objects/unicodeobject.o > unicodesyms.txt and attach the resulting file, as well as ar tv libpython2.4.a|grep unicode and report the output of this command? TIA. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311579&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes
Bugs item #1311784, was opened at 2005-10-03 14:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter Klotz (pete_icoserve) Assigned to: Nobody/Anonymous (nobody) Summary: python.exe 2.4.2 compiled with VS2005 crashes Initial Comment: The C runtime library shipped with Visual Studio 2005 performs strict checking of parameters. In function initsignal() in file Modules\signalmodule.c, an iteration over all signals from 1 to NSIG is performed. The function PyOS_getsig() is called with each of these integer values. PyOS_getsig() then calls signal() with the given value which leads to the crash. According to signal.h from VS2005 only these signals are allowed: #define SIGINT 2 #define SIGILL 4 #define SIGABRT_COMPAT 6 #define SIGFPE 8 #define SIGSEGV 11 #define SIGTERM 15 #define SIGBREAK21 #define SIGABRT 22 A solution would be to restrict the loop in initsignal() to the above values under Windows. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-10-10 22:13 Message: Logged In: YES user_id=21627 Yes, I really do. Users have protested a lot when we switched from VC6 to VS.NET2003, because they had to buy new compilers. We cannot reasonably force another compiler switch on them next year. However, this is off-topic for this bug report, please discuss it on python-dev. As for 64-bit windows support: I happily build 64-bit Windows binaries all the time with VS.NET2003, see www.python.org/2.4.2. There are no AMD64 binaries released, but extending the technology to support, say, the AMD64 SDK compiler would be possible. Patches to the actual code are greatfully accepted. -- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-10 09:05 Message: Logged In: YES user_id=299547 Do you really think ignoring/skipping VS2005 is a proper solution? I am currently porting our software to 64Bit Windows (AMD64/EM64T) and the only compiler supporting this is the one included in VS2005. If Python does not support VS2005 everyone needing a 64Bit version of Python is forced to locate and fix this problem on his own. -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-08 11:56 Message: Logged In: YES user_id=21627 Can somebody please study the source of the C runtime of VS2005 (probably needs to be requested specifically during installation), to find out whether more generic solutions are available. Possible solutions include: - don't call signal, but call an alternative function instead which won't cause a crash - set some magic variable, disabling the error checking - fetch the list of supported signals from somewhere (at compile time or at run time), and iterate over that list. Anyway, I don't see the official Python 2.5 release built with VS 2005, so this is a minor issue - I rather expect Python to skip VS 2005, and go right to the version that succeeds it. -- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-04 10:02 Message: Logged In: YES user_id=299547 I would leave the code for pre-VS2005 compilers as is and introduce a specific workaround for VS2005 and all following compilers. Something like this comes to my mind: #if defined (_WIN32) && _MSC_VER >= 1400 ... #endif This works for 32 and 64 bit platforms since _WIN32 is defined in both cases. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 21:54 Message: Logged In: YES user_id=33168 Do you suggest this be special cased for VS2005 specifically or Windows in general (ie, any version/compiler)? -- Comment By: Peter Klotz (pete_icoserve) Date: 2005-10-03 20:10 Message: Logged In: YES user_id=299547 VS2005 is still not released. It is scheduled for November 7th 2005. I tested with CTP (Community Technology Preview) August 2005. However I doubt they will change the behavior of their C library at this point of development. -- Comment By: Michael Hudson (mwh) Date: 2005-10-03 15:05 Message: Logged In: YES user_id=6656 Is VS2005 actually out now then? This behaviour violates the C standard, as far as we can tell, so we when VS2005 was in beta we hoped that they would fix
[ python-Bugs-1311579 ] 2.4.2 make problems
Bugs item #1311579, was opened at 2005-10-03 09:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311579&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Mothersdill (nlhas) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.2 make problems Initial Comment: Recommended to post this as a bug in comp.lang. python: Reply from Reinhold Birkenfeld > I have a standard Debian x86 system with Python 2.4.1 (compiled from > source). Attempts to compile 2.4.2 fail with references to Unicode -- > is there a basic system library that's missing? > Can you post a bug report to SourceForge and include the full output from make there? Also, have there been any unusual configure warnings? Reinhold + No: nothing unusual that I can see in configure output -- I can post config.log if necessary. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-10-10 22:19 Message: Logged In: YES user_id=21627 Really strange... Can you please 1.'file Objects/unicodeobject.o' (report its output) 2. rm Objects/unicodeobject.o 3. make (report the precise command used to rebuild unicodeobject.o) 4. Invoke the command detected in 3), adding --save-temps 5. Attached a compressed version of the resulting unicodeobject.i -- Comment By: Paul Mothersdill (nlhas) Date: 2005-10-10 20:57 Message: Logged In: YES user_id=424542 The previous stuff was based on the bz2 source file. On a hunch I downloaded the tgz source, which compiled like a dream. I can only assume that there must be a difference between the two source files (at least as downloaded a couple of weeks ago immediately after release for bz2 and now for tgz). Unfortunately the original bz2 file has been deleted. Anyway: the problem has "gone away". -- Comment By: Paul Mothersdill (nlhas) Date: 2005-10-10 20:17 Message: Logged In: YES user_id=424542 There is no output from nm unicodeobject.o -- the file is there (441 bytes, no permissions problems). See script.txt. -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-08 12:03 Message: Logged In: YES user_id=21627 Do you have an Objects/unicodeobject.o in your build tree? If yes, can you please do nm Objects/unicodeobject.o > unicodesyms.txt and attach the resulting file, as well as ar tv libpython2.4.a|grep unicode and report the output of this command? TIA. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311579&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1311579 ] 2.4.2 make problems
Bugs item #1311579, was opened at 2005-10-03 09:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311579&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: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Paul Mothersdill (nlhas) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.2 make problems Initial Comment: Recommended to post this as a bug in comp.lang. python: Reply from Reinhold Birkenfeld > I have a standard Debian x86 system with Python 2.4.1 (compiled from > source). Attempts to compile 2.4.2 fail with references to Unicode -- > is there a basic system library that's missing? > Can you post a bug report to SourceForge and include the full output from make there? Also, have there been any unusual configure warnings? Reinhold + No: nothing unusual that I can see in configure output -- I can post config.log if necessary. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-10-10 22:24 Message: Logged In: YES user_id=21627 Didn't notice your last message. Really strange, still... When I download both tar files, and uncompress them with their compressors (gzip 1.3.5 and bzip 1.0.2), the resulting tar files are byte-for-byte identical. So I assume something happened with your download. Closing as "works for me". -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-10 22:19 Message: Logged In: YES user_id=21627 Really strange... Can you please 1.'file Objects/unicodeobject.o' (report its output) 2. rm Objects/unicodeobject.o 3. make (report the precise command used to rebuild unicodeobject.o) 4. Invoke the command detected in 3), adding --save-temps 5. Attached a compressed version of the resulting unicodeobject.i -- Comment By: Paul Mothersdill (nlhas) Date: 2005-10-10 20:57 Message: Logged In: YES user_id=424542 The previous stuff was based on the bz2 source file. On a hunch I downloaded the tgz source, which compiled like a dream. I can only assume that there must be a difference between the two source files (at least as downloaded a couple of weeks ago immediately after release for bz2 and now for tgz). Unfortunately the original bz2 file has been deleted. Anyway: the problem has "gone away". -- Comment By: Paul Mothersdill (nlhas) Date: 2005-10-10 20:17 Message: Logged In: YES user_id=424542 There is no output from nm unicodeobject.o -- the file is there (441 bytes, no permissions problems). See script.txt. -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-08 12:03 Message: Logged In: YES user_id=21627 Do you have an Objects/unicodeobject.o in your build tree? If yes, can you please do nm Objects/unicodeobject.o > unicodesyms.txt and attach the resulting file, as well as ar tv libpython2.4.a|grep unicode and report the output of this command? TIA. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311579&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1323294 ] Minor error in the Library Reference doc
Bugs item #1323294, was opened at 2005-10-10 17:21 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=1323294&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: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: Minor error in the Library Reference doc Initial Comment: The function "module" in the module new says: module( name) This function returns a new module object with name name. name must be a string. The doc string says: C:\Python24\Lib\site-packages\scipy>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from new import module >>> module.__doc__ 'module(name[, doc])\n\nCreate a module object.\nThe name must be a string; the optional doc argumen t can have any type.' >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323294&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1321736 ] Missing Library Modules
Bugs item #1321736, was opened at 2005-10-09 21:17 Message generated for change (Comment added) made by georgel377 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1321736&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: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George LeCompte (georgel377) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Library Modules Initial Comment: downloaded python-2.4.2 under redhat Linux 9 python >>> import time Traceback (most recent call last): File "", line 1, in ? ImportError: No module named time >>> import math Traceback (most recent call last): File "", line 1, in ? ImportError: No module named math >>> Haven't checked many more modules didn't notice any errors in ./config, make, or make install. -- >Comment By: George LeCompte (georgel377) Date: 2005-10-10 16:15 Message: Logged In: YES user_id=1187496 I did a make clean, ./configure, make, and make install with no improvements. Here is the contnts of the file previously attached. I think it answers the questions. .:/usr/local/lib/python2.4/:/usr/local/lib/python2.4/site-packages/ PYTHON PATH seems OK [EMAIL PROTECTED] Python-2.4.2]# echo $PYTHONPATH .:/usr/local/lib/python2.4/:/usr/local/lib/python2.4/site-packages/ [EMAIL PROTECTED] Python-2.4.2]# There were some warning during make: [EMAIL PROTECTED] Python-2.4.2]# make >makeInfo libpython2.4.a(posixmodule.o)(.text+0x39e0): In function `posix_tmpnam': Modules/posixmodule.c:6159: the use of `tmpnam_r' is dangerous, better use `mkstemp' libpython2.4.a(posixmodule.o)(.text+0x3952): In function `posix_tempnam': Modules/posixmodule.c:6114: the use of `tempnam' is dangerous, better use `mkstemp' /home/george/downloads/Python/Python-2.4.2/Modules/cjkcodecs/_codecs_iso2022.c: In function `iso2022_encode': /home/george/downloads/Python/Python-2.4.2/Modules/cjkcodecs/_codecs_iso2022.c:207: warning: passing arg 1 of pointer to function from incompatible pointer [EMAIL PROTECTED] Python-2.4.2]# time.so and math.so exist under build/lib*2.4 [EMAIL PROTECTED] Python-2.4.2]# find / -name 'math.so' /usr/local/lib/python2.4/lib-dynload/math.so /usr/src/redhat/BUILD/Python-2.3.4/build/lib.linux-i686-2.3/math.so /home/george/.kde/share/usr/local/lib/python2.4/lib-dynload/math.so /home/george/downloads/Python/Python-2.4.2/build/lib.linux-i686-2.4/math.so [EMAIL PROTECTED] Python-2.4.2]# find / -name 'time.so' /usr/local/lib/python2.4/lib-dynload/time.so /usr/src/redhat/BUILD/Python-2.3.4/build/lib.linux-i686-2.3/time.so /home/george/.kde/share/usr/local/lib/python2.4/lib-dynload/time.so /home/george/downloads/Python/Python-2.4.2/build/lib.linux-i686-2.4/time.so [EMAIL PROTECTED] Python-2.4.2]# The problem still persists: [EMAIL PROTECTED] Python-2.4.2]# [EMAIL PROTECTED] Python-2.4.2]# python Python 2.4.2 (#5, Oct 10 2005, 07:52:32) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time Traceback (most recent call last): File "", line 1, in ? ImportError: No module named time >>> import math Traceback (most recent call last): File "", line 1, in ? ImportError: No module named math >>> import sys >>> import datetime Traceback (most recent call last): File "", line 1, in ? ImportError: No module named datetime >>> import rand Traceback (most recent call last): File "", line 1, in ? ImportError: No module named rand >>> -- Comment By: George LeCompte (georgel377) Date: 2005-10-10 09:05 Message: Logged In: YES user_id=1187496 Attached a file with edited log showing problem. george -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-09 22:16 Message: Logged In: YES user_id=33168 Can you re-run make and see if there are errors? Is there anything in your PYTHONPATH environment variable? We will need more information in order to attempt to debug this. Do the .so files exist under build/lib*2.4/ ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1321736&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1323369 ] getwindowsversion() constants in sys module
Bugs item #1323369, was opened at 2005-10-11 12:44 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=1323369&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: getwindowsversion() constants in sys module Initial Comment: In the documentation for the sys.getwindowsversion() function, it says that the 'platform' value may be one of four constants (specifying them by name). However, these constants are not in the sys module (they are in win32con from pywin32). It would be better if either the documentation said that the constants were available in win32con if pywin32 is installed, or if the constants were added to the sys module. I personally think the latter is better since it's a single line of code, and makes the getwindowsversion() function more useful, but I'm not sure whether people will want to clutter the sys module with four constants. I'm happy to provide a patch for either behaviour, if an appropriate developer will choose one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323369&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1321736 ] Missing Library Modules
Bugs item #1321736, was opened at 2005-10-09 21:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1321736&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: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George LeCompte (georgel377) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Library Modules Initial Comment: downloaded python-2.4.2 under redhat Linux 9 python >>> import time Traceback (most recent call last): File "", line 1, in ? ImportError: No module named time >>> import math Traceback (most recent call last): File "", line 1, in ? ImportError: No module named math >>> Haven't checked many more modules didn't notice any errors in ./config, make, or make install. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-10 20:16 Message: Logged In: YES user_id=33168 The files (time.so, math.so) look like they are installed where they should be. What is your LD_LIBRARY_PATH? Does it work as a normal user (not root)? ls -l /usr/local/lib/python2.4/lib-dynload/math.so ? Finally, this is the most likely to help you resolve the problem, run strace. strace will show where python is trying to load math.so and should indicate what error is occurring. Hopefully, that will point out the real problem. -- Comment By: George LeCompte (georgel377) Date: 2005-10-10 16:15 Message: Logged In: YES user_id=1187496 I did a make clean, ./configure, make, and make install with no improvements. Here is the contnts of the file previously attached. I think it answers the questions. .:/usr/local/lib/python2.4/:/usr/local/lib/python2.4/site-packages/ PYTHON PATH seems OK [EMAIL PROTECTED] Python-2.4.2]# echo $PYTHONPATH .:/usr/local/lib/python2.4/:/usr/local/lib/python2.4/site-packages/ [EMAIL PROTECTED] Python-2.4.2]# There were some warning during make: [EMAIL PROTECTED] Python-2.4.2]# make >makeInfo libpython2.4.a(posixmodule.o)(.text+0x39e0): In function `posix_tmpnam': Modules/posixmodule.c:6159: the use of `tmpnam_r' is dangerous, better use `mkstemp' libpython2.4.a(posixmodule.o)(.text+0x3952): In function `posix_tempnam': Modules/posixmodule.c:6114: the use of `tempnam' is dangerous, better use `mkstemp' /home/george/downloads/Python/Python-2.4.2/Modules/cjkcodecs/_codecs_iso2022.c: In function `iso2022_encode': /home/george/downloads/Python/Python-2.4.2/Modules/cjkcodecs/_codecs_iso2022.c:207: warning: passing arg 1 of pointer to function from incompatible pointer [EMAIL PROTECTED] Python-2.4.2]# time.so and math.so exist under build/lib*2.4 [EMAIL PROTECTED] Python-2.4.2]# find / -name 'math.so' /usr/local/lib/python2.4/lib-dynload/math.so /usr/src/redhat/BUILD/Python-2.3.4/build/lib.linux-i686-2.3/math.so /home/george/.kde/share/usr/local/lib/python2.4/lib-dynload/math.so /home/george/downloads/Python/Python-2.4.2/build/lib.linux-i686-2.4/math.so [EMAIL PROTECTED] Python-2.4.2]# find / -name 'time.so' /usr/local/lib/python2.4/lib-dynload/time.so /usr/src/redhat/BUILD/Python-2.3.4/build/lib.linux-i686-2.3/time.so /home/george/.kde/share/usr/local/lib/python2.4/lib-dynload/time.so /home/george/downloads/Python/Python-2.4.2/build/lib.linux-i686-2.4/time.so [EMAIL PROTECTED] Python-2.4.2]# The problem still persists: [EMAIL PROTECTED] Python-2.4.2]# [EMAIL PROTECTED] Python-2.4.2]# python Python 2.4.2 (#5, Oct 10 2005, 07:52:32) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time Traceback (most recent call last): File "", line 1, in ? ImportError: No module named time >>> import math Traceback (most recent call last): File "", line 1, in ? ImportError: No module named math >>> import sys >>> import datetime Traceback (most recent call last): File "", line 1, in ? ImportError: No module named datetime >>> import rand Traceback (most recent call last): File "", line 1, in ? ImportError: No module named rand >>> -- Comment By: George LeCompte (georgel377) Date: 2005-10-10 09:05 Message: Logged In: YES user_id=1187496 Attached a file with edited log showing problem. george -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-09 22:16 Message: Logged In: YES user_id=33168 Can you re-run make and see if there are errors? Is there anything in your PYTHONPATH environment variable? We will need more information in order to attempt to debug this. Do the .so files exist under build/lib*2.4/ ? -
[ python-Bugs-1323294 ] Minor error in the Library Reference doc
Bugs item #1323294, was opened at 2005-10-10 14:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323294&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: Fixed Priority: 5 Submitted By: Colin J. Williams (cjwhrh) >Assigned to: Neal Norwitz (nnorwitz) Summary: Minor error in the Library Reference doc Initial Comment: The function "module" in the module new says: module( name) This function returns a new module object with name name. name must be a string. The doc string says: C:\Python24\Lib\site-packages\scipy>python Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from new import module >>> module.__doc__ 'module(name[, doc])\n\nCreate a module object.\nThe name must be a string; the optional doc argumen t can have any type.' >>> -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-10 20:24 Message: Logged In: YES user_id=33168 Thanks. Checked in as: * Doc/lib/libnew.tex 1.11, 1.10.2.1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1323294&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246900 ] failure to build RPM on rhel 3
Bugs item #1246900, was opened at 2005-07-28 09:14
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246900&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick Wagstrom (pridkett)
>Assigned to: Sean Reifschneider (jafo)
Summary: failure to build RPM on rhel 3
Initial Comment:
This is on RHEL 3 AS (Taroon update 5) on a dual
processor x86_64 machine
Attempting to build the RPM from Python.org fails with
a very non-descript error message:
+ mv -f idle idle2.4
+ echo '#!/usr/bin/env python2.4'
+ echo 'import os, sys'
+ echo 'os.execvp("/usr/bin/python2.4",
["/usr/bin/python2.4",
"/usr/lib/python2.4/idlelib/idle.py"] + sys.argv[1:])'
+ echo 'print "Failed to exec Idle"'
+ echo 'sys.exit(1)'
+ chmod 755 /var/tmp/python2.4-2.4.1-root/usr/bin/idle2.4
+ cp -a Tools
/var/tmp/python2.4-2.4.1-root/usr/lib64/python2.4
+ rm -f mainpkg.files
+ find
/var/tmp/python2.4-2.4.1-root/usr/lib64/python2.4/lib-dynload
-type f
+ sed 's|^/var/tmp/python2.4-2.4.1-root|/|'
+ grep -v -e '_tkinter.so$'
error: Bad exit status from /var/tmp/rpm-tmp.97009
(%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.97009 (%install)
So, thinking that it might be something related to
tkinter and idel, I tried not building those, but it
still fails to complete. It appears that the problem
is that nothing is getting put in /usr/lib64 and
everything is getting put in /usr/lib.
Attempts were made at hacking the spec file to pass
--libdir=/usr/lib64 --exec-prefix=/usr to configure and
still have the problem that it doesn't put anything in
/usr/lib64 even though the spec file, and common logic,
would expect there to be files in /usr/lib64.
I was able to compile Python 2.4 just fine on the
machine and install it, but still it did not have
anything in /usr/lib64/python2.4, which is where the
architecture specific files should be.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-10 20:31
Message:
Logged In: YES
user_id=33168
Sean, do you have any insight into this issue?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246900&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193099 ] Embedded python thread crashes
Bugs item #1193099, was opened at 2005-04-30 12:03
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193099&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: ugodiggi (ugodiggi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Embedded python thread crashes
Initial Comment:
The following code crashes about 1/3 of the times.
My platform is Python 2.4.1 on WXP (I tried the release
version from the msi and the debug version built by me).
I can reproduce the same behavior on another wxp
system, under python 2.4.
The crash happens (in the python thread) while the main
thread is in Py_Finalize.
I traced the crash to _Py_ForgetReference(op) in
object.c at line 1847, where I have op->_ob_prev == NULL.
The open file seems to be the issue, since if I remove
all the references to the file I cannot get the program
to crash.
Cheers and ciao
Ugo
// TestPyThreads.cpp
//
#include // Sleep
#include "Python.h"
int main()
{
PyEval_InitThreads();
Py_Initialize();
PyGILState_STATE main_restore_state =
PyGILState_UNLOCKED;
PyGILState_Release(main_restore_state);
// start the thread
{
PyGILState_STATE state =
PyGILState_Ensure();
int trash = PyRun_SimpleString(
"import thread\n"
"import time\n"
"def foo():\n"
" f =
open('pippo.out', 'w', 0)\n"
" i = 0;\n"
" while 1:\n"
"f.write('%d\n'%i)\n"
"time.sleep(0.01)\n"
"i += 1\n"
"t =
thread.start_new_thread(foo, ())\n"
);
PyGILState_Release(state);
}
// wait 300 ms
Sleep(300);
PyGILState_Ensure();
Py_Finalize();
return 0;
}
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-10 20:52
Message:
Logged In: YES
user_id=33168
Perhaps this is caused by different runtime DLLs. Here's
what I googled for: site:mail.python.org windows python
runtime dll crash
See http://python.org/sf/1003535
Can you try to research more and see if you can come up with
anything? (I don't run windows, so I can't test anything.)
Do you get this problem with the version built from
python.org or only with the version you built?
--
Comment By: ugodiggi (ugodiggi)
Date: 2005-10-06 00:29
Message:
Logged In: YES
user_id=1269908
Something changed on the computer I'm testing on, and the
crash happens way less often (say 1/10 of the times in debug
mode, and very rarely in Release mode).
The compiler is MSVC7.1 on WXP, using Python 241
This is the stack of the main thread
7ffe0304()
ntdll.dll!77f5b5d4()
kernel32.dll!77e7a683()
msvcr71d.dll!_close_lk(int fh=0x0003) Line 115 +
0x4aC
msvcr71d.dll!_close(int fh=0x0003) Line 60 + 0x9
C
msvcr71d.dll!_fclose_lk(_iobuf * str=0x1027c898) Line
127 + 0xc C
msvcr71d.dll!fclose(_iobuf * stream=0x1027c898) Line
58 + 0x9C
> python24_d.dll!file_dealloc(PyFileObject *
f=0x00919ec8) Line 308 + 0xd C
python24_d.dll!_Py_Dealloc(_object * op=0x00919ec8)
Line 1870 + 0x7 C
python24_d.dll!frame_dealloc(_frame * f=0x00972960)
Line 394 + 0x67 C
python24_d.dll!_Py_Dealloc(_object * op=0x00972960)
Line 1870 + 0x7 C
python24_d.dll!PyThreadState_Clear(_ts *
tstate=0x00892c88) Line 200 + 0x6c C
python24_d.dll!PyInterpreterState_Clear(_is *
interp=0x00894f48) Line 93 + 0x9 C
python24_d.dll!Py_Finalize() Line 401 + 0x9C
TestPyThreads.exe!main() Line 33 + 0x8 C++
TestPyThreads.exe!mainCRTStartup() Line 259 + 0x19
C
kernel32.dll!77e8141a()
and this is the stack of the other thread (_threadstart)
(the crash is here, where "if (frame->f_exc_type != NULL) "
gets called with frame == NULL)
> python24_d.dll!reset_exc_info(_ts * tstate=0x00892c88)
Line 2861 + 0x3 C
python24_d.dll!PyEval_EvalFrame(_frame *
f=0x00972960) Line 2490 + 0x9 C
python24_d.dll!PyEval_EvalCodeEx(PyCodeObject *
co=0x00943ad0, _object * globals=0x008e3230, _object *
locals=0x, _object * * args=0x008c104c, int
argcount=
[ python-Bugs-1167751 ] Argument genexp corner case
Bugs item #1167751, was opened at 2005-03-21 09:47
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167751&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: Parser/Compiler
>Group: Python 2.5
Status: Open
Resolution: None
>Priority: 8
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Argument genexp corner case
Initial Comment:
The following raises an unexpected exception; I would
expect it to either work or raise a SyntaxError. It
seems that the grammar parses it, but the compiler does
not do the right thing.
>>> def foo(a): pass
>>> foo(a = i for i in range(10))
Traceback (most recent call last):
File "", line 1, in ?
NameError: name 'i' is not defined
foo(a = (i for i in range(10)) works.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-10 21:10
Message:
Logged In: YES
user_id=33168
I definitely agree this is a big problem.
Here's what the code above generates:
2 0 LOAD_GLOBAL 0 (foo)
3 LOAD_CONST 1 ('a')
6 LOAD_GLOBAL 1 (i)
9 CALL_FUNCTION 256
12 POP_TOP
13 LOAD_CONST 0 (None)
16 RETURN_VALUE
If I put parens around the genexp, I get:
2 0 LOAD_GLOBAL 0 (foo)
3 LOAD_CONST 1 ('a')
6 LOAD_CONST 2 ( at 0x2a960baae8, file "", line 2>)
9 MAKE_FUNCTION0
12 LOAD_GLOBAL 1 (range)
15 LOAD_CONST 3 (10)
18 CALL_FUNCTION1
21 GET_ITER
22 CALL_FUNCTION1
25 CALL_FUNCTION 256
28 POP_TOP
29 LOAD_CONST 0 (None)
32 RETURN_VALUE
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167751&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246900 ] failure to build RPM on rhel 3
Bugs item #1246900, was opened at 2005-07-28 16:14
Message generated for change (Comment added) made by jafo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246900&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.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Patrick Wagstrom (pridkett)
Assigned to: Sean Reifschneider (jafo)
Summary: failure to build RPM on rhel 3
Initial Comment:
This is on RHEL 3 AS (Taroon update 5) on a dual
processor x86_64 machine
Attempting to build the RPM from Python.org fails with
a very non-descript error message:
+ mv -f idle idle2.4
+ echo '#!/usr/bin/env python2.4'
+ echo 'import os, sys'
+ echo 'os.execvp("/usr/bin/python2.4",
["/usr/bin/python2.4",
"/usr/lib/python2.4/idlelib/idle.py"] + sys.argv[1:])'
+ echo 'print "Failed to exec Idle"'
+ echo 'sys.exit(1)'
+ chmod 755 /var/tmp/python2.4-2.4.1-root/usr/bin/idle2.4
+ cp -a Tools
/var/tmp/python2.4-2.4.1-root/usr/lib64/python2.4
+ rm -f mainpkg.files
+ find
/var/tmp/python2.4-2.4.1-root/usr/lib64/python2.4/lib-dynload
-type f
+ sed 's|^/var/tmp/python2.4-2.4.1-root|/|'
+ grep -v -e '_tkinter.so$'
error: Bad exit status from /var/tmp/rpm-tmp.97009
(%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.97009 (%install)
So, thinking that it might be something related to
tkinter and idel, I tried not building those, but it
still fails to complete. It appears that the problem
is that nothing is getting put in /usr/lib64 and
everything is getting put in /usr/lib.
Attempts were made at hacking the spec file to pass
--libdir=/usr/lib64 --exec-prefix=/usr to configure and
still have the problem that it doesn't put anything in
/usr/lib64 even though the spec file, and common logic,
would expect there to be files in /usr/lib64.
I was able to compile Python 2.4 just fine on the
machine and install it, but still it did not have
anything in /usr/lib64/python2.4, which is where the
architecture specific files should be.
--
>Comment By: Sean Reifschneider (jafo)
Date: 2005-10-11 04:40
Message:
Logged In: YES
user_id=81797
This is a duplicate of bug 1294959
(https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=1294959),
which I opened about a month ago. That bug includes patches
from Red Hat which make it able to build the /usr/lib64
code. I believe the above bug covers the details, if it
does not, let me know and I'll update it there.
The short form is that the Python build process doesn't have
any way to build for /usr/lib64 without hacking the code,
unless I'm missing something.
I was hoping the bug would lead to some discussion about how
best to approach this problem. I guess I should post on
python-dev.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-11 03:31
Message:
Logged In: YES
user_id=33168
Sean, do you have any insight into this issue?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246900&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246900 ] failure to build RPM on rhel 3
Bugs item #1246900, was opened at 2005-07-28 09:14
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246900&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.4
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Patrick Wagstrom (pridkett)
Assigned to: Sean Reifschneider (jafo)
Summary: failure to build RPM on rhel 3
Initial Comment:
This is on RHEL 3 AS (Taroon update 5) on a dual
processor x86_64 machine
Attempting to build the RPM from Python.org fails with
a very non-descript error message:
+ mv -f idle idle2.4
+ echo '#!/usr/bin/env python2.4'
+ echo 'import os, sys'
+ echo 'os.execvp("/usr/bin/python2.4",
["/usr/bin/python2.4",
"/usr/lib/python2.4/idlelib/idle.py"] + sys.argv[1:])'
+ echo 'print "Failed to exec Idle"'
+ echo 'sys.exit(1)'
+ chmod 755 /var/tmp/python2.4-2.4.1-root/usr/bin/idle2.4
+ cp -a Tools
/var/tmp/python2.4-2.4.1-root/usr/lib64/python2.4
+ rm -f mainpkg.files
+ find
/var/tmp/python2.4-2.4.1-root/usr/lib64/python2.4/lib-dynload
-type f
+ sed 's|^/var/tmp/python2.4-2.4.1-root|/|'
+ grep -v -e '_tkinter.so$'
error: Bad exit status from /var/tmp/rpm-tmp.97009
(%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.97009 (%install)
So, thinking that it might be something related to
tkinter and idel, I tried not building those, but it
still fails to complete. It appears that the problem
is that nothing is getting put in /usr/lib64 and
everything is getting put in /usr/lib.
Attempts were made at hacking the spec file to pass
--libdir=/usr/lib64 --exec-prefix=/usr to configure and
still have the problem that it doesn't put anything in
/usr/lib64 even though the spec file, and common logic,
would expect there to be files in /usr/lib64.
I was able to compile Python 2.4 just fine on the
machine and install it, but still it did not have
anything in /usr/lib64/python2.4, which is where the
architecture specific files should be.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-10 21:48
Message:
Logged In: YES
user_id=33168
Yeah, you probably should post something...unless you want
to read about concurrency for ever until your mind
deadlocks...or is it live locks. ;-)
--
Comment By: Sean Reifschneider (jafo)
Date: 2005-10-10 21:40
Message:
Logged In: YES
user_id=81797
This is a duplicate of bug 1294959
(https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=1294959),
which I opened about a month ago. That bug includes patches
from Red Hat which make it able to build the /usr/lib64
code. I believe the above bug covers the details, if it
does not, let me know and I'll update it there.
The short form is that the Python build process doesn't have
any way to build for /usr/lib64 without hacking the code,
unless I'm missing something.
I was hoping the bug would lead to some discussion about how
best to approach this problem. I guess I should post on
python-dev.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-10 20:31
Message:
Logged In: YES
user_id=33168
Sean, do you have any insight into this issue?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246900&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
