Commits

Alex Gaynor committed d343da0 Merge

merged upstream

  • Participants
  • Parent commits d140a90, 0d7e2fc

Comments (0)

Files changed (5)

File pypy/doc/architecture.rst

 
  * a compliant, flexible and fast implementation of the Python_ Language 
    which uses the above toolchain to enable new advanced high-level features 
-   without having to encode the low-level details.
+   without having to encode the low-level details.  We call this PyPy.
 
 By separating concerns in this way, our implementation
 of Python - and other dynamic languages - is able to automatically
 High Level Goals
 =============================
 
-PyPy - the Translation Framework 
+RPython - the Translation Toolchain
 -----------------------------------------------
 
 Traditionally, language interpreters are written in a target platform language
 very challenging because of the involved complexity.
 
 
-PyPy - the Python Interpreter 
+PyPy - the Python Interpreter
 --------------------------------------------
 
 Our main motivation for developing the translation framework is to
 of `Extreme Programming`_, the architecture of PyPy has evolved over time
 and continues to evolve.  Nevertheless, the high level architecture is 
 stable. As described above, there are two rather independent basic
-subsystems: the `Python Interpreter`_ and the `Translation Framework`_.
+subsystems: the `PyPy Python Interpreter`_ and the `RPython Translation Toolchain`_.
 
 .. _`translation framework`:
 
-The Translation Framework
+RPython Translation Toolchain
 -------------------------
 
 The job of the RPython toolchain is to translate RPython_ programs
 
 * Optionally, `various transformations`_ can then be applied which, for
   example, perform optimizations such as inlining, add capabilities
-  such as stackless-style concurrency (deprecated), or insert code for the
+  such as stackless-style concurrency, or insert code for the
   `garbage collector`_.
 
 * Then, the graphs are converted to source code for the target platform
 .. _`standard interpreter`: 
 .. _`python interpreter`: 
 
-The Python Interpreter
+PyPy Python Interpreter
 -------------------------------------
 
 PyPy's *Python Interpreter* is written in RPython and implements the

File pypy/doc/faq.rst

 CPython extension and replace it with a pure python version that the
 JIT can see.
 
-We fully support ctypes-based extensions.
+We fully support ctypes-based extensions. But for best performance, we
+recommend that you use the cffi_ module to interface with C code.
 
 For information on which third party extensions work (or do not work) 
 with PyPy see the `compatibility wiki`_.
 
 .. _`extension modules`: cpython_differences.html#extension-modules
 .. _`cpython differences`: cpython_differences.html
-.. _`compatibility wiki`: https://bitbucket.org/pypy/compatibility/wiki/Home
+.. _`compatibility wiki`:
+.. https://bitbucket.org/pypy/compatibility/wiki/Home
+.. _cffi: http://cffi.readthedocs.org/
 
 ---------------------------------
 On which platforms does PyPy run?
 bootstrap, as cross compilation is not really meant to work yet.
 At the moment you need CPython 2.5 - 2.7
 for the translation process. PyPy's JIT requires an x86 or x86_64 CPU.
+(There has also been good progress on getting the JIT working for ARMv7.)
 
 ------------------------------------------------
 Which Python version (2.x?) does PyPy implement?
 * Second, and perhaps most important: do you have a really good reason
   for writing the module in RPython in the first place?  Nowadays you
   should really look at alternatives, like writing it in pure Python,
-  using ctypes if it needs to call C code.  Other alternatives are being
-  developed too (as of summer 2011), like a Cython binding.
+  using cffi_ if it needs to call C code.
 
 In this context it is not that important to be able to translate
 RPython modules independently of translating the complete interpreter.

File pypy/doc/getting-started-dev.rst

 The translator is a tool based on the PyPy interpreter which can translate
 sufficiently static RPython programs into low-level code (in particular it can
 be used to translate the `full Python interpreter`_). To be able to experiment with it
-you need to:
+you need to download and install the usual (CPython) version of:
 
-  * Download and install Pygame_.
-
-  * Download and install `Dot Graphviz`_ 
+  * Pygame_
+  * `Dot Graphviz`_
 
 To start the interactive translator shell do::
 

File pypy/doc/whatsnew-head.rst

 Moves optimized JIT frames from stack to heap. As a side effect it enables
 stackless to work well with the JIT on PyPy. Also removes a bunch of code from
 the GC which fixes cannot find gc roots.
+
+.. branch: pycon2013-doc-fixes
+Documentation fixes after going through the docs at PyCon 2013 sprint.

File rpython/rlib/ropenssl.py

 ssl_external('SSLv23_method', [], SSL_METHOD)
 ssl_external('SSL_CTX_use_PrivateKey_file', [SSL_CTX, rffi.CCHARP, rffi.INT], rffi.INT)
 ssl_external('SSL_CTX_use_certificate_chain_file', [SSL_CTX, rffi.CCHARP], rffi.INT)
-ssl_external('SSL_CTX_get_options', [SSL_CTX], rffi.INT, macro=True)
-ssl_external('SSL_CTX_set_options', [SSL_CTX, rffi.INT], rffi.INT, macro=True)
+ssl_external('SSL_CTX_get_options', [SSL_CTX], rffi.LONG, macro=True)
+ssl_external('SSL_CTX_set_options', [SSL_CTX, rffi.LONG], rffi.LONG, macro=True)
 if HAVE_SSL_CTX_CLEAR_OPTIONS:
-    ssl_external('SSL_CTX_clear_options', [SSL_CTX, rffi.INT], rffi.INT,
+    ssl_external('SSL_CTX_clear_options', [SSL_CTX, rffi.LONG], rffi.LONG,
                  macro=True)
 ssl_external('SSL_CTX_ctrl', [SSL_CTX, rffi.INT, rffi.INT, rffi.VOIDP], rffi.INT)
 ssl_external('SSL_CTX_set_verify', [SSL_CTX, rffi.INT, rffi.VOIDP], lltype.Void)