[issue1073] Mysterious failure under Windows

Changes by Aki: -- severity: major status: open title: Mysterious failure under Windows versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1073] Mysterious failure under Windows

New submission from Aki: Hi, I'm not sure this is a right place to write in the problem I found. What I found was: (1) create a thread (2) open a file in the thread (3) everything works fine under Solaris (4) Openning a file in the thread fails intermittenly under Windows Not always it

[issue1073] Mysterious failure under Windows

Aki added the comment: I know it is hard to believe. I spent days to try out many things. For example, I added the following: try: print os.path.isfile(fn) <<<--- fd = open(fn, 'rb') crypted = fd.read()

[issue1073] Mysterious failure under Windows

Aki added the comment: Sorry to disappoint you but ... (1) Does the file exist before program is started, and remains after program finishes? Yes and Yes (2) Do you change the current directory (with os.chdir or similar)? No. The file is in the current directory where the program was invoked

[issue1777530] ctypes on Solaris

Aki added the comment: Hello Thomas, Thank you for creating the patch. Unfortunately, it didn't work. (I rerun the whole installation process) You used the following to check if the os is Solaris: if sys.platform.startswith("solaris"): Under Solaris 2.x sys.platform return

[issue1095] make install failed

New submission from Aki: I thought this was already reported but I didn't see it in the list. If this issue is already addressed, please discard. The 'make install' failed if I re-run the installation again because python-config under /usr/local/bin was already there. Removing

[issue1095] make install failed

Aki added the comment: > Shouldn't ln -f ignore existing destination files? > What system is that? Well, it was on Solaris 9. Under Solaris, ln -sf won't clobber an existing soft link. I don't know if there is a work around of this rather than removing the link explicitly

[issue1777530] ctypes on Solaris

Aki added the comment: Sorry for not having done this earlier. I thought this was already closed ... I used your updated patch and installed the Python 2.5.1 from scratch. It worked without any problem except python-config issue, which I have reported in another case [issue1095

[issue4902] failed to build ctypes in Python2.6.1 (even with gcc)

New submission from Aki : I'm trying to build Python 2.6.1 on Solaris/x86 machine but it puked. gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/home/neko/gnu/Python-2.6.1/./Include -Ibuild/temp.solaris-2.10-i86pc-2.6/libffi/include -Ibuild/temp.so

[issue4902] failed to build ctypes in Python2.6.1 (even with gcc)

Aki added the comment: Hello Martin, Thank you for your prompt response. I recompiled the source with --save-temps. I examined the assembler source and found that it was complaining about '~'! movl 10 + 3) & ~3) + 4) + 4)(%eax), %edx ^ this one The sourc

[issue4902] failed to build ctypes in Python2.6.1 (even with gcc)

Aki added the comment: I have installed GNU binutil package to my machine to use GNU as. I re-run configure but configure somehow always found Sun as rather than GNU as even I saw GNU as first from my csh environment. I temporalily renamed Sun as so that configure was forced to use GNU as

[issue4902] failed to build ctypes in Python2.6.1 (even with gcc)

Aki added the comment: > I'm really puzzled; gcc would normally not generate assembler code like this. This is because an assembler source (sysv.S) was given. Python-2.6.1/Modules/_ctypes/libffi/src/x86/sysv.S It was created by Red Hat. A macro, RAW_CLOSURE_CIF_OFFSET,

[issue5527] multiprocessing won't work with Tkinter (under Linux)

New submission from Aki : Hello, The attached test case, which uses multiprocessing module to run Tkinter GUI process, runs flawlessly under Solaris but hung under Linux (CentOS5). The test case is a trimmed version of much larger program but it still exhibits the same problem. I got a

[issue5527] multiprocessing won't work with Tkinter (under Linux)

Aki added the comment: Hello Jani Hakala, Thank you very much for working on the case I created. And, sorry for not getting back to you. I have confirmed observation that the problem is fixed under Linux if Tkinter is imported after fork(). However, this remains a problem for me and most

[issue5527] multiprocessing won't work with Tkinter (under Linux)

Aki added the comment: Hello Jani Hakala, Thank you for your suggestions. Yes, from Tkconstants import * would ease the pain. The second suggestion, importing gui in another file didn't work well with my code as I'm using a class to host both gui process and non-gui process

[issue17368] Python version of JSON decoder does not work with object_pairs_hook

New submission from Aki: Specifying any object_pairs_hook makes JSON decoding break when JSONObject from json/decoder.py is used. Can be emulated easily by setting c_make_scanner = None at json/scanner.py Example script: ** import json test = '{"key": "value", &quo

[issue4652] IDLE does not work with Unicode

New submission from Aki Wakabayashi : I have installed python 3.0 on Ubuntu 8.10 yesterday and played around with the new unicode features and had no problems with Japanese characters(both in interactive and script mode). However, after rebooting, IDLE will no longer let me input any Japanese

[issue1602] windows console doesn't print or input Unicode

Changes by Aki Sasaki : -- nosy: +escapewindow ___ Python tracker <http://bugs.python.org/issue1602> ___ ___ Python-bugs-list mailing list Unsubscribe: