[issue28459] _pyio module broken on Cygwin / setmode not usable
Masayuki Yamamoto <ma3yuki.8mam...@gmail.com> added the comment: FYI, cygwin-pyio-setmode.patch includes two extra parts for running on Cygwin. First, fix import error for ctypes (unopened issue). Second, fix building _ctypes module (#4032 - PR 4153). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32287] Import of _pyio module failed on cygwin
Masayuki Yamamoto <ma3yuki.8mam...@gmail.com> added the comment: This issue seems to duplicate #28459. #28459 has a patch (implement _setmode() by ctypes on _pyio). I'm not sure _setmode() will be used in other places in the future, but the patch just works at the moment. In addition, I have an idea which implements C extension (imitation msvcrt or just cygwin). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32287> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28117] warning: dereferencing type-punned pointer will break strict-aliasing rules
Masayuki Yamamoto <ma3yuki.8mam...@gmail.com> added the comment: Serhiy, would you open a PR? Your patch looks good to me. I've been looking at the warning on my machine (ubuntu 16.04 x86), it's a bit annoying to me. -- nosy: +masamoto ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8548] Building on CygWin 1.7: PATH_MAX redefined
Masayuki Yamamoto <ma3yuki.8mam...@gmail.com> added the comment: This issue has been out-of-date since Python 3.4 maintenance became security status. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue8548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14598] _cursesmodule.c fails with ncurses-5.9 on Linux
Masayuki Yamamoto <ma3yuki.8mam...@gmail.com> added the comment: Probably, yes. ncurses on Cygwin has provided is_pad() [*]. In addition, the old version of Cygwin will become to not define WINDOW_HAS_FLAGS by issue25720. [*] newer version than patchlevel 20090906 was provided on Cygwin in 2009. https://sourceware.org/ml/cygwin-announce/2009-11/msg00025.html -- status: pending -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue14598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25720] Fix curses module compilation with ncurses6
Masayuki Yamamoto <ma3yuki.8mam...@gmail.com> added the comment: I opened PR 4164 to improve the is_pad configure check and previous PR was closed. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25720] Fix curses module compilation with ncurses6
Change by Masayuki Yamamoto <ma3yuki.8mam...@gmail.com>: -- pull_requests: +4133 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4032] distutils doesn't search ".dll.a" as library on cygwin
Masayuki Yamamoto <ma3yuki.8mam...@gmail.com> added the comment: I opened PR 4153 that is an alternative for PR 4136 (issue2445). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue4032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4032] distutils doesn't search ".dll.a" as library on cygwin
Change by Masayuki Yamamoto <ma3yuki.8mam...@gmail.com>: -- pull_requests: +4121 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue4032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31828] Support Py_tss_NEEDS_INIT outside of static initialisation
Change by Masayuki Yamamoto <ma3yuki.8mam...@gmail.com>: -- keywords: +patch pull_requests: +4067 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31828] Support Py_tss_NEEDS_INIT outside of static initialisation
Masayuki Yamamoto <ma3yuki.8mam...@gmail.com> added the comment: Or Py_tss_NEEDS_INIT is removed from the C API document to become a private feature; in other words, the Python interpreter will recommend that the static allocation for the TSS key shouldn't be used in the API client codes except for the interpreter core and built-in modules. (okay, I know it's an unfair suggestion) BTW, it's my mistake which the word "default value" for Py_tss_NEEDS_INIT, actually it makes more sense "initializer". I'd like to fix the document and the PEP, would I open the PR with this issue? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: FYI, PEP 539 was accepted (see python-dev threads [1] [2]). The only thing missing is a reference implementation, next I complete it. [1] https://mail.python.org/pipermail/python-dev/2017-August/149091.html [2] https://mail.python.org/pipermail/python-dev/2017-September/149354.html -- versions: -Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: Since previous comment, I've studied the switch for show/hide implementation detail. As the result, I have understood the Py_BUILD_CORE macro hasn't been generally used for hiding implementation detail (and Py_LIMITED_API does the part). Therefore, I withdraw previous proposal for implementation detail, and I'm going to fix PEP a few. After that, I'd like to post to python-dev to know the developer's view of the PEP draft. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: oh, I found a mistake. - replace Py_LIMITED_API with Py_BUILD_CORE on Include/pythread.h Py_tss_t definition -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: Nick and Erik, thank you for the comments! I merged proposal into the PR. Well, I'm interested in the hide implementation detail for TSS API (lately, I've read the python-ideas thread "PEP: Hide implementation details in the C API" which Victor opened [1]). Present, the draft of new API has given two methods for thread key initialization for the non-limited API (i.e. Py_tss_NEEDS_INIT for statically, PyThread_tss_alloc for dynamic). The static initialization needs implementation detail for thread key, but Py_tss_t is designed as an opaque data type based on the stable ABI and we don't feel like to open the implementation detail to the API client. On the other hand, we'd provide newly thread key (de-)allocation functions for the limited API, the API client is able to get an initialized value without knowing thread key detail. And also the functions can be used on the non-limited API. Therefore, I think it makes more sense that all API clients use PyThread_tss_(alloc|free) regardless of the limited API. The reason is which are (1) Py_tss_t behaves as an opaque data type as expected for any API client (cannot read and write directly the fields in any case), (2) the API gets more consistency (just one method for key initialization on the API client). TL;DR: I'd suggest to make key type strict, what do you think about below changes? - replace Py_LIMITED_API with Py_BUILD_CORE on Python/pythread.h Py_tss_t definition - use PyThread_tss_(alloc|free) in Modules/_tracemalloc.c - also use in Modules/_testcapimodule.c [1] https://mail.python.org/pipermail/python-ideas/2017-July/046399.html -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: Hi, I attempted Nick's proposal and removed unused codes from TLS implementation (bpo-30279, bpo-30832). This change looks good to me (PR 1362). As the result, I think ready to be more slim API because the own implementation for TLS was removed. Therefore, additional proposal to two API functions: * Omit PyThread_ReInitTSS function * Omit PyThread_tss_delete_value function These functions have handled memory deallocation to key-value storage on the own implementation, but above said, currently the own implementation is gone. It means: 1. PyThread_ReInitTSS makes to be no-op for all supported platforms (Windows and pthreads) 2. likewise PyThread_tss_delete_value just does to empty the storage (i.e. "PyThread_tss_delete_value(key)" makes to be equal to "PyThread_tss_set(key, NULL)"). We (or at least I) won't get back to the own implementation, therefore, I suggest to omit these functions for new TSS API. See proposed updates https://github.com/ma8ma/cpython/pull/1 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30854] Compile error on Python/ceval.c without threads
Changes by Masayuki Yamamoto <ma3yuki.8mam...@gmail.com>: -- pull_requests: +2654 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30854> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30854] Compile error on Python/ceval.c
Changes by Masayuki Yamamoto <ma3yuki.8mam...@gmail.com>: -- pull_requests: +2651 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30854> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30703] Non-reentrant signal handler (test_multiprocessing_forkserver hangs)
Changes by Masayuki Yamamoto <ma3yuki.8mam...@gmail.com>: -- pull_requests: +2652 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30703> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30854] Compile error on Python/ceval.c
New submission from Masayuki Yamamoto: I found a syntax error when compiling without threads. In that place, the colon has been used instead of semicolon at end of statement. build commands and error log: $ uname -a Linux masayuki-P35-DS3 4.4.0-83-generic #106-Ubuntu SMP Mon Jun 26 17:54:25 UTC 2017 i686 i686 i686 GNU/Linux $ git checkout master $ ./configure --without-threads && LC_ALL=C make -j2 (snip) gcc -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I. -I./Include-DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c Python/ceval.c: In function 'Py_MakePendingCalls': Python/ceval.c:551:23: error: expected ';' before ':' token goto error: ^ Makefile:1551: recipe for target 'Python/ceval.o' failed make: *** [Python/ceval.o] Error 1 related changeset: 3024c0529077f5cff0b32dc84b5923c8fba99a87 [3.6] bpo-30703: Improve signal delivery (GH-2415) (#2527) c08177a1ccad2ed0d50898c2731b518c631aed14 bpo-30703: Improve signal delivery (#2415) I open one line change PR that replaces colon with semicolon for master branch right away. -- components: Build messages: 297711 nosy: masamoto, pitrou priority: normal severity: normal status: open title: Compile error on Python/ceval.c type: compile error versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30854> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30832] Remove own implementation for thread-local storage
Changes by Masayuki Yamamoto <ma3yuki.8mam...@gmail.com>: -- pull_requests: +2604 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30832] Remove own implementation for thread-local storage
New submission from Masayuki Yamamoto: CPython has provided the own implementation for thread-local storage (TLS) on Python/thread.c, it's used in the case which a platform has not supplied native TLS. However, currently all supported platforms (NT and pthreads) have provided native TLS and defined the Py_HAVE_NATIVE_TLS macro with unconditional in any case. Therefore, I'd propose removing outdated code. python-dev: https://mail.python.org/pipermail/python-dev/2017-July/148534.html -- components: Interpreter Core messages: 297543 nosy: haypo, masamoto priority: normal severity: normal status: open title: Remove own implementation for thread-local storage type: enhancement versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25720] Fix curses module compilation with ncurses6
Masayuki Yamamoto added the comment: Ping. I updated PR a bit: macOS is joined to new compile condition and remove platform-specific condition. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30609] Python 3.6.1 fails to generate 256 colors on Cygwin based 64-bit Windows 10
Masayuki Yamamoto added the comment: @rigordo Are you using mintty? If I remember rightly, mintty hasn't been set 256 colors after installation (at least in past release, I'm not sure currently). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25720] Fix curses module compilation with ncurses6
Masayuki Yamamoto added the comment: Hi, I finished various things and tackle the issue again, I opened PR 1689 at last. Changes from previous patch: * If ncurses doesn't have both is_pad function and _flags field of WINDOW, NCURSES_OPAQUE is defined as zero to make WINDOW to non-opaque type before including ncurses.h. * The conditional compile on function definition are kept, it replaces WINDOW_HAS_FLAGS with py_is_pad macro itself. * Unindent the blocks that places after section of the conditional compile on function definition. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25720] Fix curses module compilation with ncurses6
Changes by Masayuki Yamamoto <ma3yuki.8mam...@gmail.com>: -- pull_requests: +1782 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30279] Remove unused Python/thread_foobar.h
New submission from Masayuki Yamamoto: Python/thread_foobar.h is the template code that is threading adaptation for new platforms, and it hasn't been used on actual platforms. As a matter of fact, Python/thread_pthread.h and Python/thread_nt.h give concrete examples of adaptation, therefore, I think thread_foobar.h hasn't needed no more. In addition, there was an issue that only changed thread_foobar.h to fix overlooking (issue21312). python-dev: https://mail.python.org/pipermail/python-dev/2017-May/147840.html -- components: Interpreter Core messages: 293057 nosy: masamoto priority: normal severity: normal status: open title: Remove unused Python/thread_foobar.h type: enhancement versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30279> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: Victor, The tracemalloc module is not available on platforms that provides own TLS implementation that uses PyMem_* functions. In the own implementation, it occurs deadlock by recursion call in thread key search. PyOnceVar API handles extendable array by using PyMem_Reallloc, therefore, I think TSS key initialization using the API will raise deadlock likewise. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Changes by Masayuki Yamamoto <ma3yuki.8mam...@gmail.com>: -- pull_requests: +1472 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29718] Fixed compile on cygwin.
Masayuki Yamamoto added the comment: We should avoid to submit quickfix to official as much as we can. Especially the case of unofficial (or inarticulate) support platform, a patch for specific platform is probably rejected because the code won't be maintained. Thread Specific Storage API (TSS) has been designed to work on more platforms, but it has incompatible changing and the API merging needs official acceptance for the PEP 539. (Please wait PEP author, or you can discuss for the new API or alternatives, see #25658 for details) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29718] Fixed compile on cygwin.
Masayuki Yamamoto added the comment: The patch can split to several issues, moreover, some issues are able to pick up as general not Cygwin specific. Perhaps, it will be an opportunity to fix even if Cygwin specific, if we could explain the implicit issue on implementation. See #4032, #25658, #25720, #27374, #28441 and #28459. Of course your patch has solutions for issues that are not yet known in the bug tracker. -- nosy: +masamoto ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: Above said, I updated minor changes to the version 2 patch. Several codes have kept the words "thread local" and "TLS" because they have pointed programming method or other meanings, not CPython TLS API itself. (e.g. _decimal module) -- Added file: http://bugs.python.org/file46379/pythread-tss-3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: I commented at the Rietveld, since I think that patch needs a bit more modification. * rename PyThread_ReInitTLS * update comments and messages that have explained CPython TLS API -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: After Erik posted PEP 539 draft, we've discussed features of new API on the Python-ideas [*]. As the result of discussion, features of new API have been changed below points. Thus, I updated patch based on the result. 1. API uses opaque type because to cover the key details. 2. The key has the state that is whether initialized, and a function is added to check the state. 3. When key creation and deletion, API silently skips function in unnecessary case (i.e. valid key never be overwritten). 4. The test is added to check the key state that after calling API. [*] https://mail.python.org/pipermail/python-ideas/2016-December/043983.html -- Added file: http://bugs.python.org/file46227/pythread-tss-2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29170] Curses Module should check for is_keypad and not window flags
Masayuki Yamamoto added the comment: #25720 is a similar issue that is originated by opaque type WINDOW. -- nosy: +masamoto ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28768] Warning: implicit declaration of function '_setmode'
Masayuki Yamamoto added the comment: Building 2.7 is for testing purposes. It is used to judge whether it is a problem (specifically for Cygwin-specific) originated in the old version. _setmode is an important function for setting input and output of CPython, so in Cygwin I feel annoying that warnings are issued even though there is actually no problem. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: I wrote a patch based on msg281227's idea. I confirmed to pass related tests (test_capi, test_threading and test_tracemalloc) on Cygwin x86 and Ubuntu 16.04 x86. This patch adds to change CPython about: 1. Avoid compile error on Currently TLS API. With POSIX threads, configure script checks pthread_key_t type. And if the type is not integer, TLS API is implemented empty (do nothing or return fail). 2. Implement New TSS API based on C11 threads. Thread key type is changed wrapped native TLS key type by typedef instead of integer, and the key parameter on key create function is changed to calling by pointer. Key create function doesn't support destructor because users have need to manage memory. And this patch changes Currently TLS API to call New TSS API. Or does it need to keep implementation? 3. Move to TSS API. Py_DEPRECATED(3.7) is added to TLS API declaration, and Modules/_tracemalloc.c and Python/pystate.c are modified to use TSS API instead of TLS API. -- Added file: http://bugs.python.org/file45763/pythread-tss.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: Elik, Ed, I have overlooked tracemalloc module raises deadlock if apply the patch. I found out a source comment on Modules/_tracemalloc.c:161 /* If your OS does not provide native thread local storage, you can implement it manually using a lock. Functions of thread.c cannot be used because they use PyMem_RawMalloc() which leads to a reentrant call. */ #if !(defined(_POSIX_THREADS) || defined(NT_THREADS)) # error "need native thread local storage (TLS)" #endif Py_HAVE_NATIVE_TLS is used only on thread source code. Therefore C Compiler couldn't report error about tracemalloc. I'm sorry that I didn't check test. Currently I'm trying to implement new API based on msg281227. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28441] Change sys.executable to include executable suffix
Changes by Masayuki Yamamoto <ma3yuki.8mam...@gmail.com>: Added file: http://bugs.python.org/file45685/sys-executable-suffix-3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28441] Change sys.executable to include executable suffix
Changes by Masayuki Yamamoto <ma3yuki.8mam...@gmail.com>: Removed file: http://bugs.python.org/file45684/sys-executable-suffix-3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28441] Change sys.executable to include executable suffix
Masayuki Yamamoto added the comment: I updated a patch to check the made path because previous patch has added suffix even to symbolic link. New patch works that If made path is invalid, revert to original. -- Added file: http://bugs.python.org/file45684/sys-executable-suffix-3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28802] Python 3.6.0b4 Reports ncurses present in Cygwin but fails to build for cygwin
New submission from Masayuki Yamamoto: We're discussing a cause of this issue at #25720. -- nosy: +masamoto ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28802> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28768] Warning: implicit declaration of function '_setmode'
Changes by Masayuki Yamamoto <ma3yuki.8mam...@gmail.com>: Added file: http://bugs.python.org/file45593/2.7-include-io.h.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28768] Warning: implicit declaration of function '_setmode'
New submission from Masayuki Yamamoto: Platform that appeared warning is Vista Cygwin x86. Interpreter execution doesn't crash because _setmode function is supplied from cygwin1.dll that always linked. Warning reason is header io.h [*] doesn't include to source file. Therefore I wrote two patches for 3.7 and 2.7. [*] https://msdn.microsoft.com/en-us/library/tw4k6df8.aspx (Cygwin also avaliable) build log on 3.7: gcc -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -I. -I./Include -DPy_BUILD_CORE -o Modules/main.o Modules/main.c Modules/main.c: In function 'Py_Main': Modules/main.c:599:5: warning: implicit declaration of function '_setmode' [-Wimplicit-function-declaration] _setmode(fileno(stdin), O_BINARY); ^ gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -I. -I./Include -DPy_BUILD_CORE -I./Modules/_io -c ./Modules/_io/fileio.c -o Modules/fileio.o ./Modules/_io/fileio.c: In function '_io_FileIO___init___impl': ./Modules/_io/fileio.c:478:5: warning: implicit declaration of function '_setmode' [-Wimplicit-function-declaration] _setmode(self->fd, O_BINARY); ^ -- components: Build files: include-io.h.patch keywords: patch messages: 281389 nosy: benjamin.peterson, masamoto, stutzbach priority: normal severity: normal status: open title: Warning: implicit declaration of function '_setmode' type: compile error versions: Python 2.7, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45592/include-io.h.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: I wrote a patch to avoid compile error for platforms that pthread_key_t is not integer. This patch changes to turn off Py_HAVE_NATIVE_TLS if pthread_key_t is not integer. Hence the platforms use TLS functions implemented by CPython self. And, I would propose new thread local storage API based on C11 thread and current TLS functions move to deprecated. C11 tss_t doesn't require defined as integer [1]. Therefore I think new API should use tss_t, not hide into integer. [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf (page 394) I'm thinking of new interfaces. For example, declaration in Include/pythread.h /* Specialise to each platforms using #if directive */ typedef /* TLS key types or C11 tss_t */ Py_tss_t; /* Based on C11 threads.h, but destructor doesn't support. the delete value function is maintained for the implementation by CPython self. */ PyAPI_FUNC(int) PyThread_tss_create(Py_tss_t *); PyAPI_FUNC(void) PyThread_tss_delete(Py_tss_t); PyAPI_FUNC(void *) PyThread_tss_get(Py_tss_t); PyAPI_FUNC(int) PyThread_tss_set(Py_tss_t, void *); PyAPI_FUNC(void) PyThread_tss_delete_value(Py_tss_t); -- Added file: http://bugs.python.org/file45548/configure-pthread_key_t.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: On, I got complex type in cloudABI. I see my patch doesn't solve it. https://github.com/NuxiNL/cloudlibc/blob/master/src/include/sys/types.h#L94 https://github.com/NuxiNL/cloudlibc/blob/master/src/include/_/types.h#L209 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: Umm, API seems a design that is passing into function by integer or pointer because the users don't need type detail. I think the implementation of complex type is not realistic. Actually, CouldABI and Cygwin are used pointer, and type detail is hided. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Masayuki Yamamoto added the comment: Hi, I came from #28656. I have read past discussions, And I've understood the pthread_key_t has possible of either integer or pointer. So I think there is a simple solution that replaces key type to intptr_t. Thus I wrote a patch, but it maybe need configure check for intptr_t if CPytyhon still be supporting for before C99 compilers. I confirmed patch on Cygwin x86. Would you be able to confirm for other platforms? -- nosy: +masamoto type: -> compile error versions: +Python 3.7 Added file: http://bugs.python.org/file45427/pythread-key-intptr_t.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28441] Change sys.executable to include executable suffix
Masayuki Yamamoto added the comment: I have missed a case of empty progpath. I updated the patch to avoid calling add_exe_suffix() at that case. -- Added file: http://bugs.python.org/file45327/sys-executable-suffix-2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4032] distutils doesn't search ".dll.a" as library on cygwin
Masayuki Yamamoto added the comment: And updated patch for 2.7 -- Added file: http://bugs.python.org/file45262/2.7-unixccompiler-implib.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4032] distutils doesn't search ".dll.a" as library on cygwin
Masayuki Yamamoto added the comment: Move version to 3.7 and 2.7, and I updated two patches adding import library type for file searching. Current Cygwin is used UnixCCompiler, and the compiler has be able to build extension module that doesn't need to library link at build time (e.g. array). And CygwinCCompiler has supported old version compilers, but its haven't maintained on Current Cygwin any longer. Therefore I think there is no necessary that waits solution to #2445 and #18654. So would you be able to free dependence to #2445, and start to review the patches? Many thanks. -- components: +Build -Windows keywords: +patch nosy: +masamoto title: distutils cannot recognize ".dll.a" as library on cygwin -> distutils doesn't search ".dll.a" as library on cygwin type: -> behavior versions: +Python 3.7 -Python 3.4, Python 3.5 Added file: http://bugs.python.org/file45261/unixccompiler-implib.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28459] _pyio module broken on Cygwin / setmode not usable
Masayuki Yamamoto added the comment: I agree to use setmode() at _pyio module for Cygwin. However, I have two reasons that I disagree to the implementation of os.setmode(). First, FreeBSD has another setmode() that operate file permission bits [1]. Therefore the implementation of os.setmode() will be confused to those users. Second, msvcrt.setmode() isn't used almost in standard library, the function is just used by _pyio module and subprocess test. Thus I think there aren't much need that implements setmode() to os module. Easy way for a solution of import error on Cygwin, setmode() is implemented on _pyio using ctypes. then Cygwin CPython forget setmode(). Otherwise it's hard way, For avoiding confliction to other platforms, I'd propose to create the cygwin module. I thought a solution implementing imitation msvcrt module, but it is unreasonable because Cygwin doesn't have other Windows API. I tried written the patch of easy way that implements setmode() into _pyio. This patch is included parts to succeed import _pyio. [1] https://www.freebsd.org/cgi/man.cgi?query=setmode=3 -- components: +Library (Lib) keywords: +patch nosy: +masamoto versions: +Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45163/cygwin-pyio-setmode.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28480] Compile error on Modules/socketmodule.c
Masayuki Yamamoto added the comment: Oh, that's enough to work, Martin. I confirmed too. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28480] Compile error on Modules/socketmodule.c
New submission from Masayuki Yamamoto: _socket module has failed to compile with --without-threads flag since 554fb699af8c, because Py_END_ALLOW_THREADS macro exists behind the done label ( Modules/socketmodule.c:666 ). If --without-threads flag goes on, Py_END_ALLOW_THREADS macro replaces to just right curly bracket. Therefore, between label and end of block have no statements. There needs meaningless statement (e.g. result = result;) to avoid compile error. I wrote a one line patch as a test. -- components: Build, Extension Modules files: socketmodule-behind-label.patch keywords: patch messages: 279000 nosy: masamoto priority: normal severity: normal status: open title: Compile error on Modules/socketmodule.c type: compile error versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45146/socketmodule-behind-label.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28441] Change sys.executable to include executable suffix
Masayuki Yamamoto added the comment: I agree to add the suffix to solve ambiguous path on Cygwin. And I think the patch should apply to all platforms having executable suffix. Therefore, I modified your patch to remove #if directive for Cygwin, and I changed title to spread covered platforms. This patch uses EXE_SUFFIX that is the EXE defined on Makefile. If platform doesn't have executable suffix, doesn't add anything process. -- components: +Interpreter Core title: sys.executable is ambiguous on Cygwin without .exe suffix -> Change sys.executable to include executable suffix Added file: http://bugs.python.org/file45137/sys-executable-suffix.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28441] sys.executable is ambiguous on Cygwin without .exe suffix
Masayuki Yamamoto added the comment: This patch has impact to end user, thus I don't agree to apply as far as Cygwin to avoid user surprise. I think to need a consistency between other platforms having executable suffix (e.g. MSYS2), and also the patch needs short documentation of changing behavior to description for sys.executable. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28405] Compile error on Modules/_futuresmodule.c
Masayuki Yamamoto added the comment: Thanks, INADA. I confirmed your solution, and has succeeded to build _futures extension. Your patch has a little misspell. I fixed it. -- Added file: http://bugs.python.org/file45046/gc_track-2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28405] Compile error on Modules/_futuresmodule.c
New submission from Masayuki Yamamoto: I tried to build cpython on cygwin (vista x86). Core interpretor has built to success, but '_futures' extension module has failed (compile error on Modules/_futuresmodule.c:946 ). It has occured since f8815001a390 part of build log: $ uname -a CYGWIN_NT-6.0 masayuki-PC 2.6.0(0.304/5/3) 2016-08-31 14:27 i686 Cygwin $ ./configure --without-threads --prefix=/opt/py37 $ LANG=C make (snip) building '_futures' extension gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -I./Include -I/opt/py37/include -I. -I/usr/local/include -I/home/masayuki/var/repos/py37-work01/Include -I/home/masayuki/var/repos/py37-work01 -c /home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.c -o build/temp.cygwin-2.6.0-i686-3.7/home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-2.6.0-i686-3.7/home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.o -L. -L/opt/py37/lib -L/usr/local/lib -L. -lpython3.7m -o build/lib.cygwin-2.6.0-i686-3.7/_futures.dll build/temp.cygwin-2.6.0-i686-3.7/home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.o: In function `new_future_iter': /home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.c:946: undefined reference to `_PyGC_generation0' /home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.c:946: undefined reference to `_PyGC_generation0' /home/masayuki/var/repos/py37-work01/Modules/_futuresmodule.c:946: undefined reference to `_PyGC_generation0' collect2: error: ld returned 1 exit status (snip) -- components: Build, Extension Modules messages: 278418 nosy: bquinlan, masamoto priority: normal severity: normal status: open title: Compile error on Modules/_futuresmodule.c type: compile error versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28405] Compile error on Modules/_futuresmodule.c
Masayuki Yamamoto added the comment: I searched declaration for _PyGC_generation0, And it has be found at Include/objimpl.h:259 The found declaration hasn't used PyAPI_DATA macro. Hence, I wrote a patch to wrap declaration by the macro. I has succeeded to build _futures module using the patch. By the way, I has found similar declarations and defines. I'd like to report them, but Should I create each another issues by places? -- keywords: +patch Added file: http://bugs.python.org/file45043/_PyGC_generation0-declaration.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25720] Fix curses module compilation with ncurses6
Masayuki Yamamoto added the comment: Thank you for confirming, Yen :) In this case, It seems necessary that resolves headers. I think missing headers issue maybe solve by #28190. I wrote a join test patch for #28190 and #25720. Would you be able to resolve headers using this? -- Added file: http://bugs.python.org/file45037/join-test-issue28190-issue25720.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25720] Fix curses module compilation with ncurses6
Masayuki Yamamoto added the comment: Added comment in review. Yen, I tried to build without curses.h file (overwrite to ncurses.h). It was failed on checking header. Hence, I confirmed curses headers on Cygwin and Ubuntu. I found out that curses.h includes the directive "#include ". And unctrl.h has "#include ". Therefore, I think that some platforms require curses.h. Would you confirm your platform curses library? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25720] Fix curses module compilation with ncurses6
Masayuki Yamamoto added the comment: I updated the patch that add configuration check for is_pad. the is_pad is wrapped into py_is_pad at Modules/_cursesmodule.c:932 by either of three ways. Case one -- is_pad is found: Define the macro that is simple wrapping. Case two -- is_pad is not found, however WINDOW has _flags field: Define the macro using _flags field. Case three -- is_pad is not found, and WINDOW doesn't have _flags field: Define the macro that is always preprocessed to FALSE. I succeeded to build curses module on Cygwin (Vista x86) using this patch. This patch doesn't include that undo fixes for specific platforms. -- versions: +Python 3.7 Added file: http://bugs.python.org/file45002/curses-is_pad.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25720] Fix curses module compilation with ncurses6
Masayuki Yamamoto added the comment: I tried to build curses module on Cygwin (Vista x86) using #25720 patch. And it has been succeeded. When test_curses ran without skip condition, it was same result as msg278060 (#28190). I found out build success reasons for cases of applying patch: #25720 -- implementation of WINDOW is opaque (*but* WINDOW_HAS_FLAGS is defined at Include/py_curses.h:61 ). However, curses module build went well to cover the _flags field from source code by is_pad. #14598 -- implementation of WINDOW is not opaque (WINDOWS_HAS_FLAGS is defined at configure script). Therefore, curses module build went well because WINDOW has the _flags field. #28190 -- implementation of WINDOW is opaque (WINDOW_HAS_FLAGS isn't defined: py_curses.h has been cleaned by patch). Hence, curses module build went well to remove the _flags field from source code at preprocessing. All case tests on Cygwin have failed at unget_wch. -- nosy: +masamoto ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28190] Detect curses headers correctly for cross-compiling
Masayuki Yamamoto added the comment: test_curses has been skipped almost. the skip reason has been written "cygwin's curses mostly just hangs" in test case class. I removed the skip condition, and ran test. Tests was almost passed. The only, unget_wch was failed by edge case '\U0010', because the wchar_t size on windows platfrom is two bytes. I'll upload test log together. -- Added file: http://bugs.python.org/file44961/cygwin-test_curses.log ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28190] Detect curses headers correctly for cross-compiling
Masayuki Yamamoto added the comment: Now, Cygwin platform is able to build core interpreter on default branch. But the curses module has been failed to build. Therefore I tried to build curses module on Cygwin (Vista x86) using this patch. And it has been succeeded. The patch effect at build time removes one compiler option "-I/usr/include/ncursesw". Maybe that modification position is setup.py:1352. I couldn't confirm why it has became success. -- nosy: +masamoto ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14438] _cursesmodule build fails on cygwin
Masayuki Yamamoto added the comment: I don't agree with #14438 patch to apply branch. this is quickfix for just Cygwin. I think that curses library should be chosen using configure script. Erik, How about patch for #14598 or #28190? I prefer #28190 because better header is chosen using configure script. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4
Masayuki Yamamoto added the comment: unpack_iterator type has not been registered into _struct module. And all users get only unpack_iterator object from function returning iterator. The object iterating doesn't need reference to type. Therefore, I think issue finish by PyType_Ready fix because this segfault doesn't have big impact. However, I think if possible, it is preferable that extension module having un-initialize type objects gets a compile error at build time. And impossible case for compile error is better that wrong extension module always fails import. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4
Masayuki Yamamoto added the comment: I wrote a patch to add the unpackiter_type initialization into PyInit__struct function. I has confirmed solve #28337 on ubuntu x86 16.04. -- nosy: +masamoto Added file: http://bugs.python.org/file44929/PyType_Ready-unpackiter_type.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28337] Segfault in _struct.unpack_iterator
Masayuki Yamamoto added the comment: I made a mistake that is issue number. The correct issue number is #21124. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28337> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28337] Segfault in _struct.unpack_iterator
New submission from Masayuki Yamamoto:
After #21224 was applied into default branch, the _struct.unpack_iterator has
crashed by segfault.
reproduce segfault:
$ uname -a
Linux masayuki-P35-DS3 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:41:41 UTC
2016 i686 i686 i686 GNU/Linux
$ hg update -C -r "branch(default)"
$ ./configure --prefix=/opt/py35 --without-threads --with-system-ffi
--with-system-expat
$ make
(build succeed)
$ ./python
Python 3.7.0a0 (default:6f299f7d6643, Oct 2 2016, 17:50:08)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> it = struct.iter_unpack('b', b'123')
>>> type(it)
(segfault happens)
--
components: Extension Modules
messages: 277867
nosy: mark.dickinson, masamoto, meador.inge, zach.ware
priority: normal
severity: normal
status: open
title: Segfault in _struct.unpack_iterator
type: crash
versions: Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28337>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27374] Cygwin: Makefile does not install DLL import library
Masayuki Yamamoto added the comment: I don't know why Cygwin packaging script (cygport) doesn't copy direct libpythonX.Ym.dll.a to /usr/lib. Hence I wrote the patch that doesn't conflict with cygport script. In current makefile rule for Cygwin, Install $(LDLIBRARY) into $(LIBPL). Therefore I prefer symlink from $(LIBPL) than copying direct library file to $(LIBDIR). What do you think of makefile rule addition that is same effect (symlink from LIBPL) as cygport script? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27374] Cygwin: Makefile does not install DLL import library
Masayuki Yamamoto added the comment: I found -L option addition at Lib/distutils/command/build_ext.py:222. This place is a process that finalize options for the build_ext command. Comment in there: for extensions under Cygwin and AtheOS Python's library directory must be appended to library_dirs After that I searched Makefile rule for installing $(LDLIBRARY) into "$(prefix)/lib/python3.5/config-3.5m" to look for way of simplifying code. And I came across the $(LIBPL) configuration variable that is used by installation of the configuration for building library. Hence I made a patch that adds to library_dirs the $(LIBPL) configuration variable instead of the "$(prefix)/lib/python$(VERSION)/config". I succeeded to build '_speedups' C extension module of simplejson using new python that is applied this patch. Erik, Would you be able to verify this patch? Thanks Build log: $ patch -p1 <3.5-issue27374-distutils-build_ext.patch $ ./configure --prefix=/opt/py35 --with-threads --with-dbmliborder=gdbm --with-system-ffi --with-system-expat $ make touch && make -j2 && make altinstall $ /opt/py35/bin/python3.5 -V Python 3.5.2+ $ LANG=C /opt/py35/bin/pip3.5 install -v simplejson (snip) running build_ext building 'simplejson._speedups' extension creating build/temp.cygwin-2.6.0-i686-3.5 creating build/temp.cygwin-2.6.0-i686-3.5/simplejson gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/opt/py35/include/python3.5m -c simplejson/_speedups.c -o build/temp.cygwin-2.6.0-i686-3.5/simplejson/_speedups.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-2.6.0-i686-3.5/simplejson/_speedups.o -L/opt/py35/lib/python3.5/config-3.5m -L/opt/py35/lib -lpython3.5m -o build/lib.cygwin-2.6.0-i686-3.5/simplejson/_speedups.cpython-35m.dll running install_lib (snip) -- Added file: http://bugs.python.org/file44685/3.5-issue27374-distutils-build_ext.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27374] Cygwin: Makefile does not install DLL import library
Masayuki Yamamoto added the comment: I'm so sorry that I misspelled your name, Erik. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27374] Cygwin: Makefile does not install DLL import library
Masayuki Yamamoto added the comment: Hello, Eric. I tried to build the '_speedups' C extension module of simplejson (third party library) using the python built on cygwin. As you pointed out, the build of '_speedups' C extension module at the stage of the link failed. build log: Python3.5.2+ has be used. It has applyed patches to known issues. $ ./configure --prefix=/opt/py35 --with-threads --with-dbmliborder=gdbm --with-system-ffi --with-system-expat $ make && make altinstall $ LANG=C /opt/py35/bin/pip3.5 install simplejson (snip) running build_ext building 'simplejson._speedups' extension creating build/temp.cygwin-2.6.0-i686-3.5 creating build/temp.cygwin-2.6.0-i686-3.5/simplejson gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/opt/py35/include/python3.5m -c simplejson/_speedups.c -o build/temp.cygwin-2.6.0-i686-3.5/simplejson/_speedups.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-2.6.0-i686-3.5/simplejson/_speedups.o -L/opt/py35/lib/python3.5/config -L/opt/py35/lib -lpython3.5m -o build/lib.cygwin-2.6.0-i686-3.5/simplejson/_speedups.cpython-35m.dll /usr/lib/gcc/i686-pc-cygwin/5.4.0/../../../../i686-pc-cygwin/bin/ld: cannot find -lpython3.5m collect2: error: ld returned 1 exit status *** WARNING: The C extension could not be compiled, speedups are not enabled. Failure information, if any, is above. I'm retrying the build without the C extension now. *** (snip) In the log, -L option specified to "/opt/py35/lib/python3.5/config". But, the current python has "/opt/py35/lib/python3.5/config-3.5m" instead of "/opt/py35/lib/python3.5/config". And libpython3.5m.dll.a library exists in the config-3.5m. I think that to succeed building a C extension module if -L options is changed to "/opt/py35/lib/python3.5/config-3.5m". I'm going to try to find the place that add -L option at build time. -- components: +Extension Modules nosy: +masamoto versions: +Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21085] compile error Python3.3 on Cygwin
Masayuki Yamamoto added the comment: Oh, I made a mistake that is checking the si_band field without signal header. Here is a modified patch adding signal header at checking the si_band field. I passed tests compiling cpython 3.5.2+ on ubuntu 16.04.1 (x86) using this patch. -- Added file: http://bugs.python.org/file44208/3.5-issue21085-struct_siginfo-2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21085] compile error Python3.3 on Cygwin
Masayuki Yamamoto added the comment: Hello, I'm writer for past patch. 3.4-issue21085-struct_siginfo.patch removes si_band field from struct_siginfo if the C siginfo_t doesn't have si_band field. This modification raises a incompatibility between platforms having struct_siginfo. Now, I wrote another patch that doesn't change fields of struct_siginfo to avoid its incompatibility. And I built cpython 3.5.2+ on vista cygwin-x86 using this patch. Murray, would you be able to tell me your idea? Many thanks. New patch changes: If platform has the C siginfo_t structure, but it doesn't have si_band field, the struct_siginfo.si_band field is always assigned zero at function return value. -- Added file: http://bugs.python.org/file44204/3.5-issue21085-struct_siginfo.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24058] Compiler warning for readline extension
Masayuki Yamamoto added the comment: I tried another two case changing variable declaration. First case of just removing extern, Compiler similarly warns, and test passed. Second case of removing _PyOS_ReadlineTState declaration, Compiler has not warned, and test passed. First: $ hg diff diff -r a50707a73d84 Modules/readline.c --- a/Modules/readline.cWed Nov 05 15:11:34 2014 +0100 +++ b/Modules/readline.cMon Apr 27 03:09:06 2015 +0900 @@ -1062,7 +1062,7 @@ rl_callback_handler_remove(); } -extern PyThreadState* _PyOS_ReadlineTState; +PyThreadState* _PyOS_ReadlineTState; static char * readline_until_enter_or_signal(const char *prompt, int *signal) $ ./configure --prefix=/opt/py34 make ... building 'readline' extension ... /cygdrive/d/cyghome/masayuki/src/CPython-3.4/Modules/readline.c:1065:16: warning: '_PyOS_ReadlineTState' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] PyThreadState* _PyOS_ReadlineTState; ^ ... $ make install $ /opt/py34/bin/python3.4m.exe -E -Wd -mtest -v test_readline == CPython 3.4.3+ (3.4:a50707a73d84+, Apr 27 2015, 02:59:04) [GCC 4.9.2] == CYGWIN_NT-6.0-1.7.35-0.287-5-3-i686-32bit-WindowsPE little-endian == hash algorithm: siphash24 32bit == /tmp/test_python_3872 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_readline testHistoryUpdates (test.test_readline.TestHistoryManipulation) ... ok test_init (test.test_readline.TestReadline) ... ok -- Ran 2 tests in 0.203s OK 1 test OK. Second: $ hg diff diff -r a50707a73d84 Modules/readline.c --- a/Modules/readline.cWed Nov 05 15:11:34 2014 +0100 +++ b/Modules/readline.cMon Apr 27 04:13:45 2015 +0900 @@ -1062,7 +1062,6 @@ rl_callback_handler_remove(); } -extern PyThreadState* _PyOS_ReadlineTState; static char * readline_until_enter_or_signal(const char *prompt, int *signal) $ ./configure --prefix=/opt/py34 make ... building 'readline' extension has not warned. $ make install $ /opt/py34/bin/python3.4m.exe -E -Wd -mtest -v test_readline == CPython 3.4.3+ (3.4:a50707a73d84+, Apr 27 2015, 04:19:36) [GCC 4.9.2] == CYGWIN_NT-6.0-1.7.35-0.287-5-3-i686-32bit-WindowsPE little-endian == hash algorithm: siphash24 32bit == /tmp/test_python_5936 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_readline testHistoryUpdates (test.test_readline.TestHistoryManipulation) ... ok test_init (test.test_readline.TestReadline) ... ok -- Ran 2 tests in 0.160s OK 1 test OK. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24058 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24058] Compiler warning for readline extension
Masayuki Yamamoto added the comment: um, Compiler warned, but test passed. It seems a only warning. build log: $ ./configure --prefix=/opt/py34 $ make ... building 'readline' extension gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I/opt/py34/include -I. -IInclude -I/usr/local/include -I/home/masayuki/src/CPython-3.4/Include -I/home/masayuki/src/CPython-3.4 -c /cygdrive/d/cyghome/masayuki/src/CPython-3.4/Modules/readline.c -o build/temp.cygwin-1.7.35-i686-3.4/cygdrive/d/cyghome/masayuki/src/CPython-3.4/Modules/readline.o /cygdrive/d/cyghome/masayuki/src/CPython-3.4/Modules/readline.c:1065:23: warning: '_PyOS_ReadlineTState' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] extern PyThreadState* _PyOS_ReadlineTState; ^ ... test log: $ /opt/py34/bin/python3.4m.exe -E -Wd -mtest -v test_readline == CPython 3.4.3+ (3.4:ce2b9f160391+, Apr 25 2015, 20:45:32) [GCC 4.9.2] == CYGWIN_NT-6.0-1.7.35-0.287-5-3-i686-32bit-WindowsPE little-endian == hash algorithm: siphash24 32bit == /tmp/test_python_2660 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_readline testHistoryUpdates (test.test_readline.TestHistoryManipulation) ... ok test_init (test.test_readline.TestReadline) ... ok -- Ran 2 tests in 0.199s OK 1 test OK. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24058 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24058] Compiler warning for readline extension
New submission from Masayuki Yamamoto: Compiler warns case of define HAVE_DECLSPEC_DLL. In Modules/readline.c:1065, _PyOS_ReadlineTState variable declaration is different to Include/pythonrun.h:275. -- components: Build, Extension Modules hgrepos: 307 messages: 242013 nosy: masamoto priority: normal severity: normal status: open title: Compiler warning for readline extension type: compile error versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24058 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24058] Compiler warning for readline extension
Masayuki Yamamoto added the comment: Here is a patch modifying variable declaration to same as Include/pytonrun.h. -- keywords: +patch Added file: http://bugs.python.org/file39205/3.4-issue24058-readline-_PyOS_ReadlineTState.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24058 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24034] Make fails Objects/typeslots.inc
Masayuki Yamamoto added the comment: I wrote the patch to replace $(PYTHON). Changes: Add TYPESLOTSGEN to configure.ac. TYPESLOTSGEN values is the built-in python. If the built-in python is not found, TYPESLOTSGEN echoes message that is skipping like ASDLGEN. Generated the configure script using autoreconf. Modify Makefile.pre.in to replace $(PYTHON) to $(TYPESLOTSGEN). And remove $(PYTHON) that isn't used anywhere. It seems already needless. Although I understand that the generated file touch can avoid to fail regenerate, I want to check built-in python to generate safer the Objects/typeslots.inc. -- keywords: +patch Added file: http://bugs.python.org/file39178/3.4-issue24034-make-fails-typeslots.inc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24034 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24034] Make fails Objects/typeslots.inc
New submission from Masayuki Yamamoto: Objects/typeslots.inc is broken, and make stop on cygwin-1.7.35-i686. If built-in python is not found in make processing, Objects/typeslots.inc generating will fail. Because Objects/typeslots.inc is generated using $(PYTHON) in Makefile, but $(PYTHON) variable is a hard-coding value that isn't check a built-in python existent. make steps to fail and error message: $ ./configure --prefix=/opt/py34 $ touch Include/typeslots.h $ make ... python.exe ./Objects/typeslots.py ./Include/typeslots.h Objects/typeslots.inc /bin/sh: python.exe: command not found Makefile:851: recipe for target 'Objects/typeslots.inc' failed make: *** [Objects/typeslots.inc] Error 127 Cygwin python executable files: $ find /usr/bin/ -name 'python*.exe' /usr/bin/python2.7.exe /usr/bin/python3.2m.exe -- components: Build, Interpreter Core messages: 241843 nosy: masamoto priority: normal severity: normal status: open title: Make fails Objects/typeslots.inc type: compile error versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24034 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8548] Building on CygWin 1.7: PATH_MAX redefined
Masayuki Yamamoto added the comment: This issue resolved on default branch in #20597 . In 3.4 branch latest, PATH_MAX seems unused already in Modules/main.c:12 and Python/pythonrun.c:35. I want to cherry-pick #20597 to 3.4 branch. -- nosy: +masamoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8548 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2445] Use The CygwinCCompiler Under Cygwin
Masayuki Yamamoto added the comment: CygwinCCompiler seems legacy code. In v3.4 latest rivision, Distutils has made to work that is a patching to UnixCCompiler. So, I have a think that doesn't need to use CygwinCCompiler to build on Cygwin. I have upload a patch for UnixCCompiler. The patch has modified from http://cygwin.org package. Other big issues and patches for build on Cygwin: #21085, #13756 -- compile error #14598, #21124 -- C extension module -- nosy: +masamoto Added file: http://bugs.python.org/file39141/3.4-distutils-shlibext.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2445 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14438] _cursesmodule build fails on cygwin
Changes by Masayuki Yamamoto light2happy@gmail.com: -- nosy: +masamoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14438 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13756] Python3.2.2 make fail on cygwin
Changes by Masayuki Yamamoto light2happy@gmail.com: -- nosy: +masamoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13756 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14598] _cursesmodule.c fails with ncurses-5.9 on Linux
Masayuki Yamamoto added the comment: I rewrote the patch for Python 3.4. The configure and pyconfig.h.in were generated by autoreconf. If evaluate to the curses WINDOW doesn't have the _flags member, The configure script defines related macros and checks the member again. And removed the quick-fix on py_curses header. The quick-fix wouldn't be needed. My environment (Cygwin 1.7.35 i686) cannot check the build case that NCURSES_OPAQUE is defined zero. -- nosy: +masamoto versions: +Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39085/3.4-issue14598-curses-WINDOW_flags.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14598 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23338] PyErr_Format in ctypes uses invalid parameter
Changes by Masayuki Yamamoto light2happy@gmail.com: -- nosy: +masamoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23338 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21085] compile error Python3.3 on Cygwin
Masayuki Yamamoto added the comment: New patch uses configure script to set the compile condition for struct_siginfo.si_band. The script was generated from configure.ac using autoreconf. Could you make sure of having the si_band in another platform? -- Added file: http://bugs.python.org/file38752/3.4-issue21085-struct_siginfo.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23663] Crash on failure in ctypes on Cygwin
Masayuki Yamamoto added the comment: similar issue #23338: PyErr_Format in ctypes uses invalid parameter -- nosy: +masamoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23663 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21085] compile error Python3.3 on Cygwin
Masayuki Yamamoto added the comment: Victor, In that case, May I edit configure script to generate the HAVE_* defines? I'd like to add a statement to check the si_band to configure.ac. And please generate patches not the git format. Otherwise, Rietveld is unable to generated the review link. I see. I use the mercurial repository from next time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21085] compile error Python3.3 on Cygwin
Masayuki Yamamoto added the comment:
I wrote improved patch to remove the 'si_band'. This patch modifies the
'n_in_sequence' to conform to the number of structure members.
And I tested manually for struct_siginfo. struct_siginfo objects builds well.
That's all for now.
$ python3.4.exe
Python 3.4.3 (default, Mar 2 2015, 22:23:56)
[GCC 4.9.2] on cygwin
Type help, copyright, credits or license for more information.
import signal
signal.struct_siginfo([1, 2, 3, 4, 5, 6])
signal.struct_siginfo(si_signo=1, si_code=2, si_errno=3, si_pid=4, si_uid=5,
si_status=6)
signal.sigwaitinfo({signal.SIGINT})
^C
signal.struct_siginfo(si_signo=2, si_code=6, si_errno=0, si_pid=3352,
si_uid=1000, si_status=0)
signal.alarm(1); signal.sigwaitinfo({signal.SIGALRM})
0
signal.struct_siginfo(si_signo=14, si_code=4, si_errno=0, si_pid=5816,
si_uid=1000, si_status=1629189728)
--
nosy: +masamoto
type: - compile error
versions: +Python 3.5
Added file:
http://bugs.python.org/file38704/3.4-issue21085-cygwin-struct_siginfo.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21085
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21088] curses addch() argument position reverses in Python3.4.0
Changes by Masayuki Yamamoto light2happy@gmail.com: -- nosy: -masamoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4
Masayuki Yamamoto added the comment: I have solved about compiling _struct module too. I have no authority of this issues, So please close of issues. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21124 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4
Changes by Masayuki Yamamoto light2happy@gmail.com: -- nosy: -masamoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21124 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4
Masayuki Yamamoto added the comment: I wrote a patch file. In other extention module source codes, global variable PyTypeObject has initialized to using PyVarObject_HEAD_INIT(NULL, 0). And so, as with other modules, I tried to edit and compiling _struct.c in Cygwin 1.7.28. The module compiling was passing, And struct module passed a test python3.4 -m test test_struct. -- keywords: +patch nosy: +masamoto Added file: http://bugs.python.org/file34701/3.4-struct.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21124 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21088] curses addch() argument position reverses in Python3.4.0
New submission from Masayuki Yamamoto: There is a test code that is RB characters display on screen. I expected displaying R to right, and displaying B to bottom. It was run as expected in Python 2.7.3 and 3.2.3 on Cygwin. But they were displayed reverse in Python 3.4.0. And when addch() arguments reversed, they were displayed in expected positions. import curses def test(stdscr): stdscr.addch(0, 5, b'R') stdscr.addch(5, 0, b'B') stdscr.refresh() stdscr.getch() curses.wrapper(test) Please make sure of issues, and fix it. Thanks. -- components: Library (Lib) messages: 215074 nosy: masamoto priority: normal severity: normal status: open title: curses addch() argument position reverses in Python3.4.0 type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
