[ 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 (Comment added) made by visike
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: Closed
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: Istvan Visegradi (visike)
Date: 2005-09-29 10:54
Message:
Logged In: YES
user_id=1352468
I made the wrong file open without codecs. With codecs it is
opening OK and works correctly. Sorry for my beginners
problem but in the documentation regarding Unicode is not
too clear for me. (I think the problem is probably with me).
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-09-27 22: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-Bugs-1306484 ] compile() converts "filename" parameter to StringType
Bugs item #1306484, was opened at 2005-09-28 06:49 Message generated for change (Comment added) made by wigy 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: Martin v. Löwis (loewis) 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? -- >Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-29 10:29 Message: Logged In: YES user_id=156682 loewis, I confess I could not understand a word. But as I see, it would have some advantages to have a completely unicode internal filename representation on systems having multiple filesystems mounted with different encodings, or systems having simply utf-8 filesystems (no 'ascii', 'replace' for allowing two filenames differing only in accents). I agree with Joel Spolsky (http://www.joelonsoftware.com/articles/Unicode.html), and I think that if choosing unicode could be easier in a language, than most of l10n problems would be solved. I understand, that coding unicode in C is a pain. Imagine - theoretically - if a literal like "hello" would automatically mean a unicode object in python, and you had to write s"hello" to make a literal string object encoded in a way some enviromental settings (or maybe the PEP 0263 header of the specific source file?) determine, so you have control on what happens. Imagine the case when there is a latin1 and a utf-8 partition mounted, and the console is latin2! Life would be much, much easier for a non-American programmer if she had to be aware from the first moment, that she is in an international environment. -- Comment By: Georg Brandl (gbrandl) Date: 2005-09-29 08:34 Message: Logged In: YES user_id=849994 Sounds sound. :) -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-29 08:20 Message: Logged In: YES user_id=21627 Why couldn't co_filename just be the Unicode string? I think one would have to change: - code_repr, to convert the filename into a byte string (preferably using 'ascii', 'replace') - tb_printinternal (not sure what to do here) - code_new, to accept either strings or unicode strings - builtin_compile, which probably indeed needs to convert the string using the file system encoding, and then patch the resulting code object to point to the unicode object originally passed (unless we can accept more pythonrun functions). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 14:54 Message: Logged In: YES user_id=1188172 Should compile() use the Py_FileSystemEncoding? -- 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-1307798 ] subprocess.Popen locks on Cygwin
Bugs item #1307798, was opened at 2005-09-29 12:05
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=1307798&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: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess.Popen locks on Cygwin
Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.
When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576).
Using options stdin, stdout, stderr doesn't help.
I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded.
$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1307806 ] PCbuild vcproj project files need a cleanup
Bugs item #1307806, was opened at 2005-09-29 13:08 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=1307806&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: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: PCbuild vcproj project files need a cleanup Initial Comment: The Visual Studio .NET vcproj files were probably generated by importing the older Visual C++ 6.0 dsp files and saving them back into the new format. The convertor is not perfect. The bigest problem it has it's the handling of the configuration macro defines. Instead of defining the used macros once for each configuration, it defines them for each individual file. This causes file bloat and could cause problems when new files are added to the project since we could get builds with mixed defines due to the $(NoInherit) flag which makes the compiler ignore global defines. For example, the current pythoncore.vcproj file has 100 KB. A cleaned up version is less than 25 KB. NOW: CLEANED-UP: There are a couple of files which require custom options: ..\Modules\getbuildinfo.c - PreprocessorDefinitions="BUILD=67" ..\PC\import_nt.c - AdditionalIncludeDirectories="..\Python" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307806&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 17:27 Message generated for change (Comment added) made by matthewleslie 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: Matthew Leslie (matthewleslie) Date: 2005-09-29 10:37 Message: Logged In: YES user_id=597393 I am running windows XP, and am logging in HKLM policies: AlwaysInstallElevated 1 EnableAdminTSRemote 1 HKCurrentUser policies: AlwaysInstallElevated 1 Sadly, I am not allowed to change HKLM keys on this machine. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 19: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 14: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 11: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 04: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-1298962 ] MSI installer does not pass values as SecureProperty from UI
Bugs item #1298962, was opened at 2005-09-22 17:27 Message generated for change (Comment added) made by matthewleslie 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: Matthew Leslie (matthewleslie) Date: 2005-09-29 10:40 Message: Logged In: YES user_id=597393 I have attached the install log -- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-29 10:37 Message: Logged In: YES user_id=597393 I am running windows XP, and am logging in HKLM policies: AlwaysInstallElevated 1 EnableAdminTSRemote 1 HKCurrentUser policies: AlwaysInstallElevated 1 Sadly, I am not allowed to change HKLM keys on this machine. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 19: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 14: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 11: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 04: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-1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code)
Bugs item #1307978, was opened at 2005-09-29 15:14 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=1307978&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: Goetz Isenmann (isenmann) Assigned to: Nobody/Anonymous (nobody) Summary: Unsatisfied symbols: _PyGILState_NoteThreadState (code) Initial Comment: Compiling python 2.4.2 without threads (for hpux1020) results in an undefined symbol _PyGILState_NoteThreadState in Python/pystate.o. There are probably some "#ifdef WITH_THREAD"s missing. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code)
Bugs item #1307978, was opened at 2005-09-29 14:14 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&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: Goetz Isenmann (isenmann) >Assigned to: Michael Hudson (mwh) Summary: Unsatisfied symbols: _PyGILState_NoteThreadState (code) Initial Comment: Compiling python 2.4.2 without threads (for hpux1020) results in an undefined symbol _PyGILState_NoteThreadState in Python/pystate.o. There are probably some "#ifdef WITH_THREAD"s missing. -- >Comment By: Michael Hudson (mwh) Date: 2005-09-29 14:28 Message: Logged In: YES user_id=6656 Aaargh, I expect you're right. Should be easy to fix, will have a patch for you to test shortly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code)
Bugs item #1307978, was opened at 2005-09-29 15:14 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&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: Goetz Isenmann (isenmann) Assigned to: Michael Hudson (mwh) Summary: Unsatisfied symbols: _PyGILState_NoteThreadState (code) Initial Comment: Compiling python 2.4.2 without threads (for hpux1020) results in an undefined symbol _PyGILState_NoteThreadState in Python/pystate.o. There are probably some "#ifdef WITH_THREAD"s missing. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 15:32 Message: Logged In: YES user_id=1188172 I'd think that a #ifdef WITH_THREAD around the _PyGILState_NoteThreadState call in pystate.c:192 is enough. -- Comment By: Michael Hudson (mwh) Date: 2005-09-29 15:28 Message: Logged In: YES user_id=6656 Aaargh, I expect you're right. Should be easy to fix, will have a patch for you to test shortly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code)
Bugs item #1307978, was opened at 2005-09-29 14:14 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&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: Goetz Isenmann (isenmann) Assigned to: Michael Hudson (mwh) Summary: Unsatisfied symbols: _PyGILState_NoteThreadState (code) Initial Comment: Compiling python 2.4.2 without threads (for hpux1020) results in an undefined symbol _PyGILState_NoteThreadState in Python/pystate.o. There are probably some "#ifdef WITH_THREAD"s missing. -- >Comment By: Michael Hudson (mwh) Date: 2005-09-29 15:04 Message: Logged In: YES user_id=6656 Can you try the attached? -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 14:32 Message: Logged In: YES user_id=1188172 I'd think that a #ifdef WITH_THREAD around the _PyGILState_NoteThreadState call in pystate.c:192 is enough. -- Comment By: Michael Hudson (mwh) Date: 2005-09-29 14:28 Message: Logged In: YES user_id=6656 Aaargh, I expect you're right. Should be easy to fix, will have a patch for you to test shortly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1308042 ] Datagram Socket Timeouts
Bugs item #1308042, was opened at 2005-09-29 10:05 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=1308042&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 Submitted By: Tom Vrankar (tvrankar) Assigned to: Nobody/Anonymous (nobody) Summary: Datagram Socket Timeouts Initial Comment: Python 2.4.1, MS Windows 2000 with service packs I'm trying to have a UDP client check for its server to start by repeatedly throwing messages at where it's expected to appear, and then checking for a response. I set a timeout on the recvfrom, expecting to block for the timeout and then proceeding to an exception handler, looping so until data is returned. Instead, the recvfrom throws an immediate exception "Connection reset by peer", and I loop rapidly without the load-softening effect of the timeout (in fact, it's the same behavior as if I didn't set the timeout at all). What UDP "connection" is it talking about? Seems wrong, but is it the implementation or is it me? If I start the server first, I get one "Invalid argument" exception in the client. In both cases, once the server is started, both processes are satisfied. Thanks. twv -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&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 (Comment added) made by jestone 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' -- >Comment By: John Stone (jestone) Date: 2005-09-29 15:33 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 Traceback (most recent call last): File "./setup.py", line 1184, in ? main() File "./setup.py", line 1178, in main scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', File "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.bu
[ 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 (Comment added) made by jestone 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' -- >Comment By: John Stone (jestone) Date: 2005-09-29 15:46 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 Traceback (most recent call last): File "./setup.py", line 1184, in ? main() File "./setup.py", line 1178, in main scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', File "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 178, in build_extensions build_ext.build_extensions(self) File "/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 183, in build_extension build_ext.bu
[ python-Bugs-1306248 ] Add 64-bit Solaris 9 build instructions to README
Bugs item #1306248, was opened at 2005-09-27 23:04 Message generated for change (Comment added) made by loewis 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 -- >Comment By: Martin v. Löwis (loewis) Date: 2005-09-29 18:06 Message: Logged In: YES user_id=21627 I'm hesitant to add instructions to the README of the style "do this to get it work", especially when I believe these instructions are either wrong or overspecified. Adding something like "Jone Stone <[EMAIL PROTECTED]> suggests to use these options" might be a compromise. As for why --without-gcc causes dropping of compiler flags: It's because of this fragment of configure.in: AC_MSG_CHECKING(for --without-gcc) AC_ARG_WITH(gcc, AC_HELP_STRING(--without-gcc,never use gcc), [ case $withval in no) CC=cc without_gcc=yes;; Not sure what caused the introduction of this fragment, but omitting --without-gcc looks like the right thing to do. In general, I would much more prefer to receive patches that make things work out of the box, instead of documenting bugs. -- Comment By: John Stone (jestone) Date: 2005-09-29 17:12 Message: Logged In: YES user_id=48806 Of course there't no single set of options, that much is true of any platform. However, I've provided one set of options that does work. It's clear to me that little testing is being done building Python for the 64-bit ABI mode of targets such as IRIX, Solaris, and other platforms using the vendor compilers. (maybe gcc works, but I can't use gcc...) In the case of the other platforms, there are comments in the README that are helpful to those of us that need to build a 64-bit Python interpreter for embedding in 64-bit applications. Several Python 2.3 versions I tried fail to pass on build flags to some of the module builds, proving that nobody tested this in the past. 2.4.2c1 works, but you have to set all of these environment variables to get it to work. Anyway, as far as the options I selected: You could choose -O but the Sun compilers prefer -xO3 (some old versions whine at you if you use -O). I chose -mt for thread safety, which is already documented in the Python README. Simply setting CC to "cc -xarch=native64" worked way back in Python 2.2, but fails with 2.3.x and 2.4.x. If you try that on 2.4.2c1 and use the configure flags below, setenv CC "cc -xarch=native64" ./configure --without-cxx --without-gcc You can see that the build scripts have already lost the -xarch=native64 in the first couple of compiles: cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/metagrammar.o Parser/metagrammar.c cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/firstsets.o Parser/firstsets.c cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/grammar.o Parser/grammar.c If I eliminate the "--without-gcc" flag to configure, the build does work by setting CC to "cc -xarch=native64". I don't know why it breaks when one adds --without-gcc, but it'd be nice if the docs cleared this up. With Python 2.2, adding --without-gcc did not break the build. This is exactly the problem with the current state of the build system and docs. I don't mind the fact that it's a little hokey to get the build done, but it'd be nice if the docs contained the facts needed to do this without a trial-and-error based search of the configuration space to avoid the bugs in the build system. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-29 08:41 Message: Logged In: YES user_id=21627 I believe there is no single set of "correct" options. E.g. why is it necessary to pass -xO3? I'm sure it will build fine without that; also, -O is documented to expand to -xO3. Likewise, why -mt? configure should figure out the necessary libraries itself, and -mt links with -lthread, when it really should link with -lpthread. -native is do
[ python-Bugs-1306253 ] Python 2.4.2c1 fails to build on 64-bit Solaris 10
Bugs item #1306253, was opened at 2005-09-27 23:10 Message generated for change (Comment added) made by loewis 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' -- >Comment By: Martin v. Löwis (loewis) Date: 2005-09-29 18:08 Message: Logged In: YES user_id=21627 If I see a message "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration then I'm certain that this is an OS bug. The system compiler reports an error in the system headers! how could this not be an OS bug? What is line 290 of limits.h, anyway? I don't know what -xc99=%none does, but it looks suspicious: such a thing should not be necessary to do. -- Comment By: John Stone (jestone) Date: 2005-09-29 17:46 Message: Logged In: YES user_id=48806 It's not an OS bug, it seems certain to be a build system bug in Python, please read on. I did some more digging, and it appears that I can avoid this problem by removing the "--without-gcc" flag to configure. This flag is somehow interfering with the build process. If I remove that flag and instead do the build like this, I get much farther: setenv CC "cc -xc99=%none -xarch=native64" ./configure >From there, I run make and the build proceeds much much farther successfully linking the python interpreter itself, but ultimately fails just past that when using the interpreter to do the rest: ranlib libpython2.4.a cc -xc99=%none -xarch=native64 -o python Modules/python.o libpython2.4.a -lresolv -lsocket -lnsl -lrt -ldl -lm case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc -xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python -E ./setup.py build;; esac running build running build_ext db.h: found (4, 2) in /usr/local/include db lib: using (4, 2) db-4.2 INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension creating build creating build/temp.solaris-2.10-sun4u-2.4 Traceback (most recent call last): File "./setup.py", line 1184, in ? main() File "./setup.py", line 1178, in main scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', File "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File
[ 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 (Comment added) made by jestone 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' -- >Comment By: John Stone (jestone) Date: 2005-09-29 16:35 Message: Logged In: YES user_id=48806 It isn't an OS bug because that specific problem is caused by something generated by the autoconf scripts and/or Python headers, and it's that specific interaction that's causing the errors. Here's line 290 of /usr/include/limits.h: typedef unsigned long size_t; /* size of something in bytes */ I suspect there's some bogus line in one of the autoconf generated includes that's typedefing size_t for itself when "--without-gcc" is used. I've compiled a few hundred thousand lines of code in 64-bit mode (some of which do indeed include limits.h) and not run into this problem prior to building Python. Since we've determined that the use of the "--without-gcc" breaks the 64-bit builds universally, I'm not inclined to dig much deeper on that particular problem. Removing --without-gcc from the configure options eliminates that compile problem, leaving the other issues I mention with the last part of the build process. Regarding "-xc99=%none", this is now required when building codes that are pre-POSIX 2003 on Solaris, otherwise the new S10 headers give you errors: "/usr/include/sys/feature_tests.h", line 332: #error: "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" The comments in the system header pertaning to this say the following: /* * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 * or a POSIX.1-2001 application with anything other than a c99 or later * compiler. Therefore, we force an error in both cases. */ In any case, adding -xc99=%none disables the c99 extensions which conflict with the old POSIX standards. This probably has to do with language changes that occured in c99 that may be incompatible with the oldest POSIX APIs. (elimination of default type promotion to int perhaps?) I agree that it's annoying, but that's the way the new headers work, and many other packages have already updated their build flags to cope. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-29 16:08 Message: Logged In: YES user_id=21627 If I see a message "/usr/include/limits.h", line 290: invalid type combination "/usr/include/limits.h", line 290: warning: useless declaration then I'm certain that this is an OS bug. The system compiler reports an error in the syst
[ 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-29 18:14 Message: Logged In: YES user_id=21627 Thanks. Unfortunately, this logfile appears to start too late. Can you please recreate it with msiexec /i python-2.4.x.msi /l*v python.log Are you being asked whether this is a per-user or per-machine install? If yes, what is your response? I'm still puzzled as to what is causing the problem here. -- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-29 12:40 Message: Logged In: YES user_id=597393 I have attached the install log -- Comment By: Matthew Leslie (matthewleslie) Date: 2005-09-29 12:37 Message: Logged In: YES user_id=597393 I am running windows XP, and am logging in HKLM policies: AlwaysInstallElevated 1 EnableAdminTSRemote 1 HKCurrentUser policies: AlwaysInstallElevated 1 Sadly, I am not allowed to change HKLM keys on this machine. -- 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-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 (Comment added) made by jestone 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 -- >Comment By: John Stone (jestone) Date: 2005-09-29 16:41 Message: Logged In: YES user_id=48806 I understand your reluctance to add cruft to the README, but given that there's no "configure --64-bit --without-gcc" that works, I think that adding something to the docs would be helpful. There's already a history of documenting bugs/limitations of the Python build system in the README, so while I agree with your view that fixing the build system would be best, adding something to the README is a good short-term solution until the 64-bit build kinks are fixed up. I suggest adding something along the lines of what has already been done for AIX/HP-UX 64-bit builds, since those also require unusual steps. Keep it short like these?: AIX 5.3: To build a 64-bit version with IBM's compiler, I used the following: export PATH=/usr/bin:/usr/vacpp/bin ./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" --disable-ipv6 AR="ar -X64" make HP-UX: When using threading, you may have to add -D_REENTRANT to the OPT variable in the top-level Makefile; reported by Pat Knight, this seems to make a difference (at least for HP-UX 10.20) even though pyconfig.h defines it. This seems unnecessary when using HP/UX 11 and later - threading seems to work "out of the box". -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-29 16:06 Message: Logged In: YES user_id=21627 I'm hesitant to add instructions to the README of the style "do this to get it work", especially when I believe these instructions are either wrong or overspecified. Adding something like "Jone Stone <[EMAIL PROTECTED]> suggests to use these options" might be a compromise. As for why --without-gcc causes dropping of compiler flags: It's because of this fragment of configure.in: AC_MSG_CHECKING(for --without-gcc) AC_ARG_WITH(gcc, AC_HELP_STRING(--without-gcc,never use gcc), [ case $withval in no) CC=cc without_gcc=yes;; Not sure what caused the introduction of this fragment, but omitting --without-gcc looks like the right thing to do. In general, I would much more prefer to receive patches that make things work out of the box, instead of documenting bugs. -- Comment By: John Stone (jestone) Date: 2005-09-29 15:12 Message: Logged In: YES user_id=48806 Of course there't no single set of options, that much is true of any platform. However, I've provided one set of options that does work. It's clear to me that little testing is being done building Python for the 64-bit ABI mode of targets such as IRIX, Solaris, and other platforms using the vendor compilers. (maybe gcc works, but I can't use gcc...) In the case of the other platforms, there are comments in the README that are helpful to those of us that need to build a 64-bit Python interpreter for embedding in 64-bit applications. Several Python 2.3 versions I tried fail to pass on build flags to some of the module builds, proving that nobody tested this in the past. 2.4.2c1 works, but you have to set all of these environment variables to get it to work. Anyway, as far as the options I selected: You could choose -O but the Sun compilers prefer -xO3 (some old versions whine at you if you use -O). I chose -mt for thread safety, which is already documented in the Python README. Simply setting CC to "cc -xarch=native64" worked way back in Python 2.2, but fails with 2.3.x and 2.4.x. If you try that on 2.4.2c1 and use the configure flags below, setenv CC "cc -xarch=native64" ./configure --without-cxx --without-gcc You can see that the build scripts have already lost the -xarch=nati
[ 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 (Comment added) made by jestone 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 -- >Comment By: John Stone (jestone) Date: 2005-09-29 15:12 Message: Logged In: YES user_id=48806 Of course there't no single set of options, that much is true of any platform. However, I've provided one set of options that does work. It's clear to me that little testing is being done building Python for the 64-bit ABI mode of targets such as IRIX, Solaris, and other platforms using the vendor compilers. (maybe gcc works, but I can't use gcc...) In the case of the other platforms, there are comments in the README that are helpful to those of us that need to build a 64-bit Python interpreter for embedding in 64-bit applications. Several Python 2.3 versions I tried fail to pass on build flags to some of the module builds, proving that nobody tested this in the past. 2.4.2c1 works, but you have to set all of these environment variables to get it to work. Anyway, as far as the options I selected: You could choose -O but the Sun compilers prefer -xO3 (some old versions whine at you if you use -O). I chose -mt for thread safety, which is already documented in the Python README. Simply setting CC to "cc -xarch=native64" worked way back in Python 2.2, but fails with 2.3.x and 2.4.x. If you try that on 2.4.2c1 and use the configure flags below, setenv CC "cc -xarch=native64" ./configure --without-cxx --without-gcc You can see that the build scripts have already lost the -xarch=native64 in the first couple of compiles: cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/metagrammar.o Parser/metagrammar.c cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/firstsets.o Parser/firstsets.c cc -c -DNDEBUG -O -I. -I./Include -DPy_BUILD_CORE -o Parser/grammar.o Parser/grammar.c If I eliminate the "--without-gcc" flag to configure, the build does work by setting CC to "cc -xarch=native64". I don't know why it breaks when one adds --without-gcc, but it'd be nice if the docs cleared this up. With Python 2.2, adding --without-gcc did not break the build. This is exactly the problem with the current state of the build system and docs. I don't mind the fact that it's a little hokey to get the build done, but it'd be nice if the docs contained the facts needed to do this without a trial-and-error based search of the configuration space to avoid the bugs in the build system. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-29 06:41 Message: Logged In: YES user_id=21627 I believe there is no single set of "correct" options. E.g. why is it necessary to pass -xO3? I'm sure it will build fine without that; also, -O is documented to expand to -xO3. Likewise, why -mt? configure should figure out the necessary libraries itself, and -mt links with -lthread, when it really should link with -lpthread. -native is documented as synonym for -xtarget=native. This in turn isn't documented much, but if it included -xarch=native, I don't understand why you want that: it is documented as "The compiler chooses the appropriate setting for producing 32-bit binaries". IOW, I think that setting CC to "cc -xarch=native64" should be enough. Unfortunately, I don't have a Sun compiler on Solaris, so I personally use gcc instead. -- 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-1307798 ] subprocess.Popen locks on Cygwin
Bugs item #1307798, was opened at 2005-09-29 12:05
Message generated for change (Settings changed) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&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: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
>Assigned to: Peter Åstrand (astrand)
Summary: subprocess.Popen locks on Cygwin
Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.
When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576).
Using options stdin, stdout, stderr doesn't help.
I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded.
$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1307357 ] Datagram Socket Timeouts
Bugs item #1307357, was opened at 2005-09-28 17:20 Message generated for change (Comment added) made by tvrankar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307357&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 Submitted By: Tom Vrankar (tvrankar) Assigned to: Nobody/Anonymous (nobody) Summary: Datagram Socket Timeouts Initial Comment: Python 2.4.1, MS Windows 2000 with service packs I'm trying to have a UDP client check for its server to start by repeatedly throwing messages at where it's expected to appear, and then checking for a response. I set a timeout on the recvfrom, expecting to block for the timeout and then proceeding to an exception handler, looping so until data is returned. Instead, the recvfrom throws an immediate exception "Connection reset by peer", and I loop rapidly without the load-softening effect of the timeout (in fact, it's the same behavior as if I didn't set the timeout at all). What UDP "connection" is it talking about? Seems wrong, but is it the implementation or is it me? If I start the server first, I get one "Invalid argument" exception in the client. In both cases, once the server is started, both processes are satisfied. Thanks. twv -- >Comment By: Tom Vrankar (tvrankar) Date: 2005-09-29 13:15 Message: Logged In: YES user_id=1353485 BTW: On Solaris 8 it works as expected, with a "timed out" exception after the requested time out for each recvfrom until the server appears. This may be a Windoze-specific socket-ism. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307357&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 23:10 Message generated for change (Comment added) made by loewis 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' -- >Comment By: Martin v. Löwis (loewis) Date: 2005-09-29 20:36 Message: Logged In: YES user_id=21627 Can you please attach the generated pyconfig.h? Also, if possible, can you please attache the preprocessor output of cc -E -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE ../Modules/python.c As for disabling C99: Python should be perfectly compatible with C99, and the most recent POSIX release. So there is no need to disable this. pyconfig.h should set _XOPEN_SOURCE to 600, requesting POSIX 2003. In turn, in line 269 for feature_tests.h, _XPG6 should be defined, and the #error should not occur. Can you please investigate why it still does? As for the distutils bug you are seeing: It comes from the %none being treated as a format argument. Please try the attached patch. -- Comment By: John Stone (jestone) Date: 2005-09-29 18:35 Message: Logged In: YES user_id=48806 It isn't an OS bug because that specific problem is caused by something generated by the autoconf scripts and/or Python headers, and it's that specific interaction that's causing the errors. Here's line 290 of /usr/include/limits.h: typedef unsigned long size_t; /* size of something in bytes */ I suspect there's some bogus line in one of the autoconf generated includes that's typedefing size_t for itself when "--without-gcc" is used. I've compiled a few hundred thousand lines of code in 64-bit mode (some of which do indeed include limits.h) and not run into this problem prior to building Python. Since we've determined that the use of the "--without-gcc" breaks the 64-bit builds universally, I'm not inclined to dig much deeper on that particular problem. Removing --without-gcc from the configure options eliminates that compile problem, leaving the other issues I mention with the last part of the build process. Regarding "-xc99=%none", this is now required when building codes that are pre-POSIX 2003 on Solaris, otherwise the new S10 headers give you errors: "/usr/include/sys/feature_tests.h", line 332: #error: "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" The comments in the system header pertaning to this say the following: /* * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 * or a POSIX.1-2001 application with anything other than a c99 or later
[ python-Bugs-1308740 ] Py_BuildValue (C/API): "K" format
Bugs item #1308740, was opened at 2005-09-29 18: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=1308740&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: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Yair Chuchem (bigorilla) Assigned to: Nobody/Anonymous (nobody) Summary: Py_BuildValue (C/API): "K" format Initial Comment: In section "5.5 Parsing arguments and building values" at the C/API documentation. At the description of Py_BuildValue's format strings, the "K" format char is not mentioned, though it is implemented. Here's a possible text to add: "K" (integer) [unsigned PY_LONG_LONG] Convert a C unsigned long long to a python int object. and maybe add a (New in version 2.3) I don't know if it's new from 2.3 or something. I know that for PyArg_ParseTuple it says that for "K" Before I found that "K" is implemented out I used the "N" format and PyLong_FromLongLong, which is far less elegant :) Thanks, Yair. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308740&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-959576 ] Can't build Python on POSIX w/o $HOME
Bugs item #959576, was opened at 2004-05-24 17:16
Message generated for change (Comment added) made by jhein-sf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't build Python on POSIX w/o $HOME
Initial Comment:
If you're building Python on os.name == 'posix' but
when there is no $HOME defined in your environment, you
cannot build Python. This is because in the bowels of
distutils, you end up in check_environ(), which has
these lines:
if os.name == 'posix' and not
os.environ.has_key('HOME'):
import pwd
os.environ['HOME'] = pwd.getpwuid(os.getuid())[5]
However, in a from-scratch build, the pwd module isn't
built by the time you get here. I found this when
using SCons to build Python, since by default the
enclosing environment isn't passed to subprocesses.
I can work around this in my builds but Python's
setup.py should probably synthesize a $HOME if one
doesn't exist. (Or maybe someone has a better idea for
a workaround).
--
Comment By: John Hein (jhein-sf)
Date: 2005-09-29 19:14
Message:
Logged In: YES
user_id=59465
I had this problem, too.
The fix proposed by birkenfeld on 9/22 works for me.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-22 07:19
Message:
Logged In: YES
user_id=1188172
Seems that the pwdmodule entry in Modules/Setup.dist must be
uncommented.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-959576 ] Can't build Python on POSIX w/o $HOME
Bugs item #959576, was opened at 2004-05-24 17:16
Message generated for change (Comment added) made by jhein-sf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't build Python on POSIX w/o $HOME
Initial Comment:
If you're building Python on os.name == 'posix' but
when there is no $HOME defined in your environment, you
cannot build Python. This is because in the bowels of
distutils, you end up in check_environ(), which has
these lines:
if os.name == 'posix' and not
os.environ.has_key('HOME'):
import pwd
os.environ['HOME'] = pwd.getpwuid(os.getuid())[5]
However, in a from-scratch build, the pwd module isn't
built by the time you get here. I found this when
using SCons to build Python, since by default the
enclosing environment isn't passed to subprocesses.
I can work around this in my builds but Python's
setup.py should probably synthesize a $HOME if one
doesn't exist. (Or maybe someone has a better idea for
a workaround).
--
Comment By: John Hein (jhein-sf)
Date: 2005-09-29 19:28
Message:
Logged In: YES
user_id=59465
Let me revise that last comment. There are some build
differences when this is done.
Uncommenting pwd in Setup.dist allows python to build, but
the 'pwd' extension (and pwd.so) does not get built.
And pwdmodule.o is ar'd into libpython2.4.a (& linked into
libpython2.4.so)
--
Comment By: John Hein (jhein-sf)
Date: 2005-09-29 19:14
Message:
Logged In: YES
user_id=59465
I had this problem, too.
The fix proposed by birkenfeld on 9/22 works for me.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-22 07:19
Message:
Logged In: YES
user_id=1188172
Seems that the pwdmodule entry in Modules/Setup.dist must be
uncommented.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin
Bugs item #1307798, was opened at 2005-09-29 12:05
Message generated for change (Comment added) made by astrand
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&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: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess.Popen locks on Cygwin
Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.
When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576).
Using options stdin, stdout, stderr doesn't help.
I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded.
$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)
--
>Comment By: Peter Åstrand (astrand)
Date: 2005-09-29 21:32
Message:
Logged In: YES
user_id=344921
Does the testsuite test_subprocess.py work correctly on this
platform?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&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 (Comment added) made by jestone 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' -- >Comment By: John Stone (jestone) Date: 2005-09-29 19:42 Message: Logged In: YES user_id=48806 The distutils patch you provided definitely cures the build problems I encountered when using the -xc99=%none compiler flag, so that at least gives one way to build. Your patch plus these options built fine (skipped C++ thus far) setenv CC "cc -xc99=%none -xarch=native64" ./configure --without-cxx I'll attach the pyconfig.h etc for this combination and I can send you the same info without those flags if you like. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-29 18:36 Message: Logged In: YES user_id=21627 Can you please attach the generated pyconfig.h? Also, if possible, can you please attache the preprocessor output of cc -E -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE ../Modules/python.c As for disabling C99: Python should be perfectly compatible with C99, and the most recent POSIX release. So there is no need to disable this. pyconfig.h should set _XOPEN_SOURCE to 600, requesting POSIX 2003. In turn, in line 269 for feature_tests.h, _XPG6 should be defined, and the #error should not occur. Can you please investigate why it still does? As for the distutils bug you are seeing: It comes from the %none being treated as a format argument. Please try the attached patch. -- Comment By: John Stone (jestone) Date: 2005-09-29 16:35 Message: Logged In: YES user_id=48806 It isn't an OS bug because that specific problem is caused by something generated by the autoconf scripts and/or Python headers, and it's that specific interaction that's causing the errors. Here's line 290 of /usr/include/limits.h: typedef unsigned long size_t; /* size of something in bytes */ I suspect there's some bogus line in one of the autoconf generated includes that's typedefing size_t for itself when "--without-gcc" is used. I've compiled a few hundred thousand lines of code in 64-bit mode (some of which do indeed include limits.h) and not run into this problem prior to building Python. Since we've determined that the use of the "--without-gcc" breaks the 64-bit builds universally, I'm not inclined to dig much deeper on that particular problem. Removing --without-gcc from the configure options eliminates that compile problem, leaving the other issues I mention with the last part of the build process. Regarding "-xc99=%none", this is now required when building codes that are
[ 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 (Comment added) made by jestone 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' -- >Comment By: John Stone (jestone) Date: 2005-09-29 19:54 Message: Logged In: YES user_id=48806 Ok, those two preproc.txt and preproc2.txt.gz ought to help you see what's going on there. -- Comment By: John Stone (jestone) Date: 2005-09-29 19:42 Message: Logged In: YES user_id=48806 The distutils patch you provided definitely cures the build problems I encountered when using the -xc99=%none compiler flag, so that at least gives one way to build. Your patch plus these options built fine (skipped C++ thus far) setenv CC "cc -xc99=%none -xarch=native64" ./configure --without-cxx I'll attach the pyconfig.h etc for this combination and I can send you the same info without those flags if you like. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-29 18:36 Message: Logged In: YES user_id=21627 Can you please attach the generated pyconfig.h? Also, if possible, can you please attache the preprocessor output of cc -E -native -xc99=%none -xarch=native64 -mt -xO3 -DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE ../Modules/python.c As for disabling C99: Python should be perfectly compatible with C99, and the most recent POSIX release. So there is no need to disable this. pyconfig.h should set _XOPEN_SOURCE to 600, requesting POSIX 2003. In turn, in line 269 for feature_tests.h, _XPG6 should be defined, and the #error should not occur. Can you please investigate why it still does? As for the distutils bug you are seeing: It comes from the %none being treated as a format argument. Please try the attached patch. -- Comment By: John Stone (jestone) Date: 2005-09-29 16:35 Message: Logged In: YES user_id=48806 It isn't an OS bug because that specific problem is caused by something generated by the autoconf scripts and/or Python headers, and it's that specific interaction that's causing the errors. Here's line 290 of /usr/include/limits.h: typedef unsigned long size_t; /* size of something in bytes */ I suspect there's some bogus line in one of the autoconf generated includes that's typedefing size_t for itself when "--without-gcc" is used. I've compiled a few hundred thousand lines of code in 64-bit mode (some of which do indeed include limits.h) and not run into this problem prior to building Python. Since we've determined that the use of the "--without-gcc" breaks the 64-bit builds universally, I'm not inclined to dig much deeper on
[ python-Bugs-1308740 ] Py_BuildValue (C/API): "K" format
Bugs item #1308740, was opened at 2005-09-29 20:57 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308740&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: Not a Bug >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Yair Chuchem (bigorilla) Assigned to: Nobody/Anonymous (nobody) Summary: Py_BuildValue (C/API): "K" format Initial Comment: In section "5.5 Parsing arguments and building values" at the C/API documentation. At the description of Py_BuildValue's format strings, the "K" format char is not mentioned, though it is implemented. Here's a possible text to add: "K" (integer) [unsigned PY_LONG_LONG] Convert a C unsigned long long to a python int object. and maybe add a (New in version 2.3) I don't know if it's new from 2.3 or something. I know that for PyArg_ParseTuple it says that for "K" Before I found that "K" is implemented out I used the "N" format and PyLong_FromLongLong, which is far less elegant :) Thanks, Yair. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:03 Message: Logged In: YES user_id=1188172 Duplicate of #1281408. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308740&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-959576 ] Can't build Python on POSIX w/o $HOME
Bugs item #959576, was opened at 2004-05-24 19:16
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&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: Barry A. Warsaw (bwarsaw)
>Assigned to: Martin v. Löwis (loewis)
Summary: Can't build Python on POSIX w/o $HOME
Initial Comment:
If you're building Python on os.name == 'posix' but
when there is no $HOME defined in your environment, you
cannot build Python. This is because in the bowels of
distutils, you end up in check_environ(), which has
these lines:
if os.name == 'posix' and not
os.environ.has_key('HOME'):
import pwd
os.environ['HOME'] = pwd.getpwuid(os.getuid())[5]
However, in a from-scratch build, the pwd module isn't
built by the time you get here. I found this when
using SCons to build Python, since by default the
enclosing environment isn't passed to subprocesses.
I can work around this in my builds but Python's
setup.py should probably synthesize a $HOME if one
doesn't exist. (Or maybe someone has a better idea for
a workaround).
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-29 22:04
Message:
Logged In: YES
user_id=1188172
Well, pwd will be built-in then, if that's a problem.
Assigning to loewis to look over it.
--
Comment By: John Hein (jhein-sf)
Date: 2005-09-29 21:28
Message:
Logged In: YES
user_id=59465
Let me revise that last comment. There are some build
differences when this is done.
Uncommenting pwd in Setup.dist allows python to build, but
the 'pwd' extension (and pwd.so) does not get built.
And pwdmodule.o is ar'd into libpython2.4.a (& linked into
libpython2.4.so)
--
Comment By: John Hein (jhein-sf)
Date: 2005-09-29 21:14
Message:
Logged In: YES
user_id=59465
I had this problem, too.
The fix proposed by birkenfeld on 9/22 works for me.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-22 09:19
Message:
Logged In: YES
user_id=1188172
Seems that the pwdmodule entry in Modules/Setup.dist must be
uncommented.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=959576&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1299051 ] "Howto RE" link is dead
Bugs item #1299051, was opened at 2005-09-22 21:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299051&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: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Macs R We (macsrwe) Assigned to: Nobody/Anonymous (nobody) Summary: "Howto RE" link is dead Initial Comment: On page http://www.python.org/doc/2.3.5/lib/re-syntax.html The link to "Regular expressions HOWTO" documentation ends up at http://www.amk.ca/python/howto/, which is a dead host. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:06 Message: Logged In: YES user_id=1188172 The host works for me. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1299051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1296004 ] MemoryError in httplib
Bugs item #1296004, was opened at 2005-09-20 07:14 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296004&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Yue Zhang (yuezhang) Assigned to: Nobody/Anonymous (nobody) Summary: MemoryError in httplib Initial Comment: The problem from http://www.thescripts.com/forum/thread25490.html can be repeated here with python2.4.1 on WinXP. Test sample: sending about 5MB http data. It appears to be caused by line 545, httplib.py. chunk = self.fp.read(amt) It seems that reading too much from that sock causes leak. Thus trying to edit the line making it chunk = self.fp.read(min(amt,5)) the problem will be solved. //Not sure whether it was sock error for using pure sock for http won't cause this problem. If you need an example of this bug, please contact me. Also, the method in httplib is using string concatenation, which might turn slow when the strings are large. An alternative is using a temp list to cache the string sections, and join the list at last. This will be faster, with the draw back of some more memory usage. Best regards, Zhang Yue -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:16 Message: Logged In: YES user_id=1188172 I added a "max amount" of 1 MB in httplib.py r1.96, 1.94.2.2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296004&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1298120 ] shlex does not support unicode
Bugs item #1298120, was opened at 2005-09-21 22:18 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298120&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: Fixed Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: shlex does not support unicode Initial Comment: Should make prominent notice that shlex does not support unicode. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:24 Message: Logged In: YES user_id=1188172 Fixed in Doc/lib/libshlex.tex r1.19, r1.18.4.1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298120&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-985651 ] BaseHTTPServer to take host from cmdline?
Bugs item #985651, was opened at 2004-07-06 01:29 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985651&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: Feature Request >Status: Closed >Resolution: Wont Fix Priority: 2 Submitted By: Tom Lynn (tlynn) Assigned to: Nobody/Anonymous (nobody) Summary: BaseHTTPServer to take host from cmdline? Initial Comment: BaseHTTPServer.py can be run from the command line, in which case it takes its port from the command line but it assumes the hostname is empty. My grasp of these things is poor, but my understanding is that empty hostname implies not externally visible. Shouldn't it be possible to supply the hostname on the command line too (even if the above belief is incorrect)? -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:30 Message: Logged In: YES user_id=1188172 Calling BaseHTTPServer directly only calls a test() method, which means that this is not intended for serious use. For that you should create your own server instance. If you feel otherwise, you can reopen this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985651&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-869197 ] setgroups rejects long integer arguments
Bugs item #869197, was opened at 2004-01-02 10:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) >Assigned to: Martin v. Löwis (loewis) Summary: setgroups rejects long integer arguments Initial Comment: os.setgroups ought to accept long integer arguments, just as os.setgid does. I think this worked in an earlier version of Python - or maybe it was that string.atol used to return a non-long integer if the number was small enough, so I didn't encounter long integers at all. >>> import os >>> os.setgid(1L) >>> os.setgroups((1L,)) Traceback (most recent call last): File "", line 1, in ? TypeError: groups must be integers >>> import sys >>> print sys.version 2.3.3 (#1, Dec 30 2003, 22:52:56) [GCC 3.2.3] -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:36 Message: Logged In: YES user_id=1188172 Attaching patch against CVS head. Please review. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility
Bugs item #1086854, was opened at 2004-12-17 05:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Friesner (jfriesne) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:37 Message: Logged In: YES user_id=1188172 Okay. Most of your replacements are function parameters or function local variables, do they have to be replaced too? -- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-28 18:59 Message: Logged In: YES user_id=383828 Here is a file containing grep output showing all the lines where I changed 'slots' to 'xslots' in my codebase: http://www.lcscanada.com/jaf/xslots.zip -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 15:02 Message: Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility
Bugs item #1086854, was opened at 2004-12-17 04:07 Message generated for change (Comment added) made by jfriesne You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Friesner (jfriesne) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. -- >Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-29 20:48 Message: Logged In: YES user_id=383828 Unfortunately, yes, When compiling with Qt, the words "signals" and "slots" become essentially reserved keywords, and any use of them as variable names causes a compile error. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 20:37 Message: Logged In: YES user_id=1188172 Okay. Most of your replacements are function parameters or function local variables, do they have to be replaced too? -- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-28 16:59 Message: Logged In: YES user_id=383828 Here is a file containing grep output showing all the lines where I changed 'slots' to 'xslots' in my codebase: http://www.lcscanada.com/jaf/xslots.zip -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 13:02 Message: Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086854 ] "slots" member variable in object.h confuses Qt moc utility
Bugs item #1086854, was opened at 2004-12-17 05:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Friesner (jfriesne) >Assigned to: Martin v. Löwis (loewis) Summary: "slots" member variable in object.h confuses Qt moc utility Initial Comment: This isn't really a Python bug per se, but it's easy to fix so I'm filing a bug report anyway. The problem is with the line PyObject *name, *slots; in the definition of struct _heaptypeobject at line 343 of Include/object.h. I'm embedding Python into my app that uses the TrollTech Qt GUI, and Qt has a preprocessor program named "moc" that looks for certain non-standard keywords. One of these keywords is the word "slots"... so having a member variable named "slots" in Include/object.h confuses moc and causes my app to have a build error. I was able to fix the problem by renaming the "slots" member variable to "xslots" in the Python source, but it would be nicer if it was renamed in the official Python distribution so that the problem doesn't come up for the next guy. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:50 Message: Logged In: YES user_id=1188172 Ah, okay. However, I can't decide whether this will be done, assigning to Martin for this case. -- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-29 22:48 Message: Logged In: YES user_id=383828 Unfortunately, yes, When compiling with Qt, the words "signals" and "slots" become essentially reserved keywords, and any use of them as variable names causes a compile error. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:37 Message: Logged In: YES user_id=1188172 Okay. Most of your replacements are function parameters or function local variables, do they have to be replaced too? -- Comment By: Jeremy Friesner (jfriesne) Date: 2005-09-28 18:59 Message: Logged In: YES user_id=383828 Here is a file containing grep output showing all the lines where I changed 'slots' to 'xslots' in my codebase: http://www.lcscanada.com/jaf/xslots.zip -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-28 15:02 Message: Logged In: YES user_id=1188172 I can find 3 occurences in typeobject.c where the variable would have to be renamed. Can you find any other? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086854&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-883495 ] python crash in pyexpat's XmlInitUnknownEncodingNS
Bugs item #883495, was opened at 2004-01-23 23:15 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883495&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.3 Status: Open >Resolution: Works For Me Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: python crash in pyexpat's XmlInitUnknownEncodingNS Initial Comment: [forwarded from http://bugs.debian.org/229281] seen with 2.3.3, works with 2.2.3 and 2.1.3 (after fixing the 2.1 incompatibilities). The pyexpat code used is the one direct from the distribution, no external library. The attached testcase demonstrates a bug in, apparently, /usr/lib/python2.3/lib-dynload/pyexpat.so. Here's the bug in gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 28350)] 0x40566800 in XmlInitUnknownEncodingNS () from /usr/lib/python2.3/lib-dynload/pyexpat.so To try it youself, run "make" in the testcase directory. I apoligise for the size of this testcase; I would have whitteled it down to something simpler, but I am not a python programmer. I also apoligise if the bug is really in some library that python uses; I only went back as far as pyexpat.so. Some developers on IRC feel this may be exploitable. Talk with Scott James Remnant <[EMAIL PROTECTED]>, who also has some idea of the encoding problems in the rss file that are causing the crash. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:14 Message: Logged In: YES user_id=33168 Martin, this seems to work in Python 2.3.4, 2.4.2 and CVS. Has it been fixed and can it be closed? -- Comment By: Martin v. Löwis (loewis) Date: 2004-04-20 12:44 Message: Logged In: YES user_id=21627 The parser crashes because it invokes GetBuffer inside Parser, when Python is providing the next chunk of input, which reallocs the buffer to a different location. However, eventPtr is not updated inside GetBuffer (and neither is positionPtr). As a result, the next access to eventPtr (in XML_GetCurrentLineNumber, invoked from set_error), will cause a segfault. It is not clear to me why these pointers are not adjusted when the buffer is reallocated. However, a consistent fix appears to be to update the eventPtr close to the place where positionPtr is initialized, which is done in the attached patch exp.diff, which fixes this test case. Fred, can you please review this patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883495&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1122301 ] marshal may crash on truncated input
Bugs item #1122301, was opened at 2005-02-14 03:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122301&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 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: marshal may crash on truncated input Initial Comment: marshal doesn't behave well on truncated or otherwise malformed input. here's a short demo script, from a recent comp.lang.python thread: ::: the problem is that the following may or may not reach the "done!" statement, somewhat depending on python version, memory allocator, and what data you pass to dumps. import marshal data = marshal.dumps((1, 2, 3, "hello", 4, 5, 6)) for i in range(len(data), -1, -1): try: print marshal.loads(data[:i]) except EOFError: print "EOFError" except ValueError: print "ValueError" print "done!" (try different data combinations, to see how far you get on your platform...) fixing this should be relatively easy, and should result in a safe unmarshaller (your application will still have to limit the amount of data fed into load/loads, of course). ::: (also note that marshal may raise either EOFError or ValueError exceptions, again somewhat depending on how the file is damaged. a little consistency wouldn't hurt, but I'm not sure if/how this can be fixed...) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:19 Message: Logged In: YES user_id=33168 This works in CVS, but still not in 2.4. I guess the patch didn't get backported. -- Comment By: Michael Hudson (mwh) Date: 2005-05-27 02:36 Message: Logged In: YES user_id=6656 Ping! -- Comment By: Michael Hudson (mwh) Date: 2005-04-19 07:58 Message: Logged In: YES user_id=6656 I think the attached fixes this example, and another involving marshalled sets. I spent a while feeding random data to marshal a few days ago and found that the commonest problem was attempting to allocate really huge sequences. Also, the TYPE_STRINGREF is horribly fragile, but I'm hoping Martin's going to fix that (he has a bug filed against him, anyway). Can you test/check it in? My marshal.c has rather a lot of local changes. Also, a test suite entry would be nice... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122301&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1308042 ] Datagram Socket Timeouts
Bugs item #1308042, was opened at 2005-09-29 07:05
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&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: Works For Me
Priority: 5
Submitted By: Tom Vrankar (tvrankar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Datagram Socket Timeouts
Initial Comment:
Python 2.4.1, MS Windows 2000 with service packs
I'm trying to have a UDP client check for its server to
start by repeatedly throwing messages at where it's
expected to appear, and then checking for a response. I
set a timeout on the recvfrom, expecting to block for
the timeout and then proceeding to an exception
handler, looping so until data is returned. Instead,
the recvfrom throws an immediate exception "Connection
reset by peer", and I loop rapidly without the
load-softening effect of the timeout (in fact, it's the
same behavior as if I didn't set the timeout at all).
What UDP "connection" is it talking about?
Seems wrong, but is it the implementation or is it me?
If I start the server first, I get one "Invalid
argument" exception in the client. In both cases, once
the server is started, both processes are satisfied.
Thanks.
twv
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 22:30
Message:
Logged In: YES
user_id=33168
Can you program the client in C and see if it behaves the
same? Sockets are mostly just wrappers around the OS calls.
It's possible this is the expected behaviour on Windows and
python is just exposing that to you.
I ran this on Linux and got this (which is what I think you
want):
[EMAIL PROTECTED] clean $ ./python PyBug/client.py &
[1] 31484
[EMAIL PROTECTED] clean $ timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
./python PyBug/server.py
timed out
timed out
timed out
('127.0.0.1', 40899) says CHECK
('127.0.0.1', 3000) says OK
[10587 refs]
[10585 refs]
[1]+ Done./python PyBug/client.py
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1307978 ] Unsatisfied symbols: _PyGILState_NoteThreadState (code)
Bugs item #1307978, was opened at 2005-09-29 06:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&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: Goetz Isenmann (isenmann) Assigned to: Michael Hudson (mwh) Summary: Unsatisfied symbols: _PyGILState_NoteThreadState (code) Initial Comment: Compiling python 2.4.2 without threads (for hpux1020) results in an undefined symbol _PyGILState_NoteThreadState in Python/pystate.o. There are probably some "#ifdef WITH_THREAD"s missing. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:31 Message: Logged In: YES user_id=33168 Wasn't a fix for this checked in? Can this be closed? -- Comment By: Michael Hudson (mwh) Date: 2005-09-29 07:04 Message: Logged In: YES user_id=6656 Can you try the attached? -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 06:32 Message: Logged In: YES user_id=1188172 I'd think that a #ifdef WITH_THREAD around the _PyGILState_NoteThreadState call in pystate.c:192 is enough. -- Comment By: Michael Hudson (mwh) Date: 2005-09-29 06:28 Message: Logged In: YES user_id=6656 Aaargh, I expect you're right. Should be easy to fix, will have a patch for you to test shortly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307978&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin
Bugs item #1307798, was opened at 2005-09-29 03:05
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&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: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
>Assigned to: Jason Tishler (jlt63)
Summary: subprocess.Popen locks on Cygwin
Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.
When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576).
Using options stdin, stdout, stderr doesn't help.
I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded.
$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 22:33
Message:
Logged In: YES
user_id=33168
Jason, any comments? Is this cygwin specific or a general
subprocess issue?
--
Comment By: Peter Åstrand (astrand)
Date: 2005-09-29 12:32
Message:
Logged In: YES
user_id=344921
Does the testsuite test_subprocess.py work correctly on this
platform?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1180147 ] test_posix fails on cygwin
Bugs item #1180147, was opened at 2005-04-10 04:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180147&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.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Henrik Wist (wist) >Assigned to: Jason Tishler (jlt63) Summary: test_posix fails on cygwin Initial Comment: $ python test/test_posix.py testNoArgFunctions (__main__.PosixTester) ... ERROR test_access (__main__.PosixTester) ... ok test_chdir (__main__.PosixTester) ... ok test_dup (__main__.PosixTester) ... ok test_dup2 (__main__.PosixTester) ... ok test_fdopen (__main__.PosixTester) ... ok test_fstat (__main__.PosixTester) ... ok test_fstatvfs (__main__.PosixTester) ... ok test_ftruncate (__main__.PosixTester) ... ok test_lsdir (__main__.PosixTester) ... ok test_pipe (__main__.PosixTester) ... ok test_stat (__main__.PosixTester) ... ok test_statvfs (__main__.PosixTester) ... ok test_strerror (__main__.PosixTester) ... ok test_tempnam (__main__.PosixTester) ... ok test_tmpfile (__main__.PosixTester) ... ok test_umask (__main__.PosixTester) ... ok test_utime (__main__.PosixTester) ... ok == ERROR: testNoArgFunctions (__main__.PosixTester) -- Traceback (most recent call last): File "test/test_posix.py", line 40, in testNoArgFunctions posix_func() OSError: [Errno 22] Invalid argument -- Ran 18 tests in 0.038s FAILED (errors=1) Traceback (most recent call last): File "test/test_posix.py", line 159, in ? test_main() File "test/test_posix.py", line 156, in test_main test_support.run_unittest(PosixTester) File "/usr/lib/python2.3/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.3/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "test/test_posix.py", line 40, in testNoArgFunctions posix_func() OSError: [Errno 22] Invalid argument This is with cygwin 1.5.12-1 and python 2.3.4-2. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:34 Message: Logged In: YES user_id=33168 Jason, any comments? -- Comment By: Henrik Wist (wist) Date: 2005-04-14 02:56 Message: Logged In: YES user_id=1256464 Strangely enough, this works when deleting /etc/group or creating it with either local groups (mkgroup -l) or domain groups (mkgroup -d). I guess it is more a cygwin problem, then. -- Comment By: Henrik Wist (wist) Date: 2005-04-10 04:12 Message: Logged In: YES user_id=1256464 And, I forgot, this is with WinXP SP2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180147&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1179412 ] can't import thru cygwin symlink
Bugs item #1179412, was opened at 2005-04-08 12:42
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1179412&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: steveward (steveward)
>Assigned to: Jason Tishler (jlt63)
Summary: can't import thru cygwin symlink
Initial Comment:
This may be a cygwin-specific problem: given foo.py:
> ln -s foo.py bar.py
> python
Python 2.4 (#1, Dec 4 2004, 20:10:33)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> import foo
This is file foo.py.
>>> import bar
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named bar
Despite the problem with imports, most os.path utilities
(exists, isfile, islink, isdir) work on cygwin symlinks.
An exception is reailpath: realpath("bar.py") returns a
path to the symlink, not to the real file.
Suspecting this as a key to the import problem, I tried
several recent python/cygwin release versions (all
installed via cygwin's setup.exe).
FIndings:
Cygwin Python realpath Import
1.5.xx: 2.yy: Works? Works?
- -- --- --
1.5.14 2.4NO NO
1.5.13 2.3.4 YES NO
1.5.14 2.3.4 YES NO
1.5.12 2.4NOYES
Neither bug shows up under Linux.
The two problems seem uncorrelated, although it may
be that each is due to some assumpion about symlink
semantics that isn't true of the Cygwin implementation.
Apologies if these problems have been previously
submitted in a form my quick scan didn't identify. A
corresponding note has been submitted to the cygwin
mailing list.
- Steve
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 22:36
Message:
Logged In: YES
user_id=33168
Jason, comments?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1179412&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1101756 ] popen4/cygwin ssh hangs
Bugs item #1101756, was opened at 2005-01-13 08:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101756&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: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ph.E (ph_e) >Assigned to: Jason Tishler (jlt63) Summary: popen4/cygwin ssh hangs Initial Comment: The following python code hangs on executing cmd2 (works with cmd1). The commands works fine when executed on a shell. I have the same problem with Python 2.3.4 and 2.4 (Windows). I use the latest Cygwin binaries import os cmd1 = "bin\ssh" cmd2 = "bin\ssh -i id_dsa [EMAIL PROTECTED] uptime" def docmd(cmd): print "Doing %s ..." % cmd (stdin, stdouterr) = os.popen4(cmd) for line in stdouterr.readlines(): print line stdin.close() stdouterr.close() print "Done." if __name__ == '__main__': docmd(cmd1) docmd(cmd2) Give me some advice for testing (popen, linux, ...). -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:36 Message: Logged In: YES user_id=33168 Jason? -- Comment By: Ph.E (ph_e) Date: 2005-01-13 09:33 Message: Logged In: YES user_id=1196530 The same code in Linux Python 2.3.4 works fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101756&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-902151 ] Thread start - strange error under Cygwin
Bugs item #902151, was opened at 2004-02-22 07:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902151&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: Threads Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Artur de Sousa Rocha (adsr) >Assigned to: Jason Tishler (jlt63) Summary: Thread start - strange error under Cygwin Initial Comment: I wrote a short script that launches several threads (parallel download using urllib.urlretrieve in this case). Sometimes when I launch my script under Cygwin, I get strange error messages like: 2 [win] python 1912 Winmain: Cannot register window class Sometimes all of the threads run OK, otherwise after the "correct" ones finish the console stops responding. No problems with this script directly under Windows -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:37 Message: Logged In: YES user_id=33168 Jason? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902151&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-864374 ] 2.3.3 tests on cygwin
Bugs item #864374, was opened at 2003-12-22 03:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&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 Submitted By: Miki Tebeka (tebeka) >Assigned to: Jason Tishler (jlt63) Summary: 2.3.3 tests on cygwin Initial Comment: Hello, After running ./configure --prefix=/usr make make test I get the following --- 217 tests OK. 7 tests failed: test_bz2 test_fork1 test_largefile test_os test_popen2 test_pty test_tempfile 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_ioctl test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on cygwin. When running test_bz2, test_fork1, test_popen2, test_pty, test_tempfile alone they look ok (return value to OS is 0). For the others I'm attaching output. My system is win2k on IBM T30 (laptop). Cygwin 1.5.5. Miki -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:37 Message: Logged In: YES user_id=33168 Jason? -- Comment By: Miki Tebeka (tebeka) Date: 2005-08-28 04:02 Message: Logged In: YES user_id=358087 Sorry, due to some bizzar DLL relocation problems with cygwin I can't run the rull test suite. However test_bz2 fails *before* the test suite gets stuck -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-25 06:28 Message: Logged In: YES user_id=1188172 Can you verify this with 2.4.1 or a CVS version? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1308042 ] Datagram Socket Timeouts
Bugs item #1308042, was opened at 2005-09-29 07:05
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&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: Works For Me
Priority: 5
Submitted By: Tom Vrankar (tvrankar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Datagram Socket Timeouts
Initial Comment:
Python 2.4.1, MS Windows 2000 with service packs
I'm trying to have a UDP client check for its server to
start by repeatedly throwing messages at where it's
expected to appear, and then checking for a response. I
set a timeout on the recvfrom, expecting to block for
the timeout and then proceeding to an exception
handler, looping so until data is returned. Instead,
the recvfrom throws an immediate exception "Connection
reset by peer", and I loop rapidly without the
load-softening effect of the timeout (in fact, it's the
same behavior as if I didn't set the timeout at all).
What UDP "connection" is it talking about?
Seems wrong, but is it the implementation or is it me?
If I start the server first, I get one "Invalid
argument" exception in the client. In both cases, once
the server is started, both processes are satisfied.
Thanks.
twv
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 22:43
Message:
Logged In: YES
user_id=33168
This is a dupe of 1307357, but I'm closing that one since
most of the comments are here. However, note this one
comment from twv in the other report that says it also works
on Solaris 8 and could well be Windoze specific.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 22:30
Message:
Logged In: YES
user_id=33168
Can you program the client in C and see if it behaves the
same? Sockets are mostly just wrappers around the OS calls.
It's possible this is the expected behaviour on Windows and
python is just exposing that to you.
I ran this on Linux and got this (which is what I think you
want):
[EMAIL PROTECTED] clean $ ./python PyBug/client.py &
[1] 31484
[EMAIL PROTECTED] clean $ timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
./python PyBug/server.py
timed out
timed out
timed out
('127.0.0.1', 40899) says CHECK
('127.0.0.1', 3000) says OK
[10587 refs]
[10585 refs]
[1]+ Done./python PyBug/client.py
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1307357 ] Datagram Socket Timeouts
Bugs item #1307357, was opened at 2005-09-28 14:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307357&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Tom Vrankar (tvrankar) Assigned to: Nobody/Anonymous (nobody) Summary: Datagram Socket Timeouts Initial Comment: Python 2.4.1, MS Windows 2000 with service packs I'm trying to have a UDP client check for its server to start by repeatedly throwing messages at where it's expected to appear, and then checking for a response. I set a timeout on the recvfrom, expecting to block for the timeout and then proceeding to an exception handler, looping so until data is returned. Instead, the recvfrom throws an immediate exception "Connection reset by peer", and I loop rapidly without the load-softening effect of the timeout (in fact, it's the same behavior as if I didn't set the timeout at all). What UDP "connection" is it talking about? Seems wrong, but is it the implementation or is it me? If I start the server first, I get one "Invalid argument" exception in the client. In both cases, once the server is started, both processes are satisfied. Thanks. twv -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:44 Message: Logged In: YES user_id=33168 Dupe of 1308042 -- Comment By: Tom Vrankar (tvrankar) Date: 2005-09-29 10:15 Message: Logged In: YES user_id=1353485 BTW: On Solaris 8 it works as expected, with a "timed out" exception after the requested time out for each recvfrom until the server appears. This may be a Windoze-specific socket-ism. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307357&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1295808 ] expat symbols should be namespaced in pyexpat
Bugs item #1295808, was opened at 2005-09-19 14:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&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: 5 Submitted By: Trent Mick (tmick) >Assigned to: Martin v. Löwis (loewis) Summary: expat symbols should be namespaced in pyexpat Initial Comment: The Problem: - you embed Python in some app - the app dynamically loads libexpat of version X - the embedded Python imports pyexpat (which was built against libexpat version X+n) --> pyexpat gets the expat symbols from the already loaded and *older* libexpat: crash (Specifically the crash we observed was in getting an old XML_ErrorString (from xmlparse.c) and then calling it with newer values in the XML_Error enum: // pyexpat.c, line 1970 ... // Added in Expat 1.95.7. MYCONST(XML_ERROR_UNBOUND_PREFIX); ... The Solution: Prefix all a exported symbols with "PyExpat_". This is similar to what Mozilla does for some common libs: http://lxr.mozilla.org/seamonkey/source/modules/libimg/png/mozpngconf.h#115 I'll attach the gdb backtrace that we were getting and a patch. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:01 Message: Logged In: YES user_id=33168 This seems to be a duplicate of bug #1075984. I like this patch better, but perhaps both patches (the one here and the other bug report) should be implemented? I think Martin helps maintain pyexpat. Maybe he has some ideas about either or both of these bugs/patches. Martin, do you think these are safe to apply? I can apply the patch(es) if you think it's safe. Trent, is this patch sufficient to meet your embedding needs so that nothing else needs to be done? I do not think this patch can be applied to 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295808&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI
Bugs item #1075984, was opened at 2004-11-30 05:13
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&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: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Memory fault pyexpat.so on SGI
Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m
cc -version
MIPSpro Compilers: Version 7.3.1.3m
- make tests passes test_pyexpat without error
- running this code leads to a core dump
-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)
<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)
- running this code from an interactive session leads
not to a coredump
I need some assistance howto provide further debug
information.
--maik./
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 23:01
Message:
Logged In: YES
user_id=33168
The problem seems to be related (same?) as bug #1295808.
Does the patch there fix these problems?
--
Comment By: Steve Juranich (sjuranic)
Date: 2005-07-19 09:22
Message:
Logged In: YES
user_id=1315245
FWIW, this same problem crops up when using Python & VTK
together (which also ships with its own version of expat).
bos's workaround will make things work, though.
--
Comment By: Bernhard Herzog (bernhard)
Date: 2005-03-29 10:11
Message:
Logged In: YES
user_id=2369
I ran into this problem as well on a debian GNU/Linux system
on x86 hardware. It occurs both with pygtk 2.4 and wxPython
2.5 both built against gtk 2.4.
bos' patch at least solves the immediate problem of the
segmentation fault. It may be a good idea to print a
warning message if some of the error codes cannot be
translated to strings, though.
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-04 15:16
Message:
Logged In: YES
user_id=28380
With the GNU linker, you can pass in -Bstatic to force it to resolve the
symbols in the local shared library, instead of globally. This also works on
Irix. I don't know about other Unixes.
--
Comment By: Michael Hudson (mwh)
Date: 2005-02-02 02:35
Message:
Logged In: YES
user_id=6656
It's a nasty one, I'll give you that.
Fred, what do you think of bos's patch? It solves the immediate issue,
but I'm not sure it's a complete fix.
It seems to me that it would be better to resolve the expat symbols at
builf time, but I don't know how to arrange for that.
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-01 22:09
Message:
Logged In: YES
user_id=28380
By the way, this is not an SGI-specific bug. This will bite any Unix system
with a modern sysv-style dynamic linker. The priority of this bug should be
higher, IMO.
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-01-31 23:53
Message:
Logged In: YES
user_id=28380
I've been bitten by the same bug. In my case, the problem was with Qt, not GTK.
It's not actually necessary to check the expat version; just see if
XML_ErrorString actually returns anything.
Here's the patch I use for this problem:
--- python/Modules/pyexpat.c2005-01-06 16:26:13 -08:00
+++ python/Modules/pyexpat.c 2005-01-31 23:46:36 -08:00
@@ -1936,9 +1936,12 @@
}
#endif
-#define MYCONST(name) -PyModule_AddStringConstant(errors_module, #name, -
(char*)XML_ErrorString(name))
+#define MYCONST(name) +{ +char *_v =
(char*)XML_ErrorString(name); +
[ python-Bugs-1294032 ] Distutils writes keywords comma-separated
Bugs item #1294032, was opened at 2005-09-17 12:56 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294032&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 Submitted By: Martijn Pieters (mjpieters) >Assigned to: A.M. Kuchling (akuchling) Summary: Distutils writes keywords comma-separated Initial Comment: The distutils package writes out the Keywords metadata field in PKG-INFO comma-separated, while the Cheeseshop/PyPI follows the PEP 341 example and seems to expect space separated keywords. Either this needs clarifying in the PEP or docutils or PyPI should be altered to better integrate. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:02 Message: Logged In: YES user_id=33168 Andrew are you working on this stuff now? If not, is Richard? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294032&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1276768 ] dirutils.mkpath (verbose option does not work)
Bugs item #1276768, was opened at 2005-08-30 08:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276768&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.4 Status: Open Resolution: None Priority: 5 Submitted By: gorilla_killa (gorilla_killa) Assigned to: Nobody/Anonymous (nobody) Summary: dirutils.mkpath (verbose option does not work) Initial Comment: The Verbose option does not work. Looked at the python script for dir_utils.py and the verbose parameter is not used in the code. Please fix this simple bug. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:29 Message: Logged In: YES user_id=33168 Can you provide a patch which behaves as you expect? Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1276768&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1261714 ] precompiled code and nameError.
Bugs item #1261714, was opened at 2005-08-16 23:50
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261714&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vladimir Menshakov (megath)
Assigned to: Nobody/Anonymous (nobody)
Summary: precompiled code and nameError.
Initial Comment:
i experienced problem with call'ing python unmarshalled
and eval'ed code.
similar problem described in mailing list, but
unfortunately has not got any solution or work-around.
http://mail.python.org/pipermail/c++-sig/2003-October/006094.html
actually I have code like this:
-
import m
class A:
def do(self):
print m.User().GetName()
test.py
a = A()
a.do()
running script from python works perfectly. but when I
call 'do' from c++ code I get following error :
PyObject_CallMethod: exceptions.NameError:global name
'm' is not defined
I checked locals dictionary, it contains missing name
('m').
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 23:30
Message:
Logged In: YES
user_id=33168
Can you provide the c++ code? Thanks.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261714&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1250170 ] gethostbyname(gethostname()) fails on misconfigured system
Bugs item #1250170, was opened at 2005-08-02 05:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250170&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tadeusz Andrzej Kadlubowski (tkadlubo) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyname(gethostname()) fails on misconfigured system Initial Comment: Hello, I downloaded python CVS tree, compiled it and ran tests. Two tests failed: urllib2 and mimetools. Both in the same fashion, when doing socket.gethostbyname(socket.gethostname()) (It is used in mimetools.py library in line 130 and in test_urllib2.py test unit in line 352.) In the interpreter it fails in the following way: >>> import socket >>> socket.gethostbyname(socket.gethostname()) Traceback (most recent call last): File "", line 1, in ? socket.gaierror: (-2, 'Name or service not known') The reason is that my hostname is bogus, no single DNS knows about it, and I don't see any reason to set up a DNS server on my box. Of course editing /etc/hosts and adding my hostname as an alias for 127.0.0.1 solves the problem. Anyway I don't see any particular reason why the library shouldn't handle such situation i.e. when there's no connection between hostname and IP address. What do you think about it? I can make a SF patch item to solve this issue if you like. I am quite sure adding try/catch will make it in both cases. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:33 Message: Logged In: YES user_id=33168 Please provide a patch and attach it to this report. Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250170&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1245381 ] log() on a big number fails on powerpc64
Bugs item #1245381, was opened at 2005-07-26 09:38
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiri Dluhos (jdluhos)
Assigned to: Nobody/Anonymous (nobody)
Summary: log() on a big number fails on powerpc64
Initial Comment:
The log() function seems to give incorrect results for
large numbers on a 64-bit powerpc architecture. The
test_math program from the Python test suite fails with
the following message:
math module, testing with eps 1e-05
constants
acos
asin
atan
atan2
ceil
cos
cosh
degrees
exp
fabs
floor
fmod
frexp
hypot
ldexp
log
Traceback (most recent call last):
File "test_math.py", line 117, in ?
testit('log(10**40, 10)', math.log(10**40, 10), 40)
File "test_math.py", line 13, in testit
raise TestFailed, '%s returned %f, expected
%f'%test.test_support.TestFailed: log(10**40, 10) returned
21.938200, expected 40.00
Tested on a SMP IBM PowerPC machine, with Python 2.3.4
(64-bit build).
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 23:36
Message:
Logged In: YES
user_id=33168
Can you test with newer versions of Python, preferrably
2.4.2 or current CVS? 2.3.4 worked for me on 64-bit Opteron.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1234328 ] 'insufficient disk space' message wrong (msi on win xp pro)
Bugs item #1234328, was opened at 2005-07-07 11:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234328&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Vrijlandt (pvrijlandt) >Assigned to: Martin v. Löwis (loewis) Summary: 'insufficient disk space' message wrong (msi on win xp pro) Initial Comment: I'm trying to do a non-admin install of python 2.4.1 using the msi on win xp pro. Our environment is pretty customized; in an ordinary explorer window I see drives I, J but no C. "My Documents" refers to i:\ which is an alias for \\\username. I'm installing to i:\\python241 for my user only. The server has enough diskspace and my diskspace is not limited. When I try to install, bug #1232947 occurs; but when I try to do the same install with a usb-stick attached (which appears as volume "e:"), the installer complains that E has insufficient disk space. In fact, this was true: but I was not installing on E but on I. The disk usage button by the way shows enough diskspace on I: and does not list E: -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:39 Message: Logged In: YES user_id=33168 Martin, do you have time for this one? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234328&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
