[issue44458] Duplicate symbol _BUFFER_BLOCK_SIZE when statically linking multiple modules
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/issue44458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44458] Duplicate symbol _BUFFER_BLOCK_SIZE when statically linking multiple modules
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 are compiled as statically linked modules (i.e., added to Lib/Setup.local), this results in a duplicate symbol error when the Python executable is linked: ``` duplicate symbol '_BUFFER_BLOCK_SIZE' in: libpython3.10.a(_bz2module.o) libpython3.10.a(_lzmamodule.o) duplicate symbol '_BUFFER_BLOCK_SIZE' in: libpython3.10.a(_bz2module.o) libpython3.10.a(zlibmodule.o) ``` -- components: Extension Modules messages: 396114 nosy: freakboy3742 priority: normal severity: normal status: open title: Duplicate symbol _BUFFER_BLOCK_SIZE when statically linking multiple modules type: compile error versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue44458> ___ ___ 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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
