[ python-Bugs-1561243 ] mac installer profile patch vs. .bash_login
Bugs item #1561243, was opened at 2006-09-19 09:32 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=1561243&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: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: mac installer profile patch vs. .bash_login Initial Comment: The mac installer for 2.4.3 and 2.5 patches ~/.profile or ~/.bash_profile. If a .bash_login file exists and no .bash_profile exists the installer currently creates a .profile, which won't be used by bash. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561243&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1561333 ] -xcode=pic32 option is not supported on Solaris x86 Sun C
Bugs item #1561333, was opened at 2006-09-19 18:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561333&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: James Lick (jlick) Assigned to: Nobody/Anonymous (nobody) Summary: -xcode=pic32 option is not supported on Solaris x86 Sun C Initial Comment: Python's ./configure script on Solaris systems sets the compiler flag -xcode=pic32 when Sun C is used. Unfortunately, the -xcode flag is only available in the sparc version of Sun C. The x86 version of Sun C does not support the -xcode option at all and generates a warning that an illegal option was used. The portable flag supported on both platforms to use independent 32-bit addressing is -KPIC. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1561333&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-1561634 ] String searching performance improvement
Feature Requests item #1561634, was opened at 2006-09-19 12:55 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=1561634&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: Performance Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Nick Welch (mackstann) Assigned to: Nobody/Anonymous (nobody) Summary: String searching performance improvement Initial Comment: The current string searching (str.find) seems to use the simplest possible method of searching, which is simply comparing character by character. A simple speed improvement would be to take needle[-1] and start searching at haystack[len(needle)-1]. Then check again at haystack[len(needle)*2-1]. etc. If the last character doesn't match, then the rest of the string couldn't possibly match. I'm sure there are other methods of speeding up string searching but this seems like a pretty simple and easy improvement. If I have some time I will go ahead and try implementing it myself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1561634&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086642 ] Compile of _socket fails on 2.4
Bugs item #1086642, was opened at 2004-12-16 12:21 Message generated for change (Comment added) made by amcnabb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension -- Comment By: Andrew McNabb (amcnabb) Date: 2006-09-19 15:26 Message: Logged In: YES user_id=1234027 I'm having this same problem with Python 2.5. I checked, and "/usr/lib/libmpc.a" is present. I've only tried with gcc, and I'm getting the exact same errors as above. -- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2005-01-11 10:56 Message: Logged In: YES user_id=71407 Before giving up I'd try to reset PATH before running configure in the Python directory. I had all kinds of trouble with the freeware tools on path. Here is what I use: /usr/bin /usr/bsd /bin /usr/sbin /sbin /etc /usr/etc /usr/bin/X11 Python 2.4 really works under IRIX, incl. the socket module. I have it going on three different machines. On one machine the timestamp for libmpc.a is from 1998! -- Comment By: A. Stocker (akosprime) Date: 2005-01-11 10:43 Message: Logged In: YES user_id=1179755 Ralf, Strange, I DO have that library: ls -l /usr/lib/libmpc* -r--r--r--1 root sys 1220 Mar 13 2001 /usr/lib/libmpc.a It makes no sense to me that the SGI MIPS compilers can't find a library that's in a default location. Very peculiar. I guess I'm just going to have to give up on getting Python 2.4 working completely under Irix. We need both network and _locale to work in order for the various scripts we have in place to work correctly and I can't get it to compile with gcc. [*sigh*] -- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2005-01-11 10:32 Message: Logged In: YES user_id=71407 You are missing a system library: /usr/lib/libmpc.a I've never done anything special to install this library but it is available on all three IRIX systems that I have access to. The library is not used to resolve any symbols. I guess y
[ python-Bugs-1086642 ] Compile of _socket fails on 2.4
Bugs item #1086642, was opened at 2004-12-16 12:21 Message generated for change (Comment added) made by amcnabb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension -- Comment By: Andrew McNabb (amcnabb) Date: 2006-09-19 15:42 Message: Logged In: YES user_id=1234027 When I use the native IRIX cc to compile socketmodule.c in Python 2.5, I get: cc -OPT:Olimit=0 -DNDEBUG -O -I. -I/auto/fsc/awm27/bzr/Python-2.5/./Include -I/fsc/awm27/i nclude -I./Include -I. -I/usr/local/include -I/auto/fsc/awm27/bzr/Python-2.5/Include -I/au to/fsc/awm27/bzr/Python-2.5 -c /auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.c -o bu ild/temp.irix64-6.5-2.5/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.o cc-1047 cc: WARNING File = /usr/include/sys/param.h, Line = 372 Macro "MAX" (declared at line 77 of "/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.c") has an incompatible redefinition. #define MAX(a,b) (((a)>(b))?(a):(b)) ^ When I commented out the macro definition in socketmodule.c, I was able to get it to compile (with the IRIX compiler). It seems to me that --without-gcc should be the default for IRIX until the gcc problem gets fixed because ./configure is currently automatically choosing gcc as the compiler when both are available. And I'm really not sure why the "#undef MAX" didn't happen. Anyway, I hope this is helpful for someone. -- Comment By: Andrew McNabb (amcnabb) Date: 2006-09-19 15:26 Message: Logged In: YES user_id=1234027 I'm having this same problem with Python 2.5. I checked, and "/usr/lib/libmpc.a" is present. I've only tried with gcc, and I'm getting the exact same errors as above. -- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2005-01-11 10:56 Message: Logged In: YES user_id=71407 Before giving up I'd try to reset PATH before running configure in the Python directory. I had all kinds of trouble with the freeware tools on path. Here is what I use: /usr/bin /usr/bsd /bin /usr/sbin /sbin /etc
[ python-Feature Requests-1561634 ] String searching performance improvement
Feature Requests item #1561634, was opened at 2006-09-19 12:55 Message generated for change (Settings changed) made by mackstann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1561634&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: Performance Group: Python 2.6 >Status: Deleted Resolution: None Priority: 5 Submitted By: Nick Welch (mackstann) Assigned to: Nobody/Anonymous (nobody) Summary: String searching performance improvement Initial Comment: The current string searching (str.find) seems to use the simplest possible method of searching, which is simply comparing character by character. A simple speed improvement would be to take needle[-1] and start searching at haystack[len(needle)-1]. Then check again at haystack[len(needle)*2-1]. etc. If the last character doesn't match, then the rest of the string couldn't possibly match. I'm sure there are other methods of speeding up string searching but this seems like a pretty simple and easy improvement. If I have some time I will go ahead and try implementing it myself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1561634&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1550791 ] UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14
Bugs item #1550791, was opened at 2006-09-01 22:23 Message generated for change (Comment added) made by dmpotts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open >Resolution: Invalid Priority: 5 Submitted By: Davin (dmpotts) Assigned to: Martin v. Löwis (loewis) Summary: UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14 Initial Comment: PROBLEM DESCRIPTION: UCS-4 tcl is not found during configuration on a SUSE 10.1 (x86-32) system where tk-8.4.12-14 and tcl-8.4.12-14 have been installed as part of the SUSE installation (and visible/managed by YaST). This results in _tkinter and dependent codes not being built. EXPECTED BEHAVIOUR: The installed tcl/tk packages (provided as part of the SUSE 10.1 install) should have been detected successfully and _tkinter and related packages should have been configured for build. TO REPRODUCE: Install SUSE 10.1 on x86 hardware, taking care to ensure that tcl and tk packages are included in that install. Download, expand, and attempt to configure Python 2.5 release candidate 1 (Python-2.5c1.tar.bz2). Note that the following occurs during configuration and that _tkinter is subsequently not built: checking for UCS-4 tcl... no -- >Comment By: Davin (dmpotts) Date: 2006-09-20 00:26 Message: Logged In: YES user_id=1588828 Excellent question -- they appear to be absent -- that would explain a thing or two. Apologies for the confusion -- changing status to Invalid. -- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-09-10 07:27 Message: Logged In: YES user_id=250749 Where are tcl.h and tk.h on this system? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1008295 ] logging.getLevelName returns a number
Bugs item #1008295, was opened at 2004-08-12 23:56 Message generated for change (Comment added) made by stevepole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&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: Fixed Priority: 5 Submitted By: Paulo Eduardo Neves (neves) Assigned to: Vinay Sajip (vsajip) Summary: logging.getLevelName returns a number Initial Comment: logging.getLevelName function doc says that it returns the "textual representation of logging level", but if the argument is already the level name, the log level integer is returned. It should return the argument. The problem is that if I add my own levels, and call LoggerInstance.log( levelName, message ), the formatter will save the level number in the log, insted of the desired level name. -- Comment By: Steve Pole (stevepole) Date: 2006-09-20 06:06 Message: Logged In: YES user_id=455201 I understand this is not a bug, it's by design. It still looks like a bug, though. Please consider the following code: import logging defaultLoglevel = logging.DEBUG newLoglevel = 'WARNING' logging.basicConfig (level = defaultLoglevel, format = '%(message)s') print logging.getLevelName (logging.getLogger ().getEffectiveLevel ()) print logging.getLogger ().getEffectiveLevel () logging.getLogger ().setLevel (newLoglevel.upper ()) print logging.getLevelName (logging.getLogger ().getEffectiveLevel ()) print logging.getLogger ().getEffectiveLevel () Output: DEBUG 10 30 WARNING So the result basically inverts. Is that really the way it is supposed to work ? Or am I misunderstanding something ? -- Comment By: Vinay Sajip (vsajip) Date: 2004-08-20 14:36 Message: Logged In: YES user_id=308438 This is not a bug, it's by design. Current CVS throws an exception if raiseExceptions is set and you pass anything other than an integer as the log level. The CVS documentation has also been updated to clarify that the level passed in is the integer rather than the level name. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1550791 ] UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14
Bugs item #1550791, was opened at 2006-09-02 00:23 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Davin (dmpotts) Assigned to: Martin v. Löwis (loewis) Summary: UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14 Initial Comment: PROBLEM DESCRIPTION: UCS-4 tcl is not found during configuration on a SUSE 10.1 (x86-32) system where tk-8.4.12-14 and tcl-8.4.12-14 have been installed as part of the SUSE installation (and visible/managed by YaST). This results in _tkinter and dependent codes not being built. EXPECTED BEHAVIOUR: The installed tcl/tk packages (provided as part of the SUSE 10.1 install) should have been detected successfully and _tkinter and related packages should have been configured for build. TO REPRODUCE: Install SUSE 10.1 on x86 hardware, taking care to ensure that tcl and tk packages are included in that install. Download, expand, and attempt to configure Python 2.5 release candidate 1 (Python-2.5c1.tar.bz2). Note that the following occurs during configuration and that _tkinter is subsequently not built: checking for UCS-4 tcl... no -- Comment By: Davin (dmpotts) Date: 2006-09-20 02:26 Message: Logged In: YES user_id=1588828 Excellent question -- they appear to be absent -- that would explain a thing or two. Apologies for the confusion -- changing status to Invalid. -- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-09-10 09:27 Message: Logged In: YES user_id=250749 Where are tcl.h and tk.h on this system? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
