Change by Russell Keith-Magee :
--
keywords: +patch
pull_requests: +25389
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26808
___
Python tracker
<https://bugs.python.org/issu
New submission from Russell Keith-Magee :
BPO-41486 added _BlocksOutputBuffer for the bz2, lzma and zlib module.
Part of this patch included a new header file, pycore_blocks_output_buffer.h,
which defines a BUFFER_BLOCK_SIZE constant.
If two or more of the bz2, lzma or zlib modules
Russell Keith-Magee added the comment:
It appears the 3.7.7RC1 embedded installer was also missing the file.
--
___
Python tracker
<https://bugs.python.org/issue39
New submission from Russell Keith-Magee :
The Windows python-3.7.7-embed-amd64.zip installer (released Mar 11 2020)
appears to be missing vcruntime140.dll. As a result, running the python.exe or
pythonw.exe included in that installer fails with a system error notifying you
of the missing DLL
Change by Russell Keith-Magee :
--
nosy: +freakboy3742
___
Python tracker
<https://bugs.python.org/issue36880>
___
___
Python-bugs-list mailing list
Unsubscribe:
Russell Keith-Magee <freakboy3...@gmail.com> added the comment:
For those interested, we developed a workaround for this in Rubicon:
https://github.com/pybee/rubicon-objc/pull/85/files
The fix involves using ctypes to access ctypes own internals, and build a
modified version of the Str
Russell Keith-Magee <freakboy3...@gmail.com> added the comment:
For those interested, I've started tracking these patches on Github:
https://github.com/freakboy3742/cpython
The 3.4, 3.5 and 3.6 branches are tested and compile as of the time of this
comment; the master branch has als
Russell Keith-Magee added the comment:
Since I was named dropped; it's worth pointing out that this has evidently been
fixed - intentionally or otherwise - in 3.6.
It wasn't an issue in 3.4 and earlier because __mod__ wasn't implemented for
bytestrings.
--
nosy: +freakboy3742
Changes by Russell Keith-Magee <freakboy3...@gmail.com>:
--
nosy: +freakboy3742
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Russell Keith-Magee added the comment:
Yes - I'm aware of Pythonista; the author of that app contracted me to develop
the 3.5 patch that is attached to this ticket :-)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Russell Keith-Magee added the comment:
Alex - The usual cause for that problem isn't regrtest (at least, not
directly). The cause is one of the tests in the suite spawning a subprocess.
Due to the way the test harness works, when the test suite forks/spawns a
subprocess (e.g., to run
Russell Keith-Magee added the comment:
Another update - the issue with libffi has been resolved, so there is now only
need for a single copy of libffi_ios sources.
This directory could potentially be merged with the libffi_osx sources, except
that libffi no longer supports PowerPC
Russell Keith-Magee added the comment:
It turns out I wasn't completely correct. As per my second point, the
interpretation of annotations needs be clarified, but my first point about
default_args including the annotation count is incorrect.
My error was made because of the documentation
New submission from Russell Keith-Magee:
Refs Issue16554, Issue13026, Issue14349, and probably others.
The documentation for the interpretation of the argc argument to MAKE_FUNCTION
in Doc/library/dis.rst is incorrect.
As of 13 August 2015, the docs say:
"""
Pushes a new
Changes by Russell Keith-Magee <freakboy3...@gmail.com>:
--
versions: -Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Russell Keith-Magee added the comment:
What hardware architecture are you compiling for? If it's ARM64, and you're
not using a trunk version of libffi, that segfault in test_ctypes is to be
expected.
Does this mean I can safely ignore the segfault?
Well, safely in the sense that everything
Russell Keith-Magee added the comment:
Are you using the libffi sources vendored into the Python source tree, or a
more recent version? I can verify that libffi v3.2 works on ARMv7 (on iOS,
anyway), and there's been plenty of changes to the ARM source tree since the
Python version
Russell Keith-Magee added the comment:
What hardware architecture are you compiling for? If it's ARM64, and you're not
using a trunk version of libffi, that segfault in test_ctypes is to be expected.
--
___
Python tracker rep...@bugs.python.org
http
Russell Keith-Magee added the comment:
Another update - this time, there are only 4 failing tests on device, all
related to ctypes issues.
The sample Xcode project and iOS-test harness have been modified, simplifying
the project layout, and using Apple-preferred directories for resources
Russell Keith-Magee added the comment:
Another patch update - the code now passes the full Python test suite on the
iOS simulator.
There are still a couple of failures on device; as before, these appear to be
due to ctypes problems and a permissions issue with os.mkdir.
--
Added
Russell Keith-Magee added the comment:
This new patch (20150504.diff) adds support for running the Python test suite
The new patch is standalone, and contains everything in the previous patch.
An XCode project (Tools/iOS-test) has been added to the source tree; this
project contains bootstrap
Russell Keith-Magee added the comment:
Here's an updated patch that integrates some of the feedback that has been
received so far.
Notable changes:
* The code now works for ARMv7. Unfortunately, the price for this is a new
libffi_ios_aarch source directory, containing generated source tree
Russell Keith-Magee added the comment:
Hi Matthias:
* The libffi situation on iOS is much the same as it is on OS/X - it needs to
be pre-generated. This can't be driven by the existing build system - libffi's
Makefile requires a separate pre-generation step. There's certainly potential
Russell Keith-Magee added the comment:
Nick: Finding a way to get on-device test results is next on my TODO list, once
I've got the patch up to date for trunk.
FYI - Updating to trunk is currently blocking on issue22625 (which was
introduced by the fix for issue22359).
I had thought about
Russell Keith-Magee added the comment:
I'm looking into this issue because of issue23670 (iOS support).
Am I correct in assuming that the right fix here is to identify a
$(CC_FOR_BUILD) analog for $(PYTHON_FOR_BUILD) that will identify the build
host's CC, enabling a build-host native $(PGEN
Russell Keith-Magee added the comment:
Nick: you are correct - these are changes to support iOS as a cross-compilation
target, so you can run your Python code on an iOS device. Apologies for the
confusion in nomenclature.
Ned: You're correct that the build needs to be run on an OS/X machine
New submission from Russell Keith-Magee:
Proposal: iOS should be a supported platform for Python development.
The attached patch is a first pass at a patch to achieve this. It is a single
patch against Python 3.4.2 sources, and requires no pre- or post-configure
modifications.
Supporting
Russell Keith-Magee added the comment:
Understood that buildbots are required. The subject has come up a couple of
times on mobile-sig - however, I haven't got a good answer for exactly what
this means in practice. Does build hardware need to be delivered to a specific
build farm location
Changes by Russell Keith-Magee freakboy3...@gmail.com:
--
nosy: +freakboy3742
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23496
___
___
Python
Russell Keith-Magee freakboy3...@gmail.com added the comment:
This isn't just a Python 3 issue -- I'm seeing this with the default Python
install on OS X Snow Leopard (i.e. Python 2.6.1). Changing the .pypirc config
line to [server-login] fixed the problem for me, too.
--
nosy
Russell Keith-Magee freakboy3...@gmail.com added the comment:
It's still a problem AFAICT. Level of interest is a different matter.
Django has needed this since 2006, so we've always shipped a locally modified
copy of the doctest module.
That said, Django is in the process of moving away
Russell Keith-Magee freakboy3...@gmail.com added the comment:
As an extra data point: we just hit this problem in Django ticket #13093
(http://code.djangoproject.com/ticket/13093). In our case, a decorator was
using wraps(); however, that decorator was breaking when it was used on a class
32 matches
Mail list logo
