[issue45537] Cygwin is unsupported - close all open issues and list them here.

Change by Erik Bray : -- pull_requests: +27359 pull_request: https://github.com/python/cpython/pull/4149 ___ Python tracker <https://bugs.python.org/issue45

[issue45537] Cygwin is unsupported - close all open issues and list them here.

Change by Erik Bray : -- keywords: +patch nosy: +erik.bray nosy_count: 1.0 -> 2.0 pull_requests: +27357 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14013 ___ Python tracker <https://bugs.python.org/i

[issue31882] Cygwin: asyncio and asyncore test suites hang indefinitely due to bug in Cygwin

Erik Bray added the comment: To my knowledge this issue is *not* fixed upstream. However, my PR no doubt needs rebasing. -- ___ Python tracker <https://bugs.python.org/issue31

[issue31885] Cygwin: socket test suites hang indefinitely due to bug in Cygwin

Erik Bray added the comment: That person was me--I have the keys to a cygwin buildbot, but it's currently not running. I lost the urgency to make cygwin fully supported, though it's come a long way. In particular the deprecation of distutils should help nix some of the long-standing

[issue31885] Cygwin: socket test suites hang indefinitely due to bug in Cygwin

Erik Bray added the comment: Thanks for asking. Indeed the fix to that issue was included in https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=5ca28a0cd71436a84797d5d66831790004e0 and as Cygwin obsoletes old releases rather quickly I see no reason to keep this issue open

[issue31878] Cygwin: _socket module does not compile due to missing ioctl declaration

Change by Erik Bray : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue39671] Mention in docs that asyncio.FIRST_COMPLETED does not guarantee the completion of no more than one task

Change by Erik Bray : -- keywords: +patch nosy: +erik.bray nosy_count: 4.0 -> 5.0 pull_requests: +21125 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21918 ___ Python tracker <https://bugs.python.org/i

[issue18876] Problems with files opened in append mode with io module

Erik Bray added the comment: Indeed, this can be closed. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue20082] Misbehavior of BufferedRandom.write with raw file in append mode

Change by Erik Bray : -- pull_requests: +20873 pull_request: https://github.com/python/cpython/pull/21729 ___ Python tracker <https://bugs.python.org/issue20

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Erik Bray added the comment: FWIW (unsurprisingly) the new test added here is broken on Cygwin, whose libc's (newlib) behavior in this undefined case. So I get: >>> from datetime import date >>> t = date(2005, 1, 1) >>> t.strftime("%Y") #

[issue28459] _pyio module broken on Cygwin / setmode not usable

Change by Erik Bray : -- pull_requests: +13877 pull_request: https://github.com/python/cpython/pull/14013 ___ Python tracker <https://bugs.python.org/issue28

[issue9665] Buid issues on Cygwin - _curses, _curses_panel, and _io

Erik Bray added the comment: I think this issue can probably be closed. It refers to a very old version of Cygwin as well as old versions of Python. I don't have any problem building the _curses or _io modules on recent versions of Cygwin (>=2.9) and with current cpython master (3.9.

[issue21536] extension built with a shared python cannot be loaded with a static python

Erik Bray added the comment: Thanks everyone. And FWIW I agree the original change is positive overall, if a bit presumptuous about different linkers' behaviors :) -- ___ Python tracker <https://bugs.python.org/issue21

[issue21536] extension built with a shared python cannot be loaded with a static python

Change by Erik Bray : -- pull_requests: +13463 ___ Python tracker <https://bugs.python.org/issue21536> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21536] extension built with a shared python cannot be loaded with a static python

Change by Erik Bray : -- pull_requests: +13461 ___ Python tracker <https://bugs.python.org/issue21536> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21536] extension built with a shared python cannot be loaded with a static python

Erik Bray added the comment: I vaguely recall seeing some discussion about this on python-dev or elsewhere and wish I had chimed in sooner, as I didn't realize action was going to be taken on this so soon. This completely breaks building extension modules on Windows-based platforms like

[issue32451] python -m venv activation issue when using cygwin on windows

Erik Bray added the comment: Coincidentally I just encountered this myself when trying to activate a venv created by Python for Windows while in a Cygwin shell. Indeed, bash for Cygwin is just like bash anywhere else, and considers it a syntax error to encounter unexpected CR's. Alas

[issue36231] no "proper" header files on macOS 10.14 Mojave

Erik Bray added the comment: Perhaps it would be better if the `xcrun --show-sdk-path` thing were run at configure-time and its result shoved into a variable we can read with sysconfig.get_config_var() -- nosy: +erik.bray ___ Python tracker

[issue34904] Crash in ZipFile.close() when writing zip file to /dev/null

Erik Bray added the comment: For the sake of completeness, same deal in pure C: $ cat devnul.c #include int main(void) { FILE *f = fopen("/dev/null", "w"); printf("tell() = %ld\n", ftell(f)); printf("write(\"abcdefgh\") = %zu\n&quo

[issue34904] Crash in ZipFile.close() when writing zip file to /dev/null

Erik Bray added the comment: On Cygwin the same tests give >>> f = open('/dev/null', 'wb') >>> f.seekable() True >>> f.write(b'abcdefgh') 8 >>> f.tell() 8 >>> f.seek(8) 8 >>> f.tell() 8 I would also try ma

[issue34904] Crash in ZipFile.close() when writing zip file to /dev/null

Erik Bray added the comment: The regression was introduced by issue26039. It does seem to be Linux-specific with seek/tell on /dev/null. For example, I cannot reproduce the issue on Cygwin. -- ___ Python tracker <https://bugs.python.

[issue34904] Crash in ZipFile.close() when writing zip file to /dev/null

New submission from Erik Bray : Not that there is any great reason to write a zip file to /dev/null, but I had some code that happened to do so which worked on Python 2.7, but at some point this broke: Python 3.8.0a0 (heads/master:fc7d1b3, Oct 5 2018, 09:49:57) [GCC 4.8.4] on linux Type

[issue34212] Cygwin link failure with builtin modules since issue30860

Erik Bray added the comment: I added a new PR modifying makesetup and adding a new variable to Makefile.pre.in, PY_BUILTIN_MODULE_CFLAGS, explicitly for building built-in modules. I think this, or some version of it, is a cleaner solution than my previous brute-force approach

[issue34212] Cygwin link failure with builtin modules since issue30860

Change by Erik Bray : -- pull_requests: +8199 ___ Python tracker <https://bugs.python.org/issue34212> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32797] Tracebacks from Cython modules no longer work

Erik Bray added the comment: > To do that, I believe it can be made to work in much the same way it did in > Python 2 if SageMath were to do the following: > > 1. Define a subclass of ExtensionModuleLoader [1] that overrides get_source() > to also look for a "

[issue32797] Tracebacks from Cython modules no longer work

Erik Bray added the comment: To add, while an enhancement just to linecache would make sense in its own right, I don't see the problem with also extending the Loader.get_source() API to be more useful as well. Its current behavior is to just return a string (or None), but it seems to me

[issue32797] Tracebacks from Cython modules no longer work

Erik Bray added the comment: Brett: > As Nick said, we have no generalized concept of source maps and I think coming up with that is what will be required to solve this as i personally don't view Loader.get_source() is not meant to be a generalized concept of some form of source c

[issue34211] Cygwin build broken due to use of _Type in static declaration in _abc module

Erik Bray added the comment: > What makes functions different from variables? Aren't they essentially just > pointers? You're on the right track by noting a difference between functions and data variables. I can tell you off the bat that when it comes to data imported from DLL

[issue34211] Cygwin build broken due to use of _Type in static declaration in _abc module

Erik Bray added the comment: > For those who are not very aware of Cygwin issues: what is wrong with > > PyVarObject_HEAD_INIT(_Type, 0); I'm glad you asked, because it actually got me thinking, and since I added a fix (albeit an unsatisfying one) for issue34212, this fix is

[issue34212] Cygwin link failure with builtin modules since issue30860

Change by Erik Bray : -- keywords: +patch pull_requests: +7968 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34212> ___ ___ Python-

[issue34212] Cygwin link failure with builtin modules since issue30860

New submission from Erik Bray : Since issue30860, libpython is no longer able to be linked as a shared library, because built-in modules are not compiled with the correct external linkage flags. This is due to the removal of -DPy_BUILD_CORE, which in pyport.h is used to control wither

[issue34211] Cygwin build broken due to use of _Type in static declaration in _abc module

Change by Erik Bray : -- keywords: +patch pull_requests: +7967 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue34211> ___ _

[issue34211] Cygwin build broken due to use of _Type in static declaration in _abc module

New submission from Erik Bray : This is essentially the same as issue21124, but introduced more recently with the addition of the _abc_data_type in the _abc module. The workaround is simply to use PyVarObject_HEAD_INIT(NULL, 0) instead of PyVarObject_HEAD_INIT(_Type, 0); PyType_Ready should

[issue31882] Cygwin: asyncio and asyncore test suites hang indefinitely due to bug in Cygwin

Erik Bray added the comment: I originally opened this in https://bugs.python.org/issue29253 but then made a dupe of my own bug! Anyways, there's a (nearly year old) pull request for it now. -- ___ Python tracker <https://bugs.python.

[issue29253] Fix test_asyncore tests on Cygwin

Erik Bray added the comment: Yes, it's a dupe. There was enough time after I later made the PR for this that I forgot I already opened an issue for it. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed _

[issue29672] `catch_warnings` context manager causes all warnings to be printed every time, even after exiting

Erik Bray added the comment: Yes, I think `catch_warnings` should back up and restore the relevant `__warningregistry__`. At which point it's not even clear to me what value there is in the _filter_version... -- ___ Python tracker <ht

[issue29672] `catch_warnings` context manager causes all warnings to be printed every time, even after exiting

Erik Bray added the comment: I just encountered this as well. The way catch_warnings is implemented is a bit "dumb" in how it treats _filter_version (it calls _filters_mutated even if the active filters are not actually changed when entering catch_warnings). More sig

[issue33939] Provide a robust O(1) mechanism to check for infinite iterators

Erik Bray added the comment: > Thinking about the generator-iterator case a bit more, "False" would be a bad > default for that. Allowing "NotImplemented" to indicate the ambiguous "Might > be finite, might be infinite" state, and using that as the de

[issue33939] Raise TypeError in __length_hint__ for consistently infinite iterators

Erik Bray added the comment: Per the discussion in https://trac.sagemath.org/ticket/24757, it would also be nice if some other common iterables like map and filter implemented a similar __length_hint__ which would interrogate whatever iterables were give as their argument(s). To summarize

[issue32797] Tracebacks from Cython modules no longer work

Erik Bray <erik.m.b...@gmail.com> added the comment: +1, that seems obvious to me like better behavior. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue20082] Misbehavior of BufferedRandom.write with raw file in append mode

Erik Bray <erik.m.b...@gmail.com> added the comment: I keep forgetting about this (given that it's like 5 years old now). Let me see if I can make a new PR for it... -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit

Erik Bray <erik.m.b...@gmail.com> added the comment: This has a backport PR now for 3.6. Once that PR is merged I think we can close this as fixed. -- stage: patch review -> backport needed versions: +Python 3.6 ___ Python tra

[issue32797] Tracebacks from Cython modules no longer work

Erik Bray <erik.m.b...@gmail.com> added the comment: On Feb 8, 2018 12:55, "Jeroen Demeyer" <rep...@bugs.python.org> wrote: New submission from Jeroen Demeyer <jdeme...@cage.ugent.be>: Displaying the source code in tracebacks for Cython-compiled extension modules in

[issue30537] Using PyNumber_AsSsize_t in itertools.islice

Erik Bray <erik.m.b...@gmail.com> added the comment: > Users might be better off by not seeing an unhelpful error message when > passing in a numpy.int32, or they might be worse-off by having lost a cue > that they were writing inefficient code (which invisibly creates tempo

[issue32438] PyLong_ API cleanup

New submission from Erik Bray <erik.m.b...@gmail.com>: Per Serhiy's comment in this thread https://mail.python.org/pipermail/python-ideas/2017-December/048413.html (which I agree with), several of the PyLong_ functions have behavior carried over from Python 2 of calling _

[issue23428] Use the monotonic clock for thread conditions on POSIX platforms

Change by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +4856 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue32243] Tests that set aggressive switch interval hang in Cygwin on a VM

Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4855 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue28459] _pyio module broken on Cygwin / setmode not usable

Erik Bray <erik.m.b...@gmail.com> added the comment: Right, the current patch is really combining several issues. I'll make a PR from it that just fixes the _pyio issue. I'll also open an issue for fixing the ctypes bug (this is a patch I've had in my cygwin branch for ages but just

[issue32287] Import of _pyio module failed on cygwin

Erik Bray <erik.m.b...@gmail.com> added the comment: Indeed, this is a duplicate of #28459. I'll also update the existing patch to a pull request. -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed ___

[issue32243] Tests that set aggressive switch interval hang in Cygwin on a VM

New submission from Erik Bray <erik.m.b...@gmail.com>: This is basically the same as #26939, but rather than Android running in an emulator it is affecting Cygwin running in a slow VM (in this case it's on my university's OpenStack infrastructure--I don't know what hypervisor they're

[issue32082] atexit module: allow getting/setting list of handlers directly

New submission from Erik Bray <erik.m.b...@gmail.com>: In Python 2 it was possible to directly manipulate the list of registered atexit handlers through atexit._exithandlers. Obviously I'm not complaining that this went away, as it was an underscored attribute. But this possi

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Erik Bray <erik.m.b...@gmail.com> added the comment: In my PR there's a behavior test for the default, so we don't have to hard-code that on a per-platform basis at least. The C != POSIX thing I'm not sure you can easily test for. -- ___

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Erik Bray <erik.m.b...@gmail.com> added the comment: Yes, I looked at some of the other issues pertaining to this, but it wasn't immediately apparent how to kill multiple birds with one stone, so here I just focused on this one assu

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4316 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

New submission from Erik Bray <erik.m.b...@gmail.com>: Several of the tests in test_c_locale_coercion (particularly LocaleCoercionTests._check_c_locale_coercion) tend to assume that the system default locale used when setting setlocale(category, "") and when all the rele

[issue28441] Change sys.executable to include executable suffix

Change by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +4305 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28441> ___ _

[issue31883] Cygwin: heap corruption bug in wcsxfrm

Erik Bray <erik.m.b...@gmail.com> added the comment: Well, we'll see how long it takes me to get them to respond on that. If it's not too much trouble then I'll be happy to drop this issue. -- ___ Python tracker <rep...@bugs.python.or

[issue31883] Cygwin: heap corruption bug in wcsxfrm

Erik Bray <erik.m.b...@gmail.com> added the comment: Well, I agree there's an unfortunate trade-off here: One can skip the test, allowing the test suite to work on slightly older versions of Cygwin, from before this issue was fixed. However, I then lose regression testing on newer ve

[issue31883] Cygwin: heap corruption bug in wcsxfrm

Erik Bray <erik.m.b...@gmail.com> added the comment: To be clear, are you saying there shouldn't be a workaround to the underlying issue (I agree), or are you saying the test skip shouldn't even be added? I'm in favor of just skipping the test since it's still a problem on (currently)

[issue4032] distutils doesn't search ".dll.a" as library on cygwin

Change by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +4120 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.py

[issue31885] Cygwin: socket test suites hang indefinitely due to bug in Cygwin

Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4119 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue31885] Cygwin: socket test suites hang indefinitely due to bug in Cygwin

New submission from Erik Bray <erik.m.b...@gmail.com>: Like issue31882, this is to mention an upstream bug in Cygwin that causes one of the tests in the test_socket test suite to hang indefinitely. That bug is fixed upstream [1], but for now it would still be better to skip th

[issue31883] Cygwin: heap corruption bug in wcsxfrm

Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4116 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue31883] Cygwin: heap corruption bug in wcsxfrm

New submission from Erik Bray <erik.m.b...@gmail.com>: There is an acknowledged bug in Cygwin's implementation of wcsxfrm() [1] that can cause heap corruption in certain cases. This bug has since been fixed in Cygwin 2.8.1-1 [2] and all current and future releases. H

[issue31882] Cygwin: asyncio and asyncore test suites hang indefinitely due to bug in Cygwin

Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4115 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue31882] Cygwin: asyncio and asyncore test suites hang indefinitely due to bug in Cygwin

New submission from Erik Bray <erik.m.b...@gmail.com>: Some of the tests for asyncio and asyncore block forever on Cygwin, due to a known (and seemingly difficult to fix) bug [1] in Cygwin involving SO_PEERCRED on UNIX sockets. SO_PEERCRED is a socket option that can be used to exchang

[issue16135] Removal of OS/2 support

Change by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +4113 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue16135> ___ _

[issue16135] Removal of OS/2 support

Change by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +4102 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue16135> ___ _

[issue31828] Support Py_tss_NEEDS_INIT outside of static initialisation

Change by Erik Bray <erik.m.b...@gmail.com>: -- nosy: +erik.bray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31828> ___ __

[issue31878] Cygwin: _socket module does not compile due to missing ioctl declaration

Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4100 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue31878] Cygwin: _socket module does not compile due to missing ioctl declaration

New submission from Erik Bray <erik.m.b...@gmail.com>: On Cygwin, ioctl() is found in sys/ioctl.h (as on Darwin). Without adding something to the effect of #ifdef __CYGWIN__ # include #endif the _socket module cannot compile on Cygwin. A fix was this was included in the (rejected)

[issue2445] Use The CygwinCCompiler Under Cygwin

Change by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +4099 stage: commit review -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.py

[issue31877] Build fails on Cython since issue28180

Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4097 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue31877] Build fails on Cython since issue28180

New submission from Erik Bray <erik.m.b...@gmail.com>: I'm trying once again to get the test suite up to snuff on Cygwin so I can start running a buildbot (particularly now that PEP 539 is done). However, as of issue28180 the build fails with: gcc-o python.exe Programs/py

[issue24766] Subclass of property doesn't preserve instance __doc__ when using doc= argument

Changes by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +2546 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24766> ___ _

[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like

Erik Bray added the comment: Actually I just finished reading njs's blog post, and as he points out that special case for SETUP_FINALLY is basically broken. There are other cases where it doesn't really work either. For example if you have: if ...: do_something() else

[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like

Erik Bray added the comment: >> Or we could steal a bit in the opcode encoding or something. > That seems like a very reasonable and easy-to-implement solution. It > would > generalize this check: > https://github.com/python/cpython/blob/e82cf8675bacd7a03de508ed11865

[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit

Erik Bray added the comment: Thanks for checking! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30353> ___ ___ Python-bugs-list

[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit

Erik Bray added the comment: Iryna, I updated the pull request with a slightly updated fix. Could you confirm again, when you get a chance, that it works for arm64? Thanks. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.p

[issue29804] test_ctypes test_pass_by_value fails on arm64 (aarch64) architecture

Changes by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +1760 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29804> ___ _

[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit

Erik Bray added the comment: Sure, thanks for pointing that out. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30353> ___ ___

[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit

Erik Bray added the comment: Thanks for pointing that out. Indeed it's the same symptom, but slightly different cause. libffi has different implementations of its calling routines for different architectures/platforms depending on the machine architecture and calling conventions used. So

[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit

Changes by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +1656 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30353> ___ _

[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit

New submission from Erik Bray: The test ctypes.test.test_structures.StructureTestCase.test_pass_by_value fails on 64-bit Cygwin and MinGW using the system libffi with: == FAIL: test_pass_by_value

[issue29718] Fixed compile on cygwin.

Erik Bray added the comment: This seems to be fixing a number of different Cygwin issues, many of which are known (some of these patches come from the Cygwin port of Python). However, some of these issues are already being handled separately, such as #25658, and I think rather than one big

[issue21085] Cygwin does not provide siginfo_t.si_band

Erik Bray added the comment: Decorater, since this issue was already closed, could you open a new one? And when you do, please add me to the nosy list. I'm still planning to get a Cygwin built bot up for Python, I've just had other various priorities

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

Erik Bray added the comment: Thanks Masayuki for the updated patch, and especially for the additional test cases. Looking at the patch, it occurs to me that this solution seems to be the minimal needed to fix the issue that we were originally trying to fix, without adding too much additional

[issue29253] Fix test_asyncore tests on Cygwin

New submission from Erik Bray: This patch works around a couple different problems with running the test_asyncore tests in Cygwin, both of which are due to bugs in Cygwin itself and not in Python. As such, I don't think Python should try to work around these issues in general, but I do think

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

Erik Bray added the comment: I'm still pretty happy with the previous patch, personally, since I don't need the tracemalloc module. But it seems like that should be fixed (or if nothing else that code in _tracemalloc.c should check Py_HAVE_NATIVE_TLS too). I like the idea of the new

[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

Erik Bray added the comment: To me, Masayuki's patch is an acceptable work-around for the time being. I don't *like* it because the fact remains that native TLS can work on these platforms and falling back on Python's slower implementation isn't necessary. That said, the previous patch

[issue28441] Change sys.executable to include executable suffix

Changes by Erik Bray <erik.m.b...@gmail.com>: -- stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28441> ___ _

[issue28441] Change sys.executable to include executable suffix

Erik Bray added the comment: Thanks! Setting EXE_SUFFIX from the Makefile is much better. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue28459] _pyio module broken on Cygwin / setmode not usable

Erik Bray added the comment: Hi Masayuki, thanks for the response (I thought I replied to this earlier but maybe I only imagined it--I've been on vacation). I agree with just about everything you write here. I'm aware of the FreeBSD setmode(), but I figured os.setmode() could do different

[issue28459] _pyio module broken on Cygwin / setmode not usable

New submission from Erik Bray: Since the patch to #24881 was merged the _pyio module has been non-importable on Cygwin, due to an attempt to import from the msvcrt module. However, the msvcrt module is not built on Cygwin (Cygwin does not use MSVCRT). Cygwin's libc does, however, have

[issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'

Erik Bray added the comment: FWIW this patch broke the _pyio module on Cygwin, as the msvcrt module is not built on Cygwin. AFAICT this is only a problem for Python built with MSVCRT, which Cygwin does not use. When test case works as expected on Cygwin without this. -- nosy

[issue28441] sys.executable is ambiguous on Cygwin without .exe suffix

Erik Bray added the comment: I agree this has a slight change in behavior which I was at first hesitant about. But I think the previous behavior was wrong insofar as it was overly ambiguous. I agree it should apply on MSYS2 as well (I actually thought __CYGWIN__ was defined on MSYS2 but I

[issue28441] sys.executable is ambiguous on Cygwin without .exe suffix

New submission from Erik Bray: This actually came up previously in #1543469 in the context of test_subprocess, but it's a more general issue that I thought was worth addressing somehow. The issue here is that as Cygwin tries to provide a "UNIX-like" experience, any system interfaces

[issue13756] Python3.2.2 make fail on cygwin

Erik Bray added the comment: Okay, that would explain it then. I was building from an older branch (pre-3.7) that still has the bundled libffi. FWIW with the fix from #2445, --with-system-ffi works (as does some trivial use of _ctypes though I haven't run all the tests). So if the bundled

[issue14438] _cursesmodule build fails on cygwin

Erik Bray added the comment: I see what you're saying--thanks for pointing out those other tickets. I'll give #28190 a try first. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue14438] _cursesmodule build fails on cygwin

Erik Bray added the comment: I think it would still be worth including this patch in Python. It wouldn't be the only condition in py_curses.h for platform-specific oddities with ncurses. This patch is still needed for the _curses module to build on Cygwin. -- nosy: +erik.bray

  1   2   3   >