[ python-Bugs-1305706 ] windows unicode write is messing up the EOL.
Bugs item #1305706, was opened at 2005-09-27 13:43 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=1305706&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: Istvan Visegradi (visike) Assigned to: Nobody/Anonymous (nobody) Summary: windows unicode write is messing up the EOL. Initial Comment: User has an Unicode UTF-16 input file and trys to read it line-by-line and write it back to a new file. With the read line the program does nothing. code example: ... ln=fi.readline() fo.write(ln) ... In linux this code works perfectly with the input UTF-16 type file. In windows Python put an extra \x0D into the EOL. EOL should look like: 0D 00 0A 00 In windows it will be: 0D 00 0D 0A 00 Please inform when correction is available. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1305706&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1302793 ] 2.4.1 windows MSI has no _socket
Bugs item #1302793, was opened at 2005-09-24 07:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&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: IamPaul (heartlesshind) Assigned to: Martin v. Löwis (loewis) Summary: 2.4.1 windows MSI has no _socket Initial Comment: The precompiled windows binary installer doesn't seem to provide a _socket module eg. >>> import urllib Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\Lib\urllib.py", line 26, in ? import socket File "c:\Python24\Lib\socket.py", line 45, in ? import _socket ImportError: No module named _socket This bears some resemblance to [ 1298709 ] -- >Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 16:05 Message: Logged In: YES user_id=21627 Unfortunately, I cannot reproduce the problem. What specific file did you download and install? What is the contents of the DLLs directory? Do you have, by any chance, PYTHONPATH or PYTHONHOME set? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI
Bugs item #1298962, was opened at 2005-09-22 19:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&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: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) >Assigned to: Martin v. Löwis (loewis) Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 16:09 Message: Logged In: YES user_id=21627 Unfortunately, I cannot reproduce the problem. On my system, the power user can install to a different drive or directory just fine, and I get no message "Ignoring disallowed property". What operating system are you using? Can you please attach a compressed copy of the log? -- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-25 13:27 Message: Logged In: YES user_id=597393 Yes, I forgot to mention that this means the installer always tries to put pythons root directory in your root C:\ directory, which is in any case messy, and in my case, a showstopper, as I need to install to another drive. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-25 06:35 Message: Logged In: YES user_id=21627 What specific problems did you run into? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1306043 ] Syntax error in Python Library Reference, 6.1.4. Files ...
Bugs item #1306043, was opened at 2005-09-27 18:56
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=1306043&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schliep (schliep)
Assigned to: Nobody/Anonymous (nobody)
Summary: Syntax error in Python Library Reference, 6.1.4. Files ...
Initial Comment:
See http://docs.python.org/lib/os-file-dir.html
Python Library Reference, first example in Section
6.1.4 Files and Directories has an obvious syntax error.
import os
from os.path import join, getsize
for root, dirs, files in os.walk('python/Lib/email'):
print root, "consumes",
print sum(getsize(join(root, name)) for name in
files), #error
print "bytes in", len(files), "non-directory files"
if 'CVS' in dirs:
dirs.remove('CVS') # don't visit CVS directories
Should be
print sum([getsize(join(root, name)) for name in
files]),
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1306043 ] Syntax error in Python Library Reference, 6.1.4. Files ...
Bugs item #1306043, was opened at 2005-09-27 18:56
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306043&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.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Alexander Schliep (schliep)
Assigned to: Nobody/Anonymous (nobody)
Summary: Syntax error in Python Library Reference, 6.1.4. Files ...
Initial Comment:
See http://docs.python.org/lib/os-file-dir.html
Python Library Reference, first example in Section
6.1.4 Files and Directories has an obvious syntax error.
import os
from os.path import join, getsize
for root, dirs, files in os.walk('python/Lib/email'):
print root, "consumes",
print sum(getsize(join(root, name)) for name in
files), #error
print "bytes in", len(files), "non-directory files"
if 'CVS' in dirs:
dirs.remove('CVS') # don't visit CVS directories
Should be
print sum([getsize(join(root, name)) for name in
files]),
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-27 19:46
Message:
Logged In: YES
user_id=1188172
No, sorry. The docs you are referring to are the docs for
Python 2.4, and Python 2.4 introduces so-called "generator
expressions", and this is one.
See http://docs.python.org/whatsnew/node4.html for more
information.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI
Bugs item #1298962, was opened at 2005-09-22 19:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&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: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Martin v. Löwis (loewis) Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 21:51 Message: Logged In: YES user_id=21627 In additon, can you please provide the settings under HKEY_CURRENT_USER\Software\Policies\Microsoft Windows\Installer and HKEY_LOCAL_MACHINE\Software\Policies\Microsoft Windows\Installer on your machine? If possible, can you try setting EnableUserControl to (DWORD)1 under the HKLM key? -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 16:09 Message: Logged In: YES user_id=21627 Unfortunately, I cannot reproduce the problem. On my system, the power user can install to a different drive or directory just fine, and I get no message "Ignoring disallowed property". What operating system are you using? Can you please attach a compressed copy of the log? -- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-25 13:27 Message: Logged In: YES user_id=597393 Yes, I forgot to mention that this means the installer always tries to put pythons root directory in your root C:\ directory, which is in any case messy, and in my case, a showstopper, as I need to install to another drive. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-25 06:35 Message: Logged In: YES user_id=21627 What specific problems did you run into? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1305706 ] windows unicode write is messing up the EOL.
Bugs item #1305706, was opened at 2005-09-27 12:43
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1305706&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: Istvan Visegradi (visike)
Assigned to: Nobody/Anonymous (nobody)
Summary: windows unicode write is messing up the EOL.
Initial Comment:
User has an Unicode UTF-16 input file and trys to read
it line-by-line and write it back to a new file.
With the read line the program does nothing.
code example:
...
ln=fi.readline()
fo.write(ln)
...
In linux this code works perfectly with the input
UTF-16 type file.
In windows Python put an extra \x0D into the EOL.
EOL should look like: 0D 00 0A 00
In windows it will be: 0D 00 0D 0A 00
Please inform when correction is available.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-09-27 21:57
Message:
Logged In: YES
user_id=21627
Can you provide a small test program that demonstrates the
problem?
I cannot reproduce it:
>>> f=codecs.open("f.txt","w",encoding="utf-16")
>>> f.write(u"Hallo\n")
>>> f.write(u"Welt\r\n")
>>> f.close()
>>> open("f.txt").read()
'\xff\xfeH\x00a\x00l\x00l\x00o\x00\n\x00W\x00e\x00l\x00t\x00\r\x00\n\x00'
This looks right to me.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1305706&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-1303434 ] Please include pdb with windows distribution
Feature Requests item #1303434, was opened at 2005-09-24 21:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&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: None Status: Open Resolution: None Priority: 5 Submitted By: Lyle Thompson (lylefile) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pdb with windows distribution Initial Comment: Checking out the source files and rebuilding is not guaranteed to build a program database (pdb) file that represents the distribution python DLL. This may be due to a differences in the windows version or visual studio service pack on my system vs the one used to build the distribution, but tracking it down can be very time consuming. Including the pdb in the distribution should be trivial and avoid this problem entirely. Although I can fix the problem for future releases of our product, I am also supporting previous releases that included the standard DLL included in the distribution. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 22:03 Message: Logged In: YES user_id=21627 Including the PDB files in the MSI is probably not acceptable to the majority of the users. python24.pdb is 3.5MiB in size, so the MSI file to download would grow considerably. Why do you need the PDB file in the first place? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1303434&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1306211 ] Python 2.4.2c1 fails to build for 64-bit Solaris 9/10
Bugs item #1306211, was opened at 2005-09-27 20: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=1306211&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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build for 64-bit Solaris 9/10 Initial Comment: Python 2.4.2c1 fails to compile on Solaris 10, yielding the following errors immediately in the build: % setenv CC "cc" % ./configure --prefix=/tmp/foo/pytest --without-pymalloc --enable-threads --without-gcc --without-cxx % make OPT="-xc99=%none -xarch=native64" cc -c -xc99=%none -xarch=native64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306211&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1306211 ] Python 2.4.2c1 fails to build for 64-bit Solaris 9/10
Bugs item #1306211, was opened at 2005-09-27 20:20 Message generated for change (Comment added) made by jestone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306211&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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build for 64-bit Solaris 9/10 Initial Comment: Python 2.4.2c1 fails to compile on Solaris 10, yielding the following errors immediately in the build: % setenv CC "cc" % ./configure --prefix=/tmp/foo/pytest --without-pymalloc --enable-threads --without-gcc --without-cxx % make OPT="-xc99=%none -xarch=native64" cc -c -xc99=%none -xarch=native64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' -- >Comment By: John Stone (jestone) Date: 2005-09-27 20:30 Message: Logged In: YES user_id=48806 The Solaris 9 version of this compile failure is shorter: make OPT="-xc99=%none -xarch=native64" cc -c -xc99=%none -xarch=native64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c "Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306211&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1306211 ] Python 2.4.2c1 fails to build for 64-bit Solaris 9/10
Bugs item #1306211, was opened at 2005-09-27 20:20 Message generated for change (Settings changed) made by jestone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306211&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: Deleted Resolution: None Priority: 5 Submitted By: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build for 64-bit Solaris 9/10 Initial Comment: Python 2.4.2c1 fails to compile on Solaris 10, yielding the following errors immediately in the build: % setenv CC "cc" % ./configure --prefix=/tmp/foo/pytest --without-pymalloc --enable-threads --without-gcc --without-cxx % make OPT="-xc99=%none -xarch=native64" cc -c -xc99=%none -xarch=native64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' -- Comment By: John Stone (jestone) Date: 2005-09-27 20:30 Message: Logged In: YES user_id=48806 The Solaris 9 version of this compile failure is shorter: make OPT="-xc99=%none -xarch=native64" cc -c -xc99=%none -xarch=native64 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o Modules/python.c "Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306211&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1306248 ] Add 64-bit Solaris 9 build instructions to README
Bugs item #1306248, was opened at 2005-09-27 21:04 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=1306248&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.4 Status: Open Resolution: None Priority: 5 Submitted By: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Add 64-bit Solaris 9 build instructions to README Initial Comment: It would be helpful to add the correct 64-bit Solaris 9 build flags to the README file. I'm still working through problems with Solaris 10, but these flags seemed to work well for Solaris 9. One could replace the "-native64" with "-generic64" for maximum binary compatibility if necessary: (csh syntax env commands below) setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-cxx -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306248&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10
Bugs item #1306253, was opened at 2005-09-27 21:10 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=1306253&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: John Stone (jestone) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.2c1 fails to build on 64-bit Solaris 10 Initial Comment: I have not yet succeeded in compiling Python 2.4.2c1 in 64-bit mode on Solaris 10. I used the following flags and configuration options, which are the same as what I used on S9, except for the addition of the "-xc99=%none" flag to prevent compilation failures due to some of the other changes from S9 to S10: setenv CC cc setenv CXX CC setenv BASECFLAGS "-native -xc99=%none -xarch=native64 -mt -xO3" setenv LDFLAGS "-xarch=native64" ./configure --without-gcc At build time I get these errors: % make cc -c -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE -o Modules/python.o ../Modules/python.c "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration "/usr/include/limits.h", line 290: warning: typedef declares no type name "/usr/include/stdio.h", line 146: warning: useless declaration "/usr/include/stdio.h", line 146: warning: typedef declares no type name "/usr/include/sys/types.h", line 344: warning: modification of typedef with "int" ignored "/usr/include/sys/types.h", line 344: invalid type combination "/usr/include/sys/types.h", line 344: warning: useless declaration "/usr/include/sys/types.h", line 344: warning: typedef declares no type name "/usr/include/sys/types.h", line 484: invalid type combination "/usr/include/sys/types.h", line 484: warning: useless declaration "/usr/include/sys/types.h", line 484: warning: typedef declares no type name "../Include/pyport.h", line 612: #error: "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." cc: acomp failed for ../Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1306449 ] PyString_AsStringAndSize() return value documented wroing
Bugs item #1306449, was opened at 2005-09-28 13:37
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=1306449&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Bond (gnbond)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyString_AsStringAndSize() return value documented wroing
Initial Comment:
The C/C++ API document (latest version from docs.python.org) has:
int PyString_AsStringAndSize( PyObject *obj, char **buffer, int
*length)
[snip]
If string is not a string object at all, PyString_AsString() returns
NULL
and raises TypeError.
But the code returns -1 (Objects/stringobject.c line 728ff in my 2.3.4
source):
{
PyErr_Format(PyExc_TypeError,
"expected string or Unicode object, "
"%.200s found", obj->ob_type->tp_name);
return -1;
}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306449&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug
Bugs item #1115379, was opened at 2005-02-03 14:11 Message generated for change (Comment added) made by wigy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&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 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-28 06:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Martin v. Löwis (loewis) Date: 2005-02-10 01:37 Message: Logged In: YES user_id=21627 There is a bug somewhere, certainly. However, I believe it is in PEP 263, which should point out that unicode strings in compile are only legal if they do *not* contain an encoding declaration, as such strings are implicitly encoded as UTF-8. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug
Bugs item #1115379, was opened at 2005-02-03 14:11 Message generated for change (Comment added) made by wigy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&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 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-28 06:29 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-28 06:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Martin v. Löwis (loewis) Date: 2005-02-10 01:37 Message: Logged In: YES user_id=21627 There is a bug somewhere, certainly. However, I believe it is in PEP 263, which should point out that unicode strings in compile are only legal if they do *not* contain an encoding declaration, as such strings are implicitly encoded as UTF-8. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1306484 ] compile() converts "filename" parameter to StringType
Bugs item #1306484, was opened at 2005-09-28 06:49 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=1306484&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 Submitted By: Vágvölgyi Attila (wigy) Assigned to: Nobody/Anonymous (nobody) Summary: compile() converts "filename" parameter to StringType Initial Comment: The builtin compile() signature looks like: compile(string, filename, kind[, flags[, dont_inherit]]) The string parameter can be either StringType or UnicodeType, but the filename parameter will be converted to StringType, so if there are non-ascii characters in the unicode object passed, it raises UnicodeEncodeError. This can be an issue on filesystems having utf-8 filenames, or when using non-English names for the backtrace beautification. The attached file contains a unit test that will succeed when the bug is resolved. I saw the error in 2.3 and 2.4, maybe it is there for all releases? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306484&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug
Bugs item #1115379, was opened at 2005-02-03 14:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&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 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-09-28 07:48 Message: Logged In: YES user_id=21627 If you load the files manually, why is it that you want to decode them to Unicode before compile()ing them? Couldn't you just pass the bytes you read from the file to compile()? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-28 06:29 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-28 06:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Martin v. Löwis (loewis) Date: 2005-02-10 01:37 Message: Logged In: YES user_id=21627 There is a bug somewhere, certainly. However, I believe it is in PEP 263, which should point out that unicode strings in compile are only legal if they do *not* contain an encoding declaration, as such strings are implicitly encoded as UTF-8. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1306449 ] PyString_AsStringAndSize() return value documented wrong
Bugs item #1306449, was opened at 2005-09-28 13:37
Message generated for change (Comment added) made by gnbond
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306449&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Bond (gnbond)
Assigned to: Nobody/Anonymous (nobody)
>Summary: PyString_AsStringAndSize() return value documented wrong
Initial Comment:
The C/C++ API document (latest version from docs.python.org) has:
int PyString_AsStringAndSize( PyObject *obj, char **buffer, int
*length)
[snip]
If string is not a string object at all, PyString_AsString() returns
NULL
and raises TypeError.
But the code returns -1 (Objects/stringobject.c line 728ff in my 2.3.4
source):
{
PyErr_Format(PyExc_TypeError,
"expected string or Unicode object, "
"%.200s found", obj->ob_type->tp_name);
return -1;
}
--
>Comment By: Gregory Bond (gnbond)
Date: 2005-09-28 16:05
Message:
Logged In: YES
user_id=293157
Fix the summary!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306449&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1276509 ] 2.4.1 make fails on Solaris 10 (complexobject.c/HUGE_VAL)
Bugs item #1276509, was opened at 2005-08-30 12:48 Message generated for change (Comment added) made by chrschaffer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&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: csmuc (chrschaffer) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 make fails on Solaris 10 (complexobject.c/HUGE_VAL) Initial Comment: Hi all, my efforts building Python 2.4.1 on Solaris 10(x386) failed. The error mesage reads: (...)Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus Objects/complexobject.c:479: error: invalid operands to binary == Objects/complexobject.c:479: error: wrong type argument to unary minus *** Error code 1 make: Fatal error: Command failed for target `Objects/complexobject.o' I found bug 970334 dealing with that topic, but I didn't find a solution provided. I tried with various compilers and libraries, e.g. /opt/sfw/bin/gcc --version gcc (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. /opt/csw/gcc3/bin/gcc --version gcc (GCC) 3.4.4 Copyright (C) 2004 Free Software Foundation, Inc. /usr/local/bin/gcc --version gcc (GCC) 3.3.2 The same result with any of them. I didn't get the solution provided in http://mail.python.org/pipermail/python-list/2005-August/293795.html to work for me, unfortunately. I'd be glad, if you could have a look into this issue. Thanks in advance, Chris -- >Comment By: csmuc (chrschaffer) Date: 2005-09-28 08:54 Message: Logged In: YES user_id=1337267 Hi all, I found a newsgroup posting which adviced to change a line in Include/pyport.h http://mail.python.org/pipermail/patches/2005-February/016881.html ---8<- The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define Py_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h --->8- I did as adviced and the compile worked. I am not sure, if this is a valid solution, but at least it´s a workaround. Thanks to Reinhold Birkenfeld for your hint! Regards, Chris -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-22 09:03 Message: Logged In: YES user_id=1188172 Looks like HUGE_VAL is defined in a curious way on your platform. Can you find out what header defines HUGE_VAL and to what it expands? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276509&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
