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

Changes by Aki Sasaki a...@escapewindow.com: -- nosy: +escapewindow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list

[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, empty: {}}' def hook(pairs

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

Aki akin...@users.sourceforge.net 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

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

Aki akin...@users.sourceforge.net 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

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

New submission from Aki akin...@users.sourceforge.net: 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

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

New submission from Aki akin...@users.sourceforge.net: 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

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

Aki akin...@users.sourceforge.net 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

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

Aki akin...@users.sourceforge.net 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

[issue4652] IDLE does not work with Unicode

New submission from Aki Wakabayashi zzyzx2...@gmail.com: 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

[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

[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 returns sunos5. You could

[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 /usr/local/lib

[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 fails

[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() fd.close

[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