[ python-Bugs-1648890 ] HP-UX: ld -Wl,+b...
Bugs item #1648890, was opened at 2007-01-31 14:57 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=1648890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: ld -Wl,+b... Initial Comment: On HP-UX 11.* (here: 11.23), configure chooses "ld -b" for extension modules like unicodedata.so. My $LDFLAGS contains instructions like "-Wl,+b" (run-time search path for shared libs). This is correct, because LDFLAGS should be passed to the compiler. distutils compiles the extension modules with "cc" (I need to use the native compiler), then it links with ld -b $(LDFLAGS) -I ... These means that options like -Wl, and -I are passed to the linker! To solve this problem quickly, I propose to modify configure. If LDSHARED="cc -b", Python 2.5 compiles. Though this works very godd with with current HP-UX compilers, it does not work with ancient HP-UX compiler suites. Maybe there should be a test in configure in order to see if LDSHARED works. If you really want to support old HP-UX compilers, distutils should not - pass $LDFLAGS containing "-Wl," to "ld" nor - call the linker with -I. This is the current state of the linker call: ld -b -L/usr/local/python/2.5/lib/hpux32 -Wl,+b,/usr/local/python/2.5/lib/hpux32:/usr/local/devel/readline/5.1-static/lib/hpux32:/usr/local/ssl/lib:/usr/local/devel/bzip-1.0.3/lib/hpux32:/usr/local/devel/berkeleydb/4.3.29-static/lib:/usr/local/lib/hpux32 -L/usr/local/devel/readline/5.1-static/lib/hpux32 -Wl,+b,/usr/local/devel/readline/5.1-static/lib/hpux32:/usr/local/ssl/lib:/usr/local/devel/bzip-1.0.3/lib/hpux32:/usr/local/devel/berkeleydb/4.3.29-static/lib:/usr/local/lib/hpux32 -L/usr/local/ssl/lib -Wl,+b,/usr/local/ssl/lib:/usr/local/devel/bzip-1.0.3/lib/hpux32:/usr/local/devel/berkeleydb/4.3.29-static/lib:/usr/local/lib/hpux32 -L/usr/local/devel/bzip-1.0.3/lib/hpux32 -Wl,+b,/usr/local/devel/bzip-1.0.3/lib/hpux32:/usr/local/devel/berkeleydb/4.3.29-static/lib:/usr/local/lib/hpux32 -L/usr/local/devel/berkeleydb/4.3.29-static/lib -Wl,+b,/usr/local/devel/berkeleydb/4.3.29-static/lib:/usr/local/lib/hpux32 -L/usr/local/lib/hpux32 -Wl,+b,/usr/local/lib/hpux32 -I. -I/soft/python! /python-2.5/Python-2.5/Include -I/usr/local/include -I/usr/local/devel/berkeleydb/4.3.29-static/include -I/usr/local/devel/bzip-1.0.3/include -I/usr/local/ssl/include -I/usr/local/devel/readline/5.1-static/include build/temp.hp-ux-B.11.23-ia64-2.5/soft/python/python-2.5/Python-2.5/Modules/readline.o -L/usr/lib/termcap -L/usr/local/python/2.5/lib -L/usr/local/lib -lreadline -o build/lib.hp-ux-B.11.23-ia64-2.5/readline.so -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648890&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1648923 ] HP-UX: -lcurses missing for readline.so
Bugs item #1648923, was opened at 2007-01-31 15:33 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=1648923&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: -lcurses missing for readline.so Initial Comment: The readline extension seemed to be built without problems, but afterwards, this line appears: /usr/lib/hpux32/dld.so: Unsatisfied code symbol 'tgetent' in load module 'build/lib.hp-ux-B.11.23-ia64-2.5/readline.so'. I have fixed this by manually rebuilding the above file with -lcurses. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648923&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1648957 ] HP-UX: _ctypes/libffi/src/ia64/ffi/__attribute__/native cc
Bugs item #1648957, was opened at 2007-01-31 16:07 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=1648957&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: _ctypes/libffi/src/ia64/ffi/__attribute__/native cc Initial Comment: _ctypes/libffi/src/ia64/ffi.c uses __attribute__((...)) twice. Consequently, ffi.c does not compile with the native compiler (cc: HP C/aC++ B3910B A.06.12 [Aug 17 2006]). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648957&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633863 ] AIX: configure ignores $CC
Bugs item #1633863, was opened at 2007-01-12 09:46 Message generated for change (Settings changed) made by jabt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) >Summary: AIX: configure ignores $CC Initial Comment: CC=xlc_r ./configure does not work on AIX-5.1, because configure unconditionally sets $CC to "cc_r": case $ac_sys_system in AIX*) CC=cc_r without_gcc=;; It would be better to leave $CC and just add "-qthreaded" to $CFLAGS. Furthermore, much of the C source code of Python uses C++ /C99 comments. This is an error with the standard AIX compiler. Please add the compiler flag "-qcpluscmt". An alternative would be to use a default of "xlc_r" for CC on AIX. This calls the compiler in a mode that both accepts C++ comments and generates reentrant code. Regards, Johannes -- Comment By: Johannes Abt (jabt) Date: 2007-01-30 14:07 Message: Logged In: YES user_id=1563402 Originator: YES Sorry about the C++ comments... all the C++ comments I have found concern Windows, PC or Darwin. I must have confused this with another project I have been compiling. Though there still the issue with setting $CC. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-19 06:47 Message: Logged In: YES user_id=33168 Originator: NO There shouldn't be any C++ comments in the Python code. If there are, it is a mistake. I did see some get removed recently. Could you let me know where you see the C++ comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1648960 ] HP-UX11.23: module zlib missing
Bugs item #1648960, was opened at 2007-01-31 16:13 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=1648960&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX11.23: module zlib missing Initial Comment: The build processes does not build module zlib, so zipimport does not work, either. /usr/local/lib/hpux32/libz.so exists. configure tells me: checking for inflateCopy in -lz... yes -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648960&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1649011 ] HP-UX: compiler warnings: alignment
Bugs item #1649011, was opened at 2007-01-31 17:20 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=1649011&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: compiler warnings: alignment Initial Comment: On HP-UX 11.23 with the native compiler (cc: HP C/aC++ B3910B A.06.12 [Aug 17 2006]), I get dozens of these warnings: /soft/python/python-2.5/Python-2.5/Modules/_ctypes/_ctypes.c", line 2885: warning #4232-D: conversion from "PyObject *" to a more strictly aligned type "CDataObject *" may cause misaligned access ob = (CDataObject *)GenericCData_new(type, args, kwds); It does not seem to be very serious. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649011&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1649098 ] non-standard: array[0]
Bugs item #1649098, was opened at 2007-01-31 19:25
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=1649098&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johannes Abt (jabt)
Assigned to: Nobody/Anonymous (nobody)
Summary: non-standard: array[0]
Initial Comment:
in Modules/_ctypes/ctypes.h:
typedef struct {
[..]
ffi_type *atypes[0];
} ffi_info;
AFAIK, arrays must be of size > 0.
_Most_ compilers accepts this, but not all
(especially my HP-UX compiler).
Please change *atypes[0] to *atypes[1]!
Bye,
Johannes
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649098&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1649100 ] Arithmetics behaving strange
Bugs item #1649100, was opened at 2007-01-31 19:36 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=1649100&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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sascha Peilicke (lastmohican) Assigned to: Nobody/Anonymous (nobody) Summary: Arithmetics behaving strange Initial Comment: Hello, i just found some strange things going around, could you please tell me if this is desired: >>> 3 + 4 7 >>> 3 +- 4 -1 >>> 3 +-+ 4 -1 >>> 3 +-+- 4 7 >>> 3 +-+-+ 4 7 >>> 3 +-+-+- 4 -1 >>> 3 +-+-+-+ 4 -1 >>> 3 +-+-+-+- 4 7 This was found in Python 2.4.4c1. And also another one: >>> _ Traceback (most recent call last): File "", line 1, in ? NameError: name '_' is not defined >>> 3 == 3 True >>> _ True >>> 3 3 >>> _ 3 So what the hell is '_' something very strange indeed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649100&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1649100 ] Arithmetics behaving strange
Bugs item #1649100, was opened at 2007-01-31 19:36 Message generated for change (Comment added) made by lastmohican You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649100&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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sascha Peilicke (lastmohican) Assigned to: Nobody/Anonymous (nobody) Summary: Arithmetics behaving strange Initial Comment: Hello, i just found some strange things going around, could you please tell me if this is desired: >>> 3 + 4 7 >>> 3 +- 4 -1 >>> 3 +-+ 4 -1 >>> 3 +-+- 4 7 >>> 3 +-+-+ 4 7 >>> 3 +-+-+- 4 -1 >>> 3 +-+-+-+ 4 -1 >>> 3 +-+-+-+- 4 7 This was found in Python 2.4.4c1. And also another one: >>> _ Traceback (most recent call last): File "", line 1, in ? NameError: name '_' is not defined >>> 3 == 3 True >>> _ True >>> 3 3 >>> _ 3 So what the hell is '_' something very strange indeed. -- >Comment By: Sascha Peilicke (lastmohican) Date: 2007-01-31 19:39 Message: Logged In: YES user_id=1465593 Originator: YES I also found these working on the following: Python 2.5 (r25:51908, Oct 6 2006, 15:22:41) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2 Seems to be a common 'problem' ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649100&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1649100 ] Arithmetics behaving strange and magic underscore
Bugs item #1649100, was opened at 2007-01-31 19:36 Message generated for change (Settings changed) made by lastmohican You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649100&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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sascha Peilicke (lastmohican) Assigned to: Nobody/Anonymous (nobody) >Summary: Arithmetics behaving strange and magic underscore Initial Comment: Hello, i just found some strange things going around, could you please tell me if this is desired: >>> 3 + 4 7 >>> 3 +- 4 -1 >>> 3 +-+ 4 -1 >>> 3 +-+- 4 7 >>> 3 +-+-+ 4 7 >>> 3 +-+-+- 4 -1 >>> 3 +-+-+-+ 4 -1 >>> 3 +-+-+-+- 4 7 This was found in Python 2.4.4c1. And also another one: >>> _ Traceback (most recent call last): File "", line 1, in ? NameError: name '_' is not defined >>> 3 == 3 True >>> _ True >>> 3 3 >>> _ 3 So what the hell is '_' something very strange indeed. -- Comment By: Sascha Peilicke (lastmohican) Date: 2007-01-31 19:39 Message: Logged In: YES user_id=1465593 Originator: YES I also found these working on the following: Python 2.5 (r25:51908, Oct 6 2006, 15:22:41) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2 Seems to be a common 'problem' ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649100&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1648957 ] HP-UX: _ctypes/libffi/src/ia64/ffi/__attribute__/native cc
Bugs item #1648957, was opened at 2007-01-31 16:07 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648957&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: _ctypes/libffi/src/ia64/ffi/__attribute__/native cc Initial Comment: _ctypes/libffi/src/ia64/ffi.c uses __attribute__((...)) twice. Consequently, ffi.c does not compile with the native compiler (cc: HP C/aC++ B3910B A.06.12 [Aug 17 2006]). -- >Comment By: Thomas Heller (theller) Date: 2007-01-31 20:43 Message: Logged In: YES user_id=11105 Originator: NO I tried that on a HP testdrive machine. While the _ctypes extension buils fine with GCC (*), it does indeed not compile with the native C compiler. But cc not understanding __attribute__ is only the first problem; if it is removed there are lots of other compilation problems. Unless someone can provide a patch, I'll close this as 'won't fix'. (*) _ctypes_test.so is also built but fails to load as shared library, because the symbol __divsf3 is not defined. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648957&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1582742 ] Python is dumping core after the test test_ctypes
Bugs item #1582742, was opened at 2006-10-23 11:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Thomas Heller (theller) Summary: Python is dumping core after the test test_ctypes Initial Comment: Hi , Iam building Python-2.5 on HPUX Itanium. The compilation is done without any error, but while testing the same using gmake test it is dumping core telling "Segementation Fault" after the test test_ctypes. Please help me in resolving the above issue.Iam attaching the output of gmake test. Thanks in advance, -- >Comment By: Thomas Heller (theller) Date: 2007-01-31 21:15 Message: Logged In: YES user_id=11105 Originator: NO I finally found time (and energy) to try out the td176 HPUX host on HP testdrive. I downloaded the python25.tar.bz2 snapshot from svn.python.org, and built it with the installed gcc 3.4.3. First, I got errors in the ctypes tests because the _ctypes_test extension/shared library could not be loaded because of a missing symbol __divsf3. Googling around I found http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html which mentions a GCC runtime library libgcc.a (see the link 'soft float library routines' on ths page). When this library is specified when building _ctypes_test.so, all ctypes unittests pass. Without any crash. It is strange, to link against the libgcc.a library it seems needed to specify the location of the library '/usr/local/lib/gcc/ia64-hp-hpux11.23/3.4.3/' - no idea why. Can some HPUX guru provide some insight? The attached patch to setup.py is what was needed, but it is a hack of course. File Added: setup.py.patch -- Comment By: Thomas Heller (theller) Date: 2006-11-02 22:02 Message: Logged In: YES user_id=11105 Neal, I see no connection between the code that you show and the stack dump. For the failure when importing ctypes.test.test_cfuncs it seems that a library (?) is missing that _ctypes_test.so requires. Any idea? (I know that HP offers shell access to HPUX boxes, but I hesitate to try that out...). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-29 03:05 Message: Logged In: YES user_id=33168 This is the code that crashes: from ctypes import * print cast(c_void_p(0), POINTER(c_int)) *** #0 ffi_call_unix+0x20 () at trunk/Modules/_ctypes/libffi/src/ia64/unix.S:63 #1 0x200079194d30:0 in ffi_call (cif=0x7fffe020, fn=0x7913a860, rvalue=0x7fffe090, avalue=0x7fffe070) at trunk/Modules/_ctypes/libffi/src/ia64/ffi.c:372 #2 0x2000791762f0:0 in _call_function_pointer (flags=4101, pProc=0x7913a860, avalues=0x7fffe070, atypes=0x7fffe050, restype=0x40081de8, resmem=0x7fffe090, argcount=3) at trunk/Modules/_ctypes/callproc.c:665 #3 0x2000791781d0:0 in _CallProc (pProc=0x7913a860, argtuple=0x401cdd78, flags=4101, argtypes=0x401ef7b8, restype=0x400eacd8, checker=0x0) at trunk/Modules/_ctypes/callproc.c:1001 #4 0x200079165350:0 in CFuncPtr_call (self=0x4007abe8, inargs=0x401cdd78, kwds=0x0) at trunk/Modules/_ctypes/_ctypes.c:3364 *** Also note there are a bunch of errors like this: Warning: could not import ctypes.test.test_cfuncs: Unsatisfied code symbol '__divsf3' in load module 'trunk/build/lib.hp-ux-B.11.23-ia64-2.6/_ctypes_test.so'. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-25 10:41 Message: Logged In: YES user_id=21627 You will need to run Python in a debugger and find out where it crashes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1649100 ] Arithmetics behaving strange and magic underscore
Bugs item #1649100, was opened at 2007-01-31 18:36 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649100&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.4 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Sascha Peilicke (lastmohican) Assigned to: Nobody/Anonymous (nobody) Summary: Arithmetics behaving strange and magic underscore Initial Comment: Hello, i just found some strange things going around, could you please tell me if this is desired: >>> 3 + 4 7 >>> 3 +- 4 -1 >>> 3 +-+ 4 -1 >>> 3 +-+- 4 7 >>> 3 +-+-+ 4 7 >>> 3 +-+-+- 4 -1 >>> 3 +-+-+-+ 4 -1 >>> 3 +-+-+-+- 4 7 This was found in Python 2.4.4c1. And also another one: >>> _ Traceback (most recent call last): File "", line 1, in ? NameError: name '_' is not defined >>> 3 == 3 True >>> _ True >>> 3 3 >>> _ 3 So what the hell is '_' something very strange indeed. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-01-31 20:22 Message: Logged In: YES user_id=849994 Originator: NO In your first example, all + and - except the first + are seen as unary operators and modify the 4. In your second example: "_" is a convenience variable in the interactive interpreter and always bound to the latest expression result. At startup, there is no such result. -- Comment By: Sascha Peilicke (lastmohican) Date: 2007-01-31 18:39 Message: Logged In: YES user_id=1465593 Originator: YES I also found these working on the following: Python 2.5 (r25:51908, Oct 6 2006, 15:22:41) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2 Seems to be a common 'problem' ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649100&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1582742 ] Python is dumping core after the test test_ctypes
Bugs item #1582742, was opened at 2006-10-23 11:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Thomas Heller (theller) Summary: Python is dumping core after the test test_ctypes Initial Comment: Hi , Iam building Python-2.5 on HPUX Itanium. The compilation is done without any error, but while testing the same using gmake test it is dumping core telling "Segementation Fault" after the test test_ctypes. Please help me in resolving the above issue.Iam attaching the output of gmake test. Thanks in advance, -- >Comment By: Thomas Heller (theller) Date: 2007-01-31 22:00 Message: Logged In: YES user_id=11105 Originator: NO I did also try the Python 2.5 release tarball and could not reproduce the bug. Machine info: bash-3.00$ uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license bash-3.00$ gcc --version gcc (GCC) 3.4.3 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. bash-3.00$ ./python Python 2.5 (r25:51908, Jan 31 2007, 15:56:22) [GCC 3.4.3] on hp-ux11 Type "help", "copyright", "credits" or "license" for more information. >>> bash-3.00$ -- Comment By: Thomas Heller (theller) Date: 2007-01-31 21:15 Message: Logged In: YES user_id=11105 Originator: NO I finally found time (and energy) to try out the td176 HPUX host on HP testdrive. I downloaded the python25.tar.bz2 snapshot from svn.python.org, and built it with the installed gcc 3.4.3. First, I got errors in the ctypes tests because the _ctypes_test extension/shared library could not be loaded because of a missing symbol __divsf3. Googling around I found http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html which mentions a GCC runtime library libgcc.a (see the link 'soft float library routines' on ths page). When this library is specified when building _ctypes_test.so, all ctypes unittests pass. Without any crash. It is strange, to link against the libgcc.a library it seems needed to specify the location of the library '/usr/local/lib/gcc/ia64-hp-hpux11.23/3.4.3/' - no idea why. Can some HPUX guru provide some insight? The attached patch to setup.py is what was needed, but it is a hack of course. File Added: setup.py.patch -- Comment By: Thomas Heller (theller) Date: 2006-11-02 22:02 Message: Logged In: YES user_id=11105 Neal, I see no connection between the code that you show and the stack dump. For the failure when importing ctypes.test.test_cfuncs it seems that a library (?) is missing that _ctypes_test.so requires. Any idea? (I know that HP offers shell access to HPUX boxes, but I hesitate to try that out...). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-29 03:05 Message: Logged In: YES user_id=33168 This is the code that crashes: from ctypes import * print cast(c_void_p(0), POINTER(c_int)) *** #0 ffi_call_unix+0x20 () at trunk/Modules/_ctypes/libffi/src/ia64/unix.S:63 #1 0x200079194d30:0 in ffi_call (cif=0x7fffe020, fn=0x7913a860, rvalue=0x7fffe090, avalue=0x7fffe070) at trunk/Modules/_ctypes/libffi/src/ia64/ffi.c:372 #2 0x2000791762f0:0 in _call_function_pointer (flags=4101, pProc=0x7913a860, avalues=0x7fffe070, atypes=0x7fffe050, restype=0x40081de8, resmem=0x7fffe090, argcount=3) at trunk/Modules/_ctypes/callproc.c:665 #3 0x2000791781d0:0 in _CallProc (pProc=0x7913a860, argtuple=0x401cdd78, flags=4101, argtypes=0x401ef7b8, restype=0x400eacd8, checker=0x0) at trunk/Modules/_ctypes/callproc.c:1001 #4 0x200079165350:0 in CFuncPtr_call (self=0x4007abe8, inargs=0x401cdd78, kwds=0x0) at trunk/Modules/_ctypes/_ctypes.c:3364 *** Also note there are a bunch of errors like this: Warning: could not import ctypes.test.test_cfuncs: Unsatisfied code symbol '__divsf3' in load module 'trunk/build/lib.hp-ux-B.11.23-ia64-2.6/_ctypes_test.so'. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-25 10:41 Message: Logged In: YES user_id=21627 You will need to run Python in a debugger and find out where it crashes. -- You can respond by visi
[ python-Bugs-933670 ] pty.fork() leaves slave fd's open on Solaris
Bugs item #933670, was opened at 2004-04-12 10:21 Message generated for change (Comment added) made by dmeranda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=933670&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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Scott Lowrey (slowrey) Assigned to: Nobody/Anonymous (nobody) Summary: pty.fork() leaves slave fd's open on Solaris Initial Comment: On a Solaris 2.8 system, slave file descriptors are left open after the child process is gone and the master has been closed. The pty.fork() function attempts to use os.forkpty() first. When that fails (apparently the os module does not provide forkpty() on Solaris?), it uses openpty() and os.fork(). openpty() returns master and slave file descriptors. Since pty.fork() only returns the master_fd, it is not clear to me how the slave would ever be closed since the caller doesn't have access to it. Perhaps pty.fork is supposed to take care of this? I am using pexpect to control my pty's, so I don't have much expertise in this area other than what I've gleaned from the code. At any rate, on a long running process used to test other programs, the open file descriptors pile up until the ulimit is reached. I've worked around this by modifying pexpect.close() to use os.close(self.child_fd + 1). A hack, I'm sure... :) -- Comment By: Deron Meranda (dmeranda) Date: 2007-01-31 16:00 Message: Logged In: YES user_id=847188 Originator: NO I am seeing the exact same problem under HP-UX 11.0 (python 2.5). Slave descriptors are leaked. This is a problem with Python's pty.fork(), not with pexpect. -- Comment By: HyunKook Kim (k5r2a) Date: 2004-08-27 04:07 Message: Logged In: YES user_id=604333 Thank you very much for your comments My Case is same to yours. -platform : Solaris 5.8 -Python : 2.3.3 -pyexpect: 0.99 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=933670&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1582742 ] Python is dumping core after the test test_ctypes
Bugs item #1582742, was opened at 2006-10-23 11:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Thomas Heller (theller) Summary: Python is dumping core after the test test_ctypes Initial Comment: Hi , Iam building Python-2.5 on HPUX Itanium. The compilation is done without any error, but while testing the same using gmake test it is dumping core telling "Segementation Fault" after the test test_ctypes. Please help me in resolving the above issue.Iam attaching the output of gmake test. Thanks in advance, -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-31 22:58 Message: Logged In: YES user_id=21627 Originator: NO Thomas, the libgcc problem might be a gcc installation problem. Just specifying -lgcc should be enough to get libgcc linked in. Furthermore, depending on how the linking is done (gcc -shared?), it shouldn't be necessary *at all* to provide -lgcc. This isn't so much a HPUX question but more a gcc question: if you link with gcc, it *ought* to work (if you link with ld(1), you are on your own). -- Comment By: Thomas Heller (theller) Date: 2007-01-31 22:00 Message: Logged In: YES user_id=11105 Originator: NO I did also try the Python 2.5 release tarball and could not reproduce the bug. Machine info: bash-3.00$ uname -a HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license bash-3.00$ gcc --version gcc (GCC) 3.4.3 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. bash-3.00$ ./python Python 2.5 (r25:51908, Jan 31 2007, 15:56:22) [GCC 3.4.3] on hp-ux11 Type "help", "copyright", "credits" or "license" for more information. >>> bash-3.00$ -- Comment By: Thomas Heller (theller) Date: 2007-01-31 21:15 Message: Logged In: YES user_id=11105 Originator: NO I finally found time (and energy) to try out the td176 HPUX host on HP testdrive. I downloaded the python25.tar.bz2 snapshot from svn.python.org, and built it with the installed gcc 3.4.3. First, I got errors in the ctypes tests because the _ctypes_test extension/shared library could not be loaded because of a missing symbol __divsf3. Googling around I found http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html which mentions a GCC runtime library libgcc.a (see the link 'soft float library routines' on ths page). When this library is specified when building _ctypes_test.so, all ctypes unittests pass. Without any crash. It is strange, to link against the libgcc.a library it seems needed to specify the location of the library '/usr/local/lib/gcc/ia64-hp-hpux11.23/3.4.3/' - no idea why. Can some HPUX guru provide some insight? The attached patch to setup.py is what was needed, but it is a hack of course. File Added: setup.py.patch -- Comment By: Thomas Heller (theller) Date: 2006-11-02 22:02 Message: Logged In: YES user_id=11105 Neal, I see no connection between the code that you show and the stack dump. For the failure when importing ctypes.test.test_cfuncs it seems that a library (?) is missing that _ctypes_test.so requires. Any idea? (I know that HP offers shell access to HPUX boxes, but I hesitate to try that out...). -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-29 03:05 Message: Logged In: YES user_id=33168 This is the code that crashes: from ctypes import * print cast(c_void_p(0), POINTER(c_int)) *** #0 ffi_call_unix+0x20 () at trunk/Modules/_ctypes/libffi/src/ia64/unix.S:63 #1 0x200079194d30:0 in ffi_call (cif=0x7fffe020, fn=0x7913a860, rvalue=0x7fffe090, avalue=0x7fffe070) at trunk/Modules/_ctypes/libffi/src/ia64/ffi.c:372 #2 0x2000791762f0:0 in _call_function_pointer (flags=4101, pProc=0x7913a860, avalues=0x7fffe070, atypes=0x7fffe050, restype=0x40081de8, resmem=0x7fffe090, argcount=3) at trunk/Modules/_ctypes/callproc.c:665 #3 0x2000791781d0:0 in _CallProc (pProc=0x7913a860, argtuple=0x401cdd78, flags=4101, argtypes=0x401ef7b8, restype=0x400eacd8, checker=0x0) at trunk/Modules/_ctypes/callproc.c:1001 #4 0x200079165350:0 in CFuncPtr_call (self=0x4007abe8, inargs=0x401cdd78, kwds=0x0) at trunk/Modules
[ python-Bugs-1648890 ] HP-UX: ld -Wl,+b...
Bugs item #1648890, was opened at 2007-01-31 14:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Johannes Abt (jabt) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX: ld -Wl,+b... Initial Comment: On HP-UX 11.* (here: 11.23), configure chooses "ld -b" for extension modules like unicodedata.so. My $LDFLAGS contains instructions like "-Wl,+b" (run-time search path for shared libs). This is correct, because LDFLAGS should be passed to the compiler. distutils compiles the extension modules with "cc" (I need to use the native compiler), then it links with ld -b $(LDFLAGS) -I ... These means that options like -Wl, and -I are passed to the linker! To solve this problem quickly, I propose to modify configure. If LDSHARED="cc -b", Python 2.5 compiles. Though this works very godd with with current HP-UX compilers, it does not work with ancient HP-UX compiler suites. Maybe there should be a test in configure in order to see if LDSHARED works. If you really want to support old HP-UX compilers, distutils should not - pass $LDFLAGS containing "-Wl," to "ld" nor - call the linker with -I. This is the current state of the linker call: ld -b -L/usr/local/python/2.5/lib/hpux32 -Wl,+b,/usr/local/python/2.5/lib/hpux32:/usr/local/devel/readline/5.1-static/lib/hpux32:/usr/local/ssl/lib:/usr/local/devel/bzip-1.0.3/lib/hpux32:/usr/local/devel/berkeleydb/4.3.29-static/lib:/usr/local/lib/hpux32 -L/usr/local/devel/readline/5.1-static/lib/hpux32 -Wl,+b,/usr/local/devel/readline/5.1-static/lib/hpux32:/usr/local/ssl/lib:/usr/local/devel/bzip-1.0.3/lib/hpux32:/usr/local/devel/berkeleydb/4.3.29-static/lib:/usr/local/lib/hpux32 -L/usr/local/ssl/lib -Wl,+b,/usr/local/ssl/lib:/usr/local/devel/bzip-1.0.3/lib/hpux32:/usr/local/devel/berkeleydb/4.3.29-static/lib:/usr/local/lib/hpux32 -L/usr/local/devel/bzip-1.0.3/lib/hpux32 -Wl,+b,/usr/local/devel/bzip-1.0.3/lib/hpux32:/usr/local/devel/berkeleydb/4.3.29-static/lib:/usr/local/lib/hpux32 -L/usr/local/devel/berkeleydb/4.3.29-static/lib -Wl,+b,/usr/local/devel/berkeleydb/4.3.29-static/lib:/usr/local/lib/hpux32 -L/usr/local/lib/hpux32 -Wl,+b,/usr/local/lib/hpux32 -I. -I/soft/python/python-2.5/Python-2.5/Include -I/usr/local/include -I/usr/local/devel/berkeleydb/4.3.29-static/include -I/usr/local/devel/bzip-1.0.3/include -I/usr/local/ssl/include -I/usr/local/devel/readline/5.1-static/include build/temp.hp-ux-B.11.23-ia64-2.5/soft/python/python-2.5/Python-2.5/Modules/readline.o -L/usr/lib/termcap -L/usr/local/python/2.5/lib -L/usr/local/lib -lreadline -o build/lib.hp-ux-B.11.23-ia64-2.5/readline.so -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-31 23:00 Message: Logged In: YES user_id=21627 Originator: NO I personally wouldn't have any issues with breaking old HPUX installations if that helps current ones. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1648890&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1649100 ] Arithmetics behaving strange and magic underscore
Bugs item #1649100, was opened at 2007-01-31 19:36 Message generated for change (Comment added) made by lastmohican You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649100&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.4 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Sascha Peilicke (lastmohican) Assigned to: Nobody/Anonymous (nobody) Summary: Arithmetics behaving strange and magic underscore Initial Comment: Hello, i just found some strange things going around, could you please tell me if this is desired: >>> 3 + 4 7 >>> 3 +- 4 -1 >>> 3 +-+ 4 -1 >>> 3 +-+- 4 7 >>> 3 +-+-+ 4 7 >>> 3 +-+-+- 4 -1 >>> 3 +-+-+-+ 4 -1 >>> 3 +-+-+-+- 4 7 This was found in Python 2.4.4c1. And also another one: >>> _ Traceback (most recent call last): File "", line 1, in ? NameError: name '_' is not defined >>> 3 == 3 True >>> _ True >>> 3 3 >>> _ 3 So what the hell is '_' something very strange indeed. -- >Comment By: Sascha Peilicke (lastmohican) Date: 2007-01-31 23:07 Message: Logged In: YES user_id=1465593 Originator: YES Ok, claryfies something, but i don't think, that this should be valid syntax. Maybe it is not a real bug, but definitly a gotcha. -- Comment By: Georg Brandl (gbrandl) Date: 2007-01-31 21:22 Message: Logged In: YES user_id=849994 Originator: NO In your first example, all + and - except the first + are seen as unary operators and modify the 4. In your second example: "_" is a convenience variable in the interactive interpreter and always bound to the latest expression result. At startup, there is no such result. -- Comment By: Sascha Peilicke (lastmohican) Date: 2007-01-31 19:39 Message: Logged In: YES user_id=1465593 Originator: YES I also found these working on the following: Python 2.5 (r25:51908, Oct 6 2006, 15:22:41) [GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu4)] on linux2 Seems to be a common 'problem' ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649100&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1649238 ] potential class with C++ in ceval.h
Bugs item #1649238, was opened at 2007-01-31 16:16 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=1649238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: thechao (jaroslov) Assigned to: Nobody/Anonymous (nobody) Summary: potential class with C++ in ceval.h Initial Comment: There is a potential clash with future revisions of C++ in the file "ceval.h". On lines 52, 54, and 57 the word "where" is used. Future versions of C++ will have a "where" keyword (for concepts). I have a diff file (attached) that changes the word "where" to "location". I'm not sure if this is an appropriate name, but it certainly compiles. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649238&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1649238 ] potential clash with C++ in ceval.h
Bugs item #1649238, was opened at 2007-01-31 16:16 Message generated for change (Settings changed) made by jaroslov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: thechao (jaroslov) Assigned to: Nobody/Anonymous (nobody) >Summary: potential clash with C++ in ceval.h Initial Comment: There is a potential clash with future revisions of C++ in the file "ceval.h". On lines 52, 54, and 57 the word "where" is used. Future versions of C++ will have a "where" keyword (for concepts). I have a diff file (attached) that changes the word "where" to "location". I'm not sure if this is an appropriate name, but it certainly compiles. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649238&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-933670 ] pty.fork() leaves slave fd's open on Solaris
Bugs item #933670, was opened at 2004-04-12 14:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=933670&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.3 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Scott Lowrey (slowrey) Assigned to: Nobody/Anonymous (nobody) Summary: pty.fork() leaves slave fd's open on Solaris Initial Comment: On a Solaris 2.8 system, slave file descriptors are left open after the child process is gone and the master has been closed. The pty.fork() function attempts to use os.forkpty() first. When that fails (apparently the os module does not provide forkpty() on Solaris?), it uses openpty() and os.fork(). openpty() returns master and slave file descriptors. Since pty.fork() only returns the master_fd, it is not clear to me how the slave would ever be closed since the caller doesn't have access to it. Perhaps pty.fork is supposed to take care of this? I am using pexpect to control my pty's, so I don't have much expertise in this area other than what I've gleaned from the code. At any rate, on a long running process used to test other programs, the open file descriptors pile up until the ulimit is reached. I've worked around this by modifying pexpect.close() to use os.close(self.child_fd + 1). A hack, I'm sure... :) -- >Comment By: Georg Brandl (gbrandl) Date: 2007-01-31 22:53 Message: Logged In: YES user_id=849994 Originator: NO This is already fixed in Subversion, see patch #783050. -- Comment By: Deron Meranda (dmeranda) Date: 2007-01-31 21:00 Message: Logged In: YES user_id=847188 Originator: NO I am seeing the exact same problem under HP-UX 11.0 (python 2.5). Slave descriptors are leaked. This is a problem with Python's pty.fork(), not with pexpect. -- Comment By: HyunKook Kim (k5r2a) Date: 2004-08-27 08:07 Message: Logged In: YES user_id=604333 Thank you very much for your comments My Case is same to yours. -platform : Solaris 5.8 -Python : 2.3.3 -pyexpect: 0.99 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=933670&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1372650 ] Cookie and multiple names
Bugs item #1372650, was opened at 2005-12-04 03:47 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Viraj Alankar (valankar) Assigned to: Nobody/Anonymous (nobody) Summary: Cookie and multiple names Initial Comment: The cookie specification described here: http://wp.netscape.com/newsref/std/cookie_spec.html states that multiple names of cookies can be sent. This does not seem to parse correctly with the Cookie module due to its dictionary storage. When parsing cookies via modpython, only the last cookie is used. I think it would be better to only use the first value, since that is what the specification says. Or provide for a way to store multiple names with different paths. -- Comment By: John J Lee (jjlee) Date: 2007-01-31 23:00 Message: Logged In: YES user_id=261020 Originator: NO The discussion of this issue is here: http://python.org/sf/1372650 No conclusion has been reached about whether it should be applied. I've said all I want to say about it already... -- Comment By: John J Lee (jjlee) Date: 2006-12-03 16:49 Message: Logged In: YES user_id=261020 Originator: NO loewis: In the Netscape cookie protocol (which is specified approximately, though ambiguously, and incorrectly in places, by cookie_spec.html), cookies sent from client to server in the Cookie: header do not include the path (neither as "path=/foo/bar", nor even as "$path=/foo/bar"). In valankar's first example of 2005-12-04 16:07, the two cookies must be interpreted as having different paths (if they do not have different paths, the client is not behaving correctly). See the section titled "Second Example transaction sequence:" in cookie_spec.html for an example of this. So, the part of cookie_spec.html you quote is not relevant (in fact, it refers to client behaviour, not server behaviour -- though it doesn't say so explicitly!). BTW, I said earlier: "clients are supposed to (and do) send the most specific cookie last". That's backwards: in fact, clients send the most specific (longest-path) cookie first. Cookie.py always ignores all but the last cookie (it overwrites the first), so it will only store the least-specific cookie, so my point stands. Also note that valankar's second example of 2005-12-04 16:07 is incorrect (unless he meant Set-Cookie: instead of Cookie:): the Cookie header should never contain path cookie-attributes (see penultimate paragraph of this comment, and perhaps more clearly, method cookielib.CookieJar._cookie_attrs()). By "cookie-attribute" I mean a string of the form "=", i.e. the same thing as represented by instances of Cookie.Morsel . AFAIK (not 100% sure here) when several cookies are returned, none of the cookie standards defines which cookie servers should or should not look at, so Cookie.py should probably make all of the cookies available through some interface. If it chooses to only provide one cookie (as it does), it would seem that a good choice would be the first cookie in the string passed to .load(), since that should be the one with the longest path. Cookie.py instead takes the last cookie (probably by accident). That's not good, but I'm unsure whether it should be changed, since it may break old code. I'm puzzled by Cookie.py's design: First, poor naming: BaseCookie (and therefore a SimpleCookie instance) seems to represent multiple HTTP cookies. Second, BaseCookie.load(string) treats attributes like "path" specially, and I do not understand why. The documentation says you're intended to pass the value of HTTP_COOKIE to that string, but AFAICS, if the client obeys any of the cookie protocols (either the de facto Netscape protocol or any of the RFCs) then HTTP_COOKIE should never contain a string like "; path=x", where x is replaced by any arbitrary string (assuming here that HTTP_COOKIE is always simply the value of the HTTP header named "Cookie", and for simplicity that there are no quoted strings in the Cookie header). Third, BaseCookie does not allow storing several cookies of the same name. As I understand it, this last problem is the one valankar was complaining about. I've always found cookies highly confusing, I must say, so it's always possible I've got something mixed up by now... but I don't think so. -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-03 12:44 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the bug. Where in t
[ python-Bugs-1372650 ] Cookie and multiple names
Bugs item #1372650, was opened at 2005-12-04 03:47 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Viraj Alankar (valankar) Assigned to: Nobody/Anonymous (nobody) Summary: Cookie and multiple names Initial Comment: The cookie specification described here: http://wp.netscape.com/newsref/std/cookie_spec.html states that multiple names of cookies can be sent. This does not seem to parse correctly with the Cookie module due to its dictionary storage. When parsing cookies via modpython, only the last cookie is used. I think it would be better to only use the first value, since that is what the specification says. Or provide for a way to store multiple names with different paths. -- Comment By: John J Lee (jjlee) Date: 2007-01-31 23:15 Message: Logged In: YES user_id=261020 Originator: NO Ignore last comment. I thought a patch had been added, but it seems I mixed up the bug and patch trackers. Curse this SF bug/patch tracker distinction! -- Comment By: John J Lee (jjlee) Date: 2007-01-31 23:00 Message: Logged In: YES user_id=261020 Originator: NO The discussion of this issue is here: http://python.org/sf/1372650 No conclusion has been reached about whether it should be applied. I've said all I want to say about it already... -- Comment By: John J Lee (jjlee) Date: 2006-12-03 16:49 Message: Logged In: YES user_id=261020 Originator: NO loewis: In the Netscape cookie protocol (which is specified approximately, though ambiguously, and incorrectly in places, by cookie_spec.html), cookies sent from client to server in the Cookie: header do not include the path (neither as "path=/foo/bar", nor even as "$path=/foo/bar"). In valankar's first example of 2005-12-04 16:07, the two cookies must be interpreted as having different paths (if they do not have different paths, the client is not behaving correctly). See the section titled "Second Example transaction sequence:" in cookie_spec.html for an example of this. So, the part of cookie_spec.html you quote is not relevant (in fact, it refers to client behaviour, not server behaviour -- though it doesn't say so explicitly!). BTW, I said earlier: "clients are supposed to (and do) send the most specific cookie last". That's backwards: in fact, clients send the most specific (longest-path) cookie first. Cookie.py always ignores all but the last cookie (it overwrites the first), so it will only store the least-specific cookie, so my point stands. Also note that valankar's second example of 2005-12-04 16:07 is incorrect (unless he meant Set-Cookie: instead of Cookie:): the Cookie header should never contain path cookie-attributes (see penultimate paragraph of this comment, and perhaps more clearly, method cookielib.CookieJar._cookie_attrs()). By "cookie-attribute" I mean a string of the form "=", i.e. the same thing as represented by instances of Cookie.Morsel . AFAIK (not 100% sure here) when several cookies are returned, none of the cookie standards defines which cookie servers should or should not look at, so Cookie.py should probably make all of the cookies available through some interface. If it chooses to only provide one cookie (as it does), it would seem that a good choice would be the first cookie in the string passed to .load(), since that should be the one with the longest path. Cookie.py instead takes the last cookie (probably by accident). That's not good, but I'm unsure whether it should be changed, since it may break old code. I'm puzzled by Cookie.py's design: First, poor naming: BaseCookie (and therefore a SimpleCookie instance) seems to represent multiple HTTP cookies. Second, BaseCookie.load(string) treats attributes like "path" specially, and I do not understand why. The documentation says you're intended to pass the value of HTTP_COOKIE to that string, but AFAICS, if the client obeys any of the cookie protocols (either the de facto Netscape protocol or any of the RFCs) then HTTP_COOKIE should never contain a string like "; path=x", where x is replaced by any arbitrary string (assuming here that HTTP_COOKIE is always simply the value of the HTTP header named "Cookie", and for simplicity that there are no quoted strings in the Cookie header). Third, BaseCookie does not allow storing several cookies of the same name. As I understand it, this last problem is the one valankar was complaining about. I've always found cookie
[ python-Bugs-1580738 ] httplib hangs reading too much data
Bugs item #1580738, was opened at 2006-10-19 20:06 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dustin J. Mitchell (djmitche) Assigned to: Nobody/Anonymous (nobody) Summary: httplib hangs reading too much data Initial Comment: I'm building an interface to Amazon's S3, using httplib. It uses a single object for multiple transactions. What's happening is this: HTTP > PUT /unitest-temp-1161039691 HTTP/1.1 HTTP > Date: Mon, 16 Oct 2006 23:01:32 GMT HTTP > Authorization: AWS <>:KiTWRuq/ 6aay0bI2J5DkE2TAWD0= HTTP > (end headers) HTTP < HTTP/1.1 200 OK HTTP < content-length: 0 HTTP < x-amz-id-2: 40uQn0OCpTiFcX+LqjMuzG6NnufdUk/.. HTTP < server: AmazonS3 HTTP < x-amz-request-id: FF504E8FD1B86F8C HTTP < location: /unitest-temp-1161039691 HTTP < date: Mon, 16 Oct 2006 23:01:33 GMT HTTPConnection.__state before response.read: Idle HTTPConnection.__response: closed? False length: 0 reading response HTTPConnection.__state after response.read: Idle HTTPConnection.__response: closed? False length: 0 ..later in the same connection.. HTTPConnection.__state before putrequest: Idle HTTPConnection.__response: closed? False length: 0 HTTP > DELETE /unitest-temp-1161039691 HTTP/1.1 HTTP > Date: Mon, 16 Oct 2006 23:01:33 GMT HTTP > Authorization: AWS <>: a5OizuLNwwV7eBUhha0B6rEJ+CQ= HTTP > (end headers) HTTPConnection.__state before getresponse: Request-sent HTTPConnection.__response: closed? False length: 0 File "/usr/lib64/python2.4/httplib.py", line 856, in getresponse raise ResponseNotReady() If the first request does not precede it, the second request is fine. To avoid excessive memory use, I'm calling request.read(16384) repeatedly, instead of just calling request.read(). This seems to be key to the problem -- if I omit the 'amt' argument to read(), then the last line of the first request reads HTTPConnection.__response: closed? True length: 0 and the later call to getresponse() doesn't raise ResponseNotReady. Looking at the source for httplib.HTTPResponse.read, self.close() gets called in the latter (working) case, but not in the former (non-working). It would seem sensible to add 'if self.length == 0: self.close()' to the end of that function (and, in fact, this change makes the whole thing work), but this comment makes me hesitant: # we do not use _safe_read() here because this may be a .will_close # connection, and the user is reading more bytes than will be provided # (for example, reading in 1k chunks) I suspect that either (a) this is a bug or (b) the client is supposed to either call read() with no arguments or calculate the proper inputs to read(amt) based on the Content-Length header. If (b), I would think the docs should be updated to reflect that? Thanks for any assistance. -- Comment By: John J Lee (jjlee) Date: 2007-01-31 23:45 Message: Logged In: YES user_id=261020 Originator: NO I disagree with mhammond. Mark is correct that closing the connection would be wrong, but self.close() in the function in question does *not* close the connection. Client code is not expected to explicitly call HTTPResponse.read() with an explicit amt argument even when persistent connections are involved. All that's required is (of course) that you have to read to the end of the current response before you get to read the next response on that connection. I think Dustin is more or less right in his diagnosis, but I haven't written a patch yet... -- Comment By: Dustin J. Mitchell (djmitche) Date: 2006-10-27 23:53 Message: Logged In: YES user_id=7446 Excellent -- the first paragraph, where you talk about the .length attribute, makes things quite clear, so I agree that (b) is the correct solution: include the content of that paragraph in the documentation. Thanks! -- Comment By: Mark Hammond (mhammond) Date: 2006-10-27 03:21 Message: Logged In: YES user_id=14198 The correct answer is indeed (b) - but note that httplib will itself do the content-length magic for you, including the correct handling of 'chunked' encoding. If the .length attribute is not None, then that is exactly how many bytes you should read. If .length is None, then either chunked encoding is used (in which case you can call read() with a fixed size until it returns an empty string), or no content-length was supplied (which can be treated the same as chunked, but the connection will close at the end. Checking ob.will_
[ python-Bugs-1647037 ] cookielib.CookieJar does not handle cookies when port in url
Bugs item #1647037, was opened at 2007-01-29 12:31
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647037&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: STS (tools-sts)
Assigned to: Nobody/Anonymous (nobody)
Summary: cookielib.CookieJar does not handle cookies when port in url
Initial Comment:
In Python 2.5 the cookielib.CookieJar does not handle cookies (i.e., recognise
the Set-Cookie: header) when the port is specified in the URL.
e.g.,
import urllib2, cookielib
cookiejar = cookielib.CookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cookiejar))
# add proxy to view results
proxy_handler = urllib2.ProxyHandler({'http':'127.0.0.1:8080'})
opener.add_handler(proxy_handler)
# Install opener globally so it can be used with urllib2.
urllib2.install_opener(opener)
# The ':80' will cause the CookieJar to never handle the
# cookie set by Google
request = urllib2.Request('http://www.google.com.au:80/')
response = opener.open(request)
response = opener.open(request) # No Cookie:
# But this works
request = urllib2.Request('http://www.google.com.au/')
response = opener.open(request)
response = opener.open(request)# Cookie: PREF=ID=d2de0..
--
Comment By: John J Lee (jjlee)
Date: 2007-02-01 00:17
Message:
Logged In: YES
user_id=261020
Originator: NO
This is not a bug. If you turn on cookielib logging (see below), you'll
see that Google sends back a cookie for google.com (not .com.au) on the
first request iff you add the port number. That cookie should not be sent
back to the server. My copy of Firefox 1.5.0.9 doesn't send back a cookie
here either.
(note they do send a .com.au cookie when you do a search, presumably
because the search button lands you at a URL without the :80 on the end.
It's probably just a minor oversight or an optimisation that they don't
send the .com.au cookie when you include the :80)
To turn on logging:
import sys, logging
logger = logging.getLogger("cookielib")
logger.addHandler(logging.StreamHandler(sys.stdout))
logger.setLevel(logging.DEBUG)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647037&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1649329 ] gettext.py incompatible with eggs
Bugs item #1649329, was opened at 2007-01-31 18:20 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=1649329&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: gettext.py incompatible with eggs Initial Comment: If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg. That's because gettext.py only knows how to find the translation catalogs in the actual filesystem. This wouldn't be so bad if the "find" function didn't serve double duty. On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks. On the other hand, it actually resolves the files in the filesystem. It would be nice if these were separate. It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem. Perhaps gettext can be updated to know about eggs. Perhaps setting localedir to something like "egg://..." would enable this functionality. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649329&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566611 ] Idle 1.2 - Calltips Hotkey does not work
Bugs item #1566611, was opened at 2006-09-27 13:24 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&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: IDLE Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: fladd (fladd710) Assigned to: Kurt B. Kaiser (kbk) Summary: Idle 1.2 - Calltips Hotkey does not work Initial Comment: Hitting CTRL+Backslash does not show the calltip (which is not shown by default) on Windows Xp with Python 1.5 Final. -- >Comment By: SourceForge Robot (sf-robot) Date: 2007-01-31 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (gbrandl) Date: 2007-01-17 13:29 Message: Logged In: YES user_id=849994 Originator: NO fladd: Please supply the additional information asked for so that we are able to process this bug. Setting status to Pending. -- Comment By: Tal Einat (taleinat) Date: 2006-12-09 09:45 Message: Logged In: YES user_id=1330769 Originator: NO You mean 2.5 final is suppose... Works for me, Python 2.5 final, WinXP Pro. Does this never work or only sometimes? Have you checked you key definitions? Does it work in the Shell window? Please be more specific... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
