Change by Erik Bray :
--
pull_requests: +27359
pull_request: https://github.com/python/cpython/pull/4149
___
Python tracker
<https://bugs.python.org/issue45
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
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
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 lon
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
Change by Erik Bray :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
Erik Bray added the comment:
Indeed, this can be closed.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Erik Bray :
--
pull_requests: +20873
pull_request: https://github.com/python/cpython/pull/21729
___
Python tracker
<https://bugs.python.org/issue20
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"
Change by Erik Bray :
--
pull_requests: +13877
pull_request: https://github.com/python/cpython/pull/14013
___
Python tracker
<https://bugs.python.org/issue28
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
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/is
Change by Erik Bray :
--
pull_requests: +13463
___
Python tracker
<https://bugs.python.org/issue21536>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Erik Bray :
--
pull_requests: +13461
___
Python tracker
<https://bugs.python.org/issue21536>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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.
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
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
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.
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.
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
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
Change by Erik Bray :
--
pull_requests: +8199
___
Python tracker
<https://bugs.python.org/issue34212>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 ".pyx&q
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
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
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
Erik Bray added the comment:
> For those who are not very aware of Cygwin issues: what is wrong with
>
> PyVarObject_HEAD_INIT(&PyType_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, thi
Change by Erik Bray :
--
keywords: +patch
pull_requests: +7968
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34212>
___
___
Python-
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
Change by Erik Bray :
--
keywords: +patch
pull_requests: +7967
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue34211>
___
_
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(&PyType_Type, 0); PyType_R
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.py
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
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
&
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
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
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
Erik Bray added the comment:
+1, that seems obvious to me like better behavior.
--
___
Python tracker
<https://bugs.python.org/issue32797>
___
___
Python-bug
Erik Bray 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
<https://bugs.python.org/is
Erik Bray 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 tracker
<https://bugs.python.org/issu
Erik Bray added the comment:
On Feb 8, 2018 12:55, "Jeroen Demeyer" wrote:
New submission from Jeroen Demeyer :
Displaying the source code in tracebacks for Cython-compiled extension
modules in IPython no longer works due to PEP 302. Various fixes are
possible, the two most obviou
Erik Bray 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 temporary
> integer objects on eve
New submission from Erik Bray :
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 __int__ on their arguments if the inp
Change by Erik Bray :
--
pull_requests: +4856
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue23428>
___
___
Python-bugs-list mai
Change by Erik Bray :
--
keywords: +patch
pull_requests: +4855
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32243>
___
___
Python-
Erik Bray 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
never got aro
Erik Bray 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
___
Python t
New submission from Erik Bray :
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
using but
New submission from Erik Bray :
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 possibility
was still useful in the co
Erik Bray 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.
--
___
Python
Erik Bray 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 assumption.
--
___
Python tracker
&
Change by Erik Bray :
--
keywords: +patch
pull_requests: +4316
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32002>
___
___
Python-
New submission from Erik Bray :
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
relevant environment variables are e
Change by Erik Bray :
--
pull_requests: +4305
___
Python tracker
<https://bugs.python.org/issue28441>
___
___
Python-bugs-list mailing list
Unsubscribe:
Erik Bray 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
<https://bugs.pyt
Erik Bray 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
versions. My personal feeli
Erik Bray 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)
recent
Change by Erik Bray :
--
pull_requests: +4120
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue4032>
___
___
Python-bugs-list mai
Change by Erik Bray :
--
keywords: +patch
pull_requests: +4119
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31885>
___
___
Python-
New submission from Erik Bray :
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 the test on
Cygwin.
The bug is that in
Change by Erik Bray :
--
keywords: +patch
pull_requests: +4116
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31883>
___
___
Python-
New submission from Erik Bray :
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. However, that was
relatively recent (July
Change by Erik Bray :
--
keywords: +patch
pull_requests: +4115
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31882>
___
___
Python-
New submission from Erik Bray :
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 exchange file ownership info
of the
Change by Erik Bray :
--
pull_requests: +4113
___
Python tracker
<https://bugs.python.org/issue16135>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Erik Bray :
--
pull_requests: +4102
___
Python tracker
<https://bugs.python.org/issue16135>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Erik Bray :
--
nosy: +erik.bray
___
Python tracker
<https://bugs.python.org/issue31828>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Erik Bray :
--
keywords: +patch
pull_requests: +4100
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31878>
___
___
Python-
New submission from Erik Bray :
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) https://bugs.python.org
Change by Erik Bray :
--
pull_requests: +4099
stage: commit review -> patch review
___
Python tracker
<https://bugs.python.org/issue2445>
___
___
Python-
Change by Erik Bray :
--
keywords: +patch
pull_requests: +4097
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31877>
___
___
Python-
New submission from Erik Bray :
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/python.o libpython3.7m.dll.a -lintl
Changes by Erik Bray :
--
pull_requests: +2546
___
Python tracker
<http://bugs.python.org/issue24766>
___
___
Python-bugs-list mailing list
Unsubscribe:
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_someth
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
Erik Bray added the comment:
Thanks for checking!
--
___
Python tracker
<http://bugs.python.org/issue30353>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.org/issue30
Changes by Erik Bray :
--
pull_requests: +1760
___
Python tracker
<http://bugs.python.org/issue29804>
___
___
Python-bugs-list mailing list
Unsubscribe:
Erik Bray added the comment:
Sure, thanks for pointing that out.
--
___
Python tracker
<http://bugs.python.org/issue30353>
___
___
Python-bugs-list mailin
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
Changes by Erik Bray :
--
pull_requests: +1656
___
Python tracker
<http://bugs.python.org/issue30353>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
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
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
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
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
Changes by Erik Bray :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue28441>
___
___
Python-bugs-list mailing list
Unsubscrib
Erik Bray added the comment:
Thanks! Setting EXE_SUFFIX from the Makefile is much better.
--
___
Python tracker
<http://bugs.python.org/issue28441>
___
___
Pytho
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
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,
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
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
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 inter
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 bu
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
<http://bugs.python.o
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
1 - 100 of 179 matches
Mail list logo