New submission from David Coles :
See the `recv_fds` example for `socket.recvmsg`.
This code produces a `DeprecationWarning` on current versions of Python.
https://docs.python.org/3.9/library/socket.html#socket.socket.recvmsg
--
assignee: docs@python
components: Distutils
David Coles added the comment:
Please find the PR including a test to reproduce the issue here:
https://github.com/python/asyncio/pull/346
--
___
Python tracker
<http://bugs.python.org/issue22
David Coles added the comment:
Hi Yury,
Sure - I'll create a PR along with a test that reproduces the issue. Should be
able to get that done this weekend.
--
___
Python tracker
<http://bugs.python.org/is
David Coles added the comment:
Since I reported this, I haven't seen any proposed solutions other other than a
retry loop to ensure that the lock is guaranteed to be reacquired when the
sleeping coroutine is woken.
The four possibilities of cancelling the waiting coroutine are:
1. B
David Coles added the comment:
This issue can still be reproduced on Python 3.5.0a1.
(Triggers a "RuntimeError: Lock is not acquired" on cond.release())
Please let me know if there's any further steps you'd like me to take here.
--
v
David Coles added the comment:
Just for context, the reason for using a custom wait function
(cond_wait_timeout) rather than the more idiomatic
asyncio.wait_for(cond.wait(), timeout) is that the combination introduces
another subtle, but nasty locking inconsistency (see
https
David Coles added the comment:
Hi Victor,
(Sorry for the delay, I think GMail ate the notification)
The main issue is that Condition.wait MUST reacquire the associated lock
released on entry to wait() before returning or else the caller's assumption
that it holds a lock (such as `with
New submission from David Coles:
If a task that is waiting on an asyncio.Condition is cancelled after
notification but before having successfully reacquired the associated lock, the
acquire() will be cancelled causing wait() to return without the lock held
(violating wait()'s contrac
David Coles added the comment:
And here's the patch for Python 2.7.
The result of testing is as follows:
- python (default) against py2-linked gdb: All tests pass
- python (2.7) against py2-linked gdb: `test_long` fails.
- python (default) against py3-linked gdb: All tests pass
- python
David Coles added the comment:
Should probably also be applied to Python 2.7 branch since it's possible be
debugging Python 2.7 with a version of py3k-linked gdb.
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/is
David Coles added the comment:
Attached is a patch that enables the test for gdb linked against py3k.
All test failures should be fixed by the patch on issue19308.
--
keywords: +patch
nosy: +dcoles
Added file: http://bugs.python.org/file32272/test_gdb-py3k-compat.patch
David Coles added the comment:
I ended up with a very similar looking patch - and so merged my changes into
Pitrou's patch.
I also had a go at fixing up the `test_gdb` unit test, which revealed a few
more string/unicode issues. Finally tracked them down to the `write_unicode`
function.
David Coles added the comment:
Sure thing. I've got a patch attached to
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1241668 but want to make
sure that it doesn't break things on the py2-linked version.
--
___
Python trac
New submission from David Coles:
Tools/gdb/libpython.py is currently Python 3 incompatible. Unfortunately recent
versions of gdb (such as the one provided in Ubuntu 13.10) may be linked
against Python 3 rather than Python 2, breaking debugging support.
Most of the issues appear to be trivial
David Coles added the comment:
Attached is a patch that updates configure.in to make sure that wchar.h is
present and that wchar_t is at least 16 bits wide.
On android-8 this patch causes the configure step to fail since SIZEOF_WCHAR_T
== 1. On android-9 and my Linux desktop the build
David Coles added the comment:
On Fri, May 6, 2011 at 3:17 PM, Marc-Andre Lemburg
wrote:
> Since you sound like you want to get Python running on Android,
> are you aware of this project ?
>
> http://code.google.com/p/android-scripting/
Yes. It's excellent. I've actua
David Coles added the comment:
On Fri, May 6, 2011 at 2:24 PM, Martin v. Löwis wrote:
>
> Martin v. Löwis added the comment:
>
> I think what they mean is a better representation from an Android API, such
> as UChar32 from utils/AndroidUnicode.h.
Ah. Sadly I don't thi
David Coles added the comment:
On Fri, May 6, 2011 at 1:31 PM, Marc-Andre Lemburg
wrote:
> wchar_t should be fairly portable these days. I think the main
> problem is that we never assumed sizeof(wchar_t) == 1 to be a
> possibility. On Windows, wchar_t was 16 bit and the glibc star
David Coles added the comment:
After doing some more investigation it appears that Android's wchar_t support
before android-9 is totally broken (see
http://android.git.kernel.org/?p=platform/ndk.git;a=blob_plain;f=docs/STANDALONE-TOOLCHAIN.html;hb=HEAD).
With android-9 you get 4 byte wc
David Coles added the comment:
Sure. There are a few other build issues (mainly missing types/structs in
Bionic) that are preventing a complete build. I'll put together a patch once I
have a working build and can verify that HAVE_USABLE_WCHAR_T is set correctly
set on a normal Linux
New submission from David Coles :
On Android platforms bionic defines wchar_t as char. This causes compiling of
unicodeobject.c to fail with "#error "unsupported wchar_t and PyUNICODE sizes,
see issue #8670".
The unusual thing is that the configure script does detect if wc
21 matches
Mail list logo
