(initial page creation from template) |
(start fleshing out the page) |
||
| Line 31: | Line 31: | ||
== Detailed Description == | == Detailed Description == | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
[http://docs.python.org/release/2.7.1/library/ctypes.html ctypes] is a Python module that allows Python code to make arbitrary function calls into C libraries. | |||
Unfortunately, such Python code needs to provide its own view of the layout of C-level type information, and if this is not in-sync with the actual C code, it it likely to segfault the python process. | |||
The underlying libraries are built with the necessary information, for use by debugging tools, in "DWARF" format, but we strip this out and place it into "debuginfo" packages, since it is large. | |||
The idea is to investigate if we can only strip part of the debuginfo, keeping the type information as part of the main library (assuming this doesn't get too large), and to then patch python, python3 and pypy to take account of this. | |||
We may want to only do this for a subset of libraries e.g. the ones that are high-value for PyPy (e.g. database connectivity). | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
<!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--> | <!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?--> | ||
This is (potentially) a distribution-wide change that would greatly improve the platform for use by PyPy, and thus Fedora would be an even better platform for PyPy usage. | |||
== Scope == | == Scope == | ||
<!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
TODO: | |||
* investigate sizes of the various parts of debuginfo across the various packages in the distro | |||
* potentially come up with some subset that are worth targeting | |||
* change the DWARF-stripping behavior to retain the information we need | |||
* patch libffi to check type information, and to extract it (for the case where no type information is provided by the caller) | |||
* patch ctypes within python and python3 to use the libffi new features, raising TypeError, or similar, if the types don't match correctly | |||
* patch pypy to cover the same ground | |||
* test! | |||
== How To Test == | == How To Test == | ||
Revision as of 16:29, 15 August 2011
Make sure you click watch on your new page so that you are notified of changes to it by others, including the Feature Wrangler
Type-safe "ctypes"
Summary
Owner
- Name: Dave Malcolm
- Email: <dmalcolm@redhat.com>
Current status
(this is just an idea at this point)
- Targeted release: [[Releases/<number> | Fedora <number> ]]
- Last updated: (DATE)
- Percentage of completion: XX%
Detailed Description
ctypes is a Python module that allows Python code to make arbitrary function calls into C libraries.
Unfortunately, such Python code needs to provide its own view of the layout of C-level type information, and if this is not in-sync with the actual C code, it it likely to segfault the python process.
The underlying libraries are built with the necessary information, for use by debugging tools, in "DWARF" format, but we strip this out and place it into "debuginfo" packages, since it is large.
The idea is to investigate if we can only strip part of the debuginfo, keeping the type information as part of the main library (assuming this doesn't get too large), and to then patch python, python3 and pypy to take account of this.
We may want to only do this for a subset of libraries e.g. the ones that are high-value for PyPy (e.g. database connectivity).
Benefit to Fedora
This is (potentially) a distribution-wide change that would greatly improve the platform for use by PyPy, and thus Fedora would be an even better platform for PyPy usage.
Scope
TODO:
- investigate sizes of the various parts of debuginfo across the various packages in the distro
- potentially come up with some subset that are worth targeting
- change the DWARF-stripping behavior to retain the information we need
- patch libffi to check type information, and to extract it (for the case where no type information is provided by the caller)
- patch ctypes within python and python3 to use the libffi new features, raising TypeError, or similar, if the types don't match correctly
- patch pypy to cover the same ground
- test!