[pypy-svn] r52783 - pypy/dist/pypy/doc

cfbolz at codespeak.net cfbolz at codespeak.net
Thu Mar 20 17:49:46 CET 2008


Author: cfbolz
Date: Thu Mar 20 17:49:46 2008
New Revision: 52783

Modified:
   pypy/dist/pypy/doc/ctypes-implementation.txt
Log:
add articles, enhance a bit


Modified: pypy/dist/pypy/doc/ctypes-implementation.txt
==============================================================================
--- pypy/dist/pypy/doc/ctypes-implementation.txt	(original)
+++ pypy/dist/pypy/doc/ctypes-implementation.txt	Thu Mar 20 17:49:46 2008
@@ -8,26 +8,29 @@
 * interpreter level code - code written in RPython, compiled
   to something else, say C, part of the interpreter.
 
-PyPy's ctypes implementation is right now mostly proof of concept,
-based on idea of quick prototyping. The main idea was to use libffi
+PyPy's ctypes implementation is right now mostly a proof of concept,
+based on the idea of quick prototyping. The main idea was to use libffi
 (same as CPython's ctypes implementation), but try to keep as much
-as possible in Python, not RPython. In cpython's situation, it would
-be to write as few as possible code in C.
+code as possible in Python, not RPython. In CPython's situation,
+the equivalent would be to write as little as possible code in C.
 
 Low-level part (called \_rawffi)
 ================================
 
-We implemented direct bindings to libffi in RPython, allowing to create
-simple types (arrays, structures), leaving in C world, managed by hand.
-This part contains no special code to keep stuff alive and is kept
-to minimum possible. 
+We implemented direct bindings to libffi in RPython, allowing to create simple
+types (arrays, structures), living in C world, managed by hand. It also
+supports calling C functions.
+This part contains no special code to keep objects alive and is kept very minimal.
+We tried to keep this as small as possible to allow porting our ctypes
+implementation to other platforms easily. It's also thinkable that Jython uses
+our ctypes implementation by writing their version of _rawffi.
 
 High-level part (lib/\_ctypes)
 ===============================
 
-This part implements the same interface as \_ctypes module in CPython,
-but it's writte in full python. This approach allowed us to experiment
-quickly and provide working implementation in 2 months of real time.
+This part implements the same interface as the \_ctypes module in CPython,
+but it's written in full python. This approach allowed us to experiment
+quickly and provide a working implementation in 2 months of real time.
 
 Reuse of the highest level (lib/ctypes)
 ========================================
@@ -45,9 +48,9 @@
 Future
 ======
 
-Ctypes implementation in PyPy is pretty much working and can run for example
-pyglet. Because it's written in pure-python, it's rather slow. As a next
-step we'll measure what so costly and try to move certain parts from
+The Ctypes implementation in PyPy is pretty much working and can run for example
+pyglet. Because it's written in pure python, it's rather slow. As a next
+step we'll measure which parts are costly and try to move certain parts from
 app-level to interp-level to improve speed. Still, we will try to keep
-interp-level part as simple as possible, not to loose robustness.
+interp-level part as simple as possible, to not loose robustness.
 



More information about the Pypy-commit mailing list