[issue39930] Embedded installer for Python 3.7.7 missing vcruntime140.dll

2020-03-11 Thread Russell Keith-Magee


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/issue39930>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue39930] Embedded installer for Python 3.7.7 missing vcruntime140.dll

2020-03-11 Thread Russell Keith-Magee


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.

The 3.7.6 embedded install included this file.

--
components: Build, Windows
messages: 363891
nosy: freakboy3742, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Embedded installer for Python 3.7.7 missing vcruntime140.dll
versions: Python 3.7

___
Python tracker 
<https://bugs.python.org/issue39930>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36880] Returning None from a callback with restype py_object decrements None's refcount too much

2019-05-11 Thread Russell Keith-Magee


Change by Russell Keith-Magee :


--
nosy: +freakboy3742

___
Python tracker 
<https://bugs.python.org/issue36880>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue5710] ctypes should return composite types from callbacks

2017-11-22 Thread Russell Keith-Magee

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 Structure data type that is able to perform a copy when 
used as returned value. 

Hopefully we'll be able to get this into the form of a patch for ctypes that is 
acceptable to Python core.

--
nosy: +freakboy3742

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue5710>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a cross-compilation target

2017-11-06 Thread Russell Keith-Magee

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 also been updated, in preparation for the 
release of 3.7.

I haven't submitted pull requests because there are still some issues that Ned 
raised in discussions at PyCon US.

--
versions: +Python 3.6, Python 3.7

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue23670>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29073] bytearray.__mod__() truncates on first \x00

2016-12-26 Thread Russell Keith-Magee

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

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29073>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET)

2016-06-04 Thread Russell Keith-Magee

Changes by Russell Keith-Magee <freakboy3...@gmail.com>:


--
nosy: +freakboy3742

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23968>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a cross-compilation target

2016-06-03 Thread Russell Keith-Magee

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/issue23670>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a cross-compilation target

2016-03-01 Thread Russell Keith-Magee

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 a network server or a multiprocess worker), the fork 
causes the a second version of the test suite to start, rather than starting 
the server subprocess.

I've attached a patch for 3.5.1. This includes a patch to work around 
Issue22625; the patch is definitely suboptimal, but it lets a build come to 
completion. What is really needed (as requested on python-dev) is some help 
working out how to fix Issue22625 properly.

--
versions: +Python 3.5
Added file: http://bugs.python.org/file42060/20160217.diff

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23670>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a cross-compilation target

2015-12-20 Thread Russell Keith-Magee

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 as a compilation target for OS/X builds 
(and neither does Apple). If PowerPC can be dropped from the list of supported 
platforms, libffi for OS X can be updated to the current trunk sources.

--
versions: +Python 3.4 -Python 3.5
Added file: http://bugs.python.org/file41376/20151221.diff

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23670>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25836] Documentation of MAKE_FUNCTION/MAKE_CLOSURE_EXTENDED_ARG is misleading

2015-12-17 Thread Russell Keith-Magee

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 for EXTENDED_ARG. The current 
text implies that you need to combine the argument value of the EXTENDED_ARG 
opcode with the argument value for the previous opcode. However if you're using 
dis.Bytecode() to extract bytecodes, that composition is done for you - you can 
effectively ignore the EXTENDED_ARG opcode.

--
title: Documentation of MAKE_FUNCTION is still incorrect -> Documentation of 
MAKE_FUNCTION/MAKE_CLOSURE_EXTENDED_ARG is misleading

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25836>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25836] Documentation of MAKE_FUNCTION is still incorrect

2015-12-10 Thread Russell Keith-Magee

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 function object on the stack.  From bottom to top, the consumed
stack must consist of:

   * ``argc & 0xFF`` default argument objects in positional order
   * ``(argc >> 8) & 0xFF`` pairs of name and default argument, with the name
 just below the object on the stack, for keyword-only parameters
   * ``(argc >> 16) & 0x7FFF`` parameter annotation objects
   * a tuple listing the parameter names for the annotations (only if there are
 ony annotation objects)
   * the code associated with the function (at TOS1)
   * the :term:`qualified name` of the function (at TOS)
"""

However, this doesn't capture the fact that:

 * if there are annotations, the number of default arguments returned by `argc 
& 0xFF` must be reduced by `(argc >> 16) & 0x7FFF`

 * The value `(argc >> 16) & 0x7FFF` for the number of annotations *includes* 
the "extra" entry for the tuple describing which arguments the annotations 
apply to. This means that `(argc >> 16) & 0x7FFF` will be either 0, or 2+; it 
can't be 1 (because if you have one annotation, you must also have a tuple 
describing which arguments is annotated).

--
assignee: docs@python
components: Documentation
messages: 256189
nosy: docs@python, freakboy3742
priority: normal
severity: normal
status: open
title: Documentation of MAKE_FUNCTION is still incorrect
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25836>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25836] Documentation of MAKE_FUNCTION is still incorrect

2015-12-10 Thread Russell Keith-Magee

Changes by Russell Keith-Magee <freakboy3...@gmail.com>:


--
versions:  -Python 2.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25836>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23496] Steps for Android Native Build of Python 3.4.2

2015-08-20 Thread Russell Keith-Magee

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 except a very recent version of 
libffi is known to not work on ARM64 - so if it doesn't work, it's not because 
of something Python is doing wrong, it's a problem with a dependency.

Are you using the libffi sources vendored into the Python source tree, or a 
more recent version? 

By 'vendored in' do you mean 'sources included in python source tree for 
building?'

Correct. The libffi source code that is in the Python source tree is quite old, 
and *definitely* doesn't work on ARM64. I'm not even sure that it works on 
ARMv7.

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 was 
vendored in.

 Would your recommend downloading and building libffi from sources (on device) 
 and then building python?

Well, for starters - as I've said before, I'd recommend not compiling on device 
at all, but that's a separate issue. 

However, regardless of where you're compiling, you can either use an external 
libffi, or you can do what I've done in the iOS patch - update the Python 
source tree to include a newer version of libffi. If you update the source in 
the Python tree, you need to use 2 versions (or a merged version); you need 
v3.2 sources for ARMv7, and trunk sources for ARM64. This is because libffi 
v3.2 doesn't work for ARM64, and trunk doesn't even compile for ARMv7. See the 
iOS patch for details.

 I'm asking the above questions because I've hit a fairly significant 
 roadblock; I'm still getting the segfault when test_ctypes is run and I can't 
 seem to get anything useful out of gdb.

Personally, I've pretty much given up on CPython on Android. Even when I got it 
working, the performance of the JNI layer is *abysmal*, and severely crippled. 
If you're planning to actually interact with the device in any way (like, say, 
put a button on the screen), that's a big problem. 

I'm working on an approach that uses Java natively - think Jython for 
Android. I'm still a way off having anything working, though.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23496
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23496] Steps for Android Native Build of Python 3.4.2

2015-07-24 Thread Russell Keith-Magee

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 was vendored in.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23496
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23496] Steps for Android Native Build of Python 3.4.2

2015-07-23 Thread Russell Keith-Magee

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://bugs.python.org/issue23496
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a cross-compilation target

2015-07-04 Thread Russell Keith-Magee

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 when 
deployed to device.

--
Added file: http://bugs.python.org/file39862/20150704.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23670
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a cross-compilation target

2015-06-28 Thread Russell Keith-Magee

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 file: http://bugs.python.org/file39824/20150628.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23670
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a cross-compilation target

2015-05-04 Thread Russell Keith-Magee

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 C code to start and run the full Python regression 
test suite.

There's also a new target in the iOS/Makefile meta-buildfile - make test - 
which will compile a debug version of the Python framework, and install it into 
the iOS-test project.

Getting the test suite to run has revealed one major limitation of the iOS 
platform - system calls like fork, exec*, and spawn* don't work. The OS calls 
*exist* at an API level - but if you use them, they either crash, or they lock 
up the device while you wait for a subprocess that will never execute. This 
makes sense considering the platform itself - there's no such thing as a 
background process in iOS; background tasks are very heavily sandboxed. 

A number of other minor problems have been identified as a result of running 
the full test suite; they have been addressed in the patch.

The test suite still has 5 failures on the simulator. I'm investigating the 
cause of these failures.

There's a couple of more failures on a physical device - 13 failures in total. 
These device-specific failures appear to be largely due to ctypes problems and 
a permissions issue with os.mkdir. 

If you run the test suite in XCode as a debug binary, the debugger will stop 
whenever a SIGPIPE, SIGINT, SIGXFSZ, SIGUSR1 or SIGUSR2 signal is raised. You 
can just hit continue in the debugger, and the test will continue. To work 
around this, you need to run the following debugger commands before the first 
signal is raised:

process handle SIGPIPE -n true -p true -s false
process handle SIGINT -n true -p true -s false
process handle SIGXFSZ -n true -p true -s false
process handle SIGUSR1 -n true -p true -s false
process handle SIGUSR2 -n true -p true -s false

I've been doing this by setting a breakpoint in the main.c method; I'm 
investigating other ways to automate this.

--
Added file: http://bugs.python.org/file39286/20150504.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23670
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a cross-compilation target

2015-04-25 Thread Russell Keith-Magee

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 for the 
ARM64 platform. I've been working with the libffi community to address the 
compilation problems that exist in trunk, but so far, this hasn't resulted in a 
fix for the problems that have been introduced in their trunk code.

* I looked into merging the libffi_ios and libffi_osx directories, but this 
proved to be harder I thought because of legacy PowerPC support. libffi still 
ships PowerPC sources, but they're no longer included in OS/X builds, because 
Apple stopped supporting PowerPC with OS/X 10.6 (released in 2009; the last 
PowerPC Apple hardware was shipped in 2006). As a result, it's difficult to 
find compilation instructions, and even harder to find actual hardware to test 
builds. If support for PowerPC architectures (on OS/X) was deprecated, this 
would make merging the libffi_ios and libffi_osx a trivial activity.

* I've audited plat_ios/IN.py, and can now confirm that it *is* identical 
between platforms.

* I have looked into replacing Setup.* with some sort of post-configure 
procedure as suggested by @doko. Unfortunately, it's not that simple. The 
problem is that there is already 2 places where the build requirements for a 
built-in module are defined. Modules/Setup contains one set of instructions 
(although those instructions are often commented out). The second set is hard 
coded into setup.py. 

The versions in setup.py are probably more reliable (as they're the ones 
actually used for most platforms), but you need to have a working Python to 
access them. However, at the post-configure point, you don't have a working 
Python, so there's a bootstrapping problem.

I've refactored the Setup.ios-* definitions so that there's less duplication. 
There's now a Setup.embedded that contains the common build instructions for 
all the modules without platform-specific build instructions. Setup.ios-* just 
contains the platform-specific build instructions (in much the same way as 
setup.py has configure_ctypes_darwin).

To work around this completely, we'd need to either introduce the need for a 
bootstrap Python so that a post-configure setup could access the build 
instructions contained in setup.py, or massively refactor the process of 
building modules so that there was a set of build instructions that both 
makesetup and setup.py could use.

--
Added file: http://bugs.python.org/file39207/20150426.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23670
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a cross-compilation target

2015-04-15 Thread Russell Keith-Magee

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 
for reuse between the OS/X and iOS generated files, though - there's no reason 
I couldn't merge the libffi_ios tree into the libffi_darwin tree - they reuse a 
lot of the same code for the x86-64 platform.

 * Regarding Setup.* - if shipping specific Setup.* files is a problem, I can 
certainly look at enhancing the makesetup process to generate these, rather 
than shipping generated files. 

 * I'll add a comment to the setup.py change. Essentially, it's an edge case of 
the current setup.py - if you don't have *any* external modules, the current 
logic breaks evaluating the size of the columns to use when displaying external 
modules that haven't been compiled - although it's displaying the list of 
*missing* modules, it uses the longest name in the *existent* extensions to 
determine the display column width.

 * The Plat_ios constants certainly appear to be the same for all platforms; 
admittedly, though, I haven't done a thorough audit of this. I'll put this on 
my todo list.

 * The build triples are armv7-apple-ios for older 32 bit iOS devices, 
aarch64-apple-ios for newer 64 bit devices, and x86_64-apple-ios on the 
simulator. Builds for armv6-apple-ios and armv7s-apple-ios are also 
plausible, but armv7 and aarch64 is what XCode supports as a default 
configuration at present.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23670
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a cross-compilation target

2015-03-16 Thread Russell Keith-Magee

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 using a mobile testing farm as a service, but I didn't 
know Sauce Labs had one. I'll keep that in mind when I get around to working on 
the test suite.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23670
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22625] When cross-compiling, don’t try to execute binaries

2015-03-16 Thread Russell Keith-Magee

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) and _freeze_importlib to be 
compiled?

--
nosy: +freakboy3742

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22625
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a cross-compilation target

2015-03-15 Thread Russell Keith-Magee

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, and 
needs to be done in multiple passes because of the need for multiple SDKs.

I've taken the approach of using Setup.local for two reasons. 

Firstly, iOS requires a fully embedded Python, because Apple doesn't approve 
of the use of dynamic loading in apps. Setup.local was the best way I found to 
force modules to be statically linked into the main library.

Secondly, because of the nature of the end-deployment, I imagine it's 
inevitable that serious end-users will want to customise their Python build for 
specific applications. AppStore submission rules prohibit running code that 
wasn't shipped with the app (i.e., Apple won't let you do an end-run around 
their app approval processes), so the set of modules you're actually using will 
be a known quantity. Since a full iOS Python build is 34MB or so, much of 
that bulk will be for binary support of modules that you aren't using, 
providing an easily configurable way to prune out unused modules from the built 
product seemed like a useful facility. There's also the issue of providing 
support for the standard library modules (like SSL) that have dependencies that 
can't be easily provided or specified out-of-the-box. 

If there's a better/more palatable approach than using Setup.local, I'm happy 
to look into it.

The libffi code is a direct copy from the current (as of a week or so ago) 
libffi trunk. There have been some bug fixes applied since 3.2.1 was released 
in november that are necessary to support ctypes on ARM64 (but, as I flagged in 
my original comment, introduces bugs for ARMv7). The libffi repo suggests the 
next version will be 4.0, but I have no idea when that will be finalised. I'm 
currently trying to get their release plans confirmed. 

As with OS/X libffi support, the source code needs to be generated, rather than 
just ./configure  make'd. That said, the libffi_darwin code could be 
re-used, as the x86_64 components are the same for Darwin as the iOS simulator.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23670
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a development platform

2015-03-15 Thread Russell Keith-Magee

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 iOS requires multiple builds - one for each of the hardware 
platforms that iOS supports (x86_64 simulator, ARMv7 and ARM64). These separate 
builds must then be merged into a single fat framework. The patch contains an 
iOS directory with a meta Makefile that manages this build-and-merge process. 
See the README in the iOS directory for details on usage.

The patch also introduces a new 'ios' platform type.

A sample XCode project for an iOS app is also provided as part of the patch.

iOS/README contains a couple of other notes about the build and the approach 
taken.

There are some known problems/limitations with this patch:

 * It's a patch against 3.4.2, not hg trunk

 * The code doesn't currently compile for ARMv7. In order to support ARM64, it 
has been necessary to use an unreleased trunk version of libffi; however, this 
version is currently broken for ARMv7. Older versions of libffi (including the 
formal 3.2.1 release) *do* work.

 * The patch doesn't currently provide any way to run the test suite on the 
target platform. Testing is currently based on a simple smoke test of some 
basic features.

So - the patch isn't ready for commit to trunk. I'm presenting it for the 
purposes of getting feedback on the broad approach while I continue to resolve 
the known issues.

--
components: Build, Cross-Build
files: 20150314.diff
keywords: patch
messages: 238125
nosy: freakboy3742
priority: normal
severity: normal
status: open
title: Modifications to support iOS as a development platform
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file38493/20150314.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23670
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23670] Modifications to support iOS as a cross-compilation target

2015-03-15 Thread Russell Keith-Magee

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, or can it just run in my home office? Does it need to be 
running 24/7, or just guarantee that at least X builds per week, or Y% of all 
builds are tested?

In terms of physical specifications - at a minimum, at least two iDevices will 
be required (an ARMv7 device, like a 5th Gen iPod, and an ARM64 device, like an 
iPhone 5S), tethered to a Mac that runs the simulator.

In terms of execution - there's definitely ways to remote-control the 
deployment and execution of apps, so I imagine buildbot integration is in the 
realm of the possible.

Android will have similar requirements, but Android also has an emulator which 
would allow testing without the existence of a physical device, which would 
provide an alternative approach.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23670
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23496] Steps for Android Native Build of Python 3.4.2

2015-02-21 Thread Russell Keith-Magee

Changes by Russell Keith-Magee freakboy3...@gmail.com:


--
nosy: +freakboy3742

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23496
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11472] upload command fails to read auth information from .pypirc

2011-09-23 Thread Russell Keith-Magee

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: +freakboy3742

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11472
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1521051] Extra configurability for doctest TestCases

2010-09-12 Thread Russell Keith-Magee

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 from using and recommending 
doctests, so there's a good chance that we'll be deprecating our local copy in 
the near future. 

There's still value in the idea -- it provides configuration points that are 
consistent and reasonable -- but Django's need for this set of changes is 
waning.

--
nosy: +freakboy3742

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1521051
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3445] Ignore missing attributes in functools.update_wrapper

2010-03-12 Thread Russell Keith-Magee

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 
with a __call__ method, because the instance of the class doesn't have a 
__name__ attribute. 

We've implemented the proposed workaround (i.e., check the attributes that are 
available and provide that tuple as the assigned argument), but I don't agree 
that this should be expected behavior. wraps() is used to make a decorated 
callable look like the callable that is being decorated; if there are different 
types of callable objects, I would personally expect wraps() to adapt to the 
differences, not raise an error if it sees anything other than a function. 

True, some attributes (like __doc__) won't always be correct as a result of 
wrapping on non-vanilla functions -- but then, that's true of plain vanilla 
functions, too. A decorator wrapping a function can fundamentally change what 
the wrapped function does, and there's no guarantee that the docstring for the 
wrapped function will still be correct after decoration.

--
nosy: +freakboy3742
versions: +Python 2.5, Python 2.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3445
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com