New submission from David Coles coles.da...@gmail.com:
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
David Coles coles.da...@gmail.com 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
David Coles coles.da...@gmail.com 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
David Coles coles.da...@gmail.com added the comment:
On Fri, May 6, 2011 at 1:31 PM, Marc-Andre Lemburg
rep...@bugs.python.org 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
David Coles coles.da...@gmail.com added the comment:
On Fri, May 6, 2011 at 2:24 PM, Martin v. Löwis rep...@bugs.python.org wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
I think what they mean is a better representation from an Android API, such
as UChar32 from utils
David Coles coles.da...@gmail.com added the comment:
On Fri, May 6, 2011 at 3:17 PM, Marc-Andre Lemburg
rep...@bugs.python.org 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
David Coles coles.da...@gmail.com 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
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:
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 tracker rep
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. Sadly
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:
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 rep...@bugs.python.org
http
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 (2.7
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 contract
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 lock
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.
--
versions: +Python 3.5
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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. Before
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
21 matches
Mail list logo
